diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 423a756498d04..3dc58dace2ece 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -6,12 +6,12 @@ [PingCAP ウェブサイトの TiDB ドキュメント](https://docs.pingcap.com/tidb/stable)を改善するには、次のいずれかの項目から始めることができます。 -- タイプミスやフォーマット（句読点、スペース、インデント、コードブロックなど）を修正します -- 不適切または古い説明を修正または更新する -- 不足しているコンテンツ（文、段落、または新しいドキュメント）を追加します -- ドキュメントの変更を英語から中国語に翻訳する -- 提出、返信、解決[ドキュメントの問題](https://github.com/pingcap/docs/issues) -- (上級) 他の人が作成したプルリクエストを確認する +- タイプミスやフォーマット（句読点、スペース、インデント、コードブロックなど）を修正します +- 不適切または古い説明を修正または更新する +- 不足しているコンテンツ（文、段落、または新しいドキュメント）を追加します +- ドキュメントの変更を英語から中国語に翻訳する +- 提出、返信、解決[ドキュメントの問題](https://github.com/pingcap/docs/issues) +- (上級) 他の人が作成したプルリクエストを確認する ## 貢献する前に {#before-you-contribute} @@ -19,11 +19,11 @@ ### スタイルに慣れる {#get-familiar-with-style} -- [コミットメッセージのスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#how-to-write-a-good-commit-message) -- [プルリクエストのタイトルスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#pull-request-title-style) -- [マークダウンルール](/resources/markdownlint-rules.md) -- [コードコメントスタイル](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) +- [コミットメッセージのスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#how-to-write-a-good-commit-message) +- [プルリクエストのタイトルスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#pull-request-title-style) +- [マークダウンルール](/resources/markdownlint-rules.md) +- [コードコメントスタイル](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/)を使用することをお勧めします。図を描く必要がある場合は、ガイドを参照し、テンプレートで提供されている図形や色を使用してください。 @@ -33,29 +33,29 @@ TiDB 用の新しいドキュメントを作成する場合は、当社のスタ プル リクエストを送信する前に、次のテンプレートを確認してください。 -- [概念](/resources/doc-templates/template-concept.md) -- [タスク](/resources/doc-templates/template-task.md) -- [参照](/resources/doc-templates/template-reference.md) -- [新機能](/resources/doc-templates/template-new-feature.md) -- [トラブルシューティング](/resources/doc-templates/template-troubleshooting.md) +- [概念](/resources/doc-templates/template-concept.md) +- [タスク](/resources/doc-templates/template-task.md) +- [参照](/resources/doc-templates/template-reference.md) +- [新機能](/resources/doc-templates/template-new-feature.md) +- [トラブルシューティング](/resources/doc-templates/template-troubleshooting.md) ### ドキュメントのバージョンについて学ぶ {#learn-about-docs-versions} 異なるバージョンの TiDB ドキュメントを管理するために、個別のブランチを使用します。 -- [開発中のドキュメント](https://docs.pingcap.com/tidb/dev)は`master`ブランチで維持されます。 -- [公開された文書](https://docs.pingcap.com/tidb/stable/)は対応する`release-`ブランチでメンテナンスされています。例えば、TiDB v8.1 のドキュメントは`release-8.1`ブランチでメンテナンスされています。 -- [アーカイブされた文書](https://docs-archive.pingcap.com/)はメンテナンスされなくなり、今後更新されることはありません。 +- [開発中のドキュメント](https://docs.pingcap.com/tidb/dev)は`master`ブランチで維持されます。 +- [公開された文書](https://docs.pingcap.com/tidb/stable/)は対応する`release-`ブランチでメンテナンスされています。例えば、TiDB v8.1 のドキュメントは`release-8.1`ブランチでメンテナンスされています。 +- [アーカイブされた文書](https://docs-archive.pingcap.com/)はメンテナンスされなくなり、今後更新されることはありません。 ### チェリーピックラベルを使用する {#use-cherry-pick-labels} あるドキュメント バージョンへの変更は他のドキュメント バージョンにも適用されることが多いため、チェリー ピック ラベルに基づいて PR チェリー ピック プロセスを自動化する[ti-chi-bot](https://github.com/ti-chi-bot)を導入します。 -- 変更が特定のドキュメントバージョンにのみ適用される場合は、そのドキュメントバージョンのブランチに基づいてPRを作成してください。チェリーピックラベルを追加する必要はありません。 +- 変更が特定のドキュメントバージョンにのみ適用される場合は、そのドキュメントバージョンのブランチに基づいてPRを作成してください。チェリーピックラベルを追加する必要はありません。 -- 変更が複数のドキュメントバージョンに適用される場合は、複数のPRを作成する代わりに、最新の適用可能なブランチ（例： `master` ）に基づいて1つのPRを作成し、適用可能なドキュメントバージョンに応じて1つまたは複数の`needs-cherry-pick-release-`ラベルをPRに追加します。PRがマージされると、ti-chi-botは指定されたバージョンのブランチに基づいて、対応するチェリーピックPRを自動的に作成します。 +- 変更が複数のドキュメントバージョンに適用される場合は、複数のPRを作成する代わりに、最新の適用可能なブランチ（例： `master` ）に基づいて1つのPRを作成し、適用可能なドキュメントバージョンに応じて1つまたは複数の`needs-cherry-pick-release-`ラベルをPRに追加します。PRがマージされると、ti-chi-botは指定されたバージョンのブランチに基づいて、対応するチェリーピックPRを自動的に作成します。 -- 変更の大部分が複数のドキュメントバージョンに適用されるものの、バージョン間で差異が存在する場合は、対象バージョンすべてにチェリーピックラベルを付与するだけでなく、PRレビュアーへのリマインダーとして「 `requires-version-specific-change`ラベルも付与する必要があります。PRがマージされ、ti-chi-botが対応するチェリーピックPRを作成した後でも、これらのチェリーピックPRに変更を加えることができます。 +- 変更の大部分が複数のドキュメントバージョンに適用されるものの、バージョン間で差異が存在する場合は、対象バージョンすべてにチェリーピックラベルを付与するだけでなく、PRレビュアーへのリマインダーとして「 `requires-version-specific-change`ラベルも付与する必要があります。PRがマージされ、ti-chi-botが対応するチェリーピックPRを作成した後でも、これらのチェリーピックPRに変更を加えることができます。 ## 貢献方法 {#how-to-contribute} @@ -71,8 +71,8 @@ TiDB 用の新しいドキュメントを作成する場合は、当社のスタ ### ステップ1: リポジトリをフォークする {#step-1-fork-the-repository} -1. プロジェクトを訪問: [https://github.com/pingcap/docs](https://github.com/pingcap/docs) -2. 右上の**フォーク**ボタンをクリックし、完了するまで待ちます。 +1. プロジェクトを訪問: [https://github.com/pingcap/docs](https://github.com/pingcap/docs) +2. 右上の**フォーク**ボタンをクリックし、完了するまで待ちます。 ### ステップ2: フォークしたリポジトリをローカルストレージにクローンする {#step-2-clone-the-forked-repository-to-local-storage} @@ -87,7 +87,7 @@ git remote -v # Confirms that your remote makes sense ### ステップ3: 新しいブランチを作成する {#step-3-create-a-new-branch} -1. ローカル マスターを、upstream/master で最新の状態にします。 +1. ローカル マスターを、upstream/master で最新の状態にします。 ``` cd $working_dir/docs @@ -96,7 +96,7 @@ git remote -v # Confirms that your remote makes sense git rebase upstream/master ``` -2. マスター ブランチに基づいて新しいブランチを作成します。 +2. マスター ブランチに基づいて新しいブランチを作成します。 ``` git checkout -b new-branch-name @@ -132,8 +132,8 @@ git push -u origin new-branch-name # "-u" is used to track the remote branch fro ### ステップ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 を作成します。詳細は[プルリクエストのタイトルスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#pull-request-title-style)を参照してください。 +1. [https://github.com/$user/docs](https://github.com/$user/docs)でフォークにアクセスします ( `$user` GitHub ID に置き換えます) +2. `new-branch-name`ブランチの横にある`Compare & pull request`ボタンをクリックして PR を作成します。詳細は[プルリクエストのタイトルスタイル](https://github.com/pingcap/community/blob/master/contributors/commit-message-pr-style.md#pull-request-title-style)を参照してください。 これで、PR が正常に送信されました。この PR がマージされると、自動的に TiDB ドキュメントの貢献者になります。 @@ -143,16 +143,16 @@ git push -u origin new-branch-name # "-u" is used to track the remote branch fro 変更が以下のいずれかの状況に該当する場合は、 **「マスターブランチのみを選択」すること**をお勧めします。PRがマージされると、変更はすぐに[PingCAP ドキュメント ウェブサイトの開発ページ](https://docs.pingcap.com/tidb/dev/)に表示されます。TiDBの次のメジャーバージョンまたはマイナーバージョンがリリースされると、変更は新しいバージョンのウェブサイトページにも表示されます。 -- 欠落または不完全なドキュメントの内容を補足するなど、ドキュメントの拡張に関連します。 -- 値、説明、例、タイプミスなど、不正確または間違ったドキュメントの内容を修正します。 -- 特定のトピック モジュールでのドキュメントのリファクタリングが含まれます。 +- 欠落または不完全なドキュメントの内容を補足するなど、ドキュメントの拡張に関連します。 +- 値、説明、例、タイプミスなど、不正確または間違ったドキュメントの内容を修正します。 +- 特定のトピック モジュールでのドキュメントのリファクタリングが含まれます。 変更が以下のいずれかの状況に当てはまる場合は、**影響を受けるリリース ブランチとマスターを選択してください**。 -- 特定のバージョンに関連する機能の動作の変更が含まれます。 -- 構成項目またはシステム変数のデフォルト値の変更など、互換性の変更が含まれます。 -- 表示エラーを解決するためにフォーマットを修正します -- 壊れたリンクを修正 +- 特定のバージョンに関連する機能の動作の変更が含まれます。 +- 構成項目またはシステム変数のデフォルト値の変更など、互換性の変更が含まれます。 +- 表示エラーを解決するためにフォーマットを修正します +- 壊れたリンクを修正 ## TiDB Cloudドキュメントへの貢献に関するガイドライン {#guideline-for-contributing-to-tidb-cloud-documentation} @@ -162,8 +162,8 @@ git push -u origin new-branch-name # "-u" is used to track the remote branch fro > > 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によって再利用されることを意味します。 +> - このファイル内のドキュメントのパスが`/tidb-cloud/`で始まる場合、このドキュメントはTiDB Cloud Dedicatedであることを意味します。 +> - このファイル内のドキュメントのパスが`/tidb-cloud/`で始まっていない場合は、この TiDB ドキュメントがTiDB Cloudによって再利用されることを意味します。 TiDB Cloudで再利用される一部の TiDB ドキュメントには、 `CustomContent`タグが含まれている場合があります。これらの`CustomContent`タグは、TiDB またはTiDB Cloudの専用コンテンツを示すために使用されます。 @@ -197,9 +197,9 @@ TiDB Cloudで再利用される一部の TiDB ドキュメントには、 `Custo この例では、 -- ``タグ内のコンテンツは TiDB にのみ適用され、 [TiDB Cloudドキュメント](https://docs.pingcap.com/tidbcloud/) Web サイトには表示されません。 -- ``タグ内のコンテンツはTiDB Cloudにのみ適用され、 [TiDBドキュメント](https://docs.pingcap.com/tidb/stable) Web サイトには表示されません。 -- ``タグで囲まれていないコンテンツは、TiDB とTiDB Cloud の両方に適用され、両方のドキュメント Web サイトに表示されます。 +- ``タグ内のコンテンツは TiDB にのみ適用され、 [TiDB Cloudドキュメント](https://docs.pingcap.com/tidbcloud/) Web サイトには表示されません。 +- ``タグ内のコンテンツはTiDB Cloudにのみ適用され、 [TiDBドキュメント](https://docs.pingcap.com/tidb/stable) Web サイトには表示されません。 +- ``タグで囲まれていないコンテンツは、TiDB とTiDB Cloud の両方に適用され、両方のドキュメント Web サイトに表示されます。 ## EBNF図のプレビューのガイドライン {#guideline-for-previewing-ebnf-diagrams} diff --git a/README.md b/README.md index 7fbaf2ff12fa3..8d1bbb0fa55b9 100644 --- a/README.md +++ b/README.md @@ -10,16 +10,16 @@ TiDB ドキュメント内の特定のコンテンツを自由に並べ替えた 現在、公式ドキュメントは次の 2 つの言語をサポートしています。 -- `en` : [英語のドキュメント](https://docs.pingcap.com/tidb/stable) -- `zh` : [中国語のドキュメント](https://docs.pingcap.com/zh/tidb/stable) +- `en` : [英語のドキュメント](https://docs.pingcap.com/tidb/stable) +- `zh` : [中国語のドキュメント](https://docs.pingcap.com/zh/tidb/stable) Google翻訳を使えば、ドキュメントを様々な言語で閲覧できます。例えば： -- `fr` : [フランス語のドキュメント](https://docs-pingcap-com.translate.goog/tidb/stable?_x_tr_sl=auto&_x_tr_tl=fr&_x_tr_hl=en&_x_tr_pto=wapp&_x_tr_hist=true) -- `ja` : [日本語のドキュメント](https://docs-pingcap-com.translate.goog/tidb/stable?_x_tr_sl=auto&_x_tr_tl=ja&_x_tr_hl=en&_x_tr_pto=wapp&_x_tr_hist=true) -- `ko` : [韓国語のドキュメント](https://docs-pingcap-com.translate.goog/tidb/stable?_x_tr_sl=auto&_x_tr_tl=ko&_x_tr_hl=en&_x_tr_pto=wapp&_x_tr_hist=true) -- `de` : [ドイツ語のドキュメント](https://docs-pingcap-com.translate.goog/tidb/stable?_x_tr_sl=auto&_x_tr_tl=de&_x_tr_hl=en&_x_tr_pto=wapp&_x_tr_hist=true) -- `es` : [スペイン語のドキュメント](https://docs-pingcap-com.translate.goog/tidb/stable?_x_tr_sl=auto&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp&_x_tr_hist=true) +- `fr` : [フランス語のドキュメント](https://docs-pingcap-com.translate.goog/tidb/stable?_x_tr_sl=auto&_x_tr_tl=fr&_x_tr_hl=en&_x_tr_pto=wapp&_x_tr_hist=true) +- `ja` : [日本語のドキュメント](https://docs-pingcap-com.translate.goog/tidb/stable?_x_tr_sl=auto&_x_tr_tl=ja&_x_tr_hl=en&_x_tr_pto=wapp&_x_tr_hist=true) +- `ko` : [韓国語のドキュメント](https://docs-pingcap-com.translate.goog/tidb/stable?_x_tr_sl=auto&_x_tr_tl=ko&_x_tr_hl=en&_x_tr_pto=wapp&_x_tr_hist=true) +- `de` : [ドイツ語のドキュメント](https://docs-pingcap-com.translate.goog/tidb/stable?_x_tr_sl=auto&_x_tr_tl=de&_x_tr_hl=en&_x_tr_pto=wapp&_x_tr_hist=true) +- `es` : [スペイン語のドキュメント](https://docs-pingcap-com.translate.goog/tidb/stable?_x_tr_sl=auto&_x_tr_tl=es&_x_tr_hl=en&_x_tr_pto=wapp&_x_tr_hist=true) ## ドキュメントのバージョン {#documentation-versions} diff --git a/TOC-api.md b/TOC-api.md index ab1cee7d79924..a0a3be8ce5945 100644 --- a/TOC-api.md +++ b/TOC-api.md @@ -6,15 +6,15 @@ ## TiDB Cloud -- [APIの概要](/api/tidb-cloud-api-overview.md) -- [API v1beta2](/api/tidb-cloud-api-v1beta2.md) -- [API v1beta1](/api/tidb-cloud-api-v1beta1.md) -- [API v1beta](/api/tidb-cloud-api-v1beta.md) +- [APIの概要](/api/tidb-cloud-api-overview.md) +- [API v1beta2](/api/tidb-cloud-api-v1beta2.md) +- [API v1beta1](/api/tidb-cloud-api-v1beta1.md) +- [API v1beta](/api/tidb-cloud-api-v1beta.md) ## TiDB Self-Managed -- [TiProxy API](/api/tiproxy-api-overview.md) -- [データ移行API](/api/dm-api-overview.md) -- [モニタリングAPI](/api/monitoring-api-overview.md) -- [TiCDC API](/api/ticdc-api-overview.md) -- [TiDB Operator API](/api/tidb-operator-api-overview.md) +- [TiProxy API](/api/tiproxy-api-overview.md) +- [データ移行API](/api/dm-api-overview.md) +- [モニタリングAPI](/api/monitoring-api-overview.md) +- [TiCDC API](/api/ticdc-api-overview.md) +- [TiDB Operator API](/api/tidb-operator-api-overview.md) diff --git a/TOC-best-practices.md b/TOC-best-practices.md index ab818b302294c..1f6eb78112390 100644 --- a/TOC-best-practices.md +++ b/TOC-best-practices.md @@ -6,31 +6,31 @@ ## 概要 -- [TiDBを使用する](/best-practices/tidb-best-practices.md) +- [TiDBを使用する](/best-practices/tidb-best-practices.md) ## スキーマ設計 -- [DDLを管理する](/best-practices/ddl-introduction.md) -- [UUIDを主キーとして使用する](/best-practices/uuid.md) -- [TiDB パーティションテーブルを使用する](/best-practices/tidb-partitioned-tables-best-practices.md) -- [複数列インデックスの最適化](/best-practices/multi-column-index-best-practices.md) -- [インデックスを管理し、未使用のインデックスを特定する](/best-practices/index-management-best-practices.md) +- [DDLを管理する](/best-practices/ddl-introduction.md) +- [UUIDを主キーとして使用する](/best-practices/uuid.md) +- [TiDB パーティションテーブルを使用する](/best-practices/tidb-partitioned-tables-best-practices.md) +- [複数列インデックスの最適化](/best-practices/multi-column-index-best-practices.md) +- [インデックスを管理し、未使用のインデックスを特定する](/best-practices/index-management-best-practices.md) ## 展開 -- [パブリッククラウドにTiDBをデプロイ](/best-practices/best-practices-on-public-cloud.md) -- [3ノードのハイブリッド展開](/best-practices/three-nodes-hybrid-deployment.md) -- [3つのデータセンター展開におけるローカル読み取り](/best-practices/three-dc-local-read.md) +- [パブリッククラウドにTiDBをデプロイ](/best-practices/best-practices-on-public-cloud.md) +- [3ノードのハイブリッド展開](/best-practices/three-nodes-hybrid-deployment.md) +- [3つのデータセンター展開におけるローカル読み取り](/best-practices/three-dc-local-read.md) ## オペレーション -- [負荷分散にHAProxyを使用する](/best-practices/haproxy-best-practices.md) -- [読み取り専用ストレージノードを使用する](/best-practices/readonly-nodes.md) -- [Grafana を使用して TiDB を監視する](/best-practices/grafana-monitor-best-practices.md) +- [負荷分散にHAProxyを使用する](/best-practices/haproxy-best-practices.md) +- [読み取り専用ストレージノードを使用する](/best-practices/readonly-nodes.md) +- [Grafana を使用して TiDB を監視する](/best-practices/grafana-monitor-best-practices.md) ## 性能チューニング -- [SaaS マルチテナントシナリオで数百万のテーブルを処理](/best-practices/saas-best-practices.md) -- [高同時実行書き込みの処理](/best-practices/high-concurrency-best-practices.md) -- [大規模リージョンで TiKV のパフォーマンスをチューニングする](/best-practices/massive-regions-best-practices.md) -- [PDスケジュールの調整](/best-practices/pd-scheduling-best-practices.md) +- [SaaS マルチテナントシナリオで数百万のテーブルを処理](/best-practices/saas-best-practices.md) +- [高同時実行書き込みの処理](/best-practices/high-concurrency-best-practices.md) +- [大規模リージョンで TiKV のパフォーマンスをチューニングする](/best-practices/massive-regions-best-practices.md) +- [PDスケジュールの調整](/best-practices/pd-scheduling-best-practices.md) diff --git a/accelerated-table-creation.md b/accelerated-table-creation.md index fb8e219ff2cad..701f0b90ca98a 100644 --- a/accelerated-table-creation.md +++ b/accelerated-table-creation.md @@ -13,7 +13,7 @@ TiDB v7.6.0 では、テーブル作成の高速化をサポートするシス ## TiDBツールとの互換性 {#compatibility-with-tidb-tools} -- TiDB v8.3.0より前のバージョンでは、 [TiCDC](https://docs.pingcap.com/tidb/stable/ticdc-overview) `tidb_enable_fast_create_table`によって作成されたテーブルのレプリケーションをサポートしていませんでした。v8.3.0以降では、TiCDCはこれらのテーブルを適切にレプリケーションできます。 +- TiDB v8.3.0より前のバージョンでは、 [TiCDC](https://docs.pingcap.com/tidb/stable/ticdc-overview) `tidb_enable_fast_create_table`によって作成されたテーブルのレプリケーションをサポートしていませんでした。v8.3.0以降では、TiCDCはこれらのテーブルを適切にレプリケーションできます。 ## 制限 {#limitation} diff --git a/ai/concepts/vector-search-overview.md b/ai/concepts/vector-search-overview.md index ca4ff9f2629f9..159b543a31018 100644 --- a/ai/concepts/vector-search-overview.md +++ b/ai/concepts/vector-search-overview.md @@ -10,8 +10,8 @@ aliases: ['/ja/tidb/stable/vector-search-overview/','/ja/tidb/dev/vector-search- > **Note:** > -> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、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以降を推奨）。 +> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、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以降を推奨）。 ## 概念 {#concepts} @@ -49,8 +49,8 @@ TiDBベクトル検索は、 [距離関数](/ai/reference/vector-search-function TiDBは、ベクトル検索機能を統合したリレーショナルデータベースとして、データとその対応するベクトル表現（ベクトル埋め込み）を1つのデータベースにまとめて保存できます。データの保存方法は以下のいずれかの方法を選択できます。 -- データとその対応するベクトル表現を、同じテーブルの異なる列に格納します。 -- データとその対応するベクトル表現を別々のテーブルに格納します。このため、データを取得する際には`JOIN`クエリを使用してテーブルを結合する必要があります。 +- データとその対応するベクトル表現を、同じテーブルの異なる列に格納します。 +- データとその対応するベクトル表現を別々のテーブルに格納します。このため、データを取得する際には`JOIN`クエリを使用してテーブルを結合する必要があります。 ## ユースケース {#use-cases} @@ -70,8 +70,8 @@ TiDBは、ベクトル検索機能を統合したリレーショナルデータ TiDB Vector Searchの利用を開始するには、以下のドキュメントを参照してください。 -- [Pythonを使ったベクトル検索を始めましょう](/ai/quickstart-via-python.md) -- [SQL を使用したベクトル検索を始めましょう](/ai/quickstart-via-sql.md) +- [Pythonを使ったベクトル検索を始めましょう](/ai/quickstart-via-python.md) +- [SQL を使用したベクトル検索を始めましょう](/ai/quickstart-via-sql.md) ## 関連リソース {#related-resources} diff --git a/ai/examples/auto-embedding-with-pytidb.md b/ai/examples/auto-embedding-with-pytidb.md index a1762f0beb137..451d22af84687 100644 --- a/ai/examples/auto-embedding-with-pytidb.md +++ b/ai/examples/auto-embedding-with-pytidb.md @@ -7,17 +7,17 @@ summary: 組み込みの埋め込みモデルを使用して、テキストデ この例では、 [pytidb](https://github.com/pingcap/pytidb)クライアントで[自動埋め込み](/ai/integrations/vector-search-auto-embedding-overview.md)機能を使用する方法を示します。 -1. `pytidb`クライアントを使用してTiDBに接続します。 -2. 自動埋め込み用に構成されたVectorFieldを持つテーブルを定義します。 -3. プレーンテキストデータを挿入してください。埋め込みデータはバックグラウンドで自動的に生成されます。 -4. 自然言語クエリを使用してベクトル検索を実行します。埋め込みベクトルは透過的に生成されます。 +1. `pytidb`クライアントを使用してTiDBに接続します。 +2. 自動埋め込み用に構成されたVectorFieldを持つテーブルを定義します。 +3. プレーンテキストデータを挿入してください。埋め込みデータはバックグラウンドで自動的に生成されます。 +4. 自然言語クエリを使用してベクトル検索を実行します。埋め込みベクトルは透過的に生成されます。 ## 前提条件 {#prerequisites} 始める前に、以下のものを用意してください。 -- **Python (>=3.10)** : [Python](https://www.python.org/downloads/) 3.10以降のバージョンをインストールしてください。 -- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 +- **Python (>=3.10)** : [Python](https://www.python.org/downloads/) 3.10以降のバージョンをインストールしてください。 +- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 ## 実行方法 {#how-to-run} @@ -38,9 +38,9 @@ pip install -r reqs.txt ### ステップ3．環境変数を設定する {#step-3-set-environment-variables} -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Starterインスタンスの名前をクリックして、その概要ページに移動します。 -2. 右上隅の**Connect**をクリックします。接続ダイアログが表示され、接続パラメータが表示されます。 -3. 接続パラメータに応じて環境変数を以下のように設定してください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Starterインスタンスの名前をクリックして、その概要ページに移動します。 +2. 右上隅の**Connect**をクリックします。接続ダイアログが表示され、接続パラメータが表示されます。 +3. 接続パラメータに応じて環境変数を以下のように設定してください。 ```bash cat > .env < .env < .env < **Note** > > 現在、全文検索は以下の製品オプションおよび地域でのみご利用いただけます。 > -> - TiDB Cloud Starter：フランクフルト（ `eu-central-1` ）、シンガポール（ `ap-southeast-1` ） +> - TiDB Cloud Starter：フランクフルト（ `eu-central-1` ）、シンガポール（ `ap-southeast-1` ） ## 実行方法 {#how-to-run} @@ -44,9 +44,9 @@ pip install -r reqs.txt ### ステップ3．環境変数を設定する {#step-3-set-environment-variables} -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Starterインスタンスの名前をクリックして、その概要ページに移動します。 -2. 右上隅の**Connect**をクリックします。接続ダイアログが表示され、接続パラメータが表示されます。 -3. 接続パラメータに応じて環境変数を以下のように設定してください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Starterインスタンスの名前をクリックして、その概要ページに移動します。 +2. 右上隅の**Connect**をクリックします。接続ダイアログが表示され、接続パラメータが表示されます。 +3. 接続パラメータに応じて環境変数を以下のように設定してください。 ```bash cat > .env <PyTiDB画像検索デモ

マルチモーダル埋め込みによるペット画像検索

@@ -18,9 +18,9 @@ summary: テキストから画像への検索と画像から画像への検索 始める前に、以下のものを用意してください。 -- **Python (>=3.10)** : [Python](https://www.python.org/downloads/) 3.10以降のバージョンをインストールしてください。 -- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 -- **Jina AI API キー**: [Jina AI埋め込み](https://jina.ai/embeddings/)から無料の API キーを取得できます。 +- **Python (>=3.10)** : [Python](https://www.python.org/downloads/) 3.10以降のバージョンをインストールしてください。 +- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 +- **Jina AI API キー**: [Jina AI埋め込み](https://jina.ai/embeddings/)から無料の API キーを取得できます。 ## 実行方法 {#how-to-run} @@ -43,9 +43,9 @@ pip install -r reqs.txt ### ステップ3．環境変数を設定する {#step-3-set-environment-variables} -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Starterインスタンスの名前をクリックして、その概要ページに移動します。 -2. 右上隅の**Connect**をクリックします。接続ダイアログが表示され、接続パラメータが表示されます。 -3. 接続パラメータに応じて環境変数を以下のように設定してください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Starterインスタンスの名前をクリックして、その概要ページに移動します。 +2. 右上隅の**Connect**をクリックします。接続ダイアログが表示され、接続パラメータが表示されます。 +3. 接続パラメータに応じて環境変数を以下のように設定してください。 ```bash cat > .env <TiDBを搭載したメモリ付きAIエージェント

TiDBを搭載したメモリ付きAIエージェント

@@ -20,9 +20,9 @@ summary: チャットボットや対話型AIアプリケーション向けに、 始める前に、以下のものを用意してください。 -- **Python (>=3.10)** : [Python](https://www.python.org/downloads/) 3.10以降のバージョンをインストールしてください。 -- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 -- **OpenAI API キー**: [OpenAI](https://platform.openai.com/api-keys)から OpenAI API キーを取得します。 +- **Python (>=3.10)** : [Python](https://www.python.org/downloads/) 3.10以降のバージョンをインストールしてください。 +- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 +- **OpenAI API キー**: [OpenAI](https://platform.openai.com/api-keys)から OpenAI API キーを取得します。 ## 実行方法 {#how-to-run} @@ -45,9 +45,9 @@ pip install -r reqs.txt ### ステップ3．環境変数を設定する {#step-3-set-environment-variables} -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Starterインスタンスの名前をクリックして、その概要ページに移動します。 -2. 右上隅の**Connect**をクリックします。接続ダイアログが表示され、接続パラメータが表示されます。 -3. 接続パラメータに応じて環境変数を以下のように設定してください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Starterインスタンスの名前をクリックして、その概要ページに移動します。 +2. 右上隅の**Connect**をクリックします。接続ダイアログが表示され、接続パラメータが表示されます。 +3. 接続パラメータに応じて環境変数を以下のように設定してください。 ```bash cat > .env < .env < .env <` : キーは、列名、JSON フィールドにアクセスするための JSON パス式 ( [メタデータフィルタリング](/ai/guides/vector-search.md#metadata-filtering)参照)、または[論理演算子](#logical-operators)になります。 -- `` : 演算子は[比較演算子](#compare-operators)または[包含演算子](#inclusion-operators)になります。 -- `` : 値は演算子に応じてスカラー値または配列になります。 +- `` : キーは、列名、JSON フィールドにアクセスするための JSON パス式 ( [メタデータフィルタリング](/ai/guides/vector-search.md#metadata-filtering)参照)、または[論理演算子](#logical-operators)になります。 +- `` : 演算子は[比較演算子](#compare-operators)または[包含演算子](#inclusion-operators)になります。 +- `` : 値は演算子に応じてスカラー値または配列になります。 **例: `created_at`が 2024-01-01 より大きいレコードをフィルタリングする** diff --git a/ai/guides/image-search.md b/ai/guides/image-search.md index 15206d9bbb7f2..bc50f286a4f61 100644 --- a/ai/guides/image-search.md +++ b/ai/guides/image-search.md @@ -106,6 +106,6 @@ results = table.search("orange tabby cat").limit(3).to_list() ## 参照 {#see-also} -- [自動埋め込みガイド](/ai/guides/auto-embedding.md) -- [ベクトル検索ガイド](/ai/concepts/vector-search-overview.md) -- [画像検索の例](/ai/examples/image-search-with-pytidb.md) +- [自動埋め込みガイド](/ai/guides/auto-embedding.md) +- [ベクトル検索ガイド](/ai/concepts/vector-search-overview.md) +- [画像検索の例](/ai/examples/image-search-with-pytidb.md) diff --git a/ai/guides/raw-queries.md b/ai/guides/raw-queries.md index 8b4575a408891..68c4270de17fc 100644 --- a/ai/guides/raw-queries.md +++ b/ai/guides/raw-queries.md @@ -37,11 +37,11 @@ client.execute( `client.query()`メソッドは、いくつかのヘルパー メソッドを含む`SQLQueryResult`インスタンスを返します。 -- `to_pydantic()` -- `to_list()` -- `to_pandas()` -- `to_rows()` -- `scalar()` +- `to_pydantic()` +- `to_list()` +- `to_pandas()` +- `to_rows()` +- `scalar()` #### Pydantic モデルとして {#as-pydantic-model} diff --git a/ai/guides/reranking.md b/ai/guides/reranking.md index 9cf7fa437de3f..dbc7fb7cbea98 100644 --- a/ai/guides/reranking.md +++ b/ai/guides/reranking.md @@ -9,8 +9,8 @@ summary: アプリケーションで再ランキングを使用する方法を 検索プロセスは次の 2 つの段階で行われます。 -1. **初期検索**: ベクトル検索により、コレクションから最も類似性の高い上位`k`ドキュメントが識別されます。 -2. **再ランキング**: 再ランキング モデルは、クエリとドキュメント間の関連性に基づいてこれら`k`ドキュメントを評価し、それらを並べ替えて最終的な上位`n`結果 ( `n` ≤ `k` ) を生成します。 +1. **初期検索**: ベクトル検索により、コレクションから最も類似性の高い上位`k`ドキュメントが識別されます。 +2. **再ランキング**: 再ランキング モデルは、クエリとドキュメント間の関連性に基づいてこれら`k`ドキュメントを評価し、それらを並べ替えて最終的な上位`n`結果 ( `n` ≤ `k` ) を生成します。 この 2 段階の検索アプローチにより、ドキュメントの関連性と精度の両方が大幅に向上します。 @@ -20,7 +20,7 @@ summary: アプリケーションで再ランキングを使用する方法を `pytidb`複数のサードパーティ プロバイダーの再ランキング モデルを使用できる`Reranker`クラスを提供します。 -1. 再ランク付けインスタンスを作成します。 +1. 再ランク付けインスタンスを作成します。 ```python from pytidb.rerankers import Reranker @@ -28,7 +28,7 @@ summary: アプリケーションで再ランキングを使用する方法を reranker = Reranker(model_name="{provider}/{model_name}") ``` -2. `.rerank()`の方法を使用してリランカーを適用します。 +2. `.rerank()`の方法を使用してリランカーを適用します。 ```python table.search("{query}").rerank(reranker, "{field_to_rerank}").limit(3) diff --git a/ai/guides/tables.md b/ai/guides/tables.md index 1951475a48d37..bda83b047272f 100644 --- a/ai/guides/tables.md +++ b/ai/guides/tables.md @@ -25,10 +25,10 @@ TiDBは、関連するデータのコレクションを整理して保存する 次の例では、次の列を持つ`items`という名前のテーブルを作成します。 -- `id` : 整数型の主キー列 -- `content` : テキスト型の列 -- `embedding` : 3次元のベクトル型列 -- `meta` : JSON型の列 +- `id` : 整数型の主キー列 +- `content` : テキスト型の列 +- `embedding` : 3次元のベクトル型列 +- `meta` : JSON型の列
@@ -52,11 +52,11 @@ table = client.create_table(schema=Item, if_exists="overwrite") `create_table`メソッドは次のパラメータを受け入れます。 -- `schema` : テーブル構造を定義する`TableModel`のクラス。 -- `if_exists` : テーブル作成モード。 - - `raise` (デフォルト): テーブルが存在しない場合は作成し、既に存在する場合はエラーを発生させます。 - - `skip` : テーブルが存在しない場合は作成し、既に存在する場合は何も行いません。 - - `overwrite` : 既存のテーブルを削除し、新しいテーブルを作成します。これは**テストや開発**には便利ですが、本番環境では推奨されません。 +- `schema` : テーブル構造を定義する`TableModel`のクラス。 +- `if_exists` : テーブル作成モード。 + - `raise` (デフォルト): テーブルが存在しない場合は作成し、既に存在する場合はエラーを発生させます。 + - `skip` : テーブルが存在しない場合は作成し、既に存在する場合は何も行いません。 + - `overwrite` : 既存のテーブルを削除し、新しいテーブルを作成します。これは**テストや開発**には便利ですが、本番環境では推奨されません。 テーブルが作成されると、 `table`オブジェクトを使用してデータの挿入、更新、削除、クエリを実行できます。 diff --git a/ai/guides/transactions.md b/ai/guides/transactions.md index b1a6b52a52b34..a08284d32504e 100644 --- a/ai/guides/transactions.md +++ b/ai/guides/transactions.md @@ -26,5 +26,5 @@ with client.session() as session: ## 参照 {#see-also} -- [TiDB 開発者ガイド - トランザクション](/develop/dev-guide-transaction-overview.md) -- [TiDB ドキュメント - SQL リファレンス - トランザクション](/transaction-overview.md) +- [TiDB 開発者ガイド - トランザクション](/develop/dev-guide-transaction-overview.md) +- [TiDB ドキュメント - SQL リファレンス - トランザクション](/transaction-overview.md) diff --git a/ai/guides/vector-search-full-text-search-python.md b/ai/guides/vector-search-full-text-search-python.md index d715c344f2872..b6e26a517d7e9 100644 --- a/ai/guides/vector-search-full-text-search-python.md +++ b/ai/guides/vector-search-full-text-search-python.md @@ -10,13 +10,13 @@ aliases: ['/ja/tidb/stable/vector-search-full-text-search-python/','/ja/tidbclou TiDBの全文検索機能は、以下の機能を提供します。 -- **テキストデータを直接クエリする**：埋め込み処理を行わずに、任意の文字列列を直接検索できます。 +- **テキストデータを直接クエリする**：埋め込み処理を行わずに、任意の文字列列を直接検索できます。 -- **多言語対応**：高品質な検索のために言語を指定する必要はありません。TiDBは、同じテーブルに保存された複数の言語のドキュメントをサポートし、各ドキュメントに最適なテキストアナラ​​イザーを自動的に選択します。 +- **多言語対応**：高品質な検索のために言語を指定する必要はありません。TiDBは、同じテーブルに保存された複数の言語のドキュメントをサポートし、各ドキュメントに最適なテキストアナラ​​イザーを自動的に選択します。 -- **関連性順に並べる**: 広く採用されている[BM25ランキング](https://en.wikipedia.org/wiki/Okapi_BM25)アルゴリズムを使用して、検索結果を関連性順に並べ替えることができます。 +- **関連性順に並べる**: 広く採用されている[BM25ランキング](https://en.wikipedia.org/wiki/Okapi_BM25)アルゴリズムを使用して、検索結果を関連性順に並べ替えることができます。 -- **SQLとの完全な互換性**：事前フィルタリング、事後フィルタリング、グループ化、結合など、すべてのSQL機能を全文検索で使用できます。 +- **SQLとの完全な互換性**：事前フィルタリング、事後フィルタリング、グループ化、結合など、すべてのSQL機能を全文検索で使用できます。 > **Tip:** > @@ -28,7 +28,7 @@ TiDBの全文検索機能は、以下の機能を提供します。 全文検索機能はまだ開発初期段階にあり、より多くのお客様に順次展開していく予定です。現在、全文検索機能は、以下のリージョンにおけるTiDB Cloud Starterでのみご利用いただけます。 -- AWS: `Oregon (us-west-2)` 、 `N. Virginia (us-east-1)` 、 `Tokyo (ap-northeast-1)` 、 `Frankfurt (eu-central-1)` 、および`Singapore (ap-southeast-1)` +- AWS: `Oregon (us-west-2)` 、 `N. Virginia (us-east-1)` 、 `Tokyo (ap-northeast-1)` 、 `Frankfurt (eu-central-1)` 、および`Singapore (ap-southeast-1)` このチュートリアルを完了するには、サポートされているリージョンにTiDB Cloud Starterインスタンスがあることを確認してください。お持ちでない場合は、 [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 @@ -66,9 +66,9 @@ db = TiDBClient.connect( これらの接続パラメータは、次のように[TiDB Cloudコンソール](https://tidbcloud.com)から取得できます。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックします。接続ダイアログが表示され、接続パラメータが表示されます。 +2. 右上隅の**Connect**をクリックします。接続ダイアログが表示され、接続パラメータが表示されます。 例えば、接続パラメータが以下のように表示される場合： @@ -99,9 +99,9 @@ db = TiDBClient.connect( 例として、 `chunks`という名前のテーブルを作成し、以下の列を追加します。 -- `id` (int): チャンクのID。 -- `text` (テキスト): チャンクのテキストコンテンツ。 -- `user_id` (int): チャンクを作成したユーザーのID。 +- `id` (int): チャンクのID。 +- `text` (テキスト): チャンクのテキストコンテンツ。 +- `user_id` (int): チャンクを作成したユーザーのID。 ```python from pytidb.schema import TableModel, Field @@ -151,13 +151,13 @@ df = ( ## 関連項目 {#see-also} -- [pytidb Python SDK ドキュメント](https://github.com/pingcap/pytidb) +- [pytidb Python SDK ドキュメント](https://github.com/pingcap/pytidb) -- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) +- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) ## フィードバックとヘルプ {#feedback-x26-help} 全文検索はまだ開発初期段階であり、利用できる地域が限られています。まだ利用できない地域で全文検索を試してみたい場合、またはご意見やご質問がある場合は、お気軽にお問い合わせください。 -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) diff --git a/ai/guides/vector-search-full-text-search-sql.md b/ai/guides/vector-search-full-text-search-sql.md index ec07686543e1f..a249bcf48d51b 100644 --- a/ai/guides/vector-search-full-text-search-sql.md +++ b/ai/guides/vector-search-full-text-search-sql.md @@ -10,13 +10,13 @@ aliases: ['/ja/tidb/stable/vector-search-full-text-search-sql/','/ja/tidbcloud/v TiDBの全文検索機能は、以下の機能を提供します。 -- **テキストデータを直接クエリする**：埋め込み処理を行わずに、任意の文字列列を直接検索できます。 +- **テキストデータを直接クエリする**：埋め込み処理を行わずに、任意の文字列列を直接検索できます。 -- **多言語対応**：高品質な検索のために言語を指定する必要はありません。TiDBのテキストアナラ​​イザーは、同一テーブル内に複数の言語で記述された文書が混在する場合でも対応し、各文書に最適なアナライザーを自動的に選択します。 +- **多言語対応**：高品質な検索のために言語を指定する必要はありません。TiDBのテキストアナラ​​イザーは、同一テーブル内に複数の言語で記述された文書が混在する場合でも対応し、各文書に最適なアナライザーを自動的に選択します。 -- **関連性順に並べる**: 広く採用されている[BM25ランキング](https://en.wikipedia.org/wiki/Okapi_BM25)アルゴリズムを使用して、検索結果を関連性順に並べ替えることができます。 +- **関連性順に並べる**: 広く採用されている[BM25ランキング](https://en.wikipedia.org/wiki/Okapi_BM25)アルゴリズムを使用して、検索結果を関連性順に並べ替えることができます。 -- **SQLとの完全な互換性**：事前フィルタリング、事後フィルタリング、グループ化、結合など、すべてのSQL機能を全文検索で使用できます。 +- **SQLとの完全な互換性**：事前フィルタリング、事後フィルタリング、グループ化、結合など、すべてのSQL機能を全文検索で使用できます。 > **Tip:** > @@ -28,17 +28,17 @@ TiDBの全文検索機能は、以下の機能を提供します。 全文検索機能はまだ開発初期段階にあり、より多くのお客様に順次展開していく予定です。現在、全文検索機能は、以下のリージョンにおけるTiDB Cloud Starterでのみご利用いただけます。 -- AWS: `Oregon (us-west-2)` 、 `N. Virginia (us-east-1)` 、 `Tokyo (ap-northeast-1)` 、 `Frankfurt (eu-central-1)` 、および`Singapore (ap-southeast-1)` +- AWS: `Oregon (us-west-2)` 、 `N. Virginia (us-east-1)` 、 `Tokyo (ap-northeast-1)` 、 `Frankfurt (eu-central-1)` 、および`Singapore (ap-southeast-1)` 全文検索を使用する前に、 TiDB Cloud Starterインスタンスがサポートされているリージョンで作成されていることを確認してください。お持ちでない場合は、 [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 全文検索を実行するには、以下の手順に従ってください。 -1. [**全文索引を作成する**](#create-a-full-text-index): フルテキスト インデックスを持つテーブルを作成するか、既存のテーブルにフルテキスト インデックスを追加します。 +1. [**全文索引を作成する**](#create-a-full-text-index): フルテキスト インデックスを持つテーブルを作成するか、既存のテーブルにフルテキスト インデックスを追加します。 -2. テキストデータ[**テキストデータを挿入する**](#insert-text-data): テーブルにテキストデータを挿入します。 +2. テキストデータ[**テキストデータを挿入する**](#insert-text-data): テーブルにテキストデータを挿入します。 -3. [**全文検索を実行する**](#perform-a-full-text-search): テキストクエリと全文検索関数を使用して全文検索を実行します。 +3. [**全文検索を実行する**](#perform-a-full-text-search): テキストクエリと全文検索関数を使用して全文検索を実行します。 ### 全文索引を作成する {#create-a-full-text-index} @@ -70,9 +70,9 @@ ALTER TABLE stock_items ADD FULLTEXT INDEX (title) WITH PARSER MULTILINGUAL ADD_ `WITH PARSER `句では、以下のパーサーが受け入れられます。 -- `STANDARD` : 高速で、英語コンテンツに対応し、スペースと句読点によって単語を分割します。インデックス作成と検索では、すべてのテキストが小文字化されます（大文字と小文字を区別しないマッチング）。 +- `STANDARD` : 高速で、英語コンテンツに対応し、スペースと句読点によって単語を分割します。インデックス作成と検索では、すべてのテキストが小文字化されます（大文字と小文字を区別しないマッチング）。 -- `MULTILINGUAL` : 英語、中国語、日本語、韓国語など、複数の言語をサポートしています。 +- `MULTILINGUAL` : 英語、中国語、日本語、韓国語など、複数の言語をサポートしています。 ### 全文インデックスを管理する {#manage-full-text-indexes} @@ -315,11 +315,11 @@ WHERE t.author_id IN ## 関連項目 {#see-also} -- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) +- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) ## フィードバックとヘルプ {#feedback-x26-help} 全文検索はまだ開発初期段階であり、利用できる地域が限られています。まだ利用できない地域で全文検索を試してみたい場合、またはご意見やご質問がある場合は、お気軽にお問い合わせください。 -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) diff --git a/ai/guides/vector-search-hybrid-search.md b/ai/guides/vector-search-hybrid-search.md index 27c8632c83cc3..3e2741dc31cf9 100644 --- a/ai/guides/vector-search-hybrid-search.md +++ b/ai/guides/vector-search-hybrid-search.md @@ -10,8 +10,8 @@ aliases: ['/ja/tidb/stable/vector-search-hybrid-search/','/ja/tidbcloud/vector-s TiDBにおけるハイブリッド検索の一般的なワークフローは以下のとおりです。 -1. **全文検索**と**ベクトル検索**にはTiDBを使用してください。 -2. 両方の検索結果を統合するには、**リランカーを**使用してください。 +1. **全文検索**と**ベクトル検索**にはTiDBを使用してください。 +2. 両方の検索結果を統合するには、**リランカーを**使用してください。 ![Hybrid Search](/media/vector-search/hybrid-search-overview.svg) @@ -21,7 +21,7 @@ TiDBにおけるハイブリッド検索の一般的なワークフローは以 全文検索機能はまだ開発初期段階にあり、より多くのお客様に順次展開していく予定です。現在、全文検索機能は、以下のリージョンにおけるTiDB Cloud Starterでのみご利用いただけます。 -- AWS: `Oregon (us-west-2)` 、 `N. Virginia (us-east-1)` 、 `Tokyo (ap-northeast-1)` 、 `Frankfurt (eu-central-1)` 、および`Singapore (ap-southeast-1)` +- AWS: `Oregon (us-west-2)` 、 `N. Virginia (us-east-1)` 、 `Tokyo (ap-northeast-1)` 、 `Frankfurt (eu-central-1)` 、および`Singapore (ap-southeast-1)` このチュートリアルを完了するには、サポートされているリージョンにTiDB Cloud Starterインスタンスがあることを確認してください。お持ちでない場合は、 [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 @@ -55,9 +55,9 @@ db = TiDBClient.connect( これらの接続パラメータは、次のように[TiDB Cloudコンソール](https://tidbcloud.com)から取得できます。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックします。接続ダイアログが表示され、接続パラメータが表示されます。 +2. 右上隅の**Connect**をクリックします。接続ダイアログが表示され、接続パラメータが表示されます。 例えば、接続パラメータが以下のように表示される場合： @@ -88,10 +88,10 @@ db = TiDBClient.connect( 例として、 `chunks`という名前のテーブルを作成し、以下の列を追加します。 -- `id` (int): チャンクのID。 -- `text` (テキスト): チャンクのテキストコンテンツ。 -- `text_vec` (ベクトル): テキストのベクトル表現。pytidb の埋め込みモデルによって自動的に生成されます。 -- `user_id` (int): チャンクを作成したユーザーのID。 +- `id` (int): チャンクのID。 +- `text` (テキスト): チャンクのテキストコンテンツ。 +- `text_vec` (ベクトル): テキストのベクトル表現。pytidb の埋め込みモデルによって自動的に生成されます。 +- `user_id` (int): チャンクを作成したユーザーのID。 ```python from pytidb.schema import TableModel, Field @@ -149,8 +149,8 @@ df = ( `pytidb` 2 つの融合方法をサポートしています。 -- `rrf` : 相互ランク融合 (デフォルト) -- `weighted` : 加重スコア融合 +- `rrf` : 相互ランク融合 (デフォルト) +- `weighted` : 加重スコア融合 ハイブリッド検索結果を最適化するために、ご自身のユースケースに最適な融合方法を選択できます。 @@ -175,7 +175,7 @@ results = ( パラメータ: -- `k` : ゼロ除算を防ぎ、高ランクのドキュメントの影響を制御するための定数 (デフォルト: 60)。 +- `k` : ゼロ除算を防ぎ、高ランクのドキュメントの影響を制御するための定数 (デフォルト: 60)。 ### 加重スコア融合 {#weighted-score-fusion} @@ -202,8 +202,8 @@ results = ( パラメータ: -- `vs_weight` : ベクトル検索スコアの重み。 -- `fts_weight` : 全文検索スコアの重み。 +- `vs_weight` : ベクトル検索スコアの重み。 +- `fts_weight` : 全文検索スコアの重み。 ## 再ランク法 {#rerank-method} @@ -235,13 +235,13 @@ results = ( ## 関連項目 {#see-also} -- [pytidb Python SDK ドキュメント](https://github.com/pingcap/pytidb) +- [pytidb Python SDK ドキュメント](https://github.com/pingcap/pytidb) -- [Pythonによる全文検索](/ai/guides/vector-search-full-text-search-python.md) +- [Pythonによる全文検索](/ai/guides/vector-search-full-text-search-python.md) ## フィードバックとヘルプ {#feedback-x26-help} 全文検索はまだ開発初期段階であり、利用できる地域が限られています。まだ利用できない地域で全文検索を試してみたい場合、またはご意見やご質問がある場合は、お気軽にお問い合わせください。 -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) diff --git a/ai/guides/vector-search.md b/ai/guides/vector-search.md index 8e455c6ce4130..f63a9eda76fca 100644 --- a/ai/guides/vector-search.md +++ b/ai/guides/vector-search.md @@ -24,10 +24,10 @@ summary: アプリケーションでベクトル検索を使用する方法を 次の例では、4 つの列を持つ`documents`テーブルを作成します。 -- `id` : テーブルの主キー。 -- `text` : ドキュメントのテキストコンテンツ。 -- `text_vec` : テキスト コンテンツのベクトル埋め込み。 -- `meta` : ドキュメントのメタデータ (JSON オブジェクト)。 +- `id` : テーブルの主キー。 +- `text` : ドキュメントのテキストコンテンツ。 +- `text_vec` : テキスト コンテンツのベクトル埋め込み。 +- `meta` : ドキュメントのメタデータ (JSON オブジェクト)。 ```python hl_lines="9" from pytidb.schema import TableModel, Field, VectorField @@ -46,11 +46,11 @@ table = client.create_table(schema=Document, if_exists="overwrite") `VectorField`クラスは次のパラメータを受け入れます。 -- `dimensions` : ベクトルの次元。指定すると、このフィールドには指定した次元のベクトルのみが格納されます。 -- `index` : ベクトルフィールドに[ベクトルインデックス](https://docs.pingcap.com/tidbcloud/vector-search-index/)を作成するかどうか。デフォルトは`True`です。 -- `distance_metric` : ベクトルインデックスに使用する距離メトリック。サポートされる値: - - `DistanceMetric.COSINE` （デフォルト）: コサイン距離メトリック。テキストの類似性を測定するのに適しています。 - - `DistanceMetric.L2` : L2距離メトリック、全体的な差異を捉えるのに適しています +- `dimensions` : ベクトルの次元。指定すると、このフィールドには指定した次元のベクトルのみが格納されます。 +- `index` : ベクトルフィールドに[ベクトルインデックス](https://docs.pingcap.com/tidbcloud/vector-search-index/)を作成するかどうか。デフォルトは`True`です。 +- `distance_metric` : ベクトルインデックスに使用する距離メトリック。サポートされる値: + - `DistanceMetric.COSINE` （デフォルト）: コサイン距離メトリック。テキストの類似性を測定するのに適しています。 + - `DistanceMetric.L2` : L2距離メトリック、全体的な差異を捉えるのに適しています
@@ -68,13 +68,13 @@ CREATE TABLE documents ( この例では、 -- `text_vec`列は`VECTOR(3)`として定義されているため、この列に格納されるベクトルは 3 次元である必要があります。 -- ベクトル検索のパフォーマンスを最適化するために、 `VEC_COSINE_DISTANCE`関数を使用してベクトル インデックスが作成されます。 +- `text_vec`列は`VECTOR(3)`として定義されているため、この列に格納されるベクトルは 3 次元である必要があります。 +- ベクトル検索のパフォーマンスを最適化するために、 `VEC_COSINE_DISTANCE`関数を使用してベクトル インデックスが作成されます。 TiDB はベクトル インデックスに対して 2 つの距離関数をサポートしています。 -- `VEC_COSINE_DISTANCE` : 2つのベクトル間のコサイン距離を計算する -- `VEC_L2_DISTANCE` : 2つのベクトル間のL2距離（ユークリッド距離）を計算する +- `VEC_COSINE_DISTANCE` : 2つのベクトル間のコサイン距離を計算する +- `VEC_L2_DISTANCE` : 2つのベクトル間のL2距離（ユークリッド距離）を計算する
@@ -85,9 +85,9 @@ TiDB はベクトル インデックスに対して 2 つの距離関数をサ 次の例では、それぞれ単純な 3 次元ベクトル埋め込みを持つ 3 つのドキュメントを挿入します。 -- `dog`ベクトル埋め込み`[1, 2, 1]` -- `fish`ベクトル埋め込み`[1, 2, 4]` -- `tree`ベクトル埋め込み`[1, 0, 0]` +- `dog`ベクトル埋め込み`[1, 2, 1]` +- `fish`ベクトル埋め込み`[1, 2, 4]` +- `tree`ベクトル埋め込み`[1, 0, 0]`
@@ -295,8 +295,8 @@ TiDB でのベクトル検索では、スカラー フィールド (整数や文 通常、メタデータ フィルタリングと組み合わせたベクトル検索には、次の 2 つのモードがあります。 -- **後フィルタリング**：TiDBはまずベクトル検索を実行し、ベクトル空間全体から上位k個の候補を取得し、その候補セットにフィルターを適用します。ベクトル検索段階では、効率性を高めるため、通常、ベクトルインデックスが使用されます。 -- **事前フィルタリング**：TiDBはベクトル検索の前にフィルタを適用します。フィルタの選択性が高く、フィルタリング対象フィールドにスカラーインデックスがある場合、このモードにより検索空間が縮小され、パフォーマンスが向上します。 +- **後フィルタリング**：TiDBはまずベクトル検索を実行し、ベクトル空間全体から上位k個の候補を取得し、その候補セットにフィルターを適用します。ベクトル検索段階では、効率性を高めるため、通常、ベクトルインデックスが使用されます。 +- **事前フィルタリング**：TiDBはベクトル検索の前にフィルタを適用します。フィルタの選択性が高く、フィルタリング対象フィールドにスカラーインデックスがある場合、このモードにより検索空間が縮小され、パフォーマンスが向上します。 ### 後フィルタリング {#post-filtering} @@ -340,8 +340,8 @@ SELECT * FROM ORDER BY () LIMIT ベクトル検索と追加のフィルタリング条件を組み合わせる必要がある場合は、ポストフィルタリングパターンを使用できます。このアプローチでは、ANNクエリは2つの部分に分割されます。 -- 内部クエリは、ベクトル インデックスを使用してベクトル検索を実行します。 -- 外側のクエリは`WHERE`条件を適用して結果をフィルタリングします。 +- 内部クエリは、ベクトル インデックスを使用してベクトル検索を実行します。 +- 外側のクエリは`WHERE`条件を適用して結果をフィルタリングします。 ```sql hl_lines="8" SELECT * diff --git a/ai/integrations/embedding-openai-compatible.md b/ai/integrations/embedding-openai-compatible.md index 58ad5ecb6d23a..973c7ef7f04df 100644 --- a/ai/integrations/embedding-openai-compatible.md +++ b/ai/integrations/embedding-openai-compatible.md @@ -15,8 +15,8 @@ summary: TiDB Vector SearchをOpenAI互換の埋め込みモデルと統合し OpenAI Embedding APIは広く利用されているため、多くのプロバイダーが以下のような互換性のあるAPIを提供しています。 -- [Ollama](https://ollama.com/) -- [vLLM](https://vllm.ai/) +- [Ollama](https://ollama.com/) +- [vLLM](https://vllm.ai/) TiDB Python SDK [pytidb](https://github.com/pingcap/pytidb) 、OpenAI 互換の埋め込みサービスと統合するための`EmbeddingFunction`クラスを提供します。 @@ -55,9 +55,9 @@ openai_like_embed = EmbeddingFunction( パラメータは以下のとおりです。 -- `model_name` : 使用するモデルを指定します。 `openai/{model_name}`の形式を使用してください。 -- `api_base` : OpenAI互換の埋め込みAPIサービスのベースURL。 -- `api_key` : 埋め込みAPIサービスで認証するために使用されるAPIキー。 +- `model_name` : 使用するモデルを指定します。 `openai/{model_name}`の形式を使用してください。 +- `api_base` : OpenAI互換の埋め込みAPIサービスのベースURL。 +- `api_key` : 埋め込みAPIサービスで認証するために使用されるAPIキー。 **例：Ollamaを`nomic-embed-text`モデルで使用する** diff --git a/ai/integrations/tidb-mcp-claude-code.md b/ai/integrations/tidb-mcp-claude-code.md index 826996ec3c4c4..1d40ffe0d549c 100644 --- a/ai/integrations/tidb-mcp-claude-code.md +++ b/ai/integrations/tidb-mcp-claude-code.md @@ -11,27 +11,27 @@ summary: このガイドでは、Claude CodeでTiDB MCPサーバーを設定す 始める前に、以下のものを用意してください。 -- **Claude Code** ： [claude.com](https://claude.com/product/claude-code)からインストールしてください。 -- **Python (>=3.10) と uv** : Python (3.10 以降) と`uv`がインストールされていることを確認します。 [インストールガイド](https://docs.astral.sh/uv/getting-started/installation/)に従って`uv`をインストールします。 -- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 +- **Claude Code** ： [claude.com](https://claude.com/product/claude-code)からインストールしてください。 +- **Python (>=3.10) と uv** : Python (3.10 以降) と`uv`がインストールされていることを確認します。 [インストールガイド](https://docs.astral.sh/uv/getting-started/installation/)に従って`uv`をインストールします。 +- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 ## TiDB Cloud Starterに接続する（推奨） {#connect-to-tidb-cloud-starter-recommended} TiDB Cloudコンソールを使用して、すぐに実行できるClaude Codeコマンドを生成します。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックして概要ページに移動し、右上隅の**Use with AI Tools**をクリックします。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックして概要ページに移動し、右上隅の**Use with AI Tools**をクリックします。 -2. 表示されたダイアログで、Claude Codeがアクセスする**Branch**と**Database**を選択してください。 +2. 表示されたダイアログで、Claude Codeがアクセスする**Branch**と**Database**を選択してください。 -3. ダイアログに表示される**Prerequisites**リストを確認し、不足している依存関係があればインストールしてください。 +3. ダイアログに表示される**Prerequisites**リストを確認し、不足している依存関係があればインストールしてください。 -4. ルートパスワードを設定します。 +4. ルートパスワードを設定します。 - - まだパスワードを設定していない場合は、**Generate Password**をクリックして、生成されたパスワードを安全な場所に保存してください（パスワードは一度しか表示されません）。 - - パスワードが既に存在する場合は、 **Enter the password for easy setup**欄に入力してください。 - - パスワードを忘れた場合は、 **Prerequisites**セクションの**Reset password**をクリックして新しいパスワードを生成してください。 + - まだパスワードを設定していない場合は、**Generate Password**をクリックして、生成されたパスワードを安全な場所に保存してください（パスワードは一度しか表示されません）。 + - パスワードが既に存在する場合は、 **Enter the password for easy setup**欄に入力してください。 + - パスワードを忘れた場合は、 **Prerequisites**セクションの**Reset password**をクリックして新しいパスワードを生成してください。 -5. **Claude Code**タブを選択し、セットアップコマンドをコピーして、ターミナルで実行してください。 +5. **Claude Code**タブを選択し、セットアップコマンドをコピーして、ターミナルで実行してください。 ## 手動設定（任意のTiDBクラスタ） {#manual-configuration-any-tidb-cluster} @@ -74,4 +74,4 @@ claude mcp add --transport stdio TiDB \ ## 関連項目 {#see-also} -- [TiDB MCPサーバー](/ai/integrations/tidb-mcp-server.md) +- [TiDB MCPサーバー](/ai/integrations/tidb-mcp-server.md) diff --git a/ai/integrations/tidb-mcp-claude-desktop.md b/ai/integrations/tidb-mcp-claude-desktop.md index 7b64e04aa55c5..0d1362eb89c0e 100644 --- a/ai/integrations/tidb-mcp-claude-desktop.md +++ b/ai/integrations/tidb-mcp-claude-desktop.md @@ -11,21 +11,21 @@ summary: このガイドでは、Claude DesktopでTiDB MCPサーバーを設定 始める前に、以下のものを用意してください。 -- **Claude Desktop** :[Claude AI](https://claude.ai/download)から Claude Desktop をダウンロードしてインストールします。 -- **Python (>=3.10) と uv** : Python (3.10 以降) と`uv`がインストールされていることを確認します。 [インストールガイド](https://docs.astral.sh/uv/getting-started/installation/)に従って`uv`をインストールします。 -- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 +- **Claude Desktop** :[Claude AI](https://claude.ai/download)から Claude Desktop をダウンロードしてインストールします。 +- **Python (>=3.10) と uv** : Python (3.10 以降) と`uv`がインストールされていることを確認します。 [インストールガイド](https://docs.astral.sh/uv/getting-started/installation/)に従って`uv`をインストールします。 +- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 ## セットアップ手順 {#setup-steps} Claude DesktopでTiDB MCPサーバーを設定するには、以下の手順に従ってください。 -1. **Settings**ダイアログを開きます。 +1. **Settings**ダイアログを開きます。 -2. ダイアログの**Developers**タブをクリックします。 +2. ダイアログの**Developers**タブをクリックします。 -3. **Edit Config**ボタンをクリックして、MCP設定ファイル`claude_desktop_config.json`を開きます。 +3. **Edit Config**ボタンをクリックして、MCP設定ファイル`claude_desktop_config.json`を開きます。 -4. 以下の設定を`claude_desktop_config.json`ファイルにコピーしてください。 +4. 以下の設定を`claude_desktop_config.json`ファイルにコピーしてください。 ```json { @@ -44,10 +44,10 @@ Claude DesktopでTiDB MCPサーバーを設定するには、以下の手順に } ``` -5. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックすると、その概要ページに移動します。 +5. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックすると、その概要ページに移動します。 -6. 右上隅の**Connect**をクリックして接続パラメータを取得し、 `TIDB_HOST` 、 `TIDB_PORT` 、 `TIDB_USERNAME` 、 `TIDB_PASSWORD` 、および`TIDB_DATABASE`の値を自分の値に置き換えてください。 +6. 右上隅の**Connect**をクリックして接続パラメータを取得し、 `TIDB_HOST` 、 `TIDB_PORT` 、 `TIDB_USERNAME` 、 `TIDB_PASSWORD` 、および`TIDB_DATABASE`の値を自分の値に置き換えてください。 -7. Claude Desktopを再起動してください。 +7. Claude Desktopを再起動してください。 詳細については、 [Claude DesktopでMCPサーバーを設定する方法](https://modelcontextprotocol.io/quickstart/user)を参照してください。 diff --git a/ai/integrations/tidb-mcp-cursor.md b/ai/integrations/tidb-mcp-cursor.md index 101da4b5d7cf5..968aa0dea2724 100644 --- a/ai/integrations/tidb-mcp-cursor.md +++ b/ai/integrations/tidb-mcp-cursor.md @@ -15,27 +15,27 @@ summary: このガイドでは、CursorエディタでTiDB MCPサーバーを設 始める前に、以下のものを用意してください。 -- **Cursor** ： [cursor.com](https://cursor.com)からCursorをダウンロードしてインストールしてください。 -- **Python (>=3.10) と uv** : Python (3.10 以降) と`uv`がインストールされていることを確認します。 [インストールガイド](https://docs.astral.sh/uv/getting-started/installation/)に従って`uv`をインストールします。 -- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 +- **Cursor** ： [cursor.com](https://cursor.com)からCursorをダウンロードしてインストールしてください。 +- **Python (>=3.10) と uv** : Python (3.10 以降) と`uv`がインストールされていることを確認します。 [インストールガイド](https://docs.astral.sh/uv/getting-started/installation/)に従って`uv`をインストールします。 +- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 ## TiDB Cloud Starterに接続する（推奨） {#connect-to-tidb-cloud-starter-recommended} TiDB Cloudコンソールを使用して、 TiDB Cloud Starterインスタンスの認証情報でCursor構成を作成します。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックして概要ページに移動し、右上隅の**Use with AI Tools**をクリックします。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックして概要ページに移動し、右上隅の**Use with AI Tools**をクリックします。 -2. 表示されたダイアログで、Cursorがアクセスする**Branch**と**Database**を選択します。 +2. 表示されたダイアログで、Cursorがアクセスする**Branch**と**Database**を選択します。 -3. ダイアログに表示される**Prerequisites**リストを確認し、不足している依存関係があればインストールしてください。 +3. ダイアログに表示される**Prerequisites**リストを確認し、不足している依存関係があればインストールしてください。 -4. ルートパスワードを設定します。 +4. ルートパスワードを設定します。 - - まだパスワードを設定していない場合は、**Generate Password**をクリックして、生成されたパスワードを安全な場所に保存してください（パスワードは一度しか表示されません）。 - - パスワードが既に存在する場合は、 **Enter the password for easy setup**欄に入力してください。 - - パスワードを忘れた場合は、 **Prerequisites**セクションの**Reset password**をクリックして新しいパスワードを生成してください。 + - まだパスワードを設定していない場合は、**Generate Password**をクリックして、生成されたパスワードを安全な場所に保存してください（パスワードは一度しか表示されません）。 + - パスワードが既に存在する場合は、 **Enter the password for easy setup**欄に入力してください。 + - パスワードを忘れた場合は、 **Prerequisites**セクションの**Reset password**をクリックして新しいパスワードを生成してください。 -5. **Cursor**タブを選択し、 **Add to Cursor**をクリックしてから、Cursorで**Install**をクリックします。 +5. **Cursor**タブを選択し、 **Add to Cursor**をクリックしてから、Cursorで**Install**をクリックします。 ## 手動設定（任意のTiDBクラスタ） {#manual-configuration-any-tidb-cluster} @@ -64,6 +64,6 @@ TiDB Cloudコンソールを使用して、 TiDB Cloud Starterインスタンス TiDB MCPサーバーのインストールで問題が発生した場合は、CursorのMCPログを確認してください。 -1. エディタ上部のメインメニューで、 **[ビュー]** > **[出力]**をクリックします。 -2. **出力**パネルのドロップダウンメニューから**MCP**を選択してください。 -3. `[error] Could not start MCP server tidb-mcp-server: Error: spawn uvx ENOENT`のようなエラーが表示される場合は、 `uvx`コマンドがシステム環境変数`$PATH`に存在しない可能性があります。macOS ユーザーの場合は、 `uvx`を実行して`brew install uv` 。 +1. エディタ上部のメインメニューで、 **[ビュー]** > **[出力]**をクリックします。 +2. **出力**パネルのドロップダウンメニューから**MCP**を選択してください。 +3. `[error] Could not start MCP server tidb-mcp-server: Error: spawn uvx ENOENT`のようなエラーが表示される場合は、 `uvx`コマンドがシステム環境変数`$PATH`に存在しない可能性があります。macOS ユーザーの場合は、 `uvx`を実行して`brew install uv` 。 diff --git a/ai/integrations/tidb-mcp-server.md b/ai/integrations/tidb-mcp-server.md index afd4b7602ad37..1337d515d9630 100644 --- a/ai/integrations/tidb-mcp-server.md +++ b/ai/integrations/tidb-mcp-server.md @@ -13,11 +13,11 @@ TiDB MCP Serverは、自然言語による指示を用いてTiDBデータベー MCPはクライアント/サーバーアーキテクチャを採用しており、ホストアプリケーションが複数の外部サーバーに接続できるようになっている。 -- **ホスト**：Claude DesktopやCursorなどのIDEといった、MCPサーバーへの接続を開始するAI搭載アプリケーション。 +- **ホスト**：Claude DesktopやCursorなどのIDEといった、MCPサーバーへの接続を開始するAI搭載アプリケーション。 -- **クライアント**：ホストアプリケーションに組み込まれたコンポーネントで、個々のMCPサーバーと1対1の接続を確立する。 +- **クライアント**：ホストアプリケーションに組み込まれたコンポーネントで、個々のMCPサーバーと1対1の接続を確立する。 -- **サーバー**： **TiDB MCPサーバー**などの外部サービスで、クライアントが外部システムとやり取りするためのツール、コンテキスト、およびプロンプトを提供します。 +- **サーバー**： **TiDB MCPサーバー**などの外部サービスで、クライアントが外部システムとやり取りするためのツール、コンテキスト、およびプロンプトを提供します。 **TiDB MCPサーバーは**、MCP互換サーバーであり、MCPクライアントがTiDBデータベースとやり取りするためのツールとコンテキストを提供します。 @@ -25,16 +25,16 @@ MCPはクライアント/サーバーアーキテクチャを採用しており 始める前に、以下のものを用意してください。 -- **MCP 互換クライアント**: 例:[Cursor](/ai/integrations/tidb-mcp-cursor.md)や[Claude Desktop](/ai/integrations/tidb-mcp-claude-desktop.md)。 -- **Python (>=3.10) と uv** : Python (3.10 以降) と`uv`がインストールされていることを確認します。 [インストールガイド](https://docs.astral.sh/uv/getting-started/installation/)に従って`uv`をインストールします。 -- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 +- **MCP 互換クライアント**: 例:[Cursor](/ai/integrations/tidb-mcp-cursor.md)や[Claude Desktop](/ai/integrations/tidb-mcp-claude-desktop.md)。 +- **Python (>=3.10) と uv** : Python (3.10 以降) と`uv`がインストールされていることを確認します。 [インストールガイド](https://docs.astral.sh/uv/getting-started/installation/)に従って`uv`をインストールします。 +- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 ## サポートされているMCPクライアント {#supported-mcp-clients} TiDB MCPサーバーを特定のMCPクライアントで使用する詳細な例については、以下のガイドを参照してください。 -- [Cursor](/ai/integrations/tidb-mcp-cursor.md) -- [Claude Desktop](/ai/integrations/tidb-mcp-claude-desktop.md) +- [Cursor](/ai/integrations/tidb-mcp-cursor.md) +- [Claude Desktop](/ai/integrations/tidb-mcp-claude-desktop.md) 上記のリストにMCPクライアントが含まれていない場合は、以下のセットアップ手順に従ってください。 @@ -42,8 +42,8 @@ TiDB MCPサーバーを特定のMCPクライアントで使用する詳細な例 TiDB MCPサーバーは、MCPクライアントとの統合に関して2つのモードをサポートしています。 -- 標準入出力（STDIO）モード（デフォルト） -- サーバー送信イベント（SSE）モード +- 標準入出力（STDIO）モード（デフォルト） +- サーバー送信イベント（SSE）モード TiDB MCPサーバーはデフォルトでSTDIOモードを使用するため、事前にスタンドアロンサーバーを起動する必要はありません。 @@ -53,13 +53,13 @@ MCPクライアントでTiDB MCPサーバーを設定するには、以下のい STDIOモードを使用してMCPクライアントにTiDB MCPサーバーを設定するには、以下の手順を実行してください。 -1. MCPサーバーの設定方法については、MCPクライアントのドキュメントを参照してください。 +1. MCPサーバーの設定方法については、MCPクライアントのドキュメントを参照してください。 -2. TiDB Cloudコンソールで、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして概要ページに移動します。 +2. TiDB Cloudコンソールで、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして概要ページに移動します。 -3. 接続パラメータを取得するには、右上隅の**Connect**をクリックしてください。 +3. 接続パラメータを取得するには、右上隅の**Connect**をクリックしてください。 -4. AIアプリケーションの設定ファイルの`mcpServers`セクションで、接続パラメータを使用してTiDB MCPサーバーを設定します。 +4. AIアプリケーションの設定ファイルの`mcpServers`セクションで、接続パラメータを使用してTiDB MCPサーバーを設定します。 MCP設定ファイルの例： @@ -84,13 +84,13 @@ STDIOモードを使用してMCPクライアントにTiDB MCPサーバーを設 MCPクライアントでSSEモードを使用してTiDB MCPサーバーを設定するには、以下の手順を実行してください。 -1. MCPサーバーの設定方法については、MCPクライアントのドキュメントを参照してください。 +1. MCPサーバーの設定方法については、MCPクライアントのドキュメントを参照してください。 -2. TiDB Cloudコンソールで、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして概要ページに移動します。 +2. TiDB Cloudコンソールで、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして概要ページに移動します。 -3. 接続パラメータを取得するには、右上隅の**Connect**をクリックしてください。 +3. 接続パラメータを取得するには、右上隅の**Connect**をクリックしてください。 -4. 接続パラメータを含む`.env`ファイルを作成します。 +4. 接続パラメータを含む`.env`ファイルを作成します。 `.env`ファイルの例: @@ -104,13 +104,13 @@ MCPクライアントでSSEモードを使用してTiDB MCPサーバーを設定 EOF ``` -5. `--transport sse`オプションを指定して TiDB MCP サーバーを起動します。 +5. `--transport sse`オプションを指定して TiDB MCP サーバーを起動します。 ```bash uvx --from "pytidb[mcp]" tidb-mcp-server --transport sse ``` -6. `TiDB` MCPサーバー構成を、AIアプリケーション構成ファイルの`mcpServers`セクションに追加します。 +6. `TiDB` MCPサーバー構成を、AIアプリケーション構成ファイルの`mcpServers`セクションに追加します。 ```json { @@ -128,36 +128,36 @@ TiDB MCPサーバーは、MCPクライアントに以下の操作（ツール） **データベース管理** -- `show_databases` - TiDB Cloud Starterインスタンス内のすべてのデータベースを表示します +- `show_databases` - TiDB Cloud Starterインスタンス内のすべてのデータベースを表示します - - `username` : データベースユーザー名（文字列、オプション） - - `password` : データベースパスワード（文字列、オプション） + - `username` : データベースユーザー名（文字列、オプション） + - `password` : データベースパスワード（文字列、オプション） -- `switch_database` - 特定のデータベースに切り替える +- `switch_database` - 特定のデータベースに切り替える - - `db_name` : 切り替え先のデータベース名（文字列、必須） - - `username` : データベースユーザー名（文字列、オプション） - - `password` : データベースパスワード（文字列、オプション） + - `db_name` : 切り替え先のデータベース名（文字列、必須） + - `username` : データベースユーザー名（文字列、オプション） + - `password` : データベースパスワード（文字列、オプション） -- `show_tables` - 現在のデータベース内のすべてのテーブルを表示します +- `show_tables` - 現在のデータベース内のすべてのテーブルを表示します **SQLクエリと実行** -- `db_query` - 読み取り専用のSQLクエリを実行します +- `db_query` - 読み取り専用のSQLクエリを実行します - - `sql_stmt` : SQLクエリステートメント（文字列、必須） + - `sql_stmt` : SQLクエリステートメント（文字列、必須） -- `db_execute` - SQLステートメント（DMLまたはDDL）を実行します +- `db_execute` - SQLステートメント（DMLまたはDDL）を実行します - - `sql_stmts` : 単一のSQL文、またはSQL文の配列（文字列または配列、必須） + - `sql_stmts` : 単一のSQL文、またはSQL文の配列（文字列または配列、必須） **ユーザー管理** -- `db_create_user` - 新しいデータベースユーザーを作成します +- `db_create_user` - 新しいデータベースユーザーを作成します - - `username` : 新規ユーザーの名前（文字列、必須） - - `password` : 新規ユーザーのパスワード（文字列、必須） + - `username` : 新規ユーザーの名前（文字列、必須） + - `password` : 新規ユーザーのパスワード（文字列、必須） -- `db_remove_user` - 既存のデータベースユーザーを削除します +- `db_remove_user` - 既存のデータベースユーザーを削除します - - `username` : 削除するユーザーの名前（文字列、必須） + - `username` : 削除するユーザーの名前（文字列、必須） diff --git a/ai/integrations/tidb-mcp-vscode.md b/ai/integrations/tidb-mcp-vscode.md index 3e94a9d39bf2c..5b1c6372e4ca9 100644 --- a/ai/integrations/tidb-mcp-vscode.md +++ b/ai/integrations/tidb-mcp-vscode.md @@ -11,27 +11,27 @@ summary: このガイドでは、Visual Studio CodeでTiDB MCPサーバーを設 始める前に、以下のものを用意してください。 -- **Visual Studio Code** : [code.visualstudio.com](https://code.visualstudio.com)からVS Codeをダウンロードしてインストールしてください。 -- **Python (>=3.10) と uv** : Python (3.10 以降) と`uv`がインストールされていることを確認します。 [インストールガイド](https://docs.astral.sh/uv/getting-started/installation/)に従って`uv`をインストールします。 -- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 +- **Visual Studio Code** : [code.visualstudio.com](https://code.visualstudio.com)からVS Codeをダウンロードしてインストールしてください。 +- **Python (>=3.10) と uv** : Python (3.10 以降) と`uv`がインストールされていることを確認します。 [インストールガイド](https://docs.astral.sh/uv/getting-started/installation/)に従って`uv`をインストールします。 +- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 ## TiDB Cloud Starterに接続する（推奨） {#connect-to-tidb-cloud-starter-recommended} TiDB Cloudコンソールを使用して、VS Code構成を生成します。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックして概要ページに移動し、右上隅の**Use with AI Tools**をクリックします。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックして概要ページに移動し、右上隅の**Use with AI Tools**をクリックします。 -2. 表示されたダイアログで、VS Codeがアクセスする**Branch**と**Database**を選択します。 +2. 表示されたダイアログで、VS Codeがアクセスする**Branch**と**Database**を選択します。 -3. ダイアログに表示される**Prerequisites**リストを確認し、不足している依存関係があればインストールしてください。 +3. ダイアログに表示される**Prerequisites**リストを確認し、不足している依存関係があればインストールしてください。 -4. ルートパスワードを設定します。 +4. ルートパスワードを設定します。 - - まだパスワードを設定していない場合は、**Generate Password**をクリックして、生成されたパスワードを安全な場所に保存してください（パスワードは一度しか表示されません）。 - - パスワードが既に存在する場合は、 **Enter the password for easy setup**欄に入力してください。 - - パスワードを忘れた場合は、 **Prerequisites**セクションの**Reset password**をクリックして新しいパスワードを生成してください。 + - まだパスワードを設定していない場合は、**Generate Password**をクリックして、生成されたパスワードを安全な場所に保存してください（パスワードは一度しか表示されません）。 + - パスワードが既に存在する場合は、 **Enter the password for easy setup**欄に入力してください。 + - パスワードを忘れた場合は、 **Prerequisites**セクションの**Reset password**をクリックして新しいパスワードを生成してください。 -5. **VS Code**タブを選択し、 **Add to VS Code**をクリックしてから、VS Codeで**Install**をクリックします。 +5. **VS Code**タブを選択し、 **Add to VS Code**をクリックしてから、VS Codeで**Install**をクリックします。 ## 手動設定（任意のTiDBクラスタ） {#manual-configuration-any-tidb-cluster} @@ -58,4 +58,4 @@ TiDB Cloudコンソールを使用して、VS Code構成を生成します。 ## 関連項目 {#see-also} -- [TiDB MCPサーバー](/ai/integrations/tidb-mcp-server.md) +- [TiDB MCPサーバー](/ai/integrations/tidb-mcp-server.md) diff --git a/ai/integrations/tidb-mcp-windsurf.md b/ai/integrations/tidb-mcp-windsurf.md index 5c0cbed1a3b4e..615200a2a7ad4 100644 --- a/ai/integrations/tidb-mcp-windsurf.md +++ b/ai/integrations/tidb-mcp-windsurf.md @@ -11,29 +11,29 @@ summary: このガイドでは、Windsurf で TiDB MCP サーバーを設定す 始める前に、以下のものを用意してください。 -- **Windsurf** ： [windsurf.com](https://windsurf.com)からWindsurfをダウンロードしてインストールしてください。 -- **Python (>=3.10) と uv** : Python (3.10 以降) と`uv`がインストールされていることを確認します。 [インストールガイド](https://docs.astral.sh/uv/getting-started/installation/)に従って`uv`をインストールします。 -- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 +- **Windsurf** ： [windsurf.com](https://windsurf.com)からWindsurfをダウンロードしてインストールしてください。 +- **Python (>=3.10) と uv** : Python (3.10 以降) と`uv`がインストールされていることを確認します。 [インストールガイド](https://docs.astral.sh/uv/getting-started/installation/)に従って`uv`をインストールします。 +- **TiDB Cloud Starterインスタンス**: [TiDB Cloud](https://tidbcloud.com/free-trial)で無料のTiDB Cloud Starterインスタンスを作成できます。 ## TiDB Cloud Starterに接続する（推奨） {#connect-to-tidb-cloud-starter-recommended} TiDB Cloudコンソールを使用して接続の詳細を取得し、WindsurfのMCP構成を更新してください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックして概要ページに移動し、右上隅の**Use with AI Tools**をクリックします。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックして概要ページに移動し、右上隅の**Use with AI Tools**をクリックします。 -2. 表示されたダイアログで、Windsurfがアクセスする**Branch**と**Database**を選択します。 +2. 表示されたダイアログで、Windsurfがアクセスする**Branch**と**Database**を選択します。 -3. ダイアログに表示される**Prerequisites**リストを確認し、不足している依存関係があればインストールしてください。 +3. ダイアログに表示される**Prerequisites**リストを確認し、不足している依存関係があればインストールしてください。 -4. ルートパスワードを設定します。 +4. ルートパスワードを設定します。 - - まだパスワードを設定していない場合は、**Generate Password**をクリックして、生成されたパスワードを安全な場所に保存してください（パスワードは一度しか表示されません）。 - - パスワードが既に存在する場合は、 **Enter the password for easy setup**欄に入力してください。 - - パスワードを忘れた場合は、 **Prerequisites**セクションの**Reset password**をクリックして新しいパスワードを生成してください。 + - まだパスワードを設定していない場合は、**Generate Password**をクリックして、生成されたパスワードを安全な場所に保存してください（パスワードは一度しか表示されません）。 + - パスワードが既に存在する場合は、 **Enter the password for easy setup**欄に入力してください。 + - パスワードを忘れた場合は、 **Prerequisites**セクションの**Reset password**をクリックして新しいパスワードを生成してください。 -5. **Windsurf**タブを選択し、表示された接続値をコピーしてください。 +5. **Windsurf**タブを選択し、表示された接続値をコピーしてください。 -6. コピーした値を使用して`mcp_config.json`ファイルを更新します。詳細については、 [Windsurf MCP ドキュメント](https://docs.windsurf.com/windsurf/cascade/mcp#adding-a-new-mcp-plugin)を参照してください。 +6. コピーした値を使用して`mcp_config.json`ファイルを更新します。詳細については、 [Windsurf MCP ドキュメント](https://docs.windsurf.com/windsurf/cascade/mcp#adding-a-new-mcp-plugin)を参照してください。 ## 手動設定（任意のTiDBクラスタ） {#manual-configuration-any-tidb-cluster} @@ -59,4 +59,4 @@ TiDB Cloudコンソールを使用して接続の詳細を取得し、Windsurf ## 関連項目 {#see-also} -- [TiDB MCPサーバー](/ai/integrations/tidb-mcp-server.md) +- [TiDB MCPサーバー](/ai/integrations/tidb-mcp-server.md) diff --git a/ai/integrations/vector-search-auto-embedding-amazon-titan.md b/ai/integrations/vector-search-auto-embedding-amazon-titan.md index 864ca58aa8263..78f3e69e56a00 100644 --- a/ai/integrations/vector-search-auto-embedding-amazon-titan.md +++ b/ai/integrations/vector-search-auto-embedding-amazon-titan.md @@ -18,16 +18,16 @@ TiDB Cloud は、次の[Amazon Titan埋め込みモデル](https://docs.aws.amaz **Amazon Titan テキスト埋め込み V2 モデル** -- 名前: `tidbcloud_free/amazon/titan-embed-text-v2` -- 寸法: 1024 (デフォルト)、512、256 -- 距離指標：コサイン類似度、L2 -- 対応言語：英語（プレビュー版では100以上の言語に対応） -- 典型的な使用例：RAG、文書検索、再ランキング、分類 -- 入力可能なテキストトークンの最大数：8,192 -- 入力可能なテキスト文字数：最大50,000文字 -- 価格：無料 -- TiDB Cloudがホストしています: ✅ -- 鍵をご持参ください：❌ +- 名前: `tidbcloud_free/amazon/titan-embed-text-v2` +- 寸法: 1024 (デフォルト)、512、256 +- 距離指標：コサイン類似度、L2 +- 対応言語：英語（プレビュー版では100以上の言語に対応） +- 典型的な使用例：RAG、文書検索、再ランキング、分類 +- 入力可能なテキストトークンの最大数：8,192 +- 入力可能なテキスト文字数：最大50,000文字 +- 価格：無料 +- TiDB Cloudがホストしています: ✅ +- 鍵をご持参ください：❌ このモデルの詳細については、 [Amazon Bedrock のドキュメント](https://docs.aws.amazon.com/bedrock/latest/userguide/titan-embedding-models.html)を参照してください。 @@ -80,8 +80,8 @@ LIMIT 2; `additional_json_options` `EMBED_TEXT()` } パラメータを使用して、以下のオプションを指定できます。 -- `normalize` (オプション): 出力埋め込みを正規化するかどうか。デフォルトは`true`です。 -- `dimensions` (オプション): 出力埋め込みの次元数。サポートされている値: `1024` (デフォルト)、 `512` 、および`256` 。 +- `normalize` (オプション): 出力埋め込みを正規化するかどうか。デフォルトは`true`です。 +- `dimensions` (オプション): 出力埋め込みの次元数。サポートされている値: `1024` (デフォルト)、 `512` 、および`256` 。 **例：別の次元を使用する** @@ -129,7 +129,7 @@ LIMIT 2; ## 関連項目 {#see-also} -- [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md) -- [ベクトル検索](/ai/concepts/vector-search-overview.md) -- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) -- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) +- [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md) +- [ベクトル検索](/ai/concepts/vector-search-overview.md) +- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) +- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) diff --git a/ai/integrations/vector-search-auto-embedding-cohere.md b/ai/integrations/vector-search-auto-embedding-cohere.md index 212476ba09114..d98e80a88d84d 100644 --- a/ai/integrations/vector-search-auto-embedding-cohere.md +++ b/ai/integrations/vector-search-auto-embedding-cohere.md @@ -18,39 +18,39 @@ TiDB Cloud は、次の[Cohere](https://cohere.com/)埋め込みモデルをネ **Cohere Embed v3 モデル** -- 名前: `tidbcloud_free/cohere/embed-english-v3` -- 寸法: 1024 -- 距離指標：コサイン類似度、L2 -- 言語：英語 -- 入力可能なテキストトークンの最大数：512個（1トークンあたり約4文字） -- 入力可能なテキスト文字数：最大2,048文字 -- 価格：無料 -- TiDB Cloudがホストしています: ✅ `tidbcloud_free/cohere/embed-english-v3` -- 鍵をご持参ください：✅ `cohere/embed-english-v3.0` +- 名前: `tidbcloud_free/cohere/embed-english-v3` +- 寸法: 1024 +- 距離指標：コサイン類似度、L2 +- 言語：英語 +- 入力可能なテキストトークンの最大数：512個（1トークンあたり約4文字） +- 入力可能なテキスト文字数：最大2,048文字 +- 価格：無料 +- TiDB Cloudがホストしています: ✅ `tidbcloud_free/cohere/embed-english-v3` +- 鍵をご持参ください：✅ `cohere/embed-english-v3.0` **Cohere Multilingual Embed v3 モデル** -- 名前: `tidbcloud_free/cohere/embed-multilingual-v3` -- 寸法: 1024 -- 距離指標：コサイン類似度、L2 -- 対応言語：100以上の言語 -- 入力可能なテキストトークンの最大数：512個（1トークンあたり約4文字） -- 入力可能なテキスト文字数：最大2,048文字 -- 価格：無料 -- TiDB Cloudがホストしています: ✅ `tidbcloud_free/cohere/embed-multilingual-v3` -- 鍵をご持参ください：✅ `cohere/embed-multilingual-v3.0` +- 名前: `tidbcloud_free/cohere/embed-multilingual-v3` +- 寸法: 1024 +- 距離指標：コサイン類似度、L2 +- 対応言語：100以上の言語 +- 入力可能なテキストトークンの最大数：512個（1トークンあたり約4文字） +- 入力可能なテキスト文字数：最大2,048文字 +- 価格：無料 +- TiDB Cloudがホストしています: ✅ `tidbcloud_free/cohere/embed-multilingual-v3` +- 鍵をご持参ください：✅ `cohere/embed-multilingual-v3.0` あるいは、独自のCohere APIキー（BYOK）をお持ちの場合は`cohere/`プレフィックスを使用してすべてのCohereモデルをご利用いただけます。例： **Cohere Embed v4 モデル** -- 名前: `cohere/embed-v4.0` -- 寸法：256、512、1024、1536（デフォルト） -- 距離指標：コサイン類似度、L2 -- 入力可能なテキストトークンの最大数：128,000 -- 価格：Cohereが請求 -- TiDB Cloudでホストされています: ❌ -- 鍵をご持参ください：✅ +- 名前: `cohere/embed-v4.0` +- 寸法：256、512、1024、1536（デフォルト） +- 距離指標：コサイン類似度、L2 +- 入力可能なテキストトークンの最大数：128,000 +- 価格：Cohereが請求 +- TiDB Cloudでホストされています: ❌ +- 鍵をご持参ください：✅ Cohere モデルの完全なリストについては、 [Cohereのドキュメント](https://docs.cohere.com/docs/cohere-embed)を参照してください。 @@ -72,8 +72,8 @@ CREATE TABLE sample ( > **Note:** > -> - Cohere埋め込みモデルの場合、テーブルを定義する際に、 `EMBED_TEXT()`関数で`input_type`を指定する必要があります。例えば、 `'{"input_type": "search_document", "input_type@search": "search_query"}'`は、データ挿入時に`input_type`が`search_document`に設定され、ベクトル検索時に`search_query`が自動的に適用されることを意味します。 -> - `@search`サフィックスは、そのフィールドがベクトル検索クエリの実行時のみ有効であることを示しています。そのため、クエリを作成する際に`input_type`を再度指定する必要はありません。 +> - Cohere埋め込みモデルの場合、テーブルを定義する際に、 `EMBED_TEXT()`関数で`input_type`を指定する必要があります。例えば、 `'{"input_type": "search_document", "input_type@search": "search_query"}'`は、データ挿入時に`input_type`が`search_document`に設定され、ベクトル検索時に`search_query`が自動的に適用されることを意味します。 +> - `@search`サフィックスは、そのフィールドがベクトル検索クエリの実行時のみ有効であることを示しています。そのため、クエリを作成する際に`input_type`を再度指定する必要はありません。 データ挿入とデータ照会： @@ -112,18 +112,18 @@ LIMIT 2; **Embed v3**モデルと**Multilingual Embed v3**モデルの両方で、以下のオプションがサポートされています。これらのオプションは、 `additional_json_options`関数の`EMBED_TEXT()`パラメータを介して指定できます。 -- `input_type` (必須): 埋め込みの目的を示す特別なトークンを先頭に追加します。同じタスクの埋め込みを生成する場合は、常に同じ入力タイプを使用する必要があります。そうしないと、埋め込みが異なる意味空間にマッピングされ、互換性がなくなります。唯一の例外はセマンティック検索で、ドキュメントは`search_document`で埋め込まれ、クエリは`search_query`で埋め込まれます。 +- `input_type` (必須): 埋め込みの目的を示す特別なトークンを先頭に追加します。同じタスクの埋め込みを生成する場合は、常に同じ入力タイプを使用する必要があります。そうしないと、埋め込みが異なる意味空間にマッピングされ、互換性がなくなります。唯一の例外はセマンティック検索で、ドキュメントは`search_document`で埋め込まれ、クエリは`search_query`で埋め込まれます。 - - `search_document` : ドキュメントから埋め込みを生成し、ベクトルデータベースに保存します。 - - `search_query` : クエリから埋め込みを生成し、ベクトルデータベースに保存されている埋め込みに対して検索を行います。 - - `classification` : テキスト分類器への入力として使用される埋め込みを生成します。 - - `clustering` : クラスタリングタスク用の埋め込みを生成します。 + - `search_document` : ドキュメントから埋め込みを生成し、ベクトルデータベースに保存します。 + - `search_query` : クエリから埋め込みを生成し、ベクトルデータベースに保存されている埋め込みに対して検索を行います。 + - `classification` : テキスト分類器への入力として使用される埋め込みを生成します。 + - `clustering` : クラスタリングタスク用の埋め込みを生成します。 -- `truncate` （オプション）：APIが最大トークン長を超える入力をどのように処理するかを制御します。以下のいずれかの値を指定できます。 +- `truncate` （オプション）：APIが最大トークン長を超える入力をどのように処理するかを制御します。以下のいずれかの値を指定できます。 - - `NONE` (デフォルト): 入力が最大入力トークン長を超えた場合にエラーを返します。 - - `START` : 入力が収まるまで、先頭からテキストを破棄します。 - - `END` : 入力が収まるまで末尾からテキストを破棄します。 + - `NONE` (デフォルト): 入力が最大入力トークン長を超えた場合にエラーを返します。 + - `START` : 入力が収まるまで、先頭からテキストを破棄します。 + - `END` : 入力が収まるまで末尾からテキストを破棄します。 ## 使用例（BYOK） {#usage-example-byok} @@ -335,7 +335,7 @@ CREATE TABLE sample ( ## 関連項目 {#see-also} -- [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md) -- [ベクトル検索](/ai/concepts/vector-search-overview.md) -- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) -- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) +- [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md) +- [ベクトル検索](/ai/concepts/vector-search-overview.md) +- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) +- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) diff --git a/ai/integrations/vector-search-auto-embedding-gemini.md b/ai/integrations/vector-search-auto-embedding-gemini.md index f46169f03ebe8..313c01d349e53 100644 --- a/ai/integrations/vector-search-auto-embedding-gemini.md +++ b/ai/integrations/vector-search-auto-embedding-gemini.md @@ -18,13 +18,13 @@ Gemini APIキー（BYOK）をお持ちの場合は、 `gemini/`プレフィッ **Gemini埋め込み-001** -- 名前: `gemini/gemini-embedding-001` -- 寸法：128～3072（デフォルト：3072） -- 距離指標：コサイン類似度、L2 -- 入力可能なテキストトークンの最大数：2,048 -- 価格：Googleが課金 -- TiDB Cloudでホストされています: ❌ -- 鍵をご持参ください：✅ +- 名前: `gemini/gemini-embedding-001` +- 寸法：128～3072（デフォルト：3072） +- 距離指標：コサイン類似度、L2 +- 入力可能なテキストトークンの最大数：2,048 +- 価格：Googleが課金 +- TiDB Cloudでホストされています: ❌ +- 鍵をご持参ください：✅ 利用可能なモデルの完全なリストについては、 [Geminiのドキュメント](https://ai.google.dev/gemini-api/docs/embeddings)を参照してください。 @@ -281,7 +281,7 @@ CREATE TABLE sample ( ## 関連項目 {#see-also} -- [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md) -- [ベクトル検索](/ai/concepts/vector-search-overview.md) -- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) -- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) +- [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md) +- [ベクトル検索](/ai/concepts/vector-search-overview.md) +- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) +- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) diff --git a/ai/integrations/vector-search-auto-embedding-huggingface.md b/ai/integrations/vector-search-auto-embedding-huggingface.md index fe4ccd9442438..99c50d2e8a5e0 100644 --- a/ai/integrations/vector-search-auto-embedding-huggingface.md +++ b/ai/integrations/vector-search-auto-embedding-huggingface.md @@ -20,13 +20,13 @@ aliases: ['/ja/tidbcloud/vector-search-auto-embedding-huggingface/'] ## 多言語対応E5ラージ {#multilingual-e5-large} -- 名前: `huggingface/intfloat/multilingual-e5-large` -- 寸法: 1024 -- 距離指標：コサイン類似度、L2 -- 価格：Hugging Faceによる課金 -- TiDB Cloudでホストされています: ❌ -- 鍵をご持参ください：✅ -- プロジェクトホームページ： [https://huggingface.co/intfloat/multilingual-e5-large](https://huggingface.co/intfloat/multilingual-e5-large) +- 名前: `huggingface/intfloat/multilingual-e5-large` +- 寸法: 1024 +- 距離指標：コサイン類似度、L2 +- 価格：Hugging Faceによる課金 +- TiDB Cloudでホストされています: ❌ +- 鍵をご持参ください：✅ +- プロジェクトホームページ： [https://huggingface.co/intfloat/multilingual-e5-large](https://huggingface.co/intfloat/multilingual-e5-large) 例： @@ -64,13 +64,13 @@ LIMIT 2; ## bge-m3 {#bge-m3} -- 名前: `huggingface/BAAI/bge-m3` -- 寸法: 1024 -- 距離指標：コサイン類似度、L2 -- 価格：Hugging Faceによる課金 -- TiDB Cloudでホストされています: ❌ -- 鍵をご持参ください：✅ -- プロジェクトホームページ： [https://huggingface.co/BAAI/bge-m3](https://huggingface.co/BAAI/bge-m3) +- 名前: `huggingface/BAAI/bge-m3` +- 寸法: 1024 +- 距離指標：コサイン類似度、L2 +- 価格：Hugging Faceによる課金 +- TiDB Cloudでホストされています: ❌ +- 鍵をご持参ください：✅ +- プロジェクトホームページ： [https://huggingface.co/BAAI/bge-m3](https://huggingface.co/BAAI/bge-m3) ```sql SET @@GLOBAL.TIDB_EXP_EMBED_HUGGINGFACE_API_KEY = 'your-huggingface-api-key-here'; @@ -106,13 +106,13 @@ LIMIT 2; ## all-MiniLM-L6-v2 {#all-minilm-l6-v2} -- 名前: `huggingface/sentence-transformers/all-MiniLM-L6-v2` -- 寸法: 384 -- 距離指標：コサイン類似度、L2 -- 価格：Hugging Faceによる課金 -- TiDB Cloudでホストされています: ❌ -- 鍵をご持参ください：✅ -- プロジェクトホームページ： [https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2](https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2) +- 名前: `huggingface/sentence-transformers/all-MiniLM-L6-v2` +- 寸法: 384 +- 距離指標：コサイン類似度、L2 +- 価格：Hugging Faceによる課金 +- TiDB Cloudでホストされています: ❌ +- 鍵をご持参ください：✅ +- プロジェクトホームページ： [https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2](https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2) 例： @@ -150,13 +150,13 @@ LIMIT 2; ## all-mpnet-base-v2 {#all-mpnet-base-v2} -- 名前: `huggingface/sentence-transformers/all-mpnet-base-v2` -- 寸法: 768 -- 距離指標：コサイン類似度、L2 -- 価格：Hugging Faceによる課金 -- TiDB Cloudでホストされています: ❌ -- 鍵をご持参ください：✅ -- プロジェクトホームページ： [https://huggingface.co/sentence-transformers/all-mpnet-base-v2](https://huggingface.co/sentence-transformers/all-mpnet-base-v2) +- 名前: `huggingface/sentence-transformers/all-mpnet-base-v2` +- 寸法: 768 +- 距離指標：コサイン類似度、L2 +- 価格：Hugging Faceによる課金 +- TiDB Cloudでホストされています: ❌ +- 鍵をご持参ください：✅ +- プロジェクトホームページ： [https://huggingface.co/sentence-transformers/all-mpnet-base-v2](https://huggingface.co/sentence-transformers/all-mpnet-base-v2) ```sql SET @@GLOBAL.TIDB_EXP_EMBED_HUGGINGFACE_API_KEY = 'your-huggingface-api-key-here'; @@ -196,14 +196,14 @@ LIMIT 2; > > このモデルでは、Hugging Face Inference APIが不安定になる可能性があります。 -- 名前: `huggingface/Qwen/Qwen3-Embedding-0.6B` -- 寸法: 1024 -- 距離指標：コサイン類似度、L2 -- 入力可能なテキストトークンの最大数：512 -- 価格：Hugging Faceによる課金 -- TiDB Cloudでホストされています: ❌ -- 鍵をご持参ください：✅ -- プロジェクトホームページ： [https://huggingface.co/Qwen/Qwen3-Embedding-0.6B](https://huggingface.co/Qwen/Qwen3-Embedding-0.6B) +- 名前: `huggingface/Qwen/Qwen3-Embedding-0.6B` +- 寸法: 1024 +- 距離指標：コサイン類似度、L2 +- 入力可能なテキストトークンの最大数：512 +- 価格：Hugging Faceによる課金 +- TiDB Cloudでホストされています: ❌ +- 鍵をご持参ください：✅ +- プロジェクトホームページ： [https://huggingface.co/Qwen/Qwen3-Embedding-0.6B](https://huggingface.co/Qwen/Qwen3-Embedding-0.6B) ```sql SET @@GLOBAL.TIDB_EXP_EMBED_HUGGINGFACE_API_KEY = 'your-huggingface-api-key-here'; @@ -323,7 +323,7 @@ for doc in results: ## 関連項目 {#see-also} -- [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md) -- [ベクトル検索](/ai/concepts/vector-search-overview.md) -- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) -- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) +- [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md) +- [ベクトル検索](/ai/concepts/vector-search-overview.md) +- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) +- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) diff --git a/ai/integrations/vector-search-auto-embedding-jina-ai.md b/ai/integrations/vector-search-auto-embedding-jina-ai.md index cedba8cb616be..b0b9935d62fb9 100644 --- a/ai/integrations/vector-search-auto-embedding-jina-ai.md +++ b/ai/integrations/vector-search-auto-embedding-jina-ai.md @@ -20,23 +20,23 @@ Jina AI APIキー（BYOK）をお持ちの場合は、 `jina_ai/`プレフィッ **jina-embeddings-v4** -- 名前: `jina_ai/jina-embeddings-v4` -- 寸法: 2048 -- 距離指標：コサイン類似度、L2 -- 入力可能なテキストトークンの最大数：32,768 -- 価格：Jina AIによる課金 -- TiDB Cloudでホストされています: ❌ -- 鍵をご持参ください：✅ +- 名前: `jina_ai/jina-embeddings-v4` +- 寸法: 2048 +- 距離指標：コサイン類似度、L2 +- 入力可能なテキストトークンの最大数：32,768 +- 価格：Jina AIによる課金 +- TiDB Cloudでホストされています: ❌ +- 鍵をご持参ください：✅ **jina-embeddings-v3** -- 名前: `jina_ai/jina-embeddings-v3` -- 寸法: 1024 -- 距離指標：コサイン類似度、L2 -- 入力可能なテキストトークンの最大数：8,192 -- 価格：Jina AIによる課金 -- TiDB Cloudでホストされています: ❌ -- 鍵をご持参ください：✅ +- 名前: `jina_ai/jina-embeddings-v3` +- 寸法: 1024 +- 距離指標：コサイン類似度、L2 +- 入力可能なテキストトークンの最大数：8,192 +- 価格：Jina AIによる課金 +- TiDB Cloudでホストされています: ❌ +- 鍵をご持参ください：✅ 利用可能なモデルの完全なリストについては、 [Jina AI ドキュメント](https://jina.ai/embeddings/)を参照してください。 @@ -259,7 +259,7 @@ CREATE TABLE sample ( ## 関連項目 {#see-also} -- [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md) -- [ベクトル検索](/ai/concepts/vector-search-overview.md) -- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) -- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) +- [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md) +- [ベクトル検索](/ai/concepts/vector-search-overview.md) +- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) +- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) diff --git a/ai/integrations/vector-search-auto-embedding-nvidia-nim.md b/ai/integrations/vector-search-auto-embedding-nvidia-nim.md index 1fee5b7022f75..8d366d66d62b4 100644 --- a/ai/integrations/vector-search-auto-embedding-nvidia-nim.md +++ b/ai/integrations/vector-search-auto-embedding-nvidia-nim.md @@ -20,14 +20,14 @@ NVIDIA NIM 上でホストされている埋め込みモデルは、独自の[NV ## bge-m3 {#bge-m3} -- 名前: `nvidia_nim/baai/bge-m3` -- 寸法: 1024 -- 距離指標：コサイン類似度、L2 -- 入力可能なテキストトークンの最大数：8,192 -- 価格：NVIDIAが請求 -- TiDB Cloudでホストされています: ❌ -- 鍵をご持参ください：✅ -- ドキュメント： [https://docs.api.nvidia.com/nim/reference/baai-bge-m3](https://docs.api.nvidia.com/nim/reference/baai-bge-m3) +- 名前: `nvidia_nim/baai/bge-m3` +- 寸法: 1024 +- 距離指標：コサイン類似度、L2 +- 入力可能なテキストトークンの最大数：8,192 +- 価格：NVIDIAが請求 +- TiDB Cloudでホストされています: ❌ +- 鍵をご持参ください：✅ +- ドキュメント： [https://docs.api.nvidia.com/nim/reference/baai-bge-m3](https://docs.api.nvidia.com/nim/reference/baai-bge-m3) 例： @@ -249,7 +249,7 @@ LIMIT 3; ## 関連項目 {#see-also} -- [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md) -- [ベクトル検索](/ai/concepts/vector-search-overview.md) -- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) -- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) +- [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md) +- [ベクトル検索](/ai/concepts/vector-search-overview.md) +- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) +- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) diff --git a/ai/integrations/vector-search-auto-embedding-openai.md b/ai/integrations/vector-search-auto-embedding-openai.md index 2bc6a87e3e510..c50eada19c990 100644 --- a/ai/integrations/vector-search-auto-embedding-openai.md +++ b/ai/integrations/vector-search-auto-embedding-openai.md @@ -18,21 +18,21 @@ OpenAI APIキー（BYOK）をお持ちの場合は、 `openai/`というプレ **テキスト埋め込み3（小）** -- 名前: `openai/text-embedding-3-small` -- 寸法：512～1536（デフォルト：1536） -- 距離指標：コサイン類似度、L2 -- 価格：OpenAIが課金 -- TiDB Cloudでホストされています: ❌ -- 鍵をご持参ください：✅ +- 名前: `openai/text-embedding-3-small` +- 寸法：512～1536（デフォルト：1536） +- 距離指標：コサイン類似度、L2 +- 価格：OpenAIが課金 +- TiDB Cloudでホストされています: ❌ +- 鍵をご持参ください：✅ **テキスト埋め込み3（大）** -- 名前: `openai/text-embedding-3-large` -- 寸法：256～3072（デフォルト：3072） -- 距離指標：コサイン類似度、L2 -- 価格：OpenAIが課金 -- TiDB Cloudでホストされています: ❌ -- 鍵をご持参ください：✅ +- 名前: `openai/text-embedding-3-large` +- 寸法：256～3072（デフォルト：3072） +- 距離指標：コサイン類似度、L2 +- 価格：OpenAIが課金 +- TiDB Cloudでホストされています: ❌ +- 鍵をご持参ください：✅ 利用可能なモデルの完全なリストについては、 [OpenAIドキュメント](https://platform.openai.com/docs/guides/embeddings)を参照してください。 @@ -266,8 +266,8 @@ SET @@GLOBAL.TIDB_EXP_EMBED_OPENAI_API_BASE = ''; > **Note:** > -> - セキュリティ上の理由から、API ベースとして設定できるのは Azure OpenAI の URL または OpenAI の URL のみです。任意のベース URL は許可されていません。 -> - OpenAI互換の別の埋め込みサービスを利用するには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 +> - セキュリティ上の理由から、API ベースとして設定できるのは Azure OpenAI の URL または OpenAI の URL のみです。任意のベース URL は許可されていません。 +> - OpenAI互換の別の埋め込みサービスを利用するには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 ## オプション {#options} @@ -291,7 +291,7 @@ CREATE TABLE sample ( ## 関連項目 {#see-also} -- [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md) -- [ベクトル検索](/ai/concepts/vector-search-overview.md) -- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) -- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) +- [自動埋め込みの概要](/ai/integrations/vector-search-auto-embedding-overview.md) +- [ベクトル検索](/ai/concepts/vector-search-overview.md) +- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) +- [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md) diff --git a/ai/integrations/vector-search-auto-embedding-overview.md b/ai/integrations/vector-search-auto-embedding-overview.md index 6db7f1804e9cc..2ae5b02733718 100644 --- a/ai/integrations/vector-search-auto-embedding-overview.md +++ b/ai/integrations/vector-search-auto-embedding-overview.md @@ -10,9 +10,9 @@ aliases: ['/ja/tidbcloud/vector-search-auto-embedding-overview/'] 自動埋め込み機能を使用するための基本的なワークフローは以下のとおりです。 -1. `EMBED_TEXT()`を使用して、テキスト列と生成されたベクトル列を持つ**テーブルを定義します**。 -2. **テキストデータを挿入すると**、ベクトルが自動的に生成され保存されます。 -3. **テキストを使用してクエリを実行します**。 `VEC_EMBED_COSINE_DISTANCE()`または`VEC_EMBED_L2_DISTANCE()`を使用して、意味的に類似したコンテンツを検索します。 +1. `EMBED_TEXT()`を使用して、テキスト列と生成されたベクトル列を持つ**テーブルを定義します**。 +2. **テキストデータを挿入すると**、ベクトルが自動的に生成され保存されます。 +3. **テキストを使用してクエリを実行します**。 `VEC_EMBED_COSINE_DISTANCE()`または`VEC_EMBED_L2_DISTANCE()`を使用して、意味的に類似したコンテンツを検索します。 > **Note:** > @@ -103,8 +103,8 @@ LIMIT 3; > **Note:** > -> - ベクトルインデックスを定義する場合は、 `VEC_COSINE_DISTANCE()`または`VEC_L2_DISTANCE()`を使用します。 -> - クエリを実行する際は、 `VEC_EMBED_COSINE_DISTANCE()`または`VEC_EMBED_L2_DISTANCE()`を使用してください。 +> - ベクトルインデックスを定義する場合は、 `VEC_COSINE_DISTANCE()`または`VEC_L2_DISTANCE()`を使用します。 +> - クエリを実行する際は、 `VEC_EMBED_COSINE_DISTANCE()`または`VEC_EMBED_L2_DISTANCE()`を使用してください。 ## 利用可能なテキスト埋め込みモデル {#available-text-embedding-models} @@ -171,8 +171,8 @@ VEC_EMBED_L2_DISTANCE(vector_column, "query_text") TiDBは、さまざまな埋め込みプロバイダーやモデルとの統合のための統一インターフェースを提供します。 -- **プログラムによる使用**：特定のプロバイダーまたはモデル用の埋め込み関数を作成するには、AI SDK の`EmbeddingFunction`クラスを使用します。 -- **SQL の使用法**: `EMBED_TEXT`関数を使用して、テキストデータから直接埋め込みを生成します。 +- **プログラムによる使用**：特定のプロバイダーまたはモデル用の埋め込み関数を作成するには、AI SDK の`EmbeddingFunction`クラスを使用します。 +- **SQL の使用法**: `EMBED_TEXT`関数を使用して、テキストデータから直接埋め込みを生成します。 `EmbeddingFunction`クラスを使用すると、さまざまな埋め込みプロバイダーやモデルを操作できます。 @@ -186,20 +186,20 @@ TiDBは、さまざまな埋め込みプロバイダーやモデルとの統合 **パラメータ:** -- `model_name` *(必須)* : 使用する埋め込みモデルを`{provider_name}/{model_name}`の形式で指定します。 +- `model_name` *(必須)* : 使用する埋め込みモデルを`{provider_name}/{model_name}`の形式で指定します。 -- `dimensions` *(オプション)* : 出力ベクトル埋め込みの次元数。指定しない場合、モデルにデフォルトの次元がない場合は、初期化時にテスト文字列が埋め込まれ、実際の次元が自動的に決定されます。 +- `dimensions` *(オプション)* : 出力ベクトル埋め込みの次元数。指定しない場合、モデルにデフォルトの次元がない場合は、初期化時にテスト文字列が埋め込まれ、実際の次元が自動的に決定されます。 -- `api_key` *（オプション）* ：埋め込みサービスにアクセスするためのAPIキー。明示的に設定されていない場合は、プロバイダのデフォルト環境変数からキーを取得します。 +- `api_key` *（オプション）* ：埋め込みサービスにアクセスするためのAPIキー。明示的に設定されていない場合は、プロバイダのデフォルト環境変数からキーを取得します。 -- `api_base` *(オプション)* : 埋め込みAPIサービスのベースURL。 +- `api_base` *(オプション)* : 埋め込みAPIサービスのベースURL。 -- `use_server` *(オプション)* : TiDB Cloud のホスト型埋め込みサービスを使用するかどうか。TiDB Cloud Starterの場合は、デフォルトで`True`になります。 +- `use_server` *(オプション)* : TiDB Cloud のホスト型埋め込みサービスを使用するかどうか。TiDB Cloud Starterの場合は、デフォルトで`True`になります。 -- `multimodal` *(オプション)* : マルチモーダル埋め込みモデルを使用するかどうか。有効にすると、 `use_server`は自動的に`False`に設定され、埋め込みサービスがクライアント側で呼び出されます。 +- `multimodal` *(オプション)* : マルチモーダル埋め込みモデルを使用するかどうか。有効にすると、 `use_server`は自動的に`False`に設定され、埋め込みサービスがクライアント側で呼び出されます。 ## 関連項目 {#see-also} -- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) -- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) -- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) +- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) +- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) +- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) diff --git a/ai/integrations/vector-search-integrate-with-amazon-bedrock.md b/ai/integrations/vector-search-integrate-with-amazon-bedrock.md index b8d71eb4edcf0..10d0aa22f9b4d 100644 --- a/ai/integrations/vector-search-integrate-with-amazon-bedrock.md +++ b/ai/integrations/vector-search-integrate-with-amazon-bedrock.md @@ -14,8 +14,8 @@ aliases: ['/ja/tidbcloud/vector-search-integrate-with-amazon-bedrock/'] > **Note:** > -> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、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以降を推奨）。 +> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、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以降を推奨）。 > **Tip** > @@ -25,11 +25,11 @@ aliases: ['/ja/tidbcloud/vector-search-integrate-with-amazon-bedrock/'] このチュートリアルを完了するには、以下が必要です。 -- [Python 3.11以降](https://www.python.org/downloads/)インストールされています +- [Python 3.11以降](https://www.python.org/downloads/)インストールされています -- [pip](https://pypi.org/project/pip/)がインストールされました +- [pip](https://pypi.org/project/pip/)がインストールされました -- [AWS CLI](https://aws.amazon.com/cli/)がインストールされました +- [AWS CLI](https://aws.amazon.com/cli/)がインストールされました AWS CLI プロファイルがサポートされている[Amazon Bedrock](https://aws.amazon.com/bedrock/)リージョンに設定されていることを確認してください。サポートされている地域のリストは[Amazon Bedrock リージョン](https://docs.aws.amazon.com/bedrock/latest/userguide/models-regions.html)でご覧いただけます。サポートされているリージョンに切り替えるには、次のコマンドを実行します。 @@ -37,14 +37,14 @@ aliases: ['/ja/tidbcloud/vector-search-integrate-with-amazon-bedrock/'] aws configure set region ``` -- TiDB Cloud Starterインスタンス +- TiDB Cloud Starterインスタンス お持ちでない場合は、 [TiDB Cloud Starterインスタンスを作成する](/tidb-cloud/select-cluster-tier.md#starter)。 -- [Amazon Bedrockに必要な権限](https://docs.aws.amazon.com/bedrock/latest/userguide/security_iam_id-based-policy-examples.html)AWS アカウントと次のモデルへのアクセス: +- [Amazon Bedrockに必要な権限](https://docs.aws.amazon.com/bedrock/latest/userguide/security_iam_id-based-policy-examples.html)AWS アカウントと次のモデルへのアクセス: - - **Amazon Titan Embeddings** ( `amazon.titan-embed-text-v2:0` ) は、テキスト埋め込みを生成するために使用されます。 - - テキスト生成に使用される**Meta Llama 3** （ `us.meta.llama3-2-3b-instruct-v1:0` ） + - **Amazon Titan Embeddings** ( `amazon.titan-embed-text-v2:0` ) は、テキスト埋め込みを生成するために使用されます。 + - テキスト生成に使用される**Meta Llama 3** （ `us.meta.llama3-2-3b-instruct-v1:0` ） アクセス権がない場合は、 [Amazon Bedrock基盤モデルへのアクセスをリクエストする](https://docs.aws.amazon.com/bedrock/latest/userguide/getting-started.html#getting-started-model-access)手順に従ってください。 @@ -56,31 +56,31 @@ aliases: ['/ja/tidbcloud/vector-search-integrate-with-amazon-bedrock/'] [TiDB Cloudコンソール](https://tidbcloud.com/)からTiDB接続情報を取得し、開発環境の環境変数を以下のように設定してください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、次に、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、次に、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. 環境変数を設定するには、ターミナルで以下のコマンドを実行してください。コマンド内のプレースホルダーは、接続ダイアログから取得した対応する接続​​パラメータに置き換える必要があります。 +5. 環境変数を設定するには、ターミナルで以下のコマンドを実行してください。コマンド内のプレースホルダーは、接続ダイアログから取得した対応する接続​​パラメータに置き換える必要があります。 ```shell export TIDB_HOST= @@ -92,20 +92,20 @@ aliases: ['/ja/tidbcloud/vector-search-integrate-with-amazon-bedrock/'] ### ステップ2. Python仮想環境をセットアップする {#step-2-set-up-the-python-virtual-environment} -1. `demo.py`という名前の Python ファイルを作成します。 +1. `demo.py`という名前の Python ファイルを作成します。 ```shell touch demo.py ``` -2. 依存関係を管理するための仮想環境を作成してアクティブ化する： +2. 依存関係を管理するための仮想環境を作成してアクティブ化する： ```shell python3 -m venv env source env/bin/activate # On Windows, use env\Scripts\activate ``` -3. 必要な依存関係をインストールします。 +3. 必要な依存関係をインストールします。 ```shell pip install SQLAlchemy==2.0.30 PyMySQL==1.1.0 tidb-vector==0.0.9 pydantic==2.7.1 boto3 @@ -151,10 +151,10 @@ Base = declarative_base() Amazon Bedrock ランタイム クライアントは、次のパラメーターを受け入れる`invoke_model` API を提供します。 -- `modelId` : Amazon Bedrock で利用可能な基盤モデルのモデル ID。 -- `accept` : 入力リクエストのタイプ。 -- `contentType` : 入力のコンテンツタイプ。 -- `body` : プロンプトと設定で構成される JSON 文字列ペイロード。 +- `modelId` : Amazon Bedrock で利用可能な基盤モデルのモデル ID。 +- `accept` : 入力リクエストのタイプ。 +- `contentType` : 入力のコンテンツタイプ。 +- `body` : プロンプトと設定で構成される JSON 文字列ペイロード。 `demo.py`に次のコードを追加して、 `invoke_model` API を呼び出し、Amazon Titan Text Embeddings を使用してテキスト埋め込みを生成し、Meta Llama 3 から応答を取得します。 @@ -261,7 +261,7 @@ def save_entities_with_embedding(session, contents): ### ステップ8．アプリケーションを実行する {#step-8-run-the-application} -1. `demo.py`に、データベースセッションを確立し、埋め込みを TiDB に保存し、例となる質問 (「TiDB とは何ですか？」など) を尋ね、モデルから結果を生成するための以下のコードを追加します。 +1. `demo.py`に、データベースセッションを確立し、埋め込みを TiDB に保存し、例となる質問 (「TiDB とは何ですか？」など) を尋ね、モデルから結果を生成するための以下のコードを追加します。 ```python if __name__ == "__main__": @@ -288,7 +288,7 @@ def save_entities_with_embedding(session, contents): print(f"Generated answer: {result}") ``` -2. `demo.py`へのすべての変更を保存し、スクリプトを実行します。 +2. `demo.py`へのすべての変更を保存し、スクリプトを実行します。 ```shell python3 demo.py @@ -320,5 +320,5 @@ def save_entities_with_embedding(session, contents): ## 関連項目 {#see-also} -- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) -- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) +- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) +- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) diff --git a/ai/integrations/vector-search-integrate-with-django-orm.md b/ai/integrations/vector-search-integrate-with-django-orm.md index e0b148cc6ce2e..37b619b651c71 100644 --- a/ai/integrations/vector-search-integrate-with-django-orm.md +++ b/ai/integrations/vector-search-integrate-with-django-orm.md @@ -10,21 +10,21 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-django-orm/','/ja/tidb/d > **Note:** > -> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、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以降を推奨）。 +> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、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} このチュートリアルを完了するには、以下が必要です。 -- [Python 3.8以降](https://www.python.org/downloads/)がインストールされていること。 -- [Git](https://git-scm.com/downloads)がインストールされていること。 -- TiDBクラスタ。 +- [Python 3.8以降](https://www.python.org/downloads/)がインストールされていること。 +- [Git](https://git-scm.com/downloads)がインストールされていること。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## サンプルアプリを実行します {#run-the-sample-app} @@ -81,38 +81,38 @@ mysqlclientのインストールで問題が発生した場合は、mysqlclient TiDB Cloud Starterインスタンスの場合、接続文字列を取得し、環境変数を設定するには、以下の手順に従ってください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. 接続ダイアログから接続パラメータをコピーしてください。 +4. 接続ダイアログから接続パラメータをコピーしてください。 > **Tip:** > > まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 -5. Python プロジェクトのルートディレクトリに`.env`ファイルを作成し、接続パラメータを対応する環境変数に貼り付けます。 +5. Python プロジェクトのルートディレクトリに`.env`ファイルを作成し、接続パラメータを対応する環境変数に貼り付けます。 - - `TIDB_HOST` : TiDBクラスタのホスト。 - - `TIDB_PORT` : TiDB クラスタのポート。 - - `TIDB_USERNAME` : TiDBに接続するためのユーザー名。 - - `TIDB_PASSWORD` : TiDBに接続するためのパスワード。 - - `TIDB_DATABASE` : 接続するデータベース名。 - - `TIDB_CA_PATH` : ルート証明書ファイルへのパス。 + - `TIDB_HOST` : TiDBクラスタのホスト。 + - `TIDB_PORT` : TiDB クラスタのポート。 + - `TIDB_USERNAME` : TiDBに接続するためのユーザー名。 + - `TIDB_PASSWORD` : TiDBに接続するためのパスワード。 + - `TIDB_DATABASE` : 接続するデータベース名。 + - `TIDB_CA_PATH` : ルート証明書ファイルへのパス。 以下はmacOSの例です。 @@ -142,11 +142,11 @@ TiDBをローカルマシンで実行している場合、 `TIDB_HOST`はデフ 各パラメータの説明は以下のとおりです。 -- `TIDB_HOST` : TiDB Self-Managed クラスタのホスト。 -- `TIDB_PORT` : TiDB Self-Managed クラスタのポート。 -- `TIDB_USERNAME` : TiDB Self-Managed クラスタに接続するためのユーザー名。 -- `TIDB_PASSWORD` : TiDB Self-Managed クラスタに接続するためのパスワード。 -- `TIDB_DATABASE` : 接続するデータベースの名前。 +- `TIDB_HOST` : TiDB Self-Managed クラスタのホスト。 +- `TIDB_PORT` : TiDB Self-Managed クラスタのポート。 +- `TIDB_USERNAME` : TiDB Self-Managed クラスタに接続するためのユーザー名。 +- `TIDB_PASSWORD` : TiDB Self-Managed クラスタに接続するためのパスワード。 +- `TIDB_DATABASE` : 接続するデータベースの名前。 @@ -236,10 +236,10 @@ Document.objects.create(content="tree", embedding=[1, 0, 0]) TiDB Vectorは以下の距離関数をサポートしています。 -- `L1Distance` -- `L2Distance` -- `CosineDistance` -- `NegativeInnerProduct` +- `L1Distance` +- `L2Distance` +- `CosineDistance` +- `NegativeInnerProduct` コサイン距離関数に基づいて、クエリベクトル`[1, 2, 3]`に意味的に最も近い上位 3 つのドキュメントを検索します。 @@ -261,5 +261,5 @@ results = Document.objects.annotate( ## 関連項目 {#see-also} -- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) -- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) +- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) +- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) diff --git a/ai/integrations/vector-search-integrate-with-jinaai-embedding.md b/ai/integrations/vector-search-integrate-with-jinaai-embedding.md index f5e0393b52cf7..ba2b26cb86a9a 100644 --- a/ai/integrations/vector-search-integrate-with-jinaai-embedding.md +++ b/ai/integrations/vector-search-integrate-with-jinaai-embedding.md @@ -10,21 +10,21 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-jinaai-embedding/','/ja/ > **Note:** > -> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、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以降を推奨）。 +> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、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} このチュートリアルを完了するには、以下が必要です。 -- [Python 3.8以降](https://www.python.org/downloads/)がインストールされていること。 -- [Git](https://git-scm.com/downloads)がインストールされていること。 -- TiDBクラスタ。 +- [Python 3.8以降](https://www.python.org/downloads/)がインストールされていること。 +- [Git](https://git-scm.com/downloads)がインストールされていること。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## サンプルアプリを実行します {#run-the-sample-app} @@ -65,31 +65,31 @@ Jina AIのAPIキーを[Jina AI 埋め込み API](https://jina.ai/embeddings/)ペ TiDB Cloud Starterインスタンスの場合、接続文字列を取得し、環境変数を設定するには、以下の手順に従ってください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`SQLAlchemy`に設定されています。 + - **Connect With**は`SQLAlchemy`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **PyMySQL**タブに切り替えて、**コピー**アイコンをクリックして接続文字列をコピーします。 +4. **PyMySQL**タブに切り替えて、**コピー**アイコンをクリックして接続文字列をコピーします。 > **Tip:** > > まだパスワードを設定していない場合は、 **Create password**をクリックしてランダムなパスワードを生成してください。 -5. ターミナルで Jina AI API キーと TiDB 接続文字列を環境変数として設定するか、以下の環境変数を含む`.env`ファイルを作成してください。 +5. ターミナルで Jina AI API キーと TiDB 接続文字列を環境変数として設定するか、以下の環境変数を含む`.env`ファイルを作成してください。 ```dotenv JINAAI_API_KEY="****" @@ -117,11 +117,11 @@ export TIDB_DATABASE_URL="mysql+pymysql://:@:/` : TiDBに接続するためのユーザー名。 -- `` : TiDBに接続するためのパスワード。 -- `` : TiDBクラスタのホスト。 -- `` : TiDB クラスタのポート。 -- `` : 接続するデータベースの名前。 +- `` : TiDBに接続するためのユーザー名。 +- `` : TiDBに接続するためのパスワード。 +- `` : TiDBクラスタのホスト。 +- `` : TiDB クラスタのポート。 +- `` : 接続するデータベースの名前。 @@ -220,8 +220,8 @@ class Document(Base): > **Note:** > -> - ベクトル列の次元は、埋め込みモデルによって生成される埋め込みの次元と一致していなければなりません。 -> - この例では、 `jina-embeddings-v2-base-en`モデルによって生成される埋め込みの次元は`768`です。 +> - ベクトル列の次元は、埋め込みモデルによって生成される埋め込みの次元と一致していなければなりません。 +> - この例では、 `jina-embeddings-v2-base-en`モデルによって生成される埋め込みの次元は`768`です。 ### Jina AIで埋め込みを作成し、TiDBに保存します。 {#create-embeddings-with-jina-ai-and-store-in-tidb} @@ -276,5 +276,5 @@ with Session(engine) as session: ## 関連項目 {#see-also} -- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) -- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) +- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) +- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) diff --git a/ai/integrations/vector-search-integrate-with-langchain.md b/ai/integrations/vector-search-integrate-with-langchain.md index d728903da467a..6c43bc9d6b58a 100644 --- a/ai/integrations/vector-search-integrate-with-langchain.md +++ b/ai/integrations/vector-search-integrate-with-langchain.md @@ -10,8 +10,8 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-langchain/','/ja/tidb/de > **Note:** > -> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)と[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で利用できます。TiDB Self-Managedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)と[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で利用できます。TiDB Self-Managedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 > **Tip** > @@ -21,15 +21,15 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-langchain/','/ja/tidb/de このチュートリアルを完了するには、以下が必要です。 -- [Python 3.8以降](https://www.python.org/downloads/)がインストールされていること。 -- [Jupyter Notebook](https://jupyter.org/install)がインストールされていること。 -- [Git](https://git-scm.com/downloads)がインストールされていること。 -- TiDBクラスタ。 +- [Python 3.8以降](https://www.python.org/downloads/)がインストールされていること。 +- [Jupyter Notebook](https://jupyter.org/install)がインストールされていること。 +- [Git](https://git-scm.com/downloads)がインストールされていること。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## さあ始めましょう {#get-started} @@ -72,24 +72,24 @@ from langchain_text_splitters import CharacterTextSplitter TiDB Cloud Starterインスタンスの場合、接続文字列を取得し、環境変数を設定するには、以下の手順に従ってください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 - - **Connect With**は`SQLAlchemy`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - **Connection Type**は`Public`に設定されています。 + - **Branch**は`main`に設定されています。 + - **Connect With**は`SQLAlchemy`に設定されています。 + - お使いの環境に合った**Operating System**を選択してください。 -4. **PyMySQL**タブをクリックして、接続文字列をコピーしてください。 +4. **PyMySQL**タブをクリックして、接続文字列をコピーしてください。 > **Tip:** > > まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 -5. 環境変数を設定します。 +5. 環境変数を設定します。 このドキュメントでは、埋め込みモデルプロバイダーとして[OpenAI](https://platform.openai.com/docs/introduction)を使用します。この手順では、前の手順で取得した接続文字列と[OpenAI APIキー](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)を指定する必要があります。 @@ -134,11 +134,11 @@ TiDBクラスタに合わせて接続パラメータの値を変更する必要 各パラメータの説明は以下のとおりです。 -- `` : TiDBに接続するためのユーザー名。 -- `` : TiDBに接続するためのパスワード。 -- `` : TiDBクラスタのホスト。 -- `` : TiDB クラスタのポート。 -- `` : 接続するデータベースの名前。 +- `` : TiDBに接続するためのユーザー名。 +- `` : TiDBに接続するためのパスワード。 +- `` : TiDBクラスタのホスト。 +- `` : TiDB クラスタのポート。 +- `` : 接続するデータベースの名前。 @@ -341,9 +341,9 @@ vector_store.drop_vectorstore() TiDBベクトルストア内の各ドキュメントには、JSONオブジェクト内のキーと値のペアとして構造化されたメタデータを関連付けることができます。キーは常に文字列であり、値は以下のいずれかの型になります。 -- 文字列 -- 数値：整数または浮動小数点 -- ブール値: `true`または`false` +- 文字列 +- 数値：整数または浮動小数点 +- ブール値: `true`または`false` 例えば、以下は有効なメタデータペイロードの例です。 @@ -358,16 +358,16 @@ TiDBベクトルストア内の各ドキュメントには、JSONオブジェク 利用可能なフィルターは以下のとおりです。 -- `$or` : 指定された条件のいずれかに一致するベクトルを選択します。 -- `$and` : 指定されたすべての条件に一致するベクトルを選択します。 -- `$eq` : 指定された値と等しい。 -- `$ne` : 指定された値と等しくありません。 -- `$gt` : 指定された値より大きい。 -- `$gte` : 指定された値以上。 -- `$lt` : 指定された値より小さい。 -- `$lte` : 指定された値以下。 -- `$in` : 指定された値の配列内。 -- `$nin` : 指定された値の配列に含まれていません。 +- `$or` : 指定された条件のいずれかに一致するベクトルを選択します。 +- `$and` : 指定されたすべての条件に一致するベクトルを選択します。 +- `$eq` : 指定された値と等しい。 +- `$ne` : 指定された値と等しくありません。 +- `$gt` : 指定された値より大きい。 +- `$gte` : 指定された値以上。 +- `$lt` : 指定された値より小さい。 +- `$lte` : 指定された値以下。 +- `$in` : 指定された値の配列内。 +- `$nin` : 指定された値の配列に含まれていません。 文書のメタデータが以下のようになっている場合： @@ -465,8 +465,8 @@ TiDB Vector offers advanced, high-speed vector processing capabilities, enhancin このプロセスは主に2つのステップから構成されます。 -1. 空港レビュー全体を対象に意味検索を行い、希望する設備に一致する空港コードを特定します。 -2. SQLクエリを実行してこれらのコードをルート情報と統合し、ユーザーの好みに合致する航空会社と目的地を強調表示します。 +1. 空港レビュー全体を対象に意味検索を行い、希望する設備に一致する空港コードを特定します。 +2. SQLクエリを実行してこれらのコードをルート情報と統合し、ユーザーの好みに合致する航空会社と目的地を強調表示します。 ### データの準備 {#prepare-data} @@ -630,5 +630,5 @@ vector_store.tidb_vector_client.execute("DROP TABLE airplan_routes") ## 関連項目 {#see-also} -- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) -- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) +- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) +- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) diff --git a/ai/integrations/vector-search-integrate-with-llamaindex.md b/ai/integrations/vector-search-integrate-with-llamaindex.md index 2eb3963d6706a..1b4ea7cb26da7 100644 --- a/ai/integrations/vector-search-integrate-with-llamaindex.md +++ b/ai/integrations/vector-search-integrate-with-llamaindex.md @@ -10,8 +10,8 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-llamaindex/','/ja/tidb/d > **Note:** > -> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)と[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で利用できます。TiDB Self-Managedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)と[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で利用できます。TiDB Self-Managedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 > **Tip** > @@ -21,15 +21,15 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-llamaindex/','/ja/tidb/d このチュートリアルを完了するには、以下が必要です。 -- [Python 3.8以降](https://www.python.org/downloads/)がインストールされていること。 -- [Jupyter Notebook](https://jupyter.org/install)がインストールされていること。 -- [Git](https://git-scm.com/downloads)がインストールされていること。 -- TiDBクラスタ。 +- [Python 3.8以降](https://www.python.org/downloads/)がインストールされていること。 +- [Jupyter Notebook](https://jupyter.org/install)がインストールされていること。 +- [Git](https://git-scm.com/downloads)がインストールされていること。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## さあ始めましょう {#get-started} @@ -71,24 +71,24 @@ from llama_index.vector_stores.tidbvector import TiDBVectorStore TiDB Cloud Starterインスタンスの場合、接続文字列を取得し、環境変数を設定するには、以下の手順に従ってください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 - - **Connect With**は`SQLAlchemy`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - **Connection Type**は`Public`に設定されています。 + - **Branch**は`main`に設定されています。 + - **Connect With**は`SQLAlchemy`に設定されています。 + - お使いの環境に合った**Operating System**を選択してください。 -4. **PyMySQL**タブをクリックして、接続文字列をコピーしてください。 +4. **PyMySQL**タブをクリックして、接続文字列をコピーしてください。 > **Tip:** > > まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 -5. 環境変数を設定します。 +5. 環境変数を設定します。 このドキュメントでは、埋め込みモデルプロバイダーとして[OpenAI](https://platform.openai.com/docs/introduction)を使用します。この手順では、前の手順で取得した接続文字列と[OpenAI APIキー](https://platform.openai.com/docs/quickstart/step-2-set-up-your-api-key)を指定する必要があります。 @@ -133,11 +133,11 @@ TiDBクラスタに合わせて、接続文字列のパラメータを変更す 各パラメータの説明は以下のとおりです。 -- `` : TiDBに接続するためのユーザー名。 -- `` : TiDBに接続するためのパスワード。 -- `` : TiDBクラスタのホスト。 -- `` : TiDB クラスタのポート。 -- `` : 接続するデータベースの名前。 +- `` : TiDBに接続するためのユーザー名。 +- `` : TiDBに接続するためのパスワード。 +- `` : TiDBクラスタのホスト。 +- `` : TiDB クラスタのポート。 +- `` : 接続するデータベースの名前。 @@ -312,5 +312,5 @@ Empty Response ## 関連項目 {#see-also} -- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) -- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) +- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) +- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) diff --git a/ai/integrations/vector-search-integrate-with-peewee.md b/ai/integrations/vector-search-integrate-with-peewee.md index 6b6832be9f216..4c782ae6906e4 100644 --- a/ai/integrations/vector-search-integrate-with-peewee.md +++ b/ai/integrations/vector-search-integrate-with-peewee.md @@ -10,21 +10,21 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-peewee/','/ja/tidb/dev/v > **Note:** > -> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)と[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で利用できます。TiDB Self-Managedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)と[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で利用できます。TiDB Self-Managedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## 前提条件 {#prerequisites} このチュートリアルを完了するには、以下が必要です。 -- [Python 3.8以降](https://www.python.org/downloads/)がインストールされていること。 -- [Git](https://git-scm.com/downloads)がインストールされていること。 -- TiDBクラスタ。 +- [Python 3.8以降](https://www.python.org/downloads/)がインストールされていること。 +- [Git](https://git-scm.com/downloads)がインストールされていること。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## サンプルアプリを実行します {#run-the-sample-app} @@ -71,38 +71,38 @@ pip install peewee pymysql python-dotenv tidb-vector TiDB Cloud Starterインスタンスの場合、接続文字列を取得し、環境変数を設定するには、以下の手順に従ってください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. 接続ダイアログから接続パラメータをコピーしてください。 +4. 接続ダイアログから接続パラメータをコピーしてください。 > **Tip:** > > まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 -5. Python プロジェクトのルートディレクトリに`.env`ファイルを作成し、接続パラメータを対応する環境変数に貼り付けます。 +5. Python プロジェクトのルートディレクトリに`.env`ファイルを作成し、接続パラメータを対応する環境変数に貼り付けます。 - - `TIDB_HOST` : TiDB Cloud Starterインスタンスのホスト。 - - `TIDB_PORT` : TiDB Cloud Starterインスタンスのポート。 - - `TIDB_USERNAME` : TiDBに接続するためのユーザー名。 - - `TIDB_PASSWORD` : TiDBに接続するためのパスワード。 - - `TIDB_DATABASE` : 接続するデータベース名。 - - `TIDB_CA_PATH` : ルート証明書ファイルへのパス。 + - `TIDB_HOST` : TiDB Cloud Starterインスタンスのホスト。 + - `TIDB_PORT` : TiDB Cloud Starterインスタンスのポート。 + - `TIDB_USERNAME` : TiDBに接続するためのユーザー名。 + - `TIDB_PASSWORD` : TiDBに接続するためのパスワード。 + - `TIDB_DATABASE` : 接続するデータベース名。 + - `TIDB_CA_PATH` : ルート証明書ファイルへのパス。 以下はmacOSの例です。 @@ -132,11 +132,11 @@ TiDBをローカルマシンで実行している場合、 `TIDB_HOST`はデフ 各パラメータの説明は以下のとおりです。 -- `TIDB_HOST` : TiDB Self-Managed クラスタのホスト。 -- `TIDB_PORT` : TiDB Self-Managed クラスタのポート。 -- `TIDB_USERNAME` : TiDB Self-Managed クラスタに接続するためのユーザー名。 -- `TIDB_PASSWORD` : TiDB Self-Managed クラスタに接続するためのパスワード。 -- `TIDB_DATABASE` : 接続するデータベースの名前。 +- `TIDB_HOST` : TiDB Self-Managed クラスタのホスト。 +- `TIDB_PORT` : TiDB Self-Managed クラスタのポート。 +- `TIDB_USERNAME` : TiDB Self-Managed クラスタに接続するためのユーザー名。 +- `TIDB_PASSWORD` : TiDB Self-Managed クラスタに接続するためのパスワード。 +- `TIDB_DATABASE` : 接続するデータベースの名前。 @@ -251,5 +251,5 @@ results = Document.select(Document, distance).where(distance_expression < 0.2).o ## 関連項目 {#see-also} -- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) -- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) +- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) +- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) diff --git a/ai/integrations/vector-search-integrate-with-sqlalchemy.md b/ai/integrations/vector-search-integrate-with-sqlalchemy.md index b1c14b8e962aa..a5343c540d9bc 100644 --- a/ai/integrations/vector-search-integrate-with-sqlalchemy.md +++ b/ai/integrations/vector-search-integrate-with-sqlalchemy.md @@ -10,21 +10,21 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-sqlalchemy/','/ja/tidb/d > **Note:** > -> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、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以降を推奨）。 +> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、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} このチュートリアルを完了するには、以下が必要です。 -- [Python 3.8以降](https://www.python.org/downloads/)がインストールされていること。 -- [Git](https://git-scm.com/downloads)がインストールされていること。 -- TiDBクラスタ。 +- [Python 3.8以降](https://www.python.org/downloads/)がインストールされていること。 +- [Git](https://git-scm.com/downloads)がインストールされていること。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## サンプルアプリを実行します {#run-the-sample-app} @@ -71,31 +71,31 @@ pip install pymysql python-dotenv sqlalchemy tidb-vector TiDB Cloud Starterインスタンスの場合、接続文字列を取得し、環境変数を設定するには、以下の手順に従ってください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用の環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用の環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`SQLAlchemy`に設定されています。 + - **Connect With**は`SQLAlchemy`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **PyMySQL**タブをクリックして、接続文字列をコピーしてください。 +4. **PyMySQL**タブをクリックして、接続文字列をコピーしてください。 > **Tip:** > > まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 -5. Python プロジェクトのルートディレクトリに`.env`ファイルを作成し、接続文字列を貼り付けます。 +5. Python プロジェクトのルートディレクトリに`.env`ファイルを作成し、接続文字列を貼り付けます。 以下はmacOSの例です。 @@ -117,11 +117,11 @@ TiDBをローカルマシンで実行している場合、 ``はデフォ 各パラメータの説明は以下のとおりです。 -- `` : TiDBに接続するためのユーザー名。 -- `` : TiDBに接続するためのパスワード。 -- `` : TiDBクラスタのホスト。 -- `` : TiDB クラスタのポート。 -- `` : 接続するデータベースの名前。 +- `` : TiDBに接続するためのユーザー名。 +- `` : TiDBに接続するためのパスワード。 +- `` : TiDBクラスタのホスト。 +- `` : TiDB クラスタのポート。 +- `` : 接続するデータベースの名前。 @@ -222,5 +222,5 @@ with Session(engine) as session: ## 関連項目 {#see-also} -- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) -- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) +- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) +- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) diff --git a/ai/quickstart-via-python.md b/ai/quickstart-via-python.md index dc59d17fc985c..43a7cce27a29e 100644 --- a/ai/quickstart-via-python.md +++ b/ai/quickstart-via-python.md @@ -10,19 +10,19 @@ aliases: ['/ja/tidb/stable/vector-search-get-started-using-python/','/ja/tidb/de このドキュメントに従うことで、以下のことを学ぶことができます。 -- TiDB Python SDKを使用してTiDBに接続します。 -- 一般的な埋め込みモデルを使用してテキスト埋め込みを生成します。 -- ベクトルをTiDBテーブルに格納します。 -- ベクトル類似度を用いて意味検索を実行する。 +- TiDB Python SDKを使用してTiDBに接続します。 +- 一般的な埋め込みモデルを使用してテキスト埋め込みを生成します。 +- ベクトルをTiDBテーブルに格納します。 +- ベクトル類似度を用いて意味検索を実行する。 > **Note:** > -> - ベクトル検索機能はパブリックプレビューであり、予告なく変更される場合があります。バグを発見した場合は、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以降を推奨）。 +> - ベクトル検索機能はパブリックプレビューであり、予告なく変更される場合があります。バグを発見した場合は、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} -- [tidbcloud.com](https://tidbcloud.com/)にアクセスしてTiDB Cloud Starterインスタンスを無料で作成するか、 [TiUP Playground](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb/#deploy-a-local-test-cluster)を使用してローカルテスト用の TiDB Self-Managedクラスタをデプロイします。 +- [tidbcloud.com](https://tidbcloud.com/)にアクセスしてTiDB Cloud Starterインスタンスを無料で作成するか、 [TiUP Playground](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb/#deploy-a-local-test-cluster)を使用してローカルテスト用の TiDB Self-Managedクラスタをデプロイします。 ## インストール {#installation} @@ -47,8 +47,8 @@ pip install "pytidb[models]" これらの接続パラメータは[TiDB Cloudコンソール](https://tidbcloud.com/tidbs)から取得できます。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、次に、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックします。接続ダイアログが表示され、接続パラメータが表示されます。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、次に、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 +2. 右上隅の**Connect**をクリックします。接続ダイアログが表示され、接続パラメータが表示されます。 例えば、接続パラメータが以下のように表示される場合： @@ -145,10 +145,10 @@ text_embed = EmbeddingFunction( 例として、 `chunks`という名前のテーブルを作成し、以下の列を追加します。 -- `id` (int): チャンクのID。 -- `text` (テキスト): チャンクのテキストコンテンツ。 -- `text_vec` (ベクトル): テキストのベクトル埋め込み。 -- `user_id` (int): チャンクを作成したユーザーのID。 +- `id` (int): チャンクのID。 +- `text` (テキスト): チャンクのテキストコンテンツ。 +- `text_vec` (ベクトル): テキストのベクトル埋め込み。 +- `user_id` (int): チャンクを作成したユーザーのID。 ```python hl_lines="6" from pytidb.schema import TableModel, Field, VectorField @@ -242,4 +242,4 @@ client.drop_table("chunks") ## 次のステップ {#next-steps} -- TiDB の[ベクトル検索](/ai/guides/vector-search.md)、 [全文検索](/ai/guides/vector-search-full-text-search-python.md)、 [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md)の詳細については、こちらをご覧ください。 +- TiDB の[ベクトル検索](/ai/guides/vector-search.md)、 [全文検索](/ai/guides/vector-search-full-text-search-python.md)、 [ハイブリッド検索](/ai/guides/vector-search-hybrid-search.md)の詳細については、こちらをご覧ください。 diff --git a/ai/quickstart-via-sql.md b/ai/quickstart-via-sql.md index bea381a334ecb..917c41ff7f894 100644 --- a/ai/quickstart-via-sql.md +++ b/ai/quickstart-via-sql.md @@ -10,27 +10,27 @@ TiDB は、MySQL 構文を拡張して[ベクトル検索](/ai/concepts/vector-s このドキュメントでは、SQL ステートメントだけを使用して TiDB Vector Search を開始する方法を説明します。 [MySQLコマンドラインクライアント](https://dev.mysql.com/doc/refman/8.4/en/mysql.html)を使用して、次の操作を実行する方法を学習します。 -- TiDBに接続します。 -- ベクトルテーブルを作成します。 -- ベクトル埋め込みを保存する。 -- ベクトル検索クエリを実行します。 +- TiDBに接続します。 +- ベクトルテーブルを作成します。 +- ベクトル埋め込みを保存する。 +- ベクトル検索クエリを実行します。 > **Note:** > -> - ベクトル検索機能はパブリックプレビューであり、予告なく変更される場合があります。バグを発見した場合は、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以降を推奨）。 +> - ベクトル検索機能はパブリックプレビューであり、予告なく変更される場合があります。バグを発見した場合は、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} この文書の手順を完了するには、以下が必要です。 -- [MySQLコマンドラインクライアント](https://dev.mysql.com/doc/refman/8.4/en/mysql.html)(MySQL CLI)がマシンにインストールされていること。 -- TiDBクラスタ。 +- [MySQLコマンドラインクライアント](https://dev.mysql.com/doc/refman/8.4/en/mysql.html)(MySQL CLI)がマシンにインストールされていること。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## さあ始めましょう {#get-started} @@ -41,15 +41,15 @@ TiDB は、MySQL 構文を拡張して[ベクトル検索](/ai/concepts/vector-s
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、次に、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、次に、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connect With**ドロップダウンリストから**MySQL CLI**を選択し、 **Connection Type**のデフォルト設定を**Public**のままにします。 +3. 接続ダイアログで、 **Connect With**ドロップダウンリストから**MySQL CLI**を選択し、 **Connection Type**のデフォルト設定を**Public**のままにします。 -4. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 +4. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 -5. 接続コマンドをコピーしてターミナルに貼り付けてください。以下はmacOSの例です。 +5. 接続コマンドをコピーしてターミナルに貼り付けてください。以下はmacOSの例です。 ```bash mysql -u '.root' -h '' -P 4000 -D 'test' --ssl-mode=VERIFY_IDENTITY --ssl-ca=/etc/ssl/cert.pem -p'' @@ -173,5 +173,5 @@ LIMIT 3; ## 参照 {#see-also} -- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) -- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) +- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) +- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) diff --git a/ai/reference/vector-search-changelogs.md b/ai/reference/vector-search-changelogs.md index b9e2e4cd054f6..da951231245d8 100644 --- a/ai/reference/vector-search-changelogs.md +++ b/ai/reference/vector-search-changelogs.md @@ -8,12 +8,12 @@ aliases: ['/ja/tidbcloud/vector-search-changelogs/'] ## 2025年7月15日 {#july-15-2025} -- TiDB Vector Search (ベータ版) が、 TiDB Cloud Dedicated (TiDB >= v8.4) クラスターで利用できるようになりました。 +- TiDB Vector Search (ベータ版) が、 TiDB Cloud Dedicated (TiDB >= v8.4) クラスターで利用できるようになりました。 ## 2024年6月25日 {#june-25-2024} -- TiDB Vector Search (ベータ版) が、すべてのリージョンのすべてのユーザー向けにTiDB Cloud Starter クラスターで利用できるようになりました。 +- TiDB Vector Search (ベータ版) が、すべてのリージョンのすべてのユーザー向けにTiDB Cloud Starter クラスターで利用できるようになりました。 ## 2024年4月1日 {#april-1-2024} -- TiDB Vector Search (ベータ版) が、招待されたユーザー向けに EU リージョンのTiDB Cloud Starter クラスターで利用できるようになりました。 +- TiDB Vector Search (ベータ版) が、招待されたユーザー向けに EU リージョンのTiDB Cloud Starter クラスターで利用できるようになりました。 diff --git a/ai/reference/vector-search-data-types.md b/ai/reference/vector-search-data-types.md index cb5a3ef8cf9dd..9aa73a459e3f2 100644 --- a/ai/reference/vector-search-data-types.md +++ b/ai/reference/vector-search-data-types.md @@ -10,19 +10,19 @@ aliases: ['/ja/tidb/stable/vector-search-data-types/','/ja/tidbcloud/vector-sear > **Note:** > -> - ベクトルデータ型はパブリックプレビューであり、予告なく変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告を行ってください。 -> - ベクトルデータ型は[TiDB Self-Managed](/overview.md) および [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で使用できます。TiDB Self-Managed の場合、TiDB バージョンは v8.4.0 以降である必要があります（v8.5.0 以降を推奨）。 +> - ベクトルデータ型はパブリックプレビューであり、予告なく変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告を行ってください。 +> - ベクトルデータ型は[TiDB Self-Managed](/overview.md) および [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で使用できます。TiDB Self-Managed の場合、TiDB バージョンは v8.4.0 以降である必要があります（v8.5.0 以降を推奨）。 現在、次のベクトル データ型が利用可能です。 -- `VECTOR` : 任意の次元の単精度浮動小数点数のシーケンス。 -- `VECTOR(D)` : 固定次元`D`を持つ単精度浮動小数点数のシーケンス。 +- `VECTOR` : 任意の次元の単精度浮動小数点数のシーケンス。 +- `VECTOR(D)` : 固定次元`D`を持つ単精度浮動小数点数のシーケンス。 ベクトル データ型を使用すると、 [`JSON`](/data-type-json.md)型を使用する場合に比べて次の利点があります。 -- ベクトル インデックスのサポート: ベクトルの検索を高速化するために[ベクトル検索インデックス](/ai/reference/vector-search-index.md)を構築できます。 -- 次元の強制: 異なる次元のベクトルの挿入を禁止する次元を指定できます。 -- 最適化されたストレージ形式: ベクトル データ型はベクトル データの処理に最適化されており、 `JSON`型と比較して優れたスペース効率とパフォーマンスを実現します。 +- ベクトル インデックスのサポート: ベクトルの検索を高速化するために[ベクトル検索インデックス](/ai/reference/vector-search-index.md)を構築できます。 +- 次元の強制: 異なる次元のベクトルの挿入を禁止する次元を指定できます。 +- 最適化されたストレージ形式: ベクトル データ型はベクトル データの処理に最適化されており、 `JSON`型と比較して優れたスペース効率とパフォーマンスを実現します。 ## 構文 {#syntax} @@ -85,19 +85,19 @@ INSERT INTO vector_table VALUES (2, '[0.3, 0.5]'); -- 2 dimensions vector, ベクトルデータ型は要素ごとに数値的に比較されます。例: -- `[1] < [12]` -- `[1,2,3] < [1,2,5]` -- `[1,2,3] = [1,2,3]` -- `[2,2,3] > [1,2,3]` +- `[1] < [12]` +- `[1,2,3] < [1,2,5]` +- `[1,2,3] = [1,2,3]` +- `[2,2,3] > [1,2,3]` 異なる次元を持つ 2 つのベクトルは、次の規則に従って辞書式比較を使用して比較されます。 -- 2 つのベクトルは最初から要素ごとに比較され、各要素は数値的に比較されます。 -- 最初の不一致要素によって、どのベクトルが辞書式に他のベクトルより*小さい*か*大きいかが*決まります。 -- あるベクトルが別のベクトルの接頭辞である場合、短いベクトルは辞書順でもう一方より*小さく*なります。例えば、 `[1,2,3] < [1,2,3,0]` 。 -- 同じ長さで同一の要素を持つベクトルは辞書的に*等しい*です。 -- 空ベクトルは、辞書順で空でないベクトルよりも*小さい*。例えば、 `[] < [1]` 。 -- 2 つの空のベクトルは辞書的に*等しい*です。 +- 2 つのベクトルは最初から要素ごとに比較され、各要素は数値的に比較されます。 +- 最初の不一致要素によって、どのベクトルが辞書式に他のベクトルより*小さい*か*大きいかが*決まります。 +- あるベクトルが別のベクトルの接頭辞である場合、短いベクトルは辞書順でもう一方より*小さく*なります。例えば、 `[1,2,3] < [1,2,3,0]` 。 +- 同じ長さで同一の要素を持つベクトルは辞書的に*等しい*です。 +- 空ベクトルは、辞書順で空でないベクトルよりも*小さい*。例えば、 `[] < [1]` 。 +- 2 つの空のベクトルは辞書的に*等しい*です。 ベクトル定数を比較する場合は、文字列値に基づく比較を避けるために、文字列からベクトルへの[明示的なキャスト](#cast)実行を検討してください。 @@ -154,10 +154,10 @@ ERROR 1105 (HY000): vectors have different dimensions: 1 and 3 Vector と String 間のキャストを行うには、次の関数を使用します。 -- `CAST(... AS VECTOR)` : 文字列 ⇒ ベクトル -- `CAST(... AS CHAR)` : ベクトル ⇒ 文字列 -- `VEC_FROM_TEXT` : 文字列 ⇒ ベクトル -- `VEC_AS_TEXT` : ベクトル ⇒ 文字列 +- `CAST(... AS VECTOR)` : 文字列 ⇒ ベクトル +- `CAST(... AS CHAR)` : ベクトル ⇒ 文字列 +- `VEC_FROM_TEXT` : 文字列 ⇒ ベクトル +- `VEC_AS_TEXT` : ベクトル ⇒ 文字列 ユーザビリティを向上させるため、ベクトル相関距離関数など、ベクトルデータ型のみをサポートする関数を呼び出す場合は、形式に準拠した文字列を渡すこともできます。この場合、TiDB は自動的に暗黙的なキャストを実行します。 @@ -243,6 +243,6 @@ Vector と String 間のキャストを行うには、次の関数を使用し ## 参照 {#see-also} -- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) -- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) -- [ベクトル検索のパフォーマンスを向上させる](/ai/reference/vector-search-improve-performance.md) +- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) +- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) +- [ベクトル検索のパフォーマンスを向上させる](/ai/reference/vector-search-improve-performance.md) diff --git a/ai/reference/vector-search-functions-and-operators.md b/ai/reference/vector-search-functions-and-operators.md index 06e8f70e07621..36a6d1aebc760 100644 --- a/ai/reference/vector-search-functions-and-operators.md +++ b/ai/reference/vector-search-functions-and-operators.md @@ -10,8 +10,8 @@ aliases: ['/ja/tidb/stable/vector-search-functions-and-operators/','/ja/tidbclou > **Note:** > -> - ベクトル関数と演算子はパブリックプレビューであり、予告なく変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告を行ってください。 -> - ベクトルデータ型は、 [TiDB Self-Managed](/overview.md) および [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) で使用できます。TiDB Self-Managedの場合、TiDBバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル関数と演算子はパブリックプレビューであり、予告なく変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告を行ってください。 +> - ベクトルデータ型は、 [TiDB Self-Managed](/overview.md) および [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) で使用できます。TiDB Self-Managedの場合、TiDBバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## ベクトル関数 {#vector-functions} @@ -314,4 +314,4 @@ SELECT VEC_AS_TEXT('[1.000, 2.5]'); ## 参照 {#see-also} -- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) +- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) diff --git a/ai/reference/vector-search-improve-performance.md b/ai/reference/vector-search-improve-performance.md index 751accc830bdf..66bb65c35110e 100644 --- a/ai/reference/vector-search-improve-performance.md +++ b/ai/reference/vector-search-improve-performance.md @@ -10,8 +10,8 @@ TiDB Vector Searchを使用すると、画像、ドキュメント、その他 > **Note:** > -> - ベクトル検索機能はパブリックプレビューです。予告なく変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告を行ってください。 -> - ベクトル検索機能は[TiDB Self-Managed](/overview.md) と [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で利用可能です。TiDB Self-Managedの場合、TiDBバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能はパブリックプレビューです。予告なく変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告を行ってください。 +> - ベクトル検索機能は[TiDB Self-Managed](/overview.md) と [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で利用可能です。TiDB Self-Managedの場合、TiDBバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## ベクトル列にベクトル検索インデックスを追加する {#add-vector-search-index-for-vector-columns} diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md index b8a622ba8d6e0..541010413162e 100644 --- a/ai/reference/vector-search-index.md +++ b/ai/reference/vector-search-index.md @@ -12,22 +12,22 @@ aliases: ['/ja/tidb/stable/vector-search-index/','/ja/tidbcloud/vector-search-in > **Note:** > -> - ベクトル検索機能はパブリックプレビューです。予告なく変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告を行ってください。 -> - ベクトル検索機能は[TiDB Self-Managed](/overview.md)および[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で利用可能です。TiDB Self-Managedの場合、TiDBバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能はパブリックプレビューです。予告なく変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告を行ってください。 +> - ベクトル検索機能は[TiDB Self-Managed](/overview.md)および[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)で利用可能です。TiDB Self-Managedの場合、TiDBバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 現在、TiDB は[HNSW（階層的ナビゲート可能なスモールワールド）](https://en.wikipedia.org/wiki/Hierarchical_navigable_small_world)ベクトル検索インデックス アルゴリズムをサポートしています。 ## 制限 {#restrictions} -- 事前にTiFlashノードをクラスターにデプロイする必要があります。 -- ベクトル検索インデックスは、主キーまたは一意インデックスとして使用することはできません。 -- ベクトル検索インデックスは単一のベクトル列にのみ作成でき、他の列 (整数や文字列など) と組み合わせて複合インデックスを形成することはできません。 -- ベクトル検索インデックスの作成および使用時には、距離関数を指定する必要があります。現在、コサイン距離`VEC_COSINE_DISTANCE()`とL2距離`VEC_L2_DISTANCE()`の関数のみがサポートされています。 -- 同じ列に対して、同じ距離関数を使用して複数のベクトル検索インデックスを作成することはサポートされていません。 -- ベクトル検索インデックスが設定された列を直接削除することはサポートされていません。このような列を削除するには、まずその列のベクトル検索インデックスを削除し、次に列自体を削除します。 -- ベクトル インデックスを持つ列の型の変更はサポートされていません。 -- ベクトル検索インデックスを[見えない](/sql-statements/sql-statement-alter-index.md)に設定することはサポートされていません。 -- [保存時の暗号化](/encryption-at-rest.md)有効になっているTiFlashノード上でベクトル検索インデックスを構築することはサポートされていません。 +- 事前にTiFlashノードをクラスターにデプロイする必要があります。 +- ベクトル検索インデックスは、主キーまたは一意インデックスとして使用することはできません。 +- ベクトル検索インデックスは単一のベクトル列にのみ作成でき、他の列 (整数や文字列など) と組み合わせて複合インデックスを形成することはできません。 +- ベクトル検索インデックスの作成および使用時には、距離関数を指定する必要があります。現在、コサイン距離`VEC_COSINE_DISTANCE()`とL2距離`VEC_L2_DISTANCE()`の関数のみがサポートされています。 +- 同じ列に対して、同じ距離関数を使用して複数のベクトル検索インデックスを作成することはサポートされていません。 +- ベクトル検索インデックスが設定された列を直接削除することはサポートされていません。このような列を削除するには、まずその列のベクトル検索インデックスを削除し、次に列自体を削除します。 +- ベクトル インデックスを持つ列の型の変更はサポートされていません。 +- ベクトル検索インデックスを[見えない](/sql-statements/sql-statement-alter-index.md)に設定することはサポートされていません。 +- [保存時の暗号化](/encryption-at-rest.md)有効になっているTiFlashノード上でベクトル検索インデックスを構築することはサポートされていません。 ## HNSWベクトルインデックスを作成する {#create-the-hnsw-vector-index} @@ -35,7 +35,7 @@ aliases: ['/ja/tidb/stable/vector-search-index/','/ja/tidbcloud/vector-search-in TiDB では、次のいずれかの方法で、 [ベクトルデータ型](/ai/reference/vector-search-data-types.md)列に対して HNSW インデックスを作成できます。 -- テーブルを作成するときは、次の構文を使用して HNSW インデックスのベクトル列を指定します。 +- テーブルを作成するときは、次の構文を使用して HNSW インデックスのベクトル列を指定します。 ```sql CREATE TABLE foo ( @@ -45,7 +45,7 @@ TiDB では、次のいずれかの方法で、 [ベクトルデータ型](/ai/r ); ``` -- ベクトル列がすでに含まれている既存のテーブルの場合は、次の構文を使用してベクトル列の HNSW インデックスを作成します。 +- ベクトル列がすでに含まれている既存のテーブルの場合は、次の構文を使用してベクトル列の HNSW インデックスを作成します。 ```sql CREATE VECTOR INDEX idx_embedding ON foo ((VEC_COSINE_DISTANCE(embedding))); @@ -60,13 +60,13 @@ TiDB では、次のいずれかの方法で、 [ベクトルデータ型](/ai/r > > ベクトル検索インデックス機能は、テーブルのTiFlashレプリカに依存します。 > -> - テーブルの作成時にベクトル検索インデックスが定義されている場合、TiDB はテーブルのTiFlashレプリカを自動的に作成します。 -> - テーブルの作成時にベクトル検索インデックスが定義されておらず、テーブルに現在TiFlashレプリカが存在しない場合は、テーブルにベクトル検索インデックスを追加する前に、手動でTiFlashレプリカを作成する必要があります。例: `ALTER TABLE 'table_name' SET TIFLASH REPLICA 1;` 。 +> - テーブルの作成時にベクトル検索インデックスが定義されている場合、TiDB はテーブルのTiFlashレプリカを自動的に作成します。 +> - テーブルの作成時にベクトル検索インデックスが定義されておらず、テーブルに現在TiFlashレプリカが存在しない場合は、テーブルにベクトル検索インデックスを追加する前に、手動でTiFlashレプリカを作成する必要があります。例: `ALTER TABLE 'table_name' SET TIFLASH REPLICA 1;` 。 HNSW ベクトル インデックスを作成するときは、ベクトルの距離関数を指定する必要があります。 -- コサイン距離: `((VEC_COSINE_DISTANCE(embedding)))` -- L2距離: `((VEC_L2_DISTANCE(embedding)))` +- コサイン距離: `((VEC_COSINE_DISTANCE(embedding)))` +- L2距離: `((VEC_L2_DISTANCE(embedding)))` ベクトルインデックスは、固定次元のベクトル列（例えば、 `VECTOR(3)`と定義された列）に対してのみ作成できます。ベクトル距離は、同じ次元のベクトル間でのみ計算できるため、非固定次元のベクトル列（例えば、 `VECTOR`と定義された列）には作成できません。 @@ -130,11 +130,11 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES; +---------------+------------+----------+-------------+---------------+-----------+----------+------------+---------------------+-------------------------+--------------------+------------------------+---------------+------------------+ ``` -- インデックス構築の進行状況は、 `ROWS_STABLE_INDEXED`と`ROWS_STABLE_NOT_INDEXED`列で確認できます。`ROWS_STABLE_NOT_INDEXED`が0になると、インデックス構築が完了します。 +- インデックス構築の進行状況は、 `ROWS_STABLE_INDEXED`と`ROWS_STABLE_NOT_INDEXED`列で確認できます。`ROWS_STABLE_NOT_INDEXED`が0になると、インデックス構築が完了します。 参考までに、768次元の500MiBベクトルデータセットのインデックス作成には最大20分かかる場合があります。インデクサーは複数のテーブルに対して並列実行できます。現在、インデクサーの優先度や速度の調整はサポートされていません。 -- デルタレイヤーの行数は`ROWS_DELTA_NOT_INDEXED`列で確認できます。TiFlashのストレージレイヤーのデータは、デルタレイヤーとステーブルレイヤーの2つのレイヤーに保存されます。デルタレイヤーには最近挿入または更新された行が保存され、書き込みワークロードに応じて定期的にステーブルレイヤーにマージされます。このマージプロセスはコンパクションと呼ばれます。 +- デルタレイヤーの行数は`ROWS_DELTA_NOT_INDEXED`列で確認できます。TiFlashのストレージレイヤーのデータは、デルタレイヤーとステーブルレイヤーの2つのレイヤーに保存されます。デルタレイヤーには最近挿入または更新された行が保存され、書き込みワークロードに応じて定期的にステーブルレイヤーにマージされます。このマージプロセスはコンパクションと呼ばれます。 Deltaレイヤーは常にインデックス化されません。最適なパフォーマンスを実現するには、DeltaレイヤーをStableレイヤーに強制的にマージし、すべてのデータがインデックス化されるようにすることができます。 @@ -242,18 +242,18 @@ LIMIT 10; いくつかの重要なフィールドの説明: -- `vector_index.load.total` : インデックスの読み込みにかかる合計時間。複数のベクトルインデックスが並行して読み込まれる可能性があるため、このフィールドは実際のクエリ時間よりも長くなる可能性があります。 -- `vector_index.load.from_s3` : S3 からロードされたインデックスの数。 -- `vector_index.load.from_disk` : ディスクからロードされたインデックスの数。インデックスは以前にS3からダウンロード済みです。 -- `vector_index.load.from_cache` : キャッシュからロードされたインデックスの数。インデックスは以前にS3からダウンロード済みです。 -- `vector_index.search.total` : インデックス内の検索にかかる合計時間。レイテンシーが大きい場合、通常、インデックスがコールド状態（一度もアクセスされていない、またはかなり前にアクセスされている状態）であるため、インデックス検索時に大量のI/O操作が発生します。複数のベクトルインデックスが並列で検索される可能性があるため、このフィールドは実際のクエリ時間よりも長くなる可能性があります。 -- `vector_index.search.discarded_nodes` : 検索中に訪問されたが破棄されたベクトル行の数。これらの破棄されたベクトルは検索結果には考慮されません。この値が大きい場合、通常、 `UPDATE`または`DELETE`ステートメントによって多くの古い行が発生していることを示します。 +- `vector_index.load.total` : インデックスの読み込みにかかる合計時間。複数のベクトルインデックスが並行して読み込まれる可能性があるため、このフィールドは実際のクエリ時間よりも長くなる可能性があります。 +- `vector_index.load.from_s3` : S3 からロードされたインデックスの数。 +- `vector_index.load.from_disk` : ディスクからロードされたインデックスの数。インデックスは以前にS3からダウンロード済みです。 +- `vector_index.load.from_cache` : キャッシュからロードされたインデックスの数。インデックスは以前にS3からダウンロード済みです。 +- `vector_index.search.total` : インデックス内の検索にかかる合計時間。レイテンシーが大きい場合、通常、インデックスがコールド状態（一度もアクセスされていない、またはかなり前にアクセスされている状態）であるため、インデックス検索時に大量のI/O操作が発生します。複数のベクトルインデックスが並列で検索される可能性があるため、このフィールドは実際のクエリ時間よりも長くなる可能性があります。 +- `vector_index.search.discarded_nodes` : 検索中に訪問されたが破棄されたベクトル行の数。これらの破棄されたベクトルは検索結果には考慮されません。この値が大きい場合、通常、 `UPDATE`または`DELETE`ステートメントによって多くの古い行が発生していることを示します。 出力の解釈については、 [`EXPLAIN`](/sql-statements/sql-statement-explain.md) 、 [`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md) 、および[EXPLAIN コマンド](/explain-walkthrough.md)を参照してください。 ## 参照 {#see-also} -- [ベクトル検索のパフォーマンスを向上させる](/ai/reference/vector-search-improve-performance.md) -- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) +- [ベクトル検索のパフォーマンスを向上させる](/ai/reference/vector-search-improve-performance.md) +- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) [^1]: KNN 検索の説明は、ClickHouse ドキュメントの[rschu1ze](https://github.com/rschu1ze)が作成した[近似最近傍検索インデックス](https://github.com/ClickHouse/ClickHouse/pull/50661/files#diff-7ebd9e71df96e74230c9a7e604fa7cb443be69ba5e23bf733fcecd4cc51b7576)ドキュメントに基づいており、Apache License 2.0 に基づいてライセンスされています。 diff --git a/ai/reference/vector-search-limitations.md b/ai/reference/vector-search-limitations.md index 05e26a9675f29..c653c2f406213 100644 --- a/ai/reference/vector-search-limitations.md +++ b/ai/reference/vector-search-limitations.md @@ -10,18 +10,18 @@ aliases: ['/ja/tidb/stable/vector-search-limitations/','/ja/tidb/dev/vector-sear > **Note:** > -> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、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以降を推奨）。 +> - ベクトル検索機能はパブリックプレビューです。予告なく変更される場合があります。バグを発見した場合は、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以降を推奨）。 ## ベクトルデータ型の制限 {#vector-data-type-limitations} -- それぞれ最大 16383 次元 [ベクトル](/ai/reference/vector-search-data-types.md)サポートします。 -- ベクトルデータ型は、 `NaN` 、 `Infinity` 、または`-Infinity`の値を格納することはできません。 -- ベクトルデータ型は倍精度浮動小数点数を格納することはできません。ベクトル列に倍精度浮動小数点数を挿入または格納すると、TiDBはそれらを単精度浮動小数点数に変換します。 -- ベクトル列は、主キーとして、または主キーの一部として使用することはできません。 -- ベクトル列は、一意インデックスとして、または一意インデックスの一部として使用することはできません。 -- ベクトル列は、パーティションキーとして、またはパーティションキーの一部として使用することはできません。 -- 現在、TiDB はベクトル列を他のデータ型 ( `JSON`や`VARCHAR`など) に変更することをサポートしていません。 +- それぞれ最大 16383 次元 [ベクトル](/ai/reference/vector-search-data-types.md)サポートします。 +- ベクトルデータ型は、 `NaN` 、 `Infinity` 、または`-Infinity`の値を格納することはできません。 +- ベクトルデータ型は倍精度浮動小数点数を格納することはできません。ベクトル列に倍精度浮動小数点数を挿入または格納すると、TiDBはそれらを単精度浮動小数点数に変換します。 +- ベクトル列は、主キーとして、または主キーの一部として使用することはできません。 +- ベクトル列は、一意インデックスとして、または一意インデックスの一部として使用することはできません。 +- ベクトル列は、パーティションキーとして、またはパーティションキーの一部として使用することはできません。 +- 現在、TiDB はベクトル列を他のデータ型 ( `JSON`や`VARCHAR`など) に変更することをサポートしていません。 ## ベクトルインデックスの制限 {#vector-index-limitations} @@ -31,20 +31,20 @@ aliases: ['/ja/tidb/stable/vector-search-limitations/','/ja/tidb/dev/vector-sear ベクトル検索を使用する際は、以下の互換性の問題にご注意ください。 -- TiDB Cloudの機能： +- TiDB Cloudの機能： - - [TiDB Cloudコンソールのデータ移行機能](/tidb-cloud/migrate-from-mysql-using-data-migration.md)MySQL ベクトル データ型のTiDB Cloudへの移行または複製をサポートしていません。 + - [TiDB Cloudコンソールのデータ移行機能](/tidb-cloud/migrate-from-mysql-using-data-migration.md)MySQL ベクトル データ型のTiDB Cloudへの移行または複製をサポートしていません。 -- TiDB Self-Managedツール： +- TiDB Self-Managedツール： - - データのバックアップと復元には、 [BR](/br/backup-and-restore-overview.md)のバージョン8.4.0以降を使用していることを確認してください。ベクトルデータ型のテーブルをTiDBバージョン8.4.0より前のバージョンに復元することはサポートされていません。 - - [TiDB Data Migration (DM)](/dm/dm-overview.md) MySQLベクトルデータ型をTiDBに移行または複製することをサポートしていません。 - - [TiCDC](/ticdc/ticdc-overview.md)ベクトル データ タイプをサポートしていないダウンストリームにベクトル データをレプリケートすると、ベクトル データ タイプが別のタイプに変更されます。詳細については、 [ベクトルデータ型との互換性](/ticdc/ticdc-compatibility.md#compatibility-with-vector-data-types)を参照してください。 + - データのバックアップと復元には、 [BR](/br/backup-and-restore-overview.md)のバージョン8.4.0以降を使用していることを確認してください。ベクトルデータ型のテーブルをTiDBバージョン8.4.0より前のバージョンに復元することはサポートされていません。 + - [TiDB Data Migration (DM)](/dm/dm-overview.md) MySQLベクトルデータ型をTiDBに移行または複製することをサポートしていません。 + - [TiCDC](/ticdc/ticdc-overview.md)ベクトル データ タイプをサポートしていないダウンストリームにベクトル データをレプリケートすると、ベクトル データ タイプが別のタイプに変更されます。詳細については、 [ベクトルデータ型との互換性](/ticdc/ticdc-compatibility.md#compatibility-with-vector-data-types)を参照してください。 ## フィードバック {#feedback} お客様からのご意見を大切にし、いつでもお手伝いいたします。 -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/ai/vector-search-get-started-using-python.md b/ai/vector-search-get-started-using-python.md index 1eb4c78bd32a0..2489e1f3fb553 100644 --- a/ai/vector-search-get-started-using-python.md +++ b/ai/vector-search-get-started-using-python.md @@ -12,21 +12,21 @@ aliases: ['/ja/tidb/stable/vector-search-get-started-using-python/','/ja/tidb/de > **Note:** > -> - ベクトル検索機能はベータ版です。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能はベータ版です。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## 前提条件 {#prerequisites} このチュートリアルを完了するには、以下が必要です。 -- [Python 3.8以降](https://www.python.org/downloads/)がインストールされていること。 -- [Git](https://git-scm.com/downloads)がインストールされていること。 -- TiDBクラスタ。 +- [Python 3.8以降](https://www.python.org/downloads/)がインストールされていること。 +- [Git](https://git-scm.com/downloads)がインストールされていること。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## さあ始めましょう {#get-started} @@ -50,8 +50,8 @@ touch example.py pip install sqlalchemy pymysql sentence-transformers tidb-vector python-dotenv ``` -- `tidb-vector` : TiDBベクトル検索と対話するためのPythonクライアント。 -- [`sentence-transformers`](https://sbert.net) : テキストから[ベクトル埋め込み](/ai/concepts/vector-search-overview.md#vector-embedding)を生成するための事前トレーニング済みモデルを提供する Python ライブラリです。 +- `tidb-vector` : TiDBベクトル検索と対話するためのPythonクライアント。 +- [`sentence-transformers`](https://sbert.net) : テキストから[ベクトル埋め込み](/ai/concepts/vector-search-overview.md#vector-embedding)を生成するための事前トレーニング済みモデルを提供する Python ライブラリです。 ### ステップ3．TiDB接続文字列を設定する {#step-3-configure-the-tidb-connection-string} @@ -62,31 +62,31 @@ pip install sqlalchemy pymysql sentence-transformers tidb-vector python-dotenv TiDB Cloud Starterインスタンスの場合、接続文字列を取得し、環境変数を設定するには、以下の手順を実行してください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、次に、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、次に、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`SQLAlchemy`に設定されています。 + - **Connect With**は`SQLAlchemy`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **PyMySQL**タブをクリックして、接続文字列をコピーしてください。 +4. **PyMySQL**タブをクリックして、接続文字列をコピーしてください。 > **Tip:** > > まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 -5. Python プロジェクトのルートディレクトリに`.env`ファイルを作成し、接続文字列を貼り付けます。 +5. Python プロジェクトのルートディレクトリに`.env`ファイルを作成し、接続文字列を貼り付けます。 以下はmacOSの例です。 @@ -108,11 +108,11 @@ TiDBをローカルマシンで実行している場合、 ``はデフォ 各パラメータの説明は以下のとおりです。 -- `` : TiDBに接続するためのユーザー名。 -- `` : TiDBに接続するためのパスワード。 -- `` : TiDBクラスタのホスト。 -- `` : TiDB クラスタのポート。 -- `` : 接続するデータベースの名前。 +- `` : TiDBに接続するためのユーザー名。 +- `` : TiDBに接続するためのパスワード。 +- `` : TiDBクラスタのホスト。 +- `` : TiDB クラスタのポート。 +- `` : 接続するデータベースの名前。
@@ -232,5 +232,5 @@ Search result ("a swimming animal"): ## 関連項目 {#see-also} -- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) -- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) +- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) +- [ベクトル検索インデックス](/ai/reference/vector-search-index.md) diff --git a/alert-rules.md b/alert-rules.md index 600d800468fc1..13a6cab6fb2b1 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -25,43 +25,43 @@ summary: TiDB クラスターのアラート ルールについて学習しま #### `TiDB_schema_error` {#tidb_schema_error} -- アラートルール: +- アラートルール: `increase(tidb_session_schema_lease_error_total{type="outdated"}[15m]) > 0` -- 説明： +- 説明： 最新のスキーマ情報は、1リース期間内にTiDBに再ロードされません。TiDBがサービス提供を継続できない場合、アラートがトリガーされます。 -- 解決： +- 解決： これは、利用できないリージョンやTiKVのタイムアウトが原因であることが多いです。TiKVの監視項目を確認して問題を特定する必要があります。 #### `TiDB_tikvclient_region_err_total` {#tidb_tikvclient_region_err_total} -- アラートルール: +- アラートルール: `increase(tidb_tikvclient_region_err_total[10m]) > 6000` -- 説明： +- 説明： TiDBサーバーは、自身のキャッシュ情報に基づいてTiKVのリージョンリーダーにアクセスします。リージョンリーダーが変更された場合、または現在のTiKVリージョン情報がTiDBキャッシュの情報と一致しない場合、リージョンキャッシュエラーが発生します。このエラーが10分間に6000回以上報告されると、アラートがトリガーされます。 -- 解決： +- 解決： リーダーのバランスが取れているかどうかを確認するには、[**TiKV詳細**>**クラスタ**ダッシュボード](/grafana-tikv-dashboard.md#cluster)を確認する。 #### `TiDB_domain_load_schema_total` {#tidb_domain_load_schema_total} -- アラートルール: +- アラートルール: `increase(tidb_domain_load_schema_total{type="failed"}[10m]) > 10` -- 説明： +- 説明： TiDB の最新スキーマ情報の再読み込みに失敗した回数の合計。10 分間に 10 回以上再読み込みに失敗した場合にアラートがトリガーされます。 -- 解決： +- 解決： [`TiDB_schema_error`](#tidb_schema_error)と同じです。 @@ -69,15 +69,15 @@ summary: TiDB クラスターのアラート ルールについて学習しま #### `TiDB_server_panic_total` {#tidb_server_panic_total} -- アラートルール: +- アラートルール: `increase(tidb_server_panic_total[10m]) > 0` -- 説明： +- 説明： パニック状態にあるTiDBスレッドの数。panicが発生するとアラートがトリガーされます。スレッドは頻繁に回復しますが、回復しない場合はTiDBが頻繁に再起動します。 -- 解決： +- 解決： panicログを収集して問題を特定します。 @@ -85,88 +85,88 @@ summary: TiDB クラスターのアラート ルールについて学習しま #### `TiDB_memory_abnormal` {#tidb_memory_abnormal} -- アラートルール: +- アラートルール: `go_memstats_heap_inuse_bytes{job="tidb"} > 1e+10` -- 説明： +- 説明： TiDBメモリ使用量の監視。使用量が10GBを超えるとアラートがトリガーされます。 -- 解決： +- 解決： HTTP API を使用して、goroutine リークの問題をトラブルシューティングします。 #### `TiDB_query_duration` {#tidb_query_duration} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(tidb_server_handle_query_duration_seconds_bucket[1m])) BY (le, instance)) > 1` -- 説明： +- 説明： TiDB でのリクエスト処理のレイテンシー。リクエストの 99% の応答時間は 1 秒以内である必要があります。それ以外の場合は、アラートがトリガーされます。 -- 解決： +- 解決： TiDB ログを確認し、キーワード`SLOW_QUERY`と`TIME_COP_PROCESS`を検索して、遅い SQL クエリを見つけます。 #### `TiDB_server_event_error` {#tidb_server_event_error} -- アラートルール: +- アラートルール: `increase(tidb_server_event_total{type=~"server_start|server_hang"}[15m]) > 0` -- 説明： +- 説明： TiDB サービスで発生したイベントの数。以下のイベントが発生するとアラートがトリガーされます。 - 1. start: TiDB サービスが開始されます。 - 2. ハング: 重大なレベルのイベントが発生すると、TiDB は`hang`モードに入り、手動で強制終了されるのを待機します。 + 1. start: TiDB サービスが開始されます。 + 2. ハング: 重大なレベルのイベントが発生すると、TiDB は`hang`モードに入り、手動で強制終了されるのを待機します。 -- 解決： +- 解決： サービスを回復するには、TiDB を再起動します。 #### `TiDB_tikvclient_backoff_seconds_count` {#tidb_tikvclient_backoff_seconds_count} -- アラートルール: +- アラートルール: `increase(tidb_tikvclient_backoff_seconds_count[10m]) > 10` -- 説明： +- 説明： TiDBがTiKVへのアクセスに失敗した場合の再試行回数。10分間の再試行回数が10回を超えると、アラートがトリガーされます。 -- 解決： +- 解決： TiKV の監視ステータスを確認する。 #### `TiDB_monitor_time_jump_back_error` {#tidb_monitor_time_jump_back_error} -- アラートルール: +- アラートルール: `increase(tidb_monitor_time_jump_back_total[10m]) > 0` -- 説明： +- 説明： TiDB を保持しているマシンの時間が巻き戻ると、アラートがトリガーされます。 -- 解決： +- 解決： NTP 構成のトラブルシューティングを行います。 #### `TiDB_ddl_waiting_jobs` {#tidb_ddl_waiting_jobs} -- アラートルール: +- アラートルール: `sum(tidb_ddl_waiting_jobs) > 5` -- 説明： +- 説明： TiDB で実行が保留中の DDL タスクの数が 5 を超えると、アラートがトリガーされます。 -- 解決： +- 解決： `admin show ddl`を実行して、時間のかかる`add index`操作が実行されているかどうかを確認します。 @@ -178,242 +178,242 @@ summary: TiDB クラスターのアラート ルールについて学習しま #### `PD_cluster_down_store_nums` {#pd_cluster_down_store_nums} -- アラートルール: +- アラートルール: `(sum(pd_cluster_status{type="store_down_count"}) by (instance) > 0) and (sum(etcd_server_is_leader) by (instance) > 0)` -- 説明： +- 説明： PD は長時間にわたって TiKV/ TiFlashハートビートを受信していません (デフォルト設定は 30 分です)。 -- 解決： +- 解決： - - TiKV/ TiFlashプロセスが正常かどうか、ネットワークが分離されているか、負荷が高すぎるかどうかを確認し、可能な限りサービスを回復します。 - - TiKV/ TiFlashインスタンスを回復できない場合は、オフラインにすることができます。 + - TiKV/ TiFlashプロセスが正常かどうか、ネットワークが分離されているか、負荷が高すぎるかどうかを確認し、可能な限りサービスを回復します。 + - TiKV/ TiFlashインスタンスを回復できない場合は、オフラインにすることができます。 ### 重大レベルのアラート {#critical-level-alerts-2} #### `PD_etcd_write_disk_latency` {#pd_etcd_write_disk_latency} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(etcd_disk_wal_fsync_duration_seconds_bucket[1m])) by (instance, job, le)) > 1` -- 説明： +- 説明： fsync 操作のレイテンシーが1秒を超える場合、etcd が通常よりも遅い速度でディスクにデータを書き込んでいることを示します。PD リーダーのタイムアウトや、TSO をディスクに時間内に保存できないことが発生し、クラスター全体のサービスがシャットダウンする可能性があります。 -- 解決： +- 解決： - - 書き込み速度が遅い原因を特定してください。システムに過負荷をかけている他のサービスが原因かもしれません。PD自体がCPUやI/Oリソースを大量に消費していないか確認しましょう。 - - サービスを回復するには、PD を再起動するか、リーダーを手動で別の PD に転送してください。 - - 環境要因により問題のある PD インスタンスを回復できない場合は、オフラインにして交換してください。 + - 書き込み速度が遅い原因を特定してください。システムに過負荷をかけている他のサービスが原因かもしれません。PD自体がCPUやI/Oリソースを大量に消費していないか確認しましょう。 + - サービスを回復するには、PD を再起動するか、リーダーを手動で別の PD に転送してください。 + - 環境要因により問題のある PD インスタンスを回復できない場合は、オフラインにして交換してください。 #### `PD_miss_peer_region_count` {#pd_miss_peer_region_count} -- アラートルール: +- アラートルール: `(sum(pd_regions_status{type="miss-peer-region-count"}) by (instance) > 100) and (sum(etcd_server_is_leader) by (instance) > 0)` -- 説明： +- 説明： リージョンレプリカの数が`max-replicas`より小さくなっています。 -- 解決： +- 解決： - - ダウンしている、またはオフラインになっている TiKV マシンがあるかどうかを確認して、問題の原因を見つけます。 - - リージョンのヘルスパネルを監視し、 `miss-peer-region-count`継続的に減少しているかどうかを確認します。 + - ダウンしている、またはオフラインになっている TiKV マシンがあるかどうかを確認して、問題の原因を見つけます。 + - リージョンのヘルスパネルを監視し、 `miss-peer-region-count`継続的に減少しているかどうかを確認します。 ### 警告レベルのアラート {#warning-level-alerts-2} #### `PD_cluster_lost_connect_store_nums` {#pd_cluster_lost_connect_store_nums} -- アラートルール: +- アラートルール: `(sum(pd_cluster_status{type="store_disconnected_count"}) by (instance) > 0) and (sum(etcd_server_is_leader) by (instance) > 0)` -- 説明： +- 説明： PDは20秒以内にTiKV/ TiFlashハートビートを受信しません。通常、TiKV/ TiFlashハートビートは10秒ごとに受信されます。 -- 解決： +- 解決： - - TiKV/ TiFlashインスタンスが再起動されているかどうかを確認します。 - - TiKV/ TiFlashプロセスが正常かどうか、ネットワークが分離されているかどうか、負荷が高すぎないかどうかを確認し、可能な限りサービスを回復します。 - - TiKV/ TiFlashインスタンスが回復できないことが確認できた場合は、オフラインにすることができます。 - - TiKV/ TiFlashインスタンスが回復可能であることが確認できたものの、短期間で回復できない場合は、 `max-down-time`の値を増やすことを検討してください。これにより、TiKV/ TiFlashインスタンスが回復不能と判断され、TiKV/ TiFlashからデータが削除されるのを防ぐことができます。 + - TiKV/ TiFlashインスタンスが再起動されているかどうかを確認します。 + - TiKV/ TiFlashプロセスが正常かどうか、ネットワークが分離されているかどうか、負荷が高すぎないかどうかを確認し、可能な限りサービスを回復します。 + - TiKV/ TiFlashインスタンスが回復できないことが確認できた場合は、オフラインにすることができます。 + - TiKV/ TiFlashインスタンスが回復可能であることが確認できたものの、短期間で回復できない場合は、 `max-down-time`の値を増やすことを検討してください。これにより、TiKV/ TiFlashインスタンスが回復不能と判断され、TiKV/ TiFlashからデータが削除されるのを防ぐことができます。 #### `PD_cluster_unhealthy_tikv_nums` {#pd_cluster_unhealthy_tikv_nums} -- アラートルール: +- アラートルール: `(sum(pd_cluster_status{type="store_unhealth_count"}) by (instance) > 0) and (sum(etcd_server_is_leader) by (instance) > 0)` -- 説明： +- 説明： 不健全なストアがあることを示します。この状況が一定時間（ [`max-store-down-time`](/pd-configuration-file.md#max-store-down-time)に設定、デフォルトは`30m` ）続くと、ストアは`Offline`状態に移行する可能性が高く、 [`PD_cluster_down_store_nums`](#pd_cluster_down_store_nums)アラートがトリガーされます。 -- 解決： +- 解決： TiKV ストアの状態を確認します。 #### `PD_cluster_low_space` {#pd_cluster_low_space} -- アラートルール: +- アラートルール: `(sum(pd_cluster_status{type="store_low_space_count"}) by (instance) > 0) and (sum(etcd_server_is_leader) by (instance) > 0)` -- 説明： +- 説明： TiKV/ TiFlashノードに十分なスペースがないことを示します。 -- 解決： +- 解決： - - クラスター内のスペースが全体的に不足していないか確認してください。不足している場合は、容量を増やしてください。 - - リージョンバランスのスケジュール設定に問題がないか確認してください。問題がある場合、データの分散が不均一になります。 - - ログ、スナップショット、コアダンプなど、大量のディスク領域を占有するファイルがあるかどうかを確認します。 - - データ量を削減するには、ノードのリージョン重みを下げます。 - - スペースを解放できない場合は、事前にノードをオフラインにすることを検討してください。これにより、ディスク容量不足によるダウンタイムの発生を防止できます。 + - クラスター内のスペースが全体的に不足していないか確認してください。不足している場合は、容量を増やしてください。 + - リージョンバランスのスケジュール設定に問題がないか確認してください。問題がある場合、データの分散が不均一になります。 + - ログ、スナップショット、コアダンプなど、大量のディスク領域を占有するファイルがあるかどうかを確認します。 + - データ量を削減するには、ノードのリージョン重みを下げます。 + - スペースを解放できない場合は、事前にノードをオフラインにすることを検討してください。これにより、ディスク容量不足によるダウンタイムの発生を防止できます。 #### `PD_etcd_network_peer_latency` {#pd_etcd_network_peer_latency} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(etcd_network_peer_round_trip_time_seconds_bucket[1m])) by (To, instance, job, le)) > 1` -- 説明： +- 説明： PDノード間のネットワークレイテンシーが高くなっています。リーダータイムアウトやTSOディスクストレージタイムアウトが発生し、クラスターのサービスに影響を与える可能性があります。 -- 解決： +- 解決： - - ネットワークとシステムの負荷状態を確認します。 - - 環境要因により問題のある PD インスタンスを回復できない場合は、オフラインにして交換してください。 + - ネットワークとシステムの負荷状態を確認します。 + - 環境要因により問題のある PD インスタンスを回復できない場合は、オフラインにして交換してください。 #### `PD_tidb_handle_requests_duration` {#pd_tidb_handle_requests_duration} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(pd_client_request_handle_requests_duration_seconds_bucket{type="tso"}[1m])) by (instance, job, le)) > 0.1` -- 説明： +- 説明： PDがTSOリクエストを処理するのに時間がかかります。これは多くの場合、高負荷が原因です。 -- 解決： +- 解決： - - サーバーの負荷状況を確認してください。 - - pprof を使用して PD の CPU プロファイルを分析します。 - - PD リーダーを手動で切り替えます。 - - 環境要因により問題のある PD インスタンスを回復できない場合は、オフラインにして交換してください。 + - サーバーの負荷状況を確認してください。 + - pprof を使用して PD の CPU プロファイルを分析します。 + - PD リーダーを手動で切り替えます。 + - 環境要因により問題のある PD インスタンスを回復できない場合は、オフラインにして交換してください。 #### `PD_down_peer_region_nums` {#pd_down_peer_region_nums} -- アラートルール: +- アラートルール: `(sum(pd_regions_status{type="down-peer-region-count"}) by (instance) > 0) and (sum(etcd_server_is_leader) by (instance) > 0)` -- 説明： +- 説明： Raftリーダーによって報告された、応答しないピアがあるリージョンの数。 -- 解決： +- 解決： - - ダウンしている TiKV、再起動したばかりの TiKV、またはビジー状態の TiKV があるかどうかを確認します。 - - リージョンのヘルスパネルを監視し、 `down_peer_region_count`継続的に減少しているかどうかを確認します。 - - TiKV サーバー間のネットワークを確認します。 + - ダウンしている TiKV、再起動したばかりの TiKV、またはビジー状態の TiKV があるかどうかを確認します。 + - リージョンのヘルスパネルを監視し、 `down_peer_region_count`継続的に減少しているかどうかを確認します。 + - TiKV サーバー間のネットワークを確認します。 #### `PD_pending_peer_region_count` {#pd_pending_peer_region_count} -- アラートルール: +- アラートルール: `(sum(pd_regions_status{type="pending-peer-region-count"}) by (instance) > 100) and (sum(etcd_server_is_leader) by (instance) > 0)` -- 説明： +- 説明： Raftログに遅延が発生しているリージョンが多すぎます。スケジュール設定によって保留中のピアの数が少なくなるのは正常ですが、その数が依然として多い場合は問題が発生している可能性があります。 -- 解決： +- 解決： - - リージョンのヘルスパネルを監視し、 `pending_peer_region_count`継続的に減少しているかどうかを確認します。 - - TiKV サーバー間のネットワーク、特に十分な帯域幅があるかどうかを確認します。 + - リージョンのヘルスパネルを監視し、 `pending_peer_region_count`継続的に減少しているかどうかを確認します。 + - TiKV サーバー間のネットワーク、特に十分な帯域幅があるかどうかを確認します。 #### `PD_leader_change` {#pd_leader_change} -- アラートルール: +- アラートルール: `count(changes(pd_tso_events{type="save"}[10m]) > 0) >= 2` -- 説明： +- 説明： 最近PDリーダーが交代しました。 -- 解決： +- 解決： - - PD の再起動、リーダーの手動による移行、リーダーの優先順位の調整などの人的要因を除外します。 - - ネットワークとシステムの負荷状態を確認します。 - - 環境要因により問題のある PD インスタンスを回復できない場合は、オフラインにして交換してください。 + - PD の再起動、リーダーの手動による移行、リーダーの優先順位の調整などの人的要因を除外します。 + - ネットワークとシステムの負荷状態を確認します。 + - 環境要因により問題のある PD インスタンスを回復できない場合は、オフラインにして交換してください。 #### `TiKV_space_used_more_than_80%` {#tikv_space_used_more_than_80} -- アラートルール: +- アラートルール: `sum(pd_cluster_status{type="storage_size"}) / sum(pd_cluster_status{type="storage_capacity"}) * 100 > 80` -- 説明： +- 説明： クラスター領域の 80% 以上が使用されています。 -- 解決： +- 解決： - - 容量を増やす必要があるかどうかを確認します。 - - ログ、スナップショット、コアダンプなど、大量のディスク領域を占有するファイルがあるかどうかを確認します。 + - 容量を増やす必要があるかどうかを確認します。 + - ログ、スナップショット、コアダンプなど、大量のディスク領域を占有するファイルがあるかどうかを確認します。 #### `PD_system_time_slow` {#pd_system_time_slow} -- アラートルール: +- アラートルール: `changes(pd_tso_events{type="system_time_slow"}[10m]) >= 1` -- 説明： +- 説明： システム時間の巻き戻しが発生する可能性があります。 -- 解決： +- 解決： システム時刻が正しく設定されているかどうかを確認します。 #### `PD_no_store_for_making_replica` {#pd_no_store_for_making_replica} -- アラートルール: +- アラートルール: `increase(pd_checker_event_count{type="replica_checker", name="no_target_store"}[1m]) > 0` -- 説明： +- 説明： 追加のレプリカを保存する適切なストアがありません。 -- 解決： +- 解決： - - ストア内に十分なスペースがあるかどうかを確認します。 - - ラベル構成が設定されている場合は、それに従って追加のレプリカ用のストアがあるかどうかを確認します。 + - ストア内に十分なスペースがあるかどうかを確認します。 + - ラベル構成が設定されている場合は、それに従って追加のレプリカ用のストアがあるかどうかを確認します。 #### `PD_cluster_slow_tikv_nums` {#pd_cluster_slow_tikv_nums} -- アラートルール: +- アラートルール: `sum(pd_cluster_status{type="store_slow_count"}) by (instance) > 0) and (sum(etcd_server_is_leader) by (instance) > 0` -- 説明： +- 説明： 低速TiKVノードがあります。`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詳細**> **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アラートルール {#tikv-alert-rules} @@ -423,199 +423,199 @@ summary: TiDB クラスターのアラート ルールについて学習しま #### `TiKV_memory_used_too_fast` {#tikv_memory_used_too_fast} -- アラートルール: +- アラートルール: `process_resident_memory_bytes{job=~"tikv",instance=~".*"} - (process_resident_memory_bytes{job=~"tikv",instance=~".*"} offset 5m) > 5*1024*1024*1024` -- 説明： +- 説明： 現在、メモリに関するTiKV監視項目はありません。Node_exporterを使用することで、クラスター内のマシンのメモリ使用量を監視できます。上記のルールは、メモリ使用量が5分以内に5GBを超えた場合（TiKVでメモリが急速に占有されている場合）、アラートがトリガーされることを示しています。 -- 解決： +- 解決： `rocksdb.defaultcf`と`rocksdb.writecf`両方の`block-cache-size`値を調整します。 #### `TiKV_GC_can_not_work` {#tikv_gc_can_not_work} -- アラートルール: +- アラートルール: `sum(increase(tikv_gcworker_gc_tasks_vec{task="gc"}[1d])) < 1 and (sum(increase(tikv_gc_compaction_filter_perform[1d])) < 1 and sum(increase(tikv_engine_event_total{db="kv", cf="write", type="compaction"}[1d])) >= 1)` -- 説明： +- 説明： TiKVインスタンスで24時間以内にGCが正常に実行されない場合、GCが正常に機能していないことを示しています。GCが短期間で実行されない場合は大きな問題は発生しませんが、GCが低速状態が続くと、保持されるバージョンが増加し、クエリの速度が低下します。 -- 解決： +- 解決： - 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)ください。 + 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)ください。 ### 重大レベルのアラート {#critical-level-alerts-3} #### `TiKV_server_report_failure_msg_total` {#tikv_server_report_failure_msg_total} -- アラートルール: +- アラートルール: `sum(rate(tikv_server_report_failure_msg_total{type="unreachable"}[10m])) BY (store_id) > 10` -- 説明： +- 説明： リモート TiKV に接続できないことを示します。 -- 解決： +- 解決： - 1. ネットワークがクリアかどうかを確認してください。 - 2. リモート TiKV がダウンしていないかどうかを確認します。 - 3. リモートTiKVがダウンしていない場合は、圧力が高すぎないか確認してください。[`TiKV_channel_full_total`](#tikv_channel_full_total)の解決策を参照してください。 + 1. ネットワークがクリアかどうかを確認してください。 + 2. リモート TiKV がダウンしていないかどうかを確認します。 + 3. リモートTiKVがダウンしていない場合は、圧力が高すぎないか確認してください。[`TiKV_channel_full_total`](#tikv_channel_full_total)の解決策を参照してください。 #### `TiKV_channel_full_total` {#tikv_channel_full_total} -- アラートルール: +- アラートルール: `sum(rate(tikv_channel_full_total[10m])) BY (type, instance) > 0` -- 説明： +- 説明： この問題は、多くの場合、 Raftstoreスレッドがスタックし、TiKV に高い圧力がかかることで発生します。 -- 解決： +- 解決： - 1. [**TiKV詳細**> **Raft Propose**ダッシュボード](/grafana-tikv-dashboard.md#raft-propose)を監視し、アラートが発生した TiKV ノードのRaftプロポーズが他の TiKV ノードよりも大幅に高いかどうかを確認します。もしそうであれば、この TiKV に 1 つ以上のホットスポットがあることを意味します。ホットスポットのスケジューリングが適切に機能するかどうかを確認する必要があります。 - 2. [**TiKV-詳細**> **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)を監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。 - 3. [**TiKV詳細**>**Raftプロセス**ダッシュボード](/grafana-tikv-dashboard.md#raft-process)を見て、 `tick duration`ハイかどうかを確認してください。ハイなら、 [`raftstore.raft-base-tick-interval`](/tikv-configuration-file.md#raft-base-tick-interval)を `"2s"`に設定する必要があります。 + 1. [**TiKV詳細**> **Raft Propose**ダッシュボード](/grafana-tikv-dashboard.md#raft-propose)を監視し、アラートが発生した TiKV ノードのRaftプロポーズが他の TiKV ノードよりも大幅に高いかどうかを確認します。もしそうであれば、この TiKV に 1 つ以上のホットスポットがあることを意味します。ホットスポットのスケジューリングが適切に機能するかどうかを確認する必要があります。 + 2. [**TiKV-詳細**> **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)を監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。 + 3. [**TiKV詳細**>**Raftプロセス**ダッシュボード](/grafana-tikv-dashboard.md#raft-process)を見て、 `tick duration`ハイかどうかを確認してください。ハイなら、 [`raftstore.raft-base-tick-interval`](/tikv-configuration-file.md#raft-base-tick-interval)を `"2s"`に設定する必要があります。 #### `TiKV_write_stall` {#tikv_write_stall} -- アラートルール: +- アラートルール: `delta(tikv_engine_write_stall[10m]) > 0` -- 説明： +- 説明： RocksDB への書き込み圧力が高すぎるため、停止が発生します。 -- 解決： +- 解決： - 1. ディスク モニターを確認し、ディスクの問題をトラブルシューティングします。 - 2. TiKV に書き込みホットスポットがあるかどうかを確認します。 - 3. `[rocksdb]`および`[raftdb]`構成では、 `max-sub-compactions`より大きな値に設定します。 + 1. ディスク モニターを確認し、ディスクの問題をトラブルシューティングします。 + 2. TiKV に書き込みホットスポットがあるかどうかを確認します。 + 3. `[rocksdb]`および`[raftdb]`構成では、 `max-sub-compactions`より大きな値に設定します。 #### `TiKV_raft_log_lag` {#tikv_raft_log_lag} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(tikv_raftstore_log_lag_bucket[1m])) by (le, instance)) > 5000` -- 説明： +- 説明： この値が比較的大きい場合、FollowerがLeaderから大きく遅れており、 Raftが正常に複製できないことを意味します。Followerが配置されているTiKVマシンがスタックまたはダウンしている可能性があります。 #### `TiKV_async_request_snapshot_duration_seconds` {#tikv_async_request_snapshot_duration_seconds} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(tikv_storage_engine_async_request_duration_seconds_bucket{type="snapshot"}[1m])) by (le, instance, type)) > 1` -- 説明： +- 説明： この値が比較的大きい場合、 Raftstoreの負荷圧力が高すぎることを意味し、すでにスタックしている可能性があります。 -- 解決： +- 解決： [`TiKV_channel_full_total`](#tikv_channel_full_total)の解決策を参照してください。 #### `TiKV_async_request_write_duration_seconds` {#tikv_async_request_write_duration_seconds} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(tikv_storage_engine_async_request_duration_seconds_bucket{type="write"}[1m])) by (le, instance, type)) > 1` -- 説明： +- 説明： この値が比較的大きい場合、 Raft の書き込みに長い時間がかかることを意味します。 -- 解決： +- 解決： - 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)を参照してください。 + 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)を参照してください。 #### `TiKV_coprocessor_request_wait_seconds` {#tikv_coprocessor_request_wait_seconds} -- アラートルール: +- アラートルール: `histogram_quantile(0.9999, sum(rate(tikv_coprocessor_request_wait_seconds_bucket[1m])) by (le, instance, req)) > 10` -- 説明： +- 説明： この値が比較的大きい場合、コプロセッサーワーカーへの負荷が高いことを意味します。コプロセッサースレッドをスタックさせるような低速タスクが発生している可能性があります。 -- 解決： +- 解決： - 1. TiDB ログからスロー クエリ ログを確認し、クエリでインデックスまたは完全なテーブル スキャンが使用されているかどうか、または分析に必要かどうかを確認します。 - 2. ホットスポットがあるかどうかを確認します。 - 3. コプロセッサーモニターで、 `coprocessor table/index scan`の`total`と`process`が一致しているかどうかを確認してください。大きく異なる場合は、無効なクエリが多すぎることを示しています。`over seek bound`があるかどうかも確認できます。もしそうであれば、GC が時間内に処理できないバージョンが多すぎます。その場合は、並列 GC スレッドの数を増やす必要があります。 + 1. TiDB ログからスロー クエリ ログを確認し、クエリでインデックスまたは完全なテーブル スキャンが使用されているかどうか、または分析に必要かどうかを確認します。 + 2. ホットスポットがあるかどうかを確認します。 + 3. コプロセッサーモニターで、 `coprocessor table/index scan`の`total`と`process`が一致しているかどうかを確認してください。大きく異なる場合は、無効なクエリが多すぎることを示しています。`over seek bound`があるかどうかも確認できます。もしそうであれば、GC が時間内に処理できないバージョンが多すぎます。その場合は、並列 GC スレッドの数を増やす必要があります。 #### `TiKV_raftstore_thread_cpu_seconds_total` {#tikv_raftstore_thread_cpu_seconds_total} -- アラートルール: +- アラートルール: `sum(rate(tikv_thread_cpu_seconds_total{name=~"raftstore_.*"}[1m])) by (instance) > 1.6` -- 説明： +- 説明： このルールは、 Raftstoreによる CPU 使用率を監視します。値が高い場合、 Raftstoreスレッドへの負荷が高いことを示します。 アラートしきい値は[`raftstore.store-pool-size`](/tikv-configuration-file.md#store-pool-size)値の 80% です。`raftstore.store-pool-size`はデフォルトで 2 なので、アラートしきい値は 1.6 になります。 -- 解決： +- 解決： [`TiKV_channel_full_total`](#tikv_channel_full_total)の解決策を参照してください。 #### `TiKV_raft_append_log_duration_secs` {#tikv_raft_append_log_duration_secs} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(tikv_raftstore_append_log_duration_seconds_bucket[1m])) by (le, instance)) > 1` -- 説明： +- 説明： Raftログの追加にかかる時間コストを示します。この値が高い場合は、通常、I/Oが混雑していることを意味します。 #### `TiKV_raft_apply_log_duration_secs` {#tikv_raft_apply_log_duration_secs} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(tikv_raftstore_apply_log_duration_seconds_bucket[1m])) by (le, instance)) > 1` -- 説明： +- 説明： Raftログの適用にかかる時間コストを示します。この値が高い場合は、通常、I/Oが混雑していることを意味します。 #### `TiKV_scheduler_latch_wait_duration_seconds` {#tikv_scheduler_latch_wait_duration_seconds} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(tikv_scheduler_latch_wait_duration_seconds_bucket[1m])) by (le, instance, type)) > 1` -- 説明： +- 説明： スケジューラでメモリロックを取得するための書き込み操作の待機時間。この値が大きい場合、書き込みの競合が多数発生しているか、競合につながる操作の完了に時間がかかり、同じロックを待機している他の操作がブロックされている可能性があります。 -- 解決： +- 解決： - 1. `Scheduler`および`Scheduler-${cmd}` ( `${cmd}`はクエリへの書き込みコマンド) のモニターでスケジューラ コマンドの実行時間を表示して、最も時間のかかるコマンドを特定します。 - 2. `Scheduler`と`Scheduler-${cmd}`モニターのスケジューラ スキャンの詳細で`total`と`process`値を確認し、 `total`と`process`一致するかどうかを確認します。 - 3. ストレージ モニターでストレージの非同期スナップショット/書き込み期間を確認し、 Raft操作が時間どおりに実行されているかどうかを確認します。 + 1. `Scheduler`および`Scheduler-${cmd}` ( `${cmd}`はクエリへの書き込みコマンド) のモニターでスケジューラ コマンドの実行時間を表示して、最も時間のかかるコマンドを特定します。 + 2. `Scheduler`と`Scheduler-${cmd}`モニターのスケジューラ スキャンの詳細で`total`と`process`値を確認し、 `total`と`process`一致するかどうかを確認します。 + 3. ストレージ モニターでストレージの非同期スナップショット/書き込み期間を確認し、 Raft操作が時間どおりに実行されているかどうかを確認します。 #### `TiKV_thread_apply_worker_cpu_seconds` {#tikv_thread_apply_worker_cpu_seconds} -- アラートルール: +- アラートルール: `max(rate(tikv_thread_cpu_seconds_total{name=~"apply_.*"}[1m])) by (instance) > 0.9` -- 説明： +- 説明： Raftログ適用スレッドに大きな負荷がかかっており、限界に近づいているか、すでに限界を超えています。これは多くの場合、書き込みの集中によって発生します。 @@ -623,150 +623,150 @@ summary: TiDB クラスターのアラート ルールについて学習しま #### `TiKV_leader_drops` {#tikv_leader_drops} -- アラートルール: +- アラートルール: `delta(tikv_pd_heartbeat_tick_total{type="leader"}[30s]) < -10` -- 説明： +- 説明： これは多くの場合、 Raftstore のスレッドがスタックしていることが原因で発生します。 -- 解決： +- 解決： - 1. [`TiKV_channel_full_total`](#tikv_channel_full_total)を参照してください。 - 2. TiKVの負荷が低い場合は、PDスケジュールの頻度が高すぎないか検討してください。PDページのオペレータ作成パネルで、PDスケジュールの種類と数を確認できます。 + 1. [`TiKV_channel_full_total`](#tikv_channel_full_total)を参照してください。 + 2. TiKVの負荷が低い場合は、PDスケジュールの頻度が高すぎないか検討してください。PDページのオペレータ作成パネルで、PDスケジュールの種類と数を確認できます。 #### `TiKV_raft_process_ready_duration_secs` {#tikv_raft_process_ready_duration_secs} -- アラートルール: +- アラートルール: `histogram_quantile(0.999, sum(rate(tikv_raftstore_raft_process_duration_secs_bucket{type='ready'}[1m])) by (le, instance, type)) > 2` -- 説明： +- 説明： Raft準備完了の処理にかかる時間コストを示します。この値が大きい場合、ログ追加タスクのスタックが原因であることが多いです。 #### `TiKV_raft_process_tick_duration_secs` {#tikv_raft_process_tick_duration_secs} -- アラートルール: +- アラートルール: `histogram_quantile(0.999, sum(rate(tikv_raftstore_raft_process_duration_secs_bucket{type='tick'}[1m])) by (le, instance, type)) > 2` -- 説明： +- 説明： Raftティックの処理にかかる時間コストを示します。この値が大きい場合は、多くの場合、リージョンが多すぎることが原因です。 -- 解決： +- 解決： - 1. `warn`や`error`などの上位レベルのログの使用を検討してください。 - 2. `[raftstore]`構成の下に`raft-base-tick-interval = "2s"`追加します。 + 1. `warn`や`error`などの上位レベルのログの使用を検討してください。 + 2. `[raftstore]`構成の下に`raft-base-tick-interval = "2s"`追加します。 #### `TiKV_scheduler_context_total` {#tikv_scheduler_context_total} -- アラートルール: +- アラートルール: `abs(delta( tikv_scheduler_context_total[5m])) > 1000` -- 説明： +- 説明： スケジューラによって実行されている書き込みコマンドの数。この値が大きい場合、タスクが時間どおりに完了していないことを意味します。 -- 解決： +- 解決： [`TiKV_scheduler_latch_wait_duration_seconds`](#tikv_scheduler_latch_wait_duration_seconds)を参照してください。 #### `TiKV_scheduler_command_duration_seconds` {#tikv_scheduler_command_duration_seconds} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(tikv_scheduler_command_duration_seconds_bucket[1m])) by (le, instance, type)) > 1` -- 説明： +- 説明： スケジューラ コマンドの実行にかかる時間コストを示します。 -- 解決： +- 解決： [`TiKV_scheduler_latch_wait_duration_seconds`](#tikv_scheduler_latch_wait_duration_seconds)を参照してください。 #### `TiKV_coprocessor_outdated_request_wait_seconds` {#tikv_coprocessor_outdated_request_wait_seconds} -- アラートルール: +- アラートルール: `delta(tikv_coprocessor_outdated_request_wait_seconds_count[10m]) > 0` -- 説明： +- 説明： コプロセッサーによる期限切れリクエストの待機時間。この値が大きい場合、コプロセッサーへの負荷が高いことを意味します。 -- 解決： +- 解決： [`TiKV_coprocessor_request_wait_seconds`](#tikv_coprocessor_request_wait_seconds)を参照してください。 #### `TiKV_coprocessor_pending_request` {#tikv_coprocessor_pending_request} -- アラートルール: +- アラートルール: `delta(tikv_coprocessor_pending_request[10m]) > 5000` -- 説明： +- 説明： コプロセッサーのキューイング要求。 -- 解決： +- 解決： [`TiKV_coprocessor_request_wait_seconds`](#tikv_coprocessor_request_wait_seconds)を参照してください。 #### `TiKV_batch_request_snapshot_nums` {#tikv_batch_request_snapshot_nums} -- アラートルール: +- アラートルール: `sum(rate(tikv_thread_cpu_seconds_total{name=~"cop_.*"}[1m])) by (instance) / (count(tikv_thread_cpu_seconds_total{name=~"cop_.*"}) * 0.9) / count(count(tikv_thread_cpu_seconds_total) by (instance)) > 0` -- 説明： +- 説明： TiKV マシンのコプロセッサーCPU 使用率が 90% を超えています。 #### `TiKV_pending_task` {#tikv_pending_task} -- アラートルール: +- アラートルール: `sum(tikv_worker_pending_task_total) BY (instance,name) > 1000` -- 説明： +- 説明： TiKV の保留中のタスクの数。 -- 解決： +- 解決： [**TiKV詳細**>**タスク**ダッシュボード](/grafana-tikv-dashboard.md#task)のうち`Worker pending tasks`メトリックから、どの種類のタスクの値が高いかを確認します。 #### `TiKV_low_space` {#tikv_low_space} -- アラートルール: +- アラートルール: `sum(tikv_store_size_bytes{type="available"}) by (instance) / sum(tikv_store_size_bytes{type="capacity"}) by (instance) < 0.2` -- 説明： +- 説明： TiKV のデータ量が、構成されたノード容量またはマシンのディスク容量の 80% を超えています。 -- 解決： +- 解決： - - ノードスペースのバランス状態を確認します。 - - さまざまな状況に応じて、ディスク容量を増やすか、一部のデータを削除するか、クラスター ノードを増やす計画を立てます。 + - ノードスペースのバランス状態を確認します。 + - さまざまな状況に応じて、ディスク容量を増やすか、一部のデータを削除するか、クラスター ノードを増やす計画を立てます。 #### `TiKV_approximate_region_size` {#tikv_approximate_region_size} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(tikv_raftstore_region_size_bucket[1m])) by (le)) > 1073741824` -- 説明： +- 説明： TiKV 分割チェッカーによってスキャンされるリージョンの最大おおよそのサイズは、1 分以内に継続的に 1 GB を超えます。 -- 解決： +- 解決： リージョン分割の速度は書き込み速度よりも遅いです。この問題を軽減するには、TiDBをバッチ分割をサポートするバージョン（2.1.0-rc1以上）にアップデートすることをお勧めします。一時的にアップデートできない場合は、 `pd-ctl operator add split-region --policy=approximate`を使用して手動でリージョンを分割できます。 @@ -786,144 +786,144 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー #### `NODE_disk_used_more_than_80%` {#node_disk_used_more_than_80} -- アラートルール: +- アラートルール: `node_filesystem_avail_bytes{fstype=~"(ext.|xfs)", mountpoint!~"/boot"} / node_filesystem_size_bytes{fstype=~"(ext.|xfs)", mountpoint!~"/boot"} * 100 <= 20` -- 説明： +- 説明： マシンのディスク領域の使用率が 80% を超えています。 -- 解決： +- 解決： - - マシンにログインし、コマンド`df -h`を実行してディスク領域の使用量を確認します。 - - さまざまな状況に応じて、ディスク容量を増やすか、一部のデータを削除するか、クラスター ノードを増やす計画を立てます。 + - マシンにログインし、コマンド`df -h`を実行してディスク領域の使用量を確認します。 + - さまざまな状況に応じて、ディスク容量を増やすか、一部のデータを削除するか、クラスター ノードを増やす計画を立てます。 #### `NODE_disk_inode_more_than_80%` {#node_disk_inode_more_than_80} -- アラートルール: +- アラートルール: `node_filesystem_files_free{fstype=~"(ext.|xfs)"} / node_filesystem_files{fstype=~"(ext.|xfs)"} * 100 < 20` -- 説明： +- 説明： マシン上のファイルシステムの inode 使用率が 80% を超えています。 -- 解決： +- 解決： - - マシンにログインし、 `df -i`コマンドを実行してファイルシステムのノード使用状況を表示します。 - - さまざまな状況に応じて、ディスク容量を増やすか、一部のデータを削除するか、クラスター ノードを増やす計画を立てます。 + - マシンにログインし、 `df -i`コマンドを実行してファイルシステムのノード使用状況を表示します。 + - さまざまな状況に応じて、ディスク容量を増やすか、一部のデータを削除するか、クラスター ノードを増やす計画を立てます。 #### `NODE_disk_readonly` {#node_disk_readonly} -- アラートルール: +- アラートルール: `node_filesystem_readonly{fstype=~"(ext.|xfs)"} == 1` -- 説明： +- 説明： ファイルシステムは読み取り専用であり、データの書き込みはできません。これは、ディスク障害やファイルシステムの破損が原因であることが多いです。 -- 解決： +- 解決： - - マシンにログインし、正常かどうかをテストするためのファイルを作成します。 - - ディスクのLEDが正常かどうかを確認してください。正常でない場合は、ディスクを交換し、マシンのファイルシステムを修復してください。 + - マシンにログインし、正常かどうかをテストするためのファイルを作成します。 + - ディスクのLEDが正常かどうかを確認してください。正常でない場合は、ディスクを交換し、マシンのファイルシステムを修復してください。 ### 重大レベルのアラート {#critical-level-alerts} #### `NODE_memory_used_more_than_80%` {#node_memory_used_more_than_80} -- アラートルール: +- アラートルール: `(((node_memory_MemTotal_bytes-node_memory_MemFree_bytes-node_memory_Cached_bytes)/(node_memory_MemTotal_bytes)*100)) >= 80` -- 説明： +- 説明： マシンのメモリ使用量が80%を超えています。 -- 解決： +- 解決： - - Grafana Node Exporter ダッシュボードでホストのメモリ パネルを確認し、使用済みメモリが多すぎるかどうか、使用可能なメモリが少なすぎるかどうかを確認します。 - - マシンにログインし、コマンド`free -m`を実行してメモリ使用量を確認します。コマンド`top`を実行すると、メモリ使用量が過度に高い異常なプロセスがあるかどうかを確認できます。 + - Grafana Node Exporter ダッシュボードでホストのメモリ パネルを確認し、使用済みメモリが多すぎるかどうか、使用可能なメモリが少なすぎるかどうかを確認します。 + - マシンにログインし、コマンド`free -m`を実行してメモリ使用量を確認します。コマンド`top`を実行すると、メモリ使用量が過度に高い異常なプロセスがあるかどうかを確認できます。 ### 警告レベルのアラート {#warning-level-alerts-4} #### `NODE_node_overload` {#node_node_overload} -- アラートルール: +- アラートルール: `(node_load5 / count without (cpu, mode) (node_cpu_seconds_total{mode="system"})) > 1` -- 説明： +- 説明： マシンの CPU 負荷は比較的高くなっています。 -- 解決： - - Grafana Node Exporter ダッシュボードでホストの CPU 使用率と負荷平均を確認し、それらが高すぎないかどうかを確認します。 +- 解決： + - Grafana Node Exporter ダッシュボードでホストの CPU 使用率と負荷平均を確認し、それらが高すぎないかどうかを確認します。 - - マシンにログインして`top`を実行し、負荷平均と CPU 使用率をチェックして、CPU 使用率が過度に高い異常なプロセスがないか確認します。 + - マシンにログインして`top`を実行し、負荷平均と CPU 使用率をチェックして、CPU 使用率が過度に高い異常なプロセスがないか確認します。 #### `NODE_cpu_used_more_than_80%` {#node_cpu_used_more_than_80} -- アラートルール: +- アラートルール: `avg(irate(node_cpu_seconds_total{mode="idle"}[5m])) by(instance) * 100 <= 20` -- 説明： +- 説明： マシンのCPU使用率が80%を超えています。 -- 解決： - - Grafana Node Exporter ダッシュボードでホストの CPU 使用率と負荷平均を確認し、それらが高すぎないかどうかを確認します。 +- 解決： + - Grafana Node Exporter ダッシュボードでホストの CPU 使用率と負荷平均を確認し、それらが高すぎないかどうかを確認します。 - - マシンにログインして`top`を実行し、負荷平均と CPU 使用率をチェックして、CPU 使用率が過度に高い異常なプロセスがあるかどうかを確認します。 + - マシンにログインして`top`を実行し、負荷平均と CPU 使用率をチェックして、CPU 使用率が過度に高い異常なプロセスがあるかどうかを確認します。 #### `NODE_tcp_estab_num_more_than_50000` {#node_tcp_estab_num_more_than_50000} -- アラートルール: +- アラートルール: `node_netstat_Tcp_CurrEstab > 50000` -- 説明： +- 説明： マシン上には「確立」ステータスの TCP リンクが 50,000 個以上あります。 -- 解決： +- 解決： - - マシンにログインし、 `ss -s`を実行して、現在のシステムで「estab」ステータスにある TCP リンクの数を確認します。 - - `netstat`を実行して異常なリンクがないか確認します。 + - マシンにログインし、 `ss -s`を実行して、現在のシステムで「estab」ステータスにある TCP リンクの数を確認します。 + - `netstat`を実行して異常なリンクがないか確認します。 #### `NODE_disk_read_latency_more_than_32ms` {#node_disk_read_latency_more_than_32ms} -- アラートルール: +- アラートルール: `((rate(node_disk_read_time_seconds_total{device=~".+"}[5m]) / rate(node_disk_reads_completed_total{device=~".+"}[5m])) or (irate(node_disk_read_time_seconds_total{device=~".+"}[5m]) / irate(node_disk_reads_completed_total{device=~".+"}[5m])) ) * 1000 > 32` -- 説明： +- 説明： ディスクの読み取りレイテンシーが 32 ミリ秒を超えています。 -- 解決： +- 解決： - - Grafana ディスク パフォーマンス ダッシュボードを表示して、ディスクの状態を確認します。 - - ディスク レイテンシ パネルを表示して、ディスクの読み取りレイテンシーを確認します。 - - ディスク I/O 使用率パネルを表示して、I/O 使用率を確認します。 + - Grafana ディスク パフォーマンス ダッシュボードを表示して、ディスクの状態を確認します。 + - ディスク レイテンシ パネルを表示して、ディスクの読み取りレイテンシーを確認します。 + - ディスク I/O 使用率パネルを表示して、I/O 使用率を確認します。 #### `NODE_disk_write_latency_more_than_16ms` {#node_disk_write_latency_more_than_16ms} -- アラートルール: +- アラートルール: `((rate(node_disk_write_time_seconds_total{device=~".+"}[5m]) / rate(node_disk_writes_completed_total{device=~".+"}[5m])) or (irate(node_disk_write_time_seconds_total{device=~".+"}[5m]) / irate(node_disk_writes_completed_total{device=~".+"}[5m])))> 16` -- 説明： +- 説明： ディスクの書き込みレイテンシーが 16 ミリ秒を超えています。 -- 解決： +- 解決： - - Grafana ディスク パフォーマンス ダッシュボードを表示して、ディスクの状態を確認します。 - - ディスク レイテンシ パネルを表示して、ディスクの書き込みレイテンシーを確認します。 - - ディスク I/O 使用率パネルを表示して、I/O 使用率を確認します。 + - Grafana ディスク パフォーマンス ダッシュボードを表示して、ディスクの状態を確認します。 + - ディスク レイテンシ パネルを表示して、ディスクの書き込みレイテンシーを確認します。 + - ディスク I/O 使用率パネルを表示して、I/O 使用率を確認します。 ## Blackbox_exporter TCP、ICMP、HTTP アラートルール {#blackbox_exporter-tcp-icmp-and-http-alert-rules} @@ -933,177 +933,177 @@ TiCDC アラート ルールの詳細な説明については、 [TiCDCアラー #### `TiDB_server_is_down` {#tidb_server_is_down} -- アラートルール: +- アラートルール: `probe_success{group="tidb"} == 0` -- 説明： +- 説明： TiDB サービス ポートのプローブに失敗しました。 -- 解決： +- 解決： - - TiDB サービスを提供するマシンがダウンしていないかどうかを確認します。 - - TiDB プロセスが存在するかどうかを確認します。 - - 監視マシンと TiDB マシン間のネットワークが正常かどうかを確認します。 + - TiDB サービスを提供するマシンがダウンしていないかどうかを確認します。 + - TiDB プロセスが存在するかどうかを確認します。 + - 監視マシンと TiDB マシン間のネットワークが正常かどうかを確認します。 #### `TiFlash_server_is_down` {#tiflash_server_is_down} -- アラートルール: +- アラートルール: `probe_success{group="tiflash"} == 0` -- 説明： +- 説明： TiFlashサービス ポートのプローブに失敗しました。 -- 解決： +- 解決： - - TiFlashサービスを提供するマシンがダウンしていないかどうかを確認します。 - - TiFlashプロセスが存在するかどうかを確認します。 - - 監視マシンとTiFlashマシン間のネットワークが正常かどうかを確認します。 + - TiFlashサービスを提供するマシンがダウンしていないかどうかを確認します。 + - TiFlashプロセスが存在するかどうかを確認します。 + - 監視マシンとTiFlashマシン間のネットワークが正常かどうかを確認します。 #### `TiKV_server_is_down` {#tikv_server_is_down} -- アラートルール: +- アラートルール: `probe_success{group="tikv"} == 0` -- 説明： +- 説明： TiKV サービス ポートのプローブに失敗しました。 -- 解決： +- 解決： - - TiKV サービスを提供するマシンがダウンしていないかどうかを確認します。 - - TiKV プロセスが存在するかどうかを確認します。 - - 監視マシンと TiKV マシン間のネットワークが正常かどうかを確認します。 + - TiKV サービスを提供するマシンがダウンしていないかどうかを確認します。 + - TiKV プロセスが存在するかどうかを確認します。 + - 監視マシンと TiKV マシン間のネットワークが正常かどうかを確認します。 #### `PD_server_is_down` {#pd_server_is_down} -- アラートルール: +- アラートルール: `probe_success{group="pd"} == 0` -- 説明： +- 説明： PD サービス ポートのプローブに失敗しました。 -- 解決： +- 解決： - - PD サービスを提供するマシンがダウンしていないかどうかを確認します。 - - PD プロセスが存在するかどうかを確認します。 - - 監視マシンとPDマシン間のネットワークが正常かどうかを確認します。 + - PD サービスを提供するマシンがダウンしていないかどうかを確認します。 + - PD プロセスが存在するかどうかを確認します。 + - 監視マシンとPDマシン間のネットワークが正常かどうかを確認します。 #### `Node_exporter_server_is_down` {#node_exporter_server_is_down} -- アラートルール: +- アラートルール: `probe_success{group="node_exporter"} == 0` -- 説明： +- 説明： Node_exporter サービス ポートのプローブに失敗しました。 -- 解決： +- 解決： - - Node_exporter サービスを提供するマシンがダウンしていないかどうかを確認します。 - - Node_exporter プロセスが存在するかどうかを確認します。 - - 監視マシンとNode_exporterマシン間のネットワークが正常かどうかを確認します。 + - Node_exporter サービスを提供するマシンがダウンしていないかどうかを確認します。 + - Node_exporter プロセスが存在するかどうかを確認します。 + - 監視マシンとNode_exporterマシン間のネットワークが正常かどうかを確認します。 #### `Blackbox_exporter_server_is_down` {#blackbox_exporter_server_is_down} -- アラートルール: +- アラートルール: `probe_success{group="blackbox_exporter"} == 0` -- 説明： +- 説明： Blackbox_Exporter サービス ポートのプローブに失敗しました。 -- 解決： +- 解決： - - Blackbox_Exporter サービスを提供するマシンがダウンしていないかどうかを確認します。 - - Blackbox_Exporter プロセスが存在するかどうかを確認します。 - - 監視マシンと Blackbox_Exporter マシン間のネットワークが正常かどうかを確認します。 + - Blackbox_Exporter サービスを提供するマシンがダウンしていないかどうかを確認します。 + - Blackbox_Exporter プロセスが存在するかどうかを確認します。 + - 監視マシンと Blackbox_Exporter マシン間のネットワークが正常かどうかを確認します。 #### `Grafana_server_is_down` {#grafana_server_is_down} -- アラートルール: +- アラートルール: `probe_success{group="grafana"} == 0` -- 説明： +- 説明： Grafana サービス ポートのプローブに失敗しました。 -- 解決： +- 解決： - - Grafana サービスを提供するマシンがダウンしていないかどうかを確認します。 - - Grafana プロセスが存在するかどうかを確認します。 - - 監視マシンと Grafana マシン間のネットワークが正常かどうかを確認します。 + - Grafana サービスを提供するマシンがダウンしていないかどうかを確認します。 + - Grafana プロセスが存在するかどうかを確認します。 + - 監視マシンと Grafana マシン間のネットワークが正常かどうかを確認します。 #### `Pushgateway_server_is_down` {#pushgateway_server_is_down} -- アラートルール: +- アラートルール: `probe_success{group="pushgateway"} == 0` -- 説明： +- 説明： Pushgateway サービス ポートのプローブに失敗しました。 -- 解決： +- 解決： - - Pushgateway サービスを提供するマシンがダウンしていないかどうかを確認します。 - - Pushgateway プロセスが存在するかどうかを確認します。 - - 監視マシンと Pushgateway マシン間のネットワークが正常かどうかを確認します。 + - Pushgateway サービスを提供するマシンがダウンしていないかどうかを確認します。 + - Pushgateway プロセスが存在するかどうかを確認します。 + - 監視マシンと Pushgateway マシン間のネットワークが正常かどうかを確認します。 #### `Kafka_exporter_is_down` {#kafka_exporter_is_down} -- アラートルール: +- アラートルール: `probe_success{group="kafka_exporter"} == 0` -- 説明： +- 説明： Kafka_Exporter サービス ポートのプローブに失敗しました。 -- 解決： +- 解決： - - Kafka_Exporter サービスを提供するマシンがダウンしていないかどうかを確認します。 - - Kafka_Exporter プロセスが存在するかどうかを確認します。 - - 監視マシンと Kafka_Exporter マシン間のネットワークが正常かどうかを確認します。 + - Kafka_Exporter サービスを提供するマシンがダウンしていないかどうかを確認します。 + - Kafka_Exporter プロセスが存在するかどうかを確認します。 + - 監視マシンと Kafka_Exporter マシン間のネットワークが正常かどうかを確認します。 #### `Pushgateway_metrics_interface` {#pushgateway_metrics_interface} -- アラートルール: +- アラートルール: `probe_success{job="blackbox_exporter_http"} == 0` -- 説明： +- 説明： Pushgateway サービスの http インターフェースのプローブに失敗しました。 -- 解決： +- 解決： - - Pushgateway サービスを提供するマシンがダウンしていないかどうかを確認します。 - - Pushgateway プロセスが存在するかどうかを確認します。 - - 監視マシンと Pushgateway マシン間のネットワークが正常かどうかを確認します。 + - Pushgateway サービスを提供するマシンがダウンしていないかどうかを確認します。 + - Pushgateway プロセスが存在するかどうかを確認します。 + - 監視マシンと Pushgateway マシン間のネットワークが正常かどうかを確認します。 ### 警告レベルのアラート {#warning-level-alerts} #### `BLACKER_ping_latency_more_than_1s` {#blacker_ping_latency_more_than_1s} -- アラートルール: +- アラートルール: `max_over_time(probe_duration_seconds{job=~"blackbox_exporter.*_icmp"}[1m]) > 1` -- 説明： +- 説明： ping のレイテンシーが1 秒を超えています。 -- 解決： +- 解決： - - Grafana Blackbox Exporter ページで 2 つのノード間の pingレイテンシーを確認し、遅延が高すぎないかどうかを確認します。 - - Grafana Node Exporter ページの TCP パネルをチェックして、パケット損失があるかどうかを確認します。 + - Grafana Blackbox Exporter ページで 2 つのノード間の pingレイテンシーを確認し、遅延が高すぎないかどうかを確認します。 + - Grafana Node Exporter ページの TCP パネルをチェックして、パケット損失があるかどうかを確認します。 diff --git a/analyze-slow-queries.md b/analyze-slow-queries.md index bcb9fb3e174e8..5e24fb4c10e4e 100644 --- a/analyze-slow-queries.md +++ b/analyze-slow-queries.md @@ -7,8 +7,8 @@ summary: スロークエリを見つけて分析する方法を学びます。 クエリの速度低下の問題を解決するには、次の 2 つの手順を実行する必要があります。 -1. 多数のクエリの中で、どのタイプのクエリが遅いかを特定します。 -2. このタイプのクエリが遅い理由を分析します。 +1. 多数のクエリの中で、どのタイプのクエリが遅いかを特定します。 +2. このタイプのクエリが遅い理由を分析します。 [スロークエリログ](/dashboard/dashboard-slow-query.md)と[ステートメントサマリーテーブル](/statement-summary-tables.md)機能を使えば、ステップ1は簡単に実行できます。2つの機能を統合し、スロークエリをブラウザに直接表示する[TiDB Dashboard](/dashboard/dashboard-intro.md)のご利用をお勧めします。 @@ -16,16 +16,16 @@ summary: スロークエリを見つけて分析する方法を学びます。 一般的に、クエリが遅くなる主な原因は次のとおりです。 -- 間違ったインデックスが選択された、間違った結合タイプまたはシーケンスが選択されたなどのオプティマイザーの問題。 -- システムの問題。オプティマイザーが原因ではない問題はすべてシステムの問題です。例えば、TiKVインスタンスがビジー状態だとリクエストの処理が遅くなったり、リージョン情報が古くなるとクエリが遅くなったりします。 +- 間違ったインデックスが選択された、間違った結合タイプまたはシーケンスが選択されたなどのオプティマイザーの問題。 +- システムの問題。オプティマイザーが原因ではない問題はすべてシステムの問題です。例えば、TiKVインスタンスがビジー状態だとリクエストの処理が遅くなったり、リージョン情報が古くなるとクエリが遅くなったりします。 実際の状況では、オプティマイザの問題がシステムの問題を引き起こす可能性があります。例えば、特定の種類のクエリでは、オプティマイザはインデックスではなくフルテーブルスキャンを使用します。その結果、SQLクエリが多くのリソースを消費し、一部のTiKVインスタンスのCPU使用率が急上昇します。これはシステムの問題のように見えますが、実際にはオプティマイザの問題です。 システムの問題を特定するのは比較的簡単です。オプティマイザの問題を分析するには、実行計画が妥当かどうかを判断する必要があります。そのため、以下の手順に従ってスロークエリを分析することをお勧めします。 -1. クエリのパフォーマンスのボトルネック、つまりクエリ プロセスの中で時間のかかる部分を特定します。 -2. システムの問題を分析します。クエリのボトルネックとその時点の監視/ログ情報に基づいて、考えられる原因を分析します。 -3. オプティマイザーの問題を分析します。より優れた実行計画があるかどうかを分析します。 +1. クエリのパフォーマンスのボトルネック、つまりクエリ プロセスの中で時間のかかる部分を特定します。 +2. システムの問題を分析します。クエリのボトルネックとその時点の監視/ログ情報に基づいて、考えられる原因を分析します。 +3. オプティマイザーの問題を分析します。より優れた実行計画があるかどうかを分析します。 上記の手順については、次のセクションで説明します。 @@ -35,13 +35,13 @@ summary: スロークエリを見つけて分析する方法を学びます。 次の方法を使用して期間情報を取得できます。 -- [スローログ](/identify-slow-queries.md) 。スローログは[TiDB Dashboard](/dashboard/dashboard-overview.md)で表示することをお勧めします。 -- [`EXPLAIN ANALYZE`ステートメント](/sql-statements/sql-statement-explain-analyze.md) 。 +- [スローログ](/identify-slow-queries.md) 。スローログは[TiDB Dashboard](/dashboard/dashboard-overview.md)で表示することをお勧めします。 +- [`EXPLAIN ANALYZE`ステートメント](/sql-statements/sql-statement-explain-analyze.md) 。 上記の方法は、以下の点で異なります。 -- スロー ログには、解析から結果の返却まで、SQL 実行のほぼすべての段階の期間が記録され、比較的包括的です (TiDB Dashboardでスロー ログを直感的にクエリおよび分析できます)。 -- `EXPLAIN ANALYZE`を実行すると、実際のSQL実行における各演算子の消費時間を知ることができます。結果には、実行時間に関するより詳細な統計情報が含まれます。 +- スロー ログには、解析から結果の返却まで、SQL 実行のほぼすべての段階の期間が記録され、比較的包括的です (TiDB Dashboardでスロー ログを直感的にクエリおよび分析できます)。 +- `EXPLAIN ANALYZE`を実行すると、実際のSQL実行における各演算子の消費時間を知ることができます。結果には、実行時間に関するより詳細な統計情報が含まれます。 まとめると、スローログと`EXPLAIN ANALYZE`ステートメントは、SQLクエリの実行がどのコンポーネント（TiDBまたはTiKV）でどの段階で遅いのかを判断するのに役立ちます。これにより、クエリのパフォーマンスボトルネックを正確に特定できます。 @@ -51,9 +51,9 @@ summary: スロークエリを見つけて分析する方法を学びます。 システムの問題は、SQL ステートメントのさまざまな実行段階に応じて、次の種類に分類できます。 -1. TiKVはデータ処理が遅いです。例えば、TiKVコプロセッサはデータの処理が遅いです。 -2. TiDB は実行速度が遅いです。例えば、 `Join`演算子はデータの処理速度が遅くなります。 -3. その他の重要な段階は遅いです。例えば、タイムスタンプの取得に長い時間がかかります。 +1. TiKVはデータ処理が遅いです。例えば、TiKVコプロセッサはデータの処理が遅いです。 +2. TiDB は実行速度が遅いです。例えば、 `Join`演算子はデータの処理速度が遅くなります。 +3. その他の重要な段階は遅いです。例えば、タイムスタンプの取得に長い時間がかかります。 スロークエリごとに、まずクエリがどのタイプに属するかを判断し、詳細に分析します。 @@ -240,11 +240,11 @@ mysql> explain select * from t t1, t t2 where t1.a>t2.a; 次の例では、テーブル スキーマが`create table t (id int, a int, b int, c int, primary key(id), key(a), key(b, c))`であると想定します。 -1. `select * from t` : フィルター条件はなく、テーブル全体のスキャンが実行されます。そのため、データの読み取りには`TableFullScan`演算子が使用されます。 -2. `select a from t where a=2` : フィルター条件があり、インデックス列のみが読み取られるため、 `IndexReader`演算子を使用してデータを読み取ります。 -3. `select * from t where a=2` : `a`のフィルター条件がありますが、 `a`インデックスでは読み取るデータを完全にカバーできないため、 `IndexLookup`演算子が使用されます。 -4. `select b from t where c=3` : プレフィックス条件がないと、マルチカラムインデックスは使用できません。そのため、 `IndexFullScan`が使用されます。 -5. ... +1. `select * from t` : フィルター条件はなく、テーブル全体のスキャンが実行されます。そのため、データの読み取りには`TableFullScan`演算子が使用されます。 +2. `select a from t where a=2` : フィルター条件があり、インデックス列のみが読み取られるため、 `IndexReader`演算子を使用してデータを読み取ります。 +3. `select * from t where a=2` : `a`のフィルター条件がありますが、 `a`インデックスでは読み取るデータを完全にカバーできないため、 `IndexLookup`演算子が使用されます。 +4. `select b from t where c=3` : プレフィックス条件がないと、マルチカラムインデックスは使用できません。そのため、 `IndexFullScan`が使用されます。 +5. ... 上記の例は、データ読み取りに使用される演算子です。その他の演算子については、 [TiDB実行計画を理解する](/explain-overview.md)を参照してください。 @@ -252,6 +252,6 @@ mysql> explain select * from t t1, t t2 where t1.a>t2.a; オプティマイザに関する問題のほとんどは[SQLチューニングの概要](/sql-tuning-overview.md)で説明されています。解決策については、以下のドキュメントを参照してください。 -1. [インデックス問題の解決方法](/wrong-index-solution.md) -2. [結合順序が間違っています](/join-reorder.md) -3. [式はプッシュダウンできない](/blocklist-control-plan.md) +1. [インデックス問題の解決方法](/wrong-index-solution.md) +2. [結合順序が間違っています](/join-reorder.md) +3. [式はプッシュダウンできない](/blocklist-control-plan.md) diff --git a/api/dm-api-overview.md b/api/dm-api-overview.md index 6d0fa9b7e0996..2ce83e8222be1 100644 --- a/api/dm-api-overview.md +++ b/api/dm-api-overview.md @@ -11,8 +11,8 @@ DM は、 [dmctlツール](/dm/dmctl-introduction.md)と同様に、DM クラス DM API を使用して、DM クラスターで次のメンテナンス操作を実行できます。 -- [クラスタ管理](/dm/dm-open-api.md#apis-for-managing-clusters) : DM マスター ノードと DM ワーカー ノードに関する情報を取得したり、停止したりします。 -- [データソース管理](/dm/dm-open-api.md#apis-for-managing-data-sources) : データ ソースを作成、更新、削除、有効化、無効化し、リレー ログ機能を管理し、データ ソースと DM ワーカー間のバインディングを変更します。 -- [レプリケーションタスク管理](/dm/dm-open-api.md#apis-for-managing-replication-tasks) : レプリケーション タスクを作成、更新、削除、開始、または停止し、スキーマと移行ルールを管理します。 +- [クラスタ管理](/dm/dm-open-api.md#apis-for-managing-clusters) : DM マスター ノードと DM ワーカー ノードに関する情報を取得したり、停止したりします。 +- [データソース管理](/dm/dm-open-api.md#apis-for-managing-data-sources) : データ ソースを作成、更新、削除、有効化、無効化し、リレー ログ機能を管理し、データ ソースと DM ワーカー間のバインディングを変更します。 +- [レプリケーションタスク管理](/dm/dm-open-api.md#apis-for-managing-replication-tasks) : レプリケーション タスクを作成、更新、削除、開始、または停止し、スキーマと移行ルールを管理します。 リクエストパラメータ、レスポンス例、使用方法など、各 API の詳細については、 [OpenAPI を使用して DM クラスターを管理](/dm/dm-open-api.md)を参照してください。 diff --git a/api/monitoring-api-overview.md b/api/monitoring-api-overview.md index 7e44d92a4cd14..9379ecb51d758 100644 --- a/api/monitoring-api-overview.md +++ b/api/monitoring-api-overview.md @@ -9,7 +9,7 @@ TiDB モニタリングフレームワークは、 [Prometheus](https://promethe 次のインターフェースを使用して、TiDB クラスターのステータスを監視できます。 -- [ステータスインターフェース](/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 を使用してこれらのメトリックを表示します。 +- [ステータスインターフェース](/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)を参照してください。 diff --git a/api/ticdc-api-overview.md b/api/ticdc-api-overview.md index 5d75e3e35bd98..90800156b915e 100644 --- a/api/ticdc-api-overview.md +++ b/api/ticdc-api-overview.md @@ -9,8 +9,8 @@ summary: TiCDC の API を学習します。 TiCDC は、TiCDC クラスターのクエリと操作用に次の 2 つのバージョンの API を提供します。 -- [TiCDC OpenAPI v1](/ticdc/ticdc-open-api.md) -- [TiCDC OpenAPI v2](/ticdc/ticdc-open-api-v2.md) +- [TiCDC OpenAPI v1](/ticdc/ticdc-open-api.md) +- [TiCDC OpenAPI v2](/ticdc/ticdc-open-api-v2.md) > **Note:** > diff --git a/api/tidb-cloud-api-overview.md b/api/tidb-cloud-api-overview.md index 4e211b1cf0206..ab86c44d6f853 100644 --- a/api/tidb-cloud-api-overview.md +++ b/api/tidb-cloud-api-overview.md @@ -14,12 +14,12 @@ TiDB Cloud APIは[RESTインターフェース](https://en.wikipedia.org/wiki/Re このAPIには以下の機能があります。 -- **JSONエンティティ。**すべてのエンティティはJSON形式で表現されます。 -- **HTTPSのみ対応。API**へのアクセスはHTTPS経由でのみ可能で、ネットワーク上で送信されるすべてのデータはTLSで暗号化されます。 -- **キーベースのアクセスとダイジェスト認証。** TiDB Cloud API にアクセスする前に、API キーを生成する必要があります。詳細については、 [APIキー管理](https://docs.pingcap.com/tidbcloud/api/v1beta#section/Authentication/API-key-management)を参照してください。すべてのリクエストは[HTTPダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)を通じて認証され、API キーがネットワーク経由で送信されることはありません。 +- **JSONエンティティ。**すべてのエンティティはJSON形式で表現されます。 +- **HTTPSのみ対応。API**へのアクセスはHTTPS経由でのみ可能で、ネットワーク上で送信されるすべてのデータはTLSで暗号化されます。 +- **キーベースのアクセスとダイジェスト認証。** TiDB Cloud API にアクセスする前に、API キーを生成する必要があります。詳細については、 [APIキー管理](https://docs.pingcap.com/tidbcloud/api/v1beta#section/Authentication/API-key-management)を参照してください。すべてのリクエストは[HTTPダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)を通じて認証され、API キーがネットワーク経由で送信されることはありません。 TiDB Cloud APIは、以下のバージョンで利用可能です。 -- [v1beta2](/api/tidb-cloud-api-v1beta2.md) ： TiDB Cloud Premiumインスタンスを管理します。 -- [v1beta1](/api/tidb-cloud-api-v1beta1.md) ： TiDB Cloud Starter、 Essential、およびDedicatedクラスタ、ならびに課金、Data Service、およびIAMリソースを管理します。 -- [v1beta](/api/tidb-cloud-api-v1beta.md) : TiDB Cloudのプロジェクト、クラスター、バックアップ、インポート、リストアを管理します。 +- [v1beta2](/api/tidb-cloud-api-v1beta2.md) ： TiDB Cloud Premiumインスタンスを管理します。 +- [v1beta1](/api/tidb-cloud-api-v1beta1.md) ： TiDB Cloud Starter、 Essential、およびDedicatedクラスタ、ならびに課金、Data Service、およびIAMリソースを管理します。 +- [v1beta](/api/tidb-cloud-api-v1beta.md) : TiDB Cloudのプロジェクト、クラスター、バックアップ、インポート、リストアを管理します。 diff --git a/api/tidb-cloud-api-v1beta.md b/api/tidb-cloud-api-v1beta.md index 4e5b4f8f18b84..e1d90549fdd2e 100644 --- a/api/tidb-cloud-api-v1beta.md +++ b/api/tidb-cloud-api-v1beta.md @@ -9,8 +9,8 @@ summary: TiDB Cloudの v1beta API について学習します。 現在、次の v1beta API を使用してTiDB Cloud内のリソースを管理できます。 -- [プロジェクト](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Project) -- [クラスタ](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Cluster) -- [バックアップ](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Backup) -- [インポート（非推奨）](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Import) -- [復元](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Restore) +- [プロジェクト](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Project) +- [クラスタ](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Cluster) +- [バックアップ](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Backup) +- [インポート（非推奨）](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Import) +- [復元](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Restore) diff --git a/api/tidb-cloud-api-v1beta1.md b/api/tidb-cloud-api-v1beta1.md index 3a15113f6f07d..00a3008a4580a 100644 --- a/api/tidb-cloud-api-v1beta1.md +++ b/api/tidb-cloud-api-v1beta1.md @@ -9,11 +9,11 @@ TiDB Cloud API v1beta1 は、 TiDB Cloud内の管理オブジェクトをプロ 現在、次の v1beta1 API を使用してTiDB Cloud内のリソースを管理できます。 -- クラスターレベルのリソース: - - [TiDB Cloud Starter または Essential クラスタ](https://docs.pingcap.com/tidbcloud/api/v1beta1/serverless) : TiDB Cloud Starter または Essential クラスターのクラスター、ブランチ、データ エクスポート タスク、およびデータ インポート タスクを管理します。 - - [TiDB Cloud Dedicatedクラスタ](https://docs.pingcap.com/tidbcloud/api/v1beta1/dedicated) : TiDB Cloud Dedicated クラスターのクラスター、リージョン、プライベート エンドポイント接続、およびデータ インポート タスクを管理します。 -- 組織またはプロジェクトレベルのリソース: - - [請求](https://docs.pingcap.com/tidbcloud/api/v1beta1/billing) : TiDB Cloudクラスターの課金を管理します。 - - [Data Service](https://docs.pingcap.com/tidbcloud/api/v1beta1/dataservice) : TiDB CloudクラスターのData Service内のリソースを管理します。 - - [IAM](https://docs.pingcap.com/tidbcloud/api/v1beta1/iam) : TiDB Cloudクラスターの API キーを管理します。 - - [MSP（非推奨）](https://docs.pingcap.com/tidbcloud/api/v1beta1/msp) +- クラスターレベルのリソース: + - [TiDB Cloud Starter または Essential クラスタ](https://docs.pingcap.com/tidbcloud/api/v1beta1/serverless) : TiDB Cloud Starter または Essential クラスターのクラスター、ブランチ、データ エクスポート タスク、およびデータ インポート タスクを管理します。 + - [TiDB Cloud Dedicatedクラスタ](https://docs.pingcap.com/tidbcloud/api/v1beta1/dedicated) : TiDB Cloud Dedicated クラスターのクラスター、リージョン、プライベート エンドポイント接続、およびデータ インポート タスクを管理します。 +- 組織またはプロジェクトレベルのリソース: + - [請求](https://docs.pingcap.com/tidbcloud/api/v1beta1/billing) : TiDB Cloudクラスターの課金を管理します。 + - [Data Service](https://docs.pingcap.com/tidbcloud/api/v1beta1/dataservice) : TiDB CloudクラスターのData Service内のリソースを管理します。 + - [IAM](https://docs.pingcap.com/tidbcloud/api/v1beta1/iam) : TiDB Cloudクラスターの API キーを管理します。 + - [MSP（非推奨）](https://docs.pingcap.com/tidbcloud/api/v1beta1/msp) diff --git a/api/tidb-cloud-api-v1beta2.md b/api/tidb-cloud-api-v1beta2.md index 0775d96a58c78..3a582b54ffc51 100644 --- a/api/tidb-cloud-api-v1beta2.md +++ b/api/tidb-cloud-api-v1beta2.md @@ -1,5 +1,5 @@ --- -title: TiDB Cloud API v1beta2 Overview +title: TiDB Cloud API v1beta2 Overview summary: TiDB Cloudのv1beta2 APIについて学びましょう。 --- @@ -9,8 +9,8 @@ TiDB Cloud API v1beta2は、 [TiDB Cloud Premium](/tidb-cloud/select-cluster-tie 現在、 TiDB Cloud Premium のリソースを管理するには、以下の v1beta2 API を使用できます。 -- [TiDB Cloud Premium API](https://docs.pingcap.com/tidbcloud/api/v1beta2/premium) ： TiDB Cloud Premiumインスタンス、バックアップ、リージョンを管理します。このAPIには以下のリソースが含まれています。 +- [TiDB Cloud Premium API](https://docs.pingcap.com/tidbcloud/api/v1beta2/premium) ： TiDB Cloud Premiumインスタンス、バックアップ、リージョンを管理します。このAPIには以下のリソースが含まれています。 - - **TiDB Cloud Premiumインスタンス**：パスワード、CA証明書、クラウドプロバイダー情報など、 TiDB Cloud Premiumインスタンスのライフサイクルと構成を管理します。 - - **バックアップ**： TiDB Cloud Premiumインスタンスのバックアップを管理します。バックアップベースのリストア機能も含まれます。 - - **リージョン**： TiDB Cloud Premiumインスタンスを作成するために利用可能なリージョンを取得します。 + - **TiDB Cloud Premiumインスタンス**：パスワード、CA証明書、クラウドプロバイダー情報など、 TiDB Cloud Premiumインスタンスのライフサイクルと構成を管理します。 + - **バックアップ**： TiDB Cloud Premiumインスタンスのバックアップを管理します。バックアップベースのリストア機能も含まれます。 + - **リージョン**： TiDB Cloud Premiumインスタンスを作成するために利用可能なリージョンを取得します。 diff --git a/api/tidb-operator-api-overview.md b/api/tidb-operator-api-overview.md index 60dc38ae475ec..8de78d20ec3f7 100644 --- a/api/tidb-operator-api-overview.md +++ b/api/tidb-operator-api-overview.md @@ -9,12 +9,12 @@ summary: TiDB Operatorの API を学習します。 Kubernetes 上で TiDB クラスターを管理するには、次のTiDB Operator API を使用できます。 -- [Backup](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#backup) -- [BackupSchedule](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#backupschedule) -- [DMCluster](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#dmcluster) -- [Restore](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#restore) -- [TidbCluster](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#tidbcluster) -- [TidbInitializer](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#tidbinitializer) -- [TidbMonitor](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#tidbmonitor) +- [Backup](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#backup) +- [BackupSchedule](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#backupschedule) +- [DMCluster](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#dmcluster) +- [Restore](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#restore) +- [TidbCluster](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#tidbcluster) +- [TidbInitializer](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#tidbinitializer) +- [TidbMonitor](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#tidbmonitor) 詳細については[TiDB Operator API ドキュメント](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 abf680d85133c..aa129e80d505c 100644 --- a/api/tiproxy-api-overview.md +++ b/api/tiproxy-api-overview.md @@ -11,9 +11,9 @@ TiProxy はオプションのコンポーネントです。サードパーティ TiProxy API を使用して、TiProxy クラスターで次の操作を実行できます。 -- [TiProxy の設定を取得する](/tiproxy/tiproxy-api.md#get-tiproxy-configuration) -- [TiProxy設定を設定する](/tiproxy/tiproxy-api.md#set-tiproxy-configuration) -- [TiProxy のヘルスステータスを取得する](/tiproxy/tiproxy-api.md#get-tiproxy-health-status) -- [TiProxy監視データを取得する](/tiproxy/tiproxy-api.md#get-tiproxy-monitoring-data) +- [TiProxy の設定を取得する](/tiproxy/tiproxy-api.md#get-tiproxy-configuration) +- [TiProxy設定を設定する](/tiproxy/tiproxy-api.md#set-tiproxy-configuration) +- [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)を参照してください。 diff --git a/as-of-timestamp.md b/as-of-timestamp.md index bdced1f8f79cb..ccfd9c82e9012 100644 --- a/as-of-timestamp.md +++ b/as-of-timestamp.md @@ -17,9 +17,9 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標 `AS OF TIMESTAMP`句は次の 3 つの方法で使用できます。 -- [`SELECT ... FROM ... AS OF TIMESTAMP`](/sql-statements/sql-statement-select.md) -- [`START TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-start-transaction.md) -- [`SET TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-set-transaction.md) +- [`SELECT ... FROM ... AS OF TIMESTAMP`](/sql-statements/sql-statement-select.md) +- [`START TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-start-transaction.md) +- [`SET TRANSACTION READ ONLY AS OF TIMESTAMP`](/sql-statements/sql-statement-set-transaction.md) 正確な時刻を指定したい場合は、 `AS OF TIMESTAMP`句に datetime 値を設定するか、time 関数を使用します。datetime の形式は「2016-10-08 16:45:26.999」のように、最小の時間単位はミリ秒ですが、ほとんどの場合、datetime を指定するには「2016-10-08 16:45:26」のように秒単位で十分です。`NOW(3)`関数を使用して、現在時刻をミリ秒単位で取得することもできます。数秒前のデータを読み取りたい場合は、 `NOW() - INTERVAL 10 SECOND`のような式を使用することを**お勧めします**。 @@ -27,10 +27,10 @@ TiDBは、特別なクライアントやドライバーを必要とせず、標 `AS OF TIMESTAMP`句の例をいくつか示します。 -- `AS OF TIMESTAMP '2016-10-08 16:45:26'` : 2016 年 10 月 8 日 16:45:26 に保存された最新のデータを読み取るように TiDB に指示します。 -- `AS OF TIMESTAMP NOW() - INTERVAL 10 SECOND` : TiDB に 10 秒前に保存された最新のデータを読み取るように指示します。 -- `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS('2016-10-08 16:45:26', '2016-10-08 16:45:29')` : 2016 年 10 月 8 日の 16:45:26 から 16:45:29 までの範囲内でできるだけ新しいデータを読み取るように TiDB に指示します。 -- `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS(NOW() - INTERVAL 20 SECOND, NOW())` : 20 秒前から現在までの時間範囲内で可能な限り新しいデータを読み取るように TiDB に指示します。 +- `AS OF TIMESTAMP '2016-10-08 16:45:26'` : 2016 年 10 月 8 日 16:45:26 に保存された最新のデータを読み取るように TiDB に指示します。 +- `AS OF TIMESTAMP NOW() - INTERVAL 10 SECOND` : TiDB に 10 秒前に保存された最新のデータを読み取るように指示します。 +- `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS('2016-10-08 16:45:26', '2016-10-08 16:45:29')` : 2016 年 10 月 8 日の 16:45:26 から 16:45:29 までの範囲内でできるだけ新しいデータを読み取るように TiDB に指示します。 +- `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS(NOW() - INTERVAL 20 SECOND, NOW())` : 20 秒前から現在までの時間範囲内で可能な限り新しいデータを読み取るように TiDB に指示します。 > **Note:** > diff --git a/auto-increment.md b/auto-increment.md index 5d8880e61e5e7..80fe8e6c468e8 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -112,9 +112,9 @@ INSERT INTO t (c) VALUES (1) 上記の例では、次の操作を順番に実行します。 -1. クライアントはインスタンス`B`にステートメント`INSERT INTO t VALUES (2, 1)`を挿入し、 `id`を`2`に設定します。ステートメントは正常に実行されます。 +1. クライアントはインスタンス`B`にステートメント`INSERT INTO t VALUES (2, 1)`を挿入し、 `id`を`2`に設定します。ステートメントは正常に実行されます。 -2. クライアントはインスタンス`A`にステートメント`INSERT INTO t (c) (1)`を送信します。このステートメントでは`id`の値が指定されていないため、ID は`A`に割り当てられます。現在、 `A` `[1, 30000]`のIDをキャッシュしているため、AUTO_INCREMENT IDの値として`2`を割り当て、ローカルカウンタを`1`増加させる可能性があります。このとき、ID `2`のデータが既にデータベースに存在するため、 `Duplicated Error`エラーが返されます。 +2. クライアントはインスタンス`A`にステートメント`INSERT INTO t (c) (1)`を送信します。このステートメントでは`id`の値が指定されていないため、ID は`A`に割り当てられます。現在、 `A` `[1, 30000]`のIDをキャッシュしているため、AUTO_INCREMENT IDの値として`2`を割り当て、ローカルカウンタを`1`増加させる可能性があります。このとき、ID `2`のデータが既にデータベースに存在するため、 `Duplicated Error`エラーが返されます。 ### 単調性 {#monotonicity} @@ -343,18 +343,18 @@ SELECT * FROM t; -- [データ移行（DM）](/dm/dm-overview.md)を使用した増分レプリケーションのシナリオでは、レプリケーションが完了すると、下流の TiDB へのデータ書き込みは DM からアプリケーションの書き込み操作に切り替わります。同時に、AUTO_INCREMENT列の ID 書き込みモードは通常、明示的な挿入から暗黙的な割り当てに切り替わります。 -- TiDB Lightningはデータのインポートを完了すると、AUTO_INCREMENT IDキャッシュを自動的にクリアします。しかし、TiCDCは増分データ同期後にキャッシュを自動的にクリアしません。そのため、TiCDCを停止した後、フェイルオーバーを実行する前に、下流クラスタのAUTO_INCREMENT IDキャッシュを手動でクリアする必要があります。 +- [データ移行（DM）](/dm/dm-overview.md)を使用した増分レプリケーションのシナリオでは、レプリケーションが完了すると、下流の TiDB へのデータ書き込みは DM からアプリケーションの書き込み操作に切り替わります。同時に、AUTO_INCREMENT列の ID 書き込みモードは通常、明示的な挿入から暗黙的な割り当てに切り替わります。 +- TiDB Lightningはデータのインポートを完了すると、AUTO_INCREMENT IDキャッシュを自動的にクリアします。しかし、TiCDCは増分データ同期後にキャッシュを自動的にクリアしません。そのため、TiCDCを停止した後、フェイルオーバーを実行する前に、下流クラスタのAUTO_INCREMENT IDキャッシュを手動でクリアする必要があります。 -- [データ移行](/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md)機能を使用した増分レプリケーションのシナリオでは、レプリケーションが完了すると、下流 TiDB へのデータ書き込みは DM からアプリケーションの書き込み操作に切り替わります。同時に、AUTO_INCREMENT列の ID 書き込みモードは通常、明示的な挿入から暗黙的な割り当てに切り替わります。 -- TiDB Lightningはデータのインポートを完了すると、AUTO_INCREMENT IDキャッシュを自動的にクリアします。しかし、TiCDCは増分データ同期後にキャッシュを自動的にクリアしません。そのため、TiCDCを停止した後、フェイルオーバーを実行する前に、下流クラスタのAUTO_INCREMENT IDキャッシュを手動でクリアする必要があります。 +- [データ移行](/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md)機能を使用した増分レプリケーションのシナリオでは、レプリケーションが完了すると、下流 TiDB へのデータ書き込みは DM からアプリケーションの書き込み操作に切り替わります。同時に、AUTO_INCREMENT列の ID 書き込みモードは通常、明示的な挿入から暗黙的な割り当てに切り替わります。 +- TiDB Lightningはデータのインポートを完了すると、AUTO_INCREMENT IDキャッシュを自動的にクリアします。しかし、TiCDCは増分データ同期後にキャッシュを自動的にクリアしません。そのため、TiCDCを停止した後、フェイルオーバーを実行する前に、下流クラスタのAUTO_INCREMENT IDキャッシュを手動でクリアする必要があります。 -- アプリケーションで明示的な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`とともに実行します。例: @@ -443,30 +443,30 @@ INSERT INTO t VALUES (); -- Returns ID 30001 IDは常に増加し、 `AUTO_ID_CACHE 0`のような大きなギャップは発生しませんが、以下のシナリオでは、シーケンスに小さなギャップが発生する可能性があります。これらのギャップは、IDの一意性と厳密に増加する性質の両方を維持するために必要です。 -- プライマリインスタンスが終了またはクラッシュした場合のフェイルオーバー中 +- プライマリインスタンスが終了またはクラッシュした場合のフェイルオーバー中 MySQL互換モードを有効にすると、割り当てられたIDは**一意**かつ**単調増加**となり、動作はMySQLとほぼ同じになります。複数のTiDBインスタンスにまたがってアクセスする場合でも、IDの単調性は維持されます。ただし、集中型サービスのプライマリインスタンスがクラッシュした場合、一部のIDが連続しなくなる可能性があります。これは、セカンダリインスタンスがフェイルオーバー時にプライマリインスタンスによって割り当てられた一部のIDを破棄することで、IDの一意性を確保するためです。 -- TiDBノードのローリングアップグレード中 +- TiDBノードのローリングアップグレード中 -- 通常の同時トランザクション中（MySQLと同様） +- 通常の同時トランザクション中（MySQLと同様） > **Note:** > > `AUTO_ID_CACHE 1`の動作とパフォーマンスは、TiDB のバージョンごとに進化しています。 > -> - v6.4.0 より前では、各 ID 割り当てに TiKV トランザクションが必要であり、パフォーマンスに影響します。 -> - v6.4.0 では、TiDB は、ID 割り当てをメモリ内操作として実行する集中割り当てサービスを導入し、パフォーマンスを大幅に向上させました。 -> - v8.1.0以降、TiDBはプライマリノード終了時の自動的な`forceRebase`操作を削除し、再起動を高速化します。これによりフェイルオーバー時に非連続のIDが追加される可能性がありますが、多くのテーブルで`AUTO_ID_CACHE 1`が使用されている場合に書き込みブロックが発生するのを防ぎます。 +> - v6.4.0 より前では、各 ID 割り当てに TiKV トランザクションが必要であり、パフォーマンスに影響します。 +> - v6.4.0 では、TiDB は、ID 割り当てをメモリ内操作として実行する集中割り当てサービスを導入し、パフォーマンスを大幅に向上させました。 +> - v8.1.0以降、TiDBはプライマリノード終了時の自動的な`forceRebase`操作を削除し、再起動を高速化します。これによりフェイルオーバー時に非連続のIDが追加される可能性がありますが、多くのテーブルで`AUTO_ID_CACHE 1`が使用されている場合に書き込みブロックが発生するのを防ぎます。 ## 制限 {#restrictions} 現在、 `AUTO_INCREMENT` TiDB で使用する場合、次の制限があります。 -- TiDB v6.6.0 以前のバージョンの場合、定義された列は主キーまたはインデックス プレフィックスのいずれかである必要があります。 -- `INTEGER` 、 `FLOAT` 、または`DOUBLE`タイプの列に定義する必要があります。 -- `DEFAULT`列の値と同じ列には指定できません。 -- `ALTER TABLE` 、属性`AUTO_INCREMENT`を持つ列を追加または変更するために使用できません。これには、属性`AUTO_INCREMENT`既存の列に追加するために`ALTER TABLE ... MODIFY/CHANGE COLUMN`を使用することや、属性`AUTO_INCREMENT`を持つ列を追加するために`ALTER TABLE ... ADD COLUMN`を使用することも含まれます。 -- `ALTER TABLE` `AUTO_INCREMENT`属性を削除するために使用できます。ただし、v2.1.18 および v3.0.4 以降、TiDB はセッション変数`@@tidb_allow_remove_auto_inc`を使用して、列の`AUTO_INCREMENT`の属性を削除するために`ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用できるかどうかを制御します。デフォルトでは、 `ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用して`AUTO_INCREMENT`属性を削除することはできません。 -- `ALTER TABLE` 、 `AUTO_INCREMENT`値を小さい値に設定するには`FORCE`オプションが必要です。 -- `AUTO_INCREMENT` `MAX()`より小さい値に設定すると、既存の値がスキップされないため、キーが重複することになります。 +- TiDB v6.6.0 以前のバージョンの場合、定義された列は主キーまたはインデックス プレフィックスのいずれかである必要があります。 +- `INTEGER` 、 `FLOAT` 、または`DOUBLE`タイプの列に定義する必要があります。 +- `DEFAULT`列の値と同じ列には指定できません。 +- `ALTER TABLE` 、属性`AUTO_INCREMENT`を持つ列を追加または変更するために使用できません。これには、属性`AUTO_INCREMENT`既存の列に追加するために`ALTER TABLE ... MODIFY/CHANGE COLUMN`を使用することや、属性`AUTO_INCREMENT`を持つ列を追加するために`ALTER TABLE ... ADD COLUMN`を使用することも含まれます。 +- `ALTER TABLE` `AUTO_INCREMENT`属性を削除するために使用できます。ただし、v2.1.18 および v3.0.4 以降、TiDB はセッション変数`@@tidb_allow_remove_auto_inc`を使用して、列の`AUTO_INCREMENT`の属性を削除するために`ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用できるかどうかを制御します。デフォルトでは、 `ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`を使用して`AUTO_INCREMENT`属性を削除することはできません。 +- `ALTER TABLE` 、 `AUTO_INCREMENT`値を小さい値に設定するには`FORCE`オプションが必要です。 +- `AUTO_INCREMENT` `MAX()`より小さい値に設定すると、既存の値がスキップされないため、キーが重複することになります。 diff --git a/auto-random.md b/auto-random.md index c5b5870954701..34b2723f3b852 100644 --- a/auto-random.md +++ b/auto-random.md @@ -42,8 +42,8 @@ CREATE TABLE t (a BIGINT /*T![auto_rand] AUTO_RANDOM(5, 54) */, b VARCHAR(255), `INSERT`ステートメントを実行すると、次のようになります。 -- `AUTO_RANDOM`列の値を明示的に指定すると、そのままテーブルに挿入されます。 -- `AUTO_RANDOM`列の値を明示的に指定しない場合は、TiDB によってランダムな値が生成され、テーブルに挿入されます。 +- `AUTO_RANDOM`列の値を明示的に指定すると、そのままテーブルに挿入されます。 +- `AUTO_RANDOM`列の値を明示的に指定しない場合は、TiDB によってランダムな値が生成され、テーブルに挿入されます。 ```sql tidb> CREATE TABLE t (a BIGINT PRIMARY KEY AUTO_RANDOM, b VARCHAR(255)) /*T! PRE_SPLIT_REGIONS=2 */ ; @@ -102,8 +102,8 @@ tidb> SHOW TABLE t REGIONS; TiDB によって自動的に割り当てられる`AUTO_RANDOM(S, R)`列の値の合計は 64 ビットです。 -- `S`はシャードビット数です。値の範囲は`1`から`15`です。デフォルト値は`5`です。 -- `R`は自動割り当て範囲の合計長です。値の範囲は`32`から`64` 。デフォルト値は`64`です。 +- `S`はシャードビット数です。値の範囲は`1`から`15`です。デフォルト値は`5`です。 +- `R`は自動割り当て範囲の合計長です。値の範囲は`32`から`64` 。デフォルト値は`64`です。 符号付きビットを持つ`AUTO_RANDOM`値の構造は次のとおりです。 @@ -117,26 +117,26 @@ TiDB によって自動的に割り当てられる`AUTO_RANDOM(S, R)`列の値 | --------- | ------ | ------------ | | `64-R`ビット | `S`ビット | `R-S`ビット | -- `AUTO_RANDOM`カラムに符号付きビットがあるかどうかは、そのカラムに`UNSIGNED`属性があるかどうかによって決まります。`UNSIGNED`属性のないカラムには 1 つの符号付きビットがあり、`UNSIGNED`属性のあるカラムには符号付きビットがありません。 -- `AUTO_RANDOM`カラムに暗黙的に割り当てられる値は常に正です。符号付きビットを持つカラムでは、暗黙的に割り当てられる値の符号付きビットは常に`0`です。このルールは、明示的に挿入される値には適用されません。 -- 予約ビットの長さは`64-R`です。予約ビットは常に`0`です。 -- AUTO_INCREMENTビットは少なくとも 27 ビット必要です。符号付きカラムでは、`R-1-S >= 27`を満たす必要があります。符号なしカラムでは、`R-S >= 27`を満たす必要があります。 -- シャードビットの内容は、現在のトランザクションの開始時刻のハッシュ値を計算することで得られます。異なるシャードビット長（10など）を使用する場合は、テーブル作成時に`AUTO_RANDOM(10)`を指定します。 -- AUTO_INCREMENTビットの値はストレージエンジンに格納され、順次割り当てられます。新しい値が割り当てられるたびに、値は1ずつ増加します。AUTO_INCREMENTビットは、 `AUTO_RANDOM`の値がグローバルに一意であることを保証します。AUTO_INCREMENTビットが使い果たされると、値が再び割り当てられる際にエラー`Failed to read auto-increment value from storage engine`が報告されます。 -- 値の範囲：最終的に生成される値の最大ビット数 = シャードビット数 + AUTO_INCREMENTビット数。符号付き列の範囲は`[-(2^(R-1))+1, (2^(R-1))-1]` 、符号なし列の範囲は`[0, (2^R)-1]`です。 -- `AUTO_RANDOM` `PRE_SPLIT_REGIONS`と組み合わせて使用できます。テーブルが正常に作成されると、 `PRE_SPLIT_REGIONS`テーブル内のデータを`2^(PRE_SPLIT_REGIONS)`で指定された数のリージョンに事前に分割します。 +- `AUTO_RANDOM`カラムに符号付きビットがあるかどうかは、そのカラムに`UNSIGNED`属性があるかどうかによって決まります。`UNSIGNED`属性のないカラムには 1 つの符号付きビットがあり、`UNSIGNED`属性のあるカラムには符号付きビットがありません。 +- `AUTO_RANDOM`カラムに暗黙的に割り当てられる値は常に正です。符号付きビットを持つカラムでは、暗黙的に割り当てられる値の符号付きビットは常に`0`です。このルールは、明示的に挿入される値には適用されません。 +- 予約ビットの長さは`64-R`です。予約ビットは常に`0`です。 +- AUTO_INCREMENTビットは少なくとも 27 ビット必要です。符号付きカラムでは、`R-1-S >= 27`を満たす必要があります。符号なしカラムでは、`R-S >= 27`を満たす必要があります。 +- シャードビットの内容は、現在のトランザクションの開始時刻のハッシュ値を計算することで得られます。異なるシャードビット長（10など）を使用する場合は、テーブル作成時に`AUTO_RANDOM(10)`を指定します。 +- AUTO_INCREMENTビットの値はストレージエンジンに格納され、順次割り当てられます。新しい値が割り当てられるたびに、値は1ずつ増加します。AUTO_INCREMENTビットは、 `AUTO_RANDOM`の値がグローバルに一意であることを保証します。AUTO_INCREMENTビットが使い果たされると、値が再び割り当てられる際にエラー`Failed to read auto-increment value from storage engine`が報告されます。 +- 値の範囲：最終的に生成される値の最大ビット数 = シャードビット数 + AUTO_INCREMENTビット数。符号付き列の範囲は`[-(2^(R-1))+1, (2^(R-1))-1]` 、符号なし列の範囲は`[0, (2^R)-1]`です。 +- `AUTO_RANDOM` `PRE_SPLIT_REGIONS`と組み合わせて使用できます。テーブルが正常に作成されると、 `PRE_SPLIT_REGIONS`テーブル内のデータを`2^(PRE_SPLIT_REGIONS)`で指定された数のリージョンに事前に分割します。 > **Note:** > > シャードビットの選択（ `S` ）： > -> - 利用可能なビット数は合計64ビットであるため、シャードビット長はAUTO_INCREMENTビット長に影響します。つまり、シャードビット長が増加するとAUTO_INCREMENTビット長は減少し、逆もまた同様です。したがって、割り当てられた値のランダム性と利用可能なスペースのバランスをとる必要があります。 -> - ベストプラクティスは、シャードビットを`log(2, x)`に設定することです。ここで、 `x`現在のストレージエンジンの数です。例えば、TiDB クラスターに TiKV ノードが 16 個ある場合、シャードビットを`log(2, 16)` （つまり`4`に設定できます。すべてのリージョンが各 TiKV ノードに均等にスケジュールされると、一括書き込みの負荷が複数の TiKV ノードに均等に分散され、リソース使用率を最大化できます。 +> - 利用可能なビット数は合計64ビットであるため、シャードビット長はAUTO_INCREMENTビット長に影響します。つまり、シャードビット長が増加するとAUTO_INCREMENTビット長は減少し、逆もまた同様です。したがって、割り当てられた値のランダム性と利用可能なスペースのバランスをとる必要があります。 +> - ベストプラクティスは、シャードビットを`log(2, x)`に設定することです。ここで、 `x`現在のストレージエンジンの数です。例えば、TiDB クラスターに TiKV ノードが 16 個ある場合、シャードビットを`log(2, 16)` （つまり`4`に設定できます。すべてのリージョンが各 TiKV ノードに均等にスケジュールされると、一括書き込みの負荷が複数の TiKV ノードに均等に分散され、リソース使用率を最大化できます。 > > 範囲の選択（ `R` ）： > -> - 通常、アプリケーションの数値型が完全な 64 ビット整数を表現できない場合は、 `R`パラメータを設定する必要があります。 -> - 例えば、JSONの数値の範囲は`[-(2^53)+1, (2^53)-1]`です。TiDBは、 `AUTO_RANDOM(5)`と定義された列にこの範囲を超える整数を簡単に割り当ててしまう可能性があり、アプリケーションがその列を読み取った際に予期しない動作を引き起こす可能性があります。このような場合、符号付き列の場合は`AUTO_RANDOM(5)` `AUTO_RANDOM(5, 54)`に、符号なし列の場合は`AUTO_RANDOM(5)` `AUTO_RANDOM(5, 53)`に置き換えることで、TiDBが列に`9007199254740991` (2^53-1) を超える整数を割り当てないようにすることができます。 +> - 通常、アプリケーションの数値型が完全な 64 ビット整数を表現できない場合は、 `R`パラメータを設定する必要があります。 +> - 例えば、JSONの数値の範囲は`[-(2^53)+1, (2^53)-1]`です。TiDBは、 `AUTO_RANDOM(5)`と定義された列にこの範囲を超える整数を簡単に割り当ててしまう可能性があり、アプリケーションがその列を読み取った際に予期しない動作を引き起こす可能性があります。このような場合、符号付き列の場合は`AUTO_RANDOM(5)` `AUTO_RANDOM(5, 54)`に、符号なし列の場合は`AUTO_RANDOM(5)` `AUTO_RANDOM(5, 53)`に置き換えることで、TiDBが列に`9007199254740991` (2^53-1) を超える整数を割り当てないようにすることができます。 `AUTO_RANDOM`列に暗黙的に割り当てられた値は`last_insert_id()`影響します。TiDB が最後に暗黙的に割り当てた ID を取得するには、 `SELECT last_insert_id ()`ステートメントを使用できます。 @@ -204,11 +204,11 @@ ALTER TABLE t FORCE AUTO_RANDOM_BASE = 1000; `AUTO_RANDOM`を使用する場合は、次の制限に注意してください。 -- 明示的に値を挿入するには、システム変数`@@allow_auto_random_explicit_insert`の値を`1` （デフォルトは`0` ）に設定する必要があります。データを挿入する際に、属性`AUTO_RANDOM`持つ列に明示的に値を指定することは推奨さ**れません**。そうしないと、このテーブルに自動的に割り当てられる数値が事前に使い果たされてしまう可能性があります。 -- この属性は、主キー列に**のみ**`BIGINT`型で指定してください。それ以外の場合はエラーが発生します。また、主キーの属性が`NONCLUSTERED`の場合、整数型の主キーであっても`AUTO_RANDOM`サポートされません`CLUSTERED`型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 -- `ALTER TABLE`を使用して`AUTO_RANDOM`属性を変更することはできません (この属性の追加や削除を含む)。 -- 最大値が列タイプの最大値に近い場合は、 `ALTER TABLE`を使用して`AUTO_INCREMENT`から`AUTO_RANDOM`に変更することはできません。 -- `AUTO_RANDOM`属性で指定された主キー列の列タイプを変更することはできません。 -- 同じ列に同時に`AUTO_RANDOM`と`AUTO_INCREMENT`を指定することはできません。 -- 同じ列に`AUTO_RANDOM`と`DEFAULT` (列のデフォルト値) を同時に指定することはできません。 -- 列に`AUTO_RANDOM`が使用されている場合、自動生成される値が非常に大きくなる可能性があるため、列属性を`AUTO_INCREMENT`に戻すのは困難です。 +- 明示的に値を挿入するには、システム変数`@@allow_auto_random_explicit_insert`の値を`1` （デフォルトは`0` ）に設定する必要があります。データを挿入する際に、属性`AUTO_RANDOM`持つ列に明示的に値を指定することは推奨さ**れません**。そうしないと、このテーブルに自動的に割り当てられる数値が事前に使い果たされてしまう可能性があります。 +- この属性は、主キー列に**のみ**`BIGINT`型で指定してください。それ以外の場合はエラーが発生します。また、主キーの属性が`NONCLUSTERED`の場合、整数型の主キーであっても`AUTO_RANDOM`サポートされません`CLUSTERED`型の主キーの詳細については、 [クラスター化インデックス](/clustered-indexes.md)を参照してください。 +- `ALTER TABLE`を使用して`AUTO_RANDOM`属性を変更することはできません (この属性の追加や削除を含む)。 +- 最大値が列タイプの最大値に近い場合は、 `ALTER TABLE`を使用して`AUTO_INCREMENT`から`AUTO_RANDOM`に変更することはできません。 +- `AUTO_RANDOM`属性で指定された主キー列の列タイプを変更することはできません。 +- 同じ列に同時に`AUTO_RANDOM`と`AUTO_INCREMENT`を指定することはできません。 +- 同じ列に`AUTO_RANDOM`と`DEFAULT` (列のデフォルト値) を同時に指定することはできません。 +- 列に`AUTO_RANDOM`が使用されている場合、自動生成される値が非常に大きくなる可能性があるため、列属性を`AUTO_INCREMENT`に戻すのは困難です。 diff --git a/backup-and-restore-using-dumpling-lightning.md b/backup-and-restore-using-dumpling-lightning.md index d343aaea4765e..f39792bf12d0a 100644 --- a/backup-and-restore-using-dumpling-lightning.md +++ b/backup-and-restore-using-dumpling-lightning.md @@ -13,21 +13,21 @@ summary: DumplingとTiDB Lightningを使用して、TiDBの完全なデータを ## 要件 {#requirements} -- Dumplingをインストールしてください： +- Dumplingをインストールしてください： ```shell tiup install dumpling ``` -- TiDB Lightningをインストールする： +- TiDB Lightningをインストールする： ```shell tiup install tidb-lightning ``` -- [Dumplingに必要なソースデータベース権限を付与する](/dumpling-overview.md#export-data-from-tidb-or-mysql) +- [Dumplingに必要なソースデータベース権限を付与する](/dumpling-overview.md#export-data-from-tidb-or-mysql) -- [TiDB Lightningに必要なターゲットデータベース権限を付与します](/tidb-lightning/tidb-lightning-requirements.md#privileges-of-the-target-database) +- [TiDB Lightningに必要なターゲットデータベース権限を付与します](/tidb-lightning/tidb-lightning-requirements.md#privileges-of-the-target-database) ## リソース要件 {#resource-requirements} @@ -41,8 +41,8 @@ summary: DumplingとTiDB Lightningを使用して、TiDBの完全なデータを バックアップタスクのデータをローカルディスクに保存する必要がある場合は、以下の制限事項に注意してください。 -- Dumplingには、データソース全体を保存できる（またはエクスポートされるすべての上流テーブルを保存できる）ディスク容量が必要です。必要なスペースを計算するには、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。 -- インポート処理中、 TiDB Lightningはソート済みのキーと値のペアを保存するための一時的な領域を必要とします。ディスク容量は、データソースの最大の単一テーブルを格納できるのに十分な量が必要です。 +- Dumplingには、データソース全体を保存できる（またはエクスポートされるすべての上流テーブルを保存できる）ディスク容量が必要です。必要なスペースを計算するには、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。 +- インポート処理中、 TiDB Lightningはソート済みのキーと値のペアを保存するための一時的な領域を必要とします。ディスク容量は、データソースの最大の単一テーブルを格納できるのに十分な量が必要です。 **Note:** DumplingによってMySQLからエクスポートされる正確なデータ量を計算することは困難ですが、次のSQLステートメントを使用して`information_schema.tables`テーブルの`DATA_LENGTH`フィールドを要約することで、データ量を推定できます。 @@ -79,12 +79,12 @@ LIMIT ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットの TiKV クラスターのストレージ容量は**、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、ターゲットの TiKV クラスターは、データソースのサイズの 6 倍よりも大きなストレージ容量が必要です。この式に x 2 が含まれている理由は次のとおりです。 -- インデックスには余分な容量が必要になる場合があります。 -- RocksDBには空間増幅がある。 +- インデックスには余分な容量が必要になる場合があります。 +- RocksDBには空間増幅がある。 ## Dumplingを使用してフルデータをバックアップします {#use-dumpling-to-back-up-full-data} -1. TiDBからAmazon S3の`s3://my-bucket/sql-backup`に全データをエクスポートするには、次のコマンドを実行します。 +1. TiDBからAmazon S3の`s3://my-bucket/sql-backup`に全データをエクスポートするには、次のコマンドを実行します。 ```shell tiup dumpling -h ${ip} -P 3306 -u root -t 16 -r 200000 -F 256MiB -B my_db1 -f 'my_db1.table[12]' -o 's3://my-bucket/sql-backup' @@ -94,11 +94,11 @@ LIMIT Dumplingのその他の構成については、 [Dumplingのオプション一覧](/dumpling-overview.md#option-list-of-dumpling)を参照してください。 -2. エクスポートが完了すると、ディレクトリ`s3://my-bucket/sql-backup`でバックアップファイルを確認できます。 +2. エクスポートが完了すると、ディレクトリ`s3://my-bucket/sql-backup`でバックアップファイルを確認できます。 ## TiDB Lightningを使用して完全なデータを復元します。 {#use-tidb-lightning-to-restore-full-data} -1. `tidb-lightning.toml`ファイルを編集して、Dumplingを使用して`s3://my-bucket/sql-backup`にバックアップされた完全なデータを、ターゲットのTiDBクラスターにインポートします。 +1. `tidb-lightning.toml`ファイルを編集して、Dumplingを使用して`s3://my-bucket/sql-backup`にバックアップされた完全なデータを、ターゲットのTiDBクラスターにインポートします。 ```toml [lightning] @@ -129,7 +129,7 @@ LIMIT TiDB Lightning構成の詳細については、 [TiDB Lightningの構成](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 -2. `tidb-lightning`を実行してインポートを開始します。コマンドラインでプログラムを直接起動すると、 `SIGHUP`シグナルを受信した後にプロセスが予期せず終了する可能性があります。この場合、 `nohup`または`screen`ツールを使用してプログラムを実行することをお勧めします。例: +2. `tidb-lightning`を実行してインポートを開始します。コマンドラインでプログラムを直接起動すると、 `SIGHUP`シグナルを受信した後にプロセスが予期せず終了する可能性があります。この場合、 `nohup`または`screen`ツールを使用してプログラムを実行することをお勧めします。例: S3 からデータをインポートする場合は、S3ストレージパスにアクセスできる SecretKey と AccessKey を環境変数としてTiDB Lightningノードに渡してください。また、 `~/.aws/credentials`から認証情報を読み取ることもできます。 @@ -139,9 +139,9 @@ LIMIT nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out 2>&1 & ``` -3. インポートが開始されたら、ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 +3. インポートが開始されたら、ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 -4. TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 +4. TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 > **Note:** > diff --git a/basic-features.md b/basic-features.md index 83620aab5d322..02241a2250082 100644 --- a/basic-features.md +++ b/basic-features.md @@ -15,9 +15,9 @@ summary: TiDBの機能概要について学びましょう。 > > 下記の表の略語は、それぞれ以下の意味を持ちます。 > -> - Y：この機能は一般提供（GA）されており、本番環境で使用できます。ただし、DMRバージョンで機能がGAになった場合でも、本番環境ではより新しいLTSバージョンでその機能を使用することをお勧めします。 -> - N: この機能はサポートされていません。 -> - E: この機能はまだ一般提供されていません（実験的）。使用上の制限事項にご注意ください。Experimental機能は予告なく変更または削除される場合があります。構文や実装は一般提供開始前に変更される可能性があります。問題が発生した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)を報告してください。 +> - Y：この機能は一般提供（GA）されており、本番環境で使用できます。ただし、DMRバージョンで機能がGAになった場合でも、本番環境ではより新しいLTSバージョンでその機能を使用することをお勧めします。 +> - N: この機能はサポートされていません。 +> - E: この機能はまだ一般提供されていません（実験的）。使用上の制限事項にご注意ください。Experimental機能は予告なく変更または削除される場合があります。構文や実装は一般提供開始前に変更される可能性があります。問題が発生した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)を報告してください。 ## データ型、関数、演算子 {#data-types-functions-and-operators} diff --git a/basic-sql-operations.md b/basic-sql-operations.md index e3ddcb7626ea7..6a2a20f5f5833 100644 --- a/basic-sql-operations.md +++ b/basic-sql-operations.md @@ -19,13 +19,13 @@ SQLを試したり、TiDBとMySQLクエリの互換性をテストしたりす SQLは、その関数に応じて以下の4種類に分類されます。 -- DDL（データ定義言語）：データベース、テーブル、ビュー、インデックスなど、データベースオブジェクトを定義するために使用されます。 +- DDL（データ定義言語）：データベース、テーブル、ビュー、インデックスなど、データベースオブジェクトを定義するために使用されます。 -- DML（データ操作言語）：アプリケーション関連のレコードを操作するために使用されます。 +- DML（データ操作言語）：アプリケーション関連のレコードを操作するために使用されます。 -- DQL（データクエリ言語）：条件付きフィルタリング後にレコードをクエリするために使用されます。 +- DQL（データクエリ言語）：条件付きフィルタリング後にレコードをクエリするために使用されます。 -- DCL（データ制御言語）：アクセス権限とセキュリティレベルを定義するために使用されます。 +- DCL（データ制御言語）：アクセス権限とセキュリティレベルを定義するために使用されます。 一般的な DDL 機能には、オブジェクト (テーブルやインデックスなど) の作成、変更、削除があります。対応するコマンドは`CREATE` 、 `ALTER` 、 `DROP`です。 diff --git a/batch-processing.md b/batch-processing.md index 85cbd51d333fb..99a3412889acc 100644 --- a/batch-processing.md +++ b/batch-processing.md @@ -9,12 +9,12 @@ summary: パイプライン DML、非トランザクション DML、IMPORT INTO` バッチ操作のパフォーマンスを最適化するために、TiDB はバージョンの進化とともにさまざまな機能を導入しています。 -- データのインポート - - `IMPORT INTO`ステートメント (TiDB v7.2.0 で導入され、v7.5.0 で GA になりました) -- データの挿入、更新、削除 - - パイプライン DML (実験的、TiDB v8.0.0 で導入) - - 非トランザクションDML（TiDB v6.1.0で導入） - - Batch-dml（非推奨） +- データのインポート + - `IMPORT INTO`ステートメント (TiDB v7.2.0 で導入され、v7.5.0 で GA になりました) +- データの挿入、更新、削除 + - パイプライン DML (実験的、TiDB v8.0.0 で導入) + - 非トランザクションDML（TiDB v6.1.0で導入） + - Batch-dml（非推奨） このドキュメントでは、これらの機能の主な利点、制限事項、使用例について概説し、効率的なバッチ処理に最適なソリューションを選択できるようにします。 @@ -24,28 +24,28 @@ summary: パイプライン DML、非トランザクション DML、IMPORT INTO` ### 主なメリット {#key-benefits} -- 非常に高速なインポート速度 -- TiDB Lightningと比べて使いやすい +- 非常に高速なインポート速度 +- TiDB Lightningと比べて使いやすい ### 制限事項 {#limitations} -- [ACID](/glossary.md#acid)保証なし -- Subject to various usage restrictions +- [ACID](/glossary.md#acid)保証なし +- Subject to various usage restrictions -- [ACID](/tidb-cloud/tidb-cloud-glossary.md#acid)保証なし -- さまざまな使用制限の対象となります +- [ACID](/tidb-cloud/tidb-cloud-glossary.md#acid)保証なし +- さまざまな使用制限の対象となります ### ユースケース {#use-cases} -- データの移行や復旧などのデータインポートシナリオに適しています。該当する場合は、 TiDB Lightningではなく`IMPORT INTO`を使用することをお勧めします。 +- データの移行や復旧などのデータインポートシナリオに適しています。該当する場合は、 TiDB Lightningではなく`IMPORT INTO`を使用することをお勧めします。 詳細については[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を参照してください。 @@ -57,17 +57,17 @@ summary: パイプライン DML、非トランザクション DML、IMPORT INTO` #### 主なメリット {#key-benefits} -- Streams data to the storage layer during transaction execution instead of buffering it entirely in memory, allowing transaction size no longer limited by TiDB memory and supporting ultra-large-scale data processing -- 標準のDMLに比べて優れたパフォーマンスを実現 -- SQL を変更せずにシステム変数を通じて有効にすることができます +- Streams data to the storage layer during transaction execution instead of buffering it entirely in memory, allowing transaction size no longer limited by TiDB memory and supporting ultra-large-scale data processing +- 標準のDMLに比べて優れたパフォーマンスを実現 +- SQL を変更せずにシステム変数を通じて有効にすることができます #### 制限事項 {#limitations} -- [自動コミット](/transaction-overview.md#autocommit) `INSERT`、`REPLACE`、`UPDATE`、`DELETE`ステートメントのみをサポートします +- [自動コミット](/transaction-overview.md#autocommit) `INSERT`、`REPLACE`、`UPDATE`、`DELETE`ステートメントのみをサポートします #### ユースケース {#use-cases} -- 大量のデータの挿入、更新、削除などの一般的なバッチ処理タスクに適しています。 +- 大量のデータの挿入、更新、削除などの一般的なバッチ処理タスクに適しています。 詳細については[パイプラインDML](/pipelined-dml.md)を参照してください。 @@ -77,19 +77,19 @@ summary: パイプライン DML、非トランザクション DML、IMPORT INTO` #### 主なメリット {#key-benefits} -- メモリ制限を回避して、単一の SQL ステートメントを複数の小さなステートメントに分割します。 -- 標準の DML よりもわずかに高速、または同等のパフォーマンスを実現します。 +- メモリ制限を回避して、単一の SQL ステートメントを複数の小さなステートメントに分割します。 +- 標準の DML よりもわずかに高速、または同等のパフォーマンスを実現します。 #### 制限事項 {#limitations} -- [自動コミット](/transaction-overview.md#autocommit)ステートメントのみをサポートします -- SQL文の変更が必要 -- SQL 構文に厳しい要件を課すため、一部のステートメントは書き直しが必要になる場合があります。 -- 完全なトランザクションACID保証がないため、障害発生時には文が部分的に実行される可能性がある。 +- [自動コミット](/transaction-overview.md#autocommit)ステートメントのみをサポートします +- SQL文の変更が必要 +- SQL 構文に厳しい要件を課すため、一部のステートメントは書き直しが必要になる場合があります。 +- 完全なトランザクションACID保証がないため、障害発生時には文が部分的に実行される可能性がある。 #### ユースケース {#use-cases} -- 大量のデータの挿入、更新、削除を伴うシナリオに適しています。ただし、その制限のため、パイプラインDMLが適用できない場合にのみ、非トランザクションDMLを検討することをお勧めします。 +- 大量のデータの挿入、更新、削除を伴うシナリオに適しています。ただし、その制限のため、パイプラインDMLが適用できない場合にのみ、非トランザクションDMLを検討することをお勧めします。 詳細については[非トランザクションDML](/non-transactional-dml.md)を参照してください。 @@ -97,11 +97,11 @@ summary: パイプライン DML、非トランザクション DML、IMPORT INTO` TiDB v4.0より前のバージョンで利用可能だったbatch-dml機能は非推奨となり、推奨されなくなりました。この機能は、以下のシステム変数によって制御されます。 -- `tidb_batch_insert` -- `tidb_batch_delete` -- `tidb_batch_commit` -- `tidb_enable_batch_dml` -- `tidb_dml_batch_size` +- `tidb_batch_insert` +- `tidb_batch_delete` +- `tidb_batch_commit` +- `tidb_enable_batch_dml` +- `tidb_dml_batch_size` データとインデックスの不一致によってデータが破損または失われるリスクがあるため、これらの変数は非推奨となり、将来のリリースでは削除される予定です。 diff --git a/benchmark/benchmark-sysbench-v2.md b/benchmark/benchmark-sysbench-v2.md index e67599936b655..190e1966e2bed 100644 --- a/benchmark/benchmark-sysbench-v2.md +++ b/benchmark/benchmark-sysbench-v2.md @@ -50,7 +50,7 @@ IDCマシン ### TiKVパラメータ設定 {#tikv-parameter-configuration} -- バージョン1.0.8 +- バージョン1.0.8 ``` sync-log = false @@ -58,7 +58,7 @@ IDCマシン grpc-raft-conn-num = 24 ``` -- v2.0.0-rc6 +- v2.0.0-rc6 ``` sync-log = false diff --git a/benchmark/benchmark-sysbench-v4-vs-v3.md b/benchmark/benchmark-sysbench-v4-vs-v3.md index 190c5078d036a..54cbca2ce1b1e 100644 --- a/benchmark/benchmark-sysbench-v4-vs-v3.md +++ b/benchmark/benchmark-sysbench-v4-vs-v3.md @@ -89,12 +89,12 @@ set global tidb_disable_txn_auto_retry=0; ## テスト計画 {#test-plan} -1. TiUPを使用して TiDB v4.0 および v3.0をデプロイ。 -2. Sysbench を使用して、各テーブルに 1,000 万行のデータが含まれる 16 個のテーブルをインポートします。 -3. 各テーブルに対して`analyze table`ステートメントを実行します。 -4. さまざまな同時実行テストの前に、復元に使用するデータをバックアップします。これにより、各テストのデータの一貫性が確保されます。 -5. Sysbenchクライアントを起動して`update_index` `update_non_index` `point_select` `read_write`を実行します。AWS NLB経由でTiDBのストレステストを実行します。各テストのウォームアップには1分、テストには5分かかります。 -6. 各タイプのテストが完了したら、クラスターを停止し、手順 4 のバックアップ データでクラスターを上書きして、クラスターを再起動します。 +1. TiUPを使用して TiDB v4.0 および v3.0をデプロイ。 +2. Sysbench を使用して、各テーブルに 1,000 万行のデータが含まれる 16 個のテーブルをインポートします。 +3. 各テーブルに対して`analyze table`ステートメントを実行します。 +4. さまざまな同時実行テストの前に、復元に使用するデータをバックアップします。これにより、各テストのデータの一貫性が確保されます。 +5. Sysbenchクライアントを起動して`update_index` `update_non_index` `point_select` `read_write`を実行します。AWS NLB経由でTiDBのストレステストを実行します。各テストのウォームアップには1分、テストには5分かかります。 +6. 各タイプのテストが完了したら、クラスターを停止し、手順 4 のバックアップ データでクラスターを上書きして、クラスターを再起動します。 ### テストデータを準備する {#prepare-test-data} diff --git a/benchmark/benchmark-tidb-using-ch.md b/benchmark/benchmark-tidb-using-ch.md index 2cb3439212d8c..bc40b3e7ea468 100644 --- a/benchmark/benchmark-tidb-using-ch.md +++ b/benchmark/benchmark-tidb-using-ch.md @@ -74,8 +74,8 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'tpcc'; 上記のステートメントの結果は次のようになります。 -- `AVAILABLE`は、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。`1`は利用可能、 `0`は利用不可を意味します。レプリカが利用可能になると、このステータスは変更されません。 -- `PROGRESS`はレプリケーションの進行状況を示します。値は`0`から`1`までです。`1`はTiFlashレプリカのレプリケーションが完了したことを意味します。 +- `AVAILABLE`は、特定のテーブルのTiFlashレプリカが利用可能かどうかを示します。`1`は利用可能、 `0`は利用不可を意味します。レプリカが利用可能になると、このステータスは変更されません。 +- `PROGRESS`はレプリケーションの進行状況を示します。値は`0`から`1`までです。`1`はTiFlashレプリカのレプリケーションが完了したことを意味します。 ## 統計を収集する {#collect-statistics} diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index 5e8c48ac6ff76..a1268c8511180 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/benchmark/benchmark-tidb-using-sysbench.md @@ -113,8 +113,8 @@ create database sbtest; 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 のすぐ後ろに移動します。 +- 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 のすぐ後ろに移動します。 > **Note:** > diff --git a/benchmark/benchmark-tidb-using-tpcc.md b/benchmark/benchmark-tidb-using-tpcc.md index 274ca03cf4974..de2544a6d392a 100644 --- a/benchmark/benchmark-tidb-using-tpcc.md +++ b/benchmark/benchmark-tidb-using-tpcc.md @@ -9,21 +9,21 @@ summary: このドキュメントでは、オンライントランザクショ TPC-Cは、オンライントランザクション処理（OLTP）ベンチマークです。以下の5種類の異なるトランザクションを含む商品販売モデルを用いて、OLTPシステムをテストします。 -- ニューオーダー -- 支払い -- 注文状況 -- 配達 -- 在庫レベル +- ニューオーダー +- 支払い +- 注文状況 +- 配達 +- 在庫レベル ## 準備する {#prepare} TPC-Cベンチマークでは、テスト前にデータベースの初期状態、つまりデータベースにおけるデータ生成のルールを指定します。テーブル`ITEM`には10万件の固定アイテムが含まれますが、倉庫の数は調整可能です。テーブル`WAREHOUSE`にW件のレコードがある場合、以下のようになります。 -- `STOCK`テーブルにはW * 100,000件のレコードがあります（各倉庫は100,000点の在庫データに対応します） -- `DISTRICT`テーブルにはW * 10のレコードがあります（各倉庫は10の地区にサービスを提供しています） -- `CUSTOMER`テーブルには W * 10 * 3,000 のレコードがあります (各地区には 3,000 人の顧客がいます) -- `HISTORY`テーブルには W * 10 * 3,000 件のレコードがあります (各顧客には 1 つのトランザクション履歴があります) -- `ORDER`テーブルには W * 10 * 3,000 件のレコードがあります (各地区には 3,000 件の注文があり、生成された最後の 900 件の注文が`NEW-ORDER`テーブルに追加されます。各注文は 5 ~ 15 件の ORDER-LINE レコードをランダムに生成します。) +- `STOCK`テーブルにはW * 100,000件のレコードがあります（各倉庫は100,000点の在庫データに対応します） +- `DISTRICT`テーブルにはW * 10のレコードがあります（各倉庫は10の地区にサービスを提供しています） +- `CUSTOMER`テーブルには W \* 10 \* 3,000 のレコードがあります (各地区には 3,000 人の顧客がいます) +- `HISTORY`テーブルには W \* 10 \* 3,000 件のレコードがあります (各顧客には 1 つのトランザクション履歴があります) +- `ORDER`テーブルには W \* 10 \* 3,000 件のレコードがあります (各地区には 3,000 件の注文があり、生成された最後の 900 件の注文が`NEW-ORDER`テーブルに追加されます。各注文は 5 ~ 15 件の ORDER-LINE レコードをランダムに生成します。) このドキュメントでは、TiDB をテストするために、例として 1,000 個のウェアハウスを使用します。 diff --git a/benchmark/benchmark-tpch.md b/benchmark/benchmark-tpch.md index cb86e75f240ab..764179eba1597 100644 --- a/benchmark/benchmark-tpch.md +++ b/benchmark/benchmark-tpch.md @@ -102,7 +102,7 @@ TiDB 2.0: 以下の点に注意してください。 -- 上の図では、オレンジ色のバーはリリース1.0のクエリ結果、青色のバーはリリース2.0のクエリ結果を表しています。Y軸はクエリの処理時間（秒）を表しており、短いほど高速です。 -- クエリ15は、現在TiDB 1.0でも2.0でもVIEWがサポートされていないため、「NaN」タグが付けられています。今後のリリースでVIEWのサポートを提供する予定です。 -- TiDB 1.0 列のクエリ 2、17、および 19 には、TiDB 1.0 がこれらのクエリの結果を返さなかったため、「NaN」タグが付けられています。 -- TiDB 1.0 列のクエリ 5、7、18、および 21 には、メモリ消費量が高すぎるため、「OOM」タグが付けられています。 +- 上の図では、オレンジ色のバーはリリース1.0のクエリ結果、青色のバーはリリース2.0のクエリ結果を表しています。Y軸はクエリの処理時間（秒）を表しており、短いほど高速です。 +- クエリ15は、現在TiDB 1.0でも2.0でもVIEWがサポートされていないため、「NaN」タグが付けられています。今後のリリースでVIEWのサポートを提供する予定です。 +- TiDB 1.0 列のクエリ 2、17、および 19 には、TiDB 1.0 がこれらのクエリの結果を返さなかったため、「NaN」タグが付けられています。 +- TiDB 1.0 列のクエリ 5、7、18、および 21 には、メモリ消費量が高すぎるため、「OOM」タグが付けられています。 diff --git a/benchmark/online-workloads-and-add-index-operations.md b/benchmark/online-workloads-and-add-index-operations.md index 6077d78bcc686..42d5ef047babf 100644 --- a/benchmark/online-workloads-and-add-index-operations.md +++ b/benchmark/online-workloads-and-add-index-operations.md @@ -81,11 +81,11 @@ sysbench $testname \ ## テストプラン1: `ADD INDEX`文の対象列への書き込み操作を頻繁に実行する {#test-plan-1-frequently-perform-write-operations-to-the-target-column-of-the-add-index-statement} -1. `oltp_read_write`テストを開始します。 -2. 手順 1 と同時に実行します。`alter table sbtest1 add index c_idx(c)`を使用してインデックスを追加します。 -3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_write`を停止します。 -4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 -5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 +1. `oltp_read_write`テストを開始します。 +2. 手順 1 と同時に実行します。`alter table sbtest1 add index c_idx(c)`を使用してインデックスを追加します。 +3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_write`を停止します。 +4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 +5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 ### テスト結果 {#test-results} @@ -211,16 +211,16 @@ sysbench $testname \ `ADD INDEX`の文のターゲット列に対して頻繁に書き込み操作（このテストでは`UPDATE` `INSERT` `DELETE`操作が含まれます）を実行すると、デフォルトの`ADD INDEX`構成はシステムのオンラインワークロードに大きな影響を与えます。これは主に、同時実行される`ADD INDEX`操作と列更新によって発生する書き込み競合が原因です。システムのパフォーマンスは次のようになります。 -- パラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値が増加すると、 `TiKV_prewrite_latch_wait_duration`の値が大幅に増加し、書き込み速度が低下します。 -- `tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値が非常に大きい場合、 `admin show ddl`コマンドを実行すると、DDL ジョブの再試行回数（例えば`Write conflict, txnStartTS 410327455965380624 is stale [try again later], ErrCount:38, SnapshotVersion: 410327228136030220`を確認できます。この場合、 `ADD INDEX`操作の完了に非常に長い時間がかかります。 +- パラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値が増加すると、 `TiKV_prewrite_latch_wait_duration`の値が大幅に増加し、書き込み速度が低下します。 +- `tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値が非常に大きい場合、 `admin show ddl`コマンドを実行すると、DDL ジョブの再試行回数（例えば`Write conflict, txnStartTS 410327455965380624 is stale [try again later], ErrCount:38, SnapshotVersion: 410327228136030220`を確認できます。この場合、 `ADD INDEX`操作の完了に非常に長い時間がかかります。 ## テストプラン 2: `ADD INDEX`ステートメントのターゲット列への書き込み操作を実行しない (クエリのみ) {#test-plan-2-do-not-perform-write-operations-to-the-target-column-of-the-add-index-statement-query-only} -1. `oltp_read_only`テストを開始します。 -2. 手順 1 と同時に実行します。`alter table sbtest1 add index c_idx(c)`を使用してインデックスを追加します。 -3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_only`を停止します。 -4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 -5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 +1. `oltp_read_only`テストを開始します。 +2. 手順 1 と同時に実行します。`alter table sbtest1 add index c_idx(c)`を使用してインデックスを追加します。 +3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_only`を停止します。 +4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 +5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 ### テスト結果 {#test-results} @@ -278,11 +278,11 @@ sysbench $testname \ ## テストプラン3: `ADD INDEX`文のターゲット列はオンラインワークロードとは無関係です {#test-plan-3-the-target-column-of-the-add-index-statement-is-irrelevant-to-online-workloads} -1. `oltp_read_write`テストを開始します。 -2. 手順 1 と同時に実行します。`alter table test add index pad_idx(pad)`を使用してインデックスを追加します。 -3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_only`を停止します。 -4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 -5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 +1. `oltp_read_write`テストを開始します。 +2. 手順 1 と同時に実行します。`alter table test add index pad_idx(pad)`を使用してインデックスを追加します。 +3. 手順 2 の最後に実行します。インデックスが正常に追加されたら、テスト`oltp_read_only`を停止します。 +4. `alter table ... add index`の期間と、この期間の Sysbench の平均 TPS と QPS を取得します。 +5. 2 つのパラメータ`tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`値を徐々に増やし、手順 1 ～ 4 を繰り返します。 ### テスト結果 {#test-results} @@ -340,5 +340,5 @@ sysbench $testname \ ## まとめ {#summary} -- `ADD INDEX`ステートメントの対象列に対して、書き込み操作（ `INSERT` `DELETE`操作を含む）を頻繁に実行すると、デフォルトの`ADD INDEX` `UPDATE`では比較的頻繁に書き込み競合が発生し、オンラインワークロードに大きな影響を与えます。同時に、 `ADD INDEX`操作は継続的な再試行により完了までに長い時間がかかります。このテストでは、 `tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`の積をデフォルト値の1/32に変更できます。例えば、 `tidb_ddl_reorg_worker_cnt`を`4`に、 `tidb_ddl_reorg_batch_size`を`256`に設定すると、パフォーマンスが向上します。 -- `ADD INDEX`ステートメントのターゲット列に対してのみクエリ操作を実行する場合、またはターゲット列がオンライン ワークロードに直接関連していない場合は、デフォルトの`ADD INDEX`構成を使用できます。 +- `ADD INDEX`ステートメントの対象列に対して、書き込み操作（ `INSERT` `DELETE`操作を含む）を頻繁に実行すると、デフォルトの`ADD INDEX` `UPDATE`では比較的頻繁に書き込み競合が発生し、オンラインワークロードに大きな影響を与えます。同時に、 `ADD INDEX`操作は継続的な再試行により完了までに長い時間がかかります。このテストでは、 `tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`の積をデフォルト値の1/32に変更できます。例えば、 `tidb_ddl_reorg_worker_cnt`を`4`に、 `tidb_ddl_reorg_batch_size`を`256`に設定すると、パフォーマンスが向上します。 +- `ADD INDEX`ステートメントのターゲット列に対してのみクエリ操作を実行する場合、またはターゲット列がオンライン ワークロードに直接関連していない場合は、デフォルトの`ADD INDEX`構成を使用できます。 diff --git a/benchmark/v4.0-performance-benchmarking-with-tpcc.md b/benchmark/v4.0-performance-benchmarking-with-tpcc.md index 2d368859259cb..cd6b149231fbc 100644 --- a/benchmark/v4.0-performance-benchmarking-with-tpcc.md +++ b/benchmark/v4.0-performance-benchmarking-with-tpcc.md @@ -89,27 +89,27 @@ set global tidb_disable_txn_auto_retry=0; ## テスト計画 {#test-plan} -1. TiUPを使用して TiDB v4.0 および v3.0をデプロイ。 +1. TiUPを使用して TiDB v4.0 および v3.0をデプロイ。 -2. BenchmarkSQL を使用して、TPC-C 5000 Warehouse データをインポートします。 +2. BenchmarkSQL を使用して、TPC-C 5000 Warehouse データをインポートします。 - 1. BenchmarkSQLをコンパイルします。 + 1. BenchmarkSQLをコンパイルします。 ```bash git clone https://github.com/pingcap/benchmarksql && cd benchmarksql && ant ``` - 2. `run`ディレクトリに入り、実際の状況に応じて`props.mysql`ファイルを編集し、 `conn` 、 `warehouses` 、 `loadWorkers` 、 `terminals` 、 `runMins`設定項目を変更します。 + 2. `run`ディレクトリに入り、実際の状況に応じて`props.mysql`ファイルを編集し、 `conn` 、 `warehouses` 、 `loadWorkers` 、 `terminals` 、 `runMins`設定項目を変更します。 - 3. `runSQL.sh ./props.mysql sql.mysql/tableCreates.sql`コマンドを実行します。 + 3. `runSQL.sh ./props.mysql sql.mysql/tableCreates.sql`コマンドを実行します。 - 4. `runSQL.sh ./props.mysql sql.mysql/indexCreates.sql`コマンドを実行します。 + 4. `runSQL.sh ./props.mysql sql.mysql/indexCreates.sql`コマンドを実行します。 - 5. MySQL クライアントを実行し、テーブルごとに`analyze table`ステートメントを実行します。 + 5. MySQL クライアントを実行し、テーブルごとに`analyze table`ステートメントを実行します。 -3. `runBenchmark.sh ./props.mysql`コマンドを実行します。 +3. `runBenchmark.sh ./props.mysql`コマンドを実行します。 -4. 結果からNew OrderのtpmCデータを抽出します。 +4. 結果からNew OrderのtpmCデータを抽出します。 ## テスト結果 {#test-result} diff --git a/benchmark/v4.0-performance-benchmarking-with-tpch.md b/benchmark/v4.0-performance-benchmarking-with-tpch.md index db162978908dc..48eef7a4b8e5e 100644 --- a/benchmark/v4.0-performance-benchmarking-with-tpch.md +++ b/benchmark/v4.0-performance-benchmarking-with-tpch.md @@ -11,9 +11,9 @@ summary: TiDB 4.0 と TiDB 3.0 の TPC-H パフォーマンスを比較します [TiFlash](/tiflash/tiflash-overview.md) TiDB のハイブリッド トランザクションおよび分析処理 (HTAP) 機能を強化する TiDB v4.0 で導入されたため、このレポートのテスト オブジェクトは次のとおりです。 -- TiKV からのみデータを読み取る TiDB v3.0。 -- TiKV からのみデータを読み取る TiDB v4.0。 -- インテリジェントな選択に基づいて TiKV およびTiFlashからデータを自動的に読み取る TiDB v4.0。 +- TiKV からのみデータを読み取る TiDB v3.0。 +- TiKV からのみデータを読み取る TiDB v4.0。 +- インテリジェントな選択に基づいて TiKV およびTiFlashからデータを自動的に読み取る TiDB v4.0。 ## テスト環境（AWS EC2） {#test-environment-aws-ec2} @@ -104,11 +104,11 @@ 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 データをインポートします。 +2. TiUPのベンチ ツールを使用して、スケール係数 10 で TPC-H データをインポートします。 - - データを v3.0 にインポートするには、次のコマンドを実行します。 + - データを v3.0 にインポートするには、次のコマンドを実行します。 ```bash tiup bench tpch prepare \ @@ -117,7 +117,7 @@ set global tidb_index_lookup_join_concurrency = 16; --analyze --tidb_build_stats_concurrency 8 --tidb_distsql_scan_concurrency 30 ``` - - データを v4.0 にインポートするには、次のコマンドを実行します。 + - データを v4.0 にインポートするには、次のコマンドを実行します。 ```bash tiup bench tpch prepare \ @@ -127,22 +127,22 @@ set global tidb_index_lookup_join_concurrency = 16; --analyze --tidb_build_stats_concurrency 8 --tidb_distsql_scan_concurrency 30 ``` -3. TPC-H クエリを実行します。 +3. TPC-H クエリを実行します。 - 1. TPC-H SQL クエリ ファイルをダウンロードします。 + 1. TPC-H SQL クエリ ファイルをダウンロードします。 ```bash git clone https://github.com/pingcap/tidb-bench.git && cd tpch/queries ``` - 2. TPC-H クエリを実行し、各クエリの実行時間を記録します。 + 2. TPC-H クエリを実行し、各クエリの実行時間を記録します。 - - TiDB v3.0 の場合、MySQL クライアントを使用して TiDB に接続し、クエリを実行し、各クエリの実行時間を記録します。 - - TiDB v4.0 の場合、MySQL クライアントを使用して TiDB に接続し、データの読み取り元に基づいて次のいずれかの操作を選択します。 - - TiKV からのみデータを読み取る場合は、 `set @@session.tidb_isolation_read_engines = 'tikv,tidb';`設定し、クエリを実行して、各クエリの実行時間を記録します。 - - コストベースのインテリジェントな選択に基づいて TiKV およびTiFlashからデータが自動的に読み取られる場合は、 `set @@session.tidb_isolation_read_engines = 'tikv,tiflash,tidb';`設定し、クエリを実行して、各クエリの実行時間を記録します。 + - TiDB v3.0 の場合、MySQL クライアントを使用して TiDB に接続し、クエリを実行し、各クエリの実行時間を記録します。 + - TiDB v4.0 の場合、MySQL クライアントを使用して TiDB に接続し、データの読み取り元に基づいて次のいずれかの操作を選択します。 + - TiKV からのみデータを読み取る場合は、 `set @@session.tidb_isolation_read_engines = 'tikv,tidb';`設定し、クエリを実行して、各クエリの実行時間を記録します。 + - コストベースのインテリジェントな選択に基づいて TiKV およびTiFlashからデータが自動的に読み取られる場合は、 `set @@session.tidb_isolation_read_engines = 'tikv,tiflash,tidb';`設定し、クエリを実行して、各クエリの実行時間を記録します。 -4. クエリ実行時間のデータを抽出して整理します。 +4. クエリ実行時間のデータを抽出して整理します。 ## テスト結果 {#test-result} @@ -179,14 +179,14 @@ set global tidb_index_lookup_join_concurrency = 16; 上記のパフォーマンス図では、次のようになります。 -- 青い線は v3.0 を表します。 -- 赤い線は v4.0 (TiKV からのみ読み取られたデータ) を表します。 -- 黄色の線は v4.0 (インテリジェントな選択に基づいて TiKV およびTiFlashから自動的に読み取られたデータ) を表します。 -- Y軸はクエリの実行時間を表します。時間が短いほど、パフォーマンスは向上します。 +- 青い線は v3.0 を表します。 +- 赤い線は v4.0 (TiKV からのみ読み取られたデータ) を表します。 +- 黄色の線は v4.0 (インテリジェントな選択に基づいて TiKV およびTiFlashから自動的に読み取られたデータ) を表します。 +- Y軸はクエリの実行時間を表します。時間が短いほど、パフォーマンスは向上します。 結果の説明: -- **v4.0 TiKV Onlyは**、TiDBがTiKVからのみデータを読み取ることを意味します。結果は、TiDBとTiKVをv4.0にアップグレードした後、TPC-Hパフォーマンスが向上したことを示しています。 -- **v4.0 TiKV/ TiFlash Automatically は**、TiDB オプティマイザーがコスト見積もりに基づいてTiFlashレプリカからデータを読み取るかどうかを自動的に決定することを意味します。この結果は、v4.0 の完全な HTAP 形式で TPC-H パフォーマンスが向上したことを示しています。 +- **v4.0 TiKV Onlyは**、TiDBがTiKVからのみデータを読み取ることを意味します。結果は、TiDBとTiKVをv4.0にアップグレードした後、TPC-Hパフォーマンスが向上したことを示しています。 +- **v4.0 TiKV/ TiFlash Automatically は**、TiDB オプティマイザーがコスト見積もりに基づいてTiFlashレプリカからデータを読み取るかどうかを自動的に決定することを意味します。この結果は、v4.0 の完全な HTAP 形式で TPC-H パフォーマンスが向上したことを示しています。 上の図から、22 のクエリ セット全体で TPC-H のパフォーマンスが平均で約 100% 向上することがわかります。 diff --git a/best-practices-for-security-configuration.md b/best-practices-for-security-configuration.md index 7992ac1c51922..6ec27209ddf11 100644 --- a/best-practices-for-security-configuration.md +++ b/best-practices-for-security-configuration.md @@ -17,8 +17,8 @@ TiDBのセキュリティは、データの整合性と機密性を保護する このリスクを回避するには、デプロイメント中にルート パスワードを設定することをお勧めします。 -- TiUPを使用したデプロイメントの場合は、 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md#step-7-start-a-tidb-cluster)を参照して、ルート ユーザーのランダム パスワードを生成します。 -- TiDB Operatorを使用したデプロイメントの場合は、 [初期アカウントとパスワードを設定する](https://docs.pingcap.com/tidb-in-kubernetes/stable/initialize-a-cluster#set-initial-account-and-password)を参照して root パスワードを設定してください。 +- TiUPを使用したデプロイメントの場合は、 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md#step-7-start-a-tidb-cluster)を参照して、ルート ユーザーのランダム パスワードを生成します。 +- TiDB Operatorを使用したデプロイメントの場合は、 [初期アカウントとパスワードを設定する](https://docs.pingcap.com/tidb-in-kubernetes/stable/initialize-a-cluster#set-initial-account-and-password)を参照して root パスワードを設定してください。 [`--initialize-secure`](/command-line-flags-for-tidb-configuration.md#--initialize-secure)オプションを使用して、初期ルート ユーザーのネットワーク アクセスを制限することもできます。 @@ -34,11 +34,11 @@ TiDBのインストールにはデフォルトでGrafanaコンポーネントが TiDBの導入中は、Grafanaのパスワードを強力なものに変更し、システムのセキュリティを確保するために定期的に更新することをお勧めします。Grafanaのパスワードを変更する手順は次のとおりです。 -- Grafana に初めてログインしたら、プロンプトに従ってパスワードを変更します。 +- Grafana に初めてログインしたら、プロンプトに従ってパスワードを変更します。 ![Grafana Password Reset Guide](/media/grafana-password-reset1.png) -- パスワードを変更するには、Grafana 個人設定センターにアクセスします。 +- パスワードを変更するには、Grafana 個人設定センターにアクセスします。 ![Grafana Password Reset Guide](/media/grafana-password-reset2.png) @@ -54,13 +54,13 @@ TiDB DashboardはTiDB SQLユーザーとアカウントシステムを共有し TiDB Dashboardは、デフォルトでは信頼できるユーザー向けに設計されています。デフォルトのポートには、TiDB Dashboardに加えて追加のAPIインターフェースが含まれています。外部ネットワークや信頼できないユーザーからのTiDB Dashboardへのアクセスを許可する場合は、セキュリティ上の脆弱性を回避するために、以下の対策を講じてください。 -- ファイアウォールまたはその他のメカニズムを使用して、デフォルトの`2379`ポートを信頼できるドメインに制限し、外部ユーザーによるアクセスを防止します。 +- ファイアウォールまたはその他のメカニズムを使用して、デフォルトの`2379`ポートを信頼できるドメインに制限し、外部ユーザーによるアクセスを防止します。 > **Note:** > > TiDB、TiKV、その他のコンポーネントは、PDクライアントポートを介してPDコンポーネントと通信する必要があります。コンポーネント間の内部ネットワークアクセスをブロックしないでください。ブロックすると、クラスターが利用できなくなります。 -- [リバースプロキシを構成する](/dashboard/dashboard-ops-reverse-proxy.md#use-tidb-dashboard-behind-a-reverse-proxy) 、別のポート上の外部ユーザーに TiDB Dashboard サービスを安全に提供します。 +- [リバースプロキシを構成する](/dashboard/dashboard-ops-reverse-proxy.md#use-tidb-dashboard-behind-a-reverse-proxy) 、別のポート上の外部ユーザーに TiDB Dashboard サービスを安全に提供します。 ## 内部ポートを保護する {#protect-internal-ports} diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md index 47e9a78acc6e2..474caccb05357 100644 --- a/best-practices/best-practices-on-public-cloud.md +++ b/best-practices/best-practices-on-public-cloud.md @@ -65,21 +65,21 @@ sdd 1033.00 4132.00 1141.33 31685.33 571.00 0.94 100.00 さまざまなパブリック クラウドに推奨されるミドルレンジ ディスクは次のとおりです。 -- AWSでは[gp3](https://aws.amazon.com/ebs/general-purpose/)推奨されます。gp3ボリュームは、ボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分な値です。 +- AWSでは[gp3](https://aws.amazon.com/ebs/general-purpose/)推奨されます。gp3ボリュームは、ボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分な値です。 -- Google Cloudでは[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)推奨されています。IOPSとMBPSは割り当てられたディスクサイズによって異なります。パフォーマンス要件を満たすには、 Raft Engineに200GBを割り当てることを推奨します。Raft Raft Engineはそれほど大きな容量を必要としませんが、最適なパフォーマンスを確保できます。 +- Google Cloudでは[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)推奨されています。IOPSとMBPSは割り当てられたディスクサイズによって異なります。パフォーマンス要件を満たすには、 Raft Engineに200GBを割り当てることを推奨します。Raft Raft Engineはそれほど大きな容量を必要としませんが、最適なパフォーマンスを確保できます。 -- Azureでは[プレミアム SSD v2](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssd-v2)推奨されます。AWS gp3と同様に、Premium SSD v2はボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分です。 +- Azureでは[プレミアム SSD v2](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssd-v2)推奨されます。AWS gp3と同様に、Premium SSD v2はボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分です。 #### ハイエンドディスク {#high-end-disk} Raft Engineのレイテンシーをさらに低減したい場合は、ハイエンドディスクの使用を検討してください。以下は、各パブリッククラウドで推奨されるハイエンドディスクです。 -- AWSでは[io2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)が推奨されます。ディスクサイズとIOPSは、お客様の特定の要件に応じてプロビジョニングできます。 +- AWSでは[io2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)が推奨されます。ディスクサイズとIOPSは、お客様の特定の要件に応じてプロビジョニングできます。 -- Google Cloud では[pd-extreme](https://cloud.google.com/compute/docs/disks#disk-types/)推奨されます。ディスクサイズ、IOPS、MBPS をプロビジョニングできますが、64 個以上の CPU コアを持つインスタンスでのみ利用可能です。 +- Google Cloud では[pd-extreme](https://cloud.google.com/compute/docs/disks#disk-types/)推奨されます。ディスクサイズ、IOPS、MBPS をプロビジョニングできますが、64 個以上の CPU コアを持つインスタンスでのみ利用可能です。 -- Azure では[Ultra Disk](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#ultra-disks)が推奨されます。ディスクサイズ、IOPS、MBPS は、お客様の特定の要件に応じてプロビジョニングできます。 +- Azure では[Ultra Disk](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#ultra-disks)が推奨されます。ディスクサイズ、IOPS、MBPS は、お客様の特定の要件に応じてプロビジョニングできます。 ### 例 1: AWS でソーシャル ネットワーク ワークロードを実行する {#example-1-run-a-social-network-workload-on-aws} @@ -87,9 +87,9 @@ AWS は、20 GB [gp3](https://aws.amazon.com/ebs/general-purpose/)ボリュー 書き込み集中型のソーシャル ネットワーク アプリケーション ワークロードに AWS 上の専用の 20 GB [gp3](https://aws.amazon.com/ebs/general-purpose/) Raft Engineディスクを使用すると、次のような改善が見られますが、推定コストはわずか 0.4% しか増加しません。 -- QPS（1秒あたりのクエリ数）が17.5%増加 -- 挿入文の平均レイテンシーが18.7%減少 -- 挿入ステートメントの p99レイテンシーが 45.6% 減少しました。 +- QPS（1秒あたりのクエリ数）が17.5%増加 +- 挿入文の平均レイテンシーが18.7%減少 +- 挿入ステートメントの p99レイテンシーが 45.6% 減少しました。 | メトリック | 共有Raft Engineディスク | 専用Raft Engineディスク | 違い （％） | | ---------------- | ----------------- | ----------------- | ------ | @@ -101,8 +101,8 @@ AWS は、20 GB [gp3](https://aws.amazon.com/ebs/general-purpose/)ボリュー 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% 減少しました。 +- Sysbench `oltp_read_write`ワークロード: QPS が 17.8% 増加し、平均レイテンシーが 15.6% 減少しました。 +- TPC-C ワークロード: QPS が 27.6% 増加し、平均レイテンシーが 23.1% 減少しました。 | メトリック | 作業負荷 | 共有Raft Engineディスク | 専用Raft Engineディスク | 違い （％） | | ------------ | ------------------------ | ----------------- | ----------------- | ------ | @@ -145,9 +145,9 @@ Google Cloud の[ライブマイグレーション機能](https://cloud.google.c Google Cloud によって開始されたライブマイグレーション イベントを検出し、これらのイベントによるパフォーマンスへの影響を軽減するために、TiDB は Google のメタデータ[例](https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/compute/metadata/main.py)に基づく[スクリプトを見る](https://github.com/PingCAP-QE/tidb-google-maintenance)提供します。このスクリプトを TiDB、TiKV、PD ノードにデプロイして、メンテナンス イベントを検出できます。メンテナンス イベントが検出されると、中断を最小限に抑え、クラスタの動作を最適化するために、次のように適切なアクションが自動的に実行されます。 -- TiDB: TiDBノードをオフラインにし、TiDBポッドを削除します。これは、TiDBインスタンスのノードプールが自動スケールに設定され、TiDB専用になっていることを前提としています。ノード上で実行されている他のポッドに中断が発生する可能性があり、切断されたノードは自動スケーラーによって回収されることが想定されます。 -- TiKV: メンテナンス中に、影響を受ける TiKV ストアのリーダーを削除します。 -- PD: 現在の PD インスタンスが PD リーダーである場合、リーダーを辞任します。 +- TiDB: TiDBノードをオフラインにし、TiDBポッドを削除します。これは、TiDBインスタンスのノードプールが自動スケールに設定され、TiDB専用になっていることを前提としています。ノード上で実行されている他のポッドに中断が発生する可能性があり、切断されたノードは自動スケーラーによって回収されることが想定されます。 +- TiKV: メンテナンス中に、影響を受ける TiKV ストアのリーダーを削除します。 +- PD: 現在の PD インスタンスが PD リーダーである場合、リーダーを辞任します。 この監視スクリプトは、Kubernetes 環境での TiDB の強化された管理機能を提供する[TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/tidb-operator-overview)を使用してデプロイされた TiDB クラスター用に特別に設計されていることに注意することが重要です。 @@ -196,9 +196,9 @@ set global tidb_tso_client_batch_max_wait_time = 2; # default: 0 チューニング後、次の効果が見られます。 -- 1 秒あたりの TSO リクエストは 64,800 に減少します。 -- CPU 使用率は約 4,600% から 1,400% に大幅に減少しました。 -- P999 値`PD server TSO handle time`が 2ms から 0.5ms に減少します。 +- 1 秒あたりの TSO リクエストは 64,800 に減少します。 +- CPU 使用率は約 4,600% から 1,400% に大幅に減少しました。 +- P999 値`PD server TSO handle time`が 2ms から 0.5ms に減少します。 これらの改善は、チューニング調整によって、安定した TSO 処理パフォーマンスを維持しながら、PDサーバーの CPU 使用率を正常に削減できたことを示しています。 diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md index 30eecf949e8c0..41009c231b170 100644 --- a/best-practices/ddl-introduction.md +++ b/best-practices/ddl-introduction.md @@ -20,11 +20,11 @@ TiDBはオンラインDDLをサポートしています。つまり、データ 対象となるDDLオブジェクトに含まれるデータを操作するかどうかによって、DDL文は次の種類に分類されます。 -- **論理 DDL ステートメント**: 論理 DDL ステートメントは通常、テーブル名の変更や列名の変更など、オブジェクトに格納されているデータを処理せずに、データベース オブジェクトのメタデータのみを変更します。 +- **論理 DDL ステートメント**: 論理 DDL ステートメントは通常、テーブル名の変更や列名の変更など、オブジェクトに格納されているデータを処理せずに、データベース オブジェクトのメタデータのみを変更します。 TiDBでは、論理DDL文は「汎用DDL」とも呼ばれます。これらの文は通常、実行時間が短く、完了までに数十ミリ秒または数秒しかかからないことがよくあります。そのため、システムリソースをあまり消費せず、アプリケーションのワークロードにも影響を与えません。 -- **物理DDL文**：物理DDL文は、変更対象となるオブジェクトのメタデータを変更するだけでなく、オブジェクトに格納されているユーザーデータも変更します。例えば、TiDBがテーブルのインデックスを作成する場合、テーブルの定義を変更するだけでなく、新しく追加されたインデックスを構築するためにテーブル全体のスキャンを実行します。 +- **物理DDL文**：物理DDL文は、変更対象となるオブジェクトのメタデータを変更するだけでなく、オブジェクトに格納されているユーザーデータも変更します。例えば、TiDBがテーブルのインデックスを作成する場合、テーブルの定義を変更するだけでなく、新しく追加されたインデックスを構築するためにテーブル全体のスキャンを実行します。 TiDBでは、物理DDL文は「reorg DDL」（再編成）とも呼ばれます。現在、物理DDL文には、 `ADD INDEX`と非可逆的な列型変更（例えば、 `INT`型から`CHAR`型への変更）のみが含まれます。これらの文の実行には時間がかかり、実行時間はテーブル内のデータ量、マシン構成、アプリケーションのワークロードによって影響を受けます。 @@ -84,17 +84,17 @@ DDLタスク間に依存関係がない場合、並列実行はデータの正 DDL実行のユーザーエクスペリエンスを向上させるため、TiDB v6.2.0以降では、オーナーがDDLタスクの関連性を判断できるようになりました。そのロジックは次のとおりです。 -- 同じテーブルに対して実行される DDL ステートメントは相互にブロックされます。 -- `DROP DATABASE`と、データベース内のすべてのオブジェクトに影響する DDL ステートメントは相互にブロックされます。 -- 異なるテーブルでのインデックスの追加と列タイプの変更を同時に実行できます。 -- v8.2.0 以降では、異なるテーブルに対して[論理DDLステートメント](/best-practices/ddl-introduction.md#types-of-ddl-statements)並列実行できます。 -- それ以外の場合、同時 DDL 実行の可用性レベルに基づいて DDL を実行できます。 +- 同じテーブルに対して実行される DDL ステートメントは相互にブロックされます。 +- `DROP DATABASE`と、データベース内のすべてのオブジェクトに影響する DDL ステートメントは相互にブロックされます。 +- 異なるテーブルでのインデックスの追加と列タイプの変更を同時に実行できます。 +- v8.2.0 以降では、異なるテーブルに対して[論理DDLステートメント](/best-practices/ddl-introduction.md#types-of-ddl-statements)並列実行できます。 +- それ以外の場合、同時 DDL 実行の可用性レベルに基づいて DDL を実行できます。 具体的には、TiDB 6.2.0 では、次の点で DDL 実行フレームワークが強化されました。 -- DDL 所有者は、前述のロジックに基づいて DDL タスクを並列に実行できます。 -- DDLジョブキューにおける先入先出法の問題が解決されました。DDLオーナーはキュー内の最初のジョブを選択するのではなく、現時点で実行可能なジョブを選択するようになりました。 -- 物理 DDL 文を処理するワーカーの数が増加し、複数の物理 DDL 文を並列に実行できるようになりました。 +- DDL 所有者は、前述のロジックに基づいて DDL タスクを並列に実行できます。 +- DDLジョブキューにおける先入先出法の問題が解決されました。DDLオーナーはキュー内の最初のジョブを選択するのではなく、現時点で実行可能なジョブを選択するようになりました。 +- 物理 DDL 文を処理するワーカーの数が増加し、複数の物理 DDL 文を並列に実行できるようになりました。 TiDBのすべてのDDLタスクはオンライン変更アプローチを使用して実装されているため、TiDBはオーナーを通じて新しいDDLジョブの関連性を判断し、その情報に基づいてDDLタスクをスケジュールすることができます。このアプローチにより、分散データベースは従来のデータベースと同等のDDL同時実行性を実現できます。 @@ -105,25 +105,25 @@ DDL実行のユーザーエクスペリエンスを向上させるため、TiDB v6.2.0 より前では、 TiDB SQLレイヤーで非同期スキーマ変更を処理するプロセスは次のとおりです。 -1. MySQL クライアントは TiDBサーバーに DDL 要求を送信します。 +1. MySQL クライアントは TiDBサーバーに DDL 要求を送信します。 -2. リクエストを受信すると、TiDBサーバーはMySQL プロトコルレイヤーでリクエストを解析および最適化し、実行のためにTiDB SQLレイヤーに送信します。 +2. リクエストを受信すると、TiDBサーバーはMySQL プロトコルレイヤーでリクエストを解析および最適化し、実行のためにTiDB SQLレイヤーに送信します。 TiDBのSQLレイヤーはDDLリクエストを受信すると、 `start job`モジュールを起動してリクエストを特定のDDLジョブ（つまりDDLタスク）にカプセル化し、ステートメントの種類に基づいてKVレイヤーの対応するDDLジョブキューに格納します。処理が必要なジョブは、対応するワーカーに通知されます。 -3. ジョブ処理の通知を受け取ると、ワーカーはDDLオーナーのロールを持っているかどうかを判断します。DDLオーナーのロールを持っている場合は、ジョブを直接処理します。そうでない場合は、何も処理せずに終了します。 +3. ジョブ処理の通知を受け取ると、ワーカーはDDLオーナーのロールを持っているかどうかを判断します。DDLオーナーのロールを持っている場合は、ジョブを直接処理します。そうでない場合は、何も処理せずに終了します。 TiDBサーバーがオーナーロールでない場合は、別のノードがオーナーになる必要があります。オーナーロールのノードのワーカーは、実行可能なジョブがあるかどうかを定期的に確認します。実行可能なジョブが見つかった場合、ワーカーはそのジョブを処理します。 -4. ワーカーはジョブを処理した後、KVレイヤーのジョブキューからジョブを削除し、 `job history queue`に配置します。ジョブをカプセル化された`start job`モジュールは、 `job history queue`内のジョブIDを定期的にチェックし、処理済みかどうかを確認します。処理済みであれば、ジョブに対応するDDL操作全体が終了します。 +4. ワーカーはジョブを処理した後、KVレイヤーのジョブキューからジョブを削除し、 `job history queue`に配置します。ジョブをカプセル化された`start job`モジュールは、 `job history queue`内のジョブIDを定期的にチェックし、処理済みかどうかを確認します。処理済みであれば、ジョブに対応するDDL操作全体が終了します。 -5. TiDBサーバーは、DDL 処理結果を MySQL クライアントに返します。 +5. TiDBサーバーは、DDL 処理結果を MySQL クライアントに返します。 TiDB v6.2.0 より前では、DDL 実行フレームワークには次の制限がありました。 -- TiKV クラスターには、それぞれ論理 DDL と物理 DDL を処理するキュー`general job queue`と`add index job queue` 2 つのキューのみがあります。 -- DDL 所有者は常に先入先出方式で DDL ジョブを処理します。 -- DDL 所有者は、一度に同じタイプ (論理または物理) の DDL タスクを 1 つだけ実行できます。これは比較的厳格であり、ユーザー エクスペリエンスに影響します。 +- TiKV クラスターには、それぞれ論理 DDL と物理 DDL を処理するキュー`general job queue`と`add index job queue` 2 つのキューのみがあります。 +- DDL 所有者は常に先入先出方式で DDL ジョブを処理します。 +- DDL 所有者は、一度に同じタイプ (論理または物理) の DDL タスクを 1 つだけ実行できます。これは比較的厳格であり、ユーザー エクスペリエンスに影響します。 これらの制限により、意図しないDDLブロッキング動作が発生する可能性があります。詳細については、 [SQL FAQ - DDL実行](https://docs.pingcap.com/tidb/stable/sql-faq#ddl-execution)を参照してください。 @@ -136,20 +136,20 @@ TiDB v6.2.0 より前では、DDL 実行フレームワークには次の制限 物理 DDL ステートメント (インデックスの追加や列タイプの変更を含む) を実行する場合、次のシステム変数の値を調整して、DDL 実行の速度とアプリケーションの負荷への影響のバランスを取ることができます。 -- [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) : この変数は、バックフィルの同時実行を制御する DDL 操作の再編成ワーカーの数を設定します。 +- [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) : この変数は、バックフィルの同時実行を制御する DDL 操作の再編成ワーカーの数を設定します。 -- [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) : この変数は、`re-organize`フェーズの DDL 操作のバッチ サイズを設定し、バックフィルされるデータの量を制御します。 +- [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) : この変数は、`re-organize`フェーズの DDL 操作のバッチ サイズを設定し、バックフィルされるデータの量を制御します。 推奨値: - - 他に負荷がない場合は、 `tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`の値を増やすことで`ADD INDEX`処理を高速化できます。例えば、2つの変数の値をそれぞれ`20`と`2048`に設定することができます。 - - 他の負荷がある場合は、 `tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`の値を減らして他のアプリケーションへの影響を最小限に抑えることができます。例えば、これらの変数の値をそれぞれ`4`と`256`に設定することができます。 + - 他に負荷がない場合は、 `tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`の値を増やすことで`ADD INDEX`処理を高速化できます。例えば、2つの変数の値をそれぞれ`20`と`2048`に設定することができます。 + - 他の負荷がある場合は、 `tidb_ddl_reorg_worker_cnt`と`tidb_ddl_reorg_batch_size`の値を減らして他のアプリケーションへの影響を最小限に抑えることができます。例えば、これらの変数の値をそれぞれ`4`と`256`に設定することができます。 > **Tip:** > -> - 前述の 2 つの変数は、DDL タスクの実行中に動的に調整され、次のトランザクション バッチで有効になります。 -> - DDL操作の種類とアプリケーションの負荷状況に応じて、適切なタイミングでDDL操作を実行してください。例えば、アプリケーションの負荷が低い場合は、 `ADD INDEX`操作を実行することをお勧めします。 -> - インデックスの追加には比較的長い時間がかかるため、TiDBはコマンド送信後、バックグラウンドでタスクを実行します。TiDBサーバーがダウンしていても、実行には影響ありません。 +> - 前述の 2 つの変数は、DDL タスクの実行中に動的に調整され、次のトランザクション バッチで有効になります。 +> - DDL操作の種類とアプリケーションの負荷状況に応じて、適切なタイミングでDDL操作を実行してください。例えば、アプリケーションの負荷が低い場合は、 `ADD INDEX`操作を実行することをお勧めします。 +> - インデックスの追加には比較的長い時間がかかるため、TiDBはコマンド送信後、バックグラウンドでタスクを実行します。TiDBサーバーがダウンしていても、実行には影響ありません。 ### DDLリクエストを同時に送信して多数のテーブルを素早く作成する {#quickly-create-many-tables-by-concurrently-sending-ddl-requests} @@ -167,28 +167,28 @@ 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`エラーを返します。 +- `ADMIN CANCEL DDL JOBS job_id, [, job_id]` : 送信されたが完了していないDDLタスクをキャンセルするために使用されます。キャンセルが完了すると、DDLタスクを実行するSQL文は`ERROR 8214 (HY000): Cancelled DDL job`エラーを返します。 完了した DDL タスクがキャンセルされた場合、 `RESULT`列に`DDL Job:90 not found`エラーが表示されます。これは、タスクが DDL 待機キューから削除されたことを意味します。 -- `ADMIN PAUSE DDL JOBS job_id [, job_id]` : 実行中のDDLジョブを一時停止します。コマンド実行後、バックグラウンドジョブが一時停止されている間、DDLジョブを実行するSQL文は実行中として表示されます。詳細は[`ADMIN PAUSE DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)を参照してください。 +- `ADMIN PAUSE DDL JOBS job_id [, job_id]` : 実行中のDDLジョブを一時停止します。コマンド実行後、バックグラウンドジョブが一時停止されている間、DDLジョブを実行するSQL文は実行中として表示されます。詳細は[`ADMIN PAUSE DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)を参照してください。 一時停止できるのは、進行中またはキュー内にあるDDLタスクのみです。それ以外の場合は、 `RESULT`列にエラー`Job 3 can't be paused now`が表示されます。 -- `ADMIN RESUME DDL JOBS job_id [, job_id]` : 一時停止中のDDLタスクを再開します。コマンド実行後、DDLタスクを実行するSQL文が実行中として表示され、バックグラウンドタスクが再開されます。詳細は[`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)を参照してください。 +- `ADMIN RESUME DDL JOBS job_id [, job_id]` : 一時停止中のDDLタスクを再開します。コマンド実行後、DDLタスクを実行するSQL文が実行中として表示され、バックグラウンドタスクが再開されます。詳細は[`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)を参照してください。 一時停止中のDDLタスクのみを再開できます。それ以外の場合は、 `RESULT`列にエラー`Job 3 can't be resumed`が表示されます。 ## DDL関連テーブル {#ddl-related-tables} -- [`information_schema.DDL_JOBS`](/information-schema/information-schema-ddl-jobs.md) : 現在実行中および完了した DDL ジョブに関する情報。 -- [`mysql.tidb_mdl_view`](/mysql-schema/mysql-schema-tidb-mdl-view.md) : [メタデータロック](/metadata-lock.md)のビューに関する情報。DDLの進行を妨げているクエリを特定するのに役立ちます。 +- [`information_schema.DDL_JOBS`](/information-schema/information-schema-ddl-jobs.md) : 現在実行中および完了した DDL ジョブに関する情報。 +- [`mysql.tidb_mdl_view`](/mysql-schema/mysql-schema-tidb-mdl-view.md) : [メタデータロック](/metadata-lock.md)のビューに関する情報。DDLの進行を妨げているクエリを特定するのに役立ちます。 ## よくある質問 {#common-questions} diff --git a/best-practices/grafana-monitor-best-practices.md b/best-practices/grafana-monitor-best-practices.md index ba894fa4687d4..44a30b81573d8 100644 --- a/best-practices/grafana-monitor-best-practices.md +++ b/best-practices/grafana-monitor-best-practices.md @@ -16,9 +16,9 @@ aliases: ['/ja/docs/dev/best-practices/grafana-monitor-best-practices/','/ja/doc TiDB 2.1.3以降のバージョンでは、TiDBモニタリングはプル方式をサポートしています。これは以下の利点を持つ優れた調整です。 -- Prometheus を移行する必要がある場合、TiDB クラスター全体を再起動する必要はありません。調整前に Prometheus を移行するには、ターゲットアドレスを更新する必要があるため、クラスター全体を再起動する必要があります。 -- 監視ポイントが単一になるのを防ぐために、Grafana + Prometheus 監視プラットフォーム (高可用性ではない) の 2 つの個別のセットを展開できます。 -- 単一障害点となる可能性のある Pushgateway が削除されます。 +- Prometheus を移行する必要がある場合、TiDB クラスター全体を再起動する必要はありません。調整前に Prometheus を移行するには、ターゲットアドレスを更新する必要があるため、クラスター全体を再起動する必要があります。 +- 監視ポイントが単一になるのを防ぐために、Grafana + Prometheus 監視プラットフォーム (高可用性ではない) の 2 つの個別のセットを展開できます。 +- 単一障害点となる可能性のある Pushgateway が削除されます。 ## 監視データのソースと表示 {#source-and-display-of-monitoring-data} @@ -53,11 +53,11 @@ tidb_executor_statement_total{type="Use"} 466016 **Edit**ボタンをクリックすると、**Metrics**タブに`tidb_executor_statement_total`メトリクス名を含むクエリ式が表示されます。パネル上のいくつかの項目の意味は次のとおりです。 -- `rate[1m]` : 1分間の成長率。カウンター型のデータにのみ使用できます。 -- `sum` : 値の合計。 -- `by type` : 合計データは元のメトリック値でタイプ別にグループ化されます。 -- `Legend format` : メトリック名の形式。 -- `Resolution` : ステップ幅はデフォルトで15秒です。解像度は、複数のピクセルに対して1つのデータポイントを生成するかどうかを指定します。 +- `rate[1m]` : 1分間の成長率。カウンター型のデータにのみ使用できます。 +- `sum` : 値の合計。 +- `by type` : 合計データは元のメトリック値でタイプ別にグループ化されます。 +- `Legend format` : メトリック名の形式。 +- `Resolution` : ステップ幅はデフォルトで15秒です。解像度は、複数のピクセルに対して1つのデータポイントを生成するかどうかを指定します。 **Metrics**タブのクエリ式は次のとおりです。 @@ -147,9 +147,9 @@ PDダッシュボードには、現在のリーダーの指標のみが表示さ GrafanaはPrometheusのAPIを介してデータを取得します。このAPIを使用して情報を取得することもできます。さらに、以下の用途もあります。 -- クラスターのサイズやステータスなどの情報を自動的に取得します。 -- 1 日あたりの QPS の合計量、1 日あたりの QPS のピーク値、1 日あたりの応答時間のカウントなど、レポートの情報を提供するために式に小さな変更を加えます。 -- 重要な指標について定期的な健全性検査を実行します。 +- クラスターのサイズやステータスなどの情報を自動的に取得します。 +- 1 日あたりの QPS の合計量、1 日あたりの QPS のピーク値、1 日あたりの応答時間のカウントなど、レポートの情報を提供するために式に小さな変更を加えます。 +- 重要な指標について定期的な健全性検査を実行します。 Prometheus の API は次のようになります。 diff --git a/best-practices/haproxy-best-practices.md b/best-practices/haproxy-best-practices.md index bbf1859bd5ffc..d2a74440695d6 100644 --- a/best-practices/haproxy-best-practices.md +++ b/best-practices/haproxy-best-practices.md @@ -22,12 +22,12 @@ HAProxyは、LinuxカーネルのコアコントリビューターであるWilly ## 基本機能 {#basic-features} -- [高可用性](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.4) : HAProxy は、正常なシャットダウンとシームレスな切り替えをサポートする高可用性を提供します。 -- [負荷分散](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#4.2-balance) : 2 つの主要なプロキシ モード (レイヤー4 とも呼ばれる TCP とレイヤー7 とも呼ばれる HTTP) がサポートされています。ラウンドロビン、Leastconn、ランダムなど、9 種類以上の負荷分散アルゴリズムがサポートされています。 -- [健康チェック](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#5.2-check) : HAProxy はサーバーの HTTP または TCP モードのステータスを定期的にチェックします。 -- [スティッキーセッション](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.6) : アプリケーションがスティッキーセッションをサポートしていない間、HAProxy はクライアントを特定のサーバーに固定することができます。 -- [SSL](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.2) : HTTPS 通信と解決がサポートされます。 -- [監視と統計](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.3) ：Web ページを通じて、サービスの状態とトラフィック フローをリアルタイムで監視できます。 +- [高可用性](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.4) : HAProxy は、正常なシャットダウンとシームレスな切り替えをサポートする高可用性を提供します。 +- [負荷分散](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#4.2-balance) : 2 つの主要なプロキシ モード (レイヤー4 とも呼ばれる TCP とレイヤー7 とも呼ばれる HTTP) がサポートされています。ラウンドロビン、Leastconn、ランダムなど、9 種類以上の負荷分散アルゴリズムがサポートされています。 +- [健康チェック](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#5.2-check) : HAProxy はサーバーの HTTP または TCP モードのステータスを定期的にチェックします。 +- [スティッキーセッション](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.6) : アプリケーションがスティッキーセッションをサポートしていない間、HAProxy はクライアントを特定のサーバーに固定することができます。 +- [SSL](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.2) : HTTPS 通信と解決がサポートされます。 +- [監視と統計](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.3) ：Web ページを通じて、サービスの状態とトラフィック フローをリアルタイムで監視できます。 ## 始める前に {#before-you-begin} @@ -59,13 +59,13 @@ HAProxy をデプロイする前に、ハードウェアとソフトウェアの > **Note:** > -> - サポートされているその他のオペレーティング システムの詳細については、 [HAProxyドキュメント](https://github.com/haproxy/haproxy/blob/master/INSTALL)を参照してください。 +> - サポートされているその他のオペレーティング システムの詳細については、 [HAProxyドキュメント](https://github.com/haproxy/haproxy/blob/master/INSTALL)を参照してください。 #### 依存関係 {#dependencies} -- エペルリリース -- gcc -- systemd-devel +- エペルリリース +- gcc +- systemd-devel 上記の依存関係をインストールするには、次のコマンドを実行します。 @@ -79,19 +79,19 @@ HAProxyを使用すると、負荷分散されたデータベース環境を簡 ### HAProxyをインストールする {#install-haproxy} -1. HAProxy 2.6.21 ソースコードのパッケージをダウンロードします。 +1. HAProxy 2.6.21 ソースコードのパッケージをダウンロードします。 ```bash wget https://www.haproxy.org/download/2.6/src/haproxy-2.6.21.tar.gz ``` -2. パッケージを抽出します。 +2. パッケージを抽出します。 ```bash tar zxf haproxy-2.6.21.tar.gz ``` -3. ソースコードからアプリケーションをコンパイルします。 +3. ソースコードからアプリケーションをコンパイルします。 ```bash cd haproxy-2.6.21 @@ -100,14 +100,14 @@ HAProxyを使用すると、負荷分散されたデータベース環境を簡 make PREFIX=${/app/haproxy} SBINDIR=${/app/haproxy/bin} install # Replace `${/app/haproxy}` and `${/app/haproxy/bin}` with your custom directories. ``` -4. プロファイルを再構成します。 +4. プロファイルを再構成します。 ```bash echo 'export PATH=/app/haproxy/bin:$PATH' >> /etc/profile . /etc/profile ``` -5. インストールが成功したかどうかを確認します。 +5. インストールが成功したかどうかを確認します。 ```bash which haproxy @@ -220,13 +220,13 @@ haproxy -f /etc/haproxy/haproxy.cfg HAProxy を停止するには、 `kill -9`コマンドを使用します。 -1. 次のコマンドを実行します。 +1. 次のコマンドを実行します。 ```bash ps -ef | grep haproxy ``` -2. HAProxy のプロセスを終了します。 +2. HAProxy のプロセスを終了します。 ```bash kill -9 ${haproxy.pid} diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md index c684f276e9ebe..6d5ce86947351 100644 --- a/best-practices/high-concurrency-best-practices.md +++ b/best-practices/high-concurrency-best-practices.md @@ -12,22 +12,22 @@ aliases: ['/ja/tidb/stable/high-concurrency-best-practices/','/ja/tidb/dev/high- このドキュメントは、読者がTiDBの基礎を理解していることを前提としています。まず、TiDBの基礎を解説した以下の3つのブログ記事と、 [TiDB ベストプラクティス](https://www.pingcap.com/blog/tidb-best-practice/)読みいただくことをお勧めします。 -- [データストレージ](https://www.pingcap.com/blog/tidb-internal-data-storage/) -- [コンピューティング](https://www.pingcap.com/blog/tidb-internal-computing/) -- [スケジュール](https://www.pingcap.com/blog/tidb-internal-scheduling/) +- [データストレージ](https://www.pingcap.com/blog/tidb-internal-data-storage/) +- [コンピューティング](https://www.pingcap.com/blog/tidb-internal-computing/) +- [スケジュール](https://www.pingcap.com/blog/tidb-internal-scheduling/) ## 同時書き込みの多いシナリオ {#highly-concurrent-write-intensive-scenario} 高度な同時書き込みシナリオは、決済や清算などのアプリケーションでバッチタスクを実行する際によく発生します。このシナリオには、次のような特徴があります。 -- 膨大な量のデータ -- 履歴データを短時間でデータベースにインポートする必要性 -- 短時間でデータベースから大量のデータを読み取る必要がある +- 膨大な量のデータ +- 履歴データを短時間でデータベースにインポートする必要性 +- 短時間でデータベースから大量のデータを読み取る必要がある これらの機能は TiDB に次のような課題をもたらします。 -- 書き込み容量または読み取り容量は線形に拡張可能である必要があります。 -- 大量のデータが同時に書き込まれてもデータベースのパフォーマンスは安定しており、低下しません。 +- 書き込み容量または読み取り容量は線形に拡張可能である必要があります。 +- 大量のデータが同時に書き込まれてもデータベースのパフォーマンスは安定しており、低下しません。 分散データベースでは、すべてのノードの能力を最大限に活用し、単一のノードがボトルネックにならないようにすることが重要です。 @@ -210,8 +210,8 @@ ORDER BY create table t (a int, b int) SHARD_ROW_ID_BITS = 4 PRE_SPLIT_REGIONS=3; ``` -- `SHARD_ROW_ID_BITS = 4` 、 `tidb_rowid`の値が 16 (16=2^4) の範囲にランダムに分散されることを意味します。 -- `PRE_SPLIT_REGIONS=3` 、テーブルが作成後に 8 (2^3) 個のリージョンに事前に分割されることを意味します。 +- `SHARD_ROW_ID_BITS = 4` 、 `tidb_rowid`の値が 16 (16=2^4) の範囲にランダムに分散されることを意味します。 +- `PRE_SPLIT_REGIONS=3` 、テーブルが作成後に 8 (2^3) 個のリージョンに事前に分割されることを意味します。 テーブル`t`にデータの書き込みが開始されると、データは事前​​に分割された 8 つのリージョンに書き込まれます。これにより、テーブルの作成後に 1 つのリージョンのみが存在する場合に発生する可能性のあるホットスポットの問題が回避されます。 diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md index fe46f5e4ca2e9..59d72a43a23a5 100644 --- a/best-practices/index-management-best-practices.md +++ b/best-practices/index-management-best-practices.md @@ -8,17 +8,17 @@ aliases: ['/ja/tidb/stable/index-management-best-practices/'] インデックスは、データベースクエリのパフォーマンスを最適化し、大量のデータのスキャンの必要性を減らすために不可欠です。しかし、アプリケーションの進化、ビジネスロジックの変化、データ量の増加に伴い、元のインデックス設計では以下のような問題が発生することがあります。 -- 未使用のインデックス: これらのインデックスはかつては関連していましたが、クエリ オプティマイザーによって選択されなくなり、ストレージを消費し、書き込み操作に不要なオーバーヘッドが追加されます。 -- 非効率的なインデックス: 一部のインデックスはオプティマイザーによって使用されますが、予想よりも多くのデータをスキャンするため、ディスク I/O が増加し、クエリのパフォーマンスが低下します。 +- 未使用のインデックス: これらのインデックスはかつては関連していましたが、クエリ オプティマイザーによって選択されなくなり、ストレージを消費し、書き込み操作に不要なオーバーヘッドが追加されます。 +- 非効率的なインデックス: 一部のインデックスはオプティマイザーによって使用されますが、予想よりも多くのデータをスキャンするため、ディスク I/O が増加し、クエリのパフォーマンスが低下します。 これらのインデックス作成の問題を放置すると、ストレージコストの増加、パフォーマンスの低下、運用効率の低下につながる可能性があります。TiDBのような分散SQLデータベースでは、分散クエリの規模と複数ノード間の調整の複雑さにより、インデックス作成の非効率性の影響はさらに大きくなります。そのため、データベースを最適化した状態に保つには、定期的なインデックス監査が不可欠です。 インデックスを積極的に識別して最適化すると、次のことが可能になります。 -- ストレージのオーバーヘッドを削減: 未使用のインデックスを削除すると、ディスク領域が解放され、長期的なストレージコストが削減されます。 -- 書き込みパフォーマンスの向上: 不要なインデックスメンテナンスが排除されると、書き込みが多いワークロード ( `INSERT` 、 `UPDATE` 、 `DELETE`など) のパフォーマンスが向上します。 -- クエリ実行の最適化: 効率的なインデックスによりスキャンされる行数が削減され、クエリ速度と応答時​​間が向上します。 -- データベース管理を合理化します。インデックスが少なく、適切に最適化されているため、バックアップ、リカバリ、スキーマの変更が簡素化されます。 +- ストレージのオーバーヘッドを削減: 未使用のインデックスを削除すると、ディスク領域が解放され、長期的なストレージコストが削減されます。 +- 書き込みパフォーマンスの向上: 不要なインデックスメンテナンスが排除されると、書き込みが多いワークロード ( `INSERT` 、 `UPDATE` 、 `DELETE`など) のパフォーマンスが向上します。 +- クエリ実行の最適化: 効率的なインデックスによりスキャンされる行数が削減され、クエリ速度と応答時​​間が向上します。 +- データベース管理を合理化します。インデックスが少なく、適切に最適化されているため、バックアップ、リカバリ、スキーマの変更が簡素化されます。 インデックスはビジネスロジックの変化に伴って進化するため、定期的なインデックス監査はデータベースメンテナンスの標準的な手順です。TiDBには、インデックスを安全かつ効果的に検出、評価、最適化するための組み込みの観測ツールが用意されています。 @@ -30,16 +30,16 @@ TiDB v8.0.0 では、インデックスの使用パターンを追跡し、デ インデックスはクエリパフォーマンスに不可欠ですが、適切な分析を行わずに削除すると、予期せぬパフォーマンス低下やシステムの不安定化につながる可能性があります。安全かつ効果的なインデックス管理を実現するために、TiDBには以下の機能を備えた組み込みの観測ツールが用意されています。 -- インデックスの使用状況をリアルタイムで追跡します。インデックスがアクセスされる頻度と、それがパフォーマンスの向上に貢献しているかどうかを特定します。 -- 未使用のインデックスを検出します。データベースが最後に再起動されてから使用されていないインデックスを見つけます。 -- インデックスの効率を評価する: インデックスがデータを効果的にフィルター処理しているか、または過度の I/O オーバーヘッドを引き起こしているかを評価します。 -- インデックスの削除を安全にテストします。インデックスを削除する前に一時的にインデックスを不可視にして、そのインデックスに依存するクエリがないことを確認します。 +- インデックスの使用状況をリアルタイムで追跡します。インデックスがアクセスされる頻度と、それがパフォーマンスの向上に貢献しているかどうかを特定します。 +- 未使用のインデックスを検出します。データベースが最後に再起動されてから使用されていないインデックスを見つけます。 +- インデックスの効率を評価する: インデックスがデータを効果的にフィルター処理しているか、または過度の I/O オーバーヘッドを引き起こしているかを評価します。 +- インデックスの削除を安全にテストします。インデックスを削除する前に一時的にインデックスを不可視にして、そのインデックスに依存するクエリがないことを確認します。 TiDB は、次のツールを導入することでインデックスの最適化を簡素化します。 -- `INFORMATION_SCHEMA.TIDB_INDEX_USAGE` : インデックスの使用パターンとクエリ頻度を監視します。 -- `sys.schema_unused_indexes` : データベースが最後に再起動されてから使用されていないインデックスを一覧表示します。 -- 不可視インデックス: インデックスを完全に削除する前に、削除の影響をテストできます。 +- `INFORMATION_SCHEMA.TIDB_INDEX_USAGE` : インデックスの使用パターンとクエリ頻度を監視します。 +- `sys.schema_unused_indexes` : データベースが最後に再起動されてから使用されていないインデックスを一覧表示します。 +- 不可視インデックス: インデックスを完全に削除する前に、削除の影響をテストできます。 これらの観測ツールを使用することで、パフォーマンスの低下を招くことなく、冗長なインデックスを確実にクリーンアップできます。 @@ -49,9 +49,9 @@ TiDB は、次のツールを導入することでインデックスの最適化 具体的には、 `TIDB_INDEX_USAGE`システム テーブルを使用して次の操作を実行できます。 -- 未使用のインデックスの検出: クエリによってアクセスされていないインデックスを識別し、安全に削除できるインデックスを判断するのに役立ちます。 -- インデックスの効率を分析する: インデックスが使用される頻度と、効率的なクエリ実行に貢献しているかどうかを追跡します。 -- クエリ パターンを評価する: インデックスが読み取り操作、データ スキャン、キー値 (KV) 要求にどのように影響するかを理解します。 +- 未使用のインデックスの検出: クエリによってアクセスされていないインデックスを識別し、安全に削除できるインデックスを判断するのに役立ちます。 +- インデックスの効率を分析する: インデックスが使用される頻度と、効率的なクエリ実行に貢献しているかどうかを追跡します。 +- クエリ パターンを評価する: インデックスが読み取り操作、データ スキャン、キー値 (KV) 要求にどのように影響するかを理解します。 [TiDB v8.4.0](/releases/release-8.4.0.md)から始まる`TIDB_INDEX_USAGE`システム テーブルには、クラスター化されたテーブルの主キーも含まれており、インデックスのパフォーマンスをより詳細に把握できます。 @@ -92,15 +92,15 @@ DESC TIDB_INDEX_USAGE; このセクションでは、 `TIDB_INDEX_USAGE`システム テーブルを使用して、未使用のインデックスと非効率的なインデックスを識別する方法について説明します。 -- 未使用のインデックス: +- 未使用のインデックス: - - `QUERY_TOTAL = 0`の場合、インデックスはどのクエリでも使用されていません。 - - `LAST_ACCESS_TIME`かなり前のものを示している場合、インデックスはもはや関連がない可能性があります。 + - `QUERY_TOTAL = 0`の場合、インデックスはどのクエリでも使用されていません。 + - `LAST_ACCESS_TIME`かなり前のものを示している場合、インデックスはもはや関連がない可能性があります。 -- 非効率的なインデックス: +- 非効率的なインデックス: - - `PERCENTAGE_ACCESS_100`値が大きい場合は完全なインデックス スキャンが実行されることを意味し、インデックスが非効率的である可能性があります。 - - `ROWS_ACCESS_TOTAL`と`QUERY_TOTAL`比較して、インデックスが使用量に比べてスキャンする行数が多すぎるかどうかを判断します。 + - `PERCENTAGE_ACCESS_100`値が大きい場合は完全なインデックス スキャンが実行されることを意味し、インデックスが非効率的である可能性があります。 + - `ROWS_ACCESS_TOTAL`と`QUERY_TOTAL`比較して、インデックスが使用量に比べてスキャンする行数が多すぎるかどうかを判断します。 `TIDB_INDEX_USAGE`システム テーブルを使用すると、インデックスのパフォーマンスに関する詳細な情報を取得できるため、不要なインデックスを削除し、クエリ実行を最適化することが容易になります。 @@ -155,11 +155,11 @@ ORDER BY total_queries DESC; `CLUSTER_TIDB_INDEX_USAGE`システム テーブルは複数のノードからのデータを統合するため、次の点に注意してください。 -- データ更新の遅延 +- データ更新の遅延 パフォーマンスへの影響を最小限に抑えるため、 `CLUSTER_TIDB_INDEX_USAGE`即座に更新されません。インデックス使用状況の指標は最大 5 分ほど遅延する場合があります。クエリを分析する際は、このレイテンシーにご注意ください。 -- メモリベースのストレージ +- メモリベースのストレージ `TIDB_INDEX_USAGE`と同様に、このシステムテーブルはノードの再起動後にデータを保持しません。ノードがダウンした場合、記録されたインデックス使用状況データは失われます。 @@ -171,9 +171,9 @@ ORDER BY total_queries DESC; これにより、次の操作を簡単に実行できるようになります。 -- 使用されなくなったインデックスを識別し、不要なストレージコストを削減します。 -- `INSERT` 、 `UPDATE` 、 `DELETE`クエリにオーバーヘッドを追加するインデックスを削除することで、DML 操作を高速化します。 -- クエリ パターンを手動で分析する必要なく、インデックス監査を合理化します。 +- 使用されなくなったインデックスを識別し、不要なストレージコストを削減します。 +- `INSERT` 、 `UPDATE` 、 `DELETE`クエリにオーバーヘッドを追加するインデックスを削除することで、DML 操作を高速化します。 +- クエリ パターンを手動で分析する必要なく、インデックス監査を合理化します。 `schema_unused_indexes`を使用すると、不要なインデックスをすばやく識別し、最小限の労力でデータベースのオーバーヘッドを削減できます。 @@ -204,16 +204,16 @@ SELECT * FROM sys.schema_unused_indexes; #### インデックスは最後の再起動以降のみ未使用とみなされます {#indexes-are-considered-unused-only-since-the-last-restart} -- TiDB ノードが再起動すると、使用状況追跡データはリセットされます。 -- このデータに依存する前に、代表的なワークロードをキャプチャできるほど十分にシステムが実行中であることを確認してください。 +- TiDB ノードが再起動すると、使用状況追跡データはリセットされます。 +- このデータに依存する前に、代表的なワークロードをキャプチャできるほど十分にシステムが実行中であることを確認してください。 #### 未使用のインデックスをすべてすぐに削除できるわけではない {#not-all-unused-indexes-can-be-dropped-immediately} インデックスの中には、あまり使用されないものの、特定のクエリ、バッチジョブ、レポート作成タスクには不可欠なものもあります。インデックスを削除する前に、以下の機能をサポートしているかどうかを検討してください。 -- 稀だが重要なクエリ（例：月次レポート、分析） -- 毎日実行されないバッチ処理ジョブ -- アドホックトラブルシューティングクエリ +- 稀だが重要なクエリ（例：月次レポート、分析） +- 毎日実行されないバッチ処理ジョブ +- アドホックトラブルシューティングクエリ 重要だが頻度の低いクエリにインデックスが表示される場合は、まずインデックスを保持するか不可視にすることをお勧めします。 @@ -237,9 +237,9 @@ SELECT * FROM sys.schema_unused_indexes; 不可視インデックスの主な利点は次のとおりです。 -- **安全なインデックステスト**：クエリはインデックスを使用しなくなりますが、関連するオプティマイザ統計は引き続き維持されます。必要に応じていつでも簡単に復元できます。 -- **インデックスストレージへの影響はゼロ**: インデックスはそのまま残るため、コストのかかる再作成は不要です。 -- **パフォーマンス監視**: DBA は、最終決定を下す前に、インデックスなしでクエリの動作を観察できます。 +- **安全なインデックステスト**：クエリはインデックスを使用しなくなりますが、関連するオプティマイザ統計は引き続き維持されます。必要に応じていつでも簡単に復元できます。 +- **インデックスストレージへの影響はゼロ**: インデックスはそのまま残るため、コストのかかる再作成は不要です。 +- **パフォーマンス監視**: DBA は、最終決定を下す前に、インデックスなしでクエリの動作を観察できます。 ### インデックスを不可視にする {#make-an-index-invisible} @@ -251,20 +251,20 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; インデックスを不可視にした後、システムのクエリ パフォーマンスを観察します。 -- パフォーマンスに変化がない場合、インデックスは不要である可能性が高いため、安全に削除できます。 -- クエリのレイテンシーが増加すると、インデックスが依然として必要になる可能性があります。 +- パフォーマンスに変化がない場合、インデックスは不要である可能性が高いため、安全に削除できます。 +- クエリのレイテンシーが増加すると、インデックスが依然として必要になる可能性があります。 ### 不可視インデックスを効果的に使用する {#use-invisible-indexes-effectively} -- **オフピーク時にテストする**: 制御された環境でパフォーマンスへの影響を監視します。 -- **クエリ監視ツールを使用する**: インデックスを不可視にする前と後のクエリ実行計画を分析します。 -- **複数のワークロードで確認します**。特定のレポートやスケジュールされたクエリにインデックスが必要ないことを確認します。 +- **オフピーク時にテストする**: 制御された環境でパフォーマンスへの影響を監視します。 +- **クエリ監視ツールを使用する**: インデックスを不可視にする前と後のクエリ実行計画を分析します。 +- **複数のワークロードで確認します**。特定のレポートやスケジュールされたクエリにインデックスが必要ないことを確認します。 ### インデックスを不可視のままにできる期間はどのくらいですか? {#how-long-can-an-index-remain-invisible} -- OLTP ワークロード: 毎日の変動を考慮するために少なくとも 1 週間監視します。 -- バッチ処理または ETL ワークロード: 月次財務レポートなどの 1 つの完全なレポート サイクルを許可します。 -- アドホック分析クエリ: クエリ ログを使用して、インデックスを削除する前にインデックスが必要ないことを確認します。 +- OLTP ワークロード: 毎日の変動を考慮するために少なくとも 1 週間監視します。 +- バッチ処理または ETL ワークロード: 月次財務レポートなどの 1 つの完全なレポート サイクルを許可します。 +- アドホック分析クエリ: クエリ ログを使用して、インデックスを削除する前にインデックスが必要ないことを確認します。 安全のため、最終決定を下す前にすべてのワークロードがテストされていることを確認するために、少なくとも 1 つのビジネス サイクル全体にわたってインデックスを不可視にしておきます。 @@ -272,23 +272,23 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; 高いパフォーマンスと効率的なリソース利用を維持するために、定期的なインデックス最適化はデータベースメンテナンスの一部です。TiDBでインデックスを効果的に管理するためのベストプラクティスを以下に示します。 -1. **インデックスの使用状況を定期的に監視します。** +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)を使用します。 - - [`schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md)を使用して未使用のインデックスを識別し、削除できるかどうかを評価します。 - - クエリ実行計画を監視して、過剰な I/O を引き起こす可能性のある非効率的なインデックスを検出します。 + - インデックスの使用アクティビティを追跡するには、 [`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. **インデックスを削除する前に検証します。** +2. **インデックスを削除する前に検証します。** - - [`ALTER TABLE ... INVISIBLE`](/sql-statements/sql-statement-alter-table.md)を使用してインデックスを不可視にし、一時的にインデックスを無効にして、完全に削除する前にその影響を確認します。 - - クエリのパフォーマンスが安定している場合は、インデックスの削除に進みます。 - - 最終決定を下す前に、すべてのクエリ パターンを考慮するのに十分な観察期間を確保してください。 + - [`ALTER TABLE ... INVISIBLE`](/sql-statements/sql-statement-alter-table.md)を使用してインデックスを不可視にし、一時的にインデックスを無効にして、完全に削除する前にその影響を確認します。 + - クエリのパフォーマンスが安定している場合は、インデックスの削除に進みます。 + - 最終決定を下す前に、すべてのクエリ パターンを考慮するのに十分な観察期間を確保してください。 -3. **既存のインデックスを最適化します。** +3. **既存のインデックスを最適化します。** - - 冗長なインデックスを統合することで、ストレージのオーバーヘッドを削減し、書き込みパフォーマンスを向上させることができます。複数のインデックスが類似したクエリを処理している場合は、それらを単一の、より効率的なインデックスに統合することを検討してください。 + - 冗長なインデックスを統合することで、ストレージのオーバーヘッドを削減し、書き込みパフォーマンスを向上させることができます。複数のインデックスが類似したクエリを処理している場合は、それらを単一の、より効率的なインデックスに統合することを検討してください。 - - 重複するプレフィックスを持つインデックス (冗長性を示している可能性があります) を検索するには、次の SQL ステートメントを実行します。 + - 重複するプレフィックスを持つインデックス (冗長性を示している可能性があります) を検索するには、次の SQL ステートメントを実行します。 ```sql SELECT TABLE_SCHEMA, TABLE_NAME, INDEX_NAME, COLUMN_NAME, SEQ_IN_INDEX @@ -297,24 +297,24 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; ORDER BY TABLE_SCHEMA, TABLE_NAME, COLUMN_NAME, SEQ_IN_INDEX; ``` - - 2 つのインデックスの先頭列が同じ場合は、代わりにそれらを複合インデックスにマージすることを検討してください。 + - 2 つのインデックスの先頭列が同じ場合は、代わりにそれらを複合インデックスにマージすることを検討してください。 - - 選択性の向上。選択性の低いインデックス（フィルタリングする行が多すぎるインデックス）は、次のように最適化できます。 + - 選択性の向上。選択性の低いインデックス（フィルタリングする行が多すぎるインデックス）は、次のように最適化できます。 - - フィルタリングの効率を向上させるために列を追加します。 - - インデックス構造の変更 (プレフィックス インデックス、複合インデックスなど)。 + - フィルタリングの効率を向上させるために列を追加します。 + - インデックス構造の変更 (プレフィックス インデックス、複合インデックスなど)。 - - インデックスの選択性を分析します。`TIDB_INDEX_USAGE`フィールドのうち`PERCENTAGE_ACCESS_*`を使用して、インデックスがデータをどの程度適切にフィルタリングしているかを評価します。 + - インデックスの選択性を分析します。`TIDB_INDEX_USAGE`フィールドのうち`PERCENTAGE_ACCESS_*`を使用して、インデックスがデータをどの程度適切にフィルタリングしているかを評価します。 -4. **DML パフォーマンスへの影響に注意してください。** +4. **DML パフォーマンスへの影響に注意してください。** - - 過剰なインデックス作成は避けてください。インデックスを追加するごとに`UPDATE` `INSERT` `DELETE`のオーバーヘッドが増加します。 - - 書き込みが多いワークロードのメンテナンス コストを最小限に抑えるために、クエリに必要なものだけをインデックスします。 + - 過剰なインデックス作成は避けてください。インデックスを追加するごとに`UPDATE` `INSERT` `DELETE`のオーバーヘッドが増加します。 + - 書き込みが多いワークロードのメンテナンス コストを最小限に抑えるために、クエリに必要なものだけをインデックスします。 -5. **定期的にテストと調整を行ってください。** +5. **定期的にテストと調整を行ってください。** - - 特にワークロードに大きな変更があった場合には、インデックス監査を定期的に実行します。 - - TiDB の実行計画分析ツールを使用して、インデックスが最適に使用されているかどうかを確認します。 - - 新しいインデックスを追加するときは、予期しない回帰を防ぐために、まず分離された環境でテストしてください。 + - 特にワークロードに大きな変更があった場合には、インデックス監査を定期的に実行します。 + - TiDB の実行計画分析ツールを使用して、インデックスが最適に使用されているかどうかを確認します。 + - 新しいインデックスを追加するときは、予期しない回帰を防ぐために、まず分離された環境でテストしてください。 これらのベスト プラクティスに従うことで、効率的なクエリ実行を実現し、不要なストレージオーバーヘッドを削減し、最適なデータベース パフォーマンスを維持できます。 diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md index a864a884869e2..fb8e2652ed8f0 100644 --- a/best-practices/massive-regions-best-practices.md +++ b/best-practices/massive-regions-best-practices.md @@ -30,20 +30,20 @@ Raftstore のワークフロー図から、各リージョンのメッセージ > **Note:** > -> - 前述のRaftstoreのCPU使用率についてですが、 Raftstoreはシングルスレッドです。Raftstoreがマルチスレッドの場合は、CPU使用率のしきい値（85%）を比例的に増やすことができます。 -> - Raftstoreスレッドには I/O 操作が存在するため、CPU 使用率は 100% に達することはありません。 +> - 前述のRaftstoreのCPU使用率についてですが、 Raftstoreはシングルスレッドです。Raftstoreがマルチスレッドの場合は、CPU使用率のしきい値（85%）を比例的に増やすことができます。 +> - Raftstoreスレッドには I/O 操作が存在するため、CPU 使用率は 100% に達することはありません。 ### パフォーマンス監視 {#performance-monitoring} Grafana の**TiKV ダッシュボード**では、次の監視メトリックを確認できます。 -- **スレッドCPU**パネルの`Raft store CPU` +- **スレッドCPU**パネルの`Raft store CPU` 基準値： `raftstore.store-pool-size * 85%`未満。 ![Check Raftstore CPU](/media/best-practices/raft-store-cpu.png) -- **Raft Propose**パネルの`Propose wait duration` +- **Raft Propose**パネルの`Propose wait duration` `Propose wait duration`は、リクエストがRaftstoreに送信されてからRaftstore が実際にリクエストの処理を開始するまでの遅延です。遅延が長い場合は、 Raftstoreがビジー状態であるか、ログ追加処理に時間がかかり、 Raftstore がリクエストを時間内に処理できないことを意味します。 @@ -51,13 +51,13 @@ Grafana の**TiKV ダッシュボード**では、次の監視メトリックを ![Check Propose wait duration](/media/best-practices/propose-wait-duration.png) -- **Raft IO**パネルの`Commit log duration` +- **Raft IO**パネルの`Commit log duration` `Commit log duration`は、 Raftstore が各リージョン内の大多数のメンバーにRaftログをコミットするのにかかる時間です。この指標の値が大きく変動する理由としては、以下が考えられます。 - - Raftstoreの作業負荷は大きいです。 - - ログ追加操作が遅いです。 - - ネットワークの混雑により、 Raftログをタイムリーにコミットできません。 + - Raftstoreの作業負荷は大きいです。 + - ログ追加操作が遅いです。 + - ネットワークの混雑により、 Raftログをタイムリーにコミットできません。 基準値: 200～500ms未満。 @@ -67,8 +67,8 @@ Grafana の**TiKV ダッシュボード**では、次の監視メトリックを パフォーマンスの問題の原因を突き止めたら、次の 2 つの側面から解決を試みてください。 -- 単一の TiKV インスタンス上のリージョン数を減らす -- 単一リージョンのメッセージ数を減らす +- 単一の TiKV インスタンス上のリージョン数を減らす +- 単一リージョンのメッセージ数を減らす ### 方法1: Raftstoreの同時実行性を高める {#method-1-increase-raftstore-concurrency} @@ -100,9 +100,9 @@ config set merge-schedule-limit 8 詳細については、 [リージョン結合](https://tikv.org/docs/4.0/tasks/configure/region-merge/)および[PD設定ファイル](/pd-configuration-file.md#schedule)の次の 3 つの構成パラメータを参照してください。 -- [`max-merge-region-size`](/pd-configuration-file.md#max-merge-region-size) -- [`max-merge-region-keys`](/pd-configuration-file.md#max-merge-region-keys) -- [`merge-schedule-limit`](/pd-configuration-file.md#merge-schedule-limit) +- [`max-merge-region-size`](/pd-configuration-file.md#max-merge-region-size) +- [`max-merge-region-keys`](/pd-configuration-file.md#max-merge-region-keys) +- [`merge-schedule-limit`](/pd-configuration-file.md#merge-schedule-limit) `Region Merge`パラメータのデフォルト設定はかなり保守的です。[PDスケジュールのベストプラクティス](/best-practices/pd-scheduling-best-practices.md#region-merge-is-slow)に記載されている方法を参考にすれば、 `Region Merge`プロセスを高速化できます。 diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md index 77229547f3558..789b823c92fb6 100644 --- a/best-practices/multi-column-index-best-practices.md +++ b/best-practices/multi-column-index-best-practices.md @@ -16,8 +16,8 @@ aliases: ['/ja/tidb/stable/multi-column-index-best-practices/'] ## 前提条件 {#prerequisites} -- マルチ列インデックス機能は、TiDB v8.3 以降のバージョンで使用できます。 -- この機能を使用する前に、 [オプティマイザー修正制御**54337**](/optimizer-fix-controls.md#54337-new-in-v830)の値を`ON`に設定する必要があります。 +- マルチ列インデックス機能は、TiDB v8.3 以降のバージョンで使用できます。 +- この機能を使用する前に、 [オプティマイザー修正制御**54337**](/optimizer-fix-controls.md#54337-new-in-v830)の値を`ON`に設定する必要があります。 ## 背景: 複数列インデックス {#background-multi-column-indexes} @@ -60,9 +60,9 @@ CREATE INDEX idx_city_bedrooms_price ON listings (city, bedrooms, price); SQLの複数列インデックスは辞書式順序で並べられます。`(city, bedrooms, price)`インデックスの場合、データはまず`city`でソートされ、次に各都市内で`bedrooms`でソートされ、最後に各`(city, bedrooms)`組み合わせ内で`price`でソートされます。この順序付けにより、TiDBは各条件に基づいて効率的に行にアクセスできます。 -1. プライマリフィルターである`city`でフィルターします。 -2. オプションで、その都市内で`bedrooms`でフィルタリングします。 -3. オプションで、都市-ベッドルーム グループ内で`price`でフィルタリングします。 +1. プライマリフィルターである`city`でフィルターします。 +2. オプションで、その都市内で`bedrooms`でフィルタリングします。 +3. オプションで、都市-ベッドルーム グループ内で`price`でフィルタリングします。 ## サンプルデータ {#sample-data} @@ -135,8 +135,8 @@ TiDBオプティマイザには、強力な範囲導出コンポーネントが ニューヨークで、価格が 2 つの重複する範囲のいずれかに該当する 2 ベッドルームの物件を検索するクエリを考えてみましょう。 -- 価格は`$1,000` ～ `$2,000` -- 価格は`$1,500` ～ `$2,500` +- 価格は`$1,000` ～ `$2,000` +- 価格は`$1,500` ～ `$2,500` この場合、2つの範囲が重複しているため、オプティマイザはそれらを`$1,000`から`$2,500`の単一の範囲に結合します。クエリとその実行計画は次のとおりです。 @@ -162,8 +162,8 @@ EXPLAIN FORMAT = "brief" 別のシナリオとして、サンフランシスコまたはサンディエゴで手頃な価格のシングルベッドルーム物件を検索するクエリを想像してみてください。ここでは、条件`OR`異なる都市の2つの異なる範囲を指定しています。 -- サンフランシスコの物件、1ベッドルーム、価格`$1,500` ～ `$2,500` -- サンディエゴの物件、1ベッドルーム、価格`$1,000` ～ `$1,500` +- サンフランシスコの物件、1ベッドルーム、価格`$1,500` ～ `$2,500` +- サンディエゴの物件、1ベッドルーム、価格`$1,000` ～ `$1,500` インデックス範囲は重複しないため、実行計画では個別のままとなり、各都市には独自のインデックス範囲が設定されます。 @@ -214,12 +214,12 @@ CREATE TABLE t1 ( このクエリでは複数の列を比較するため、TiDB オプティマイザーは次の 2 つの手順で処理する必要があります。 -1. 表現を翻訳します。 +1. 表現を翻訳します。 TiDB オプティマイザーは、これらの複雑な条件をより単純な部分に分解します。 - - `(a1, b1) > (1, 10)`は`(a1 > 1) OR (a1 = 1 AND b1 > 10)`に変換されます。つまり、 `a1` `1`より大きい場合、または`a1`がちょうど`1`で`b1`が`10`より大きい場合がすべて含まれます。 - - `(a1, b1) < (10, 20)`は`(a1 < 10) OR (a1 = 10 AND b1 < 20)`に変換され、 `a1` `10`より小さい場合や、 `a1`がちょうど`10`で`b1`が`20`より小さい場合をカバーします。 + - `(a1, b1) > (1, 10)`は`(a1 > 1) OR (a1 = 1 AND b1 > 10)`に変換されます。つまり、 `a1` `1`より大きい場合、または`a1`がちょうど`1`で`b1`が`10`より大きい場合がすべて含まれます。 + - `(a1, b1) < (10, 20)`は`(a1 < 10) OR (a1 = 10 AND b1 < 20)`に変換され、 `a1` `10`より小さい場合や、 `a1`がちょうど`10`で`b1`が`20`より小さい場合をカバーします。 これらの式は`AND`を使用して結合されます。 @@ -227,12 +227,12 @@ CREATE TABLE t1 ( ((a1 > 1) OR (a1 = 1 AND b1 > 10)) AND ((a1 < 10) OR (a1 = 10 AND b1 < 20)) ``` -2. 範囲を導出して結合します。 +2. 範囲を導出して結合します。 TiDBオプティマイザは条件を分解した後、各部分の範囲を計算し、それらを結合します。この例では、次のように導出されます。 - - `(a1, b1) > (1, 10)`の場合: `a1 > 1`の場合は範囲`(1, +inf]`を作成し、 `a1 = 1`および`b1 > 10`の場合は`(1, 10, 1, +inf]`を作成します。 - - `(a1, b1) < (10, 20)`の場合: `a1 < 10`の場合は範囲`[-inf, 10)`を作成し、 `a1 = 10`と`b1 < 20`の場合は範囲`[10, -inf, 10, 20)`を作成します。 + - `(a1, b1) > (1, 10)`の場合: `a1 > 1`の場合は範囲`(1, +inf]`を作成し、 `a1 = 1`および`b1 > 10`の場合は`(1, 10, 1, +inf]`を作成します。 + - `(a1, b1) < (10, 20)`の場合: `a1 < 10`の場合は範囲`[-inf, 10)`を作成し、 `a1 = 10`と`b1 < 20`の場合は範囲`[10, -inf, 10, 20)`を作成します。 最終結果では、これらを組み合わせて、洗練された範囲`(1, 10, 1, +inf] UNION (1, 10) UNION [10, -inf, 10, 20)`得られます。 diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 3a5fef18ac756..7026b92a79abc 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -8,14 +8,14 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ このドキュメントでは、PDスケジューリングの原則と戦略を、一般的なシナリオを通して詳細に解説し、アプリケーション開発の効率化を図ります。このドキュメントは、TiDB、TiKV、PDの基本的な知識と、以下のコア概念を理解していることを前提としています。 -- [リーダー/フォロワー/ラーナー](/glossary.md#leaderfollowerlearner) -- [オペレーター](/glossary.md#operator) -- [演算子ステップ](/glossary.md#operator-step) -- [保留中/ダウン](/glossary.md#pendingdown) -- [リージョン/ピア/Raftグループ](/glossary.md#regionpeerraft-group) -- [リージョン分割](/glossary.md#region-split) -- [スケジューラ](/glossary.md#scheduler) -- [ストア](/glossary.md#store) +- [リーダー/フォロワー/ラーナー](/glossary.md#leaderfollowerlearner) +- [オペレーター](/glossary.md#operator) +- [演算子ステップ](/glossary.md#operator-step) +- [保留中/ダウン](/glossary.md#pendingdown) +- [リージョン/ピア/Raftグループ](/glossary.md#regionpeerraft-group) +- [リージョン分割](/glossary.md#region-split) +- [スケジューラ](/glossary.md#scheduler) +- [ストア](/glossary.md#store) > **Note:** > @@ -29,35 +29,35 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ スケジュール設定プロセスには通常、次の 3 つのステップがあります。 -1. 情報を収集する +1. 情報を収集する 各 TiKV ノードは、次の 2 種類のハートビートを定期的に PD に報告します。 - - `StoreHeartbeat` : ディスク容量、使用可能なストレージ、読み取り/書き込みトラフィックなど、ストアの全体的な情報が含まれます。 - - `RegionHeartbeat` : 各リージョンの範囲、ピア分布、ピアステータス、データ量、読み取り/書き込みトラフィックなど、リージョンの全体的な情報が含まれます。 + - `StoreHeartbeat` : ディスク容量、使用可能なストレージ、読み取り/書き込みトラフィックなど、ストアの全体的な情報が含まれます。 + - `RegionHeartbeat` : 各リージョンの範囲、ピア分布、ピアステータス、データ量、読み取り/書き込みトラフィックなど、リージョンの全体的な情報が含まれます。 PD はスケジュール決定のためにこの情報を収集し、復元します。 -2. 演算子を生成する +2. 演算子を生成する さまざまなスケジューラが、次の点を考慮して、独自のロジックと要件に基づいてオペレーターを生成します。 - - 異常な状態（切断、ダウン、ビジー、容量不足）にあるピアをストアに追加しないでください。 - - 異常な状態のリージョンのバランスをとらない - - リーダーを保留中のピアに転送しないでください - - リーダーを直接削除しないでください - - さまざまなリージョンピアの物理的な分離を破壊しない - - ラベルプロパティなどの制約に違反しない + - 異常な状態（切断、ダウン、ビジー、容量不足）にあるピアをストアに追加しないでください。 + - 異常な状態のリージョンのバランスをとらない + - リーダーを保留中のピアに転送しないでください + - リーダーを直接削除しないでください + - さまざまなリージョンピアの物理的な分離を破壊しない + - ラベルプロパティなどの制約に違反しない -3. 実行演算子 +3. 実行演算子 演算子を実行するための一般的な手順は次のとおりです。 - 1. 生成された演算子は、まず`OperatorController`によって管理されるキューに参加します。 + 1. 生成された演算子は、まず`OperatorController`によって管理されるキューに参加します。 - 2. `OperatorController`キューからオペレータを取り出し、設定に基づいて一定の同時実行数で実行します。このステップでは、各オペレータステップを対応するリージョンリーダーに割り当てます。 + 2. `OperatorController`キューからオペレータを取り出し、設定に基づいて一定の同時実行数で実行します。このステップでは、各オペレータステップを対応するリージョンリーダーに割り当てます。 - 3. オペレータは「終了」または「タイムアウト」としてマークされ、キューから削除されます。 + 3. オペレータは「終了」または「タイムアウト」としてマークされ、キューから削除されます。 ### 負荷分散 {#load-balancing} @@ -65,14 +65,14 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ `balance-leader`と`balance-region`は同様のスケジュール プロセスを共有します。 -1. リソースの可用性に応じてストアを評価します。 -2. `balance-leader`または`balance-region` 、高スコアのストアから低スコアのストアへ、リーダーまたはピアを継続的に異動させます。 +1. リソースの可用性に応じてストアを評価します。 +2. `balance-leader`または`balance-region` 、高スコアのストアから低スコアのストアへ、リーダーまたはピアを継続的に異動させます。 しかし、評価方法は異なります。`balance-leader`はストア内のリーダーに対応するすべてのリージョンサイズの合計を使用しますが、 `balance-region`の方法は比較的複雑です。各ノードの具体的なストレージ容量に応じて、 `balance-region`の評価方法は以下のようになります。 -- 十分なストレージがある場合のデータ量に基づいて（ノード間でデータ分散のバランスをとるため）。 -- ストレージが不足している場合は、使用可能なストレージに基づいて割り当てます (異なるノード上のストレージの可用性のバランスをとるため)。 -- どちらの状況も当てはまらない場合は、上記の 2 つの要素の加重合計に基づきます。 +- 十分なストレージがある場合のデータ量に基づいて（ノード間でデータ分散のバランスをとるため）。 +- ストレージが不足している場合は、使用可能なストレージに基づいて割り当てます (異なるノード上のストレージの可用性のバランスをとるため)。 +- どちらの状況も当てはまらない場合は、上記の 2 つの要素の加重合計に基づきます。 ノードによってパフォーマンスが異なる場合があるため、ストアごとにロードバランシングの重みを設定することもできます。`leader-weight`と`region-weight`は、それぞれリーダー重みとリージョン重みを制御します（どちらもデフォルトは「1」です）。例えば、あるストアの`leader-weight`を「2」に設定すると、スケジューリングが安定した後、そのノードのリーダー数は他のノードの約2倍になります。同様に、あるストアの`leader-weight`を「0.5」に設定すると、そのノードのリーダー数は他のノードの約半分になります。 @@ -80,9 +80,9 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ ホットリージョンのスケジューリングには`hot-region-scheduler`を使用します。TiDB v3.0以降では、このプロセスは次のように実行されます。 -1. ストアから報告された情報に基づいて、一定期間内に特定のしきい値を超える読み取り/書き込みトラフィックを判別し、ホットリージョンをカウントします。 +1. ストアから報告された情報に基づいて、一定期間内に特定のしきい値を超える読み取り/書き込みトラフィックを判別し、ホットリージョンをカウントします。 -2. 負荷分散と同様の方法でこれらのリージョンを再分配します。 +2. 負荷分散と同様の方法でこれらのリージョンを再分配します。 ホット書き込みリージョンの場合、 `hot-region-scheduler`リージョンピアとリーダーの両方の再配布を試行します。ホット読み取りリージョンの場合、 `hot-region-scheduler`リージョンリーダーのみを再配布します。 @@ -104,9 +104,9 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ 具体的には、新しく分割されたリージョンが[`split-merge-interval`](/pd-configuration-file.md#split-merge-interval) (デフォルトでは`1h` ) を超える値で存在する場合、次の条件が同時に発生すると、このリージョンはリージョンのマージ スケジュールをトリガーします。 -- このリージョンのサイズは[`max-merge-region-size`](/pd-configuration-file.md#max-merge-region-size)の値より小さいです。v8.4.0 以降、デフォルト値は 20 MiB から 54 MiB に変更されます。新しいデフォルト値は、新規に作成されたクラスターにのみ自動的に適用されます。既存のクラスターには影響しません。 +- このリージョンのサイズは[`max-merge-region-size`](/pd-configuration-file.md#max-merge-region-size)の値より小さいです。v8.4.0 以降、デフォルト値は 20 MiB から 54 MiB に変更されます。新しいデフォルト値は、新規に作成されたクラスターにのみ自動的に適用されます。既存のクラスターには影響しません。 -- このリージョンのキーの数が[`max-merge-region-keys`](/pd-configuration-file.md#max-merge-region-keys)より小さいです。v8.4.0 以降、デフォルト値は 200000 から 540000 に変更されます。新しいデフォルト値は、新規に作成されたクラスターにのみ自動的に適用されます。既存のクラスターには影響しません。 +- このリージョンのキーの数が[`max-merge-region-keys`](/pd-configuration-file.md#max-merge-region-keys)より小さいです。v8.4.0 以降、デフォルト値は 200000 から 540000 に変更されます。新しいデフォルト値は、新規に作成されたクラスターにのみ自動的に適用されます。既存のクラスターには影響しません。 ## クエリのスケジュールステータス {#query-scheduling-status} @@ -116,22 +116,22 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ **Grafana PD/Operator**ページには、次のようなオペレーターに関するメトリックが表示されます。 -- スケジュールオペレータ作成:オペレータ作成情報 -- オペレータ完了時間: 各オペレータが消費した実行時間 -- オペレータステップの実行時間: オペレータステップで消費される実行時間 +- スケジュールオペレータ作成:オペレータ作成情報 +- オペレータ完了時間: 各オペレータが消費した実行時間 +- オペレータステップの実行時間: オペレータステップで消費される実行時間 次のコマンドで pd-ctl を使用して演算子を照会できます。 -- `operator show` : 現在のスケジュールタスクで生成されたすべての演算子を照会します -- `operator show [admin | leader | region]` : 演算子をタイプ別に照会する +- `operator show` : 現在のスケジュールタスクで生成されたすべての演算子を照会します +- `operator show [admin | leader | region]` : 演算子をタイプ別に照会する ### 残高ステータス {#balance-status} **Grafana PD/統計- バランス**ページには、次のような負荷分散に関するメトリックが表示されます。 -- ストアリーダー/リージョンスコア: 各ストアのスコア -- ストアリーダー/リージョン数: 各ストアのリーダー/リージョンの数 -- 利用可能なストア: 各ストアで利用可能なストレージ +- ストアリーダー/リージョンスコア: 各ストアのスコア +- ストアリーダー/リージョン数: 各ストアのリーダー/リージョンの数 +- 利用可能なストア: 各ストアで利用可能なストレージ pd-ctl のストア コマンドを使用して、各ストアの残高ステータスを照会できます。 @@ -139,16 +139,16 @@ pd-ctl のストア コマンドを使用して、各ストアの残高ステー **Grafana PD/統計- ホットスポット**ページには、次のようなホット リージョンに関するメトリックが表示されます。 -- ホットライトリージョンのリーダー/ピア分布: ホットライトリージョンにおけるリーダー/ピア分布 -- ホット読み取りリージョンのリーダー分布: ホット読み取りリージョンにおけるリーダー分布 +- ホットライトリージョンのリーダー/ピア分布: ホットライトリージョンにおけるリーダー/ピア分布 +- ホット読み取りリージョンのリーダー分布: ホット読み取りリージョンにおけるリーダー分布 次のコマンドで pd-ctl を使用してホット リージョンのステータスを照会することもできます。 -- `hot read` : ホット読み取りリージョンを照会する -- `hot write` : ホット書き込みリージョンを照会する -- `hot store` : ストア別にホットリージョンの分布を照会する -- `region topread [limit]` : 読み取りトラフィックが最も多いリージョンを照会します -- `region topwrite [limit]` : 書き込みトラフィックが最も多いリージョンを照会します +- `hot read` : ホット読み取りリージョンを照会する +- `hot write` : ホット書き込みリージョンを照会する +- `hot store` : ストア別にホットリージョンの分布を照会する +- `region topread [limit]` : 読み取りトラフィックが最も多いリージョンを照会します +- `region topwrite [limit]` : 書き込みトラフィックが最も多いリージョンを照会します ### リージョンの健康 {#region-health} @@ -156,10 +156,10 @@ pd-ctl のストア コマンドを使用して、各ストアの残高ステー リージョンチェック コマンドを使用して pd-ctl を使用すると、異常状態にあるリージョンのリストを照会できます。 -- `region check miss-peer` : 十分なピアがないリージョンを照会する -- `region check extra-peer` : 追加のピアを持つリージョンを照会します -- `region check down-peer` : ダウンしているピアがあるリージョンを照会する -- `region check pending-peer` : 保留中のピアがあるリージョンを照会します +- `region check miss-peer` : 十分なピアがないリージョンを照会する +- `region check extra-peer` : 追加のピアを持つリージョンを照会します +- `region check down-peer` : ダウンしているピアがあるリージョンを照会する +- `region check pending-peer` : 保留中のピアがあるリージョンを照会します ## 制御スケジューリング戦略 {#control-scheduling-strategy} @@ -169,28 +169,28 @@ pd-ctl を使用すると、以下の3つの側面からスケジューリング PDはpd-ctlを介してスケジューラを動的に追加および削除することをサポートしています。例： -- `scheduler show` : システムで現在実行中のスケジューラを表示します -- `scheduler remove balance-leader-scheduler` : バランスリーダースケジューラを削除（無効化）する -- `scheduler add evict-leader-scheduler 1` : ストア 1 のすべてのリーダーを削除するスケジューラを追加します。 +- `scheduler show` : システムで現在実行中のスケジューラを表示します +- `scheduler remove balance-leader-scheduler` : バランスリーダースケジューラを削除（無効化）する +- `scheduler add evict-leader-scheduler 1` : ストア 1 のすべてのリーダーを削除するスケジューラを追加します。 ### オペレータを手動で追加/削除する {#adddelete-operators-manually} PDはpd-ctlを介してオペレータを直接追加または削除することもできます。例えば： -- `operator add add-peer 2 5` : ストア5のリージョン2にピアを追加する -- `operator add transfer-leader 2 5` :リージョン2のリーダーをストア5に移行します -- `operator add split-region 2` :リージョン2を均等なサイズで2つのリージョンに分割します -- `operator remove 2` :リージョン2で現在保留中の演算子を削除します +- `operator add add-peer 2 5` : ストア5のリージョン2にピアを追加する +- `operator add transfer-leader 2 5` :リージョン2のリーダーをストア5に移行します +- `operator add split-region 2` :リージョン2を均等なサイズで2つのリージョンに分割します +- `operator remove 2` :リージョン2で現在保留中の演算子を削除します ### スケジュールパラメータを調整する {#adjust-scheduling-parameter} pd-ctl の`config show`コマンドを使用してスケジュール設定を確認し、 `config set {key} {value}`を使用して値を調整できます。一般的な調整には以下が含まれます。 -- `leader-schedule-limit` : 転送リーダーのスケジュールの同時実行を制御する -- `region-schedule-limit` : ピアスケジュールの追加/削除の同時実行を制御する -- `enable-replace-offline-replica` : ノードをオフラインにするスケジュールを有効にするかどうかを決定します -- `enable-location-replacement` : リージョンの分離レベルを処理するスケジュールを有効にするかどうかを決定します -- `max-snapshot-count` : 各ストアのスナップショットの送受信の最大同時実行数を制御します +- `leader-schedule-limit` : 転送リーダーのスケジュールの同時実行を制御する +- `region-schedule-limit` : ピアスケジュールの追加/削除の同時実行を制御する +- `enable-replace-offline-replica` : ノードをオフラインにするスケジュールを有効にするかどうかを決定します +- `enable-location-replacement` : リージョンの分離レベルを処理するスケジュールを有効にするかどうかを決定します +- `max-snapshot-count` : 各ストアのスナップショットの送受信の最大同時実行数を制御します ## 一般的なシナリオにおけるPDスケジューリング {#pd-scheduling-in-common-scenarios} @@ -204,24 +204,24 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー 各ストアのスコアが近い場合、PDはリーダー／リージョンが均等に分布していると誤って認識していることを意味します。考えられる理由は以下の通りです。 -- 負荷の不均衡を引き起こすホットリージョンがあります。この場合、 [ホットリージョンのスケジュール](#hot-regions-are-not-evenly-distributed)に基づいてさらに分析する必要があります。 -- 空きリージョンや小さなリージョンが多数存在するため、ストア間でリーダーの数に大きな差が生じ、 Raftストアへの負荷が高くなります。このような状況では、 [リージョンの統合](#region-merge-is-slow)スケジューリングが適しています。 -- ハードウェアおよびソフトウェア環境はストアによって異なります。リーダー/リージョンの配分を制御するには、 [負荷分散](#load-balancing)参考にして`leader-weight`と`region-weight`の値を調整してください。 -- その他の不明な理由。ただし、 `leader-weight`と`region-weight`の値を調整することで、リーダー/リージョンの配分を制御することができます。 +- 負荷の不均衡を引き起こすホットリージョンがあります。この場合、 [ホットリージョンのスケジュール](#hot-regions-are-not-evenly-distributed)に基づいてさらに分析する必要があります。 +- 空きリージョンや小さなリージョンが多数存在するため、ストア間でリーダーの数に大きな差が生じ、 Raftストアへの負荷が高くなります。このような状況では、 [リージョンの統合](#region-merge-is-slow)スケジューリングが適しています。 +- ハードウェアおよびソフトウェア環境はストアによって異なります。リーダー/リージョンの配分を制御するには、 [負荷分散](#load-balancing)参考にして`leader-weight`と`region-weight`の値を調整してください。 +- その他の不明な理由。ただし、 `leader-weight`と`region-weight`の値を調整することで、リーダー/リージョンの配分を制御することができます。 異なるストア間で評価に大きな差がある場合は、オペレータ関連の指標、特にオペレータの生成と実行に焦点を当てて調査する必要があります。主な状況としては、以下の2つが挙げられます。 -- オペレータが正常に生成されていても、スケジュール処理が遅い場合は、次のことが考えられます。 +- オペレータが正常に生成されていても、スケジュール処理が遅い場合は、次のことが考えられます。 - - スケジューリング速度は、負荷分散を目的としてデフォルトで制限されています。`leader-schedule-limit`または`region-schedule-limit`を大きくしても、通常のサービスに大きな影響はありません。また、 `max-pending-peer-count`および`max-snapshot-count`で指定された制限を適切に緩和することもできます。 - - 他のスケジューリングタスクが同時に実行されているため、バランシングの速度が低下しています。この場合、バランシングが他のスケジューリングタスクよりも優先される可能性がある場合は、他のタスクを停止するか、速度を制限することができます。例えば、バランシングの実行中に一部のノードをオフラインにすると、両方の操作でクォータ`region-schedule-limit`が消費されます。このような場合、スケジューラの速度を制限してノードを削除するか、 `enable-replace-offline-replica = false`設定して一時的に無効にすることができます。 - - スケジューリングプロセスが遅すぎます。原因を確認するには`RemovePeer` **Operator ステップの所要時間**メトリックを確認してください。通常、スナップショットの送受信を伴わないステップ（ `TransferLeader` `PromoteLearner` ）は数ミリ秒で完了するはずですが、スナップショットを伴うステップ（ `AddLearner` `AddPeer` ）は数十秒で完了すると予想されます。所要時間が明らかに長すぎる場合は、TiKV の負荷が高いか、ネットワークのボトルネックが発生している可能性があります。具体的な分析が必要です。 + - スケジューリング速度は、負荷分散を目的としてデフォルトで制限されています。`leader-schedule-limit`または`region-schedule-limit`を大きくしても、通常のサービスに大きな影響はありません。また、 `max-pending-peer-count`および`max-snapshot-count`で指定された制限を適切に緩和することもできます。 + - 他のスケジューリングタスクが同時に実行されているため、バランシングの速度が低下しています。この場合、バランシングが他のスケジューリングタスクよりも優先される可能性がある場合は、他のタスクを停止するか、速度を制限することができます。例えば、バランシングの実行中に一部のノードをオフラインにすると、両方の操作でクォータ`region-schedule-limit`が消費されます。このような場合、スケジューラの速度を制限してノードを削除するか、 `enable-replace-offline-replica = false`設定して一時的に無効にすることができます。 + - スケジューリングプロセスが遅すぎます。原因を確認するには`RemovePeer` **Operator ステップの所要時間**メトリックを確認してください。通常、スナップショットの送受信を伴わないステップ（ `TransferLeader` `PromoteLearner` ）は数ミリ秒で完了するはずですが、スナップショットを伴うステップ（ `AddLearner` `AddPeer` ）は数十秒で完了すると予想されます。所要時間が明らかに長すぎる場合は、TiKV の負荷が高いか、ネットワークのボトルネックが発生している可能性があります。具体的な分析が必要です。 -- PDは対応するバランシングスケジューラを生成できません。考えられる原因は次のとおりです。 +- PDは対応するバランシングスケジューラを生成できません。考えられる原因は次のとおりです。 - - スケジューラが有効化されていません。例えば、対応するスケジューラが削除されているか、制限が「​​0」に設定されている可能性があります。 - - その他の制約。例えば、システム内の制約`evict-leader-scheduler`により、リーダーが対応するストアに移行できない、あるいはラベルプロパティが設定されているため、一部のストアがリーダーを拒否するといった状況です。 - - クラスタトポロジによる制約。例えば、3つのデータセンターにまたがる3つのレプリカを持つクラスタでは、レプリカ分離のため、各リージョンの3つのレプリカが異なるデータセンターに分散されます。これらのデータセンター間でストア数が異なる場合、スケジューリングは各データセンター内ではバランスの取れた状態になりますが、グローバルではバランスが取れません。 + - スケジューラが有効化されていません。例えば、対応するスケジューラが削除されているか、制限が「​​0」に設定されている可能性があります。 + - その他の制約。例えば、システム内の制約`evict-leader-scheduler`により、リーダーが対応するストアに移行できない、あるいはラベルプロパティが設定されているため、一部のストアがリーダーを拒否するといった状況です。 + - クラスタトポロジによる制約。例えば、3つのデータセンターにまたがる3つのレプリカを持つクラスタでは、レプリカ分離のため、各リージョンの3つのレプリカが異なるデータセンターに分散されます。これらのデータセンター間でストア数が異なる場合、スケジューリングは各データセンター内ではバランスの取れた状態になりますが、グローバルではバランスが取れません。 ### ノードをオフラインにするのが遅い {#taking-nodes-offline-is-slow} @@ -229,14 +229,14 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー オペレーターは正常に生成されたが、スケジュール プロセスが遅い場合は、次の理由が考えられます。 -- スケジューリング速度はデフォルトで制限されています。`leader-schedule-limit`または`replica-schedule-limit`の値を大きく調整できます。同様に、 `max-pending-peer-count`と`max-snapshot-count`の制限を緩和することも検討できます。 -- 他のスケジューリングタスクが同時に実行され、システム内のリソースを奪い合っています。解決策は[リーダー/リージョンが均等に分布していない](#leadersregions-are-not-evenly-distributed)を参照してください。 -- 単一ノードをオフラインにすると、処理対象となるリージョンリーダー（レプリカ3台構成では約1/3）が削除対象のノードに分散されます。そのため、処理速度はこの単一ノードによるスナップショット生成速度によって制限されます。「 `evict-leader-scheduler`を手動で追加することで、リージョンリーダーの移行速度を上げることができます。 +- スケジューリング速度はデフォルトで制限されています。`leader-schedule-limit`または`replica-schedule-limit`の値を大きく調整できます。同様に、 `max-pending-peer-count`と`max-snapshot-count`の制限を緩和することも検討できます。 +- 他のスケジューリングタスクが同時に実行され、システム内のリソースを奪い合っています。解決策は[リーダー/リージョンが均等に分布していない](#leadersregions-are-not-evenly-distributed)を参照してください。 +- 単一ノードをオフラインにすると、処理対象となるリージョンリーダー（レプリカ3台構成では約1/3）が削除対象のノードに分散されます。そのため、処理速度はこの単一ノードによるスナップショット生成速度によって制限されます。「 `evict-leader-scheduler`を手動で追加することで、リージョンリーダーの移行速度を上げることができます。 対応する演算子の生成に失敗した場合、考えられる理由は次のとおりです。 -- オペレータが停止しているか、 `replica-schedule-limit` "0" に設定されます。 -- リージョン移行に適したノードが存在しません。例えば、同じラベルの置き換えノードの利用可能な容量が20%未満の場合、PDはそのノードのストレージ不足を回避するためにスケジューリングを停止します。このような場合は、ノードを追加するか、データを削除してスペースを解放する必要があります。 +- オペレータが停止しているか、 `replica-schedule-limit` "0" に設定されます。 +- リージョン移行に適したノードが存在しません。例えば、同じラベルの置き換えノードの利用可能な容量が20%未満の場合、PDはそのノードのストレージ不足を回避するためにスケジューリングを停止します。このような場合は、ノードを追加するか、データを削除してスペースを解放する必要があります。 ### ノードをオンラインにするのが遅い {#bringing-nodes-online-is-slow} @@ -246,13 +246,13 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー ホット リージョンのスケジュールの問題は、通常、次のカテゴリに分類されます。 -- ホットリージョンは PD メトリックを通じて観察できますが、スケジュール速度が追いつかず、ホットリージョンを時間内に再分配できません。 +- ホットリージョンは PD メトリックを通じて観察できますが、スケジュール速度が追いつかず、ホットリージョンを時間内に再分配できません。 **解決策**： `hot-region-schedule-limit`値を大きくし、他のスケジューラの制限クォータを減らして、ホットリージョンのスケジューリングを高速化します。または、 `hot-region-cache-hits-threshold`値を小さくして、PD がトラフィックの変化に敏感になるように調整することもできます。 -- 単一のリージョンにホットスポットが形成されています。例えば、小さなテーブルが大量のリクエストによって集中的にスキャンされている場合などです。これはPDメトリクスからも検出できます。単一のホットスポットを分散させることはできないため、このようなリージョンを分割するには、手動で`split-region`演算子を追加する必要があります。 +- 単一のリージョンにホットスポットが形成されています。例えば、小さなテーブルが大量のリクエストによって集中的にスキャンされている場合などです。これはPDメトリクスからも検出できます。単一のホットスポットを分散させることはできないため、このようなリージョンを分割するには、手動で`split-region`演算子を追加する必要があります。 -- TiKV関連のメトリクスから、一部のノードの負荷が他のノードよりも著しく高くなっており、これがシステム全体のボトルネックとなっています。現在、PDはトラフィック分析のみでホットスポットをカウントしているため、特定のシナリオではPDがホットスポットを特定できない可能性があります。例えば、一部のリージョンでポイント検索リクエストが集中している場合、トラフィック内では検出しにくいものの、高いQPSが主要モジュールのボトルネックにつながる可能性があります。 +- TiKV関連のメトリクスから、一部のノードの負荷が他のノードよりも著しく高くなっており、これがシステム全体のボトルネックとなっています。現在、PDはトラフィック分析のみでホットスポットをカウントしているため、特定のシナリオではPDがホットスポットを特定できない可能性があります。例えば、一部のリージョンでポイント検索リクエストが集中している場合、トラフィック内では検出しにくいものの、高いQPSが主要モジュールのボトルネックにつながる可能性があります。 **解決策**：まず、特定のビジネスに基づいてホットリージョンが形成されるテーブルを特定します。次に、 `scatter-range-scheduler`のスケジューラを追加して、このテーブルのすべてのリージョンを均等に分散させます。TiDBは、この操作を簡素化するためのHTTP APIインターフェースも提供しています。詳細は[TiDB HTTP API](https://github.com/pingcap/tidb/blob/release-8.5/docs/tidb_http_api.md)を参照してください。 @@ -260,20 +260,20 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー 低速スケジューリングと同様に、リージョンマージの速度は、 `merge-schedule-limit`と`region-schedule-limit`の設定によって制限されているか、リージョンマージスケジューラが他のスケジューラと競合している可能性が高くなります。具体的な解決策は次のとおりです。 -- メトリクスからシステム内に多数の空きリージョンがあることが分かっている場合は、 `max-merge-region-size`と`max-merge-region-keys`を小さな値に調整することでマージを高速化できます。これは、マージプロセスにはレプリカの移行が含まれるため、マージ対象のリージョンが小さいほどマージが高速化されるためです。マージ演算子が既に高速に生成されている場合は、プロセスをさらに高速化するために、 `patrol-region-interval`を`10ms`に設定できます（TiDB v5.3.0以降では、この設定項目のデフォルト値は`10ms`です）。これにより、CPU消費量は増加しますが、リージョンスキャンが高速化されます。 +- メトリクスからシステム内に多数の空きリージョンがあることが分かっている場合は、 `max-merge-region-size`と`max-merge-region-keys`を小さな値に調整することでマージを高速化できます。これは、マージプロセスにはレプリカの移行が含まれるため、マージ対象のリージョンが小さいほどマージが高速化されるためです。マージ演算子が既に高速に生成されている場合は、プロセスをさらに高速化するために、 `patrol-region-interval`を`10ms`に設定できます（TiDB v5.3.0以降では、この設定項目のデフォルト値は`10ms`です）。これにより、CPU消費量は増加しますが、リージョンスキャンが高速化されます。 -- 多数のテーブルが作成され、その後空になっています（切り捨てられたテーブルも含みます）。分割テーブル属性が有効になっている場合、これらの空のリージョンは結合できません。この属性を無効にするには、以下のパラメータを調整してください。 +- 多数のテーブルが作成され、その後空になっています（切り捨てられたテーブルも含みます）。分割テーブル属性が有効になっている場合、これらの空のリージョンは結合できません。この属性を無効にするには、以下のパラメータを調整してください。 - - TiKV: `split-region-on-table`から`false`に設定します。パラメータを動的に変更することはできません。 - - PD: PD Controlを使用して、クラスターの状況に応じて必要なパラメータを設定します。 + - TiKV: `split-region-on-table`から`false`に設定します。パラメータを動的に変更することはできません。 + - PD: PD Controlを使用して、クラスターの状況に応じて必要なパラメータを設定します。 - - クラスターにTiDBインスタンスがなく、 [`key-type`](/pd-control.md#config-show--set-option-value--placement-rules)の値が`raw`または`txn`に設定されているとします。この場合、PDは`enable-cross-table-merge setting`の値に関係なく、テーブル間でリージョンをマージできます。 `key-type`パラメータは動的に変更できます。 + - クラスターにTiDBインスタンスがなく、 [`key-type`](/pd-control.md#config-show--set-option-value--placement-rules)の値が`raw`または`txn`に設定されているとします。この場合、PDは`enable-cross-table-merge setting`の値に関係なく、テーブル間でリージョンをマージできます。 `key-type`パラメータは動的に変更できます。 ```bash config set key-type txn ``` - - クラスターにTiDBインスタンスがあり、 `key-type`の値が`table`に設定されているとします。この場合、PDは`enable-cross-table-merge`の値が`true`に設定されている場合にのみ、テーブル間でリージョンをマージできます。 `key-type`パラメータは動的に変更できます。 + - クラスターにTiDBインスタンスがあり、 `key-type`の値が`table`に設定されているとします。この場合、PDは`enable-cross-table-merge`の値が`true`に設定されている場合にのみ、テーブル間でリージョンをマージできます。 `key-type`パラメータは動的に変更できます。 ```bash config set enable-cross-table-merge true diff --git a/best-practices/readonly-nodes.md b/best-practices/readonly-nodes.md index 721e99fc2e970..36937a40bf8c4 100644 --- a/best-practices/readonly-nodes.md +++ b/best-practices/readonly-nodes.md @@ -26,7 +26,7 @@ tikv_servers: ### 2. 配置ルールを使用して、ラーナーとして読み取り専用ノードにデータを保存する {#2-use-placement-rules-to-store-data-on-read-only-nodes-as-learners} -1. `pd-ctl config placement-rules`コマンドを実行して、デフォルトの配置ルールをエクスポートします。 +1. `pd-ctl config placement-rules`コマンドを実行して、デフォルトの配置ルールをエクスポートします。 ```shell pd-ctl config placement-rules rule-bundle load --out="rules.json" @@ -54,7 +54,7 @@ tikv_servers: ] ``` -2. すべてのデータをラーナーとして読み取り専用ノードに保存します。以下の例はデフォルトの設定に基づいています。 +2. すべてのデータをラーナーとして読み取り専用ノードに保存します。以下の例はデフォルトの設定に基づいています。 ```json [ @@ -94,7 +94,7 @@ tikv_servers: ] ``` -3. 上記の構成を PD に書き込むには、 `pd-ctl config placement-rules`コマンドを使用します。 +3. 上記の構成を PD に書き込むには、 `pd-ctl config placement-rules`コマンドを使用します。 ```shell pd-ctl config placement-rules rule-bundle save --in="rules.json" @@ -102,8 +102,8 @@ tikv_servers: > **Note:** > -> - 大規模なデータセットを持つクラスターで上記の操作を実行すると、クラスター全体のデータが読み取り専用ノードに完全に複製されるまでに時間がかかる場合があります。この間、読み取り専用ノードはサービスを提供できない可能性があります。 -> - バックアップの特別な実装のため、各ラベルのラーナー数は 1 を超えることはできません。そうでない場合、バックアップ中に重複データが生成されます。 +> - 大規模なデータセットを持つクラスターで上記の操作を実行すると、クラスター全体のデータが読み取り専用ノードに完全に複製されるまでに時間がかかる場合があります。この間、読み取り専用ノードはサービスを提供できない可能性があります。 +> - バックアップの特別な実装のため、各ラベルのラーナー数は 1 を超えることはできません。そうでない場合、バックアップ中に重複データが生成されます。 ### 3. Follower Readを使用して読み取り専用ノードからデータを読み取る {#3-use-follower-read-to-read-data-from-read-only-nodes} diff --git a/best-practices/saas-best-practices.md b/best-practices/saas-best-practices.md index 7231abaa1cd4d..480ba4341a023 100644 --- a/best-practices/saas-best-practices.md +++ b/best-practices/saas-best-practices.md @@ -18,15 +18,15 @@ aliases: ['/ja/tidb/stable/saas-best-practices/'] 大容量メモリを搭載したTiDBインスタンスの使用をお勧めします。例: -- 100 万個のテーブルの場合は、32 GiB 以上のメモリを使用します。 -- 300 万のテーブルの場合は、64 GiB 以上のメモリを使用します。 +- 100 万個のテーブルの場合は、32 GiB 以上のメモリを使用します。 +- 300 万のテーブルの場合は、64 GiB 以上のメモリを使用します。 大容量メモリ搭載のTiDBインスタンスは、Infoschema、 統計、および実行プランキャッシュに多くのキャッシュスペースを割り当てるため、キャッシュヒット率が向上し、ビジネスパフォーマンスが向上します。また、大容量メモリは、TiDB GCによるパフォーマンス変動や安定性の問題を軽減します。 TiKV および PD に推奨されるハードウェア構成は次のとおりです。 -- TiKV: 8 個の vCPU と 32 GiB 以上のメモリ。 -- PD: 8 個の CPU と 16 GiB 以上のメモリ。 +- TiKV: 8 個の vCPU と 32 GiB 以上のメモリ。 +- PD: 8 個の CPU と 16 GiB 以上のメモリ。 ## リージョンの数を制御する {#control-the-number-of-regions} @@ -34,23 +34,23 @@ TiKV および PD に推奨されるハードウェア構成は次のとおり ## キャッシュを構成する {#configure-caches} -- TiDB v8.4.0 以降、TiDB は SQL 実行中に、SQL ステートメントに関連するテーブル情報をオンデマンドで Infoschema キャッシュにロードします。 +- TiDB v8.4.0 以降、TiDB は SQL 実行中に、SQL ステートメントに関連するテーブル情報をオンデマンドで Infoschema キャッシュにロードします。 - - TiDB ダッシュボードの**Schema Load**パネルの下にある**Infoschema v2 Cache Size**サブパネルと**Infoschema v2 Cache Operation**サブパネルを観察することで、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 Load**パネルの下にある**Infoschema v2 Cache Size**サブパネルと**Infoschema v2 Cache Operation**サブパネルを観察することで、Infoschema キャッシュのサイズとヒット率を監視できます。 + - システム変数[`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800)を使用すると、ビジネスニーズに合わせて Infoschema キャッシュのメモリ制限を調整できます。Infoschema キャッシュのサイズは、SQL 実行に関係するテーブルの数に比例します。実際のテストでは、100 万テーブル（各テーブルに 4 つの列、1 つの主キー、1 つのインデックス）のメタデータを完全にキャッシュするには、約 2.4 GiB のメモリが必要です。 -- TiDB は、SQL 実行中に、SQL ステートメントに関係するテーブル統計をオンデマンドで統計キャッシュに読み込みます。 +- TiDB は、SQL 実行中に、SQL ステートメントに関係するテーブル統計をオンデマンドで統計キャッシュに読み込みます。 - - TiDB ダッシュボードの**Statistics & Plan Management**パネルの**Stats Cache Cost**サブパネルと**Stats Cache OPS**サブパネルを観察することで、統計キャッシュのサイズとヒット率を監視できます。 - - システム変数[`tidb_stats_cache_mem_quota`](/system-variables.md#tidb_stats_cache_mem_quota-new-in-v610)を使用することで、ビジネスニーズに合わせて統計キャッシュのメモリ制限を調整できます。実際のテストでは、100,000 個のテーブルに対して単純な SQL（演算子`IndexRangeScan`を使用）を実行すると、統計キャッシュで約 3.96 GiB のメモリが消費されます。 + - TiDB ダッシュボードの**Statistics & Plan Management**パネルの**Stats Cache Cost**サブパネルと**Stats Cache OPS**サブパネルを観察することで、統計キャッシュのサイズとヒット率を監視できます。 + - システム変数[`tidb_stats_cache_mem_quota`](/system-variables.md#tidb_stats_cache_mem_quota-new-in-v610)を使用することで、ビジネスニーズに合わせて統計キャッシュのメモリ制限を調整できます。実際のテストでは、100,000 個のテーブルに対して単純な SQL（演算子`IndexRangeScan`を使用）を実行すると、統計キャッシュで約 3.96 GiB のメモリが消費されます。 ## 統計を収集する {#collect-statistics} -- TiDB v8.4.0以降、TiDBはTiDBクラスター内で同時に実行できる自動分析操作の数を制御するためのシステム変数[`tidb_auto_analyze_concurrency`](/system-variables.md#tidb_auto_analyze_concurrency-new-in-v840)を導入しました。複数テーブルを扱うシナリオでは、必要に応じてこの同時実行数を増やすことで、自動分析のスループットを向上させることができます。同時実行数の値を増やすと、スループットとTiDBオーナーノードのCPU使用率は直線的に増加します。実際のテストでは、同時実行数を16に設定することで、1分以内に320個のテーブル（各テーブルは10,000行、4列、1つのインデックスを持つ）の自動分析を実行でき、TiDBオーナーノードのCPUコアを1つ消費しました。 -- システム変数[`tidb_auto_build_stats_concurrency`](/system-variables.md#tidb_auto_build_stats_concurrency-new-in-v650)と[`tidb_build_sampling_stats_concurrency`](/system-variables.md#tidb_build_sampling_stats_concurrency-new-in-v750)は、TiDB統計情報の構築における同時実行性を制御します。シナリオに応じて調整できます。 - - パーティション化されたテーブルが多数あるシナリオでは、 `tidb_auto_build_stats_concurrency`の値を増やすことを優先します。 - - 列数が多いシナリオでは、 `tidb_build_sampling_stats_concurrency`の値を増やすことを優先します。 -- 過剰なリソース使用を避けるため、 `tidb_auto_analyze_concurrency` 、 `tidb_auto_build_stats_concurrency` 、 `tidb_build_sampling_stats_concurrency`の積が TiDB CPU コアの数を超えないようにしてください。 +- TiDB v8.4.0以降、TiDBはTiDBクラスター内で同時に実行できる自動分析操作の数を制御するためのシステム変数[`tidb_auto_analyze_concurrency`](/system-variables.md#tidb_auto_analyze_concurrency-new-in-v840)を導入しました。複数テーブルを扱うシナリオでは、必要に応じてこの同時実行数を増やすことで、自動分析のスループットを向上させることができます。同時実行数の値を増やすと、スループットとTiDBオーナーノードのCPU使用率は直線的に増加します。実際のテストでは、同時実行数を16に設定することで、1分以内に320個のテーブル（各テーブルは10,000行、4列、1つのインデックスを持つ）の自動分析を実行でき、TiDBオーナーノードのCPUコアを1つ消費しました。 +- システム変数[`tidb_auto_build_stats_concurrency`](/system-variables.md#tidb_auto_build_stats_concurrency-new-in-v650)と[`tidb_build_sampling_stats_concurrency`](/system-variables.md#tidb_build_sampling_stats_concurrency-new-in-v750)は、TiDB統計情報の構築における同時実行性を制御します。シナリオに応じて調整できます。 + - パーティション化されたテーブルが多数あるシナリオでは、 `tidb_auto_build_stats_concurrency`の値を増やすことを優先します。 + - 列数が多いシナリオでは、 `tidb_build_sampling_stats_concurrency`の値を増やすことを優先します。 +- 過剰なリソース使用を避けるため、 `tidb_auto_analyze_concurrency` 、 `tidb_auto_build_stats_concurrency` 、 `tidb_build_sampling_stats_concurrency`の積が TiDB CPU コアの数を超えないようにしてください。 ## システムテーブルを効率的にクエリする {#query-system-tables-efficiently} @@ -58,13 +58,13 @@ TiKV および PD に推奨されるハードウェア構成は次のとおり たとえば、300 万のテーブルがあるシナリオでは次のようになります。 -- 次の SQL ステートメントを実行すると、約 8 GiB のメモリが消費されます。 +- 次の SQL ステートメントを実行すると、約 8 GiB のメモリが消費されます。 ```sql SELECT COUNT(*) FROM information_schema.tables; ``` -- 次の SQL ステートメントの実行には約 20 分かかります。 +- 次の SQL ステートメントの実行には約 20 分かかります。 ```sql SELECT COUNT(*) FROM information_schema.views; @@ -76,9 +76,9 @@ TiKV および PD に推奨されるハードウェア構成は次のとおり SaaSマルチテナントシナリオでは、通常、各ユーザーはTiDBに接続して自身のテナント（データベース）内のデータを操作します。多数の接続をサポートするには、次の点に留意してください。 -- より多くの同時リクエストをサポートするには、TiDB 構成項目[`token-limit`](/tidb-configuration-file.md#token-limit) (デフォルトでは`1000` ) を増やします。 -- TiDBのメモリ使用量は接続数にほぼ比例します。実際のテストでは、アイドル接続が20万件あると、TiDBのメモリ使用量が約30GiB増加しました。実際の接続数に基づいて、TiDBのメモリ仕様を増やすことをお勧めします。 -- `PREPARED`ステートメントを使用する場合、各接続はセッションレベルのプリペアドプランキャッシュを維持します。`DEALLOCATE`ステートメントが長時間実行されない場合、キャッシュに過剰なプランが蓄積され、メモリ使用量が増加する可能性があります。実際のテストでは、 `IndexRangeScan`を含む 400,000 の実行計画で約 5 GiB のメモリが消費されました。これに応じてメモリ仕様を増やすことをお勧めします。 +- より多くの同時リクエストをサポートするには、TiDB 構成項目[`token-limit`](/tidb-configuration-file.md#token-limit) (デフォルトでは`1000` ) を増やします。 +- TiDBのメモリ使用量は接続数にほぼ比例します。実際のテストでは、アイドル接続が20万件あると、TiDBのメモリ使用量が約30GiB増加しました。実際の接続数に基づいて、TiDBのメモリ仕様を増やすことをお勧めします。 +- `PREPARED`ステートメントを使用する場合、各接続はセッションレベルのプリペアドプランキャッシュを維持します。`DEALLOCATE`ステートメントが長時間実行されない場合、キャッシュに過剰なプランが蓄積され、メモリ使用量が増加する可能性があります。実際のテストでは、 `IndexRangeScan`を含む 400,000 の実行計画で約 5 GiB のメモリが消費されました。これに応じてメモリ仕様を増やすことをお勧めします。 ## 古いものを使用するには、慎重に読んでください {#use-stale-read-carefully} @@ -86,15 +86,15 @@ SaaSマルチテナントシナリオでは、通常、各ユーザーはTiDBに ## BRバックアップと復元を最適化 {#optimize-br-backup-and-restore} -- 数百万のテーブルを含むフルバックアップを復元する場合は、大容量メモリを搭載したBRインスタンスの使用をお勧めします。例: - - 100 万個のテーブルの場合は、32 GiB 以上のメモリを備えたBRインスタンスを使用します。 - - 300 万のテーブルの場合は、64 GiB 以上のメモリを備えたBRインスタンスを使用します。 -- BRログバックアップとスナップショットリストアは追加のTiKVメモリを消費します。32GiB以上のメモリを搭載したTiKVインスタンスの使用をお勧めします。 -- ログの復元速度を向上させるには、必要に応じてBR構成[`pitr-batch-count`と`pitr-concurrency`](/br/br-pitr-manual.md#restore-to-a-specified-point-in-time-pitr)を調整します。 +- 数百万のテーブルを含むフルバックアップを復元する場合は、大容量メモリを搭載したBRインスタンスの使用をお勧めします。例: + - 100 万個のテーブルの場合は、32 GiB 以上のメモリを備えたBRインスタンスを使用します。 + - 300 万のテーブルの場合は、64 GiB 以上のメモリを備えたBRインスタンスを使用します。 +- BRログバックアップとスナップショットリストアは追加のTiKVメモリを消費します。32GiB以上のメモリを搭載したTiKVインスタンスの使用をお勧めします。 +- ログの復元速度を向上させるには、必要に応じてBR構成[`pitr-batch-count`と`pitr-concurrency`](/br/br-pitr-manual.md#restore-to-a-specified-point-in-time-pitr)を調整します。 ## TiDB Lightningでデータをインポートする {#import-data-with-tidb-lightning} [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用して数百万のテーブルをインポートする場合は、次の推奨事項に従ってください。 -- 大きなテーブル (100 GiB 以上) の場合は、 TiDB Lightning [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を使用します。 -- 小さなテーブル (通常は多数) の場合は、 TiDB Lightning [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)を使用します。 +- 大きなテーブル (100 GiB 以上) の場合は、 TiDB Lightning [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を使用します。 +- 小さなテーブル (通常は多数) の場合は、 TiDB Lightning [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)を使用します。 diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md index 573976e22a954..a3428096ab7c3 100644 --- a/best-practices/three-nodes-hybrid-deployment.md +++ b/best-practices/three-nodes-hybrid-deployment.md @@ -88,8 +88,8 @@ RocksDBスレッドプールは、コンパクションジョブとフラッシ このテストでは、 `rocksdb.max-background-jobs`の値は`3`に、 `rocksdb.max-sub-compactions`の値は`1`に設定されています。TPC-C負荷での12時間テスト中、書き込みストールは発生しませんでした。実際の負荷に応じて2つのパラメータ値を最適化する際には、監視指標に基づいて値を徐々に下げることができます。 -- 書き込み停止が発生する場合は、値を`rocksdb.max-background-jobs`増やします。 -- 書き込み停止が続く場合は、値`rocksdb.max-sub-compactions`を`2`または`3`に設定します。 +- 書き込み停止が発生する場合は、値を`rocksdb.max-background-jobs`増やします。 +- 書き込み停止が続く場合は、値`rocksdb.max-sub-compactions`を`2`または`3`に設定します。 #### `rocksdb.rate-bytes-per-sec` {#rocksdb-rate-bytes-per-sec} diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index 6da8e35ae5584..96811f41d583c 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -10,9 +10,9 @@ aliases: ['/ja/docs/dev/tidb-best-practices/','/ja/tidb/stable/tidb-best-practic この文書を読む前に、TiDBの技術的原理を紹介する以下の3つのブログ記事を読むことをお勧めします。 -- [TiDB内部（I） - データストレージ](https://www.pingcap.com/blog/tidb-internal-data-storage/) -- [TiDB 内部 (II) - コンピューティング](https://www.pingcap.com/blog/tidb-internal-computing/) -- [TiDB内部（III） - スケジューリング](https://www.pingcap.com/blog/tidb-internal-scheduling/) +- [TiDB内部（I） - データストレージ](https://www.pingcap.com/blog/tidb-internal-data-storage/) +- [TiDB 内部 (II) - コンピューティング](https://www.pingcap.com/blog/tidb-internal-computing/) +- [TiDB内部（III） - スケジューリング](https://www.pingcap.com/blog/tidb-internal-scheduling/) ## 序文 {#preface} @@ -36,25 +36,25 @@ Raftは、強力な一貫性を備えたデータ複製を保証する合意ア TiDBは完全な分散トランザクションを提供し、そのモデルは[Google Percolator](https://research.google/pubs/large-scale-incremental-processing-using-distributed-transactions-and-notifications/)をベースに最適化されています。このドキュメントでは、以下の機能を紹介します。 -- 楽観的トランザクションモデル +- 楽観的トランザクションモデル TiDBの楽観的トランザクションモデルでは、コミットフェーズまで競合を検出しません。競合が発生した場合、トランザクションは再試行する必要があります。しかし、競合が深刻な場合、再試行前の操作は無効となり、繰り返す必要があるため、このモデルは非効率的です。 データベースがカウンターとして使用されていると仮定します。アクセス同時実行数が多いと、深刻な競合が発生し、複数回の再試行やタイムアウトにつながる可能性があります。そのため、深刻な競合が発生するシナリオでは、悲観的トランザクションモードを使用するか、Redisにカウンターを配置するなど、システムアーキテクチャレベルで問題を解決することを推奨します。ただし、アクセス競合がそれほど深刻でない場合は、楽観的トランザクションモデルでも十分です。 -- 悲観的トランザクションモード +- 悲観的トランザクションモード TiDB では、悲観的トランザクション モードは MySQL とほぼ同じ動作をします。トランザクションは実行フェーズ中にロックを適用し、競合状況での再試行を回避して成功率を高めます。悲観的ロックを適用することで、 `SELECT FOR UPDATE`を使用してデータを事前にロックすることもできます。 しかし、アプリケーションシナリオにおける競合が少ない場合は、楽観的トランザクションモデルの方が優れたパフォーマンスを発揮します。 -- トランザクションサイズ制限 +- トランザクションサイズ制限 分散トランザクションは2フェーズコミットを実行する必要があり、下位レイヤーはRaftレプリケーションを実行するため、トランザクションが非常に大きい場合、コミット処理が非常に遅くなり、その結果、後続のRaftレプリケーション処理が停止してしまう可能性があります。この問題を回避するために、トランザクションサイズには制限が設けられています。 - - トランザクションは（デフォルトでは）5,000個のSQLステートメントに制限されています。 - - 各キーと値のペアのエントリは、デフォルトでは最大6MBです。 - - キーと値のペアの合計サイズは10GB以下です。 + - トランザクションは（デフォルトでは）5,000個のSQLステートメントに制限されています。 + - 各キーと値のペアのエントリは、デフォルトでは最大6MBです。 + - キーと値のペアの合計サイズは10GB以下です。 [Google Cloud Spanner](https://cloud.google.com/spanner/quotas)でも同様の制限を確認できます。 @@ -72,8 +72,8 @@ TiDB は、SQL 構造を Key-Value 構造に自動的にマッピングします 簡単に言うと、TiDBは以下の操作を実行します。 -- データの行はキーと値のペアにマッピングされます。キーには`TableID`という接頭辞が付き、行IDが接尾辞として付加されます。 -- インデックスはキーと値のペアとしてマッピングされます。キーには`TableID+IndexID`が接頭辞として付き、インデックス値が接尾辞として付きます。 +- データの行はキーと値のペアにマッピングされます。キーには`TableID`という接頭辞が付き、行IDが接尾辞として付加されます。 +- インデックスはキーと値のペアとしてマッピングされます。キーには`TableID+IndexID`が接頭辞として付き、インデックス値が接尾辞として付きます。 同じテーブル内のデータまたはインデックスには、同じ接頭辞が付きます。これらのキーと値は、TiKV のキー空間内で隣接する位置にあります。そのため、書き込むデータ量が多く、すべてが 1 つのテーブルに書き込まれる場合、書き込みホットスポットが発生します。連続して書き込まれるデータのインデックス値の一部も連続している場合 (たとえば、 `update time`のように時間とともに増加するフィールド) は、状況が悪化し、書き込みホットスポットがいくつか発生して、システム全体のボトルネックになります。 @@ -85,22 +85,22 @@ TiDB は、[グローバルインデックス](/global-indexes.md)インデッ MySQLで培った多くの経験は、TiDBにも応用できます。ただし、TiDBには独自の機能があることに留意してください。以下は、TiDBでセカンダリインデックスを使用する際の注意点です。 -- セカンダリインデックスが多いほど良いのか？ +- セカンダリインデックスが多いほど良いのか？ セカンダリインデックスはクエリの速度を向上させることができますが、インデックスを追加すると副作用があります。前のセクションでは、インデックスのストレージ形式について説明しました。インデックスを追加するごとに、行を挿入する際にキーと値のペアが1つずつ増えます。したがって、インデックスの数が増えるほど、書き込み速度は低下し、使用する容量も増加します。 さらに、インデックスが多すぎるとオプティマイザの実行時間に影響を与え、不適切なインデックスはオプティマイザを誤った方向に導きます。したがって、セカンダリインデックスの数が多いほどパフォーマンスが向上するとは限りません。 -- どの列にインデックスを作成すべきですか？ +- どの列にインデックスを作成すべきですか？ 前述のとおり、インデックスは重要ですが、インデックスの数は適切でなければなりません。アプリケーションの特性に応じて適切なインデックスを作成する必要があります。原則として、パフォーマンスを向上させるためには、クエリに関係する列にインデックスを作成する必要があります。インデックスを作成する必要がある状況は以下のとおりです。 - - 差異の度合いが高い列の場合、インデックスによってフィルタリングされた行数は著しく削減されます。 - - 複数のクエリ条件がある場合は、複合インデックスを選択できます。複合インデックスの前に、同等の条件を持つ列を配置することに注意してください。 + - 差異の度合いが高い列の場合、インデックスによってフィルタリングされた行数は著しく削減されます。 + - 複数のクエリ条件がある場合は、複合インデックスを選択できます。複合インデックスの前に、同等の条件を持つ列を配置することに注意してください。 例えば、よく使われるクエリが`select * from t where c1 = 10 and c2 = 100 and c3 > 10`の場合、複合インデックス`Index cidx (c1, c2, c3)`を作成できます。このようにして、クエリ条件を使用してインデックスのプレフィックスを作成し、スキャンを実行できます。 -- インデックスを介したクエリとテーブルを直接スキャンすることの違い +- インデックスを介したクエリとテーブルを直接スキャンすることの違い TiDBはグローバルインデックスを実装しているため、テーブルのインデックスとデータは必ずしも同じデータシャーディング上に配置されるとは限りません。インデックスを介してクエリを実行する場合、まずインデックスをスキャンして対応する行IDを取得し、次にその行IDを使用してデータを取得します。そのため、この方法では2回のネットワークリクエストが発生し、一定のパフォーマンスオーバーヘッドが生じます。 @@ -108,31 +108,31 @@ MySQLで培った多くの経験は、TiDBにも応用できます。ただし 以下の2つの条件では、2回のアクセスという問題は発生しません。 - - インデックスの列は既にクエリの要件を満たしています。 `c`テーブルの`t`列にインデックスがあり、クエリが`select c from t where c > 10;`であると仮定します。このとき、インデックスにアクセスすれば必要なすべてのデータを取得できます。この状況は`Covering Index`と呼ばれます。しかし、クエリのパフォーマンスに重点を置く場合は、フィルタリングする必要はないがクエリ結果で返す必要がある列の一部をインデックスに入れ、複合インデックスを作成できます。 `select c1, c2 from t where c1 > 10;`例にとります。複合インデックス`Index c12 (c1, c2)`を作成することで、このクエリを最適化できます。 + - インデックスの列は既にクエリの要件を満たしています。 `c`テーブルの`t`列にインデックスがあり、クエリが`select c from t where c > 10;`であると仮定します。このとき、インデックスにアクセスすれば必要なすべてのデータを取得できます。この状況は`Covering Index`と呼ばれます。しかし、クエリのパフォーマンスに重点を置く場合は、フィルタリングする必要はないがクエリ結果で返す必要がある列の一部をインデックスに入れ、複合インデックスを作成できます。 `select c1, c2 from t where c1 > 10;`例にとります。複合インデックス`Index c12 (c1, c2)`を作成することで、このクエリを最適化できます。 - - テーブルの主キーは整数型です。この場合、TiDBは主キーの値を行IDとして使用します。したがって、クエリ条件が主キーに基づいている場合は、行IDの範囲を直接構築し、テーブルデータをスキャンして結果を取得できます。 + - テーブルの主キーは整数型です。この場合、TiDBは主キーの値を行IDとして使用します。したがって、クエリ条件が主キーに基づいている場合は、行IDの範囲を直接構築し、テーブルデータをスキャンして結果を取得できます。 -- クエリの同時実行性 +- クエリの同時実行性 データは複数のリージョンに分散されているため、TiDB ではクエリが並行して実行されます。ただし、システム リソースを大量に消費する可能性があるため、デフォルトでは並行処理の頻度は高くありません。また、OLTP クエリは通常、大量のデータを扱わないため、低い並行処理頻度で十分です。一方、OLAP クエリでは並行処理の頻度が高く、TiDB は以下のシステム変数によってクエリの並行処理頻度を調整します。 - - [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) : + - [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) : テーブルデータとインデックスデータのスキャンを含む、データのスキャンの同時実行性。 - - [`tidb_index_lookup_size`](/system-variables.md#tidb_index_lookup_size) : + - [`tidb_index_lookup_size`](/system-variables.md#tidb_index_lookup_size) : テーブルデータにアクセスする前にインデックスにアクセスして行IDを取得する必要がある場合、行IDのバッチを単一のリクエストとして使用してテーブルデータにアクセスします。このパラメータはバッチのサイズを設定します。バッチが大きいほどレイテンシーが増加し、小さいほどクエリが増える可能性があります。このパラメータの適切なサイズは、クエリが扱うデータの量に関連しています。通常、変更は必要ありません。 - - [`tidb_index_lookup_concurrency`](/system-variables.md#tidb_index_lookup_concurrency) : + - [`tidb_index_lookup_concurrency`](/system-variables.md#tidb_index_lookup_concurrency) : テーブルデータにアクセスする前にインデックスにアクセスして行IDを取得する必要がある場合、このパラメータによって、行IDを介してデータを取得する際の同時実行性が変更されます。 -- インデックスを使用して結果の順序を確実にします +- インデックスを使用して結果の順序を確実にします インデックスを使用してデータをフィルタリングまたはソートできます。TiDB はまずインデックスの順序に従って行IDを取得し、その後それらの行IDの順序に従って行の内容を返します。このようにして、返される結果はインデックス列に従って順序付けられます。インデックスのスキャンと行の取得のモデルは並列処理＋パイプラインであると既に述べました。行がインデックスの順序に従って返される場合、2つのクエリ間の高い同時実行性はレイテンシーを削減しません。そのため、デフォルトでは同時実行性は低く設定されていますが、 [`tidb_executor_concurrency`](/system-variables.md#tidb_executor_concurrency-new-in-v50)を調整することで増やすことができます。 -- 逆インデックススキャン +- 逆インデックススキャン TiDBは、昇順インデックスを逆順にスキャンする機能をサポートしていますが、その速度は通常のスキャンよりも20%遅くなります。データが頻繁に変更され、バージョンが多数存在する場合、パフォーマンスのオーバーヘッドが大きくなる可能性があります。逆順インデックススキャンはできる限り避けることをお勧めします。 @@ -211,8 +211,8 @@ TiDB の技術的な詳細に関する記事については、 [PingCAP公式ブ TiDBは、以下のシナリオに適しています。 -- データ量が大きすぎるため、スタンドアロンデータベースでは対応できません。 -- シャーディングはしたくない -- アクセスモードには明らかなホットスポットはありません -- トランザクション、高い一貫性、およびディザスタリカバリが求められます。 -- リアルタイムのハイブリッドトランザクション/分析処理（HTAP）分析を実現し、データパイプラインを削減したいと考えている。 +- データ量が大きすぎるため、スタンドアロンデータベースでは対応できません。 +- シャーディングはしたくない +- アクセスモードには明らかなホットスポットはありません +- トランザクション、高い一貫性、およびディザスタリカバリが求められます。 +- リアルタイムのハイブリッドトランザクション/分析処理（HTAP）分析を実現し、データパイプラインを削減したいと考えている。 diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md index 9d5742b27a7f5..887f9223f7887 100644 --- a/best-practices/tidb-partitioned-tables-best-practices.md +++ b/best-practices/tidb-partitioned-tables-best-practices.md @@ -26,8 +26,8 @@ TiDBのパーティションテーブルは、大規模データセットの管 このセクションでは、次の方法でクエリ効率を向上させる方法について説明します。 -- [パーティションプルーニング](#partition-pruning) -- [セカンダリインデックスのクエリパフォーマンス](#query-performance-on-secondary-indexes-non-partitioned-tables-vs-local-indexes-vs-global-indexes) +- [パーティションプルーニング](#partition-pruning) +- [セカンダリインデックスのクエリパフォーマンス](#query-performance-on-secondary-indexes-non-partitioned-tables-vs-local-indexes-vs-global-indexes) ### パーティションプルーニング {#partition-pruning} @@ -35,9 +35,9 @@ TiDBのパーティションテーブルは、大規模データセットの管 パーティションプルーニングは、クエリ述語がパーティション戦略と一致している場合に最も効果的です。典型的な使用例は次のとおりです。 -- 時系列データ クエリ: データが時間範囲 (たとえば、日次または月次) でパーティション分割されている場合、特定の時間ウィンドウに限定されたクエリでは、関連のないパーティションをすぐにスキップできます。 -- マルチテナントまたはカテゴリベースのデータセット: テナント ID またはカテゴリ別にパーティション分割することで、クエリをパーティションの小さなサブセットに集中させることができます。 -- ハイブリッドトランザクションおよび分析処理（HTAP）：特にレンジパーティショニングにおいて、TiDBはTiFlash上​​の分析ワークロードにパーティションプルーニングを適用できます。この最適化により、無関係なパーティションがスキップされ、大規模なデータセットにおけるテーブル全体のスキャンが回避されます。 +- 時系列データ クエリ: データが時間範囲 (たとえば、日次または月次) でパーティション分割されている場合、特定の時間ウィンドウに限定されたクエリでは、関連のないパーティションをすぐにスキップできます。 +- マルチテナントまたはカテゴリベースのデータセット: テナント ID またはカテゴリ別にパーティション分割することで、クエリをパーティションの小さなサブセットに集中させることができます。 +- ハイブリッドトランザクションおよび分析処理（HTAP）：特にレンジパーティショニングにおいて、TiDBはTiFlash上​​の分析ワークロードにパーティションプルーニングを適用できます。この最適化により、無関係なパーティションがスキップされ、大規模なデータセットにおけるテーブル全体のスキャンが回避されます。 その他の使用例については、 [パーティションプルーニング](/partition-pruning.md)を参照してください。 @@ -51,17 +51,17 @@ TiDBでは、パーティションテーブルはデフォルトでローカル このテストでは、次のテーブル構成間でのクエリ パフォーマンスを比較します。 -- パーティションテーブル -- ローカルインデックスを持つパーティションテーブル -- グローバルインデックスを持つパーティションテーブル +- パーティションテーブル +- ローカルインデックスを持つパーティションテーブル +- グローバルインデックスを持つパーティションテーブル #### テストセットアップ {#test-setup} テストでは次の構成を使用します。 -- パーティションテーブルには、 `date`列で定義された 365 個の範囲パーティションが含まれています。 -- ワークロードは、各インデックス キーが複数の行と一致する大量の OLTP クエリ パターンをシミュレートします。 -- このテストでは、さまざまなパーティション数も評価し、パーティションの粒度がクエリのレイテンシーとインデックスの効率にどのように影響するかを測定します。 +- パーティションテーブルには、 `date`列で定義された 365 個の範囲パーティションが含まれています。 +- ワークロードは、各インデックス キーが複数の行と一致する大量の OLTP クエリ パターンをシミュレートします。 +- このテストでは、さまざまなパーティション数も評価し、パーティションの粒度がクエリのレイテンシーとインデックスの効率にどのように影響するかを測定します。 #### スキーマ {#schema} @@ -106,9 +106,9 @@ WHERE `fa`.`sid` IN ( このクエリ パターンが代表的なものである理由は次のとおりです。 -- パーティション キーのないセカンダリ インデックスをフィルターします。 -- プルーニングが不足しているため、各パーティションのローカル インデックス検索がトリガーされます。 -- パーティション化されたテーブルに対して、大幅に多くのテーブル検索タスクが生成されます。 +- パーティション キーのないセカンダリ インデックスをフィルターします。 +- プルーニングが不足しているため、各パーティションのローカル インデックス検索がトリガーされます。 +- パーティション化されたテーブルに対して、大幅に多くのテーブル検索タスクが生成されます。 #### テスト結果 {#test-results} @@ -120,14 +120,14 @@ WHERE `fa`.`sid` IN ( | ローカルインデックスを持つパーティションテーブル | 108ミリ秒 | 600 | 375 | 975 | | グローバルインデックスを持つパーティションテーブル | 14.8ミリ秒 | 69 | 383 | 452 | -- **非パーティションテーブル**：最小限のタスクで最高のパフォーマンスを提供します。ほとんどのOLTPワークロードに適しています。 -- **グローバル インデックスを持つパーティション テーブル**: インデックス スキャンの効率は向上しますが、多くの行が一致する場合、テーブル検索のコストは依然として高くなります。 -- **ローカル インデックスを持つパーティション テーブル**: クエリ条件にパーティション キーが含まれていない場合、ローカル インデックス クエリはすべてのパーティションをスキャンします。 +- **非パーティションテーブル**：最小限のタスクで最高のパフォーマンスを提供します。ほとんどのOLTPワークロードに適しています。 +- **グローバル インデックスを持つパーティション テーブル**: インデックス スキャンの効率は向上しますが、多くの行が一致する場合、テーブル検索のコストは依然として高くなります。 +- **ローカル インデックスを持つパーティション テーブル**: クエリ条件にパーティション キーが含まれていない場合、ローカル インデックス クエリはすべてのパーティションをスキャンします。 > **Note:** > -> - **平均クエリ時間**は`statement_summary`ビューから取得されます。 -> - **COP タスクの**メトリックは実行計画から派生します。 +> - **平均クエリ時間**は`statement_summary`ビューから取得されます。 +> - **COP タスクの**メトリックは実行計画から派生します。 #### 実行計画の例 {#execution-plan-examples} @@ -175,9 +175,9 @@ WHERE `fa`.`sid` IN ( > **Note:** > -> - TiDB v8.5.3以前のバージョンでは、一意の列に対してのみグローバルインデックスを作成できました。v8.5.4以降では、一意でない列に対してもグローバルインデックスを作成できます。この制限は、将来のLTSバージョンで解除される予定です。 -> - 一意でないグローバル インデックスの場合は、 `ADD UNIQUE INDEX`ではなく`ADD INDEX`を使用します。 -> - `GLOBAL`キーワードを明示的に指定する必要があります。 +> - TiDB v8.5.3以前のバージョンでは、一意の列に対してのみグローバルインデックスを作成できました。v8.5.4以降では、一意でない列に対してもグローバルインデックスを作成できます。この制限は、将来のLTSバージョンで解除される予定です。 +> - 一意でないグローバル インデックスの場合は、 `ADD UNIQUE INDEX`ではなく`ADD INDEX`を使用します。 +> - `GLOBAL`キーワードを明示的に指定する必要があります。 ##### オプション1: `ALTER TABLE`を使用する {#option-1-use-alter-table} @@ -211,18 +211,18 @@ PARTITION BY RANGE (id) ( TiDB パーティション テーブルのパフォーマンス オーバーヘッドは、パーティションの数とインデックスの種類によって異なります。 -- **パーティション数**：パーティション数が増えるとパフォーマンスが低下します。パーティション数が少ない場合は影響は無視できるかもしれませんが、ワークロードによって異なります。 -- **ローカルインデックス**：クエリに有効なパーティションプルーニング条件が含まれていない場合、パーティション数が直接的に[リモート プロシージャ コール (RPC)](https://docs.pingcap.com/tidb/stable/glossary/#remote-procedure-call-rpc)の数を決定します。つまり、パーティション数が増えると、通常、RPCが増加し、レイテンシーが増加します。 -- **グローバルインデックス**：パフォーマンスは、関連するパーティションの数と、テーブル参照を必要とする行数の両方に依存します。データが複数のリージョンに分散されている非常に大きなテーブルの場合、グローバルインデックスを介してデータにアクセスすると、パーティションテーブルと同等のパフォーマンスが得られます。これは、どちらのシナリオでも複数のリージョン間RPCが使用されるためです。 +- **パーティション数**：パーティション数が増えるとパフォーマンスが低下します。パーティション数が少ない場合は影響は無視できるかもしれませんが、ワークロードによって異なります。 +- **ローカルインデックス**：クエリに有効なパーティションプルーニング条件が含まれていない場合、パーティション数が直接的に[リモート プロシージャ コール (RPC)](https://docs.pingcap.com/tidb/stable/glossary/#remote-procedure-call-rpc)の数を決定します。つまり、パーティション数が増えると、通常、RPCが増加し、レイテンシーが増加します。 +- **グローバルインデックス**：パフォーマンスは、関連するパーティションの数と、テーブル参照を必要とする行数の両方に依存します。データが複数のリージョンに分散されている非常に大きなテーブルの場合、グローバルインデックスを介してデータにアクセスすると、パーティションテーブルと同等のパフォーマンスが得られます。これは、どちらのシナリオでも複数のリージョン間RPCが使用されるためです。 #### 推奨事項 {#recommendations} TiDB でパーティション テーブルとインデックスを設計するときは、次のガイドラインに従います。 -- パーティションテーブルは必要な場合にのみ使用してください。ほとんどのOLTPワークロードでは、適切にインデックスが設定されたパーティションテーブルの方がパフォーマンスが向上し、管理が簡単になります。 -- すべてのクエリに、少数のパーティションに一致する有効なパーティション プルーニング条件が含まれている場合は、ローカル インデックスを使用します。 -- 効果的なパーティション プルーニング条件がなく、多数のパーティションに一致する重要なクエリには、グローバル インデックスを使用します。 -- DDL 操作の効率 (高速`DROP PARTITION`など) が優先され、潜在的なパフォーマンスへの影響が許容できる場合にのみ、ローカル インデックスを使用します。 +- パーティションテーブルは必要な場合にのみ使用してください。ほとんどのOLTPワークロードでは、適切にインデックスが設定されたパーティションテーブルの方がパフォーマンスが向上し、管理が簡単になります。 +- すべてのクエリに、少数のパーティションに一致する有効なパーティション プルーニング条件が含まれている場合は、ローカル インデックスを使用します。 +- 効果的なパーティション プルーニング条件がなく、多数のパーティションに一致する重要なクエリには、グローバル インデックスを使用します。 +- DDL 操作の効率 (高速`DROP PARTITION`など) が優先され、潜在的なパフォーマンスへの影響が許容できる場合にのみ、ローカル インデックスを使用します。 ## 一括データ削除を容易にする {#facilitate-bulk-data-deletion} @@ -230,16 +230,16 @@ TiDBでは、 [TTL (存続時間)](/time-to-live.md)を使用するか、パー ### TTLと`DROP PARTITION`の違い {#differences-between-ttl-and-drop-partition} -- TTL: データの経過時間に基づいて自動的にデータを削除します。この方法は、時間の経過とともに行を段階的にスキャンして削除するため、処理速度が低下する可能性があります。 -- `DROP PARTITION` : 1回の操作でパーティション全体を削除します。この方法は、特に大規模なデータセットの場合、通常、はるかに高速です。 +- TTL: データの経過時間に基づいて自動的にデータを削除します。この方法は、時間の経過とともに行を段階的にスキャンして削除するため、処理速度が低下する可能性があります。 +- `DROP PARTITION` : 1回の操作でパーティション全体を削除します。この方法は、特に大規模なデータセットの場合、通常、はるかに高速です。 #### テストケース {#test-case} このテストでは、TTL と`DROP PARTITION`のパフォーマンスを比較します。 -- TTL 構成: 10 分ごとに実行されます。 -- パーティション構成: 10 分ごとに 1 つのパーティションを削除します。 -- ワークロード: 50 および 100 の同時スレッドによるバックグラウンド書き込みワークロード。 +- TTL 構成: 10 分ごとに実行されます。 +- パーティション構成: 10 分ごとに 1 つのパーティションを削除します。 +- ワークロード: 50 および 100 の同時スレッドによるバックグラウンド書き込みワークロード。 テストでは、実行時間、システム リソースの使用量、および削除された行の合計数を測定します。 @@ -251,15 +251,15 @@ TiDBでは、 [TTL (存続時間)](/time-to-live.md)を使用するか、パー TTL パフォーマンスに関する調査結果は次のとおりです。 -- スレッドが 50 個の場合、各 TTL ジョブには 8 ～ 10 分かかり、700 万～ 1,100 万行が削除されます。 -- 100 スレッドの場合、TTL は最大 2,000 万行を処理できますが、実行時間は 15 ～ 30 分に増加し、変動も大きくなります。 -- 負荷が高い場合、TTL ジョブは追加のスキャンと削除のオーバーヘッドにより全体的な QPS を低下させます。 +- スレッドが 50 個の場合、各 TTL ジョブには 8 ～ 10 分かかり、700 万～ 1,100 万行が削除されます。 +- 100 スレッドの場合、TTL は最大 2,000 万行を処理できますが、実行時間は 15 ～ 30 分に増加し、変動も大きくなります。 +- 負荷が高い場合、TTL ジョブは追加のスキャンと削除のオーバーヘッドにより全体的な QPS を低下させます。 `DROP PARTITION`パフォーマンスに関する調査結果は次のとおりです。 -- `ALTER TABLE ... DROP PARTITION`ステートメントは、パーティション全体をほぼ即座に削除します。 -- この操作はメタデータ レベルで実行されるため、最小限のリソースしか使用されません。 -- `DROP PARTITION` 、特に大規模な履歴データセットの場合、TTL よりも高速で予測可能です。 +- `ALTER TABLE ... DROP PARTITION`ステートメントは、パーティション全体をほぼ即座に削除します。 +- この操作はメタデータ レベルで実行されるため、最小限のリソースしか使用されません。 +- `DROP PARTITION` 、特に大規模な履歴データセットの場合、TTL よりも高速で予測可能です。 #### TiDBでTTLと`DROP PARTITION`使用する {#use-ttl-and-drop-partition-in-tidb} @@ -319,8 +319,8 @@ ALTER TABLE ad_cache LAST PARTITION LESS THAN ("${nextTimestamp}"); #### 推奨事項 {#recommendations} -- 大規模なデータクリーンアップや時間ベースのデータクリーンアップには、パーティション分割テーブル（パーティション番号`DROP PARTITION`を使用してください。このアプローチにより、パフォーマンスが向上し、システムへの影響が軽減され、操作が簡素化されます。 -- きめ細かいデータクリーンアップやバックグラウンドデータクリーンアップにはTTLを使用してください。TTLは、書き込みスループットが高いワークロードや、大量のデータを迅速に削除するワークロードには適していません。 +- 大規模なデータクリーンアップや時間ベースのデータクリーンアップには、パーティション分割テーブル（パーティション番号`DROP PARTITION`を使用してください。このアプローチにより、パフォーマンスが向上し、システムへの影響が軽減され、操作が簡素化されます。 +- きめ細かいデータクリーンアップやバックグラウンドデータクリーンアップにはTTLを使用してください。TTLは、書き込みスループットが高いワークロードや、大量のデータを迅速に削除するワークロードには適していません。 ### パーティション削除の効率: ローカルインデックスとグローバルインデックス {#partition-drop-efficiency-local-indexes-vs-global-indexes} @@ -349,21 +349,21 @@ ALTER TABLE A DROP PARTITION A_2024363; #### 推奨事項 {#recommendations} -- パーティションテーブルでグローバル インデックスが使用される場合、 `DROP PARTITION` 、 `TRUNCATE PARTITION` 、 `REORGANIZE PARTITION`などの DDL 操作の実行時間が長くなることが予想されます。 -- パーティションを頻繁に削除し、パフォーマンスへの影響を最小限に抑える必要がある場合は、ローカル インデックスを使用して、より高速で効率的なパーティション管理を実現します。 +- パーティションテーブルでグローバル インデックスが使用される場合、 `DROP PARTITION` 、 `TRUNCATE PARTITION` 、 `REORGANIZE PARTITION`などの DDL 操作の実行時間が長くなることが予想されます。 +- パーティションを頻繁に削除し、パフォーマンスへの影響を最小限に抑える必要がある場合は、ローカル インデックスを使用して、より高速で効率的なパーティション管理を実現します。 ## ホットスポットの問題を軽減する {#mitigate-hotspot-issues} TiDB では、読み取りまたは書き込みトラフィックが[リージョン](/tidb-storage.md#region)に不均等に分散されている場合にホットスポットが発生します。ホットスポットは、次のような場合によく発生します。 -- 単調に増加する主キー ( `AUTO_INCREMENT`主キーと`AUTO_ID_CACHE=1`など)。 -- デフォルト値が`CURRENT_TIMESTAMP`である datetime 列のセカンダリ インデックス。 +- 単調に増加する主キー ( `AUTO_INCREMENT`主キーと`AUTO_ID_CACHE=1`など)。 +- デフォルト値が`CURRENT_TIMESTAMP`である datetime 列のセカンダリ インデックス。 TiDBは新しい行とインデックスエントリを「右端」のリージョンに追加します。時間が経つにつれて、この動作は次のような問題を引き起こす可能性があります。 -- 単一のリージョンが書き込みワークロードの大部分を処理し、他のリージョンは十分に活用されないままになります。 -- 読み取りおよび書き込みのレイテンシーが増加し、全体的なスループットが低下します。 -- TiKV ノードを追加しても、ボトルネックが単一のリージョンに残るため、パフォーマンスはほとんど向上しません。 +- 単一のリージョンが書き込みワークロードの大部分を処理し、他のリージョンは十分に活用されないままになります。 +- 読み取りおよび書き込みのレイテンシーが増加し、全体的なスループットが低下します。 +- TiKV ノードを追加しても、ボトルネックが単一のリージョンに残るため、パフォーマンスはほとんど向上しません。 これらの問題を軽減するには、パーティションテーブルを使用できます。主キーにハッシュまたはキーによるパーティション分割を適用することで、TiDB は挿入操作を複数のパーティションとリージョンに分散し、単一のリージョンにおけるホットスポットの競合を軽減します。 @@ -383,9 +383,9 @@ TiDBはテーブルデータとインデックスをリージョンに保存し **ハッシュまたはキーでパーティション分割されたテーブル** -- TiDB は、主キーまたはインデックス列にハッシュ関数またはキー関数を適用して、テーブルとそのインデックスを複数のパーティションに分割します。 -- 各パーティションには独自のリージョン セットがあり、通常は異なる TiKV ノードに分散されます。 -- 挿入操作は複数のリージョンに並行して分散され、ワー​​クロードのバランスと書き込みスループットが向上します。 +- TiDB は、主キーまたはインデックス列にハッシュ関数またはキー関数を適用して、テーブルとそのインデックスを複数のパーティションに分割します。 +- 各パーティションには独自のリージョン セットがあり、通常は異なる TiKV ノードに分散されます。 +- 挿入操作は複数のリージョンに並行して分散され、ワー​​クロードのバランスと書き込みスループットが向上します。 ### パーティショニングを使用する場合 {#when-to-use-partitioning} @@ -411,16 +411,16 @@ PARTITION BY KEY (id) PARTITIONS 16; パーティション化されたテーブルには次のような利点があります。 -- **バランスの取れた書き込みワークロード**: ホットスポットが複数のパーティションとリージョンに分散され、競合が軽減され、挿入パフォーマンスが向上します。 -- **パーティション プルーニングによるクエリ パフォーマンスの向上**: パーティション キーでフィルターするクエリの場合、TiDB は無関係なパーティションをスキップし、スキャンされるデータを削減して、クエリのレイテンシーを改善します。 +- **バランスの取れた書き込みワークロード**: ホットスポットが複数のパーティションとリージョンに分散され、競合が軽減され、挿入パフォーマンスが向上します。 +- **パーティション プルーニングによるクエリ パフォーマンスの向上**: パーティション キーでフィルターするクエリの場合、TiDB は無関係なパーティションをスキップし、スキャンされるデータを削減して、クエリのレイテンシーを改善します。 ### 制限事項 {#limitations} パーティション テーブルを使用する前に、次の制限を考慮してください。 -- パーティションテーブルをパーティションテーブルに変換すると、TiDB によってパーティションごとに個別のリージョンが作成されるため、リージョンの合計数が増加します。 +- パーティションテーブルをパーティションテーブルに変換すると、TiDB によってパーティションごとに個別のリージョンが作成されるため、リージョンの合計数が増加します。 -- パーティションキーでフィルタリングしないクエリでは、パーティションプルーニングを使用できません。TiDBはすべてのパーティションをスキャンするか、すべてのパーティションにわたってインデックス検索を実行する必要があるため、コプロセッサタスクの数が増加し、パフォーマンスが低下する可能性があります。 +- パーティションキーでフィルタリングしないクエリでは、パーティションプルーニングを使用できません。TiDBはすべてのパーティションをスキャンするか、すべてのパーティションにわたってインデックス検索を実行する必要があるため、コプロセッサタスクの数が増加し、パフォーマンスが低下する可能性があります。 たとえば、次のクエリではパーティション キー ( `id` ) が使用されていないため、パフォーマンスが低下する可能性があります。 @@ -428,7 +428,7 @@ PARTITION BY KEY (id) PARTITIONS 16; SELECT * FROM server_info WHERE `serial_no` = ?; ``` -- パーティションキーを使用しないクエリのスキャンオーバーヘッドを削減するには、グローバルインデックスを作成する必要があります。グローバルインデックスは`DROP PARTITION`操作を遅くする可能性がありますが、ハッシュおよびキーパーティションテーブルは`DROP PARTITION`サポートしていません。したがって、これらのパーティションはほとんど切り捨てられないため、グローバルインデックスは実用的なソリューションです。例： +- パーティションキーを使用しないクエリのスキャンオーバーヘッドを削減するには、グローバルインデックスを作成する必要があります。グローバルインデックスは`DROP PARTITION`操作を遅くする可能性がありますが、ハッシュおよびキーパーティションテーブルは`DROP PARTITION`サポートしていません。したがって、これらのパーティションはほとんど切り捨てられないため、グローバルインデックスは実用的なソリューションです。例： ```sql ALTER TABLE server_info ADD UNIQUE INDEX(serial_no, id) GLOBAL; @@ -478,8 +478,8 @@ TiDBでは、新しく作成されたパーティションは、最初は1つの #### 利点 {#advantages} -- [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)と[`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions)で構成された非クラスター化パーティションテーブルに新しいパーティションを作成すると、TiDB によってリージョンが自動的に事前分割され、手作業の労力が大幅に削減されます。 -- 運用オーバーヘッドは低いです。 +- [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)と[`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions)で構成された非クラスター化パーティションテーブルに新しいパーティションを作成すると、TiDB によってリージョンが自動的に事前分割され、手作業の労力が大幅に削減されます。 +- 運用オーバーヘッドは低いです。 #### デメリット {#disadvantages} @@ -499,8 +499,8 @@ TiDBでは、新しく作成されたパーティションは、最初は1つの **要件：** -- `PRE_SPLIT_REGIONS`の値は`SHARD_ROW_ID_BITS`以下でなければなりません。 -- 各パーティションは`2^(PRE_SPLIT_REGIONS)`リージョンに事前に分割されます。 +- `PRE_SPLIT_REGIONS`の値は`SHARD_ROW_ID_BITS`以下でなければなりません。 +- 各パーティションは`2^(PRE_SPLIT_REGIONS)`リージョンに事前に分割されます。 ```sql CREATE TABLE employees ( @@ -543,9 +543,9 @@ ALTER TABLE employees PARTITION `p3` ATTRIBUTES 'merge_option=deny'; SELECT MIN(id), MAX(id) FROM employees; ``` -- テーブルに履歴データがない場合、ビジネス要件と予想されるデータ範囲に基づいて最小値と最大値を推定します。 -- 複合主キーまたは複合インデックスの場合は、分割境界を定義するために左端の列のみを使用します。 -- 左端の列が文字列の場合は、データが均等に分散されるように、その長さと値の分散を考慮してください。 +- テーブルに履歴データがない場合、ビジネス要件と予想されるデータ範囲に基づいて最小値と最大値を推定します。 +- 複合主キーまたは複合インデックスの場合は、分割境界を定義するために左端の列のみを使用します。 +- 左端の列が文字列の場合は、データが均等に分散されるように、その長さと値の分散を考慮してください。 ##### ステップ4. リージョンを事前に分割して散布する {#step-4-pre-split-and-scatter-regions} @@ -605,8 +605,8 @@ SHOW TABLE employees PARTITION (p4) regions; #### 利点 {#advantages} -- 新しい範囲パーティションによるホットスポットのリスクはありません。 -- ポイントおよび範囲クエリの読み取りパフォーマンスが良好です。 +- 新しい範囲パーティションによるホットスポットのリスクはありません。 +- ポイントおよび範囲クエリの読み取りパフォーマンスが良好です。 #### デメリット {#disadvantages} @@ -620,9 +620,9 @@ SHOW TABLE employees PARTITION (p4) regions; 1億2000万行のような大規模なテーブルでは、パフォーマンスチューニングやスキーマの再設計のために、パーティション化されたスキーマとパーティション化されていないスキーマ間の変換が必要になる場合があります。TiDBは以下のアプローチをサポートしています。 -- [パイプラインDML](/pipelined-dml.md) : `INSERT INTO ... SELECT ...` -- [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) : `IMPORT INTO ... FROM SELECT ...` -- [オンラインDDL](/dm/feature-online-ddl.md) : `ALTER TABLE`を使用した直接スキーマ変換 +- [パイプラインDML](/pipelined-dml.md) : `INSERT INTO ... SELECT ...` +- [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) : `IMPORT INTO ... FROM SELECT ...` +- [オンラインDDL](/dm/feature-online-ddl.md) : `ALTER TABLE`を使用した直接スキーマ変換 このセクションでは、両方の変換方向についてこれらの方法の効率と影響を比較し、ベスト プラクティスの推奨事項を示します。 diff --git a/best-practices/uuid.md b/best-practices/uuid.md index aadbbd5c6be80..1435d53d2ecd4 100644 --- a/best-practices/uuid.md +++ b/best-practices/uuid.md @@ -12,9 +12,9 @@ UUID（Universally Unique Identifiers）は、分散データベースにおけ UUID を主キーとして使用すると、 [`AUTO_INCREMENT`](/auto-increment.md)整数と比較して次の利点があります。 -- UUIDは複数のシステムで競合のリスクなく生成できます。場合によっては、TiDBへのネットワーク通信回数を削減し、パフォーマンスを向上させることができます。 -- UUID は、ほとんどのプログラミング言語とデータベース システムでサポートされています。 -- URLの一部として使用される場合、UUIDは列挙攻撃に対して脆弱ではありません。一方、 `AUTO_INCREMENT`数字を使用すると、請求書IDやユーザーIDを推測される可能性があります。 +- UUIDは複数のシステムで競合のリスクなく生成できます。場合によっては、TiDBへのネットワーク通信回数を削減し、パフォーマンスを向上させることができます。 +- UUID は、ほとんどのプログラミング言語とデータベース システムでサポートされています。 +- URLの一部として使用される場合、UUIDは列挙攻撃に対して脆弱ではありません。一方、 `AUTO_INCREMENT`数字を使用すると、請求書IDやユーザーIDを推測される可能性があります。 ## ベストプラクティス {#best-practices} @@ -56,8 +56,8 @@ CREATE TABLE `uuid_demo_2` ( Key Visualizer の詳細については、次のドキュメントを参照してください。 -- TiDB Self-Managedの場合は[Key Visualizer](/dashboard/dashboard-key-visualizer.md) -- TiDB Cloudの場合は[Key Visualizer](/tidb-cloud/tune-performance.md#key-visualizer) +- TiDB Self-Managedの場合は[Key Visualizer](/dashboard/dashboard-key-visualizer.md) +- TiDB Cloudの場合は[Key Visualizer](/tidb-cloud/tune-performance.md#key-visualizer) ## MySQLとの互換性 {#mysql-compatibility} diff --git a/blocklist-control-plan.md b/blocklist-control-plan.md index cb8890f74900c..d1c0ab4b48383 100644 --- a/blocklist-control-plan.md +++ b/blocklist-control-plan.md @@ -38,7 +38,7 @@ summary: 最適化ルールと式プッシュダウンの動作を制御する > > 以下のすべての操作には、データベースの`super privilege`権限が必要です。各最適化ルールには名前が付けられています。例えば、列プルーニングの名前は`column_prune`です。すべての最適化ルールの名前は、表[重要な最適化ルール](#important-optimization-rules)の2列目に記載されています。 -- 特定のルールを無効にしたい場合は、そのルール名を`mysql.opt_rule_blacklist`テーブルに記述します。例： +- 特定のルールを無効にしたい場合は、そのルール名を`mysql.opt_rule_blacklist`テーブルに記述します。例： ```sql INSERT INTO mysql.opt_rule_blacklist VALUES("join_reorder"), ("topn_push_down"); @@ -54,7 +54,7 @@ summary: 最適化ルールと式プッシュダウンの動作を制御する > > `admin reload opt_rule_blacklist`は、上記のステートメントを実行した TiDBサーバーにのみ有効になります。クラスター内のすべての TiDB サーバーに有効にしたい場合は、各 TiDBサーバーでこのコマンドを実行してください。 -- ルールを再度有効にする場合は、テーブル内の対応するデータを削除してから、 `admin reload`ステートメントを実行します。 +- ルールを再度有効にする場合は、テーブル内の対応するデータを削除してから、 `admin reload`ステートメントを実行します。 ```sql DELETE FROM mysql.opt_rule_blacklist WHERE name IN ("join_reorder", "topn_push_down"); @@ -95,12 +95,12 @@ DESC mysql.expr_pushdown_blacklist; 上記の各フィールドの説明は次のとおりです。 -- `name` : プッシュダウンが無効になっている関数の名前。 -- `store_type` : 関数の計算時にプッシュダウンされないようにするコンポーネントを指定します。指定できる要素は`tidb` 、 `tikv` 、 `tiflash`です。`store_type`は大文字と小文字を区別しません。複数の要素を指定する必要がある場合は、各コンポーネントをカンマで区切ってください。 - - `store_type`が`tidb`の場合、TiDBメモリテーブルの読み取り中に他の TiDB サーバーで関数を実行できるかどうかを示します。 - - `store_type`が`tikv`の場合、関数が TiKV サーバーのコプロセッサーコンポーネントで実行できるかどうかを示します。 - - `store_type`が`tiflash`の場合、関数がTiFlash Server のコプロセッサーコンポーネントで実行できるかどうかを示します。 -- `reason` : この関数がブロックリストに追加された理由を記録します。 +- `name` : プッシュダウンが無効になっている関数の名前。 +- `store_type` : 関数の計算時にプッシュダウンされないようにするコンポーネントを指定します。指定できる要素は`tidb` 、 `tikv` 、 `tiflash`です。`store_type`は大文字と小文字を区別しません。複数の要素を指定する必要がある場合は、各コンポーネントをカンマで区切ってください。 + - `store_type`が`tidb`の場合、TiDBメモリテーブルの読み取り中に他の TiDB サーバーで関数を実行できるかどうかを示します。 + - `store_type`が`tikv`の場合、関数が TiKV サーバーのコプロセッサーコンポーネントで実行できるかどうかを示します。 + - `store_type`が`tiflash`の場合、関数がTiFlash Server のコプロセッサーコンポーネントで実行できるかどうかを示します。 +- `reason` : この関数がブロックリストに追加された理由を記録します。 ### 使用法 {#usage} @@ -110,17 +110,17 @@ DESC mysql.expr_pushdown_blacklist; ブロックリストに 1 つ以上の式 (関数または演算子) を追加するには、次の手順を実行します。 -1. 対応する関数名または演算子名と、プッシュダウンを無効にするコンポーネントのセットを`mysql.expr_pushdown_blacklist`テーブルに挿入します。 +1. 対応する関数名または演算子名と、プッシュダウンを無効にするコンポーネントのセットを`mysql.expr_pushdown_blacklist`テーブルに挿入します。 -2. `admin reload expr_pushdown_blacklist`を実行します。 +2. `admin reload expr_pushdown_blacklist`を実行します。 ### ブロックリストから削除 {#remove-from-the-blocklist} ブロックリストから 1 つ以上の式を削除するには、次の手順を実行します。 -1. 対応する関数名または演算子名、およびプッシュダウンを無効にするコンポーネントのセットを`mysql.expr_pushdown_blacklist`テーブルから削除します。 +1. 対応する関数名または演算子名、およびプッシュダウンを無効にするコンポーネントのセットを`mysql.expr_pushdown_blacklist`テーブルから削除します。 -2. `admin reload expr_pushdown_blacklist`を実行します。 +2. `admin reload expr_pushdown_blacklist`を実行します。 > **Note:** > @@ -132,7 +132,7 @@ DESC mysql.expr_pushdown_blacklist; ブロックリストが有効になっているかどうかを判断するには、 `EXPLAIN`の結果を観察します（ [TiDB クエリ実行計画の概要](/explain-overview.md)を参照）。 -1. 次の SQL ステートメントの`WHERE`句の述語`a < 2`と`a > 2` 、TiKV にプッシュダウンできます。 +1. 次の SQL ステートメントの`WHERE`句の述語`a < 2`と`a > 2` 、TiKV にプッシュダウンできます。 ```sql EXPLAIN SELECT * FROM t WHERE a < 2 AND a > 2; @@ -149,7 +149,7 @@ DESC mysql.expr_pushdown_blacklist; 3 rows in set (0.00 sec) ``` -2. 式を`mysql.expr_pushdown_blacklist`テーブルに挿入し、 `admin reload expr_pushdown_blacklist`を実行します。 +2. 式を`mysql.expr_pushdown_blacklist`テーブルに挿入し、 `admin reload expr_pushdown_blacklist`を実行します。 ```sql INSERT INTO mysql.expr_pushdown_blacklist VALUES('<','tikv',''), ('>','tikv',''); @@ -168,7 +168,7 @@ DESC mysql.expr_pushdown_blacklist; Query OK, 0 rows affected (0.00 sec) ``` -3. 実行計画をもう一度観察すると、演算子`<`と`>`両方が TiKVコプロセッサーにプッシュダウンされていないことがわかります。 +3. 実行計画をもう一度観察すると、演算子`<`と`>`両方が TiKVコプロセッサーにプッシュダウンされていないことがわかります。 ```sql EXPLAIN SELECT * FROM t WHERE a < 2 and a > 2; @@ -185,7 +185,7 @@ DESC mysql.expr_pushdown_blacklist; 3 rows in set (0.00 sec) ``` -4. ブロックリストから 1 つの式 (ここでは`>` ) を削除し、 `admin reload expr_pushdown_blacklist`を実行します。 +4. ブロックリストから 1 つの式 (ここでは`>` ) を削除し、 `admin reload expr_pushdown_blacklist`を実行します。 ```sql DELETE FROM mysql.expr_pushdown_blacklist WHERE name = '>'; @@ -203,7 +203,7 @@ DESC mysql.expr_pushdown_blacklist; Query OK, 0 rows affected (0.00 sec) ``` -5. 実行計画をもう一度観察すると、 `<`プッシュダウンされていないのに対し、 `>` TiKVコプロセッサーにプッシュダウンされていることがわかります。 +5. 実行計画をもう一度観察すると、 `<`プッシュダウンされていないのに対し、 `>` TiKVコプロセッサーにプッシュダウンされていることがわかります。 ```sql EXPLAIN SELECT * FROM t WHERE a < 2 AND a > 2; diff --git a/br/backup-and-restore-design.md b/br/backup-and-restore-design.md index d09f24bce8873..082c34904efb4 100644 --- a/br/backup-and-restore-design.md +++ b/br/backup-and-restore-design.md @@ -9,15 +9,15 @@ summary: TiDBは、Backup & Restore（BR）とTiDB Operatorを使用したクラ 各バックアップおよび復元機能のアーキテクチャの詳細については、次のドキュメントを参照してください。 -- 完全なデータのバックアップと復元 +- 完全なデータのバックアップと復元 - - [スナップショットデータをバックアップする](/br/br-snapshot-architecture.md#process-of-backup) - - [スナップショットバックアップデータを復元する](/br/br-snapshot-architecture.md#process-of-restore) + - [スナップショットデータをバックアップする](/br/br-snapshot-architecture.md#process-of-backup) + - [スナップショットバックアップデータを復元する](/br/br-snapshot-architecture.md#process-of-restore) -- データ変更ログのバックアップ +- データ変更ログのバックアップ - - [ログバックアップ: KVデータの変更のバックアップ](/br/br-log-architecture.md#process-of-log-backup) + - [ログバックアップ: KVデータの変更のバックアップ](/br/br-log-architecture.md#process-of-log-backup) -- ポイントインタイムリカバリ（PITR） +- ポイントインタイムリカバリ（PITR） - - [PITR](/br/br-log-architecture.md#process-of-pitr) + - [PITR](/br/br-log-architecture.md#process-of-pitr) diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index 65f5c888ed0ca..bf33041af357b 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -9,10 +9,10 @@ TiDBは、 Raftプロトコルと適切なデプロイメントトポロジー BRは以下の要件を満たしています。 -- クラスターデータを最短5分のRPO（目標復旧時点）でディザスタリカバリ（DR）システムにバックアップすることで、災害発生時のデータ損失を軽減します。 -- アプリケーションの動作不良が発生した場合は、エラー発生前の時点までデータをロールバックすることで対処します。 -- 司法監督の要件を満たすために、履歴データの監査を実施する。 -- 本番環境を複製することで、トラブルシューティング、パフォーマンスチューニング、シミュレーションテストに便利になります。 +- クラスターデータを最短5分のRPO（目標復旧時点）でディザスタリカバリ（DR）システムにバックアップすることで、災害発生時のデータ損失を軽減します。 +- アプリケーションの動作不良が発生した場合は、エラー発生前の時点までデータをロールバックすることで対処します。 +- 司法監督の要件を満たすために、履歴データの監査を実施する。 +- 本番環境を複製することで、トラブルシューティング、パフォーマンスチューニング、シミュレーションテストに便利になります。 ## 使用する前に {#before-you-use} @@ -20,27 +20,27 @@ BRは以下の要件を満たしています。 ### 制限 {#restrictions} -- PITRは、**空のクラスター**へのデータ復元のみをサポートしています。 -- PITRは、システムテーブルからユーザーテーブルまたは権限テーブルのデータを復元することをサポートしていません。 -- BRは、クラスター上で複数のバックアップタスクを**同時に**実行することをサポートしていません。 -- 復元中のテーブルをバックアップすることは推奨されません。バックアップされたデータに問題が発生する可能性があるためです。 -- PITRを使用してクラスタを復元する場合、ログバックアップタスクを実行したり、TiCDCを使用してデータをダウンストリームクラスタにレプリケートしたりすることはできません。 +- PITRは、**空のクラスター**へのデータ復元のみをサポートしています。 +- PITRは、システムテーブルからユーザーテーブルまたは権限テーブルのデータを復元することをサポートしていません。 +- BRは、クラスター上で複数のバックアップタスクを**同時に**実行することをサポートしていません。 +- 復元中のテーブルをバックアップすることは推奨されません。バックアップされたデータに問題が発生する可能性があるためです。 +- PITRを使用してクラスタを復元する場合、ログバックアップタスクを実行したり、TiCDCを使用してデータをダウンストリームクラスタにレプリケートしたりすることはできません。 ### いくつかのヒント {#some-tips} スナップショットバックアップ: -- アプリケーションへの影響を最小限に抑えるため、バックアップ作業はピーク時以外の時間帯に行うことをお勧めします。 -- 複数のバックアップまたはリストアタスクは、一つずつ実行することをお勧めします。複数のバックアップタスクを並行して実行すると、パフォーマンスが低下します。さらに悪いことに、複数のタスク間の連携が不足すると、タスクの失敗やクラスタのパフォーマンス低下につながる可能性があります。 +- アプリケーションへの影響を最小限に抑えるため、バックアップ作業はピーク時以外の時間帯に行うことをお勧めします。 +- 複数のバックアップまたはリストアタスクは、一つずつ実行することをお勧めします。複数のバックアップタスクを並行して実行すると、パフォーマンスが低下します。さらに悪いことに、複数のタスク間の連携が不足すると、タスクの失敗やクラスタのパフォーマンス低下につながる可能性があります。 スナップショット復元: -- BRはターゲットクラスターのリソースを最大限に活用します。そのため、新しいクラスターまたはオフラインのクラスターにデータを復元することをお勧めします。本番のクラスターにデータを復元することは避けてください。そうしないと、アプリケーションに必ず影響が出ます。 +- BRはターゲットクラスターのリソースを最大限に活用します。そのため、新しいクラスターまたはオフラインのクラスターにデータを復元することをお勧めします。本番のクラスターにデータを復元することは避けてください。そうしないと、アプリケーションに必ず影響が出ます。 バックアップストレージとネットワーク構成： -- バックアップデータは、Amazon S3、GCS、またはAzure Blob Storageと互換性のあるストレージシステムに保存することをお勧めします。 -- BR、TiKV、およびバックアップストレージシステムに十分なネットワーク帯域幅があり、バックアップストレージシステムが十分な読み取り/書き込み性能（IOPS）を提供できることを確認する必要があります。そうでない場合、バックアップおよびリストア時にパフォーマンスのボトルネックになる可能性があります。 +- バックアップデータは、Amazon S3、GCS、またはAzure Blob Storageと互換性のあるストレージシステムに保存することをお勧めします。 +- BR、TiKV、およびバックアップストレージシステムに十分なネットワーク帯域幅があり、バックアップストレージシステムが十分な読み取り/書き込み性能（IOPS）を提供できることを確認する必要があります。そうでない場合、バックアップおよびリストア時にパフォーマンスのボトルネックになる可能性があります。 ## バックアップと復元を使用する {#use-backup-and-restore} @@ -48,59 +48,59 @@ BRの使用方法は、TiDBの導入方法によって異なります。この 他の導入シナリオでこの機能を使用する方法については、以下のドキュメントを参照してください。 -- [TiDB CloudにデプロイされたTiDBのバックアップと復元](https://docs.pingcap.com/tidbcloud/backup-and-restore):[TiDB Cloud](https://www.pingcap.com/tidb-cloud/?from=en)上に TiDB クラスターを作成することをお勧めします。 TiDB Cloud は、アプリケーションに集中できるようにするフルマネージド データベースを提供します。 -- [TiDB Operatorを使用してデータをバックアップおよび復元する](https://docs.pingcap.com/tidb-in-kubernetes/stable/backup-restore-overview): Kubernetes 上でTiDB Operator を使用して TiDB クラスターをデプロイする場合は、Kubernetes CustomResourceDefinition (CRD) を使用してデータをバックアップおよび復元することをお勧めします。 +- [TiDB CloudにデプロイされたTiDBのバックアップと復元](https://docs.pingcap.com/tidbcloud/backup-and-restore):[TiDB Cloud](https://www.pingcap.com/tidb-cloud/?from=en)上に TiDB クラスターを作成することをお勧めします。 TiDB Cloud は、アプリケーションに集中できるようにするフルマネージド データベースを提供します。 +- [TiDB Operatorを使用してデータをバックアップおよび復元する](https://docs.pingcap.com/tidb-in-kubernetes/stable/backup-restore-overview): Kubernetes 上でTiDB Operator を使用して TiDB クラスターをデプロイする場合は、Kubernetes CustomResourceDefinition (CRD) を使用してデータをバックアップおよび復元することをお勧めします。 ## BR機能 {#br-features} TiDB BRは以下の機能を提供します。 -- クラスタデータのバックアップ: 特定の時点におけるクラスタの完全なデータ (**フルバックアップ**) をバックアップすることも、TiDB のデータ変更 (**ログバックアップ**、ここでログとは TiKV の KV の変更を意味します) をバックアップすることもできます。 +- クラスタデータのバックアップ: 特定の時点におけるクラスタの完全なデータ (**フルバックアップ**) をバックアップすることも、TiDB のデータ変更 (**ログバックアップ**、ここでログとは TiKV の KV の変更を意味します) をバックアップすることもできます。 -- バックアップデータを復元する： +- バックアップデータを復元する： - - **完全バックアップを復元すること**も、完全バックアップ内の**特定のデータベースやテーブル**を復元することもできます。 - - バックアップデータ（フルバックアップとログバックアップ）に基づいて、対象クラスターをバックアップクラスターの任意の時点に復元できます。このタイプの復元は、ポイントインタイムリカバリ（略してPITR）と呼ばれます。 + - **完全バックアップを復元すること**も、完全バックアップ内の**特定のデータベースやテーブル**を復元することもできます。 + - バックアップデータ（フルバックアップとログバックアップ）に基づいて、対象クラスターをバックアップクラスターの任意の時点に復元できます。このタイプの復元は、ポイントインタイムリカバリ（略してPITR）と呼ばれます。 ### クラスターデータのバックアップ {#back-up-cluster-data} フルバックアップは、特定の時点におけるクラスタのすべてのデータをバックアップします。TiDBは、以下のフルバックアップ方法をサポートしています。 -- クラスターのスナップショットをバックアップする: TiDB クラスターのスナップショットには、特定の時点でのトランザクション的に一貫したデータが含まれています。詳細については、 [スナップショットバックアップ](/br/br-snapshot-guide.md#back-up-cluster-snapshots)を参照してください。 +- クラスターのスナップショットをバックアップする: TiDB クラスターのスナップショットには、特定の時点でのトランザクション的に一貫したデータが含まれています。詳細については、 [スナップショットバックアップ](/br/br-snapshot-guide.md#back-up-cluster-snapshots)を参照してください。 フルバックアップは多くのストレージ容量を消費し、特定の時点のクラスタデータのみを含みます。必要に応じて復元ポイントを選択する、つまりポイントインタイムリカバリ（PITR）を実行する場合は、以下の2つのバックアップ方法を同時に使用できます。 -- [ログバックアップ](/br/br-pitr-guide.md#start-log-backup)バックアップが開始されると、タスクはすべてのTiKVノードで実行され続け、TiDBの増分データを定期的に小バッチで指定されたストレージにバックアップします。 -- 定期的にスナップショットバックアップを実行してください。クラスタ全体のデータをバックアップストレージにバックアップします。例えば、毎日午前0時にクラスタのスナップショットバックアップを実行します。 +- [ログバックアップ](/br/br-pitr-guide.md#start-log-backup)バックアップが開始されると、タスクはすべてのTiKVノードで実行され続け、TiDBの増分データを定期的に小バッチで指定されたストレージにバックアップします。 +- 定期的にスナップショットバックアップを実行してください。クラスタ全体のデータをバックアップストレージにバックアップします。例えば、毎日午前0時にクラスタのスナップショットバックアップを実行します。 #### バックアップのパフォーマンスと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)を参照してください。 -- ログバックアップタスクのみの場合、クラスタへの影響は約5%です。ログバックアップは、3～5分ごとに最後の更新後に生成されたすべての変更をバックアップストレージにフラッシュするため、**最短5分のリカバリポイント目標（RPO）を実現できます**。 +- クラスタの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} バックアップ機能に対応して、完全復元とPITRの2種類の復元を実行できます。 -- フルバックアップを復元する +- フルバックアップを復元する - - クラスターのスナップショット バックアップの復元: スナップショット バックアップ データを、空のクラスター、またはデータの競合がないクラスター (同じスキーマまたはテーブルを持つ) に復元できます。詳細については、 [スナップショットバックアップを復元する](/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） +- 任意の時点へのデータ復元（PITR） - - `br restore point`コマンドを実行すると、リカバリ時点より前の最新のスナップショットバックアップデータを復元し、指​​定した時点までのバックアップデータをログに記録できます。BRは復元範囲を自動的に判断し、バックアップデータにアクセスして、ターゲットクラスタにデータを復元します。 + - `br restore point`コマンドを実行すると、リカバリ時点より前の最新のスナップショットバックアップデータを復元し、指​​定した時点までのバックアップデータをログに記録できます。BRは復元範囲を自動的に判断し、バックアップデータにアクセスして、ターゲットクラスタにデータを復元します。 #### TiDBクラスターのパフォーマンスと影響を回復する {#restore-performance-and-impact-on-tidb-clusters} -- データの復元はスケーラブルな速度で実行されます。通常、速度は TiKV ノードあたり 1 GiB/秒です。詳細については、 [パフォーマンスとインパクトを回復](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-restore)をご覧ください。 -- 各 TiKV ノードでは、PITR は 30 GiB/h でログ データを復元できます。詳細については、 [PITRのパフォーマンスと影響](/br/br-pitr-guide.md#performance-capabilities-of-pitr)ご覧ください。 +- データの復元はスケーラブルな速度で実行されます。通常、速度は TiKV ノードあたり 1 GiB/秒です。詳細については、 [パフォーマンスとインパクトを回復](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-restore)をご覧ください。 +- 各 TiKV ノードでは、PITR は 30 GiB/h でログ データを復元できます。詳細については、 [PITRのパフォーマンスと影響](/br/br-pitr-guide.md#performance-capabilities-of-pitr)ご覧ください。 ## バックアップストレージ {#backup-storage} TiDBは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、NFS、およびその他のS3互換ファイルストレージサービスへのデータバックアップをサポートしています。詳細については、以下のドキュメントを参照してください。 -- [URIでバックアップストレージを指定します](/external-storage-uri.md) -- [バックアップストレージへのアクセス権限を設定する](/br/backup-and-restore-storages.md#authentication) +- [URIでバックアップストレージを指定します](/external-storage-uri.md) +- [バックアップストレージへのアクセス権限を設定する](/br/backup-and-restore-storages.md#authentication) ## 互換性 {#compatibility} @@ -143,8 +143,8 @@ TiDB v6.6.0より前のBRの互換性情報は以下のとおりです。 > **Note:** > -> - 既知の問題：v7.2.0以降、新規作成されたクラスタの一部のシステムテーブルフィールドは、大文字と小文字を区別しなくなります。ただし、v7.2.0より前のバージョンからv7.2.0以降に**オンラインでアップグレードされ**たクラスタの場合、対応するシステムテーブルフィールドは引き続き大文字と小文字を区別します。これら2種類のクラスタ間でシステムテーブルを含むバックアップおよびリストア操作を行うと、失敗する可能性があります。詳細については、 [問題番号43717](https://github.com/pingcap/tidb/issues/43717)を参照してください。 -> - バージョン8.5.5以降、 BRは`--sys-check-collation`パラメータを使用してシステムテーブルを復元する際に、照合順序の互換性チェックをサポートするようになりました。復元中、 BRはターゲットクラスタ照合順序で大文字小文字の競合が存在するかどうかを確認します。データがターゲット照合順序と互換性がある場合、 BRは以前のバージョンからのバックアップを正常に復元できます。そうでない場合、 BRはエラーを報告して復元を終了します。 +> - 既知の問題：v7.2.0以降、新規作成されたクラスタの一部のシステムテーブルフィールドは、大文字と小文字を区別しなくなります。ただし、v7.2.0より前のバージョンからv7.2.0以降に**オンラインでアップグレードされ**たクラスタの場合、対応するシステムテーブルフィールドは引き続き大文字と小文字を区別します。これら2種類のクラスタ間でシステムテーブルを含むバックアップおよびリストア操作を行うと、失敗する可能性があります。詳細については、 [問題番号43717](https://github.com/pingcap/tidb/issues/43717)を参照してください。 +> - バージョン8.5.5以降、 BRは`--sys-check-collation`パラメータを使用してシステムテーブルを復元する際に、照合順序の互換性チェックをサポートするようになりました。復元中、 BRはターゲットクラスタ照合順序で大文字小文字の競合が存在するかどうかを確認します。データがターゲット照合順序と互換性がある場合、 BRは以前のバージョンからのバックアップを正常に復元できます。そうでない場合、 BRはエラーを報告して復元を終了します。 以下の表は、フルバックアップの互換性マトリックスを示しています。なお、表の情報はすべて新規作成されたクラスターに適用されます。v7.2.0より前のバージョンからv7.2.0以降にアップグレードされたクラスターについては、v7.1.0のバックアップと同様の動作となります。 @@ -168,15 +168,15 @@ TiDB v6.6.0より前のBRの互換性情報は以下のとおりです。 > **Note:** > -> - システムテーブル以外のデータのみがバックアップされる場合（フルバックアップまたはログバックアップ）、すべてのバージョンは互換性があります。 -> - `mysql`システム テーブルの復元が互換性のないシナリオでは、 `--with-sys-table=false`を設定してすべてのシステム テーブルの復元をスキップするか、より細かいフィルターを使用して互換性のないシステム テーブルのみをスキップすることで問題を解決できます。たとえば、 `--filter '*.*' --filter "__TiDB_BR_Temporary_*.*" --filter '!mysql.*' --filter 'mysql.bind_info' --filter 'mysql.user' --filter 'mysql.global_priv' --filter 'mysql.global_grants' --filter 'mysql.default_roles' --filter 'mysql.role_edges' --filter '!sys.*' --filter '!INFORMATION_SCHEMA.*' --filter '!PERFORMANCE_SCHEMA.*' --filter '!METRICS_SCHEMA.*' --filter '!INSPECTION_SCHEMA.*'`などです。 -> - `-`該当するシナリオに互換性の制限がないことを意味します。 +> - システムテーブル以外のデータのみがバックアップされる場合（フルバックアップまたはログバックアップ）、すべてのバージョンは互換性があります。 +> - `mysql`システム テーブルの復元が互換性のないシナリオでは、 `--with-sys-table=false`を設定してすべてのシステム テーブルの復元をスキップするか、より細かいフィルターを使用して互換性のないシステム テーブルのみをスキップすることで問題を解決できます。たとえば、 `--filter '*.*' --filter "__TiDB_BR_Temporary_*.*" --filter '!mysql.*' --filter 'mysql.bind_info' --filter 'mysql.user' --filter 'mysql.global_priv' --filter 'mysql.global_grants' --filter 'mysql.default_roles' --filter 'mysql.role_edges' --filter '!sys.*' --filter '!INFORMATION_SCHEMA.*' --filter '!PERFORMANCE_SCHEMA.*' --filter '!METRICS_SCHEMA.*' --filter '!INSPECTION_SCHEMA.*'`などです。 +> - `-`該当するシナリオに互換性の制限がないことを意味します。 ## 関連項目 {#see-also} -- [TiDBスナップショットのバックアップと復元ガイド](/br/br-snapshot-guide.md) -- [TiDBログバックアップおよびPITRガイド](/br/br-pitr-guide.md) -- [バックアップストレージ](/br/backup-and-restore-storages.md) +- [TiDBスナップショットのバックアップと復元ガイド](/br/br-snapshot-guide.md) +- [TiDBログバックアップおよびPITRガイド](/br/br-pitr-guide.md) +- [バックアップストレージ](/br/backup-and-restore-storages.md) ## 関連リソース {#related-resources} diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md index e6bac22696e97..b906a04039ab4 100644 --- a/br/backup-and-restore-storages.md +++ b/br/backup-and-restore-storages.md @@ -106,8 +106,8 @@ tiup br restore db --db test -u "${PD_IP}:2379" \ バックアップの前に、S3 上のバックアップ ディレクトリにアクセスするための次の権限を設定します。 -- バックアップ中に`s3:DeleteObject`およびバックアップ & リストア ( BR ) `s3:AbortMultipartUpload`バックアップ ディレクトリ`s3:GetObject`アクセスするための最小権限: `s3:ListBucket` 、および`s3:PutObject` -- 復元中に TiKV とBRがバックアップ ディレクトリにアクセスするための最小権限: `s3:ListBucket`と`s3:GetObject` 。 +- バックアップ中に`s3:DeleteObject`およびバックアップ & リストア ( BR ) `s3:AbortMultipartUpload`バックアップ ディレクトリ`s3:GetObject`アクセスするための最小権限: `s3:ListBucket` 、および`s3:PutObject` +- 復元中に TiKV とBRがバックアップ ディレクトリにアクセスするための最小権限: `s3:ListBucket`と`s3:GetObject` 。 バックアップディレクトリをまだ作成していない場合は、 [バケットを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)を参照して指定のリージョンに S3 バケットを作成してください。必要に応じて、 [フォルダを作成する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-folders.html)を参照してバケット内にフォルダを作成することもできます。 @@ -117,16 +117,16 @@ tiup br restore db --db test -u "${PD_IP}:2379" \ 次のいずれかの方法で S3 へのアクセスを構成することをお勧めします。 -- 方法1: アクセスキーを指定する +- 方法1: アクセスキーを指定する URIにアクセスキーとシークレットアクセスキーを指定すると、指定されたアクセスキーとシークレットアクセスキーを使用して認証が行われます。URIでキーを指定する以外にも、以下の方法がサポートされています。 - - BRは環境変数`$AWS_ACCESS_KEY_ID`と`$AWS_SECRET_ACCESS_KEY`を読み取ります。 - - BR は環境変数`$AWS_ACCESS_KEY`と`$AWS_SECRET_KEY`を読み取ります。 - - BR は、環境変数`$AWS_SHARED_CREDENTIALS_FILE`で指定されたパスにある共有資格情報ファイルを読み取ります。 - - BR は`~/.aws/credentials`パスの共有資格情報ファイルを読み取ります。 + - BRは環境変数`$AWS_ACCESS_KEY_ID`と`$AWS_SECRET_ACCESS_KEY`を読み取ります。 + - BR は環境変数`$AWS_ACCESS_KEY`と`$AWS_SECRET_KEY`を読み取ります。 + - BR は、環境変数`$AWS_SHARED_CREDENTIALS_FILE`で指定されたパスにある共有資格情報ファイルを読み取ります。 + - BR は`~/.aws/credentials`パスの共有資格情報ファイルを読み取ります。 -- 方法2: IAMロールに基づくアクセス +- 方法2: IAMロールに基づくアクセス S3にアクセスできるIAMロールを、TiKVノードとBRノードが稼働するEC2インスタンスに関連付けます。関連付け後、 BRは追加設定なしでS3内のバックアップディレクトリに直接アクセスできるようになります。 @@ -140,21 +140,21 @@ tiup br restore db --db test -u "${PD_IP}:2379" \ GCS へのアクセスに使用する認証情報は、次の方法で設定できます。 -- 方法1: `credentials-file`を明示的に指定する +- 方法1: `credentials-file`を明示的に指定する - - `credentials-file`が Service Account JSON ファイルを指している場合、BR と TiKV はこの認証情報を使用して GCS にアクセスします。 - - TiKV が`gcp_v2`外部ストレージバックエンドを使用している場合、 `credentials-file`は Google Cloud WIF で使用される`external_account` JSON を指すこともできます。 + - `credentials-file`が Service Account JSON ファイルを指している場合、BR と TiKV はこの認証情報を使用して GCS にアクセスします。 + - TiKV が`gcp_v2`外部ストレージバックエンドを使用している場合、 `credentials-file`は Google Cloud WIF で使用される`external_account` JSON を指すこともできます。 -- 方法2: Application Default Credentials (ADC) を使用する +- 方法2: Application Default Credentials (ADC) を使用する - - BRは環境変数`$GOOGLE_APPLICATION_CREDENTIALS`で指定されたパスのファイルを読み取ります。 - - BRはファイル`~/.config/gcloud/application_default_credentials.json`を読み取ります。 - - BR が GCE または GAE で実行される場合、メタデータサーバーから取得した認証情報を使用します。 + - BRは環境変数`$GOOGLE_APPLICATION_CREDENTIALS`で指定されたパスのファイルを読み取ります。 + - BRはファイル`~/.config/gcloud/application_default_credentials.json`を読み取ります。 + - BR が GCE または GAE で実行される場合、メタデータサーバーから取得した認証情報を使用します。 TiKV で GCS WIF または ADC を使用する場合は、 `gcp_v2`外部ストレージバックエンドを有効にする必要があります。**v8.5.7 以降、TiKV はデフォルトで`gcp_v2`外部ストレージバックエンドを有効にします。** `gcp_v2`は次の方法で設定できます。 -- 完全バックアップと復元: [TiKV Configuration File Descriptions](/tikv-configuration-file.md)で`[backup].gcp-v2-enable`を`true`に設定します -- ログバックアップ: [TiKV Configuration File Descriptions](/tikv-configuration-file.md)で`[log-backup].gcp-v2-enable`を`true`に設定します +- 完全バックアップと復元: [TiKV Configuration File Descriptions](/tikv-configuration-file.md)で`[backup].gcp-v2-enable`を`true`に設定します +- ログバックアップ: [TiKV Configuration File Descriptions](/tikv-configuration-file.md)で`[log-backup].gcp-v2-enable`を`true`に設定します 前述の 2 つの設定項目のデフォルト値はどちらも`true`です。 `gcp_v2`を無効にすると、TiKV は引き続き従来の GCS 実装を使用します。この実装は Service Account JSON のみをサポートし、WIF の直接使用はサポートしません。 @@ -169,31 +169,31 @@ TiKV で GCS WIF または ADC を使用する場合は、 `gcp_v2`外部スト
-- 方法1: 共有アクセス署名を指定する +- 方法1: 共有アクセス署名を指定する URIに`account-name`と`sas-token`を指定した場合、指定されたアカウント名と共有アクセス署名（SAS）トークンを使用して認証が行われます。SASトークンには`&`という文字が含まれていることに注意してください。これをURIに追加する前に、 `%26`としてエンコードする必要があります。パーセントエンコードを使用して、 `sas-token`全体を直接エンコードすることもできます。 -- 方法2: アクセスキーを指定する +- 方法2: アクセスキーを指定する URIに`account-name`と`account-key`を指定すると、指定されたアカウント名とアカウントキーを用いて認証が行われます。URIでキーを指定する方法に加え、 BRは環境変数`$AZURE_STORAGE_KEY`からキーを読み取ることもできます。 -- 方法3: バックアップと復元にAzure ADを使用する +- 方法3: バックアップと復元にAzure ADを使用する BRが実行されているノードで環境変数`$AZURE_CLIENT_ID` `$AZURE_TENANT_ID`および`$AZURE_CLIENT_SECRET`を設定します。 - - TiUPを使用してクラスターを起動すると、TiKV は systemd サービスを使用します。次の例は、TiKV の上記の 3 つの環境変数を設定する方法を示しています。 + - TiUPを使用してクラスターを起動すると、TiKV は systemd サービスを使用します。次の例は、TiKV の上記の 3 つの環境変数を設定する方法を示しています。 > **Note:** > > この方法を使用する場合は、手順 3 で TiKV を再起動する必要があります。クラスターを再起動できない場合は、 **方法 1: バックアップと復元のアクセス キーを指定する**を使用します。 - 1. このノードの TiKV ポートが`24000` 、つまり systemd サービスの名前が`tikv-24000`であるとします。 + 1. このノードの TiKV ポートが`24000` 、つまり systemd サービスの名前が`tikv-24000`であるとします。 ```shell systemctl edit tikv-24000 ``` - 2. TiKV 構成ファイルを編集して、次の 3 つの環境変数を構成します。 + 2. TiKV 構成ファイルを編集して、次の 3 つの環境変数を構成します。 ``` [Service] @@ -202,14 +202,14 @@ TiKV で GCS WIF または ADC を使用する場合は、 `gcp_v2`外部スト Environment="AZURE_CLIENT_SECRET=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa" ``` - 3. 設定を再読み込みし、TiKV を再起動します。 + 3. 設定を再読み込みし、TiKV を再起動します。 ```shell systemctl daemon-reload systemctl restart tikv-24000 ``` - - コマンドラインで起動した TiKV およびBRの Azure AD 情報を構成するには、次のコマンドを実行して、オペレーティング環境で環境変数`$AZURE_CLIENT_ID` `$AZURE_TENANT_ID`および`$AZURE_CLIENT_SECRET`が構成されているかどうかを確認するだけです。 + - コマンドラインで起動した TiKV およびBRの Azure AD 情報を構成するには、次のコマンドを実行して、オペレーティング環境で環境変数`$AZURE_CLIENT_ID` `$AZURE_TENANT_ID`および`$AZURE_CLIENT_SECRET`が構成されているかどうかを確認するだけです。 ```shell echo $AZURE_CLIENT_ID @@ -217,20 +217,20 @@ TiKV で GCS WIF または ADC を使用する場合は、 `gcp_v2`外部スト echo $AZURE_CLIENT_SECRET ``` - - BRを使用してデータを Azure Blob Storage にバックアップします。 + - BRを使用してデータを Azure Blob Storage にバックアップします。 ```shell tiup br backup full -u "${PD_IP}:2379" \ --storage "azure://external/backup-20220915?account-name=${account-name}" ``` -- 方法4: AzureマネージドIDを使用する +- 方法4: AzureマネージドIDを使用する v8.5.5 以降では、TiDB クラスターとBRが Azure 仮想マシン (VM) または Azure Kubernetes Service (AKS) 環境で実行されており、Azure マネージド ID がノードに割り当てられている場合は、認証に Azure マネージド ID を使用できます。 この方法を使用する前に、 [Azureポータル](https://azure.microsoft.com/)内のターゲットストレージアカウントにアクセスするためのアクセス許可 ( `Storage Blob Data Contributor`など) が対応するマネージド ID に付与されていることを確認してください。 - - **システム割り当てマネージド ID** : + - **システム割り当てマネージド ID** : システム割り当てマネージド ID を使用する場合、Azure 関連の環境変数を構成する必要はありません。BRコマンドを直接実行できます。 @@ -243,41 +243,41 @@ TiKV で GCS WIF または ADC を使用する場合は、 `gcp_v2`外部スト > > ランタイム環境で環境変数`AZURE_CLIENT_ID` 、 `AZURE_TENANT_ID` 、 `AZURE_CLIENT_SECRET`設定されて**いない**ことを確認してください。設定されていない場合、Azure SDK が他の認証方法を優先し、マネージド ID が有効にならない可能性があります。 - - **ユーザー割り当てマネージド ID** : + - **ユーザー割り当てマネージド ID** : ユーザー割り当てマネージドIDを使用する場合は、TiKVとBRのランタイム環境で環境変数`AZURE_CLIENT_ID`を設定し、その値をマネージドIDのクライアントIDに設定してから、 BRバックアップコマンドを実行する必要があります。詳細な手順は次のとおりです。 - 1. TiUPで起動するときに TiKV のクライアント ID を設定します。 + 1. TiUPで起動するときに TiKV のクライアント ID を設定します。 次の手順では、TiKV ポート`24000`と systemd サービス名`tikv-24000`例として使用します。 - 1. 次のコマンドを実行して、systemd サービス エディターを開きます。 + 1. 次のコマンドを実行して、systemd サービス エディターを開きます。 ```shell systemctl edit tikv-24000 ``` - 2. `AZURE_CLIENT_ID`環境変数をマネージド ID クライアント ID に設定します。 + 2. `AZURE_CLIENT_ID`環境変数をマネージド ID クライアント ID に設定します。 ```ini [Service] Environment="AZURE_CLIENT_ID=" ``` - 3. systemd 構成を再ロードし、TiKV を再起動します。 + 3. systemd 構成を再ロードし、TiKV を再起動します。 ```shell systemctl daemon-reload systemctl restart tikv-24000 ``` - 2. BRの`AZURE_CLIENT_ID`環境変数を設定します。 + 2. BRの`AZURE_CLIENT_ID`環境変数を設定します。 ```shell export AZURE_CLIENT_ID="" ``` - 3. 次のBRコマンドを使用して、データを Azure Blob Storage にバックアップします。 + 3. 次のBRコマンドを使用して、データを Azure Blob Storage にバックアップします。 ```shell tiup br backup full -u "${PD_IP}:2379" \ diff --git a/br/backup-and-restore-use-cases.md b/br/backup-and-restore-use-cases.md index 221d695913110..0e00ace69c4fb 100644 --- a/br/backup-and-restore-use-cases.md +++ b/br/backup-and-restore-use-cases.md @@ -9,8 +9,8 @@ summary: TiDBは、タイムリーなデータリカバリやビジネス監査 AWS に TiDB本番クラスターをデプロイし、ビジネスチームが次の要件を要求しているとします。 -- データの変更はタイムリーにバックアップしてください。データベースに災害が発生した場合でも、最小限のデータ損失（許容できるのは数分間のデータ損失のみ）でアプリケーションを迅速に復旧できます。 -- 毎月、特定の時間に業務監査を実施します。監査依頼を受けた場合、要求に応じて過去1ヶ月間の特定の時点のデータにクエリを実行するためのデータベースを提供する必要があります。 +- データの変更はタイムリーにバックアップしてください。データベースに災害が発生した場合でも、最小限のデータ損失（許容できるのは数分間のデータ損失のみ）でアプリケーションを迅速に復旧できます。 +- 毎月、特定の時間に業務監査を実施します。監査依頼を受けた場合、要求に応じて過去1ヶ月間の特定の時点のデータにクエリを実行するためのデータベースを提供する必要があります。 PITR を使用すると、前述の要件を満たすことができます。 @@ -30,23 +30,23 @@ PITRを使用するには、TiDBクラスタ（v6.2.0以上）をデプロイし > **Note:** > -> - BR がバックアップおよび復元タスクを実行する際、PD および TiKV にアクセスする必要があります。BRがすべての PD および TiKV ノードに接続できることを確認してください。 -> - BRと PD サーバーは同じタイムゾーンを使用する必要があります。 +> - BR がバックアップおよび復元タスクを実行する際、PD および TiKV にアクセスする必要があります。BRがすべての PD および TiKV ノードに接続できることを確認してください。 +> - BRと PD サーバーは同じタイムゾーンを使用する必要があります。 TiUPを使用して TiDB クラスターをデプロイまたはアップグレードします。 -- 新しい TiDB クラスターをデプロイするには、 [TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)を参照してください。 -- TiDB クラスターが v6.2.0 より前の場合は、 [TiDBクラスタのアップグレード](/upgrade-tidb-using-tiup.md)を参照してアップグレードしてください。 +- 新しい TiDB クラスターをデプロイするには、 [TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)を参照してください。 +- TiDB クラスターが v6.2.0 より前の場合は、 [TiDBクラスタのアップグレード](/upgrade-tidb-using-tiup.md)を参照してアップグレードしてください。 TiUPを使用してBRをインストールまたはアップグレードします。 -- インストール： +- インストール： ```shell tiup install br:v8.5.5 ``` -- アップグレード: +- アップグレード: ```shell tiup update br:v8.5.5 @@ -56,34 +56,34 @@ TiUPを使用してBRをインストールまたはアップグレードしま バックアップ タスクを開始する前に、次の点を含めてバックアップストレージを準備します。 -1. バックアップデータを保存する S3 バケットとディレクトリを準備します。 -2. S3 バケットにアクセスするための権限を設定します。 -3. 各バックアップ データを保存するサブディレクトリを計画します。 +1. バックアップデータを保存する S3 バケットとディレクトリを準備します。 +2. S3 バケットにアクセスするための権限を設定します。 +3. 各バックアップ データを保存するサブディレクトリを計画します。 詳細な手順は次のとおりです。 -1. バックアップデータを保存するためのディレクトリをS3に作成します。この例ではディレクトリは`s3://tidb-pitr-bucket/backup-data`です。 +1. バックアップデータを保存するためのディレクトリをS3に作成します。この例ではディレクトリは`s3://tidb-pitr-bucket/backup-data`です。 - 1. バケットを作成します。バックアップデータの保存先として既存のS3を選択できます。S3が存在しない場合は、 [AWSドキュメント: バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)を参照してS3バケットを作成してください。この例では、バケット名は`tidb-pitr-bucket`です。 - 2. バックアップデータ用のディレクトリを作成します。バケット（ `tidb-pitr-bucket` ）内に`backup-data`という名前のディレクトリを作成します。詳細な手順は[AWS ドキュメント: Amazon S3 コンソールでフォルダを使用してオブジェクトを整理する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-folders.html)を参照してください。 + 1. バケットを作成します。バックアップデータの保存先として既存のS3を選択できます。S3が存在しない場合は、 [AWSドキュメント: バケットの作成](https://docs.aws.amazon.com/AmazonS3/latest/userguide/create-bucket-overview.html)を参照してS3バケットを作成してください。この例では、バケット名は`tidb-pitr-bucket`です。 + 2. バックアップデータ用のディレクトリを作成します。バケット（ `tidb-pitr-bucket` ）内に`backup-data`という名前のディレクトリを作成します。詳細な手順は[AWS ドキュメント: Amazon S3 コンソールでフォルダを使用してオブジェクトを整理する](https://docs.aws.amazon.com/AmazonS3/latest/userguide/using-folders.html)を参照してください。 -2. BRとTiKVがS3ディレクトリにアクセスするための権限を設定します。S3バケットにアクセスする最も安全な方法であるIAMメソッドを使用して権限を付与することをお勧めします。詳細な手順については、 [AWS ドキュメント: ユーザーポリシーによるバケットへのアクセスの制御](https://docs.aws.amazon.com/AmazonS3/latest/userguide/walkthrough1.html)を参照してください。必要な権限は次のとおりです。 +2. BRとTiKVがS3ディレクトリにアクセスするための権限を設定します。S3バケットにアクセスする最も安全な方法であるIAMメソッドを使用して権限を付与することをお勧めします。詳細な手順については、 [AWS ドキュメント: ユーザーポリシーによるバケットへのアクセスの制御](https://docs.aws.amazon.com/AmazonS3/latest/userguide/walkthrough1.html)を参照してください。必要な権限は次のとおりです。 - - バックアップ クラスター内の TiKV とBRには`s3:GetObject` `s3://tidb-pitr-bucket/backup-data`ディレクトリ`s3:DeleteObject` `s3:ListBucket` 、および`s3:PutObject` `s3:AbortMultipartUpload`権限が必要です。 - - 復元クラスター内の TiKV とBRには、 `s3://tidb-pitr-bucket/backup-data`ディレクトリの`s3:ListBucket`と`s3:GetObject`権限が必要です。 + - バックアップ クラスター内の TiKV とBRには`s3:GetObject` `s3://tidb-pitr-bucket/backup-data`ディレクトリ`s3:DeleteObject` `s3:ListBucket` 、および`s3:PutObject` `s3:AbortMultipartUpload`権限が必要です。 + - 復元クラスター内の TiKV とBRには、 `s3://tidb-pitr-bucket/backup-data`ディレクトリの`s3:ListBucket`と`s3:GetObject`権限が必要です。 -3. スナップショット (完全) バックアップやログ バックアップなどのバックアップ データを保存するディレクトリ構造を計画します。 +3. スナップショット (完全) バックアップやログ バックアップなどのバックアップ データを保存するディレクトリ構造を計画します。 - - すべてのスナップショットバックアップデータは`s3://tidb-pitr-bucket/backup-data/snapshot-${date}`ディレクトリに保存されます。 `${date}`スナップショットバックアップの開始時刻です。例えば、2022/05/12 00:01:30 に開始されたスナップショットバックアップは`s3://tidb-pitr-bucket/backup-data/snapshot-20220512000130`に保存されます。 - - ログバックアップデータは`s3://tidb-pitr-bucket/backup-data/log-backup/`ディレクトリに保存されます。 + - すべてのスナップショットバックアップデータは`s3://tidb-pitr-bucket/backup-data/snapshot-${date}`ディレクトリに保存されます。 `${date}`スナップショットバックアップの開始時刻です。例えば、2022/05/12 00:01:30 に開始されたスナップショットバックアップは`s3://tidb-pitr-bucket/backup-data/snapshot-20220512000130`に保存されます。 + - ログバックアップデータは`s3://tidb-pitr-bucket/backup-data/log-backup/`ディレクトリに保存されます。 ## バックアップポリシーを決定する {#determine-the-backup-policy} 最小限のデータ損失、迅速な回復、および 1 か月以内のビジネス監査の要件を満たすには、次のようにバックアップ ポリシーを設定できます。 -- ログ バックアップを実行して、データベース内のデータの変更を継続的にバックアップします。 -- 2 日ごとに午前 0 時にスナップショット バックアップを実行します。 -- スナップショット バックアップ データとログ バックアップ データを 30 日以内に保持し、30 日以上経過したバックアップ データをクリーンアップします。 +- ログ バックアップを実行して、データベース内のデータの変更を継続的にバックアップします。 +- 2 日ごとに午前 0 時にスナップショット バックアップを実行します。 +- スナップショット バックアップ データとログ バックアップ データを 30 日以内に保持し、30 日以上経過したバックアップ データをクリーンアップします。 ## ログバックアップを実行する {#run-log-backup} @@ -116,7 +116,7 @@ crontabなどの自動ツールを使えば、スナップショットバック 以下に 2 つのスナップショット バックアップの例を示します。 -- 2022/05/14 00:00:00にスナップショットバックアップを実行します +- 2022/05/14 00:00:00にスナップショットバックアップを実行します ```shell tiup br backup full --pd="${PD_IP}:2379" \ @@ -124,7 +124,7 @@ crontabなどの自動ツールを使えば、スナップショットバック --backupts='2022/05/14 00:00:00 +08:00' ``` -- 2022/05/16 00:00:00にスナップショットバックアップを実行します +- 2022/05/16 00:00:00にスナップショットバックアップを実行します ```shell tiup br backup full --pd="${PD_IP}:2379" \ @@ -159,13 +159,13 @@ crontab などの自動ツールを使用して、2 日ごとに古いデータ たとえば、次のコマンドを実行して古いデータをクリーンアップできます。 -- 2022/05/14 00:00:00より前のスナップショットデータを削除します +- 2022/05/14 00:00:00より前のスナップショットデータを削除します ```shell rm s3://tidb-pitr-bucket/backup-data/snapshot-20220514000000 ``` -- 2022/05/14 00:00:00より前のログバックアップデータを削除します +- 2022/05/14 00:00:00より前のログバックアップデータを削除します ```shell tiup br log truncate --until='2022-05-14 00:00:00 +0800' --storage='s3://tidb-pitr-bucket/backup-data/log-backup' @@ -173,6 +173,6 @@ crontab などの自動ツールを使用して、2 日ごとに古いデータ ## 参照 {#see-also} -- [バックアップストレージ](/br/backup-and-restore-storages.md) -- [スナップショットのバックアップと復元コマンドマニュアル](/br/br-snapshot-manual.md) -- [ログバックアップとPITRコマンドマニュアル](/br/br-pitr-manual.md) +- [バックアップストレージ](/br/backup-and-restore-storages.md) +- [スナップショットのバックアップと復元コマンドマニュアル](/br/br-snapshot-manual.md) +- [ログバックアップとPITRコマンドマニュアル](/br/br-pitr-manual.md) diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md index 708da0648a5f8..44e8c7a6c32f1 100644 --- a/br/br-auto-tune.md +++ b/br/br-auto-tune.md @@ -39,19 +39,19 @@ tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v 自動調整機能には、次の問題と対応する解決策があります。 -- 問題1：**書き込み負荷の高いクラスタ**では、自動チューニングによってワークロードとバックアップタスクが「正のフィードバックループ」に陥る可能性があります。つまり、バックアップタスクが過剰なリソースを消費し、クラスタが使用するリソースが少なくなるのです。この時点で、自動チューニングはクラスタのワークロードがそれほど高くないと誤って判断し、バックアップの実行速度を速めてしまう可能性があります。このような場合、自動チューニングは効果を発揮しません。 +- 問題1：**書き込み負荷の高いクラスタ**では、自動チューニングによってワークロードとバックアップタスクが「正のフィードバックループ」に陥る可能性があります。つまり、バックアップタスクが過剰なリソースを消費し、クラスタが使用するリソースが少なくなるのです。この時点で、自動チューニングはクラスタのワークロードがそれほど高くないと誤って判断し、バックアップの実行速度を速めてしまう可能性があります。このような場合、自動チューニングは効果を発揮しません。 - - 解決策：バックアップタスクで使用されるスレッド数を制限したい場合は、手動で`backup.num-threads`小さい数値に調整してください。動作原理は以下のとおりです。 + - 解決策：バックアップタスクで使用されるスレッド数を制限したい場合は、手動で`backup.num-threads`小さい数値に調整してください。動作原理は以下のとおりです。 バックアッププロセスには、SSTのデコード、エンコード、圧縮、解凍といった多くの処理が含まれており、CPUリソースを消費します。さらに、過去のテストケースでは、バックアッププロセス中に、バックアップに使用されるスレッドプールのCPU使用率が100%に近づくことが確認されています。これは、バックアップタスクが多くのCPUリソースを消費していることを意味します。TiKVは、バックアップタスクで使用されるスレッド数を調整することで、バックアップタスクで使用されるCPUコア数を制限し、バックアップタスクがクラスターのパフォーマンスに与える影響を軽減します。 -- 問題 2:**ホットスポットのあるクラスター**の場合、ホットスポットがある TiKV ノード上のバックアップ タスクが過度に制限され、全体的なバックアップ プロセスが遅くなることがあります。 +- 問題 2:**ホットスポットのあるクラスター**の場合、ホットスポットがある TiKV ノード上のバックアップ タスクが過度に制限され、全体的なバックアップ プロセスが遅くなることがあります。 - - 解決策: ホットスポット ノードを削除するか、ホットスポット ノードの自動調整を無効にします (これにより、クラスターのパフォーマンスが低下する可能性があります)。 + - 解決策: ホットスポット ノードを削除するか、ホットスポット ノードの自動調整を無効にします (これにより、クラスターのパフォーマンスが低下する可能性があります)。 -- 問題3：**トラフィックジッタが大きい**シナリオでは、自動調整機能は一定間隔（デフォルトでは1分）で速度制限を調整するため、トラフィックジッタが大きい状況に対応できない可能性があります。詳細は[`auto-tune-refresh-interval`](#implementation)ご覧ください。 +- 問題3：**トラフィックジッタが大きい**シナリオでは、自動調整機能は一定間隔（デフォルトでは1分）で速度制限を調整するため、トラフィックジッタが大きい状況に対応できない可能性があります。詳細は[`auto-tune-refresh-interval`](#implementation)ご覧ください。 - - 解決策: 自動調整を無効にします。 + - 解決策: 自動調整を無効にします。 ## 実装 {#implementation} @@ -59,15 +59,15 @@ tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v この機能には、TiKV設定ファイルに記載されていない関連する設定項目が2つあります。これらの設定項目は内部調整のみを目的としています。バックアップタスクを実行する際に、これらの設定項目を設定する必要は**ありません**。 -- `backup.auto-tune-remain-threads` : +- `backup.auto-tune-remain-threads` : - - 自動調整は、バックアップ タスクで使用されるリソースを制御し、同じノード上の他のタスクで少なくとも`backup.auto-tune-remain-threads`コアが使用可能であることを保証します。 - - デフォルト値: `round(0.2 * vCPU)` + - 自動調整は、バックアップ タスクで使用されるリソースを制御し、同じノード上の他のタスクで少なくとも`backup.auto-tune-remain-threads`コアが使用可能であることを保証します。 + - デフォルト値: `round(0.2 * vCPU)` -- `backup.auto-tune-refresh-interval` : +- `backup.auto-tune-refresh-interval` : - - 自動調整により、 `backup.auto-tune-refresh-interval`分ごとに統計が更新され、バックアップ タスクで使用できる CPU コアの最大数が再計算されます。 - - デフォルト値: `1m` + - 自動調整により、 `backup.auto-tune-refresh-interval`分ごとに統計が更新され、バックアップ タスクで使用できる CPU コアの最大数が再計算されます。 + - デフォルト値: `1m` 以下は、自動チューニングの動作例です。`*`はバックアップ タスクで使用される CPU コアを示します。`^`は他のタスクで使用される CPU コアを示します。`-`は、アイドル状態の CPU コアを示します。 diff --git a/br/br-batch-create-table.md b/br/br-batch-create-table.md index bbc961aa976a1..e4b53ae6aaaf4 100644 --- a/br/br-batch-create-table.md +++ b/br/br-batch-create-table.md @@ -11,8 +11,8 @@ summary: TiDB v6.0.0では、データ復元時のテーブル作成プロセス > **Note:** > -> - バッチテーブル作成機能を使用するには、TiDBとBRの両方がv6.0.0以降である必要があります。TiDBまたはBRのいずれかがv6.0.0より前の場合、 BRはシリアル実行実装を使用します。 -> - クラスター管理ツール ( TiUPなど) を使用しており、TiDB とBR がv6.0.0 以降のバージョンであるか、TiDB とBRが v6.0.0 より前のバージョンから v6.0.0 以降にアップグレードされているとします。 +> - バッチテーブル作成機能を使用するには、TiDBとBRの両方がv6.0.0以降である必要があります。TiDBまたはBRのいずれかがv6.0.0より前の場合、 BRはシリアル実行実装を使用します。 +> - クラスター管理ツール ( TiUPなど) を使用しており、TiDB とBR がv6.0.0 以降のバージョンであるか、TiDB とBRが v6.0.0 より前のバージョンから v6.0.0 以降にアップグレードされているとします。 ## 使用シナリオ {#usage-scenario} @@ -36,11 +36,11 @@ tiup br restore full \ ## 実装 {#implementation} -- v6.0.0 より前のシリアル実行実装: +- v6.0.0 より前のシリアル実行実装: データを復元する際、 BR は対象の TiDB クラスター内にデータベースとテーブルを作成し、バックアップデータをテーブルに復元します。テーブルを作成するために、 BR はまず TiDB 内部 API を呼び出し、次にテーブル作成タスクを処理します。これは`Create Table`文の実行と同様に機能します。TiDB DDL オーナーはテーブルを順次作成します。DDL オーナーがテーブルを作成すると、それに応じて DDL スキーマのバージョンが変更され、各バージョンの変更は他の TiDB DDL ワーカー（ BRを含む）に同期されます。そのため、多数のテーブルを復元する場合、シリアル実行の実装には時間がかかります。 -- v6.0.0 以降のバッチテーブル作成実装: +- v6.0.0 以降のバッチテーブル作成実装: デフォルトでは、 BRは複数のバッチでテーブルを作成し、各バッチには128個のテーブルが含まれます。この実装により、 BRが1バッチのテーブルを作成する際に、TiDBスキーマバージョンは1回のみ変更されます。この実装により、テーブル作成速度が大幅に向上します。 @@ -48,13 +48,13 @@ tiup br restore full \ このセクションでは、バッチテーブル作成機能に関するテスト情報について説明します。テスト環境は次のとおりです。 -- クラスタ構成: +- クラスタ構成: - - 15 個の TiKV インスタンス。各 TiKV インスタンスには、16 個の CPU コア、80 GB のメモリ、および RPC リクエストを処理するための 16 個のスレッド ( [`import.num-threads`](/tikv-configuration-file.md#num-threads) = 16) が搭載されています。 - - 3 つの TiDB インスタンス。各 TiDB インスタンスには、16 個の CPU コアと 32 GB のメモリが搭載されています。 - - 3 つの PD インスタンス。各 PD インスタンスには、16 個の CPU コアと 32 GB のメモリが搭載されています。 + - 15 個の TiKV インスタンス。各 TiKV インスタンスには、16 個の CPU コア、80 GB のメモリ、および RPC リクエストを処理するための 16 個のスレッド ( [`import.num-threads`](/tikv-configuration-file.md#num-threads) = 16) が搭載されています。 + - 3 つの TiDB インスタンス。各 TiDB インスタンスには、16 個の CPU コアと 32 GB のメモリが搭載されています。 + - 3 つの PD インスタンス。各 PD インスタンスには、16 個の CPU コアと 32 GB のメモリが搭載されています。 -- 復元するデータのサイズ: 16.16 TB +- 復元するデータのサイズ: 16.16 TB テスト結果は次のとおりです。 diff --git a/br/br-checkpoint-backup.md b/br/br-checkpoint-backup.md index fe077bdb57d59..5669fd5bb8ecf 100644 --- a/br/br-checkpoint-backup.md +++ b/br/br-checkpoint-backup.md @@ -47,6 +47,6 @@ tiup br backup full \ `br`バックアップを再試行する場合、バックアップ中のデータやチェックポイントで記録されていないデータなど、バックアップ済みのデータの一部を再度バックアップする必要がある場合があります。 -- 中断の原因がエラーである場合、 `br`終了前にバックアップされたデータのメタ情報を保持します。この場合、次回の再試行では、バックアップ中のデータのみを再度バックアップする必要があります。 +- 中断の原因がエラーである場合、 `br`終了前にバックアップされたデータのメタ情報を保持します。この場合、次回の再試行では、バックアップ中のデータのみを再度バックアップする必要があります。 -- `br`プロセスがシステムによって中断された場合、 `br`は外部ストレージにバックアップされたデータのメタ情報を永続化できません。`br`は30秒ごとにメタ情報を永続化するため、中断前の30秒間にバックアップされたデータは永続化できず、次回の再試行時に再度バックアップする必要があります。 +- `br`プロセスがシステムによって中断された場合、 `br`は外部ストレージにバックアップされたデータのメタ情報を永続化できません。`br`は30秒ごとにメタ情報を永続化するため、中断前の30秒間にバックアップされたデータは永続化できず、次回の再試行時に再度バックアップする必要があります。 diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index 8bc968a215772..9e4e70084deb8 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -53,9 +53,9 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた `br`は復元を再試行する場合、復元中のデータやチェックポイントによって記録されていないデータなど、復元されたデータの一部を再度復元する必要がある場合があります。 -- 中断の原因がエラーである場合、 `br`は終了前に復元されたデータのメタ情報を保持します。この場合、次回の再試行では復元中のデータのみを再度復元する必要があります。 +- 中断の原因がエラーである場合、 `br`は終了前に復元されたデータのメタ情報を保持します。この場合、次回の再試行では復元中のデータのみを再度復元する必要があります。 -- `br`プロセスがシステムによって中断された場合、 `br`は外部ストレージに復元されたデータのメタ情報を永続化できません。`br`は30秒ごとにメタ情報を永続化するため、中断前の30秒間に復元されたデータは永続化できず、次回の再試行時に再度復元する必要があります。 +- `br`プロセスがシステムによって中断された場合、 `br`は外部ストレージに復元されたデータのメタ情報を永続化できません。`br`は30秒ごとにメタ情報を永続化するため、中断前の30秒間に復元されたデータは永続化できず、次回の再試行時に再度復元する必要があります。 ### 復元中にクラスタデータを変更しないようにする {#avoid-modifying-cluster-data-during-the-restore} @@ -107,10 +107,10 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた 外部ストレージでは、チェックポイント データのディレクトリ構造は次のようになります。 -- ルート パス`restore-{downstream-cluster-ID}`は、ダウンストリーム クラスター ID `{downstream-cluster-ID}`を使用して、異なる復元クラスターを区別します。 -- パス`restore-{downstream-cluster-ID}/log`は、ログ復元フェーズ中にログ ファイルのチェックポイント データが保存されます。 -- パス`restore-{downstream-cluster-ID}/sst`は、ログ復元フェーズ中にログ バックアップによってバックアップされない SST ファイルのチェックポイント データが保存されます。 -- パス`restore-{downstream-cluster-ID}/snapshot`は、スナップショット復元フェーズ中にチェックポイント データが保存されます。 +- ルート パス`restore-{downstream-cluster-ID}`は、ダウンストリーム クラスター ID `{downstream-cluster-ID}`を使用して、異なる復元クラスターを区別します。 +- パス`restore-{downstream-cluster-ID}/log`は、ログ復元フェーズ中にログ ファイルのチェックポイント データが保存されます。 +- パス`restore-{downstream-cluster-ID}/sst`は、ログ復元フェーズ中にログ バックアップによってバックアップされない SST ファイルのチェックポイント データが保存されます。 +- パス`restore-{downstream-cluster-ID}/snapshot`は、スナップショット復元フェーズ中にチェックポイント データが保存されます。 diff --git a/br/br-compact-log-backup.md b/br/br-compact-log-backup.md index 43d01c162ac08..70428ff468955 100644 --- a/br/br-compact-log-backup.md +++ b/br/br-compact-log-backup.md @@ -11,20 +11,20 @@ summary: ログ バックアップを SST 形式に圧縮することで、ポ 従来のログ バックアップでは、書き込み操作が極めて非構造化された方法で保存されるため、次のような問題が発生する可能性があります。 -- **回復パフォーマンスの低下**: 順序付けられていないデータは、 Raftプロトコルを介してクラスターに 1 つずつ書き込む必要があります。 -- **書き込み増幅**: すべての書き込みは、L0 から最下レベルまでレベルごとに圧縮する必要があります。 -- **完全バックアップへの依存**: リカバリ データの量を制御するには、頻繁な完全バックアップが必要であり、アプリケーションの操作に影響を及ぼす可能性があります。 +- **回復パフォーマンスの低下**: 順序付けられていないデータは、 Raftプロトコルを介してクラスターに 1 つずつ書き込む必要があります。 +- **書き込み増幅**: すべての書き込みは、L0 から最下レベルまでレベルごとに圧縮する必要があります。 +- **完全バックアップへの依存**: リカバリ データの量を制御するには、頻繁な完全バックアップが必要であり、アプリケーションの操作に影響を及ぼす可能性があります。 バージョン8.5.5以降、コンパクトログバックアップ機能にオフラインコンパクション機能が追加され、非構造化ログバックアップデータを構造化SSTファイルに変換できるようになりました。これにより、以下の改善がもたらされます。 -- SST ファイルをクラスターに迅速にインポートできるため、**リカバリ パフォーマンスが向上します**。 -- 圧縮中に冗長データが削除され、**ストレージスペースの消費量が削減されます**。 -- リカバリ時間目標 (RTO) を確保しながら、より長い完全バックアップ間隔を設定できるため、**アプリケーションへの影響を軽減できます**。 +- SST ファイルをクラスターに迅速にインポートできるため、**リカバリ パフォーマンスが向上します**。 +- 圧縮中に冗長データが削除され、**ストレージスペースの消費量が削減されます**。 +- リカバリ時間目標 (RTO) を確保しながら、より長い完全バックアップ間隔を設定できるため、**アプリケーションへの影響を軽減できます**。 ## 制限事項 {#limitations} -- コンパクトログバックアップは完全バックアップの代替手段ではありません。定期的な完全バックアップと併用する必要があります。PITR機能を確保するため、圧縮プロセスではすべてのMVCCバージョンが保持されます。完全バックアップを長期間実行しないと、ストレージ使用量が過剰になり、後でデータを復元する際に問題が発生する可能性があります。 -- 現在、ローカル暗号化を有効にしたバックアップの圧縮はサポートされていません。 +- コンパクトログバックアップは完全バックアップの代替手段ではありません。定期的な完全バックアップと併用する必要があります。PITR機能を確保するため、圧縮プロセスではすべてのMVCCバージョンが保持されます。完全バックアップを長期間実行しないと、ストレージ使用量が過剰になり、後でデータを復元する際に問題が発生する可能性があります。 +- 現在、ローカル暗号化を有効にしたバックアップの圧縮はサポートされていません。 ## コンパクトログバックアップを使用する {#use-compact-log-backup} @@ -48,8 +48,8 @@ br operator base64ify --storage "s3://your/log/backup/storage/here" --load-creds > **Note:** > -> - 上記のコマンドを実行する際にオプション`--load-creds`を指定した場合、エンコードされたBase64文字列には、現在のBR環境から読み込まれた認証情報が含まれます。適切なセキュリティとアクセス制御を確保するためにご注意ください。 -> - `--storage`の値は、ログ バックアップ タスクの`log status`コマンドの出力と一致する必要があります。 +> - 上記のコマンドを実行する際にオプション`--load-creds`を指定した場合、エンコードされたBase64文字列には、現在のBR環境から読み込まれた認証情報が含まれます。適切なセキュリティとアクセス制御を確保するためにご注意ください。 +> - `--storage`の値は、ログ バックアップ タスクの`log status`コマンドの出力と一致する必要があります。 #### ステップ2: ログ圧縮を実行する {#step-2-execute-log-compaction} @@ -63,10 +63,10 @@ tikv-ctl --log-level info compact-log-backup \ パラメータの説明: -- `-s` : 前の手順で取得したBase64エンコード文字列。 -- `-N` : 同時ログ圧縮タスクの最大数。 -- `--from` : 圧縮の開始タイムスタンプ。 -- `--until` : 圧縮の終了タイムスタンプ。 +- `-s` : 前の手順で取得したBase64エンコード文字列。 +- `-N` : 同時ログ圧縮タスクの最大数。 +- `--from` : 圧縮の開始タイムスタンプ。 +- `--until` : 圧縮の終了タイムスタンプ。 パラメータ`--from`と`--until`は、圧縮操作の時間範囲を定義します。圧縮操作では、指定された時間範囲内の書き込み操作を含むすべてのログファイルが処理されるため、生成されるSSTファイルにはこの範囲外のデータが含まれる場合があります。 diff --git a/br/br-incremental-guide.md b/br/br-incremental-guide.md index 2c0595c6f67d4..c8b1b41970fdf 100644 --- a/br/br-incremental-guide.md +++ b/br/br-incremental-guide.md @@ -19,9 +19,9 @@ TiDBクラスターの増分データは、期間の開始スナップショッ バージョン8.3.0以降、増分バックアップと後続のログバックアップの互換性を制御するための構成パラメータ`--allow-pitr-from-incremental`が導入されました。デフォルト値は`true`で、増分バックアップと後続のログバックアップの互換性があることを意味します。 -- デフォルト値`true`ままにしておくと、増分リストアを開始する前に、再生が必要なDDLが厳密にチェックされます。このモードでは、 `ADD INDEX` 、 `MODIFY COLUMN` 、 `REORG PARTITION`まだサポートされていません。増分バックアップとログバックアップを併用する場合は、増分バックアッププロセス中に、前述のDDLが存在しないことを確認してください。そうでない場合、これら3つのDDLを正しく再生できません。 +- デフォルト値`true`ままにしておくと、増分リストアを開始する前に、再生が必要なDDLが厳密にチェックされます。このモードでは、 `ADD INDEX` 、 `MODIFY COLUMN` 、 `REORG PARTITION`まだサポートされていません。増分バックアップとログバックアップを併用する場合は、増分バックアッププロセス中に、前述のDDLが存在しないことを確認してください。そうでない場合、これら3つのDDLを正しく再生できません。 -- リカバリプロセス全体でログ バックアップなしで増分復元を使用する場合は、 `--allow-pitr-from-incremental`から`false`設定して増分リカバリ フェーズでのチェックをスキップできます。 +- リカバリプロセス全体でログ バックアップなしで増分復元を使用する場合は、 `--allow-pitr-from-incremental`から`false`設定して増分リカバリ フェーズでのチェックをスキップできます。 ## 増分データをバックアップする {#back-up-incremental-data} @@ -40,9 +40,9 @@ tiup br backup full --pd "${PD_IP}:2379" \ --ratelimit 128 ``` -- `--lastbackupts` : 最後のバックアップのタイムスタンプ。 -- `--ratelimit` : バックアップ タスクを実行する**TiKV あたりの**最大速度 (MiB/秒)。 -- `storage` : バックアップデータのストレージパス。増分バックアップデータは、前回のスナップショットバックアップとは異なるパスに保存する必要があります。上記の例では、増分バックアップデータはフルバックアップデータの下の`incr`ディレクトリに保存されます。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 +- `--lastbackupts` : 最後のバックアップのタイムスタンプ。 +- `--ratelimit` : バックアップ タスクを実行する**TiKV あたりの**最大速度 (MiB/秒)。 +- `storage` : バックアップデータのストレージパス。増分バックアップデータは、前回のスナップショットバックアップとは異なるパスに保存する必要があります。上記の例では、増分バックアップデータはフルバックアップデータの下の`incr`ディレクトリに保存されます。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 ## 増分データを復元する {#restore-incremental-data} diff --git a/br/br-log-architecture.md b/br/br-log-architecture.md index 33f82c0c91db5..c20a1f7b14e86 100644 --- a/br/br-log-architecture.md +++ b/br/br-log-architecture.md @@ -49,37 +49,37 @@ sequenceDiagram ログバックアッププロセスに関わるシステムコンポーネントと主要概念： -- **ローカルメタデータ**：ローカルチェックポイントts、グローバルチェックポイントts、バックアップファイル情報など、単一のTiKVノードによってバックアップされたメタデータを示します。 -- **ローカルチェックポイント ts** (ローカルメタデータ内): この TiKV ノードでローカルチェックポイント ts より前に生成されたすべてのログがターゲットストレージにバックアップされたことを示します。 -- **グローバルチェックポイント ts** ：すべての TiKV ノードでグローバルチェックポイント ts より前に生成されたすべてのログがターゲットストレージにバックアップされたことを示します。TiDB コーディネーターは、すべての TiKV ノードのローカルチェックポイント ts を収集してこのタイムスタンプを計算し、PD に報告します。 -- **TiDBコーディネーター**：TiDBノードがコーディネーターとして選出され、ログバックアップタスク全体（グローバルチェックポイントタスク）の進捗状況を収集および計算する役割を担います。このコンポーネントはステートレスな設計となっており、障害発生後は、稼働中のTiDBノードから新しいコーディネーターが選出されます。 -- **TiKVログバックアップオブザーバー**：TiDBクラスタ内の各TiKVノードで実行され、ログデータのバックアップを担当します。TiKVノードに障害が発生した場合、リージョンリーダーの再選出後、他のTiKVノードがそのノードのデータ範囲のバックアップを引き継ぎ、グローバルチェックポイントtsから始まる障害範囲のデータをバックアップします。 +- **ローカルメタデータ**：ローカルチェックポイントts、グローバルチェックポイントts、バックアップファイル情報など、単一のTiKVノードによってバックアップされたメタデータを示します。 +- **ローカルチェックポイント ts** (ローカルメタデータ内): この TiKV ノードでローカルチェックポイント ts より前に生成されたすべてのログがターゲットストレージにバックアップされたことを示します。 +- **グローバルチェックポイント ts** ：すべての TiKV ノードでグローバルチェックポイント ts より前に生成されたすべてのログがターゲットストレージにバックアップされたことを示します。TiDB コーディネーターは、すべての TiKV ノードのローカルチェックポイント ts を収集してこのタイムスタンプを計算し、PD に報告します。 +- **TiDBコーディネーター**：TiDBノードがコーディネーターとして選出され、ログバックアップタスク全体（グローバルチェックポイントタスク）の進捗状況を収集および計算する役割を担います。このコンポーネントはステートレスな設計となっており、障害発生後は、稼働中のTiDBノードから新しいコーディネーターが選出されます。 +- **TiKVログバックアップオブザーバー**：TiDBクラスタ内の各TiKVノードで実行され、ログデータのバックアップを担当します。TiKVノードに障害が発生した場合、リージョンリーダーの再選出後、他のTiKVノードがそのノードのデータ範囲のバックアップを引き継ぎ、グローバルチェックポイントtsから始まる障害範囲のデータをバックアップします。 バックアップの全手順は以下のとおりです。 -1. BR は`br log start`コマンドを受信します。 +1. BR は`br log start`コマンドを受信します。 - - BRは、バックアップタスクのチェックポイントts（ログバックアップの開始時刻）とストレージパスを解析します。 - - **ログバックアップタスクの登録**： BRはPDにログバックアップタスクを登録します。 + - BRは、バックアップタスクのチェックポイントts（ログバックアップの開始時刻）とストレージパスを解析します。 + - **ログバックアップタスクの登録**： BRはPDにログバックアップタスクを登録します。 -2. TiKVは、ログバックアップタスクの作成と更新を監視します。 +2. TiKVは、ログバックアップタスクの作成と更新を監視します。 - - **ログバックアップタスクの取得**：各TiKVノードのログバックアップオブザーバーは、PDからログバックアップタスクを取得し、指定された範囲のログデータをバックアップします。 + - **ログバックアップタスクの取得**：各TiKVノードのログバックアップオブザーバーは、PDからログバックアップタスクを取得し、指定された範囲のログデータをバックアップします。 -3. ログバックアップオブザーバーは、KVの変更ログを継続的にバックアップします。 +3. ログバックアップオブザーバーは、KVの変更ログを継続的にバックアップします。 - - **Read kv Change data** : KV 変更データを読み取り、変更ログ[カスタム形式でバックアップファイル](#log-backup-files)に保存します。 - - **グローバルチェックポイントtsの取得**：PDからグローバルチェックポイントtsを取得します。 - - **ローカルメタデータの生成**：ローカルチェックポイントts、グローバルチェックポイントts、バックアップファイル情報など、バックアップタスクのローカルメタデータを生成します。 - - **ログデータとメタデータのアップロード**：バックアップファイルとローカルメタデータを定期的にターゲットストレージにアップロードします。 - - **GC の設定**: PD に対して、バックアップされていないデータ (ローカル チェックポイント ts より大きいデータ) が[TiDB GCメカニズム](/garbage-collection-overview.md)によって再利用されないように要求します。 + - **Read kv Change data** : KV 変更データを読み取り、変更ログ[カスタム形式でバックアップファイル](#log-backup-files)に保存します。 + - **グローバルチェックポイントtsの取得**：PDからグローバルチェックポイントtsを取得します。 + - **ローカルメタデータの生成**：ローカルチェックポイントts、グローバルチェックポイントts、バックアップファイル情報など、バックアップタスクのローカルメタデータを生成します。 + - **ログデータとメタデータのアップロード**：バックアップファイルとローカルメタデータを定期的にターゲットストレージにアップロードします。 + - **GC の設定**: PD に対して、バックアップされていないデータ (ローカル チェックポイント ts より大きいデータ) が[TiDB GCメカニズム](/garbage-collection-overview.md)によって再利用されないように要求します。 -4. TiDBコーディネーターは、ログバックアップタスクの進行状況を監視します。 +4. TiDBコーディネーターは、ログバックアップタスクの進行状況を監視します。 - - **バックアップの進行状況を監視する**: すべての TiKV ノードをポーリングすることにより、各リージョン(リージョンチェックポイント ts) のバックアップの進行状況を取得します。 - - **グローバルチェックポイントtsの報告**：リージョンチェックポイントtsに基づいてログバックアップタスク全体（グローバルチェックポイントts）の進行状況を計算し、グローバルチェックポイントtsをPDに報告します。 + - **バックアップの進行状況を監視する**: すべての TiKV ノードをポーリングすることにより、各リージョン(リージョンチェックポイント ts) のバックアップの進行状況を取得します。 + - **グローバルチェックポイントtsの報告**：リージョンチェックポイントtsに基づいてログバックアップタスク全体（グローバルチェックポイントts）の進行状況を計算し、グローバルチェックポイントtsをPDに報告します。 -5. PD はログバックアップタスクの状態を保持しており、 `br log status`を使用して表示できます。 +5. PD はログバックアップタスクの状態を保持しており、 `br log status`を使用して表示できます。 ## PITRのプロセス {#process-of-pitr} @@ -111,46 +111,46 @@ sequenceDiagram PITRの全プロセスは以下のとおりです。 -1. BR は`br restore point`コマンドを受信します。 +1. BR は`br restore point`コマンドを受信します。 - - BRは、フルバックアップデータのアドレス、ログバックアップデータのアドレス、およびポイントインタイムリカバリ時間を解析します。 - - バックアップデータ内の復元対象（データベースまたはテーブル）を照会し、復元対象のテーブルが存在し、復元要件を満たしているかどうかを確認します。 + - BRは、フルバックアップデータのアドレス、ログバックアップデータのアドレス、およびポイントインタイムリカバリ時間を解析します。 + - バックアップデータ内の復元対象（データベースまたはテーブル）を照会し、復元対象のテーブルが存在し、復元要件を満たしているかどうかを確認します。 -2. BRはバックアップデータを完全に復元します。 +2. BRはバックアップデータを完全に復元します。 - - 完全なバックアップ データを復元します。スナップショットバックアップデータの復元プロセスの詳細については、 [スナップショットバックアップデータを復元する](/br/br-snapshot-architecture.md#process-of-restore)を参照してください。 + - 完全なバックアップ データを復元します。スナップショットバックアップデータの復元プロセスの詳細については、 [スナップショットバックアップデータを復元する](/br/br-snapshot-architecture.md#process-of-restore)を参照してください。 -3. BRはログバックアップデータを復元します。 +3. BRはログバックアップデータを復元します。 - - **バックアップデータの読み取り**：ログバックアップデータを読み取り、復元する必要のあるログバックアップデータを計算します。 - - **リージョン情報の取得**: PD にアクセスして、すべてのリージョンのディストリビューションを取得します。 - - **TiKVにデータ復元を要求する**：ログ復元要求を作成し、対応するTiKVノードに送信します。ログ復元要求には、復元するログバックアップデータの情報が含まれています。 + - **バックアップデータの読み取り**：ログバックアップデータを読み取り、復元する必要のあるログバックアップデータを計算します。 + - **リージョン情報の取得**: PD にアクセスして、すべてのリージョンのディストリビューションを取得します。 + - **TiKVにデータ復元を要求する**：ログ復元要求を作成し、対応するTiKVノードに送信します。ログ復元要求には、復元するログバックアップデータの情報が含まれています。 -4. TiKVはBRからの復元要求を受け入れ、ログ復元ワーカーを起動します。 +4. TiKVはBRからの復元要求を受け入れ、ログ復元ワーカーを起動します。 - - ログ復元ワーカーは、復元する必要のあるログバックアップデータを取得します。 + - ログ復元ワーカーは、復元する必要のあるログバックアップデータを取得します。 -5. TiKVはログバックアップデータを復元します。 +5. TiKVはログバックアップデータを復元します。 - - **KVのダウンロード**：ログ復元ワーカーは、ログ復元要求に従って、バックアップストレージから対応するバックアップデータをローカルディレクトリにダウンロードします。 - - **KVの書き換え**：ログ復元ワーカーは、復元クラスタテーブルのテーブルIDに基づいてバックアップデータのKVデータを書き換えます。つまり、 [キー値](/tidb-computing.md#mapping-table-data-to-key-value)内の元のテーブルIDを新しいテーブルIDに置き換えます。復元ワーカーは、インデックスIDも同様に書き換えます。 - - **KVの適用**：ログ復元ワーカーは、処理されたKVデータをRaftインターフェースを介してストア（RocksDB）に書き込みます。 - - **レポート復元結果**: ログ復元ワーカーは復元結果をBRに返します。 + - **KVのダウンロード**：ログ復元ワーカーは、ログ復元要求に従って、バックアップストレージから対応するバックアップデータをローカルディレクトリにダウンロードします。 + - **KVの書き換え**：ログ復元ワーカーは、復元クラスタテーブルのテーブルIDに基づいてバックアップデータのKVデータを書き換えます。つまり、 [キー値](/tidb-computing.md#mapping-table-data-to-key-value)内の元のテーブルIDを新しいテーブルIDに置き換えます。復元ワーカーは、インデックスIDも同様に書き換えます。 + - **KVの適用**：ログ復元ワーカーは、処理されたKVデータをRaftインターフェースを介してストア（RocksDB）に書き込みます。 + - **レポート復元結果**: ログ復元ワーカーは復元結果をBRに返します。 -6. BRは各TiKVノードから復元結果を受け取ります。 +6. BRは各TiKVノードから復元結果を受け取ります。 - - 例えば ​​TiKV ノードがダウンしている場合など、 `RegionNotFound`または`EpochNotMatch`が原因でデータの復元に失敗した場合、 BR は復元を再試行します。 - - 復元に失敗し、再試行もできない場合、復元タスクは失敗します。 - - すべてのデータが復元されると、復元タスクは成功します。 + - 例えば ​​TiKV ノードがダウンしている場合など、 `RegionNotFound`または`EpochNotMatch`が原因でデータの復元に失敗した場合、 BR は復元を再試行します。 + - 復元に失敗し、再試行もできない場合、復元タスクは失敗します。 + - すべてのデータが復元されると、復元タスクは成功します。 ## ログバックアップファイル {#log-backup-files} ログバックアップでは、以下の種類のファイルが生成されます。 -- `{flushTs}-{minDefaultTs}-{minTs}-{maxTs}.meta`ファイル: 各 TiKV ノードがログ バックアップ データをアップロードするたびに生成され、今回アップロードされたすべてのログ バックアップ データ ファイルのメタデータが保存されます。ファイル名の各フィールドの意味については、[バックアップファイルの構造](#structure-of-backup-files)を参照してください。 -- `{store_id}.ts`ファイル: 各 TiKV ノードがログバックアップデータをアップロードするたびに、グローバルチェックポイント ts で更新されます。 `{store_id}`は TiKV ノードのストア ID です。 -- `{min_ts}-{uuid}.log`ファイル: バックアップ タスクの KV 変更ログ データを格納します。 `{min_ts}`は、ファイル内の KV 変更ログ データの最小 TSO タイムスタンプであり、 `{uuid}`はファイル作成時にランダムに生成されます。 -- `v1_stream_truncate_safepoint.txt`ファイル: `br log truncate`によって削除されたストレージ内の最新のバックアップデータに対応するタイムスタンプを保存します。 +- `{flushTs}-{minDefaultTs}-{minTs}-{maxTs}.meta`ファイル: 各 TiKV ノードがログ バックアップ データをアップロードするたびに生成され、今回アップロードされたすべてのログ バックアップ データ ファイルのメタデータが保存されます。ファイル名の各フィールドの意味については、[バックアップファイルの構造](#structure-of-backup-files)を参照してください。 +- `{store_id}.ts`ファイル: 各 TiKV ノードがログバックアップデータをアップロードするたびに、グローバルチェックポイント ts で更新されます。 `{store_id}`は TiKV ノードのストア ID です。 +- `{min_ts}-{uuid}.log`ファイル: バックアップ タスクの KV 変更ログ データを格納します。 `{min_ts}`は、ファイル内の KV 変更ログ データの最小 TSO タイムスタンプであり、 `{uuid}`はファイル作成時にランダムに生成されます。 +- `v1_stream_truncate_safepoint.txt`ファイル: `br log truncate`によって削除されたストレージ内の最新のバックアップデータに対応するタイムスタンプを保存します。 ### バックアップファイルの構造 {#structure-of-backup-files} @@ -172,17 +172,17 @@ PITRの全プロセスは以下のとおりです。 バックアップファイルディレクトリ構造の説明： -- `backupmeta`ディレクトリ: バックアップメタデータファイルを保存します。v8.5.3 以降、これらのファイルの命名規則は`{resolved_ts}-{uuid}.meta`から`{flushTs}-{minDefaultTs}-{minTs}-{maxTs}.meta`に変更されます。ファイル名には、次のタイムスタンプフィールドが含まれます。 +- `backupmeta`ディレクトリ: バックアップメタデータファイルを保存します。v8.5.3 以降、これらのファイルの命名規則は`{resolved_ts}-{uuid}.meta`から`{flushTs}-{minDefaultTs}-{minTs}-{maxTs}.meta`に変更されます。ファイル名には、次のタイムスタンプフィールドが含まれます。 - - `flushTs` : バックアップファイルが定期的に外部ストレージにアップロードされる際のタイムスタンプ。この値はPDから取得され、グローバルに一意です。 - - `minDefaultTs` （書き込みCFファイルのみに適用）：このバックアップでカバーされる最も早いトランザクション開始時刻。 - - `minTs`および`maxTs` : バックアップ ファイルに含まれるすべてのキー値データの最小および最大タイムスタンプ。 + - `flushTs` : バックアップファイルが定期的に外部ストレージにアップロードされる際のタイムスタンプ。この値はPDから取得され、グローバルに一意です。 + - `minDefaultTs` （書き込みCFファイルのみに適用）：このバックアップでカバーされる最も早いトランザクション開始時刻。 + - `minTs`および`maxTs` : バックアップ ファイルに含まれるすべてのキー値データの最小および最大タイムスタンプ。 これらのタイムスタンプはすべて、長さが一定になるように左側にゼロを埋め込んだ、固定長の16桁の16進数文字列としてエンコードされます。このエンコード方式により、ファイル名が自然に辞書順にソートされるため、外部ストレージシステムでのバッチリスト表示や範囲フィルタリング操作を効率的に実行できます。 -- `global_checkpoint` : グローバルバックアップの進行状況を表します。これは`br restore point`を使用してデータを復元できる最新の時点を記録します。 +- `global_checkpoint` : グローバルバックアップの進行状況を表します。これは`br restore point`を使用してデータを復元できる最新の時点を記録します。 -- `{date}/{hour}` ：対応する日付と時刻のバックアップデータを保存します。ストレージをクリーンアップする際は、手動でデータを削除するのではなく、必ず`br log truncate`を使用してください。これは、メタデータがこのディレクトリ内のデータを参照しているため、手動で削除すると復元失敗や復元後のデータ不整合が発生する可能性があるためです。 +- `{date}/{hour}` ：対応する日付と時刻のバックアップデータを保存します。ストレージをクリーンアップする際は、手動でデータを削除するのではなく、必ず`br log truncate`を使用してください。これは、メタデータがこのディレクトリ内のデータを参照しているため、手動で削除すると復元失敗や復元後のデータ不整合が発生する可能性があるためです。 以下は一例です。 diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md index 1daf9df1e0520..4055e72d4d42d 100644 --- a/br/br-monitoring-and-alert.md +++ b/br/br-monitoring-and-alert.md @@ -17,13 +17,13 @@ summary: このドキュメントでは、ログバックアップの監視、 ### 監視構成 {#monitoring-configuration} -- TiUPを使用してデプロイされたクラスターの場合、Prometheus は監視メトリックを自動的に収集します。 -- 手動でデプロイされたクラスターの場合は、 [TiDBクラスタ監視の展開](/deploy-monitoring-services.md)の手順に従って、Prometheus 構成ファイルの`scrape_configs`セクションに TiKV 関連のジョブを追加します。 +- TiUPを使用してデプロイされたクラスターの場合、Prometheus は監視メトリックを自動的に収集します。 +- 手動でデプロイされたクラスターの場合は、 [TiDBクラスタ監視の展開](/deploy-monitoring-services.md)の手順に従って、Prometheus 構成ファイルの`scrape_configs`セクションに TiKV 関連のジョブを追加します。 ### Grafanaの設定 {#grafana-configuration} -- TiUPを使用してデプロイされたクラスターの場合、ダッシュボード[Grafana](https://grafana.com/)にポイントインタイムリカバリ (PITR) パネルが表示されます。TiKV-Details ダッシュボードの**バックアップログ**パネルが PITR パネルです。 -- 手動でデプロイされたクラスターの場合は、 [Grafanaダッシュボードをインポートする](/deploy-monitoring-services.md#step-2-import-a-grafana-dashboard)を参照し、 [tikv_詳細](https://github.com/tikv/tikv/blob/release-8.5/metrics/grafana/tikv_details.json) JSON ファイルを Grafana にアップロードしてください。その後、TiKV-Details ダッシュボードの**バックアップログ**パネルを見つけてください。 +- TiUPを使用してデプロイされたクラスターの場合、ダッシュボード[Grafana](https://grafana.com/)にポイントインタイムリカバリ (PITR) パネルが表示されます。TiKV-Details ダッシュボードの**バックアップログ**パネルが PITR パネルです。 +- 手動でデプロイされたクラスターの場合は、 [Grafanaダッシュボードをインポートする](/deploy-monitoring-services.md#step-2-import-a-grafana-dashboard)を参照し、 [tikv_詳細](https://github.com/tikv/tikv/blob/release-8.5/metrics/grafana/tikv_details.json) JSON ファイルを Grafana にアップロードしてください。その後、TiKV-Details ダッシュボードの**バックアップログ**パネルを見つけてください。 ### 監視メトリクス {#monitoring-metrics} @@ -60,17 +60,17 @@ summary: このドキュメントでは、ログバックアップの監視、 PITR でアラート項目を構成するには、次の手順に従います。 -1. Prometheusが配置されているノードのアラートルール用の設定ファイル（例： `pitr.rules.yml` ）を作成します。このファイルには、 [Prometheusのドキュメント](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/) 、以下の推奨アラート項目、および設定サンプルに従ってアラートルールを記述します。 -2. Prometheus 構成ファイルの`rule_files`フィールドに、アラート ルール ファイルのパスを追加します。 -3. Prometheusプロセスにシグナル`SIGHUP`送信するか（ `kill -HUP pid` ）、HTTPリクエスト`POST`を`http://prometheus-addr/-/reload`に送信します（HTTPリクエストを送信する前に、Prometheusの起動時にパラメータ`--web.enable-lifecycle`を追加します）。 +1. Prometheusが配置されているノードのアラートルール用の設定ファイル（例： `pitr.rules.yml` ）を作成します。このファイルには、 [Prometheusのドキュメント](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/) 、以下の推奨アラート項目、および設定サンプルに従ってアラートルールを記述します。 +2. Prometheus 構成ファイルの`rule_files`フィールドに、アラート ルール ファイルのパスを追加します。 +3. Prometheusプロセスにシグナル`SIGHUP`送信するか（ `kill -HUP pid` ）、HTTPリクエスト`POST`を`http://prometheus-addr/-/reload`に送信します（HTTPリクエストを送信する前に、Prometheusの起動時にパラメータ`--web.enable-lifecycle`を追加します）。 推奨されるアラート項目は次のとおりです。 #### ログバックアップ実行RPO10分以上 {#logbackuprunningrpomorethan10m} -- 警告項目: `max(time() - tidb_log_backup_last_checkpoint / 262144000) by (task) / 60 > 10 and max(tidb_log_backup_last_checkpoint) by (task) > 0 and max(tikv_log_backup_task_status) by (task) == 0` -- 警戒レベル：警告 -- 説明: ログデータが10分以上ストレージに保存されていません。このアラートはリマインダーです。ほとんどの場合、ログバックアップには影響しません。 +- 警告項目: `max(time() - tidb_log_backup_last_checkpoint / 262144000) by (task) / 60 > 10 and max(tidb_log_backup_last_checkpoint) by (task) > 0 and max(tikv_log_backup_task_status) by (task) == 0` +- 警戒レベル：警告 +- 説明: ログデータが10分以上ストレージに保存されていません。このアラートはリマインダーです。ほとんどの場合、ログバックアップには影響しません。 このアラート項目の構成サンプルは次のとおりです。 @@ -89,30 +89,30 @@ groups: #### ログバックアップ実行RPO30分以上 {#logbackuprunningrpomorethan30m} -- 警告項目: `max(time() - tidb_log_backup_last_checkpoint / 262144000) by (task) / 60 > 30 and max(tidb_log_backup_last_checkpoint) by (task) > 0 and max(tikv_log_backup_task_status) by (task) == 0` -- 警戒レベル: 重大 -- 説明: ログデータが30分以上ストレージに保存されていません。このアラートは多くの場合、異常を示しています。原因を特定するには、TiKVログを確認してください。 +- 警告項目: `max(time() - tidb_log_backup_last_checkpoint / 262144000) by (task) / 60 > 30 and max(tidb_log_backup_last_checkpoint) by (task) > 0 and max(tikv_log_backup_task_status) by (task) == 0` +- 警戒レベル: 重大 +- 説明: ログデータが30分以上ストレージに保存されていません。このアラートは多くの場合、異常を示しています。原因を特定するには、TiKVログを確認してください。 #### ログバックアップ一時停止中 (2 時間以上) {#logbackuppausingmorethan2h} -- 警告項目: `max(time() - tidb_log_backup_last_checkpoint / 262144000) by (task) / 3600 > 2 and max(tidb_log_backup_last_checkpoint) by (task) > 0 and max(tikv_log_backup_task_status) by (task) == 1` -- 警戒レベル：警告 -- 説明: ログバックアップタスクが2時間以上一時停止されています。このアラートはリマインダーであり、できるだけ早く`br log resume`を実行してください。 +- 警告項目: `max(time() - tidb_log_backup_last_checkpoint / 262144000) by (task) / 3600 > 2 and max(tidb_log_backup_last_checkpoint) by (task) > 0 and max(tikv_log_backup_task_status) by (task) == 1` +- 警戒レベル：警告 +- 説明: ログバックアップタスクが2時間以上一時停止されています。このアラートはリマインダーであり、できるだけ早く`br log resume`を実行してください。 #### ログバックアップ一時停止中（12時間以上） {#logbackuppausingmorethan12h} -- 警告項目: `max(time() - tidb_log_backup_last_checkpoint / 262144000) by (task) / 3600 > 12 and max(tidb_log_backup_last_checkpoint) by (task) > 0 and max(tikv_log_backup_task_status) by (task) == 1` -- 警戒レベル: 重大 -- 説明: ログバックアップタスクが12時間以上一時停止されています。タスクを再開するには、できるだけ早く`br log resume`を実行してください。ログタスクの一時停止時間が長すぎると、データが失われるリスクがあります。 +- 警告項目: `max(time() - tidb_log_backup_last_checkpoint / 262144000) by (task) / 3600 > 12 and max(tidb_log_backup_last_checkpoint) by (task) > 0 and max(tikv_log_backup_task_status) by (task) == 1` +- 警戒レベル: 重大 +- 説明: ログバックアップタスクが12時間以上一時停止されています。タスクを再開するには、できるだけ早く`br log resume`を実行してください。ログタスクの一時停止時間が長すぎると、データが失われるリスクがあります。 #### ログバックアップ失敗 {#logbackupfailed} -- 警告項目: `max(tikv_log_backup_task_status) by (task) == 2 and max(tidb_log_backup_last_checkpoint) by (task) > 0` -- 警戒レベル: 重大 -- 説明: ログバックアップタスクが失敗しました。失敗の原因を確認するには、 `br log status`を実行する必要があります。必要に応じて、TiKV ログをさらに確認する必要があります。 +- 警告項目: `max(tikv_log_backup_task_status) by (task) == 2 and max(tidb_log_backup_last_checkpoint) by (task) > 0` +- 警戒レベル: 重大 +- 説明: ログバックアップタスクが失敗しました。失敗の原因を確認するには、 `br log status`を実行する必要があります。必要に応じて、TiKV ログをさらに確認する必要があります。 #### ログバックアップGCセーフポイントがチェックポイントを超える {#logbackupgcsafepointexceedscheckpoint} -- 警告項目: `min(tidb_log_backup_last_checkpoint) by (instance) - max(tikv_gcworker_autogc_safe_point) by (instance) < 0` -- 警戒レベル: 重大 -- 説明: バックアップ前に一部のデータがガベージコレクションされました。これは、一部のデータが失われており、サービスに影響を与える可能性が非常に高いことを意味します。 +- 警告項目: `min(tidb_log_backup_last_checkpoint) by (instance) - max(tikv_gcworker_autogc_safe_point) by (instance) < 0` +- 警戒レベル: 重大 +- 説明: バックアップ前に一部のデータがガベージコレクションされました。これは、一部のデータが失われており、サービスに影響を与える可能性が非常に高いことを意味します。 diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md index 1ef9b97e4ef1d..cf02125afacbd 100644 --- a/br/br-pitr-guide.md +++ b/br/br-pitr-guide.md @@ -15,8 +15,8 @@ br コマンドライン ツール (以下、 `br`と呼びます) を使用し > **Note:** > -> - 以下の例では、Amazon S3 アクセスキーとシークレットキーを使用して権限を承認することを前提としています。IAM ロールを使用して権限を承認する場合は、 `--send-credentials-to-tikv`を`false`に設定する必要があります。 -> - 他のストレージシステムまたは認証方法を使用して権限を認証する場合は、 [バックアップストレージ](/br/backup-and-restore-storages.md)に従ってパラメータ設定を調整します。 +> - 以下の例では、Amazon S3 アクセスキーとシークレットキーを使用して権限を承認することを前提としています。IAM ロールを使用して権限を承認する場合は、 `--send-credentials-to-tikv`を`false`に設定する必要があります。 +> - 他のストレージシステムまたは認証方法を使用して権限を認証する場合は、 [バックアップストレージ](/br/backup-and-restore-storages.md)に従ってパラメータ設定を調整します。 ログ バックアップを開始するには、 `tiup br log start`を実行します。クラスターは 1 回につき 1 つのログ バックアップ タスクのみ実行できます。 @@ -49,26 +49,26 @@ checkpoint[global]: 2022-05-13 11:31:47.2 +0800; gap=4m53s フィールドの説明は次のとおりです。 -- `name` : ログ バックアップ タスクの名前。 -- `status` : ログ バックアップ タスクのステータス`NORMAL` 、 `PAUSED` 、 `ERROR`を含む)。 -- `start` : ログ バックアップ タスクの開始タイムスタンプ。 -- `end` : ログバックアップタスクの終了タイムスタンプ。現在、このフィールドは無効です。 -- `storage` : ログ バックアップの外部ストレージの URI。 -- `speed(est.)` : ログバックアップの現在のデータ転送速度。この値は、過去数秒間に取得されたトラフィックサンプルに基づいて推定されます。より正確なトラフィック統計情報については、Grafanaの**TiKV-Details**ダッシュボードの`Log Backup`行を確認してください。 -- `checkpoint[global]` : ログバックアップの現在の進行状況。PITRを使用して、このタイムスタンプより前の時点に復元できます。 +- `name` : ログ バックアップ タスクの名前。 +- `status` : ログ バックアップ タスクのステータス`NORMAL` 、 `PAUSED` 、 `ERROR`を含む)。 +- `start` : ログ バックアップ タスクの開始タイムスタンプ。 +- `end` : ログバックアップタスクの終了タイムスタンプ。現在、このフィールドは無効です。 +- `storage` : ログ バックアップの外部ストレージの URI。 +- `speed(est.)` : ログバックアップの現在のデータ転送速度。この値は、過去数秒間に取得されたトラフィックサンプルに基づいて推定されます。より正確なトラフィック統計情報については、Grafanaの**TiKV-Details**ダッシュボードの`Log Backup`行を確認してください。 +- `checkpoint[global]` : ログバックアップの現在の進行状況。PITRを使用して、このタイムスタンプより前の時点に復元できます。 ログバックアップタスクが一時停止されている場合、 `log status`コマンドは一時停止の詳細を表示するための追加フィールドを出力します。これらは次のとおりです。 -- `pause-time` : 一時停止操作が実行される時刻。 -- `pause-operator` : 一時停止操作を実行するマシンのホスト名。 -- `pause-operator-pid` : 一時停止操作を実行するプロセスの PID。 -- `pause-payload` : タスクが一時停止されているときに付加される追加情報。 +- `pause-time` : 一時停止操作が実行される時刻。 +- `pause-operator` : 一時停止操作を実行するマシンのホスト名。 +- `pause-operator-pid` : 一時停止操作を実行するプロセスの PID。 +- `pause-payload` : タスクが一時停止されているときに付加される追加情報。 一時停止の原因が TiKV のエラーである場合は、TiKV からの追加のエラー レポートも表示される場合があります。 -- `error[store=*]` : TiKV のエラー コード。 -- `error-happen-at[store=*]` : TiKV でエラーが発生した時刻。 -- `error-message[store=*]` : TiKV のエラー メッセージ。 +- `error[store=*]` : TiKV のエラー コード。 +- `error-happen-at[store=*]` : TiKV でエラーが発生した時刻。 +- `error-message[store=*]` : TiKV のエラー メッセージ。 ### 定期的に完全バックアップを実行する {#run-full-backup-regularly} @@ -112,21 +112,21 @@ PITRを実行するには、復元ポイントより前のフルバックアッ 次の手順では、バックアップ保持期間を超えたバックアップ データをクリーンアップする方法について説明します。 -1. バックアップ保持期間外の**最後の完全バックアップ**を取得します。 +1. バックアップ保持期間外の**最後の完全バックアップ**を取得します。 -2. `validate`コマンドを使用して、バックアップに対応する時点を取得します。2022/09/01 より前のバックアップデータを消去する必要がある場合、この時点より前の最後の完全バックアップを探し、それが消去されないことを確認する必要があります。 +2. `validate`コマンドを使用して、バックアップに対応する時点を取得します。2022/09/01 より前のバックアップデータを消去する必要がある場合、この時点より前の最後の完全バックアップを探し、それが消去されないことを確認する必要があります。 ```shell FULL_BACKUP_TS=`tiup br validate decode --field="end-version" --storage "s3://backup-101/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}"| tail -n1` ``` -3. スナップショットバックアップ`FULL_BACKUP_TS`より前のログバックアップデータを削除します。 +3. スナップショットバックアップ`FULL_BACKUP_TS`より前のログバックアップデータを削除します。 ```shell tiup br log truncate --until=${FULL_BACKUP_TS} --storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' ``` -4. スナップショットバックアップ`FULL_BACKUP_TS`より前のスナップショットデータを削除します。 +4. スナップショットバックアップ`FULL_BACKUP_TS`より前のスナップショットデータを削除します。 ```shell aws s3 rm --recursive s3://backup-101/snapshot-${date} @@ -134,40 +134,40 @@ PITRを実行するには、復元ポイントより前のフルバックアッ ## PITRのパフォーマンス機能 {#performance-capabilities-of-pitr} -- 各 TiKV ノードでは、PITR はスナップショット データ (完全復元) を 2 TiB/h の速度で復元し、ログ データ (メタ ファイルと KV ファイルを含む) を 30 GiB/h の速度で復元できます。 -- BRは古くなったログバックアップデータ（ `tiup br log truncate` ）を600GB/hの速度で削除します。 +- 各 TiKV ノードでは、PITR はスナップショット データ (完全復元) を 2 TiB/h の速度で復元し、ログ データ (メタ ファイルと KV ファイルを含む) を 30 GiB/h の速度で復元できます。 +- BRは古くなったログバックアップデータ（ `tiup br log truncate` ）を600GB/hの速度で削除します。 > **Note:** > > 上記の仕様は、以下の2つのテストシナリオのテスト結果に基づいています。実際のデータは異なる場合があります。 > -> - スナップショットデータの復元速度 = クラスター内のすべての TiKV ノードで復元されたスナップショットデータの合計サイズ / (所要時間 * TiKV ノードの数) -> - ログデータの復元速度 = クラスター内のすべての TiKV ノードに復元されたログデータの合計サイズ / (期間 * TiKV ノードの数) +> - スナップショットデータの復元速度 = クラスター内のすべての TiKV ノードで復元されたスナップショットデータの合計サイズ / (所要時間 * TiKV ノードの数) +> - ログデータの復元速度 = クラスター内のすべての TiKV ノードに復元されたログデータの合計サイズ / (期間 * TiKV ノードの数) > > 外部ストレージには、単一のレプリカの KV データのみが含まれます。そのため、外部ストレージのデータ サイズは、クラスターで復元された実際のデータ サイズを表すものではありません。BRは、クラスターに設定されているレプリカの数に応じて、すべてのレプリカを復元します。レプリカの数が多いほど、実際に復元できるデータも多くなります。テストのすべてのクラスターのデフォルトのレプリカ数は 3 です。全体的な復元パフォーマンスを向上させるには、TiKV 設定ファイルの[`import.num-threads`](/tikv-configuration-file.md#import)項目とBRコマンドの[`pitr-concurrency`](/br/br-pitr-manual.md#restore-to-a-specified-point-in-time-pitr)オプションを変更できます。アップストリーム クラスターに**多くのリージョン**があり、**フラッシュ間隔が短い**場合、PITR によって多数の小さなファイルが生成されます。これにより、復元中のバッチ処理とディスパッチのオーバーヘッドが増加します。バッチごとに処理されるファイル数を増やすには、次のパラメーターの値を**適度に**増やすことができます。 > -> - `pitr-batch-size` :**バッチあたりの累積バイト数**(デフォルト**16 MiB** )。 -> - `pitr-batch-count` :**バッチあたりのファイル数**(デフォルトは**8** )。 +> - `pitr-batch-size` :**バッチあたりの累積バイト数**(デフォルト**16 MiB** )。 +> - `pitr-batch-count` :**バッチあたりのファイル数**(デフォルトは**8** )。 > > 次のバッチを開始するかどうかを決定するときに、これら 2 つのしきい値は独立して評価されます。最初にいずれかのしきい値に達した場合、現在のバッチが閉じられ、次のバッチが開始されますが、もう一方のしきい値はそのバッチでは無視されます。 テストシナリオ 1 ( [TiDB Cloud](https://tidbcloud.com)上) は次のとおりです。 -- TiKVノード数（8コア、16GBメモリ）: 21 -- TiKV構成項目`import.num-threads` ：8 -- BRコマンドオプション`pitr-concurrency` ：128 -- リージョン数: 183,000 -- クラスターに作成された新しいログデータ: 10 GB/時間 -- 書き込み（挿入/更新/削除）QPS: 10,000 +- TiKVノード数（8コア、16GBメモリ）: 21 +- TiKV構成項目`import.num-threads` ：8 +- BRコマンドオプション`pitr-concurrency` ：128 +- リージョン数: 183,000 +- クラスターに作成された新しいログデータ: 10 GB/時間 +- 書き込み（挿入/更新/削除）QPS: 10,000 テスト シナリオ 2 (TiDB Self-Managed 上) は次のとおりです。 -- TiKVノード数（8コア、64GBメモリ）: 6 -- TiKV構成項目`import.num-threads` ：8 -- BRコマンドオプション`pitr-concurrency` ：128 -- リージョン数: 50,000 -- クラスターに作成された新しいログデータ: 10 GB/時間 -- 書き込み（挿入/更新/削除）QPS: 10,000 +- TiKVノード数（8コア、64GBメモリ）: 6 +- TiKV構成項目`import.num-threads` ：8 +- BRコマンドオプション`pitr-concurrency` ：128 +- リージョン数: 50,000 +- クラスターに作成された新しいログデータ: 10 GB/時間 +- 書き込み（挿入/更新/削除）QPS: 10,000 ## 監視と警告 {#monitoring-and-alert} @@ -177,7 +177,7 @@ PITRを実行するには、復元ポイントより前のフルバックアッ ## 参照 {#see-also} -- [TiDB バックアップと復元のユースケース](/br/backup-and-restore-use-cases.md) -- [br コマンドラインマニュアル](/br/use-br-command-line-tool.md) -- [ログバックアップとPITRアーキテクチャ](/br/br-log-architecture.md) -- [バックアップと復元の監視とアラート](/br/br-monitoring-and-alert.md) +- [TiDB バックアップと復元のユースケース](/br/backup-and-restore-use-cases.md) +- [br コマンドラインマニュアル](/br/use-br-command-line-tool.md) +- [ログバックアップとPITRアーキテクチャ](/br/br-log-architecture.md) +- [バックアップと復元の監視とアラート](/br/br-monitoring-and-alert.md) diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index 7368d0f159fe0..e05f586b3b272 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -9,8 +9,8 @@ summary: TiDB ログ バックアップとポイントインタイム リカバ ログ バックアップと PITR の詳細については、以下を参照してください。 -- [ログバックアップとPITRガイド](/br/br-pitr-guide.md) -- [バックアップと復元のユースケース](/br/backup-and-restore-use-cases.md) +- [ログバックアップとPITRガイド](/br/br-pitr-guide.md) +- [バックアップと復元のユースケース](/br/backup-and-restore-use-cases.md) ## ログバックアップを実行する {#perform-log-backup} @@ -36,13 +36,13 @@ Available Commands: 各サブコマンドの説明は次のとおりです。 -- `tiup br log start` : ログ バックアップ タスクを開始します。 -- `tiup br log status` : ログ バックアップ タスクのステータスを照会します。 -- `tiup br log pause` : ログ バックアップ タスクを一時停止します。 -- `tiup br log resume` : 一時停止されたログ バックアップ タスクを再開します。 -- `tiup br log stop` : ログ バックアップ タスクを停止し、タスク メタデータを削除します。 -- `tiup br log truncate` : バックアップストレージからログ バックアップ データをクリーンアップします。 -- `tiup br log metadata` : ログ バックアップ データのメタデータを照会します。 +- `tiup br log start` : ログ バックアップ タスクを開始します。 +- `tiup br log status` : ログ バックアップ タスクのステータスを照会します。 +- `tiup br log pause` : ログ バックアップ タスクを一時停止します。 +- `tiup br log resume` : 一時停止されたログ バックアップ タスクを再開します。 +- `tiup br log stop` : ログ バックアップ タスクを停止し、タスク メタデータを削除します。 +- `tiup br log truncate` : バックアップストレージからログ バックアップ データをクリーンアップします。 +- `tiup br log metadata` : ログ バックアップ データのメタデータを照会します。 ### ログバックアップタスクを開始する {#start-a-log-backup-task} @@ -73,11 +73,11 @@ Global Flags: 出力例には共通パラメータのみが表示されています。これらのパラメータは以下のように記述されます。 -- `--start-ts` : ログバックアップの開始タイムスタンプを指定します。このパラメータが指定されていない場合、バックアッププログラムは現在の時刻を`start-ts`として使用します。 -- `task-name` : ログバックアップのタスク名を指定します。この名前は、バックアップタスクのクエリ、一時停止、再開にも使用されます。 -- `--ca` 、 `--cert` 、 `--key` : TiKVおよびPDと通信するためのmTLS暗号化方式を指定します。 -- `--pd` : バックアップ クラスターの PD アドレスを指定します。BRはログ バックアップ タスクを開始するために PD にアクセスする必要があります。 -- `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのストレージとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 +- `--start-ts` : ログバックアップの開始タイムスタンプを指定します。このパラメータが指定されていない場合、バックアッププログラムは現在の時刻を`start-ts`として使用します。 +- `task-name` : ログバックアップのタスク名を指定します。この名前は、バックアップタスクのクエリ、一時停止、再開にも使用されます。 +- `--ca` 、 `--cert` 、 `--key` : TiKVおよびPDと通信するためのmTLS暗号化方式を指定します。 +- `--pd` : バックアップ クラスターの PD アドレスを指定します。BRはログ バックアップ タスクを開始するために PD にアクセスする必要があります。 +- `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのストレージとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 使用例: @@ -94,9 +94,9 @@ BR を使用すると、ログ バックアップ データをバックアップ TiDB v8.4.0 以降では、ログ バックアップ コマンドで次のパラメータ ( [スナップショットバックアップの暗号化](/br/br-snapshot-manual.md#encrypt-the-backup-data)に類似) を渡すことで、ログ バックアップ データを暗号化できます。 -- `--log.crypter.method` : 暗号化アルゴリズム。`aes128-ctr` 、 `aes192-ctr` 、または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 -- `--log.crypter.key` : 16進文字列形式の暗号化キー。アルゴリズム`aes128-ctr`の場合は128ビット（16バイト）、アルゴリズム`aes192-ctr`の場合は24バイト、アルゴリズム`aes256-ctr`の場合は32バイトのキーです。 -- `--log.crypter.key-file` : キーファイル。`crypter.key`を渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。 +- `--log.crypter.method` : 暗号化アルゴリズム。`aes128-ctr` 、 `aes192-ctr` 、または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 +- `--log.crypter.key` : 16進文字列形式の暗号化キー。アルゴリズム`aes128-ctr`の場合は128ビット（16バイト）、アルゴリズム`aes192-ctr`の場合は24バイト、アルゴリズム`aes256-ctr`の場合は32バイトのキーです。 +- `--log.crypter.key-file` : キーファイル。`crypter.key`を渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。 次に例を示します。 @@ -111,8 +111,8 @@ tiup br log start \ ただし、セキュリティ要件が高いシナリオでは、固定の暗号化キーをコマンドラインで直接渡すことは望ましくない場合があります。セキュリティをさらに強化するには、マスターキーベースの暗号化システムを使用して暗号化キーを管理できます。このシステムは、ログバックアップファイルごとに異なるデータキーを生成し、マスターキーのローテーションをサポートします。以下のパラメータを使用して設定できます。 -- `--master-key-crypter-method` : マスターキーに基づく暗号化アルゴリズム。`aes128-ctr` 、 `aes192-ctr`または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 -- `--master-key` ：マスターキーの設定。ローカルディスクに保存されたマスターキー、またはクラウドキー管理サービス（KMS）によって管理されたマスターキーを使用できます。 +- `--master-key-crypter-method` : マスターキーに基づく暗号化アルゴリズム。`aes128-ctr` 、 `aes192-ctr`または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 +- `--master-key` ：マスターキーの設定。ローカルディスクに保存されたマスターキー、またはクラウドキー管理サービス（KMS）によって管理されたマスターキーを使用できます。 ローカル ディスクに保存されているマスター キーを使用して暗号化します。 @@ -149,8 +149,8 @@ tiup br log start \ > **Note:** > -> - キーが失われると、ログ バックアップ データをクラスターに復元できなくなります。 -> - 暗号化機能は、 `br`および TiDB クラスター v8.4.0 以降で使用する必要があります。暗号化されたログバックアップデータは、v8.4.0 より前のクラスターでは復元できません。 +> - キーが失われると、ログ バックアップ データをクラスターに復元できなくなります。 +> - 暗号化機能は、 `br`および TiDB クラスター v8.4.0 以降で使用する必要があります。暗号化されたログバックアップデータは、v8.4.0 より前のクラスターでは復元できません。 ### ログバックアップのステータスを照会する {#query-the-log-backup-status} @@ -202,12 +202,12 @@ checkpoint[global]: 2022-07-25 22:52:15.518 +0800; gap=2m52s 出力フィールドの説明は次のとおりです。 -- `status` : バックアップ タスクのステータス。 `NORMAL` 、 `ERROR` 、または`PAUSE`になります。 -- `start` : バックアップタスクの開始時刻。バックアップタスクの開始時に指定された`start-ts`です。 -- `storage` : バックアップストレージアドレス。 -- `speed` : バックアップタスクの合計 QPS。QPS は 1 秒あたりにバックアップされるログの数を意味します。 -- `checkpoint [global]` : このチェックポイントより前のすべてのデータがバックアップストレージにバックアップされています。これは、バックアップデータの復元に使用できる最新のタイムスタンプです。 -- `error [store]` : ログ バックアップ プログラムがストレージノード上で検出したエラー。 +- `status` : バックアップ タスクのステータス。 `NORMAL` 、 `ERROR` 、または`PAUSE`になります。 +- `start` : バックアップタスクの開始時刻。バックアップタスクの開始時に指定された`start-ts`です。 +- `storage` : バックアップストレージアドレス。 +- `speed` : バックアップタスクの合計 QPS。QPS は 1 秒あたりにバックアップされるログの数を意味します。 +- `checkpoint [global]` : このチェックポイントより前のすべてのデータがバックアップストレージにバックアップされています。これは、バックアップデータの復元に使用できる最新のタイムスタンプです。 +- `error [store]` : ログ バックアップ プログラムがストレージノード上で検出したエラー。 ### ログバックアップタスクを一時停止して再開する {#pause-and-resume-a-log-backup-task} @@ -236,8 +236,8 @@ Global Flags: > **Note:** > -> - ログバックアップタスクが一時停止された後、変更ログを生成するMVCCデータが削除されるのを防ぐため、バックアッププログラムは現在のバックアップチェックポイントをサービスセーフポイントとして自動的に設定します。このサービスセーフポイントには、過去24時間以内のMVCCデータが保持されます。バックアップタスクが24時間以上一時停止された場合、対応するデータはガベージコレクションされ、バックアップされません。 -> - MVCCデータを過剰に保持すると、TiDBクラスターのストレージ容量とパフォーマンスに悪影響を及ぼします。そのため、バックアップタスクを適切なタイミングで再開することをお勧めします。 +> - ログバックアップタスクが一時停止された後、変更ログを生成するMVCCデータが削除されるのを防ぐため、バックアッププログラムは現在のバックアップチェックポイントをサービスセーフポイントとして自動的に設定します。このサービスセーフポイントには、過去24時間以内のMVCCデータが保持されます。バックアップタスクが24時間以上一時停止された場合、対応するデータはガベージコレクションされ、バックアップされません。 +> - MVCCデータを過剰に保持すると、TiDBクラスターのストレージ容量とパフォーマンスに悪影響を及ぼします。そのため、バックアップタスクを適切なタイミングで再開することをお勧めします。 使用例: @@ -317,9 +317,9 @@ tiup br log stop --task-name=pitr --pd="${PD_IP}:2379" `tiup br log stop`コマンドを実行してログバックアップタスクを停止した後、別の`--storage`ディレクトリに新しいログバックアップタスクを作成するか、 `tiup br log start`コマンドを実行して元の`--storage`ディレクトリでログバックアップタスクを再開できます。元の`--storage`ディレクトリでタスクを再開する場合は、以下の点に注意してください。 -- タスクを再開するための`--storage`ディレクトリのパラメータは、停止されたタスクと同じである必要があります。 -- `--start-ts`を指定する必要はありません。BRは最後のバックアップ チェックポイントから自動的にバックアップを開始します。 -- タスクが長時間停止し、複数のバージョンのデータがガベージコレクションされている場合、タスクを再開しようとするとエラー`BR:Backup:ErrBackupGCSafepointExceeded`が報告されます。この場合、別のディレクトリ`--storage`に新しいログバックアップタスクを作成する必要があります。 +- タスクを再開するための`--storage`ディレクトリのパラメータは、停止されたタスクと同じである必要があります。 +- `--start-ts`を指定する必要はありません。BRは最後のバックアップ チェックポイントから自動的にバックアップを開始します。 +- タスクが長時間停止し、複数のバージョンのデータがガベージコレクションされている場合、タスクを再開しようとするとエラー`BR:Backup:ErrBackupGCSafepointExceeded`が報告されます。この場合、別のディレクトリ`--storage`に新しいログバックアップタスクを作成する必要があります。 ### ログバックアップデータをクリーンアップする {#clean-up-log-backup-data} @@ -347,9 +347,9 @@ Global Flags: このコマンドはバックアップストレージにのみアクセスし、TiDBクラスターにはアクセスしません。パラメータの説明は以下のとおりです。 -- `--dry-run` : コマンドを実行しますが、実際にはファイルを削除しません。 -- `--until` : 指定されたタイムスタンプより前のすべてのログ バックアップ データを削除します。 -- `--storage` : バックアップストレージのアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 +- `--dry-run` : コマンドを実行しますが、実際にはファイルを削除しません。 +- `--until` : 指定されたタイムスタンプより前のすべてのログ バックアップ データを削除します。 +- `--storage` : バックアップストレージのアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 使用例: @@ -441,15 +441,15 @@ Global Flags: 出力例には共通パラメータのみが表示されています。これらのパラメータは以下のように記述されます。 -- `--full-backup-storage` : スナップショット（フル）バックアップのストレージアドレス。PITRを使用する場合は、このパラメータを指定して、復元タイムスタンプ前の最新のスナップショットバックアップを選択します。ログバックアップデータのみを復元する場合は、このパラメータを省略できます。リカバリクラスターを初めて初期化する場合は、スナップショットバックアップを指定する必要があります。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、Azure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 -- `--pitr-batch-count` : ログデータを復元する際の、1バッチあたりのファイル数の上限。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。 -- `--pitr-batch-size` : ログデータを復元する際の単一バッチの最大データサイズ（バイト単位）。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。 -- `--pitr-concurrency` : ログ復元中の同時タスク数。各同時タスクは、一度に1バッチのログデータを復元します。 -- `--restored-ts` : データを復元するタイムスタンプ。このパラメータが指定されていない場合、 BRはログバックアップで利用可能な最新のタイムスタンプ、つまりバックアップデータのチェックポイントにデータを復元します。 -- `--start-ts` : ログバックアップデータを復元する開始タイムスタンプ。ログバックアップデータのみを復元する必要がある場合は、このパラメータを指定する必要があります。 -- `--pd` : 復元クラスターの PD アドレス。 -- `--ca` 、 `--cert` 、 `--key` : TiKVおよびPDと通信するためのmTLS暗号化方式を指定します。 -- `--storage` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 +- `--full-backup-storage` : スナップショット（フル）バックアップのストレージアドレス。PITRを使用する場合は、このパラメータを指定して、復元タイムスタンプ前の最新のスナップショットバックアップを選択します。ログバックアップデータのみを復元する場合は、このパラメータを省略できます。リカバリクラスターを初めて初期化する場合は、スナップショットバックアップを指定する必要があります。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、Azure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 +- `--pitr-batch-count` : ログデータを復元する際の、1バッチあたりのファイル数の上限。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。 +- `--pitr-batch-size` : ログデータを復元する際の単一バッチの最大データサイズ（バイト単位）。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。 +- `--pitr-concurrency` : ログ復元中の同時タスク数。各同時タスクは、一度に1バッチのログデータを復元します。 +- `--restored-ts` : データを復元するタイムスタンプ。このパラメータが指定されていない場合、 BRはログバックアップで利用可能な最新のタイムスタンプ、つまりバックアップデータのチェックポイントにデータを復元します。 +- `--start-ts` : ログバックアップデータを復元する開始タイムスタンプ。ログバックアップデータのみを復元する必要がある場合は、このパラメータを指定する必要があります。 +- `--pd` : 復元クラスターの PD アドレス。 +- `--ca` 、 `--cert` 、 `--key` : TiKVおよびPDと通信するためのmTLS暗号化方式を指定します。 +- `--storage` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 使用例: @@ -469,9 +469,9 @@ Restore KV Files <-------------------------------------------------------------- > **Note:** > -> - クラスターを初めて復元する際は、完全なスナップショットデータを指定する必要があります。そうしないと、テーブルIDルールの書き換えにより、新しく作成されたテーブルの一部のデータが正しくなくなる可能性があります。詳細については、GitHub の問題[＃54418](https://github.com/pingcap/tidb/issues/54418)をご覧ください。 -> - 特定の期間のログバックアップデータを繰り返しリストアすることはできません。範囲`[t1=10, t2=20)`のログバックアップデータを繰り返しリストアすると、リストアされたデータに不整合が生じる可能性があります。 -> - 異なる期間のログデータを複数のバッチで復元する場合は、ログデータが連続した順序で復元されるようにしてください。ログバックアップデータ`[t1, t2)` 、 `[t2, t3)` 、 `[t3, t4)`を連続した順序で復元すると、復元されたデータは整合性を保ちます。ただし、 `[t1, t2)`復元した後、 `[t2, t3)`スキップして`[t3, t4)`を復元すると、復元されたデータは不整合になる可能性があります。 +> - クラスターを初めて復元する際は、完全なスナップショットデータを指定する必要があります。そうしないと、テーブルIDルールの書き換えにより、新しく作成されたテーブルの一部のデータが正しくなくなる可能性があります。詳細については、GitHub の問題[＃54418](https://github.com/pingcap/tidb/issues/54418)をご覧ください。 +> - 特定の期間のログバックアップデータを繰り返しリストアすることはできません。範囲`[t1=10, t2=20)`のログバックアップデータを繰り返しリストアすると、リストアされたデータに不整合が生じる可能性があります。 +> - 異なる期間のログデータを複数のバッチで復元する場合は、ログデータが連続した順序で復元されるようにしてください。ログバックアップデータ`[t1, t2)` 、 `[t2, t3)` 、 `[t3, t4)`を連続した順序で復元すると、復元されたデータは整合性を保ちます。ただし、 `[t1, t2)`復元した後、 `[t2, t3)`スキップして`[t3, t4)`を復元すると、復元されたデータは不整合になる可能性があります。 ### 暗号化されたログバックアップデータを復元する {#restore-encrypted-log-backup-data} @@ -507,11 +507,11 @@ TiDB v8.5.5 以降では、PITR 中にフィルターを使用して特定のデ フィルタ パターンは他のBR操作と同じ[テーブルフィルタリング構文](/table-filter.md)に従います。 -- `'*.*'` : すべてのデータベースとテーブルに一致します。 -- `'db1.*'` : データベース`db1`内のすべてのテーブルに一致します。 -- `'db1.table1'` : データベース`db1`内の特定のテーブル`table1`と一致します。 -- `'db*.tbl*'` : `db`で始まるデータベースと`tbl`で始まるテーブルに一致します。 -- `'!mysql.*'` : `mysql`データベース内のすべてのテーブルを除外します。 +- `'*.*'` : すべてのデータベースとテーブルに一致します。 +- `'db1.*'` : データベース`db1`内のすべてのテーブルに一致します。 +- `'db1.table1'` : データベース`db1`内の特定のテーブル`table1`と一致します。 +- `'db*.tbl*'` : `db`で始まるデータベースと`tbl`で始まるテーブルに一致します。 +- `'!mysql.*'` : `mysql`データベース内のすべてのテーブルを除外します。 使用例: @@ -543,15 +543,15 @@ tiup br restore point --pd="${PD_IP}:2379" \ > **Note:** > -> - フィルターを使用してデータを復元する前に、ターゲットクラスターにフィルターに一致するデータベースまたはテーブルが含まれていないことを確認してください。含まれていない場合、復元はエラーで失敗します。 -> - フィルター オプションは、スナップショット バックアップとログ バックアップの両方の復元フェーズ中に適用されます。 -> - 複数の`--filter`オプションを指定して、異なるパターンを含めたり除外したりできます。 -> - PITRフィルタリングはシステムテーブルをまだサポートしていません。特定のシステムテーブルを復元する必要がある場合は、代わりにフィルターを指定した`br restore full`コマンドを使用してください。このコマンドはスナップショットバックアップデータのみを復元し、ログバックアップデータは復元しないことに注意してください。 -> - 復元タスク内の正規表現は、 `restored-ts`時点でのテーブル名と一致し、次の 3 つのケースが考えられます。 -> - テーブルA（テーブルID = 1）：テーブル名は、 `restored-ts`時点以前において、常に`--filter`正規表現と一致します。この場合、PITRはテーブルを復元します。 -> - テーブルB（テーブルID = 2）：テーブル名は`restored-ts`より前の時点では`--filter`正規表現と一致しませんでしたが、 `restored-ts`時点では一致しました。この場合、PITRはテーブルを復元します。 -> - テーブルC（テーブルID = 3）：テーブル名は、 `restored-ts`より前の時点では正規表現`--filter`と一致していましたが、 `restored-ts`時点では一致**していません**。この場合、PITRはテーブルを復元しませ**ん**。 -> - データベースとテーブルのフィルタリング機能を使用して、データの一部をオンラインで復元できます。オンライン復元プロセス中は、復元されたオブジェクトと同じ名前のデータベースまたはテーブルを作成し**ないで**ください。そうしないと、競合が発生して復元タスクが失敗します。データの不整合を回避するため、この復元プロセス中にPITRによって作成されたテーブルは、復元タスクが完了するまで読み取りも書き込みもできません。 +> - フィルターを使用してデータを復元する前に、ターゲットクラスターにフィルターに一致するデータベースまたはテーブルが含まれていないことを確認してください。含まれていない場合、復元はエラーで失敗します。 +> - フィルター オプションは、スナップショット バックアップとログ バックアップの両方の復元フェーズ中に適用されます。 +> - 複数の`--filter`オプションを指定して、異なるパターンを含めたり除外したりできます。 +> - PITRフィルタリングはシステムテーブルをまだサポートしていません。特定のシステムテーブルを復元する必要がある場合は、代わりにフィルターを指定した`br restore full`コマンドを使用してください。このコマンドはスナップショットバックアップデータのみを復元し、ログバックアップデータは復元しないことに注意してください。 +> - 復元タスク内の正規表現は、 `restored-ts`時点でのテーブル名と一致し、次の 3 つのケースが考えられます。 +> - テーブルA（テーブルID = 1）：テーブル名は、 `restored-ts`時点以前において、常に`--filter`正規表現と一致します。この場合、PITRはテーブルを復元します。 +> - テーブルB（テーブルID = 2）：テーブル名は`restored-ts`より前の時点では`--filter`正規表現と一致しませんでしたが、 `restored-ts`時点では一致しました。この場合、PITRはテーブルを復元します。 +> - テーブルC（テーブルID = 3）：テーブル名は、 `restored-ts`より前の時点では正規表現`--filter`と一致していましたが、 `restored-ts`時点では一致**していません**。この場合、PITRはテーブルを復元しませ**ん**。 +> - データベースとテーブルのフィルタリング機能を使用して、データの一部をオンラインで復元できます。オンライン復元プロセス中は、復元されたオブジェクトと同じ名前のデータベースまたはテーブルを作成し**ないで**ください。そうしないと、競合が発生して復元タスクが失敗します。データの不整合を回避するため、この復元プロセス中にPITRによって作成されたテーブルは、復元タスクが完了するまで読み取りも書き込みもできません。 ### 同時復元操作 {#concurrent-restore-operations} @@ -579,26 +579,26 @@ tiup br restore point --pd="${PD_IP}:2379" \ > **Note:** > -> - 各同時復元操作は、異なるデータベースまたは重複しないテーブルセットを対象とする必要があります。重複するデータセットを同時に復元しようとすると、エラーが発生します。 -> - 複数の復元タスクはシステムリソースを大量に消費します。CPUとI/Oリソースが十分な場合にのみ、複数の復元タスクを同時に実行することをお勧めします。 +> - 各同時復元操作は、異なるデータベースまたは重複しないテーブルセットを対象とする必要があります。重複するデータセットを同時に復元しようとすると、エラーが発生します。 +> - 複数の復元タスクはシステムリソースを大量に消費します。CPUとI/Oリソースが十分な場合にのみ、複数の復元タスクを同時に実行することをお勧めします。 ### 進行中のログバックアップとスナップショット復元の互換性 {#compatibility-between-ongoing-log-backup-and-snapshot-restore} v8.5.5 以降では、ログ バックアップ タスクの実行中に、次の条件がすべて満たされている場合は、スナップショット リストア ( `br restore [full|database|table]` ) を実行し、進行中のログ バックアップ (以下、「ログ バックアップ」) によってリストアされたデータを適切に記録することができます。 -- バックアップおよび復元操作を実行するノードには、次の必要な権限があります。 - - スナップショットの復元のための、バックアップソースを含む外部ストレージへの読み取りアクセス - - ログバックアップで使用されるターゲット外部ストレージへの書き込みアクセス -- ログバックアップの対象となる外部ストレージは、Amazon S3（ `s3://` ）、Google Cloud Storage（ `gcs://` ）、またはAzure Blob Storage（ `azblob://` ）です。 -- 復元するデータは、ログ バックアップのターゲットストレージと同じ種類の外部ストレージを使用します。 -- 復元対象のデータとログバックアップのどちらにもローカル暗号化が有効になっていません。詳細については、 [ログバックアップの暗号化](#encrypt-the-log-backup-data)と[スナップショットバックアップの暗号化](/br/br-snapshot-manual.md#encrypt-the-backup-data)を参照してください。 +- バックアップおよび復元操作を実行するノードには、次の必要な権限があります。 + - スナップショットの復元のための、バックアップソースを含む外部ストレージへの読み取りアクセス + - ログバックアップで使用されるターゲット外部ストレージへの書き込みアクセス +- ログバックアップの対象となる外部ストレージは、Amazon S3（ `s3://` ）、Google Cloud Storage（ `gcs://` ）、またはAzure Blob Storage（ `azblob://` ）です。 +- 復元するデータは、ログ バックアップのターゲットストレージと同じ種類の外部ストレージを使用します。 +- 復元対象のデータとログバックアップのどちらにもローカル暗号化が有効になっていません。詳細については、 [ログバックアップの暗号化](#encrypt-the-log-backup-data)と[スナップショットバックアップの暗号化](/br/br-snapshot-manual.md#encrypt-the-backup-data)を参照してください。 上記の条件のいずれかが満たされていない場合は、次の手順に従ってデータを復元できます。 -1. [ログバックアップタスクを停止する](#stop-a-log-backup-task) 。 -2. データの復元を実行します。 -3. 復元が完了したら、新しいスナップショット バックアップを実行します。 -4. [ログバックアップタスクを再開する](#restart-a-log-backup-task) 。 +1. [ログバックアップタスクを停止する](#stop-a-log-backup-task) 。 +2. データの復元を実行します。 +3. 復元が完了したら、新しいスナップショット バックアップを実行します。 +4. [ログバックアップタスクを再開する](#restart-a-log-backup-task) 。 > **Note:** > @@ -614,8 +614,8 @@ TiDB v8.5.5以降では、ログバックアップタスクの実行中にPITR 期間`[t1, t2)`にこのような不整合が発生した場合、この期間のデータを直接復元することはできません。代わりに、以下のいずれかの方法を選択してください。 -- データを`t1`まで復元します（不整合期間前のデータを取得します）。 -- `t2`の後に新しいスナップショット バックアップを実行し、それを将来の PITR 操作のベースとして使用します。 +- データを`t1`まで復元します（不整合期間前のデータを取得します）。 +- `t2`の後に新しいスナップショット バックアップを実行し、それを将来の PITR 操作のベースとして使用します。 ### 復元操作を中止する {#abort-restore-operations} diff --git a/br/br-snapshot-architecture.md b/br/br-snapshot-architecture.md index 431c37f21d016..2bff38fae4004 100644 --- a/br/br-snapshot-architecture.md +++ b/br/br-snapshot-architecture.md @@ -42,34 +42,34 @@ sequenceDiagram バックアップの全手順は以下のとおりです。 -1. BR は`br backup full`コマンドを受け取ります。 +1. BR は`br backup full`コマンドを受け取ります。 - - バックアップの日時とストレージパスを取得します。 + - バックアップの日時とストレージパスを取得します。 -2. BRはバックアップデータのスケジュールを設定します。 +2. BRはバックアップデータのスケジュールを設定します。 - - **GCの一時停止**： BRは、TiDB [TiDB GCメカニズム](/garbage-collection-overview.md)によってバックアップデータがクリーンアップされないように、TiDB GCの時間を設定します。 - - **TiKV とリージョン情報の取得**: BR はPD にアクセスして、すべての TiKV ノードのアドレスとデータの[リージョン](/tidb-storage.md#region)分布を取得します。 - - **TiKVにデータバックアップを依頼する**： BRはバックアップ依頼を作成し、すべてのTiKVノードに送信します。バックアップ依頼には、バックアップのタイミング、バックアップ対象のリージョン、およびストレージパスが含まれます。 + - **GCの一時停止**： BRは、TiDB [TiDB GCメカニズム](/garbage-collection-overview.md)によってバックアップデータがクリーンアップされないように、TiDB GCの時間を設定します。 + - **TiKV とリージョン情報の取得**: BR はPD にアクセスして、すべての TiKV ノードのアドレスとデータの[リージョン](/tidb-storage.md#region)分布を取得します。 + - **TiKVにデータバックアップを依頼する**： BRはバックアップ依頼を作成し、すべてのTiKVノードに送信します。バックアップ依頼には、バックアップのタイミング、バックアップ対象のリージョン、およびストレージパスが含まれます。 -3. TiKVはバックアップ要求を受け入れ、バックアップワーカーを起動します。 +3. TiKVはバックアップ要求を受け入れ、バックアップワーカーを起動します。 -4. TiKVはデータをバックアップします。 +4. TiKVはデータをバックアップします。 - - **KVのスキャン**：バックアップワーカーは、リーダーが存在するリージョンから、バックアップ時点に対応するデータを読み取ります。 - - **SST の生成**: バックアップ ワーカーはデータを SST ファイルに保存し、メモリに保存します。 - - **SSTファイルのアップロード**：バックアップワーカーがSSTファイルをストレージパスにアップロードします。 + - **KVのスキャン**：バックアップワーカーは、リーダーが存在するリージョンから、バックアップ時点に対応するデータを読み取ります。 + - **SST の生成**: バックアップ ワーカーはデータを SST ファイルに保存し、メモリに保存します。 + - **SSTファイルのアップロード**：バックアップワーカーがSSTファイルをストレージパスにアップロードします。 -5. BRは各TiKVノードからバックアップ結果を受け取ります。 +5. BRは各TiKVノードからバックアップ結果を受け取ります。 - - リージョン変更（例えば、TiKVノードがダウンした場合）により一部のデータのバックアップが失敗した場合、 BRはバックアップを再試行します。 - - バックアップに失敗したデータがあり、再試行もできない場合、バックアップタスクは失敗します。 - - すべてのデータのバックアップが完了した後、 BRはメタデータのバックアップを行います。 + - リージョン変更（例えば、TiKVノードがダウンした場合）により一部のデータのバックアップが失敗した場合、 BRはバックアップを再試行します。 + - バックアップに失敗したデータがあり、再試行もできない場合、バックアップタスクは失敗します。 + - すべてのデータのバックアップが完了した後、 BRはメタデータのバックアップを行います。 -6. BRはメタデータをバックアップします。 +6. BRはメタデータをバックアップします。 - - **スキーマのバックアップ**： BRはテーブルスキーマをバックアップし、テーブルデータのチェックサムを計算します。 - - **メタデータのアップロード**： BRはバックアップメタデータを生成し、ストレージパスにアップロードします。バックアップメタデータには、バックアップタイムスタンプ、テーブルと対応するバックアップファイル、データチェックサム、およびファイルチェックサムが含まれます。 + - **スキーマのバックアップ**： BRはテーブルスキーマをバックアップし、テーブルデータのチェックサムを計算します。 + - **メタデータのアップロード**： BRはバックアップメタデータを生成し、ストレージパスにアップロードします。バックアップメタデータには、バックアップタイムスタンプ、テーブルと対応するバックアップファイル、データチェックサム、およびファイルチェックサムが含まれます。 ## 復元プロセス {#process-of-restore} @@ -99,34 +99,34 @@ sequenceDiagram 完全な復元手順は以下のとおりです。 -1. BR は`br restore`コマンドを受け取ります。 +1. BR は`br restore`コマンドを受け取ります。 - - 復元するデータストレージパスとデータベースまたはテーブルを取得します。 - - 復元対象のテーブルが存在するか、また復元要件を満たしているかを確認します。 + - 復元するデータストレージパスとデータベースまたはテーブルを取得します。 + - 復元対象のテーブルが存在するか、また復元要件を満たしているかを確認します。 -2. BRは復元データのスケジュールを設定します。 +2. BRは復元データのスケジュールを設定します。 - - **リージョンスケジュールの一時停止**： BRは、復元中に自動リージョンスケジューリングを一時停止するようPDに要求します。 - - **スキーマの復元**： BRはバックアップデータのスキーマ、および復元対象のデータベースとテーブルを取得します。新しく作成されたテーブルのIDは、バックアップデータのIDと異なる場合があることに注意してください。 - - **リージョンの分割と分散**： BRはPDにバックアップデータに基づいてリージョンを分割（Split）するよう要求し、ストレージノードに均等に分散（Scatter）されるようにリージョンをスケジュールします。各リージョンには、指定されたデータ範囲`[start key, end key)`があります。 - - **TiKVにデータ復元を依頼する**： BRは復元依頼を作成し、リージョン分割の結果に応じて対応するTiKVノードに送信します。復元依頼には、復元するデータと書き換えルールが含まれます。 + - **リージョンスケジュールの一時停止**： BRは、復元中に自動リージョンスケジューリングを一時停止するようPDに要求します。 + - **スキーマの復元**： BRはバックアップデータのスキーマ、および復元対象のデータベースとテーブルを取得します。新しく作成されたテーブルのIDは、バックアップデータのIDと異なる場合があることに注意してください。 + - **リージョンの分割と分散**： BRはPDにバックアップデータに基づいてリージョンを分割（Split）するよう要求し、ストレージノードに均等に分散（Scatter）されるようにリージョンをスケジュールします。各リージョンには、指定されたデータ範囲`[start key, end key)`があります。 + - **TiKVにデータ復元を依頼する**： BRは復元依頼を作成し、リージョン分割の結果に応じて対応するTiKVノードに送信します。復元依頼には、復元するデータと書き換えルールが含まれます。 -3. TiKVは復元要求を受け入れ、復元ワーカーを起動します。 +3. TiKVは復元要求を受け入れ、復元ワーカーを起動します。 - - リストアワーカーは、リストアのために読み込む必要のあるバックアップデータを計算します。 + - リストアワーカーは、リストアのために読み込む必要のあるバックアップデータを計算します。 -4. TiKVはデータを復元します。 +4. TiKVはデータを復元します。 - - **SSTファイルのダウンロード**：復元ワーカーは、ストレージパスから対応するSSTファイルをローカルディレクトリにダウンロードします。 - - **KVの書き換え**：復元ワーカーは、新しいテーブルIDに基づいてKVデータを書き換えます。つまり、 [キー値](/tidb-computing.md#mapping-table-data-to-key-value)内の元のテーブルIDを新しいテーブルIDに置き換えます。復元ワーカーは、インデックスIDも同様に書き換えます。 - - **SSTの取り込み**: リストアワーカーは、処理済みの SST ファイルを RocksDB に取り込みます。 - - **復元結果の報告**: 復元ワーカーは復元結果をBRに報告します。 + - **SSTファイルのダウンロード**：復元ワーカーは、ストレージパスから対応するSSTファイルをローカルディレクトリにダウンロードします。 + - **KVの書き換え**：復元ワーカーは、新しいテーブルIDに基づいてKVデータを書き換えます。つまり、 [キー値](/tidb-computing.md#mapping-table-data-to-key-value)内の元のテーブルIDを新しいテーブルIDに置き換えます。復元ワーカーは、インデックスIDも同様に書き換えます。 + - **SSTの取り込み**: リストアワーカーは、処理済みの SST ファイルを RocksDB に取り込みます。 + - **復元結果の報告**: 復元ワーカーは復元結果をBRに報告します。 -5. BRは各TiKVノードから復元結果を受け取ります。 +5. BRは各TiKVノードから復元結果を受け取ります。 - - 例えば ​​TiKV ノードがダウンしている場合など、 `RegionNotFound`または`EpochNotMatch`が原因でデータの復元に失敗した場合、 BR は復元を再試行します。 - - 復元に失敗し、再試行もできない場合、復元タスクは失敗します。 - - すべてのデータが復元されると、復元タスクは成功します。 + - 例えば ​​TiKV ノードがダウンしている場合など、 `RegionNotFound`または`EpochNotMatch`が原因でデータの復元に失敗した場合、 BR は復元を再試行します。 + - 復元に失敗し、再試行もできない場合、復元タスクは失敗します。 + - すべてのデータが復元されると、復元タスクは成功します。 ## バックアップファイル {#backup-files} @@ -134,33 +134,33 @@ sequenceDiagram スナップショットバックアップでは、以下の種類のファイルが生成されます。 -- `SST`ファイル: TiKV ノードがバックアップするデータを格納します。 `SST`ファイルのサイズは、リージョンのサイズと同じです。 -- `backupmeta`ファイル: バックアップ タスクのメタデータを格納します。これには、すべてのバックアップ ファイルの数、キー範囲、サイズ、および各バックアップ ファイルのハッシュ (sha256) 値が含まれます。 -- `backup.lock`ファイル: 複数のバックアップ タスクが同じディレクトリにデータを保存するのを防ぎます。 +- `SST`ファイル: TiKV ノードがバックアップするデータを格納します。 `SST`ファイルのサイズは、リージョンのサイズと同じです。 +- `backupmeta`ファイル: バックアップ タスクのメタデータを格納します。これには、すべてのバックアップ ファイルの数、キー範囲、サイズ、および各バックアップ ファイルのハッシュ (sha256) 値が含まれます。 +- `backup.lock`ファイル: 複数のバックアップ タスクが同じディレクトリにデータを保存するのを防ぎます。 ### SSTファイルの命名形式 {#naming-format-of-sst-files} データが Google Cloud Storage (GCS) または Azure Blob Storage にバックアップされる場合、SST ファイルは`storeID_regionID_regionEpoch_keyHash_timestamp_cf`の形式で命名されます。名前に含まれるフィールドについては、以下のように説明します。 -- `storeID`は TiKV ノード ID です。 -- `regionID`はリージョンID です。 -- `regionEpoch`はリージョンのバージョン番号です。 -- `keyHash`は、範囲の開始キーのハッシュ (sha256) 値であり、ファイルの一意性を保証します。 -- `timestamp`は、TiKV によって生成された SST ファイルの Unix タイムスタンプです。 -- `cf` RocksDB のカラムファミリーを示します ( `cf`が`default`または`write`であるデータのみを復元します)。 +- `storeID`は TiKV ノード ID です。 +- `regionID`はリージョンID です。 +- `regionEpoch`はリージョンのバージョン番号です。 +- `keyHash`は、範囲の開始キーのハッシュ (sha256) 値であり、ファイルの一意性を保証します。 +- `timestamp`は、TiKV によって生成された SST ファイルの Unix タイムスタンプです。 +- `cf` RocksDB のカラムファミリーを示します ( `cf`が`default`または`write`であるデータのみを復元します)。 データがAmazon S3またはネットワークディスクにバックアップされる場合、SSTファイルは`regionID_regionEpoch_keyHash_timestamp_cf`という形式で命名されます。名前に含まれるフィールドについては、以下のように説明します。 -- `regionID`はリージョンID です。 -- `regionEpoch`はリージョンのバージョン番号です。 -- `keyHash`は、範囲の開始キーのハッシュ (sha256) 値であり、ファイルの一意性を保証します。 -- `timestamp`は、TiKV によって生成された SST ファイルの Unix タイムスタンプです。 -- `cf` RocksDB のカラムファミリーを示します ( `cf`が`default`または`write`であるデータのみを復元します)。 +- `regionID`はリージョンID です。 +- `regionEpoch`はリージョンのバージョン番号です。 +- `keyHash`は、範囲の開始キーのハッシュ (sha256) 値であり、ファイルの一意性を保証します。 +- `timestamp`は、TiKV によって生成された SST ファイルの Unix タイムスタンプです。 +- `cf` RocksDB のカラムファミリーを示します ( `cf`が`default`または`write`であるデータのみを復元します)。 ### 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 ファイルのストレージ形式の詳細については、 [RocksDBブロックベーステーブル形式](https://github.com/facebook/rocksdb/wiki/Rocksdb-BlockBasedTable-Format)を参照してください。 +- SST ファイルのバックアップ データのエンコード形式の詳細については、[テーブルデータのキー値へのマッピング](/tidb-computing.md#mapping-table-data-to-key-value)を参照してください。 ### バックアップファイルの構造 {#structure-of-backup-files} @@ -196,4 +196,4 @@ sequenceDiagram ## 関連項目 {#see-also} -- [TiDBスナップショットのバックアップと復元ガイド](/br/br-snapshot-guide.md) +- [TiDBスナップショットのバックアップと復元ガイド](/br/br-snapshot-guide.md) diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md index 77dc2dd9010e8..a33ea91808b35 100644 --- a/br/br-snapshot-guide.md +++ b/br/br-snapshot-guide.md @@ -11,15 +11,15 @@ summary: このドキュメントでは、brコマンドラインツールを使 基本的なバックアップと復元に加えて、スナップショットバックアップと復元には以下の機能も備わっています。 -- [指定した時点のバックアップデータ](#back-up-cluster-snapshots) -- [指定されたデータベースまたはテーブルのデータを復元する](#restore-a-database-or-a-table) +- [指定した時点のバックアップデータ](#back-up-cluster-snapshots) +- [指定されたデータベースまたはテーブルのデータを復元する](#restore-a-database-or-a-table) ## クラスタスナップショットのバックアップ {#back-up-cluster-snapshots} > **Note:** > -> - 以下の例では、Amazon S3 アクセス キーとシークレット キーを使用して権限を認証することを前提としていますIAMロールを使用して権限を認証する場合は、 `--send-credentials-to-tikv` `false`に設定する必要があります。 -> - 他のストレージシステムまたは認証方法を使用して権限を認証する場合は、[バックアップストレージ](/br/backup-and-restore-storages.md)に従ってパラメータ設定を調整します。 +> - 以下の例では、Amazon S3 アクセス キーとシークレット キーを使用して権限を認証することを前提としていますIAMロールを使用して権限を認証する場合は、 `--send-credentials-to-tikv` `false`に設定する必要があります。 +> - 他のストレージシステムまたは認証方法を使用して権限を認証する場合は、[バックアップストレージ](/br/backup-and-restore-storages.md)に従ってパラメータ設定を調整します。 `tiup br backup full`コマンドを実行すると、TiDB クラスタのスナップショットをバックアップできます。ヘルプ情報を表示するには、 `tiup br backup full --help`を実行してください。 @@ -31,17 +31,17 @@ tiup br backup full --pd "${PD_IP}:2379" \ 前述のコマンドでは： -- `--backupts` : スナップショットのタイムポイント。形式は[TSO](/tso.md)またはタイムスタンプで、 `400036290571534337`や`2018-05-11 01:42:23 +08:00`などです。このスナップショットのデータがガベージコレクションされると、 `tiup br backup`コマンドはエラーを返し、 `br`は終了します。タイムスタンプを使用してバックアップする場合は、タイムゾーンも指定することをお勧めします。そうしないと、 `br`はデフォルトでローカルタイムゾーンを使用してタイムスタンプを構築するため、バックアップのタイムポイントが正しくない可能性があります。このパラメーターを指定しない場合、 `br`バックアップ開始時刻に対応するスナップショットを選択します。 -- `--storage` : バックアップ データのストレージアドレス。スナップショット バックアップは、Amazon S3、Google Cloud Storage、および Azure Blob Storage をバックアップストレージとしてサポートします。前述のコマンドでは、例として Amazon S3 を使用しています。詳細については、[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 +- `--backupts` : スナップショットのタイムポイント。形式は[TSO](/tso.md)またはタイムスタンプで、 `400036290571534337`や`2018-05-11 01:42:23 +08:00`などです。このスナップショットのデータがガベージコレクションされると、 `tiup br backup`コマンドはエラーを返し、 `br`は終了します。タイムスタンプを使用してバックアップする場合は、タイムゾーンも指定することをお勧めします。そうしないと、 `br`はデフォルトでローカルタイムゾーンを使用してタイムスタンプを構築するため、バックアップのタイムポイントが正しくない可能性があります。このパラメーターを指定しない場合、 `br`バックアップ開始時刻に対応するスナップショットを選択します。 +- `--storage` : バックアップ データのストレージアドレス。スナップショット バックアップは、Amazon S3、Google Cloud Storage、および Azure Blob Storage をバックアップストレージとしてサポートします。前述のコマンドでは、例として Amazon S3 を使用しています。詳細については、[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 バックアップ中は、下図のように端末に進行状況バーが表示されます。進行状況バーが100%に達すると、バックアップタスクが完了し、合計バックアップ時間、平均バックアップ速度、バックアップデータサイズなどの統計情報が表示されます。 -- `total-ranges` : バックアップするファイルの総数を示します。 -- `ranges-succeed` : 正常にバックアップされたファイルの数を示します。 -- `ranges-failed` : バックアップに失敗したファイルの数を示します。 -- `backup-total-ranges` : バックアップするテーブル（パーティションを含む）とインデックスの数を示します。 -- `write-CF-files` : `write CF`データを含むバックアップ SST ファイルの数を示します。 -- `default-CF-files` : `default CF`データを含むバックアップ SST ファイルの数を示します。 +- `total-ranges` : バックアップするファイルの総数を示します。 +- `ranges-succeed` : 正常にバックアップされたファイルの数を示します。 +- `ranges-failed` : バックアップに失敗したファイルの数を示します。 +- `backup-total-ranges` : バックアップするテーブル（パーティションを含む）とインデックスの数を示します。 +- `write-CF-files` : `write CF`データを含むバックアップ SST ファイルの数を示します。 +- `default-CF-files` : `default CF`データを含むバックアップ SST ファイルの数を示します。 ```shell Full Backup <-------------------------------------------------------------------------------> 100.00% @@ -68,11 +68,11 @@ tiup br validate decode --field="end-version" \ > **Note:** > -> - BR v7.5.0以前のバージョンでは、TiKVノードあたりのスナップショット復元速度は約100 MiB/秒です。 -> - BR v7.6.0以降、大規模なリージョンを含むシナリオにおける潜在的なリストアのボトルネックに対処するため、 BRは粗粒度リージョン散乱アルゴリズム（実験的）によるリストアの高速化をサポートしています。この機能は、コマンドラインパラメータ`--granularity="coarse-grained"`を指定することで有効にできます。 -> - BR v8.0.0以降、粗粒度リージョン分散アルゴリズムによるスナップショット復元が一般提供（GA）となり、デフォルトで有効になっています。BRは、粗粒度リージョン分散アルゴリズムの採用、データベースとテーブルのバッチ作成、SSTファイルダウンロードと取り込み操作間の相互影響の低減、テーブル統計情報の復元の高速化など、さまざまな最適化を実装することで、スナップショット復元の速度を大幅に向上させています。実際のケースのテスト結果によると、スナップショット復元用のSSTファイルダウンロード速度は最大で約10倍向上し、TiKVノードあたりのデータ復元速度は1.2 GiB/sで安定し、エンドツーエンドの復元速度は約1.5～3倍向上し、100 TiBのデータを1時間以内に復元できます。 -> - BR v8.2.0以降、コマンドラインパラメータ`--granularity`は非推奨となり、粗粒度リージョン散乱アルゴリズムがデフォルトで有効になっています。 -> - BR v8.3.0 以降では、スナップショット復元タスクで TiKV とTiFlashのディスク空き容量チェックが導入されました。タスクの開始時に、 BR は復元対象の SST ファイルのサイズに基づいて TiKV とTiFlash に十分なディスク空き容量があるかどうかを確認します。TiKV v8.3.0 以降のバージョンでは、TiKV は各 SST ファイルをダウンロードする前に十分なディスク空き容量があるかどうかを確認します。これらのチェックのいずれかで空き容量が不足している場合、復元タスクはエラーで失敗します。 `--check-requirements=false`を設定することで、復元タスクの開始時のチェックをスキップできますが、TiKV が各 SST ファイルをダウンロードする前のディスク空き容量チェックはスキップできません。 +> - BR v7.5.0以前のバージョンでは、TiKVノードあたりのスナップショット復元速度は約100 MiB/秒です。 +> - BR v7.6.0以降、大規模なリージョンを含むシナリオにおける潜在的なリストアのボトルネックに対処するため、 BRは粗粒度リージョン散乱アルゴリズム（実験的）によるリストアの高速化をサポートしています。この機能は、コマンドラインパラメータ`--granularity="coarse-grained"`を指定することで有効にできます。 +> - BR v8.0.0以降、粗粒度リージョン分散アルゴリズムによるスナップショット復元が一般提供（GA）となり、デフォルトで有効になっています。BRは、粗粒度リージョン分散アルゴリズムの採用、データベースとテーブルのバッチ作成、SSTファイルダウンロードと取り込み操作間の相互影響の低減、テーブル統計情報の復元の高速化など、さまざまな最適化を実装することで、スナップショット復元の速度を大幅に向上させています。実際のケースのテスト結果によると、スナップショット復元用のSSTファイルダウンロード速度は最大で約10倍向上し、TiKVノードあたりのデータ復元速度は1.2 GiB/sで安定し、エンドツーエンドの復元速度は約1.5～3倍向上し、100 TiBのデータを1時間以内に復元できます。 +> - BR v8.2.0以降、コマンドラインパラメータ`--granularity`は非推奨となり、粗粒度リージョン散乱アルゴリズムがデフォルトで有効になっています。 +> - BR v8.3.0 以降では、スナップショット復元タスクで TiKV とTiFlashのディスク空き容量チェックが導入されました。タスクの開始時に、 BR は復元対象の SST ファイルのサイズに基づいて TiKV とTiFlash に十分なディスク空き容量があるかどうかを確認します。TiKV v8.3.0 以降のバージョンでは、TiKV は各 SST ファイルをダウンロードする前に十分なディスク空き容量があるかどうかを確認します。これらのチェックのいずれかで空き容量が不足している場合、復元タスクはエラーで失敗します。 `--check-requirements=false`を設定することで、復元タスクの開始時のチェックをスキップできますが、TiKV が各 SST ファイルをダウンロードする前のディスク空き容量チェックはスキップできません。 `tiup br restore full`コマンドを実行すると、スナップショットバックアップを復元できます。ヘルプ情報を表示するには、 `tiup br restore full --help`を実行してください。 @@ -85,15 +85,15 @@ tiup br restore full --pd "${PD_IP}:2379" \ 復元処理中は、下図のように端末にプログレスバーが表示されます。プログレスバーが100%に達すると、復元タスクが完了し、合計復元時間、平均復元速度、合計データサイズなどの統計情報が表示されます。 -- `total-ranges` : 復元されるファイルの総数を示します。 -- `ranges-succeed` : 正常に復元されたファイルの数を示します。 -- `ranges-failed` : 復元に失敗したファイルの数を示します。 -- `merge-ranges` : データ範囲をマージするのにかかった時間を示します。 -- `split-region` : 領域を分割して散布するのにかかる時間を示します。 -- `restore-files` : TiKV が SST ファイルをダウンロードして取り込むのにかかる時間を示します。 -- `write-CF-files` : `write CF`データを含む復元された SST ファイルの数を示します。 -- `default-CF-files` : `default CF`データを含む復元された SST ファイルの数を示します。 -- `split-keys` : 領域を分割するために生成されるキーの数を示します。 +- `total-ranges` : 復元されるファイルの総数を示します。 +- `ranges-succeed` : 正常に復元されたファイルの数を示します。 +- `ranges-failed` : 復元に失敗したファイルの数を示します。 +- `merge-ranges` : データ範囲をマージするのにかかった時間を示します。 +- `split-region` : 領域を分割して散布するのにかかる時間を示します。 +- `restore-files` : TiKV が SST ファイルをダウンロードして取り込むのにかかる時間を示します。 +- `write-CF-files` : `write CF`データを含む復元された SST ファイルの数を示します。 +- `default-CF-files` : `default CF`データを含む復元された SST ファイルの数を示します。 +- `split-keys` : 領域を分割するために生成されるキーの数を示します。 ```shell Split&Scatter Region <--------------------------------------------------------------------> 100.00% @@ -147,10 +147,10 @@ tiup br restore full \ ### `mysql`スキーマ内のテーブルを復元する {#restore-tables-in-the-mysql-schema} -- BR v5.1.0以降では、スナップショットをバックアップすると、 BRは`mysql`スキーマ内の**システムテーブルを**自動的にバックアップしますが、デフォルトではこれらのシステムテーブルを復元しません。 -- バージョン6.2.0以降、 BRでは`--with-sys-table`を指定して、**一部のシステムテーブルのデータを**復元できます。 -- バージョン7.6.0以降、 BRは`--with-sys-table`デフォルトで有効にしており、これはBRがデフォルトで**一部のシステムテーブルのデータを**復元することを意味します。 -- バージョン 8.5.5 以降、 BRシステム テーブルの物理的な復元をサポートする`--fast-load-sys-tables`パラメーターが導入されました。このパラメーターはデフォルトで有効になっています。この方式では`RENAME TABLE` DDL ステートメントを使用して、 `__TiDB_BR_Temporary_mysql`データベースのシステム テーブルと`mysql`データベースのシステム テーブルをアトミックに交換します。 `REPLACE INTO` SQL ステートメントを使用したシステム テーブルの論理的な復元とは異なり、物理的な復元ではシステム テーブル内の既存のデータが完全に上書きされます。 +- BR v5.1.0以降では、スナップショットをバックアップすると、 BRは`mysql`スキーマ内の**システムテーブルを**自動的にバックアップしますが、デフォルトではこれらのシステムテーブルを復元しません。 +- バージョン6.2.0以降、 BRでは`--with-sys-table`を指定して、**一部のシステムテーブルのデータを**復元できます。 +- バージョン7.6.0以降、 BRは`--with-sys-table`デフォルトで有効にしており、これはBRがデフォルトで**一部のシステムテーブルのデータを**復元することを意味します。 +- バージョン 8.5.5 以降、 BRシステム テーブルの物理的な復元をサポートする`--fast-load-sys-tables`パラメーターが導入されました。このパラメーターはデフォルトで有効になっています。この方式では`RENAME TABLE` DDL ステートメントを使用して、 `__TiDB_BR_Temporary_mysql`データベースのシステム テーブルと`mysql`データベースのシステム テーブルをアトミックに交換します。 `REPLACE INTO` SQL ステートメントを使用したシステム テーブルの論理的な復元とは異なり、物理的な復元ではシステム テーブル内の既存のデータが完全に上書きされます。 **BRは、以下のシステムテーブルのデータを復元できます。** @@ -170,9 +170,9 @@ tiup br restore full \ **BR は以下のシステムテーブルを復元しません。** -- 統計テーブル ( `mysql.stat_*` )。ただし、統計は復元できます。 [統計情報のバックアップ](/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) +- 統計テーブル ( `mysql.stat_*` )。ただし、統計は復元できます。 [統計情報のバックアップ](/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) @@ -199,9 +199,9 @@ tiup br restore full \ システム権限に関連するデータを復元する場合、データの復元前に、 BR はターゲットクラスタのシステムテーブルがバックアップデータ内のシステムテーブルと互換性があるかどうかをチェックすることに注意してください。「互換性がある」とは、以下のすべての条件が満たされていることを意味します。 -- ターゲットクラスタは、バックアップデータと同じシステムテーブルを持っています。 -- 対象クラスタのシステム権限テーブルの**列数は**、バックアップデータの列数と同じです。列の順序は重要ではありません。 -- 対象クラスタのシステム権限テーブルの列は、バックアップデータの列と互換性があります。列のデータ型が長さを持つ型（整数や文字列など）の場合、対象クラスタの長さはバックアップデータの長さ以上でなければなりません。列のデータ型が`ENUM`型の場合、対象クラスタの`ENUM`値の数のスーパーセットでなければなりません。 +- ターゲットクラスタは、バックアップデータと同じシステムテーブルを持っています。 +- 対象クラスタのシステム権限テーブルの**列数は**、バックアップデータの列数と同じです。列の順序は重要ではありません。 +- 対象クラスタのシステム権限テーブルの列は、バックアップデータの列と互換性があります。列のデータ型が長さを持つ型（整数や文字列など）の場合、対象クラスタの長さはバックアップデータの長さ以上でなければなりません。列のデータ型が`ENUM`型の場合、対象クラスタの`ENUM`値の数のスーパーセットでなければなりません。 ## パフォーマンスと影響 {#performance-and-impact} @@ -211,16 +211,16 @@ tiup br restore full \ バックアップの効果を示すために、この文書ではいくつかのスナップショットバックアップテストの結果を一覧で示します。 -- (5.3.0以前) TiKVノード上のBRのバックアップスレッドがノードの総CPUの75%を占めると、QPSは元のQPSの35%減少します。 -- (5.4.0 以降) TiKV ノード上のBRスレッド数が`8`以下で、クラスタの CPU 使用率が 80% を超えない場合、 BRタスクがクラスタに与える影響 (書き込みと読み取り) は最大で 20% です。 -- (5.4.0 以降) TiKV ノード上のBRスレッド数が`8`以下で、クラスターの CPU 使用率が 75% を超えない場合、クラスターに対するBRタスク (書き込みと読み取り) の影響は最大で 10% です。 -- (5.4.0 以降) TiKV ノード上のBRスレッド数が`8`以下で、クラスターの CPU 使用率が 60% を超えない場合、 BRタスクはクラスター (書き込みと読み取り) にほとんど影響を与えません。 +- (5.3.0以前) TiKVノード上のBRのバックアップスレッドがノードの総CPUの75%を占めると、QPSは元のQPSの35%減少します。 +- (5.4.0 以降) TiKV ノード上のBRスレッド数が`8`以下で、クラスタの CPU 使用率が 80% を超えない場合、 BRタスクがクラスタに与える影響 (書き込みと読み取り) は最大で 20% です。 +- (5.4.0 以降) TiKV ノード上のBRスレッド数が`8`以下で、クラスターの CPU 使用率が 75% を超えない場合、クラスターに対するBRタスク (書き込みと読み取り) の影響は最大で 10% です。 +- (5.4.0 以降) TiKV ノード上のBRスレッド数が`8`以下で、クラスターの CPU 使用率が 60% を超えない場合、 BRタスクはクラスター (書き込みと読み取り) にほとんど影響を与えません。 以下の方法を使用すると、バックアップタスクがクラスタのパフォーマンスに与える影響を手動で制御できます。ただし、これらの2つの方法は、バックアップタスクがクラスタに与える影響を軽減する一方で、バックアップタスクの速度も低下させます。 -- 推奨される方法: TiKV 構成パラメータ[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整します。このパラメータは、バックアップ タスクで使用されるワーカー スレッドの数を制御します。バックアップは CPU 負荷の高い操作であるため、このパラメータを調整することで TiKV の CPU 使用率をより正確に制御でき、リソースの分離と予測性を向上させることができます。ほとんどのシナリオでは、 `num-threads`を調整するだけで、バックアップがクラスタに与える影響を制限できます。内部テストでは、スレッド数を`8`以下に設定し、クラスタ全体の CPU 使用率が 60% 未満に維持されている場合、バックアップがフォアグラウンド ワークロードに与える影響はごくわずかであることが示されています。 +- 推奨される方法: TiKV 構成パラメータ[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整します。このパラメータは、バックアップ タスクで使用されるワーカー スレッドの数を制御します。バックアップは CPU 負荷の高い操作であるため、このパラメータを調整することで TiKV の CPU 使用率をより正確に制御でき、リソースの分離と予測性を向上させることができます。ほとんどのシナリオでは、 `num-threads`を調整するだけで、バックアップがクラスタに与える影響を制限できます。内部テストでは、スレッド数を`8`以下に設定し、クラスタ全体の CPU 使用率が 60% 未満に維持されている場合、バックアップがフォアグラウンド ワークロードに与える影響はごくわずかであることが示されています。 -- 代替方法: `backup.num-threads`を既に小さな値 (たとえば`1` ) に設定しているが、バックアップがクラスタに与える影響をさらに軽減したい場合は、 `--ratelimit`パラメータの使用を検討してください。このオプションは、バックアップ ファイルを外部ストレージに書き込むために使用される帯域幅を MiB/s で制限します。実際のレート制限効果は、圧縮データのサイズによって異なることに注意してください。詳細については、ログの`backup data size (after compressed)`フィールドを参照してください。 `--ratelimit`が有効になっている場合、 BR は自動的に`--concurrency`を`1`に設定して、同時リクエストの数を減らします。 +- 代替方法: `backup.num-threads`を既に小さな値 (たとえば`1` ) に設定しているが、バックアップがクラスタに与える影響をさらに軽減したい場合は、 `--ratelimit`パラメータの使用を検討してください。このオプションは、バックアップ ファイルを外部ストレージに書き込むために使用される帯域幅を MiB/s で制限します。実際のレート制限効果は、圧縮データのサイズによって異なることに注意してください。詳細については、ログの`backup data size (after compressed)`フィールドを参照してください。 `--ratelimit`が有効になっている場合、 BR は自動的に`--concurrency`を`1`に設定して、同時リクエストの数を減らします。 > **Note:** > @@ -228,25 +228,25 @@ tiup br restore full \ > > このような状況では、以下の選択肢を検討できます。 > -> - [クラスターをスケールアウトする](/tiup/tiup-cluster.md#scale-out-a-cluster)利用可能なリソースを増やします。 -> - [`Log Backup`](/br/br-log-architecture.md)を有効にすることで、バックアップ負荷を軽減し、オンラインワークロードへの影響を最小限に抑えることができます。 +> - [クラスターをスケールアウトする](/tiup/tiup-cluster.md#scale-out-a-cluster)利用可能なリソースを増やします。 +> - [`Log Backup`](/br/br-log-architecture.md)を有効にすることで、バックアップ負荷を軽減し、オンラインワークロードへの影響を最小限に抑えることができます。 バックアップスレッドの数を制限することで、クラスタのパフォーマンスに対するバックアップの影響を軽減できますが、これはバックアップのパフォーマンスに影響を与えます。前述のテスト結果から、バックアップ速度はバックアップスレッドの数に比例することがわかっています。スレッド数が少ない場合、バックアップ速度は約20 MiB/スレッドです。例えば、単一のTiKVノードで5つのバックアップスレッドを使用すると、100 MiB/秒のバックアップ速度を達成できます。 ### スナップショット復元のパフォーマンスと影響 {#performance-and-impact-of-snapshot-restore} -- データ復元中、TiDBはTiKVのCPU、ディスクI/O、およびネットワーク帯域幅のリソースを最大限に活用しようとします。そのため、実行中のアプリケーションへの影響を避けるため、バックアップデータは空のクラスタに復元することをお勧めします。 -- バックアップデータの復元速度は、クラスタ構成、デプロイメント、および実行中のアプリケーションに大きく左右されます。スナップショット復元のパフォーマンスと影響は、さまざまなユーザーシナリオによって異なるため、実際の環境でテストする必要があります。 -- BRは、大規模なリージョンシナリオにおけるリージョン復元を高速化するために、粗粒度リージョン分散アルゴリズムを提供します。このアルゴリズムにより、各TiKVノードが安定した均等に分散されたダウンロードタスクを受け取ることが保証され、各TiKVノードのリソースを最大限に活用して、迅速な並列リカバリを実現します。実際のいくつかの事例では、大規模なリージョンシナリオにおいて、クラスタのスナップショット復元速度が約3倍向上しました。 -- バージョン8.0.0以降、 `br`コマンドラインツールに`--tikv-max-restore-concurrency`パラメータが導入され、 BRがTiKVノードごとにダウンロードおよび取り込むファイルの最大数を制御するようになりました。このパラメータを設定することで、ジョブキューの最大長（ジョブキューの最大長 = 32 * TiKVノード数 * `--tikv-max-restore-concurrency` ）も制御でき、 BRノードのメモリ消費量を制御できます。 +- データ復元中、TiDBはTiKVのCPU、ディスクI/O、およびネットワーク帯域幅のリソースを最大限に活用しようとします。そのため、実行中のアプリケーションへの影響を避けるため、バックアップデータは空のクラスタに復元することをお勧めします。 +- バックアップデータの復元速度は、クラスタ構成、デプロイメント、および実行中のアプリケーションに大きく左右されます。スナップショット復元のパフォーマンスと影響は、さまざまなユーザーシナリオによって異なるため、実際の環境でテストする必要があります。 +- BRは、大規模なリージョンシナリオにおけるリージョン復元を高速化するために、粗粒度リージョン分散アルゴリズムを提供します。このアルゴリズムにより、各TiKVノードが安定した均等に分散されたダウンロードタスクを受け取ることが保証され、各TiKVノードのリソースを最大限に活用して、迅速な並列リカバリを実現します。実際のいくつかの事例では、大規模なリージョンシナリオにおいて、クラスタのスナップショット復元速度が約3倍向上しました。 +- バージョン8.0.0以降、 `br`コマンドラインツールに`--tikv-max-restore-concurrency`パラメータが導入され、 BRがTiKVノードごとにダウンロードおよび取り込むファイルの最大数を制御するようになりました。このパラメータを設定することで、ジョブキューの最大長（ジョブキューの最大長 = 32 \* TiKVノード数 \* `--tikv-max-restore-concurrency` ）も制御でき、 BRノードのメモリ消費量を制御できます。 通常の場合、 `--tikv-max-restore-concurrency`はクラスタ構成に基づいて自動的に調整されるため、手動構成は不要です。Grafana の**TiKV-Details** > **Backup & Import** > **Import RPC count**監視メトリックで、 BR がダウンロードするファイルの数が長期間 0 に近いままで、 BRが取り込むファイルの数が常に上限に達している場合、ファイル取り込みタスクが蓄積され、ジョブキューが最大長に達していることを示しています。この場合、タスクの蓄積問題を軽減するために、次の対策を講じることができます。 - - `--ratelimit`パラメータを設定してダウンロード速度を制限し、ファイル取り込みタスクに必要なリソースを確保します。たとえば、いずれかの TiKV ノードのディスク スループットが`x MiB/s`で、バックアップ ファイルのダウンロード用ネットワーク帯域幅が`x/2 MiB/s`を超える場合は、このパラメータを`--ratelimit x/2`に設定できます。いずれかの TiKV ノードのディスク スループットが`x MiB/s`で、バックアップ ファイルのダウンロード用ネットワーク帯域幅が`x/2 MiB/s`以下である場合は、 `--ratelimit`パラメータを設定せずにそのままにできます。 - - ジョブキューの最大長を増やすには、 `--tikv-max-restore-concurrency`の値を増やします。 + - `--ratelimit`パラメータを設定してダウンロード速度を制限し、ファイル取り込みタスクに必要なリソースを確保します。たとえば、いずれかの TiKV ノードのディスク スループットが`x MiB/s`で、バックアップ ファイルのダウンロード用ネットワーク帯域幅が`x/2 MiB/s`を超える場合は、このパラメータを`--ratelimit x/2`に設定できます。いずれかの TiKV ノードのディスク スループットが`x MiB/s`で、バックアップ ファイルのダウンロード用ネットワーク帯域幅が`x/2 MiB/s`以下である場合は、 `--ratelimit`パラメータを設定せずにそのままにできます。 + - ジョブキューの最大長を増やすには、 `--tikv-max-restore-concurrency`の値を増やします。 ## 関連項目 {#see-also} -- [TiDBのバックアップとリストアのユースケース](/br/backup-and-restore-use-cases.md) -- [コマンドラインマニュアル](/br/use-br-command-line-tool.md) -- [TiDBスナップショットバックアップおよびリストアアーキテクチャ](/br/br-snapshot-architecture.md) +- [TiDBのバックアップとリストアのユースケース](/br/backup-and-restore-use-cases.md) +- [コマンドラインマニュアル](/br/use-br-command-line-tool.md) +- [TiDBスナップショットバックアップおよびリストアアーキテクチャ](/br/br-snapshot-architecture.md) diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md index 6619f9399231e..e8cfcd16a6570 100644 --- a/br/br-snapshot-manual.md +++ b/br/br-snapshot-manual.md @@ -7,25 +7,25 @@ summary: TiDBスナップショットのバックアップと復元コマンド このドキュメントでは、次のようなアプリケーション シナリオに応じて、TiDB スナップショットのバックアップと復元のコマンドについて説明します。 -- [クラスターのスナップショットをバックアップする](#back-up-cluster-snapshots) -- [データベースまたはテーブルをバックアップする](#back-up-a-database-or-a-table) - - [データベースをバックアップする](#back-up-a-database) - - [テーブルをバックアップする](#back-up-a-table) - - [テーブルフィルターを使用して複数のテーブルをバックアップする](#back-up-multiple-tables-with-table-filter) -- [統計のバックアップ](#back-up-statistics) -- [バックアップデータを暗号化する](#encrypt-the-backup-data) -- [クラスタースナップショットを復元する](#restore-cluster-snapshots) -- [データベースまたはテーブルを復元する](#restore-a-database-or-a-table) - - [データベースを復元する](#restore-a-database) - - [テーブルを復元する](#restore-a-table) - - [テーブルフィルターを使用して複数のテーブルを復元する](#restore-multiple-tables-with-table-filter) - - [`mysql`スキーマから実行プランバインディングを復元する](#restore-execution-plan-bindings-from-the-mysql-schema) -- [暗号化されたスナップショットを復元する](#restore-encrypted-snapshots) +- [クラスターのスナップショットをバックアップする](#back-up-cluster-snapshots) +- [データベースまたはテーブルをバックアップする](#back-up-a-database-or-a-table) + - [データベースをバックアップする](#back-up-a-database) + - [テーブルをバックアップする](#back-up-a-table) + - [テーブルフィルターを使用して複数のテーブルをバックアップする](#back-up-multiple-tables-with-table-filter) +- [統計のバックアップ](#back-up-statistics) +- [バックアップデータを暗号化する](#encrypt-the-backup-data) +- [クラスタースナップショットを復元する](#restore-cluster-snapshots) +- [データベースまたはテーブルを復元する](#restore-a-database-or-a-table) + - [データベースを復元する](#restore-a-database) + - [テーブルを復元する](#restore-a-table) + - [テーブルフィルターを使用して複数のテーブルを復元する](#restore-multiple-tables-with-table-filter) + - [`mysql`スキーマから実行プランバインディングを復元する](#restore-execution-plan-bindings-from-the-mysql-schema) +- [暗号化されたスナップショットを復元する](#restore-encrypted-snapshots) スナップショットのバックアップと復元の詳細については、以下を参照してください。 -- [スナップショットのバックアップと復元ガイド](/br/br-snapshot-guide.md) -- [バックアップと復元のユースケース](/br/backup-and-restore-use-cases.md) +- [スナップショットのバックアップと復元ガイド](/br/br-snapshot-guide.md) +- [バックアップと復元のユースケース](/br/backup-and-restore-use-cases.md) ## クラスターのスナップショットをバックアップする {#back-up-cluster-snapshots} @@ -41,13 +41,13 @@ tiup br backup full \ 上記のコマンドでは、次のようになります。 -- `--backupts` : スナップショットの時点。形式は[TSO](/tso.md)またはタイムスタンプ（例： `400036290571534337` 、 `2024-06-28 13:30:00 +08:00`です。このスナップショットのデータがガベージコレクションされた場合、 `tiup br backup`コマンドはエラーを返し、 'br' は終了します。このパラメータを指定しない場合、 `br`バックアップ開始時刻に対応するスナップショットを選択します。 -- `--log-file` : `br`ログが書き込まれる対象ファイル。 +- `--backupts` : スナップショットの時点。形式は[TSO](/tso.md)またはタイムスタンプ（例： `400036290571534337` 、 `2024-06-28 13:30:00 +08:00`です。このスナップショットのデータがガベージコレクションされた場合、 `tiup br backup`コマンドはエラーを返し、 'br' は終了します。このパラメータを指定しない場合、 `br`バックアップ開始時刻に対応するスナップショットを選択します。 +- `--log-file` : `br`ログが書き込まれる対象ファイル。 > **Note:** > -> - v8.5.0 以降、 BRツールは、バックアップ パフォーマンスを向上させるために、フル バックアップ中のテーブル レベルのチェックサム計算をデフォルトで無効にします ( `--checksum=false` )。 -> - BRツールは既にGCへの自己適応をサポートしています。バックアップ中にTiDBのGCセーフポイントが先に進まないように、PDのタイムスタンプ`backupTS` （デフォルトでは最新のPDタイムスタンプ）をPDの`safePoint`に自動的に登録することで、GC設定を手動で設定する必要がなくなります。 +> - v8.5.0 以降、 BRツールは、バックアップ パフォーマンスを向上させるために、フル バックアップ中のテーブル レベルのチェックサム計算をデフォルトで無効にします ( `--checksum=false` )。 +> - BRツールは既にGCへの自己適応をサポートしています。バックアップ中にTiDBのGCセーフポイントが先に進まないように、PDのタイムスタンプ`backupTS` （デフォルトでは最新のPDタイムスタンプ）をPDの`safePoint`に自動的に登録することで、GC設定を手動で設定する必要がなくなります。 バックアップ中は、ターミナルに以下のようにプログレスバーが表示されます。プログレスバーが100%に達すると、バックアップが完了します。 @@ -148,9 +148,9 @@ BRはバックアップ側でのバックアップデータの暗号化と[Amazo TiDB v5.3.0 以降では、次のパラメータを設定することでバックアップ データを暗号化できます。 -- `--crypter.method` : 暗号化アルゴリズム`aes128-ctr` `aes192-ctr`または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 -- `--crypter.key` : 16進文字列形式の暗号化キー。アルゴリズム`aes128-ctr`の場合は128ビット（16バイト）、アルゴリズム`aes192-ctr`の場合は24バイト、アルゴリズム`aes256-ctr`の場合は32バイトのキーです。 -- `--crypter.key-file` : キーファイル。`crypter.key`を渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。 +- `--crypter.method` : 暗号化アルゴリズム`aes128-ctr` `aes192-ctr`または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。 +- `--crypter.key` : 16進文字列形式の暗号化キー。アルゴリズム`aes128-ctr`の場合は128ビット（16バイト）、アルゴリズム`aes192-ctr`の場合は24バイト、アルゴリズム`aes256-ctr`の場合は32バイトのキーです。 +- `--crypter.key-file` : キーファイル。`crypter.key`を渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。 次に例を示します。 @@ -164,8 +164,8 @@ tiup br backup full\ > **Note:** > -> - キーが失われると、バックアップ データをクラスターに復元できなくなります。 -> - 暗号化機能は、 `br`および TiDB クラスタ v5.3.0 以降で使用する必要があります。暗号化されたバックアップデータは、v5.3.0 より前のクラスタでは復元できません。 +> - キーが失われると、バックアップ データをクラスターに復元できなくなります。 +> - 暗号化機能は、 `br`および TiDB クラスタ v5.3.0 以降で使用する必要があります。暗号化されたバックアップデータは、v5.3.0 より前のクラスタでは復元できません。 ## クラスタースナップショットを復元する {#restore-cluster-snapshots} @@ -182,9 +182,9 @@ 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)を参照してください。 -- `--ratelimit` : 復元タスクを実行する**TiKVあたりの**最大速度。単位はMiB/sです。 -- `--log-file` : `br`ログが書き込まれる対象ファイル。 +- `--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`ログが書き込まれる対象ファイル。 復元中は、ターミナルに以下のプログレスバーが表示されます。プログレスバーが100%に達すると、復元タスクが完了します。 `br` 、データのセキュリティを確保するため、復元されたデータの検証を行います。 diff --git a/br/br-use-overview.md b/br/br-use-overview.md index 5f476dc80f687..1d52e20406f67 100644 --- a/br/br-use-overview.md +++ b/br/br-use-overview.md @@ -15,17 +15,17 @@ TiDB のバックアップおよび復元機能を使用する前に、推奨さ **TiDBには2種類のバックアップがあります。どちらを使用すればよいでしょうか？**フルバックアップには、特定の時点におけるクラスターの全データが含まれます。ログバックアップには、TiDBに書き込まれたデータの変更が含まれます。両方のバックアップを同時に使用することをお勧めします。 -- **ログバックアップの開始**： `tiup br log start`のコマンドを実行してログバックアップタスクを開始します。その後、タスクはすべてのTiKVノードで実行され続け、TiDBデータの変更を小さなバッチで指定されたストレージに定期的にバックアップします。 -- **スナップショット（フル）バックアップを定期的に実行する**： `tiup br backup full`のコマンドを実行して、クラスターのスナップショットを指定されたストレージにバックアップします。例えば、毎日午前0時にクラスターのスナップショットをバックアップします。 +- **ログバックアップの開始**： `tiup br log start`のコマンドを実行してログバックアップタスクを開始します。その後、タスクはすべてのTiKVノードで実行され続け、TiDBデータの変更を小さなバッチで指定されたストレージに定期的にバックアップします。 +- **スナップショット（フル）バックアップを定期的に実行する**： `tiup br backup full`のコマンドを実行して、クラスターのスナップショットを指定されたストレージにバックアップします。例えば、毎日午前0時にクラスターのスナップショットをバックアップします。 ### バックアップデータを管理するにはどうすればいいですか? {#how-to-manage-backup-data} BRは基本的なバックアップと復元機能のみを提供し、バックアップ管理はサポートしていません。そのため、バックアップデータの管理方法をご自身で決定する必要があります。具体的には、以下のような点についてご検討ください。 -- どのバックアップストレージシステムを選択すればよいですか? -- バックアップ タスク中にバックアップ データをどのディレクトリに配置すればよいですか? -- フルバックアップデータとログバックアップデータのディレクトリはどのように整理すればよいですか? -- ストレージシステム内の履歴バックアップ データをどのように処理しますか? +- どのバックアップストレージシステムを選択すればよいですか? +- バックアップ タスク中にバックアップ データをどのディレクトリに配置すればよいですか? +- フルバックアップデータとログバックアップデータのディレクトリはどのように整理すればよいですか? +- ストレージシステム内の履歴バックアップ データをどのように処理しますか? 次のセクションでは、これらの質問に 1 つずつ答えていきます。 @@ -35,8 +35,8 @@ BRは基本的なバックアップと復元機能のみを提供し、バック TiDB クラスターを独自に構築したデータ センターに導入する場合は、次のプラクティスが推奨されます。 -- バックアップストレージシステムとして[MinIO](https://docs.min.io/docs/minio-quickstart-guide.html)構築し、S3 プロトコルを使用してデータを MinIO にバックアップします。 -- ネットワーク ファイル システム (NFS、NAS など) ディスクを br コマンドライン ツールとすべての TiKV インスタンスにマウントし、POSIX ファイル システム インターフェイスを使用して、バックアップ データを対応する NFS ディレクトリに書き込みます。 +- バックアップストレージシステムとして[MinIO](https://docs.min.io/docs/minio-quickstart-guide.html)構築し、S3 プロトコルを使用してデータを MinIO にバックアップします。 +- ネットワーク ファイル システム (NFS、NAS など) ディスクを br コマンドライン ツールとすべての TiKV インスタンスにマウントし、POSIX ファイル システム インターフェイスを使用して、バックアップ データを対応する NFS ディレクトリに書き込みます。 > **Note:** > @@ -44,30 +44,30 @@ TiDB クラスターを独自に構築したデータ センターに導入す **バックアップデータディレクトリを整理する** -- 統合管理のため、スナップショット バックアップとログ バックアップを同じディレクトリ (例: `backup-${cluster-id}` ) に保存します。 -- 各スナップショット バックアップを、バックアップの日付が含まれるディレクトリ (例: `backup-${cluster-id}/fullbackup-202209081330` ) に保存します。 -- ログバックアップは固定ディレクトリ（例： `backup-${cluster-id}/logbackup` ）に保存されます。ログバックアッププログラムは、毎日`logbackup`ディレクトリの下にサブディレクトリを作成し、毎日バックアップされたデータを区別します。 +- 統合管理のため、スナップショット バックアップとログ バックアップを同じディレクトリ (例: `backup-${cluster-id}` ) に保存します。 +- 各スナップショット バックアップを、バックアップの日付が含まれるディレクトリ (例: `backup-${cluster-id}/fullbackup-202209081330` ) に保存します。 +- ログバックアップは固定ディレクトリ（例： `backup-${cluster-id}/logbackup` ）に保存されます。ログバックアッププログラムは、毎日`logbackup`ディレクトリの下にサブディレクトリを作成し、毎日バックアップされたデータを区別します。 **履歴バックアップデータの処理** 各バックアップデータのライフサイクル（例えば7日間）を設定する必要があるとします。このようなライフサイクルは**バックアップ保持期間**と呼ばれ、バックアップチュートリアルでも説明されています。 -- PITRを実行するには、復元ポイントより前の完全バックアップと、完全バックアップと復元ポイント間のログバックアップを復元する必要があります。そのため、**完全スナップショットより前のログバックアップのみを削除することをお勧めします**。バックアップ保持期間を超えるログバックアップの場合は、 `tiup br log truncate`コマンドを使用して、指定した時点より前のバックアップを削除できます。 -- 保存期間を超えたバックアップ データについては、バックアップ ディレクトリを削除またはアーカイブできます。 +- PITRを実行するには、復元ポイントより前の完全バックアップと、完全バックアップと復元ポイント間のログバックアップを復元する必要があります。そのため、**完全スナップショットより前のログバックアップのみを削除することをお勧めします**。バックアップ保持期間を超えるログバックアップの場合は、 `tiup br log truncate`コマンドを使用して、指定した時点より前のバックアップを削除できます。 +- 保存期間を超えたバックアップ データについては、バックアップ ディレクトリを削除またはアーカイブできます。 ### データを復元するにはどうすればいいですか? {#how-to-restore-data} -- 完全バックアップ データのみを復元するには、 `tiup br restore`を使用して、指定したバックアップの完全復元を実行できます。 -- ログ バックアップを開始し、定期的に完全バックアップを実行している場合は、 `tiup br restore point`コマンドを実行して、バックアップ保持期間内の任意の時点にデータを復元できます。 +- 完全バックアップ データのみを復元するには、 `tiup br restore`を使用して、指定したバックアップの完全復元を実行できます。 +- ログ バックアップを開始し、定期的に完全バックアップを実行している場合は、 `tiup br restore point`コマンドを実行して、バックアップ保持期間内の任意の時点にデータを復元できます。 ## BRをデプロイて使用する {#deploy-and-use-br} BRを展開するには、次の要件が満たされていることを確認してください。 -- BR、TiKVノード、およびバックアップストレージシステムは、バックアップ速度よりも大きなネットワーク帯域幅を提供します。ターゲットクラスターが非常に大規模な場合、バックアップおよびリストア速度のしきい値は、バックアップネットワークの帯域幅によって制限されます。 -- バックアップストレージシステムは、十分な読み取りおよび書き込みパフォーマンス（IOPS）を提供します。そうでない場合、バックアップまたは復元中にパフォーマンスのボトルネックになる可能性があります。 -- TiKVノードには、バックアップ用に少なくとも2つの追加CPUコアと高性能ディスクが搭載されています。そうでない場合、バックアップがクラスターで実行されているサービスに影響を及ぼす可能性があります。 -- BR は、8 個以上のコアと 16 GiB のメモリを備えたノードで実行されます。 +- BR、TiKVノード、およびバックアップストレージシステムは、バックアップ速度よりも大きなネットワーク帯域幅を提供します。ターゲットクラスターが非常に大規模な場合、バックアップおよびリストア速度のしきい値は、バックアップネットワークの帯域幅によって制限されます。 +- バックアップストレージシステムは、十分な読み取りおよび書き込みパフォーマンス（IOPS）を提供します。そうでない場合、バックアップまたは復元中にパフォーマンスのボトルネックになる可能性があります。 +- TiKVノードには、バックアップ用に少なくとも2つの追加CPUコアと高性能ディスクが搭載されています。そうでない場合、バックアップがクラスターで実行されているサービスに影響を及ぼす可能性があります。 +- BR は、8 個以上のコアと 16 GiB のメモリを備えたノードで実行されます。 バックアップと復元機能は、コマンドラインツール、SQLコマンドの実行、 TiDB Operatorの使用など、いくつかの方法で使用できます。以下のセクションでは、これら3つの方法について詳しく説明します。 @@ -75,20 +75,20 @@ BRを展開するには、次の要件が満たされていることを確認し TiDB は、br コマンドライン ツールを使用したバックアップと復元をサポートしています。 -- `tiup install br`コマンドを[TiUPオンラインを使用してbrコマンドラインツールをインストールする](/migration-tools.md#install-tools-using-tiup)まで実行できます。 -- `br`コマンドを使用してデータをバックアップおよび復元する方法の詳細については、次のドキュメントを参照してください。 +- `tiup install br`コマンドを[TiUPオンラインを使用してbrコマンドラインツールをインストールする](/migration-tools.md#install-tools-using-tiup)まで実行できます。 +- `br`コマンドを使用してデータをバックアップおよび復元する方法の詳細については、次のドキュメントを参照してください。 - - [TiDB スナップショットのバックアップと復元ガイド](/br/br-snapshot-guide.md) - - [TiDB ログバックアップと PITR ガイド](/br/br-pitr-guide.md) - - [TiDB バックアップとリストアのユースケース](/br/backup-and-restore-use-cases.md) + - [TiDB スナップショットのバックアップと復元ガイド](/br/br-snapshot-guide.md) + - [TiDB ログバックアップと PITR ガイド](/br/br-pitr-guide.md) + - [TiDB バックアップとリストアのユースケース](/br/backup-and-restore-use-cases.md) ### SQL文を使用する {#use-sql-statements} TiDB は、SQL ステートメントを使用した完全バックアップと復元をサポートします。 -- [`BACKUP`](/sql-statements/sql-statement-backup.md) : 完全なスナップショット データをバックアップします。 -- [`RESTORE`](/sql-statements/sql-statement-restore.md) : スナップショット バックアップ データを復元します。 -- [`SHOW BACKUPS|RESTORES`](/sql-statements/sql-statement-show-backups.md) : バックアップと復元の進行状況を表示します。 +- [`BACKUP`](/sql-statements/sql-statement-backup.md) : 完全なスナップショット データをバックアップします。 +- [`RESTORE`](/sql-statements/sql-statement-restore.md) : スナップショット バックアップ データを復元します。 +- [`SHOW BACKUPS|RESTORES`](/sql-statements/sql-statement-show-backups.md) : バックアップと復元の進行状況を表示します。 ### Kubernetes でTiDB Operatorを使用する {#use-tidb-operator-on-kubernetes} @@ -96,5 +96,5 @@ Kubernetesでは、 TiDB Operatorを使用してTiDBクラスターのデータ ## 参照 {#see-also} -- [TiDB バックアップと復元の概要](/br/backup-and-restore-overview.md) -- [TiDB バックアップおよびリストアアーキテクチャ](/br/backup-and-restore-design.md) +- [TiDB バックアップと復元の概要](/br/backup-and-restore-overview.md) +- [TiDB バックアップおよびリストアアーキテクチャ](/br/backup-and-restore-design.md) diff --git a/br/use-br-command-line-tool.md b/br/use-br-command-line-tool.md index d3591637b2dd2..44f4fc6dd9dac 100644 --- a/br/use-br-command-line-tool.md +++ b/br/use-br-command-line-tool.md @@ -20,77 +20,77 @@ tiup br backup full --pd "${PD_IP}:2379" \ 上記のコマンドの説明は次のとおりです。 -- `backup` : `tiup br`のサブコマンド。 -- `full` : `tiup br backup`のサブコマンド。 -- `-s` (または`--storage` ): バックアップ ファイルが保存されるパスを指定するオプション。`"s3://backup-data/snapshot-202209081330/"`は`-s`のパラメーターです。 -- `--pd` : PD サービス アドレスを指定するオプション`"${PD_IP}:2379"`は`--pd`のパラメーターです。 +- `backup` : `tiup br`のサブコマンド。 +- `full` : `tiup br backup`のサブコマンド。 +- `-s` (または`--storage` ): バックアップ ファイルが保存されるパスを指定するオプション。`"s3://backup-data/snapshot-202209081330/"`は`-s`のパラメーターです。 +- `--pd` : PD サービス アドレスを指定するオプション`"${PD_IP}:2379"`は`--pd`のパラメーターです。 ### コマンドとサブコマンド {#commands-and-sub-commands} `tiup br`コマンドは複数のサブコマンドの階層で構成されています。現在、br コマンドラインツールには以下のサブコマンドがあります。 -- `tiup br backup` : TiDB クラスターのデータをバックアップするために使用されます。 -- `tiup br log` : ログ バックアップ タスクの開始と管理に使用されます。 -- `tiup br restore` : TiDB クラスターのバックアップ データを復元するために使用されます。 -- `tiup br debug` : バックアップ メタデータの解析、バックアップ データのチェックなどに使用されます。 +- `tiup br backup` : TiDB クラスターのデータをバックアップするために使用されます。 +- `tiup br log` : ログ バックアップ タスクの開始と管理に使用されます。 +- `tiup br restore` : TiDB クラスターのバックアップ データを復元するために使用されます。 +- `tiup br debug` : バックアップ メタデータの解析、バックアップ データのチェックなどに使用されます。 `tiup br backup`および`tiup br restore`は次のサブコマンドが含まれます。 -- `full` : すべてのクラスター データをバックアップまたは復元するために使用されます。 -- `db` : クラスターの指定されたデータベースをバックアップまたは復元するために使用されます。 -- `table` : クラスターの指定されたデータベース内の単一のテーブルをバックアップまたは復元するために使用されます。 +- `full` : すべてのクラスター データをバックアップまたは復元するために使用されます。 +- `db` : クラスターの指定されたデータベースをバックアップまたは復元するために使用されます。 +- `table` : クラスターの指定されたデータベース内の単一のテーブルをバックアップまたは復元するために使用されます。 `tiup br debug`には次のサブコマンドが含まれます。 -- `checksum` : (隠しパラメーター) バックアップ データの整合性をオフラインでチェックし、すべてのバックアップ ファイルが[`ADMIN CHECKSUM TABLE`](/sql-statements/sql-statement-admin-checksum-table.md)で計算された CRC64 チェックサム結果と一致することを確認するために使用されます。 -- `backupmeta` : バックアップデータファイル間に交差が存在するかどうかを確認するために使用されます。通常、バックアップデータファイルは交差しません。 -- `decode` : 完全バックアップのメタデータファイル`backupmeta` JSON形式に解析するために使用されます。さらに、 `--field`パラメータを使用して特定のフィールドを解析することもできます。 -- `encode` : 完全バックアップの`backupmeta.json`メタデータ ファイルを、データの復元中に使用される protobuf 形式にエンコードするために使用されます。 -- `reset-pd-config-as-default` : (非推奨) データ回復プロセス中に変更された PD 構成をデフォルト構成に復元するために使用されます。 -- `search-log-backup` : ログ バックアップ データ内の特定のキー情報を検索するために使用されます。 +- `checksum` : (隠しパラメーター) バックアップ データの整合性をオフラインでチェックし、すべてのバックアップ ファイルが[`ADMIN CHECKSUM TABLE`](/sql-statements/sql-statement-admin-checksum-table.md)で計算された CRC64 チェックサム結果と一致することを確認するために使用されます。 +- `backupmeta` : バックアップデータファイル間に交差が存在するかどうかを確認するために使用されます。通常、バックアップデータファイルは交差しません。 +- `decode` : 完全バックアップのメタデータファイル`backupmeta` JSON形式に解析するために使用されます。さらに、 `--field`パラメータを使用して特定のフィールドを解析することもできます。 +- `encode` : 完全バックアップの`backupmeta.json`メタデータ ファイルを、データの復元中に使用される protobuf 形式にエンコードするために使用されます。 +- `reset-pd-config-as-default` : (非推奨) データ回復プロセス中に変更された PD 構成をデフォルト構成に復元するために使用されます。 +- `search-log-backup` : ログ バックアップ データ内の特定のキー情報を検索するために使用されます。 ### 一般的なオプション {#common-options} -- `--pd` : PDサービスアドレスを指定します。例： `"${PD_IP}:2379"` 。 -- `-s` （または`--storage` ）: バックアップファイルを保存するパスを指定します。バックアップデータの保存には、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、NFSがサポートされています。詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 -- `--ca` : PEM 形式の信頼された CA 証明書へのパスを指定します。 -- `--cert` : PEM 形式の SSL 証明書へのパスを指定します。 -- `--key` : PEM 形式の SSL 証明書キーへのパスを指定します。 -- `--status-addr` : `br` Prometheus に統計を提供するリスニング アドレスを指定します。 -- `--concurrency` : バックアップタスクを複数のリクエストに分割し、同じ TiKV ノードに同時に送信する方法を制御します。このパラメータは主にBRから TiKV へのリクエスト分割の粒度に影響し、全体的なバックアップスループットを直接決定するものではありません。ほとんどの場合、この値を変更する必要はありません。バックアップパフォーマンスを向上させるには、代わりに[`tikv.backup.num-threads`](/tikv-configuration-file.md#num-threads-1)調整する必要があります。 -- `--pitr-concurrency` : ログ復元中の同時タスクの数。 -- `--tikv-max-restore-concurrency` : スナップショット復元中の TiKV ノードあたりの同時タスクの最大数。 -- `--compression` : バックアップファイルの生成に使用する圧縮アルゴリズムを決定します。`lz4` 、 `snappy` 、 `zstd`をサポートし、デフォルトは`zstd`です（通常は変更する必要はありません）。異なる圧縮アルゴリズムの選択に関するガイダンスについては、 [この文書](https://github.com/EighteenZi/rocksdb_wiki/blob/master/Compression.md)を参照してください。 -- `--compression-level` : バックアップに選択した圧縮アルゴリズムに対応する圧縮レベルを設定します。`zstd`のデフォルトの圧縮レベルは 3 です。ほとんどの場合、このオプションを設定する必要はありません。 +- `--pd` : PDサービスアドレスを指定します。例： `"${PD_IP}:2379"` 。 +- `-s` （または`--storage` ）: バックアップファイルを保存するパスを指定します。バックアップデータの保存には、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、NFSがサポートされています。詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 +- `--ca` : PEM 形式の信頼された CA 証明書へのパスを指定します。 +- `--cert` : PEM 形式の SSL 証明書へのパスを指定します。 +- `--key` : PEM 形式の SSL 証明書キーへのパスを指定します。 +- `--status-addr` : `br` Prometheus に統計を提供するリスニング アドレスを指定します。 +- `--concurrency` : バックアップタスクを複数のリクエストに分割し、同じ TiKV ノードに同時に送信する方法を制御します。このパラメータは主にBRから TiKV へのリクエスト分割の粒度に影響し、全体的なバックアップスループットを直接決定するものではありません。ほとんどの場合、この値を変更する必要はありません。バックアップパフォーマンスを向上させるには、代わりに[`tikv.backup.num-threads`](/tikv-configuration-file.md#num-threads-1)調整する必要があります。 +- `--pitr-concurrency` : ログ復元中の同時タスクの数。 +- `--tikv-max-restore-concurrency` : スナップショット復元中の TiKV ノードあたりの同時タスクの最大数。 +- `--compression` : バックアップファイルの生成に使用する圧縮アルゴリズムを決定します。`lz4` 、 `snappy` 、 `zstd`をサポートし、デフォルトは`zstd`です（通常は変更する必要はありません）。異なる圧縮アルゴリズムの選択に関するガイダンスについては、 [この文書](https://github.com/EighteenZi/rocksdb_wiki/blob/master/Compression.md)を参照してください。 +- `--compression-level` : バックアップに選択した圧縮アルゴリズムに対応する圧縮レベルを設定します。`zstd`のデフォルトの圧縮レベルは 3 です。ほとんどの場合、このオプションを設定する必要はありません。 ## フルバックアップのコマンド {#commands-of-full-backup} クラスターデータをバックアップするには、 `tiup br backup`コマンドを実行します。`full`または`table`サブコマンドを追加して、バックアップ操作の範囲（クラスター全体（ `full` ）または単一のテーブル（ `table` ））を指定できます。 -- [TiDB クラスターのスナップショットをバックアップする](/br/br-snapshot-manual.md#back-up-cluster-snapshots) -- [データベースをバックアップする](/br/br-snapshot-manual.md#back-up-a-database) -- [テーブルをバックアップする](/br/br-snapshot-manual.md#back-up-a-table) -- [テーブルフィルターを使用して複数のテーブルをバックアップする](/br/br-snapshot-manual.md#back-up-multiple-tables-with-table-filter) -- [スナップショットを暗号化する](/br/backup-and-restore-storages.md#server-side-encryption) +- [TiDB クラスターのスナップショットをバックアップする](/br/br-snapshot-manual.md#back-up-cluster-snapshots) +- [データベースをバックアップする](/br/br-snapshot-manual.md#back-up-a-database) +- [テーブルをバックアップする](/br/br-snapshot-manual.md#back-up-a-table) +- [テーブルフィルターを使用して複数のテーブルをバックアップする](/br/br-snapshot-manual.md#back-up-multiple-tables-with-table-filter) +- [スナップショットを暗号化する](/br/backup-and-restore-storages.md#server-side-encryption) ## ログバックアップのコマンド {#commands-of-log-backup} ログ バックアップを開始し、ログ バックアップ タスクを管理するには、 `tiup br log`コマンドを実行します。 -- [ログバックアップタスクを開始する](/br/br-pitr-manual.md#start-a-log-backup-task) -- [ログバックアップのステータスを照会する](/br/br-pitr-manual.md#query-the-log-backup-status) -- [ログバックアップタスクを一時停止して再開する](/br/br-pitr-manual.md#pause-and-resume-a-log-backup-task) -- [ログバックアップタスクを停止して再開する](/br/br-pitr-manual.md#stop-and-restart-a-log-backup-task) -- [バックアップデータをクリーンアップする](/br/br-pitr-manual.md#clean-up-log-backup-data) -- [バックアップメタデータを確認する](/br/br-pitr-manual.md#view-the-log-backup-metadata) +- [ログバックアップタスクを開始する](/br/br-pitr-manual.md#start-a-log-backup-task) +- [ログバックアップのステータスを照会する](/br/br-pitr-manual.md#query-the-log-backup-status) +- [ログバックアップタスクを一時停止して再開する](/br/br-pitr-manual.md#pause-and-resume-a-log-backup-task) +- [ログバックアップタスクを停止して再開する](/br/br-pitr-manual.md#stop-and-restart-a-log-backup-task) +- [バックアップデータをクリーンアップする](/br/br-pitr-manual.md#clean-up-log-backup-data) +- [バックアップメタデータを確認する](/br/br-pitr-manual.md#view-the-log-backup-metadata) ## バックアップデータの復元コマンド {#commands-of-restoring-backup-data} クラスターデータを復元するには、コマンド`tiup br restore`を実行します。サブコマンド`full` 、 `db` 、または`table`を追加して、復元範囲を指定できます。復元範囲は、クラスター全体 ( `full` )、単一のデータベース ( `db` )、または単一のテーブル ( `table` ) です。 -- [ポイントインタイムリカバリ](/br/br-pitr-manual.md#restore-to-a-specified-point-in-time-pitr) -- [クラスタースナップショットを復元する](/br/br-snapshot-manual.md#restore-cluster-snapshots) -- [データベースを復元する](/br/br-snapshot-manual.md#restore-a-database) -- [テーブルを復元する](/br/br-snapshot-manual.md#restore-a-table) -- [テーブルフィルターを使用して複数のテーブルを復元する](/br/br-snapshot-manual.md#restore-multiple-tables-with-table-filter) -- [暗号化されたスナップショットを復元する](/br/br-snapshot-manual.md#restore-encrypted-snapshots) +- [ポイントインタイムリカバリ](/br/br-pitr-manual.md#restore-to-a-specified-point-in-time-pitr) +- [クラスタースナップショットを復元する](/br/br-snapshot-manual.md#restore-cluster-snapshots) +- [データベースを復元する](/br/br-snapshot-manual.md#restore-a-database) +- [テーブルを復元する](/br/br-snapshot-manual.md#restore-a-table) +- [テーブルフィルターを使用して複数のテーブルを復元する](/br/br-snapshot-manual.md#restore-multiple-tables-with-table-filter) +- [暗号化されたスナップショットを復元する](/br/br-snapshot-manual.md#restore-encrypted-snapshots) diff --git a/cached-tables.md b/cached-tables.md index 67651fd4a7515..847500b07cee1 100644 --- a/cached-tables.md +++ b/cached-tables.md @@ -13,15 +13,15 @@ TiDB v6.0.0では、頻繁にアクセスされるものの更新頻度の低い キャッシュされたテーブル機能は、次の特性を持つテーブルに適しています。 -- テーブルのデータ量は小さく、たとえば 4 MiB 未満です。 -- テーブルは読み取り専用であるか、ほとんど更新されません (たとえば、書き込み QPS (1 秒あたりのクエリ数) が 1 分あたり 10 回未満)。 -- テーブルは頻繁にアクセスされ、たとえば TiKV からの直接読み取り中に小さなテーブルでホットスポットが発生する場合など、読み取りパフォーマンスの向上が期待されます。 +- テーブルのデータ量は小さく、たとえば 4 MiB 未満です。 +- テーブルは読み取り専用であるか、ほとんど更新されません (たとえば、書き込み QPS (1 秒あたりのクエリ数) が 1 分あたり 10 回未満)。 +- テーブルは頻繁にアクセスされ、たとえば TiKV からの直接読み取り中に小さなテーブルでホットスポットが発生する場合など、読み取りパフォーマンスの向上が期待されます。 テーブルのデータ量が少ないにもかかわらず、データへのアクセス頻度が高い場合、TiKVではデータが特定のリージョンに集中し、ホットスポットリージョンと呼ばれるリージョンがパフォーマンスに影響を与えます。そのため、キャッシュテーブルの典型的な使用シナリオは以下のようになります。 -- アプリケーションが構成情報を読み取るコンフィグレーションテーブル。 -- 金融セクターの為替レート表。これらの表は1日に1回のみ更新され、リアルタイムではありません。 -- ほとんど更新されない銀行支店またはネットワーク情報テーブル。 +- アプリケーションが構成情報を読み取るコンフィグレーションテーブル。 +- 金融セクターの為替レート表。これらの表は1日に1回のみ更新され、リアルタイムではありません。 +- ほとんど更新されない銀行支店またはネットワーク情報テーブル。 設定テーブルを例に挙げてみましょう。アプリケーションを再起動すると、設定情報がすべての接続に読み込まれるため、読み取りレイテンシーが高くなります。この場合、キャッシュテーブル機能を使用することでこの問題を解決できます。 @@ -221,16 +221,16 @@ Query OK, 0 rows affected (0.00 sec) キャッシュされたテーブルは次の機能をサポート**しません**。 -- パーティション化されたテーブルで`ALTER TABLE t ADD PARTITION`操作を実行することはサポートされていません。 -- 一時テーブルで`ALTER TABLE t CACHE`操作を実行することはサポートされていません。 -- ビューに対して`ALTER TABLE t CACHE`操作を実行することはサポートされていません。 -- ステイル読み取りはサポートされていません。 -- キャッシュされたテーブルへの直接DDL操作はサポートされていません。DDL操作を実行する前に、まず`ALTER TABLE t NOCACHE`を使用してキャッシュされたテーブルを通常のテーブルに戻す必要があります。 +- パーティション化されたテーブルで`ALTER TABLE t ADD PARTITION`操作を実行することはサポートされていません。 +- 一時テーブルで`ALTER TABLE t CACHE`操作を実行することはサポートされていません。 +- ビューに対して`ALTER TABLE t CACHE`操作を実行することはサポートされていません。 +- ステイル読み取りはサポートされていません。 +- キャッシュされたテーブルへの直接DDL操作はサポートされていません。DDL操作を実行する前に、まず`ALTER TABLE t NOCACHE`を使用してキャッシュされたテーブルを通常のテーブルに戻す必要があります。 キャッシュされたテーブルは次のシナリオでは使用**できません**。 -- 履歴データを読み取るためにシステム変数`tidb_snapshot`を設定します。 -- 変更中は、データが再ロードされるまでキャッシュされたデータは無効になります。 +- 履歴データを読み取るためにシステム変数`tidb_snapshot`を設定します。 +- 変更中は、データが再ロードされるまでキャッシュされたデータは無効になります。 ## TiDB移行ツールとの互換性 {#compatibility-with-tidb-migration-tools} @@ -240,5 +240,5 @@ Query OK, 0 rows affected (0.00 sec) ## 参照 {#see-also} -- [ALTER TABLE](/sql-statements/sql-statement-alter-table.md) -- [システム変数](/system-variables.md) +- [ALTER TABLE](/sql-statements/sql-statement-alter-table.md) +- [システム変数](/system-variables.md) diff --git a/certificate-authentication.md b/certificate-authentication.md index 9254a88d0bb4e..c5121cd9446c3 100644 --- a/certificate-authentication.md +++ b/certificate-authentication.md @@ -9,10 +9,10 @@ TiDBは、ユーザーがTiDBにログインするための証明書ベースの 証明書ベースの認証を使用するには、次の操作を実行する必要がある場合があります。 -- セキュリティキーと証明書を作成する -- TiDBとクライアントの証明書を構成する -- ユーザーがログインするときに検証するユーザー証明書情報を設定します -- 証明書の更新と置き換え +- セキュリティキーと証明書を作成する +- TiDBとクライアントの証明書を構成する +- ユーザーがログインするときに検証するユーザー証明書情報を設定します +- 証明書の更新と置き換え ドキュメントの残りの部分では、これらの操作を実行する方法について詳しく説明します。 @@ -32,7 +32,7 @@ TiDBは、ユーザーがTiDBにログインするための証明書ベースの ### CAキーと証明書を生成する {#generate-ca-key-and-certificate} -1. CA キーを生成するには、次のコマンドを実行します。 +1. CA キーを生成するには、次のコマンドを実行します。 ```bash sudo openssl genrsa 2048 > ca-key.pem @@ -47,13 +47,13 @@ TiDBは、ユーザーがTiDBにログインするための証明書ベースの e is 65537 (0x010001) ``` -2. 次のコマンドを実行して、CA キーに対応する証明書を生成します。 +2. 次のコマンドを実行して、CA キーに対応する証明書を生成します。 ```bash sudo openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.pem ``` -3. 詳細な証明書情報を入力します。例： +3. 詳細な証明書情報を入力します。例： ```bash Country Name (2 letter code) [AU]:US @@ -71,13 +71,13 @@ TiDBは、ユーザーがTiDBにログインするための証明書ベースの ### サーバーキーと証明書を生成する {#generate-server-key-and-certificate} -1. 次のコマンドを実行してサーバーキーを生成します。 +1. 次のコマンドを実行してサーバーキーを生成します。 ```bash sudo openssl req -newkey rsa:2048 -days 365000 -nodes -keyout server-key.pem -out server-req.pem ``` -2. 詳細な証明書情報を入力します。例： +2. 詳細な証明書情報を入力します。例： ```bash Country Name (2 letter code) [AU]:US @@ -94,7 +94,7 @@ TiDBは、ユーザーがTiDBにログインするための証明書ベースの An optional company name []: ``` -3. サーバーの RSA キーを生成するには、次のコマンドを実行します。 +3. サーバーの RSA キーを生成するには、次のコマンドを実行します。 ```bash sudo openssl rsa -in server-key.pem -out server-key.pem @@ -106,7 +106,7 @@ TiDBは、ユーザーがTiDBにログインするための証明書ベースの writing RSA key ``` -4. CA 証明書の署名を使用して、署名されたサーバー証明書を生成します。 +4. CA 証明書の署名を使用して、署名されたサーバー証明書を生成します。 ```bash sudo openssl x509 -req -in server-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem @@ -128,13 +128,13 @@ TiDBは、ユーザーがTiDBにログインするための証明書ベースの サーバーの鍵と証明書を生成したら、クライアント用の鍵と証明書を生成する必要があります。多くの場合、ユーザーごとに異なる鍵と証明書を生成する必要があります。 -1. 次のコマンドを実行してクライアント キーを生成します。 +1. 次のコマンドを実行してクライアント キーを生成します。 ```bash sudo openssl req -newkey rsa:2048 -days 365000 -nodes -keyout client-key.pem -out client-req.pem ``` -2. 詳細な証明書情報を入力します。例： +2. 詳細な証明書情報を入力します。例： ```bash Country Name (2 letter code) [AU]:US @@ -151,7 +151,7 @@ TiDBは、ユーザーがTiDBにログインするための証明書ベースの An optional company name []: ``` -3. 次のコマンドを実行して、クライアントの RSA キーを生成します。 +3. 次のコマンドを実行して、クライアントの RSA キーを生成します。 ```bash sudo openssl rsa -in client-key.pem -out client-key.pem @@ -163,7 +163,7 @@ TiDBは、ユーザーがTiDBにログインするための証明書ベースの writing RSA key ``` -4. CA 証明書の署名を使用してクライアント証明書を生成します。 +4. CA 証明書の署名を使用してクライアント証明書を生成します。 ```bash sudo openssl x509 -req -in client-req.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.pem @@ -239,7 +239,7 @@ mysql -u test -h 0.0.0.0 -P 4000 --ssl-cert /path/to/client-cert.new.pem --ssl-k ユーザー証明書情報は、X.509 証明書属性の確認に使用される`REQUIRE SUBJECT` 、 `REQUIRE ISSUER` 、 `REQUIRE SAN` 、および`REQUIRE CIPHER`で指定できます。 -- `REQUIRE SUBJECT` : ログイン時のクライアント証明書のサブジェクト情報を指定します。このオプションを指定した場合、 `REQUIRE SSL`または`REQUIRE X509`を設定する必要はありません。指定する情報は、 [クライアントキーと証明書を生成する](#generate-client-key-and-certificate)で入力したサブジェクト情報と一致します。 +- `REQUIRE SUBJECT` : ログイン時のクライアント証明書のサブジェクト情報を指定します。このオプションを指定した場合、 `REQUIRE SSL`または`REQUIRE X509`を設定する必要はありません。指定する情報は、 [クライアントキーと証明書を生成する](#generate-client-key-and-certificate)で入力したサブジェクト情報と一致します。 このオプションを取得するには、次のコマンドを実行します。 @@ -247,7 +247,7 @@ mysql -u test -h 0.0.0.0 -P 4000 --ssl-cert /path/to/client-cert.new.pem --ssl-k openssl x509 -noout -subject -in client-cert.pem | sed 's/.\{8\}//' | sed 's/, /\//g' | sed 's/ = /=/g' | sed 's/^/\//' ``` -- `REQUIRE ISSUER` : ユーザー証明書を発行するCA証明書の`subject`情報を指定します。指定する情報は、 [CAキーと証明書を生成する](#generate-ca-key-and-certificate)で入力した`subject`情報と一致します。 +- `REQUIRE ISSUER` : ユーザー証明書を発行するCA証明書の`subject`情報を指定します。指定する情報は、 [CAキーと証明書を生成する](#generate-ca-key-and-certificate)で入力した`subject`情報と一致します。 このオプションを取得するには、次のコマンドを実行します。 @@ -255,21 +255,21 @@ mysql -u test -h 0.0.0.0 -P 4000 --ssl-cert /path/to/client-cert.new.pem --ssl-k openssl x509 -noout -subject -in ca-cert.pem | sed 's/.\{8\}//' | sed 's/, /\//g' | sed 's/ = /=/g' | sed 's/^/\//' ``` -- `REQUIRE SAN` : ユーザー証明書を発行するCA証明書の`Subject Alternative Name`情報を指定します。指定する情報は、クライアント証明書の生成に使用された[`openssl.cnf`設定ファイルの`alt_names`](https://docs.pingcap.com/tidb/stable/generate-self-signed-certificates)の情報と一致します。 +- `REQUIRE SAN` : ユーザー証明書を発行するCA証明書の`Subject Alternative Name`情報を指定します。指定する情報は、クライアント証明書の生成に使用された[`openssl.cnf`設定ファイルの`alt_names`](https://docs.pingcap.com/tidb/stable/generate-self-signed-certificates)の情報と一致します。 - - 生成された証明書の`REQUIRE SAN`項目の情報を取得するには、次のコマンドを実行します。 + - 生成された証明書の`REQUIRE SAN`項目の情報を取得するには、次のコマンドを実行します。 ```shell openssl x509 -noout -extensions subjectAltName -in client.crt ``` - - `REQUIRE SAN`現在、次の`Subject Alternative Name`チェック項目をサポートしています。 + - `REQUIRE SAN`現在、次の`Subject Alternative Name`チェック項目をサポートしています。 - - URI - - IP - - DNS + - URI + - IP + - DNS - - 複数のチェック項目は、カンマで区切って設定できます。例えば、ユーザー`u1`の場合は、 `REQUIRE SAN`以下のように設定します。 + - 複数のチェック項目は、カンマで区切って設定できます。例えば、ユーザー`u1`の場合は、 `REQUIRE SAN`以下のように設定します。 ```sql CREATE USER 'u1'@'%' REQUIRE SAN 'DNS:d1,URI:spiffe://example.org/myservice1,URI:spiffe://example.org/myservice2'; @@ -277,7 +277,7 @@ mysql -u test -h 0.0.0.0 -P 4000 --ssl-cert /path/to/client-cert.new.pem --ssl-k 上記の構成では、URI 項目`spiffe://example.org/myservice1`または`spiffe://example.org/myservice2`と DNS 項目`d1`を持つ証明書を使用して`u1`ユーザーのみが TiDB にログインできます。 -- `REQUIRE CIPHER` : クライアントがサポートする暗号方式をチェックします。サポートされている暗号方式のリストを確認するには、次のステートメントを使用します。 +- `REQUIRE CIPHER` : クライアントがサポートする暗号方式をチェックします。サポートされている暗号方式のリストを確認するには、次のステートメントを使用します。 ```sql SHOW SESSION STATUS LIKE 'Ssl_cipher_list'; @@ -289,13 +289,13 @@ mysql -u test -h 0.0.0.0 -P 4000 --ssl-cert /path/to/client-cert.new.pem --ssl-k スペースまたは`and`区切り文字として使用して、1 つのオプションまたは複数のオプションを設定できます。 -- ユーザー作成時にユーザー証明書を設定します（ `CREATE USER` ）： +- ユーザー作成時にユーザー証明書を設定します（ `CREATE USER` ）： ```sql CREATE USER 'u1'@'%' REQUIRE ISSUER '' SUBJECT '' SAN '' CIPHER ''; ``` -- ユーザーを変更するときにユーザー証明書を構成します。 +- ユーザーを変更するときにユーザー証明書を構成します。 ```sql ALTER USER 'u1'@'%' REQUIRE ISSUER '' SUBJECT '' SAN '' CIPHER ''; @@ -303,10 +303,10 @@ mysql -u test -h 0.0.0.0 -P 4000 --ssl-cert /path/to/client-cert.new.pem --ssl-k 上記の設定後、ログイン時に以下の項目が検証されます。 -- SSL が使用され、クライアント証明書を発行する CA はサーバーで構成された CA と一致しています。 -- クライアント証明書の`issuer`情報が`REQUIRE ISSUER`で指定された情報と一致します。 -- 接続に使用される暗号は、 `REQUIRE CIPHER`で指定された暗号と一致します。 -- クライアント証明書の`Subject Alternative Name`情報が`REQUIRE SAN`で指定された情報と一致します。 +- SSL が使用され、クライアント証明書を発行する CA はサーバーで構成された CA と一致しています。 +- クライアント証明書の`issuer`情報が`REQUIRE ISSUER`で指定された情報と一致します。 +- 接続に使用される暗号は、 `REQUIRE CIPHER`で指定された暗号と一致します。 +- クライアント証明書の`Subject Alternative Name`情報が`REQUIRE SAN`で指定された情報と一致します。 上記のすべての項目が検証された場合にのみ、TiDBにログインできます。検証されていない場合は、エラー`ERROR 1045 (28000): Access denied`が返されます。以下のコマンドを使用して、TLSバージョン、暗号アルゴリズム、および現在の接続でログインに証明書が使用されているかどうかを確認できます。 @@ -358,20 +358,20 @@ CA証明書は、クライアントとサーバー間の相互検証の基盤と ### CAキーと証明書を更新する {#update-ca-key-and-certificate} -1. 古い CA キーと証明書をバックアップします ( `ca-key.pem`が盗まれたと仮定)。 +1. 古い CA キーと証明書をバックアップします ( `ca-key.pem`が盗まれたと仮定)。 ```bash mv ca-key.pem ca-key.old.pem && \ mv ca-cert.pem ca-cert.old.pem ``` -2. 新しい CA キーを生成します。 +2. 新しい CA キーを生成します。 ```bash sudo openssl genrsa 2048 > ca-key.pem ``` -3. 新しく生成された CA キーを使用して新しい CA 証明書を生成します。 +3. 新しく生成された CA キーを使用して新しい CA 証明書を生成します。 ```bash sudo openssl req -new -x509 -nodes -days 365000 -key ca-key.pem -out ca-cert.new.pem @@ -381,7 +381,7 @@ CA証明書は、クライアントとサーバー間の相互検証の基盤と > > 新しいCA証明書を生成することは、クライアントとサーバーの鍵と証明書を置き換え、オンラインユーザーに影響を与えないようにするためです。したがって、上記のコマンドに追加される情報は、 `REQUIRE ISSUER`情報と一致している必要があります。 -4. 結合された CA 証明書を生成します。 +4. 結合された CA 証明書を生成します。 ```bash cat ca-cert.new.pem ca-cert.old.pem > ca-cert.pem @@ -397,7 +397,7 @@ CA証明書は、クライアントとサーバー間の相互検証の基盤と > > クライアントとサーバーの古い CA 証明書を結合された CA 証明書に置き換えた**後にのみ、**以下の手順を実行してください。 -1. クライアントの新しい RSA キーを生成します。 +1. クライアントの新しい RSA キーを生成します。 ```bash sudo openssl req -newkey rsa:2048 -days 365000 -nodes -keyout client-key.new.pem -out client-req.new.pem && \ @@ -408,13 +408,13 @@ CA証明書は、クライアントとサーバー間の相互検証の基盤と > > 上記のコマンドは、クライアントの鍵と証明書を置き換え、オンラインユーザーに影響を与えないようにするためのものです。そのため、上記のコマンドに追加される情報は、 `REQUIRE SUBJECT`情報と一致している必要があります。 -2. 結合された証明書と新しい CA キーを使用して、新しいクライアント証明書を生成します。 +2. 結合された証明書と新しい CA キーを使用して、新しいクライアント証明書を生成します。 ```bash sudo openssl x509 -req -in client-req.new.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out client-cert.new.pem ``` -3. 新しいクライアント キーと証明書を使用して、クライアント (MySQL など) を TiDB に接続します。 +3. 新しいクライアント キーと証明書を使用して、クライアント (MySQL など) を TiDB に接続します。 ```bash mysql -u test -h 0.0.0.0 -P 4000 --ssl-cert /path/to/client-cert.new.pem --ssl-key /path/to/client-key.new.pem --ssl-ca /path/to/ca-cert.pem @@ -426,20 +426,20 @@ CA証明書は、クライアントとサーバー間の相互検証の基盤と ### サーバーのキーと証明書を更新する {#update-the-server-key-and-certificate} -1. サーバーの新しい RSA キーを生成します: +1. サーバーの新しい RSA キーを生成します: ```bash sudo openssl req -newkey rsa:2048 -days 365000 -nodes -keyout server-key.new.pem -out server-req.new.pem && \ sudo openssl rsa -in server-key.new.pem -out server-key.new.pem ``` -2. 結合された CA 証明書と新しい CA キーを使用して、新しいサーバー証明書を生成します。 +2. 結合された CA 証明書と新しい CA キーを使用して、新しいサーバー証明書を生成します。 ```bash sudo openssl x509 -req -in server-req.new.pem -days 365000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.new.pem ``` -3. 新しいサーバーキーと証明書を使用するようにTiDBサーバーを設定します。ファイルを[サーバー証明書を使用するように TiDB を構成する](#configure-tidb-to-use-server-certificate)セクションで指定したディレクトリに配置します。 +3. 新しいサーバーキーと証明書を使用するようにTiDBサーバーを設定します。ファイルを[サーバー証明書を使用するように TiDB を構成する](#configure-tidb-to-use-server-certificate)セクションで指定したディレクトリに配置します。 ```sql ALTER INSTANCE RELOAD TLS; diff --git a/character-set-and-collation.md b/character-set-and-collation.md index adad2ac41df21..a68235faac27a 100644 --- a/character-set-and-collation.md +++ b/character-set-and-collation.md @@ -148,8 +148,8 @@ SHOW COLLATION; > > ただし、TiDB のデフォルトの照合順序は、クライアントの[接続照合順序](https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html#charset-connection-system-variables)設定にも影響されます。例えば、MySQL 8.x クライアントでは、 `utf8mb4`文字セットの接続照合順序はデフォルトで`utf8mb4_0900_ai_ci`に設定されています。 > -> - TiDB v7.4.0 より前では、クライアントが`utf8mb4_0900_ai_ci` [接続照合順序](https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html#charset-connection-system-variables)として使用すると、TiDB は`utf8mb4_0900_ai_ci`照合順序をサポートしていないため、TiDB は TiDBサーバーのデフォルトの照合照合順序`utf8mb4_bin`を使用します。 -> - v7.4.0 以降、クライアントが[接続照合順序](https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html#charset-connection-system-variables)として`utf8mb4_0900_ai_ci`を使用する場合、TiDB はクライアントの構成に従って、デフォルトの照合順序として`utf8mb4_0900_ai_ci`を使用します。 +> - TiDB v7.4.0 より前では、クライアントが`utf8mb4_0900_ai_ci` [接続照合順序](https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html#charset-connection-system-variables)として使用すると、TiDB は`utf8mb4_0900_ai_ci`照合順序をサポートしていないため、TiDB は TiDBサーバーのデフォルトの照合照合順序`utf8mb4_bin`を使用します。 +> - v7.4.0 以降、クライアントが[接続照合順序](https://dev.mysql.com/doc/refman/8.0/en/charset-connection.html#charset-connection-system-variables)として`utf8mb4_0900_ai_ci`を使用する場合、TiDB はクライアントの構成に従って、デフォルトの照合順序として`utf8mb4_0900_ai_ci`を使用します。 次のステートメントを使用すると、文字セットに対応する照合順序 ( [照合のための新しいフレームワーク](#new-framework-for-collations)下) を表示できます。 @@ -386,15 +386,15 @@ SELECT _utf8mb4'string' COLLATE utf8mb4_general_ci; ルール: -- ルール 1: `CHARACTER SET charset_name`と`COLLATE collation_name`を指定すると、 `charset_name`文字セットと`collation_name`照合順序が直接使用されます。 -- ルール 2: `CHARACTER SET charset_name`を指定して`COLLATE collation_name`を指定しない場合は、 `charset_name`文字セットとデフォルトの照合順序`charset_name`が使用されます。 -- ルール 3: `CHARACTER SET charset_name`も`COLLATE collation_name`を指定しない場合は、システム変数`character_set_connection`と`collation_connection`で指定された文字セットと照合順序が使用されます。 +- ルール 1: `CHARACTER SET charset_name`と`COLLATE collation_name`を指定すると、 `charset_name`文字セットと`collation_name`照合順序が直接使用されます。 +- ルール 2: `CHARACTER SET charset_name`を指定して`COLLATE collation_name`を指定しない場合は、 `charset_name`文字セットとデフォルトの照合順序`charset_name`が使用されます。 +- ルール 3: `CHARACTER SET charset_name`も`COLLATE collation_name`を指定しない場合は、システム変数`character_set_connection`と`collation_connection`で指定された文字セットと照合順序が使用されます。 ### クライアント接続の文字セットと照合順序 {#client-connection-character-set-and-collation} -- サーバーの文字セットと照合順序は、システム変数`character_set_server`と`collation_server`の値です。 +- サーバーの文字セットと照合順序は、システム変数`character_set_server`と`collation_server`の値です。 -- デフォルト データベースの文字セットと照合順序は、システム変数`character_set_database`と`collation_database`の値です。 +- デフォルト データベースの文字セットと照合順序は、システム変数`character_set_database`と`collation_database`の値です。 `character_set_connection`と`collation_connection`を使用して、各接続の文字セットと照合順序を指定するために使用できます。`character_set_client`は、クライアントの文字セットを設定するための変数です。 @@ -402,7 +402,7 @@ SELECT _utf8mb4'string' COLLATE utf8mb4_general_ci; 次のステートメントを使用して、クライアントに関連する文字セットと照合順序を設定できます。 -- `SET NAMES 'charset_name' [COLLATE 'collation_name']` +- `SET NAMES 'charset_name' [COLLATE 'collation_name']` `SET NAMES`は、クライアントがサーバーに SQL ステートメントを送信するために使用する文字セットを示します。`SET NAMES utf8mb4`は、クライアントからのすべてのリクエストとサーバーからの結果に utf8mb4 が使用されることを示します。 @@ -416,7 +416,7 @@ SELECT _utf8mb4'string' COLLATE utf8mb4_general_ci; `COLLATE`はオプションです。指定しない場合は、デフォルトの照合順序`charset_name`を使用して`collation_connection`が設定されます。 -- `SET CHARACTER SET 'charset_name'` +- `SET CHARACTER SET 'charset_name'` `SET NAMES`と同様に、 `SET NAMES 'charset_name'`ステートメントは次のステートメントの組み合わせと同等です。 @@ -433,9 +433,9 @@ SELECT _utf8mb4'string' COLLATE utf8mb4_general_ci; ## 文字セットと照合順序の選択に関する一般的なルール {#general-rules-on-selecting-character-sets-and-collation} -- ルール 1: `CHARACTER SET charset_name`と`COLLATE collation_name`を指定すると、 `charset_name`文字セットと`collation_name`照合順序が直接使用されます。 -- ルール 2: `CHARACTER SET charset_name`を指定し、 `COLLATE collation_name`を指定しない場合は、 `charset_name`文字セットとデフォルトの照合順序`charset_name`が使用されます。 -- ルール 3: `CHARACTER SET charset_name`も`COLLATE collation_name`も指定しない場合は、最適化レベルが高い文字セットと照合順序が使用されます。 +- ルール 1: `CHARACTER SET charset_name`と`COLLATE collation_name`を指定すると、 `charset_name`文字セットと`collation_name`照合順序が直接使用されます。 +- ルール 2: `CHARACTER SET charset_name`を指定し、 `COLLATE collation_name`を指定しない場合は、 `charset_name`文字セットとデフォルトの照合順序`charset_name`が使用されます。 +- ルール 3: `CHARACTER SET charset_name`も`COLLATE collation_name`も指定しない場合は、最適化レベルが高い文字セットと照合順序が使用されます。 ## 文字の有効性チェック {#validity-check-of-characters} @@ -578,13 +578,13 @@ ERROR 1062 (23000): Duplicate entry 'a ' for key 't.PRIMARY' -- TiDB modifies th 式に異なる照合順序を持つ複数の節が含まれる場合、計算で使用される照合順序を推測する必要があります。そのルールは以下のとおりです。 -- 明示的な`COLLATE`句の強制可能性値は`0`です。 -- 2 つの文字列の照合順序に互換性がない場合は、異なる照合順序を持つ 2 つの文字列の連結の強制可能性値は`1`なります。 -- 列の照合順序`CAST()` 、 `CONVERT()` 、または`BINARY()`の強制値は`2`です。 -- システム定数 ( `USER ()`または`VERSION ()`によって返される文字列) の強制値は`3`です。 -- 定数の強制値は`4`です。 -- 数値または中間変数の強制値は`5`です。 -- `NULL`または`NULL`から派生した式の強制値は`6`です。 +- 明示的な`COLLATE`句の強制可能性値は`0`です。 +- 2 つの文字列の照合順序に互換性がない場合は、異なる照合順序を持つ 2 つの文字列の連結の強制可能性値は`1`なります。 +- 列の照合順序`CAST()` 、 `CONVERT()` 、または`BINARY()`の強制値は`2`です。 +- システム定数 ( `USER ()`または`VERSION ()`によって返される文字列) の強制値は`3`です。 +- 定数の強制値は`4`です。 +- 数値または中間変数の強制値は`5`です。 +- `NULL`または`NULL`から派生した式の強制値は`6`です。 TiDBは照合順序を推論する際に、強制性値の低い式の照合順序を優先的に使用します。2つの句の強制性値が同じ場合、以下の優先順位に従って照合順序が決定されます。 @@ -592,8 +592,8 @@ TiDBは照合順序を推論する際に、強制性値の低い式の照合順 次の状況では、TiDB は照合順序を推測できず、エラーを報告します。 -- 2 つの句の照合順序が異なり、両方の句の強制可能性値が`0`の場合。 -- 2 つの句の照合順序に互換性がなく、返される式の型が`String`の場合。 +- 2 つの句の照合順序が異なり、両方の句の強制可能性値が`0`の場合。 +- 2 つの句の照合順序に互換性がなく、返される式の型が`String`の場合。 ## `COLLATE`句 {#collate-clause} diff --git a/character-set-gbk.md b/character-set-gbk.md index 44f1b0098a5d7..088ff3c6ff9d5 100644 --- a/character-set-gbk.md +++ b/character-set-gbk.md @@ -46,8 +46,8 @@ SHOW COLLATION WHERE CHARSET = 'gbk'; MySQLにおけるGBK文字セットのデフォルトの照合照合順序は`gbk_chinese_ci`です。TiDBにおけるGBK文字セットのデフォルトの照合照合順序は、TiDB設定項目[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)の値によって異なります。 -- デフォルトでは、 TiDB 構成項目[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)は`true`に設定されています。つまり、 [照合のための新しいフレームワーク](/character-set-and-collation.md#new-framework-for-collations)が有効になっており、 GBK 文字セットのデフォルトの照合照合順序は`gbk_chinese_ci`です。 -- TiDB 構成項目[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap) `false`に設定されている場合、 [照合のための新しいフレームワーク](/character-set-and-collation.md#new-framework-for-collations)は無効になり、 GBK 文字セットのデフォルトの照合順序は`gbk_bin`になります。 +- デフォルトでは、 TiDB 構成項目[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)は`true`に設定されています。つまり、 [照合のための新しいフレームワーク](/character-set-and-collation.md#new-framework-for-collations)が有効になっており、 GBK 文字セットのデフォルトの照合照合順序は`gbk_chinese_ci`です。 +- TiDB 構成項目[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap) `false`に設定されている場合、 [照合のための新しいフレームワーク](/character-set-and-collation.md#new-framework-for-collations)は無効になり、 GBK 文字セットのデフォルトの照合順序は`gbk_bin`になります。 @@ -61,11 +61,11 @@ MySQLにおけるGBK文字セットのデフォルトの照合照合順序は`gb ### 無効な文字互換性 {#invalid-character-compatibility} -- システム変数[`character_set_client`](/system-variables.md#character_set_client)と[`character_set_connection`](/system-variables.md#character_set_connection)同時に`gbk`に設定されていない場合、TiDB は MySQL と同じ方法で無効な文字を処理します。 -- `character_set_client`と`character_set_connection`両方が`gbk`に設定されている場合、TiDB は無効な文字を MySQL とは異なる方法で処理します。 +- システム変数[`character_set_client`](/system-variables.md#character_set_client)と[`character_set_connection`](/system-variables.md#character_set_connection)同時に`gbk`に設定されていない場合、TiDB は MySQL と同じ方法で無効な文字を処理します。 +- `character_set_client`と`character_set_connection`両方が`gbk`に設定されている場合、TiDB は無効な文字を MySQL とは異なる方法で処理します。 - - MySQL は、読み取り操作と書き込み操作で無効な GBK 文字セットを異なる方法で処理します。 - - TiDBは、読み取り操作と書き込み操作の両方において、無効なGBK文字セットを同じ方法で処理します。SQL厳密モードでは、無効なGBK文字の読み取りまたは書き込み時にエラーが報告されます。非厳密モードでは、無効なGBK文字の読み取りまたは書き込み時に、TiDBは無効なGBK文字を`?`に置き換えます。 + - MySQL は、読み取り操作と書き込み操作で無効な GBK 文字セットを異なる方法で処理します。 + - TiDBは、読み取り操作と書き込み操作の両方において、無効なGBK文字セットを同じ方法で処理します。SQL厳密モードでは、無効なGBK文字の読み取りまたは書き込み時にエラーが報告されます。非厳密モードでは、無効なGBK文字の読み取りまたは書き込み時に、TiDBは無効なGBK文字を`?`に置き換えます。 例えば、 `SET NAMES gbk`後、 MySQL と TiDB でそれぞれ`CREATE TABLE gbk_table(a VARCHAR(32) CHARACTER SET gbk)`ステートメントを使用してテーブルを作成し、次の表の SQL ステートメントを実行すると、詳細な違いを確認できます。 @@ -78,11 +78,11 @@ MySQLにおけるGBK文字セットのデフォルトの照合照合順序は`gb ### その他のMySQL互換性 {#other-mysql-compatibility} -- 現在、TiDB は、 `ALTER TABLE`ステートメントを使用して他の文字セット タイプを`gbk`に変換したり、 `gbk`を他の文字セット タイプに変換したりすることはサポートしていません。 +- 現在、TiDB は、 `ALTER TABLE`ステートメントを使用して他の文字セット タイプを`gbk`に変換したり、 `gbk`を他の文字セット タイプに変換したりすることはサポートしていません。 -- TiDBは`_gbk`の使用をサポートしていません。例: +- TiDBは`_gbk`の使用をサポートしていません。例: ```sql CREATE TABLE t(a CHAR(10) CHARSET BINARY); @@ -96,21 +96,21 @@ MySQLにおけるGBK文字セットのデフォルトの照合照合順序は`gb -- 現在、 `ENUM`および`SET`タイプのバイナリ文字については、TiDB は`utf8mb4`文字セットとして処理します。 +- 現在、 `ENUM`および`SET`タイプのバイナリ文字については、TiDB は`utf8mb4`文字セットとして処理します。 ## コンポーネントの互換性 {#component-compatibility} -- 現在、 TiFlash はGBK 文字セットをサポートしていません。 +- 現在、 TiFlash はGBK 文字セットをサポートしていません。 -- TiDB Data Migration (DM) では、 `charset=GBK`テーブルを v5.4.0 より前の TiDB クラスターに移行することはサポートされていません。 +- TiDB Data Migration (DM) では、 `charset=GBK`テーブルを v5.4.0 より前の TiDB クラスターに移行することはサポートされていません。 -- TiDB Lightning は、v5.4.0 より前の TiDB クラスターへの`charset=GBK`テーブルのインポートをサポートしていません。 +- TiDB Lightning は、v5.4.0 より前の TiDB クラスターへの`charset=GBK`テーブルのインポートをサポートしていません。 -- TiCDC v6.1.0より前のバージョンでは、 `charset=GBK`テーブルのレプリケーションはサポートされていません。v6.1.0より前のバージョンのTiCDCでは、TiDBクラスターへの`charset=GBK`テーブルのレプリケーションはサポートされていません。 +- TiCDC v6.1.0より前のバージョンでは、 `charset=GBK`テーブルのレプリケーションはサポートされていません。v6.1.0より前のバージョンのTiCDCでは、TiDBクラスターへの`charset=GBK`テーブルのレプリケーションはサポートされていません。 -- バックアップ＆リストア（BR）バージョン5.4.0より前のバージョンでは、 `charset=GBK`テーブルのリカバリはサポートされていません。また、 BRのバージョン5.4.0より前のバージョンでは、TiDBクラスターへの`charset=GBK`テーブルのリカバリはサポートされていません。 +- バックアップ＆リストア（BR）バージョン5.4.0より前のバージョンでは、 `charset=GBK`テーブルのリカバリはサポートされていません。また、 BRのバージョン5.4.0より前のバージョンでは、TiDBクラスターへの`charset=GBK`テーブルのリカバリはサポートされていません。 ## 参照 {#see-also} -- [`SHOW CHARACTER SET`](/sql-statements/sql-statement-show-character-set.md) -- [文字セットと照合順序](/character-set-and-collation.md) +- [`SHOW CHARACTER SET`](/sql-statements/sql-statement-show-character-set.md) +- [文字セットと照合順序](/character-set-and-collation.md) diff --git a/check-before-deployment.md b/check-before-deployment.md index c5b46cb4c860a..d8a4024c33f5a 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -21,7 +21,7 @@ summary: TiDB をデプロイする前に環境チェック操作について学 `/dev/nvme0n1`データ ディスクを例に挙げます。 -1. データ ディスクを表示する。 +1. データ ディスクを表示する。 ```bash fdisk -l @@ -31,7 +31,7 @@ summary: TiDB をデプロイする前に環境チェック操作について学 Disk /dev/nvme0n1: 1000 GB ``` -2. パーティションを作成します。 +2. パーティションを作成します。 ```bash parted -s -a optimal /dev/nvme0n1 mklabel gpt -- mkpart primary ext4 1 -1 @@ -48,13 +48,13 @@ summary: TiDB をデプロイする前に環境チェック操作について学 > > パーティションのデバイス番号を表示するには、 `lsblk`コマンドを使用します。NVMe ディスクの場合、生成されるデバイス番号は通常`nvme0n1p1`です。通常のディスク (たとえば、 `/dev/sdb` ) の場合、生成されるデバイス番号は通常`sdb1`です。 -3. データ ディスクを ext4 ファイルシステムにフォーマットします。 +3. データ ディスクを ext4 ファイルシステムにフォーマットします。 ```bash mkfs.ext4 /dev/nvme0n1p1 ``` -4. データ ディスクのパーティション UUIDを表示する。 +4. データ ディスクのパーティション UUIDを表示する。 この例では、nvme0n1p1 の UUID は`c51eb23b-195c-4061-92a9-3fad812cc12f`です。 @@ -73,7 +73,7 @@ summary: TiDB をデプロイする前に環境チェック操作について学 └─nvme0n1p1 ext4 c51eb23b-195c-4061-92a9-3fad812cc12f ``` -5. `/etc/fstab`ファイルを編集し、 `nodelalloc`マウント オプションを追加します。 +5. `/etc/fstab`ファイルを編集し、 `nodelalloc`マウント オプションを追加します。 ```bash vi /etc/fstab @@ -83,7 +83,7 @@ summary: TiDB をデプロイする前に環境チェック操作について学 UUID=c51eb23b-195c-4061-92a9-3fad812cc12f /data1 ext4 defaults,nodelalloc,noatime 0 2 ``` -6. データ ディスクをマウントします。 +6. データ ディスクをマウントします。 ```bash mkdir /data1 && \ @@ -91,7 +91,7 @@ summary: TiDB をデプロイする前に環境チェック操作について学 mount -a ``` -7. 次のコマンドを使用して確認します。 +7. 次のコマンドを使用して確認します。 ```bash mount -t ext4 @@ -107,10 +107,10 @@ summary: TiDB をデプロイする前に環境チェック操作について学 TiDB は動作に十分な量のメモリを必要とします。TiDB が使用するメモリがスワップアウトされ、その後スワップインされると、レイテンシーの急上昇が発生する可能性があります。安定したパフォーマンスを維持したい場合は、システムスワップを恒久的に無効化することをお勧めしますが、メモリ不足時に OOM 問題が発生する可能性があります。このような OOM 問題を回避したい場合は、恒久的に無効化するのではなく、スワップ優先度を下げるだけで済みます。 -- スワップを有効化して使用すると、パフォーマンスのジッター問題が発生する可能性があります。低レイテンシかつ安定性が重要なデータベースサービスでは、オペレーティングシステム層のスワップを恒久的に無効化することをお勧めします。スワップを恒久的に無効化するには、以下の方法があります。 +- スワップを有効化して使用すると、パフォーマンスのジッター問題が発生する可能性があります。低レイテンシかつ安定性が重要なデータベースサービスでは、オペレーティングシステム層のスワップを恒久的に無効化することをお勧めします。スワップを恒久的に無効化するには、以下の方法があります。 - - オペレーティング システムの初期化フェーズでは、スワップ パーティション ディスクを個別にパーティション分割しないでください。 - - オペレーティング システムの初期化フェーズ中に既に別のスワップ パーティション ディスクをパーティション分割し、スワップを有効にしている場合は、次のコマンドを実行してスワップを無効にします。 + - オペレーティング システムの初期化フェーズでは、スワップ パーティション ディスクを個別にパーティション分割しないでください。 + - オペレーティング システムの初期化フェーズ中に既に別のスワップ パーティション ディスクをパーティション分割し、スワップを有効にしている場合は、次のコマンドを実行してスワップを無効にします。 ```bash echo "vm.swappiness = 0">> /etc/sysctl.conf @@ -118,7 +118,7 @@ TiDB は動作に十分な量のメモリを必要とします。TiDB が使用 swapoff -a && swapon -a ``` -- ホストメモリが不足している場合、システムスワップを無効にするとOOM問題が発生する可能性が高くなります。スワップを永続的に無効にする代わりに、次のコマンドを実行してスワップ優先度を下げることができます。 +- ホストメモリが不足している場合、システムスワップを無効にするとOOM問題が発生する可能性が高くなります。スワップを永続的に無効にする代わりに、次のコマンドを実行してスワップ優先度を下げることができます。 ```bash echo "vm.swappiness = 0">> /etc/sysctl.conf @@ -129,11 +129,11 @@ TiDB は動作に十分な量のメモリを必要とします。TiDB が使用 TiDBの一部の操作では、サーバーへの一時ファイルの書き込みが必要となるため、TiDBを実行するオペレーティングシステムユーザーに、対象ディレクトリへの読み書き権限が十分にあることを確認する必要があります。TiDBインスタンスを`root`権限で起動していない場合は、ディレクトリの権限を確認し、正しく設定する必要があります。 -- TiDB作業領域 +- TiDB作業領域 ハッシュテーブルの構築やソートなど、大量のメモリを消費する操作では、メモリ消費量を削減し、安定性を向上させるために、一時データをディスクに書き込むことがあります。書き込み先のディスク上の場所は、設定項目[`tmp-storage-path`](/tidb-configuration-file.md#tmp-storage-path)で定義されます。デフォルト設定では、TiDBを実行するユーザーに、オペレーティングシステムの一時フォルダ（通常は`/tmp` ）への読み取りおよび書き込み権限があることを確認してください。 -- `Fast Online DDL`作業領域 +- `Fast Online DDL`作業領域 変数[`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) `ON` (v6.5.0 以降のバージョンではデフォルト値) に設定されている場合、 `Fast Online DDL`が有効になり、一部の DDL 操作ではファイルシステム内の一時ファイルの読み取りと書き込みが必要になります。場所は設定項目[`temp-dir`](/tidb-configuration-file.md#temp-dir-new-in-v630)で定義されます。TiDB を実行するユーザーが、オペレーティングシステムのそのディレクトリに対する読み取りおよび書き込み権限を持っていることを確認する必要があります。デフォルトのディレクトリ`/tmp/tidb`は tmpfs (一時ファイルシステム) を使用します。ディスクディレクトリを明示的に指定することをお勧めします。以下は`/data/tidb-deploy/tempdir`例として使用しています。 @@ -163,26 +163,26 @@ TiDBクラスターでは、読み取り・書き込みリクエストやデー このセクションでは、ターゲット マシンのファイアウォール サービスを停止および無効にする方法について説明します。 -1. ファイアウォールの状態を確認してください。以下の例では、CentOS Linuxリリース7.7.1908（Core）を使用しています。 +1. ファイアウォールの状態を確認してください。以下の例では、CentOS Linuxリリース7.7.1908（Core）を使用しています。 ```shell sudo firewall-cmd --state sudo systemctl status firewalld.service ``` -2. ファイアウォール サービスを停止します。 +2. ファイアウォール サービスを停止します。 ```bash sudo systemctl stop firewalld.service ``` -3. ファイアウォール サービスの自動起動を無効にします。 +3. ファイアウォール サービスの自動起動を無効にします。 ```bash sudo systemctl disable firewalld.service ``` -4. ファイアウォールのステータスを確認します。 +4. ファイアウォールのステータスを確認します。 ```bash sudo systemctl status firewalld.service @@ -283,7 +283,7 @@ TiDB は、 ACIDモデルにおけるトランザクションの線形一貫性 NTP サービスがインストールされ、NTPサーバーと正常に同期しているかどうかを確認するには、次の手順を実行します。 -1. 次のコマンドを実行します。`running`が返された場合、NTPサービスは実行中です。 +1. 次のコマンドを実行します。`running`が返された場合、NTPサービスは実行中です。 ```bash sudo systemctl status ntpd.service @@ -295,7 +295,7 @@ NTP サービスがインストールされ、NTPサーバーと正常に同期 Active: active (running) since 一 2017-12-18 13:13:19 CST; 3s ago ``` - - `Unit ntpd.service could not be found.`が返された場合は、次のコマンドを試して、システムが NTP とのクロック同期を実行するために`ntpd`ではなく`chronyd`を使用するように設定されているかどうかを確認します。 + - `Unit ntpd.service could not be found.`が返された場合は、次のコマンドを試して、システムが NTP とのクロック同期を実行するために`ntpd`ではなく`chronyd`を使用するように設定されているかどうかを確認します。 ```bash sudo systemctl status chronyd.service @@ -311,7 +311,7 @@ NTP サービスがインストールされ、NTPサーバーと正常に同期 システムが`chronyd`を使用するように構成されている場合は、手順 3 に進みます。 -2. `ntpstat`コマンドを実行して、NTP サービスが NTPサーバーと同期しているかどうかを確認します。 +2. `ntpstat`コマンドを実行して、NTP サービスが NTPサーバーと同期しているかどうかを確認します。 > **Note:** > @@ -321,7 +321,7 @@ NTP サービスがインストールされ、NTPサーバーと正常に同期 ntpstat ``` - - `synchronised to NTP server` (NTPサーバーと同期中) を返す場合、同期プロセスは正常です。 + - `synchronised to NTP server` (NTPサーバーと同期中) を返す場合、同期プロセスは正常です。 ``` synchronised to NTP server (85.199.214.101) at stratum 2 @@ -329,19 +329,19 @@ NTP サービスがインストールされ、NTPサーバーと正常に同期 polling server every 1024 s ``` - - 次の状況は、NTP サービスが正常に同期していないことを示しています。 + - 次の状況は、NTP サービスが正常に同期していないことを示しています。 ``` unsynchronised ``` - - 次の状況は、NTP サービスが正常に実行されていないことを示しています。 + - 次の状況は、NTP サービスが正常に実行されていないことを示しています。 ``` Unable to talk to NTP daemon. Is it running? ``` -3. `chronyc tracking`コマンドを実行して、Chrony サービスが NTPサーバーと同期しているかどうかを確認します。 +3. `chronyc tracking`コマンドを実行して、Chrony サービスが NTPサーバーと同期しているかどうかを確認します。 > **Note:** > @@ -351,7 +351,7 @@ NTP サービスがインストールされ、NTPサーバーと正常に同期 chronyc tracking ``` - - コマンドが`Leap status : Normal`を返す場合、同期プロセスは正常です。 + - コマンドが`Leap status : Normal`を返す場合、同期プロセスは正常です。 ``` Reference ID : 5EC69F0A (ntp1.time.nl) @@ -369,19 +369,19 @@ NTP サービスがインストールされ、NTPサーバーと正常に同期 Leap status : Normal ``` - - コマンドが次の結果を返す場合、同期でエラーが発生しています。 + - コマンドが次の結果を返す場合、同期でエラーが発生しています。 ``` Leap status : Not synchronised ``` - - コマンドが次の結果を返す場合、 `chronyd`サービスは正常に実行されていません。 + - コマンドが次の結果を返す場合、 `chronyd`サービスは正常に実行されていません。 ``` 506 Cannot talk to daemon ``` - - オフセットが大きすぎると思われる場合は、コマンド`chronyc makestep`を実行してすぐに時間オフセットを修正できます。そうでない場合は、 `chronyd`を実行して徐々に時間オフセットを修正します。 + - オフセットが大きすぎると思われる場合は、コマンド`chronyc makestep`を実行してすぐに時間オフセットを修正できます。そうでない場合は、 `chronyd`を実行して徐々に時間オフセットを修正します。 NTPサービスの同期をできるだけ早く開始するには、次のコマンドを実行してください。`pool.ntp.org`をNTPサーバーに置き換えてください。 @@ -403,18 +403,18 @@ sudo systemctl enable ntpd.service 本番環境の TiDB の場合、次の方法でオペレーティング システム構成を最適化することをお勧めします。 -- [透過的巨大ページ（THP）](/tune-operating-system.md#memorytransparent-huge-page-thp)を無効にします。データベースのメモリアクセスは通常、スパースです。高位メモリが著しく断片化されると、THP によるメモリ割り当てのレイテンシーが増大する可能性があります。したがって、パフォーマンスの変動を避けるため、THP を無効にすることをお勧めします。 +- [透過的巨大ページ（THP）](/tune-operating-system.md#memorytransparent-huge-page-thp)を無効にします。データベースのメモリアクセスは通常、スパースです。高位メモリが著しく断片化されると、THP によるメモリ割り当てのレイテンシーが増大する可能性があります。したがって、パフォーマンスの変動を避けるため、THP を無効にすることをお勧めします。 -- ストレージ媒体の[I/Oスケジューラ](/tune-operating-system.md#io-scheduler)を設定します。 +- ストレージ媒体の[I/Oスケジューラ](/tune-operating-system.md#io-scheduler)を設定します。 - - 高速SSDストレージの場合、カーネルのデフォルトのI/Oスケジューリング操作によってパフォーマンスが低下する可能性があります。 I/Oスケジューラを`noop`や`none`などの先入先出（FIFO）に設定することをお勧めします。この設定により、カーネルはI/Oリクエストをスケジューリングなしで直接ハードウェアに渡すことができるため、パフォーマンスが向上します。 - - NVMeストレージの場合、デフォルトのI/Oスケジューラは`none`なので、調整は必要ありません。 + - 高速SSDストレージの場合、カーネルのデフォルトのI/Oスケジューリング操作によってパフォーマンスが低下する可能性があります。 I/Oスケジューラを`noop`や`none`などの先入先出（FIFO）に設定することをお勧めします。この設定により、カーネルはI/Oリクエストをスケジューリングなしで直接ハードウェアに渡すことができるため、パフォーマンスが向上します。 + - NVMeストレージの場合、デフォルトのI/Oスケジューラは`none`なので、調整は必要ありません。 -- CPU周波数を動的に制御する[cpufreqモジュール](/tune-operating-system.md#cpufrequency-scaling)の`performance`モードを選択します。CPU周波数を動的な調整なしでサポートされている最高動作周波数に固定すると、パフォーマンスが最大限に発揮されます。 +- CPU周波数を動的に制御する[cpufreqモジュール](/tune-operating-system.md#cpufrequency-scaling)の`performance`モードを選択します。CPU周波数を動的な調整なしでサポートされている最高動作周波数に固定すると、パフォーマンスが最大限に発揮されます。 これらのパラメータを確認して構成する手順は次のとおりです。 -1. THP が有効か無効かを確認するには、次のコマンドを実行します。 +1. THP が有効か無効かを確認するには、次のコマンドを実行します。 ```bash cat /sys/kernel/mm/transparent_hugepage/enabled @@ -428,7 +428,7 @@ sudo systemctl enable ntpd.service > > `[always] madvise never`が出力された場合、THP が有効になっています。無効にする必要があります。 -2. 次のコマンドを実行して、データ ディレクトリが配置されているディスクのI/O Scheduler を確認します。 +2. 次のコマンドを実行して、データ ディレクトリが配置されているディスクのI/O Scheduler を確認します。 データ ディレクトリで SD または VD デバイスを使用している場合は、次のコマンドを実行してI/Oスケジューラを確認します。 @@ -460,7 +460,7 @@ sudo systemctl enable ntpd.service > > `[none] mq-deadline kyber bfq`は、NVMe デバイスが`none` I/Oスケジューラを使用しており、変更の必要がないことを示します。 -3. ディスクの`ID_SERIAL`を確認するには、次のコマンドを実行します。 +3. ディスクの`ID_SERIAL`を確認するには、次のコマンドを実行します。 ```bash udevadm info --name=/dev/sdb | grep ID_SERIAL @@ -473,10 +473,10 @@ sudo systemctl enable ntpd.service > **Note:** > - > - 複数のディスクにデータ ディレクトリが割り当てられている場合は、各ディスクの`ID_SERIAL`を記録するために、各ディスクに対して上記のコマンドを実行する必要があります。 - > - デバイスが`noop`または`none`スケジューラを使用している場合は、 `ID_SERIAL`を記録したり、udev ルールや調整されたプロファイルを構成したりする必要はありません。 + > - 複数のディスクにデータ ディレクトリが割り当てられている場合は、各ディスクの`ID_SERIAL`を記録するために、各ディスクに対して上記のコマンドを実行する必要があります。 + > - デバイスが`noop`または`none`スケジューラを使用している場合は、 `ID_SERIAL`を記録したり、udev ルールや調整されたプロファイルを構成したりする必要はありません。 -4. cpufreq モジュールの電源ポリシーを確認するには、次のコマンドを実行します。 +4. cpufreq モジュールの電源ポリシーを確認するには、次のコマンドを実行します。 ```bash cpupower frequency-info --policy @@ -492,11 +492,11 @@ sudo systemctl enable ntpd.service > > `The governor "powersave"`が出力された場合、 cpufreq モジュールの電源ポリシーは`powersave`です。これを`performance`に変更する必要があります。仮想マシンまたはクラウドホストを使用している場合、出力は通常`Unable to determine current policy`であり、何も変更する必要はありません。 -5. オペレーティング システムの最適なパラメータを構成します。 +5. オペレーティング システムの最適なパラメータを構成します。 - - 方法 1:tuned を使用する (推奨) + - 方法 1:tuned を使用する (推奨) - 1. 現在のオペレーティング システムの調整されたプロファイルを表示するには、 `tuned-adm list`コマンドを実行します。 + 1. 現在のオペレーティング システムの調整されたプロファイルを表示するには、 `tuned-adm list`コマンドを実行します。 ```bash tuned-adm list @@ -519,7 +519,7 @@ sudo systemctl enable ntpd.service 出力`Current active profile: balanced`は、現在のオペレーティングシステムの調整済みプロファイルが`balanced`あることを意味します。現在のプロファイルに基づいてオペレーティングシステムの構成を最適化することをお勧めします。 - 2. 新しい調整プロファイルを作成します。 + 2. 新しい調整プロファイルを作成します。 ```bash mkdir /etc/tuned/balanced-tidb-optimal/ @@ -543,7 +543,7 @@ sudo systemctl enable ntpd.service 出力`include=balanced`は、オペレーティング システムの最適化構成を現在の`balanced`プロファイルに追加することを意味します。 - 3. 新しく調整されたプロファイルを適用します。 + 3. 新しく調整されたプロファイルを適用します。 > **Note:** > @@ -553,9 +553,9 @@ sudo systemctl enable ntpd.service tuned-adm profile balanced-tidb-optimal ``` - - 方法2：スクリプトを使用して設定する。既に方法1を使用している場合は、この方法をスキップしてください。 + - 方法2：スクリプトを使用して設定する。既に方法1を使用している場合は、この方法をスキップしてください。 - 1. デフォルトのカーネル バージョンを確認するには、 `grubby`コマンドを実行します。 + 1. デフォルトのカーネル バージョンを確認するには、 `grubby`コマンドを実行します。 > **Note:** > @@ -569,7 +569,7 @@ sudo systemctl enable ntpd.service /boot/vmlinuz-3.10.0-957.el7.x86_64 ``` - 2. カーネル構成を変更するには、 `grubby --update-kernel`を実行します。 + 2. カーネル構成を変更するには、 `grubby --update-kernel`を実行します。 ```bash grubby --args="transparent_hugepage=never" --update-kernel `grubby --default-kernel` @@ -579,7 +579,7 @@ sudo systemctl enable ntpd.service > > `--update-kernel`の後に実際のバージョン番号（ `--update-kernel /boot/vmlinuz-3.10.0-957.el7.x86_64`や`ALL` ）を指定することもできます。 - 3. 変更されたデフォルトのカーネル構成を確認するには、 `grubby --info`を実行します。 + 3. 変更されたデフォルトのカーネル構成を確認するには、 `grubby --info`を実行します。 ```bash grubby --info /boot/vmlinuz-3.10.0-957.el7.x86_64 @@ -598,14 +598,14 @@ sudo systemctl enable ntpd.service title=CentOS Linux (3.10.0-957.el7.x86_64) 7 (Core) ``` - 4. THP を直ちに無効にするには、現在のカーネル構成を変更します。 + 4. THP を直ちに無効にするには、現在のカーネル構成を変更します。 ```bash echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag ``` - 5. udev スクリプトでI/Oスケジューラを設定します。 + 5. udev スクリプトでI/Oスケジューラを設定します。 ```bash vi /etc/udev/rules.d/60-tidb-schedulers.rules @@ -617,7 +617,7 @@ sudo systemctl enable ntpd.service ``` - 6. udev スクリプトを適用します。 + 6. udev スクリプトを適用します。 > **Note:** > @@ -628,7 +628,7 @@ sudo systemctl enable ntpd.service udevadm trigger --type=devices --action=change ``` - 7. CPU 電力ポリシーを構成するサービスを作成します。 + 7. CPU 電力ポリシーを構成するサービスを作成します。 ```bash cat >> /etc/systemd/system/cpupower.service << EOF @@ -642,7 +642,7 @@ sudo systemctl enable ntpd.service EOF ``` - 8. CPU 電源ポリシー構成サービスを適用します。 + 8. CPU 電源ポリシー構成サービスを適用します。 ```bash systemctl daemon-reload @@ -650,7 +650,7 @@ sudo systemctl enable ntpd.service systemctl start cpupower.service ``` -6. THP のステータスを確認するには、次のコマンドを実行します。 +6. THP のステータスを確認するには、次のコマンドを実行します。 ```bash cat /sys/kernel/mm/transparent_hugepage/enabled @@ -660,7 +660,7 @@ sudo systemctl enable ntpd.service always madvise [never] ``` -7. 次のコマンドを実行して、データ ディレクトリが配置されているディスクのI/Oスケジューラを確認します。 +7. 次のコマンドを実行して、データ ディレクトリが配置されているディスクのI/Oスケジューラを確認します。 ```bash cat /sys/block/sd[bc]/queue/scheduler @@ -671,7 +671,7 @@ sudo systemctl enable ntpd.service [noop] deadline cfq ``` -8. cpufreq モジュールの電源ポリシーを確認するには、次のコマンドを実行します。 +8. cpufreq モジュールの電源ポリシーを確認するには、次のコマンドを実行します。 ```bash cpupower frequency-info --policy @@ -683,7 +683,7 @@ sudo systemctl enable ntpd.service The governor "performance" may decide which speed to use within this range. ``` -9. `sysctl`パラメータを変更するには、次のコマンドを実行します。 +9. `sysctl`パラメータを変更するには、次のコマンドを実行します。 ```bash echo "fs.file-max = 1000000">> /etc/sysctl.conf @@ -700,10 +700,10 @@ sudo systemctl enable ntpd.service > **Note:** > - > - `vm.min_free_kbytes`は、システムによって予約される空きメモリの最小量 (KiB 単位) を制御する Linux カーネル パラメータです。 - > - `vm.min_free_kbytes`に設定すると、メモリ回収メカニズムに影響します。設定値が大きすぎると利用可能なメモリが減少し、小さすぎるとメモリ要求速度がバックグラウンド回収速度を超え、メモリ回収が発生し、結果としてメモリ割り当てが遅延する可能性があります。 - > - `vm.min_free_kbytes`を少なくとも`1048576` KiB（1 GiB）に設定することをお勧めします。[NUMAがインストールされている](/check-before-deployment.md#install-the-numactl-tool)場合は、 `number of NUMA nodes * 1048576` KiBに設定することをお勧めします。 - > - Linux カーネル 4.11 以前を実行しているシステムの場合は、 `net.ipv4.tcp_tw_recycle = 0`を設定することをお勧めします。 + > - `vm.min_free_kbytes`は、システムによって予約される空きメモリの最小量 (KiB 単位) を制御する Linux カーネル パラメータです。 + > - `vm.min_free_kbytes`に設定すると、メモリ回収メカニズムに影響します。設定値が大きすぎると利用可能なメモリが減少し、小さすぎるとメモリ要求速度がバックグラウンド回収速度を超え、メモリ回収が発生し、結果としてメモリ割り当てが遅延する可能性があります。 + > - `vm.min_free_kbytes`を少なくとも`1048576` KiB（1 GiB）に設定することをお勧めします。[NUMAがインストールされている](/check-before-deployment.md#install-the-numactl-tool)場合は、 `number of NUMA nodes * 1048576` KiBに設定することをお勧めします。 + > - Linux カーネル 4.11 以前を実行しているシステムの場合は、 `net.ipv4.tcp_tw_recycle = 0`を設定することをお勧めします。 10. ユーザーの`limits.conf`ファイルを構成するには、次のコマンドを実行します。 @@ -724,17 +724,17 @@ sudo systemctl enable ntpd.service SSH相互信頼を設定する際は、すべてのターゲットノードで`tidb`ユーザーを作成して使用することをお勧めします。通常、TiDBではすべてのノードで同じユーザーを使用する必要はありません。ただし、以下のシナリオではユーザーの一貫性に注意してください。 -- Backup & Restore (BR) の使用: すべてのBRおよび TiDB 関連の操作を同じユーザーで実行することを強くお勧めします。 -- NFSなどのネットワークストレージを使用する場合：ユーザーがすべてのノードで同じUIDとGIDを持っていることを確認してください。NFSは、基盤となるUIDとGIDに基づいてファイルアクセス権限を決定します。ノード間でUIDまたはGIDが異なる場合、またはBRを実行しているユーザーがTiDBを実行しているユーザーと異なる場合（特に`sudo`権限がない場合）、バックアップまたはリストア操作中に権限拒否エラーが発生する可能性があります。 +- Backup & Restore (BR) の使用: すべてのBRおよび TiDB 関連の操作を同じユーザーで実行することを強くお勧めします。 +- NFSなどのネットワークストレージを使用する場合：ユーザーがすべてのノードで同じUIDとGIDを持っていることを確認してください。NFSは、基盤となるUIDとGIDに基づいてファイルアクセス権限を決定します。ノード間でUIDまたはGIDが異なる場合、またはBRを実行しているユーザーがTiDBを実行しているユーザーと異なる場合（特に`sudo`権限がない場合）、バックアップまたはリストア操作中に権限拒否エラーが発生する可能性があります。 -1. それぞれ`root`ユーザー アカウントを使用してターゲット マシンにログインし、 `tidb`ユーザーを作成してログイン パスワードを設定します。 +1. それぞれ`root`ユーザー アカウントを使用してターゲット マシンにログインし、 `tidb`ユーザーを作成してログイン パスワードを設定します。 ```bash useradd -m -d /home/tidb tidb passwd tidb ``` -2. パスワードなしで sudo を設定するには、次のコマンドを実行し、ファイルの末尾に`tidb ALL=(ALL) NOPASSWD: ALL`追加します。 +2. パスワードなしで sudo を設定するには、次のコマンドを実行し、ファイルの末尾に`tidb ALL=(ALL) NOPASSWD: ALL`追加します。 ```bash visudo @@ -744,14 +744,14 @@ SSH相互信頼を設定する際は、すべてのターゲットノードで`t tidb ALL=(ALL) NOPASSWD: ALL ``` -3. `tidb`ユーザーでコントロールマシンにログインし、以下のコマンドを実行します。`10.0.1.1`をターゲットマシンの IP アドレスに置き換え、プロンプトが表示されたらターゲットマシンの`tidb`ユーザーパスワードを入力します。コマンド実行後、SSH 相互信頼が既に作成されています。これは他のマシンにも適用されます。新しく作成された`tidb`ユーザーには`.ssh`ディレクトリがありません。このようなディレクトリを作成するには、RSA キーを生成するコマンドを実行します。コントロールマシンに TiDB コンポーネントを展開するには、コントロールマシンとコントロールマシン自体の相互信頼を設定します。 +3. `tidb`ユーザーでコントロールマシンにログインし、以下のコマンドを実行します。`10.0.1.1`をターゲットマシンの IP アドレスに置き換え、プロンプトが表示されたらターゲットマシンの`tidb`ユーザーパスワードを入力します。コマンド実行後、SSH 相互信頼が既に作成されています。これは他のマシンにも適用されます。新しく作成された`tidb`ユーザーには`.ssh`ディレクトリがありません。このようなディレクトリを作成するには、RSA キーを生成するコマンドを実行します。コントロールマシンに TiDB コンポーネントを展開するには、コントロールマシンとコントロールマシン自体の相互信頼を設定します。 ```bash ssh-keygen -t rsa ssh-copy-id -i ~/.ssh/id_rsa.pub 10.0.1.1 ``` -4. `tidb`ユーザーアカウントを使用してコントロールマシンにログインし、 `ssh`を使用してターゲットマシンの IP アドレスにログインします。パスワードを入力する必要がなく、正常にログインできれば、SSH 相互信頼が正常に設定されています。 +4. `tidb`ユーザーアカウントを使用してコントロールマシンにログインし、 `ssh`を使用してターゲットマシンの IP アドレスにログインします。パスワードを入力する必要がなく、正常にログインできれば、SSH 相互信頼が正常に設定されています。 ```bash ssh 10.0.1.1 @@ -761,7 +761,7 @@ SSH相互信頼を設定する際は、すべてのターゲットノードで`t [tidb@10.0.1.1 ~]$ ``` -5. `tidb`ユーザーでターゲットマシンにログインした後、以下のコマンドを実行します。パスワードを入力する必要がなく、 `root`ユーザーに切り替えられる場合は、 `tidb`ユーザーのパスワードなしのsudoが正常に設定されています。 +5. `tidb`ユーザーでターゲットマシンにログインした後、以下のコマンドを実行します。パスワードを入力する必要がなく、 `root`ユーザーに切り替えられる場合は、 `tidb`ユーザーのパスワードなしのsudoが正常に設定されています。 ```bash sudo -su root @@ -777,8 +777,8 @@ SSH相互信頼を設定する際は、すべてのターゲットノードで`t > **Note:** > -> - NUMA を使用してコアをバインドすることは、CPU リソースを分離する方法であり、高度に構成された物理マシンに複数のインスタンスを展開するのに適しています。 -> - `tiup cluster deploy`を使用してデプロイメントを完了したら、 `exec`コマンドを使用してクラスター レベルの管理操作を実行できます。 +> - NUMA を使用してコアをバインドすることは、CPU リソースを分離する方法であり、高度に構成された物理マシンに複数のインスタンスを展開するのに適しています。 +> - `tiup cluster deploy`を使用してデプロイメントを完了したら、 `exec`コマンドを使用してクラスター レベルの管理操作を実行できます。 NUMA ツールをインストールするには、次の 2 つの方法のいずれかを実行します。 @@ -790,13 +790,13 @@ sudo yum -y install numactl **方法 2** : `tiup cluster exec`コマンドを実行して、既存のクラスターに NUMA を一括インストールします。 -1. [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)に従ってクラスター`tidb-test`を展開します。TiDB クラスターをインストールしている場合は、この手順をスキップできます。 +1. [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)に従ってクラスター`tidb-test`を展開します。TiDB クラスターをインストールしている場合は、この手順をスキップできます。 ```bash tiup cluster deploy tidb-test v6.1.0 ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa] ``` -2. `sudo`権限を使用して`tiup cluster exec`コマンドを実行し、 `tidb-test`クラスター内のすべてのターゲット マシンに NUMA をインストールします。 +2. `sudo`権限を使用して`tiup cluster exec`コマンドを実行し、 `tidb-test`クラスター内のすべてのターゲット マシンに NUMA をインストールします。 ```bash tiup cluster exec tidb-test --sudo --command "yum -y install numactl" diff --git a/choose-index.md b/choose-index.md index 08760827620e8..90a2ac933d04d 100644 --- a/choose-index.md +++ b/choose-index.md @@ -38,13 +38,13 @@ TiDBは、ルールまたはコストに基づいてインデックスを選択 TiDBは、インデックスを選択するために以下のヒューリスティックな事前ルールを使用します。 -- ルール 1: インデックスが「完全一致の一意インデックス + テーブルから行を取得する必要がない（つまり、インデックスによって生成されるプランが IndexReader オペレーターである）」という条件を満たす場合、TiDB はこのインデックスを直接選択します。 +- ルール 1: インデックスが「完全一致の一意インデックス + テーブルから行を取得する必要がない（つまり、インデックスによって生成されるプランが IndexReader オペレーターである）」という条件を満たす場合、TiDB はこのインデックスを直接選択します。 -- ルール 2: インデックスが「完全一致の一意インデックス + テーブルから行を取得する必要性（つまり、インデックスによって生成されるプランが IndexLookupReader オペレーターである）」を満たす場合、TiDB はテーブルから取得する行数が最も少ないインデックスを候補インデックスとして選択します。 +- ルール 2: インデックスが「完全一致の一意インデックス + テーブルから行を取得する必要性（つまり、インデックスによって生成されるプランが IndexLookupReader オペレーターである）」を満たす場合、TiDB はテーブルから取得する行数が最も少ないインデックスを候補インデックスとして選択します。 -- ルール 3: インデックスが「通常のインデックス + テーブルから行を取得する必要がない + 読み取る行数が特定のしきい値の値より少ない」という条件を満たす場合、TiDB は読み取る行数が最も少ないインデックスを候補インデックスとして選択します。 +- ルール 3: インデックスが「通常のインデックス + テーブルから行を取得する必要がない + 読み取る行数が特定のしきい値の値より少ない」という条件を満たす場合、TiDB は読み取る行数が最も少ないインデックスを候補インデックスとして選択します。 -- ルール4：ルール2とルール3に基づいて候補インデックスが1つだけ選択された場合は、その候補インデックスを選択します。ルール2とルール3に基づいてそれぞれ2つの候補インデックスが選択された場合は、読み込む行数が少ない方のインデックスを選択します（インデックスを持つ行数＋テーブルから取得する行数）。 +- ルール4：ルール2とルール3に基づいて候補インデックスが1つだけ選択された場合は、その候補インデックスを選択します。ルール2とルール3に基づいてそれぞれ2つの候補インデックスが選択された場合は、読み込む行数が少ない方のインデックスを選択します（インデックスを持つ行数＋テーブルから取得する行数）。 上記のルールにおける「完全一致のインデックス」とは、インデックス付けされた各列が等しい条件を満たすことを意味します。 `EXPLAIN FORMAT = 'verbose' ...`ステートメントを実行する際に、事前ルールがインデックスに一致する場合、TiDB はインデックスが事前ルールに一致することを示す NOTE レベルの警告を出力します。 @@ -75,13 +75,13 @@ mysql> SHOW WARNINGS; スカイライン剪定は、インデックスに対するヒューリスティックなフィルタリングルールであり、誤った推定によるインデックス選択の誤りの可能性を低減できます。インデックスを評価するには、以下の次元が必要です。 -- インデックス付き列によってカバーされるアクセス条件の数はいくつでしょうか。「アクセス条件」とは、列範囲に変換できるWHERE句の条件のことです。インデックス付き列セットがカバーするアクセス条件が多いほど、この点において優れています。 +- インデックス付き列によってカバーされるアクセス条件の数はいくつでしょうか。「アクセス条件」とは、列範囲に変換できるWHERE句の条件のことです。インデックス付き列セットがカバーするアクセス条件が多いほど、この点において優れています。 -- テーブルにアクセスするためにインデックスを選択した場合に、テーブルから行を取得する必要があるかどうか（つまり、インデックスによって生成されるプランが IndexReader オペレーターまたは IndexLookupReader オペレーターであるかどうか）。テーブルから行を取得しないインデックスは、取得するインデックスよりもこの点で優れています。両方のインデックスが TiDB を使用してテーブルから行を取得する必要がある場合は、インデックス付き列によってカバーされるフィルタリング条件の数を比較します。フィルタリング条件とは、インデックスに基づいて判断できる`where`条件のことです。インデックスの列セットがより多くのアクセス条件をカバーするほど、テーブルから取得される行の数は少なくなり、この点でインデックスの性能が向上します。 +- テーブルにアクセスするためにインデックスを選択した場合に、テーブルから行を取得する必要があるかどうか（つまり、インデックスによって生成されるプランが IndexReader オペレーターまたは IndexLookupReader オペレーターであるかどうか）。テーブルから行を取得しないインデックスは、取得するインデックスよりもこの点で優れています。両方のインデックスが TiDB を使用してテーブルから行を取得する必要がある場合は、インデックス付き列によってカバーされるフィルタリング条件の数を比較します。フィルタリング条件とは、インデックスに基づいて判断できる`where`条件のことです。インデックスの列セットがより多くのアクセス条件をカバーするほど、テーブルから取得される行の数は少なくなり、この点でインデックスの性能が向上します。 -- インデックスが特定の順序を満たすかどうかを選択します。インデックスの読み取りでは特定の列セットの順序が保証されるため、クエリの順序を満たすインデックスは、この次元で満たさないインデックスよりも優れています。 +- インデックスが特定の順序を満たすかどうかを選択します。インデックスの読み取りでは特定の列セットの順序が保証されるため、クエリの順序を満たすインデックスは、この次元で満たさないインデックスよりも優れています。 -- インデックスが[グローバルインデックス](/global-indexes.md)かどうか。パーティション テーブルでは、グローバル インデックスにより、通常のインデックスと比較して SQL の cop タスクの数が効果的に削減され、全体的なパフォーマンスが向上します。 +- インデックスが[グローバルインデックス](/global-indexes.md)かどうか。パーティション テーブルでは、グローバル インデックスにより、通常のインデックスと比較して SQL の cop タスクの数が効果的に削減され、全体的なパフォーマンスが向上します。 上記次元において、インデックス`idx_a`が 3 つの次元すべてにおいてインデックス`idx_b`と同等以上のパフォーマンスを発揮し、かつ 1 つの次元において`idx_b`よりも優れたパフォーマンスを発揮する場合、 `idx_a`が優先されます。 `EXPLAIN FORMAT = 'verbose' ...`ステートメントを実行する際に、スカイラインプルーニングによって一部のインデックスが除外された場合、TiDB は、スカイラインプルーニングによる除外後に残ったインデックスを一覧表示する NOTE レベルの警告を出力します。 @@ -114,24 +114,24 @@ mysql> SHOW WARNINGS; スカイライン剪定ルールを使用して不適切なインデックスを除外した後、インデックスの選択は完全にコスト見積もりに基づいて行われます。テーブルへのアクセスにかかるコスト見積もりには、以下の点を考慮する必要があります。 -- ストレージエンジン内のインデックス付きデータの各行の平均長。 -- インデックスによって生成されたクエリ範囲内の行数。 -- テーブルから行を取得するのにかかるコスト。 -- クエリ実行中にインデックスによって生成される範囲の数。 +- ストレージエンジン内のインデックス付きデータの各行の平均長。 +- インデックスによって生成されたクエリ範囲内の行数。 +- テーブルから行を取得するのにかかるコスト。 +- クエリ実行中にインデックスによって生成される範囲の数。 これらの要素とコストモデルに基づいて、オプティマイザはテーブルにアクセスするためのコストが最も低いインデックスを選択します。 #### コスト見積もりに基づく選択における一般的なチューニングの問題 {#common-tuning-problems-with-cost-estimation-based-selection} -1. 推定行数は正確ではありませんか？ +1. 推定行数は正確ではありませんか？ これは通常、統計情報が古いか不正確であることが原因です。 `ANALYZE TABLE`ステートメントを再実行するか、 `ANALYZE TABLE`のパラメータを変更してください。 -2. 統計は正確で、 TiFlashからの読み取りは高速ですが、なぜオプティマイザはTiKVからの読み取りを選択するのでしょうか？ +2. 統計は正確で、 TiFlashからの読み取りは高速ですが、なぜオプティマイザはTiKVからの読み取りを選択するのでしょうか？ 現状では、 TiFlashとTiKV [`tidb_opt_seek_factor`](/system-variables.md#tidb_opt_seek_factor)区別するためのコストモデルはまだ粗雑です。tidb_opt_seek_factorパラメータの値を小さくすると、オプティマイザはTiFlashを選択するようになります。 -3. 統計情報は正確です。インデックスAはテーブルから行を取得する必要がありますが、実際にはテーブルから行を取得しないインデックスBよりも高速に実行されます。オプティマイザはなぜインデックスBを選択するのでしょうか？ +3. 統計情報は正確です。インデックスAはテーブルから行を取得する必要がありますが、実際にはテーブルから行を取得しないインデックスBよりも高速に実行されます。オプティマイザはなぜインデックスBを選択するのでしょうか？ この場合、テーブルから行を取得する際のコスト見積もりが大きすぎる可能性があります。tidb_opt_network_factor パラメータの値を小さくすることで[`tidb_opt_network_factor`](/system-variables.md#tidb_opt_network_factor)テーブルから行を取得する際のコストを削減できます。 @@ -139,9 +139,9 @@ mysql> SHOW WARNINGS; インデックスの選択は[オプティマイザのヒント](/optimizer-hints.md)を介して単一のクエリで制御できます。 -- `USE_INDEX` / `IGNORE_INDEX`オプティマイザに特定のインデックスを使用/使用しないように強制できます。 `FORCE_INDEX`と`USE_INDEX`は同じ効果があります。 +- `USE_INDEX` / `IGNORE_INDEX`オプティマイザに特定のインデックスを使用/使用しないように強制できます。 `FORCE_INDEX`と`USE_INDEX`は同じ効果があります。 -- `READ_FROM_STORAGE`オプティマイザに特定のテーブルに対してクエリを実行するために TiKV / TiFlashストレージエンジンを選択するように強制できます。 +- `READ_FROM_STORAGE`オプティマイザに特定のテーブルに対してクエリを実行するために TiKV / TiFlashストレージエンジンを選択するように強制できます。 ## 多値インデックスを使用する {#use-multi-valued-indexes} @@ -285,7 +285,7 @@ EXPLAIN SELECT /*+ use_index_merge(t3, k1, k2, ka) */ * FROM t3 WHERE 1 member o CREATE TABLE t4(a INT, j JSON, INDEX mvi1((CAST(j->'$.a' AS UNSIGNED ARRAY))), INDEX mvi2((CAST(j->'$.b' AS UNSIGNED ARRAY)))); ``` -- `OR`に関連する条件については、それぞれ IndexMerge を使用してアクセスできる必要があります。例: +- `OR`に関連する条件については、それぞれ IndexMerge を使用してアクセスできる必要があります。例: ```sql EXPLAIN SELECT /*+ use_index_merge(t4, mvi1) */ * FROM t4 WHERE json_overlaps(j->'$.a', '[1, 2]') OR json_overlaps(j->'$.a', '[3, 4]'); @@ -325,7 +325,7 @@ CREATE TABLE t4(a INT, j JSON, INDEX mvi1((CAST(j->'$.a' AS UNSIGNED ARRAY))), I +---------+------+----------------------------+ ``` -- `AND`に関連する条件については、それぞれ IndexMerge を使用してアクセスできる必要があります。TiDB は、これらの条件を持つ多値インデックスへのアクセスに IndexMerge のみを使用できます。例: +- `AND`に関連する条件については、それぞれ IndexMerge を使用してアクセスできる必要があります。TiDB は、これらの条件を持つ多値インデックスへのアクセスに IndexMerge のみを使用できます。例: ```sql EXPLAIN SELECT /*+ use_index_merge(t4, mvi1) */ * FROM t4 WHERE json_contains(j->'$.a', '[1, 2]') AND json_contains(j->'$.a', '[3, 4]'); @@ -360,9 +360,9 @@ CREATE TABLE t4(a INT, j JSON, INDEX mvi1((CAST(j->'$.a' AS UNSIGNED ARRAY))), I +-------------------------------+---------+-----------+-----------------------------------------------------------------------------+----------------------------------------------------+ ``` -- IndexMerge に使用されるすべての条件は、それらを接続している`OR`または`AND`のセマンティクスと一致する必要があります。 +- IndexMerge に使用されるすべての条件は、それらを接続している`OR`または`AND`のセマンティクスと一致する必要があります。 - - `json_contains` `AND`と接続されている場合は、意味的に一致します。例: + - `json_contains` `AND`と接続されている場合は、意味的に一致します。例: ```sql EXPLAIN SELECT /*+ use_index_merge(t4, mvi1, mvi2) */ * FROM t4 WHERE json_contains(j->'$.a', '[1]') AND json_contains(j->'$.b', '[2, 3]'); @@ -392,7 +392,7 @@ CREATE TABLE t4(a INT, j JSON, INDEX mvi1((CAST(j->'$.a' AS UNSIGNED ARRAY))), I +-------------------------+----------+-----------+---------------+---------------------------------------------------------------------------------------------------------------------------------------------------------+ ``` - - `json_overlaps` `OR`と接続されている場合は、意味的に一致します。例: + - `json_overlaps` `OR`と接続されている場合は、意味的に一致します。例: ```sql EXPLAIN SELECT /*+ use_index_merge(t4, mvi1, mvi2) */ * FROM t4 WHERE json_overlaps(j->'$.a', '[1]') OR json_overlaps(j->'$.b', '[2, 3]'); @@ -424,7 +424,7 @@ CREATE TABLE t4(a INT, j JSON, INDEX mvi1((CAST(j->'$.a' AS UNSIGNED ARRAY))), I +---------------------------------+---------+-----------+-----------------------------------------------------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------+ ``` - - `json_member_of`が`OR`または`AND`に接続されている場合、意味的に一致します。例: + - `json_member_of`が`OR`または`AND`に接続されている場合、意味的に一致します。例: ```sql EXPLAIN SELECT /*+ use_index_merge(t4, mvi1, mvi2) */ * FROM t4 WHERE 1 member of (j->'$.a') AND 2 member of (j->'$.b') AND 3 member of (j->'$.a'); @@ -455,7 +455,7 @@ CREATE TABLE t4(a INT, j JSON, INDEX mvi1((CAST(j->'$.a' AS UNSIGNED ARRAY))), I +-------------------------------+---------+-----------+-----------------------------------------------------------------------------+---------------------------------------------+ ``` - - 複数の値を含む`json_contains`条件が`OR`に接続されている場合、または複数の値を含む`json_overlaps`条件が`AND`に接続されている場合、それらは意味論に一致しませんが、値が 1 つだけの場合は意味論に一致します。例: + - 複数の値を含む`json_contains`条件が`OR`に接続されている場合、または複数の値を含む`json_overlaps`条件が`AND`に接続されている場合、それらは意味論に一致しませんが、値が 1 つだけの場合は意味論に一致します。例: ```sql -- Refer to the preceding examples for conditions that do not match the semantics. The following only provides examples of conditions that match the semantics. @@ -486,7 +486,7 @@ CREATE TABLE t4(a INT, j JSON, INDEX mvi1((CAST(j->'$.a' AS UNSIGNED ARRAY))), I +-------------------------------+---------+-----------+-----------------------------------------------------------------------------+---------------------------------------------+ ``` - - `OR`と`AND`の両方を使用して条件を接続する場合 (実質的には`OR`と`AND`ネストされている場合)、IndexMerge を構成する条件は`OR`のセマンティクスにすべて一致するか、 `AND`のセマンティクスにすべて一致する必要があります。 `OR`のセマンティクスに部分的に一致し、かつ`AND`のセマンティクスに部分的に一致することはできません。例: + - `OR`と`AND`の両方を使用して条件を接続する場合 (実質的には`OR`と`AND`ネストされている場合)、IndexMerge を構成する条件は`OR`のセマンティクスにすべて一致するか、 `AND`のセマンティクスにすべて一致する必要があります。 `OR`のセマンティクスに部分的に一致し、かつ`AND`のセマンティクスに部分的に一致することはできません。例: ```sql EXPLAIN SELECT /*+ use_index_merge(t4, mvi1, mvi2) */ * FROM t4 WHERE 1 member of (j->'$.a') AND (2 member of (j->'$.b') OR 3 member of (j->'$.a')); diff --git a/clinic/clinic-data-instruction-for-tiup.md b/clinic/clinic-data-instruction-for-tiup.md index 9adec6a2d457b..b4a18dda22749 100644 --- a/clinic/clinic-data-instruction-for-tiup.md +++ b/clinic/clinic-data-instruction-for-tiup.md @@ -11,8 +11,8 @@ PingCAP Clinicによって収集された診断データは、クラスターの クラウドに展開される診断サービスである Clinic Server は、データのストレージの場所に応じて 2 つの独立したサービスを提供します。 -- [国際ユーザー向けClinic Server](https://clinic.pingcap.com) ：収集したデータを国際ユーザー向けのClinic Serverにアップロードすると、データはPingCAPがAWS米国リージョンに展開するAmazon S3サービスに保存されます。PingCAPは厳格なデータアクセスポリシーを採用しており、承認されたテクニカルサポート担当者のみがデータにアクセスできます。 -- [中国本土のユーザー向けClinic Server](https://clinic.pingcap.com.cn) ：収集したデータを中国本土のユーザー向けClinic Serverにアップロードすると、データはPingCAPが中国（北京）リージョンに展開するAmazon S3サービスに保存されます。PingCAPは厳格なデータアクセスポリシーを採用しており、承認されたテクニカルサポート担当者のみがデータにアクセスできます。 +- [国際ユーザー向けClinic Server](https://clinic.pingcap.com) ：収集したデータを国際ユーザー向けのClinic Serverにアップロードすると、データはPingCAPがAWS米国リージョンに展開するAmazon S3サービスに保存されます。PingCAPは厳格なデータアクセスポリシーを採用しており、承認されたテクニカルサポート担当者のみがデータにアクセスできます。 +- [中国本土のユーザー向けClinic Server](https://clinic.pingcap.com.cn) ：収集したデータを中国本土のユーザー向けClinic Serverにアップロードすると、データはPingCAPが中国（北京）リージョンに展開するAmazon S3サービスに保存されます。PingCAPは厳格なデータアクセスポリシーを採用しており、承認されたテクニカルサポート担当者のみがデータにアクセスできます。 ## TiDB クラスター {#tidb-clusters} @@ -148,7 +148,7 @@ PingCAP Clinicによって収集された診断データは、クラスターの ログの種類: -- `std` : ファイル名に`stderr`含まれるログファイル。 -- `rocksdb` : プレフィックスが`rocksdb` 、サフィックスが`.info`ログ ファイル。 -- `slow` : クエリ ログ ファイルが遅い。 -- `unknown` : 上記のいずれの種類にも一致しないログ ファイル。 +- `std` : ファイル名に`stderr`含まれるログファイル。 +- `rocksdb` : プレフィックスが`rocksdb` 、サフィックスが`.info`ログ ファイル。 +- `slow` : クエリ ログ ファイルが遅い。 +- `unknown` : 上記のいずれの種類にも一致しないログ ファイル。 diff --git a/clinic/clinic-introduction.md b/clinic/clinic-introduction.md index 23ef15c448ae0..f02f10485dab4 100644 --- a/clinic/clinic-introduction.md +++ b/clinic/clinic-introduction.md @@ -9,7 +9,7 @@ PingCAP Clinic診断サービス（PingCAP Clinic）は、 TiUPまたはTiDB Ope PingCAP Clinic は、クラスターの問題を診断するために次の 2 つのコンポーネントを提供します。 -- [Diagクライアント](https://github.com/pingcap/diag) : +- [Diagクライアント](https://github.com/pingcap/diag) : Diagクライアント（Diag）は、クラスタ側にデプロイされるオープンソースの診断ツールです。Diagは、クラスタ診断データの収集、Clinic Serverへの診断データのアップロード、そしてクラスタ上でローカルで簡単なヘルスチェックを実行するために使用されます。Diagで収集できる診断データの全リストについては、 [PingCAP Clinic診断データ](/clinic/clinic-data-instruction-for-tiup.md)ご覧ください。 @@ -17,20 +17,20 @@ PingCAP Clinic は、クラスターの問題を診断するために次の 2 > > Diag は TiDB v4.0 以降のバージョンをサポートしていますが、TiDB Ansible を使用してデプロイされたクラスターからのデータ収集は**サポートしていません**。 -- Clinic Server: +- Clinic Server: Clinic Serverはクラウド上に展開されるクラウドサービスです。SaaSモデルで診断サービスを提供することで、Clinic Serverはアップロードされた診断データを受信するだけでなく、データの保存、閲覧、クラスター診断レポートの提供など、オンライン診断環境として機能します。Clinic Serverは、ストレージの場所に応じて2つの独立したサービスを提供します。 - - [国際ユーザー向けClinic Server](https://clinic.pingcap.com) : データは米国の AWS に保存されます。 - - [中国本土のユーザー向けClinic Server](https://clinic.pingcap.com.cn) : データは中国 (北京) リージョンの AWS に保存されます。 + - [国際ユーザー向けClinic Server](https://clinic.pingcap.com) : データは米国の AWS に保存されます。 + - [中国本土のユーザー向けClinic Server](https://clinic.pingcap.com.cn) : データは中国 (北京) リージョンの AWS に保存されます。 ## ユーザーシナリオ {#user-scenarios} -- クラスタの問題をリモートでトラブルシューティングする +- クラスタの問題をリモートでトラブルシューティングする クラスターにすぐに解決できない問題が発生した場合、PingCAPまたはコミュニティから[サポートを受ける](/support.md)ことができます。リモートアシスタンスのためにテクニカルサポートに連絡する場合、クラスターからさまざまな診断データを保存し、サポートスタッフに転送する必要があります。この場合、Diagを使用すると、ワンクリックで診断データを収集できます。Diagを使用すると、完全な診断データを迅速に収集できるため、複雑な手動データ収集操作を回避できます。データを収集した後、PingCAPテクニカルサポートスタッフがクラスターの問題をトラブルシューティングできるように、データをClinic Serverにアップロードできます。Clinic Serverは、アップロードされた診断データを安全に保存し、オンライン診断をサポートすることで、トラブルシューティングの効率を大幅に向上させます。 -- クラスターのステータスを素早く確認 +- クラスターのステータスを素早く確認 クラスタが現時点で安定して動作している場合でも、潜在的な安定性リスクを検出するために、定期的にクラスタを検査する必要があります。PingCAP Clinicが提供するローカルおよびサーバー側のクイックチェック機能を使用することで、クラスタの潜在的な健全性リスクを特定できます。 @@ -40,20 +40,20 @@ PingCAP Clinic は、クラスターの問題を診断するために次の 2 まず、Diag はデプロイメントツールTiUP (tiup-cluster) またはTiDB Operator ( tidb-operator ) からクラスタトポロジ情報を取得します。次に、Diag は以下のような様々なデータ収集方法を通じて、様々な種類の診断データを収集します。 -- SCP 経由でサーバーファイルを転送する +- SCP 経由でサーバーファイルを転送する TiUPを使用して展開されたクラスターの場合、Diag はセキュリティコピー プロトコル (SCP) を介してターゲットコンポーネントのノードからログ ファイルと構成ファイルを直接収集できます。 -- SSH経由でリモートコマンドを実行してデータを収集する +- SSH経由でリモートコマンドを実行してデータを収集する TiUPを使用して展開されたクラスターの場合、Diag は SSH ( セキュリティ Shell) を介してターゲットコンポーネントシステムに接続し、コマンド (Insight など) を実行して、カーネル ログ、カーネル パラメーター、システムとハードウェアの基本情報などのシステム情報を取得できます。 -- HTTP呼び出しを通じてデータを収集する +- HTTP呼び出しを通じてデータを収集する - - Diag は TiDB コンポーネントの HTTP インターフェイスを呼び出すことで、TiDB、TiKV、PD などのコンポーネントのリアルタイム構成サンプリング情報とリアルタイム パフォーマンス サンプリング情報を取得できます。 - - Prometheus の HTTP インターフェースを呼び出すことで、Diag はアラート情報と監視メトリック データを取得できます。 + - Diag は TiDB コンポーネントの HTTP インターフェイスを呼び出すことで、TiDB、TiKV、PD などのコンポーネントのリアルタイム構成サンプリング情報とリアルタイム パフォーマンス サンプリング情報を取得できます。 + - Prometheus の HTTP インターフェースを呼び出すことで、Diag はアラート情報と監視メトリック データを取得できます。 -- SQL 文を使用してデータベースパラメータを照会する +- SQL 文を使用してデータベースパラメータを照会する DiagはSQL文を使用して、TiDBのシステム変数やその他の情報を照会できます。この方法を使用するには、データ収集時にTiDBにアクセスするためのユーザー名とパスワードを**追加で入力する**必要があります。 @@ -61,8 +61,8 @@ PingCAP Clinic は、クラスターの問題を診断するために次の 2 > **Note:** > -> - Clinic Serverは2022年7月15日から2025年4月15日まで無料です。それ以降に有料になる場合は、2025年4月15日までにメールでお知らせいたします。 -> - 使用制限を調整する場合は、PingCAP から[サポートを受けてください](/support.md)。 +> - Clinic Serverは2022年7月15日から2025年4月15日まで無料です。それ以降に有料になる場合は、2025年4月15日までにメールでお知らせいたします。 +> - 使用制限を調整する場合は、PingCAP から[サポートを受けてください](/support.md)。 | サービスタイプ | 制限 | | :------------- | :---------- | @@ -74,11 +74,11 @@ PingCAP Clinic は、クラスターの問題を診断するために次の 2 ## 次のステップ {#next-step} -- オンプレミス環境でPingCAP Clinicを使用する - - [PingCAP Clinicのクイックスタート](/clinic/quick-start-with-clinic.md) - - [PingCAP Clinicを使用したクラスターのトラブルシューティング](/clinic/clinic-user-guide-for-tiup.md) - - [PingCAP Clinic診断データ](/clinic/clinic-data-instruction-for-tiup.md) +- オンプレミス環境でPingCAP Clinicを使用する + - [PingCAP Clinicのクイックスタート](/clinic/quick-start-with-clinic.md) + - [PingCAP Clinicを使用したクラスターのトラブルシューティング](/clinic/clinic-user-guide-for-tiup.md) + - [PingCAP Clinic診断データ](/clinic/clinic-data-instruction-for-tiup.md) -- Kubernetes でPingCAP Clinicを使用する - - [PingCAP Clinicを使用して TiDBクラスタのトラブルシューティングを行う](https://docs.pingcap.com/tidb-in-kubernetes/stable/clinic-user-guide) - - [PingCAP Clinic診断データ](https://docs.pingcap.com/tidb-in-kubernetes/stable/clinic-data-collection) +- Kubernetes でPingCAP Clinicを使用する + - [PingCAP Clinicを使用して TiDBクラスタのトラブルシューティングを行う](https://docs.pingcap.com/tidb-in-kubernetes/stable/clinic-user-guide) + - [PingCAP Clinic診断データ](https://docs.pingcap.com/tidb-in-kubernetes/stable/clinic-data-collection) diff --git a/clinic/clinic-user-guide-for-tiup.md b/clinic/clinic-user-guide-for-tiup.md index 017bb7c8e1b0e..d1ffc93d9e80e 100644 --- a/clinic/clinic-user-guide-for-tiup.md +++ b/clinic/clinic-user-guide-for-tiup.md @@ -9,18 +9,18 @@ TiUPを使用して導入された TiDB クラスターおよび DM クラスタ > **Note:** > -> - このドキュメントは、セルフホスト環境で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 を使用してデプロイされたクラスターからのデータ収集を**サポートしていません**。 +> - PingCAP Clinic は、 TiDB Ansible を使用してデプロイされたクラスターからのデータ収集を**サポートしていません**。 ## ユーザーシナリオ {#user-scenarios} -- [クラスタの問題をリモートでトラブルシューティングする](#troubleshoot-cluster-problems-remotely) +- [クラスタの問題をリモートでトラブルシューティングする](#troubleshoot-cluster-problems-remotely) - - クラスターに問題がある場合、PingCAP から[サポートを受ける](/support.md)必要があります。リモート トラブルシューティングを容易にするために、Diag を使用して診断データを収集し、収集したデータを Clinic Server にアップロードし、データ アクセス リンクをテクニカル サポート スタッフに提供するための次の操作を実行できます。 - - クラスターに何らかの問題があり、すぐに問題を分析できない場合は、Diag を使用してデータを収集し、後で分析できるように保存することができます。 + - クラスターに問題がある場合、PingCAP から[サポートを受ける](/support.md)必要があります。リモート トラブルシューティングを容易にするために、Diag を使用して診断データを収集し、収集したデータを Clinic Server にアップロードし、データ アクセス リンクをテクニカル サポート スタッフに提供するための次の操作を実行できます。 + - クラスターに何らかの問題があり、すぐに問題を分析できない場合は、Diag を使用してデータを収集し、後で分析できるように保存することができます。 -- [ローカルでクラスタのステータスをクイックチェックする](#perform-a-quick-check-on-the-cluster-status-locally) +- [ローカルでクラスタのステータスをクイックチェックする](#perform-a-quick-check-on-the-cluster-status-locally) クラスタが現在安定して動作している場合でも、潜在的な安定性リスクを検出するために、定期的にクラスタを検査する必要があります。PingCAP Clinicが提供するローカルクイックチェック機能を使用すると、クラスタの潜在的なヘルスリスクを特定できます。ローカルチェックでは構成のみがチェックされます。メトリックやログなど、より多くの項目をチェックするには、診断データをClinic Serverにアップロードし、ヘルスレポート機能を使用することをお勧めします。 @@ -28,15 +28,15 @@ TiUPを使用して導入された TiDB クラスターおよび DM クラスタ PingCAP Clinicを使用する前に、Diag（ PingCAP Clinicが提供するデータ収集コンポーネント）をインストールし、データをアップロードする環境を準備する必要があります。 -1. Diag をインストールします。 +1. Diag をインストールします。 - - コントロール マシンにTiUPがインストールされている場合は、次のコマンドを実行して Diag をインストールします。 + - コントロール マシンにTiUPがインストールされている場合は、次のコマンドを実行して Diag をインストールします。 ```bash tiup install diag ``` - - Diag をインストールしている場合は、次のコマンドを使用して Diag を最新バージョンにアップグレードできます。 + - Diag をインストールしている場合は、次のコマンドを使用して Diag を最新バージョンにアップグレードできます。 ```bash tiup update diag @@ -44,16 +44,16 @@ PingCAP Clinicを使用する前に、Diag（ PingCAP Clinicが提供するデ > **Note:** > - > - インターネット接続のないクラスタでは、Diagをオフラインで展開する必要があります。詳細については、 [TiUPをオフラインでデプロイ: 方法2](/production-deployment-using-tiup.md#deploy-tiup-offline)を参照してください。 - > - Diag は、TiDB Server オフライン ミラー パッケージ v5.4.0 以降で**のみ**提供されます。 + > - インターネット接続のないクラスタでは、Diagをオフラインで展開する必要があります。詳細については、 [TiUPをオフラインでデプロイ: 方法2](/production-deployment-using-tiup.md#deploy-tiup-offline)を参照してください。 + > - Diag は、TiDB Server オフライン ミラー パッケージ v5.4.0 以降で**のみ**提供されます。 -2. データをアップロードするためのアクセス トークン (トークン) を取得して設定します。 +2. データをアップロードするためのアクセス トークン (トークン) を取得して設定します。 Diag を通じて収集したデータをアップロードする際、ユーザー認証用のトークンが必要です。既にトークン Diag を設定している場合は、そのトークンを再利用してこの手順を省略できます。 トークンを取得するには、次の手順を実行します。 - - Clinic Serverにログインします。 + - Clinic Serverにログインします。
@@ -69,30 +69,30 @@ PingCAP Clinicを使用する前に、Diag（ PingCAP Clinicが提供するデ - - クラスタページの右下隅にあるアイコンをクリックし、 **Get Access Token For Diag Tool**を選択して、ポップアップウィンドウの**+**をクリックします。表示されるトークンをコピーして保存してください。 + - クラスタページの右下隅にあるアイコンをクリックし、 **Get Access Token For Diag Tool**を選択して、ポップアップウィンドウの**+**をクリックします。表示されるトークンをコピーして保存してください。 ![Get the Token](/media/clinic-get-token.png) > **Note:** > - > - Clinic Serverに初めてアクセスする場合は、トークンを取得する前に、 [PingCAP Clinicのクイックスタート](/clinic/quick-start-with-clinic.md#prerequisites)を参考に環境を準備する必要があります。 - > - データセキュリティのため、TiDBはトークン作成時にのみトークンを表示します。トークンを紛失した場合は、古いトークンを削除して新しいトークンを作成してください。 - > - トークンはデータのアップロードにのみ使用されます。 + > - Clinic Serverに初めてアクセスする場合は、トークンを取得する前に、 [PingCAP Clinicのクイックスタート](/clinic/quick-start-with-clinic.md#prerequisites)を参考に環境を準備する必要があります。 + > - データセキュリティのため、TiDBはトークン作成時にのみトークンを表示します。トークンを紛失した場合は、古いトークンを削除して新しいトークンを作成してください。 + > - トークンはデータのアップロードにのみ使用されます。 - - 次に、Diag でトークンを設定します。例: + - 次に、Diag でトークンを設定します。例: ```bash tiup diag config clinic.token ${token-value} ``` -3. Diag に`region`設定します。 +3. Diag に`region`設定します。 `region` 、データの圧縮に使用する暗号化証明書と、データのアップロード時に使用する対象サービスを決定します。例: > **Note:** > - > - Diag v0.9.0 以降のバージョンでは設定`region`サポートされます。 - > - Diag v0.9.0より前のバージョンでは、データはデフォルトで中国リージョンのClinic Serverにアップロードされます。これらのバージョンで`region`設定するには、 `tiup update diag`コマンドを実行してDiagを最新バージョンにアップグレードし、その後Diagで`region`設定してください。 + > - Diag v0.9.0 以降のバージョンでは設定`region`サポートされます。 + > - Diag v0.9.0より前のバージョンでは、データはデフォルトで中国リージョンのClinic Serverにアップロードされます。これらのバージョンで`region`設定するには、 `tiup update diag`コマンドを実行してDiagを最新バージョンにアップグレードし、その後Diagで`region`設定してください。
@@ -116,7 +116,7 @@ PingCAP Clinicを使用する前に、Diag（ PingCAP Clinicが提供するデ -4. (オプション) ログの秘匿化を有効にします。 +4. (オプション) ログの秘匿化を有効にします。 TiDBが詳細なログ情報を提供する場合、ログに機密情報（ユーザーデータなど）が出力される可能性があります。ローカルログおよびClinic Serverへの機密情報の漏洩を防ぎたい場合は、TiDB側でログの秘匿化を有効にすることができます。詳細については、 [ログの秘匿化](/log-redaction.md#log-redaction-in-tidb-side)をご覧ください。 @@ -134,7 +134,7 @@ Diag によって収集できるデータの完全なリストについては、 Diag を使用すると、 TiUPを使用して展開された TiDB クラスターと DM クラスターからデータを収集できます。 -1. Diag のデータ収集コマンドを実行します。 +1. Diag のデータ収集コマンドを実行します。 たとえば、現在の時刻に基づいて 4 時間前から 2 時間前までの診断データを収集するには、次のコマンドを実行します。 @@ -157,8 +157,8 @@ Diag を使用すると、 TiUPを使用して展開された TiDB クラスタ データ収集のパラメータの説明: - - `-f/--from` : データ収集の開始時刻を指定します。このパラメータを指定しない場合、デフォルトの開始時刻は現在時刻の2時間前になります。タイムゾーンを変更するには、 `-f="12:30 +0800"`構文を使用します。このパラメータでタイムゾーン情報を指定しない場合（例： `+0800` ）、デフォルトのタイムゾーンはUTCです。 - - `-t/--to` : データ収集の終了時刻を指定します。このパラメータを指定しない場合、デフォルトの終了時刻は現在時刻となります。タイムゾーンを変更するには、 `-f="12:30 +0800"`構文を使用します。このパラメータでタイムゾーン情報を指定しない場合（例： `+0800` ）、デフォルトのタイムゾーンはUTCです。 + - `-f/--from` : データ収集の開始時刻を指定します。このパラメータを指定しない場合、デフォルトの開始時刻は現在時刻の2時間前になります。タイムゾーンを変更するには、 `-f="12:30 +0800"`構文を使用します。このパラメータでタイムゾーン情報を指定しない場合（例： `+0800` ）、デフォルトのタイムゾーンはUTCです。 + - `-t/--to` : データ収集の終了時刻を指定します。このパラメータを指定しない場合、デフォルトの終了時刻は現在時刻となります。タイムゾーンを変更するには、 `-f="12:30 +0800"`構文を使用します。このパラメータでタイムゾーン情報を指定しない場合（例： `+0800` ）、デフォルトのタイムゾーンはUTCです。 パラメータの使用に関するヒント: @@ -166,15 +166,15 @@ Diag を使用すると、 TiUPを使用して展開された TiDB クラスタ > **Note:** > - > - Diag はデフォルトではシステム変数データ (db_vars) を収集しません。このデータを収集するには、データベースにアクセスできるユーザー名とパスワードを追加で入力する必要があります。なお、このデータベースではシステム変数への読み取りアクセスが有効になっている必要があります。 - > - Diagはデフォルトではパフォーマンスデータ（ `perf` ）とデバッグデータ（ `debug` ）を収集しません。 - > - システム変数を含む完全な診断データを収集するには、コマンド`tiup diag collect --include="system,monitor,log,config,db_vars,perf,debug"`を使用します。 + > - Diag はデフォルトではシステム変数データ (db_vars) を収集しません。このデータを収集するには、データベースにアクセスできるユーザー名とパスワードを追加で入力する必要があります。なお、このデータベースではシステム変数への読み取りアクセスが有効になっている必要があります。 + > - Diagはデフォルトではパフォーマンスデータ（ `perf` ）とデバッグデータ（ `debug` ）を収集しません。 + > - システム変数を含む完全な診断データを収集するには、コマンド`tiup diag collect --include="system,monitor,log,config,db_vars,perf,debug"`を使用します。 - - `-l` : ファイル転送の帯域幅制限。単位は Kbit/s、デフォルト値は`100000` (scp の`-l`のパラメータ) です。 - - `-N/--node` : 指定されたノードからのみデータを収集します。形式は`ip:port`です。 - - `--include` : 特定の種類のデータのみを収集します。オプションの値は`system` 、 `monitor` 、 `log` 、 `config` 、 `db_vars`です。2つ以上の種類を含める場合は、種類間の区切りとして`,`を使用できます。 - - `--exclude` : 特定の種類のデータを収集しません。オプションの値は`system` 、 `monitor` 、 `log` 、 `config` 、 `db_vars`です。2つ以上の種類を除外する場合は、種類間の区切りとして`,`を使用できます。 - - `--metricsfilter` : 指定されたPrometheusメトリックのみを収集します。メトリックのプレフィックスをカンマ区切りで指定できます。例えば、 `--metricsfilter=tidb,pd` `tidb`で始まるメトリックと`pd`で始まるメトリックを収集します。 + - `-l` : ファイル転送の帯域幅制限。単位は Kbit/s、デフォルト値は`100000` (scp の`-l`のパラメータ) です。 + - `-N/--node` : 指定されたノードからのみデータを収集します。形式は`ip:port`です。 + - `--include` : 特定の種類のデータのみを収集します。オプションの値は`system` 、 `monitor` 、 `log` 、 `config` 、 `db_vars`です。2つ以上の種類を含める場合は、種類間の区切りとして`,`を使用できます。 + - `--exclude` : 特定の種類のデータを収集しません。オプションの値は`system` 、 `monitor` 、 `log` 、 `config` 、 `db_vars`です。2つ以上の種類を除外する場合は、種類間の区切りとして`,`を使用できます。 + - `--metricsfilter` : 指定されたPrometheusメトリックのみを収集します。メトリックのプレフィックスをカンマ区切りで指定できます。例えば、 `--metricsfilter=tidb,pd` `tidb`で始まるメトリックと`pd`で始まるメトリックを収集します。 > **Tip:** > @@ -199,7 +199,7 @@ Diag を使用すると、 TiUPを使用して展開された TiDB クラスタ Do you want to continue? [y/N]: (default=N) ``` -2. データの収集を開始することを確認するには、 `Y`入力します。 +2. データの収集を開始することを確認するには、 `Y`入力します。 データの収集には一定の時間がかかります。収集するデータの量によって時間は異なります。例えば、テスト環境では1GBのデータの収集に約10分かかります。 @@ -213,14 +213,14 @@ Diag を使用すると、 TiUPを使用して展開された TiDB クラスタ 収集されたデータは、データソースに基づいて個別のサブディレクトリに保存されます。これらのサブディレクトリは、マシン名とポート番号に基づいて名前が付けられます。各ノードの設定、ログ、その他のファイルのストレージの場所は、TiDBクラスターの実サーバーにおける相対的なストレージパスと同じです。 -- システムとハードウェアの基本情報： `insight.json` -- システム`/etc/security/limits.conf`の内容： `limits.conf` -- カーネルパラメータのリスト: `sysctl.conf` -- カーネルログ: `dmesg.log` -- データ収集中のネットワーク接続: `ss.txt` -- コンフィグレーションデータ：各ノードの`config.json`ディレクトリ -- クラスター自体のメタ情報: in `meta.yaml` (このファイルは収集されたデータを保存するディレクトリの最上位にあります) -- 監視データ： `/monitor`ファイルディレクトリ内。監視データはデフォルトで圧縮されており、直接表示できません。監視データを含むJSONファイルを直接表示するには、データ収集時に`--compress-metrics=false`パラメータで圧縮を無効にしてください。 +- システムとハードウェアの基本情報： `insight.json` +- システム`/etc/security/limits.conf`の内容： `limits.conf` +- カーネルパラメータのリスト: `sysctl.conf` +- カーネルログ: `dmesg.log` +- データ収集中のネットワーク接続: `ss.txt` +- コンフィグレーションデータ：各ノードの`config.json`ディレクトリ +- クラスター自体のメタ情報: in `meta.yaml` (このファイルは収集されたデータを保存するディレクトリの最上位にあります) +- 監視データ： `/monitor`ファイルディレクトリ内。監視データはデフォルトで圧縮されており、直接表示できません。監視データを含むJSONファイルを直接表示するには、データ収集時に`--compress-metrics=false`パラメータで圧縮を無効にしてください。 ### ステップ4. データのアップロード {#step-4-upload-data} @@ -228,8 +228,8 @@ PingCAPテクニカルサポートスタッフにクラスター診断データ クラスターのネットワーク接続に応じて、次のいずれかの方法を選択してデータをアップロードできます。 -- 方法 1: クラスターが配置されているネットワークがインターネットにアクセスできる場合は、 [アップロードコマンドを使用してデータを直接アップロードする](#method-1-upload-directly)を実行できます。 -- 方法 2: クラスターが配置されているネットワークがインターネットにアクセスできない場合は、 [データをパックしてアップロードする](#method-2-pack-and-upload-data)を実行する必要があります。 +- 方法 1: クラスターが配置されているネットワークがインターネットにアクセスできる場合は、 [アップロードコマンドを使用してデータを直接アップロードする](#method-1-upload-directly)を実行できます。 +- 方法 2: クラスターが配置されているネットワークがインターネットにアクセスできない場合は、 [データをパックしてアップロードする](#method-2-pack-and-upload-data)を実行する必要があります。 > **Note:** > @@ -249,7 +249,7 @@ tiup diag upload クラスターが設置されているネットワークがインターネットにアクセスできない場合は、イントラネット上でデータをパックし、インターネットにアクセスできるデバイスを使用してデータパッケージをClinic Serverにアップロードする必要があります。詳細な手順は以下のとおりです。 -1. 以下のコマンドを実行して、 [ステップ2. データを収集する](#step-2-collect-data)で取得した収集データをパックします。 +1. 以下のコマンドを実行して、 [ステップ2. データを収集する](#step-2-collect-data)で取得した収集データをパックします。 ```bash tiup diag package ${filepath} @@ -264,7 +264,7 @@ tiup diag upload パッケージングが完了すると、データは`.diag`形式にパッケージ化されます。`.diag`ファイルは、Clinic Serverにアップロードされた後にのみ復号化して閲覧できます。収集したデータをClinic Serverにアップロードせずに直接転送する場合は、独自の方法でデータを圧縮して転送することもできます。 -2. インターネットにアクセスできるマシンから、圧縮されたデータ パッケージをアップロードします。 +2. インターネットにアクセスできるマシンから、圧縮されたデータ パッケージをアップロードします。 ```bash tiup diag upload ${filepath} @@ -280,13 +280,13 @@ tiup diag upload Download URL: "https://clinic.pingcap.com.cn/portal/#/orgs/4/clusters/XXXX" ``` -3. アップロードが完了したら、 `Download URL`のリンクを開いてアップロードされたデータを確認するか、以前に連絡した PingCAP テクニカル サポート スタッフにリンクを送信することができます。 +3. アップロードが完了したら、 `Download URL`のリンクを開いてアップロードされたデータを確認するか、以前に連絡した PingCAP テクニカル サポート スタッフにリンクを送信することができます。 ## ローカルでクラスタのステータスをクイックチェックする {#perform-a-quick-check-on-the-cluster-status-locally} Diag を使用すると、クラスタの状態をローカルで簡単に確認できます。クラスタが現在安定して動作している場合でも、潜在的な安定性リスクを検出するために、定期的にクラスタの状態を確認する必要があります。PingCAP Clinicが提供するローカルクイックチェック機能を使用すると、クラスタの潜在的なヘルスリスクを特定できます。ローカルチェックでは構成のみがチェックされます。メトリックやログなど、より多くの項目を確認するには、診断データを Clinic Serverにアップロードし、ヘルスレポート機能を使用することをお勧めします。 -1. 構成データを収集します。 +1. 構成データを収集します。 ```bash tiup diag collect ${cluster-name} --include="config" @@ -294,7 +294,7 @@ Diag を使用すると、クラスタの状態をローカルで簡単に確認 設定ファイルのデータは比較的小さく、収集後、デフォルトで現在のパスに保存されます。テスト環境では、18ノードのクラスタの場合、設定ファイルのデータサイズは10KB未満でした。 -2. 構成データを診断します。 +2. 構成データを診断します。 ```bash tiup diag check ${subdir-in-output-data} @@ -302,7 +302,7 @@ Diag を使用すると、クラスタの状態をローカルで簡単に確認 上記コマンドの`${subdir-in-output-data}`は収集したデータを保存するパスであり、このパスには`meta.yaml`ファイルがあります。 -3. 診断結果を表示する: +3. 診断結果を表示する: 診断結果はコマンドラインに返されます。例: @@ -354,14 +354,14 @@ Diag を使用すると、クラスタの状態をローカルで簡単に確認 ## FAQ {#faq} -1. データのアップロードに失敗した場合、再度アップロードできますか？ +1. データのアップロードに失敗した場合、再度アップロードできますか？ はい。データのアップロードはブレークポイントアップロードをサポートしています。アップロードに失敗した場合は、直接再度アップロードできます。 -2. データをアップロードした後、返されたデータアクセスリンクを開くことができません。どうすればよいでしょうか？ +2. データをアップロードした後、返されたデータアクセスリンクを開くことができません。どうすればよいでしょうか？ まずClinic Serverにログインしてください。ログインに成功してもリンクを開けない場合は、データへのアクセス権があるかどうかを確認してください。アクセス権がない場合は、データ所有者に連絡して許可を得てください。許可を得た後、Clinic Serverにログインしてリンクを再度開いてください。 -3. アップロードされたデータはClinic Serverにどのくらいの期間保存されますか? +3. アップロードされたデータはClinic Serverにどのくらいの期間保存されますか? 最長期間は180日間です。Clinic Serverページでアップロードしたデータはいつでも削除できます。 diff --git a/clinic/quick-start-with-clinic.md b/clinic/quick-start-with-clinic.md index fab091e669d92..1fbcae654b472 100644 --- a/clinic/quick-start-with-clinic.md +++ b/clinic/quick-start-with-clinic.md @@ -11,25 +11,25 @@ PingCAP Clinicは、 [Diagクライアント](https://github.com/pingcap/diag) ## ユーザーシナリオ {#user-scenarios} -- PingCAP テクニカル サポートからリモートで支援を受ける際にクラスターの問題を正確に特定し、迅速に解決するには、Diag を使用して診断データを収集し、収集したデータを Clinic Server にアップロードして、データ アクセス リンクをテクニカル サポートに提供することができます。 -- クラスターが正常に実行されており、クラスターのステータスを確認する必要がある場合は、Diag を使用して診断データを収集し、そのデータを Clinic Server にアップロードして、Health Report の結果を表示できます。 +- PingCAP テクニカル サポートからリモートで支援を受ける際にクラスターの問題を正確に特定し、迅速に解決するには、Diag を使用して診断データを収集し、収集したデータを Clinic Server にアップロードして、データ アクセス リンクをテクニカル サポートに提供することができます。 +- クラスターが正常に実行されており、クラスターのステータスを確認する必要がある場合は、Diag を使用して診断データを収集し、そのデータを Clinic Server にアップロードして、Health Report の結果を表示できます。 > **Note:** > -> - 以下のデータ収集およびアップロード方法は[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によって収集された診断データは、クラスターの問題のトラブルシューティングに**のみ**使用されます。 +> - 以下のデータ収集およびアップロード方法は[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} PingCAP Clinicを使用する前に、Diag をインストールし、データをアップロードするための環境を準備する必要があります。 -1. TiUPがインストールされているコントロール マシンで、次のコマンドを実行して Diag をインストールします。 +1. TiUPがインストールされているコントロール マシンで、次のコマンドを実行して Diag をインストールします。 ```bash tiup install diag ``` -2. Clinic Serverにログインします。 +2. Clinic Serverにログインします。
@@ -47,33 +47,33 @@ PingCAP Clinicを使用する前に、Diag をインストールし、データ
-3. Clinic Server 上に組織を作成します。組織は TiDB クラスターの集合です。作成した組織に診断データをアップロードできます。 +3. Clinic Server 上に組織を作成します。組織は TiDB クラスターの集合です。作成した組織に診断データをアップロードできます。 -4. データをアップロードするには、アクセストークンを取得してください。Diag を通じて収集したデータをアップロードする際は、データが安全に分離されていることを確認するために、ユーザー認証用のトークンが必要です。Clinic Serverから既にトークンを取得している場合は、そのトークンを再利用できます。 +4. データをアップロードするには、アクセストークンを取得してください。Diag を通じて収集したデータをアップロードする際は、データが安全に分離されていることを確認するために、ユーザー認証用のトークンが必要です。Clinic Serverから既にトークンを取得している場合は、そのトークンを再利用できます。 ![An example of a token](/media/clinic-get-token.png) > **Note:** > - > - データセキュリティのため、TiDBはトークン作成時にのみトークン情報を表示します。トークン情報を紛失した場合は、古いトークンを削除して新しいトークンを作成できます。 - > - トークンはデータのアップロードにのみ使用されます。 + > - データセキュリティのため、TiDBはトークン作成時にのみトークン情報を表示します。トークン情報を紛失した場合は、古いトークンを削除して新しいトークンを作成できます。 + > - トークンはデータのアップロードにのみ使用されます。 -5. Diag にトークンと`region`設定します。 +5. Diag にトークンと`region`設定します。 - - `clinic.token`設定するには、次のコマンドを実行します。 + - `clinic.token`設定するには、次のコマンドを実行します。 ```bash tiup diag config clinic.token ${token-value} ``` - - `clinic.region`設定するには、次のコマンドを実行します。 + - `clinic.region`設定するには、次のコマンドを実行します。 `region` 、データの圧縮に使用する暗号化証明書と、データのアップロード時に使用する対象サービスを決定します。例: > **Note:** > - > - Diag v0.9.0 以降のバージョンでは設定`region`サポートされます。 - > - Diag v0.9.0より前のバージョンでは、データはデフォルトで中国リージョンのClinic Serverにアップロードされます。これらのバージョンで`region`設定するには、 `tiup update diag`コマンドを実行してDiagを最新バージョンにアップグレードし、その後Diagで`region`設定してください。 + > - Diag v0.9.0 以降のバージョンでは設定`region`サポートされます。 + > - Diag v0.9.0より前のバージョンでは、データはデフォルトで中国リージョンのClinic Serverにアップロードされます。これらのバージョンで`region`設定するには、 `tiup update diag`コマンドを実行してDiagを最新バージョンにアップグレードし、その後Diagで`region`設定してください。
@@ -97,13 +97,13 @@ PingCAP Clinicを使用する前に、Diag をインストールし、データ -6. (オプション) ログの秘匿化を有効にします。 +6. (オプション) ログの秘匿化を有効にします。 TiDBが詳細なログ情報を提供する場合、ログに機密情報（ユーザーデータなど）が出力される可能性があります。ローカルログおよびClinic Serverへの機密情報の漏洩を防ぎたい場合は、TiDB側でログの秘匿化を有効にすることができます。詳細については、 [ログの秘匿化](/log-redaction.md#log-redaction-in-tidb-side)をご覧ください。 ## 手順 {#steps} -1. Diag を実行して診断データを収集します。 +1. Diag を実行して診断データを収集します。 たとえば、現在の時刻に基づいて 4 時間前から 2 時間前までの診断データを収集するには、次のコマンドを実行します。 @@ -115,13 +115,13 @@ PingCAP Clinicを使用する前に、Diag をインストールし、データ 収集が完了すると、Diag は収集されたデータが保存されているフォルダー パスを提供します。 -2. 収集したデータをClinic Serverにアップロードします。 +2. 収集したデータをClinic Serverにアップロードします。 > **Note:** > > アップロードするデータ（収集されたデータを含む圧縮ファイル）のサイズは3GB**以下に**してください。3GBを超える場合、データのアップロードは失敗します。 - - クラスターが配置されているネットワークがインターネットにアクセスできる場合は、次のコマンドを使用して、収集されたデータを含むフォルダーを直接アップロードできます。 + - クラスターが配置されているネットワークがインターネットにアクセスできる場合は、次のコマンドを使用して、収集されたデータを含むフォルダーを直接アップロードできます。 ```bash tiup diag upload ${filepath} @@ -133,20 +133,20 @@ PingCAP Clinicを使用する前に、Diag をインストールし、データ > > この方法でデータをアップロードする場合は、Diag v0.9.0以降のバージョンを使用する必要があります。Diagのバージョンは実行時に取得できます。Diagのバージョンが0.9.0より前のバージョンの場合は、 `tiup update diag`コマンドを使用してDiagを最新バージョンにアップグレードできます。 - - クラスターが設置されているネットワークがインターネットにアクセスできない場合は、収集したデータをパックしてアップロードする必要があります。詳細は[方法2. データをパックしてアップロードする](/clinic/clinic-user-guide-for-tiup.md#method-2-pack-and-upload-data)ご覧ください。 + - クラスターが設置されているネットワークがインターネットにアクセスできない場合は、収集したデータをパックしてアップロードする必要があります。詳細は[方法2. データをパックしてアップロードする](/clinic/clinic-user-guide-for-tiup.md#method-2-pack-and-upload-data)ご覧ください。 -3. アップロードが完了したら、コマンド出力の`Download URL`からデータ アクセス リンクを取得します。 +3. アップロードが完了したら、コマンド出力の`Download URL`からデータ アクセス リンクを取得します。 デフォルトでは、診断データには、クラスター名、クラスター トポロジ情報、収集された診断データ内のログ コンテンツ、収集されたデータ内のメトリックに基づいて再構成された Grafana ダッシュボード情報が含まれます。 データを使用してクラスターの問題を自分でトラブルシューティングすることも、PingCAP テクニカル サポート スタッフにデータ アクセス リンクを提供してリモート トラブルシューティングを容易にすることもできます。 -4. ヘルスレポートの結果を表示する +4. ヘルスレポートの結果を表示する データがアップロードされると、Clinic Server はバックグラウンドで自動的にデータを処理します。ヘルスレポートは約5～15分で生成されます。診断データリンクを開き、「ヘルスレポート」をクリックすると、レポートをご覧いただけます。 ## 次は何？ {#what-s-next} -- [PingCAP Clinicの概要](/clinic/clinic-introduction.md) -- [PingCAP Clinicを使用したクラスターのトラブルシューティング](/clinic/clinic-user-guide-for-tiup.md) -- [PingCAP Clinic診断データ](/clinic/clinic-data-instruction-for-tiup.md) +- [PingCAP Clinicの概要](/clinic/clinic-introduction.md) +- [PingCAP Clinicを使用したクラスターのトラブルシューティング](/clinic/clinic-user-guide-for-tiup.md) +- [PingCAP Clinic診断データ](/clinic/clinic-data-instruction-for-tiup.md) diff --git a/clustered-indexes.md b/clustered-indexes.md index a42ea41c0ba64..34fdd6a8e74db 100644 --- a/clustered-indexes.md +++ b/clustered-indexes.md @@ -11,11 +11,11 @@ TiDBはバージョン5.0以降、クラスター化インデックス機能を 現在、TiDBの主キーを含むテーブルは、以下の2つのカテゴリに分類されます。 -- `NONCLUSTERED` : テーブルの主キーは非クラスター化インデックスです。非クラスター化インデックスを持つテーブルでは、行データのキーは、TiDB によって暗黙的に割り当てられる内部の[`_tidb_rowid`](/tidb-rowid.md)値で構成されます。主キーは基本的に一意インデックスであるため、非クラスター化インデックスを持つテーブルでは、行を格納するために少なくとも 2 つのキーと値のペアが必要です。それらは次のとおりです。 - - `_tidb_rowid` （キー） - 行データ（値） - - 主キーデータ（キー） - `_tidb_rowid` （値） -- `CLUSTERED` : テーブルの主キーはクラスター化インデックスです。クラスター化インデックスを持つテーブルでは、行データのキーはユーザーが指定した主キーデータで構成されます。したがって、クラスター化インデックスを持つテーブルでは、行を格納するために必要なキーと値のペアは1つだけです。それは次のとおりです。 - - 主キーデータ（キー） - 行データ（値） +- `NONCLUSTERED` : テーブルの主キーは非クラスター化インデックスです。非クラスター化インデックスを持つテーブルでは、行データのキーは、TiDB によって暗黙的に割り当てられる内部の[`_tidb_rowid`](/tidb-rowid.md)値で構成されます。主キーは基本的に一意インデックスであるため、非クラスター化インデックスを持つテーブルでは、行を格納するために少なくとも 2 つのキーと値のペアが必要です。それらは次のとおりです。 + - `_tidb_rowid` （キー） - 行データ（値） + - 主キーデータ（キー） - `_tidb_rowid` （値） +- `CLUSTERED` : テーブルの主キーはクラスター化インデックスです。クラスター化インデックスを持つテーブルでは、行データのキーはユーザーが指定した主キーデータで構成されます。したがって、クラスター化インデックスを持つテーブルでは、行を格納するために必要なキーと値のペアは1つだけです。それは次のとおりです。 + - 主キーデータ（キー） - 行データ（値） > **Note:** > @@ -25,15 +25,15 @@ TiDBはバージョン5.0以降、クラスター化インデックス機能を クラスター化インデックスを持たないテーブルと比較して、クラスター化インデックスを持つテーブルは、以下のシナリオにおいて、より優れたパフォーマンスとスループットのメリットを提供します。 -- データが挿入される際、クラスター化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 -- 同等の条件を持つクエリが主キーのみに関係する場合、クラスター化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 -- 範囲条件を含むクエリが主キーのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 -- 同等条件または範囲条件を含むクエリが主キーのプレフィックスのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの複数回の読み取りを削減します。 +- データが挿入される際、クラスター化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 +- 同等の条件を持つクエリが主キーのみに関係する場合、クラスター化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 +- 範囲条件を含むクエリが主キーのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 +- 同等条件または範囲条件を含むクエリが主キーのプレフィックスのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの複数回の読み取りを削減します。 一方、クラスター化インデックスを持つテーブルにはいくつかの欠点があります。以下をご覧ください。 -- 値が近い多数の主キーを挿入する場合、書き込みホットスポットの問題が発生する可能性があります。 -- 主キーのデータ型が64ビットより大きい場合、特にセカンダリインデックスが複数存在する場合は、テーブルデータがより多くのストレージ容量を消費します。 +- 値が近い多数の主キーを挿入する場合、書き込みホットスポットの問題が発生する可能性があります。 +- 主キーのデータ型が64ビットより大きい場合、特にセカンダリインデックスが複数存在する場合は、テーブルデータがより多くのストレージ容量を消費します。 ## 使用例 {#usages} @@ -63,9 +63,9 @@ CREATE TABLE t (a BIGINT, b VARCHAR(255), PRIMARY KEY(a, b) /*T![clustered_index キーワード`CLUSTERED` / `NONCLUSTERED`を明示的に指定しないステートメントの場合、デフォルトの動作はシステム変数[`@@global.tidb_enable_clustered_index`](/system-variables.md#tidb_enable_clustered_index-new-in-v50)によって制御されます。この変数でサポートされている値は次のとおりです。 -- `OFF`は、主キーがデフォルトで非クラスター化インデックスとして作成されることを示します。 -- `ON`は、主キーがデフォルトでクラスター化インデックスとして作成されることを示します。 -- `INT_ONLY`は、動作が構成項目`alter-primary-key`によって制御されることを示します。 `alter-primary-key`が`true`に設定されている場合、プライマリ キーはデフォルトで非クラスター化インデックスとして作成されます。 `false`に設定されている場合、整数列で構成されるプライマリ キーのみがクラスター化インデックスとして作成されます。 +- `OFF`は、主キーがデフォルトで非クラスター化インデックスとして作成されることを示します。 +- `ON`は、主キーがデフォルトでクラスター化インデックスとして作成されることを示します。 +- `INT_ONLY`は、動作が構成項目`alter-primary-key`によって制御されることを示します。 `alter-primary-key`が`true`に設定されている場合、プライマリ キーはデフォルトで非クラスター化インデックスとして作成されます。 `false`に設定されている場合、整数列で構成されるプライマリ キーのみがクラスター化インデックスとして作成されます。 `@@global.tidb_enable_clustered_index`のデフォルト値は`ON`です。 @@ -94,9 +94,9 @@ ALTER TABLE t DROP INDEX `PRIMARY`; テーブルの主キーがクラスター化インデックスであるかどうかは、以下のいずれかの方法で確認できます。 -- コマンド`SHOW CREATE TABLE`を実行します。 -- コマンド`SHOW INDEX FROM`を実行します。 -- システムテーブル`information_schema.tables`の`TIDB_PK_TYPE`列をクエリします。 +- コマンド`SHOW CREATE TABLE`を実行します。 +- コマンド`SHOW INDEX FROM`を実行します。 +- システムテーブル`information_schema.tables`の`TIDB_PK_TYPE`列をクエリします。 コマンド`SHOW CREATE TABLE`を実行すると、 `PRIMARY KEY`の属性が`CLUSTERED`か`NONCLUSTERED`かを確認できます。例: @@ -142,11 +142,11 @@ mysql> SELECT TIDB_PK_TYPE FROM information_schema.tables WHERE table_schema = ' 現在、クラスター化インデックス機能にはいくつかの異なる制限があります。以下を参照してください。 -- サポート対象外であり、サポートプランにも含まれていない状況： - - クラスター化インデックスと属性[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)を併用することはサポートされていません。また、属性[`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions)は、 [`AUTO_RANDOM`](/auto-random.md)ではないクラスター化インデックスを持つテーブルには適用されません。 - - クラスター化インデックスを持つテーブルのダウングレードはサポートされていません。そのようなテーブルをダウングレードする必要がある場合は、代わりに論理バックアップツールを使用してデータを移行してください。 -- まだサポートされていないが、サポート計画に含まれている状況： - - `ALTER TABLE`ステートメントを使用したクラスター化インデックスの追加、削除、および変更はサポートされていません。 +- サポート対象外であり、サポートプランにも含まれていない状況： + - クラスター化インデックスと属性[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)を併用することはサポートされていません。また、属性[`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions)は、 [`AUTO_RANDOM`](/auto-random.md)ではないクラスター化インデックスを持つテーブルには適用されません。 + - クラスター化インデックスを持つテーブルのダウングレードはサポートされていません。そのようなテーブルをダウングレードする必要がある場合は、代わりに論理バックアップツールを使用してデータを移行してください。 +- まだサポートされていないが、サポート計画に含まれている状況： + - `ALTER TABLE`ステートメントを使用したクラスター化インデックスの追加、削除、および変更はサポートされていません。 クラスター化インデックスを属性`SHARD_ROW_ID_BITS`と一緒に使用すると、TiDB は次のエラーを報告します。 @@ -163,9 +163,9 @@ TiDBは、クラスター化インデックスを持つテーブルのアップ クラスター化インデックス機能は、TiDB v3.0およびv4.0で部分的にサポートされています。以下の要件がすべて満たされている場合、デフォルトで有効になります。 -- テーブルには`PRIMARY KEY`が含まれています。 -- `PRIMARY KEY`は 1 つの列のみで構成されています。 -- `PRIMARY KEY`は`INTEGER`です。 +- テーブルには`PRIMARY KEY`が含まれています。 +- `PRIMARY KEY`は 1 つの列のみで構成されています。 +- `PRIMARY KEY`は`INTEGER`です。 TiDB v5.0 以降、クラスター化インデックス機能はすべてのタイプの主キーに対して完全にサポートされていますが、デフォルトの動作は TiDB v3.0 および v4.0 と一貫しています。デフォルトの動作を変更するには、システム変数`@@tidb_enable_clustered_index`を`ON`または`OFF`に設定します。詳細については、[クラスター化インデックスを持つテーブルを作成する](#create-a-table-with-clustered-indexes)を参照してください。 @@ -177,8 +177,8 @@ TiDB固有のコメント構文では、キーワード`CLUSTERED`と`NONCLUSTER クラスター化インデックス機能は、v5.0以降のバージョンにおいて、以下の移行ツールとのみ互換性があります。 -- バックアップおよび復元ツール： BR、 Dumpling、 TiDB Lightning。 -- データ移行およびレプリケーションツール：DMとTiCDC。 +- バックアップおよび復元ツール： BR、 Dumpling、 TiDB Lightning。 +- データ移行およびレプリケーションツール：DMとTiCDC。 ただし、v5.0 BRツールを使用してテーブルをバックアップおよび復元しても、非クラスター化インデックスを持つテーブルをクラスター化インデックスを持つテーブルに変換することはできません。また、その逆も同様です。 diff --git a/column-privilege-management.md b/column-privilege-management.md index ab9fbaa0ed7da..48852d7e68be3 100644 --- a/column-privilege-management.md +++ b/column-privilege-management.md @@ -15,8 +15,8 @@ summary: TiDBは、MySQL互換の列レベルの権限管理メカニズムを 列レベルの権限を付与および取り消すための構文は、テーブルレベルの権限の構文と似ていますが、以下の点が異なります。 -- 列名リストは**、テーブル名**の後ではなく、**権限タイプ**の後に記述してください。 -- 複数の列名はカンマで区切られます（ `,` ）。 +- 列名リストは**、テーブル名**の後ではなく、**権限タイプ**の後に記述してください。 +- 複数の列名はカンマで区切られます（ `,` ）。 ```sql GRANT priv_type(col_name [, col_name] ...) [, priv_type(col_name [, col_name] ...)] ... @@ -30,9 +30,9 @@ REVOKE priv_type(col_name [, col_name] ...) [, priv_type(col_name [, col_name] . どこ： -- `priv_type`は`SELECT` 、 `INSERT` 、 `UPDATE` 、および`REFERENCES` 。 -- `ON`句では、例えば`test.tbl`のようにテーブルを指定する必要があります。 -- 単一の`GRANT`または`REVOKE`ステートメントには、複数の特権項目を含めることができ、各特権項目は独自の列名のリストを指定できます。 +- `priv_type`は`SELECT` 、 `INSERT` 、 `UPDATE` 、および`REFERENCES` 。 +- `ON`句では、例えば`test.tbl`のようにテーブルを指定する必要があります。 +- 単一の`GRANT`または`REVOKE`ステートメントには、複数の特権項目を含めることができ、各特権項目は独自の列名のリストを指定できます。 例えば、次のステートメントは`SELECT`の`col1`に対する権限と、 `col2`の`UPDATE`の`col3`に対する権限をユーザーに付与します。 @@ -91,9 +91,9 @@ SHOW GRANTS FOR 'newuser'@'%'; 列レベルの権限を付与または取り消した後、TiDB は SQL ステートメントで参照されている列に対して権限チェックを実行します。例: -- `SELECT`ステートメント: `SELECT`列の権限は、 `SELECT`リストで参照される列、および`WHERE` 、 `ORDER BY` 、その他の句に影響します。 -- `UPDATE`ステートメント: `SET`句で更新される列には`UPDATE`列権限が必要です。式または条件で読み込まれる列には、通常、 `SELECT`列権限も必要です。 -- `INSERT`ステートメント: `INSERT`列の権限を必要とする列が書き込まれます。 `INSERT INTO t VALUES (...)`テーブル定義の順序ですべての列に値を書き込むことと同じです。 +- `SELECT`ステートメント: `SELECT`列の権限は、 `SELECT`リストで参照される列、および`WHERE` 、 `ORDER BY` 、その他の句に影響します。 +- `UPDATE`ステートメント: `SET`句で更新される列には`UPDATE`列権限が必要です。式または条件で読み込まれる列には、通常、 `SELECT`列権限も必要です。 +- `INSERT`ステートメント: `INSERT`列の権限を必要とする列が書き込まれます。 `INSERT INTO t VALUES (...)`テーブル定義の順序ですべての列に値を書き込むことと同じです。 次の例では、ユーザー`newuser`は`col1`を照会し、 `col3`を更新することしかできません。 @@ -123,8 +123,8 @@ TiDBの列レベルの権限は、一般的にMySQLと互換性があります ビューに対して`SELECT`権限チェックを実行する場合、MySQLとTiDBでは以下の点が異なります。 -- MySQLはまずビューの内部クエリ内の列を削除し、次に内部テーブルの列権限をチェックするため、状況によってはチェックが比較的緩やかになる場合があります。 -- TiDBは権限チェックの前に列の削除を行わないため、追加の列権限が必要になる場合があります。 +- MySQLはまずビューの内部クエリ内の列を削除し、次に内部テーブルの列権限をチェックするため、状況によってはチェックが比較的緩やかになる場合があります。 +- TiDBは権限チェックの前に列の削除を行わないため、追加の列権限が必要になる場合があります。 ```sql -- Prepare the environment by logging in as root @@ -167,6 +167,6 @@ SELECT * FROM v; ## 関連項目 {#see-also} -- [権限管理](/privilege-management.md) -- [`GRANT `](/sql-statements/sql-statement-grant-privileges.md) -- [`REVOKE `](/sql-statements/sql-statement-revoke-privileges.md) +- [権限管理](/privilege-management.md) +- [`GRANT `](/sql-statements/sql-statement-grant-privileges.md) +- [`REVOKE `](/sql-statements/sql-statement-revoke-privileges.md) diff --git a/command-line-flags-for-pd-configuration.md b/command-line-flags-for-pd-configuration.md index ae82e145085ed..ceedfe9bdc7b4 100644 --- a/command-line-flags-for-pd-configuration.md +++ b/command-line-flags-for-pd-configuration.md @@ -9,47 +9,47 @@ PD は、コマンドラインフラグと環境変数を使用して構成で ## `--advertise-client-urls` {#advertise-client-urls} -- クライアントがPDにアクセスするためのアドバタイズURLのリスト -- デフォルト: `"${client-urls}"` -- Docker または NAT ネットワーク環境などの状況では、クライアントが PD がリッスンするデフォルトのクライアント URL を通じて PD にアクセスできない場合は、アドバタイズ クライアント URL を手動で設定する必要があります。 -- 例えば、Dockerの内部IPアドレスは`172.17.0.1` 、ホストのIPアドレスは`192.168.100.113` 、ポートマッピングは`-p 2379:2379`に設定されています。この場合、 `--advertise-client-urls`を`"http://192.168.100.113:2379"`に設定できます。クライアントは`"http://192.168.100.113:2379"`を通じてこのサービスを見つけられます。 +- クライアントがPDにアクセスするためのアドバタイズURLのリスト +- デフォルト: `"${client-urls}"` +- Docker または NAT ネットワーク環境などの状況では、クライアントが PD がリッスンするデフォルトのクライアント URL を通じて PD にアクセスできない場合は、アドバタイズ クライアント URL を手動で設定する必要があります。 +- 例えば、Dockerの内部IPアドレスは`172.17.0.1` 、ホストのIPアドレスは`192.168.100.113` 、ポートマッピングは`-p 2379:2379`に設定されています。この場合、 `--advertise-client-urls`を`"http://192.168.100.113:2379"`に設定できます。クライアントは`"http://192.168.100.113:2379"`を通じてこのサービスを見つけられます。 ## `--advertise-peer-urls` {#advertise-peer-urls} -- 他のPDノード（ピア）がPDノードにアクセスするためのアドバタイズURLのリスト -- デフォルト: `"${peer-urls}"` -- Docker または NAT ネットワーク環境などの状況では、他のノード (ピア) がこの PD ノードによってリッスンされるデフォルトのピア URL を介して PD ノードにアクセスできない場合は、アドバタイズ ピア URL を手動で設定する必要があります。 -- 例えば、Dockerの内部IPアドレスが`172.17.0.1`で、ホストのIPアドレスが`192.168.100.113` 、ポートマッピングが`-p 2380:2380`に設定されている場合、 `--advertise-peer-urls`を`"http://192.168.100.113:2380"`に設定できます。他のPDノードは`"http://192.168.100.113:2380"`を介してこのサービスを検出できます。 +- 他のPDノード（ピア）がPDノードにアクセスするためのアドバタイズURLのリスト +- デフォルト: `"${peer-urls}"` +- Docker または NAT ネットワーク環境などの状況では、他のノード (ピア) がこの PD ノードによってリッスンされるデフォルトのピア URL を介して PD ノードにアクセスできない場合は、アドバタイズ ピア URL を手動で設定する必要があります。 +- 例えば、Dockerの内部IPアドレスが`172.17.0.1`で、ホストのIPアドレスが`192.168.100.113` 、ポートマッピングが`-p 2380:2380`に設定されている場合、 `--advertise-peer-urls`を`"http://192.168.100.113:2380"`に設定できます。他のPDノードは`"http://192.168.100.113:2380"`を介してこのサービスを検出できます。 ## `--client-urls` {#client-urls} -- PDがリッスンするクライアントURLのリスト -- デフォルト: `"http://127.0.0.1:2379"` -- クラスターをデプロイする際は、現在のホストのIPアドレスを`--client-urls` （例： `"http://192.168.100.113:2379"` ）に指定する必要があります。クラスターをDocker上で実行する場合は、DockerのIPアドレスを`"http://0.0.0.0:2379"`に指定してください。 +- PDがリッスンするクライアントURLのリスト +- デフォルト: `"http://127.0.0.1:2379"` +- クラスターをデプロイする際は、現在のホストのIPアドレスを`--client-urls` （例： `"http://192.168.100.113:2379"` ）に指定する必要があります。クラスターをDocker上で実行する場合は、DockerのIPアドレスを`"http://0.0.0.0:2379"`に指定してください。 ## `--peer-urls` {#peer-urls} -- PDノードがリッスンするピアURLのリスト -- デフォルト: `"http://127.0.0.1:2380"` -- クラスターをデプロイする際は、現在のホストのIPアドレスを`--peer-urls` （例： `"http://192.168.100.113:2380"`に指定する必要があります。クラスターがDocker上で実行される場合は、DockerのIPアドレスを`"http://0.0.0.0:2380"`に指定してください。 +- PDノードがリッスンするピアURLのリスト +- デフォルト: `"http://127.0.0.1:2380"` +- クラスターをデプロイする際は、現在のホストのIPアドレスを`--peer-urls` （例： `"http://192.168.100.113:2380"`に指定する必要があります。クラスターがDocker上で実行される場合は、DockerのIPアドレスを`"http://0.0.0.0:2380"`に指定してください。 ## `--config` {#config} -- 設定ファイル -- デフォルト: `""` -- コマンドラインを使用して設定を行った場合、設定ファイル内の同じ設定が上書きされます。 +- 設定ファイル +- デフォルト: `""` +- コマンドラインを使用して設定を行った場合、設定ファイル内の同じ設定が上書きされます。 ## `--data-dir` {#data-dir} -- データディレクトリへのパス -- デフォルト: `"default.${name}"` +- データディレクトリへのパス +- デフォルト: `"default.${name}"` ## `--initial-cluster` {#initial-cluster} -- ブートストラップのための初期クラスタ構成 -- デフォルト: `"{name}=http://{advertise-peer-url}"` -- たとえば、 `name`が「pd」、 `advertise-peer-urls`が`"http://192.168.100.113:2380"`の場合、 `initial-cluster`は`"pd=http://192.168.100.113:2380"`なります。 -- 3 つの PD サーバーを起動する必要がある場合、 `initial-cluster`は次のようになります。 +- ブートストラップのための初期クラスタ構成 +- デフォルト: `"{name}=http://{advertise-peer-url}"` +- たとえば、 `name`が「pd」、 `advertise-peer-urls`が`"http://192.168.100.113:2380"`の場合、 `initial-cluster`は`"pd=http://192.168.100.113:2380"`なります。 +- 3 つの PD サーバーを起動する必要がある場合、 `initial-cluster`は次のようになります。 ``` pd1=http://192.168.100.113:2380, pd2=http://192.168.100.114:2380, pd3=192.168.100.115:2380 @@ -57,50 +57,50 @@ PD は、コマンドラインフラグと環境変数を使用して構成で ## `--join` {#join} -- クラスターに動的に参加する -- デフォルト: `""` -- 既存のクラスターに参加する場合は、 `--join="${advertise-client-urls}"`を使用できます。 `advertise-client-url`は既存の PD のいずれかで、複数のアドバタイズ クライアント URL はコンマで区切られます。 +- クラスターに動的に参加する +- デフォルト: `""` +- 既存のクラスターに参加する場合は、 `--join="${advertise-client-urls}"`を使用できます。 `advertise-client-url`は既存の PD のいずれかで、複数のアドバタイズ クライアント URL はコンマで区切られます。 ## `-L` {#l} -- ログレベル -- デフォルト: `"info"` -- `"warn"` `"fatal"` `"error"` `"debug"` `"info"` +- ログレベル +- デフォルト: `"info"` +- `"warn"` `"fatal"` `"error"` `"debug"` `"info"` ## `--log-file` {#log-file} -- ログファイル -- デフォルト: `""` -- このフラグが設定されていない場合、ログは「stderr」に書き込まれます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 +- ログファイル +- デフォルト: `""` +- このフラグが設定されていない場合、ログは「stderr」に書き込まれます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 ## `--log-rotate` {#log-rotate} -- ログローテーションを有効または無効にするには -- デフォルト: `true` -- 値が true の場合、PD 構成ファイルの`[log.file]`に従います。 +- ログローテーションを有効または無効にするには +- デフォルト: `true` +- 値が true の場合、PD 構成ファイルの`[log.file]`に従います。 ## `--name` {#name} -- このPDメンバーの人間が読める一意の名前 -- デフォルト: `"pd-${hostname}"` -- 複数の PD を開始する場合は、それぞれに異なる名前を使用する必要があります。 +- このPDメンバーの人間が読める一意の名前 +- デフォルト: `"pd-${hostname}"` +- 複数の PD を開始する場合は、それぞれに異なる名前を使用する必要があります。 ## `--cacert` {#cacert} -- TLSを有効にするために使用されるCAのファイルパス -- デフォルト: `""` +- TLSを有効にするために使用されるCAのファイルパス +- デフォルト: `""` ## `--cert` {#cert} -- TLSを有効にするために使用されるX509証明書を含むPEMファイルのパス -- デフォルト: `""` +- TLSを有効にするために使用されるX509証明書を含むPEMファイルのパス +- デフォルト: `""` ## `--key` {#key} -- TLSを有効にするために使用されるX509キーを含むPEMファイルのパス -- デフォルト: `""` +- TLSを有効にするために使用されるX509キーを含むPEMファイルのパス +- デフォルト: `""` ## `--metrics-addr` {#metrics-addr} -- デフォルトでは Prometheus にデータをプッシュしない Prometheus Pushgateway のアドレス。 -- デフォルト: `""` +- デフォルトでは Prometheus にデータをプッシュしない Prometheus Pushgateway のアドレス。 +- デフォルト: `""` diff --git a/command-line-flags-for-scheduling-configuration.md b/command-line-flags-for-scheduling-configuration.md index 387e62e9700be..46bcca783e32f 100644 --- a/command-line-flags-for-scheduling-configuration.md +++ b/command-line-flags-for-scheduling-configuration.md @@ -9,66 +9,66 @@ summary: スケジュール構成フラグは、コマンド ライン フラグ ## `--advertise-listen-addr` {#advertise-listen-addr} -- クライアントがスケジューリング ノードにアクセスするための URL。 -- デフォルト: `${listen-addr}` -- Docker や NAT ネットワーク環境などの状況では、クライアントが`scheduling`でリッスンされるデフォルトのクライアント URL を通じてスケジューリング ノードにアクセスできない場合は、クライアント アクセス用に`--advertise-listen-addr`手動で設定する必要があります。 -- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 3379:3379`に設定されています。この場合、 `--advertise-listen-addr="http://192.168.100.113:3379"`設定できます。そうすることで、クライアントは`http://192.168.100.113:3379`を通じてこのサービスを見つけることができるようになります。 +- クライアントがスケジューリング ノードにアクセスするための URL。 +- デフォルト: `${listen-addr}` +- Docker や NAT ネットワーク環境などの状況では、クライアントが`scheduling`でリッスンされるデフォルトのクライアント URL を通じてスケジューリング ノードにアクセスできない場合は、クライアント アクセス用に`--advertise-listen-addr`手動で設定する必要があります。 +- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 3379:3379`に設定されています。この場合、 `--advertise-listen-addr="http://192.168.100.113:3379"`設定できます。そうすることで、クライアントは`http://192.168.100.113:3379`を通じてこのサービスを見つけることができるようになります。 ## `--backend-endpoints` {#backend-endpoints} -- 現在のスケジューリング ノードがリッスンする他のスケジューリング ノードのバックエンド エンドポイントのリスト。 -- デフォルト: `http://127.0.0.1:2379` +- 現在のスケジューリング ノードがリッスンする他のスケジューリング ノードのバックエンド エンドポイントのリスト。 +- デフォルト: `http://127.0.0.1:2379` ## `--cacert` {#cacert} -- TLS を有効にするために使用される CA のファイル パス。 -- デフォルト: `""` +- TLS を有効にするために使用される CA のファイル パス。 +- デフォルト: `""` ## `--cert` {#cert} -- TLS を有効にするために使用される、X.509 証明書を含む PEM ファイルのパス。 -- デフォルト: `""` +- TLS を有効にするために使用される、X.509 証明書を含む PEM ファイルのパス。 +- デフォルト: `""` ## `--config` {#config} -- 設定ファイル。 -- デフォルト: `""` -- 設定ファイルを指定すると、スケジューリングノードはまずそのファイルから設定を読み取ります。同じ設定がコマンドラインフラグでも指定されている場合、スケジューリングノードはコマンドラインフラグの設定を使用して設定ファイルの設定を上書きします。 +- 設定ファイル。 +- デフォルト: `""` +- 設定ファイルを指定すると、スケジューリングノードはまずそのファイルから設定を読み取ります。同じ設定がコマンドラインフラグでも指定されている場合、スケジューリングノードはコマンドラインフラグの設定を使用して設定ファイルの設定を上書きします。 ## `--data-dir` {#data-dir} -- スケジューリング ノード上のデータ ディレクトリへのパス。 -- デフォルト: `"default.${name}"` +- スケジューリング ノード上のデータ ディレクトリへのパス。 +- デフォルト: `"default.${name}"` ## `--key` {#key} -- TLS を有効にするために使用される、X.509 キーを含む PEM ファイルのパス。 -- デフォルト: `""` +- TLS を有効にするために使用される、X.509 キーを含む PEM ファイルのパス。 +- デフォルト: `""` ## `--listen-addr` {#listen-addr} -- 現在のスケジューリング ノードがリッスンするクライアント URL。 -- デフォルト: `"http://127.0.0.1:3379"` -- クラスターをデプロイする際は、現在のホストのIPアドレスを`--listen-addr` （例： `"http://192.168.100.113:3379"` ）に指定する必要があります。ノードがDocker上で実行されている場合は、DockerのIPアドレスを`"http://0.0.0.0:3379"`に指定してください。 +- 現在のスケジューリング ノードがリッスンするクライアント URL。 +- デフォルト: `"http://127.0.0.1:3379"` +- クラスターをデプロイする際は、現在のホストのIPアドレスを`--listen-addr` （例： `"http://192.168.100.113:3379"` ）に指定する必要があります。ノードがDocker上で実行されている場合は、DockerのIPアドレスを`"http://0.0.0.0:3379"`に指定してください。 ## `--log-file` {#log-file} -- ログ ファイル。 -- デフォルト: `""` -- このフラグが設定されていない場合、ログは「stderr」に出力されます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 +- ログ ファイル。 +- デフォルト: `""` +- このフラグが設定されていない場合、ログは「stderr」に出力されます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 ## `--name` v8.3.0 の新機能 {#name-new-in-v830} -- 現在のスケジューリング ノードの名前。 -- デフォルト: `"scheduling-${hostname}"` -- 複数のスケジューリング ノードを起動する必要がある場合は、識別しやすいように、ノードごとに異なる名前を設定することをお勧めします。 +- 現在のスケジューリング ノードの名前。 +- デフォルト: `"scheduling-${hostname}"` +- 複数のスケジューリング ノードを起動する必要がある場合は、識別しやすいように、ノードごとに異なる名前を設定することをお勧めします。 ## `-L` {#l} -- ログ レベル。 -- デフォルト: `"info"` -- `"warn"` `"fatal"` `"error"` `"debug"` `"info"` +- ログ レベル。 +- デフォルト: `"info"` +- `"warn"` `"fatal"` `"error"` `"debug"` `"info"` ## `-V` , `--version` {#v-version} -- バージョン情報を出力して終了します。 +- バージョン情報を出力して終了します。 diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index ee8e300b383f3..efdf0528ae33a 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/command-line-flags-for-tidb-configuration.md @@ -9,120 +9,120 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## `--advertise-address` {#--advertise-address} -- TiDBサーバーにログインするためのIPアドレス -- デフォルト: `""` -- このアドレスは、TiDB クラスターの残りの部分とユーザーがアクセスできる必要があります。 +- TiDBサーバーにログインするためのIPアドレス +- デフォルト: `""` +- このアドレスは、TiDB クラスターの残りの部分とユーザーがアクセスできる必要があります。 ## `--config` {#--config} -- 設定ファイル -- デフォルト: `""` -- 設定ファイルが指定されている場合、TiDB は設定ファイルを読み取ります。対応する設定がコマンドラインオプションにも存在する場合、TiDB はコマンドラインオプションの設定を使用して設定ファイルの設定を上書きします。詳細な設定情報については、 [TiDBコンフィグレーションファイルの説明](/tidb-configuration-file.md)を参照してください。 +- 設定ファイル +- デフォルト: `""` +- 設定ファイルが指定されている場合、TiDB は設定ファイルを読み取ります。対応する設定がコマンドラインオプションにも存在する場合、TiDB はコマンドラインオプションの設定を使用して設定ファイルの設定を上書きします。詳細な設定情報については、 [TiDBコンフィグレーションファイルの説明](/tidb-configuration-file.md)を参照してください。 ## `--config-check` {#--config-check} -- 設定ファイルの有効性をチェックして終了します -- デフォルト: `false` +- 設定ファイルの有効性をチェックして終了します +- デフォルト: `false` ## `--config-strict` {#--config-strict} -- 設定ファイルの有効性を強制する -- デフォルト: `false` +- 設定ファイルの有効性を強制する +- デフォルト: `false` ## `--cors` {#--cors} -- TiDB HTTPステータスサービスのクロスオリジンリクエスト共有（CORS）リクエストの値`Access-Control-Allow-Origin`を指定します。 -- デフォルト: `""` +- TiDB HTTPステータスサービスのクロスオリジンリクエスト共有（CORS）リクエストの値`Access-Control-Allow-Origin`を指定します。 +- デフォルト: `""` ## `--host` {#--host} -- TiDBサーバーが監視するホストアドレス -- デフォルト: `"0.0.0.0"` -- TiDBサーバーはこのアドレスを監視します。 -- `"0.0.0.0"`アドレスはデフォルトですべてのネットワークカードを監視します。複数のネットワークカードがある場合は、サービスを提供するネットワークカード（例： `192.168.100.113` ）を指定してください。 +- TiDBサーバーが監視するホストアドレス +- デフォルト: `"0.0.0.0"` +- TiDBサーバーはこのアドレスを監視します。 +- `"0.0.0.0"`アドレスはデフォルトですべてのネットワークカードを監視します。複数のネットワークカードがある場合は、サービスを提供するネットワークカード（例： `192.168.100.113` ）を指定してください。 ## `--initialize-insecure` {#--initialize-insecure} -- tidb-server を非セキュアモードでブートストラップする -- デフォルト: `true` +- tidb-server を非セキュアモードでブートストラップする +- デフォルト: `true` ## `--initialize-secure` {#--initialize-secure} -- tidb-server の初期化時に、認証方式`auth_socket`を使用してアカウント`root`を作成するかどうかを制御します。 `true`に設定した場合、TiDB への初回ログインにはソケット接続を使用する必要があります。これにより、セキュリティが強化されます。 -- デフォルト: `false` +- tidb-server の初期化時に、認証方式`auth_socket`を使用してアカウント`root`を作成するかどうかを制御します。 `true`に設定した場合、TiDB への初回ログインにはソケット接続を使用する必要があります。これにより、セキュリティが強化されます。 +- デフォルト: `false` ## `--initialize-sql-file` {#--initialize-sql-file} -- TiDBクラスタの初回起動時に実行されるSQLスクリプト。詳細は[構成項目`initialize-sql-file`](/tidb-configuration-file.md#initialize-sql-file-new-in-v660)を参照。 -- デフォルト: `""` +- TiDBクラスタの初回起動時に実行されるSQLスクリプト。詳細は[構成項目`initialize-sql-file`](/tidb-configuration-file.md#initialize-sql-file-new-in-v660)を参照。 +- デフォルト: `""` ## `-L` {#-l} -- ログレベル -- デフォルト: `"info"` -- `"warn"` `"fatal"` `"error"` `"debug"` `"info"` +- ログレベル +- デフォルト: `"info"` +- `"warn"` `"fatal"` `"error"` `"debug"` `"info"` ## `--lease` {#--lease} -- スキーマリースの期間。何をするかを十分に理解していない場合は、値を変更するのは**危険**です。 -- デフォルト: `45s` +- スキーマリースの期間。何をするかを十分に理解していない場合は、値を変更するのは**危険**です。 +- デフォルト: `45s` ## `--log-file` {#--log-file} -- ログファイル -- デフォルト: `""` -- このオプションが設定されていない場合、ログは「stderr」に出力されます。このオプションが設定されている場合、ログは対応するファイルに出力されます。 +- ログファイル +- デフォルト: `""` +- このオプションが設定されていない場合、ログは「stderr」に出力されます。このオプションが設定されている場合、ログは対応するファイルに出力されます。 ## `--log-general` {#--log-general} -- [一般ログ](/system-variables.md#tidb_general_log)のファイル名 -- デフォルト: `""` -- このオプションが設定されていない場合、一般ログはデフォルトで[`--log-file`](#--log-file)で指定されたファイルに書き込まれます。 +- [一般ログ](/system-variables.md#tidb_general_log)のファイル名 +- デフォルト: `""` +- このオプションが設定されていない場合、一般ログはデフォルトで[`--log-file`](#--log-file)で指定されたファイルに書き込まれます。 ## `--log-slow-query` {#--log-slow-query} -- スロークエリログのディレクトリ -- デフォルト: `""` -- このオプションが設定されていない場合、ログはデフォルトで`--log-file`で指定されたファイルに出力されます。 +- スロークエリログのディレクトリ +- デフォルト: `""` +- このオプションが設定されていない場合、ログはデフォルトで`--log-file`で指定されたファイルに出力されます。 ## `--metrics-addr` {#--metrics-addr} -- Prometheus Pushgatewayアドレス -- デフォルト: `""` -- 空のままにすると、Prometheus クライアントのプッシュが停止します。 -- 形式は`--metrics-addr=192.168.100.115:9091`です。 +- Prometheus Pushgatewayアドレス +- デフォルト: `""` +- 空のままにすると、Prometheus クライアントのプッシュが停止します。 +- 形式は`--metrics-addr=192.168.100.115:9091`です。 ## `--metrics-interval` {#--metrics-interval} -- Prometheusクライアントのプッシュ間隔（秒） -- デフォルト: `15s` -- 値を 0 に設定すると、Prometheus クライアントのプッシュが停止します。 +- Prometheusクライアントのプッシュ間隔（秒） +- デフォルト: `15s` +- 値を 0 に設定すると、Prometheus クライアントのプッシュが停止します。 ## `-P` {#-p} -- TiDBサービスの監視ポート -- デフォルト: `"4000"` -- TiDBサーバーはこのポートからの MySQL クライアント要求を受け入れます。 +- TiDBサービスの監視ポート +- デフォルト: `"4000"` +- TiDBサーバーはこのポートからの MySQL クライアント要求を受け入れます。 ## `--path` {#--path} -- 「unistore」のようなローカルストレージエンジンのデータディレクトリへのパス -- `--store = tikv`の場合、パスを指定する必要があります。 `--store = unistore`の場合、パスを指定しないとデフォルト値が使用されます。 -- TiKVのような分散ストレージエンジンの場合、 `--path`は実際のPDアドレスを指定します。PDサーバーを192.168.100.113:2379、192.168.100.114:2379、192.168.100.115:2379にデプロイすると仮定すると、 `--path`の値は「192.168.100.113:2379、192.168.100.114:2379、192.168.100.115:2379」となります。 -- デフォルト: `"/tmp/tidb"` -- 純粋なインメモリ TiDB を有効にするには、 `tidb-server --store=unistore --path=""`を使用します。 +- 「unistore」のようなローカルストレージエンジンのデータディレクトリへのパス +- `--store = tikv`の場合、パスを指定する必要があります。 `--store = unistore`の場合、パスを指定しないとデフォルト値が使用されます。 +- TiKVのような分散ストレージエンジンの場合、 `--path`は実際のPDアドレスを指定します。PDサーバーを192.168.100.113:2379、192.168.100.114:2379、192.168.100.115:2379にデプロイすると仮定すると、 `--path`の値は「192.168.100.113:2379、192.168.100.114:2379、192.168.100.115:2379」となります。 +- デフォルト: `"/tmp/tidb"` +- 純粋なインメモリ TiDB を有効にするには、 `tidb-server --store=unistore --path=""`を使用します。 ## `--proxy-protocol-fallbackable` {#--proxy-protocol-fallbackable} -- PROXYプロトコルフォールバックモードを有効にするかどうかを制御します。このパラメータを`true`に設定すると、TiDBはPROXYプロトコル仕様を使用せず、PROXYプロトコルヘッダーを送信せずに、 `--proxy-protocol-networks`に属するクライアント接続を受け入れます。デフォルトでは、TiDBは`--proxy-protocol-networks`に属し、PROXYプロトコルヘッダーを送信するクライアント接続のみを受け入れます。 -- デフォルト値: `false` +- PROXYプロトコルフォールバックモードを有効にするかどうかを制御します。このパラメータを`true`に設定すると、TiDBはPROXYプロトコル仕様を使用せず、PROXYプロトコルヘッダーを送信せずに、 `--proxy-protocol-networks`に属するクライアント接続を受け入れます。デフォルトでは、TiDBは`--proxy-protocol-networks`に属し、PROXYプロトコルヘッダーを送信するクライアント接続のみを受け入れます。 +- デフォルト値: `false` ## `--proxy-protocol-networks` {#--proxy-protocol-networks} -- [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）で、区切り文字として`,`を使用します。`*`は任意の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）で、区切り文字として`,`を使用します。`*`は任意のIPアドレスを意味します。 > **Warning:** > @@ -134,8 +134,8 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## `--proxy-protocol-header-timeout` {#--proxy-protocol-header-timeout} -- PROXYプロトコルヘッダー読み取りのタイムアウト -- デフォルト: `5` (秒) +- PROXYプロトコルヘッダー読み取りのタイムアウト +- デフォルト: `5` (秒) > **Warning:** > @@ -147,89 +147,89 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## `--report-status` {#--report-status} -- ステータスレポートとpprofツールを有効（ `true` ）または無効（ `false` ）にする -- デフォルト: `true` -- このパラメータを`true`に設定すると、メトリクスとpprofが有効になります。 `false`に設定すると、メトリクスとpprofが無効になります。 +- ステータスレポートとpprofツールを有効（ `true` ）または無効（ `false` ）にする +- デフォルト: `true` +- このパラメータを`true`に設定すると、メトリクスとpprofが有効になります。 `false`に設定すると、メトリクスとpprofが無効になります。 ## `--run-ddl` {#--run-ddl} -- `tidb-server` DDL文を実行するかどうかを確認し、クラスタ内の`tidb-server`の数が2を超える場合に設定する -- デフォルト: `true` -- 値は (true) または (false) になります。 (true) は、 `tidb-server` DDL 自体を実行することを示します。 (false) は、 `tidb-server` DDL 自体を実行しないことを示します。 +- `tidb-server` DDL文を実行するかどうかを確認し、クラスタ内の`tidb-server`の数が2を超える場合に設定する +- デフォルト: `true` +- 値は (true) または (false) になります。 (true) は、 `tidb-server` DDL 自体を実行することを示します。 (false) は、 `tidb-server` DDL 自体を実行しないことを示します。 ## `--socket string` {#--socket-string} -- TiDB サービスは、外部接続に Unix ソケット ファイルを使用します。 -- デフォルト: `""` -- `/tmp/tidb.sock`を使用して Unix ソケット ファイルを開きます。 +- TiDB サービスは、外部接続に Unix ソケット ファイルを使用します。 +- デフォルト: `""` +- `/tmp/tidb.sock`を使用して Unix ソケット ファイルを開きます。 ## `--status` {#--status} -- TiDBサーバーのステータスレポートポート -- デフォルト: `"10080"` -- このポートはサーバー内部データを取得するために使用されます。データには[Prometheusメトリクス](https://prometheus.io/)と[pprof](https://golang.org/pkg/net/http/pprof/)が含まれます。 -- Prometheus メトリックには`"http://host:status_port/metrics"`でアクセスできます。 -- pprof データには`"http://host:status_port/debug/pprof"`でアクセスできます。 +- TiDBサーバーのステータスレポートポート +- デフォルト: `"10080"` +- このポートはサーバー内部データを取得するために使用されます。データには[Prometheusメトリクス](https://prometheus.io/)と[pprof](https://golang.org/pkg/net/http/pprof/)が含まれます。 +- Prometheus メトリックには`"http://host:status_port/metrics"`でアクセスできます。 +- pprof データには`"http://host:status_port/debug/pprof"`でアクセスできます。 ## `--status-host` {#--status-host} -- TiDBサービスのステータスを監視するために使用される`HOST` -- デフォルト: `0.0.0.0` +- TiDBサービスのステータスを監視するために使用される`HOST` +- デフォルト: `0.0.0.0` ## `--store` {#--store} -- 最下層で TiDB が使用するストレージエンジンを指定します -- デフォルト: `"unistore"` -- 「unistore」または「tikv」を選択できます。（「unistore」はローカルストレージエンジン、「tikv」は分散ストレージエンジンです） +- 最下層で TiDB が使用するストレージエンジンを指定します +- デフォルト: `"unistore"` +- 「unistore」または「tikv」を選択できます。（「unistore」はローカルストレージエンジン、「tikv」は分散ストレージエンジンです） ## `--temp-dir` {#--temp-dir} -- TiDBの一時ディレクトリ -- デフォルト: `"/tmp/tidb"` +- TiDBの一時ディレクトリ +- デフォルト: `"/tmp/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} -- TiDBで同時に実行できるセッション数。トラフィック制御に使用されます。 -- デフォルト: `1000` -- 同時セッション数が`token-limit`より大きい場合、リクエストはブロックされ、トークンを解放する操作が終了するまで待機します。 +- TiDBで同時に実行できるセッション数。トラフィック制御に使用されます。 +- デフォルト: `1000` +- 同時セッション数が`token-limit`より大きい場合、リクエストはブロックされ、トークンを解放する操作が終了するまで待機します。 ## `-V` {#-v} -- TiDBのバージョンを出力します -- デフォルト: `""` +- TiDBのバージョンを出力します +- デフォルト: `""` ## `--plugin-dir` {#--plugin-dir} -- プラグインのストレージディレクトリ。 -- デフォルト: `"/data/deploy/plugin"` +- プラグインのストレージディレクトリ。 +- デフォルト: `"/data/deploy/plugin"` ## `--plugin-load` {#--plugin-load} -- ロードするプラグインの名前。それぞれはコンマで区切られます。 -- デフォルト: `""` +- ロードするプラグインの名前。それぞれはコンマで区切られます。 +- デフォルト: `""` ## `--affinity-cpus` {#--affinity-cpus} -- TiDBサーバーのCPUアフィニティをカンマ区切りで設定します。例："1,2,3"。 -- デフォルト: `""` +- TiDBサーバーのCPUアフィニティをカンマ区切りで設定します。例："1,2,3"。 +- デフォルト: `""` ## `--redact` {#--redact} -- サブコマンド`collect-log`を使用するときに、 TiDBサーバーがログ ファイルを非感度化するかどうかを決定します。 -- デフォルト: false -- 値が`true`の場合、マスキング操作となり、 `‹ ›`マーク記号で囲まれたすべてのフィールドが`?`に置き換えられます。値が`false`の場合、リストア操作となり、すべてのマーク記号が削除されます。この機能を使用するには、 `./tidb-server --redact=xxx collect-log `を実行して、 ``で指定された TiDBサーバーログファイルを非感応化またはリストアし、 ``に出力します。詳細については、システム変数[`tidb_redact_log`](/system-variables.md#tidb_redact_log)を参照してください。 +- サブコマンド`collect-log`を使用するときに、 TiDBサーバーがログ ファイルを非感度化するかどうかを決定します。 +- デフォルト: false +- 値が`true`の場合、マスキング操作となり、 `‹ ›`マーク記号で囲まれたすべてのフィールドが`?`に置き換えられます。値が`false`の場合、リストア操作となり、すべてのマーク記号が削除されます。この機能を使用するには、 `./tidb-server --redact=xxx collect-log `を実行して、 ``で指定された TiDBサーバーログファイルを非感応化またはリストアし、 ``に出力します。詳細については、システム変数[`tidb_redact_log`](/system-variables.md#tidb_redact_log)を参照してください。 ## `--repair-mode` {#--repair-mode} -- データ修復シナリオでのみ使用される修復モードを有効にするかどうかを決定します。 -- デフォルト: `false` +- データ修復シナリオでのみ使用される修復モードを有効にするかどうかを決定します。 +- デフォルト: `false` ## `--repair-list` {#--repair-list} -- 修復モードで修復されるテーブルの名前。 -- デフォルト: `""` +- 修復モードで修復されるテーブルの名前。 +- デフォルト: `""` diff --git a/command-line-flags-for-tikv-configuration.md b/command-line-flags-for-tikv-configuration.md index f7d76c3209b6c..71f3b66f82417 100644 --- a/command-line-flags-for-tikv-configuration.md +++ b/command-line-flags-for-tikv-configuration.md @@ -7,53 +7,53 @@ summary: TiKV のいくつかの構成フラグについて学習します。 TiKV は、コマンドラインパラメータに対していくつかの読み取り可能な単位変換をサポートしています。 -- ファイルサイズ（バイト単位）: KB、MB、GB、TB、PB（または小文字） -- 時間（ミリ秒単位）: ms、s、m、h +- ファイルサイズ（バイト単位）: KB、MB、GB、TB、PB（または小文字） +- 時間（ミリ秒単位）: ms、s、m、h ## `-A, --addr` {#-a---addr} -- TiKVサーバーが監視するアドレス -- デフォルト: `"127.0.0.1:20160"` -- クラスターをデプロイするには、現在のホストのIPアドレスを`--addr`で指定する必要があります（例： `"192.168.100.113:20160"` 。クラスターがDocker上で実行される場合は、DockerのIPアドレスを`"0.0.0.0:20160"`で指定します。 +- TiKVサーバーが監視するアドレス +- デフォルト: `"127.0.0.1:20160"` +- クラスターをデプロイするには、現在のホストのIPアドレスを`--addr`で指定する必要があります（例： `"192.168.100.113:20160"` 。クラスターがDocker上で実行される場合は、DockerのIPアドレスを`"0.0.0.0:20160"`で指定します。 ## `--advertise-addr` {#--advertise-addr} -- サーバーは外部からのクライアントトラフィックのアドレスをアドバタイズします -- デフォルト: `${addr}` -- Docker または NAT ネットワークのためにクライアントが`--addr`アドレス経由で TiKV に接続できない場合は、 `--advertise-addr`アドレスを手動で設定する必要があります。 -- 例えば、Dockerの内部IPアドレスが172.17.0.1で、ホストのIPアドレスが192.168.100.113で、ポートマッピングが`-p 20160:20160`に設定されている場合、 `--advertise-addr`を「192.168.100.113:20160」に設定できます。クライアントは192.168.100.113:20160を介してこのサービスにアクセスできます。 +- サーバーは外部からのクライアントトラフィックのアドレスをアドバタイズします +- デフォルト: `${addr}` +- Docker または NAT ネットワークのためにクライアントが`--addr`アドレス経由で TiKV に接続できない場合は、 `--advertise-addr`アドレスを手動で設定する必要があります。 +- 例えば、Dockerの内部IPアドレスが172.17.0.1で、ホストのIPアドレスが192.168.100.113で、ポートマッピングが`-p 20160:20160`に設定されている場合、 `--advertise-addr`を「192.168.100.113:20160」に設定できます。クライアントは192.168.100.113:20160を介してこのサービスにアクセスできます。 ## `--status-addr` {#--status-addr} -- TiKV サービスのステータスをリッスンするポート -- デフォルト: `"20180"` -- Prometheus は`http://host:status_port/metrics`を介してこのステータス情報にアクセスできます。 -- プロファイルは`http://host:status_port/debug/pprof/profile`を介してこのステータス情報にアクセスできます。 +- TiKV サービスのステータスをリッスンするポート +- デフォルト: `"20180"` +- Prometheus は`http://host:status_port/metrics`を介してこのステータス情報にアクセスできます。 +- プロファイルは`http://host:status_port/debug/pprof/profile`を介してこのステータス情報にアクセスできます。 ## `--advertise-status-addr` {#--advertise-status-addr} -- TiKV が外部からサービス ステータスにアクセスするために使用するアドレス。 -- デフォルト: 値`--status-addr`が使用されます。 -- Docker または NAT ネットワークのためにクライアントが`--status-addr`アドレス経由で TiKV に接続できない場合は、 `--advertise-status-addr`アドレスを手動で設定する必要があります。 -- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 20180:20180`に設定されています。この場合、 `--advertise-status-addr="192.168.100.113:20180"`を設定します。クライアントは`192.168.100.113:20180`を通じてこのサービスを見つけられます。 +- TiKV が外部からサービス ステータスにアクセスするために使用するアドレス。 +- デフォルト: 値`--status-addr`が使用されます。 +- Docker または NAT ネットワークのためにクライアントが`--status-addr`アドレス経由で TiKV に接続できない場合は、 `--advertise-status-addr`アドレスを手動で設定する必要があります。 +- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 20180:20180`に設定されています。この場合、 `--advertise-status-addr="192.168.100.113:20180"`を設定します。クライアントは`192.168.100.113:20180`を通じてこのサービスを見つけられます。 ## `-C, --config` {#-c---config} -- 設定ファイル -- デフォルト: `""` -- コマンドラインを使用して設定を行うと、設定ファイル内の同じ設定が上書きされます。 +- 設定ファイル +- デフォルト: `""` +- コマンドラインを使用して設定を行うと、設定ファイル内の同じ設定が上書きされます。 ## `--capacity` {#--capacity} -- ストアキャパシティ -- デフォルト: `0` (無制限) -- PDはこのフラグを使用して、TiKVサーバーのバランス調整方法を決定します。（ヒント：1073741824の代わりに10GBを使用することもできます） +- ストアキャパシティ +- デフォルト: `0` (無制限) +- PDはこのフラグを使用して、TiKVサーバーのバランス調整方法を決定します。（ヒント：1073741824の代わりに10GBを使用することもできます） ## `--config-info ` {#--config-info-format} -- このフラグを使用すると、使用可能な構成値が`FORMAT`に従ってリストされ、終了します。 -- `FORMAT`の値オプション: `json` 。現在、JSON 形式のみがサポートされています。 -- 出力されるJSONには、設定名（Name）、デフォルト値（DefaultValue）、現在の値（ValueInFile）のみが記載されます。`-C`または`--config`が指定されている場合は、ファイル内の設定項目の現在の値とデフォルト値が一緒に記載され、 `-C`または`--config`が指定されていない項目にはデフォルト値のみが設定されます。以下は例です。 +- このフラグを使用すると、使用可能な構成値が`FORMAT`に従ってリストされ、終了します。 +- `FORMAT`の値オプション: `json` 。現在、JSON 形式のみがサポートされています。 +- 出力されるJSONには、設定名（Name）、デフォルト値（DefaultValue）、現在の値（ValueInFile）のみが記載されます。`-C`または`--config`が指定されている場合は、ファイル内の設定項目の現在の値とデフォルト値が一緒に記載され、 `-C`または`--config`が指定されていない項目にはデフォルト値のみが設定されます。以下は例です。 ```json { @@ -76,23 +76,23 @@ TiKV は、コマンドラインパラメータに対していくつかの読み ## `--data-dir` {#--data-dir} -- データディレクトリへのパス -- デフォルト: `"/tmp/tikv/store"` +- データディレクトリへのパス +- デフォルト: `"/tmp/tikv/store"` ## `-L` {#-l} -- ログレベル -- デフォルト: `"info"` -- `"warn"` `"fatal"` `"error"` `"debug"` `"info"` +- ログレベル +- デフォルト: `"info"` +- `"warn"` `"fatal"` `"error"` `"debug"` `"info"` ## `--log-file` {#--log-file} -- ログファイル -- デフォルト: `""` -- このフラグが設定されていない場合、ログは「stderr」に書き込まれます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 +- ログファイル +- デフォルト: `""` +- このフラグが設定されていない場合、ログは「stderr」に書き込まれます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 ## `--pd` {#--pd} -- PDサーバーのアドレスリスト -- デフォルト: `""` -- TiKVを動作させるには、TiKVサーバーをPDサーバーに接続する際に値`--pd`を使用する必要があります。複数のPDアドレスはカンマで区切ってください（例：192.168.100.113:2379, 192.168.100.114:2379, 192.168.100.115:2379）。 +- PDサーバーのアドレスリスト +- デフォルト: `""` +- TiKVを動作させるには、TiKVサーバーをPDサーバーに接続する際に値`--pd`を使用する必要があります。複数のPDアドレスはカンマで区切ってください（例：192.168.100.113:2379, 192.168.100.114:2379, 192.168.100.115:2379）。 diff --git a/command-line-flags-for-tso-configuration.md b/command-line-flags-for-tso-configuration.md index ff28a8036b451..fec4f44f41316 100644 --- a/command-line-flags-for-tso-configuration.md +++ b/command-line-flags-for-tso-configuration.md @@ -9,66 +9,66 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ## `--advertise-listen-addr` {#advertise-listen-addr} -- クライアントが TSO ノードにアクセスするための URL。 -- デフォルト: `${listen-addr}` -- Docker や NAT ネットワーク環境などの状況では、クライアントが`tso`でリッスンされるデフォルトのクライアント URL を通じて TSO ノードにアクセスできない場合は、クライアント アクセス用に`--advertise-listen-addr`手動で設定する必要があります。 -- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 3379:3379`に設定されています。この場合、 `--advertise-listen-addr="http://192.168.100.113:3379"`設定できます。そうすることで、クライアントは`http://192.168.100.113:3379`を通じてこのサービスを見つけることができるようになります。 +- クライアントが TSO ノードにアクセスするための URL。 +- デフォルト: `${listen-addr}` +- Docker や NAT ネットワーク環境などの状況では、クライアントが`tso`でリッスンされるデフォルトのクライアント URL を通じて TSO ノードにアクセスできない場合は、クライアント アクセス用に`--advertise-listen-addr`手動で設定する必要があります。 +- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 3379:3379`に設定されています。この場合、 `--advertise-listen-addr="http://192.168.100.113:3379"`設定できます。そうすることで、クライアントは`http://192.168.100.113:3379`を通じてこのサービスを見つけることができるようになります。 ## `--backend-endpoints` {#backend-endpoints} -- 現在の TSO ノードがリッスンする他の TSO ノードのバックエンド エンドポイントのリスト。 -- デフォルト: `http://127.0.0.1:2379` +- 現在の TSO ノードがリッスンする他の TSO ノードのバックエンド エンドポイントのリスト。 +- デフォルト: `http://127.0.0.1:2379` ## `--cacert` {#cacert} -- TLS を有効にするために使用される CA のファイル パス。 -- デフォルト: `""` +- TLS を有効にするために使用される CA のファイル パス。 +- デフォルト: `""` ## `--cert` {#cert} -- TLS を有効にするために使用される、X.509 証明書を含む PEM ファイルのパス。 -- デフォルト: `""` +- TLS を有効にするために使用される、X.509 証明書を含む PEM ファイルのパス。 +- デフォルト: `""` ## `--config` {#config} -- 設定ファイル。 -- デフォルト: `""` -- 設定ファイルを指定すると、TSOノードはまずそのファイルから設定を読み取ります。同じ設定がコマンドラインフラグでも指定されている場合、TSOノードはコマンドラインフラグの設定を使用して設定ファイルの設定を上書きします。 +- 設定ファイル。 +- デフォルト: `""` +- 設定ファイルを指定すると、TSOノードはまずそのファイルから設定を読み取ります。同じ設定がコマンドラインフラグでも指定されている場合、TSOノードはコマンドラインフラグの設定を使用して設定ファイルの設定を上書きします。 ## `--data-dir` {#data-dir} -- TSO ノード上のデータ ディレクトリへのパス。 -- デフォルト: `"default.${name}"` +- TSO ノード上のデータ ディレクトリへのパス。 +- デフォルト: `"default.${name}"` ## `--key` {#key} -- TLS を有効にするために使用される、X.509 キーを含む PEM ファイルのパス。 -- デフォルト: `""` +- TLS を有効にするために使用される、X.509 キーを含む PEM ファイルのパス。 +- デフォルト: `""` ## `--listen-addr` {#listen-addr} -- 現在の TSO ノードがリッスンするクライアント URL。 -- デフォルト: `"http://127.0.0.1:3379"` -- クラスターをデプロイする際は、現在のホストのIPアドレスを`--listen-addr` （例： `"http://192.168.100.113:3379"` ）に指定する必要があります。ノードがDocker上で実行されている場合は、DockerのIPアドレスを`"http://0.0.0.0:3379"`に指定してください。 +- 現在の TSO ノードがリッスンするクライアント URL。 +- デフォルト: `"http://127.0.0.1:3379"` +- クラスターをデプロイする際は、現在のホストのIPアドレスを`--listen-addr` （例： `"http://192.168.100.113:3379"` ）に指定する必要があります。ノードがDocker上で実行されている場合は、DockerのIPアドレスを`"http://0.0.0.0:3379"`に指定してください。 ## `--log-file` {#log-file} -- ログ ファイル。 -- デフォルト: `""` -- このフラグが設定されていない場合、ログは「stderr」に出力されます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 +- ログ ファイル。 +- デフォルト: `""` +- このフラグが設定されていない場合、ログは「stderr」に出力されます。このフラグが設定されている場合、ログは対応するファイルに出力されます。 ## `--name` v8.3.0 の新機能 {#name-new-in-v830} -- 現在の TSO ノードの名前。 -- デフォルト: `"tso-${hostname}"` -- 複数の TSO ノードを起動する必要がある場合は、識別を容易にするために、ノードごとに異なる名前を設定することをお勧めします。 +- 現在の TSO ノードの名前。 +- デフォルト: `"tso-${hostname}"` +- 複数の TSO ノードを起動する必要がある場合は、識別を容易にするために、ノードごとに異なる名前を設定することをお勧めします。 ## `-L` {#l} -- ログ レベル。 -- デフォルト: `"info"` -- `"warn"` `"fatal"` `"error"` `"debug"` `"info"` +- ログ レベル。 +- デフォルト: `"info"` +- `"warn"` `"fatal"` `"error"` `"debug"` `"info"` ## `-V` , `--version` {#v-version} -- バージョン情報を出力して終了します。 +- バージョン情報を出力して終了します。 diff --git a/comment-syntax.md b/comment-syntax.md index 9fe8c1d627832..2d419c4e8285c 100644 --- a/comment-syntax.md +++ b/comment-syntax.md @@ -9,7 +9,7 @@ summary: このドキュメントでは、TiDB でサポートされているコ TiDB は次の 3 つのコメント スタイルをサポートしています。 -- 行をコメント化するには`#`を使用します。 +- 行をコメント化するには`#`を使用します。 ```sql SELECT 1+1; # comments @@ -24,7 +24,7 @@ TiDB は次の 3 つのコメント スタイルをサポートしています 1 row in set (0.00 sec) ``` -- 行をコメント化するには`--`を使用します。 +- 行をコメント化するには`--`を使用します。 ```sql SELECT 1+1; -- comments @@ -54,7 +54,7 @@ TiDB は次の 3 つのコメント スタイルをサポートしています 1 row in set (0.01 sec) ``` -- ブロックまたは複数行をコメント化するには`/* */`を使用します。 +- ブロックまたは複数行をコメント化するには`/* */`を使用します。 ```sql SELECT 1 /* this is an in-line comment */ + 1; @@ -122,8 +122,8 @@ MySQLでは、コメントにサーバーのバージョン番号（例： `/*!5 TiDB には独自のコメント構文 (つまり、TiDB 固有のコメント構文) があり、次の 2 種類に分けられます。 -- `/*T! Specific code */` : この構文は TiDB によってのみ解析および実行され、他のデータベースでは無視されます。 -- `/*T![feature_id] Specific code */` : この構文は、TiDBの異なるバージョン間の互換性を確保するために使用されます。TiDBは、現在のバージョンで`feature_id`の対応する機能を実装している場合にのみ、このコメント内のSQLフラグメントを解析できます。例えば、 `AUTO_RANDOM`機能はv3.1.1で導入されているため、このバージョンのTiDBは`/*T![auto_rand] auto_random */`を`auto_random`に解析できます。`AUTO_RANDOM`機能はv3.0.0では実装されていないため、上記のSQL文フラグメントは無視されます。**`/*T![`文字内にスペースを入れないでください**。 +- `/*T! Specific code */` : この構文は TiDB によってのみ解析および実行され、他のデータベースでは無視されます。 +- `/*T![feature_id] Specific code */` : この構文は、TiDBの異なるバージョン間の互換性を確保するために使用されます。TiDBは、現在のバージョンで`feature_id`の対応する機能を実装している場合にのみ、このコメント内のSQLフラグメントを解析できます。例えば、 `AUTO_RANDOM`機能はv3.1.1で導入されているため、このバージョンのTiDBは`/*T![auto_rand] auto_random */`を`auto_random`に解析できます。`AUTO_RANDOM`機能はv3.0.0では実装されていないため、上記のSQL文フラグメントは無視されます。**`/*T![`文字内にスペースを入れないでください**。 ## オプティマイザコメント構文 {#optimizer-comment-syntax} diff --git a/configure-load-base-split.md b/configure-load-base-split.md index eee47692d3bbb..a155c0895fdd1 100644 --- a/configure-load-base-split.md +++ b/configure-load-base-split.md @@ -17,8 +17,8 @@ TiDBでは、負荷が特定のノードに集中すると、ホットスポッ 以前は、この問題の解決策として、1 つ以上のホットスポットリージョンを分割するコマンドを手動で実行していましたが、この方法には 2 つの問題がありました。 -- リージョンを均等に分割することは、必ずしも最適な選択とは限りません。リクエストが少数のキーに集中する可能性があるためです。このような場合、均等分割後もホットスポットがいずれかのリージョンに残る可能性があり、目的を達成するには複数回の均等分割が必要になる場合があります。 -- 人間の介入はタイムリーでも簡単でもない。 +- リージョンを均等に分割することは、必ずしも最適な選択とは限りません。リクエストが少数のキーに集中する可能性があるためです。このような場合、均等分割後もホットスポットがいずれかのリージョンに残る可能性があり、目的を達成するには複数回の均等分割が必要になる場合があります。 +- 人間の介入はタイムリーでも簡単でもない。 ## 実装原理 {#implementation-principles} @@ -30,21 +30,21 @@ Load Base Splitによって分割されたリージョンは、すぐにはマ ロード ベース分割機能は現在、次のパラメータによって制御されています。 -- [`split.qps-threshold`](/tikv-configuration-file.md#qps-threshold) :リージョンがホットスポットと判断されるQPSのしきい値。4GB [`region-split-size`](/tikv-configuration-file.md#region-split-size)の場合はデフォルト値は1秒あたり`3000` 、それ以外の場合はデフォルト値は`7000`です。 -- [`split.byte-threshold`](/tikv-configuration-file.md#byte-threshold-new-in-v50) : (v5.0で導入)リージョンがホットスポットとして識別されるトラフィックしきい値。単位はバイトです`region-split-size`が4GB未満の場合はデフォルト値は30MiB/秒、それ以外の場合は100MiB/秒です。 -- [`split.region-cpu-overload-threshold-ratio`](/tikv-configuration-file.md#region-cpu-overload-threshold-ratio-new-in-v620) : (v6.2.0 で導入)リージョンがホットスポットと判断される CPU 使用率のしきい値 (読み取りスレッドプールの CPU 時間の割合)。`region-split-size`が4GB未満の場合はデフォルト値は`0.25` 、それ以外の場合はデフォルト値は`0.75`です。 +- [`split.qps-threshold`](/tikv-configuration-file.md#qps-threshold) :リージョンがホットスポットと判断されるQPSのしきい値。4GB [`region-split-size`](/tikv-configuration-file.md#region-split-size)の場合はデフォルト値は1秒あたり`3000` 、それ以外の場合はデフォルト値は`7000`です。 +- [`split.byte-threshold`](/tikv-configuration-file.md#byte-threshold-new-in-v50) : (v5.0で導入)リージョンがホットスポットとして識別されるトラフィックしきい値。単位はバイトです`region-split-size`が4GB未満の場合はデフォルト値は30MiB/秒、それ以外の場合は100MiB/秒です。 +- [`split.region-cpu-overload-threshold-ratio`](/tikv-configuration-file.md#region-cpu-overload-threshold-ratio-new-in-v620) : (v6.2.0 で導入)リージョンがホットスポットと判断される CPU 使用率のしきい値 (読み取りスレッドプールの CPU 時間の割合)。`region-split-size`が4GB未満の場合はデフォルト値は`0.25` 、それ以外の場合はデフォルト値は`0.75`です。 リージョンが10 秒連続して次のいずれかの条件を満たした場合、TiKV はリージョンを分割しようとします。 -- 読み取り要求の合計が`split.qps-threshold`超えます。 -- トラフィックが`split.byte-threshold`超えています。 -- 統合読み取りプール内の CPU 使用率が`split.region-cpu-overload-threshold-ratio`超えています。 +- 読み取り要求の合計が`split.qps-threshold`超えます。 +- トラフィックが`split.byte-threshold`超えています。 +- 統合読み取りプール内の CPU 使用率が`split.region-cpu-overload-threshold-ratio`超えています。 ロードベーススプリットはデフォルトで有効になっていますが、パラメータがかなり高い値に設定されています。この機能を無効にするには、 `split.qps-threshold`と`split.byte-threshold`十分に高い値に設定し、同時に`split.region-cpu-overload-threshold-ratio`を`0`に設定してください。 パラメータを変更するには、次の 2 つの方法のいずれかを実行します。 -- SQL ステートメントを使用します。 +- SQL ステートメントを使用します。 ```sql # Set the QPS threshold to 1500 @@ -55,7 +55,7 @@ Load Base Splitによって分割されたリージョンは、すぐにはマ SET config tikv split.region-cpu-overload-threshold-ratio=0.5; ``` -- TiKV を使用する: +- TiKV を使用する: ```shell curl -X POST "http://ip:status_port/config" -H "accept: application/json" -d '{"split.qps-threshold":"1500"}' @@ -65,13 +65,13 @@ Load Base Splitによって分割されたリージョンは、すぐにはマ したがって、次の 2 つの方法のいずれかで構成を表示できます。 -- SQL ステートメントを使用します。 +- SQL ステートメントを使用します。 ```sql show config where type='tikv' and name like '%split.qps-threshold%'; ``` -- TiKV を使用する: +- TiKV を使用する: ```shell curl "http://ip:status_port/config" diff --git a/configure-memory-usage.md b/configure-memory-usage.md index 053775a6cadcf..836906dc8b3e1 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -7,8 +7,8 @@ summary: クエリのメモリクォータを構成して OOM (メモリ不足) 現在、TiDBは単一のSQLクエリのメモリクォータを追跡し、メモリ使用量が特定のしきい値を超えた場合に、OOM（メモリ不足）を防止したり、OOMのトラブルシューティングを行うためのアクションを実行できます。システム変数[`tidb_mem_oom_action`](/system-variables.md#tidb_mem_oom_action-new-in-v610)は、クエリがメモリ制限に達した場合に実行するアクションを指定します。 -- 値が`LOG`の場合、 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)制限に達したときにクエリは引き続き実行されますが、TiDB はログにエントリを出力します。 -- 値が`CANCEL`の場合、TiDBは[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)制限に達した直後にSQLクエリの実行を停止し、クライアントにエラーを返します。エラー情報には、SQL実行プロセスでメモリを消費する各物理実行演算子のメモリ使用量が明確に表示されます。 +- 値が`LOG`の場合、 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)制限に達したときにクエリは引き続き実行されますが、TiDB はログにエントリを出力します。 +- 値が`CANCEL`の場合、TiDBは[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)制限に達した直後にSQLクエリの実行を停止し、クライアントにエラーを返します。エラー情報には、SQL実行プロセスでメモリを消費する各物理実行演算子のメモリ使用量が明確に表示されます。 ## クエリのメモリクォータを設定する {#configure-the-memory-quota-of-a-query} @@ -43,14 +43,14 @@ SET GLOBAL tidb_server_memory_limit = "32GB"; 現在、 `tidb_server_memory_limit`で設定されたメモリ制限では、次の SQL 操作は終了し**ません**。 -- DDL操作 -- ウィンドウ関数と共通テーブル式を含むSQL操作 +- DDL操作 +- ウィンドウ関数と共通テーブル式を含むSQL操作 > **Warning:** > -> - TiDBは起動プロセス中に[`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)制限が確実に適用されるとは保証しません。オペレーティングシステムの空きメモリが不足している場合、TiDBは依然としてOOMが発生する可能性があります。TiDBインスタンスに十分な空きメモリがあることを確認する必要があります。 -> - メモリ制御の過程で、TiDB の合計メモリ使用量が`tidb_server_memory_limit`で設定された制限をわずかに超える場合があります。 -> - バージョン6.5.0以降、設定項目`server-memory-quota`は非推奨となりました。互換性を確保するため、クラスターをバージョン6.5.0以降にアップグレードすると、 `tidb_server_memory_limit`は`server-memory-quota`の値を継承します。アップグレード前に`server-memory-quota`を設定していない場合は、`tidb_server_memory_limit`のデフォルト値（`80%`）が使用されます。 +> - TiDBは起動プロセス中に[`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)制限が確実に適用されるとは保証しません。オペレーティングシステムの空きメモリが不足している場合、TiDBは依然としてOOMが発生する可能性があります。TiDBインスタンスに十分な空きメモリがあることを確認する必要があります。 +> - メモリ制御の過程で、TiDB の合計メモリ使用量が`tidb_server_memory_limit`で設定された制限をわずかに超える場合があります。 +> - バージョン6.5.0以降、設定項目`server-memory-quota`は非推奨となりました。互換性を確保するため、クラスターをバージョン6.5.0以降にアップグレードすると、 `tidb_server_memory_limit`は`server-memory-quota`の値を継承します。アップグレード前に`server-memory-quota`を設定していない場合は、`tidb_server_memory_limit`のデフォルト値（`80%`）が使用されます。 tidb-server インスタンスのメモリ使用量が総メモリの一定割合（割合はシステム変数[`tidb_server_memory_limit_gc_trigger`](/system-variables.md#tidb_server_memory_limit_gc_trigger-new-in-v640)によって制御されます）に達すると、tidb-server はメモリ負荷を軽減するためにGolang GC をトリガーしようとします。インスタンスメモリがしきい値付近で変動することで頻繁な GC が発生し、パフォーマンスに問題が生じるのを防ぐため、この GC 方式では GC は最大で 1 分に 1 回しかトリガーされません。 @@ -68,43 +68,43 @@ tidb-server インスタンスのメモリ使用量が総メモリの一定割 tidb-server インスタンスのメモリ使用量がメモリしきい値 (デフォルトでは合計メモリの 70%) を超え、次のいずれかの条件が満たされると、TiDB は関連するステータス ファイルを記録し、アラーム ログを出力。 -- メモリ使用量がメモリしきい値を超えるのは初めてです。 -- メモリ使用量がメモリしきい値を超えており、前回のアラームから 60 秒以上経過しています。 -- メモリ使用量がメモリしきい値を超え、 `(Current memory usage - Memory usage at the last alarm) / Total memory > 10%` 。 +- メモリ使用量がメモリしきい値を超えるのは初めてです。 +- メモリ使用量がメモリしきい値を超えており、前回のアラームから 60 秒以上経過しています。 +- メモリ使用量がメモリしきい値を超え、 `(Current memory usage - Memory usage at the last alarm) / Total memory > 10%` 。 システム変数[`tidb_memory_usage_alarm_ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio)を使用してメモリ使用率を変更することで、アラームをトリガーするメモリしきい値を制御できます。 過剰なメモリ使用量のアラームがトリガーされると、TiDB は次のアクションを実行します。 -- TiDB は、TiDB ログ ファイル[`filename`](/tidb-configuration-file.md#filename)が配置されているディレクトリに次の情報を記録します。 +- TiDB は、TiDB ログ ファイル[`filename`](/tidb-configuration-file.md#filename)が配置されているディレクトリに次の情報を記録します。 - - 現在実行中のすべてのSQL文の中で、メモリ使用量が最も多い上位10個のSQL文と実行時間が最も長い上位10個のSQL文に関する情報 - - ゴルーチンスタック情報 - - ヒープメモリの使用状況 + - 現在実行中のすべてのSQL文の中で、メモリ使用量が最も多い上位10個のSQL文と実行時間が最も長い上位10個のSQL文に関する情報 + - ゴルーチンスタック情報 + - ヒープメモリの使用状況 -- TiDB は、キーワード`tidb-server has the risk of OOM`と次のメモリ関連のシステム変数の値を含むアラーム ログを出力。 +- TiDB は、キーワード`tidb-server has the risk of OOM`と次のメモリ関連のシステム変数の値を含むアラーム ログを出力。 - - [`tidb_mem_oom_action`](/system-variables.md#tidb_mem_oom_action-new-in-v610) - - [`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) - - [`tidb_analyze_version`](/system-variables.md#tidb_analyze_version-new-in-v510) - - [`tidb_enable_rate_limit_action`](/system-variables.md#tidb_enable_rate_limit_action) + - [`tidb_mem_oom_action`](/system-variables.md#tidb_mem_oom_action-new-in-v610) + - [`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) + - [`tidb_analyze_version`](/system-variables.md#tidb_analyze_version-new-in-v510) + - [`tidb_enable_rate_limit_action`](/system-variables.md#tidb_enable_rate_limit_action) アラームのステータスファイルが過度に蓄積されるのを防ぐため、TiDBはデフォルトで、直近5回のアラーム中に生成されたステータスファイルのみを保持します。この数は、システム変数[`tidb_memory_usage_alarm_keep_record_num`](/system-variables.md#tidb_memory_usage_alarm_keep_record_num-new-in-v640)を設定することで調整できます。 次の例では、アラームをトリガーするメモリを大量に消費する SQL ステートメントを構築します。 -1. `tidb_memory_usage_alarm_ratio`を`0.85`に設定します : +1. `tidb_memory_usage_alarm_ratio`を`0.85`に設定します : ```sql SET GLOBAL tidb_memory_usage_alarm_ratio = 0.85; ``` -2. `CREATE TABLE t(a int);`を実行し、1000 行のデータを挿入します。 +2. `CREATE TABLE t(a int);`を実行し、1000 行のデータを挿入します。 -3. `select * from t t1 join t t2 join t t3 order by t1.a`を実行します。この SQL 文は 10 億件のレコードを出力し、大量のメモリを消費するため、アラームがトリガーされます。 +3. `select * from t t1 join t t2 join t t3 order by t1.a`を実行します。この SQL 文は 10 億件のレコードを出力し、大量のメモリを消費するため、アラームがトリガーされます。 -4. システムメモリの合計、現在のシステムメモリ使用量、tidb-server インスタンスのメモリ使用量、およびステータス ファイルのディレクトリを記録する`tidb.log`ファイルを確認します。 +4. システムメモリの合計、現在のシステムメモリ使用量、tidb-server インスタンスのメモリ使用量、およびステータス ファイルのディレクトリを記録する`tidb.log`ファイルを確認します。 ``` [2022/10/11 16:39:02.281 +08:00] [WARN] [memoryusagealarm.go:212] ["tidb-server has the risk of OOM because of memory usage exceeds alarm ratio. Running SQLs and heap profile will be recorded in record path"] ["is tidb_server_memory_limit set"=false] ["system memory total"=33682427904] ["system memory usage"=22120655360] ["tidb-server memory usage"=21468556992] [memory-usage-alarm-ratio=0.85] ["record path"=/tiup/deploy/tidb-4000/log/oom_record] @@ -112,14 +112,14 @@ tidb-server インスタンスのメモリ使用量がメモリしきい値 (デ 上記のサンプル ログ ファイルのフィールドは次のように説明されています。 - - `is tidb_server_memory_limit set`は [`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)が設定されているかどうかを示します。 - - `system memory total`は現在のシステムの合計メモリを示します。 - - `system memory usage`は現在のシステムメモリ使用量を示します。 - - `tidb-server memory usage`は、tidb-server インスタンスのメモリ使用量を示します。 - - `memory-usage-alarm-ratio`はシステム変数[`tidb_memory_usage_alarm_ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio)の値を示します。 - - `record path`はステータス ファイルのディレクトリを示します。 + - `is tidb_server_memory_limit set`は [`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)が設定されているかどうかを示します。 + - `system memory total`は現在のシステムの合計メモリを示します。 + - `system memory usage`は現在のシステムメモリ使用量を示します。 + - `tidb-server memory usage`は、tidb-server インスタンスのメモリ使用量を示します。 + - `memory-usage-alarm-ratio`はシステム変数[`tidb_memory_usage_alarm_ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio)の値を示します。 + - `record path`はステータス ファイルのディレクトリを示します。 -5. ステータスファイルのディレクトリ（上記の例ではディレクトリ`/tiup/deploy/tidb-4000/log/oom_record` ）を確認すると、対応するタイムスタンプ（例： `record2022-10-09T17:18:38+08:00` ）を持つレコードディレクトリが表示されます。レコードディレクトリには、 `goroutinue` 、 `heap` 、 `running_sql`の3つのファイルが含まれています。これらの3つのファイルには、ステータスファイルが記録された時刻が末尾に付加されます。これらのファイルには、それぞれ、ゴルーチンのスタック情報、ヒープメモリの使用状況、アラーム発生時の実行SQL情報が記録されています。 `running_sql`の内容については、 [`expensive-queries`](/identify-expensive-queries.md)を参照してください。 +5. ステータスファイルのディレクトリ（上記の例ではディレクトリ`/tiup/deploy/tidb-4000/log/oom_record` ）を確認すると、対応するタイムスタンプ（例： `record2022-10-09T17:18:38+08:00` ）を持つレコードディレクトリが表示されます。レコードディレクトリには、 `goroutinue` 、 `heap` 、 `running_sql`の3つのファイルが含まれています。これらの3つのファイルには、ステータスファイルが記録された時刻が末尾に付加されます。これらのファイルには、それぞれ、ゴルーチンのスタック情報、ヒープメモリの使用状況、アラーム発生時の実行SQL情報が記録されています。 `running_sql`の内容については、 [`expensive-queries`](/identify-expensive-queries.md)を参照してください。 ## tidb-server の書き込みトランザクションのメモリ使用量を削減します {#reduce-the-memory-usage-for-write-transactions-in-tidb-server} @@ -129,21 +129,21 @@ TiDBが使用するトランザクションモデルでは、トランザクシ ### フロー制御 {#flow-control} -- TiDBは、データ読み取り演算子の動的メモリ制御をサポートしています。デフォルトでは、この演算子は[`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency)で許可される最大スレッド数を使用してデータを読み取ります。単一のSQL実行でメモリ使用量が毎回[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)を超えると、データ読み取り演算子は1つのスレッドを停止します。 +- TiDBは、データ読み取り演算子の動的メモリ制御をサポートしています。デフォルトでは、この演算子は[`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency)で許可される最大スレッド数を使用してデータを読み取ります。単一のSQL実行でメモリ使用量が毎回[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)を超えると、データ読み取り演算子は1つのスレッドを停止します。 -- このフロー制御動作は、システム変数[`tidb_enable_rate_limit_action`](/system-variables.md#tidb_enable_rate_limit_action)によって制御されます。 +- このフロー制御動作は、システム変数[`tidb_enable_rate_limit_action`](/system-variables.md#tidb_enable_rate_limit_action)によって制御されます。 -- フロー制御動作がトリガーされると、TiDB はキーワード`memory exceeds quota, destroy one token now`を含むログを出力します。 +- フロー制御動作がトリガーされると、TiDB はキーワード`memory exceeds quota, destroy one token now`を含むログを出力します。 ### ディスクスピル {#disk-spill} TiDBは、実行演算子のディスクへの書き込みをサポートしています。SQL実行のメモリ使用量がメモリクォータを超えた場合、tidb-serverは実行演算子の中間データをディスクに書き出すことで、メモリ負荷を軽減します。ディスクへの書き込みをサポートする演算子には、Sort、MergeJoin、HashJoin、HashAggなどがあります。 -- ディスクスピル動作は、 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 、 [`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom) 、 [`tmp-storage-path`](/tidb-configuration-file.md#tmp-storage-path) 、および[`tmp-storage-quota`](/tidb-configuration-file.md#tmp-storage-quota)パラメータによって共同で制御されます。 -- ディスク スピルがトリガーされると、TiDB はキーワード`memory exceeds quota, spill to disk now`または`memory exceeds quota, set aggregate mode to spill-mode`を含むログを出力します。 -- Sort、MergeJoin、およびHashJoin演算子のディスクスピルはv4.0.0で導入されました。HashAgg演算子の非並列アルゴリズムのディスクスピルはv5.2.0で導入されました。HashAgg演算子の並列アルゴリズムのディスクスピルはv8.0.0で実験的機能として導入され、v8.2.0で一般提供（GA）されました。TopN演算子のディスクスピルはv8.3.0で導入されました。 -- [`tidb_enable_parallel_hashagg_spill`](/system-variables.md#tidb_enable_parallel_hashagg_spill-new-in-v800)システム変数を使用して、ディスクスピルをサポートする並列HashAggアルゴリズムを有効にするかどうかを制御できます。この変数は将来のリリースで廃止される予定です。 -- Sort、MergeJoin、HashJoin、HashAgg、または TopN を含む SQL 実行によって OOM が発生すると、TiDB はデフォルトでディスク スピルをトリガーします。 +- ディスクスピル動作は、 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 、 [`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom) 、 [`tmp-storage-path`](/tidb-configuration-file.md#tmp-storage-path) 、および[`tmp-storage-quota`](/tidb-configuration-file.md#tmp-storage-quota)パラメータによって共同で制御されます。 +- ディスク スピルがトリガーされると、TiDB はキーワード`memory exceeds quota, spill to disk now`または`memory exceeds quota, set aggregate mode to spill-mode`を含むログを出力します。 +- Sort、MergeJoin、およびHashJoin演算子のディスクスピルはv4.0.0で導入されました。HashAgg演算子の非並列アルゴリズムのディスクスピルはv5.2.0で導入されました。HashAgg演算子の並列アルゴリズムのディスクスピルはv8.0.0で実験的機能として導入され、v8.2.0で一般提供（GA）されました。TopN演算子のディスクスピルはv8.3.0で導入されました。 +- [`tidb_enable_parallel_hashagg_spill`](/system-variables.md#tidb_enable_parallel_hashagg_spill-new-in-v800)システム変数を使用して、ディスクスピルをサポートする並列HashAggアルゴリズムを有効にするかどうかを制御できます。この変数は将来のリリースで廃止される予定です。 +- Sort、MergeJoin、HashJoin、HashAgg、または TopN を含む SQL 実行によって OOM が発生すると、TiDB はデフォルトでディスク スピルをトリガーします。 > **Note:** > @@ -151,15 +151,15 @@ TiDBは、実行演算子のディスクへの書き込みをサポートして 次の例では、メモリを消費する SQL ステートメントを使用して、HashAgg のディスク スピル機能を示します。 -1. SQL ステートメントのメモリクォータを 1 GB (デフォルトは 1 GB) に設定します。 +1. SQL ステートメントのメモリクォータを 1 GB (デフォルトは 1 GB) に設定します。 ```sql SET tidb_mem_quota_query = 1 << 30; ``` -2. 単一のテーブル`CREATE TABLE t(a int);`を作成し、256 行の異なるデータを挿入します。 +2. 単一のテーブル`CREATE TABLE t(a int);`を作成し、256 行の異なるデータを挿入します。 -3. 次の SQL ステートメントを実行します。 +3. 次の SQL ステートメントを実行します。 ```sql [tidb]> explain analyze select /*+ HASH_AGG() */ count(*) from t t1 join t t2 join t t3 group by t1.a, t2.a, t3.a; @@ -171,7 +171,7 @@ TiDBは、実行演算子のディスクへの書き込みをサポートして ERROR 1105 (HY000): Out Of Memory Quota![conn_id=3] ``` -4. 同じSQL文を実行します。今回は文が正常に実行され、エラーメッセージは返されません。以下の詳細な実行計画から、HashAggが600MBのハードディスク容量を使用していることがわかります。 +4. 同じSQL文を実行します。今回は文が正常に実行され、エラーメッセージは返されません。以下の詳細な実行計画から、HashAggが600MBのハードディスク容量を使用していることがわかります。 ```sql [tidb]> explain analyze select /*+ HASH_AGG() */ count(*) from t t1 join t t2 join t t3 group by t1.a, t2.a, t3.a; @@ -206,10 +206,10 @@ v6.1.3 <= TiDB < v6.5.0 の場合、手動で`GOMEMLIMIT`を設定する `GOMEMLIMIT`のパフォーマンスを確認するために、 `GOMEMLIMIT`構成の有無での特定のメモリ使用量を比較するテストを実行します。 -- TiDB v6.1.2 では、シミュレートされたワークロードが数分間実行された後、TiDBサーバーはOOM (システムメモリ: 約 48 GiB) に遭遇します。 +- TiDB v6.1.2 では、シミュレートされたワークロードが数分間実行された後、TiDBサーバーはOOM (システムメモリ: 約 48 GiB) に遭遇します。 ![v6.1.2 workload oom](/media/configure-memory-usage-612-oom.png) -- TiDB v6.1.3では、 `GOMEMLIMIT`は40000MiBに設定されています。シミュレーションされたワークロードは長時間安定して動作し、TiDBサーバーでOOMは発生せず、プロセスの最大メモリ使用量は40.8GiB前後で安定していることがわかりました。 +- TiDB v6.1.3では、 `GOMEMLIMIT`は40000MiBに設定されています。シミュレーションされたワークロードは長時間安定して動作し、TiDBサーバーでOOMは発生せず、プロセスの最大メモリ使用量は40.8GiB前後で安定していることがわかりました。 ![v6.1.3 workload no oom with GOMEMLIMIT](/media/configure-memory-usage-613-no-oom.png) diff --git a/configure-placement-rules.md b/configure-placement-rules.md index a3b1fdc374166..c12a75a0b0b36 100644 --- a/configure-placement-rules.md +++ b/configure-placement-rules.md @@ -43,10 +43,10 @@ TiDBバージョン5.0以降では、配置ルール機能はデフォルトで `LabelConstraint`は`notIn` `notExists` `in` `exists`のプリミティブに基づいてラベルをフィルタリングします。これらの4つのプリミティブの意味は次のとおりです。 -- `in` : 指定されたキーのラベル値が指定されたリストに含まれます。 -- `notIn` : 指定されたキーのラベル値は、指定されたリストに含まれていません。 -- `exists` : 指定されたラベル キーが含まれます。 -- `notExists` : 指定されたラベル キーは含まれません。 +- `in` : 指定されたキーのラベル値が指定されたリストに含まれます。 +- `notIn` : 指定されたキーのラベル値は、指定されたリストに含まれていません。 +- `exists` : 指定されたラベル キーが含まれます。 +- `notExists` : 指定されたラベル キーは含まれません。 `LocationLabels`の意味と機能は、v4.0 以前のバージョンと同じです。例えば、 `[zone,rack,host]`をデプロイし、3 層トポロジを定義しているとします。クラスターには複数のゾーン（アベイラビリティゾーン）があり、各ゾーンには複数のラックがあり、各ラックには複数のホストがあります。スケジュールを実行する際、PD はまずリージョンのピアを異なるゾーンに配置しようとします。この試行が失敗した場合（レプリカは 3 つあるがゾーンは合計 2 つしかない場合など）、PD はこれらのレプリカを異なるラックに配置することを保証します。ラック数が分離を保証するのに十分でない場合、PD はホストレベルの分離を試みます。 @@ -100,8 +100,8 @@ PD は、 `max-replicas` 、 `location-labels` 、および`isolation-level`構 > **Note:** > -> - 配置ルールが有効で複数のルールが存在する場合、以前に設定されたルール`max-replicas` 、 `location-labels` 、および`isolation-level`は適用されなくなります。レプリカポリシーを調整するには、配置ルールに関連するインターフェースを使用してください。 -> - 配置ルールが有効になっていて、デフォルト ルールが 1 つだけ存在する場合、 `max-replicas` 、 `location-labels` 、または`isolation-level`が変更されると、TiDB はこのデフォルト ルールを自動的に更新します。 +> - 配置ルールが有効で複数のルールが存在する場合、以前に設定されたルール`max-replicas` 、 `location-labels` 、および`isolation-level`は適用されなくなります。レプリカポリシーを調整するには、配置ルールに関連するインターフェースを使用してください。 +> - 配置ルールが有効になっていて、デフォルト ルールが 1 つだけ存在する場合、 `max-replicas` 、 `location-labels` 、または`isolation-level`が変更されると、TiDB はこのデフォルト ルールを自動的に更新します。 ### 配置ルールを無効にする {#disable-placement-rules} @@ -123,25 +123,25 @@ pd-ctl config placement-rules disable pd-ctl は、システム内のルールを表示するために次のメソッドの使用をサポートしており、出力は JSON 形式のルールまたはルール リストです。 -- すべてのルールのリストを表示するには: +- すべてのルールのリストを表示するには: ```bash pd-ctl config placement-rules show ``` -- PD グループ内のすべてのルールのリストを表示するには: +- PD グループ内のすべてのルールのリストを表示するには: ```bash pd-ctl config placement-rules show --group=pd ``` -- グループ内の特定の ID のルールを表示するには: +- グループ内の特定の ID のルールを表示するには: ```bash pd-ctl config placement-rules show --group=pd --id=default ``` -- リージョンに一致するルール リストを表示するには: +- リージョンに一致するルール リストを表示するには: ```bash pd-ctl config placement-rules show --region=2 @@ -195,25 +195,25 @@ Success! ### pd-ctlを使用してルールグループを構成する {#use-pd-ctl-to-configure-rule-groups} -- すべてのルール グループのリストを表示するには: +- すべてのルール グループのリストを表示するには: ```bash pd-ctl config placement-rules rule-group show ``` -- 特定の ID のルール グループを表示するには: +- 特定の ID のルール グループを表示するには: ```bash pd-ctl config placement-rules rule-group show pd ``` -- ルール グループの`index`と`override`属性を設定するには: +- ルール グループの`index`と`override`属性を設定するには: ```bash pd-ctl config placement-rules rule-group set pd 100 true ``` -- ルール グループの構成を削除するには (グループ内にルールがある場合はデフォルトのグループ構成を使用します)。 +- ルール グループの構成を削除するには (グループ内にルールがある場合はデフォルトのグループ構成を使用します)。 ```bash pd-ctl config placement-rules rule-group delete pd diff --git a/configure-store-limit.md b/configure-store-limit.md index c9e9887383a68..e025e35371202 100644 --- a/configure-store-limit.md +++ b/configure-store-limit.md @@ -17,9 +17,9 @@ PDはオペレータ単位でスケジューリングを実行します。オペ 上記の例では、 `replace-down-replica`演算子には次の特定の演算が含まれています。 -1. ID `20` ～ `store 3`のラーナーピアを追加します。 -2. ID `20` on `store 3`のラーナーピアを投票者に昇格します。 -3. `store 2`のピアを削除します。 +1. ID `20` ～ `store 3`のラーナーピアを追加します。 +2. ID `20` on `store 3`のラーナーピアを投票者に昇格します。 +3. `store 2`のピアを削除します。 ストア制限は、ストアIDとトークンバケットのマッピングをメモリ内に保持することで、ストアレベルの速度制限を実現します。ここでの異なる操作は、それぞれ異なるトークンバケットに対応しています。現在、ストア制限は、ラーナー/ピアの追加とピアの削除という2つの操作の速度制限のみをサポートしています。つまり、各ストアには2種類のトークンバケットがあります。 diff --git a/configure-time-zone.md b/configure-time-zone.md index a9e311714ec98..13392f1fafd14 100644 --- a/configure-time-zone.md +++ b/configure-time-zone.md @@ -7,9 +7,9 @@ summary: TiDBのタイムゾーン設定は、`time_zone`システム変数に TiDBのタイムゾーンは、システム変数[`time_zone`](/system-variables.md#time_zone)によって決定されます。セッションレベルまたはグローバルレベルで設定できます。`time_zone`のデフォルト値は`SYSTEM`です。`SYSTEM`に対応する実際のタイムゾーンは、TiDBクラスタのブートストラップが初期化される際に設定されます。詳細なロジックは次のとおりです。 -1. TiDB は`TZ`環境変数の使用を優先します。 -2. `TZ`環境変数が失敗した場合、TiDB は`/etc/localtime`ソフト リンクからタイム ゾーンを読み取ります。 -3. 上記の両方の方法が失敗した場合、TiDB はシステムタイムゾーンとして`UTC`を使用します。 +1. TiDB は`TZ`環境変数の使用を優先します。 +2. `TZ`環境変数が失敗した場合、TiDB は`/etc/localtime`ソフト リンクからタイム ゾーンを読み取ります。 +3. 上記の両方の方法が失敗した場合、TiDB はシステムタイムゾーンとして`UTC`を使用します。 ## タイムゾーン設定を表示する {#view-time-zone-settings} @@ -23,13 +23,13 @@ SELECT @@global.time_zone, @@session.time_zone, @@global.system_time_zone; TiDB では、 `time_zone`システム変数の値は次のいずれかの形式で設定できます。 -- `SYSTEM` (デフォルト値) は、タイム ゾーンがシステムのタイム ゾーンと同じであることを示します。 -- UTC オフセット（`'+10:00'`または`'-6:00'`など）。 -- `'Europe/Helsinki'` 、 `'US/Eastern'` 、 `'MET'`などの名前付きタイムゾーン。 +- `SYSTEM` (デフォルト値) は、タイム ゾーンがシステムのタイム ゾーンと同じであることを示します。 +- UTC オフセット（`'+10:00'`または`'-6:00'`など）。 +- `'Europe/Helsinki'` 、 `'US/Eastern'` 、 `'MET'`などの名前付きタイムゾーン。 ニーズに応じて、次のように TiDB のタイムゾーンをグローバル レベルまたはセッション レベルで設定できます。 -- TiDB のタイムゾーンをグローバル レベルで設定します。 +- TiDB のタイムゾーンをグローバル レベルで設定します。 ```sql SET GLOBAL time_zone = ${time-zone-value}; @@ -41,7 +41,7 @@ TiDB では、 `time_zone`システム変数の値は次のいずれかの形式 SET GLOBAL time_zone = 'UTC'; ``` -- セッション レベルで TiDB のタイム ゾーンを設定します。 +- セッション レベルで TiDB のタイム ゾーンを設定します。 ```sql SET time_zone = ${time-zone-value}; @@ -110,13 +110,13 @@ select * from t; ## タイムゾーン設定に関する重要な考慮事項 {#important-considerations-for-time-zone-settings} -- `TIMESTAMP`と`DATETIME`値の変換中にはタイムゾーンが関係し、現在のセッションの`time_zone`に基づいて処理されます。 -- データ移行では、プライマリ データベースとセカンダリ データベースのタイム ゾーン設定が一致しているかどうかに特に注意する必要があります。 -- 正確なタイムスタンプを取得するには、ネットワークタイムプロトコル（NTP）または高精度時間プロトコル（PTP）サービスを使用して信頼性の高いクロックを設定することを強くお勧めします。NTPサービスの確認方法については、 [NTPサービスを確認してインストールする](/check-before-deployment.md#check-and-install-the-ntp-service)を参照してください。 -- 夏時間を採用しているタイムゾーンを使用すると、特にそれらのタイムスタンプを使用して計算を実行するときに、タイムスタンプがあいまいになったり、タイムスタンプが存在しなくなったりする可能性があることに注意してください。 -- MySQLは[`mysql_tzinfo_to_sql`](https://dev.mysql.com/doc/refman/8.4/en/mysql-tzinfo-to-sql.html)を使用して、オペレーティングシステムのタイムゾーンデータベースを`mysql`データベースのテーブルに変換します。一方、TiDBはオペレーティングシステムのタイムゾーンデータベースからタイムゾーンデータファイルを直接読み取り、Goプログラミング言語に組み込まれたタイムゾーン処理機能を活用します。 +- `TIMESTAMP`と`DATETIME`値の変換中にはタイムゾーンが関係し、現在のセッションの`time_zone`に基づいて処理されます。 +- データ移行では、プライマリ データベースとセカンダリ データベースのタイム ゾーン設定が一致しているかどうかに特に注意する必要があります。 +- 正確なタイムスタンプを取得するには、ネットワークタイムプロトコル（NTP）または高精度時間プロトコル（PTP）サービスを使用して信頼性の高いクロックを設定することを強くお勧めします。NTPサービスの確認方法については、 [NTPサービスを確認してインストールする](/check-before-deployment.md#check-and-install-the-ntp-service)を参照してください。 +- 夏時間を採用しているタイムゾーンを使用すると、特にそれらのタイムスタンプを使用して計算を実行するときに、タイムスタンプがあいまいになったり、タイムスタンプが存在しなくなったりする可能性があることに注意してください。 +- MySQLは[`mysql_tzinfo_to_sql`](https://dev.mysql.com/doc/refman/8.4/en/mysql-tzinfo-to-sql.html)を使用して、オペレーティングシステムのタイムゾーンデータベースを`mysql`データベースのテーブルに変換します。一方、TiDBはオペレーティングシステムのタイムゾーンデータベースからタイムゾーンデータファイルを直接読み取り、Goプログラミング言語に組み込まれたタイムゾーン処理機能を活用します。 ## 参照 {#see-also} -- [日付と時刻のデータ型](/data-type-date-and-time.md) -- [データと時間関数](/functions-and-operators/date-and-time-functions.md) +- [日付と時刻のデータ型](/data-type-date-and-time.md) +- [データと時間関数](/functions-and-operators/date-and-time-functions.md) diff --git a/constraints.md b/constraints.md index 32b2285a76128..1854626800c7e 100644 --- a/constraints.md +++ b/constraints.md @@ -45,9 +45,9 @@ INSERT INTO users (id,age,last_login) VALUES (NULL,123,NULL); Query OK, 1 row affected (0.03 sec) ``` -- 最初の`INSERT`文は、 `AUTO_INCREMENT`列に`NULL`を割り当てることができるため成功します。TiDBはシーケンス番号を自動的に生成します。 -- 2 番目の`INSERT`ステートメントは、 `age`列が`NOT NULL`として定義されているため失敗します。 -- 3番目の`INSERT`文は、 `last_login`列が明示的に`NOT NULL`として定義されていないため成功します。NULL値はデフォルトで許可されています。 +- 最初の`INSERT`文は、 `AUTO_INCREMENT`列に`NULL`を割り当てることができるため成功します。TiDBはシーケンス番号を自動的に生成します。 +- 2 番目の`INSERT`ステートメントは、 `age`列が`NOT NULL`として定義されているため失敗します。 +- 3番目の`INSERT`文は、 `last_login`列が明示的に`NOT NULL`として定義されていないため成功します。NULL値はデフォルトで許可されています。 ## チェック {#check} @@ -65,22 +65,22 @@ TiDB の`CHECK`制約の構文は MySQL と同じです。 構文の説明: -- `[]` : `[]`内の内容はオプションです。 -- `CONSTRAINT [symbol]` : `CHECK`の制約の名前を指定します。 -- `CHECK (expr)` : 制約条件を指定します。ここで、 `expr`はブール式である必要があります。テーブルの各行について、この式の計算結果は`TRUE` 、 `FALSE` 、または`UNKNOWN` ( `NULL`値の場合) のいずれかである必要があります。ある行の計算結果が`FALSE`の場合、制約に違反していることを示します。 -- `[NOT] ENFORCED` : 制約チェックを実装するかどうかを指定します。これを使用して、制約`CHECK`有効または無効にすることができます。 +- `[]` : `[]`内の内容はオプションです。 +- `CONSTRAINT [symbol]` : `CHECK`の制約の名前を指定します。 +- `CHECK (expr)` : 制約条件を指定します。ここで、 `expr`はブール式である必要があります。テーブルの各行について、この式の計算結果は`TRUE` 、 `FALSE` 、または`UNKNOWN` ( `NULL`値の場合) のいずれかである必要があります。ある行の計算結果が`FALSE`の場合、制約に違反していることを示します。 +- `[NOT] ENFORCED` : 制約チェックを実装するかどうかを指定します。これを使用して、制約`CHECK`有効または無効にすることができます。 ### `CHECK`制約を追加する {#add-check-constraints} TiDB では、 [`CREATE TABLE`](/sql-statements/sql-statement-create-table.md)または[`ALTER TABLE`](/sql-statements/sql-statement-modify-column.md)ステートメントのいずれかを使用して、テーブルに`CHECK`制約を追加できます。 -- `CREATE TABLE`ステートメントを使用して`CHECK`制約を追加する例: +- `CREATE TABLE`ステートメントを使用して`CHECK`制約を追加する例: ```sql CREATE TABLE t(a INT CHECK(a > 10) NOT ENFORCED, b INT, c INT, CONSTRAINT c1 CHECK (b > c)); ``` -- `ALTER TABLE`ステートメントを使用して`CHECK`制約を追加する例: +- `ALTER TABLE`ステートメントを使用して`CHECK`制約を追加する例: ```sql ALTER TABLE t ADD CONSTRAINT CHECK (1 < c); @@ -123,8 +123,8 @@ ALTER TABLE t DROP CONSTRAINT t_chk_1; テーブルに[`CHECK`制約を追加する](#add-check-constraints)設定すると、データの挿入または更新時に TiDB が制約チェックを実装する必要があるかどうかを指定できます。 -- `NOT ENFORCED`を指定すると、TiDB はデータの挿入または更新時に制約条件をチェックしません。 -- `NOT ENFORCED`が指定されていないか`ENFORCED`が指定されている場合、TiDB はデータの挿入または更新中に制約条件をチェックします。 +- `NOT ENFORCED`を指定すると、TiDB はデータの挿入または更新時に制約条件をチェックしません。 +- `NOT ENFORCED`が指定されていないか`ENFORCED`が指定されている場合、TiDB はデータの挿入または更新中に制約条件をチェックします。 制約を追加するときに`[NOT] ENFORCED`を指定するだけでなく、 `ALTER TABLE`ステートメントを使用して`CHECK`制約を有効または無効にすることもできます。例： @@ -134,8 +134,8 @@ ALTER TABLE t ALTER CONSTRAINT c1 NOT ENFORCED; ### MySQLとの互換性 {#mysql-compatibility} -- 列（例： `ALTER TABLE t ADD COLUMN a CHECK(a > 0)` ）の追加時に`CHECK`制約を追加することはサポートされていません。この場合、列のみが正常に追加され、TiDBは`CHECK`制約を無視し、エラーを報告しません。 -- `ALTER TABLE t CHANGE a b int CHECK(b > 0)`を使用して`CHECK`制約を追加することはサポートされていません。この文を実行すると、TiDBはエラーを報告します。 +- 列（例： `ALTER TABLE t ADD COLUMN a CHECK(a > 0)` ）の追加時に`CHECK`制約を追加することはサポートされていません。この場合、列のみが正常に追加され、TiDBは`CHECK`制約を無視し、エラーを報告しません。 +- `ALTER TABLE t CHANGE a b int CHECK(b > 0)`を使用して`CHECK`制約を追加することはサポートされていません。この文を実行すると、TiDBはエラーを報告します。 ## 一意キー {#unique-key} @@ -251,7 +251,7 @@ ERROR 1062 (23000): Duplicate entry 'bill' for key 'users.username' 悲観的トランザクションのパフォーマンスを向上させるには、変数[`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630)を`OFF`に設定できます。これにより、TiDB は一意インデックスの一意制約チェックを（このインデックスが次にロックを必要とするとき、またはトランザクションがコミットされるときまで）延期し、対応する悲観的ロックをスキップします。この変数を使用する際は、以下の点に注意してください。 -- 遅延された一意制約チェックのため、悲観的トランザクションをコミットすると、TiDB は一意制約を満たさない結果を読み取り、エラー`Duplicate entry`を返す場合があります。このエラーが発生すると、TiDB は現在のトランザクションをロールバックします。 +- 遅延された一意制約チェックのため、悲観的トランザクションをコミットすると、TiDB は一意制約を満たさない結果を読み取り、エラー`Duplicate entry`を返す場合があります。このエラーが発生すると、TiDB は現在のトランザクションをロールバックします。 次の例では、ロックを`bill`にスキップするため、TiDB は一意性制約を満たさない結果を取得する可能性があります。 @@ -287,7 +287,7 @@ ERROR 1062 (23000): Duplicate entry 'bill' for key 'users.username' ERROR 1062 (23000): Duplicate entry 'bill' for key 'users.username' ``` -- この変数が無効になっている場合、データの書き込みを必要とする悲観的トランザクションをコミットすると、 `Write conflict`エラーが返される可能性があります。このエラーが発生すると、TiDBは現在のトランザクションをロールバックします。 +- この変数が無効になっている場合、データの書き込みを必要とする悲観的トランザクションをコミットすると、 `Write conflict`エラーが返される可能性があります。このエラーが発生すると、TiDBは現在のトランザクションをロールバックします。 次の例のように、2つの同時トランザクションが同じテーブルにデータを挿入する必要がある場合、悲観的ロックをスキップすると、トランザクションをコミットしたときにTiDBはエラー`Write conflict`を返します。そして、トランザクションはロールバックされます。 @@ -320,9 +320,9 @@ ERROR 1062 (23000): Duplicate entry 'bill' for key 'users.username' ERROR 9007 (HY000): Write conflict, txnStartTS=435688780611190794, conflictStartTS=435688783311536129, conflictCommitTS=435688783311536130, key={tableID=74, indexID=1, indexValues={bill, }} primary={tableID=74, indexID=1, indexValues={bill, }}, reason=LazyUniquenessCheck [try again later] ``` -- この変数が無効になっている場合、複数の悲観的トランザクション間で書き込み競合が発生すると、他の悲観的トランザクションがコミットされた際に悲観的ロックが強制的にロールバックされ、エラー`Pessimistic lock not found`が発生する可能性があります。このエラーが発生した場合、悲観的トランザクションの一意制約チェックを延期することが、アプリケーションのシナリオに適していないことを意味します。この場合、競合を回避するようにアプリケーションロジックを調整するか、エラー発生後にトランザクションを再試行することを検討してください。 +- この変数が無効になっている場合、複数の悲観的トランザクション間で書き込み競合が発生すると、他の悲観的トランザクションがコミットされた際に悲観的ロックが強制的にロールバックされ、エラー`Pessimistic lock not found`が発生する可能性があります。このエラーが発生した場合、悲観的トランザクションの一意制約チェックを延期することが、アプリケーションのシナリオに適していないことを意味します。この場合、競合を回避するようにアプリケーションロジックを調整するか、エラー発生後にトランザクションを再試行することを検討してください。 -- この変数が無効になっている場合、悲観的トランザクションで DML ステートメントを実行するとエラー`8147: LazyUniquenessCheckFailure`が返される可能性があります。 +- この変数が無効になっている場合、悲観的トランザクションで DML ステートメントを実行するとエラー`8147: LazyUniquenessCheckFailure`が返される可能性があります。 > **Note:** > @@ -341,7 +341,7 @@ ERROR 1062 (23000): Duplicate entry 'bill' for key 'users.username' ERROR 8147 (23000): transaction aborted because lazy uniqueness check is enabled and an error occurred: [kv:1062]Duplicate entry 'bill' for key 'users.username' ``` -- この変数が無効になっている場合、 `1062 Duplicate entry`エラーは現在の SQL 文に起因しない可能性があります。そのため、トランザクションが同じ名前のインデックスを持つ複数のテーブルを操作する場合、 `1062`エラーメッセージを確認して、実際にどのインデックスにエラーが発生しているかを特定する必要があります。 +- この変数が無効になっている場合、 `1062 Duplicate entry`エラーは現在の SQL 文に起因しない可能性があります。そのため、トランザクションが同じ名前のインデックスを持つ複数のテーブルを操作する場合、 `1062`エラーメッセージを確認して、実際にどのインデックスにエラーが発生しているかを特定する必要があります。 ## 主キー {#primary-key} @@ -381,9 +381,9 @@ CREATE TABLE t4 (a INT NOT NULL, b INT NOT NULL, PRIMARY KEY (a,b)); Query OK, 0 rows affected (0.10 sec) ``` -- 列`a`が主キーとして定義されており、NULL 値が許可されないため、テーブル`t2`を作成できませんでした。 -- テーブルには主キーを 1 つしか持てないため、テーブル`t3`を作成できませんでした。 -- 主キーは 1 つしか存在できませんが、TiDB では複数の列を複合主キーとして定義することがサポートされているため、テーブル`t4`が正常に作成されました。 +- 列`a`が主キーとして定義されており、NULL 値が許可されないため、テーブル`t2`を作成できませんでした。 +- テーブルには主キーを 1 つしか持てないため、テーブル`t3`を作成できませんでした。 +- 主キーは 1 つしか存在できませんが、TiDB では複数の列を複合主キーとして定義することがサポートされているため、テーブル`t4`が正常に作成されました。 上記のルールに加えて、TiDBは現在、 `NONCLUSTERED`型の主キーの追加と削除のみをサポートしています。例えば： diff --git a/control-execution-plan.md b/control-execution-plan.md index 00bfb069ff7e4..56b9b8ea8a93e 100644 --- a/control-execution-plan.md +++ b/control-execution-plan.md @@ -7,8 +7,8 @@ summary: この章では、TiDB における実行計画の生成を制御する SQLチューニングの最初の2章では、TiDBの実行計画の理解方法と、TiDBが実行計画を生成する方法について解説します。本章では、実行計画の問題点を特定した際に、実行計画の生成を制御するために使用できる方法について説明します。本章の主な内容は以下の3点です。 -- [オプティマイザのヒント](/optimizer-hints.md)では、TiDB が実行計画を生成するようにヒントを使用する方法を学びます。 -- しかし、ヒントはSQL文を侵襲的に変更します。場合によっては、ヒントを単純に挿入することはできません。SQL [SQLプラン管理](/sql-plan-management.md)では、TiDBが別の構文を使用して実行計画の生成を非侵襲的に制御する方法と、バックグラウンドで実行計画を自動的に進化させる方法について説明しています。この方法は、バージョンアップグレードやクラスタのパフォーマンス低下によって引き起こされる実行計画の不安定性などの問題に対処するのに役立ちます。 -- 最後に、[最適化ルールと式のプッシュダウンのブロックリスト](/blocklist-control-plan.md)でブロックリストの使用方法を学びます。 +- [オプティマイザのヒント](/optimizer-hints.md)では、TiDB が実行計画を生成するようにヒントを使用する方法を学びます。 +- しかし、ヒントはSQL文を侵襲的に変更します。場合によっては、ヒントを単純に挿入することはできません。SQL [SQLプラン管理](/sql-plan-management.md)では、TiDBが別の構文を使用して実行計画の生成を非侵襲的に制御する方法と、バックグラウンドで実行計画を自動的に進化させる方法について説明しています。この方法は、バージョンアップグレードやクラスタのパフォーマンス低下によって引き起こされる実行計画の不安定性などの問題に対処するのに役立ちます。 +- 最後に、[最適化ルールと式のプッシュダウンのブロックリスト](/blocklist-control-plan.md)でブロックリストの使用方法を学びます。 上記の方法に加えて、実行計画はいくつかのシステム変数にも影響されます。システムレベルまたはセッションレベルでこれらの変数を変更することで、実行計画の生成を制御できます。v6.5.3およびv7.1.0以降、TiDBは比較的特殊な変数[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)を導入しました。この変数は複数の制御項目を受け入れることができ、クラスタのアップグレード後にオプティマイザの動作変更によって発生するパフォーマンスの低下を防ぐために、オプティマイザの動作をよりきめ細かく制御できます。詳細については[オプティマイザー修正コントロール](/optimizer-fix-controls.md)を参照してください。 diff --git a/coprocessor-cache.md b/coprocessor-cache.md index 22d7ae22922bb..fc47abef05fac 100644 --- a/coprocessor-cache.md +++ b/coprocessor-cache.md @@ -23,30 +23,30 @@ v4.0 以降、TiDB インスタンスは TiKV (コプロセッサーキャッシ ## 機能の説明 {#feature-description} -- 単一の TiDB インスタンスで SQL ステートメントが初めて実行されると、実行結果はキャッシュされません。 +- 単一の TiDB インスタンスで SQL ステートメントが初めて実行されると、実行結果はキャッシュされません。 -- 計算結果はTiDBのメモリにキャッシュされます。TiDBインスタンスを再起動すると、キャッシュは無効になります。 +- 計算結果はTiDBのメモリにキャッシュされます。TiDBインスタンスを再起動すると、キャッシュは無効になります。 -- キャッシュは TiDB インスタンス間で共有されません。 +- キャッシュは TiDB インスタンス間で共有されません。 -- プッシュダウン計算の結果のみがキャッシュされます。キャッシュにヒットした場合でも、TiDBは後続の計算を実行する必要があります。 +- プッシュダウン計算の結果のみがキャッシュされます。キャッシュにヒットした場合でも、TiDBは後続の計算を実行する必要があります。 -- キャッシュはリージョン単位で管理されます。リージョンにデータを書き込むと、リージョンキャッシュは無効になります。そのため、コプロセッサーキャッシュ機能は、主に変更頻度の低いデータに効果を発揮します。 +- キャッシュはリージョン単位で管理されます。リージョンにデータを書き込むと、リージョンキャッシュは無効になります。そのため、コプロセッサーキャッシュ機能は、主に変更頻度の低いデータに効果を発揮します。 -- プッシュダウン計算リクエストが同じ場合、キャッシュにヒットします。通常、以下のシナリオでは、プッシュダウン計算リクエストは同じか、部分的に同じです。 - - SQL文は同じです。例えば、同じSQL文が繰り返し実行されます。 +- プッシュダウン計算リクエストが同じ場合、キャッシュにヒットします。通常、以下のシナリオでは、プッシュダウン計算リクエストは同じか、部分的に同じです。 + - SQL文は同じです。例えば、同じSQL文が繰り返し実行されます。 このシナリオでは、すべてのプッシュダウン計算要求は一貫しており、すべての要求はプッシュダウン計算キャッシュを使用できます。 - - SQL文には変更条件が含まれており、その他の部分は一貫しています。変更条件は、テーブルまたはパーティションの主キーです。 + - SQL文には変更条件が含まれており、その他の部分は一貫しています。変更条件は、テーブルまたはパーティションの主キーです。 このシナリオでは、プッシュダウン計算要求の一部は以前の要求の一部と同じであり、これらの計算要求はキャッシュされた (以前の) プッシュダウン計算結果を使用できます。 - - SQL文には複数の変更条件が含まれており、その他の部分は一貫しています。変更条件は複合インデックス列と完全に一致します。 + - SQL文には複数の変更条件が含まれており、その他の部分は一貫しています。変更条件は複合インデックス列と完全に一致します。 このシナリオでは、プッシュダウン計算要求の一部は以前の要求の一部と同じであり、これらの計算要求はキャッシュされた (以前の) プッシュダウン計算結果を使用できます。 -- この機能はユーザーにとって透過的です。この機能を有効または無効にしても計算結果には影響せず、SQL実行時間のみに影響します。 +- この機能はユーザーにとって透過的です。この機能を有効または無効にしても計算結果には影響せず、SQL実行時間のみに影響します。 ## キャッシュ効果を確認する {#check-the-cache-effect} diff --git a/cost-model.md b/cost-model.md index cd357b8e459ec..9edf5b354216f 100644 --- a/cost-model.md +++ b/cost-model.md @@ -31,8 +31,8 @@ mysql> SHOW CREATE TABLE t; `SELECT * FROM t WHERE b < 100 and c < 100`文を実行するときに、TiDB が`b < 100`条件を満たす行が 20 行、 `c < 100`行が 500 行で、 `INT`種類のインデックスの長さが 8 であると見積もったとします。この場合、TiDB は 2 つのインデックスのコストを計算します。 -- インデックス`b`のコスト = 行数`b < 100` * インデックス`b`の長さ = 20 * 8 = 160 -- インデックス`c`のコスト = 行数`c < 100` * インデックス`c`の長さ = 500 * 8 = 4000 +- インデックス`b`のコスト = 行数`b < 100` * インデックス`b`の長さ = 20 * 8 = 160 +- インデックス`c`のコスト = 行数`c < 100` * インデックス`c`の長さ = 500 * 8 = 4000 インデックス`b`のコストが低いため、TiDB はインデックスとして`b`選択します。 diff --git a/credits.md b/credits.md index b602120cf38f2..7e12465b029d5 100644 --- a/credits.md +++ b/credits.md @@ -11,24 +11,24 @@ summary: TiDB コミュニティへの貢献者のリストと役割について TiDB開発者は、新機能の開発、パフォーマンスの向上、安定性の保証、バグ修正に貢献しています。TiDB関連リポジトリの貢献者リストは次のとおりです。 -- [pingcap/tidb](https://github.com/pingcap/tidb/graphs/contributors) -- [tikv/tikv](https://github.com/tikv/tikv/graphs/contributors) -- [tikv/pd](https://github.com/tikv/pd/graphs/contributors) -- [pingcap/tiflash](https://github.com/pingcap/tiflash/graphs/contributors) -- [pingcap/tidb-operator](https://github.com/pingcap/tidb-operator/graphs/contributors) -- [pingcap/tiup](https://github.com/pingcap/tiup/graphs/contributors) -- [pingcap/tidb-dashboard](https://github.com/pingcap/tidb-dashboard/graphs/contributors) -- [pingcap/tiflow](https://github.com/pingcap/tiflow/graphs/contributors) -- [pingcap/tidb-tools](https://github.com/pingcap/tidb-tools/graphs/contributors) -- [tikv/client-java](https://github.com/tikv/client-java/graphs/contributors) -- [tidb-incubator/TiBigData](https://github.com/tidb-incubator/TiBigData/graphs/contributors) -- [ti-community-infra](https://github.com/orgs/ti-community-infra/people) +- [pingcap/tidb](https://github.com/pingcap/tidb/graphs/contributors) +- [tikv/tikv](https://github.com/tikv/tikv/graphs/contributors) +- [tikv/pd](https://github.com/tikv/pd/graphs/contributors) +- [pingcap/tiflash](https://github.com/pingcap/tiflash/graphs/contributors) +- [pingcap/tidb-operator](https://github.com/pingcap/tidb-operator/graphs/contributors) +- [pingcap/tiup](https://github.com/pingcap/tiup/graphs/contributors) +- [pingcap/tidb-dashboard](https://github.com/pingcap/tidb-dashboard/graphs/contributors) +- [pingcap/tiflow](https://github.com/pingcap/tiflow/graphs/contributors) +- [pingcap/tidb-tools](https://github.com/pingcap/tidb-tools/graphs/contributors) +- [tikv/client-java](https://github.com/tikv/client-java/graphs/contributors) +- [tidb-incubator/TiBigData](https://github.com/tidb-incubator/TiBigData/graphs/contributors) +- [ti-community-infra](https://github.com/orgs/ti-community-infra/people) ## TiDBドキュメントの作成者と翻訳者 {#writers-and-translators-for-tidb-documentation} ライターと翻訳者は、TiDBおよび関連プロジェクトのドキュメントの執筆と翻訳を担当しています。以下は、TiDBドキュメント関連リポジトリの貢献者リストです。 -- [pingcap/ドキュメント-cn](https://github.com/pingcap/docs-cn/graphs/contributors) -- [pingcap/ドキュメント](https://github.com/pingcap/docs/graphs/contributors) -- [pingcap/docs-tidb-operator](https://github.com/pingcap/docs-tidb-operator/graphs/contributors) -- [tikv/ウェブサイト](https://github.com/tikv/website/graphs/contributors) +- [pingcap/ドキュメント-cn](https://github.com/pingcap/docs-cn/graphs/contributors) +- [pingcap/ドキュメント](https://github.com/pingcap/docs/graphs/contributors) +- [pingcap/docs-tidb-operator](https://github.com/pingcap/docs-tidb-operator/graphs/contributors) +- [tikv/ウェブサイト](https://github.com/tikv/website/graphs/contributors) diff --git a/daily-check.md b/daily-check.md index c0973713d7083..64678a477c739 100644 --- a/daily-check.md +++ b/daily-check.md @@ -17,9 +17,9 @@ TiDB Dashboardは、TiDBデータベースの運用と保守を簡素化しま ![Instance panel](/media/instance-status-panel.png) -- **ステータス**：このインジケーターは、ステータスが正常かどうかを確認するために使用されます。オンラインノードの場合は、このインジケーターは無視できます。 -- **稼働時間**：重要な指標です。`Up Time`が変更されている場合は、コンポーネントが再起動された理由を特定する必要があります。 -- **バージョン**、**デプロイメントディレクトリ**、 **Gitハッシュ**：これらの指標を確認することで、バージョンやデプロイメントディレクトリの不整合や誤りを回避できます。 +- **ステータス**：このインジケーターは、ステータスが正常かどうかを確認するために使用されます。オンラインノードの場合は、このインジケーターは無視できます。 +- **稼働時間**：重要な指標です。`Up Time`が変更されている場合は、コンポーネントが再起動された理由を特定する必要があります。 +- **バージョン**、**デプロイメントディレクトリ**、 **Gitハッシュ**：これらの指標を確認することで、バージョンやデプロイメントディレクトリの不整合や誤りを回避できます。 ### ホストパネル {#host-panel} @@ -37,15 +37,15 @@ CPU、メモリ、ディスクの使用状況を確認できます。いずれ ![Region panel](/media/region-panel.png) -- `down-peer-region-count` ： Raftリーダーによって報告された、応答しないピアを持つリージョンの数。 -- `empty-region-count` ：サイズが1MiB未満の空のリージョンの数。これらのリージョンは、 `TRUNCATE TABLE` / `DROP TABLE`ステートメントを実行することによって生成されます。この数が多い場合は、 `Region Merge`有効にして複数のテーブル間でリージョンをマージすることを検討してください。 -- `extra-peer-region-count` ：追加のレプリカを持つリージョンの数。これらのリージョンはスケジューリング処理中に生成されます。 -- `learner-peer-region-count` ：ラーナーピアが存在するリージョンの数。ラーナーピアのソースは様々で、例えば、 TiFlashのラーナーピアや、設定済みの配置ルールに含まれるラーナーピアなどがあります。 -- `miss-peer-region-count` ：レプリカが不足しているリージョンの数。この値は必ずしも`0`より大きいとは限りません。 -- `offline-peer-region-count` ：ピアオフライン処理中のリージョン数。 -- `oversized-region-count` : サイズが`region-max-size`または`region-max-keys`より大きい領域の数。 -- `pending-peer-region-count` ： Raftログが古いリージョンの数。スケジューリング処理中に保留中のピアがいくつか生成されるのは正常です。ただし、この値が一定期間（30分以上）大きい場合は正常ではありません。 -- `undersized-region-count` : サイズが`max-merge-region-size`または`max-merge-region-keys`より小さい領域の数。 +- `down-peer-region-count` ： Raftリーダーによって報告された、応答しないピアを持つリージョンの数。 +- `empty-region-count` ：サイズが1MiB未満の空のリージョンの数。これらのリージョンは、 `TRUNCATE TABLE` / `DROP TABLE`ステートメントを実行することによって生成されます。この数が多い場合は、 `Region Merge`有効にして複数のテーブル間でリージョンをマージすることを検討してください。 +- `extra-peer-region-count` ：追加のレプリカを持つリージョンの数。これらのリージョンはスケジューリング処理中に生成されます。 +- `learner-peer-region-count` ：ラーナーピアが存在するリージョンの数。ラーナーピアのソースは様々で、例えば、 TiFlashのラーナーピアや、設定済みの配置ルールに含まれるラーナーピアなどがあります。 +- `miss-peer-region-count` ：レプリカが不足しているリージョンの数。この値は必ずしも`0`より大きいとは限りません。 +- `offline-peer-region-count` ：ピアオフライン処理中のリージョン数。 +- `oversized-region-count` : サイズが`region-max-size`または`region-max-keys`より大きい領域の数。 +- `pending-peer-region-count` ： Raftログが古いリージョンの数。スケジューリング処理中に保留中のピアがいくつか生成されるのは正常です。ただし、この値が一定期間（30分以上）大きい場合は正常ではありません。 +- `undersized-region-count` : サイズが`max-merge-region-size`または`max-merge-region-keys`より小さい領域の数。 一般的に、これらの指標が小さく、かつゼロ以外の値を示すのは正常なことです。 @@ -61,9 +61,9 @@ TiKVにおけるKVリクエストの所要時間は99です。所要時間が長 TiDBがPDからTSOを取得するのにかかる時間。待ち時間が長くなる理由は以下のとおりです。 -- TiDBからPDへのネットワークレイテンシーが大きい。pingコマンドを手動で実行して、ネットワークレイテンシーをテストできます。 -- TiDBサーバーへの負荷が高い。 -- PDサーバーへの負荷が高い。 +- TiDBからPDへのネットワークレイテンシーが大きい。pingコマンドを手動で実行して、ネットワークレイテンシーをテストできます。 +- TiDBサーバーへの負荷が高い。 +- PDサーバーへの負荷が高い。 ### 概要パネル {#overview-panel} diff --git a/dashboard/continuous-profiling.md b/dashboard/continuous-profiling.md index cb0746d27fa39..6f206db98bd82 100644 --- a/dashboard/continuous-profiling.md +++ b/dashboard/continuous-profiling.md @@ -17,32 +17,32 @@ summary: TiDB Dashboardの継続的プロファイリングにより、専門家 継続的プロファイリングは[手動プロファイリング](/dashboard/dashboard-profiling.md)の拡張機能です。どちらも、各インスタンスの異なる種類のパフォーマンスデータを収集・分析するために使用できます。両者の違いは次のとおりです。 -- 手動プロファイリングでは、プロファイリングを開始した瞬間に短期間 (たとえば 30 秒) のみパフォーマンス データが収集されますが、継続プロファイリングが有効になっている場合は、継続的にデータが収集されます。 -- 手動プロファイリングは現在発生している問題を分析するためにのみ使用できますが、継続的プロファイリングは現在の問題と履歴の問題の両方を分析するために使用できます。 -- 手動プロファイリングでは特定のインスタンスの特定のパフォーマンス データを収集できますが、継続的プロファイリングではすべてのインスタンスのすべてのパフォーマンス データを収集します。 -- 継続的なプロファイリングでは、より多くのパフォーマンス データが保存されるため、より多くのディスク領域が使用されます。 +- 手動プロファイリングでは、プロファイリングを開始した瞬間に短期間 (たとえば 30 秒) のみパフォーマンス データが収集されますが、継続プロファイリングが有効になっている場合は、継続的にデータが収集されます。 +- 手動プロファイリングは現在発生している問題を分析するためにのみ使用できますが、継続的プロファイリングは現在の問題と履歴の問題の両方を分析するために使用できます。 +- 手動プロファイリングでは特定のインスタンスの特定のパフォーマンス データを収集できますが、継続的プロファイリングではすべてのインスタンスのすべてのパフォーマンス データを収集します。 +- 継続的なプロファイリングでは、より多くのパフォーマンス データが保存されるため、より多くのディスク領域が使用されます。 ## サポートされているパフォーマンスデータ {#supported-performance-data} [手動プロファイリング](/dashboard/dashboard-profiling.md#supported-performance-data)内のすべてのパフォーマンス データが収集されます。 -- CPU: TiDB、TiKV、 TiFlash、PDインスタンスの各内部関数のCPUオーバーヘッド +- CPU: TiDB、TiKV、 TiFlash、PDインスタンスの各内部関数のCPUオーバーヘッド -- ヒープ: TiDB、TiKV、PDインスタンス上の各内部関数のメモリ消費量 +- ヒープ: TiDB、TiKV、PDインスタンス上の各内部関数のメモリ消費量 -- ミューテックス: TiDBおよびPDインスタンス上のミューテックスの競合状態 +- ミューテックス: TiDBおよびPDインスタンス上のミューテックスの競合状態 -- Goroutine: TiDB および PD インスタンス上のすべての Goroutine の実行状態と呼び出しスタック +- Goroutine: TiDB および PD インスタンス上のすべての Goroutine の実行状態と呼び出しスタック ## ページにアクセスする {#access-the-page} 継続的プロファイリング ページには、次のいずれかの方法でアクセスできます。 -- TiDB Dashboardにログインした後、左側のナビゲーション メニューで**[高度なデバッグ]** > **[インスタンスのプロファイリング]** > **[継続的なプロファイリング]**をクリックします。 +- TiDB Dashboardにログインした後、左側のナビゲーション メニューで**[高度なデバッグ]** > **[インスタンスのプロファイリング]** > **[継続的なプロファイリング]**をクリックします。 ![Access page](/media/dashboard/dashboard-conprof-access.png) -- ブラウザで[http://127.0.0.1:2379/dashboard/#/continuous_profiling](http://127.0.0.1:2379/dashboard/#/continuous_profiling)にアクセスしてください。`127.0.0.1:2379`を実際のPDインスタンスのアドレスとポートに置き換えてください。 +- ブラウザで[http://127.0.0.1:2379/dashboard/#/continuous_profiling](http://127.0.0.1:2379/dashboard/#/continuous_profiling)にアクセスしてください。`127.0.0.1:2379`を実際のPDインスタンスのアドレスとポートに置き換えてください。 ## 継続的なプロファイリングを有効にする {#enable-continuous-profiling} @@ -54,9 +54,9 @@ summary: TiDB Dashboardの継続的プロファイリングにより、専門家 この機能を有効にするには: -1. [継続的なプロファイリングページ](#access-the-page)ご覧ください。 -2. **Open Settings**をクリックします。右側の**Settings**領域で、 **Enable Feature**をオンにし、必要に応じて**Retention Duration**のデフォルト値を変更します。 -3. **Save**をクリックします。 +1. [継続的なプロファイリングページ](#access-the-page)ご覧ください。 +2. **Open Settings**をクリックします。右側の**Settings**領域で、 **Enable Feature**をオンにし、必要に応じて**Retention Duration**のデフォルト値を変更します。 +3. **Save**をクリックします。 ![Enable feature](/media/dashboard/dashboard-conprof-start.png) @@ -82,10 +82,10 @@ summary: TiDB Dashboardの継続的プロファイリングにより、専門家 ## 継続的なプロファイリングを無効にする {#disable-continuous-profiling} -1. [継続的なプロファイリングページ](#access-the-page)ご覧ください。 -2. 右上隅の歯車アイコンをクリックして設定ページを開きます。 **Enable Feature**をオフにします。 -3. **Save**をクリックします。 -4. ポップアップされたダイアログボックスで、 **[無効にする]**をクリックします。 +1. [継続的なプロファイリングページ](#access-the-page)ご覧ください。 +2. 右上隅の歯車アイコンをクリックして設定ページを開きます。 **Enable Feature**をオフにします。 +3. **Save**をクリックします。 +4. ポップアップされたダイアログボックスで、 **[無効にする]**をクリックします。 ![Disable feature](/media/dashboard/dashboard-conprof-stop.png) diff --git a/dashboard/dashboard-access.md b/dashboard/dashboard-access.md index 2342917c7d561..7e90e59630535 100644 --- a/dashboard/dashboard-access.md +++ b/dashboard/dashboard-access.md @@ -23,9 +23,9 @@ TiDB Dashboardにアクセスするには、ブラウザから[http://127.0.0.1: TiDB Dashboardは、比較的新しいバージョンの次の一般的なデスクトップ ブラウザーで使用できます。 -- Chrome >= 77 -- Firefox >= 68 -- Edge >= 17 +- Chrome >= 77 +- Firefox >= 68 +- Edge >= 17 > **Note:** > @@ -35,16 +35,16 @@ TiDB Dashboardは、比較的新しいバージョンの次の一般的なデス TiDB Dashboardにアクセスすると、ユーザー ログイン インターフェイスに移動します。 -- TiDB `root`アカウントを使用して TiDB Dashboardにサインインできます。 -- TiDB Dashboardには、シングルサインオン（SSO）経由でサインインすることもできます。詳細については、 [TiDB DashboardのSSOを構成する](/dashboard/dashboard-session-sso.md)ご覧ください。 -- [ユーザー定義のSQLユーザー](/dashboard/dashboard-user.md)を作成した場合は、このアカウントと対応するパスワードを使用してサインインできます。 +- TiDB `root`アカウントを使用して TiDB Dashboardにサインインできます。 +- TiDB Dashboardには、シングルサインオン（SSO）経由でサインインすることもできます。詳細については、 [TiDB DashboardのSSOを構成する](/dashboard/dashboard-session-sso.md)ご覧ください。 +- [ユーザー定義のSQLユーザー](/dashboard/dashboard-user.md)を作成した場合は、このアカウントと対応するパスワードを使用してサインインできます。 次のいずれかの状況が存在する場合、ログインが失敗する可能性があります。 -- TiDB `root`ユーザーが存在しません。 -- PD が起動していないか、アクセスできません。 -- TiDB が起動されていないか、アクセスできません。 -- パスワードが`root`間違っています。 +- TiDB `root`ユーザーが存在しません。 +- PD が起動していないか、アクセスできません。 +- TiDB が起動されていないか、アクセスできません。 +- パスワードが`root`間違っています。 サインイン後、セッションは24時間有効です。サインアウトの方法については、 [ログアウト](#logout)セクションをご覧ください。 @@ -52,8 +52,8 @@ TiDB Dashboardにアクセスすると、ユーザー ログイン インター TiDB Dashboardでは次の言語がサポートされています。 -- 英語 -- 中国語（簡体字） +- 英語 +- 中国語（簡体字） **SQL ユーザー サインイン**ページで、**言語の切り替え**ドロップダウン リストをクリックしてインターフェイス言語を切り替えることができます。 diff --git a/dashboard/dashboard-cluster-info.md b/dashboard/dashboard-cluster-info.md index 6451c75f2b8fa..103dd06901dd8 100644 --- a/dashboard/dashboard-cluster-info.md +++ b/dashboard/dashboard-cluster-info.md @@ -11,9 +11,9 @@ summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体 クラスター情報ページにアクセスするには、次の 2 つの方法のいずれかを使用できます。 -- TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**[クラスタ情報]**をクリックします。 +- TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**[クラスタ情報]**をクリックします。 -- ブラウザで[http://127.0.0.1:2379/dashboard/#/cluster_info/instance](http://127.0.0.1:2379/dashboard/#/cluster_info/instance)にアクセスしてください。`127.0.0.1:2379`を実際のPDインスタンスのアドレスとポートに置き換えてください。 +- ブラウザで[http://127.0.0.1:2379/dashboard/#/cluster_info/instance](http://127.0.0.1:2379/dashboard/#/cluster_info/instance)にアクセスしてください。`127.0.0.1:2379`を実際のPDインスタンスのアドレスとポートに置き換えてください。 ## インスタンスリスト {#instance-list} @@ -25,27 +25,27 @@ summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体 リストには次の情報が含まれます。 -- アドレス: インスタンス アドレス。 -- ステータス: インスタンスの実行ステータス。 -- 稼働時間: インスタンスの開始時刻。 -- バージョン: インスタンスのバージョン番号。 -- Git ハッシュ: インスタンス バイナリ ファイルに対応する Git ハッシュ値。 -- デプロイメント ディレクトリ: インスタンス バイナリ ファイルが配置されているディレクトリ。 +- アドレス: インスタンス アドレス。 +- ステータス: インスタンスの実行ステータス。 +- 稼働時間: インスタンスの開始時刻。 +- バージョン: インスタンスのバージョン番号。 +- Git ハッシュ: インスタンス バイナリ ファイルに対応する Git ハッシュ値。 +- デプロイメント ディレクトリ: インスタンス バイナリ ファイルが配置されているディレクトリ。 ### インスタンスのステータス {#instance-status} インスタンスは次のいずれかのステータスで実行できます。 -- 稼働中: インスタンスは正常に実行されています。 -- ダウンまたは到達不能: インスタンスが実行されていないか、対応するホストにネットワークの問題が発生しています。 -- tombstone: インスタンス上のデータが完全に移行され、スケールインが完了しました。このステータスは、TiKV またはTiFlashインスタンスにのみ存在します。 -- 離脱中: インスタンス上のデータが移行中で、スケールインが進行中です。このステータスは、TiKV またはTiFlashインスタンスでのみ表示されます。 -- 不明: インスタンスの実行状態は不明です。 +- 稼働中: インスタンスは正常に実行されています。 +- ダウンまたは到達不能: インスタンスが実行されていないか、対応するホストにネットワークの問題が発生しています。 +- tombstone: インスタンス上のデータが完全に移行され、スケールインが完了しました。このステータスは、TiKV またはTiFlashインスタンスにのみ存在します。 +- 離脱中: インスタンス上のデータが移行中で、スケールインが進行中です。このステータスは、TiKV またはTiFlashインスタンスでのみ表示されます。 +- 不明: インスタンスの実行状態は不明です。 > **Note:** > -> - TiDB Dashboardの`Leaving` 、PD API によって返される`Offline` 、およびTiUPの`Pending Offline`同じステータスを示します。 -> - テーブル内の一部の列は、インスタンスが起動している場合にのみ表示できます。 +> - TiDB Dashboardの`Leaving` 、PD API によって返される`Offline` 、およびTiUPの`Pending Offline`同じステータスを示します。 +> - テーブル内の一部の列は、インスタンスが起動している場合にのみ表示できます。 インスタンスのステータスはPDのスケジュール情報から取得されます。詳細については[情報収集](/tidb-scheduling.md#information-collection)を参照してください。 @@ -59,11 +59,11 @@ summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体 リストには次の情報が含まれます。 -- ホスト アドレス: ホスト IP アドレス。 -- CPU: ホスト CPU の論理コアの数。 -- CPU 使用率: 現在の 1 秒間のユーザー モードとカーネル モードの CPU 使用率。 -- メモリ: ホストの合計物理メモリサイズ。 -- メモリ使用量: ホストの現在のメモリ使用量。 +- ホスト アドレス: ホスト IP アドレス。 +- CPU: ホスト CPU の論理コアの数。 +- CPU 使用率: 現在の 1 秒間のユーザー モードとカーネル モードの CPU 使用率。 +- メモリ: ホストの合計物理メモリサイズ。 +- メモリ使用量: ホストの現在のメモリ使用量。 > **Note:** > @@ -79,12 +79,12 @@ summary: TiDB Dashboardのクラスタ情報ページでは、クラスタ全体 リストには次の情報が含まれます。 -- ホスト アドレス: ホスト IP アドレス。 -- マウント ディレクトリ: インスタンスが実行されているホスト上のこのディスクのマウント パス。 -- ファイル システム: インスタンスが実行されているホスト上のこのディスクのファイル システム タイプ。 -- ディスク容量: インスタンスが実行されているホスト上のディスクの合計容量。 -- ディスク使用量: インスタンスが実行されているホスト上のディスクのスペース使用量。 -- インスタンス: このホスト上で実行されているインスタンス。 +- ホスト アドレス: ホスト IP アドレス。 +- マウント ディレクトリ: インスタンスが実行されているホスト上のこのディスクのマウント パス。 +- ファイル システム: インスタンスが実行されているホスト上のこのディスクのファイル システム タイプ。 +- ディスク容量: インスタンスが実行されているホスト上のディスクの合計容量。 +- ディスク使用量: インスタンスが実行されているホスト上のディスクのスペース使用量。 +- インスタンス: このホスト上で実行されているインスタンス。 > **Note:** > diff --git a/dashboard/dashboard-diagnostics-access.md b/dashboard/dashboard-diagnostics-access.md index 19d4bc743f28a..d618ffc9acaf5 100644 --- a/dashboard/dashboard-diagnostics-access.md +++ b/dashboard/dashboard-diagnostics-access.md @@ -15,19 +15,19 @@ TiDB Dashboardのクラスタ診断機能は、指定された時間範囲内で クラスター診断ページにアクセスするには、次のいずれかの方法を使用できます。 -- TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**Cluster Diagnostics**をクリックします。 +- TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**Cluster Diagnostics**をクリックします。 ![Access Cluster Diagnostics page](/media/dashboard/dashboard-diagnostics-access-v650.png) -- ブラウザで`http://127.0.0.1:2379/dashboard/#/diagnose`にアクセスしてください。`127.0.0.1:2379`を実際のPDアドレスとポート番号に置き換えてください。 +- ブラウザで`http://127.0.0.1:2379/dashboard/#/diagnose`にアクセスしてください。`127.0.0.1:2379`を実際のPDアドレスとポート番号に置き換えてください。 ## 診断レポートを生成する {#generate-diagnostic-report} 指定された時間範囲内でクラスターを診断し、クラスターの負荷を確認するには、次の手順に従って診断レポートを生成します。 -1. **Range Start Time**を`2022-05-21 14:40:00`などに設定します。 -2. **Range Duration**を`10 min`などに設定します。 -3. **Start**をクリックします。 +1. **Range Start Time**を`2022-05-21 14:40:00`などに設定します。 +2. **Range Duration**を`10 min`などに設定します。 +3. **Start**をクリックします。 ![Generate diagnostic report](/media/dashboard/dashboard-diagnostics-gen-report-v650.png) @@ -43,16 +43,16 @@ TiDB Dashboardのクラスタ診断機能は、指定された時間範囲内で 特定の時点でシステム例外が発生した場合（例えば、QPSジッターやレイテンシーの上昇など）、診断レポートを生成できます。このレポートでは、異常な時間帯のシステムと正常な時間帯のシステムを比較します。例えば、 -- 異常時間範囲: `2022-05-21 14:40:00` - `2022-05-21 14:45:00`この時間範囲内では、システムは異常です。 -- 正常な時間範囲: `2022-05-21 14:30:00` - `2022-05-21 14:35:00`この時間範囲内では、システムは正常です。 +- 異常時間範囲: `2022-05-21 14:40:00` - `2022-05-21 14:45:00`この時間範囲内では、システムは異常です。 +- 正常な時間範囲: `2022-05-21 14:30:00` - `2022-05-21 14:35:00`この時間範囲内では、システムは正常です。 前の 2 つの時間範囲の比較レポートを生成するには、次の手順に従います。 -1. システムが異常になる範囲の開始時刻である**Range Start Time**（例： `2022-05-21 14:40:00` ）を設定します。 -2. **Range Duration**を設定します。通常、この期間はシステム異常の継続時間（5分など）です。 -3. **Compare by Baseline**を有効にします。 -4. **Baseline Range Start Time**を設定します。これは、システムが正常である範囲（比較対象）の開始時刻（ `2022-05-21 14:30:00`など）です。 -5. **Start**をクリックします。 +1. システムが異常になる範囲の開始時刻である**Range Start Time**（例： `2022-05-21 14:40:00` ）を設定します。 +2. **Range Duration**を設定します。通常、この期間はシステム異常の継続時間（5分など）です。 +3. **Compare by Baseline**を有効にします。 +4. **Baseline Range Start Time**を設定します。これは、システムが正常である範囲（比較対象）の開始時刻（ `2022-05-21 14:30:00`など）です。 +5. **Start**をクリックします。 ![Generate comparison report](/media/dashboard/dashboard-diagnostics-gen-compare-report-v650.png) diff --git a/dashboard/dashboard-diagnostics-report.md b/dashboard/dashboard-diagnostics-report.md index e86bdc5886bc2..c5fab5b014b15 100644 --- a/dashboard/dashboard-diagnostics-report.md +++ b/dashboard/dashboard-diagnostics-report.md @@ -11,12 +11,12 @@ summary: TiDB Dashboard診断レポートでは、基本情報、診断情報、 診断レポートは次の部分で構成されます。 -- 基本情報: 診断レポートの時間範囲、クラスターのハードウェア情報、クラスター トポロジのバージョン情報が含まれます。 -- 診断情報: 自動診断の結果を表示します。 -- 負荷情報:サーバー、TiDB、PD、または TiKV の CPU、メモリ、その他の負荷情報が含まれます。 -- 概要情報: 各 TiDB、PD、または TiKV モジュールの消費時間とエラー情報が含まれます。 -- TiDB/PD/TiKV 監視情報:各コンポーネントの監視情報が含まれます。 -- コンフィグレーション情報: 各コンポーネントの構成情報が含まれます。 +- 基本情報: 診断レポートの時間範囲、クラスターのハードウェア情報、クラスター トポロジのバージョン情報が含まれます。 +- 診断情報: 自動診断の結果を表示します。 +- 負荷情報:サーバー、TiDB、PD、または TiKV の CPU、メモリ、その他の負荷情報が含まれます。 +- 概要情報: 各 TiDB、PD、または TiKV モジュールの消費時間とエラー情報が含まれます。 +- TiDB/PD/TiKV 監視情報:各コンポーネントの監視情報が含まれます。 +- コンフィグレーション情報: 各コンポーネントの構成情報が含まれます。 診断レポートの例は次のとおりです。 @@ -26,9 +26,9 @@ summary: TiDB Dashboard診断レポートでは、基本情報、診断情報、 このレポートでは、いくつかの小さなボタンについて次のように説明しています。 -- **i**アイコン: マウスを**i**アイコンに移動すると、行の説明が表示されます。 -- **expand** : **expand**をクリックすると、この監視メトリックの詳細が表示されます。例えば、上の画像の`tidb_get_token`の詳細情報には、各 TiDB インスタンスのレイテンシーの監視情報が含まれています。 -- **折りたたみ**：**展開**とは逆に、詳細な監視情報を折りたたむためのボタンです。 +- **i**アイコン: マウスを**i**アイコンに移動すると、行の説明が表示されます。 +- **expand** : **expand**をクリックすると、この監視メトリックの詳細が表示されます。例えば、上の画像の`tidb_get_token`の詳細情報には、各 TiDB インスタンスのレイテンシーの監視情報が含まれています。 +- **折りたたみ**：**展開**とは逆に、詳細な監視情報を折りたたむためのボタンです。 すべての監視メトリックは、基本的にTiDB Grafana監視ダッシュボードのメトリックと一致しています。モジュールに異常が見つかった場合は、TiDB Grafanaで詳細な監視情報を確認できます。 @@ -52,12 +52,12 @@ summary: TiDB Dashboard診断レポートでは、基本情報、診断情報、 上記の表のフィールドの説明は次のとおりです。 -- `HOST` :サーバーの IP アドレス。 -- `INSTANCE` :サーバーにデプロイされているインスタンスの数。たとえば、 `pd * 1`はサーバーに PD インスタンスが 1 つデプロイされていることを意味します。`tidb * 2 pd * 1`は、サーバーに TiDB インスタンスが 2 つと PD インスタンスが 1 つデプロイされていることを意味します。 -- `CPU_CORES` :サーバーの CPU コア数 (物理コアまたは論理コア) を示します。 -- `MEMORY` :サーバーのメモリサイズを示します。単位はGBです。 -- `DISK` :サーバーのディスクサイズを示します。単位はGBです。 -- `UPTIME` :サーバーの稼働時間。単位は日です。 +- `HOST` :サーバーの IP アドレス。 +- `INSTANCE` :サーバーにデプロイされているインスタンスの数。たとえば、 `pd * 1`はサーバーに PD インスタンスが 1 つデプロイされていることを意味します。`tidb * 2 pd * 1`は、サーバーに TiDB インスタンスが 2 つと PD インスタンスが 1 つデプロイされていることを意味します。 +- `CPU_CORES` :サーバーの CPU コア数 (物理コアまたは論理コア) を示します。 +- `MEMORY` :サーバーのメモリサイズを示します。単位はGBです。 +- `DISK` :サーバーのディスクサイズを示します。単位はGBです。 +- `UPTIME` :サーバーの稼働時間。単位は日です。 #### クラスタトポロジ情報 {#cluster-topology-info} @@ -67,13 +67,13 @@ summary: TiDB Dashboard診断レポートでは、基本情報、診断情報、 上記の表のフィールドの説明は次のとおりです。 -- `TYPE` : ノードタイプ。 -- `INSTANCE` : インスタンス アドレス ( `IP:PORT`形式の文字列)。 -- `STATUS_ADDRESS` : HTTP API サービス アドレス。 -- `VERSION` : 対応するノードのセマンティック バージョン番号。 -- `GIT_HASH` : ノード バージョンをコンパイルするときの Git コミット ハッシュ。2 つのノードが完全に一貫したバージョンであるかどうかを識別するために使用されます。 -- `START_TIME` : 対応するノードの開始時刻。 -- `UPTIME` : 対応するノードの稼働時間。 +- `TYPE` : ノードタイプ。 +- `INSTANCE` : インスタンス アドレス ( `IP:PORT`形式の文字列)。 +- `STATUS_ADDRESS` : HTTP API サービス アドレス。 +- `VERSION` : 対応するノードのセマンティック バージョン番号。 +- `GIT_HASH` : ノード バージョンをコンパイルするときの Git コミット ハッシュ。2 つのノードが完全に一貫したバージョンであるかどうかを識別するために使用されます。 +- `START_TIME` : 対応するノードの開始時刻。 +- `UPTIME` : 対応するノードの稼働時間。 ### 診断情報 {#diagnostic-information} @@ -85,17 +85,17 @@ TiDBには自動診断結果が組み込まれています。各フィールド `Node Load Info`テーブルには、時間範囲内でのサーバーの以下のメトリックの平均値 (AVG)、最大値 (MAX)、最小値 (MIN) を含む、サーバーノードの負荷情報が表示されます。 -- CPU使用率（最大値は`100%` ） -- メモリ使用量 -- ディスクI/O使用量 -- ディスク書き込みレイテンシー -- ディスク読み取りレイテンシー -- ディスク読み取りバイト数/秒 -- 1秒あたりのディスク書き込みバイト数 -- ノードネットワークが1分あたりに受信したバイト数 -- ノードネットワークから1分あたりに送信されるバイト数 -- ノードで使用されているTCP接続の数 -- ノードのすべてのTCP接続の数 +- CPU使用率（最大値は`100%` ） +- メモリ使用量 +- ディスクI/O使用量 +- ディスク書き込みレイテンシー +- ディスク読み取りレイテンシー +- ディスク読み取りバイト数/秒 +- 1秒あたりのディスク書き込みバイト数 +- ノードネットワークが1分あたりに受信したバイト数 +- ノードネットワークから1分あたりに送信されるバイト数 +- ノードで使用されているTCP接続の数 +- ノードのすべてのTCP接続の数 ![Server Load Info report](/media/dashboard/dashboard-diagnostics-node-load-info.png) @@ -119,8 +119,8 @@ TiDBには自動診断結果が組み込まれています。各フィールド 上の表では、 -- `CONFIG_KEY` : 対応するモジュールの関連スレッド構成。 -- `CURRENT_CONFIG_VALUE` : レポートが生成された時点の構成の現在の値。 +- `CONFIG_KEY` : 対応するモジュールの関連スレッド構成。 +- `CURRENT_CONFIG_VALUE` : レポートが生成された時点の構成の現在の値。 > **Note:** > @@ -142,15 +142,15 @@ TiDBには自動診断結果が組み込まれています。各フィールド 上記の表の列のフィールドは次のように説明されます。 -- `METRIC_NAME` : 監視メトリックの名前。 -- `Label` : 監視メトリックのラベル情報。**展開を**クリックすると、メトリックの各ラベルの詳細な監視情報が表示されます。 -- `TIME_RATIO` : この監視メトリックによって消費された合計時間と、監視行の合計時間の比率（ `TIME_RATIO`は`1`です。たとえば、 `kv_request`の合計消費時間は`tidb_query`の`1.65`倍（つまり`38325.58` / `23223.86` ）です。KVリクエストは同時に実行されるため、すべてのKVリクエストの合計時間は、クエリの合計実行時間（ `tidb_query` ）を超える可能性があります。 -- `TOTAL_TIME` : この監視メトリックによって消費された合計時間。 -- `TOTAL_COUNT` : この監視メトリックが実行された合計回数。 -- `P999` : この監視メトリックの最大 P999 時間。 -- `P99` : この監視メトリックの最大 P99 時間。 -- `P90` : この監視メトリックの最大 P90 時間。 -- `P80` : この監視メトリックの最大 P80 時間。 +- `METRIC_NAME` : 監視メトリックの名前。 +- `Label` : 監視メトリックのラベル情報。**展開を**クリックすると、メトリックの各ラベルの詳細な監視情報が表示されます。 +- `TIME_RATIO` : この監視メトリックによって消費された合計時間と、監視行の合計時間の比率（ `TIME_RATIO`は`1`です。たとえば、 `kv_request`の合計消費時間は`tidb_query`の`1.65`倍（つまり`38325.58` / `23223.86` ）です。KVリクエストは同時に実行されるため、すべてのKVリクエストの合計時間は、クエリの合計実行時間（ `tidb_query` ）を超える可能性があります。 +- `TOTAL_TIME` : この監視メトリックによって消費された合計時間。 +- `TOTAL_COUNT` : この監視メトリックが実行された合計回数。 +- `P999` : この監視メトリックの最大 P999 時間。 +- `P99` : この監視メトリックの最大 P99 時間。 +- `P90` : この監視メトリックの最大 P90 時間。 +- `P80` : この監視メトリックの最大 P80 時間。 次の画像は、上記の監視メトリックにおける関連モジュールの時間消費の関係を示しています。 @@ -160,43 +160,43 @@ TiDBには自動診断結果が組み込まれています。各フィールド 上の画像では、時間消費量`tidb_query`には次の 4 つの部分が含まれます。 -- `get_token` -- `parse` -- `compile` -- `execute` +- `get_token` +- `parse` +- `compile` +- `execute` `execute`回には次の部分が含まれます。 -- `wait_start_tso` -- 現在監視されていないTiDBレイヤーでの実行時間 -- KVリクエスト時間 -- `KV_backoff`時間、これはKVリクエストが失敗した後のバックオフの時間です +- `wait_start_tso` +- 現在監視されていないTiDBレイヤーでの実行時間 +- KVリクエスト時間 +- `KV_backoff`時間、これはKVリクエストが失敗した後のバックオフの時間です 上記の部分のうち、KV 要求時間には次の部分が含まれます。 -- ネットワークのリクエスト送受信にかかった時間です。現在、この項目の監視指標はありません。KVリクエスト時間から`tikv_grpc_message`差し引くことで、この項目のおおよその見積もりが可能です。 -- 消費時間`tikv_grpc_message` 。 +- ネットワークのリクエスト送受信にかかった時間です。現在、この項目の監視指標はありません。KVリクエスト時間から`tikv_grpc_message`差し引くことで、この項目のおおよその見積もりが可能です。 +- 消費時間`tikv_grpc_message` 。 上記の部品のうち、 `tikv_grpc_message`回の消費量に含まれる部品は以下のとおりです。 -- コプロセッサー要求の消費時間。これは、COPタイプの要求の処理を指します。この消費時間には、以下の部分が含まれます。 - - `tikv_cop_wait` : リクエスト キューによって消費された時間。 - - `Coprocessor handle` :コプロセッサー要求の処理に費やされた時間。 +- コプロセッサー要求の消費時間。これは、COPタイプの要求の処理を指します。この消費時間には、以下の部分が含まれます。 + - `tikv_cop_wait` : リクエスト キューによって消費された時間。 + - `Coprocessor handle` :コプロセッサー要求の処理に費やされた時間。 -- `tikv_scheduler_command`時間の消費で、次の部分が含まれます。 - - `tikv_scheduler_processing_read` : 読み取り要求の処理に費やされた時間。 - - スナップショットを`tikv_storage_async_request`で取得するのにかかった時間 (スナップショットはこの監視メトリックのラベルです)。 - - 書き込みリクエストの処理にかかる時間。この時間消費には以下の部分が含まれます。 - - `tikv_scheduler_latch_wait` : ラッチを待機するのにかかる時間。 - - `tikv_storage_async_request`の書き込みの消費時間 (書き込みはこの監視メトリックのラベルです)。 +- `tikv_scheduler_command`時間の消費で、次の部分が含まれます。 + - `tikv_scheduler_processing_read` : 読み取り要求の処理に費やされた時間。 + - スナップショットを`tikv_storage_async_request`で取得するのにかかった時間 (スナップショットはこの監視メトリックのラベルです)。 + - 書き込みリクエストの処理にかかる時間。この時間消費には以下の部分が含まれます。 + - `tikv_scheduler_latch_wait` : ラッチを待機するのにかかる時間。 + - `tikv_storage_async_request`の書き込みの消費時間 (書き込みはこの監視メトリックのラベルです)。 上記のメトリックのうち、 `tikv_storage_async_request`の書き込み時間の消費は、次の部分を含むRaft KV の書き込み時間の消費を指します。 -- `tikv_raft_propose_wait` -- `tikv_raft_process` 、主に`tikv_raft_append_log`含む -- `tikv_raft_commit_log` -- `tikv_raft_apply_wait` -- `tikv_raft_apply_log` +- `tikv_raft_propose_wait` +- `tikv_raft_process` 、主に`tikv_raft_append_log`含む +- `tikv_raft_commit_log` +- `tikv_raft_apply_wait` +- `tikv_raft_apply_log` `TOTAL_TIME` 、P999 時間、および P99 時間を使用して、上記の時間消費間の関係に従ってどのモジュールがより長い時間を消費しているかを判断し、関連する監視メトリックを確認することができます。 @@ -232,12 +232,12 @@ TiDBには自動診断結果が組み込まれています。各フィールド ![Transaction report](/media/dashboard/dashboard-diagnostics-tidb-txn.png) -- `TOTAL_VALUE` : レポート時間範囲内のすべての値の合計 (SUM)。 -- `TOTAL_COUNT` : この監視メトリックの発生回数の合計。 -- `P999` : この監視メトリックの最大の P999 値。 -- `P99` : この監視メトリックの最大 P99 値。 -- `P90` : この監視メトリックの最大 P90 値。 -- `P80` : この監視メトリックの最大 P80 値。 +- `TOTAL_VALUE` : レポート時間範囲内のすべての値の合計 (SUM)。 +- `TOTAL_COUNT` : この監視メトリックの発生回数の合計。 +- `P999` : この監視メトリックの最大の P999 値。 +- `P99` : この監視メトリックの最大 P99 値。 +- `P90` : この監視メトリックの最大 P90 値。 +- `P80` : この監視メトリックの最大 P80 値。 例： @@ -255,34 +255,34 @@ TiDBには自動診断結果が組み込まれています。各フィールド TiDB のその他の監視テーブルは次のとおりです。 -- 統計情報: TiDB 統計情報の関連する監視メトリックを表示します。 -- スロークエリ上位 10 件: レポートの時間範囲内でスロークエリ上位 10 件の情報を表示します。 -- ダイジェストによるトップ 10 のスロークエリ グループ: SQL フィンガープリントに従って集計された、レポートの時間範囲内の上位 10 件のスロークエリ情報を表示します。 -- 異なるプランを持つスロークエリ: レポートの時間範囲内で実行計画が変更される SQL ステートメント。 +- 統計情報: TiDB 統計情報の関連する監視メトリックを表示します。 +- スロークエリ上位 10 件: レポートの時間範囲内でスロークエリ上位 10 件の情報を表示します。 +- ダイジェストによるトップ 10 のスロークエリ グループ: SQL フィンガープリントに従って集計された、レポートの時間範囲内の上位 10 件のスロークエリ情報を表示します。 +- 異なるプランを持つスロークエリ: レポートの時間範囲内で実行計画が変更される SQL ステートメント。 #### PD関連のモニタリング情報 {#pd-related-monitoring-information} PD モジュールの監視情報に関連するテーブルは次のとおりです。 -- `Time Consumed by PD Component` : PD 内の関連モジュールの監視メトリックによって消費された時間。 -- `Blance Leader/Region` : `tikv_note_1`からスケジュールアウトされたリーダーの数や、スケジュールインされたリーダーの数など、レポート時間範囲内でクラスター内で`balance-region`と`balance leader`の監視情報が発生しました。 -- `Cluster Status` : TiKV ノードの合計数、クラスターの合計ストレージ容量、リージョンの数、オフラインの TiKV ノードの数などのクラスターのステータス情報。 -- `Store Status` :リージョンスコア、リーダー スコア、リージョン/リーダーの数など、各 TiKV ノードのステータス情報を記録します。 -- `Etcd Status` : PD 内の etcd 関連情報。 +- `Time Consumed by PD Component` : PD 内の関連モジュールの監視メトリックによって消費された時間。 +- `Blance Leader/Region` : `tikv_note_1`からスケジュールアウトされたリーダーの数や、スケジュールインされたリーダーの数など、レポート時間範囲内でクラスター内で`balance-region`と`balance leader`の監視情報が発生しました。 +- `Cluster Status` : TiKV ノードの合計数、クラスターの合計ストレージ容量、リージョンの数、オフラインの TiKV ノードの数などのクラスターのステータス情報。 +- `Store Status` :リージョンスコア、リーダー スコア、リージョン/リーダーの数など、各 TiKV ノードのステータス情報を記録します。 +- `Etcd Status` : PD 内の etcd 関連情報。 #### TiKV関連の監視情報 {#tikv-related-monitoring-information} TiKV モジュールの監視情報に関連するテーブルは次のとおりです。 -- `Time Consumed by TiKV Component` : TiKV 内の関連モジュールによって消費された時間。 -- `Time Consumed by RocksDB` : TiKV で RocksDB によって消費された時間。 -- `TiKV Error` : TiKV 内の各モジュールに関連するエラー情報。 -- `TiKV Engine Size` : TiKV 内の各ノード上の列ファミリーの保存データのサイズ。 -- `Coprocessor Info` : TiKV 内のコプロセッサーモジュールに関連する監視情報。 -- `Raft Info` : TiKV 内のRaftモジュールの監視情報。 -- `Snapshot Info` : TiKV 内のスナップショット関連の監視情報。 -- `GC Info` : TiKV 内のガベージ コレクション (GC) 関連の監視情報。 -- `Cache Hit` : TiKV 内の RocksDB の各キャッシュのヒット率情報。 +- `Time Consumed by TiKV Component` : TiKV 内の関連モジュールによって消費された時間。 +- `Time Consumed by RocksDB` : TiKV で RocksDB によって消費された時間。 +- `TiKV Error` : TiKV 内の各モジュールに関連するエラー情報。 +- `TiKV Engine Size` : TiKV 内の各ノード上の列ファミリーの保存データのサイズ。 +- `Coprocessor Info` : TiKV 内のコプロセッサーモジュールに関連する監視情報。 +- `Raft Info` : TiKV 内のRaftモジュールの監視情報。 +- `Snapshot Info` : TiKV 内のスナップショット関連の監視情報。 +- `GC Info` : TiKV 内のガベージ コレクション (GC) 関連の監視情報。 +- `Cache Hit` : TiKV 内の RocksDB の各キャッシュのヒット率情報。 ### コンフィグレーション情報 {#configuration-information} @@ -290,17 +290,17 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり レポート時間範囲内で、次のテーブルにはレポート時間範囲の開始時刻に値が設定される項目が含まれます。 -- `Scheduler Initial Config` : レポートの開始時刻における PD スケジュール関連構成の初期値。 -- `TiDB GC Initial Config` : レポート開始時のTiDB GC関連構成の初期値 -- `TiKV RocksDB Initial Config` : レポート開始時のTiKV RocksDB関連設定の初期値 -- `TiKV RaftStore Initial Config` : レポート開始時の TiKV RaftStore 関連設定の初期値 +- `Scheduler Initial Config` : レポートの開始時刻における PD スケジュール関連構成の初期値。 +- `TiDB GC Initial Config` : レポート開始時のTiDB GC関連構成の初期値 +- `TiKV RocksDB Initial Config` : レポート開始時のTiKV RocksDB関連設定の初期値 +- `TiKV RaftStore Initial Config` : レポート開始時の TiKV RaftStore 関連設定の初期値 レポートの時間範囲内で、一部の構成が変更された場合、次のテーブルには変更された一部の構成のレコードが含まれます。 -- `Scheduler Config Change History` -- `TiDB GC Config Change History` -- `TiKV RocksDB Config Change History` -- `TiKV RaftStore Config Change History` +- `Scheduler Config Change History` +- `TiDB GC Config Change History` +- `TiKV RocksDB Config Change History` +- `TiKV RaftStore Config Change History` 例： @@ -308,14 +308,14 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり 上記の表は、レポート時間範囲内で`leader-schedule-limit`構成パラメータが変更されたことを示しています。 -- `2020-05-22T20:00:00+08:00` : レポートの開始時刻では、構成値`leader-schedule-limit`は`4`です。これは、構成が変更されたことを意味するのではなく、レポート時間範囲の開始時刻では、構成値が`4`あることを意味します。 -- `2020-05-22T20:07:00+08:00` : `leader-schedule-limit`構成値は`8`であり、この構成の値が`2020-05-22T20:07:00+08:00`付近で変更されたことを示します。 +- `2020-05-22T20:00:00+08:00` : レポートの開始時刻では、構成値`leader-schedule-limit`は`4`です。これは、構成が変更されたことを意味するのではなく、レポート時間範囲の開始時刻では、構成値が`4`あることを意味します。 +- `2020-05-22T20:07:00+08:00` : `leader-schedule-limit`構成値は`8`であり、この構成の値が`2020-05-22T20:07:00+08:00`付近で変更されたことを示します。 次の表は、レポートが生成された時点での TiDB、PD、および TiKV の現在の構成を示しています。 -- `TiDB's Current Config` -- `PD's Current Config` -- `TiKV's Current Config` +- `TiDB's Current Config` +- `PD's Current Config` +- `TiKV's Current Config` ## 比較レポート {#comparison-report} @@ -329,9 +329,9 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり スロークエリに関連するテーブルは次のように表示されます。 -- `Slow Queries In Time Range t2` : `t2`にのみ表示され、 `t1`では表示されないスロークエリを表示します。 -- `Top 10 slow query in time range t1` : `t1`期間中のスロークエリ トップ10。 -- `Top 10 slow query in time range t2` : `t2`期間中のスロークエリ トップ10。 +- `Slow Queries In Time Range t2` : `t2`にのみ表示され、 `t1`では表示されないスロークエリを表示します。 +- `Top 10 slow query in time range t1` : `t1`期間中のスロークエリ トップ10。 +- `Top 10 slow query in time range t2` : `t2`期間中のスロークエリ トップ10。 ### DIFF_RATIOの紹介 {#diff-ratio-introduction} @@ -339,18 +339,18 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり ![Compare Instance CPU Usage report](/media/dashboard/dashboard-diagnostics-compare-instance-cpu-usage.png) -- `t1.AVG` 、 `t1.MAX` 、 `t1.Min` 、 `t1`における CPU 使用率の平均値、最大値、最小値です。 -- `t2.AVG` `t2.MAX` `t2.Min` `t2`中のCPU使用率の平均値、最大値、最小値です。 -- `AVG_DIFF_RATIO`は`t1`と`t2`間の平均値の`DIFF_RATIO`です。 -- `MAX_DIFF_RATIO`は`t1`と`t2`間の最大値の`DIFF_RATIO`です。 -- `MIN_DIFF_RATIO`は`t1`と`t2`間の最小値の`DIFF_RATIO`です。 +- `t1.AVG` 、 `t1.MAX` 、 `t1.Min` 、 `t1`における CPU 使用率の平均値、最大値、最小値です。 +- `t2.AVG` `t2.MAX` `t2.Min` `t2`中のCPU使用率の平均値、最大値、最小値です。 +- `AVG_DIFF_RATIO`は`t1`と`t2`間の平均値の`DIFF_RATIO`です。 +- `MAX_DIFF_RATIO`は`t1`と`t2`間の最大値の`DIFF_RATIO`です。 +- `MIN_DIFF_RATIO`は`t1`と`t2`間の最小値の`DIFF_RATIO`です。 `DIFF_RATIO` : 2つの時間範囲の差の値を示します。以下の値があります。 -- 監視メトリックの値が`t2`以内のみで、 `t1`以内の値がない場合は、 `DIFF_RATIO`の値は`1`なります。 -- 監視メトリックの値が`t1`内のみにあり、 `t2`時間範囲内に値がない場合は、 `DIFF_RATIO`の値は`-1`なります。 -- `t2`の値が`t1`より大きい場合、 `DIFF_RATIO` = `(t2.value / t1.value)-1`なります。 -- `t2`の値が`t1`の値より小さい場合、 `DIFF_RATIO` = `1-(t1.value / t2.value)` +- 監視メトリックの値が`t2`以内のみで、 `t1`以内の値がない場合は、 `DIFF_RATIO`の値は`1`なります。 +- 監視メトリックの値が`t1`内のみにあり、 `t2`時間範囲内に値がない場合は、 `DIFF_RATIO`の値は`-1`なります。 +- `t2`の値が`t1`より大きい場合、 `DIFF_RATIO` = `(t2.value / t1.value)-1`なります。 +- `t2`の値が`t1`の値より小さい場合、 `DIFF_RATIO` = `1-(t1.value / t2.value)` たとえば、上の表では、 `t2`の`tidb`ノードの平均 CPU 使用率は`t1`の 2.02 倍、つまり`2.02` = `1240/410-1`です。 @@ -360,9 +360,9 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり ![Maximum Different Item table](/media/dashboard/dashboard-diagnostics-maximum-different-item.png) -- `Table` : この監視メトリックが比較レポート内のどのテーブルから取得されるかを示します。たとえば、 `TiKV, coprocessor_info` TiKVコンポーネントの`coprocessor_info`のテーブルを示します。 -- `METRIC_NAME` : 監視メトリック名。`expand`をクリックすると、メトリックの異なるラベルの比較が表示されます。 -- `LABEL` : 監視メトリックに対応するラベル。例えば、監視メトリック`TiKV Coprocessor scan`には、TiKVアドレス、リクエストタイプ、操作タイプ、操作カラムファミリーを表す2つのラベル（ `instance` 、 `req` 、 `tag` 、 `sql_type` ）があります。 -- `MAX_DIFF` : `t1.VALUE`と`t2.VALUE`の`DIFF_RATIO`を計算した結果の差の値。 +- `Table` : この監視メトリックが比較レポート内のどのテーブルから取得されるかを示します。たとえば、 `TiKV, coprocessor_info` TiKVコンポーネントの`coprocessor_info`のテーブルを示します。 +- `METRIC_NAME` : 監視メトリック名。`expand`をクリックすると、メトリックの異なるラベルの比較が表示されます。 +- `LABEL` : 監視メトリックに対応するラベル。例えば、監視メトリック`TiKV Coprocessor scan`には、TiKVアドレス、リクエストタイプ、操作タイプ、操作カラムファミリーを表す2つのラベル（ `instance` 、 `req` 、 `tag` 、 `sql_type` ）があります。 +- `MAX_DIFF` : `t1.VALUE`と`t2.VALUE`の`DIFF_RATIO`を計算した結果の差の値。 上記の表から、 `t2`時間範囲では`t1`時間範囲よりもコプロセッサー要求がはるかに多く、 `t2`の TiDB の SQL 解析時間が大幅に長くなっていることがわかります。 diff --git a/dashboard/dashboard-diagnostics-usage.md b/dashboard/dashboard-diagnostics-usage.md index a5eca75b373b3..527cf565d8d8e 100644 --- a/dashboard/dashboard-diagnostics-usage.md +++ b/dashboard/dashboard-diagnostics-usage.md @@ -31,13 +31,13 @@ T2: `2020-03-10 13:24:30` ～ `2020-03-10 13:27:30` 。この範囲ではQPSが 上記の診断結果は、診断時間中に大きなクエリが存在する可能性があることを示しています。上記のレポートの各**DETAIL**は以下のように説明されています。 -- `tidb_qps` : QPSが0.93倍減少しました。 -- `tidb_query_duration` : P999 クエリのレイテンシーが1.54 倍増加しました。 -- `tidb_cop_duration` : P999 コプロセッサ要求の処理レイテンシーが 2.48 倍に増加しました。 -- `tidb_kv_write_num` : P999 TiDB トランザクションで書き込まれた KV の数は 7.61 倍に増加しました。 -- `tikv_cop_scan_keys_total_nun` : TiKVコプロセッサーによってスキャンされるキー/値の数が 3 つの TiKV インスタンスで大幅に改善されました。 -- `pd_operator_step_finish_total_count`では、転属リーダー数が2.45倍に増加しており、異常時間帯のスケジュールが正常時間帯のスケジュールよりも高くなっていることがわかります。 -- このレポートは、スロークエリが存在する可能性があることを示しており、SQL文を使用してスロークエリを照会できることを示しています。SQL文の実行結果は次のとおりです。 +- `tidb_qps` : QPSが0.93倍減少しました。 +- `tidb_query_duration` : P999 クエリのレイテンシーが1.54 倍増加しました。 +- `tidb_cop_duration` : P999 コプロセッサ要求の処理レイテンシーが 2.48 倍に増加しました。 +- `tidb_kv_write_num` : P999 TiDB トランザクションで書き込まれた KV の数は 7.61 倍に増加しました。 +- `tikv_cop_scan_keys_total_nun` : TiKVコプロセッサーによってスキャンされるキー/値の数が 3 つの TiKV インスタンスで大幅に改善されました。 +- `pd_operator_step_finish_total_count`では、転属リーダー数が2.45倍に増加しており、異常時間帯のスケジュールが正常時間帯のスケジュールよりも高くなっていることがわかります。 +- このレポートは、スロークエリが存在する可能性があることを示しており、SQL文を使用してスロークエリを照会できることを示しています。SQL文の実行結果は次のとおりです。 ```sql SELECT * FROM (SELECT count(*), min(time), sum(query_time) AS sum_query_time, sum(Process_time) AS sum_process_time, sum(Wait_time) AS sum_wait_time, sum(Commit_time), sum(Request_count), sum(process_keys), sum(Write_keys), max(Cop_proc_max), min(query),min(prev_stmt), digest FROM information_schema.CLUSTER_SLOW_QUERY WHERE time >= '2020-03-10 13:24:30' AND time < '2020-03-10 13:27:30' AND Is_internal = false GROUP BY digest) AS t1 WHERE t1.digest NOT IN (SELECT digest FROM information_schema.CLUSTER_SLOW_QUERY WHERE time >= '2020-03-10 13:21:00' AND time < '2020-03-10 13:24:00' GROUP BY digest) ORDER BY t1.sum_query_time DESC limit 10\G diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index 5528daf925d1f..da1c1ff8f1ce4 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -13,9 +13,9 @@ summary: このドキュメントは、TiDB Dashboardに関するよくある質 クラスター内に複数のPlacement Driver（PD）インスタンスがデプロイされている場合、TiDB Dashboardサービスを実際に実行するPDインスタンスは1つだけです。このPDインスタンスではなく他のPDインスタンスにアクセスすると、ブラウザは別のアドレスにリダイレクトします。TiDB Dashboardへのアクセス用にファイアウォールまたはリバースプロキシが適切に設定されていない場合、ダッシュボードにアクセスした際に、ファイアウォールまたはリバースプロキシによって保護されている内部アドレスにリダイレクトされる可能性があります。 -- 複数の PD インスタンスを使用した TiDB Dashboardの動作原理については、 [TiDB Dashboardのマルチ PD インスタンスの展開](/dashboard/dashboard-ops-deploy.md)を参照してください。 -- リバース プロキシを正しく構成する方法については、 [リバースプロキシ経由でTiDB Dashboardを使用する](/dashboard/dashboard-ops-reverse-proxy.md)を参照してください。 -- ファイアウォールを正しく構成する方法については、 [TiDB Dashboardのセキュリティ保護](/dashboard/dashboard-ops-security.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} @@ -33,16 +33,16 @@ Prometheusインスタンスをデプロイしてもこの問題が引き続き デプロイメントツールがTiUPの場合は、以下の手順に従って問題を解決してください。その他のデプロイメントツールについては、それぞれのツールのドキュメントを参照してください。 -1. TiUPおよびTiUPクラスタのアップグレード: +1. TiUPおよびTiUPクラスタのアップグレード: ```bash tiup update --self tiup update cluster --force ``` -2. アップグレード後、Prometheus インスタンスを使用して新しいクラスターをデプロイすると、メトリックが正常に表示されます。 +2. アップグレード後、Prometheus インスタンスを使用して新しいクラスターをデプロイすると、メトリックが正常に表示されます。 -3. アップグレード後、既存のクラスターを再起動してメトリクスアドレスを報告できます。`CLUSTER_NAME`を実際のクラスター名に置き換えてください。 +3. アップグレード後、既存のクラスターを再起動してメトリクスアドレスを報告できます。`CLUSTER_NAME`を実際のクラスター名に置き換えてください。 ```bash tiup cluster start CLUSTER_NAME @@ -64,7 +64,7 @@ Web ページに`required component NgMonitoring is not started`が表示され ステップ1. バージョンを確認する -1. TiUPクラスターのバージョンを確認してください。NgMonitoring はTiUP v1.9.0 以降の場合にのみデプロイされます。 +1. TiUPクラスターのバージョンを確認してください。NgMonitoring はTiUP v1.9.0 以降の場合にのみデプロイされます。 ```shell tiup cluster --version @@ -78,7 +78,7 @@ Web ページに`required component NgMonitoring is not started`が表示され Git Ref: v1.9.0 ``` -2. TiUPクラスターのバージョンが v1.9.0 より前の場合は、 TiUPとTiUPクラスターを最新バージョンにアップグレードします。 +2. TiUPクラスターのバージョンが v1.9.0 より前の場合は、 TiUPとTiUPクラスターを最新バージョンにアップグレードします。 ```shell tiup update --all @@ -86,13 +86,13 @@ Web ページに`required component NgMonitoring is not started`が表示され ステップ2. TiUPを使用して、コントロールマシンにng_port設定項目を追加します。その後、Prometheusをリロードします。 -1. クラスター構成ファイルを編集モードで開きます。 +1. クラスター構成ファイルを編集モードで開きます。 ```shell tiup cluster edit-config ${cluster-name} ``` -2. `monitoring_servers`の下に`ng_port:12020`パラメータを追加します。 +2. `monitoring_servers`の下に`ng_port:12020`パラメータを追加します。 ``` monitoring_servers: @@ -100,7 +100,7 @@ Web ページに`required component NgMonitoring is not started`が表示され ng_port: 12020 ``` -3. Prometheus をリロードします。 +3. Prometheus をリロードします。 ```shell tiup cluster reload ${cluster-name} --role prometheus @@ -131,18 +131,18 @@ tiup update playground クラスターのアップグレード後に**Slow Queries**ページにエラー`unknown field`が表示される場合、そのエラーはTiDB Dashboardのサーバーフィールド（更新される可能性があります）とユーザー設定フィールド（ブラウザキャッシュ内）の差異に起因する互換性の問題に関連しています。この問題は修正されています。クラスターのバージョンがv5.0.3またはv4.0.14より前の場合は、以下の手順に従ってブラウザキャッシュをクリアしてください。 -1. TiDB Dashboard ページを開きます。 +1. TiDB Dashboard ページを開きます。 -2. 開発者ツールを開きます。ブラウザによって開発者ツールの開き方が異なります。**メニューバー**をクリックした後、以下の手順に従ってください。 +2. 開発者ツールを開きます。ブラウザによって開発者ツールの開き方が異なります。**メニューバー**をクリックした後、以下の手順に従ってください。 - - Firefox:**メニュー**> **Web 開発**>**ツールの切り替え**、または**ツール**> **Web 開発**>**ツールの切り替え**。 - - Chrome:**その他のツール**>**開発者ツール**。 - - Safari:**開発**> **Webインスペクタを表示**。**開発**メニューが表示されない場合は、 **Safari** >**環境設定**>**詳細**に移動し、メニューバーに**開発メニューを表示**チェックボックスをオンにします。 + - Firefox:**メニュー**> **Web 開発**>**ツールの切り替え**、または**ツール**> **Web 開発**>**ツールの切り替え**。 + - Chrome:**その他のツール**>**開発者ツール**。 + - Safari:**開発**> **Webインスペクタを表示**。**開発**メニューが表示されない場合は、 **Safari** >**環境設定**>**詳細**に移動し、メニューバーに**開発メニューを表示**チェックボックスをオンにします。 次の例では、Chrome が使用されています。 ![Opening DevTools from Chrome's main menu](/media/dashboard/dashboard-faq-devtools.png) -3. **Application**パネルを選択し、**Local Storage**メニューを展開して、 **TiDB Dashboardページのドメイン**を選択します。 **Clear All**ボタンをクリックします。 +3. **Application**パネルを選択し、**Local Storage**メニューを展開して、 **TiDB Dashboardページのドメイン**を選択します。 **Clear All**ボタンをクリックします。 ![Clear the Local Storage](/media/dashboard/dashboard-faq-devtools-application.png) diff --git a/dashboard/dashboard-key-visualizer.md b/dashboard/dashboard-key-visualizer.md index 3575a6725690c..6380cdd5634d1 100644 --- a/dashboard/dashboard-key-visualizer.md +++ b/dashboard/dashboard-key-visualizer.md @@ -11,11 +11,11 @@ TiDB DashboardのKey Visualizerページは、TiDBの使用状況を分析し、 Key Visualizer ページにアクセスするには、次の 2 つの方法のいずれかを使用できます。 -- TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**Key Visualizer**をクリックします。 +- TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**Key Visualizer**をクリックします。 ![Access Key Visualizer](/media/dashboard/dashboard-keyviz-access-v650.png) -- ブラウザで[http://127.0.0.1:2379/dashboard/#/keyviz](http://127.0.0.1:2379/dashboard/#/keyviz)にアクセスしてください。`127.0.0.1:2379`を実際のPDインスタンスのアドレスとポートに置き換えてください。 +- ブラウザで[http://127.0.0.1:2379/dashboard/#/keyviz](http://127.0.0.1:2379/dashboard/#/keyviz)にアクセスしてください。`127.0.0.1:2379`を実際のPDインスタンスのアドレスとポートに置き換えてください。 ## インターフェースのデモンストレーション {#interface-demonstration} @@ -25,9 +25,9 @@ Key Visualizer ページにアクセスするには、次の 2 つの方法の 上記のインターフェースから、次のオブジェクトを確認できます。 -- 全体的なトラフィックの経時的な変化を示す大きなヒートマップ。 -- 特定の座標点の詳細情報。 -- テーブルとインデックスの情報 (ヒートマップの左側)。 +- 全体的なトラフィックの経時的な変化を示す大きなヒートマップ。 +- 特定の座標点の詳細情報。 +- テーブルとインデックスの情報 (ヒートマップの左側)。 ## 基本概念 {#basic-concepts} @@ -43,8 +43,8 @@ TiDBクラスタでは、保存されたデータはTiKVインスタンス間に TiDBデータベースを使用する場合、ホットスポット問題が発生することがよくあります。これは、高トラフィックが狭い範囲のデータに集中する現象です。連続したデータ範囲が同じTiKVインスタンスで処理されることが多いため、ホットスポットが発生するTiKVインスタンスは、アプリケーション全体のパフォーマンスのボトルネックとなります。ホットスポット問題は、次のようなシナリオでよく発生します。 -- 主キーが`AUTO_INCREMENT`であるテーブルに隣接するデータを書き込むと、このテーブルでホットスポットの問題が発生します。 -- 隣接する時間データをテーブルの時間インデックスに書き込むと、テーブル インデックスでホットスポットの問題が発生します。 +- 主キーが`AUTO_INCREMENT`であるテーブルに隣接するデータを書き込むと、このテーブルでホットスポットの問題が発生します。 +- 隣接する時間データをテーブルの時間インデックスに書き込むと、テーブル インデックスでホットスポットの問題が発生します。 ホットスポットの詳細については、 [高同時実行書き込みのベストプラクティス](/best-practices/high-concurrency-best-practices.md#hotspot-causes)を参照してください。 @@ -86,15 +86,15 @@ Key Visualizerページを初めてご利用になる場合は、 **Settings** Key Visualizer を開くと、デフォルトで過去 6 時間のデータベース全体のヒートマップが表示されます。このヒートマップでは、右側（現在時刻）に近いほど、各バケット列に対応する時間間隔が短くなります。特定の期間または特定のリージョン範囲を観察したい場合は、拡大して詳細を確認できます。具体的な手順は以下のとおりです。 -1. ヒートマップを上または下にスクロールします。 -2. 範囲を選択するには、次のいずれかのボタンをクリックしてドラッグします。 +1. ヒートマップを上または下にスクロールします。 +2. 範囲を選択するには、次のいずれかのボタンをクリックしてドラッグします。 - - **Select & Zoom**ボタンをクリックします。次に、このボタンをクリック＆ドラッグして、ズームインする領域を選択します。 + - **Select & Zoom**ボタンをクリックします。次に、このボタンをクリック＆ドラッグして、ズームインする領域を選択します。 ![Selection box](/media/dashboard/dashboard-keyviz-select-zoom.gif) - - リージョン範囲をデータベース全体にリセットするには、 **[リセット]**ボタンをクリックします。 - - **時間選択ボックス**(前のインターフェイスの`6 hour`の位置) をクリックし、観測期間を再度選択します。 + - リージョン範囲をデータベース全体にリセットするには、 **[リセット]**ボタンをクリックします。 + - **時間選択ボックス**(前のインターフェイスの`6 hour`の位置) をクリックし、観測期間を再度選択します。 ![Select time](/media/dashboard/dashboard-keyviz-select-time.png) @@ -116,11 +116,11 @@ Key Visualizer を開くと、デフォルトで過去 6 時間のデータベ 関心のあるメトリックを表示するには**、メトリック選択ボックス**(上記のインターフェイスの`Write (bytes)`の位置) でこのメトリックを選択します。 -- `Read (bytes)` : トラフィックを読み取ります。 -- `Write (bytes)` : トラフィックを書き込みます。 -- `Read (keys)` : 読み取られた行数。 -- `Write (keys)` : 書き込まれた行数。 -- `All` : 読み取りトラフィックと書き込みトラフィックの合計。 +- `Read (bytes)` : トラフィックを読み取ります。 +- `Write (bytes)` : トラフィックを書き込みます。 +- `Read (keys)` : 読み取られた行数。 +- `Write (keys)` : 書き込まれた行数。 +- `All` : 読み取りトラフィックと書き込みトラフィックの合計。 ### 更新と自動更新 {#refresh-and-automatic-refresh} diff --git a/dashboard/dashboard-log-search.md b/dashboard/dashboard-log-search.md index a7243c8a5c081..a455d3b059c13 100644 --- a/dashboard/dashboard-log-search.md +++ b/dashboard/dashboard-log-search.md @@ -15,10 +15,10 @@ TiDB Dashboardにログインした後、 **Search Logs**をクリックして このページでは、次の検索パラメータが提供されます。 -- 時間範囲: 検索するログの時間範囲を指定します。デフォルト値は過去30分です。 -- ログレベル: 最小ログレベルを指定します。このログレベルを超えるすべてのログが検索されます。デフォルト値は`INFO`です。 -- キーワード: このパラメータはオプションで、任意の有効な文字列を指定できます。複数のキーワードはスペースで区切られます。正規表現がサポートされています（大文字と小文字は区別されません）。 -- コンポーネント: 検索するクラスターコンポーネントを選択します。複数選択可能で、空でない値を指定する必要があります。デフォルトではすべてのコンポーネントが選択されています。 +- 時間範囲: 検索するログの時間範囲を指定します。デフォルト値は過去30分です。 +- ログレベル: 最小ログレベルを指定します。このログレベルを超えるすべてのログが検索されます。デフォルト値は`INFO`です。 +- キーワード: このパラメータはオプションで、任意の有効な文字列を指定できます。複数のキーワードはスペースで区切られます。正規表現がサポートされています（大文字と小文字は区別されません）。 +- コンポーネント: 検索するクラスターコンポーネントを選択します。複数選択可能で、空でない値を指定する必要があります。デフォルトではすべてのコンポーネントが選択されています。 **Search**ボタンをクリックすると、検索結果の詳細ページが表示されます。 @@ -30,13 +30,13 @@ TiDB Dashboardにログインした後、 **Search Logs**をクリックして このページは次の 3 つの領域で構成されています。 -- パラメータオプション（上記画像のエリア1）：これらのオプションは、検索ホームページのパラメータオプションと同じです。ボックス内のパラメータを再度選択して、新しい検索を開始できます。 -- 進行状況 (上記画像の領域 2): ログ検索ステータスや各ノードの統計情報など、現在の検索進行状況がこのページの右側に表示されます。 -- 検索結果（上記画像の領域3）: - - 時間: ログが生成された時刻。タイムゾーンはフロントエンドユーザーのタイムゾーンと同じです。 - - レベル: ログ レベル。 - - コンポーネント:コンポーネント名とアドレスを表示します。 - - ログ: 各ログレコードの本文部分（ログ時間とログレベルを除く）。ログが長すぎる場合は自動的に切り捨てられます。行をクリックすると、全内容が表示されます。ログ全体は最大512文字まで表示できます。 +- パラメータオプション（上記画像のエリア1）：これらのオプションは、検索ホームページのパラメータオプションと同じです。ボックス内のパラメータを再度選択して、新しい検索を開始できます。 +- 進行状況 (上記画像の領域 2): ログ検索ステータスや各ノードの統計情報など、現在の検索進行状況がこのページの右側に表示されます。 +- 検索結果（上記画像の領域3）: + - 時間: ログが生成された時刻。タイムゾーンはフロントエンドユーザーのタイムゾーンと同じです。 + - レベル: ログ レベル。 + - コンポーネント:コンポーネント名とアドレスを表示します。 + - ログ: 各ログレコードの本文部分（ログ時間とログレベルを除く）。ログが長すぎる場合は自動的に切り捨てられます。行をクリックすると、全内容が表示されます。ログ全体は最大512文字まで表示できます。 > **Note:** > @@ -46,15 +46,15 @@ TiDB Dashboardにログインした後、 **Search Logs**をクリックして 検索進行状況エリアでは、ノード上の検索は検索タスクと呼ばれます。検索タスクには以下のステータスがあります。 -- 実行中: 検索を開始すると、すべてのタスクが**Running**ステータスになります。 -- 成功: タスクが完了すると、自動的に**Success**ステータスになります。この時点で、ログはダッシュボードバックエンドが配置されているローカルディスクにキャッシュされており、フロントエンドに提供してダウンロードできます。 -- 失敗: 検索タスクをキャンセルした場合、またはタスクがエラーで終了した場合、タスクは**Failed**ステータスになります。タスクが失敗すると、ローカルの一時ファイルは自動的に消去されます。 +- 実行中: 検索を開始すると、すべてのタスクが**Running**ステータスになります。 +- 成功: タスクが完了すると、自動的に**Success**ステータスになります。この時点で、ログはダッシュボードバックエンドが配置されているローカルディスクにキャッシュされており、フロントエンドに提供してダウンロードできます。 +- 失敗: 検索タスクをキャンセルした場合、またはタスクがエラーで終了した場合、タスクは**Failed**ステータスになります。タスクが失敗すると、ローカルの一時ファイルは自動的に消去されます。 検索進行領域には、次の 3 つのコントロール ボタンがあります。 -- **Download Selected**: このボタンをクリックすると、選択したコンポーネント（完了したコンポーネントのみ選択可能）のログがダウンロードされ、tarファイルが生成されます。このtarファイルを解凍すると、1つまたは複数のzipファイルが生成されます（各コンポーネントに対応するzipファイルが1つずつあります）。zipファイルを解凍すると、ログテキストファイルが生成されます。 -- **Cancel**：このボタンをクリックすると、実行中のすべてのタスクがキャンセルされます。このボタンは、実行中のタスクがある場合にのみクリックできます。 -- **Retry**：このボタンをクリックすると、失敗したタスクがすべて再試行されます。このボタンは、失敗したタスクがあり、実行中のタスクがない場合にのみクリックできます。 +- **Download Selected**: このボタンをクリックすると、選択したコンポーネント（完了したコンポーネントのみ選択可能）のログがダウンロードされ、tarファイルが生成されます。このtarファイルを解凍すると、1つまたは複数のzipファイルが生成されます（各コンポーネントに対応するzipファイルが1つずつあります）。zipファイルを解凍すると、ログテキストファイルが生成されます。 +- **Cancel**：このボタンをクリックすると、実行中のすべてのタスクがキャンセルされます。このボタンは、実行中のタスクがある場合にのみクリックできます。 +- **Retry**：このボタンをクリックすると、失敗したタスクがすべて再試行されます。このボタンは、失敗したタスクがあり、実行中のタスクがない場合にのみクリックできます。 ## 検索履歴リスト {#search-history-list} diff --git a/dashboard/dashboard-metrics-relation.md b/dashboard/dashboard-metrics-relation.md index 0d63934b2b3d7..733ada63e5f64 100644 --- a/dashboard/dashboard-metrics-relation.md +++ b/dashboard/dashboard-metrics-relation.md @@ -23,9 +23,9 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー たとえば、監視メトリック`tidb_execute`のノードの意味は次のとおりです。 -- `tidb_execute`監視メトリックの合計実行時間は 19306.46 秒で、これはクエリの合計実行時間の 89.4% を占めます。 -- `tidb_execute`ノード自体の継続時間は 9070.18 秒で、これはクエリ全体の継続時間の 42% を占めます。 -- ボックス領域にマウスを移動すると、合計期間、平均期間、平均 P99 (99 パーセンタイル) 期間などのメトリックの詳細情報が表示されます。 +- `tidb_execute`監視メトリックの合計実行時間は 19306.46 秒で、これはクエリの合計実行時間の 89.4% を占めます。 +- `tidb_execute`ノード自体の継続時間は 9070.18 秒で、これはクエリ全体の継続時間の 42% を占めます。 +- ボックス領域にマウスを移動すると、合計期間、平均期間、平均 P99 (99 パーセンタイル) 期間などのメトリックの詳細情報が表示されます。 ![tidb\_execute node example](/media/dashboard/dashboard-metrics-relation-node-example.png) @@ -33,17 +33,17 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー 各ボックス領域は監視メトリックを表し、次の情報を提供します。 -- 監視メトリックの名前 -- 監視メトリックの合計期間 -- メトリックの合計期間とクエリの合計期間の割合 +- 監視メトリックの名前 +- 監視メトリックの合計期間 +- メトリックの合計期間とクエリの合計期間の割合 *メトリックノードの合計継続時間*=*メトリックノード自体の継続時間*+*その子ノードの継続時間*。したがって、一部のノードのメトリックグラフには、 `tidb_execute`のグラフのように、ノード自体の継続時間が合計継続時間に対する割合が表示されます。 ![tidb\_execute node example1](/media/dashboard/dashboard-metrics-relation-node-example1.png) -- `tidb_execute` 、TiDB 実行エンジンでの SQL クエリの実行期間を表す監視メトリックの名前です。 -- `19306.46s`は、メトリック`tidb_execute`の合計実行時間が 19306.46 秒であることを示します。`89.40%`は、19306.46 秒がすべての SQL クエリ（ユーザー SQL クエリと TiDB 内部 SQL クエリを含む）の合計実行時間の 89.40% を占めていることを示します。クエリの合計実行時間は、 `tidb_query`の合計実行時間です。 -- `9070.18s`は、 `tidb_execute`ノード自体の合計実行時間が 9070.18 秒であり、残りがその子ノードによって消費された時間であることを表します。`42.00%`は、9070.18 秒がすべてのクエリの合計クエリ時間の 42.00% を占めることを表します。 +- `tidb_execute` 、TiDB 実行エンジンでの SQL クエリの実行期間を表す監視メトリックの名前です。 +- `19306.46s`は、メトリック`tidb_execute`の合計実行時間が 19306.46 秒であることを示します。`89.40%`は、19306.46 秒がすべての SQL クエリ（ユーザー SQL クエリと TiDB 内部 SQL クエリを含む）の合計実行時間の 89.40% を占めていることを示します。クエリの合計実行時間は、 `tidb_query`の合計実行時間です。 +- `9070.18s`は、 `tidb_execute`ノード自体の合計実行時間が 9070.18 秒であり、残りがその子ノードによって消費された時間であることを表します。`42.00%`は、9070.18 秒がすべてのクエリの合計クエリ時間の 42.00% を占めることを表します。 ボックス領域にマウスを移動すると、 `tidb_execute`メトリック ノードの詳細が表示されます。 @@ -59,8 +59,8 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー 上のグラフから、 `tidb_execute`の 2 つの子ノードがわかります。 -- `pd_start_tso_wait` : トランザクションの`start_tso`待機する合計時間。これは 300.66 秒です。 -- `tidb_txn_cmd` : TiDB が関連するトランザクション コマンドを実行する合計時間。9935.62 秒です。 +- `pd_start_tso_wait` : トランザクションの`start_tso`待機する合計時間。これは 300.66 秒です。 +- `tidb_txn_cmd` : TiDB が関連するトランザクション コマンドを実行する合計時間。9935.62 秒です。 さらに、 `tidb_execute`は`tidb_cop`ボックス領域を指す点線の矢印もあり、次のことを示しています。 @@ -76,13 +76,13 @@ TiDB Dashboardにログイン後、左側のナビゲーション メニュー `tidb_kv_request`の親ノードである`tidb_cop`と`tidb_txn_cmd.get`は、どちらも`tidb_kv_request`を指す点線矢印があり、次のことを示しています。 -- `tidb_cop`の持続時間には`tidb_kv_request`の持続時間の一部が含まれます。 -- `tidb_txn_cmd.get`の持続時間には`tidb_kv_request`の持続時間の一部も含まれます。 +- `tidb_cop`の持続時間には`tidb_kv_request`の持続時間の一部が含まれます。 +- `tidb_txn_cmd.get`の持続時間には`tidb_kv_request`の持続時間の一部も含まれます。 しかし、 `tidb_kv_request`の持続時間が`tidb_cop`にどれだけ含まれているかを判断することは困難です。 -- `tidb_kv_request.Get` : TiDB が`Get`種類のキー値要求を送信する期間。 -- `tidb_kv_request.Cop` : TiDB が`Cop`種類のキー値要求を送信する期間。 +- `tidb_kv_request.Get` : TiDB が`Get`種類のキー値要求を送信する期間。 +- `tidb_kv_request.Cop` : TiDB が`Cop`種類のキー値要求を送信する期間。 `tidb_kv_request`子ノードとして`tidb_kv_request.Get`と`tidb_kv_request.Cop`ノードを含みませんが、後者の2つのノードで構成されます。子ノードの名前プレフィックスは親ノードの名前に`.xxx`を加えたもので、これは子ノードが親ノードのサブクラスであることを意味します。このケースは次のように理解できます。 diff --git a/dashboard/dashboard-monitoring.md b/dashboard/dashboard-monitoring.md index 0ffc5fcdba1fe..bf863e83e8780 100644 --- a/dashboard/dashboard-monitoring.md +++ b/dashboard/dashboard-monitoring.md @@ -21,38 +21,38 @@ TiDBクラスターをTiUPを使用してデプロイした場合、Grafanaで パフォーマンス概要ダッシュボードは、TiDB、PD、および TiKV のメトリックを調整し、それぞれを次のセクションで表示します。 -- **Overview**：データベース時間とSQL実行時間の概要。概要で異なる色を確認することで、データベースのワークロードプロファイルとパフォーマンスのボトルネックを素早く特定できます。 +- **Overview**：データベース時間とSQL実行時間の概要。概要で異なる色を確認することで、データベースのワークロードプロファイルとパフォーマンスのボトルネックを素早く特定できます。 -- **負荷プロファイル**: データベース QPS、接続情報、アプリケーションが TiDB と対話する MySQL コマンド タイプ、データベース内部 TSO および KV 要求 OPS、TiKV および TiDB のリソース使用量など、主要なメトリックとリソース使用量。 +- **負荷プロファイル**: データベース QPS、接続情報、アプリケーションが TiDB と対話する MySQL コマンド タイプ、データベース内部 TSO および KV 要求 OPS、TiKV および TiDB のリソース使用量など、主要なメトリックとリソース使用量。 -- **トップダウンのレイテンシーの内訳**: クエリレイテンシーと接続アイドル時間の比率、クエリレイテンシーの内訳、実行中の TSO/KV 要求レイテンシー、TiKV 内の書き込みレイテンシーの内訳。 +- **トップダウンのレイテンシーの内訳**: クエリレイテンシーと接続アイドル時間の比率、クエリレイテンシーの内訳、実行中の TSO/KV 要求レイテンシー、TiKV 内の書き込みレイテンシーの内訳。 次のセクションでは、パフォーマンス概要ダッシュボードのメトリックについて説明します。 ### SQLタイプ別のデータベース時間 {#database-time-by-sql-type} -- `database time` : 1秒あたりの合計データベース時間 -- `sql_type` : 各タイプのSQL文が1秒あたりに消費するデータベース時間 +- `database time` : 1秒あたりの合計データベース時間 +- `sql_type` : 各タイプのSQL文が1秒あたりに消費するデータベース時間 ### SQLフェーズ別のデータベース時間 {#database-time-by-sql-phase} -- `database time` : 1秒あたりの合計データベース時間 -- `get token/parse/compile/execute` : 4つのSQL処理フェーズで消費されたデータベース時間 +- `database time` : 1秒あたりの合計データベース時間 +- `get token/parse/compile/execute` : 4つのSQL処理フェーズで消費されたデータベース時間 SQL実行フェーズは緑色で、その他のフェーズは全体的に赤色で表示されます。緑色以外の領域が大きい場合は、実行フェーズ以外のフェーズでデータベース時間が大量に消費されていることを意味し、さらなる原因分析が必要です。 ### SQL実行時間の概要 {#sql-execute-time-overview} -- `execute time` : SQL実行中に1秒あたりに消費されたデータベース時間 -- `tso_wait` : SQL実行中の1秒あたりの同時TSO待機時間 -- `kv request type` ：SQL実行中に各KVリクエストタイプを1秒あたりに待機する時間。KVリクエストは同時実行されるため、合計KVリクエスト待機時間はSQL実行時間を超える場合があります。 +- `execute time` : SQL実行中に1秒あたりに消費されたデータベース時間 +- `tso_wait` : SQL実行中の1秒あたりの同時TSO待機時間 +- `kv request type` ：SQL実行中に各KVリクエストタイプを1秒あたりに待機する時間。KVリクエストは同時実行されるため、合計KVリクエスト待機時間はSQL実行時間を超える場合があります。 緑色のメトリクスは一般的なKV書き込みリクエスト（プリライトやコミットなど）を表し、青色のメトリクスは一般的な読み取りリクエストを表します。その他の色のメトリクスは、注意が必要な予期しない状況を表します。例えば、悲観的ロックKVリクエストは赤色で、TSO待機は濃い茶色で表示されます。 青または緑以外の領域が大きい場合は、SQL実行中にボトルネックが発生していることを意味します。例： -- 重大なロック競合が発生した場合、赤色の領域が大きな割合を占めることになります。 -- TSO の待ち時間に過度に時間がかかってしまうと、濃い茶色の領域が大きな割合を占めることになります。 +- 重大なロック競合が発生した場合、赤色の領域が大きな割合を占めることになります。 +- TSO の待ち時間に過度に時間がかかってしまうと、濃い茶色の領域が大きな割合を占めることになります。 ### QPS {#qps} @@ -68,81 +68,81 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 ### KV/TSO リクエスト OPS {#kv-tso-request-ops} -- kvリクエスト合計: すべてのTiDBインスタンスにおける1秒あたりのKVリクエストの合計数 -- タイプ別の KV リクエスト数: `Get`など`Commit`タイプに基づいて`Prewrite`すべての TiDB インスタンスでの 1 秒あたりの KV リクエスト数 -- tso - cmd: TiDB がすべての TiDB インスタンスの PD に送信する 1 秒あたりの gRPC リクエストの数。各 gRPC リクエストには、TSO リクエストのバッチが含まれます。 -- tso - リクエスト: すべての TiDB インスタンスにおける 1 秒あたりの TSO リクエスト数 +- kvリクエスト合計: すべてのTiDBインスタンスにおける1秒あたりのKVリクエストの合計数 +- タイプ別の KV リクエスト数: `Get`など`Commit`タイプに基づいて`Prewrite`すべての TiDB インスタンスでの 1 秒あたりの KV リクエスト数 +- tso - cmd: TiDB がすべての TiDB インスタンスの PD に送信する 1 秒あたりの gRPC リクエストの数。各 gRPC リクエストには、TSO リクエストのバッチが含まれます。 +- tso - リクエスト: すべての TiDB インスタンスにおける 1 秒あたりの TSO リクエスト数 通常、 `tso - request` `tso - cmd`で割った値が、1 秒あたりの TSO 要求バッチの平均サイズになります。 ### 接続数 {#connection-count} -- `total` : すべてのTiDBインスタンスへの接続数 -- `active connections` : すべてのTiDBインスタンスへのアクティブな接続の数 -- 各TiDBインスタンスへの接続数 +- `total` : すべてのTiDBインスタンスへの接続数 +- `active connections` : すべてのTiDBインスタンスへのアクティブな接続の数 +- 各TiDBインスタンスへの接続数 ### TiDB CPU/メモリ {#tidb-cpu-memory} -- `CPU-Avg` : すべての TiDB インスタンスの平均 CPU 使用率 -- `CPU-Delta` : すべての TiDB インスタンスの最大 CPU 使用率からすべての TiDB インスタンスの最小 CPU 使用率を引いた値 -- `CPU-Max` : すべての TiDB インスタンスの最大 CPU 使用率 -- `CPU-Quota` : TiDBが使用できるCPUコアの数 -- `Mem-Max` : すべての TiDB インスタンスの最大メモリ使用率 +- `CPU-Avg` : すべての TiDB インスタンスの平均 CPU 使用率 +- `CPU-Delta` : すべての TiDB インスタンスの最大 CPU 使用率からすべての TiDB インスタンスの最小 CPU 使用率を引いた値 +- `CPU-Max` : すべての TiDB インスタンスの最大 CPU 使用率 +- `CPU-Quota` : TiDBが使用できるCPUコアの数 +- `Mem-Max` : すべての TiDB インスタンスの最大メモリ使用率 ### TiKV CPU/メモリ {#tikv-cpu-memory} -- `CPU-Avg` : すべての TiKV インスタンスの平均 CPU 使用率 -- `CPU-Delta` : すべての TiKV インスタンスの最大 CPU 使用率からすべての TiKV インスタンスの最小 CPU 使用率を引いた値 -- `CPU-Max` : すべての TiKV インスタンスの最大 CPU 使用率 -- `CPU-Quota` : TiKVが使用できるCPUコアの数 -- `Mem-Max` : すべての TiKV インスタンスの最大メモリ使用率 +- `CPU-Avg` : すべての TiKV インスタンスの平均 CPU 使用率 +- `CPU-Delta` : すべての TiKV インスタンスの最大 CPU 使用率からすべての TiKV インスタンスの最小 CPU 使用率を引いた値 +- `CPU-Max` : すべての TiKV インスタンスの最大 CPU 使用率 +- `CPU-Quota` : TiKVが使用できるCPUコアの数 +- `Mem-Max` : すべての TiKV インスタンスの最大メモリ使用率 ### PD CPU/メモリ {#pd-cpu-memory} -- `CPU-Max` : すべてのPDインスタンスの最大CPU使用率 -- `CPU-Quota` : PDが使用できるCPUコアの数 -- `Mem-Max` : すべてのPDインスタンスの最大メモリ使用率 +- `CPU-Max` : すべてのPDインスタンスの最大CPU使用率 +- `CPU-Quota` : PDが使用できるCPUコアの数 +- `Mem-Max` : すべてのPDインスタンスの最大メモリ使用率 ### トラフィックを読む {#read-traffic} -- `TiDB -> Client` : TiDBからクライアントへの送信トラフィック統計 -- `Rocksdb -> TiKV` :ストレージレイヤー内での読み取り操作中に TiKV が RocksDB から取得するデータフロー +- `TiDB -> Client` : TiDBからクライアントへの送信トラフィック統計 +- `Rocksdb -> TiKV` :ストレージレイヤー内での読み取り操作中に TiKV が RocksDB から取得するデータフロー ### 書き込みトラフィック {#write-traffic} -- `Client -> TiDB` : クライアントから TiDB への受信トラフィック統計 -- `TiDB -> TiKV: general` : フォアグラウンドトランザクションが TiDB から TiKV に書き込まれる速度 -- `TiDB -> TiKV: internal` : 内部トランザクションが TiDB から TiKV に書き込まれる速度 -- `TiKV -> Rocksdb` : TiKVからRocksDBへの書き込み操作の流れ -- `RocksDB Compaction` : RocksDBの圧縮操作によって生成された合計読み取りおよび書き込みI/Oフロー +- `Client -> TiDB` : クライアントから TiDB への受信トラフィック統計 +- `TiDB -> TiKV: general` : フォアグラウンドトランザクションが TiDB から TiKV に書き込まれる速度 +- `TiDB -> TiKV: internal` : 内部トランザクションが TiDB から TiKV に書き込まれる速度 +- `TiKV -> Rocksdb` : TiKVからRocksDBへの書き込み操作の流れ +- `RocksDB Compaction` : RocksDBの圧縮操作によって生成された合計読み取りおよび書き込みI/Oフロー ### 間隔 {#duration} -- `Duration` : 実行時間 +- `Duration` : 実行時間 - - クライアントからのリクエストをTiDBが受信してから、TiDBがそのリクエストを実行し、結果をクライアントに返すまでの時間。通常、クライアントからのリクエストはSQL文の形式で送信されますが、この時間には`COM_PING` 、 `COM_SLEEP` 、 `COM_STMT_FETCH` 、 `COM_SEND_LONG_DATA`などのコマンドの実行時間も含まれる場合があります。 - - TiDBはマルチクエリをサポートしています。つまり、クライアントは一度に複数のSQL文（例： `select 1; select 1; select 1;`を送信できます。この場合、このクエリの合計実行時間には、すべてのSQL文の実行時間が含まれます。 + - クライアントからのリクエストをTiDBが受信してから、TiDBがそのリクエストを実行し、結果をクライアントに返すまでの時間。通常、クライアントからのリクエストはSQL文の形式で送信されますが、この時間には`COM_PING` 、 `COM_SLEEP` 、 `COM_STMT_FETCH` 、 `COM_SEND_LONG_DATA`などのコマンドの実行時間も含まれる場合があります。 + - TiDBはマルチクエリをサポートしています。つまり、クライアントは一度に複数のSQL文（例： `select 1; select 1; select 1;`を送信できます。この場合、このクエリの合計実行時間には、すべてのSQL文の実行時間が含まれます。 -- `avg` : すべてのリクエストを実行する平均時間 +- `avg` : すべてのリクエストを実行する平均時間 -- `99` : すべてのリクエストを実行するためのP99期間 +- `99` : すべてのリクエストを実行するためのP99期間 -- `avg by type` : すべての TiDB インスタンス内のすべてのリクエストを実行するのにかかった平均時間 (タイプ別`UPDATE`収集`INSERT` : `SELECT` +- `avg by type` : すべての TiDB インスタンス内のすべてのリクエストを実行するのにかかった平均時間 (タイプ別`UPDATE`収集`INSERT` : `SELECT` ### 接続アイドル時間 {#connection-idle-duration} 接続アイドル期間は、接続がアイドル状態にある期間を示します。 -- `avg-in-txn` : 接続がトランザクション内にあるときの平均接続アイドル期間 -- `avg-not-in-txn` : 接続がトランザクション内にない場合の平均接続アイドル期間 -- `99-in-txn` : 接続がトランザクション内にある場合の P99 接続アイドル期間 -- `99-not-in-txn` : 接続がトランザクション内にない場合の P99 接続アイドル期間 +- `avg-in-txn` : 接続がトランザクション内にあるときの平均接続アイドル期間 +- `avg-not-in-txn` : 接続がトランザクション内にない場合の平均接続アイドル期間 +- `99-in-txn` : 接続がトランザクション内にある場合の P99 接続アイドル期間 +- `99-not-in-txn` : 接続がトランザクション内にない場合の P99 接続アイドル期間 ### 解析期間、コンパイル期間、実行期間 {#parse-duration-compile-duration-and-execute-duration} -- `Parse Duration` : SQL文の解析に要した時間 -- `Compile Duration` : 解析されたSQL ASTを実行計画にコンパイルするのにかかる時間 -- `Execution Duration` : SQL文の実行計画の実行に費やされた時間 +- `Parse Duration` : SQL文の解析に要した時間 +- `Compile Duration` : 解析されたSQL ASTを実行計画にコンパイルするのにかかる時間 +- `Execution Duration` : SQL文の実行計画の実行に費やされた時間 これら 3 つのメトリックにはすべて、すべての TiDB インスタンスの平均期間と 99 パーセンタイル期間が含まれます。 @@ -156,16 +156,16 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 ### PD TSO 待機/RPC 期間 {#pd-tso-wait-rpc-duration} -- `wait - avg` : すべての TiDB インスタンスで PD が TSO を返すのを待つ平均時間 -- `rpc - avg` : PDにTSOリクエストを送信してからすべてのTiDBインスタンスでTSOを受信するまでの平均時間 -- `wait - 99` : すべての TiDB インスタンスで PD が TSO を返すのを待つ P99 時間 -- `rpc - 99` : PDにTSOリクエストを送信してからすべてのTiDBインスタンスでTSOを受信するまでのP99時間 +- `wait - avg` : すべての TiDB インスタンスで PD が TSO を返すのを待つ平均時間 +- `rpc - avg` : PDにTSOリクエストを送信してからすべてのTiDBインスタンスでTSOを受信するまでの平均時間 +- `wait - 99` : すべての TiDB インスタンスで PD が TSO を返すのを待つ P99 時間 +- `rpc - 99` : PDにTSOリクエストを送信してからすべてのTiDBインスタンスでTSOを受信するまでのP99時間 ### ストレージ非同期書き込み期間、保存期間、適用期間 {#storage-async-write-duration-store-duration-and-apply-duration} -- `Storage Async Write Duration` : 非同期書き込みにかかった時間 -- `Store Duration` : 非同期書き込み中のストアループで消費された時間 -- `Apply Duration` : 非同期書き込み中の適用ループで消費された時間 +- `Storage Async Write Duration` : 非同期書き込みにかかった時間 +- `Store Duration` : 非同期書き込み中のストアループで消費された時間 +- `Apply Duration` : 非同期書き込み中の適用ループで消費された時間 これら 3 つのメトリックにはすべて、すべての TiKV インスタンスの平均期間と P99 期間が含まれます。 @@ -173,8 +173,8 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 ### 追加ログ期間、コミットログ期間、適用ログ期間 {#append-log-duration-commit-log-duration-and-apply-log-duration} -- `Append Log Duration` : Raftがログを追加するのにかかった時間 -- `Commit Log Duration` : Raftがログをコミットするのにかかる時間 -- `Apply Log Duration` : Raftがログを適用するのに要した時間 +- `Append Log Duration` : Raftがログを追加するのにかかった時間 +- `Commit Log Duration` : Raftがログをコミットするのにかかる時間 +- `Apply Log Duration` : Raftがログを適用するのに要した時間 これら 3 つのメトリックにはすべて、すべての TiKV インスタンスの平均期間と P99 期間が含まれます。 diff --git a/dashboard/dashboard-ops-deploy.md b/dashboard/dashboard-ops-deploy.md index 15b3066d68595..7c413b2ef1ae5 100644 --- a/dashboard/dashboard-ops-deploy.md +++ b/dashboard/dashboard-ops-deploy.md @@ -13,9 +13,9 @@ TiDB Dashboard UIは、v4.0以降のバージョンのPDコンポーネントに 標準の TiDB クラスターをデプロイする方法については、次のドキュメントを参照してください。 -- [TiDB Self-Managedのクイックスタート](/quick-start-with-tidb.md) -- [本番環境にTiDBをデプロイ](/production-deployment-using-tiup.md) -- [Kubernetes環境のデプロイメント](https://docs.pingcap.com/tidb-in-kubernetes/stable/access-dashboard) +- [TiDB Self-Managedのクイックスタート](/quick-start-with-tidb.md) +- [本番環境にTiDBをデプロイ](/production-deployment-using-tiup.md) +- [Kubernetes環境のデプロイメント](https://docs.pingcap.com/tidb-in-kubernetes/stable/access-dashboard) > **Note:** > @@ -72,8 +72,8 @@ tiup ctl:v pd -u http://127.0.0.1:2379 config set dashboard-add 上記のコマンドでは、 -- `127.0.0.1:2379`任意の PD インスタンスの IP とポートに置き換えます。 -- `9.9.9.9:2379` TiDB Dashboard サービスを実行する新しい PD インスタンスの IP とポートに置き換えます。 +- `127.0.0.1:2379`任意の PD インスタンスの IP とポートに置き換えます。 +- `9.9.9.9:2379` TiDB Dashboard サービスを実行する新しい PD インスタンスの IP とポートに置き換えます。 変更が有効になっているかどうかを確認するには、 `tiup cluster display`コマンドを使用します ( `CLUSTER_NAME`をクラスター名に置き換えます)。 @@ -127,6 +127,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)を参照してください。 +- ファイアウォールの設定など、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 bb11f272a1489..c06242e252c1b 100644 --- a/dashboard/dashboard-ops-reverse-proxy.md +++ b/dashboard/dashboard-ops-reverse-proxy.md @@ -44,7 +44,7 @@ http://192.168.0.123:2379/dashboard/ [HAProxy](https://www.haproxy.org/)をリバースプロキシとして使用する場合は、次の手順を実行します。 -1. 例えば、TiDB Dashboardのリバースプロキシを`8033`ポート（例）で使用します。HAProxy設定ファイルに以下の設定を追加します。 +1. 例えば、TiDB Dashboardのリバースプロキシを`8033`ポート（例）で使用します。HAProxy設定ファイルに以下の設定を追加します。 ```haproxy frontend tidb_dashboard_front @@ -62,9 +62,9 @@ http://192.168.0.123:2379/dashboard/ > > **このパス内のサービスのみが**リバースプロキシの背後にあることを保証するには、 `use_backend`ディレクティブの`if`部分を保持する必要があります。そうしないと、セキュリティリスクが発生する可能性があります。[TiDB Dashboardのセキュリティ保護](/dashboard/dashboard-ops-security.md)を参照してください。 -2. 設定を有効にするには、HAProxy を再起動します。 +2. 設定を有効にするには、HAProxy を再起動します。 -3. リバース プロキシが有効かどうかをテストします。HAProxy が配置されているマシンの`8033`ポートの`/dashboard/`アドレス ( `http://example.com:8033/dashboard/`など) にアクセスして、TiDB Dashboardにアクセスします。 +3. リバース プロキシが有効かどうかをテストします。HAProxy が配置されているマシンの`8033`ポートの`/dashboard/`アドレス ( `http://example.com:8033/dashboard/`など) にアクセスして、TiDB Dashboardにアクセスします。 @@ -72,7 +72,7 @@ http://192.168.0.123:2379/dashboard/ [NGINX](https://nginx.org/)リバース プロキシとして使用する場合は、次の手順を実行します。 -1. TiDB Dashboardのリバースプロキシを`8033`ポート（例）で使用します。NGINX設定ファイルに以下の設定を追加します。 +1. TiDB Dashboardのリバースプロキシを`8033`ポート（例）で使用します。NGINX設定ファイルに以下の設定を追加します。 ```nginx server { @@ -89,13 +89,13 @@ http://192.168.0.123:2379/dashboard/ > > `proxy_pass`ディレクティブの`/dashboard/`パスは必ず保持してください。これにより、このパスの下にあるサービスのみがリバースプロキシされます。そうしないと、セキュリティリスクが発生します。[TiDB Dashboardのセキュリティ保護](/dashboard/dashboard-ops-security.md)を参照してください。 -2. 設定を有効にするには、NGINX をリロードします。 +2. 設定を有効にするには、NGINX をリロードします。 ```shell sudo nginx -s reload ``` -3. リバース プロキシが有効かどうかをテストします。NGINX が配置されているマシンの`8033`ポートの`/dashboard/`アドレス ( `http://example.com:8033/dashboard/`など) にアクセスして、TiDB Dashboardにアクセスします。 +3. リバース プロキシが有効かどうかをテストします。NGINX が配置されているマシンの`8033`ポートの`/dashboard/`アドレス ( `http://example.com:8033/dashboard/`など) にアクセスして、TiDB Dashboardにアクセスします。 @@ -127,13 +127,13 @@ server_configs: デプロイされたクラスターの場合: -1. クラスターの構成ファイルを編集モードで開きます ( `CLUSTER_NAME`をクラスター名に置き換えます)。 +1. クラスターの構成ファイルを編集モードで開きます ( `CLUSTER_NAME`をクラスター名に置き換えます)。 ```shell tiup cluster edit-config CLUSTER_NAME ``` -2. `server_configs`の`pd`設定の下にある設定項目を変更または追加します。`server_configs`が存在しない場合は、最上位レベルに追加します。 +2. `server_configs`の`pd`設定の下にある設定項目を変更または追加します。`server_configs`が存在しない場合は、最上位レベルに追加します。 ```yaml monitored: @@ -169,7 +169,7 @@ server_configs: dashboard.public-path-prefix: /foo ``` -3. 変更した設定を有効にするには、すべての PD インスタンスに対してローリング再起動を実行します ( `CLUSTER_NAME`をクラスター名に置き換えます)。 +3. 変更した設定を有効にするには、すべての PD インスタンスに対してローリング再起動を実行します ( `CLUSTER_NAME`をクラスター名に置き換えます)。 ```shell tiup cluster reload CLUSTER_NAME -R pd diff --git a/dashboard/dashboard-ops-security.md b/dashboard/dashboard-ops-security.md index 150ebd0e6fa92..4f4a75c92240d 100644 --- a/dashboard/dashboard-ops-security.md +++ b/dashboard/dashboard-ops-security.md @@ -31,13 +31,13 @@ TiDB DashboardはPDクライアントポート（デフォルトは[http://IP:23 以下の対策を講じることをお勧めします。 -- ファイアウォールを使用して、コンポーネントが外部ネットワークまたは信頼できないネットワーク経由で PDコンポーネントの**クライアント**ポートにアクセスすることを禁止します。 +- ファイアウォールを使用して、コンポーネントが外部ネットワークまたは信頼できないネットワーク経由で PDコンポーネントの**クライアント**ポートにアクセスすることを禁止します。 > **Note:** > > 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} @@ -92,5 +92,5 @@ http://192.168.0.123:2379/dashboard/ ## その他の推奨される安全対策 {#other-recommended-safety-measures} -- [TLS認証を有効にして保存データを暗号化する](/enable-tls-between-components.md) -- [TiDBクライアントとサーバー間のTLSを有効にする](/enable-tls-between-clients-and-servers.md) +- [TLS認証を有効にして保存データを暗号化する](/enable-tls-between-components.md) +- [TiDBクライアントとサーバー間のTLSを有効にする](/enable-tls-between-clients-and-servers.md) diff --git a/dashboard/dashboard-overview.md b/dashboard/dashboard-overview.md index 8677851185ee3..a8a2b5e6d6aae 100644 --- a/dashboard/dashboard-overview.md +++ b/dashboard/dashboard-overview.md @@ -7,12 +7,12 @@ summary: TiDB概要ページには、クラスターのQPS、レイテンシー このページには、次の情報を含む TiDB クラスター全体の概要が表示されます。 -- クラスター全体の 1 秒あたりのクエリ数 (QPS)。 -- クラスター全体のクエリのレイテンシー。 -- 最近の期間に最も長い実行時間を累積した SQL ステートメント。 -- 最近の期間の実行時間がしきい値を超えたスロークエリ。 -- 各インスタンスのノード数とステータス。 -- メッセージを監視および警告します。 +- クラスター全体の 1 秒あたりのクエリ数 (QPS)。 +- クラスター全体のクエリのレイテンシー。 +- 最近の期間に最も長い実行時間を累積した SQL ステートメント。 +- 最近の期間の実行時間がしきい値を超えたスロークエリ。 +- 各インスタンスのノード数とステータス。 +- メッセージを監視および警告します。 ## ページにアクセスする {#access-the-page} @@ -74,8 +74,8 @@ TiDB Dashboardにログインすると、デフォルトで概要ページが表 上の画像のステータスは次のように説明されます。 -- 稼働中: インスタンスは正常に実行されています (オフラインストレージインスタンスを含む)。 -- ダウン: ネットワーク切断やプロセスクラッシュなど、インスタンスが異常な状態で動作しています。 +- 稼働中: インスタンスは正常に実行されています (オフラインストレージインスタンスを含む)。 +- ダウン: ネットワーク切断やプロセスクラッシュなど、インスタンスが異常な状態で動作しています。 **Instance**のタイトルをクリックすると、各インスタンスの詳細な実行ステータスを示す[クラスタ情報ページ](/dashboard/dashboard-cluster-info.md)が表示されます。 @@ -85,9 +85,9 @@ TiDB Dashboardにログインすると、デフォルトで概要ページが表 ![Monitor and alert](/media/dashboard/dashboard-overview-monitor.png) -- **View Metrics**：このリンクをクリックすると、Grafanaダッシュボードに移動し、クラスターの詳細な監視情報を確認できます。Grafanaダッシュボードの各監視メトリクスの詳細については、 [監視メトリック](/grafana-overview-dashboard.md)を参照してください。 -- **View Alerts**：このリンクをクリックすると、AlertManagerページに移動し、クラスターの詳細なアラート情報を確認できます。クラスターにアラートが存在する場合、アラートの数がリンクテキストに直接表示されます。 -- **Run Diagnostics**: このリンクをクリックすると、より詳細な[クラスター診断ページ](/dashboard/dashboard-diagnostics-access.md)にジャンプします。 +- **View Metrics**：このリンクをクリックすると、Grafanaダッシュボードに移動し、クラスターの詳細な監視情報を確認できます。Grafanaダッシュボードの各監視メトリクスの詳細については、 [監視メトリック](/grafana-overview-dashboard.md)を参照してください。 +- **View Alerts**：このリンクをクリックすると、AlertManagerページに移動し、クラスターの詳細なアラート情報を確認できます。クラスターにアラートが存在する場合、アラートの数がリンクテキストに直接表示されます。 +- **Run Diagnostics**: このリンクをクリックすると、より詳細な[クラスター診断ページ](/dashboard/dashboard-diagnostics-access.md)にジャンプします。 > **Note:** > diff --git a/dashboard/dashboard-profiling.md b/dashboard/dashboard-profiling.md index be403782bd412..4ba39f85dd508 100644 --- a/dashboard/dashboard-profiling.md +++ b/dashboard/dashboard-profiling.md @@ -19,27 +19,27 @@ summary: 手動プロファイリングを使用すると、TiDB、TiKV、PD、 現在、次のパフォーマンス データがサポートされています。 -- CPU: TiDB、TiKV、PD、 TiFlashインスタンスの各内部関数のCPUオーバーヘッド +- CPU: TiDB、TiKV、PD、 TiFlashインスタンスの各内部関数のCPUオーバーヘッド > TiKV およびTiFlashインスタンスの CPU オーバーヘッドは、現在 ARMアーキテクチャではサポートされていません。 -- ヒープ: TiDB、TiKV、PDインスタンス上の各内部関数のメモリ消費量 +- ヒープ: TiDB、TiKV、PDインスタンス上の各内部関数のメモリ消費量 > TiDBはv7.5以降、TiKVヒーププロファイルをサポートしています。TiDB Dashboardの実行環境にはPerl実行環境が必要です。Perl実行環境がない場合、エラーが発生します。 -- ミューテックス: TiDBおよびPDインスタンス上のミューテックスの競合状態 +- ミューテックス: TiDBおよびPDインスタンス上のミューテックスの競合状態 -- Goroutine: TiDB および PD インスタンス上のすべての Goroutine の実行状態と呼び出しスタック +- Goroutine: TiDB および PD インスタンス上のすべての Goroutine の実行状態と呼び出しスタック ## ページにアクセスする {#access-the-page} 次のいずれかの方法でインスタンス プロファイリング ページにアクセスできます。 -- TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**[高度なデバッグ]** > **[インスタンスのプロファイリング]** > **[手動プロファイリング]**をクリックします。 +- TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**[高度なデバッグ]** > **[インスタンスのプロファイリング]** > **[手動プロファイリング]**をクリックします。 ![Access instance profiling page](/media/dashboard/dashboard-profiling-access.png) -- ブラウザで[http://127.0.0.1:2379/dashboard/#/instance_profiling](http://127.0.0.1:2379/dashboard/#/instance_profiling)にアクセスしてください。`127.0.0.1:2379`を実際のPDインスタンスのアドレスとポートに置き換えてください。 +- ブラウザで[http://127.0.0.1:2379/dashboard/#/instance_profiling](http://127.0.0.1:2379/dashboard/#/instance_profiling)にアクセスしてください。`127.0.0.1:2379`を実際のPDインスタンスのアドレスとポートに置き換えてください。 ## プロファイリングを開始 {#start-profiling} diff --git a/dashboard/dashboard-resource-manager.md b/dashboard/dashboard-resource-manager.md index 24ce03b15c697..082b5ad8bac33 100644 --- a/dashboard/dashboard-resource-manager.md +++ b/dashboard/dashboard-resource-manager.md @@ -11,9 +11,9 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ リソース マネージャー ページにアクセスするには、次の 2 つの方法のいずれかを使用できます。 -- TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**[リソース マネージャー] を**クリックします。 +- TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**[リソース マネージャー] を**クリックします。 -- ブラウザで[http://127.0.0.1:2379/dashboard/#/resource_manager](http://127.0.0.1:2379/dashboard/#/resource_manager)にアクセスしてください。`127.0.0.1:2379`を実際のPDインスタンスのアドレスとポートに置き換えてください。 +- ブラウザで[http://127.0.0.1:2379/dashboard/#/resource_manager](http://127.0.0.1:2379/dashboard/#/resource_manager)にアクセスしてください。`127.0.0.1:2379`を実際のPDインスタンスのアドレスとポートに置き換えてください。 ## リソースマネージャーページ {#resource-manager-page} @@ -23,43 +23,43 @@ 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)を参照してください。 -- 容量の見積もり：リソース計画を立てる前に、クラスター全体の容量を把握する必要があります。以下のいずれかの方法を使用できます。 +- 容量の見積もり：リソース計画を立てる前に、クラスター全体の容量を把握する必要があります。以下のいずれかの方法を使用できます。 - - [実際の作業負荷に基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload) - - [ハードウェアの展開に基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-hardware-deployment) + - [実際の作業負荷に基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload) + - [ハードウェアの展開に基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-hardware-deployment) -- メトリクス: パネル上のメトリクスを観察することで、クラスターの現在の全体的なリソース消費状態を把握できます。 +- メトリクス: パネル上のメトリクスを観察することで、クラスターの現在の全体的なリソース消費状態を把握できます。 ## 容量の見積もり {#estimate-capacity} リソース計画を立てる前に、クラスター全体の容量を把握しておく必要があります。TiDBは、現在のクラスターの[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru#what-is-request-unit-ru)の容量を見積もる2つの方法を提供しています。 -- [ハードウェアの展開に基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-hardware-deployment) +- [ハードウェアの展開に基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-hardware-deployment) TiDB は次のワークロード タイプを受け入れます。 - - `tpcc` : 大量のデータ書き込みを伴うワークロードに適用されます。これは`TPC-C`と同様のワークロードモデルに基づいて推定されます。 - - `oltp_write_only` : 大量のデータ書き込みを伴うワークロードに適用されます。これは`sysbench oltp_write_only`と同様のワークロードモデルに基づいて推定されます。 - - `oltp_read_write` : データの読み取りと書き込みが均等なワークロードに適用されます。これは`sysbench oltp_read_write`と同様のワークロードモデルに基づいて推定されます。 - - `oltp_read_only` : 大量のデータ読み取りを伴うワークロードに適用されます。これは`sysbench oltp_read_only`と同様のワークロードモデルに基づいて推定されます。 + - `tpcc` : 大量のデータ書き込みを伴うワークロードに適用されます。これは`TPC-C`と同様のワークロードモデルに基づいて推定されます。 + - `oltp_write_only` : 大量のデータ書き込みを伴うワークロードに適用されます。これは`sysbench oltp_write_only`と同様のワークロードモデルに基づいて推定されます。 + - `oltp_read_write` : データの読み取りと書き込みが均等なワークロードに適用されます。これは`sysbench oltp_read_write`と同様のワークロードモデルに基づいて推定されます。 + - `oltp_read_only` : 大量のデータ読み取りを伴うワークロードに適用されます。これは`sysbench oltp_read_only`と同様のワークロードモデルに基づいて推定されます。 ![Calibrate by Hardware](/media/dashboard/dashboard-resource-manager-calibrate-by-hardware.png) **ユーザーリソースグループの合計RUは**、 `default`リソースグループを除くすべてのユーザーリソースグループのRUの合計量を表します。この値が推定容量を超えると、システムはアラートをトリガーします。デフォルトでは、システムは定義済みの`default`リソースグループに無制限の使用量を割り当てます。すべてのユーザーが`default`リソースグループに属している場合、リソースはリソース制御が無効になっている場合と同じように割り当てられます。 -- [実際の作業負荷に基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload) +- [実際の作業負荷に基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload) ![Calibrate by Workload](/media/dashboard/dashboard-resource-manager-calibrate-by-workload.png) 推定期間を10分から24時間まで選択できます。使用されるタイムゾーンはフロントエンドユーザーのタイムゾーンと同じです。 - - 時間ウィンドウの範囲が 10 分から 24 時間の範囲外の場合、次のエラーが表示されます`ERROR 1105 (HY000): the duration of calibration is too short, which could lead to inaccurate output. Please make the duration between 10m0s and 24h0m0s` 。 + - 時間ウィンドウの範囲が 10 分から 24 時間の範囲外の場合、次のエラーが表示されます`ERROR 1105 (HY000): the duration of calibration is too short, which could lead to inaccurate output. Please make the duration between 10m0s and 24h0m0s` 。 - - [実際の作業負荷に基づく容量推定](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload)機能の監視メトリックには、 `tikv_cpu_quota` 、 `tidb_server_maxprocs` 、 `resource_manager_resource_unit` 、 `process_cpu_usage`含まれます。CPUクォータ監視データが空の場合、対応する監視メトリック名（例： `Error 1105 (HY000): There is no CPU quota metrics, metrics 'tikv_cpu_quota' is empty` ）にエラーが発生します。 + - [実際の作業負荷に基づく容量推定](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload)機能の監視メトリックには、 `tikv_cpu_quota` 、 `tidb_server_maxprocs` 、 `resource_manager_resource_unit` 、 `process_cpu_usage`含まれます。CPUクォータ監視データが空の場合、対応する監視メトリック名（例： `Error 1105 (HY000): There is no CPU quota metrics, metrics 'tikv_cpu_quota' is empty` ）にエラーが発生します。 - - 時間枠内のワークロードが低すぎる場合、または`resource_manager_resource_unit`と`process_cpu_usage`監視データが欠落している場合は、エラーが報告されます`Error 1105 (HY000): The workload in selected time window is too low, with which TiDB is unable to reach a capacity estimation; please select another time window with higher workload, or calibrate resource by hardware instead`また、TiKVはmacOSのCPU使用率を監視しないため、実際のワークロードに基づく容量推定をサポートしておらず、このエラーも報告されます。 + - 時間枠内のワークロードが低すぎる場合、または`resource_manager_resource_unit`と`process_cpu_usage`監視データが欠落している場合は、エラーが報告されます`Error 1105 (HY000): The workload in selected time window is too low, with which TiDB is unable to reach a capacity estimation; please select another time window with higher workload, or calibrate resource by hardware instead`また、TiKVはmacOSのCPU使用率を監視しないため、実際のワークロードに基づく容量推定をサポートしておらず、このエラーも報告されます。 [メトリクス](#metrics)セクションの**CPU 使用率**を使用して適切な時間範囲を選択できます。 @@ -71,12 +71,12 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ パネル上のメトリクスを観察することで、クラスター全体の現在のリソース消費状況を把握できます。監視メトリクスとその意味は次のとおりです。 -- 消費された RU の合計: リアルタイムでカウントされた要求ユニットの合計消費量。 -- リソース グループによって消費された RU: リソース グループによってリアルタイムで消費された要求ユニットの数。 -- TiDB - - CPU クォータ: TiDB の最大 CPU 使用量。 - - CPU 使用率: すべての TiDB インスタンスの合計 CPU 使用率。 -- TiKV - - CPU クォータ: TiKV の最大 CPU 使用量。 - - CPU 使用率: すべての TiKV インスタンスの合計 CPU 使用率。 - - IO MBps: すべての TiKV インスタンスの合計 I/O スループット。 +- 消費された RU の合計: リアルタイムでカウントされた要求ユニットの合計消費量。 +- リソース グループによって消費された RU: リソース グループによってリアルタイムで消費された要求ユニットの数。 +- TiDB + - CPU クォータ: TiDB の最大 CPU 使用量。 + - CPU 使用率: すべての TiDB インスタンスの合計 CPU 使用率。 +- TiKV + - CPU クォータ: TiKV の最大 CPU 使用量。 + - CPU 使用率: すべての TiKV インスタンスの合計 CPU 使用率。 + - IO MBps: すべての TiKV インスタンスの合計 I/O スループット。 diff --git a/dashboard/dashboard-session-share.md b/dashboard/dashboard-session-share.md index 838e5e118ef96..93faa5585c895 100644 --- a/dashboard/dashboard-session-share.md +++ b/dashboard/dashboard-session-share.md @@ -9,11 +9,11 @@ TiDB Dashboardの現在のセッションを他のユーザーと共有して、 ## 招待者の手順 {#steps-for-the-inviter} -1. TiDB Dashboardにサインインします。 +1. TiDB Dashboardにサインインします。 -2. 左側のサイドバーにあるユーザー名をクリックして、設定ページにアクセスします。 +2. 左側のサイドバーにあるユーザー名をクリックして、設定ページにアクセスします。 -3. **[現在のセッションを共有]**をクリックします。 +3. **[現在のセッションを共有]**をクリックします。 ![Sample Step](/media/dashboard/dashboard-session-share-settings-1-v650.png) @@ -21,17 +21,17 @@ TiDB Dashboardの現在のセッションを他のユーザーと共有して、 > > セキュリティ上の理由により、共有セッションを再度共有することはできません。 -4. ポップアップ ダイアログで共有設定を調整します。 +4. ポップアップ ダイアログで共有設定を調整します。 - - 有効期限: 共有セッションの有効期間。現在のセッションからサインアウトしても、共有セッションの有効期間は変わりません。 + - 有効期限: 共有セッションの有効期間。現在のセッションからサインアウトしても、共有セッションの有効期間は変わりません。 - - 読み取り専用権限として共有: 共有セッションでは読み取り操作のみが許可され、書き込み操作 (構成の変更など) は許可されません。 + - 読み取り専用権限として共有: 共有セッションでは読み取り操作のみが許可され、書き込み操作 (構成の変更など) は許可されません。 -5. **[認証コードの生成]を**クリックします。 +5. **[認証コードの生成]を**クリックします。 ![Sample Step](/media/dashboard/dashboard-session-share-settings-2-v650.png) -6. 生成された**認証コードを**、セッションを共有するユーザーに提供します。 +6. 生成された**認証コードを**、セッションを共有するユーザーに提供します。 ![Sample Step](/media/dashboard/dashboard-session-share-settings-3-v650.png) @@ -41,16 +41,16 @@ TiDB Dashboardの現在のセッションを他のユーザーと共有して、 ## 招待された人の手順 {#steps-for-the-invitee} -1. TiDB Dashboardのサインイン ページで、 **[代替認証の使用] を**クリックします。 +1. TiDB Dashboardのサインイン ページで、 **[代替認証の使用] を**クリックします。 ![Sample Step](/media/dashboard/dashboard-session-share-signin-1-v650.png) -2. **承認コード**をクリックしてサインインに使用します。 +2. **承認コード**をクリックしてサインインに使用します。 ![Sample Step](/media/dashboard/dashboard-session-share-signin-2-v650.png) -3. 招待者から受け取った認証コードを入力します。 +3. 招待者から受け取った認証コードを入力します。 -4. **[サインイン]を**クリックします。 +4. **[サインイン]を**クリックします。 ![Sample Step](/media/dashboard/dashboard-session-share-signin-3-v650.png) diff --git a/dashboard/dashboard-session-sso.md b/dashboard/dashboard-session-sso.md index cd53e496c95b5..7cec2ef69f259 100644 --- a/dashboard/dashboard-session-sso.md +++ b/dashboard/dashboard-session-sso.md @@ -11,24 +11,24 @@ TiDB Dashboardは、SQLベースの[OIDC](https://openid.net/connect/)サイン ### SSOを有効にする {#enable-sso} -1. TiDB Dashboardにサインインします。 +1. TiDB Dashboardにサインインします。 -2. 左側のサイドバーにあるユーザー名をクリックして、設定ページにアクセスします。 +2. 左側のサイドバーにあるユーザー名をクリックして、設定ページにアクセスします。 -3. **Single Sign-On**セクションで、 **Enable to use SSO when sign into TiDB Dashboard**を選択します。 +3. **Single Sign-On**セクションで、 **Enable to use SSO when sign into TiDB Dashboard**を選択します。 > **Note:** > > アカウントに`SYSTEM_VARIABLES_ADMIN`権限がない場合、 **Enable to use SSO when sign into TiDB Dashboard**オプションは無効になります。権限の詳細については、 [TiDB Dashboardのユーザー管理](/dashboard/dashboard-user.md)をご覧ください。 -4. フォームの**OIDC Client ID**と**OIDC Discovery URL**フィールドに入力します。 +4. フォームの**OIDC Client ID**と**OIDC Discovery URL**フィールドに入力します。 通常、SSO サービス プロバイダーから次の 2 つのフィールドを取得できます。 - - OIDC Client ID は、OIDC トークン発行者とも呼ばれます。 - - OIDC Discovery URL は、OIDC Token Audience とも呼ばれます。 + - OIDC Client ID は、OIDC トークン発行者とも呼ばれます。 + - OIDC Discovery URL は、OIDC Token Audience とも呼ばれます。 -5. **Authorize Impersonation**をクリックし、SQL パスワードを入力します。 +5. **Authorize Impersonation**をクリックし、SQL パスワードを入力します。 TiDB Dashboardはこの SQL パスワードを保存し、SSO サインインが完了した後に通常の SQL サインインを偽装するために使用します。 @@ -38,11 +38,11 @@ TiDB Dashboardは、SQLベースの[OIDC](https://openid.net/connect/)サイン > > 入力したパスワードは暗号化されて保存されます。SQLユーザーのパスワードを変更すると、SSOサインインが失敗します。その場合は、パスワードを再入力することでSSOを復旧できます。 -6. **Authorize and Save**をクリックします。 +6. **Authorize and Save**をクリックします。 ![Sample Step](/media/dashboard/dashboard-session-sso-enable-2.png) -7. 設定を保存するには、 **Update** (Update) をクリックします。 +7. 設定を保存するには、 **Update** (Update) をクリックします。 ![Sample Step](/media/dashboard/dashboard-session-sso-enable-3.png) @@ -56,13 +56,13 @@ TiDB Dashboardで SSO サインインが有効になりました。 SSO を無効にすると、保存されている SQL パスワードが完全に消去されます。 -1. TiDB Dashboardにサインインします。 +1. TiDB Dashboardにサインインします。 -2. 左側のサイドバーにあるユーザー名をクリックして、設定ページにアクセスします。 +2. 左側のサイドバーにあるユーザー名をクリックして、設定ページにアクセスします。 -3. **Single Sign-On**セクションで、 **Enable to use SSO when sign into TiDB Dashboard**の選択を解除します。 +3. **Single Sign-On**セクションで、 **Enable to use SSO when sign into TiDB Dashboard**の選択を解除します。 -4. 設定を保存するには、 **Update** (Update) をクリックします。 +4. 設定を保存するには、 **Update** (Update) をクリックします。 ![Sample Step](/media/dashboard/dashboard-session-sso-disable.png) @@ -70,27 +70,27 @@ SSO を無効にすると、保存されている SQL パスワードが完全 SQLユーザーのパスワードを変更すると、SSOサインインは失敗します。この場合、SQLパスワードを再入力することでSSOサインインを再開できます。 -1. TiDB Dashboardにサインインします。 +1. TiDB Dashboardにサインインします。 -2. 左側のサイドバーにあるユーザー名をクリックして、設定ページにアクセスします。 +2. 左側のサイドバーにあるユーザー名をクリックして、設定ページにアクセスします。 -3. **Single Sign-On**セクションで、 **Authorize Impersonation**をクリックし、更新された SQL パスワードを入力します。 +3. **Single Sign-On**セクションで、 **Authorize Impersonation**をクリックし、更新された SQL パスワードを入力します。 ![Sample Step](/media/dashboard/dashboard-session-sso-reauthorize.png) -4. **Authorize and Save**をクリックします。 +4. **Authorize and Save**をクリックします。 ## SSO経由でサインイン {#sign-in-via-sso} TiDB Dashboardに SSO が設定されると、次の手順に従って SSO 経由でサインインできます。 -1. TiDB Dashboardのサインイン ページで、 **Sign in via Company Account**をクリックします。 +1. TiDB Dashboardのサインイン ページで、 **Sign in via Company Account**をクリックします。 ![Sample Step](/media/dashboard/dashboard-session-sso-signin.png) -2. SSO サービスが設定されたシステムにサインインします。 +2. SSO サービスが設定されたシステムにサインインします。 -3. サインインを完了するために、TiDB Dashboardにリダイレクトされます。 +3. サインインを完了するために、TiDB Dashboardにリダイレクトされます。 ## 例 1: TiDB Dashboardの SSO サインインに Okta を使用する {#example-1-use-okta-for-tidb-dashboard-sso-sign-in} @@ -100,23 +100,23 @@ TiDB Dashboardに SSO が設定されると、次の手順に従って SSO 経 まず、SSO を統合するための Okta アプリケーション統合を作成します。 -1. Okta 管理サイトにアクセスします。 +1. Okta 管理サイトにアクセスします。 -2. 左側のサイドバーから**Applications** > **Applications**に移動します。 +2. 左側のサイドバーから**Applications** > **Applications**に移動します。 -3. **Create App Integration**をクリックします。 +3. **Create App Integration**をクリックします。 ![Sample Step](/media/dashboard/dashboard-session-sso-okta-1.png) -4. ポップアップされたダイアログで、**Sign-in method**で**OIDC - OpenID Connect**を選択します。 +4. ポップアップされたダイアログで、**Sign-in method**で**OIDC - OpenID Connect**を選択します。 -5. **Application Type**で**Single-Page Application**を選択します。 +5. **Application Type**で**Single-Page Application**を選択します。 -6. **Next**ボタンをクリックします。 +6. **Next**ボタンをクリックします。 ![Sample Step](/media/dashboard/dashboard-session-sso-okta-2.png) -7. **Sign-in redirect URIs**を次のように入力します。 +7. **Sign-in redirect URIs**を次のように入力します。 ``` http://DASHBOARD_IP:PORT/dashboard/?sso_callback=1 @@ -124,7 +124,7 @@ TiDB Dashboardに SSO が設定されると、次の手順に従って SSO 経 `DASHBOARD_IP:PORT` 、ブラウザで TiDB Dashboardにアクセスするために使用する実際のドメイン (または IP アドレス) とポートに置き換えます。 -8. **Sign-out redirect URIs**を次のように入力します。 +8. **Sign-out redirect URIs**を次のように入力します。 ``` http://DASHBOARD_IP:PORT/dashboard/ @@ -134,21 +134,21 @@ TiDB Dashboardに SSO が設定されると、次の手順に従って SSO 経 ![Sample Step](/media/dashboard/dashboard-session-sso-okta-3.png) -9. **Assignments**フィールドで、組織内のどのタイプのユーザーに SSO サインインを許可するかを構成し、 **Save**をクリックして構成を保存します。 +9. **Assignments**フィールドで、組織内のどのタイプのユーザーに SSO サインインを許可するかを構成し、 **Save**をクリックして構成を保存します。 ![Sample Step](/media/dashboard/dashboard-session-sso-okta-4.png) ### ステップ2: OIDC情報を取得し、TiDB Dashboardに入力します {#step-2-obtain-oidc-information-and-fill-in-tidb-dashboard} -1. Okta で作成したアプリケーション統合で、 **Sign On**をクリックします。 +1. Okta で作成したアプリケーション統合で、 **Sign On**をクリックします。 ![Sample Step 1](/media/dashboard/dashboard-session-sso-okta-info-1.png) -2. **OpenID Connect ID Token**セクションから**Issuer**フィールドと**Audience**フィールドの値をコピーします。 +2. **OpenID Connect ID Token**セクションから**Issuer**フィールドと**Audience**フィールドの値をコピーします。 ![Sample Step 2](/media/dashboard/dashboard-session-sso-okta-info-2.png) -3. TiDB Dashboardの設定ページを開き、 **OIDC Client ID**に前の手順で取得した**Issuer**を入力し、 **OIDC Discovery URL**に**Audience**を入力します。その後、認証を完了し、設定を保存します。例： +3. TiDB Dashboardの設定ページを開き、 **OIDC Client ID**に前の手順で取得した**Issuer**を入力し、 **OIDC Discovery URL**に**Audience**を入力します。その後、認証を完了し、設定を保存します。例： ![Sample Step 3](/media/dashboard/dashboard-session-sso-okta-info-3.png) @@ -160,21 +160,21 @@ Oktaと同様に、 [オーソ0](https://auth0.com/)もOIDC SSOアイデンテ ### ステップ1: Auth0を構成する {#step-1-configure-auth0} -1. Auth0 管理サイトにアクセスします。 +1. Auth0 管理サイトにアクセスします。 -2. 左側のサイドバーで**Applications** > **Applications**に移動します。 +2. 左側のサイドバーで**Applications** > **Applications**に移動します。 -3. **Create App Integration**をクリックします。 +3. **Create App Integration**をクリックします。 ![Create Application](/media/dashboard/dashboard-session-sso-auth0-create-app.png) ポップアップダイアログで、**Name**を入力します（例：「TiDB Dashboard」）。**Choose an application type**で**Single Page Web Applications**を選択します。 **Create**をクリックします。 -4. **Settings**をクリックします。 +4. **Settings**をクリックします。 ![Settings](/media/dashboard/dashboard-session-sso-auth0-settings-1.png) -5. **許可されたコールバック URL**を次のように入力します。 +5. **許可されたコールバック URL**を次のように入力します。 ``` http://DASHBOARD_IP:PORT/dashboard/?sso_callback=1 @@ -182,7 +182,7 @@ Oktaと同様に、 [オーソ0](https://auth0.com/)もOIDC SSOアイデンテ `DASHBOARD_IP:PORT` 、ブラウザで TiDB Dashboardにアクセスするために使用する実際のドメイン (または IP アドレス) とポートに置き換えます。 -6. **許可されたログアウト URL**を次のように入力します。 +6. **許可されたログアウト URL**を次のように入力します。 ``` http://DASHBOARD_IP:PORT/dashboard/ @@ -192,13 +192,13 @@ Oktaと同様に、 [オーソ0](https://auth0.com/)もOIDC SSOアイデンテ ![Settings](/media/dashboard/dashboard-session-sso-auth0-settings-2.png) -7. その他の設定はデフォルト値のままにして、 **Save Changes**をクリックします。 +7. その他の設定はデフォルト値のままにして、 **Save Changes**をクリックします。 ### ステップ2: OIDC情報を取得し、TiDB Dashboardに入力します {#step-2-obtain-oidc-information-and-fill-in-tidb-dashboard} -1. Auth0 の**Settings**タブの**Basic Information**にある**Client ID**を、TiDB Dashboardの**OIDC Client ID**に入力します。 +1. Auth0 の**Settings**タブの**Basic Information**にある**Client ID**を、TiDB Dashboardの**OIDC Client ID**に入力します。 -2. **OIDC Discovery URL**に、**Domain**フィールドの値の先頭に`https://`、末尾に`/`を追加して入力します（例： `https://example.us.auth0.com/` ）。認証を完了し、設定を保存します。 +2. **OIDC Discovery URL**に、**Domain**フィールドの値の先頭に`https://`、末尾に`/`を追加して入力します（例： `https://example.us.auth0.com/` ）。認証を完了し、設定を保存します。 ![Settings](/media/dashboard/dashboard-session-sso-auth0-settings-3.png) @@ -210,15 +210,15 @@ Oktaと同様に、 [オーソ0](https://auth0.com/)もOIDC SSOアイデンテ ### ステップ1：Casdoorを設定する {#step-1-configure-casdoor} -1. Casdoor 管理サイトをデプロイてアクセスします。 +1. Casdoor 管理サイトをデプロイてアクセスします。 -2. 上部のサイドバーの**Applications**から移動します。 +2. 上部のサイドバーの**Applications**から移動します。 -3. **Applications - Add**をクリックします![Settings](/media/dashboard/dashboard-session-sso-casdoor-settings-1.png) +3. **Applications - Add**をクリックします![Settings](/media/dashboard/dashboard-session-sso-casdoor-settings-1.png) -4. **Name**と**Display name**を入力します (例: **TiDB Dashboard**)。 +4. **Name**と**Display name**を入力します (例: **TiDB Dashboard**)。 -5. 次のように**リダイレクト URL**を追加します。 +5. 次のように**リダイレクト URL**を追加します。 ``` http://DASHBOARD_IP:PORT/dashboard/?sso_callback=1 @@ -228,15 +228,15 @@ Oktaと同様に、 [オーソ0](https://auth0.com/)もOIDC SSOアイデンテ ![Settings](/media/dashboard/dashboard-session-sso-casdoor-settings-2.png) -6. その他の設定はデフォルト値のままにして、 **Save & Exit**をクリックします。 +6. その他の設定はデフォルト値のままにして、 **Save & Exit**をクリックします。 -7. ページに表示されている**Client ID**を保存します。 +7. ページに表示されている**Client ID**を保存します。 ### ステップ2: OIDC情報を取得し、TiDB Dashboardに入力します {#step-2-obtain-oidc-information-and-fill-in-tidb-dashboard} -1. 前の手順で保存した**Client ID**を TiDB Dashboardの**OIDC Client ID**に入力します。 +1. 前の手順で保存した**Client ID**を TiDB Dashboardの**OIDC Client ID**に入力します。 -2. **OIDC Discovery URL**に、**Domain**フィールドの値の先頭に`https://`、末尾に`/`を追加して入力します（例： `https://casdoor.example.com/` ）。認証を完了し、設定を保存します。 +2. **OIDC Discovery URL**に、**Domain**フィールドの値の先頭に`https://`、末尾に`/`を追加して入力します（例： `https://casdoor.example.com/` ）。認証を完了し、設定を保存します。 ![Settings](/media/dashboard/dashboard-session-sso-casdoor-settings-3.png) diff --git a/dashboard/dashboard-slow-query.md b/dashboard/dashboard-slow-query.md index 4639a4d819fbf..ae86cd00f0401 100644 --- a/dashboard/dashboard-slow-query.md +++ b/dashboard/dashboard-slow-query.md @@ -17,9 +17,9 @@ TiDB Dashboardの「スロークエリ」ページでは、クラスタ内のす スロークエリページにアクセスするには、以下の2つの方法のいずれかを使用できます。 -- TiDB Dashboardにログイン後、左側のナビゲーションメニューにある**Slow Queries**をクリックします。 +- TiDB Dashboardにログイン後、左側のナビゲーションメニューにある**Slow Queries**をクリックします。 -- ブラウザで[http://127.0.0.1:2379/dashboard/#/slow_query](http://127.0.0.1:2379/dashboard/#/slow_query)にアクセスしてください。 `127.0.0.1:2379`を実際の PD アドレスとポートに置き換えてください。 +- ブラウザで[http://127.0.0.1:2379/dashboard/#/slow_query](http://127.0.0.1:2379/dashboard/#/slow_query)にアクセスしてください。 `127.0.0.1:2379`を実際の PD アドレスとポートに置き換えてください。 スロー クエリ ページに表示されるすべてのデータは、TiDB スロー クエリ システム テーブルおよびスロー クエリ ログから取得されます。詳細については[スロークエリログ](/identify-slow-queries.md)を参照してください。 @@ -51,9 +51,9 @@ TiDB Dashboardの「スロークエリ」ページでは、クラスタ内のす リスト内のいずれかの項目をクリックすると、以下の項目を含む、スロークエリの詳細な実行情報が表示されます。 -- クエリ：SQL文のテキスト（下図の領域1） -- 計画：スロークエリの実行計画（下図の領域2） -- その他のソート済みSQL実行情報（下図の領域3） +- クエリ：SQL文のテキスト（下図の領域1） +- 計画：スロークエリの実行計画（下図の領域2） +- その他のソート済みSQL実行情報（下図の領域3） ![View execution details](/media/dashboard/dashboard-slow-queries-detail1-v620.png) @@ -61,8 +61,8 @@ TiDB Dashboardの「スロークエリ」ページでは、クラスタ内のす > **Note:** > -> - `Query`列に記録されるクエリの最大長は、 [`tidb_stmt_summary_max_sql_length`](/system-variables.md#tidb_stmt_summary_max_sql_length-new-in-v40)システム変数によって制限されます。 -> - プリペアドステートメントの場合、引数はクエリの末尾にリストされます。例: `[arguments: "foo", 123]` 。表示できない引数は、16 進数のリテラルとして表示されます。例: `0x01` 。 +> - `Query`列に記録されるクエリの最大長は、 [`tidb_stmt_summary_max_sql_length`](/system-variables.md#tidb_stmt_summary_max_sql_length-new-in-v40)システム変数によって制限されます。 +> - プリペアドステートメントの場合、引数はクエリの末尾にリストされます。例: `[arguments: "foo", 123]` 。表示できない引数は、16 進数のリテラルとして表示されます。例: `0x01` 。 アイテムの詳細情報を表示するには、 **Expand**ボタンをクリックします。詳細情報をクリップボードにコピーするには、 **Copy**ボタンをクリックします。 @@ -78,10 +78,10 @@ TiDB Dashboardでは、表、テキスト、グラフの 3 つの方法で実行 表形式はテキスト形式と同様の情報を表示しますが、よりユーザーフレンドリーな操作性を提供します。 -- 列幅は自由に調整できます。 -- コンテンツが列幅を超えると、自動的に切り詰められ、完全な情報を示すツールチップが表示されます。 -- 実行計画が大きい場合は、テキストファイルとしてダウンロードしてローカルで分析できます。 -- 列選択ツールを使用して、列を非表示にしたり管理したりできます。 +- 列幅は自由に調整できます。 +- コンテンツが列幅を超えると、自動的に切り詰められ、完全な情報を示すツールチップが表示されます。 +- 実行計画が大きい場合は、テキストファイルとしてダウンロードしてローカルで分析できます。 +- 列選択ツールを使用して、列を非表示にしたり管理したりできます。 ![Execution plan in table format - column picker](/media/dashboard/dashboard-table-plan-columnpicker.png) @@ -91,10 +91,10 @@ TiDB Dashboardでは、表、テキスト、グラフの 3 つの方法で実行 ![Execution plan in graph format](/media/dashboard/dashboard-visual-plan-2.png) -- グラフは、左から右、上から下の順に実行状況を示しています。 -- 上位ノードは親演算子、下位ノードは子演算子です。 -- タイトルバーの色は、オペレーターが実行されるコンポーネントを示します。黄色はTiDB、青はTiKV、ピンクはTiFlashを表します。 -- タイトルバーにはオペレーター名が表示され、その下に表示されるテキストはオペレーターの基本情報です。 +- グラフは、左から右、上から下の順に実行状況を示しています。 +- 上位ノードは親演算子、下位ノードは子演算子です。 +- タイトルバーの色は、オペレーターが実行されるコンポーネントを示します。黄色はTiDB、青はTiKV、ピンクはTiFlashを表します。 +- タイトルバーにはオペレーター名が表示され、その下に表示されるテキストはオペレーターの基本情報です。 ノード領域をクリックすると、詳細なオペレーター情報が右側のサイドバーに表示されます。 diff --git a/dashboard/dashboard-statement-details.md b/dashboard/dashboard-statement-details.md index 834f5ccfddf45..2484e0170e469 100644 --- a/dashboard/dashboard-statement-details.md +++ b/dashboard/dashboard-statement-details.md @@ -7,9 +7,9 @@ summary: TiDB Dashboardは、SQLテンプレートの概要、実行計画一覧 リスト内の任意の項目をクリックすると、SQL文の詳細ページに移動し、より詳細な情報が表示されます。この情報には、以下の部分が含まれます。 -- SQL ステートメントの概要。これには、SQL テンプレート、SQL テンプレート ID、表示されている SQL 実行の現在の時間範囲、実行計画の数、SQL ステートメントが実行されるデータベース、および高速プラン バインディング機能が含まれます (次の図の領域 1)。 -- 実行計画リスト：SQL文に複数の実行計画がある場合、このリストが表示されます。実行計画のテキスト情報に加え、TiDB v6.2.0ではビジュアル実行計画が導入され、文の各演算子や詳細情報をより直感的に把握できるようになりました。複数の実行計画を選択すると、選択したプランの詳細がリストの下に表示されます（下図の領域2）。 -- プランの実行詳細。選択した実行計画の詳細情報が表示されます。1（下図の領域3） [実行計画の詳細](#execution-details-of-plans)を参照してください。 +- SQL ステートメントの概要。これには、SQL テンプレート、SQL テンプレート ID、表示されている SQL 実行の現在の時間範囲、実行計画の数、SQL ステートメントが実行されるデータベース、および高速プラン バインディング機能が含まれます (次の図の領域 1)。 +- 実行計画リスト：SQL文に複数の実行計画がある場合、このリストが表示されます。実行計画のテキスト情報に加え、TiDB v6.2.0ではビジュアル実行計画が導入され、文の各演算子や詳細情報をより直感的に把握できるようになりました。複数の実行計画を選択すると、選択したプランの詳細がリストの下に表示されます（下図の領域2）。 +- プランの実行詳細。選択した実行計画の詳細情報が表示されます。1（下図の領域3） [実行計画の詳細](#execution-details-of-plans)を参照してください。 ![Details](/media/dashboard/dashboard-statement-detail-v660.png) @@ -21,29 +21,29 @@ TiDB v6.6.0以降、高速プランバインディング機能が導入されま #### 実行計画をバインドする {#bind-an-execution-plan} -1. **Plan Binding**をクリックします。 **Plan Binding**ダイアログボックスが表示されます。 +1. **Plan Binding**をクリックします。 **Plan Binding**ダイアログボックスが表示されます。 ![Fast plan binding - not bound - entry](/media/dashboard/dashboard-quick-binding-entry-notbound.png) -2. バインドするプランを選択し、 **Bind**をクリックします。 +2. バインドするプランを選択し、 **Bind**をクリックします。 ![Fast plan binding - popup](/media/dashboard/dashboard-quick-binding-popup-notbound.png) -3. バインディングが完了すると、 **Bound**ラベルが表示されます。 +3. バインディングが完了すると、 **Bound**ラベルが表示されます。 ![Fast plan binding - popup - binding completed](/media/dashboard/dashboard-quick-binding-popup-bound.png) #### 既存のバインディングを削除する {#drop-an-existing-binding} -1. 既存のバインディングを持つSQL文のページで、 **Plan Binding**をクリックします。 **Plan Binding**ダイアログボックスが表示されます。 +1. 既存のバインディングを持つSQL文のページで、 **Plan Binding**をクリックします。 **Plan Binding**ダイアログボックスが表示されます。 ![Fast plan binding - bound - entry](/media/dashboard/dashboard-quick-binding-entry-bound.png) -2. **［ドロップ］を**クリックします。 +2. **［ドロップ］を**クリックします。 ![Fast plan binding - popup - bound](/media/dashboard/dashboard-quick-binding-popup-bound.png) -3. バインドが削除されると、 **Not bound**ラベルが表示されます。 +3. バインドが削除されると、 **Not bound**ラベルが表示されます。 ![Fast plan binding - popup](/media/dashboard/dashboard-quick-binding-popup-notbound.png) @@ -51,10 +51,10 @@ TiDB v6.6.0以降、高速プランバインディング機能が導入されま 現在、高速プラン バインディング機能では、次の種類の SQL ステートメントはサポートされていません。 -- `SELECT` `INSERT` `UPDATE` `REPLACE` `DELETE` -- サブクエリを含むクエリ -- TiFlashにアクセスするクエリ -- 3つ以上のテーブルを結合するクエリ +- `SELECT` `INSERT` `UPDATE` `REPLACE` `DELETE` +- サブクエリを含むクエリ +- TiFlashにアクセスするクエリ +- 3つ以上のテーブルを結合するクエリ この機能を使用するには、SUPER権限が必要です。使用中に権限に関する問題が発生した場合は、 [TiDB Dashboardのユーザー管理](/dashboard/dashboard-user.md)を参照して必要な権限を追加してください。 @@ -62,9 +62,9 @@ TiDB v6.6.0以降、高速プランバインディング機能が導入されま プランの実行詳細には次の情報が含まれます。 -- SQLサンプル: プランに従って実際に実行された特定のSQL文のテキスト。時間範囲内で実行されたSQL文であれば、どれでもSQLサンプルとして使用できます。 -- 実行計画: 実行計画に関する完全な情報が、表、グラフ、テキストで表示されます。実行計画の詳細については、 [クエリ実行計画を理解する](/explain-overview.md)を参照してください。複数の実行計画を選択した場合は、そのうちの1つだけが表示されます。 -- SQL ステートメントの基本情報、実行時間、コプロセッサー読み取り、トランザクション、およびスロークエリについては、対応するタブ タイトルをクリックして、さまざまな情報を切り替えることができます。 +- SQLサンプル: プランに従って実際に実行された特定のSQL文のテキスト。時間範囲内で実行されたSQL文であれば、どれでもSQLサンプルとして使用できます。 +- 実行計画: 実行計画に関する完全な情報が、表、グラフ、テキストで表示されます。実行計画の詳細については、 [クエリ実行計画を理解する](/explain-overview.md)を参照してください。複数の実行計画を選択した場合は、そのうちの1つだけが表示されます。 +- SQL ステートメントの基本情報、実行時間、コプロセッサー読み取り、トランザクション、およびスロークエリについては、対応するタブ タイトルをクリックして、さまざまな情報を切り替えることができます。 ![Execution details of plans](/media/dashboard/dashboard-statement-plans-detail.png) @@ -84,10 +84,10 @@ TiDB Dashboardでは、実行計画を表、テキスト、グラフの3つの 表形式ではテキスト形式と同様の情報が表示されますが、よりユーザーフレンドリーな操作が提供されます。 -- 列幅は自由に調整できます。 -- コンテンツが列幅を超えると、自動的に切り捨てられ、完全な情報のツールヒントが表示されます。 -- 実行計画が大きい場合は、ローカル分析用にテキスト ファイルとしてダウンロードできます。 -- 列ピッカーを使用して列を非表示にしたり管理したりできます。 +- 列幅は自由に調整できます。 +- コンテンツが列幅を超えると、自動的に切り捨てられ、完全な情報のツールヒントが表示されます。 +- 実行計画が大きい場合は、ローカル分析用にテキスト ファイルとしてダウンロードできます。 +- 列ピッカーを使用して列を非表示にしたり管理したりできます。 ![Execution plan in table format - column picker](/media/dashboard/dashboard-table-plan-columnpicker.png) @@ -97,10 +97,10 @@ TiDB Dashboardでは、実行計画を表、テキスト、グラフの3つの ![Execution plan in graph format](/media/dashboard/dashboard-visual-plan-2.png) -- グラフには、左から右、上から下への実行が表示されます。 -- 上位ノードは親演算子であり、下位ノードは子演算子です。 -- タイトル バーの色は、演算子が実行されるコンポーネントを示します。黄色は TiDB、青は TiKV、ピンクはTiFlashを表します。 -- タイトル バーにはオペレーターの名前が表示され、その下に表示されるテキストはオペレーターの基本情報です。 +- グラフには、左から右、上から下への実行が表示されます。 +- 上位ノードは親演算子であり、下位ノードは子演算子です。 +- タイトル バーの色は、演算子が実行されるコンポーネントを示します。黄色は TiDB、青は TiKV、ピンクはTiFlashを表します。 +- タイトル バーにはオペレーターの名前が表示され、その下に表示されるテキストはオペレーターの基本情報です。 ノード領域をクリックすると、右側のサイドバーにオペレータの詳細情報が表示されます。 diff --git a/dashboard/dashboard-statement-list.md b/dashboard/dashboard-statement-list.md index 966996ee5f2d2..d255c35444c69 100644 --- a/dashboard/dashboard-statement-list.md +++ b/dashboard/dashboard-statement-list.md @@ -13,9 +13,9 @@ SQL文ページには、クラスター内のすべてのSQL文の実行状況 SQL ステートメントの概要ページにアクセスするには、次の 2 つの方法のいずれかを使用できます。 -- TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**[SQL ステートメント]**をクリックします。 +- TiDB Dashboardにログインしたら、左側のナビゲーション メニューで**[SQL ステートメント]**をクリックします。 -- ブラウザで[http://127.0.0.1:2379/dashboard/#/statement](http://127.0.0.1:2379/dashboard/#/statement)にアクセスしてください。`127.0.0.1:2379`を実際のPDインスタンスのアドレスとポートに置き換えてください。 +- ブラウザで[http://127.0.0.1:2379/dashboard/#/statement](http://127.0.0.1:2379/dashboard/#/statement)にアクセスしてください。`127.0.0.1:2379`を実際のPDインスタンスのアドレスとポートに置き換えてください。 SQL文の概要ページに表示されるすべてのデータは、TiDB ステートメント サマリー テーブルから取得されます。テーブルの詳細については、 [TiDB ステートメント サマリー テーブル](/statement-summary-tables.md)を参照してください。 @@ -53,16 +53,16 @@ SQL文の概要ページの上部で、表示するSQL実行の時間範囲を 設定ページでは、SQL文機能を有効または無効にすることができます。SQL文機能を有効にすると、以下の設定を変更できます。 -- 収集間隔：各SQL文の分析期間。デフォルトでは30分です。SQL文機能は、一定期間内のすべてのSQL文を集計し、カウントします。期間が長すぎると集計の粒度が粗くなり、問題の特定に適さなくなります。期間が短すぎると統計の粒度が細かくなり、問題の特定には適しますが、同じデータ保持期間内でのレコード数とメモリ使用量が増加します。したがって、実際の状況に応じてこの値を調整し、問題の特定時には適切にこの値を下げる必要があります。 -- データ保持期間：概要情報の保持期間。デフォルトでは1日です。この期間を超えて保持されたデータは、システムテーブルから削除されます。 +- 収集間隔：各SQL文の分析期間。デフォルトでは30分です。SQL文機能は、一定期間内のすべてのSQL文を集計し、カウントします。期間が長すぎると集計の粒度が粗くなり、問題の特定に適さなくなります。期間が短すぎると統計の粒度が細かくなり、問題の特定には適しますが、同じデータ保持期間内でのレコード数とメモリ使用量が増加します。したがって、実際の状況に応じてこの値を調整し、問題の特定時には適切にこの値を下げる必要があります。 +- データ保持期間：概要情報の保持期間。デフォルトでは1日です。この期間を超えて保持されたデータは、システムテーブルから削除されます。 詳細は[ステートメントサマリーテーブルの構成](/statement-summary-tables.md#parameter-configuration)を参照してください。 > **Note:** > -> - ステートメント システム テーブルはメモリ内にのみ保存されるため、SQL ステートメント機能が無効にされると、システム テーブル内のデータはクリアされます。 +> - ステートメント システム テーブルはメモリ内にのみ保存されるため、SQL ステートメント機能が無効にされると、システム テーブル内のデータはクリアされます。 > -> - `Collect interval`と`retain duration`の値はメモリ使用量に影響するため、実際の状況に応じて調整することをお勧めします`retain duration`の値は大きすぎないようにしてください。 +> - `Collect interval`と`retain duration`の値はメモリ使用量に影響するため、実際の状況に応じて調整することをお勧めします`retain duration`の値は大きすぎないようにしてください。 ### その他 {#others} diff --git a/dashboard/dashboard-user.md b/dashboard/dashboard-user.md index cfcf1341dc753..7cc8734a1685b 100644 --- a/dashboard/dashboard-user.md +++ b/dashboard/dashboard-user.md @@ -11,31 +11,31 @@ TiDB SQLユーザーを制御および管理する方法の詳細については ## 必要な権限 {#required-privileges} -- 接続された TiDBサーバーで[セキュリティ強化モード（SEM）](/system-variables.md#tidb_enable_enhanced_security)が有効になっていない場合に TiDB Dashboardにアクセスするには、SQL ユーザーに次の**すべての**権限が必要です。 +- 接続された TiDBサーバーで[セキュリティ強化モード（SEM）](/system-variables.md#tidb_enable_enhanced_security)が有効になっていない場合に TiDB Dashboardにアクセスするには、SQL ユーザーに次の**すべての**権限が必要です。 - - プロセス - - データベースを表示 - - 設定 - - ダッシュボードクライアント + - プロセス + - データベースを表示 + - 設定 + - ダッシュボードクライアント -- 接続された TiDBサーバーで[セキュリティ強化モード（SEM）](/system-variables.md#tidb_enable_enhanced_security)が有効になっているときに TiDB Dashboardにアクセスするには、SQL ユーザーに次の**すべての**権限が必要です。 +- 接続された TiDBサーバーで[セキュリティ強化モード（SEM）](/system-variables.md#tidb_enable_enhanced_security)が有効になっているときに TiDB Dashboardにアクセスするには、SQL ユーザーに次の**すべての**権限が必要です。 - - プロセス - - データベースを表示 - - 設定 - - ダッシュボードクライアント - - 制限付きテーブル管理者 - - 制限付きステータス管理者 - - 制限付き変数管理者 + - プロセス + - データベースを表示 + - 設定 + - ダッシュボードクライアント + - 制限付きテーブル管理者 + - 制限付きステータス管理者 + - 制限付き変数管理者 -- TiDB Dashboardにサインインした後、インターフェイス上の構成を変更するには、SQL ユーザーに次の権限も必要です。 +- TiDB Dashboardにサインインした後、インターフェイス上の構成を変更するには、SQL ユーザーに次の権限も必要です。 - - システム変数管理者 + - システム変数管理者 -- TiDB Dashboardにサインインした後、インターフェース上の[高速バインド実行計画](/dashboard/dashboard-statement-details.md#fast-plan-binding)機能を使用するには、SQL ユーザーに次の権限も必要です。 +- TiDB Dashboardにサインインした後、インターフェース上の[高速バインド実行計画](/dashboard/dashboard-statement-details.md#fast-plan-binding)機能を使用するには、SQL ユーザーに次の権限も必要です。 - - システム変数管理者 - - SUPER + - システム変数管理者 + - SUPER > **Note:** > @@ -47,7 +47,7 @@ SQL ユーザーが前述の権限要件を満たしていない場合、以下 ## 例: TiDB Dashboardにアクセスするための最小権限の SQL ユーザーを作成する {#example-create-a-least-privileged-sql-user-to-access-tidb-dashboard} -- 接続された TiDBサーバーで[セキュリティ強化モード（SEM）](/system-variables.md#tidb_enable_enhanced_security)が有効になっていない場合、TiDB Dashboardにサインインできる SQL ユーザー`dashboardAdmin`を作成するには、次の SQL ステートメントを実行します。 +- 接続された TiDBサーバーで[セキュリティ強化モード（SEM）](/system-variables.md#tidb_enable_enhanced_security)が有効になっていない場合、TiDB Dashboardにサインインできる SQL ユーザー`dashboardAdmin`を作成するには、次の SQL ステートメントを実行します。 ```sql CREATE USER 'dashboardAdmin'@'%' IDENTIFIED BY ''; @@ -63,7 +63,7 @@ SQL ユーザーが前述の権限要件を満たしていない場合、以下 GRANT SUPER ON *.* TO 'dashboardAdmin'@'%'; ``` -- 接続先のTiDBサーバーで[セキュリティ強化モード（SEM）](/system-variables.md#tidb_enable_enhanced_security)が有効になっている場合は、まずSEMを無効にし、以下のSQL文を実行して、TiDB DashboardにサインインできるSQLユーザー`dashboardAdmin`を作成します。ユーザーを作成したら、SEMを再度有効にします。 +- 接続先のTiDBサーバーで[セキュリティ強化モード（SEM）](/system-variables.md#tidb_enable_enhanced_security)が有効になっている場合は、まずSEMを無効にし、以下のSQL文を実行して、TiDB DashboardにサインインできるSQLユーザー`dashboardAdmin`を作成します。ユーザーを作成したら、SEMを再度有効にします。 ```sql CREATE USER 'dashboardAdmin'@'%' IDENTIFIED BY ''; @@ -86,7 +86,7 @@ SQL ユーザーが前述の権限要件を満たしていない場合、以下 次の例は、 [ロールベースのアクセス制御（RBAC）](/role-based-access-control.md)メカニズムを通じて TiDB Dashboardにアクセスするためのロールとユーザーを作成する方法を示しています。 -1. TiDB Dashboardのすべての権限要件を満たす`dashboard_access`ロールを作成します。 +1. TiDB Dashboardのすべての権限要件を満たす`dashboard_access`ロールを作成します。 ```sql CREATE ROLE 'dashboard_access'; @@ -97,7 +97,7 @@ SQL ユーザーが前述の権限要件を満たしていない場合、以下 GRANT SUPER ON *.* TO 'dashboardAdmin'@'%'; ``` -2. `dashboard_access`ロールを他のユーザーに付与し、 `dashboard_access`デフォルトのロールとして設定します。 +2. `dashboard_access`ロールを他のユーザーに付与し、 `dashboard_access`デフォルトのロールとして設定します。 ```sql CREATE USER 'dashboardAdmin'@'%' IDENTIFIED BY ''; diff --git a/dashboard/top-sql.md b/dashboard/top-sql.md index 36da5bf0ee83c..ba45955bb0997 100644 --- a/dashboard/top-sql.md +++ b/dashboard/top-sql.md @@ -12,36 +12,36 @@ TiDB DashboardのTop SQLページでは、指定したTiDBまたはTiKVノード Top SQLは以下の機能を提供します。 -- 現在の時間範囲で最も多くのリソースを消費する上位`5`、`20`、または`100`件のSQLクエリをグラフと表で可視化し、残りのレコードは自動的に`Others`として集約されます。 -- CPU時間またはネットワークバイトでソートされたリソース消費のホットスポットを表示します。TiKVノードを選択した場合は、論理I/Oバイトでソートすることもできます。 -- クエリごとにSQLと実行計画の詳細を表示します。TiKVノードを選択した場合は、`By Table`、`By DB`、`By Region`の次元で集計分析を行うこともできます。 -- グラフで選択した時間範囲を拡大し、データを手動で更新し、自動更新を有効にし、表データをCSVにエクスポートします。 -- 実行されたすべてのSQL文（現在実行中のものも含む）を収集します。 -- 特定のTiDBまたはTiKVノードのデータを表示します。 +- 現在の時間範囲で最も多くのリソースを消費する上位`5`、`20`、または`100`件のSQLクエリをグラフと表で可視化し、残りのレコードは自動的に`Others`として集約されます。 +- CPU時間またはネットワークバイトでソートされたリソース消費のホットスポットを表示します。TiKVノードを選択した場合は、論理I/Oバイトでソートすることもできます。 +- クエリごとにSQLと実行計画の詳細を表示します。TiKVノードを選択した場合は、`By Table`、`By DB`、`By Region`の次元で集計分析を行うこともできます。 +- グラフで選択した時間範囲を拡大し、データを手動で更新し、自動更新を有効にし、表データをCSVにエクスポートします。 +- 実行されたすべてのSQL文（現在実行中のものも含む）を収集します。 +- 特定のTiDBまたはTiKVノードのデータを表示します。 ## 推奨シナリオ {#recommended-scenarios} Top SQLは、パフォーマンスの問題を分析するのに適しています。以下に、 Top SQLの典型的なシナリオをいくつか示します。 -- クラスター内の特定のTiDBまたはTiKVノードのCPU使用率が非常に高いことがわかりました。どの種類のSQLが大量のCPUリソースを消費しているかをすばやく特定したいと考えています。 -- クラスター全体のクエリが遅くなっています。現在最も多くのリソースを消費しているSQLを見つけたい、またはワークロードの変化の前後で主なクエリの違いを比較したいと考えています。 -- より高い次元からホットスポットを特定する必要があり、TiKV側で`Table`、`DB`、または`Region`ごとにリソース消費を集計して表示したいと考えています。 -- CPU次元だけでなく、ネットワークトラフィックまたは論理I/Oの観点からTiKVホットスポットをトラブルシューティングする必要があります。 +- クラスター内の特定のTiDBまたはTiKVノードのCPU使用率が非常に高いことがわかりました。どの種類のSQLが大量のCPUリソースを消費しているかをすばやく特定したいと考えています。 +- クラスター全体のクエリが遅くなっています。現在最も多くのリソースを消費しているSQLを見つけたい、またはワークロードの変化の前後で主なクエリの違いを比較したいと考えています。 +- より高い次元からホットスポットを特定する必要があり、TiKV側で`Table`、`DB`、または`Region`ごとにリソース消費を集計して表示したいと考えています。 +- CPU次元だけでなく、ネットワークトラフィックまたは論理I/Oの観点からTiKVホットスポットをトラブルシューティングする必要があります。 以下のシナリオでは、Top SQLは使用できません。 -- Top SQLは、データの誤りや異常なクラッシュなど、パフォーマンス以外の問題を特定するために使用することはできません。 -- Top SQLは、ロック競合、トランザクションのセマンティクスエラー、またはリソース消費が原因ではないその他の問題を直接分析するには適していません。 +- Top SQLは、データの誤りや異常なクラッシュなど、パフォーマンス以外の問題を特定するために使用することはできません。 +- Top SQLは、ロック競合、トランザクションのセマンティクスエラー、またはリソース消費が原因ではないその他の問題を直接分析するには適していません。 ## ページにアクセスしてください {#access-the-page} 以下のいずれかの方法で、Top SQLページにアクセスできます。 -- TiDB Dashboardにログイン後、左側のナビゲーションメニューにある**Top SQL**をクリックしてください。 +- TiDB Dashboardにログイン後、左側のナビゲーションメニューにある**Top SQL**をクリックしてください。 ![Top SQL](/media/dashboard/v8.5-top-sql-access.png) -- ブラウザで[http://127.0.0.1:2379/dashboard/#/topsql](http://127.0.0.1:2379/dashboard/#/topsql)にアクセスしてください。 `127.0.0.1:2379`を実際の PD ノードのアドレスとポートに置き換えてください。 +- ブラウザで[http://127.0.0.1:2379/dashboard/#/topsql](http://127.0.0.1:2379/dashboard/#/topsql)にアクセスしてください。 `127.0.0.1:2379`を実際の PD ノードのアドレスとポートに置き換えてください。 ## Top SQLを有効にする {#enable-top-sql} @@ -51,9 +51,9 @@ Top SQLは、パフォーマンスの問題を分析するのに適していま Top SQLは、有効にするとクラスタのパフォーマンスにわずかな影響（平均で3%以内）を与えるため、デフォルトでは有効になっていません。Top Top SQLを有効にするには、以下の手順に従ってください。 -1. [Top SQLページ](#access-the-page)にアクセスしてください。 -2. **Open Settings**をクリックします。ページ右側の**Settings**領域で、**Enable Feature**スイッチを有効にします。 -3. **Save**をクリックしてください。 +1. [Top SQLページ](#access-the-page)にアクセスしてください。 +2. **Open Settings**をクリックします。ページ右側の**Settings**領域で、**Enable Feature**スイッチを有効にします。 +3. **Save**をクリックしてください。 Top SQLを有効にすると、この時点以降に収集されたデータのみを表示でき、有効化前の履歴データは補完されません。データ表示には通常約1分の遅延があるため、新しいデータを確認するには少し待つ必要があります。Top SQLを無効にした後も、履歴データの有効期限が切れていなければ、Top SQLページにはこの履歴データが引き続き表示されますが、新しいデータは収集も表示もされなくなります。 @@ -90,15 +90,15 @@ TiUPトポロジー設定の詳細については、 [TiUPクラスターのト 以下は、 Top SQL を使用するための一般的な手順です。 -1. [Top SQLページ](#access-the-page)にアクセスしてください。 +1. [Top SQLページ](#access-the-page)にアクセスしてください。 -2. ワークロードを監視したい特定のTiDBまたはTiKVノードを選択してください。 +2. ワークロードを監視したい特定のTiDBまたはTiKVノードを選択してください。 ![Select a TiDB or TiKV node](/media/dashboard/v8.5-top-sql-usage-select-instance.png) どのノードを監視すればよいかわからない場合は、まずGrafanaまたは[TiDB DashboardのOverviewページ](/dashboard/dashboard-overview.md)でワークロードが異常なノードを特定し、その後Top SQLページに戻ってさらに分析できます。 -3. 必要に応じて時間範囲を設定し、データを更新します。 +3. 必要に応じて時間範囲を設定し、データを更新します。 タイムピッカーで時間範囲を調整するか、グラフで時間範囲を選択して観測ウィンドウを拡大できます。時間範囲を小さく設定すると、最大1秒の精度でよりきめ細かいデータが表示されます。 @@ -108,7 +108,7 @@ TiUPトポロジー設定の詳細については、 [TiUPクラスターのト ![Refresh](/media/dashboard/v8.5-top-sql-usage-refresh.png) -4. 観測モードを選択します。 +4. 観測モードを選択します。 - `Limit`を使用して、Top `5`、`20`、または`100`件のSQLクエリを表示します。 - デフォルトの集計次元は`By Query`です。TiKVノードを選択した場合は、`By Table`、`By DB`、または`By Region`の次元で集計することもできます。 @@ -123,13 +123,13 @@ TiUPトポロジー設定の詳細については、 [TiUPクラスターのト > > `By Region`、`Order By Network`、および`Order By Logical IO`は、[TiKV Network IO collection (multi-dimensional)](#optional-enable-tikv-network-io-collection-new-in-v857)が有効な場合にのみ使用できます。この機能が有効でなくても履歴データがまだ存在する場合、ページには引き続き履歴データが表示され、新しいデータを完全には収集できないことが示されます。 -5. グラフと表でリソース消費のホットスポットレコードを確認します。 +5. グラフと表でリソース消費のホットスポットレコードを確認します。 ![Chart and Table](/media/dashboard/v8.5-top-sql-usage-chart.png) 棒グラフは現在のソート次元でのリソース消費を示し、異なる色は異なるレコードを表します。表には現在のソート次元に従った累積値が表示され、末尾にはTop N以外のすべてのレコードを集約する`Others`行が表示されます。 -6. `By Query`ビューで、表の行をクリックすると、その種類のSQLの実行計画詳細を表示できます。 +6. `By Query`ビューで、表の行をクリックすると、その種類のSQLの実行計画詳細を表示できます。 ![Details](/media/dashboard/v8.5-top-sql-details.png) @@ -144,20 +144,20 @@ TiUPトポロジー設定の詳細については、 [TiUPクラスターのト `By Query`ビューでは、Top SQLテーブル内の**Search in SQL Statements**をクリックして、対応するSQL Statement Analysisページに移動することもできます。現在の表の結果をオフラインで分析する必要がある場合は、表の上にある**Download to CSV**をクリックして現在の表データをエクスポートできます。 -7. TiKVノードで、より高い次元からホットスポットを特定する必要がある場合は、`By Table`、`By DB`、または`By Region`に切り替えて集計結果を表示できます。 +7. TiKVノードで、より高い次元からホットスポットを特定する必要がある場合は、`By Table`、`By DB`、または`By Region`に切り替えて集計結果を表示できます。 ![Aggregated results at DB level](/media/dashboard/v8.5-top-sql-usage-agg-by-db-detail.png) -8. これらの最初の手がかりに基づいて、 [SQLステートメント](/dashboard/dashboard-statement-list.md)または[スロークエリ](/dashboard/dashboard-slow-query.md)ページを使用して根本原因をさらに分析できます。 +8. これらの最初の手がかりに基づいて、 [SQLステートメント](/dashboard/dashboard-statement-list.md)または[スロークエリ](/dashboard/dashboard-slow-query.md)ページを使用して根本原因をさらに分析できます。 ## Top SQLを無効にする {#disable-top-sql} 以下の手順に従うことで、この機能を無効にすることができます。 -1. [Top SQLページ](#access-the-page)にアクセスしてください。 -2. 右上隅の歯車アイコンをクリックして設定ペインを開き、**Enable Feature**スイッチを無効にします。 -3. **Save**をクリックしてください。 -4. ポップアップ表示されたダイアログボックスで、 **Disable**をクリックします。 +1. [Top SQLページ](#access-the-page)にアクセスしてください。 +2. 右上隅の歯車アイコンをクリックして設定ペインを開き、**Enable Feature**スイッチを無効にします。 +3. **Save**をクリックしてください。 +4. ポップアップ表示されたダイアログボックスで、 **Disable**をクリックします。 Top SQLを無効にすると、Top SQLは新しいデータの収集を停止しますが、有効期限が切れる前の履歴データは引き続き表示できます。 diff --git a/data-type-date-and-time.md b/data-type-date-and-time.md index 1ccabafd97d3c..391e535d99f51 100644 --- a/data-type-date-and-time.md +++ b/data-type-date-and-time.md @@ -11,11 +11,11 @@ TiDBは、時間値を格納するためにMySQLのすべての日付と時刻 日付と時刻の値の型を扱うときは、次の点に注意してください。 -- TiDB はさまざまな形式を解釈しようとしますが、日付部分は月-日-年や日-月-年ではなく、年-月-日 (たとえば、「1998-09-04」) の形式である必要があります。 +- TiDB はさまざまな形式を解釈しようとしますが、日付部分は月-日-年や日-月-年ではなく、年-月-日 (たとえば、「1998-09-04」) の形式である必要があります。 -- 日付の年の部分が 2 桁で指定されている場合、TiDB はそれを[特定のルール](#two-digit-year-portion-contained-in-the-date)に基づいて変換します。 +- 日付の年の部分が 2 桁で指定されている場合、TiDB はそれを[特定のルール](#two-digit-year-portion-contained-in-the-date)に基づいて変換します。 -- コンテキスト内で数値が必要な場合、TiDBは日付または時刻値を自動的に数値型に変換します。例: +- コンテキスト内で数値が必要な場合、TiDBは日付または時刻値を自動的に数値型に変換します。例: ```sql mysql> SELECT NOW(), NOW()+0, NOW(3)+0; @@ -26,7 +26,7 @@ TiDBは、時間値を格納するためにMySQLのすべての日付と時刻 +---------------------+----------------+--------------------+ ``` -- TiDBは、無効な値やサポート範囲外の値を、その型のゼロ値に自動的に変換することがあります。この動作はSQLモードの設定に依存します。例： +- TiDBは、無効な値やサポート範囲外の値を、その型のゼロ値に自動的に変換することがあります。この動作はSQLモードの設定に依存します。例： ```sql mysql> show create table t1; @@ -63,11 +63,11 @@ TiDBは、時間値を格納するためにMySQLのすべての日付と時刻 1 row in set (0.01 sec) ``` -- 異なる SQL モードを設定すると、TiDB の動作が変わる場合があります。 +- 異なる SQL モードを設定すると、TiDB の動作が変わる場合があります。 -- SQLモード`NO_ZERO_DATE`が有効になっていない場合、TiDBは列`DATE`と`DATETIME`の月または日にゼロ値（例：「2009-00-00」または「2009-01-00」）を許可します。この日付型を関数（例：列`DATE_SUB()`または`DATE_ADD()` ）で計算する場合、結果が不正確になる可能性があります。 +- SQLモード`NO_ZERO_DATE`が有効になっていない場合、TiDBは列`DATE`と`DATETIME`の月または日にゼロ値（例：「2009-00-00」または「2009-01-00」）を許可します。この日付型を関数（例：列`DATE_SUB()`または`DATE_ADD()` ）で計算する場合、結果が不正確になる可能性があります。 -- デフォルトでは、TiDBはSQLモード`NO_ZERO_DATE`有効にします。このモードでは、「0000-00-00」などのゼロ値が保存されるのを防ぎます。 +- デフォルトでは、TiDBはSQLモード`NO_ZERO_DATE`有効にします。このモードでは、「0000-00-00」などのゼロ値が保存されるのを防ぎます。 さまざまな種類のゼロ値を次の表に示します。 @@ -141,11 +141,11 @@ YEAR[(4)] `YEAR`は次の形式規則に従います。 -- 4桁の数字の範囲は1901年から2155年までです -- 4桁の文字列の範囲は「1901」から「2155」までです -- 1桁または2桁の数字の範囲は1から99です。したがって、1〜69は2001〜2069に変換され、70〜99は1970〜1999に変換されます。 -- 1桁または2桁の文字列の範囲は「0」から「99」までです -- 値0は0000として扱われ、文字列「0」または「00」は2000として扱われます。 +- 4桁の数字の範囲は1901年から2155年までです +- 4桁の文字列の範囲は「1901」から「2155」までです +- 1桁または2桁の数字の範囲は1から99です。したがって、1〜69は2001〜2069に変換され、70〜99は1970〜1999に変換されます。 +- 1桁または2桁の文字列の範囲は「0」から「99」までです +- 値0は0000として扱われ、文字列「0」または「00」は2000として扱われます。 無効な値`YEAR`は自動的に 0000 に変換されます (ユーザーが`NO_ZERO_DATE` SQL モードを使用していない場合)。 @@ -177,7 +177,7 @@ CREATE TABLE t1 ( `DATETIME`と`TIMESTAMP`値は、マイクロ秒単位の精度で最大 6 桁の小数部を持つことができます。`DATETIME`型または`TIMESTAMP`型のいずれかの列では、小数部は破棄されずに保存されます。小数部がある場合、値は「YYYY-MM-DD HH:MM:SS[.fraction]」の形式で表され、小数部の範囲は 000000 から 999999 です。小数部と残りの部分を区切るために小数点を使用する必要があります。 -- 小数精度をサポートする列を定義するには`type_name(fsp)`を使用します。`type_name`は`TIME` 、 `DATETIME`または`TIMESTAMP`になります。例えば、 +- 小数精度をサポートする列を定義するには`type_name(fsp)`を使用します。`type_name`は`TIME` 、 `DATETIME`または`TIMESTAMP`になります。例えば、 ```sql CREATE TABLE t1 (t TIME(3), dt DATETIME(6)); @@ -187,7 +187,7 @@ CREATE TABLE t1 ( `0`は小数部がないことを意味します。`fsp`を省略した場合、デフォルトは0です。 -- 小数部を含む`TIME` 、 `DATETIME` 、または`TIMESTAMP`挿入する場合、小数部の桁数が少なすぎる、または多すぎる場合は、四捨五入が必要になることがあります。例： +- 小数部を含む`TIME` 、 `DATETIME` 、または`TIMESTAMP`挿入する場合、小数部の桁数が少なすぎる、または多すぎる場合は、四捨五入が必要になることがあります。例： ```sql mysql> CREATE TABLE fractest( c1 TIME(2), c2 DATETIME(2), c3 TIMESTAMP(2) ); @@ -212,13 +212,13 @@ CREATE TABLE t1 ( `DATE`の変換: -- `DATE`を`DATETIME`または`TIMESTAMP`に変換すると、DATEには時間情報が含まれていないため、時間部分「00:00:00」が追加されます。 -- `DATE`を`TIME`に変換すると、結果は「00:00:00」になります。 +- `DATE`を`DATETIME`または`TIMESTAMP`に変換すると、DATEには時間情報が含まれていないため、時間部分「00:00:00」が追加されます。 +- `DATE`を`TIME`に変換すると、結果は「00:00:00」になります。 `DATETIME`または`TIMESTAMP`の変換: -- `DATETIME`または`TIMESTAMP` `DATE`に変換する場合、時刻と小数部分は切り捨てられます。例えば、「1999-12-31 23:59:59.499」は「1999-12-31」に変換されます。 -- `DATETIME`または`TIMESTAMP`をTIMEに変換すると、 `TIME`は日付情報が含まれていないため、日付部分は破棄されます。 +- `DATETIME`または`TIMESTAMP` `DATE`に変換する場合、時刻と小数部分は切り捨てられます。例えば、「1999-12-31 23:59:59.499」は「1999-12-31」に変換されます。 +- `DATETIME`または`TIMESTAMP`をTIMEに変換すると、 `TIME`は日付情報が含まれていないため、日付部分は破棄されます。 `TIME`を他の日時形式に変換すると、日付部分は自動的に`CURRENT_DATE()`に指定されます。最終的な変換結果は、 `TIME`と`CURRENT_DATE()`で構成される日付になります。つまり、TIME の値が '00:00:00' から '23:59:59' の範囲外の場合、変換後の日付部分は現在の日付を示しません。 @@ -253,8 +253,8 @@ mysql> SELECT NOW(), NOW()+0, NOW(3)+0; `DATETIME` `DATE` `TIMESTAMP`の場合、TiDB は曖昧さを排除するために次の規則に従います。 -- 01から69までの値は2001から2069までの値に変換されます -- 70から99までの値は1970から1999までの値に変換されます +- 01から69までの値は2001から2069までの値に変換されます +- 70から99までの値は1970から1999までの値に変換されます これらのルールは`YEAR`タイプにも適用されますが、1 つの例外があります。 diff --git a/data-type-default-values.md b/data-type-default-values.md index 431dad50ba106..b58497fd322bf 100644 --- a/data-type-default-values.md +++ b/data-type-default-values.md @@ -9,27 +9,27 @@ summary: TiDB のデータ型のデフォルト値について学習します。 すべてのデータ型にデフォルト値を設定できます。通常、デフォルト値は定数であり、関数や式は使用できませんが、いくつか例外があります。 -- 時間型の場合、 `TIMESTAMP`と`DATETIME`列のデフォルト値として`NOW` 、 `CURRENT_TIMESTAMP` 、 `LOCALTIME` 、 `LOCALTIMESTAMP`関数を使用できます。 -- 整数型の場合、 `NEXT VALUE FOR`関数を使用してシーケンスの次の値を列の既定値として設定し、 [`RAND()`](/functions-and-operators/numeric-functions-and-operators.md)関数を使用してランダムな浮動小数点値を列の既定値として生成できます。 -- 文字列型の場合、 [`UUID()`](/functions-and-operators/miscellaneous-functions.md)関数を使用して、列のデフォルト値として[ユニバーサルユニーク識別子 (UUID)](/best-practices/uuid.md)を生成できます。 -- バイナリ型の場合、 [`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md)関数を使用して UUID をバイナリ形式に変換し、変換された値を列のデフォルト値として設定できます。 -- v8.0.0 以降、TiDB は[`BLOB`](/data-type-string.md#blob-type) 、 [`TEXT`](/data-type-string.md#text-type) 、 [`JSON`](/data-type-json.md#json-data-type)データ型に対して[デフォルト値を指定する](#specify-expressions-as-default-values)を追加でサポートしますが、それらに対して[デフォルト値](#default-values)を設定するには式のみを使用できます。 +- 時間型の場合、 `TIMESTAMP`と`DATETIME`列のデフォルト値として`NOW` 、 `CURRENT_TIMESTAMP` 、 `LOCALTIME` 、 `LOCALTIMESTAMP`関数を使用できます。 +- 整数型の場合、 `NEXT VALUE FOR`関数を使用してシーケンスの次の値を列の既定値として設定し、 [`RAND()`](/functions-and-operators/numeric-functions-and-operators.md)関数を使用してランダムな浮動小数点値を列の既定値として生成できます。 +- 文字列型の場合、 [`UUID()`](/functions-and-operators/miscellaneous-functions.md)関数を使用して、列のデフォルト値として[ユニバーサルユニーク識別子 (UUID)](/best-practices/uuid.md)を生成できます。 +- バイナリ型の場合、 [`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md)関数を使用して UUID をバイナリ形式に変換し、変換された値を列のデフォルト値として設定できます。 +- v8.0.0 以降、TiDB は[`BLOB`](/data-type-string.md#blob-type) 、 [`TEXT`](/data-type-string.md#text-type) 、 [`JSON`](/data-type-json.md#json-data-type)データ型に対して[デフォルト値を指定する](#specify-expressions-as-default-values)を追加でサポートしますが、それらに対して[デフォルト値](#default-values)を設定するには式のみを使用できます。 列定義に明示的な`DEFAULT`値が含まれていない場合、TiDB は次のようにデフォルト値を決定します。 -- 列が値として`NULL`取ることができる場合、列は明示的な`DEFAULT NULL`句で定義されます。 -- 列が値として`NULL`取ることができない場合は、TiDB は明示的な`DEFAULT`句なしで列を定義します。 +- 列が値として`NULL`取ることができる場合、列は明示的な`DEFAULT NULL`句で定義されます。 +- 列が値として`NULL`取ることができない場合は、TiDB は明示的な`DEFAULT`句なしで列を定義します。 明示的な`DEFAULT`句のない`NOT NULL`列へのデータ入力の場合、 `INSERT`または`REPLACE`ステートメントに列の値が含まれていないと、TiDB はその時点で有効な SQL モードに従って列を処理します。 -- 厳密なSQLモードが有効になっている場合、トランザクションテーブルではエラーが発生し、文はロールバックされます。非トランザクションテーブルではエラーが発生します。 -- 厳密モードが有効になっていない場合、TiDB は列を列データ型の暗黙的なデフォルト値に設定します。 +- 厳密なSQLモードが有効になっている場合、トランザクションテーブルではエラーが発生し、文はロールバックされます。非トランザクションテーブルではエラーが発生します。 +- 厳密モードが有効になっていない場合、TiDB は列を列データ型の暗黙的なデフォルト値に設定します。 暗黙のデフォルトは次のように定義されます。 -- 数値型の場合、デフォルトは 0 です。`AUTO_INCREMENT`で宣言された場合、デフォルトはシーケンス内の次の値になります。 -- `TIMESTAMP`以外の日付と時刻型の場合、デフォルト値はその型に適切な「ゼロ」値です。`TIMESTAMP`の場合、デフォルト値は現在の日付と時刻です。 -- `ENUM`以外の文字列型の場合、デフォルト値は空文字列です。`ENUM`の場合、デフォルト値は最初の列挙値です。 +- 数値型の場合、デフォルトは 0 です。`AUTO_INCREMENT`で宣言された場合、デフォルトはシーケンス内の次の値になります。 +- `TIMESTAMP`以外の日付と時刻型の場合、デフォルト値はその型に適切な「ゼロ」値です。`TIMESTAMP`の場合、デフォルト値は現在の日付と時刻です。 +- `ENUM`以外の文字列型の場合、デフォルト値は空文字列です。`ENUM`の場合、デフォルト値は最初の列挙値です。 ## 式をデフォルト値として指定する {#specify-expressions-as-default-values} @@ -37,20 +37,20 @@ MySQL 8.0.13以降では、 `DEFAULT`句のデフォルト値として式を指 TiDB は、 `DEFAULT`句のデフォルト値として次の式を指定することをサポートしています。 -- `UPPER(SUBSTRING_INDEX(USER(), '@', 1))` -- `REPLACE(UPPER(UUID()), '-', '')` -- 次の形式の`DATE_FORMAT`式: - - `DATE_FORMAT(NOW(), '%Y-%m')` - - `DATE_FORMAT(NOW(), '%Y-%m-%d')` - - `DATE_FORMAT(NOW(), '%Y-%m-%d %H.%i.%s')` - - `DATE_FORMAT(NOW(), '%Y-%m-%d %H:%i:%s')` -- `STR_TO_DATE('1980-01-01', '%Y-%m-%d')` -- [`CURRENT_TIMESTAMP()`](/functions-and-operators/date-and-time-functions.md) 、 [`CURRENT_DATE()`](/functions-and-operators/date-and-time-functions.md) : どちらもデフォルトの小数秒精度 (fsp) を使用します -- [`JSON_OBJECT()`](/functions-and-operators/json-functions.md) [`JSON_ARRAY()`](/functions-and-operators/json-functions.md) [`JSON_QUOTE()`](/functions-and-operators/json-functions.md) -- [`NEXTVAL()`](/functions-and-operators/sequence-functions.md#nextval) -- [`RAND()`](/functions-and-operators/numeric-functions-and-operators.md) -- [`UUID()`](/functions-and-operators/miscellaneous-functions.md#uuid) [`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md#uuid_to_bin) -- [`VEC_FROM_TEXT()`](/ai/reference/vector-search-functions-and-operators.md#vec_from_text) +- `UPPER(SUBSTRING_INDEX(USER(), '@', 1))` +- `REPLACE(UPPER(UUID()), '-', '')` +- 次の形式の`DATE_FORMAT`式: + - `DATE_FORMAT(NOW(), '%Y-%m')` + - `DATE_FORMAT(NOW(), '%Y-%m-%d')` + - `DATE_FORMAT(NOW(), '%Y-%m-%d %H.%i.%s')` + - `DATE_FORMAT(NOW(), '%Y-%m-%d %H:%i:%s')` +- `STR_TO_DATE('1980-01-01', '%Y-%m-%d')` +- [`CURRENT_TIMESTAMP()`](/functions-and-operators/date-and-time-functions.md) 、 [`CURRENT_DATE()`](/functions-and-operators/date-and-time-functions.md) : どちらもデフォルトの小数秒精度 (fsp) を使用します +- [`JSON_OBJECT()`](/functions-and-operators/json-functions.md) [`JSON_ARRAY()`](/functions-and-operators/json-functions.md) [`JSON_QUOTE()`](/functions-and-operators/json-functions.md) +- [`NEXTVAL()`](/functions-and-operators/sequence-functions.md#nextval) +- [`RAND()`](/functions-and-operators/numeric-functions-and-operators.md) +- [`UUID()`](/functions-and-operators/miscellaneous-functions.md#uuid) [`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md#uuid_to_bin) +- [`VEC_FROM_TEXT()`](/ai/reference/vector-search-functions-and-operators.md#vec_from_text) TiDBは、 `BLOB` 、 `TEXT` 、 `JSON`データ型にデフォルト値を割り当てることができます。ただし、これらのデータ型のデフォルト値を定義するには、リテラルではなく式のみを使用できます。以下は`BLOB`の例です。 diff --git a/data-type-json.md b/data-type-json.md index 88f942ec3326c..64ee855b2aad7 100644 --- a/data-type-json.md +++ b/data-type-json.md @@ -7,8 +7,8 @@ summary: TiDB の JSON データ型について学習します。 TiDBは、半構造化データの保存に便利な`JSON` （JavaScript Object Notation）データ型をサポートしています。`JSON`データ型は、文字列列に`JSON`形式の文字列を保存する場合と比べて、以下の利点があります。 -- シリアル化にはバイナリ形式を使用します。内部形式により、 `JSON`ドキュメント要素への高速な読み取りアクセスが可能になります。 -- `JSON`列に保存されたJSONドキュメントを自動検証します。有効なドキュメントのみを保存できます。 +- シリアル化にはバイナリ形式を使用します。内部形式により、 `JSON`ドキュメント要素への高速な読み取りアクセスが可能になります。 +- `JSON`列に保存されたJSONドキュメントを自動検証します。有効なドキュメントのみを保存できます。 `JSON`列は、他のバイナリ型の列と同様に直接インデックス付けされませんが、生成列の形式で`JSON`ドキュメント内のフィールドをインデックス付けできます。 @@ -48,13 +48,13 @@ JSONドキュメント内の値には型があります。これは[`JSON_TYPE` ## 制限 {#restrictions} -- 現在、TiDBはTiFlashへのプッシュダウンを限定的に`JSON`関数のみサポートしています。詳細については[プッシュダウン式](/tiflash/tiflash-supported-pushdown-calculations.md#push-down-expressions)をご覧ください。 -- TiDBバックアップ＆リストア（BR）は、v6.3.0でJSON列データのエンコード方法を変更します。そのため、JSON列を含むデータをBRを使用してv6.3.0より前のTiDBクラスターにリストアすることは推奨されません。 -- `DATE` 、 `DATETIME` 、 `TIME`などの非標準`JSON`データ型を含むデータをレプリケートする場合は、レプリケーション ツールを使用しないでください。 +- 現在、TiDBはTiFlashへのプッシュダウンを限定的に`JSON`関数のみサポートしています。詳細については[プッシュダウン式](/tiflash/tiflash-supported-pushdown-calculations.md#push-down-expressions)をご覧ください。 +- TiDBバックアップ＆リストア（BR）は、v6.3.0でJSON列データのエンコード方法を変更します。そのため、JSON列を含むデータをBRを使用してv6.3.0より前のTiDBクラスターにリストアすることは推奨されません。 +- `DATE` 、 `DATETIME` 、 `TIME`などの非標準`JSON`データ型を含むデータをレプリケートする場合は、レプリケーション ツールを使用しないでください。 ## MySQLとの互換性 {#mysql-compatibility} -- `BINARY`型のデータを含む JSON 列を作成すると、MySQL は現在そのデータを`STRING`型として誤ってラベル付けしますが、TiDB はそれを`BINARY`型として正しく処理します。 +- `BINARY`型のデータを含む JSON 列を作成すると、MySQL は現在そのデータを`STRING`型として誤ってラベル付けしますが、TiDB はそれを`BINARY`型として正しく処理します。 ```sql CREATE TABLE test(a json); @@ -72,7 +72,7 @@ JSONドキュメント内の値には型があります。これは[`JSON_TYPE` 詳細については、issue [#37443](https://github.com/pingcap/tidb/issues/37443)を参照してください。 -- データ型を`ENUM`または`SET`から`JSON`に変換する際、TiDB はデータ形式の正確性をチェックします。例えば、TiDB で以下の SQL 文を実行するとエラーが返されます。 +- データ型を`ENUM`または`SET`から`JSON`に変換する際、TiDB はデータ形式の正確性をチェックします。例えば、TiDB で以下の SQL 文を実行するとエラーが返されます。 ```sql CREATE TABLE t(e ENUM('a')); @@ -83,7 +83,7 @@ JSONドキュメント内の値には型があります。これは[`JSON_TYPE` 詳細については、issue [#9999](https://github.com/pingcap/tidb/issues/9999)を参照してください。 -- TiDB では、 `ORDER BY`を使用して JSON 配列または JSON オブジェクトをソートできます。 +- TiDB では、 `ORDER BY`を使用して JSON 配列または JSON オブジェクトをソートできます。 MySQL では、 `ORDER BY`を使用して JSON 配列または JSON オブジェクトをソートすると、MySQL から警告が返され、ソート結果が比較演算の結果と一致しなくなります。 @@ -113,7 +113,7 @@ JSONドキュメント内の値には型があります。これは[`JSON_TYPE` 詳細については、issue [#37506](https://github.com/pingcap/tidb/issues/37506)を参照してください。 -- JSON 列にデータを挿入すると、TiDB は暗黙的にデータの値を`JSON`型に変換します。 +- JSON 列にデータを挿入すると、TiDB は暗黙的にデータの値を`JSON`型に変換します。 ```sql CREATE TABLE t(col JSON); diff --git a/data-type-numeric.md b/data-type-numeric.md index ab4bb831e41fe..6d747e3cc8f82 100644 --- a/data-type-numeric.md +++ b/data-type-numeric.md @@ -7,9 +7,9 @@ summary: TiDB でサポートされている数値データ型について学習 TiDB は、以下を含むすべての MySQL 数値型をサポートしています。 -- [整数型](#integer-types) (正確な値) -- [浮動小数点型](#floating-point-types) (近似値) -- [固定小数点型](#fixed-point-types) (正確な値) +- [整数型](#integer-types) (正確な値) +- [浮動小数点型](#floating-point-types) (近似値) +- [固定小数点型](#fixed-point-types) (正確な値) ## 整数型 {#integer-types} diff --git a/data-type-overview.md b/data-type-overview.md index fc9f57b3f49da..6160d5be29454 100644 --- a/data-type-overview.md +++ b/data-type-overview.md @@ -9,8 +9,8 @@ TiDBは[文字列型](/data-type-string.md) MySQLの`SPATIAL`型を除くすべ データ型に使用される定義は`T(M[, D])`として指定されます。 -- `T`は特定のデータ型を示します。 -- 整数型の場合、 `M`は最大表示幅を示します。浮動小数点型と固定小数点型の場合、 `M`は格納可能な桁数（精度）です。文字列型の場合、 `M`は最大長です。Mの許容最大値はデータ型によって異なります。 +- `T`は特定のデータ型を示します。 +- 整数型の場合、 `M`は最大表示幅を示します。浮動小数点型と固定小数点型の場合、 `M`は格納可能な桁数（精度）です。文字列型の場合、 `M`は最大長です。Mの許容最大値はデータ型によって異なります。 @@ -28,5 +28,5 @@ TiDBは[文字列型](/data-type-string.md) MySQLの`SPATIAL`型を除くすべ -- `D`は浮動小数点型と固定小数点型に適用され、小数点以下の桁数 (スケール) を示します。 -- `fsp`は`TIME` 、 `DATETIME` 、 `TIMESTAMP`型に適用され、小数秒の精度を表します。`fsp`を指定する場合は、0から6の範囲でなければなりません。0 は小数部がないことを意味します。省略した場合、デフォルトの精度は0です。 +- `D`は浮動小数点型と固定小数点型に適用され、小数点以下の桁数 (スケール) を示します。 +- `fsp`は`TIME` 、 `DATETIME` 、 `TIMESTAMP`型に適用され、小数秒の精度を表します。`fsp`を指定する場合は、0から6の範囲でなければなりません。0 は小数部がないことを意味します。省略した場合、デフォルトの精度は0です。 diff --git a/ddl_embedded_analyze.md b/ddl_embedded_analyze.md index 3c8ac7be7eef3..d7ceda003ebb3 100644 --- a/ddl_embedded_analyze.md +++ b/ddl_embedded_analyze.md @@ -7,8 +7,8 @@ summary: このドキュメントでは、新しく作成または再編成さ このドキュメントでは、次の 2 種類の DDL ステートメントに組み込まれている`ANALYZE`機能について説明します。 -- 新しいインデックスを作成するDDL文: [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) -- 既存のインデックスを再編成する DDL ステートメント: [`MODIFY COLUMN`](/sql-statements/sql-statement-modify-column.md)と[`CHANGE COLUMN`](/sql-statements/sql-statement-change-column.md) +- 新しいインデックスを作成するDDL文: [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) +- 既存のインデックスを再編成する DDL ステートメント: [`MODIFY COLUMN`](/sql-statements/sql-statement-modify-column.md)と[`CHANGE COLUMN`](/sql-statements/sql-statement-change-column.md) この機能を有効にすると、TiDBは新規または再編成されたインデックスがユーザーに表示される前に、自動的に`ANALYZE` （統計収集）操作を実行します。これにより、インデックスの作成または再編成後に一時的に統計が利用できなくなることによる、オプティマイザの推定値の不正確さや潜在的なプラン変更を防止できます。 @@ -113,8 +113,8 @@ ADMIN SHOW DDL JOBS 1; `tidb_stats_update_during_ddl`が`ON`の場合、インデックスの再編成を行う[`MODIFY COLUMN`](/sql-statements/sql-statement-modify-column.md)または[`CHANGE COLUMN`](/sql-statements/sql-statement-change-column.md)を実行すると、Reorg フェーズの完了後に埋め込まれた`ANALYZE`操作も実行されます。このメカニズムは`ADD INDEX`の場合と同じです。 -- インデックスが表示される前に統計の収集を開始します。 -- `ANALYZE`がタイムアウトすると、 [`MODIFY COLUMN`](/sql-statements/sql-statement-modify-column.md)と[`CHANGE COLUMN`](/sql-statements/sql-statement-change-column.md) `ANALYZE`完了を同期的に待つのをやめ、後続の処理を続行します。これにより、インデックスがユーザーにとってより早く表示されます。つまり、 `ANALYZE`非同期的に完了すると、インデックス統計が更新されます。 +- インデックスが表示される前に統計の収集を開始します。 +- `ANALYZE`がタイムアウトすると、 [`MODIFY COLUMN`](/sql-statements/sql-statement-modify-column.md)と[`CHANGE COLUMN`](/sql-statements/sql-statement-change-column.md) `ANALYZE`完了を同期的に待つのをやめ、後続の処理を続行します。これにより、インデックスがユーザーにとってより早く表示されます。つまり、 `ANALYZE`非同期的に完了すると、インデックス統計が更新されます。 例えば： diff --git a/deploy-monitoring-services.md b/deploy-monitoring-services.md index 25340c386e2aa..4be20d59dc997 100644 --- a/deploy-monitoring-services.md +++ b/deploy-monitoring-services.md @@ -105,12 +105,12 @@ scrape_configs: TiDB、PD、TiKV などのコンポーネントのアラーム ルールを有効にするには、対応するコンポーネントのアラーム ルール ファイルを個別にダウンロードし、アラーム ルール ファイルの構成を Prometheus 構成ファイルに追加します。 -- TiDB: [`tidb.rules.yml`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/metrics/alertmanager/tidb.rules.yml) -- PD: [`pd.rules.yml`](https://github.com/tikv/pd/blob/release-8.5/metrics/alertmanager/pd.rules.yml) -- TiKV: [`tikv.rules.yml`](https://github.com/tikv/tikv/blob/release-8.5/metrics/alertmanager/tikv.rules.yml) -- TiFlash: [`tiflash.rules.yml`](https://github.com/pingcap/tiflash/blob/release-8.5/metrics/alertmanager/tiflash.rules.yml) -- TiCDC: [`ticdc.rules.yml`](https://github.com/pingcap/tiflow/blob/release-8.5/metrics/alertmanager/ticdc.rules.yml) -- TiDB Lightning： [`lightning.rules.yml`](https://github.com/pingcap/tidb/blob/release-8.5/br/metrics/alertmanager/lightning.rules.yml) +- TiDB: [`tidb.rules.yml`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/metrics/alertmanager/tidb.rules.yml) +- PD: [`pd.rules.yml`](https://github.com/tikv/pd/blob/release-8.5/metrics/alertmanager/pd.rules.yml) +- TiKV: [`tikv.rules.yml`](https://github.com/tikv/tikv/blob/release-8.5/metrics/alertmanager/tikv.rules.yml) +- TiFlash: [`tiflash.rules.yml`](https://github.com/pingcap/tiflash/blob/release-8.5/metrics/alertmanager/tiflash.rules.yml) +- TiCDC: [`ticdc.rules.yml`](https://github.com/pingcap/tiflow/blob/release-8.5/metrics/alertmanager/ticdc.rules.yml) +- TiDB Lightning： [`lightning.rules.yml`](https://github.com/pingcap/tidb/blob/release-8.5/br/metrics/alertmanager/lightning.rules.yml) ```ini rule_files: @@ -198,50 +198,50 @@ Grafana サービスを開始します。 ### ステップ1: Prometheusデータソースを追加する {#step-1-add-a-prometheus-data-source} -1. Grafana Web インターフェースにログインします。 +1. Grafana Web インターフェースにログインします。 - - デフォルトアドレス: [http://localhost:3000](http://localhost:3000) + - デフォルトアドレス: [http://localhost:3000](http://localhost:3000) - - デフォルトアカウント: admin + - デフォルトアカウント: admin - - デフォルトのパスワード: admin + - デフォルトのパスワード: admin > **Note:** > > **Change Password**手順では、 **Skip**を選択できます。 -2. Grafana サイドバー メニューで、**コンフィグレーション**内の**データ ソース**をクリックします。 +2. Grafana サイドバー メニューで、**コンフィグレーション**内の**データ ソース**をクリックします。 -3. **データ ソースの追加を**クリックします。 +3. **データ ソースの追加を**クリックします。 -4. データ ソース情報を指定します。 +4. データ ソース情報を指定します。 - - データ ソースの**名前**を指定します。 - - **タイプ**には**Prometheus**を選択します。 - - **URL**には、Prometheus アドレスを指定します。 - - 必要に応じて他のフィールドを指定します。 + - データ ソースの**名前**を指定します。 + - **タイプ**には**Prometheus**を選択します。 + - **URL**には、Prometheus アドレスを指定します。 + - 必要に応じて他のフィールドを指定します。 -5. 新しいデータ ソースを保存するには、 **[追加]**をクリックします。 +5. 新しいデータ ソースを保存するには、 **[追加]**をクリックします。 ### ステップ2: Grafanaダッシュボードをインポートする {#step-2-import-a-grafana-dashboard} PDサーバー、TiKVサーバー、および TiDBサーバーの Grafana ダッシュボードをインポートするには、それぞれ次の手順を実行します。 -1. Grafana ロゴをクリックしてサイドバー メニューを開きます。 +1. Grafana ロゴをクリックしてサイドバー メニューを開きます。 -2. サイドバー メニューで、 **[ダッシュボード]** -> **[インポート]**をクリックして、 **[ダッシュボードのインポート]**ウィンドウを開きます。 +2. サイドバー メニューで、 **[ダッシュボード]** -> **[インポート]**をクリックして、 **[ダッシュボードのインポート]**ウィンドウを開きます。 -3. **Upload .json File**をクリックして JSON ファイルをアップロードします ( [pingcap/tidb](https://github.com/pingcap/tidb/tree/release-8.5/pkg/metrics/grafana) [tikv/tikv](https://github.com/tikv/tikv/tree/release-8.5/metrics/grafana)、および[tikv/pd](https://github.com/tikv/pd/tree/release-8.5/metrics/grafana)から TiDB Grafana 構成ファイルをダウンロードします)。 +3. **Upload .json File**をクリックして JSON ファイルをアップロードします ( [pingcap/tidb](https://github.com/pingcap/tidb/tree/release-8.5/pkg/metrics/grafana) [tikv/tikv](https://github.com/tikv/tikv/tree/release-8.5/metrics/grafana)、および[tikv/pd](https://github.com/tikv/pd/tree/release-8.5/metrics/grafana)から TiDB Grafana 構成ファイルをダウンロードします)。 > **Note:** > > TiKV、PD、および TiDB Dashboardの場合、対応する JSON ファイルは`tikv_summary.json` 、 `tikv_details.json` 、 `tikv_trouble_shooting.json` 、 `pd.json` 、 `tidb.json` 、および`tidb_summary.json`です。 -4. **[ロード]**をクリックします。 +4. **[ロード]**をクリックします。 -5. Prometheus データ ソースを選択します。 +5. Prometheus データ ソースを選択します。 -6. **Import**をクリックします。Prometheusダッシュボードがインポートされます。 +6. **Import**をクリックします。Prometheusダッシュボードがインポートされます。 ## コンポーネントメトリックを表示する {#view-component-metrics} @@ -251,27 +251,27 @@ PDサーバー、TiKVサーバー、および TiDBサーバーの Grafana ダッ クラスター コンポーネントの次のメトリックを取得できます。 -- **TiDBサーバー:** +- **TiDBサーバー:** - - レイテンシーとスループットを監視するためのクエリ処理時間 - - DDLプロセス監視 - - TiKVクライアント関連の監視 - - PDクライアント関連の監視 + - レイテンシーとスループットを監視するためのクエリ処理時間 + - DDLプロセス監視 + - TiKVクライアント関連の監視 + - PDクライアント関連の監視 -- **PDサーバー:** +- **PDサーバー:** - - コマンドが実行される合計回数 - - 特定のコマンドが失敗した合計回数 - - コマンドが成功するまでの期間 - - コマンドが失敗する期間 - - コマンドが終了して結果を返すまでの時間 + - コマンドが実行される合計回数 + - 特定のコマンドが失敗した合計回数 + - コマンドが成功するまでの期間 + - コマンドが失敗する期間 + - コマンドが終了して結果を返すまでの時間 -- **TiKVサーバー:** +- **TiKVサーバー:** - - ガベージコレクション（GC）監視 - - TiKVコマンドが実行される合計回数 - - スケジューラがコマンドを実行する期間 - - Raftの提案コマンドの総回数 - - Raftがコマンドを実行する期間 - - Raftコマンドが失敗した合計回数 - - Raftが準備完了状態を処理する合計回数 + - ガベージコレクション（GC）監視 + - TiKVコマンドが実行される合計回数 + - スケジューラがコマンドを実行する期間 + - Raftの提案コマンドの総回数 + - Raftがコマンドを実行する期間 + - Raftコマンドが失敗した合計回数 + - Raftが準備完了状態を処理する合計回数 diff --git a/derive-topn-from-window.md b/derive-topn-from-window.md index be98f65659b1f..4befd20f36480 100644 --- a/derive-topn-from-window.md +++ b/derive-topn-from-window.md @@ -25,13 +25,13 @@ WITH t_topN AS (SELECT a FROM t1 ORDER BY a LIMIT 3) SELECT * FROM (SELECT ROW_N この機能を有効にした後、次のいずれかの操作を実行して無効にすることができます。 -- セッション変数[`tidb_opt_derive_topn`](/system-variables.md#tidb_opt_derive_topn-new-in-v700)を`OFF`に設定します。 -- [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md)に記載されている手順に従います。 +- セッション変数[`tidb_opt_derive_topn`](/system-variables.md#tidb_opt_derive_topn-new-in-v700)を`OFF`に設定します。 +- [最適化ルールと式プッシュダウンのブロックリスト](/blocklist-control-plan.md)に記載されている手順に従います。 ## 制限事項 {#limitations} -- SQL 書き換えでは`ROW_NUMBER()`ウィンドウ関数のみがサポートされます。 -- TiDB は、 `ROW_NUMBER()`の結果をフィルタリングし、フィルタ条件が`<`または`<=`の場合にのみ SQL を書き換えることができます。 +- SQL 書き換えでは`ROW_NUMBER()`ウィンドウ関数のみがサポートされます。 +- TiDB は、 `ROW_NUMBER()`の結果をフィルタリングし、フィルタ条件が`<`または`<=`の場合にのみ SQL を書き換えることができます。 ## 使用例 {#usage-examples} diff --git a/develop/_index.md b/develop/_index.md index 8f0b423f3d9e2..32545d559063e 100644 --- a/develop/_index.md +++ b/develop/_index.md @@ -176,6 +176,6 @@ JetBrains の DataGrip を使用して TiDB データベースに接続し、管 TiDB を使用した開発に関するその他のトピックを学習します。 -- [TiDB データベース開発リファレンス](/develop/dev-guide-schema-design-overview.md)に従って、データとスキーマを設計、操作、最適化、およびトラブルシューティングします。 -- 無料のオンラインコース[TiDBの紹介](https://eng.edu.pingcap.com/catalog/info/id:203/?utm_source=docs-dev-guide)を受講してください。 -- TiDB Cloudで人気の[サービス統合](/tidb-cloud/integrate-tidbcloud-with-airbyte.md)探索します。 +- [TiDB データベース開発リファレンス](/develop/dev-guide-schema-design-overview.md)に従って、データとスキーマを設計、操作、最適化、およびトラブルシューティングします。 +- 無料のオンラインコース[TiDBの紹介](https://eng.edu.pingcap.com/catalog/info/id:203/?utm_source=docs-dev-guide)を受講してください。 +- TiDB Cloudで人気の[サービス統合](/tidb-cloud/integrate-tidbcloud-with-airbyte.md)探索します。 diff --git a/develop/dev-guide-aws-appflow-integration.md b/develop/dev-guide-aws-appflow-integration.md index cee35702f1c75..4b57ad4348536 100644 --- a/develop/dev-guide-aws-appflow-integration.md +++ b/develop/dev-guide-aws-appflow-integration.md @@ -14,28 +14,28 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、 [TiDB Clou ## 前提条件 {#prerequisites} -- [Git](https://git-scm.com/) +- [Git](https://git-scm.com/) -- [JDK](https://openjdk.org/install/) 11以降 +- [JDK](https://openjdk.org/install/) 11以降 -- [Maven](https://maven.apache.org/install.html)3.8以上 +- [Maven](https://maven.apache.org/install.html)3.8以上 -- [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)バージョン 2 +- [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)バージョン 2 -- [AWSサーバーレスアプリケーションモデルコマンドラインインターフェイス（AWS SAM CLI）](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html) 1.58.0以降 +- [AWSサーバーレスアプリケーションモデルコマンドラインインターフェイス（AWS SAM CLI）](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html) 1.58.0以降 -- 次の要件を持つ AWS [IDおよびアクセス管理（IAM）ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html): +- 次の要件を持つ AWS [IDおよびアクセス管理（IAM）ユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html): - - ユーザーは[アクセスキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)を使用して AWS にアクセスできます。 - - ユーザーには以下の権限が付与されています。 + - ユーザーは[アクセスキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)を使用して AWS にアクセスできます。 + - ユーザーには以下の権限が付与されています。 - - `AWSCertificateManagerFullAccess` : [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/)読み書きに使用されます。 - - `AWSCloudFormationFullAccess` : SAM CLI は[AWS CloudFormation](https://aws.amazon.com/cloudformation/)を使用して AWS リソースを宣言します。 - - `AmazonS3FullAccess` : AWS CloudFormation は[Amazon S3](https://aws.amazon.com/s3/?nc2=h_ql_prod_fs_s3)を使用して公開します。 - - `AWSLambda_FullAccess` : 現在、Amazon AppFlow 用の新しいコネクタを実装する方法は[AWS Lambda](https://aws.amazon.com/lambda/?nc2=h_ql_prod_fs_lbd)のみです。 - - `IAMFullAccess` : SAM CLI はコネクタ用に`ConnectorFunctionRole`を作成する必要があります。 + - `AWSCertificateManagerFullAccess` : [AWS Secrets Manager](https://aws.amazon.com/secrets-manager/)読み書きに使用されます。 + - `AWSCloudFormationFullAccess` : SAM CLI は[AWS CloudFormation](https://aws.amazon.com/cloudformation/)を使用して AWS リソースを宣言します。 + - `AmazonS3FullAccess` : AWS CloudFormation は[Amazon S3](https://aws.amazon.com/s3/?nc2=h_ql_prod_fs_s3)を使用して公開します。 + - `AWSLambda_FullAccess` : 現在、Amazon AppFlow 用の新しいコネクタを実装する方法は[AWS Lambda](https://aws.amazon.com/lambda/?nc2=h_ql_prod_fs_lbd)のみです。 + - `IAMFullAccess` : SAM CLI はコネクタ用に`ConnectorFunctionRole`を作成する必要があります。 -- [Salesforce](https://developer.salesforce.com)アカウント。 +- [Salesforce](https://developer.salesforce.com)アカウント。 ## ステップ1. TiDBコネクタを登録する {#step-1-register-a-tidb-connector} @@ -49,20 +49,20 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration ### Lambda関数を構築してアップロードする {#build-and-upload-a-lambda} -1. パッケージを作成する： +1. パッケージを作成する： ```bash cd tidb-appflow-integration mvn clean package ``` -2. （オプション）AWSアクセスキーIDとシークレットアクセスキーを設定していない場合は、設定してください。 +2. （オプション）AWSアクセスキーIDとシークレットアクセスキーを設定していない場合は、設定してください。 ```bash aws configure ``` -3. JARパッケージをLambda関数としてアップロードしてください。 +3. JARパッケージをLambda関数としてアップロードしてください。 ```bash sam deploy --guided @@ -70,10 +70,10 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration > **Note:** > - > - `--guided`オプションでは、プロンプトが表示され、デプロイの手順を案内します。入力内容は構成ファイルに保存され、デフォルトでは`samconfig.toml`というファイルになります。 - > - `stack_name`デプロイする AWS Lambda の名前を指定します。 - > - このガイドでは、TiDB Cloud Starterのクラウド プロバイダーとして AWS を使用しています。ソースまたは宛先として Amazon S3 を使用するには、AWS Lambda の`region`を Amazon S3 と同じに設定する必要があります。 - > - 既に`sam deploy --guided`を実行したことがある場合は、代わりに`sam deploy`を実行するだけで、SAM CLI は設定ファイル`samconfig.toml`を使用して操作を簡素化します。 + > - `--guided`オプションでは、プロンプトが表示され、デプロイの手順を案内します。入力内容は構成ファイルに保存され、デフォルトでは`samconfig.toml`というファイルになります。 + > - `stack_name`デプロイする AWS Lambda の名前を指定します。 + > - このガイドでは、TiDB Cloud Starterのクラウド プロバイダーとして AWS を使用しています。ソースまたは宛先として Amazon S3 を使用するには、AWS Lambda の`region`を Amazon S3 と同じに設定する必要があります。 + > - 既に`sam deploy --guided`を実行したことがある場合は、代わりに`sam deploy`を実行するだけで、SAM CLI は設定ファイル`samconfig.toml`を使用して操作を簡素化します。 以下のような出力が表示された場合、このLambda関数は正常にデプロイされています。 @@ -81,21 +81,21 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration Successfully created/updated stack - in ``` -4. [AWS Lambdaコンソール](https://console.aws.amazon.com/lambda/home)にアクセスすると、先ほどアップロードしたLambda関数が表示されます。ウィンドウの右上隅で正しいリージョンを選択する必要があることに注意してください。 +4. [AWS Lambdaコンソール](https://console.aws.amazon.com/lambda/home)にアクセスすると、先ほどアップロードしたLambda関数が表示されます。ウィンドウの右上隅で正しいリージョンを選択する必要があることに注意してください。 ![lambda dashboard](/media/develop/aws-appflow-step-lambda-dashboard.png) ### Lambdaを使用してコネクタを登録します {#use-lambda-to-register-a-connector} -1. [AWS マネジメントコンソール](https://console.aws.amazon.com)コンソールで、 [Amazon AppFlow > コネクタ](https://console.aws.amazon.com/appflow/home#/gallery)クリックし、 **Register a new connector**をクリックします。 +1. [AWS マネジメントコンソール](https://console.aws.amazon.com)コンソールで、 [Amazon AppFlow > コネクタ](https://console.aws.amazon.com/appflow/home#/gallery)クリックし、 **Register a new connector**をクリックします。 ![register connector](/media/develop/aws-appflow-step-register-connector.png) -2. **Register a new connector**ダイアログで、アップロードしたLambda関数を選択し、コネクタ名を使用してコネクタラベルを指定します。 +2. **Register a new connector**ダイアログで、アップロードしたLambda関数を選択し、コネクタ名を使用してコネクタラベルを指定します。 ![register connector dialog](/media/develop/aws-appflow-step-register-connector-dialog.png) -3. **Register**をクリックします。すると、TiDBコネクタが正常に登録されます。 +3. **Register**をクリックします。すると、TiDBコネクタが正常に登録されます。 ## ステップ2. フローを作成する {#step-2-create-a-flow} @@ -113,7 +113,7 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration **ソースの詳細**と**宛先の詳細**を選択してください。TiDBコネクタはどちらにも使用できます。 -1. ソース名を選択してください。このドキュメントでは、例として**Salesforceを**ソースとして使用します。 +1. ソース名を選択してください。このドキュメントでは、例として**Salesforceを**ソースとして使用します。 ![salesforce source](/media/develop/aws-appflow-step-salesforce-source.png) @@ -121,13 +121,13 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration ![salesforce data](/media/develop/aws-appflow-step-salesforce-data.png) -2. **Connect**をクリックしてください。 +2. **Connect**をクリックしてください。 - 1. **Connect to Salesforce**ダイアログで、この接続の名前を指定し、 **Continue**をクリックします。 + 1. **Connect to Salesforce**ダイアログで、この接続の名前を指定し、 **Continue**をクリックします。 ![connect to salesforce](/media/develop/aws-appflow-step-connect-to-salesforce.png) - 2. 「許可」をクリックして、AWSがSalesforceデータを読み取ることを**許可する**ことを確認してください。 + 2. 「許可」をクリックして、AWSがSalesforceデータを読み取ることを**許可する**ことを確認してください。 ![allow salesforce](/media/develop/aws-appflow-step-allow-salesforce.png) @@ -135,11 +135,11 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration > > 会社がすでに Salesforce の Professional Edition を使用している場合、REST API はデフォルトでは有効になっていません。 REST API を使用するには、新しい Developer Edition の登録が必要になる場合があります。詳細については、 [Salesforceフォーラムトピック](https://developer.salesforce.com/forums/?id=906F0000000D9Y2IAK)を参照してください。 -3. **Destination details**エリアで、接続先として**TiDB-Connector**を選択します。 **Connect**ボタンが表示されます。 +3. **Destination details**エリアで、接続先として**TiDB-Connector**を選択します。 **Connect**ボタンが表示されます。 ![tidb dest](/media/develop/aws-appflow-step-tidb-dest.png) -4. **Connect**をクリックする前に、Salesforce **Account**オブジェクト用に TiDB に`sf_account`テーブルを作成する必要があります。このテーブルスキーマは[Amazon AppFlow のチュートリアル](https://docs.aws.amazon.com/appflow/latest/userguide/flow-tutorial-set-up-source.html)にあるサンプルデータとは異なることに注意してください。 +4. **Connect**をクリックする前に、Salesforce **Account**オブジェクト用に TiDB に`sf_account`テーブルを作成する必要があります。このテーブルスキーマは[Amazon AppFlow のチュートリアル](https://docs.aws.amazon.com/appflow/latest/userguide/flow-tutorial-set-up-source.html)にあるサンプルデータとは異なることに注意してください。 ```sql CREATE TABLE `sf_account` ( @@ -153,13 +153,13 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration ); ``` -5. `sf_account`テーブルが作成されたら、 **[接続]**をクリックします。接続ダイアログが表示されます。 +5. `sf_account`テーブルが作成されたら、 **[接続]**をクリックします。接続ダイアログが表示されます。 -6. **TiDBコネクタへの接続**ダイアログで、 TiDB Cloud Starterインスタンスの接続プロパティを入力します。TiDB Cloud Starterの場合、 **TLS**オプションを`Yes`に設定する必要があります。これにより、TiDBコネクタがTLS接続を使用できるようになります。次に、 **[接続]**をクリックします。 +6. **TiDBコネクタへの接続**ダイアログで、 TiDB Cloud Starterインスタンスの接続プロパティを入力します。TiDB Cloud Starterの場合、 **TLS**オプションを`Yes`に設定する必要があります。これにより、TiDBコネクタがTLS接続を使用できるようになります。次に、 **[接続]**をクリックします。 ![tidb connection message](/media/develop/aws-appflow-step-tidb-connection-message.png) -7. これで、接続時に指定したデータベース内のすべてのテーブルを取得できます。ドロップダウンリストから**sf_account**テーブルを選択してください。 +7. これで、接続時に指定したデータベース内のすべてのテーブルを取得できます。ドロップダウンリストから**sf_account**テーブルを選択してください。 ![database](/media/develop/aws-appflow-step-database.png) @@ -167,7 +167,7 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration ![complete flow](/media/develop/aws-appflow-step-complete-flow.png) -8. **Error handling**領域で、 **Stop the current flow run**を選択します。**Flow trigger**領域で、 **Run on demand**トリガータイプを選択します。これは、フローを手動で実行する必要があることを意味します。次に、 **Next**をクリックします。 +8. **Error handling**領域で、 **Stop the current flow run**を選択します。**Flow trigger**領域で、 **Run on demand**トリガータイプを選択します。これは、フローを手動で実行する必要があることを意味します。次に、 **Next**をクリックします。 ![complete step1](/media/develop/aws-appflow-step-complete-step1.png) @@ -175,7 +175,7 @@ git clone https://github.com/pingcap-inc/tidb-appflow-integration Salesforce の**Account**オブジェクトのフィールドを TiDB の`sf_account`テーブルにマッピングし、 **[次へ]**をクリックします。 -- `sf_account`テーブルは TiDB に新しく作成されましたが、空です。 +- `sf_account`テーブルは TiDB に新しく作成されましたが、空です。 ```sql test> SELECT * FROM sf_account; @@ -185,18 +185,18 @@ Salesforce の**Account**オブジェクトのフィールドを TiDB の`sf_acc +----+------+------+---------------+--------+----------+ ``` -- マッピングルールを設定するには、左側でソースフィールド名を選択し、右側で宛先フィールド名を選択します。次に、 **Map fields**をクリックすると、ルールが設定されます。 +- マッピングルールを設定するには、左側でソースフィールド名を選択し、右側で宛先フィールド名を選択します。次に、 **Map fields**をクリックすると、ルールが設定されます。 ![add mapping rule](/media/develop/aws-appflow-step-add-mapping-rule.png) -- このドキュメントでは、以下のマッピングルール（ソースフィールド名→宛先フィールド名）が必要です。 +- このドキュメントでは、以下のマッピングルール（ソースフィールド名→宛先フィールド名）が必要です。 - - アカウントID -> id - - アカウント名 -> 名前 - - アカウントタイプ -> タイプ - - 請求先州/都道府県 -> billing_state - - アカウント評価 -> 評価 - - 産業 -> 産業 + - アカウントID -> id + - アカウント名 -> 名前 + - アカウントタイプ -> タイプ + - 請求先州/都道府県 -> billing_state + - アカウント評価 -> 評価 + - 産業 -> 産業 ![mapping a rule](/media/develop/aws-appflow-step-mapping-a-rule.png) @@ -249,13 +249,13 @@ test> SELECT * FROM sf_account; ## 注目すべきこと {#noteworthy-things} -- 何か問題が発生した場合は、AWS マネジメントコンソールの[CloudWatch](https://console.aws.amazon.com/cloudwatch/home)ページにアクセスしてログを取得できます。 -- このドキュメントの手順は、 [Amazon AppFlow Custom Connector SDK を使用したカスタムコネクタの構築](https://aws.amazon.com/blogs/compute/building-custom-connectors-using-the-amazon-appflow-custom-connector-sdk/)に基づいています。 -- [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)は本番環境では**ありません**。 -- 長くなりすぎないように、このドキュメントの例では`Insert`戦略のみを示していますが、 `Update`および`Upsert`戦略もテスト済みで使用できます。 +- 何か問題が発生した場合は、AWS マネジメントコンソールの[CloudWatch](https://console.aws.amazon.com/cloudwatch/home)ページにアクセスしてログを取得できます。 +- このドキュメントの手順は、 [Amazon AppFlow Custom Connector SDK を使用したカスタムコネクタの構築](https://aws.amazon.com/blogs/compute/building-custom-connectors-using-the-amazon-appflow-custom-connector-sdk/)に基づいています。 +- [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)は本番環境では**ありません**。 +- 長くなりすぎないように、このドキュメントの例では`Insert`戦略のみを示していますが、 `Update`および`Upsert`戦略もテスト済みで使用できます。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-bookshop-schema-design.md b/develop/dev-guide-bookshop-schema-design.md index 30cd07459c822..387fe855cd3c7 100644 --- a/develop/dev-guide-bookshop-schema-design.md +++ b/develop/dev-guide-bookshop-schema-design.md @@ -14,8 +14,8 @@ Bookshopは、さまざまなジャンルの本を購入したり、読んだ本 Bookshopアプリケーションのテーブル構造とデータをインポートするには、以下のインポート方法のいずれかを選択してください。 -- [TiDB Self-Managed: `tiup demo`経由](#tidb-self-managed-via-tiup-demo)。 -- [TiDB Cloud：インポート機能経由](#tidb-cloud-via-the-import-feature)。 +- [TiDB Self-Managed: `tiup demo`経由](#tidb-self-managed-via-tiup-demo)。 +- [TiDB Cloud：インポート機能経由](#tidb-cloud-via-the-import-feature)。 ### TiDB Self-Managed: `tiup demo`経由 {#tidb-self-managed-via-tiup-demo} @@ -59,11 +59,11 @@ tiup demo bookshop prepare -U -H -P 4000 -p 例えば、以下のコマンドを実行すると、次のものが生成されます。 -- `--users`パラメータを介して取得した 200,000 行のユーザー情報 -- `--books`パラメータを介して50万行の書籍情報を取得 -- `--authors`パラメータによる 100,000 行の著者情報 -- `--ratings`パラメータによる 1,000,000 行の評価レコード -- `--orders`パラメータを介して1,000,000行の注文レコードを取得 +- `--users`パラメータを介して取得した 200,000 行のユーザー情報 +- `--books`パラメータを介して50万行の書籍情報を取得 +- `--authors`パラメータによる 100,000 行の著者情報 +- `--ratings`パラメータによる 1,000,000 行の評価レコード +- `--orders`パラメータを介して1,000,000行の注文レコードを取得 ```shell tiup demo bookshop prepare --users=200000 --books=500000 --authors=100000 --ratings=1000000 --orders=1000000 --drop-tables @@ -73,36 +73,36 @@ tiup demo bookshop prepare --users=200000 --books=500000 --authors=100000 --rati ### TiDB Cloud：インポート機能経由 {#tidb-cloud-via-the-import-feature} -1. 対象のTiDB Cloudリソースの**Import**ページを開きます。 +1. 対象のTiDB Cloudリソースの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象リソースの名前をクリックして概要ページに移動し、左側のナビゲーションペインにある**Import**をクリックします。 + 2. 対象リソースの名前をクリックして概要ページに移動し、左側のナビゲーションペインにある**Import**をクリックします。 -2. **Import data from Cloud Storage**を選択し、次に**Amazon S3**をクリックします。 +2. **Import data from Cloud Storage**を選択し、次に**Amazon S3**をクリックします。 -3. **Import Data from Amazon S3**ページで、以下のソースデータ情報を設定してください。 +3. **Import Data from Amazon S3**ページで、以下のソースデータ情報を設定してください。 - - **Import File Count**： TiDB Cloud Starterの場合は、 **Multiple files**を選択してください。このフィールドはTiDB Cloud Dedicatedでは利用できません。 - - **Included Schema Files**：**Yes**を選択してください。 - - **Data Format**: SELECT **SQL** 。 - - **Folder URI** : `s3://developer.pingcap.com/bookshop/`を入力してください。 - - **Bucket Access**: **AWS Role ARN**を選択します。 - - **Role ARN** : `arn:aws:iam::494090988690:role/s3-tidb-cloud-developer-access`を入力してください。 + - **Import File Count**： TiDB Cloud Starterの場合は、 **Multiple files**を選択してください。このフィールドはTiDB Cloud Dedicatedでは利用できません。 + - **Included Schema Files**：**Yes**を選択してください。 + - **Data Format**: SELECT **SQL** 。 + - **Folder URI** : `s3://developer.pingcap.com/bookshop/`を入力してください。 + - **Bucket Access**: **AWS Role ARN**を選択します。 + - **Role ARN** : `arn:aws:iam::494090988690:role/s3-tidb-cloud-developer-access`を入力してください。 この例では、以下のデータが事前に生成されます。 - - 20万行のユーザー情報 - - 50万行の書籍情報 - - 著者情報10万行 - - 1,000,000行の評価記録 - - 1,000,000行の注文記録 + - 20万行のユーザー情報 + - 50万行の書籍情報 + - 著者情報10万行 + - 1,000,000行の評価記録 + - 1,000,000行の注文記録 -4. **Connect** ＞ **Start Import**をクリックしてインポート処理を開始し、 TiDB Cloudインポート完了をお待ちください。 +4. **Connect** ＞ **Start Import**をクリックしてインポート処理を開始し、 TiDB Cloudインポート完了をお待ちください。 データをTiDB Cloudにインポートまたは移行する方法の詳細については、 [TiDB Cloud移行の概要](https://docs.pingcap.com/tidbcloud/tidb-cloud-migration-overview)を参照してください。 @@ -277,6 +277,6 @@ CREATE TABLE `bookshop`.`orders` ( ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-build-cluster-in-cloud.md b/develop/dev-guide-build-cluster-in-cloud.md index 34ad54c79ea03..c6c19ab96f778 100644 --- a/develop/dev-guide-build-cluster-in-cloud.md +++ b/develop/dev-guide-build-cluster-in-cloud.md @@ -14,23 +14,23 @@ aliases: ['/ja/tidb/stable/dev-guide-build-cluster-in-cloud/','/ja/tidb/dev/dev- ## ステップ1. TiDB Cloud Starterインスタンスを作成します {#step-1-create-a-starter-instance} {#step-1-create-a-starter-instance} -1. TiDB Cloudアカウントをお持ちでない場合は、[ここ](https://tidbcloud.com/free-trial)をクリックしてアカウントを作成してください。 +1. TiDB Cloudアカウントをお持ちでない場合は、[ここ](https://tidbcloud.com/free-trial)をクリックしてアカウントを作成してください。 -2. TiDB Cloudアカウントに[ログイン](https://tidbcloud.com/)。 +2. TiDB Cloudアカウントに[ログイン](https://tidbcloud.com/)。 -3. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、 **Create Resource**をクリックします。 +3. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、 **Create Resource**をクリックします。 -4. **Create Resource**ページでは、デフォルトで**Starter**が選択されています。TiDB Cloud Starterインスタンスの名前を入力し、作成先のクラウドプロバイダーとリージョンを選択してください。 +4. **Create Resource**ページでは、デフォルトで**Starter**が選択されています。TiDB Cloud Starterインスタンスの名前を入力し、作成先のクラウドプロバイダーとリージョンを選択してください。 -5. **Create**をクリックして、 TiDB Cloud Starterインスタンスを作成します。 +5. **Create**をクリックして、 TiDB Cloud Starterインスタンスを作成します。 TiDB Cloud Starterインスタンスは、約30秒で作成されます。 -6. TiDB Cloud Starterインスタンスが作成されたら、インスタンス名をクリックして概要ページに移動し、右上隅の**Connect**をクリックします。接続ダイアログが表示されます。 +6. TiDB Cloud Starterインスタンスが作成されたら、インスタンス名をクリックして概要ページに移動し、右上隅の**Connect**をクリックします。接続ダイアログが表示されます。 -7. ダイアログで、希望する接続方法とオペレーティングシステムを選択すると、対応する接続​​文字列が表示されます。このドキュメントでは、例としてMySQLクライアントを使用します。 +7. ダイアログで、希望する接続方法とオペレーティングシステムを選択すると、対応する接続​​文字列が表示されます。このドキュメントでは、例としてMySQLクライアントを使用します。 -8. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。生成されたパスワードは二度と表示されないため、安全な場所に保存してください。ルートパスワードを設定しないと、 TiDB Cloud Starterインスタンスに接続できません。 +8. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。生成されたパスワードは二度と表示されないため、安全な場所に保存してください。ルートパスワードを設定しないと、 TiDB Cloud Starterインスタンスに接続できません。 > **Note:** > @@ -38,7 +38,7 @@ aliases: ['/ja/tidb/stable/dev-guide-build-cluster-in-cloud/','/ja/tidb/dev/dev- ## ステップ2. TiDB Cloud Starterインスタンスに接続します {#step-2-connect-to-a-starter-instance} {#step-2-connect-to-a-starter-instance} -1. MySQLクライアントがインストールされていない場合は、お使いのオペレーティングシステムを選択し、以下の手順に従ってインストールしてください。 +1. MySQLクライアントがインストールされていない場合は、お使いのオペレーティングシステムを選択し、以下の手順に従ってインストールしてください。 @@ -109,7 +109,7 @@ mysql Ver 15.1 Distrib 5.5.68-MariaDB, for Linux (x86_64) using readline 5.1 -2. [ステップ1](#step-1-create-a-starter-instance)で取得した接続文字列を実行します。 +2. [ステップ1](#step-1-create-a-starter-instance)で取得した接続文字列を実行します。 ```shell mysql --connect-timeout 15 -u '.root' -h -P 4000 -D test --ssl-mode=VERIFY_IDENTITY --ssl-ca=/etc/ssl/cert.pem -p @@ -117,10 +117,10 @@ mysql Ver 15.1 Distrib 5.5.68-MariaDB, for Linux (x86_64) using readline 5.1 > **Note:** > -> - TiDB Cloud Starterインスタンスに接続するときは、 [TLS接続を使用する](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters)必要があります。 -> - TiDB Cloud Starterインスタンスへの接続時に問題が発生した場合は、 [TiDB Cloud Starterインスタンスへのセキュリティ接続](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters)で詳細を確認してください。 +> - TiDB Cloud Starterインスタンスに接続するときは、 [TLS接続を使用する](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters)必要があります。 +> - TiDB Cloud Starterインスタンスへの接続時に問題が発生した場合は、 [TiDB Cloud Starterインスタンスへのセキュリティ接続](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters)で詳細を確認してください。 -3. ログインするにはパスワードを入力してください。 +3. ログインするにはパスワードを入力してください。 ## ステップ3．SQLステートメントを実行する {#step-3-execute-a-sql-statement} @@ -144,6 +144,6 @@ SELECT 'Hello TiDB Cloud!'; ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-choose-driver-or-orm.md b/develop/dev-guide-choose-driver-or-orm.md index bcfd9d7a39035..ce53b50efe7a8 100644 --- a/develop/dev-guide-choose-driver-or-orm.md +++ b/develop/dev-guide-choose-driver-or-orm.md @@ -10,8 +10,8 @@ aliases: ['/ja/tidb/stable/dev-guide-choose-driver-or-orm/','/ja/tidbcloud/dev-g > > TiDB は、ドライバーと ORM に対して次の 2 つのサポート レベルを提供します。 > -> - **完全**: TiDB がツールのほとんどの機能と互換性があり、最新バージョンとの互換性を維持していることを示します。PingCAP は、最新バージョン[TiDB でサポートされているサードパーティ ツール](/develop/dev-guide-third-party-support.md)との互換性テストを定期的に実施します。 -> - **互換**：対応するサードパーティ製ツールがMySQLに適合しており、TiDBはMySQLプロトコルと高い互換性があるため、TiDBはツールのほとんどの機能を使用できることを示します。ただし、PingCAPはツールのすべての機能について完全なテストを完了していないため、予期しない動作が発生する可能性があります。 +> - **完全**: TiDB がツールのほとんどの機能と互換性があり、最新バージョンとの互換性を維持していることを示します。PingCAP は、最新バージョン[TiDB でサポートされているサードパーティ ツール](/develop/dev-guide-third-party-support.md)との互換性テストを定期的に実施します。 +> - **互換**：対応するサードパーティ製ツールがMySQLに適合しており、TiDBはMySQLプロトコルと高い互換性があるため、TiDBはツールのほとんどの機能を使用できることを示します。ただし、PingCAPはツールのすべての機能について完全なテストを完了していないため、予期しない動作が発生する可能性があります。 > > 詳細については[TiDB でサポートされているサードパーティ ツール](/develop/dev-guide-third-party-support.md)を参照してください。 @@ -93,9 +93,9 @@ implementation group: 'org.bouncycastle', name: 'bcpkix-jdk15on', version: '1.67 > **Note:** > -> - 現在、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以降、 [SAVEPOINT](/sql-statements/sql-statement-savepoint.md)をサポートしています。`@Transactional`で`Propagation.NESTED`トランザクション伝播オプションを使用するには、つまり`@Transactional(propagation = Propagation.NESTED)`を設定するには、TiDBがv6.2.0以降であることを確認してください。 +> - TiDBはv6.2.0以降、 [SAVEPOINT](/sql-statements/sql-statement-savepoint.md)をサポートしています。`@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`以降でのみサポートされます。`Hibernate`バージョンが`6.0.0.Beta2`より前の場合は、まずアップグレードしてください。 @@ -305,6 +305,6 @@ peewee を使用して TiDB アプリケーションを構築する例につい ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-connect-to-tidb.md b/develop/dev-guide-connect-to-tidb.md index 08a6b4c1fa407..df5a276fca498 100644 --- a/develop/dev-guide-connect-to-tidb.md +++ b/develop/dev-guide-connect-to-tidb.md @@ -8,22 +8,22 @@ aliases: ['/ja/tidb/stable/dev-guide-connect-to-tidb/','/ja/tidb/dev/dev-guide-c TiDBはMySQLプロトコルとの互換性が非常に高いため、ほとんどのMySQLツール、ドライバ、およびORMを使用して接続できます。 -- SQLを手動で実行する（接続テスト、デバッグ、または簡単な検証のため）には、 [MySQL CLIツール](/develop/dev-guide-mysql-tools.md)から始めます。 +- SQLを手動で実行する（接続テスト、デバッグ、または簡単な検証のため）には、 [MySQL CLIツール](/develop/dev-guide-mysql-tools.md)から始めます。 -- 視覚的なインターフェースを使用して接続するには、以下の一般的なGUIツールのドキュメントを参照してください。 +- 視覚的なインターフェースを使用して接続するには、以下の一般的なGUIツールのドキュメントを参照してください。 - - [JetBrains DataGrip](/develop/dev-guide-gui-datagrip.md) - - [DBeaver](/develop/dev-guide-gui-dbeaver.md) - - [VS Code](/develop/dev-guide-gui-vscode-sqltools.md) - - [MySQL Workchen](/develop/dev-guide-gui-mysql-workbench.md) - - [Navicat](/develop/dev-guide-gui-navicat.md) + - [JetBrains DataGrip](/develop/dev-guide-gui-datagrip.md) + - [DBeaver](/develop/dev-guide-gui-dbeaver.md) + - [VS Code](/develop/dev-guide-gui-vscode-sqltools.md) + - [MySQL Workchen](/develop/dev-guide-gui-mysql-workbench.md) + - [Navicat](/develop/dev-guide-gui-navicat.md) -- TiDB 上でアプリケーションを構築するには、プログラミング言語とフレームワークに基づいて [ドライバーまたはORMを選択してください](/develop/dev-guide-choose-driver-or-orm.md)。 +- TiDB 上でアプリケーションを構築するには、プログラミング言語とフレームワークに基づいて [ドライバーまたはORMを選択してください](/develop/dev-guide-choose-driver-or-orm.md)。 -- エッジ環境から HTTP 経由でTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続するには、 [TiDB Cloud Serverless Driver](/develop/serverless-driver.md)を使用します。TiDB Cloud Serverless Driverはパブリックプレビューであり、 TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにのみ適用可能であることに注意してください。 +- エッジ環境から HTTP 経由でTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続するには、 [TiDB Cloud Serverless Driver](/develop/serverless-driver.md)を使用します。TiDB Cloud Serverless Driverはパブリックプレビューであり、 TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにのみ適用可能であることに注意してください。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index a65fb68cf5a9f..10f36b15a58af 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -12,9 +12,9 @@ aliases: ['/ja/tidb/stable/dev-guide-connection-parameters/','/ja/tidb/dev/dev-g > > この文書では、以下のセクションは[TiDBを使用したJavaアプリケーション開発のベストプラクティス](/develop/java-app-best-practices.md)から抜粋したものです。 > -> - [接続数を設定する](#configure-the-number-of-connections) -> - [プローブ構成](#probe-configuration) -> - [接続パラメータ](#connection-parameters) +> - [接続数を設定する](#configure-the-number-of-connections) +> - [プローブ構成](#probe-configuration) +> - [接続パラメータ](#connection-parameters) ## 接続プール {#connection-pool} @@ -26,8 +26,8 @@ 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)を参照してください。 -- **minimumIdle** ：接続プール内のアイドル接続の最小数。主に、アプリケーションがアイドル状態のときに突発的なリクエストに対応するために、一部の接続を確保するために使用されます。アプリケーションの特性に合わせて設定する必要があります。 +- **maximumPoolSize** : コネクションプール内の最大接続数。この値が大きすぎると、TiDB は不要な接続を維持するためにリソースを消費します。この値が小さすぎると、アプリケーションの接続が遅くなります。したがって、アプリケーションの特性に応じてこの値を構成する必要があります。詳細については、 [プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)を参照してください。 +- **minimumIdle** ：接続プール内のアイドル接続の最小数。主に、アプリケーションがアイドル状態のときに突発的なリクエストに対応するために、一部の接続を確保するために使用されます。アプリケーションの特性に合わせて設定する必要があります。 アプリケーションは、接続の使用が終了したら、その接続を返却する必要があります。接続プールの問題を早期に発見するために、アプリケーションは適切な接続プール監視ツール（ **metricRegistry**など）を使用することをお勧めします。 @@ -40,25 +40,25 @@ TiDBサーバーがシャットダウン、メンテナンスのために再起
-- **`maxLifetime`** ：プール内の接続の最大有効期間。 +- **`maxLifetime`** ：プール内の接続の最大有効期間。
-- **`maxAge`** ：プール内の接続の最大有効期間。 +- **`maxAge`** ：プール内の接続の最大有効期間。
-- **`maxConnectionAge`** ：接続プールにおける接続の最大有効期間。 +- **`maxConnectionAge`** ：接続プールにおける接続の最大有効期間。
-- **`maxConnLifetimeMillis`** ：接続プールにおける接続の最大有効期間。 +- **`maxConnLifetimeMillis`** ：接続プールにおける接続の最大有効期間。
@@ -67,8 +67,8 @@ 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では、デフォルトでは（エラーが報告されない限り）クライアント接続を積極的に閉じることはありません。 +- バージョン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)ようなネットワークプロキシが存在する場合があります。これらのプロキシは通常、特定のアイドル期間（プロキシのアイドル設定によって決定されます）が経過すると、接続を自動的にクリーンアップします。接続プールは、プロキシのアイドル設定を監視するだけでなく、キープアライブのために接続を維持またはプローブする必要もあります。 @@ -82,9 +82,9 @@ The last packet sent successfully to the server was 3600000 milliseconds ago. Th `n`が非常に大きな値 (上記の例の`3600000`など) の場合、この接続は長時間アイドル状態になり、その後プロキシによって閉じられた可能性が高いです。通常の解決策は、プロキシのアイドル設定の値を増やし、接続プールが次のことを実行できるようにすることです。 -- 接続を使用する前に、毎回接続が利用可能かどうかを確認してください。 -- 別のスレッドを使用して、接続が利用可能かどうかを定期的に確認してください。 -- 接続を維持するために、定期的にテストクエリを送信してください。 +- 接続を使用する前に、毎回接続が利用可能かどうかを確認してください。 +- 別のスレッドを使用して、接続が利用可能かどうかを定期的に確認してください。 +- 接続を維持するために、定期的にテストクエリを送信してください。 接続プールの実装によっては、上記の方法のうち1つ以上がサポートされている場合があります。対応する設定については、接続プールのドキュメントを参照してください。 @@ -100,9 +100,9 @@ connections = ((core_count * 2) + effective_spindle_count) 式中の各パラメータの説明は以下のとおりです。 -- **接続数**：取得された接続のサイズ。 -- **core_count** ：CPUコアの数。 -- **effective_spindle_count** ：ハードドライブの数（ [SSD](https://en.wikipedia.org/wiki/Solid-state_drive)ではありません）。回転するハードディスクはそれぞれスピンドルと呼ばれるためです。たとえば、16台のディスクで構成されたRAIDサーバーを使用している場合、 **effective_spindle_count**は16になります。HDD**は**通常、一度に1つのリクエストしか処理できないため、この式は実際にはサーバーが同時に処理できるI/Oリクエストの数を測定しています。 +- **接続数**：取得された接続のサイズ。 +- **core_count** ：CPUコアの数。 +- **effective_spindle_count** ：ハードドライブの数（ [SSD](https://en.wikipedia.org/wiki/Solid-state_drive)ではありません）。回転するハードディスクはそれぞれスピンドルと呼ばれるためです。たとえば、16台のディスクで構成されたRAIDサーバーを使用している場合、 **effective_spindle_count**は16になります。HDD**は**通常、一度に1つのリクエストしか処理できないため、この式は実際にはサーバーが同時に処理できるI/Oリクエストの数を測定しています。 特に、 [式](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing#the-formula)下の次の注記に注意してください。 @@ -118,9 +118,9 @@ connections = ((core_count * 2) + effective_spindle_count) このメモは以下を示しています。 -- **core_countは**、 [ハイパースレッディング](https://en.wikipedia.org/wiki/Hyper-threading)有効にするかどうかに関わらず、物理コアの数です。 -- データが完全にキャッシュされると、 **effective_spindle_count を**`0`に設定する必要があります。キャッシュのヒット率が低下すると、カウントは実際の数値である`HDD`に近づきます。 -- **この計算式が*SSD*にも有効かどうかは検証されておらず、不明である。** +- **core_countは**、 [ハイパースレッディング](https://en.wikipedia.org/wiki/Hyper-threading)有効にするかどうかに関わらず、物理コアの数です。 +- データが完全にキャッシュされると、 **effective_spindle_count を**`0`に設定する必要があります。キャッシュのヒット率が低下すると、カウントは実際の数値である`HDD`に近づきます。 +- **この計算式が*SSD*にも有効かどうかは検証されておらず、不明である。** SSDを使用する場合は、経験に基づき、以下の式を使用することをお勧めします。 @@ -136,15 +136,15 @@ connections = (number of cores * 4) 最適なサイズを選ぶための基本的なルールをいくつかご紹介します。 -- ネットワークまたはストレージのレイテンシーが高い場合は、最大接続数を増やしてレイテンシーによる待ち時間を短縮してください。スレッドがレイテンシーによってブロックされた場合でも、他のスレッドが処理を引き継いで処理を続行できます。 -- サーバー上に複数のサービスがデプロイされており、各サービスがそれぞれ独立した接続プールを持っている場合は、すべての接続プールへの最大接続数の合計を考慮してください。 +- ネットワークまたはストレージのレイテンシーが高い場合は、最大接続数を増やしてレイテンシーによる待ち時間を短縮してください。スレッドがレイテンシーによってブロックされた場合でも、他のスレッドが処理を引き継いで処理を続行できます。 +- サーバー上に複数のサービスがデプロイされており、各サービスがそれぞれ独立した接続プールを持っている場合は、すべての接続プールへの最大接続数の合計を考慮してください。 ## 接続パラメータ {#connection-parameters} Javaアプリケーションは、さまざまなフレームワークでカプセル化されたできます。ほとんどのフレームワークでは、データベースサーバーとのやり取りを行うために、最下層でJDBC APIが呼び出されます。JDBCに関しては、以下の点に重点を置くことをお勧めします。 -- JDBC APIの使用方法の選択 -- API実装者のパラメータ設定 +- JDBC APIの使用方法の選択 +- API実装者のパラメータ設定 ### JDBC API {#jdbc-api} @@ -174,13 +174,13 @@ OLTP（オンライン・トランザクション処理）シナリオでは、 JDBCでは通常、以下の2つの処理方法が使用されます。 -- 最初の方法: [**FetchSizeを**`Integer.MIN_VALUE`に設定します](https://dev.mysql.com/doc/connector-j/en/connector-j-reference-implementation-notes.html#ResultSet)クライアントがキャッシュしないようにします。クライアントは`StreamingResult`を介してネットワーク接続から実行結果を読み取ります。 +- 最初の方法: [**FetchSizeを**`Integer.MIN_VALUE`に設定します](https://dev.mysql.com/doc/connector-j/en/connector-j-reference-implementation-notes.html#ResultSet)クライアントがキャッシュしないようにします。クライアントは`StreamingResult`を介してネットワーク接続から実行結果を読み取ります。 クライアントがストリーミング読み取り方式を使用する場合、クエリを実行するためにステートメントを引き続き使用する前に、読み取りを完了するか、 `resultset`閉じる必要があります。そうしないと、エラー`No statements may be issued when any streaming result sets are open and in use on a given connection. Ensure that you have called .close() on any active streaming result sets before attempting more queries.`が返されます。 クライアントが読み取りを完了するか、 `resultset`閉じる前にクエリでこのようなエラーが発生するのを回避するには、URLに`clobberStreamingResults=true`パラメータを追加できます。そうすると、 `resultset`自動的に閉じられますが、前のストリーミングクエリで読み取られる結果セットは失われます。 -- 2つ目の方法：まず正の整数として[`FetchSize`設定](http://makejavafaster.blogspot.com/2015/06/jdbc-fetch-size-performance.html)設定し、次にJDBC URLで`useCursorFetch = true`設定することで、カーソルフェッチを使用します。 +- 2つ目の方法：まず正の整数として[`FetchSize`設定](http://makejavafaster.blogspot.com/2015/06/jdbc-fetch-size-performance.html)設定し、次にJDBC URLで`useCursorFetch = true`設定することで、カーソルフェッチを使用します。 TiDBは両方の方法をサポートしていますが、実装がよりシンプルで実行効率も優れているため、 `FetchSize`から`Integer.MIN_VALUE`に設定する最初の方法を使用することをお勧めします。 @@ -196,27 +196,27 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 このセクションでは、 `Prepare`に関連するパラメータを紹介します。 -- **useServerPrepStmts** +- **useServerPrepStmts** **useServerPrepStmts は**デフォルトで`false`に設定されています。つまり、Prepare API を使用する場合でも、「prepare」操作はクライアント側でのみ実行されます。サーバーの解析オーバーヘッドを回避するため、同じ SQL ステートメントで Prepare API を複数回使用する場合は、この設定を`true`に設定することをお勧めします。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 - - TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 - - リクエストで`COM_QUERY` `COM_STMT_EXECUTE`または`COM_STMT_PREPARE`に置き換えられている場合、この設定は既に有効になっていることを意味します。 + - TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 + - リクエストで`COM_QUERY` `COM_STMT_EXECUTE`または`COM_STMT_PREPARE`に置き換えられている場合、この設定は既に有効になっていることを意味します。 -- **`cachePrepStmts`** +- **`cachePrepStmts`** `useServerPrepStmts=true`ではサーバーがプリペアドステートメントを実行できますが、デフォルトではクライアントは実行後にプリペアドステートメントを閉じ、再利用しません。つまり、「準備」操作はテキストファイルの実行ほど効率的ではありません。この問題を解決するには、 `useServerPrepStmts=true`設定した後、 `cachePrepStmts=true`設定することをお勧めします。これにより、クライアントはプリペアドステートメントをキャッシュできるようになります。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 - - TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 - - リクエスト内の`COM_STMT_EXECUTE`の数が`COM_STMT_PREPARE`の数よりはるかに多い場合、この設定は既に有効になっていることを意味します。 + - TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 + - リクエスト内の`COM_STMT_EXECUTE`の数が`COM_STMT_PREPARE`の数よりはるかに多い場合、この設定は既に有効になっていることを意味します。 さらに、 `useConfigs=maxPerformance`設定すると、 `cachePrepStmts=true`含む複数のパラメータが同時に設定されます。 -- **prepStmtCacheSqlLimit** +- **prepStmtCacheSqlLimit** `cachePrepStmts`設定が完了したら、 `prepStmtCacheSqlLimit`設定（デフォルト値は`256` ）にも注意してください。この設定は、クライアントにキャッシュされるプリペアドステートメントの最大長を制御します。 @@ -224,17 +224,17 @@ JDBCは通常、JDBC URLパラメータの形式で実装関連の設定を提 次のような場合は、この設定が小さすぎるかどうかを確認する必要があります。 - - TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 - - そして、 `cachePrepStmts=true`設定されているが、 `COM_STMT_PREPARE`は依然として`COM_STMT_EXECUTE`とほぼ等しく、 `COM_STMT_CLOSE`存在することがわかった。 + - TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 + - そして、 `cachePrepStmts=true`設定されているが、 `COM_STMT_PREPARE`は依然として`COM_STMT_EXECUTE`とほぼ等しく、 `COM_STMT_CLOSE`存在することがわかった。 -- **prepStmtCacheSize** +- **prepStmtCacheSize** **prepStmtCacheSize は**、キャッシュされるプリペアドステートメントの数を制御します（デフォルト値は`25`です）。アプリケーションで多くの種類の SQL ステートメントを「準備」する必要があり、プリペアドステートメントを再利用したい場合は、この値を増やすことができます。 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 - - TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 - - リクエスト内の`COM_STMT_EXECUTE`の数が`COM_STMT_PREPARE`の数よりはるかに多い場合、この設定は既に有効になっていることを意味します。 + - TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 + - リクエスト内の`COM_STMT_EXECUTE`の数が`COM_STMT_PREPARE`の数よりはるかに多い場合、この設定は既に有効になっていることを意味します。 #### バッチ関連パラメータ {#batch-related-parameters} @@ -312,6 +312,6 @@ TiDB はタイムアウトを制御するために 2 つの MySQL 互換パラ ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)か[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)についてコミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)か[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)についてコミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-create-database.md b/develop/dev-guide-create-database.md index 95061afc0b624..dfe7952956ddd 100644 --- a/develop/dev-guide-create-database.md +++ b/develop/dev-guide-create-database.md @@ -12,8 +12,8 @@ aliases: ['/ja/tidb/stable/dev-guide-create-database/','/ja/tidb/dev/dev-guide-c データベースを作成する前に、以下の手順を実行してください。 -- [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md)お読みください。 +- [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md)お読みください。 ## データベースとは何か {#what-is-database} @@ -73,10 +73,10 @@ mysql ## データベース作成におけるルール {#rules-in-database-creation} -- データベース[データベース命名規則](/develop/dev-guide-object-naming-guidelines.md)に従って、データベースに意味のある名前を付けます。 -- TiDBには`test`という名前のデフォルトデータベースが付属しています。ただし、必要がない限り、本番環境での使用は推奨されません。 `CREATE DATABASE`ステートメントを使用して独自のデータベースを作成し、SQLセッションで[`USE {databasename};`](/sql-statements/sql-statement-use.md)ステートメントを使用して現在のデータベースを変更できます。 -- `root`ユーザーを使用して、データベース、ロール、ユーザーなどのオブジェクトを作成します。ロールとユーザーには、必要な権限のみを付与してください。 -- ベストプラクティスとして、データベーススキーマの変更を実行する際には、ドライバやORMではなく、 **MySQLコマンドラインクライアント**または**MySQL GUIクライアント**を使用することをお勧めします。 +- データベース[データベース命名規則](/develop/dev-guide-object-naming-guidelines.md)に従って、データベースに意味のある名前を付けます。 +- TiDBには`test`という名前のデフォルトデータベースが付属しています。ただし、必要がない限り、本番環境での使用は推奨されません。 `CREATE DATABASE`ステートメントを使用して独自のデータベースを作成し、SQLセッションで[`USE {databasename};`](/sql-statements/sql-statement-use.md)ステートメントを使用して現在のデータベースを変更できます。 +- `root`ユーザーを使用して、データベース、ロール、ユーザーなどのオブジェクトを作成します。ロールとユーザーには、必要な権限のみを付与してください。 +- ベストプラクティスとして、データベーススキーマの変更を実行する際には、ドライバやORMではなく、 **MySQLコマンドラインクライアント**または**MySQL GUIクライアント**を使用することをお勧めします。 ## 次のステップ {#next-step} @@ -84,6 +84,6 @@ mysql ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-create-secondary-indexes.md b/develop/dev-guide-create-secondary-indexes.md index ab6c02b513f27..e93b6dcfc8a98 100644 --- a/develop/dev-guide-create-secondary-indexes.md +++ b/develop/dev-guide-create-secondary-indexes.md @@ -12,10 +12,10 @@ aliases: ['/ja/tidb/stable/dev-guide-create-secondary-indexes/','/ja/tidb/dev/de セカンダリインデックスを作成する前に、以下の手順を実行してください。 -- [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md)お読みください。 -- [データベースを作成する](/develop/dev-guide-create-database.md)。 -- [テーブルを作成する](/develop/dev-guide-create-table.md)。 +- [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md)お読みください。 +- [データベースを作成する](/develop/dev-guide-create-database.md)。 +- [テーブルを作成する](/develop/dev-guide-create-table.md)。 ## セカンダリインデックスとは何ですか？ {#what-is-secondary-index} @@ -35,9 +35,9 @@ CREATE INDEX {index_name} ON {table_name} ({column_names}); パラメータの説明: -- `{index_name}` : セカンダリ インデックスの名前。 -- `{table_name}` : テーブル名。 -- `{column_names}` : インデックスを作成する列の名前をセミコロンとカンマで区切ります。 +- `{index_name}` : セカンダリ インデックスの名前。 +- `{table_name}` : テーブル名。 +- `{column_names}` : インデックスを作成する列の名前をセミコロンとカンマで区切ります。 ## 新しいテーブルを作成する際にセカンダリインデックスを作成する {#create-a-secondary-index-when-creating-a-new-table} @@ -49,8 +49,8 @@ KEY `{index_name}` (`{column_names}`) パラメータの説明: -- `{index_name}` : セカンダリ インデックスの名前。 -- `{column_names}` : インデックスを作成する列の名前をセミコロンとカンマで区切ります。 +- `{index_name}` : セカンダリ インデックスの名前。 +- `{column_names}` : インデックスを作成する列の名前をセミコロンとカンマで区切ります。 ## セカンダリインデックス作成におけるルール {#rules-in-secondary-index-creation} @@ -141,8 +141,8 @@ CREATE INDEX `idx_book_published_at` ON `bookshop`.`books` (`bookshop`.`books`.` SQLパフォーマンスチューニングの詳細については、以下のドキュメントを参照してください。 -- [TiDB CloudのSQLチューニング概要](/tidb-cloud/tidb-cloud-sql-tuning-overview.md) -- [TiDB Self-ManagedのSQLチューニング概要](/sql-tuning-overview.md) +- [TiDB CloudのSQLチューニング概要](/tidb-cloud/tidb-cloud-sql-tuning-overview.md) +- [TiDB Self-ManagedのSQLチューニング概要](/sql-tuning-overview.md) > **Note:** > @@ -172,6 +172,6 @@ SHOW INDEXES FROM `bookshop`.`books`; ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-create-table.md b/develop/dev-guide-create-table.md index 35b90ce4037a2..123ae3db7227a 100644 --- a/develop/dev-guide-create-table.md +++ b/develop/dev-guide-create-table.md @@ -12,9 +12,9 @@ aliases: ['/ja/tidb/stable/dev-guide-create-table/','/ja/tidb/dev/dev-guide-crea この文書を読む前に、以下の作業が完了していることを確認してください。 -- [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md)お読みください。 -- [データベースを作成する](/develop/dev-guide-create-database.md)。 +- [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md)お読みください。 +- [データベースを作成する](/develop/dev-guide-create-database.md)。 ## テーブルとは何ですか {#what-is-a-table} @@ -32,8 +32,8 @@ CREATE TABLE {table_name} ( {elements} ); **パラメータの説明** -- `{table_name}` : 作成するテーブルの名前。 -- `{elements}` : 列定義や主キー定義など、テーブル要素をカンマで区切ったリスト。 +- `{table_name}` : 作成するテーブルの名前。 +- `{elements}` : 列定義や主キー定義など、テーブル要素をカンマで区切ったリスト。 `bookshop`データベースにユーザー情報を保存するためのテーブルを作成する必要があるとします。 @@ -56,9 +56,9 @@ CREATE TABLE `bookshop`.`users` ( **パラメータの説明** -- `{column_name}` : 列名。 -- `{data_type}` : 列[データ型](/data-type-overview.md)。 -- `{column_qualification}` :**列レベルの制約**や[生成列](/generated-columns.md)句などのカラム修飾。 +- `{column_name}` : 列名。 +- `{data_type}` : 列[データ型](/data-type-overview.md)。 +- `{column_qualification}` :**列レベルの制約**や[生成列](/generated-columns.md)句などのカラム修飾。 `users`テーブルに、一意の識別子`id` 、 `balance` 、 `nickname`などの列を追加できます。 @@ -93,9 +93,9 @@ CREATE TABLE `bookshop`.`books` ( このテーブルには`users`テーブルよりも多くのデータ型が含まれています。 -- [整数](/data-type-numeric.md#integer-types): ディスク使用量の過剰使用やパフォーマンスへの影響（型範囲が大きすぎる場合）またはデータオーバーフロー（データ型範囲が小さすぎる場合）を避けるため、適切なサイズの型を使用することをお勧めします。 -- :[日時](/data-type-date-and-time.md)型は**、**時間値を格納できます。 -- [列挙型](/data-type-string.md#enum-type): enum型は、限られた値の選択を格納するために使用できます。 +- [整数](/data-type-numeric.md#integer-types): ディスク使用量の過剰使用やパフォーマンスへの影響（型範囲が大きすぎる場合）またはデータオーバーフロー（データ型範囲が小さすぎる場合）を避けるため、適切なサイズの型を使用することをお勧めします。 +- :[日時](/data-type-date-and-time.md)型は**、**時間値を格納できます。 +- [列挙型](/data-type-string.md#enum-type): enum型は、限られた値の選択を格納するために使用できます。 ## 主キーを選択 {#select-primary-key} @@ -105,9 +105,9 @@ CREATE TABLE `bookshop`.`books` ( > > TiDBにおける**主キー**のデフォルト定義は、 [InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html) （MySQLの一般的なストレージエンジン）における定義とは異なります。 > -> - **InnoDB**では、**主キー**は一意であり、nullではなく、**インデックスはクラスター化されています**。 +> - **InnoDB**では、**主キー**は一意であり、nullではなく、**インデックスはクラスター化されています**。 > -> - TiDBでは、**主キー**は一意であり、NULLであってはなりません。ただし、主キーが**クラスター化インデックス**であることは保証されていません。代わりに、別のキーワードセット`CLUSTERED` / `NONCLUSTERED`によって、**主キー**が**クラスター化インデックス**であるかどうかが制御されます。キーワードが指定されていない場合は、システム変数`@@global.tidb_enable_clustered_index`によって制御されます（[クラスター化インデックス](https://docs.pingcap.com/tidb/stable/clustered-indexes)に記載のとおり）。 +> - TiDBでは、**主キー**は一意であり、NULLであってはなりません。ただし、主キーが**クラスター化インデックス**であることは保証されていません。代わりに、別のキーワードセット`CLUSTERED` / `NONCLUSTERED`によって、**主キー**が**クラスター化インデックス**であるかどうかが制御されます。キーワードが指定されていない場合は、システム変数`@@global.tidb_enable_clustered_index`によって制御されます（[クラスター化インデックス](https://docs.pingcap.com/tidb/stable/clustered-indexes)に記載のとおり）。 **主キー**は`CREATE TABLE`ステートメントで定義されます。[主キー制約](/constraints.md#primary-key)制約付き列すべてに NULL 以外の値のみが含まれることを要求します。 @@ -136,11 +136,11 @@ TiDB は v5.0 以降、[クラスター化インデックス](/clustered-indexes 現在、TiDBの***主キーを含む***テーブルは、以下の2つのカテゴリに分類されます。 -- `NONCLUSTERED` : テーブルの主キーは非クラスター化インデックスです。非クラスター化インデックスを持つテーブルでは、行データのキーは、TiDB によって暗黙的に割り当てられる内部`_tidb_rowid`で構成されます。主キーは基本的に一意インデックスであるため、非クラスター化インデックスを持つテーブルでは、行を格納するために少なくとも 2 つのキーと値のペアが必要です。それらは次のとおりです。 - - `_tidb_rowid` （キー） - 行データ（値） - - 主キーデータ（キー） - `_tidb_rowid` （値） -- `CLUSTERED` : テーブルの主キーはクラスター化インデックスです。クラスター化インデックスを持つテーブルでは、行データのキーはユーザーが指定した主キーデータで構成されます。したがって、クラスター化インデックスを持つテーブルでは、行を格納するために必要なキーと値のペアは1つだけです。それは次のとおりです。 - - 主キーデータ（キー） - 行データ（値） +- `NONCLUSTERED` : テーブルの主キーは非クラスター化インデックスです。非クラスター化インデックスを持つテーブルでは、行データのキーは、TiDB によって暗黙的に割り当てられる内部`_tidb_rowid`で構成されます。主キーは基本的に一意インデックスであるため、非クラスター化インデックスを持つテーブルでは、行を格納するために少なくとも 2 つのキーと値のペアが必要です。それらは次のとおりです。 + - `_tidb_rowid` （キー） - 行データ（値） + - 主キーデータ（キー） - `_tidb_rowid` （値） +- `CLUSTERED` : テーブルの主キーはクラスター化インデックスです。クラスター化インデックスを持つテーブルでは、行データのキーはユーザーが指定した主キーデータで構成されます。したがって、クラスター化インデックスを持つテーブルでは、行を格納するために必要なキーと値のペアは1つだけです。それは次のとおりです。 + - 主キーデータ（キー） - 行データ（値） [主キーを選択](#select-primary-key)で説明されているように、**クラスター化インデックス**は TiDB でキーワード`CLUSTERED`および`NONCLUSTERED`を使用して制御されます。 @@ -248,8 +248,8 @@ ALTER TABLE {table_name} SET TIFLASH REPLICA {count}; **パラメータの説明** -- `{table_name}` : テーブル名。 -- `{count}` : 複製されたレプリカの数。0 の場合、複製されたレプリカは削除されます。 +- `{table_name}` : テーブル名。 +- `{count}` : 複製されたレプリカの数。0 の場合、複製されたレプリカは削除されます。 **TiFlash は**テーブルを複製します。クエリが実行されると、TiDB はコストの最適化に基づいてクエリに対して TiKV (行ベース) またはTiFlash (列ベース) を自動的に選択します。あるいは、クエリで**TiFlash**レプリカを使用するかどうかを手動で指定できます。指定方法については、 [TiDBを使用してTiFlashレプリカを読み取ります](/tiflash/use-tidb-to-read-tiflash.md)を参照してください。 @@ -335,49 +335,49 @@ SHOW TABLES IN `bookshop`; ### テーブル名を付ける際のガイドライン {#guidelines-to-follow-when-naming-a-table} -- **完全修飾**テーブル名（例： `CREATE TABLE {database_name}. {table_name}` ）を使用してください。データベース名を指定しない場合、TiDB は**SQL セッション**で現在使用されているデータベースを使用します。SQL セッションでデータベースを指定する際に`USE {databasename};`を使用しない場合、TiDB はエラーを返します。 -- 意味のあるテーブル名を使用してください。たとえば、ユーザー テーブルを作成する必要がある場合は、 `user` 、 `t_user` 、 `users`のような名前を使用するか、会社または組織の命名規則に従ってください。会社または組織に命名規則がない場合は、 [テーブル命名規則](/develop/dev-guide-object-naming-guidelines.md#table-naming-convention)を参照してください。 `t1` 、 `table1`のようなテーブル名は使用しないでください。 -- 複数の単語はアンダースコアで区切られ、名前は32文字以内にすることをお勧めします。 -- 異なるビジネスモジュールのテーブル用に個別の`DATABASE`を作成し、それに応じてコメントを追加してください。 +- **完全修飾**テーブル名（例： `CREATE TABLE {database_name}. {table_name}` ）を使用してください。データベース名を指定しない場合、TiDB は**SQL セッション**で現在使用されているデータベースを使用します。SQL セッションでデータベースを指定する際に`USE {databasename};`を使用しない場合、TiDB はエラーを返します。 +- 意味のあるテーブル名を使用してください。たとえば、ユーザー テーブルを作成する必要がある場合は、 `user` 、 `t_user` 、 `users`のような名前を使用するか、会社または組織の命名規則に従ってください。会社または組織に命名規則がない場合は、 [テーブル命名規則](/develop/dev-guide-object-naming-guidelines.md#table-naming-convention)を参照してください。 `t1` 、 `table1`のようなテーブル名は使用しないでください。 +- 複数の単語はアンダースコアで区切られ、名前は32文字以内にすることをお勧めします。 +- 異なるビジネスモジュールのテーブル用に個別の`DATABASE`を作成し、それに応じてコメントを追加してください。 ### 列を定義する際に従うべきガイドライン {#guidelines-to-follow-when-defining-columns} -- 列のサポート[データ型](/data-type-overview.md)を確認し、データ型の制約に従ってデータを整理してください。列に格納するデータに適した型を選択してください。 -- 主キーの選択に関する[従うべきガイドライン](#guidelines-to-follow-when-selecting-primary-key)を確認し、主キー列を使用するかどうかを決定します。 -- クラスター化インデックスを選択するための[従うべきガイドライン](#guidelines-to-follow-when-selecting-clustered-index)ガイドラインを確認し、**クラスター化インデックス**を指定するかどうかを決定してください。 -- [列制約を追加する](#add-column-constraints)チェックし、列に制約を追加するかどうかを決定します。 -- 意味のある列名を使用してください。会社または組織のテーブル命名規則に従うことをお勧めします。会社または組織に対応する命名規則がない場合は、 [列名の命名規則](/develop/dev-guide-object-naming-guidelines.md#column-naming-convention)を参照してください。 +- 列のサポート[データ型](/data-type-overview.md)を確認し、データ型の制約に従ってデータを整理してください。列に格納するデータに適した型を選択してください。 +- 主キーの選択に関する[従うべきガイドライン](#guidelines-to-follow-when-selecting-primary-key)を確認し、主キー列を使用するかどうかを決定します。 +- クラスター化インデックスを選択するための[従うべきガイドライン](#guidelines-to-follow-when-selecting-clustered-index)ガイドラインを確認し、**クラスター化インデックス**を指定するかどうかを決定してください。 +- [列制約を追加する](#add-column-constraints)チェックし、列に制約を追加するかどうかを決定します。 +- 意味のある列名を使用してください。会社または組織のテーブル命名規則に従うことをお勧めします。会社または組織に対応する命名規則がない場合は、 [列名の命名規則](/develop/dev-guide-object-naming-guidelines.md#column-naming-convention)を参照してください。 ### 主キーを選択する際に従うべきガイドライン {#guidelines-to-follow-when-selecting-primary-key} -- テーブル内に**主キー**または**一意インデックス**を定義します。 -- 意味のある**列**を**主キー**として選択するようにしてください。 -- パフォーマンス上の理由から、幅の広いテーブルを保存することは避けてください。テーブルフィールドの数が`60`を超え、1行のデータの合計サイズが`64K`超えることは推奨されません。データ長が長すぎるフィールドは、別のテーブルに分割することをお勧めします。 -- 複雑なデータ型を使用することは推奨されません。 -- 結合するフィールドについては、データ型が一致していることを確認し、暗黙的な型変換を避けてください。 -- 単一の単調データ列に**主キー**を定義することは避けてください。単一の単調データ列（たとえば、 `AUTO_INCREMENT`属性を持つ列）を使用して**主キー**を定義すると、書き込みパフォーマンスに影響が出る可能性があります。可能であれば、 `AUTO_RANDOM`ではなく`AUTO_INCREMENT` }を使用してください。これにより、主キーの連続性および増分属性が破棄されます。 -- 書き込み集中シナリオで単一の単調データ列にインデックスを作成する必要がある場合は、この単調データ列を**主キー**として定義する代わりに、 `AUTO_RANDOM`を使用してそのテーブルの**主キー**を作成するか、 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)と[`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions)を使用して`_tidb_rowid`をシャーディングすることができます。 +- テーブル内に**主キー**または**一意インデックス**を定義します。 +- 意味のある**列**を**主キー**として選択するようにしてください。 +- パフォーマンス上の理由から、幅の広いテーブルを保存することは避けてください。テーブルフィールドの数が`60`を超え、1行のデータの合計サイズが`64K`超えることは推奨されません。データ長が長すぎるフィールドは、別のテーブルに分割することをお勧めします。 +- 複雑なデータ型を使用することは推奨されません。 +- 結合するフィールドについては、データ型が一致していることを確認し、暗黙的な型変換を避けてください。 +- 単一の単調データ列に**主キー**を定義することは避けてください。単一の単調データ列（たとえば、 `AUTO_INCREMENT`属性を持つ列）を使用して**主キー**を定義すると、書き込みパフォーマンスに影響が出る可能性があります。可能であれば、 `AUTO_RANDOM`ではなく`AUTO_INCREMENT` }を使用してください。これにより、主キーの連続性および増分属性が破棄されます。 +- 書き込み集中シナリオで単一の単調データ列にインデックスを作成する必要がある場合は、この単調データ列を**主キー**として定義する代わりに、 `AUTO_RANDOM`を使用してそのテーブルの**主キー**を作成するか、 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)と[`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions)を使用して`_tidb_rowid`をシャーディングすることができます。 ### クラスター化インデックスを選択する際に従うべきガイドライン {#guidelines-to-follow-when-selecting-clustered-index} -- **クラスター化インデックス**を構築するには、 [主キーの選択に関するガイドライン](#guidelines-to-follow-when-selecting-primary-key)に従ってください。 +- **クラスター化インデックス**を構築するには、 [主キーの選択に関するガイドライン](#guidelines-to-follow-when-selecting-primary-key)に従ってください。 -- クラスター化インデックスを持たないテーブルと比較して、クラスター化インデックスを持つテーブルは、以下のシナリオにおいて、より優れたパフォーマンスとスループットのメリットを提供します。 - - データが挿入される際、クラスター化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 - - 同等の条件を持つクエリが主キーのみに関係する場合、クラスター化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 - - 範囲条件を含むクエリが主キーのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 - - 同等条件または範囲条件を含むクエリが主キーのプレフィックスのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの複数回の読み取りを削減します。 +- クラスター化インデックスを持たないテーブルと比較して、クラスター化インデックスを持つテーブルは、以下のシナリオにおいて、より優れたパフォーマンスとスループットのメリットを提供します。 + - データが挿入される際、クラスター化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 + - 同等の条件を持つクエリが主キーのみに関係する場合、クラスター化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 + - 範囲条件を含むクエリが主キーのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 + - 同等条件または範囲条件を含むクエリが主キーのプレフィックスのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの複数回の読み取りを削減します。 -- 一方、クラスター化インデックスを持つテーブルには、次のような問題が発生する可能性があります。 - - 近い値を持つ主キーを多数挿入すると、書き込みホットスポットの問題が発生する可能性があります。 [主キーを選択する際に従うべきガイドライン](#guidelines-to-follow-when-selecting-primary-key)てください。 - - 主キーのデータ型が64ビットより大きい場合、特にセカンダリインデックスが複数存在する場合は、テーブルデータがより多くのストレージ容量を消費します。 +- 一方、クラスター化インデックスを持つテーブルには、次のような問題が発生する可能性があります。 + - 近い値を持つ主キーを多数挿入すると、書き込みホットスポットの問題が発生する可能性があります。 [主キーを選択する際に従うべきガイドライン](#guidelines-to-follow-when-selecting-primary-key)てください。 + - 主キーのデータ型が64ビットより大きい場合、特にセカンダリインデックスが複数存在する場合は、テーブルデータがより多くのストレージ容量を消費します。 -- [クラスター化インデックスを使用するかどうかのデフォルトの動作](/clustered-indexes.md#create-a-table-with-clustered-indexes)を制御するには、システム変数`@@global.tidb_enable_clustered_index`と構成`alter-primary-key` } を使用する代わりに、クラスター化インデックスを使用するかどうかを明示的に指定できます。 +- [クラスター化インデックスを使用するかどうかのデフォルトの動作](/clustered-indexes.md#create-a-table-with-clustered-indexes)を制御するには、システム変数`@@global.tidb_enable_clustered_index`と構成`alter-primary-key` } を使用する代わりに、クラスター化インデックスを使用するかどうかを明示的に指定できます。 ### `CREATE TABLE`文を実行する際に従うべきガイドライン {#guidelines-to-follow-when-executing-the-create-table-statement} -- データベーススキーマの変更にクライアント側のDriverやORMを使用することは推奨されません。データベーススキーマの変更には[MySQLクライアント](https://dev.mysql.com/doc/refman/8.0/en/mysql.html)またはGUIクライアントを使用することをお勧めします。このドキュメントでは、ほとんどのシナリオでSQLファイルを渡してデータベーススキーマを変更するために**MySQLクライアント**を使用します。 -- SQL 開発[テーブルの作成と削除に関する仕様](/develop/dev-guide-sql-development-specification.md#create-and-delete-tables)従ってください。ビジネスアプリケーション内にbuild文とdelete文をラップして判定ロジックを追加することを推奨します。 +- データベーススキーマの変更にクライアント側のDriverやORMを使用することは推奨されません。データベーススキーマの変更には[MySQLクライアント](https://dev.mysql.com/doc/refman/8.0/en/mysql.html)またはGUIクライアントを使用することをお勧めします。このドキュメントでは、ほとんどのシナリオでSQLファイルを渡してデータベーススキーマを変更するために**MySQLクライアント**を使用します。 +- SQL 開発[テーブルの作成と削除に関する仕様](/develop/dev-guide-sql-development-specification.md#create-and-delete-tables)従ってください。ビジネスアプリケーション内にbuild文とdelete文をラップして判定ロジックを追加することを推奨します。 ## あと一歩 {#one-more-step} @@ -385,6 +385,6 @@ SHOW TABLES IN `bookshop`; ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-delete-data.md b/develop/dev-guide-delete-data.md index 0a8e32b182112..049b3db3c2694 100644 --- a/develop/dev-guide-delete-data.md +++ b/develop/dev-guide-delete-data.md @@ -12,9 +12,9 @@ aliases: ['/ja/tidb/stable/dev-guide-delete-data/','/ja/tidb/dev/dev-guide-delet この文書を読む前に、以下のものを準備してください。 -- [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md) -- [スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md)、データベース[データベースを作成する](/develop/dev-guide-create-database.md)、[テーブルを作成する](/develop/dev-guide-create-table.md)、 [セカンダリインデックスを作成する](/develop/dev-guide-create-secondary-indexes.md)を読む -- [データを挿入する](/develop/dev-guide-insert-data.md) +- [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md) +- [スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md)、データベース[データベースを作成する](/develop/dev-guide-create-database.md)、[テーブルを作成する](/develop/dev-guide-create-table.md)、 [セカンダリインデックスを作成する](/develop/dev-guide-create-secondary-indexes.md)を読む +- [データを挿入する](/develop/dev-guide-insert-data.md) ## SQL構文 {#sql-syntax} @@ -35,15 +35,15 @@ DELETE FROM {table} WHERE {filter} データを削除する際に従うべきベストプラクティスを以下に示します。 -- `WHERE`ステートメントには、必ず`DELETE`句を指定してください。 `WHERE`句が指定されていない場合、TiDB はテーブル内の***すべての行***を削除します。 +- `WHERE`ステートメントには、必ず`DELETE`句を指定してください。 `WHERE`句が指定されていない場合、TiDB はテーブル内の***すべての行***を削除します。 -- TiDB では 1 つのトランザクションのサイズが制限されているため (たとえば、1 万行以上)、大量の行を削除する場合は[一括削除](#bulk-delete)を使用します (段階[トランザクションの合計サイズ制限](/tidb-configuration-file.md#txn-total-size-limit)、デフォルトでは 100 MB)。 +- TiDB では 1 つのトランザクションのサイズが制限されているため (たとえば、1 万行以上)、大量の行を削除する場合は[一括削除](#bulk-delete)を使用します (段階[トランザクションの合計サイズ制限](/tidb-configuration-file.md#txn-total-size-limit)、デフォルトでは 100 MB)。 -- テーブル内のすべてのデータを削除する場合は、 `DELETE`ステートメントを使用しないでください。代わりに、 [`TRUNCATE`](/sql-statements/sql-statement-truncate.md)ステートメントを使用してください。 +- テーブル内のすべてのデータを削除する場合は、 `DELETE`ステートメントを使用しないでください。代わりに、 [`TRUNCATE`](/sql-statements/sql-statement-truncate.md)ステートメントを使用してください。 -- パフォーマンスに関する考慮事項については、[パフォーマンスに関する考慮事項](#performance-considerations)を参照してください。 +- パフォーマンスに関する考慮事項については、[パフォーマンスに関する考慮事項](#performance-considerations)を参照してください。 -- 大量のデータを削除する必要があるシナリオでは、[非トランザクション一括削除](#non-transactional-bulk-delete)パフォーマンスが大幅に向上します。ただし、これにより削除のトランザクションが失われるため、ロールバック**できません**。正しい操作を選択していることを確認してください。 +- 大量のデータを削除する必要があるシナリオでは、[非トランザクション一括削除](#non-transactional-bulk-delete)パフォーマンスが大幅に向上します。ただし、これにより削除のトランザクションが失われるため、ロールバック**できません**。正しい操作を選択していることを確認してください。 ## 例 {#example} @@ -165,8 +165,8 @@ with connection: > **Note:** > -> - `rated_at`フィールドは、[日付と時刻の種類](/data-type-date-and-time.md)種類の`DATETIME`タイプです。タイムゾーンに関係なく、TiDB にリテラル数量として保存されていると想定できます。一方、 `TIMESTAMP`タイプはタイムスタンプを保存するため、異なるタイム[タイムゾーン](/configure-time-zone.md)には異なる時刻文字列が表示されます。 -> - MySQLと同様に、 `TIMESTAMP`データ型は[2038年の問題](https://en.wikipedia.org/wiki/Year_2038_problem)の影響を受けます。2038より大きい値を格納する場合は、 `DATETIME`型を使用することをお勧めします。 +> - `rated_at`フィールドは、[日付と時刻の種類](/data-type-date-and-time.md)種類の`DATETIME`タイプです。タイムゾーンに関係なく、TiDB にリテラル数量として保存されていると想定できます。一方、 `TIMESTAMP`タイプはタイムスタンプを保存するため、異なるタイム[タイムゾーン](/configure-time-zone.md)には異なる時刻文字列が表示されます。 +> - MySQLと同様に、 `TIMESTAMP`データ型は[2038年の問題](https://en.wikipedia.org/wiki/Year_2038_problem)の影響を受けます。2038より大きい値を格納する場合は、 `DATETIME`型を使用することをお勧めします。 ## パフォーマンスに関する考慮事項 {#performance-considerations} @@ -386,6 +386,6 @@ BATCH ON `rated_at` LIMIT 1000 DELETE FROM `ratings` WHERE `rated_at` >= "2022-0 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-get-data-from-single-table.md b/develop/dev-guide-get-data-from-single-table.md index aaa7cffe4f624..05833e17cf01e 100644 --- a/develop/dev-guide-get-data-from-single-table.md +++ b/develop/dev-guide-get-data-from-single-table.md @@ -19,16 +19,16 @@ aliases: ['/ja/tidb/stable/dev-guide-get-data-from-single-table/','/ja/tidb/dev/
-1. [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -2. [Bookshopアプリケーションのテーブルスキーマとサンプルデータをインポートします](/develop/dev-guide-bookshop-schema-design.md#import-table-structures-and-data) -3. [TiDBに接続する](/develop/dev-guide-connect-to-tidb.md)。 +1. [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +2. [Bookshopアプリケーションのテーブルスキーマとサンプルデータをインポートします](/develop/dev-guide-bookshop-schema-design.md#import-table-structures-and-data) +3. [TiDBに接続する](/develop/dev-guide-connect-to-tidb.md)。
-1. [TiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md)。 -2. [Bookshopアプリケーションのテーブルスキーマとサンプルデータをインポートします](/develop/dev-guide-bookshop-schema-design.md#import-table-structures-and-data) -3. [TiDBに接続する](/develop/dev-guide-connect-to-tidb.md)。 +1. [TiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md)。 +2. [Bookshopアプリケーションのテーブルスキーマとサンプルデータをインポートします](/develop/dev-guide-bookshop-schema-design.md#import-table-structures-and-data) +3. [TiDBに接続する](/develop/dev-guide-connect-to-tidb.md)。
@@ -72,10 +72,10 @@ SELECT id, name FROM authors; Javaでは、著者の基本情報を格納するために、クラス`Author`[価格帯](/data-type-numeric.md)[データ型](/data-type-overview.md)応じて適切なJavaデータ型を選択する必要があります。例： -- `Int`型のデータを格納するには、 `int`型の変数を使用します。 -- `Long`型のデータを格納するには、 `bigint`型の変数を使用します。 -- `Short`型のデータを格納するには、 `tinyint`型の変数を使用します。 -- `String`型のデータを格納するには、 `varchar`型の変数を使用します。 +- `Int`型のデータを格納するには、 `int`型の変数を使用します。 +- `Long`型のデータを格納するには、 `bigint`型の変数を使用します。 +- `Short`型のデータを格納するには、 `tinyint`型の変数を使用します。 +- `String`型のデータを格納するには、 `varchar`型の変数を使用します。 ```java public class Author { @@ -380,6 +380,6 @@ public List getAuthorCountsByBirthYear() throws SQLException { ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-gui-datagrip.md b/develop/dev-guide-gui-datagrip.md index 1d04af7bde93b..ac4cf1c84a299 100644 --- a/develop/dev-guide-gui-datagrip.md +++ b/develop/dev-guide-gui-datagrip.md @@ -14,8 +14,8 @@ TiDBはMySQL互換のデータベースであり、 [JetBrains DataGrip](https:/ DataGripは2つの方法で使用できます。 -- [DataGrip IDE](https://www.jetbrains.com/datagrip/download)スタンドアロンツールとして。 -- IntelliJ、PhpStorm、PyCharm などの JetBrains IDE のデータベース[データベースツールとSQLプラグイン](https://www.jetbrains.com/help/idea/relational-databases.html)として。 +- [DataGrip IDE](https://www.jetbrains.com/datagrip/download)スタンドアロンツールとして。 +- IntelliJ、PhpStorm、PyCharm などの JetBrains IDE のデータベース[データベースツールとSQLプラグイン](https://www.jetbrains.com/help/idea/relational-databases.html)として。 このチュートリアルは主にスタンドアロン版のDataGrip IDEに焦点を当てています。JetBrains IDEのJetBrains Database ToolsおよびSQLプラグインを使用してTiDBに接続する手順も同様です。また、どのJetBrains IDEからTiDBに接続する場合でも、このドキュメントの手順を参考にすることができます。 @@ -23,13 +23,13 @@ DataGripは2つの方法で使用できます。 このチュートリアルを完了するには、以下が必要です。 -- [DataGrip **2023.2.1**以降](https://www.jetbrains.com/datagrip/download/)、または非コミュニティ エディションの[JetBrains](https://www.jetbrains.com/)IDE。 -- TiDBクラスタ。 +- [DataGrip **2023.2.1**以降](https://www.jetbrains.com/datagrip/download/)、または非コミュニティ エディションの[JetBrains](https://www.jetbrains.com/)IDE。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続する {#connect-to-tidb} @@ -38,70 +38,70 @@ DataGripは2つの方法で使用できます。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 - - **Connect With**は`DataGrip`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - **Connection Type**は`Public`に設定されています。 + - **Branch**は`main`に設定されています。 + - **Connect With**は`DataGrip`に設定されています。 + - お使いの環境に合った**Operating System**を選択してください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. DataGripを起動し、接続を管理するためのプロジェクトを作成します。 +5. DataGripを起動し、接続を管理するためのプロジェクトを作成します。 ![Create a project in DataGrip](/media/develop/datagrip-create-project.jpg) -6. 新しく作成したプロジェクトで、**Database Explorer**パネルの左上隅にある**+**をクリックし、 **Data Source** > **Other** > **TiDB**を選択します。 +6. 新しく作成したプロジェクトで、**Database Explorer**パネルの左上隅にある**+**をクリックし、 **Data Source** > **Other** > **TiDB**を選択します。 ![Select a data source in DataGrip](/media/develop/datagrip-data-source-select.jpg) -7. TiDB Cloud接続ダイアログから接続文字列をコピーします。次に、それを**URL**フィールドに貼り付けると、残りのパラメータは自動的に入力されます。結果の例は次のとおりです。 +7. TiDB Cloud接続ダイアログから接続文字列をコピーします。次に、それを**URL**フィールドに貼り付けると、残りのパラメータは自動的に入力されます。結果の例は次のとおりです。 ![Configure the URL field for TiDB Cloud Starter](/media/develop/datagrip-url-paste.jpg) **Download missing driver files**という警告が表示された場合は、 **Download**をクリックしてドライバファイルを入手してください。 -8. **Test Connection**をクリックして、対象のTiDB Cloud StarterまたはEssentialインスタンスへの接続を検証してください。 +8. **Test Connection**をクリックして、対象のTiDB Cloud StarterまたはEssentialインスタンスへの接続を検証してください。 ![Test the connection to a TiDB Cloud Starter instance](/media/develop/datagrip-test-connection.jpg) -9. 接続設定を保存するには、 **OK**をクリックしてください。 +9. 接続設定を保存するには、 **OK**をクリックしてください。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. DataGripを起動し、接続を管理するためのプロジェクトを作成します。 +7. DataGripを起動し、接続を管理するためのプロジェクトを作成します。 -8. 新しく作成したプロジェクトで、**Database Explorer**パネルの左上隅にある**+**をクリックし、 **Data Source** > **Other** > **TiDB**を選択します。 +8. 新しく作成したプロジェクトで、**Database Explorer**パネルの左上隅にある**+**をクリックし、 **Data Source** > **Other** > **TiDB**を選択します。 -9. 適切な接続文字列をコピーして、DataGrip の **Data Source and Drivers**ウィンドウに貼り付けてください。DataGrip のフィールドとTiDB Cloud Premium の接続文字列のマッピングは以下のとおりです。 +9. 適切な接続文字列をコピーして、DataGrip の **Data Source and Drivers**ウィンドウに貼り付けてください。DataGrip のフィールドとTiDB Cloud Premium の接続文字列のマッピングは以下のとおりです。 | DataGrip field | TiDB Cloud Premium接続文字列 | | ------------ | ----------------------- | @@ -110,8 +110,8 @@ DataGripは2つの方法で使用できます。 | User | `{user}` | | Password | `{password}` | - - **SSH/SSL**タブで、 **Use SSL**チェックボックスをオフにします。 - - **Download missing driver files**という警告が表示された場合は、 **Download**をクリックしてドライバファイルを入手してください。 + - **SSH/SSL**タブで、 **Use SSL**チェックボックスをオフにします。 + - **Download missing driver files**という警告が表示された場合は、 **Download**をクリックしてドライバファイルを入手してください。 10. **Test Connection**をクリックして、 TiDB Cloud Premiumインスタンスへの接続を検証してください。 @@ -120,25 +120,25 @@ DataGripは2つの方法で使用できます。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. DataGripを起動し、接続を管理するためのプロジェクトを作成します。 +4. DataGripを起動し、接続を管理するためのプロジェクトを作成します。 ![Create a project in DataGrip](/media/develop/datagrip-create-project.jpg) -5. 新しく作成したプロジェクトで、**Database Explorer**パネルの左上隅にある**+**をクリックし、 **Data Source** > **Other** > **TiDB**を選択します。 +5. 新しく作成したプロジェクトで、**Database Explorer**パネルの左上隅にある**+**をクリックし、 **Data Source** > **Other** > **TiDB**を選択します。 ![Select a data source in DataGrip](/media/develop/datagrip-data-source-select.jpg) -6. 適切な接続文字列をコピーして、DataGrip の **Data Source and Drivers**ウィンドウに貼り付けてください。DataGrip フィールドとTiDB Cloud Dedicated接続文字列のマッピングは以下のとおりです。 +6. 適切な接続文字列をコピーして、DataGrip の **Data Source and Drivers**ウィンドウに貼り付けてください。DataGrip フィールドとTiDB Cloud Dedicated接続文字列のマッピングは以下のとおりです。 | DataGrip field | TiDB Cloud Dedicated接続文字列 | | ------------ | ------------------------- | @@ -151,17 +151,17 @@ DataGripは2つの方法で使用できます。 ![Configure the connection parameters for TiDB Cloud Dedicated](/media/develop/datagrip-dedicated-connect.jpg) -7. **SSH/SSL**タブをクリックし、 **Use SSL**チェックボックスを選択して、CA証明書のパスを**CA file**フィールドに入力します。 +7. **SSH/SSL**タブをクリックし、 **Use SSL**チェックボックスを選択して、CA証明書のパスを**CA file**フィールドに入力します。 ![Configure the CA for TiDB Cloud Dedicated](/media/develop/datagrip-dedicated-ssl.jpg) **Download missing driver files**という警告が表示された場合は、 **Download**をクリックしてドライバファイルを入手してください。 -8. **Advanced**タブをクリックし、スクロールして**enabledTLSProtocols**パラメーターを見つけ、その値を`TLSv1.2,TLSv1.3`に設定します。 +8. **Advanced**タブをクリックし、スクロールして**enabledTLSProtocols**パラメーターを見つけ、その値を`TLSv1.2,TLSv1.3`に設定します。 ![Configure the TLS for TiDB Cloud Dedicated](/media/develop/datagrip-dedicated-advanced.jpg) -9. **Test Connection**をクリックして、 TiDB Cloud Dedicatedクラスターへの接続を検証してください。 +9. **Test Connection**をクリックして、 TiDB Cloud Dedicatedクラスターへの接続を検証してください。 ![Test the connection to a TiDB Cloud Dedicated cluster](/media/develop/datagrip-dedicated-test-connection.jpg) @@ -170,20 +170,20 @@ DataGripは2つの方法で使用できます。
-1. DataGripを起動し、接続を管理するためのプロジェクトを作成します。 +1. DataGripを起動し、接続を管理するためのプロジェクトを作成します。 ![Create a project in DataGrip](/media/develop/datagrip-create-project.jpg) -2. 新しく作成したプロジェクトで、**Database Explorer**パネルの左上隅にある**+**をクリックし、 **Data Source** > **Other** > **TiDB**を選択します。 +2. 新しく作成したプロジェクトで、**Database Explorer**パネルの左上隅にある**+**をクリックし、 **Data Source** > **Other** > **TiDB**を選択します。 ![Select a data source in DataGrip](/media/develop/datagrip-data-source-select.jpg) -3. 以下の接続パラメータを設定してください。 +3. 以下の接続パラメータを設定してください。 - - **Host**：TiDB Self-ManagedクラスタのIPアドレスまたはドメイン名。 - - **Port**：TiDB Self-Managedクラスタのポート番号。 - - **User**：TiDB Self-Managedクラスタに接続するために使用するユーザー名。 - - **Password**：ユーザー名のパスワード。 + - **Host**：TiDB Self-ManagedクラスタのIPアドレスまたはドメイン名。 + - **Port**：TiDB Self-Managedクラスタのポート番号。 + - **User**：TiDB Self-Managedクラスタに接続するために使用するユーザー名。 + - **Password**：ユーザー名のパスワード。 例えば、以下のような例があります。 @@ -191,23 +191,23 @@ DataGripは2つの方法で使用できます。 **Download missing driver files**という警告が表示された場合は、 **Download**をクリックしてドライバファイルを入手してください。 -4. **Test Connection**をクリックして、TiDB Self-Managedクラスタへの接続を検証してください。 +4. **Test Connection**をクリックして、TiDB Self-Managedクラスタへの接続を検証してください。 ![Test the connection to a TiDB Self-Managed cluster](/media/develop/datagrip-self-hosted-test-connection.jpg) -5. 接続設定を保存するには、 **OK**をクリックしてください。 +5. 接続設定を保存するには、 **OK**をクリックしてください。
## 次のステップ {#next-steps} -- DataGrip の使用法の詳細については[DataGripのドキュメント](https://www.jetbrains.com/help/datagrip/getting-started.html)ご覧ください。 -- [開発者ガイド](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)、[トランザクション](/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/)を取得します。 +- DataGrip の使用法の詳細については[DataGripのドキュメント](https://www.jetbrains.com/help/datagrip/getting-started.html)ご覧ください。 +- [開発者ガイド](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)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-gui-dbeaver.md b/develop/dev-guide-gui-dbeaver.md index deab2b2b441f9..0d66b418ed214 100644 --- a/develop/dev-guide-gui-dbeaver.md +++ b/develop/dev-guide-gui-dbeaver.md @@ -18,27 +18,27 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt このチュートリアルを完了するには、以下が必要です。 -- [DBeaver Community **23.0.3**以降](https://dbeaver.io/download/)。 -- TiDBクラスタ。 +- [DBeaver Community **23.0.3**以降](https://dbeaver.io/download/)。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) さらに、 **Windows**上の DBeaver からTiDB Cloud StarterまたはTiDB Cloud Essential のパブリックエンドポイントに接続するには、以下の手順で追加の SSL 証明書 (ISRG Root X1) を設定する必要があります。設定しない場合、接続は失敗します。その他のオペレーティングシステムの場合は、これらの手順はスキップできます。 -1. [ISRGルートX1証明書](https://letsencrypt.org/certs/isrgrootx1.pem)をダウンロードし、 `C:\certs\isrgrootx1.pem`などのローカル パスに保存します。 +1. [ISRGルートX1証明書](https://letsencrypt.org/certs/isrgrootx1.pem)をダウンロードし、 `C:\certs\isrgrootx1.pem`などのローカル パスに保存します。 -2. DBeaverで接続設定を編集し、 **SSL**タブに移動します。 +2. DBeaverで接続設定を編集し、 **SSL**タブに移動します。 - 1. **Use SSL**を選択してください。 - 2. **CA certificate**フィールドで、ダウンロードした`isrgrootx1.pem`ファイルを選択します。 - 3. その他の証明書欄は空欄のままにしてください。 + 1. **Use SSL**を選択してください。 + 2. **CA certificate**フィールドで、ダウンロードした`isrgrootx1.pem`ファイルを選択します。 + 3. その他の証明書欄は空欄のままにしてください。 -3. SSL 構成の競合を避けるため、**Driver properties**タブで、既存の`sslMode` 、 `useSSL` 、または`requireSSL`エントリをすべて削除してください。 +3. SSL 構成の競合を避けるため、**Driver properties**タブで、既存の`sslMode` 、 `useSSL` 、または`requireSSL`エントリをすべて削除してください。 -4. **Test Connection**をクリックして、接続が成功したことを確認してください。 +4. **Test Connection**をクリックして、接続が成功したことを確認してください。 ## TiDBに接続する {#connect-to-tidb} @@ -47,34 +47,34 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 - - **Connect With**は`DBeaver`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - **Connection Type**は`Public`に設定されています。 + - **Branch**は`main`に設定されています。 + - **Connect With**は`DBeaver`に設定されています。 + - お使いの環境に合った**Operating System**を選択してください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. DBeaverを起動し、左上隅の**New Database Connection**をクリックします。 **Connect to a database**ダイアログで、リストから**TiDB**を選択し、 **Next**をクリックします。 +5. DBeaverを起動し、左上隅の**New Database Connection**をクリックします。 **Connect to a database**ダイアログで、リストから**TiDB**を選択し、 **Next**をクリックします。 ![Select TiDB as the database in DBeaver](/media/develop/dbeaver-select-database.jpg) -6. TiDB Cloud接続ダイアログから接続文字列をコピーします。DBeaverで、 **Connect by**に**URL**を選択し、 **URL**フィールドに接続文字列を貼り付けます。 +6. TiDB Cloud接続ダイアログから接続文字列をコピーします。DBeaverで、 **Connect by**に**URL**を選択し、 **URL**フィールドに接続文字列を貼り付けます。 -7. **Authentication (Database Native)**セクションで、**Username**と**Password**を入力してください。例は以下のとおりです。 +7. **Authentication (Database Native)**セクションで、**Username**と**Password**を入力してください。例は以下のとおりです。 ![Configure connection settings for TiDB Cloud Starter](/media/develop/dbeaver-connection-settings-serverless.jpg) -8. **Test Connection**をクリックして、対象のTiDB Cloud StarterまたはEssentialインスタンスへの接続を検証してください。 +8. **Test Connection**をクリックして、対象のTiDB Cloud StarterまたはEssentialインスタンスへの接続を検証してください。 **Download driver files**ダイアログが表示されたら、 **Download**をクリックしてドライバファイルを入手してください。 @@ -84,33 +84,33 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt ![Connection test result](/media/develop/dbeaver-connection-test.jpg) -9. 接続設定を保存するには、 **Finish**をクリックしてください。 +9. 接続設定を保存するには、 **Finish**をクリックしてください。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. DBeaverを起動し、左上隅の**New Database Connection**をクリックします。 **Connect to a database**ダイアログで、リストから**TiDB**を選択し、 **Next**をクリックします。 +7. DBeaverを起動し、左上隅の**New Database Connection**をクリックします。 **Connect to a database**ダイアログで、リストから**TiDB**を選択し、 **Next**をクリックします。 -8. 適切な接続文字列をコピーして、DBeaverの接続パネルに貼り付けてください。DBeaverのフィールドとTiDB Cloud Premiumの接続文字列のマッピングは以下のとおりです。 +8. 適切な接続文字列をコピーして、DBeaverの接続パネルに貼り付けてください。DBeaverのフィールドとTiDB Cloud Premiumの接続文字列のマッピングは以下のとおりです。 | DBeaverフィールド | TiDB Cloud Premium接続文字列 | | ------------ | ----------------------- | @@ -121,28 +121,28 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt SSL設定は無効のままにしてください。 -9. **Test Connection**をクリックして、 TiDB Cloud Premiumインスタンスへの接続を検証してください。 +9. **Test Connection**をクリックして、 TiDB Cloud Premiumインスタンスへの接続を検証してください。 10. 接続設定を保存するには、 **Finish**をクリックしてください。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. DBeaverを起動し、左上隅の**New Database Connection**をクリックします。 **Connect to a database**ダイアログで、リストから**TiDB**を選択し、 **Next**をクリックします。 +4. DBeaverを起動し、左上隅の**New Database Connection**をクリックします。 **Connect to a database**ダイアログで、リストから**TiDB**を選択し、 **Next**をクリックします。 ![Select TiDB as the database in DBeaver](/media/develop/dbeaver-select-database.jpg) -5. 適切な接続文字列をコピーして、DBeaverの接続パネルに貼り付けてください。DBeaverのフィールドとTiDB Cloud Dedicatedの接続文字列のマッピングは以下のとおりです。 +5. 適切な接続文字列をコピーして、DBeaverの接続パネルに貼り付けてください。DBeaverのフィールドとTiDB Cloud Dedicatedの接続文字列のマッピングは以下のとおりです。 | DBeaverフィールド | TiDB Cloud Dedicated接続文字列 | | ------------ | ------------------------- | @@ -155,7 +155,7 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt ![Configure connection settings for TiDB Cloud Dedicated](/media/develop/dbeaver-connection-settings-dedicated.jpg) -6. **Test Connection**をクリックして、 TiDB Cloud Dedicatedクラスターへの接続を検証してください。 +6. **Test Connection**をクリックして、 TiDB Cloud Dedicatedクラスターへの接続を検証してください。 **Download driver files**ダイアログが表示されたら、 **Download**をクリックしてドライバファイルを入手してください。 @@ -165,27 +165,27 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt ![Connection test result](/media/develop/dbeaver-connection-test.jpg) -7. 接続設定を保存するには、 **Finish**をクリックしてください。 +7. 接続設定を保存するには、 **Finish**をクリックしてください。
-1. DBeaverを起動し、左上隅の**New Database Connection**をクリックします。 **Connect to a database**ダイアログで、リストから**TiDB**を選択し、 **Next**をクリックします。 +1. DBeaverを起動し、左上隅の**New Database Connection**をクリックします。 **Connect to a database**ダイアログで、リストから**TiDB**を選択し、 **Next**をクリックします。 ![Select TiDB as the database in DBeaver](/media/develop/dbeaver-select-database.jpg) -2. 以下の接続パラメータを設定してください。 +2. 以下の接続パラメータを設定してください。 - - **Server Host**：TiDB Self-ManagedクラスタのIPアドレスまたはドメイン名。 - - **Port**：TiDB Self-Managedクラスタのポート番号。 - - **Username**：TiDB Self-Managedクラスタに接続するために使用するユーザー名。 - - **Password**：ユーザー名のパスワード。 + - **Server Host**：TiDB Self-ManagedクラスタのIPアドレスまたはドメイン名。 + - **Port**：TiDB Self-Managedクラスタのポート番号。 + - **Username**：TiDB Self-Managedクラスタに接続するために使用するユーザー名。 + - **Password**：ユーザー名のパスワード。 例えば、以下のような例があります。 ![Configure connection settings for TiDB Self-Managed](/media/develop/dbeaver-connection-settings-self-hosted.jpg) -3. **Test Connection**をクリックして、TiDB Self-Managedクラスタへの接続を検証してください。 +3. **Test Connection**をクリックして、TiDB Self-Managedクラスタへの接続を検証してください。 **Download driver files**ダイアログが表示されたら、 **Download**をクリックしてドライバファイルを入手してください。 @@ -195,19 +195,19 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt ![Connection test result](/media/develop/dbeaver-connection-test.jpg) -4. 接続設定を保存するには、 **Finish**をクリックしてください。 +4. 接続設定を保存するには、 **Finish**をクリックしてください。
## 次のステップ {#next-steps} -- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/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/)を取得します。 +- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-gui-mysql-workbench.md b/develop/dev-guide-gui-mysql-workbench.md index 4c6fe91099d07..cdf8eee2d00aa 100644 --- a/develop/dev-guide-gui-mysql-workbench.md +++ b/develop/dev-guide-gui-mysql-workbench.md @@ -10,8 +10,8 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my > **Warning:** > -> - MySQL WorkbenchはMySQLとの互換性があるため、TiDBに接続できますが、MySQL WorkbenchはTiDBを完全にサポートしているわけではありません。TiDBをMySQLとして扱うため、使用中に問題が発生する可能性があります。 -> - [DataGrip](/develop/dev-guide-gui-datagrip.md)、 [DBeaver](/develop/dev-guide-gui-dbeaver.md) 、 [VS Code SQLTools](/develop/dev-guide-gui-vscode-sqltools.md)など、TiDB を正式にサポートする他の GUI ツールを使用することをお勧めします。 TiDB で完全にサポートされている GUI ツールの完全なリストについては、 [TiDBがサポートするサードパーティツール](/develop/dev-guide-third-party-support.md#gui)を参照してください。 +> - MySQL WorkbenchはMySQLとの互換性があるため、TiDBに接続できますが、MySQL WorkbenchはTiDBを完全にサポートしているわけではありません。TiDBをMySQLとして扱うため、使用中に問題が発生する可能性があります。 +> - [DataGrip](/develop/dev-guide-gui-datagrip.md)、 [DBeaver](/develop/dev-guide-gui-dbeaver.md) 、 [VS Code SQLTools](/develop/dev-guide-gui-vscode-sqltools.md)など、TiDB を正式にサポートする他の GUI ツールを使用することをお勧めします。 TiDB で完全にサポートされている GUI ツールの完全なリストについては、 [TiDBがサポートするサードパーティツール](/develop/dev-guide-third-party-support.md#gui)を参照してください。 このチュートリアルでは、MySQL Workbenchを使用してTiDBに接続する方法を学ぶことができます。 @@ -23,13 +23,13 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my このチュートリアルを完了するには、以下が必要です。 -- [MySQL Workchen](https://dev.mysql.com/downloads/workbench/) **8.0.31**以降のバージョン。 -- TiDBクラスタ。 +- [MySQL Workchen](https://dev.mysql.com/downloads/workbench/) **8.0.31**以降のバージョン。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続する {#connect-to-tidb} @@ -38,34 +38,34 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 - - **Connect With**は`MySQL Workbench`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - **Connection Type**は`Public`に設定されています。 + - **Branch**は`main`に設定されています。 + - **Connect With**は`MySQL Workbench`に設定されています。 + - お使いの環境に合った**Operating System**を選択してください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. MySQL Workbenchを起動し、 **MySQL Connections**タイトルの横にある**+**をクリックします。 +5. MySQL Workbenchを起動し、 **MySQL Connections**タイトルの横にある**+**をクリックします。 ![MySQL Workbench: add new connection](/media/develop/mysql-workbench-add-new-connection.png) -6. **Setup New Connection**ダイアログで、以下の接続パラメータを設定します。 +6. **Setup New Connection**ダイアログで、以下の接続パラメータを設定します。 - - **Connection Name**：この接続に分かりやすい名前を付けてください。 - - **Hostname**： TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 - - **Port**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 - - **Username**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 - - **Password**： **Store in Keychain ...**または**Store in Vault**をクリックし、手順4で作成したパスワードを入力して、 **OK**をクリックしてパスワードを保存します。 + - **Connection Name**：この接続に分かりやすい名前を付けてください。 + - **Hostname**： TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 + - **Port**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 + - **Username**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 + - **Password**： **Store in Keychain ...**または**Store in Vault**をクリックし、手順4で作成したパスワードを入力して、 **OK**をクリックしてパスワードを保存します。 ![MySQL Workbench: store the password of TiDB Cloud Starter in keychain](/media/develop/mysql-workbench-store-password-in-keychain.png) @@ -73,70 +73,70 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my ![MySQL Workbench: configure connection settings for TiDB Cloud Starter](/media/develop/mysql-workbench-connection-config-serverless-parameters.png) -7. **Test Connection**をクリックして、対象のTiDB Cloud StarterまたはEssentialインスタンスへの接続を検証してください。 +7. **Test Connection**をクリックして、対象のTiDB Cloud StarterまたはEssentialインスタンスへの接続を検証してください。 -8. 接続テストが成功すると、 **Successfully made the MySQL connection**というメッセージが表示されます。 **OK**をクリックして接続設定を保存してください。 +8. 接続テストが成功すると、 **Successfully made the MySQL connection**というメッセージが表示されます。 **OK**をクリックして接続設定を保存してください。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. MySQL Workbenchを起動し、 **MySQL Connections**タイトルの横にある**+**をクリックします。 +7. MySQL Workbenchを起動し、 **MySQL Connections**タイトルの横にある**+**をクリックします。 -8. **Setup New Connection**ダイアログで、以下の接続パラメータを設定します。 +8. **Setup New Connection**ダイアログで、以下の接続パラメータを設定します。 - - **Connection Name**：この接続に分かりやすい名前を付けてください。 - - **Hostname**： TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 - - **Port**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 - - **Username**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 - - **Password**： **Store in Keychain ...**または**Store in Vault**をクリックし、 TiDB Cloud Premiumインスタンスのパスワードを入力して、 **OK**をクリックするとパスワードが保存されます。 + - **Connection Name**：この接続に分かりやすい名前を付けてください。 + - **Hostname**： TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 + - **Port**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 + - **Username**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 + - **Password**： **Store in Keychain ...**または**Store in Vault**をクリックし、 TiDB Cloud Premiumインスタンスのパスワードを入力して、 **OK**をクリックするとパスワードが保存されます。 -9. **Test Connection**をクリックして、 TiDB Cloud Premiumインスタンスへの接続を検証してください。 +9. **Test Connection**をクリックして、 TiDB Cloud Premiumインスタンスへの接続を検証してください。 10. 接続テストが成功すると、 **Successfully made the MySQL connection**というメッセージが表示されます。 **OK**をクリックして接続設定を保存してください。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. MySQL Workbenchを起動し、 **MySQL Connections**タイトルの横にある**+**をクリックします。 +4. MySQL Workbenchを起動し、 **MySQL Connections**タイトルの横にある**+**をクリックします。 ![MySQL Workbench: add new connection](/media/develop/mysql-workbench-add-new-connection.png) -5. **Setup New Connection**ダイアログで、以下の接続パラメータを設定します。 +5. **Setup New Connection**ダイアログで、以下の接続パラメータを設定します。 - - **Connection Name**：この接続に分かりやすい名前を付けてください。 - - **Hostname**： TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 - - **Port**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 - - **Username**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 - - **Password**： **Store in Keychain ...**をクリックし、 TiDB Cloud Dedicatedクラスタのパスワードを入力して、 **OK**をクリックするとパスワードが保存されます。 + - **Connection Name**：この接続に分かりやすい名前を付けてください。 + - **Hostname**： TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 + - **Port**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 + - **Username**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 + - **Password**： **Store in Keychain ...**をクリックし、 TiDB Cloud Dedicatedクラスタのパスワードを入力して、 **OK**をクリックするとパスワードが保存されます。 ![MySQL Workbench: store the password of TiDB Cloud Dedicated in keychain](/media/develop/mysql-workbench-store-dedicated-password-in-keychain.png) @@ -144,24 +144,24 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my ![MySQL Workbench: configure connection settings for TiDB Cloud Dedicated](/media/develop/mysql-workbench-connection-config-dedicated-parameters.png) -6. **Test Connection**をクリックして、 TiDB Cloud Dedicatedクラスターへの接続を検証してください。 +6. **Test Connection**をクリックして、 TiDB Cloud Dedicatedクラスターへの接続を検証してください。 -7. 接続テストが成功すると、 **Successfully made the MySQL connection**というメッセージが表示されます。 **OK**をクリックして接続設定を保存してください。 +7. 接続テストが成功すると、 **Successfully made the MySQL connection**というメッセージが表示されます。 **OK**をクリックして接続設定を保存してください。
-1. MySQL Workbenchを起動し、 **MySQL Connections**タイトルの横にある**+**をクリックします。 +1. MySQL Workbenchを起動し、 **MySQL Connections**タイトルの横にある**+**をクリックします。 ![MySQL Workbench: add new connection](/media/develop/mysql-workbench-add-new-connection.png) -2. **Setup New Connection**ダイアログで、以下の接続パラメータを設定します。 +2. **Setup New Connection**ダイアログで、以下の接続パラメータを設定します。 - - **Connection Name**：この接続に分かりやすい名前を付けてください。 - - **Hostname**：TiDB Self-ManagedクラスタのIPアドレスまたはドメイン名を入力してください。 - - **Port**：TiDB Self-Managedクラスタのポート番号を入力してください。 - - **Username**：TiDBに接続するために使用するユーザー名を入力してください。 - - **Password**： **Store in Keychain ...**をクリックし、TiDB Self-Managedクラスタへの接続に使用するパスワードを入力して、 **OK**をクリックしてパスワードを保存します。 + - **Connection Name**：この接続に分かりやすい名前を付けてください。 + - **Hostname**：TiDB Self-ManagedクラスタのIPアドレスまたはドメイン名を入力してください。 + - **Port**：TiDB Self-Managedクラスタのポート番号を入力してください。 + - **Username**：TiDBに接続するために使用するユーザー名を入力してください。 + - **Password**： **Store in Keychain ...**をクリックし、TiDB Self-Managedクラスタへの接続に使用するパスワードを入力して、 **OK**をクリックしてパスワードを保存します。 ![MySQL Workbench: store the password of TiDB Self-Managed in keychain](/media/develop/mysql-workbench-store-self-hosted-password-in-keychain.png) @@ -169,9 +169,9 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my ![MySQL Workbench: configure connection settings for TiDB Self-Managed](/media/develop/mysql-workbench-connection-config-self-hosted-parameters.png) -3. **Test Connection**をクリックして、TiDB Self-Managedクラスタへの接続を検証してください。 +3. **Test Connection**をクリックして、TiDB Self-Managedクラスタへの接続を検証してください。 -4. 接続テストが成功すると、 **Successfully made the MySQL connection**というメッセージが表示されます。 **OK**をクリックして接続設定を保存してください。 +4. 接続テストが成功すると、 **Successfully made the MySQL connection**というメッセージが表示されます。 **OK**をクリックして接続設定を保存してください。
@@ -182,8 +182,8 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my このエラーは、クエリの実行時間がタイムアウト制限を超えたことを示しています。この問題を解決するには、以下の手順でタイムアウト設定を調整してください。 -1. MySQL Workbenchを起動し、 **Workbench Preferences**ページに移動します。 -2. **SQL Editor** > **MySQL Session**セクションで、 **DBMS connection read timeout interval (in seconds)**オプションを設定します。これは、MySQL Workbenchがサーバーから切断されるまでにクエリが実行できる最大時間（秒単位）を設定します。 +1. MySQL Workbenchを起動し、 **Workbench Preferences**ページに移動します。 +2. **SQL Editor** > **MySQL Session**セクションで、 **DBMS connection read timeout interval (in seconds)**オプションを設定します。これは、MySQL Workbenchがサーバーから切断されるまでにクエリが実行できる最大時間（秒単位）を設定します。 ![MySQL Workbench: adjust timeout option in SQL Editor settings](/media/develop/mysql-workbench-adjust-sqleditor-read-timeout.jpg) @@ -191,12 +191,12 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my ## 次のステップ {#next-steps} -- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/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/)を取得します。 +- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-gui-navicat.md b/develop/dev-guide-gui-navicat.md index 0abdc7df03181..c250a773d71d2 100644 --- a/develop/dev-guide-gui-navicat.md +++ b/develop/dev-guide-gui-navicat.md @@ -18,14 +18,14 @@ TiDBはMySQL互換データベースであり、[Navicat](https://www.navicat.co このチュートリアルを完了するには、以下が必要です。 -- [Navicat Premium](https://www.navicat.com) **17.1.6**以降のバージョン。 -- Navicat Premiumの有料アカウント。 -- TiDBクラスタ。 +- [Navicat Premium](https://www.navicat.com) **17.1.6**以降のバージョン。 +- Navicat Premiumの有料アカウント。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続する {#connect-to-tidb} @@ -34,78 +34,78 @@ TiDBはMySQL互換データベースであり、[Navicat](https://www.navicat.co
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 - - **Connect With**は`Navicat`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - **Connection Type**は`Public`に設定されています。 + - **Branch**は`main`に設定されています。 + - **Connect With**は`Navicat`に設定されています。 + - お使いの環境に合った**Operating System**を選択してください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. Navicat Premiumを起動し、左上隅の**Connection**をクリックし、**Vendor Filter**リストから**PingCAP**を選択し、右側のパネルで**TiDB**をダブルクリックします。 +5. Navicat Premiumを起動し、左上隅の**Connection**をクリックし、**Vendor Filter**リストから**PingCAP**を選択し、右側のパネルで**TiDB**をダブルクリックします。 ![Navicat: add new connection](/media/develop/navicat-premium-add-new-connection.png) -6. **New Connection (TiDB)**ダイアログで、以下の接続パラメータを設定します。 +6. **New Connection (TiDB)**ダイアログで、以下の接続パラメータを設定します。 - - **Connection Name**：この接続に分かりやすい名前を付けてください。 - - **Host**: TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 - - **Port**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 - - **User Name**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 - - **Password**：手順4で作成したパスワードを入力してください。 + - **Connection Name**：この接続に分かりやすい名前を付けてください。 + - **Host**: TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 + - **Port**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 + - **User Name**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 + - **Password**：手順4で作成したパスワードを入力してください。 ![Navicat: configure connection general panel for TiDB Cloud Starter](/media/develop/navicat-premium-connection-config-serverless-general.png) -7. **SSL**タブをクリックし、 **Use SSL** 、 **Use authentication** 、 **Verify server certificate against CA**のチェックボックスを選択します。次に、 TiDB Cloud接続ダイアログから`CA`ファイルを選択し、 **CA Certificate**フィールドに貼り付けます。 +7. **SSL**タブをクリックし、 **Use SSL** 、 **Use authentication** 、 **Verify server certificate against CA**のチェックボックスを選択します。次に、 TiDB Cloud接続ダイアログから`CA`ファイルを選択し、 **CA Certificate**フィールドに貼り付けます。 ![Navicat: configure connection SSL panel for TiDB Cloud Starter](/media/develop/navicat-premium-connection-config-serverless-ssl.png) -8. **Test Connection**をクリックして、対象のTiDB Cloud StarterまたはEssentialインスタンスへの接続を検証してください。 +8. **Test Connection**をクリックして、対象のTiDB Cloud StarterまたはEssentialインスタンスへの接続を検証してください。 -9. 接続テストが成功すると、 **Connection Successful**というメッセージが表示されます。 **OK**をクリックして接続設定を完了してください。 +9. 接続テストが成功すると、 **Connection Successful**というメッセージが表示されます。 **OK**をクリックして接続設定を完了してください。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、 **Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、 **Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. Navicat Premiumを起動し、左上隅の**Connect**をクリックし、**Vendor Filter**リストから**PingCAP**を選択し、右側のパネルで**TiDB**をダブルクリックします。 +7. Navicat Premiumを起動し、左上隅の**Connect**をクリックし、**Vendor Filter**リストから**PingCAP**を選択し、右側のパネルで**TiDB**をダブルクリックします。 -8. **New Connection (TiDB)**ダイアログで、以下の接続パラメータを設定します。 +8. **New Connection (TiDB)**ダイアログで、以下の接続パラメータを設定します。 - - **Connection Name**：この接続に分かりやすい名前を付けてください。 - - **Host**: TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 - - **Port**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 - - **User Name**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 - - **Password**： TiDB Cloud Premiumインスタンスのパスワードを入力してください。 + - **Connection Name**：この接続に分かりやすい名前を付けてください。 + - **Host**: TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 + - **Port**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 + - **User Name**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 + - **Password**： TiDB Cloud Premiumインスタンスのパスワードを入力してください。 -9. **SSL**タブをクリックし、 **Use SSL**チェックボックスをオフにします。 +9. **SSL**タブをクリックし、 **Use SSL**チェックボックスをオフにします。 10. **Test Connection**をクリックして、 TiDB Cloud Premiumインスタンスへの接続を検証してください。 @@ -114,71 +114,71 @@ TiDBはMySQL互換データベースであり、[Navicat](https://www.navicat.co
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. CA証明書をダウンロードするには、 **CA cert**をクリックしてください。 +4. CA証明書をダウンロードするには、 **CA cert**をクリックしてください。 -5. Navicat Premiumを起動し、左上隅の**Connect**をクリックし、**Vendor Filter**リストから**PingCAP**を選択し、右側のパネルで**TiDB**をダブルクリックします。 +5. Navicat Premiumを起動し、左上隅の**Connect**をクリックし、**Vendor Filter**リストから**PingCAP**を選択し、右側のパネルで**TiDB**をダブルクリックします。 ![Navicat: add new connection](/media/develop/navicat-premium-add-new-connection.png) -6. **New Connection (TiDB)**ダイアログで、以下の接続パラメータを設定します。 +6. **New Connection (TiDB)**ダイアログで、以下の接続パラメータを設定します。 - - **Connection Name**：この接続に分かりやすい名前を付けてください。 - - **Host**: TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 - - **Port**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 - - **User Name**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 - - **Password**： TiDB Cloud Dedicatedクラスタのパスワードを入力してください。 + - **Connection Name**：この接続に分かりやすい名前を付けてください。 + - **Host**: TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 + - **Port**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 + - **User Name**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 + - **Password**： TiDB Cloud Dedicatedクラスタのパスワードを入力してください。 ![Navicat: configure connection general panel for TiDB Cloud Dedicated](/media/develop/navicat-premium-connection-config-dedicated-general.png) -7. **SSL**タブをクリックし、 **Use SSL** 、 **Use authentication**、 **Verify server certificate against CA**チェックボックスをオンにします。次に、手順4でダウンロードしたCAファイルを**CA Certificate**フィールドに選択します。 +7. **SSL**タブをクリックし、 **Use SSL** 、 **Use authentication**、 **Verify server certificate against CA**チェックボックスをオンにします。次に、手順4でダウンロードしたCAファイルを**CA Certificate**フィールドに選択します。 ![Navicat: configure connection SSL panel for TiDB Cloud Dedicated](/media/develop/navicat-premium-connection-config-dedicated-ssl.png) -8. TiDB Cloud Dedicatedクラスターへの接続を検証するために、**接続テストを実行します**。 +8. TiDB Cloud Dedicatedクラスターへの接続を検証するために、**接続テストを実行します**。 -9. 接続テストが成功すると、 **Connection Successful**というメッセージが表示されます。 **OK**をクリックして接続設定を完了してください。 +9. 接続テストが成功すると、 **Connection Successful**というメッセージが表示されます。 **OK**をクリックして接続設定を完了してください。
-1. Navicat Premiumを起動し、左上隅の**Connection**をクリックし、**Vendor Filter**リストから**PingCAP**を選択し、右側のパネルで**TiDB**をダブルクリックします。 +1. Navicat Premiumを起動し、左上隅の**Connection**をクリックし、**Vendor Filter**リストから**PingCAP**を選択し、右側のパネルで**TiDB**をダブルクリックします。 ![Navicat: add new connection](/media/develop/navicat-premium-add-new-connection.png) -2. **New Connection (TiDB)**ダイアログで、以下の接続パラメータを設定します。 +2. **New Connection (TiDB)**ダイアログで、以下の接続パラメータを設定します。 - - **Connection Name**：この接続に分かりやすい名前を付けてください。 - - **Host**：TiDB Self-ManagedクラスタのIPアドレスまたはドメイン名を入力してください。 - - **Port**：TiDB Self-Managedクラスタのポート番号を入力してください。 - - **User Name**：TiDBに接続するために使用するユーザー名を入力してください。 - - **Password**：TiDBに接続するために使用するパスワードを入力してください。 + - **Connection Name**：この接続に分かりやすい名前を付けてください。 + - **Host**：TiDB Self-ManagedクラスタのIPアドレスまたはドメイン名を入力してください。 + - **Port**：TiDB Self-Managedクラスタのポート番号を入力してください。 + - **User Name**：TiDBに接続するために使用するユーザー名を入力してください。 + - **Password**：TiDBに接続するために使用するパスワードを入力してください。 ![Navicat: configure connection general panel for self-hosted TiDB](/media/develop/navicat-premium-connection-config-self-hosted-general.png) -3. **Test Connection**をクリックして、TiDB Self-Managedクラスタへの接続を検証してください。 +3. **Test Connection**をクリックして、TiDB Self-Managedクラスタへの接続を検証してください。 -4. 接続テストが成功すると、 **Connection Successful**というメッセージが表示されます。 **OK**をクリックして接続設定を完了してください。 +4. 接続テストが成功すると、 **Connection Successful**というメッセージが表示されます。 **OK**をクリックして接続設定を完了してください。
## 次のステップ {#next-steps} -- [開発者ガイド](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)、[トランザクション](/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/)を取得します。 +- [開発者ガイド](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)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-gui-vscode-sqltools.md b/develop/dev-guide-gui-vscode-sqltools.md index 6114c76f7e16f..f7fb7bb6dc13c 100644 --- a/develop/dev-guide-gui-vscode-sqltools.md +++ b/develop/dev-guide-gui-vscode-sqltools.md @@ -12,24 +12,24 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code > **Note:** > -> - このチュートリアルは、 TiDB Cloud Starter、 TiDB Cloud Essential、 TiDB Cloud Premium、 TiDB Cloud Dedicated、およびTiDB Self-Managedに対応しています。 -> - このチュートリアルは、 [GitHub Codespaces](https://github.com/features/codespaces) 、Visual Studio [Visual Studio Code 開発コンテナ](https://code.visualstudio.com/docs/devcontainers/containers)[Visual Studio Code WSL](https://code.visualstudio.com/docs/remote/wsl) Code リモート開発環境でも動作します。 +> - このチュートリアルは、 TiDB Cloud Starter、 TiDB Cloud Essential、 TiDB Cloud Premium、 TiDB Cloud Dedicated、およびTiDB Self-Managedに対応しています。 +> - このチュートリアルは、 [GitHub Codespaces](https://github.com/features/codespaces) 、Visual Studio [Visual Studio Code 開発コンテナ](https://code.visualstudio.com/docs/devcontainers/containers)[Visual Studio Code WSL](https://code.visualstudio.com/docs/remote/wsl) Code リモート開発環境でも動作します。 ## 前提条件 {#prerequisites} このチュートリアルを完了するには、以下が必要です。 -- [Visual Studio Code](https://code.visualstudio.com/#alt-downloads) **1.72.0**以降のバージョン。 -- [SQLTools MySQL/MariaDB/TiDB](https://marketplace.visualstudio.com/items?itemName=mtxr.sqltools-driver-mysql)拡張機能です。インストールするには、以下のいずれかの方法を使用できます。 - - このリンクをクリックするとVS Codeが起動し、拡張機能を直接インストールできます。 - - [VS Code マーケットプレイス](https://marketplace.visualstudio.com/items?itemName=mtxr.sqltools-driver-mysql)に移動し、 **Install**をクリックします。 - - VS Code の**Extensions**タブで`mtxr.sqltools-driver-mysql`を検索して**SQLTools MySQL/MariaDB/TiDB**拡張機能を取得し、 **Install**をクリックします。 -- TiDBクラスタ。 +- [Visual Studio Code](https://code.visualstudio.com/#alt-downloads) **1.72.0**以降のバージョン。 +- [SQLTools MySQL/MariaDB/TiDB](https://marketplace.visualstudio.com/items?itemName=mtxr.sqltools-driver-mysql)拡張機能です。インストールするには、以下のいずれかの方法を使用できます。 + - このリンクをクリックするとVS Codeが起動し、拡張機能を直接インストールできます。 + - [VS Code マーケットプレイス](https://marketplace.visualstudio.com/items?itemName=mtxr.sqltools-driver-mysql)に移動し、 **Install**をクリックします。 + - VS Code の**Extensions**タブで`mtxr.sqltools-driver-mysql`を検索して**SQLTools MySQL/MariaDB/TiDB**拡張機能を取得し、 **Install**をクリックします。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続する {#connect-to-tidb} @@ -38,48 +38,48 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`VS Code`に設定されています。 + - **Connect With**は`VS Code`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > VS Code をリモート開発環境で実行している場合は、リストからリモートのオペレーティングシステムを選択してください。たとえば、Windows Subsystem for Linux (WSL) を使用している場合は、対応する Linux ディストリビューションに切り替えてください。GitHub Codespaces を使用している場合は、この操作は不要です。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. VS Codeを起動し、ナビゲーションペインで**SQLTools**拡張機能を選択します。 **CONNECTIONS**セクションで**Add New Connection**をクリックし、データベースドライバとして**TiDB**を選択します。 +5. VS Codeを起動し、ナビゲーションペインで**SQLTools**拡張機能を選択します。 **CONNECTIONS**セクションで**Add New Connection**をクリックし、データベースドライバとして**TiDB**を選択します。 ![VS Code SQLTools: add new connection](/media/develop/vsc-sqltools-add-new-connection.jpg) -6. 設定画面で、以下の接続パラメータを設定します。 +6. 設定画面で、以下の接続パラメータを設定します。 - - **Connection name**：この接続に分かりやすい名前を付けてください。 - - **Connection group**：（オプション）この接続グループに分かりやすい名前を付けます。同じグループ名を持つ接続はグループ化されます。 - - **Connect using**：**Server and Port**を選択してください。 - - **Server Address**： TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 - - **Port**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 - - **Database**：接続したいデータベースを入力してください。 - - **Username**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 - - **Password mode**: **SQLTools Driver Credentials**を選択します。 - - **MySQL driver specific options**領域で、以下のパラメータを設定します。 + - **Connection name**：この接続に分かりやすい名前を付けてください。 + - **Connection group**：（オプション）この接続グループに分かりやすい名前を付けます。同じグループ名を持つ接続はグループ化されます。 + - **Connect using**：**Server and Port**を選択してください。 + - **Server Address**： TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 + - **Port**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 + - **Database**：接続したいデータベースを入力してください。 + - **Username**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 + - **Password mode**: **SQLTools Driver Credentials**を選択します。 + - **MySQL driver specific options**領域で、以下のパラメータを設定します。 - - **Authentication Protocol**：**default**を選択してください。 - - **SSL** ： **Enabled**を選択します。TiDB Cloud Starterは安全な接続を必要とします。**SSL Options (node.TLSSocket)**領域で、 TiDB Cloud接続ダイアログの`CA`パラメーターを**Certificate Authority (CA) Certificate File**フィールドに設定してください。 + - **Authentication Protocol**：**default**を選択してください。 + - **SSL** ： **Enabled**を選択します。TiDB Cloud Starterは安全な接続を必要とします。**SSL Options (node.TLSSocket)**領域で、 TiDB Cloud接続ダイアログの`CA`パラメーターを**Certificate Authority (CA) Certificate File**フィールドに設定してください。 > **Note:** > @@ -87,53 +87,53 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code ![VS Code SQLTools: configure connection settings for TiDB Cloud Starter](/media/develop/vsc-sqltools-connection-config-serverless.jpg) -7. **TEST CONNECTION**をクリックして、対象のTiDB Cloud StarterまたはEssentialインスタンスへの接続を検証してください。 +7. **TEST CONNECTION**をクリックして、対象のTiDB Cloud StarterまたはEssentialインスタンスへの接続を検証してください。 - 1. ポップアップウィンドウで**Allow**をクリックします。 - 2. **SQLTools Driver Credentials**ダイアログで、手順4で作成したパスワードを入力します。 + 1. ポップアップウィンドウで**Allow**をクリックします。 + 2. **SQLTools Driver Credentials**ダイアログで、手順4で作成したパスワードを入力します。 ![VS Code SQLTools: enter password to connect to TiDB Cloud Starter](/media/develop/vsc-sqltools-password.jpg) -8. 接続テストが成功すると、**Successfully connected!**というメッセージが表示されます。 **SAVE CONNECTION**をクリックして、接続設定を保存してください。 +8. 接続テストが成功すると、**Successfully connected!**というメッセージが表示されます。 **SAVE CONNECTION**をクリックして、接続設定を保存してください。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、 **Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、 **Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. VS Codeを起動し、ナビゲーションペインで**SQLTools**拡張機能を選択します。 **CONNECTIONS**セクションで**Add New Connection**をクリックし、データベースドライバとして**TiDB**を選択します。 +7. VS Codeを起動し、ナビゲーションペインで**SQLTools**拡張機能を選択します。 **CONNECTIONS**セクションで**Add New Connection**をクリックし、データベースドライバとして**TiDB**を選択します。 -8. 設定画面で、以下の接続パラメータを設定します。 +8. 設定画面で、以下の接続パラメータを設定します。 - - **Connect using**：**Server and Port**を選択してください。 - - **Server Address**： TiDB Cloud接続ダイアログから`host`パラメータを入力します。 - - **Port**: TiDB Cloud接続ダイアログから`port`パラメータを入力します。 - - **Database**：接続したいデータベースを入力してください。 - - **Username**： TiDB Cloud接続ダイアログから`user`パラメータを入力してください。 - - **Password mode**: **SQLTools Driver Credentials**を選択します。 - - **MySQL driver specific options**領域で、以下のパラメータを設定します。 + - **Connect using**：**Server and Port**を選択してください。 + - **Server Address**： TiDB Cloud接続ダイアログから`host`パラメータを入力します。 + - **Port**: TiDB Cloud接続ダイアログから`port`パラメータを入力します。 + - **Database**：接続したいデータベースを入力してください。 + - **Username**： TiDB Cloud接続ダイアログから`user`パラメータを入力してください。 + - **Password mode**: **SQLTools Driver Credentials**を選択します。 + - **MySQL driver specific options**領域で、以下のパラメータを設定します。 - - **Authentication Protocol**：**default**を選択してください。 - - **SSL** ：**Disabled**を選択してください。 + - **Authentication Protocol**：**default**を選択してください。 + - **SSL** ：**Disabled**を選択してください。 -9. **TEST CONNECTION**をクリックして、 TiDB Cloud Premiumインスタンスへの接続を検証してください。 +9. **TEST CONNECTION**をクリックして、 TiDB Cloud Premiumインスタンスへの接続を検証してください。 10. **SQLTools Driver Credentials**ダイアログで、パスワードを入力します。 @@ -142,101 +142,101 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. VS Codeを起動し、ナビゲーションペインで**SQLTools**拡張機能を選択します。 **CONNECTIONS**セクションで**Add New Connection**をクリックし、データベースドライバとして**TiDB**を選択します。 +4. VS Codeを起動し、ナビゲーションペインで**SQLTools**拡張機能を選択します。 **CONNECTIONS**セクションで**Add New Connection**をクリックし、データベースドライバとして**TiDB**を選択します。 ![VS Code SQLTools: add new connection](/media/develop/vsc-sqltools-add-new-connection.jpg) -5. 設定画面で、以下の接続パラメータを設定します。 +5. 設定画面で、以下の接続パラメータを設定します。 - - **Connection name**：この接続に分かりやすい名前を付けてください。 - - **Connection group**：（オプション）この接続グループに分かりやすい名前を付けます。同じグループ名を持つ接続はグループ化されます。 - - **Connect using**：**Server and Port**を選択してください。 - - **Server Address**： TiDB Cloud接続ダイアログから`host`パラメータを入力します。 - - **Port**: TiDB Cloud接続ダイアログから`port`パラメータを入力します。 - - **Database**：接続したいデータベースを入力してください。 - - **Username**： TiDB Cloud接続ダイアログから`user`パラメータを入力してください。 - - **Password mode**: **SQLTools Driver Credentials**を選択します。 - - **MySQL driver specific options**領域で、以下のパラメータを設定します。 + - **Connection name**：この接続に分かりやすい名前を付けてください。 + - **Connection group**：（オプション）この接続グループに分かりやすい名前を付けます。同じグループ名を持つ接続はグループ化されます。 + - **Connect using**：**Server and Port**を選択してください。 + - **Server Address**： TiDB Cloud接続ダイアログから`host`パラメータを入力します。 + - **Port**: TiDB Cloud接続ダイアログから`port`パラメータを入力します。 + - **Database**：接続したいデータベースを入力してください。 + - **Username**： TiDB Cloud接続ダイアログから`user`パラメータを入力してください。 + - **Password mode**: **SQLTools Driver Credentials**を選択します。 + - **MySQL driver specific options**領域で、以下のパラメータを設定します。 - - **Authentication Protocol**：**default**を選択してください。 - - **SSL** ：**Disabled**を選択してください。 + - **Authentication Protocol**：**default**を選択してください。 + - **SSL** ：**Disabled**を選択してください。 ![VS Code SQLTools: configure connection settings for TiDB Cloud Dedicated](/media/develop/vsc-sqltools-connection-config-dedicated.jpg) -6. **TEST CONNECTION**をクリックして、 TiDB Cloud Dedicatedクラスターへの接続を検証してください。 +6. **TEST CONNECTION**をクリックして、 TiDB Cloud Dedicatedクラスターへの接続を検証してください。 - 1. ポップアップウィンドウで**Allow**をクリックします。 - 2. **SQLTools Driver Credentials**ダイアログで、 TiDB Cloud Dedicatedクラスタのパスワードを入力します。 + 1. ポップアップウィンドウで**Allow**をクリックします。 + 2. **SQLTools Driver Credentials**ダイアログで、 TiDB Cloud Dedicatedクラスタのパスワードを入力します。 ![VS Code SQLTools: enter password to connect to TiDB Cloud Dedicated](/media/develop/vsc-sqltools-password.jpg) -7. 接続テストが成功すると、**Successfully connected!**というメッセージが表示されます。 **SAVE CONNECTION**をクリックして、接続設定を保存してください。 +7. 接続テストが成功すると、**Successfully connected!**というメッセージが表示されます。 **SAVE CONNECTION**をクリックして、接続設定を保存してください。
-1. VS Codeを起動し、ナビゲーションペインで**SQLTools**拡張機能を選択します。 **CONNECTIONS**セクションで**Add New Connection**をクリックし、データベースドライバとして**TiDB**を選択します。 +1. VS Codeを起動し、ナビゲーションペインで**SQLTools**拡張機能を選択します。 **CONNECTIONS**セクションで**Add New Connection**をクリックし、データベースドライバとして**TiDB**を選択します。 ![VS Code SQLTools: add new connection](/media/develop/vsc-sqltools-add-new-connection.jpg) -2. 設定画面で、以下の接続パラメータを設定します。 +2. 設定画面で、以下の接続パラメータを設定します。 - - **Connection name**：この接続に分かりやすい名前を付けてください。 + - **Connection name**：この接続に分かりやすい名前を付けてください。 - - **Connection group**：（オプション）この接続グループに分かりやすい名前を付けます。同じグループ名を持つ接続はグループ化されます。 + - **Connection group**：（オプション）この接続グループに分かりやすい名前を付けます。同じグループ名を持つ接続はグループ化されます。 - - **Connect using**：**Server and Port**を選択してください。 + - **Connect using**：**Server and Port**を選択してください。 - - **Server Address**：TiDB Self-ManagedクラスタのIPアドレスまたはドメイン名を入力してください。 + - **Server Address**：TiDB Self-ManagedクラスタのIPアドレスまたはドメイン名を入力してください。 - - **Port**：TiDB Self-Managedクラスタのポート番号を入力してください。 + - **Port**：TiDB Self-Managedクラスタのポート番号を入力してください。 - - **Database**：接続したいデータベースを入力してください。 + - **Database**：接続したいデータベースを入力してください。 - - **Username**：TiDB Self-Managedクラスタに接続するために使用するユーザー名を入力してください。 + - **Username**：TiDB Self-Managedクラスタに接続するために使用するユーザー名を入力してください。 - - **Password mode**： + - **Password mode**： - - パスワードが空欄の場合は、 **Use empty password**を選択してください。 - - それ以外の場合は、 **SQLTools Driver Credentials**を選択してください。 + - パスワードが空欄の場合は、 **Use empty password**を選択してください。 + - それ以外の場合は、 **SQLTools Driver Credentials**を選択してください。 - - **MySQL driver specific options**領域で、以下のパラメータを設定します。 + - **MySQL driver specific options**領域で、以下のパラメータを設定します。 - - **Authentication Protocol**：**default**を選択してください。 - - **SSL** ：**Disabled**を選択してください。 + - **Authentication Protocol**：**default**を選択してください。 + - **SSL** ：**Disabled**を選択してください。 ![VS Code SQLTools: configure connection settings for TiDB Self-Managed](/media/develop/vsc-sqltools-connection-config-self-hosted.jpg) -3. **TEST CONNECTION**をクリックして、TiDB Self-Managedクラスタへの接続を検証してください。 +3. **TEST CONNECTION**をクリックして、TiDB Self-Managedクラスタへの接続を検証してください。 パスワードが空欄でない場合は、ポップアップウィンドウで**Allow**をクリックし、TiDB Self-Managedクラスタのパスワードを入力してください。 ![VS Code SQLTools: enter password to connect to TiDB Self-Managed](/media/develop/vsc-sqltools-password.jpg) -4. 接続テストが成功すると、**Successfully connected!**というメッセージが表示されます。 **SAVE CONNECTION**をクリックして、接続設定を保存してください。 +4. 接続テストが成功すると、**Successfully connected!**というメッセージが表示されます。 **SAVE CONNECTION**をクリックして、接続設定を保存してください。
## 次のステップ {#next-steps} -- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/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/)を取得します。 +- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-hybrid-oltp-and-olap-queries.md b/develop/dev-guide-hybrid-oltp-and-olap-queries.md index 1f29dea0c0bfa..2bc00cb25fd22 100644 --- a/develop/dev-guide-hybrid-oltp-and-olap-queries.md +++ b/develop/dev-guide-hybrid-oltp-and-olap-queries.md @@ -216,8 +216,8 @@ TiDBはコストベースオプティマイザー（CBO）を使用して、コ > **Note:** > -> - テーブルに別名がある場合は、ヒントでテーブル名の代わりに別名を使用します。そうしないと、ヒントは機能しません。 -> - `read_from_storage`ヒントは[共通テーブル式](/develop/dev-guide-use-common-table-expression.md)には機能しません。 +> - テーブルに別名がある場合は、ヒントでテーブル名の代わりに別名を使用します。そうしないと、ヒントは機能しません。 +> - `read_from_storage`ヒントは[共通テーブル式](/develop/dev-guide-use-common-table-expression.md)には機能しません。 ```sql WITH orders_group_by_month AS ( @@ -247,13 +247,13 @@ TiDBがTiFlashをどのように使用するかの詳細については、 [TiDB ## 続きを読む {#read-more} -- [TiDB Cloudの HTAP クイックスタート](/tidb-cloud/tidb-cloud-htap-quickstart.md) -- [TiDB Self-Managed向けHTAPクイックスタート](/quick-start-with-htap.md)と[TiDB Self-ManagedのHTAPを探索する](/explore-htap.md) -- [ウィンドウ関数](/functions-and-operators/window-functions.md) -- [TiFlashを使用する](/tiflash/tiflash-overview.md#use-tiflash) +- [TiDB Cloudの HTAP クイックスタート](/tidb-cloud/tidb-cloud-htap-quickstart.md) +- [TiDB Self-Managed向けHTAPクイックスタート](/quick-start-with-htap.md)と[TiDB Self-ManagedのHTAPを探索する](/explore-htap.md) +- [ウィンドウ関数](/functions-and-operators/window-functions.md) +- [TiFlashを使用する](/tiflash/tiflash-overview.md#use-tiflash) ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-implicit-type-conversion.md b/develop/dev-guide-implicit-type-conversion.md index 9a9c497f8374f..1ff797562f060 100644 --- a/develop/dev-guide-implicit-type-conversion.md +++ b/develop/dev-guide-implicit-type-conversion.md @@ -14,20 +14,20 @@ SQL ステートメントの述語の両側のデータ型が一致しない場 TiDB における暗黙的な型変換のルールは次のとおりです。 -- 引数の一方または両方が`NULL`の場合、比較の結果は`NULL`になります。NULL 安全な`<=>`比較演算子は変換を必要としません。NULL `<=>` NULL は`true`となるためです。 -- 比較演算の両方の引数が文字列の場合、それらは文字列として比較されます。 -- 両方の引数が整数の場合、それらは整数として比較されます。 -- 数値との比較を行わない場合、16 進値はバイナリ文字列として扱われます。 -- 引数の一方が小数値の場合、比較はもう一方の引数に依存します。もう一方の引数が小数値または整数値の場合、その引数は小数値と比較されます。もう一方の引数が浮動小数点値の場合、その引数は浮動小数点値と比較されます。 -- 引数の 1 つが`TIMESTAMP`列または`DATETIME`列で、もう 1 つの引数が定数の場合、比較が実行される前に定数はタイムスタンプに変換されます。 -- それ以外の場合、引数は浮動小数点数 ( `DOUBLE`型) として比較されます。 +- 引数の一方または両方が`NULL`の場合、比較の結果は`NULL`になります。NULL 安全な`<=>`比較演算子は変換を必要としません。NULL `<=>` NULL は`true`となるためです。 +- 比較演算の両方の引数が文字列の場合、それらは文字列として比較されます。 +- 両方の引数が整数の場合、それらは整数として比較されます。 +- 数値との比較を行わない場合、16 進値はバイナリ文字列として扱われます。 +- 引数の一方が小数値の場合、比較はもう一方の引数に依存します。もう一方の引数が小数値または整数値の場合、その引数は小数値と比較されます。もう一方の引数が浮動小数点値の場合、その引数は浮動小数点値と比較されます。 +- 引数の 1 つが`TIMESTAMP`列または`DATETIME`列で、もう 1 つの引数が定数の場合、比較が実行される前に定数はタイムスタンプに変換されます。 +- それ以外の場合、引数は浮動小数点数 ( `DOUBLE`型) として比較されます。 ## 暗黙的な型変換によって生じる結果 {#consequences-caused-by-implicit-type-conversion} 暗黙的な型変換は、人間とコンピュータのインタラクションの利便性を向上させます。ただし、アプリケーションコードでは暗黙的な型変換の使用は避けてください。以下の問題が発生する可能性があります。 -- インデックスの無効性 -- 精度の低下 +- インデックスの無効性 +- 精度の低下 ### インデックスの無効性 {#index-invalidity} @@ -80,6 +80,6 @@ SELECT * FROM `t1` WHERE `a` BETWEEN '12123123' AND '1111222211111111200000'; ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-index-best-practice.md b/develop/dev-guide-index-best-practice.md index 82753235d5411..af002ae3201e3 100644 --- a/develop/dev-guide-index-best-practice.md +++ b/develop/dev-guide-index-best-practice.md @@ -28,22 +28,22 @@ CREATE TABLE `books` ( ## インデックス作成のベストプラクティス {#best-practices-for-creating-indexes} -- 複数の列を含む結合インデックスを作成します。これは[カバリングインデックスの最適化](/explain-indexes.md#indexreader)呼ばれる最適化です。**カバリングインデックス最適化**により、TiDB はインデックス上で直接データをクエリできるようになり、パフォーマンスが向上します。 +- 複数の列を含む結合インデックスを作成します。これは[カバリングインデックスの最適化](/explain-indexes.md#indexreader)呼ばれる最適化です。**カバリングインデックス最適化**により、TiDB はインデックス上で直接データをクエリできるようになり、パフォーマンスが向上します。 -- 頻繁にクエリを実行しない列には、セカンダリインデックスを作成しないでください。セカンダリインデックスはクエリの速度向上に役立ちますが、副作用もあることに注意してください。インデックスを追加するたびに、行を挿入する際にキーと値が1つずつ追加されます。インデックスの数が増えるほど、書き込み速度が低下し、消費する領域も増加します。さらに、インデックスが多すぎるとオプティマイザの実行時間に影響し、不適切なインデックスはオプティマイザに誤動作をさせる可能性があります。そのため、インデックスの数が増えても必ずしもパフォーマンスが向上するとは限りません。 +- 頻繁にクエリを実行しない列には、セカンダリインデックスを作成しないでください。セカンダリインデックスはクエリの速度向上に役立ちますが、副作用もあることに注意してください。インデックスを追加するたびに、行を挿入する際にキーと値が1つずつ追加されます。インデックスの数が増えるほど、書き込み速度が低下し、消費する領域も増加します。さらに、インデックスが多すぎるとオプティマイザの実行時間に影響し、不適切なインデックスはオプティマイザに誤動作をさせる可能性があります。そのため、インデックスの数が増えても必ずしもパフォーマンスが向上するとは限りません。 -- アプリケーションに応じて適切なインデックスを作成してください。原則として、パフォーマンスを向上させるために、クエリで使用する列にのみインデックスを作成してください。以下のケースはインデックスの作成に適しています。 +- アプリケーションに応じて適切なインデックスを作成してください。原則として、パフォーマンスを向上させるために、クエリで使用する列にのみインデックスを作成してください。以下のケースはインデックスの作成に適しています。 - - 識別度の高い列は、フィルタリングされる行数を大幅に削減できます。例えば、個人ID番号にはインデックスを作成し、性別にはインデックスを作成しないことをお勧めします。 - - 複数の条件でクエリを実行する場合は、複合インデックスを使用します。同じ条件を持つ列は、複合インデックスの先頭に配置する必要があることに注意してください。例えば、クエリ`select* from t where c1 = 10 and c2 = 100 and c3 > 10`が頻繁に使用される場合は、複合インデックス`Index cidx (c1, c2, c3)`を作成することを検討してください。これにより、クエリ条件でスキャンするためのインデックスプレフィックスを構築できます。 + - 識別度の高い列は、フィルタリングされる行数を大幅に削減できます。例えば、個人ID番号にはインデックスを作成し、性別にはインデックスを作成しないことをお勧めします。 + - 複数の条件でクエリを実行する場合は、複合インデックスを使用します。同じ条件を持つ列は、複合インデックスの先頭に配置する必要があることに注意してください。例えば、クエリ`select* from t where c1 = 10 and c2 = 100 and c3 > 10`が頻繁に使用される場合は、複合インデックス`Index cidx (c1, c2, c3)`を作成することを検討してください。これにより、クエリ条件でスキャンするためのインデックスプレフィックスを構築できます。 -- セカンダリインデックスには意味のある名前を付けてください。会社や組織のテーブル命名規則に従うことをお勧めします。そのような命名規則がない場合は、 [インデックス命名仕様](/develop/dev-guide-object-naming-guidelines.md)ルールに従ってください。 +- セカンダリインデックスには意味のある名前を付けてください。会社や組織のテーブル命名規則に従うことをお勧めします。そのような命名規則がない場合は、 [インデックス命名仕様](/develop/dev-guide-object-naming-guidelines.md)ルールに従ってください。 ## インデックスの使用に関するベストプラクティス {#best-practices-for-using-indexes} -- インデックスはクエリを高速化するためのものなので、既存のインデックスが実際にいくつかのクエリで使用されていることを確認してください。どのクエリでも使用されていないインデックスは意味がないため、削除する必要があります。 +- インデックスはクエリを高速化するためのものなので、既存のインデックスが実際にいくつかのクエリで使用されていることを確認してください。どのクエリでも使用されていないインデックスは意味がないため、削除する必要があります。 -- 結合インデックスを使用する場合は、左プレフィックスルールに従ってください。 +- 結合インデックスを使用する場合は、左プレフィックスルールに従ってください。 `title`列と`published_at`列に新しい結合インデックスを作成するとします。 @@ -63,7 +63,7 @@ CREATE TABLE `books` ( SELECT * FROM books WHERE published_at = '2018-08-18 21:42:08'; ``` -- クエリの条件としてインデックス列を使用する場合は、計算、関数、または型変換を使用しないでください。そうしないと、TiDB オプティマイザーがインデックスを使用できなくなります。 +- クエリの条件としてインデックス列を使用する場合は、計算、関数、または型変換を使用しないでください。そうしないと、TiDB オプティマイザーがインデックスを使用できなくなります。 時間型列`published_at`に新しいインデックスを作成するとします。 @@ -95,7 +95,7 @@ CREATE TABLE `books` ( > > 現在、式インデックスは実験的機能であり、TiDB設定ファイルで有効化する必要があります。詳細については[式インデックス](/sql-statements/sql-statement-create-index.md#expression-index)を参照してください。 -- クエリ対象の列がインデックス内の列に含まれるカバーリング インデックスを使用するようにし、 `SELECT *`ステートメントですべての列をクエリすることは避けてください。 +- クエリ対象の列がインデックス内の列に含まれるカバーリング インデックスを使用するようにし、 `SELECT *`ステートメントですべての列をクエリすることは避けてください。 次のクエリでは、データを取得するためにインデックス`title_published_at_idx`をスキャンするだけで済みます。 @@ -109,19 +109,19 @@ CREATE TABLE `books` ( SELECT * FROM books WHERE title = 'database'; ``` -- クエリ条件に`!=`または`NOT IN`が含まれている場合、クエリではインデックスを使用できません。例えば、次のクエリではインデックスを使用できません。 +- クエリ条件に`!=`または`NOT IN`が含まれている場合、クエリではインデックスを使用できません。例えば、次のクエリではインデックスを使用できません。 ```sql SELECT * FROM books WHERE title != 'database'; ``` -- クエリ内の条件`LIKE`がワイルドカード`%`で始まる場合、クエリではインデックスを使用できません。例えば、次のクエリではインデックスを使用できません。 +- クエリ内の条件`LIKE`がワイルドカード`%`で始まる場合、クエリではインデックスを使用できません。例えば、次のクエリではインデックスを使用できません。 ```sql 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`インデックスを使用するように強制できます。 @@ -129,10 +129,10 @@ CREATE TABLE `books` ( SELECT * FROM t USE INDEX(id_idx) WHERE id = 1 and title = 'database'; ``` -- クエリ条件で`IN`式を使用する場合、その後に一致する値の数が 300 を超えないようにすることをお勧めします。そうしないと、実行効率が低下します。 +- クエリ条件で`IN`式を使用する場合、その後に一致する値の数が 300 を超えないようにすることをお勧めします。そうしないと、実行効率が低下します。 ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-insert-data.md b/develop/dev-guide-insert-data.md index b4d24643c0374..bf0acecf48717 100644 --- a/develop/dev-guide-insert-data.md +++ b/develop/dev-guide-insert-data.md @@ -14,20 +14,20 @@ aliases: ['/ja/tidb/stable/dev-guide-insert-data/','/ja/tidb/dev/dev-guide-inser この文書を読む前に、以下のものを準備してください。 -- [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md)、データベース[データベースを作成する](/develop/dev-guide-create-database.md)、[テーブルを作成する](/develop/dev-guide-create-table.md)、 [セカンダリインデックスを作成する](/develop/dev-guide-create-secondary-indexes.md)を読む +- [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md)、データベース[データベースを作成する](/develop/dev-guide-create-database.md)、[テーブルを作成する](/develop/dev-guide-create-table.md)、 [セカンダリインデックスを作成する](/develop/dev-guide-create-secondary-indexes.md)を読む ## 行を挿入する {#insert-rows} 複数の行のデータを挿入する方法は2つあります。たとえば、 **3人**の選手のデータを挿入する必要がある場合などです。 -- **複数行挿入ステートメント**： +- **複数行挿入ステートメント**： ```sql INSERT INTO `player` (`id`, `coins`, `goods`) VALUES (1, 1000, 1), (2, 230, 2), (3, 300, 5); ``` -- 複数の**単一行挿入ステートメント**： +- 複数の**単一行挿入ステートメント**： ```sql INSERT INTO `player` (`id`, `coins`, `goods`) VALUES (1, 1000, 1); @@ -112,9 +112,9 @@ jdbc:mysql://127.0.0.1:4000/test?user=root&useConfigs=maxPerformance&useServerPr Javaでの完全な例については、以下を参照してください。 -- [JDBCを使用してTiDBに接続する](/develop/dev-guide-sample-application-java-jdbc.md) -- [Hibernateを使用してTiDBに接続する](/develop/dev-guide-sample-application-java-hibernate.md) -- [Spring Bootを使用してTiDBに接続する](/develop/dev-guide-sample-application-java-spring-boot.md) +- [JDBCを使用してTiDBに接続する](/develop/dev-guide-sample-application-java-jdbc.md) +- [Hibernateを使用してTiDBに接続する](/develop/dev-guide-sample-application-java-hibernate.md) +- [Spring Bootを使用してTiDBに接続する](/develop/dev-guide-sample-application-java-spring-boot.md)
@@ -188,8 +188,8 @@ func buildBulkInsertSQL(amount int) string { Golangでの完全な例については、以下を参照してください。 -- [Go-MySQL-Driverを使用してTiDBに接続する](/develop/dev-guide-sample-application-golang-sql-driver.md) -- [GORMを使用してTiDBに接続する](/develop/dev-guide-sample-application-golang-gorm.md) +- [Go-MySQL-Driverを使用してTiDBに接続する](/develop/dev-guide-sample-application-golang-sql-driver.md) +- [GORMを使用してTiDBに接続する](/develop/dev-guide-sample-application-golang-gorm.md)
@@ -215,11 +215,11 @@ with get_connection(autocommit=True) as connection: Pythonでの完全な例については、以下を参照してください。 -- [PyMySQLを使用してTiDBに接続する](/develop/dev-guide-sample-application-python-pymysql.md) -- [mysqlclientを使用してTiDBに接続します](https://github.com/tidb-samples/tidb-python-mysqlclient-quickstart) -- [MySQL Connector/Pythonを使用してTiDBに接続する](/develop/dev-guide-sample-application-python-mysql-connector.md) -- [SQLAlchemyを使用してTiDBに接続する](/develop/dev-guide-sample-application-python-sqlalchemy.md) -- [peeweeを使用してTiDBに接続します](/develop/dev-guide-sample-application-python-peewee.md) +- [PyMySQLを使用してTiDBに接続する](/develop/dev-guide-sample-application-python-pymysql.md) +- [mysqlclientを使用してTiDBに接続します](https://github.com/tidb-samples/tidb-python-mysqlclient-quickstart) +- [MySQL Connector/Pythonを使用してTiDBに接続する](/develop/dev-guide-sample-application-python-mysql-connector.md) +- [SQLAlchemyを使用してTiDBに接続する](/develop/dev-guide-sample-application-python-sqlalchemy.md) +- [peeweeを使用してTiDBに接続します](/develop/dev-guide-sample-application-python-peewee.md)
@@ -234,18 +234,18 @@ TiDBに大量のデータを迅速にインポートする必要がある場合
-- データエクスポート： [Dumpling](/dumpling-overview.md)を使用して、MySQLまたはTiDBデータをローカルストレージまたはクラウドストレージにエクスポートします。TiDB Cloud StarterまたはEssentialインスタンスの場合は、 [TiDB Cloudコンソール](https://tidbcloud.com/)の[エクスポート](/tidb-cloud/serverless-export.md)機能を使用して、より効率的にデータをエクスポートすることもできます。 -- データのインポート: [TiDB Cloudコンソール](https://tidbcloud.com/)の[インポート](/tidb-cloud/import-sample-data.md)機能を使用します。 Dumplingでエクスポートしたデータをインポートしたり、ローカルの CSV ファイルをインポートしたり、[クラウドストレージからCSVファイルをTiDB Cloudにインポートする](/tidb-cloud/import-csv-files.md)ことができます。 -- データレプリケーション： [TiDB Cloudコンソール](https://tidbcloud.com/)の[TiDB Data Migration](/tidb-cloud/migrate-from-mysql-using-data-migration.md)機能を使用します。 MySQL 互換データベースを TiDB にレプリケートできます。また、ソースデータベースからのシャーディングされたインスタンスとテーブルのマージおよび移行もサポートしています。 -- データのバックアップと復元: [TiDB Cloudコンソール](https://tidbcloud.com/)の[バックアップ](/tidb-cloud/backup-and-restore.md)機能を使用します。 Dumplingと比較して、バックアップと復元はビッグ データのシナリオにより適しています。 +- データエクスポート： [Dumpling](/dumpling-overview.md)を使用して、MySQLまたはTiDBデータをローカルストレージまたはクラウドストレージにエクスポートします。TiDB Cloud StarterまたはEssentialインスタンスの場合は、 [TiDB Cloudコンソール](https://tidbcloud.com/)の[エクスポート](/tidb-cloud/serverless-export.md)機能を使用して、より効率的にデータをエクスポートすることもできます。 +- データのインポート: [TiDB Cloudコンソール](https://tidbcloud.com/)の[インポート](/tidb-cloud/import-sample-data.md)機能を使用します。 Dumplingでエクスポートしたデータをインポートしたり、ローカルの CSV ファイルをインポートしたり、[クラウドストレージからCSVファイルをTiDB Cloudにインポートする](/tidb-cloud/import-csv-files.md)ことができます。 +- データレプリケーション： [TiDB Cloudコンソール](https://tidbcloud.com/)の[TiDB Data Migration](/tidb-cloud/migrate-from-mysql-using-data-migration.md)機能を使用します。 MySQL 互換データベースを TiDB にレプリケートできます。また、ソースデータベースからのシャーディングされたインスタンスとテーブルのマージおよび移行もサポートしています。 +- データのバックアップと復元: [TiDB Cloudコンソール](https://tidbcloud.com/)の[バックアップ](/tidb-cloud/backup-and-restore.md)機能を使用します。 Dumplingと比較して、バックアップと復元はビッグ データのシナリオにより適しています。
-- データエクスポート： [Dumpling](/dumpling-overview.md) 。MySQLまたはTiDBのデータをローカルまたはAmazon S3にエクスポートできます。 -- データインポート: [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 。 **Dumpling**でエクスポートされたデータ、 **CSV**ファイル、 [Amazon AuroraからTiDBへのデータ移行](/migrate-aurora-to-tidb.md)をインポートできます。ローカル ディスクまたは Amazon S3 クラウド ディスクからのデータの読み取りもサポートします。 -- データレプリケーション： [TiDB Data Migration](/dm/dm-overview.md)MySQL、MariaDB、Amazon AuroraデータベースをTiDBにレプリケートできます。また、ソースデータベースからのシャーディングされたインスタンスとテーブルのマージおよび移行もサポートしています。 -- データのバックアップと復元:[Backup & Restore (BR)](/br/backup-and-restore-overview.md) 。 **Dumpling**と比較して、 **BR**は***ビッグデータの***シナリオにより適しています。 +- データエクスポート： [Dumpling](/dumpling-overview.md) 。MySQLまたはTiDBのデータをローカルまたはAmazon S3にエクスポートできます。 +- データインポート: [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 。 **Dumpling**でエクスポートされたデータ、 **CSV**ファイル、 [Amazon AuroraからTiDBへのデータ移行](/migrate-aurora-to-tidb.md)をインポートできます。ローカル ディスクまたは Amazon S3 クラウド ディスクからのデータの読み取りもサポートします。 +- データレプリケーション： [TiDB Data Migration](/dm/dm-overview.md)MySQL、MariaDB、Amazon AuroraデータベースをTiDBにレプリケートできます。また、ソースデータベースからのシャーディングされたインスタンスとテーブルのマージおよび移行もサポートしています。 +- データのバックアップと復元:[Backup & Restore (BR)](/br/backup-and-restore-overview.md) 。 **Dumpling**と比較して、 **BR**は***ビッグデータの***シナリオにより適しています。
@@ -276,13 +276,13 @@ ERROR 8216 (HY000): Invalid auto random: Explicit insertion on auto_random colum このエラーに対処するには、2つの解決策があります。 -- （推奨）挿入ステートメントからこの列を削除し、TiDB が初期化した`AUTO_RANDOM`の値を使用してください。これは`AUTO_RANDOM`のセマンティクスに適合します。 +- （推奨）挿入ステートメントからこの列を削除し、TiDB が初期化した`AUTO_RANDOM`の値を使用してください。これは`AUTO_RANDOM`のセマンティクスに適合します。 ```sql INSERT INTO `bookshop`.`users` (`balance`, `nickname`) VALUES (0.00, 'nicky'); ``` -- この列を指定する***必要が***あることが確実な場合は、 [`SET`ステートメント](https://docs.pingcap.com/tidb/stable/sql-statement-set-variable)を使用できます。 ユーザー変数を変更することで、挿入時に`AUTO_RANDOM`の列を指定できるようにします。 +- この列を指定する***必要が***あることが確実な場合は、 [`SET`ステートメント](https://docs.pingcap.com/tidb/stable/sql-statement-set-variable)を使用できます。 ユーザー変数を変更することで、挿入時に`AUTO_RANDOM`の列を指定できるようにします。 ```sql SET @@allow_auto_random_explicit_insert = true; @@ -295,6 +295,6 @@ TiDB では、HTAP 機能により、データの挿入時に追加の操作を ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-join-tables.md b/develop/dev-guide-join-tables.md index b8f71ee79c423..d595b8d618f29 100644 --- a/develop/dev-guide-join-tables.md +++ b/develop/dev-guide-join-tables.md @@ -210,9 +210,9 @@ TiDBはSQL構文レベルでは`LEFT SEMI JOIN table_name`サポートしてい TiDB は、次の一般的なテーブル結合アルゴリズムをサポートしています。 -- [インデックス結合](/explain-joins.md#index-join) -- [ハッシュ結合](/explain-joins.md#hash-join) -- [マージ結合](/explain-joins.md#merge-join) +- [インデックス結合](/explain-joins.md#index-join) +- [ハッシュ結合](/explain-joins.md#hash-join) +- [マージ結合](/explain-joins.md#merge-join) オプティマイザは、結合対象テーブルのデータ量などの要因に基づいて、適切な結合アルゴリズムを選択します。クエリが結合にどのアルゴリズムを使用しているかは、 `EXPLAIN`ステートメントで確認できます。 @@ -231,10 +231,10 @@ LIMIT 10; 結合アルゴリズムに関連するヒント: -- [MERGE_JOIN(t1_name [, tl_name ...])](/optimizer-hints.md#merge_joint1_name--tl_name-) -- [INL_JOIN(t1_name [, tl_name ...])](/optimizer-hints.md#inl_joint1_name--tl_name-) -- [INL_HASH_JOIN(t1_name [, tl_name ...])](/optimizer-hints.md#inl_hash_join) -- [HASH_JOIN(t1_name [, tl_name ...])](/optimizer-hints.md#hash_joint1_name--tl_name-) +- [MERGE_JOIN(t1_name [, tl_name ...])](/optimizer-hints.md#merge_joint1_name--tl_name-) +- [INL_JOIN(t1_name [, tl_name ...])](/optimizer-hints.md#inl_joint1_name--tl_name-) +- [INL_HASH_JOIN(t1_name [, tl_name ...])](/optimizer-hints.md#inl_hash_join) +- [HASH_JOIN(t1_name [, tl_name ...])](/optimizer-hints.md#hash_joint1_name--tl_name-) ## 注文を結合する {#join-orders} @@ -252,11 +252,11 @@ WHERE b.id = ba.book_id AND ba.author_id = a.id; ## 参照 {#see-also} -- [テーブル結合を使用するステートメントを説明する](/explain-joins.md) -- [結合したテーブルの再配置の概要](/join-reorder.md) +- [テーブル結合を使用するステートメントを説明する](/explain-joins.md) +- [結合したテーブルの再配置の概要](/join-reorder.md) ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-mysql-tools.md b/develop/dev-guide-mysql-tools.md index 4797b6d61f7b3..5250b341ac971 100644 --- a/develop/dev-guide-mysql-tools.md +++ b/develop/dev-guide-mysql-tools.md @@ -59,6 +59,6 @@ mysqlsh --sql mysql://root@:4000 ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-object-naming-guidelines.md b/develop/dev-guide-object-naming-guidelines.md index 0e91f99aeaa96..dce66a810d154 100644 --- a/develop/dev-guide-object-naming-guidelines.md +++ b/develop/dev-guide-object-naming-guidelines.md @@ -10,10 +10,10 @@ aliases: ['/ja/tidb/stable/dev-guide-object-naming-guidelines/','/ja/tidbcloud/d ## 一般的なルール {#general-rules} -- 意味のある英語の単語をアンダースコアで区切って使用することをお勧めします。 -- 名前には文字、数字、アンダースコアのみを使用してください。 -- `group`や`order`などの TiDB 予約語を列名として使用しないでください。 -- すべてのデータベース オブジェクトには小文字を使用することをお勧めします。 +- 意味のある英語の単語をアンダースコアで区切って使用することをお勧めします。 +- 名前には文字、数字、アンダースコアのみを使用してください。 +- `group`や`order`などの TiDB 予約語を列名として使用しないでください。 +- すべてのデータベース オブジェクトには小文字を使用することをお勧めします。 ## データベースの命名規則 {#database-naming-convention} @@ -21,33 +21,33 @@ aliases: ['/ja/tidb/stable/dev-guide-object-naming-guidelines/','/ja/tidbcloud/d ## テーブルの命名規則 {#table-naming-convention} -- 同じビジネスまたはモジュールのテーブルには同じプレフィックスを使用し、テーブル名が可能な限りわかりやすいものにします。 -- 名前内の単語はアンダースコアで区切ります。テーブル名は32文字以内にすることをお勧めします。 -- 理解を深めるために、表の目的を注釈で示すことをお勧めします。例えば： - - 一時テーブル: `tmp_t_crm_relation_0425` - - バックアップテーブル: `bak_t_crm_relation_20170425` - - 事業運営の暫定表： `tmp_st_{business code}_{creator abbreviation}_{date}` - - 会計期間の記録表: `t_crm_ec_record_YYYY{MM}{dd}` -- 異なるビジネス モジュールのテーブルごとに個別のデータベースを作成し、それに応じて注釈を追加します。 +- 同じビジネスまたはモジュールのテーブルには同じプレフィックスを使用し、テーブル名が可能な限りわかりやすいものにします。 +- 名前内の単語はアンダースコアで区切ります。テーブル名は32文字以内にすることをお勧めします。 +- 理解を深めるために、表の目的を注釈で示すことをお勧めします。例えば： + - 一時テーブル: `tmp_t_crm_relation_0425` + - バックアップテーブル: `bak_t_crm_relation_20170425` + - 事業運営の暫定表： `tmp_st_{business code}_{creator abbreviation}_{date}` + - 会計期間の記録表: `t_crm_ec_record_YYYY{MM}{dd}` +- 異なるビジネス モジュールのテーブルごとに個別のデータベースを作成し、それに応じて注釈を追加します。 ## カラムの命名規則 {#column-naming-convention} -- 列の命名は、列の実際の意味または略語です。 -- 同じ意味を持つテーブル間では同じ列名を使用することをお勧めします。 -- 列に注釈を追加し、「0: オフライン、1: オンライン」などの列挙型の名前付きの値を指定することをお勧めします。 -- ブール列の名前は`is_{description}`にすることをお勧めします。例えば、 `member`テーブルの、メンバーが有効かどうかを示す列の名前は`is_enabled`にすることができます。 -- 列名を 30 文字以上にすることは推奨されません。また、列の数は 60 未満にする必要があります。 -- `order` 、 `from` 、 `desc`などのTiDB予約語を列名として使用しないでください。キーワードが予約されているかどうかを確認するには、 [TiDBキーワード](/keywords.md)を参照してください。 +- 列の命名は、列の実際の意味または略語です。 +- 同じ意味を持つテーブル間では同じ列名を使用することをお勧めします。 +- 列に注釈を追加し、「0: オフライン、1: オンライン」などの列挙型の名前付きの値を指定することをお勧めします。 +- ブール列の名前は`is_{description}`にすることをお勧めします。例えば、 `member`テーブルの、メンバーが有効かどうかを示す列の名前は`is_enabled`にすることができます。 +- 列名を 30 文字以上にすることは推奨されません。また、列の数は 60 未満にする必要があります。 +- `order` 、 `from` 、 `desc`などのTiDB予約語を列名として使用しないでください。キーワードが予約されているかどうかを確認するには、 [TiDBキーワード](/keywords.md)を参照してください。 ## インデックスの命名規則 {#index-naming-convention} -- 主キーインデックス: `pk_{table_name_abbreviation}_{field_name_abbreviation}` -- 一意インデックス: `uk_{table_name_abbreviation}_{field_name_abbreviation}` -- 共通インデックス: `idx_{table_name_abbreviation}_{field_name_abbreviation}` -- 複数の単語を含むカラム名: 意味のある略語を使用してください +- 主キーインデックス: `pk_{table_name_abbreviation}_{field_name_abbreviation}` +- 一意インデックス: `uk_{table_name_abbreviation}_{field_name_abbreviation}` +- 共通インデックス: `idx_{table_name_abbreviation}_{field_name_abbreviation}` +- 複数の単語を含むカラム名: 意味のある略語を使用してください ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-optimistic-and-pessimistic-transaction.md b/develop/dev-guide-optimistic-and-pessimistic-transaction.md index 06916316af385..6c44387ef7afe 100644 --- a/develop/dev-guide-optimistic-and-pessimistic-transaction.md +++ b/develop/dev-guide-optimistic-and-pessimistic-transaction.md @@ -16,9 +16,9 @@ aliases: ['/ja/tidb/stable/dev-guide-optimistic-and-pessimistic-transaction/','/ 以下は[書店](/develop/dev-guide-bookshop-schema-design.md)の例です。本の購入を例に挙げ、楽観的トランザクションと悲観的トランザクションの長所と短所を示しています。本の購入プロセスは主に以下の流れで構成されます。 -1. 在庫数量を更新する -2. 注文を作成する -3. 支払いをする +1. 在庫数量を更新する +2. 注文を作成する +3. 支払いをする これらの操作はすべて成功するか、すべて失敗するかのいずれかになります。同時トランザクションが発生した場合、過剰販売が発生しないようにする必要があります。 @@ -1370,6 +1370,6 @@ mysql> SELECT * FROM users; ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-optimize-sql-best-practices.md b/develop/dev-guide-optimize-sql-best-practices.md index 630c8814875e9..cf84eeda57ab9 100644 --- a/develop/dev-guide-optimize-sql-best-practices.md +++ b/develop/dev-guide-optimize-sql-best-practices.md @@ -133,8 +133,8 @@ DELETE FROM t; TiDBはオンラインのインデックス追加操作をサポートしています。[ADD INDEX](/sql-statements/sql-statement-add-index.md)または[CREATE INDEX](/sql-statements/sql-statement-create-index.md)文でインデックスを追加できます。テーブルへのデータの読み取りと書き込みはブロックされません。以下のシステム変数を変更することで、インデックス追加操作のフェーズ`re-organize`における同時実行性とバッチサイズを調整できます。 -- [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) -- [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) +- [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) +- [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) オンラインアプリケーションへの影響を軽減するため、インデックス追加操作のデフォルトの速度は低速に設定されています。インデックス追加操作の対象列が読み取り負荷のみ、またはオンラインワークロードに直接関連していない場合は、上記の変数の値を適切に増やすことで、インデックス追加操作を高速化できます。 @@ -160,10 +160,10 @@ SET @@global.tidb_ddl_reorg_batch_size = 128; ### 参照 {#see-also} -- [高同時実行書き込みのベストプラクティス](/best-practices/high-concurrency-best-practices.md) +- [高同時実行書き込みのベストプラクティス](/best-practices/high-concurrency-best-practices.md) ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-optimize-sql-overview.md b/develop/dev-guide-optimize-sql-overview.md index 02747fca19a96..1970d3a7264d9 100644 --- a/develop/dev-guide-optimize-sql-overview.md +++ b/develop/dev-guide-optimize-sql-overview.md @@ -8,32 +8,32 @@ aliases: ['/ja/tidb/stable/dev-guide-optimize-sql-overview/','/ja/tidbcloud/dev- このドキュメントでは、TiDBにおけるSQL文のパフォーマンスを最適化する方法を紹介します。良好なパフォーマンスを得るには、まず以下の点に着目してください。 -- SQLパフォーマンスチューニング -- スキーマ設計: アプリケーションのワークロード パターンに基づいて、トランザクションの競合やホット スポットを回避するためにテーブル スキーマを変更する必要がある場合があります。 +- SQLパフォーマンスチューニング +- スキーマ設計: アプリケーションのワークロード パターンに基づいて、トランザクションの競合やホット スポットを回避するためにテーブル スキーマを変更する必要がある場合があります。 ## SQLパフォーマンスチューニング {#sql-performance-tuning} 良好な SQL ステートメントのパフォーマンスを得るには、次のガイドラインに従ってください。 -- スキャンする行数はできるだけ少なくしてください。必要なデータのみをスキャンし、余分なデータのスキャンは避けることをお勧めします。 -- 適切なインデックスを使用してください。SQLの`WHERE`句の列に対応するインデックスがあることを確認してください。インデックスがない場合、文はフルテーブルスキャンを必要とし、パフォーマンスが低下します。 -- 適切な結合タイプを使用してください。クエリに含まれるテーブルの相対的なサイズに基づいて、適切な結合タイプを選択することが重要です。通常、TiDBのコストベースオプティマイザは、パフォーマンスが最も高い結合タイプを選択します。ただし、場合によっては、より適切な結合タイプを手動で指定する必要があることもあります。 -- 適切なストレージエンジンを使用してください。OLTPとOLAPのハイブリッドワークロードには、 TiFlashエンジンが推奨されます。詳細については、 [HTAPクエリ](/develop/dev-guide-hybrid-oltp-and-olap-queries.md)を参照してください。 +- スキャンする行数はできるだけ少なくしてください。必要なデータのみをスキャンし、余分なデータのスキャンは避けることをお勧めします。 +- 適切なインデックスを使用してください。SQLの`WHERE`句の列に対応するインデックスがあることを確認してください。インデックスがない場合、文はフルテーブルスキャンを必要とし、パフォーマンスが低下します。 +- 適切な結合タイプを使用してください。クエリに含まれるテーブルの相対的なサイズに基づいて、適切な結合タイプを選択することが重要です。通常、TiDBのコストベースオプティマイザは、パフォーマンスが最も高い結合タイプを選択します。ただし、場合によっては、より適切な結合タイプを手動で指定する必要があることもあります。 +- 適切なストレージエンジンを使用してください。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} -- [TiDB Cloudの SQL性能チューニング](/tidb-cloud/tidb-cloud-sql-tuning-overview.md) -- [TiDB Self-ManagedのSQL性能チューニング](/sql-tuning-overview.md) +- [TiDB Cloudの SQL性能チューニング](/tidb-cloud/tidb-cloud-sql-tuning-overview.md) +- [TiDB Self-ManagedのSQL性能チューニング](/sql-tuning-overview.md) ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-optimize-sql.md b/develop/dev-guide-optimize-sql.md index c9e3ceebaea07..fbb33bb58d5a0 100644 --- a/develop/dev-guide-optimize-sql.md +++ b/develop/dev-guide-optimize-sql.md @@ -243,11 +243,11 @@ EXPLAIN SELECT * FROM books WHERE id = 896; ### 参照 {#see-also} -- [EXPLAIN コマンド](/explain-walkthrough.md) -- [インデックスを使用するステートメントを説明する](/explain-indexes.md) +- [EXPLAIN コマンド](/explain-walkthrough.md) +- [インデックスを使用するステートメントを説明する](/explain-indexes.md) ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-paginate-results.md b/develop/dev-guide-paginate-results.md index 696d3953d4b48..1f4cb564c56f3 100644 --- a/develop/dev-guide-paginate-results.md +++ b/develop/dev-guide-paginate-results.md @@ -337,6 +337,6 @@ ORDER BY book_id, user_id; ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-playground-gitpod.md b/develop/dev-guide-playground-gitpod.md index 63a67f09c08c9..17c05387cbbae 100644 --- a/develop/dev-guide-playground-gitpod.md +++ b/develop/dev-guide-playground-gitpod.md @@ -14,15 +14,15 @@ Gitpodは、コードを直接記述する開発環境向けのオープンソ ## クイックスタート {#quick-start} -1. TiDB アプリケーション開発用のサンプル コード リポジトリ[pingcap-inc/tidb-example-java](https://github.com/pingcap-inc/tidb-example-java)をフォークします。 +1. TiDB アプリケーション開発用のサンプル コード リポジトリ[pingcap-inc/tidb-example-java](https://github.com/pingcap-inc/tidb-example-java)をフォークします。 -2. ブラウザのアドレスバーでサンプル コード リポジトリの URL の前に`https://gitpod.io/#`付けて、Gitpod ワークスペースを起動します。 +2. ブラウザのアドレスバーでサンプル コード リポジトリの URL の前に`https://gitpod.io/#`付けて、Gitpod ワークスペースを起動します。 - - たとえば、 `https://gitpod.io/#https://github.com/pingcap-inc/tidb-example-java` 。 + - たとえば、 `https://gitpod.io/#https://github.com/pingcap-inc/tidb-example-java` 。 - - URL内で環境変数を設定できます。例： `https://gitpod.io/#targetFile=spring-jpa-hibernate_Makefile,targetMode=spring-jpa-hibernate/https://github.com/pingcap-inc/tidb-example-java` 。 + - URL内で環境変数を設定できます。例： `https://gitpod.io/#targetFile=spring-jpa-hibernate_Makefile,targetMode=spring-jpa-hibernate/https://github.com/pingcap-inc/tidb-example-java` 。 -3. ログインし、リストされているプロバイダーのいずれかを使用してワークスペースを起動します。例： `Github` 。 +3. ログインし、リストされているプロバイダーのいずれかを使用してワークスペースを起動します。例： `Github` 。 ## デフォルトのGitpod設定と環境を使用する {#use-the-default-gitpod-configuration-and-environment} @@ -170,6 +170,6 @@ Gitpodは、完全かつ自動化された、事前設定済みのクラウド ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-prepared-statement.md b/develop/dev-guide-prepared-statement.md index a05abe1a3a405..7f581c88816f5 100644 --- a/develop/dev-guide-prepared-statement.md +++ b/develop/dev-guide-prepared-statement.md @@ -8,8 +8,8 @@ aliases: ['/ja/tidb/stable/dev-guide-prepared-statement/','/ja/tidbcloud/dev-gui A [プリペアドステートメント](/sql-statements/sql-statement-prepare.md) 、パラメータのみが異なる複数のSQL文をテンプレート化します。SQL文とパラメータを分離します。これにより、SQL文の以下の側面を改善できます。 -- **セキュリティ**: パラメータとステートメントが分離されているため、 [SQLインジェクション](https://en.wikipedia.org/wiki/SQL_injection)攻撃のリスクを回避します。 -- **パフォーマンス**: ステートメントは TiDBサーバー上で事前に解析されるため、後続の実行ではパラメータのみが渡され、SQL ステートメント全体の解析、SQL ステートメント文字列の結合、およびネットワーク転送のコストが節約されます。 +- **セキュリティ**: パラメータとステートメントが分離されているため、 [SQLインジェクション](https://en.wikipedia.org/wiki/SQL_injection)攻撃のリスクを回避します。 +- **パフォーマンス**: ステートメントは TiDBサーバー上で事前に解析されるため、後続の実行ではパラメータのみが渡され、SQL ステートメント全体の解析、SQL ステートメント文字列の結合、およびネットワーク転送のコストが節約されます。 ほとんどのアプリケーションでは、SQL文を列挙できます。限られた数のSQL文で、アプリケーション全体のデータクエリを完了できます。そのため、プリペアドステートメントを使用するのがベストプラクティスです。 @@ -218,9 +218,9 @@ jdbc:mysql://127.0.0.1:4000/test?user=root&useConfigs=maxPerformance&useServerPr Javaの完全な例については、以下を参照してください。 -- [JDBC で TiDB に接続する](/develop/dev-guide-sample-application-java-jdbc.md) -- [Hibernate で TiDB に接続する](/develop/dev-guide-sample-application-java-hibernate.md) -- [Spring BootでTiDBに接続する](/develop/dev-guide-sample-application-java-spring-boot.md) +- [JDBC で TiDB に接続する](/develop/dev-guide-sample-application-java-jdbc.md) +- [Hibernate で TiDB に接続する](/develop/dev-guide-sample-application-java-hibernate.md) +- [Spring BootでTiDBに接続する](/develop/dev-guide-sample-application-java-spring-boot.md)
@@ -228,6 +228,6 @@ Javaの完全な例については、以下を参照してください。 ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-proxysql-integration.md b/develop/dev-guide-proxysql-integration.md index 051d1946cb11a..73bcbd2b10cea 100644 --- a/develop/dev-guide-proxysql-integration.md +++ b/develop/dev-guide-proxysql-integration.md @@ -10,9 +10,9 @@ aliases: ['/ja/tidb/stable/dev-guide-proxysql-integration/','/ja/tidb/dev/dev-gu TiDBとProxySQLについてさらに詳しく知りたい場合は、以下のリンクが参考になります。 -- [TiDB Cloud](https://docs.pingcap.com/tidbcloud) -- [TiDB開発者ガイド](https://docs.pingcap.com/developer/) -- [ProxySQLドキュメント](https://proxysql.com/documentation/) +- [TiDB Cloud](https://docs.pingcap.com/tidbcloud) +- [TiDB開発者ガイド](https://docs.pingcap.com/developer/) +- [ProxySQLドキュメント](https://proxysql.com/documentation/) ## ProxySQLとは何ですか？ {#what-is-proxysql} @@ -22,9 +22,9 @@ ProxySQLは、高速性、効率性、使いやすさを追求してゼロから ## ProxySQLとの連携の理由とは？ {#why-proxysql-integration} -- ProxySQL は、TiDB と対話する際のレイテンシーを短縮することで、アプリケーションのパフォーマンスを向上させるのに役立ちます。 Lambda などのサーバーレス関数を使用したスケーラブルなアプリケーションでワークロードが非決定的で急増する可能性がある場合や、大量のデータを読み込むクエリを実行するアプリケーションを構築している場合など、何を構築しているかに関係なく。 [接続プーリング](https://proxysql.com/documentation/detailed-answers-on-faq/)や[頻繁に使用されるクエリをキャッシュする](https://proxysql.com/documentation/query-cache/)可能性をキャッシュするなどの ProxySQL の強力な機能を活用することで、アプリケーションはすぐにメリットを得ることができます。 -- ProxySQL は、ProxySQL で利用できる簡単に設定できる機能である[クエリルール](#query-rules)利用することで、SQL インジェクションなどの SQL 脆弱性に対するアプリケーション セキュリティ保護の追加レイヤーとして機能します。 -- [ProxySQL](https://github.com/sysown/proxysql)と[TiDB](https://github.com/pingcap/tidb)どちらもオープンソースプロジェクトであるため、ベンダーロックインの心配がないというメリットを享受できます。 +- ProxySQL は、TiDB と対話する際のレイテンシーを短縮することで、アプリケーションのパフォーマンスを向上させるのに役立ちます。 Lambda などのサーバーレス関数を使用したスケーラブルなアプリケーションでワークロードが非決定的で急増する可能性がある場合や、大量のデータを読み込むクエリを実行するアプリケーションを構築している場合など、何を構築しているかに関係なく。 [接続プーリング](https://proxysql.com/documentation/detailed-answers-on-faq/)や[頻繁に使用されるクエリをキャッシュする](https://proxysql.com/documentation/query-cache/)可能性をキャッシュするなどの ProxySQL の強力な機能を活用することで、アプリケーションはすぐにメリットを得ることができます。 +- ProxySQL は、ProxySQL で利用できる簡単に設定できる機能である[クエリルール](#query-rules)利用することで、SQL インジェクションなどの SQL 脆弱性に対するアプリケーション セキュリティ保護の追加レイヤーとして機能します。 +- [ProxySQL](https://github.com/sysown/proxysql)と[TiDB](https://github.com/pingcap/tidb)どちらもオープンソースプロジェクトであるため、ベンダーロックインの心配がないというメリットを享受できます。 ## デプロイメントアーキテクチャ {#deployment-architecture} @@ -40,18 +40,18 @@ TiDB と ProxySQL を連携させる最も一般的な方法は、アプリケ このセクションでは、開発環境で TiDB と ProxySQL を統合する方法について説明します。ProxySQL 統合を開始するには、すべての[前提条件](#prerequisite)完了後。 -- オプション 1: [TiDB CloudとProxySQLを統合する](#option-1-integrate-tidb-cloud-with-proxysql) -- オプション 2: [TiDB Self-ManagedをProxySQLと統合する](#option-2-integrate-tidb-self-managed-with-proxysql) +- オプション 1: [TiDB CloudとProxySQLを統合する](#option-1-integrate-tidb-cloud-with-proxysql) +- オプション 2: [TiDB Self-ManagedをProxySQLと統合する](#option-2-integrate-tidb-self-managed-with-proxysql) ### 前提条件 {#prerequisites} 選択するオプションによっては、以下のパッケージが必要になる場合があります。 -- [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) -- [Docker](https://docs.docker.com/get-docker/) -- [Python 3](https://www.python.org/downloads/) -- [Docker Compose](https://docs.docker.com/compose/install/linux/) -- [MySQLクライアント](https://dev.mysql.com/doc/refman/8.0/en/mysql.html) +- [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) +- [Docker](https://docs.docker.com/get-docker/) +- [Python 3](https://www.python.org/downloads/) +- [Docker Compose](https://docs.docker.com/compose/install/linux/) +- [MySQLクライアント](https://dev.mysql.com/doc/refman/8.0/en/mysql.html) 以下のインストール手順に従ってください。 @@ -59,8 +59,8 @@ TiDB と ProxySQL を連携させる最も一般的な方法は、アプリケ
-1. Docker[ダウンロード](https://docs.docker.com/get-docker/)して起動します (Docker デスクトップには既に Docker Compose が含まれています)。 -2. Pythonと`mysql-client`をインストールするには、次のコマンドを実行してください。 +1. Docker[ダウンロード](https://docs.docker.com/get-docker/)して起動します (Docker デスクトップには既に Docker Compose が含まれています)。 +2. Pythonと`mysql-client`をインストールするには、次のコマンドを実行してください。 ```bash /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)" @@ -81,17 +81,17 @@ systemctl start docker
-- Gitをダウンロードしてインストールしてください。 +- Gitをダウンロードしてインストールしてください。 - 1. [Git Windows ダウンロード](https://git-scm.com/download/win)ページから**64 ビット Git for Windows セットアップ**パッケージをダウンロードします。 - 2. セットアップウィザードの手順に従ってGitパッケージをインストールしてください。デフォルトのインストール設定を使用する場合は、 **Next**を数回クリックしてください。 + 1. [Git Windows ダウンロード](https://git-scm.com/download/win)ページから**64 ビット Git for Windows セットアップ**パッケージをダウンロードします。 + 2. セットアップウィザードの手順に従ってGitパッケージをインストールしてください。デフォルトのインストール設定を使用する場合は、 **Next**を数回クリックしてください。 ![proxysql-windows-git-install](/media/develop/proxysql-windows-git-install.png) -- MySQL Shellをダウンロードしてインストールしてください。 +- MySQL Shellをダウンロードしてインストールしてください。 - 1. [MySQL Community Server のダウンロード](https://dev.mysql.com/downloads/mysql/)ページから MySQL インストーラーの ZIP ファイルをダウンロードします。 - 2. ファイルを解凍し、 `mysql.exe`フォルダ内の`bin` } を探します。Git Bash で`bin`フォルダのパスをシステム変数に追加し、 `PATH`変数に設定する必要があります。 + 1. [MySQL Community Server のダウンロード](https://dev.mysql.com/downloads/mysql/)ページから MySQL インストーラーの ZIP ファイルをダウンロードします。 + 2. ファイルを解凍し、 `mysql.exe`フォルダ内の`bin` } を探します。Git Bash で`bin`フォルダのパスをシステム変数に追加し、 `PATH`変数に設定する必要があります。 ```bash echo 'export PATH="(your bin folder)":$PATH' >>~/.bash_profile @@ -105,14 +105,14 @@ systemctl start docker source ~/.bash_profile ``` -- Dockerをダウンロードしてインストールしてください。 +- Dockerをダウンロードしてインストールしてください。 - 1. [Dockerのダウンロード](https://www.docker.com/products/docker-desktop/)ページからDocker Desktopインストーラーをダウンロードします。 - 2. インストーラーをダブルクリックして実行してください。インストールが完了すると、再起動を促すメッセージが表示されます。 + 1. [Dockerのダウンロード](https://www.docker.com/products/docker-desktop/)ページからDocker Desktopインストーラーをダウンロードします。 + 2. インストーラーをダブルクリックして実行してください。インストールが完了すると、再起動を促すメッセージが表示されます。 ![proxysql-windows-docker-install](/media/develop/proxysql-windows-docker-install.png) -- [Pythonのダウンロード](https://www.python.org/downloads/)ページから最新の Python 3 インストーラーをダウンロードして実行します。 +- [Pythonのダウンロード](https://www.python.org/downloads/)ページから最新の Python 3 インストーラーをダウンロードして実行します。
@@ -124,15 +124,15 @@ systemctl start docker #### ステップ1. TiDB Cloud Starterインスタンスを作成する {#step-1-create-a-tidb-cloud-starter-instance} -1. [無料のTiDB Cloud Starterインスタンスを作成します](https://docs.pingcap.com/tidbcloud/tidb-cloud-quickstart#step-1-create-a-starter-instance) TiDB Cloud Starterインスタンスに設定した root パスワードを覚えておいてください。 -2. 後で使用するために、 TiDB Cloud Starterインスタンスのホスト名、ポート番号、およびユーザー名を取得してください。 +1. [無料のTiDB Cloud Starterインスタンスを作成します](https://docs.pingcap.com/tidbcloud/tidb-cloud-quickstart#step-1-create-a-starter-instance) TiDB Cloud Starterインスタンスに設定した root パスワードを覚えておいてください。 +2. 後で使用するために、 TiDB Cloud Starterインスタンスのホスト名、ポート番号、およびユーザー名を取得してください。 - 1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックすると、その概要ページに移動します。 - 2. 概要ページで、 **[接続]**ペインを見つけて、 `Endpoint` 、 `Port` 、および`User`フィールドをコピーします。ここで`Endpoint`はTiDB Cloud Starterインスタンスのホスト名です。 + 1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックすると、その概要ページに移動します。 + 2. 概要ページで、 **[接続]**ペインを見つけて、 `Endpoint` 、 `Port` 、および`User`フィールドをコピーします。ここで`Endpoint`はTiDB Cloud Starterインスタンスのホスト名です。 #### ステップ2. ProxySQL構成ファイルを生成する {#step-2-generate-proxysql-configuration-files} -1. TiDB および ProxySQL 用の[統合例のコードリポジトリ](https://github.com/pingcap-inc/tidb-proxysql-integration)クローンを作成します。 +1. TiDB および ProxySQL 用の[統合例のコードリポジトリ](https://github.com/pingcap-inc/tidb-proxysql-integration)クローンを作成します。 @@ -162,7 +162,7 @@ systemctl start docker -2. `tidb-cloud-connect`フォルダに移動します。 +2. `tidb-cloud-connect`フォルダに移動します。 @@ -192,7 +192,7 @@ systemctl start docker -3. `proxysql-config.py`を実行してProxySQL構成ファイルを生成します。 +3. `proxysql-config.py`を実行してProxySQL構成ファイルを生成します。 @@ -236,7 +236,7 @@ systemctl start docker #### ステップ3. ProxySQLの設定 {#step-3-configure-proxysql} -1. Dockerを起動します。Dockerが既に起動している場合は、この手順をスキップしてください。 +1. Dockerを起動します。Dockerが既に起動している場合は、この手順をスキップしてください。 @@ -262,7 +262,7 @@ systemctl start docker -2. ProxySQLイメージをプルし、バックグラウンドでProxySQLコンテナを起動します。 +2. ProxySQLイメージをプルし、バックグラウンドでProxySQLコンテナを起動します。 @@ -292,7 +292,7 @@ systemctl start docker -3. ProxySQL と統合するには、次のコマンドを実行します。このコマンドは、 **ProxySQL 管理インターフェース**内で`proxysql-prepare.sql`を実行します。 +3. ProxySQL と統合するには、次のコマンドを実行します。このコマンドは、 **ProxySQL 管理インターフェース**内で`proxysql-prepare.sql`を実行します。 @@ -326,10 +326,10 @@ systemctl start docker > > `proxysql-prepare.sql`スクリプトは、以下の処理を実行します。 > - > 1. TiDB Cloud Starterインスタンスのユーザー名とパスワードを使用してユーザーを追加します。 - > 2. ユーザーを監視アカウントに割り当てます。 - > 3. TiDB Cloud Starterインスタンスをホストリストに追加します。 - > 4. ProxySQLとTiDB Cloud Starterインスタンス間の安全な接続を有効にします。 + > 1. TiDB Cloud Starterインスタンスのユーザー名とパスワードを使用してユーザーを追加します。 + > 2. ユーザーを監視アカウントに割り当てます。 + > 3. TiDB Cloud Starterインスタンスをホストリストに追加します。 + > 4. ProxySQLとTiDB Cloud Starterインスタンス間の安全な接続を有効にします。 > > より深く理解するには、 `proxysql-prepare.sql`ファイルを確認することを強くお勧めします。 ProxySQL 構成の詳細については、 [ProxySQLのドキュメント](https://proxysql.com/documentation/proxysql-configuration/)を参照してください。 @@ -353,7 +353,7 @@ systemctl start docker #### ステップ4. ProxySQL経由でTiDBに接続する {#step-4-connect-to-tidb-through-proxysql} -1. TiDB Cloud Starterインスタンスに接続するには、 `proxysql-connect.py`を実行します。スクリプトは自動的に MySQL クライアントを起動し、 [ステップ2](#step-2-generate-proxysql-configuration-files)で指定したユーザー名とパスワードを使用して接続します。 +1. TiDB Cloud Starterインスタンスに接続するには、 `proxysql-connect.py`を実行します。スクリプトは自動的に MySQL クライアントを起動し、 [ステップ2](#step-2-generate-proxysql-configuration-files)で指定したユーザー名とパスワードを使用して接続します。 @@ -383,7 +383,7 @@ systemctl start docker -2. TiDB Cloud Starterインスタンスに接続した後、次のSQL文を使用して接続を検証できます。 +2. TiDB Cloud Starterインスタンスに接続した後、次のSQL文を使用して接続を検証できます。 ```sql SELECT VERSION(); @@ -395,7 +395,7 @@ systemctl start docker > > ***デバッグの場合：*** TiDB Cloud Starterインスタンスに接続できない場合は、ファイル`tidb-cloud-connect.cnf` 、 `proxysql-prepare.sql` 、および`proxysql-connect.py`を確認してください。提供したサーバー情報が利用可能で正しいことを確認してください。 -3. コンテナを停止して削除し、前のディレクトリに戻るには、次のコマンドを実行します。 +3. コンテナを停止して削除し、前のディレクトリに戻るには、次のコマンドを実行します。 @@ -434,7 +434,7 @@ systemctl start docker 以下の手順では、ProxySQL と TiDB をそれぞれポート`6033`と`4000`にセットアップしますので、これらのポートが使用可能であることを確認してください。 -1. Dockerを起動します。Dockerが既に起動している場合は、この手順をスキップしてください。 +1. Dockerを起動します。Dockerが既に起動している場合は、この手順をスキップしてください。 @@ -460,7 +460,7 @@ systemctl start docker -2. TiDB および ProxySQL 用の[統合例のコードリポジトリ](https://github.com/pingcap-inc/tidb-proxysql-integration)クローンを作成します。 +2. TiDB および ProxySQL 用の[統合例のコードリポジトリ](https://github.com/pingcap-inc/tidb-proxysql-integration)クローンを作成します。 @@ -490,7 +490,7 @@ systemctl start docker -3. ProxySQLとTiDBの最新イメージを取得します。 +3. ProxySQLとTiDBの最新イメージを取得します。 @@ -520,7 +520,7 @@ systemctl start docker -4. TiDBとProxySQLの両方をコンテナとして実行する統合環境を起動します。 +4. TiDBとProxySQLの両方をコンテナとして実行する統合環境を起動します。 @@ -552,7 +552,7 @@ systemctl start docker ProxySQL `6033`ポートにログインするには、 `root`ユーザー名と空のパスワードを使用できます。 -5. ProxySQL経由でTiDBに接続する： +5. ProxySQL経由でTiDBに接続する： @@ -582,7 +582,7 @@ systemctl start docker -6. TiDB Self-Managedクラスタに接続した後、次のSQLステートメントを使用して接続を検証できます。 +6. TiDB Self-Managedクラスタに接続した後、次のSQLステートメントを使用して接続を検証できます。 ```sql SELECT VERSION(); @@ -590,7 +590,7 @@ systemctl start docker TiDBのバージョンが表示されていれば、ProxySQL経由でTiDBコンテナへの接続は成功しています。 -7. コンテナを停止して削除し、前のディレクトリに戻るには、次のコマンドを実行します。 +7. コンテナを停止して削除し、前のディレクトリに戻るには、次のコマンドを実行します。 @@ -643,7 +643,7 @@ ProxySQLは様々なプラットフォームにインストールできます。 #### ステップ2. ProxySQLをインストールする {#step-2-install-proxysql} -1. YUMリポジトリにProxySQLを追加する： +1. YUMリポジトリにProxySQLを追加する： ```bash cat > /etc/yum.repos.d/proxysql.repo << EOF @@ -655,13 +655,13 @@ ProxySQLは様々なプラットフォームにインストールできます。 EOF ``` -2. ProxySQLをインストールします。 +2. ProxySQLをインストールします。 ```bash yum install -y proxysql ``` -3. ProxySQLを起動します。 +3. ProxySQLを起動します。 ```bash systemctl start proxysql @@ -679,7 +679,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 ##### オプション1：管理インターフェースを使用してProxySQLを設定する {#option-1-configure-proxysql-using-the-admin-interface} -1. ProxySQLの内部設定を再構成するには、任意のMySQLコマンドラインクライアントからアクセスできる標準のProxySQL管理インターフェースを使用します（デフォルトではポート`6032`で利用可能です）。 +1. ProxySQLの内部設定を再構成するには、任意のMySQLコマンドラインクライアントからアクセスできる標準のProxySQL管理インターフェースを使用します（デフォルトではポート`6032`で利用可能です）。 ```bash mysql -u admin -padmin -h 127.0.0.1 -P6032 --prompt 'ProxySQL Admin> ' @@ -687,7 +687,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 上記の手順を実行すると、ProxySQLの管理画面が表示されます。 -2. 使用するTiDB Cloud Dedicatedクラスターを構成します。ProxySQL に 1 つまたは複数のTiDB Cloud Dedicatedクラスターを追加できます。たとえば、次のステートメントは 1 つのTiDB Cloud Dedicatedクラスターを追加します。 ``と``を、ご使用のTiDB Cloud Dedicatedエンドポイントとポートに置き換える必要があります (デフォルトのポートは`4000`です)。 +2. 使用するTiDB Cloud Dedicatedクラスターを構成します。ProxySQL に 1 つまたは複数のTiDB Cloud Dedicatedクラスターを追加できます。たとえば、次のステートメントは 1 つのTiDB Cloud Dedicatedクラスターを追加します。 ``と``を、ご使用のTiDB Cloud Dedicatedエンドポイントとポートに置き換える必要があります (デフォルトのポートは`4000`です)。 ```sql INSERT INTO mysql_servers(hostgroup_id, hostname, port) @@ -703,11 +703,11 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 > **Note:** > - > - `hostgroup_id` : ホストグループの ID を指定します。ProxySQL はホストグループを使用してクラスタを管理します。SQL トラフィックをこれらのクラスタに均等に分散するには、負荷分散が必要な複数のクラスタを同じホストグループに構成できます。読み取りと書き込みなどの目的でクラスタを区別するには、異なるホストグループを使用するように構成できます。 - > - `hostname` : TiDB Cloud Dedicatedクラスターのエンドポイント。 - > - `port` : TiDB Cloud Dedicatedクラスターのポート。 + > - `hostgroup_id` : ホストグループの ID を指定します。ProxySQL はホストグループを使用してクラスタを管理します。SQL トラフィックをこれらのクラスタに均等に分散するには、負荷分散が必要な複数のクラスタを同じホストグループに構成できます。読み取りと書き込みなどの目的でクラスタを区別するには、異なるホストグループを使用するように構成できます。 + > - `hostname` : TiDB Cloud Dedicatedクラスターのエンドポイント。 + > - `port` : TiDB Cloud Dedicatedクラスターのポート。 -3. プロキシログインユーザーを設定して、ユーザーがTiDB Cloud Dedicatedクラスタに対して適切な権限を持っていることを確認してください。以下のステートメントでは、「 *tidb cloud dedicated cluster username* 」と「 *tidb cloud dedicated cluster password* 」を、実際のTiDB Cloud Dedicatedクラスタのユーザー名とパスワードに置き換えてください。 +3. プロキシログインユーザーを設定して、ユーザーがTiDB Cloud Dedicatedクラスタに対して適切な権限を持っていることを確認してください。以下のステートメントでは、「 *tidb cloud dedicated cluster username* 」と「 *tidb cloud dedicated cluster password* 」を、実際のTiDB Cloud Dedicatedクラスタのユーザー名とパスワードに置き換えてください。 ```sql INSERT INTO mysql_users( @@ -726,17 +726,17 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 > **Note:** > - > - `username` : TiDB ユーザー名。 - > - `password` : TiDB パスワード。 - > - `active` : ユーザーがアクティブかどうかを制御します。 `1`ユーザーが**アクティブ**でログインに使用できることを示し、 `0`はユーザーが非アクティブであることを示します。 - > - `default_hostgroup` : ユーザーが使用するデフォルトのホストグループ。クエリ ルールがトラフィックを特定のホストグループに上書きしない限り、SQL トラフィックはこのホストグループに分散されます。 - > - `transaction_persistent` : `1`は、永続的なトランザクションを示します。ユーザーが接続内でトランザクションを開始すると、トランザクションがコミットまたはロールバックされるまで、すべてのクエリ ステートメントは同じホスト グループにルーティングされます。 + > - `username` : TiDB ユーザー名。 + > - `password` : TiDB パスワード。 + > - `active` : ユーザーがアクティブかどうかを制御します。 `1`ユーザーが**アクティブ**でログインに使用できることを示し、 `0`はユーザーが非アクティブであることを示します。 + > - `default_hostgroup` : ユーザーが使用するデフォルトのホストグループ。クエリ ルールがトラフィックを特定のホストグループに上書きしない限り、SQL トラフィックはこのホストグループに分散されます。 + > - `transaction_persistent` : `1`は、永続的なトランザクションを示します。ユーザーが接続内でトランザクションを開始すると、トランザクションがコミットまたはロールバックされるまで、すべてのクエリ ステートメントは同じホスト グループにルーティングされます。 ##### オプション2：設定ファイルを使用してProxySQLを設定する {#option-2-configure-proxysql-using-a-configuration-file} このオプションは、ProxySQL を構成するための代替方法としてのみ考慮してください。詳細については、 [設定ファイルによるProxySQLの設定](https://github.com/sysown/proxysql#configuring-proxysql-through-the-config-file)を参照してください。 -1. 既存のSQLiteデータベース（設定が内部的に保存されている場所）をすべて削除します。 +1. 既存のSQLiteデータベース（設定が内部的に保存されている場所）をすべて削除します。 ```bash rm /var/lib/proxysql/proxysql.db @@ -746,7 +746,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 > > SQLiteデータベースファイルを削除すると、ProxySQL管理インターフェースを使用して行った設定変更はすべて失われます。 -2. 必要に応じて設定ファイル`/etc/proxysql.cnf`を変更してください。例: +2. 必要に応じて設定ファイル`/etc/proxysql.cnf`を変更してください。例: ``` mysql_servers: @@ -775,10 +775,10 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 前述の例では： - - `address`および`port` : TiDB Cloud Dedicatedクラスターのエンドポイントとポートを指定します。 - - `username`および`password` : TiDB Cloud Dedicatedクラスターのユーザー名とパスワードを指定します。 + - `address`および`port` : TiDB Cloud Dedicatedクラスターのエンドポイントとポートを指定します。 + - `username`および`password` : TiDB Cloud Dedicatedクラスターのユーザー名とパスワードを指定します。 -3. ProxySQLを再起動してください。 +3. ProxySQLを再起動してください。 ```bash systemctl restart proxysql @@ -804,7 +804,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 > > 以下の手順では、TiDBとProxySQLのコンテナイメージを使用してクエリルールを設定します。まだプルしていない場合は、詳細な手順について[統合セクション](#option-2-integrate-tidb-self-managed-with-proxysql)を参照してください。 -1. TiDB および ProxySQL 用の[統合例のコードリポジトリ](https://github.com/pingcap-inc/tidb-proxysql-integration)クローンを作成します。前の手順ですでにクローンを作成している場合は、この手順をスキップしてください。 +1. TiDB および ProxySQL 用の[統合例のコードリポジトリ](https://github.com/pingcap-inc/tidb-proxysql-integration)クローンを作成します。前の手順ですでにクローンを作成している場合は、この手順をスキップしてください。 @@ -834,7 +834,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 -2. ProxySQLルールのサンプルディレクトリに移動します。 +2. ProxySQLルールのサンプルディレクトリに移動します。 @@ -864,7 +864,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 -3. 以下のコマンドを実行して、2つのTiDBコンテナと1つのProxySQLコンテナを起動します。 +3. 以下のコマンドを実行して、2つのTiDBコンテナと1つのProxySQLコンテナを起動します。 @@ -896,10 +896,10 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 全てが順調に進めば、以下のコンテナが起動されます。 - - ポート`4001`および`4002`を介して公開される TiDB クラスタの 2 つの Docker コンテナ - - ポート`6034`を介して公開される ProxySQL Docker コンテナが 1 つあります。 + - ポート`4001`および`4002`を介して公開される TiDB クラスタの 2 つの Docker コンテナ + - ポート`6034`を介して公開される ProxySQL Docker コンテナが 1 つあります。 -4. 2 つの TiDB コンテナでは、 `mysql`を使用して同様のスキーマ定義を持つテーブルを作成し、次に異なるデータ ( `'tidb-server01-port-4001'` 、 `'tidb-server02-port-4002'` ) を挿入してこれらのコンテナを識別します。 +4. 2 つの TiDB コンテナでは、 `mysql`を使用して同様のスキーマ定義を持つテーブルを作成し、次に異なるデータ ( `'tidb-server01-port-4001'` 、 `'tidb-server02-port-4002'` ) を挿入してこれらのコンテナを識別します。 @@ -959,7 +959,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 -5. ProxySQL を構成するには、次のコマンドを実行します。このコマンドは、ProxySQL 管理インターフェイス内で`proxysql-prepare.sql`を実行し、TiDB コンテナと ProxySQL 間のプロキシ接続を確立します。 +5. ProxySQL を構成するには、次のコマンドを実行します。このコマンドは、ProxySQL 管理インターフェイス内で`proxysql-prepare.sql`を実行し、TiDB コンテナと ProxySQL 間のプロキシ接続を確立します。 @@ -993,25 +993,25 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 > > `proxysql-prepare.sql`は以下のことを行います。 > - > - `hostgroup_id`を持つ TiDB クラスタを`0`および`1`として ProxySQL に追加します。 - > - 空のパスワードを持つユーザー`root`を追加し、 `default_hostgroup`を`0`に設定します。 - > - `^SELECT.*FOR UPDATE$`ルールを追加し、 `rule_id`を`1`として、 `destination_hostgroup`を`0`として追加します。SQL ステートメントがこのルールに一致する場合、リクエストは`hostgroup`を`0`として TiDB クラスタに転送されます。 - > - `^SELECT`ルールを追加し、 `rule_id`を`2`として、 `destination_hostgroup`を`1`として追加します。SQL ステートメントがこのルールに一致する場合、リクエストは`hostgroup`を`1`として TiDB クラスタに転送されます。 + > - `hostgroup_id`を持つ TiDB クラスタを`0`および`1`として ProxySQL に追加します。 + > - 空のパスワードを持つユーザー`root`を追加し、 `default_hostgroup`を`0`に設定します。 + > - `^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パターンがクエリルールとどのように一致するかについての追加情報は以下のとおりです。 - - ProxySQL は`rule_id`の昇順でルールを 1 つずつ照合しようとします。 - - `^`記号は SQL ステートメントの開始と一致し、 `$`終了と一致します。 + - ProxySQL は`rule_id`の昇順でルールを 1 つずつ照合しようとします。 + - `^`記号は SQL ステートメントの開始と一致し、 `$`終了と一致します。 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)を参照してください。 -6. 設定を確認し、クエリルールが正しく機能するかどうかをチェックしてください。 +6. 設定を確認し、クエリルールが正しく機能するかどうかをチェックしてください。 - 1. `root`ユーザーとしてProxySQL MySQLインターフェースにログインしてください。 + 1. `root`ユーザーとしてProxySQL MySQLインターフェースにログインしてください。 @@ -1041,9 +1041,9 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 - 2. 以下のSQL文を実行してください。 + 2. 以下のSQL文を実行してください。 - - `SELECT`ステートメントを実行します。 + - `SELECT`ステートメントを実行します。 ```sql SELECT * FROM test.tidb_server; @@ -1051,7 +1051,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 このステートメントは、ルールID `2`に一致し、ステートメントを`hostgroup 1`上の TiDB クラスタに転送します。 - - `SELECT ... FOR UPDATE`ステートメントを実行します。 + - `SELECT ... FOR UPDATE`ステートメントを実行します。 ```sql SELECT * FROM test.tidb_server FOR UPDATE; @@ -1059,7 +1059,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 このステートメントは、ルールID `1`に一致し、ステートメントを`hostgroup 0`上の TiDB クラスタに転送します。 - - トランザクションを開始する: + - トランザクションを開始する: ```sql BEGIN; @@ -1091,9 +1091,9 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 +--------------------------------+ ``` - 3. MySQLクライアントをいつでも終了するには、 `quit`と入力してEnterキーを押してください。 + 3. MySQLクライアントをいつでも終了するには、 `quit`と入力してEnterキーを押してください。 -7. コンテナを停止して削除し、前のディレクトリに戻るには、次のコマンドを実行します。 +7. コンテナを停止して削除し、前のディレクトリに戻るには、次のコマンドを実行します。 @@ -1128,6 +1128,6 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-aws-lambda.md b/develop/dev-guide-sample-application-aws-lambda.md index caf10b52a9616..ce4193c037857 100644 --- a/develop/dev-guide-sample-application-aws-lambda.md +++ b/develop/dev-guide-sample-application-aws-lambda.md @@ -10,10 +10,10 @@ TiDBはMySQL互換データベース、 [AWS Lambda関数](https://aws.amazon.co このチュートリアルでは、AWS Lambda FunctionsでTiDBとmysql2を使用して以下のタスクを実行する方法を学びます。 -- 環境をセットアップしてください。 -- mysql2を使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 -- AWS Lambda関数をデプロイ。 +- 環境をセットアップしてください。 +- mysql2を使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- AWS Lambda関数をデプロイ。 > **Note** > @@ -23,17 +23,17 @@ TiDBはMySQL互換データベース、 [AWS Lambda関数](https://aws.amazon.co このチュートリアルを完了するには、以下が必要です。 -- [Node.js **18**](https://nodejs.org/en/download/)以降。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 -- 管理者権限を持つ[AWSユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)。 -- [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) -- [AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html) +- [Node.js **18**](https://nodejs.org/en/download/)以降。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 +- 管理者権限を持つ[AWSユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)。 +- [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) +- [AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html) **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) AWSアカウントまたはユーザーをお持ちでない場合は、 [Lambda入門](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html)ガイドの手順に従って作成できます。 @@ -70,31 +70,31 @@ npm install
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックします。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックします。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Note** > > Node.jsアプリケーションでは、SSL CA証明書を提供する必要はありません。Node.jsはTLS（SSL）接続を確立する際に、デフォルトで組み込みの[Mozilla CA証明書](https://wiki.mozilla.org/CA/Included_Certificates)を使用するためです。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを作成できます。 -5. 対応する接続​​文字列をコピーして`env.json`に貼り付けてください。以下に例を示します。 +5. 対応する接続​​文字列をコピーして`env.json`に貼り付けてください。以下に例を示します。 ```json { @@ -114,26 +114,26 @@ npm install
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. 対応する接続​​文字列をコピーして`env.json`に貼り付けてください。以下に例を示します。 +7. 対応する接続​​文字列をコピーして`env.json`に貼り付けてください。以下に例を示します。 ```json { @@ -175,21 +175,21 @@ npm install ### ステップ4：コードを実行して結果を確認する {#step-4-run-the-code-and-check-the-result} -1. （前提条件） [AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html)をインストールしてください。 +1. （前提条件） [AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html)をインストールしてください。 -2. バンドルを作成する: +2. バンドルを作成する: ```bash npm run build ``` -3. サンプルLambda関数を呼び出します。 +3. サンプルLambda関数を呼び出します。 ```bash sam local invoke --env-vars env.json -e events/event.json "tidbHelloWorldFunction" ``` -4. ターミナルの出力を確認してください。出力が以下の例と似ていれば、接続は成功しています。 +4. ターミナルの出力を確認してください。出力が以下の例と似ていれば、接続は成功しています。 ```bash {"statusCode":200,"body":"{\"results\":[{\"Hello World\":\"Hello World\"}]}"} @@ -203,15 +203,15 @@ AWS Lambda関数は、 [SAM CLI](#sam-cli-deployment-recommended)または[AWS L ### SAM CLIの導入（推奨） {#sam-cli-deployment-recommended} -1. ([前提条件](#prerequisites)) [AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html)をインストールします。 +1. ([前提条件](#prerequisites)) [AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html)をインストールします。 -2. バンドルを作成する: +2. バンドルを作成する: ```bash npm run build ``` -3. [`template.yml`](https://github.com/tidb-samples/tidb-aws-lambda-quickstart/blob/main/template.yml)の環境変数を更新してください。 +3. [`template.yml`](https://github.com/tidb-samples/tidb-aws-lambda-quickstart/blob/main/template.yml)の環境変数を更新してください。 ```yaml Environment: @@ -222,7 +222,7 @@ AWS Lambda関数は、 [SAM CLI](#sam-cli-deployment-recommended)または[AWS L TIDB_PASSWORD: {password} ``` -4. AWS 環境変数を設定します ( [短期資格](https://docs.aws.amazon.com/cli/latest/userguide/cli-authentication-short-term.html)を参照)。 +4. AWS 環境変数を設定します ( [短期資格](https://docs.aws.amazon.com/cli/latest/userguide/cli-authentication-short-term.html)を参照)。 ```bash export AWS_ACCESS_KEY_ID={your_access_key_id} @@ -230,7 +230,7 @@ AWS Lambda関数は、 [SAM CLI](#sam-cli-deployment-recommended)または[AWS L export AWS_SESSION_TOKEN={your_session_token} ``` -5. AWS Lambda関数をデプロイ： +5. AWS Lambda関数をデプロイ： ```bash sam deploy --guided @@ -267,7 +267,7 @@ AWS Lambda関数は、 [SAM CLI](#sam-cli-deployment-recommended)または[AWS L ### Webコンソールの展開 {#web-console-deployment} -1. バンドルを作成する: +1. バンドルを作成する: ```bash npm run build @@ -277,22 +277,22 @@ AWS Lambda関数は、 [SAM CLI](#sam-cli-deployment-recommended)または[AWS L # dist/index.zip ``` -2. [AWS Lambdaコンソール](https://console.aws.amazon.com/lambda/home#/functions)コンソールにアクセスしてください。 +2. [AWS Lambdaコンソール](https://console.aws.amazon.com/lambda/home#/functions)コンソールにアクセスしてください。 -3. [Lambda関数の作成](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html)の手順に従って、Node.js Lambda 関数を作成します。 +3. [Lambda関数の作成](https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.html)の手順に従って、Node.js Lambda 関数を作成します。 -4. [Lambda デプロイメントパッケージ](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-package.html#gettingstarted-package-zip)の手順に従って、 `dist/index.zip`ファイルをアップロードします。 +4. [Lambda デプロイメントパッケージ](https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-package.html#gettingstarted-package-zip)の手順に従って、 `dist/index.zip`ファイルをアップロードします。 -5. Lambda 関数で[対応する接続​​文字列をコピーして設定します](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html) +5. Lambda 関数で[対応する接続​​文字列をコピーして設定します](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html) - 1. Lambda コンソールの[Functions](https://console.aws.amazon.com/lambda/home#/functions)ページで、 **Configuration**タブを選択し、 **Environment variables**を選択します。 - 2. **Edit**を選択してください。 - 3. データベースへのアクセス資格情報を追加するには、以下の手順を実行してください。 - - **Add environment variable**を選択し、 **Key**に`TIDB_HOST`と入力し、 **Value**にホスト名を入力します。 - - **Add environment variable**を選択し、 **Key**に`TIDB_PORT`と入力し、 **Value**にポート番号を入力します（デフォルトは4000です）。 - - **Add environment variable**を選択し、 **Key**に`TIDB_USER`と入力し、 **Value**にユーザー名を入力します。 - - **Add environment variable**を選択し、 **Key**に`TIDB_PASSWORD`と入力し、 **Value**にデータベース作成時に選択したパスワードを入力します。 - - **Save**を選択してください。 + 1. Lambda コンソールの[Functions](https://console.aws.amazon.com/lambda/home#/functions)ページで、 **Configuration**タブを選択し、 **Environment variables**を選択します。 + 2. **Edit**を選択してください。 + 3. データベースへのアクセス資格情報を追加するには、以下の手順を実行してください。 + - **Add environment variable**を選択し、 **Key**に`TIDB_HOST`と入力し、 **Value**にホスト名を入力します。 + - **Add environment variable**を選択し、 **Key**に`TIDB_PORT`と入力し、 **Value**にポート番号を入力します（デフォルトは4000です）。 + - **Add environment variable**を選択し、 **Key**に`TIDB_USER`と入力し、 **Value**にユーザー名を入力します。 + - **Add environment variable**を選択し、 **Key**に`TIDB_PASSWORD`と入力し、 **Value**にデータベース作成時に選択したパスワードを入力します。 + - **Save**を選択してください。 ## サンプルコードスニペット {#sample-code-snippets} @@ -384,22 +384,22 @@ console.log(rsh.affectedRows); ## 役立つメモ {#useful-notes} -- [接続プール](https://github.com/sidorares/node-mysql2#using-connection-pools)を使用してデータベース接続を管理することで、接続の頻繁な確立と切断によって発生するパフォーマンスのオーバーヘッドを削減できます。 -- SQL インジェクションを回避するには、 [プリペアドステートメント](https://github.com/sidorares/node-mysql2#using-prepared-statements)を使用することをお勧めします。 -- 複雑な SQL ステートメントがあまり含まれないシナリオでは、[Sequelize](https://sequelize.org/)、 [TypeORM](https://typeorm.io/) 、または[Prisma](https://www.prisma.io/)などの ORM フレームワークを使用すると、開発効率が大幅に向上します。 -- アプリケーション用の RESTful API を構築するには、 [AWS LambdaをAPI Gatewayで使用する](https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html)お勧めします。 -- TiDB Cloud Starterと AWS Lambda を使用した高性能アプリケーションの設計については、 [このブログ](https://aws.amazon.com/blogs/apn/designing-high-performance-applications-using-serverless-tidb-cloud-and-aws-lambda/)を参照してください。 +- [接続プール](https://github.com/sidorares/node-mysql2#using-connection-pools)を使用してデータベース接続を管理することで、接続の頻繁な確立と切断によって発生するパフォーマンスのオーバーヘッドを削減できます。 +- SQL インジェクションを回避するには、 [プリペアドステートメント](https://github.com/sidorares/node-mysql2#using-prepared-statements)を使用することをお勧めします。 +- 複雑な SQL ステートメントがあまり含まれないシナリオでは、[Sequelize](https://sequelize.org/)、 [TypeORM](https://typeorm.io/) 、または[Prisma](https://www.prisma.io/)などの ORM フレームワークを使用すると、開発効率が大幅に向上します。 +- アプリケーション用の RESTful API を構築するには、 [AWS LambdaをAPI Gatewayで使用する](https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html)お勧めします。 +- TiDB Cloud Starterと AWS Lambda を使用した高性能アプリケーションの設計については、 [このブログ](https://aws.amazon.com/blogs/apn/designing-high-performance-applications-using-serverless-tidb-cloud-and-aws-lambda/)を参照してください。 ## 次のステップ {#next-steps} -- AWS Lambda関数でTiDBを使用する方法の詳細については、 [TiDB-Lambda統合/aws-lambda-bookstoreデモ](https://github.com/pingcap/TiDB-Lambda-integration/blob/main/aws-lambda-bookstore/README.md)ご覧ください。また、AWS API Gatewayを使用して、アプリケーション用のRESTful APIを構築することもできます。 -- `mysql2`の使用法について詳しくは、 [`mysql2`のドキュメント](https://sidorares.github.io/node-mysql2/docs/documentation)ご覧ください。 -- AWS Lambda の使用方法の詳細については[AWS `Lambda`の開発者ガイド](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)ご覧ください。 -- [開発者ガイド](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)、[トランザクション](/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/)を取得します。 +- AWS Lambda関数でTiDBを使用する方法の詳細については、 [TiDB-Lambda統合/aws-lambda-bookstoreデモ](https://github.com/pingcap/TiDB-Lambda-integration/blob/main/aws-lambda-bookstore/README.md)ご覧ください。また、AWS API Gatewayを使用して、アプリケーション用のRESTful APIを構築することもできます。 +- `mysql2`の使用法について詳しくは、 [`mysql2`のドキュメント](https://sidorares.github.io/node-mysql2/docs/documentation)ご覧ください。 +- AWS Lambda の使用方法の詳細については[AWS `Lambda`の開発者ガイド](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)ご覧ください。 +- [開発者ガイド](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)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-cs.md b/develop/dev-guide-sample-application-cs.md index 5ed43d210f2e5..00193f4146fcf 100644 --- a/develop/dev-guide-sample-application-cs.md +++ b/develop/dev-guide-sample-application-cs.md @@ -12,9 +12,9 @@ C#（「シーシャープ」と発音）は、Microsoftが開発した.NETフ ## 前提条件 {#prerequisites} -- [.NET 9.0 SDK](https://dotnet.microsoft.com/en-us/download)をダウンロードしてください。 -- このチュートリアルでは`dotnet`コマンドラインツールを使用します。あるいは、Visual Studio Code IDE を使用して C# コードを操作することもできます。 -- このチュートリアルを完了するには、TiDB インスタンスへのアクセスが必要です。TiDB Cloud上の[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)インスタンスまたは[TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier/#tidb-cloud-dedicated)クラスター、あるいは`tiup playground`を使用して起動した TiDB Self-Managed クラスターを使用できます。 +- [.NET 9.0 SDK](https://dotnet.microsoft.com/en-us/download)をダウンロードしてください。 +- このチュートリアルでは`dotnet`コマンドラインツールを使用します。あるいは、Visual Studio Code IDE を使用して C# コードを操作することもできます。 +- このチュートリアルを完了するには、TiDB インスタンスへのアクセスが必要です。TiDB Cloud上の[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)インスタンスまたは[TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier/#tidb-cloud-dedicated)クラスター、あるいは`tiup playground`を使用して起動した TiDB Self-Managed クラスターを使用できます。 ## ステップ1. コンソールプロジェクトを設定する {#step-1-set-up-a-console-project} diff --git a/develop/dev-guide-sample-application-golang-gorm.md b/develop/dev-guide-sample-application-golang-gorm.md index 0f85cc10982a8..7b6e70468bc54 100644 --- a/develop/dev-guide-sample-application-golang-gorm.md +++ b/develop/dev-guide-sample-application-golang-gorm.md @@ -10,9 +10,9 @@ TiDB は MySQL 互換データベースであり、[GORM](https://gorm.io/index. このチュートリアルでは、TiDBとGORMを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- GORMを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- 環境をセットアップしてください。 +- GORMを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 > **Note:** > @@ -22,14 +22,14 @@ TiDB は MySQL 互換データベースであり、[GORM](https://gorm.io/index. このチュートリアルを完了するには、以下が必要です。 -- [Go](https://go.dev/)**1.20**以上。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- [Go](https://go.dev/)**1.20**以上。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -51,37 +51,37 @@ cd tidb-golang-gorm-quickstart
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. gateway01.ap-northeast-1.prod.aws.tidbcloud.com @@ -96,37 +96,37 @@ cd tidb-golang-gorm-quickstart TiDB Cloud Starter は安全な接続を必要とします。そのため、 `USE_SSL`の値を`true`に設定する必要があります。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -139,28 +139,28 @@ cd tidb-golang-gorm-quickstart 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -173,18 +173,18 @@ cd tidb-golang-gorm-quickstart 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' @@ -197,20 +197,20 @@ cd tidb-golang-gorm-quickstart プレースホルダー`{}`を接続パラメータに置き換え、 `USE_SSL` `false`に設定してください。TiDB をローカルで実行している場合、デフォルトのホスト アドレスは`127.0.0.1`で、パスワードは空です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
### ステップ3：コードを実行して結果を確認する {#step-3-run-the-code-and-check-the-result} -1. サンプルコードを実行するには、以下のコマンドを実行してください。 +1. サンプルコードを実行するには、以下のコマンドを実行してください。 ```shell make ``` -2. [期待される出力.txt](https://github.com/tidb-samples/tidb-golang-gorm-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 +2. [期待される出力.txt](https://github.com/tidb-samples/tidb-golang-gorm-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 ## サンプルコードスニペット {#sample-code-snippets} @@ -273,12 +273,12 @@ db.Delete(&Player{ID: "id"}) ## 次のステップ {#next-steps} -- GORM の使用法の詳細については[GORMのドキュメント](https://gorm.io/docs/index.html)と[GORMのドキュメントにあるTiDBのセクション](https://gorm.io/docs/connecting_to_the_database.html#TiDB)ご覧ください。 -- [開発者ガイド](https://docs.pingcap.com/developer/) の [データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/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/)を取得します。 +- GORM の使用法の詳細については[GORMのドキュメント](https://gorm.io/docs/index.html)と[GORMのドキュメントにあるTiDBのセクション](https://gorm.io/docs/connecting_to_the_database.html#TiDB)ご覧ください。 +- [開発者ガイド](https://docs.pingcap.com/developer/) の [データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-golang-sql-driver.md b/develop/dev-guide-sample-application-golang-sql-driver.md index f936a576d8ebc..976ed3d6f9328 100644 --- a/develop/dev-guide-sample-application-golang-sql-driver.md +++ b/develop/dev-guide-sample-application-golang-sql-driver.md @@ -10,9 +10,9 @@ TiDBはMySQL互換データベースであり、 [Go-MySQL-Driver](https://githu このチュートリアルでは、TiDBとGo-MySQL-Driverを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- Go-MySQL-Driverを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- 環境をセットアップしてください。 +- Go-MySQL-Driverを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 > **Note:** > @@ -22,14 +22,14 @@ TiDBはMySQL互換データベースであり、 [Go-MySQL-Driver](https://githu このチュートリアルを完了するには、以下が必要です。 -- [Go](https://go.dev/)**1.20**以上。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- [Go](https://go.dev/)**1.20**以上。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -51,37 +51,37 @@ cd tidb-golang-sql-driver-quickstart
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. gateway01.ap-northeast-1.prod.aws.tidbcloud.com @@ -96,37 +96,37 @@ cd tidb-golang-sql-driver-quickstart TiDB Cloud Starter は安全な接続を必要とします。そのため、 `USE_SSL`の値を`true`に設定する必要があります。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -139,28 +139,28 @@ cd tidb-golang-sql-driver-quickstart 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -173,18 +173,18 @@ cd tidb-golang-sql-driver-quickstart 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' @@ -197,20 +197,20 @@ cd tidb-golang-sql-driver-quickstart プレースホルダー`{}`を接続パラメータに置き換え、 `USE_SSL` `false`に設定してください。TiDB をローカルで実行している場合、デフォルトのホスト アドレスは`127.0.0.1`で、パスワードは空です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
### ステップ3：コードを実行して結果を確認する {#step-3-run-the-code-and-check-the-result} -1. サンプルコードを実行するには、以下のコマンドを実行してください。 +1. サンプルコードを実行するには、以下のコマンドを実行してください。 ```shell make ``` -2. [期待される出力.txt](https://github.com/tidb-samples/tidb-golang-sql-driver-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 +2. [期待される出力.txt](https://github.com/tidb-samples/tidb-golang-sql-driver-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 ## サンプルコードスニペット {#sample-code-snippets} @@ -312,23 +312,23 @@ openDB("mysql", func(db *sql.DB) { Golangドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となる。 -- データベース接続を手動で確立および解放します。 -- データベースのトランザクションを手動で管理する。 -- データ行をデータオブジェクトに手動でマッピングします。 +- データベース接続を手動で確立および解放します。 +- データベースのトランザクションを手動で管理する。 +- データ行をデータオブジェクトに手動でマッピングします。 複雑なSQL文を書く必要がない限り、 [GORM](/develop/dev-guide-sample-application-golang-gorm.md)などの[ORM](https://en.wikipedia.org/w/index.php?title=Object-relational_mapping)フレームワークを使用して開発することをお勧めします。ORMフレームワークは、次のような点で役立ちます。 -- 接続とトランザクションを管理するための[定型コード](https://en.wikipedia.org/wiki/Boilerplate_code)を削減します。 -- 多数のSQL文の代わりに、データオブジェクトを使用してデータを操作します。 +- 接続とトランザクションを管理するための[定型コード](https://en.wikipedia.org/wiki/Boilerplate_code)を削減します。 +- 多数のSQL文の代わりに、データオブジェクトを使用してデータを操作します。 ## 次のステップ {#next-steps} -- 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/)を取得します。 +- 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/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-java-hibernate.md b/develop/dev-guide-sample-application-java-hibernate.md index b61ca891a464c..36b29955c92a8 100644 --- a/develop/dev-guide-sample-application-java-hibernate.md +++ b/develop/dev-guide-sample-application-java-hibernate.md @@ -10,9 +10,9 @@ TiDBはMySQL互換データベースであり、[Hibernate](https://hibernate.or このチュートリアルでは、TiDBとHibernateを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- Hibernateを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- 環境をセットアップしてください。 +- Hibernateを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 > **Note:** > @@ -22,15 +22,15 @@ TiDBはMySQL互換データベースであり、[Hibernate](https://hibernate.or このチュートリアルを完了するには、以下が必要です。 -- **Java Development Kit (JDK) 17**以降が必要です。業務要件や個人のニーズに応じて、 [OpenJDK](https://openjdk.org/)または[Oracle JDK](https://www.oracle.com/hk/java/technologies/downloads/)を選択できます。 -- [Maven](https://maven.apache.org/install.html)**3.8**以上。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- **Java Development Kit (JDK) 17**以降が必要です。業務要件や個人のニーズに応じて、 [OpenJDK](https://openjdk.org/)または[Oracle JDK](https://www.oracle.com/hk/java/technologies/downloads/)を選択できます。 +- [Maven](https://maven.apache.org/install.html)**3.8**以上。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -52,37 +52,37 @@ cd tidb-java-hibernate-quickstart
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +5. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -6. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +6. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' # e.g. gateway01.ap-northeast-1.prod.aws.tidbcloud.com @@ -97,37 +97,37 @@ cd tidb-java-hibernate-quickstart TiDB Cloud Starter は安全な接続を必要とします。そのため、 `USE_SSL`の値を`true`に設定する必要があります。 -7. `env.sh`ファイルを保存します。 +7. `env.sh`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +7. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -8. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +8. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -140,28 +140,28 @@ cd tidb-java-hibernate-quickstart 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -9. `env.sh`ファイルを保存します。 +9. `env.sh`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -5. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +5. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -174,18 +174,18 @@ cd tidb-java-hibernate-quickstart 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -6. `env.sh`ファイルを保存します。 +6. `env.sh`ファイルを保存します。
-1. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +1. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -2. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +2. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' @@ -198,20 +198,20 @@ cd tidb-java-hibernate-quickstart プレースホルダー`{}`を接続パラメータに置き換え、 `USE_SSL` `false`に設定してください。TiDB をローカルで実行している場合、デフォルトのホスト アドレスは`127.0.0.1`で、パスワードは空です。 -3. `env.sh`ファイルを保存します。 +3. `env.sh`ファイルを保存します。
### ステップ3：コードを実行して結果を確認する {#step-3-run-the-code-and-check-the-result} -1. サンプルコードを実行するには、以下のコマンドを実行してください。 +1. サンプルコードを実行するには、以下のコマンドを実行してください。 ```shell make ``` -2. [期待される出力.txt](https://github.com/tidb-samples/tidb-java-hibernate-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 +2. [期待される出力.txt](https://github.com/tidb-samples/tidb-java-hibernate-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 ## サンプルコードスニペット {#sample-code-snippets} @@ -331,13 +331,13 @@ SET GLOBAL tidb_enable_check_constraint=ON; ## 次のステップ {#next-steps} -- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/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/)を取得します。 -- Java開発者向けのコース「 [JavaからTiDBを操作する](https://eng.edu.pingcap.com/catalog/info/id:212)を通じて学習します。 +- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/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/)を取得します。 +- Java開発者向けのコース「 [JavaからTiDBを操作する](https://eng.edu.pingcap.com/catalog/info/id:212)を通じて学習します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-java-jdbc.md b/develop/dev-guide-sample-application-java-jdbc.md index 53237a4ef1777..ab2427660d980 100644 --- a/develop/dev-guide-sample-application-java-jdbc.md +++ b/develop/dev-guide-sample-application-java-jdbc.md @@ -10,28 +10,28 @@ TiDBはMySQL互換データベースであり、JDBC（Java Database Connectivit このチュートリアルでは、TiDBとJDBCを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- JDBCを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- 環境をセットアップしてください。 +- JDBCを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 > **Note:** > -> - このチュートリアルは、 TiDB Cloud Starter、 TiDB Cloud Essential、 TiDB Cloud Premium、 TiDB Cloud Dedicated、およびTiDB Self-Managedに対応しています。 -> - TiDB v7.4 以降、 `connectionCollation`が構成されておらず、JDBC URL で`characterEncoding`が構成されていないか、または`UTF-8`に設定されている場合、JDBC 接続で使用される照合順序は JDBC ドライバーのバージョンによって異なります。詳細については、 [JDBC接続で使用される照合順序](/faq/sql-faq.md#collation-used-in-jdbc-connections)を参照してください。 +> - このチュートリアルは、 TiDB Cloud Starter、 TiDB Cloud Essential、 TiDB Cloud Premium、 TiDB Cloud Dedicated、およびTiDB Self-Managedに対応しています。 +> - TiDB v7.4 以降、 `connectionCollation`が構成されておらず、JDBC URL で`characterEncoding`が構成されていないか、または`UTF-8`に設定されている場合、JDBC 接続で使用される照合順序は JDBC ドライバーのバージョンによって異なります。詳細については、 [JDBC接続で使用される照合順序](/faq/sql-faq.md#collation-used-in-jdbc-connections)を参照してください。 ## 前提条件 {#prerequisites} このチュートリアルを完了するには、以下が必要です。 -- **Java Development Kit (JDK) 17**以降が必要です。業務要件や個人のニーズに応じて、 [OpenJDK](https://openjdk.org/)または[Oracle JDK](https://www.oracle.com/hk/java/technologies/downloads/)を選択できます。 -- [Maven](https://maven.apache.org/install.html)**3.8**以上。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- **Java Development Kit (JDK) 17**以降が必要です。業務要件や個人のニーズに応じて、 [OpenJDK](https://openjdk.org/)または[Oracle JDK](https://www.oracle.com/hk/java/technologies/downloads/)を選択できます。 +- [Maven](https://maven.apache.org/install.html)**3.8**以上。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -53,37 +53,37 @@ cd tidb-java-jdbc-quickstart
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +5. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -6. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +6. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' # e.g. gateway01.ap-northeast-1.prod.aws.tidbcloud.com @@ -98,38 +98,38 @@ cd tidb-java-jdbc-quickstart TiDB Cloud Starter は安全な接続を必要とします。そのため、 `USE_SSL`の値を`true`に設定する必要があります。 -7. `env.sh`ファイルを保存します。 +7. `env.sh`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +7. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -8. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +8. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -142,29 +142,29 @@ cd tidb-java-jdbc-quickstart 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -9. `env.sh`ファイルを保存します。 +9. `env.sh`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -5. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +5. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -177,18 +177,18 @@ cd tidb-java-jdbc-quickstart 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -6. `env.sh`ファイルを保存します。 +6. `env.sh`ファイルを保存します。
-1. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +1. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -2. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +2. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' @@ -201,20 +201,20 @@ cd tidb-java-jdbc-quickstart プレースホルダー`{}`を接続パラメータに置き換え、 `USE_SSL` `false`に設定してください。TiDB をローカルで実行している場合、デフォルトのホスト アドレスは`127.0.0.1`で、パスワードは空です。 -3. `env.sh`ファイルを保存します。 +3. `env.sh`ファイルを保存します。
### ステップ3：コードを実行して結果を確認する {#step-3-run-the-code-and-check-the-result} -1. サンプルコードを実行するには、以下のコマンドを実行してください。 +1. サンプルコードを実行するには、以下のコマンドを実行してください。 ```shell make ``` -2. [期待される出力.txt](https://github.com/tidb-samples/tidb-java-jdbc-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 +2. [期待される出力.txt](https://github.com/tidb-samples/tidb-java-jdbc-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 ## サンプルコードスニペット {#sample-code-snippets} @@ -321,14 +321,14 @@ public void deletePlayer(String id) throws SQLException { Javaドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となる。 -- データベース接続を手動で確立および解放します。 -- データベースのトランザクションを手動で管理する。 -- データ行をデータオブジェクトに手動でマッピングします。 +- データベース接続を手動で確立および解放します。 +- データベースのトランザクションを手動で管理する。 +- データ行をデータオブジェクトに手動でマッピングします。 複雑なSQL文を書く必要がない限り、 [Hibernate](/develop/dev-guide-sample-application-java-hibernate.md)、 [MyBatis](/develop/dev-guide-sample-application-java-mybatis.md) 、 [Spring Data JPA](/develop/dev-guide-sample-application-java-spring-boot.md)などの[ORM](https://en.wikipedia.org/w/index.php?title=Object-relational_mapping)フレームワークを開発に利用することをお勧めします。これにより、以下のようなメリットが得られます。 -- 接続とトランザクションを管理するための[定型コード](https://en.wikipedia.org/wiki/Boilerplate_code)を削減します。 -- 多数のSQL文の代わりに、データオブジェクトを使用してデータを操作します。 +- 接続とトランザクションを管理するための[定型コード](https://en.wikipedia.org/wiki/Boilerplate_code)を削減します。 +- 多数のSQL文の代わりに、データオブジェクトを使用してデータを操作します。 ### MySQLとの互換性 {#mysql-compatibility} @@ -336,20 +336,20 @@ MySQL では、 `DECIMAL`列にデータを挿入する際に、小数点以下 TiDB v8.5.3以前のバージョンでは： -- 小数点以下の桁数が定義されたスケールを超えているが72を超えていない場合、TiDBは余分な桁を自動的に切り捨て、切り捨てられたデータを正常に挿入します。 -- ただし、小数点以下の桁数が72を超えると、挿入は失敗し、エラーが返されます。 +- 小数点以下の桁数が定義されたスケールを超えているが72を超えていない場合、TiDBは余分な桁を自動的に切り捨て、切り捨てられたデータを正常に挿入します。 +- ただし、小数点以下の桁数が72を超えると、挿入は失敗し、エラーが返されます。 TiDB v8.5.4以降、TiDBはMySQLの動作に準拠するようになりました。つまり、小数点以下の桁数がいくつ多くても、余分な桁を自動的に切り捨て、切り捨てられたデータを正常に挿入します。 ## 次のステップ {#next-steps} -- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/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/)を取得します。 -- Java開発者向けのコース「 [JavaからTiDBを操作する](https://eng.edu.pingcap.com/catalog/info/id:212)を通じて学習します。 +- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/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/)を取得します。 +- Java開発者向けのコース「 [JavaからTiDBを操作する](https://eng.edu.pingcap.com/catalog/info/id:212)を通じて学習します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-java-mybatis.md b/develop/dev-guide-sample-application-java-mybatis.md index 83ca2c6440865..9018384121d36 100644 --- a/develop/dev-guide-sample-application-java-mybatis.md +++ b/develop/dev-guide-sample-application-java-mybatis.md @@ -10,9 +10,9 @@ TiDBはMySQL互換のデータベースであり、 [MyBatis](https://mybatis.or このチュートリアルでは、TiDBとMyBatisを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- MyBatisを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- 環境をセットアップしてください。 +- MyBatisを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 > **Note:** > @@ -22,15 +22,15 @@ TiDBはMySQL互換のデータベースであり、 [MyBatis](https://mybatis.or このチュートリアルを完了するには、以下が必要です。 -- **Java Development Kit (JDK) 17**以降が必要です。業務要件や個人のニーズに応じて、 [OpenJDK](https://openjdk.org/)または[Oracle JDK](https://www.oracle.com/hk/java/technologies/downloads/)を選択できます。 -- [Maven](https://maven.apache.org/install.html)**3.8**以上。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- **Java Development Kit (JDK) 17**以降が必要です。業務要件や個人のニーズに応じて、 [OpenJDK](https://openjdk.org/)または[Oracle JDK](https://www.oracle.com/hk/java/technologies/downloads/)を選択できます。 +- [Maven](https://maven.apache.org/install.html)**3.8**以上。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -52,37 +52,37 @@ cd tidb-java-mybatis-quickstart
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +5. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -6. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +6. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' # e.g. gateway01.ap-northeast-1.prod.aws.tidbcloud.com @@ -97,37 +97,37 @@ cd tidb-java-mybatis-quickstart TiDB Cloud Starter は安全な接続を必要とします。そのため、 `USE_SSL`の値を`true`に設定する必要があります。 -7. `env.sh`ファイルを保存します。 +7. `env.sh`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +7. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -8. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +8. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -140,28 +140,28 @@ cd tidb-java-mybatis-quickstart 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -9. `env.sh`ファイルを保存します。 +9. `env.sh`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -5. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +5. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -174,18 +174,18 @@ cd tidb-java-mybatis-quickstart 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -6. `env.sh`ファイルを保存します。 +6. `env.sh`ファイルを保存します。
-1. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +1. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -2. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +2. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' @@ -198,20 +198,20 @@ cd tidb-java-mybatis-quickstart プレースホルダー`{}`を接続パラメータに置き換え、 `USE_SSL` `false`に設定してください。TiDB をローカルで実行している場合、デフォルトのホスト アドレスは`127.0.0.1`で、パスワードは空です。 -3. `env.sh`ファイルを保存します。 +3. `env.sh`ファイルを保存します。
### ステップ3：コードを実行して結果を確認する {#step-3-run-the-code-and-check-the-result} -1. サンプルコードを実行するには、以下のコマンドを実行してください。 +1. サンプルコードを実行するには、以下のコマンドを実行してください。 ```shell make ``` -2. [期待される出力.txt](https://github.com/tidb-samples/tidb-java-mybatis-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 +2. [期待される出力.txt](https://github.com/tidb-samples/tidb-java-mybatis-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 ## サンプルコードスニペット {#sample-code-snippets} @@ -345,13 +345,13 @@ public SqlSessionFactory getSessionFactory() { ## 次のステップ {#next-steps} -- MyBatis の使用法について詳しくは[MyBatisのドキュメント](http://www.mybatis.org/mybatis-3/)ご覧ください。 -- [開発者ガイド](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)、[トランザクション](/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/)を取得します。 -- Java開発者向けのコース「 [JavaからTiDBを操作する](https://eng.edu.pingcap.com/catalog/info/id:212)を通じて学習します。 +- MyBatis の使用法について詳しくは[MyBatisのドキュメント](http://www.mybatis.org/mybatis-3/)ご覧ください。 +- [開発者ガイド](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)、[トランザクション](/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/)を取得します。 +- Java開発者向けのコース「 [JavaからTiDBを操作する](https://eng.edu.pingcap.com/catalog/info/id:212)を通じて学習します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-java-spring-boot.md b/develop/dev-guide-sample-application-java-spring-boot.md index 2d291c5141c83..02f0a6b25e190 100644 --- a/develop/dev-guide-sample-application-java-spring-boot.md +++ b/develop/dev-guide-sample-application-java-spring-boot.md @@ -10,9 +10,9 @@ aliases: ['/ja/tidbcloud/dev-guide-sample-application-spring-boot','/ja/tidb/dev このチュートリアルでは、TiDBを[Spring Data JPA](https://spring.io/projects/spring-data-jpa)およびJPAプロバイダとしての[Hibernate](https://hibernate.org/orm/)と組み合わせて使用​​し、以下のタスクを実行する方法を学びます。 -- 環境をセットアップしてください。 -- HibernateとSpring Data JPAを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- 環境をセットアップしてください。 +- HibernateとSpring Data JPAを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 > **Note:** > @@ -22,15 +22,15 @@ aliases: ['/ja/tidbcloud/dev-guide-sample-application-spring-boot','/ja/tidb/dev このチュートリアルを完了するには、以下が必要です。 -- **Java Development Kit (JDK) 17**以降が必要です。業務要件や個人のニーズに応じて、 [OpenJDK](https://openjdk.org/)または[Oracle JDK](https://www.oracle.com/hk/java/technologies/downloads/)を選択できます。 -- [Maven](https://maven.apache.org/install.html)**3.8**以上。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- **Java Development Kit (JDK) 17**以降が必要です。業務要件や個人のニーズに応じて、 [OpenJDK](https://openjdk.org/)または[Oracle JDK](https://www.oracle.com/hk/java/technologies/downloads/)を選択できます。 +- [Maven](https://maven.apache.org/install.html)**3.8**以上。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -52,37 +52,37 @@ cd tidb-java-springboot-jpa-quickstart
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +5. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -6. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +6. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' # e.g. gateway01.ap-northeast-1.prod.aws.tidbcloud.com @@ -97,37 +97,37 @@ cd tidb-java-springboot-jpa-quickstart TiDB Cloud Starter は安全な接続を必要とします。そのため、 `USE_SSL`の値を`true`に設定する必要があります。 -7. `env.sh`ファイルを保存します。 +7. `env.sh`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +7. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -8. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +8. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -140,28 +140,28 @@ cd tidb-java-springboot-jpa-quickstart 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -9. `env.sh`ファイルを保存します。 +9. `env.sh`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -5. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +5. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -174,18 +174,18 @@ cd tidb-java-springboot-jpa-quickstart 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -6. `env.sh`ファイルを保存します。 +6. `env.sh`ファイルを保存します。
-1. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 +1. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 ```shell cp env.sh.example env.sh ``` -2. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +2. 対応する接続​​文字列`env.sh`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```shell export TIDB_HOST='{host}' @@ -198,26 +198,26 @@ cd tidb-java-springboot-jpa-quickstart プレースホルダー`{}`を接続パラメータに置き換え、 `USE_SSL` `false`に設定してください。TiDB をローカルで実行している場合、デフォルトのホスト アドレスは`127.0.0.1`で、パスワードは空です。 -3. `env.sh`ファイルを保存します。 +3. `env.sh`ファイルを保存します。
### ステップ3：コードを実行して結果を確認する {#step-3-run-the-code-and-check-the-result} -1. サンプルコードを実行するには、以下のコマンドを実行してください。 +1. サンプルコードを実行するには、以下のコマンドを実行してください。 ```shell make ``` -2. 別のターミナルセッションでリクエストスクリプトを実行してください。 +2. 別のターミナルセッションでリクエストスクリプトを実行してください。 ```shell make request ``` -3. [期待される出力.txt](https://github.com/tidb-samples/tidb-java-springboot-jpa-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 +3. [期待される出力.txt](https://github.com/tidb-samples/tidb-java-springboot-jpa-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 ## サンプルコードスニペット {#sample-code-snippets} @@ -245,9 +245,9 @@ spring: 設定後、環境変数`TIDB_JDBC_URL` 、 `TIDB_USER` 、および`TIDB_PASSWORD`を、ご使用の TiDB の実際の値に設定してください。設定ファイルには、これらの環境変数のデフォルト設定が記載されています。環境変数を設定しない場合、デフォルト値は次のようになります。 -- `TIDB_JDBC_URL` : `"jdbc:mysql://localhost:4000/test"` -- `TIDB_USER` : `"root"` -- `TIDB_PASSWORD` : `""` +- `TIDB_JDBC_URL` : `"jdbc:mysql://localhost:4000/test"` +- `TIDB_USER` : `"root"` +- `TIDB_PASSWORD` : `""` ### データ管理: `@Repository` {#data-management-repository} @@ -292,21 +292,21 @@ playerRepository.deleteById(id); ## 次のステップ {#next-steps} -- このドキュメントで使用されているサードパーティライブラリおよびフレームワークの詳細については、それぞれの公式ドキュメントを参照してください。 +- このドキュメントで使用されているサードパーティライブラリおよびフレームワークの詳細については、それぞれの公式ドキュメントを参照してください。 - - [Spring Frameworkのドキュメント](https://spring.io/projects/spring-framework) - - [Spring Bootのドキュメント](https://spring.io/projects/spring-boot) - - [Spring Data JPAのドキュメント](https://spring.io/projects/spring-data-jpa) - - [Hibernateのドキュメント](https://hibernate.org/orm/documentation) + - [Spring Frameworkのドキュメント](https://spring.io/projects/spring-framework) + - [Spring Bootのドキュメント](https://spring.io/projects/spring-boot) + - [Spring Data JPAのドキュメント](https://spring.io/projects/spring-data-jpa) + - [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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- [開発者ガイド](https://docs.pingcap.com/developer/) の [データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/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/)を取得します。 +- プロフェッショナルな[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)を通じて学習します。 +- Java開発者向けのコース「 [JavaからTiDBを操作する](https://eng.edu.pingcap.com/catalog/info/id:212)を通じて学習します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-nextjs.md b/develop/dev-guide-sample-application-nextjs.md index 3875cd6d88bc3..080c5be29b833 100644 --- a/develop/dev-guide-sample-application-nextjs.md +++ b/develop/dev-guide-sample-application-nextjs.md @@ -10,9 +10,9 @@ TiDBはMySQL互換のデータベースであり、 [mysql2](https://github.com/ このチュートリアルでは、Next.jsでTiDBとmysql2を使用して以下のタスクを実行する方法を学びます。 -- 環境をセットアップしてください。 -- mysql2を使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- 環境をセットアップしてください。 +- mysql2を使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 > **Note** > @@ -22,14 +22,14 @@ TiDBはMySQL互換のデータベースであり、 [mysql2](https://github.com/ このチュートリアルを完了するには、以下が必要です。 -- [Node.js **18**](https://nodejs.org/en/download/)以降。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- [Node.js **18**](https://nodejs.org/en/download/)以降。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -64,31 +64,31 @@ npm install
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックします。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックします。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Note** > > Node.jsアプリケーションでは、SSL CA証明書を提供する必要はありません。Node.jsはTLS（SSL）接続を確立する際に、デフォルトで組み込みの[Mozilla CA証明書](https://wiki.mozilla.org/CA/Included_Certificates)を使用するためです。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```bash # Linux @@ -100,7 +100,7 @@ npm install Copy-Item ".env.example" -Destination ".env" ``` -6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```bash TIDB_HOST='{gateway-region}.aws.tidbcloud.com' @@ -113,32 +113,32 @@ npm install `{}`内のプレースホルダーを、接続ダイアログで取得した値に置き換えてください。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```bash # Linux @@ -150,7 +150,7 @@ npm install Copy-Item ".env.example" -Destination ".env" ``` -8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```bash TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -163,13 +163,13 @@ npm install `{}`内のプレースホルダーを、接続ダイアログで取得した値に置き換えてください。 -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```bash # Linux @@ -181,7 +181,7 @@ npm install Copy-Item ".env.example" -Destination ".env" ``` -2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```bash TIDB_HOST='{tidb_server_host}' @@ -194,7 +194,7 @@ npm install `{}`内のプレースホルダーを、 **[接続]**ウィンドウで取得した値に置き換えてください。TiDB をローカルで実行している場合、デフォルトのホスト アドレスは`127.0.0.1`で、パスワードは空欄です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
@@ -202,17 +202,17 @@ npm install ### ステップ4：コードを実行して結果を確認する {#step-4-run-the-code-and-check-the-result} -1. アプリケーションを起動します: +1. アプリケーションを起動します: ```bash npm run dev ``` -2. ブラウザを開いて`http://localhost:3000`にアクセスしてください。（実際のポート番号は端末で確認してください。デフォルトは`3000`です。） +2. ブラウザを開いて`http://localhost:3000`にアクセスしてください。（実際のポート番号は端末で確認してください。デフォルトは`3000`です。） -3. サンプルコードを実行するには、 **RUN SQL**をクリックしてください。 +3. サンプルコードを実行するには、 **RUN SQL**をクリックしてください。 -4. ターミナルの出力を確認してください。出力が以下の例と似ていれば、接続は成功しています。 +4. ターミナルの出力を確認してください。出力が以下の例と似ていれば、接続は成功しています。 ```json { @@ -314,19 +314,19 @@ console.log(rsh.affectedRows); ## 役立つメモ {#useful-notes} -- [接続プール](https://github.com/sidorares/node-mysql2#using-connection-pools)を使用してデータベース接続を管理することで、接続の頻繁な確立と切断によって発生するパフォーマンスのオーバーヘッドを削減できます。 -- SQL インジェクションを回避するには、 [プリペアドステートメント](https://github.com/sidorares/node-mysql2#using-prepared-statements)を使用することをお勧めします。 -- 複雑な SQL ステートメントがあまり含まれないシナリオでは、[Sequelize](https://sequelize.org/)、 [TypeORM](https://typeorm.io/) 、または[Prisma](https://www.prisma.io/)などの ORM フレームワークを使用すると、開発効率が大幅に向上します。 +- [接続プール](https://github.com/sidorares/node-mysql2#using-connection-pools)を使用してデータベース接続を管理することで、接続の頻繁な確立と切断によって発生するパフォーマンスのオーバーヘッドを削減できます。 +- SQL インジェクションを回避するには、 [プリペアドステートメント](https://github.com/sidorares/node-mysql2#using-prepared-statements)を使用することをお勧めします。 +- 複雑な SQL ステートメントがあまり含まれないシナリオでは、[Sequelize](https://sequelize.org/)、 [TypeORM](https://typeorm.io/) 、または[Prisma](https://www.prisma.io/)などの ORM フレームワークを使用すると、開発効率が大幅に向上します。 ## 次のステップ {#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)を参照してください。 -- [開発者ガイド](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)、[トランザクション](/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/)を取得します。 +- ORM と Next.js を使用して複雑なアプリケーションを構築する方法の詳細については、 [書店デモ](https://github.com/pingcap/tidb-prisma-vercel-demo)を参照してください。 +- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-nodejs-mysql2.md b/develop/dev-guide-sample-application-nodejs-mysql2.md index c9d897d0432de..60fa4bbc44a66 100644 --- a/develop/dev-guide-sample-application-nodejs-mysql2.md +++ b/develop/dev-guide-sample-application-nodejs-mysql2.md @@ -10,9 +10,9 @@ TiDBはMySQL互換のデータベースであり、 [node-mysql2](https://github このチュートリアルでは、TiDBとnode-mysql2を使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- node-mysql2を使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- 環境をセットアップしてください。 +- node-mysql2を使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 > **Note:** > @@ -22,14 +22,14 @@ TiDBはMySQL互換のデータベースであり、 [node-mysql2](https://github このチュートリアルを完了するには、以下が必要です。 -- お使いのコンピューターに[Node.js](https://nodejs.org/en) >= 16.xがインストールされていること。 -- お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています。 -- TiDBクラスタが稼働中です。 +- お使いのコンピューターに[Node.js](https://nodejs.org/en) >= 16.xがインストールされていること。 +- お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています。 +- TiDBクラスタが稼働中です。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -69,26 +69,26 @@ npm install mysql2 dotenv --save
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 - - **Operating System**は、アプリケーションを実行するオペレーティングシステムと一致します。 + - **Connection Type**は`Public`に設定されています。 + - **Branch**は`main`に設定されています。 + - **Connect With**は`General`に設定されています。 + - **Operating System**は、アプリケーションを実行するオペレーティングシステムと一致します。 -4. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 +4. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 +6. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 ```dotenv TIDB_HOST={host} @@ -103,37 +103,37 @@ npm install mysql2 dotenv --save > > TiDB Cloud Starterの場合、パブリックエンドポイントを使用する際には、 `TIDB_ENABLE_SSL`を介して TLS 接続を有効にする**必要があります**。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`を接続パラメータに置き換えます。 +8. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`を接続パラメータに置き換えます。 ```dotenv TIDB_HOST={host} @@ -144,28 +144,28 @@ npm install mysql2 dotenv --save TIDB_ENABLE_SSL=false ``` -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 +5. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 ```dotenv TIDB_HOST={host} @@ -183,18 +183,18 @@ npm install mysql2 dotenv --save > > TLS接続を有効にするには、 `TIDB_ENABLE_SSL`を`true`に変更し、 `TIDB_CA_PATH`を使用して、接続ダイアログからダウンロードしたCA証明書のファイルパスを指定します。 -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 +2. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 ```dotenv TIDB_HOST={host} @@ -206,7 +206,7 @@ npm install mysql2 dotenv --save TiDBをローカルで実行している場合、デフォルトのホストアドレスは`127.0.0.1`で、パスワードは空です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
@@ -328,20 +328,20 @@ console.log(rsh.affectedRows); ## 役立つメモ {#useful-notes} -- [接続プール](https://github.com/sidorares/node-mysql2#using-connection-pools)を使用してデータベース接続を管理することで、接続の頻繁な確立と切断によって発生するパフォーマンスのオーバーヘッドを削減できます。 -- SQL インジェクションを回避するには、 [プリペアドステートメント](https://github.com/sidorares/node-mysql2#using-prepared-statements)を使用することをお勧めします。 -- 複雑な SQL ステートメントがあまり含まれないシナリオでは、[Sequelize](https://sequelize.org/)、 [TypeORM](https://typeorm.io/) 、または[Prisma](https://www.prisma.io/)などの ORM フレームワークを使用すると、開発効率が大幅に向上します。 -- データベースで大きな数値（ `supportBigNumbers: true`列と`BIGINT`列）を扱う場合は、 `DECIMAL`オプションを有効にすることをお勧めします。 -- ネットワークの問題によるソケットエラー`enableKeepAlive: true`回避するために、{ `read ECONNRESET`オプションを有効にすることをお勧めします。（関連する問題： [sidorares/node-mysql2#683](https://github.com/sidorares/node-mysql2/issues/683) ） +- [接続プール](https://github.com/sidorares/node-mysql2#using-connection-pools)を使用してデータベース接続を管理することで、接続の頻繁な確立と切断によって発生するパフォーマンスのオーバーヘッドを削減できます。 +- SQL インジェクションを回避するには、 [プリペアドステートメント](https://github.com/sidorares/node-mysql2#using-prepared-statements)を使用することをお勧めします。 +- 複雑な SQL ステートメントがあまり含まれないシナリオでは、[Sequelize](https://sequelize.org/)、 [TypeORM](https://typeorm.io/) 、または[Prisma](https://www.prisma.io/)などの ORM フレームワークを使用すると、開発効率が大幅に向上します。 +- データベースで大きな数値（ `supportBigNumbers: true`列と`BIGINT`列）を扱う場合は、 `DECIMAL`オプションを有効にすることをお勧めします。 +- ネットワークの問題によるソケットエラー`enableKeepAlive: true`回避するために、{ `read ECONNRESET`オプションを有効にすることをお勧めします。（関連する問題： [sidorares/node-mysql2#683](https://github.com/sidorares/node-mysql2/issues/683) ） ## 次のステップ {#next-steps} -- node-mysql2 ドライバーの使用方法の詳細については[node-mysql2 のドキュメント](https://github.com/sidorares/node-mysql2#readme)を参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 -- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 +- 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/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-nodejs-mysqljs.md b/develop/dev-guide-sample-application-nodejs-mysqljs.md index e700f85389391..0cacc403e75af 100644 --- a/develop/dev-guide-sample-application-nodejs-mysqljs.md +++ b/develop/dev-guide-sample-application-nodejs-mysqljs.md @@ -10,9 +10,9 @@ TiDBはMySQL互換データベースであり、 [mysql.js](https://github.com/m このチュートリアルでは、TiDBとmysql.jsドライバを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- mysql.jsドライバを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- 環境をセットアップしてください。 +- mysql.jsドライバを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 > **Note:** > @@ -22,14 +22,14 @@ TiDBはMySQL互換データベースであり、 [mysql.js](https://github.com/m このチュートリアルを完了するには、以下が必要です。 -- お使いのコンピューターに[Node.js](https://nodejs.org/en) >= 16.xがインストールされていること。 -- お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています。 -- TiDBクラスタが稼働中です。 +- お使いのコンピューターに[Node.js](https://nodejs.org/en) >= 16.xがインストールされていること。 +- お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています。 +- TiDBクラスタが稼働中です。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -69,26 +69,26 @@ npm install mysql dotenv --save
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 - - **Operating System**は、アプリケーションを実行するオペレーティングシステムと一致します。 + - **Connection Type**は`Public`に設定されています。 + - **Branch**は`main`に設定されています。 + - **Connect With**は`General`に設定されています。 + - **Operating System**は、アプリケーションを実行するオペレーティングシステムと一致します。 -4. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 +4. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 +6. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 ```dotenv TIDB_HOST={host} @@ -103,37 +103,37 @@ npm install mysql dotenv --save > > TiDB Cloud Starterの場合、パブリックエンドポイントを使用する際には、 `TIDB_ENABLE_SSL`を介して TLS 接続を有効にする**必要があります**。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`を接続パラメータに置き換えます。 +8. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`を接続パラメータに置き換えます。 ```dotenv TIDB_HOST={host} @@ -144,28 +144,28 @@ npm install mysql dotenv --save TIDB_ENABLE_SSL=false ``` -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 +5. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 ```dotenv TIDB_HOST={host} @@ -183,18 +183,18 @@ npm install mysql dotenv --save > > TLS接続を有効にするには、 `TIDB_ENABLE_SSL`を`true`に変更し、 `TIDB_CA_PATH`を使用して、接続ダイアログからダウンロードしたCA証明書のファイルパスを指定します。 -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. `.env`ファイルを編集し、対応するプレースホルダー`{}` TiDB の接続パラメータに置き換えてください。設定例は以下のとおりです。 +2. `.env`ファイルを編集し、対応するプレースホルダー`{}` TiDB の接続パラメータに置き換えてください。設定例は以下のとおりです。 ```dotenv TIDB_HOST={host} @@ -206,7 +206,7 @@ npm install mysql dotenv --save TiDBをローカルで実行している場合、デフォルトのホストアドレスは`127.0.0.1`で、パスワードは空です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
@@ -345,9 +345,9 @@ conn.query('DELETE FROM players WHERE id = ?;', [1], (err, ok) => { ## 役立つメモ {#useful-notes} -- [接続プール](https://github.com/mysqljs/mysql#pooling-connections)を使用してデータベース接続を管理することで、接続の頻繁な確立と切断によって発生するパフォーマンスのオーバーヘッドを削減できます。 +- [接続プール](https://github.com/mysqljs/mysql#pooling-connections)を使用してデータベース接続を管理することで、接続の頻繁な確立と切断によって発生するパフォーマンスのオーバーヘッドを削減できます。 -- SQL インジェクション攻撃を回避するには、SQL を実行する前に[クエリ値のエスケープ](https://github.com/mysqljs/mysql#escaping-query-values)を使用することをお勧めします。 +- SQL インジェクション攻撃を回避するには、SQL を実行する前に[クエリ値のエスケープ](https://github.com/mysqljs/mysql#escaping-query-values)を使用することをお勧めします。 > **Note** > @@ -355,18 +355,18 @@ conn.query('DELETE FROM players WHERE id = ?;', [1], (err, ok) => { > > SQLインジェクション攻撃を回避したり、バッチ挿入/更新の効率を向上させたりするためにこの機能を使用したい場合は、代わりに[mysql2](https://github.com/sidorares/node-mysql2)パッケージを使用することをお勧めします。 -- ORM フレームワークを使用して、[Sequelize](https://sequelize.org/)、 [TypeORM](https://typeorm.io/) 、 [Prisma](/develop/dev-guide-sample-application-nodejs-prisma.md)など、多数の複雑な SQL ステートメントを使用しないシナリオでの開発効率を向上させます。 +- ORM フレームワークを使用して、[Sequelize](https://sequelize.org/)、 [TypeORM](https://typeorm.io/) 、 [Prisma](/develop/dev-guide-sample-application-nodejs-prisma.md)など、多数の複雑な SQL ステートメントを使用しないシナリオでの開発効率を向上させます。 -- データベースで大きな数値（ `supportBigNumbers: true`列と`BIGINT`列）を扱う場合は、 `DECIMAL`オプションを有効にすることをお勧めします。 +- データベースで大きな数値（ `supportBigNumbers: true`列と`BIGINT`列）を扱う場合は、 `DECIMAL`オプションを有効にすることをお勧めします。 ## 次のステップ {#next-steps} -- mysql.js ドライバーの使用方法の詳細については[mysql.jsのドキュメント](https://github.com/mysqljs/mysql#readme)を参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 -- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 +- 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/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-nodejs-prisma.md b/develop/dev-guide-sample-application-nodejs-prisma.md index 4798af75ce827..2351e4b4501b6 100644 --- a/develop/dev-guide-sample-application-nodejs-prisma.md +++ b/develop/dev-guide-sample-application-nodejs-prisma.md @@ -10,9 +10,9 @@ TiDB は MySQL 互換データベースであり、[Prisma](https://github.com/p このチュートリアルでは、TiDBとPrismaを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- Prismaを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- 環境をセットアップしてください。 +- Prismaを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 > **Note:** > @@ -22,14 +22,14 @@ TiDB は MySQL 互換データベースであり、[Prisma](https://github.com/p このチュートリアルを完了するには、以下が必要です。 -- お使いのコンピューターに[Node.js](https://nodejs.org/en) >= 16.xがインストールされていること。 -- お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています。 -- TiDBクラスタが稼働中です。 +- お使いのコンピューターに[Node.js](https://nodejs.org/en) >= 16.xがインストールされていること。 +- お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています。 +- TiDBクラスタが稼働中です。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -69,26 +69,26 @@ npm install prisma typescript ts-node @types/node --save-dev
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 - - **Connect With**は`Prisma`に設定されています。 - - **Operating System**は、アプリケーションを実行するオペレーティングシステムと一致します。 + - **Connection Type**は`Public`に設定されています。 + - **Branch**は`main`に設定されています。 + - **Connect With**は`Prisma`に設定されています。 + - **Operating System**は、アプリケーションを実行するオペレーティングシステムと一致します。 -4. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 +4. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. `.env`ファイルを編集し、環境変数`DATABASE_URL`次のように設定し、接続ダイアログで対応するプレースホルダー`{}`接続文字列に置き換えます。 +6. `.env`ファイルを編集し、環境変数`DATABASE_URL`次のように設定し、接続ダイアログで対応するプレースホルダー`{}`接続文字列に置き換えます。 ```dotenv DATABASE_URL='{connection_string}' @@ -98,9 +98,9 @@ npm install prisma typescript ts-node @types/node --save-dev > > TiDB Cloud Starterの場合、パブリックエンドポイントを使用する際には`sslaccept=strict`を設定して TLS 接続を有効にする**必要があります**。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。 -8. `prisma/schema.prisma`で、 `mysql`を接続プロバイダとして、 `env("DATABASE_URL")`接続 URL として設定します。 +8. `prisma/schema.prisma`で、 `mysql`を接続プロバイダとして、 `env("DATABASE_URL")`接続 URL として設定します。 ```prisma datasource db { @@ -112,38 +112,38 @@ npm install prisma typescript ts-node @types/node --save-dev
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. `.env`ファイルを編集し、環境変数`DATABASE_URL`次のように設定し、接続ダイアログで対応するプレースホルダー`{}`接続パラメータに置き換えます。 +8. `.env`ファイルを編集し、環境変数`DATABASE_URL`次のように設定し、接続ダイアログで対応するプレースホルダー`{}`接続パラメータに置き換えます。 ```dotenv DATABASE_URL='mysql://{user}:{password}@{host}:4000/test' ``` -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。 10. `prisma/schema.prisma`で、 `mysql`を接続プロバイダとして、 `env("DATABASE_URL")`接続 URL として設定します。 @@ -157,23 +157,23 @@ npm install prisma typescript ts-node @types/node --save-dev
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. `.env`ファイルを編集し、環境変数`DATABASE_URL`次のように設定し、接続ダイアログで対応するプレースホルダー`{}`接続パラメータに置き換えます。 +5. `.env`ファイルを編集し、環境変数`DATABASE_URL`次のように設定し、接続ダイアログで対応するプレースホルダー`{}`接続パラメータに置き換えます。 ```dotenv DATABASE_URL='mysql://{user}:{password}@{host}:4000/test?sslaccept=strict&sslcert={downloaded_ssl_ca_path}' @@ -183,9 +183,9 @@ npm install prisma typescript ts-node @types/node --save-dev > > TiDB Cloud Starterの場合、パブリックエンドポイントを使用する際には`sslaccept=strict`を設定して TLS 接続を有効にすることを**お勧めします**。 `sslaccept=strict`を設定して TLS 接続を有効にする場合は、 `sslcert=/path/to/ca.pem`を介して接続ダイアログからダウンロードした CA 証明書のファイルパスを指定する必要があります。 -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。 -7. `prisma/schema.prisma`で、 `mysql`を接続プロバイダとして、 `env("DATABASE_URL")`接続 URL として設定します。 +7. `prisma/schema.prisma`で、 `mysql`を接続プロバイダとして、 `env("DATABASE_URL")`接続 URL として設定します。 ```prisma datasource db { @@ -197,13 +197,13 @@ npm install prisma typescript ts-node @types/node --save-dev
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. `.env`ファイルを編集し、環境変数`DATABASE_URL`次のように設定し、対応するプレースホルダー`{}` TiDB の接続パラメータに置き換えます。 +2. `.env`ファイルを編集し、環境変数`DATABASE_URL`次のように設定し、対応するプレースホルダー`{}` TiDB の接続パラメータに置き換えます。 ```dotenv DATABASE_URL='mysql://{user}:{password}@{host}:4000/test' @@ -211,9 +211,9 @@ npm install prisma typescript ts-node @types/node --save-dev TiDBをローカルで実行している場合、デフォルトのホストアドレスは`127.0.0.1`で、パスワードは空です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。 -4. `prisma/schema.prisma`で、 `mysql`を接続プロバイダとして、 `env("DATABASE_URL")`接続 URL として設定します。 +4. `prisma/schema.prisma`で、 `mysql`を接続プロバイダとして、 `env("DATABASE_URL")`接続 URL として設定します。 ```prisma datasource db { @@ -393,22 +393,22 @@ await prisma.player.delete({ [参照整合性](https://en.wikipedia.org/wiki/Referential_integrity?useskin=vector)をチェックするには、外部キー制約または Prisma リレーション モードを使用できます。 -- [外部キー](https://docs.pingcap.com/tidb/stable/foreign-key)、TiDB v6.6.0 以降でサポートされている機能であり、v8.5.0 以降で一般的に利用可能です。外部キーを使用すると、関連データのテーブル間参照が可能になり、外部キー制約によって関連データの一貫性が確保されます。 +- [外部キー](https://docs.pingcap.com/tidb/stable/foreign-key)、TiDB v6.6.0 以降でサポートされている機能であり、v8.5.0 以降で一般的に利用可能です。外部キーを使用すると、関連データのテーブル間参照が可能になり、外部キー制約によって関連データの一貫性が確保されます。 > **Warning:** > > **外部キーは、小規模から中規模のデータ量を扱う場合に適しています。**大規模なデータ量で外部キーを使用すると、深刻なパフォーマンス問題が発生したり、システムに予期せぬ影響を及ぼしたりする可能性があります。外部キーを使用する場合は、事前に徹底的な検証を行い、慎重に使用してください。 -- [Prisma Relation Mode](https://www.prisma.io/docs/concepts/components/prisma-schema/relations/relation-mode)Prisma Client側の参照整合性のエミュレーションです。ただし、参照整合性を維持するために追加のデータベース クエリが必要になるため、パフォーマンスに影響があることに注意してください。 +- [Prisma Relation Mode](https://www.prisma.io/docs/concepts/components/prisma-schema/relations/relation-mode)Prisma Client側の参照整合性のエミュレーションです。ただし、参照整合性を維持するために追加のデータベース クエリが必要になるため、パフォーマンスに影響があることに注意してください。 ## 次のステップ {#next-steps} -- ORM フレームワーク Prisma ドライバーの使用方法の詳細については[Prismaのドキュメント](https://www.prisma.io/docs)を参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 -- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 +- 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/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-nodejs-sequelize.md b/develop/dev-guide-sample-application-nodejs-sequelize.md index bf8ef7df09b88..9a1fa197f1c2f 100644 --- a/develop/dev-guide-sample-application-nodejs-sequelize.md +++ b/develop/dev-guide-sample-application-nodejs-sequelize.md @@ -10,9 +10,9 @@ TiDB は MySQL 互換データベースであり、[Sequelize](https://sequelize このチュートリアルでは、TiDBとSequelizeを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- Sequelizeを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- 環境をセットアップしてください。 +- Sequelizeを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 > **Note** > @@ -22,14 +22,14 @@ TiDB は MySQL 互換データベースであり、[Sequelize](https://sequelize このチュートリアルを完了するには、以下が必要です。 -- [Node.js **18**](https://nodejs.org/en/download/)以降。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- [Node.js **18**](https://nodejs.org/en/download/)以降。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -64,37 +64,37 @@ npm install
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Note** > > Node.jsアプリケーションでは、SSL CA証明書を提供する必要はありません。Node.jsはTLS（SSL）接続を確立する際に、デフォルトで組み込みの[Mozilla CA証明書](https://wiki.mozilla.org/CA/Included_Certificates)を使用するためです。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを作成できます。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 +6. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 ```dotenv TIDB_HOST='{host}' @@ -105,38 +105,38 @@ npm install TIDB_ENABLE_SSL='true' ``` -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`を接続パラメータに置き換えます。 +8. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`を接続パラメータに置き換えます。 ```dotenv TIDB_HOST='{host}' @@ -147,29 +147,29 @@ npm install TIDB_ENABLE_SSL='false' ``` -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 +5. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 ```shell TIDB_HOST='{host}' @@ -181,19 +181,19 @@ npm install TIDB_CA_PATH='{path/to/ca}' ``` -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 +2. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 ```shell TIDB_HOST='{host}' @@ -205,7 +205,7 @@ npm install TiDBをローカルで実行している場合、デフォルトのホストアドレスは`127.0.0.1`で、パスワードは空です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
@@ -352,12 +352,12 @@ logger.info(deletedNewPlayer?.toJSON()); ## 次のステップ {#next-steps} -- 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/)を取得します。 +- 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/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-nodejs-typeorm.md b/develop/dev-guide-sample-application-nodejs-typeorm.md index d7cf50fc291ef..d039a1b8310eb 100644 --- a/develop/dev-guide-sample-application-nodejs-typeorm.md +++ b/develop/dev-guide-sample-application-nodejs-typeorm.md @@ -10,9 +10,9 @@ TiDBはMySQL互換のデータベースであり、 [TypeORM](https://github.com このチュートリアルでは、TiDBとTypeORMを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- TypeORMを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- 環境をセットアップしてください。 +- TypeORMを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 > **Note** > @@ -22,14 +22,14 @@ TiDBはMySQL互換のデータベースであり、 [TypeORM](https://github.com このチュートリアルを完了するには、以下が必要です。 -- お使いのコンピューターに[Node.js](https://nodejs.org/en) >= 16.xがインストールされていること。 -- お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています。 -- TiDBクラスタが稼働中です。 +- お使いのコンピューターに[Node.js](https://nodejs.org/en) >= 16.xがインストールされていること。 +- お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています。 +- TiDBクラスタが稼働中です。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -56,12 +56,12 @@ npm install 既存のプロジェクトの場合、以下のコマンドを実行してパッケージをインストールしてください。 -- `typeorm` : Node.js 用の ORM フレームワーク。 -- `mysql2` : Node.js 用の MySQL ドライバーです`mysql`ドライバーも使用できます。 -- `dotenv` : `.env`ファイルから環境変数を読み込みます。 -- `typescript` : TypeScript コードを JavaScript にコンパイルします。 -- `ts-node` : TypeScript コードをコンパイルせずに直接実行します。 -- `@types/node` : Node.js 用の TypeScript 型定義を提供します。 +- `typeorm` : Node.js 用の ORM フレームワーク。 +- `mysql2` : Node.js 用の MySQL ドライバーです`mysql`ドライバーも使用できます。 +- `dotenv` : `.env`ファイルから環境変数を読み込みます。 +- `typescript` : TypeScript コードを JavaScript にコンパイルします。 +- `ts-node` : TypeScript コードをコンパイルせずに直接実行します。 +- `@types/node` : Node.js 用の TypeScript 型定義を提供します。 ```shell npm install typeorm mysql2 dotenv --save @@ -77,26 +77,26 @@ npm install @types/node ts-node typescript --save-dev
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 - - **Operating System**は、アプリケーションを実行するオペレーティングシステムと一致します。 + - **Connection Type**は`Public`に設定されています。 + - **Branch**は`main`に設定されています。 + - **Connect With**は`General`に設定されています。 + - **Operating System**は、アプリケーションを実行するオペレーティングシステムと一致します。 -4. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 +4. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 +6. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 ```dotenv TIDB_HOST={host} @@ -111,37 +111,37 @@ npm install @types/node ts-node typescript --save-dev > > TiDB Cloud StarterおよびTiDB Cloud Essentialの場合、パブリック エンドポイントを使用する際には`TIDB_ENABLE_SSL`を介して TLS 接続を有効にする**必要があります**。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`を接続パラメータに置き換えます。 +8. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`を接続パラメータに置き換えます。 ```dotenv TIDB_HOST={host} @@ -152,28 +152,28 @@ npm install @types/node ts-node typescript --save-dev TIDB_ENABLE_SSL=false ``` -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 +5. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログ上の対応するプレースホルダー`{}`接続パラメータに置き換えます。 ```dotenv TIDB_HOST={host} @@ -189,18 +189,18 @@ npm install @types/node ts-node typescript --save-dev > > TiDB Cloud Dedicatedの場合、パブリックエンドポイントを使用する際には`TIDB_ENABLE_SSL`を介して TLS 接続を有効にすることを**お勧めします**。 `TIDB_ENABLE_SSL=true`を設定する際には、 `TIDB_CA_PATH=/path/to/ca.pem`を介して接続ダイアログからダウンロードした CA 証明書のパスを指定する**必要があります**。 -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. `.env`ファイルを編集し、環境変数を以下のように設定し、対応するプレースホルダー`{}` TiDB の接続パラメータに置き換えてください。 +2. `.env`ファイルを編集し、環境変数を以下のように設定し、対応するプレースホルダー`{}` TiDB の接続パラメータに置き換えてください。 ```dotenv TIDB_HOST={host} @@ -212,7 +212,7 @@ npm install @types/node ts-node typescript --save-dev TiDBをローカルで実行している場合、デフォルトのホストアドレスは`127.0.0.1`で、パスワードは空です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
@@ -395,12 +395,12 @@ export class ActionLog { ## 次のステップ {#next-steps} -- TypeORM の使用法の詳細については[TypeORMのドキュメント](https://typeorm.io/)を参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 -- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 +- 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/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-python-django.md b/develop/dev-guide-sample-application-python-django.md index 1ccaa3f93606b..ce6eb5f118f2f 100644 --- a/develop/dev-guide-sample-application-python-django.md +++ b/develop/dev-guide-sample-application-python-django.md @@ -10,9 +10,9 @@ TiDBはMySQL互換のデータベースであり、[Django](https://www.djangopr このチュートリアルでは、TiDBとDjangoを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- Djangoを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。必要に応じて、基本的なCRUD操作のサンプルコードスニペットも利用できます。 +- 環境をセットアップしてください。 +- Djangoを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。必要に応じて、基本的なCRUD操作のサンプルコードスニペットも利用できます。 > **Note:** > @@ -22,14 +22,14 @@ TiDBはMySQL互換のデータベースであり、[Django](https://www.djangopr このチュートリアルを完了するには、以下が必要です。 -- [Python 3.8以降](https://www.python.org/downloads/)。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- [Python 3.8以降](https://www.python.org/downloads/)。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -69,37 +69,37 @@ mysqlclient でインストールの問題が発生した場合は、 [mysqlclie
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. gateway01.ap-northeast-1.prod.aws.tidbcloud.com @@ -114,37 +114,37 @@ mysqlclient でインストールの問題が発生した場合は、 [mysqlclie TiDB Cloud Starter は安全な接続を必要とします。mysqlclient の`ssl_mode`はデフォルトで`PREFERRED`になっているため、 `CA_PATH`手動で指定する必要はありません。空欄のままにしてください。ただし、 `CA_PATH`手動で指定する必要がある特別な理由がある場合は、 [TiDB Cloud StarterへのTLS接続](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters)を参照して、さまざまなオペレーティングシステムの証明書パスを取得してください。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -156,28 +156,28 @@ mysqlclient でインストールの問題が発生した場合は、 [mysqlclie 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -190,18 +190,18 @@ mysqlclient でインストールの問題が発生した場合は、 [mysqlclie 必ず、プレースホルダー`{}`を接続ダイアログから取得した接続パラメータに置き換え、 `CA_PATH`前の手順でダウンロードした証明書のパスに設定してください。 -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{tidb_server_host}' @@ -213,7 +213,7 @@ mysqlclient でインストールの問題が発生した場合は、 [mysqlclie プレースホルダー`{}`を接続パラメータに置き換え、 `CA_PATH`の行を削除してください。TiDB をローカルで実行している場合、デフォルトのホスト アドレスは`127.0.0.1`で、パスワードは空欄です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
@@ -228,7 +228,7 @@ python manage.py migrate ### ステップ5：サンプルアプリケーションを実行する {#step-5-run-the-sample-application} -1. アプリケーションを開発モードで実行します。 +1. アプリケーションを開発モードで実行します。 ```shell python manage.py runserver @@ -240,14 +240,14 @@ python manage.py migrate python manage.py runserver 8080 ``` -2. アプリケーションにアクセスするには、ブラウザを開いて`http://localhost:8000/`にアクセスしてください。サンプルアプリケーションでは、以下の操作が可能です。 +2. アプリケーションにアクセスするには、ブラウザを開いて`http://localhost:8000/`にアクセスしてください。サンプルアプリケーションでは、以下の操作が可能です。 - - 新しいプレイヤーを作成します。 - - プレイヤーを一括作成する。 - - 全プレイヤーを表示する。 - - プレイヤーを更新する。 - - プレイヤーを削除する。 - - 2人のプレイヤー間で商品を取引する。 + - 新しいプレイヤーを作成します。 + - プレイヤーを一括作成する。 + - 全プレイヤーを表示する。 + - プレイヤーを更新する。 + - プレイヤーを削除する。 + - 2人のプレイヤー間で商品を取引する。 ## サンプルコードスニペット {#sample-code-snippets} @@ -359,12 +359,12 @@ Player.objects.filter(coins=100).delete() ## 次のステップ {#next-steps} -- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/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/)を取得します。 +- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-python-mysql-connector.md b/develop/dev-guide-sample-application-python-mysql-connector.md index bec3f6cdce7c3..adfd96f52b7a0 100644 --- a/develop/dev-guide-sample-application-python-mysql-connector.md +++ b/develop/dev-guide-sample-application-python-mysql-connector.md @@ -10,9 +10,9 @@ TiDB は MySQL 互換データベースであり、 [MySQL Connector/Python](htt このチュートリアルでは、TiDBとMySQL Connector/Pythonを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- MySQL Connector/Pythonを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。必要に応じて、基本的なCRUD操作のサンプルコードスニペットも利用できます。 +- 環境をセットアップしてください。 +- MySQL Connector/Pythonを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。必要に応じて、基本的なCRUD操作のサンプルコードスニペットも利用できます。 > **Note:** > @@ -22,14 +22,14 @@ TiDB は MySQL 互換データベースであり、 [MySQL Connector/Python](htt このチュートリアルを完了するには、以下が必要です。 -- [Python 3.8以降](https://www.python.org/downloads/)。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- [Python 3.8以降](https://www.python.org/downloads/)。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -59,37 +59,37 @@ pip install -r requirements.txt
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. gateway01.ap-northeast-1.prod.aws.tidbcloud.com @@ -102,37 +102,37 @@ pip install -r requirements.txt 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -144,28 +144,28 @@ pip install -r requirements.txt 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -178,18 +178,18 @@ pip install -r requirements.txt 必ず、プレースホルダー`{}`を接続ダイアログから取得した接続パラメータに置き換え、 `CA_PATH`前の手順でダウンロードした証明書のパスに設定してください。 -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{tidb_server_host}' @@ -201,20 +201,20 @@ pip install -r requirements.txt プレースホルダー`{}`を接続パラメータに置き換え、 `CA_PATH`の行を削除してください。TiDB をローカルで実行している場合、デフォルトのホスト アドレスは`127.0.0.1`で、パスワードは空欄です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
### ステップ4：コードを実行して結果を確認する {#step-4-run-the-code-and-check-the-result} -1. サンプルコードを実行するには、以下のコマンドを実行してください。 +1. サンプルコードを実行するには、以下のコマンドを実行してください。 ```shell python mysql_connector_example.py ``` -2. [期待される出力.txt](https://github.com/tidb-samples/tidb-python-mysqlconnector-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 +2. [期待される出力.txt](https://github.com/tidb-samples/tidb-python-mysqlconnector-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 ## サンプルコードスニペット {#sample-code-snippets} @@ -299,23 +299,23 @@ with get_connection(autocommit=True) as conn: Pythonドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となる。 -- データベース接続を手動で確立および解放します。 -- データベースのトランザクションを手動で管理する。 -- データ行（ `mysql-connector-python`ではタプルまたは辞書として表現されます）をデータオブジェクトに手動でマッピングします。 +- データベース接続を手動で確立および解放します。 +- データベースのトランザクションを手動で管理する。 +- データ行（ `mysql-connector-python`ではタプルまたは辞書として表現されます）をデータオブジェクトに手動でマッピングします。 複雑なSQL文を書く必要がない限り、 [SQLAlchemy](/develop/dev-guide-sample-application-python-sqlalchemy.md) 、 [Peewee](/develop/dev-guide-sample-application-python-peewee.md)、Django ORMなどの[ORM](https://en.wikipedia.org/w/index.php?title=Object-relational_mapping)フレームワークを使用して開発することをお勧めします。これにより、次のようなことが可能になります。 -- 接続とトランザクションを管理するための[定型コード](https://en.wikipedia.org/wiki/Boilerplate_code)を削減します。 -- 多数のSQL文の代わりに、データオブジェクトを使用してデータを操作します。 +- 接続とトランザクションを管理するための[定型コード](https://en.wikipedia.org/wiki/Boilerplate_code)を削減します。 +- 多数のSQL文の代わりに、データオブジェクトを使用してデータを操作します。 ## 次のステップ {#next-steps} -- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/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/)を取得します。 +- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-python-mysqlclient.md b/develop/dev-guide-sample-application-python-mysqlclient.md index d0c31aff7f7ca..d9e31c23fde61 100644 --- a/develop/dev-guide-sample-application-python-mysqlclient.md +++ b/develop/dev-guide-sample-application-python-mysqlclient.md @@ -10,9 +10,9 @@ TiDBはMySQL互換のデータベースであり、 [mysqlclient](https://github このチュートリアルでは、TiDBとmysqlclientを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- mysqlclientを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。必要に応じて、基本的なCRUD操作のサンプルコードスニペットも利用できます。 +- 環境をセットアップしてください。 +- mysqlclientを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。必要に応じて、基本的なCRUD操作のサンプルコードスニペットも利用できます。 > **Note:** > @@ -22,14 +22,14 @@ TiDBはMySQL互換のデータベースであり、 [mysqlclient](https://github このチュートリアルを完了するには、以下が必要です。 -- [Python **3.10**以降](https://www.python.org/downloads/)。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- [Python **3.10**以降](https://www.python.org/downloads/)。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -61,37 +61,37 @@ pip install -r requirements.txt
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{gateway-region}.aws.tidbcloud.com' @@ -106,37 +106,37 @@ pip install -r requirements.txt TiDB Cloud Starter は安全な接続を必要とします。mysqlclient の`ssl_mode`はデフォルトで`PREFERRED`になっているため、 `CA_PATH`手動で指定する必要はありません。空欄のままにしてください。ただし、 `CA_PATH`手動で指定する必要がある特別な理由がある場合は、 [TiDB Cloud StarterへのTLS接続](https://docs.pingcap.com/tidbcloud/secure-connections-to-serverless-clusters)を参照して、さまざまなオペレーティングシステムの証明書パスを取得してください。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -149,28 +149,28 @@ pip install -r requirements.txt 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}.clusters.tidb-cloud.com' @@ -183,18 +183,18 @@ pip install -r requirements.txt 必ず、プレースホルダー`{}`を接続ダイアログから取得した接続パラメータに置き換え、 `CA_PATH`前の手順でダウンロードした証明書のパスに設定してください。 -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{tidb_server_host}' @@ -206,20 +206,20 @@ pip install -r requirements.txt プレースホルダー`{}`を接続パラメータに置き換え、 `CA_PATH`の行を削除してください。TiDB をローカルで実行している場合、デフォルトのホスト アドレスは`127.0.0.1`で、パスワードは空欄です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
### ステップ4：コードを実行して結果を確認する {#step-4-run-the-code-and-check-the-result} -1. サンプルコードを実行するには、以下のコマンドを実行してください。 +1. サンプルコードを実行するには、以下のコマンドを実行してください。 ```shell python mysqlclient_example.py ``` -2. [期待される出力.txt](https://github.com/tidb-samples/tidb-python-mysqlclient-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 +2. [期待される出力.txt](https://github.com/tidb-samples/tidb-python-mysqlclient-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 ## サンプルコードスニペット {#sample-code-snippets} @@ -302,23 +302,23 @@ with get_mysqlclient_connection(autocommit=True) as conn: Pythonドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となる。 -- データベース接続を手動で確立および解放します。 -- データベースのトランザクションを手動で管理する。 -- データ行（ `mysqlclient`ではタプルとして表現されています）をデータオブジェクトに手動でマッピングします。 +- データベース接続を手動で確立および解放します。 +- データベースのトランザクションを手動で管理する。 +- データ行（ `mysqlclient`ではタプルとして表現されています）をデータオブジェクトに手動でマッピングします。 複雑なSQL文を書く必要がない限り、 [SQLAlchemy](/develop/dev-guide-sample-application-python-sqlalchemy.md) 、 [Peewee](/develop/dev-guide-sample-application-python-peewee.md)、Django ORMなどの[ORM](https://en.wikipedia.org/w/index.php?title=Object-relational_mapping)フレームワークを使用して開発することをお勧めします。これにより、次のようなことが可能になります。 -- 接続とトランザクションを管理するための[定型コード](https://en.wikipedia.org/wiki/Boilerplate_code)を削減します。 -- 多数のSQL文の代わりに、データオブジェクトを使用してデータを操作します。 +- 接続とトランザクションを管理するための[定型コード](https://en.wikipedia.org/wiki/Boilerplate_code)を削減します。 +- 多数のSQL文の代わりに、データオブジェクトを使用してデータを操作します。 ## 次のステップ {#next-steps} -- `mysqlclient`の使用法の詳細については[mysqlclient のドキュメント](https://mysqlclient.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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/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/)を取得します。 +- `mysqlclient`の使用法の詳細については[mysqlclient のドキュメント](https://mysqlclient.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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-python-peewee.md b/develop/dev-guide-sample-application-python-peewee.md index 212700f0f128a..b68ed22ee11dd 100644 --- a/develop/dev-guide-sample-application-python-peewee.md +++ b/develop/dev-guide-sample-application-python-peewee.md @@ -10,9 +10,9 @@ TiDBはMySQL互換のデータベースであり、PythonはPythonで人気の[P このチュートリアルでは、TiDBとpeeweeを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- peeweeを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。必要に応じて、基本的なCRUD操作のサンプルコードスニペットも利用できます。 +- 環境をセットアップしてください。 +- peeweeを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。必要に応じて、基本的なCRUD操作のサンプルコードスニペットも利用できます。 > **Note:** > @@ -22,14 +22,14 @@ TiDBはMySQL互換のデータベースであり、PythonはPythonで人気の[P このチュートリアルを完了するには、以下が必要です。 -- [Python 3.8以降](https://www.python.org/downloads/)。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- [Python 3.8以降](https://www.python.org/downloads/)。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -63,37 +63,37 @@ peeweeは、複数のデータベースを扱うORMライブラリです。デ
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. gateway01.ap-northeast-1.prod.aws.tidbcloud.com @@ -106,37 +106,37 @@ peeweeは、複数のデータベースを扱うORMライブラリです。デ 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -148,28 +148,28 @@ peeweeは、複数のデータベースを扱うORMライブラリです。デ 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -182,18 +182,18 @@ peeweeは、複数のデータベースを扱うORMライブラリです。デ 必ず、プレースホルダー`{}`を接続ダイアログから取得した接続パラメータに置き換え、 `CA_PATH`前の手順でダウンロードした証明書のパスに設定してください。 -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{tidb_server_host}' @@ -205,20 +205,20 @@ peeweeは、複数のデータベースを扱うORMライブラリです。デ プレースホルダー`{}`を接続パラメータに置き換え、 `CA_PATH`の行を削除してください。TiDB をローカルで実行している場合、デフォルトのホスト アドレスは`127.0.0.1`で、パスワードは空欄です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
### ステップ4：コードを実行して結果を確認する {#step-4-run-the-code-and-check-the-result} -1. サンプルコードを実行するには、以下のコマンドを実行してください。 +1. サンプルコードを実行するには、以下のコマンドを実行してください。 ```shell python peewee_example.py ``` -2. [期待される出力.txt](https://github.com/tidb-samples/tidb-python-peewee-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 +2. [期待される出力.txt](https://github.com/tidb-samples/tidb-python-peewee-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 ## サンプルコードスニペット {#sample-code-snippets} @@ -335,12 +335,12 @@ Player.delete().where(Player.coins == 100).execute() ## 次のステップ {#next-steps} -- Peeweeの使い方の詳細については、[Peeweeのドキュメント](https://docs.peewee-orm.com/)をご覧ください。 -- [開発者ガイド](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)、[トランザクション](/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/)を取得します。 +- Peeweeの使い方の詳細については、[Peeweeのドキュメント](https://docs.peewee-orm.com/)をご覧ください。 +- [開発者ガイド](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)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-python-pymysql.md b/develop/dev-guide-sample-application-python-pymysql.md index fd93efebbc34f..3538d13625995 100644 --- a/develop/dev-guide-sample-application-python-pymysql.md +++ b/develop/dev-guide-sample-application-python-pymysql.md @@ -10,9 +10,9 @@ TiDBはMySQL互換のデータベースであり、 [PyMySQL](https://github.com このチュートリアルでは、TiDBとPyMySQLを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- PyMySQLを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。必要に応じて、基本的なCRUD操作のサンプルコードスニペットも利用できます。 +- 環境をセットアップしてください。 +- PyMySQLを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。必要に応じて、基本的なCRUD操作のサンプルコードスニペットも利用できます。 > **Note:** > @@ -22,14 +22,14 @@ TiDBはMySQL互換のデータベースであり、 [PyMySQL](https://github.com このチュートリアルを完了するには、以下が必要です。 -- [Python 3.8以降](https://www.python.org/downloads/)。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- [Python 3.8以降](https://www.python.org/downloads/)。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -59,37 +59,37 @@ pip install -r requirements.txt
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. gateway01.ap-northeast-1.prod.aws.tidbcloud.com @@ -102,37 +102,37 @@ pip install -r requirements.txt 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -144,28 +144,28 @@ pip install -r requirements.txt 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -178,18 +178,18 @@ pip install -r requirements.txt 必ず、プレースホルダー`{}`を接続ダイアログから取得した接続パラメータに置き換え、 `CA_PATH`前の手順でダウンロードした証明書のパスに設定してください。 -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{tidb_server_host}' @@ -201,20 +201,20 @@ pip install -r requirements.txt プレースホルダー`{}`を接続パラメータに置き換え、 `CA_PATH`の行を削除してください。TiDB をローカルで実行している場合、デフォルトのホスト アドレスは`127.0.0.1`で、パスワードは空欄です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
### ステップ4：コードを実行して結果を確認する {#step-4-run-the-code-and-check-the-result} -1. サンプルコードを実行するには、以下のコマンドを実行してください。 +1. サンプルコードを実行するには、以下のコマンドを実行してください。 ```shell python pymysql_example.py ``` -2. [期待される出力.txt](https://github.com/tidb-samples/tidb-python-pymysql-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 +2. [期待される出力.txt](https://github.com/tidb-samples/tidb-python-pymysql-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 ## サンプルコードスニペット {#sample-code-snippets} @@ -304,23 +304,23 @@ with get_connection(autocommit=True) as conn: Pythonドライバはデータベースへの低レベルアクセスを提供するが、開発者には以下のことが必要となる。 -- データベース接続を手動で確立および解放します。 -- データベースのトランザクションを手動で管理する。 -- データ行（ `pymysql`ではタプルまたは辞書として表現されます）をデータオブジェクトに手動でマッピングします。 +- データベース接続を手動で確立および解放します。 +- データベースのトランザクションを手動で管理する。 +- データ行（ `pymysql`ではタプルまたは辞書として表現されます）をデータオブジェクトに手動でマッピングします。 複雑なSQL文を書く必要がない限り、 [SQLAlchemy](/develop/dev-guide-sample-application-python-sqlalchemy.md) 、 [Peewee](/develop/dev-guide-sample-application-python-peewee.md)、Django ORMなどの[ORM](https://en.wikipedia.org/w/index.php?title=Object-relational_mapping)フレームワークを開発に使用することをお勧めします。これにより、次のようなメリットが得られます。 -- 接続とトランザクションを管理するための[定型コード](https://en.wikipedia.org/wiki/Boilerplate_code)を削減します。 -- 多数のSQL文の代わりに、データオブジェクトを使用してデータを操作します。 +- 接続とトランザクションを管理するための[定型コード](https://en.wikipedia.org/wiki/Boilerplate_code)を削減します。 +- 多数のSQL文の代わりに、データオブジェクトを使用してデータを操作します。 ## 次のステップ {#next-steps} -- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/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/)を取得します。 +- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-python-sqlalchemy.md b/develop/dev-guide-sample-application-python-sqlalchemy.md index 3566c7389d8fa..479335fb4a0be 100644 --- a/develop/dev-guide-sample-application-python-sqlalchemy.md +++ b/develop/dev-guide-sample-application-python-sqlalchemy.md @@ -10,9 +10,9 @@ TiDBはMySQL互換のデータベースであり、 [SQLAlchemy](https://www.sql このチュートリアルでは、TiDBとSQLAlchemyを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- SQLAlchemyを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。必要に応じて、基本的なCRUD操作のサンプルコードスニペットも利用できます。 +- 環境をセットアップしてください。 +- SQLAlchemyを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。必要に応じて、基本的なCRUD操作のサンプルコードスニペットも利用できます。 > **Note:** > @@ -22,14 +22,14 @@ TiDBはMySQL互換のデータベースであり、 [SQLAlchemy](https://www.sql このチュートリアルを完了するには、以下が必要です。 -- [Python 3.8以降](https://www.python.org/downloads/)。 -- [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- [Python 3.8以降](https://www.python.org/downloads/)。 +- [Git](https://git-scm.com/downloads) 。 +- TiDBクラスタ。 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -69,37 +69,37 @@ SQLAlchemyは、複数のデータベースを扱うORMライブラリです。 > > 現在、 TiDB Cloud Starterインスタンスには制限があります。5 分間アクティブな接続がない場合、インスタンスはシャットダウンし、すべての接続が閉じられます。そのため、 TiDB Cloud Starterインスタンスで SQLAlchemy を使用する場合、プールされた接続で`OperationalError`のような`Lost connection to MySQL server during query`や`MySQL Connection not available`発生する可能性があります。このエラーを回避するには、 `pool_recycle`パラメータを`300`に設定してください。詳細については、SQLAlchemy ドキュメントの[接続切れへの対処](https://docs.sqlalchemy.org/en/20/core/pooling.html#dealing-with-disconnects)を参照してください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 + - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 + - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 + - **Connect With**は`General`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - お使いの環境に合った**Operating System**を選択してください。 > **Tip:** > > プログラムがWindows Subsystem for Linux（WSL）上で実行されている場合は、対応するLinuxディストリビューションに切り替えてください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. gateway01.ap-northeast-1.prod.aws.tidbcloud.com @@ -112,37 +112,37 @@ SQLAlchemyは、複数のデータベースを扱うORMライブラリです。 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +8. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -154,28 +154,28 @@ SQLAlchemyは、複数のデータベースを扱うORMライブラリです。 必ずプレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。 -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +5. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{host}' # e.g. tidb.xxxx.clusters.tidb-cloud.com @@ -188,18 +188,18 @@ SQLAlchemyは、複数のデータベースを扱うORMライブラリです。 必ず、プレースホルダー`{}`を接続ダイアログから取得した接続パラメータに置き換え、 `CA_PATH`前の手順でダウンロードした証明書のパスに設定してください。 -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +2. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{tidb_server_host}' @@ -211,20 +211,20 @@ SQLAlchemyは、複数のデータベースを扱うORMライブラリです。 プレースホルダー`{}`を接続パラメータに置き換え、 `CA_PATH`の行を削除してください。TiDB をローカルで実行している場合、デフォルトのホスト アドレスは`127.0.0.1`で、パスワードは空欄です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
### ステップ4：コードを実行して結果を確認する {#step-4-run-the-code-and-check-the-result} -1. サンプルコードを実行するには、以下のコマンドを実行してください。 +1. サンプルコードを実行するには、以下のコマンドを実行してください。 ```shell python sqlalchemy_example.py ``` -2. [期待される出力.txt](https://github.com/tidb-samples/tidb-python-sqlalchemy-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 +2. [期待される出力.txt](https://github.com/tidb-samples/tidb-python-sqlalchemy-quickstart/blob/main/Expected-Output.txt)をチェックして、出力が一致するかどうかを確認してください。 ## サンプルコードスニペット {#sample-code-snippets} @@ -328,12 +328,12 @@ with Session() as session: ## 次のステップ {#next-steps} -- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/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/)を取得します。 +- 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)、[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)、[トランザクション](/develop/dev-guide-transaction-overview.md)、[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md) などの章を参考に、TiDB アプリケーション開発のベストプラクティスを学びます。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-ruby-mysql2.md b/develop/dev-guide-sample-application-ruby-mysql2.md index 0644a1201b65c..1d9d370f329d3 100644 --- a/develop/dev-guide-sample-application-ruby-mysql2.md +++ b/develop/dev-guide-sample-application-ruby-mysql2.md @@ -10,9 +10,9 @@ TiDBはMySQL互換のデータベースであり、 [mysql2](https://github.com/ このチュートリアルでは、TiDBとmysql2を使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- mysql2を使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- 環境をセットアップしてください。 +- mysql2を使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 > **Note:** > @@ -22,15 +22,15 @@ TiDBはMySQL互換のデータベースであり、 [mysql2](https://github.com/ このチュートリアルを完了するには、以下が必要です。 -- [Ruby](https://www.ruby-lang.org/en/)>= 3.0 がマシンにインストールされている -- あなたのマシンにインストールされている[Bundler](https://bundler.io/) -- お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています -- TiDBクラスタが稼働中 +- [Ruby](https://www.ruby-lang.org/en/)>= 3.0 がマシンにインストールされている +- あなたのマシンにインストールされている[Bundler](https://bundler.io/) +- お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています +- TiDBクラスタが稼働中 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -70,26 +70,26 @@ bundle add mysql2 dotenv
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 - - **Branch**は`main`に設定されています。 - - **Connect With**は`General`に設定されています。 - - **Operating System**は、アプリケーションを実行するオペレーティングシステムと一致します。 + - **Connection Type**は`Public`に設定されています。 + - **Branch**は`main`に設定されています。 + - **Connect With**は`General`に設定されています。 + - **Operating System**は、アプリケーションを実行するオペレーティングシステムと一致します。 -4. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 +4. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`を接続パラメータに置き換えます。 +6. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`を接続パラメータに置き換えます。 ```dotenv DATABASE_HOST={host} @@ -104,37 +104,37 @@ bundle add mysql2 dotenv > > [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、パブリック エンドポイントを使用する際には`DATABASE_ENABLE_SSL`を介して TLS 接続を有効にする**必要があります**。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`を接続パラメータに置き換えます。 +8. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`を接続パラメータに置き換えます。 ```dotenv DATABASE_HOST={host} @@ -145,28 +145,28 @@ bundle add mysql2 dotenv DATABASE_ENABLE_SSL=false ``` -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`を接続パラメータに置き換えます。 +5. `.env`ファイルを編集し、環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`を接続パラメータに置き換えます。 ```dotenv DATABASE_HOST={host} @@ -184,18 +184,18 @@ bundle add mysql2 dotenv > > TLS接続を有効にするには、 `DATABASE_ENABLE_SSL`を`true`に変更し、 `DATABASE_SSL_CA`を使用して、接続ダイアログからダウンロードしたCA証明書のファイルパスを指定します。 -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. `.env`ファイルを編集し、環境変数を以下のように設定し、対応するプレースホルダー`{}`を独自の TiDB 接続情報に置き換えてください。 +2. `.env`ファイルを編集し、環境変数を以下のように設定し、対応するプレースホルダー`{}`を独自の TiDB 接続情報に置き換えてください。 ```dotenv DATABASE_HOST={host} @@ -207,7 +207,7 @@ bundle add mysql2 dotenv TiDBをローカルで実行している場合、デフォルトのホストアドレスは`127.0.0.1`で、パスワードは空です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
@@ -328,21 +328,21 @@ end デフォルトでは、mysql2 gem は、ファイルが見つかるまで特定の順序で既存の CA 証明書を検索できます。 -1. Debian、Ubuntu、Gentoo、Arch、またはSlackwareの場合`/etc/ssl/certs/ca-certificates.crt` -2. `/etc/pki/tls/certs/ca-bundle.crt`は RedHat、Fedora、CentOS、Mageia、Vercel、または Netlify 用です。 -3. OpenSUSE 用`/etc/ssl/ca-bundle.pem` -4. `/etc/ssl/cert.pem` macOS または Alpine (Docker コンテナ) +1. Debian、Ubuntu、Gentoo、Arch、またはSlackwareの場合`/etc/ssl/certs/ca-certificates.crt` +2. `/etc/pki/tls/certs/ca-bundle.crt`は RedHat、Fedora、CentOS、Mageia、Vercel、または Netlify 用です。 +3. OpenSUSE 用`/etc/ssl/ca-bundle.pem` +4. `/etc/ssl/cert.pem` macOS または Alpine (Docker コンテナ) CA証明書のパスを手動で指定することも可能ですが、異なるマシンや環境によってCA証明書の保存場所が異なる可能性があるため、複数の環境に展開するシナリオでは大きな不便が生じる可能性があります。そのため、柔軟性と異なる環境への展開の容易性を考慮して、 `sslca`を`nil`に設定することをお勧めします。 ## 次のステップ {#next-steps} -- mysql2 ドライバーの使用方法の詳細については[mysql2のドキュメント](https://github.com/brianmario/mysql2#readme)を参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読ん[クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 -- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 +- 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/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sample-application-ruby-rails.md b/develop/dev-guide-sample-application-ruby-rails.md index be644d5a73b47..19e59e194ec06 100644 --- a/develop/dev-guide-sample-application-ruby-rails.md +++ b/develop/dev-guide-sample-application-ruby-rails.md @@ -10,9 +10,9 @@ TiDBはMySQL互換のデータベースであり、 [Rails](https://github.com/r このチュートリアルでは、TiDBとRailsを使用して以下のタスクを実行する方法を学ぶことができます。 -- 環境をセットアップしてください。 -- Railsを使用してTiDBに接続します。 -- アプリケーションをビルドして実行します。オプションで、ActiveRecord ORM を使用した基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 +- 環境をセットアップしてください。 +- Railsを使用してTiDBに接続します。 +- アプリケーションをビルドして実行します。オプションで、ActiveRecord ORM を使用した基本的な CRUD 操作用の[サンプルコードスニペット](#sample-code-snippets)を見つけることができます。 > **Note:** > @@ -22,15 +22,15 @@ TiDBはMySQL互換のデータベースであり、 [Rails](https://github.com/r このチュートリアルを完了するには、以下が必要です。 -- [Ruby](https://www.ruby-lang.org/en/)>= 3.0 がマシンにインストールされている -- あなたのマシンにインストールされている[Bundler](https://bundler.io/) -- お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています -- TiDBクラスタが稼働中 +- [Ruby](https://www.ruby-lang.org/en/)>= 3.0 がマシンにインストールされている +- あなたのマシンにインストールされている[Bundler](https://bundler.io/) +- お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています +- TiDBクラスタが稼働中 **TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** -- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) +- (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [ローカルテスト用のTiDB Self-Managedクラスタをデプロイ](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番のTiDB Self-Managedクラスタをデプロイ](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -70,21 +70,21 @@ bundle add mysql2 dotenv
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、**Connect With**ドロップダウンリストから`Rails`を選択し、 **Connection Type**のデフォルト設定を`Public`のままにします。 +3. 接続ダイアログで、**Connect With**ドロップダウンリストから`Rails`を選択し、 **Connection Type**のデフォルト設定を`Public`のままにします。 -4. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 +4. まだパスワードを設定していない場合は、 **Generate Password**をクリックしてランダムなパスワードを生成してください。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. `.env`ファイルを編集し、 `DATABASE_URL`環境変数を次のように設定し、接続ダイアログから接続文字列をコピーして変数の値として使用します。 +6. `.env`ファイルを編集し、 `DATABASE_URL`環境変数を次のように設定し、接続ダイアログから接続文字列をコピーして変数の値として使用します。 ```dotenv DATABASE_URL='mysql2://{user}:{password}@{host}:{port}/{database_name}?ssl_mode=verify_identity' @@ -94,64 +94,64 @@ bundle add mysql2 dotenv > > [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、パブリックエンドポイントを使用する際には、 `ssl_mode=verify_identity`クエリパラメータを使用して TLS 接続を有効にする**必要があります**。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックし、次に**Add IP Address**をクリックします。 クライアントのIPアドレスがアクセスリストに追加されていることを確認してください。 -4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 +4. 左側のナビゲーションペインで**Overview**をクリックすると、インスタンスの概要ページに戻ります。 -5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +5. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 +6. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択します。 - - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 - - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 - - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 - - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 + - 公開エンドポイントがまだ有効化中であることを示すメッセージが表示された場合は、処理が完了するまでお待ちください。 + - まだパスワードを設定していない場合は、ダイアログの**Set Root Password**をクリックしてください。 + - サーバー証明書を確認する必要がある場合、または接続に失敗して認証局（CA）証明書が必要な場合は、 **CA cert**をクリックしてダウンロードしてください。 + - **Public**接続タイプに加えて、 TiDB Cloud Premium は**Private Endpoint**接続をサポートします。詳細については、 [AWS PrivateLink経由でTiDB Cloud Premiumに接続します](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)を参照してください。 -7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +7. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -8. `.env`ファイルを編集し、 `DATABASE_URL`環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`接続パラメータに置き換えます。 +8. `.env`ファイルを編集し、 `DATABASE_URL`環境変数を以下のように設定し、接続ダイアログで対応するプレースホルダー`{}`接続パラメータに置き換えます。 ```dotenv DATABASE_URL='mysql2://{user}:{password}@{host}:{port}/{database_name}' ``` -9. `.env`ファイルを保存します。 +9. `.env`ファイルを保存します。
-1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **CA cert**をクリックしてCA証明書をダウンロードします。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)の手順に従って設定します。 TiDB Cloud Dedicated は、**Public**接続タイプに加えて、**Private Endpoint**および**VPC Peering**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)を参照してください。 -4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -5. `.env`ファイルを編集し、 `DATABASE_URL`環境変数を次のように設定し、接続ダイアログから接続文字列をコピーして変数の値として設定し、 `sslca`クエリパラメータを接続ダイアログからダウンロードした CA 証明書のファイルパスに設定します。 +5. `.env`ファイルを編集し、 `DATABASE_URL`環境変数を次のように設定し、接続ダイアログから接続文字列をコピーして変数の値として設定し、 `sslca`クエリパラメータを接続ダイアログからダウンロードした CA 証明書のファイルパスに設定します。 ```dotenv DATABASE_URL='mysql2://{user}:{password}@{host}:{port}/{database}?ssl_mode=verify_identity&sslca=/path/to/ca.pem' @@ -163,18 +163,18 @@ bundle add mysql2 dotenv > > TLS接続を有効にするには、 `ssl_mode`クエリパラメータの値を`verify_identity`に変更し、 `sslca`の値を接続ダイアログからダウンロードしたCA証明書のファイルパスに変更してください。 -6. `.env`ファイルを保存します。 +6. `.env`ファイルを保存します。
-1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +1. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -2. `.env`ファイルを編集し、 `DATABASE_URL`環境変数を次のように設定し、 `{user}` 、 `{password}` 、 `{host}` 、 `{port}` 、および`{database}`独自の TiDB 接続情報に置き換えてください。 +2. `.env`ファイルを編集し、 `DATABASE_URL`環境変数を次のように設定し、 `{user}` 、 `{password}` 、 `{host}` 、 `{port}` 、および`{database}`独自の TiDB 接続情報に置き換えてください。 ```dotenv DATABASE_URL='mysql2://{user}:{password}@{host}:{port}/{database}' @@ -182,27 +182,27 @@ bundle add mysql2 dotenv TiDBをローカルで実行している場合、デフォルトのホストアドレスは`127.0.0.1`で、パスワードは空です。 -3. `.env`ファイルを保存します。 +3. `.env`ファイルを保存します。
### ステップ4：コードを実行して結果を確認する {#step-4-run-the-code-and-check-the-result} -1. データベースとテーブルを作成します。 +1. データベースとテーブルを作成します。 ```shell bundle exec rails db:create bundle exec rails db:migrate ``` -2. サンプルデータにシード値を設定します。 +2. サンプルデータにシード値を設定します。 ```shell bundle exec rails db:seed ``` -3. サンプルコードを実行するには、以下のコマンドを実行してください。 +3. サンプルコードを実行するには、以下のコマンドを実行してください。 ```shell bundle exec rails runner ./quickstart.rb @@ -297,21 +297,21 @@ player.destroy デフォルトでは、mysql2 gem（ActiveRecord ORMがTiDBに接続するために使用）は、ファイルが見つかるまで特定の順序で既存のCA証明書を検索します。 -1. /etc/ssl/certs/ca-certificates.crt # Debian / Ubuntu / Gentoo / Arch / Slackware -2. /etc/pki/tls/certs/ca-bundle.crt # RedHat / Fedora / CentOS / Mageia / Vercel / Netlify -3. /etc/ssl/ca-bundle.pem # OpenSUSE -4. /etc/ssl/cert.pem # MacOS / Alpine (Dockerコンテナ) +1. /etc/ssl/certs/ca-certificates.crt # Debian / Ubuntu / Gentoo / Arch / Slackware +2. /etc/pki/tls/certs/ca-bundle.crt # RedHat / Fedora / CentOS / Mageia / Vercel / Netlify +3. /etc/ssl/ca-bundle.pem # OpenSUSE +4. /etc/ssl/cert.pem # MacOS / Alpine (Dockerコンテナ) CA証明書のパスを手動で指定することも可能ですが、異なるマシンや環境によってCA証明書の保存場所が異なる場合があるため、複数の環境に展開するシナリオでは、この方法は大きな不便をもたらす可能性があります。そのため、 `sslca`を`nil`に設定することで、柔軟性と異なる環境への展開の容易性を確保できます。 ## 次のステップ {#next-steps} -- ActiveRecord ORM の使用法について詳しくは[ActiveRecordのドキュメント](https://guides.rubyonrails.org/active_record_basics.html)ご覧ください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、[クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 -- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 +- ActiveRecord ORM の使用法について詳しくは[ActiveRecordのドキュメント](https://guides.rubyonrails.org/active_record_basics.html)ご覧ください。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、[クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 +- プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-schema-design-overview.md b/develop/dev-guide-schema-design-overview.md index eb2e814dbfdc4..f6acee8f90bb7 100644 --- a/develop/dev-guide-schema-design-overview.md +++ b/develop/dev-guide-schema-design-overview.md @@ -14,9 +14,9 @@ aliases: ['/ja/tidb/stable/dev-guide-schema-design-overview/','/ja/tidb/dev/dev- 一般的な用語を区別するために、TiDBで使用される用語に関する簡単な合意事項を以下に示します。 -- 一般的な用語との混同を避けるため 本ドキュメントでは、**データベース**とは論理オブジェクトを指し、 **TiDBと**[データベース](https://en.wikipedia.org/wiki/Database)TiDB自体を指し、**クラスターとは**実行中のTiDBデプロイメントを指します。 +- 一般的な用語との混同を避けるため 本ドキュメントでは、**データベース**とは論理オブジェクトを指し、 **TiDBと**[データベース](https://en.wikipedia.org/wiki/Database)TiDB自体を指し、**クラスターとは**実行中のTiDBデプロイメントを指します。 -- TiDB は MySQL 互換の構文を使用します。この**構文**では、スキーマはデータベース内の論理オブジェクトの代わりに一般用語[スキーマ](https://en.wiktionary.org/wiki/schema)を意味します。詳細については、 [MySQLドキュメント](https://dev.mysql.com/doc/refman/8.0/en/create-database.html)を参照してください。スキーマを論理オブジェクトとして持つデータベース (たとえば、 [PostgreSQL](https://www.postgresql.org/docs/current/ddl-schemas.html) 、 [オラクル](https://docs.oracle.com/en/database/oracle/oracle-database/21/tdddg/creating-managing-schema-objects.html)、 [Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/relational-databases/security/authentication-access/create-a-database-schema?view=sql-server-ver15) ) から移行する場合は、この違いに必ず注意してください。 +- TiDB は MySQL 互換の構文を使用します。この**構文**では、スキーマはデータベース内の論理オブジェクトの代わりに一般用語[スキーマ](https://en.wiktionary.org/wiki/schema)を意味します。詳細については、 [MySQLドキュメント](https://dev.mysql.com/doc/refman/8.0/en/create-database.html)を参照してください。スキーマを論理オブジェクトとして持つデータベース (たとえば、 [PostgreSQL](https://www.postgresql.org/docs/current/ddl-schemas.html) 、 [オラクル](https://docs.oracle.com/en/database/oracle/oracle-database/21/tdddg/creating-managing-schema-objects.html)、 [Microsoft SQL Server](https://docs.microsoft.com/en-us/sql/relational-databases/security/authentication-access/create-a-database-schema?view=sql-server-ver15) ) から移行する場合は、この違いに必ず注意してください。 ### データベース {#database} @@ -36,15 +36,15 @@ TiDBには`test`という名前のデフォルトデータベースが付属し インデックスには大きく分けて2種類あります。 -- **主キー**：主キー列に対するインデックス。 -- **セカンダリインデックス**：主キー以外の列に設定されるインデックス。 +- **主キー**：主キー列に対するインデックス。 +- **セカンダリインデックス**：主キー以外の列に設定されるインデックス。 > **Note:** > > 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)を参照してください。 +> - InnoDBでは、**主キー**の定義は一意であり、nullではなく、**クラスター化されたインデックス**です。 +> - TiDB では、**プライマリ キー**の定義は一意であり、NULL ではありません。ただし、プライマリ キーが**クラスター化インデックス**であるとは限りません。プライマリ キーがクラスター化インデックスであるかどうかを指定するには、 `CLUSTERED`ステートメントの`NONCLUSTERED`の後に、予約されていないキーワード`PRIMARY KEY`または`CREATE TABLE`追加します。ステートメントでこれらのキーワードが明示的に指定されていない場合、デフォルトの動作はシステム変数`@@global.tidb_enable_clustered_index`によって制御されます。詳細については、[クラスター化インデックス](/clustered-indexes.md)を参照してください。 #### 専門索引 {#specialized-indexes} @@ -54,9 +54,9 @@ TiDBには`test`という名前のデフォルトデータベースが付属し TiDBは、**テーブル**と同じレベルで以下の論理オブジェクトをサポートしています。 -- [ビュー](/views.md): ビューは仮想テーブルとして機能し、そのスキーマはビューを作成する`SELECT`ステートメントによって定義されます。 -- [シーケンス](/sql-statements/sql-statement-create-sequence.md): シーケンスはシーケンシャルデータを生成し、保存します。 -- [一時テーブル](/temporary-tables.md): データが永続的ではないテーブル。 +- [ビュー](/views.md): ビューは仮想テーブルとして機能し、そのスキーマはビューを作成する`SELECT`ステートメントによって定義されます。 +- [シーケンス](/sql-statements/sql-statement-create-sequence.md): シーケンスはシーケンシャルデータを生成し、保存します。 +- [一時テーブル](/temporary-tables.md): データが永続的ではないテーブル。 ## アクセス制御 {#access-control} @@ -72,6 +72,6 @@ TiDB は、ユーザーベースとロールベースの両方のアクセス制 ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-sql-development-specification.md b/develop/dev-guide-sql-development-specification.md index 86792a165a823..fbce3bd9bb5f5 100644 --- a/develop/dev-guide-sql-development-specification.md +++ b/develop/dev-guide-sql-development-specification.md @@ -10,18 +10,18 @@ aliases: ['/ja/tidb/stable/dev-guide-sql-development-specification/','/ja/tidbcl ## テーブルの作成と削除 {#create-and-delete-tables} -- 基本原則: テーブル命名規則に従うことを前提として、アプリケーションがテーブルの作成および削除ステートメントを内部的にパッケージ化し、ビジネスプロセスの異常な中断を防ぐための判断ロジックを追加することをお勧めします。 -- 詳細: アプリケーション側で異常に実行された SQL コマンドによる異常な中断を回避するために、 `if`判断を追加するには、 `create table if not exists table_name`または`drop table if exists table_name`ステートメントを推奨します。 +- 基本原則: テーブル命名規則に従うことを前提として、アプリケーションがテーブルの作成および削除ステートメントを内部的にパッケージ化し、ビジネスプロセスの異常な中断を防ぐための判断ロジックを追加することをお勧めします。 +- 詳細: アプリケーション側で異常に実行された SQL コマンドによる異常な中断を回避するために、 `if`判断を追加するには、 `create table if not exists table_name`または`drop table if exists table_name`ステートメントを推奨します。 ## `SELECT *`の使用法 {#select-usage} -- 基本原則: クエリに`SELECT *`を使用しないでください。 -- 詳細：必要に応じて適切な列を選択し、 `SELECT *`を使用してすべてのフィールドを読み取ることは避けてください。このような操作はネットワーク帯域幅を消費するためです。カバリングインデックスを効果的に活用するには、クエリ対象のフィールドをインデックスに追加することを検討してください。 +- 基本原則: クエリに`SELECT *`を使用しないでください。 +- 詳細：必要に応じて適切な列を選択し、 `SELECT *`を使用してすべてのフィールドを読み取ることは避けてください。このような操作はネットワーク帯域幅を消費するためです。カバリングインデックスを効果的に活用するには、クエリ対象のフィールドをインデックスに追加することを検討してください。 ## フィールドで関数を使用する {#use-functions-on-fields} -- 基本原則：クエリ対象のフィールドに対して関連関数を使用できます。インデックスの失敗を避けるため、 `WHERE`句のフィルタリング対象フィールドに対しては、データ型変換関数を含むいかなる関数も使用しないでください。式インデックスの使用を検討してください。 -- 詳細な説明: +- 基本原則：クエリ対象のフィールドに対して関連関数を使用できます。インデックスの失敗を避けるため、 `WHERE`句のフィルタリング対象フィールドに対しては、データ型変換関数を含むいかなる関数も使用しないでください。式インデックスの使用を検討してください。 +- 詳細な説明: 推奨されません: @@ -41,17 +41,17 @@ aliases: ['/ja/tidb/stable/dev-guide-sql-development-specification/','/ja/tidbcl ## その他の仕様 {#other-specifications} -- 条件`WHERE`のインデックス列に対して数学演算や関数を実行しないでください。 -- `OR`を`IN`または`UNION`に置き換えてください。`IN`の数は`300`未満でなければなりません。 -- あいまいプレフィックスクエリには`%`プレフィックスを使用しないでください。 -- アプリケーションが**マルチステートメント**を使用して SQL を実行する場合、つまり複数の SQL がセミコロンで結合され、一度にクライアントに送信されて実行される場合、TiDB は最初の SQL 実行の結果のみを返します。 -- 式を使用する場合は、その式がストレージレイヤー（TiKVまたはTiFlash ）へのコンピューティングのプッシュダウンをサポートしているかどうかを確認してください。サポートされていない場合は、TiDBレイヤーでメモリ消費量が増加し、OOMが発生する可能性が高くなります。ストレージレイヤーにプッシュダウンできるコンピューティングは以下の通りです。 - - [TiFlashはプッシュダウン計算をサポート](/tiflash/tiflash-supported-pushdown-calculations.md) 。 - - [TiKV - プッシュダウンの式一覧](/functions-and-operators/expressions-pushed-down.md) 。 - - [述語プッシュダウン](/predicate-push-down.md) 。 +- 条件`WHERE`のインデックス列に対して数学演算や関数を実行しないでください。 +- `OR`を`IN`または`UNION`に置き換えてください。`IN`の数は`300`未満でなければなりません。 +- あいまいプレフィックスクエリには`%`プレフィックスを使用しないでください。 +- アプリケーションが**マルチステートメント**を使用して SQL を実行する場合、つまり複数の SQL がセミコロンで結合され、一度にクライアントに送信されて実行される場合、TiDB は最初の SQL 実行の結果のみを返します。 +- 式を使用する場合は、その式がストレージレイヤー（TiKVまたはTiFlash ）へのコンピューティングのプッシュダウンをサポートしているかどうかを確認してください。サポートされていない場合は、TiDBレイヤーでメモリ消費量が増加し、OOMが発生する可能性が高くなります。ストレージレイヤーにプッシュダウンできるコンピューティングは以下の通りです。 + - [TiFlashはプッシュダウン計算をサポート](/tiflash/tiflash-supported-pushdown-calculations.md) 。 + - [TiKV - プッシュダウンの式一覧](/functions-and-operators/expressions-pushed-down.md) 。 + - [述語プッシュダウン](/predicate-push-down.md) 。 ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-third-party-support.md b/develop/dev-guide-third-party-support.md index 9b89ee34c5a23..7c2f976377ee9 100644 --- a/develop/dev-guide-third-party-support.md +++ b/develop/dev-guide-third-party-support.md @@ -16,8 +16,8 @@ TiDB は[MySQLプロトコルとの高い互換性](/mysql-compatibility.md)あ PingCAP はコミュニティと連携し、サードパーティ ツールに対して次のサポート レベルを提供します。 -- ***完全***：TiDB は対応するサードパーティ製ツールのほとんどの機能と既に互換性があり、最新バージョンとの互換性も維持していることを示します。PingCAP は、ツールの最新バージョンとの互換性テストを定期的に実施します。 -- ***互換***：対応するサードパーティ製ツールがMySQLに適合しており、TiDBはMySQLプロトコルと高い互換性があるため、TiDBはツールのほとんどの機能を使用できることを示します。ただし、PingCAPはツールのすべての機能について完全なテストを完了していないため、予期しない動作が発生する可能性があります。 +- ***完全***：TiDB は対応するサードパーティ製ツールのほとんどの機能と既に互換性があり、最新バージョンとの互換性も維持していることを示します。PingCAP は、ツールの最新バージョンとの互換性テストを定期的に実施します。 +- ***互換***：対応するサードパーティ製ツールがMySQLに適合しており、TiDBはMySQLプロトコルと高い互換性があるため、TiDBはツールのほとんどの機能を使用できることを示します。ただし、PingCAPはツールのすべての機能について完全なテストを完了していないため、予期しない動作が発生する可能性があります。 > **Note:** > @@ -63,6 +63,6 @@ PingCAP はコミュニティと連携し、サードパーティ ツールに ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-third-party-tools-compatibility.md b/develop/dev-guide-third-party-tools-compatibility.md index d2a87e2267dc6..37355eb2dc7a9 100644 --- a/develop/dev-guide-third-party-tools-compatibility.md +++ b/develop/dev-guide-third-party-tools-compatibility.md @@ -10,12 +10,12 @@ aliases: ['/ja/tidb/stable/dev-guide-third-party-tools-compatibility/','/ja/tidb > > [サポートされていない機能](/mysql-compatibility.md#unsupported-features)セクションには、次のものを含む、TiDB でサポートされていない機能がリストされています。 > -> - ストアドプロシージャと関数 -> - トリガー -> - イベント -> - ユーザー定義関数 -> - `SPATIAL`関数、データ型、インデックス -> - `XA`構文 +> - ストアドプロシージャと関数 +> - トリガー +> - イベント +> - ユーザー定義関数 +> - `SPATIAL`関数、データ型、インデックス +> - `XA`構文 > > 上記の機能がサポートされていないのは想定された動作であり、このドキュメントには記載されていません。詳細については、 [MySQLとの互換性](/mysql-compatibility.md)を参照してください。 @@ -43,8 +43,8 @@ MySQLは、データベースに対して実行された操作の合計数を追 これらの変数は使用しないでください。よくあるシナリオの一つは監視です。TiDBは監視性に優れているため、サーバーステータス変数からのクエリは必要ありません。監視サービスの詳細については、以下のドキュメントを参照してください。 -- TiDB Cloudドキュメント: [TiDBクラスタを監視する](/tidb-cloud/monitor-tidb-cluster.md) . -- TiDB Self-Managed ドキュメント: [TiDB 監視フレームワークの概要](/tidb-monitoring-framework.md) . +- TiDB Cloudドキュメント: [TiDBクラスタを監視する](/tidb-cloud/monitor-tidb-cluster.md) . +- TiDB Self-Managed ドキュメント: [TiDB 監視フレームワークの概要](/tidb-monitoring-framework.md) . ### TiDBはエラーメッセージで`TIMESTAMP`と`DATETIME`を区別します {#tidb-distinguishes-between-timestamp-and-datetime-in-error-messages} @@ -104,8 +104,8 @@ TiDB では`NO_BACKSLASH_ESCAPES`と`\`を使用しないでください。SQL TiDBはプロトコルのパラメータ`SERVER_QUERY_NO_GOOD_INDEX_USED`と`SERVER_QUERY_NO_INDEX_USED`を設定しません。そのため、以下のパラメータが実際の状況と矛盾した値として返されます。 -- `com.mysql.cj.protocol.ServerSession.noIndexUsed()` -- `com.mysql.cj.protocol.ServerSession.noGoodIndexUsed()` +- `com.mysql.cj.protocol.ServerSession.noIndexUsed()` +- `com.mysql.cj.protocol.ServerSession.noGoodIndexUsed()` **回避方法** @@ -159,8 +159,8 @@ MySQL Connector/J 8.0.31 以前のバージョンを、MySQL サーバー 5.7.5 TiDB では、次の方法でもこれを修正します。 -- クライアント側: このバグは**pingcap/mysql-connector-j**で修正されており、公式の MySQL Connector/J の代わりに[pingcap/mysql-connector-j](https://github.com/pingcap/mysql-connector-j)を使用できます。 -- サーバー側: この互換性の問題は TiDB v6.3.0 以降で修正されており、サーバーをv6.3.0 以降のバージョンにアップグレードできます。 +- クライアント側: このバグは**pingcap/mysql-connector-j**で修正されており、公式の MySQL Connector/J の代わりに[pingcap/mysql-connector-j](https://github.com/pingcap/mysql-connector-j)を使用できます。 +- サーバー側: この互換性の問題は TiDB v6.3.0 以降で修正されており、サーバーをv6.3.0 以降のバージョンにアップグレードできます。 ## Sequelizeとの互換性 {#compatibility-with-sequelize} @@ -170,15 +170,15 @@ TiDB では、次の方法でもこれを修正します。 サポートされていない機能は次のとおりです。 -- [`GEOMETRY`](https://github.com/pingcap/tidb/issues/6347)はサポートされていません。 -- 整数主キーの変更はサポートされていません。 -- `PROCEDURE`はサポートされていません。 -- `READ-UNCOMMITTED`と`SERIALIZABLE` [分離レベル](/system-variables.md#transaction_isolation)はサポートされていません。 -- 列の`AUTO_INCREMENT`属性の変更はデフォルトでは許可されません。 -- `FULLTEXT` 、 `HASH` 、 `SPATIAL`インデックスはサポートされていません。 -- `sequelize.queryInterface.showIndex(Model.tableName);`はサポートされていません。 -- `sequelize.options.databaseVersion`はサポートされていません。 -- [`queryInterface.addColumn`](https://sequelize.org/api/v6/class/src/dialects/abstract/query-interface.js~queryinterface#instance-method-addColumn)を使用した外部キ​​ー参照の追加はサポートされていません。 +- [`GEOMETRY`](https://github.com/pingcap/tidb/issues/6347)はサポートされていません。 +- 整数主キーの変更はサポートされていません。 +- `PROCEDURE`はサポートされていません。 +- `READ-UNCOMMITTED`と`SERIALIZABLE` [分離レベル](/system-variables.md#transaction_isolation)はサポートされていません。 +- 列の`AUTO_INCREMENT`属性の変更はデフォルトでは許可されません。 +- `FULLTEXT` 、 `HASH` 、 `SPATIAL`インデックスはサポートされていません。 +- `sequelize.queryInterface.showIndex(Model.tableName);`はサポートされていません。 +- `sequelize.options.databaseVersion`はサポートされていません。 +- [`queryInterface.addColumn`](https://sequelize.org/api/v6/class/src/dialects/abstract/query-interface.js~queryinterface#instance-method-addColumn)を使用した外部キ​​ー参照の追加はサポートされていません。 ### 整数主キーの変更はサポートされていません {#modification-of-integer-primary-key-is-not-supported} @@ -218,6 +218,6 @@ TiDB がサポートする分離レベル`REPEATABLE-READ`または`READ-COMMITT ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-tidb-basics.md b/develop/dev-guide-tidb-basics.md index 680599cd0d7bd..d61f1df3f12d1 100644 --- a/develop/dev-guide-tidb-basics.md +++ b/develop/dev-guide-tidb-basics.md @@ -7,9 +7,9 @@ summary: トランザクション メカニズムやアプリケーションが TiDB を使い始める前に、TiDB がどのように動作するかに関するいくつかの重要なメカニズムを理解する必要があります。 -- TiDB でのトランザクションの仕組みを理解するには[TiDBトランザクションの概要](/transaction-overview.md) 、アプリケーション開発に必要なトランザクションの知識については[アプリケーション開発者向けトランザクションノート](/develop/dev-guide-transaction-overview.md)をお読みください。 -- [アプリケーションがTiDBと対話する方法](#the-way-applications-interact-with-tidb)理解する。 -- 分散データベース TiDB およびTiDB Cloud を構築するためのコア コンポーネントと概念を学習するには、無料のオンライン コース[TiDBの紹介](https://eng.edu.pingcap.com/catalog/info/id:203/?utm_source=docs-dev-guide)を参照してください。 +- TiDB でのトランザクションの仕組みを理解するには[TiDBトランザクションの概要](/transaction-overview.md) 、アプリケーション開発に必要なトランザクションの知識については[アプリケーション開発者向けトランザクションノート](/develop/dev-guide-transaction-overview.md)をお読みください。 +- [アプリケーションがTiDBと対話する方法](#the-way-applications-interact-with-tidb)理解する。 +- 分散データベース TiDB およびTiDB Cloud を構築するためのコア コンポーネントと概念を学習するには、無料のオンライン コース[TiDBの紹介](https://eng.edu.pingcap.com/catalog/info/id:203/?utm_source=docs-dev-guide)を参照してください。 ## TiDBトランザクションメカニズム {#tidb-transaction-mechanisms} @@ -29,18 +29,18 @@ TiDB は MySQL プロトコルおよび MySQL 構文と互換性があるため ## 続きを読む {#read-more} -- [クイックスタート](/develop/dev-guide-build-cluster-in-cloud.md) -- [DriverまたはORMを選択](/develop/dev-guide-choose-driver-or-orm.md) -- [TiDBに接続する](https://docs.pingcap.com/tidb/v8.5/dev-guide-connect-to-tidb/) -- [データベーススキーマ設計](/develop/dev-guide-schema-design-overview.md) -- [データの書き込み](/develop/dev-guide-insert-data.md) -- [データの読み取り](/develop/dev-guide-get-data-from-single-table.md) -- [トランザクション](/develop/dev-guide-transaction-overview.md) -- [最適化する](/develop/dev-guide-optimize-sql-overview.md) -- [アプリケーション例](/develop/dev-guide-sample-application-java-spring-boot.md) +- [クイックスタート](/develop/dev-guide-build-cluster-in-cloud.md) +- [DriverまたはORMを選択](/develop/dev-guide-choose-driver-or-orm.md) +- [TiDBに接続する](https://docs.pingcap.com/tidb/v8.5/dev-guide-connect-to-tidb/) +- [データベーススキーマ設計](/develop/dev-guide-schema-design-overview.md) +- [データの書き込み](/develop/dev-guide-insert-data.md) +- [データの読み取り](/develop/dev-guide-get-data-from-single-table.md) +- [トランザクション](/develop/dev-guide-transaction-overview.md) +- [最適化する](/develop/dev-guide-optimize-sql-overview.md) +- [アプリケーション例](/develop/dev-guide-sample-application-java-spring-boot.md) ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-tidb-crud-sql.md b/develop/dev-guide-tidb-crud-sql.md index 58ca87ecd9d7b..627a03e619a8b 100644 --- a/develop/dev-guide-tidb-crud-sql.md +++ b/develop/dev-guide-tidb-crud-sql.md @@ -28,13 +28,13 @@ SQL を試して、MySQL クエリと TiDB の互換性をテストするには SQLは、その関数に応じて以下の4種類に分類されます。 -- **DDL（データ定義言語）** ：データベース、テーブル、ビュー、インデックスなどのデータベースオブジェクトを定義するために使用されます。 +- **DDL（データ定義言語）** ：データベース、テーブル、ビュー、インデックスなどのデータベースオブジェクトを定義するために使用されます。 -- **DML（データ操作言語）** ：アプリケーション関連のレコードを操作するために使用されます。 +- **DML（データ操作言語）** ：アプリケーション関連のレコードを操作するために使用されます。 -- **DQL（データクエリ言語）** ：条件付きフィルタリング後にレコードをクエリするために使用されます。 +- **DQL（データクエリ言語）** ：条件付きフィルタリング後にレコードをクエリするために使用されます。 -- **DCL（データ制御言語）** ：アクセス権限とセキュリティレベルを定義するために使用されます。 +- **DCL（データ制御言語）** ：アクセス権限とセキュリティレベルを定義するために使用されます。 以下では主にDMLとDQLについて紹介します。 DDL と DCL の詳細については、 [TiDBでSQLを探求しよう](/basic-sql-operations.md)または[SQL Statement Overview](/sql-statements/sql-statement-overview.md)を参照してください。 @@ -105,6 +105,6 @@ SELECT * FROM person WHERE id < 5; ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-time-to-live.md b/develop/dev-guide-time-to-live.md index ca3daa86f07b1..0b8b85705855f 100644 --- a/develop/dev-guide-time-to-live.md +++ b/develop/dev-guide-time-to-live.md @@ -13,9 +13,9 @@ TiDBは、TiDBデータの有効期間を行レベルで管理できる[TTL (存 TTLは、一定期間が経過するとデータがビジネス価値を失うシナリオ向けに設計されています。典型的なユースケースとしては、以下のようなものがあります。 -- 認証コードと短縮URLの記録を定期的に削除する -- 古くなった過去の注文を定期的にクリーンアップする -- 中間計算結果を自動的に削除する +- 認証コードと短縮URLの記録を定期的に削除する +- 古くなった過去の注文を定期的にクリーンアップする +- 中間計算結果を自動的に削除する > **Note:** > @@ -66,4 +66,4 @@ ALTER TABLE app_logs TTL_ENABLE = 'OFF'; ## 参照 {#see-also} -- [TTL (存続時間)](/time-to-live.md) +- [TTL (存続時間)](/time-to-live.md) diff --git a/develop/dev-guide-timeouts-in-tidb.md b/develop/dev-guide-timeouts-in-tidb.md index 0b7d2b2ab7b52..c257c3d316ee1 100644 --- a/develop/dev-guide-timeouts-in-tidb.md +++ b/develop/dev-guide-timeouts-in-tidb.md @@ -12,18 +12,18 @@ aliases: ['/ja/tidb/stable/dev-guide-timeouts-in-tidb/','/ja/tidbcloud/dev-guide TiDBのトランザクション実装では、MVCC（Multiple Version Concurrency Control：複数バージョン同時実行制御）メカニズムが採用されています。新しく書き込まれたデータが古いデータを上書きする場合、古いデータは置き換えられず、新しく書き込まれたデータと共に保持されます。バージョンはタイムスタンプによって区別されます。TiDBは、定期的なガベージコレクション（GC）メカニズムを使用して、不要になった古いデータをクリーンアップします。 -- TiDB バージョン v4.0 より前のバージョンの場合: +- TiDB バージョン v4.0 より前のバージョンの場合: デフォルトでは、各MVCCバージョン（整合性スナップショット）は10分間保持されます。読み取りに10分以上かかるトランザクションにはエラー`GC life time is shorter than transaction duration`が発生します。 -- TiDB v4.0 以降のバージョンの場合: +- TiDB v4.0 以降のバージョンの場合: 24時間を超えない実行中のトランザクションの場合、トランザクション実行中はガベージコレクション（GC）がブロックされます。エラー`GC life time is shorter than transaction duration`は発生しません。 一時的に読み取り時間を長くする必要がある場合は、MVCC バージョンの保持時間を長くすることができます。 -- v5.0 より前の TiDB バージョンの場合: TiDB の`mysql.tidb`のテーブルの`tikv_gc_life_time`調整します。 -- TiDB v5.0 以降のバージョンの場合: システム変数[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)を調整します。 +- v5.0 より前の TiDB バージョンの場合: TiDB の`mysql.tidb`のテーブルの`tikv_gc_life_time`調整します。 +- TiDB v5.0 以降のバージョンの場合: システム変数[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)を調整します。 システム変数の設定はグローバルかつ即座に反映されます。値を増やすと既存のスナップショットの有効期間が延長され、値を減らすとすべてのスナップショットの有効期間が即座に短縮されます。MVCCのバージョンが多すぎると、TiDBクラスタのパフォーマンスに影響します。そのため、この変数は適切なタイミングで以前の設定に戻す必要があります。 @@ -33,8 +33,8 @@ TiDBのトランザクション実装では、MVCC（Multiple Version Concurrenc > > ただし、次のいずれかのシナリオでは、 Dumpling はGC 時間を自動的に調整できません。 > -> - データサイズが非常に大きい（1 TB 以上）。 -> - Dumpling はPD に直接接続できません。たとえば、 TiDB クラスターはTiDB Cloud上、またはDumplingとは分離された Kubernetes 上にあります。 +> - データサイズが非常に大きい（1 TB 以上）。 +> - Dumpling はPD に直接接続できません。たとえば、 TiDB クラスターはTiDB Cloud上、またはDumplingとは分離された Kubernetes 上にあります。 > > このようなシナリオでは、エクスポート プロセス中の GC によるエクスポートの失敗を回避するために、事前に GC 時間を手動で延長する必要があります。 > @@ -64,17 +64,17 @@ v6.1.0 以降では、 [`enable-global-kill`](/tidb-configuration-file.md#enable TiDB は、次の MySQL 互換のタイムアウト制御パラメータを提供します。 -- **wait_timeout は**、 Javaアプリケーションへの接続における非対話型アイドルタイムアウトを制御します。TiDB v5.4以降では、デフォルト値は`wait_timeout`で、これは`28800`秒（8時間）です。TiDB v5.4より前のバージョンでは、デフォルト値は`0`で、これはタイムアウトが無制限であることを意味します。 -- **interactive_timeout は**、 Javaアプリケーションへの接続における対話型アイドルタイムアウトを制御します。デフォルトの値は`8 hours`です。 -- **max_execution_time は**、接続におけるSQL実行のタイムアウトを制御します。この値は、 `SELECT`文（ `SELECT ... FOR UPDATE`文を含む）の場合のみ有効です。デフォルト値は`0`で、接続が無限にビジー状態になることを許可します。つまり、SQL文は無限に長い時間実行されます。 +- **wait_timeout は**、 Javaアプリケーションへの接続における非対話型アイドルタイムアウトを制御します。TiDB v5.4以降では、デフォルト値は`wait_timeout`で、これは`28800`秒（8時間）です。TiDB v5.4より前のバージョンでは、デフォルト値は`0`で、これはタイムアウトが無制限であることを意味します。 +- **interactive_timeout は**、 Javaアプリケーションへの接続における対話型アイドルタイムアウトを制御します。デフォルトの値は`8 hours`です。 +- **max_execution_time は**、接続におけるSQL実行のタイムアウトを制御します。この値は、 `SELECT`文（ `SELECT ... FOR UPDATE`文を含む）の場合のみ有効です。デフォルト値は`0`で、接続が無限にビジー状態になることを許可します。つまり、SQL文は無限に長い時間実行されます。 しかし、実際の本番環境では、アイドル接続とSQL文の無期限実行は、データベースとアプリケーションの両方に悪影響を及ぼします。アプリケーションの接続文字列でこれら2つのセッションレベル変数を設定することで、アイドル接続とSQL文の無期限実行を回避できます。例えば、次のように設定します。 -- `sessionVariables=wait_timeout=3600` （1時間） -- `sessionVariables=max_execution_time=300000` （5分） +- `sessionVariables=wait_timeout=3600` （1時間） +- `sessionVariables=max_execution_time=300000` （5分） ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-transaction-overview.md b/develop/dev-guide-transaction-overview.md index 5499b9e54ae9c..77bb1fdeed940 100644 --- a/develop/dev-guide-transaction-overview.md +++ b/develop/dev-guide-transaction-overview.md @@ -130,10 +130,10 @@ SELECT * FROM `users`; SQL-92 標準では、次の 4 つの分離レベルが定義されています。 -- コミットされていない読み取り ( `READ UNCOMMITTED` ) -- コミットされた読み取り ( `READ COMMITTED` ) -- 繰り返し読み取り ( `REPEATABLE READ` ) -- シリアル化可能（ `SERIALIZABLE` ）。 +- コミットされていない読み取り ( `READ UNCOMMITTED` ) +- コミットされた読み取り ( `READ COMMITTED` ) +- 繰り返し読み取り ( `REPEATABLE READ` ) +- シリアル化可能（ `SERIALIZABLE` ）。 詳細については、以下の表を参照してください。 @@ -163,6 +163,6 @@ TiDBは、MySQLとの整合性を確保するために、スナップショッ ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-transaction-restraints.md b/develop/dev-guide-transaction-restraints.md index c13503e8baeef..e2d246d11c052 100644 --- a/develop/dev-guide-transaction-restraints.md +++ b/develop/dev-guide-transaction-restraints.md @@ -20,9 +20,9 @@ TiDB の`SI`分離レベルでは**ファントム リード**を回避できま 以下の2つの例は**、ファントムリード**がどのようなものかを示しています。 -- 例 1:**トランザクションA は**、まずクエリに従って`n`行を取得し、次に**トランザクションB は**、これらの`m`行以外の`n`行を変更するか、**トランザクションA**のクエリに一致する`m`行を追加します。**トランザクションA**が再度クエリを実行すると、条件に一致する`n+m`行が存在することがわかります。これはファントムのようなものなので、**ファントム リード**と呼ばれます。 +- 例 1:**トランザクションA は**、まずクエリに従って`n`行を取得し、次に**トランザクションB は**、これらの`m`行以外の`n`行を変更するか、**トランザクションA**のクエリに一致する`m`行を追加します。**トランザクションA**が再度クエリを実行すると、条件に一致する`n+m`行が存在することがわかります。これはファントムのようなものなので、**ファントム リード**と呼ばれます。 -- 例2：**管理者Aが**データベース内のすべての学生の成績を特定の点数からABCDEの成績に変更しますが、このとき**管理者Bが**特定の点数のレコードを挿入します。**管理者Aが**変更を終え、まだ変更されていないレコード（**管理者B**が挿入したレコード）が残っていることに気付いた場合、それは**ファントムリード**です。 +- 例2：**管理者Aが**データベース内のすべての学生の成績を特定の点数からABCDEの成績に変更しますが、このとき**管理者Bが**特定の点数のレコードを挿入します。**管理者Aが**変更を終え、まだ変更されていないレコード（**管理者B**が挿入したレコード）が残っていることに気付いた場合、それは**ファントムリード**です。 ## SIは書き込みスキューを回避できない {#si-cannot-avoid-write-skew} @@ -710,16 +710,16 @@ mysql> SELECT * FROM T2; 基本原則は、トランザクションのサイズを制限することです。KVレベルでは、TiDBは単一トランザクションのサイズに制限を設けています。SQLレベルでは、1行のデータが1つのKVエントリにマッピングされ、インデックスを追加するたびに1つのKVエントリが追加されます。SQLレベルでの制限は以下のとおりです。 -- 1行あたりのレコードの最大サイズは120MiBです。 +- 1行あたりのレコードの最大サイズは120MiBです。 - - TiDB v4.0.10 以降、v4.0.x バージョン、および TiDB v5.0.0 以降のバージョンでは、tidb-server の[`performance.txn-entry-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-entry-size-limit-new-in-v4010-and-v500)設定パラメータを使用して調整できます。v4.0.10 より前のバージョンでは、値は`6 MB`です。 - - バージョン7.6.0以降では、 [`tidb_txn_entry_size_limit`](/system-variables.md#tidb_txn_entry_size_limit-new-in-v760)システム変数を使用して、この設定項目の値を動的に変更できます。 - - TiKV も単一の書き込みリクエストのデータサイズを制限していることに注意してください。単一の書き込みリクエストのデータサイズが [`raftstore.raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)(デフォルトは `8 MiB`)を超えると、TiKV はそのリクエストを拒否します。単一行が大きい場合は、TiDB の `tidb_txn_entry_size_limit` と TiKV の `raftstore.raft-entry-max-size` の両方を調整する必要があります。 + - TiDB v4.0.10 以降、v4.0.x バージョン、および TiDB v5.0.0 以降のバージョンでは、tidb-server の[`performance.txn-entry-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-entry-size-limit-new-in-v4010-and-v500)設定パラメータを使用して調整できます。v4.0.10 より前のバージョンでは、値は`6 MB`です。 + - バージョン7.6.0以降では、 [`tidb_txn_entry_size_limit`](/system-variables.md#tidb_txn_entry_size_limit-new-in-v760)システム変数を使用して、この設定項目の値を動的に変更できます。 + - TiKV も単一の書き込みリクエストのデータサイズを制限していることに注意してください。単一の書き込みリクエストのデータサイズが [`raftstore.raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)(デフォルトは `8 MiB`)を超えると、TiKV はそのリクエストを拒否します。単一行が大きい場合は、TiDB の `tidb_txn_entry_size_limit` と TiKV の `raftstore.raft-entry-max-size` の両方を調整する必要があります。 -- 単一トランザクションでサポートされる最大サイズは1 TiBです。 +- 単一トランザクションでサポートされる最大サイズは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 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)を参照してください。 サイズ制限と行数制限の両方において、トランザクション実行時のエンコード処理とトランザクション用の追加キーのオーバーヘッドも考慮する必要があることに注意してください。最適なパフォーマンスを実現するには、100～500行ごとに1つのトランザクションを書き込むことをお勧めします。 @@ -733,6 +733,6 @@ mysql> SELECT * FROM T2; ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-transaction-troubleshoot.md b/develop/dev-guide-transaction-troubleshoot.md index f1912d05ff1c7..4d3d57f37ce57 100644 --- a/develop/dev-guide-transaction-troubleshoot.md +++ b/develop/dev-guide-transaction-troubleshoot.md @@ -84,13 +84,13 @@ MySQL などの従来のデータベースとは異なり、TiDB では、楽観 再試行ロジックは次のルールに従う必要があります。 -- 失敗した再試行回数が`max_retries`制限に達した場合、エラーをスローします。 -- SQL実行例外をキャッチするには`try ... catch ...`を使用します。以下のエラーが発生した場合は再試行してください。その他のエラーが発生した場合はロールバックしてください。 - - `Error 8002: can not retry select for update statement` : SELECT FOR UPDATE 書き込み競合エラー - - `Error 8022: Error: KV error safe to retry` : トランザクションのコミットに失敗したエラー。 - - `Error 8028: Information schema is changed during the execution of the statement` : DDL 操作によってテーブル スキーマが変更され、トランザクションのコミットでエラーが発生しました。 - - `Error 9007: Write conflict` : 書き込み競合エラー。通常、楽観的トランザクション モードが使用されているときに、複数のトランザクションが同じデータ行を変更することによって発生します。 -- try ブロックの最後にあるトランザクションを`COMMIT` 。 +- 失敗した再試行回数が`max_retries`制限に達した場合、エラーをスローします。 +- SQL実行例外をキャッチするには`try ... catch ...`を使用します。以下のエラーが発生した場合は再試行してください。その他のエラーが発生した場合はロールバックしてください。 + - `Error 8002: can not retry select for update statement` : SELECT FOR UPDATE 書き込み競合エラー + - `Error 8022: Error: KV error safe to retry` : トランザクションのコミットに失敗したエラー。 + - `Error 8028: Information schema is changed during the execution of the statement` : DDL 操作によってテーブル スキーマが変更され、トランザクションのコミットでエラーが発生しました。 + - `Error 9007: Write conflict` : 書き込み競合エラー。通常、楽観的トランザクション モードが使用されているときに、複数のトランザクションが同じデータ行を変更することによって発生します。 +- try ブロックの最後にあるトランザクションを`COMMIT` 。 エラー コードの詳細については、 [エラーコードとトラブルシューティング](/error-codes.md)を参照してください。 @@ -124,10 +124,10 @@ while True: ## 参照 {#see-also} -- [楽観的トランザクションにおける書き込み競合のトラブルシューティング](/troubleshoot-write-conflicts.md) +- [楽観的トランザクションにおける書き込み競合のトラブルシューティング](/troubleshoot-write-conflicts.md) ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-troubleshoot-overview.md b/develop/dev-guide-troubleshoot-overview.md index de7c65588aa53..96c32c1d7d5f4 100644 --- a/develop/dev-guide-troubleshoot-overview.md +++ b/develop/dev-guide-troubleshoot-overview.md @@ -18,16 +18,16 @@ SQL クエリのパフォーマンスを向上させる場合は、 [SQL性能
-- [スロークエリ](/tidb-cloud/tune-performance.md#slow-query) -- [ステートメント分析](/tidb-cloud/tune-performance.md#statement-analysis) -- [Key Visualizer](/tidb-cloud/tune-performance.md#key-visualizer) +- [スロークエリ](/tidb-cloud/tune-performance.md#slow-query) +- [ステートメント分析](/tidb-cloud/tune-performance.md#statement-analysis) +- [Key Visualizer](/tidb-cloud/tune-performance.md#key-visualizer)
-- [スロークエリを分析する](/analyze-slow-queries.md) -- [Top SQLを使用してコストの高いクエリを特定する](/dashboard/top-sql.md) +- [スロークエリを分析する](/analyze-slow-queries.md) +- [Top SQLを使用してコストの高いクエリを特定する](/dashboard/top-sql.md)
@@ -40,12 +40,12 @@ SQL 操作について質問がある場合は、 [SQLに関するよくある ## 参照 {#see-also} -- [サポートされていない機能](/mysql-compatibility.md#unsupported-features) -- [TiDB Cloudに関するよくある質問](/tidb-cloud/tidb-cloud-faq.md) -- [TiDB Self-Managedに関するFAQ](/faq/faq-overview.md) +- [サポートされていない機能](/mysql-compatibility.md#unsupported-features) +- [TiDB Cloudに関するよくある質問](/tidb-cloud/tidb-cloud-faq.md) +- [TiDB Self-Managedに関するFAQ](/faq/faq-overview.md) ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-unique-serial-number-generation.md b/develop/dev-guide-unique-serial-number-generation.md index 3f60353c1e975..593963bc08ae5 100644 --- a/develop/dev-guide-unique-serial-number-generation.md +++ b/develop/dev-guide-unique-serial-number-generation.md @@ -32,10 +32,10 @@ Snowflakeは、Twitterが提案する分散ID生成ソリューションです | 1bit | 28bits | 22bits | 13bits | ``` -- 符号: 1ビットの固定長。生成されるIDが常に正の数であることを示すために`0`に固定されます。 -- デルタ秒: デフォルトは28ビット。現在の時刻を、あらかじめ設定されたタイムベース（デフォルトは`2016-05-20` ）に対する増分値（秒）で表します。28ビットでは最大約8.7年までサポートできます。 -- ワーカーノードID：デフォルトでは22ビット。マシンIDを表します。通常、アプリケーションプロセスの開始時に中央IDジェネレータから取得されます。一般的な中央IDジェネレータには、AUTO_INCREMENT列やZooKeeperなどがあります。デフォルトの割り当てポリシーは「discard-as-you-go（実行時に破棄）」で、プロセスは再起動時に新しいワーカーノードIDを再取得します。22ビットでは最大約420万回の起動をサポートできます。 -- シーケンス: デフォルトでは13ビット。1秒あたりの同時実行シーケンス数。13ビットでは1秒あたり8192の同時実行シーケンスをサポートできます。 +- 符号: 1ビットの固定長。生成されるIDが常に正の数であることを示すために`0`に固定されます。 +- デルタ秒: デフォルトは28ビット。現在の時刻を、あらかじめ設定されたタイムベース（デフォルトは`2016-05-20` ）に対する増分値（秒）で表します。28ビットでは最大約8.7年までサポートできます。 +- ワーカーノードID：デフォルトでは22ビット。マシンIDを表します。通常、アプリケーションプロセスの開始時に中央IDジェネレータから取得されます。一般的な中央IDジェネレータには、AUTO_INCREMENT列やZooKeeperなどがあります。デフォルトの割り当てポリシーは「discard-as-you-go（実行時に破棄）」で、プロセスは再起動時に新しいワーカーノードIDを再取得します。22ビットでは最大約420万回の起動をサポートできます。 +- シーケンス: デフォルトでは13ビット。1秒あたりの同時実行シーケンス数。13ビットでは1秒あたり8192の同時実行シーケンスをサポートできます。 ## 番号割り当てソリューション {#number-allocation-solution} @@ -53,6 +53,6 @@ Snowflakeは、Twitterが提案する分散ID生成ソリューションです ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-unstable-result-set.md b/develop/dev-guide-unstable-result-set.md index 3367433749ea6..5ec4959254a38 100644 --- a/develop/dev-guide-unstable-result-set.md +++ b/develop/dev-guide-unstable-result-set.md @@ -14,8 +14,8 @@ aliases: ['/ja/tidb/stable/dev-guide-unstable-result-set/','/ja/tidbcloud/dev-gu たとえば、次の 2 つのテーブルがあるとします。 -- `stu_info`学生情報を保存します -- `stu_score`生徒のテストのスコアが格納されます。 +- `stu_info`学生情報を保存します +- `stu_score`生徒のテストのスコアが格納されます。 次に、次のような SQL クエリ ステートメントを記述します。 @@ -176,7 +176,7 @@ TiDB はストレージレイヤーからデータを並列に読み取るため `GROUP_CONCAT()`結果セットの出力を順序通りにするには、SQLセマンティクスに準拠した`ORDER BY`句にソートフィールドを追加する必要があります。次の例では、 `ORDER BY`を除いた`customer_id`を連結する`GROUP_CONCAT()`によって、結果セットが不安定になります。 -1. 除外`ORDER BY` +1. 除外`ORDER BY` 最初のクエリ: @@ -200,7 +200,7 @@ TiDB はストレージレイヤーからデータを並列に読み取るため +-------------------------------------------------------------------------+ ``` -2. `ORDER BY`含む +2. `ORDER BY`含む 最初のクエリ: @@ -230,6 +230,6 @@ TiDB はストレージレイヤーからデータを並列に読み取るため ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-update-data.md b/develop/dev-guide-update-data.md index 2bb46029795fd..0b943e64d83e6 100644 --- a/develop/dev-guide-update-data.md +++ b/develop/dev-guide-update-data.md @@ -8,16 +8,16 @@ aliases: ['/ja/tidb/stable/dev-guide-update-data/','/ja/tidb/dev/dev-guide-updat このドキュメントでは、さまざまなプログラミング言語を使用して、以下のSQL文でTiDBのデータを更新する方法について説明します。 -- [UPDATE](/sql-statements/sql-statement-update.md): 指定されたテーブル内のデータを変更するために使用されます。 -- [INSERT ON DUPLICATE KEY UPDATE](/sql-statements/sql-statement-insert.md): データの挿入、および主キーまたは一意キーの競合が発生した場合のデータの更新に使用します。複数の一意キー（主キーを含む）がある場合は、このステートメントの使用は**推奨されません**。これは、このステートメントが一意キー（主キーを含む）の競合を検出するとすぐにデータを更新するためです。複数の行で競合が発生した場合、更新されるのは1行のみです。 +- [UPDATE](/sql-statements/sql-statement-update.md): 指定されたテーブル内のデータを変更するために使用されます。 +- [INSERT ON DUPLICATE KEY UPDATE](/sql-statements/sql-statement-insert.md): データの挿入、および主キーまたは一意キーの競合が発生した場合のデータの更新に使用します。複数の一意キー（主キーを含む）がある場合は、このステートメントの使用は**推奨されません**。これは、このステートメントが一意キー（主キーを含む）の競合を検出するとすぐにデータを更新するためです。複数の行で競合が発生した場合、更新されるのは1行のみです。 ## 始める前に {#before-you-start} この文書を読む前に、以下のものを準備してください。 -- [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md)、データベース[データベースを作成する](/develop/dev-guide-create-database.md)、[テーブルを作成する](/develop/dev-guide-create-table.md)、 [セカンダリインデックスを作成する](/develop/dev-guide-create-secondary-indexes.md)読んでください。 -- `UPDATE`データを取得したい場合は、最初に[データを挿入する](/develop/dev-guide-insert-data.md)必要があります。 +- [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- [スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md)、データベース[データベースを作成する](/develop/dev-guide-create-database.md)、[テーブルを作成する](/develop/dev-guide-create-table.md)、 [セカンダリインデックスを作成する](/develop/dev-guide-create-secondary-indexes.md)読んでください。 +- `UPDATE`データを取得したい場合は、最初に[データを挿入する](/develop/dev-guide-insert-data.md)必要があります。 ## `UPDATE`を使用する {#use-update} @@ -49,8 +49,8 @@ UPDATE {table} SET {update_column} = {update_value} WHERE {filter_column} = {fil データ更新に関するベストプラクティスを以下に示します。 -- `WHERE`ステートメントには、必ず`UPDATE`句を指定してください。 `UPDATE`ステートメントに`WHERE`句がない場合、TiDB はテーブル内の***すべての行***を更新します。 -- 大量の行 (たとえば、1 万行以上) を更新する必要がある場合は[一括更新](#bulk-update)を使用します。 TiDB は 1 つのトランザクションのサイズを制限しているため ( [トランザクションの合計サイズ制限](/tidb-configuration-file.md#txn-total-size-limit)、デフォルトでは 100 MB)、一度にあまりにも多くのデータ更新が行われると、長時間ロックが保持されすぎたり ([悲観的トランザクション](/pessimistic-transaction.md))、競合が発生したり ([楽観的トランザクション](/optimistic-transaction.md)) されます。 +- `WHERE`ステートメントには、必ず`UPDATE`句を指定してください。 `UPDATE`ステートメントに`WHERE`句がない場合、TiDB はテーブル内の***すべての行***を更新します。 +- 大量の行 (たとえば、1 万行以上) を更新する必要がある場合は[一括更新](#bulk-update)を使用します。 TiDB は 1 つのトランザクションのサイズを制限しているため ( [トランザクションの合計サイズ制限](/tidb-configuration-file.md#txn-total-size-limit)、デフォルトでは 100 MB)、一度にあまりにも多くのデータ更新が行われると、長時間ロックが保持されすぎたり ([悲観的トランザクション](/pessimistic-transaction.md))、競合が発生したり ([楽観的トランザクション](/optimistic-transaction.md)) されます。 ### `UPDATE`例 {#update-example} @@ -105,8 +105,8 @@ INSERT INTO {table} ({columns}) VALUES ({values}) ### `INSERT ON DUPLICATE KEY UPDATE`のベストプラクティス {#insert-on-duplicate-key-update-best-practices} -- `INSERT ON DUPLICATE KEY UPDATE`は、一意キーが 1 つだけのテーブルでのみ使用してください。このステートメントは***、一意キー***(主キーを含む) の競合が検出された場合、データを更新します。競合する行が複数ある場合、更新されるのは 1 行のみです。したがって、競合する行が 1 つだけであることを保証できない限り、一意キーが複数あるテーブルで`INSERT ON DUPLICATE KEY UPDATE`ステートメントを使用することはお勧めしません。 -- データを作成または更新する際に、このステートメントを使用してください。 +- `INSERT ON DUPLICATE KEY UPDATE`は、一意キーが 1 つだけのテーブルでのみ使用してください。このステートメントは***、一意キー***(主キーを含む) の競合が検出された場合、データを更新します。競合する行が複数ある場合、更新されるのは 1 行のみです。したがって、競合する行が 1 つだけであることを保証できない限り、一意キーが複数あるテーブルで`INSERT ON DUPLICATE KEY UPDATE`ステートメントを使用することはお勧めしません。 +- データを作成または更新する際に、このステートメントを使用してください。 ### `INSERT ON DUPLICATE KEY UPDATE`例 {#insert-on-duplicate-key-update-example} @@ -395,7 +395,7 @@ public class BatchUpdateExample { } ``` -- `hibernate.cfg.xml`設定: +- `hibernate.cfg.xml`設定: ```xml @@ -429,6 +429,6 @@ public class BatchUpdateExample { ## お困りですか？ {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 -- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)or [Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに質問してください。 +- [TiDB Cloudのサポートチケットを送信してください](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信してください](/support.md) diff --git a/develop/dev-guide-use-common-table-expression.md b/develop/dev-guide-use-common-table-expression.md index c695df2cd190e..6bd277c6b5025 100644 --- a/develop/dev-guide-use-common-table-expression.md +++ b/develop/dev-guide-use-common-table-expression.md @@ -214,10 +214,10 @@ SELECT * FROM fibonacci; ## 続きを読む {#read-more} -- [と](/sql-statements/sql-statement-with.md) +- [と](/sql-statements/sql-statement-with.md) ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-use-follower-read.md b/develop/dev-guide-use-follower-read.md index 16fe3cf8a5544..2cdb64ece214b 100644 --- a/develop/dev-guide-use-follower-read.md +++ b/develop/dev-guide-use-follower-read.md @@ -20,8 +20,8 @@ TiDBは、 [リージョン](/tidb-storage.md#region)基本単位として、ク 次のいずれかを実行すると、アプリケーションにホットスポットリージョンがあるかどうかを視覚的に分析できます。 -- TiDB Cloud: [TiDB Cloudコンソールのキー ビジュアライザー](/tidb-cloud/tune-performance.md#key-visualizer)に移動し、「メトリック選択ボックス」を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 -- TiDB Self-Managed: [TiDB DashboardのKey Visualizer](/dashboard/dashboard-key-visualizer.md)に移動し、「メトリック選択ボックス」を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 +- TiDB Cloud: [TiDB Cloudコンソールのキー ビジュアライザー](/tidb-cloud/tune-performance.md#key-visualizer)に移動し、「メトリック選択ボックス」を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 +- TiDB Self-Managed: [TiDB DashboardのKey Visualizer](/dashboard/dashboard-key-visualizer.md)に移動し、「メトリック選択ボックス」を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 ホットスポットの問題が存在する場合は、 [TiDBホットスポットの問題の処理](/troubleshoot-hot-spot-issues.md)を参照してトラブルシューティングを行うことができます。これにより、アプリケーション レベルでのホットスポットの生成を回避することができます。 @@ -137,13 +137,13 @@ public static class AuthorDAO { ## 続きを読む {#read-more} -- [Follower Read](/follower-read.md) -- [ホットスポットの問題のトラブルシューティング](/troubleshoot-hot-spot-issues.md) -- [TiDB Cloudコンソールのキー ビジュアライザー](/tidb-cloud/tune-performance.md#key-visualizer) -- [TiDB Self-Managed向けTiDB DashboardのKey Visualizer](/dashboard/dashboard-key-visualizer.md) +- [Follower Read](/follower-read.md) +- [ホットスポットの問題のトラブルシューティング](/troubleshoot-hot-spot-issues.md) +- [TiDB Cloudコンソールのキー ビジュアライザー](/tidb-cloud/tune-performance.md#key-visualizer) +- [TiDB Self-Managed向けTiDB DashboardのKey Visualizer](/dashboard/dashboard-key-visualizer.md) ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-use-stale-read.md b/develop/dev-guide-use-stale-read.md index ae23e3121ec4d..efa45e9a60f53 100644 --- a/develop/dev-guide-use-stale-read.md +++ b/develop/dev-guide-use-stale-read.md @@ -97,9 +97,9 @@ SELECT id, title, type, price FROM books AS OF TIMESTAMP '2022-04-20 15:20:00' O 正確な時間を指定することに加えて、次のことも指定できます。 -- `AS OF TIMESTAMP NOW() - INTERVAL 10 SECOND` 10 秒前の最新データを照会します。 -- `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS('2016-10-08 16:45:26', '2016-10-08 16:45:29')` `2016-10-08 16:45:26`から`2016-10-08 16:45:29`の間の最新データを照会します。 -- `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS(NOW() -INTERVAL 20 SECOND, NOW())` 20 秒以内に最新のデータを照会します。 +- `AS OF TIMESTAMP NOW() - INTERVAL 10 SECOND` 10 秒前の最新データを照会します。 +- `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS('2016-10-08 16:45:26', '2016-10-08 16:45:29')` `2016-10-08 16:45:26`から`2016-10-08 16:45:29`の間の最新データを照会します。 +- `AS OF TIMESTAMP TIDB_BOUNDED_STALENESS(NOW() -INTERVAL 20 SECOND, NOW())` 20 秒以内に最新のデータを照会します。 指定するタイムスタンプまたは間隔は、現在の時刻より早すぎたり遅すぎたりしないようにしてください。また、 `NOW()`はデフォルトで秒精度となります。より高い精度を実現するには、パラメータを追加することができます。例えば、 `NOW(3)`ではミリ秒精度となります。詳細については、 [MySQLドキュメント](https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_now)を参照してください。 @@ -495,12 +495,12 @@ public static class StaleReadHelper{ ## 続きを読む {#read-more} -- [ステイル読み取りの使用シナリオ](/stale-read.md) -- [`AS OF TIMESTAMP`句を使用して履歴データを読み取る](/as-of-timestamp.md) -- [`tidb_read_staleness`システム変数を使用して履歴データを読み取る](/tidb-read-staleness.md) +- [ステイル読み取りの使用シナリオ](/stale-read.md) +- [`AS OF TIMESTAMP`句を使用して履歴データを読み取る](/as-of-timestamp.md) +- [`tidb_read_staleness`システム変数を使用して履歴データを読み取る](/tidb-read-staleness.md) ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-use-subqueries.md b/develop/dev-guide-use-subqueries.md index 1c58e799d8b90..94ec1ef9bcb56 100644 --- a/develop/dev-guide-use-subqueries.md +++ b/develop/dev-guide-use-subqueries.md @@ -18,11 +18,11 @@ aliases: ['/ja/tidb/stable/dev-guide-use-subqueries/','/ja/tidbcloud/dev-guide-u ほとんどの場合、サブクエリには次の 5 つの種類があります。 -- スカラーサブクエリ (例: `SELECT (SELECT s1 FROM t2) FROM t1` )。 -- 派生テーブル (例: `SELECT t1.s1 FROM (SELECT s1 FROM t2) t1` )。 -- 存在判定、例: `WHERE NOT EXISTS(SELECT ... FROM t2)` 、 `WHERE t1.a IN (SELECT ... FROM t2)` 。 -- 量化比較、例: `WHERE t1.a = ANY(SELECT ... FROM t2)` 、 `WHERE t1.a = ANY(SELECT ... FROM t2)` 。 -- 比較演算子のオペランドとしてのサブクエリ (例: `WHERE t1.a > (SELECT ... FROM t2)` 。 +- スカラーサブクエリ (例: `SELECT (SELECT s1 FROM t2) FROM t1` )。 +- 派生テーブル (例: `SELECT t1.s1 FROM (SELECT s1 FROM t2) t1` )。 +- 存在判定、例: `WHERE NOT EXISTS(SELECT ... FROM t2)` 、 `WHERE t1.a IN (SELECT ... FROM t2)` 。 +- 量化比較、例: `WHERE t1.a = ANY(SELECT ... FROM t2)` 、 `WHERE t1.a = ANY(SELECT ... FROM t2)` 。 +- 比較演算子のオペランドとしてのサブクエリ (例: `WHERE t1.a > (SELECT ... FROM t2)` 。 ## サブクエリのカテゴリ {#category-of-subquery} @@ -126,12 +126,12 @@ WHERE ## 続きを読む {#read-more} -- [サブクエリ関連の最適化](/subquery-optimization.md) -- [相関サブクエリの非相関](/correlated-subquery-optimization.md) -- [TiDBにおけるサブクエリの最適化](https://www.pingcap.com/blog/subquery-optimization-in-tidb/) +- [サブクエリ関連の最適化](/subquery-optimization.md) +- [相関サブクエリの非相関](/correlated-subquery-optimization.md) +- [TiDBにおけるサブクエリの最適化](https://www.pingcap.com/blog/subquery-optimization-in-tidb/) ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-use-temporary-tables.md b/develop/dev-guide-use-temporary-tables.md index 916394a56c62b..d1712e86e8bf5 100644 --- a/develop/dev-guide-use-temporary-tables.md +++ b/develop/dev-guide-use-temporary-tables.md @@ -48,8 +48,8 @@ LIMIT 50; TiDB の一時テーブルは、ローカル一時テーブルとグローバル一時テーブルの 2 種類に分かれています。 -- ローカル一時テーブルの場合、テーブル定義とテーブル内のデータは現在のセッションでのみ参照可能です。このタイプは、セッション中の中間データを一時的に保存するのに適しています。 -- グローバル一時テーブルの場合、テーブル定義はTiDBクラスタ全体から参照可能で、テーブル内のデータは現在のトランザクションからのみ参照可能です。このタイプは、トランザクション中の中間データを一時的に保存するのに適しています。 +- ローカル一時テーブルの場合、テーブル定義とテーブル内のデータは現在のセッションでのみ参照可能です。このタイプは、セッション中の中間データを一時的に保存するのに適しています。 +- グローバル一時テーブルの場合、テーブル定義はTiDBクラスタ全体から参照可能で、テーブル内のデータは現在のトランザクションからのみ参照可能です。このタイプは、トランザクション中の中間データを一時的に保存するのに適しています。 ### ローカル一時テーブルを作成する {#create-a-local-temporary-table} @@ -257,10 +257,10 @@ TiDB の一時テーブルの制限については、 [他の TiDB 機能との ## 続きを読む {#read-more} -- [一時テーブル](/temporary-tables.md) +- [一時テーブル](/temporary-tables.md) ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-use-views.md b/develop/dev-guide-use-views.md index b93b015c346ed..89b322c80a552 100644 --- a/develop/dev-guide-use-views.md +++ b/develop/dev-guide-use-views.md @@ -12,8 +12,8 @@ aliases: ['/ja/tidb/stable/dev-guide-use-views/','/ja/tidbcloud/dev-guide-use-vi TiDBはビューをサポートしています。ビューは仮想テーブルとして機能し、そのスキーマはビューを作成する`SELECT`ステートメントによって定義されます。 -- 安全なフィールドとデータのみをユーザーに公開するビューを作成することで、基になるテーブル内の機密フィールドとデータのセキュリティを確保できます。 -- 頻繁に使用される複雑なクエリのビューを作成して、複雑なクエリをより簡単に、より便利に実行できます。 +- 安全なフィールドとデータのみをユーザーに公開するビューを作成することで、基になるテーブル内の機密フィールドとデータのセキュリティを確保できます。 +- 頻繁に使用される複雑なクエリのビューを作成して、複雑なクエリをより簡単に、より便利に実行できます。 ## ビューを作成する {#create-a-view} @@ -51,8 +51,8 @@ TiDB がビューをクエリする場合、ビューに関連付けられた`SE 現在、TiDB のビューは`ALTER VIEW view_name AS query;`をサポートしていませんが、次の 2 つの方法でビューを「更新」できます。 -- `DROP VIEW view_name;`ステートメントで古いビューを削除し、 `CREATE VIEW view_name AS query;`ステートメントで新しいビューを作成してビューを更新します。 -- 同じ名前の既存のビューを上書きするには、 `CREATE OR REPLACE VIEW view_name AS query;`ステートメントを使用します。 +- `DROP VIEW view_name;`ステートメントで古いビューを削除し、 `CREATE VIEW view_name AS query;`ステートメントで新しいビューを作成してビューを更新します。 +- 同じ名前の既存のビューを上書きするには、 `CREATE OR REPLACE VIEW view_name AS query;`ステートメントを使用します。 ```sql CREATE OR REPLACE VIEW book_with_ratings AS @@ -118,14 +118,14 @@ TiDB のビューの制限については、 [ビューの制限](/views.md#limi ## 続きを読む {#read-more} -- [ビュー](/views.md) -- [CREATE VIEW](/sql-statements/sql-statement-create-view.md) -- [DROP VIEW](/sql-statements/sql-statement-drop-view.md) -- [ビューを使用したEXPLAINステートメント](/explain-views.md) -- [TiFlink: TiKV と Flink を使用した強整合性マテリアライズド ビュー](https://github.com/tiflink/tiflink) +- [ビュー](/views.md) +- [CREATE VIEW](/sql-statements/sql-statement-create-view.md) +- [DROP VIEW](/sql-statements/sql-statement-drop-view.md) +- [ビューを使用したEXPLAINステートメント](/explain-views.md) +- [TiFlink: TiKV と Flink を使用した強整合性マテリアライズド ビュー](https://github.com/tiflink/tiflink) ## ヘルプが必要ですか? {#need-help} -- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 -- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDB Self-Managedのサポートチケットを送信する](/support.md) +- [Discord](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[Slack](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 +- [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-vector-search.md b/develop/dev-guide-vector-search.md index 2953bc4b09e33..5d14ccc717e0c 100644 --- a/develop/dev-guide-vector-search.md +++ b/develop/dev-guide-vector-search.md @@ -11,8 +11,8 @@ summary: 概念、チュートリアル、統合、リファレンス ドキュ TiDB ベクトル検索を開始するには、次のチュートリアルを参照してください。 -- [Pythonで始める](/ai/quickstart-via-python.md) -- [SQL経由で開始する](/ai/quickstart-via-sql.md) +- [Pythonで始める](/ai/quickstart-via-python.md) +- [SQL経由で開始する](/ai/quickstart-via-sql.md) ## 自動埋め込み {#auto-embedding} @@ -48,14 +48,14 @@ RAG シナリオでの検索品質を向上させるには、ベクトル検索 ベクトル検索を実装する前に、次の制限事項に注意してください。 -- ベクトルあたり最大16383次元 -- ベクトル列は主キー、一意インデックス、パーティション キーとして使用することはできません。 -- ベクトルと他のデータ型間の直接キャストは行いません（文字列を中間として使用します） +- ベクトルあたり最大16383次元 +- ベクトル列は主キー、一意インデックス、パーティション キーとして使用することはできません。 +- ベクトルと他のデータ型間の直接キャストは行いません（文字列を中間として使用します） 完全なリストについては、 [ベクトル検索の制限](/ai/reference/vector-search-limitations.md)を参照してください。 ## 参照 {#reference} -- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) -- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) -- [ベクトルインデックス](/ai/reference/vector-search-index.md) +- [ベクトルデータ型](/ai/reference/vector-search-data-types.md) +- [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) +- [ベクトルインデックス](/ai/reference/vector-search-index.md) diff --git a/develop/dev-guide-wordpress.md b/develop/dev-guide-wordpress.md index b7b7497470cde..bbb529d0f8609 100644 --- a/develop/dev-guide-wordpress.md +++ b/develop/dev-guide-wordpress.md @@ -18,7 +18,7 @@ TiDBはMySQL互換データベースであり、 TiDB Cloud Starterはフルマ このチュートリアルを完了するには、以下が必要です。 -- お持ちでない場合は、 [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 +- お持ちでない場合は、 [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 ## TiDB Cloud StarterでWordPressを実行する {#run-wordpress-with-tidb-cloud-starter} @@ -35,13 +35,13 @@ cd wordpress-tidb-docker ### ステップ2：依存関係をインストールする {#step-2-install-dependencies} -1. サンプルリポジトリでは、WordPressを起動するために[Docker](https://www.docker.com/)と[Docker Compose](https://docs.docker.com/compose/)が必要です。既にインストール済みであれば、この手順はスキップできます。WordPressはLinux環境（Ubuntuなど）で実行することを強くお勧めします。DockerとDocker Composeをインストールするには、次のコマンドを実行してください。 +1. サンプルリポジトリでは、WordPressを起動するために[Docker](https://www.docker.com/)と[Docker Compose](https://docs.docker.com/compose/)が必要です。既にインストール済みであれば、この手順はスキップできます。WordPressはLinux環境（Ubuntuなど）で実行することを強くお勧めします。DockerとDocker Composeをインストールするには、次のコマンドを実行してください。 ```shell sudo sh install.sh ``` -2. サンプル リポジトリには、サブモジュールとして[TiDB互換性プラグイン](https://github.com/pingcap/wordpress-tidb-plugin)が含まれています。次のコマンドを実行してサブモジュールを更新します。 +2. サンプル リポジトリには、サブモジュールとして[TiDB互換性プラグイン](https://github.com/pingcap/wordpress-tidb-plugin)が含まれています。次のコマンドを実行してサブモジュールを更新します。 ```shell git submodule update --init --recursive @@ -51,30 +51,30 @@ cd wordpress-tidb-docker TiDB Cloud StarterへのWordPressデータベース接続を設定します。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、次に、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、次に、対象のTiDB Cloud Starterインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 - - **Connect With**は`WordPress`に設定されています。 - - **Operating System**は`Debian/Ubuntu/Arch`に設定されています。 - - **Database**は、使用したいデータベースに設定されます。たとえば、 `test` 。 + - **Connection Type**は`Public`に設定されています。 + - **Connect With**は`WordPress`に設定されています。 + - **Operating System**は`Debian/Ubuntu/Arch`に設定されています。 + - **Database**は、使用したいデータベースに設定されます。たとえば、 `test` 。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > > 以前にパスワードを作成したことがある場合は、元のパスワードを使用するか、 **Reset Password**をクリックして新しいパスワードを生成できます。 -5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 +5. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 ```shell cp .env.example .env ``` -6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 +6. 対応する接続​​文字列`.env`ファイルにコピー＆ペーストしてください。例は以下のとおりです。 ```dotenv TIDB_HOST='{HOST}' # e.g. gateway01.ap-northeast-1.prod.aws.tidbcloud.com @@ -86,23 +86,23 @@ TiDB Cloud StarterへのWordPressデータベース接続を設定します。 プレースホルダー`{}`を、接続ダイアログから取得した接続パラメータに置き換えてください。デフォルトでは、 TiDB Cloud Starterには`test`データベースが付属しています。TiDB Cloud Starterインスタンスで既に別のデータベースを作成している場合は、 `test`データベース名に置き換えてください。 -7. `.env`ファイルを保存します。 +7. `.env`ファイルを保存します。 ### ステップ4： TiDB Cloud StarterでWordPressを起動する {#step-4-start-wordpress-with-tidb-cloud-starter} -1. WordPressをDockerコンテナとして実行するには、以下のコマンドを実行してください。 +1. WordPressをDockerコンテナとして実行するには、以下のコマンドを実行してください。 ```shell docker compose up -d ``` -2. ローカルマシンでコンテナを起動した場合は[localhost](http://localhost/)にアクセスしてWordPressサイトをセットアップし、リモートマシンでWordPressが実行されている場合は`http://`にアクセスしてください。 +2. ローカルマシンでコンテナを起動した場合は[localhost](http://localhost/)にアクセスしてWordPressサイトをセットアップし、リモートマシンでWordPressが実行されている場合は`http://`にアクセスしてください。 ### ステップ5：データベース接続を確認する {#step-5-confirm-the-database-connection} -1. TiDB CloudコンソールでTiDB Cloud Starterインスタンスの接続ダイアログを閉じ、 **SQLエディタ**ページを開きます。 -2. 左側の**Schemas**タブで、WordPressに接続したデータベースをクリックします。 -3. そのデータベースのテーブル一覧に、WordPressのテーブル（ `wp_posts`や`wp_comments`など）が表示されていることを確認してください。 +1. TiDB CloudコンソールでTiDB Cloud Starterインスタンスの接続ダイアログを閉じ、 **SQLエディタ**ページを開きます。 +2. 左側の**Schemas**タブで、WordPressに接続したデータベースをクリックします。 +3. そのデータベースのテーブル一覧に、WordPressのテーブル（ `wp_posts`や`wp_comments`など）が表示されていることを確認してください。 ## お困りですか？ {#need-help} diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index bba397e973335..9a78827499271 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -12,20 +12,20 @@ aliases: ['/ja/docs/dev/best-practices/java-app-best-practices/','/ja/docs/dev/r JavaアプリケーションでTiDBデータベースと連携する一般的なコンポーネントには、以下のようなものがあります。 -- ネットワーク プロトコル: クライアントは、標準の[MySQLプロトコル](https://dev.mysql.com/doc/dev/mysql-server/latest/PAGE_PROTOCOL.html)を介して TiDBサーバーと対話します。 -- JDBC APIとJDBCドライバ： Javaアプリケーションは通常、標準の[JDBC（Javaデータベース接続）](https://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/) APIを使用してデータベースにアクセスします。TiDBに接続するには、JDBC APIを介してMySQLプロトコルを実装するJDBCドライバを使用できます。MySQL用の一般的なJDBCドライバには[MySQL Connector/J](https://github.com/mysql/mysql-connector-j)や[MariaDB Connector/J](https://mariadb.com/docs/connectors/mariadb-connector-j/about-mariadb-connector-j#about-mariadb-connectorj)などがあります。 -- データベース接続プール：アプリケーションは通常、接続要求のたびに接続を作成するオーバーヘッドを削減するために、接続プールを使用して接続をキャッシュし、再利用します。JDBCData [データソース](https://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html)接続プールAPIを定義しています。必要に応じて、さまざまなオープンソースの接続プール実装から選択できます。 -- データアクセスフレームワーク: アプリケーションは通常、 [MyBatis](https://mybatis.org/mybatis-3/index.html)や[Hibernate](https://hibernate.org/)などのデータアクセスフレームワークを使用して、データベースアクセス操作をさらに簡素化および管理します。 -- アプリケーションの実装: アプリケーション ロジックは、いつどのコマンドをデータベースに送信するかを制御します。一部のアプリケーションは[春のトランザクション](https://docs.spring.io/spring/docs/4.2.x/spring-framework-reference/html/transaction.html)アスペクトを使用して、トランザクションの開始およびコミットのロジックを管理します。 +- ネットワーク プロトコル: クライアントは、標準の[MySQLプロトコル](https://dev.mysql.com/doc/dev/mysql-server/latest/PAGE_PROTOCOL.html)を介して TiDBサーバーと対話します。 +- JDBC APIとJDBCドライバ： Javaアプリケーションは通常、標準の[JDBC（Javaデータベース接続）](https://docs.oracle.com/javase/8/docs/technotes/guides/jdbc/) APIを使用してデータベースにアクセスします。TiDBに接続するには、JDBC APIを介してMySQLプロトコルを実装するJDBCドライバを使用できます。MySQL用の一般的なJDBCドライバには[MySQL Connector/J](https://github.com/mysql/mysql-connector-j)や[MariaDB Connector/J](https://mariadb.com/docs/connectors/mariadb-connector-j/about-mariadb-connector-j#about-mariadb-connectorj)などがあります。 +- データベース接続プール：アプリケーションは通常、接続要求のたびに接続を作成するオーバーヘッドを削減するために、接続プールを使用して接続をキャッシュし、再利用します。JDBCData [データソース](https://docs.oracle.com/javase/8/docs/api/javax/sql/DataSource.html)接続プールAPIを定義しています。必要に応じて、さまざまなオープンソースの接続プール実装から選択できます。 +- データアクセスフレームワーク: アプリケーションは通常、 [MyBatis](https://mybatis.org/mybatis-3/index.html)や[Hibernate](https://hibernate.org/)などのデータアクセスフレームワークを使用して、データベースアクセス操作をさらに簡素化および管理します。 +- アプリケーションの実装: アプリケーション ロジックは、いつどのコマンドをデータベースに送信するかを制御します。一部のアプリケーションは[春のトランザクション](https://docs.spring.io/spring/docs/4.2.x/spring-framework-reference/html/transaction.html)アスペクトを使用して、トランザクションの開始およびコミットのロジックを管理します。 ![Java application components](/media/best-practices/java-practice-1.png) 上記の図から、 Javaアプリケーションは次のようなことを行う可能性があることがわかります。 -- JDBC APIを介してMySQLプロトコルを実装し、TiDBと連携させる。 -- 接続プールから永続的な接続を取得します。 -- SQL文を生成および実行するには、MyBatisなどのデータアクセスフレームワークを使用します。 -- Spring トランザクションを使用すると、トランザクションを自動的に開始または停止できます。 +- JDBC APIを介してMySQLプロトコルを実装し、TiDBと連携させる。 +- 接続プールから永続的な接続を取得します。 +- SQL文を生成および実行するには、MyBatisなどのデータアクセスフレームワークを使用します。 +- Spring トランザクションを使用すると、トランザクションを自動的に開始または停止できます。 この文書の残りの部分では、上記のコンポーネントを使用してJavaアプリケーションを開発する際に発生する問題とその解決策について説明します。 @@ -33,8 +33,8 @@ JavaアプリケーションでTiDBデータベースと連携する一般的な Javaアプリケーションは、さまざまなフレームワークでカプセル化されたできます。ほとんどのフレームワークでは、データベースサーバーとのやり取りを行うために、最下層でJDBC APIが呼び出されます。JDBCに関しては、以下の点に重点を置くことをお勧めします。 -- JDBC APIの使用方法の選択 -- API実装者のパラメータ設定 +- JDBC APIの使用方法の選択 +- API実装者のパラメータ設定 ### JDBC API {#jdbc-api} @@ -64,13 +64,13 @@ OLTP (オンライン トランザクション処理) シナリオの場合、 JDBCでは通常、以下の2つの処理方法が使用されます。 -- 最初のメソッド: [`FetchSize` `Integer.MIN_VALUE`に設定します](https://dev.mysql.com/doc/connector-j/en/connector-j-reference-implementation-notes.html#ResultSet)クライアントがキャッシュしないようにします。クライアントは`StreamingResult`を介してネットワーク接続から実行結果を読み取ります。 +- 最初のメソッド: [`FetchSize` `Integer.MIN_VALUE`に設定します](https://dev.mysql.com/doc/connector-j/en/connector-j-reference-implementation-notes.html#ResultSet)クライアントがキャッシュしないようにします。クライアントは`StreamingResult`を介してネットワーク接続から実行結果を読み取ります。 クライアントがストリーミング読み取り方式を使用する場合、クエリを実行するためにステートメントの使用を続行する前に、読み取りを完了するか`resultset`を閉じる必要があります。そうしないと、エラー`No statements may be issued when any streaming result sets are open and in use on a given connection. Ensure that you have called .close() on any active streaming result sets before attempting more queries.`が返されます。 クライアントが`resultset`読み取りを完了または閉じる前にクエリでこのようなエラーが発生するのを回避するには、URL に`clobberStreamingResults=true`パラメータを追加します。そうすると、 `resultset`は自動的に閉じられますが、前のストリーミング クエリで読み取られる結果セットは失われます。 -- 2番目の方法：まず[`FetchSize`設定](http://makejavafaster.blogspot.com/2015/06/jdbc-fetch-size-performance.html)、次にJDBC URLで`useCursorFetch = true`を設定することで、カーソルフェッチを使用します。 +- 2番目の方法：まず[`FetchSize`設定](http://makejavafaster.blogspot.com/2015/06/jdbc-fetch-size-performance.html)、次にJDBC URLで`useCursorFetch = true`を設定することで、カーソルフェッチを使用します。 TiDBは両方の方法をサポートしていますが、実装がよりシンプルで実行効率も優れているため、 `FetchSize`を`Integer.MIN_VALUE`に設定する最初の方法を使用することをお勧めします。 @@ -92,8 +92,8 @@ JDBC は通常、実装関連の設定を JDBC URL パラメーターの形式 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 -- TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 -- リクエスト内で`COM_QUERY`が`COM_STMT_EXECUTE`または`COM_STMT_PREPARE`に置き換えられた場合、この設定は既に有効になっていることを意味します。 +- TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 +- リクエスト内で`COM_QUERY`が`COM_STMT_EXECUTE`または`COM_STMT_PREPARE`に置き換えられた場合、この設定は既に有効になっていることを意味します。 ##### `cachePrepStmts` {#cacheprepstmts} @@ -101,8 +101,8 @@ JDBC は通常、実装関連の設定を JDBC URL パラメーターの形式 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 -- TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 -- リクエスト内の`COM_STMT_EXECUTE`の数が`COM_STMT_PREPARE`の数よりはるかに多い場合、この設定は既に有効になっていることを意味します。 +- TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 +- リクエスト内の`COM_STMT_EXECUTE`の数が`COM_STMT_PREPARE`の数よりはるかに多い場合、この設定は既に有効になっていることを意味します。 さらに、 `useConfigs=maxPerformance`を設定すると、 `cachePrepStmts=true`を含む複数のパラメーターが同時に設定されます。 @@ -114,8 +114,8 @@ JDBC は通常、実装関連の設定を JDBC URL パラメーターの形式 次のような場合は、この設定が小さすぎるかどうかを確認する必要があります。 -- TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 -- そして、 `cachePrepStmts=true`が設定されているが、 `COM_STMT_PREPARE`は依然として`COM_STMT_EXECUTE`とほぼ等しく、 `COM_STMT_CLOSE`が存在することがわかった。 +- TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 +- そして、 `cachePrepStmts=true`が設定されているが、 `COM_STMT_PREPARE`は依然として`COM_STMT_EXECUTE`とほぼ等しく、 `COM_STMT_CLOSE`が存在することがわかった。 ##### `prepStmtCacheSize` {#prepstmtcachesize} @@ -123,8 +123,8 @@ JDBC は通常、実装関連の設定を JDBC URL パラメーターの形式 この設定が既に有効になっていることを確認するには、次の操作を実行してください。 -- TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 -- リクエスト内の`COM_STMT_EXECUTE`の数が`COM_STMT_PREPARE`の数よりはるかに多い場合、この設定は既に有効になっていることを意味します。 +- TiDB モニタリング ダッシュボードに移動し、 **[クエリ概要]** > **[インスタンス別 CPS]**からリクエスト コマンド タイプを確認します。 +- リクエスト内の`COM_STMT_EXECUTE`の数が`COM_STMT_PREPARE`の数よりはるかに多い場合、この設定は既に有効になっていることを意味します。 #### `readOnlyPropagatesToServer` {#readonlypropagatestoserver} @@ -204,9 +204,9 @@ update t set a = 10 where id = 1; update t set a = 11 where id = 2; update t set TiDBは、以下のMySQL互換のタイムアウト制御パラメータを提供します。 -- `wait_timeout` : Javaアプリケーションへの接続における非対話型アイドルタイムアウトを制御します。TiDB v5.4 以降では、 `wait_timeout`のデフォルト値は`28800`秒、つまり 8 時間です。TiDB バージョンが v5.4 より前の場合、デフォルト値は`0`で、タイムアウトは無制限です。 -- `interactive_timeout` : Javaアプリケーションへの接続における対話型アイドルタイムアウトを制御します。デフォルト値は8時間です。 -- `max_execution_time` : 接続における SQL 実行のタイムアウトを制御します。これは`SELECT`ステートメント ( `SELECT ... FOR UPDATE`を含む) にのみ有効です。デフォルト値は`0`で、接続が無限にビジー状態になることを許可します。つまり、SQL ステートメントが無限に長い時間実行されます。 +- `wait_timeout` : Javaアプリケーションへの接続における非対話型アイドルタイムアウトを制御します。TiDB v5.4 以降では、 `wait_timeout`のデフォルト値は`28800`秒、つまり 8 時間です。TiDB バージョンが v5.4 より前の場合、デフォルト値は`0`で、タイムアウトは無制限です。 +- `interactive_timeout` : Javaアプリケーションへの接続における対話型アイドルタイムアウトを制御します。デフォルト値は8時間です。 +- `max_execution_time` : 接続における SQL 実行のタイムアウトを制御します。これは`SELECT`ステートメント ( `SELECT ... FOR UPDATE`を含む) にのみ有効です。デフォルト値は`0`で、接続が無限にビジー状態になることを許可します。つまり、SQL ステートメントが無限に長い時間実行されます。 しかし、実際の本番環境では、アイドル状態の接続や実行時間が長すぎる SQL ステートメントは、データベースやアプリケーションに悪影響を及ぼします。アイドル状態の接続や実行時間が長すぎる SQL ステートメントを回避するには、アプリケーションの接続文字列で次の 2 つのパラメータを設定できます。たとえば、 `sessionVariables=wait_timeout=3600` (1 時間) と`sessionVariables=max_execution_time=300000` (5 分) を設定します。 @@ -228,11 +228,11 @@ TiDB（MySQL）接続の構築は、（少なくともOLTPシナリオにおい TiDBは以下のJava接続プールをサポートしています。 -- [HikariCP](https://github.com/brettwooldridge/HikariCP) -- [トムキャットJDBC](https://tomcat.apache.org/tomcat-10.1-doc/jdbc-pool) -- [druid](https://github.com/alibaba/druid) -- [c3p0](https://www.mchange.com/projects/c3p0/) -- [dbcp](https://commons.apache.org/proper/commons-dbcp/) +- [HikariCP](https://github.com/brettwooldridge/HikariCP) +- [トムキャットJDBC](https://tomcat.apache.org/tomcat-10.1-doc/jdbc-pool) +- [druid](https://github.com/alibaba/druid) +- [c3p0](https://www.mchange.com/projects/c3p0/) +- [dbcp](https://commons.apache.org/proper/commons-dbcp/) 実際には、一部の接続プールは特定のセッションを継続的に使用する場合があります。TiDB の計算ノード全体で接続の総数は均等に分散されているように見えますが、アクティブな接続の分散が不均一な場合、実際の負荷の不均衡が生じる可能性があります。分散環境では、接続ライフサイクルを効果的に管理し、アクティブな接続が特定のノードに固定されるのを防ぎ、負荷分散のバランスを保つHikariCPの使用をお勧めします。 @@ -251,18 +251,18 @@ hikari: パラメータの説明は以下の通りです。詳細については、 [HikariCPの公式ドキュメント](https://github.com/brettwooldridge/HikariCP/blob/dev/README.md)を参照してください。 -- `maximumPoolSize` : プール内の最大接続数。デフォルト値は`10`です。コンテナ化された環境では、 Javaアプリケーションで使用可能な CPU コア数の 4～10 倍に設定することをお勧めします。この値を高く設定しすぎるとリソースの無駄遣いにつながり、低く設定しすぎると接続の取得が遅くなる可能性があります。 詳細については、[プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)を参照してください。 -- `minimumIdle` : HikariCPでは、このパラメータを設定しないことを推奨します。デフォルト値は`maximumPoolSize`の値と同じで、接続プールのスケーリングを無効にします。これにより、トラフィックの急増時にも接続がすぐに利用可能になり、接続作成による遅延を回避できます。 -- `connectionTimeout` : アプリケーションが接続プールから接続を取得するために待機する最大時間 (ミリ秒)。デフォルト値は`30000`ミリ秒 (30 秒) です。この時間内に利用可能な接続が得られない場合、 `SQLException`例外が発生します。 -- `maxLifetime` : プール内の接続の最大有効期間 (ミリ秒)。デフォルト値は`1800000`ミリ秒 (30 分) です。使用中の接続には影響しません。接続が閉じられた後、この設定に従って削除されます。この値を低く設定しすぎると、再接続が頻繁に発生する可能性があります。[`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)を使用している場合は、この値が待機時間よりも小さいことを確認してください。 -- `keepaliveTime` : プール内の接続に対するキープアライブ操作の間隔 (ミリ秒)。この設定は、データベースまたはネットワークのアイドルタイムアウトによって発生する切断を防ぐのに役立ちます。デフォルト値は`120000`ミリ秒 (2 分) です。プールは、アイドル状態の接続を維持するために JDBC4 `isValid()`メソッドを使用することを優先します。 +- `maximumPoolSize` : プール内の最大接続数。デフォルト値は`10`です。コンテナ化された環境では、 Javaアプリケーションで使用可能な CPU コア数の 4～10 倍に設定することをお勧めします。この値を高く設定しすぎるとリソースの無駄遣いにつながり、低く設定しすぎると接続の取得が遅くなる可能性があります。 詳細については、[プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)を参照してください。 +- `minimumIdle` : HikariCPでは、このパラメータを設定しないことを推奨します。デフォルト値は`maximumPoolSize`の値と同じで、接続プールのスケーリングを無効にします。これにより、トラフィックの急増時にも接続がすぐに利用可能になり、接続作成による遅延を回避できます。 +- `connectionTimeout` : アプリケーションが接続プールから接続を取得するために待機する最大時間 (ミリ秒)。デフォルト値は`30000`ミリ秒 (30 秒) です。この時間内に利用可能な接続が得られない場合、 `SQLException`例外が発生します。 +- `maxLifetime` : プール内の接続の最大有効期間 (ミリ秒)。デフォルト値は`1800000`ミリ秒 (30 分) です。使用中の接続には影響しません。接続が閉じられた後、この設定に従って削除されます。この値を低く設定しすぎると、再接続が頻繁に発生する可能性があります。[`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)を使用している場合は、この値が待機時間よりも小さいことを確認してください。 +- `keepaliveTime` : プール内の接続に対するキープアライブ操作の間隔 (ミリ秒)。この設定は、データベースまたはネットワークのアイドルタイムアウトによって発生する切断を防ぐのに役立ちます。デフォルト値は`120000`ミリ秒 (2 分) です。プールは、アイドル状態の接続を維持するために JDBC4 `isValid()`メソッドを使用することを優先します。 ### プローブ構成 {#probe-configuration} 接続プールは、以下のようにクライアントから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では、デフォルトでは（エラーが報告されない限り）クライアント接続を積極的に閉じることはありません。 +- バージョン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)などのネットワークプロキシが存在する場合があります。これらのプロキシは通常、特定のアイドル期間（プロキシのアイドル設定によって決定されます）が経過すると、接続を自動的にクリーンアップします。接続プールは、プロキシのアイドル設定を監視するだけでなく、キープアライブのために接続を維持またはプローブする必要もあります。 @@ -276,9 +276,9 @@ The last packet sent successfully to the server was 3600000 milliseconds ago. Th `n`の値が非常に大きい場合 (上記の例の`3600000`など)、この接続が長時間アイドル状態になり、中間プロキシによって閉じられた可能性が高いです。通常の解決策は、プロキシのアイドル設定の値を増やし、接続プールが次の操作を実行できるようにすることです。 -- 接続を使用する前に毎回接続が利用可能かどうかを確認してください。 -- 別のスレッドを使用して、接続が利用可能かどうかを定期的に確認してください。 -- 接続を維持するために、定期的にテストクエリを送信してください。 +- 接続を使用する前に毎回接続が利用可能かどうかを確認してください。 +- 別のスレッドを使用して、接続が利用可能かどうかを定期的に確認してください。 +- 接続を維持するために、定期的にテストクエリを送信してください。 接続プールの実装によっては、上記の方法のうち1つ以上がサポートされている場合があります。対応する設定については、接続プールのドキュメントを参照してください。 @@ -296,8 +296,8 @@ The last packet sent successfully to the server was 3600000 milliseconds ago. Th MyBatis Mapperは2つのパラメータをサポートしています。 -- `select 1 from t where id = #{param1}` 、プリペアドステートメントとして`select 1 from t where id =?`に変換され、「準備済み」の状態になります。実際のパラメータは再利用されます。このパラメータを前述の接続準備パラメータと併用すると、最高のパフォーマンスが得られます。 -- `select 1 from t where id = ${param2}`はテキストファイル`select 1 from t where id = 1`に置き換えられ、実行されます。このステートメントが異なるパラメータに置き換えられて実行されると、MyBatis はステートメントの「準備」のために TiDB に異なるリクエストを送信します。これにより、TiDB が多数のプリペアドステートメントをキャッシュする可能性があり、この方法で SQL 操作を実行すると、インジェクションのセキュリティリスクが発生します。 +- `select 1 from t where id = #{param1}` 、プリペアドステートメントとして`select 1 from t where id =?`に変換され、「準備済み」の状態になります。実際のパラメータは再利用されます。このパラメータを前述の接続準備パラメータと併用すると、最高のパフォーマンスが得られます。 +- `select 1 from t where id = ${param2}`はテキストファイル`select 1 from t where id = 1`に置き換えられ、実行されます。このステートメントが異なるパラメータに置き換えられて実行されると、MyBatis はステートメントの「準備」のために TiDB に異なるリクエストを送信します。これにより、TiDB が多数のプリペアドステートメントをキャッシュする可能性があり、この方法で SQL 操作を実行すると、インジェクションのセキュリティリスクが発生します。 #### 動的SQLバッチ {#dynamic-sql-batch} @@ -327,9 +327,9 @@ MyBatis Mapperは2つのパラメータをサポートしています。 [前のセクション](#use-streamingresult-to-get-the-execution-result)JDBC で読み取り実行結果をストリーミングする方法を紹介します。 MyBatis で超大規模な結果セットを読み込む場合は、JDBC の対応する設定に加えて、次の点にも注意する必要があります。 -- マッパー構成で単一の SQL ステートメントに対して`fetchSize`を設定できます (前のコードブロックを参照)。その効果は、JDBC で`setFetchSize`を呼び出すのと同等です。 -- `ResultHandler`を使用したクエリ インターフェースを使用すると、結果セット全体を一度に取得することを避けることができます。 -- ストリーム読み取りには`Cursor`クラスを使用できます。 +- マッパー構成で単一の SQL ステートメントに対して`fetchSize`を設定できます (前のコードブロックを参照)。その効果は、JDBC で`setFetchSize`を呼び出すのと同等です。 +- `ResultHandler`を使用したクエリ インターフェースを使用すると、結果セット全体を一度に取得することを避けることができます。 +- ストリーム読み取りには`Cursor`クラスを使用できます。 XML を使用してマッピングを設定する場合、マッピングの`fetchSize="-2147483648"`セクションで`Integer.MIN_VALUE` } ( `
オペレーティングシステムサポートされているCPUアーキテクチャ
Red Hat Enterprise Linux 9.4 以降の 9.x バージョン
  • x86_64
  • ARM 64
Red Hat Enterprise Linux 8.6 以降の 8.x バージョン
  • x86_64
  • ARM 64
Amazon Linux 2
  • x86_64
  • ARM 64
Amazon Linux 2023
  • x86_64
  • ARM 64
Rocky Linux 9.1以降
  • x86_64
  • ARM 64
Kylin V10 SP1/SP2/SP3（SP3はv7.5.5以降でサポートされています）
  • x86_64
  • ARM 64
UnionTech OS (UOS) V20
  • x86_64
  • ARM 64
openEuler 22.03 LTS SP1/SP3
  • x86_64
  • ARM 64
> **Warning:** > - > - [CentOS Linux サポート終了](https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/)よると、CentOS Linux 7 のアップストリーム サポートは 2024 年 6 月 30 日に終了しました。 - > - TiDBをアップグレードする前に、オペレーティングシステムのバージョンを確認してください。TiDB v8.4.0 DMRおよびv8.5.0では、glibc 2.17のサポートが終了し、CentOS Linux 7のサポートとテストも終了しました。Rocky Linux 9.1以降のバージョンを使用することをお勧めします。CentOS 7上のTiDBクラスタをv8.4.0またはv8.5.0にアップグレードすると、クラスタが利用できなくなるリスクがあります。 - > - CentOS Linux 7 をまだ使用しているユーザーを支援するために、v8.5.1 以降、TiDB は glibc 2.17 のサポートを再開し、CentOS Linux 7 のテストを再開し、CentOS Linux 7 と互換性を持つようになりました。ただし、CentOS Linux の EOL ステータスのため、CentOS Linux 7 の[公式発表およびセキュリティに関するガイダンス](https://www.redhat.com/en/blog/centos-linux-has-reached-its-end-life-eol)を確認し、Rocky Linux 9.1 や TiDB が本番用にサポートするオペレーティング システムに移行することを強くお勧めします。 後で。 - > - [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB は、8.4 DMR バージョン以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタを v8.4.0 以降にアップグレードすると、クラスタが使用できなくなります。TiDB をアップグレードする前に、オペレーティングシステムのバージョンを確認してください。 + > - [CentOS Linux サポート終了](https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/)よると、CentOS Linux 7 のアップストリーム サポートは 2024 年 6 月 30 日に終了しました。 + > - TiDBをアップグレードする前に、オペレーティングシステムのバージョンを確認してください。TiDB v8.4.0 DMRおよびv8.5.0では、glibc 2.17のサポートが終了し、CentOS Linux 7のサポートとテストも終了しました。Rocky Linux 9.1以降のバージョンを使用することをお勧めします。CentOS 7上のTiDBクラスタをv8.4.0またはv8.5.0にアップグレードすると、クラスタが利用できなくなるリスクがあります。 + > - CentOS Linux 7 をまだ使用しているユーザーを支援するために、v8.5.1 以降、TiDB は glibc 2.17 のサポートを再開し、CentOS Linux 7 のテストを再開し、CentOS Linux 7 と互換性を持つようになりました。ただし、CentOS Linux の EOL ステータスのため、CentOS Linux 7 の[公式発表およびセキュリティに関するガイダンス](https://www.redhat.com/en/blog/centos-linux-has-reached-its-end-life-eol)を確認し、Rocky Linux 9.1 や TiDB が本番用にサポートするオペレーティング システムに移行することを強くお勧めします。 後で。 + > - [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB は、8.4 DMR バージョン以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタを v8.4.0 以降にアップグレードすると、クラスタが使用できなくなります。TiDB をアップグレードする前に、オペレーティングシステムのバージョンを確認してください。 > **Note:** > > Red Hat Enterprise Linux 9.x のサポートは[TiUP](https://github.com/pingcap/tiup/releases) v1.16.5 から開始されます。 -- 以下のオペレーティングシステムとCPUアーキテクチャの組み合わせであれば、TiDBのコンパイル、ビルド、デプロイが可能です。さらに、OLTP、OLAP、およびデータツールの基本機能も利用できます。ただし、これらの組み合わせは包括的かつ体系的なテストを受けていないため、TiDBは**エンタープライズレベルの本番品質を保証するものではありません**。 +- 以下のオペレーティングシステムとCPUアーキテクチャの組み合わせであれば、TiDBのコンパイル、ビルド、デプロイが可能です。さらに、OLTP、OLAP、およびデータツールの基本機能も利用できます。ただし、これらの組み合わせは包括的かつ体系的なテストを受けていないため、TiDBは**エンタープライズレベルの本番品質を保証するものではありません**。
オペレーティングシステムサポートされているCPUアーキテクチャ
macOS 12 (Monterey) 以降
  • x86_64
  • ARM 64
Oracle Enterprise Linux 8以降x86_64
Ubuntu LTS 20.04以降x86_64
CentOS Stream 8
  • x86_64
  • ARM 64
Debian 10 (Buster) 以降x86_64
Fedora 38以降x86_64
openSUSE Leap v15.5以降（Tumbleweedを除く） x86_64
SUSE Linux Enterprise Server 15 x86_64
> **Note:** > - > - Oracle Enterprise Linuxの場合、TiDBはRed Hat互換カーネル（RHCK）をサポートしており、Oracle Enterprise Linuxが提供するUnbreakable Enterprise Kernelはサポートしていません。 - > - TiDBの今後のバージョンでは、Ubuntu 16.04のサポートは終了します。Ubuntu 18.04以降へのアップグレードを強くお勧めします。 - > - CentOS Stream 8 は、2024 年 5 月 31 日に[ビルド終了](https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/)。 + > - Oracle Enterprise Linuxの場合、TiDBはRed Hat互換カーネル（RHCK）をサポートしており、Oracle Enterprise Linuxが提供するUnbreakable Enterprise Kernelはサポートしていません。 + > - TiDBの今後のバージョンでは、Ubuntu 16.04のサポートは終了します。Ubuntu 18.04以降へのアップグレードを強くお勧めします。 + > - CentOS Stream 8 は、2024 年 5 月 31 日に[ビルド終了](https://blog.centos.org/2023/04/end-dates-are-coming-for-centos-stream-8-and-centos-linux-7/)。 -- 前述の 2 つの表に記載されているオペレーティングシステムの 32 ビット版を使用している場合、TiDB は 32 ビットオペレーティングシステムおよび対応する CPUアーキテクチャ上でコンパイル、ビルド、またはデプロイできることが**保証されません**。また、TiDB は 32 ビットオペレーティングシステムに積極的に対応しません。 +- 前述の 2 つの表に記載されているオペレーティングシステムの 32 ビット版を使用している場合、TiDB は 32 ビットオペレーティングシステムおよび対応する CPUアーキテクチャ上でコンパイル、ビルド、またはデプロイできることが**保証されません**。また、TiDB は 32 ビットオペレーティングシステムに積極的に対応しません。 -- 上記に記載されていない他のオペレーティングシステムバージョンでも動作する可能性はありますが、公式にはサポートされていません。 +- 上記に記載されていない他のオペレーティングシステムバージョンでも動作する可能性はありますが、公式にはサポートされていません。 ### TiDBのコンパイルと実行に必要なライブラリ {#libraries-required-for-compiling-and-running-tidb} @@ -63,8 +63,8 @@ TiDBの実行に必要なライブラリ：glibc（バージョン2.28-151.el8 以下のCPUアーキテクチャがサポートされています。 -- x86_64。 TiDB v6.6.0 以降では、 [x86-64-v2命令セット](https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level)が必要です。 -- ARM 64 +- x86_64。 TiDB v6.6.0 以降では、 [x86-64-v2命令セット](https://developers.redhat.com/blog/2021/01/05/building-red-hat-enterprise-linux-9-for-the-x86-64-v2-microarchitecture-level)が必要です。 +- ARM 64 ## ソフトウェア要件 {#software-requirements} @@ -104,11 +104,11 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ > **Note:** > -> - テスト環境では、TiDBとPDのインスタンスを同じサーバーにデプロイできます。 -> - 性能関連のテストにおいては、テスト結果の正確性を保証するため、性能の低いストレージおよびネットワークハードウェア構成を使用しないでください。 -> - TiKVサーバーには、読み書き速度を向上させるためにNVMe SSDの使用をお勧めします。 -> - 機能をテストして確認するだけの場合は、 [TiDB クイックスタートガイド](/quick-start-with-tidb.md)に従って単一マシンに TiDB を展開してください。 -> - バージョン 6.3.0 以降、Linux AMD64アーキテクチャでTiFlash をデプロイするには、CPU が AVX2 命令セットをサポートしている必要があります。 `grep avx2 /proc/cpuinfo`に出力があることを確認してください。Linux ARM64アーキテクチャでTiFlash をデプロイするには、CPU が ARMv8 命令セットアーキテクチャをサポートしている必要があります。 `grep 'crc32' /proc/cpuinfo | grep 'asimd'`に出力があることを確認してください。命令セット拡張機能を使用することで、TiFlash のベクトル化エンジンはより優れたパフォーマンスを発揮できます。 +> - テスト環境では、TiDBとPDのインスタンスを同じサーバーにデプロイできます。 +> - 性能関連のテストにおいては、テスト結果の正確性を保証するため、性能の低いストレージおよびネットワークハードウェア構成を使用しないでください。 +> - TiKVサーバーには、読み書き速度を向上させるためにNVMe SSDの使用をお勧めします。 +> - 機能をテストして確認するだけの場合は、 [TiDB クイックスタートガイド](/quick-start-with-tidb.md)に従って単一マシンに TiDB を展開してください。 +> - バージョン 6.3.0 以降、Linux AMD64アーキテクチャでTiFlash をデプロイするには、CPU が AVX2 命令セットをサポートしている必要があります。 `grep avx2 /proc/cpuinfo`に出力があることを確認してください。Linux ARM64アーキテクチャでTiFlash をデプロイするには、CPU が ARMv8 命令セットアーキテクチャをサポートしている必要があります。 `grep 'crc32' /proc/cpuinfo | grep 'asimd'`に出力があることを確認してください。命令セット拡張機能を使用することで、TiFlash のベクトル化エンジンはより優れたパフォーマンスを発揮できます。 ### 本番環境 {#production-environment} @@ -124,21 +124,21 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ > **Note:** > -> - 本番環境では、TiDBとPDのインスタンスを同じサーバーにデプロイできます。ただし、より高いパフォーマンスと信頼性を求める場合は、それぞれを別々にデプロイすることをお勧めします。 -> - 本番環境では、TiDB、TiKV、およびTiFlashをそれぞれ最低8コアのCPUで構成することを強く推奨します。より高いパフォーマンスを得るには、さらに高い構成をお勧めします。 -> - PCIe SSDを使用する場合はTiKVハードディスクの容量を4TB以内に、通常のSSDを使用する場合は1.5TB以内に抑えることをお勧めします。 -> - AWS、Google Cloud、Azureなどのクラウドプロバイダー上にTiDBクラスタをデプロイする場合は、インスタンスストアではなくクラウドディスクをTiKVノードに使用することをお勧めします。 +> - 本番環境では、TiDBとPDのインスタンスを同じサーバーにデプロイできます。ただし、より高いパフォーマンスと信頼性を求める場合は、それぞれを別々にデプロイすることをお勧めします。 +> - 本番環境では、TiDB、TiKV、およびTiFlashをそれぞれ最低8コアのCPUで構成することを強く推奨します。より高いパフォーマンスを得るには、さらに高い構成をお勧めします。 +> - PCIe SSDを使用する場合はTiKVハードディスクの容量を4TB以内に、通常のSSDを使用する場合は1.5TB以内に抑えることをお勧めします。 +> - AWS、Google Cloud、Azureなどのクラウドプロバイダー上にTiDBクラスタをデプロイする場合は、インスタンスストアではなくクラウドディスクをTiKVノードに使用することをお勧めします。 > -> - インスタンスストアボリュームのデータ耐久性は比較的低いです。インスタンスストアのライフサイクルは仮想マシンのライフサイクルと連動しています。インスタンスの再起動、停止、移行、ハードウェア障害、またはメンテナンスが行われると、データが失われる可能性があります。ほとんどのクラウドプロバイダーは、インスタンスストアを一時的なストレージとして明示的に分類しています。たとえば、 [AWSドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html)によると、「インスタンスストアボリューム上のデータは、関連付けられたインスタンスの存続期間中のみ保持されます。インスタンスを停止、休止状態、または終了すると、インスタンスストアボリューム上のデータはすべて失われます。」 -> - インスタンスストアボリュームは通常、スナップショットやノード間・リージョン間のレプリケーションをサポートしていません。そのため、データの破損やハードウェア障害が発生した場合、迅速なデータ復旧は困難です。 -> - インスタンスストアの容量はインスタンスタイプに紐づいており、個別にスケーリングすることはできません。 +> - インスタンスストアボリュームのデータ耐久性は比較的低いです。インスタンスストアのライフサイクルは仮想マシンのライフサイクルと連動しています。インスタンスの再起動、停止、移行、ハードウェア障害、またはメンテナンスが行われると、データが失われる可能性があります。ほとんどのクラウドプロバイダーは、インスタンスストアを一時的なストレージとして明示的に分類しています。たとえば、 [AWSドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Storage.html)によると、「インスタンスストアボリューム上のデータは、関連付けられたインスタンスの存続期間中のみ保持されます。インスタンスを停止、休止状態、または終了すると、インスタンスストアボリューム上のデータはすべて失われます。」 +> - インスタンスストアボリュームは通常、スナップショットやノード間・リージョン間のレプリケーションをサポートしていません。そのため、データの破損やハードウェア障害が発生した場合、迅速なデータ復旧は困難です。 +> - インスタンスストアの容量はインスタンスタイプに紐づいており、個別にスケーリングすることはできません。 TiFlashを導入する前に、以下の項目に注意してください。 -- TiFlash は[複数のディスクに展開されています](/tiflash/tiflash-configuration.md#multi-disk-deployment)。 -- TiFlashデータディレクトリの最初のディスクとして、TiKVデータのリアルタイムレプリケーションをバッファリングするために、高性能SSDを使用することをお勧めします。このディスクの性能は、PCIe SSDなど、TiKVと同等以上である必要があります。ディスク容量は、総容量の10%以上でなければなりません。そうでない場合、このノードのボトルネックになる可能性があります。他のディスクには通常のSSDを使用することもできますが、より高性能なPCIe SSDを使用すると、パフォーマンスが向上することに注意してください。 -- TiFlashはTiKVとは別のノードにデプロイすることをお勧めします。どうしても同じノードにTiFlashとTiKVをデプロイする必要がある場合は、CPUコア数とメモリ容量を増やし、互いに干渉しないようにTiFlashとTiKVを異なるディスクにデプロイするようにしてください。 -- TiFlashディスクの総容量は、次のように計算されます: `the data volume of the entire TiKV cluster to be replicated / the number of TiKV replicas * the number of TiFlash replicas` 。たとえば、TiKV の計画容量が 1 TB、TiKV レプリカ数が 3、 TiFlashレプリカ数が 2 の場合、推奨されるTiFlashの総容量は`1024 GB / 3 * 2`です。一部のテーブルのデータのみを複製することもできます。その場合は、複製するテーブルのデータ量に応じてTiFlash の容量を決定します。 +- TiFlash は[複数のディスクに展開されています](/tiflash/tiflash-configuration.md#multi-disk-deployment)。 +- TiFlashデータディレクトリの最初のディスクとして、TiKVデータのリアルタイムレプリケーションをバッファリングするために、高性能SSDを使用することをお勧めします。このディスクの性能は、PCIe SSDなど、TiKVと同等以上である必要があります。ディスク容量は、総容量の10%以上でなければなりません。そうでない場合、このノードのボトルネックになる可能性があります。他のディスクには通常のSSDを使用することもできますが、より高性能なPCIe SSDを使用すると、パフォーマンスが向上することに注意してください。 +- TiFlashはTiKVとは別のノードにデプロイすることをお勧めします。どうしても同じノードにTiFlashとTiKVをデプロイする必要がある場合は、CPUコア数とメモリ容量を増やし、互いに干渉しないようにTiFlashとTiKVを異なるディスクにデプロイするようにしてください。 +- TiFlashディスクの総容量は、次のように計算されます: `the data volume of the entire TiKV cluster to be replicated / the number of TiKV replicas * the number of TiFlash replicas` 。たとえば、TiKV の計画容量が 1 TB、TiKV レプリカ数が 3、 TiFlashレプリカ数が 2 の場合、推奨されるTiFlashの総容量は`1024 GB / 3 * 2`です。一部のテーブルのデータのみを複製することもできます。その場合は、複製するテーブルのデータ量に応じてTiFlash の容量を決定します。 TiCDCを導入する前に、500GB以上のPCIe SSDディスクにTiCDCを導入することを推奨します。 @@ -190,12 +190,12 @@ TiDBは、データベースメトリクスの可視化に[Grafana](https://graf 前述のTiFlashソフトウェアおよびハードウェア要件は、結合されたストレージとコンピューティングアーキテクチャに関するものです。 v7.0.0 以降、 TiFlash は[分散型ストレージおよびコンピューティングアーキテクチャ](/tiflash/tiflash-disaggregated-and-s3.md)をサポートします。このアーキテクチャでは、 TiFlash は書き込みノードと計算ノードの 2 種類のノードに分割されます。これらのノードの要件は次のとおりです。 -- ソフトウェア: 結合されたストレージとコンピューティングアーキテクチャと同じままです。 [OSおよびプラットフォームの要件](#os-and-platform-requirements)を参照してください。 -- ネットワーク ポート: 結合されたストレージとコンピューティングアーキテクチャと同じままです。[ネットワーク](#network-requirements)を参照してください。 -- ディスク容量: - - TiFlash書き込みノード： TiFlashレプリカの追加時およびリージョンレプリカの移行時に、データをAmazon S3にアップロードする前にローカルバッファとして使用されるディスク容量は、少なくとも200GB以上設定することをお勧めします。また、Amazon S3と互換性のあるオブジェクトストレージが必要です。 - - TiFlash計算ノード：パフォーマンス向上のため、主に書き込みノードから読み取ったデータをキャッシュする目的で、最低でも100GBのディスク容量を設定することをお勧めします。計算ノードのキャッシュが満杯になる場合がありますが、これは正常な動作です。 -- CPUとメモリの要件については、以下のセクションで説明します。 +- ソフトウェア: 結合されたストレージとコンピューティングアーキテクチャと同じままです。 [OSおよびプラットフォームの要件](#os-and-platform-requirements)を参照してください。 +- ネットワーク ポート: 結合されたストレージとコンピューティングアーキテクチャと同じままです。[ネットワーク](#network-requirements)を参照してください。 +- ディスク容量: + - TiFlash書き込みノード： TiFlashレプリカの追加時およびリージョンレプリカの移行時に、データをAmazon S3にアップロードする前にローカルバッファとして使用されるディスク容量は、少なくとも200GB以上設定することをお勧めします。また、Amazon S3と互換性のあるオブジェクトストレージが必要です。 + - TiFlash計算ノード：パフォーマンス向上のため、主に書き込みノードから読み取ったデータをキャッシュする目的で、最低でも100GBのディスク容量を設定することをお勧めします。計算ノードのキャッシュが満杯になる場合がありますが、これは正常な動作です。 +- CPUとメモリの要件については、以下のセクションで説明します。 ### 開発環境およびテスト環境 {#development-and-test-environments} diff --git a/hybrid-deployment-topology.md b/hybrid-deployment-topology.md index f9c8c1c3a43a8..8bf356f293b7f 100644 --- a/hybrid-deployment-topology.md +++ b/hybrid-deployment-topology.md @@ -26,8 +26,8 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて ### トポロジテンプレート {#topology-templates} -- [ハイブリッド展開のためのシンプルなテンプレート](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) +- [ハイブリッド展開のためのシンプルなテンプレート](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)を参照してください。 @@ -35,42 +35,42 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて このセクションでは、単一マシンに複数のインスタンスをデプロイする際の主要なパラメータについて説明します。これは主に、単一マシンにTiDBとTiKVの複数のインスタンスをデプロイするシナリオで使用されます。以下の計算方法に従って、結果を構成テンプレートに入力する必要があります。 -- TiKVの設定を最適化する +- TiKVの設定を最適化する - - `readpool`スレッドプールに自己適応するように設定します。`readpool.unified.max-thread-count`パラメータを設定することで、 `readpool.storage`と`readpool.coprocessor`が統合スレッドプールを共有し、それぞれ自己適応スイッチを設定できます。 + - `readpool`スレッドプールに自己適応するように設定します。`readpool.unified.max-thread-count`パラメータを設定することで、 `readpool.storage`と`readpool.coprocessor`が統合スレッドプールを共有し、それぞれ自己適応スイッチを設定できます。 - - `readpool.storage`と`readpool.coprocessor`有効にする: + - `readpool.storage`と`readpool.coprocessor`有効にする: ```yaml readpool.storage.use-unified-pool: true readpool.coprocessor.use-unified-pool: true ``` - - 計算方法： + - 計算方法： ``` readpool.unified.max-thread-count = cores * 0.8 / the number of TiKV instances ``` - - storageCF（すべてのRocksDB列ファミリー）をメモリに適応させるように設定するには、 `storage.block-cache.capacity`パラメータを設定することで、CFがメモリ使用量を自動的に調整できるようになります。 + - storageCF（すべてのRocksDB列ファミリー）をメモリに適応させるように設定するには、 `storage.block-cache.capacity`パラメータを設定することで、CFがメモリ使用量を自動的に調整できるようになります。 - - 計算方法： + - 計算方法： ``` storage.block-cache.capacity = (MEM_TOTAL * 0.5 / the number of TiKV instances) ``` - - 複数の TiKV インスタンスが同じ物理ディスクにデプロイされている場合は、TiKV 構成に`capacity`パラメータを追加します。 + - 複数の TiKV インスタンスが同じ物理ディスクにデプロイされている場合は、TiKV 構成に`capacity`パラメータを追加します。 ``` raftstore.capacity = disk total capacity / the number of TiKV instances ``` -- ラベルスケジュール設定 +- ラベルスケジュール設定 1台のマシンに複数のTiKVインスタンスがデプロイされているため、物理マシンがダウンすると、 Raftグループはデフォルトの3つのレプリカのうち2つを失い、クラスターが利用できなくなる可能性があります。この問題に対処するには、ラベルを使用してPDのスマートスケジューリングを有効にします。これにより、 Raftグループは同一マシン上の複数のTiKVインスタンスに2つ以上のレプリカを持つようになります。 - - TiKV構成 + - TiKV構成 同じ物理マシンに対して同じホストレベルのラベル情報が構成されています。 @@ -80,7 +80,7 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて host: tikv1 ``` - - PD構成 + - PD構成 PD がリージョンを識別してスケジュールできるようにするには、PD のラベル タイプを構成します。 @@ -89,17 +89,17 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて replication.location-labels: ["host"] ``` -- `numa_node`コアバインディング +- `numa_node`コアバインディング - - インスタンスパラメータモジュールで、対応するパラメータ`numa_node`を設定し、CPUコアの数を追加します。 + - インスタンスパラメータモジュールで、対応するパラメータ`numa_node`を設定し、CPUコアの数を追加します。 - - NUMAを使用してコアをバインドする前に、numactlツールがインストールされていること、および物理マシンのCPU情報を確認してください。その後、パラメータを設定してください。 + - NUMAを使用してコアをバインドする前に、numactlツールがインストールされていること、および物理マシンのCPU情報を確認してください。その後、パラメータを設定してください。 - - `numa_node`パラメータは`numactl --membind`構成に対応します。 + - `numa_node`パラメータは`numactl --membind`構成に対応します。 > **Note:** > -> - 構成ファイル テンプレートを編集するときは、必要なパラメータ、IP、ポート、およびディレクトリを変更します。 -> - 各コンポーネントは、グローバルポートの`/-`デフォルトでポート`deploy_dir`として使用します。例えば、TiDBがポート`4001`を指定した場合、そのポート`deploy_dir`デフォルトで`/tidb-deploy/tidb-4001`なります。したがって、マルチインスタンスのシナリオでは、デフォルト以外のポートを指定する場合、ディレクトリを再度指定する必要はありません。 -> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPTiUPコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、コントロールマシンと同じユーザーを維持することもできます。 -> - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 +> - 構成ファイル テンプレートを編集するときは、必要なパラメータ、IP、ポート、およびディレクトリを変更します。 +> - 各コンポーネントは、グローバルポートの`/-`デフォルトでポート`deploy_dir`として使用します。例えば、TiDBがポート`4001`を指定した場合、そのポート`deploy_dir`デフォルトで`/tidb-deploy/tidb-4001`なります。したがって、マルチインスタンスのシナリオでは、デフォルト以外のポートを指定する場合、ディレクトリを再度指定する必要はありません。 +> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPTiUPコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、コントロールマシンと同じユーザーを維持することもできます。 +> - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/identify-expensive-queries.md b/identify-expensive-queries.md index 02cf48694e7d2..afa36900dea40 100644 --- a/identify-expensive-queries.md +++ b/identify-expensive-queries.md @@ -21,36 +21,36 @@ TiDBを使用すると、SQL実行中に高負荷なクエリを特定できる 基本フィールド: -- `cost_time` : ログが印刷されるときのステートメントの実行時間。 -- `stats` : 文に関係するテーブルまたはインデックスで使用される統計情報のバージョン。値が`pseudo`の場合、利用可能な統計情報がないことを意味します。この場合、テーブルまたはインデックスを分析する必要があります。 -- `table_ids` : ステートメントに関係するテーブルの ID。 -- `txn_start_ts` : トランザクションの開始タイムスタンプと一意のID。この値を使用して、トランザクション関連のログを検索できます。 -- `sql` : SQL ステートメント。 -- `session_alias` : 現在のセッションのエイリアス。 -- `affected rows` : 現在ステートメントによって影響を受けている行数。 +- `cost_time` : ログが印刷されるときのステートメントの実行時間。 +- `stats` : 文に関係するテーブルまたはインデックスで使用される統計情報のバージョン。値が`pseudo`の場合、利用可能な統計情報がないことを意味します。この場合、テーブルまたはインデックスを分析する必要があります。 +- `table_ids` : ステートメントに関係するテーブルの ID。 +- `txn_start_ts` : トランザクションの開始タイムスタンプと一意のID。この値を使用して、トランザクション関連のログを検索できます。 +- `sql` : SQL ステートメント。 +- `session_alias` : 現在のセッションのエイリアス。 +- `affected rows` : 現在ステートメントによって影響を受けている行数。 メモリ使用量関連のフィールド: -- `mem_max` : ログ出力時のステートメントのメモリ使用量。このフィールドには、メモリ使用量を測定するための単位として、バイトと、その他の読みやすく適応性の高い単位（MBやGBなど）の2種類があります。 +- `mem_max` : ログ出力時のステートメントのメモリ使用量。このフィールドには、メモリ使用量を測定するための単位として、バイトと、その他の読みやすく適応性の高い単位（MBやGBなど）の2種類があります。 ユーザー関連フィールド: -- `user` : ステートメントを実行するユーザーの名前。 -- `conn_id` : 接続ID（セッションID）。例えば、キーワード`con:60026`を使用すると、セッションIDが`60026`ログを検索できます。 -- `database` : ステートメントが実行されるデータベース。 +- `user` : ステートメントを実行するユーザーの名前。 +- `conn_id` : 接続ID（セッションID）。例えば、キーワード`con:60026`を使用すると、セッションIDが`60026`ログを検索できます。 +- `database` : ステートメントが実行されるデータベース。 TiKVコプロセッサータスク関連フィールド: -- `wait_time` : TiKV 内のステートメントにおけるすべてのコプロセッサー要求の合計待機時間。TiKV のコプロセッサーは限られた数のスレッドを実行するため、コプロセッサーのすべてのスレッドが動作している場合でも、要求がキューイングされる可能性があります。キュー内の要求の処理に時間がかかる場合、後続の要求の待機時間が増加します。 -- `request_count` : ステートメントが送信するコプロセッサー要求の数。 -- `total_keys` :コプロセッサーがスキャンしたキーの数。 -- `processed_keys` :コプロセッサーが処理したキーの数。`total_keys`と比較すると、 `processed_keys`には古いバージョンの MVCC は含まれません。`processed_keys`と`total_keys`の差が大きいことから、古いバージョンが多数存在することがわかります。 -- `num_cop_tasks` : ステートメントが送信するコプロセッサー要求の数。 -- `process_avg_time` :コプロセッサータスクの平均実行時間。 -- `process_p90_time` :コプロセッサータスクの P90 実行時間。 -- `process_max_time` :コプロセッサータスクの最大実行時間。 -- `process_max_addr` : 実行時間が最も長いコプロセッサータスクのアドレス。 -- `wait_avg_time` :コプロセッサータスクの平均待機時間。 -- `wait_p90_time` :コプロセッサータスクの P90 待機時間。 -- `wait_max_time` :コプロセッサータスクの最大待機時間。 -- `wait_max_addr` : 待機時間が最も長いコプロセッサータスクのアドレス。 +- `wait_time` : TiKV 内のステートメントにおけるすべてのコプロセッサー要求の合計待機時間。TiKV のコプロセッサーは限られた数のスレッドを実行するため、コプロセッサーのすべてのスレッドが動作している場合でも、要求がキューイングされる可能性があります。キュー内の要求の処理に時間がかかる場合、後続の要求の待機時間が増加します。 +- `request_count` : ステートメントが送信するコプロセッサー要求の数。 +- `total_keys` :コプロセッサーがスキャンしたキーの数。 +- `processed_keys` :コプロセッサーが処理したキーの数。`total_keys`と比較すると、 `processed_keys`には古いバージョンの MVCC は含まれません。`processed_keys`と`total_keys`の差が大きいことから、古いバージョンが多数存在することがわかります。 +- `num_cop_tasks` : ステートメントが送信するコプロセッサー要求の数。 +- `process_avg_time` :コプロセッサータスクの平均実行時間。 +- `process_p90_time` :コプロセッサータスクの P90 実行時間。 +- `process_max_time` :コプロセッサータスクの最大実行時間。 +- `process_max_addr` : 実行時間が最も長いコプロセッサータスクのアドレス。 +- `wait_avg_time` :コプロセッサータスクの平均待機時間。 +- `wait_p90_time` :コプロセッサータスクの P90 待機時間。 +- `wait_max_time` :コプロセッサータスクの最大待機時間。 +- `wait_max_addr` : 待機時間が最も長いコプロセッサータスクのアドレス。 diff --git a/identify-slow-queries.md b/identify-slow-queries.md index 2bd6e08e87033..c22723f85ad65 100644 --- a/identify-slow-queries.md +++ b/identify-slow-queries.md @@ -52,125 +52,125 @@ insert into t select * from t; スロークエリの基本： -- `Time` : ログの印刷時間。 -- `Query_time` : ステートメントの実行時間。 -- `Parse_time` : ステートメントの解析時間。 -- `Compile_time` : クエリ最適化の所要時間。 -- `Optimize_time` : 実行計画の最適化に要した時間。 -- `Wait_TS` : ステートメントがトランザクションのタイムスタンプを取得するまでの待機時間。 -- `Query` : SQL ステートメント。 `Query`はスローログには出力されませんが、対応するフィールドは、スローログがメモリテーブルにマッピングされた後に`Query`と呼ばれます。 -- `Digest` : SQL ステートメントのフィンガープリント。 -- `Txn_start_ts` : トランザクションの開始タイムスタンプと一意のID。この値を使用して、トランザクション関連のログを検索できます。 -- `Is_internal` : SQL ステートメントが TiDB 内部で実行されるかどうか。 `true`は、SQL ステートメントが TiDB 内部で実行されることを示し、 `false`は、SQL ステートメントがユーザーによって実行されることを示します。 -- `Index_names` : ステートメントで使用されるインデックス名。 -- `Stats` : このクエリ中に使用される統計情報の健全性状態、内部バージョン、総行数、変更された行数、およびロード状態。 `pseudo`統計情報が健全でないことを示します。オプティマイザが完全にロードされていない統計情報を使用しようとすると、内部状態も出力されます。たとえば、 `t1:439478225786634241[105000;5000][col1:allEvicted][idx1:allEvicted]`の意味は次のように理解できます。 - - `t1` : テーブル`t1`の統計情報は、クエリ最適化中に使用されます。 - - `439478225786634241` : 内部バージョン。 - - `105000` : 統計情報における行の総数。 - - `5000` : 前回の統計収集以降に変更された行数。 - - `col1:allEvicted` : 列`col1`の統計情報が完全には読み込まれていません。 - - `idx1:allEvicted` : インデックス`idx1`の統計情報が完全には読み込まれていません。 -- `Succ` : ステートメントが正常に実行されたかどうか。 -- `Backoff_time` : ステートメントが再試行を必要とするエラーに遭遇した場合の、再試行までの待機時間。このような一般的なエラーには、 `lock occurs` 、 `Region split` 、および`tikv server is busy`などがあります。 -- `Plan` : ステートメントの実行計画。 `SELECT tidb_decode_plan('xxx...')`ステートメントを実行して、具体的な実行計画を解析します。 -- `Binary_plan` : バイナリエンコードされたステートメントの実行計画。特定の実行計画を解析するには、 [`SELECT tidb_decode_binary_plan('xxx...')`](/functions-and-operators/tidb-functions.md#tidb_decode_binary_plan)ステートメントを実行します。 `Plan`および`Binary_plan`フィールドには同じ情報が含まれています。ただし、これら 2 つのフィールドから解析される実行計画の形式は異なります。 -- `Prepared` : このステートメントが`Prepare`または`Execute`の要求であるかどうか。 -- `Plan_from_cache` : このステートメントが実行プランキャッシュにヒットするかどうか。 -- `Plan_from_binding` : このステートメントがバインドされた実行計画を使用するかどうか。 -- `Has_more_results` : このステートメントには、ユーザーが取得できる結果がさらにあるかどうか。 -- `Rewrite_time` : このステートメントのクエリを書き換えるのに要した時間。 -- `Preproc_subqueries` : ステートメント内で事前に実行されるサブクエリの数。たとえば、 `where id in (select if from t)`サブクエリが事前に実行される場合があります。 -- `Preproc_subqueries_time` : このステートメントのサブクエリを事前に実行するために要した時間。 -- `Exec_retry_count` : このステートメントの再試行回数。このフィールドは通常、ロックが失敗した場合にステートメントが再試行される悲観的トランザクションに使用されます。 -- `Exec_retry_time` : このステートメントの実行再試行時間。たとえば、ステートメントが合計 3 回実行された場合 (最初の 2 回は失敗)、 `Exec_retry_time`は最初の 2 回の実行の合計時間を意味します。最後の実行の時間は、 `Query_time`から`Exec_retry_time`を引いた時間です。 -- `KV_total` : このステートメントによって、TiKV またはTiFlash上のすべての RPC リクエストに費やされた時間。 -- `PD_total` : このステートメントによる PD 上のすべての RPC リクエストに費やされた時間。 -- `Backoff_total` : このステートメントの実行中にすべてのバックオフに費やされた時間。 -- `Write_sql_response_total` : このステートメントによって結果をクライアントに送信するのに要した時間。 -- `Result_rows` : クエリ結果の行数。 -- `IsExplicitTxn` : このステートメントが明示的なトランザクションに含まれているかどうか。値が`false`の場合、トランザクションは`autocommit=1`となり、ステートメントは実行後に自動的にコミットされます。 -- `Warnings` : このステートメントの実行中に生成される JSON 形式の警告。これらの警告は、一般的に[`SHOW WARNINGS`](/sql-statements/sql-statement-show-warnings.md)ステートメントの出力と一致しますが、より詳細な診断情報を提供する追加の警告が含まれる場合があります。これらの追加の警告は`IsExtra: true`としてマークされます。 +- `Time` : ログの印刷時間。 +- `Query_time` : ステートメントの実行時間。 +- `Parse_time` : ステートメントの解析時間。 +- `Compile_time` : クエリ最適化の所要時間。 +- `Optimize_time` : 実行計画の最適化に要した時間。 +- `Wait_TS` : ステートメントがトランザクションのタイムスタンプを取得するまでの待機時間。 +- `Query` : SQL ステートメント。 `Query`はスローログには出力されませんが、対応するフィールドは、スローログがメモリテーブルにマッピングされた後に`Query`と呼ばれます。 +- `Digest` : SQL ステートメントのフィンガープリント。 +- `Txn_start_ts` : トランザクションの開始タイムスタンプと一意のID。この値を使用して、トランザクション関連のログを検索できます。 +- `Is_internal` : SQL ステートメントが TiDB 内部で実行されるかどうか。 `true`は、SQL ステートメントが TiDB 内部で実行されることを示し、 `false`は、SQL ステートメントがユーザーによって実行されることを示します。 +- `Index_names` : ステートメントで使用されるインデックス名。 +- `Stats` : このクエリ中に使用される統計情報の健全性状態、内部バージョン、総行数、変更された行数、およびロード状態。 `pseudo`統計情報が健全でないことを示します。オプティマイザが完全にロードされていない統計情報を使用しようとすると、内部状態も出力されます。たとえば、 `t1:439478225786634241[105000;5000][col1:allEvicted][idx1:allEvicted]`の意味は次のように理解できます。 + - `t1` : テーブル`t1`の統計情報は、クエリ最適化中に使用されます。 + - `439478225786634241` : 内部バージョン。 + - `105000` : 統計情報における行の総数。 + - `5000` : 前回の統計収集以降に変更された行数。 + - `col1:allEvicted` : 列`col1`の統計情報が完全には読み込まれていません。 + - `idx1:allEvicted` : インデックス`idx1`の統計情報が完全には読み込まれていません。 +- `Succ` : ステートメントが正常に実行されたかどうか。 +- `Backoff_time` : ステートメントが再試行を必要とするエラーに遭遇した場合の、再試行までの待機時間。このような一般的なエラーには、 `lock occurs` 、 `Region split` 、および`tikv server is busy`などがあります。 +- `Plan` : ステートメントの実行計画。 `SELECT tidb_decode_plan('xxx...')`ステートメントを実行して、具体的な実行計画を解析します。 +- `Binary_plan` : バイナリエンコードされたステートメントの実行計画。特定の実行計画を解析するには、 [`SELECT tidb_decode_binary_plan('xxx...')`](/functions-and-operators/tidb-functions.md#tidb_decode_binary_plan)ステートメントを実行します。 `Plan`および`Binary_plan`フィールドには同じ情報が含まれています。ただし、これら 2 つのフィールドから解析される実行計画の形式は異なります。 +- `Prepared` : このステートメントが`Prepare`または`Execute`の要求であるかどうか。 +- `Plan_from_cache` : このステートメントが実行プランキャッシュにヒットするかどうか。 +- `Plan_from_binding` : このステートメントがバインドされた実行計画を使用するかどうか。 +- `Has_more_results` : このステートメントには、ユーザーが取得できる結果がさらにあるかどうか。 +- `Rewrite_time` : このステートメントのクエリを書き換えるのに要した時間。 +- `Preproc_subqueries` : ステートメント内で事前に実行されるサブクエリの数。たとえば、 `where id in (select if from t)`サブクエリが事前に実行される場合があります。 +- `Preproc_subqueries_time` : このステートメントのサブクエリを事前に実行するために要した時間。 +- `Exec_retry_count` : このステートメントの再試行回数。このフィールドは通常、ロックが失敗した場合にステートメントが再試行される悲観的トランザクションに使用されます。 +- `Exec_retry_time` : このステートメントの実行再試行時間。たとえば、ステートメントが合計 3 回実行された場合 (最初の 2 回は失敗)、 `Exec_retry_time`は最初の 2 回の実行の合計時間を意味します。最後の実行の時間は、 `Query_time`から`Exec_retry_time`を引いた時間です。 +- `KV_total` : このステートメントによって、TiKV またはTiFlash上のすべての RPC リクエストに費やされた時間。 +- `PD_total` : このステートメントによる PD 上のすべての RPC リクエストに費やされた時間。 +- `Backoff_total` : このステートメントの実行中にすべてのバックオフに費やされた時間。 +- `Write_sql_response_total` : このステートメントによって結果をクライアントに送信するのに要した時間。 +- `Result_rows` : クエリ結果の行数。 +- `IsExplicitTxn` : このステートメントが明示的なトランザクションに含まれているかどうか。値が`false`の場合、トランザクションは`autocommit=1`となり、ステートメントは実行後に自動的にコミットされます。 +- `Warnings` : このステートメントの実行中に生成される JSON 形式の警告。これらの警告は、一般的に[`SHOW WARNINGS`](/sql-statements/sql-statement-show-warnings.md)ステートメントの出力と一致しますが、より詳細な診断情報を提供する追加の警告が含まれる場合があります。これらの追加の警告は`IsExtra: true`としてマークされます。 以下の項目はトランザクションの実行に関連しています。 -- `Prewrite_time` : 2 フェーズ トランザクション コミットの最初のフェーズ (プリライト) の期間。 -- `Commit_time` : 2 フェーズ トランザクション コミットの第 2 フェーズ (コミット) の期間。 -- `Get_commit_ts_time` : 2 フェーズ トランザクション コミットの第 2 フェーズ (コミット) で`commit_ts`を取得するのに費やされた時間。 -- `Local_latch_wait_time` : TiDB が 2 相トランザクションコミットの第 2 相 (コミット) の前にロックを待機するのに費やす時間。 -- `Write_keys` : トランザクションが TiKV の Write CF に書き込むキーの数。 -- `Write_size` : トランザクションがコミットされたときに書き込まれるキーまたは値の合計サイズ。 -- `Prewrite_region` : 2フェーズトランザクションコミットの第1フェーズ（プリライト）に関与するTiKVリージョンの数。各リージョンはリモートプロシージャコールをトリガーします。 -- `Wait_prewrite_binlog_time` : トランザクションがコミットされたときにバイナリログを書き込むのに要した時間。v8.4.0以降、TiDB Binlogは削除され、このフィールドには値がありません。 -- `Resolve_lock_time` : トランザクションのコミット中にロックが発生した場合、ロックを解消するか、ロックの有効期限が切れるまで待機する時間。 +- `Prewrite_time` : 2 フェーズ トランザクション コミットの最初のフェーズ (プリライト) の期間。 +- `Commit_time` : 2 フェーズ トランザクション コミットの第 2 フェーズ (コミット) の期間。 +- `Get_commit_ts_time` : 2 フェーズ トランザクション コミットの第 2 フェーズ (コミット) で`commit_ts`を取得するのに費やされた時間。 +- `Local_latch_wait_time` : TiDB が 2 相トランザクションコミットの第 2 相 (コミット) の前にロックを待機するのに費やす時間。 +- `Write_keys` : トランザクションが TiKV の Write CF に書き込むキーの数。 +- `Write_size` : トランザクションがコミットされたときに書き込まれるキーまたは値の合計サイズ。 +- `Prewrite_region` : 2フェーズトランザクションコミットの第1フェーズ（プリライト）に関与するTiKVリージョンの数。各リージョンはリモートプロシージャコールをトリガーします。 +- `Wait_prewrite_binlog_time` : トランザクションがコミットされたときにバイナリログを書き込むのに要した時間。v8.4.0以降、TiDB Binlogは削除され、このフィールドには値がありません。 +- `Resolve_lock_time` : トランザクションのコミット中にロックが発生した場合、ロックを解消するか、ロックの有効期限が切れるまで待機する時間。 メモリ使用量フィールド: -- `Mem_max` : SQL ステートメントの実行期間中に使用される最大メモリ領域 (単位はバイト)。 +- `Mem_max` : SQL ステートメントの実行期間中に使用される最大メモリ領域 (単位はバイト)。 ハードディスクの項目: -- `Disk_max` : SQL ステートメントの実行期間中に使用される最大ディスク容量 (単位はバイト)。 +- `Disk_max` : SQL ステートメントの実行期間中に使用される最大ディスク容量 (単位はバイト)。 ユーザーフィールド: -- `User` : このステートメントを実行するユーザーの名前。 -- `Host` : このステートメントのホスト名。 -- `Conn_ID` : 接続ID（セッションID）。たとえば、キーワード`con:3`を使用して、セッションIDが`3`のログを検索できます。 -- `DB` : 現在のデータベース。 +- `User` : このステートメントを実行するユーザーの名前。 +- `Host` : このステートメントのホスト名。 +- `Conn_ID` : 接続ID（セッションID）。たとえば、キーワード`con:3`を使用して、セッションIDが`3`のログを検索できます。 +- `DB` : 現在のデータベース。 TiKVコプロセッサータスクフィールド： -- `Request_count` : ステートメントが送信するコプロセッサー要求の数。 -- `Total_keys` :コプロセッサーがスキャンしたキーの数。 -- `Process_time` : TiKV における SQL ステートメントの合計処理時間。データは TiKV に同時送信されるため、この値は`Query_time`を超える場合があります。 -- `Wait_time` : TiKV におけるステートメントの合計待機時間。TiKV のコプロセッサーは限られた数のスレッドを実行するため、コプロセッサーのすべてのスレッドが動作している場合、リクエストがキューに蓄積される可能性があります。キュー内のリクエストの処理に時間がかかると、後続のリクエストの待機時間が増加します。 -- `Process_keys` :コプロセッサーが処理したキーの数。 `total_keys`と比較すると、 `processed_keys`には MVCC の古いバージョンは含まれていません。 `processed_keys`と`total_keys`の間に大きな差があることから、多くの古いバージョンが存在することがわかります。 -- `Num_cop_tasks` : このステートメントによって送信されたコプロセッサータスクの数。 -- `Cop_proc_avg` : RocksDB のミューテックスなど、カウントできない待機時間を含む、cop-tasks の平均実行時間。 -- `Cop_proc_p90` : cop-tasks の P90 実行時間。 -- `Cop_proc_max` : cop-tasks の最大実行時間。 -- `Cop_proc_addr` : 実行時間が最も長い cop-task のアドレス。 -- `Cop_wait_avg` : リクエストのキューイングとスナップショットの取得時間を含む、cop-tasks の平均待機時間。 -- `Cop_wait_p90` : cop-tasks の P90 待機時間。 -- `Cop_wait_max` : cop-tasks の最大待機時間。 -- `Cop_wait_addr` : 待ち時間が最も長い cop-task のアドレス。 -- `Rocksdb_delete_skipped_count` : RocksDB がデータをスキャンする際に検出する削除済み (tombstone) キーの数。 -- `Rocksdb_key_skipped_count` : RocksDB がデータをスキャンする際に遭遇するすべてのキーの数。 -- `Rocksdb_block_cache_hit_count` : RocksDB がブロックキャッシュからデータを読み取る回数。 -- `Rocksdb_block_read_count` : RocksDB がファイルシステムからデータを読み取る回数。 -- `Rocksdb_block_read_byte` : RocksDB がファイルシステムから読み取るデータ量。 -- `Rocksdb_block_read_time` : RocksDB がファイルシステムからデータを読み取るのにかかる時間。 -- `Cop_backoff_{backoff-type}_total_times` : エラーによって発生したバックオフの合計回数。 -- `Cop_backoff_{backoff-type}_total_time` : エラーによって発生したバックオフの合計時間。 -- `Cop_backoff_{backoff-type}_max_time` : エラーによって発生したバックオフの最長時間。 -- `Cop_backoff_{backoff-type}_max_addr` : エラーによって最も長いバックオフ時間が発生した cop-task のアドレス。 -- `Cop_backoff_{backoff-type}_avg_time` : エラーによって発生するバックオフの平均時間。 -- `Cop_backoff_{backoff-type}_p90_time` : エラーによって発生した P90 パーセンタイルバックオフ時間。 +- `Request_count` : ステートメントが送信するコプロセッサー要求の数。 +- `Total_keys` :コプロセッサーがスキャンしたキーの数。 +- `Process_time` : TiKV における SQL ステートメントの合計処理時間。データは TiKV に同時送信されるため、この値は`Query_time`を超える場合があります。 +- `Wait_time` : TiKV におけるステートメントの合計待機時間。TiKV のコプロセッサーは限られた数のスレッドを実行するため、コプロセッサーのすべてのスレッドが動作している場合、リクエストがキューに蓄積される可能性があります。キュー内のリクエストの処理に時間がかかると、後続のリクエストの待機時間が増加します。 +- `Process_keys` :コプロセッサーが処理したキーの数。 `total_keys`と比較すると、 `processed_keys`には MVCC の古いバージョンは含まれていません。 `processed_keys`と`total_keys`の間に大きな差があることから、多くの古いバージョンが存在することがわかります。 +- `Num_cop_tasks` : このステートメントによって送信されたコプロセッサータスクの数。 +- `Cop_proc_avg` : RocksDB のミューテックスなど、カウントできない待機時間を含む、cop-tasks の平均実行時間。 +- `Cop_proc_p90` : cop-tasks の P90 実行時間。 +- `Cop_proc_max` : cop-tasks の最大実行時間。 +- `Cop_proc_addr` : 実行時間が最も長い cop-task のアドレス。 +- `Cop_wait_avg` : リクエストのキューイングとスナップショットの取得時間を含む、cop-tasks の平均待機時間。 +- `Cop_wait_p90` : cop-tasks の P90 待機時間。 +- `Cop_wait_max` : cop-tasks の最大待機時間。 +- `Cop_wait_addr` : 待ち時間が最も長い cop-task のアドレス。 +- `Rocksdb_delete_skipped_count` : RocksDB がデータをスキャンする際に検出する削除済み (tombstone) キーの数。 +- `Rocksdb_key_skipped_count` : RocksDB がデータをスキャンする際に遭遇するすべてのキーの数。 +- `Rocksdb_block_cache_hit_count` : RocksDB がブロックキャッシュからデータを読み取る回数。 +- `Rocksdb_block_read_count` : RocksDB がファイルシステムからデータを読み取る回数。 +- `Rocksdb_block_read_byte` : RocksDB がファイルシステムから読み取るデータ量。 +- `Rocksdb_block_read_time` : RocksDB がファイルシステムからデータを読み取るのにかかる時間。 +- `Cop_backoff_{backoff-type}_total_times` : エラーによって発生したバックオフの合計回数。 +- `Cop_backoff_{backoff-type}_total_time` : エラーによって発生したバックオフの合計時間。 +- `Cop_backoff_{backoff-type}_max_time` : エラーによって発生したバックオフの最長時間。 +- `Cop_backoff_{backoff-type}_max_addr` : エラーによって最も長いバックオフ時間が発生した cop-task のアドレス。 +- `Cop_backoff_{backoff-type}_avg_time` : エラーによって発生するバックオフの平均時間。 +- `Cop_backoff_{backoff-type}_p90_time` : エラーによって発生した P90 パーセンタイルバックオフ時間。 `backoff-type`は、一般的に以下の種類が含まれます。 -- `tikvRPC` : TiKV への RPC リクエストの送信に失敗したために発生したバックオフ。 -- `tiflashRPC` : TiFlashへの RPC リクエストの送信に失敗したために発生したバックオフ。 -- `pdRPC` : PD への RPC リクエストの送信に失敗したために発生したバックオフ。 -- `txnLock` : ロックの競合によって発生するバックオフ。 -- `regionMiss` : リージョンが分割またはマージされた後に TiDBリージョンキャッシュ情報が古くなった場合に、リクエストの処理が失敗することによって発生するバックオフ。 -- `regionScheduling` : リージョンがスケジュールされていてLeaderが選択されていない場合、TiDB はリクエストを処理できないため、バックオフが発生します。 -- `tikvServerBusy` : TiKV の負荷が高すぎて新しいリクエストを処理できないために発生するバックオフ。 -- `tiflashServerBusy` : TiFlash の負荷が高すぎて新しいリクエストを処理できないために発生するバックオフ。 -- `tikvDiskFull` : TiKV ディスクがいっぱいになったことが原因で発生したバックオフ。 -- `txnLockFast` : データ読み取り中にロックが発生したことが原因で発生するバックオフ。 +- `tikvRPC` : TiKV への RPC リクエストの送信に失敗したために発生したバックオフ。 +- `tiflashRPC` : TiFlashへの RPC リクエストの送信に失敗したために発生したバックオフ。 +- `pdRPC` : PD への RPC リクエストの送信に失敗したために発生したバックオフ。 +- `txnLock` : ロックの競合によって発生するバックオフ。 +- `regionMiss` : リージョンが分割またはマージされた後に TiDBリージョンキャッシュ情報が古くなった場合に、リクエストの処理が失敗することによって発生するバックオフ。 +- `regionScheduling` : リージョンがスケジュールされていてLeaderが選択されていない場合、TiDB はリクエストを処理できないため、バックオフが発生します。 +- `tikvServerBusy` : TiKV の負荷が高すぎて新しいリクエストを処理できないために発生するバックオフ。 +- `tiflashServerBusy` : TiFlash の負荷が高すぎて新しいリクエストを処理できないために発生するバックオフ。 +- `tikvDiskFull` : TiKV ディスクがいっぱいになったことが原因で発生したバックオフ。 +- `txnLockFast` : データ読み取り中にロックが発生したことが原因で発生するバックオフ。 リソース制御に関連する分野： -- `Resource_group` : ステートメントがバインドされているリソース グループ。 -- `Request_unit_read` : ステートメントによって消費された読み取り RU の合計。 -- `Request_unit_write` : ステートメントによって消費された書き込み RU の合計。 -- `Time_queued_by_rc` : ステートメントが利用可能なリソースを待機する合計時間。 +- `Resource_group` : ステートメントがバインドされているリソース グループ。 +- `Request_unit_read` : ステートメントによって消費された読み取り RU の合計。 +- `Request_unit_write` : ステートメントによって消費された書き込み RU の合計。 +- `Time_queued_by_rc` : ステートメントが利用可能なリソースを待機する合計時間。 ストレージエンジンに関連する分野： -- `Storage_from_kv` : v8.5.5 で導入され、このステートメントが TiKV からデータを読み取ったかどうかを示します。 -- `Storage_from_mpp` : v8.5.5 で導入され、このステートメントがTiFlashからデータを読み取ったかどうかを示します。 +- `Storage_from_kv` : v8.5.5 で導入され、このステートメントが TiKV からデータを読み取ったかどうかを示します。 +- `Storage_from_mpp` : v8.5.5 で導入され、このステートメントがTiFlashからデータを読み取ったかどうかを示します。 ## `tidb_slow_log_rules`を使用する {#use-tidb_slow_log_rules} @@ -178,30 +178,30 @@ TiKVコプロセッサータスクフィールド： スロークエリログのトリガー動作は`tidb_slow_log_rules`の設定に依存します。 -- `tidb_slow_log_rules`が設定されていない場合、スロークエリログのトリガーは引き続き[`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold) (ミリ秒単位) に依存します。 -- `tidb_slow_log_rules`が設定されている場合、設定済みのルールが優先され、 [`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold)は無視されます。 +- `tidb_slow_log_rules`が設定されていない場合、スロークエリログのトリガーは引き続き[`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold) (ミリ秒単位) に依存します。 +- `tidb_slow_log_rules`が設定されている場合、設定済みのルールが優先され、 [`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold)は無視されます。 各フィールドの意味、診断値、および背景情報の詳細については、[フィールドの説明](#fields-description)を参照してください。 ### 統一されたルール構文と型制約 {#unified-rule-syntax-and-type-constraints} -- ルール容量と分離: `SESSION`と`GLOBAL`はそれぞれ最大 10 個のルールをサポートします。1 つのセッションで最大 20 個のアクティブなルールを持つことができます。ルールは`;`で分離されます。 -- 条件の形式: 各条件は`field_name:value`の形式を使用します。単一のルール内の複数の条件は`,`で区切られます。 -- フィールドとスコープ: フィールド名は大文字と小文字を区別しません (アンダースコアやその他の文字は保持されます)。 `SESSION`ルールは`Conn_ID`をサポートしていません。 `GLOBAL`ルールのみが`Conn_ID`をサポートしています。 -- 意味の一致： - - 数値フィールドは`>=`を使用して照合されます。文字列フィールドとブール値フィールドは等価性 ( `=` ) を使用して照合されます。 - - `DB`と`Resource_group`のマッチングは、大文字と小文字を区別しません。 - - `>` 、 `<` 、 `!=`などの明示的な演算子はサポートされていません。 +- ルール容量と分離: `SESSION`と`GLOBAL`はそれぞれ最大 10 個のルールをサポートします。1 つのセッションで最大 20 個のアクティブなルールを持つことができます。ルールは`;`で分離されます。 +- 条件の形式: 各条件は`field_name:value`の形式を使用します。単一のルール内の複数の条件は`,`で区切られます。 +- フィールドとスコープ: フィールド名は大文字と小文字を区別しません (アンダースコアやその他の文字は保持されます)。 `SESSION`ルールは`Conn_ID`をサポートしていません。 `GLOBAL`ルールのみが`Conn_ID`をサポートしています。 +- 意味の一致： + - 数値フィールドは`>=`を使用して照合されます。文字列フィールドとブール値フィールドは等価性 ( `=` ) を使用して照合されます。 + - `DB`と`Resource_group`のマッチングは、大文字と小文字を区別しません。 + - `>` 、 `<` 、 `!=`などの明示的な演算子はサポートされていません。 型制約は以下のとおりです。 -- 数値型（ `int64` 、 `uint64` 、 `float64` ）は、いずれも`>= 0`を必要とします。負の値を指定すると、解析エラーが発生します。 - - `int64` : 最大値は`2^63-1`です。 - - `uint64` : 最大値は`2^64-1`です。 - - `float64` : 一般的な上限はおおよそ`1.79e308`です。現在、解析は Go の`ParseFloat`を使用して行われています。 `NaN` / `Inf`は解析できますが、常に真または常に偽となるルールにつながる可能性があります。これらを使用することは推奨されません。 -- `bool` : `true` / `false` 、 `1` / `0` 、および`t` / `f`をサポートします (大文字小文字を区別しません)。 -- `string` : 現在`,` (条件区切り文字) または`;` (ルール区切り文字) を含む文字列は、引用符 (シングルクォートまたはダブルクォート) があってもサポートされていません。エスケープ処理もサポートされていません。 -- 重複するフィールド：単一のルール内で同じフィールドが複数回指定されている場合、最後に指定されたフィールドが有効になります。 +- 数値型（ `int64` 、 `uint64` 、 `float64` ）は、いずれも`>= 0`を必要とします。負の値を指定すると、解析エラーが発生します。 + - `int64` : 最大値は`2^63-1`です。 + - `uint64` : 最大値は`2^64-1`です。 + - `float64` : 一般的な上限はおおよそ`1.79e308`です。現在、解析は Go の`ParseFloat`を使用して行われています。 `NaN` / `Inf`は解析できますが、常に真または常に偽となるルールにつながる可能性があります。これらを使用することは推奨されません。 +- `bool` : `true` / `false` 、 `1` / `0` 、および`t` / `f`をサポートします (大文字小文字を区別しません)。 +- `string` : 現在`,` (条件区切り文字) または`;` (ルール区切り文字) を含む文字列は、引用符 (シングルクォートまたはダブルクォート) があってもサポートされていません。エスケープ処理もサポートされていません。 +- 重複するフィールド：単一のルール内で同じフィールドが複数回指定されている場合、最後に指定されたフィールドが有効になります。 ### サポートされているフィールド {#supported-fields} @@ -253,37 +253,37 @@ TiKVコプロセッサータスクフィールド： ### 効果的な行動とマッチング順序 {#effective-behavior-and-matching-order} -- ルール更新動作: `SET [SESSION|GLOBAL] tidb_slow_log_rules = '...'`の実行ごとに、既存のルールに追加するのではなく、そのスコープ内の既存のルールを上書きします。 -- ルールクリア動作: `SET [SESSION|GLOBAL] tidb_slow_log_rules = ''`対応するスコープ内のルールをクリアします。 -- 現在のセッションに、`SESSION`ルール、現在の`Conn_ID`に対する`GLOBAL`ルール、または`Conn_ID`を含まない一般的なグローバルルールなど、適用可能な`tidb_slow_log_rules`がある場合、スロークエリログの出力はルールのマッチング結果によって決定され、 `tidb_slow_log_threshold`は使用されなくなります。 -- 現在のセッションに適用可能なルールがない場合、たとえば`SESSION`と`GLOBAL`両方のルールが空の場合、または現在の`GLOBAL`に一致しない`Conn_ID`ルールのみが構成されている場合、スロークエリのログ記録は`tidb_slow_log_threshold`に依存します。単位はミリ秒であることに注意してください。 -- スローログを書き込む条件としてSQL実行時間を使用したい場合は、ルール内で`Query_time`を使用し、単位が秒であることに注意してください。 -- ルールマッチングロジック： - - 複数のルールは`OR`で結合され、単一のルール内の複数のフィールド条件は`AND`で結合されます。 - - `SESSION`スコープのルールが最初に一致します。一致するルールがない場合、TiDB は現在の`GLOBAL`に対して`Conn_ID`ルールを一致させ、続いて`GLOBAL`を含まない一般的な`Conn_ID`ルールを一致させます。 -- `SHOW VARIABLES LIKE 'tidb_slow_log_rules'`と`SELECT @@SESSION.tidb_slow_log_rules`は`SESSION`ルールテキストを返します。設定されていない場合は空の文字列を返します。 `SELECT @@GLOBAL.tidb_slow_log_rules` `GLOBAL`ルールテキストを返します。 +- ルール更新動作: `SET [SESSION|GLOBAL] tidb_slow_log_rules = '...'`の実行ごとに、既存のルールに追加するのではなく、そのスコープ内の既存のルールを上書きします。 +- ルールクリア動作: `SET [SESSION|GLOBAL] tidb_slow_log_rules = ''`対応するスコープ内のルールをクリアします。 +- 現在のセッションに、`SESSION`ルール、現在の`Conn_ID`に対する`GLOBAL`ルール、または`Conn_ID`を含まない一般的なグローバルルールなど、適用可能な`tidb_slow_log_rules`がある場合、スロークエリログの出力はルールのマッチング結果によって決定され、 `tidb_slow_log_threshold`は使用されなくなります。 +- 現在のセッションに適用可能なルールがない場合、たとえば`SESSION`と`GLOBAL`両方のルールが空の場合、または現在の`GLOBAL`に一致しない`Conn_ID`ルールのみが構成されている場合、スロークエリのログ記録は`tidb_slow_log_threshold`に依存します。単位はミリ秒であることに注意してください。 +- スローログを書き込む条件としてSQL実行時間を使用したい場合は、ルール内で`Query_time`を使用し、単位が秒であることに注意してください。 +- ルールマッチングロジック： + - 複数のルールは`OR`で結合され、単一のルール内の複数のフィールド条件は`AND`で結合されます。 + - `SESSION`スコープのルールが最初に一致します。一致するルールがない場合、TiDB は現在の`GLOBAL`に対して`Conn_ID`ルールを一致させ、続いて`GLOBAL`を含まない一般的な`Conn_ID`ルールを一致させます。 +- `SHOW VARIABLES LIKE 'tidb_slow_log_rules'`と`SELECT @@SESSION.tidb_slow_log_rules`は`SESSION`ルールテキストを返します。設定されていない場合は空の文字列を返します。 `SELECT @@GLOBAL.tidb_slow_log_rules` `GLOBAL`ルールテキストを返します。 ### 例 {#examples} -- 標準フォーマット（ `SESSION`範囲）： +- 標準フォーマット（ `SESSION`範囲）： ```sql SET SESSION tidb_slow_log_rules = 'Query_time: 0.5, Is_internal: false'; ``` -- 無効な形式です（ `SESSION`スコープは`Conn_ID`をサポートしていません）： +- 無効な形式です（ `SESSION`スコープは`Conn_ID`をサポートしていません）： ```sql SET SESSION tidb_slow_log_rules = 'Conn_ID: 12, Query_time: 0.5, Is_internal: false'; ``` -- グローバルルール（すべての接続に適用）： +- グローバルルール（すべての接続に適用）： ```sql SET GLOBAL tidb_slow_log_rules = 'Query_time: 0.5, Is_internal: false'; ``` -- 特定の接続に対するグローバルルール（ `Conn_ID:11`と`Conn_ID:12` 2 つの接続にそれぞれ適用されます）： +- 特定の接続に対するグローバルルール（ `Conn_ID:11`と`Conn_ID:12` 2 つの接続にそれぞれ適用されます）： ```sql SET GLOBAL tidb_slow_log_rules = 'Conn_ID: 11, Query_time: 0.5, Is_internal: false; Conn_ID: 12, Query_time: 0.6, Process_time: 0.3, DB: db1'; @@ -291,30 +291,30 @@ TiKVコプロセッサータスクフィールド： ### 推奨事項 {#recommendations} -- `tidb_slow_log_rules`単一しきい値方式に代わるように設計されています。多次元メトリック条件の組み合わせをサポートし、スロークエリのログ記録をより柔軟かつきめ細かく制御できます。 +- `tidb_slow_log_rules`単一しきい値方式に代わるように設計されています。多次元メトリック条件の組み合わせをサポートし、スロークエリのログ記録をより柔軟かつきめ細かく制御できます。 -- TiDBノード1台（CPUコア16個、メモリ48GiB）とTiKVノード3台（それぞれCPUコア16個、メモリ48GiB）を備えた十分なリソースが確保されたテスト環境で、sysbenchテストを繰り返したところ、多次元スロークエリログルールによって30分以内に数百万件のスローログエントリが生成されても、パフォーマンスへの影響は小さいままであることが分かりました。しかし、ログの量が数千万件に達すると、TPSが大幅に低下し、レイテンシーが著しく増加します。そのため、業務ワークロードが高い場合や、CPUとメモリのリソースが限界に近い場合は、 `tidb_slow_log_rules`を慎重に設定して、ルールが広すぎるためにログが大量に発生するのを防いでください。ログ出力レートを制限する必要がある場合は、 [`tidb_slow_log_max_per_sec`](/system-variables.md#tidb_slow_log_max_per_sec-new-in-v856)を使用してスロットリングを行い、業務パフォーマンスへの影響を軽減してください。 +- TiDBノード1台（CPUコア16個、メモリ48GiB）とTiKVノード3台（それぞれCPUコア16個、メモリ48GiB）を備えた十分なリソースが確保されたテスト環境で、sysbenchテストを繰り返したところ、多次元スロークエリログルールによって30分以内に数百万件のスローログエントリが生成されても、パフォーマンスへの影響は小さいままであることが分かりました。しかし、ログの量が数千万件に達すると、TPSが大幅に低下し、レイテンシーが著しく増加します。そのため、業務ワークロードが高い場合や、CPUとメモリのリソースが限界に近い場合は、 `tidb_slow_log_rules`を慎重に設定して、ルールが広すぎるためにログが大量に発生するのを防いでください。ログ出力レートを制限する必要がある場合は、 [`tidb_slow_log_max_per_sec`](/system-variables.md#tidb_slow_log_max_per_sec-new-in-v856)を使用してスロットリングを行い、業務パフォーマンスへの影響を軽減してください。 ## 関連するシステム変数 {#related-system-variables} -- [`tidb_slow_log_rules`](/system-variables.md#tidb_slow_log_rules-new-in-v856) : [`tidb_slow_log_rules`推奨事項](#recommendations)を参照 +- [`tidb_slow_log_rules`](/system-variables.md#tidb_slow_log_rules-new-in-v856) : [`tidb_slow_log_rules`推奨事項](#recommendations)を参照 -- [`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold) : スロークエリログのしきい値を設定します。実行時間がこのしきい値を超える SQL ステートメントは、スロークエリログに記録されます。デフォルト値は`300ms` (ミリ秒) です。 +- [`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold) : スロークエリログのしきい値を設定します。実行時間がこのしきい値を超える SQL ステートメントは、スロークエリログに記録されます。デフォルト値は`300ms` (ミリ秒) です。 > **Tip:** > > `tidb_slow_log_rules`の時間関連フィールド（ `Query_time`や`Process_time`など）は単位として秒を使用し、小数点を含むことができますが、 [`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold)はミリ秒を使用します。 -- [`tidb_slow_log_max_per_sec`](/system-variables.md#tidb_slow_log_max_per_sec-new-in-v856) : 1 秒あたりに書き込めるスロークエリログエントリの最大数を設定します。デフォルト値は`0`です。この変数は v8.5.6 で導入されました。 - - `0`という値は、1 秒あたりに書き込まれるスロークエリログエントリの数に制限がないことを意味します。 - - `0`より大きい値を指定すると、TiDBは1秒あたりに指定された数のスロークエリログエントリを書き込みます。超過分のログエントリは破棄され、スロークエリログファイルには書き込まれません。 - - ルールベースのスロークエリログが頻繁にトリガーされるのを防ぐため、 `tidb_slow_log_rules`を有効にした後にこの変数を設定することをお勧めします。 +- [`tidb_slow_log_max_per_sec`](/system-variables.md#tidb_slow_log_max_per_sec-new-in-v856) : 1 秒あたりに書き込めるスロークエリログエントリの最大数を設定します。デフォルト値は`0`です。この変数は v8.5.6 で導入されました。 + - `0`という値は、1 秒あたりに書き込まれるスロークエリログエントリの数に制限がないことを意味します。 + - `0`より大きい値を指定すると、TiDBは1秒あたりに指定された数のスロークエリログエントリを書き込みます。超過分のログエントリは破棄され、スロークエリログファイルには書き込まれません。 + - ルールベースのスロークエリログが頻繁にトリガーされるのを防ぐため、 `tidb_slow_log_rules`を有効にした後にこの変数を設定することをお勧めします。 -- [`tidb_query_log_max_len`](/system-variables.md#tidb_query_log_max_len) : スロークエリログに記録されるSQLステートメントの最大長を設定します。デフォルト値は4096バイトです。 +- [`tidb_query_log_max_len`](/system-variables.md#tidb_query_log_max_len) : スロークエリログに記録されるSQLステートメントの最大長を設定します。デフォルト値は4096バイトです。 -- [`tidb_redact_log`](/system-variables.md#tidb_redact_log) : スロークエリログに記録される SQL ステートメント内のユーザーデータが秘匿化され、 `?`に置き換えられるかどうかを制御します。デフォルト値は`0`で、この機能は無効になっています。 +- [`tidb_redact_log`](/system-variables.md#tidb_redact_log) : スロークエリログに記録される SQL ステートメント内のユーザーデータが秘匿化され、 `?`に置き換えられるかどうかを制御します。デフォルト値は`0`で、この機能は無効になっています。 -- [`tidb_enable_collect_execution_info`](/system-variables.md#tidb_enable_collect_execution_info) : 実行計画内の各オペレーターの物理実行情報を記録するかどうかを制御します。デフォルト値は`1`です。この機能はパフォーマンスに約 3% 影響します。この機能を有効にすると、 `Plan`の情報を次のように表示できます。 +- [`tidb_enable_collect_execution_info`](/system-variables.md#tidb_enable_collect_execution_info) : 実行計画内の各オペレーターの物理実行情報を記録するかどうかを制御します。デフォルト値は`1`です。この機能はパフォーマンスに約 3% 影響します。この機能を有効にすると、 `Plan`の情報を次のように表示できます。 ```sql > select tidb_decode_plan('jAOIMAk1XzE3CTAJMQlmdW5jczpjb3VudChDb2x1bW4jNyktPkMJC/BMNQkxCXRpbWU6MTAuOTMxNTA1bXMsIGxvb3BzOjIJMzcyIEJ5dGVzCU4vQQoxCTMyXzE4CTAJMQlpbmRleDpTdHJlYW1BZ2dfOQkxCXQRSAwyNzY4LkgALCwgcnBjIG51bTogMQkMEXMQODg0MzUFK0hwcm9jIGtleXM6MjUwMDcJMjA2HXsIMgk1BWM2zwAAMRnIADcVyAAxHcEQNQlOL0EBBPBbCjMJMTNfMTYJMQkzMTI4MS44NTc4MTk5MDUyMTcJdGFibGU6dCwgaW5kZXg6aWR4KGEpLCByYW5nZTpbLWluZiw1MDAwMCksIGtlZXAgb3JkZXI6ZmFsc2UJMjUBrgnQVnsA'); @@ -349,7 +349,7 @@ set @@tidb_enable_collect_execution_info=0; TiDB 4.0 では、 `SLOW_QUERY`は、ローテーションされたスローログファイルを含む、任意の期間のスローログのクエリをサポートしています。解析する必要のあるスローログファイルを見つけるには`TIME`の範囲を指定する必要があります。 `TIME`の範囲を指定しない場合、TiDB は現在のスローログファイルのみを解析します。例: -- 時間範囲を指定しない場合、TiDB はスローログファイルに書き込むスロークエリデータのみを解析します。 +- 時間範囲を指定しない場合、TiDB はスローログファイルに書き込むスロークエリデータのみを解析します。 ```sql select count(*), @@ -366,7 +366,7 @@ TiDB 4.0 では、 `SLOW_QUERY`は、ローテーションされたスローロ +----------+----------------------------+----------------------------+ ``` -- 例えば、 `2020-03-10 00:00:00`から`2020-03-11 00:00:00`までといった時間範囲を指定すると、TiDB はまず指定された時間範囲のスローログファイルを探し出し、次にスロークエリ情報を解析します。 +- 例えば、 `2020-03-10 00:00:00`から`2020-03-11 00:00:00`までといった時間範囲を指定すると、TiDB はまず指定された時間範囲のスローログファイルを探し出し、次にスロークエリ情報を解析します。 ```sql select count(*), @@ -445,7 +445,7 @@ limit 2; 上位N個のSQL文を照会した後、同じフィンガープリントを使用して、同様の低速なクエリを引き続き照会します。 -1. 処理速度の遅い上位N件のクエリと、それに対応するSQLフィンガープリントを取得します。 +1. 処理速度の遅い上位N件のクエリと、それに対応するSQLフィンガープリントを取得します。 ```sql select query_time, query, digest @@ -465,7 +465,7 @@ limit 2; +-------------+-----------------------------+------------------------------------------------------------------+ ``` -2. 同様のスロークエリをフィンガープリントを使って照会する。 +2. 同様のスロークエリをフィンガープリントを使って照会する。 ```sql select query, query_time diff --git a/import-example-data.md b/import-example-data.md index d3b6f3008f762..b2e3eb0f9e706 100644 --- a/import-example-data.md +++ b/import-example-data.md @@ -22,13 +22,13 @@ unzip \*-tripdata.zip 次の方法を使用して、システム データを TiDB にインポートできます。 -1. CSV ファイルの名前を変更します。 +1. CSV ファイルの名前を変更します。 ```bash i=1; for csv in *csv; do mv $csv bikeshare.trips.$(printf "%03d" $i).csv; i=$((i+1)); done ``` -2. データベースとテーブルを作成します。 +2. データベースとテーブルを作成します。 ```sql CREATE SCHEMA bikeshare; @@ -47,7 +47,7 @@ unzip \*-tripdata.zip ); ``` -3. 次のように`tidb-lightning.toml`ファイルを作成します。 +3. 次のように`tidb-lightning.toml`ファイルを作成します。 ```toml [tikv-importer] @@ -67,7 +67,7 @@ unzip \*-tripdata.zip password = "very_secret" ``` -4. 次のコマンドを実行します。 +4. 次のコマンドを実行します。 ```shell tiup tidb-lightning -c tidb-lightning.toml diff --git a/index-advisor.md b/index-advisor.md index bb671ceb70675..2a67f4759c6de 100644 --- a/index-advisor.md +++ b/index-advisor.md @@ -116,10 +116,10 @@ RECOMMEND INDEX SHOW OPTION; 以下のオプションが利用可能です。 -- `timeout` : `RECOMMEND INDEX`コマンドの実行に許容される最大時間を指定します。 -- `max_num_index` : `RECOMMEND INDEX`の結果に含めるインデックスの最大数を指定します。 -- `max_index_columns` : 結果の複数列インデックスで許可される最大列数を指定します。 -- `max_num_query` : ステートメントサマリーワークロードから選択するクエリの最大数を指定します。 +- `timeout` : `RECOMMEND INDEX`コマンドの実行に許容される最大時間を指定します。 +- `max_num_index` : `RECOMMEND INDEX`の結果に含めるインデックスの最大数を指定します。 +- `max_index_columns` : 結果の複数列インデックスで許可される最大列数を指定します。 +- `max_num_query` : ステートメントサマリーワークロードから選択するクエリの最大数を指定します。 現在のオプション設定を確認するには、 `RECOMMEND INDEX SHOW OPTION`ステートメントを実行してください。 @@ -147,9 +147,9 @@ Query OK, 1 row affected (0.00 sec) インデックス推奨機能には、以下の制限事項があります。 -- 現在、[プリペアドステートメント](/develop/dev-guide-prepared-statement.md)ステートメントはサポートされていません。 `RECOMMEND INDEX RUN`ステートメントは`Prepare`および`Execute`プロトコルを介して実行されるクエリに対してインデックスを推奨することはできません。 -- 現時点では、インデックスの削除に関する推奨事項は提供されていません。 -- 現在、インデックスアドバイザーのユーザーインターフェース（UI）はまだ提供されていません。 +- 現在、[プリペアドステートメント](/develop/dev-guide-prepared-statement.md)ステートメントはサポートされていません。 `RECOMMEND INDEX RUN`ステートメントは`Prepare`および`Execute`プロトコルを介して実行されるクエリに対してインデックスを推奨することはできません。 +- 現時点では、インデックスの削除に関する推奨事項は提供されていません。 +- 現在、インデックスアドバイザーのユーザーインターフェース（UI）はまだ提供されていません。 ## 使用されていないインデックスを削除する {#remove-unused-indexes} diff --git a/information-schema/client-errors-summary-by-host.md b/information-schema/client-errors-summary-by-host.md index 2993c5efa6ae8..968f80b61a6c6 100644 --- a/information-schema/client-errors-summary-by-host.md +++ b/information-schema/client-errors-summary-by-host.md @@ -7,20 +7,20 @@ summary: CLIENT_ERRORS_SUMMARY_BY_HOST` INFORMATION_SCHEMA テーブルについ 表`CLIENT_ERRORS_SUMMARY_BY_HOST`は、TiDBサーバーに接続したクライアントに返されたSQLエラーと警告の概要を示しています。これには以下が含まれます。 -- 不正な SQL ステートメント。 -- ゼロ除算エラー。 -- 範囲外または重複したキー値を挿入しようとしました。 -- 権限エラー。 -- 存在しないテーブル。 +- 不正な SQL ステートメント。 +- ゼロ除算エラー。 +- 範囲外または重複したキー値を挿入しようとしました。 +- 権限エラー。 +- 存在しないテーブル。 これらのエラーはMySQLサーバープロトコルを介してクライアントに返され、アプリケーションは適切なアクションを実行することが期待されます。表`INFORMATION_SCHEMA.CLIENT_ERRORS_SUMMARY_BY_HOST`は、アプリケーションがTiDBサーバーから返されたエラーを適切に処理（またはログに記録）していないシナリオにおいて、エラーを検査するための便利な方法を提供します。 `CLIENT_ERRORS_SUMMARY_BY_HOST`リモートホストごとにエラーを要約するため、あるアプリケーションサーバーが他のサーバーよりも多くのエラーを生成しているシナリオを診断するのに役立ちます。考えられるシナリオは次のとおりです。 -- 時代遅れの MySQL クライアント ライブラリ。 -- 古いアプリケーション (新しいデプロイメントを展開するときにこのサーバーが見逃された可能性があります)。 -- ユーザー権限の「ホスト」部分の使用方法が間違っています。 -- 信頼性の低いネットワーク接続により、タイムアウトや接続切断がさらに発生します。 +- 時代遅れの MySQL クライアント ライブラリ。 +- 古いアプリケーション (新しいデプロイメントを展開するときにこのサーバーが見逃された可能性があります)。 +- ユーザー権限の「ホスト」部分の使用方法が間違っています。 +- 信頼性の低いネットワーク接続により、タイムアウトや接続切断がさらに発生します。 集計されたカウントは、ステートメント`FLUSH CLIENT_ERRORS_SUMMARY`を使用してリセットできます。集計は各 TiDBサーバーにローカルであり、メモリ内にのみ保持されます。TiDBサーバーを再起動すると、集計は失われます。 @@ -48,13 +48,13 @@ DESC CLIENT_ERRORS_SUMMARY_BY_HOST; フィールドの説明: -- `HOST` : クライアントのリモート ホスト。 -- `ERROR_NUMBER` : 返された MySQL 互換エラー番号。 -- `ERROR_MESSAGE` : エラー番号に一致するエラー メッセージ (プリペアドステートメント形式)。 -- `ERROR_COUNT` : このエラーがクライアント ホストに返された回数。 -- `WARNING_COUNT` : この警告がクライアント ホストに返された回数。 -- `FIRST_SEEN` : このエラー (または警告) がクライアント ホストから初めて確認されました。 -- `LAST_SEEN` : このエラー (または警告) がクライアント ホストから最後に確認された時刻。 +- `HOST` : クライアントのリモート ホスト。 +- `ERROR_NUMBER` : 返された MySQL 互換エラー番号。 +- `ERROR_MESSAGE` : エラー番号に一致するエラー メッセージ (プリペアドステートメント形式)。 +- `ERROR_COUNT` : このエラーがクライアント ホストに返された回数。 +- `WARNING_COUNT` : この警告がクライアント ホストに返された回数。 +- `FIRST_SEEN` : このエラー (または警告) がクライアント ホストから初めて確認されました。 +- `LAST_SEEN` : このエラー (または警告) がクライアント ホストから最後に確認された時刻。 以下の例は、クライアントがローカルTiDBサーバーに接続する際に生成される警告を示しています。`FLUSH CLIENT_ERRORS_SUMMARY`を実行するとサマリーはリセットされます。 diff --git a/information-schema/client-errors-summary-by-user.md b/information-schema/client-errors-summary-by-user.md index c5787c5841542..b6df23119161a 100644 --- a/information-schema/client-errors-summary-by-user.md +++ b/information-schema/client-errors-summary-by-user.md @@ -7,19 +7,19 @@ summary: CLIENT_ERRORS_SUMMARY_BY_USER` INFORMATION_SCHEMA テーブルについ 表`CLIENT_ERRORS_SUMMARY_BY_USER`は、TiDBサーバーに接続したクライアントに返されたSQLエラーと警告の概要を示しています。これには以下が含まれます。 -- 不正な SQL ステートメント。 -- ゼロ除算エラー。 -- 範囲外または重複したキー値を挿入しようとしました。 -- 権限エラー。 -- 存在しないテーブル。 +- 不正な SQL ステートメント。 +- ゼロ除算エラー。 +- 範囲外または重複したキー値を挿入しようとしました。 +- 権限エラー。 +- 存在しないテーブル。 クライアントエラーはMySQLサーバープロトコルを介してクライアントに返され、アプリケーションは適切なアクションを実行することが期待されます。`INFORMATION_SCHEMA.CLIENT_ERRORS_SUMMARY_BY_USER`表は、アプリケーションがTiDBサーバーから返されたエラーを適切に処理（またはログに記録）していないシナリオにおいて、エラーを検査するための便利な方法を提供します。 `CLIENT_ERRORS_SUMMARY_BY_USER`ユーザーごとにエラーを要約するため、あるユーザーサーバーが他のサーバーよりも多くのエラーを生成しているシナリオを診断するのに役立ちます。考えられるシナリオには以下が含まれます。 -- 権限エラー。 -- テーブルまたはリレーショナル オブジェクトが見つかりません。 -- SQL 構文が正しくないか、アプリケーションと TiDB のバージョン間に互換性がありません。 +- 権限エラー。 +- テーブルまたはリレーショナル オブジェクトが見つかりません。 +- SQL 構文が正しくないか、アプリケーションと TiDB のバージョン間に互換性がありません。 集計されたカウントは、ステートメント`FLUSH CLIENT_ERRORS_SUMMARY`でリセットできます。集計は各 TiDBサーバーにローカルであり、メモリ内にのみ保持されます。TiDBサーバーが再起動すると、集計は失われます。 @@ -47,13 +47,13 @@ DESC CLIENT_ERRORS_SUMMARY_BY_USER; フィールドの説明: -- `USER` : 認証されたユーザー。 -- `ERROR_NUMBER` : 返された MySQL 互換エラー番号。 -- `ERROR_MESSAGE` : エラー番号に一致するエラー メッセージ (プリペアドステートメント形式)。 -- `ERROR_COUNT` : このエラーがユーザーに返された回数。 -- `WARNING_COUNT` : この警告がユーザーに返された回数。 -- `FIRST_SEEN` : このエラー (または警告) がユーザーに初めて送信されたとき。 -- `LAST_SEEN` : このエラー (または警告) がユーザーに最後に送信された時刻。 +- `USER` : 認証されたユーザー。 +- `ERROR_NUMBER` : 返された MySQL 互換エラー番号。 +- `ERROR_MESSAGE` : エラー番号に一致するエラー メッセージ (プリペアドステートメント形式)。 +- `ERROR_COUNT` : このエラーがユーザーに返された回数。 +- `WARNING_COUNT` : この警告がユーザーに返された回数。 +- `FIRST_SEEN` : このエラー (または警告) がユーザーに初めて送信されたとき。 +- `LAST_SEEN` : このエラー (または警告) がユーザーに最後に送信された時刻。 以下の例は、クライアントがローカルTiDBサーバーに接続する際に生成される警告を示しています。`FLUSH CLIENT_ERRORS_SUMMARY`を実行するとサマリーはリセットされます。 diff --git a/information-schema/client-errors-summary-global.md b/information-schema/client-errors-summary-global.md index 71296e372fec6..add96de463a5c 100644 --- a/information-schema/client-errors-summary-global.md +++ b/information-schema/client-errors-summary-global.md @@ -7,11 +7,11 @@ summary: CLIENT_ERRORS_SUMMARY_GLOBAL` INFORMATION_SCHEMA テーブルについ 表`CLIENT_ERRORS_SUMMARY_GLOBAL`は、TiDBサーバーに接続したクライアントに返されたすべてのSQLエラーと警告のグローバルサマリーを示しています。これには以下が含まれます。 -- 不正な SQL ステートメント。 -- ゼロ除算エラー。 -- 範囲外の重複キー値を挿入しようとしました。 -- 権限エラー。 -- テーブルが存在しません。 +- 不正な SQL ステートメント。 +- ゼロ除算エラー。 +- 範囲外の重複キー値を挿入しようとしました。 +- 権限エラー。 +- テーブルが存在しません。 クライアントエラーはMySQLサーバープロトコルを介してクライアントに返され、アプリケーションは適切なアクションを実行することが期待されます。表`INFORMATION_SCHEMA.CLIENT_ERRORS_SUMMARY_GLOBAL`は概要を示しており、アプリケーションがTiDBサーバーから返されたエラーを適切に処理（またはログに記録）していないシナリオで役立ちます。 @@ -40,12 +40,12 @@ DESC CLIENT_ERRORS_SUMMARY_GLOBAL; フィールドの説明: -- `ERROR_NUMBER` : 返された MySQL 互換エラー番号。 -- `ERROR_MESSAGE` : エラー番号に一致するエラー メッセージ (プリペアドステートメント形式)。 -- `ERROR_COUNT` : このエラーが返された回数。 -- `WARNING_COUNT` : この警告が返された回数。 -- `FIRST_SEEN` : このエラー (または警告) が最初に送信されたとき。 -- `LAST_SEEN` : このエラー (または警告) が最後に送信された時刻。 +- `ERROR_NUMBER` : 返された MySQL 互換エラー番号。 +- `ERROR_MESSAGE` : エラー番号に一致するエラー メッセージ (プリペアドステートメント形式)。 +- `ERROR_COUNT` : このエラーが返された回数。 +- `WARNING_COUNT` : この警告が返された回数。 +- `FIRST_SEEN` : このエラー (または警告) が最初に送信されたとき。 +- `LAST_SEEN` : このエラー (または警告) が最後に送信された時刻。 以下の例は、ローカルTiDBサーバーへの接続時に生成される警告を示しています。`FLUSH CLIENT_ERRORS_SUMMARY`を実行するとサマリーがリセットされます。 diff --git a/information-schema/information-schema-analyze-status.md b/information-schema/information-schema-analyze-status.md index 172f1492b1917..abc9cf62450f1 100644 --- a/information-schema/information-schema-analyze-status.md +++ b/information-schema/information-schema-analyze-status.md @@ -59,22 +59,22 @@ SELECT * FROM information_schema.analyze_status; `ANALYZE_STATUS`テーブルのフィールドは、次のように説明されます。 -- `TABLE_SCHEMA` : テーブルが属するデータベースの名前。 -- `TABLE_NAME` : テーブルの名前。 -- `PARTITION_NAME` :パーティションテーブルの名前。 -- `JOB_INFO` : `ANALYZE`タスクの情報。インデックスが分析される場合、この情報にはインデックス名が含まれます。 `tidb_analyze_version = 2`の場合、この情報にはサンプルレートなどの構成項目が含まれます。 -- `PROCESSED_ROWS` : 処理された行数。 -- `START_TIME` : `ANALYZE`タスクの開始時刻。 -- `END_TIME` : `ANALYZE`タスクの終了時刻。 -- `STATE` : `ANALYZE`タスクの実行ステータス。値は`pending` 、 `running` 、 `finished`または`failed` 。 -- `FAIL_REASON` : タスクが失敗した理由。実行が成功した場合は、値は`NULL`になります。 -- `INSTANCE` : タスクを実行する TiDB インスタンス。 -- `PROCESS_ID` : タスクを実行するプロセスID。 -- `REMAINING_SECONDS` : タスクが完了するまでの推定残り時間（秒）。 -- `PROGRESS` : タスクの進捗状況。 -- `ESTIMATED_TOTAL_ROWS` : タスクによって分析する必要のある行の総数。 +- `TABLE_SCHEMA` : テーブルが属するデータベースの名前。 +- `TABLE_NAME` : テーブルの名前。 +- `PARTITION_NAME` :パーティションテーブルの名前。 +- `JOB_INFO` : `ANALYZE`タスクの情報。インデックスが分析される場合、この情報にはインデックス名が含まれます。 `tidb_analyze_version = 2`の場合、この情報にはサンプルレートなどの構成項目が含まれます。 +- `PROCESSED_ROWS` : 処理された行数。 +- `START_TIME` : `ANALYZE`タスクの開始時刻。 +- `END_TIME` : `ANALYZE`タスクの終了時刻。 +- `STATE` : `ANALYZE`タスクの実行ステータス。値は`pending` 、 `running` 、 `finished`または`failed` 。 +- `FAIL_REASON` : タスクが失敗した理由。実行が成功した場合は、値は`NULL`になります。 +- `INSTANCE` : タスクを実行する TiDB インスタンス。 +- `PROCESS_ID` : タスクを実行するプロセスID。 +- `REMAINING_SECONDS` : タスクが完了するまでの推定残り時間（秒）。 +- `PROGRESS` : タスクの進捗状況。 +- `ESTIMATED_TOTAL_ROWS` : タスクによって分析する必要のある行の総数。 ## 関連項目 {#see-also} -- [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md) -- [`SHOW ANALYZE STATUS`](/sql-statements/sql-statement-show-analyze-status.md) +- [`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md) +- [`SHOW ANALYZE STATUS`](/sql-statements/sql-statement-show-analyze-status.md) diff --git a/information-schema/information-schema-character-sets.md b/information-schema/information-schema-character-sets.md index d4744043ef9f5..76ba2b73db92b 100644 --- a/information-schema/information-schema-character-sets.md +++ b/information-schema/information-schema-character-sets.md @@ -50,14 +50,14 @@ SELECT * FROM `CHARACTER_SETS`; `CHARACTER_SETS`表の列の説明は次のとおりです。 -- `CHARACTER_SET_NAME` : 文字セットの名前。 -- `DEFAULT_COLLATE_NAME`文字セットのデフォルトの照合順序名。 -- `DESCRIPTION`文字セットの説明。 -- `MAXLEN`この文字セットに文字を格納するために必要な最大長。 +- `CHARACTER_SET_NAME` : 文字セットの名前。 +- `DEFAULT_COLLATE_NAME`文字セットのデフォルトの照合順序名。 +- `DESCRIPTION`文字セットの説明。 +- `MAXLEN`この文字セットに文字を格納するために必要な最大長。 ## 参照 {#see-also} -- [`SHOW CHARACTER SET`](/sql-statements/sql-statement-show-character-set.md) -- [`SHOW COLLATION`](/sql-statements/sql-statement-show-collation.md) -- [`INFORMATION_SCHEMA.COLLATIONS`](/information-schema/information-schema-collations.md) -- [`INFORMATION_SCHEMA.COLLATION_CHARACTER_SET_APPLICABILITY`](/information-schema/information-schema-collation-character-set-applicability.md) +- [`SHOW CHARACTER SET`](/sql-statements/sql-statement-show-character-set.md) +- [`SHOW COLLATION`](/sql-statements/sql-statement-show-collation.md) +- [`INFORMATION_SCHEMA.COLLATIONS`](/information-schema/information-schema-collations.md) +- [`INFORMATION_SCHEMA.COLLATION_CHARACTER_SET_APPLICABILITY`](/information-schema/information-schema-collation-character-set-applicability.md) diff --git a/information-schema/information-schema-check-constraints.md b/information-schema/information-schema-check-constraints.md index d82907d0b3c48..1677d537b7744 100644 --- a/information-schema/information-schema-check-constraints.md +++ b/information-schema/information-schema-check-constraints.md @@ -47,7 +47,7 @@ CONSTRAINT_CATALOG: def `CHECK_CONSTRAINTS`テーブル内のフィールドは次のように説明されます。 -- `CONSTRAINT_CATALOG` : 制約のカタログ。常に`def`です。 -- `CONSTRAINT_SCHEMA` : 制約のスキーマ。 -- `CONSTRAINT_NAME` : 制約の名前。 -- `CHECK_CLAUSE` : チェック制約の句。 +- `CONSTRAINT_CATALOG` : 制約のカタログ。常に`def`です。 +- `CONSTRAINT_SCHEMA` : 制約のスキーマ。 +- `CONSTRAINT_NAME` : 制約の名前。 +- `CHECK_CLAUSE` : チェック制約の句。 diff --git a/information-schema/information-schema-cluster-config.md b/information-schema/information-schema-cluster-config.md index 2f28ec5fa246d..159991b442f98 100644 --- a/information-schema/information-schema-cluster-config.md +++ b/information-schema/information-schema-cluster-config.md @@ -29,10 +29,10 @@ DESC cluster_config; フィールドの説明: -- `TYPE` : インスタンスタイプ。オプションの値は`tidb` 、 `pd` 、 `tikv`です。 -- `INSTANCE` : インスタンスのサービス アドレス。 -- `KEY` : 構成項目名。 -- `VALUE` : 構成項目の値。 +- `TYPE` : インスタンスタイプ。オプションの値は`tidb` 、 `pd` 、 `tikv`です。 +- `INSTANCE` : インスタンスのサービス アドレス。 +- `KEY` : 構成項目名。 +- `VALUE` : 構成項目の値。 次の例は、 `CLUSTER_CONFIG`テーブルを使用して TiKV インスタンスの`coprocessor`構成をクエリする方法を示しています。 diff --git a/information-schema/information-schema-cluster-hardware.md b/information-schema/information-schema-cluster-hardware.md index 0c85457eb8fd5..45361884897fe 100644 --- a/information-schema/information-schema-cluster-hardware.md +++ b/information-schema/information-schema-cluster-hardware.md @@ -32,16 +32,16 @@ DESC cluster_hardware; フィールドの説明: -- `TYPE` : 表[`information_schema.cluster_info`](/information-schema/information-schema-cluster-info.md)のフィールド`TYPE`に対応します。オプションの値は`tidb` 、 `pd` 、 `tikv`です。 -- `INSTANCE` : [`information_schema.cluster_info`](/information-schema/information-schema-cluster-info.md)クラスター情報テーブルの`INSTANCE`フィールドに対応します。 -- `DEVICE_TYPE` : ハードウェアタイプ。現在、 `cpu` 、 `memory` 、 `disk` 、 `net`タイプを照会できます。 -- `DEVICE_NAME` : ハードウェア名`DEVICE_NAME`の値は`DEVICE_TYPE`に応じて変化します。 - - `cpu` : ハードウェア名は cpu です。 - - `memory` : ハードウェア名はメモリです。 - - `disk` : ディスク名。 - - `net` : ネットワーク カード名。 -- `NAME` : ハードウェアの異なる情報名。例えば、CPUには`cpu-logical-cores`と`cpu-physical-cores`という2つの情報名があり、それぞれ論理コア番号と物理コア番号を意味します。 -- `VALUE` : ディスクボリュームや CPU コア数などの対応するハードウェア情報の値。 +- `TYPE` : 表[`information_schema.cluster_info`](/information-schema/information-schema-cluster-info.md)のフィールド`TYPE`に対応します。オプションの値は`tidb` 、 `pd` 、 `tikv`です。 +- `INSTANCE` : [`information_schema.cluster_info`](/information-schema/information-schema-cluster-info.md)クラスター情報テーブルの`INSTANCE`フィールドに対応します。 +- `DEVICE_TYPE` : ハードウェアタイプ。現在、 `cpu` 、 `memory` 、 `disk` 、 `net`タイプを照会できます。 +- `DEVICE_NAME` : ハードウェア名`DEVICE_NAME`の値は`DEVICE_TYPE`に応じて変化します。 + - `cpu` : ハードウェア名は cpu です。 + - `memory` : ハードウェア名はメモリです。 + - `disk` : ディスク名。 + - `net` : ネットワーク カード名。 +- `NAME` : ハードウェアの異なる情報名。例えば、CPUには`cpu-logical-cores`と`cpu-physical-cores`という2つの情報名があり、それぞれ論理コア番号と物理コア番号を意味します。 +- `VALUE` : ディスクボリュームや CPU コア数などの対応するハードウェア情報の値。 次の例は、 `CLUSTER_HARDWARE`テーブルを使用して CPU 情報を照会する方法を示しています。 diff --git a/information-schema/information-schema-cluster-info.md b/information-schema/information-schema-cluster-info.md index c74792817e686..728bc36b21bf7 100644 --- a/information-schema/information-schema-cluster-info.md +++ b/information-schema/information-schema-cluster-info.md @@ -34,14 +34,14 @@ desc cluster_info; フィールドの説明： -- `TYPE` : インスタンスタイプ。オプションの値は`tidb` 、 `pd` 、および`tikv`です。 -- `INSTANCE` : インスタンスアドレス。これは`IP:PORT`の形式の文字列です。 -- `STATUS_ADDRESS` : HTTP API のサービス アドレス。tikv-ctl、pd-ctl、または tidb-ctl の一部のコマンドでは、この API とこのアドレスが使用される場合があります。このアドレスからクラスタに関する詳細情報を取得することもできます。詳細は[TiDB HTTP APIドキュメント](https://github.com/pingcap/tidb/blob/release-8.5/docs/tidb_http_api.md)を参照してください。 -- `VERSION` : 対応するインスタンスのセマンティックバージョン番号。MySQL のバージョン番号との互換性を保つため、TiDB のバージョンは`${mysql-version}-${tidb-version}`の形式で表示されます。 -- `GIT_HASH` : インスタンス バージョンをコンパイルする際の Git コミット ハッシュ。これは、2 つのインスタンスが完全に一貫したバージョンであるかどうかを識別するために使用されます。 -- `START_TIME` : 対応するインスタンスの開始時刻。 -- `UPTIME` : 対応するインスタンスの稼働時間。 -- `SERVER_ID` : 対応するインスタンスのサーバーID。 +- `TYPE` : インスタンスタイプ。オプションの値は`tidb` 、 `pd` 、および`tikv`です。 +- `INSTANCE` : インスタンスアドレス。これは`IP:PORT`の形式の文字列です。 +- `STATUS_ADDRESS` : HTTP API のサービス アドレス。tikv-ctl、pd-ctl、または tidb-ctl の一部のコマンドでは、この API とこのアドレスが使用される場合があります。このアドレスからクラスタに関する詳細情報を取得することもできます。詳細は[TiDB HTTP APIドキュメント](https://github.com/pingcap/tidb/blob/release-8.5/docs/tidb_http_api.md)を参照してください。 +- `VERSION` : 対応するインスタンスのセマンティックバージョン番号。MySQL のバージョン番号との互換性を保つため、TiDB のバージョンは`${mysql-version}-${tidb-version}`の形式で表示されます。 +- `GIT_HASH` : インスタンス バージョンをコンパイルする際の Git コミット ハッシュ。これは、2 つのインスタンスが完全に一貫したバージョンであるかどうかを識別するために使用されます。 +- `START_TIME` : 対応するインスタンスの開始時刻。 +- `UPTIME` : 対応するインスタンスの稼働時間。 +- `SERVER_ID` : 対応するインスタンスのサーバーID。 ```sql SELECT * FROM cluster_info; diff --git a/information-schema/information-schema-cluster-load.md b/information-schema/information-schema-cluster-load.md index f8047688af19b..ba9caee79e515 100644 --- a/information-schema/information-schema-cluster-load.md +++ b/information-schema/information-schema-cluster-load.md @@ -32,16 +32,16 @@ DESC cluster_load; フィールドの説明: -- `TYPE` : 表[`information_schema.cluster_info`](/information-schema/information-schema-cluster-info.md)のフィールド`TYPE`に対応します。オプションの値は`tidb` 、 `pd` 、 `tikv`です。 -- `INSTANCE` : [`information_schema.cluster_info`](/information-schema/information-schema-cluster-info.md)クラスター情報テーブルの`INSTANCE`フィールドに対応します。 -- `DEVICE_TYPE` : ハードウェアタイプ。現在、 `cpu` 、 `memory` 、 `disk` 、 `net`タイプを照会できます。 -- `DEVICE_NAME` : ハードウェア名`DEVICE_NAME`の値は`DEVICE_TYPE`に応じて変化します。 - - `cpu` : ハードウェア名は cpu です。 - - `disk` : ディスク名。 - - `net` : ネットワーク カード名。 - - `memory` : ハードウェア名はメモリです。 -- `NAME` : 異なる負荷タイプ。例えば、CPU `load15`は`load1` `load5` 3つの負荷タイプがあり、それぞれ1分、5分、15分以内のCPUの平均負荷を意味します。 -- `VALUE` : ハードウェア負荷の値。例えば、 `1min` 、 `5min` 、 `15min`それぞれ、1分、5分、15分以内のハードウェアの平均負荷を意味します。 +- `TYPE` : 表[`information_schema.cluster_info`](/information-schema/information-schema-cluster-info.md)のフィールド`TYPE`に対応します。オプションの値は`tidb` 、 `pd` 、 `tikv`です。 +- `INSTANCE` : [`information_schema.cluster_info`](/information-schema/information-schema-cluster-info.md)クラスター情報テーブルの`INSTANCE`フィールドに対応します。 +- `DEVICE_TYPE` : ハードウェアタイプ。現在、 `cpu` 、 `memory` 、 `disk` 、 `net`タイプを照会できます。 +- `DEVICE_NAME` : ハードウェア名`DEVICE_NAME`の値は`DEVICE_TYPE`に応じて変化します。 + - `cpu` : ハードウェア名は cpu です。 + - `disk` : ディスク名。 + - `net` : ネットワーク カード名。 + - `memory` : ハードウェア名はメモリです。 +- `NAME` : 異なる負荷タイプ。例えば、CPU `load15`は`load1` `load5` 3つの負荷タイプがあり、それぞれ1分、5分、15分以内のCPUの平均負荷を意味します。 +- `VALUE` : ハードウェア負荷の値。例えば、 `1min` 、 `5min` 、 `15min`それぞれ、1分、5分、15分以内のハードウェアの平均負荷を意味します。 次の例は、 `CLUSTER_LOAD`テーブルを使用して CPU の現在の負荷情報を照会する方法を示しています。 diff --git a/information-schema/information-schema-cluster-log.md b/information-schema/information-schema-cluster-log.md index 40549e451473e..581c8711af3b2 100644 --- a/information-schema/information-schema-cluster-log.md +++ b/information-schema/information-schema-cluster-log.md @@ -33,17 +33,17 @@ DESC cluster_log; フィールドの説明: -- `TIME` : ログを印刷する時間。 -- `TYPE` : インスタンスタイプ。オプションの値は`tidb` 、 `pd` 、 `tikv`です。 -- `INSTANCE` : インスタンスのサービス アドレス。 -- `LEVEL` : ログレベル。 -- `MESSAGE` : ログの内容。 +- `TIME` : ログを印刷する時間。 +- `TYPE` : インスタンスタイプ。オプションの値は`tidb` 、 `pd` 、 `tikv`です。 +- `INSTANCE` : インスタンスのサービス アドレス。 +- `LEVEL` : ログレベル。 +- `MESSAGE` : ログの内容。 > **Note:** > -> - クラスターログテーブルのすべてのフィールドは、対応するインスタンスにプッシュダウンされて実行されます。クラスターログテーブルの使用に伴うオーバーヘッドを削減するには、検索に使用するキーワード、時間範囲、そして可能な限り多くの条件を指定する必要があります。例えば、 `select * from cluster_log where message like '%ddl%' and time > '2020-05-18 20:40:00' and time<'2020-05-18 21:40:00' and type='tidb'`に指定します。 +> - クラスターログテーブルのすべてのフィールドは、対応するインスタンスにプッシュダウンされて実行されます。クラスターログテーブルの使用に伴うオーバーヘッドを削減するには、検索に使用するキーワード、時間範囲、そして可能な限り多くの条件を指定する必要があります。例えば、 `select * from cluster_log where message like '%ddl%' and time > '2020-05-18 20:40:00' and time<'2020-05-18 21:40:00' and type='tidb'`に指定します。 > -> - `message`フィールドは`like`と`regexp`正規表現をサポートしており、対応するパターンは`regexp`としてエンコードされます。複数の`message`条件を指定すると、 `grep`コマンドの`pipeline`形式と同じになります。例えば、 `select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*' and time > '2020-05-18 20:40:00' and time<'2020-05-18 21:40:00'`ステートメントを実行すると、すべてのクラスターインスタンスで`grep 'coprocessor' xxx.log | grep -E '.*slow.*'`を実行するのと同じになります。 +> - `message`フィールドは`like`と`regexp`正規表現をサポートしており、対応するパターンは`regexp`としてエンコードされます。複数の`message`条件を指定すると、 `grep`コマンドの`pipeline`形式と同じになります。例えば、 `select * from cluster_log where message like 'coprocessor%' and message regexp '.*slow.*' and time > '2020-05-18 20:40:00' and time<'2020-05-18 21:40:00'`ステートメントを実行すると、すべてのクラスターインスタンスで`grep 'coprocessor' xxx.log | grep -E '.*slow.*'`を実行するのと同じになります。 次の例は、 `CLUSTER_LOG`テーブルを使用して DDL ステートメントの実行プロセスをクエリする方法を示しています。 @@ -66,6 +66,6 @@ SELECT time,instance,left(message,150) FROM cluster_log WHERE message LIKE '%ddl 上記のクエリ結果は、DDL ステートメントを実行するプロセスを示しています。 -1. DDL JOB ID が`80`のリクエストが`127.0.0.1:4002` TiDB インスタンスに送信されます。 -2. `127.0.0.1:4000` TiDB インスタンスがこの DDL 要求を処理します。これは、 `127.0.0.1:4000`のインスタンスがその時点で DDL 所有者であることを示します。 -3. DDL JOB ID が`80`のリクエストが処理されました。 +1. DDL JOB ID が`80`のリクエストが`127.0.0.1:4002` TiDB インスタンスに送信されます。 +2. `127.0.0.1:4000` TiDB インスタンスがこの DDL 要求を処理します。これは、 `127.0.0.1:4000`のインスタンスがその時点で DDL 所有者であることを示します。 +3. DDL JOB ID が`80`のリクエストが処理されました。 diff --git a/information-schema/information-schema-cluster-systeminfo.md b/information-schema/information-schema-cluster-systeminfo.md index 022bde44e2929..093e718bbe26f 100644 --- a/information-schema/information-schema-cluster-systeminfo.md +++ b/information-schema/information-schema-cluster-systeminfo.md @@ -32,12 +32,12 @@ DESC cluster_systeminfo; フィールドの説明: -- `TYPE` : 表[`information_schema.cluster_info`](/information-schema/information-schema-cluster-info.md)のフィールド`TYPE`に対応します。オプションの値は`tidb` 、 `pd` 、 `tikv`です。 -- `INSTANCE` : [`information_schema.cluster_info`](/information-schema/information-schema-cluster-info.md)クラスター情報テーブルの`INSTANCE`フィールドに対応します。 -- `SYSTEM_TYPE` : システムタイプ。現在、 `system`システムタイプを照会できます。 -- `SYSTEM_NAME` : システム名。現在、 `sysctl`システム名を照会できます。 -- `NAME` : `sysctl`に対応する構成名。 -- `VALUE` : `sysctl`に対応する構成項目の値。 +- `TYPE` : 表[`information_schema.cluster_info`](/information-schema/information-schema-cluster-info.md)のフィールド`TYPE`に対応します。オプションの値は`tidb` 、 `pd` 、 `tikv`です。 +- `INSTANCE` : [`information_schema.cluster_info`](/information-schema/information-schema-cluster-info.md)クラスター情報テーブルの`INSTANCE`フィールドに対応します。 +- `SYSTEM_TYPE` : システムタイプ。現在、 `system`システムタイプを照会できます。 +- `SYSTEM_NAME` : システム名。現在、 `sysctl`システム名を照会できます。 +- `NAME` : `sysctl`に対応する構成名。 +- `VALUE` : `sysctl`に対応する構成項目の値。 次の例は、 `CLUSTER_SYSTEMINFO`システム情報テーブルを使用して、クラスター内のすべてのサーバーのカーネル バージョンを照会する方法を示しています。 diff --git a/information-schema/information-schema-collation-character-set-applicability.md b/information-schema/information-schema-collation-character-set-applicability.md index 4335e1a288811..28270542e2b2f 100644 --- a/information-schema/information-schema-collation-character-set-applicability.md +++ b/information-schema/information-schema-collation-character-set-applicability.md @@ -45,12 +45,12 @@ SELECT * FROM COLLATION_CHARACTER_SET_APPLICABILITY WHERE character_set_name='ut `COLLATION_CHARACTER_SET_APPLICABILITY`表の列の説明は次のとおりです。 -- `COLLATION_NAME` :照合順序の名前。 -- `CHARACTER_SET_NAME` :照合順序が属する文字セットの名前。 +- `COLLATION_NAME` :照合順序の名前。 +- `CHARACTER_SET_NAME` :照合順序が属する文字セットの名前。 ## 参照 {#see-also} -- [`SHOW CHARACTER SET`](/sql-statements/sql-statement-show-character-set.md) -- [`SHOW COLLATION`](/sql-statements/sql-statement-show-collation.md) -- [`INFORMATION_SCHEMA.CHARACTER_SETS`](/information-schema/information-schema-character-sets.md) -- [`INFORMATION_SCHEMA.COLLATIONS`](/information-schema/information-schema-collations.md) +- [`SHOW CHARACTER SET`](/sql-statements/sql-statement-show-character-set.md) +- [`SHOW COLLATION`](/sql-statements/sql-statement-show-collation.md) +- [`INFORMATION_SCHEMA.CHARACTER_SETS`](/information-schema/information-schema-character-sets.md) +- [`INFORMATION_SCHEMA.COLLATIONS`](/information-schema/information-schema-collations.md) diff --git a/information-schema/information-schema-collations.md b/information-schema/information-schema-collations.md index 05748988d56a4..8628b05f25c4d 100644 --- a/information-schema/information-schema-collations.md +++ b/information-schema/information-schema-collations.md @@ -46,17 +46,17 @@ SELECT * FROM collations WHERE character_set_name='utf8mb4'; `COLLATIONS`表の列の説明は次のとおりです。 -- `COLLATION_NAME` :照合順序の名前。 -- `CHARACTER_SET_NAME` :照合順序が属する文字セットの名前。 -- `ID` :照合順序の ID。 -- `IS_DEFAULT` : この照合順序が、それが属する文字セットのデフォルトの照合順序であるかどうか。 -- `IS_COMPILED` : 文字セットがサーバーにコンパイルされているかどうか。 -- `SORTLEN` :照合順序が文字をソートするときに割り当てられるメモリの最小長。 -- `PAD_ATTRIBUTE` : 文字列の比較中に末尾のスペースを無視するかどうか。`PAD SPACE`は末尾のスペースが無視されることを意味し (たとえば、 `'abc'` `'abc '`と等しい)、 `NO PAD`は末尾のスペースが重要であることを意味します (たとえば、 `'abc'` `'abc '`等しくありません)。 +- `COLLATION_NAME` :照合順序の名前。 +- `CHARACTER_SET_NAME` :照合順序が属する文字セットの名前。 +- `ID` :照合順序の ID。 +- `IS_DEFAULT` : この照合順序が、それが属する文字セットのデフォルトの照合順序であるかどうか。 +- `IS_COMPILED` : 文字セットがサーバーにコンパイルされているかどうか。 +- `SORTLEN` :照合順序が文字をソートするときに割り当てられるメモリの最小長。 +- `PAD_ATTRIBUTE` : 文字列の比較中に末尾のスペースを無視するかどうか。`PAD SPACE`は末尾のスペースが無視されることを意味し (たとえば、 `'abc'` `'abc '`と等しい)、 `NO PAD`は末尾のスペースが重要であることを意味します (たとえば、 `'abc'` `'abc '`等しくありません)。 ## 参照 {#see-also} -- [`SHOW CHARACTER SET`](/sql-statements/sql-statement-show-character-set.md) -- [`SHOW COLLATION`](/sql-statements/sql-statement-show-collation.md) -- [`INFORMATION_SCHEMA.CHARACTER_SETS`](/information-schema/information-schema-character-sets.md) -- [`INFORMATION_SCHEMA.COLLATION_CHARACTER_SET_APPLICABILITY`](/information-schema/information-schema-collation-character-set-applicability.md) +- [`SHOW CHARACTER SET`](/sql-statements/sql-statement-show-character-set.md) +- [`SHOW COLLATION`](/sql-statements/sql-statement-show-collation.md) +- [`INFORMATION_SCHEMA.CHARACTER_SETS`](/information-schema/information-schema-character-sets.md) +- [`INFORMATION_SCHEMA.COLLATION_CHARACTER_SET_APPLICABILITY`](/information-schema/information-schema-collation-character-set-applicability.md) diff --git a/information-schema/information-schema-columns.md b/information-schema/information-schema-columns.md index 756ac93962c17..db00f285331ba 100644 --- a/information-schema/information-schema-columns.md +++ b/information-schema/information-schema-columns.md @@ -80,31 +80,31 @@ CHARACTER_MAXIMUM_LENGTH: NULL `COLUMNS`表の列の説明は次のとおりです。 -- `TABLE_CATALOG` : 列を含むテーブルが属するカタログの名前。値は常に`def` 。 -- `TABLE_SCHEMA` : 列を含むテーブルが配置されているスキーマの名前。 -- `TABLE_NAME` : 列を含むテーブルの名前。 -- `COLUMN_NAME` : 列の名前。 -- `ORDINAL_POSITION` : テーブル内の列の位置。 -- `COLUMN_DEFAULT` : 列のデフォルト値。明示的なデフォルト値が`NULL`の場合、または列定義に`default`句が含まれていない場合、この値は`NULL`なります。 -- `IS_NULLABLE` : 列がNULL値可能かどうか。列がNULL値を格納できる場合、この値は`YES` 、そうでない場合は`NO`なります。 -- `DATA_TYPE` : 列内のデータのタイプ。 -- `CHARACTER_MAXIMUM_LENGTH` : 文字列列の場合、文字の最大長。 -- `CHARACTER_OCTET_LENGTH` : 文字列列の場合、最大長（バイト単位）。 -- `NUMERIC_PRECISION` : 数値型列の数値精度。 -- `NUMERIC_SCALE` : 数値型列の数値スケール。 -- `DATETIME_PRECISION` : 時刻型列の場合、秒の小数部の精度。 -- `CHARACTER_SET_NAME` : 文字列列の文字セットの名前。 -- `COLLATION_NAME` : 文字列列の照合順序の名前。 -- `COLUMN_TYPE` : 列のタイプ。 -- `COLUMN_KEY` : この列がインデックスされているかどうか。このフィールドには次の値が含まれます。 - - 空: この列にはインデックスが付いていません。または、この列にはインデックスが付いていて、複数列の一意でないインデックスの 2 番目の列です。 - - `PRI` : この列は主キーまたは複数の主キーの 1 つです。 - - `UNI` : この列は、一意インデックスの最初の列です。 - - `MUL` : 列は、特定の値が複数回出現することを許可される、一意でないインデックスの最初の列です。 -- `EXTRA` : 指定された列の追加情報。 -- `PRIVILEGES` : 現在のユーザーがこの列に対して持つ権限。現在、この値はTiDBで固定されており、常に`select,insert,update,references`です。 -- `COLUMN_COMMENT` : 列定義に含まれるコメント。 -- `GENERATION_EXPRESSION` : 生成列の場合、この値は列の値を計算するために使用された式を表示します。非生成列の場合、この値は空です。 +- `TABLE_CATALOG` : 列を含むテーブルが属するカタログの名前。値は常に`def` 。 +- `TABLE_SCHEMA` : 列を含むテーブルが配置されているスキーマの名前。 +- `TABLE_NAME` : 列を含むテーブルの名前。 +- `COLUMN_NAME` : 列の名前。 +- `ORDINAL_POSITION` : テーブル内の列の位置。 +- `COLUMN_DEFAULT` : 列のデフォルト値。明示的なデフォルト値が`NULL`の場合、または列定義に`default`句が含まれていない場合、この値は`NULL`なります。 +- `IS_NULLABLE` : 列がNULL値可能かどうか。列がNULL値を格納できる場合、この値は`YES` 、そうでない場合は`NO`なります。 +- `DATA_TYPE` : 列内のデータのタイプ。 +- `CHARACTER_MAXIMUM_LENGTH` : 文字列列の場合、文字の最大長。 +- `CHARACTER_OCTET_LENGTH` : 文字列列の場合、最大長（バイト単位）。 +- `NUMERIC_PRECISION` : 数値型列の数値精度。 +- `NUMERIC_SCALE` : 数値型列の数値スケール。 +- `DATETIME_PRECISION` : 時刻型列の場合、秒の小数部の精度。 +- `CHARACTER_SET_NAME` : 文字列列の文字セットの名前。 +- `COLLATION_NAME` : 文字列列の照合順序の名前。 +- `COLUMN_TYPE` : 列のタイプ。 +- `COLUMN_KEY` : この列がインデックスされているかどうか。このフィールドには次の値が含まれます。 + - 空: この列にはインデックスが付いていません。または、この列にはインデックスが付いていて、複数列の一意でないインデックスの 2 番目の列です。 + - `PRI` : この列は主キーまたは複数の主キーの 1 つです。 + - `UNI` : この列は、一意インデックスの最初の列です。 + - `MUL` : 列は、特定の値が複数回出現することを許可される、一意でないインデックスの最初の列です。 +- `EXTRA` : 指定された列の追加情報。 +- `PRIVILEGES` : 現在のユーザーがこの列に対して持つ権限。現在、この値はTiDBで固定されており、常に`select,insert,update,references`です。 +- `COLUMN_COMMENT` : 列定義に含まれるコメント。 +- `GENERATION_EXPRESSION` : 生成列の場合、この値は列の値を計算するために使用された式を表示します。非生成列の場合、この値は空です。 対応する`SHOW`ステートメントは次のとおりです。 @@ -125,4 +125,4 @@ SHOW COLUMNS FROM t1 FROM test; ## 参照 {#see-also} -- [`SHOW COLUMNS FROM`](/sql-statements/sql-statement-show-columns-from.md) +- [`SHOW COLUMNS FROM`](/sql-statements/sql-statement-show-columns-from.md) diff --git a/information-schema/information-schema-data-lock-waits.md b/information-schema/information-schema-data-lock-waits.md index 69dba2e57001d..fed6c606dca70 100644 --- a/information-schema/information-schema-data-lock-waits.md +++ b/information-schema/information-schema-data-lock-waits.md @@ -27,39 +27,39 @@ DESC data_lock_waits; `DATA_LOCK_WAITS`テーブル内の各列フィールドの意味は次のとおりです。 -- `KEY` : ロックを待機しているキー（16 進形式）。 -- `KEY_INFO` : `KEY`の詳細情報。[キー情報](#key_info)セクションを参照してください。 -- `TRX_ID` : ロックを待機しているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 -- `CURRENT_HOLDING_TRX_ID` : 現在ロックを保持しているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 -- `SQL_DIGEST` : ロック待機中のトランザクションで現在ブロックされている SQL ステートメントのダイジェスト。 -- `SQL_DIGEST_TEXT` : ロック待機中のトランザクションで現在ブロックされている正規化されたSQL文（引数とフォーマットのないSQL文）。これは`SQL_DIGEST`に相当します。 +- `KEY` : ロックを待機しているキー（16 進形式）。 +- `KEY_INFO` : `KEY`の詳細情報。[キー情報](#key_info)セクションを参照してください。 +- `TRX_ID` : ロックを待機しているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 +- `CURRENT_HOLDING_TRX_ID` : 現在ロックを保持しているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 +- `SQL_DIGEST` : ロック待機中のトランザクションで現在ブロックされている SQL ステートメントのダイジェスト。 +- `SQL_DIGEST_TEXT` : ロック待機中のトランザクションで現在ブロックされている正規化されたSQL文（引数とフォーマットのないSQL文）。これは`SQL_DIGEST`に相当します。 > **Warning:** > -> - [PROCESS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_process)権限を持つユーザーのみがこのテーブルをクエリできます。 -> - 現在、楽観的トランザクションの場合、フィールド`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)を参照してください。 +> - [PROCESS](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_process)権限を持つユーザーのみがこのテーブルをクエリできます。 +> - 現在、楽観的トランザクションの場合、フィールド`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)を参照してください。 ## `KEY_INFO` {#key_info} `KEY_INFO`列は`KEY`列の詳細情報です。情報はJSON形式で表示されます。各フィールドの説明は以下の通りです。 -- `"db_id"` : キーが属するスキーマの ID。 -- `"db_name"` : キーが属するスキーマの名前。 -- `"table_id"` : キーが属するテーブルの ID。 -- `"table_name"` : キーが属するテーブルの名前。 -- `"partition_id"` : キーが配置されているパーティションの ID。 -- `"partition_name"` : キーが配置されているパーティションの名前。 -- `"handle_type"` : 行キー（つまり、データ行を格納するキー）のハンドルタイプ。可能な値は次のとおりです。 - - `"int"` : ハンドル タイプは int です。つまり、ハンドルは行 ID です。 - - `"common"` : ハンドルの型が int64 ではありません。クラスター化インデックスが有効な場合、この型は非 int 型の主キーに表示されます。 - - `"unknown"` : ハンドル タイプは現在サポートされていません。 -- `"handle_value"` : ハンドル値。 -- `"index_id"` : インデックスキー（インデックスを格納するキー）が属するインデックス ID。 -- `"index_name"` : インデックス キーが属するインデックスの名前。 -- `"index_values"` : インデックス キー内のインデックス値。 +- `"db_id"` : キーが属するスキーマの ID。 +- `"db_name"` : キーが属するスキーマの名前。 +- `"table_id"` : キーが属するテーブルの ID。 +- `"table_name"` : キーが属するテーブルの名前。 +- `"partition_id"` : キーが配置されているパーティションの ID。 +- `"partition_name"` : キーが配置されているパーティションの名前。 +- `"handle_type"` : 行キー（つまり、データ行を格納するキー）のハンドルタイプ。可能な値は次のとおりです。 + - `"int"` : ハンドル タイプは int です。つまり、ハンドルは行 ID です。 + - `"common"` : ハンドルの型が int64 ではありません。クラスター化インデックスが有効な場合、この型は非 int 型の主キーに表示されます。 + - `"unknown"` : ハンドル タイプは現在サポートされていません。 +- `"handle_value"` : ハンドル値。 +- `"index_id"` : インデックスキー（インデックスを格納するキー）が属するインデックス ID。 +- `"index_name"` : インデックス キーが属するインデックスの名前。 +- `"index_values"` : インデックス キー内のインデックス値。 上記のフィールドのうち、該当しない、または現在利用できない場合、そのフィールドはクエリ結果から省略されます。例えば、行キー情報には`index_id` 、 `index_name` 、 `index_values`は含まれません。インデックスキーには`handle_type`と`handle_value`は含まれません。非パーティションテーブルでは`partition_id`と`partition_name`は表示されません。削除されたテーブルのキー情報では`table_name` 、 `db_id` 、 `db_name` 、 `index_name`などのスキーマ情報を取得できず、テーブルがパーティションテーブルであるかどうかを区別できません。 @@ -90,12 +90,12 @@ CURRENT_HOLDING_TRX_ID: 426790590082449409 -- [ロックの競合のトラブルシューティング](/troubleshoot-lock-conflicts.md) +- [ロックの競合のトラブルシューティング](/troubleshoot-lock-conflicts.md) -- [トランザクションエラーの処理](/develop/dev-guide-transaction-troubleshoot.md) +- [トランザクションエラーの処理](/develop/dev-guide-transaction-troubleshoot.md) diff --git a/information-schema/information-schema-deadlocks.md b/information-schema/information-schema-deadlocks.md index 27ffcb2fff214..e8f1ab43fd32d 100644 --- a/information-schema/information-schema-deadlocks.md +++ b/information-schema/information-schema-deadlocks.md @@ -34,15 +34,15 @@ DESC deadlocks; `DEADLOCKS`テーブル内の各列フィールドの意味は次のとおりです。 -- `DEADLOCK_ID` : デッドロックイベントのID。テーブル内に複数のデッドロックエラーが存在する場合、この列を使用して、異なるデッドロックエラーに属する行を区別できます。 -- `OCCUR_TIME` : デッドロック エラーが発生した時刻。 -- `RETRYABLE` : デッドロックエラーを再試行できるかどうか。再試行可能なデッドロックエラーの説明については、セクション[再試行可能なデッドロックエラー](#retryable-deadlock-errors)を参照してください。 -- `TRY_LOCK_TRX_ID` : ロックを取得しようとするトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 -- `CURRENT_SQL_DIGEST` : ロックを取得するトランザクションで現在実行されている SQL ステートメントのダイジェスト。 -- `CURRENT_SQL_DIGEST_TEXT` : ロックを取得するトランザクションで現在実行されている SQL ステートメントの正規化された形式。 -- `KEY` : トランザクションがロックしようとしたブロックされたキー。このフィールドの値は16進文字列で表示されます。 -- `KEY_INFO` : `KEY`の詳細情報。[`KEY_INFO`](#key_info)セクションを参照してください。 -- `TRX_HOLDING_LOCK` : 現在キーのロックを保持し、ブロックを引き起こしているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 +- `DEADLOCK_ID` : デッドロックイベントのID。テーブル内に複数のデッドロックエラーが存在する場合、この列を使用して、異なるデッドロックエラーに属する行を区別できます。 +- `OCCUR_TIME` : デッドロック エラーが発生した時刻。 +- `RETRYABLE` : デッドロックエラーを再試行できるかどうか。再試行可能なデッドロックエラーの説明については、セクション[再試行可能なデッドロックエラー](#retryable-deadlock-errors)を参照してください。 +- `TRY_LOCK_TRX_ID` : ロックを取得しようとするトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 +- `CURRENT_SQL_DIGEST` : ロックを取得するトランザクションで現在実行されている SQL ステートメントのダイジェスト。 +- `CURRENT_SQL_DIGEST_TEXT` : ロックを取得するトランザクションで現在実行されている SQL ステートメントの正規化された形式。 +- `KEY` : トランザクションがロックしようとしたブロックされたキー。このフィールドの値は16進文字列で表示されます。 +- `KEY_INFO` : `KEY`の詳細情報。[`KEY_INFO`](#key_info)セクションを参照してください。 +- `TRX_HOLDING_LOCK` : 現在キーのロックを保持し、ブロックを引き起こしているトランザクションのID。このIDはトランザクションの`start_ts`でもあります。 @@ -58,27 +58,27 @@ DESC deadlocks; > **Warning:** > -> - [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)を参照してください。 +> - [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)を参照してください。 ## `KEY_INFO` {#key_info} `KEY_INFO`列は`KEY`列の詳細情報です。情報はJSON形式で表示されます。各フィールドの説明は以下の通りです。 -- `"db_id"` : キーが属するスキーマの ID。 -- `"db_name"` : キーが属するスキーマの名前。 -- `"table_id"` : キーが属するテーブルの ID。 -- `"table_name"` : キーが属するテーブルの名前。 -- `"partition_id"` : キーが配置されているパーティションの ID。 -- `"partition_name"` : キーが配置されているパーティションの名前。 -- `"handle_type"` : 行キー（つまり、データ行を格納するキー）のハンドルタイプ。可能な値は次のとおりです。 - - `"int"` : ハンドル タイプは int です。つまり、ハンドルは行 ID です。 - - `"common"` : ハンドルの型が int64 ではありません。クラスター化インデックスが有効な場合、この型は非 int 型の主キーに表示されます。 - - `"unknown"` : ハンドル タイプは現在サポートされていません。 -- `"handle_value"` : ハンドル値。 -- `"index_id"` : インデックスキー（インデックスを格納するキー）が属するインデックス ID。 -- `"index_name"` : インデックス キーが属するインデックスの名前。 -- `"index_values"` : インデックス キー内のインデックス値。 +- `"db_id"` : キーが属するスキーマの ID。 +- `"db_name"` : キーが属するスキーマの名前。 +- `"table_id"` : キーが属するテーブルの ID。 +- `"table_name"` : キーが属するテーブルの名前。 +- `"partition_id"` : キーが配置されているパーティションの ID。 +- `"partition_name"` : キーが配置されているパーティションの名前。 +- `"handle_type"` : 行キー（つまり、データ行を格納するキー）のハンドルタイプ。可能な値は次のとおりです。 + - `"int"` : ハンドル タイプは int です。つまり、ハンドルは行 ID です。 + - `"common"` : ハンドルの型が int64 ではありません。クラスター化インデックスが有効な場合、この型は非 int 型の主キーに表示されます。 + - `"unknown"` : ハンドル タイプは現在サポートされていません。 +- `"handle_value"` : ハンドル値。 +- `"index_id"` : インデックスキー（インデックスを格納するキー）が属するインデックス ID。 +- `"index_name"` : インデックス キーが属するインデックスの名前。 +- `"index_values"` : インデックス キー内のインデックス値。 上記のフィールドのうち、該当しない、または現在利用できない場合、そのフィールドはクエリ結果から省略されます。例えば、行キー情報には`index_id` 、 `index_name` 、 `index_values`は含まれません。インデックスキーには`handle_type`と`handle_value`は含まれません。非パーティションテーブルでは`partition_id`と`partition_name`は表示されません。削除されたテーブルのキー情報では`table_name` 、 `db_id` 、 `db_name` 、 `index_name`などのスキーマ情報を取得できず、テーブルがパーティションテーブルであるかどうかを区別できません。 @@ -106,8 +106,8 @@ DESC deadlocks; トランザクションAがトランザクションBによって既に保持されているロックによってブロックされ、トランザクションBが現在のトランザクションAによって保持されているロックによって直接的または間接的にブロックされている場合、デッドロックエラーが発生します。このデッドロックには、以下の2つのケースが考えられます。 -- ケース 1:トランザクションB は、トランザクション A の開始後、トランザクション A がブロックされる前に実行されたステートメントによって生成されたロックによって (直接的または間接的に) ブロックされる可能性があります。 -- ケース 2:トランザクションB も、トランザクション A で現在実行中のステートメントによってブロックされる可能性があります。 +- ケース 1:トランザクションB は、トランザクション A の開始後、トランザクション A がブロックされる前に実行されたステートメントによって生成されたロックによって (直接的または間接的に) ブロックされる可能性があります。 +- ケース 2:トランザクションB も、トランザクション A で現在実行中のステートメントによってブロックされる可能性があります。 ケース 1 では、TiDB はトランザクション A のクライアントにデッドロック エラーを報告し、トランザクションを終了します。 @@ -126,10 +126,10 @@ UPDATE t SET v = 2 WHERE id = 1; 次に、トランザクション A が`id = 1`と`id = 2`で 2 つの行をロックし、 2 つのトランザクションが次の順序で実行されるとします。 -1. トランザクションA は行を`id = 1`でロックします。 -2. トランザクションB は最初のステートメントを実行し、行を`id = 2`でロックします。 -3. トランザクションB は 2 番目のステートメントを実行し、 `id = 1`で行をロックしようとしますが、これはトランザクション A によってブロックされます。 -4. トランザクションA は`id = 2`で行をロックしようとしますが、トランザクション B によってブロックされ、デッドロックが発生します。 +1. トランザクションA は行を`id = 1`でロックします。 +2. トランザクションB は最初のステートメントを実行し、行を`id = 2`でロックします。 +3. トランザクションB は 2 番目のステートメントを実行し、 `id = 1`で行をロックしようとしますが、これはトランザクション A によってブロックされます。 +4. トランザクションA は`id = 2`で行をロックしようとしますが、トランザクション B によってブロックされ、デッドロックが発生します。 この場合、他のトランザクションをブロックしているトランザクションAのステートメントが、現在実行中のステートメントでもあるため、現在のステートメントに対する悲観的ロックを解消し（トランザクションBの実行を継続できるように）、現在のステートメントを再試行できます。TiDBは、内部的にキーハッシュを使用して、これが当てはまるかどうかを判断します。 diff --git a/information-schema/information-schema-engines.md b/information-schema/information-schema-engines.md index 05df7cdbca2cd..1f79198b97075 100644 --- a/information-schema/information-schema-engines.md +++ b/information-schema/information-schema-engines.md @@ -41,13 +41,13 @@ SELECT * FROM engines; `ENGINES`表の列の説明は次のとおりです。 -- `ENGINES` :ストレージエンジンの名前。 -- `SUPPORT` :サーバーがストレージエンジンに対して持つサポートレベル。TiDBでは、この値は常に`DEFAULT`です。 -- `COMMENT` :ストレージエンジンに関する簡単なコメント。 -- `TRANSACTIONS` :ストレージエンジンがトランザクションをサポートするかどうか。 -- `XA` :ストレージエンジンが XA トランザクションをサポートするかどうか。 -- `SAVEPOINTS` :ストレージエンジンが`savepoints`サポートするかどうか。 +- `ENGINES` :ストレージエンジンの名前。 +- `SUPPORT` :サーバーがストレージエンジンに対して持つサポートレベル。TiDBでは、この値は常に`DEFAULT`です。 +- `COMMENT` :ストレージエンジンに関する簡単なコメント。 +- `TRANSACTIONS` :ストレージエンジンがトランザクションをサポートするかどうか。 +- `XA` :ストレージエンジンが XA トランザクションをサポートするかどうか。 +- `SAVEPOINTS` :ストレージエンジンが`savepoints`サポートするかどうか。 ## 参照 {#see-also} -- [`SHOW ENGINES`](/sql-statements/sql-statement-show-engines.md) +- [`SHOW ENGINES`](/sql-statements/sql-statement-show-engines.md) diff --git a/information-schema/information-schema-inspection-result.md b/information-schema/information-schema-inspection-result.md index 9787696c88db8..52934218a3beb 100644 --- a/information-schema/information-schema-inspection-result.md +++ b/information-schema/information-schema-inspection-result.md @@ -39,20 +39,20 @@ DESC inspection_result; フィールドの説明: -- `RULE` : 診断ルールの名前。現在、以下のルールが利用可能です。 - - `config` : 構成が一貫していて適切かどうかを確認します。異なるインスタンス間で同じ構成が不一致の場合、診断結果`warning`が生成されます。 - - `version` : バージョンの整合性チェック。異なるインスタンス間で同じバージョンが一致しない場合は、診断結果`warning`が生成されます。 - - `node-load` :サーバーの負荷をチェックします。現在のシステム負荷が高すぎる場合は、対応する`warning`診断結果が生成されます。 - - `critical-error` ：システムの各モジュールは重大なエラーを定義します。重大なエラーが対応する時間内にしきい値を超えた場合、警告診断結果が生成されます。 - - `threshold-check` ：診断システムは主要な指標のしきい値をチェックします。しきい値を超えた場合、対応する診断情報が生成されます。 -- `ITEM` : 各ルールは異なる項目を診断します。このフィールドは、各ルールに対応する具体的な診断項目を示します。 -- `TYPE` : 診断のインスタンスタイプ。オプションの値は`tidb` 、 `pd` 、 `tikv`です。 -- `INSTANCE` : 診断されたインスタンスの特定のアドレス。 -- `STATUS_ADDRESS` : インスタンスの HTTP API サービス アドレス。 -- `VALUE` : 特定の診断項目の値。 -- `REFERENCE` ：この診断項目の基準値（閾値）。`VALUE`が閾値を超えると、対応する診断情報が生成されます。 -- `SEVERITY` : 重大度レベル。オプションの値は`warning`と`critical`です。 -- `DETAILS` : 診断の詳細。追加の診断のための SQL ステートメントまたはドキュメント リンクも含まれる場合があります。 +- `RULE` : 診断ルールの名前。現在、以下のルールが利用可能です。 + - `config` : 構成が一貫していて適切かどうかを確認します。異なるインスタンス間で同じ構成が不一致の場合、診断結果`warning`が生成されます。 + - `version` : バージョンの整合性チェック。異なるインスタンス間で同じバージョンが一致しない場合は、診断結果`warning`が生成されます。 + - `node-load` :サーバーの負荷をチェックします。現在のシステム負荷が高すぎる場合は、対応する`warning`診断結果が生成されます。 + - `critical-error` ：システムの各モジュールは重大なエラーを定義します。重大なエラーが対応する時間内にしきい値を超えた場合、警告診断結果が生成されます。 + - `threshold-check` ：診断システムは主要な指標のしきい値をチェックします。しきい値を超えた場合、対応する診断情報が生成されます。 +- `ITEM` : 各ルールは異なる項目を診断します。このフィールドは、各ルールに対応する具体的な診断項目を示します。 +- `TYPE` : 診断のインスタンスタイプ。オプションの値は`tidb` 、 `pd` 、 `tikv`です。 +- `INSTANCE` : 診断されたインスタンスの特定のアドレス。 +- `STATUS_ADDRESS` : インスタンスの HTTP API サービス アドレス。 +- `VALUE` : 特定の診断項目の値。 +- `REFERENCE` ：この診断項目の基準値（閾値）。`VALUE`が閾値を超えると、対応する診断情報が生成されます。 +- `SEVERITY` : 重大度レベル。オプションの値は`warning`と`critical`です。 +- `DETAILS` : 診断の詳細。追加の診断のための SQL ステートメントまたはドキュメント リンクも含まれる場合があります。 ## 診断例 {#diagnostics-example} @@ -103,9 +103,9 @@ DETAILS | max duration of 172.16.5.40:20151 tikv rocksdb-write-duration was to 上記の診断結果から、次の問題が検出されます。 -- 最初の行は、TiDB の`log.slow-threshold`値が`0`に設定されており、パフォーマンスに影響する可能性があることを示しています。 -- 2 行目は、クラスター内に 2 つの異なる TiDB バージョンが存在することを示します。 -- 3行目と4行目は、TiKVの書き込み遅延が長すぎることを示しています。予想される遅延は0.1秒以内ですが、実際の遅延は予想よりもはるかに長くなっています。 +- 最初の行は、TiDB の`log.slow-threshold`値が`0`に設定されており、パフォーマンスに影響する可能性があることを示しています。 +- 2 行目は、クラスター内に 2 つの異なる TiDB バージョンが存在することを示します。 +- 3行目と4行目は、TiKVの書き込み遅延が長すぎることを示しています。予想される遅延は0.1秒以内ですが、実際の遅延は予想よりもはるかに長くなっています。 「2020-03-26 00:03:00」から「2020-03-26 00:08:00」までなど、指定した範囲内にある問題を診断することもできます。時間範囲を指定するには、SQLヒントに`/*+ time_range() */`を指定します。次のクエリ例をご覧ください。 @@ -136,8 +136,8 @@ DETAILS | max duration of 172.16.5.40:10089 tidb get-token-duration is too slo 上記の診断結果から、次の問題が検出されます。 -- 最初の行は、 `172.16.5.40:4009` TiDB インスタンスが`2020/03/26 00:05:45.670`で再起動されることを示しています。 -- 2 行目は、 `172.16.5.40:10089` TiDB インスタンスの最大`get-token-duration`時間は 0.234 秒ですが、予想時間は 0.001 秒未満であることを示しています。 +- 最初の行は、 `172.16.5.40:4009` TiDB インスタンスが`2020/03/26 00:05:45.670`で再起動されることを示しています。 +- 2 行目は、 `172.16.5.40:10089` TiDB インスタンスの最大`get-token-duration`時間は 0.234 秒ですが、予想時間は 0.001 秒未満であることを示しています。 条件を指定して、たとえばレベル`critical`の診断結果を照会することもできます。 @@ -177,7 +177,7 @@ select * from information_schema.inspection_rules where type='inspection'; `config`診断ルールでは、 `CLUSTER_CONFIG`のシステム テーブルをクエリすることによって、次の 2 つの診断ルールが実行されます。 -- 同じコンポーネントの設定値が一貫しているかどうかを確認します。すべての設定項目でこの整合性チェックが実行されるわけではありません。整合性チェックの許可リストは次のとおりです。 +- 同じコンポーネントの設定値が一貫しているかどうかを確認します。すべての設定項目でこの整合性チェックが実行されるわけではありません。整合性チェックの許可リストは次のとおりです。 ```go // The allowlist of the TiDB configuration consistency check @@ -212,7 +212,7 @@ select * from information_schema.inspection_rules where type='inspection'; storage.block-cache.capacity ``` -- 以下の構成項目の値が期待どおりであるかどうかを確認します。 +- 以下の構成項目の値が期待どおりであるかどうかを確認します。 | コンポーネント | コンフィグレーション項目 | 期待値 | | ---- | ------------------ | -------- | @@ -242,7 +242,7 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo `critical-error`診断ルールでは、次の 2 つの診断ルールが実行されます。 -- メトリック スキーマ内の関連する監視システム テーブルをクエリして、クラスターに次のエラーがあるかどうかを検出します。 +- メトリック スキーマ内の関連する監視システム テーブルをクエリして、クラスターに次のエラーがあるかどうかを検出します。 | コンポーネント | エラー名 | 監視テーブル | エラーの説明 | | ---- | ----------------------- | ---------------------------------- | -------------------------------------------- | @@ -253,7 +253,7 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo | TiKV | チャネルがいっぱいです | tikv_チャンネルの合計数 | TiKV で「チャネルがいっぱいです」というエラーが発生します。 | | TiKV | tikv_engine_write_stall | tikv_engine_write_stall | TiKV で「ストール」エラーが発生します。 | -- `metrics_schema.up`監視テーブルと`CLUSTER_LOG`システム テーブルを照会して、コンポーネントが再起動されているかどうかを確認します。 +- `metrics_schema.up`監視テーブルと`CLUSTER_LOG`システム テーブルを照会して、コンポーネントが再起動されているかどうかを確認します。 ### `threshold-check`診断ルール {#threshold-check-diagnostic-rule} @@ -283,16 +283,16 @@ DETAILS | the cluster has 2 different tidb versions, execute the sql to see mo さらに、このルールは、TiKV インスタンス内の次のスレッドの CPU 使用率が高すぎるかどうかもチェックします。 -- スケジューラワーカーCPU -- コプロセッサ-通常のCPU -- コプロセッサ-高CPU -- コプロセッサ-低CPU -- grpc-cpu -- ラフトストアCPU -- CPU適用 -- ストレージ読み取りプール - 通常 - CPU -- ストレージ読み取りプールの高CPU -- ストレージ読み取りプールの低CPU -- スプリットチェックCPU +- スケジューラワーカーCPU +- コプロセッサ-通常のCPU +- コプロセッサ-高CPU +- コプロセッサ-低CPU +- grpc-cpu +- ラフトストアCPU +- CPU適用 +- ストレージ読み取りプール - 通常 - CPU +- ストレージ読み取りプールの高CPU +- ストレージ読み取りプールの低CPU +- スプリットチェックCPU 組み込みの診断ルールは常に改善されています。さらに診断ルールをお持ちの場合は、 [`tidb`リポジトリ](https://github.com/pingcap/tidb)に PR または Issue を作成してください。 diff --git a/information-schema/information-schema-inspection-summary.md b/information-schema/information-schema-inspection-summary.md index efed0e59069d2..445d410e63689 100644 --- a/information-schema/information-schema-inspection-summary.md +++ b/information-schema/information-schema-inspection-summary.md @@ -37,11 +37,11 @@ DESC inspection_summary; フィールドの説明: -- `RULE` : 要約ルール。新しいルールは継続的に追加されるため、 `select * from inspection_rules where type='summary'`ステートメントを実行すると最新のルールリストを照会できます。 -- `INSTANCE` : 監視対象インスタンス。 -- `METRICS_NAME` : 監視メトリック名。 -- `QUANTILE` : `QUANTILE`を含む監視テーブルに有効です。述語をプッシュダウンすることで、複数のパーセンタイルを指定できます。例えば、 `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)`を実行してDDL関連の監視メトリックを要約し、P80/P90/P99/P999の結果を照会できます。`AVG_VALUE` 、 `MIN_VALUE` 、 `MAX_VALUE`は、それぞれ集計の平均値、最小値、最大値を示します。 -- `COMMENT` : 対応する監視メトリックに関するコメント。 +- `RULE` : 要約ルール。新しいルールは継続的に追加されるため、 `select * from inspection_rules where type='summary'`ステートメントを実行すると最新のルールリストを照会できます。 +- `INSTANCE` : 監視対象インスタンス。 +- `METRICS_NAME` : 監視メトリック名。 +- `QUANTILE` : `QUANTILE`を含む監視テーブルに有効です。述語をプッシュダウンすることで、複数のパーセンタイルを指定できます。例えば、 `select * from inspection_summary where rule='ddl' and quantile in (0.80, 0.90, 0.99, 0.999)`を実行してDDL関連の監視メトリックを要約し、P80/P90/P99/P999の結果を照会できます。`AVG_VALUE` 、 `MIN_VALUE` 、 `MAX_VALUE`は、それぞれ集計の平均値、最小値、最大値を示します。 +- `COMMENT` : 対応する監視メトリックに関するコメント。 > **Note:** > @@ -53,8 +53,8 @@ DESC inspection_summary; 次の例では、2 つの期間における読み取りリンクの監視メトリックを比較します。 -- `(2020-01-16 16:00:54.933, 2020-01-16 16:10:54.933)` -- `(2020-01-16 16:10:54.933, 2020-01-16 16:20:54.933)` +- `(2020-01-16 16:00:54.933, 2020-01-16 16:10:54.933)` +- `(2020-01-16 16:10:54.933, 2020-01-16 16:20:54.933)` ```sql SELECT diff --git a/information-schema/information-schema-key-column-usage.md b/information-schema/information-schema-key-column-usage.md index 3e1df35cc3483..fa99dfcdef8ee 100644 --- a/information-schema/information-schema-key-column-usage.md +++ b/information-schema/information-schema-key-column-usage.md @@ -68,15 +68,15 @@ POSITION_IN_UNIQUE_CONSTRAINT: NULL `KEY_COLUMN_USAGE`表の列の説明は次のとおりです。 -- `CONSTRAINT_CATALOG` : 制約が属するカタログの名前。値は常に`def` 。 -- `CONSTRAINT_SCHEMA` : 制約が属するスキーマの名前。 -- `CONSTRAINT_NAME` : 制約の名前。 -- `TABLE_CATALOG` : テーブルが属するカタログの名前。値は常に`def` 。 -- `TABLE_SCHEMA` : テーブルが属するスキーマの名前。 -- `TABLE_NAME` : 制約のあるテーブルの名前。 -- `COLUMN_NAME` : 制約のある列の名前。 -- `ORDINAL_POSITION` : テーブル内ではなく、制約内の列の位置。位置番号は`1`から始まります。 -- `POSITION_IN_UNIQUE_CONSTRAINT` : 一意制約と主キー制約は空です。外部キー制約の場合、この列は参照先テーブルのキーの位置となります。 -- `REFERENCED_TABLE_SCHEMA` : 制約によって参照されるスキーマの名前。現在、TiDBでは、外部キー制約を除くすべての制約において、この列の値は`nil`です。 -- `REFERENCED_TABLE_NAME` : 制約によって参照されるテーブルの名前。現在、TiDBでは、外部キー制約を除くすべての制約において、この列の値は`nil`です。 -- `REFERENCED_COLUMN_NAME` : 制約によって参照される列の名前。現在、TiDBでは、外部キー制約を除くすべての制約において、この列の値は`nil`です。 +- `CONSTRAINT_CATALOG` : 制約が属するカタログの名前。値は常に`def` 。 +- `CONSTRAINT_SCHEMA` : 制約が属するスキーマの名前。 +- `CONSTRAINT_NAME` : 制約の名前。 +- `TABLE_CATALOG` : テーブルが属するカタログの名前。値は常に`def` 。 +- `TABLE_SCHEMA` : テーブルが属するスキーマの名前。 +- `TABLE_NAME` : 制約のあるテーブルの名前。 +- `COLUMN_NAME` : 制約のある列の名前。 +- `ORDINAL_POSITION` : テーブル内ではなく、制約内の列の位置。位置番号は`1`から始まります。 +- `POSITION_IN_UNIQUE_CONSTRAINT` : 一意制約と主キー制約は空です。外部キー制約の場合、この列は参照先テーブルのキーの位置となります。 +- `REFERENCED_TABLE_SCHEMA` : 制約によって参照されるスキーマの名前。現在、TiDBでは、外部キー制約を除くすべての制約において、この列の値は`nil`です。 +- `REFERENCED_TABLE_NAME` : 制約によって参照されるテーブルの名前。現在、TiDBでは、外部キー制約を除くすべての制約において、この列の値は`nil`です。 +- `REFERENCED_COLUMN_NAME` : 制約によって参照される列の名前。現在、TiDBでは、外部キー制約を除くすべての制約において、この列の値は`nil`です。 diff --git a/information-schema/information-schema-keywords.md b/information-schema/information-schema-keywords.md index 9f39c1b834322..4bdbe4b9a251c 100644 --- a/information-schema/information-schema-keywords.md +++ b/information-schema/information-schema-keywords.md @@ -26,8 +26,8 @@ DESC keywords; フィールドの説明: -- `WORD` : キーワード。 -- `RESERVED` : キーワードが予約されているかどうか。 +- `WORD` : キーワード。 +- `RESERVED` : キーワードが予約されているかどうか。 次のステートメントは、キーワード`ADD`と`USER`に関する情報を照会します。 diff --git a/information-schema/information-schema-memory-usage-ops-history.md b/information-schema/information-schema-memory-usage-ops-history.md index 8d2f1523ce861..822e689acb0b5 100644 --- a/information-schema/information-schema-memory-usage-ops-history.md +++ b/information-schema/information-schema-memory-usage-ops-history.md @@ -47,15 +47,15 @@ SELECT * FROM information_schema.memory_usage_ops_history; `MEMORY_USAGE_OPS_HISTORY`テーブル内の列は次のように説明されます。 -- `TIME` : セッションが終了したときのタイムスタンプ。 -- `OPS` ：「セッションキル」 -- `MEMORY_LIMIT` : TiDB終了時のメモリ使用量制限（バイト単位）。この値はシステム変数`tidb_server_memory_limit`の値と同じです。[/system-variables.md#tidb_server_memory_limit-new-in-v640]。 -- `MEMORY_CURRENT` : TiDB の現在のメモリ使用量 (バイト単位)。 -- `PROCESSID` : 終了したセッションの接続 ID。 -- `MEM` : 終了したセッションのメモリ使用量（バイト単位）。 -- `DISK` : 終了したセッションのディスク使用量（バイト単位）。 -- `CLIENT` : 終了したセッションのクライアント接続アドレス。 -- `DB` : 終了したセッションに接続されていたデータベースの名前。 -- `USER` : 終了したセッションのユーザー名。 -- `SQL_DIGEST` : 終了したセッションで実行されている SQL ステートメントのダイジェスト。 -- `SQL_TEXT` : 終了したセッションで実行されている SQL ステートメント。 +- `TIME` : セッションが終了したときのタイムスタンプ。 +- `OPS` ：「セッションキル」 +- `MEMORY_LIMIT` : TiDB終了時のメモリ使用量制限（バイト単位）。この値はシステム変数`tidb_server_memory_limit`の値と同じです。[/system-variables.md#tidb_server_memory_limit-new-in-v640]。 +- `MEMORY_CURRENT` : TiDB の現在のメモリ使用量 (バイト単位)。 +- `PROCESSID` : 終了したセッションの接続 ID。 +- `MEM` : 終了したセッションのメモリ使用量（バイト単位）。 +- `DISK` : 終了したセッションのディスク使用量（バイト単位）。 +- `CLIENT` : 終了したセッションのクライアント接続アドレス。 +- `DB` : 終了したセッションに接続されていたデータベースの名前。 +- `USER` : 終了したセッションのユーザー名。 +- `SQL_DIGEST` : 終了したセッションで実行されている SQL ステートメントのダイジェスト。 +- `SQL_TEXT` : 終了したセッションで実行されている SQL ステートメント。 diff --git a/information-schema/information-schema-memory-usage.md b/information-schema/information-schema-memory-usage.md index 39bd490a4d43b..c2e67d3ad59ea 100644 --- a/information-schema/information-schema-memory-usage.md +++ b/information-schema/information-schema-memory-usage.md @@ -46,30 +46,30 @@ SELECT * FROM information_schema.memory_usage; `MEMORY_USAGE`テーブル内の列は次のように説明されます。 -- MEMORY_TOTAL: TiDB の使用可能なメモリの合計 (バイト単位)。 -- MEMORY_LIMIT: TiDBのメモリ使用量の制限（バイト単位）。この値はシステム変数[`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)の値と同じです。 -- MEMORY_CURRENT: TiDB の現在のメモリ使用量 (バイト単位)。 -- MEMORY_MAX_USED: TiDB の起動時から現在までのメモリ使用量 (バイト単位)。 -- CURRENT_OPS: "shrinking" | null。"shrinking" は、TiDB がメモリ使用量を削減する操作を実行していることを意味します。 -- SESSION_KILL_LAST: セッションが最後に終了した時刻のタイムスタンプ。 -- SESSION_KILL_TOTAL: TiDB の開始時から現在までに終了したセッションの回数。 -- GC_LAST:メモリ使用量によってGolang GC が最後にトリガーされたときのタイムスタンプ。 -- GC_TOTAL: TiDB の開始時から現在までの、メモリ使用量によってGolang GC がトリガーされた回数。 -- DISK_USAGE: 現在のデータスピル操作のディスク使用量（バイト単位）。 -- QUERY_FORCE_DISK: TiDB が開始されてから現在までにデータがディスクに書き出された回数。 +- MEMORY_TOTAL: TiDB の使用可能なメモリの合計 (バイト単位)。 +- MEMORY_LIMIT: TiDBのメモリ使用量の制限（バイト単位）。この値はシステム変数[`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)の値と同じです。 +- MEMORY_CURRENT: TiDB の現在のメモリ使用量 (バイト単位)。 +- MEMORY_MAX_USED: TiDB の起動時から現在までのメモリ使用量 (バイト単位)。 +- CURRENT_OPS: "shrinking" | null。"shrinking" は、TiDB がメモリ使用量を削減する操作を実行していることを意味します。 +- SESSION_KILL_LAST: セッションが最後に終了した時刻のタイムスタンプ。 +- SESSION_KILL_TOTAL: TiDB の開始時から現在までに終了したセッションの回数。 +- GC_LAST:メモリ使用量によってGolang GC が最後にトリガーされたときのタイムスタンプ。 +- GC_TOTAL: TiDB の開始時から現在までの、メモリ使用量によってGolang GC がトリガーされた回数。 +- DISK_USAGE: 現在のデータスピル操作のディスク使用量（バイト単位）。 +- QUERY_FORCE_DISK: TiDB が開始されてから現在までにデータがディスクに書き出された回数。 ## 参照 {#see-also} -- [TiDBメモリ制御](/configure-memory-usage.md) -- [TiKVメモリパラメータのパフォーマンスを調整する](/tune-tikv-memory-performance.md) +- [TiDBメモリ制御](/configure-memory-usage.md) +- [TiKVメモリパラメータのパフォーマンスを調整する](/tune-tikv-memory-performance.md) -- [TiDBメモリ制御](https://docs.pingcap.com/tidb/stable/configure-memory-usage) -- [TiKVメモリパラメータのパフォーマンスを調整する](https://docs.pingcap.com/tidb/stable/tune-tikv-memory-performance) +- [TiDBメモリ制御](https://docs.pingcap.com/tidb/stable/configure-memory-usage) +- [TiKVメモリパラメータのパフォーマンスを調整する](https://docs.pingcap.com/tidb/stable/tune-tikv-memory-performance) diff --git a/information-schema/information-schema-metrics-summary.md b/information-schema/information-schema-metrics-summary.md index 8d68d1a8df7c0..9bd70048c4657 100644 --- a/information-schema/information-schema-metrics-summary.md +++ b/information-schema/information-schema-metrics-summary.md @@ -7,8 +7,8 @@ summary: METRICS_SUMMARY システム テーブルについて学習します。 TiDB クラスタには多くの監視メトリックがあります。異常な監視メトリックを容易に検出できるように、TiDB 4.0 では次の 2 つの監視サマリーテーブルが導入されています。 -- `information_schema.metrics_summary` -- `information_schema.metrics_summary_by_label` +- `information_schema.metrics_summary` +- `information_schema.metrics_summary_by_label` > **Note:** > @@ -38,12 +38,12 @@ DESC metrics_summary; フィールドの説明: -- `METRICS_NAME` : 監視テーブル名。 -- `QUANTILE` : パーセンタイル。SQL文を使用して`QUANTILE`を指定することもできます。例: - - `select * from metrics_summary where quantile=0.99` 0.99 パーセンタイルのデータを表示することを指定します。 - - `select * from metrics_summary where quantile in (0.80, 0.90, 0.99, 0.999)` 、0.8、0.90、0.99、0.999 パーセンタイルのデータを同時に表示することを指定します。 -- `SUM_VALUE` 、 `AVG_VALUE` 、 `MIN_VALUE` 、 `MAX_VALUE`それぞれ合計、平均値、最小値、最大値を意味します。 -- `COMMENT` : 対応する監視テーブルのコメント。 +- `METRICS_NAME` : 監視テーブル名。 +- `QUANTILE` : パーセンタイル。SQL文を使用して`QUANTILE`を指定することもできます。例: + - `select * from metrics_summary where quantile=0.99` 0.99 パーセンタイルのデータを表示することを指定します。 + - `select * from metrics_summary where quantile in (0.80, 0.90, 0.99, 0.999)` 、0.8、0.90、0.99、0.999 パーセンタイルのデータを同時に表示することを指定します。 +- `SUM_VALUE` 、 `AVG_VALUE` 、 `MIN_VALUE` 、 `MAX_VALUE`それぞれ合計、平均値、最小値、最大値を意味します。 +- `COMMENT` : 対応する監視テーブルのコメント。 例えば： @@ -135,8 +135,8 @@ COMMENT | The quantile of TiDB query durations(second) 上記の例に加えて、監視サマリーテーブルを使用して、2つの期間のフルリンク監視項目を比較することで、監視データから最も大きな変化があったモジュールを迅速に特定し、ボトルネックを迅速に特定できます。次の例では、2つの期間（t1がベースライン）のすべての監視項目を比較し、これらの項目を差異の大きい順に並べ替えています。 -- 期間t1: `("2020-03-03 17:08:00", "2020-03-03 17:11:00")` -- 期間t2: `("2020-03-03 17:18:00", "2020-03-03 17:21:00")` +- 期間t1: `("2020-03-03 17:08:00", "2020-03-03 17:11:00")` +- 期間t2: `("2020-03-03 17:18:00", "2020-03-03 17:21:00")` 2 つの期間の監視項目は`METRICS_NAME`に従って結合され、差異値に従ってソートされます。`TIME_RANGE`はクエリ時間を指定するヒントです。 @@ -176,10 +176,10 @@ ORDER BY ratio DESC LIMIT 10; 上記のクエリ結果から、次の情報を取得できます。 -- 期間 t2 の`tib_slow_query_cop_process_total_time` (TiDB のスロークエリでの時間消費量`cop process` ) は、期間 t1 の 5,865 倍になります。 -- 期間t2における`tidb_distsql_partial_scan_key_total_num` （TiDBの`distsql`が要求するスキャンキー数）は、期間t1の3,648倍です。期間t2における`tidb_slow_query_cop_wait_total_time` （コプロセッサーがTiDBのスロークエリのキューイングを要求する際の待機時間）は、期間t1の267倍です。 -- 期間 t2 の`tikv_cop_total_response_size` (TiKVコプロセッサー要求結果のサイズ) は、期間 t1 の 192 倍になります。 -- 期間 t2 (TiKVコプロセッサーによって要求されたスキャン) の`tikv_cop_scan_details`は、期間 t1 の 105 倍になります。 +- 期間 t2 の`tib_slow_query_cop_process_total_time` (TiDB のスロークエリでの時間消費量`cop process` ) は、期間 t1 の 5,865 倍になります。 +- 期間t2における`tidb_distsql_partial_scan_key_total_num` （TiDBの`distsql`が要求するスキャンキー数）は、期間t1の3,648倍です。期間t2における`tidb_slow_query_cop_wait_total_time` （コプロセッサーがTiDBのスロークエリのキューイングを要求する際の待機時間）は、期間t1の267倍です。 +- 期間 t2 の`tikv_cop_total_response_size` (TiKVコプロセッサー要求結果のサイズ) は、期間 t1 の 192 倍になります。 +- 期間 t2 (TiKVコプロセッサーによって要求されたスキャン) の`tikv_cop_scan_details`は、期間 t1 の 105 倍になります。 上記の結果から、期間t2のコプロセッサーリクエストが期間t1よりもはるかに多いことがわかります。これによりTiKVコプロセッサーが過負荷になり、 `cop task`待機状態になります。期間t2に大規模なクエリが発生し、負荷がさらに増加している可能性があります。 diff --git a/information-schema/information-schema-metrics-tables.md b/information-schema/information-schema-metrics-tables.md index 2e5ba7f77a7e4..822e70894d7d5 100644 --- a/information-schema/information-schema-metrics-tables.md +++ b/information-schema/information-schema-metrics-tables.md @@ -32,11 +32,11 @@ DESC METRICS_TABLES; フィールドの説明: -- `TABLE_NAME` : `METRICS_SCHEMA`のテーブル名に対応します。 -- `PROMQL` : 監視テーブルの動作原理は、SQL文を`PromQL`にマッピングし、Prometheusの結果をSQLクエリ結果に変換することです。このフィールドは`PromQL`の式テンプレートです。監視テーブルのデータをクエリすると、クエリ条件を使用してこのテンプレート内の変数が書き換えられ、最終的なクエリ式が生成されます。 -- `LABELS` : 監視項目のラベル。各ラベルは監視テーブル内の列に対応しています。SQL文に対応する列のフィルターが含まれている場合、対応する`PromQL`それに応じて変化します。 -- `QUANTILE` : パーセンタイル。ヒストグラム型の監視データの場合、デフォルトのパーセンタイルが指定されます。このフィールドの値が`0`の場合、監視テーブルに対応する監視項目はヒストグラムではないことを意味します。 -- `COMMENT` : 監視テーブルに関するコメント。 +- `TABLE_NAME` : `METRICS_SCHEMA`のテーブル名に対応します。 +- `PROMQL` : 監視テーブルの動作原理は、SQL文を`PromQL`にマッピングし、Prometheusの結果をSQLクエリ結果に変換することです。このフィールドは`PromQL`の式テンプレートです。監視テーブルのデータをクエリすると、クエリ条件を使用してこのテンプレート内の変数が書き換えられ、最終的なクエリ式が生成されます。 +- `LABELS` : 監視項目のラベル。各ラベルは監視テーブル内の列に対応しています。SQL文に対応する列のフィルターが含まれている場合、対応する`PromQL`それに応じて変化します。 +- `QUANTILE` : パーセンタイル。ヒストグラム型の監視データの場合、デフォルトのパーセンタイルが指定されます。このフィールドの値が`0`の場合、監視テーブルに対応する監視項目はヒストグラムではないことを意味します。 +- `COMMENT` : 監視テーブルに関するコメント。 ```sql SELECT * FROM metrics_tables LIMIT 5\G diff --git a/information-schema/information-schema-partitions.md b/information-schema/information-schema-partitions.md index bf750dbeb4138..0307dafdc346f 100644 --- a/information-schema/information-schema-partitions.md +++ b/information-schema/information-schema-partitions.md @@ -121,4 +121,4 @@ SUBPARTITION_ORDINAL_POSITION: NULL ## 参照 {#see-also} -- [パーティションを使用してステートメントを説明する](/explain-partitions.md) +- [パーティションを使用してステートメントを説明する](/explain-partitions.md) diff --git a/information-schema/information-schema-processlist.md b/information-schema/information-schema-processlist.md index 757140943e016..f84872c0fe03a 100644 --- a/information-schema/information-schema-processlist.md +++ b/information-schema/information-schema-processlist.md @@ -11,29 +11,29 @@ summary: PROCESSLIST` information_schema テーブルについて学習します -- SQL ステートメントのダイジェストを表示する`DIGEST`列。 -- 処理中のリクエストによって使用されているメモリをバイト単位で表示する`MEM`列。 -- ディスク使用量をバイト単位で表示する`DISK`列。 -- トランザクションの開始時刻を表示する`TxnStart`列。 -- リソース グループ名を表示する`RESOURCE_GROUP`列。 -- 現在のセッションのエイリアスを表示する`SESSION_ALIAS`列。 -- ステートメントによって現在影響を受けている行数を示す`ROWS_AFFECTED`列。 -- `TIDB_CPU`列は、ステートメントがTiDBサーバーのCPUを消費した時間をナノ秒単位で示します。この列は、 [Top SQL](/dashboard/top-sql.md)機能が有効な場合にのみ意味のある値を表示します。それ以外の場合は、値は`0`になります。 -- ステートメントが TiKVサーバーCPU を消費する時間をナノ秒単位で表示する`TIKV_CPU`列。 +- SQL ステートメントのダイジェストを表示する`DIGEST`列。 +- 処理中のリクエストによって使用されているメモリをバイト単位で表示する`MEM`列。 +- ディスク使用量をバイト単位で表示する`DISK`列。 +- トランザクションの開始時刻を表示する`TxnStart`列。 +- リソース グループ名を表示する`RESOURCE_GROUP`列。 +- 現在のセッションのエイリアスを表示する`SESSION_ALIAS`列。 +- ステートメントによって現在影響を受けている行数を示す`ROWS_AFFECTED`列。 +- `TIDB_CPU`列は、ステートメントがTiDBサーバーのCPUを消費した時間をナノ秒単位で示します。この列は、 [Top SQL](/dashboard/top-sql.md)機能が有効な場合にのみ意味のある値を表示します。それ以外の場合は、値は`0`になります。 +- ステートメントが TiKVサーバーCPU を消費する時間をナノ秒単位で表示する`TIKV_CPU`列。 -- SQL ステートメントのダイジェストを表示する`DIGEST`列。 -- 処理中のリクエストによって使用されているメモリをバイト単位で表示する`MEM`列。 -- ディスク使用量をバイト単位で表示する`DISK`列。 -- トランザクションの開始時刻を表示する`TxnStart`列。 -- リソース グループ名を表示する`RESOURCE_GROUP`列。 -- 現在のセッションのエイリアスを表示する`SESSION_ALIAS`列。 -- ステートメントによって現在影響を受けている行数を示す`ROWS_AFFECTED`列。 -- `TIDB_CPU`列は、ステートメントがTiDBサーバーのCPUを消費した時間をナノ秒単位で示します。この列は、 [Top SQL](https://docs.pingcap.com/tidb/stable/top-sql)機能が有効な場合にのみ意味のある値を表示します。それ以外の場合は、値は`0`になります。 -- ステートメントが TiKVサーバーCPU を消費する時間をナノ秒単位で表示する`TIKV_CPU`列。 +- SQL ステートメントのダイジェストを表示する`DIGEST`列。 +- 処理中のリクエストによって使用されているメモリをバイト単位で表示する`MEM`列。 +- ディスク使用量をバイト単位で表示する`DISK`列。 +- トランザクションの開始時刻を表示する`TxnStart`列。 +- リソース グループ名を表示する`RESOURCE_GROUP`列。 +- 現在のセッションのエイリアスを表示する`SESSION_ALIAS`列。 +- ステートメントによって現在影響を受けている行数を示す`ROWS_AFFECTED`列。 +- `TIDB_CPU`列は、ステートメントがTiDBサーバーのCPUを消費した時間をナノ秒単位で示します。この列は、 [Top SQL](https://docs.pingcap.com/tidb/stable/top-sql)機能が有効な場合にのみ意味のある値を表示します。それ以外の場合は、値は`0`になります。 +- ステートメントが TiKVサーバーCPU を消費する時間をナノ秒単位で表示する`TIKV_CPU`列。 @@ -95,45 +95,45 @@ RESOURCE_GROUP: default -- `ID` : ユーザー接続の ID。 -- `USER` : `PROCESS`を実行しているユーザーの名前。 -- `HOST` : ユーザーが接続しているアドレス。 -- `DB` : 現在接続されているデフォルト データベースの名前。 -- `COMMAND` : `PROCESS`が実行しているコマンドの種類。 -- `TIME` : 現在の実行時間`PROCESS` (秒)。 -- `STATE` : 現在の接続状態。 -- `INFO` : 処理中の要求されたステートメント。 -- `DIGEST` : SQL ステートメントのダイジェスト。 -- `MEM` : 処理中のリクエストによって使用されるメモリ(バイト単位)。 -- `DISK` : ディスク使用量（バイト単位）。 -- `TxnStart` : トランザクションの開始時刻。 -- `RESOURCE_GROUP` : リソース グループ名。 -- `SESSION_ALIAS` : 現在のセッションのエイリアス。 -- `ROWS_AFFECTED` : 現在ステートメントによって影響を受けている行数。 -- `TIDB_CPU` : ステートメントがTiDBサーバーのCPUを消費する時間（ナノ秒単位）。この列は、 [Top SQL](/dashboard/top-sql.md)機能が有効な場合にのみ意味のある値を表示します。それ以外の場合は、値は`0`になります。 -- `TIKV_CPU` : ステートメントが TiKVサーバーCPU を消費する時間 (ナノ秒単位)。 +- `ID` : ユーザー接続の ID。 +- `USER` : `PROCESS`を実行しているユーザーの名前。 +- `HOST` : ユーザーが接続しているアドレス。 +- `DB` : 現在接続されているデフォルト データベースの名前。 +- `COMMAND` : `PROCESS`が実行しているコマンドの種類。 +- `TIME` : 現在の実行時間`PROCESS` (秒)。 +- `STATE` : 現在の接続状態。 +- `INFO` : 処理中の要求されたステートメント。 +- `DIGEST` : SQL ステートメントのダイジェスト。 +- `MEM` : 処理中のリクエストによって使用されるメモリ(バイト単位)。 +- `DISK` : ディスク使用量（バイト単位）。 +- `TxnStart` : トランザクションの開始時刻。 +- `RESOURCE_GROUP` : リソース グループ名。 +- `SESSION_ALIAS` : 現在のセッションのエイリアス。 +- `ROWS_AFFECTED` : 現在ステートメントによって影響を受けている行数。 +- `TIDB_CPU` : ステートメントがTiDBサーバーのCPUを消費する時間（ナノ秒単位）。この列は、 [Top SQL](/dashboard/top-sql.md)機能が有効な場合にのみ意味のある値を表示します。それ以外の場合は、値は`0`になります。 +- `TIKV_CPU` : ステートメントが TiKVサーバーCPU を消費する時間 (ナノ秒単位)。 -- `ID` : ユーザー接続の ID。 -- `USER` : `PROCESS`を実行しているユーザーの名前。 -- `HOST` : ユーザーが接続しているアドレス。 -- `DB` : 現在接続されているデフォルト データベースの名前。 -- `COMMAND` : `PROCESS`が実行しているコマンドの種類。 -- `TIME` : 現在の実行時間`PROCESS` (秒)。 -- `STATE` : 現在の接続状態。 -- `INFO` : 処理中の要求されたステートメント。 -- `DIGEST` : SQL ステートメントのダイジェスト。 -- `MEM` : 処理中のリクエストによって使用されるメモリ(バイト単位)。 -- `DISK` : ディスク使用量（バイト単位）。 -- `TxnStart` : トランザクションの開始時刻。 -- `RESOURCE_GROUP` : リソース グループ名。 -- `SESSION_ALIAS` : 現在のセッションのエイリアス。 -- `ROWS_AFFECTED` : 現在ステートメントによって影響を受けている行数。 -- `TIDB_CPU` : ステートメントがTiDBサーバーのCPUを消費する時間（ナノ秒単位）。この列は、 [Top SQL](https://docs.pingcap.com/tidb/stable/top-sql)機能が有効な場合にのみ意味のある値を表示します。それ以外の場合は、値は`0`になります。 -- `TIKV_CPU` : ステートメントが TiKVサーバーCPU を消費する時間 (ナノ秒単位)。 +- `ID` : ユーザー接続の ID。 +- `USER` : `PROCESS`を実行しているユーザーの名前。 +- `HOST` : ユーザーが接続しているアドレス。 +- `DB` : 現在接続されているデフォルト データベースの名前。 +- `COMMAND` : `PROCESS`が実行しているコマンドの種類。 +- `TIME` : 現在の実行時間`PROCESS` (秒)。 +- `STATE` : 現在の接続状態。 +- `INFO` : 処理中の要求されたステートメント。 +- `DIGEST` : SQL ステートメントのダイジェスト。 +- `MEM` : 処理中のリクエストによって使用されるメモリ(バイト単位)。 +- `DISK` : ディスク使用量（バイト単位）。 +- `TxnStart` : トランザクションの開始時刻。 +- `RESOURCE_GROUP` : リソース グループ名。 +- `SESSION_ALIAS` : 現在のセッションのエイリアス。 +- `ROWS_AFFECTED` : 現在ステートメントによって影響を受けている行数。 +- `TIDB_CPU` : ステートメントがTiDBサーバーのCPUを消費する時間（ナノ秒単位）。この列は、 [Top SQL](https://docs.pingcap.com/tidb/stable/top-sql)機能が有効な場合にのみ意味のある値を表示します。それ以外の場合は、値は`0`になります。 +- `TIKV_CPU` : ステートメントが TiKVサーバーCPU を消費する時間 (ナノ秒単位)。 diff --git a/information-schema/information-schema-resource-groups.md b/information-schema/information-schema-resource-groups.md index ef6e8fc7358f5..b363e8a9e4498 100644 --- a/information-schema/information-schema-resource-groups.md +++ b/information-schema/information-schema-resource-groups.md @@ -78,10 +78,10 @@ SELECT * FROM information_schema.resource_groups WHERE NAME = 'rg1'; -- View the `RESOURCE_GROUPS`テーブルの列の説明は以下のとおりです。 -- `NAME` : リソース グループの名前。 -- `RU_PER_SEC` : リソース グループのバックフィル速度。単位は RU/秒で、RU [リクエストユニット](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)を意味します。 -- `PRIORITY` : TiKV で処理されるタスクの絶対優先度。異なるリソースは`PRIORITY`の設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。 `PRIORITY`が同じリソース グループの場合、タスクは`RU_PER_SEC`の設定に従って比例的にスケジュールされます。 `PRIORITY`が指定されていない場合、デフォルトの優先度は`MEDIUM`です。 -- `BURSTABLE` : リソース グループが利用可能なシステム リソースを過剰に使用することを許可するかどうか。 +- `NAME` : リソース グループの名前。 +- `RU_PER_SEC` : リソース グループのバックフィル速度。単位は RU/秒で、RU [リクエストユニット](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)を意味します。 +- `PRIORITY` : TiKV で処理されるタスクの絶対優先度。異なるリソースは`PRIORITY`の設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。 `PRIORITY`が同じリソース グループの場合、タスクは`RU_PER_SEC`の設定に従って比例的にスケジュールされます。 `PRIORITY`が指定されていない場合、デフォルトの優先度は`MEDIUM`です。 +- `BURSTABLE` : リソース グループが利用可能なシステム リソースを過剰に使用することを許可するかどうか。 > **Note:** > diff --git a/information-schema/information-schema-runaway-watches.md b/information-schema/information-schema-runaway-watches.md index 9e042b68a89eb..fee6c0bd1f20d 100644 --- a/information-schema/information-schema-runaway-watches.md +++ b/information-schema/information-schema-runaway-watches.md @@ -137,14 +137,14 @@ RESOURCE_GROUP_NAME: default `RUNAWAY_WATCHES`テーブルの各列フィールドの意味は次のとおりです。 -- `ID` : ウォッチアイテムのID。 -- `RESOURCE_GROUP_NAME` : リソース グループの名前。 -- `START_TIME` : 開始時刻。 -- `END_TIME` ：終了時刻。 `UNLIMITED`は、ウォッチアイテムの有効期間が無制限であることを意味します。 -- `WATCH` : クイック識別のマッチタイプ。値は次のとおりです。 - - `Plan`は、プランダイジェストが一致したことを示します。この場合、 `WATCH_TEXT`列にプランダイジェストが表示されます。 - - `Similar`は、SQL ダイジェストが一致したことを示します。この場合、 `WATCH_TEXT`列に SQL ダイジェストが表示されます。 - - `Exact`は、SQLテキストが一致したことを示します。この場合、 `WATCH_TEXT`列にSQLテキストが表示されます。 -- `SOURCE` ：監視対象アイテムの発生源。 `QUERY_LIMIT`ルールによって識別された場合は、識別されたTiDB IPアドレスが表示されます。手動で追加された場合は、 `manual`が表示されます。 -- `ACTION` : 識別後の対応する操作。 -- `RULE` : 識別ルール。現在の 3 つのルールは`ElapsedTime` 、 `ProcessedKeys` 、および`RequestUnit`です。形式は`ProcessedKeys = 666(10)`で、 `666`は実際の値、 `10`はしきい値です。 +- `ID` : ウォッチアイテムのID。 +- `RESOURCE_GROUP_NAME` : リソース グループの名前。 +- `START_TIME` : 開始時刻。 +- `END_TIME` ：終了時刻。 `UNLIMITED`は、ウォッチアイテムの有効期間が無制限であることを意味します。 +- `WATCH` : クイック識別のマッチタイプ。値は次のとおりです。 + - `Plan`は、プランダイジェストが一致したことを示します。この場合、 `WATCH_TEXT`列にプランダイジェストが表示されます。 + - `Similar`は、SQL ダイジェストが一致したことを示します。この場合、 `WATCH_TEXT`列に SQL ダイジェストが表示されます。 + - `Exact`は、SQLテキストが一致したことを示します。この場合、 `WATCH_TEXT`列にSQLテキストが表示されます。 +- `SOURCE` ：監視対象アイテムの発生源。 `QUERY_LIMIT`ルールによって識別された場合は、識別されたTiDB IPアドレスが表示されます。手動で追加された場合は、 `manual`が表示されます。 +- `ACTION` : 識別後の対応する操作。 +- `RULE` : 識別ルール。現在の 3 つのルールは`ElapsedTime` 、 `ProcessedKeys` 、および`RequestUnit`です。形式は`ProcessedKeys = 666(10)`で、 `666`は実際の値、 `10`はしきい値です。 diff --git a/information-schema/information-schema-schemata.md b/information-schema/information-schema-schemata.md index 5028aefb369d2..c9c3a899b8926 100644 --- a/information-schema/information-schema-schemata.md +++ b/information-schema/information-schema-schemata.md @@ -44,8 +44,8 @@ SELECT * FROM SCHEMATA; `SCHEMATA`テーブル内のフィールドは次のように説明されます。 -- `CATALOG_NAME` : データベースが属するカタログ。 -- `SCHEMA_NAME` : データベース名。 -- `DEFAULT_CHARACTER_SET_NAME` : データベースのデフォルトの文字セット。 -- `DEFAULT_COLLATION_NAME` : データベースのデフォルトの照合照合順序。 -- `SQL_PATH` : この項目の値は常に`NULL` 。 +- `CATALOG_NAME` : データベースが属するカタログ。 +- `SCHEMA_NAME` : データベース名。 +- `DEFAULT_CHARACTER_SET_NAME` : データベースのデフォルトの文字セット。 +- `DEFAULT_COLLATION_NAME` : データベースのデフォルトの照合照合順序。 +- `SQL_PATH` : この項目の値は常に`NULL` 。 diff --git a/information-schema/information-schema-sequences.md b/information-schema/information-schema-sequences.md index 982fffad21848..c57deb822dc53 100644 --- a/information-schema/information-schema-sequences.md +++ b/information-schema/information-schema-sequences.md @@ -78,8 +78,8 @@ SEQUENCE_SCHEMA: test ## 参照 {#see-also} -- [`CREATE SEQUENCE`](/sql-statements/sql-statement-create-sequence.md) -- [`SHOW CREATE SEQUENCE`](/sql-statements/sql-statement-show-create-sequence.md) -- [`ALTER SEQUENCE`](/sql-statements/sql-statement-alter-sequence.md) -- [`DROP SEQUENCE`](/sql-statements/sql-statement-drop-sequence.md) -- [シーケンス関数](/functions-and-operators/sequence-functions.md) +- [`CREATE SEQUENCE`](/sql-statements/sql-statement-create-sequence.md) +- [`SHOW CREATE SEQUENCE`](/sql-statements/sql-statement-show-create-sequence.md) +- [`ALTER SEQUENCE`](/sql-statements/sql-statement-alter-sequence.md) +- [`DROP SEQUENCE`](/sql-statements/sql-statement-drop-sequence.md) +- [シーケンス関数](/functions-and-operators/sequence-functions.md) diff --git a/information-schema/information-schema-session-variables.md b/information-schema/information-schema-session-variables.md index 036708a66da8b..902e37ce9eeda 100644 --- a/information-schema/information-schema-session-variables.md +++ b/information-schema/information-schema-session-variables.md @@ -52,5 +52,5 @@ SELECT * FROM SESSION_VARIABLES ORDER BY variable_name LIMIT 10; `SESSION_VARIABLES`表の列の説明は次のとおりです。 -- `VARIABLE_NAME` : データベース内のセッション レベル変数の名前。 -- `VARIABLE_VALUE` : データベース内のセッション レベルの変数の値。 +- `VARIABLE_NAME` : データベース内のセッション レベル変数の名前。 +- `VARIABLE_VALUE` : データベース内のセッション レベルの変数の値。 diff --git a/information-schema/information-schema-sql-diagnostics.md b/information-schema/information-schema-sql-diagnostics.md index 16a0cc8d1fd25..6721eb947b52d 100644 --- a/information-schema/information-schema-sql-diagnostics.md +++ b/information-schema/information-schema-sql-diagnostics.md @@ -9,18 +9,18 @@ SQL診断はTiDB v4.0で導入された機能です。この機能を使用す SQL 診断システムには、次の利点があります。 -- システム全体のすべてのコンポーネントからの情報を統合します。 -- システム テーブルを通じて上位レイヤーへの一貫したインターフェイスを提供します。 -- 監視の概要と自動診断を提供します。 -- クラスター情報のクエリが簡単になります。 +- システム全体のすべてのコンポーネントからの情報を統合します。 +- システム テーブルを通じて上位レイヤーへの一貫したインターフェイスを提供します。 +- 監視の概要と自動診断を提供します。 +- クラスター情報のクエリが簡単になります。 ## 概要 {#overview} SQL 診断システムは、次の 3 つの主要部分で構成されます。 -- **クラスタ情報テーブル**：SQL診断システムは、各インスタンスの個別情報を統一的に取得できるクラスタ情報テーブルを導入します。このシステムは、クラスタトポロジ、ハードウェア情報、ソフトウェア情報、カーネルパラメータ、監視情報、システム情報、スロークエリ、ステートメント、そしてクラスタ全体のログをテーブルに完全に統合します。そのため、これらの情報をSQL文で照会できます。 +- **クラスタ情報テーブル**：SQL診断システムは、各インスタンスの個別情報を統一的に取得できるクラスタ情報テーブルを導入します。このシステムは、クラスタトポロジ、ハードウェア情報、ソフトウェア情報、カーネルパラメータ、監視情報、システム情報、スロークエリ、ステートメント、そしてクラスタ全体のログをテーブルに完全に統合します。そのため、これらの情報をSQL文で照会できます。 -- **クラスタ監視テーブル**：SQL診断システムは、クラスター監視テーブルを導入しました。これらのテーブルはすべて`metrics_schema`にまとめられており、SQL文を使用して監視情報を照会できます。v4.0以前の可視化監視と比較して、このSQLベースの方法を使用することで、クラスター全体のすべての監視情報に対して相関クエリを実行し、異なる期間の結果を比較することで、パフォーマンスのボトルネックを迅速に特定できます。TiDBクラスターには多くの監視メトリックがあるため、SQL診断システムは監視サマリーテーブルも提供しており、異常な監視項目をより簡単に見つけることができます。 +- **クラスタ監視テーブル**：SQL診断システムは、クラスター監視テーブルを導入しました。これらのテーブルはすべて`metrics_schema`にまとめられており、SQL文を使用して監視情報を照会できます。v4.0以前の可視化監視と比較して、このSQLベースの方法を使用することで、クラスター全体のすべての監視情報に対して相関クエリを実行し、異なる期間の結果を比較することで、パフォーマンスのボトルネックを迅速に特定できます。TiDBクラスターには多くの監視メトリックがあるため、SQL診断システムは監視サマリーテーブルも提供しており、異常な監視項目をより簡単に見つけることができます。 **自動診断**：クラスタ情報テーブル、クラスタ監視テーブル、サマリーテーブルをクエリするSQL文を手動で実行して問題を特定することもできますが、自動診断を利用することで、一般的な問題を迅速に特定できます。SQL診断システムは、既存のクラスタ情報テーブルと監視テーブルに基づいて自動診断を実行し、関連する診断結果テーブルと診断サマリーテーブルを提供します。 @@ -28,12 +28,12 @@ SQL 診断システムは、次の 3 つの主要部分で構成されます。 クラスタ情報テーブルは、すべてのインスタンスとクラスタ内のインスタンスの情報を集約します。これらのテーブルを使用すると、1つのSQL文だけですべてのクラスタ情報を照会できます。以下はクラスタ情報テーブルの一覧です。 -- クラスタートポロジテーブル[`information_schema.cluster_info`](/information-schema/information-schema-cluster-info.md)からは、クラスターの現在のトポロジ情報、各インスタンスのバージョン、バージョンに対応する Git ハッシュ、各インスタンスの開始時刻、および各インスタンスの実行時間を取得できます。 -- クラスター構成テーブル[`information_schema.cluster_config`](/information-schema/information-schema-cluster-config.md)から、クラスター内のすべてのインスタンスの構成を取得できます。4.0より前のバージョンでは、これらの構成情報を取得するには、各インスタンスのHTTP APIに個別にアクセスする必要があります。 -- クラスター ハードウェア テーブル[`information_schema.cluster_hardware`](/information-schema/information-schema-cluster-hardware.md)では、クラスター ハードウェア情報を簡単に照会できます。 -- クラスター負荷テーブル[`information_schema.cluster_load`](/information-schema/information-schema-cluster-load.md)では、クラスターのさまざまなインスタンスとハードウェア タイプの負荷情報を照会できます。 -- カーネルパラメータテーブル[`information_schema.cluster_systeminfo`](/information-schema/information-schema-cluster-systeminfo.md)では、クラスター内の異なるインスタンスのカーネル構成情報を照会できます。現在、TiDBはsysctl情報の照会をサポートしています。 -- クラスターログテーブル[`information_schema.cluster_log`](/information-schema/information-schema-cluster-log.md)では、クラスターログをクエリできます。クエリ条件を各インスタンスにプッシュダウンすることで、クエリがクラスターのパフォーマンスに与える影響は、 `grep`コマンドよりも小さくなります。 +- クラスタートポロジテーブル[`information_schema.cluster_info`](/information-schema/information-schema-cluster-info.md)からは、クラスターの現在のトポロジ情報、各インスタンスのバージョン、バージョンに対応する Git ハッシュ、各インスタンスの開始時刻、および各インスタンスの実行時間を取得できます。 +- クラスター構成テーブル[`information_schema.cluster_config`](/information-schema/information-schema-cluster-config.md)から、クラスター内のすべてのインスタンスの構成を取得できます。4.0より前のバージョンでは、これらの構成情報を取得するには、各インスタンスのHTTP APIに個別にアクセスする必要があります。 +- クラスター ハードウェア テーブル[`information_schema.cluster_hardware`](/information-schema/information-schema-cluster-hardware.md)では、クラスター ハードウェア情報を簡単に照会できます。 +- クラスター負荷テーブル[`information_schema.cluster_load`](/information-schema/information-schema-cluster-load.md)では、クラスターのさまざまなインスタンスとハードウェア タイプの負荷情報を照会できます。 +- カーネルパラメータテーブル[`information_schema.cluster_systeminfo`](/information-schema/information-schema-cluster-systeminfo.md)では、クラスター内の異なるインスタンスのカーネル構成情報を照会できます。現在、TiDBはsysctl情報の照会をサポートしています。 +- クラスターログテーブル[`information_schema.cluster_log`](/information-schema/information-schema-cluster-log.md)では、クラスターログをクエリできます。クエリ条件を各インスタンスにプッシュダウンすることで、クエリがクラスターのパフォーマンスに与える影響は、 `grep`コマンドよりも小さくなります。 TiDB v4.0より前のシステムテーブルでは、現在のインスタンスのみを参照できます。TiDB v4.0では、対応するクラスタテーブルが導入され、単一のTiDBインスタンスでクラスタ全体のグローバルビューを取得できます。これらのテーブルは現在`information_schema`にあり、クエリ方法は他の`information_schema`システムテーブルと同じです。 @@ -41,16 +41,16 @@ TiDB v4.0より前のシステムテーブルでは、現在のインスタン 異なる期間におけるクラスタの状態を動的に監視・比較するために、SQL診断システムはクラスタ監視システムテーブルを導入しています。すべての監視テーブルは`metrics_schema`に格納されており、SQL文を用いて監視情報を照会できます。この方法を用いることで、クラスタ全体のすべての監視情報に対して相関クエリを実行し、異なる期間の結果を比較することで、パフォーマンスのボトルネックを迅速に特定できます。 -- [`information_schema.metrics_tables`](/information-schema/information-schema-metrics-tables.md) : 現在、多くのシステム テーブルが存在するため、 `information_schema.metrics_tables`テーブルでこれらの監視テーブルのメタ情報を照会できます。 +- [`information_schema.metrics_tables`](/information-schema/information-schema-metrics-tables.md) : 現在、多くのシステム テーブルが存在するため、 `information_schema.metrics_tables`テーブルでこれらの監視テーブルのメタ情報を照会できます。 TiDB クラスターには多くの監視メトリックがあるため、TiDB は v4.0 で次の監視サマリー テーブルを提供します。 -- 監視概要表[`information_schema.metrics_summary`](/information-schema/information-schema-metrics-summary.md)は、すべての監視データがまとめられており、各監視メトリックをより効率的に確認できます。 -- [`information_schema.metrics_summary_by_label`](/information-schema/information-schema-metrics-summary.md)はすべての監視データを要約します。特に、この表は各監視メトリックの異なるラベルを使用して統計情報を集計します。 +- 監視概要表[`information_schema.metrics_summary`](/information-schema/information-schema-metrics-summary.md)は、すべての監視データがまとめられており、各監視メトリックをより効率的に確認できます。 +- [`information_schema.metrics_summary_by_label`](/information-schema/information-schema-metrics-summary.md)はすべての監視データを要約します。特に、この表は各監視メトリックの異なるラベルを使用して統計情報を集計します。 ## 自動診断 {#automatic-diagnostics} 上記のクラスタ情報テーブルおよびクラスタ監視テーブルでは、クラスタのトラブルシューティングを行うために手動でSQL文を実行する必要があります。TiDB v4.0は自動診断をサポートしています。既存の基本情報テーブルをベースにした診断関連のシステムテーブルを使用することで、診断を自動実行できます。自動診断に関連するシステムテーブルは以下のとおりです。 -- 診断結果テーブル[`information_schema.inspection_result`](/information-schema/information-schema-inspection-result.md)には、システムの診断結果が表示されます。診断は受動的にトリガーされます。`select * from inspection_result`を実行すると、すべての診断ルールがトリガーされ、システムが診断され、システム内の障害またはリスクが結果に表示されます。 -- 診断サマリーテーブル[`information_schema.inspection_summary`](/information-schema/information-schema-inspection-summary.md) 、特定のリンクまたはモジュールの監視情報を要約したものです。モジュールまたはリンク全体のコンテキストに基づいて、トラブルシューティングを行い、問題を特定することができます。 +- 診断結果テーブル[`information_schema.inspection_result`](/information-schema/information-schema-inspection-result.md)には、システムの診断結果が表示されます。診断は受動的にトリガーされます。`select * from inspection_result`を実行すると、すべての診断ルールがトリガーされ、システムが診断され、システム内の障害またはリスクが結果に表示されます。 +- 診断サマリーテーブル[`information_schema.inspection_summary`](/information-schema/information-schema-inspection-summary.md) 、特定のリンクまたはモジュールの監視情報を要約したものです。モジュールまたはリンク全体のコンテキストに基づいて、トラブルシューティングを行い、問題を特定することができます。 diff --git a/information-schema/information-schema-statistics.md b/information-schema/information-schema-statistics.md index 4c62e12b15572..ed60b10e636fa 100644 --- a/information-schema/information-schema-statistics.md +++ b/information-schema/information-schema-statistics.md @@ -40,24 +40,24 @@ DESC statistics; `STATISTICS`テーブル内のフィールドは次のように説明されます。 -- `TABLE_CATALOG` : インデックスを含むテーブルが属するカタログの名前。この値は常に`def` 。 -- `TABLE_SCHEMA` : インデックスを含むテーブルが属するデータベースの名前。 -- `TABLE_NAME` : インデックスを含むテーブルの名前。 -- `NON_UNIQUE` : インデックスに重複する値を含めることができない場合、値は`0`になります。インデックスで重複する値が許可される場合は、値は`1`なります。 -- `INDEX_SCHEMA` : インデックスが属するデータベースの名前。 -- `INDEX_NAME` : インデックスの名前。インデックスが主キーの場合、値は常に`PRIMARY`なります。 -- `SEQ_IN_INDEX` : インデックス内の列番号`1`から始まります。 -- `COLUMN_NAME` : 列名。2列`Expression`の説明を参照してください。 -- `COLLATION` : インデックス内の列のソート方法。値は`A` （昇順）、 `D` （降順）、または`NULL` （ソートなし）のいずれかになります。 -- `CARDINALITY` : TiDBはこのフィールドを使用しません。フィールド値は常に`0`です。 -- `SUB_PART` : インデックスのプレフィックス。列のプレフィックスの一部のみがインデックスされている場合、値はインデックスされた文字数になります。列全体がインデックスされている場合、値は`NULL`なります。 -- `PACKED` : TiDBはこのフィールドを使用しません。この値は常に`NULL` 。 -- `NULLABLE` : 列に`NULL`値が含まれる可能性がある場合、値は`YES`なります。そうでない場合、値は`''`になります。 -- `INDEX_TYPE` : インデックスのタイプ。 -- `COMMENT` : インデックスに関連するその他の情報。 -- `INDEX_COMMENT` : インデックスの作成時にインデックスに指定されたコメント属性を持つコメント。 -- `IS_VISIBLE` : このインデックスが可視かどうか。[不可視インデックス](/sql-statements/sql-statement-create-index.md#invisible-index)を参照してください。 -- `Expression`非式部分のインデックスキーの場合、この値は`NULL`です。式部分のインデックスキーの場合、この値は式そのものです[式インデックス](/sql-statements/sql-statement-create-index.md#expression-index)を参照してください。 +- `TABLE_CATALOG` : インデックスを含むテーブルが属するカタログの名前。この値は常に`def` 。 +- `TABLE_SCHEMA` : インデックスを含むテーブルが属するデータベースの名前。 +- `TABLE_NAME` : インデックスを含むテーブルの名前。 +- `NON_UNIQUE` : インデックスに重複する値を含めることができない場合、値は`0`になります。インデックスで重複する値が許可される場合は、値は`1`なります。 +- `INDEX_SCHEMA` : インデックスが属するデータベースの名前。 +- `INDEX_NAME` : インデックスの名前。インデックスが主キーの場合、値は常に`PRIMARY`なります。 +- `SEQ_IN_INDEX` : インデックス内の列番号`1`から始まります。 +- `COLUMN_NAME` : 列名。2列`Expression`の説明を参照してください。 +- `COLLATION` : インデックス内の列のソート方法。値は`A` （昇順）、 `D` （降順）、または`NULL` （ソートなし）のいずれかになります。 +- `CARDINALITY` : TiDBはこのフィールドを使用しません。フィールド値は常に`0`です。 +- `SUB_PART` : インデックスのプレフィックス。列のプレフィックスの一部のみがインデックスされている場合、値はインデックスされた文字数になります。列全体がインデックスされている場合、値は`NULL`なります。 +- `PACKED` : TiDBはこのフィールドを使用しません。この値は常に`NULL` 。 +- `NULLABLE` : 列に`NULL`値が含まれる可能性がある場合、値は`YES`なります。そうでない場合、値は`''`になります。 +- `INDEX_TYPE` : インデックスのタイプ。 +- `COMMENT` : インデックスに関連するその他の情報。 +- `INDEX_COMMENT` : インデックスの作成時にインデックスに指定されたコメント属性を持つコメント。 +- `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-table-constraints.md b/information-schema/information-schema-table-constraints.md index cf44df7985bdb..993277ff2f3c1 100644 --- a/information-schema/information-schema-table-constraints.md +++ b/information-schema/information-schema-table-constraints.md @@ -47,8 +47,8 @@ SELECT * FROM table_constraints WHERE constraint_type='UNIQUE'; `TABLE_CONSTRAINTS`テーブル内のフィールドは次のように説明されます。 -- `CONSTRAINT_CATALOG` : 制約が属するカタログの名前。この値は常に`def` 。 -- `CONSTRAINT_SCHEMA` : 制約が属するデータベースの名前。 -- `CONSTRAINT_NAME` : 制約の名前。 -- `TABLE_NAME` : テーブルの名前。 -- `CONSTRAINT_TYPE` : 制約の種類。値は`UNIQUE` 、 `PRIMARY KEY` 、または`FOREIGN KEY`のいずれかです。`UNIQUE`と`PRIMARY KEY`の情報は、 `SHOW INDEX`ステートメントの実行結果と同様です。 +- `CONSTRAINT_CATALOG` : 制約が属するカタログの名前。この値は常に`def` 。 +- `CONSTRAINT_SCHEMA` : 制約が属するデータベースの名前。 +- `CONSTRAINT_NAME` : 制約の名前。 +- `TABLE_NAME` : テーブルの名前。 +- `CONSTRAINT_TYPE` : 制約の種類。値は`UNIQUE` 、 `PRIMARY KEY` 、または`FOREIGN KEY`のいずれかです。`UNIQUE`と`PRIMARY KEY`の情報は、 `SHOW INDEX`ステートメントの実行結果と同様です。 diff --git a/information-schema/information-schema-table-storage-stats.md b/information-schema/information-schema-table-storage-stats.md index 50a30909fcb1f..456c95b0aa28f 100644 --- a/information-schema/information-schema-table-storage-stats.md +++ b/information-schema/information-schema-table-storage-stats.md @@ -53,11 +53,11 @@ EMPTY_REGION_COUNT: 1 `TABLE_STORAGE_STATS`テーブル内のフィールドは次のように説明されます。 -- `TABLE_SCHEMA` : テーブルが属するスキーマの名前。 -- `TABLE_NAME` : テーブルの名前。 -- `TABLE_ID` : テーブルの ID。 -- `PEER_COUNT` : テーブルのレプリカの数。 -- `REGION_COUNT` : リージョンの数。 -- `EMPTY_REGION_COUNT` : このテーブルにデータが含まれていないリージョンの数。 -- `TABLE_SIZE` : テーブルの合計サイズ (MiB 単位)。 -- `TABLE_KEYS` : テーブル内のレコードの合計数。 +- `TABLE_SCHEMA` : テーブルが属するスキーマの名前。 +- `TABLE_NAME` : テーブルの名前。 +- `TABLE_ID` : テーブルの ID。 +- `PEER_COUNT` : テーブルのレプリカの数。 +- `REGION_COUNT` : リージョンの数。 +- `EMPTY_REGION_COUNT` : このテーブルにデータが含まれていないリージョンの数。 +- `TABLE_SIZE` : テーブルの合計サイズ (MiB 単位)。 +- `TABLE_KEYS` : テーブル内のレコードの合計数。 diff --git a/information-schema/information-schema-tables.md b/information-schema/information-schema-tables.md index 6b6650770e7e8..535a70c1a2f44 100644 --- a/information-schema/information-schema-tables.md +++ b/information-schema/information-schema-tables.md @@ -97,38 +97,38 @@ SHOW TABLES `TABLES`テーブル内の列の説明は次のとおりです。 -- `TABLE_CATALOG` : テーブルが属するカタログの名前。値は常に`def`です。 -- `TABLE_SCHEMA` : テーブルが属するスキーマの名前。 -- `TABLE_NAME` : テーブルの名前。 -- `TABLE_TYPE` : テーブルのタイプ。 -- `ENGINE` :ストレージエンジンの種類。現在の値は`InnoDB`です。 -- `VERSION` : バージョン。デフォルトの値は`10`です。 -- `ROW_FORMAT` : 行形式。現在の値は`Compact`です。 -- `TABLE_ROWS` : 統計におけるテーブル内の行数。 -- `AVG_ROW_LENGTH` : 表の平均行の長さ`AVG_ROW_LENGTH` = `DATA_LENGTH` / `TABLE_ROWS` 。 -- `DATA_LENGTH` : データ長。`DATA_LENGTH` = `TABLE_ROWS` * タプル内の列のストレージ長の合計。TiKVのレプリカは考慮されません。 -- `MAX_DATA_LENGTH` : 最大データ長。現在の値は`0` 、データ長に上限がないことを意味します。 -- `INDEX_LENGTH` : インデックスの長さ`INDEX_LENGTH` = `TABLE_ROWS` * インデックスタプル内の列の長さの合計。TiKVのレプリカは考慮されません。 -- `DATA_FREE` : データフラグメント。現在の値は`0`です。 -- `AUTO_INCREMENT` : 現在のAUTO_INCREMENT主キーの値。 -- `CREATE_TIME` : テーブルが作成された時刻。 -- `UPDATE_TIME` : テーブルが更新される時刻。 -- `CHECK_TIME` : テーブルがチェックされる時刻。 -- `TABLE_COLLATION` : テーブル内の文字列の照合順序。 -- `CHECKSUM` : チェックサム。 -- `CREATE_OPTIONS` : オプションを作成します。 -- `TABLE_COMMENT` : 表のコメントとメモ。 +- `TABLE_CATALOG` : テーブルが属するカタログの名前。値は常に`def`です。 +- `TABLE_SCHEMA` : テーブルが属するスキーマの名前。 +- `TABLE_NAME` : テーブルの名前。 +- `TABLE_TYPE` : テーブルのタイプ。 +- `ENGINE` :ストレージエンジンの種類。現在の値は`InnoDB`です。 +- `VERSION` : バージョン。デフォルトの値は`10`です。 +- `ROW_FORMAT` : 行形式。現在の値は`Compact`です。 +- `TABLE_ROWS` : 統計におけるテーブル内の行数。 +- `AVG_ROW_LENGTH` : 表の平均行の長さ`AVG_ROW_LENGTH` = `DATA_LENGTH` / `TABLE_ROWS` 。 +- `DATA_LENGTH` : データ長。`DATA_LENGTH` = `TABLE_ROWS` * タプル内の列のストレージ長の合計。TiKVのレプリカは考慮されません。 +- `MAX_DATA_LENGTH` : 最大データ長。現在の値は`0` 、データ長に上限がないことを意味します。 +- `INDEX_LENGTH` : インデックスの長さ`INDEX_LENGTH` = `TABLE_ROWS` * インデックスタプル内の列の長さの合計。TiKVのレプリカは考慮されません。 +- `DATA_FREE` : データフラグメント。現在の値は`0`です。 +- `AUTO_INCREMENT` : 現在のAUTO_INCREMENT主キーの値。 +- `CREATE_TIME` : テーブルが作成された時刻。 +- `UPDATE_TIME` : テーブルが更新される時刻。 +- `CHECK_TIME` : テーブルがチェックされる時刻。 +- `TABLE_COLLATION` : テーブル内の文字列の照合順序。 +- `CHECKSUM` : チェックサム。 +- `CREATE_OPTIONS` : オプションを作成します。 +- `TABLE_COMMENT` : 表のコメントとメモ。 テーブル内の情報の大部分はMySQLと同じです。以下の列はTiDBによって新たに定義されています。 -- `TIDB_TABLE_ID` : テーブルの内部IDを示します。このIDはTiDBクラスタ内で一意です。 -- `TIDB_ROW_ID_SHARDING_INFO` : テーブルのシャーディングタイプを示します。可能な値は次のとおりです。 - - `"NOT_SHARDED"` : テーブルはシャード化されていません。 - - `"NOT_SHARDED(PK_IS_HANDLE)"` : 行 ID として整数の主キーを定義するテーブルはシャード化されません。 - - `"PK_AUTO_RANDOM_BITS={bit_number}"` : 整数の主キーを行 ID として定義するテーブルは、主キーに`AUTO_RANDOM`属性が割り当てられているため、シャードされます。 - - `"SHARD_BITS={bit_number}"` : テーブルは`SHARD_ROW_ID_BITS={bit_number}`を使用して分割されます。 - - `NULL` : テーブルはシステム テーブルまたはビューであるため、シャード化できません。 -- `TIDB_PK_TYPE` : テーブルの主キーの種類。可能な値は`CLUSTERED` (クラスター化主キー) と`NONCLUSTERED` (非クラスター化主キー) です。 -- `TIDB_PLACEMENT_POLICY_NAME` : テーブルに適用された配置ポリシーの名前。 -- `TIDB_TABLE_MODE` : テーブルのモード。たとえば、 `Normal` 、 `Import` 、 `Restore` 。 -- `TIDB_AFFINITY` : テーブルのアフィニティレベル。パーティション化されていないテーブルの場合は`table` 、パーティション化されたテーブルの場合は`partition` 、アフィニティが有効化されていない場合は`NULL`なります。 +- `TIDB_TABLE_ID` : テーブルの内部IDを示します。このIDはTiDBクラスタ内で一意です。 +- `TIDB_ROW_ID_SHARDING_INFO` : テーブルのシャーディングタイプを示します。可能な値は次のとおりです。 + - `"NOT_SHARDED"` : テーブルはシャード化されていません。 + - `"NOT_SHARDED(PK_IS_HANDLE)"` : 行 ID として整数の主キーを定義するテーブルはシャード化されません。 + - `"PK_AUTO_RANDOM_BITS={bit_number}"` : 整数の主キーを行 ID として定義するテーブルは、主キーに`AUTO_RANDOM`属性が割り当てられているため、シャードされます。 + - `"SHARD_BITS={bit_number}"` : テーブルは`SHARD_ROW_ID_BITS={bit_number}`を使用して分割されます。 + - `NULL` : テーブルはシステム テーブルまたはビューであるため、シャード化できません。 +- `TIDB_PK_TYPE` : テーブルの主キーの種類。可能な値は`CLUSTERED` (クラスター化主キー) と`NONCLUSTERED` (非クラスター化主キー) です。 +- `TIDB_PLACEMENT_POLICY_NAME` : テーブルに適用された配置ポリシーの名前。 +- `TIDB_TABLE_MODE` : テーブルのモード。たとえば、 `Normal` 、 `Import` 、 `Restore` 。 +- `TIDB_AFFINITY` : テーブルのアフィニティレベル。パーティション化されていないテーブルの場合は`table` 、パーティション化されたテーブルの場合は`partition` 、アフィニティが有効化されていない場合は`NULL`なります。 diff --git a/information-schema/information-schema-tidb-check-constraints.md b/information-schema/information-schema-tidb-check-constraints.md index f21771223f02e..2ae5be4ee0ff7 100644 --- a/information-schema/information-schema-tidb-check-constraints.md +++ b/information-schema/information-schema-tidb-check-constraints.md @@ -51,9 +51,9 @@ CONSTRAINT_CATALOG: def `TIDB_CHECK_CONSTRAINTS`テーブル内のフィールドは次のように説明されます。 -- `CONSTRAINT_CATALOG` : 制約のカタログ。常に`def`です。 -- `CONSTRAINT_SCHEMA` : 制約のスキーマ。 -- `CONSTRAINT_NAME` : 制約の名前。 -- `CHECK_CLAUSE` : チェック制約の句。 -- `TABLE_NAME` : 制約が配置されているテーブルの名前。 -- `TABLE_ID` : 制約が配置されているテーブルの ID。 +- `CONSTRAINT_CATALOG` : 制約のカタログ。常に`def`です。 +- `CONSTRAINT_SCHEMA` : 制約のスキーマ。 +- `CONSTRAINT_NAME` : 制約の名前。 +- `CHECK_CLAUSE` : チェック制約の句。 +- `TABLE_NAME` : 制約が配置されているテーブルの名前。 +- `TABLE_ID` : 制約が配置されているテーブルの ID。 diff --git a/information-schema/information-schema-tidb-hot-regions-history.md b/information-schema/information-schema-tidb-hot-regions-history.md index b757dd39accad..5023f76df0dad 100644 --- a/information-schema/information-schema-tidb-hot-regions-history.md +++ b/information-schema/information-schema-tidb-hot-regions-history.md @@ -54,22 +54,22 @@ DESC tidb_hot_regions_history; `TIDB_HOT_REGIONS_HISTORY`テーブルのフィールドは、次のように説明されます。 -- UPDATE_TIME: ホットリージョンの更新時刻。 -- DB_NAME: ホットリージョンが存在するオブジェクトのデータベース名。 -- TABLE_ID: ホットリージョンが存在するテーブルのID。 -- TABLE_NAME: ホットリージョンが存在するテーブルの名前。 -- INDEX_NAME: ホットリージョンが存在するインデックスの名前。 -- INDEX_ID: ホットリージョンが存在するインデックスのID。 -- REGION_ID: ホットリージョンのID。 -- STORE_ID: ホットリージョンが存在するストアのID。 -- PEER_ID: ホットリージョンに対応するピアのID。 -- IS_LEARNER: ピアがラーナーであるかどうか。 -- IS_LEADER: ピアがリーダーであるかどうか。 -- タイプ: ホットリージョンのタイプ。 -- HOT_DEGREE: ホットリージョンの高温度。 -- FLOW_BYTES:リージョン内で書き込まれたバイト数と読み取られたバイト数。 -- KEY_RATE:リージョン内で書き込まれた鍵と読み取られた鍵の数。 -- QUERY_RATE:リージョン内で書き込まれたクエリと読み込まれたクエリの数。 +- UPDATE_TIME: ホットリージョンの更新時刻。 +- DB_NAME: ホットリージョンが存在するオブジェクトのデータベース名。 +- TABLE_ID: ホットリージョンが存在するテーブルのID。 +- TABLE_NAME: ホットリージョンが存在するテーブルの名前。 +- INDEX_NAME: ホットリージョンが存在するインデックスの名前。 +- INDEX_ID: ホットリージョンが存在するインデックスのID。 +- REGION_ID: ホットリージョンのID。 +- STORE_ID: ホットリージョンが存在するストアのID。 +- PEER_ID: ホットリージョンに対応するピアのID。 +- IS_LEARNER: ピアがラーナーであるかどうか。 +- IS_LEADER: ピアがリーダーであるかどうか。 +- タイプ: ホットリージョンのタイプ。 +- HOT_DEGREE: ホットリージョンの高温度。 +- FLOW_BYTES:リージョン内で書き込まれたバイト数と読み取られたバイト数。 +- KEY_RATE:リージョン内で書き込まれた鍵と読み取られた鍵の数。 +- QUERY_RATE:リージョン内で書き込まれたクエリと読み込まれたクエリの数。 > **Note:** > @@ -77,7 +77,7 @@ DESC tidb_hot_regions_history; ## 一般的なユーザーシナリオ {#common-user-scenarios} -- 特定の期間内のホットリージョンを検索します。 `update_time`実際の時間に置き換えてください。 +- 特定の期間内のホットリージョンを検索します。 `update_time`実際の時間に置き換えてください。 ```sql SELECT * FROM INFORMATION_SCHEMA.TIDB_HOT_REGIONS_HISTORY WHERE update_time >'2021-08-18 21:40:00' and update_time <'2021-09-19 00:00:00'; @@ -87,31 +87,31 @@ DESC tidb_hot_regions_history; > > `UPDATE_TIME`は Unix タイムスタンプもサポートしています。たとえば、 `update_time >TIMESTAMP('2021-08-18 21:40:00')`や`update_time > FROM_UNIXTIME(1629294000.000)`などです。 -- 特定の期間内のテーブル内のホットリージョンをクエリします。 `update_time`と`table_name`実際の値に置き換えてください。 +- 特定の期間内のテーブル内のホットリージョンをクエリします。 `update_time`と`table_name`実際の値に置き換えてください。 ```SQL SELECT * FROM INFORMATION_SCHEMA.TIDB_HOT_REGIONS_HISTORY WHERE update_time >'2021-08-18 21:40:00' and update_time <'2021-09-19 00:00:00' and TABLE_NAME = 'table_name'; ``` -- 特定の期間におけるホットリージョンの分布を照会します。 `update_time`と`table_name`実際の値に置き換えてください。 +- 特定の期間におけるホットリージョンの分布を照会します。 `update_time`と`table_name`実際の値に置き換えてください。 ```sql SELECT count(region_id) cnt, store_id FROM INFORMATION_SCHEMA.TIDB_HOT_REGIONS_HISTORY WHERE update_time >'2021-08-18 21:40:00' and update_time <'2021-09-19 00:00:00' and table_name = 'table_name' GROUP BY STORE_ID ORDER BY cnt DESC; ``` -- 特定の期間におけるホットLeaderリージョンの分布を照会します。 `update_time`と`table_name`実際の値に置き換えてください。 +- 特定の期間におけるホットLeaderリージョンの分布を照会します。 `update_time`と`table_name`実際の値に置き換えてください。 ```sql SELECT count(region_id) cnt, store_id FROM INFORMATION_SCHEMA.TIDB_HOT_REGIONS_HISTORY WHERE update_time >'2021-08-18 21:40:00' and update_time <'2021-09-19 00:00:00' and table_name = 'table_name' and is_leader=1 GROUP BY STORE_ID ORDER BY cnt DESC; ``` -- 特定の期間におけるホットインデックスリージョンの分布を照会します。 `update_time`と`table_name`実際の値に置き換えてください。 +- 特定の期間におけるホットインデックスリージョンの分布を照会します。 `update_time`と`table_name`実際の値に置き換えてください。 ```sql SELECT count(region_id) cnt, index_name, store_id FROM INFORMATION_SCHEMA.TIDB_HOT_REGIONS_HISTORY WHERE update_time >'2021-08-18 21:40:00' and update_time <'2021-09-19 00:00:00' and table_name = 'table_name' group by index_name, store_id order by index_name,cnt desc; ``` -- 特定の期間におけるホットなインデックスLeaderリージョンの分布を照会します。 `update_time`と`table_name`実際の値に置き換えてください。 +- 特定の期間におけるホットなインデックスLeaderリージョンの分布を照会します。 `update_time`と`table_name`実際の値に置き換えてください。 ```sql SELECT count(region_id) cnt, index_name, store_id FROM INFORMATION_SCHEMA.TIDB_HOT_REGIONS_HISTORY WHERE update_time >'2021-08-18 21:40:00' and update_time <'2022-09-19 00:00:00' and table_name = 'table_name' and is_leader=1 group by index_name, store_id order by index_name,cnt desc; diff --git a/information-schema/information-schema-tidb-hot-regions.md b/information-schema/information-schema-tidb-hot-regions.md index 406afc56e182d..491208534e33f 100644 --- a/information-schema/information-schema-tidb-hot-regions.md +++ b/information-schema/information-schema-tidb-hot-regions.md @@ -36,13 +36,13 @@ DESC tidb_hot_regions; `TIDB_HOT_REGIONS`表の列の説明は次のとおりです。 -- `TABLE_ID` : ホットリージョンが配置されているテーブルの ID。 -- `INDEX_ID` : ホットリージョンが配置されているインデックスの ID。 -- `DB_NAME` : ホットリージョンが配置されているオブジェクトのデータベース名。 -- `TABLE_NAME` : ホットリージョンが配置されているテーブルの名前。 -- `INDEX_NAME` : ホットリージョンが配置されているインデックスの名前。 -- `REGION_ID` : ホットリージョンの ID。 -- `TYPE` : ホットリージョンのタイプ。 -- `MAX_HOT_DEGREE` :リージョンの最大暑さ度。 -- `REGION_COUNT` : インスタンス内のホットリージョンの数。 -- `FLOW_BYTES` :リージョン内で書き込まれたバイト数と読み取られたバイト数。 +- `TABLE_ID` : ホットリージョンが配置されているテーブルの ID。 +- `INDEX_ID` : ホットリージョンが配置されているインデックスの ID。 +- `DB_NAME` : ホットリージョンが配置されているオブジェクトのデータベース名。 +- `TABLE_NAME` : ホットリージョンが配置されているテーブルの名前。 +- `INDEX_NAME` : ホットリージョンが配置されているインデックスの名前。 +- `REGION_ID` : ホットリージョンの ID。 +- `TYPE` : ホットリージョンのタイプ。 +- `MAX_HOT_DEGREE` :リージョンの最大暑さ度。 +- `REGION_COUNT` : インスタンス内のホットリージョンの数。 +- `FLOW_BYTES` :リージョン内で書き込まれたバイト数と読み取られたバイト数。 diff --git a/information-schema/information-schema-tidb-index-usage.md b/information-schema/information-schema-tidb-index-usage.md index 648b801807313..f2211a6fa44e8 100644 --- a/information-schema/information-schema-tidb-index-usage.md +++ b/information-schema/information-schema-tidb-index-usage.md @@ -46,20 +46,20 @@ DESC TIDB_INDEX_USAGE; `TIDB_INDEX_USAGE`テーブルの列は以下のとおりです。 -- `TABLE_SCHEMA` : インデックスを含むテーブルが属するデータベースの名前。 -- `TABLE_NAME` : インデックスを含むテーブルの名前。 -- `INDEX_NAME` : インデックスの名前。 -- `QUERY_TOTAL` : インデックスにアクセスするステートメントの総数。 -- `KV_REQ_TOTAL` : インデックスにアクセスした際に生成された KV リクエストの総数。 -- `ROWS_ACCESS_TOTAL` : インデックスにアクセスする際にスキャンされた行の総数。 -- `PERCENTAGE_ACCESS_0` : 行アクセス率（テーブル内の全行数に対するアクセスされた行の割合）が 0 になる回数。 -- `PERCENTAGE_ACCESS_0_1` : 行アクセス率が 0% ～ 1% である回数。 -- `PERCENTAGE_ACCESS_1_10` : 行アクセス率が 1% ～ 10% である回数。 -- `PERCENTAGE_ACCESS_10_20` : 行アクセス率が 10% ～ 20% の間である回数。 -- `PERCENTAGE_ACCESS_20_50` : 行アクセス率が 20% ～ 50% の間である回数。 -- `PERCENTAGE_ACCESS_50_100` : 行アクセス率が 50% ～ 100% の間である回数。 -- `PERCENTAGE_ACCESS_100` : 行アクセス率が 100% になる回数。 -- `LAST_ACCESS_TIME` : インデックスへの最新のアクセス時刻。 +- `TABLE_SCHEMA` : インデックスを含むテーブルが属するデータベースの名前。 +- `TABLE_NAME` : インデックスを含むテーブルの名前。 +- `INDEX_NAME` : インデックスの名前。 +- `QUERY_TOTAL` : インデックスにアクセスするステートメントの総数。 +- `KV_REQ_TOTAL` : インデックスにアクセスした際に生成された KV リクエストの総数。 +- `ROWS_ACCESS_TOTAL` : インデックスにアクセスする際にスキャンされた行の総数。 +- `PERCENTAGE_ACCESS_0` : 行アクセス率（テーブル内の全行数に対するアクセスされた行の割合）が 0 になる回数。 +- `PERCENTAGE_ACCESS_0_1` : 行アクセス率が 0% ～ 1% である回数。 +- `PERCENTAGE_ACCESS_1_10` : 行アクセス率が 1% ～ 10% である回数。 +- `PERCENTAGE_ACCESS_10_20` : 行アクセス率が 10% ～ 20% の間である回数。 +- `PERCENTAGE_ACCESS_20_50` : 行アクセス率が 20% ～ 50% の間である回数。 +- `PERCENTAGE_ACCESS_50_100` : 行アクセス率が 50% ～ 100% の間である回数。 +- `PERCENTAGE_ACCESS_100` : 行アクセス率が 100% になる回数。 +- `LAST_ACCESS_TIME` : インデックスへの最新のアクセス時刻。 ## クラスターTIDBインデックス使用状況 {#cluster_tidb_index_usage} @@ -99,10 +99,10 @@ DESC CLUSTER_TIDB_INDEX_USAGE; ## 制限事項 {#limitations} -- `TIDB_INDEX_USAGE`テーブルのデータは、最大 5 分遅れる場合があります。 -- TiDBが再起動すると、 `TIDB_INDEX_USAGE`テーブルのデータがクリアされます。 -- TiDBは、テーブルに有効な統計情報がある場合にのみ、そのテーブルのインデックス使用状況を記録します。 +- `TIDB_INDEX_USAGE`テーブルのデータは、最大 5 分遅れる場合があります。 +- TiDBが再起動すると、 `TIDB_INDEX_USAGE`テーブルのデータがクリアされます。 +- TiDBは、テーブルに有効な統計情報がある場合にのみ、そのテーブルのインデックス使用状況を記録します。 ## 続きを読む {#read-more} -- [`sys.schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md) +- [`sys.schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md) diff --git a/information-schema/information-schema-tidb-indexes.md b/information-schema/information-schema-tidb-indexes.md index dee7395fac531..ff998a1d4b5f0 100644 --- a/information-schema/information-schema-tidb-indexes.md +++ b/information-schema/information-schema-tidb-indexes.md @@ -51,14 +51,14 @@ WHERE `TIDB_INDEXES`テーブル内のフィールドは次のように説明されます。 -- `TABLE_SCHEMA` : インデックスが属するスキーマの名前。 -- `TABLE_NAME` : インデックスが属するテーブルの名前。 -- `NON_UNIQUE` : インデックスが一意の場合、値は`0`になります。それ以外の場合、値は`1`なります。 -- `KEY_NAME` : インデックス名。インデックスが主キーの場合、名前は`PRIMARY`なります。 -- `SEQ_IN_INDEX` : インデックス内の列の連続番号`1`から始まります。 -- `COLUMN_NAME` : インデックスが配置されている列の名前。 -- `SUB_PART` : インデックスのプレフィックス長。列が部分的にインデックスされている場合、値`SUB_PART`インデックスされた文字数です。それ以外の場合は、値は`NULL`です。 -- `INDEX_COMMENT` : インデックスの作成時に作成されるインデックスのコメント。 -- `INDEX_ID` : インデックス ID。 -- `IS_VISIBLE` : インデックスが表示されるかどうか。 -- `CLUSTERED` : [クラスター化インデックス](/clustered-indexes.md)かどうか。 +- `TABLE_SCHEMA` : インデックスが属するスキーマの名前。 +- `TABLE_NAME` : インデックスが属するテーブルの名前。 +- `NON_UNIQUE` : インデックスが一意の場合、値は`0`になります。それ以外の場合、値は`1`なります。 +- `KEY_NAME` : インデックス名。インデックスが主キーの場合、名前は`PRIMARY`なります。 +- `SEQ_IN_INDEX` : インデックス内の列の連続番号`1`から始まります。 +- `COLUMN_NAME` : インデックスが配置されている列の名前。 +- `SUB_PART` : インデックスのプレフィックス長。列が部分的にインデックスされている場合、値`SUB_PART`インデックスされた文字数です。それ以外の場合は、値は`NULL`です。 +- `INDEX_COMMENT` : インデックスの作成時に作成されるインデックスのコメント。 +- `INDEX_ID` : インデックス ID。 +- `IS_VISIBLE` : インデックスが表示されるかどうか。 +- `CLUSTERED` : [クラスター化インデックス](/clustered-indexes.md)かどうか。 diff --git a/information-schema/information-schema-tidb-trx.md b/information-schema/information-schema-tidb-trx.md index c2db2e482772b..37706e1ddf927 100644 --- a/information-schema/information-schema-tidb-trx.md +++ b/information-schema/information-schema-tidb-trx.md @@ -36,31 +36,31 @@ DESC TIDB_TRX; `TIDB_TRX`テーブル内の各列フィールドの意味は次のとおりです。 -- `ID` : トランザクション ID。トランザクションの`start_ts` (開始タイムスタンプ) です。 -- `START_TIME` : トランザクションの開始時刻。これは、トランザクションの`start_ts`に対応する物理的な時間です。 -- `CURRENT_SQL_DIGEST` : トランザクションで現在実行されている SQL ステートメントのダイジェスト。 -- `CURRENT_SQL_DIGEST_TEXT` : トランザクションによって現在実行されているSQL文の正規化された形式、つまり引数とフォーマットのないSQL文。これは`CURRENT_SQL_DIGEST`に相当します。 -- `STATE` : トランザクションの現在の状態。以下の値のいずれかになります。 - - `Idle` : トランザクションはアイドル状態です。つまり、ユーザーがクエリを入力するのを待機しています。 - - `Running` : トランザクションはクエリを実行しています。 - - `LockWaiting` : トランザクションは悲観的ロックの取得を待機しています。他のトランザクションによってブロックされているかどうかに関係なく、トランザクションは悲観的ロック操作の開始時にこの状態になることに注意してください。 - - `Committing` : トランザクションはコミット処理中です。 - - `RollingBack` : トランザクションはロールバック中です。 -- `WAITING_START_TIME` : `STATE`の値が`LockWaiting`の場合、この列には待機の開始時刻が表示されます。 -- `MEM_BUFFER_KEYS` : 現在のトランザクションによってメモリバッファーに書き込まれたキーの数。 -- `MEM_BUFFER_BYTES` : 現在のトランザクションによってメモリバッファーに書き込まれたキー値バイトの合計数。 -- `SESSION_ID` : このトランザクションが属するセッションの ID。 -- `USER` : トランザクションを実行するユーザーの名前。 -- `DB` : トランザクションが実行されるセッションの現在のデフォルトのデータベース名。 -- `ALL_SQL_DIGESTS` : トランザクションによって実行された文のダイジェストリスト。このリストはJSON形式の文字列配列として表示されます。各トランザクションは最大で最初の50文を記録します。[`TIDB_DECODE_SQL_DIGESTS`](/functions-and-operators/tidb-functions.md#tidb_decode_sql_digests)を使用すると、この列の情報を対応する正規化されたSQL文のリストに変換できます。 -- `RELATED_TABLE_IDS` : トランザクションがアクセスするテーブル、ビュー、およびその他のオブジェクトの ID。 +- `ID` : トランザクション ID。トランザクションの`start_ts` (開始タイムスタンプ) です。 +- `START_TIME` : トランザクションの開始時刻。これは、トランザクションの`start_ts`に対応する物理的な時間です。 +- `CURRENT_SQL_DIGEST` : トランザクションで現在実行されている SQL ステートメントのダイジェスト。 +- `CURRENT_SQL_DIGEST_TEXT` : トランザクションによって現在実行されているSQL文の正規化された形式、つまり引数とフォーマットのないSQL文。これは`CURRENT_SQL_DIGEST`に相当します。 +- `STATE` : トランザクションの現在の状態。以下の値のいずれかになります。 + - `Idle` : トランザクションはアイドル状態です。つまり、ユーザーがクエリを入力するのを待機しています。 + - `Running` : トランザクションはクエリを実行しています。 + - `LockWaiting` : トランザクションは悲観的ロックの取得を待機しています。他のトランザクションによってブロックされているかどうかに関係なく、トランザクションは悲観的ロック操作の開始時にこの状態になることに注意してください。 + - `Committing` : トランザクションはコミット処理中です。 + - `RollingBack` : トランザクションはロールバック中です。 +- `WAITING_START_TIME` : `STATE`の値が`LockWaiting`の場合、この列には待機の開始時刻が表示されます。 +- `MEM_BUFFER_KEYS` : 現在のトランザクションによってメモリバッファーに書き込まれたキーの数。 +- `MEM_BUFFER_BYTES` : 現在のトランザクションによってメモリバッファーに書き込まれたキー値バイトの合計数。 +- `SESSION_ID` : このトランザクションが属するセッションの ID。 +- `USER` : トランザクションを実行するユーザーの名前。 +- `DB` : トランザクションが実行されるセッションの現在のデフォルトのデータベース名。 +- `ALL_SQL_DIGESTS` : トランザクションによって実行された文のダイジェストリスト。このリストはJSON形式の文字列配列として表示されます。各トランザクションは最大で最初の50文を記録します。[`TIDB_DECODE_SQL_DIGESTS`](/functions-and-operators/tidb-functions.md#tidb_decode_sql_digests)を使用すると、この列の情報を対応する正規化されたSQL文のリストに変換できます。 +- `RELATED_TABLE_IDS` : トランザクションがアクセスするテーブル、ビュー、およびその他のオブジェクトの ID。 > **Note:** > -> - [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)を参照してください。 -> - [`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 内部トランザクションの情報の表示をサポートしていません。 +> - [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)を参照してください。 +> - [`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 内部トランザクションの情報の表示をサポートしていません。 ## 例 {#example} diff --git a/information-schema/information-schema-tiflash-indexes.md b/information-schema/information-schema-tiflash-indexes.md index 313bf5522e4af..ecb0ffb3c8033 100644 --- a/information-schema/information-schema-tiflash-indexes.md +++ b/information-schema/information-schema-tiflash-indexes.md @@ -41,17 +41,17 @@ DESC TIFLASH_INDEXES; `TIFLASH_INDEXES`テーブル内のフィールドは次のように説明されます。 -- `TIDB_DATABASE` : テーブルが属するデータベースの名前。 -- `TIDB_TABLE` : テーブルの名前。 -- `TABLE_ID` : テーブルの内部 ID。TiDB クラスター内で一意です。 -- `COLUMN_NAME` : インデックスが構築される列の名前。 -- `INDEX_NAME` : インデックスの名前。 -- `COLUMN_ID` : インデックスが構築される列の ID。 -- `INDEX_ID` : インデックスの ID。 -- `INDEX_KIND` : インデックスのタイプ。 -- `ROWS_STABLE_INDEXED` : 安定レイヤーがインデックス構築を完了したTiFlashレプリカ内の行数。 -- `ROWS_STABLE_NOT_INDEXED` : 安定レイヤーがインデックス構築を完了していないTiFlashレプリカ内の行数。 -- `ROWS_DELTA_INDEXED` : Deltaレイヤーがインデックス構築を完了したTiFlashレプリカ内の行数。 -- `ROWS_DELTA_NOT_INDEXED` : Deltaレイヤーがインデックス構築を完了していないTiFlashレプリカ内の行数。 -- `ERROR_MESSAGE` : インデックス構築中に発生した回復不能なエラーの詳細。 -- `TIFLASH_INSTANCE` : インデックス構築タスクを実行するTiFlashインスタンスのアドレス。 +- `TIDB_DATABASE` : テーブルが属するデータベースの名前。 +- `TIDB_TABLE` : テーブルの名前。 +- `TABLE_ID` : テーブルの内部 ID。TiDB クラスター内で一意です。 +- `COLUMN_NAME` : インデックスが構築される列の名前。 +- `INDEX_NAME` : インデックスの名前。 +- `COLUMN_ID` : インデックスが構築される列の ID。 +- `INDEX_ID` : インデックスの ID。 +- `INDEX_KIND` : インデックスのタイプ。 +- `ROWS_STABLE_INDEXED` : 安定レイヤーがインデックス構築を完了したTiFlashレプリカ内の行数。 +- `ROWS_STABLE_NOT_INDEXED` : 安定レイヤーがインデックス構築を完了していないTiFlashレプリカ内の行数。 +- `ROWS_DELTA_INDEXED` : Deltaレイヤーがインデックス構築を完了したTiFlashレプリカ内の行数。 +- `ROWS_DELTA_NOT_INDEXED` : Deltaレイヤーがインデックス構築を完了していないTiFlashレプリカ内の行数。 +- `ERROR_MESSAGE` : インデックス構築中に発生した回復不能なエラーの詳細。 +- `TIFLASH_INSTANCE` : インデックス構築タスクを実行するTiFlashインスタンスのアドレス。 diff --git a/information-schema/information-schema-tiflash-replica.md b/information-schema/information-schema-tiflash-replica.md index afa7c0a164431..ae4e7828297ac 100644 --- a/information-schema/information-schema-tiflash-replica.md +++ b/information-schema/information-schema-tiflash-replica.md @@ -31,10 +31,10 @@ DESC TIFLASH_REPLICA; `TIFLASH_REPLICA`テーブル内のフィールドは次のように説明されます。 -- `TABLE_SCHEMA` : テーブルが属するデータベースの名前。 -- `TABLE_NAME` : テーブルの名前。 -- `TABLE_ID` : テーブルの内部 ID。TiDB クラスター内で一意です。 -- `REPLICA_COUNT` : TiFlashレプリカの数。 -- `LOCATION_LABELS` : TiFlashレプリカが作成されるときに設定される LocationLabelList。 -- `AVAILABLE` : テーブルのTiFlashレプリカが利用可能かどうかを示します。値が`1` （利用可能）の場合、TiDB オプティマイザーはクエリコストに基づいて、クエリを TiKV またはTiFlashにプッシュダウンするかをインテリジェントに選択します。値が`0` （利用不可）の場合、TiDB はクエリをTiFlashにプッシュダウンしません。このフィールドの値が`1` （利用可能）になると、それ以上変化しなくなります。 -- `PROGRESS` : TiFlashレプリカのレプリケーションの進行状況。小数点以下2桁の精度で分単位です。このフィールドのスコープは`[0, 1]`です。`AVAILABLE`が`1`で`PROGRESS`が1未満の場合、 TiFlashレプリカはTiKVより大幅に遅れており、データレプリケーションの待機タイムアウトにより、 TiFlashにプッシュダウンされたクエリは失敗する可能性があります。 +- `TABLE_SCHEMA` : テーブルが属するデータベースの名前。 +- `TABLE_NAME` : テーブルの名前。 +- `TABLE_ID` : テーブルの内部 ID。TiDB クラスター内で一意です。 +- `REPLICA_COUNT` : TiFlashレプリカの数。 +- `LOCATION_LABELS` : TiFlashレプリカが作成されるときに設定される LocationLabelList。 +- `AVAILABLE` : テーブルのTiFlashレプリカが利用可能かどうかを示します。値が`1` （利用可能）の場合、TiDB オプティマイザーはクエリコストに基づいて、クエリを TiKV またはTiFlashにプッシュダウンするかをインテリジェントに選択します。値が`0` （利用不可）の場合、TiDB はクエリをTiFlashにプッシュダウンしません。このフィールドの値が`1` （利用可能）になると、それ以上変化しなくなります。 +- `PROGRESS` : TiFlashレプリカのレプリケーションの進行状況。小数点以下2桁の精度で分単位です。このフィールドのスコープは`[0, 1]`です。`AVAILABLE`が`1`で`PROGRESS`が1未満の場合、 TiFlashレプリカはTiKVより大幅に遅れており、データレプリケーションの待機タイムアウトにより、 TiFlashにプッシュダウンされたクエリは失敗する可能性があります。 diff --git a/information-schema/information-schema-tiflash-segments.md b/information-schema/information-schema-tiflash-segments.md index 36d390debab88..5634d0e9fe893 100644 --- a/information-schema/information-schema-tiflash-segments.md +++ b/information-schema/information-schema-tiflash-segments.md @@ -56,34 +56,34 @@ DESC tiflash_segments; `TIFLASH_SEGMENTS`テーブル内のフィールドは次のように説明されます。 -- `TIDB_DATABASE` : TiDB内のデータベース名。セグメントはこのデータベース内のテーブルに属します。 -- `TIDB_TABLE` : TiDB内のテーブル名。セグメントはこのテーブルに属します。 -- `TABLE_ID` : セグメントが属するテーブルの内部ID。このIDはTiDBクラスタ内で一意です。 -- `IS_TOMBSTONE` : セグメントが属するテーブルがリサイクル可能かどうかを示します。`1`はテーブルがリサイクル可能であることを示します。`0`はテーブルが通常の状態であることを示します。 -- `SEGMENT_ID` : テーブル内で一意のセグメント ID。 -- `RANGE` : セグメントに含まれるデータの範囲。 -- `EPOCH` : セグメントの更新バージョン。各セグメントのバージョン番号は単調に増加します。 -- `ROWS` : セグメント内の行の合計数。 -- `SIZE` : セグメント データの合計サイズ (バイト単位)。 -- `DELTA_RATE` : デルタレイヤーの合計行数とセグメントの合計行数の比率。 -- `DELTA_MEMTABLE_ROWS` : デルタレイヤーにキャッシュされた行の合計数。 -- `DELTA_MEMTABLE_SIZE` : Deltaレイヤーにキャッシュされたデータの合計サイズ (バイト単位)。 -- `DELTA_MEMTABLE_COLUMN_FILES` : デルタレイヤーにキャッシュされたカラムファイルの数。 -- `DELTA_MEMTABLE_DELETE_RANGES` : デルタレイヤーにキャッシュされた削除範囲の数。 -- `DELTA_PERSISTED_PAGE_ID` : デルタレイヤーのディスクに保存されているデータの ID。 -- `DELTA_PERSISTED_ROWS` : デルタレイヤーに保存されたデータの行の合計数。 -- `DELTA_PERSISTED_SIZE` : Deltaレイヤーに保存されたデータの合計サイズ (バイト単位)。 -- `DELTA_PERSISTED_COLUMN_FILES` : デルタレイヤー内の永続化されたカラムファイルの数。 -- `DELTA_PERSISTED_DELETE_RANGES` : デルタレイヤーに保持される削除範囲の数。 -- `DELTA_CACHE_SIZE` : Deltaレイヤーのキャッシュのサイズ (バイト単位)。 -- `DELTA_INDEX_SIZE` : Deltaレイヤー内のインデックスのサイズ (バイト単位)。 -- `STABLE_PAGE_ID` : 安定レイヤーのデータのディスクストレージID。 -- `STABLE_ROWS` : 安定レイヤー内の行の合計数。 -- `STABLE_SIZE` : 安定レイヤーのデータの合計サイズ (バイト単位)。 -- `STABLE_DMFILES` : 安定レイヤー内の DMFiles の数。 -- `STABLE_DMFILES_ID_0` : 安定レイヤーの最初の DMFile のディスクストレージID。 -- `STABLE_DMFILES_ROWS` : 安定レイヤーの DMFile 内の行の合計数。 -- `STABLE_DMFILES_SIZE` : 安定レイヤーの DMFile 内のデータの合計サイズ (バイト単位)。 -- `STABLE_DMFILES_SIZE_ON_DISK` : 安定レイヤーで DMFile が占めるディスク領域 (バイト単位)。 -- `STABLE_DMFILES_PACKS` : 安定レイヤーの DMFile 内のパックの数。 -- `TIFLASH_INSTANCE` : TiFlashインスタンスのアドレス。 +- `TIDB_DATABASE` : TiDB内のデータベース名。セグメントはこのデータベース内のテーブルに属します。 +- `TIDB_TABLE` : TiDB内のテーブル名。セグメントはこのテーブルに属します。 +- `TABLE_ID` : セグメントが属するテーブルの内部ID。このIDはTiDBクラスタ内で一意です。 +- `IS_TOMBSTONE` : セグメントが属するテーブルがリサイクル可能かどうかを示します。`1`はテーブルがリサイクル可能であることを示します。`0`はテーブルが通常の状態であることを示します。 +- `SEGMENT_ID` : テーブル内で一意のセグメント ID。 +- `RANGE` : セグメントに含まれるデータの範囲。 +- `EPOCH` : セグメントの更新バージョン。各セグメントのバージョン番号は単調に増加します。 +- `ROWS` : セグメント内の行の合計数。 +- `SIZE` : セグメント データの合計サイズ (バイト単位)。 +- `DELTA_RATE` : デルタレイヤーの合計行数とセグメントの合計行数の比率。 +- `DELTA_MEMTABLE_ROWS` : デルタレイヤーにキャッシュされた行の合計数。 +- `DELTA_MEMTABLE_SIZE` : Deltaレイヤーにキャッシュされたデータの合計サイズ (バイト単位)。 +- `DELTA_MEMTABLE_COLUMN_FILES` : デルタレイヤーにキャッシュされたカラムファイルの数。 +- `DELTA_MEMTABLE_DELETE_RANGES` : デルタレイヤーにキャッシュされた削除範囲の数。 +- `DELTA_PERSISTED_PAGE_ID` : デルタレイヤーのディスクに保存されているデータの ID。 +- `DELTA_PERSISTED_ROWS` : デルタレイヤーに保存されたデータの行の合計数。 +- `DELTA_PERSISTED_SIZE` : Deltaレイヤーに保存されたデータの合計サイズ (バイト単位)。 +- `DELTA_PERSISTED_COLUMN_FILES` : デルタレイヤー内の永続化されたカラムファイルの数。 +- `DELTA_PERSISTED_DELETE_RANGES` : デルタレイヤーに保持される削除範囲の数。 +- `DELTA_CACHE_SIZE` : Deltaレイヤーのキャッシュのサイズ (バイト単位)。 +- `DELTA_INDEX_SIZE` : Deltaレイヤー内のインデックスのサイズ (バイト単位)。 +- `STABLE_PAGE_ID` : 安定レイヤーのデータのディスクストレージID。 +- `STABLE_ROWS` : 安定レイヤー内の行の合計数。 +- `STABLE_SIZE` : 安定レイヤーのデータの合計サイズ (バイト単位)。 +- `STABLE_DMFILES` : 安定レイヤー内の DMFiles の数。 +- `STABLE_DMFILES_ID_0` : 安定レイヤーの最初の DMFile のディスクストレージID。 +- `STABLE_DMFILES_ROWS` : 安定レイヤーの DMFile 内の行の合計数。 +- `STABLE_DMFILES_SIZE` : 安定レイヤーの DMFile 内のデータの合計サイズ (バイト単位)。 +- `STABLE_DMFILES_SIZE_ON_DISK` : 安定レイヤーで DMFile が占めるディスク領域 (バイト単位)。 +- `STABLE_DMFILES_PACKS` : 安定レイヤーの DMFile 内のパックの数。 +- `TIFLASH_INSTANCE` : TiFlashインスタンスのアドレス。 diff --git a/information-schema/information-schema-tiflash-tables.md b/information-schema/information-schema-tiflash-tables.md index e2002a36d773a..971138a6147f6 100644 --- a/information-schema/information-schema-tiflash-tables.md +++ b/information-schema/information-schema-tiflash-tables.md @@ -77,55 +77,55 @@ DESC tiflash_tables; `TIFLASH_TABLES`テーブル内のフィールドは次のように説明されます。 -- `TIDB_DATABASE` : TiDB 内でテーブルが属するデータベースの名前。 -- `TIDB_TABLE` : TiDB 内のテーブルの名前。 -- `TABLE_ID` : テーブルの内部 ID。TiDB クラスター内で一意です。 -- `IS_TOMBSTONE` : テーブルがリサイクル可能かどうかを示します。`1`はテーブルがリサイクル可能であることを示し、 `0`はテーブルが通常の状態であることを示します。 -- `SEGMENT_COUNT` : テーブル内のセグメント数。セグメントはTiFlashにおけるデータ管理単位です。 -- `TOTAL_ROWS` : テーブル内の行の合計数。 -- `TOTAL_SIZE` : テーブルの合計サイズ (バイト単位)。 -- `TOTAL_DELETE_RANGES` : テーブル内の削除範囲の合計数。 -- `DELTA_RATE_ROWS` : Deltaレイヤー内のテーブルの合計行数とそのテーブルの合計行数の比率。 -- `DELTA_RATE_SEGMENTS` : テーブル内の空でないデルタレイヤーを含むセグメントの割合。 -- `DELTA_PLACED_RATE` : デルタレイヤー内のテーブルのインデックス構築が完了した行の割合。 -- `DELTA_CACHE_SIZE` : Deltaレイヤー内のテーブルのキャッシュのサイズ (バイト単位)。 -- `DELTA_CACHE_RATE` : デルタレイヤー内のテーブルのキャッシュデータの割合。 -- `DELTA_CACHE_WASTED_RATE` : デルタレイヤー内のテーブルの無効なキャッシュデータの割合。 -- `DELTA_INDEX_SIZE` : Deltaレイヤー内のインデックスによって占有されるメモリのサイズ (バイト単位)。 -- `AVG_SEGMENT_ROWS` : テーブルのすべてのセグメント内の行の平均数。 -- `AVG_SEGMENT_SIZE` : テーブルのすべてのセグメントの平均サイズ (バイト単位)。 -- `DELTA_COUNT` : テーブル内の空でないデルタレイヤーを含むセグメントの数。 -- `TOTAL_DELTA_ROWS` : デルタレイヤー内の行の合計数。 -- `TOTAL_DELTA_SIZE` : Deltaレイヤーのデータの合計サイズ (バイト単位)。 -- `AVG_DELTA_ROWS` : すべての Delta レイヤー内のデータの平均行数。 -- `AVG_DELTA_SIZE` : すべての Delta レイヤーのデータの平均サイズ (バイト単位)。 -- `AVG_DELTA_DELETE_RANGES` : すべての Delta レイヤーにおける範囲削除操作の平均数。 -- `STABLE_COUNT` : テーブル内の空でない安定レイヤーを含むセグメントの数。 -- `TOTAL_STABLE_ROWS` : すべての安定レイヤーの行の合計数。 -- `TOTAL_STABLE_SIZE` : すべての安定レイヤーのデータの合計サイズ (バイト単位)。 -- `TOTAL_STABLE_SIZE_ON_DISK` : すべての安定レイヤーのデータが占めるディスク領域 (バイト単位)。 -- `AVG_STABLE_ROWS` : すべての安定レイヤー内のデータの平均行数。 -- `AVG_STABLE_SIZE` : すべての安定レイヤーのデータの平均サイズ (バイト単位)。 -- `TOTAL_PACK_COUNT_IN_DELTA` : すべての Delta レイヤー内のカラムファイルの合計数。 -- `MAX_PACK_COUNT_IN_DELTA` : 単一の Deltaレイヤー内のカラムファイルの最大数。 -- `AVG_PACK_COUNT_IN_DELTA` : すべてのデルタ レイヤー内のカラムファイルの平均数。 -- `AVG_PACK_ROWS_IN_DELTA` : すべてのデルタ レイヤー内のすべてのカラムファイル内の行の平均数。 -- `AVG_PACK_SIZE_IN_DELTA` : すべての Delta レイヤー内のすべてのカラムファイルのデータの平均サイズ (バイト単位)。 -- `TOTAL_PACK_COUNT_IN_STABLE` : すべての安定レイヤー内のパックの合計数。 -- `AVG_PACK_COUNT_IN_STABLE` : すべての安定レイヤー内のパックの平均数。 -- `AVG_PACK_ROWS_IN_STABLE` : すべての安定レイヤー内のすべてのパック内の行の平均数。 -- `AVG_PACK_SIZE_IN_STABLE` : 安定レイヤー内のすべてのパックのデータの平均サイズ (バイト単位)。 -- `STORAGE_STABLE_NUM_SNAPSHOTS` : 安定レイヤー内のスナップショットの数。 -- `STORAGE_STABLE_OLDEST_SNAPSHOT_LIFETIME` : 安定レイヤーの最も古いスナップショットの継続時間 (秒単位)。 -- `STORAGE_STABLE_OLDEST_SNAPSHOT_THREAD_ID` : 安定レイヤーの最も古いスナップショットのスレッド ID。 -- `STORAGE_STABLE_OLDEST_SNAPSHOT_TRACING_ID` : 安定レイヤー内の最も古いスナップショットのトレース ID。 -- `STORAGE_DELTA_NUM_SNAPSHOTS` : デルタレイヤー内のスナップショットの数。 -- `STORAGE_DELTA_OLDEST_SNAPSHOT_LIFETIME` : Deltaレイヤー内の最も古いスナップショットの期間 (秒単位)。 -- `STORAGE_DELTA_OLDEST_SNAPSHOT_THREAD_ID` : デルタレイヤー内の最も古いスナップショットのスレッド ID。 -- `STORAGE_DELTA_OLDEST_SNAPSHOT_TRACING_ID` : Deltaレイヤー内の最も古いスナップショットのトレース ID。 -- `STORAGE_META_NUM_SNAPSHOTS` : メタ情報内のスナップショットの数。 -- `STORAGE_META_OLDEST_SNAPSHOT_LIFETIME` : メタ情報内の最も古いスナップショットの継続時間 (秒単位)。 -- `STORAGE_META_OLDEST_SNAPSHOT_THREAD_ID` : メタ情報内の最も古いスナップショットのスレッド ID。 -- `STORAGE_META_OLDEST_SNAPSHOT_TRACING_ID` : メタ情報内の最も古いスナップショットのトレース ID。 -- `BACKGROUND_TASKS_LENGTH` : バックグラウンドのタスク キューの長さ。 -- `TIFLASH_INSTANCE` : TiFlashインスタンスのアドレス。 +- `TIDB_DATABASE` : TiDB 内でテーブルが属するデータベースの名前。 +- `TIDB_TABLE` : TiDB 内のテーブルの名前。 +- `TABLE_ID` : テーブルの内部 ID。TiDB クラスター内で一意です。 +- `IS_TOMBSTONE` : テーブルがリサイクル可能かどうかを示します。`1`はテーブルがリサイクル可能であることを示し、 `0`はテーブルが通常の状態であることを示します。 +- `SEGMENT_COUNT` : テーブル内のセグメント数。セグメントはTiFlashにおけるデータ管理単位です。 +- `TOTAL_ROWS` : テーブル内の行の合計数。 +- `TOTAL_SIZE` : テーブルの合計サイズ (バイト単位)。 +- `TOTAL_DELETE_RANGES` : テーブル内の削除範囲の合計数。 +- `DELTA_RATE_ROWS` : Deltaレイヤー内のテーブルの合計行数とそのテーブルの合計行数の比率。 +- `DELTA_RATE_SEGMENTS` : テーブル内の空でないデルタレイヤーを含むセグメントの割合。 +- `DELTA_PLACED_RATE` : デルタレイヤー内のテーブルのインデックス構築が完了した行の割合。 +- `DELTA_CACHE_SIZE` : Deltaレイヤー内のテーブルのキャッシュのサイズ (バイト単位)。 +- `DELTA_CACHE_RATE` : デルタレイヤー内のテーブルのキャッシュデータの割合。 +- `DELTA_CACHE_WASTED_RATE` : デルタレイヤー内のテーブルの無効なキャッシュデータの割合。 +- `DELTA_INDEX_SIZE` : Deltaレイヤー内のインデックスによって占有されるメモリのサイズ (バイト単位)。 +- `AVG_SEGMENT_ROWS` : テーブルのすべてのセグメント内の行の平均数。 +- `AVG_SEGMENT_SIZE` : テーブルのすべてのセグメントの平均サイズ (バイト単位)。 +- `DELTA_COUNT` : テーブル内の空でないデルタレイヤーを含むセグメントの数。 +- `TOTAL_DELTA_ROWS` : デルタレイヤー内の行の合計数。 +- `TOTAL_DELTA_SIZE` : Deltaレイヤーのデータの合計サイズ (バイト単位)。 +- `AVG_DELTA_ROWS` : すべての Delta レイヤー内のデータの平均行数。 +- `AVG_DELTA_SIZE` : すべての Delta レイヤーのデータの平均サイズ (バイト単位)。 +- `AVG_DELTA_DELETE_RANGES` : すべての Delta レイヤーにおける範囲削除操作の平均数。 +- `STABLE_COUNT` : テーブル内の空でない安定レイヤーを含むセグメントの数。 +- `TOTAL_STABLE_ROWS` : すべての安定レイヤーの行の合計数。 +- `TOTAL_STABLE_SIZE` : すべての安定レイヤーのデータの合計サイズ (バイト単位)。 +- `TOTAL_STABLE_SIZE_ON_DISK` : すべての安定レイヤーのデータが占めるディスク領域 (バイト単位)。 +- `AVG_STABLE_ROWS` : すべての安定レイヤー内のデータの平均行数。 +- `AVG_STABLE_SIZE` : すべての安定レイヤーのデータの平均サイズ (バイト単位)。 +- `TOTAL_PACK_COUNT_IN_DELTA` : すべての Delta レイヤー内のカラムファイルの合計数。 +- `MAX_PACK_COUNT_IN_DELTA` : 単一の Deltaレイヤー内のカラムファイルの最大数。 +- `AVG_PACK_COUNT_IN_DELTA` : すべてのデルタ レイヤー内のカラムファイルの平均数。 +- `AVG_PACK_ROWS_IN_DELTA` : すべてのデルタ レイヤー内のすべてのカラムファイル内の行の平均数。 +- `AVG_PACK_SIZE_IN_DELTA` : すべての Delta レイヤー内のすべてのカラムファイルのデータの平均サイズ (バイト単位)。 +- `TOTAL_PACK_COUNT_IN_STABLE` : すべての安定レイヤー内のパックの合計数。 +- `AVG_PACK_COUNT_IN_STABLE` : すべての安定レイヤー内のパックの平均数。 +- `AVG_PACK_ROWS_IN_STABLE` : すべての安定レイヤー内のすべてのパック内の行の平均数。 +- `AVG_PACK_SIZE_IN_STABLE` : 安定レイヤー内のすべてのパックのデータの平均サイズ (バイト単位)。 +- `STORAGE_STABLE_NUM_SNAPSHOTS` : 安定レイヤー内のスナップショットの数。 +- `STORAGE_STABLE_OLDEST_SNAPSHOT_LIFETIME` : 安定レイヤーの最も古いスナップショットの継続時間 (秒単位)。 +- `STORAGE_STABLE_OLDEST_SNAPSHOT_THREAD_ID` : 安定レイヤーの最も古いスナップショットのスレッド ID。 +- `STORAGE_STABLE_OLDEST_SNAPSHOT_TRACING_ID` : 安定レイヤー内の最も古いスナップショットのトレース ID。 +- `STORAGE_DELTA_NUM_SNAPSHOTS` : デルタレイヤー内のスナップショットの数。 +- `STORAGE_DELTA_OLDEST_SNAPSHOT_LIFETIME` : Deltaレイヤー内の最も古いスナップショットの期間 (秒単位)。 +- `STORAGE_DELTA_OLDEST_SNAPSHOT_THREAD_ID` : デルタレイヤー内の最も古いスナップショットのスレッド ID。 +- `STORAGE_DELTA_OLDEST_SNAPSHOT_TRACING_ID` : Deltaレイヤー内の最も古いスナップショットのトレース ID。 +- `STORAGE_META_NUM_SNAPSHOTS` : メタ情報内のスナップショットの数。 +- `STORAGE_META_OLDEST_SNAPSHOT_LIFETIME` : メタ情報内の最も古いスナップショットの継続時間 (秒単位)。 +- `STORAGE_META_OLDEST_SNAPSHOT_THREAD_ID` : メタ情報内の最も古いスナップショットのスレッド ID。 +- `STORAGE_META_OLDEST_SNAPSHOT_TRACING_ID` : メタ情報内の最も古いスナップショットのトレース ID。 +- `BACKGROUND_TASKS_LENGTH` : バックグラウンドのタスク キューの長さ。 +- `TIFLASH_INSTANCE` : TiFlashインスタンスのアドレス。 diff --git a/information-schema/information-schema-tikv-region-peers.md b/information-schema/information-schema-tikv-region-peers.md index 1f60b75323f3c..aeb92b595a77b 100644 --- a/information-schema/information-schema-tikv-region-peers.md +++ b/information-schema/information-schema-tikv-region-peers.md @@ -52,13 +52,13 @@ WHERE `TIKV_REGION_PEERS`テーブルのフィールドは、次のように説明されます。 -- REGION_ID:リージョンID。 -- PEER_ID:リージョンピアのID。 -- STORE_ID:リージョンが配置されている TiKV ストアの ID。 -- IS_LEARNER: ピアがラーナーであるかどうか。 -- IS_LEADER: ピアがリーダーであるかどうか。 -- ステータス：ピアのステータス： - - 保留中：一時的に利用できません。 - - ダウン：オフラインになり、変換されました。このピアはサービスを提供しなくなりました。 - - 通常：正常に動作しています。 -- DOWN_SECONDS: オフライン状態が続いている時間（秒単位）。 +- REGION_ID:リージョンID。 +- PEER_ID:リージョンピアのID。 +- STORE_ID:リージョンが配置されている TiKV ストアの ID。 +- IS_LEARNER: ピアがラーナーであるかどうか。 +- IS_LEADER: ピアがリーダーであるかどうか。 +- ステータス：ピアのステータス： + - 保留中：一時的に利用できません。 + - ダウン：オフラインになり、変換されました。このピアはサービスを提供しなくなりました。 + - 通常：正常に動作しています。 +- DOWN_SECONDS: オフライン状態が続いている時間（秒単位）。 diff --git a/information-schema/information-schema-tikv-region-status.md b/information-schema/information-schema-tikv-region-status.md index 13967f5fb3c02..b695c3f7cfad9 100644 --- a/information-schema/information-schema-tikv-region-status.md +++ b/information-schema/information-schema-tikv-region-status.md @@ -48,26 +48,26 @@ DESC TIKV_REGION_STATUS; `TIKV_REGION_STATUS`テーブルの列の説明は以下のとおりです。 -- `REGION_ID` :リージョンの ID 。 -- `START_KEY` :リージョンの開始キーの値。 -- `END_KEY` :リージョンの終了キーの値。 -- `TABLE_ID` :リージョンが属するテーブルのID。 -- `DB_NAME` : `TABLE_ID`が属するデータベースの名前。 -- `TABLE_NAME` :リージョンが属するテーブルの名前。 -- `IS_INDEX` :リージョンデータがインデックスであるかどうか。0 はインデックスではないことを意味し、1 はインデックスであることを意味します。現在のリージョンにテーブルデータとインデックスデータの両方が含まれている場合、レコードの行が複数になり、 `IS_INDEX`はそれぞれ 0 と 1 になります。 -- `INDEX_ID` :リージョンが属するインデックスのID。 `IS_INDEX`が 0 の場合、この列の値は NULL になります。 -- `INDEX_NAME` :リージョンが属するインデックスの名前。 `IS_INDEX`が 0 の場合、この列の値は NULL になります。 -- `IS_PARTITION` :リージョンが属するテーブルがパーティション化されているかどうか。 -- `PARTITION_ID` :リージョンが属するテーブルがパーティション化されている場合、この列にはリージョンが属するパーティションの ID が表示されます。 -- `PARTITION_NAME` :リージョンが属するテーブルがパーティション化されている場合、この列にはリージョンが属するパーティションの名前が表示されます。 -- `EPOCH_CONF_VER` :リージョン構成のバージョン番号。ピアが追加または削除されると、バージョン番号が増加します。 -- `EPOCH_VERSION` :リージョンの現在のバージョン番号。リージョンが分割または統合されると、バージョン番号が増加します。 -- `WRITTEN_BYTES` :リージョンに書き込まれたデータ量（バイト）。 -- `READ_BYTES` :リージョンから読み取られたデータ量（バイト）。 -- `APPROXIMATE_SIZE` :リージョンのおおよそのデータサイズ (MB)。 -- `APPROXIMATE_KEYS` :リージョン内のキーのおおよその数。 -- `REPLICATIONSTATUS_STATE` :リージョンの現在のレプリケーション状態。状態は`UNKNOWN` 、 `SIMPLE_MAJORITY` 、または`INTEGRITY_OVER_LABEL`のいずれかになります。 -- `REPLICATIONSTATUS_STATEID` : `REPLICATIONSTATUS_STATE`に対応する識別子。 +- `REGION_ID` :リージョンの ID 。 +- `START_KEY` :リージョンの開始キーの値。 +- `END_KEY` :リージョンの終了キーの値。 +- `TABLE_ID` :リージョンが属するテーブルのID。 +- `DB_NAME` : `TABLE_ID`が属するデータベースの名前。 +- `TABLE_NAME` :リージョンが属するテーブルの名前。 +- `IS_INDEX` :リージョンデータがインデックスであるかどうか。0 はインデックスではないことを意味し、1 はインデックスであることを意味します。現在のリージョンにテーブルデータとインデックスデータの両方が含まれている場合、レコードの行が複数になり、 `IS_INDEX`はそれぞれ 0 と 1 になります。 +- `INDEX_ID` :リージョンが属するインデックスのID。 `IS_INDEX`が 0 の場合、この列の値は NULL になります。 +- `INDEX_NAME` :リージョンが属するインデックスの名前。 `IS_INDEX`が 0 の場合、この列の値は NULL になります。 +- `IS_PARTITION` :リージョンが属するテーブルがパーティション化されているかどうか。 +- `PARTITION_ID` :リージョンが属するテーブルがパーティション化されている場合、この列にはリージョンが属するパーティションの ID が表示されます。 +- `PARTITION_NAME` :リージョンが属するテーブルがパーティション化されている場合、この列にはリージョンが属するパーティションの名前が表示されます。 +- `EPOCH_CONF_VER` :リージョン構成のバージョン番号。ピアが追加または削除されると、バージョン番号が増加します。 +- `EPOCH_VERSION` :リージョンの現在のバージョン番号。リージョンが分割または統合されると、バージョン番号が増加します。 +- `WRITTEN_BYTES` :リージョンに書き込まれたデータ量（バイト）。 +- `READ_BYTES` :リージョンから読み取られたデータ量（バイト）。 +- `APPROXIMATE_SIZE` :リージョンのおおよそのデータサイズ (MB)。 +- `APPROXIMATE_KEYS` :リージョン内のキーのおおよその数。 +- `REPLICATIONSTATUS_STATE` :リージョンの現在のレプリケーション状態。状態は`UNKNOWN` 、 `SIMPLE_MAJORITY` 、または`INTEGRITY_OVER_LABEL`のいずれかになります。 +- `REPLICATIONSTATUS_STATEID` : `REPLICATIONSTATUS_STATE`に対応する識別子。 また、 `top confver` 、 `top read` 、 `top write`操作を、 `ORDER BY X LIMIT Y` `EPOCH_CONF_VER`列に対する`WRITTEN_BYTES`操作によって`READ_BYTES` 。 diff --git a/information-schema/information-schema-tikv-store-status.md b/information-schema/information-schema-tikv-store-status.md index 2bf4eed82ca7e..8398b6ae25288 100644 --- a/information-schema/information-schema-tikv-store-status.md +++ b/information-schema/information-schema-tikv-store-status.md @@ -47,22 +47,22 @@ DESC TIKV_STORE_STATUS; `TIKV_STORE_STATUS`テーブルの列の説明は以下のとおりです。 -- `STORE_ID` : ストアのID。 -- `ADDRESS` : ストアのアドレス。 -- `STORE_STATE` : ストア状態の識別子。これは`STORE_STATE_NAME`に対応します。 -- `STORE_STATE_NAME` : ストア状態の名前。名前は`Up` 、 `Offline` 、または`Tombstone` 。 -- `LABEL` : ストアのラベルセット。 -- `VERSION` : ストアのバージョン番号。 -- `CAPACITY` : ストアのストレージ容量。 -- `AVAILABLE` : ストアの残りのストレージ容量。 -- `LEADER_COUNT` : ストアのリーダーの数。 -- `LEADER_WEIGHT` : ストアのリーダーウェイト。 -- `LEADER_SCORE` : ストアのリーダースコア。 -- `LEADER_SIZE` : ストア上のすべてのリーダーのおおよその合計データサイズ (MB)。 -- `REGION_COUNT` : ストアのリージョン数。 -- `REGION_WEIGHT` : ストアのリージョンウェイト。 -- `REGION_SCORE` : ストアのリージョンスコア。 -- `REGION_SIZE` : ストア上のすべてのリージョンのおおよその合計データサイズ (MB)。 -- `START_TS` : ストアが開始された時のタイムスタンプ。 -- `LAST_HEARTBEAT_TS` : ストアから送信された最後のハートビートのタイムスタンプ。 -- `UPTIME` : ストアが起動してからの合計時間。 +- `STORE_ID` : ストアのID。 +- `ADDRESS` : ストアのアドレス。 +- `STORE_STATE` : ストア状態の識別子。これは`STORE_STATE_NAME`に対応します。 +- `STORE_STATE_NAME` : ストア状態の名前。名前は`Up` 、 `Offline` 、または`Tombstone` 。 +- `LABEL` : ストアのラベルセット。 +- `VERSION` : ストアのバージョン番号。 +- `CAPACITY` : ストアのストレージ容量。 +- `AVAILABLE` : ストアの残りのストレージ容量。 +- `LEADER_COUNT` : ストアのリーダーの数。 +- `LEADER_WEIGHT` : ストアのリーダーウェイト。 +- `LEADER_SCORE` : ストアのリーダースコア。 +- `LEADER_SIZE` : ストア上のすべてのリーダーのおおよその合計データサイズ (MB)。 +- `REGION_COUNT` : ストアのリージョン数。 +- `REGION_WEIGHT` : ストアのリージョンウェイト。 +- `REGION_SCORE` : ストアのリージョンスコア。 +- `REGION_SIZE` : ストア上のすべてのリージョンのおおよその合計データサイズ (MB)。 +- `START_TS` : ストアが開始された時のタイムスタンプ。 +- `LAST_HEARTBEAT_TS` : ストアから送信された最後のハートビートのタイムスタンプ。 +- `UPTIME` : ストアが起動してからの合計時間。 diff --git a/information-schema/information-schema-user-attributes.md b/information-schema/information-schema-user-attributes.md index 75c64148dd86f..73104ad0f3ffc 100644 --- a/information-schema/information-schema-user-attributes.md +++ b/information-schema/information-schema-user-attributes.md @@ -25,9 +25,9 @@ DESC user_attributes; `USER_ATTRIBUTES`テーブル内のフィールドは次のように説明されます。 -- `USER` : ユーザー名。 -- `HOST` : ユーザーがTiDBに接続できるホスト。このフィールドの値が`％`の場合、ユーザーはどのホストからでもTiDBに接続できます。 -- `ATTRIBUTE` : [`CREATE USER`](/sql-statements/sql-statement-create-user.md)または[`ALTER USER`](/sql-statements/sql-statement-alter-user.md)ステートメントで設定されるユーザーのコメントと属性。 +- `USER` : ユーザー名。 +- `HOST` : ユーザーがTiDBに接続できるホスト。このフィールドの値が`％`の場合、ユーザーはどのホストからでもTiDBに接続できます。 +- `ATTRIBUTE` : [`CREATE USER`](/sql-statements/sql-statement-create-user.md)または[`ALTER USER`](/sql-statements/sql-statement-alter-user.md)ステートメントで設定されるユーザーのコメントと属性。 次に例を示します。 diff --git a/information-schema/information-schema-user-privileges.md b/information-schema/information-schema-user-privileges.md index 3718dce1c505b..404671ea7df08 100644 --- a/information-schema/information-schema-user-privileges.md +++ b/information-schema/information-schema-user-privileges.md @@ -122,11 +122,11 @@ SELECT * FROM USER_PRIVILEGES; `USER_PRIVILEGES`テーブル内のフィールドは次のように説明されます。 -- `GRANTEE` : 許可されたユーザーの名前。形式は`'user_name'@'host_name'`です。 -- `TABLE_CATALOG` : テーブルが属するカタログの名前。この値は常に`def` 。 -- `PRIVILEGE_TYPE` : 付与する権限の種類。各行には1つの権限の種類のみが表示されます。 -- `IS_GRANTABLE` : `GRANT OPTION`権限がある場合、値は`YES`なります。それ以外の場合、値は`NO`になります。 +- `GRANTEE` : 許可されたユーザーの名前。形式は`'user_name'@'host_name'`です。 +- `TABLE_CATALOG` : テーブルが属するカタログの名前。この値は常に`def` 。 +- `PRIVILEGE_TYPE` : 付与する権限の種類。各行には1つの権限の種類のみが表示されます。 +- `IS_GRANTABLE` : `GRANT OPTION`権限がある場合、値は`YES`なります。それ以外の場合、値は`NO`になります。 ## 参照 {#see-also} -- [`SHOW GRANTS`](/sql-statements/sql-statement-show-grants.md) +- [`SHOW GRANTS`](/sql-statements/sql-statement-show-grants.md) diff --git a/information-schema/information-schema-variables-info.md b/information-schema/information-schema-variables-info.md index 52e69db16cd9f..9d4cfd417755e 100644 --- a/information-schema/information-schema-variables-info.md +++ b/information-schema/information-schema-variables-info.md @@ -45,11 +45,11 @@ SELECT * FROM variables_info ORDER BY variable_name LIMIT 3; `VARIABLES_INFO`テーブル内のフィールドは次のように説明されます。 -- `VARIABLE_NAME` : システム変数の名前。 -- `VARIABLE_SCOPE` : システム変数のスコープ。`SESSION`は 、システム変数が現在のセッションでのみ有効であることを意味します。`INSTANCE`は 、システム変数が TiDB インスタンスで有効であることを意味します。`GLOBAL`は 、システム変数が TiDB クラスターで有効であることを意味します。`NONE`は 、システム変数が TiDB クラスターで読み取り専用であることを意味します。 -- `DEFAULT_VALUE` : システム変数のデフォルト値。 -- `CURRENT_VALUE` : システム変数の現在の値。スコープに`SESSION`含まれる場合、現在のセッションでは`CURRENT_VALUE`値となります。 -- `MIN_VALUE` : システム変数に許容される最小値。システム変数が数値でない場合、 `MIN_VALUE` NULL になります。 -- `MAX_VALUE` : システム変数に許容される最大値。システム変数が数値でない場合、 `MAX_VALUE` NULL になります。 -- `POSSIBLE_VALUES` : システム変数の可能な値。システム変数が列挙型でない場合、 `POSSIBLE_VALUES` NULL になります。 -- `IS_NOOP` : システム変数が`noop`システム変数であるかどうか。 +- `VARIABLE_NAME` : システム変数の名前。 +- `VARIABLE_SCOPE` : システム変数のスコープ。`SESSION`は 、システム変数が現在のセッションでのみ有効であることを意味します。`INSTANCE`は 、システム変数が TiDB インスタンスで有効であることを意味します。`GLOBAL`は 、システム変数が TiDB クラスターで有効であることを意味します。`NONE`は 、システム変数が TiDB クラスターで読み取り専用であることを意味します。 +- `DEFAULT_VALUE` : システム変数のデフォルト値。 +- `CURRENT_VALUE` : システム変数の現在の値。スコープに`SESSION`含まれる場合、現在のセッションでは`CURRENT_VALUE`値となります。 +- `MIN_VALUE` : システム変数に許容される最小値。システム変数が数値でない場合、 `MIN_VALUE` NULL になります。 +- `MAX_VALUE` : システム変数に許容される最大値。システム変数が数値でない場合、 `MAX_VALUE` NULL になります。 +- `POSSIBLE_VALUES` : システム変数の可能な値。システム変数が列挙型でない場合、 `POSSIBLE_VALUES` NULL になります。 +- `IS_NOOP` : システム変数が`noop`システム変数であるかどうか。 diff --git a/information-schema/information-schema-views.md b/information-schema/information-schema-views.md index cf4886f9e4fc8..bb1668ab1d685 100644 --- a/information-schema/information-schema-views.md +++ b/information-schema/information-schema-views.md @@ -58,18 +58,18 @@ COLLATION_CONNECTION: utf8mb4_0900_ai_ci `VIEWS`テーブル内のフィールドは次のように説明されます。 -- `TABLE_CATALOG` : ビューが属するカタログの名前。この値は常に`def` 。 -- `TABLE_SCHEMA` : ビューが属するスキーマの名前。 -- `TABLE_NAME` : ビュー名。 -- `VIEW_DEFINITION` : ビューの定義。ビューが作成されるときに`SELECT`ステートメントによって作成されます。 -- `CHECK_OPTION` : `CHECK_OPTION`値。値の選択肢は`NONE` 、 `CASCADE` 、 `LOCAL`です。 -- `IS_UPDATABLE` : ビューに`UPDATE` / `INSERT` / `DELETE`が適用されるかどうか。TiDBでは、値は常に`NO`です。 -- `DEFINER` : ビューを作成したユーザーの名前。形式は`'user_name'@'host_name'`です。 -- `SECURITY_TYPE` : `SQL SECURITY`の値。値の選択肢は`DEFINER`と`INVOKER`です。 -- `CHARACTER_SET_CLIENT` : ビューが作成された時点の`character_set_client`セッション変数の値。 -- `COLLATION_CONNECTION` : ビューが作成された時点の`collation_connection`セッション変数の値。 +- `TABLE_CATALOG` : ビューが属するカタログの名前。この値は常に`def` 。 +- `TABLE_SCHEMA` : ビューが属するスキーマの名前。 +- `TABLE_NAME` : ビュー名。 +- `VIEW_DEFINITION` : ビューの定義。ビューが作成されるときに`SELECT`ステートメントによって作成されます。 +- `CHECK_OPTION` : `CHECK_OPTION`値。値の選択肢は`NONE` 、 `CASCADE` 、 `LOCAL`です。 +- `IS_UPDATABLE` : ビューに`UPDATE` / `INSERT` / `DELETE`が適用されるかどうか。TiDBでは、値は常に`NO`です。 +- `DEFINER` : ビューを作成したユーザーの名前。形式は`'user_name'@'host_name'`です。 +- `SECURITY_TYPE` : `SQL SECURITY`の値。値の選択肢は`DEFINER`と`INVOKER`です。 +- `CHARACTER_SET_CLIENT` : ビューが作成された時点の`character_set_client`セッション変数の値。 +- `COLLATION_CONNECTION` : ビューが作成された時点の`collation_connection`セッション変数の値。 ## 参照 {#see-also} -- [`CREATE VIEW`](/sql-statements/sql-statement-create-view.md) -- [`DROP VIEW`](/sql-statements/sql-statement-drop-view.md) +- [`CREATE VIEW`](/sql-statements/sql-statement-create-view.md) +- [`DROP VIEW`](/sql-statements/sql-statement-drop-view.md) diff --git a/join-reorder.md b/join-reorder.md index 77c721413f6b0..80b0e5eb54f91 100644 --- a/join-reorder.md +++ b/join-reorder.md @@ -15,15 +15,15 @@ SELECT * FROM t1, t2, t3 WHERE t1.a=t2.a AND t3.a=t2.a; このクエリでは、テーブルを次の 2 つの順序で結合できます。 -- t1はt2に結合し、次にt3に結合します。 -- t2はt3に結合し、次にt1に結合します。 +- t1はt2に結合し、次にt3に結合します。 +- t2はt3に結合し、次にt1に結合します。 t1 と t3 のデータ量と分布は異なるため、これら 2 つの実行順序では異なるパフォーマンスが現れる場合があります。 したがって、オプティマイザは結合順序を決定するアルゴリズムを必要とします。現在、TiDBでは以下の2つの結合したテーブルの再配置アルゴリズムが使用されています。 -- 貪欲アルゴリズム：結合に含まれるすべてのノードの中で、TiDBは行数が最も少ないテーブルを選択し、他の各テーブルとの結合結果をそれぞれ推定します。そして、結合結果が最小となるペアを選択します。その後、TiDBは同様のプロセスを繰り返し、次のラウンドに向けて他のノードを選択して結合します。このプロセスは、すべてのノードが結合を完了するまで続きます。 -- 動的計画法アルゴリズム: 結合に含まれるすべてのノード間で、TiDB は可能なすべての結合順序を列挙し、最適な結合順序を選択します。 +- 貪欲アルゴリズム：結合に含まれるすべてのノードの中で、TiDBは行数が最も少ないテーブルを選択し、他の各テーブルとの結合結果をそれぞれ推定します。そして、結合結果が最小となるペアを選択します。その後、TiDBは同様のプロセスを繰り返し、次のラウンドに向けて他のノードを選択して結合します。このプロセスは、すべてのノードが結合を完了するまで続きます。 +- 動的計画法アルゴリズム: 結合に含まれるすべてのノード間で、TiDB は可能なすべての結合順序を列挙し、最適な結合順序を選択します。 ## 例: 結合したテーブルの再配置の貪欲アルゴリズム {#example-the-greedy-algorithm-of-join-reorder} @@ -61,8 +61,8 @@ TiDBの結合したテーブルの再配置アルゴリズムの選択は、変 現在の結合したテーブルの再配置アルゴリズムには次の制限があります。 -- 結果セットの計算方法によって制限されるため、アルゴリズムでは最適な結合順序を確実に選択することはできません。 -- 結合したテーブルの再配置アルゴリズムの外部結合のサポートは、 [`tidb_enable_outer_join_reorder`](/system-variables.md#tidb_enable_outer_join_reorder-new-in-v610)システム変数によって制御されます。 -- 現在、動的計画法アルゴリズムでは、外部結合の結合したテーブルの再配置を実行できません。 +- 結果セットの計算方法によって制限されるため、アルゴリズムでは最適な結合順序を確実に選択することはできません。 +- 結合したテーブルの再配置アルゴリズムの外部結合のサポートは、 [`tidb_enable_outer_join_reorder`](/system-variables.md#tidb_enable_outer_join_reorder-new-in-v610)システム変数によって制御されます。 +- 現在、動的計画法アルゴリズムでは、外部結合の結合したテーブルの再配置を実行できません。 現在、TiDBでは結合順序を強制する`STRAIGHT_JOIN`構文がサポートされています。詳細については[構文要素の説明](/sql-statements/sql-statement-select.md#description-of-the-syntax-elements)を参照してください。 diff --git a/latency-breakdown.md b/latency-breakdown.md index a526a02c1181b..1da3a1b8daf28 100644 --- a/latency-breakdown.md +++ b/latency-breakdown.md @@ -7,12 +7,12 @@ summary: TiDB のレイテンシーと、実際の使用例でレイテンシー このドキュメントでは、レイテンシーをメトリックに分解し、次の側面からユーザーの観点から分析します。 -- [一般的なSQLレイヤー](#general-sql-layer) -- [クエリを読む](#read-queries) -- [クエリを書く](#write-queries) -- [バッチクライアント](#batch-client) -- [TiKVスナップショット](#tikv-snapshot) -- [非同期書き込み](#async-write) +- [一般的なSQLレイヤー](#general-sql-layer) +- [クエリを読む](#read-queries) +- [クエリを書く](#write-queries) +- [バッチクライアント](#batch-client) +- [TiKVスナップショット](#tikv-snapshot) +- [非同期書き込み](#async-write) これらの分析により、 TiDB SQLクエリの実行時間コストに関する詳細な情報が得られます。これは、TiDBのクリティカルパス診断のガイドです。さらに、[診断のユースケース](#diagnosis-use-cases)セクションでは、実際のユースケースにおけるレイテンシーの分析方法を紹介します。 @@ -64,10 +64,10 @@ e2e duration = tidb_session_execute_duration_seconds{type="general"} ``` -- `tidb_server_get_token_duration_seconds`はトークンの待機時間を記録します。これは通常1ミリ秒未満であり、無視できるほど小さい値です。 -- `tidb_session_parse_duration_seconds`はSQL クエリを抽象構文ツリー (AST) に解析する時間を記録します。これは[`PREPARE/EXECUTE`ステートメント](/develop/dev-guide-optimize-sql-best-practices.md#use-prepare)でスキップできます。 -- `tidb_session_compile_duration_seconds`はAST を実行計画にコンパイルする時間を記録し、これは[SQL プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)でスキップできます。 -- `tidb_session_execute_duration_seconds{type="general"}`は実行時間を記録しますが、これにはあらゆる種類のユーザークエリが混在します。パフォーマンスの問題やボトルネックを分析するには、これを細分化した期間に分割する必要があります。 +- `tidb_server_get_token_duration_seconds`はトークンの待機時間を記録します。これは通常1ミリ秒未満であり、無視できるほど小さい値です。 +- `tidb_session_parse_duration_seconds`はSQL クエリを抽象構文ツリー (AST) に解析する時間を記録します。これは[`PREPARE/EXECUTE`ステートメント](/develop/dev-guide-optimize-sql-best-practices.md#use-prepare)でスキップできます。 +- `tidb_session_compile_duration_seconds`はAST を実行計画にコンパイルする時間を記録し、これは[SQL プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)でスキップできます。 +- `tidb_session_execute_duration_seconds{type="general"}`は実行時間を記録しますが、これにはあらゆる種類のユーザークエリが混在します。パフォーマンスの問題やボトルネックを分析するには、これを細分化した期間に分割する必要があります。 一般的に、OLTP（オンライントランザクション処理）ワークロードは、重要なコードを共有する読み取りクエリと書き込みクエリに分けられます。以下のセクションでは、実行方法が異なる[読み取りクエリ](#read-queries)と[クエリを書く](#write-queries)のレイテンシーについて説明します。 @@ -315,9 +315,9 @@ Diagram( 書き込みクエリは次の 3 つのフェーズに分かれています。 -- 実行フェーズ: 変更を実行し、TiDB のメモリに書き込みます。 -- ロックフェーズ: 実行結果に対して悲観的ロックを取得します。 -- コミット フェーズ: 2 フェーズ コミット プロトコル (2PC) を使用してトランザクションをコミットします。 +- 実行フェーズ: 変更を実行し、TiDB のメモリに書き込みます。 +- ロックフェーズ: 実行結果に対して悲観的ロックを取得します。 +- コミット フェーズ: 2 フェーズ コミット プロトコル (2PC) を使用してトランザクションをコミットします。 実行フェーズでは、TiDBはメモリ内のデータを操作します。主なレイテンシーは必要なデータの読み取りに起因します。更新クエリと削除クエリの場合、TiDBはまずTiKVからデータを読み取り、次にメモリ内の行を更新または削除します。 @@ -421,11 +421,11 @@ 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)セクションを参照してください。 +- `tikv_storage_engine_async_request_duration_seconds{type="snapshot"}`はスナップショットタイプの期間です。詳細については、 [TiKVスナップショット](#tikv-snapshot)セクションを参照してください。 -- `lock in-mem key count`と`lock on-disk key count`は次のように計算されます。 +- `lock in-mem key count`と`lock on-disk key count`は次のように計算されます。 ```text lock in-mem key count = @@ -444,7 +444,7 @@ tikv_grpc_msg_duration_seconds{type="kv_pessimistic_lock"} = sum(rate(tikv_storage_rocksdb_perf{metric="block_read_time",req="acquire_pessimistic_lock"})) / sum(rate(tikv_storage_rocksdb_perf{metric="block_read_count",req="acquire_pessimistic_lock"})) ``` -- `lock write duration`はディスク上の書き込みロックの持続時間です。詳細については、 [非同期書き込み](#async-write)セクションを参照してください。 +- `lock write duration`はディスク上の書き込みロックの持続時間です。詳細については、 [非同期書き込み](#async-write)セクションを参照してください。 ### コミット {#commit} @@ -522,10 +522,10 @@ Commit_time = コミット期間は、次の 4 つの指標に分類できます。 -- `Get_latest_ts_time`は、非同期コミットまたはシングル フェーズ コミット (1PC) トランザクションで最新の TSO を取得するのにかかる時間を記録します。 -- `Prewrite_time`は事前書き込みフェーズの期間を記録します。 -- `Get_commit_ts_time`は、一般的な 2PC トランザクションの期間を記録します。 -- `Commit_time`はコミットフェーズの所要時間を記録します。非同期コミットまたは1PCトランザクションにはこのフェーズはありません。 +- `Get_latest_ts_time`は、非同期コミットまたはシングル フェーズ コミット (1PC) トランザクションで最新の TSO を取得するのにかかる時間を記録します。 +- `Prewrite_time`は事前書き込みフェーズの期間を記録します。 +- `Get_commit_ts_time`は、一般的な 2PC トランザクションの期間を記録します。 +- `Commit_time`はコミットフェーズの所要時間を記録します。非同期コミットまたは1PCトランザクションにはこのフェーズはありません。 悲観的ロックと同様に、フロー制御はレイテンシー(前の式の`prewrite_round`と`commit_round` ) の増幅として機能します。 @@ -608,11 +608,11 @@ Diagram( ) ``` -- リクエストの送信にかかる全体的な所要時間は`tidb_tikvclient_request_seconds`と測定されます。 -- RPC クライアントは各ストアへの接続プール (ConnArray という名前) を維持し、各プールにはバッチ要求 (送信) チャネルを持つ BatchConn があります。 -- ストアが TiKV であり、バッチ サイズが正の場合、バッチが有効になります。これはほとんどの場合に当てはまります。 -- バッチ要求チャネルのサイズは[`tikv-client.max-batch-size`](/tidb-configuration-file.md#max-batch-size) (デフォルトは`128` ) で、エンキューの期間は`tidb_tikvclient_batch_wait_duration`として観測されます。 -- ストリーム要求には`CmdBatchCop` 、 `CmdCopStream` 、 `CmdMPPConn` 3 種類があり、ストリームから最初の応答を取得するために追加の`recv()`呼び出しが必要になります。 +- リクエストの送信にかかる全体的な所要時間は`tidb_tikvclient_request_seconds`と測定されます。 +- RPC クライアントは各ストアへの接続プール (ConnArray という名前) を維持し、各プールにはバッチ要求 (送信) チャネルを持つ BatchConn があります。 +- ストアが TiKV であり、バッチ サイズが正の場合、バッチが有効になります。これはほとんどの場合に当てはまります。 +- バッチ要求チャネルのサイズは[`tikv-client.max-batch-size`](/tidb-configuration-file.md#max-batch-size) (デフォルトは`128` ) で、エンキューの期間は`tidb_tikvclient_batch_wait_duration`として観測されます。 +- ストリーム要求には`CmdBatchCop` 、 `CmdCopStream` 、 `CmdMPPConn` 3 種類があり、ストリームから最初の応答を取得するために追加の`recv()`呼び出しが必要になります。 まだいくらかのレイテンシーが観測されていますが、 `tidb_tikvclient_request_seconds`は次のように概算できます。 @@ -624,10 +624,10 @@ tidb_tikvclient_request_seconds{type="?"} = tidb_tikvclient_rpc_net_latency_seconds{store="?"} ``` -- `tidb_tikvclient_batch_wait_duration`はバッチ システムでの待機期間を記録します。 -- `tidb_tikvclient_batch_send_latency`はバッチ システムでのエンコード期間を記録します。 -- `tikv_grpc_msg_duration_seconds{type="kv_?"}`は TiKV 処理期間です。 -- `tidb_tikvclient_rpc_net_latency_seconds`はネットワークレイテンシーを記録します。 +- `tidb_tikvclient_batch_wait_duration`はバッチ システムでの待機期間を記録します。 +- `tidb_tikvclient_batch_send_latency`はバッチ システムでのエンコード期間を記録します。 +- `tikv_grpc_msg_duration_seconds{type="kv_?"}`は TiKV 処理期間です。 +- `tidb_tikvclient_rpc_net_latency_seconds`はネットワークレイテンシーを記録します。 ## TiKVスナップショット {#tikv-snapshot} @@ -665,7 +665,7 @@ RocksDB からスナップショットを取得する操作は通常は高速な 非同期書き込みは、TiKV がコールバックを使用して Raft ベースの複製されたステート マシンに非同期的にデータを書き込むプロセスです。 -- 以下は、非同期 IO が無効になっている場合の非同期書き込み操作の時間コスト図です。 +- 以下は、非同期 IO が無効になっている場合の非同期書き込み操作の時間コスト図です。 ```railroad+diagram Diagram( @@ -687,7 +687,7 @@ RocksDB からスナップショットを取得する操作は通常は高速な ) ``` -- 以下は、非同期 IO が有効な場合の非同期書き込み操作の時間コスト図です。 +- 以下は、非同期 IO が有効な場合の非同期書き込み操作の時間コスト図です。 ```railroad+diagram Diagram( @@ -724,9 +724,9 @@ async write duration(async io enabled) = 非同期書き込みは次の 3 つのフェーズに分けられます。 -- 提案 -- コミット -- 適用：上記の式に`tikv_raftstore_apply_wait_time_duration_secs + tikv_raftstore_apply_log_duration_seconds`を代入する +- 提案 +- コミット +- 適用：上記の式に`tikv_raftstore_apply_wait_time_duration_secs + tikv_raftstore_apply_log_duration_seconds`を代入する 提案フェーズの期間は次のように計算されます。 @@ -871,7 +871,7 @@ tikv_raftstore_apply_log_duration_seconds = 書き込み速度が遅い原因を調査する前に、 `tikv_scheduler_latch_wait_duration_seconds_sum{type="acquire_pessimistic_lock"} by (instance)`を確認して競合の原因をトラブルシューティングする必要があります。 -- 特定の TiKV インスタンスでこのメトリックが高い場合、ホットなリージョンで競合が発生している可能性があります。 -- このメトリックがすべてのインスタンスにわたって高い場合、アプリケーションに競合が発生している可能性があります。 +- 特定の TiKV インスタンスでこのメトリックが高い場合、ホットなリージョンで競合が発生している可能性があります。 +- このメトリックがすべてのインスタンスにわたって高い場合、アプリケーションに競合が発生している可能性があります。 アプリケーションからの競合の原因を確認した後、 [ロック](#lock)と[コミット](#commit)期間を分析することで、遅い書き込みクエリを調査できます。 diff --git a/literal-values.md b/literal-values.md index f2ed995a4ba0e..b023f28e1beae 100644 --- a/literal-values.md +++ b/literal-values.md @@ -30,8 +30,8 @@ TiDBのリテラル値には、文字リテラル、数値リテラル、時刻 文字列は次の 2 つのタイプに分かれます。 -- バイナリ文字列: 文字セットと照合順序が両方とも`binary`あるバイトのシーケンスで構成され、比較の単位として**バイト**を使用します。 -- 非バイナリ文字列: 文字のシーケンスで構成され、 `binary`以外の様々な文字セットと照合順序を持ちます。非バイナリ文字列は、**文字を**単位として互いに比較されます。文字セットによっては、1文字に複数のバイトが含まれる場合があります。 +- バイナリ文字列: 文字セットと照合順序が両方とも`binary`あるバイトのシーケンスで構成され、比較の単位として**バイト**を使用します。 +- 非バイナリ文字列: 文字のシーケンスで構成され、 `binary`以外の様々な文字セットと照合順序を持ちます。非バイナリ文字列は、**文字を**単位として互いに比較されます。文字セットによっては、1文字に複数のバイトが含まれる場合があります。 文字列リテラルにはオプションの`character set introducer`と`COLLATE clause`があり、特定の文字セットと照合順序を使用する文字列として指定できます。 @@ -93,31 +93,31 @@ SELECT _utf8'some text'; TiDB は次の日付形式をサポートしています。 -- `'YYYY-MM-DD'`または`'YY-MM-DD'` : ここでの`-`という区切り文字は厳密ではありません。任意の句読点を使用できます。例えば、 `'2017-08-24'` 、 `'2017&08&24'` 、 `'2012@12^31'`はすべて有効な日付形式です。唯一の特別な句読点は「.」で、これは整数部と小数部を区切る小数点として扱われます。日付と時刻は`T`または空白で区切ることができます。例えば、 `2017-8-24 10:42:00`と`2017-8-24T10:42:00`は同じ日付と時刻を表します。 -- `'YYYYMMDDHHMMSS'`または`'YYMMDDHHMMSS'` : 例えば、 `'20170824104520'`と`'170824104520'`は`'2017-08-24 10:45:20'`とみなされます。ただし、 `'170824304520'`など範囲外の値を指定した場合、有効な日付として扱われません。 `YYYYMMDD HHMMSS` 、 `YYYYMMDD HH:MM:DD` 、 `YYYY-MM-DD HHMMSS`などの誤った形式は挿入に失敗することに注意してください。 -- `YYYYMMDDHHMMSS`または`YYMMDDHHMMSS` : これらの形式では、一重引用符や二重引用符は使用されず、数字が使用されることに注意してください。例えば、 `20170824104520`は`'2017-08-24 10:45:20'`と解釈されます。 +- `'YYYY-MM-DD'`または`'YY-MM-DD'` : ここでの`-`という区切り文字は厳密ではありません。任意の句読点を使用できます。例えば、 `'2017-08-24'` 、 `'2017&08&24'` 、 `'2012@12^31'`はすべて有効な日付形式です。唯一の特別な句読点は「.」で、これは整数部と小数部を区切る小数点として扱われます。日付と時刻は`T`または空白で区切ることができます。例えば、 `2017-8-24 10:42:00`と`2017-8-24T10:42:00`は同じ日付と時刻を表します。 +- `'YYYYMMDDHHMMSS'`または`'YYMMDDHHMMSS'` : 例えば、 `'20170824104520'`と`'170824104520'`は`'2017-08-24 10:45:20'`とみなされます。ただし、 `'170824304520'`など範囲外の値を指定した場合、有効な日付として扱われません。 `YYYYMMDD HHMMSS` 、 `YYYYMMDD HH:MM:DD` 、 `YYYY-MM-DD HHMMSS`などの誤った形式は挿入に失敗することに注意してください。 +- `YYYYMMDDHHMMSS`または`YYMMDDHHMMSS` : これらの形式では、一重引用符や二重引用符は使用されず、数字が使用されることに注意してください。例えば、 `20170824104520`は`'2017-08-24 10:45:20'`と解釈されます。 DATETIME または TIMESTAMP 値の後には、マイクロ秒単位の精度（6桁）を表す小数部が続きます。小数部は、常に小数点`.`で残りの時間と区切る必要があります。 2桁のみの年値は曖昧です。4桁の年形式を使用することをお勧めします。TiDBは2桁の年値を以下の規則に従って解釈します。 -- 年値が`70-99`の範囲内にある場合は`1970-1999`に変換されます。 -- 年値が`00-69`の範囲内にある場合は`2000-2069`に変換されます。 +- 年値が`70-99`の範囲内にある場合は`1970-1999`に変換されます。 +- 年値が`00-69`の範囲内にある場合は`2000-2069`に変換されます。 月または日が10未満の場合は、 `'2017-8-4'`は`'2017-08-04'`と同じです。時間についても同様です。例えば、 `'2017-08-24 1:2:3'`は`'2017-08-24 01:02:03'`と同じです。 日付または時刻の値が必要な場合、TiDB は値の長さに応じて指定された形式を選択します。 -- 6桁: `YYMMDD` 。 -- 12桁: `YYMMDDHHMMSS` 。 -- 8桁: `YYYYMMDD` 。 -- 14桁: `YYYYMMDDHHMMSS` 。 +- 6桁: `YYMMDD` 。 +- 12桁: `YYMMDDHHMMSS` 。 +- 8桁: `YYYYMMDD` 。 +- 14桁: `YYYYMMDDHHMMSS` 。 TiDB は、時間値に対して次の形式をサポートしています。 -- `'D HH:MM:SS'` 、または`'HH:MM:SS'` 、 `'HH:MM'` 、 `'D HH:MM'` 、 `'D HH'` 、 `'SS'` : `D`は日数を意味し、有効な値の範囲は`0-34`です。 -- `HHMMSS`形式の数値: たとえば、 `231010`は`'23:10:10'`として解釈されます。 -- `SS` 、 `MMSS` 、 `HHMMSS`のいずれかの形式の数字は時間としてみなすことができます。 +- `'D HH:MM:SS'` 、または`'HH:MM:SS'` 、 `'HH:MM'` 、 `'D HH:MM'` 、 `'D HH'` 、 `'SS'` : `D`は日数を意味し、有効な値の範囲は`0-34`です。 +- `HHMMSS`形式の数値: たとえば、 `231010`は`'23:10:10'`として解釈されます。 +- `SS` 、 `MMSS` 、 `HHMMSS`のいずれかの形式の数字は時間としてみなすことができます。 Time 型の小数点も`.`で、小数点以下の精度は最大 6 桁になります。 diff --git a/maintain-tidb-using-tiup.md b/maintain-tidb-using-tiup.md index f12d9767e1199..6682a22b8e97e 100644 --- a/maintain-tidb-using-tiup.md +++ b/maintain-tidb-using-tiup.md @@ -35,13 +35,13 @@ tiup cluster start ${cluster-name} コマンドに`-R`または`-N`パラメータを追加することで、一部のコンポーネントのみを起動できます。例： -- このコマンドは PDコンポーネントのみを起動します。 +- このコマンドは PDコンポーネントのみを起動します。 ```bash tiup cluster start ${cluster-name} -R pd ``` -- このコマンドは、ホスト`1.2.3.4`と`1.2.3.5`のPDコンポーネントのみを起動します。 +- このコマンドは、ホスト`1.2.3.4`と`1.2.3.5`のPDコンポーネントのみを起動します。 ```bash tiup cluster start ${cluster-name} -N 1.2.3.4:2379,1.2.3.5:2379 @@ -63,15 +63,15 @@ tiup cluster display ${cluster-name} クラスタの稼働中にコンポーネントのパラメータを変更する必要がある場合は、コマンド`edit-config`を実行してください。詳細な手順は次のとおりです。 -1. クラスターの構成ファイルを編集モードで開きます。 +1. クラスターの構成ファイルを編集モードで開きます。 ```bash tiup cluster edit-config ${cluster-name} ``` -2. パラメータを設定します。 +2. パラメータを設定します。 - - 構成がコンポーネントに対してグローバルに有効な場合は、 `server_configs`を編集します。 + - 構成がコンポーネントに対してグローバルに有効な場合は、 `server_configs`を編集します。 ``` server_configs: @@ -79,7 +79,7 @@ tiup cluster display ${cluster-name} log.slow-threshold: 300 ``` - - 特定のノードで設定を有効にする場合は、ノードの`config`で設定を編集します。 + - 特定のノードで設定を有効にする場合は、ノードの`config`で設定を編集します。 ``` tidb_servers: @@ -95,7 +95,7 @@ tiup cluster display ${cluster-name} コンポーネントの構成パラメータの詳細については、 [TiDB `config.toml.example`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/config/config.toml.example) 、 [TiKV `config.toml.example`](https://github.com/tikv/tikv/blob/release-8.5/etc/config-template.toml) 、および[PD `config.toml.example`](https://github.com/tikv/pd/blob/release-8.5/conf/config.toml)を参照してください。 -3. `reload`コマンドを実行して、構成をローリング更新し、対応するコンポーネントを再起動します。 +3. `reload`コマンドを実行して、構成をローリング更新し、対応するコンポーネントを再起動します。 ```bash tiup cluster reload ${cluster-name} [-N ] [-R ] @@ -164,8 +164,8 @@ tiup cluster rename ${cluster-name} ${new-name} > **Note:** > -> - クラスターの名前を変更する操作により、監視システム (Prometheus および Grafana) が再起動されます。 -> - クラスターの名前を変更した後、古いクラスター名を持つパネルがGrafanaに残る場合があります。これらのパネルは手動で削除する必要があります。 +> - クラスターの名前を変更する操作により、監視システム (Prometheus および Grafana) が再起動されます。 +> - クラスターの名前を変更した後、古いクラスター名を持つパネルがGrafanaに残る場合があります。これらのパネルは手動で削除する必要があります。 ## クラスターを停止する {#stop-the-cluster} @@ -181,13 +181,13 @@ tiup cluster stop ${cluster-name} `start`コマンドと同様に、 `stop`コマンドでも`-R`または`-N`パラメータを追加することで、一部のコンポーネントを停止できます。例: -- このコマンドは TiDBコンポーネントのみを停止します。 +- このコマンドは TiDBコンポーネントのみを停止します。 ```bash tiup cluster stop ${cluster-name} -R tidb ``` -- このコマンドは、ホスト`1.2.3.4`と`1.2.3.5`の TiDB コンポーネントのみを停止します。 +- このコマンドは、ホスト`1.2.3.4`と`1.2.3.5`の TiDB コンポーネントのみを停止します。 ```bash tiup cluster stop ${cluster-name} -N 1.2.3.4:4000,1.2.3.5:4000 @@ -197,37 +197,37 @@ tiup cluster stop ${cluster-name} クラスタデータのクリーンアップ操作では、すべてのサービスが停止し、データディレクトリまたはログディレクトリがクリーンアップされます。この操作は元に戻すことができませんので、**慎重に**進めてください。 -- クラスター内のすべてのサービスのデータをクリーンアップしますが、ログは保持します。 +- クラスター内のすべてのサービスのデータをクリーンアップしますが、ログは保持します。 ```bash tiup cluster clean ${cluster-name} --data ``` -- クラスター内のすべてのサービスのログをクリーンアップしますが、データは保持します。 +- クラスター内のすべてのサービスのログをクリーンアップしますが、データは保持します。 ```bash tiup cluster clean ${cluster-name} --log ``` -- クラスター内のすべてのサービスのデータとログをクリーンアップします。 +- クラスター内のすべてのサービスのデータとログをクリーンアップします。 ```bash tiup cluster clean ${cluster-name} --all ``` -- Prometheus 以外のすべてのサービスのログとデータをクリーンアップします。 +- Prometheus 以外のすべてのサービスのログとデータをクリーンアップします。 ```bash tiup cluster clean ${cluster-name} --all --ignore-role prometheus ``` -- `172.16.13.11:9000`インスタンスを除くすべてのサービスのログとデータをクリーンアップします。 +- `172.16.13.11:9000`インスタンスを除くすべてのサービスのログとデータをクリーンアップします。 ```bash tiup cluster clean ${cluster-name} --all --ignore-node 172.16.13.11:9000 ``` -- `172.16.13.12`ノードを除くすべてのサービスのログとデータをクリーンアップします。 +- `172.16.13.12`ノードを除くすべてのサービスのログとデータをクリーンアップします。 ```bash tiup cluster clean ${cluster-name} --all --ignore-node 172.16.13.12 @@ -272,13 +272,13 @@ grafana_servers: #### VictoriaMetrics リモート書き込みを有効にする {#enable-victoriametrics-remote-write} -1. クラスター構成を編集します。 +1. クラスター構成を編集します。 ```bash tiup cluster edit-config ${cluster-name} ``` -2. `monitoring_servers`の下で`prom_remote_write_to_vm`を`true`に設定します: +2. `monitoring_servers`の下で`prom_remote_write_to_vm`を`true`に設定します: ```yaml monitoring_servers: @@ -287,7 +287,7 @@ grafana_servers: prom_remote_write_to_vm: true ``` -3. 変更を適用するには、構成を再ロードします。 +3. 変更を適用するには、構成を再ロードします。 ```bash tiup cluster reload ${cluster-name} -R prometheus @@ -295,13 +295,13 @@ grafana_servers: #### デフォルトのデータソースをVictoriaMetricsに切り替える {#switch-the-default-data-source-to-victoriametrics} -1. クラスター構成を編集します。 +1. クラスター構成を編集します。 ```bash tiup cluster edit-config ${cluster-name} ``` -2. `grafana_servers`の下で`use_vm_as_datasource`を`true`に設定します: +2. `grafana_servers`の下で`use_vm_as_datasource`を`true`に設定します: ```yaml grafana_servers: @@ -310,7 +310,7 @@ grafana_servers: use_vm_as_datasource: true ``` -3. 変更を適用するには、構成を再ロードします。 +3. 変更を適用するには、構成を再ロードします。 ```bash tiup cluster reload ${cluster-name} -R grafana @@ -320,13 +320,13 @@ grafana_servers: 切り替え前に生成された履歴メトリックを表示する必要がある場合は、次のように Grafana のデータ ソースを切り替えます。 -1. クラスター構成を編集します。 +1. クラスター構成を編集します。 ```bash tiup cluster edit-config ${cluster-name} ``` -2. `grafana_servers`の下で、 `use_vm_as_datasource`をコメントアウトします。 +2. `grafana_servers`の下で、 `use_vm_as_datasource`をコメントアウトします。 ```yaml grafana_servers: @@ -335,13 +335,13 @@ grafana_servers: # use_vm_as_datasource: true ``` -3. 変更を適用するには、構成をリロードします。 +3. 変更を適用するには、構成をリロードします。 ```bash tiup cluster reload ${cluster-name} -R grafana ``` -4. VictoriaMetrics に戻るには、 [デフォルトのデータソースをVictoriaMetricsに切り替える](#switch-the-default-data-source-to-victoriametrics)の手順を繰り返します。 +4. VictoriaMetrics に戻るには、 [デフォルトのデータソースをVictoriaMetricsに切り替える](#switch-the-default-data-source-to-victoriametrics)の手順を繰り返します。 ### 古い指標とサービスをクリーンアップする {#clean-up-old-metrics-and-services} @@ -349,13 +349,13 @@ grafana_servers: #### Prometheusをエージェントモードに設定する {#set-prometheus-to-agent-mode} -1. クラスター構成を編集します。 +1. クラスター構成を編集します。 ```bash tiup cluster edit-config ${cluster-name} ``` -2. `monitoring_servers`の下で、 `enable_prom_agent_mode`を`true`に設定し、 `prom_remote_write_to_vm`と`use_vm_as_datasource`が正しく設定されていることを確認します。 +2. `monitoring_servers`の下で、 `enable_prom_agent_mode`を`true`に設定し、 `prom_remote_write_to_vm`と`use_vm_as_datasource`が正しく設定されていることを確認します。 ```yaml monitoring_servers: @@ -369,7 +369,7 @@ grafana_servers: use_vm_as_datasource: true ``` -3. 変更を適用するには、構成をリロードします。 +3. 変更を適用するには、構成をリロードします。 ```bash tiup cluster reload ${cluster-name} -R prometheus @@ -377,7 +377,7 @@ grafana_servers: #### 期限切れのデータディレクトリを削除する {#remove-expired-data-directories} -1. 設定ファイルで、監視サーバーの`data_dir`パスを見つけます。 +1. 設定ファイルで、監視サーバーの`data_dir`パスを見つけます。 ```yaml monitoring_servers: @@ -386,7 +386,7 @@ grafana_servers: data_dir: "/tidb-data/prometheus-8249" ``` -2. データディレクトリを削除します。 +2. データディレクトリを削除します。 ```bash rm -rf /tidb-data/prometheus-8249 diff --git a/max-min-eliminate.md b/max-min-eliminate.md index 3545efaa45094..396caae40ea2f 100644 --- a/max-min-eliminate.md +++ b/max-min-eliminate.md @@ -9,15 +9,15 @@ SQL文に`max` `min`関数が含まれている場合、クエリオプティマ この最適化ルールは`min` `select`ステートメント内の`max`関数の数に応じて次の 2 つのタイプに分けられます。 -- [`max` / `min`関数が1つだけあるステートメント](#one-maxmin-function) -- [複数の`max` / `min`関数を含むステートメント](#multiple-maxmin-functions) +- [`max` / `min`関数が1つだけあるステートメント](#one-maxmin-function) +- [複数の`max` / `min`関数を含むステートメント](#multiple-maxmin-functions) ## 1つの`max` / `min`関数 {#one-maxmin-function} SQL ステートメントが次の条件を満たす場合、このルールが適用されます。 -- ステートメントには、 `max`または`min`集計関数が 1 つだけ含まれています。 -- 集計関数には関連する`group by`節がありません。 +- ステートメントには、 `max`または`min`集計関数が 1 つだけ含まれています。 +- 集計関数には関連する`group by`節がありません。 例えば： @@ -53,9 +53,9 @@ mysql> explain select max(a) from t; SQL ステートメントが次の条件を満たす場合、このルールが適用されます。 -- ステートメントには複数の集計関数が含まれており、それらはすべて`max`または`min`関数です。 -- 集計関数には関連する`group by`句がありません。 -- 各`max`関数の列には順序を維持するためのインデックス`min`あります。 +- ステートメントには複数の集計関数が含まれており、それらはすべて`max`または`min`関数です。 +- 集計関数には関連する`group by`句がありません。 +- 各`max`関数の列には順序を維持するためのインデックス`min`あります。 例えば： diff --git a/metadata-lock.md b/metadata-lock.md index 43ebc2cc94976..b2f21630ff555 100644 --- a/metadata-lock.md +++ b/metadata-lock.md @@ -17,22 +17,22 @@ TiDBは、オンライン非同期スキーマ変更アルゴリズムを使用 TiDB のメタデータ ロックは、次のようなすべての DDL ステートメントに適用されます。 -- [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) -- [`ADD COLUMN`](/sql-statements/sql-statement-add-column.md) -- [`DROP COLUMN`](/sql-statements/sql-statement-drop-column.md) -- [`DROP INDEX`](/sql-statements/sql-statement-drop-index.md) -- [`DROP PARTITION`](/partitioned-table.md#partition-management) -- [`TRUNCATE TABLE`](/sql-statements/sql-statement-truncate.md) -- [`EXCHANGE PARTITION`](/partitioned-table.md#partition-management) -- [`REORGANIZE PARTITION`](/partitioned-table.md#partition-management) -- [`CHANGE COLUMN`](/sql-statements/sql-statement-change-column.md) -- [`MODIFY COLUMN`](/sql-statements/sql-statement-modify-column.md) +- [`ADD INDEX`](/sql-statements/sql-statement-add-index.md) +- [`ADD COLUMN`](/sql-statements/sql-statement-add-column.md) +- [`DROP COLUMN`](/sql-statements/sql-statement-drop-column.md) +- [`DROP INDEX`](/sql-statements/sql-statement-drop-index.md) +- [`DROP PARTITION`](/partitioned-table.md#partition-management) +- [`TRUNCATE TABLE`](/sql-statements/sql-statement-truncate.md) +- [`EXCHANGE PARTITION`](/partitioned-table.md#partition-management) +- [`REORGANIZE PARTITION`](/partitioned-table.md#partition-management) +- [`CHANGE COLUMN`](/sql-statements/sql-statement-change-column.md) +- [`MODIFY COLUMN`](/sql-statements/sql-statement-modify-column.md) メタデータロックを有効にすると、TiDBにおけるDDLタスクの実行にパフォーマンスへの影響が出る可能性があります。この影響を軽減するために、メタデータロックを必要としないシナリオをいくつか以下に示します。 -- 自動コミットが有効になっているクエリは`SELECT` -- ステイル読み取りが有効になっています -- 一時テーブルにアクセスする +- 自動コミットが有効になっているクエリは`SELECT` +- ステイル読み取りが有効になっています +- 一時テーブルにアクセスする ## 使用法 {#usage} @@ -40,9 +40,9 @@ TiDB v6.5.0以降、メタデータロックはデフォルトで有効になり ## インパクト {#impact} -- DML の場合、メタデータ ロックは実行をブロックせず、デッドロックも発生しません。 -- メタデータ ロックを有効にすると、トランザクション内のメタデータ オブジェクトの情報は最初のアクセス時に決定され、その後は変更されません。 -- DDLの場合、メタデータの状態を変更すると、古いトランザクションによってDDLがブロックされる可能性があります。以下に例を示します。 +- DML の場合、メタデータ ロックは実行をブロックせず、デッドロックも発生しません。 +- メタデータ ロックを有効にすると、トランザクション内のメタデータ オブジェクトの情報は最初のアクセス時に決定され、その後は変更されません。 +- DDLの場合、メタデータの状態を変更すると、古いトランザクションによってDDLがブロックされる可能性があります。以下に例を示します。 | セッション1 | セッション2 | | :----------------------------------------------------------------------------------------- | :--------------------------------------------------------- | @@ -134,5 +134,5 @@ TiDBにおけるDDL操作はオンラインDDLモードです。DDL文の実行 メタデータロックは、TiDBクラスタ内のすべてのトランザクションで使用されるメタデータのバージョン差が最大1バージョン以内であることを保証できます。この目的を達成するために、TiDBは次の2つのルールを実装しています。 -- DMLを実行すると、TiDBはトランザクションコンテキスト内でDMLによってアクセスされたメタデータオブジェクト（テーブル、ビュー、対応するメタデータバージョンなど）を記録します。これらのレコードは、トランザクションがコミットされるとクリーンアップされます。 -- DDL文の状態が変化すると、メタデータの最新バージョンがすべてのTiDBノードにプッシュされます。TiDBノード上でこの状態変化に関連するすべてのトランザクションで使用されるメタデータバージョンと現在のメタデータバージョンの差が2未満の場合、そのTiDBノードはメタデータオブジェクトのメタデータロックを取得したとみなされます。次の状態変化は、クラスタ内のすべてのTiDBノードがメタデータオブジェクトのメタデータロックを取得した後にのみ実行できます。 +- DMLを実行すると、TiDBはトランザクションコンテキスト内でDMLによってアクセスされたメタデータオブジェクト（テーブル、ビュー、対応するメタデータバージョンなど）を記録します。これらのレコードは、トランザクションがコミットされるとクリーンアップされます。 +- DDL文の状態が変化すると、メタデータの最新バージョンがすべてのTiDBノードにプッシュされます。TiDBノード上でこの状態変化に関連するすべてのトランザクションで使用されるメタデータバージョンと現在のメタデータバージョンの差が2未満の場合、そのTiDBノードはメタデータオブジェクトのメタデータロックを取得したとみなされます。次の状態変化は、クラスタ内のすべてのTiDBノードがメタデータオブジェクトのメタデータロックを取得した後にのみ実行できます。 diff --git a/metrics-schema.md b/metrics-schema.md index b79b588ef0a03..1a50489d16ba5 100644 --- a/metrics-schema.md +++ b/metrics-schema.md @@ -111,11 +111,11 @@ SELECT * FROM information_schema.metrics_tables WHERE table_name='tidb_query_dur フィールドの説明: -- `TABLE_NAME` : `metrics_schema`のテーブル名に対応します。この例では、テーブル名は`tidb_query_duration`です。 -- `PROMQL` : 監視テーブルの動作原理は、まずSQL文を`PromQL`にマッピングし、次にPrometheusにデータを要求し、Prometheusの結果をSQLクエリ結果に変換することです。このフィールドは`PromQL`の式テンプレートです。監視テーブルのデータをクエリすると、クエリ条件を使用してこのテンプレート内の変数が書き換えられ、最終的なクエリ式が生成されます。 -- `LABELS` : 監視項目のラベル。`tidb_query_duration`は`instance`と`sql_type`の 2 つのラベルがあります。 -- `QUANTILE` : パーセンタイル。ヒストグラム型の監視データの場合、デフォルトのパーセンタイルが指定されます。このフィールドの値が`0`の場合、監視テーブルに対応する監視項目はヒストグラムではないことを意味します。 -- `COMMENT` : 監視テーブルの説明。`tidb_query_duration`テーブルは、TiDBクエリ実行のパーセンタイル時間（P999/P99/P90のクエリ時間など）を照会するために使用されていることがわかります。単位は秒です。 +- `TABLE_NAME` : `metrics_schema`のテーブル名に対応します。この例では、テーブル名は`tidb_query_duration`です。 +- `PROMQL` : 監視テーブルの動作原理は、まずSQL文を`PromQL`にマッピングし、次にPrometheusにデータを要求し、Prometheusの結果をSQLクエリ結果に変換することです。このフィールドは`PromQL`の式テンプレートです。監視テーブルのデータをクエリすると、クエリ条件を使用してこのテンプレート内の変数が書き換えられ、最終的なクエリ式が生成されます。 +- `LABELS` : 監視項目のラベル。`tidb_query_duration`は`instance`と`sql_type`の 2 つのラベルがあります。 +- `QUANTILE` : パーセンタイル。ヒストグラム型の監視データの場合、デフォルトのパーセンタイルが指定されます。このフィールドの値が`0`の場合、監視テーブルに対応する監視項目はヒストグラムではないことを意味します。 +- `COMMENT` : 監視テーブルの説明。`tidb_query_duration`テーブルは、TiDBクエリ実行のパーセンタイル時間（P999/P99/P90のクエリ時間など）を照会するために使用されていることがわかります。単位は秒です。 `tidb_query_duration`テーブルのスキーマをクエリするには、次のステートメントを実行します。 @@ -137,10 +137,10 @@ SHOW CREATE TABLE metrics_schema.tidb_query_duration; +---------------------+--------------------------------------------------------------------------------------------------------------------+ ``` -- `time` : 監視項目の時間。 -- `instance`と`sql_type` : `tidb_query_duration`監視項目のラベル。`instance`は監視アドレスを意味します。`sql_type`は実行された SQL 文の種類を意味します。 -- `quantile` : パーセンタイル。ヒストグラム型の監視項目にはこの列があり、クエリのパーセンタイル時間を示します。例えば、 `quantile = 0.9` P90の時間をクエリすることを意味します。 -- `value` : 監視項目の値。 +- `time` : 監視項目の時間。 +- `instance`と`sql_type` : `tidb_query_duration`監視項目のラベル。`instance`は監視アドレスを意味します。`sql_type`は実行された SQL 文の種類を意味します。 +- `quantile` : パーセンタイル。ヒストグラム型の監視項目にはこの列があり、クエリのパーセンタイル時間を示します。例えば、 `quantile = 0.9` P90の時間をクエリすることを意味します。 +- `value` : 監視項目の値。 次の文は`2020-03-25 23:42:00` [ `2020-03-25 23:40:00` ]の範囲内のP99時間を照会します。 @@ -166,8 +166,8 @@ SELECT * FROM metrics_schema.tidb_query_duration WHERE value is not null AND tim 上記のクエリ結果の最初の行は、2020年3月25日 23:40:00の時点において、TiDBインスタンス`172.16.5.40:10089`において、 `Insert`文のP99実行時間が0.509929485256秒であることを意味します。他の行も同様の意味を持ちます。`sql_type`の列のその他の値は、以下のように記述されます。 -- `Select` : `select`型のステートメントが実行されます。 -- `internal` : 統計情報を更新し、グローバル変数を取得するために使用される TiDB の内部 SQL ステートメント。 +- `Select` : `select`型のステートメントが実行されます。 +- `internal` : 統計情報を更新し、グローバル変数を取得するために使用される TiDB の内部 SQL ステートメント。 上記のステートメントの実行計画を表示するには、次のステートメントを実行します。 @@ -188,12 +188,12 @@ DESC SELECT * FROM metrics_schema.tidb_query_duration WHERE value is not null AN [ `2020-03-25 23:40:00` , `2020-03-25 23:42:00` ] の範囲では、各ラベルに3つの時間値しかないことに気づくかもしれません。実行計画では、 `step`の値は1分であり、これらの値の間隔は1分であることを意味します。`step`は次の2つのセッション変数によって決定されます。 -- `tidb_metric_query_step` : クエリ解決ステップ幅。Prometheusから`query_range`データを取得するには、 `start_time` 、 `end_time` 、 `step`を指定する必要があります。 `step` 、この変数の値が使用されます。 -- `tidb_metric_query_range_duration` : 監視データが照会されると、 `PROMQL`の`$ RANGE_DURATION`のフィールドの値がこの変数の値に置き換えられます。デフォルト値は60秒です。 +- `tidb_metric_query_step` : クエリ解決ステップ幅。Prometheusから`query_range`データを取得するには、 `start_time` 、 `end_time` 、 `step`を指定する必要があります。 `step` 、この変数の値が使用されます。 +- `tidb_metric_query_range_duration` : 監視データが照会されると、 `PROMQL`の`$ RANGE_DURATION`のフィールドの値がこの変数の値に置き換えられます。デフォルト値は60秒です。 監視項目の値を異なる粒度で表示するには、監視テーブルをクエリする前に、上記の2つのセッション変数を変更します。例： -1. 2 つのセッション変数の値を変更し、時間の粒度を 30 秒に設定します。 +1. 2 つのセッション変数の値を変更し、時間の粒度を 30 秒に設定します。 > **Note:** > @@ -204,7 +204,7 @@ DESC SELECT * FROM metrics_schema.tidb_query_duration WHERE value is not null AN set @@tidb_metric_query_range_duration=30; ``` -2. `tidb_query_duration`監視項目に対して、以下のようにクエリを実行します。結果から、3分間の時間範囲内で、各ラベルに6つの時間値があり、各値の間隔は30秒であることがわかります。 +2. `tidb_query_duration`監視項目に対して、以下のようにクエリを実行します。結果から、3分間の時間範囲内で、各ラベルに6つの時間値があり、各値の間隔は30秒であることがわかります。 ```sql select * from metrics_schema.tidb_query_duration where value is not null and time>='2020-03-25 23:40:00' and time <= '2020-03-25 23:42:00' and quantile=0.99; @@ -232,7 +232,7 @@ DESC SELECT * FROM metrics_schema.tidb_query_duration WHERE value is not null AN +---------------------+-------------------+----------+----------+-----------------+ ``` -3. 実行計画を表示する。結果から、実行計画の`PromQL`と`step`値が30秒に変更されていることも確認できます。 +3. 実行計画を表示する。結果から、実行計画の`PromQL`と`step`値が30秒に変更されていることも確認できます。 ```sql desc select * from metrics_schema.tidb_query_duration where value is not null and time>='2020-03-25 23:40:00' and time <= '2020-03-25 23:42:00' and quantile=0.99; diff --git a/migrate-aurora-to-tidb.md b/migrate-aurora-to-tidb.md index dfff242157cc3..b7d742927b766 100644 --- a/migrate-aurora-to-tidb.md +++ b/migrate-aurora-to-tidb.md @@ -9,14 +9,14 @@ summary: DBスナップショットを使用して、Amazon AuroraからTiDBへ 移行全体は2つのプロセスから構成されます。 -- TiDB Lightningを使用してTiDBに完全なデータをインポートします -- DMを使用して増分データをTiDBに複製する（オプション） +- TiDB Lightningを使用してTiDBに完全なデータをインポートします +- DMを使用して増分データをTiDBに複製する（オプション） ## 前提条件 {#prerequisites} -- [DumplingとTiDB Lightningをインストールする](/migration-tools.md)。ターゲット側で対応するテーブルを手動で作成する場合は、 Dumplingをインストールしないでください。 -- [Dumplingに必要な上流データベース権限を取得します](/dumpling-overview.md#required-privileges) -- [TiDB Lightningに必要なターゲットデータベース権限を取得します](/tidb-lightning/tidb-lightning-faq.md#what-are-the-privilege-requirements-for-the-target-database) +- [DumplingとTiDB Lightningをインストールする](/migration-tools.md)。ターゲット側で対応するテーブルを手動で作成する場合は、 Dumplingをインストールしないでください。 +- [Dumplingに必要な上流データベース権限を取得します](/dumpling-overview.md#required-privileges) +- [TiDB Lightningに必要なターゲットデータベース権限を取得します](/tidb-lightning/tidb-lightning-faq.md#what-are-the-privilege-requirements-for-the-target-database) ## TiDBに全データをインポートする {#import-full-data-to-tidb} @@ -90,7 +90,7 @@ nohup tiup tidb-lightning -config tidb-lightning-schema.toml > nohup.out 2>&1 & #### 2.1 Amazon AuroraのスナップショットをAmazon S3にエクスポートする {#2-1-export-an-amazon-aurora-snapshot-to-amazon-s3} -1. 後続の増分移行のために、Amazon Auroraのbinlogの名前と場所を取得します。Amazon Auroraで`SHOW MASTER STATUS`コマンドを実行し、現在のbinlogの位置を記録します。 +1. 後続の増分移行のために、Amazon Auroraのbinlogの名前と場所を取得します。Amazon Auroraで`SHOW MASTER STATUS`コマンドを実行し、現在のbinlogの位置を記録します。 ```sql SHOW MASTER STATUS; @@ -107,7 +107,7 @@ nohup tiup tidb-lightning -config tidb-lightning-schema.toml > nohup.out 2>&1 & 1 row in set (0.012 sec) ``` -2. Amazon Auroraスナップショットをエクスポートします。詳細な手順については、 [DBスナップショットデータをAmazon S3にエクスポートする](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_ExportSnapshot.html)を参照してください。binlogの位置を取得したら、5 分以内にスナップショットをエクスポートします。そうしないと、記録されたbinlogの位置が古くなり、増分レプリケーション中にデータの競合が発生する可能性があります。 +2. Amazon Auroraスナップショットをエクスポートします。詳細な手順については、 [DBスナップショットデータをAmazon S3にエクスポートする](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_ExportSnapshot.html)を参照してください。binlogの位置を取得したら、5 分以内にスナップショットをエクスポートします。そうしないと、記録されたbinlogの位置が古くなり、増分レプリケーション中にデータの競合が発生する可能性があります。 #### 2.2 データファイル用のTiDB Lightning構成ファイルを作成する {#2-2-create-the-tidb-lightning-configuration-file-for-the-data-file} @@ -152,7 +152,7 @@ TiDBクラスターでTLSを有効にする必要がある場合は、 [TiDB Lig #### 2.3 TiDBへの全データのインポート {#2-3-import-full-data-to-tidb} -1. TiDB Lightningを使用して、Amazon AuroraのスナップショットからTiDBにデータをインポートします。 +1. TiDB Lightningを使用して、Amazon AuroraのスナップショットからTiDBにデータをインポートします。 ```shell export AWS_ACCESS_KEY_ID=${access_key} @@ -160,12 +160,12 @@ TiDBクラスターでTLSを有効にする必要がある場合は、 [TiDB Lig nohup tiup tidb-lightning -config tidb-lightning-data.toml > nohup.out 2>&1 & ``` -2. インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 +2. インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 - - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 - - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進捗状況を確認します。 + - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 + - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進捗状況を確認します。 -3. TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 +3. TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 > **Note:** > @@ -177,12 +177,12 @@ TiDBクラスターでTLSを有効にする必要がある場合は、 [TiDB Lig ### 前提条件 {#prerequisites} -- [DMをインストール](/dm/deploy-a-dm-cluster-using-tiup.md)。 -- [DMに必要なソースデータベースとターゲットデータベースの権限を取得します](/dm/dm-worker-intro.md) +- [DMをインストール](/dm/deploy-a-dm-cluster-using-tiup.md)。 +- [DMに必要なソースデータベースとターゲットデータベースの権限を取得します](/dm/dm-worker-intro.md) ### ステップ1：データソースを作成する {#step-1-create-the-data-source} -1. `source1.yaml`ファイルは以下の手順で作成します。 +1. `source1.yaml`ファイルは以下の手順で作成します。 ```yaml # Must be unique. @@ -197,7 +197,7 @@ TiDBクラスターでTLSを有効にする必要がある場合は、 [TiDB Lig port: 3306 ``` -2. 次のコマンドを実行して、 `tiup dmctl`を使用してデータソース構成を DM クラスターにロードします。 +2. 次のコマンドを実行して、 `tiup dmctl`を使用してデータソース構成を DM クラスターにロードします。 ```shell tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml @@ -298,13 +298,13 @@ TiUPを使用してDMをデプロイした際に、Prometheus、Alertmanager、 DMが実行されている間、DM-worker、DM-master、およびdmctlは関連情報をログに出力します。これらのコンポーネントのログディレクトリは以下のとおりです。 -- DM-master: DM-master プロセス パラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログ ディレクトリはデフォルトで`/dm-deploy/dm-master-8261/log/`になります。 -- DM-worker: DM-worker プロセス パラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログ ディレクトリはデフォルトで`/dm-deploy/dm-worker-8262/log/`になります。 +- DM-master: DM-master プロセス パラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログ ディレクトリはデフォルトで`/dm-deploy/dm-master-8261/log/`になります。 +- DM-worker: DM-worker プロセス パラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログ ディレクトリはデフォルトで`/dm-deploy/dm-worker-8262/log/`になります。 ## 次は？ {#what-s-next} -- [移行タスクを一時停止する](/dm/dm-pause-task.md)。 -- [移行タスクを再開する](/dm/dm-resume-task.md)。 -- [移行タスクを停止します](/dm/dm-stop-task.md)。 -- [クラスタデータソースとタスク構成のエクスポートとインポート](/dm/dm-export-import-config.md)。 -- [失敗したDDLステートメントを処理する](/dm/handle-failed-ddl-statements.md)。 +- [移行タスクを一時停止する](/dm/dm-pause-task.md)。 +- [移行タスクを再開する](/dm/dm-resume-task.md)。 +- [移行タスクを停止します](/dm/dm-stop-task.md)。 +- [クラスタデータソースとタスク構成のエクスポートとインポート](/dm/dm-export-import-config.md)。 +- [失敗したDDLステートメントを処理する](/dm/handle-failed-ddl-statements.md)。 diff --git a/migrate-from-csv-files-to-tidb.md b/migrate-from-csv-files-to-tidb.md index c52c74202d64b..5df036cc589da 100644 --- a/migrate-from-csv-files-to-tidb.md +++ b/migrate-from-csv-files-to-tidb.md @@ -11,15 +11,15 @@ TiDB Lightningは、CSVファイルやタブ区切り値（TSV）などの他の ## 前提条件 {#prerequisites} -- [TiDB Lightningをインストールする](/migration-tools.md)。 -- [TiDB Lightningに必要なターゲットデータベース権限を取得します](/tidb-lightning/tidb-lightning-requirements.md#privileges-of-the-target-database) +- [TiDB Lightningをインストールする](/migration-tools.md)。 +- [TiDB Lightningに必要なターゲットデータベース権限を取得します](/tidb-lightning/tidb-lightning-requirements.md#privileges-of-the-target-database) ## ステップ1. CSVファイルを準備する {#step-1-prepare-the-csv-files} すべてのCSVファイルを同じディレクトリに配置してください。TiDB LightningがすべてのCSVファイルを認識する必要がある場合は、ファイル名が以下の要件を満たす必要があります。 -- CSV ファイルにテーブル全体のデータが含まれている場合は、ファイル名を`${db_name}.${table_name}.csv`とします。 -- 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例： `${db_name}.${table_name}.003.csv` 。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 +- CSV ファイルにテーブル全体のデータが含まれている場合は、ファイル名を`${db_name}.${table_name}.csv`とします。 +- 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例： `${db_name}.${table_name}.003.csv` 。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 TiDB Lightning は、このディレクトリとそのサブディレクトリ内のすべての`.csv`ファイルを再帰的に検索します。 @@ -27,14 +27,14 @@ TiDB Lightning は、このディレクトリとそのサブディレクトリ CSVファイルにはスキーマ情報が含まれていないため、CSVファイルからTiDBにデータをインポートする前に、対象テーブルのスキーマを作成する必要があります。対象テーブルのスキーマは、以下の2つの方法のいずれかで作成できます。 -- **方法 1** : TiDB Lightningを使用してターゲット テーブル スキーマを作成します。 +- **方法 1** : TiDB Lightningを使用してターゲット テーブル スキーマを作成します。 必要なDDLステートメントを含むSQLファイルを作成します。 - - `CREATE DATABASE`ファイルに`${db_name}-schema-create.sql` } ステートメントを追加します。 - - `CREATE TABLE`ファイルに`${db_name}.${table_name}-schema.sql` } ステートメントを追加します。 + - `CREATE DATABASE`ファイルに`${db_name}-schema-create.sql` } ステートメントを追加します。 + - `CREATE TABLE`ファイルに`${db_name}.${table_name}-schema.sql` } ステートメントを追加します。 -- **方法2** ：対象テーブルのスキーマを手動で作成する。 +- **方法2** ：対象テーブルのスキーマを手動で作成する。 ## ステップ3．設定ファイルを作成する {#step-3-create-the-configuration-file} @@ -104,8 +104,8 @@ TiDB Lightningは、サイズが約256MiBの均一なCSVファイルからデー 厳密な形式のCSVファイルでは、各フィールドは1行のみを占めます。以下の要件を満たす必要があります。 -- 区切り文字が空です。 -- 各フィールドには CR ( `\r` ) または LF ( `\n` ) は含まれていません。 +- 区切り文字が空です。 +- 各フィールドには CR ( `\r` ) または LF ( `\n` ) は含まれていません。 `terminator` `strict-format` } を明示的に指定する必要があります。 @@ -126,8 +126,8 @@ nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out 2>&1 & インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 -- ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 -- [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進行状況を確認します。 +- ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 +- [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進行状況を確認します。 TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 @@ -183,4 +183,4 @@ trim-last-separator = true ## 次は？ {#what-s-next} -- [CSVのサポートと制限事項](/tidb-lightning/tidb-lightning-data-source.md#csv)。 +- [CSVのサポートと制限事項](/tidb-lightning/tidb-lightning-data-source.md#csv)。 diff --git a/migrate-from-mariadb.md b/migrate-from-mariadb.md index 525212842c786..3f2d5349aa76f 100644 --- a/migrate-from-mariadb.md +++ b/migrate-from-mariadb.md @@ -11,22 +11,22 @@ summary: MariaDBからTiDBへのデータ移行方法を学びましょう。 適切な移行戦略を選択してください。 -- 最初の戦略は、 [Dumplingでデータをダンプし、 TiDB Lightningでデータを復元する](#dump-data-with-dumpling-and-restore-data-with-tidb-lightning)です。これは MariaDB のすべてのバージョンで機能します。この戦略の欠点は、より多くのダウンタイムが必要になることです。 -- 2 番目の戦略は、 [DMを使用してデータを複製する](#replicate-data-with-dm)ことです。 DM は MariaDB のすべてのバージョンをサポートしているわけではありません。サポートされているバージョンは、 [DM互換性カタログ](/dm/dm-compatibility-catalog.md#compatibility-catalog-of-tidb-data-migration)に記載されています。 +- 最初の戦略は、 [Dumplingでデータをダンプし、 TiDB Lightningでデータを復元する](#dump-data-with-dumpling-and-restore-data-with-tidb-lightning)です。これは MariaDB のすべてのバージョンで機能します。この戦略の欠点は、より多くのダウンタイムが必要になることです。 +- 2 番目の戦略は、 [DMを使用してデータを複製する](#replicate-data-with-dm)ことです。 DM は MariaDB のすべてのバージョンをサポートしているわけではありません。サポートされているバージョンは、 [DM互換性カタログ](/dm/dm-compatibility-catalog.md#compatibility-catalog-of-tidb-data-migration)に記載されています。 これら2つの戦略以外にも、あなたの状況に特化した戦略が存在する可能性があります。例えば、以下のような戦略です。 -- オブジェクトリレーショナルマッピング（ORM）の機能を使用して、データを再デプロイおよび移行してください。 -- 移行作業中は、アプリケーションを修正してMariaDBとTiDBの両方から書き込みを行えるようにしてください。 +- オブジェクトリレーショナルマッピング（ORM）の機能を使用して、データを再デプロイおよび移行してください。 +- 移行作業中は、アプリケーションを修正してMariaDBとTiDBの両方から書き込みを行えるようにしてください。 この文書では、最初の2つの戦略のみを取り上げています。 選択した戦略に基づいて、以下のものを準備してください。 -- **ダンプとリストアの**戦略について： - - [Dumpling](/dumpling-overview.md)と[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)をインストールしてください。 - - Dumpling がデータをエクスポートするために MariaDBサーバー上で [必要な権限](/dumpling-overview.md#required-privileges)を持っていることを確認してください。 -- **データレプリケーション**戦略として、[データ移行（DM）](/dm/dm-overview.md)を設定します。 +- **ダンプとリストアの**戦略について： + - [Dumpling](/dumpling-overview.md)と[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)をインストールしてください。 + - Dumpling がデータをエクスポートするために MariaDBサーバー上で [必要な権限](/dumpling-overview.md#required-privileges)を持っていることを確認してください。 +- **データレプリケーション**戦略として、[データ移行（DM）](/dm/dm-overview.md)を設定します。 ## 互換性を確認してください {#check-compatibility} @@ -342,21 +342,21 @@ tidb> MariaDBからTiDBへデータを移行するには、以下の手順を実行してください。 -1. アプリケーションを停止してください。アプリケーションをオフラインにしてください。これにより、移行中または移行後にMariaDB内のデータが変更されることがなくなります。 +1. アプリケーションを停止してください。アプリケーションをオフラインにしてください。これにより、移行中または移行後にMariaDB内のデータが変更されることがなくなります。 -2. MariaDBに[`tiup dumpling`](/dumpling-overview.md#use-dumpling-to-export-data)コマンドを使用してデータをダンプします。 +2. MariaDBに[`tiup dumpling`](/dumpling-overview.md#use-dumpling-to-export-data)コマンドを使用してデータをダンプします。 ```shell tiup dumpling --port 3306 --host 127.0.0.1 --user root --password secret -F 256MB -o /data/backup ``` -3. `tiup tidb-lightning`コマンドを使用してデータを復元します。 TiDB Lightning の構成方法と実行方法の詳細については、 [TiDB Lightningを使い始めよう](/get-started-with-tidb-lightning.md)を参照してください。 +3. `tiup tidb-lightning`コマンドを使用してデータを復元します。 TiDB Lightning の構成方法と実行方法の詳細については、 [TiDB Lightningを使い始めよう](/get-started-with-tidb-lightning.md)を参照してください。 -4. ユーザーアカウントと権限を移行します。ユーザーと権限を移行する方法の詳細については、[ユーザーと権限のエクスポート](#export-users-and-grants)を参照してください。 +4. ユーザーアカウントと権限を移行します。ユーザーと権限を移行する方法の詳細については、[ユーザーと権限のエクスポート](#export-users-and-grants)を参照してください。 -5. アプリケーションを再構成してください。TiDBサーバーに接続できるように、アプリケーションの設定を変更する必要があります。 +5. アプリケーションを再構成してください。TiDBサーバーに接続できるように、アプリケーションの設定を変更する必要があります。 -6. クリーンアップ。移行が成功したことを確認したら、MariaDB のデータの最終バックアップを作成し、サーバーを停止します。これにより、 TiUP、 Dumpling、 TiDB Lightningなどのツールを削除することもできます。 +6. クリーンアップ。移行が成功したことを確認したら、MariaDB のデータの最終バックアップを作成し、サーバーを停止します。これにより、 TiUP、 Dumpling、 TiDB Lightningなどのツールを削除することもできます。 ## DMを使用してデータを複製する {#replicate-data-with-dm} @@ -400,9 +400,9 @@ MariaDBからMariaDBへのレプリケーションのように、最初に初期 TiDBに切り替えるには、以下の手順を実行する必要があります。 -1. アプリケーションを停止してください。 -2. レプリケーション遅延を監視してください。遅延時間は0秒になるはずです。 -3. アプリケーションの設定を変更してTiDBに接続するようにし、再度起動してください。 +1. アプリケーションを停止してください。 +2. レプリケーション遅延を監視してください。遅延時間は0秒になるはずです。 +3. アプリケーションの設定を変更してTiDBに接続するようにし、再度起動してください。 レプリケーションの遅延を確認するには、 `dmctl`を介して[`query-status `](/dm/dm-query-status.md#detailed-query-result)を実行し、 `"synced: true"`内の`subTaskStatus`を確認します。 diff --git a/migrate-from-parquet-files-to-tidb.md b/migrate-from-parquet-files-to-tidb.md index 071a8e5c025a2..e96dc779a52f1 100644 --- a/migrate-from-parquet-files-to-tidb.md +++ b/migrate-from-parquet-files-to-tidb.md @@ -11,8 +11,8 @@ Amazon AuroraからParquetファイルをエクスポートする場合は、 [A ## 前提条件 {#prerequisites} -- [TiUPを使用してTiDB Lightningをインストールする](/migration-tools.md)。 -- [TiDB Lightningに必要なターゲットデータベース権限を取得します](/tidb-lightning/tidb-lightning-faq.md#what-are-the-privilege-requirements-for-the-target-database) +- [TiUPを使用してTiDB Lightningをインストールする](/migration-tools.md)。 +- [TiDB Lightningに必要なターゲットデータベース権限を取得します](/tidb-lightning/tidb-lightning-faq.md#what-are-the-privilege-requirements-for-the-target-database) ## ステップ1. Parquetファイルを用意する {#step-1-prepare-the-parquet-files} @@ -20,7 +20,7 @@ Amazon AuroraからParquetファイルをエクスポートする場合は、 [A Hive の各テーブルは`STORED AS PARQUET LOCATION '/path/in/hdfs'`を指定することで、Parquet ファイルにエクスポートできます。したがって、 `test`という名前のテーブルをエクスポートする必要がある場合は、次の手順を実行します。 -1. Hiveで以下のSQL文を実行してください。 +1. Hiveで以下のSQL文を実行してください。 ```sql CREATE TABLE temp STORED AS PARQUET LOCATION '/path/in/hdfs' @@ -29,7 +29,7 @@ Hive の各テーブルは`STORED AS PARQUET LOCATION '/path/in/hdfs'`を指定 上記のステートメントを実行すると、テーブルデータはHDFSシステムに正常にエクスポートされます。 -2. `hdfs dfs -get`コマンドを使用して、Parquet ファイルをローカルファイルシステムにエクスポートします。 +2. `hdfs dfs -get`コマンドを使用して、Parquet ファイルをローカルファイルシステムにエクスポートします。 ```shell hdfs dfs -get /path/in/hdfs /path/in/local @@ -41,22 +41,22 @@ Hive の各テーブルは`STORED AS PARQUET LOCATION '/path/in/hdfs'`を指定 DROP TABLE temp; ``` -3. Hive からエクスポートされた Parquet ファイルには`.parquet`サフィックスが付いていない場合があるため、TiDB Lightning はそれらを正しく識別できません。ファイルをインポートする前に、ファイル名を変更して `.parquet`サフィックスを追加し、ファイル名全体をTiDB Lightning が認識する形式（例: `${db_name}.${table_name}.parquet`）に変更する必要があります。ファイルの種類とパターンに関する詳細については、 [TiDB Lightningデータソース](/tidb-lightning/tidb-lightning-data-source.md)を参照してください。また、正しい[カスタマイズされた表現](/tidb-lightning/tidb-lightning-data-source.md#match-customized-files)を設定することでデータ ファイルを一致させることもできます。 +3. Hive からエクスポートされた Parquet ファイルには`.parquet`サフィックスが付いていない場合があるため、TiDB Lightning はそれらを正しく識別できません。ファイルをインポートする前に、ファイル名を変更して `.parquet`サフィックスを追加し、ファイル名全体をTiDB Lightning が認識する形式（例: `${db_name}.${table_name}.parquet`）に変更する必要があります。ファイルの種類とパターンに関する詳細については、 [TiDB Lightningデータソース](/tidb-lightning/tidb-lightning-data-source.md)を参照してください。また、正しい[カスタマイズされた表現](/tidb-lightning/tidb-lightning-data-source.md#match-customized-files)を設定することでデータ ファイルを一致させることもできます。 -4. すべての Parquet ファイルを、例えば`/data/my_datasource/`や`s3://my-bucket/sql-backup`のような単一のディレクトリに配置してください。TiDB Lightning は、このディレクトリとそのサブディレクトリ内のすべての`.parquet`ファイルを再帰的に検索します。 +4. すべての Parquet ファイルを、例えば`/data/my_datasource/`や`s3://my-bucket/sql-backup`のような単一のディレクトリに配置してください。TiDB Lightning は、このディレクトリとそのサブディレクトリ内のすべての`.parquet`ファイルを再帰的に検索します。 ## ステップ2. 対象テーブルのスキーマを作成する {#step-2-create-the-target-table-schema} ParquetファイルからTiDBにデータをインポートする前に、ターゲットテーブルスキーマを作成する必要があります。ターゲットテーブルスキーマは、以下の2つの方法のいずれかで作成できます。 -- **方法 1** : TiDB Lightningを使用してターゲット テーブル スキーマを作成します。 +- **方法 1** : TiDB Lightningを使用してターゲット テーブル スキーマを作成します。 必要なDDLステートメントを含むSQLファイルを作成します。 - - `CREATE DATABASE`ファイルに`${db_name}-schema-create.sql` } ステートメントを追加します。 - - `CREATE TABLE`ファイルに`${db_name}.${table_name}-schema.sql` } ステートメントを追加します。 + - `CREATE DATABASE`ファイルに`${db_name}-schema-create.sql` } ステートメントを追加します。 + - `CREATE TABLE`ファイルに`${db_name}.${table_name}-schema.sql` } ステートメントを追加します。 -- **方法2** ：対象テーブルのスキーマを手動で作成する。 +- **方法2** ：対象テーブルのスキーマを手動で作成する。 ## ステップ3．設定ファイルを作成する {#step-3-create-the-configuration-file} @@ -94,9 +94,9 @@ pd-addr = "${ip}:${port}" # The address of the PD cluster, e.g.: 172.16.31.3:237 ## ステップ4．データのインポート {#step-4-import-the-data} -1. `tidb-lightning`を実行します。 +1. `tidb-lightning`を実行します。 - - Amazon S3 からデータをインポートする場合は、 TiDB Lightning を実行する前に、S3 バックエンドストレージへのアクセス権限を持つアカウントの SecretKey と AccessKey を環境変数として設定する必要があります。 + - Amazon S3 からデータをインポートする場合は、 TiDB Lightning を実行する前に、S3 バックエンドストレージへのアクセス権限を持つアカウントの SecretKey と AccessKey を環境変数として設定する必要があります。 ```shell export AWS_ACCESS_KEY_ID=${access_key} @@ -105,20 +105,20 @@ pd-addr = "${ip}:${port}" # The address of the PD cluster, e.g.: 172.16.31.3:237 前述の方法に加えて、 TiDB Lightning は`~/.aws/credentials`から認証情報ファイルを読み取ることもサポートしています。 - - コマンドラインでプログラムを起動すると、 `SIGHUP`シグナルを受信した後にプロセスが予期せず終了する可能性があります。この場合、 `nohup`または`screen`ツールを使用してプログラムを実行することをお勧めします。例: + - コマンドラインでプログラムを起動すると、 `SIGHUP`シグナルを受信した後にプロセスが予期せず終了する可能性があります。この場合、 `nohup`または`screen`ツールを使用してプログラムを実行することをお勧めします。例: ```shell nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out 2>&1 & ``` -2. インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 +2. インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 - - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 - - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進捗状況を確認してください。 + - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 + - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進捗状況を確認してください。 TiDB Lightningはインポートが完了すると自動的に終了します。 -3. インポートが成功したかどうか確認してください。 +3. インポートが成功したかどうか確認してください。 最終行に`tidb-lightning.log`に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 diff --git a/migrate-from-sql-files-to-tidb.md b/migrate-from-sql-files-to-tidb.md index 87b6baac8529d..e50df9d292c99 100644 --- a/migrate-from-sql-files-to-tidb.md +++ b/migrate-from-sql-files-to-tidb.md @@ -9,8 +9,8 @@ summary: SQLファイルからTiDBへのデータ移行方法を学びましょ ## 前提条件 {#prerequisites} -- [TiUPを使用してTiDB Lightningをインストールする](/migration-tools.md) -- [TiDB Lightningの対象データベースに必要な権限を付与します](/tidb-lightning/tidb-lightning-faq.md#what-are-the-privilege-requirements-for-the-target-database) +- [TiUPを使用してTiDB Lightningをインストールする](/migration-tools.md) +- [TiDB Lightningの対象データベースに必要な権限を付与します](/tidb-lightning/tidb-lightning-faq.md#what-are-the-privilege-requirements-for-the-target-database) ## ステップ1. SQLファイルを準備する {#step-1-prepare-sql-files} @@ -22,14 +22,14 @@ TiDBにデータをインポートするには、対象データベースのテ Dumplingを使用してデータをエクスポートする場合、テーブルスキーマファイルは自動的にエクスポートされます。その他の方法でエクスポートされたデータについては、以下のいずれかの方法でテーブルスキーマを作成できます。 -- **方法 1** : TiDB Lightningを使用してターゲット テーブル スキーマを作成します。 +- **方法 1** : TiDB Lightningを使用してターゲット テーブル スキーマを作成します。 必要なDDLステートメントを含むSQLファイルを作成します。 - - `CREATE DATABASE`ファイルに`${db_name}-schema-create.sql` } ステートメントを追加します。 - - `CREATE TABLE`ファイルに`${db_name}.${table_name}-schema.sql` } ステートメントを追加します。 + - `CREATE DATABASE`ファイルに`${db_name}-schema-create.sql` } ステートメントを追加します。 + - `CREATE TABLE`ファイルに`${db_name}.${table_name}-schema.sql` } ステートメントを追加します。 -- **方法2** ：対象テーブルのスキーマを手動で作成する。 +- **方法2** ：対象テーブルのスキーマを手動で作成する。 ## ステップ3．設定ファイルを作成する {#step-3-create-the-configuration-file} @@ -81,8 +81,8 @@ TiDB Lightning は`~/.aws/credentials`からの認証情報ファイルの読み インポートが開始された後、以下のいずれかの方法で進行状況を確認できます。 -- ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。このログはデフォルトで 5 分ごとに更新されます。 -- Grafana ダッシュボードを使用します。詳細については、 [TiDB Lightningモニタリング](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 +- ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。このログはデフォルトで 5 分ごとに更新されます。 +- Grafana ダッシュボードを使用します。詳細については、 [TiDB Lightningモニタリング](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 インポートが完了すると、 TiDB Lightning は自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合は、インポートは成功です。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 diff --git a/migrate-from-tidb-to-mysql.md b/migrate-from-tidb-to-mysql.md index 267be45bd52b2..1782686e2825f 100644 --- a/migrate-from-tidb-to-mysql.md +++ b/migrate-from-tidb-to-mysql.md @@ -7,14 +7,14 @@ summary: TiDB から MySQL 互換データベースにデータを移行する このドキュメントでは、TiDB クラスターからAurora、MySQL、MariaDB などの MySQL 互換データベースへのデータ移行方法について説明します。プロセス全体は以下の 4 つのステップで構成されます。 -1. 環境を設定します。 -2. 全データを移行します。 -3. 増分データを移行します。 -4. サービスを MySQL 互換クラスターに移行します。 +1. 環境を設定します。 +2. 全データを移行します。 +3. 増分データを移行します。 +4. サービスを MySQL 互換クラスターに移行します。 ## ステップ1. 環境を設定する {#step-1-set-up-the-environment} -1. TiDB クラスターをアップストリームにデプロイ。 +1. TiDB クラスターをアップストリームにデプロイ。 TiUP Playgroundを使用してTiDBクラスタをデプロイ。詳細については、 [TiUPを使用してオンライン TiDBクラスタをデプロイおよび管理](/tiup/tiup-cluster.md)を参照してください。 @@ -25,17 +25,17 @@ summary: TiDB から MySQL 互換データベースにデータを移行する tiup status ``` -2. MySQL インスタンスをダウンストリームにデプロイ。 +2. MySQL インスタンスをダウンストリームにデプロイ。 - - ラボ環境では、Docker を使用して次のコマンドを実行することで、MySQL インスタンスをすばやくデプロイできます。 + - ラボ環境では、Docker を使用して次のコマンドを実行することで、MySQL インスタンスをすばやくデプロイできます。 ```shell docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -p 3306:3306 -d mysql ``` - - 本番環境では、 [MySQLのインストール](https://dev.mysql.com/doc/refman/8.0/en/installing.html)の手順に従って MySQL インスタンスをデプロイできます。 + - 本番環境では、 [MySQLのインストール](https://dev.mysql.com/doc/refman/8.0/en/installing.html)の手順に従って MySQL インスタンスをデプロイできます。 -3. サービスのワークロードをシミュレートします。 +3. サービスのワークロードをシミュレートします。 ラボ環境では、 `go-tpc`を使用してTiDBクラスタの上流にデータを書き込むことができます。これは、TiDBクラスタでイベントの変更を生成するためです。以下のコマンドを実行して、TiDBクラスタに`tpcc`という名前のデータベースを作成し、 TiUP benchを使用してこのデータベースにデータを書き込みます。 @@ -54,7 +54,7 @@ summary: TiDB から MySQL 互換データベースにデータを移行する > > 本番のクラスタでは、GCを無効にしてバックアップを実行すると、クラスタのパフォーマンスに影響する可能性があります。この手順は、オフピーク時に実行することをお勧めします。 -1. ガベージコレクション (GC) を無効にします。 +1. ガベージコレクション (GC) を無効にします。 増分移行中に新しく書き込まれたデータが削除されないようにするには、フルデータをエクスポートする前に、上流クラスターのGCを無効にする必要があります。これにより、履歴データが削除されません。TiDB v4.0.0以降のバージョンでは、 Dumplingが[GCをブロックするためにGCセーフポイントを自動的に調整する](/dumpling-overview.md#manually-set-the-tidb-gc-time)なる可能性があります。ただし、 Dumplingの終了後にGCプロセスが開始され、増分変更の移行が失敗する可能性があるため、GCを手動で無効にすることは依然として必要です。 @@ -83,15 +83,15 @@ summary: TiDB から MySQL 互換データベースにデータを移行する 1 row in set (0.00 sec) ``` -2. データをバックアップします。 +2. データをバックアップします。 - 1. Dumplingを使用して SQL 形式でデータをエクスポートします。 + 1. Dumplingを使用して SQL 形式でデータをエクスポートします。 ```shell tiup dumpling -u root -P 4000 -h 127.0.0.1 --filetype sql -t 8 -o ./dumpling_output -r 200000 -F256MiB ``` - 2. データのエクスポートが完了したら、次のコマンドを実行してメタデータを確認します。メタデータの`Pos`はエクスポート スナップショットの TSO であり、BackupTS として記録できます。 + 2. データのエクスポートが完了したら、次のコマンドを実行してメタデータを確認します。メタデータの`Pos`はエクスポート スナップショットの TSO であり、BackupTS として記録できます。 ```shell cat dumpling_output/metadata @@ -106,7 +106,7 @@ summary: TiDB から MySQL 互換データベースにデータを移行する Finished dump at: 2022-06-28 17:49:57 ``` -3. データを復元します。 +3. データを復元します。 MyLoader（オープンソースツール）を使用して、下流のMySQLインスタンスにデータをインポートします。MyLoaderのインストールと使用方法の詳細については、 [MyDumpler/MyLoader](https://github.com/mydumper/mydumper)を参照してください。MyLoaderはv0.10以前のバージョンを使用する必要があります。それ以降のバージョンでは、 Dumplingによってエクスポートされたメタデータファイルを処理できません。 @@ -116,7 +116,7 @@ summary: TiDB から MySQL 互換データベースにデータを移行する myloader -h 127.0.0.1 -P 3306 -d ./dumpling_output/ ``` -4. (オプション) データを検証します。 +4. (オプション) データを検証します。 [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)を使用すると、特定の時間に上流と下流の間のデータの整合性をチェックできます。 @@ -151,11 +151,11 @@ summary: TiDB から MySQL 互換データベースにデータを移行する ## ステップ3. 増分データの移行 {#step-3-migrate-incremental-data} -1. TiCDCをデプロイ。 +1. TiCDCをデプロイ。 完全なデータ移行が完了したら、増分データをレプリケーションするためのTiCDCクラスターをデプロイして設定します。本番環境では、 [TiCDCをデプロイ](/ticdc/deploy-ticdc.md)の手順に従ってTiCDCをデプロイしてください。このドキュメントでは、テストクラスターの作成時にTiCDCノードが起動済みであるため、TiCDCのデプロイ手順をスキップして、次のステップに進み、変更フィードを作成できます。 -2. 変更フィードを作成します。 +2. 変更フィードを作成します。 アップストリーム クラスターで次のコマンドを実行して、アップストリーム クラスターからダウンストリーム クラスターへの変更フィードを作成します。 @@ -165,14 +165,14 @@ summary: TiDB から MySQL 互換データベースにデータを移行する このコマンドのパラメータは次のとおりです。 - - `--server` : TiCDC クラスター内の任意のノードの IP アドレス - - `--sink-uri` : 下流クラスタのURI - - `--changefeed-id` : チェンジフィードID、正規表現の形式でなければなりません、 `^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$` - - `--start-ts` : 変更フィードの開始タイムスタンプ。バックアップ時刻である必要があります (または[ステップ2. 全データの移行](#step-2-migrate-full-data)の「データのバックアップ」セクションの BackupTS) + - `--server` : TiCDC クラスター内の任意のノードの IP アドレス + - `--sink-uri` : 下流クラスタのURI + - `--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)を参照してください。 -3. GC を有効にします。 +3. GC を有効にします。 TiCDCを用いた増分移行では、GCは複製された履歴データのみを削除します。そのため、変更フィードを作成した後、以下のコマンドを実行してGCを有効にする必要があります。詳細は[TiCDCガベージコレクション（GC）セーフポイントの完全な動作は何ですか？](/ticdc/ticdc-faq.md#what-is-the-complete-behavior-of-ticdc-garbage-collection-gc-safepoint)を参照してください。 @@ -205,7 +205,7 @@ summary: TiDB から MySQL 互換データベースにデータを移行する チェンジフィードを作成すると、上流クラスターに書き込まれたデータは、低レイテンシーで下流クラスターに複製されます。読み取りトラフィックを下流クラスターに徐々に移行できます。一定期間、読み取りトラフィックを観察してください。下流クラスターが安定している場合は、以下の手順で書き込みトラフィックも下流クラスターに移行できます。 -1. アップストリームクラスタの書き込みサービスを停止します。変更フィードを停止する前に、アップストリームのすべてのデータがダウンストリームに複製されていることを確認してください。 +1. アップストリームクラスタの書き込みサービスを停止します。変更フィードを停止する前に、アップストリームのすべてのデータがダウンストリームに複製されていることを確認してください。 ```shell # Stop the changefeed from the upstream cluster to the downstream cluster @@ -228,4 +228,4 @@ summary: TiDB から MySQL 互換データベースにデータを移行する ] ``` -2. 書き込みサービスを下流クラスターに移行した後、しばらく観察します。下流クラスターが安定している場合は、上流クラスターを破棄できます。 +2. 書き込みサービスを下流クラスターに移行した後、しばらく観察します。下流クラスターが安定している場合は、上流クラスターを破棄できます。 diff --git a/migrate-from-tidb-to-tidb.md b/migrate-from-tidb-to-tidb.md index 1f9edb149c978..1aa4c81db6f39 100644 --- a/migrate-from-tidb-to-tidb.md +++ b/migrate-from-tidb-to-tidb.md @@ -7,23 +7,23 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー このドキュメントでは、あるTiDBクラスタから別のTiDBクラスタにデータを移行する方法について説明します。この機能は、以下のシナリオに適用されます。 -- データベースの分割: TiDB クラスターが大きすぎる場合、またはクラスターのサービス間への影響を避けたい場合は、データベースを分割できます。 -- データベースの再配置: データ センターの変更など、データベースを物理的に再配置します。 -- 新しいバージョンの TiDB クラスターにデータを移行する: データのセキュリティと精度の要件を満たすために、新しいバージョンの TiDB クラスターにデータを移行します。 +- データベースの分割: TiDB クラスターが大きすぎる場合、またはクラスターのサービス間への影響を避けたい場合は、データベースを分割できます。 +- データベースの再配置: データ センターの変更など、データベースを物理的に再配置します。 +- 新しいバージョンの TiDB クラスターにデータを移行する: データのセキュリティと精度の要件を満たすために、新しいバージョンの TiDB クラスターにデータを移行します。 このドキュメントでは、移行プロセス全体を例示し、次の手順について説明します。 -1. 環境を設定します。 +1. 環境を設定します。 -2. 全データを移行します。 +2. 全データを移行します。 -3. 増分データを移行します。 +3. 増分データを移行します。 -4. サービスを新しい TiDB クラスターに移行します。 +4. サービスを新しい TiDB クラスターに移行します。 ## ステップ1. 環境を設定する {#step-1-set-up-the-environment} -1. TiDB クラスターをデプロイ。 +1. TiDB クラスターをデプロイ。 TiUP Playgroundを使用して、アップストリームとダウンストリームにそれぞれ1つずつ、2つのTiDBクラスタをデプロイ。詳細については、 [TiUPを使用してオンライン TiDBクラスタをデプロイおよび管理](/tiup/tiup-cluster.md)を参照してください。 @@ -36,7 +36,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー tiup status ``` -2. データを初期化します。 +2. データを初期化します。 デフォルトでは、新しくデプロイされたクラスターにテストデータベースが作成されます。そのため、 [Sysbench](https://github.com/akopytov/sysbench#linux)を使用してテストデータを生成し、実際のシナリオでデータをシミュレートできます。 @@ -59,7 +59,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー rate=100 # Set average TPS to 100 ``` -3. サービスのワークロードをシミュレートします。 +3. サービスのワークロードをシミュレートします。 実際のシナリオでは、サービスデータは上流クラスターに継続的に書き込まれます。このドキュメントでは、sysbenchを使用してこのワークロードをシミュレートします。具体的には、以下のコマンドを実行して、10人のワーカーが3つのテーブル（sbtest1、sbtest2、sbtest3）に継続的にデータを書き込むようにし、合計TPSが100を超えないようにします。 @@ -67,7 +67,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー sysbench oltp_write_only --config-file=./tidb-config --tables=3 run ``` -4. 外部ストレージを準備します。 +4. 外部ストレージを準備します。 フルデータバックアップでは、上流クラスターと下流クラスターの両方がバックアップファイルにアクセスする必要があります。バックアップファイルの保存には[外部ストレージ](/br/backup-and-restore-storages.md)を使用することをお勧めします。このドキュメントでは、Minioを使用してS3互換ストレージサービスをシミュレートします。 @@ -86,10 +86,10 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー 上記のコマンドは、S3サービスをシミュレートするために、1つのノードでminioサーバーを起動します。コマンドのパラメータは以下のように設定されています。 - - エンドポイント: `http://${HOST_IP}:6060/` - - アクセスキー: `minio` - - シークレットアクセスキー: `miniostorage` - - バケット: `backup` + - エンドポイント: `http://${HOST_IP}:6060/` + - アクセスキー: `minio` + - シークレットアクセスキー: `miniostorage` + - バケット: `backup` アクセスリンクは以下のとおりです。 @@ -103,11 +103,11 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー > **Note:** > -> - `BACKUP`と`RESTORE` SQL 文は実験的です。本番環境での使用は推奨されません。予告なく変更または削除される可能性があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - 本番のクラスタでは、GCを無効にしてバックアップを実行すると、クラスタのパフォーマンスに影響する可能性があります。パフォーマンスの低下を防ぐため、オフピーク時にデータのバックアップを実行し、 `RATE_LIMIT`適切な値に設定することをお勧めします。 -> - アップストリームクラスタとダウンストリームクラスタのバージョンが異なる場合は、 [BR互換性](/br/backup-and-restore-overview.md#before-you-use)を確認する必要があります。このドキュメントでは、アップストリームクラスタとダウンストリームクラスタは同じバージョンであると想定しています。 +> - `BACKUP`と`RESTORE` SQL 文は実験的です。本番環境での使用は推奨されません。予告なく変更または削除される可能性があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)を報告してください。 +> - 本番のクラスタでは、GCを無効にしてバックアップを実行すると、クラスタのパフォーマンスに影響する可能性があります。パフォーマンスの低下を防ぐため、オフピーク時にデータのバックアップを実行し、 `RATE_LIMIT`適切な値に設定することをお勧めします。 +> - アップストリームクラスタとダウンストリームクラスタのバージョンが異なる場合は、 [BR互換性](/br/backup-and-restore-overview.md#before-you-use)を確認する必要があります。このドキュメントでは、アップストリームクラスタとダウンストリームクラスタは同じバージョンであると想定しています。 -1. GC を無効にします。 +1. GC を無効にします。 増分マイグレーション中に新しく書き込まれたデータが削除されないようにするには、バックアップ前に上流クラスターのGCを無効にする必要があります。これにより、履歴データが削除されなくなります。 @@ -140,7 +140,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)を参照してください。 -2. データをバックアップします。 +2. データをバックアップします。 データをバックアップするには、アップストリーム クラスターで`BACKUP`ステートメントを実行します。 @@ -159,7 +159,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー `BACKUP`コマンドの実行後、TiDB はバックアップデータに関するメタデータを返します。`BackupTS`より前に生成されたデータがバックアップされるため、ご注意ください。このドキュメントでは、 `BackupTS`を**データチェックの終了**と**TiCDC による増分移行スキャンの開始**として使用します。 -3. データを復元します。 +3. データを復元します。 ダウンストリーム クラスターで`RESTORE`コマンドを実行してデータを復元します。 @@ -176,7 +176,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー 1 row in set (41.85 sec) ``` -4. (オプション) データを検証します。 +4. (オプション) データを検証します。 [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)を使用すると、特定の時刻における上流と下流のデータの整合性を確認できます。上記の`BACKUP`出力は、上流クラスターが 431434047157698561 にバックアップを完了したことを示しています。上記の`RESTORE`出力は、下流クラスターが 431434141450371074 に復元を完了したことを示しています。 @@ -212,11 +212,11 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー ## ステップ3. 増分データの移行 {#step-3-migrate-incremental-data} -1. TiCDCをデプロイ。 +1. TiCDCをデプロイ。 完全なデータ移行が完了したら、増分データをレプリケーションするためのTiCDCをデプロイして設定します。本番環境では、 [TiCDCをデプロイ](/ticdc/deploy-ticdc.md)の手順に従ってTiCDCをデプロイしてください。このドキュメントでは、テストクラスターの作成時にTiCDCノードが起動済みであるため、TiCDCのデプロイ手順をスキップして、変更フィードの設定に進むことができます。 -2. 変更フィードを作成します。 +2. 変更フィードを作成します。 アップストリーム クラスターで次のコマンドを実行して、アップストリーム クラスターからダウンストリーム クラスターへの変更フィードを作成します。 @@ -226,14 +226,14 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー このコマンドのパラメータは次のとおりです。 - - `--server` : TiCDC クラスター内の任意のノードの IP アドレス - - `--sink-uri` : 下流クラスタのURI - - `--changefeed-id` : チェンジフィードID。正規表現の形式である必要があります。^[a-zA-Z0-9]+(-[a-zA-Z0-9]+)*$ - - `--start-ts` : 変更フィードの開始タイムスタンプ。バックアップ時刻である必要があります (または[ステップ2. 全データを移行する](#step-2-migrate-full-data)の「データのバックアップ」セクションの BackupTS) + - `--server` : TiCDC クラスター内の任意のノードの IP アドレス + - `--sink-uri` : 下流クラスタのURI + - `--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)を参照してください。 -3. GC を有効にします。 +3. GC を有効にします。 TiCDCを用いた増分移行では、GCは複製された履歴データのみを削除します。そのため、変更フィードを作成した後、以下のコマンドを実行してGCを有効にする必要があります。詳細は[TiCDCガベージコレクション(GC) セーフポイントの完全な動作は何ですか?](/ticdc/ticdc-faq.md#what-is-the-complete-behavior-of-ticdc-garbage-collection-gc-safepoint)を参照してください。 @@ -266,7 +266,7 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー チェンジフィードを作成すると、上流クラスターに書き込まれたデータが低レイテンシーで下流クラスターに複製されます。読み取りトラフィックを下流クラスターに徐々に移行できます。しばらく観察してください。下流クラスターが安定している場合は、以下の手順で書き込みトラフィックを下流クラスターに移行できます。 -1. アップストリームクラスタの書き込みサービスを停止します。変更フィードを停止する前に、アップストリームのすべてのデータがダウンストリームに複製されていることを確認してください。 +1. アップストリームクラスタの書き込みサービスを停止します。変更フィードを停止する前に、アップストリームのすべてのデータがダウンストリームに複製されていることを確認してください。 ```shell # Stop the changefeed from the upstream cluster to the downstream cluster @@ -290,10 +290,10 @@ summary: ある TiDB クラスターから別の TiDB クラスターにデー ] ``` -2. ダウンストリームからアップストリームへのチェンジフィードを作成します。アップストリームとダウンストリームのデータは一致しており、クラスターに新しいデータが書き込まれていないため、デフォルト設定を使用するには`start-ts`を指定しないでください。 +2. ダウンストリームからアップストリームへのチェンジフィードを作成します。アップストリームとダウンストリームのデータは一致しており、クラスターに新しいデータが書き込まれていないため、デフォルト設定を使用するには`start-ts`を指定しないでください。 ```shell tiup cdc cli changefeed create --server=http://172.16.6.125:8300 --sink-uri="mysql://root:@172.16.6.122:4000" --changefeed-id="downstream -to-upstream" ``` -3. 書き込みサービスを下流クラスターに移行した後、しばらく観察します。下流クラスターが安定している場合は、上流クラスターを破棄できます。 +3. 書き込みサービスを下流クラスターに移行した後、しばらく観察します。下流クラスターが安定している場合は、上流クラスターを破棄できます。 diff --git a/migrate-from-vitess.md b/migrate-from-vitess.md index 2e4ad2d2af018..b8776efd392a7 100644 --- a/migrate-from-vitess.md +++ b/migrate-from-vitess.md @@ -13,8 +13,8 @@ VitessのバックエンドはMySQLベースであるため、VitessからTiDB データ サイズが 10 TiB を超える場合は、2 つの手順でインポートを実行することをお勧めします。 -1. 既存のデータをインポートするには、 DumplingとTiDB Lightning を使用します。 -2. DM を使用して増分データをインポートします。 +1. 既存のデータをインポートするには、 DumplingとTiDB Lightning を使用します。 +2. DM を使用して増分データをインポートします。 これらのツールに加えて、 [Vitess用Debeziumコネクタ](https://debezium.io/documentation/reference/connectors/vitess.html)も使用できます。このコネクタを使用すると、 [Kafka Connect](https://kafka.apache.org/documentation/#connect)または[Apache Flink](https://nightlies.apache.org/flink/flink-docs-stable/)を使用して、Vitess から TiDB に変更をストリーミングできます。 @@ -26,11 +26,11 @@ 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) -- この例では、 TiDB Lightning は[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を使用してデータを TiKV に直接取り込みます。 +- この例では、 TiDB Lightning は[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を使用してデータを TiKV に直接取り込みます。 ![Vitess to TiDB Migration with local backend](/media/vitess_to_tidb_dumpling_local.png) diff --git a/migrate-large-mysql-shards-to-tidb.md b/migrate-large-mysql-shards-to-tidb.md index cf3663bda05b0..3f70b6f7cae3b 100644 --- a/migrate-large-mysql-shards-to-tidb.md +++ b/migrate-large-mysql-shards-to-tidb.md @@ -15,25 +15,25 @@ MySQL シャードのデータ サイズが 1 TiB 未満の場合は、[小規 このドキュメントでは、以下の手順に従ってデータを移行する方法を説明します。 -1. Dumplingを使用して完全なデータをエクスポートします。この例では、2つの上流データベースからそれぞれ2つのテーブルをエクスポートします。 +1. Dumplingを使用して完全なデータをエクスポートします。この例では、2つの上流データベースからそれぞれ2つのテーブルをエクスポートします。 - - `table1`から`table2`と`my_db1`をエクスポートします。 - - `table3`から`table4`と`my_db2`をエクスポートします。 + - `table1`から`table2`と`my_db1`をエクスポートします。 + - `table3`から`table4`と`my_db2`をエクスポートします。 -2. TiDB Lightning を起動して、データを TiDB の`mydb.table5`に移行します。 +2. TiDB Lightning を起動して、データを TiDB の`mydb.table5`に移行します。 -3. （オプション）TiDB DMを使用して増分レプリケーションを実行します。 +3. （オプション）TiDB DMを使用して増分レプリケーションを実行します。 ## 前提条件 {#prerequisites} 作業を開始する前に、移行作業の準備として以下のドキュメントを参照してください。 -- [TiUPを使用してDMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md) -- [TiUPを使用してDumplingとライトニングをデプロイ](/migration-tools.md) -- [Dumplingに必要なターゲットデータベース権限](/dumpling-overview.md#export-data-from-tidb-or-mysql) -- [TiDB Lightningに必要なターゲットデータベース権限](/tidb-lightning/tidb-lightning-requirements.md) -- [TiDB Lightningのダウンストリームストレージスペース](/tidb-lightning/tidb-lightning-requirements.md) -- [DMワーカーに必要な権限](/dm/dm-worker-intro.md) +- [TiUPを使用してDMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md) +- [TiUPを使用してDumplingとライトニングをデプロイ](/migration-tools.md) +- [Dumplingに必要なターゲットデータベース権限](/dumpling-overview.md#export-data-from-tidb-or-mysql) +- [TiDB Lightningに必要なターゲットデータベース権限](/tidb-lightning/tidb-lightning-requirements.md) +- [TiDB Lightningのダウンストリームストレージスペース](/tidb-lightning/tidb-lightning-requirements.md) +- [DMワーカーに必要な権限](/dm/dm-worker-intro.md) ### シャーディングされたテーブルの競合をチェックする {#check-conflicts-for-sharded-tables} @@ -118,9 +118,9 @@ TiDB Lightningによる移行を開始する前に、チェックポイントの TiDB Lightningタスクが回復不能なエラー（データ破損など）によりクラッシュした場合、チェックポイントから再開せず、エラーを報告してタスクを終了します。インポートされたデータの安全性を確保するため、他の手順に進む前に`tidb-lightning-ctl`コマンドを使用してこれらのエラーを解決する必要があります。オプションは次のとおりです。 -- --checkpoint-error-destroy: このオプションを使用すると、失敗したターゲット テーブルへのデータインポートを最初からやり直すことができます。そのためには、まずそれらのテーブル内の既存のデータをすべて削除する必要があります。 -- --checkpoint-error-ignore: マイグレーションが失敗した場合、このオプションはエラーが発生しなかったかのようにエラー状態をクリアします。 -- --checkpoint-remove: このオプションは、エラーの有無に関わらず、すべてのチェックポイントを削除します。 +- --checkpoint-error-destroy: このオプションを使用すると、失敗したターゲット テーブルへのデータインポートを最初からやり直すことができます。そのためには、まずそれらのテーブル内の既存のデータをすべて削除する必要があります。 +- --checkpoint-error-ignore: マイグレーションが失敗した場合、このオプションはエラーが発生しなかったかのようにエラー状態をクリアします。 +- --checkpoint-remove: このオプションは、エラーの有無に関わらず、すべてのチェックポイントを削除します。 詳細については、 [TiDB Lightningチェックポイント](/tidb-lightning/tidb-lightning-checkpoints.md)を参照してください。 @@ -143,7 +143,7 @@ CREATE TABLE `table5` ( `tidb-lightning`を開始するには、以下の手順に従ってください。 -1. toml ファイルを編集します。次の例では`tidb-lightning.toml`が使用されています。 +1. toml ファイルを編集します。次の例では`tidb-lightning.toml`が使用されています。 ```toml [lightning] @@ -193,7 +193,7 @@ CREATE TABLE `table5` ( pd-addr = "${ip}:${port}" ``` -2. `tidb-lightning`を実行します。シェルでプログラム名を直接呼び出してプログラムを実行すると、SIGHUP シグナルを受信した後にプロセスが予期せず終了する可能性があります。 `nohup` 、 `screen` 、 `tiup`などのツールを使用してプログラムを実行し、プロセスをシェルのバックグラウンドで実行することをお勧めします。S3 から移行する場合は、Amazon S3 バックエンド ストアにアクセスできるアカウントの SecretKey と AccessKey を環境変数として Lightning ノードに渡す必要があります。 `~/.aws/credentials`からの認証情報ファイルの読み取りもサポートされています。例: +2. `tidb-lightning`を実行します。シェルでプログラム名を直接呼び出してプログラムを実行すると、SIGHUP シグナルを受信した後にプロセスが予期せず終了する可能性があります。 `nohup` 、 `screen` 、 `tiup`などのツールを使用してプログラムを実行し、プロセスをシェルのバックグラウンドで実行することをお勧めします。S3 から移行する場合は、Amazon S3 バックエンド ストアにアクセスできるアカウントの SecretKey と AccessKey を環境変数として Lightning ノードに渡す必要があります。 `~/.aws/credentials`からの認証情報ファイルの読み取りもサポートされています。例: ```shell export AWS_ACCESS_KEY_ID=${access_key} @@ -201,10 +201,10 @@ CREATE TABLE `table5` ( nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out 2>&1 & ``` -3. 移行タスクを開始した後、以下のいずれかの方法で進捗状況を確認できます。 +3. 移行タスクを開始した後、以下のいずれかの方法で進捗状況を確認できます。 - - `grep`ツールを使用して、ログファイル内でキーワード`progress`を検索してください。デフォルトでは、進行状況を報告するメッセージが5分ごとにログファイルに書き込まれます。 - - 監視ダッシュボードから進捗状況を確認します。詳細については、 [TiDB Lightningモニタリング](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 + - `grep`ツールを使用して、ログファイル内でキーワード`progress`を検索してください。デフォルトでは、進行状況を報告するメッセージが5分ごとにログファイルに書き込まれます。 + - 監視ダッシュボードから進捗状況を確認します。詳細については、 [TiDB Lightningモニタリング](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 @@ -357,25 +357,25 @@ tiup dmctl --master-addr ${advertise-addr} query-status ${task-name} 移行タスクの履歴や内部運用指標は、Grafanaまたはログを通じて確認できます。 -- Grafana経由 +- Grafana経由 TiUPを使用してDMクラスタをデプロイする際に、Prometheus、Alertmanager、およびGrafanaが正しくデプロイされていれば、GrafanaでDMの監視メトリクスを表示できます。具体的には、デプロイ時に指定したIPアドレスとポートをGrafanaに入力し、DMダッシュボードを選択してください。 -- ログ経由 +- ログ経由 DMが実行されている場合、DM-master、DM-worker、およびdmctlは、移行タスクに関する情報を含むログを出力します。各コンポーネントのログディレクトリは以下のとおりです。 - - DM-master ログディレクトリ: これは、DM-master コマンドラインパラメータ`--log-file`で指定されます。DM がTiUPを使用してデプロイされている場合、ログディレクトリは`/dm-deploy/dm-master-8261/log/`です。 - - DM-worker のログ ディレクトリ: これは、DM-worker コマンドライン パラメータ`--log-file`で指定されます。DM がTiUPを使用してデプロイされている場合、ログ ディレクトリは`/dm-deploy/dm-worker-8262/log/`です。 + - DM-master ログディレクトリ: これは、DM-master コマンドラインパラメータ`--log-file`で指定されます。DM がTiUPを使用してデプロイされている場合、ログディレクトリは`/dm-deploy/dm-master-8261/log/`です。 + - DM-worker のログ ディレクトリ: これは、DM-worker コマンドライン パラメータ`--log-file`で指定されます。DM がTiUPを使用してデプロイされている場合、ログ ディレクトリは`/dm-deploy/dm-worker-8262/log/`です。 ## 関連項目 {#see-also} -- [Dumpling](/dumpling-overview.md) -- [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) -- [悲観的モードと楽観的モード](/dm/feature-shard-merge.md) -- [データ移行タスクを一時停止する](/dm/dm-pause-task.md) -- [データ移行タスクを再開する](/dm/dm-resume-task.md) -- [データ移行タスクを停止する](/dm/dm-stop-task.md) -- [クラスターのデータソースのエクスポートとインポート、およびタスクコンフィグレーション](/dm/dm-export-import-config.md) -- [失敗したDDLステートメントを処理する](/dm/handle-failed-ddl-statements.md) -- [エラーを処理する](/dm/dm-error-handling.md) +- [Dumpling](/dumpling-overview.md) +- [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) +- [悲観的モードと楽観的モード](/dm/feature-shard-merge.md) +- [データ移行タスクを一時停止する](/dm/dm-pause-task.md) +- [データ移行タスクを再開する](/dm/dm-resume-task.md) +- [データ移行タスクを停止する](/dm/dm-stop-task.md) +- [クラスターのデータソースのエクスポートとインポート、およびタスクコンフィグレーション](/dm/dm-export-import-config.md) +- [失敗したDDLステートメントを処理する](/dm/handle-failed-ddl-statements.md) +- [エラーを処理する](/dm/dm-error-handling.md) diff --git a/migrate-large-mysql-to-tidb.md b/migrate-large-mysql-to-tidb.md index e39d07ed7435c..e180ab85f8ba0 100644 --- a/migrate-large-mysql-to-tidb.md +++ b/migrate-large-mysql-to-tidb.md @@ -11,11 +11,11 @@ summary: MySQLからTiDBへ大規模データセットを移行する方法を ## 前提条件 {#prerequisites} -- [DMをインストール](/dm/deploy-a-dm-cluster-using-tiup.md)。 -- [DumplingとTiDB Lightningをインストールする](/migration-tools.md)。 -- [DMに必要なソースデータベースとターゲットデータベースの権限を付与します](/dm/dm-worker-intro.md) -- [TiDB Lightningに必要なターゲットデータベース権限を付与します](/tidb-lightning/tidb-lightning-faq.md#what-are-the-privilege-requirements-for-the-target-database) -- [Dumplingに必要なソースデータベース権限を付与する](/dumpling-overview.md#export-data-from-tidb-or-mysql)。 +- [DMをインストール](/dm/deploy-a-dm-cluster-using-tiup.md)。 +- [DumplingとTiDB Lightningをインストールする](/migration-tools.md)。 +- [DMに必要なソースデータベースとターゲットデータベースの権限を付与します](/dm/dm-worker-intro.md) +- [TiDB Lightningに必要なターゲットデータベース権限を付与します](/tidb-lightning/tidb-lightning-faq.md#what-are-the-privilege-requirements-for-the-target-database) +- [Dumplingに必要なソースデータベース権限を付与する](/dumpling-overview.md#export-data-from-tidb-or-mysql)。 ## リソース要件 {#resource-requirements} @@ -25,9 +25,9 @@ summary: MySQLからTiDBへ大規模データセットを移行する方法を **ディスク容量**： -- Dumplingには、データソース全体を保存できる（またはエクスポートされるすべての上流テーブルを保存できる）ディスク容量が必要です。SSD推奨です。必要なスペースを計算するには、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。 -- インポート処理中、 TiDB Lightningはソート済みのキーと値のペアを保存するための一時的な領域を必要とします。ディスク容量は、データソースの最大の単一テーブルを格納できるのに十分な量が必要です。 -- データ総量が大きい場合は、上流側のbinlogの保存期間を延長することができます。これは、増分レプリケーション中にバイナリログが失われないようにするためです。 +- Dumplingには、データソース全体を保存できる（またはエクスポートされるすべての上流テーブルを保存できる）ディスク容量が必要です。SSD推奨です。必要なスペースを計算するには、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。 +- インポート処理中、 TiDB Lightningはソート済みのキーと値のペアを保存するための一時的な領域を必要とします。ディスク容量は、データソースの最大の単一テーブルを格納できるのに十分な量が必要です。 +- データ総量が大きい場合は、上流側のbinlogの保存期間を延長することができます。これは、増分レプリケーション中にバイナリログが失われないようにするためです。 **注**： DumplingによってMySQLからエクスポートされる正確なデータ量を計算することは困難ですが、次のSQLステートメントを使用して`information_schema.tables`テーブルの`DATA_LENGTH`フィールドを要約することで、データ量を推定できます。 @@ -64,12 +64,12 @@ LIMIT ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットの TiKV クラスターのストレージ容量は**、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、ターゲットの TiKV クラスターは、データソースのサイズの 6 倍よりも大きなストレージ容量が必要です。この式に`x 2`が含まれている理由は次のとおりです。 -- インデックスには余分な容量が必要になる場合があります。 -- RocksDBには空間増幅がある。 +- インデックスには余分な容量が必要になる場合があります。 +- RocksDBには空間増幅がある。 ## ステップ1. MySQLからすべてのデータをエクスポートする {#step-1-export-all-data-from-mysql} -1. 以下のコマンドを実行して、MySQLからすべてのデータをエクスポートします。 +1. 以下のコマンドを実行して、MySQLからすべてのデータをエクスポートします。 ```shell tiup dumpling -h ${ip} -P 3306 -u root -t 16 -r 200000 -F 256MiB -B my_db1 -f 'my_db1.table[12]' -o 's3://my-bucket/sql-backup' @@ -94,7 +94,7 @@ LIMIT `${data-path}`には、エクスポートされたすべての上流テーブルを保存するのに十分な空き容量があることを確認してください。必要な容量を計算するには、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。大きなテーブルがすべてのスペースを消費してエクスポートが中断されるのを防ぐため、 `-F`オプションを使用して単一ファイルのサイズを制限することを強くお勧めします。 -2. `${data-path}`ディレクトリにある`metadata`ファイルを確認します。これは、Dumpling によって生成されたメタデータ ファイルです。ステップ 3 の増分レプリケーションに必要なbinlogの位置情報を記録します。 +2. `${data-path}`ディレクトリにある`metadata`ファイルを確認します。これは、Dumpling によって生成されたメタデータ ファイルです。ステップ 3 の増分レプリケーションに必要なbinlogの位置情報を記録します。 ``` SHOW MASTER STATUS: @@ -105,7 +105,7 @@ LIMIT ## ステップ2. TiDBに全データをインポートする {#step-2-import-full-data-to-tidb} -1. `tidb-lightning.toml`設定ファイルを作成します。 +1. `tidb-lightning.toml`設定ファイルを作成します。 ```toml [lightning] @@ -136,7 +136,7 @@ LIMIT TiDB Lightning構成の詳細については、 [TiDB Lightning のコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 -2. `tidb-lightning`を実行してインポートを開始します。コマンドラインでプログラムを直接起動すると、SIGHUP シグナルを受信した後にプロセスが予期せず終了する可能性があります。 `nohup`を使用してコマンドラインからプロセスを直接起動することは推奨されません。代わりに、次のスクリプトの内容を編集してください。例: +2. `tidb-lightning`を実行してインポートを開始します。コマンドラインでプログラムを直接起動すると、SIGHUP シグナルを受信した後にプロセスが予期せず終了する可能性があります。 `nohup`を使用してコマンドラインからプロセスを直接起動することは推奨されません。代わりに、次のスクリプトの内容を編集してください。例: S3 からデータをインポートする場合は、S3ストレージパスにアクセスできる SecretKey と AccessKey を環境変数としてTiDB Lightningノードに渡してください。また、 `~/.aws/credentials`から認証情報を読み取ることもできます。 @@ -149,12 +149,12 @@ LIMIT 次に、スクリプトを使用してTiDB Lightning を起動します。 -3. インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 +3. インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 - - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 - - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進捗状況を確認します。 + - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 + - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進捗状況を確認します。 -4. TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 +4. TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 > **Note:** > @@ -166,7 +166,7 @@ LIMIT ### データソースを追加する {#add-the-data-source} -1. `source1.yaml`ファイルを作成します。 +1. `source1.yaml`ファイルを作成します。 ```yaml # Must be unique. @@ -182,7 +182,7 @@ LIMIT port: 3306 ``` -2. 次のコマンドを実行して、 `tiup dmctl`を使用してデータソース構成を DM クラスターにロードします。 +2. 次のコマンドを実行して、 `tiup dmctl`を使用してデータソース構成を DM クラスターにロードします。 ```shell tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml @@ -197,7 +197,7 @@ LIMIT ### レプリケーションタスクを追加する {#add-a-replication-task} -1. `task.yaml`ファイルを編集します。増分レプリケーションモードと各データソースの開始点を設定します。 +1. `task.yaml`ファイルを編集します。増分レプリケーションモードと各データソースの開始点を設定します。 ```yaml name: task-test # Task name. Must be globally unique. @@ -240,7 +240,7 @@ LIMIT tiup dmctl --master-addr ${advertise-addr} check-task task.yaml ``` -2. 以下のコマンドを実行して、移行タスクを開始します。 +2. 以下のコマンドを実行して、移行タスクを開始します。 ```shell tiup dmctl --master-addr ${advertise-addr} start-task task.yaml @@ -275,13 +275,13 @@ TiUPを使用してDMをデプロイした際に、Prometheus、Alertmanager、 DMが実行されている間、DM-worker、DM-master、およびdmctlは関連情報をログに出力します。これらのコンポーネントのログディレクトリは以下のとおりです。 -- DM-master: DM-master プロセス パラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログ ディレクトリはデフォルトで`/dm-deploy/dm-master-8261/log/`になります。 -- DM-worker: DM-worker プロセス パラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログ ディレクトリはデフォルトで`/dm-deploy/dm-worker-8262/log/`になります。 +- DM-master: DM-master プロセス パラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログ ディレクトリはデフォルトで`/dm-deploy/dm-master-8261/log/`になります。 +- DM-worker: DM-worker プロセス パラメータ`--log-file`で指定されます。TiUPを使用して DM をデプロイする場合、ログ ディレクトリはデフォルトで`/dm-deploy/dm-worker-8262/log/`になります。 ## 次は？ {#what-s-next} -- [データ移行タスクを一時停止する](/dm/dm-pause-task.md) -- [データ移行タスクを再開する](/dm/dm-resume-task.md) -- [データ移行タスクを停止する](/dm/dm-stop-task.md) -- [クラスターのデータソースのエクスポートとインポート、およびタスクコンフィグレーション](/dm/dm-export-import-config.md) -- [失敗したDDLステートメントを処理する](/dm/handle-failed-ddl-statements.md) +- [データ移行タスクを一時停止する](/dm/dm-pause-task.md) +- [データ移行タスクを再開する](/dm/dm-resume-task.md) +- [データ移行タスクを停止する](/dm/dm-stop-task.md) +- [クラスターのデータソースのエクスポートとインポート、およびタスクコンフィグレーション](/dm/dm-export-import-config.md) +- [失敗したDDLステートメントを処理する](/dm/handle-failed-ddl-statements.md) diff --git a/migrate-small-mysql-shards-to-tidb.md b/migrate-small-mysql-shards-to-tidb.md index 3042179c9804c..4b56318a48d22 100644 --- a/migrate-small-mysql-shards-to-tidb.md +++ b/migrate-small-mysql-shards-to-tidb.md @@ -28,8 +28,8 @@ summary: シャードの小さなデータセットを MySQL から TiDB に移 移行を開始する前に、次のタスクが完了していることを確認してください。 -- [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md) -- [DMワーカーに必要な権限](/dm/dm-worker-intro.md) +- [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md) +- [DMワーカーに必要な権限](/dm/dm-worker-intro.md) ### シャードテーブルの競合をチェックする {#check-conflicts-for-the-sharded-tables} @@ -170,10 +170,10 @@ block-allow-list: # filter or only migrate all operations of some data タスク ファイル内の`routes` 、およびその他`filters`構成の詳細については、次のドキュメントを参照してください。 -- [テーブルルーティング](/dm/dm-table-routing.md) -- [ブロックと許可のテーブルリスト](/dm/dm-block-allow-table-lists.md) -- [Binlogイベントフィルター](/filter-binlog-event.md) -- [SQL 式を使用して特定の行の変更をフィルタリングする](/filter-dml-event.md) +- [テーブルルーティング](/dm/dm-table-routing.md) +- [ブロックと許可のテーブルリスト](/dm/dm-block-allow-table-lists.md) +- [Binlogイベントフィルター](/filter-binlog-event.md) +- [SQL 式を使用して特定の行の変更をフィルタリングする](/filter-dml-event.md) ## ステップ3. タスクを開始する {#step-3-start-the-task} @@ -210,22 +210,22 @@ tiup dmctl --master-addr ${advertise-addr} query-status ${task-name} Grafana またはログを通じて、移行タスクの履歴と内部運用メトリックを表示できます。 -- Grafana経由 +- Grafana経由 TiUPを使用してDMクラスターをデプロイする際に、Prometheus、Alertmanager、Grafanaが正しくデプロイされていれば、GrafanaでDMの監視メトリクスを確認できます。具体的には、デプロイ時に指定したIPアドレスとポート番号をGrafanaに入力し、DMダッシュボードを選択してください。 -- ログ経由 +- ログ経由 DM の実行中、DM-master、DM-worker、dmctl は、移行タスクに関する情報を含むログを出力します。各コンポーネントのログディレクトリは以下のとおりです。 - - DMマスターログディレクトリ：DMマスタープロセスパラメータ`--log-file`で指定されます。DMがTiUPを使用して展開されている場合、ログディレクトリは`/dm-deploy/dm-master-8261/log/`です。 - - DMワーカーログディレクトリ：DMワーカープロセスパラメータ`--log-file`で指定します。DMがTiUPを使用してデプロイされている場合、ログディレクトリは`/dm-deploy/dm-worker-8262/log/`です。 + - DMマスターログディレクトリ：DMマスタープロセスパラメータ`--log-file`で指定されます。DMがTiUPを使用して展開されている場合、ログディレクトリは`/dm-deploy/dm-master-8261/log/`です。 + - DMワーカーログディレクトリ：DMワーカープロセスパラメータ`--log-file`で指定します。DMがTiUPを使用してデプロイされている場合、ログディレクトリは`/dm-deploy/dm-worker-8262/log/`です。 ## 参照 {#see-also} -- [大規模データセットの MySQL シャードを TiDB に移行およびマージする](/migrate-large-mysql-shards-to-tidb.md) 。 -- [シャードテーブルからのデータのマージと移行](/dm/feature-shard-merge.md) -- [シャード統合シナリオにおけるデータ移行のベストプラクティス](/dm/shard-merge-best-practices.md) -- [エラーの処理](/dm/dm-error-handling.md) -- [パフォーマンスの問題に対処する](/dm/dm-handle-performance-issues.md) -- [FAQ](/dm/dm-faq.md) +- [大規模データセットの MySQL シャードを TiDB に移行およびマージする](/migrate-large-mysql-shards-to-tidb.md) 。 +- [シャードテーブルからのデータのマージと移行](/dm/feature-shard-merge.md) +- [シャード統合シナリオにおけるデータ移行のベストプラクティス](/dm/shard-merge-best-practices.md) +- [エラーの処理](/dm/dm-error-handling.md) +- [パフォーマンスの問題に対処する](/dm/dm-handle-performance-issues.md) +- [FAQ](/dm/dm-faq.md) diff --git a/migrate-small-mysql-to-tidb.md b/migrate-small-mysql-to-tidb.md index 4d1570e0d7c87..3efe5228ec9be 100644 --- a/migrate-small-mysql-to-tidb.md +++ b/migrate-small-mysql-to-tidb.md @@ -13,8 +13,8 @@ summary: 小さなデータセットを MySQL から TiDB に移行する方法 ## 前提条件 {#prerequisites} -- [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md) -- [DMのソースデータベースとターゲットデータベースに必要な権限を付与します](/dm/dm-worker-intro.md) +- [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md) +- [DMのソースデータベースとターゲットデータベースに必要な権限を付与します](/dm/dm-worker-intro.md) ## ステップ1. データソースを作成する {#step-1-create-the-data-source} @@ -124,13 +124,13 @@ tiup dmctl --master-addr ${advertise-addr} query-status ${task-name} TiUPを使用して DM をデプロイする際に Prometheus、Alertmanager、Grafana をデプロイしている場合は、デプロイ時に指定した IP アドレスとポートを使用して Grafana にアクセスできます。その後、DM ダッシュボードを選択して、DM 関連の監視メトリクスを表示できます。 -- DMマスターのログディレクトリ：DMマスタープロセスパラメータ`--log-file`で指定されます。TiUPを使用してDMを展開した場合、ログディレクトリはデフォルトで`/dm-deploy/dm-master-8261/log/`なります。 -- DM-workerのログディレクトリ：DM-workerプロセスパラメータ`--log-file`で指定されます。TiUPを使用してDMをデプロイした場合、デフォルトのログディレクトリは`/dm-deploy/dm-worker-8262/log/`です。 +- DMマスターのログディレクトリ：DMマスタープロセスパラメータ`--log-file`で指定されます。TiUPを使用してDMを展開した場合、ログディレクトリはデフォルトで`/dm-deploy/dm-master-8261/log/`なります。 +- DM-workerのログディレクトリ：DM-workerプロセスパラメータ`--log-file`で指定されます。TiUPを使用してDMをデプロイした場合、デフォルトのログディレクトリは`/dm-deploy/dm-worker-8262/log/`です。 ## 次は何？ {#what-s-next} -- [移行タスクを一時停止する](/dm/dm-pause-task.md) -- [移行タスクを再開する](/dm/dm-resume-task.md) -- [移行タスクを停止する](/dm/dm-stop-task.md) -- [クラスターデータソースとタスク構成をエクスポートおよびインポートする](/dm/dm-export-import-config.md) -- [失敗したDDL文を処理する](/dm/handle-failed-ddl-statements.md) +- [移行タスクを一時停止する](/dm/dm-pause-task.md) +- [移行タスクを再開する](/dm/dm-resume-task.md) +- [移行タスクを停止する](/dm/dm-stop-task.md) +- [クラスターデータソースとタスク構成をエクスポートおよびインポートする](/dm/dm-export-import-config.md) +- [失敗したDDL文を処理する](/dm/handle-failed-ddl-statements.md) diff --git a/migrate-with-more-columns-downstream.md b/migrate-with-more-columns-downstream.md index aa82b3bde1997..c5effbc833512 100644 --- a/migrate-with-more-columns-downstream.md +++ b/migrate-with-more-columns-downstream.md @@ -7,10 +7,10 @@ summary: 対応するアップストリーム テーブルよりも多くの列 このドキュメントでは、対応する上流テーブルよりも多くの列を持つ下流TiDBテーブルにデータを移行する際に必要な追加手順について説明します。通常の移行手順については、以下の移行シナリオをご覧ください。 -- [小規模データセットをMySQLからTiDBに移行する](/migrate-small-mysql-to-tidb.md) -- [大規模データセットをMySQLからTiDBに移行する](/migrate-large-mysql-to-tidb.md) -- [小さなデータセットの MySQL シャードを TiDB に移行してマージする](/migrate-small-mysql-shards-to-tidb.md) -- [大規模データセットの MySQL シャードを TiDB に移行およびマージする](/migrate-large-mysql-shards-to-tidb.md) +- [小規模データセットをMySQLからTiDBに移行する](/migrate-small-mysql-to-tidb.md) +- [大規模データセットをMySQLからTiDBに移行する](/migrate-large-mysql-to-tidb.md) +- [小さなデータセットの MySQL シャードを TiDB に移行してマージする](/migrate-small-mysql-shards-to-tidb.md) +- [大規模データセットの MySQL シャードを TiDB に移行およびマージする](/migrate-large-mysql-shards-to-tidb.md) ## DM を使用して、より多くの列を持つ下流の TiDB テーブルにデータを移行します {#use-dm-to-migrate-data-to-a-downstream-tidb-table-with-more-columns} @@ -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 @@ -65,7 +65,7 @@ DM がダウンストリーム テーブル スキーマを使用してアップ ) ``` -2. `binlog-schema`コマンドを使用して、データソースから移行するテーブルのテーブルスキーマを設定します。この時点で、データ移行タスクは上記の`Column count doesn't match`エラーにより一時停止状態になっているはずです。 +2. `binlog-schema`コマンドを使用して、データソースから移行するテーブルのテーブルスキーマを設定します。この時点で、データ移行タスクは上記の`Column count doesn't match`エラーにより一時停止状態になっているはずです。 {{< copyable "shell-regular" >}} @@ -93,7 +93,7 @@ DM がダウンストリーム テーブル スキーマを使用してアップ tiup dmctl --master-addr 172.16.10.71:8261 binlog-schema update -s mysql-01 task-test -d log -t message log.message.sql ``` -3. 一時停止状態の移行タスクを再開するには、 `resume-task`コマンドを使用します。 +3. 一時停止状態の移行タスクを再開するには、 `resume-task`コマンドを使用します。 {{< copyable "shell-regular" >}} @@ -101,7 +101,7 @@ DM がダウンストリーム テーブル スキーマを使用してアップ tiup dmctl --master-addr ${advertise-addr} resume-task ${task-name} ``` -4. `query-status`コマンドを使用して、データ移行タスクが正しく実行されていることを確認します。 +4. `query-status`コマンドを使用して、データ移行タスクが正しく実行されていることを確認します。 {{< copyable "shell-regular" >}} diff --git a/migrate-with-pt-ghost.md b/migrate-with-pt-ghost.md index 4314c03359c4a..d5ddaf75686a9 100644 --- a/migrate-with-pt-ghost.md +++ b/migrate-with-pt-ghost.md @@ -11,10 +11,10 @@ DM を使用して MySQL から TiDB にデータを移行する場合、 `onlin 詳細なレプリケーション手順については、シナリオごとに次のドキュメントを参照してください。 -- [小規模データセットをMySQLからTiDBに移行する](/migrate-small-mysql-to-tidb.md) -- [大規模データセットをMySQLからTiDBに移行する](/migrate-large-mysql-to-tidb.md) -- [小さなデータセットの MySQL シャードを TiDB に移行してマージする](/migrate-small-mysql-shards-to-tidb.md) -- [大規模データセットの MySQL シャードを TiDB に移行およびマージする](/migrate-large-mysql-shards-to-tidb.md) +- [小規模データセットをMySQLからTiDBに移行する](/migrate-small-mysql-to-tidb.md) +- [大規模データセットをMySQLからTiDBに移行する](/migrate-large-mysql-to-tidb.md) +- [小さなデータセットの MySQL シャードを TiDB に移行してマージする](/migrate-small-mysql-shards-to-tidb.md) +- [大規模データセットの MySQL シャードを TiDB に移行およびマージする](/migrate-large-mysql-shards-to-tidb.md) ## DM でオンライン DDL を有効にする {#enable-online-ddl-on-dm} @@ -36,31 +36,31 @@ DM で online-ddl を有効にすると、gh-ost または pt-osc を複製す gh-ost または pt-osc のワークフロー: -- DDL 実テーブルのテーブル スキーマに従ってゴースト テーブルを作成します。 +- DDL 実テーブルのテーブル スキーマに従ってゴースト テーブルを作成します。 -- ゴースト テーブルに DDL を適用します。 +- ゴースト テーブルに DDL を適用します。 -- DDL 実テーブルのデータをゴースト テーブルに複製します。 +- DDL 実テーブルのデータをゴースト テーブルに複製します。 -- 2 つのテーブル間でデータの一貫性が保たれたら、名前変更ステートメントを使用して実際のテーブルをゴースト テーブルに置き換えます。 +- 2 つのテーブル間でデータの一貫性が保たれたら、名前変更ステートメントを使用して実際のテーブルをゴースト テーブルに置き換えます。 DM のワークフロー: -- 下流のゴースト テーブルの作成をスキップします。 +- 下流のゴースト テーブルの作成をスキップします。 -- ゴースト テーブルに適用された DDL を記録します。 +- ゴースト テーブルに適用された DDL を記録します。 -- ゴースト テーブルからのみデータを複製します。 +- ゴースト テーブルからのみデータを複製します。 -- 下流に記録された DDL を適用します。 +- 下流に記録された DDL を適用します。 ![dm-online-ddl](/media/dm/dm-online-ddl.png) ワークフローの変更により、次のような利点がもたらされます。 -- ダウンストリーム TiDB はゴースト テーブルを作成して複製する必要がないため、ストレージスペースとネットワーク転送のオーバーヘッドが節約されます。 +- ダウンストリーム TiDB はゴースト テーブルを作成して複製する必要がないため、ストレージスペースとネットワーク転送のオーバーヘッドが節約されます。 -- シャード テーブルからデータを移行およびマージする場合、レプリケーションの正確性を確保するために、シャード ゴースト テーブルごとに RENAME 操作は無視されます。 +- シャード テーブルからデータを移行およびマージする場合、レプリケーションの正確性を確保するために、シャード ゴースト テーブルごとに RENAME 操作は無視されます。 ## 参照 {#see-also} diff --git a/migration-overview.md b/migration-overview.md index 03a22c57c5438..9226d2e4f79cf 100644 --- a/migration-overview.md +++ b/migration-overview.md @@ -7,18 +7,18 @@ summary: データ移行シナリオとソリューションの概要を学習 このドキュメントでは、TiDBで使用できるデータ移行ソリューションの概要を説明します。データ移行ソリューションは以下のとおりです。 -- 完全なデータ移行。 - - Amazon Auroraスナップショット、CSV ファイル、または SQL ダンプファイルを TiDB にインポートするには、 TiDB Lightningを使用して完全な移行を実行できます。 - - すべての TiDB データを CSV ファイルまたは SQL ダンプ ファイルとしてエクスポートするには、 Dumplingを使用して完全な移行を実行できます。これにより、MySQL または MariaDB からのデータ移行が容易になります。 - - データ サイズのボリュームが小さい (たとえば、1 TiB 未満) データベースからすべてのデータを移行するには、TiDB Data Migration (DM) を使用することもできます。 +- 完全なデータ移行。 + - Amazon Auroraスナップショット、CSV ファイル、または SQL ダンプファイルを TiDB にインポートするには、 TiDB Lightningを使用して完全な移行を実行できます。 + - すべての TiDB データを CSV ファイルまたは SQL ダンプ ファイルとしてエクスポートするには、 Dumplingを使用して完全な移行を実行できます。これにより、MySQL または MariaDB からのデータ移行が容易になります。 + - データ サイズのボリュームが小さい (たとえば、1 TiB 未満) データベースからすべてのデータを移行するには、TiDB Data Migration (DM) を使用することもできます。 -- TiDBのクイック初期化。TiDB Lightningは、データの高速インポートをサポートし、TiDB内の特定のテーブルを高速に初期化できます。この機能を使用する前に、クイック初期化はTiDBに大きな影響を与え、初期化中はクラスタがサービスを提供できないことにご注意ください。 +- TiDBのクイック初期化。TiDB Lightningは、データの高速インポートをサポートし、TiDB内の特定のテーブルを高速に初期化できます。この機能を使用する前に、クイック初期化はTiDBに大きな影響を与え、初期化中はクラスタがサービスを提供できないことにご注意ください。 -- 増分レプリケーション。TiDB DM を使用すると、MySQL、MariaDB、またはAuroraから TiDB にバイナリログをレプリケートできるため、レプリケーション期間中のウィンドウのダウンタイムが大幅に短縮されます。 +- 増分レプリケーション。TiDB DM を使用すると、MySQL、MariaDB、またはAuroraから TiDB にバイナリログをレプリケートできるため、レプリケーション期間中のウィンドウのダウンタイムが大幅に短縮されます。 -- TiDBクラスタ間のデータレプリケーション。TiDBはバックアップとリストアをサポートしています。この機能により、既存のTiDBクラスタのスナップショットを新しいTiDBクラスタに初期化できます。 +- TiDBクラスタ間のデータレプリケーション。TiDBはバックアップとリストアをサポートしています。この機能により、既存のTiDBクラスタのスナップショットを新しいTiDBクラスタに初期化できます。 -- TiDBクラスタ間の増分レプリケーション。TiDBは、同種データベース間のディザスタリカバリをサポートし、災害発生後のプライマリデータベースとセカンダリデータベースの最終的なデータ整合性を確保します。これは、プライマリクラスタとセカンダリクラスタの両方がTiDBである場合にのみ機能します。 +- TiDBクラスタ間の増分レプリケーション。TiDBは、同種データベース間のディザスタリカバリをサポートし、災害発生後のプライマリデータベースとセカンダリデータベースの最終的なデータ整合性を確保します。これは、プライマリクラスタとセカンダリクラスタの両方がTiDBである場合にのみ機能します。 データベースの種類、デプロイメントの場所、アプリケーションのデータサイズ、アプリケーションのニーズに応じて、さまざまな移行ソリューションを選択できます。以下のセクションでは、一般的な移行シナリオをいくつか紹介します。これらのセクションを参考に、ニーズに最適なソリューションを決定してください。 @@ -26,7 +26,7 @@ summary: データ移行シナリオとソリューションの概要を学習 Auroraから AWS にデプロイされた TiDB クラスターにデータを移行する場合、データ移行には完全なデータ移行と増分レプリケーションの 2 つの操作が必要です。アプリケーションのニーズに応じて、対応する操作を選択できます。 -- [Amazon Auroraから TiDB へのデータ移行](/migrate-aurora-to-tidb.md) 。 +- [Amazon Auroraから TiDB へのデータ移行](/migrate-aurora-to-tidb.md) 。 ## MySQLからTiDBへのデータ移行 {#migrate-data-from-mysql-to-tidb} @@ -38,23 +38,23 @@ Auroraから AWS にデプロイされた TiDB クラスターにデータを移 アプリケーションでデータストレージにMySQLシャードを使用しており、これらのシャードを1つのテーブルとしてTiDBに移行する必要がある場合、DMを使用してシャードのマージと移行を実行できます。 -- [小さなデータセットの MySQL シャードを TiDB に移行してマージする](/migrate-small-mysql-shards-to-tidb.md) +- [小さなデータセットの MySQL シャードを TiDB に移行してマージする](/migrate-small-mysql-shards-to-tidb.md) シャードテーブルのデータサイズが大きく（例えば1TiB以上）、移行期間中に他のアプリケーションによるTiDBへの書き込みを許可しない場合は、 TiDB Lightningを使用してシャードテーブルを迅速にマージ・インポートできます。その後、DMを使用して、アプリケーションのニーズに応じて増分シャーディングデータ（binlog）を複製できます。 -- [大規模データセットの MySQL シャードを TiDB に移行およびマージする](/migrate-large-mysql-shards-to-tidb.md) +- [大規模データセットの MySQL シャードを TiDB に移行およびマージする](/migrate-large-mysql-shards-to-tidb.md) ## Vitess から TiDB へのデータの移行 {#migrate-data-from-vitess-to-tidb} Vitess から TiDB にデータを移行するには、次のガイドが利用できます。 -- [Vitess から TiDB へのデータ移行](/migrate-from-vitess.md) +- [Vitess から TiDB へのデータ移行](/migrate-from-vitess.md) ## ファイルから TiDB にデータを移行する {#migrate-data-from-files-to-tidb} -- [CSVファイルからTiDBにデータを移行する](/migrate-from-csv-files-to-tidb.md) -- [SQL ファイルから TiDB にデータを移行する](/migrate-from-sql-files-to-tidb.md) -- [Parquet ファイルから TiDB にデータを移行する](/migrate-from-parquet-files-to-tidb.md) +- [CSVファイルからTiDBにデータを移行する](/migrate-from-csv-files-to-tidb.md) +- [SQL ファイルから TiDB にデータを移行する](/migrate-from-sql-files-to-tidb.md) +- [Parquet ファイルから TiDB にデータを移行する](/migrate-from-parquet-files-to-tidb.md) ## TiDB クラスタ間の増分レプリケーション {#incremental-replication-between-tidb-clusters} @@ -64,7 +64,7 @@ TiCDCは、TiDBクラスタ間の増分データレプリケーションに使 次の機能により移行プロセスが改善され、アプリケーションのより多くのニーズを満たすことができる可能性があります。 -- [gh-ost または pt-osc を使用するデータベースからの継続的なレプリケーション](/migrate-with-pt-ghost.md) -- [より多くの列を持つ下流の TiDB テーブルにデータを移行する](/migrate-with-more-columns-downstream.md) -- [Binlogイベントをフィルタリングする](/filter-binlog-event.md) -- [SQL 式を使用して DML イベントをフィルタリングする](/filter-dml-event.md) +- [gh-ost または pt-osc を使用するデータベースからの継続的なレプリケーション](/migrate-with-pt-ghost.md) +- [より多くの列を持つ下流の TiDB テーブルにデータを移行する](/migrate-with-more-columns-downstream.md) +- [Binlogイベントをフィルタリングする](/filter-binlog-event.md) +- [SQL 式を使用して DML イベントをフィルタリングする](/filter-dml-event.md) diff --git a/migration-tools.md b/migration-tools.md index eac4a22ba3e62..c79deff92ec49 100644 --- a/migration-tools.md +++ b/migration-tools.md @@ -15,75 +15,75 @@ TiDB は、完全なデータ移行、増分データ移行、バックアップ ## TiDB Data Migration (DM) {#tidb-data-migration-dm} -- **ユーザーシナリオ**: MySQL互換データベースからTiDBへのデータ移行 -- **アップストリーム**: MySQL、MariaDB、 Aurora -- **下流**：TiDB -- **利点**： - - 完全なデータ移行と増分レプリケーションをサポートする、便利で統合されたデータ移行タスク管理ツール - - フィルタリングテーブルと操作をサポート - - シャードのマージと移行をサポート -- **制限事項**：データのインポート速度はTiDB Lightning [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)とほぼ同等で、TiDB Lightning [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)よりも大幅に遅くなります。そのため、1TiB未満のデータ全体を移行する場合は、DMを使用することをお勧めします。 +- **ユーザーシナリオ**: MySQL互換データベースからTiDBへのデータ移行 +- **アップストリーム**: MySQL、MariaDB、 Aurora +- **下流**：TiDB +- **利点**： + - 完全なデータ移行と増分レプリケーションをサポートする、便利で統合されたデータ移行タスク管理ツール + - フィルタリングテーブルと操作をサポート + - シャードのマージと移行をサポート +- **制限事項**：データのインポート速度はTiDB Lightning [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)とほぼ同等で、TiDB Lightning [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)よりも大幅に遅くなります。そのため、1TiB未満のデータ全体を移行する場合は、DMを使用することをお勧めします。 ## TiDB Lightning {#tidb-lightning} -- **ユーザーシナリオ**: TiDBへの完全なデータのインポート -- **上流（インポートされたソースファイル）** : - - Dumplingからエクスポートされたファイル - - Amazon Aurora、Apache Hive、Snowflake によってエクスポートされた Parquet ファイル - - CSVファイル - - ローカルディスクまたは Amazon S3 からのデータ -- **下流**：TiDB -- **利点**： - - 大量のデータを迅速にインポートし、TiDB クラスタ内の特定のテーブルを迅速に初期化することをサポートします。 - - インポートの進行状況を保存するチェックポイントをサポートし、再起動後、`tidb-lightning`は中断したところからインポートを続行します - - データフィルタリングをサポート -- **制限事項**： - - データのインポートに[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md)を使用すると、インポート プロセス中に TiDB クラスターはサービスを提供できません。 - - TiDB サービスに影響を与えたくない場合は、 TiDB Lightning [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md)に従ってデータのインポートを実行してください。 +- **ユーザーシナリオ**: TiDBへの完全なデータのインポート +- **上流（インポートされたソースファイル）** : + - Dumplingからエクスポートされたファイル + - Amazon Aurora、Apache Hive、Snowflake によってエクスポートされた Parquet ファイル + - CSVファイル + - ローカルディスクまたは Amazon S3 からのデータ +- **下流**：TiDB +- **利点**： + - 大量のデータを迅速にインポートし、TiDB クラスタ内の特定のテーブルを迅速に初期化することをサポートします。 + - インポートの進行状況を保存するチェックポイントをサポートし、再起動後、`tidb-lightning`は中断したところからインポートを続行します + - データフィルタリングをサポート +- **制限事項**： + - データのインポートに[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md)を使用すると、インポート プロセス中に TiDB クラスターはサービスを提供できません。 + - TiDB サービスに影響を与えたくない場合は、 TiDB Lightning [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode-usage.md)に従ってデータのインポートを実行してください。 ## Dumpling {#dumpling} -- **ユーザーシナリオ**: MySQLまたはTiDBからの完全なデータエクスポート -- **アップストリーム**: MySQL、TiDB -- **下流（出力ファイル）** : SQL、CSV -- **利点**： - - データのフィルタリングを容易にするテーブルフィルタ機能をサポート - - Amazon S3へのデータのエクスポートをサポート -- **おすすめ**： - - エクスポートしたデータを TiDB 以外のデータベースに復元する場合は、 Dumplingを使用することをお勧めします。 - - エクスポートしたデータを別の TiDB クラスターに復元する場合は、Backup & Restore (BR) を使用することをお勧めします。 +- **ユーザーシナリオ**: MySQLまたはTiDBからの完全なデータエクスポート +- **アップストリーム**: MySQL、TiDB +- **下流（出力ファイル）** : SQL、CSV +- **利点**： + - データのフィルタリングを容易にするテーブルフィルタ機能をサポート + - Amazon S3へのデータのエクスポートをサポート +- **おすすめ**： + - エクスポートしたデータを TiDB 以外のデータベースに復元する場合は、 Dumplingを使用することをお勧めします。 + - エクスポートしたデータを別の TiDB クラスターに復元する場合は、Backup & Restore (BR) を使用することをお勧めします。 ## TiCDC {#ticdc} -- **ユーザーシナリオ**：このツールは、TiKVの変更ログをプルすることで実装されます。これにより、クラスターデータを上流のTSOと整合性のある状態に復元し、他のシステムがデータ変更をサブスクライブできるようになります。 -- **上流**：TiDB -- **ダウンストリーム**: TiDB、MySQL、Kafka、MQ、Confluent、Amazon S3、GCS、Azure Blob Storage、NFS などのストレージサービス。 -- **利点**：TiCDCオープンプロトコルを提供する -- **制限事項**：TiCDCは、少なくとも1つの有効なインデックスを持つテーブルのみを複製します。以下のシナリオはサポートされていません。 - - RawKV のみを使用する TiKV クラスター。 - - DDL 操作`CREATE SEQUENCE`と TiDB の`SEQUENCE`関数。 +- **ユーザーシナリオ**：このツールは、TiKVの変更ログをプルすることで実装されます。これにより、クラスターデータを上流のTSOと整合性のある状態に復元し、他のシステムがデータ変更をサブスクライブできるようになります。 +- **上流**：TiDB +- **ダウンストリーム**: TiDB、MySQL、Kafka、MQ、Confluent、Amazon S3、GCS、Azure Blob Storage、NFS などのストレージサービス。 +- **利点**：TiCDCオープンプロトコルを提供する +- **制限事項**：TiCDCは、少なくとも1つの有効なインデックスを持つテーブルのみを複製します。以下のシナリオはサポートされていません。 + - RawKV のみを使用する TiKV クラスター。 + - DDL 操作`CREATE SEQUENCE`と TiDB の`SEQUENCE`関数。 ## Backup & Restore (BR) {#backup--restore-br} -- **ユーザーシナリオ**: データのバックアップとリストアによって大量の TiDB クラスターデータを移行する -- **上流**：TiDB -- **下流（出力ファイル）** : SST、backup.meta ファイル、backup.lock ファイル -- **利点**： - - 別のTiDBクラスタへのデータ移行に適しています - - 災害復旧のための外部ストレージへのデータバックアップをサポート -- **制限事項**： - - BR がTiCDC の上流クラスターにデータを復元する場合、復元されたデータは TiCDC によって下流に複製できません。 - - BR は、 `mysql.tidb`テーブルで同じ`new_collation_enabled`値を持つクラスター間の操作のみをサポートします。 +- **ユーザーシナリオ**: データのバックアップとリストアによって大量の TiDB クラスターデータを移行する +- **上流**：TiDB +- **下流（出力ファイル）** : SST、backup.meta ファイル、backup.lock ファイル +- **利点**： + - 別のTiDBクラスタへのデータ移行に適しています + - 災害復旧のための外部ストレージへのデータバックアップをサポート +- **制限事項**： + - BR がTiCDC の上流クラスターにデータを復元する場合、復元されたデータは TiCDC によって下流に複製できません。 + - BR は、 `mysql.tidb`テーブルで同じ`new_collation_enabled`値を持つクラスター間の操作のみをサポートします。 ## sync-diff-inspector {#sync-diff-inspector} -- **ユーザーシナリオ**: MySQLプロトコルを使用してデータベースに保存されたデータを比較する -- **アップストリーム**: TiDB、MySQL -- **下流**: TiDB、MySQL -- **利点**: 少量のデータが不整合なシナリオでデータを修復するために使用できます -- **制限事項**： - - MySQL と TiDB 間のデータ移行ではオンライン チェックはサポートされていません。 - - JSON、BIT、BINARY、BLOB などのタイプのデータはサポートされていません。 +- **ユーザーシナリオ**: MySQLプロトコルを使用してデータベースに保存されたデータを比較する +- **アップストリーム**: TiDB、MySQL +- **下流**: TiDB、MySQL +- **利点**: 少量のデータが不整合なシナリオでデータを修復するために使用できます +- **制限事項**： + - MySQL と TiDB 間のデータ移行ではオンライン チェックはサポートされていません。 + - JSON、BIT、BINARY、BLOB などのタイプのデータはサポートされていません。 ## TiUPを使用してツールをインストールする {#install-tools-using-tiup} @@ -162,5 +162,5 @@ tiup update --self && tiup update dm ## 参照 {#see-also} -- [TiUPをオフラインでデプロイ](/production-deployment-using-tiup.md#deploy-tiup-offline) -- [バイナリでツールをダウンロードしてインストールする](/download-ecosystem-tools.md) +- [TiUPをオフラインでデプロイ](/production-deployment-using-tiup.md#deploy-tiup-offline) +- [バイナリでツールをダウンロードしてインストールする](/download-ecosystem-tools.md) diff --git a/minimal-deployment-topology.md b/minimal-deployment-topology.md index 84a36c6a8ba6f..2f5ee0866bed5 100644 --- a/minimal-deployment-topology.md +++ b/minimal-deployment-topology.md @@ -22,12 +22,12 @@ summary: TiDB クラスターの最小限のデプロイメント トポロジ ### トポロジテンプレート {#topology-templates} -- [最小トポロジーのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-mini.yaml) -- [最小トポロジーの複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-mini.yaml) +- [最小トポロジーのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-mini.yaml) +- [最小トポロジーの複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-mini.yaml) 上記の TiDB クラスター トポロジ ファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 > **Note:** > -> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUP クラスターコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 -> - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 +> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUP クラスターコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 +> - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/multi-data-centers-in-one-city-deployment.md b/multi-data-centers-in-one-city-deployment.md index 4e7d4e0513691..e6e850f5d9729 100644 --- a/multi-data-centers-in-one-city-deployment.md +++ b/multi-data-centers-in-one-city-deployment.md @@ -21,15 +21,15 @@ summary: 1 つのリージョン内の複数の可用性ゾーンへのデプロ Raftは分散コンセンサスアルゴリズムです。このアルゴリズムを使用することで、TiDBクラスタのコンポーネント間でPDとTiKVの両方がデータの災害復旧を実現します。これは以下のメカニズムを通じて実現されます。 -- Raftメンバーの本質的な役割は、ログの複製を実行し、状態マシンとして機能することです。Raftメンバー間では、ログを複製することでデータの複製が実現されます。Raftは、さまざまな状況に応じて自身の状態を変化させ、サービスを提供するリーダーを選出します。 -- Raftは多数決プロトコルに従う投票システムです。Raftグループでは、メンバーが過半数の票を獲得すると、そのメンバーはリーダーに昇格します。つまり、 Raftグループに過半数のノードが残っている場合、サービスを提供するリーダーが選出されます。 +- Raftメンバーの本質的な役割は、ログの複製を実行し、状態マシンとして機能することです。Raftメンバー間では、ログを複製することでデータの複製が実現されます。Raftは、さまざまな状況に応じて自身の状態を変化させ、サービスを提供するリーダーを選出します。 +- Raftは多数決プロトコルに従う投票システムです。Raftグループでは、メンバーが過半数の票を獲得すると、そのメンバーはリーダーに昇格します。つまり、 Raftグループに過半数のノードが残っている場合、サービスを提供するリーダーが選出されます。 Raft の信頼性を活用するには、実際の展開シナリオで次の条件を満たす必要があります。 -- 1 台のサーバーに障害が発生した場合に備えて、少なくとも 3 台のサーバーを使用します。 -- 1 つのラックが故障した場合に備えて、少なくとも 3 つのラックを使用してください。 -- 1 つの AZ に障害が発生した場合に備えて、少なくとも 3 つの AZ を使用します。 -- 1 つのリージョンでデータの安全性の問題が発生した場合に備えて、少なくとも 3 つのリージョンに TiDBをデプロイ。 +- 1 台のサーバーに障害が発生した場合に備えて、少なくとも 3 台のサーバーを使用します。 +- 1 つのラックが故障した場合に備えて、少なくとも 3 つのラックを使用してください。 +- 1 つの AZ に障害が発生した場合に備えて、少なくとも 3 つの AZ を使用します。 +- 1 つのリージョンでデータの安全性の問題が発生した場合に備えて、少なくとも 3 つのリージョンに TiDBをデプロイ。 ネイティブRaftプロトコルは、偶数個のレプリカを適切にサポートしていません。リージョン間のネットワークレイテンシーの影響を考慮すると、高可用性と耐障害性を備えたRaftデプロイメントには、同一リージョン内に3つのAZを配置することが最適なソリューションとなる可能性があります。 @@ -45,9 +45,9 @@ TiDB、TiKV、PD は 3 つの AZ に分散されており、これが最も一 **利点:** -- すべてのレプリカは 3 つの AZ に分散されており、高い可用性と災害復旧機能を備えています。 -- 1 つの AZ がダウンしてもデータは失われません (RPO = 0)。 -- 1つのAZがダウンした場合でも、他の2つのAZが自動的にリーダー選出を開始し、一定時間内（通常は20秒以内）にサービスを自動的に再開します。詳細については、次の図をご覧ください。 +- すべてのレプリカは 3 つの AZ に分散されており、高い可用性と災害復旧機能を備えています。 +- 1 つの AZ がダウンしてもデータは失われません (RPO = 0)。 +- 1つのAZがダウンした場合でも、他の2つのAZが自動的にリーダー選出を開始し、一定時間内（通常は20秒以内）にサービスを自動的に再開します。詳細については、次の図をご覧ください。 ![Disaster Recovery for 3-AZ Deployment](/media/deploy-3dc-dr.png) @@ -55,9 +55,9 @@ TiDB、TiKV、PD は 3 つの AZ に分散されており、これが最も一 パフォーマンスはネットワークレイテンシーによって影響を受ける可能性があります。 -- 書き込みの場合、すべてのデータは少なくとも2つのAZに複製される必要があります。TiDBは書き込みに2フェーズコミットを使用するため、書き込みレイテンシーは2つのAZ間のネットワークレイテンシーの2倍以上になります。 -- リーダーが読み取り要求を送信する TiDB ノードと同じ AZ にない場合、読み取りパフォーマンスはネットワークレイテンシーの影響も受けます。 -- 各TiDBトランザクションは、PDリーダーからタイムスタンプオラクル（TSO）を取得する必要があります。そのため、TiDBとPDリーダーが同じAZにない場合、書き込みリクエストを含む各トランザクションはTSOを2回取得する必要があるため、トランザクションのパフォーマンスはネットワークレイテンシーの影響を受けます。 +- 書き込みの場合、すべてのデータは少なくとも2つのAZに複製される必要があります。TiDBは書き込みに2フェーズコミットを使用するため、書き込みレイテンシーは2つのAZ間のネットワークレイテンシーの2倍以上になります。 +- リーダーが読み取り要求を送信する TiDB ノードと同じ AZ にない場合、読み取りパフォーマンスはネットワークレイテンシーの影響も受けます。 +- 各TiDBトランザクションは、PDリーダーからタイムスタンプオラクル（TSO）を取得する必要があります。そのため、TiDBとPDリーダーが同じAZにない場合、書き込みリクエストを含む各トランザクションはTSOを2回取得する必要があるため、トランザクションのパフォーマンスはネットワークレイテンシーの影響を受けます。 ### 最適化されたアーキテクチャ {#optimized-architecture} @@ -86,10 +86,10 @@ member leader_priority pdName3 3 **デメリット:** -- 書き込みシナリオは、依然としてAZ間のネットワークレイテンシーの影響を受けます。これは、 Raftが多数決プロトコルに準拠し、書き込まれたすべてのデータが少なくとも2つのAZに複製される必要があるためです。 -- サービスを提供する TiDBサーバーは1 つの AZ にのみ存在します。 -- すべてのアプリケーション トラフィックは 1 つの AZ によって処理され、パフォーマンスはその AZ のネットワーク帯域幅の圧力によって制限されます。 -- TSO の取得能力と読み取りパフォーマンスは、アプリケーショントラフィックを処理する AZ 内の PDサーバーと TiKVサーバーが稼働しているかどうかによって影響を受けます。これらのサーバーがダウンしている場合でも、アプリケーションはセンター間ネットワークレイテンシーの影響を受けます。 +- 書き込みシナリオは、依然としてAZ間のネットワークレイテンシーの影響を受けます。これは、 Raftが多数決プロトコルに準拠し、書き込まれたすべてのデータが少なくとも2つのAZに複製される必要があるためです。 +- サービスを提供する TiDBサーバーは1 つの AZ にのみ存在します。 +- すべてのアプリケーション トラフィックは 1 つの AZ によって処理され、パフォーマンスはその AZ のネットワーク帯域幅の圧力によって制限されます。 +- TSO の取得能力と読み取りパフォーマンスは、アプリケーショントラフィックを処理する AZ 内の PDサーバーと TiKVサーバーが稼働しているかどうかによって影響を受けます。これらのサーバーがダウンしている場合でも、アプリケーションはセンター間ネットワークレイテンシーの影響を受けます。 ### 展開例 {#deployment-example} diff --git a/mysql-compatibility.md b/mysql-compatibility.md index f0d53a838b2a9..56312177a814f 100644 --- a/mysql-compatibility.md +++ b/mysql-compatibility.md @@ -23,8 +23,8 @@ TiDBはMySQLプロトコルと高い互換性を持ち、 MySQL 5.7およびMySQ TiDBはMySQLレプリケーションプロトコルをサポートしていない点に注意が必要です。代わりに、MySQLでデータをレプリケートするための専用ツールが提供されています。 -- MySQL からデータを複製する: [TiDB Data Migration (DM)](/dm/dm-overview.md)は、MySQL または MariaDB から TiDB への完全なデータ移行と増分データレプリケーションをサポートするツールです。 -- データをMySQLに複製する: [TiCDC](/ticdc/ticdc-overview.md)は、TiKV変更ログを取得してTiDBの増分データを複製するためのツールです。TiCDCは[MySQLシンク](/ticdc/ticdc-overview.md#replication-consistency)を使用して、TiDBの増分データをMySQLに複製します。 +- MySQL からデータを複製する: [TiDB Data Migration (DM)](/dm/dm-overview.md)は、MySQL または MariaDB から TiDB への完全なデータ移行と増分データレプリケーションをサポートするツールです。 +- データをMySQLに複製する: [TiCDC](/ticdc/ticdc-overview.md)は、TiKV変更ログを取得してTiDBの増分データを複製するためのツールです。TiCDCは[MySQLシンク](/ticdc/ticdc-overview.md#replication-consistency)を使用して、TiDBの増分データをMySQLに複製します。 @@ -40,73 +40,73 @@ TiDBはMySQLレプリケーションプロトコルをサポートしていな ## サポートされていない機能 {#unsupported-features} -- ストアドプロシージャと関数 +- ストアドプロシージャと関数 -- トリガー +- トリガー -- イベント +- イベント -- ユーザー定義関数 +- ユーザー定義関数 -- `FULLTEXT`構文とインデックス [#1793](https://github.com/pingcap/tidb/issues/1793) +- `FULLTEXT`構文とインデックス [#1793](https://github.com/pingcap/tidb/issues/1793) > **Note:** > > 現在、特定の AWS リージョンのTiDB Cloud Starterインスタンスのみが[`FULLTEXT`構文とインデックス](https://docs.pingcap.com/tidbcloud/vector-search-full-text-search-sql)をサポートしています。TiDB Self-Managed およびTiDB Cloud Dedicatedは`FULLTEXT`構文の解析をサポートしていますが、 `FULLTEXT`インデックスの使用はサポートしていません。 -- `SPATIAL` （別名`GIS` / `GEOMETRY` ）関数、データ型、およびインデックス [#6347](https://github.com/pingcap/tidb/issues/6347) +- `SPATIAL` （別名`GIS` / `GEOMETRY` ）関数、データ型、およびインデックス [#6347](https://github.com/pingcap/tidb/issues/6347) -- `ascii` 、 `latin1` 、 `binary` 、 `utf8` 、 `utf8mb4` 、および`gbk`などの文字セット。 +- `ascii` 、 `latin1` 、 `binary` 、 `utf8` 、 `utf8mb4` 、および`gbk`などの文字セット。 -- オプティマイザトレース +- オプティマイザトレース -- XML関数 +- XML関数 -- Xプロトコル [#1109](https://github.com/pingcap/tidb/issues/1109) +- Xプロトコル [#1109](https://github.com/pingcap/tidb/issues/1109) -- `XA`構文（TiDBは内部的に2フェーズコミットを使用しますが、これはSQLインターフェース経由では公開されません） +- `XA`構文（TiDBは内部的に2フェーズコミットを使用しますが、これはSQLインターフェース経由では公開されません） -- `CREATE TABLE tblName AS SELECT stmt`構文 [#4754](https://github.com/pingcap/tidb/issues/4754) +- `CREATE TABLE tblName AS SELECT stmt`構文 [#4754](https://github.com/pingcap/tidb/issues/4754) -- `CHECK TABLE`構文 [#4673](https://github.com/pingcap/tidb/issues/4673) +- `CHECK TABLE`構文 [#4673](https://github.com/pingcap/tidb/issues/4673) -- `CHECKSUM TABLE`構文 [#1895](https://github.com/pingcap/tidb/issues/1895) +- `CHECKSUM TABLE`構文 [#1895](https://github.com/pingcap/tidb/issues/1895) -- `REPAIR TABLE`構文 +- `REPAIR TABLE`構文 -- `OPTIMIZE TABLE`構文 +- `OPTIMIZE TABLE`構文 -- `HANDLER`ステートメント +- `HANDLER`ステートメント -- `CREATE TABLESPACE`ステートメント +- `CREATE TABLESPACE`ステートメント -- 「セッショントラッカー：OKパケットにGTIDコンテキストを追加する」 +- 「セッショントラッカー：OKパケットにGTIDコンテキストを追加する」 -- 降順インデックス [#2519](https://github.com/pingcap/tidb/issues/2519) +- 降順インデックス [#2519](https://github.com/pingcap/tidb/issues/2519) -- `SKIP LOCKED`構文 [#18207](https://github.com/pingcap/tidb/issues/18207) +- `SKIP LOCKED`構文 [#18207](https://github.com/pingcap/tidb/issues/18207) -- LATERAL 派生テーブル（TiDB は [`LATERAL` 派生テーブル構文](/lateral-derived-tables.md) の構文解析をサポートしていますが、この構文を使用するクエリの実行はサポートしていません） [#40328](https://github.com/pingcap/tidb/issues/40328) +- LATERAL 派生テーブル（TiDB は [`LATERAL` 派生テーブル構文](/lateral-derived-tables.md) の構文解析をサポートしていますが、この構文を使用するクエリの実行はサポートしていません） [#40328](https://github.com/pingcap/tidb/issues/40328) -- サブクエリ [#11414](https://github.com/pingcap/tidb/issues/11414)で結合します +- サブクエリ [#11414](https://github.com/pingcap/tidb/issues/11414)で結合します ## MySQLとの違い {#differences-from-mysql} ### AUTO_INCREMENT ID {#auto-increment-id} -- TiDBでは、AUTO_INCREMENTされる列値（ID）は、単一のTiDBサーバー内でグローバルに一意であり、インクリメントされます。複数のTiDBサーバー間でIDをインクリメントするには、[`AUTO_INCREMENT` MySQL互換モード](/auto-increment.md#mysql-compatibility-mode)を使用できます。ただし、IDは必ずしも順番に割り当てられるとは限らないため、 `Duplicated Error`メッセージが表示されないように、デフォルト値とカスタム値を混在させないことをお勧めします。 +- TiDBでは、AUTO_INCREMENTされる列値（ID）は、単一のTiDBサーバー内でグローバルに一意であり、インクリメントされます。複数のTiDBサーバー間でIDをインクリメントするには、[`AUTO_INCREMENT` MySQL互換モード](/auto-increment.md#mysql-compatibility-mode)を使用できます。ただし、IDは必ずしも順番に割り当てられるとは限らないため、 `Duplicated Error`メッセージが表示されないように、デフォルト値とカスタム値を混在させないことをお勧めします。 -- `tidb_allow_remove_auto_inc`システム変数を使用すると、 `AUTO_INCREMENT`列属性の削除を許可または禁止できます。列属性を削除するには、 `ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`構文を使用します。 +- `tidb_allow_remove_auto_inc`システム変数を使用すると、 `AUTO_INCREMENT`列属性の削除を許可または禁止できます。列属性を削除するには、 `ALTER TABLE MODIFY`または`ALTER TABLE CHANGE`構文を使用します。 -- TiDBは`AUTO_INCREMENT`列属性の追加をサポートしておらず、一度削除すると復元できません。 +- TiDBは`AUTO_INCREMENT`列属性の追加をサポートしておらず、一度削除すると復元できません。 -- TiDB v6.6.0以前のバージョンでは、TiDBのAUTO_INCREMENT列はMySQL InnoDBと同様に動作し、主キーまたはインデックスプレフィックスである必要があります。v7.0.0以降、TiDBはこの制限を撤廃し、より柔軟なテーブル主キー定義を可能にしました。 [#40580](https://github.com/pingcap/tidb/issues/40580) +- 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)を参照してください。 > **Note:** > -> - テーブル作成時に主キーを指定しない場合、TiDB は`_tidb_rowid`を使用して行を識別します。この値の割り当ては、AUTO_INCREMENT列 (そのような列が存在する場合) とアロケータを共有します。AUTO_INCREMENT列を主キーとして指定した場合、TiDB はこの列を使用して行を識別します。この場合、次のような状況が発生する可能性があります。 +> - テーブル作成時に主キーを指定しない場合、TiDB は`_tidb_rowid`を使用して行を識別します。この値の割り当ては、AUTO_INCREMENT列 (そのような列が存在する場合) とアロケータを共有します。AUTO_INCREMENT列を主キーとして指定した場合、TiDB はこの列を使用して行を識別します。この場合、次のような状況が発生する可能性があります。 ```sql mysql> CREATE TABLE t(id INT UNIQUE KEY AUTO_INCREMENT); @@ -180,19 +180,19 @@ TiDBはMySQLの組み込み関数のほとんどをサポートしています TiDBでは、サポートされているすべてのDDL変更をオンラインで実行できます。ただし、TiDBのDDL操作には、MySQLと比較していくつかの大きな制限があります。 -- 単一の`ALTER TABLE`ステートメントを使用してテーブルの複数のスキーマ オブジェクト (列やインデックスなど) を変更する場合、同じオブジェクトを複数の変更で指定することはサポートされていません。たとえば、 `ALTER TABLE t1 MODIFY COLUMN c1 INT, DROP COLUMN c1`コマンドを実行すると、 `Unsupported operate same column/index`エラーが出力されます。 -- 同じ`ALTER TABLE`ステートメント内で、`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)を参照してください。 -- `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`はサポートされていない特定のパーティションタイプです。 -- Range、Range COLUMNS、List、およびList COLUMNSパーティションテーブルは、 `ADD` 、 `DROP` 、 `TRUNCATE` 、および`REORGANIZE`操作をサポートします。その他のパーティション操作は無視されます。 -- ハッシュおよびキーパーティションテーブルは`ADD` 、 `COALESCE` 、および`TRUNCATE`操作をサポートします。その他のパーティション操作は無視されます。 -- パーティションテーブルでは、以下の構文はサポートされていません。 +- 単一の`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)を参照してください。 +- `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`はサポートされていない特定のパーティションタイプです。 +- Range、Range COLUMNS、List、およびList COLUMNSパーティションテーブルは、 `ADD` 、 `DROP` 、 `TRUNCATE` 、および`REORGANIZE`操作をサポートします。その他のパーティション操作は無視されます。 +- ハッシュおよびキーパーティションテーブルは`ADD` 、 `COALESCE` 、および`TRUNCATE`操作をサポートします。その他のパーティション操作は無視されます。 +- パーティションテーブルでは、以下の構文はサポートされていません。 - - `SUBPARTITION` - - `{CHECK|OPTIMIZE|REPAIR|IMPORT|DISCARD|REBUILD} PARTITION` + - `SUBPARTITION` + - `{CHECK|OPTIMIZE|REPAIR|IMPORT|DISCARD|REBUILD} PARTITION` パーティショニングの詳細については、[パーティショニング](/partitioned-table.md)を参照してください。 @@ -206,8 +206,8 @@ TiDBでは、[統計の収集](/statistics.md#manual-collection)はMySQLとは TiDB は、次の`SELECT`構文をサポートしていません。 -- `SELECT ... INTO @variable` -- `SELECT .. GROUP BY expr` MySQL 5.7のように`GROUP BY expr ORDER BY expr`を意味しません。 +- `SELECT ... INTO @variable` +- `SELECT .. GROUP BY expr` MySQL 5.7のように`GROUP BY expr ORDER BY expr`を意味しません。 詳細については、 [`SELECT`](/sql-statements/sql-statement-select.md)文のリファレンスを参照してください。 @@ -225,11 +225,11 @@ TiDB のビューは更新できず、 `UPDATE` 、 `INSERT` 、 `DELETE`など ### 文字セットと照合順序 {#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)を参照してください。 +- GBK文字セットのMySQL互換性に関する情報については、 [GBK互換性](/character-set-gbk.md#mysql-compatibility)を参照してください。 -- TiDBは、テーブルで使用されている文字セットを各国語の文字セットとして継承します。 +- TiDBは、テーブルで使用されている文字セットを各国語の文字セットとして継承します。 ### ストレージエンジン {#storage-engines} @@ -245,51 +245,51 @@ TiDBでは、代替ストレージエンジンを使用してテーブルを作 TiDB はほとんどの[SQLモード](/sql-mode.md)をサポートしています。 -- `Oracle`や`PostgreSQL`などの互換モードは解析されますが、無視されます。互換モードはMySQL 5.7で非推奨となり、MySQL 8.0 で削除されました。 -- `ONLY_FULL_GROUP_BY`モードには、 MySQL 5.7との小さな[意味の違い](/functions-and-operators/aggregate-group-by-functions.md#differences-from-mysql)あります。 -- MySQL の`NO_DIR_IN_CREATE`および`NO_ENGINE_SUBSTITUTION` SQL モードは互換性のために受け入れられていますが、TiDB には適用できません。 +- `Oracle`や`PostgreSQL`などの互換モードは解析されますが、無視されます。互換モードはMySQL 5.7で非推奨となり、MySQL 8.0 で削除されました。 +- `ONLY_FULL_GROUP_BY`モードには、 MySQL 5.7との小さな[意味の違い](/functions-and-operators/aggregate-group-by-functions.md#differences-from-mysql)あります。 +- MySQL の`NO_DIR_IN_CREATE`および`NO_ENGINE_SUBSTITUTION` SQL モードは互換性のために受け入れられていますが、TiDB には適用できません。 ### デフォルトの差異 {#default-differences} TiDBは、MySQL 5.7およびMySQL 8.0と比較して、デフォルト設定にいくつかの違いがあります。 -- デフォルトの文字セット: - - TiDB のデフォルト値は`utf8mb4`です。 - - MySQL 5.7のデフォルト値は`latin1`です。 - - MySQL 8.0 のデフォルト値は`utf8mb4`です。 -- デフォルトの照合順序: - - TiDB のデフォルトの照合順序は`utf8mb4_bin`です。 - - MySQL 5.7のデフォルトの照合順序は`utf8mb4_general_ci`です。 - - MySQL 8.0 のデフォルトの照合順序は`utf8mb4_0900_ai_ci`です。 -- デフォルトのSQLモード: - - TiDB のデフォルトの SQL モードには、次のモードが含まれます: `ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION` 。 - - MySQLのデフォルトのSQLモード： - - MySQL 5.7のデフォルトのSQLモードは、TiDBと同じです。 - - MySQL 8.0 のデフォルトの SQL モードには、次のモードが含まれます: `ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION` 。 -- `lower_case_table_names`のデフォルト値: - - TiDB のデフォルト値は`2`であり、現在サポートされているのは`2`のみです。 - - MySQLのデフォルト値は以下のとおりです。 - - Linux の場合: `0` 。これは、テーブル名とデータベース名が`CREATE TABLE`または`CREATE DATABASE` 。名前の比較では大文字小文字が区別されます。 - - Windows の場合: `1` 。これは、テーブル名がディスク上に小文字で保存され、名前の比較では大文字と小文字が区別されないことを意味します。MySQL は、保存時および検索時にすべてのテーブル名を小文字に変換します。この動作は、データベース名とテーブルエイリアスにも適用されます。 - - macOS の場合: `2` 。これは、テーブル名とデータベース名が`CREATE TABLE`または`CREATE DATABASE`ステートメントで指定された文字の大文字小文字に従ってディスクに保存されますが、MySQL は検索時にそれらを小文字に変換します。名前の比較では大文字小文字は区別されません。 -- `explicit_defaults_for_timestamp`のデフォルト値: - - TiDB のデフォルト値は`ON`であり、現在サポートされているのは`ON`のみです。 - - MySQLのデフォルト値は以下のとおりです。 - - MySQL 5.7の場合: `OFF` 。 - - MySQL 8.0 の場合: `ON` 。 +- デフォルトの文字セット: + - TiDB のデフォルト値は`utf8mb4`です。 + - MySQL 5.7のデフォルト値は`latin1`です。 + - MySQL 8.0 のデフォルト値は`utf8mb4`です。 +- デフォルトの照合順序: + - TiDB のデフォルトの照合順序は`utf8mb4_bin`です。 + - MySQL 5.7のデフォルトの照合順序は`utf8mb4_general_ci`です。 + - MySQL 8.0 のデフォルトの照合順序は`utf8mb4_0900_ai_ci`です。 +- デフォルトのSQLモード: + - TiDB のデフォルトの SQL モードには、次のモードが含まれます: `ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION` 。 + - MySQLのデフォルトのSQLモード： + - MySQL 5.7のデフォルトのSQLモードは、TiDBと同じです。 + - MySQL 8.0 のデフォルトの SQL モードには、次のモードが含まれます: `ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION` 。 +- `lower_case_table_names`のデフォルト値: + - TiDB のデフォルト値は`2`であり、現在サポートされているのは`2`のみです。 + - MySQLのデフォルト値は以下のとおりです。 + - Linux の場合: `0` 。これは、テーブル名とデータベース名が`CREATE TABLE`または`CREATE DATABASE` 。名前の比較では大文字小文字が区別されます。 + - Windows の場合: `1` 。これは、テーブル名がディスク上に小文字で保存され、名前の比較では大文字と小文字が区別されないことを意味します。MySQL は、保存時および検索時にすべてのテーブル名を小文字に変換します。この動作は、データベース名とテーブルエイリアスにも適用されます。 + - macOS の場合: `2` 。これは、テーブル名とデータベース名が`CREATE TABLE`または`CREATE DATABASE`ステートメントで指定された文字の大文字小文字に従ってディスクに保存されますが、MySQL は検索時にそれらを小文字に変換します。名前の比較では大文字小文字は区別されません。 +- `explicit_defaults_for_timestamp`のデフォルト値: + - TiDB のデフォルト値は`ON`であり、現在サポートされているのは`ON`のみです。 + - MySQLのデフォルト値は以下のとおりです。 + - MySQL 5.7の場合: `OFF` 。 + - MySQL 8.0 の場合: `ON` 。 ### 日時 {#date-and-time} TiDBは、以下の点を考慮して、名前付きタイムゾーンをサポートしています。 -- TiDBは、計算にシステムに現在インストールされているすべてのタイムゾーンルール（通常は`tzdata`パッケージ）を使用します。これにより、タイムゾーンテーブルデータをインポートすることなく、すべてのタイムゾーン名を使用できます。タイムゾーンテーブルデータをインポートしても、計算ルールは変更されません。 -- 現在、MySQL はデフォルトでローカル タイムゾーンを使用し、システムに組み込まれている現在のタイムゾーン ルール (夏時間の開始時など) に基づいて計算します。 [タイムゾーンテーブルデータのインポート](https://dev.mysql.com/doc/refman/8.0/en/time-zone-support.html#time-zone-installation)インポートがないと、MySQL は名前でタイムゾーンを指定できません。 +- TiDBは、計算にシステムに現在インストールされているすべてのタイムゾーンルール（通常は`tzdata`パッケージ）を使用します。これにより、タイムゾーンテーブルデータをインポートすることなく、すべてのタイムゾーン名を使用できます。タイムゾーンテーブルデータをインポートしても、計算ルールは変更されません。 +- 現在、MySQL はデフォルトでローカル タイムゾーンを使用し、システムに組み込まれている現在のタイムゾーン ルール (夏時間の開始時など) に基づいて計算します。 [タイムゾーンテーブルデータのインポート](https://dev.mysql.com/doc/refman/8.0/en/time-zone-support.html#time-zone-installation)インポートがないと、MySQL は名前でタイムゾーンを指定できません。 ### タイプシステムの違い {#type-system-differences} 以下の列タイプはMySQLではサポートされていますが、TiDBでは**サポートされていません**。 -- `SQL_TSI_*` （SQL_TSI_MONTH、SQL_TSI_WEEK、SQL_TSI_DAY、SQL_TSI_HOUR、SQL_TSI_MINUTE、SQL_TSI_SECONDを含みますが、SQL_TSI_YEARは含みません） +- `SQL_TSI_*` （SQL_TSI_MONTH、SQL_TSI_WEEK、SQL_TSI_DAY、SQL_TSI_HOUR、SQL_TSI_MINUTE、SQL_TSI_SECONDを含みますが、SQL_TSI_YEARは含みません） ### 正規表現 {#regular-expressions} @@ -299,16 +299,16 @@ TiDBは、以下の点を考慮して、名前付きタイムゾーンをサポ TiDBは、MySQLで非推奨となった特定の機能を実装していません。例えば、以下の機能などです。 -- 浮動小数点型の精度を指定する。MySQL 8.0 ではこの機能[非推奨](https://dev.mysql.com/doc/refman/8.0/en/floating-point-types.html)、代わりに`DECIMAL`型を使用することをお勧めします。 -- `ZEROFILL`属性。MySQL 8.0ではこの機能[非推奨](https://dev.mysql.com/doc/refman/8.0/en/numeric-type-attributes.html)、代わりにアプリケーションで数値をパディングすることをお勧めします。 +- 浮動小数点型の精度を指定する。MySQL 8.0 ではこの機能[非推奨](https://dev.mysql.com/doc/refman/8.0/en/floating-point-types.html)、代わりに`DECIMAL`型を使用することをお勧めします。 +- `ZEROFILL`属性。MySQL 8.0ではこの機能[非推奨](https://dev.mysql.com/doc/refman/8.0/en/numeric-type-attributes.html)、代わりにアプリケーションで数値をパディングすることをお勧めします。 ### `CREATE RESOURCE GROUP` 、 `DROP RESOURCE GROUP` 、および`ALTER RESOURCE GROUP`ステートメント {#create-resource-group-drop-resource-group-and-alter-resource-group-statements} リソースグループの作成、変更、削除に関する以下のステートメントは、MySQLとは異なるパラメータをサポートしています。詳細については、以下のドキュメントを参照してください。 -- [`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md) -- [`DROP RESOURCE GROUP`](/sql-statements/sql-statement-drop-resource-group.md) -- [`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md) +- [`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md) +- [`DROP RESOURCE GROUP`](/sql-statements/sql-statement-drop-resource-group.md) +- [`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md) ## MySQL InnoDBとの悲観的トランザクション（ロック）に関する相違点 {#differences-on-pessimistic-transaction-lock-with-mysql-innodb} diff --git a/mysql-schema/mysql-schema-tidb-mdl-view.md b/mysql-schema/mysql-schema-tidb-mdl-view.md index 49eae6f15aab0..8962a81ed44e1 100644 --- a/mysql-schema/mysql-schema-tidb-mdl-view.md +++ b/mysql-schema/mysql-schema-tidb-mdl-view.md @@ -30,10 +30,10 @@ DESC mysql.tidb_mdl_view; ## フィールド {#fields} -- `job_id` : ジョブの識別子。 -- `db_name` : データベース名。 -- `table_name` : テーブル名。 -- `query` : クエリ。 -- `session_id` : セッションの識別子。 -- `start_time` : 開始時刻。この列は以前のバージョンでは`TxnStart`呼ばれていました。 -- `SQL_DIGESTS` : SQL ステートメントのダイジェスト。 +- `job_id` : ジョブの識別子。 +- `db_name` : データベース名。 +- `table_name` : テーブル名。 +- `query` : クエリ。 +- `session_id` : セッションの識別子。 +- `start_time` : 開始時刻。この列は以前のバージョンでは`TxnStart`呼ばれていました。 +- `SQL_DIGESTS` : SQL ステートメントのダイジェスト。 diff --git a/mysql-schema/mysql-schema-user.md b/mysql-schema/mysql-schema-user.md index 065e3d7ebf342..5486d9849a535 100644 --- a/mysql-schema/mysql-schema-user.md +++ b/mysql-schema/mysql-schema-user.md @@ -72,41 +72,41 @@ DESC mysql.user; -- 範囲： - - `Host` : TiDB アカウントのホスト名を指定します。 - - `User` : TiDB アカウントのユーザー名を指定します。 +- 範囲： + - `Host` : TiDB アカウントのホスト名を指定します。 + - `User` : TiDB アカウントのユーザー名を指定します。 -- 特権： +- 特権： `_priv`または`_Priv`で終わるフィールドは、ユーザーアカウントに付与される権限を定義します。例えば、 `Select_priv`ユーザーがグローバル権限`Select`を持つことを意味します。詳細については、 [TiDB操作に必要な権限](/privilege-management.md#privileges-required-for-tidb-operations)を参照してください。 -- セキュリティ： - - `authentication_string`と`plugin` ： `authentication_string`にはユーザーアカウントの認証情報が保存されます。認証情報は、 `plugin`フィールドで指定された認証プラグインに基づいて解釈されます。 - - `Account_locked` : ユーザー アカウントがロックされているかどうかを示します。 - - `Password_reuse_history`と`Password_reuse_time` : [パスワード再利用ポリシー](/password-management.md#password-reuse-policy)に使用されます。 - - `User_attributes` : ユーザーのコメントとユーザー属性に関する情報を提供します。 - - `Token_issuer` : [`tidb_auth_token`](/security-compatibility-with-mysql.md#tidb_auth_token)認証プラグインに使用されます。 - - `Password_expired` 、 `Password_last_changed` 、 `Password_lifetime` : [パスワード有効期限ポリシー](/password-management.md#password-expiration-policy)に使用されます。 +- セキュリティ： + - `authentication_string`と`plugin` ： `authentication_string`にはユーザーアカウントの認証情報が保存されます。認証情報は、 `plugin`フィールドで指定された認証プラグインに基づいて解釈されます。 + - `Account_locked` : ユーザー アカウントがロックされているかどうかを示します。 + - `Password_reuse_history`と`Password_reuse_time` : [パスワード再利用ポリシー](/password-management.md#password-reuse-policy)に使用されます。 + - `User_attributes` : ユーザーのコメントとユーザー属性に関する情報を提供します。 + - `Token_issuer` : [`tidb_auth_token`](/security-compatibility-with-mysql.md#tidb_auth_token)認証プラグインに使用されます。 + - `Password_expired` 、 `Password_last_changed` 、 `Password_lifetime` : [パスワード有効期限ポリシー](/password-management.md#password-expiration-policy)に使用されます。 -- 範囲： - - `Host` : TiDB アカウントのホスト名を指定します。 - - `User` : TiDB アカウントのユーザー名を指定します。 +- 範囲： + - `Host` : TiDB アカウントのホスト名を指定します。 + - `User` : TiDB アカウントのユーザー名を指定します。 -- 特権： +- 特権： `_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`フィールドで指定された認証プラグインに基づいて解釈されます。 - - `Account_locked` : ユーザー アカウントがロックされているかどうかを示します。 - - `Password_reuse_history`と`Password_reuse_time` : [パスワード再利用ポリシー](https://docs.pingcap.com/tidb/stable/password-management#password-reuse-policy)に使用されます。 - - `User_attributes` : ユーザーのコメントとユーザー属性に関する情報を提供します。 - - `Token_issuer` : [`tidb_auth_token`](https://docs.pingcap.com/tidb/stable/security-compatibility-with-mysql#tidb_auth_token)認証プラグインに使用されます。 - - `Password_expired` 、 `Password_last_changed` 、 `Password_lifetime` : [パスワード有効期限ポリシー](https://docs.pingcap.com/tidb/stable/password-management#password-expiration-policy)に使用されます。 +- セキュリティ： + - `authentication_string`と`plugin` ： `authentication_string`にはユーザーアカウントの認証情報が保存されます。認証情報は、 `plugin`フィールドで指定された認証プラグインに基づいて解釈されます。 + - `Account_locked` : ユーザー アカウントがロックされているかどうかを示します。 + - `Password_reuse_history`と`Password_reuse_time` : [パスワード再利用ポリシー](https://docs.pingcap.com/tidb/stable/password-management#password-reuse-policy)に使用されます。 + - `User_attributes` : ユーザーのコメントとユーザー属性に関する情報を提供します。 + - `Token_issuer` : [`tidb_auth_token`](https://docs.pingcap.com/tidb/stable/security-compatibility-with-mysql#tidb_auth_token)認証プラグインに使用されます。 + - `Password_expired` 、 `Password_last_changed` 、 `Password_lifetime` : [パスワード有効期限ポリシー](https://docs.pingcap.com/tidb/stable/password-management#password-expiration-policy)に使用されます。 diff --git a/mysql-schema/mysql-schema.md b/mysql-schema/mysql-schema.md index 6010872bda7cf..94b63fc248f4b 100644 --- a/mysql-schema/mysql-schema.md +++ b/mysql-schema/mysql-schema.md @@ -15,25 +15,25 @@ summary: TiDBのシステムテーブルについて学びましょう。 これらのシステムテーブルには、ユーザーアカウントとその権限に関する許可情報が含まれています。 -- [`user`](/mysql-schema/mysql-schema-user.md) ：ユーザーアカウント、グローバル権限、およびその他の権限以外の列 -- `db` : データベースレベルの権限 -- `tables_priv` : テーブルレベルの権限 -- `columns_priv` : 列レベルの権限 -- `password_history` : パスワード変更履歴 -- `default_roles` : ユーザーのデフォルトロール -- `global_grants` : 動的権限 -- `global_priv` : 証明書に基づく認証情報 -- `role_edges` : 役割間の関係 +- [`user`](/mysql-schema/mysql-schema-user.md) ：ユーザーアカウント、グローバル権限、およびその他の権限以外の列 +- `db` : データベースレベルの権限 +- `tables_priv` : テーブルレベルの権限 +- `columns_priv` : 列レベルの権限 +- `password_history` : パスワード変更履歴 +- `default_roles` : ユーザーのデフォルトロール +- `global_grants` : 動的権限 +- `global_priv` : 証明書に基づく認証情報 +- `role_edges` : 役割間の関係 ## クラスタステータスシステムテーブル {#cluster-status-system-tables} -- `tidb`テーブルには、TiDB に関するグローバル情報が含まれています。 +- `tidb`テーブルには、TiDB に関するグローバル情報が含まれています。 - - `bootstrapped` : TiDBクラスタが初期化されているかどうか。この値は読み取り専用であり、変更できません。 - - `tidb_server_version` : TiDB の初期化時のバージョン情報。この値は読み取り専用であり、変更できません。 - - `system_tz` : TiDB のシステム タイム ゾーン。 - - `new_collation_enabled` : TiDB が[照合順序のための新しいフレームワーク](/character-set-and-collation.md#new-framework-for-collations)を有効にしたかどうか。この値は読み取り専用であり、変更できないことに注意してください。 - - `cluster_id` （v8.5.6で追加）：TiDBクラスタの一意の識別子。この値は読み取り専用であり、変更できません。 + - `bootstrapped` : TiDBクラスタが初期化されているかどうか。この値は読み取り専用であり、変更できません。 + - `tidb_server_version` : TiDB の初期化時のバージョン情報。この値は読み取り専用であり、変更できません。 + - `system_tz` : TiDB のシステム タイム ゾーン。 + - `new_collation_enabled` : TiDB が[照合順序のための新しいフレームワーク](/character-set-and-collation.md#new-framework-for-collations)を有効にしたかどうか。この値は読み取り専用であり、変更できないことに注意してください。 + - `cluster_id` （v8.5.6で追加）：TiDBクラスタの一意の識別子。この値は読み取り専用であり、変更できません。 ## サーバー側のヘルプシステムテーブル {#server-side-help-system-tables} @@ -41,29 +41,29 @@ summary: TiDBのシステムテーブルについて学びましょう。 ## 統計システム表 {#statistics-system-tables} -- `stats_buckets` : 統計のバケット -- `stats_histograms` : 統計のヒストグラム -- `stats_top_n` : 統計のトップN -- `stats_meta` : テーブルのメタ情報（行の総数や更新された行数など） -- `stats_extended` : 列間の順序相関などの拡張統計 -- `stats_feedback` : 統計情報のクエリフィードバック -- `stats_fm_sketch` : 統計列のヒストグラムの FMSketch 分布 -- `stats_table_locked` : ロックされた統計情報に関する情報 -- `stats_meta_history` : 履歴統計のメタ情報 -- `stats_history` : 履歴統計のその他の情報 -- `analyze_options` : 各テーブルのデフォルトの`analyze`オプション -- `column_stats_usage` : 列統計の使用方法 -- `analyze_jobs` : 進行中の統計収集タスクと過去 7 日間の履歴タスク記録 +- `stats_buckets` : 統計のバケット +- `stats_histograms` : 統計のヒストグラム +- `stats_top_n` : 統計のトップN +- `stats_meta` : テーブルのメタ情報（行の総数や更新された行数など） +- `stats_extended` : 列間の順序相関などの拡張統計 +- `stats_feedback` : 統計情報のクエリフィードバック +- `stats_fm_sketch` : 統計列のヒストグラムの FMSketch 分布 +- `stats_table_locked` : ロックされた統計情報に関する情報 +- `stats_meta_history` : 履歴統計のメタ情報 +- `stats_history` : 履歴統計のその他の情報 +- `analyze_options` : 各テーブルのデフォルトの`analyze`オプション +- `column_stats_usage` : 列統計の使用方法 +- `analyze_jobs` : 進行中の統計収集タスクと過去 7 日間の履歴タスク記録 ## 実行計画関連のシステムテーブル {#execution-plan-related-system-tables} -- `bind_info` : 実行計画のバインディング情報 -- `capture_plan_baselines_blacklist` : 実行計画の自動バインド用のブロックリスト +- `bind_info` : 実行計画のバインディング情報 +- `capture_plan_baselines_blacklist` : 実行計画の自動バインド用のブロックリスト ## PLAN REPLAYERに関連するシステムテーブル {#system-tables-related-to-plan-replayer} -- `plan_replayer_status` : ユーザーが登録した[`PLAN REPLAYER CAPTURE`](https://docs.pingcap.com/tidb/stable/sql-plan-replayer#use-plan-replayer-capture)タスク -- `plan_replayer_task` : [`PLAN REPLAYER CAPTURE`](https://docs.pingcap.com/tidb/stable/sql-plan-replayer#use-plan-replayer-capture)タスクの結果 +- `plan_replayer_status` : ユーザーが登録した[`PLAN REPLAYER CAPTURE`](https://docs.pingcap.com/tidb/stable/sql-plan-replayer#use-plan-replayer-capture)タスク +- `plan_replayer_task` : [`PLAN REPLAYER CAPTURE`](https://docs.pingcap.com/tidb/stable/sql-plan-replayer#use-plan-replayer-capture)タスクの結果 ## GCワーカーシステムテーブル {#gc-worker-system-tables} @@ -71,51 +71,51 @@ summary: TiDBのシステムテーブルについて学びましょう。 > > GCワーカーシステムテーブルは、TiDB Self-Managedでのみ適用され、 [TiDB Cloud](https://docs.pingcap.com/tidbcloud/)では利用できません。 -- `gc_delete_range` : 削除する KV 範囲 -- `gc_delete_range_done` : 削除された KV 範囲 +- `gc_delete_range` : 削除する KV 範囲 +- `gc_delete_range_done` : 削除された KV 範囲 ## キャッシュされたテーブルに関連するシステムテーブル {#system-tables-related-to-cached-tables} -- `table_cache_meta`キャッシュされたテーブルのメタデータを保存します。 +- `table_cache_meta`キャッシュされたテーブルのメタデータを保存します。 ## TTL関連のシステムテーブル {#ttl-related-system-tables} -- `tidb_ttl_table_status` : すべてのTTLテーブルに対して、以前に実行されたTTLジョブと進行中のTTLジョブ -- `tidb_ttl_task` : 現在進行中のTTLサブタスク -- `tidb_ttl_job_history` : 過去 90 日間の TTL タスクの実行履歴 +- `tidb_ttl_table_status` : すべてのTTLテーブルに対して、以前に実行されたTTLジョブと進行中のTTLジョブ +- `tidb_ttl_task` : 現在進行中のTTLサブタスク +- `tidb_ttl_job_history` : 過去 90 日間の TTL タスクの実行履歴 ## 暴走クエリに関連するシステムテーブル {#system-tables-related-to-runaway-queries} -- `tidb_runaway_queries` : 過去 7 日間に検出されたすべての暴走クエリの履歴記録 -- `tidb_runaway_watch` : 暴走クエリの監視リスト -- `tidb_runaway_watch_done` : 削除または期限切れの暴走クエリの監視リスト +- `tidb_runaway_queries` : 過去 7 日間に検出されたすべての暴走クエリの履歴記録 +- `tidb_runaway_watch` : 暴走クエリの監視リスト +- `tidb_runaway_watch_done` : 削除または期限切れの暴走クエリの監視リスト ## メタデータロックに関連するシステムテーブル {#system-tables-related-to-metadata-locks} -- [`tidb_mdl_view`](/mysql-schema/mysql-schema-tidb-mdl-view.md) : メタデータ ロックのビュー。これを使用して、現在ブロックされている DDL ステートメントに関する情報を表示できます。[メタデータロック](/metadata-lock.md)も参照してください。 -- `tidb_mdl_info` : TiDB が内部的に使用して、ノード間でメタデータ ロックを同期します。 +- [`tidb_mdl_view`](/mysql-schema/mysql-schema-tidb-mdl-view.md) : メタデータ ロックのビュー。これを使用して、現在ブロックされている DDL ステートメントに関する情報を表示できます。[メタデータロック](/metadata-lock.md)も参照してください。 +- `tidb_mdl_info` : TiDB が内部的に使用して、ノード間でメタデータ ロックを同期します。 ## DDLステートメントに関連するシステムテーブル {#system-tables-related-to-ddl-statements} -- `tidb_ddl_history` : DDLステートメントの履歴レコード -- `tidb_ddl_job` : TiDBによって現在実行されているDDLステートメントのメタデータ -- `tidb_ddl_reorg` : TiDBによって現在実行されている物理DDLステートメント（インデックスの追加など）のメタデータ +- `tidb_ddl_history` : DDLステートメントの履歴レコード +- `tidb_ddl_job` : TiDBによって現在実行されているDDLステートメントのメタデータ +- `tidb_ddl_reorg` : TiDBによって現在実行されている物理DDLステートメント（インデックスの追加など）のメタデータ ## TiDB分散実行フレームワーク（DXF）に関連するシステムテーブル {#system-tables-related-to-tidb-distributed-execution-framework-dxf} -- `dist_framework_meta` : 分散実行フレームワーク (DXF) タスクスケジューラのメタデータ -- `tidb_global_task` : 現在の DXF タスクのメタデータ -- `tidb_global_task_history` : 成功したタスクと失敗したタスクの両方を含む、過去の DXF タスクのメタデータ -- `tidb_background_subtask` : 現在の DXF サブタスクのメタデータ -- `tidb_background_subtask_history` : 過去の DXF サブタスクのメタデータ +- `dist_framework_meta` : 分散実行フレームワーク (DXF) タスクスケジューラのメタデータ +- `tidb_global_task` : 現在の DXF タスクのメタデータ +- `tidb_global_task_history` : 成功したタスクと失敗したタスクの両方を含む、過去の DXF タスクのメタデータ +- `tidb_background_subtask` : 現在の DXF サブタスクのメタデータ +- `tidb_background_subtask_history` : 過去の DXF サブタスクのメタデータ ## リソース制御に関連するシステムテーブル {#system-tables-related-to-resource-control} -- `request_unit_by_group` : すべてのリソースグループの消費リソースユニット (RU) の履歴記録 +- `request_unit_by_group` : すべてのリソースグループの消費リソースユニット (RU) の履歴記録 ## バックアップと復元に関連するシステムテーブル {#system-tables-related-to-backup-and-restore} -- `tidb_pitr_id_map` : ポイントインタイムリカバリ(PITR) 操作の ID マッピング情報 +- `tidb_pitr_id_map` : ポイントインタイムリカバリ(PITR) 操作の ID マッピング情報 ## その他のシステムテーブル {#miscellaneous-system-tables} @@ -125,17 +125,17 @@ summary: TiDBのシステムテーブルについて学びましょう。 > > `tidb` 、 `expr_pushdown_blacklist` 、 `opt_rule_blacklist` 、 `table_cache_meta` 、 `tidb_import_jobs` 、および`tidb_timers`システムテーブルは、TiDB Self-Managedにのみ適用され、 [TiDB Cloud](https://docs.pingcap.com/tidbcloud/)では利用できません。 -- `GLOBAL_VARIABLES` : グローバルシステム変数テーブル -- `expr_pushdown_blacklist` : 式プッシュダウンのブロックリスト -- `opt_rule_blacklist` : 論理最適化ルールのブロックリスト -- `tidb_import_jobs` : [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)のジョブ情報 -- `tidb_timers` : 内部タイマーのメタデータ -- `advisory_locks` : [ロック関数](/functions-and-operators/locking-functions.md)に関する情報 +- `GLOBAL_VARIABLES` : グローバルシステム変数テーブル +- `expr_pushdown_blacklist` : 式プッシュダウンのブロックリスト +- `opt_rule_blacklist` : 論理最適化ルールのブロックリスト +- `tidb_import_jobs` : [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)のジョブ情報 +- `tidb_timers` : 内部タイマーのメタデータ +- `advisory_locks` : [ロック関数](/functions-and-operators/locking-functions.md)に関する情報 -- `GLOBAL_VARIABLES` : グローバルシステム変数テーブル +- `GLOBAL_VARIABLES` : グローバルシステム変数テーブル diff --git a/non-transactional-dml.md b/non-transactional-dml.md index 685770e4282d2..3b75b724ff18f 100644 --- a/non-transactional-dml.md +++ b/non-transactional-dml.md @@ -13,18 +13,18 @@ summary: TiDBの非トランザクションDMLステートメントについて 非トランザクション DML ステートメントには次のものがあります。 -- `INSERT INTO ... SELECT` -- `REPLACE INTO .. SELECT` -- `UPDATE` -- `DELETE` +- `INSERT INTO ... SELECT` +- `REPLACE INTO .. SELECT` +- `UPDATE` +- `DELETE` 詳細な構文については[`BATCH`](/sql-statements/sql-statement-batch.md)を参照してください。 > **Note:** > -> - 非トランザクション DML ステートメントは、ステートメントの原子性と分離性を保証せず、元の DML ステートメントと同等ではありません。 -> - DML ステートメントが非トランザクション DML ステートメントに書き換えられた後は、その動作が元のステートメントの動作と一致しているとは想定できません。 -> - 非トランザクション DML を使用する前に、分割されたステートメントが相互に影響を与えるかどうかを分析する必要があります。 +> - 非トランザクション DML ステートメントは、ステートメントの原子性と分離性を保証せず、元の DML ステートメントと同等ではありません。 +> - DML ステートメントが非トランザクション DML ステートメントに書き換えられた後は、その動作が元のステートメントの動作と一致しているとは想定できません。 +> - 非トランザクション DML を使用する前に、分割されたステートメントが相互に影響を与えるかどうかを分析する必要があります。 ## 使用シナリオ {#usage-scenarios} @@ -40,23 +40,23 @@ summary: TiDBの非トランザクションDMLステートメントについて 非トランザクション DML ステートメントを使用する前に、次の条件が満たされていることを確認してください。 -- このステートメントはアトミック性を必要としないため、実行結果で一部の行を変更し、一部の行を変更しないままにすることができます。 +- このステートメントはアトミック性を必要としないため、実行結果で一部の行を変更し、一部の行を変更しないままにすることができます。 -- ステートメントはべき等であるか、エラーメッセージに従ってデータの一部に対して再試行する準備ができています。システム変数が`tidb_redact_log = 1`と`tidb_nontransactional_ignore_error = 1`に設定されている場合、このステートメントはべき等である必要があります。そうでない場合、ステートメントが部分的に失敗した場合、失敗した部分を正確に特定できません。 +- ステートメントはべき等であるか、エラーメッセージに従ってデータの一部に対して再試行する準備ができています。システム変数が`tidb_redact_log = 1`と`tidb_nontransactional_ignore_error = 1`に設定されている場合、このステートメントはべき等である必要があります。そうでない場合、ステートメントが部分的に失敗した場合、失敗した部分を正確に特定できません。 -- 操作対象のデータには他の同時書き込みがないため、他のステートメントによって同時に更新されることはありません。そうでない場合、書き込みの欠落、誤った書き込み、同じ行の複数回の変更など、予期しない結果が発生する可能性があります。 +- 操作対象のデータには他の同時書き込みがないため、他のステートメントによって同時に更新されることはありません。そうでない場合、書き込みの欠落、誤った書き込み、同じ行の複数回の変更など、予期しない結果が発生する可能性があります。 -- このステートメントは、自身で読み取るデータを変更しません。変更しないと、後続のバッチは前のバッチで書き込まれたデータを読み取ってしまい、予期しない結果が発生しやすくなります。 +- このステートメントは、自身で読み取るデータを変更しません。変更しないと、後続のバッチは前のバッチで書き込まれたデータを読み取ってしまい、予期しない結果が発生しやすくなります。 - - 非トランザクション`INSERT INTO ... SELECT`ステートメント内で同じテーブルから選択して変更する場合は、シャード列を変更しないでください。そうしないと、複数のバッチが同じ行を読み取り、データを複数回挿入する可能性があります。 - - `BATCH ON test.t.id LIMIT 10000 INSERT INTO t SELECT id+1, value FROM t;`の使用は推奨されません。 - - `BATCH ON test.t.id LIMIT 10000 INSERT INTO t SELECT id, value FROM t;`を使用することをお勧めします。 - - シャード列`id`に`AUTO_INCREMENT`属性がある場合は、 `BATCH ON test.t.id LIMIT 10000 INSERT INTO t(value) SELECT value FROM t;`を使用することをお勧めします。 - - 非トランザクション`UPDATE` 、 `INSERT ... ON DUPLICATE KEY UPDATE` 、または`REPLACE INTO`ステートメントでシャード列を更新しないでください。 - - 例えば、非トランザクション`UPDATE`ステートメントの場合、分割された SQL ステートメントは順番に実行されます。前のバッチの変更は、前のバッチがコミットされた後に次のバッチによって読み取られるため、同じデータ行が複数回変更されることになります。 - - これらのステートメントは`BATCH ON test.t.id LIMIT 10000 UPDATE t SET test.t.id = test.t.id-1;`をサポートしていません。 - - `BATCH ON test.t.id LIMIT 1 INSERT INTO t SELECT id+1, value FROM t ON DUPLICATE KEY UPDATE id = id + 1;`の使用は推奨されません。 - - シャード列は結合キーとして使用しないでください。例えば、次の例ではシャード列`test.t.id`を結合キーとして使用しているため、非トランザクションの`UPDATE`文が同じ行を複数回変更することになります。 + - 非トランザクション`INSERT INTO ... SELECT`ステートメント内で同じテーブルから選択して変更する場合は、シャード列を変更しないでください。そうしないと、複数のバッチが同じ行を読み取り、データを複数回挿入する可能性があります。 + - `BATCH ON test.t.id LIMIT 10000 INSERT INTO t SELECT id+1, value FROM t;`の使用は推奨されません。 + - `BATCH ON test.t.id LIMIT 10000 INSERT INTO t SELECT id, value FROM t;`を使用することをお勧めします。 + - シャード列`id`に`AUTO_INCREMENT`属性がある場合は、 `BATCH ON test.t.id LIMIT 10000 INSERT INTO t(value) SELECT value FROM t;`を使用することをお勧めします。 + - 非トランザクション`UPDATE` 、 `INSERT ... ON DUPLICATE KEY UPDATE` 、または`REPLACE INTO`ステートメントでシャード列を更新しないでください。 + - 例えば、非トランザクション`UPDATE`ステートメントの場合、分割された SQL ステートメントは順番に実行されます。前のバッチの変更は、前のバッチがコミットされた後に次のバッチによって読み取られるため、同じデータ行が複数回変更されることになります。 + - これらのステートメントは`BATCH ON test.t.id LIMIT 10000 UPDATE t SET test.t.id = test.t.id-1;`をサポートしていません。 + - `BATCH ON test.t.id LIMIT 1 INSERT INTO t SELECT id+1, value FROM t ON DUPLICATE KEY UPDATE id = id + 1;`の使用は推奨されません。 + - シャード列は結合キーとして使用しないでください。例えば、次の例ではシャード列`test.t.id`を結合キーとして使用しているため、非トランザクションの`UPDATE`文が同じ行を複数回変更することになります。 ```sql CREATE TABLE t(id int, v int, key(id)); @@ -67,9 +67,9 @@ summary: TiDBの非トランザクションDMLステートメントについて SELECT * FROM t2; -- (4, 1) (4, 2) (4, 4) ``` -- この記述は[制限](#restrictions)を満たしています。 +- この記述は[制限](#restrictions)を満たしています。 -- この DML ステートメントによって読み取りまたは書き込みが行われるテーブルに対して同時 DDL 操作を実行することは推奨されません。 +- この DML ステートメントによって読み取りまたは書き込みが行われるテーブルに対して同時 DDL 操作を実行することは推奨されません。 > **Warning:** > @@ -232,19 +232,19 @@ BATCH ON id LIMIT 2 DELETE /*+ USE_INDEX(t)*/ FROM t WHERE v < 6; 非トランザクション DML ステートメントを使用するには、次の手順をお勧めします。 -1. 適切な[シャード列](#parameter-description)を選択します。整数型または文字列型が推奨されます。 +1. 適切な[シャード列](#parameter-description)を選択します。整数型または文字列型が推奨されます。 -2. 非トランザクション DML 文に`DRY RUN QUERY`追加し、クエリを手動で実行して、DML 文の影響を受けるデータ範囲がおおよそ正しいかどうかを確認します。 +2. 非トランザクション DML 文に`DRY RUN QUERY`追加し、クエリを手動で実行して、DML 文の影響を受けるデータ範囲がおおよそ正しいかどうかを確認します。 -3. 非トランザクションDML文に`DRY RUN`を追加し、クエリを手動で実行して、分割文と実行計画を確認してください。以下の点に注意する必要があります。 +3. 非トランザクションDML文に`DRY RUN`を追加し、クエリを手動で実行して、分割文と実行計画を確認してください。以下の点に注意する必要があります。 - - 分割ステートメントが前のステートメントによって書き込まれた結果を読み取ることができるかどうか。これにより異常が発生する可能性があります。 - - インデックスの選択性。 - - TiDB によって自動的に選択されたシャード列が変更されるかどうか。 + - 分割ステートメントが前のステートメントによって書き込まれた結果を読み取ることができるかどうか。これにより異常が発生する可能性があります。 + - インデックスの選択性。 + - TiDB によって自動的に選択されたシャード列が変更されるかどうか。 -4. 非トランザクション DML ステートメントを実行します。 +4. 非トランザクション DML ステートメントを実行します。 -5. エラーが報告された場合は、エラー メッセージまたはログから特定の失敗したデータ範囲を取得し、再試行するか手動で処理します。 +5. エラーが報告された場合は、エラー メッセージまたはログから特定の失敗したデータ範囲を取得し、再試行するか手動で処理します。 ## パラメータの説明 {#parameter-description} @@ -257,11 +257,11 @@ BATCH ON id LIMIT 2 DELETE /*+ USE_INDEX(t)*/ FROM t WHERE v < 6; 非トランザクションDML文は、データバッチ処理の基盤として列（シャード列）を使用します。実行効率を高めるには、シャード列でインデックスを使用する必要があります。異なるインデックスやシャード列によって、実行効率は数十倍も異なる可能性があります。シャード列を選択する際には、以下の点にご留意ください。 -- アプリケーションデータの分布がわかっている場合は、条件`WHERE`に従って、バッチ処理後にデータをより狭い範囲に分割する列を選択します。 - - 理想的には、条件`WHERE`ではシャード列のインデックスを利用することで、バッチごとにスキャンするデータ量を削減できます。例えば、各トランザクションの開始時刻と終了時刻を記録するトランザクションテーブルがあり、終了時刻が1か月前であるすべてのトランザクションレコードを削除したいとします。トランザクションの開始時刻にインデックスがあり、トランザクションの開始時刻と終了時刻が比較的近い場合は、開始時刻列をシャード列として選択できます。 - - 理想的とは言えないケースでは、シャード列のデータ分布は`WHERE`条件から完全に独立しており、シャード列のインデックスを使用してデータ スキャンの範囲を縮小することはできません。 -- クラスター化インデックスが存在する場合は、実行効率を高めるために、主キー（ `INT`主キーと`_tidb_rowid`含む）をシャード列として使用することをお勧めします。 -- 重複する値が少ない列を選択してください。 +- アプリケーションデータの分布がわかっている場合は、条件`WHERE`に従って、バッチ処理後にデータをより狭い範囲に分割する列を選択します。 + - 理想的には、条件`WHERE`ではシャード列のインデックスを利用することで、バッチごとにスキャンするデータ量を削減できます。例えば、各トランザクションの開始時刻と終了時刻を記録するトランザクションテーブルがあり、終了時刻が1か月前であるすべてのトランザクションレコードを削除したいとします。トランザクションの開始時刻にインデックスがあり、トランザクションの開始時刻と終了時刻が比較的近い場合は、開始時刻列をシャード列として選択できます。 + - 理想的とは言えないケースでは、シャード列のデータ分布は`WHERE`条件から完全に独立しており、シャード列のインデックスを使用してデータ スキャンの範囲を縮小することはできません。 +- クラスター化インデックスが存在する場合は、実行効率を高めるために、主キー（ `INT`主キーと`_tidb_rowid`含む）をシャード列として使用することをお勧めします。 +- 重複する値が少ない列を選択してください。 シャード列を指定しないことも可能です。その場合、TiDBはデフォルトで最初の列`handle`をシャード列として使用します。ただし、クラスター化インデックスの主キーの最初の列が、非トランザクションDML文でサポートされていないデータ型（ `ENUM` 、 `BIT` 、 `SET` 、 `JSON` ）の場合、TiDBはエラーを報告します。アプリケーションのニーズに応じて適切なシャード列を選択できます。 @@ -275,16 +275,16 @@ BATCH ON id LIMIT 2 DELETE /*+ USE_INDEX(t)*/ FROM t WHERE v < 6; 以下は非トランザクションDML文に対する厳格な制限です。これらの制限が満たされない場合、TiDBはエラーを報告します。 -- DML ステートメントには`ORDER BY`または`LIMIT`句を含めることはできません。 -- サブクエリまたはセット演算はサポートされていません。 -- シャード列にはインデックスが必要です。インデックスは単一列インデックス、または結合インデックスの最初の列にすることができます。 -- [`autocommit`](/system-variables.md#autocommit)モードで使用する必要があります。 -- batch-dml が有効な場合は使用できません。 -- [`tidb_snapshot`](/read-historical-data.md)が設定されている場合は使用できません。 -- `prepare`ステートメントでは使用できません。 -- `ENUM` 、 `BIT` 、 `SET` 、 `JSON`タイプはシャード列としてサポートされていません。 -- [一時テーブル](/temporary-tables.md)にはサポートされていません。 -- [共通テーブル式](/develop/dev-guide-use-common-table-expression.md)はサポートされていません。 +- DML ステートメントには`ORDER BY`または`LIMIT`句を含めることはできません。 +- サブクエリまたはセット演算はサポートされていません。 +- シャード列にはインデックスが必要です。インデックスは単一列インデックス、または結合インデックスの最初の列にすることができます。 +- [`autocommit`](/system-variables.md#autocommit)モードで使用する必要があります。 +- batch-dml が有効な場合は使用できません。 +- [`tidb_snapshot`](/read-historical-data.md)が設定されている場合は使用できません。 +- `prepare`ステートメントでは使用できません。 +- `ENUM` 、 `BIT` 、 `SET` 、 `JSON`タイプはシャード列としてサポートされていません。 +- [一時テーブル](/temporary-tables.md)にはサポートされていません。 +- [共通テーブル式](/develop/dev-guide-use-common-table-expression.md)はサポートされていません。 ## 制御バッチ実行の失敗 {#control-batch-execution-failure} @@ -298,10 +298,10 @@ BATCH ON id LIMIT 2 DELETE /*+ USE_INDEX(t)*/ FROM t WHERE v < 6; 非トランザクション DML `BATCH ON $C$ LIMIT $N$ DELETE FROM ... WHERE $P$`の場合、$C$ は分割に使用される列、$N$ はバッチ サイズ、$P$ はフィルター条件です。 -1. TiDBは、元のステートメントのフィルタ条件$P$と分割対象として指定された列$C$に基づいて、$P$を満たすすべての$C$をクエリします。TiDBはこれらの$C$を$N$に基づいてグループ$B_1 \dots B_k$に分類します。すべての$B_i$について、TiDBは最初と最後の$C$を$S_i$と$E_i$として保持します。このステップで実行されたクエリステートメントは、 [`DRY RUN QUERY`](/non-transactional-dml.md#query-the-batch-dividing-statement)を通して確認できます。 -2. $B_i$に含まれるデータは、$P_i$を満たすサブセットです: $C$ BETWEEN $S_i$ AND $E_i$。$P_i$を使用することで、各バッチで処理する必要があるデータの範囲を絞り込むことができます。 -3. $B_i$ の場合、TiDBは上記の条件を元の文の`WHERE`条件に埋め込み、WHERE ($P_i$) AND ($P$) とします。このステップの実行結果は[`DRY RUN`](/non-transactional-dml.md#query-the-statements-corresponding-to-the-first-and-the-last-batches)で確認できます。 -4. すべてのバッチに対して、新しいステートメントを順番に実行します。各グループのエラーは収集および結合され、すべてのグループが完了した後に、非トランザクションDMLステートメント全体の結果として返されます。 +1. TiDBは、元のステートメントのフィルタ条件$P$と分割対象として指定された列$C$に基づいて、$P$を満たすすべての$C$をクエリします。TiDBはこれらの$C$を$N$に基づいてグループ$B_1 \dots B_k$に分類します。すべての$B_i$について、TiDBは最初と最後の$C$を$S_i$と$E_i$として保持します。このステップで実行されたクエリステートメントは、 [`DRY RUN QUERY`](/non-transactional-dml.md#query-the-batch-dividing-statement)を通して確認できます。 +2. $B_i$に含まれるデータは、$P_i$を満たすサブセットです: $C$ BETWEEN $S_i$ AND $E_i$。$P_i$を使用することで、各バッチで処理する必要があるデータの範囲を絞り込むことができます。 +3. $B_i$ の場合、TiDBは上記の条件を元の文の`WHERE`条件に埋め込み、WHERE ($P_i$) AND ($P$) とします。このステップの実行結果は[`DRY RUN`](/non-transactional-dml.md#query-the-statements-corresponding-to-the-first-and-the-last-batches)で確認できます。 +4. すべてのバッチに対して、新しいステートメントを順番に実行します。各グループのエラーは収集および結合され、すべてのグループが完了した後に、非トランザクションDMLステートメント全体の結果として返されます。 ## バッチDMLとの比較 {#comparison-with-batch-dml} @@ -313,9 +313,9 @@ batch-dml は、DML ステートメントの実行中にトランザクション 非トランザクションDML文は、まだすべてのバッチDML使用シナリオの代替となるわけではありません。主な違いは次のとおりです。 -- パフォーマンス: [シャード列](#how-to-select-a-shard-column)が効率的な場合、非トランザクションDMLステートメントのパフォーマンスはバッチDMLのパフォーマンスに近づきます。シャード列の効率が低い場合、非トランザクションDMLステートメントのパフォーマンスはバッチDMLよりも大幅に低下します。 +- パフォーマンス: [シャード列](#how-to-select-a-shard-column)が効率的な場合、非トランザクションDMLステートメントのパフォーマンスはバッチDMLのパフォーマンスに近づきます。シャード列の効率が低い場合、非トランザクションDMLステートメントのパフォーマンスはバッチDMLよりも大幅に低下します。 -- 安定性：batch-dmlは、不適切な使用によりデータインデックスの不整合が発生しやすい傾向があります。非トランザクションDML文はデータインデックスの不整合を引き起こしません。ただし、不適切に使用された場合、非トランザクションDML文は元の文と同等ではなくなり、アプリケーションで予期しない動作が発生する可能性があります。詳細は[よくある問題のセクション](#non-transactional-delete-has-exceptional-behavior-that-is-not-equivalent-to-ordinary-delete)を参照してください。 +- 安定性：batch-dmlは、不適切な使用によりデータインデックスの不整合が発生しやすい傾向があります。非トランザクションDML文はデータインデックスの不整合を引き起こしません。ただし、不適切に使用された場合、非トランザクションDML文は元の文と同等ではなくなり、アプリケーションで予期しない動作が発生する可能性があります。詳細は[よくある問題のセクション](#non-transactional-delete-has-exceptional-behavior-that-is-not-equivalent-to-ordinary-delete)を参照してください。 ## よくある問題 {#common-issues} @@ -374,9 +374,9 @@ WHERE t.c1 IS NULL; このエラーを回避するには、次の推奨事項に従ってください。 -- 非トランザクションDML文ではテーブルエイリアスの使用は避けてください。例えば、 `t.c1`を`c1`または`t_old.c1`に書き換えます。 -- [破片の列](#parameter-description)を指定する際は、テーブルエイリアスを使用しないでください。例えば、 `BATCH ON t.id`を `BATCH ON db.t_old.id`または`BATCH ON t_old.id`に書き換えます。 -- 実行する前に、 `DRY RUN QUERY`または`DRY RUN`を使用して書き換えられたステートメントをプレビューし、期待どおりであることを確認します。 +- 非トランザクションDML文ではテーブルエイリアスの使用は避けてください。例えば、 `t.c1`を`c1`または`t_old.c1`に書き換えます。 +- [破片の列](#parameter-description)を指定する際は、テーブルエイリアスを使用しないでください。例えば、 `BATCH ON t.id`を `BATCH ON db.t_old.id`または`BATCH ON t_old.id`に書き換えます。 +- 実行する前に、 `DRY RUN QUERY`または`DRY RUN`を使用して書き換えられたステートメントをプレビューし、期待どおりであることを確認します。 ### 実際のバッチサイズは指定されたバッチサイズと同じではありません {#the-actual-batch-size-is-not-the-same-as-the-specified-batch-size} @@ -406,10 +406,10 @@ WHERE t.c1 IS NULL; 非トランザクション DML ステートメントは、この DML ステートメントの元の形式と同等ではありません。次のような理由が考えられます。 -- 他にも同時書き込みがあります。 -- 非トランザクション DML ステートメントは、ステートメント自体が読み取る値を変更します。 -- 各バッチで実行されるSQL文は、 `WHERE`条件が変更されるため、実行計画や式の計算順序が異なる場合があります。そのため、実行結果が元のSQL文と異なる可能性があります。 -- DML ステートメントには非決定論的な操作が含まれています。 +- 他にも同時書き込みがあります。 +- 非トランザクション DML ステートメントは、ステートメント自体が読み取る値を変更します。 +- 各バッチで実行されるSQL文は、 `WHERE`条件が変更されるため、実行計画や式の計算順序が異なる場合があります。そのため、実行結果が元のSQL文と異なる可能性があります。 +- DML ステートメントには非決定論的な操作が含まれています。 ## MySQLとの互換性 {#mysql-compatibility} @@ -417,5 +417,5 @@ WHERE t.c1 IS NULL; ## 参照 {#see-also} -- [`BATCH`](/sql-statements/sql-statement-batch.md)構文 -- [`tidb_nontransactional_ignore_error`](/system-variables.md#tidb_nontransactional_ignore_error-new-in-v610) +- [`BATCH`](/sql-statements/sql-statement-batch.md)構文 +- [`tidb_nontransactional_ignore_error`](/system-variables.md#tidb_nontransactional_ignore_error-new-in-v610) diff --git a/online-unsafe-recovery.md b/online-unsafe-recovery.md index 763c64a962e9b..7c7eca85a2638 100644 --- a/online-unsafe-recovery.md +++ b/online-unsafe-recovery.md @@ -23,9 +23,9 @@ TiDBでは、ユーザーが定義したレプリカルールに従って、同 オンライン安全でない回復機能は、次のシナリオに適しています。 -- ストアが永久的に破損すると、ストアを再起動できなくなるため、アプリケーション サービスのデータは読み取りおよび書き込み不能になります。 -- データの損失を受け入れ、影響を受けるデータを読み取りおよび書き込み可能にすることができます。 -- ワンストップのオンラインデータ復旧操作を実行したい。 +- ストアが永久的に破損すると、ストアを再起動できなくなるため、アプリケーション サービスのデータは読み取りおよび書き込み不能になります。 +- データの損失を受け入れ、影響を受けるデータを読み取りおよび書き込み可能にすることができます。 +- ワンストップのオンラインデータ復旧操作を実行したい。 ## 使用法 {#usage} @@ -33,8 +33,8 @@ TiDBでは、ユーザーが定義したレプリカルールに従って、同 Online Unsafe Recovery を使用する前に、次の要件が満たされていることを確認してください。 -- 確かに、オフライン ストアでは一部のデータが利用できなくなります。 -- オフライン ストアは自動的に回復または再起動できません。 +- 確かに、オフライン ストアでは一部のデータが利用できなくなります。 +- オフライン ストアは自動的に回復または再起動できません。 ### ステップ1. 回復できないストアを指定する {#step-1-specify-the-stores-that-cannot-be-recovered} @@ -46,8 +46,8 @@ pd-ctl -u unsafe remove-failed-stores > **Note:** > -> - 上記のコマンドでは、回復不可能な**すべての**TiKVノードとTiFlashノードが一度に指定されていることを確認してください。回復不可能なノードを省略すると、回復プロセスがブロックされる可能性があります。 -> - 短期間内（1 日以内など）にオンライン アンセーフ リカバリを既に実行している場合は、このコマンドの後続の実行に、以前に処理された TiKV ノードとTiFlashノードがまだ含まれていることを確認してください。 +> - 上記のコマンドでは、回復不可能な**すべての**TiKVノードとTiFlashノードが一度に指定されていることを確認してください。回復不可能なノードを省略すると、回復プロセスがブロックされる可能性があります。 +> - 短期間内（1 日以内など）にオンライン アンセーフ リカバリを既に実行している場合は、このコマンドの後続の実行に、以前に処理された TiKV ノードとTiFlashノードがまだ含まれていることを確認してください。 リカバリタスクの最長時間を指定するには、 `--timeout `オプションを使用します。このオプションを指定しない場合、デフォルトの最長時間は5分です。タイムアウトが発生すると、リカバリは中断され、エラーが返されます。 @@ -55,9 +55,9 @@ pd-ctl -u unsafe remove-failed-stores コマンドが`Failed`返す場合、 PD ControlはタスクをPDに登録できませんでした。考えられるエラーは次のとおりです。 -- `unsafe recovery is running` : 進行中の回復タスクがすでに存在します。 -- `invalid input store x doesn't exist` ：指定されたストア ID は存在しません。 -- `invalid input store x is up and connected` : ID を持つ指定されたストアはまだ正常であり、回復する必要はありません。 +- `unsafe recovery is running` : 進行中の回復タスクがすでに存在します。 +- `invalid input store x doesn't exist` ：指定されたストア ID は存在しません。 +- `invalid input store x is up and connected` : ID を持つ指定されたストアはまだ正常であり、回復する必要はありません。 [`pd-recover`](/pd-recover.md)ような災害復旧操作後にPDが復旧不可能なTiKVノードのストア情報を失い、特定のストアIDが不明になった場合は、 `--auto-detect`モードを使用できます。このモードでは、PDは未登録または以前に登録されたが強制的に削除されたTiKVノードからレプリカを自動的に削除できます。 @@ -67,10 +67,10 @@ pd-ctl -u unsafe remove-failed-stores --auto-detect > **Note:** > -> - 安全でないリカバリではすべてのピアから情報を収集する必要があるため、メモリ使用量が増加する可能性があります (100,000 のピアは 500 MiB のメモリを使用すると推定されます)。 -> - コマンドの実行中に PD が再起動すると、リカバリが中断され、タスクを再度トリガーする必要があります。 -> - コマンドを実行すると、指定されたストアは Tombstone ステータスに設定され、これらのストアを再起動できなくなります。 -> - コマンドの実行中は、すべてのスケジュール タスクと分割/マージが一時停止され、回復が成功または失敗した後に自動的に再開されます。 +> - 安全でないリカバリではすべてのピアから情報を収集する必要があるため、メモリ使用量が増加する可能性があります (100,000 のピアは 500 MiB のメモリを使用すると推定されます)。 +> - コマンドの実行中に PD が再起動すると、リカバリが中断され、タスクを再度トリガーする必要があります。 +> - コマンドを実行すると、指定されたストアは Tombstone ステータスに設定され、これらのストアを再起動できなくなります。 +> - コマンドの実行中は、すべてのスケジュール タスクと分割/マージが一時停止され、回復が成功または失敗した後に自動的に再開されます。 ### ステップ2. 回復の進行状況を確認し、完了を待ちます {#step-2-check-the-recovery-progress-and-wait-for-the-completion} @@ -82,12 +82,12 @@ pd-ctl -u unsafe remove-failed-stores show 回復プロセスには複数の段階があります。 -- `collect report` : PD が TiKV からレポートを収集し、グローバル情報を取得する初期段階。 -- `tombstone tiflash learner` : 異常なリージョンのうち、他の正常なピアよりも新しいTiFlashラーナーを削除して、このような極端な状況やpanicの可能性を防ぎます。 -- `force leader for commit merge` : 特別な段階。コミットマージが完了していない場合、極端な状況を想定して、コミットマージが行われたリージョンに対してまず`force leader`が実行されます。 -- `force leader` : 正常でないリージョンに、残りの正常なピアの中からRaftリーダーを割り当てるように強制します。 -- `demote failed voter` : リージョンの失敗した投票者をラーナーに降格し、その後、リージョンは通常どおりRaftリーダーを選出できます。 -- `create empty region` : キー範囲のギャップを埋めるために空のリージョンを作成します。これは、一部のリージョンのすべてのレプリカを含むストアが破損しているケースを解決するためのものです。 +- `collect report` : PD が TiKV からレポートを収集し、グローバル情報を取得する初期段階。 +- `tombstone tiflash learner` : 異常なリージョンのうち、他の正常なピアよりも新しいTiFlashラーナーを削除して、このような極端な状況やpanicの可能性を防ぎます。 +- `force leader for commit merge` : 特別な段階。コミットマージが完了していない場合、極端な状況を想定して、コミットマージが行われたリージョンに対してまず`force leader`が実行されます。 +- `force leader` : 正常でないリージョンに、残りの正常なピアの中からRaftリーダーを割り当てるように強制します。 +- `demote failed voter` : リージョンの失敗した投票者をラーナーに降格し、その後、リージョンは通常どおりRaftリーダーを選出できます。 +- `create empty region` : キー範囲のギャップを埋めるために空のリージョンを作成します。これは、一部のリージョンのすべてのレプリカを含むストアが破損しているケースを解決するためのものです。 上記の各ステージは、情報、時間、詳細な復旧計画を含むJSON形式で出力されます。例： @@ -157,8 +157,8 @@ SELECT TABLE_SCHEMA, TABLE_NAME, TIDB_TABLE_ID FROM INFORMATION_SCHEMA.TABLES WH > **Note:** > -> - 回復操作により、一部の投票失敗者が学習失敗者になりました。そのため、PDスケジュールではこれらの学習失敗者を削除するのに時間がかかります。 -> - 新しいストアを随時追加することをお勧めします。 +> - 回復操作により、一部の投票失敗者が学習失敗者になりました。そのため、PDスケジュールではこれらの学習失敗者を削除するのに時間がかかります。 +> - 新しいストアを随時追加することをお勧めします。 タスク実行中にエラーが発生した場合、出力の最後のステージに`"Unsafe recovery failed"`とエラーメッセージが表示されます。例： @@ -183,19 +183,19 @@ ADMIN CHECK TABLE table_name; 不整合なインデックスがある場合は、古いインデックスの名前を変更し、新しいインデックスを作成してから、古いインデックスを削除することで、インデックスの不整合を修正できます。 -1. 古いインデックスの名前を変更します: +1. 古いインデックスの名前を変更します: ```sql ALTER TABLE table_name RENAME INDEX index_name TO index_name_lame_duck; ``` -2. 新しいインデックスを作成します。 +2. 新しいインデックスを作成します。 ```sql ALTER TABLE table_name ADD INDEX index_name (column_name); ``` -3. 古いインデックスを削除します。 +3. 古いインデックスを削除します。 ```sql ALTER TABLE table_name DROP INDEX index_name_lame_duck; @@ -206,13 +206,13 @@ ADMIN CHECK TABLE table_name;
-1. 回復不可能なノードを削除します。 +1. 回復不可能なノードを削除します。 ```bash tiup cluster scale-in -N --force ``` -2. Tombstone ノードをクリーンアップします。 +2. Tombstone ノードをクリーンアップします。 ```bash tiup cluster prune @@ -221,13 +221,13 @@ ADMIN CHECK TABLE table_name;
-1. `PersistentVolumeClaim`を削除します。 +1. `PersistentVolumeClaim`を削除します。 ```bash kubectl delete -n ${namespace} pvc ${pvc_name} --wait=false ``` -2. TiKV ポッドを削除し、新しく作成された TiKV ポッドがクラスターに参加するのを待ちます。 +2. TiKV ポッドを削除し、新しく作成された TiKV ポッドがクラスターに参加するのを待ちます。 ```bash kubectl delete -n ${namespace} pod ${pod_name} diff --git a/optimistic-transaction.md b/optimistic-transaction.md index 575f488db0fdb..400f092b52fc6 100644 --- a/optimistic-transaction.md +++ b/optimistic-transaction.md @@ -68,48 +68,48 @@ sequenceDiagram TiDB-->>client: success ``` -1. クライアントがトランザクションを開始します。 +1. クライアントがトランザクションを開始します。 TiDB は、現在のトランザクションの一意のトランザクション ID として、PD からタイムスタンプ (時間とともに単調増加し、グローバルに一意) を取得します。これを`start_ts`と呼びます。TiDB はマルチバージョン同時実行制御を実装しているため、 `start_ts`このトランザクションによって取得されたデータベース スナップショットのバージョンとしても機能します。つまり、トランザクションは`start_ts`のデータベースからのみデータを読み取ることができます。 -2. クライアントは読み取りリクエストを発行します。 +2. クライアントは読み取りリクエストを発行します。 - 1. TiDBはPDからルーティング情報（TiKVノード間でデータがどのように分散されるか）を受け取ります。 - 2. TiDBはTiKVからバージョン`start_ts`のデータを受信する。 + 1. TiDBはPDからルーティング情報（TiKVノード間でデータがどのように分散されるか）を受け取ります。 + 2. TiDBはTiKVからバージョン`start_ts`のデータを受信する。 -3. クライアントが書き込みリクエストを発行します。 +3. クライアントが書き込みリクエストを発行します。 TiDBは、書き込まれたデータが制約を満たしているかどうかを確認します（データ型が正しいこと、NOT NULL制約が満たされていることなど）。**有効なデータは、TiDB内のこのトランザクションのプライベートメモリに格納されます**。 -4. クライアントはコミット要求を発行します。 +4. クライアントはコミット要求を発行します。 -5. TiDBは2PC方式を採用し、トランザクションの原子性を保証すると同時に、データをストア内に永続化します。 +5. TiDBは2PC方式を採用し、トランザクションの原子性を保証すると同時に、データをストア内に永続化します。 - 1. TiDBは、書き込むデータから主キーを選択します。 - 2. TiDBはPDからリージョン分布情報を受け取り、それに応じてすべてのキーをリージョンごとにグループ化します。 - 3. TiDBは、関係するすべてのTiKVノードに書き込み前リクエストを送信します。その後、TiKVは競合や期限切れのバージョンがないかを確認します。有効なデータはロックされます。 - 4. TiDBはプリライトフェーズで全ての応答を受信し、プリライトは成功しました。 - 5. TiDB は PD からコミット バージョン番号を受け取り、それを`commit_ts`とマークします。 - 6. TiDBは、主キーが格納されているTiKVノードへの2回目のコミットを開始します。TiKVはデータをチェックし、書き込み前フェーズで残されたロックを解除します。 - 7. TiDBは、第2フェーズが正常に完了したことを報告するメッセージを受信する。 + 1. TiDBは、書き込むデータから主キーを選択します。 + 2. TiDBはPDからリージョン分布情報を受け取り、それに応じてすべてのキーをリージョンごとにグループ化します。 + 3. TiDBは、関係するすべてのTiKVノードに書き込み前リクエストを送信します。その後、TiKVは競合や期限切れのバージョンがないかを確認します。有効なデータはロックされます。 + 4. TiDBはプリライトフェーズで全ての応答を受信し、プリライトは成功しました。 + 5. TiDB は PD からコミット バージョン番号を受け取り、それを`commit_ts`とマークします。 + 6. TiDBは、主キーが格納されているTiKVノードへの2回目のコミットを開始します。TiKVはデータをチェックし、書き込み前フェーズで残されたロックを解除します。 + 7. TiDBは、第2フェーズが正常に完了したことを報告するメッセージを受信する。 -6. TiDBは、トランザクションが正常にコミットされたことをクライアントに通知するメッセージを返します。 +6. TiDBは、トランザクションが正常にコミットされたことをクライアントに通知するメッセージを返します。 -7. TiDBは、このトランザクションに残っているロックを非同期的にクリアします。 +7. TiDBは、このトランザクションに残っているロックを非同期的にクリアします。 ## メリットとデメリット {#advantages-and-disadvantages} 上記のTiDBにおけるトランザクション処理から、TiDBトランザクションには以下の利点があることが明らかです。 -- 理解しやすい -- 単一行トランザクションに基づくクロスノードトランザクションを実装する -- 分散型ロック管理 +- 理解しやすい +- 単一行トランザクションに基づくクロスノードトランザクションを実装する +- 分散型ロック管理 しかし、TiDBトランザクションには次のような欠点もあります。 -- 2PCによるトランザクションレイテンシー -- タイムスタンプ割り当てを一元管理するサービスが必要 -- メモリに大量のデータが書き込まれたときに発生するOOM（メモリ不足）エラー +- 2PCによるトランザクションレイテンシー +- タイムスタンプ割り当てを一元管理するサービスが必要 +- メモリに大量のデータが書き込まれたときに発生するOOM（メモリ不足）エラー ## トランザクションの再試行 {#transaction-retries} @@ -123,8 +123,8 @@ sequenceDiagram > **Note:** > -> - TiDB v3.0.0以降、トランザクションの自動再試行はデフォルトで無効になっています。これは、**トランザクション分離レベルを損なう**可能性があるためです。 -> - TiDB v8.0.0以降、楽観的トランザクションの自動再試行はサポートされなくなりました。 +> - TiDB v3.0.0以降、トランザクションの自動再試行はデフォルトで無効になっています。これは、**トランザクション分離レベルを損なう**可能性があるためです。 +> - TiDB v8.0.0以降、楽観的トランザクションの自動再試行はサポートされなくなりました。 トランザクションのコミット中に書き込み競合が発生した場合、TiDB は書き込み操作を含む SQL ステートメントを自動的に再試行します。自動再試行を有効にするには、 `tidb_disable_txn_auto_retry`を`OFF`に設定し、再試行回数の上限を`tidb_retry_limit`に設定してください。 @@ -138,7 +138,7 @@ tidb_retry_limit = 10 自動再試行は、セッションレベルまたはグローバルレベルのいずれかで有効にできます。 -1. セッションレベル: +1. セッションレベル: ```sql SET tidb_disable_txn_auto_retry = OFF; @@ -148,7 +148,7 @@ tidb_retry_limit = 10 SET tidb_retry_limit = 10; ``` -2. 世界レベル： +2. 世界レベル： ```sql SET GLOBAL tidb_disable_txn_auto_retry = OFF; @@ -168,9 +168,9 @@ tidb_retry_limit = 10 その理由は、再試行の手順から明らかである。 -1. 新しいタイムスタンプを割り当てて、それを`start_ts`とマークします。 -2. 書き込み操作を含むSQL文を再試行してください。 -3. 2フェーズコミットを実装する。 +1. 新しいタイムスタンプを割り当てて、それを`start_ts`とマークします。 +2. 書き込み操作を含むSQL文を再試行してください。 +3. 2フェーズコミットを実装する。 ステップ2では、TiDBは書き込み操作を含むSQLステートメントのみを再試行します。ただし、再試行中に、TiDBはトランザクションの開始を示す新しいバージョン番号を受け取ります。つまり、TiDBは新しいバージョン`start_ts`のデータを使用してSQLステートメントを再試行します。この場合、トランザクションが他のクエリ結果を使用してデータを更新すると、分離レベル`REPEATABLE READ`が侵害されるため、結果に矛盾が生じる可能性があります。 diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md index fffe2522ad80e..d7254180383bd 100644 --- a/optimizer-fix-controls.md +++ b/optimizer-fix-controls.md @@ -7,8 +7,8 @@ summary: オプティマイザー修正制御機能について学習し、tidb_ 製品が継続的に進化するにつれて、TiDBオプティマイザの動作が変化し、より合理的な実行計画が生成されます。しかし、特定のシナリオでは、新しい動作が予期しない結果につながる可能性があります。例えば、 -- 一部の動作の効果は特定のシナリオに依存します。ほとんどのシナリオで改善をもたらす変更が、他のシナリオでは後退を引き起こす可能性があります。 -- 場合によっては、行動の詳細の変化とその結果の関係が非常に複雑になることがあります。特定の行動の改善が、全体的な退行を引き起こす可能性があります。 +- 一部の動作の効果は特定のシナリオに依存します。ほとんどのシナリオで改善をもたらす変更が、他のシナリオでは後退を引き起こす可能性があります。 +- 場合によっては、行動の詳細の変化とその結果の関係が非常に複雑になることがあります。特定の行動の改善が、全体的な退行を引き起こす可能性があります。 そのため、TiDBは、複数の修正項目に値を設定することで、TiDBオプティマイザの動作をきめ細かく制御できるオプティマイザ修正制御機能を提供しています。このドキュメントでは、オプティマイザ修正制御機能とその使用方法について説明し、TiDBが現在オプティマイザ修正制御でサポートしているすべての修正項目を一覧表示します。 @@ -28,92 +28,92 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; ### `33031`バージョン8.0.0の新機能 {#33031-new-in-v800} -- デフォルト値: `OFF` -- 可能`OFF`値: `ON` -- この変数は、パーティションテーブルに対してプランキャッシュを許可するかどうかを制御します。 `ON`に設定した場合、 [パーティションテーブル](/partitioned-table.md)では[プリペアドステートメントプランキャッシュ](/sql-prepared-plan-cache.md)も[非プリペアドステートメントプランキャッシュ](/sql-non-prepared-plan-cache.md)有効になりません。 +- デフォルト値: `OFF` +- 可能`OFF`値: `ON` +- この変数は、パーティションテーブルに対してプランキャッシュを許可するかどうかを制御します。 `ON`に設定した場合、 [パーティションテーブル](/partitioned-table.md)では[プリペアドステートメントプランキャッシュ](/sql-prepared-plan-cache.md)も[非プリペアドステートメントプランキャッシュ](/sql-non-prepared-plan-cache.md)有効になりません。 ### `44262` v6.5.3 および v7.2.0 の新機能 {#44262-new-in-v653-and-v720} -- デフォルト値: `OFF` -- 可能`OFF`値: `ON` -- この変数は、パーティションテーブルの[世界統計](/statistics.md#collect-statistics-of-partitioned-tables-in-dynamic-pruning-mode)が欠落している場合に、 [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)を使用してそのテーブルにアクセスできるようにするかどうかを制御します。 +- デフォルト値: `OFF` +- 可能`OFF`値: `ON` +- この変数は、パーティションテーブルの[世界統計](/statistics.md#collect-statistics-of-partitioned-tables-in-dynamic-pruning-mode)が欠落している場合に、 [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)を使用してそのテーブルにアクセスできるようにするかどうかを制御します。 ### `44389` v6.5.3 および v7.2.0 の新機能 {#44389-new-in-v653-and-v720} -- デフォルト値: `OFF` -- 可能`OFF`値: `ON` -- `c = 10 and (a = 'xx' or (a = 'kk' and b = 1))`などのフィルターの場合、この変数は`IndexRangeScan`より包括的なスキャン範囲を構築するかどうかを制御します。 +- デフォルト値: `OFF` +- 可能`OFF`値: `ON` +- `c = 10 and (a = 'xx' or (a = 'kk' and b = 1))`などのフィルターの場合、この変数は`IndexRangeScan`より包括的なスキャン範囲を構築するかどうかを制御します。 ### `44823`バージョン7.3.0の新機能 {#44823-new-in-v730} -- デフォルト値: `200` -- 可能な値: `[0, 2147483647]` -- メモリを節約するために、プラン キャッシュでは、この変数で指定された数を超えるパラメータを持つクエリはキャッシュされません。 `0`制限がないことを意味します。 +- デフォルト値: `200` +- 可能な値: `[0, 2147483647]` +- メモリを節約するために、プラン キャッシュでは、この変数で指定された数を超えるパラメータを持つクエリはキャッシュされません。 `0`制限がないことを意味します。 ### `44830` v6.5.7 および v7.3.0 の新機能 {#44830-new-in-v657-and-v730} -- デフォルト値: `OFF` -- 可能`OFF`値: `ON` -- この変数は、物理的な最適化中に生成された`PointGet`演算子を使用して実行計画をプラン キャッシュがキャッシュできるかどうかを制御します。 +- デフォルト値: `OFF` +- 可能`OFF`値: `ON` +- この変数は、物理的な最適化中に生成された`PointGet`演算子を使用して実行計画をプラン キャッシュがキャッシュできるかどうかを制御します。 ### `44855` v6.5.4 および v7.3.0 の新機能 {#44855-new-in-v654-and-v730} -- デフォルト値: `OFF` -- 可能`OFF`値: `ON` -- 一部のシナリオでは、 `IndexJoin`演算子の`Probe`側に`Selection`演算子が含まれている場合、TiDB は行数を`IndexScan`と大幅に過大評価します。その結果、 `IndexJoin`ではなく、最適ではないクエリプランが選択される場合があります。 -- この問題を軽減するために、TiDB では改善が導入されました。ただし、クエリプランのフォールバックによる潜在的なリスクがあるため、この改善はデフォルトで無効になっています。 -- この変数は、前述の改善を有効にするかどうかを制御します。 +- デフォルト値: `OFF` +- 可能`OFF`値: `ON` +- 一部のシナリオでは、 `IndexJoin`演算子の`Probe`側に`Selection`演算子が含まれている場合、TiDB は行数を`IndexScan`と大幅に過大評価します。その結果、 `IndexJoin`ではなく、最適ではないクエリプランが選択される場合があります。 +- この問題を軽減するために、TiDB では改善が導入されました。ただし、クエリプランのフォールバックによる潜在的なリスクがあるため、この改善はデフォルトで無効になっています。 +- この変数は、前述の改善を有効にするかどうかを制御します。 ### `45132`バージョン7.4.0の新機能 {#45132-new-in-v740} -- デフォルト値: `1000` -- 可能な値: `[0, 2147483647]` -- この変数は、オプティマイザがアクセスパスを選択する際のヒューリスティック戦略の閾値を設定します。あるアクセスパスの推定行数（例えば`Index_A` ）が他のアクセスパスの推定行数（デフォルトでは`1000`倍）よりも大幅に少ない場合、オプティマイザはコスト比較をスキップし、直接`Index_A`選択します。 -- `0` 、このヒューリスティック戦略を無効にすることを意味します。 +- デフォルト値: `1000` +- 可能な値: `[0, 2147483647]` +- この変数は、オプティマイザがアクセスパスを選択する際のヒューリスティック戦略の閾値を設定します。あるアクセスパスの推定行数（例えば`Index_A` ）が他のアクセスパスの推定行数（デフォルトでは`1000`倍）よりも大幅に少ない場合、オプティマイザはコスト比較をスキップし、直接`Index_A`選択します。 +- `0` 、このヒューリスティック戦略を無効にすることを意味します。 ### `45798`バージョン7.5.0の新機能 {#45798-new-in-v750} -- デフォルト値: `ON` -- 可能`OFF`値: `ON` -- この変数は、プラン キャッシュが[生成列](/generated-columns.md)にアクセスする実行計画をキャッシュできるかどうかを制御します。 +- デフォルト値: `ON` +- 可能`OFF`値: `ON` +- この変数は、プラン キャッシュが[生成列](/generated-columns.md)にアクセスする実行計画をキャッシュできるかどうかを制御します。 ### `46177` v6.5.6、v7.1.3、v7.5.0 の新機能 {#46177-new-in-v656-v713-and-v750} -- デフォルト値: `ON` 。v8.5.0 より前では、デフォルト値は`OFF`です。 -- 可能`OFF`値: `ON` -- この変数は、強制されていないプランを見つけた後、クエリの最適化中にオプティマイザーが強制されているプランを探索するかどうかを制御します。 +- デフォルト値: `ON` 。v8.5.0 より前では、デフォルト値は`OFF`です。 +- 可能`OFF`値: `ON` +- この変数は、強制されていないプランを見つけた後、クエリの最適化中にオプティマイザーが強制されているプランを探索するかどうかを制御します。 ### `47400`バージョン8.4.0の新機能 {#47400-new-in-v840} -- デフォルト値: `ON` -- 可能`OFF`値: `ON` -- クエリプランの各プランステップで適切な行数を正確に推定することは困難であるため、オプティマイザは`estRows`小さく推定する場合があります。この変数は、最小値`estRows`を制限するかどうかを制御します。 -- `ON` : 最小値`estRows`を 1 に制限します。これは、v8.4.0 で導入された新しい動作であり、Oracle や Db2 などの他のデータベースと一致しています。 -- `OFF` : 最小行数推定制限を無効にします。これにより、v8.4.0 より前のバージョンとの動作の一貫性が維持されます。この場合、 `estRows` 0 になる可能性があります。 +- デフォルト値: `ON` +- 可能`OFF`値: `ON` +- クエリプランの各プランステップで適切な行数を正確に推定することは困難であるため、オプティマイザは`estRows`小さく推定する場合があります。この変数は、最小値`estRows`を制限するかどうかを制御します。 +- `ON` : 最小値`estRows`を 1 に制限します。これは、v8.4.0 で導入された新しい動作であり、Oracle や Db2 などの他のデータベースと一致しています。 +- `OFF` : 最小行数推定制限を無効にします。これにより、v8.4.0 より前のバージョンとの動作の一貫性が維持されます。この場合、 `estRows` 0 になる可能性があります。 ### `52592`バージョン8.4.0の新機能 {#52592-new-in-v840} -- デフォルト値: `OFF` -- 可能`OFF`値: `ON` -- この変数は、クエリ実行時に演算子`Point Get`と`Batch Point Get`を無効にするかどうかを制御します。デフォルト値`OFF`は、演算子`Point Get`と`Batch Point Get`をクエリ実行に使用できることを意味します。`ON`に設定すると、オプティマイザは演算子`Point Get`と`Batch Point Get`を無効にし、クエリ実行にコプロセッサーを強制的に選択します。 -- `Point Get`と`Batch Point Get`列投影をサポートしていません（つまり、列のサブセットのみを返すことはできません）。そのため、シナリオによっては、実行効率がコプロセッサーよりも低くなる可能性があります。この変数を`ON`に設定すると、クエリのパフォーマンスが向上します。この変数を`ON`に設定する推奨シナリオは次のとおりです。 +- デフォルト値: `OFF` +- 可能`OFF`値: `ON` +- この変数は、クエリ実行時に演算子`Point Get`と`Batch Point Get`を無効にするかどうかを制御します。デフォルト値`OFF`は、演算子`Point Get`と`Batch Point Get`をクエリ実行に使用できることを意味します。`ON`に設定すると、オプティマイザは演算子`Point Get`と`Batch Point Get`を無効にし、クエリ実行にコプロセッサーを強制的に選択します。 +- `Point Get`と`Batch Point Get`列投影をサポートしていません（つまり、列のサブセットのみを返すことはできません）。そのため、シナリオによっては、実行効率がコプロセッサーよりも低くなる可能性があります。この変数を`ON`に設定すると、クエリのパフォーマンスが向上します。この変数を`ON`に設定する推奨シナリオは次のとおりです。 - - 多数の列を持つ幅の広いテーブルで、少数の列のみがクエリされます。 - - 大きな JSON 値を持つテーブルで、JSON 列がクエリされないか、JSON 列の小さな部分のみがクエリされます。 + - 多数の列を持つ幅の広いテーブルで、少数の列のみがクエリされます。 + - 大きな JSON 値を持つテーブルで、JSON 列がクエリされないか、JSON 列の小さな部分のみがクエリされます。 ### `52869`バージョン8.1.0の新機能 {#52869-new-in-v810} -- デフォルト値: `ON`。v8.5.7 より前では、デフォルト値は `OFF` です。 -- 可能`OFF`値: `ON` -- この修正制御が `OFF` に設定されている場合、オプティマイザがクエリ プランに対して単一インデックス スキャン方式 (フル テーブル スキャン以外) を選択できるとき、オプティマイザはインデックス マージを自動的に選択しません。詳細については、[インデックスマージを使用したステートメントの説明](/explain-index-merge.md#examples) の**Note**を参照してください。 -- この修正制御が `ON` に設定されている場合、前述の制限は解除され、オプティマイザはより多くのクエリでインデックス マージを自動的に選択できます。ただし、コスト見積もりの不正確さなどの要因により、オプティマイザが本来最適な実行計画を見逃す可能性があります。 +- デフォルト値: `ON`。v8.5.7 より前では、デフォルト値は `OFF` です。 +- 可能`OFF`値: `ON` +- この修正制御が `OFF` に設定されている場合、オプティマイザがクエリ プランに対して単一インデックス スキャン方式 (フル テーブル スキャン以外) を選択できるとき、オプティマイザはインデックス マージを自動的に選択しません。詳細については、[インデックスマージを使用したステートメントの説明](/explain-index-merge.md#examples) の**Note**を参照してください。 +- この修正制御が `ON` に設定されている場合、前述の制限は解除され、オプティマイザはより多くのクエリでインデックス マージを自動的に選択できます。ただし、コスト見積もりの不正確さなどの要因により、オプティマイザが本来最適な実行計画を見逃す可能性があります。 ### `54337`バージョン8.3.0の新機能 {#54337-new-in-v830} -- デフォルト値: `OFF` -- 可能`OFF`値: `ON` -- 現在、TiDBオプティマイザは、各接続詞が範囲のリストで構成される複雑な接続詞条件のインデックス範囲の導出に制限があります。これは、一般的な範囲交差を適用することで解決できます。 -- この修正コントロールを有効にすると、この制限が解除され、オプティマイザーは複雑な範囲交差を処理できるようになります。ただし、接続詞の数が多い（10個を超える）条件の場合、最適化時間がわずかに長くなる可能性があります。 +- デフォルト値: `OFF` +- 可能`OFF`値: `ON` +- 現在、TiDBオプティマイザは、各接続詞が範囲のリストで構成される複雑な接続詞条件のインデックス範囲の導出に制限があります。これは、一般的な範囲交差を適用することで解決できます。 +- この修正コントロールを有効にすると、この制限が解除され、オプティマイザーは複雑な範囲交差を処理できるようになります。ただし、接続詞の数が多い（10個を超える）条件の場合、最適化時間がわずかに長くなる可能性があります。 ### `56318` {#56318} @@ -121,6 +121,6 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; > > これは[TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)のみ利用可能です。 -- デフォルト値: `ON` -- 可能`OFF`値: `ON` -- この変数は`ORDER BY`ステートメントで使用される重い式を 2 回計算することを回避するかどうかを制御します。 +- デフォルト値: `ON` +- 可能`OFF`値: `ON` +- この変数は`ORDER BY`ステートメントで使用される重い式を 2 回計算することを回避するかどうかを制御します。 diff --git a/optimizer-hints.md b/optimizer-hints.md index 9909ed8a5dd1b..5847cb7f2f462 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -51,8 +51,8 @@ SELECT /*+ HASH_JOIN(@sel_1 t1@sel_1, t3) */ * FROM (SELECT t1.a, t1.b FROM t t1 上で説明したように、ヒント内のクエリ ブロックの名前は次の方法で指定できます。 -- ヒントの最初のパラメータとしてクエリブロック名を設定し、他のパラメータとはスペースで区切ってください。このセクションにリストされているすべてのヒントには、 `QB_NAME`に加えて、オプションの隠しパラメータ`@QB_NAME`も存在します。このパラメータを使用することで、ヒントの有効範囲を指定できます。 -- パラメータ内のテーブル名に`@QB_NAME`を追加して、このテーブルがどのクエリ ブロックに属するかを明示的に指定します。 +- ヒントの最初のパラメータとしてクエリブロック名を設定し、他のパラメータとはスペースで区切ってください。このセクションにリストされているすべてのヒントには、 `QB_NAME`に加えて、オプションの隠しパラメータ`@QB_NAME`も存在します。このパラメータを使用することで、ヒントの有効範囲を指定できます。 +- パラメータ内のテーブル名に`@QB_NAME`を追加して、このテーブルがどのクエリ ブロックに属するかを明示的に指定します。 > **Note:** > @@ -236,8 +236,8 @@ SELECT /*+ SHUFFLE_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; > **Note:** > -> - このヒントを使用する前に、現在のTiDBクラスタがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 -> - このヒントは、 [`HASH_JOIN_BUILD`ヒント](#hash_join_buildt1_name--tl_name-)および[`HASH_JOIN_PROBE`ヒント](#hash_join_probet1_name--tl_name-)と組み合わせて使用して、シャッフル結合アルゴリズムのビルド側とプローブ側を制御できます。 +> - このヒントを使用する前に、現在のTiDBクラスタがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 +> - このヒントは、 [`HASH_JOIN_BUILD`ヒント](#hash_join_buildt1_name--tl_name-)および[`HASH_JOIN_PROBE`ヒント](#hash_join_probet1_name--tl_name-)と組み合わせて使用して、シャッフル結合アルゴリズムのビルド側とプローブ側を制御できます。 ### BROADCAST_JOIN(t1_name [, tl_name ...]) {#broadcast_joint1_name--tl_name-} @@ -249,8 +249,8 @@ SELECT /*+ BROADCAST_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; > **Note:** > -> - このヒントを使用する前に、現在のTiDBクラスタがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 -> - このヒントは、 [`HASH_JOIN_BUILD`ヒント](#hash_join_buildt1_name--tl_name-)および[`HASH_JOIN_PROBE`ヒント](#hash_join_probet1_name--tl_name-)と組み合わせて使用して、ブロードキャスト結合アルゴリズムのビルド側とプローブ側を制御できます。 +> - このヒントを使用する前に、現在のTiDBクラスタがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 +> - このヒントは、 [`HASH_JOIN_BUILD`ヒント](#hash_join_buildt1_name--tl_name-)および[`HASH_JOIN_PROBE`ヒント](#hash_join_probet1_name--tl_name-)と組み合わせて使用して、ブロードキャスト結合アルゴリズムのビルド側とプローブ側を制御できます。 ### NO_DECORRELATE() {#no_decorrelate} @@ -417,8 +417,8 @@ EXPLAIN SELECT /*+ ORDER_INDEX(t, a) */ a FROM t ORDER BY a LIMIT 10; > **Note:** > -> - クエリ自体がインデックスを順番に読み取る必要がない場合（つまり、ヒントがない場合、オプティマイザはいかなる状況でもインデックスを順番に読み取るプランを生成しません）、ヒント`ORDER_INDEX`を使用するとエラー`Can't find a proper physical plan for this query`が発生します。この場合、対応するヒント`ORDER_INDEX`を削除する必要があります。 -> - パーティションテーブルのインデックスは順番に読み取ることができないため、パーティションテーブルとその関連インデックスでは`ORDER_INDEX`ヒントを使用しないでください。 +> - クエリ自体がインデックスを順番に読み取る必要がない場合（つまり、ヒントがない場合、オプティマイザはいかなる状況でもインデックスを順番に読み取るプランを生成しません）、ヒント`ORDER_INDEX`を使用するとエラー`Can't find a proper physical plan for this query`が発生します。この場合、対応するヒント`ORDER_INDEX`を削除する必要があります。 +> - パーティションテーブルのインデックスは順番に読み取ることができないため、パーティションテーブルとその関連インデックスでは`ORDER_INDEX`ヒントを使用しないでください。 ### NO_ORDER_INDEX(t1_name, idx1_name [, idx2_name ...]) {#no_order_indext1_name-idx1_name--idx2_name-} @@ -471,15 +471,15 @@ EXPLAIN SELECT /*+ INDEX_LOOKUP_PUSHDOWN(t1, a) */ a, b FROM t1; `INDEX_LOOKUP_PUSHDOWN`ヒントには現在次の制限があります。 -- キャッシュされたテーブルと一時テーブルはサポートされていません。 -- [グローバルインデックス](/global-indexes.md)を使用したクエリはサポートされていません。 -- [多値インデックス](/choose-index.md#use-multi-valued-indexes)を使用したクエリはサポートされていません。 -- `REPEATABLE-READ`以外の分離レベルはサポートされていません。 -- [Follower Read](/follower-read.md)はサポートされていません。 -- [ステイル読み取り](/stale-read.md)と[`tidb_snapshot`を使用して履歴データを読み取る](/read-historical-data.md)はサポートされていません。 -- プッシュダウンされた`LocalIndexLookUp`演算子は`keep order`をサポートしていません。実行計画にインデックス列に基づく`ORDER BY`が含まれている場合、クエリは通常の`IndexLookUp`にフォールバックします。 -- プッシュダウンされた`LocalIndexLookUp`演算子は、ページング モードでのコプロセッサー要求の送信をサポートしていません。 -- プッシュダウンされた`LocalIndexLookUp`演算子は[コプロセッサーキャッシュ](/coprocessor-cache.md)をサポートしません。 +- キャッシュされたテーブルと一時テーブルはサポートされていません。 +- [グローバルインデックス](/global-indexes.md)を使用したクエリはサポートされていません。 +- [多値インデックス](/choose-index.md#use-multi-valued-indexes)を使用したクエリはサポートされていません。 +- `REPEATABLE-READ`以外の分離レベルはサポートされていません。 +- [Follower Read](/follower-read.md)はサポートされていません。 +- [ステイル読み取り](/stale-read.md)と[`tidb_snapshot`を使用して履歴データを読み取る](/read-historical-data.md)はサポートされていません。 +- プッシュダウンされた`LocalIndexLookUp`演算子は`keep order`をサポートしていません。実行計画にインデックス列に基づく`ORDER BY`が含まれている場合、クエリは通常の`IndexLookUp`にフォールバックします。 +- プッシュダウンされた`LocalIndexLookUp`演算子は、ページング モードでのコプロセッサー要求の送信をサポートしていません。 +- プッシュダウンされた`LocalIndexLookUp`演算子は[コプロセッサーキャッシュ](/coprocessor-cache.md)をサポートしません。 ### NO_INDEX_LOOKUP_PUSHDOWN(t1_name)バージョン8.5.5の新機能 {#no_index_lookup_pushdownt1_name-new-in-v855} @@ -552,12 +552,12 @@ SELECT /*+ LEADING(t1, t2) */ * FROM t1, t2, t3 WHERE t1.id = t2.id and t2.id = `LEADING`ヒントは次の状況では有効になりません。 -- `LEADING`ヒントが複数指定されています。 -- `LEADING`ヒントで指定されたテーブル名が存在しません。 -- `LEADING`ヒントに重複したテーブル名が指定されています。 -- オプティマイザーは、ヒント`LEADING`で指定された順序に従って結合操作を実行できません。 -- `straight_join()`ヒントがすでに存在します。 -- クエリには、外部結合とデカルト積が含まれています。 +- `LEADING`ヒントが複数指定されています。 +- `LEADING`ヒントで指定されたテーブル名が存在しません。 +- `LEADING`ヒントに重複したテーブル名が指定されています。 +- オプティマイザーは、ヒント`LEADING`で指定された順序に従って結合操作を実行できません。 +- `straight_join()`ヒントがすでに存在します。 +- クエリには、外部結合とデカルト積が含まれています。 上記の状況では、警告が生成されます。 @@ -597,8 +597,8 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * > > `MERGE()`は単純な CTE クエリにのみ適用されます。以下の状況には適用されません。 > -> - [再帰CTE](https://docs.pingcap.com/tidb/stable/dev-guide-use-common-table-expression#recursive-cte) -> - 集計演算子、ウィンドウ関数、 `DISTINCT`など、展開できないインラインを含むサブクエリ。 +> - [再帰CTE](https://docs.pingcap.com/tidb/stable/dev-guide-use-common-table-expression#recursive-cte) +> - 集計演算子、ウィンドウ関数、 `DISTINCT`など、展開できないインラインを含むサブクエリ。 > > CTE 参照の数が多すぎると、クエリのパフォーマンスがデフォルトのマテリアライゼーション動作よりも低下する可能性があります。 @@ -614,7 +614,7 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * > > `@QueryBlockName`と直後の`.ViewName@QueryBlockName`の間には空白があります。そうでない場合、 `.ViewName@QueryBlockName`は`QueryBlockName`の一部として扱われます。例えば、 `QB_NAME(v2_1, v2@SEL_1 .@SEL_1)`は有効ですが、 `QB_NAME(v2_1, v2@SEL_1.@SEL_1)`は正しく解析できません。 -- 単一のビューとサブクエリのない単純なステートメントの場合、次の例では、ビュー`v`の最初のクエリ ブロック名を指定します。 +- 単一のビューとサブクエリのない単純なステートメントの場合、次の例では、ビュー`v`の最初のクエリ ブロック名を指定します。 ```sql SELECT /* Comment: The name of the current query block is the default @SEL_1 */ * FROM v; @@ -629,7 +629,7 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * SELECT /*+ QB_NAME(v_1, v) USE_INDEX(t@v_1, idx) */ * FROM v; ``` -- ネストされたビューとサブクエリを含む複雑なステートメントの場合、次の例では、ビュー`v1`と`v2`の 2 つのクエリ ブロックのそれぞれの名前を指定します。 +- ネストされたビューとサブクエリを含む複雑なステートメントの場合、次の例では、ビュー`v1`と`v2`の 2 つのクエリ ブロックのそれぞれの名前を指定します。 ```sql SELECT /* Comment: The name of the current query block is the default @SEL_1 */ * FROM v2 JOIN ( @@ -659,43 +659,43 @@ WITH CTE1 AS (SELECT * FROM t1), CTE2 AS (WITH CTE3 AS (SELECT /*+ MERGE() */ * > **Note:** > -> - ビューでグローバルヒントを使用するには、対応する`QB_NAME`ヒントをビューに定義する必要があります。そうしないと、グローバルヒントは有効になりません。 +> - ビューでグローバルヒントを使用するには、対応する`QB_NAME`ヒントをビューに定義する必要があります。そうしないと、グローバルヒントは有効になりません。 > -> - ヒントを使用してビュー内の複数のテーブル名を指定する場合、同じヒントに表示されるテーブル名が同じビューの同じクエリ ブロック内にあることを確認する必要があります。 +> - ヒントを使用してビュー内の複数のテーブル名を指定する場合、同じヒントに表示されるテーブル名が同じビューの同じクエリ ブロック内にあることを確認する必要があります。 > -> - 最も外側のクエリ ブロックのビューで`QB_NAME`ヒントを定義すると、次のようになります。 +> - 最も外側のクエリ ブロックのビューで`QB_NAME`ヒントを定義すると、次のようになります。 > -> - `QB_NAME`のビューリストの最初の項目において、 `@SEL_`が明示的に宣言されていない場合、デフォルトは`QB_NAME`が定義されているクエリブロックの位置と一致します。つまり、クエリ`SELECT /*+ QB_NAME(qb1, v2) */ * FROM v2 JOIN (SELECT /*+ QB_NAME(qb2, v2) */ * FROM v2) vv;`は`SELECT /*+ QB_NAME(qb1, v2@SEL_1) */ * FROM v2 JOIN (SELECT /*+ QB_NAME(qb2, v2@SEL_2) */ * FROM v2) vv;`と同等です。 -> - `QB_NAME`ビューリストの最初の項目以外の項目については、 `@SEL_1`のみを省略できます。つまり、現在のビューの最初のクエリブロックで`@SEL_1`が宣言されている場合、 `@SEL_1`を省略できます。それ以外の場合、 `@SEL_`は省略できません。上記の例の場合： +> - `QB_NAME`のビューリストの最初の項目において、 `@SEL_`が明示的に宣言されていない場合、デフォルトは`QB_NAME`が定義されているクエリブロックの位置と一致します。つまり、クエリ`SELECT /*+ QB_NAME(qb1, v2) */ * FROM v2 JOIN (SELECT /*+ QB_NAME(qb2, v2) */ * FROM v2) vv;`は`SELECT /*+ QB_NAME(qb1, v2@SEL_1) */ * FROM v2 JOIN (SELECT /*+ QB_NAME(qb2, v2@SEL_2) */ * FROM v2) vv;`と同等です。 +> - `QB_NAME`ビューリストの最初の項目以外の項目については、 `@SEL_1`のみを省略できます。つまり、現在のビューの最初のクエリブロックで`@SEL_1`が宣言されている場合、 `@SEL_1`を省略できます。それ以外の場合、 `@SEL_`は省略できません。上記の例の場合： > -> - ビュー`v2`の最初のクエリ ブロックは`QB_NAME(v2_1, v2)`として宣言できます。 -> - ビュー`v2`の 2 番目のクエリ ブロックは`QB_NAME(v2_2, v2.@SEL_2)`として宣言できます。 -> - ビュー`v1`の最初のクエリ ブロックは`QB_NAME(v1_1, v2.v1@SEL_2)`として宣言できます。 -> - ビュー`v1`の 2 番目のクエリ ブロックは`QB_NAME(v1_2, v2.v1@SEL_2 .@SEL_2)`として宣言できます。 +> - ビュー`v2`の最初のクエリ ブロックは`QB_NAME(v2_1, v2)`として宣言できます。 +> - ビュー`v2`の 2 番目のクエリ ブロックは`QB_NAME(v2_2, v2.@SEL_2)`として宣言できます。 +> - ビュー`v1`の最初のクエリ ブロックは`QB_NAME(v1_1, v2.v1@SEL_2)`として宣言できます。 +> - ビュー`v1`の 2 番目のクエリ ブロックは`QB_NAME(v1_2, v2.v1@SEL_2 .@SEL_2)`として宣言できます。 ### ステップ2: ターゲットヒントを追加する {#step-2-add-the-target-hints} ビューのクエリブロックに`QB_NAME`ヒントを定義した後、ビュー内で有効にするために、必要な[クエリブロックで有効になるヒント](#hints-that-take-effect-in-query-blocks)ヒントを`ViewName@QueryBlockName`の形式で追加できます。例： -- ビュー`v2`の最初のクエリ ブロックに`MERGE_JOIN()`ヒントを指定します。 +- ビュー`v2`の最初のクエリ ブロックに`MERGE_JOIN()`ヒントを指定します。 ```sql SELECT /*+ QB_NAME(v2_1, v2) merge_join(t@v2_1) */ * FROM v2; ``` -- ビュー`v2`の 2 番目のクエリ ブロックにヒント`MERGE_JOIN()`と`STREAM_AGG()`を指定します。 +- ビュー`v2`の 2 番目のクエリ ブロックにヒント`MERGE_JOIN()`と`STREAM_AGG()`を指定します。 ```sql SELECT /*+ QB_NAME(v2_2, v2.@SEL_2) merge_join(t1@v2_2) stream_agg(@v2_2) */ * FROM v2; ``` -- ビュー`v1`の最初のクエリ ブロックに`HASH_JOIN()`ヒントを指定します。 +- ビュー`v1`の最初のクエリ ブロックに`HASH_JOIN()`ヒントを指定します。 ```sql SELECT /*+ QB_NAME(v1_1, v2.v1@SEL_2) hash_join(t@v1_1) */ * FROM v2; ``` -- ビュー`v1`の 2 番目のクエリ ブロックにヒント`HASH_JOIN()`と`HASH_AGG()`を指定します。 +- ビュー`v1`の 2 番目のクエリ ブロックにヒント`HASH_JOIN()`と`HASH_AGG()`を指定します。 ```sql SELECT /*+ QB_NAME(v1_2, v2.v1@SEL_2 .@SEL_2) hash_join(t1@v1_2) hash_agg(@v1_2) */ * FROM v2; @@ -723,8 +723,8 @@ select /*+ NO_INDEX_MERGE() */ * from t where t.a > 0 or t.b > 0; > **Note:** > -> - `NO_INDEX_MERGE`は`USE_INDEX_MERGE`よりも優先度が高くなります。両方のヒントが使用されている場合、 `USE_INDEX_MERGE`は効果がありません。 -> - サブクエリの場合、 `NO_INDEX_MERGE`サブクエリの最も外側のレベルに配置された場合にのみ有効になります。 +> - `NO_INDEX_MERGE`は`USE_INDEX_MERGE`よりも優先度が高くなります。両方のヒントが使用されている場合、 `USE_INDEX_MERGE`は効果がありません。 +> - サブクエリの場合、 `NO_INDEX_MERGE`サブクエリの最も外側のレベルに配置された場合にのみ有効になります。 ### USE_TOJA(boolean_value) {#use_tojaboolean_value} @@ -788,8 +788,8 @@ prepare stmt from 'select /*+ IGNORE_PLAN_CACHE() */ * from t where t.id = ?'; > **Warning:** > -> - 予期しない動作が発生する可能性があるため、明示的にサポートされていない変数を変更しないことを強くお勧めします。 -> - サブクエリに`SET_VAR`を記述しないでください。記述すると、効果が得られない可能性があります。詳細については、 [`SET_VAR`サブクエリに記述すると効果を発揮しません](#set_var-does-not-take-effect-when-written-in-subqueries)を参照してください。 +> - 予期しない動作が発生する可能性があるため、明示的にサポートされていない変数を変更しないことを強くお勧めします。 +> - サブクエリに`SET_VAR`を記述しないでください。記述すると、効果が得られない可能性があります。詳細については、 [`SET_VAR`サブクエリに記述すると効果を発揮しません](#set_var-does-not-take-effect-when-written-in-subqueries)を参照してください。 次に例を示します。 @@ -825,8 +825,8 @@ SELECT /*+ STRAIGHT_JOIN() */ * FROM t t1, t t2 WHERE t1.a = t2.a; > **Note:** > -> - `STRAIGHT_JOIN`は`LEADING`よりも優先度が高くなります。両方のヒントが使用されている場合、 `LEADING`は効果がありません。 -> - `STRAIGHT_JOIN`ヒントよりも一般的な`LEADING`ヒントを使用することをお勧めします。 +> - `STRAIGHT_JOIN`は`LEADING`よりも優先度が高くなります。両方のヒントが使用されている場合、 `LEADING`は効果がありません。 +> - `STRAIGHT_JOIN`ヒントよりも一般的な`LEADING`ヒントを使用することをお勧めします。 ### NTH_PLAN(N) {#nth_plann} @@ -1086,8 +1086,8 @@ EXPLAIN SELECT /*+ leading(t1, t3), inl_join(t3) */ * FROM t1, t2, t3 WHERE t1.i `Can't find a proper physical plan for this query`エラーは次のシナリオで発生する可能性があります。 -- クエリ自体はインデックスを順番に読み取る必要はありません。つまり、このクエリでは、ヒントを使用しない限り、オプティマイザはインデックスを順番に読み取るプランを生成しません。この場合、ヒント`ORDER_INDEX`が指定されていると、このエラーが発生します。この問題を解決するには、対応するヒント`ORDER_INDEX`を削除してください。 -- クエリは、 `NO_JOIN`に関連するヒントを使用して、可能なすべての結合方法を除外します。 +- クエリ自体はインデックスを順番に読み取る必要はありません。つまり、このクエリでは、ヒントを使用しない限り、オプティマイザはインデックスを順番に読み取るプランを生成しません。この場合、ヒント`ORDER_INDEX`が指定されていると、このエラーが発生します。この問題を解決するには、対応するヒント`ORDER_INDEX`を削除してください。 +- クエリは、 `NO_JOIN`に関連するヒントを使用して、可能なすべての結合方法を除外します。 ```sql CREATE TABLE t1 (a INT); @@ -1096,7 +1096,7 @@ EXPLAIN SELECT /*+ NO_HASH_JOIN(t1), NO_MERGE_JOIN(t1) */ * FROM t1, t2 WHERE t1 ERROR 1815 (HY000): Internal : Can't find a proper physical plan for this query ``` -- システム変数[`tidb_opt_enable_hash_join`](/system-variables.md#tidb_opt_enable_hash_join-new-in-v656-v712-and-v740)は`OFF`に設定され、他のすべての結合タイプも除外されます。 +- システム変数[`tidb_opt_enable_hash_join`](/system-variables.md#tidb_opt_enable_hash_join-new-in-v656-v712-and-v740)は`OFF`に設定され、他のすべての結合タイプも除外されます。 ```sql CREATE TABLE t1 (a INT); diff --git a/oracle-functions-to-tidb.md b/oracle-functions-to-tidb.md index 3401eacf621e8..ebf21e6a3f4c7 100644 --- a/oracle-functions-to-tidb.md +++ b/oracle-functions-to-tidb.md @@ -146,19 +146,19 @@ SELECT * FROM tables LIMIT 2000 OFFSET 0 Oracle では、次の場合に`NULL`値が`ORDER BY`句によってソートされます。 -- `ORDER BY column ASC`ステートメントでは、最後に`NULL`値が返されます。 +- `ORDER BY column ASC`ステートメントでは、最後に`NULL`値が返されます。 -- `ORDER BY column DESC`ステートメントでは、最初に`NULL`値が返されます。 +- `ORDER BY column DESC`ステートメントでは、最初に`NULL`値が返されます。 -- `ORDER BY column [ASC|DESC] NULLS FIRST`文では、 `NULL`値が非NULL値の前に返されます。非NULL値は、 `ASC|DESC`で指定された昇順または降順で返されます。 +- `ORDER BY column [ASC|DESC] NULLS FIRST`文では、 `NULL`値が非NULL値の前に返されます。非NULL値は、 `ASC|DESC`で指定された昇順または降順で返されます。 -- `ORDER BY column [ASC|DESC] NULLS LAST`文では、非 NULL 値の後に`NULL`値が返されます。非 NULL 値は、 `ASC|DESC`で指定された昇順または降順で返されます。 +- `ORDER BY column [ASC|DESC] NULLS LAST`文では、非 NULL 値の後に`NULL`値が返されます。非 NULL 値は、 `ASC|DESC`で指定された昇順または降順で返されます。 TiDB では、次の場合に`NULL`値が`ORDER BY`句によってソートされます。 -- `ORDER BY column ASC`ステートメントでは、最初に`NULL`値が返されます。 +- `ORDER BY column ASC`ステートメントでは、最初に`NULL`値が返されます。 -- `ORDER BY column DESC`ステートメントでは、最後に`NULL`値が返されます。 +- `ORDER BY column DESC`ステートメントでは、最後に`NULL`値が返されます。 次の表は、Oracle と TiDB の同等の`ORDER BY`ステートメントの例を示しています。 diff --git a/overview.md b/overview.md index faae89858befc..9c4512aab3ac4 100644 --- a/overview.md +++ b/overview.md @@ -23,50 +23,50 @@ TiDB Self-Managedは、TiDBの製品オプションの一つであり、ユー ## 主な機能 {#key-features} -- **水平方向のスケーリングが容易** +- **水平方向のスケーリングが容易** TiDBのアーキテクチャ設計では、コンピューティングとストレージが分離されているため、必要に応じてコンピューティングまたはストレージ容量をオンラインでスケールアウトまたはスケールインできます。このスケーリングプロセスは、アプリケーションの運用および保守担当者にとって透過的です。 -- **金融グレードの高可用性** +- **金融グレードの高可用性** データは複数のレプリカに保存され、トランザクションログの取得にはMulti-Raftプロトコルが使用されます。トランザクションは、データが過半数のレプリカに正常に書き込まれた場合にのみコミットされます。これにより、レプリカの一部がダウンした場合でも、高い一貫性と可用性が保証されます。必要に応じて、地理的な場所とレプリカの数を設定することで、さまざまな耐障害性レベルに対応できます。 -- **リアルタイムHTAP** +- **リアルタイムHTAP** TiDBは、行ベースストレージエンジンである[TiKV](/tikv-overview.md)と、カラム型ストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)という2つのストレージエンジンを提供します。TiFlashは、Multi-Raft Learnerプロトコルを使用してTiKVからリアルタイムでデータを複製し、TiKV行ベースストレージエンジンとTiFlashカラム型ストレージエンジン間のデータの一貫性を確保します。HTAPリソースの分離問題を解決するために、必要に応じてTiKVとTiFlashを異なるマシンにデプロイできます。 -- **クラウドネイティブ分散データベース** +- **クラウドネイティブ分散データベース** TiDB はクラウド向けに設計された分散データベースで、クラウド プラットフォーム上で柔軟なスケーラビリティ、信頼性、セキュリティを提供します。ユーザーは、変化するワークロードの要件に合わせて TiDB を柔軟に拡張できます。TiDB では、各データに少なくとも 3 つのレプリカがあり、異なるクラウド可用性ゾーンにスケジュールすることで、データ センター全体の停止にも対応できます。TiDB [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable/tidb-operator-overview) Kubernetes 上での TiDB の管理を支援し、TiDB クラスターの運用に関連するタスクを自動化することで、マネージド Kubernetes を提供するあらゆるクラウドへの TiDB のデプロイを容易にします。フル マネージド TiDB サービスである[TiDB Cloud](https://pingcap.com/tidb-cloud/) 、[クラウド上のTiDB](https://docs.pingcap.com/tidbcloud/)の真の力を引き出す最も簡単で経済的かつ堅牢な方法であり、数回のクリックだけで TiDB クラスターをデプロイして実行できます。 -- **MySQLプロトコルおよびMySQLエコシステムと互換性があります。** +- **MySQLプロトコルおよびMySQLエコシステムと互換性があります。** TiDBはMySQLプロトコル、MySQLの共通機能、およびMySQLエコシステムと互換性があります。アプリケーションをTiDBに移行する場合、多くの場合、コードを1行も変更する必要はないか、ごくわずかなコードの変更だけで済みます。さらに、TiDBはデータをTiDBに簡単に移行するための一連の[データ移行ツール](/ecosystem-tool-user-guide.md)を提供します。 ## ユースケース {#use-cases} -- **金融業界のシナリオ** +- **金融業界のシナリオ** TiDBは、データの一貫性、信頼性、可用性、拡張性、耐障害性に対する要求が高い金融業界のシナリオに最適です。従来のソリューションは、コストが高く非効率的で、リソース利用率が低く、メンテナンスコストが高額でした。TiDBは、複数のレプリカとMulti-Raftプロトコルを使用して、データを異なるデータセンター、ラック、マシンにスケジュールすることで、システムのRTO 30秒以下、RPO=0を実現します。 -- **大規模データと高並行処理のシナリオ** +- **大規模データと高並行処理のシナリオ** 従来のスタンドアロン型データベースでは、急速に成長するアプリケーションのデータ容量要件を満たすことができません。TiDBは、コンピューティングとストレージを分離したアーキテクチャを採用したコスト効率の高いソリューションであり、コンピューティング容量とストレージ容量を個別に容易に拡張できます。コンピューティングレイヤーは最大512ノードをサポートし、各ノードは最大1,000の同時実行をサポートし、クラスタの最大容量はペタバイト（PB）レベルです。 -- **リアルタイムHTAPシナリオ** +- **リアルタイムHTAPシナリオ** TiDBは、リアルタイム処理を必要とする膨大なデータ量と高い同時実行性を伴うシナリオに最適です。TiDBはバージョン4.0で、列指向ストレージエンジンTiFlashを導入しました。これは、行指向ストレージエンジンTiKVと組み合わせることで、TiDBを真のHTAPデータベースとして構築します。わずかなストレージコストを追加するだけで、オンライントランザクション処理とリアルタイムデータ分析の両方を同一システムで処理できるため、コストを大幅に削減できます。 -- **データ集約および二次処理シナリオ** +- **データ集約および二次処理シナリオ** TiDBは、分散したデータを同一システムに集約し、二次処理を実行してT+0またはT+1レポートを生成する必要がある企業に適しています。Hadoopと比較すると、TiDBははるかにシンプルです。TiDBが提供するETL（抽出、変換、ロード）ツールまたはデータ移行ツールを使用して、データをTiDBに複製できます。レポートはSQLステートメントを使用して直接生成できます。 ## 関連項目 {#see-also} -- [TiDBアーキテクチャ](/tidb-architecture.md) -- [TiDBストレージ](/tidb-storage.md) -- [TiDBコンピューティング](/tidb-computing.md) -- [TiDBスケジューリング](/tidb-scheduling.md) +- [TiDBアーキテクチャ](/tidb-architecture.md) +- [TiDBストレージ](/tidb-storage.md) +- [TiDBコンピューティング](/tidb-computing.md) +- [TiDBスケジューリング](/tidb-scheduling.md) ## 関連リソース {#related-resources} diff --git a/partition-pruning.md b/partition-pruning.md index 38f103115afe2..3f18b3c1429e3 100644 --- a/partition-pruning.md +++ b/partition-pruning.md @@ -224,9 +224,9 @@ explain select * from t where x between 7 and 14; `fn`関数が単調である場合、任意の`x`と`y`に対して、また`x > y`であれば`fn(x) > fn(y)` 。したがって、この`fn`関数は厳密に単調であると言えます。任意の`x`と`y`に対して、 `x > y`であれば`fn(x) >= fn(y)` 。この場合、 `fn` 「単調」と言えるでしょう。理論的には、厳密に単調であるかどうかにかかわらず、すべての単調関数がパーティションプルーニングによってサポートされます。現在、TiDBは次の単調関数のみをサポートしています。 -- [`UNIX_TIMESTAMP()`](/functions-and-operators/date-and-time-functions.md) -- [`TO_DAYS()`](/functions-and-operators/date-and-time-functions.md) -- [`EXTRACT(
@@ -156,11 +156,11 @@ Data Serviceの利用を開始するには、独自のデータアプリを作 WindowsまたはLinuxの場合： - - エディタにステートメントが 1 つしかない場合は、それを実行するには、 **Ctrl + Enter**キーを押すか、クリックします。 **Run**。 + - エディタにステートメントが 1 つしかない場合は、それを実行するには、 **Ctrl + Enter**キーを押すか、クリックします。 **Run**。 - - エディタに複数のステートメントがある場合、それらのステートメントを1つまたは複数順番に実行するには、カーソルを対象のステートメントの上に置くか、カーソルで対象のステートメントの行を選択し、 **Ctrl + Enter**キーを押すか、 **Run**をクリックします。 + - エディタに複数のステートメントがある場合、それらのステートメントを1つまたは複数順番に実行するには、カーソルを対象のステートメントの上に置くか、カーソルで対象のステートメントの行を選択し、 **Ctrl + Enter**キーを押すか、 **Run**をクリックします。 - - エディタ内のすべてのステートメントを順番に実行するには、 **Shift + Ctrl + Enter**キーを押すか、カーソルですべてのステートメントの行を選択して**Run**をクリックします。 + - エディタ内のすべてのステートメントを順番に実行するには、 **Shift + Ctrl + Enter**キーを押すか、カーソルですべてのステートメントの行を選択して**Run**をクリックします。
@@ -179,9 +179,9 @@ Data Serviceの利用を開始するには、独自のデータアプリを作 エンドポイントをデプロイするには、以下の手順を実行してください。 -1. エンドポイントの詳細ページで、右上隅にある**Deploy**をクリックします。 +1. エンドポイントの詳細ページで、右上隅にある**Deploy**をクリックします。 -2. デプロイを確定するには、 **Deploy**をクリックしてください。エンドポイントが正常にデプロイされると、 **Endpoint has been deployed**というメッセージが表示されます。 +2. デプロイを確定するには、 **Deploy**をクリックしてください。エンドポイントが正常にデプロイされると、 **Endpoint has been deployed**というメッセージが表示されます。 デプロイ履歴を表示するには、左側のペインでデータアプリの名前をクリックし、右側のペインで**Deployments**タブをクリックします。 @@ -191,28 +191,28 @@ HTTPSリクエストを送信することでエンドポイントを呼び出す #### 1. APIキーを作成する {#1-create-an-api-key} -1. [**Data Service**](https://tidbcloud.com/project/data-service)ページの左側のペインで、データ アプリの名前をクリックして詳細を表示します。 +1. [**Data Service**](https://tidbcloud.com/project/data-service)ページの左側のペインで、データ アプリの名前をクリックして詳細を表示します。 -2. **Authentication**エリアで、 **Create API Key**をクリックします。 +2. **Authentication**エリアで、 **Create API Key**をクリックします。 -3. **Create API Key**ダイアログボックスで、以下の操作を行います。 +3. **Create API Key**ダイアログボックスで、以下の操作を行います。 - 1. （任意）APIキーの説明を入力してください。 + 1. （任意）APIキーの説明を入力してください。 - 2. APIキーの役割を選択してください。 + 2. APIキーの役割を選択してください。 このロールは、APIキーがデータアプリにリンクされたTiDB Cloud Starterインスタンスに対してデータの読み取りまたは書き込みを行えるかどうかを制御するために使用されます。 `ReadOnly`または`ReadAndWrite`ロールを選択できます。 - - `ReadOnly` : API キーで`SELECT` 、 `SHOW` 、 `USE` 、 `DESC` 、 `EXPLAIN`ステートメントなどのデータを読み取ることのみを許可します。 - - `ReadAndWrite` : このAPIキーは、データの読み書きを可能にします。このAPIキーを使用して、DMLステートメントやDDLステートメントなど、すべてのSQLステートメントを実行できます。 + - `ReadOnly` : API キーで`SELECT` 、 `SHOW` 、 `USE` 、 `DESC` 、 `EXPLAIN`ステートメントなどのデータを読み取ることのみを許可します。 + - `ReadAndWrite` : このAPIキーは、データの読み書きを可能にします。このAPIキーを使用して、DMLステートメントやDDLステートメントなど、すべてのSQLステートメントを実行できます。 - 3. （オプション）APIキーの希望するレート制限を設定します。 + 3. （オプション）APIキーの希望するレート制限を設定します。 -4. **Next**をクリックします。公開鍵と秘密鍵が表示されます。 +4. **Next**をクリックします。公開鍵と秘密鍵が表示されます。 秘密鍵を安全な場所にコピーして保存したことを確認してください。このページを離れると、完全な秘密鍵を再度取得することはできません。 -5. **Done**をクリックしてください。 +5. **Done**をクリックしてください。 API キーの詳細については、[Data ServiceのAPIキー](/tidb-cloud/data-service-api-key.md)を参照してください。 @@ -220,9 +220,9 @@ API キーの詳細については、[Data ServiceのAPIキー](/tidb-cloud/data TiDB Cloudは、エンドポイントを呼び出すのに役立つコード例を生成します。コード例を取得するには、以下の手順を実行してください。 -1. [**Data Service**](https://tidbcloud.com/project/data-service)ページの左側のペインで、エンドポイントの名前をクリックし、右上隅の**...** > **Code Example**をクリックします。**Code Example**ダイアログボックスが表示されます。 +1. [**Data Service**](https://tidbcloud.com/project/data-service)ページの左側のペインで、エンドポイントの名前をクリックし、右上隅の**...** > **Code Example**をクリックします。**Code Example**ダイアログボックスが表示されます。 -2. ダイアログボックスで、エンドポイントを呼び出すために使用するTiDB Cloud Starterインスタンスとデータベースを選択し、コード例をコピーします。 +2. ダイアログボックスで、エンドポイントを呼び出すために使用するTiDB Cloud Starterインスタンスとデータベースを選択し、コード例をコピーします。 curlコードの例を以下に示します。 @@ -255,15 +255,15 @@ TiDB Cloudは、エンドポイントを呼び出すのに役立つコード例 > **Note:** > - > - リージョンドメイン`.data.tidbcloud.com`をリクエストすることで、 TiDB Cloud Starterインスタンスが配置されているリージョンのエンドポイントに直接アクセスできます。 - > - あるいは、リージョンを指定せずにグローバルドメイン`data.tidbcloud.com`リクエストすることもできます。この場合、 TiDB Cloud はリクエストをターゲットリージョンに内部的にリダイレクトしますが、レイテンシーが増加する可能性があります。この方法を選択する場合は、エンドポイントを呼び出す際に、curl コマンドに`--location-trusted`オプションを追加してください。 + > - リージョンドメイン`.data.tidbcloud.com`をリクエストすることで、 TiDB Cloud Starterインスタンスが配置されているリージョンのエンドポイントに直接アクセスできます。 + > - あるいは、リージョンを指定せずにグローバルドメイン`data.tidbcloud.com`リクエストすることもできます。この場合、 TiDB Cloud はリクエストをターゲットリージョンに内部的にリダイレクトしますが、レイテンシーが増加する可能性があります。この方法を選択する場合は、エンドポイントを呼び出す際に、curl コマンドに`--location-trusted`オプションを追加してください。 #### 3. コード例を使用する {#3-use-the-code-example} アプリケーションにコード例を貼り付けて実行してください。そうすれば、エンドポイントからの応答を取得できます。 -- ``と``のプレースホルダーを、ご自身の API キーに置き換える必要があります。 -- エンドポイントにパラメータが含まれている場合は、エンドポイントを呼び出す際にパラメータ値を指定してください。 +- ``と``のプレースホルダーを、ご自身の API キーに置き換える必要があります。 +- エンドポイントにパラメータが含まれている場合は、エンドポイントを呼び出す際にパラメータ値を指定してください。 エンドポイントを呼び出した後、JSON形式のレスポンスを確認できます。以下に例を示します。 @@ -307,7 +307,7 @@ TiDB Cloudは、エンドポイントを呼び出すのに役立つコード例 ## もっと詳しく知る {#learn-more} -- [Data Service概要](/tidb-cloud/data-service-overview.md) -- [Chat2Query API を使い始めよう](/tidb-cloud/use-chat2query-api.md) -- [データアプリを管理する](/tidb-cloud/data-service-manage-data-app.md) -- [エンドポイントの管理](/tidb-cloud/data-service-manage-endpoint.md) +- [Data Service概要](/tidb-cloud/data-service-overview.md) +- [Chat2Query API を使い始めよう](/tidb-cloud/use-chat2query-api.md) +- [データアプリを管理する](/tidb-cloud/data-service-manage-data-app.md) +- [エンドポイントの管理](/tidb-cloud/data-service-manage-endpoint.md) diff --git a/tidb-cloud/data-service-integrations.md b/tidb-cloud/data-service-integrations.md index d368ad148dc44..9a0ab5897e5e9 100644 --- a/tidb-cloud/data-service-integrations.md +++ b/tidb-cloud/data-service-integrations.md @@ -15,15 +15,15 @@ summary: TiDB Cloudコンソールで、 TiDB CloudデータアプリをGPTやDi データアプリをGPTと統合するには、以下の手順を実行してください。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータアプリを見つけ、対象のデータアプリの名前をクリックし、次に**Integrations**タブをクリックします。 +2. 左側のペインで、対象のデータアプリを見つけ、対象のデータアプリの名前をクリックし、次に**Integrations**タブをクリックします。 -3. **Integrate with GPTs**領域で、 **Get Configuration**をクリックします。 +3. **Integrate with GPTs**領域で、 **Get Configuration**をクリックします。 ![Get Configuration](/media/tidb-cloud/data-service/GPTs1.png) -4. 表示されたダイアログボックスには、以下の項目が表示されます。 +4. 表示されたダイアログボックスには、以下の項目が表示されます。 ａ． **API Specification URL** : データ アプリの OpenAPI 仕様の URL をコピーします。詳細については、 [OpenAPI仕様を使用する](/tidb-cloud/data-service-manage-data-app.md#use-the-openapi-specification)を参照してください。 @@ -33,7 +33,7 @@ summary: TiDB Cloudコンソールで、 TiDB CloudデータアプリをGPTやDi ![GPTs Dialog Box](/media/tidb-cloud/data-service/GPTs2.png) -5. コピーしたAPI仕様のURLとエンコードされたAPIキーをGPT構成で使用してください。 +5. コピーしたAPI仕様のURLとエンコードされたAPIキーをGPT構成で使用してください。 ## データアプリをDifyと連携させましょう {#integrate-your-data-app-with-dify} diff --git a/tidb-cloud/data-service-manage-data-app.md b/tidb-cloud/data-service-manage-data-app.md index 88076572616ab..4a8a61a51804c 100644 --- a/tidb-cloud/data-service-manage-data-app.md +++ b/tidb-cloud/data-service-manage-data-app.md @@ -13,35 +13,35 @@ Data Service（プレビュー版）のデータアプリは、特定のアプ プロジェクトのデータ アプリを作成するには、次の手順を実行します。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページで、左側のペインで**Create DataApp**。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページで、左側のペインで**Create DataApp**。 > **Tip:** > > これがプロジェクトの最初のデータ アプリである場合は、ページの中央にある**Create Data App**をクリックします。 -2. 名前と説明を入力し、データ アプリがアクセスするクラスターを選択します。 +2. 名前と説明を入力し、データ アプリがアクセスするクラスターを選択します。 > **Note:** > > デフォルトでは、データアプリの種類は**Standard Data App**です。**Chat2Query Data App**を作成する場合は、このドキュメントではなく[Chat2Query APIを使い始める](/tidb-cloud/use-chat2query-api.md)を参照してください。 -3. (オプション) データ アプリのエンドポイントを優先 GitHub リポジトリとブランチに自動的にデプロイするには、 **Connect to GitHub**を有効にして、次の操作を行います。 +3. (オプション) データ アプリのエンドポイントを優先 GitHub リポジトリとブランチに自動的にデプロイするには、 **Connect to GitHub**を有効にして、次の操作を行います。 - 1. **Install on GitHub**をクリックし、画面の指示に従って、 **TiDB Cloud Data Service**をアプリケーションとしてターゲット リポジトリにインストールします。 - 2. **Authorize**をクリックして、GitHub 上のアプリケーションへのアクセスを承認します。 - 3. データ アプリの構成ファイルを保存するターゲット リポジトリ、ブランチ、ディレクトリを指定します。 + 1. **Install on GitHub**をクリックし、画面の指示に従って、 **TiDB Cloud Data Service**をアプリケーションとしてターゲット リポジトリにインストールします。 + 2. **Authorize**をクリックして、GitHub 上のアプリケーションへのアクセスを承認します。 + 3. データ アプリの構成ファイルを保存するターゲット リポジトリ、ブランチ、ディレクトリを指定します。 > **Note:** > - > - ディレクトリはスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata` 。指定したディレクトリがターゲットリポジトリとブランチに存在しない場合は、自動的に作成されます。 - > - リポジトリ、ブランチ、ディレクトリの組み合わせは、設定ファイルのパスを識別します。このパスはデータアプリ間で一意である必要があります。指定したパスが既に別のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、 TiDB Cloudコンソールで現在のデータアプリ用に設定されたエンドポイントによって、指定したパス内のファイルが上書きされます。 - > - 指定したパスに別のデータ アプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータ アプリにインポートする場合は、 [既存のデータアプリの構成をインポートする](/tidb-cloud/data-service-manage-github-connection.md#import-configurations-of-an-existing-data-app)を参照してください。 + > - ディレクトリはスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata` 。指定したディレクトリがターゲットリポジトリとブランチに存在しない場合は、自動的に作成されます。 + > - リポジトリ、ブランチ、ディレクトリの組み合わせは、設定ファイルのパスを識別します。このパスはデータアプリ間で一意である必要があります。指定したパスが既に別のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、 TiDB Cloudコンソールで現在のデータアプリ用に設定されたエンドポイントによって、指定したパス内のファイルが上書きされます。 + > - 指定したパスに別のデータ アプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータ アプリにインポートする場合は、 [既存のデータアプリの構成をインポートする](/tidb-cloud/data-service-manage-github-connection.md#import-configurations-of-an-existing-data-app)を参照してください。 -4. **Create Data App**をクリックします。 +4. **Create Data App**をクリックします。 新しく作成されたデータアプリがリストの一番上に追加されます。新しいデータアプリにはデフォルトで「 `untitled endpoint`が作成されます。 -5. データアプリをGitHubに接続するように設定している場合は、指定したGitHubディレクトリを確認してください`tidb-cloud-data-service`までに[データアプリの構成ファイル](/tidb-cloud/data-service-app-config-files.md)ディレクトリにコミットされていることがわかります。これは、データアプリがGitHubに正常に接続されていることを意味します。 +5. データアプリをGitHubに接続するように設定している場合は、指定したGitHubディレクトリを確認してください`tidb-cloud-data-service`までに[データアプリの構成ファイル](/tidb-cloud/data-service-app-config-files.md)ディレクトリにコミットされていることがわかります。これは、データアプリがGitHubに正常に接続されていることを意味します。 新しいデータアプリでは、**Auto Sync & Deployment**、および**Review Draft**がデフォルトで有効になっているため、 TiDB Cloudコンソールと GitHub 間でデータアプリの変更を簡単に同期し、デプロイ前に変更を確認できます。GitHub との統合の詳細については、 [データアプリの変更を GitHub で自動的にデプロイ](/tidb-cloud/data-service-manage-github-connection.md)ご覧ください。 @@ -53,9 +53,9 @@ Data Service（プレビュー版）のデータアプリは、特定のアプ データアプリの名前、バージョン、説明を編集できます。データアプリのプロパティを編集するには、次の手順に従います。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリの名前をクリックして詳細を表示します。 -3. **Data App Properties**領域で、 をクリックし、アプリ名、バージョン、または説明を変更して、 **Confirm**をクリックします。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +2. 左側のペインで、対象のデータ アプリの名前をクリックして詳細を表示します。 +3. **Data App Properties**領域で、 をクリックし、アプリ名、バージョン、または説明を変更して、 **Confirm**をクリックします。 ### GitHub接続を管理する {#manage-github-connection} @@ -67,17 +67,17 @@ Data Service（プレビュー版）のデータアプリは、特定のアプ クラスターをデータ アプリにリンクするには、次の手順を実行します。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリを見つけ、対象のデータ アプリの名前をクリックして詳細を表示します。 -3. **Linked Data Sources**領域で、 **Add Cluster**をクリックします。 -4. 表示されたダイアログボックスで、リストからクラスターを選択し、 **Add**をクリックします。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +2. 左側のペインで、対象のデータ アプリを見つけ、対象のデータ アプリの名前をクリックして詳細を表示します。 +3. **Linked Data Sources**領域で、 **Add Cluster**をクリックします。 +4. 表示されたダイアログボックスで、リストからクラスターを選択し、 **Add**をクリックします。 データ アプリからリンクされたクラスターを削除するには、次の手順を実行します。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリを見つけ、対象のデータ アプリの名前をクリックして詳細を表示します。 -3. **Linked Data Sources**領域で、データ アプリから削除する対象のリンク クラスターを見つけて、 **[Action]**列の**[Delete] を**クリックします。 -4. 表示されたダイアログボックスで削除を確認します。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +2. 左側のペインで、対象のデータ アプリを見つけ、対象のデータ アプリの名前をクリックして詳細を表示します。 +3. **Linked Data Sources**領域で、データ アプリから削除する対象のリンク クラスターを見つけて、 **[Action]**列の**[Delete] を**クリックします。 +4. 表示されたダイアログボックスで削除を確認します。 リンクされたクラスターを削除しても、クラスター自体は削除されませんが、データ アプリ内の既存のエンドポイントはクラスターにアクセスできなくなります。 @@ -97,26 +97,26 @@ Data Service（プレビュー版）のデータアプリは、特定のアプ デプロイメントを管理するには、次の手順を実行します。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリを見つけ、対象のデータ アプリの名前をクリックして詳細を表示します。 +2. 左側のペインで、対象のデータ アプリを見つけ、対象のデータ アプリの名前をクリックして詳細を表示します。 -3. **Deployment Configuration**領域で、 **Config**をクリックします。デプロイメント構成のダイアログが表示されます。 +3. **Deployment Configuration**領域で、 **Config**をクリックします。デプロイメント構成のダイアログが表示されます。 -4. ダイアログで、**Auto Sync & Deployment**と**Review Draft**の希望の設定を選択します。 +4. ダイアログで、**Auto Sync & Deployment**と**Review Draft**の希望の設定を選択します。 - - **Auto Sync & Deployment** + - **Auto Sync & Deployment** - - このオプションは、データアプリがGitHubに接続されている場合にのみ有効にできます。詳細については、 [GitHubで自動デプロイ](/tidb-cloud/data-service-manage-github-connection.md)ご覧ください。 - - 有効にすると、指定したGitHubディレクトリに加えられた変更がTiDB Cloudに自動的にデプロイされ、 TiDB Cloudコンソールに加えられた変更もGitHubにプッシュされます。対応するデプロイ情報とコミット情報は、データアプリのデプロイ履歴で確認できます。 - - 無効にすると、指定した GitHub ディレクトリで行われた変更はTiDB Cloudにデプロイ**されず**、 TiDB Cloudコンソールで行われた変更も GitHub にプッシュされ**ません**。 + - このオプションは、データアプリがGitHubに接続されている場合にのみ有効にできます。詳細については、 [GitHubで自動デプロイ](/tidb-cloud/data-service-manage-github-connection.md)ご覧ください。 + - 有効にすると、指定したGitHubディレクトリに加えられた変更がTiDB Cloudに自動的にデプロイされ、 TiDB Cloudコンソールに加えられた変更もGitHubにプッシュされます。対応するデプロイ情報とコミット情報は、データアプリのデプロイ履歴で確認できます。 + - 無効にすると、指定した GitHub ディレクトリで行われた変更はTiDB Cloudにデプロイ**されず**、 TiDB Cloudコンソールで行われた変更も GitHub にプッシュされ**ません**。 - - **Review Draft** + - **Review Draft** - - 有効にすると、デプロイ前にTiDB Cloudコンソールでデータアプリに加えた変更を確認できます。確認結果に基づいて、変更をデプロイするか破棄するかを選択できます。 - - 無効にすると、 TiDB Cloudコンソールで行ったデータ アプリの変更が直接デプロイされます。 + - 有効にすると、デプロイ前にTiDB Cloudコンソールでデータアプリに加えた変更を確認できます。確認結果に基づいて、変更をデプロイするか破棄するかを選択できます。 + - 無効にすると、 TiDB Cloudコンソールで行ったデータ アプリの変更が直接デプロイされます。 -5. **Action**列では、必要に応じて変更を編集または再展開できます。 +5. **Action**列では、必要に応じて変更を編集または再展開できます。 ## OpenAPI仕様を使用する {#use-the-openapi-specification} @@ -126,15 +126,15 @@ Data Service（プレビュー版）は、各データアプリ向けのOpenAPI データ アプリの OpenAPI 仕様を JSON または YAML 形式でダウンロードするには、次の手順を実行します。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリの名前をクリックして詳細を表示します。 +2. 左側のペインで、対象のデータ アプリの名前をクリックして詳細を表示します。 -3. **API Specification**領域で、 **Download**をクリックし、 **JSON**または**YAML**を選択します。 +3. **API Specification**領域で、 **Download**をクリックし、 **JSON**または**YAML**を選択します。 OpenAPI 仕様を初めてダウンロードする場合は、プロンプトが表示されたらリクエストを承認する必要があります。 -4. 次に、OpenAPI 仕様がローカル マシンにダウンロードされます。 +4. 次に、OpenAPI 仕様がローカル マシンにダウンロードされます。 ### OpenAPIドキュメントを確認する {#view-the-openapi-documentation} @@ -142,26 +142,26 @@ Data Service（プレビュー版）では、各データアプリごとに自 OpenAPI ドキュメントにアクセスするには、次の手順を実行します。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリの名前をクリックして詳細を表示します。 +2. 左側のペインで、対象のデータ アプリの名前をクリックして詳細を表示します。 -3. ページの右上隅にある**View API Docs**をクリックします。 +3. ページの右上隅にある**View API Docs**をクリックします。 OpenAPI 仕様を初めて使用する場合は、プロンプトが表示されたらリクエストを承認する必要があります。 -4. すると、OpenAPIドキュメントが新しいタブで開きます。ドキュメントでは、以下の情報を確認できます。 +4. すると、OpenAPIドキュメントが新しいタブで開きます。ドキュメントでは、以下の情報を確認できます。 - - データ アプリの名前、バージョン、説明。 - - タグごとにグループ化されたエンドポイント。 + - データ アプリの名前、バージョン、説明。 + - タグごとにグループ化されたエンドポイント。 -5. (オプション) エンドポイントを試すには、次の手順を実行します。 +5. (オプション) エンドポイントを試すには、次の手順を実行します。 - 1. **[Authorize]**をクリックし、表示されたダイアログ ボックスにデータ アプリの公開キーを**Username**として、秘密キーを**Password**として入力します。 + 1. **[Authorize]**をクリックし、表示されたダイアログ ボックスにデータ アプリの公開キーを**Username**として、秘密キーを**Password**として入力します。 詳細については[APIキーを管理する](/tidb-cloud/data-service-api-key.md)を参照してください。 - 2. ターゲットエンドポイントを見つけ、必要なパラメータを入力して**Try it out**をクリックします。レスポンスは**Response body**領域に表示されます。 + 2. ターゲットエンドポイントを見つけ、必要なパラメータを入力して**Try it out**をクリックします。レスポンスは**Response body**領域に表示されます。 OpenAPI ドキュメントの使用方法の詳細については、 [スワッガーUI](https://swagger.io/tools/swagger-ui/)を参照してください。 @@ -173,13 +173,13 @@ OpenAPI ドキュメントの使用方法の詳細については、 [スワッ データ アプリを削除するには、次の手順を実行します。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリを見つけ、対象のデータ アプリの名前をクリックして詳細を表示します。 -3. **Danger Zone**エリアで、 **Delete Data App**をクリックします。確認のダイアログボックスが表示されます。 -4. `//`を入力し、 **I understand, delete**をクリックします。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +2. 左側のペインで、対象のデータ アプリを見つけ、対象のデータ アプリの名前をクリックして詳細を表示します。 +3. **Danger Zone**エリアで、 **Delete Data App**をクリックします。確認のダイアログボックスが表示されます。 +4. `//`を入力し、 **I understand, delete**をクリックします。 データアプリを削除すると、データアプリ内の既存のエンドポイントとAPIキーも削除されます。このデータアプリがGitHubに接続されている場合、アプリを削除しても、対応するGitHubリポジトリ内のファイルは削除されません。 ## もっと詳しく知る {#learn-more} -- [Postmanでデータアプリを実行する](/tidb-cloud/data-service-postman-integration.md) +- [Postmanでデータアプリを実行する](/tidb-cloud/data-service-postman-integration.md) diff --git a/tidb-cloud/data-service-manage-endpoint.md b/tidb-cloud/data-service-manage-endpoint.md index e7adc640037ee..9d029a43aa7b4 100644 --- a/tidb-cloud/data-service-manage-endpoint.md +++ b/tidb-cloud/data-service-manage-endpoint.md @@ -11,12 +11,12 @@ Data Service (PREVIEW) のエンドポイントは、SQL ステートメント ## 始める前に {#before-you-begin} -- エンドポイントを作成する前に、以下の点を確認してください。 +- エンドポイントを作成する前に、以下の点を確認してください。 - - TiDB Cloud Starterインスタンスとデータ アプリが作成されました。詳細については、 [データアプリを作成する](/tidb-cloud/data-service-manage-data-app.md#create-a-data-app)を参照してください。 - - エンドポイントが操作するデータベース、テーブル、および列は、既にターゲットのTiDB Cloud Starterインスタンスに存在しています。 + - 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} @@ -30,61 +30,61 @@ Data Serviceでは、エンドポイントを自動生成したり、手動で TiDB Cloud Data Serviceでは、以下のようにして1つまたは複数のエンドポイントを一度に自動的に生成できます。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータアプリを見つけ、アプリ名の右側にある**+**をクリックし、 **Autogenerate Endpoint**をクリックします。エンドポイント生成ダイアログが表示されます。 +2. 左側のペインで、対象のデータアプリを見つけ、アプリ名の右側にある**+**をクリックし、 **Autogenerate Endpoint**をクリックします。エンドポイント生成ダイアログが表示されます。 -3. ダイアログで、以下の操作を行ってください。 +3. ダイアログで、以下の操作を行ってください。 - 1. エンドポイントを生成する対象となるTiDB Cloud Starterインスタンス、データベース、およびテーブルを選択してください。 + 1. エンドポイントを生成する対象となるTiDB Cloud Starterインスタンス、データベース、およびテーブルを選択してください。 > **Note:** > > **Table**ドロップダウンリストには、システムテーブルおよび列定義のないテーブルを除き、少なくとも1つの列を持つユーザー定義テーブルのみが表示されます。 - 2. 生成するエンドポイントに対して、少なくとも1つのHTTP操作（ `GET (Retrieve)` 、 `POST (Create)` 、 `PUT (Update)`など）を選択してください。 + 2. 生成するエンドポイントに対して、少なくとも1つのHTTP操作（ `GET (Retrieve)` 、 `POST (Create)` 、 `PUT (Update)`など）を選択してください。 TiDB Cloud Data Serviceは、選択した操作ごとに対応するエンドポイントを生成します。バッチ操作（例`POST (Batch Create)` ）を選択した場合、生成されたエンドポイントを使用すると、単一のリクエストで複数の行を操作できます。 選択したテーブルに [ベクトルデータ型](/ai/reference/vector-search-data-types.md)が含まれている場合は、**Vector Search Operations**オプションを有効にしてベクトル距離関数を選択することで、選択した距離関数に基づいてベクトル距離を自動的に計算するベクトル検索エンドポイントを生成できます。サポートされている[ベクトル距離関数](/ai/reference/vector-search-functions-and-operators.md)は次のものが含まれます。 - - `VEC_L2_DISTANCE` (デフォルト): 2 つのベクトル間の L2 距離 (ユークリッド距離) を計算します。 - - `VEC_COSINE_DISTANCE` : 2 つのベクトル間のコサイン距離を計算します。 - - `VEC_NEGATIVE_INNER_PRODUCT` : 2 つのベクトルの内積の負の値を使用して距離を計算します。 - - `VEC_L1_DISTANCE` : 2 つのベクトル間の L1 距離 (マンハッタン距離) を計算します。 + - `VEC_L2_DISTANCE` (デフォルト): 2 つのベクトル間の L2 距離 (ユークリッド距離) を計算します。 + - `VEC_COSINE_DISTANCE` : 2 つのベクトル間のコサイン距離を計算します。 + - `VEC_NEGATIVE_INNER_PRODUCT` : 2 つのベクトルの内積の負の値を使用して距離を計算します。 + - `VEC_L1_DISTANCE` : 2 つのベクトル間の L1 距離 (マンハッタン距離) を計算します。 - 3. （オプション）操作のタイムアウトとタグを設定します。生成されたすべてのエンドポイントは、設定されたプロパティを自動的に継承しますが、必要に応じて後で変更できます。 + 3. （オプション）操作のタイムアウトとタグを設定します。生成されたすべてのエンドポイントは、設定されたプロパティを自動的に継承しますが、必要に応じて後で変更できます。 - 4. （オプション）**Auto-Deploy Endpoint**オプション（デフォルトでは無効）は、生成されたエンドポイントを直接デプロイするかどうかを制御します。このオプションを有効にすると、ドラフトレビュープロセスがスキップされ、生成されたエンドポイントは、追加の手動レビューや承認なしに即座にデプロイされます。 + 4. （オプション）**Auto-Deploy Endpoint**オプション（デフォルトでは無効）は、生成されたエンドポイントを直接デプロイするかどうかを制御します。このオプションを有効にすると、ドラフトレビュープロセスがスキップされ、生成されたエンドポイントは、追加の手動レビューや承認なしに即座にデプロイされます。 -4. **Generate**をクリックしてください。 +4. **Generate**をクリックしてください。 生成されたエンドポイントは、エンドポイントリストの一番上に表示されます。 -5. 生成されたエンドポイント名、SQLステートメント、プロパティ、および新しいエンドポイントのパラメータを確認してください。 +5. 生成されたエンドポイント名、SQLステートメント、プロパティ、および新しいエンドポイントのパラメータを確認してください。 - - エンドポイント名: 生成されるエンドポイント名は`/`の形式で、リクエストメソッド ( `GET` 、 `POST` 、 `PUT`など) がエンドポイント名の前に表示されます。たとえば、選択されたテーブル名が`sample_table`で、選択された操作が`POST (Create)`の場合、生成されたエンドポイントは`POST /sample_table`と表示されます。 + - エンドポイント名: 生成されるエンドポイント名は`/`の形式で、リクエストメソッド ( `GET` 、 `POST` 、 `PUT`など) がエンドポイント名の前に表示されます。たとえば、選択されたテーブル名が`sample_table`で、選択された操作が`POST (Create)`の場合、生成されたエンドポイントは`POST /sample_table`と表示されます。 - - バッチ操作を選択した場合、 TiDB Cloud Data Service は生成されるエンドポイント名に`/bulk`を追加します。たとえば、選択されたテーブル名が`/sample_table`で、選択された操作が`POST (Batch Create)`の場合、生成されるエンドポイントは`POST /sample_table/bulk`と表示されます。 - - `POST (Vector Similarity Search)`が選択された場合、 TiDB Cloud Data Service は生成されるエンドポイント名に`/vector_search`を追加します。たとえば、選択されたテーブル名が`/sample_table`で、選択された操作が`POST (Vector Similarity Search)`の場合、生成されたエンドポイントは`POST /sample_table/vector_search`と表示されます。 - - 既に同じリクエスト メソッドとエンドポイント名を持つエンドポイントが存在する場合、 TiDB Cloud Data Service は生成されたエンドポイント名に`_dump_`を追加します。たとえば、 `/sample_table_dump_EUKRfl`となります。 + - バッチ操作を選択した場合、 TiDB Cloud Data Service は生成されるエンドポイント名に`/bulk`を追加します。たとえば、選択されたテーブル名が`/sample_table`で、選択された操作が`POST (Batch Create)`の場合、生成されるエンドポイントは`POST /sample_table/bulk`と表示されます。 + - `POST (Vector Similarity Search)`が選択された場合、 TiDB Cloud Data Service は生成されるエンドポイント名に`/vector_search`を追加します。たとえば、選択されたテーブル名が`/sample_table`で、選択された操作が`POST (Vector Similarity Search)`の場合、生成されたエンドポイントは`POST /sample_table/vector_search`と表示されます。 + - 既に同じリクエスト メソッドとエンドポイント名を持つエンドポイントが存在する場合、 TiDB Cloud Data Service は生成されたエンドポイント名に`_dump_`を追加します。たとえば、 `/sample_table_dump_EUKRfl`となります。 - - SQLステートメント： TiDB Cloud Data Serviceは、テーブルの列仕様と選択されたエンドポイント操作に基づいて、生成されたエンドポイント用のSQLステートメントを自動的に作成します。エンドポイント名をクリックすると、ページの中央部分に表示されるSQLステートメントを確認できます。 + - SQLステートメント： TiDB Cloud Data Serviceは、テーブルの列仕様と選択されたエンドポイント操作に基づいて、生成されたエンドポイント用のSQLステートメントを自動的に作成します。エンドポイント名をクリックすると、ページの中央部分に表示されるSQLステートメントを確認できます。 - - エンドポイントのプロパティ： TiDB Cloud Data Serviceは、選択内容に応じてエンドポイントパス、リクエストメソッド、タイムアウト、タグを自動的に構成します。これらのプロパティは、ページの右側のペインに表示されます。 + - エンドポイントのプロパティ： TiDB Cloud Data Serviceは、選択内容に応じてエンドポイントパス、リクエストメソッド、タイムアウト、タグを自動的に構成します。これらのプロパティは、ページの右側のペインに表示されます。 - - エンドポイントパラメータ： TiDB Cloud Data Serviceは、生成されたエンドポイントのパラメータを自動的に構成します。パラメータは、ページの右側のペインに表示されます。 + - エンドポイントパラメータ： TiDB Cloud Data Serviceは、生成されたエンドポイントのパラメータを自動的に構成します。パラメータは、ページの右側のペインに表示されます。 -6. 生成されたエンドポイントの名前、SQL ステートメント、プロパティ、パラメーターなどの詳細を変更する場合は[エンドポイントを開発する](#deploy-an-endpoint)に記載されている手順を参照してください。 +6. 生成されたエンドポイントの名前、SQL ステートメント、プロパティ、パラメーターなどの詳細を変更する場合は[エンドポイントを開発する](#deploy-an-endpoint)に記載されている手順を参照してください。 ### エンドポイントを手動で作成する {#create-an-endpoint-manually} エンドポイントを手動で作成するには、以下の手順を実行してください。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリを見つけ、アプリ名の右側にある**+ を**クリックし、次に**Create Endpoint**をクリックします。 -3. 必要に応じてデフォルト名を更新してください。新しく作成されたエンドポイントは、エンドポイントリストの一番上に追加されます。 -4. [エンドポイントを開発する](#develop-an-endpoint)」の指示に従って、新しいエンドポイントを構成します。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +2. 左側のペインで、対象のデータ アプリを見つけ、アプリ名の右側にある**+ を**クリックし、次に**Create Endpoint**をクリックします。 +3. 必要に応じてデフォルト名を更新してください。新しく作成されたエンドポイントは、エンドポイントリストの一番上に追加されます。 +4. [エンドポイントを開発する](#develop-an-endpoint)」の指示に従って、新しいエンドポイントを構成します。 ### 定義済みのシステムエンドポイントを追加します {#add-a-predefined-system-endpoint} @@ -92,37 +92,37 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 データアプリに定義済みのシステムエンドポイントを追加するには、次の手順を実行します。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータ アプリを見つけ、アプリ名の右側にある**+**をクリックし、次に**Manage Endpoint Library**をクリックします。 +2. 左側のペインで、対象のデータ アプリを見つけ、アプリ名の右側にある**+**をクリックし、次に**Manage Endpoint Library**をクリックします。 エンドポイントライブラリ管理のダイアログが表示されます。現在、このダイアログには**Execute Query** （つまり、 `/system/query`エンドポイント）のみが表示されます。 -3. `/system/query`エンドポイントをデータアプリに追加するには、**Execute Query**スイッチを**Added**に切り替えます。 +3. `/system/query`エンドポイントをデータアプリに追加するには、**Execute Query**スイッチを**Added**に切り替えます。 > **Tip:** > > データ アプリから追加済みの定義済みエンドポイントを削除するには、 **Execute Query**スイッチを**Removed**に切り替えます。 -4. **Save**をクリックしてください。 +4. **Save**をクリックしてください。 > **Note:** > - > - **Save**をクリックすると、追加または削除されたエンドポイントが即座に本番にデプロイされ、追加されたエンドポイントはすぐにアクセス可能になり、削除されたエンドポイントはすぐにアクセス不可能になります。 - > - 現在のアプリ内に、同じパスとメソッドを持つ定義されていないエンドポイントが既に存在する場合、システムエンドポイントの作成は失敗します。 + > - **Save**をクリックすると、追加または削除されたエンドポイントが即座に本番にデプロイされ、追加されたエンドポイントはすぐにアクセス可能になり、削除されたエンドポイントはすぐにアクセス不可能になります。 + > - 現在のアプリ内に、同じパスとメソッドを持つ定義されていないエンドポイントが既に存在する場合、システムエンドポイントの作成は失敗します。 追加されたシステム提供のエンドポイントは、エンドポイントリストの一番上に表示されます。 -5. 新しいエンドポイントのエンドポイント名、SQLステートメント、プロパティ、およびパラメータを確認してください。 +5. 新しいエンドポイントのエンドポイント名、SQLステートメント、プロパティ、およびパラメータを確認してください。 > **Note:** > > `/system/query`エンドポイントは強力で汎用性が高い反面、潜在的に破壊的な影響を及ぼす可能性があります。慎重に使用し、意図しない結果を防ぐために、クエリが安全かつ十分に検討されていることを確認してください。 - - エンドポイント名: エンドポイント名とパスは`/system/query`で、リクエストメソッドは`POST`です。 - - SQL ステートメント: `/system/query`エンドポイントには、SQL ステートメントは含まれていません。ページの中央部分に SQL エディタがありますので、そこに必要な SQL ステートメントを記述してください。 `/system/query`エンドポイント用に SQL エディタに記述した SQL ステートメントは、次回以降に開発やテストを行うために SQL エディタに保存されますが、エンドポイント構成には保存されないことに注意してください。 - - エンドポイントのプロパティ：ページの右側のペインにある**Properties**タブで、エンドポイントのプロパティを確認できます。他のカスタムエンドポイントとは異なり、システムエンドポイントでは、 `timeout`と`max rows`プロパティのみをカスタマイズできます。 - - エンドポイントパラメータ：ページの右側のペインにある**Params**タブでエンドポイントパラメータを確認できます。 `/system/query`エンドポイントのパラメータは自動的に設定され、変更することはできません。 + - エンドポイント名: エンドポイント名とパスは`/system/query`で、リクエストメソッドは`POST`です。 + - SQL ステートメント: `/system/query`エンドポイントには、SQL ステートメントは含まれていません。ページの中央部分に SQL エディタがありますので、そこに必要な SQL ステートメントを記述してください。 `/system/query`エンドポイント用に SQL エディタに記述した SQL ステートメントは、次回以降に開発やテストを行うために SQL エディタに保存されますが、エンドポイント構成には保存されないことに注意してください。 + - エンドポイントのプロパティ：ページの右側のペインにある**Properties**タブで、エンドポイントのプロパティを確認できます。他のカスタムエンドポイントとは異なり、システムエンドポイントでは、 `timeout`と`max rows`プロパティのみをカスタマイズできます。 + - エンドポイントパラメータ：ページの右側のペインにある**Params**タブでエンドポイントパラメータを確認できます。 `/system/query`エンドポイントのパラメータは自動的に設定され、変更することはできません。 ## エンドポイントを開発する {#develop-an-endpoint} @@ -138,25 +138,25 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 #### 基本特性 {#basic-properties} -- **パス**：ユーザーがエンドポイントにアクセスするために使用するパス。 +- **パス**：ユーザーがエンドポイントにアクセスするために使用するパス。 - - パスの長さは64文字未満でなければなりません。 + - パスの長さは64文字未満でなければなりません。 - - リクエストメソッドとパスの組み合わせは、データアプリ内で一意である必要があります。 + - リクエストメソッドとパスの組み合わせは、データアプリ内で一意である必要があります。 - - パスには、文字、数字、アンダースコア ( `_` )、スラッシュ ( `/` )、および中括弧で囲まれたパラメーター ( `{var}`など) のみが許可されます。各パスはスラッシュ ( `/` ) で始まり、文字、数字、またはアンダースコア ( `_` ) で終わる必要があります。例: `/my_endpoint/get_id` 。 + - パスには、文字、数字、アンダースコア ( `_` )、スラッシュ ( `/` )、および中括弧で囲まれたパラメーター ( `{var}`など) のみが許可されます。各パスはスラッシュ ( `/` ) で始まり、文字、数字、またはアンダースコア ( `_` ) で終わる必要があります。例: `/my_endpoint/get_id` 。 - - `{ }`で囲まれたパラメータには、文字、数字、アンダースコア ( `_` ) のみが許可されます。 `{ }`で囲まれた各パラメータは、文字またはアンダースコア ( `_` ) で始まる必要があります。 + - `{ }`で囲まれたパラメータには、文字、数字、アンダースコア ( `_` ) のみが許可されます。 `{ }`で囲まれた各パラメータは、文字またはアンダースコア ( `_` ) で始まる必要があります。 > **Note:** > - > - パスでは、各パラメータは別々のレベルに配置する必要があり、接頭辞や接尾辞はサポートされていません。 + > - パスでは、各パラメータは別々のレベルに配置する必要があり、接頭辞や接尾辞はサポートされていません。 > > 有効なパス: `/var/{var}`および`/{var}` > > 無効なパス: `/var{var}`および`/{var}var` > - > - 同じメソッドとプレフィックスを持つパスは、次の例のように競合する可能性があります。 + > - 同じメソッドとプレフィックスを持つパスは、次の例のように競合する可能性があります。 > > `GET /var/{var1}` > @@ -164,7 +164,7 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 > > `GET /var/123`両方に一致するため、これら 2 つのパスは互いに競合します。 > - > - パラメータを含むパスは、パラメータを含まないパスよりも優先度が低くなります。例： + > - パラメータを含むパスは、パラメータを含まないパスよりも優先度が低くなります。例： > > `GET /var/{var1}` > @@ -172,39 +172,39 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 > > `GET /var/123`が優先されるため、これら 2 つのパスは競合しません。 > - > - パス パラメーターは SQL で直接使用できます。詳細については、[パラメータを設定する](#configure-parameters)を参照してください。 + > - パス パラメーターは SQL で直接使用できます。詳細については、[パラメータを設定する](#configure-parameters)を参照してください。 -- **Endpoint URL** : (読み取り専用) デフォルト URL は、対応するTiDB Cloud Starterインスタンスが配置されているリージョン、データ アプリのサービス URL、およびエンドポイントのパスに基づいて自動的に生成されます。たとえば、エンドポイントのパスが`/my_endpoint/get_id`の場合、エンドポイント URL は`https://.data.tidbcloud.com/api/v1beta/app//endpoint/my_endpoint/get_id`です。データ アプリのカスタム ドメインを構成するには、 [Data Serviceのカスタムドメイン](/tidb-cloud/data-service-custom-domain.md)を参照してください。 +- **Endpoint URL** : (読み取り専用) デフォルト URL は、対応するTiDB Cloud Starterインスタンスが配置されているリージョン、データ アプリのサービス URL、およびエンドポイントのパスに基づいて自動的に生成されます。たとえば、エンドポイントのパスが`/my_endpoint/get_id`の場合、エンドポイント URL は`https://.data.tidbcloud.com/api/v1beta/app//endpoint/my_endpoint/get_id`です。データ アプリのカスタム ドメインを構成するには、 [Data Serviceのカスタムドメイン](/tidb-cloud/data-service-custom-domain.md)を参照してください。 -- **Request Method**：エンドポイントのHTTPメソッド。以下のメソッドがサポートされています。 +- **Request Method**：エンドポイントのHTTPメソッド。以下のメソッドがサポートされています。 - - `GET` : `SELECT`ステートメントなどのデータを照会または取得するには、このメソッドを使用します。 - - `POST` : このメソッドを使用して、 `INSERT`ステートメントなどのデータを挿入または作成します。 - - `PUT` : `UPDATE`ステートメントなどのデータを更新または変更するには、このメソッドを使用します。 - - `DELETE` : `DELETE`ステートメントなどのデータを削除するには、このメソッドを使用します。 + - `GET` : `SELECT`ステートメントなどのデータを照会または取得するには、このメソッドを使用します。 + - `POST` : このメソッドを使用して、 `INSERT`ステートメントなどのデータを挿入または作成します。 + - `PUT` : `UPDATE`ステートメントなどのデータを更新または変更するには、このメソッドを使用します。 + - `DELETE` : `DELETE`ステートメントなどのデータを削除するには、このメソッドを使用します。 -- **Description**（任意）：エンドポイントの説明。 +- **Description**（任意）：エンドポイントの説明。 #### 高度なプロパティ {#advanced-properties} -- **タイムアウト(ms)** ：エンドポイントのタイムアウト時間（ミリ秒単位）。 +- **タイムアウト(ms)** ：エンドポイントのタイムアウト時間（ミリ秒単位）。 -- **Max Rows**：エンドポイントが操作または返すことができる最大行数。 +- **Max Rows**：エンドポイントが操作または返すことができる最大行数。 -- **Tag**：エンドポイントのグループを識別するために使用されるタグ。 +- **Tag**：エンドポイントのグループを識別するために使用されるタグ。 -- **Pagination**：このプロパティは、リクエストメソッドが`GET`で、エンドポイントの最後の SQL ステートメントが`SELECT`操作の場合にのみ使用できます。**Pagination**が有効になっている場合、エンドポイントを呼び出す際にクエリ パラメータとして`page`と`page_size`を指定することで、結果をページネーションできます（例`https://.data.tidbcloud.com/api/v1beta/app//endpoint/my_endpoint/get_id?page=&page_size=` 。詳細については、[エンドポイントを呼び出す](#call-an-endpoint)を参照してください。 +- **Pagination**：このプロパティは、リクエストメソッドが`GET`で、エンドポイントの最後の SQL ステートメントが`SELECT`操作の場合にのみ使用できます。**Pagination**が有効になっている場合、エンドポイントを呼び出す際にクエリ パラメータとして`page`と`page_size`を指定することで、結果をページネーションできます（例`https://.data.tidbcloud.com/api/v1beta/app//endpoint/my_endpoint/get_id?page=&page_size=` 。詳細については、[エンドポイントを呼び出す](#call-an-endpoint)を参照してください。 > **Note:** > - > - リクエストに`page`および`page_size`パラメータを含めない場合、デフォルトの動作では、 **Max Rows**プロパティで指定された最大行数が 1 ページに返されます。 - > - `page_size`は**Max Rows**プロパティ以下でなければなりません。そうでない場合はエラーが返されます。 + > - リクエストに`page`および`page_size`パラメータを含めない場合、デフォルトの動作では、 **Max Rows**プロパティで指定された最大行数が 1 ページに返されます。 + > - `page_size`は**Max Rows**プロパティ以下でなければなりません。そうでない場合はエラーが返されます。 -- **Cache Response**：このプロパティは、リクエストメソッドが`GET`の場合にのみ使用できます。**Cache Response**が有効になっている場合、 TiDB Cloud Data Service は`GET`によって返されたレスポンスを、指定された有効期限 (TTL) 期間内にキャッシュできます。 +- **Cache Response**：このプロパティは、リクエストメソッドが`GET`の場合にのみ使用できます。**Cache Response**が有効になっている場合、 TiDB Cloud Data Service は`GET`によって返されたレスポンスを、指定された有効期限 (TTL) 期間内にキャッシュできます。 -- **有効期限（Time-to-live）** ：このプロパティは**Cache Response**が有効になっている場合にのみ使用できます。これを使用して、キャッシュされたレスポンスの有効期限（TTL）を秒単位で指定できます。TTL期間中に同じ`GET`リクエストを再度行うと、Data Serviceはターゲットデータベースからデータを再度取得する代わりに、キャッシュされたレスポンスを直接返します。これにより、クエリのパフォーマンスが向上します。 +- **有効期限（Time-to-live）** ：このプロパティは**Cache Response**が有効になっている場合にのみ使用できます。これを使用して、キャッシュされたレスポンスの有効期限（TTL）を秒単位で指定できます。TTL期間中に同じ`GET`リクエストを再度行うと、Data Serviceはターゲットデータベースからデータを再度取得する代わりに、キャッシュされたレスポンスを直接返します。これにより、クエリのパフォーマンスが向上します。 -- **Batch Operation**: このプロパティは、リクエストメソッドが`POST`または`PUT`の場合にのみ表示されます。**Batch Operation**が有効になっている場合、単一のリクエストで複数の行を操作できます。たとえば、curl コマンドの`POST`オプションのオブジェクトの`items`フィールドにデータ オブジェクトの配列を配置することで、単一`--data-raw`リクエストで複数の行のデータ[エンドポイントを呼び出す](#call-an-endpoint)。. +- **Batch Operation**: このプロパティは、リクエストメソッドが`POST`または`PUT`の場合にのみ表示されます。**Batch Operation**が有効になっている場合、単一のリクエストで複数の行を操作できます。たとえば、curl コマンドの`POST`オプションのオブジェクトの`items`フィールドにデータ オブジェクトの配列を配置することで、単一`--data-raw`リクエストで複数の行のデータ[エンドポイントを呼び出す](#call-an-endpoint)。. > **Note:** > @@ -214,7 +214,7 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 エンドポイント詳細ページのSQLエディタでは、エンドポイントのSQLステートメントを記述して実行できます。また、 `--`に続けて指示を入力するだけで、AIがSQLステートメントを自動的に生成することもできます。 -1. TiDB Cloud Starterインスタンスを選択してください。 +1. TiDB Cloud Starterインスタンスを選択してください。 > **Note:** > @@ -222,12 +222,12 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 SQLエディタの上部にあるドロップダウンリストから、SQLステートメントを実行するTiDB Cloud Starterインスタンスを選択します。すると、右側のペインにある**Schema**タブで、そのTiDB Cloud Starterインスタンスのすべてのデータベースを表示できます。 -2. エンドポイントの種類に応じて、以下のいずれかの方法でデータベースを選択してください。 +2. エンドポイントの種類に応じて、以下のいずれかの方法でデータベースを選択してください。 - - 事前定義されたシステムエンドポイント：SQLエディタの上部にあるドロップダウンリストから、対象のデータベースを選択します。 - - その他のエンドポイント: SQL エディタで対象データベースを指定する SQL ステートメントを記述します。例: `USE database_name;` 。 + - 事前定義されたシステムエンドポイント：SQLエディタの上部にあるドロップダウンリストから、対象のデータベースを選択します。 + - その他のエンドポイント: SQL エディタで対象データベースを指定する SQL ステートメントを記述します。例: `USE database_name;` 。 -3. SQL文を記述してください。 +3. SQL文を記述してください。 SQLエディタでは、テーブル結合クエリ、複雑なクエリ、集計関数などのステートメントを記述できます。また、 `--`と入力して指示を続けるだけで、AIがSQLステートメントを自動的に生成することもできます。 @@ -237,10 +237,10 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 > **Note:** > - > - パラメータ名は大文字と小文字を区別します。 - > - このパラメータは、テーブル名または列名として使用することはできません。 + > - パラメータ名は大文字と小文字を区別します。 + > - このパラメータは、テーブル名または列名として使用することはできません。 -4. SQL文を実行します。 +4. SQL文を実行します。 SQL文にパラメータを挿入している場合は、右側のペインにある**Params**タブで、パラメータにテスト値またはデフォルト値が設定されていることを確認してください。設定されていない場合、エラーが返されます。 @@ -249,11 +249,11 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 macOSの場合： - - エディタにステートメントが1つしかない場合は、それを実行するには、 **⌘ + Enter**を押すか、クリックします。 **Run**。 + - エディタにステートメントが1つしかない場合は、それを実行するには、 **⌘ + Enter**を押すか、クリックします。 **Run**。 - - エディタに複数のステートメントがある場合、それらのステートメントを1つまたは複数順番に実行するには、カーソルを対象のステートメントの上に置くか、カーソルで対象のステートメントの行を選択し、 **⌘ + Enter**キーを押すか、 **Run**をクリックします。 + - エディタに複数のステートメントがある場合、それらのステートメントを1つまたは複数順番に実行するには、カーソルを対象のステートメントの上に置くか、カーソルで対象のステートメントの行を選択し、 **⌘ + Enter**キーを押すか、 **Run**をクリックします。 - - エディタ内のすべてのステートメントを順番に実行するには、 **⇧ + ⌘ + Enter**キーを押すか、カーソルですべてのステートメントの行を選択して**Run**をクリックします。 + - エディタ内のすべてのステートメントを順番に実行するには、 **⇧ + ⌘ + Enter**キーを押すか、カーソルですべてのステートメントの行を選択して**Run**をクリックします。 @@ -261,11 +261,11 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 WindowsまたはLinuxの場合： - - エディタにステートメントが 1 つしかない場合は、それを実行するには、 **Ctrl + Enter**キーを押すか、クリックします。 **Run**。 + - エディタにステートメントが 1 つしかない場合は、それを実行するには、 **Ctrl + Enter**キーを押すか、クリックします。 **Run**。 - - エディタに複数のステートメントがある場合、それらのステートメントを1つまたは複数順番に実行するには、カーソルを対象のステートメントの上に置くか、カーソルで対象のステートメントの行を選択し、 **Ctrl + Enter**キーを押すか、 **Run**をクリックします。 + - エディタに複数のステートメントがある場合、それらのステートメントを1つまたは複数順番に実行するには、カーソルを対象のステートメントの上に置くか、カーソルで対象のステートメントの行を選択し、 **Ctrl + Enter**キーを押すか、 **Run**をクリックします。 - - エディタ内のすべてのステートメントを順番に実行するには、 **Shift + Ctrl + Enter**キーを押すか、カーソルですべてのステートメントの行を選択して**Run**をクリックします。 + - エディタ内のすべてのステートメントを順番に実行するには、 **Shift + Ctrl + Enter**キーを押すか、カーソルですべてのステートメントの行を選択して**Run**をクリックします。 @@ -282,30 +282,30 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 **Definition**セクションでは、パラメーターの以下のプロパティを表示および管理できます。 -- パラメータ名: 名前には文字、数字、アンダースコアのみを含めることができ ( `_` )、文字またはアンダースコアで始まる必要があります ( `_` )。 `page`および`page_size`はリクエスト結果のページネーション用に予約されて**いる**ため、パラメータ名として使用しないでください。 +- パラメータ名: 名前には文字、数字、アンダースコアのみを含めることができ ( `_` )、文字またはアンダースコアで始まる必要があります ( `_` )。 `page`および`page_size`はリクエスト結果のページネーション用に予約されて**いる**ため、パラメータ名として使用しないでください。 -- **Required**：リクエストにおいてパラメータが必須かどうかを指定します。パスパラメータの場合、設定は必須であり、変更できません。その他のパラメータの場合、デフォルト設定は必須ではありません。 +- **Required**：リクエストにおいてパラメータが必須かどうかを指定します。パスパラメータの場合、設定は必須であり、変更できません。その他のパラメータの場合、デフォルト設定は必須ではありません。 -- **Type**: パラメーターのデータ型を指定します。パスパラメーターの場合、 `STRING`と`INTEGER`のみがサポートされます。その他のパラメーターの場合、 `STRING` 、 `NUMBER` 、 `INTEGER` 、 `BOOLEAN` 、および`ARRAY`がサポートされます。 +- **Type**: パラメーターのデータ型を指定します。パスパラメーターの場合、 `STRING`と`INTEGER`のみがサポートされます。その他のパラメーターの場合、 `STRING` 、 `NUMBER` 、 `INTEGER` 、 `BOOLEAN` 、および`ARRAY`がサポートされます。 `STRING`型のパラメーターを使用する場合、引用符 ( `'`または`"` ) を追加する必要はありません。たとえば、 `foo` `STRING`型に対して有効であり、 `"foo"`として処理されますが、 `"foo"`は`"\"foo\""`として処理されます。 -- **Enum Value**: (オプション) パラメーターの有効な値を指定します。パラメーターのタイプが`STRING` 、 `INTEGER` 、または`NUMBER`の場合にのみ使用できます。 +- **Enum Value**: (オプション) パラメーターの有効な値を指定します。パラメーターのタイプが`STRING` 、 `INTEGER` 、または`NUMBER`の場合にのみ使用できます。 - - このフィールドを空欄にした場合、パラメータには指定された型の任意の値を指定できます。 - - 複数の有効な値を指定するには、カンマで区切ります ( `,` )。たとえば、パラメータータイプを`STRING`に設定し、このフィールドを`foo, bar`と指定した場合、パラメーター値は`foo`または`bar`のみになります。 + - このフィールドを空欄にした場合、パラメータには指定された型の任意の値を指定できます。 + - 複数の有効な値を指定するには、カンマで区切ります ( `,` )。たとえば、パラメータータイプを`STRING`に設定し、このフィールドを`foo, bar`と指定した場合、パラメーター値は`foo`または`bar`のみになります。 -- **ItemType** : `ARRAY`型パラメーターのアイテムタイプを指定します。 +- **ItemType** : `ARRAY`型パラメーターのアイテムタイプを指定します。 -- **Default Value**：パラメータのデフォルト値を指定します。 +- **Default Value**：パラメータのデフォルト値を指定します。 - - `ARRAY`型の場合、複数の値をカンマで区切る必要があります ( `,` )。 - - 値がパラメータの型に変換できることを確認してください。そうでない場合、エンドポイントはエラーを返します。 - - パラメータにテスト値を設定しない場合、エンドポイントのテスト時にはデフォルト値が使用されます。 + - `ARRAY`型の場合、複数の値をカンマで区切る必要があります ( `,` )。 + - 値がパラメータの型に変換できることを確認してください。そうでない場合、エンドポイントはエラーを返します。 + - パラメータにテスト値を設定しない場合、エンドポイントのテスト時にはデフォルト値が使用されます。 -- **Location**：パラメータの位置を示します。このプロパティは変更できません。 - - パスパラメータの場合、このプロパティは`Path`です。 - - その他のパラメーターの場合、リクエスト メソッドが`GET`または`DELETE`の場合、このプロパティは`Query`です。リクエスト メソッドが`POST`または`PUT`の場合、このプロパティは`Body`です。 +- **Location**：パラメータの位置を示します。このプロパティは変更できません。 + - パスパラメータの場合、このプロパティは`Path`です。 + - その他のパラメーターの場合、リクエスト メソッドが`GET`または`DELETE`の場合、このプロパティは`Query`です。リクエスト メソッドが`POST`または`PUT`の場合、このプロパティは`Body`です。 **Test Values**セクションでは、テストパラメータの表示と設定ができます。これらの値は、エンドポイントをテストする際のパラメータ値として使用されます。値がパラメータの型に変換できることを確認してください。変換できない場合、エンドポイントはエラーを返します。 @@ -313,9 +313,9 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 エンドポイントの名前を変更するには、以下の手順を実行します。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータアプリの名前をクリックすると、そのエンドポイントが表示されます。 -3. 名前を変更したいエンドポイントを見つけて、 **[...]** > **Rename**をクリックし、エンドポイントの新しい名前を入力します。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +2. 左側のペインで、対象のデータアプリの名前をクリックすると、そのエンドポイントが表示されます。 +3. 名前を変更したいエンドポイントを見つけて、 **[...]** > **Rename**をクリックし、エンドポイントの新しい名前を入力します。 > **Note:** > @@ -329,20 +329,20 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 > > データ アプリを Postman にインポートした場合は、Postman でデータ アプリのエンドポイントをテストすることもできます。詳細については、 [Postmanでデータアプリを実行する](/tidb-cloud/data-service-postman-integration.md)を参照してください。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータアプリの名前をクリックすると、そのエンドポイントが表示されます。 +2. 左側のペインで、対象のデータアプリの名前をクリックすると、そのエンドポイントが表示されます。 -3. テストしたいエンドポイントの名前をクリックすると、その詳細が表示されます。 +3. テストしたいエンドポイントの名前をクリックすると、その詳細が表示されます。 -4. （オプション）エンドポイントにパラメータが含まれている場合は、テストを行う前にテスト値を設定する必要があります。 +4. （オプション）エンドポイントにパラメータが含まれている場合は、テストを行う前にテスト値を設定する必要があります。 - 1. エンドポイントの詳細ページの右側のペインで、 **Params**タブをクリックします。 - 2. **Test Values**セクションを展開し、パラメーターのテスト値を設定します。 + 1. エンドポイントの詳細ページの右側のペインで、 **Params**タブをクリックします。 + 2. **Test Values**セクションを展開し、パラメーターのテスト値を設定します。 パラメータにテスト値を設定しない場合、デフォルト値が使用されます。 -5. 右上隅の**Test**をクリックしてください。 +5. 右上隅の**Test**をクリックしてください。 > **Tip:** > @@ -358,11 +358,11 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 エンドポイントをデプロイするには、以下の手順を実行します。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータアプリの名前をクリックすると、そのエンドポイントが表示されます。 -3. デプロイしたいエンドポイントを見つけ、エンドポイント名をクリックして詳細を表示し、右上隅の**Deploy**をクリックします。 -4. データアプリで**Review Draft**が有効になっている場合、変更内容を確認するためのダイアログが表示されます。確認結果に基づいて、変更を破棄するかどうかを選択できます。 -5. デプロイを確定するには、 **Deploy**をクリックしてください。エンドポイントが正常にデプロイされると、 **Endpoint has been deployed**というメッセージが表示されます。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +2. 左側のペインで、対象のデータアプリの名前をクリックすると、そのエンドポイントが表示されます。 +3. デプロイしたいエンドポイントを見つけ、エンドポイント名をクリックして詳細を表示し、右上隅の**Deploy**をクリックします。 +4. データアプリで**Review Draft**が有効になっている場合、変更内容を確認するためのダイアログが表示されます。確認結果に基づいて、変更を破棄するかどうかを選択できます。 +5. デプロイを確定するには、 **Deploy**をクリックしてください。エンドポイントが正常にデプロイされると、 **Endpoint has been deployed**というメッセージが表示されます。 エンドポイント詳細ページの右側のペインで、**Deployments**タブをクリックすると、デプロイ履歴を表示できます。 @@ -382,28 +382,28 @@ Data Serviceでは、データアプリに直接追加できる事前定義済 TiDB Cloud Data Serviceは、エンドポイントを呼び出すのに役立つコード例を生成します。コード例を取得するには、以下の手順を実行してください。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータアプリの名前をクリックすると、そのエンドポイントが表示されます。 +2. 左側のペインで、対象のデータアプリの名前をクリックすると、そのエンドポイントが表示されます。 -3. 呼び出したいエンドポイントを見つけて、 **[...]** > **Code Example**をクリックします。**Code Example**ダイアログボックスが表示されます。 +3. 呼び出したいエンドポイントを見つけて、 **[...]** > **Code Example**をクリックします。**Code Example**ダイアログボックスが表示されます。 > **Tip:** > > または、エンドポイント名をクリックして詳細を表示し、右上隅の**...** > **Code Example**をクリックすることもできます。 -4. ダイアログボックスで、エンドポイントを呼び出すために使用する環境と認証方法を選択し、コード例をコピーしてください。 +4. ダイアログボックスで、エンドポイントを呼び出すために使用する環境と認証方法を選択し、コード例をコピーしてください。 > **Note:** > - > - コード例は、エンドポイントのプロパティとパラメータに基づいて生成されます。 - > - 現在、 TiDB Cloud Data Serviceではcurlコードの例のみを提供しています。 + > - コード例は、エンドポイントのプロパティとパラメータに基づいて生成されます。 + > - 現在、 TiDB Cloud Data Serviceではcurlコードの例のみを提供しています。 - - 環境：ニーズに応じて、**Test Environment**または**Online Environment**を選択してください。**Online Environment**エンドポイントをデプロイした後にのみ利用可能です。 - - 認証方法：**Basic Authentication**または**Digest Authentication**を選択してください。 + - 環境：ニーズに応じて、**Test Environment**または**Online Environment**を選択してください。**Online Environment**エンドポイントをデプロイした後にのみ利用可能です。 + - 認証方法：**Basic Authentication**または**Digest Authentication**を選択してください。 - - **Basic Authentication** APIキーがBase64エンコードされたテキストとして送信されます。 - - **Digest Authentication** APIキーが暗号化された形式で送信されるため、より安全です。 + - **Basic Authentication** APIキーがBase64エンコードされたテキストとして送信されます。 + - **Digest Authentication** APIキーが暗号化された形式で送信されるため、より安全です。 **Basic Authentication**と比較して、**Digest Authentication**のcurlコードには`--digest`オプションが追加されています。 @@ -456,21 +456,21 @@ TiDB Cloud Data Serviceは、エンドポイントを呼び出すのに役立つ > **Note:** > - > - リージョンドメイン`.data.tidbcloud.com`をリクエストすることで、 TiDB Cloud Starterインスタンスが配置されているリージョンのエンドポイントに直接アクセスできます。 - > - あるいは、リージョンを指定せずにグローバルドメイン`data.tidbcloud.com`リクエストすることもできます。この場合、 TiDB Cloud Data Service はリクエストをターゲットリージョンに内部的にリダイレクトしますが、レイテンシーが増加する可能性があります。この方法を選択する場合は、エンドポイントを呼び出す際に、curl コマンドに`--location-trusted`オプションを追加してください。 + > - リージョンドメイン`.data.tidbcloud.com`をリクエストすることで、 TiDB Cloud Starterインスタンスが配置されているリージョンのエンドポイントに直接アクセスできます。 + > - あるいは、リージョンを指定せずにグローバルドメイン`data.tidbcloud.com`リクエストすることもできます。この場合、 TiDB Cloud Data Service はリクエストをターゲットリージョンに内部的にリダイレクトしますが、レイテンシーが増加する可能性があります。この方法を選択する場合は、エンドポイントを呼び出す際に、curl コマンドに`--location-trusted`オプションを追加してください。 -5. コード例をアプリケーションに貼り付け、必要に応じて編集してから実行してください。 +5. コード例をアプリケーションに貼り付け、必要に応じて編集してから実行してください。 - - ``および``プレースホルダーを API キーに置き換える必要があります。詳細については、 [APIキーを管理する](/tidb-cloud/data-service-api-key.md)を参照してください。 + - ``および``プレースホルダーを API キーに置き換える必要があります。詳細については、 [APIキーを管理する](/tidb-cloud/data-service-api-key.md)を参照してください。 - - エンドポイントのリクエストメソッドが`GET`で、エンドポイントでページ**Pagination**が有効になっている場合、 `page=`と`page_size=`の値を目的の値に更新することで、結果をページ分割できます。たとえば、1 ページあたり 10 個のアイテムを含む 2 ページ目を取得するには、 `page=2`と`page_size=10`を使用します。 + - エンドポイントのリクエストメソッドが`GET`で、エンドポイントでページ**Pagination**が有効になっている場合、 `page=`と`page_size=`の値を目的の値に更新することで、結果をページ分割できます。たとえば、1 ページあたり 10 個のアイテムを含む 2 ページ目を取得するには、 `page=2`と`page_size=10`を使用します。 - - エンドポイントのリクエストメソッドが`POST`または`PUT`の場合は、操作対象のデータ行に応じて`--data-raw`オプションを入力してください。 + - エンドポイントのリクエストメソッドが`POST`または`PUT`の場合は、操作対象のデータ行に応じて`--data-raw`オプションを入力してください。 - - **Batch Operation**が有効になっているエンドポイントの場合、 `--data-raw`オプションは、データ オブジェクトの配列を含む`items`フィールドを持つオブジェクトを受け入れるため、1 つのエンドポイントを使用して複数のデータ行を操作できます。 - - **Batch Operation**が有効になっていないエンドポイントの場合、 `--data-raw`オプションは 1 つのデータ オブジェクトのみを受け入れます。 + - **Batch Operation**が有効になっているエンドポイントの場合、 `--data-raw`オプションは、データ オブジェクトの配列を含む`items`フィールドを持つオブジェクトを受け入れるため、1 つのエンドポイントを使用して複数のデータ行を操作できます。 + - **Batch Operation**が有効になっていないエンドポイントの場合、 `--data-raw`オプションは 1 つのデータ オブジェクトのみを受け入れます。 - - エンドポイントにパラメータが含まれている場合は、エンドポイントを呼び出す際にパラメータ値を指定してください。 + - エンドポイントにパラメータが含まれている場合は、エンドポイントを呼び出す際にパラメータ値を指定してください。 ### 応答 {#response} @@ -484,10 +484,10 @@ TiDB Cloud Data Serviceは、エンドポイントを呼び出すのに役立つ エンドポイントをアンデプロイするには、以下の手順を実行します。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータアプリの名前をクリックすると、そのエンドポイントが表示されます。 -3. アンデプロイするエンドポイントを見つけて、 **[...]** > **Undeploy**をクリックします。 -4. 展開解除を確定するには、 **Undeploy**をクリックしてください。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +2. 左側のペインで、対象のデータアプリの名前をクリックすると、そのエンドポイントが表示されます。 +3. アンデプロイするエンドポイントを見つけて、 **[...]** > **Undeploy**をクリックします。 +4. 展開解除を確定するには、 **Undeploy**をクリックしてください。 ## エンドポイントを削除します {#delete-an-endpoint} @@ -497,7 +497,7 @@ TiDB Cloud Data Serviceは、エンドポイントを呼び出すのに役立つ エンドポイントを削除するには、以下の手順を実行します。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータアプリの名前をクリックすると、そのエンドポイントが表示されます。 -3. 削除したいエンドポイントの名前をクリックし、右上隅の**…** ＞ **Delete**をクリックします。 -4. 削除を確定するには、 **Delete**をクリックしてください。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +2. 左側のペインで、対象のデータアプリの名前をクリックすると、そのエンドポイントが表示されます。 +3. 削除したいエンドポイントの名前をクリックし、右上隅の**…** ＞ **Delete**をクリックします。 +4. 削除を確定するには、 **Delete**をクリックしてください。 diff --git a/tidb-cloud/data-service-manage-github-connection.md b/tidb-cloud/data-service-manage-github-connection.md index 10622d97c158b..eef736d7a3e4c 100644 --- a/tidb-cloud/data-service-manage-github-connection.md +++ b/tidb-cloud/data-service-manage-github-connection.md @@ -17,8 +17,8 @@ GitHub接続で**Auto Sync & Deployment**が有効になっている場合、Git データアプリをGitHubに接続する前に、以下のものを用意してください。 -- GitHubアカウント。 -- ターゲットブランチを含むGitHubリポジトリ。 +- GitHubアカウント。 +- ターゲットブランチを含むGitHubリポジトリ。 > **Note:** > @@ -30,32 +30,32 @@ GitHub接続で**Auto Sync & Deployment**が有効になっている場合、Git アプリ作成時にGitHub接続を有効にしなかった場合でも、以下の手順で有効にすることができます。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータアプリの名前をクリックすると、その詳細が表示されます。 +2. 左側のペインで、対象のデータアプリの名前をクリックすると、その詳細が表示されます。 -3. **Settings**タブで、 **Connect to GitHub**エリアの**Connect**をクリックします。接続設定用のダイアログボックスが表示されます。 +3. **Settings**タブで、 **Connect to GitHub**エリアの**Connect**をクリックします。接続設定用のダイアログボックスが表示されます。 -4. ダイアログボックスで、以下の手順を実行してください。 +4. ダイアログボックスで、以下の手順を実行してください。 - 1. **Install on GitHub**をクリックし、画面の指示に従って、 **TiDB Cloud Data Service**をアプリケーションとして対象のリポジトリにインストールしてください。 + 1. **Install on GitHub**をクリックし、画面の指示に従って、 **TiDB Cloud Data Service**をアプリケーションとして対象のリポジトリにインストールしてください。 - 2. **Authorize**をクリックして、GitHub上のアプリケーションへのアクセスを承認してください。 + 2. **Authorize**をクリックして、GitHub上のアプリケーションへのアクセスを承認してください。 - 3. データアプリの設定ファイルを保存する対象リポジトリ、ブランチ、およびディレクトリを指定してください。 + 3. データアプリの設定ファイルを保存する対象リポジトリ、ブランチ、およびディレクトリを指定してください。 > **Note:** > - > - ディレクトリ名はスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata`のようになります。指定したディレクトリが対象のリポジトリとブランチに存在しない場合は、自動的に作成されます。 - > - リポジトリ、ブランチ、ディレクトリの組み合わせによって構成ファイルのパスが識別されます。このパスはデータアプリ間で一意である必要があります。指定したパスが既に他のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、現在のデータアプリ用にTiDB Cloudコンソールで構成されたエンドポイントによって、指定したパス内のファイルが上書きされます。 - > - 指定したパスに別のデータ アプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータ アプリにインポートする場合は、「誰でもデータ[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)インポートする」を参照してください。 + > - ディレクトリ名はスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata`のようになります。指定したディレクトリが対象のリポジトリとブランチに存在しない場合は、自動的に作成されます。 + > - リポジトリ、ブランチ、ディレクトリの組み合わせによって構成ファイルのパスが識別されます。このパスはデータアプリ間で一意である必要があります。指定したパスが既に他のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、現在のデータアプリ用にTiDB Cloudコンソールで構成されたエンドポイントによって、指定したパス内のファイルが上書きされます。 + > - 指定したパスに別のデータ アプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータ アプリにインポートする場合は、「誰でもデータ[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)インポートする」を参照してください。 - 4. TiDB CloudコンソールまたはGitHubで行われたデータアプリの変更を相互に同期させるには、 **Configure Auto Sync & Deployment**を有効にします。 + 4. TiDB CloudコンソールまたはGitHubで行われたデータアプリの変更を相互に同期させるには、 **Configure Auto Sync & Deployment**を有効にします。 - - この機能を有効にすると、指定したGitHubディレクトリで行われた変更がTiDB Cloudに自動的にデプロイされ、 TiDB Cloudコンソールで行われた変更もGitHubにプッシュされます。関連するデプロイおよびコミット情報は、データアプリのデプロイ履歴で確認できます。 - - この機能を無効にすると、指定したGitHubディレクトリで行われた変更はTiDB Cloudにデプロイさ**れず**、 TiDB Cloudコンソールで行われた変更もGitHubにプッシュされ**ません**。 + - この機能を有効にすると、指定したGitHubディレクトリで行われた変更がTiDB Cloudに自動的にデプロイされ、 TiDB Cloudコンソールで行われた変更もGitHubにプッシュされます。関連するデプロイおよびコミット情報は、データアプリのデプロイ履歴で確認できます。 + - この機能を無効にすると、指定したGitHubディレクトリで行われた変更はTiDB Cloudにデプロイさ**れず**、 TiDB Cloudコンソールで行われた変更もGitHubにプッシュされ**ません**。 -5. **Confirm Connect**をクリックしてください。 +5. **Confirm Connect**をクリックしてください。 ## ステップ2. データアプリの設定をGitHubと同期する {#step-2-synchronize-data-app-configurations-with-github} @@ -82,8 +82,8 @@ GitHub接続で**Auto Sync & Deployment**が有効になっている場合、Git **Auto Sync & Deployment**が有効になっている場合、GitHubまたはTiDB Cloudコンソールのいずれかを使用してデータアプリを変更できます。 -- [オプション1：GitHub上のファイルを更新してデータアプリを修正する](#option-1-modify-your-data-app-by-updating-files-on-github) -- [オプション2： TiDB Cloudコンソールでデータアプリを変更する](#option-2-modify-your-data-app-in-the-tidb-cloud-console) +- [オプション1：GitHub上のファイルを更新してデータアプリを修正する](#option-1-modify-your-data-app-by-updating-files-on-github) +- [オプション2： TiDB Cloudコンソールでデータアプリを変更する](#option-2-modify-your-data-app-in-the-tidb-cloud-console) > **Note:** > @@ -108,12 +108,12 @@ GitHub接続で**Auto Sync & Deployment**が有効になっている場合、Git TiDB Cloudコンソールでデータアプリのエンドポイント[データアプリのエンドポイントを変更する](/tidb-cloud/data-service-manage-endpoint.md)後 (エンドポイントの変更など)、次のように変更を確認して GitHub にデプロイできます。 -1. 右上隅の**Deploy**をクリックしてください。変更内容を確認するためのダイアログが表示されます。 -2. レビュー内容に応じて、以下のいずれかを実行してください。 +1. 右上隅の**Deploy**をクリックしてください。変更内容を確認するためのダイアログが表示されます。 +2. レビュー内容に応じて、以下のいずれかを実行してください。 - - 現在の草稿に基づいてさらに変更を加えたい場合は、このダイアログを閉じて変更を行ってください。 - - 現在の変更を前回のデプロイメントの状態に戻したい場合は、 **Discard Draft**をクリックしてください。 - - 変更内容に問題がなければ、変更内容の説明（任意）を入力し、 **Deploy and Push to GitHub**をクリックします。デプロイ状況は上部のバナーに表示されます。 + - 現在の草稿に基づいてさらに変更を加えたい場合は、このダイアログを閉じて変更を行ってください。 + - 現在の変更を前回のデプロイメントの状態に戻したい場合は、 **Discard Draft**をクリックしてください。 + - 変更内容に問題がなければ、変更内容の説明（任意）を入力し、 **Deploy and Push to GitHub**をクリックします。デプロイ状況は上部のバナーに表示されます。 デプロイが成功すると、 TiDB Cloudコンソールで行われた変更は自動的にGitHubにプッシュされます。 @@ -121,19 +121,19 @@ TiDB Cloudコンソールでデータアプリのエンドポイント[データ 既存のデータアプリの設定を新しいデータアプリにインポートするには、次の手順を実行します。 -1. 既存のデータアプリの設定ファイルを、GitHub上の新しいブランチまたはディレクトリにコピーします。 +1. 既存のデータアプリの設定ファイルを、GitHub上の新しいブランチまたはディレクトリにコピーします。 -2. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページで、GitHub に接続せずに[新しいデータアプリを作成する](/tidb-cloud/data-service-manage-data-app.md#create-a-data-app)。 +2. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページで、GitHub に接続せずに[新しいデータアプリを作成する](/tidb-cloud/data-service-manage-data-app.md#create-a-data-app)。 -3. **Auto Sync & Deployment**を有効にして、[新しいデータアプリをGitHubに接続します](#step-1-connect-your-data-app-to-github)。新しいデータ アプリのターゲット リポジトリ、ブランチ、ディレクトリを指定するときは、コピーした構成ファイルを含む新しいパスを使用します。 +3. **Auto Sync & Deployment**を有効にして、[新しいデータアプリをGitHubに接続します](#step-1-connect-your-data-app-to-github)。新しいデータ アプリのターゲット リポジトリ、ブランチ、ディレクトリを指定するときは、コピーした構成ファイルを含む新しいパスを使用します。 -4. 新しいデータアプリのIDと名前を取得します。左側のペインで新しいデータアプリの名前をクリックすると、右側のペインの**Data App Properties**領域にアプリのIDと名前が表示されます。 +4. 新しいデータアプリのIDと名前を取得します。左側のペインで新しいデータアプリの名前をクリックすると、右側のペインの**Data App Properties**領域にアプリのIDと名前が表示されます。 -5. GitHub の新しいパスで、 `app_id`ファイル内の`app_name`と`datapp_config.json`を取得した ID と名前に更新し、変更をプッシュしてください。 +5. GitHub の新しいパスで、 `app_id`ファイル内の`app_name`と`datapp_config.json`を取得した ID と名前に更新し、変更をプッシュしてください。 ファイルの変更がGitHubにプッシュされると、 TiDB Cloudは最新の変更内容を反映した新しいデータアプリを自動的にデプロイします。 -6. GitHubからインポートされた設定を表示するには、 TiDB Cloudコンソールのウェブページを更新してください。 +6. GitHubからインポートされた設定を表示するには、 TiDB Cloudコンソールのウェブページを更新してください。 デプロイ履歴では、デプロイ状況やコミット情報も確認できます。 @@ -141,34 +141,34 @@ TiDB Cloudコンソールでデータアプリのエンドポイント[データ データアプリのGitHub接続を編集する場合（リポジトリ、ブランチ、ディレクトリの切り替えなど）、以下の手順を実行してください。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータアプリの名前をクリックすると、その詳細が表示されます。 +2. 左側のペインで、対象のデータアプリの名前をクリックすると、その詳細が表示されます。 -3. **Connect to GitHub**エリアで、 接続設定用のダイアログボックスが表示されます。 +3. **Connect to GitHub**エリアで、 接続設定用のダイアログボックスが表示されます。 -4. ダイアログボックスで、データアプリのリポジトリ、ブランチ、およびディレクトリを変更します。 +4. ダイアログボックスで、データアプリのリポジトリ、ブランチ、およびディレクトリを変更します。 > **Note:** > - > - ディレクトリ名はスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata`のようになります。指定したディレクトリが対象のリポジトリとブランチに存在しない場合は、自動的に作成されます。 - > - リポジトリ、ブランチ、ディレクトリの組み合わせによって構成ファイルのパスが識別されます。このパスはデータアプリ間で一意である必要があります。指定したパスが既に他のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、現在のデータアプリ用にTiDB Cloudコンソールで構成されたエンドポイントによって、指定したパス内のファイルが上書きされます。 - > - 指定したパスに別のデータ アプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータ アプリにインポートする場合は、「誰でもデータ[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)インポートする」を参照してください。 + > - ディレクトリ名はスラッシュ（ `/` ）で始まる必要があります。例えば、 `/mydata`のようになります。指定したディレクトリが対象のリポジトリとブランチに存在しない場合は、自動的に作成されます。 + > - リポジトリ、ブランチ、ディレクトリの組み合わせによって構成ファイルのパスが識別されます。このパスはデータアプリ間で一意である必要があります。指定したパスが既に他のデータアプリで使用されている場合は、新しいパスを指定する必要があります。そうしないと、現在のデータアプリ用にTiDB Cloudコンソールで構成されたエンドポイントによって、指定したパス内のファイルが上書きされます。 + > - 指定したパスに別のデータ アプリからコピーされた構成ファイルが含まれており、これらのファイルを現在のデータ アプリにインポートする場合は、「誰でもデータ[既存のデータアプリの設定をインポートする](#import-configurations-of-an-existing-data-app)インポートする」を参照してください。 -5. TiDB CloudコンソールまたはGitHubで行われたデータアプリの変更を相互に同期させるには、 **Configure Auto Sync & Deployment**を有効にします。 +5. TiDB CloudコンソールまたはGitHubで行われたデータアプリの変更を相互に同期させるには、 **Configure Auto Sync & Deployment**を有効にします。 - - この機能を有効にすると、指定したGitHubディレクトリで行われた変更がTiDB Cloudに自動的にデプロイされ、 TiDB Cloudコンソールで行われた変更もGitHubにプッシュされます。関連するデプロイおよびコミット情報は、データアプリのデプロイ履歴で確認できます。 - - この機能を無効にすると、指定したGitHubディレクトリで行われた変更はTiDB Cloudにデプロイさ**れず**、 TiDB Cloudコンソールで行われた変更もGitHubにプッシュされ**ません**。 + - この機能を有効にすると、指定したGitHubディレクトリで行われた変更がTiDB Cloudに自動的にデプロイされ、 TiDB Cloudコンソールで行われた変更もGitHubにプッシュされます。関連するデプロイおよびコミット情報は、データアプリのデプロイ履歴で確認できます。 + - この機能を無効にすると、指定したGitHubディレクトリで行われた変更はTiDB Cloudにデプロイさ**れず**、 TiDB Cloudコンソールで行われた変更もGitHubにプッシュされ**ません**。 -6. **Confirm Connect**をクリックしてください。 +6. **Confirm Connect**をクリックしてください。 ## GitHub接続を削除 {#remove-github-connection} データアプリをGitHubに接続しなくなった場合は、以下の手順に従ってください。 -1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータアプリの名前をクリックすると、その詳細が表示されます。 -3. **Settings**タブで、 **Connect to GitHub**エリアの**Disconnect**をクリックします。 -4. 切断を確定するには、 **Disconnect**をクリックしてください。 +1. プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +2. 左側のペインで、対象のデータアプリの名前をクリックすると、その詳細が表示されます。 +3. **Settings**タブで、 **Connect to GitHub**エリアの**Disconnect**をクリックします。 +4. 切断を確定するには、 **Disconnect**をクリックしてください。 接続解除操作後、データ アプリの設定ファイルは GitHub ディレクトリに残りますが、 `tidb-cloud-data-service`によって同期されなくなります。 diff --git a/tidb-cloud/data-service-oas-with-nextjs.md b/tidb-cloud/data-service-oas-with-nextjs.md index ec152dc08c617..da8d9b56f0718 100644 --- a/tidb-cloud/data-service-oas-with-nextjs.md +++ b/tidb-cloud/data-service-oas-with-nextjs.md @@ -11,10 +11,10 @@ summary: データアプリのOpenAPI仕様を使用してクライアントコ Next.jsでOpenAPI Specificationを使用する前に、以下のものが用意されていることを確認してください。 -- [TiDB Cloud Starterインスタンス](/tidb-cloud/create-tidb-cluster-serverless.md)または[TiDB Cloud Dedicatedクラスター](/tidb-cloud/create-tidb-cluster.md)クラスター。 -- [Node.js](https://nodejs.org/en/download) -- [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) -- [yarn](https://yarnpkg.com/getting-started/install) +- [TiDB Cloud Starterインスタンス](/tidb-cloud/create-tidb-cluster-serverless.md)または[TiDB Cloud Dedicatedクラスター](/tidb-cloud/create-tidb-cluster.md)クラスター。 +- [Node.js](https://nodejs.org/en/download) +- [npm](https://docs.npmjs.com/downloading-and-installing-node-js-and-npm) +- [yarn](https://yarnpkg.com/getting-started/install) このドキュメントでは、例としてTiDB Cloud Starterインスタンスを使用します。 @@ -57,7 +57,7 @@ SELECT * FROM test.repository; 以下では、Next.jsを例として、データアプリのOpenAPI仕様を使用してクライアントコードを生成する方法を説明します。 -1. `hello-repos`という名前の Next.js プロジェクトを作成します。 +1. `hello-repos`という名前の Next.js プロジェクトを作成します。 公式テンプレートを使用してNext.jsプロジェクトを作成するには、次のコマンドを使用し、プロンプトが表示されたらすべてのデフォルトオプションをそのまま使用してください。 @@ -71,7 +71,7 @@ SELECT * FROM test.repository; cd hello-repos ``` -2. 依存関係をインストールします。 +2. 依存関係をインストールします。 このドキュメントでは[OpenAPIジェネレーター](https://github.com/OpenAPITools/openapi-generator)を使用して、OpenAPI 仕様から API クライアント ライブラリを自動的に生成します。 @@ -81,11 +81,11 @@ SELECT * FROM test.repository; yarn add @openapitools/openapi-generator-cli --dev ``` -3. OpenAPI仕様をダウンロードして、 `oas/doc.json`として保存してください。 +3. OpenAPI仕様をダウンロードして、 `oas/doc.json`として保存してください。 - 1. TiDB Cloud[**Data Service**](https://tidbcloud.com/project/data-service)ページで、左側のペインにあるデータアプリ名をクリックすると、アプリの設定が表示されます。 - 2. **API Specification**エリアで**Download**をクリックし、JSON形式を選択して、プロンプトが表示されたら**Authorize**をクリックします。 - 3. ダウンロードしたファイルを`oas/doc.json`プロジェクトディレクトリに`hello-repos` }という名前で保存してください。 + 1. TiDB Cloud[**Data Service**](https://tidbcloud.com/project/data-service)ページで、左側のペインにあるデータアプリ名をクリックすると、アプリの設定が表示されます。 + 2. **API Specification**エリアで**Download**をクリックし、JSON形式を選択して、プロンプトが表示されたら**Authorize**をクリックします。 + 3. ダウンロードしたファイルを`oas/doc.json`プロジェクトディレクトリに`hello-repos` }という名前で保存してください。 詳細については、 [OpenAPI仕様書をダウンロードする](/tidb-cloud/data-service-manage-data-app.md#download-the-openapi-specification)を参照してください。 @@ -133,7 +133,7 @@ SELECT * FROM test.repository; ... ``` -4. クライアントコードを生成する： +4. クライアントコードを生成する： ```shell yarn run openapi-generator-cli generate -i oas/doc.json --generator-name typescript-fetch -o gen/api @@ -145,7 +145,7 @@ SELECT * FROM test.repository; 生成されたクライアントコードを使用して、Next.jsアプリケーションを開発できます。 -1. `hello-repos`プロジェクトディレクトリに、次の変数を含む`.env.local`ファイルを作成し、変数の値をデータアプリの公開鍵と秘密鍵に設定します。 +1. `hello-repos`プロジェクトディレクトリに、次の変数を含む`.env.local`ファイルを作成し、変数の値をデータアプリの公開鍵と秘密鍵に設定します。 ``` TIDBCLOUD_DATA_SERVICE_PUBLIC_KEY=YOUR_PUBLIC_KEY @@ -154,7 +154,7 @@ SELECT * FROM test.repository; データ アプリの API キーを作成するには、 [APIキーを作成する](/tidb-cloud/data-service-api-key.md#create-an-api-key)を参照してください。 -2. `hello-repos`プロジェクトディレクトリで、 `app/page.tsx`の内容を、 `GET /repositories`エンドポイントからデータを取得して表示する以下のコードに置き換えてください。 +2. `hello-repos`プロジェクトディレクトリで、 `app/page.tsx`の内容を、 `GET /repositories`エンドポイントからデータを取得して表示する以下のコードに置き換えてください。 ```js import {DefaultApi, Configuration} from "../gen/api" diff --git a/tidb-cloud/data-service-overview.md b/tidb-cloud/data-service-overview.md index 47dffdcbb0d01..370549868417c 100644 --- a/tidb-cloud/data-service-overview.md +++ b/tidb-cloud/data-service-overview.md @@ -27,14 +27,14 @@ Data Service のエンドポイントは、SQL 文を実行するためにカス Data Serviceを使用すると、TiDB CloudをHTTPS対応のあらゆるアプリケーションやサービスとシームレスに統合できます。以下に、典型的な使用シナリオをいくつかご紹介します。 -- モバイル アプリケーションまたは Web アプリケーションから TiDB クラスターのデータベースに直接アクセスします。 -- サーバーレス エッジ関数を使用してエンドポイントを呼び出し、データベース接続プールによって発生するスケーラビリティの問題を回避します。 -- データソースとしてData Serviceを使用することで、 TiDB Cloudをデータ可視化プロジェクトに統合できます。これにより、データベース接続のユーザー名とパスワードの漏洩を防ぎ、APIのセキュリティと使いやすさが向上します。 -- MySQLインターフェースがサポートしていない環境からデータベースに接続します。これにより、データへのアクセスにおける柔軟性と選択肢が広がります。 +- モバイル アプリケーションまたは Web アプリケーションから TiDB クラスターのデータベースに直接アクセスします。 +- サーバーレス エッジ関数を使用してエンドポイントを呼び出し、データベース接続プールによって発生するスケーラビリティの問題を回避します。 +- データソースとしてData Serviceを使用することで、 TiDB Cloudをデータ可視化プロジェクトに統合できます。これにより、データベース接続のユーザー名とパスワードの漏洩を防ぎ、APIのセキュリティと使いやすさが向上します。 +- MySQLインターフェースがサポートしていない環境からデータベースに接続します。これにより、データへのアクセスにおける柔軟性と選択肢が広がります。 ## 次は何か {#what-s-next} -- [Data Serviceを始める](/tidb-cloud/data-service-get-started.md) -- [Chat2Query APIを使い始める](/tidb-cloud/use-chat2query-api.md) -- [データアプリを管理する](/tidb-cloud/data-service-manage-data-app.md) -- [エンドポイントの管理](/tidb-cloud/data-service-manage-endpoint.md) +- [Data Serviceを始める](/tidb-cloud/data-service-get-started.md) +- [Chat2Query APIを使い始める](/tidb-cloud/use-chat2query-api.md) +- [データアプリを管理する](/tidb-cloud/data-service-manage-data-app.md) +- [エンドポイントの管理](/tidb-cloud/data-service-manage-endpoint.md) diff --git a/tidb-cloud/data-service-postman-integration.md b/tidb-cloud/data-service-postman-integration.md index d891ec1783749..422834561daec 100644 --- a/tidb-cloud/data-service-postman-integration.md +++ b/tidb-cloud/data-service-postman-integration.md @@ -15,45 +15,45 @@ TiDB Cloud [Data Service](https://tidbcloud.com/project/data-service)では、 Postmanにデータアプリをインポートする前に、以下のものを用意してください。 -- [Postman](https://www.postman.com/)アカウント +- [Postman](https://www.postman.com/)アカウント -- [Postmanデスクトップアプリ](https://www.postman.com/downloads)(オプション)。あるいは、アプリをダウンロードせずに Postman Web バージョンを使用することもできます。 +- [Postmanデスクトップアプリ](https://www.postman.com/downloads)(オプション)。あるいは、アプリをダウンロードせずに Postman Web バージョンを使用することもできます。 -- 明確に定義された[終点](/tidb-cloud/data-service-manage-endpoint.md)が少なくとも 1 つある[データアプリ](/tidb-cloud/data-service-manage-data-app.md)。次の要件を満たすエンドポイントのみを Postman にインポートできます。 +- 明確に定義された[終点](/tidb-cloud/data-service-manage-endpoint.md)が少なくとも 1 つある[データアプリ](/tidb-cloud/data-service-manage-data-app.md)。次の要件を満たすエンドポイントのみを Postman にインポートできます。 - - 対象のTiDB Cloud Starterインスタンスが選択されました。 - - エンドポイントパスとリクエストメソッドが設定されました。 - - SQL文が記述されました。 + - 対象のTiDB Cloud Starterインスタンスが選択されました。 + - エンドポイントパスとリクエストメソッドが設定されました。 + - SQL文が記述されました。 -- データアプリ用の[APIキー](/tidb-cloud/data-service-api-key.md#create-an-api-key)。 +- データアプリ用の[APIキー](/tidb-cloud/data-service-api-key.md#create-an-api-key)。 ## ステップ1. データアプリをPostmanにインポートする {#step-1-import-your-data-app-to-postman} データアプリをPostmanにインポートするには、以下の手順に従ってください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. 左側のペインで、対象のデータアプリの名前をクリックすると、その詳細が表示されます。 +2. 左側のペインで、対象のデータアプリの名前をクリックすると、その詳細が表示されます。 -3. ページ右上隅にある**Run in Postman**をクリックします。インポート手順が表示されたダイアログが表示されます。 +3. ページ右上隅にある**Run in Postman**をクリックします。インポート手順が表示されたダイアログが表示されます。 > **Note:** > - > - データアプリに明確なエンドポイント（ターゲットとなるTiDB Cloud Starterインスタンス、パス、リクエストメソッド、SQLステートメントが構成されていること）が設定されていない場合、データアプリの**Run in Postman**は無効のままになります。 - > - Chat2Queryデータアプリの場合、 **Run in Postman**は利用できません。 + > - データアプリに明確なエンドポイント（ターゲットとなるTiDB Cloud Starterインスタンス、パス、リクエストメソッド、SQLステートメントが構成されていること）が設定されていない場合、データアプリの**Run in Postman**は無効のままになります。 + > - Chat2Queryデータアプリの場合、 **Run in Postman**は利用できません。 -4. データアプリのインポートに関するダイアログに表示される手順に従ってください。 +4. データアプリのインポートに関するダイアログに表示される手順に従ってください。 - 1. お好みに応じて、 **Run in Postman for Web**または**Run in Postman Desktop**を選択してPostmanワークスペースを開き、次に目的のワークスペースを選択してください。 + 1. お好みに応じて、 **Run in Postman for Web**または**Run in Postman Desktop**を選択してPostmanワークスペースを開き、次に目的のワークスペースを選択してください。 - - Postmanにログインしていない場合は、画面の指示に従ってまずPostmanにログインしてください。 - - **Run in Postman Desktop**をクリックした場合は、画面の指示に従ってPostmanデスクトップアプリを起動してください。 + - Postmanにログインしていない場合は、画面の指示に従ってまずPostmanにログインしてください。 + - **Run in Postman Desktop**をクリックした場合は、画面の指示に従ってPostmanデスクトップアプリを起動してください。 - 2. Postmanで目的のワークスペースのページで、左側のナビゲーションメニューにある**Import**をクリックします。 + 2. Postmanで目的のワークスペースのページで、左側のナビゲーションメニューにある**Import**をクリックします。 - 3. TiDB CloudダイアログからデータアプリのURLをコピーし、そのURLをPostmanに貼り付けてインポートします。 + 3. TiDB CloudダイアログからデータアプリのURLをコピーし、そのURLをPostmanに貼り付けてインポートします。 -5. URLを貼り付けると、Postmanはデータアプリを新しい[コレクション](https://learning.postman.com/docs/collections/collections-overview)として自動的にインポートします。コレクション名は`TiDB Data Service - `形式です。 +5. URLを貼り付けると、Postmanはデータアプリを新しい[コレクション](https://learning.postman.com/docs/collections/collections-overview)として自動的にインポートします。コレクション名は`TiDB Data Service - `形式です。 コレクション内では、デプロイ済みのエンドポイントは**Deployed**フォルダーに、デプロイされていないエンドポイントは**Draft**フォルダーにグループ化されます。 @@ -61,28 +61,28 @@ Postmanにデータアプリをインポートする前に、以下のものを Postmanでインポートしたデータアプリを実行する前に、PostmanでデータアプリのAPIキーを次のように設定する必要があります。 -1. Postman の左側のナビゲーション メニューで`TiDB Data Service - `をクリックすると、右側にタブが開きます。 -2. `TiDB Data Service - `タブの下にある**Variables**タブをクリックします。 -3. 変数テーブルの**Current value**列に、データアプリの公開鍵と秘密鍵を入力してください。 -4. `TiDB Data Service - `タブの右上隅にある**Save**をクリックします。 +1. Postman の左側のナビゲーション メニューで`TiDB Data Service - `をクリックすると、右側にタブが開きます。 +2. `TiDB Data Service - `タブの下にある**Variables**タブをクリックします。 +3. 変数テーブルの**Current value**列に、データアプリの公開鍵と秘密鍵を入力してください。 +4. `TiDB Data Service - `タブの右上隅にある**Save**をクリックします。 ## ステップ3. Postmanでデータアプリを実行する {#step-3-run-data-app-in-postman} Postmanでデータアプリを実行するには、以下の手順に従ってください。 -1. Postmanの左側のナビゲーションペインで、 **Deployed**または**Draft**フォルダーを展開し、エンドポイント名をクリックして右側にタブを開きます。 +1. Postmanの左側のナビゲーションペインで、 **Deployed**または**Draft**フォルダーを展開し、エンドポイント名をクリックして右側にタブを開きます。 -2. ``タブでは、次のようにエンドポイントを呼び出すことができます。 +2. ``タブでは、次のようにエンドポイントを呼び出すことができます。 - - パラメータのないエンドポイントの場合は、 **Send**をクリックして直接呼び出すことができます。 - - パラメータ付きのエンドポイントの場合は、まずパラメータ値を入力してから**Send**をクリックする必要があります。 + - パラメータのないエンドポイントの場合は、 **Send**をクリックして直接呼び出すことができます。 + - パラメータ付きのエンドポイントの場合は、まずパラメータ値を入力してから**Send**をクリックする必要があります。 - - `GET`または`DELETE`リクエストの場合は、**Query Params**テーブルのパラメータ値を入力してください。 - - `POST`または`PUT`リクエストの場合は、 **Body**タブをクリックし、パラメーター値を JSON オブジェクトとして入力します。TiDB Cloud Data Service のエンドポイントで**Batch Operation**が有効になっている場合は、パラメーター値を JSON オブジェクトの配列として`items`フィールドに入力します。 + - `GET`または`DELETE`リクエストの場合は、**Query Params**テーブルのパラメータ値を入力してください。 + - `POST`または`PUT`リクエストの場合は、 **Body**タブをクリックし、パラメーター値を JSON オブジェクトとして入力します。TiDB Cloud Data Service のエンドポイントで**Batch Operation**が有効になっている場合は、パラメーター値を JSON オブジェクトの配列として`items`フィールドに入力します。 -3. 下部のペインで応答を確認してください。 +3. 下部のペインで応答を確認してください。 -4. 異なるパラメータ値でエンドポイントを再度呼び出したい場合は、パラメータ値を適切に編集してから、再度**Send**をクリックしてください。 +4. 異なるパラメータ値でエンドポイントを再度呼び出したい場合は、パラメータ値を適切に編集してから、再度**Send**をクリックしてください。 Postman の使用法の詳細については、 [Postmanのドキュメント](https://learning.postman.com/docs)を参照してください。 diff --git a/tidb-cloud/data-service-response-and-status-code.md b/tidb-cloud/data-service-response-and-status-code.md index 153dc95de254a..ff81a7d39955b 100644 --- a/tidb-cloud/data-service-response-and-status-code.md +++ b/tidb-cloud/data-service-response-and-status-code.md @@ -19,19 +19,19 @@ Data Serviceは、JSON形式のボディを持つHTTPレスポンスを返しま レスポンスボディには以下のフィールドが含まれます。 -- `type` :*文字列*。このエンドポイントのタイプ。値は`"sql_endpoint"`または`"chat2data_endpoint"`のいずれかになります。エンドポイントによって返されるレスポンスのタイプが異なります。 -- `data` :*オブジェクト*。実行結果は、次の3つの部分から構成されます。 +- `type` :*文字列*。このエンドポイントのタイプ。値は`"sql_endpoint"`または`"chat2data_endpoint"`のいずれかになります。エンドポイントによって返されるレスポンスのタイプが異なります。 +- `data` :*オブジェクト*。実行結果は、次の3つの部分から構成されます。 - - `columns` :*配列*。返されるフィールドのスキーマ情報。 + - `columns` :*配列*。返されるフィールドのスキーマ情報。 - - `rows` :*配列*。返される結果は`key:value`形式です。 + - `rows` :*配列*。返される結果は`key:value`形式です。 エンドポイントで**Batch Operation**が有効になっており、エンドポイントの最後の SQL ステートメントが`INSERT`または`UPDATE`操作である場合は、次の点に注意してください。 - - エンドポイントから返される結果には、各行の応答とステータスを示す`"message"`および`"success"`フィールドも含まれます。 - - 対象テーブルの主キー列が`auto_increment`に設定されている場合、エンドポイントから返される結果には、各行の`"auto_increment_id"`フィールドも含まれます。このフィールドの値は、 `INSERT`操作のAUTO_INCREMENT ID であり、 `null`などの他の操作の場合は`UPDATE`となります。 + - エンドポイントから返される結果には、各行の応答とステータスを示す`"message"`および`"success"`フィールドも含まれます。 + - 対象テーブルの主キー列が`auto_increment`に設定されている場合、エンドポイントから返される結果には、各行の`"auto_increment_id"`フィールドも含まれます。このフィールドの値は、 `INSERT`操作のAUTO_INCREMENT ID であり、 `null`などの他の操作の場合は`UPDATE`となります。 - - `result` :*オブジェクト*。SQL ステートメントの実行関連情報。成功/失敗ステータス、実行時間、返された行数、ユーザー構成などが含まれます。 + - `result` :*オブジェクト*。SQL ステートメントの実行関連情報。成功/失敗ステータス、実行時間、返された行数、ユーザー構成などが含まれます。 回答例は以下のとおりです。 diff --git a/tidb-cloud/database-schema-concepts.md b/tidb-cloud/database-schema-concepts.md index e685252c5f9fb..adcb44b512548 100644 --- a/tidb-cloud/database-schema-concepts.md +++ b/tidb-cloud/database-schema-concepts.md @@ -17,13 +17,13 @@ TiDBにおけるデータベースとは、テーブルやインデックスな システムデータベースは、システムテーブルを格納するためにTiDBによって作成されるデフォルトのデータベースです。TiDBは以下のシステムデータベースを提供します。 -- [`INFORMATION_SCHEMA`](/information-schema/information-schema.md) +- [`INFORMATION_SCHEMA`](/information-schema/information-schema.md) -- [`mysql`](/mysql-schema/mysql-schema.md) +- [`mysql`](/mysql-schema/mysql-schema.md) -- [`performance_schema`](/performance-schema/performance-schema.md) +- [`performance_schema`](/performance-schema/performance-schema.md) -- [`sys`](/sys-schema/sys-schema.md) +- [`sys`](/sys-schema/sys-schema.md) ### `test`データベース {#test-database} @@ -37,11 +37,11 @@ TiDBには`test`という名前のデフォルトデータベースが付属し ### システムテーブル {#system-table} -- `mysql`スキーマには、TiDBシステムテーブルが含まれています。この設計は、MySQLの`mysql`スキーマに似ており、 `mysql.user`などのテーブルを直接編集できます。また、MySQLの拡張機能となるテーブルも多数含まれています。 +- `mysql`スキーマには、TiDBシステムテーブルが含まれています。この設計は、MySQLの`mysql`スキーマに似ており、 `mysql.user`などのテーブルを直接編集できます。また、MySQLの拡張機能となるテーブルも多数含まれています。 -- 情報スキーマは、ANSI 標準に準拠したシステム メタデータの表示方法を提供します。TiDB は、MySQL との互換性のために含まれているテーブルに加えて、多数のカスタム`INFORMATION_SCHEMA`テーブルも提供します。多くの`INFORMATION_SCHEMA`テーブルには、対応する`SHOW`コマンドがあります。 `INFORMATION_SCHEMA`をクエリする利点は、テーブル間で結合できることです。 +- 情報スキーマは、ANSI 標準に準拠したシステム メタデータの表示方法を提供します。TiDB は、MySQL との互換性のために含まれているテーブルに加えて、多数のカスタム`INFORMATION_SCHEMA`テーブルも提供します。多くの`INFORMATION_SCHEMA`テーブルには、対応する`SHOW`コマンドがあります。 `INFORMATION_SCHEMA`をクエリする利点は、テーブル間で結合できることです。 -- パフォーマンススキーマ。TiDBは、MySQLとの互換性のためにパフォーマンススキーマテーブルを実装しています。 +- パフォーマンススキーマ。TiDBは、MySQLとの互換性のためにパフォーマンススキーマテーブルを実装しています。 ### キャッシュされたテーブル {#cached-table} @@ -79,9 +79,9 @@ TiDB は`SPATIAL`タイプを除く、MySQL のすべてのデータタイプを インデックスには大きく分けて2種類あります。 -- 主キー：主キー列にインデックスを作成します。 +- 主キー：主キー列にインデックスを作成します。 -- セカンダリインデックス：主キー以外の列のインデックス +- セカンダリインデックス：主キー以外の列のインデックス ### 一意インデックス {#unique-indexes} @@ -161,9 +161,9 @@ TiDBはバージョン6.6.0以降、実験的機能として外部キー制約 ビューは仮想テーブルとして機能し、そのスキーマはビューを作成する`SELECT`ステートメントによって定義されます。ビューを使用することには、次のような利点があります。 -- 基となるテーブルに保存されている機密性の高いフィールドとデータのセキュリティを確保するため、安全なフィールドとデータのみをユーザーに公開する。 +- 基となるテーブルに保存されている機密性の高いフィールドとデータのセキュリティを確保するため、安全なフィールドとデータのみをユーザーに公開する。 -- 複雑なクエリをより簡単かつ便利にするために、ビューとして頻繁に出現する複雑なクエリを定義する。 +- 複雑なクエリをより簡単かつ便利にするために、ビューとして頻繁に出現する複雑なクエリを定義する。 詳細については、[ビュー](/views.md)を参照してください。 diff --git a/tidb-cloud/dedicated-external-storage.md b/tidb-cloud/dedicated-external-storage.md index 1b56332c04166..3035ead8aaa8c 100644 --- a/tidb-cloud/dedicated-external-storage.md +++ b/tidb-cloud/dedicated-external-storage.md @@ -14,44 +14,44 @@ TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンス用にこれら TiDB Cloud Dedicatedクラスターが Amazon S3 バケット内のソースデータにアクセスできるようにするには、以下のいずれかの方法を使用してクラスターのバケットアクセスを設定します。 -- [ロールARNを使用する](#configure-amazon-s3-access-using-a-role-arn)(推奨): ロール ARN を使用して Amazon S3 バケットにアクセスします。 -- [AWSアクセスキーを使用する](#configure-amazon-s3-access-using-an-aws-access-key): IAMユーザーのアクセスキーを使用して、Amazon S3 バケットにアクセスします。 +- [ロールARNを使用する](#configure-amazon-s3-access-using-a-role-arn)(推奨): ロール ARN を使用して Amazon S3 バケットにアクセスします。 +- [AWSアクセスキーを使用する](#configure-amazon-s3-access-using-an-aws-access-key): IAMユーザーのアクセスキーを使用して、Amazon S3 バケットにアクセスします。 ### ロールARNを使用してAmazon S3へのアクセスを設定する {#configure-amazon-s3-access-using-a-role-arn} TiDB Cloudのバケットアクセスを設定し、以下の手順でロールARNを取得します。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、対象の TiDB クラスターに対応するTiDB Cloudアカウント ID と外部 ID を取得します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、対象の TiDB クラスターに対応するTiDB Cloudアカウント ID と外部 ID を取得します。 - 1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 - 3. **Import data from Cloud Storage**をクリックします。 + 3. **Import data from Cloud Storage**をクリックします。 - 4. **Import Data from Cloud Storage**ページで、**Storage Provider**を**Amazon S3**に設定し、 **Credentials**で**AWS Role ARN**が選択されていることを確認してから、 **Role ARN**フィールドの下にある**Click here to create new one with AWS CloudFormation**をクリックします。 **Add New Role ARN**ダイアログが表示されます。 + 4. **Import Data from Cloud Storage**ページで、**Storage Provider**を**Amazon S3**に設定し、 **Credentials**で**AWS Role ARN**が選択されていることを確認してから、 **Role ARN**フィールドの下にある**Click here to create new one with AWS CloudFormation**をクリックします。 **Add New Role ARN**ダイアログが表示されます。 - 5. **問題が発生しましたか？ロールARNを手動で作成して**、このクラスターの**TiDB Cloud Account ID**と**TiDB Cloud External ID**を取得してください。これらのIDは後で使用するため、メモしておいてください。 + 5. **問題が発生しましたか？ロールARNを手動で作成して**、このクラスターの**TiDB Cloud Account ID**と**TiDB Cloud External ID**を取得してください。これらのIDは後で使用するため、メモしておいてください。 -2. AWS マネジメントコンソールで、Amazon S3 バケット用のマネージドポリシーを作成します。 +2. AWS マネジメントコンソールで、Amazon S3 バケット用のマネージドポリシーを作成します。 - 1. AWS マネジメント コンソールにサインインし、 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)で Amazon S3 コンソールを開きます。 + 1. AWS マネジメント コンソールにサインインし、 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)で Amazon S3 コンソールを開きます。 - 2. **バケット**一覧から、ソースデータが入っているバケットの名前を選択し、 **Copy ARN**をクリックしてS3バケットのARNを取得します（例： `arn:aws:s3:::tidb-cloud-source-data` ）。後で使用するために、バケットのARNをメモしておいてください。 + 2. **バケット**一覧から、ソースデータが入っているバケットの名前を選択し、 **Copy ARN**をクリックしてS3バケットのARNを取得します（例： `arn:aws:s3:::tidb-cloud-source-data` ）。後で使用するために、バケットのARNをメモしておいてください。 ![Copy bucket ARN](/media/tidb-cloud/copy-bucket-arn.png) - 3. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)でIAMコンソールを開き、左側のナビゲーション ペインで**[ポリシー]**をクリックし、 **Create Policy**をクリックします。 + 3. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)でIAMコンソールを開き、左側のナビゲーション ペインで**[ポリシー]**をクリックし、 **Create Policy**をクリックします。 ![Create a policy](/media/tidb-cloud/aws-create-policy.png) - 4. **Create policy**ページで、 **JSON**タブをクリックします。 + 4. **Create policy**ページで、 **JSON**タブをクリックします。 - 5. 以下のアクセス ポリシー テンプレートをコピーして、ポリシー テキスト フィールドに貼り付けてください。 + 5. 以下のアクセス ポリシー テンプレートをコピーして、ポリシー テキスト フィールドに貼り付けてください。 ````json { @@ -105,31 +105,31 @@ TiDB Cloudのバケットアクセスを設定し、以下の手順でロールA ```` - 6. **Next**をクリックしてください。 + 6. **Next**をクリックしてください。 - 7. ポリシー名を設定し、ポリシーのタグを追加（任意）してから、 **Create policy**をクリックします。 + 7. ポリシー名を設定し、ポリシーのタグを追加（任意）してから、 **Create policy**をクリックします。 -3. AWS マネジメントコンソールで、 TiDB Cloudのアクセスロールを作成し、ロール ARN を取得します。 +3. AWS マネジメントコンソールで、 TiDB Cloudのアクセスロールを作成し、ロール ARN を取得します。 - 1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)のIAMコンソールで、左側のナビゲーション ペインの**[ロール]**をクリックし、 **Create role**をクリックします。 + 1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)のIAMコンソールで、左側のナビゲーション ペインの**[ロール]**をクリックし、 **Create role**をクリックします。 ![Create a role](/media/tidb-cloud/aws-create-role.png) - 2. 役割を作成するには、以下の情報を入力してください。 + 2. 役割を作成するには、以下の情報を入力してください。 - - **Trusted entity type**で**AWS account**を選択します。 - - **An AWS account**の下にある**Another AWS account**を選択し、 TiDB CloudアカウントIDを**Account ID**フィールドに貼り付けます。 - - **オプション**で**Require external ID**をクリックして[混乱した副官の問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)回避し、 TiDB Cloud外部IDを**External ID**フィールドに貼り付けます。「外部IDを必須にする」を選択せず​​にロールを作成すると、S3バケットURIとIAMロールARNを持つユーザーであれば誰でもAmazon S3バケットにアクセスできる可能性があります。アカウントIDと外部IDの両方を使用してロールを作成すると、同じプロジェクトおよび同じリージョンで実行されているTiDBクラスタのみがバケットにアクセスできます。 + - **Trusted entity type**で**AWS account**を選択します。 + - **An AWS account**の下にある**Another AWS account**を選択し、 TiDB CloudアカウントIDを**Account ID**フィールドに貼り付けます。 + - **オプション**で**Require external ID**をクリックして[混乱した副官の問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)回避し、 TiDB Cloud外部IDを**External ID**フィールドに貼り付けます。「外部IDを必須にする」を選択せず​​にロールを作成すると、S3バケットURIとIAMロールARNを持つユーザーであれば誰でもAmazon S3バケットにアクセスできる可能性があります。アカウントIDと外部IDの両方を使用してロールを作成すると、同じプロジェクトおよび同じリージョンで実行されているTiDBクラスタのみがバケットにアクセスできます。 - 3. **Next**をクリックしてポリシー一覧を開き、先ほど作成したポリシーを選択してから**Next**をクリックします。 + 3. **Next**をクリックしてポリシー一覧を開き、先ほど作成したポリシーを選択してから**Next**をクリックします。 - 4. **Role details**で役割の名前を設定し、右下隅の**Create role**をクリックします。役割が作成されると、役割の一覧が表示されます。 + 4. **Role details**で役割の名前を設定し、右下隅の**Create role**をクリックします。役割が作成されると、役割の一覧が表示されます。 - 5. 役割の一覧から、先ほど作成した役割の名前をクリックして概要ページに移動し、役割のARNをコピーします。 + 5. 役割の一覧から、先ほど作成した役割の名前をクリックして概要ページに移動し、役割のARNをコピーします。 ![Copy AWS role ARN](/media/tidb-cloud/aws-role-arn.png) -4. TiDB Cloudコンソールで、 TiDB CloudアカウントIDと外部IDを取得する**Data Import**ページに移動し、ロールARNを**Role ARN**フィールドに貼り付けます。 +4. TiDB Cloudコンソールで、 TiDB CloudアカウントIDと外部IDを取得する**Data Import**ページに移動し、ロールARNを**Role ARN**フィールドに貼り付けます。 ### AWSアクセスキーを使用してAmazon S3へのアクセスを設定する {#configure-amazon-s3-access-using-an-aws-access-key} @@ -137,18 +137,18 @@ TiDB Cloudのバケットアクセスを設定し、以下の手順でロールA アクセスキーを設定するには、以下の手順に従ってください。 -1. 以下のポリシーを持つIAMユーザーを作成します。 +1. 以下のポリシーを持つIAMユーザーを作成します。 - - `AmazonS3ReadOnlyAccess` - - [`CreateOwnAccessKeys` （必須）および`ManageOwnAccessKeys` （オプション）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#access-keys_required-permissions) + - `AmazonS3ReadOnlyAccess` + - [`CreateOwnAccessKeys` （必須）および`ManageOwnAccessKeys` （オプション）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html#access-keys_required-permissions) これらのポリシーは、ソースデータが保存されているバケットにのみ適用されるようにすることをお勧めします。 詳細については、 [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)にサインインしてください。 +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)を参照してください。 > **Note:** > @@ -158,59 +158,59 @@ TiDB Cloudのバケットアクセスを設定し、以下の手順でロールA TiDB CloudがGCSバケット内のソースデータにアクセスできるようにするには、バケットのGCSアクセスを設定する必要があります。プロジェクト内の1つのTiDBクラスタの設定が完了すると、そのプロジェクト内のすべてのTiDBクラスタがGCSバケットにアクセスできるようになります。 -1. TiDB Cloudコンソールで、対象のTiDBクラスターのGoogle CloudサービスアカウントIDを取得します。 +1. TiDB Cloudコンソールで、対象のTiDBクラスターのGoogle CloudサービスアカウントIDを取得します。 - 1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 - 3. **Import data from Cloud Storage**をクリックします。 + 3. **Import data from Cloud Storage**をクリックします。 - 4. **Import Data from Cloud Storage**ページで、 **Storage Provider**を**Google Cloud Storage**に設定し、後で使用するためにGoogle CloudサービスアカウントIDをコピーしてください。 + 4. **Import Data from Cloud Storage**ページで、 **Storage Provider**を**Google Cloud Storage**に設定し、後で使用するためにGoogle CloudサービスアカウントIDをコピーしてください。 -2. Google Cloud コンソールで、GCS バケット用のIAMロールを作成します。 +2. Google Cloud コンソールで、GCS バケット用のIAMロールを作成します。 - 1. [Google Cloud Console](https://console.cloud.google.com/)にサインインしてください。 + 1. [Google Cloud Console](https://console.cloud.google.com/)にサインインしてください。 - 2. [役割](https://console.cloud.google.com/iam-admin/roles)ページに移動し、**CREATE ROLE**をクリックしてください。 + 2. [役割](https://console.cloud.google.com/iam-admin/roles)ページに移動し、**CREATE ROLE**をクリックしてください。 ![Create a role](/media/tidb-cloud/gcp-create-role.png) - 3. 役割の名前、説明、ID、および役割の起動ステージを入力してください。役割名は、作成後に変更することはできません。 + 3. 役割の名前、説明、ID、および役割の起動ステージを入力してください。役割名は、作成後に変更することはできません。 - 4. **ADD PERMISSIONS**をクリックしてください。 + 4. **ADD PERMISSIONS**をクリックしてください。 - 5. ロールに以下の読み取り専用権限を追加し、 **[追加]**をクリックします。 + 5. ロールに以下の読み取り専用権限を追加し、 **[追加]**をクリックします。 - - storage.buckets.get - - storage.get - - storage.オブジェクトリスト + - storage.buckets.get + - storage.get + - storage.オブジェクトリスト 権限名をフィルタークエリとして**プロパティ名または値を入力**フィールドにコピーし、フィルター結果からその名前を選択できます。3つの権限を追加するには、権限名の間に**OR**を使用します。 ![Add permissions](/media/tidb-cloud/gcp-add-permissions.png) -3. [バケツ](https://console.cloud.google.com/storage/browser)ページに移動し、 TiDB CloudがアクセスするGCSバケットの名前をクリックします。 +3. [バケツ](https://console.cloud.google.com/storage/browser)ページに移動し、 TiDB CloudがアクセスするGCSバケットの名前をクリックします。 -4. **Bucket details**ページで、 **[権限]**タブをクリックし、 **GRANT ACCESS**をクリックします。 +4. **Bucket details**ページで、 **[権限]**タブをクリックし、 **GRANT ACCESS**をクリックします。 ![Grant Access to the bucket ](/media/tidb-cloud/gcp-bucket-permissions.png) -5. バケットへのアクセス権を付与するには、以下の情報を入力し、 **SAVE**をクリックしてください。 +5. バケットへのアクセス権を付与するには、以下の情報を入力し、 **SAVE**をクリックしてください。 - - **New Principals**フィールドに、対象のTiDBクラスターのGoogle Cloud ServiceアカウントIDを貼り付けます。 + - **New Principals**フィールドに、対象のTiDBクラスターのGoogle Cloud ServiceアカウントIDを貼り付けます。 - - **Select a role**ドロップダウンリストに、先ほど作成したIAMロールの名前を入力し、フィルター結果からその名前を選択します。 + - **Select a role**ドロップダウンリストに、先ほど作成したIAMロールの名前を入力し、フィルター結果からその名前を選択します。 > **Note:** > > TiDB Cloudへのアクセス権を削除するには、付与したアクセス権を削除するだけで済みます。 -6. **Bucket details**ページで、**OBJECTS**タブをクリックします。 +6. **Bucket details**ページで、**OBJECTS**タブをクリックします。 ファイルの gsutil URI をコピーするには、ファイルを選択し、 **[オブジェクトを開く] オーバーフロー メニュー**をクリックして、 **Copy gsutil URI**をクリックします。 @@ -222,31 +222,31 @@ TiDB CloudがGCSバケット内のソースデータにアクセスできるよ ![Get bucket URI](/media/tidb-cloud/gcp-bucket-uri02.png) -7. TiDB Cloudコンソールで、Google Cloud Service アカウント ID を取得する**Data Import**ページに移動し、GCS バケットの gsutil URI を**バケット gsutil URI**フィールドに貼り付けます。たとえば、 `gs://tidb-cloud-source-data/`を貼り付けます。 +7. TiDB Cloudコンソールで、Google Cloud Service アカウント ID を取得する**Data Import**ページに移動し、GCS バケットの gsutil URI を**バケット gsutil URI**フィールドに貼り付けます。たとえば、 `gs://tidb-cloud-source-data/`を貼り付けます。 ## Azure Blob Storageへのアクセスを構成する {#configure-azure-blob-storage-access} TiDB Cloud DedicatedがAzure Blobコンテナにアクセスできるようにするには、コンテナのAzure Blobアクセスを設定する必要があります。アカウントSASトークンを使用してコンテナアクセスを設定できます。 -1. [Azureストレージアカウント](https://portal.azure.com/#browse/Microsoft.Storage%2FStorageAccounts)ページで、コンテナーが属するストレージアカウントをクリックします。 +1. [Azureストレージアカウント](https://portal.azure.com/#browse/Microsoft.Storage%2FStorageAccounts)ページで、コンテナーが属するストレージアカウントをクリックします。 -2. ストレージアカウントのナビゲーション ペインで、 **Security + networking** > **Shared access signature**をクリックします。 +2. ストレージアカウントのナビゲーション ペインで、 **Security + networking** > **Shared access signature**をクリックします。 ![sas-position](/media/tidb-cloud/dedicated-external-storage/azure-sas-position.png) -3. **Shared access signature**ページで、次のように必要な権限を持つ[アカウントSASトークン](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview)を作成します。 +3. **Shared access signature**ページで、次のように必要な権限を持つ[アカウントSASトークン](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview)を作成します。 - 1. **Allowed services**で**Blob**を選択します。 - 2. **Allowed resource types**で、 **Container**と**Object**を選択します。 - 3. **Allowed permissions**で、必要な権限を選択します。たとえば、 TiDB Cloud Dedicatedにデータをインポートするには、 **Read**と**List**の権限が必要です。 - 4. 必要に応じて**開始日時と有効期限日時**を調整してください。セキュリティ上の理由から、有効期限はデータインポートのスケジュールに合わせて設定することをお勧めします。 - 5. その他の設定については、デフォルト値を維持してください。 + 1. **Allowed services**で**Blob**を選択します。 + 2. **Allowed resource types**で、 **Container**と**Object**を選択します。 + 3. **Allowed permissions**で、必要な権限を選択します。たとえば、 TiDB Cloud Dedicatedにデータをインポートするには、 **Read**と**List**の権限が必要です。 + 4. 必要に応じて**開始日時と有効期限日時**を調整してください。セキュリティ上の理由から、有効期限はデータインポートのスケジュールに合わせて設定することをお勧めします。 + 5. その他の設定については、デフォルト値を維持してください。 ![sas-create](/media/tidb-cloud/dedicated-external-storage/azure-sas-create.png) -4. SASトークンを生成するには、 **Generate SAS and connection string**をクリックしてください。 +4. SASトークンを生成するには、 **Generate SAS and connection string**をクリックしてください。 -5. 生成された**SAS Token**をコピーしてください。このトークン文字列は、TiDB Cloudでデータインポートを設定する際に必要になります。 +5. 生成された**SAS Token**をコピーしてください。このトークン文字列は、TiDB Cloudでデータインポートを設定する際に必要になります。 > **Note:** > diff --git a/tidb-cloud/delete-tidb-cluster.md b/tidb-cloud/delete-tidb-cluster.md index dccf4d8e1b4ac..624c1500ebd5b 100644 --- a/tidb-cloud/delete-tidb-cluster.md +++ b/tidb-cloud/delete-tidb-cluster.md @@ -7,44 +7,44 @@ summary: TiDB Cloudリソースを削除する方法を学びましょう。 このドキュメントでは、以下のTiDB Cloudリソースを削除する方法について説明します。 -- [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)インスタンス -- [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンス -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスター +- [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)インスタンス +- [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンス +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスター 以下の手順を実行することで、いつでもTiDB Cloudリソースを削除できます。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 -2. 削除する対象リソースの行で、 **...**をクリックします。 +2. 削除する対象リソースの行で、 **...**をクリックします。 > **Tip:** > > または、対象のリソース名をクリックして概要ページに移動し、右上隅の**...**をクリックすることもできます。 -3. ドロップダウンメニューの**Delete**をクリックしてください。 +3. ドロップダウンメニューの**Delete**をクリックしてください。 -4. 削除確認ウィンドウで、削除を確定してください。 +4. 削除確認ウィンドウで、削除を確定してください。 - - 手動または自動バックアップが少なくとも 1 つある場合は、バックアップの数とバックアップの課金ポリシーを確認できます。 **Continue**をクリックして`//`と入力します。 - - バックアップがない場合は、 `//`と入力してください。 + - 手動または自動バックアップが少なくとも 1 つある場合は、バックアップの数とバックアップの課金ポリシーを確認できます。 **Continue**をクリックして`//`と入力します。 + - バックアップがない場合は、 `//`と入力してください。 今後、削除した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)を参照してください。 > **Note:** > > [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)インスタンスは、削除後のデータの復元をサポートしていません。 TiDB Cloud Starterインスタンスを削除し、将来そのデータを復元したい場合は、 [TiDB Cloud Starterからデータをエクスポート](/tidb-cloud/serverless-export.md)を参照してデータをバックアップとしてエクスポートします。 -5. **I understand, delete it**をクリックしてください。 +5. **I understand, delete it**をクリックしてください。 バックアップ済みのTiDB Cloud EssentialインスタンスまたはTiDB Cloud Dedicatedクラスタが削除されると、既存のバックアップファイルはごみ箱に移動されます。 - - 自動バックアップは、最新のものを除き、保持期間が終了すると期限切れとなり自動的に削除されます。保持期間は、変更しない場合はデフォルトで7日間です。最新の自動バックアップは、明示的に削除しない限り削除されません。 + - 自動バックアップは、最新のものを除き、保持期間が終了すると期限切れとなり自動的に削除されます。保持期間は、変更しない場合はデフォルトで7日間です。最新の自動バックアップは、明示的に削除しない限り削除されません。 - - 手動で作成したバックアップファイルは、手動で削除されるまでごみ箱に保存されます。 + - 手動で作成したバックアップファイルは、手動で削除されるまでごみ箱に保存されます。 > **Note:** > @@ -52,5 +52,5 @@ summary: TiDB Cloudリソースを削除する方法を学びましょう。 ごみ箱からデータを復元したい場合は、以下のドキュメントを参照してください。 - - [削除されたTiDB Cloud Essentialインスタンスを復元する](/tidb-cloud/backup-and-restore-serverless.md#restore-from-recycle-bin)。 - - [削除されたTiDB Cloud Dedicatedクラスターを復元する](/tidb-cloud/backup-and-restore.md#restore-a-deleted-cluster)。 + - [削除されたTiDB Cloud Essentialインスタンスを復元する](/tidb-cloud/backup-and-restore-serverless.md#restore-from-recycle-bin)。 + - [削除されたTiDB Cloud Dedicatedクラスターを復元する](/tidb-cloud/backup-and-restore.md#restore-a-deleted-cluster)。 diff --git a/tidb-cloud/essential-changefeed-overview.md b/tidb-cloud/essential-changefeed-overview.md index 9375ef2511622..1086d05238d98 100644 --- a/tidb-cloud/essential-changefeed-overview.md +++ b/tidb-cloud/essential-changefeed-overview.md @@ -9,19 +9,19 @@ TiDB Cloud changefeed を使用すると、TiDB Cloudから他のデータサー > **Note:** > -> - 現在、 TiDB Cloud Essentialの変更フィード機能はリクエストに応じてのみ利用可能です。この機能をリクエストするには、以下の手順に従ってください。 +> - 現在、 TiDB Cloud Essentialの変更フィード機能はリクエストに応じてのみ利用可能です。この機能をリクエストするには、以下の手順に従ってください。 > -> 1. [TiDB Cloudコンソール](https://tidbcloud.com)の右下隅にある?をクリックします**。** 。 -> 2. **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。 -> 3. チケットを作成します。「説明」欄に「changefeedへの申請」と入力します。 -> 4. **Submit**をクリックしてください。 -> - TiDB Cloud Essentialインスタンスごとに最大10個の変更フィードが許可されています。 -> - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)インスタンスでは、変更フィード機能は利用できません。 +> 1. [TiDB Cloudコンソール](https://tidbcloud.com)の右下隅にある?をクリックします**。** 。 +> 2. **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。 +> 3. チケットを作成します。「説明」欄に「changefeedへの申請」と入力します。 +> 4. **Submit**をクリックしてください。 +> - TiDB Cloud Essentialインスタンスごとに最大10個の変更フィードが許可されています。 +> - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)インスタンスでは、変更フィード機能は利用できません。 ## 制限 {#restrictions} -- Changefeeds は、 `RENAME TABLE`のように、単一の`RENAME TABLE t1 TO t3, t2 TO t4` } ステートメントで複数のテーブルの名前を変更する DDL ステートメントをサポートしていません。このステートメントを実行すると、Changefeed のデータレプリケーションが永続的に中断されます。 -- 変更フィードのスループットは約20 MiB/秒です。増分データ量がこの制限を超える場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 +- Changefeeds は、 `RENAME TABLE`のように、単一の`RENAME TABLE t1 TO t3, t2 TO t4` } ステートメントで複数のテーブルの名前を変更する DDL ステートメントをサポートしていません。このステートメントを実行すると、Changefeed のデータレプリケーションが永続的に中断されます。 +- 変更フィードのスループットは約20 MiB/秒です。増分データ量がこの制限を超える場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 ## 対応地域 {#supported-regions} @@ -38,13 +38,13 @@ TiDB Cloud changefeed を使用すると、TiDB Cloudから他のデータサー 変更フィード機能にアクセスするには、以下の手順に従ってください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Changefeed**をクリックします。変更フィードページが表示されます。 +2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Changefeed**をクリックします。変更フィードページが表示されます。 **Changefeed**ページでは、変更フィードの作成、既存の変更フィードの一覧表示、および既存の変更フィードの操作（変更フィードの一時停止、再開、編集、削除など）を行うことができます。 @@ -52,8 +52,8 @@ TiDB Cloud changefeed を使用すると、TiDB Cloudから他のデータサー 変更フィードを作成するには、チュートリアルを参照してください。 -- [Apache Kafkaへのシンク](/tidb-cloud/essential-changefeed-sink-to-kafka.md) -- [MySQLにシンクする](/tidb-cloud/essential-changefeed-sink-to-mysql.md) +- [Apache Kafkaへのシンク](/tidb-cloud/essential-changefeed-sink-to-kafka.md) +- [MySQLにシンクする](/tidb-cloud/essential-changefeed-sink-to-mysql.md) ## 変更フィードを確認する {#view-a-changefeed} @@ -62,9 +62,9 @@ TiDB Cloud changefeed を使用すると、TiDB Cloudから他のデータサー
-1. ターゲットのTiDB Cloud Essentialインスタンスの[**Changefeed**](#view-the-changefeed-page)ページに移動します。 -2. 表示したい該当する変更フィードを見つけて、 **Action**列の**...** > **View**をクリックします。 -3. 変更フィードの詳細（設定、ステータス、メトリクスなど）を確認できます。 +1. ターゲットのTiDB Cloud Essentialインスタンスの[**Changefeed**](#view-the-changefeed-page)ページに移動します。 +2. 表示したい該当する変更フィードを見つけて、 **Action**列の**...** > **View**をクリックします。 +3. 変更フィードの詳細（設定、ステータス、メトリクスなど）を確認できます。
@@ -86,8 +86,8 @@ TiDB CloudコンソールまたはTiDB Cloud CLIを使用して、変更フィ
-1. ターゲットのTiDB Cloud Essentialインスタンスの[**Changefeed**](#view-the-changefeed-page)ページに移動します。 -2. 一時停止または再開したい該当する変更フィードを見つけて、 **Action**列の**...** > **Pause/Resume**をクリックします。 +1. ターゲットのTiDB Cloud Essentialインスタンスの[**Changefeed**](#view-the-changefeed-page)ページに移動します。 +2. 一時停止または再開したい該当する変更フィードを見つけて、 **Action**列の**...** > **Pause/Resume**をクリックします。
@@ -119,18 +119,18 @@ ticloud serverless changefeed resume -c --changefeed-id
-1. ターゲットのTiDB Cloud Essentialインスタンスの[**Changefeed**](#view-the-changefeed-page)ページに移動します。 +1. ターゲットのTiDB Cloud Essentialインスタンスの[**Changefeed**](#view-the-changefeed-page)ページに移動します。 -2. 一時停止したい変更フィードを見つけて、 **Action**列の**...** > **Pause**をクリックします。 +2. 一時停止したい変更フィードを見つけて、 **Action**列の**...** > **Pause**をクリックします。 -3. 変更フィードのステータスが`Paused`に変更されたら、 **...** > **Edit**をクリックして、対応する変更フィードを編集します。 +3. 変更フィードのステータスが`Paused`に変更されたら、 **...** > **Edit**をクリックして、対応する変更フィードを編集します。 TiDB Cloudはデフォルトで変更フィードの設定を自動的に行います。以下の設定を変更できます。 - - Apache Kafkaシンク：**Destination**、**Connection**、**Start Position**を除くすべての設定 - - MySQLシンク：**Destination**、**Connection**、**Start Position**を除くすべての設定 + - Apache Kafkaシンク：**Destination**、**Connection**、**Start Position**を除くすべての設定 + - MySQLシンク：**Destination**、**Connection**、**Start Position**を除くすべての設定 -4. 設定を編集した後、 **...** > **Resume**をクリックして、対応する変更フィードを再開します。 +4. 設定を編集した後、 **...** > **Resume**をクリックして、対応する変更フィードを再開します。
@@ -153,10 +153,10 @@ ticloud serverless changefeed edit --cluster-id --changefeed-id
-1. ターゲットのTiDB Cloud Essentialインスタンスの[**Changefeed**](#view-the-changefeed-page)ページに移動します。 -2. 削除したい変更フィードを見つけて、 **Action**列の**...** > **Delete**をクリックします。 +1. ターゲットのTiDB Cloud Essentialインスタンスの[**Changefeed**](#view-the-changefeed-page)ページに移動します。 +2. 削除したい変更フィードを見つけて、 **Action**列の**...** > **Delete**をクリックします。
@@ -193,9 +193,9 @@ ticloud serverless changefeed delete --cluster-id --changefeed-id < 各州は以下のように説明されます。 -- `CREATING` : 変更フィードが作成されています。 -- `CREATE_FAILED` : 変更フィードの作成に失敗しました。変更フィードを削除して、新しいものを作成する必要があります。 -- `RUNNING` : changefeed は正常に実行され、checkpoint-ts も正常に進行します。 -- `PAUSED` : 変更フィードが一時停止されています。 -- `WARNING` : 変更フィードが警告を返します。回復可能なエラーのため、変更フィードは続行できません。この状態の変更フィードは、状態が`RUNNING`に遷移するまで再開を試み続けます。この状態の変更フィードは[GCオペレーション](https://docs.pingcap.com/tidb/stable/garbage-collection-overview)ブロックします 。 -- `RUNNING_FAILED` : 変更フィードが失敗しました。何らかのエラーにより、変更フィードを再開できず、自動的に復旧することもできません。増分データのガベージコレクション(GC) の前に問題が解決された場合は、失敗した変更フィードを手動で再開できます。増分データのデフォルトの有効期限 (TTL) は 24 時間です。つまり、変更フィードが中断されてから 24 時間以内に GC メカニズムによってデータが削除されることはありません。 +- `CREATING` : 変更フィードが作成されています。 +- `CREATE_FAILED` : 変更フィードの作成に失敗しました。変更フィードを削除して、新しいものを作成する必要があります。 +- `RUNNING` : changefeed は正常に実行され、checkpoint-ts も正常に進行します。 +- `PAUSED` : 変更フィードが一時停止されています。 +- `WARNING` : 変更フィードが警告を返します。回復可能なエラーのため、変更フィードは続行できません。この状態の変更フィードは、状態が`RUNNING`に遷移するまで再開を試み続けます。この状態の変更フィードは[GCオペレーション](https://docs.pingcap.com/tidb/stable/garbage-collection-overview)ブロックします 。 +- `RUNNING_FAILED` : 変更フィードが失敗しました。何らかのエラーにより、変更フィードを再開できず、自動的に復旧することもできません。増分データのガベージコレクション(GC) の前に問題が解決された場合は、失敗した変更フィードを手動で再開できます。増分データのデフォルトの有効期限 (TTL) は 24 時間です。つまり、変更フィードが中断されてから 24 時間以内に GC メカニズムによってデータが削除されることはありません。 diff --git a/tidb-cloud/essential-changefeed-sink-to-kafka.md b/tidb-cloud/essential-changefeed-sink-to-kafka.md index ba7a3ff0b27f7..6f2685b442ce1 100644 --- a/tidb-cloud/essential-changefeed-sink-to-kafka.md +++ b/tidb-cloud/essential-changefeed-sink-to-kafka.md @@ -11,31 +11,31 @@ summary: このドキュメントでは、TiDB Cloud Essentialから Apache Kafk > > 現在、 TiDB Cloud Essentialの変更フィード機能はリクエストに応じてのみ利用可能です。この機能をリクエストするには、以下の手順に従ってください。 > -> 1. [TiDB Cloudコンソール](https://tidbcloud.com)の右下隅にある?をクリックします**。** 。 -> 2. **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。 -> 3. チケットを作成します。「説明」欄に「changefeedへの申請」と入力します。 -> 4. **Submit**をクリックしてください。 +> 1. [TiDB Cloudコンソール](https://tidbcloud.com)の右下隅にある?をクリックします**。** 。 +> 2. **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。 +> 3. チケットを作成します。「説明」欄に「changefeedへの申請」と入力します。 +> 4. **Submit**をクリックしてください。 ## 制限 {#restrictions} -- TiDB Cloud Essentialインスタンスごとに、最大10個の変更フィードを作成できます。 -- 現在、 TiDB Cloud Essentialは、Kafkaブローカーへの接続に自己署名TLS証明書をアップロードすることをサポートしていません。 -- TiDB Cloud EssentialはTiCDCを使用して変更フィードを確立するため、同じ[TiCDCの制限](https://docs.pingcap.com/tidb/stable/ticdc-overview#unsupported-scenarios)があります。 -- 複製対象のテーブルに主キーまたはNULLを許容しない一意インデックスがない場合、複製中に一意制約が存在しないことで、一部の再試行シナリオにおいて、ターゲットで重複データが挿入される可能性があります。 +- TiDB Cloud Essentialインスタンスごとに、最大10個の変更フィードを作成できます。 +- 現在、 TiDB Cloud Essentialは、Kafkaブローカーへの接続に自己署名TLS証明書をアップロードすることをサポートしていません。 +- TiDB Cloud EssentialはTiCDCを使用して変更フィードを確立するため、同じ[TiCDCの制限](https://docs.pingcap.com/tidb/stable/ticdc-overview#unsupported-scenarios)があります。 +- 複製対象のテーブルに主キーまたはNULLを許容しない一意インデックスがない場合、複製中に一意制約が存在しないことで、一部の再試行シナリオにおいて、ターゲットで重複データが挿入される可能性があります。 ## 前提条件 {#prerequisites} Apache Kafkaにデータをストリーミングするためのチェンジフィードを作成する前に、以下の前提条件を満たす必要があります。 -- ネットワーク接続を設定する -- Kafka ACL認証の権限を追加する +- ネットワーク接続を設定する +- Kafka ACL認証の権限を追加する ### ネットワーク {#network} TiDB Cloud EssentialインスタンスがApache Kafkaサービスに接続できることを確認してください。接続方法は以下のいずれかを選択できます。 -- プライベートリンク接続：セキュリティコンプライアンスを満たし、ネットワーク品質を確保します。 -- 公共ネットワーク：迅速なセットアップに適しています。 +- プライベートリンク接続：セキュリティコンプライアンスを満たし、ネットワーク品質を確保します。 +- 公共ネットワーク：迅速なセットアップに適しています。
@@ -46,10 +46,10 @@ TiDB Cloud Essentialは現在、セルフホスト型Kafka、Confluent Cloud Ded Kafkaのデプロイメントとクラウドプロバイダーに基づいてプライベートリンク接続を設定するには、以下のガイドを参照してください。 -- [プライベートリンク接続を介してAWS上のConfluent Cloudに接続します](/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md) -- [プライベートリンク接続を介してAWSセルフホスト型Kafkaに接続します](/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md) -- [プライベートリンク接続を介してAlibaba Cloudセルフホスト型Kafkaに接続する](/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md) -- [プライベートリンク接続を介してAmazon MSK Provisionedに接続します](/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md) +- [プライベートリンク接続を介してAWS上のConfluent Cloudに接続します](/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md) +- [プライベートリンク接続を介してAWSセルフホスト型Kafkaに接続します](/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md) +- [プライベートリンク接続を介してAlibaba Cloudセルフホスト型Kafkaに接続する](/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md) +- [プライベートリンク接続を介してAmazon MSK Provisionedに接続します](/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md)
@@ -66,16 +66,16 @@ Apache Kafkaサービスへのパブリックアクセスを提供する場合 TiDB Cloud Essential の変更フィードが Apache Kafka にデータをストリーミングし、Kafka トピックを自動的に作成できるようにするには、Kafka に次の権限が追加されていることを確認してください。 -- Kafka のトピック リソース タイプに`Create`および`Write`権限が追加されます。 -- Kafka のクラスタ リソース タイプに`DescribeConfigs`権限が追加されます。 +- 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/security/authorization/acls/manage-acls.html#add-acls)を参照してください。 ## ステップ1. Apache Kafka の変更フィードを作成する {#step-1-create-a-changefeed-for-apache-kafka} -1. [TiDB Cloudコンソール](https://tidbcloud.com)にログインします。 -2. 対象のTiDB Cloud Essentialインスタンスの概要ページに移動し、左側のナビゲーションペインで**Data** > **Changefeed**をクリックします。 -3. **Create Changefeed**をクリックし、次に**Destination**として**Kafka**を選択します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)にログインします。 +2. 対象のTiDB Cloud Essentialインスタンスの概要ページに移動し、左側のナビゲーションペインで**Data** > **Changefeed**をクリックします。 +3. **Create Changefeed**をクリックし、次に**Destination**として**Kafka**を選択します。 ## ステップ2. changefeedターゲットを設定する {#step-2-configure-the-changefeed-target} @@ -84,130 +84,130 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト
-1. **Connectivity Method**で**Public**を選択し、Kafkaブローカーのエンドポイントを入力します。複数のエンドポイントはカンマ`,`を使用して区切ることができます。 +1. **Connectivity Method**で**Public**を選択し、Kafkaブローカーのエンドポイントを入力します。複数のエンドポイントはカンマ`,`を使用して区切ることができます。 -2. Kafkaの認証設定に応じて、**Authentication**オプションを選択してください。 +2. Kafkaの認証設定に応じて、**Authentication**オプションを選択してください。 - - Kafkaで認証が必要ない場合は、デフォルトオプションの**Disable**のままにしてください。 - - Kafkaで認証が必要な場合は、該当する認証タイプを選択し、認証に使用するKafkaアカウントの**user name**と**パスワード**を入力してください。 + - Kafkaで認証が必要ない場合は、デフォルトオプションの**Disable**のままにしてください。 + - Kafkaで認証が必要な場合は、該当する認証タイプを選択し、認証に使用するKafkaアカウントの**user name**と**パスワード**を入力してください。 -3. **Kafka Version**については、ご使用のKafkaのバージョンに基づいて、 **Kafka v2**または**Kafka v3**を選択してください。 +3. **Kafka Version**については、ご使用のKafkaのバージョンに基づいて、 **Kafka v2**または**Kafka v3**を選択してください。 -4. この変更フィード内のデータの**Compression**タイプを選択してください。 +4. この変更フィード内のデータの**Compression**タイプを選択してください。 -5. Kafkaで**TLS Encryption**オプションを有効にしてください。 +5. Kafkaで**TLS Encryption**オプションを有効にしてください。 -6. **Next**をクリックしてネットワーク接続をテストしてください。テストが成功すると、次のページに移動します。 +6. **Next**をクリックしてネットワーク接続をテストしてください。テストが成功すると、次のページに移動します。
-1. **Connectivity Method**で**Private Link**を選択します。 +1. **Connectivity Method**で**Private Link**を選択します。 -2. **Private Link Connection**で、[ネットワーク](#network)セクションで作成したプライベートリンク接続を選択します。プライベートリンク接続のアベイラビリティゾーンが、Kafkaデプロイメントのアベイラビリティゾーンと一致していることを確認してください。 +2. **Private Link Connection**で、[ネットワーク](#network)セクションで作成したプライベートリンク接続を選択します。プライベートリンク接続のアベイラビリティゾーンが、Kafkaデプロイメントのアベイラビリティゾーンと一致していることを確認してください。 -3. [ネットワーク](#network)セクションで取得した**Bootstrap Port**を入力してください。Amazon MSKプロビジョニング済みプライベートリンク接続を使用している場合は、このフィールドはスキップできます。 +3. [ネットワーク](#network)セクションで取得した**Bootstrap Port**を入力してください。Amazon MSKプロビジョニング済みプライベートリンク接続を使用している場合は、このフィールドはスキップできます。 -4. Kafkaの認証設定に応じて、**Authentication**オプションを選択してください。 +4. Kafkaの認証設定に応じて、**Authentication**オプションを選択してください。 - - Kafkaで認証が必要ない場合は、デフォルトオプションの**Disable**のままにしてください。 - - Kafkaで認証が必要な場合は、該当する認証タイプを選択し、認証に使用するKafkaアカウントの**user name**と**パスワード**を入力してください。 + - Kafkaで認証が必要ない場合は、デフォルトオプションの**Disable**のままにしてください。 + - Kafkaで認証が必要な場合は、該当する認証タイプを選択し、認証に使用するKafkaアカウントの**user name**と**パスワード**を入力してください。 -5. **Kafka Version**については、ご使用のKafkaのバージョンに基づいて、 **Kafka v2**または**Kafka v3**を選択してください。 +5. **Kafka Version**については、ご使用のKafkaのバージョンに基づいて、 **Kafka v2**または**Kafka v3**を選択してください。 -6. この変更フィード内のデータの**Compression**タイプを選択してください。 +6. この変更フィード内のデータの**Compression**タイプを選択してください。 -7. Kafkaで**TLS Encryption**オプションを有効にしてください。 +7. Kafkaで**TLS Encryption**オプションを有効にしてください。 -8. KafkaでTLS SNI検証が必要な場合は、 **TLS Server Name**を入力してください。例： `Confluent Cloud Dedicated clusters` 。 +8. KafkaでTLS SNI検証が必要な場合は、 **TLS Server Name**を入力してください。例： `Confluent Cloud Dedicated clusters` 。 -9. **Next**をクリックしてネットワーク接続をテストしてください。テストが成功すると、次のページに移動します。 +9. **Next**をクリックしてネットワーク接続をテストしてください。テストが成功すると、次のページに移動します。
## ステップ3．チェンジフィードを設定する {#step-3-set-the-changefeed} -1. **Table Filter**カスタマイズして、複製するテーブルをフィルターします。ルールの構文については、 [テーブルフィルタルール](https://docs.pingcap.com/tidb/stable/table-filter/#syntax)を参照してください。 +1. **Table Filter**カスタマイズして、複製するテーブルをフィルターします。ルールの構文については、 [テーブルフィルタルール](https://docs.pingcap.com/tidb/stable/table-filter/#syntax)を参照してください。 - - **Replication Scope**：有効なキーを持つテーブルのみをレプリケートするか、選択したすべてのテーブルをレプリケートするかを選択できます。 - - **Filter Rules**：この列でフィルタルールを設定できます。デフォルトでは、すべてのテーブルを複製するルール`*.*`が設定されています。新しいルールを追加して**Apply**をクリックすると、 TiDB Cloud はTiDB 内のすべてのテーブルをクエリし、**Filter results**の下にルールに一致するテーブルのみを表示します。 - - **Case Sensitive**：フィルタルールにおけるデータベース名とテーブル名の照合において、大文字小文字を区別するかどうかを設定できます。デフォルトでは、大文字小文字は区別されません。 - - **有効なキーで結果をフィルタリングする**：この列には、主キーや一意インデックスなど、有効なキーを持つテーブルが表示されます。 - - **有効なキーのない結果をフィルタリングする**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタ ルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`test.tbl1`を使用して、テーブル`"!test.tbl1"`を除外できます。 + - **Replication Scope**：有効なキーを持つテーブルのみをレプリケートするか、選択したすべてのテーブルをレプリケートするかを選択できます。 + - **Filter Rules**：この列でフィルタルールを設定できます。デフォルトでは、すべてのテーブルを複製するルール`*.*`が設定されています。新しいルールを追加して**Apply**をクリックすると、 TiDB Cloud はTiDB 内のすべてのテーブルをクエリし、**Filter results**の下にルールに一致するテーブルのみを表示します。 + - **Case Sensitive**：フィルタルールにおけるデータベース名とテーブル名の照合において、大文字小文字を区別するかどうかを設定できます。デフォルトでは、大文字小文字は区別されません。 + - **有効なキーで結果をフィルタリングする**：この列には、主キーや一意インデックスなど、有効なキーを持つテーブルが表示されます。 + - **有効なキーのない結果をフィルタリングする**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタ ルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`test.tbl1`を使用して、テーブル`"!test.tbl1"`を除外できます。 -2. **Event Filter**をカスタマイズして、複製したいイベントを絞り込みます。 +2. **Event Filter**をカスタマイズして、複製したいイベントを絞り込みます。 - - **Tables matching**：この列では、イベントフィルターを適用するテーブルを設定できます。ルールの構文は、前の**Table Filter**領域で使用されているものと同じです。 - - **Event Filter**：無視したいイベントを選択できます。 + - **Tables matching**：この列では、イベントフィルターを適用するテーブルを設定できます。ルールの構文は、前の**Table Filter**領域で使用されているものと同じです。 + - **Event Filter**：無視したいイベントを選択できます。 -3. **Column Selector**カスタマイズして、イベントから列を選択し、選択した列に関連するデータ変更のみを下流に送信します。 +3. **Column Selector**カスタマイズして、イベントから列を選択し、選択した列に関連するデータ変更のみを下流に送信します。 - - **Tables matching**：列セレクターを適用するテーブルを指定します。どのルールにも一致しないテーブルの場合、すべての列が送信されます。 - - **Column Selector**：一致したテーブルのどの列をダウンストリームに送信するかを指定します。 + - **Tables matching**：列セレクターを適用するテーブルを指定します。どのルールにも一致しないテーブルの場合、すべての列が送信されます。 + - **Column Selector**：一致したテーブルのどの列をダウンストリームに送信するかを指定します。 マッチングルールの詳細については、 [カラムセレクター](https://docs.pingcap.com/tidb/stable/ticdc-sink-to-kafka/#column-selectors)を参照してください。 -4. **Data Format**領域で、希望するKafkaメッセージのフォーマットを選択してください。 +4. **Data Format**領域で、希望するKafkaメッセージのフォーマットを選択してください。 - - Avroは、コンパクトで高速なバイナリデータフォーマットであり、豊富なデータ構造を備え、様々なフローシステムで広く利用されています。詳細については、 [Avroデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-avro-protocol)を参照してください。 - - Canal-JSONは、解析が容易なプレーンなJSONテキスト形式です。詳細については、 [Canal-JSONデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-canal-json)を参照してください。 - - オープン プロトコルは、監視、キャッシュ、全文インデックス作成、分析エンジン、および異なるデータベース間のプライマリとセカンダリのレプリケーションのためのデータ ソースを提供する行レベルのデータ変更通知プロトコルです。詳細については、 [オープンプロトコルデータフォーマット](https://docs.pingcap.com/tidb/stable/ticdc-open-protocol)を参照してください。 - - Debeziumは、データベースの変更をキャプチャするためのツールです。キャプチャされた各データベース変更を「イベント」と呼ばれるメッセージに変換し、これらのイベントをKafkaに送信します。詳細については、 [Debeziumデータ形式](https://docs.pingcap.com/tidb/stable/ticdc-debezium)を参照してください。 + - 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)を参照してください。 -5. TiDB拡張フィールドをKafkaメッセージ本文に追加する場合は、 **TiDB Extension**オプションを有効にしてください。 +5. TiDB拡張フィールドをKafkaメッセージ本文に追加する場合は、 **TiDB Extension**オプションを有効にしてください。 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固有の設定項目が表示されます。これらの設定項目は、以下のように入力できます。 +6. データ形式として**Avro**を選択すると、ページにAvro固有の設定項目が表示されます。これらの設定項目は、以下のように入力できます。 - - **Decimal**および**Unsigned BigInt**の設定では、 TiDB CloudがKafkaメッセージ内のdecimal型およびunsigned bigint型のデータ型をどのように処理するかを指定します。 - - **Schema Registry**領域で、スキーマレジストリのエンドポイントを入力します。**HTTP Authentication**を有効にする場合は、ユーザー名とパスワードを入力します。 + - **Decimal**および**Unsigned BigInt**の設定では、 TiDB CloudがKafkaメッセージ内のdecimal型およびunsigned bigint型のデータ型をどのように処理するかを指定します。 + - **Schema Registry**領域で、スキーマレジストリのエンドポイントを入力します。**HTTP Authentication**を有効にする場合は、ユーザー名とパスワードを入力します。 -7. **Topic Distribution**エリアで配信モードを選択し、選択したモードに応じてトピック名の設定を入力します。 +7. **Topic Distribution**エリアで配信モードを選択し、選択したモードに応じてトピック名の設定を入力します。 データ形式として**Avro**を選択した場合、 **Distribution Mode**ドロップダウンリストでは**[テーブルごとの変更ログをKafkaトピックに配信する]**モードのみを選択できます。 配信モードは、変更フィードがKafkaトピックを作成する方法を制御します。テーブルごと、データベースごと、またはすべての変更ログに対して1つのトピックを作成するかを選択できます。 - - **テーブルごとに変更ログをKafkaトピックに配信する** + - **テーブルごとに変更ログをKafkaトピックに配信する** 変更フィードでテーブルごとに専用のKafkaトピックを作成する場合は、このモードを選択します。そうすると、テーブルのすべてのKafkaメッセージが専用のKafkaトピックに送信されます。トピックのプレフィックス、データベース名とテーブル名の間の区切り文字、およびサフィックスを設定することで、テーブルのトピック名をカスタマイズできます。たとえば、区切り文字を`_`に設定すると、トピック名は`_`の形式になります。 スキーマ作成イベントなど、行以外のイベントの変更ログについては、 **Default Topic Name**フィールドにトピック名を指定できます。変更フィードは、指定されたトピックに基づいて、これらの変更ログを収集するためのトピックを作成します。 - - **データベースごとに変更ログをKafkaトピックに配信する** + - **データベースごとに変更ログをKafkaトピックに配信する** 変更フィードでデータベースごとに専用のKafkaトピックを作成する場合は、このモードを選択してください。そうすると、データベースのすべてのKafkaメッセージが専用のKafkaトピックに送信されます。トピックのプレフィックスとサフィックスを設定することで、データベースのトピック名をカスタマイズできます。 解決済みTsイベントなど、行以外のイベントの変更ログについては、 **Default Topic Name**フィールドにトピック名を指定できます。変更フィードは、指定されたトピックに基づいて、これらの変更ログを収集するためのトピックを作成します。 - - **すべての変更ログを、指定された1つのKafkaトピックに送信する** + - **すべての変更ログを、指定された1つのKafkaトピックに送信する** 変更フィードで全ての変更ログに対して1つのKafkaトピックを作成する場合は、このモードを選択してください。そうすると、変更フィード内のすべてのKafkaメッセージが1つのKafkaトピックに送信されます。トピック名は**Topic Name**フィールドで指定できます。 -8. **Partition Distribution**領域では、Kafkaメッセージの送信先パーティションを決定できます。**すべてのテーブルに対して単一のパーティションディスパッチャを**定義することも、**テーブルごとに異なるパーティションディスパッチャを**定義することもできます。TiDB Cloudは、次の4種類のディスパッチャを提供しています。 +8. **Partition Distribution**領域では、Kafkaメッセージの送信先パーティションを決定できます。**すべてのテーブルに対して単一のパーティションディスパッチャを**定義することも、**テーブルごとに異なるパーティションディスパッチャを**定義することもできます。TiDB Cloudは、次の4種類のディスパッチャを提供しています。 - - **主キーまたはインデックス値に基づいて変更ログをKafkaパーティションに分散します。** + - **主キーまたはインデックス値に基づいて変更ログをKafkaパーティションに分散します。** 変更フィードでテーブルのKafkaメッセージを異なるパーティションに送信する場合は、この分散方法を選択してください。行の変更ログの主キーまたはインデックス値によって、変更ログの送信先パーティションが決まります。主キーを使用する場合は、 **Index Name**フィールドを空のままにしてください。この分散方法は、パーティションのバランスを改善し、行レベルの順序性を確保します。 - - **変更ログをテーブルごとにKafkaパーティションに分散する** + - **変更ログをテーブルごとにKafkaパーティションに分散する** 変更フィードによってテーブルのKafkaメッセージを1つのKafkaパーティションに送信する場合は、この分散方法を選択してください。行の変更ログのテーブル名によって、変更ログが送信されるパーティションが決まります。この分散方法はテーブルの順序性を保証しますが、パーティションのバランスが崩れる可能性があります。 - - **変更ログをタイムスタンプに基づいてKafkaパーティションに分散する** + - **変更ログをタイムスタンプに基づいてKafkaパーティションに分散する** 変更フィードがKafkaメッセージをランダムに異なるKafkaパーティションに送信するようにするには、この分散方法を選択してください。行の変更ログの commitTs によって、変更ログが送信されるパーティションが決まります。この分散方法は、パーティションのバランスを改善し、各パーティションの順序性を確保します。ただし、データ項目の複数の変更が異なるパーティションに送信され、異なるコンシューマーのコンシューマー処理の進行状況が異なる場合があり、データの不整合が発生する可能性があります。そのため、コンシューマーは、複数のパーティションからのデータを消費する前に commitTs でソートする必要があります。 - - **変更ログを列の値に基づいてKafkaパーティションに分散する** + - **変更ログを列の値に基づいてKafkaパーティションに分散する** テーブルのKafkaメッセージを異なるパーティションに送信するように変更フィードを設定したい場合は、この配信方法を選択してください。行の変更ログで指定された列の値によって、変更ログの送信先パーティションが決まります。この配信方法は、各パーティション内の順序性を保証し、同じ列値を持つ変更ログが同じパーティションに送信されることを保証します。 -9. **Topic Configuration**領域で、以下の数値を設定してください。changefeedは、これらの数値に基づいてKafkaトピックを自動的に作成します。 +9. **Topic Configuration**領域で、以下の数値を設定してください。changefeedは、これらの数値に基づいてKafkaトピックを自動的に作成します。 - - **Replication Factor**：各KafkaメッセージがレプリケートされるKafkaサーバーの数を制御します。有効な値の範囲は、 [`min.insync.replicas`](https://kafka.apache.org/33/documentation.html#brokerconfigs_min.insync.replicas)からKafkaブローカーの数までです。 - - **Partition Number**：トピックに存在するパーティションの数を制御します。有効な値の範囲は`[1, 10 * the number of Kafka brokers]`です。 + - **Replication Factor**：各KafkaメッセージがレプリケートされるKafkaサーバーの数を制御します。有効な値の範囲は、 [`min.insync.replicas`](https://kafka.apache.org/33/documentation.html#brokerconfigs_min.insync.replicas)からKafkaブローカーの数までです。 + - **Partition Number**：トピックに存在するパーティションの数を制御します。有効な値の範囲は`[1, 10 * the number of Kafka brokers]`です。 10. **Split Event**エリアで、 `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)を参照してください。 @@ -215,6 +215,6 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト ## ステップ4．変更フィードを確認して作成する {#step-4-review-and-create-your-changefeed} -1. **Changefeed Name**欄に、変更フィードの名前を指定します。 -2. 設定した変更フィードの設定をすべて確認してください。必要に応じて**Previous**をクリックして変更してください。 -3. すべての設定が正しければ、 **Submit**をクリックして変更フィードを作成します。 +1. **Changefeed Name**欄に、変更フィードの名前を指定します。 +2. 設定した変更フィードの設定をすべて確認してください。必要に応じて**Previous**をクリックして変更してください。 +3. すべての設定が正しければ、 **Submit**をクリックして変更フィードを作成します。 diff --git a/tidb-cloud/essential-changefeed-sink-to-mysql.md b/tidb-cloud/essential-changefeed-sink-to-mysql.md index 82408faf996c8..0e7fc3a7b087e 100644 --- a/tidb-cloud/essential-changefeed-sink-to-mysql.md +++ b/tidb-cloud/essential-changefeed-sink-to-mysql.md @@ -11,31 +11,31 @@ summary: このドキュメントでは、Sink to MySQL changefeed を使用し > > 現在、 TiDB Cloud Essentialの変更フィード機能はリクエストに応じてのみ利用可能です。この機能をリクエストするには、以下の手順に従ってください。 > -> 1. [TiDB Cloudコンソール](https://tidbcloud.com)の右下隅にある?をクリックします**。** 。 -> 2. **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。 -> 3. チケットを作成します。「説明」欄に「changefeedへの申請」と入力します。 -> 4. **Submit**をクリックしてください。 +> 1. [TiDB Cloudコンソール](https://tidbcloud.com)の右下隅にある?をクリックします**。** 。 +> 2. **Support Tickets**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。 +> 3. チケットを作成します。「説明」欄に「changefeedへの申請」と入力します。 +> 4. **Submit**をクリックしてください。 ## 制限 {#restrictions} -- TiDB Cloud Essentialインスタンスごとに、最大10個のチェンジフィードを作成できます。 -- TiDB Cloud Essential はTiCDC を使用して変更フィードを確立するため、同じ[TiCDCの制限](https://docs.pingcap.com/tidb/stable/ticdc-overview#unsupported-scenarios)があります。 -- 複製対象のテーブルに主キーまたはNULLを許容しない一意インデックスがない場合、複製中に一意制約が存在しないことで、一部の再試行シナリオにおいて、下流で重複データが挿入される可能性があります。 +- TiDB Cloud Essentialインスタンスごとに、最大10個のチェンジフィードを作成できます。 +- TiDB Cloud Essential はTiCDC を使用して変更フィードを確立するため、同じ[TiCDCの制限](https://docs.pingcap.com/tidb/stable/ticdc-overview#unsupported-scenarios)があります。 +- 複製対象のテーブルに主キーまたはNULLを許容しない一意インデックスがない場合、複製中に一意制約が存在しないことで、一部の再試行シナリオにおいて、下流で重複データが挿入される可能性があります。 ## 前提条件 {#prerequisites} 変更フィードを作成する前に、以下の前提条件を満たす必要があります。 -- ネットワーク接続を設定する -- 既存データをエクスポートしてMySQLにロードする（オプション） -- 既存のデータをロードせず、増分データのみをMySQLに複製する場合は、MySQLに対応するターゲットテーブルを作成してください。 +- ネットワーク接続を設定する +- 既存データをエクスポートしてMySQLにロードする（オプション） +- 既存のデータをロードせず、増分データのみをMySQLに複製する場合は、MySQLに対応するターゲットテーブルを作成してください。 ### ネットワーク {#network} TiDB Cloud EssentialインスタンスがMySQLサービスに接続できることを確認してください。接続方法は以下のいずれかを選択できます。 -- プライベートリンク接続：セキュリティコンプライアンスを満たし、ネットワーク品質を確保します。 -- 公共ネットワーク：迅速なセットアップに適しています。 +- プライベートリンク接続：セキュリティコンプライアンスを満たし、ネットワーク品質を確保します。 +- 公共ネットワーク：迅速なセットアップに適しています。
@@ -60,10 +60,10 @@ MySQLサービスがパブリックネットワーク経由でアクセスでき 既存のデータを読み込むには： -1. [`tidb_gc_life_time`](https://docs.pingcap.com/tidb/stable/system-variables#tidb_gc_life_time-new-in-v50)を以下の2つの操作の合計時間よりも長く設定することで、この期間中の履歴データがTiDBによってガベージ コレクションされないようにします。 +1. [`tidb_gc_life_time`](https://docs.pingcap.com/tidb/stable/system-variables#tidb_gc_life_time-new-in-v50)を以下の2つの操作の合計時間よりも長く設定することで、この期間中の履歴データがTiDBによってガベージ コレクションされないようにします。 - - 既存データのエクスポートとインポートにかかる時間 - - **Sink to MySQL**を作成する時間 + - 既存データのエクスポートとインポートにかかる時間 + - **Sink to MySQL**を作成する時間 例えば： @@ -71,9 +71,9 @@ MySQLサービスがパブリックネットワーク経由でアクセスでき SET GLOBAL tidb_gc_life_time = '72h'; ``` -2. [エクスポート](/tidb-cloud/serverless-export.md)機能を使用してTiDB Cloud Essentialインスタンスからデータをエクスポートし、その後、 [mydumper/myloader](https://centminmod.com/mydumper.html)などのコミュニティツールを使用してデータをMySQLサービスにロードします。 +2. [エクスポート](/tidb-cloud/serverless-export.md)機能を使用してTiDB Cloud Essentialインスタンスからデータをエクスポートし、その後、 [mydumper/myloader](https://centminmod.com/mydumper.html)などのコミュニティツールを使用してデータをMySQLサービスにロードします。 -3. [エクスポート](/tidb-cloud/serverless-export.md)によって返されるスナップショットの時刻を記録してください。このタイムスタンプを、MySQLシンクを設定する際の開始位置として使用してください。 +3. [エクスポート](/tidb-cloud/serverless-export.md)によって返されるスナップショットの時刻を記録してください。このタイムスタンプを、MySQLシンクを設定する際の開始位置として使用してください。 ### MySQLでターゲットテーブルを作成する {#create-target-tables-in-mysql} @@ -83,41 +83,41 @@ MySQLサービスがパブリックネットワーク経由でアクセスでき 前提条件を満たしたら、データをMySQLに取り込むことができます。 -1. 対象のTiDB Cloud Essentialインスタンスの概要ページに移動し、左側のナビゲーションペインで**Data** > **Changefeed**をクリックします。 +1. 対象のTiDB Cloud Essentialインスタンスの概要ページに移動し、左側のナビゲーションペインで**Data** > **Changefeed**をクリックします。 -2. **Create Changefeed**をクリックし、**宛先**として**MySQL**を選択します。 +2. **Create Changefeed**をクリックし、**宛先**として**MySQL**を選択します。 -3. **Connectivity Method**で、MySQLサービスへの接続方法を選択してください。 +3. **Connectivity Method**で、MySQLサービスへの接続方法を選択してください。 - - **Public**を選択した場合は、MySQLエンドポイントを入力してください。 - - **Private Link**を選択した場合は、[ネットワーク](#network)セクションで作成したプライベートリンク接続を選択し、MySQLサービスのMySQLポートを入力してください。 + - **Public**を選択した場合は、MySQLエンドポイントを入力してください。 + - **Private Link**を選択した場合は、[ネットワーク](#network)セクションで作成したプライベートリンク接続を選択し、MySQLサービスのMySQLポートを入力してください。 -4. **Authentication**画面で、MySQLユーザー名とパスワードを入力し、MySQLサービスのTLS暗号化を設定してください。現在、 TiDB CloudはMySQL TLS接続における自己署名証明書をサポートしていません。 +4. **Authentication**画面で、MySQLユーザー名とパスワードを入力し、MySQLサービスのTLS暗号化を設定してください。現在、 TiDB CloudはMySQL TLS接続における自己署名証明書をサポートしていません。 -5. **Next**をクリックして、TiDBがMySQLに正常に接続できるかどうかをテストしてください。 +5. **Next**をクリックして、TiDBがMySQLに正常に接続できるかどうかをテストしてください。 - - はいの場合、次の設定手順に進みます。 - - そうでない場合は、接続エラーが表示されますので、エラーを処理してください。エラーが解決したら、もう一度**Next**をクリックしてください。 + - はいの場合、次の設定手順に進みます。 + - そうでない場合は、接続エラーが表示されますので、エラーを処理してください。エラーが解決したら、もう一度**Next**をクリックしてください。 -6. **Table Filter**カスタマイズして、複製するテーブルをフィルターします。ルールの構文については、 [テーブルフィルタルール](https://docs.pingcap.com/tidb/stable/table-filter/#syntax)を参照してください。 +6. **Table Filter**カスタマイズして、複製するテーブルをフィルターします。ルールの構文については、 [テーブルフィルタルール](https://docs.pingcap.com/tidb/stable/table-filter/#syntax)を参照してください。 - - **Replication Scope**：有効なキーを持つテーブルのみをレプリケートするか、選択したすべてのテーブルをレプリケートするかを選択できます。 - - **Filter Rules**：この列でフィルタルールを設定できます。デフォルトでは、すべてのテーブルを複製するルール`*.*`が設定されています。新しいルールを追加して**Apply**をクリックすると、 TiDB Cloud はTiDB 内のすべてのテーブルをクエリし、**Filter results**の下にルールに一致するテーブルのみを表示します。 - - **Case Sensitive**：フィルタルールにおけるデータベース名とテーブル名の照合において、大文字小文字を区別するかどうかを設定できます。デフォルトでは、大文字小文字は区別されません。 - - **有効なキーで結果をフィルタリングする**：この列には、主キーや一意インデックスなど、有効なキーを持つテーブルが表示されます。 - - **有効なキーのない結果をフィルタリングする**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタ ルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`test.tbl1`を使用して、テーブル`"!test.tbl1"`を除外できます。 + - **Replication Scope**：有効なキーを持つテーブルのみをレプリケートするか、選択したすべてのテーブルをレプリケートするかを選択できます。 + - **Filter Rules**：この列でフィルタルールを設定できます。デフォルトでは、すべてのテーブルを複製するルール`*.*`が設定されています。新しいルールを追加して**Apply**をクリックすると、 TiDB Cloud はTiDB 内のすべてのテーブルをクエリし、**Filter results**の下にルールに一致するテーブルのみを表示します。 + - **Case Sensitive**：フィルタルールにおけるデータベース名とテーブル名の照合において、大文字小文字を区別するかどうかを設定できます。デフォルトでは、大文字小文字は区別されません。 + - **有効なキーで結果をフィルタリングする**：この列には、主キーや一意インデックスなど、有効なキーを持つテーブルが表示されます。 + - **有効なキーのない結果をフィルタリングする**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタ ルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`test.tbl1`を使用して、テーブル`"!test.tbl1"`を除外できます。 -7. **Event Filter**をカスタマイズして、複製したいイベントを絞り込みます。 +7. **Event Filter**をカスタマイズして、複製したいイベントを絞り込みます。 - - **Tables matching**：この列では、イベントフィルターを適用するテーブルを設定できます。ルールの構文は、前の**Table Filter**領域で使用されているものと同じです。 - - **Event Filter**：無視したいイベントを選択できます。 + - **Tables matching**：この列では、イベントフィルターを適用するテーブルを設定できます。ルールの構文は、前の**Table Filter**領域で使用されているものと同じです。 + - **Event Filter**：無視したいイベントを選択できます。 -8. **Start Replication Position**で、MySQLシンクの開始位置を設定します。 +8. **Start Replication Position**で、MySQLシンクの開始位置を設定します。 - - エクスポートを使用して[既存のデータをロードしました](#load-existing-data-optional)がある場合は、 **From Time**を選択し、エクスポートによって返されたスナップショット時刻を入力します。タイムゾーンが正しいことを確認してください。 - - 上流のTiDB Cloud Essentialインスタンスにデータがない場合は、 **Start replication from now on**を選択してください。 + - エクスポートを使用して[既存のデータをロードしました](#load-existing-data-optional)がある場合は、 **From Time**を選択し、エクスポートによって返されたスナップショット時刻を入力します。タイムゾーンが正しいことを確認してください。 + - 上流のTiDB Cloud Essentialインスタンスにデータがない場合は、 **Start replication from now on**を選択してください。 -9. **Next**をクリックして変更フィードを設定してください。 +9. **Next**をクリックして変更フィードを設定してください。 **Changefeed Name**欄に、変更フィードの名前を指定します。 diff --git a/tidb-cloud/essential-database-audit-logging.md b/tidb-cloud/essential-database-audit-logging.md index 87ff7a0ce35e7..907b1b1d0439c 100644 --- a/tidb-cloud/essential-database-audit-logging.md +++ b/tidb-cloud/essential-database-audit-logging.md @@ -36,26 +36,26 @@ INSERT INTO `test`.`users` (`id`, `name`, `password`) VALUES ( ... ); TiDB Cloud Essentialは、以下のいずれかの条件が満たされた場合に新しい監査ログファイルを生成します。 -- 現在のログファイルがローテーションサイズ（デフォルトでは100MiB）に達しました。 -- 前回のログ生成から、ローテーション間隔（デフォルトでは1時間）が経過しました。内部スケジューリングメカニズムによっては、ログ生成が数分遅れる場合があります。 +- 現在のログファイルがローテーションサイズ（デフォルトでは100MiB）に達しました。 +- 前回のログ生成から、ローテーション間隔（デフォルトでは1時間）が経過しました。内部スケジューリングメカニズムによっては、ログ生成が数分遅れる場合があります。 ## 監査ログの場所 {#audit-logging-locations} 監査ログは以下の場所に保存できます。 -- [Amazon S3](https://aws.amazon.com/s3/) -- [Google Cloud Storage](https://cloud.google.com/storage) -- [Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/) -- [Alibaba Cloudオブジェクトストレージサービス（OSS）](https://www.alibabacloud.com/product/oss) +- [Amazon S3](https://aws.amazon.com/s3/) +- [Google Cloud Storage](https://cloud.google.com/storage) +- [Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/) +- [Alibaba Cloudオブジェクトストレージサービス（OSS）](https://www.alibabacloud.com/product/oss) ### Amazon S3 {#amazon-s3} 監査ログをAmazon S3に保存するには、以下の情報を提供する必要があります。 -- URI: `s3:////` -- アクセス認証情報：以下のいずれかを選択してください。 - - `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でホストされているクラスターのみでサポートされています。 +- URI: `s3:////` +- アクセス認証情報：以下のいずれかを選択してください。 + - `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)を参照してください。 @@ -63,8 +63,8 @@ TiDB Cloud Essentialは、以下のいずれかの条件が満たされた場合 監査ログをGoogle Cloud Storageに保存するには、以下の情報を提供する必要があります。 -- URI: `gs:////` -- アクセス資格情報: `storage.objects.create`および`storage.objects.delete`権限を持つサービス[サービスアカウントキー](https://cloud.google.com/iam/docs/creating-managing-service-account-keys)。 +- 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)を参照してください。 @@ -72,8 +72,8 @@ TiDB Cloud Essentialは、以下のいずれかの条件が満たされた場合 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） ブラウザ。 +- 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)を参照してください。 @@ -81,8 +81,8 @@ Azure Blob Storage に監査ログを保存するには、以下の情報を提 Alibaba Cloud OSSに監査ログを保存するには、以下の情報を提供する必要があります。 -- URI: `oss:////` -- アクセス資格情報: OSS バケットへのデータのエクスポートを許可する`oss:PutObject`および`oss:GetBucketInfo`権限を持つ[アクセスキーペア](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair)キーペア。 +- 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)を参照してください。 @@ -92,12 +92,12 @@ Alibaba Cloud OSSに監査ログを保存するには、以下の情報を提供 フィルタルールには以下のフィールドが含まれます。 -- `users` : 監査イベントをフィルタリングするためのユーザー名のリスト。ワイルドカード`%`を使用すると、任意のユーザー名に一致させることができます。 -- `filters` : フィルタオブジェクトのリスト。各フィルタオブジェクトには、次のフィールドが含まれます。 +- `users` : 監査イベントをフィルタリングするためのユーザー名のリスト。ワイルドカード`%`を使用すると、任意のユーザー名に一致させることができます。 +- `filters` : フィルタオブジェクトのリスト。各フィルタオブジェクトには、次のフィールドが含まれます。 - - `classes` : 監査イベントをフィルタリングするためのイベントクラスのリスト。例: `["QUERY", "EXECUTE"]` 。 - - `tables` : テーブル フィルターのリスト。詳細については、 [テーブルフィルター](https://docs.pingcap.com/tidb/stable/table-filter/)を参照してください。 - - `statusCodes` : 監査イベントをフィルタリングするためのステータスコードのリスト。 `1`は成功、 `0`は失敗を意味します。 + - `classes` : 監査イベントをフィルタリングするためのイベントクラスのリスト。例: `["QUERY", "EXECUTE"]` 。 + - `tables` : テーブル フィルターのリスト。詳細については、 [テーブルフィルター](https://docs.pingcap.com/tidb/stable/table-filter/)を参照してください。 + - `statusCodes` : 監査イベントをフィルタリングするためのステータスコードのリスト。 `1`は成功、 `0`は失敗を意味します。 以下の表は、データベース監査ログにおけるすべてのイベントクラスを示しています。 @@ -141,19 +141,19 @@ TiDB CloudコンソールまたはTiDB Cloud CLIを使用して、 TiDB Cloud Es
-1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Settings** > **DB Audit Logging**をクリックします。 +2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Settings** > **DB Audit Logging**をクリックします。 -3. **DB Audit Logging**ページで、 **Enable**をクリックします。 +3. **DB Audit Logging**ページで、 **Enable**をクリックします。 -4. 監査ログのストレージの場所を選択し、必要な情報を入力します。次に、 **Test Connection and Next**または**Next**をクリックします。利用可能なストレージの場所の詳細については、[監査ログの場所](#audit-logging-locations)を参照してください。 +4. 監査ログのストレージの場所を選択し、必要な情報を入力します。次に、 **Test Connection and Next**または**Next**をクリックします。利用可能なストレージの場所の詳細については、[監査ログの場所](#audit-logging-locations)を参照してください。 -5. **Database Audit Logging Settings**ダイアログで、ログファイルのローテーションとログのマスキング設定を入力し、 **Save**をクリックします。 +5. **Database Audit Logging Settings**ダイアログで、ログファイルのローテーションとログのマスキング設定を入力し、 **Save**をクリックします。
@@ -177,17 +177,17 @@ TiDB Cloud Essentialインスタンスの監査ログは、有効化後に編集
-1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Settings** > **DB Audit Logging**をクリックします。 +2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Settings** > **DB Audit Logging**をクリックします。 -3. **DB Audit Logging**ページで、 **Settings**をクリックします。 +3. **DB Audit Logging**ページで、 **Settings**をクリックします。 -4. **Database Audit Logging Settings**ダイアログで、ログファイルのローテーションまたはログのマスキング設定を更新し、 **Save**をクリックします。 +4. **Database Audit Logging Settings**ダイアログで、ログファイルのローテーションまたはログのマスキング設定を更新し、 **Save**をクリックします。
@@ -209,17 +209,17 @@ TiDB Cloud Essentialインスタンスの監査ログを無効にすることが
-1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Settings** > **DB Audit Logging**をクリックします。 +2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Settings** > **DB Audit Logging**をクリックします。 -3. **DB Audit Logging**ページで、右上隅の**...**をクリックし、次に**Disable**にします。 +3. **DB Audit Logging**ページで、右上隅の**...**をクリックし、次に**Disable**にします。 -4. **Disable DB Audit Logging**ダイアログで、 **Disable**をクリックします。 +4. **Disable DB Audit Logging**ダイアログで、 **Disable**をクリックします。
@@ -245,17 +245,17 @@ ticloud serverless audit-log config update -c --disabled=true
-1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Settings** > **DB Audit Logging**をクリックします。 +2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Settings** > **DB Audit Logging**をクリックします。 -3. **DB Audit Logging**ページで、 **Add Filter Rule**をクリックします。 +3. **DB Audit Logging**ページで、 **Add Filter Rule**をクリックします。 -4. **Add Filter Rule**ダイアログで、 **Filter Name** 、 **SQL Users** 、および**Filter Rule**フィールドに入力し、 **Confirm**をクリックします。これらのフィールドの詳細については、[監査ログフィルタルール](#audit-logging-filter-rules)を参照してください。 +4. **Add Filter Rule**ダイアログで、 **Filter Name** 、 **SQL Users** 、および**Filter Rule**フィールドに入力し、 **Confirm**をクリックします。これらのフィールドの詳細については、[監査ログフィルタルール](#audit-logging-filter-rules)を参照してください。
@@ -275,17 +275,17 @@ ticloud serverless audit-log filter create --cluster-id --display-n
-1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Settings** > **DB Audit Logging**をクリックします。 +2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Settings** > **DB Audit Logging**をクリックします。 -3. **DB Audit Logging**ページで、編集するフィルタルールを見つけ、その行の**...**をクリックしてから、 **Edit**をクリックします。 +3. **DB Audit Logging**ページで、編集するフィルタルールを見つけ、その行の**...**をクリックしてから、 **Edit**をクリックします。 -4. **Edit Filter Rule**ダイアログで、 **Filter Name**または**Filter Rule**フィールドを更新し、 **Confirm**をクリックします。 +4. **Edit Filter Rule**ダイアログで、 **Filter Name**または**Filter Rule**フィールドを更新し、 **Confirm**をクリックします。
@@ -305,15 +305,15 @@ ticloud serverless audit-log filter update --cluster-id --filter-ru
-1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Settings** > **DB Audit Logging**をクリックします。 +2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Settings** > **DB Audit Logging**をクリックします。 -3. **DB Audit Logging**ページで、無効にしたいフィルタルールを見つけ、トグルをオフにしてフィルタルールを無効にします。 +3. **DB Audit Logging**ページで、無効にしたいフィルタルールを見つけ、トグルをオフにしてフィルタルールを無効にします。
@@ -333,17 +333,17 @@ ticloud serverless audit-log filter update --cluster-id --filter-ru
-1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Settings** > **DB Audit Logging**をクリックします。 +2. 対象のTiDB Cloud Essentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Settings** > **DB Audit Logging**をクリックします。 -3. **DB Audit Logging**ページで、削除するフィルタルールを見つけて、 **...**をクリックします。 +3. **DB Audit Logging**ページで、削除するフィルタルールを見つけて、 **...**をクリックします。 -4. **Delete**をクリックし、次に**I understand. Delete it**をクリックしてください。 +4. **Delete**をクリックし、次に**I understand. Delete it**をクリックしてください。
diff --git a/tidb-cloud/explore-data-with-chat2query.md b/tidb-cloud/explore-data-with-chat2query.md index bd2d2f1578140..d7d9d7a5cc8ac 100644 --- a/tidb-cloud/explore-data-with-chat2query.md +++ b/tidb-cloud/explore-data-with-chat2query.md @@ -13,32 +13,32 @@ SQLエディタでは、SQLクエリを手動で記述することも、macOSで SQLエディタの推奨される使用例は以下のとおりです。 -- Chat2QueryのAI機能を活用することで、複雑なSQLクエリを瞬時に生成、デバッグ、または書き換えることができます。 -- TiDBのMySQL互換性を迅速にテストします。 -- TiDBのSQL機能を、独自のデータセットを使って簡単に探索できます。 +- Chat2QueryのAI機能を活用することで、複雑なSQLクエリを瞬時に生成、デバッグ、または書き換えることができます。 +- TiDBのMySQL互換性を迅速にテストします。 +- TiDBのSQL機能を、独自のデータセットを使って簡単に探索できます。 ## 制限事項 {#limitations} -- AIが生成するSQLクエリは100%正確とは限らないため、修正が必要になる場合があります。 -- SQL Editorは、AWS上でホストされている[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)インスタンスでのみ利用可能です。TiDB [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでSQL EditorおよびChat2Queryを使用するには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 +- AIが生成するSQLクエリは100%正確とは限らないため、修正が必要になる場合があります。 +- SQL Editorは、AWS上でホストされている[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)インスタンスでのみ利用可能です。TiDB [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでSQL EditorおよびChat2Queryを使用するには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 ## Access SQL エディター {#access-sql-editor} -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページにアクセスします。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページにアクセスします。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. TiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスタの名前をクリックし、左側のナビゲーションペインで**SQL Editor**をクリックします。 +2. TiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスタの名前をクリックし、左側のナビゲーションペインで**SQL Editor**をクリックします。 > **Note:** > > 以下のケースでは、 **SQL Editor**エントリが灰色で表示され、クリックできません。 > - > - お客様のTiDB Cloud Dedicatedクラスターはv6.5.0より前のバージョンです。SQLエディターを使用するには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にご依頼いただき、クラスターをアップグレードしていただく必要があります。 - > - TiDB Cloud Dedicatedクラスターが作成されたばかりで、SQLエディタの実行環境はまだ準備中です。数分お待ちいただければ、Chat2Queryがご利用いただけるようになります。 - > - TiDB Cloud Dedicatedクラスターは[一時停止](/tidb-cloud/pause-or-resume-tidb-cluster.md)。 + > - お客様のTiDB Cloud Dedicatedクラスターはv6.5.0より前のバージョンです。SQLエディターを使用するには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にご依頼いただき、クラスターをアップグレードしていただく必要があります。 + > - TiDB Cloud Dedicatedクラスターが作成されたばかりで、SQLエディタの実行環境はまだ準備中です。数分お待ちいただければ、Chat2Queryがご利用いただけるようになります。 + > - TiDB Cloud Dedicatedクラスターは[一時停止](/tidb-cloud/pause-or-resume-tidb-cluster.md)。 ## AIによるSQLクエリ生成を有効または無効にする {#enable-or-disable-ai-to-generate-sql-queries} @@ -46,30 +46,30 @@ PingCAP は、ユーザーのデータのプライバシーとセキュリティ Chat2Queryに初めてアクセスすると、PingCAPとAmazon Bedrockがお客様のコードスニペットを使用してサービスを調査および改善することを許可するかどうかを尋ねるダイアログが表示されます。 -- AIがSQLクエリを生成できるようにするには、チェックボックスを選択して**Save and Get Started**をクリックします。 -- AIによるSQLクエリ生成を無効にするには、このダイアログを直接閉じてください。 +- AIがSQLクエリを生成できるようにするには、チェックボックスを選択して**Save and Get Started**をクリックします。 +- AIによるSQLクエリ生成を無効にするには、このダイアログを直接閉じてください。 初回アクセス後も、AI設定は以下のように変更できます。 -- AIを有効にするには、Chat2Queryの右上隅にある**Enable AI power for data exploration**をクリックしてください。 -- AIを無効にするには、 [TiDB Cloudコンソール](https://tidbcloud.com/)の左下隅にあるをクリックします。**Account Settings**をクリックし、 **AI & Privacy**タブをクリックして、 **AI-powered Data Exploration**オプションを無効にします。 +- AIを有効にするには、Chat2Queryの右上隅にある**Enable AI power for data exploration**をクリックしてください。 +- AIを無効にするには、 [TiDB Cloudコンソール](https://tidbcloud.com/)の左下隅にあるをクリックします。**Account Settings**をクリックし、 **AI & Privacy**タブをクリックして、 **AI-powered Data Exploration**オプションを無効にします。 ## SQLクエリを作成して実行する {#write-and-run-sql-queries} SQLエディタでは、独自のデータセットを使用してSQLクエリを作成および実行できます。 -1. SQLクエリを記述します。 +1. SQLクエリを記述します。
macOSの場合： - - AIが有効になっている場合は、 **⌘ + I**を押して指示を入力し、 **Enter**を押すだけで、AIがSQLクエリを自動的に生成します。 + - AIが有効になっている場合は、 **⌘ + I**を押して指示を入力し、 **Enter**を押すだけで、AIがSQLクエリを自動的に生成します。 Chat2Queryによって生成されたSQLクエリの場合、クエリを承認して編集を続けるには**Accept**をクリックしてください。クエリが要件を満たさない場合は、 **Discard**をクリックして拒否してください。または、 **Regenerate**をクリックしてChat2Queryに新しいクエリをリクエストすることもできます。 - - AIが無効になっている場合は、SQLクエリを手動で記述してください。 + - AIが無効になっている場合は、SQLクエリを手動で記述してください。
@@ -77,27 +77,27 @@ SQLエディタでは、独自のデータセットを使用してSQLクエリ WindowsまたはLinuxの場合： - - AIが有効になっている場合は、 **Ctrl + I**を押して指示を入力し、 **Enter**を押すだけで、AIがSQLクエリを自動的に生成します。 + - AIが有効になっている場合は、 **Ctrl + I**を押して指示を入力し、 **Enter**を押すだけで、AIがSQLクエリを自動的に生成します。 Chat2Queryによって生成されたSQLクエリの場合、クエリを承認して編集を続けるには**Accept**をクリックしてください。クエリが要件を満たさない場合は、 **Discard**をクリックして拒否してください。または、 **Regenerate**をクリックしてChat2Queryに新しいクエリをリクエストすることもできます。 - - AIが無効になっている場合は、SQLクエリを手動で記述してください。 + - AIが無効になっている場合は、SQLクエリを手動で記述してください。
-2. SQLクエリを実行します。 +2. SQLクエリを実行します。
macOSの場合： - - エディタにクエリが 1 つしかない場合は、それを実行するには、 **⌘ + Enter**キーを押すか、クリックします。 **Run**。 + - エディタにクエリが 1 つしかない場合は、それを実行するには、 **⌘ + Enter**キーを押すか、クリックします。 **Run**。 - - エディタに複数のクエリがある場合、それらの1つまたは複数を順番に実行するには、カーソルで対象のクエリの行を選択し、 **⌘ + Enter キー**を押すか、 **Run**をクリックします。 + - エディタに複数のクエリがある場合、それらの1つまたは複数を順番に実行するには、カーソルで対象のクエリの行を選択し、 **⌘ + Enter キー**を押すか、 **Run**をクリックします。 - - エディタ内のすべてのクエリを順番に実行するには、 **⇧ + ⌘ + Enter キー**を押すか、カーソルですべてのクエリの行を選択して**Run**をクリックします。 + - エディタ内のすべてのクエリを順番に実行するには、 **⇧ + ⌘ + Enter キー**を押すか、カーソルですべてのクエリの行を選択して**Run**をクリックします。
@@ -105,11 +105,11 @@ SQLエディタでは、独自のデータセットを使用してSQLクエリ WindowsまたはLinuxの場合： - - エディターにクエリが 1 つしかない場合は、それを実行するには、 **Ctrl + Enter**キーを押すか、クリックします。 **Run**。 + - エディターにクエリが 1 つしかない場合は、それを実行するには、 **Ctrl + Enter**キーを押すか、クリックします。 **Run**。 - - エディターに複数のクエリがある場合、それらのクエリを1つまたは複数順番に実行するには、カーソルで対象のクエリの行を選択し、 **Ctrl + Enter**を押すか、 **Run**をクリックします。 + - エディターに複数のクエリがある場合、それらのクエリを1つまたは複数順番に実行するには、カーソルで対象のクエリの行を選択し、 **Ctrl + Enter**を押すか、 **Run**をクリックします。 - - エディタ内のすべてのクエリを順番に実行するには、 **Shift + Ctrl + Enter**キーを押すか、カーソルですべてのクエリの行を選択して**Run**をクリックします。 + - エディタ内のすべてのクエリを順番に実行するには、 **Shift + Ctrl + Enter**キーを押すか、カーソルですべてのクエリの行を選択して**Run**をクリックします。 @@ -124,20 +124,20 @@ SQLエディタでは、独自のデータセットを使用してSQLクエリ SQLエディタでは、Chat2Queryを使用して既存のSQLクエリを書き換えることで、パフォーマンスの最適化、エラーの修正、またはその他の特定の要件への対応を行うことができます。 -1. カーソルを使って、書き換えたいSQLクエリの行を選択してください。 +1. カーソルを使って、書き換えたいSQLクエリの行を選択してください。 -2. お使いのオペレーティングシステムに対応したキーボードショートカットを使用して、Chat2Queryを起動して書き換えを実行してください。 +2. お使いのオペレーティングシステムに対応したキーボードショートカットを使用して、Chat2Queryを起動して書き換えを実行してください。 - - ⌘ + I (macOS) - - WindowsまたはLinuxでCtrl + I + - ⌘ + I (macOS) + - WindowsまたはLinuxでCtrl + I 指示を入力したら、 **Enter**を押してください。AIが書き換え処理を行います。 -3. Chat2Queryを起動すると、提案された書き換え内容と以下のオプションが表示されます。 +3. Chat2Queryを起動すると、提案された書き換え内容と以下のオプションが表示されます。 - - **Accept**：ここをクリックすると、提案された書き換え案を承認して編集を続行できます。 - - **Discard**：提案された書き換え内容がご期待に沿わない場合は、こちらをクリックしてください。 - - **Regenerate**：ここをクリックすると、フィードバックや追加の指示に基づいて、Chat2Queryによる再書き換えをリクエストできます。 + - **Accept**：ここをクリックすると、提案された書き換え案を承認して編集を続行できます。 + - **Discard**：提案された書き換え内容がご期待に沿わない場合は、こちらをクリックしてください。 + - **Regenerate**：ここをクリックすると、フィードバックや追加の指示に基づいて、Chat2Queryによる再書き換えをリクエストできます。 > **Note:** > @@ -147,9 +147,9 @@ SQLエディタでは、Chat2Queryを使用して既存のSQLクエリを書き SQLエディタでは、SQLクエリを複数のSQLファイルに保存し、以下のようにSQLファイルを管理できます。 -- SQLファイルを追加するには、 **SQL Files**タブの**+**をクリックします。 -- SQL ファイルの名前を変更するには、ファイル名にカーソルを合わせ、ファイル名の横にある**...**をクリックして、 **Rename**を選択します。 -- SQL ファイルを削除するには、ファイル名にカーソルを合わせ、ファイル名の横にある**...**をクリックしてから、 **Delete**を選択します。なお、 **SQL Files**タブに SQL ファイルが 1 つしかない場合は、削除できません。 +- SQLファイルを追加するには、 **SQL Files**タブの**+**をクリックします。 +- SQL ファイルの名前を変更するには、ファイル名にカーソルを合わせ、ファイル名の横にある**...**をクリックして、 **Rename**を選択します。 +- SQL ファイルを削除するには、ファイル名にカーソルを合わせ、ファイル名の横にある**...**をクリックしてから、 **Delete**を選択します。なお、 **SQL Files**タブに SQL ファイルが 1 つしかない場合は、削除できません。 ## API経由でChat2Queryにアクセスする {#access-chat2query-via-api} @@ -157,11 +157,11 @@ Chat2QueryにはUI経由でアクセスできるだけでなく、API経由で Chat2Queryでは、以下の手順でChat2Queryデータアプリにアクセスしたり作成したりできます。 -1. 右上隅の**…**をクリックし、次に**Access Chat2Query via API**をクリックします。 -2. 表示されたダイアログで、次のいずれかの操作を行います。 +1. 右上隅の**…**をクリックし、次に**Access Chat2Query via API**をクリックします。 +2. 表示されたダイアログで、次のいずれかの操作を行います。 - - 新しい Chat2Query データ アプリを作成するには、 **New Chat2Query Data App**をクリックします。 - - 既存のChat2Queryデータアプリにアクセスするには、対象のデータアプリの名前をクリックしてください。 + - 新しい Chat2Query データ アプリを作成するには、 **New Chat2Query Data App**をクリックします。 + - 既存のChat2Queryデータアプリにアクセスするには、対象のデータアプリの名前をクリックしてください。 詳細については、 [Chat2Query API を使い始めましょう](/tidb-cloud/use-chat2query-api.md)を参照してください。 @@ -169,9 +169,9 @@ Chat2Queryでは、以下の手順でChat2Queryデータアプリにアクセス TiDB Cloud には、カスタム API エンドポイントを使用して HTTPS リクエスト経由でTiDB Cloudデータにアクセスできる[Data Service（PREVIEW）](/tidb-cloud/data-service-overview.md)機能があります。SQL エディターでは、以下の手順で SQL ファイルからData Service（PREVIEW）のエンドポイントを生成できます。 -1. ファイル名にカーソルを合わせ、ファイル名の横にある**...**をクリックして、 **Generate endpoint**を選択します。 -2. **Generate endpoint**ダイアログボックスで、エンドポイントを生成するデータアプリを選択し、エンドポイント名を入力します。 -3. **Generate**をクリックします。エンドポイントが生成され、その詳細ページが表示されます。 +1. ファイル名にカーソルを合わせ、ファイル名の横にある**...**をクリックして、 **Generate endpoint**を選択します。 +2. **Generate endpoint**ダイアログボックスで、エンドポイントを生成するデータアプリを選択し、エンドポイント名を入力します。 +3. **Generate**をクリックします。エンドポイントが生成され、その詳細ページが表示されます。 詳細については、[エンドポイントを管理する](/tidb-cloud/data-service-manage-endpoint.md)を参照してください. @@ -179,11 +179,11 @@ TiDB Cloud には、カスタム API エンドポイントを使用して HTTPS SQLエディターでは、以下の設定を変更できます。 -- クエリ結果の最大行数 -- システムデータベーススキーマを**Schemas**タブに表示するかどうか +- クエリ結果の最大行数 +- システムデータベーススキーマを**Schemas**タブに表示するかどうか 設定を変更するには、以下の手順に従ってください。 -1. **SQL Editor**の右上隅にある**...**をクリックし、 **Settings**を選択します。 -2. 必要に応じて設定を変更してください。 -3. **Save**をクリックしてください。 +1. **SQL Editor**の右上隅にある**...**をクリックし、 **Settings**を選択します。 +2. 必要に応じて設定を変更してください。 +3. **Save**をクリックしてください。 diff --git a/tidb-cloud/features.md b/tidb-cloud/features.md index f10761c83cd31..ef3904cfde0f0 100644 --- a/tidb-cloud/features.md +++ b/tidb-cloud/features.md @@ -11,10 +11,10 @@ summary: TiDB Cloudの各プランにおける機能サポート状況につい > > [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 TiDB Cloudを始めるのに最適な方法です。さらに、 [TiDB Playground](https://play.tidbcloud.com/?utm_source=docs&utm_medium=tidb_cloud_quick_start)でTiDB Cloudの機能を試すこともできます。 -- ✅:**一般公開済み**、または**パブリックプレビュー中です**。 -- 🔒:**プライベートプレビュー中です**。 -- 🚧:**開発中です**。 -- ❌:**現在ご利用いただけません**。 +- ✅:**一般公開済み**、または**パブリックプレビュー中です**。 +- 🔒:**プライベートプレビュー中です**。 +- 🚧:**開発中です**。 +- ❌:**現在ご利用いただけません**。
カテゴリ特徴StarterEssentialPremiumDedicated
基本スケーラブルなトランザクション処理✅ ✅ ✅ ✅
分析処理✅ ✅ ✅ ✅
API ✅
（一般公開プレビュー）		 ✅
（一般公開プレビュー）		 ✅
（一般公開プレビュー）		 ✅
（一般公開プレビュー）
開発者エクスペリエンスデータブランチ✅ ✅ 🚧 ❌
SQLエディタ✅ 🚧 🚧 ❌
リソース管理使った分だけ支払う✅ ✅ ✅ ❌
ワークロードに基づいた自動スケーリング✅ ✅ ✅ ❌
クラスターの手動変更❌ ❌ ❌ ✅
パスワード設定✅ ✅ ✅ ✅
一時停止と再開❌ ❌ ❌ ✅
システムメンテナンス期間❌ ❌ 🚧 ✅
バックアップファイルのごみ箱❌ ✅ ✅ ✅
Specialized featuresベクトルストレージとベクトル検索✅
（一般公開プレビュー）		❌❌❌
全文検索✅
（一般公開プレビュー）		❌🚧❌
データ処理CSV、Parquet、SQLファイルからTiDB Cloudへのデータインポート✅ ✅ ✅ ✅
MySQL互換データベースからTiDB Cloudへのデータ移行❌ ✅
（一般公開プレビュー）		 ✅
（一般公開プレビュー）		 ✅
CSV、Parquet、SQLファイルによるローカルストレージまたはオブジェクトストレージへのデータエクスポート✅
（一般公開プレビュー）		 ✅
（一般公開プレビュー）		 🔒 ❌
変更フィードを使用して、Kafkaまたはその他のMySQL互換データベースへのデータレプリケーションを変更します。 ❌ 🔒 ✅ ✅
バックアップと復元自動バックアップ✅ ✅ ✅ ✅
手動バックアップ❌ ❌ ✅ ✅
デュアルリージョンバックアップ❌ ❌ ❌ ✅
特定時点リカバリ（PITR） ❌ ✅ ✅ ✅
復元する✅ ✅ ✅ ✅
可観測性組み込みの指標✅ ✅ ✅ ✅
アラート❌ ✅ ✅ ✅
SQL文の分析✅ ✅ ✅ ✅
スロークエリログ✅ ✅ ✅ ✅
Top SQL ❌ ✅
（公開プレビューでトップRUを獲得）		 ✅
（公開プレビューでトップRUを獲得）		 ✅
イベント✅ ✅ 🚧 ✅
PrometheusとGrafanaの統合❌ ✅
（一般公開プレビュー）		 ✅
（一般公開プレビュー）		 ✅
Datadogとの連携❌✅
(Public preview)		✅
(Public preview)		 ✅
New Relicとの連携❌ ❌ ❌ ✅
高可用性クロスAZフェイルオーバー❌ ❌ ✅ ✅ ✅
リソース割り当てノードグループ❌ ❌ ❌ ✅
リソース制御❌ ❌ 🚧 ✅
ネットワーク接続プライベートエンドポイント✅ ✅ ✅ ✅
公開エンドポイント✅ ✅ ✅ ✅
VPCピアリング❌ ❌ 🔒 ✅
Securityデータベース監査ログ❌ 🔒 ✅ ✅
(Public preview)
コンソール監査ログ✅ ✅ ✅ ✅
ログの秘匿化✅ ✅ ✅ ✅
CMEK ❌ ❌ 🔒 ✅
二重層暗号化✅ ✅ 🔒 ✅
IAM （メールアドレスとパスワードによるログイン、標準SSO、Cloud Organization SSOを含む） ✅ ✅ ✅ ✅
クラウドとリージョンAWS ✅ ✅ ✅ ✅
アリババクラウド✅ ✅ ✅ ❌
Azure ❌ ❌ 🚧 ✅
Google Cloud ❌ ❌ ❌ ✅
クラウドとリージョンAWS ✅ ✅ ✅ ✅
Azure ❌ ❌ 🚧 ✅
Google Cloud ❌ ❌ ❌ ✅
diff --git a/tidb-cloud/get-started-with-cli.md b/tidb-cloud/get-started-with-cli.md index 109f52f1c40cc..c652c5f0f0a00 100644 --- a/tidb-cloud/get-started-with-cli.md +++ b/tidb-cloud/get-started-with-cli.md @@ -7,9 +7,9 @@ summary: TiDB Cloud CLI を使用して、TiDB Cloud StarterおよびEssential TiDB Cloud は、ターミナルから数行のコマンドでTiDB Cloudとやり取りできるコマンドラインインターフェイス (CLI) [`ticloud`](https://github.com/tidbcloud/tidbcloud-cli)を提供しています。たとえば、 `ticloud`を使用して、次の操作を簡単に実行できます。 -- TiDB Cloud StarterまたはEssentialインスタンスの作成、削除、一覧表示を行います。 -- TiDB Cloud StarterまたはEssentialインスタンスにデータをインポートします。 -- TiDB Cloud StarterまたはEssentialインスタンスからデータをエクスポートします。 +- TiDB Cloud StarterまたはEssentialインスタンスの作成、削除、一覧表示を行います。 +- TiDB Cloud StarterまたはEssentialインスタンスにデータをインポートします。 +- TiDB Cloud StarterまたはEssentialインスタンスからデータをエクスポートします。 > **Note:** > @@ -17,7 +17,7 @@ TiDB Cloud は、ターミナルから数行のコマンドでTiDB Cloudとや ## 始める前に {#before-you-begin} -- TiDB Cloudアカウントを持っていること。お持ちでない場合は、[無料トライアルに登録する](https://tidbcloud.com/free-trial)。 +- TiDB Cloudアカウントを持っていること。お持ちでない場合は、[無料トライアルに登録する](https://tidbcloud.com/free-trial)。 ## インストール {#installation} @@ -26,41 +26,41 @@ TiDB Cloud は、ターミナルから数行のコマンドでTiDB Cloudとや macOS または Linux の場合、 `ticloud`次のいずれかの方法を使用してインストールできます。 -- スクリプト経由でインストールする（推奨） +- スクリプト経由でインストールする（推奨） ```shell curl https://raw.githubusercontent.com/tidbcloud/tidbcloud-cli/main/install.sh | sh ``` -- [TiUP](https://tiup.io/)経由でインストール +- [TiUP](https://tiup.io/)経由でインストール ```shell tiup install cloud ``` -- 手動でインストール +- 手動でインストール [リリース](https://github.com/tidbcloud/tidbcloud-cli/releases/latest)ページからコンパイル済みのバイナリをダウンロードし、インストール先の任意の場所にコピーしてください。 -- GitHub Actionsにインストールする +- GitHub Actionsにインストールする GitHub Actions で`ticloud`を設定するには、 [`setup-tidbcloud-cli`](https://github.com/tidbcloud/setup-tidbcloud-cli)を使用します。 MySQLコマンドラインクライアントがインストールされていない場合は、インストールしてください。パッケージマネージャーを使用してインストールできます。 -- Debianベースのディストリビューション： +- Debianベースのディストリビューション： ```shell sudo apt-get install mysql-client ``` -- RPMベースのディストリビューション： +- RPMベースのディストリビューション： ```shell sudo yum install mysql ``` -- macOS: +- macOS: ```shell brew install mysql-client @@ -72,11 +72,11 @@ MySQLコマンドラインクライアントがインストールされていな Windowsの場合、 `ticloud`以下のいずれかの方法でインストールできます。 -- 手動でインストール +- 手動でインストール [リリース](https://github.com/tidbcloud/tidbcloud-cli/releases/latest)ページからコンパイル済みのバイナリをダウンロードし、インストール先の場所にコピーしてください。 -- GitHub Actionsにインストールする +- GitHub Actionsにインストールする GitHub Actions で`ticloud`を設定するには、 [`setup-tidbcloud-cli`](https://github.com/tidbcloud/setup-tidbcloud-cli)を使用します。 @@ -97,7 +97,7 @@ MySQL コマンドライン クライアントがインストールされてい TiDB Cloud CLI を使用して TiDB Cloud Starterインスタンスを作成する前に、ユーザー プロファイルを作成するか、 TiDB Cloudにログインする必要があります。 -- [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)を使用してユーザープロファイルを作成します。 ```shell ticloud config create @@ -107,7 +107,7 @@ TiDB Cloud CLI を使用して TiDB Cloud Starterインスタンスを作成す > > プロファイル名には`.`を含めて**はいけません**。 -- TiDB Cloudに認証情報を使用してログインしてください。 +- TiDB Cloudに認証情報を使用してログインしてください。 ```shell ticloud auth login diff --git a/tidb-cloud/high-availability-with-multi-az.md b/tidb-cloud/high-availability-with-multi-az.md index a45582eda0f77..739c2f4423d09 100644 --- a/tidb-cloud/high-availability-with-multi-az.md +++ b/tidb-cloud/high-availability-with-multi-az.md @@ -9,14 +9,14 @@ TiDBはRaftコンセンサスアルゴリズムを使用し、 Raftグループ TiDB Cloud Dedicated クラスタは、TiDB ノード、TiKV ノード、 TiFlashノードという 3 つの主要コンポーネントで構成されています。TiDB Cloud Dedicated の各コンポーネントの高可用性実装は次のとおりです。 -- **TiDBノード** +- **TiDBノード** TiDBはコンピューティングのみを目的としており、データの保存は行いません。水平方向に拡張可能です。TiDB Cloud Dedicatedは、リージョン内の異なるアベイラビリティゾーンにTiDBノードを均等に配置します。ユーザーがSQLリクエストを実行すると、リクエストはまず複数のアベイラビリティゾーンに展開されたロードバランサーを通過し、その後、ロードバランサーによって複数のTiDBノードに分散されて実行されます。高可用性を確保するため、各TiDB Cloud Dedicatedクラスタには少なくとも2つのTiDBノードを配置することをお勧めします。 -- **TiKVノード** +- **TiKVノード** [TiKV](https://docs.pingcap.com/tidb/stable/tikv-overview) 、水平スケーラビリティを備えたTiDB Cloud Dedicatedクラスタの行ベースのストレージレイヤーです。TiDB Cloud DedicatedクラスタのTiKVノードの最小数は3です。TiDB Cloud Dedicatedは、選択したリージョン内のすべてのアベイラビリティゾーン（少なくとも3つ）にTiKVノードを均等にデプロイすることで、耐久性と高可用性を実現します。典型的な3レプリカ構成では、データはすべてのアベイラビリティゾーンのTiKVノードに均等に分散され、各TiKVノードのディスクに永続化されます。 -- **TiFlashノード** +- **TiFlashノード** [TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview) 、TiKV の列指向ストレージ拡張機能であり、TiDB を本質的にハイブリッドトランザクション/分析処理 (HTAP) データベースにする重要なコンポーネントです。TiFlash、列指向レプリカはRaft Learnerコンセンサスアルゴリズムに従って非同期的に複製されます。TiDB Cloud Dedicated は、 TiFlashノードをリージョン内の異なるアベイラビリティゾーンに均等にデプロイします。本番環境での高可用性を確保するため、各TiDB Cloud Dedicated クラスターに少なくとも 2 つのTiFlashノードを設定し、少なくとも 2 つのデータレプリカを作成本番ことをお勧めします。 diff --git a/tidb-cloud/import-csv-files-serverless.md b/tidb-cloud/import-csv-files-serverless.md index ee6aff808a5b2..4d0e5a999d3bf 100644 --- a/tidb-cloud/import-csv-files-serverless.md +++ b/tidb-cloud/import-csv-files-serverless.md @@ -13,37 +13,37 @@ summary: Amazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object St ## 制限事項 {#limitations} -- データの一貫性を確保するため、 TiDB Cloud では CSV ファイルを空のテーブルにのみインポートできます。既にデータが含まれている既存のテーブルにデータをインポートするには、このドキュメントの手順に従って一時的な空のテーブルにデータをインポートし、 `INSERT SELECT`ステートメントを使用してデータを対象の既存のテーブルにコピーします。 +- データの一貫性を確保するため、 TiDB Cloud では CSV ファイルを空のテーブルにのみインポートできます。既にデータが含まれている既存のテーブルにデータをインポートするには、このドキュメントの手順に従って一時的な空のテーブルにデータをインポートし、 `INSERT SELECT`ステートメントを使用してデータを対象の既存のテーブルにコピーします。 ## ステップ1. CSVファイルを準備する {#step-1-prepare-the-csv-files} -1. CSVファイルが256MiBを超える場合は、それぞれ約256MiBのサイズの小さなファイルに分割することを検討してください。 +1. CSVファイルが256MiBを超える場合は、それぞれ約256MiBのサイズの小さなファイルに分割することを検討してください。 TiDB Cloudは非常に大きなCSVファイルのインポートをサポートしていますが、256MiB程度のサイズの複数の入力ファイルを扱う場合に最高のパフォーマンスを発揮します。これは、 TiDB Cloudが複数のファイルを並列処理できるため、インポート速度を大幅に向上させることができるからです。 -2. CSVファイルの名前は以下のようにしてください。 +2. CSVファイルの名前は以下のようにしてください。 - - CSV ファイルにテーブル全体のデータがすべて含まれている場合は、ファイル名を`${db_name}.${table_name}.csv`形式で指定してください。この形式は、データをインポートする際に`${db_name}.${table_name}`テーブルにマッピングされます。 + - CSV ファイルにテーブル全体のデータがすべて含まれている場合は、ファイル名を`${db_name}.${table_name}.csv`形式で指定してください。この形式は、データをインポートする際に`${db_name}.${table_name}`テーブルにマッピングされます。 - - 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`と`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 + - 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`と`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 - - TiDB Cloudは、 `.gzip` 、 `.gz` 、 `.zstd` 、 `.zst` `.snappy`の各形式の圧縮ファイルのインポートをサポートしています。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。この形式では、 `${suffix}`は省略可能で、「000001」などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 + - TiDB Cloudは、 `.gzip` 、 `.gz` 、 `.zstd` 、 `.zst` `.snappy`の各形式の圧縮ファイルのインポートをサポートしています。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。この形式では、 `${suffix}`は省略可能で、「000001」などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 > **Note:** > - > - パフォーマンスを向上させるためには、各圧縮ファイルのサイズを100MiBに制限することをお勧めします。 - > - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)に存在する必要があります。 Snappy 圧縮の他のバリアントはサポートされていません。 - > - 非圧縮ファイルの場合、場合によっては前述のルールに従ってCSVファイル名を更新できない場合（たとえば、CSVファイルリンクが他のプログラムでも使用されている場合）、ファイル名を変更せずに、[ステップ4](#step-4-import-csv-files)の**Mapping Settings**を使用してソースデータを単一のターゲットテーブルにインポートできます。 + > - パフォーマンスを向上させるためには、各圧縮ファイルのサイズを100MiBに制限することをお勧めします。 + > - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)に存在する必要があります。 Snappy 圧縮の他のバリアントはサポートされていません。 + > - 非圧縮ファイルの場合、場合によっては前述のルールに従ってCSVファイル名を更新できない場合（たとえば、CSVファイルリンクが他のプログラムでも使用されている場合）、ファイル名を変更せずに、[ステップ4](#step-4-import-csv-files)の**Mapping Settings**を使用してソースデータを単一のターゲットテーブルにインポートできます。 ## ステップ2．対象テーブルのスキーマを作成する {#step-2-create-the-target-table-schemas} CSVファイルにはスキーマ情報が含まれていないため、CSVファイルからTiDB Cloudにデータをインポートする前に、以下のいずれかの方法を使用してテーブルスキーマを作成する必要があります。 -- 方法1： TiDB Cloudで、ソースデータ用のターゲットデータベースとテーブルを作成します。 +- 方法1： TiDB Cloudで、ソースデータ用のターゲットデータベースとテーブルを作成します。 -- 方法2：CSVファイルが保存されているAmazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object Storage Serviceのディレクトリに、ソースデータ用のターゲットテーブルスキーマファイルを次のように作成します。 +- 方法2：CSVファイルが保存されているAmazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object Storage Serviceのディレクトリに、ソースデータ用のターゲットテーブルスキーマファイルを次のように作成します。 - 1. ソースデータ用のデータベーススキーマファイルを作成します。 + 1. ソースデータ用のデータベーススキーマファイルを作成します。 [ステップ1](#step-1-prepare-the-csv-files)の命名規則に従ってCSVファイルが作成されている場合、データベーススキーマファイルはデータインポートにおいてオプションです。そうでない場合は、データベーススキーマファイルは必須です。 @@ -55,7 +55,7 @@ CSVファイルにはスキーマ情報が含まれていないため、CSVフ CREATE DATABASE mydb; ``` - 2. ソースデータ用のテーブルスキーマファイルを作成します。 + 2. ソースデータ用のテーブルスキーマファイルを作成します。 CSVファイルが保存されているAmazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object Storage Serviceディレクトリにテーブルスキーマファイルを含めない場合、 TiDB Cloudはデータのインポート時に対応するテーブルを作成しません。 @@ -78,15 +78,15 @@ CSVファイルにはスキーマ情報が含まれていないため、CSVフ TiDB CloudがAmazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object Storage Serviceバケット内のCSVファイルにアクセスできるようにするには、次のいずれかの操作を行います。 -- CSV ファイルが Amazon S3 にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 +- CSV ファイルが Amazon S3 にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-csv-files)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 -- CSV ファイルが GCS にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 +- CSV ファイルが GCS にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 -- CSV ファイルが Azure Blob Storage にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)。 +- CSV ファイルが Azure Blob Storage にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)。 -- CSV ファイルが Alibaba Cloud Object Storage Service (OSS) にある場合は、 TiDB Cloud StarterまたはEssentialインスタンス[Alibaba Cloud Object Storage Service (OSS) へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 +- CSV ファイルが Alibaba Cloud Object Storage Service (OSS) にある場合は、 TiDB Cloud StarterまたはEssentialインスタンス[Alibaba Cloud Object Storage Service (OSS) へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 ## ステップ4．CSVファイルをインポートする {#step-4-import-csv-files} @@ -95,31 +95,31 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー
-1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 +1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Amazon S3**を選択してください。 - - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `s3://sampledata/ingest/TableName.01.csv` 。 - - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://sampledata/ingest/` 。 - - **Credential**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 - - **AWS Role ARN** ：AWSロールARNの値を入力してください。 - - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 + - **Storage Provider**： **Amazon S3**を選択してください。 + - **Source Files URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `s3://sampledata/ingest/TableName.01.csv` 。 + - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://sampledata/ingest/` 。 + - **Credential**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 + - **AWS Role ARN** ：AWSロールARNの値を入力してください。 + - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 +5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 **Source Files URI**でディレクトリが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションがデフォルトで選択されます。 @@ -127,50 +127,50 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 - - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - - **Source**: ファイル名のパターンを`[file_name].csv`の形式で入力してください。例: `TableName.01.csv` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 + - **Source**: ファイル名のパターンを`[file_name].csv`の形式で入力してください。例: `TableName.01.csv` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 - - `my-data?.csv` : `my-data` `my-data1.csv`や`my-data2.csv`のような 1 文字が続くすべての CSV ファイルに一致します。 - - `my-data*.csv` : `my-data`で始まるすべての CSV ファイルに一致します。たとえば`my-data-2023.csv`や`my-data-final.csv`などです。 + - `my-data?.csv` : `my-data` `my-data1.csv`や`my-data2.csv`のような 1 文字が続くすべての CSV ファイルに一致します。 + - `my-data*.csv` : `my-data`で始まるすべての CSV ファイルに一致します。たとえば`my-data-2023.csv`や`my-data-final.csv`などです。 - - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 + - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 -6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 +6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
-1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 +1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Google Cloud Storage**を選択してください。 - - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[gcs|gs]://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `[gcs|gs]://sampledata/ingest/TableName.01.csv` 。 - - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[gcs|gs]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[gcs|gs]://sampledata/ingest/` 。 - - **Credential**: GCS IAM役割サービス アカウント キーを使用してバケットにアクセスできます。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)を参照してください。 + - **Storage Provider**： **Google Cloud Storage**を選択してください。 + - **Source Files URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[gcs|gs]://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `[gcs|gs]://sampledata/ingest/TableName.01.csv` 。 + - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[gcs|gs]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[gcs|gs]://sampledata/ingest/` 。 + - **Credential**: GCS IAM役割サービス アカウント キーを使用してバケットにアクセスできます。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)を参照してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 +5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 **Source Files URI**でディレクトリが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションがデフォルトで選択されます。 @@ -178,50 +178,50 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 - - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - - **Source**: ファイル名のパターンを`[file_name].csv`の形式で入力してください。例: `TableName.01.csv` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 + - **Source**: ファイル名のパターンを`[file_name].csv`の形式で入力してください。例: `TableName.01.csv` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 - - `my-data?.csv` : `my-data` `my-data1.csv`や`my-data2.csv`のような 1 文字が続くすべての CSV ファイルに一致します。 - - `my-data*.csv` : `my-data`で始まるすべての CSV ファイルに一致します。たとえば`my-data-2023.csv`や`my-data-final.csv`などです。 + - `my-data?.csv` : `my-data` `my-data1.csv`や`my-data2.csv`のような 1 文字が続くすべての CSV ファイルに一致します。 + - `my-data*.csv` : `my-data`で始まるすべての CSV ファイルに一致します。たとえば`my-data-2023.csv`や`my-data-final.csv`などです。 - - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 + - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 -6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 +6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
-1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 +1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Azure Blob Storage**を選択します。 - - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[azure|https]://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `[azure|https]://sampledata/ingest/TableName.01.csv` 。 - - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[azure|https]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[azure|https]://sampledata/ingest/` 。 - - **Credential**: Shared Access Signature (SAS) トークンを使用してバケットにアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 + - **Storage Provider**： **Azure Blob Storage**を選択します。 + - **Source Files URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[azure|https]://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `[azure|https]://sampledata/ingest/TableName.01.csv` 。 + - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[azure|https]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[azure|https]://sampledata/ingest/` 。 + - **Credential**: Shared Access Signature (SAS) トークンを使用してバケットにアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 +5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 **Source Files URI**でディレクトリが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションがデフォルトで選択されます。 @@ -229,50 +229,50 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 - - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - - **Source**: ファイル名のパターンを`[file_name].csv`の形式で入力してください。例: `TableName.01.csv` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 + - **Source**: ファイル名のパターンを`[file_name].csv`の形式で入力してください。例: `TableName.01.csv` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 - - `my-data?.csv` : `my-data` `my-data1.csv`や`my-data2.csv`のような 1 文字が続くすべての CSV ファイルに一致します。 - - `my-data*.csv` : `my-data`で始まるすべての CSV ファイルに一致します。たとえば`my-data-2023.csv`や`my-data-final.csv`などです。 + - `my-data?.csv` : `my-data` `my-data1.csv`や`my-data2.csv`のような 1 文字が続くすべての CSV ファイルに一致します。 + - `my-data*.csv` : `my-data`で始まるすべての CSV ファイルに一致します。たとえば`my-data-2023.csv`や`my-data-final.csv`などです。 - - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 + - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 -6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 +6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
-1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 +1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Alibaba Cloud OSS**を選択してください。 - - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `oss://sampledata/ingest/TableName.01.csv` 。 - - 複数のファイルをインポートする場合は、ソースフォルダの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)を参照してください。 + - **Storage Provider**： **Alibaba Cloud OSS**を選択してください。 + - **Source Files URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `oss://sampledata/ingest/TableName.01.csv` 。 + - 複数のファイルをインポートする場合は、ソースフォルダの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)を参照してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 +5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 **Source Files URI**でディレクトリが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションがデフォルトで選択されます。 @@ -280,22 +280,22 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。 - - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - - **Source**: ファイル名のパターンを`[file_name].csv`の形式で入力してください。例: `TableName.01.csv` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 + - **Source**: ファイル名のパターンを`[file_name].csv`の形式で入力してください。例: `TableName.01.csv` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 - - `my-data?.csv` : `my-data` `my-data1.csv`や`my-data2.csv`のような 1 文字が続くすべての CSV ファイルに一致します。 - - `my-data*.csv` : `my-data`で始まるすべての CSV ファイルに一致します。たとえば`my-data-2023.csv`や`my-data-final.csv`などです。 + - `my-data?.csv` : `my-data` `my-data1.csv`や`my-data2.csv`のような 1 文字が続くすべての CSV ファイルに一致します。 + - `my-data*.csv` : `my-data`で始まるすべての CSV ファイルに一致します。たとえば`my-data-2023.csv`や`my-data-final.csv`などです。 - - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 + - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 -6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 +6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
@@ -305,10 +305,10 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー インポートエラーが発生した場合は、以下の手順を実行してください。 -1. 部分的にインポートされたテーブルを削除します。 -2. テーブルスキーマファイルを確認してください。エラーがある場合は、テーブルスキーマファイルを修正してください。 -3. CSVファイル内のデータ型を確認してください。 -4. インポートタスクをもう一度実行してみてください。 +1. 部分的にインポートされたテーブルを削除します。 +2. テーブルスキーマファイルを確認してください。エラーがある場合は、テーブルスキーマファイルを修正してください。 +3. CSVファイル内のデータ型を確認してください。 +4. インポートタスクをもう一度実行してみてください。 ## トラブルシューティング {#troubleshooting} diff --git a/tidb-cloud/import-csv-files.md b/tidb-cloud/import-csv-files.md index 1853c5119db7d..08d2ce03bb85c 100644 --- a/tidb-cloud/import-csv-files.md +++ b/tidb-cloud/import-csv-files.md @@ -14,40 +14,40 @@ aliases: ['/ja/tidbcloud/migrate-from-amazon-s3-or-gcs','/ja/tidbcloud/migrate-f ## 制限事項 {#limitations} -- データの一貫性を確保するため、 TiDB Cloud では CSV ファイルを空のテーブルにのみインポートできます。既にデータが含まれている既存のテーブルにデータをインポートするには、このドキュメントの手順に従ってTiDB Cloud を使用して一時的な空のテーブルにデータをインポートし、その後`INSERT SELECT`ステートメントを使用してデータを対象の既存のテーブルにコピーします。 +- データの一貫性を確保するため、 TiDB Cloud では CSV ファイルを空のテーブルにのみインポートできます。既にデータが含まれている既存のテーブルにデータをインポートするには、このドキュメントの手順に従ってTiDB Cloud を使用して一時的な空のテーブルにデータをインポートし、その後`INSERT SELECT`ステートメントを使用してデータを対象の既存のテーブルにコピーします。 -- TiDB Cloud Dedicatedクラスターに[変更フィード](/tidb-cloud/changefeed-overview.md)があるか、 [特定時点への復元](/tidb-cloud/backup-and-restore.md#turn-on-point-in-time-restore)が有効になっている場合、現在のデータインポート機能は[物理インポートモード](https://docs.pingcap.com/tidb/stable/tidb-lightning-physical-import-mode)を使用しているため、クラスターにデータをインポートできません ([**Import Data**ボタンが無効になります)。このモードでは、インポートされたデータは変更ログを生成しないため、変更フィードとポイントインタイム リストアはインポートされたデータを検出できません。 +- TiDB Cloud Dedicatedクラスターに[変更フィード](/tidb-cloud/changefeed-overview.md)があるか、 [特定時点への復元](/tidb-cloud/backup-and-restore.md#turn-on-point-in-time-restore)が有効になっている場合、現在のデータインポート機能は[物理インポートモード](https://docs.pingcap.com/tidb/stable/tidb-lightning-physical-import-mode)を使用しているため、クラスターにデータをインポートできません ([**Import Data**ボタンが無効になります)。このモードでは、インポートされたデータは変更ログを生成しないため、変更フィードとポイントインタイム リストアはインポートされたデータを検出できません。 ## ステップ1. CSVファイルを準備する {#step-1-prepare-the-csv-files} -1. CSVファイルのサイズが256MiBを超える場合は、それぞれ約256MiBのサイズの小さなファイルに分割することを検討してください。 +1. CSVファイルのサイズが256MiBを超える場合は、それぞれ約256MiBのサイズの小さなファイルに分割することを検討してください。 TiDB Cloudは非常に大きなCSVファイルのインポートをサポートしていますが、256MiB程度のサイズの複数の入力ファイルを扱う場合に最高のパフォーマンスを発揮します。これは、 TiDB Cloudが複数のファイルを並列処理できるため、インポート速度を大幅に向上させることができるからです。 -2. CSVファイルの名前は以下のようにしてください。 +2. CSVファイルの名前は以下のようにしてください。 - - CSV ファイルにテーブル全体のデータがすべて含まれている場合は、ファイル名を`${db_name}.${table_name}.csv`形式で指定してください。この形式は、データをインポートする際に`${db_name}.${table_name}`テーブルにマッピングされます。 + - CSV ファイルにテーブル全体のデータがすべて含まれている場合は、ファイル名を`${db_name}.${table_name}.csv`形式で指定してください。この形式は、データをインポートする際に`${db_name}.${table_name}`テーブルにマッピングされます。 - - 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`と`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順でなければなりません。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 + - 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`と`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順でなければなりません。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 - - TiDB Cloudは、 `.gzip` 、 `.gz` 、{ `.zst` `.zstd` 、および`.snappy`形式で圧縮ファイルをインポートすることをサポートしています。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。ここで`${suffix}`は省略可能で、「000001」などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 + - TiDB Cloudは、 `.gzip` 、 `.gz` 、{ `.zst` `.zstd` 、および`.snappy`形式で圧縮ファイルをインポートすることをサポートしています。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。ここで`${suffix}`は省略可能で、「000001」などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 > **Note:** > - > - データファイルのみを圧縮すればよく、データベースファイルやテーブルスキーマファイルを圧縮する必要はありません。 - > - パフォーマンスを向上させるためには、各圧縮ファイルのサイズを100MiBに制限することをお勧めします。 - > - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)に存在する必要があります。 Snappy 圧縮の他のバリアントはサポートされていません。 - > - 圧縮されていないファイルの場合、前述のルールに従って CSV ファイル名を更新できない場合 (たとえば、CSV ファイル リンクが他のプログラムでも使用されている場合)、ファイル名を変更せずに、[ステップ4](#step-4-import-csv-files-to-tidb-cloud)の**Destination Mapping**手順で**自動マッピングにTiDBファイル命名規則を使用する**の選択を解除して、ソース ファイルを単一のターゲット テーブルに手動でマッピングできます。 + > - データファイルのみを圧縮すればよく、データベースファイルやテーブルスキーマファイルを圧縮する必要はありません。 + > - パフォーマンスを向上させるためには、各圧縮ファイルのサイズを100MiBに制限することをお勧めします。 + > - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)に存在する必要があります。 Snappy 圧縮の他のバリアントはサポートされていません。 + > - 圧縮されていないファイルの場合、前述のルールに従って CSV ファイル名を更新できない場合 (たとえば、CSV ファイル リンクが他のプログラムでも使用されている場合)、ファイル名を変更せずに、[ステップ4](#step-4-import-csv-files-to-tidb-cloud)の**Destination Mapping**手順で**自動マッピングにTiDBファイル命名規則を使用する**の選択を解除して、ソース ファイルを単一のターゲット テーブルに手動でマッピングできます。 ## ステップ2．対象テーブルのスキーマを作成する {#step-2-create-the-target-table-schemas} CSVファイルにはスキーマ情報が含まれていないため、CSVファイルからTiDB Cloudにデータをインポートする前に、以下のいずれかの方法を使用してテーブルスキーマを作成する必要があります。 -- 方法1： TiDB Cloudで、ソースデータ用のターゲットデータベースとテーブルを作成します。 +- 方法1： TiDB Cloudで、ソースデータ用のターゲットデータベースとテーブルを作成します。 -- 方法2：CSVファイルが保存されているAmazon S3、GCS、またはAzure Blob Storageディレクトリに、ソースデータ用のターゲットテーブルスキーマファイルを次のように作成します。 +- 方法2：CSVファイルが保存されているAmazon S3、GCS、またはAzure Blob Storageディレクトリに、ソースデータ用のターゲットテーブルスキーマファイルを次のように作成します。 - 1. ソースデータ用のデータベーススキーマファイルを作成します。 + 1. ソースデータ用のデータベーススキーマファイルを作成します。 [ステップ1](#step-1-prepare-the-csv-files)の命名規則に従ってCSVファイルが作成されている場合、データベーススキーマファイルはデータインポートにおいてオプションです。そうでない場合は、データベーススキーマファイルは必須です。 @@ -59,7 +59,7 @@ CSVファイルにはスキーマ情報が含まれていないため、CSVフ CREATE DATABASE mydb; ``` - 2. ソースデータ用のテーブルスキーマファイルを作成します。 + 2. ソースデータ用のテーブルスキーマファイルを作成します。 CSVファイルが保存されているAmazon S3、GCS、またはAzure Blob Storageディレクトリにテーブルスキーマファイルを含めない場合、 TiDB Cloudはデータのインポート時に対応するテーブルを作成しません。 @@ -82,13 +82,13 @@ CSVファイルにはスキーマ情報が含まれていないため、CSVフ TiDB CloudがAmazon S3バケット、GCSバケット、またはAzure Blob Storageコンテナ内のCSVファイルにアクセスできるようにするには、次のいずれかの操作を行います。 -- CSV ファイルが Amazon S3 にある場合は、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 +- CSV ファイルが Amazon S3 にある場合は、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-csv-files-to-tidb-cloud)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 -- CSV ファイルが GCS にある場合は、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 +- CSV ファイルが GCS にある場合は、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 -- CSV ファイルが Azure Blob Storage にある場合は、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)。 +- CSV ファイルが Azure Blob Storage にある場合は、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)。 ## ステップ4. CSVファイルをTiDB Cloudにインポートする {#step-4-import-csv-files-to-tidb-cloud} @@ -97,31 +97,31 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に
-1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Amazon S3**を選択してください。 - - **Source URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `s3://mybucket/myfolder/TableName.01.csv` 。 - - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://mybucket/myfolder/` 。 - - **Credentials**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)を参照してください。 - - **AWS Role ARN** (推奨): AWS ロール ARN の値を入力します。まだロール ARN がない場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロール ARN を作成する]**をクリックし、画面の指示に従うか、 **[問題が発生しましたか?] ダイアログでロール ARN を手動で作成して、**クラスターの**TiDB Cloud Account ID**と**TiDB Cloud External ID**を取得し、 IAMロールを手動で作成します。 - - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 + - **Storage Provider**： **Amazon S3**を選択してください。 + - **Source URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `s3://mybucket/myfolder/TableName.01.csv` 。 + - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://mybucket/myfolder/` 。 + - **Credentials**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)を参照してください。 + - **AWS Role ARN** (推奨): AWS ロール ARN の値を入力します。まだロール ARN がない場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロール ARN を作成する]**をクリックし、画面の指示に従うか、 **[問題が発生しましたか?] ダイアログでロール ARN を手動で作成して、**クラスターの**TiDB Cloud Account ID**と**TiDB Cloud External ID**を取得し、 IAMロールを手動で作成します。 + - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 +5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 **Source URI**でディレクトリを指定すると、 TiDB Cloudはデフォルトで**自動マッピングにTiDBファイル命名規則を使用する**オプションを選択します。 @@ -129,52 +129,52 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に > > **Source URI**で単一のファイルを指定すると、 TiDB Cloudは**自動マッピングにTiDBファイル命名規則を使用する**オプションを表示せず、**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを入力するだけで済みます。 - - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 + - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 - - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - - **Source**: ファイル名のパターンを`[file_name].csv`の形式で入力してください。例: `TableName.01.csv` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 + - **Source**: ファイル名のパターンを`[file_name].csv`の形式で入力してください。例: `TableName.01.csv` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 - - `my-data?.csv` : `my-data` `my-data1.csv`や`my-data2.csv`のような 1 文字が続くすべての CSV ファイルに一致します。 - - `my-data*.csv` : `my-data`で始まるすべての CSV ファイルに一致します。たとえば`my-data-2023.csv`や`my-data-final.csv`などです。 + - `my-data?.csv` : `my-data` `my-data1.csv`や`my-data2.csv`のような 1 文字が続くすべての CSV ファイルに一致します。 + - `my-data*.csv` : `my-data`で始まるすべての CSV ファイルに一致します。たとえば`my-data-2023.csv`や`my-data-final.csv`などです。 - - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを入力してください。 + - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを入力してください。 必要に応じて、 **Edit CSV Configuration**をクリックして、CSVファイルに合わせてオプションを設定してください。区切り文字や区切り記号の設定、エスケープ文字にバックスラッシュを使用するかどうかの指定、ファイルにヘッダー行が含まれているかどうかの指定が可能です。 -6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 +6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
-1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Google Cloud Storage**を選択してください。 - - **Source URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`gs://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `gs://mybucket/myfolder/TableName.01.csv` 。 - - 複数のファイルをインポートする場合は、ソースフォルダのURIを`gs://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `gs://mybucket/myfolder/` 。 - - **Google Cloud サービス アカウント ID** : TiDB Cloud は、このページで一意の Google Cloud サービス アカウント ID ( `example-service-account@your-project.iam.gserviceaccount.com`など) を提供します。このサービス アカウント ID に、Google Cloud プロジェクト内の GCS バケットに対して必要なIAM権限（ `Storage Object Viewer`など）を付与します。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)を参照してください。 + - **Storage Provider**： **Google Cloud Storage**を選択してください。 + - **Source URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`gs://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `gs://mybucket/myfolder/TableName.01.csv` 。 + - 複数のファイルをインポートする場合は、ソースフォルダのURIを`gs://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `gs://mybucket/myfolder/` 。 + - **Google Cloud サービス アカウント ID** : TiDB Cloud は、このページで一意の Google Cloud サービス アカウント ID ( `example-service-account@your-project.iam.gserviceaccount.com`など) を提供します。このサービス アカウント ID に、Google Cloud プロジェクト内の GCS バケットに対して必要なIAM権限（ `Storage Object Viewer`など）を付与します。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)を参照してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 +5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 **Source URI**でディレクトリを指定すると、 TiDB Cloudはデフォルトで**自動マッピングにTiDBファイル命名規則を使用する**オプションを選択します。 @@ -182,77 +182,77 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に > > **Source URI**で単一のファイルを指定すると、 TiDB Cloudは**自動マッピングにTiDBファイル命名規則を使用する**オプションを表示せず、**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを入力するだけで済みます。 - - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 + - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 - - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - - **Source**: ファイル名のパターンを`[file_name].csv`の形式で入力してください。例: `TableName.01.csv` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 + - **Source**: ファイル名のパターンを`[file_name].csv`の形式で入力してください。例: `TableName.01.csv` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 - - `my-data?.csv` : `my-data` `my-data1.csv`や`my-data2.csv`のような 1 文字が続くすべての CSV ファイルに一致します。 - - `my-data*.csv` : `my-data`で始まるすべての CSV ファイルに一致します。たとえば`my-data-2023.csv`や`my-data-final.csv`などです。 + - `my-data?.csv` : `my-data` `my-data1.csv`や`my-data2.csv`のような 1 文字が続くすべての CSV ファイルに一致します。 + - `my-data*.csv` : `my-data`で始まるすべての CSV ファイルに一致します。たとえば`my-data-2023.csv`や`my-data-final.csv`などです。 - - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを入力してください。 + - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを入力してください。 必要に応じて、 **Edit CSV Configuration**をクリックして、CSVファイルに合わせてオプションを設定してください。区切り文字や区切り記号の設定、エスケープ文字にバックスラッシュを使用するかどうかの指定、ファイルにヘッダー行が含まれているかどうかの指定が可能です。 -6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 +6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
-1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Azure Blob Storage**を選択します。 + - **Storage Provider**： **Azure Blob Storage**を選択します。 - - **Source URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `https://myaccount.blob.core.windows.net/mycontainer/myfolder/TableName.01.csv` 。 - - 複数のファイルをインポートする場合は、ソースフォルダのURIを`https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/`の形式で入力してください。例： `https://myaccount.blob.core.windows.net/mycontainer/myfolder/` 。 + - **Source URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `https://myaccount.blob.core.windows.net/mycontainer/myfolder/TableName.01.csv` 。 + - 複数のファイルをインポートする場合は、ソースフォルダのURIを`https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/`の形式で入力してください。例： `https://myaccount.blob.core.windows.net/mycontainer/myfolder/` 。 - - **Connectivity Method**： TiDB CloudがAzure Blob Storageに接続する方法を選択してください。 + - **Connectivity Method**： TiDB CloudがAzure Blob Storageに接続する方法を選択してください。 - - **Public**（デフォルト）：パブリックインターネット経由で接続します。ストレージアカウントがパブリックネットワークへのアクセスを許可している場合にこのオプションを使用してください。 - - **Private Link**：Azure プライベートエンドポイント経由で接続し、ネットワークから隔離されたアクセスを実現します。ストレージアカウントがパブリックアクセスをブロックしている場合、またはセキュリティポリシーでプライベート接続が必要な場合にこのオプションを使用します。**Private Link**を選択した場合は、追加フィールド**Azure Blob Storage Resource ID**も入力する必要があります。リソース ID を確認するには： + - **Public**（デフォルト）：パブリックインターネット経由で接続します。ストレージアカウントがパブリックネットワークへのアクセスを許可している場合にこのオプションを使用してください。 + - **Private Link**：Azure プライベートエンドポイント経由で接続し、ネットワークから隔離されたアクセスを実現します。ストレージアカウントがパブリックアクセスをブロックしている場合、またはセキュリティポリシーでプライベート接続が必要な場合にこのオプションを使用します。**Private Link**を選択した場合は、追加フィールド**Azure Blob Storage Resource ID**も入力する必要があります。リソース ID を確認するには： - 1. [Azureポータル](https://portal.azure.com/)にアクセスします。 - 2. ストレージアカウントに移動し、 **Overview** > **JSON View**をクリックします。 - 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/`の形式です。 + 1. [Azureポータル](https://portal.azure.com/)にアクセスします。 + 2. ストレージアカウントに移動し、 **Overview** > **JSON View**をクリックします。 + 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/`の形式です。 - - **SAS Token**: TiDB Cloud がAzure Blob Storage コンテナー内のソース ファイルにアクセスできるようにするアカウント SAS トークンを入力します。まだお持ちでない場合は、 **[ここをクリックして Azure ARM テンプレートを使用して新しいものを作成する]**をクリックし、画面の指示に従うか、アカウント SAS トークンを手動で作成します。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)を参照してください。 + - **SAS Token**: TiDB Cloud がAzure Blob Storage コンテナー内のソース ファイルにアクセスできるようにするアカウント SAS トークンを入力します。まだお持ちでない場合は、 **[ここをクリックして Azure ARM テンプレートを使用して新しいものを作成する]**をクリックし、画面の指示に従うか、アカウント SAS トークンを手動で作成します。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)を参照してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。ウィザードを続行するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 - 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 + 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 - 2. **Networking** > **Private endpoint connections**をクリックします。 + 2. **Networking** > **Private endpoint connections**をクリックします。 - 3. TiDB Cloudからの保留中の接続要求を見つけて、 **Approve**をクリックします。 + 3. TiDB Cloudからの保留中の接続要求を見つけて、 **Approve**をクリックします。 - 4. [TiDB Cloudコンソール](https://tidbcloud.com/)に戻ります。エンドポイントが承認されると、インポート ウィザードが自動的に続行されます。 + 4. [TiDB Cloudコンソール](https://tidbcloud.com/)に戻ります。エンドポイントが承認されると、インポート ウィザードが自動的に続行されます。 > **Note:** > > エンドポイントがまだ承認されていない場合、 TiDB Cloud は接続が承認待ちであることを示すメッセージを表示します。Azure でリクエスト[Azureポータル](https://portal.azure.com/)承認してから、再試行してください。 -5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 +5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 **Source URI**でディレクトリを指定すると、 TiDB Cloudはデフォルトで**自動マッピングにTiDBファイル命名規則を使用する**オプションを選択します。 @@ -260,24 +260,24 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に > > **Source URI**で単一のファイルを指定すると、 TiDB Cloudは**自動マッピングにTiDBファイル命名規則を使用する**オプションを表示せず、**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを入力するだけで済みます。 - - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 + - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**CSV**を選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 - - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソースCSVファイルをターゲットデータベースおよびテーブルに関連付けるためのマッピングルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - - **Source**: ファイル名のパターンを`[file_name].csv`の形式で入力してください。例: `TableName.01.csv` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 + - **Source**: ファイル名のパターンを`[file_name].csv`の形式で入力してください。例: `TableName.01.csv` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 - - `my-data?.csv` : `my-data` `my-data1.csv`や`my-data2.csv`のような 1 文字が続くすべての CSV ファイルに一致します。 - - `my-data*.csv` : `my-data`で始まるすべての CSV ファイルに一致します。たとえば`my-data-2023.csv`や`my-data-final.csv`などです。 + - `my-data?.csv` : `my-data` `my-data1.csv`や`my-data2.csv`のような 1 文字が続くすべての CSV ファイルに一致します。 + - `my-data*.csv` : `my-data`で始まるすべての CSV ファイルに一致します。たとえば`my-data-2023.csv`や`my-data-final.csv`などです。 - - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを入力してください。 + - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを入力してください。 必要に応じて、 **Edit CSV Configuration**をクリックして、CSVファイルに合わせてオプションを設定してください。区切り文字や区切り記号の設定、エスケープ文字にバックスラッシュを使用するかどうかの指定、ファイルにヘッダー行が含まれているかどうかの指定が可能です。 -6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 +6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
@@ -287,10 +287,10 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に インポートエラーが発生した場合は、以下の手順を実行してください。 -1. 部分的にインポートされたテーブルを削除します。 -2. テーブルスキーマファイルを確認してください。エラーがある場合は、テーブルスキーマファイルを修正してください。 -3. CSVファイル内のデータ型を確認してください。 -4. インポートタスクをもう一度実行してみてください。 +1. 部分的にインポートされたテーブルを削除します。 +2. テーブルスキーマファイルを確認してください。エラーがある場合は、テーブルスキーマファイルを修正してください。 +3. CSVファイル内のデータ型を確認してください。 +4. インポートタスクをもう一度実行してみてください。 ## トラブルシューティング {#troubleshooting} diff --git a/tidb-cloud/import-parquet-files-serverless.md b/tidb-cloud/import-parquet-files-serverless.md index e223f505ed27d..d5169ad280f8f 100644 --- a/tidb-cloud/import-parquet-files-serverless.md +++ b/tidb-cloud/import-parquet-files-serverless.md @@ -9,9 +9,9 @@ TiDB Cloud StarterまたはTiDB Cloud Essential[Apache Parquet](https://parquet. > **Note:** > -> - TiDB Cloud Dedicatedについては、[クラウドストレージからParquetファイルをTiDB Cloud Dedicatedにインポートする](/tidb-cloud/import-parquet-files.md)。 -> - TiDB Cloud は、空のテーブルへの Parquet ファイルのインポートのみをサポートしています。既にデータが含まれている既存のテーブルにデータをインポートするには、このドキュメントの手順に従って一時的な空のテーブルにデータをインポートし、 `INSERT SELECT`ステートメントを使用してデータを対象の既存のテーブルにコピーします。 -> - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)に存在する必要があります。 Snappy 圧縮の他のバリアントはサポートされていません。 +> - TiDB Cloud Dedicatedについては、[クラウドストレージからParquetファイルをTiDB Cloud Dedicatedにインポートする](/tidb-cloud/import-parquet-files.md)。 +> - TiDB Cloud は、空のテーブルへの Parquet ファイルのインポートのみをサポートしています。既にデータが含まれている既存のテーブルにデータをインポートするには、このドキュメントの手順に従って一時的な空のテーブルにデータをインポートし、 `INSERT SELECT`ステートメントを使用してデータを対象の既存のテーブルにコピーします。 +> - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)に存在する必要があります。 Snappy 圧縮の他のバリアントはサポートされていません。 ## ステップ1. Parquetファイルを準備する {#step-1-prepare-the-parquet-files} @@ -19,21 +19,21 @@ TiDB Cloud StarterまたはTiDB Cloud Essential[Apache Parquet](https://parquet. > > 現在、 TiDB Cloud、[サポートされているデータ型](#supported-data-types)のデータ型を含む Parquet ファイルのインポートはサポートされていません。インポートする Parquet ファイルにこれらのデータ型が含まれている場合は、まず (例: `STRING` ) を使用して Parquet ファイルを再生成する必要があります。または、AWS Glue などのサービスを使用してデータ型を簡単に変換することもできます。 > -> - `LIST` -> - `NEST STRUCT` -> - `BOOL` -> - `ARRAY` -> - `MAP` +> - `LIST` +> - `NEST STRUCT` +> - `BOOL` +> - `ARRAY` +> - `MAP` -1. Parquetファイルが256MBを超える場合は、それぞれ約256MBのサイズの小さなファイルに分割することを検討してください。 +1. Parquetファイルが256MBを超える場合は、それぞれ約256MBのサイズの小さなファイルに分割することを検討してください。 TiDB Cloudは非常に大きなParquetファイルのインポートをサポートしていますが、256MB程度の複数の入力ファイルを使用した場合に最高のパフォーマンスを発揮します。これは、 TiDB Cloudが複数のファイルを並列処理できるため、インポート速度を大幅に向上させることができるからです。 -2. Parquetファイルの名前は以下のようにしてください。 +2. Parquetファイルの名前は以下のようにしてください。 - - Parquet ファイルにテーブル全体のデータがすべて含まれている場合は、ファイルを`${db_name}.${table_name}.parquet`形式で命名してください。この形式は、データをインポートする際に`${db_name}.${table_name}`テーブルにマッピングされます。 + - Parquet ファイルにテーブル全体のデータがすべて含まれている場合は、ファイルを`${db_name}.${table_name}.parquet`形式で命名してください。この形式は、データをインポートする際に`${db_name}.${table_name}`テーブルにマッピングされます。 - - 1つのテーブルのデータが複数のParquetファイルに分割されている場合は、これらのParquetファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.parquet`と`${db_name}.${table_name}.000002.parquet`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 + - 1つのテーブルのデータが複数のParquetファイルに分割されている場合は、これらのParquetファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.parquet`と`${db_name}.${table_name}.000002.parquet`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 > **Note:** > @@ -43,11 +43,11 @@ TiDB Cloud StarterまたはTiDB Cloud Essential[Apache Parquet](https://parquet. Parquetファイルにはスキーマ情報が含まれていないため、ParquetファイルからTiDB Cloudにデータをインポートする前に、以下のいずれかの方法を使用してテーブルスキーマを作成する必要があります。 -- 方法1： TiDB Cloudで、ソースデータ用のターゲットデータベースとテーブルを作成します。 +- 方法1： TiDB Cloudで、ソースデータ用のターゲットデータベースとテーブルを作成します。 -- 方法2：Parquetファイルが配置されているAmazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object Storage Serviceのディレクトリで、ソースデータのターゲットテーブルスキーマファイルを次のように作成します。 +- 方法2：Parquetファイルが配置されているAmazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object Storage Serviceのディレクトリで、ソースデータのターゲットテーブルスキーマファイルを次のように作成します。 - 1. ソースデータ用のデータベーススキーマファイルを作成します。 + 1. ソースデータ用のデータベーススキーマファイルを作成します。 [ステップ1](#step-1-prepare-the-parquet-files)の命名規則に従ってParquetファイルが作成されている場合、データベーススキーマファイルはデータインポートにおいてオプションです。そうでない場合は、データベーススキーマファイルは必須です。 @@ -59,7 +59,7 @@ Parquetファイルにはスキーマ情報が含まれていないため、Parq CREATE DATABASE mydb; ``` - 2. ソースデータ用のテーブルスキーマファイルを作成します。 + 2. ソースデータ用のテーブルスキーマファイルを作成します。 Parquet ファイルが格納されている Amazon S3、GCS、Azure Blob Storage、または Alibaba Cloud Object Storage Service ディレクトリにテーブルスキーマファイルを含めない場合、 TiDB Cloud はデータのインポート時に対応するテーブルを作成しません。 @@ -82,15 +82,15 @@ Parquetファイルにはスキーマ情報が含まれていないため、Parq TiDB CloudがAmazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object Storage Serviceバケット内のParquetファイルにアクセスできるようにするには、次のいずれかの操作を行います。 -- Parquet ファイルが Amazon S3 にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 +- Parquet ファイルが Amazon S3 にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-parquet-files)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 -- Parquet ファイルが GCS にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 +- Parquet ファイルが GCS にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 -- Parquet ファイルが Azure Blob Storage に配置されている場合は、 TiDB Cloud StarterまたはEssentialインスタンスの[Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)。 +- Parquet ファイルが Azure Blob Storage に配置されている場合は、 TiDB Cloud StarterまたはEssentialインスタンスの[Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)。 -- Parquet ファイルが Alibaba Cloud Object Storage Service (OSS) にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスの[Alibaba Cloud Object Storage Service (OSS) へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 +- Parquet ファイルが Alibaba Cloud Object Storage Service (OSS) にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスの[Alibaba Cloud Object Storage Service (OSS) へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 ## ステップ4．Parquetファイルをインポートする {#step-4-import-parquet-files} @@ -99,31 +99,31 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン
-1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 +1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Amazon S3**を選択してください。 - - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `s3://sampledata/ingest/TableName.01.parquet` 。 - - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://sampledata/ingest/` 。 - - **Credential**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 - - **AWS Role ARN** ：AWSロールARNの値を入力してください。 - - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 + - **Storage Provider**： **Amazon S3**を選択してください。 + - **Source Files URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `s3://sampledata/ingest/TableName.01.parquet` 。 + - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://sampledata/ingest/` 。 + - **Credential**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 + - **AWS Role ARN** ：AWSロールARNの値を入力してください。 + - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 +5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 **Source Files URI**でディレクトリが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションがデフォルトで選択されます。 @@ -131,50 +131,50 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマップできるようにするには、このオプションを選択したままにして、データ形式として**Parquet**を選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマップできるようにするには、このオプションを選択したままにして、データ形式として**Parquet**を選択します。 - - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - - **Source**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 + - **Source**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 - - `my-data?.parquet` : `my-data` `my-data1.parquet`や`my-data2.parquet`のような 1 文字が続くすべての Parquet ファイルに一致します。 - - `my-data*.parquet` : `my-data`で始まるすべての Parquet ファイルに一致します。たとえば`my-data-2023.parquet`や`my-data-final.parquet`などです。 + - `my-data?.parquet` : `my-data` `my-data1.parquet`や`my-data2.parquet`のような 1 文字が続くすべての Parquet ファイルに一致します。 + - `my-data*.parquet` : `my-data`で始まるすべての Parquet ファイルに一致します。たとえば`my-data-2023.parquet`や`my-data-final.parquet`などです。 - - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 + - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 -6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 +6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
-1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 +1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Google Cloud Storage**を選択してください。 - - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[gcs|gs]://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `[gcs|gs]://sampledata/ingest/TableName.01.parquet` 。 - - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[gcs|gs]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[gcs|gs]://sampledata/ingest/` 。 - - **Credential**: GCS IAM役割サービス アカウント キーを使用してバケットにアクセスできます。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)を参照してください。 + - **Storage Provider**： **Google Cloud Storage**を選択してください。 + - **Source Files URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[gcs|gs]://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `[gcs|gs]://sampledata/ingest/TableName.01.parquet` 。 + - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[gcs|gs]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[gcs|gs]://sampledata/ingest/` 。 + - **Credential**: GCS IAM役割サービス アカウント キーを使用してバケットにアクセスできます。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)を参照してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 +5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 **Source Files URI**でディレクトリが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションがデフォルトで選択されます。 @@ -182,50 +182,50 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet**を選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet**を選択します。 - - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - - **Source**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 + - **Source**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 - - `my-data?.parquet` : `my-data` `my-data1.parquet`や`my-data2.parquet`のような 1 文字が続くすべての Parquet ファイルに一致します。 - - `my-data*.parquet` : `my-data`で始まるすべての Parquet ファイルに一致します。たとえば`my-data-2023.parquet`や`my-data-final.parquet`などです。 + - `my-data?.parquet` : `my-data` `my-data1.parquet`や`my-data2.parquet`のような 1 文字が続くすべての Parquet ファイルに一致します。 + - `my-data*.parquet` : `my-data`で始まるすべての Parquet ファイルに一致します。たとえば`my-data-2023.parquet`や`my-data-final.parquet`などです。 - - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 + - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 -6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 +6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
-1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 +1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Azure Blob Storage**を選択します。 - - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[azure|https]://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `[azure|https]://sampledata/ingest/TableName.01.parquet` 。 - - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[azure|https]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[azure|https]://sampledata/ingest/` 。 - - **Credential**: Shared Access Signature (SAS) トークンを使用してバケットにアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 + - **Storage Provider**： **Azure Blob Storage**を選択します。 + - **Source Files URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[azure|https]://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `[azure|https]://sampledata/ingest/TableName.01.parquet` 。 + - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[azure|https]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[azure|https]://sampledata/ingest/` 。 + - **Credential**: Shared Access Signature (SAS) トークンを使用してバケットにアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)を参照してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 +5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 **Source Files URI**でディレクトリが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションがデフォルトで選択されます。 @@ -233,50 +233,50 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet**を選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet**を選択します。 - - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - - **Source**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 + - **Source**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 - - `my-data?.parquet` : `my-data` `my-data1.parquet`や`my-data2.parquet`のような 1 文字が続くすべての Parquet ファイルに一致します。 - - `my-data*.parquet` : `my-data`で始まるすべての Parquet ファイルに一致します。たとえば`my-data-2023.parquet`や`my-data-final.parquet`などです。 + - `my-data?.parquet` : `my-data` `my-data1.parquet`や`my-data2.parquet`のような 1 文字が続くすべての Parquet ファイルに一致します。 + - `my-data*.parquet` : `my-data`で始まるすべての Parquet ファイルに一致します。たとえば`my-data-2023.parquet`や`my-data-final.parquet`などです。 - - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 + - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 -6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 +6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
-1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 +1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Alibaba Cloud OSS**を選択してください。 - - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `oss://sampledata/ingest/TableName.01.parquet` 。 - - 複数のファイルをインポートする場合は、ソースフォルダの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)を参照してください。 + - **Storage Provider**： **Alibaba Cloud OSS**を選択してください。 + - **Source Files URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `oss://sampledata/ingest/TableName.01.parquet` 。 + - 複数のファイルをインポートする場合は、ソースフォルダの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)を参照してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 +5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 **Source Files URI**でディレクトリが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションがデフォルトで選択されます。 @@ -284,22 +284,22 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloudは**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet**を選択します。 + - TiDB Cloud が[ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソース ファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet**を選択します。 - - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - - **Source**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 + - **Source**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。 `*`と`?`ワイルドカードのみがサポートされています。 - - `my-data?.parquet` : `my-data` `my-data1.parquet`や`my-data2.parquet`のような 1 文字が続くすべての Parquet ファイルに一致します。 - - `my-data*.parquet` : `my-data`で始まるすべての Parquet ファイルに一致します。たとえば`my-data-2023.parquet`や`my-data-final.parquet`などです。 + - `my-data?.parquet` : `my-data` `my-data1.parquet`や`my-data2.parquet`のような 1 文字が続くすべての Parquet ファイルに一致します。 + - `my-data*.parquet` : `my-data`で始まるすべての Parquet ファイルに一致します。たとえば`my-data-2023.parquet`や`my-data-final.parquet`などです。 - - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 + - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを選択します。 -6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 +6. **Next**をクリックしてください。TiDB Cloudがソースファイルを適切にスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
@@ -309,15 +309,15 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン インポートエラーが発生した場合は、以下の手順を実行してください。 -1. 部分的にインポートされたテーブルを削除します。 +1. 部分的にインポートされたテーブルを削除します。 -2. テーブルスキーマファイルを確認してください。エラーがある場合は、テーブルスキーマファイルを修正してください。 +2. テーブルスキーマファイルを確認してください。エラーがある場合は、テーブルスキーマファイルを修正してください。 -3. Parquetファイル内のデータ型を確認してください。 +3. Parquetファイル内のデータ型を確認してください。 Parquet ファイルにサポートされていないデータ型 (たとえば、 `NEST STRUCT` 、 `ARRAY` 、または`MAP` ) が含まれている場合は、サポートされているデータ[サポートされているデータ型](#supported-data-types)(たとえば、 `STRING` )。 -4. インポートタスクをもう一度実行してみてください。 +4. インポートタスクをもう一度実行してみてください。 ## サポートされているデータ型 {#supported-data-types} diff --git a/tidb-cloud/import-parquet-files.md b/tidb-cloud/import-parquet-files.md index 6757b8f60141b..7a8c5682d2ac2 100644 --- a/tidb-cloud/import-parquet-files.md +++ b/tidb-cloud/import-parquet-files.md @@ -13,9 +13,9 @@ summary: Amazon S3、GCS、またはAzure Blob StorageからTiDB Cloud Dedicated ## 制限事項 {#limitations} -- データの一貫性を確保するため、 TiDB Cloud では Parquet ファイルを空のテーブルにのみインポートできます。既にデータが含まれている既存のテーブルにデータをインポートするには、このドキュメントの手順に従ってTiDB Cloud を使用して一時的な空のテーブルにデータをインポートし、その後`INSERT SELECT`ステートメントを使用してデータを対象の既存のテーブルにコピーします。 +- データの一貫性を確保するため、 TiDB Cloud では Parquet ファイルを空のテーブルにのみインポートできます。既にデータが含まれている既存のテーブルにデータをインポートするには、このドキュメントの手順に従ってTiDB Cloud を使用して一時的な空のテーブルにデータをインポートし、その後`INSERT SELECT`ステートメントを使用してデータを対象の既存のテーブルにコピーします。 -- TiDB Cloud Dedicatedクラスターに[変更フィード](/tidb-cloud/changefeed-overview.md)があるか、 [特定時点への復元](/tidb-cloud/backup-and-restore.md#turn-on-point-in-time-restore)が有効になっている場合、現在のデータインポート機能は[物理インポートモード](https://docs.pingcap.com/tidb/stable/tidb-lightning-physical-import-mode)を使用しているため、クラスターにデータをインポートできません ([**Import Data**ボタンが無効になります)。このモードでは、インポートされたデータは変更ログを生成しないため、変更フィードとポイントインタイム リストアはインポートされたデータを検出できません。 +- TiDB Cloud Dedicatedクラスターに[変更フィード](/tidb-cloud/changefeed-overview.md)があるか、 [特定時点への復元](/tidb-cloud/backup-and-restore.md#turn-on-point-in-time-restore)が有効になっている場合、現在のデータインポート機能は[物理インポートモード](https://docs.pingcap.com/tidb/stable/tidb-lightning-physical-import-mode)を使用しているため、クラスターにデータをインポートできません ([**Import Data**ボタンが無効になります)。このモードでは、インポートされたデータは変更ログを生成しないため、変更フィードとポイントインタイム リストアはインポートされたデータを検出できません。 ## ステップ1. Parquetファイルを準備する {#step-1-prepare-the-parquet-files} @@ -23,36 +23,36 @@ summary: Amazon S3、GCS、またはAzure Blob StorageからTiDB Cloud Dedicated > > 現在、 TiDB Cloud、[サポートされているデータ型](#supported-data-types)のデータ型を含む Parquet ファイルのインポートはサポートされていません。インポートする Parquet ファイルにこれらのデータ型が含まれている場合は、まず (例: `STRING` ) を使用して Parquet ファイルを再生成する必要があります。または、AWS Glue などのサービスを使用してデータ型を簡単に変換することもできます。 > -> - `LIST` -> - `NEST STRUCT` -> - `BOOL` -> - `ARRAY` -> - `MAP` +> - `LIST` +> - `NEST STRUCT` +> - `BOOL` +> - `ARRAY` +> - `MAP` -1. Parquetファイルが256MBを超える場合は、それぞれ約256MBのサイズの小さなファイルに分割することを検討してください。 +1. Parquetファイルが256MBを超える場合は、それぞれ約256MBのサイズの小さなファイルに分割することを検討してください。 TiDB Cloudは非常に大きなParquetファイルのインポートをサポートしていますが、256MB程度の複数の入力ファイルを使用した場合に最高のパフォーマンスを発揮します。これは、 TiDB Cloudが複数のファイルを並列処理できるため、インポート速度を大幅に向上させることができるからです。 -2. Parquetファイルの名前は以下のようにしてください。 +2. Parquetファイルの名前は以下のようにしてください。 - - Parquet ファイルにテーブル全体のデータがすべて含まれている場合は、ファイルを`${db_name}.${table_name}.parquet`形式で命名してください。この形式は、データをインポートする際に`${db_name}.${table_name}`テーブルにマッピングされます。 + - Parquet ファイルにテーブル全体のデータがすべて含まれている場合は、ファイルを`${db_name}.${table_name}.parquet`形式で命名してください。この形式は、データをインポートする際に`${db_name}.${table_name}`テーブルにマッピングされます。 - - 1つのテーブルのデータが複数のParquetファイルに分割されている場合は、これらのParquetファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.parquet`と`${db_name}.${table_name}.000002.parquet`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 + - 1つのテーブルのデータが複数のParquetファイルに分割されている場合は、これらのParquetファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.parquet`と`${db_name}.${table_name}.000002.parquet`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 > **Note:** > - > - 前述のルールに従って Parquet ファイル名を更新できない場合 (たとえば、Parquet ファイル リンクが他のプログラムでも使用されている場合)、ファイル名を変更せずに、 [ステップ4](#step-4-import-parquet-files-to-tidb-cloud)の**Destination Mapping**サブステップで**自動マッピングにTiDBファイル命名規則を使用する**の選択を解除して、ソース ファイルを単一のターゲット テーブルに手動でマッピングできます。 - > - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)に存在する必要があります。 Snappy 圧縮の他のバリアントはサポートされていません。 + > - 前述のルールに従って Parquet ファイル名を更新できない場合 (たとえば、Parquet ファイル リンクが他のプログラムでも使用されている場合)、ファイル名を変更せずに、 [ステップ4](#step-4-import-parquet-files-to-tidb-cloud)の**Destination Mapping**サブステップで**自動マッピングにTiDBファイル命名規則を使用する**の選択を解除して、ソース ファイルを単一のターゲット テーブルに手動でマッピングできます。 + > - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)に存在する必要があります。 Snappy 圧縮の他のバリアントはサポートされていません。 ## ステップ2．対象テーブルのスキーマを作成する {#step-2-create-the-target-table-schemas} Parquetファイルにはスキーマ情報が含まれていないため、ParquetファイルからTiDB Cloudにデータをインポートする前に、以下のいずれかの方法を使用してテーブルスキーマを作成する必要があります。 -- 方法1： TiDB Cloudで、ソースデータ用のターゲットデータベースとテーブルを作成します。 +- 方法1： TiDB Cloudで、ソースデータ用のターゲットデータベースとテーブルを作成します。 -- 方法2：Parquetファイルが保存されているAmazon S3、GCS、またはAzure Blob Storageディレクトリに、ソースデータのターゲットテーブルスキーマファイルを次のように作成します。 +- 方法2：Parquetファイルが保存されているAmazon S3、GCS、またはAzure Blob Storageディレクトリに、ソースデータのターゲットテーブルスキーマファイルを次のように作成します。 - 1. ソースデータ用のデータベーススキーマファイルを作成します。 + 1. ソースデータ用のデータベーススキーマファイルを作成します。 [ステップ1](#step-1-prepare-the-parquet-files)の命名規則に従ってParquetファイルが作成されている場合、データベーススキーマファイルはデータインポートにおいてオプションです。そうでない場合は、データベーススキーマファイルは必須です。 @@ -64,7 +64,7 @@ Parquetファイルにはスキーマ情報が含まれていないため、Parq CREATE DATABASE mydb; ``` - 2. ソースデータ用のテーブルスキーマファイルを作成します。 + 2. ソースデータ用のテーブルスキーマファイルを作成します。 Parquet ファイルが格納されている Amazon S3、GCS、または Azure Blob Storage ディレクトリにテーブルスキーマファイルを含めない場合、 TiDB Cloud はデータのインポート時に対応するテーブルを作成しません。 @@ -87,13 +87,13 @@ Parquetファイルにはスキーマ情報が含まれていないため、Parq TiDB CloudがAmazon S3バケット、GCSバケット、またはAzure Blob Storageコンテナ内のParquetファイルにアクセスできるようにするには、次のいずれかの操作を行います。 -- Parquet ファイルが Amazon S3 にある場合は、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 +- Parquet ファイルが Amazon S3 にある場合は、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、 [ステップ4](#step-4-import-parquet-files-to-tidb-cloud)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 -- Parquet ファイルが GCS にある場合は、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 +- Parquet ファイルが GCS にある場合は、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 -- Parquet ファイルが Azure Blob Storage に配置されている場合は、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)。 +- Parquet ファイルが Azure Blob Storage に配置されている場合は、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)。 ## ステップ4. ParquetファイルをTiDB Cloudにインポートする {#step-4-import-parquet-files-to-tidb-cloud} @@ -102,31 +102,31 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順
-1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Amazon S3**を選択してください。 - - **Source URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `s3://mybucket/myfolder/TableName.01.parquet` 。 - - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://mybucket/myfolder/` 。 - - **Credentials**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)を参照してください。 - - **AWS Role ARN** (推奨): AWS ロール ARN の値を入力します。まだロール ARN がない場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロール ARN を作成する]**をクリックし、画面の指示に従うか、 **[問題が発生しましたか?] ダイアログでロール ARN を手動で作成して、**クラスターの**TiDB Cloud Account ID**と**TiDB Cloud External ID**を取得し、 IAMロールを手動で作成します。 - - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 + - **Storage Provider**： **Amazon S3**を選択してください。 + - **Source URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `s3://mybucket/myfolder/TableName.01.parquet` 。 + - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://mybucket/myfolder/` 。 + - **Credentials**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)を参照してください。 + - **AWS Role ARN** (推奨): AWS ロール ARN の値を入力します。まだロール ARN がない場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロール ARN を作成する]**をクリックし、画面の指示に従うか、 **[問題が発生しましたか?] ダイアログでロール ARN を手動で作成して、**クラスターの**TiDB Cloud Account ID**と**TiDB Cloud External ID**を取得し、 IAMロールを手動で作成します。 + - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 +5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 **Source URI**でディレクトリを指定すると、 TiDB Cloudはデフォルトで**自動マッピングにTiDBファイル命名規則を使用する**オプションを選択します。 @@ -134,50 +134,50 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 > > **Source URI**で単一のファイルを指定すると、 TiDB Cloudは**自動マッピングにTiDBファイル命名規則を使用する**オプションを表示せず、**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを入力するだけで済みます。 - - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet**を選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 + - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet**を選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 - - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - - **Source**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 + - **Source**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 - - `my-data?.parquet` : `my-data` `my-data1.parquet`や`my-data2.parquet`のような 1 文字が続くすべての Parquet ファイルに一致します。 - - `my-data*.parquet` : `my-data`で始まるすべての Parquet ファイルに一致します。たとえば`my-data10.parquet`や`my-data100.parquet`などです。 + - `my-data?.parquet` : `my-data` `my-data1.parquet`や`my-data2.parquet`のような 1 文字が続くすべての Parquet ファイルに一致します。 + - `my-data*.parquet` : `my-data`で始まるすべての Parquet ファイルに一致します。たとえば`my-data10.parquet`や`my-data100.parquet`などです。 - - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを入力してください。 + - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを入力してください。 -6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 +6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
-1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Google Cloud Storage**を選択してください。 - - **Source URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`gs://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `gs://mybucket/myfolder/TableName.01.parquet` 。 - - 複数のファイルをインポートする場合は、ソースフォルダのURIを`gs://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `gs://mybucket/myfolder/` 。 - - **Credentials**: 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)を参照してください。 + - **Storage Provider**： **Google Cloud Storage**を選択してください。 + - **Source URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`gs://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `gs://mybucket/myfolder/TableName.01.parquet` 。 + - 複数のファイルをインポートする場合は、ソースフォルダのURIを`gs://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `gs://mybucket/myfolder/` 。 + - **Credentials**: 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. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 +5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 **Source URI**でディレクトリを指定すると、 TiDB Cloudはデフォルトで**自動マッピングにTiDBファイル命名規則を使用する**オプションを選択します。 @@ -185,75 +185,75 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 > > **Source URI**で単一のファイルを指定すると、 TiDB Cloudは**自動マッピングにTiDBファイル命名規則を使用する**オプションを表示せず、**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを入力するだけで済みます。 - - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet**を選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 + - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet**を選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 - - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - - **Source**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 + - **Source**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 - - `my-data?.parquet` : `my-data` `my-data1.parquet`や`my-data2.parquet`のような 1 文字が続くすべての Parquet ファイルに一致します。 - - `my-data*.parquet` : `my-data`で始まるすべての Parquet ファイルに一致します。たとえば`my-data10.parquet`や`my-data100.parquet`などです。 + - `my-data?.parquet` : `my-data` `my-data1.parquet`や`my-data2.parquet`のような 1 文字が続くすべての Parquet ファイルに一致します。 + - `my-data*.parquet` : `my-data`で始まるすべての Parquet ファイルに一致します。たとえば`my-data10.parquet`や`my-data100.parquet`などです。 - - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを入力してください。 + - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを入力してください。 -6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 +6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
-1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Azure Blob Storage**を選択します。 + - **Storage Provider**： **Azure Blob Storage**を選択します。 - - **Source URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `https://myaccount.blob.core.windows.net/mycontainer/myfolder/TableName.01.parquet` 。 - - 複数のファイルをインポートする場合は、ソースフォルダのURIを`https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/`の形式で入力してください。例： `https://myaccount.blob.core.windows.net/mycontainer/myfolder/` 。 + - **Source URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `https://myaccount.blob.core.windows.net/mycontainer/myfolder/TableName.01.parquet` 。 + - 複数のファイルをインポートする場合は、ソースフォルダのURIを`https://[account_name].blob.core.windows.net/[container_name]/[data_source_folder]/`の形式で入力してください。例： `https://myaccount.blob.core.windows.net/mycontainer/myfolder/` 。 - - **Connectivity Method**： TiDB CloudがAzure Blob Storageに接続する方法を選択してください。 + - **Connectivity Method**： TiDB CloudがAzure Blob Storageに接続する方法を選択してください。 - - **Public**（デフォルト）：パブリックインターネット経由で接続します。ストレージアカウントがパブリックネットワークへのアクセスを許可している場合にこのオプションを使用してください。 - - **Private Link**：Azure プライベートエンドポイント経由で接続し、ネットワークから隔離されたアクセスを実現します。ストレージアカウントがパブリックアクセスをブロックしている場合、またはセキュリティポリシーでプライベート接続が必要な場合にこのオプションを使用します。**Private Link**を選択した場合は、追加フィールド**Azure Blob Storage Resource ID**も入力する必要があります。リソース ID を確認するには： + - **Public**（デフォルト）：パブリックインターネット経由で接続します。ストレージアカウントがパブリックネットワークへのアクセスを許可している場合にこのオプションを使用してください。 + - **Private Link**：Azure プライベートエンドポイント経由で接続し、ネットワークから隔離されたアクセスを実現します。ストレージアカウントがパブリックアクセスをブロックしている場合、またはセキュリティポリシーでプライベート接続が必要な場合にこのオプションを使用します。**Private Link**を選択した場合は、追加フィールド**Azure Blob Storage Resource ID**も入力する必要があります。リソース ID を確認するには： - 1. [Azureポータル](https://portal.azure.com/)にアクセスします。 - 2. ストレージアカウントに移動し、 **Overview** > **JSON View**をクリックします。 - 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/`の形式です。 + 1. [Azureポータル](https://portal.azure.com/)にアクセスします。 + 2. ストレージアカウントに移動し、 **Overview** > **JSON View**をクリックします。 + 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/`の形式です。 - - **Credentials**: TiDB Cloud がAzure Blob Storage コンテナー内のソース ファイルにアクセスできるようにするためのアカウント SAS トークンを入力します。まだお持ちでない場合は、 **[ここをクリックして Azure ARM テンプレートを使用して新しいものを作成する]**をクリックし、画面の指示に従うか、アカウント SAS トークンを手動で作成します。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)を参照してください。 + - **Credentials**: TiDB Cloud がAzure Blob Storage コンテナー内のソース ファイルにアクセスできるようにするためのアカウント SAS トークンを入力します。まだお持ちでない場合は、 **[ここをクリックして Azure ARM テンプレートを使用して新しいものを作成する]**をクリックし、画面の指示に従うか、アカウント SAS トークンを手動で作成します。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)を参照してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。ウィザードを続行するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 - 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 + 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 - 2. **Networking** > **Private endpoint connections**をクリックします。 + 2. **Networking** > **Private endpoint connections**をクリックします。 - 3. TiDB Cloudからの保留中の接続要求を見つけて、 **Approve**をクリックします。 + 3. TiDB Cloudからの保留中の接続要求を見つけて、 **Approve**をクリックします。 - 4. [TiDB Cloudコンソール](https://tidbcloud.com/)に戻ります。エンドポイントが承認されると、インポート ウィザードが自動的に続行されます。 + 4. [TiDB Cloudコンソール](https://tidbcloud.com/)に戻ります。エンドポイントが承認されると、インポート ウィザードが自動的に続行されます。 > **Note:** > > エンドポイントがまだ承認されていない場合、 TiDB Cloud は接続が承認待ちであることを示すメッセージを表示します。Azure でリクエスト[Azureポータル](https://portal.azure.com/)承認してから、再試行してください。 -5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 +5. **Destination Mapping**セクションで、ソースファイルをターゲットテーブルにどのようにマッピングするかを指定します。 **Source URI**でディレクトリを指定すると、 TiDB Cloudはデフォルトで**自動マッピングにTiDBファイル命名規則を使用する**オプションを選択します。 @@ -261,22 +261,22 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 > > **Source URI**で単一のファイルを指定すると、 TiDB Cloudは**自動マッピングにTiDBファイル命名規則を使用する**オプションを表示せず、**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを入力するだけで済みます。 - - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet**を選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 + - TiDB Cloud が[TiDBファイルの命名規則](/tidb-cloud/naming-conventions-for-data-import.md)に従うすべてのソースファイルを対応するテーブルに自動的にマッピングするには、このオプションを選択したままにして、データ形式として**Parquet**を選択します。ソースフォルダにスキーマファイル ( `${db_name}-schema-create.sql`や`${db_name}.${table_name}-schema.sql`など) が含まれている場合、 TiDB Cloud は、ターゲットデータベースとテーブルがまだ存在しない場合に、それらを使用して作成します。 - - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 + - ソース Parquet ファイルをターゲットのデータベースおよびテーブルに関連付けるためのマッピング ルールを手動で構成するには、このオプションの選択を解除し、次のフィールドに入力します。 - - **Source**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 + - **Source**: ファイル名のパターンを`[file_name].parquet`の形式で入力してください。例: `TableName.01.parquet` 。ワイルドカードを使用して複数のファイルを照合することもできます。TiDB Cloud は`*`と`?`のワイルドカードのみをサポートしています。 - - `my-data?.parquet` : `my-data` `my-data1.parquet`や`my-data2.parquet`のような 1 文字が続くすべての Parquet ファイルに一致します。 - - `my-data*.parquet` : `my-data`で始まるすべての Parquet ファイルに一致します。たとえば`my-data10.parquet`や`my-data100.parquet`などです。 + - `my-data?.parquet` : `my-data` `my-data1.parquet`や`my-data2.parquet`のような 1 文字が続くすべての Parquet ファイルに一致します。 + - `my-data*.parquet` : `my-data`で始まるすべての Parquet ファイルに一致します。たとえば`my-data10.parquet`や`my-data100.parquet`などです。 - - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを入力してください。 + - **Target Database**と**Target Table**：データをインポートする対象データベースとテーブルを入力してください。 -6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 +6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
@@ -286,15 +286,15 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 インポートエラーが発生した場合は、以下の手順を実行してください。 -1. 部分的にインポートされたテーブルを削除します。 +1. 部分的にインポートされたテーブルを削除します。 -2. テーブルスキーマファイルを確認してください。エラーがある場合は、テーブルスキーマファイルを修正してください。 +2. テーブルスキーマファイルを確認してください。エラーがある場合は、テーブルスキーマファイルを修正してください。 -3. Parquetファイル内のデータ型を確認してください。 +3. Parquetファイル内のデータ型を確認してください。 Parquet ファイルにサポートされていないデータ型 (たとえば、 `NEST STRUCT` 、 `ARRAY` 、または`MAP` ) が含まれている場合は、サポートされているデータ[サポートされているデータ型](#supported-data-types)(たとえば、 `STRING` )。 -4. インポートタスクをもう一度実行してみてください。 +4. インポートタスクをもう一度実行してみてください。 ## サポートされているデータ型 {#supported-data-types} diff --git a/tidb-cloud/import-sample-data-serverless.md b/tidb-cloud/import-sample-data-serverless.md index 1b12591d564d1..d3dad8b77aafd 100644 --- a/tidb-cloud/import-sample-data-serverless.md +++ b/tidb-cloud/import-sample-data-serverless.md @@ -11,39 +11,39 @@ summary: TiDB Cloud StarterまたはTiDB Cloud EssentialにUI経由でサンプ > > この文書で使用されているサンプルデータは、Amazon S3 から取得したものです。 -1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 +1. 対象のTiDB Cloud StarterまたはEssentialインスタンスの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Amazon S3**を選択してください。 - - **Source Files URI** ：サンプルデータURI `s3://tidbcloud-sample-data/data-ingestion/`を入力してください。 - - **Credential**： - - **AWS Role ARN** : `arn:aws:iam::801626783489:role/import-sample-access`を入力してください。 - - **AWS Access Key**：サンプルデータの場合はこのオプションをスキップしてください。 + - **Storage Provider**： **Amazon S3**を選択してください。 + - **Source Files URI** ：サンプルデータURI `s3://tidbcloud-sample-data/data-ingestion/`を入力してください。 + - **Credential**： + - **AWS Role ARN** : `arn:aws:iam::801626783489:role/import-sample-access`を入力してください。 + - **AWS Access Key**：サンプルデータの場合はこのオプションをスキップしてください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、 **自動マッピングにファイル命名規則を使用する**オプションが選択されたままになっていることを確認し、データ形式として**SQL**を選択します。 +5. **Destination Mapping**セクションで、 **自動マッピングにファイル命名規則を使用する**オプションが選択されたままになっていることを確認し、データ形式として**SQL**を選択します。 -6. **Next**をクリックしてください。 +6. **Next**をクリックしてください。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 TiDB Cloud StarterまたはEssentialインスタンスに接続した後、ターミナルでいくつかのクエリを実行して結果を確認できます。例： -1. 「12th & U St NW」から始まる旅行記録を取得してください。 +1. 「12th & U St NW」から始まる旅行記録を取得してください。 ```sql use bikeshare; @@ -70,7 +70,7 @@ TiDB Cloud StarterまたはEssentialインスタンスに接続した後、タ +-----------------+---------------+---------------------+---------------------+--------------------+------------------+-------------------------------------------+----------------+-----------+------------+-----------+------------+---------------+ ``` -2. 電動自転車で走行記録を取得しましょう： +2. 電動自転車で走行記録を取得しましょう： ```sql use bikeshare; diff --git a/tidb-cloud/import-sample-data.md b/tidb-cloud/import-sample-data.md index 8aad744faee7b..e16adfca3f99c 100644 --- a/tidb-cloud/import-sample-data.md +++ b/tidb-cloud/import-sample-data.md @@ -10,125 +10,125 @@ summary: TiDB Cloud DedicatedにUI経由でサンプルデータをインポー
-1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Amazon S3**を選択してください。 - - **Source URI** ：サンプルデータURI `s3://tidbcloud-sample-data/data-ingestion/`を入力してください。 - - **Credentials**: **AWS Role ARN**を選択し、 `arn:aws:iam::801626783489:role/import-sample-access`を入力します。 - - **AWS Access Key**：サンプルデータの場合はこのオプションをスキップしてください。 + - **Storage Provider**： **Amazon S3**を選択してください。 + - **Source URI** ：サンプルデータURI `s3://tidbcloud-sample-data/data-ingestion/`を入力してください。 + - **Credentials**: **AWS Role ARN**を選択し、 `arn:aws:iam::801626783489:role/import-sample-access`を入力します。 + - **AWS Access Key**：サンプルデータの場合はこのオプションをスキップしてください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、 **自動マッピングにTiDBファイル命名規則を使用する**を選択したまま、データ形式として**SQL**を選択します。 +5. **Destination Mapping**セクションで、 **自動マッピングにTiDBファイル命名規則を使用する**を選択したまま、データ形式として**SQL**を選択します。 -6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 +6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
-1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Google Cloud Storage**を選択してください。 - - **Source URI** ：サンプルデータURI `gs://tidbcloud-samples-us-west1/`を入力してください。 - - **Google CloudサービスアカウントID** ： TiDB Cloudは、このページにGoogle CloudサービスアカウントIDを表示します。サンプルデータURIを使用する場合は、そのまま続行できます。 + - **Storage Provider**： **Google Cloud Storage**を選択してください。 + - **Source URI** ：サンプルデータURI `gs://tidbcloud-samples-us-west1/`を入力してください。 + - **Google CloudサービスアカウントID** ： TiDB Cloudは、このページにGoogle CloudサービスアカウントIDを表示します。サンプルデータURIを使用する場合は、そのまま続行できます。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Destination Mapping**セクションで、 **自動マッピングにTiDBファイル命名規則を使用する**を選択したまま、データ形式として**SQL**を選択します。 +5. **Destination Mapping**セクションで、 **自動マッピングにTiDBファイル命名規則を使用する**を選択したまま、データ形式として**SQL**を選択します。 -6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 +6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
-1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスタの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Azure Blob Storage**を選択します。 + - **Storage Provider**： **Azure Blob Storage**を選択します。 - - **Source URI** ：サンプルデータURI `https://tcidmsampledata.blob.core.windows.net/sql/`を入力してください。 + - **Source URI** ：サンプルデータURI `https://tcidmsampledata.blob.core.windows.net/sql/`を入力してください。 - - **Connectivity Method**： TiDB CloudがAzure Blob Storageに接続する方法を選択します。サンプルデータをインポートするには、デフォルトの接続方法を使用できます。 + - **Connectivity Method**： TiDB CloudがAzure Blob Storageに接続する方法を選択します。サンプルデータをインポートするには、デフォルトの接続方法を使用できます。 - - **Public**（デフォルト）：パブリックインターネット経由で接続します。ストレージアカウントがパブリックネットワークへのアクセスを許可している場合にこのオプションを使用してください。 - - **Private Link**：Azure プライベートエンドポイント経由で接続し、ネットワークから隔離されたアクセスを実現します。ストレージアカウントがパブリックアクセスをブロックしている場合、またはセキュリティポリシーでプライベート接続が必要な場合にこのオプションを使用します。**Private Link**を選択した場合は、追加フィールド**Azure Blob Storage Resource ID**も入力する必要があります。リソース ID を確認するには： + - **Public**（デフォルト）：パブリックインターネット経由で接続します。ストレージアカウントがパブリックネットワークへのアクセスを許可している場合にこのオプションを使用してください。 + - **Private Link**：Azure プライベートエンドポイント経由で接続し、ネットワークから隔離されたアクセスを実現します。ストレージアカウントがパブリックアクセスをブロックしている場合、またはセキュリティポリシーでプライベート接続が必要な場合にこのオプションを使用します。**Private Link**を選択した場合は、追加フィールド**Azure Blob Storage Resource ID**も入力する必要があります。リソース ID を確認するには： - 1. [Azureポータル](https://portal.azure.com/)にアクセスします。 - 2. ストレージアカウントに移動し、 **Overview** > **JSON View**をクリックします。 - 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/`の形式です。 + 1. [Azureポータル](https://portal.azure.com/)にアクセスします。 + 2. ストレージアカウントに移動し、 **Overview** > **JSON View**をクリックします。 + 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/`の形式です。 - - **SAS Token**： + - **SAS Token**： - - サンプルデータには、次の**SAS Token**を使用してください： `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 Token**を使用してください： `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)を参照してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 接続方法として**Private Link**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。接続を開始するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 - 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 + 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 - 2. **Networking** > **Private endpoint connections**をクリックします。 + 2. **Networking** > **Private endpoint connections**をクリックします。 - 3. TiDB Cloudからの保留中の接続要求を見つけて、 **Approve**をクリックします。 + 3. TiDB Cloudからの保留中の接続要求を見つけて、 **Approve**をクリックします。 - 4. [TiDB Cloudコンソール](https://tidbcloud.com/)に戻ります。エンドポイントが承認されると、インポート ウィザードが自動的に続行されます。 + 4. [TiDB Cloudコンソール](https://tidbcloud.com/)に戻ります。エンドポイントが承認されると、インポート ウィザードが自動的に続行されます。 > **Note:** > > エンドポイントがまだ承認されていない場合、 TiDB Cloud は接続が承認待ちであることを示すメッセージを表示します。Azure でリクエスト[Azureポータル](https://portal.azure.com/)承認してから、再試行してください。 -5. **Destination Mapping**セクションで、 **自動マッピングにTiDBファイル命名規則を使用する**を選択したまま、データ形式として**SQL**を選択します。 +5. **Destination Mapping**セクションで、 **自動マッピングにTiDBファイル命名規則を使用する**を選択したまま、データ形式として**SQL**を選択します。 -6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 +6. **Next**をクリックします。TiDB Cloudがソースファイルをスキャンします。 -7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 +7. スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックします。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
@@ -137,7 +137,7 @@ summary: TiDB Cloud DedicatedにUI経由でサンプルデータをインポー クラスターに接続した後、ターミナルでいくつかのクエリを実行して結果を確認できます。例えば、次のようになります。 -1. 「12th & U St NW」から始まる旅行記録を取得してください。 +1. 「12th & U St NW」から始まる旅行記録を取得してください。 ```sql use bikeshare; @@ -164,7 +164,7 @@ summary: TiDB Cloud DedicatedにUI経由でサンプルデータをインポー +-----------------+---------------+---------------------+---------------------+--------------------+------------------+-------------------------------------------+----------------+-----------+------------+-----------+------------+---------------+ ``` -2. 電動自転車で走行記録を取得しましょう： +2. 電動自転車で走行記録を取得しましょう： ```sql use bikeshare; diff --git a/tidb-cloud/import-with-mysql-cli-serverless.md b/tidb-cloud/import-with-mysql-cli-serverless.md index d486c94d734b9..22e50cf02e8f7 100644 --- a/tidb-cloud/import-with-mysql-cli-serverless.md +++ b/tidb-cloud/import-with-mysql-cli-serverless.md @@ -11,24 +11,24 @@ summary: MySQL CLIを使用して、 TiDB Cloud StarterまたはTiDB Cloud Essen MySQL CLI を介してTiDB Cloud StarterまたはTiDB Cloud Essentialにデータをインポートするには、以下の前提条件を満たす必要があります。 -- TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにアクセスできます。お持ちでない場合は、 [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)」の手順に従って作成します。 -- ローカルコンピュータにMySQL CLIをインストールしてください。 +- TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにアクセスできます。お持ちでない場合は、 [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)」の手順に従って作成します。 +- ローカルコンピュータにMySQL CLIをインストールしてください。 ## ステップ1. TiDB Cloud StarterまたはEssentialインスタンスに接続します。 {#step-1-connect-to-your-tidb-cloud-starter-or-essential-instance} TiDB Cloud StarterまたはEssentialインスタンスに接続してください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud StarterまたはEssentialインスタンスの名前をクリックして、概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 +3. 接続ダイアログの設定がご使用のオペレーティング環境と一致していることを確認してください。 - - **Connection Type**は`Public`に設定されています。 - - **Connect With**`MySQL CLI`に設定されています。 - - お使いの環境に合った**Operating System**を選択してください。 + - **Connection Type**は`Public`に設定されています。 + - **Connect With**`MySQL CLI`に設定されています。 + - お使いの環境に合った**Operating System**を選択してください。 -4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 +4. **Generate Password**をクリックすると、ランダムなパスワードが生成されます。 > **Tip:** > @@ -62,9 +62,9 @@ SQLファイルまたはCSVファイルからデータをインポートでき SQLファイルからデータをインポートするには、以下の手順を実行してください。 -1. インポートしたいデータを含む実際のSQLファイル（例： `product_data.sql` ）を提供してください。このSQLファイルには、実際のデータを含む`INSERT`個のステートメントが含まれている必要があります。 +1. インポートしたいデータを含む実際のSQLファイル（例： `product_data.sql` ）を提供してください。このSQLファイルには、実際のデータを含む`INSERT`個のステートメントが含まれている必要があります。 -2. SQLファイルからデータをインポートするには、以下のコマンドを使用してください。 +2. SQLファイルからデータをインポートするには、以下のコマンドを使用してください。 ```bash mysql --comments --connect-timeout 150 -u '' -h -P 4000 -D test --ssl-mode=VERIFY_IDENTITY --ssl-ca= -p < product_data.sql @@ -79,9 +79,9 @@ SQLファイルからデータをインポートするには、以下の手順 CSVファイルからデータをインポートするには、以下の手順を実行してください。 -1. TiDBで、データインポートのニーズに合わせてデータベースとスキーマを作成します。 +1. TiDBで、データインポートのニーズに合わせてデータベースとスキーマを作成します。 -2. インポートしたいデータを含むサンプルCSVファイル（例： `product_data.csv` ）を提供してください。以下はCSVファイルの例です。 +2. インポートしたいデータを含むサンプルCSVファイル（例： `product_data.csv` ）を提供してください。以下はCSVファイルの例です。 **product_data.csv:** @@ -92,7 +92,7 @@ CSVファイルからデータをインポートするには、以下の手順 6,Tablet,299.99 ``` -3. 以下のコマンドを使用して、CSVファイルからデータをインポートします。 +3. 以下のコマンドを使用して、CSVファイルからデータをインポートします。 ```bash mysql --comments --connect-timeout 150 -u '' -h -P 4000 -D test --ssl-mode=VERIFY_IDENTITY --ssl-ca= -p -e "LOAD DATA LOCAL INFILE '' INTO TABLE products diff --git a/tidb-cloud/import-with-mysql-cli.md b/tidb-cloud/import-with-mysql-cli.md index 7a500e0a3288e..38865c11f4fa9 100644 --- a/tidb-cloud/import-with-mysql-cli.md +++ b/tidb-cloud/import-with-mysql-cli.md @@ -11,22 +11,22 @@ summary: MySQL CLIを使用してTiDB Cloud Dedicatedにデータをインポー MySQL CLI を介してTiDB Cloud Dedicatedにデータをインポートするには、以下の前提条件を満たす必要があります。 -- TiDB Cloud Dedicatedクラスターにアクセスできるようになりました。お持ちでない場合は、 [TiDB Cloud Dedicatedクラスターを作成する](/tidb-cloud/create-tidb-cluster.md)」の手順に従って作成してください。 -- ローカルコンピュータにMySQL CLIをインストールしてください。 +- TiDB Cloud Dedicatedクラスターにアクセスできるようになりました。お持ちでない場合は、 [TiDB Cloud Dedicatedクラスターを作成する](/tidb-cloud/create-tidb-cluster.md)」の手順に従って作成してください。 +- ローカルコンピュータにMySQL CLIをインストールしてください。 ## ステップ1. TiDB Cloud Dedicatedクラスターに接続します。 {#step-1-connect-to-your-tidb-cloud-dedicated-cluster} TiDB Cloud Dedicatedクラスターに接続してください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **Networking**ページで、 **IP Access List**領域の**Add IP Address**をクリックします。 +3. **Networking**ページで、 **IP Access List**領域の**Add IP Address**をクリックします。 -4. ダイアログで**Allow access from anywhere**を選択し、 **Confirm**をクリックします。 +4. ダイアログで**Allow access from anywhere**を選択し、 **Confirm**をクリックします。 -5. 右上隅にある**Connect**をクリックすると、接続情報ダイアログが開きます。 +5. 右上隅にある**Connect**をクリックすると、接続情報ダイアログが開きます。 接続文字列を取得する方法の詳細については、 [パブリック接続経由​​でTiDB Cloud Dedicatedに接続します](/tidb-cloud/connect-via-standard-connection.md)を参照してください。 @@ -58,9 +58,9 @@ SQLファイルまたはCSVファイルからデータをインポートでき SQLファイルからデータをインポートするには、以下の手順を実行してください。 -1. インポートしたいデータを含む実際のSQLファイル（例： `product_data.sql` ）を提供してください。このSQLファイルには、実際のデータを含む`INSERT`個のステートメントが含まれている必要があります。 +1. インポートしたいデータを含む実際のSQLファイル（例： `product_data.sql` ）を提供してください。このSQLファイルには、実際のデータを含む`INSERT`個のステートメントが含まれている必要があります。 -2. SQLファイルからデータをインポートするには、以下のコマンドを使用してください。 +2. SQLファイルからデータをインポートするには、以下のコマンドを使用してください。 ```bash mysql --comments --connect-timeout 150 -u '' -h -P 4000 -D test --ssl-mode=VERIFY_IDENTITY --ssl-ca= -p < product_data.sql @@ -75,9 +75,9 @@ SQLファイルからデータをインポートするには、以下の手順 CSVファイルからデータをインポートするには、以下の手順を実行してください。 -1. TiDBで、データインポートのニーズに合わせてデータベースとスキーマを作成します。 +1. TiDBで、データインポートのニーズに合わせてデータベースとスキーマを作成します。 -2. インポートしたいデータを含むサンプルCSVファイル（例： `product_data.csv` ）を提供してください。以下はCSVファイルの例です。 +2. インポートしたいデータを含むサンプルCSVファイル（例： `product_data.csv` ）を提供してください。以下はCSVファイルの例です。 **product_data.csv:** @@ -88,7 +88,7 @@ CSVファイルからデータをインポートするには、以下の手順 6,Tablet,299.99 ``` -3. 以下のコマンドを使用して、CSVファイルからデータをインポートします。 +3. 以下のコマンドを使用して、CSVファイルからデータをインポートします。 ```bash mysql --comments --connect-timeout 150 -u '' -h -P 4000 -D test --ssl-mode=VERIFY_IDENTITY --ssl-ca= -p -e "LOAD DATA LOCAL INFILE '' INTO TABLE products @@ -97,7 +97,7 @@ CSVファイルからデータをインポートするには、以下の手順 IGNORE 1 LINES (product_id, product_name, price);" ``` -4. パス、テーブル名（この例では`products` ）、 `` 、 `` 、 `` 、 `` 、 `` 、およびその他のプレースホルダーを実際の情報に置き換え、必要に応じてサンプルCSVデータを実際のデータセットに置き換えてください。 +4. パス、テーブル名（この例では`products` ）、 `` 、 `` 、 `` 、 `` 、 `` 、およびその他のプレースホルダーを実際の情報に置き換え、必要に応じてサンプルCSVデータを実際のデータセットに置き換えてください。 > **Note:** > diff --git a/tidb-cloud/integrate-tidbcloud-with-airbyte.md b/tidb-cloud/integrate-tidbcloud-with-airbyte.md index 5be7e9f264ff1..a2817c9dedc60 100644 --- a/tidb-cloud/integrate-tidbcloud-with-airbyte.md +++ b/tidb-cloud/integrate-tidbcloud-with-airbyte.md @@ -11,16 +11,16 @@ summary: Airbyte TiDBコネクタの使い方を学びましょう。 Airbyteは、わずか数ステップでローカル環境にデプロイできます。 -1. ワークスペースに[Docker](https://www.docker.com/products/docker-desktop)をインストールします。 +1. ワークスペースに[Docker](https://www.docker.com/products/docker-desktop)をインストールします。 -2. Airbyteのソースコードをクローンする。 +2. Airbyteのソースコードをクローンする。 ```shell git clone https://github.com/airbytehq/airbyte.git && \ cd airbyte ``` -3. docker-composeを使用してDockerイメージを実行します。 +3. docker-composeを使用してDockerイメージを実行します。 ```shell docker-compose up @@ -44,27 +44,27 @@ airbyte-server | -------------------------------------- 便利なことに、TiDBをソースと宛先に設定する手順は同じです。 -1. サイドバーの**Sources**または**Destinations**をクリックし、TiDBタイプを選択して新しいTiDBコネクタを作成します。 +1. サイドバーの**Sources**または**Destinations**をクリックし、TiDBタイプを選択して新しいTiDBコネクタを作成します。 -2. 以下のパラメータを入力してください。 +2. 以下のパラメータを入力してください。 - - ホスト: TiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスタークラスターのエンドポイント - - ポート: データベースのポート番号 - - データベース：データを同期したいデータベース - - ユーザー名：データベースにアクセスするためのユーザー名 - - パスワード：ユーザー名のパスワード + - ホスト: TiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスタークラスターのエンドポイント + - ポート: データベースのポート番号 + - データベース：データを同期したいデータベース + - ユーザー名：データベースにアクセスするためのユーザー名 + - パスワード：ユーザー名のパスワード TiDB Cloudコンソールの接続ダイアログからパラメーター値を取得できます。ダイアログを開くには、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスタークラスターの名前をクリックして概要ページに移動し、右上隅の**Connect**をクリックします。 -3. **SSL Connection**を有効にし、 **JDBC URLパラメータ**でTLSプロトコルを**TLSv1.2**または**TLSv1.3**に設定します。 +3. **SSL Connection**を有効にし、 **JDBC URLパラメータ**でTLSプロトコルを**TLSv1.2**または**TLSv1.3**に設定します。 > **Note:** > - > - TiDB Cloud はTLS 接続をサポートしています。TLSv1.2 および**TLSv1.3**から TLS プロトコルを選択できます。たとえば、 `enabledTLSProtocols=TLSv1.2` **。** - > - JDBC を介してTiDB Cloudへの TLS 接続を無効にする場合は、JDBC URL パラメータで useSSL を`false`に設定し、SSL 接続を閉じる必要があります。たとえば、 `useSSL=false`のように設定します。 - > - TiDB Cloud StarterとTiDB Cloud EssentialはTLS接続のみをサポートしています。 + > - TiDB Cloud はTLS 接続をサポートしています。TLSv1.2 および**TLSv1.3**から TLS プロトコルを選択できます。たとえば、 `enabledTLSProtocols=TLSv1.2` **。** + > - JDBC を介してTiDB Cloudへの TLS 接続を無効にする場合は、JDBC URL パラメータで useSSL を`false`に設定し、SSL 接続を閉じる必要があります。たとえば、 `useSSL=false`のように設定します。 + > - TiDB Cloud StarterとTiDB Cloud EssentialはTLS接続のみをサポートしています。 -4. コネクタの作成を完了するには、**Set up source**または**宛先の設定**をクリックします。次のスクリーンショットは、ソースとしてTiDBを設定した例です。 +4. コネクタの作成を完了するには、**Set up source**または**宛先の設定**をクリックします。次のスクリーンショットは、ソースとしてTiDBを設定した例です。 ![TiDB source configuration](/media/tidb-cloud/integration-airbyte-parameters.jpg) @@ -78,40 +78,40 @@ TiDB コネクタの詳細については、 [TiDBソース](https://docs.airbyt 以下の手順では、TiDBをソースと宛先の両方として使用します。他のコネクタでは、パラメータが異なる場合があります。 -1. サイドバーの**Connections**をクリックし、次に**New Connection**をクリックします。 +1. サイドバーの**Connections**をクリックし、次に**New Connection**をクリックします。 -2. 事前に設定した送信元と送信先を選択してください。 +2. 事前に設定した送信元と送信先を選択してください。 -3. 接続**Set up**パネルに移動し、 `${source_name} - ${destination-name}`などの接続名を作成します。 +3. 接続**Set up**パネルに移動し、 `${source_name} - ${destination-name}`などの接続名を作成します。 -4. **Replication frequency**を**Every 24 hours**に設定すると、接続は1日に1回データを複製します。 +4. **Replication frequency**を**Every 24 hours**に設定すると、接続は1日に1回データを複製します。 -5. **Destination Namespace**を**Custom format**に設定し、**Namespace Custom Format**を**test**に設定して、すべてのデータを`test`データベースに保存します。 +5. **Destination Namespace**を**Custom format**に設定し、**Namespace Custom Format**を**test**に設定して、すべてのデータを`test`データベースに保存します。 -6. **Sync mode**で**Full refresh | Overwrite**を選択してください。 +6. **Sync mode**で**Full refresh | Overwrite**を選択してください。 > **Tip:** > > TiDB コネクタは[増分更新と完全更新の同期](https://airbyte.com/blog/understanding-data-replication-modes)をサポートします。 > - > - インクリメンタルモードでは、Airbyteは前回の同期ジョブ以降にソースに追加されたレコードのみを読み取ります。インクリメンタルモードを使用した最初の同期は、フルリフレッシュモードと同等です。 - > - フルリフレッシュモードでは、Airbyteはソース内のすべてのレコードを読み取り、同期タスクごとに宛先に複製します。Airbyteの**Namespace**という名前のテーブルごとに、同期モードを個別に設定できます。 + > - インクリメンタルモードでは、Airbyteは前回の同期ジョブ以降にソースに追加されたレコードのみを読み取ります。インクリメンタルモードを使用した最初の同期は、フルリフレッシュモードと同等です。 + > - フルリフレッシュモードでは、Airbyteはソース内のすべてのレコードを読み取り、同期タスクごとに宛先に複製します。Airbyteの**Namespace**という名前のテーブルごとに、同期モードを個別に設定できます。 ![Set up connection](/media/tidb-cloud/integration-airbyte-connection.jpg) -7. デフォルトの正規化モードを使用するには、 **Normalization & Transformation**を**Normalized tabular data**に設定するか、ジョブのdbtファイルを設定してください。 +7. デフォルトの正規化モードを使用するには、 **Normalization & Transformation**を**Normalized tabular data**に設定するか、ジョブのdbtファイルを設定してください。 -8. **Set up connection**をクリックしてください。 +8. **Set up connection**をクリックしてください。 -9. 接続が確立されたら、 **ENABLED**をクリックして同期タスクをアクティブ化します。また、 **Sync now**をクリックすると、すぐに同期を開始できます。 +9. 接続が確立されたら、 **ENABLED**をクリックして同期タスクをアクティブ化します。また、 **Sync now**をクリックすると、すぐに同期を開始できます。 ![Sync data](/media/tidb-cloud/integration-airbyte-sync.jpg) ## 制限事項 {#limitations} -- TiDBコネクタは、TiCDCが提供する変更データキャプチャ（CDC）機能を使用できません。増分同期はカーソル機構に基づいて実行されます。 -- TiDB の宛先では、デフォルトの正規化モードで`timestamp`型が`varchar`型に変換されます。これは、Airbyte が送信中にタイムスタンプ型を文字列に変換し、TiDB が`cast ('2020-07-28 14:50:15+1:00' as timestamp)`をサポートしていないためです。 -- 一部の大規模な ELT ミッションでは、TiDB の[トランザクション制限](/develop/dev-guide-transaction-restraints.md#large-transaction-restrictions)のパラメーターを増やす必要があります。 +- TiDBコネクタは、TiCDCが提供する変更データキャプチャ（CDC）機能を使用できません。増分同期はカーソル機構に基づいて実行されます。 +- TiDB の宛先では、デフォルトの正規化モードで`timestamp`型が`varchar`型に変換されます。これは、Airbyte が送信中にタイムスタンプ型を文字列に変換し、TiDB が`cast ('2020-07-28 14:50:15+1:00' as timestamp)`をサポートしていないためです。 +- 一部の大規模な ELT ミッションでは、TiDB の[トランザクション制限](/develop/dev-guide-transaction-restraints.md#large-transaction-restrictions)のパラメーターを増やす必要があります。 ## 関連リソース {#related-resources} diff --git a/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md b/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md index df35a21ed33a4..6cd528c38bd1c 100644 --- a/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md +++ b/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md @@ -15,10 +15,10 @@ summary: TiDB Cloud StarterをAmazon LambdaおよびCloudFormationと統合す このガイドでは、以下のコンポーネントを使用して、完全に機能するオンライン書店を作成します。 -- AWS Lambda関数：Sequelize ORMとFastify APIフレームワークを使用して、TiDB Cloud Starterインスタンスからのリクエストとクエリデータを処理します。 -- AWS Secrets Manager SDK: TiDB Cloud Starterインスタンスの接続構成を取得および管理します。 -- AWS API Gateway：HTTPリクエストのルーティングを処理します。 -- TiDB Cloud Starter：クラウドネイティブな分散型SQLデータベース。 +- AWS Lambda関数：Sequelize ORMとFastify APIフレームワークを使用して、TiDB Cloud Starterインスタンスからのリクエストとクエリデータを処理します。 +- AWS Secrets Manager SDK: TiDB Cloud Starterインスタンスの接続構成を取得および管理します。 +- AWS API Gateway：HTTPリクエストのルーティングを処理します。 +- TiDB Cloud Starter：クラウドネイティブな分散型SQLデータベース。 AWS CloudFormationは、Secrets Manager、API Gateway、Lambda関数など、プロジェクトに必要なリソースを作成するために使用されます。 @@ -30,26 +30,26 @@ AWS CloudFormationは、Secrets Manager、API Gateway、Lambda関数など、プ 始める前に、以下のものを用意してください。 -- 以下のAWSサービスにアクセスできるAWSアカウント： - - [AWS CloudFormation](https://aws.amazon.com/cloudformation/) - - [シークレットマネージャー](https://aws.amazon.com/secrets-manager/) - - [APIゲートウェイ](https://aws.amazon.com/api-gateway/) - - [Lambdaサービス](https://aws.amazon.com/lambda/) - - [S3](https://aws.amazon.com/s3/) - - [IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) +- 以下のAWSサービスにアクセスできるAWSアカウント： + - [AWS CloudFormation](https://aws.amazon.com/cloudformation/) + - [シークレットマネージャー](https://aws.amazon.com/secrets-manager/) + - [APIゲートウェイ](https://aws.amazon.com/api-gateway/) + - [Lambdaサービス](https://aws.amazon.com/lambda/) + - [S3](https://aws.amazon.com/s3/) + - [IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) -- [TiDB Cloud](https://tidbcloud.com)アカウントとTiDB Cloud Starterインスタンスが必要です。TiDB Cloud Starterインスタンスの接続情報を取得するには、以下の手順に従ってください。 +- [TiDB Cloud](https://tidbcloud.com)アカウントとTiDB Cloud Starterインスタンスが必要です。TiDB Cloud Starterインスタンスの接続情報を取得するには、以下の手順に従ってください。 ![TiDB Cloud connection information](/media/develop/aws-lambda-tidbcloud-connection-info.png) -- [Postman](https://www.postman.com/)や[カール](https://curl.se/)などのAPIテストツール。このドキュメントのほとんどの例では cURL を使用します。 Windows ユーザーには Postman をお勧めします。 +- [Postman](https://www.postman.com/)や[カール](https://curl.se/)などのAPIテストツール。このドキュメントのほとんどの例では cURL を使用します。 Windows ユーザーには Postman をお勧めします。 -- プロジェクトの[最新リリースのアセット](https://github.com/pingcap/TiDB-Lambda-integration/releases/latest)ローカル マシンにダウンロードします。これには、 `cloudformation_template.yml`および`cloudformation_template.json`ファイルが含まれます。 +- プロジェクトの[最新リリースのアセット](https://github.com/pingcap/TiDB-Lambda-integration/releases/latest)ローカル マシンにダウンロードします。これには、 `cloudformation_template.yml`および`cloudformation_template.json`ファイルが含まれます。 > **Note:** > -> - AWS リソースを作成する際は、リージョンとして`us-east-1`を使用することをお勧めします。これは、このデモの Lambda 関数コードでリージョンが`us-east-1`とハードコーディングされており、コードバンドルが`us-east-1`リージョンに保存されるためです。 -> - 別のリージョンを使用する場合は、以下の手順に従ってLambda関数のコードを変更し、再構築して、コードバンドルを独自のS3バケットにアップロードする必要があります。 +> - AWS リソースを作成する際は、リージョンとして`us-east-1`を使用することをお勧めします。これは、このデモの Lambda 関数コードでリージョンが`us-east-1`とハードコーディングされており、コードバンドルが`us-east-1`リージョンに保存されるためです。 +> - 別のリージョンを使用する場合は、以下の手順に従ってLambda関数のコードを変更し、再構築して、コードバンドルを独自のS3バケットにアップロードする必要があります。
us-east-1以外のリージョンを使用する場合は、Lambda関数のコードを修正して再構築してください。 @@ -61,51 +61,51 @@ AWS リソースを作成する際に`us-east-1`以外の別の AWS リージョ コードバンドルを再構築して独自のS3バケットにアップロードするには、次の手順を実行します。 -1. 開発環境を初期化します。 +1. 開発環境を初期化します。 - - [Gitpod](https://gitpod.io/#/https://github.com/pingcap/TiDB-Lambda-integration)ワークスペースを開き、GitHubアカウントでログインしてください。 + - [Gitpod](https://gitpod.io/#/https://github.com/pingcap/TiDB-Lambda-integration)ワークスペースを開き、GitHubアカウントでログインしてください。 -2. ラムダ関数のコードを修正してください。 +2. ラムダ関数のコードを修正してください。 - 1. 左側のサイドバーで`aws-lambda-cloudformation/src/secretManager.ts`ファイルを開きます。 - 2. 22行目を見つけて、 `region`変数を自分の地域に合わせて変更してください。 + 1. 左側のサイドバーで`aws-lambda-cloudformation/src/secretManager.ts`ファイルを開きます。 + 2. 22行目を見つけて、 `region`変数を自分の地域に合わせて変更してください。 -3. コードバンドルを再構築してください。 +3. コードバンドルを再構築してください。 - 1. 依存関係をインストールしてください。 + 1. 依存関係をインストールしてください。 - 1. Gitpodでターミナルを開きます。 + 1. Gitpodでターミナルを開きます。 - 2. 作業ディレクトリを入力してください： + 2. 作業ディレクトリを入力してください： ```shell cd aws-lambda-cloudformation ``` - 3. 依存関係をインストールします。 + 3. 依存関係をインストールします。 ```shell yarn ``` - 2. コードバンドルを再構築してください。 + 2. コードバンドルを再構築してください。 - 1. コードバンドルを作成します。 + 1. コードバンドルを作成します。 ```shell yarn build ``` - 2. `aws-lambda-cloudformation/dist/index.zip`ファイルを確認してください。 + 2. `aws-lambda-cloudformation/dist/index.zip`ファイルを確認してください。 - 3. `index.zip`ファイルを右クリックして、 **Download**を選択します。 + 3. `index.zip`ファイルを右クリックして、 **Download**を選択します。 -4. 再構築したコードバンドルを、ご自身のS3バケットにアップロードしてください。 +4. 再構築したコードバンドルを、ご自身のS3バケットにアップロードしてください。 - 1. AWS マネジメントコンソールの[S3サービス](https://console.aws.amazon.com/s3)にアクセスします。 - 2. 選択したリージョンに新しいバケットを作成します。 - 3. `index.zip`ファイルをバケットにアップロードします。 - 4. 後で使用するため、S3バケット名とリージョンをメモしておいてください。 + 1. AWS マネジメントコンソールの[S3サービス](https://console.aws.amazon.com/s3)にアクセスします。 + 2. 選択したリージョンに新しいバケットを作成します。 + 3. `index.zip`ファイルをバケットにアップロードします。 + 4. 後で使用するため、S3バケット名とリージョンをメモしておいてください。
@@ -113,44 +113,44 @@ AWS リソースを作成する際に`us-east-1`以外の別の AWS リージョ AWS CloudFormation を使用して書店プロジェクトを設定するには、次の手順を実行します。 -1. AWS マネジメントコンソールに移動し、 [AWS CloudFormationサービス](https://console.aws.amazon.com/cloudformation)にアクセスします。 -2. **Create Stack** > **With new resources (standard)**をクリックします。 -3. **Create Stack**ページで、スタックの作成プロセスを完了します。 +1. AWS マネジメントコンソールに移動し、 [AWS CloudFormationサービス](https://console.aws.amazon.com/cloudformation)にアクセスします。 +2. **Create Stack** > **With new resources (standard)**をクリックします。 +3. **Create Stack**ページで、スタックの作成プロセスを完了します。 - 1. **Prerequisite**の領域で、 **Choose an existing template**を選択します。 + 1. **Prerequisite**の領域で、 **Choose an existing template**を選択します。 - 2. **Specify template**領域で、 **Upload a template file**を選択し、 **Choose file**をクリックしてテンプレート ファイル (YAML または JSON) をアップロードし、 **Next**をクリックします。 + 2. **Specify template**領域で、 **Upload a template file**を選択し、 **Choose file**をクリックしてテンプレート ファイル (YAML または JSON) をアップロードし、 **Next**をクリックします。 まだファイルをお持ちでない場合は、 [GitHub](https://github.com/pingcap/TiDB-Lambda-integration/releases/latest)からダウンロードしてください。このファイルには、プロジェクトに必要なリソースを作成するAWS CloudFormationテンプレートが含まれています。 ![Create a stack](/media/develop/aws-lambda-cf-create-stack.png) - 3. スタックの詳細を指定してください。 + 3. スタックの詳細を指定してください。 - - 地域として`us-east-1`を使用する場合は、次のスクリーンショットのようにフィールドに入力してください。 + - 地域として`us-east-1`を使用する場合は、次のスクリーンショットのようにフィールドに入力してください。 ![Specify AWS Lambda stack details](/media/develop/aws-lambda-cf-stack-config.png) - - **Stack name**：スタック名を入力してください。 - - **S3Bucket** ：zipファイルを保存しているS3バケットを入力してください。 - - **S3Key** ：S3キーを入力してください。 - - **TiDBDatabase** ： TiDB Cloud Starterインスタンス名を入力してください。 - - **TiDBHost** : TiDB Cloudデータベースにアクセスするためのホスト URL を入力してください。 `localhost`を入力してください。 - - **TiDBPassword** ： TiDB Cloudデータベースへのアクセスに使用するパスワードを入力してください。 - - **TiDBPort** ： TiDB Cloudデータベースへのアクセスに使用するポート番号を入力してください。 - - **TiDBUser** ： TiDB Cloudデータベースにアクセスするためのユーザー名を入力してください。 + - **Stack name**：スタック名を入力してください。 + - **S3Bucket** ：zipファイルを保存しているS3バケットを入力してください。 + - **S3Key** ：S3キーを入力してください。 + - **TiDBDatabase** ： TiDB Cloud Starterインスタンス名を入力してください。 + - **TiDBHost** : TiDB Cloudデータベースにアクセスするためのホスト URL を入力してください。 `localhost`を入力してください。 + - **TiDBPassword** ： TiDB Cloudデータベースへのアクセスに使用するパスワードを入力してください。 + - **TiDBPort** ： TiDB Cloudデータベースへのアクセスに使用するポート番号を入力してください。 + - **TiDBUser** ： TiDB Cloudデータベースにアクセスするためのユーザー名を入力してください。 - - `us-east-1`以外のAWSリージョンを使用する場合は、以下の手順に従ってください。 + - `us-east-1`以外のAWSリージョンを使用する場合は、以下の手順に従ってください。 - 1. Lambda 関数のコードを変更して再構築し、 [`us-east-1`以外のリージョンを使用する場合は、Lambda関数のコードを修正して再構築してください](#prerequisites)を参照してください。 - 2. スタックの詳細フィールドでは、 `S3Bucket`および`S3Key`パラメーターに、ご自身の設定に応じて S3 バケット名とリージョンを指定してください。 - 3. 前のスクリーンショットのように、他の項目も入力してください。 + 1. Lambda 関数のコードを変更して再構築し、 [`us-east-1`以外のリージョンを使用する場合は、Lambda関数のコードを修正して再構築してください](#prerequisites)を参照してください。 + 2. スタックの詳細フィールドでは、 `S3Bucket`および`S3Key`パラメーターに、ご自身の設定に応じて S3 バケット名とリージョンを指定してください。 + 3. 前のスクリーンショットのように、他の項目も入力してください。 - 4. スタックオプションを設定してください。デフォルト設定を使用することもできます。 + 4. スタックオプションを設定してください。デフォルト設定を使用することもできます。 ![Configure stack options](/media/develop/aws-lambda-cf-stack-config-option.png) - 5. スタックを確認し、作成します。 + 5. スタックを確認し、作成します。 ![Review and create the stack](/media/develop/aws-lambda-cf-stack-config-review.png) @@ -158,45 +158,45 @@ AWS CloudFormation を使用して書店プロジェクトを設定するには スタックが作成されたら、プロジェクトは次のように使用できます。 -1. AWS マネジメント コンソールで[APIゲートウェイサービス](https://console.aws.amazon.com/apigateway)サービスにアクセスし、 `TiDBCloudApiGatewayV2` API をクリックし、左側のペインで**API: TiDBCloudApiGatewayV2**をクリックします。 +1. AWS マネジメント コンソールで[APIゲートウェイサービス](https://console.aws.amazon.com/apigateway)サービスにアクセスし、 `TiDBCloudApiGatewayV2` API をクリックし、左側のペインで**API: TiDBCloudApiGatewayV2**をクリックします。 -2. **Overview**ページから`Invoke URL`をコピーしてください。この URL が API エンドポイントとして機能します。 +2. **Overview**ページから`Invoke URL`をコピーしてください。この URL が API エンドポイントとして機能します。 ![API Gateway Invoke URL](/media/develop/aws-lambda-get-apigateway-invoke-url.png) -3. APIをテストするには、PostmanやcURLなどのAPIテストツールを使用してください。 +3. APIをテストするには、PostmanやcURLなどのAPIテストツールを使用してください。 - - 模擬書籍の初期化: + - 模擬書籍の初期化: ```shell curl -X POST -H "Content-Type: application/json" -d '{"count":100}' https:///book/init ``` - - すべての書籍を入手する： + - すべての書籍を入手する： ```shell curl https:///book ``` - - 書籍IDで書籍を入手： + - 書籍IDで書籍を入手： ```shell curl https:///book/ ``` - - 本を作成する： + - 本を作成する： ```shell curl -X POST -H "Content-Type: application/json" -d '{ "title": "Book Title", "type": "Test", "publishAt": "2022-12-15T21:01:49.000Z", "stock": 123, "price": 12.34, "authors": "Test Test" }' https:// /book ``` - - 本を更新する： + - 本を更新する： ```shell curl -X PUT -H "Content-Type: application/json" -d '{ "title": "Book Title(updated)" }' https:///book/ ``` - - 本を削除する： + - 本を削除する： ```shell curl -X DELETE https:///book/ @@ -206,5 +206,5 @@ AWS CloudFormation を使用して書店プロジェクトを設定するには 不要な料金が発生しないように、作成されたすべてのリソースをクリーンアップしてください。 -1. [AWS マネジメントコンソール](https://console.aws.amazon.com/cloudformation)コンソールにアクセスします。 -2. 作成したAWS CloudFormationスタックを削除してください。 +1. [AWS マネジメントコンソール](https://console.aws.amazon.com/cloudformation)コンソールにアクセスします。 +2. 作成したAWS CloudFormationスタックを削除してください。 diff --git a/tidb-cloud/integrate-tidbcloud-with-cloudflare.md b/tidb-cloud/integrate-tidbcloud-with-cloudflare.md index d32e87f56ac06..6c0372be2f3b0 100644 --- a/tidb-cloud/integrate-tidbcloud-with-cloudflare.md +++ b/tidb-cloud/integrate-tidbcloud-with-cloudflare.md @@ -19,38 +19,48 @@ 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)を参照してください。 -- [Cloudflare Workersアカウント](https://dash.cloudflare.com/login)。 -- [npm](https://docs.npmjs.com/about-npm)がインストールされています。 +- [TiDB Cloudアカウント](https://tidbcloud.com/signup)。 +- 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)がインストールされています。 ## ステップ1：Wranglerをセットアップする {#step-1-set-up-wrangler} [Wrangler](https://developers.cloudflare.com/workers/wrangler/)Cloudflare Worker の公式 CLI です。これを使用して、Worker の生成、構築、プレビュー、および公開を行うことができます。 -1. Wranglerをインストールする： +1. Wranglerをインストールする： - npm install wrangler + ``` + npm install wrangler + ``` -2. Wranglerを認証するには、wrangler loginを実行します。 +2. Wranglerを認証するには、wrangler loginを実行します。 - wrangler login + ``` + wrangler login + ``` -3. Wranglerを使用してワーカープロジェクトを作成します。 +3. Wranglerを使用してワーカープロジェクトを作成します。 - wrangler init tidb-cloud-cloudflare + ``` + wrangler init tidb-cloud-cloudflare + ``` -4. 端末に、プロジェクトに関する一連の質問が表示されます。すべての質問に対して、デフォルト値を選択してください。 +4. 端末に、プロジェクトに関する一連の質問が表示されます。すべての質問に対して、デフォルト値を選択してください。 ## ステップ2：TiDB Cloud Serverless Driverをインストールする {#step-2-install-the-serverless-driver} -1. プロジェクトディレクトリを入力してください： +1. プロジェクトディレクトリを入力してください： - cd tidb-cloud-cloudflare + ``` + cd tidb-cloud-cloudflare + ``` -2. npmを使用してTiDB Cloud Serverless Driverをインストールします。 +2. npmを使用してTiDB Cloud Serverless Driverをインストールします。 - npm install @tidbcloud/serverless + ``` + npm install @tidbcloud/serverless + ``` これにより`package.json`にサーバーレスドライバの依存関係が追加されます。 @@ -81,7 +91,9 @@ export default { `DATABASE_URL`は`mysql://username:password@host/database`の形式に従います。環境変数は wrangler cli を使用して設定できます。 - wrangler secret put +``` +wrangler secret put +``` Cloudflare Workers ダッシュボードから`DATABASE_URL`シークレットを編集することもできます。 @@ -91,13 +103,15 @@ Cloudflare Workers ダッシュボードから`DATABASE_URL`シークレット プロジェクトディレクトリで、以下のコマンドを実行してください。 - npx wrangler deploy +``` +npx wrangler deploy +``` ## ステップ6：Cloudflare Workersを試してみる {#step-6-try-your-cloudflare-workers} -1. [Cloudflareダッシュボード](https://dash.cloudflare.com)に移動してワーカーを見つけます。ワーカーの URL は概要ページで確認できます。 +1. [Cloudflareダッシュボード](https://dash.cloudflare.com)に移動してワーカーを見つけます。ワーカーの URL は概要ページで確認できます。 -2. そのURLにアクセスすれば、結果が表示されます。 +2. そのURLにアクセスすれば、結果が表示されます。 ## 例 {#examples} diff --git a/tidb-cloud/integrate-tidbcloud-with-dbt.md b/tidb-cloud/integrate-tidbcloud-with-dbt.md index a5c55f0738ca0..44447f6623e81 100644 --- a/tidb-cloud/integrate-tidbcloud-with-dbt.md +++ b/tidb-cloud/integrate-tidbcloud-with-dbt.md @@ -57,17 +57,17 @@ cd jaffle_shop このディレクトリ内: -- `dbt_project.yml`は dbt プロジェクト構成ファイルであり、プロジェクト名とデータベース構成ファイルの情報が含まれています。 +- `dbt_project.yml`は dbt プロジェクト構成ファイルであり、プロジェクト名とデータベース構成ファイルの情報が含まれています。 -- `models`ディレクトリには、プロジェクトの SQL モデルとテーブル スキーマが含まれています。このセクションはデータ アナリストが作成します。モデルの詳細については、 [SQLモデル](https://docs.getdbt.com/docs/build/sql-models)を参照してください。 +- `models`ディレクトリには、プロジェクトの SQL モデルとテーブル スキーマが含まれています。このセクションはデータ アナリストが作成します。モデルの詳細については、 [SQLモデル](https://docs.getdbt.com/docs/build/sql-models)を参照してください。 -- `seeds`ディレクトリには、データベース エクスポート ツールによってダンプされた CSV ファイルが保存されます。たとえば、 Dumplingを通じて[TiDB Cloudデータをエクスポートする](https://docs.pingcap.com/tidbcloud/export-data-from-tidb-cloud)できます。 `jaffle_shop`プロジェクトでは、これらの CSV ファイルが処理される生データとして使用されます。 +- `seeds`ディレクトリには、データベース エクスポート ツールによってダンプされた CSV ファイルが保存されます。たとえば、 Dumplingを通じて[TiDB Cloudデータをエクスポートする](https://docs.pingcap.com/tidbcloud/export-data-from-tidb-cloud)できます。 `jaffle_shop`プロジェクトでは、これらの CSV ファイルが処理される生データとして使用されます。 ## ステップ3：プロジェクトの設定 {#step-3-configure-the-project} プロジェクトを設定するには、以下の手順に従ってください。 -1. グローバル設定を完了してください。 +1. グローバル設定を完了してください。 [プロフィール項目の説明](#description-of-profile-fields)を参照し、デフォルトのグローバル プロファイル`~/.dbt/profiles.yml`編集して、 TiDB Cloudとの接続を構成できます。 @@ -92,7 +92,7 @@ cd jaffle_shop TiDB Cloud コンソールの接続ダイアログから`server` 、 `port` 、および`username`の値を取得できます。ダイアログを開くには、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスタークラスターの名前をクリックして概要ページに移動し、右上隅の**Connect**をクリックします。 -2. プロジェクトの設定を完了してください。 +2. プロジェクトの設定を完了してください。 jaffle_shop プロジェクトディレクトリで、プロジェクト設定ファイル`dbt_project.yml`を編集し、 `profile`フィールドを`jaffle_shop_tidb`に変更します。この設定により、プロジェクトは`~/.dbt/profiles.yml`ファイルで指定されているとおりにデータベースからクエリを実行できるようになります。 @@ -131,7 +131,7 @@ cd jaffle_shop materialized: view # *.sql which in models/staging/ would bt materialized to view ``` -3. 設定を確認してください。 +3. 設定を確認してください。 以下のコマンドを実行して、データベースとプロジェクトの設定が正しいかどうかを確認してください。 @@ -147,7 +147,7 @@ cd jaffle_shop プロジェクトの作成と設定が完了したので、次はCSVデータをロードし、ターゲットデータベースにCSVをテーブルとして具体化する段階です。 -1. CSVデータを読み込み、対象データベースにテーブルとしてCSVデータを作成します。 +1. CSVデータを読み込み、対象データベースにテーブルとしてCSVデータを作成します。 ```shell dbt seed @@ -172,7 +172,7 @@ cd jaffle_shop 結果からわかるように、シードファイルが起動され、 `analytics.raw_customers` 、 `analytics.raw_orders` 、および`analytics.raw_payments` 。 -2. TiDB Cloudで結果を確認してください。 +2. TiDB Cloudで結果を確認してください。 `show databases`コマンドは、dbt が作成した新しい`analytics`データベースを一覧表示します。 `show tables`コマンドは、 `analytics`データベースに、作成したテーブルに対応する 3 つのテーブルが存在することを示します。 @@ -224,7 +224,7 @@ cd jaffle_shop これで、設定済みのプロジェクトを実行してデータ変換を完了する準備が整いました。 -1. データ変換を完了するには、dbtプロジェクトを実行してください。 +1. データ変換を完了するには、dbtプロジェクトを実行してください。 ```shell dbt run @@ -258,7 +258,7 @@ cd jaffle_shop 結果によると、2 つのテーブル ( `analytics.customers`と`analytics.orders` ) と 3 つのビュー ( `analytics.stg_customers` 、 `analytics.stg_orders` 、および`analytics.stg_payments` ) が正常に作成されました。 -2. TiDB Cloudにアクセスして、変換が成功したことを確認してください。 +2. TiDB Cloudにアクセスして、変換が成功したことを確認してください。 ```sql mysql> USE ANALYTICS; @@ -303,19 +303,19 @@ dbtを使用すると、プロジェクト全体の構造を表示し、すべ 視覚的なドキュメントを生成するには、以下の手順に従ってください。 -1. ドキュメントを生成する： +1. ドキュメントを生成する： ```shell dbt docs generate ``` -2. サーバーを起動します： +2. サーバーを起動します： ```shell dbt docs serve ``` -3. ブラウザからドキュメントにアクセスするには、 [http://localhost:8080](http://localhost:8080)にアクセスしてください。 +3. ブラウザからドキュメントにアクセスするには、 [http://localhost:8080](http://localhost:8080)にアクセスしてください。 ## プロフィール項目の説明 {#description-of-profile-fields} @@ -335,21 +335,21 @@ dbt-tidb では、以下の関数を直接使用できます。使用方法に 以下の関数がサポートされています。 -- `bool_or` -- `cast_bool_to_text` -- `dateadd` -- `datediff` 。なお、 `datediff`は dbt-util とは少し異なります。切り上げではなく切り捨てが行われます。 -- `date_trunc` -- `hash` -- `safe_cast` -- `split_part` -- `last_day` -- `cast_bool_to_text` -- `concat` -- `escape_single_quotes` -- `except` -- `intersect` -- `length` -- `position` -- `replace` -- `right` +- `bool_or` +- `cast_bool_to_text` +- `dateadd` +- `datediff` 。なお、 `datediff`は dbt-util とは少し異なります。切り上げではなく切り捨てが行われます。 +- `date_trunc` +- `hash` +- `safe_cast` +- `split_part` +- `last_day` +- `cast_bool_to_text` +- `concat` +- `escape_single_quotes` +- `except` +- `intersect` +- `length` +- `position` +- `replace` +- `right` diff --git a/tidb-cloud/integrate-tidbcloud-with-n8n.md b/tidb-cloud/integrate-tidbcloud-with-n8n.md index f0c2958460c5f..b88e48ece9825 100644 --- a/tidb-cloud/integrate-tidbcloud-with-n8n.md +++ b/tidb-cloud/integrate-tidbcloud-with-n8n.md @@ -15,11 +15,11 @@ summary: n8nにおけるTiDB Cloudノードの使い方を学びましょう。 ## 前提条件： TiDB Cloud APIキーを取得する {#prerequisites-get-tidb-cloud-api-key} -1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 -2. 左側のナビゲーションペインで、 **Organization Settings** > **API Keys**をクリックします。 -3. **API Keys**ページで、 **Create API Key**をクリックします。 -4. APIキーの説明を入力し、 **Next**をクリックしてください。 -5. 作成したAPIキーをコピーしてn8nで後で使用するようにし、 **Done**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 +2. 左側のナビゲーションペインで、 **Organization Settings** > **API Keys**をクリックします。 +3. **API Keys**ページで、 **Create API Key**をクリックします。 +4. APIキーの説明を入力し、 **Next**をクリックしてください。 +5. 作成したAPIキーをコピーしてn8nで後で使用するようにし、 **Done**をクリックしてください。 詳細については、 [TiDB Cloud APIの概要](https://docs.pingcap.com/api/tidb-cloud-api-overview)を参照してください。 @@ -30,8 +30,8 @@ summary: n8nにおけるTiDB Cloudノードの使い方を学びましょう。
-1. 作業スペースに[Node.js](https://nodejs.org/en/download/)をインストールしてください。 -2. `npx`から n8n をダウンロードして起動します。 +1. 作業スペースに[Node.js](https://nodejs.org/en/download/)をインストールしてください。 +2. `npx`から n8n をダウンロードして起動します。 ```shell npx n8n @@ -40,8 +40,8 @@ summary: n8nにおけるTiDB Cloudノードの使い方を学びましょう。
-1. ワークスペースに[Docker](https://www.docker.com/products/docker-desktop)をインストールします。 -2. `docker`から n8n をダウンロードして起動します。 +1. ワークスペースに[Docker](https://www.docker.com/products/docker-desktop)をインストールします。 +2. `docker`から n8n をダウンロードして起動します。 ```shell docker run -it --rm --name n8n -p 5678:5678 -v ~/.n8n:/home/node/.n8n n8nio/n8n @@ -56,11 +56,11 @@ n8nを起動したら、 [localhost:5678](http://localhost:5678)にアクセス TiDB Cloudノードは、npmリポジトリでは`n8n-nodes-tidb-cloud`という名前です。n8nでTiDB Cloudを制御するには、このノードを手動でインストールする必要があります。 -1. [localhost:5678](http://localhost:5678)ページで、n8nをセルフホスティングするためのオーナーアカウントを作成します。 -2. **Settings**>**Community nodes**に移動してください。 -3. **Install a community node**をクリックしてください。 -4. **npm Package Name**フィールドに`n8n-nodes-tidb-cloud`と入力します。 -5. **Install**をクリックしてください。 +1. [localhost:5678](http://localhost:5678)ページで、n8nをセルフホスティングするためのオーナーアカウントを作成します。 +2. **Settings**>**Community nodes**に移動してください。 +3. **Install a community node**をクリックしてください。 +4. **npm Package Name**フィールドに`n8n-nodes-tidb-cloud`と入力します。 +5. **Install**をクリックしてください。 その後、**TiDB Cloud**の検索バーで**TiDB Cloud**ノードを検索し、ワークスペースにドラッグすることでTiDB Cloudノードを使用できます。 @@ -70,11 +70,11 @@ TiDB Cloudノードは、npmリポジトリでは`n8n-nodes-tidb-cloud`という この使用例のワークフローでは、以下のノードを使用します。 -- [スケジュールトリガー](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.scheduletrigger/) -- [RSSを読む](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.rssfeedread/) -- [コード](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.code/) -- [Gmail](https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-base.gmail/) -- [TiDB Cloudノード](https://www.npmjs.com/package/n8n-nodes-tidb-cloud) +- [スケジュールトリガー](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.scheduletrigger/) +- [RSSを読む](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.rssfeedread/) +- [コード](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.code/) +- [Gmail](https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-base.gmail/) +- [TiDB Cloudノード](https://www.npmjs.com/package/n8n-nodes-tidb-cloud) 最終的なワークフローは次の画像のようになります。 @@ -84,15 +84,15 @@ TiDB Cloudノードは、npmリポジトリでは`n8n-nodes-tidb-cloud`という TiDB Cloud Starterインスタンスをお持ちでない場合は、このノードを使用してインスタンスを作成できます。そうでない場合は、この操作をスキップしても構いません。 -1. **Workflows**パネルに移動し、 **Add workflow**をクリックします。 -2. 新しいワークフローワークスペースで、右上隅の**+**をクリックし、 **All**フィールドを選択します。 -3. `TiDB Cloud`を検索して、ワークスペースにドラッグします。 -4. TiDB Cloudノードの認証情報（TiDB Cloud APIキー）を入力してください。 -5. **Project**一覧から、プロジェクトを選択してください。 -6. **操作**リストで、 `Create Serverless Cluster`を選択します。 -7. **Cluster Name**ボックスに、 TiDB Cloud Starterインスタンスの名前を入力します。 -8. **リージョン**リストから地域を選択してください。 -9. **Password**欄に、 TiDB Cloud Starterインスタンスへのログインに使用するパスワードを入力してください。 +1. **Workflows**パネルに移動し、 **Add workflow**をクリックします。 +2. 新しいワークフローワークスペースで、右上隅の**+**をクリックし、 **All**フィールドを選択します。 +3. `TiDB Cloud`を検索して、ワークスペースにドラッグします。 +4. TiDB Cloudノードの認証情報（TiDB Cloud APIキー）を入力してください。 +5. **Project**一覧から、プロジェクトを選択してください。 +6. **操作**リストで、 `Create Serverless Cluster`を選択します。 +7. **Cluster Name**ボックスに、 TiDB Cloud Starterインスタンスの名前を入力します。 +8. **リージョン**リストから地域を選択してください。 +9. **Password**欄に、 TiDB Cloud Starterインスタンスへのログインに使用するパスワードを入力してください。 10. ノードを実行するには、 **Execute Node**をクリックしてください。 > **Note:** @@ -103,37 +103,37 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ #### ワークフローの開始点として手動トリガーを使用する {#use-a-manual-trigger-as-the-workflow-s-starter} -1. ワークフローがまだ作成されていない場合は、**Workflows**パネルに移動して、 **Start from scratch**をクリックしてください。既にワークフローを作成している場合は、この手順をスキップしてください。 -2. 右上隅の**+**をクリックして、 `schedule trigger`を検索します。 -3. 手動トリガーノードをワークスペースにドラッグし、ノードをダブルクリックします。**パラメーター**ダイアログが表示されます。 -4. ルールを以下のように設定してください。 +1. ワークフローがまだ作成されていない場合は、**Workflows**パネルに移動して、 **Start from scratch**をクリックしてください。既にワークフローを作成している場合は、この手順をスキップしてください。 +2. 右上隅の**+**をクリックして、 `schedule trigger`を検索します。 +3. 手動トリガーノードをワークスペースにドラッグし、ノードをダブルクリックします。**パラメーター**ダイアログが表示されます。 +4. ルールを以下のように設定してください。 - - **Trigger Interval**： `Days` - - **Days Between Triggers**： `1` - - **Trigger at Hour**： `8am` - - **Trigger at Minute**: `0` + - **Trigger Interval**： `Days` + - **Days Between Triggers**： `1` + - **Trigger at Hour**： `8am` + - **Trigger at Minute**: `0` このトリガーは、毎朝午前8時にワークフローを実行します。 #### データ挿入に使用するテーブルを作成します。 {#create-a-table-used-to-insert-data} -1. 手動トリガーノードの右側にある**+**をクリックします。 +1. 手動トリガーノードの右側にある**+**をクリックします。 -2. `TiDB Cloud`を検索してワークスペースに追加します。 +2. `TiDB Cloud`を検索してワークスペースに追加します。 -3. **パラメーター**ダイアログで、 TiDB Cloudノードの認証情報を入力します。認証情報は、 TiDB Cloud APIキーです。 +3. **パラメーター**ダイアログで、 TiDB Cloudノードの認証情報を入力します。認証情報は、 TiDB Cloud APIキーです。 -4. **Project**一覧から、プロジェクトを選択してください。 +4. **Project**一覧から、プロジェクトを選択してください。 -5. **操作**リストで、 `Execute SQL`を選択します。 +5. **操作**リストで、 `Execute SQL`を選択します。 -6. TiDB Cloud Starterインスタンスを選択してください。リストに新しいインスタンスが表示されない場合は、インスタンスの作成が完了するまで数分お待ちください。 +6. TiDB Cloud Starterインスタンスを選択してください。リストに新しいインスタンスが表示されない場合は、インスタンスの作成が完了するまで数分お待ちください。 -7. **User**一覧からユーザーを選択してください。TiDB Cloudは常にデフォルトユーザーを作成するため、手動で作成する必要はありません。 +7. **User**一覧からユーザーを選択してください。TiDB Cloudは常にデフォルトユーザーを作成するため、手動で作成する必要はありません。 -8. **Database**ボックスに`test`と入力します。 +8. **Database**ボックスに`test`と入力します。 -9. データベースのパスワードを入力してください。 +9. データベースのパスワードを入力してください。 10. **SQL**ボックスに、次のSQLを入力してください。 @@ -145,27 +145,27 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ #### Hacker NewsのRSSフィードを入手する {#get-the-hacker-news-rss} -1. TiDB Cloudノードの右側にある**+**をクリックします。 -2. `RSS Read`を検索してワークスペースに追加します。 -3. **URL**ボックスに`https://hnrss.org/frontpage`と入力します。 +1. TiDB Cloudノードの右側にある**+**をクリックします。 +2. `RSS Read`を検索してワークスペースに追加します。 +3. **URL**ボックスに`https://hnrss.org/frontpage`と入力します。 #### TiDBにデータを挿入する {#insert-data-to-tidb} -1. RSS Readノードの右側にある**+**をクリックしてください。 -2. `TiDB Cloud`を検索してワークスペースに追加します。 -3. 以前のTiDB Cloudノードで入力した認証情報を選択してください。 -4. **Project**一覧から、プロジェクトを選択してください。 -5. **操作**リストで、 `Insert`を選択します。 -6. **Cluster** 、 **User** 、 **Database** 、 **Password**の各ボックスに、それぞれ対応する値を入力してください。 -7. **Table**ボックスに、 `hacker_news_briefing`表を入力します。 -8. **Columns**ボックスに`creator, title, link, pubdate, comments, content, guid, isodate`と入力します。 +1. RSS Readノードの右側にある**+**をクリックしてください。 +2. `TiDB Cloud`を検索してワークスペースに追加します。 +3. 以前のTiDB Cloudノードで入力した認証情報を選択してください。 +4. **Project**一覧から、プロジェクトを選択してください。 +5. **操作**リストで、 `Insert`を選択します。 +6. **Cluster** 、 **User** 、 **Database** 、 **Password**の各ボックスに、それぞれ対応する値を入力してください。 +7. **Table**ボックスに、 `hacker_news_briefing`表を入力します。 +8. **Columns**ボックスに`creator, title, link, pubdate, comments, content, guid, isodate`と入力します。 #### メッセージを作成する {#build-message} -1. RSSフィードの「読む」ノードの右側にある**+**をクリックします。 -2. `code`を検索してワークスペースに追加します。 -3. `Run Once for All Items`モードを選択してください。 -4. **JavaScript**ボックスに、以下のコードをコピー＆ペーストしてください。 +1. RSSフィードの「読む」ノードの右側にある**+**をクリックします。 +2. `code`を検索してワークスペースに追加します。 +3. `Run Once for All Items`モードを選択してください。 +4. **JavaScript**ボックスに、以下のコードをコピー＆ペーストしてください。 ```javascript let message = ""; @@ -198,15 +198,15 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ #### Gmailでメッセージを送信 {#send-message-by-gmail} -1. コードノードの右側にある**+**をクリックします。 -2. `gmail`を検索してワークスペースに追加します。 -3. Gmail ノードの認証情報を入力します。詳細な手順については、 [n8nドキュメント](https://docs.n8n.io/integrations/builtin/credentials/google/oauth-single-service/)ドキュメントを参照してください。 -4. **Resource**リストで、 `Message`を選択します。 -5. **操作**リストで、 `Send`を選択します。 -6. **To**欄にメールアドレスを入力してください。 -7. **件名**欄に`Hacker News Briefing`と入力します。 -8. **Email Type**ボックスで、 `HTML`を選択します。 -9. **Message**ボックスで、 `Expression`をクリックし、 `{{ $json["response"] }}`と入力します。 +1. コードノードの右側にある**+**をクリックします。 +2. `gmail`を検索してワークスペースに追加します。 +3. Gmail ノードの認証情報を入力します。詳細な手順については、 [n8nドキュメント](https://docs.n8n.io/integrations/builtin/credentials/google/oauth-single-service/)ドキュメントを参照してください。 +4. **Resource**リストで、 `Message`を選択します。 +5. **操作**リストで、 `Send`を選択します。 +6. **To**欄にメールアドレスを入力してください。 +7. **件名**欄に`Hacker News Briefing`と入力します。 +8. **Email Type**ボックスで、 `HTML`を選択します。 +9. **Message**ボックスで、 `Expression`をクリックし、 `{{ $json["response"] }}`と入力します。 > **Note:** > @@ -226,11 +226,11 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ TiDB Cloudノードは[通常のノード](https://docs.n8n.io/workflows/nodes/#regular-nodes)として機能し、次の 5 つの操作のみをサポートします。 -- **Create Serverless Cluster**: TiDB Cloud Starterインスタンスを作成します。 -- **Execute SQL**：TiDBでSQL文を実行します。 -- **Delete**：TiDB内の行を削除します。 -- **Insert** ：TiDBに行を挿入します。 -- **Update**: TiDB の行を更新します。 +- **Create Serverless Cluster**: TiDB Cloud Starterインスタンスを作成します。 +- **Execute SQL**：TiDBでSQL文を実行します。 +- **Delete**：TiDB内の行を削除します。 +- **Insert** ：TiDBに行を挿入します。 +- **Update**: TiDB の行を更新します。 ### フィールズ {#fields} @@ -239,70 +239,70 @@ TiDB Cloudノードは[通常のノード](https://docs.n8n.io/workflows/nodes/#
-- **TiDB Cloud API の認証情報**: TiDB Cloud API キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 -- **Project**： TiDB Cloudプロジェクト名。 -- **操作**: このノードの操作。サポートされているすべての操作については、[サポート対象のオペレーション](#supported-operations)を参照してください。 -- **Cluster**： TiDB Cloud Starterインスタンスの名前を入力してください。 -- **リージョン**：リージョン名。TiDB Cloud Starterインスタンスをデプロイするリージョンを選択してください。通常は、アプリケーションのデプロイ先に最も近いリージョンを選択してください。 -- **Password**：rootパスワード。新しいTiDB Cloud Starterインスタンスのパスワードを設定してください。 +- **TiDB Cloud API の認証情報**: TiDB Cloud API キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 +- **Project**： TiDB Cloudプロジェクト名。 +- **操作**: このノードの操作。サポートされているすべての操作については、[サポート対象のオペレーション](#supported-operations)を参照してください。 +- **Cluster**： TiDB Cloud Starterインスタンスの名前を入力してください。 +- **リージョン**：リージョン名。TiDB Cloud Starterインスタンスをデプロイするリージョンを選択してください。通常は、アプリケーションのデプロイ先に最も近いリージョンを選択してください。 +- **Password**：rootパスワード。新しいTiDB Cloud Starterインスタンスのパスワードを設定してください。
-- **TiDB Cloud API の認証情報**: TiDB Cloud API キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 -- **Project**： TiDB Cloudプロジェクト名。 -- **操作**: このノードの操作。サポートされているすべての操作については、[サポート対象のオペレーション](#supported-operations)を参照してください。 -- **Cluster**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 -- **Password**： TiDB Cloud Starterインスタンスのパスワード。 -- **User**： TiDB Cloud Starterインスタンスのユーザー名。 -- **Database**：データベース名。 -- **SQL** ：実行するSQL文。 +- **TiDB Cloud API の認証情報**: TiDB Cloud API キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 +- **Project**： TiDB Cloudプロジェクト名。 +- **操作**: このノードの操作。サポートされているすべての操作については、[サポート対象のオペレーション](#supported-operations)を参照してください。 +- **Cluster**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 +- **Password**： TiDB Cloud Starterインスタンスのパスワード。 +- **User**： TiDB Cloud Starterインスタンスのユーザー名。 +- **Database**：データベース名。 +- **SQL** ：実行するSQL文。
-- **TiDB Cloud API の認証情報**: TiDB Cloud API キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 -- **Project**： TiDB Cloudプロジェクト名。 -- **操作**: このノードの操作。サポートされているすべての操作については、[支援活動](#supported-operations)を参照してください。 -- **Cluster**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 -- **Password**： TiDB Cloud Starterインスタンスのパスワード。 -- **User**： TiDB Cloud Starterインスタンスのユーザー名。 -- **Database**：データベース名。 -- **Table**：テーブル名。 `From list`モードを使用してテーブル名を選択するか、 `Name`モードを使用してテーブル名を手動で入力できます。 -- **Delete Key**：データベース内のどの行を削除するかを決定するアイテムのプロパティ名。アイテムとは、あるノードから別のノードに送信されるデータのことです。ノードは、受信データの各アイテムに対してアクションを実行します。n8n のアイテムの詳細については、 [n8nドキュメント](https://docs.n8n.io/workflows/items/)を参照してください。 +- **TiDB Cloud API の認証情報**: TiDB Cloud API キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 +- **Project**： TiDB Cloudプロジェクト名。 +- **操作**: このノードの操作。サポートされているすべての操作については、[支援活動](#supported-operations)を参照してください。 +- **Cluster**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 +- **Password**： TiDB Cloud Starterインスタンスのパスワード。 +- **User**： TiDB Cloud Starterインスタンスのユーザー名。 +- **Database**：データベース名。 +- **Table**：テーブル名。 `From list`モードを使用してテーブル名を選択するか、 `Name`モードを使用してテーブル名を手動で入力できます。 +- **Delete Key**：データベース内のどの行を削除するかを決定するアイテムのプロパティ名。アイテムとは、あるノードから別のノードに送信されるデータのことです。ノードは、受信データの各アイテムに対してアクションを実行します。n8n のアイテムの詳細については、 [n8nドキュメント](https://docs.n8n.io/workflows/items/)を参照してください。
-- **TiDB Cloud API の認証情報**: TiDB Cloud API キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 -- **Project**： TiDB Cloudプロジェクト名。 -- **操作**: このノードの操作。サポートされているすべての操作については、[支援活動](#supported-operations)を参照してください。 -- **Cluster**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 -- **Password**： TiDB Cloud Starterインスタンスのパスワード。 -- **User**： TiDB Cloud Starterインスタンスのユーザー名。 -- **Database**：データベース名。 -- **Table**：テーブル名。 `From list`モードを使用してテーブル名を選択するか、 `Name`モードを使用してテーブル名を手動で入力できます。 -- **Columns**：入力項目のプロパティをカンマで区切ったリストで、新しい行の列として使用されます。項目とは、あるノードから別のノードに送信されるデータのことです。ノードは、受信データの各項目に対してアクションを実行します。n8n の項目に関する詳細は、 [n8nドキュメント](https://docs.n8n.io/workflows/items/)を参照してください。 +- **TiDB Cloud API の認証情報**: TiDB Cloud API キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 +- **Project**： TiDB Cloudプロジェクト名。 +- **操作**: このノードの操作。サポートされているすべての操作については、[支援活動](#supported-operations)を参照してください。 +- **Cluster**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 +- **Password**： TiDB Cloud Starterインスタンスのパスワード。 +- **User**： TiDB Cloud Starterインスタンスのユーザー名。 +- **Database**：データベース名。 +- **Table**：テーブル名。 `From list`モードを使用してテーブル名を選択するか、 `Name`モードを使用してテーブル名を手動で入力できます。 +- **Columns**：入力項目のプロパティをカンマで区切ったリストで、新しい行の列として使用されます。項目とは、あるノードから別のノードに送信されるデータのことです。ノードは、受信データの各項目に対してアクションを実行します。n8n の項目に関する詳細は、 [n8nドキュメント](https://docs.n8n.io/workflows/items/)を参照してください。
-- **TiDB Cloud API の認証情報**: TiDB Cloud API キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 -- **Project**： TiDB Cloudプロジェクト名。 -- **操作**: このノードの操作。サポートされているすべての操作については、[支援活動](#supported-operations)を参照してください。 -- **Cluster**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 -- **Password**： TiDB Cloud Starterインスタンスのパスワード。 -- **User**： TiDB Cloud Starterインスタンスのユーザー名。 -- **Database**：データベース名。 -- **Table**：テーブル名。 `From list`モードを使用してテーブル名を選択するか、 `Name`モードを使用してテーブル名を手動で入力できます。 -- **Update Key**: データベース内のどの行を更新するかを決定するアイテムのプロパティ名。アイテムとは、あるノードから別のノードに送信されるデータのことです。ノードは、受信データの各アイテムに対してアクションを実行します。n8n のアイテムの詳細については、 [n8nドキュメント](https://docs.n8n.io/workflows/items/)を参照してください。 -- **Columns**：入力項目のプロパティをカンマで区切ったリスト。更新対象の行の列として使用されます。 +- **TiDB Cloud API の認証情報**: TiDB Cloud API キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 +- **Project**： TiDB Cloudプロジェクト名。 +- **操作**: このノードの操作。サポートされているすべての操作については、[支援活動](#supported-operations)を参照してください。 +- **Cluster**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 +- **Password**： TiDB Cloud Starterインスタンスのパスワード。 +- **User**： TiDB Cloud Starterインスタンスのユーザー名。 +- **Database**：データベース名。 +- **Table**：テーブル名。 `From list`モードを使用してテーブル名を選択するか、 `Name`モードを使用してテーブル名を手動で入力できます。 +- **Update Key**: データベース内のどの行を更新するかを決定するアイテムのプロパティ名。アイテムとは、あるノードから別のノードに送信されるデータのことです。ノードは、受信データの各アイテムに対してアクションを実行します。n8n のアイテムの詳細については、 [n8nドキュメント](https://docs.n8n.io/workflows/items/)を参照してください。 +- **Columns**：入力項目のプロパティをカンマで区切ったリスト。更新対象の行の列として使用されます。
### 制限事項 {#limitations} -- 通常、 **Execute SQL**操作では1つのSQLステートメントしか実行できません。1つの操作で複数のステートメントを実行する場合は、 [`tidb_multi_statement_mode`](https://docs.pingcap.com/tidbcloud/system-variables#tidb_multi_statement_mode-new-in-v4011)手動で有効にする必要があります。 -- **Delete**および**Update**操作では、キーとして1つのフィールドを指定する必要があります。たとえば、 `Delete Key`を`id`に設定すると、 `DELETE FROM table WHERE id = ${item.id}`を実行するのと同等になります。現在、**Delete**および**Update**操作では、キーを1つだけ指定できます。 -- **Insert**および**Update**操作の場合、**Columns**フィールドにカンマ区切りのリストを指定する必要があり、フィールド名は入力項目のプロパティ名と同じでなければなりません。 +- 通常、 **Execute SQL**操作では1つのSQLステートメントしか実行できません。1つの操作で複数のステートメントを実行する場合は、 [`tidb_multi_statement_mode`](https://docs.pingcap.com/tidbcloud/system-variables#tidb_multi_statement_mode-new-in-v4011)手動で有効にする必要があります。 +- **Delete**および**Update**操作では、キーとして1つのフィールドを指定する必要があります。たとえば、 `Delete Key`を`id`に設定すると、 `DELETE FROM table WHERE id = ${item.id}`を実行するのと同等になります。現在、**Delete**および**Update**操作では、キーを1つだけ指定できます。 +- **Insert**および**Update**操作の場合、**Columns**フィールドにカンマ区切りのリストを指定する必要があり、フィールド名は入力項目のプロパティ名と同じでなければなりません。 diff --git a/tidb-cloud/integrate-tidbcloud-with-netlify.md b/tidb-cloud/integrate-tidbcloud-with-netlify.md index 8c7660d52d48e..8f6ae58ea5427 100644 --- a/tidb-cloud/integrate-tidbcloud-with-netlify.md +++ b/tidb-cloud/integrate-tidbcloud-with-netlify.md @@ -17,15 +17,15 @@ summary: TiDB CloudクラスターをNetlifyプロジェクトに接続する方 NetlifyアカウントとCLIをお持ちであることが前提となります。お持ちでない場合は、以下のリンクを参照して作成してください。 -- [Netlifyアカウントに登録する](https://app.netlify.com/signup)。 -- [Netlify CLI を入手](https://docs.netlify.com/cli/get-started/)。 +- [Netlifyアカウントに登録する](https://app.netlify.com/signup)。 +- [Netlify CLI を入手](https://docs.netlify.com/cli/get-started/)。 ### TiDB CloudアカウントとTiDB Cloudリソース {#a-tidb-cloud-account-and-a-tidb-cloud-resource} アカウントとTiDB Cloudリソースをお持ちであることが前提となります。お持ちでない場合は、以下の手順に従って作成してください。 -- [TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスを作成します](/tidb-cloud/create-tidb-cluster-serverless.md) -- [TiDB Cloud Dedicatedクラスターを作成する](/tidb-cloud/create-tidb-cluster.md) +- [TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスを作成します](/tidb-cloud/create-tidb-cluster-serverless.md) +- [TiDB Cloud Dedicatedクラスターを作成する](/tidb-cloud/create-tidb-cluster.md) TiDB Cloudのリソース1つで、複数のNetlifyサイトに接続できます。 @@ -41,9 +41,9 @@ TiDB Cloudは、すぐに開発を始められるように、TypeScriptとNext.j ### サンプルプロジェクトをフォークして、自分のスペースにクローンしてください。 {#fork-the-example-project-and-clone-it-to-your-own-space} -1. [Next.jsとPrismaを使用したフルスタックの例](https://github.com/tidbcloud/nextjs-prisma-example)リポジトリを自分のGitHubリポジトリにフォークします。 +1. [Next.jsとPrismaを使用したフルスタックの例](https://github.com/tidbcloud/nextjs-prisma-example)リポジトリを自分のGitHubリポジトリにフォークします。 -2. フォークしたリポジトリを自分のスペースにクローンしてください。 +2. フォークしたリポジトリを自分のスペースにクローンしてください。 ```shell git clone https://github.com/${your_username}/nextjs-prisma-example.git @@ -63,13 +63,13 @@ TiDB Cloud Dedicatedクラスタの場合、接続文字列はTiDB Cloudコン > > Cloud CLI をインストールしていない場合は、次の手順を実行する前に、 [TiDB Cloud CLI クイックスタート](/tidb-cloud/get-started-with-cli.md)を参照して簡単にインストールしてください。 -1. TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスの接続文字列を対話モードで取得します。 +1. TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスの接続文字列を対話モードで取得します。 ```shell ticloud cluster connect-info ``` -2. プロンプトに従って、 TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンス、クライアント、およびオペレーティングシステムを選択してください。なお、このドキュメントで使用されているクライアントは`Prisma`です。 +2. プロンプトに従って、 TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンス、クライアント、およびオペレーティングシステムを選択してください。なお、このドキュメントで使用されているクライアントは`Prisma`です。 ``` Choose the cluster @@ -93,20 +93,20 @@ TiDB Cloud Dedicatedクラスタの場合、接続文字列はTiDB Cloudコン > > 後で接続文字列を使用する際は、以下の点に注意してください。 > - > - 接続文字列内のパラメータを実際の値に置き換えてください。 - > - このドキュメントのサンプルアプリでは新しいデータベースが必要なので、 ``固有の新しい名前に置き換える必要があります。 + > - 接続文字列内のパラメータを実際の値に置き換えてください。 + > - このドキュメントのサンプルアプリでは新しいデータベースが必要なので、 ``固有の新しい名前に置き換える必要があります。
-1. [TiDB Cloudコンソール](https://tidbcloud.com/)では、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットリソースの名前をクリックして概要ページに移動し、右上隅の**Connect**をクリックします。表示されたダイアログで、接続文字列から以下の接続パラメータを取得できます。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)では、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットリソースの名前をクリックして概要ページに移動し、右上隅の**Connect**をクリックします。表示されたダイアログで、接続文字列から以下の接続パラメータを取得できます。 - - `${host}` - - `${port}` - - `${user}` - - `${password}` + - `${host}` + - `${port}` + - `${user}` + - `${password}` -2. 以下の接続文字列に接続パラメータを入力してください。 +2. 以下の接続文字列に接続パラメータを入力してください。 ```shell mysql://:@:/?sslaccept=strict @@ -116,21 +116,21 @@ TiDB Cloud Dedicatedクラスタの場合、接続文字列はTiDB Cloudコン > > 後で接続文字列を使用する際は、以下の点に注意してください。 > - > - 接続文字列内のパラメータを実際の値に置き換えてください。 - > - このドキュメントのサンプルアプリでは新しいデータベースが必要なので、 ``固有の新しい名前に置き換える必要があります。 + > - 接続文字列内のパラメータを実際の値に置き換えてください。 + > - このドキュメントのサンプルアプリでは新しいデータベースが必要なので、 ``固有の新しい名前に置き換える必要があります。
## ステップ2. サンプルアプリをNetlifyにデプロイ {#step-2-deploy-the-example-app-to-netlify} -1. Netlify CLIで、Netlifyアカウントを認証し、アクセストークンを取得します。 +1. Netlify CLIで、Netlifyアカウントを認証し、アクセストークンを取得します。 ```shell netlify login ``` -2. 自動セットアップを開始します。この手順では、継続的デプロイのためにリポジトリを接続するため、Netlify CLI がリポジトリ上にデプロイキーとウェブフックを作成するためのアクセス権が必要です。 +2. 自動セットアップを開始します。この手順では、継続的デプロイのためにリポジトリを接続するため、Netlify CLI がリポジトリ上にデプロイキーとウェブフックを作成するためのアクセス権が必要です。 ```shell netlify init @@ -177,7 +177,7 @@ TiDB Cloud Dedicatedクラスタの場合、接続文字列はTiDB Cloudコン netlify open Open the Netlify admin URL of your site ``` -3. 環境変数を設定します。自分のスペースと Netlify スペースからTiDB Cloudに接続するには、 [ステップ1](#step-1-get-the-example-project-and-the-connection-string)で取得した接続文字列として`DATABASE_URL`を設定する必要があります。 +3. 環境変数を設定します。自分のスペースと Netlify スペースからTiDB Cloudに接続するには、 [ステップ1](#step-1-get-the-example-project-and-the-connection-string)で取得した接続文字列として`DATABASE_URL`を設定する必要があります。 ```shell # set the environment variable for your own space @@ -197,7 +197,7 @@ TiDB Cloud Dedicatedクラスタの場合、接続文字列はTiDB Cloudコン netlify env:list ``` -4. アプリをローカルでビルドし、スキーマをTiDB Cloudリソースに移行します。 +4. アプリをローカルでビルドし、スキーマをTiDB Cloudリソースに移行します。 > **Tip:** > @@ -208,7 +208,7 @@ TiDB Cloud Dedicatedクラスタの場合、接続文字列はTiDB Cloudコン npm run netlify-build ``` -5. アプリケーションをローカル環境で実行してください。ローカル開発サーバーを起動して、サイトをプレビューできます。 +5. アプリケーションをローカル環境で実行してください。ローカル開発サーバーを起動して、サイトをプレビューできます。 ```shell netlify dev @@ -216,7 +216,7 @@ TiDB Cloud Dedicatedクラスタの場合、接続文字列はTiDB Cloudコン 次に、ブラウザで`http://localhost:3000/`にアクセスして、そのUIを探索してください。 -6. アプリを Netlify にデプロイ。ローカルプレビューで問題がなければ、次のコマンドを使用してサイトを Netlify にデプロイできます。 `--trigger`ローカルファイルをアップロードせずにデプロイすることを意味します。ローカルで変更を加えた場合は、GitHub リポジトリにコミットされていることを確認してください。 +6. アプリを Netlify にデプロイ。ローカルプレビューで問題がなければ、次のコマンドを使用してサイトを Netlify にデプロイできます。 `--trigger`ローカルファイルをアップロードせずにデプロイすることを意味します。ローカルで変更を加えた場合は、GitHub リポジトリにコミットされていることを確認してください。 ```shell netlify deploy --prod --trigger @@ -230,9 +230,9 @@ TiDB Cloud Dedicatedクラスタの場合、接続文字列はTiDB Cloudコン エッジ機能を使用するには、以下の手順に従ってください。 -1. プロジェクトのルートディレクトリに`netlify/edge-functions`という名前のディレクトリを作成します。 +1. プロジェクトのルートディレクトリに`netlify/edge-functions`という名前のディレクトリを作成します。 -2. ディレクトリ内に`hello.ts`という名前のファイルを作成し、以下のコードを追加してください。 +2. ディレクトリ内に`hello.ts`という名前のファイルを作成し、以下のコードを追加してください。 ```typescript import { connect } from 'https://esm.sh/@tidbcloud/serverless' @@ -246,13 +246,13 @@ TiDB Cloud Dedicatedクラスタの場合、接続文字列はTiDB Cloudコン export const config = { path: "/api/hello" }; ``` -3. `DATABASE_URL`環境変数を設定してください。接続情報は[TiDB Cloudコンソール](https://tidbcloud.com/)から取得できます。 . +3. `DATABASE_URL`環境変数を設定してください。接続情報は[TiDB Cloudコンソール](https://tidbcloud.com/)から取得できます。 . ```shell netlify env:set DATABASE_URL 'mysql://:@/' ``` -4. Netlifyにエッジ機能をデプロイ。 +4. Netlifyにエッジ機能をデプロイ。 ```shell netlify deploy --prod --trigger diff --git a/tidb-cloud/integrate-tidbcloud-with-vercel.md b/tidb-cloud/integrate-tidbcloud-with-vercel.md index 796bd250e45f2..bfb6a69f0412e 100644 --- a/tidb-cloud/integrate-tidbcloud-with-vercel.md +++ b/tidb-cloud/integrate-tidbcloud-with-vercel.md @@ -13,13 +13,13 @@ TiDB CloudとVercelを組み合わせることで、MySQL互換のリレーシ このガイドでは、以下のいずれかの方法を使用して、 TiDB CloudのリソースをVercelプロジェクトに接続する方法について説明します。 -- [TiDB Cloud Vercelとの連携を介して接続します](#connect-via-the-tidb-cloud-vercel-integration) -- [環境変数を手動で設定して接続します](#connect-via-manually-setting-environment-variables) +- [TiDB Cloud Vercelとの連携を介して接続します](#connect-via-the-tidb-cloud-vercel-integration) +- [環境変数を手動で設定して接続します](#connect-via-manually-setting-environment-variables) 上記2つの方法のいずれにおいても、 TiDB Cloudはデータベースにプログラムで接続するための以下のオプションを提供します。 -- クラスタ: 直接接続または[TiDB Cloud Serverless Driver](/develop/serverless-driver.md)を使用して、 TiDB Cloudクラスターを Vercel プロジェクトに接続します。 -- [データアプリ](/tidb-cloud/data-service-manage-data-app.md): HTTP エンドポイントのコレクションを通じてTiDB Cloudクラスターのデータにアクセスします。 +- クラスタ: 直接接続または[TiDB Cloud Serverless Driver](/develop/serverless-driver.md)を使用して、 TiDB Cloudクラスターを Vercel プロジェクトに接続します。 +- [データアプリ](/tidb-cloud/data-service-manage-data-app.md): HTTP エンドポイントのコレクションを通じてTiDB Cloudクラスターのデータにアクセスします。 ## 前提条件 {#prerequisites} @@ -29,8 +29,8 @@ 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)を使用して試すことができます。 +- [新しい個人アカウントを作成する](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プロジェクトは、1つのTiDB Cloudクラスターにしか接続できません。統合を変更するには、まず現在のクラスターとの接続を解除してから、新しいクラスターに接続する必要があります。 @@ -38,13 +38,13 @@ Vercelプロジェクトは、1つのTiDB Cloudクラスターにしか接続で TiDB Cloudにアカウントとクラスターが既に作成されている必要があります。アカウントとクラスターをお持ちでない場合は、以下の手順に従って作成してください。 -- [TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスを作成します](/tidb-cloud/create-tidb-cluster-serverless.md) +- [TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスを作成します](/tidb-cloud/create-tidb-cluster-serverless.md) > **Note:** > > TiDB Cloud Vercelとの連携では、TiDB Cloud StarterおよびTiDB Cloud Essentialインスタンスの作成がサポートされています。また、連携プロセス中に後からインスタンスを作成することも可能です。 -- [TiDB Cloud Dedicatedクラスターを作成する](/tidb-cloud/create-tidb-cluster.md) +- [TiDB Cloud Dedicatedクラスターを作成する](/tidb-cloud/create-tidb-cluster.md) > **Note:** > @@ -58,10 +58,10 @@ TiDB Cloudにアカウントとクラスターが既に作成されている必 データ[データアプリ](/tidb-cloud/data-service-manage-data-app.md)を介してTiDB Cloudクラスターに接続する場合は、事前にTiDB Cloudに対象のデータアプリとエンドポイントが設定されている必要があります。設定されていない場合は、以下の手順に従って作成してください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 -2. あなたのプロジェクトに合わせて[データアプリを作成する](/tidb-cloud/data-service-manage-data-app.md#create-a-data-app)。 -3. [データアプリをリンクする](/tidb-cloud/data-service-manage-data-app.md#manage-linked-data-sources)ターゲットのTiDB Cloudクラスターにリンクします。 -4. [エンドポイントを管理する](/tidb-cloud/data-service-manage-endpoint.md)ことで、SQL ステートメントを実行するようにカスタマイズできます。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、プロジェクトの[**Data Service**](https://tidbcloud.com/project/data-service)ページに移動します。 +2. あなたのプロジェクトに合わせて[データアプリを作成する](/tidb-cloud/data-service-manage-data-app.md#create-a-data-app)。 +3. [データアプリをリンクする](/tidb-cloud/data-service-manage-data-app.md#manage-linked-data-sources)ターゲットのTiDB Cloudクラスターにリンクします。 +4. [エンドポイントを管理する](/tidb-cloud/data-service-manage-endpoint.md)ことで、SQL ステートメントを実行するようにカスタマイズできます。 Vercelプロジェクトは、1つのTiDB Cloudデータアプリにしか接続できません。Vercelプロジェクトのデータアプリを変更するには、まず現在のアプリとの接続を解除してから、新しいアプリに接続する必要があります。 @@ -80,24 +80,24 @@ TiDB Cloud Vercel 統合経由で接続するには、 [Vercelの統合マーケ
-1. [TiDB Cloud Vercelとの統合](https://vercel.com/integrations/tidb-cloud)ページの右上領域にある**Add Integration**をクリックします。 **[TiDB Cloudの追加]**ダイアログが表示されます。 -2. ドロップダウンリストから統合の範囲を選択し、 **Continue**をクリックしてください。 -3. 統合を追加するVercelプロジェクトを選択し、 **Continue**をクリックします。 -4. 統合に必要な権限を確認し、 **Add Integration**をクリックしてください。すると、 TiDB Cloudコンソールの統合ページに移動します。 -5. 統合ページで、以下の操作を行います。 - - 1. 対象となるVercelプロジェクトを選択し、 **Next**をクリックしてください。 - 2. 対象となるTiDB Cloud組織とプロジェクトを選択してください。 - 3. 接続タイプとして**Cluster**を選択してください。 - 4. 対象のTiDB Cloudリソースを選択してください。**Cluster**のドロップダウン リストが空の場合、または新しいTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスを選択する場合は、リストの**+ Create Cluster**をクリックして作成してください。 - 5. 接続するデータベースを選択してください。**Database**のドロップダウンリストが空の場合、または新しいデータベースを選択する場合は、リスト内の**+ Create Database**をクリックして作成してください。 - 6. Vercelプロジェクトで使用しているフレームワークを選択してください。対象のフレームワークが一覧にない場合は、 **General**を選択してください。フレームワークによって環境変数が異なります。 - 7. プレビュー環境用に新しいブランチを作成するために、**Branching**を有効にするかどうかを選択してください。 - 8. **Add Integration and Return to Vercel**をクリックします。 +1. [TiDB Cloud Vercelとの統合](https://vercel.com/integrations/tidb-cloud)ページの右上領域にある**Add Integration**をクリックします。 **[TiDB Cloudの追加]**ダイアログが表示されます。 +2. ドロップダウンリストから統合の範囲を選択し、 **Continue**をクリックしてください。 +3. 統合を追加するVercelプロジェクトを選択し、 **Continue**をクリックします。 +4. 統合に必要な権限を確認し、 **Add Integration**をクリックしてください。すると、 TiDB Cloudコンソールの統合ページに移動します。 +5. 統合ページで、以下の操作を行います。 + + 1. 対象となるVercelプロジェクトを選択し、 **Next**をクリックしてください。 + 2. 対象となるTiDB Cloud組織とプロジェクトを選択してください。 + 3. 接続タイプとして**Cluster**を選択してください。 + 4. 対象のTiDB Cloudリソースを選択してください。**Cluster**のドロップダウン リストが空の場合、または新しいTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスを選択する場合は、リストの**+ Create Cluster**をクリックして作成してください。 + 5. 接続するデータベースを選択してください。**Database**のドロップダウンリストが空の場合、または新しいデータベースを選択する場合は、リスト内の**+ Create Database**をクリックして作成してください。 + 6. Vercelプロジェクトで使用しているフレームワークを選択してください。対象のフレームワークが一覧にない場合は、 **General**を選択してください。フレームワークによって環境変数が異なります。 + 7. プレビュー環境用に新しいブランチを作成するために、**Branching**を有効にするかどうかを選択してください。 + 8. **Add Integration and Return to Vercel**をクリックします。 ![Vercel Integration Page](/media/tidb-cloud/vercel/integration-link-cluster-page.png) -6. Vercelダッシュボードに戻り、Vercelプロジェクトに移動して、 **Settings** > **Environment Variables**をクリックし、対象のTiDBクラスタの環境変数が自動的に追加されているかどうかを確認してください。 +6. Vercelダッシュボードに戻り、Vercelプロジェクトに移動して、 **Settings** > **Environment Variables**をクリックし、対象のTiDBクラスタの環境変数が自動的に追加されているかどうかを確認してください。 以下の変数が追加された場合、積分は完了です。 @@ -127,21 +127,21 @@ TiDB Cloud Vercel 統合経由で接続するには、 [Vercelの統合マーケ
-1. [TiDB Cloud Vercelとの統合](https://vercel.com/integrations/tidb-cloud)ページの右上領域にある**Add Integration**をクリックします。 **[TiDB Cloudの追加]**ダイアログが表示されます。 -2. ドロップダウンリストから統合の範囲を選択し、 **Continue**をクリックしてください。 -3. 統合を追加するVercelプロジェクトを選択し、 **Continue**をクリックします。 -4. 統合に必要な権限を確認し、 **Add Integration**をクリックしてください。すると、 TiDB Cloudコンソールの統合ページに移動します。 -5. 統合ページで、以下の操作を行います。 +1. [TiDB Cloud Vercelとの統合](https://vercel.com/integrations/tidb-cloud)ページの右上領域にある**Add Integration**をクリックします。 **[TiDB Cloudの追加]**ダイアログが表示されます。 +2. ドロップダウンリストから統合の範囲を選択し、 **Continue**をクリックしてください。 +3. 統合を追加するVercelプロジェクトを選択し、 **Continue**をクリックします。 +4. 統合に必要な権限を確認し、 **Add Integration**をクリックしてください。すると、 TiDB Cloudコンソールの統合ページに移動します。 +5. 統合ページで、以下の操作を行います。 - 1. 対象となるVercelプロジェクトを選択し、 **Next**をクリックしてください。 - 2. 対象となるTiDB Cloud組織とプロジェクトを選択してください。 - 3. 接続タイプとして**Data App**を選択してください。 - 4. 対象のTiDBデータアプリを選択してください。 - 5. **Add Integration and Return to Vercel**をクリックします。 + 1. 対象となるVercelプロジェクトを選択し、 **Next**をクリックしてください。 + 2. 対象となるTiDB Cloud組織とプロジェクトを選択してください。 + 3. 接続タイプとして**Data App**を選択してください。 + 4. 対象のTiDBデータアプリを選択してください。 + 5. **Add Integration and Return to Vercel**をクリックします。 ![Vercel Integration Page](/media/tidb-cloud/vercel/integration-link-data-app-page.png) -6. Vercelダッシュボードに戻り、Vercelプロジェクトに移動して、 **Settings** > **Environment Variables**をクリックし、対象のデータアプリの環境変数が自動的に追加されているかどうかを確認してください。 +6. Vercelダッシュボードに戻り、Vercelプロジェクトに移動して、 **Settings** > **Environment Variables**をクリックし、対象のデータアプリの環境変数が自動的に追加されているかどうかを確認してください。 以下の変数が追加された場合、積分は完了です。 @@ -158,10 +158,10 @@ TiDB Cloud Vercel 統合経由で接続するには、 [Vercelの統合マーケ [TiDB Cloud Vercelとの統合](https://vercel.com/integrations/tidb-cloud)をインストールしている場合は、統合内の接続を追加または削除できます。 -1. Vercelダッシュボードで、 **Integrations**をクリックします。 -2. TiDB Cloudのエントリで**Manage**をクリックします。 -3. **Configure**をクリックします。 -4. 接続を追加または削除するには、 **Add Link**または**Remove**をクリックします。 +1. Vercelダッシュボードで、 **Integrations**をクリックします。 +2. TiDB Cloudのエントリで**Manage**をクリックします。 +3. **Configure**をクリックします。 +4. 接続を追加または削除するには、 **Add Link**または**Remove**をクリックします。 ![Vercel Integration Configuration Page](/media/tidb-cloud/vercel/integration-vercel-configuration-page.png) @@ -177,35 +177,35 @@ Vercel の[プレビュー展開](https://vercel.com/docs/deployments/preview-de TiDB Cloud Branching を有効にするには、 [TiDB Cloud Vercel統合ワークフロー](#integration-workflow)で次のことを確認する必要があります。 -1. 接続タイプとして**Cluster**を選択してください。 -2. プレビュー環境用の新しいブランチを作成するには、**Branching**を有効にしてください。 +1. 接続タイプとして**Cluster**を選択してください。 +2. プレビュー環境用の新しいブランチを作成するには、**Branching**を有効にしてください。 Gitリポジトリに変更をプッシュすると、Vercelがプレビューデプロイメントをトリガーします。TiDB Cloudとの連携により、Gitブランチ用のTiDB Cloudクラスタのブランチが自動的に作成され、環境変数が設定されます。詳細な手順は以下のとおりです。 -1. Gitリポジトリに新しいブランチを作成します。 +1. Gitリポジトリに新しいブランチを作成します。 ```shell cd tidb-prisma-vercel-demo1 git checkout -b new-branch ``` -2. 変更を加えて、その変更をリモートリポジトリにプッシュします。 +2. 変更を加えて、その変更をリモートリポジトリにプッシュします。 -3. Vercelは、新しいブランチのプレビュー展開を開始します。 +3. Vercelは、新しいブランチのプレビュー展開を開始します。 ![Vercel Preview\_Deployment](/media/tidb-cloud/vercel/vercel-preview-deployment.png) - 1. デプロイ時に、 TiDB Cloud統合機能は、Gitブランチと同じ名前のブランチをクラスタ用に自動的に作成します。ブランチが既に存在する場合は、 TiDB Cloud統合機能はこの手順をスキップします。 + 1. デプロイ時に、 TiDB Cloud統合機能は、Gitブランチと同じ名前のブランチをクラスタ用に自動的に作成します。ブランチが既に存在する場合は、 TiDB Cloud統合機能はこの手順をスキップします。 ![TiDB\_Cloud\_Branch\_Check](/media/tidb-cloud/vercel/tidbcloud-branch-check.png) - 2. ブランチの準備が完了すると、 TiDB Cloud統合によって、Vercelプロジェクトのプレビューデプロイメントで環境変数が設定されます。 + 2. ブランチの準備が完了すると、 TiDB Cloud統合によって、Vercelプロジェクトのプレビューデプロイメントで環境変数が設定されます。 ![Preview\_Envs](/media/tidb-cloud/vercel/preview-envs.png) - 3. TiDB Cloudとの連携により、ブランチの準備が整うまで待機するためのブロッキングチェックも登録されます。このチェックは手動で再実行することも可能です。 + 3. TiDB Cloudとの連携により、ブランチの準備が整うまで待機するためのブロッキングチェックも登録されます。このチェックは手動で再実行することも可能です。 -4. チェックに合格したら、プレビュー環境にアクセスして変更内容を確認できます。 +4. チェックに合格したら、プレビュー環境にアクセスして変更内容を確認できます。 > **Note:** > @@ -220,11 +220,11 @@ Gitリポジトリに変更をプッシュすると、Vercelがプレビュー
-1. TiDBクラスタの接続情報を取得します。 +1. TiDBクラスタの接続情報を取得します。 接続情報は、クラスタの接続ダイアログから取得できます。ダイアログを開くには、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象リソースの名前をクリックして概要ページを開き、右上隅の**Connect**をクリックします。 -2. Vercel ダッシュボード > Vercel プロジェクト >**Settings**>**Environment Variables**に移動し、TiDB クラスターの接続情報に従って[各環境変数の値を宣言する](https://vercel.com/docs/concepts/projects/environment-variables#declare-an-environment-variable)。 +2. Vercel ダッシュボード > Vercel プロジェクト >**Settings**>**Environment Variables**に移動し、TiDB クラスターの接続情報に従って[各環境変数の値を宣言する](https://vercel.com/docs/concepts/projects/environment-variables#declare-an-environment-variable)。 ![Vercel Environment Variables](/media/tidb-cloud/vercel/integration-vercel-environment-variables.png) @@ -239,28 +239,28 @@ datasource db { Vercelでは、環境変数を次のように宣言できます。 -- **Key**= `DATABASE_URL` -- **Value**= `mysql://:@:/?sslaccept=strict` +- **Key**= `DATABASE_URL` +- **Value**= `mysql://:@:/?sslaccept=strict` TiDB Cloud コンソールでは、 `` 、 `` 、 `` 、 `` 、および``TiDB Cloudを取得できます。
-1. データ アプリとそのエンドポイントをまだ作成していない場合は、「データ アプリ[データアプリを管理する](/tidb-cloud/data-service-manage-data-app.md)と[エンドポイントの管理](/tidb-cloud/data-service-manage-endpoint.md)の手順に従ってデータ アプリとそのエンドポイントを作成します。 +1. データ アプリとそのエンドポイントをまだ作成していない場合は、「データ アプリ[データアプリを管理する](/tidb-cloud/data-service-manage-data-app.md)と[エンドポイントの管理](/tidb-cloud/data-service-manage-endpoint.md)の手順に従ってデータ アプリとそのエンドポイントを作成します。 -2. Vercel ダッシュボード > Vercel プロジェクト >**Settings**>**Environment Variables**に移動し、データ アプリの接続情報に従って[各環境変数の値を宣言する](https://vercel.com/docs/concepts/projects/environment-variables#declare-an-environment-variable)。 +2. Vercel ダッシュボード > Vercel プロジェクト >**Settings**>**Environment Variables**に移動し、データ アプリの接続情報に従って[各環境変数の値を宣言する](https://vercel.com/docs/concepts/projects/environment-variables#declare-an-environment-variable)。 ![Vercel Environment Variables](/media/tidb-cloud/vercel/integration-vercel-environment-variables.png) Vercelでは、環境変数を次のように宣言できます。 - - **Key**= `DATA_APP_BASE_URL` - - **Value**= `` - - **Key**= `DATA_APP_PUBLIC_KEY` - - **Value**= `` - - **Key**= `DATA_APP_PRIVATE_KEY` - - **Value**= `` + - **Key**= `DATA_APP_BASE_URL` + - **Value**= `` + - **Key**= `DATA_APP_PUBLIC_KEY` + - **Value**= `` + - **Key**= `DATA_APP_PRIVATE_KEY` + - **Value**= `` `` 、 `` 、 ``の情報は、 TiDB Cloudコンソールの[Data Service](https://tidbcloud.com/project/data-service)ページから取得できます。 diff --git a/tidb-cloud/integrate-tidbcloud-with-zapier.md b/tidb-cloud/integrate-tidbcloud-with-zapier.md index f6fddc14914ac..57b8cc2a5fc66 100644 --- a/tidb-cloud/integrate-tidbcloud-with-zapier.md +++ b/tidb-cloud/integrate-tidbcloud-with-zapier.md @@ -9,9 +9,9 @@ summary: TiDB CloudをZapierを使って5000以上のアプリに接続する方 Zapier で[TiDB Cloudアプリ](https://zapier.com/apps/tidb-cloud/integrations)を使用すると、次のことが可能になります。 -- MySQL互換のHTAPデータベースであるTiDBを使用してください。ローカルでの構築は不要です。 -- TiDB Cloudの管理をより簡単にします。 -- TiDB Cloudを5000以上のアプリに接続して、ワークフローを自動化しましょう。 +- MySQL互換のHTAPデータベースであるTiDBを使用してください。ローカルでの構築は不要です。 +- TiDB Cloudの管理をより簡単にします。 +- TiDB Cloudを5000以上のアプリに接続して、ワークフローを自動化しましょう。 このガイドでは、Zapier 上のTiDB Cloudアプリの概要と使用例について説明します。 @@ -25,9 +25,9 @@ Zapier で[TiDB Cloudアプリ](https://zapier.com/apps/tidb-cloud/integrations) 始める前に必要なもの： -- [Zapierアカウント](https://zapier.com/app/login)。 -- [GitHubアカウント](https://github.com/login)。 -- [TiDB Cloudアカウント](https://tidbcloud.com/signup)と TiDB Cloud Starterインスタンス。詳細については、 [TiDB Cloudクイックスタート](https://docs.pingcap.com/tidbcloud/tidb-cloud-quickstart#step-1-create-a-starter-instance)を参照してください。 +- [Zapierアカウント](https://zapier.com/app/login)。 +- [GitHubアカウント](https://github.com/login)。 +- [TiDB Cloudアカウント](https://tidbcloud.com/signup)と TiDB Cloud Starterインスタンス。詳細については、 [TiDB Cloudクイックスタート](https://docs.pingcap.com/tidbcloud/tidb-cloud-quickstart#step-1-create-a-starter-instance)を参照してください。 ### ステップ1：テンプレートを入手する {#step-1-get-the-template} @@ -37,85 +37,85 @@ Zapier で[TiDB Cloudアプリ](https://zapier.com/apps/tidb-cloud/integrations) エディターページでは、トリガーとアクションを確認できます。トリガーをクリックして設定してください。 -1. アプリとイベントを選択 +1. アプリとイベントを選択 テンプレートにはアプリとイベントがデフォルトで設定されているため、ここでは何もする必要はありません。 **Continue**をクリックしてください。 -2. アカウントを選択 +2. アカウントを選択 TiDB Cloudに接続するGitHubアカウントを選択してください。新規アカウントを接続することも、既存のアカウントを選択することもできます。設定が完了したら、 **Continue**をクリックしてください。 -3. トリガーの設定 +3. トリガーの設定 テンプレートでは、デフォルトでトリガーが設定されています。 **Continue**をクリックしてください。 -4. テストトリガー +4. テストトリガー **Test trigger**をクリックします。トリガーが正常に設定されると、GitHubアカウントから新しいグローバルイベントのデータが表示されます。 **Continue**をクリックします。 ### ステップ3： `Find Table in TiDB Cloud`アクションを設定する {#step-3-set-up-the-find-table-in-tidb-cloud-action} -1. アプリとイベントを選択 +1. アプリとイベントを選択 テンプレートで設定されているデフォルト値`Find Table`そのまま使用します。 **Continue**をクリックします。 -2. アカウントを選択 +2. アカウントを選択 - 1. **Sign in**ボタンをクリックすると、新しいログインページにリダイレクトされます。 - 2. ログイン ページで、公開キーと秘密キーを入力します。 TiDB Cloud API キーを取得するには、 [TiDB Cloud APIドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta#section/Authentication/API-Key-Management)ドキュメントの手順に従ってください。 - 3. **Continue**をクリックしてください。 + 1. **Sign in**ボタンをクリックすると、新しいログインページにリダイレクトされます。 + 2. ログイン ページで、公開キーと秘密キーを入力します。 TiDB Cloud API キーを取得するには、 [TiDB Cloud APIドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta#section/Authentication/API-Key-Management)ドキュメントの手順に従ってください。 + 3. **Continue**をクリックしてください。 ![Account](/media/tidb-cloud/zapier/zapier-tidbcloud-account.png) -3. アクションを設定する +3. アクションを設定する この手順では、イベントデータを保存するTiDB Cloud Starterインスタンス内のテーブルを指定する必要があります。テーブルがまだ作成されていない場合は、この手順で作成できます。 - 1. ドロップダウンリストからプロジェクト名とインスタンス名を選択してください。TiDB Cloud Starterインスタンスの接続情報が自動的に表示されます。 + 1. ドロップダウンリストからプロジェクト名とインスタンス名を選択してください。TiDB Cloud Starterインスタンスの接続情報が自動的に表示されます。 ![Set up project name and instance name](/media/tidb-cloud/zapier/zapier-set-up-tidbcloud-project-and-cluster.png) - 2. パスワードを入力してください。 + 2. パスワードを入力してください。 - 3. ドロップダウンリストからデータベースを選択してください。 + 3. ドロップダウンリストからデータベースを選択してください。 ![Set up database name](/media/tidb-cloud/zapier/zapier-set-up-tidbcloud-databse.png) Zapierは、入力されたパスワードを使用してTiDB Cloudからデータベースを検索します。TiDB Cloud Starterインスタンスにデータベースが見つからない場合は、パスワードを再入力してページを更新してください。 - 4. **The table you want to search**ボックスに`github_global_event`と入力します。テーブルが存在しない場合、テンプレートは次の DDL を使用してテーブルを作成します。 **Continue**をクリックします。 + 4. **The table you want to search**ボックスに`github_global_event`と入力します。テーブルが存在しない場合、テンプレートは次の DDL を使用してテーブルを作成します。 **Continue**をクリックします。 ![The create table DDL](/media/tidb-cloud/zapier/zapier-tidbcloud-create-table-ddl.png) -4. テストアクション +4. テストアクション **Test action**をクリックすると、Zapierがテーブルを作成します。テストをスキップすることも可能で、その場合はワークフローが初めて実行されるときにテーブルが作成されます。 ### ステップ4： `Create Row in TiDB Cloud`設定する {#step-4-set-up-the-create-row-in-tidb-cloud-action} -1. アプリとイベントを選択 +1. アプリとイベントを選択 テンプレートで設定されているデフォルト値をそのまま使用します。 **Continue**をクリックしてください。 -2. アカウントを選択 +2. アカウントを選択 `Find Table in TiDB Cloud`アクションを設定する際に選択したアカウントを選択します。 **Continue**をクリックします。 ![Choose account](/media/tidb-cloud/zapier/zapier-tidbcloud-choose-account.png) -3. アクションを設定する +3. アクションを設定する - 1. 前の手順と同様に、**Project Name**、**Cluster Name**、 **TiDB Password**、**Database Name**を入力してください。 + 1. 前の手順と同様に、**Project Name**、**Cluster Name**、 **TiDB Password**、**Database Name**を入力してください。 - 2. **Table Name**で、ドロップダウンリストから**github_global_event**テーブルを選択します。テーブルの列が表示されます。 + 2. **Table Name**で、ドロップダウンリストから**github_global_event**テーブルを選択します。テーブルの列が表示されます。 ![Table columns](/media/tidb-cloud/zapier/zapier-set-up-tidbcloud-columns.png) - 3. **Columns**ボックスで、トリガーから対応するデータを選択します。すべての列を入力し、 **Continue**をクリックします。 + 3. **Columns**ボックスで、トリガーから対応するデータを選択します。すべての列を入力し、 **Continue**をクリックします。 ![Fill in Columns](/media/tidb-cloud/zapier/zapier-fill-in-tidbcloud-triggers-data.png) -4. テストアクション +4. テストアクション **Test action**をクリックして、テーブルに新しい行を作成します。TiDB Cloud Starterインスタンスを確認すると、データが正常に書き込まれていることが確認できます。 @@ -177,11 +177,11 @@ TiDB Cloudには、Zapierで直接使用できるテンプレートがいくつ 以下に例を示します。 -- [GoogleスプレッドシートにTiDB Cloudの新しい行を複製する](https://zapier.com/apps/google-sheets/integrations/tidb-cloud/1134881/duplicate-new-tidb-cloud-rows-in-google-sheets)。 -- [新しいカスタムTiDBクエリからGmail経由でメールを送信する](https://zapier.com/apps/gmail/integrations/tidb-cloud/1134903/send-emails-via-gmail-from-new-custom-tidb-queries)。 -- [新たに捕捉したウェブフックからTiDB Cloudに行を追加する](https://zapier.com/apps/tidb-cloud/integrations/webhook/1134955/add-rows-to-tidb-cloud-from-newly-caught-webhooks)。 -- [新しいSalesforce連絡先をTiDB行に保存します](https://zapier.com/apps/salesforce/integrations/tidb-cloud/1134923/store-new-salesforce-contacts-on-tidb-rows)。 -- [再開機能付きの新しいGmailメール用にTiDB行を作成し、Slackに直接通知を送信する](https://zapier.com/apps/gmail/integrations/slack/1135456/create-tidb-rows-for-new-gmail-emails-with-resumes-and-send-direct-slack-notifications) +- [GoogleスプレッドシートにTiDB Cloudの新しい行を複製する](https://zapier.com/apps/google-sheets/integrations/tidb-cloud/1134881/duplicate-new-tidb-cloud-rows-in-google-sheets)。 +- [新しいカスタムTiDBクエリからGmail経由でメールを送信する](https://zapier.com/apps/gmail/integrations/tidb-cloud/1134903/send-emails-via-gmail-from-new-custom-tidb-queries)。 +- [新たに捕捉したウェブフックからTiDB Cloudに行を追加する](https://zapier.com/apps/tidb-cloud/integrations/webhook/1134955/add-rows-to-tidb-cloud-from-newly-caught-webhooks)。 +- [新しいSalesforce連絡先をTiDB行に保存します](https://zapier.com/apps/salesforce/integrations/tidb-cloud/1134923/store-new-salesforce-contacts-on-tidb-rows)。 +- [再開機能付きの新しいGmailメール用にTiDB行を作成し、Slackに直接通知を送信する](https://zapier.com/apps/gmail/integrations/slack/1135456/create-tidb-rows-for-new-gmail-emails-with-resumes-and-send-direct-slack-notifications) ## FAQ {#faq} @@ -209,11 +209,11 @@ API 内のアイテムが複数の異なるポーリングに存在する場合 `New Row`トリガーは、重複排除を行う`id`フィールドを生成するために、柔軟な戦略も使用します。トリガーは`id`フィールドを次の順序で生成します。 -1. 結果に`id`列が含まれている場合は、 `id`列を使用します。 -2. トリガー構成で`Dedupe Key`を指定する場合は、 `Dedupe Key`を使用してください。 -3. テーブルに主キーがある場合は、その主キーを使用します。主キーが複数ある場合は、最初の列を使用します。 -4. テーブルに一意キーがある場合は、その一意キーを使用してください。 -5. 表の最初の列を使用してください。 +1. 結果に`id`列が含まれている場合は、 `id`列を使用します。 +2. トリガー構成で`Dedupe Key`を指定する場合は、 `Dedupe Key`を使用してください。 +3. テーブルに主キーがある場合は、その主キーを使用します。主キーが複数ある場合は、最初の列を使用します。 +4. テーブルに一意キーがある場合は、その一意キーを使用してください。 +5. 表の最初の列を使用してください。 **新規行（カスタムクエリ）トリガー** @@ -227,9 +227,9 @@ API 内のアイテムが複数の異なるポーリングに存在する場合 `Find or create`アクションを使用すると、リソースが存在しない場合に作成できます。以下に例を示します。 -1. `Find Table`アクションを選択してください +1. `Find Table`アクションを選択してください -2. `set up action`ステップで、 `Create TiDB Cloud Table if it doesn’t exist yet?`ボックスにチェックを入れて、 `find and create`を有効にします。 +2. `set up action`ステップで、 `Create TiDB Cloud Table if it doesn’t exist yet?`ボックスにチェックを入れて、 `find and create`を有効にします。 ![Find and create](/media/tidb-cloud/zapier/zapier-tidbcloud-find-and-create.png) diff --git a/tidb-cloud/key-concepts.md b/tidb-cloud/key-concepts.md index b76d0cf7ea91b..5a85e24738de8 100644 --- a/tidb-cloud/key-concepts.md +++ b/tidb-cloud/key-concepts.md @@ -39,8 +39,8 @@ TiDB Cloud Dedicated を使用すると、データ量やワークロードの TiDB Cloudは、サポートされているすべてのプランで高い可用性を保証します。 -- TiDB Cloud Starter、 TiDB Cloud Essential、およびTiDB Cloud Premium については、[TiDB Cloudにおける高可用性](/tidb-cloud/serverless-high-availability.md)を参照してください。 -- TiDB Cloud Dedicatedについては、 [TiDB Cloud Dedicatedにおける高可用性](/tidb-cloud/high-availability-with-multi-az.md)を参照してください。 +- TiDB Cloud Starter、 TiDB Cloud Essential、およびTiDB Cloud Premium については、[TiDB Cloudにおける高可用性](/tidb-cloud/serverless-high-availability.md)を参照してください。 +- TiDB Cloud Dedicatedについては、 [TiDB Cloud Dedicatedにおける高可用性](/tidb-cloud/high-availability-with-multi-az.md)を参照してください。 ## 監視 {#monitoring} diff --git a/tidb-cloud/manage-projects-and-resources.md b/tidb-cloud/manage-projects-and-resources.md index 2fa46619d16d4..8ce666627dca3 100644 --- a/tidb-cloud/manage-projects-and-resources.md +++ b/tidb-cloud/manage-projects-and-resources.md @@ -13,8 +13,8 @@ summary: TiDB Cloudのリソースとプロジェクトの管理方法につい TiDB Cloudのリソースは、管理可能なデプロイ可能な単位です。以下のいずれかになります。 -- TiDB Xインスタンスは、[TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md)上に構築されたサービス指向のTiDB Cloud製品です。{{{ .starter }}}、Essential、Premium、またはBYOCインスタンスなどがあります。 -- {{{ .dedicated }}}クラスター +- TiDB Xインスタンスは、[TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md)上に構築されたサービス指向のTiDB Cloud製品です。{{{ .starter }}}、Essential、Premium、またはBYOCインスタンスなどがあります。 +- {{{ .dedicated }}}クラスター @@ -26,8 +26,8 @@ TiDB Cloudのリソースは、管理可能なデプロイ可能な単位です TiDB Cloudでは、 [プロジェクト](/tidb-cloud/tidb-cloud-glossary.md#project)を使用してTiDB Cloudリソースを整理および管理できます。 -- TiDB Xインスタンスの場合、プロジェクトはオプションです。つまり、これらのインスタンスをプロジェクトにグループ化することも、組織レベルで管理することもできます。 -- TiDB Cloud Dedicatedクラスターの場合、プロジェクトが必要です。 +- TiDB Xインスタンスの場合、プロジェクトはオプションです。つまり、これらのインスタンスをプロジェクトにグループ化することも、組織レベルで管理することもできます。 +- TiDB Cloud Dedicatedクラスターの場合、プロジェクトが必要です。 ## TiDB Cloudのリソースを管理する {#manage-tidb-cloud-resources} @@ -47,9 +47,9 @@ TiDB Cloudリソースを作成するには、組織の[**My TiDB**](https://tid 詳細については、以下の資料を参照してください。 -- [TiDB Cloud StarterまたはEssentialインスタンスを作成します](/tidb-cloud/create-tidb-cluster-serverless.md) +- [TiDB Cloud StarterまたはEssentialインスタンスを作成します](/tidb-cloud/create-tidb-cluster-serverless.md) -- [TiDB Cloud Premiumインスタンスを作成する](/tidb-cloud/premium/create-tidb-instance-premium.md) +- [TiDB Cloud Premiumインスタンスを作成する](/tidb-cloud/premium/create-tidb-instance-premium.md) @@ -57,7 +57,7 @@ TiDB Cloudリソースを作成するには、組織の[**My TiDB**](https://tid -- [TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md) +- [TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md) ### TiDB Cloudのリソースを管理する {#manage-tidb-cloud-resources} @@ -79,32 +79,32 @@ TiDB Cloudのリソースをプロジェクトごとにグループ化して表 プロジェクトビューでは、組織内で自分が所属しているプロジェクトを確認できます。 -- どのプロジェクトにも属さない TiDB X インスタンスは`Out of project`という名前のテーブルに表示されます。 -- 特定のプロジェクトに属するTiDB Xインスタンスは、対応するTiDB Xプロジェクトテーブルに表示されます。 -- TiDB Cloud Dedicatedクラスターは、対応するDedicatedプロジェクトテーブルに表示されます。これらのテーブルのフォルダーアイコンには、**Dedicated**プロジェクトの種類を示す**D**の文字が付いています。 +- どのプロジェクトにも属さない TiDB X インスタンスは`Out of project`という名前のテーブルに表示されます。 +- 特定のプロジェクトに属するTiDB Xインスタンスは、対応するTiDB Xプロジェクトテーブルに表示されます。 +- TiDB Cloud Dedicatedクラスターは、対応するDedicatedプロジェクトテーブルに表示されます。これらのテーブルのフォルダーアイコンには、**Dedicated**プロジェクトの種類を示す**D**の文字が付いています。 ### プロジェクトを作成する {#create-a-project} > **Note:** > -> - 無料トライアルユーザーは新規プロジェクトを作成できません。 -> - TiDB Xインスタンスの場合、プロジェクトの作成は任意です。TiDB Cloud Dedicatedクラスタの場合は、デフォルトのプロジェクトを使用するか、新しいプロジェクトを作成して管理する必要があります。 +> - 無料トライアルユーザーは新規プロジェクトを作成できません。 +> - TiDB Xインスタンスの場合、プロジェクトの作成は任意です。TiDB Cloud Dedicatedクラスタの場合は、デフォルトのプロジェクトを使用するか、新しいプロジェクトを作成して管理する必要があります。 `Organization Owner`の役割をお持ちの場合は、組織内でプロジェクトを作成できます。 新しいプロジェクトを作成するには、以下の手順に従ってください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Create Project**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Create Project**をクリックします。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 表示されたダイアログにプロジェクト名を入力してください。 +2. 表示されたダイアログにプロジェクト名を入力してください。 -3. プロジェクトを作成する対象となるTiDB Cloudリソースの種類に応じて、次のいずれかの操作を行います。 +3. プロジェクトを作成する対象となるTiDB Cloudリソースの種類に応じて、次のいずれかの操作を行います。 - - プロジェクトが TiDB X インスタンス用に作成されている場合は、 **Confirm**をクリックします。 + - プロジェクトが TiDB X インスタンス用に作成されている場合は、 **Confirm**をクリックします。 @@ -123,7 +123,7 @@ TiDB Cloudのリソースをプロジェクトごとにグループ化して表 - - プロジェクトがTiDB Cloud Dedicatedクラスター用に作成されている場合は、 **Create for Dedicated Cluster**オプションを選択し、プロジェクトの [顧客管理型暗号化キー（CMEK）](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md)と[メンテナンスウィンドウ](/tidb-cloud/configure-maintenance-window.md)を構成して、 **Confirm**をクリックします。 + - プロジェクトがTiDB Cloud Dedicatedクラスター用に作成されている場合は、 **Create for Dedicated Cluster**オプションを選択し、プロジェクトの [顧客管理型暗号化キー（CMEK）](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md)と[メンテナンスウィンドウ](/tidb-cloud/configure-maintenance-window.md)を構成して、 **Confirm**をクリックします。 ### プロジェクトを管理する {#manage-a-project} @@ -131,16 +131,16 @@ TiDB Cloudのリソースをプロジェクトごとにグループ化して表 プロジェクトを管理するには、以下の手順に従ってください。 -1. TiDB Cloudコンソールで、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +1. TiDB Cloudコンソールで、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、次のように管理します。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、次のように管理します。 - - TiDB X プロジェクトとTiDB Dedicatedプロジェクトの両方で、ターゲット プロジェクトの行にある**[...]**をクリックして、プロジェクトの名前変更やプロジェクトへのメンバーの招待など、プロジェクトに対してクイック アクションを実行できます。詳細については、[プロジェクトへのアクセスを管理する](/tidb-cloud/manage-user-access.md)を参照してください。 - - TiDB Dedicatedプロジェクトの場合、対象プロジェクトの行にあるアイコンをクリックすると、プロジェクトごとにTiDB Cloud Dedicatedクラスターのネットワーク、メンテナンス、アラートの購読、暗号化アクセスなどの設定を管理できます。 + - TiDB X プロジェクトとTiDB Dedicatedプロジェクトの両方で、ターゲット プロジェクトの行にある**[...]**をクリックして、プロジェクトの名前変更やプロジェクトへのメンバーの招待など、プロジェクトに対してクイック アクションを実行できます。詳細については、[プロジェクトへのアクセスを管理する](/tidb-cloud/manage-user-access.md)を参照してください。 + - TiDB Dedicatedプロジェクトの場合、対象プロジェクトの行にあるアイコンをクリックすると、プロジェクトごとにTiDB Cloud Dedicatedクラスターのネットワーク、メンテナンス、アラートの購読、暗号化アクセスなどの設定を管理できます。 ### TiDB Xインスタンスをプロジェクト間で移動する {#move-a-tidb-x-instance-between-projects} @@ -152,17 +152,17 @@ TiDB Cloudのリソースをプロジェクトごとにグループ化して表 TiDB Xインスタンスを移動するには、以下の手順を実行してください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 -2. プロジェクトビューで、移動する TiDB X インスタンスを含むプロジェクトフォルダーを展開し、対象の TiDB X インスタンスの**...**をクリックしてから、 **Move**をクリックします。 +2. プロジェクトビューで、移動する TiDB X インスタンスを含むプロジェクトフォルダーを展開し、対象の TiDB X インスタンスの**...**をクリックしてから、 **Move**をクリックします。 > **Tip:** > > TiDB Xインスタンスがどのプロジェクトにも含まれていない場合、それは**Out of project**フォルダに表示されます。 -3. 表示されたダイアログで、次のいずれかの操作を行います。 +3. 表示されたダイアログで、次のいずれかの操作を行います。 - - TiDB Xインスタンスをプロジェクトに移動するには、 **To a project**を選択し、ドロップダウンリストから対象のプロジェクトを選択します。 - - TiDB X インスタンスをどのプロジェクトからも移動するには、 **Outside any project**を選択します。 + - TiDB Xインスタンスをプロジェクトに移動するには、 **To a project**を選択し、ドロップダウンリストから対象のプロジェクトを選択します。 + - TiDB X インスタンスをどのプロジェクトからも移動するには、 **Outside any project**を選択します。 -4. **Move**をクリックします。 +4. **Move**をクリックします。 diff --git a/tidb-cloud/manage-serverless-spend-limit.md b/tidb-cloud/manage-serverless-spend-limit.md index 30f71aa5cdd22..c5c56a01267ee 100644 --- a/tidb-cloud/manage-serverless-spend-limit.md +++ b/tidb-cloud/manage-serverless-spend-limit.md @@ -17,9 +17,9 @@ TiDB Cloudの各組織につき、最大 5 つの [無料のTiDB Cloud Starter 組織内の最初の 5 つのTiDB Cloud Starterインスタンス（無料版かスケーラブル版かを問わず）については、 TiDB Cloud はそれぞれに以下の無料使用クォ​​ータを提供します。 -- 行ベースストレージ：5 GiB -- カラム型ストレージ：5 GiB -- [要求単位（RU）](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) : 5,000万RU/月 +- 行ベースストレージ：5 GiB +- カラム型ストレージ：5 GiB +- [要求単位（RU）](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) : 5,000万RU/月 TiDB Cloud Starterインスタンスが使用クォータに達すると、ユーザーが または新しい月の開始時に使用がリセットさ[割り当てを増やす](#update-spending-limit)まで、新しい接続試行は即座に拒否されます。クォータに達する前に確立された既存の接続はアクティブなままですが、スロットリングが発生します。たとえば、無料のTiDB Cloud StarterTiDB Cloud Starterの行ベースのストレージが5 GiB を超えると、 TiDB Cloud Starterインスタンスは自動的に新しい接続試行を制限します。 @@ -33,16 +33,16 @@ TiDB Cloud Starterインスタンスが使用クォータに達すると、ユ TiDB Cloud Starterインスタンスの支出制限を更新するには、以下の手順を実行してください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックすると、その概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックすると、その概要ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. **Capacity used this month**の欄で、 **Set Spending Limit**をクリックします。 +2. **Capacity used this month**の欄で、 **Set Spending Limit**をクリックします。 以前に支出限度額を設定していて、それを更新したい場合は、クリックしてください。 **Edit**。 -3. 必要に応じて月間支出限度額を編集してください。支払い方法を登録していない場合は、限度額を編集した後にクレジットカードを追加する必要があります。 +3. 必要に応じて月間支出限度額を編集してください。支払い方法を登録していない場合は、限度額を編集した後にクレジットカードを追加する必要があります。 -4. **Update Spending Limit**をクリックしてください。 +4. **Update Spending Limit**をクリックしてください。 diff --git a/tidb-cloud/manage-user-access.md b/tidb-cloud/manage-user-access.md index adc0d431c9e53..95691286c7514 100644 --- a/tidb-cloud/manage-user-access.md +++ b/tidb-cloud/manage-user-access.md @@ -13,19 +13,19 @@ TiDB Cloudにアクセスする前に、 [TiDB Cloudアカウントを作成す TiDB Cloudは、組織、プロジェクト、リソースに基づいた階層構造を採用しており、ユーザーとTiDBデプロイメントの管理を支援します。 -- TiDB Cloudの[リソース](/tidb-cloud/tidb-cloud-glossary.md#tidb-cloud-resource)TiDB X インスタンスまたはTiDB Cloud Dedicatedクラスタのいずれかです。TiDB X インスタンスは、 [TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md)上に構築されたサービス指向のTiDB Cloudオファリングです。TiDB Cloud Starter、 Essential、Premium インスタンスなどがあります。 +- TiDB Cloudの[リソース](/tidb-cloud/tidb-cloud-glossary.md#tidb-cloud-resource)TiDB X インスタンスまたはTiDB Cloud Dedicatedクラスタのいずれかです。TiDB X インスタンスは、 [TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md)上に構築されたサービス指向のTiDB Cloudオファリングです。TiDB Cloud Starter、 Essential、Premium インスタンスなどがあります。 -- A [プロジェクト](/tidb-cloud/tidb-cloud-glossary.md#project)は、 TiDB Cloudリソースのコンテナです。 +- A [プロジェクト](/tidb-cloud/tidb-cloud-glossary.md#project)は、 TiDB Cloudリソースのコンテナです。 - - TiDB Xインスタンスの場合、プロジェクトはオプションの論理コンテナです。つまり、これらのインスタンスをプロジェクトにグループ化することも、組織レベルで保持することもできます。 - - TiDB Cloud Dedicatedクラスターの場合、プロジェクトはインフラストラクチャに紐づいており必須です。つまり、管理上の目的で、 TiDB Cloud Dedicatedクラスターはプロジェクトにグループ化する必要があります。 + - TiDB Xインスタンスの場合、プロジェクトはオプションの論理コンテナです。つまり、これらのインスタンスをプロジェクトにグループ化することも、組織レベルで保持することもできます。 + - TiDB Cloud Dedicatedクラスターの場合、プロジェクトはインフラストラクチャに紐づいており必須です。つまり、管理上の目的で、 TiDB Cloud Dedicatedクラスターはプロジェクトにグループ化する必要があります。 -- 組織とは、 TiDB Cloudアカウント（任意の数のメンバーアカウントを含む管理アカウントを含む）、プロジェクト、およびリソースを管理するために使用する最上位のエンティティ（会社や顧客など）です。 +- 組織とは、 TiDB Cloudアカウント（任意の数のメンバーアカウントを含む管理アカウントを含む）、プロジェクト、およびリソースを管理するために使用する最上位のエンティティ（会社や顧客など）です。 組織のオーナーであれば、組織内で複数のプロジェクトを作成できます。 -- TiDB Xインスタンスについては、プロジェクトごとにグループ化するか、組織レベルで直接管理するかを選択できます。 -- TiDB Cloud Dedicatedクラスターの場合、それらをプロジェクトにグループ化する必要があります。 +- TiDB Xインスタンスについては、プロジェクトごとにグループ化するか、組織レベルで直接管理するかを選択できます。 +- TiDB Cloud Dedicatedクラスターの場合、それらをプロジェクトにグループ化する必要があります。 以下は階層構造の一例です。 @@ -46,10 +46,10 @@ TiDB Cloudは、組織、プロジェクト、リソースに基づいた階層 この構造の下では： -- 組織にアクセスするには、ユーザーはその組織のメンバーである必要があります。 -- 組織内のプロジェクトにアクセスするには、ユーザーは少なくともその組織内のプロジェクトに対する読み取りアクセス権を持っている必要があります。 -- 特定のTiDB Xインスタンスにアクセスするには、プロジェクトロールまたはインスタンスロールのいずれかを通じてユーザーにアクセス権を付与することができます。 -- TiDB Cloud Dedicatedクラスターにアクセスするには、ユーザーはクラスターが配置されているプロジェクトへの読み取りアクセス権を持っている必要があります。 +- 組織にアクセスするには、ユーザーはその組織のメンバーである必要があります。 +- 組織内のプロジェクトにアクセスするには、ユーザーは少なくともその組織内のプロジェクトに対する読み取りアクセス権を持っている必要があります。 +- 特定のTiDB Xインスタンスにアクセスするには、プロジェクトロールまたはインスタンスロールのいずれかを通じてユーザーにアクセス権を付与することができます。 +- TiDB Cloud Dedicatedクラスターにアクセスするには、ユーザーはクラスターが配置されているプロジェクトへの読み取りアクセス権を持っている必要があります。 ユーザーの役割と権限の詳細については、[ユーザーロール](#user-roles)を参照してください。 @@ -63,9 +63,9 @@ TiDB Cloudは組織レベルで課金計算を行い、各プロジェクトお 例えば、次のようなことができます。 -- 目的に応じて、開発、ステージング、本番など、さまざまなプロジェクトを作成します。 -- 異なるユーザーに、異なる組織ロール、プロジェクトロール、インスタンスロールを割り当てます。 -- 組織設定を構成します。たとえば、組織のタイムゾーンを設定します。 +- 目的に応じて、開発、ステージング、本番など、さまざまなプロジェクトを作成します。 +- 異なるユーザーに、異なる組織ロール、プロジェクトロール、インスタンスロールを割り当てます。 +- 組織設定を構成します。たとえば、組織のタイムゾーンを設定します。 ### プロジェクト {#projects} @@ -73,9 +73,9 @@ TiDB Cloudは組織レベルで課金計算を行い、各プロジェクトお TiDB Cloudには、3種類のプロジェクトがあります。 -- **TiDB Dedicatedプロジェクト**：このプロジェクトタイプは、 TiDB Cloud Dedicatedクラスタでのみ使用されます。RBAC、ネットワーク、メンテナンス、アラート購読、暗号化アクセスなど、 TiDB Cloud Dedicatedクラスタの設定をプロジェクトごとに個別に管理できます。 -- **TiDB X project**: このプロジェクト タイプは、TiDB X インスタンス ( TiDB Cloud Starter、 Essential、Premium インスタンスを含む) でのみ使用されます。プロジェクトごとに TiDB X インスタンスの RBAC を管理できます。TiDB X プロジェクトは[**My TiDB**](https://tidbcloud.com/tidbs)ページでプロジェクトを作成する際のデフォルトのプロジェクト タイプです。 -- **TiDB X 仮想プロジェクト**: このプロジェクトは仮想プロジェクトであり、管理機能は提供しません。これは、どのプロジェクトにも属さない TiDB X インスタンスの仮想コンテナとして機能するため、これらのインスタンスには、プロジェクト ID を使用してTiDB Cloud API 経由でアクセスできます。各組織には一意の仮想プロジェクト ID があります。この ID は、TiDB Cloud API の[アクセス可能なプロジェクトをすべて一覧表示します](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Project/operation/ListProjects) 。 +- **TiDB Dedicatedプロジェクト**：このプロジェクトタイプは、 TiDB Cloud Dedicatedクラスタでのみ使用されます。RBAC、ネットワーク、メンテナンス、アラート購読、暗号化アクセスなど、 TiDB Cloud Dedicatedクラスタの設定をプロジェクトごとに個別に管理できます。 +- **TiDB X project**: このプロジェクト タイプは、TiDB X インスタンス ( TiDB Cloud Starter、 Essential、Premium インスタンスを含む) でのみ使用されます。プロジェクトごとに TiDB X インスタンスの RBAC を管理できます。TiDB X プロジェクトは[**My TiDB**](https://tidbcloud.com/tidbs)ページでプロジェクトを作成する際のデフォルトのプロジェクト タイプです。 +- **TiDB X 仮想プロジェクト**: このプロジェクトは仮想プロジェクトであり、管理機能は提供しません。これは、どのプロジェクトにも属さない TiDB X インスタンスの仮想コンテナとして機能するため、これらのインスタンスには、プロジェクト ID を使用してTiDB Cloud API 経由でアクセスできます。各組織には一意の仮想プロジェクト ID があります。この ID は、TiDB Cloud API の[アクセス可能なプロジェクトをすべて一覧表示します](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Project/operation/ListProjects) 。 以下の表は、これらのプロジェクトタイプ間の違いを示しています。 @@ -114,8 +114,8 @@ TiDB Cloudは、組織、プロジェクト、インスタンスの各レベル > **Note:** > -> - `Organization Console Audit Manager`ロール（以前は`Organization Console Audit Admin`でした）は、データベース監査ログではなく、 TiDB Cloudコンソールでの監査ログの管理に使用されます。データベース監査を管理するには、プロジェクトレベルで`Project Owner`ロールを使用してください。 -> - `Organization Billing Manager`ロールは`Organization Billing Admin`から名前が変更され、 `Organization Viewer`ロールは`Organization Member`から名前が変更されました。 +> - `Organization Console Audit Manager`ロール（以前は`Organization Console Audit Admin`でした）は、データベース監査ログではなく、 TiDB Cloudコンソールでの監査ログの管理に使用されます。データベース監査を管理するには、プロジェクトレベルで`Project Owner`ロールを使用してください。 +> - `Organization Billing Manager`ロールは`Organization Billing Admin`から名前が変更され、 `Organization Viewer`ロールは`Organization Member`から名前が変更されました。 ### プロジェクトの役割 {#project-roles} @@ -123,11 +123,11 @@ TiDB Cloudは、組織、プロジェクト、インスタンスの各レベル > **Note:** > -> - `Organization Owner`すべてのプロジェクトに対して`Project Owner`のすべての権限を持っているため、 `Organization Owner`もプロジェクトメンバーを招待したり、メンバーにプロジェクトの役割を付与したりできます。 -> - 各プロジェクトロールには、デフォルトで`Organization Viewer`のすべての権限が付与されています。 -> - 組織内のユーザーがどのプロジェクトにも所属していない場合、そのユーザーにはプロジェクトに関する権限は一切ありません。 -> - TiDB XプロジェクトとTiDB Dedicatedプロジェクトの両方において、プロジェクトロールはプロジェクト内のリソースへのアクセスを制御します。TiDB Dedicatedプロジェクトの場合、プロジェクトロールはDedicated固有のプロジェクト設定も制御します。 -> - TiDB X 仮想プロジェクトには管理機能がないため、プロジェクトロールは TiDB X 仮想プロジェクトには適用されません。どの TiDB X プロジェクトにもグループ化されていない特定の TiDB X インスタンスの RBAC を管理するには、[インスタンスロール](#instance-roles)を使用してください。 +> - `Organization Owner`すべてのプロジェクトに対して`Project Owner`のすべての権限を持っているため、 `Organization Owner`もプロジェクトメンバーを招待したり、メンバーにプロジェクトの役割を付与したりできます。 +> - 各プロジェクトロールには、デフォルトで`Organization Viewer`のすべての権限が付与されています。 +> - 組織内のユーザーがどのプロジェクトにも所属していない場合、そのユーザーにはプロジェクトに関する権限は一切ありません。 +> - TiDB XプロジェクトとTiDB Dedicatedプロジェクトの両方において、プロジェクトロールはプロジェクト内のリソースへのアクセスを制御します。TiDB Dedicatedプロジェクトの場合、プロジェクトロールはDedicated固有のプロジェクト設定も制御します。 +> - TiDB X 仮想プロジェクトには管理機能がないため、プロジェクトロールは TiDB X 仮想プロジェクトには適用されません。どの TiDB X プロジェクトにもグループ化されていない特定の TiDB X インスタンスの RBAC を管理するには、[インスタンスロール](#instance-roles)を使用してください。 | 許可 | `Project Owner` | `Project Data Access Read-Write` | `Project Data Access Read-Only` | `Project Viewer` | | ---------------------------------------------------------------------------------------------------- | --------------- | -------------------------------- | ------------------------------- | ---------------- | @@ -153,10 +153,10 @@ TiDB Xインスタンスはインスタンスレベルのロールをサポー > **Note:** > -> - インスタンスロールは、 TiDB Cloud Starter、 Essential、およびPremiumインスタンスにのみ適用されます。TiDB Cloud Dedicatedクラスターはインスタンスロールをサポートしていません。 -> - `Organization Owner`組織内のすべての TiDB X インスタンスに対するすべての権限を自動的に持っています。 -> - 各インスタンスロールは、デフォルトで`Organization Viewer`ロールのすべての権限を継承します。 -> - プロジェクトロールとインスタンスロールは加算式です。ユーザーはプロジェクトロールからアクセス権を継承できるだけでなく、個々のインスタンスに対してより具体的なロールを持つこともできます。 +> - インスタンスロールは、 TiDB Cloud Starter、 Essential、およびPremiumインスタンスにのみ適用されます。TiDB Cloud Dedicatedクラスターはインスタンスロールをサポートしていません。 +> - `Organization Owner`組織内のすべての TiDB X インスタンスに対するすべての権限を自動的に持っています。 +> - 各インスタンスロールは、デフォルトで`Organization Viewer`ロールのすべての権限を継承します。 +> - プロジェクトロールとインスタンスロールは加算式です。ユーザーはプロジェクトロールからアクセス権を継承できるだけでなく、個々のインスタンスに対してより具体的なロールを持つこともできます。 | 許可 | `Instance Manager` | `TiDB X Instance Data Access Read-Write` | `TiDB X Instance Data Access Read-Only` | `TiDB X Instance Viewer` | | ---------------------------------------------------------------------------------- | ------------------ | ---------------------------------------- | --------------------------------------- | ------------------------ | @@ -179,14 +179,14 @@ TiDB Xインスタンスはインスタンスレベルのロールをサポー 組織を表示したり、組織を切り替えるには、以下の手順に従ってください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボボックスをクリックします。所属する組織の一覧が表示されます。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボボックスをクリックします。所属する組織の一覧が表示されます。 > **Tip:** > - > - 現在特定のTiDB Cloudリソースのページにいる場合、左上隅のコンボボックスをクリックした後、組織リストに戻るには、コンボボックス内の**Back to My TiDB**をクリックする必要があります。 - > - 複数の組織に所属している場合は、コンボボックス内の対象組織名をクリックすることで、組織間でアカウントを切り替えることができます。 + > - 現在特定のTiDB Cloudリソースのページにいる場合、左上隅のコンボボックスをクリックした後、組織リストに戻るには、コンボボックス内の**Back to My TiDB**をクリックする必要があります。 + > - 複数の組織に所属している場合は、コンボボックス内の対象組織名をクリックすることで、組織間でアカウントを切り替えることができます。 -2. 組織IDやタイムゾーンなどの組織の詳細情報を表示するには、組織名をクリックし、左側のナビゲーションペインで**Organization Settings** > **General**をクリックします。 +2. 組織IDやタイムゾーンなどの組織の詳細情報を表示するには、組織名をクリックし、左側のナビゲーションペインで**Organization Settings** > **General**をクリックします。 ### 組織のタイムゾーンを設定してください {#set-the-time-zone-for-your-organization} @@ -194,13 +194,13 @@ TiDB Xインスタンスはインスタンスレベルのロールをサポー 現地のタイムゾーン設定を変更するには、以下の手順に従ってください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 -2. 左側のナビゲーションペインで、 **Organization Settings** > **General**をクリックします。 +2. 左側のナビゲーションペインで、 **Organization Settings** > **General**をクリックします。 -3. **Time Zone**セクションで、ドロップダウンリストからお住まいのタイムゾーンを選択してください。 +3. **Time Zone**セクションで、ドロップダウンリストからお住まいのタイムゾーンを選択してください。 -4. **Update**をクリックしてください。 +4. **Update**をクリックしてください。 ### ユーザーを組織に招待する {#invite-a-user-to-your-organization} @@ -212,28 +212,28 @@ TiDB Xインスタンスはインスタンスレベルのロールをサポー 組織にユーザーを招待するには、以下の手順に従ってください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 -2. 左側のナビゲーションペインで、 **Organization Settings** > **Users**をクリックします。 +2. 左側のナビゲーションペインで、 **Organization Settings** > **Users**をクリックします。 -3. **Users**ページで、右上隅にある**Invite User**をクリックします。 +3. **Users**ページで、右上隅にある**Invite User**をクリックします。 -4. 招待するユーザーのメールアドレスを入力してください。 +4. 招待するユーザーのメールアドレスを入力してください。 > **Tip:** > > 一度に複数のメンバーを招待したい場合は、複数のメールアドレスを入力できます。 -5. （オプション）招待されたユーザーには、デフォルトではプロジェクトまたはインスタンスの権限が一切付与されていません。ユーザーにプロジェクトまたはインスタンスのロールを付与するには、以下の手順を実行してください。 +5. （オプション）招待されたユーザーには、デフォルトではプロジェクトまたはインスタンスの権限が一切付与されていません。ユーザーにプロジェクトまたはインスタンスのロールを付与するには、以下の手順を実行してください。 - - ユーザーにプロジェクトレベルのアクセス権を付与するには、 **[役割の追加] をクリックし、[プロジェクトの選択] を選択して**、役割を付与し、対象とするプロジェクトを選択します。 - - ユーザーに特定の TiDB X インスタンスへのアクセス権を付与するには、 **[役割の追加] をクリックし、[インスタンスの選択] を選択して**、役割を付与し、ユーザーに割り当てる対象の TiDB X インスタンスを選択します。 + - ユーザーにプロジェクトレベルのアクセス権を付与するには、 **[役割の追加] をクリックし、[プロジェクトの選択] を選択して**、役割を付与し、対象とするプロジェクトを選択します。 + - ユーザーに特定の TiDB X インスタンスへのアクセス権を付与するには、 **[役割の追加] をクリックし、[インスタンスの選択] を選択して**、役割を付与し、ユーザーに割り当てる対象の TiDB X インスタンスを選択します。 -6. **Invite**をクリックしてください。すると、新しいユーザーがユーザーリストに正常に追加されます。同時に、招待されたメールアドレスに確認リンク付きのメールが送信されます。 +6. **Invite**をクリックしてください。すると、新しいユーザーがユーザーリストに正常に追加されます。同時に、招待されたメールアドレスに確認リンク付きのメールが送信されます。 -7. このメールを受け取った後、ユーザーはメール内のリンクをクリックして本人確認を行う必要があり、すると新しいページが表示されます。 +7. このメールを受け取った後、ユーザーはメール内のリンクをクリックして本人確認を行う必要があり、すると新しいページが表示されます。 -8. 招待されたメールアドレスがTiDB Cloudアカウントに登録されていない場合、ユーザーはアカウント作成ページへ誘導されます。メールアドレスが既にTiDB Cloudアカウントに登録されている場合は、ユーザーはサインインページへ誘導され、サインイン後、アカウントは自動的に組織に参加します。 +8. 招待されたメールアドレスがTiDB Cloudアカウントに登録されていない場合、ユーザーはアカウント作成ページへ誘導されます。メールアドレスが既にTiDB Cloudアカウントに登録されている場合は、ユーザーはサインインページへ誘導され、サインイン後、アカウントは自動的に組織に参加します。 > **Note:** > @@ -249,13 +249,13 @@ TiDB Xインスタンスはインスタンスレベルのロールをサポー > > 組織からメンバーが削除された場合、そのメンバーはすべてのプロジェクトからも削除され、組織内のすべてのインスタンスへのアクセス権を失います。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 -2. 左側のナビゲーションペインで、 **Organization Settings** > **Users**をクリックします。 +2. 左側のナビゲーションペインで、 **Organization Settings** > **Users**をクリックします。 -3. **Users**ページで、対象メンバーの行を見つけ、その行の**...**をクリックし、次に**Delete**をクリックします。 +3. **Users**ページで、対象メンバーの行を見つけ、その行の**...**をクリックし、次に**Delete**をクリックします。 -4. 確認ダイアログで、 **Delete**をクリックします。 +4. 確認ダイアログで、 **Delete**をクリックします。 ## プロジェクトへのアクセスを管理する {#manage-project-access} @@ -267,17 +267,17 @@ TiDB Xインスタンスはインスタンスレベルのロールをサポー プロジェクト名を変更するには、以下の手順に従ってください。 -1. TiDB Cloudコンソールで、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +1. TiDB Cloudコンソールで、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. プロジェクトビューで、対象プロジェクトのテーブルを見つけ、テーブルの右上隅にある**...**をクリックし、次に**Rename**をクリックします。 +2. プロジェクトビューで、対象プロジェクトのテーブルを見つけ、テーブルの右上隅にある**...**をクリックし、次に**Rename**をクリックします。 -3. 新しいプロジェクト名を入力してください。 +3. 新しいプロジェクト名を入力してください。 -4. **Confirm**をクリックしてください。 +4. **Confirm**をクリックしてください。 ### プロジェクトメンバーを招待する {#invite-a-project-member} @@ -289,25 +289,25 @@ TiDB Xインスタンスはインスタンスレベルのロールをサポー プロジェクトにメンバーを招待するには、以下の手順に従ってください。 -1. TiDB Cloudコンソールで、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、次にクリックします。 プロジェクトビューに移動するためのアイコン。 +1. TiDB Cloudコンソールで、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、次にクリックします。 プロジェクトビューに移動するためのアイコン。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. プロジェクトビューで、対象プロジェクトのテーブルを見つけ、テーブルの右上隅にある**...**をクリックし、次に**Invite**をクリックします。 +2. プロジェクトビューで、対象プロジェクトのテーブルを見つけ、テーブルの右上隅にある**...**をクリックし、次に**Invite**をクリックします。 -3. 表示されたダイアログで、招待するユーザーのメールアドレスを入力し、そのユーザーのプロジェクトロールを選択してください。 +3. 表示されたダイアログで、招待するユーザーのメールアドレスを入力し、そのユーザーのプロジェクトロールを選択してください。 > **Tip:** > > 一度に複数のメンバーを招待したい場合は、複数のメールアドレスを入力できます。 -4. **Confirm**をクリックしてください。すると、新しいユーザーがユーザーリストに正常に追加されます。同時に、招待されたメールアドレスに確認リンク付きのメールが送信されます。 +4. **Confirm**をクリックしてください。すると、新しいユーザーがユーザーリストに正常に追加されます。同時に、招待されたメールアドレスに確認リンク付きのメールが送信されます。 -5. このメールを受け取った後、ユーザーはメール内のリンクをクリックして本人確認を行う必要があり、すると新しいページが表示されます。 +5. このメールを受け取った後、ユーザーはメール内のリンクをクリックして本人確認を行う必要があり、すると新しいページが表示されます。 -6. 招待されたメールアドレスがTiDB Cloudアカウントに登録されていない場合、ユーザーはアカウント作成ページに移動します。メールアドレスが既にTiDB Cloudアカウントに登録されている場合は、ユーザーはサインインページに移動します。サインイン後、アカウントは自動的にプロジェクトに参加します。 +6. 招待されたメールアドレスがTiDB Cloudアカウントに登録されていない場合、ユーザーはアカウント作成ページに移動します。メールアドレスが既にTiDB Cloudアカウントに登録されている場合は、ユーザーはサインインページに移動します。サインイン後、アカウントは自動的にプロジェクトに参加します。 > **Note:** > @@ -319,15 +319,15 @@ TiDB Xインスタンスはインスタンスレベルのロールをサポー プロジェクトからメンバーを削除するには、以下の手順を実行してください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 -2. 左側のナビゲーションペインで、 **Organization Settings** > **Users**をクリックします。 +2. 左側のナビゲーションペインで、 **Organization Settings** > **Users**をクリックします。 -3. **Users**ページで、対象メンバーの行を見つけ、その行の**...**をクリックし、次に**Edit Role**をクリックします。 +3. **Users**ページで、対象メンバーの行を見つけ、その行の**...**をクリックし、次に**Edit Role**をクリックします。 -4. **Edit Role**ダイアログで、対象のプロジェクトを見つけて、 アイコン。 +4. **Edit Role**ダイアログで、対象のプロジェクトを見つけて、 アイコン。 -5. **Save**をクリックしてください。 +5. **Save**をクリックしてください。 ## インスタンスへのアクセスを管理する {#manage-instance-access} @@ -341,19 +341,19 @@ TiDB Xインスタンスはインスタンスレベルのロールをサポー TiDB Xインスタンスへのアクセス権を付与するには、以下の手順を実行してください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 -2. 左側のナビゲーションペインで、 **Organization Settings** > **Users**をクリックします。 +2. 左側のナビゲーションペインで、 **Organization Settings** > **Users**をクリックします。 -3. **Users**ページで、対象メンバーの行を見つけ、その行の**...**をクリックし、次に**Edit Role**をクリックします。 +3. **Users**ページで、対象メンバーの行を見つけ、その行の**...**をクリックし、次に**Edit Role**をクリックします。 > **Tip:** > > ユーザーがまだ組織に属していない場合は、右上隅にある**Invite User**をクリックし、[ユーザーを組織に招待する](#invite-a-user-to-your-organization)の手順に従って、ユーザーにインスタンス ロールを付与します。 -4. **Edit Role**ページで、 **Instance access**セクションの**Add Role and Select Instance**をクリックし、ユーザーにロールを付与して、対象のTiDB Xインスタンスを選択します。 +4. **Edit Role**ページで、 **Instance access**セクションの**Add Role and Select Instance**をクリックし、ユーザーにロールを付与して、対象のTiDB Xインスタンスを選択します。 -5. **Save**をクリックしてください。 +5. **Save**をクリックしてください。 ### ユーザーのインスタンスアクセス権を削除します {#remove-instance-access-for-a-user} @@ -361,37 +361,37 @@ TiDB Xインスタンスへのアクセス権を付与するには、以下の ユーザーのインスタンスアクセス権を削除するには、以下の手順を実行してください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 -2. 左側のナビゲーションペインで、 **Organization Settings** > **Users**をクリックします。 +2. 左側のナビゲーションペインで、 **Organization Settings** > **Users**をクリックします。 -3. **Users**ページで、対象メンバーの行を見つけ、その行の**...**をクリックし、次に**Edit Role**をクリックします。 +3. **Users**ページで、対象メンバーの行を見つけ、その行の**...**をクリックし、次に**Edit Role**をクリックします。 -4. **Edit Role**ダイアログで、対象のインスタンスを見つけて、 アイコン。 +4. **Edit Role**ダイアログで、対象のインスタンスを見つけて、 アイコン。 -5. **Save**をクリックしてください。 +5. **Save**をクリックしてください。 ## ユーザーの役割を変更する {#modify-roles-of-a-user} TiDB Cloudでユーザーの役割を変更するには、以下の手順を実行してください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)では、左上隅のコンボボックスを使用して、対象の組織に切り替えてください。 -2. 左側のナビゲーションペインで、 **Organization Settings** > **Users**をクリックします。 +2. 左側のナビゲーションペインで、 **Organization Settings** > **Users**をクリックします。 -3. **Users**ページで、対象ユーザーの行を見つけ、その行の**...**をクリックし、次に**Edit Role**をクリックします。 +3. **Users**ページで、対象ユーザーの行を見つけ、その行の**...**をクリックし、次に**Edit Role**をクリックします。 - - `Organization Owner`ロールに属している場合は、対象ユーザーの組織ロール、プロジェクトロール、およびインスタンスロールを変更できます。 - - `Project Owner`ロールに属している場合は、対象ユーザーのプロジェクトロールとインスタンスロールを変更できます。 + - `Organization Owner`ロールに属している場合は、対象ユーザーの組織ロール、プロジェクトロール、およびインスタンスロールを変更できます。 + - `Project Owner`ロールに属している場合は、対象ユーザーのプロジェクトロールとインスタンスロールを変更できます。 -4. **Save**をクリックしてください。 +4. **Save**をクリックしてください。 ## ユーザープロファイルの管理 {#manage-user-profiles} TiDB Cloudでは、氏名（姓、名）、電話番号など、プロフィール情報を簡単に管理できます。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左下隅にあるをクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左下隅にあるをクリックします。 -2. **Account Settings**をクリックしてください。 +2. **Account Settings**をクリックしてください。 -3. 表示されたダイアログで、プロファイル情報を更新し、 **Update**をクリックします。 +3. 表示されたダイアログで、プロファイル情報を更新し、 **Update**をクリックします。 diff --git a/tidb-cloud/managed-service-provider-customer.md b/tidb-cloud/managed-service-provider-customer.md index 9496de17aa0e2..222bd7f866cd1 100644 --- a/tidb-cloud/managed-service-provider-customer.md +++ b/tidb-cloud/managed-service-provider-customer.md @@ -9,8 +9,8 @@ summary: マネージド サービス プロバイダー (MSP) の顧客にな TiDB Cloud の直接顧客と比較すると、サインアップと請求書の支払いに関していくつかの違いがあります。 -- MSP 顧客は、MSP が提供する専用のサインアップ ページからTiDB Cloudアカウントにサインアップする必要があります。 -- MSP 顧客は、PingCAP に直接支払うのではなく、MSP チャネルを通じて請求書を支払います。 +- MSP 顧客は、MSP が提供する専用のサインアップ ページからTiDB Cloudアカウントにサインアップする必要があります。 +- MSP 顧客は、PingCAP に直接支払うのではなく、MSP チャネルを通じて請求書を支払います。 TiDB Cloudコンソールでのその他の日常的な操作は、直接のTiDB Cloud顧客と MSP 顧客の両方で同じです。 diff --git a/tidb-cloud/migrate-from-mysql-using-aws-dms.md b/tidb-cloud/migrate-from-mysql-using-aws-dms.md index 02c4d2f43a66a..587d078510ad8 100644 --- a/tidb-cloud/migrate-from-mysql-using-aws-dms.md +++ b/tidb-cloud/migrate-from-mysql-using-aws-dms.md @@ -17,118 +17,118 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ 移行を開始する前に、以下の内容を必ずお読みください。 -- ソースデータベースが Amazon RDS または Amazon Auroraの場合、 `binlog_format`パラメータを`ROW`に設定する必要があります。データベースがデフォルトのパラメータ グループを使用する場合、 `binlog_format`パラメータはデフォルトで`MIXED`となり、変更できません。この場合、 [新しいパラメータグループを作成する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.Prerequisites.html#CHAP_GettingStarted.Prerequisites.params)必要があります (例: `newset` 。その`binlog_format`を`ROW`に設定します。次に、 [デフォルトパラメータグループを変更する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithDBInstanceParamGroups.html#USER_WorkingWithParamGroups.Modifying)`newset`に変更します。パラメータ グループを変更するとデータベースが再起動されることに注意してください。 -- ソース データベースが TiDB と互換性のある照合順序を使用していることを確認してください。TiDB の utf8mb4 文字セットのデフォルトの照合照合順序は`utf8mb4_bin`です。しかし、MySQL 8.0 では、デフォルトの照合照合順序は`utf8mb4_0900_ai_ci`です。アップストリームの MySQL がデフォルトの照合順序を使用している場合、TiDB は`utf8mb4_0900_ai_ci`と互換性がないため、AWS DMS は TiDB にターゲット テーブルを作成できず、データを移行できません。この問題を解決するには、移行前にソース データベースの照合順序`utf8mb4_bin`に変更する必要があります。TiDB でサポートされている文字セットと照合順序の完全なリストについては、 [文字セットと照合](https://docs.pingcap.com/tidb/stable/character-set-and-collation)を参照してください。 -- TiDB には、デフォルトで`INFORMATION_SCHEMA` 、 `PERFORMANCE_SCHEMA` 、 `mysql` 、 `sys` } 、および`test`システム データベースが含まれています。AWS DMS 移行タスクを作成する際は、デフォルトの`%`を使用して移行オブジェクトを選択するのではなく、これらのシステム データベースを除外する必要があります。そうしないと、AWS DMS はこれらのシステム データベースをソース データベースからターゲット TiDB に移行しようとし、タスクが失敗します。この問題を回避するには、特定のデータベース名とテーブル名を入力することをお勧めします。 -- AWS DMSのパブリックネットワークIPアドレスとプライベートネットワークIPアドレスを、ソースデータベースとターゲットデータベースの両方のIPアクセスリストに追加してください。そうしないと、状況によってはネットワーク接続が失敗する可能性があります。 -- [VPCピアリング](/tidb-cloud/set-up-vpc-peering-connections.md#set-up-vpc-peering-on-aws)または[プライベートエンドポイント接続](/tidb-cloud/set-up-private-endpoint-connections.md)を使用して、AWS DMS と TiDB クラスターを接続します。 -- データ書き込みパフォーマンスを向上させるため、AWS DMSとTiDBクラスターには同じリージョンを使用することをお勧めします。 -- AWS DMS `dms.t3.large` （2 vCPU、8 GiBメモリ）以上のインスタンスクラスを使用することをお勧めします。インスタンスクラスが小さい場合、メモリ不足（OOM）エラーが発生する可能性があります。 -- AWS DMS は、ターゲット データベースに`awsdms_control`データベースを自動的に作成します。 +- ソースデータベースが Amazon RDS または Amazon Auroraの場合、 `binlog_format`パラメータを`ROW`に設定する必要があります。データベースがデフォルトのパラメータ グループを使用する場合、 `binlog_format`パラメータはデフォルトで`MIXED`となり、変更できません。この場合、 [新しいパラメータグループを作成する](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.Prerequisites.html#CHAP_GettingStarted.Prerequisites.params)必要があります (例: `newset` 。その`binlog_format`を`ROW`に設定します。次に、 [デフォルトパラメータグループを変更する](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithDBInstanceParamGroups.html#USER_WorkingWithParamGroups.Modifying)`newset`に変更します。パラメータ グループを変更するとデータベースが再起動されることに注意してください。 +- ソース データベースが TiDB と互換性のある照合順序を使用していることを確認してください。TiDB の utf8mb4 文字セットのデフォルトの照合照合順序は`utf8mb4_bin`です。しかし、MySQL 8.0 では、デフォルトの照合照合順序は`utf8mb4_0900_ai_ci`です。アップストリームの MySQL がデフォルトの照合順序を使用している場合、TiDB は`utf8mb4_0900_ai_ci`と互換性がないため、AWS DMS は TiDB にターゲット テーブルを作成できず、データを移行できません。この問題を解決するには、移行前にソース データベースの照合順序`utf8mb4_bin`に変更する必要があります。TiDB でサポートされている文字セットと照合順序の完全なリストについては、 [文字セットと照合](https://docs.pingcap.com/tidb/stable/character-set-and-collation)を参照してください。 +- TiDB には、デフォルトで`INFORMATION_SCHEMA` 、 `PERFORMANCE_SCHEMA` 、 `mysql` 、 `sys` } 、および`test`システム データベースが含まれています。AWS DMS 移行タスクを作成する際は、デフォルトの`%`を使用して移行オブジェクトを選択するのではなく、これらのシステム データベースを除外する必要があります。そうしないと、AWS DMS はこれらのシステム データベースをソース データベースからターゲット TiDB に移行しようとし、タスクが失敗します。この問題を回避するには、特定のデータベース名とテーブル名を入力することをお勧めします。 +- AWS DMSのパブリックネットワークIPアドレスとプライベートネットワークIPアドレスを、ソースデータベースとターゲットデータベースの両方のIPアクセスリストに追加してください。そうしないと、状況によってはネットワーク接続が失敗する可能性があります。 +- [VPCピアリング](/tidb-cloud/set-up-vpc-peering-connections.md#set-up-vpc-peering-on-aws)または[プライベートエンドポイント接続](/tidb-cloud/set-up-private-endpoint-connections.md)を使用して、AWS DMS と TiDB クラスターを接続します。 +- データ書き込みパフォーマンスを向上させるため、AWS DMSとTiDBクラスターには同じリージョンを使用することをお勧めします。 +- AWS DMS `dms.t3.large` （2 vCPU、8 GiBメモリ）以上のインスタンスクラスを使用することをお勧めします。インスタンスクラスが小さい場合、メモリ不足（OOM）エラーが発生する可能性があります。 +- AWS DMS は、ターゲット データベースに`awsdms_control`データベースを自動的に作成します。 ## 制限 {#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 は`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)を参照してください。 ## ステップ1. AWS DMSレプリケーションインスタンスを作成する {#step-1-create-an-aws-dms-replication-instance} -1. AWS DMS コンソールの[レプリケーションインスタンス](https://console.aws.amazon.com/dms/v2/home#replicationInstances)ページに移動し、対応するリージョンに切り替えます。 AWS DMS にはTiDB Cloudと同じリージョンを使用することをお勧めします。このドキュメントでは、アップストリームおよびダウンストリームのデータベースと DMS インスタンスはすべて**us-west-2**リージョンにあります。 +1. AWS DMS コンソールの[レプリケーションインスタンス](https://console.aws.amazon.com/dms/v2/home#replicationInstances)ページに移動し、対応するリージョンに切り替えます。 AWS DMS にはTiDB Cloudと同じリージョンを使用することをお勧めします。このドキュメントでは、アップストリームおよびダウンストリームのデータベースと DMS インスタンスはすべて**us-west-2**リージョンにあります。 -2. **Create replication instance**をクリックします。 +2. **Create replication instance**をクリックします。 ![Create replication instance](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-create-instance.png) -3. インスタンス名、ARN、および説明を入力してください。 +3. インスタンス名、ARN、および説明を入力してください。 -4. インスタンス構成を入力してください。 - - **Instance class**：適切なインスタンスクラスを選択してください。パフォーマンスを向上させるには、 `dms.t3.large`またはそれより高いインスタンスクラスを使用することをお勧めします。 - - **Engine version**：デフォルト設定を使用します。 - - **マルチAZ** ：ビジネスニーズに応じて、**Single-AZ**または**マルチAZ**を選択してください。 +4. インスタンス構成を入力してください。 + - **Instance class**：適切なインスタンスクラスを選択してください。パフォーマンスを向上させるには、 `dms.t3.large`またはそれより高いインスタンスクラスを使用することをお勧めします。 + - **Engine version**：デフォルト設定を使用します。 + - **マルチAZ** ：ビジネスニーズに応じて、**Single-AZ**または**マルチAZ**を選択してください。 -5. ストレージは**Allocated storage (GiB)**フィールドで設定します。デフォルト設定を使用してください。 +5. ストレージは**Allocated storage (GiB)**フィールドで設定します。デフォルト設定を使用してください。 -6. 接続性とセキュリティを設定します。 - - **Network type - new**: **IPv4**を選択してください。 - - **IPv4 用仮想プライベートクラウド (VPC)** ：必要な VPC を選択してください。ネットワーク構成を簡素化するため、アップストリームデータベースと同じ VPC を使用することをお勧めします。 - - **Replication subnet group**：レプリケーションインスタンスに使用するサブネットグループを選択してください。 - - **Public accessible**：デフォルト設定を使用します。 +6. 接続性とセキュリティを設定します。 + - **Network type - new**: **IPv4**を選択してください。 + - **IPv4 用仮想プライベートクラウド (VPC)** ：必要な VPC を選択してください。ネットワーク構成を簡素化するため、アップストリームデータベースと同じ VPC を使用することをお勧めします。 + - **Replication subnet group**：レプリケーションインスタンスに使用するサブネットグループを選択してください。 + - **Public accessible**：デフォルト設定を使用します。 -7. 必要に応じて、**Advanced settings**、**Maintenance**、および**Tags**を設定します。 **Create replication instance**をクリックして、インスタンスの作成を完了します。 +7. 必要に応じて、**Advanced settings**、**Maintenance**、および**Tags**を設定します。 **Create replication instance**をクリックして、インスタンスの作成を完了します。 ## ステップ2. ソースデータベースエンドポイントを作成する {#step-2-create-the-source-database-endpoint} -1. [AWS DMSコンソール](https://console.aws.amazon.com/dms/v2/home)で、先ほど作成したレプリケーションインスタンスをクリックします。次のスクリーンショットに示すように、パブリックネットワークIPアドレスとプライベートネットワークIPアドレスをコピーします。 +1. [AWS DMSコンソール](https://console.aws.amazon.com/dms/v2/home)で、先ほど作成したレプリケーションインスタンスをクリックします。次のスクリーンショットに示すように、パブリックネットワークIPアドレスとプライベートネットワークIPアドレスをコピーします。 ![Copy the public and private network IP addresses](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-copy-ip.png) -2. Amazon RDS のセキュリティグループルールを設定します。この例では、AWS DMS インスタンスのパブリック IP アドレスとプライベート IP アドレスをセキュリティグループに追加します。 +2. Amazon RDS のセキュリティグループルールを設定します。この例では、AWS DMS インスタンスのパブリック IP アドレスとプライベート IP アドレスをセキュリティグループに追加します。 ![Configure the security group rules](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-rules.png) -3. ソースデータベースのエンドポイントを作成するには、 **Create endpoint**をクリックします。 +3. ソースデータベースのエンドポイントを作成するには、 **Create endpoint**をクリックします。 ![Click Create endpoint](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-endpoint.png) -4. この例では、 **Select RDS DB instance**をクリックし、ソースとなるRDSインスタンスを選択します。ソースデータベースがセルフホスト型のMySQLの場合は、この手順をスキップして、次の手順で情報を入力できます。 +4. この例では、 **Select RDS DB instance**をクリックし、ソースとなるRDSインスタンスを選択します。ソースデータベースがセルフホスト型のMySQLの場合は、この手順をスキップして、次の手順で情報を入力できます。 ![Select RDS DB instance](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-select-rds.png) -5. 以下の情報を設定してください。 +5. 以下の情報を設定してください。 - - **Endpoint identifier**：後続のタスク構成で識別しやすくするために、ソースエンドポイントにラベルを作成します。 - - **記述的な Amazon リソース名 (ARN) - オプション**: デフォルトの DMS ARN に分かりやすい名前を作成します。 - - **Source engine**: **MySQL**を選択してください。 - - **Access to endpoint database**:**Provide access information manually**を選択します。 - - **Server name**：データプロバイダーのデータサーバー名を入力してください。データベースコンソールからコピーできます。アップストリームがAmazon RDSまたはAmazon Auroraの場合は、名前が自動的に入力されます。ドメイン名のないセルフホスト型MySQLの場合は、IPアドレスを入力してください。 - - ソースデータベースの**Port**、**Username**、**Password**を入力してください。 - - **セキュリティソケットレイヤー（SSL）モード**：必要に応じてSSLモードを有効にできます。 + - **Endpoint identifier**：後続のタスク構成で識別しやすくするために、ソースエンドポイントにラベルを作成します。 + - **記述的な Amazon リソース名 (ARN) - オプション**: デフォルトの DMS ARN に分かりやすい名前を作成します。 + - **Source engine**: **MySQL**を選択してください。 + - **Access to endpoint database**:**Provide access information manually**を選択します。 + - **Server name**：データプロバイダーのデータサーバー名を入力してください。データベースコンソールからコピーできます。アップストリームがAmazon RDSまたはAmazon Auroraの場合は、名前が自動的に入力されます。ドメイン名のないセルフホスト型MySQLの場合は、IPアドレスを入力してください。 + - ソースデータベースの**Port**、**Username**、**Password**を入力してください。 + - **セキュリティソケットレイヤー（SSL）モード**：必要に応じてSSLモードを有効にできます。 ![Fill in the endpoint configurations](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-endpoint-config.png) -6. **Endpoint settings**、 **KMS key**、**Tags**にはデフォルト値を使用してください。**Test endpoint connection (optional)**セクションでは、ネットワーク構成を簡素化するために、ソースデータベースと同じVPCを選択することをお勧めします。対応するレプリケーションインスタンスを選択し、 **Run test**をクリックします。ステータスが**successful**である必要があります。 +6. **Endpoint settings**、 **KMS key**、**Tags**にはデフォルト値を使用してください。**Test endpoint connection (optional)**セクションでは、ネットワーク構成を簡素化するために、ソースデータベースと同じVPCを選択することをお勧めします。対応するレプリケーションインスタンスを選択し、 **Run test**をクリックします。ステータスが**successful**である必要があります。 -7. **Create endpoint**をクリックします。 +7. **Create endpoint**をクリックします。 ![Click Create endpoint](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-connection.png) ## ステップ3. ターゲットデータベースエンドポイントを作成する {#step-3-create-the-target-database-endpoint} -1. [AWS DMSコンソール](https://console.aws.amazon.com/dms/v2/home)で、先ほど作成したレプリケーションインスタンスをクリックします。次のスクリーンショットに示すように、パブリックネットワークIPアドレスとプライベートネットワークIPアドレスをコピーします。 +1. [AWS DMSコンソール](https://console.aws.amazon.com/dms/v2/home)で、先ほど作成したレプリケーションインスタンスをクリックします。次のスクリーンショットに示すように、パブリックネットワークIPアドレスとプライベートネットワークIPアドレスをコピーします。 ![Copy the public and private network IP addresses](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-copy-ip.png) -2. TiDB Cloudコンソールで、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のリソース名をクリックしてから、右上隅の**Connect**をクリックすると、 TiDB Cloudデータベースの接続情報が表示されます。 +2. TiDB Cloudコンソールで、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のリソース名をクリックしてから、右上隅の**Connect**をクリックすると、 TiDB Cloudデータベースの接続情報が表示されます。 -3. ダイアログの**Step 1: Create traffic filter**で、 **Edit**をクリックし、AWS DMS コンソールからコピーしたパブリック IP アドレスとプライベート IP アドレスを入力して、 **Update Filter**をクリックします。AWS DMS レプリケーション インスタンスのパブリック IP アドレスとプライベート IP アドレスを TiDB クラスタのトラフィック フィルタに同時に追加することをお勧めします。そうしないと、状況によっては AWS DMS が TiDB クラスタに接続できない場合があります。 +3. ダイアログの**Step 1: Create traffic filter**で、 **Edit**をクリックし、AWS DMS コンソールからコピーしたパブリック IP アドレスとプライベート IP アドレスを入力して、 **Update Filter**をクリックします。AWS DMS レプリケーション インスタンスのパブリック IP アドレスとプライベート IP アドレスを TiDB クラスタのトラフィック フィルタに同時に追加することをお勧めします。そうしないと、状況によっては AWS DMS が TiDB クラスタに接続できない場合があります。 -4. **Download CA cert**をクリックします。ダイアログの**[ステップ3：SQLクライアントで接続する**]で、接続文字列内の`-u` 、 `-h` 、および`-P`情報を後で使用するためにメモしておきます。 +4. **Download CA cert**をクリックします。ダイアログの**[ステップ3：SQLクライアントで接続する**]で、接続文字列内の`-u` 、 `-h` 、および`-P`情報を後で使用するためにメモしておきます。 -5. ダイアログの**VPC Peering**タブをクリックし、 **Step 1: Set up VPC**の下にある**Add**をクリックして、TiDBクラスターとAWS DMSのVPCピアリング接続を作成します。 +5. ダイアログの**VPC Peering**タブをクリックし、 **Step 1: Set up VPC**の下にある**Add**をクリックして、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クラスタのターゲットエンドポイントを設定します。 +7. TiDBクラスタのターゲットエンドポイントを設定します。 - - **Endpoint type**：**Target endpoint**を選択してください。 - - **Endpoint identifier**：エンドポイントの名前を入力してください。 - - **記述的な Amazon リソース名 (ARN) - オプション**: デフォルトの DMS ARN に分かりやすい名前を作成します。 - - **Target engine**: **MySQL**を選択してください。 + - **Endpoint type**：**Target endpoint**を選択してください。 + - **Endpoint identifier**：エンドポイントの名前を入力してください。 + - **記述的な Amazon リソース名 (ARN) - オプション**: デフォルトの DMS ARN に分かりやすい名前を作成します。 + - **Target engine**: **MySQL**を選択してください。 ![Configure the target endpoint](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-target-endpoint.png) -8. [AWS DMSコンソール](https://console.aws.amazon.com/dms/v2/home)で、 **Create endpoint**をクリックしてターゲットデータベースエンドポイントを作成し、次の情報を設定します。 +8. [AWS DMSコンソール](https://console.aws.amazon.com/dms/v2/home)で、 **Create endpoint**をクリックしてターゲットデータベースエンドポイントを作成し、次の情報を設定します。 - - **Server name**: 記録した`-h`情報である TiDB クラスターのホスト名を入力してください。 - - **Port**：記録した`-P`情報と同じTiDBクラスタのポート番号を入力してください。TiDBクラスタのデフォルトポートは4000です。 - - **User name**: TiDB クラスターのユーザー名を入力してください。これは、記録した`-u`情報です。 - - **Password**：TiDBクラスタのパスワードを入力してください。 - - **セキュリティソケットレイヤー（SSL）モード**： **Verify-ca**を選択します。 - - **Add new CA certificate**をクリックして、前の手順でTiDB CloudコンソールからダウンロードしたCAファイルをインポートします。 + - **Server name**: 記録した`-h`情報である TiDB クラスターのホスト名を入力してください。 + - **Port**：記録した`-P`情報と同じTiDBクラスタのポート番号を入力してください。TiDBクラスタのデフォルトポートは4000です。 + - **User name**: TiDB クラスターのユーザー名を入力してください。これは、記録した`-u`情報です。 + - **Password**：TiDBクラスタのパスワードを入力してください。 + - **セキュリティソケットレイヤー（SSL）モード**： **Verify-ca**を選択します。 + - **Add new CA certificate**をクリックして、前の手順でTiDB CloudコンソールからダウンロードしたCAファイルをインポートします。 ![Fill in the target endpoint information](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-target-endpoint2.png) -9. CAファイルをインポートします。 +9. CAファイルをインポートします。 ![Upload CA](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-upload-ca.png) @@ -140,43 +140,43 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ ## ステップ4. データベース移行タスクを作成する {#step-4-create-a-database-migration-task} -1. AWS DMS コンソールで、 [データ移行タスク](https://console.aws.amazon.com/dms/v2/home#tasks)ページに移動します。お住まいの地域に切り替えてください。次に、ウィンドウの右上隅にある**Create task**をクリックします。 +1. AWS DMS コンソールで、 [データ移行タスク](https://console.aws.amazon.com/dms/v2/home#tasks)ページに移動します。お住まいの地域に切り替えてください。次に、ウィンドウの右上隅にある**Create task**をクリックします。 ![Create task](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-create-task.png) -2. 以下の情報を設定してください。 +2. 以下の情報を設定してください。 - - **Task identifier**: タスクの名前を入力してください。覚えやすい名前を使用することをお勧めします。 - - **記述的な Amazon リソース名 (ARN) - オプション**: デフォルトの DMS ARN に分かりやすい名前を作成します。 - - **Replication instance**：先ほど作成したAWS DMSインスタンスを選択します。 - - **Source database endpoint**：先ほど作成したソースデータベースエンドポイントを選択してください。 - - **Target database endpoint**：先ほど作成したターゲットデータベースエンドポイントを選択してください。 - - **Migration type**：必要に応じて移行タイプを選択してください。この例では、 **Migrate existing data and replicate ongoing changes**を選択します。 + - **Task identifier**: タスクの名前を入力してください。覚えやすい名前を使用することをお勧めします。 + - **記述的な Amazon リソース名 (ARN) - オプション**: デフォルトの DMS ARN に分かりやすい名前を作成します。 + - **Replication instance**：先ほど作成したAWS DMSインスタンスを選択します。 + - **Source database endpoint**：先ほど作成したソースデータベースエンドポイントを選択してください。 + - **Target database endpoint**：先ほど作成したターゲットデータベースエンドポイントを選択してください。 + - **Migration type**：必要に応じて移行タイプを選択してください。この例では、 **Migrate existing data and replicate ongoing changes**を選択します。 ![Task configurations](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-task-config.png) -3. 以下の情報を設定してください。 +3. 以下の情報を設定してください。 - - **Editing mode**：**ウィザード**を選択してください。 - - **ソーストランザクションのカスタムCDC停止モード**：デフォルト設定を使用します。 - - **Target table preparation mode**：必要に応じて**Do nothing**またはその他のオプションを選択してください。この例では、 **Do nothing**を選択します。 - - **フルロード完了後にタスクを停止する**：デフォルト設定を使用する。 - - **LOB列をレプリケーションに含める**：**Limited LOB mode**を選択します。 - - **LOBの最大サイズ（KB）** ：デフォルト値の**32**を使用します。 - - **Turn on validation**：必要に応じて選択してください。 - - **Task logs**: 今後のトラブルシューティングのために、 **Turn on CloudWatch logs**を選択してください。関連する設定については、デフォルト設定を使用してください。 + - **Editing mode**：**ウィザード**を選択してください。 + - **ソーストランザクションのカスタムCDC停止モード**：デフォルト設定を使用します。 + - **Target table preparation mode**：必要に応じて**Do nothing**またはその他のオプションを選択してください。この例では、 **Do nothing**を選択します。 + - **フルロード完了後にタスクを停止する**：デフォルト設定を使用する。 + - **LOB列をレプリケーションに含める**：**Limited LOB mode**を選択します。 + - **LOBの最大サイズ（KB）** ：デフォルト値の**32**を使用します。 + - **Turn on validation**：必要に応じて選択してください。 + - **Task logs**: 今後のトラブルシューティングのために、 **Turn on CloudWatch logs**を選択してください。関連する設定については、デフォルト設定を使用してください。 ![Task settings](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-task-settings.png) -4. **Table mappings**のセクションで、移行するデータベースを指定します。 +4. **Table mappings**のセクションで、移行するデータベースを指定します。 スキーマ名は、Amazon RDS インスタンス内のデータベース名です。**Source name**のデフォルト値は「%」で、これは Amazon RDS 内のすべてのデータベースが TiDB に移行されることを意味します。これにより、Amazon RDS 内の`mysql`や`sys`などのシステム データベースが TiDB クラスターに移行され、タスクが失敗します。そのため、特定のデータベース名を入力するか、すべてのシステム データベースを除外することをお勧めします。たとえば、次のスクリーンショットの設定に従って、 `franktest`という名前のデータベースと、そのデータベース内のすべてのテーブルのみが移行されます。 ![Table mappings](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-table-mappings.png) -5. 右下隅の**Create task**をクリックしてください。 +5. 右下隅の**Create task**をクリックしてください。 -6. [データ移行タスク](https://console.aws.amazon.com/dms/v2/home#tasks)ページに戻ります。お住まいの地域に切り替えてください。タスクのステータスと進捗状況を確認できます。 +6. [データ移行タスク](https://console.aws.amazon.com/dms/v2/home#tasks)ページに戻ります。お住まいの地域に切り替えてください。タスクのステータスと進捗状況を確認できます。 ![Tasks status](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-task-status.png) @@ -186,8 +186,8 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ ## 関連項目 {#see-also} -- AWS DMS をTiDB Cloudに接続する方法の詳細については、 [AWS DMSをTiDB Cloudに接続する](/tidb-cloud/tidb-cloud-connect-aws-dms.md)を参照してください。 +- AWS DMS をTiDB Cloudに接続する方法の詳細については、 [AWS DMSをTiDB Cloudに接続する](/tidb-cloud/tidb-cloud-connect-aws-dms.md)を参照してください。 -- Aurora MySQL や Amazon Relational Database Service (RDS) などの MySQL 互換データベースからTiDB Cloudに移行する場合は、 [TiDB Cloudでのデータ移行](/tidb-cloud/migrate-from-mysql-using-data-migration.md)を使用することをお勧めします。 +- Aurora MySQL や Amazon Relational Database Service (RDS) などの MySQL 互換データベースからTiDB Cloudに移行する場合は、 [TiDB Cloudでのデータ移行](/tidb-cloud/migrate-from-mysql-using-data-migration.md)を使用することをお勧めします。 -- AWS DMS を使用して Amazon RDS for Oracle からTiDB Cloudに移行する場合は、 [AWS DMSを使用してAmazon RDS for OracleからTiDB Cloudに移行する](/tidb-cloud/migrate-from-oracle-using-aws-dms.md)を参照してください。 +- AWS DMS を使用して Amazon RDS for Oracle からTiDB Cloudに移行する場合は、 [AWS DMSを使用してAmazon RDS for OracleからTiDB Cloudに移行する](/tidb-cloud/migrate-from-oracle-using-aws-dms.md)を参照してください。 diff --git a/tidb-cloud/migrate-from-mysql-using-data-migration.md b/tidb-cloud/migrate-from-mysql-using-data-migration.md index 327945fc53922..46a4145b1a1b3 100644 --- a/tidb-cloud/migrate-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-from-mysql-using-data-migration.md @@ -32,22 +32,22 @@ aliases: ['/ja/tidbcloud/migrate-data-into-tidb','/ja/tidbcloud/migrate-incremen ### 可用性 {#availability} -- 現在、 TiDB Cloud Starterではデータ移行機能は利用できません。 +- 現在、 TiDB Cloud Starterではデータ移行機能は利用できません。 -- [TiDB Cloudコンソール](https://tidbcloud.com/)にTiDB Cloud Dedicatedクラスターの[データ移行](/tidb-cloud/migrate-from-mysql-using-data-migration.md#step-1-go-to-the-data-migration-page)エントリーが表示されない場合、その機能はお住まいの地域で利用できない可能性があります。お住まいの地域のサポートをリクエストするには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 +- [TiDB Cloudコンソール](https://tidbcloud.com/)にTiDB Cloud Dedicatedクラスターの[データ移行](/tidb-cloud/migrate-from-mysql-using-data-migration.md#step-1-go-to-the-data-migration-page)エントリーが表示されない場合、その機能はお住まいの地域で利用できない可能性があります。お住まいの地域のサポートをリクエストするには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 -- Amazon Aurora MySQL ライターインスタンスは、既存データ移行と増分データ移行の両方をサポートします。Amazon Aurora MySQL リーダーインスタンスは、既存データ移行のみをサポートし、増分データ移行はサポートしません。 +- Amazon Aurora MySQL ライターインスタンスは、既存データ移行と増分データ移行の両方をサポートします。Amazon Aurora MySQL リーダーインスタンスは、既存データ移行のみをサポートし、増分データ移行はサポートしません。 -- TiDB Cloud Premiumのデータ移行機能は、現在パブリックプレビュー版として提供されています。 +- TiDB Cloud Premiumのデータ移行機能は、現在パブリックプレビュー版として提供されています。 - - 移行ジョブ間でソース接続の詳細を保存または再利用することはできません。 - - パブリックプレビュー期間中は、機能の成熟に伴い、移行ジョブに追加の制限が適用される場合があります。詳細については、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 + - 移行ジョブ間でソース接続の詳細を保存または再利用することはできません。 + - パブリックプレビュー期間中は、機能の成熟に伴い、移行ジョブに追加の制限が適用される場合があります。詳細については、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 @@ -70,11 +70,11 @@ TiDB Cloud Essentialインスタンスでは、組織ごとに最大 100 個の ### フィルタリングおよび削除されたデータベース {#filtered-out-and-deleted-databases} -- システムデータベースは、移行するデータベースをすべて選択した場合でも、フィルタリングされてTiDB Cloudに移行されません。つまり、 `mysql` 、 `information_schema` 、 `performance_schema` 、および`sys`は、この機能を使用して移行されません。 +- システムデータベースは、移行するデータベースをすべて選択した場合でも、フィルタリングされてTiDB Cloudに移行されません。つまり、 `mysql` 、 `information_schema` 、 `performance_schema` 、および`sys`は、この機能を使用して移行されません。 -- TiDB CloudでTiDB Cloud Dedicatedクラスタを削除すると、そのクラスタ内のすべての移行ジョブが自動的に削除され、復元できなくなります。 +- TiDB CloudでTiDB Cloud Dedicatedクラスタを削除すると、そのクラスタ内のすべての移行ジョブが自動的に削除され、復元できなくなります。 @@ -90,24 +90,24 @@ Alibaba Cloud RDSをデータソースとして使用する場合、すべての ### 既存のデータ移行の限界 {#limitations-of-existing-data-migration} -- 既存データの移行中に、移行対象のテーブルが移行先のデータベースに既に存在し、かつ重複するキーがある場合、重複するキーを持つ行は置き換えられます。 +- 既存データの移行中に、移行対象のテーブルが移行先のデータベースに既に存在し、かつ重複するキーがある場合、重複するキーを持つ行は置き換えられます。 -- TiDB Cloud Dedicatedの場合、データセット サイズが 1 TiB より小さい場合は、論理モード (デフォルト モード) を使用することをお勧めします。データセットのサイズが 1 TiB より大きい場合、または既存のデータをより速く移行したい場合は、物理モードを使用できます。詳細については、[既存データと増分データを移行する](#migrate-existing-data-and-incremental-data)を参照してください。 +- TiDB Cloud Dedicatedの場合、データセット サイズが 1 TiB より小さい場合は、論理モード (デフォルト モード) を使用することをお勧めします。データセットのサイズが 1 TiB より大きい場合、または既存のデータをより速く移行したい場合は、物理モードを使用できます。詳細については、[既存データと増分データを移行する](#migrate-existing-data-and-incremental-data)を参照してください。 -- TiDB Cloud Essentialでは、現在、データ移行には論理モードのみがサポートされています。このモードでは、MySQLソースデータベースからSQLステートメントとしてデータをエクスポートし、TiDB上で実行します。このモードでは、移行前のターゲットテーブルは空でも空でなくても構いません。 +- TiDB Cloud Essentialでは、現在、データ移行には論理モードのみがサポートされています。このモードでは、MySQLソースデータベースからSQLステートメントとしてデータをエクスポートし、TiDB上で実行します。このモードでは、移行前のターゲットテーブルは空でも空でなくても構いません。 -- TiDB Cloud Premium では、論理モード (デフォルト) と物理モードの両方がサポートされています。論理モードでは、MySQL ソース データベースから SQL ステートメントとしてデータをエクスポートし、ターゲットのTiDB Cloud Premium インスタンスで実行します。このとき、ロード中にリクエストキャパシティユニット (RCU) が消費されます。物理モードでは、ターゲットのTiDB Cloud Premium インスタンスで`IMPORT INTO`を使用し、ロードのスループットとコスト効率を優先する場合の大規模データセットに推奨されます。 -- 物理モードを使用し、移行ジョブが開始されたら、 TiDB Cloud PremiumインスタンスでPITR（ポイントインタイムリカバリ）を有効にしたり、変更フィードを設定したり**しないで**ください。そうしないと、移行ジョブが停止します。PITRを有効にしたり、変更フィードを設定したりする必要がある場合は、代わりに論理モードを使用してデータを移行してください。 -- 物理モードを使用する場合、既存のデータ移行が完了する前に、 TiDB Cloud Premiumインスタンスに対して2つ目の移行ジョブまたはインポートタスクを作成することはできません。 +- TiDB Cloud Premium では、論理モード (デフォルト) と物理モードの両方がサポートされています。論理モードでは、MySQL ソース データベースから SQL ステートメントとしてデータをエクスポートし、ターゲットのTiDB Cloud Premium インスタンスで実行します。このとき、ロード中にリクエストキャパシティユニット (RCU) が消費されます。物理モードでは、ターゲットのTiDB Cloud Premium インスタンスで`IMPORT INTO`を使用し、ロードのスループットとコスト効率を優先する場合の大規模データセットに推奨されます。 +- 物理モードを使用し、移行ジョブが開始されたら、 TiDB Cloud PremiumインスタンスでPITR（ポイントインタイムリカバリ）を有効にしたり、変更フィードを設定したり**しないで**ください。そうしないと、移行ジョブが停止します。PITRを有効にしたり、変更フィードを設定したりする必要がある場合は、代わりに論理モードを使用してデータを移行してください。 +- 物理モードを使用する場合、既存のデータ移行が完了する前に、 TiDB Cloud Premiumインスタンスに対して2つ目の移行ジョブまたはインポートタスクを作成することはできません。 @@ -115,29 +115,29 @@ Alibaba Cloud RDSをデータソースとして使用する場合、すべての -- 増分データ移行中に、移行対象のテーブルが既にターゲットデータベースに重複キーで存在する場合、エラーが報告され、移行は中断されます。この場合、MySQLソースデータが正確であることを確認する必要があります。データが正確であれば、移行ジョブの**Restart**ボタンをクリックすると、移行ジョブはターゲットのTiDB Cloud Dedicatedクラスタ内の競合レコードをMySQLソースレコードに置き換えます。 +- 増分データ移行中に、移行対象のテーブルが既にターゲットデータベースに重複キーで存在する場合、エラーが報告され、移行は中断されます。この場合、MySQLソースデータが正確であることを確認する必要があります。データが正確であれば、移行ジョブの**Restart**ボタンをクリックすると、移行ジョブはターゲットのTiDB Cloud Dedicatedクラスタ内の競合レコードをMySQLソースレコードに置き換えます。 -- 増分データ移行中に、移行対象のテーブルが既にターゲットデータベースに重複キーで存在する場合、エラーが報告され、移行は中断されます。この場合、MySQLソースデータが正確であることを確認する必要があります。データが正確であれば、移行ジョブの**Restart**ボタンをクリックすると、移行ジョブはターゲットのTiDB Cloud Essentialインスタンス内の競合レコードをMySQLソースレコードに置き換えます。 -- 増分データ移行 (進行中の変更をTiDB Cloud Essentialインスタンスに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60 秒間セーフ モードに入ることがあります。セーフ モード中、 TiDB Cloudは`INSERT`ステートメントを`REPLACE`に、 `UPDATE`ステートメントを`DELETE`および`REPLACE`に移行し、これらのトランザクションをターゲットのTiDB Cloud Essentialインスタンスに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソース テーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Essentialインスタンスで重複した行が発生する可能性があります。 +- 増分データ移行中に、移行対象のテーブルが既にターゲットデータベースに重複キーで存在する場合、エラーが報告され、移行は中断されます。この場合、MySQLソースデータが正確であることを確認する必要があります。データが正確であれば、移行ジョブの**Restart**ボタンをクリックすると、移行ジョブはターゲットのTiDB Cloud Essentialインスタンス内の競合レコードをMySQLソースレコードに置き換えます。 +- 増分データ移行 (進行中の変更をTiDB Cloud Essentialインスタンスに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60 秒間セーフ モードに入ることがあります。セーフ モード中、 TiDB Cloudは`INSERT`ステートメントを`REPLACE`に、 `UPDATE`ステートメントを`DELETE`および`REPLACE`に移行し、これらのトランザクションをターゲットのTiDB Cloud Essentialインスタンスに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソース テーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Essentialインスタンスで重複した行が発生する可能性があります。 -- 増分データ移行 (進行中の変更をTiDB Cloud Dedicatedクラスターに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60 秒間セーフ モードに入ることがあります。セーフ モード中、 TiDB Cloudは`INSERT`ステートメントを`REPLACE`に、 `UPDATE`ステートメントを`DELETE`および`REPLACE`に移行し、これらのトランザクションをターゲットのTiDB Cloud Dedicatedクラスターに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソース テーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Dedicated Dedicated クラスターで重複した行が発生する可能性があります。 +- 増分データ移行 (進行中の変更をTiDB Cloud Dedicatedクラスターに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60 秒間セーフ モードに入ることがあります。セーフ モード中、 TiDB Cloudは`INSERT`ステートメントを`REPLACE`に、 `UPDATE`ステートメントを`DELETE`および`REPLACE`に移行し、これらのトランザクションをターゲットのTiDB Cloud Dedicatedクラスターに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソース テーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Dedicated Dedicated クラスターで重複した行が発生する可能性があります。 -- 以下のシナリオでは、移行ジョブに24時間以上かかる場合、ソースデータベースのバイナリログを削除しないでください。これにより、データ移行ツールは増分データ移行のために連続したバイナリログを取得できます。 +- 以下のシナリオでは、移行ジョブに24時間以上かかる場合、ソースデータベースのバイナリログを削除しないでください。これにより、データ移行ツールは増分データ移行のために連続したバイナリログを取得できます。 - - 既存のデータ移行中に。 - - 既存のデータ移行が完了し、増分データ移行が初めて開始された後、レイテンシーは0msになりません。 + - 既存のデータ移行中に。 + - 既存のデータ移行が完了し、増分データ移行が初めて開始された後、レイテンシーは0msになりません。 -- 増分データ移行 (進行中の変更をTiDB Cloud Premium インスタンスに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60 秒間セーフ モードに入ることがあります。セーフ モード中、 TiDB Cloudは`INSERT`ステートメントを`REPLACE`に、 `UPDATE`ステートメントを`DELETE`および`REPLACE`に移行し、これらのトランザクションをターゲットのTiDB Cloud Premium インスタンスに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソース テーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Premium インスタンスで重複した行が発生する可能性があります。 +- 増分データ移行 (進行中の変更をTiDB Cloud Premium インスタンスに移行する) 中に、移行ジョブが突然のエラーから回復した場合、60 秒間セーフ モードに入ることがあります。セーフ モード中、 TiDB Cloudは`INSERT`ステートメントを`REPLACE`に、 `UPDATE`ステートメントを`DELETE`および`REPLACE`に移行し、これらのトランザクションをターゲットのTiDB Cloud Premium インスタンスに適用して、突然のエラー中に発生したすべてのデータが安全にターゲットに到達するようにします。ソース テーブルに主キーまたは null 以外の一意インデックスがない場合、ターゲットのTiDB Cloud Premium インスタンスで重複した行が発生する可能性があります。 @@ -217,7 +217,7 @@ SHOW VARIABLES WHERE Variable_name IN
自己管理型MySQLインスタンスを構成する -1. `/etc/my.cnf`を開いて、以下を追加します。 +1. `/etc/my.cnf`を開いて、以下を追加します。 ``` [mysqld] @@ -228,13 +228,13 @@ SHOW VARIABLES WHERE Variable_name IN binlog_transaction_compression = OFF ``` -2. 変更を適用するには、MySQLサービスを再起動してください。 +2. 変更を適用するには、MySQLサービスを再起動してください。 ``` sudo systemctl restart mysqld ``` -3. 設定が有効になっていることを確認するには、 `SHOW VARIABLES`ステートメントを再度実行してください。 +3. 設定が有効になっていることを確認するには、 `SHOW VARIABLES`ステートメントを再度実行してください。 詳細な手順については、MySQL ドキュメントの[MySQLサーバーのシステム変数](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html)および[バイナリログ](https://dev.mysql.com/doc/refman/8.0/en/binary-log.html)を参照してください。 @@ -242,10 +242,10 @@ SHOW VARIABLES WHERE Variable_name IN
AWS RDSまたはAurora MySQLの設定 -1. AWS マネジメント コンソールで、 [Amazon RDS コンソール](https://console.aws.amazon.com/rds/)を開き、左側のナビゲーション ペインで**Parameter groups**をクリックし、カスタム パラメータ グループを作成または編集します。 -2. 上記の4つのパラメータを必要な値に設定してください。 -3. パラメータグループをインスタンスまたはクラスターにアタッチし、再起動して変更を適用してください。 -4. 再起動後、インスタンスに接続し、 `SHOW VARIABLES`ステートメントを実行して構成を確認します。 +1. AWS マネジメント コンソールで、 [Amazon RDS コンソール](https://console.aws.amazon.com/rds/)を開き、左側のナビゲーション ペインで**Parameter groups**をクリックし、カスタム パラメータ グループを作成または編集します。 +2. 上記の4つのパラメータを必要な値に設定してください。 +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)を参照してください。 @@ -253,13 +253,13 @@ SHOW VARIABLES WHERE Variable_name IN
Azure Database for MySQL の構成 - Flexible Server -1. [Azureポータル](https://portal.azure.com/)で、 **Azure Database for MySQL servers**を検索して選択し、インスタンス名をクリックしてから、左側のナビゲーション ペインで**Setting** > **Server parameters**をクリックします。 +1. [Azureポータル](https://portal.azure.com/)で、 **Azure Database for MySQL servers**を検索して選択し、インスタンス名をクリックしてから、左側のナビゲーション ペインで**Setting** > **Server parameters**をクリックします。 -2. 各パラメータを検索し、その値を更新します。 +2. 各パラメータを検索し、その値を更新します。 ほとんどの変更は再起動なしで反映されます。再起動が必要な場合は、ポータルから通知が表示されます。 -3. `SHOW VARIABLES`ステートメントを実行して、設定を確認します。 +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)を参照してください。 @@ -267,10 +267,10 @@ SHOW VARIABLES WHERE Variable_name IN
Google Cloud SQL for MySQL の設定 -1. [Google Cloud Console](https://console.cloud.google.com/project/_/sql/instances)で、インスタンスを含むプロジェクトを選択し、インスタンス名をクリックして、 **Edit**をクリックします。 -2. 必要なフラグ ( `log_bin` 、 `binlog_format` 、 `binlog_row_image` 、 `binlog_expire_logs_seconds` ) を追加または変更します。 -3. **Save**をクリックしてください。再起動が必要な場合は、コンソールからメッセージが表示されます。 -4. 再起動後、 `SHOW VARIABLES`ステートメントを実行して変更を確認します。 +1. [Google Cloud Console](https://console.cloud.google.com/project/_/sql/instances)で、インスタンスを含むプロジェクトを選択し、インスタンス名をクリックして、 **Edit**をクリックします。 +2. 必要なフラグ ( `log_bin` 、 `binlog_format` 、 `binlog_row_image` 、 `binlog_expire_logs_seconds` ) を追加または変更します。 +3. **Save**をクリックしてください。再起動が必要な場合は、コンソールからメッセージが表示されます。 +4. 再起動後、 `SHOW VARIABLES`ステートメントを実行して変更を確認します。 詳細な手順については、Google Cloud ドキュメントの[データベースフラグを設定する](https://cloud.google.com/sql/docs/mysql/flags)と[特定時点へのリカバリを使用する](https://cloud.google.com/sql/docs/mysql/backup-recovery/pitr)ご覧ください。 @@ -278,21 +278,21 @@ SHOW VARIABLES WHERE Variable_name IN
Alibaba Cloud RDS MySQL の設定 -1. [ApsaraDB RDSコンソール](https://rds.console.aliyun.com/)で、インスタンスのリージョンを選択し、RDS for MySQL インスタンスの ID をクリックします。 +1. [ApsaraDB RDSコンソール](https://rds.console.aliyun.com/)で、インスタンスのリージョンを選択し、RDS for MySQL インスタンスの ID をクリックします。 -2. 左側のナビゲーションペインで**Parameters**をクリックし、各パラメーターを検索して、次の値を設定します。 +2. 左側のナビゲーションペインで**Parameters**をクリックし、各パラメーターを検索して、次の値を設定します。 - - `binlog_row_image` : `FULL` + - `binlog_row_image` : `FULL` -3. 左側のナビゲーション ペインで、 **Backup and Restoration**をクリックし、 **Backup Strategy**を選択します。移行中に DM が連続するbinlogファイルにアクセスできるようにするには、バックアップ戦略を次の制約で構成します。 +3. 左側のナビゲーション ペインで、 **Backup and Restoration**をクリックし、 **Backup Strategy**を選択します。移行中に DM が連続するbinlogファイルにアクセスできるようにするには、バックアップ戦略を次の制約で構成します。 - - 保存期間：最低3日間（推奨7日間）に設定してください。 + - 保存期間：最低3日間（推奨7日間）に設定してください。 - - 保持ファイル: 古いログが時期尚早に上書きされないように、「最大ファイル数」が十分であることを確認してください。 + - 保持ファイル: 古いログが時期尚早に上書きされないように、「最大ファイル数」が十分であることを確認してください。 - - ストレージ保護：ストレージの使用状況を綿密に監視してください。ディスク容量の使用量がシステムしきい値に達すると、保持期間の設定に関わらず、RDS は最も古いバイナリログを自動的に削除しますのでご注意ください。 + - ストレージ保護：ストレージの使用状況を綿密に監視してください。ディスク容量の使用量がシステムしきい値に達すると、保持期間の設定に関わらず、RDS は最も古いバイナリログを自動的に削除しますのでご注意ください。 -4. 変更を適用した後（必要に応じて再起動した後）、インスタンスに接続し、このセクションの`SHOW VARIABLES`ステートメントを実行して構成を確認します。 +4. 変更を適用した後（必要に応じて再起動した後）、インスタンスに接続し、このセクションの`SHOW VARIABLES`ステートメントを実行して構成を確認します。 詳細については、 [インスタンスパラメータを設定します](https://www.alibabacloud.com/help/en/rds/apsaradb-rds-for-mysql/modify-the-parameters-of-an-apsaradb-rds-for-mysql-instance)を参照してください。 @@ -342,10 +342,10 @@ TiDB Cloud Premiumで利用可能な接続方法は以下のとおりです。
TLS/SSL暗号化接続用のクラウドプロバイダーの証明書をダウンロードして保存する -- Amazon Aurora MySQL または Amazon RDS MySQL: [SSL/TLSを使用してDBインスタンスまたはクラスタへの接続を暗号化する](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.SSL.html) -- Azure Database for MySQL - フレキシブル サーバー: [暗号化された接続で接続します](https://learn.microsoft.com/en-us/azure/mysql/flexible-server/how-to-connect-tls-ssl) -- Google Cloud SQL for MySQL: [SSL/TLS証明書の管理](https://cloud.google.com/sql/docs/mysql/manage-ssl-instance) -- Alibaba Cloud RDS MySQL: [SSL暗号化機能を設定する](https://www.alibabacloud.com/help/en/rds/apsaradb-rds-for-mysql/configure-a-cloud-certificate-to-enable-ssl-encryption) +- Amazon Aurora MySQL または Amazon RDS MySQL: [SSL/TLSを使用してDBインスタンスまたはクラスタへの接続を暗号化する](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.SSL.html) +- Azure Database for MySQL - フレキシブル サーバー: [暗号化された接続で接続します](https://learn.microsoft.com/en-us/azure/mysql/flexible-server/how-to-connect-tls-ssl) +- Google Cloud SQL for MySQL: [SSL/TLS証明書の管理](https://cloud.google.com/sql/docs/mysql/manage-ssl-instance) +- Alibaba Cloud RDS MySQL: [SSL暗号化機能を設定する](https://www.alibabacloud.com/help/en/rds/apsaradb-rds-for-mysql/configure-a-cloud-certificate-to-enable-ssl-encryption)
@@ -359,27 +359,27 @@ TiDB Cloud Premiumで利用可能な接続方法は以下のとおりです。 > > ファイアウォールの送信側IPアドレス範囲は、データ移行タスクの作成時にのみ利用可能です。このIPアドレス範囲を事前に取得することはできません。開始する前に、以下の点を確認してください。 > -> - ファイアウォールルールを変更する権限が必要です。 -> - セットアッププロセス中に、クラウドプロバイダーのコンソールにアクセスできます。 -> - タスク作成ワークフローを一時停止して、ファイアウォールを設定できます。 +> - ファイアウォールルールを変更する権限が必要です。 +> - セットアッププロセス中に、クラウドプロバイダーのコンソールにアクセスできます。 +> - タスク作成ワークフローを一時停止して、ファイアウォールを設定できます。 -1. ソースとなるMySQLインスタンスのエンドポイントホスト名（FQDN）またはパブリックIPアドレスを特定し、記録します。 +1. ソースとなるMySQLインスタンスのエンドポイントホスト名（FQDN）またはパブリックIPアドレスを特定し、記録します。 -2. データベースのファイアウォールまたはセキュリティグループのルールを変更するには、必要な権限が付与されていることを確認してください。詳細については、クラウドプロバイダーのドキュメントを参照してください。 +2. データベースのファイアウォールまたはセキュリティグループのルールを変更するには、必要な権限が付与されていることを確認してください。詳細については、クラウドプロバイダーのドキュメントを参照してください。 - - Amazon Aurora MySQL または Amazon RDS MySQL: [セキュリティグループによるアクセス制御](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.RDSSecurityGroups.html)。 - - Azure Database for MySQL - フレキシブル サーバー: [公共ネットワークアクセス](https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-networking-public) - - Google Cloud SQL for MySQL: [認証済みネットワーク](https://cloud.google.com/sql/docs/mysql/configure-ip?__hstc=86493575.39bd75fe158e3a694e276e9709c7bc82.1766498597248.1768349165136.1768351956126.50&__hssc=86493575.1.1768351956126&__hsfp=3e9153f1372737b813f3fefb5bbb2ddf#authorized-networks)。 + - Amazon Aurora MySQL または Amazon RDS MySQL: [セキュリティグループによるアクセス制御](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Overview.RDSSecurityGroups.html)。 + - Azure Database for MySQL - フレキシブル サーバー: [公共ネットワークアクセス](https://learn.microsoft.com/en-us/azure/mysql/flexible-server/concepts-networking-public) + - Google Cloud SQL for MySQL: [認証済みネットワーク](https://cloud.google.com/sql/docs/mysql/configure-ip?__hstc=86493575.39bd75fe158e3a694e276e9709c7bc82.1766498597248.1768349165136.1768351956126.50&__hssc=86493575.1.1768351956126&__hsfp=3e9153f1372737b813f3fefb5bbb2ddf#authorized-networks)。 -3. オプション：適切な証明書を使用して転送中の暗号化を行い、パブリックインターネットアクセスを備えたマシンからソースデータベースへの接続を確認します。 +3. オプション：適切な証明書を使用して転送中の暗号化を行い、パブリックインターネットアクセスを備えたマシンからソースデータベースへの接続を確認します。 ```shell mysql -h -P -u -p --ssl-ca= -e "SELECT version();" ``` -4. 後ほど、データ移行ジョブの設定時に、 TiDB Cloud送信元IPアドレス範囲が提供されます。その際、上記と同じ手順に従って、このIPアドレス範囲をデータベースのファイアウォールまたはセキュリティグループのルールに追加する必要があります。 +4. 後ほど、データ移行ジョブの設定時に、 TiDB Cloud送信元IPアドレス範囲が提供されます。その際、上記と同じ手順に従って、このIPアドレス範囲をデータベースのファイアウォールまたはセキュリティグループのルールに追加する必要があります。 #### プライベートリンクまたはプライベートエンドポイント {#private-link-or-private-endpoint} @@ -391,13 +391,13 @@ TiDB Cloud Premiumで利用可能な接続方法は以下のとおりです。 AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサポートしていません。そのため、ネットワークロードバランサー (NLB) を作成し、それをソース MySQL インスタンスに関連付けられたエンドポイントサービスとして公開し、TiDB Cloud の AWS プリンシパルがそのサービスを利用できるように承認する必要があります。 -1. [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)データベースのプライベート IP アドレスを含むターゲット グループに転送する TCP リスナーをポート`3306`で持つ内部 NLB を作成します。以下のキー設定を構成します。 +1. [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)データベースのプライベート IP アドレスを含むターゲット グループに転送する TCP リスナーをポート`3306`で持つ内部 NLB を作成します。以下のキー設定を構成します。 - - **スキーム**:**内部**。ロードバランサーはVPC内に留まります。次のステップのエンドポイントサービスのみが、ロードバランサーをTiDB Cloudに公開します。 - - **VPC** ：RDSまたはAuroraインスタンスと同じVPCを指定します。フォームはデフォルトでアカウントのデフォルトVPCを選択しますが、データベースが配置されている場所は通常このVPCではないため、続行する前に**VPC**のドロップダウンリストを変更してください。 - - **Availability Zones**：**少なくとも2つのアベイラビリティゾーン**でサブネットを選択してください。NLBでは、エンドポイントサービスの可用性を確保するためにマルチAZ構成が必要です。RDSがシングルAZ構成の場合でも、同じVPC内の別のAZに2つ目のサブネットが必要になります。 - - **Listener port**： `3306` 。ウィザードのデフォルト値は`80`です。リスナーを作成する前に変更してください。 - - **Target group**：対象タイプは**IP addresses**、プロトコルは**TCP** 、ポートは**3306** 、データベースと同じVPC内。RDSエンドポイントを直接登録することはできないため、代わりにデータベースのプライベートIPアドレスを登録してください。 + - **スキーム**:**内部**。ロードバランサーはVPC内に留まります。次のステップのエンドポイントサービスのみが、ロードバランサーをTiDB Cloudに公開します。 + - **VPC** ：RDSまたはAuroraインスタンスと同じVPCを指定します。フォームはデフォルトでアカウントのデフォルトVPCを選択しますが、データベースが配置されている場所は通常このVPCではないため、続行する前に**VPC**のドロップダウンリストを変更してください。 + - **Availability Zones**：**少なくとも2つのアベイラビリティゾーン**でサブネットを選択してください。NLBでは、エンドポイントサービスの可用性を確保するためにマルチAZ構成が必要です。RDSがシングルAZ構成の場合でも、同じVPC内の別のAZに2つ目のサブネットが必要になります。 + - **Listener port**： `3306` 。ウィザードのデフォルト値は`80`です。リスナーを作成する前に変更してください。 + - **Target group**：対象タイプは**IP addresses**、プロトコルは**TCP** 、ポートは**3306** 、データベースと同じVPC内。RDSエンドポイントを直接登録することはできないため、代わりにデータベースのプライベートIPアドレスを登録してください。 [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)でデータベースのプライベート IP アドレスを見つけるには、 左側のナビゲーション ペインで**Network Interfaces**をクリックし、 **Description** = `RDSNetworkInterface`と**VPC** = ご使用の VPC でフィルタリングします。一致するネットワーク インターフェイスに表示されている**Primary private IPv4 address**を使用します。 @@ -407,17 +407,17 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ 詳細な手順については、AWS ドキュメントの[ネットワークロードバランサーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)を参照してください。 -2. [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)で、左側のナビゲーションペインの**Endpoint Services**をクリックし、 **Create endpoint service**をクリックします。次の設定を構成します。 +2. [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)で、左側のナビゲーションペインの**Endpoint Services**をクリックし、 **Create endpoint service**をクリックします。次の設定を構成します。 - - **Load balancer type**を**Network**に設定し、前の手順で作成したNLBを選択します。**Available load balancers**リストが空の場合は、NLBが**Active**状態になるまで待ってから、リストの横にある更新アイコンをクリックします。 - - **Acceptance required**：有効（デフォルト）。 - - **Supported IP address types**： **IPv4**を選択してください。 + - **Load balancer type**を**Network**に設定し、前の手順で作成したNLBを選択します。**Available load balancers**リストが空の場合は、NLBが**Active**状態になるまで待ってから、リストの横にある更新アイコンをクリックします。 + - **Acceptance required**：有効（デフォルト）。 + - **Supported IP address types**： **IPv4**を選択してください。 エンドポイントサービスが作成されたら、後で使用するためにサービス名をコピーしてください。サービス名は`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)を参照してください。 -3. TiDB CloudのAWSプリンシパルがエンドポイントサービスを使用できるように承認します。Amazon [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)のエンドポイントサービスの詳細ページで、 **Allow principals**タブを開き、 **Allow principals**をクリックして、次のARNを追加します。 +3. TiDB CloudのAWSプリンシパルがエンドポイントサービスを使用できるように承認します。Amazon [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)のエンドポイントサービスの詳細ページで、 **Allow principals**タブを開き、 **Allow principals**をクリックして、次のARNを追加します。 ```text arn:aws:iam::886436925895:root @@ -427,13 +427,13 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ 詳細な手順については、AWS ドキュメントの[権限を管理する](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html#add-remove-permissions)を参照してください。 -4. オプション：移行を開始する前に、同じVPC内の踏み台サーバーまたはクライアントから接続テストを実施してください。 +4. オプション：移行を開始する前に、同じVPC内の踏み台サーバーまたはクライアントから接続テストを実施してください。 ```shell mysql -h -P 3306 -u -p --ssl-ca= -e "SELECT version();" ``` -5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように設定する際には、AWSコンソールに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。 +5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように設定する際には、AWSコンソールに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。
@@ -443,23 +443,23 @@ Azure Database for MySQL - Flexible Server は、ネイティブのプライベ 新しいプライベートエンドポイントを追加するには、以下の手順を実行してください。 -1. [Azureポータル](https://portal.azure.com/)で、 **Azure Database for MySQL servers**を検索して選択し、インスタンス名をクリックしてから、左側のナビゲーション ペインで**Setting** > **Networking**をクリックします。 +1. [Azureポータル](https://portal.azure.com/)で、 **Azure Database for MySQL servers**を検索して選択し、インスタンス名をクリックしてから、左側のナビゲーション ペインで**Setting** > **Networking**をクリックします。 -2. **Networking**ページで、**Private endpoints**セクションまでスクロールダウンし、 **+ Create private endpoint**をクリックして、画面の指示に従ってプライベートエンドポイントを設定します。 +2. **Networking**ページで、**Private endpoints**セクションまでスクロールダウンし、 **+ Create private endpoint**をクリックして、画面の指示に従ってプライベートエンドポイントを設定します。 セットアップ中に、**Virtual Network**タブでTiDB Cloud がアクセスできる仮想ネットワークとサブネットを選択し、 **DNS**タブで**Private DNS integration**を有効にします。プライベートエンドポイントが作成されてデプロイされたら、 **Go to resource**をクリックし、左側のナビゲーション ペインで**Settings** > **DNS configuration**をクリックして、**Customer Visible FQDNs**セクションでインスタンスへの接続に使用するホスト名を見つけます。通常、ホスト名は`.mysql.database.azure.com`形式です。 詳細な手順については、Azure ドキュメントの[プライベートリンクセンターを使用してプライベートエンドポイントを作成します](https://learn.microsoft.com/en-us/azure/mysql/flexible-server/how-to-networking-private-link-portal#create-a-private-endpoint-via-private-link-center)を参照してください。 -3. オプション：移行を開始する前に、同じVPCまたはVNet内の踏み台サーバーまたはクライアントから接続テストを実施してください。 +3. オプション：移行を開始する前に、同じVPCまたはVNet内の踏み台サーバーまたはクライアントから接続テストを実施してください。 ```shell mysql -h -P 3306 -u -p --ssl-ca= -e "SELECT version();" ``` -4. [Azureポータル](https://portal.azure.com/)の で、MySQL Flexible Server インスタンスの概要ページ (プライベート エンドポイント オブジェクトではありません) に戻り、 **[Essentials]**セクションで**[JSON ビュー]**をクリックして、後で使用するためにリソース ID をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.DBforMySQL/flexibleServers/`形式です。このリソース ID (プライベート エンドポイント ID ではありません) を使用して、 TiDB Cloud DM を構成します。 +4. [Azureポータル](https://portal.azure.com/)の で、MySQL Flexible Server インスタンスの概要ページ (プライベート エンドポイント オブジェクトではありません) に戻り、 **[Essentials]**セクションで**[JSON ビュー]**をクリックして、後で使用するためにリソース ID をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.DBforMySQL/flexibleServers/`形式です。このリソース ID (プライベート エンドポイント ID ではありません) を使用して、 TiDB Cloud DM を構成します。 -5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように構成する際には、Azureポータルに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。 +5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように構成する際には、Azureポータルに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。
@@ -477,13 +477,13 @@ AWS 上でホストされているTiDB Cloud Premium インスタンスの場合 AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサポートしていません。そのため、ネットワークロードバランサー (NLB) を作成し、それをソース MySQL インスタンスに関連付けられたエンドポイントサービスとして公開し、TiDB Cloud の AWS プリンシパルがそのサービスを利用できるように承認する必要があります。 -1. [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)データベースのプライベート IP アドレスを含むターゲット グループに転送する TCP リスナーをポート`3306`で持つ内部 NLB を作成します。以下のキー設定を構成します。 +1. [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)データベースのプライベート IP アドレスを含むターゲット グループに転送する TCP リスナーをポート`3306`で持つ内部 NLB を作成します。以下のキー設定を構成します。 - - **スキーム**:**内部**。ロードバランサーはVPC内に留まります。次のステップのエンドポイントサービスのみが、ロードバランサーをTiDB Cloudに公開します。 - - **VPC** ：RDSまたはAuroraインスタンスと同じVPCを指定します。フォームはデフォルトでアカウントのデフォルトVPCを選択しますが、データベースが配置されている場所は通常このVPCではないため、続行する前に**VPC**のドロップダウンリストを変更してください。 - - **Availability Zones**：**少なくとも2つのアベイラビリティゾーン**でサブネットを選択してください。NLBでは、エンドポイントサービスの可用性を確保するためにマルチAZ構成が必要です。RDSがシングルAZ構成の場合でも、同じVPC内の別のAZに2つ目のサブネットが必要になります。 - - **Listener port**： `3306` 。ウィザードのデフォルト値は`80`です。リスナーを作成する前に変更してください。 - - **Target group**：対象タイプは**IP addresses**、プロトコルは**TCP** 、ポートは**3306** 、データベースと同じVPC内。RDSエンドポイントを直接登録することはできないため、代わりにデータベースのプライベートIPアドレスを登録してください。 + - **スキーム**:**内部**。ロードバランサーはVPC内に留まります。次のステップのエンドポイントサービスのみが、ロードバランサーをTiDB Cloudに公開します。 + - **VPC** ：RDSまたはAuroraインスタンスと同じVPCを指定します。フォームはデフォルトでアカウントのデフォルトVPCを選択しますが、データベースが配置されている場所は通常このVPCではないため、続行する前に**VPC**のドロップダウンリストを変更してください。 + - **Availability Zones**：**少なくとも2つのアベイラビリティゾーン**でサブネットを選択してください。NLBでは、エンドポイントサービスの可用性を確保するためにマルチAZ構成が必要です。RDSがシングルAZ構成の場合でも、同じVPC内の別のAZに2つ目のサブネットが必要になります。 + - **Listener port**： `3306` 。ウィザードのデフォルト値は`80`です。リスナーを作成する前に変更してください。 + - **Target group**：対象タイプは**IP addresses**、プロトコルは**TCP** 、ポートは**3306** 、データベースと同じVPC内。RDSエンドポイントを直接登録することはできないため、代わりにデータベースのプライベートIPアドレスを登録してください。 [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)でデータベースのプライベート IP アドレスを見つけるには、 左側のナビゲーション ペインで**Network Interfaces**をクリックし、 **Description** = `RDSNetworkInterface`と**VPC** = ご使用の VPC でフィルタリングします。一致するネットワーク インターフェイスに表示されている**Primary private IPv4 address**を使用します。 @@ -493,17 +493,17 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ 詳細な手順については、AWS ドキュメントの[ネットワークロードバランサーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)を参照してください。 -2. [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)で、左側のナビゲーションペインの**Endpoint Services**をクリックし、 **Create endpoint service**をクリックします。次の設定を構成します。 +2. [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)で、左側のナビゲーションペインの**Endpoint Services**をクリックし、 **Create endpoint service**をクリックします。次の設定を構成します。 - - **Load balancer type**を**Network**に設定し、前の手順で作成したNLBを選択します。**Available load balancers**リストが空の場合は、NLBが**Active**状態になるまで待ってから、リストの横にある更新アイコンをクリックします。 - - **Acceptance required**：有効（デフォルト）。 - - **Supported IP address types**： **IPv4**を選択してください。 + - **Load balancer type**を**Network**に設定し、前の手順で作成したNLBを選択します。**Available load balancers**リストが空の場合は、NLBが**Active**状態になるまで待ってから、リストの横にある更新アイコンをクリックします。 + - **Acceptance required**：有効（デフォルト）。 + - **Supported IP address types**： **IPv4**を選択してください。 エンドポイントサービスが作成されたら、後で使用するためにサービス名をコピーしてください。サービス名は`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)を参照してください。 -3. TiDB CloudのAWSプリンシパルがエンドポイントサービスを使用できるように承認します。Amazon [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)のエンドポイントサービスの詳細ページで、 **Allow principals**タブを開き、 **Allow principals**をクリックして、次のARNを追加します。 +3. TiDB CloudのAWSプリンシパルがエンドポイントサービスを使用できるように承認します。Amazon [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)のエンドポイントサービスの詳細ページで、 **Allow principals**タブを開き、 **Allow principals**をクリックして、次のARNを追加します。 ```text arn:aws:iam::886436925895:root @@ -513,13 +513,13 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ 詳細な手順については、AWS ドキュメントの[権限を管理する](https://docs.aws.amazon.com/vpc/latest/privatelink/configure-endpoint-service.html#add-remove-permissions)を参照してください。 -4. オプション：移行を開始する前に、同じVPC内の踏み台サーバーまたはクライアントから接続テストを実施してください。 +4. オプション：移行を開始する前に、同じVPC内の踏み台サーバーまたはクライアントから接続テストを実施してください。 ```shell mysql -h -P 3306 -u -p --ssl-ca= -e "SELECT version();" ``` -5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように設定する際には、AWSコンソールに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。 +5. 後ほど、 TiDB Cloud DMをPrivateLink経由で接続するように設定する際には、AWSコンソールに戻り、 TiDB Cloudからこのプライベートエンドポイントへの保留中の接続要求を承認する必要があります。
@@ -527,19 +527,19 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ **Networking**ページからプライベートエンドポイントを作成するには、以下の手順を実行してください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、 TiDB Cloud Premiumインスタンスの概要ページに移動してください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、 TiDB Cloud Premiumインスタンスの概要ページに移動してください。 -2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 -3. **AWS Private Endpoints for External Services**セクションで、 **[Create Private Endpoint for External Services]**をクリックします。 +3. **AWS Private Endpoints for External Services**セクションで、 **[Create Private Endpoint for External Services]**をクリックします。 -4. **Create Private Endpoint for External Services**ダイアログで、プライベートエンドポイントの名前と、MySQLソースデータベース用にAWS PrivateLinkをセットアップした際にコピーした**Endpoint Service Name**を入力します。 +4. **Create Private Endpoint for External Services**ダイアログで、プライベートエンドポイントの名前と、MySQLソースデータベース用にAWS PrivateLinkをセットアップした際にコピーした**Endpoint Service Name**を入力します。 > **Note:** > > **Create**をクリックする前に、上記の「MySQLソースデータベースのAWS PrivateLinkとプライベートエンドポイントの設定」の手順3で説明されているように、AWSのエンドポイントサービスでTiDB CloudのAWSプリンシパル（ `arn:aws:iam::886436925895:root` ）が承認されていることを確認してください。承認されていない場合、このダイアログは**エラーメッセージを表示せ**ずに永久に停止します。 -5. **Create**をクリックします。 +5. **Create**をクリックします。 プライベートエンドポイントが利用可能になったら、データ移行ジョブを作成する際にそれを選択できるようになります。 @@ -555,9 +555,9 @@ AWS VPCピアリングまたはGoogle Cloud VPCネットワークピアリング MySQLサービスがAWS VPC内にある場合は、以下の手順を実行してください。 -1. MySQL サービスの VPC とTiDB Cloud Dedicatedクラスターの間で[VPCピアリング接続を設定する](/tidb-cloud/set-up-vpc-peering-connections.md)。 +1. MySQL サービスの VPC とTiDB Cloud Dedicatedクラスターの間で[VPCピアリング接続を設定する](/tidb-cloud/set-up-vpc-peering-connections.md)。 -2. MySQLサービスが関連付けられているセキュリティグループの受信ルールを変更します。 +2. MySQLサービスが関連付けられているセキュリティグループの受信ルールを変更します。 @@ -571,10 +571,10 @@ MySQLサービスがAWS VPC内にある場合は、以下の手順を実行し -3. MySQLのURLにDNSホスト名が含まれている場合、 TiDB CloudがMySQLサービスのホスト名を解決できるようにする必要があります。 +3. MySQLのURLにDNSホスト名が含まれている場合、 TiDB CloudがMySQLサービスのホスト名を解決できるようにする必要があります。 - 1. [VPCピアリング接続のDNS解決を有効にする](https://docs.aws.amazon.com/vpc/latest/peering/modify-peering-connections.html#vpc-peering-dns)の手順に従います。 - 2. **Accepter DNS resolution**オプションを有効にする。 + 1. [VPCピアリング接続のDNS解決を有効にする](https://docs.aws.amazon.com/vpc/latest/peering/modify-peering-connections.html#vpc-peering-dns)の手順に従います。 + 2. **Accepter DNS resolution**オプションを有効にする。
@@ -582,11 +582,11 @@ 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)。 +2. MySQL サービスの VPC とTiDB Cloud Dedicatedクラスターの間で[VPCピアリング接続を設定する](/tidb-cloud/set-up-vpc-peering-connections.md)。 -3. MySQLが配置されているVPCの受信ファイアウォールルールを変更します。 +3. MySQLが配置されているVPCの受信ファイアウォールルールを変更します。 @@ -658,121 +658,121 @@ GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX, CREATE VIEW ON ## ステップ1：データ移行ページに移動します {#step-1-go-to-the-data-migration-page} -1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 -2. ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンス名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**Data** > **Data Migration**をクリックします。 +2. ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンス名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**Data** > **Data Migration**をクリックします。 -3. **Data Migration**ページで、右上隅にある**Create Migration Job**をクリックします。**Create Migration Job**ページが表示されます。 +3. **Data Migration**ページで、右上隅にある**Create Migration Job**をクリックします。**Create Migration Job**ページが表示されます。 ## ステップ2：ソース接続とターゲット接続を設定する {#step-2-configure-the-source-and-target-connections} **Create Migration Job**ページで、ソースとターゲットの接続を設定します。 -1. 職名を入力してください。職名は文字で始まり、60文字以内である必要があります。文字（AZ、az）、数字（0～9）、アンダースコア（_）、ハイフン（-）が使用可能です。 +1. 職名を入力してください。職名は文字で始まり、60文字以内である必要があります。文字（AZ、az）、数字（0～9）、アンダースコア（_）、ハイフン（-）が使用可能です。 -2. ソース接続プロファイルを入力してください。 +2. ソース接続プロファイルを入力してください。 - - **Data source**：データソースの種類。 + - **Data source**：データソースの種類。 - - **Connectivity method**：セキュリティ要件とクラウドプロバイダーに基づいて、データソースの接続方法を選択してください。 + - **Connectivity method**：セキュリティ要件とクラウドプロバイダーに基づいて、データソースの接続方法を選択してください。 - - **Public IP** ：すべてのクラウドプロバイダーで利用可能（テストおよび概念実証移行に推奨）。 - - **Private Link**：AWSおよびAzureでのみ利用可能（プライベート接続を必要とする本番ワークロードに推奨）。 - - **VPC Peering**：AWSとGoogle Cloudでのみ利用可能です（低遅延でリージョン内接続が必要で、VPC/VNet CIDRが重複しない本番ロードに推奨されます）。 + - **Public IP** ：すべてのクラウドプロバイダーで利用可能（テストおよび概念実証移行に推奨）。 + - **Private Link**：AWSおよびAzureでのみ利用可能（プライベート接続を必要とする本番ワークロードに推奨）。 + - **VPC Peering**：AWSとGoogle Cloudでのみ利用可能です（低遅延でリージョン内接続が必要で、VPC/VNet CIDRが重複しない本番ロードに推奨されます）。 - - **Connectivity method**：セキュリティ要件とクラウドプロバイダーに基づいて、データソースの接続方法を選択してください。 + - **Connectivity method**：セキュリティ要件とクラウドプロバイダーに基づいて、データソースの接続方法を選択してください。 - - **Public**：すべてのクラウドプロバイダーで利用可能（テストおよび概念実証のための移行に推奨）。 - - **Private Link**：AWSおよびAlibaba Cloudでのみ利用可能です（プライベート接続を必要とする本番のワークロードに推奨）。 + - **Public**：すべてのクラウドプロバイダーで利用可能（テストおよび概念実証のための移行に推奨）。 + - **Private Link**：AWSおよびAlibaba Cloudでのみ利用可能です（プライベート接続を必要とする本番のワークロードに推奨）。 - - **Connectivity method**：セキュリティ要件とクラウドプロバイダーに基づいて、データソースの接続方法を選択してください。 + - **Connectivity method**：セキュリティ要件とクラウドプロバイダーに基づいて、データソースの接続方法を選択してください。 - - **Public**： TiDB Cloud Premiumがサポートするすべてのクラウドプロバイダーで利用可能（テストおよび概念実証移行に推奨）。 - - **Private Link**：AWSのみで利用可能（プライベート接続を必要とする本番のワークロードに推奨）。 + - **Public**： TiDB Cloud Premiumがサポートするすべてのクラウドプロバイダーで利用可能（テストおよび概念実証移行に推奨）。 + - **Private Link**：AWSのみで利用可能（プライベート接続を必要とする本番のワークロードに推奨）。 - - 選択した**Connectivity method**に基づいて、以下の手順を実行してください。 + - 選択した**Connectivity method**に基づいて、以下の手順を実行してください。 - - **Public IP**または**VPC Peering**を選択した場合は、**Hostname or IP address**フィールドにデータソースのホスト名またはIPアドレスを入力してください。 - - **Private Link**を選択した場合は、以下の情報を入力してください。 - - **Endpoint Service Name**(**Data source**がAWS の場合に利用可能): RDS または Aurora インスタンス用に作成した VPC エンドAuroraサービス名 (形式: `com.amazonaws.vpce..vpce-svc-` 、例: `com.amazonaws.vpce.us-east-1.vpce-svc-0123456789abcdef0` ) を入力します。 - - **Private Endpoint Resource ID** （**Data source**がAzureの場合に利用可能）：MySQL Flexible ServerインスタンスのリソースIDを入力します（形式： `/subscriptions//resourceGroups//providers/Microsoft.DBforMySQL/flexibleServers/` ）。 + - **Public IP**または**VPC Peering**を選択した場合は、**Hostname or IP address**フィールドにデータソースのホスト名またはIPアドレスを入力してください。 + - **Private Link**を選択した場合は、以下の情報を入力してください。 + - **Endpoint Service Name**(**Data source**がAWS の場合に利用可能): RDS または Aurora インスタンス用に作成した VPC エンドAuroraサービス名 (形式: `com.amazonaws.vpce..vpce-svc-` 、例: `com.amazonaws.vpce.us-east-1.vpce-svc-0123456789abcdef0` ) を入力します。 + - **Private Endpoint Resource ID** （**Data source**がAzureの場合に利用可能）：MySQL Flexible ServerインスタンスのリソースIDを入力します（形式： `/subscriptions//resourceGroups//providers/Microsoft.DBforMySQL/flexibleServers/` ）。 - - 選択した**Connectivity method**に基づいて、以下の手順を実行してください。 + - 選択した**Connectivity method**に基づいて、以下の手順を実行してください。 - - **Public**を選択した場合は、 **Hostname or IP address**フィールドにデータソースのホスト名またはIPアドレスを入力してください。 - - **Private Link**が選択されている場合は、[プライベートリンク[プライベートリンクまたはプライベートエンドポイント](#private-link-or-private-endpoint)セクションで作成したプライベート リンク接続を選択します。 + - **Public**を選択した場合は、 **Hostname or IP address**フィールドにデータソースのホスト名またはIPアドレスを入力してください。 + - **Private Link**が選択されている場合は、[プライベートリンク[プライベートリンクまたはプライベートエンドポイント](#private-link-or-private-endpoint)セクションで作成したプライベート リンク接続を選択します。 - - 選択した**Connectivity method**に基づいて、以下の手順を実行してください。 + - 選択した**Connectivity method**に基づいて、以下の手順を実行してください。 - - **Public**を選択した場合は、 **Hostname or IP address**フィールドにデータソースのホスト名またはIPアドレスを入力してください。 - - **Private Link**が選択されている場合は、 **Private Endpoint**フィールドで既存のプライベート エンドポイントを選択するか、 **[ここでプライベート エンドポイントを作成] をクリックしてプライベート エンドポイント**を作成します。プライベート エンドポイントは、 TiDB Cloud Premium インスタンスの**Networking** > **[AWS 外部サービス用プライベートエンドポイント]**で管理されます。プライベート エンドポイントは、複数のデータ移行ジョブおよび変更フィード間で再利用できます。設定の詳細については、[プライベートリンクまたはプライベートエンドポイント](#private-link-or-private-endpoint)をご覧ください。 + - **Public**を選択した場合は、 **Hostname or IP address**フィールドにデータソースのホスト名またはIPアドレスを入力してください。 + - **Private Link**が選択されている場合は、 **Private Endpoint**フィールドで既存のプライベート エンドポイントを選択するか、 **[ここでプライベート エンドポイントを作成] をクリックしてプライベート エンドポイント**を作成します。プライベート エンドポイントは、 TiDB Cloud Premium インスタンスの**Networking** > **[AWS 外部サービス用プライベートエンドポイント]**で管理されます。プライベート エンドポイントは、複数のデータ移行ジョブおよび変更フィード間で再利用できます。設定の詳細については、[プライベートリンクまたはプライベートエンドポイント](#private-link-or-private-endpoint)をご覧ください。 - - **Port**：データソースのポート番号。 - - **User Name**：データソースのユーザー名。 - - **Password**：ユーザー名のパスワード。 - - **SSL/TLS** ：エンドツーエンドのデータ暗号化のためにSSL/TLSを有効にします（すべての移行作業で強く推奨）。MySQLサーバーのSSL構成に基づいて、適切な証明書をアップロードしてください。 + - **Port**：データソースのポート番号。 + - **User Name**：データソースのユーザー名。 + - **Password**：ユーザー名のパスワード。 + - **SSL/TLS** ：エンドツーエンドのデータ暗号化のためにSSL/TLSを有効にします（すべての移行作業で強く推奨）。MySQLサーバーのSSL構成に基づいて、適切な証明書をアップロードしてください。 SSL/TLS設定オプション： - - オプション1：サーバー認証のみ + - オプション1：サーバー認証のみ - - MySQLサーバーがサーバー認証のみに設定されている場合は、 **CA Certificate**のみをアップロードしてください。 - - このオプションでは、MySQLサーバーが自身の証明書を提示して身元を証明し、 TiDB Cloudが認証局（CA）に対してサーバー証明書を検証します。 - - CA証明書は中間者攻撃から保護し、MySQLサーバーを`require_secure_transport = ON`で起動する場合に必要です。 + - MySQLサーバーがサーバー認証のみに設定されている場合は、 **CA Certificate**のみをアップロードしてください。 + - このオプションでは、MySQLサーバーが自身の証明書を提示して身元を証明し、 TiDB Cloudが認証局（CA）に対してサーバー証明書を検証します。 + - CA証明書は中間者攻撃から保護し、MySQLサーバーを`require_secure_transport = ON`で起動する場合に必要です。 - - オプション2：クライアント証明書認証 + - オプション2：クライアント証明書認証 - - MySQLサーバーがクライアント証明書認証用に構成されている場合は、**Client Certificate**と**Client private key**をアップロードしてください。 - - このオプションでは、 TiDB Cloudは認証のためにMySQLサーバーに証明書を提示しますが、 TiDB Cloudサーバーの証明書を検証しません。 - - このオプションは通常、MySQLサーバーが`REQUIRE SUBJECT '...'`や`REQUIRE ISSUER '...'`などのオプションで構成されているが、 `REQUIRE X509`含まれていない場合に使用され、クライアント証明書の完全な CA 検証を行わずに、クライアント証明書の特定の属性をチェックできるようにします。 - - このオプションは、MySQLサーバーが自己署名証明書またはカスタムPKI環境でクライアント証明書を受け入れる場合によく使用されます。ただし、この構成は中間者攻撃に対して脆弱であるため、他のネットワークレベルの制御によってサーバーの信頼性が保証されない限り、本番環境での本番は推奨されません。 + - MySQLサーバーがクライアント証明書認証用に構成されている場合は、**Client Certificate**と**Client private key**をアップロードしてください。 + - このオプションでは、 TiDB Cloudは認証のためにMySQLサーバーに証明書を提示しますが、 TiDB Cloudサーバーの証明書を検証しません。 + - このオプションは通常、MySQLサーバーが`REQUIRE SUBJECT '...'`や`REQUIRE ISSUER '...'`などのオプションで構成されているが、 `REQUIRE X509`含まれていない場合に使用され、クライアント証明書の完全な CA 検証を行わずに、クライアント証明書の特定の属性をチェックできるようにします。 + - このオプションは、MySQLサーバーが自己署名証明書またはカスタムPKI環境でクライアント証明書を受け入れる場合によく使用されます。ただし、この構成は中間者攻撃に対して脆弱であるため、他のネットワークレベルの制御によってサーバーの信頼性が保証されない限り、本番環境での本番は推奨されません。 - - オプション3：相互TLS（mTLS） - 最高レベルのセキュリティ + - オプション3：相互TLS（mTLS） - 最高レベルのセキュリティ - - MySQLサーバーが相互TLS（mTLS）認証用に構成されている場合は、 **CA Certificate**、**Client Certificate**、および**Client private key**をアップロードしてください。 - - このオプションでは、MySQLサーバーはクライアント証明書を使用してTiDB Cloudの身元を検証し、 TiDB CloudはCA証明書を使用してMySQLサーバーの身元を検証します。 - - このオプションは、MySQLサーバーで移行ユーザーに対して`REQUIRE X509`または`REQUIRE SSL`が設定されている場合に必要です。 - - このオプションは、MySQLサーバーが認証のためにクライアント証明書を必要とする場合に使用されます。 - - 証明書は以下の情報源から入手できます。 - - クラウド プロバイダーからダウンロードします ( [TLS証明書リンク](#end-to-end-encryption-over-tlsssl)を参照)。 - - 組織の内部認証局証明書を使用してください。 - - 自己署名証明書（開発／テスト専用）。 + - MySQLサーバーが相互TLS（mTLS）認証用に構成されている場合は、 **CA Certificate**、**Client Certificate**、および**Client private key**をアップロードしてください。 + - このオプションでは、MySQLサーバーはクライアント証明書を使用してTiDB Cloudの身元を検証し、 TiDB CloudはCA証明書を使用してMySQLサーバーの身元を検証します。 + - このオプションは、MySQLサーバーで移行ユーザーに対して`REQUIRE X509`または`REQUIRE SSL`が設定されている場合に必要です。 + - このオプションは、MySQLサーバーが認証のためにクライアント証明書を必要とする場合に使用されます。 + - 証明書は以下の情報源から入手できます。 + - クラウド プロバイダーからダウンロードします ( [TLS証明書リンク](#end-to-end-encryption-over-tlsssl)を参照)。 + - 組織の内部認証局証明書を使用してください。 + - 自己署名証明書（開発／テスト専用）。 -3. ターゲット接続プロファイルを入力してください。 +3. ターゲット接続プロファイルを入力してください。 - - **User Name**: TiDB Cloud DedicatedクラスターTiDB CloudTiDB Cloud EssentialインスタンスTiDB CloudTiDB Cloud Premiumインスタンスのユーザー名を入力します。 - - **Password**： TiDB Cloudのユーザー名のパスワードを入力してください。 + - **User Name**: TiDB Cloud DedicatedクラスターTiDB CloudTiDB Cloud EssentialインスタンスTiDB CloudTiDB Cloud Premiumインスタンスのユーザー名を入力します。 + - **Password**： TiDB Cloudのユーザー名のパスワードを入力してください。 -4. 入力した情報を検証するには、 **Validate Connection and Next**をクリックしてください。 +4. 入力した情報を検証するには、 **Validate Connection and Next**をクリックしてください。 -5. 表示されたメッセージに従って行動してください。 +5. 表示されたメッセージに従って行動してください。 - - 接続方法として**Public IP**または**VPC Peering**を使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - 接続方法として**Private Link**を使用する場合、エンドポイント要求を承認するよう求められます。 - - AWSの場合： [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**をクリックし、 TiDB Cloudからのエンドポイントリクエストを承認します。 - - Azure の場合: [Azureポータル](https://portal.azure.com)に移動し、MySQL Flexible Server を名前で検索し、左側のナビゲーション ペインで**Setting** > **Networking**をクリックし、右側の**Private endpoint**セクションを見つけて、 TiDB Cloudからの保留中の接続要求を承認します。 + - 接続方法として**Public IP**または**VPC Peering**を使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 + - 接続方法として**Private Link**を使用する場合、エンドポイント要求を承認するよう求められます。 + - AWSの場合： [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**をクリックし、 TiDB Cloudからのエンドポイントリクエストを承認します。 + - Azure の場合: [Azureポータル](https://portal.azure.com)に移動し、MySQL Flexible Server を名前で検索し、左側のナビゲーション ペインで**Setting** > **Networking**をクリックし、右側の**Private endpoint**セクションを見つけて、 TiDB Cloudからの保留中の接続要求を承認します。 @@ -782,8 +782,8 @@ GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX, CREATE VIEW ON - - 接続方法として**パブリックを**使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)でエンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**を選択し、 TiDB Cloudからのエンドポイント接続要求を承認してください。 + - 接続方法として**パブリックを**使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 + - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)でエンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**を選択し、 TiDB Cloudからのエンドポイント接続要求を承認してください。 @@ -815,14 +815,14 @@ TiDB Cloudへのデータ移行を一度で完了させるには、 **Existing d **既存データ**と**増分データ**の移行には、**physical mode**または**logical mode**を使用できます。 -- デフォルトモードは**logical mode**です。このモードでは、MySQLソースデータベースからSQLステートメントとしてデータをエクスポートし、TiDB上で実行します。このモードでは、移行前のターゲットテーブルは空でも空でなくても構いません。ただし、物理モードよりもパフォーマンスは低下します。 +- デフォルトモードは**logical mode**です。このモードでは、MySQLソースデータベースからSQLステートメントとしてデータをエクスポートし、TiDB上で実行します。このモードでは、移行前のターゲットテーブルは空でも空でなくても構いません。ただし、物理モードよりもパフォーマンスは低下します。 -- 大規模なデータセットの場合は、**physical mode**の使用をお勧めします。このモードでは、MySQLソースデータベースからデータをエクスポートし、KVペアとしてエンコードしてTiKVに直接書き込むことで、パフォーマンスを向上させます。このモードでは、移行前にターゲットテーブルが空である必要があります。16 RCU（レプリケーション容量ユニット）の仕様の場合、パフォーマンスは論理モードの約2.5倍高速です。その他の仕様では、論理モードと比較してパフォーマンスが20%～50%向上する可能性があります。なお、パフォーマンスデータは参考値であり、シナリオによって異なる場合がありますのでご注意ください。 +- 大規模なデータセットの場合は、**physical mode**の使用をお勧めします。このモードでは、MySQLソースデータベースからデータをエクスポートし、KVペアとしてエンコードしてTiKVに直接書き込むことで、パフォーマンスを向上させます。このモードでは、移行前にターゲットテーブルが空である必要があります。16 RCU（レプリケーション容量ユニット）の仕様の場合、パフォーマンスは論理モードの約2.5倍高速です。その他の仕様では、論理モードと比較してパフォーマンスが20%～50%向上する可能性があります。なお、パフォーマンスデータは参考値であり、シナリオによって異なる場合がありますのでご注意ください。 > **Note:** > -> - 物理モードを使用する場合、既存のデータ移行が完了する前に、 TiDB Cloud Dedicatedクラスタに対して2つ目の移行ジョブまたはインポートタスクを作成することはできません。 -> - 物理モードを使用し、移行ジョブが開始されたら、 TiDB Cloud Dedicatedクラスターで PITR (ポイントインタイムリカバリ) を有効にしたり、変更フィードを設定したり**しないで**ください。そうしないと、移行ジョブが停止します。PITR を有効にしたり、変更フィードを設定したりする必要がある場合は、代わりに論理モードを使用してデータを移行してください。 +> - 物理モードを使用する場合、既存のデータ移行が完了する前に、 TiDB Cloud Dedicatedクラスタに対して2つ目の移行ジョブまたはインポートタスクを作成することはできません。 +> - 物理モードを使用し、移行ジョブが開始されたら、 TiDB Cloud Dedicatedクラスターで PITR (ポイントインタイムリカバリ) を有効にしたり、変更フィードを設定したり**しないで**ください。そうしないと、移行ジョブが停止します。PITR を有効にしたり、変更フィードを設定したりする必要がある場合は、代わりに論理モードを使用してデータを移行してください。 物理モードでは、MySQLソースデータを可能な限り高速にエクスポートするため、 [異なる仕様](/tidb-cloud/tidb-cloud-billing-dm.md#specifications-for-data-migration)データエクスポート時のMySQLソースデータベースのQPSとTPSに対するパフォーマンスへの影響が異なります。以下の表は、各仕様のパフォーマンス低下を示しています。 @@ -848,14 +848,14 @@ TiDB Cloud Premiumへのデータ移行を一度で完了させるには、 **Fu **既存データの移行**には、**physical mode**または**logical mode**のいずれかを使用できます。 -- デフォルトモードは**logical mode**です。このモードでは、MySQLソースデータベースからSQLステートメントとしてデータをエクスポートし、ターゲットのTiDB Cloud Premiumインスタンス上で実行します。このモードでは、移行前にターゲットテーブルが空でも空でなくても構いませんが、物理モードよりもパフォーマンスが低下します。 +- デフォルトモードは**logical mode**です。このモードでは、MySQLソースデータベースからSQLステートメントとしてデータをエクスポートし、ターゲットのTiDB Cloud Premiumインスタンス上で実行します。このモードでは、移行前にターゲットテーブルが空でも空でなくても構いませんが、物理モードよりもパフォーマンスが低下します。 -- 大規模なデータセットの場合は、**physical mode**を選択できます。このモードでは、ターゲットのTiDB Cloud Premium インスタンスで`IMPORT INTO`を使用してロードを高速化します。物理モードでは、移行前にターゲットテーブルが空である必要があります。事前チェックで選択したターゲットテーブルが空でないことが検出された場合、移行ジョブは自動的に論理モードに切り替わります。 +- 大規模なデータセットの場合は、**physical mode**を選択できます。このモードでは、ターゲットのTiDB Cloud Premium インスタンスで`IMPORT INTO`を使用してロードを高速化します。物理モードでは、移行前にターゲットテーブルが空である必要があります。事前チェックで選択したターゲットテーブルが空でないことが検出された場合、移行ジョブは自動的に論理モードに切り替わります。 > **Note:** > -> - 物理モードを使用する場合、既存のデータ移行が完了する前に、 TiDB Cloud Premiumインスタンスに対して2つ目の移行ジョブまたはインポートタスクを作成することはできません。 -> - 物理モードを使用し、移行ジョブが開始されたら、 TiDB Cloud PremiumインスタンスでPITR（ポイントインタイムリカバリ）を有効にしたり、変更フィードを設定したり**しないで**ください。そうしないと、移行ジョブが停止します。PITRを有効にしたり、変更フィードを設定したりする必要がある場合は、代わりに論理モードを使用してデータを移行してください。 +> - 物理モードを使用する場合、既存のデータ移行が完了する前に、 TiDB Cloud Premiumインスタンスに対して2つ目の移行ジョブまたはインポートタスクを作成することはできません。 +> - 物理モードを使用し、移行ジョブが開始されたら、 TiDB Cloud PremiumインスタンスでPITR（ポイントインタイムリカバリ）を有効にしたり、変更フィードを設定したり**しないで**ください。そうしないと、移行ジョブが停止します。PITRを有効にしたり、変更フィードを設定したりする必要がある場合は、代わりに論理モードを使用してデータを移行してください。 @@ -877,13 +877,13 @@ TiDB Cloud Premiumへのデータ移行を一度で完了させるには、 **Fu ## ステップ4：移行するオブジェクトを選択する {#step-4-choose-the-objects-to-be-migrated} -1. **Choose Objects to Migrate**ページで、移行するオブジェクトを選択します。 **All**をクリックするとすべてのオブジェクトを選択できます。 **Customize**をクリックしてから、オブジェクト名の横にあるチェックボックスをクリックしてオブジェクトを選択することもできます。 +1. **Choose Objects to Migrate**ページで、移行するオブジェクトを選択します。 **All**をクリックするとすべてのオブジェクトを選択できます。 **Customize**をクリックしてから、オブジェクト名の横にあるチェックボックスをクリックしてオブジェクトを選択することもできます。 - - **All**をクリックすると、移行ジョブはソースデータベースインスタンス全体から既存のデータをTiDB Cloudに移行し、完全移行後に進行中の変更も移行します。ただし、これは前の手順で**Existing data migration**と**Incremental data migration**のチェックボックスを選択した場合にのみ実行されます。 - - **Customize**をクリックしてデータベースを選択すると、移行ジョブによって既存のデータと選択したデータベースの進行中の変更がTiDB Cloudに移行されます。ただし、これは前の手順で**Existing data migration**と**Incremental data migration**のチェックボックスを選択した場合にのみ実行されます。 - - **Customize**をクリックしてデータベース名の下のテーブルを選択すると、移行ジョブは既存のデータと選択したテーブルの進行中の変更のみを移行します。同じデータベースで後から作成されたテーブルは移行されません。 + - **All**をクリックすると、移行ジョブはソースデータベースインスタンス全体から既存のデータをTiDB Cloudに移行し、完全移行後に進行中の変更も移行します。ただし、これは前の手順で**Existing data migration**と**Incremental data migration**のチェックボックスを選択した場合にのみ実行されます。 + - **Customize**をクリックしてデータベースを選択すると、移行ジョブによって既存のデータと選択したデータベースの進行中の変更がTiDB Cloudに移行されます。ただし、これは前の手順で**Existing data migration**と**Incremental data migration**のチェックボックスを選択した場合にのみ実行されます。 + - **Customize**をクリックしてデータベース名の下のテーブルを選択すると、移行ジョブは既存のデータと選択したテーブルの進行中の変更のみを移行します。同じデータベースで後から作成されたテーブルは移行されません。 -2. **Next**をクリックしてください。 +2. **Next**をクリックしてください。 ## ステップ5：事前チェック {#step-5-precheck} @@ -957,24 +957,24 @@ TiDB Cloud Dedicatedは、さまざまなシナリオにおけるパフォーマ 移行ジョブの仕様を拡張する際には、以下の点に注意してください。 -- 移行ジョブの仕様を拡張するには、約5～10分かかります。 -- スケーリングが失敗した場合、ジョブの仕様はスケーリング前と同じままになります。 +- 移行ジョブの仕様を拡張するには、約5～10分かかります。 +- スケーリングが失敗した場合、ジョブの仕様はスケーリング前と同じままになります。 ### 制限事項 {#limitations-1} -- 移行ジョブの仕様をスケーリングできるのは、ジョブが**Running**または**Paused**の状態にある場合のみです。 -- TiDB Cloudは、既存のデータエクスポート段階における移行ジョブ仕様のスケーリングをサポートしていません。 -- 移行ジョブの仕様を拡張すると、ジョブが再起動されます。ジョブのソーステーブルに主キーがない場合、重複データが挿入される可能性があります。 -- スケーリング中は、ソースデータベースのバイナリログをパージしたり、MySQLソースデータベースの`expire_logs_days`を一時的に増やしたりしないでください。そうしないと、連続したバイナリログの位置を取得できず、ジョブが失敗する可能性があります。 +- 移行ジョブの仕様をスケーリングできるのは、ジョブが**Running**または**Paused**の状態にある場合のみです。 +- TiDB Cloudは、既存のデータエクスポート段階における移行ジョブ仕様のスケーリングをサポートしていません。 +- 移行ジョブの仕様を拡張すると、ジョブが再起動されます。ジョブのソーステーブルに主キーがない場合、重複データが挿入される可能性があります。 +- スケーリング中は、ソースデータベースのバイナリログをパージしたり、MySQLソースデータベースの`expire_logs_days`を一時的に増やしたりしないでください。そうしないと、連続したバイナリログの位置を取得できず、ジョブが失敗する可能性があります。 ### スケーリング手順 {#scaling-procedure} -1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 -2. 対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Data Migration**をクリックします。 +2. 対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Data Migration**をクリックします。 -3. **Data Migration**ページで、スケールアップする移行ジョブを探します。**Action**列で、 **[...]** > **Scale Up/Down**をクリックします。 +3. **Data Migration**ページで、スケールアップする移行ジョブを探します。**Action**列で、 **[...]** > **Scale Up/Down**をクリックします。 -4. **Scale Up/Down**ウィンドウで、使用する新しい仕様を選択し、 **Submit**をクリックします。ウィンドウの下部に、その仕様の新しい価格が表示されます。 +4. **Scale Up/Down**ウィンドウで、使用する新しい仕様を選択し、 **Submit**をクリックします。ウィンドウの下部に、その仕様の新しい価格が表示されます。 diff --git a/tidb-cloud/migrate-from-op-tidb.md b/tidb-cloud/migrate-from-op-tidb.md index 7df3e91af33d5..488b25ecef4c7 100644 --- a/tidb-cloud/migrate-from-op-tidb.md +++ b/tidb-cloud/migrate-from-op-tidb.md @@ -9,12 +9,12 @@ summary: TiDB Self-ManagedからTiDB Cloudへのデータ移行方法を学び 全体の手順は以下のとおりです。 -1. 環境を構築し、ツールを準備する。 -2. 全データを移行します。手順は以下のとおりです。 - 1. Dumplingを使用して、TiDB Self-ManagedからAmazon S3にデータをエクスポートします。 - 2. Amazon S3 からTiDB Cloudへデータをインポートします。 -3. TiCDCを使用して増分データを複製します。 -4. 移行されたデータを確認してください。 +1. 環境を構築し、ツールを準備する。 +2. 全データを移行します。手順は以下のとおりです。 + 1. Dumplingを使用して、TiDB Self-ManagedからAmazon S3にデータをエクスポートします。 + 2. Amazon S3 からTiDB Cloudへデータをインポートします。 +3. TiCDCを使用して増分データを複製します。 +4. 移行されたデータを確認してください。 ## 前提条件 {#prerequisites} @@ -22,16 +22,16 @@ S3バケットとTiDB Cloudリソースは同じリージョンに配置する 移行前に、以下のものを準備する必要があります。 -- 管理者アクセス権を持つ[AWSアカウント](https://docs.aws.amazon.com/AmazonS3/latest/userguide/setting-up-s3.html#sign-up-for-aws-gsg) -- [AWS S3バケット](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-bucket.html) -- [TiDB Cloudアカウント](/tidb-cloud/tidb-cloud-quickstart.md)には、AWSでホストされている対象のTiDB Cloudリソースへの[`Project Data Access Read-Write`](/tidb-cloud/manage-user-access.md#user-roles)アクセス権が少なくとも必要です。 +- 管理者アクセス権を持つ[AWSアカウント](https://docs.aws.amazon.com/AmazonS3/latest/userguide/setting-up-s3.html#sign-up-for-aws-gsg) +- [AWS S3バケット](https://docs.aws.amazon.com/AmazonS3/latest/userguide/creating-bucket.html) +- [TiDB Cloudアカウント](/tidb-cloud/tidb-cloud-quickstart.md)には、AWSでホストされている対象のTiDB Cloudリソースへの[`Project Data Access Read-Write`](/tidb-cloud/manage-user-access.md#user-roles)アクセス権が少なくとも必要です。 ## ツールを準備する {#prepare-tools} 以下のツールを準備する必要があります。 -- Dumpling：データエクスポートツール -- TiCDC：データ複製ツール +- Dumpling：データエクスポートツール +- TiCDC：データ複製ツール ### Dumpling {#dumpling} @@ -39,8 +39,8 @@ S3バケットとTiDB Cloudリソースは同じリージョンに配置する Dumpling をデプロイする前に、以下の点にご注意ください。 -- TiDB Cloudリソースと同じVPC内の新しいEC2インスタンスにDumplingをデプロイすることをお勧めします。 -- 推奨されるEC2インスタンスタイプは**c6g.4xlarge** （16 vCPU、32 GiBメモリ）です。必要に応じて他のEC2インスタンスタイプを選択することもできます。Amazonマシンイメージ（AMI）は、Amazon Linux、Ubuntu、またはRed Hatから選択可能です。 +- TiDB Cloudリソースと同じVPC内の新しいEC2インスタンスにDumplingをデプロイすることをお勧めします。 +- 推奨されるEC2インスタンスタイプは**c6g.4xlarge** （16 vCPU、32 GiBメモリ）です。必要に応じて他のEC2インスタンスタイプを選択することもできます。Amazonマシンイメージ（AMI）は、Amazon Linux、Ubuntu、またはRed Hatから選択可能です。 TiUPを使用するか、インストールパッケージを使用することで、 Dumplingをデプロイできます。 @@ -61,27 +61,27 @@ tiup update --self && tiup update dumpling インストールパッケージを使用してDumplingをデプロイするには： -1. [ツールキットパッケージ](https://docs.pingcap.com/tidb/stable/download-ecosystem-tools)をダウンロードします。 +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} 上流データベースからデータをエクスポートするには、以下の権限が必要です。 -- 選択 -- リロード -- ロックテーブル -- レプリケーションクライアント -- プロセス +- 選択 +- リロード +- ロックテーブル +- レプリケーションクライアント +- プロセス ### TiCDCをデプロイ {#deploy-ticdc} アップストリームの 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: @@ -93,7 +93,7 @@ tiup update --self && tiup update dumpling data_dir: /tidb-data/cdc-8300 ``` -3. TiCDCコンポーネントを追加し、ステータスを確認してください。 +3. TiCDCコンポーネントを追加し、ステータスを確認してください。 ```shell tiup cluster scale-out scale-out.yml @@ -104,8 +104,8 @@ tiup update --self && tiup update dumpling TiDB Self-ManagedクラスタからTiDB Cloudへデータを移行するには、以下の手順で完全なデータ移行を実行します。 -1. TiDB Self-ManagedクラスターからAmazon S3へデータを移行します。 -2. Amazon S3からTiDB Cloudへデータを移行します。 +1. TiDB Self-ManagedクラスターからAmazon S3へデータを移行します。 +2. Amazon S3からTiDB Cloudへデータを移行します。 ### TiDB Self-ManagedクラスターからAmazon S3へデータを移行する {#migrate-data-from-the-tidb-self-managed-cluster-to-amazon-s3} @@ -139,11 +139,11 @@ SELECT @@global.tidb_gc_enable; 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)にサインインしてください。 +1. AWSアカウントIDまたはアカウントエイリアス、 IAMユーザー名、およびパスワードを使用して[IAMコンソール](https://console.aws.amazon.com/iam/home#/security_credentials)にサインインしてください。 -2. 右上にあるナビゲーションバーでユーザー名を選択し、 **My Security Credentials**をクリックします。 +2. 右上にあるナビゲーションバーでユーザー名を選択し、 **My Security Credentials**をクリックします。 -3. アクセスキーを作成するには、 **Create access key**をクリックします。次に、 **Download .csv file**を選択して、アクセスキー ID とシークレット アクセスキーをコンピュータの CSV ファイルに保存します。このファイルは安全な場所に保存してください。このダイアログボックスを閉じると、シークレット アクセスキーには再度アクセスできなくなります。CSV ファイルをダウンロードしたら、 **Close**を選択します。アクセスキーを作成すると、キー ペアはデフォルトで有効になり、すぐに使用できます。 +3. アクセスキーを作成するには、 **Create access key**をクリックします。次に、 **Download .csv file**を選択して、アクセスキー ID とシークレット アクセスキーをコンピュータの CSV ファイルに保存します。このファイルは安全な場所に保存してください。このダイアログボックスを閉じると、シークレット アクセスキーには再度アクセスできなくなります。CSV ファイルをダウンロードしたら、 **Close**を選択します。アクセスキーを作成すると、キー ペアはデフォルトで有効になり、すぐに使用できます。 ![Create access key](/media/tidb-cloud/op-to-cloud-create-access-key01.png) @@ -153,14 +153,14 @@ AWS コンソールでアクセスキーを作成します。詳細について Dumplingを使用して、アップストリームのTiDBクラスタからAmazon S3にデータをエクスポートするには、次の手順を実行します。 -1. Dumplingの環境変数を設定します。 +1. Dumplingの環境変数を設定します。 ```shell export AWS_ACCESS_KEY_ID=${AccessKey} 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情報を取得する方法を示しています。 @@ -170,7 +170,7 @@ Dumplingを使用して、アップストリームのTiDBクラスタからAmazo ![Get the region information](/media/tidb-cloud/op-to-cloud-copy-region-info.png) -3. Dumplingを実行して、データをAmazon S3バケットにエクスポートします。 +3. Dumplingを実行して、データをAmazon S3バケットにエクスポートします。 ```shell dumpling \ @@ -189,35 +189,35 @@ Dumplingを使用して、アップストリームのTiDBクラスタからAmazo 詳細については、 [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview#export-to-sql-files)を参照してください。 -4. エクスポートデータを確認してください。通常、エクスポートデータには以下の内容が含まれます。 +4. エクスポートデータを確認してください。通常、エクスポートデータには以下の内容が含まれます。 - - `metadata` : このファイルには、エクスポートの開始時刻とマスターバイナリログの場所が含まれています。 - - `{schema}-schema-create.sql` : スキーマを作成するための SQL ファイル - - `{schema}.{table}-schema.sql` : テーブルを作成するための SQL ファイル - - `{schema}.{table}.{0001}.{sql|csv}` : データファイル - - `*-schema-view.sql` 、 `*-schema-trigger.sql` 、 `*-schema-post.sql` ：その他のエクスポートされたSQLファイル + - `metadata` : このファイルには、エクスポートの開始時刻とマスターバイナリログの場所が含まれています。 + - `{schema}-schema-create.sql` : スキーマを作成するための SQL ファイル + - `{schema}.{table}-schema.sql` : テーブルを作成するための SQL ファイル + - `{schema}.{table}.{0001}.{sql|csv}` : データファイル + - `*-schema-view.sql` 、 `*-schema-trigger.sql` 、 `*-schema-post.sql` ：その他のエクスポートされたSQLファイル ### Amazon S3からTiDB Cloudへデータを移行する {#migrate-data-from-amazon-s3-to-tidb-cloud} TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポートした後、データをTiDB Cloudに移行する必要があります。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/)以下のドキュメントに従って、対象のTiDBリソースのアカウントIDと外部IDを取得してください。 +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 のアクセス権限を設定します。通常、以下の読み取り専用権限が必要です。 +2. Amazon S3 のアクセス権限を設定します。通常、以下の読み取り専用権限が必要です。 - - s3:GetObject - - s3:GetObjectVersion - - s3:リストバケット - - s3:GetBucketLocation + - s3:GetObject + - s3:GetObjectVersion + - s3:リストバケット + - s3:GetBucketLocation S3バケットがサーバー側暗号化（SSE-KMS）を使用している場合は、KMS権限も追加する必要があります。 - - kms:復号化 + - kms:復号化 -3. アクセスポリシーを設定します。 [AWSコンソール > IAM > アクセス管理 > ポリシー](https://console.aws.amazon.com/iamv2/home#/policies)してリージョンに切り替えて、 TiDB Cloudのアクセス ポリシーが既に存在するかどうかを確認します。存在しない場合は、このドキュメントに従ってポリシーを作成します。 [JSONタブでポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)。 +3. アクセスポリシーを設定します。 [AWSコンソール > IAM > アクセス管理 > ポリシー](https://console.aws.amazon.com/iamv2/home#/policies)してリージョンに切り替えて、 TiDB Cloudのアクセス ポリシーが既に存在するかどうかを確認します。存在しない場合は、このドキュメントに従ってポリシーを作成します。 [JSONタブでポリシーを作成する](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)。 以下は、JSONポリシーのテンプレート例です。 @@ -264,40 +264,40 @@ 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にインポートするときに使用します。 +5. ロール ARN を取得します。 [AWSコンソール > IAM > アクセス管理 > ロール](https://console.aws.amazon.com/iamv2/home#/roles)。お住まいの地域に切り替えてください。作成したロールをクリックし、ARN をメモします。これは、データをTiDB Cloudにインポートするときに使用します。 -6. TiDB Cloudにデータをインポートします。 +6. TiDB Cloudにデータをインポートします。 - - TiDB Cloud Dedicatedクラスターについては、[クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)。 - - TiDB Cloud StarterまたはTiDB Cloud 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 StarterまたはTiDB Cloud Essentialインスタンスについては、 [TiDB Cloud StarterまたはEssentialにクラウドストレージからCSVファイルをインポートする](/tidb-cloud/import-csv-files-serverless.md)。 ## 増分データを複製する {#replicate-incremental-data} 増分データを複製するには、次の手順を実行します。 -1. 増分データ移行の開始時刻を取得します。例えば、完全データ移行のメタデータファイルから取得できます。 +1. 増分データ移行の開始時刻を取得します。例えば、完全データ移行のメタデータファイルから取得できます。 ![Start Time in Metadata](/media/tidb-cloud/start_ts_in_metadata.png) -2. TiCDCがTiDB Cloudに接続できるようにします。 +2. TiCDCがTiDB Cloudに接続できるようにします。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲット リソースの名前をクリックして、その概要ページに移動します。 - 2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 - 3. TiDB Cloudのプランに応じて、TiCDCがTiDB Cloudに接続できるようにするために、以下のいずれかの操作を行ってください。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲット リソースの名前をクリックして、その概要ページに移動します。 + 2. 左側のナビゲーションペインで、 **Settings** > **Networking**をクリックします。 + 3. TiDB Cloudのプランに応じて、TiCDCがTiDB Cloudに接続できるようにするために、以下のいずれかの操作を行ってください。 - - TiDB Cloud StarterまたはEssentialの場合は、 **Authorized Networks**セクションで**Add rule**をクリックします。表示されたダイアログで、TiCDCコンポーネントのパブリック IP アドレスを使用するファイアウォール ルールを追加し、 **Save**をクリックします。詳細については、 [パブリックエンドポイント向けにTiDB Cloud StarterまたはEssential Firewallルールを設定する](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md#create-and-manage-a-firewall-rule)を参照してください。 - - TiDB Cloud Dedicatedの場合は、 **Add IP Address**をクリックします。表示されたダイアログで、 **Use IP addresses**を選択し、 **+**をクリックし、TiCDCコンポーネントのパブリック IP アドレスを**IP Address**フィールドに入力して、 **Confirm**をクリックします。詳細については、 [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)を参照してください。 + - TiDB Cloud StarterまたはEssentialの場合は、 **Authorized Networks**セクションで**Add rule**をクリックします。表示されたダイアログで、TiCDCコンポーネントのパブリック IP アドレスを使用するファイアウォール ルールを追加し、 **Save**をクリックします。詳細については、 [パブリックエンドポイント向けにTiDB Cloud StarterまたはEssential Firewallルールを設定する](/tidb-cloud/configure-serverless-firewall-rules-for-public-endpoints.md#create-and-manage-a-firewall-rule)を参照してください。 + - TiDB Cloud Dedicatedの場合は、 **Add IP Address**をクリックします。表示されたダイアログで、 **Use IP addresses**を選択し、 **+**をクリックし、TiCDCコンポーネントのパブリック IP アドレスを**IP Address**フィールドに入力して、 **Confirm**をクリックします。詳細については、 [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)を参照してください。 -3. 下流のTiDB Cloudリソースの接続情報を取得します。 +3. 下流のTiDB Cloudリソースの接続情報を取得します。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloudリソースの名前をクリックして、その概要ページに移動します。 - 2. 右上隅の**Connect**をクリックしてください。 - 3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **Connect With**ドロップダウンリストから**General**を選択します。 - 4. 接続情報から、 TiDB Cloudリソースのホスト IP アドレスとポートを取得できます。詳細については、 [公共回線経由で接続する](/tidb-cloud/connect-via-standard-connection.md)を参照してください。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloudリソースの名前をクリックして、その概要ページに移動します。 + 2. 右上隅の**Connect**をクリックしてください。 + 3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Public**を選択し、 **Connect With**ドロップダウンリストから**General**を選択します。 + 4. 接続情報から、 TiDB Cloudリソースのホスト IP アドレスとポートを取得できます。詳細については、 [公共回線経由で接続する](/tidb-cloud/connect-via-standard-connection.md)を参照してください。 -4. 増分レプリケーションタスクを作成して実行します。アップストリームクラスターで、以下を実行します。 +4. 増分レプリケーションタスクを作成して実行します。アップストリームクラスターで、以下を実行します。 ```shell tiup cdc cli changefeed create \ @@ -307,21 +307,21 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート --start-ts="431434047157698561" ``` - - `--pd` : アップストリームクラスタのPDアドレス。形式は`[upstream_pd_ip]:[pd_port]`です。 + - `--pd` : アップストリームクラスタのPDアドレス。形式は`[upstream_pd_ip]:[pd_port]`です。 - - `--sink-uri` : レプリケーション タスクのダウンストリーム アドレス。 `--sink-uri`は、次の形式に従って構成します。現在、このスキームは`mysql` 、 `tidb` 、 `kafka` 、 `s3` 、および`local` 。 + - `--sink-uri` : レプリケーション タスクのダウンストリーム アドレス。 `--sink-uri`は、次の形式に従って構成します。現在、このスキームは`mysql` 、 `tidb` 、 `kafka` 、 `s3` 、および`local` 。 ```shell [scheme]://[userinfo@][host]:[port][/path]?[query_parameters] ``` - - `--changefeed-id` : レプリケーションタスクのID。形式は、^[a-zA-Z0-9]+(-[a-zA-Z0-9]+)*$ の正規表現に一致する必要があります。このIDが指定されていない場合、TiCDCは自動的にUUID（バージョン4形式）をIDとして生成します。 + - `--changefeed-id` : レプリケーションタスクのID。形式は、^[a-zA-Z0-9]+(-[a-zA-Z0-9]+)*$ の正規表現に一致する必要があります。このIDが指定されていない場合、TiCDCは自動的にUUID（バージョン4形式）をIDとして生成します。 - - `--start-ts` : 変更フィードの開始TSOを指定します。TiCDCクラスタはこのTSOからデータの取得を開始します。デフォルト値は現在時刻です。 + - `--start-ts` : 変更フィードの開始TSOを指定します。TiCDCクラスタはこのTSOからデータの取得を開始します。デフォルト値は現在時刻です。 詳細については、 [TiCDC ChangefeedsのCLIとコンフィグレーションパラメータ](https://docs.pingcap.com/tidb/dev/ticdc-changefeed-config)を参照してください。 -5. アップストリームクラスタでGCメカニズムを再度有効にします。増分レプリケーションでエラーや遅延が検出されない場合は、GCメカニズムを有効にして、アップストリームクラスタのガベージコレクションを再開します。 +5. アップストリームクラスタでGCメカニズムを再度有効にします。増分レプリケーションでエラーや遅延が検出されない場合は、GCメカニズムを有効にして、アップストリームクラスタのガベージコレクションを再開します。 設定が正しく機能しているかどうかを確認するには、以下のコマンドを実行してください。 @@ -341,11 +341,11 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート 1 row in set (0.01 sec) ``` -6. 増分レプリケーションタスクを確認します。 +6. 増分レプリケーションタスクを確認します。 - - 出力に「変更フィードの作成に成功しました！」というメッセージが表示された場合、レプリケーションタスクは正常に作成されています。 + - 出力に「変更フィードの作成に成功しました！」というメッセージが表示された場合、レプリケーションタスクは正常に作成されています。 - - 状態が`normal`の場合、レプリケーションタスクは正常です。 + - 状態が`normal`の場合、レプリケーションタスクは正常です。 ```shell tiup cdc cli changefeed list --pd=http://172.16.6.122:2379 @@ -353,29 +353,29 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート ![Update Filter](/media/tidb-cloud/normal_status_in_replication_task.png) - - レプリケーションを確認します。アップストリームクラスタに新しいレコードを書き込み、そのレコードがダウンストリームのTiDB Cloudリソースにレプリケートされているかどうかを確認します。 + - レプリケーションを確認します。アップストリームクラスタに新しいレコードを書き込み、そのレコードがダウンストリームのTiDB Cloudリソースにレプリケートされているかどうかを確認します。 -7. アップストリームとダウンストリームで同じタイムゾーンを設定してください。デフォルトでは、 TiDB CloudはタイムゾーンをUTCに設定します。アップストリームとダウンストリームでタイムゾーンが異なる場合は、両方で同じタイムゾーンを設定する必要があります。 +7. アップストリームとダウンストリームで同じタイムゾーンを設定してください。デフォルトでは、 TiDB CloudはタイムゾーンをUTCに設定します。アップストリームとダウンストリームでタイムゾーンが異なる場合は、両方で同じタイムゾーンを設定する必要があります。 - 1. 上流の TiDB Self-Managed クラスタで、次のコマンドを実行してタイムゾーンを確認します。 + 1. 上流の TiDB Self-Managed クラスタで、次のコマンドを実行してタイムゾーンを確認します。 ```sql SELECT @@global.time_zone; ``` - 2. ダウンストリームのTiDB Cloudリソースで、次のコマンドを実行してタイムゾーンを設定します。 + 2. ダウンストリームのTiDB Cloudリソースで、次のコマンドを実行してタイムゾーンを設定します。 ```sql SET GLOBAL time_zone = '+08:00'; ``` - 3. 設定を確認するために、タイムゾーンを再度確認してください。 + 3. 設定を確認するために、タイムゾーンを再度確認してください。 ```sql SELECT @@global.time_zone; ``` -8. アップストリームの TiDB Self-Managed クラスターでクエリバインディングをバックアップし、ダウンストリームのTiDB Cloudリソースに復元します。クエリバインディングをバックアップするには、[クエリバインディング](/sql-plan-management.md)の次のクエリを使用できます。 +8. アップストリームの TiDB Self-Managed クラスターでクエリバインディングをバックアップし、ダウンストリームのTiDB Cloudリソースに復元します。クエリバインディングをバックアップするには、[クエリバインディング](/sql-plan-management.md)の次のクエリを使用できます。 ```sql SELECT DISTINCT(CONCAT('CREATE GLOBAL BINDING FOR ', original_sql,' USING ', bind_sql,';')) FROM mysql.bind_info WHERE status='enabled'; @@ -385,7 +385,7 @@ TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポート クエリバインディングを取得したら、下流のTiDB Cloudリソースでそれらを実行して、クエリバインディングを復元します。 -9. 上流の TiDB Self-Managed クラスタでユーザー情報と権限情報をバックアップし、下流のTiDB Cloudリソースに復元します。ユーザー情報と権限情報のバックアップには、以下のスクリプトを使用できます。プレースホルダーを実際の値に置き換える必要があることに注意してください。 +9. 上流の TiDB Self-Managed クラスタでユーザー情報と権限情報をバックアップし、下流のTiDB Cloudリソースに復元します。ユーザー情報と権限情報のバックアップには、以下のスクリプトを使用できます。プレースホルダーを実際の値に置き換える必要があることに注意してください。 ```shell #!/bin/bash diff --git a/tidb-cloud/migrate-from-oracle-using-aws-dms.md b/tidb-cloud/migrate-from-oracle-using-aws-dms.md index 1d99aeba2fe0b..c2a75d52208ca 100644 --- a/tidb-cloud/migrate-from-oracle-using-aws-dms.md +++ b/tidb-cloud/migrate-from-oracle-using-aws-dms.md @@ -13,9 +13,9 @@ summary: AWS Database Migration Service (AWS DMS) を使用して、Amazon RDS f TiDB CloudとAWS DMSについてさらに詳しく知りたい場合は、以下をご覧ください。 -- [TiDB Cloud](https://docs.pingcap.com/tidbcloud/) -- [TiDB開発者ガイド](https://docs.pingcap.com/tidbcloud/dev-guide-overview) -- [AWS DMS ドキュメント](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html) +- [TiDB Cloud](https://docs.pingcap.com/tidbcloud/) +- [TiDB開発者ガイド](https://docs.pingcap.com/tidbcloud/dev-guide-overview) +- [AWS DMS ドキュメント](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html) ## AWS DMSを使う理由とは？ {#why-use-aws-dms} @@ -27,9 +27,9 @@ PostgreSQL、Oracle、SQL Serverなどの異種データベースからTiDB Clou 大まかに言うと、以下の手順に従ってください。 -1. Oracle用のAmazon RDSソースを設定します。 -2. TiDB Cloud Starterインスタンスを作成します。 -3. AWS DMSを使用してデータ移行（フルロード）を設定します。 +1. Oracle用のAmazon RDSソースを設定します。 +2. TiDB Cloud Starterインスタンスを作成します。 +3. AWS DMSを使用してデータ移行（フルロード）を設定します。 以下の図は、高レベルのアーキテクチャを示しています。 @@ -39,10 +39,10 @@ PostgreSQL、Oracle、SQL Serverなどの異種データベースからTiDB Clou 始める前に、以下の前提条件をお読みください。 -- [AWS DMSの前提条件](/tidb-cloud/migrate-from-mysql-using-aws-dms.md#prerequisites) -- [AWSクラウドアカウント](https://aws.amazon.com) -- [TiDB Cloudアカウント](https://tidbcloud.com) -- [DBeaver](https://dbeaver.io/) +- [AWS DMSの前提条件](/tidb-cloud/migrate-from-mysql-using-aws-dms.md#prerequisites) +- [AWSクラウドアカウント](https://aws.amazon.com) +- [TiDB Cloudアカウント](https://tidbcloud.com) +- [DBeaver](https://dbeaver.io/) 次に、AWS DMS を使用して Amazon RDS for Oracle からTiDB Cloudへデータを移行する方法を学びます。 @@ -66,8 +66,8 @@ Oracle DB インスタンスの作成方法については、「Oracle DB イン 以下のスクリプトを使用して、github_events テーブルに 10,000 行のデータを作成し、データを投入します。GitHub イベントデータセットは[GHアーカイブ](https://gharchive.org/)からダウンロードできます。 10,000 行のデータが含まれています。以下の SQL スクリプトを使用して Oracle で実行します。 -- [table_schema_oracle.sql](https://github.com/pingcap-inc/tidb-integration-script/blob/main/aws-dms/oracle_table_schema.sql) -- [oracle_data.sql](https://github.com/pingcap-inc/tidb-integration-script/blob/main/aws-dms/oracle_data.sql) +- [table_schema_oracle.sql](https://github.com/pingcap-inc/tidb-integration-script/blob/main/aws-dms/oracle_table_schema.sql) +- [oracle_data.sql](https://github.com/pingcap-inc/tidb-integration-script/blob/main/aws-dms/oracle_data.sql) SQLスクリプトの実行が完了したら、Oracleのデータを確認してください。以下の例では、 [DBeaver](https://dbeaver.io/)を使用してデータを照会します。 @@ -75,21 +75,21 @@ SQLスクリプトの実行が完了したら、Oracleのデータを確認し ## ステップ4. TiDB Cloud Starterインスタンスを作成する {#step-4-create-a-tidb-cloud-starter-instance} -1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインします。 -2. [TiDB Cloud Starterインスタンスを作成する](/tidb-cloud/tidb-cloud-quickstart.md)。 +2. [TiDB Cloud Starterインスタンスを作成する](/tidb-cloud/tidb-cloud-quickstart.md)。 -3. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックすると、その概要ページに移動します。 +3. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Starterインスタンスの名前をクリックすると、その概要ページに移動します。 -4. 右上隅にある**Connect**をクリックします。 +4. 右上隅にある**Connect**をクリックします。 -5. **Generate Password**をクリックしてパスワードを生成し、生成されたパスワードをコピーしてください。 +5. **Generate Password**をクリックしてパスワードを生成し、生成されたパスワードをコピーしてください。 ## ステップ5. AWS DMSレプリケーションインスタンスを作成する {#step-5-create-an-aws-dms-replication-instance} -1. AWS DMS コンソールの[レプリケーションインスタンス](https://console.aws.amazon.com/dms/v2/home#replicationInstances)ページに移動し、対応するリージョンに切り替えます。 +1. AWS DMS コンソールの[レプリケーションインスタンス](https://console.aws.amazon.com/dms/v2/home#replicationInstances)ページに移動し、対応するリージョンに切り替えます。 -2. VPC 内に`dms.t3.large`を使用して AWS DMS レプリケーション インスタンスを作成します。 +2. VPC 内に`dms.t3.large`を使用して AWS DMS レプリケーション インスタンスを作成します。 ![Create AWS DMS Instance](/media/tidb-cloud/aws-dms-from-oracle-to-tidb-8.png) @@ -99,9 +99,9 @@ SQLスクリプトの実行が完了したら、Oracleのデータを確認し ## ステップ6．DMSエンドポイントを作成する {#step-6-create-dms-endpoints} -1. [AWS DMSコンソール](https://console.aws.amazon.com/dms/v2/home)で、左側のペインにある`Endpoints`メニュー項目をクリックします。 +1. [AWS DMSコンソール](https://console.aws.amazon.com/dms/v2/home)で、左側のペインにある`Endpoints`メニュー項目をクリックします。 -2. OracleのソースエンドポイントとTiDBのターゲットエンドポイントを作成します。 +2. OracleのソースエンドポイントとTiDBのターゲットエンドポイントを作成します。 以下のスクリーンショットは、ソースエンドポイントの設定を示しています。 @@ -125,19 +125,19 @@ AWS Schema Conversion Tool を使用してスキーマを移行する場合は ## ステップ8. データベース移行タスクを作成する {#step-8-create-a-database-migration-task} -1. AWS DMS コンソールで、 [データ移行タスク](https://console.aws.amazon.com/dms/v2/home#tasks)ページに移動します。お住まいの地域に切り替えてください。次に、ウィンドウの右上隅にある**Create task**をクリックします。 +1. AWS DMS コンソールで、 [データ移行タスク](https://console.aws.amazon.com/dms/v2/home#tasks)ページに移動します。お住まいの地域に切り替えてください。次に、ウィンドウの右上隅にある**Create task**をクリックします。 ![Create task](/media/tidb-cloud/aws-dms-to-tidb-cloud-create-task.png) -2. データベース移行タスクを作成し、**Selection rules**を指定します。 +2. データベース移行タスクを作成し、**Selection rules**を指定します。 ![Create AWS DMS migration task](/media/tidb-cloud/aws-dms-from-oracle-to-tidb-11.png) ![AWS DMS migration task selection rules](/media/tidb-cloud/aws-dms-from-oracle-to-tidb-12.png) -3. タスクを作成し、開始し、タスクが完了するまで待ちます。 +3. タスクを作成し、開始し、タスクが完了するまで待ちます。 -4. **Table statistics**をクリックしてテーブルを確認してください。スキーマ名は`ADMIN`です。 +4. **Table statistics**をクリックしてテーブルを確認してください。スキーマ名は`ADMIN`です。 ![Check AWS DMS migration task](/media/tidb-cloud/aws-dms-from-oracle-to-tidb-13.png) @@ -157,5 +157,5 @@ AWS DMS を使用すると、このドキュメントの例に従って、任意 ## 関連項目 {#see-also} -- [AWS DMSを使用してMySQL互換データベースから移行する](/tidb-cloud/migrate-from-mysql-using-aws-dms.md) -- [AWS DMSをTiDB Cloudに接続する](/tidb-cloud/tidb-cloud-connect-aws-dms.md) +- [AWS DMSを使用してMySQL互換データベースから移行する](/tidb-cloud/migrate-from-mysql-using-aws-dms.md) +- [AWS DMSをTiDB Cloudに接続する](/tidb-cloud/tidb-cloud-connect-aws-dms.md) 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 d340941cfb37c..089fbe0f97724 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 @@ -31,7 +31,7 @@ summary: データ移行を使用して、Amazon Aurora MySQL、Amazon Relationa > > このセクションでは、増分データ移行に関する制限事項のみを記載しています。一般的な制限事項も併せてお読みになることをお勧めします。 [制限事項](/tidb-cloud/migrate-from-mysql-using-data-migration.md#limitations)をご覧ください。 -- 対象データベースにターゲットテーブルがまだ作成されていない場合、移行ジョブは以下のようなエラーを報告して失敗します。この場合、ターゲットテーブルを手動で作成してから、移行ジョブを再試行する必要があります。 +- 対象データベースにターゲットテーブルがまだ作成されていない場合、移行ジョブは以下のようなエラーを報告して失敗します。この場合、ターゲットテーブルを手動で作成してから、移行ジョブを再試行する必要があります。 ```sql startLocation: [position: (mysql_bin.000016, 5122), gtid-set: @@ -42,13 +42,13 @@ summary: データ移行を使用して、Amazon Aurora MySQL、Amazon Relationa tracker Raw Cause: Error 1146: Table 'zm.table1' doesn't exist ``` -- アップストリームで一部の行が削除または更新され、ダウンストリームに対応する行がない場合、移行ジョブは、アップストリームから`DELETE`および`UPDATE` DML 操作を複製する際に、削除または更新可能な行がないことを検知します。 +- アップストリームで一部の行が削除または更新され、ダウンストリームに対応する行がない場合、移行ジョブは、アップストリームから`DELETE`および`UPDATE` DML 操作を複製する際に、削除または更新可能な行がないことを検知します。 増分データの移行開始位置としてGTIDを指定する場合、以下の制限事項に注意してください。 -- ソースデータベースでGTIDモードが有効になっていることを確認してください。 -- ソースデータベースがMySQLの場合、MySQLのバージョンは5.6以降である必要があり、ストレージエンジンはInnoDBである必要があります。 -- 移行ジョブがアップストリームのセカンダリデータベースに接続する場合、 `REPLICATE CREATE TABLE ... SELECT`イベントは移行できません。これは、ステートメントが同じ GTID が割り当てられた 2 つのトランザクション ( `CREATE TABLE`と`INSERT` ) に分割されるためです。その結果、 `INSERT`ステートメントはセカンダリデータベースによって無視されます。 +- ソースデータベースでGTIDモードが有効になっていることを確認してください。 +- ソースデータベースがMySQLの場合、MySQLのバージョンは5.6以降である必要があり、ストレージエンジンはInnoDBである必要があります。 +- 移行ジョブがアップストリームのセカンダリデータベースに接続する場合、 `REPLICATE CREATE TABLE ... SELECT`イベントは移行できません。これは、ステートメントが同じ GTID が割り当てられた 2 つのトランザクション ( `CREATE TABLE`と`INSERT` ) に分割されるためです。その結果、 `INSERT`ステートメントはセカンダリデータベースによって無視されます。 ## 前提条件 {#prerequisites} @@ -62,8 +62,8 @@ summary: データ移行を使用して、Amazon Aurora MySQL、Amazon Relationa Amazon RDS および Amazon Aurora MySQL の場合、新しい変更可能なパラメータ グループ (デフォルトのパラメータ グループではない) を作成し、そのパラメータ グループ内の以下のパラメータを変更してから、インスタンスを再起動して変更を適用する必要があります。 -- `gtid_mode` -- `enforce_gtid_consistency` +- `gtid_mode` +- `enforce_gtid_consistency` GTIDモードが正常に有効化されたかどうかは、以下のSQL文を実行することで確認できます。 @@ -123,9 +123,9 @@ SHOW VARIABLES LIKE 'binlog_row_image'; 自己ホスト型のMySQLインスタンスでGTIDモードを有効にするには、以下の手順に従ってください。 -1. 適切な権限を持つMySQLクライアントを使用してMySQLサーバーに接続します。 +1. 適切な権限を持つMySQLクライアントを使用してMySQLサーバーに接続します。 -2. GTIDモードを有効にするには、以下のSQL文を実行してください。 +2. GTIDモードを有効にするには、以下のSQL文を実行してください。 ```sql -- Enable the GTID mode @@ -138,9 +138,9 @@ SHOW VARIABLES LIKE 'binlog_row_image'; RESET MASTER; ``` -3. 設定変更を有効にするには、MySQLサーバーを再起動してください。 +3. 設定変更を有効にするには、MySQLサーバーを再起動してください。 -4. 次のSQL文を実行して、GTIDモードが正常に有効化されているかどうかを確認してください。 +4. 次のSQL文を実行して、GTIDモードが正常に有効化されているかどうかを確認してください。 ```sql SHOW VARIABLES LIKE 'gtid_mode'; @@ -150,68 +150,68 @@ SHOW VARIABLES LIKE 'binlog_row_image'; ## ステップ1：データ移行ページに移動します {#step-1-go-to-the-data-migration-page} -1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンス名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**Data** > **Data Migration**をクリックします。 +2. ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンス名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**Data** > **Data Migration**をクリックします。 -3. **Data Migration**ページで、右上隅にある**Create Migration Job**をクリックします。**Create Migration Job**ページが表示されます。 +3. **Data Migration**ページで、右上隅にある**Create Migration Job**をクリックします。**Create Migration Job**ページが表示されます。 ## ステップ2：ソース接続とターゲット接続を設定する {#step-2-configure-the-source-and-target-connection} **Create Migration Job**ページで、ソースとターゲットの接続を設定します。 -1. 職名を入力してください。職名は文字で始まり、60文字以内である必要があります。文字（AZ、az）、数字（0～9）、アンダースコア（_）、ハイフン（-）が使用可能です。 +1. 職名を入力してください。職名は文字で始まり、60文字以内である必要があります。文字（AZ、az）、数字（0～9）、アンダースコア（_）、ハイフン（-）が使用可能です。 -2. ソース接続プロファイルを入力してください。 +2. ソース接続プロファイルを入力してください。 - - **Data source**：データソースの種類。 - - **リージョン**：データソースのリージョン。クラウドデータベースの場合のみ必要です。 - - **Connectivity method**: データ ソースの接続方法。現在、接続方法に応じて、パブリックIP、VPCピアリング、またはプライベートリンクを選択できます。接続方法に応じて、パブリックIPまたはプライベートリンクを選択できます。接続方法に応じて、パブリックリンクまたはプライベートリンク（AWSのみ）を選択できます。 + - **Data source**：データソースの種類。 + - **リージョン**：データソースのリージョン。クラウドデータベースの場合のみ必要です。 + - **Connectivity method**: データ ソースの接続方法。現在、接続方法に応じて、パブリックIP、VPCピアリング、またはプライベートリンクを選択できます。接続方法に応じて、パブリックIPまたはプライベートリンクを選択できます。接続方法に応じて、パブリックリンクまたはプライベートリンク（AWSのみ）を選択できます。 - - **Hostname or IP address**（パブリックIPおよびVPCピアリングの場合）：データソースのホスト名またはIPアドレス。 - - **Service Name**（プライベートリンクの場合）：エンドポイントのサービス名。 + - **Hostname or IP address**（パブリックIPおよびVPCピアリングの場合）：データソースのホスト名またはIPアドレス。 + - **Service Name**（プライベートリンクの場合）：エンドポイントのサービス名。 - - **Hostname or IP address**（パブリックIPの場合）：データソースのホスト名またはIPアドレス。 - - **Private Link Connection**(プライベート リンク用): [プライベートリンク接続](/tidb-cloud/serverless-private-link-connection.md)セクションで作成したプライベート リンク接続。 + - **Hostname or IP address**（パブリックIPの場合）：データソースのホスト名またはIPアドレス。 + - **Private Link Connection**(プライベート リンク用): [プライベートリンク接続](/tidb-cloud/serverless-private-link-connection.md)セクションで作成したプライベート リンク接続。 - - **Hostname or IP address**（公開の場合）：データソースのホスト名またはIPアドレス。 - - **Private Endpoint**(プライベート リンク用): TiDB Cloud Premium インスタンスの**Networking** > **[外部サービス向け AWS プライベート エンドポイント]**で作成したプライベート エンドポイント。または、**ここで [プライベート エンドポイントの作成] をクリックしてプライベート エンドポイント**を作成します。セットアップの詳細については、データ移行ガイドの[プライベートリンクまたはプライベートエンドポイント](/tidb-cloud/migrate-from-mysql-using-data-migration.md#private-link-or-private-endpoint)セクションを参照してください。 + - **Hostname or IP address**（公開の場合）：データソースのホスト名またはIPアドレス。 + - **Private Endpoint**(プライベート リンク用): TiDB Cloud Premium インスタンスの**Networking** > **[外部サービス向け AWS プライベート エンドポイント]**で作成したプライベート エンドポイント。または、**ここで [プライベート エンドポイントの作成] をクリックしてプライベート エンドポイント**を作成します。セットアップの詳細については、データ移行ガイドの[プライベートリンクまたはプライベートエンドポイント](/tidb-cloud/migrate-from-mysql-using-data-migration.md#private-link-or-private-endpoint)セクションを参照してください。 - - **Port**：データソースのポート番号。 - - **Username**：データソースのユーザー名。 - - **Password**：ユーザー名のパスワード。 - - **SSL/TLS** ：SSL/TLSを有効にする場合は、以下のいずれかの証明書を含む、データソースの証明書をアップロードする必要があります。 - - CA証明書のみ - - クライアント証明書とクライアントキー - - CA証明書、クライアント証明書、およびクライアントキー + - **Port**：データソースのポート番号。 + - **Username**：データソースのユーザー名。 + - **Password**：ユーザー名のパスワード。 + - **SSL/TLS** ：SSL/TLSを有効にする場合は、以下のいずれかの証明書を含む、データソースの証明書をアップロードする必要があります。 + - CA証明書のみ + - クライアント証明書とクライアントキー + - CA証明書、クライアント証明書、およびクライアントキー -3. ターゲット接続プロファイルを入力してください。 +3. ターゲット接続プロファイルを入力してください。 - - **Username**: ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンスのユーザー名を入力します。 - - **Password**： TiDB Cloudのユーザー名のパスワードを入力してください。 + - **Username**: ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンスのユーザー名を入力します。 + - **Password**： TiDB Cloudのユーザー名のパスワードを入力してください。 -4. 入力した情報を検証するには、 **Validate Connection and Next**をクリックしてください。 +4. 入力した情報を検証するには、 **Validate Connection and Next**をクリックしてください。 -5. 表示されたメッセージに従って行動してください。 +5. 表示されたメッセージに従って行動してください。 - - パブリックIPまたはVPCピアリングを使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - AWS Private Link を使用している場合、エンドポイント要求を承認するよう求められます。AWS [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成した AWS リージョンに切り替え、 **Endpoint services**をクリックしてエンドポイント要求を承認してください。 + - パブリックIPまたはVPCピアリングを使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 + - AWS Private Link を使用している場合、エンドポイント要求を承認するよう求められます。AWS [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成した AWS リージョンに切り替え、 **Endpoint services**をクリックしてエンドポイント要求を承認してください。 @@ -222,8 +222,8 @@ SHOW VARIABLES LIKE 'binlog_row_image'; - - 接続方法として**パブリックを**使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**をクリックして、 TiDB Cloudからのエンドポイント接続要求を承認してください。 + - 接続方法として**パブリックを**使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 + - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**をクリックして、 TiDB Cloudからのエンドポイント接続要求を承認してください。 @@ -233,9 +233,9 @@ SHOW VARIABLES LIKE 'binlog_row_image'; **Start Position**領域では、増分データ移行の開始位置として、以下のいずれかのタイプを指定できます。 -- 増分移行ジョブが開始される時間 -- GTID -- Binlogファイル名と位置 +- 増分移行ジョブが開始される時間 +- GTID +- Binlogファイル名と位置 移行ジョブが開始されると、開始位置を変更することはできません。 @@ -269,9 +269,9 @@ SHOW MASTER STATUS; ## ステップ4：移行するオブジェクトを選択する {#step-4-choose-the-objects-to-be-migrated} -1. **Choose Objects to Migrate**ページで、移行するオブジェクトを選択します。 **All**をクリックするとすべてのオブジェクトを選択できます。 **Customize**をクリックしてから、オブジェクト名の横にあるチェックボックスをクリックしてオブジェクトを選択することもできます。 +1. **Choose Objects to Migrate**ページで、移行するオブジェクトを選択します。 **All**をクリックするとすべてのオブジェクトを選択できます。 **Customize**をクリックしてから、オブジェクト名の横にあるチェックボックスをクリックしてオブジェクトを選択することもできます。 -2. **Next**をクリックしてください。 +2. **Next**をクリックしてください。 ## ステップ5：事前チェック {#step-5-precheck} diff --git a/tidb-cloud/migrate-metrics-integrations.md b/tidb-cloud/migrate-metrics-integrations.md index 1e31b3386156c..a2f04bf2ad963 100644 --- a/tidb-cloud/migrate-metrics-integrations.md +++ b/tidb-cloud/migrate-metrics-integrations.md @@ -9,35 +9,35 @@ TiDB Cloudは、DatadogおよびNew Relicとの連携をクラスタレベルで ## 前提条件 {#prerequisites} -- TiDB Cloudのサードパーティ メトリクス統合を設定するには、 TiDB Cloudで`Organization Owner`または`Project Owner`アクセス権が必要です。 +- TiDB Cloudのサードパーティ メトリクス統合を設定するには、 TiDB Cloudで`Organization Owner`または`Project Owner`アクセス権が必要です。 ## 移行手順 {#migration-steps} ### ステップ1：従来のプロジェクトレベルのDatadogおよびNew Relic統合を削除します。 {#step-1-delete-the-legacy-project-level-datadog-and-new-relic-integrations} -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションパネルで、 **Project Settings**の下にある**Integrations**をクリックします。 +3. 左側のナビゲーションパネルで、 **Project Settings**の下にある**Integrations**をクリックします。 -4. **Integrations**ページで、 **Integration to Datadog**または**Integration to New Relic**の横にある**Delete**をクリックします。 +4. **Integrations**ページで、 **Integration to Datadog**または**Integration to New Relic**の横にある**Delete**をクリックします。 -5. 表示されたダイアログで、 `Delete`と入力して、従来の統合機能の削除を確認します。 +5. 表示されたダイアログで、 `Delete`と入力して、従来の統合機能の削除を確認します。 ### ステップ2. 各クラスターごとに新しいDatadogまたはNew Relic統合を作成します。 {#step-2-create-the-new-datadog-or-new-relic-integration-for-each-cluster} プロジェクト内の各[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対して、以下の手順を繰り返してください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして、その概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションパネルで、 **Settings** > **Integrations**をクリックします。 +2. 左側のナビゲーションパネルで、 **Settings** > **Integrations**をクリックします。 -3. **Integrations**ページで、必要に応じて新しい統合を作成します。詳細については、 [TiDB CloudとDatadogを統合する](/tidb-cloud/monitor-datadog-integration.md)および[TiDB CloudとNew Relicを統合する](/tidb-cloud/monitor-new-relic-integration.md)を参照してください。 +3. **Integrations**ページで、必要に応じて新しい統合を作成します。詳細については、 [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-prometheus-metrics-integrations.md b/tidb-cloud/migrate-prometheus-metrics-integrations.md index 2f3138ac9e62c..a8558b8ebdf42 100644 --- a/tidb-cloud/migrate-prometheus-metrics-integrations.md +++ b/tidb-cloud/migrate-prometheus-metrics-integrations.md @@ -9,7 +9,7 @@ TiDB Cloud は、 [Prometheusとの統合](/tidb-cloud/monitor-prometheus-and-gr ## 前提条件 {#prerequisites} -- TiDB Cloudのサードパーティ メトリクス統合を設定するには、 TiDB Cloudで`Organization Owner`または`Project Owner`アクセス権が必要です。 +- TiDB Cloudのサードパーティ メトリクス統合を設定するには、 TiDB Cloudで`Organization Owner`または`Project Owner`アクセス権が必要です。 ## 移行手順 {#migration-steps} @@ -17,29 +17,29 @@ Prometheusとの連携を移行するには、以下の手順を実行してく ### ステップ1. 従来のプロジェクトレベルのPrometheus統合を削除します（ベータ版） {#step-1-delete-the-legacy-project-level-prometheus-integrations-beta} -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションパネルで、 **Project Settings**の下にある**Project Settings**をクリックします。 +3. 左側のナビゲーションパネルで、 **Project Settings**の下にある**Project Settings**をクリックします。 -4. **Integrations** > **Integration to Prometheus (BETA)**モジュールで、 **[Scrape_config Files]**を選択し、 **Delete**をクリックします。 +4. **Integrations** > **Integration to Prometheus (BETA)**モジュールで、 **[Scrape_config Files]**を選択し、 **Delete**をクリックします。 -5. 表示されたダイアログで、 `Delete`と入力して、従来の統合機能の削除を確認します。 +5. 表示されたダイアログで、 `Delete`と入力して、従来の統合機能の削除を確認します。 ### ステップ2. 各クラスターに対して、新しいクラスターレベルのPrometheus統合を作成します。 {#step-2-create-a-new-cluster-level-prometheus-integration-for-each-cluster} プロジェクト内の各[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対して、以下の手順を繰り返してください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして、その概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションパネルで、 **Settings** > **Integrations**をクリックします。 +2. 左側のナビゲーションパネルで、 **Settings** > **Integrations**をクリックします。 -3. **Integrations**ページで、新しい Prometheus 統合を作成します。詳細については、 [TiDB CloudをPrometheusおよびGrafanaと統合する](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)を参照してください。 +3. **Integrations**ページで、新しい Prometheus 統合を作成します。詳細については、 [TiDB CloudをPrometheusおよびGrafanaと統合する](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)を参照してください。 ## プロジェクトレベルのPrometheus統合を削除した場合の影響（ベータ版） {#impact-of-deleting-the-project-level-prometheus-integration-beta} diff --git a/tidb-cloud/migrate-sql-shards.md b/tidb-cloud/migrate-sql-shards.md index 391abab0238eb..90f6cd4a05f9c 100644 --- a/tidb-cloud/migrate-sql-shards.md +++ b/tidb-cloud/migrate-sql-shards.md @@ -17,14 +17,14 @@ summary: 大規模データセットのMySQLシャードをTiDB Cloudに移行 上流クラスターの環境情報は以下のとおりです。 -- MySQLバージョン：MySQL v5.7.18 -- MySQLインスタンス1： - - スキーマ`store_01`およびテーブル`[sale_01, sale_02]` - - スキーマ`store_02`およびテーブル`[sale_01, sale_02]` -- MySQLインスタンス2： - - スキーマ`store_01`およびテーブル`[sale_01, sale_02]` - - スキーマ`store_02`およびテーブル`[sale_01, sale_02]` -- テーブル構造： +- MySQLバージョン：MySQL v5.7.18 +- MySQLインスタンス1： + - スキーマ`store_01`およびテーブル`[sale_01, sale_02]` + - スキーマ`store_02`およびテーブル`[sale_01, sale_02]` +- MySQLインスタンス2： + - スキーマ`store_01`およびテーブル`[sale_01, sale_02]` + - スキーマ`store_02`およびテーブル`[sale_01, sale_02]` +- テーブル構造： ```sql CREATE TABLE sale_01 ( @@ -58,13 +58,13 @@ DM のバージョンは v5.3.0 です。 TiDB DM を手動でデプロイする Amazon S3 バケット内に、第 1 階層ディレクトリ`store` (データベースのレベルに対応) と第 2 階層ディレクトリ`sales` (テーブルのレベルに対応) を作成します。 `sales`内に、MySQL インスタンスごとに第 3 階層ディレクトリ (MySQL インスタンスのレベルに対応) を作成します。例: -- MySQLインスタンス1のデータを`s3://dumpling-s3/store/sales/instance01/`に移行します。 -- MySQLインスタンス2のデータを`s3://dumpling-s3/store/sales/instance02/`に移行します。 +- MySQLインスタンス1のデータを`s3://dumpling-s3/store/sales/instance01/`に移行します。 +- MySQLインスタンス2のデータを`s3://dumpling-s3/store/sales/instance02/`に移行します。 複数のインスタンスにシャードがある場合は、データベースごとに第 1 レベルのディレクトリを 1 つ作成し、シャーディングされたテーブルごとに第 2 レベルのディレクトリを 1 つ作成します。次に、管理を容易にするために、MySQL インスタンスごとに第 3 レベルのディレクトリを作成します。たとえば、MySQL インスタンス 1 と MySQL インスタンス 2 のテーブル`stock_N.product_N`をTiDB Cloudのテーブル`stock.products`に移行およびマージする場合は、次のディレクトリを作成できます。 -- `s3://dumpling-s3/stock/products/instance01/` -- `s3://dumpling-s3/stock/products/instance02/` +- `s3://dumpling-s3/stock/products/instance01/` +- `s3://dumpling-s3/stock/products/instance02/` ### ステップ2. Dumplingを使用してデータをAmazon S3にエクスポートする {#step-2-use-dumpling-to-export-data-to-amazon-s3} @@ -72,14 +72,14 @@ Dumpling のインストール方法については、 [Dumplingの紹介](https 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)を参照してください。 +- アップストリームクラスターの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)を参照してください。 CSVファイルの名前は以下のようにしてください。 -- 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`と`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 +- 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`と`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 > **Note:** > @@ -87,14 +87,14 @@ CSVファイルの名前は以下のようにしてください。 データをAmazon S3にエクスポートするには、以下の手順を実行してください。 -1. Amazon S3 バケットの`AWS_ACCESS_KEY_ID`と`AWS_SECRET_ACCESS_KEY`を取得します。 +1. Amazon S3 バケットの`AWS_ACCESS_KEY_ID`と`AWS_SECRET_ACCESS_KEY`を取得します。 ```shell [root@localhost ~]# export AWS_ACCESS_KEY_ID={your_aws_access_key_id} [root@localhost ~]# export AWS_SECRET_ACCESS_KEY= {your_aws_secret_access_key} ``` -2. MySQL instance1 から Amazon S3 バケット内の`s3://dumpling-s3/store/sales/instance01/`ディレクトリにデータをエクスポートします。 +2. MySQL instance1 から Amazon S3 バケット内の`s3://dumpling-s3/store/sales/instance01/`ディレクトリにデータをエクスポートします。 ```shell [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" @@ -102,7 +102,7 @@ CSVファイルの名前は以下のようにしてください。 パラメータの詳細については、 [Dumplingのオプション一覧](https://docs.pingcap.com/tidb/stable/dumpling-overview#option-list-of-dumpling)を参照してください。 -3. MySQL instance2 から Amazon S3 バケット内の`s3://dumpling-s3/store/sales/instance02/`ディレクトリにデータをエクスポートします。 +3. MySQL instance2 から Amazon S3 バケット内の`s3://dumpling-s3/store/sales/instance02/`ディレクトリにデータをエクスポートします。 ```shell [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" @@ -175,33 +175,33 @@ Query OK, 0 rows affected (0.17 sec) Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次のようにデータインポートタスクを実行できます。 -1. ターゲットのTiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスターの**Import**ページを開きます。 +1. ターゲットのTiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスターの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. ターゲットのTiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**Data** > **Import**をクリックします。 + 2. ターゲットのTiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーション ペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**を選択し、次に**Amazon S3**をクリックします。 +2. **Import data from Cloud Storage**を選択し、次に**Amazon S3**をクリックします。 -3. **Amazon S3からデータをインポートする**ページで、以下の情報を入力してください。 +3. **Amazon S3からデータをインポートする**ページで、以下の情報を入力してください。 - - **Import File Count**： TiDB Cloud StarterまたはTiDB Cloud Essentialの場合は、 **Multiple files**を選択してください。このフィールドはTiDB Cloud Dedicatedでは利用できません。 - - **Included Schema Files**:**No**を選択します。 - - **Data Format**： **CSV**を選択してください。 - - **Folder URI** : ソース データのバケット URI を入力してください。この例では、テーブルに対応する第 2 階層のディレクトリ`s3://dumpling-s3/store/sales/`を使用することで、 TiDB Cloud はすべての MySQL インスタンスのデータを`store.sales`に一度にインポートしてマージできます。 - - **Bucket Access**> **AWS Role ARN** ：取得したロールARNを入力してください。 + - **Import File Count**： TiDB Cloud StarterまたはTiDB Cloud Essentialの場合は、 **Multiple files**を選択してください。このフィールドはTiDB Cloud Dedicatedでは利用できません。 + - **Included Schema Files**:**No**を選択します。 + - **Data Format**： **CSV**を選択してください。 + - **Folder URI** : ソース データのバケット URI を入力してください。この例では、テーブルに対応する第 2 階層のディレクトリ`s3://dumpling-s3/store/sales/`を使用することで、 TiDB Cloud はすべての MySQL インスタンスのデータを`store.sales`に一度にインポートしてマージできます。 + - **Bucket Access**> **AWS Role ARN** ：取得したロールARNを入力してください。 バケットの場所がTiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスタークラスターと異なる場合は、クロスリージョンのコンプライアンスを確認してください。 TiDB Cloudは、指定されたバケット URI 内のデータにアクセスできるかどうかの検証を開始します。検証後、 TiDB Cloudはデフォルトのファイル命名パターンを使用してデータ ソース内のすべてのファイルのスキャンを試行し、次のページの左側にスキャンの概要結果を返します。 `AccessDenied`エラーが発生した場合は、 [S3からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング](/tidb-cloud/troubleshoot-import-access-denied-error.md)を参照してください。 -4. **Connect**をクリックしてください。 +4. **Connect**をクリックしてください。 -5. **Destination**セクションで、対象のデータベースとテーブルを選択します。 +5. **Destination**セクションで、対象のデータベースとテーブルを選択します。 複数のファイルをインポートする場合、 **Advanced Settings** ＞ **Mapping Settings**を使用して、各ターゲットテーブルとその対応するCSVファイルごとにカスタムマッピングルールを定義できます。その後、データソースファイルは、指定されたカスタムマッピングルールを使用して再スキャンされます。 @@ -209,9 +209,9 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 ワイルドカードを使用してソースファイルを照合することもできます。例： - - `s3://[bucket_name]/[data_source_folder]/my-data?.csv` : そのフォルダ内の`my-data`で始まり、その後に 1 文字が続くすべての CSV ファイル (例えば`my-data1.csv`や`my-data2.csv` ) は、同じターゲット テーブルにインポートされます。 + - `s3://[bucket_name]/[data_source_folder]/my-data?.csv` : そのフォルダ内の`my-data`で始まり、その後に 1 文字が続くすべての CSV ファイル (例えば`my-data1.csv`や`my-data2.csv` ) は、同じターゲット テーブルにインポートされます。 - - `s3://[bucket_name]/[data_source_folder]/my-data*.csv` : `my-data`で始まるフォルダ内のすべての CSV ファイルは、同じターゲット テーブルにインポートされます。 + - `s3://[bucket_name]/[data_source_folder]/my-data*.csv` : `my-data`で始まるフォルダ内のすべての CSV ファイルは、同じターゲット テーブルにインポートされます。 `?`と`*`のみがサポートされていることに注意してください。 @@ -219,7 +219,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 > > URIにはデータソースフォルダを含める必要があります。 -6. 必要に応じてCSV設定を編集してください。 +6. 必要に応じてCSV設定を編集してください。 また、 **Edit CSV configuration**をクリックすると、Backslash Escape、Separator、Delimiterを設定して、より詳細な制御を行うことができます。 @@ -227,9 +227,9 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 > > セパレータ、デリミタ、およびヌルの設定には、英数字と特定の特殊文字の両方を使用できます。サポートされている特殊文字には、 `\t` 、 `\b` 、 `\n` 、 `\r` 、 `\f` 、および`\u0001`が含まれます。 -7. **Start Import**をクリックしてください。 +7. **Start Import**をクリックしてください。 -8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +8. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 データのインポート後、 TiDB CloudのAmazon S3アクセスを削除したい場合は、追加したポリシーを削除するだけで済みます。 @@ -243,7 +243,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 ### ステップ1. データソースを追加する {#step-1-add-the-data-source} -1. DMにアップストリームデータソースを設定するために、新しいデータソースファイル`dm-source1.yaml`を作成します。以下の内容を追加してください。 +1. DMにアップストリームデータソースを設定するために、新しいデータソースファイル`dm-source1.yaml`を作成します。以下の内容を追加してください。 ```yaml # MySQL Configuration. @@ -259,7 +259,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 port: ${port} # For example: 3307 ``` -2. 別の新しいデータソースファイル`dm-source2.yaml`を作成し、以下の内容を追加してください。 +2. 別の新しいデータソースファイル`dm-source2.yaml`を作成し、以下の内容を追加してください。 ```yaml # MySQL Configuration. @@ -275,7 +275,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 port: 3308 ``` -3. ターミナルで次のコマンドを実行します。 `tiup dmctl`を使用して、最初のデータソース構成をDMクラスタにロードします。 +3. ターミナルで次のコマンドを実行します。 `tiup dmctl`を使用して、最初のデータソース構成をDMクラスタにロードします。 ```shell [root@localhost ~]# tiup dmctl --master-addr ${advertise-addr} operate-source create dm-source1.yaml @@ -310,7 +310,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 ``` -4. ターミナルで次のコマンドを実行します。 `tiup dmctl`を使用して、2番目のデータソース構成をDMクラスタにロードします。 +4. ターミナルで次のコマンドを実行します。 `tiup dmctl`を使用して、2番目のデータソース構成をDMクラスタにロードします。 ```shell [root@localhost ~]# tiup dmctl --master-addr 192.168.11.110:9261 operate-source create dm-source2.yaml @@ -339,9 +339,9 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 ### ステップ2. レプリケーションタスクを作成する {#step-2-create-a-replication-task} -1. レプリケーションタスク用に`test-task1.yaml`ファイルを作成します。 +1. レプリケーションタスク用に`test-task1.yaml`ファイルを作成します。 -2. DumplingによってエクスポートされたMySQLインスタンス1のメタデータファイルから開始点を見つけます。例： +2. DumplingによってエクスポートされたMySQLインスタンス1のメタデータファイルから開始点を見つけます。例： ```toml Started dump at: 2022-05-25 10:16:26 @@ -352,7 +352,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 Finished dump at: 2022-05-25 10:16:27 ``` -3. DumplingによってエクスポートされたMySQLインスタンス2のメタデータファイル内で開始点を見つけます。例： +3. DumplingによってエクスポートされたMySQLインスタンス2のメタデータファイル内で開始点を見つけます。例： ```toml Started dump at: 2022-05-25 10:20:32 @@ -363,7 +363,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 Finished dump at: 2022-05-25 10:20:32 ``` -4. タスク構成ファイル`test-task1`を編集して、各データソースの増分レプリケーションモードとレプリケーション開始点を設定します。 +4. タスク構成ファイル`test-task1`を編集して、各データソースの増分レプリケーションモードとレプリケーション開始点を設定します。 ```yaml ## ********* Task Configuration ********* diff --git a/tidb-cloud/monitor-alert-email.md b/tidb-cloud/monitor-alert-email.md index 0c832777cd5ff..f9f6bf1c227b2 100644 --- a/tidb-cloud/monitor-alert-email.md +++ b/tidb-cloud/monitor-alert-email.md @@ -15,13 +15,13 @@ TiDB Cloud、電子メール、[Slack](/tidb-cloud/monitor-alert-slack.md)、[Zo -- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象プロジェクトへの`Project Owner`アクセス権が必要です。 +- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象プロジェクトへの`Project Owner`アクセス権が必要です。 -- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象インスタンスへの`Project Owner`または`Instance Manager`アクセス権が必要です。 +- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象インスタンスへの`Project Owner`または`Instance Manager`アクセス権が必要です。 @@ -35,28 +35,28 @@ TiDB Cloud、電子メール、[Slack](/tidb-cloud/monitor-alert-slack.md)、[Zo > > TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスタがある場合でも、購読は一度だけで済みます。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションペインで、 **Alert Subscription**の下にある**Project Settings**をクリックします。 +3. 左側のナビゲーションペインで、 **Alert Subscription**の下にある**Project Settings**をクリックします。 -4. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +4. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -5. **Subscriber Type**のドロップダウンリストから**Email**を選択してください。 +5. **Subscriber Type**のドロップダウンリストから**Email**を選択してください。 -6. メールアドレスを入力してください。 +6. メールアドレスを入力してください。 -7. **Test Connection**をクリックしてください。 +7. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 -8. 購読を完了するには、 **Save**をクリックしてください。 +8. 購読を完了するには、 **Save**をクリックしてください。 または、 TiDB Cloud Dedicatedクラスタの[**Alert**](/tidb-cloud/monitor-built-in-alerting.md#view-alerts)ページの右上隅にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -68,22 +68,22 @@ TiDB Cloud、電子メール、[Slack](/tidb-cloud/monitor-alert-slack.md)、[Zo > > TiDB Cloud Essentialの場合、アラートの購読は現在のインスタンス内のすべてのアラートに適用されます。複数のTiDB Cloud Essentialインスタンスをお持ちの場合は、各インスタンスごとに個別に購読する必要があります。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -4. **Subscriber Type**のドロップダウンリストから**Email**を選択してください。 +4. **Subscriber Type**のドロップダウンリストから**Email**を選択してください。 -5. メールアドレスを入力してください。 +5. メールアドレスを入力してください。 -6. **Test Connection**をクリックしてください。 +6. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 -7. 購読を完了するには、 **Save**をクリックしてください。 +7. 購読を完了するには、 **Save**をクリックしてください。 または、 TiDB Cloud Essentialインスタンスの[**Alert**](/tidb-cloud/monitor-built-in-alerting.md#view-alerts)ページの右上隅にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -95,22 +95,22 @@ TiDB Cloud、電子メール、[Slack](/tidb-cloud/monitor-alert-slack.md)、[Zo > > TiDB Cloud Premiumの場合、アラートの購読は現在のインスタンス内のすべてのアラートに適用されます。複数のTiDB Cloud Premiumインスタンスをお持ちの場合は、各インスタンスごとに個別に購読する必要があります。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -4. **Subscriber Type**のドロップダウンリストから**Email**を選択してください。 +4. **Subscriber Type**のドロップダウンリストから**Email**を選択してください。 -5. メールアドレスを入力してください。 +5. メールアドレスを入力してください。 -6. **Test Connection**をクリックしてください。 +6. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 -7. 購読を完了するには、 **Save**をクリックしてください。 +7. 購読を完了するには、 **Save**をクリックしてください。 または、 TiDB Cloud Premiumインスタンスの[**Alert**](/tidb-cloud/monitor-built-in-alerting.md#view-alerts)ページの右上隅にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -124,28 +124,28 @@ TiDB Cloud、電子メール、[Slack](/tidb-cloud/monitor-alert-slack.md)、[Zo -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Alert Subscription**をクリックします。 -4. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **...** > **Unsubscribe**をクリックします。 -5. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Alert Subscription**をクリックします。 +4. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **...** > **Unsubscribe**をクリックします。 +5. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **...** > **Unsubscribe**をクリックします。 -4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **...** > **Unsubscribe**をクリックします。 +4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **...** > **Unsubscribe**をクリックします。 -4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **...** > **Unsubscribe**をクリックします。 +4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 diff --git a/tidb-cloud/monitor-alert-flashduty.md b/tidb-cloud/monitor-alert-flashduty.md index effd7c7627528..7fb1fe5ad2aa0 100644 --- a/tidb-cloud/monitor-alert-flashduty.md +++ b/tidb-cloud/monitor-alert-flashduty.md @@ -13,17 +13,17 @@ TiDB Cloud、Flashduty、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メー ## 前提条件 {#prerequisites} -- Flashduty 機能による購読機能は、 **Enterprise**または**Premium**[サポートプラン](/tidb-cloud/connected-care-overview.md)に加入している組織のみが利用できます。 +- Flashduty 機能による購読機能は、 **Enterprise**または**Premium**[サポートプラン](/tidb-cloud/connected-care-overview.md)に加入している組織のみが利用できます。 -- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象プロジェクトへの`Project Owner`アクセス権が必要です。 +- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象プロジェクトへの`Project Owner`アクセス権が必要です。 -- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象インスタンスへの`Project Owner`または`Instance Manager`アクセス権が必要です。 +- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象インスタンスへの`Project Owner`または`Instance Manager`アクセス権が必要です。 @@ -33,8 +33,8 @@ TiDB Cloud、Flashduty、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メー ### ステップ1. FlashdutyのWebhook URLを生成する {#step-1-generate-a-flashduty-webhook-url} -1. [FlashDuty Prometheusとの統合](https://docs.flashcat.cloud/en/on-call/integration/alert-integration/alert-sources/prometheus)の手順に従ってWebhook URLを生成します。 -2. 生成されたウェブフックURLを保存して、次のステップで使用してください。 +1. [FlashDuty Prometheusとの統合](https://docs.flashcat.cloud/en/on-call/integration/alert-integration/alert-sources/prometheus)の手順に従ってWebhook URLを生成します。 +2. 生成されたウェブフックURLを保存して、次のステップで使用してください。 ### ステップ2. TiDB Cloudから購読する {#step-2-subscribe-from-tidb-cloud} @@ -46,28 +46,28 @@ TiDB Cloud、Flashduty、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メー > > TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスタがある場合でも、購読は一度だけで済みます。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションペインで、 **Alert Subscription**の下にある**Project Settings**をクリックします。 +3. 左側のナビゲーションペインで、 **Alert Subscription**の下にある**Project Settings**をクリックします。 -4. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +4. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -5. **Subscriber Type**のドロップダウンリストから**Flashduty**を選択してください。 +5. **Subscriber Type**のドロップダウンリストから**Flashduty**を選択してください。 -6. **Name**欄に名前を入力し、 **Webhook URL**欄にFlashdutyのWebhook URLを入力してください。 +6. **Name**欄に名前を入力し、 **Webhook URL**欄にFlashdutyのWebhook URLを入力してください。 -7. **Test Connection**をクリックしてください。 +7. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 -8. 購読を完了するには、 **Save**をクリックしてください。 +8. 購読を完了するには、 **Save**をクリックしてください。 または、 TiDB Cloud Dedicatedクラスタの**Alert**ページの右上にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -81,22 +81,22 @@ TiDB Cloud、Flashduty、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メー > > TiDB Cloud Essentialの場合、アラートの購読は現在のインスタンス内のすべてのアラートに適用されます。複数のTiDB Cloud Essentialインスタンスをお持ちの場合は、各インスタンスごとに個別に購読する必要があります。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -4. **Subscriber Type**のドロップダウンリストから**Flashduty**を選択してください。 +4. **Subscriber Type**のドロップダウンリストから**Flashduty**を選択してください。 -5. **Name**欄に名前を入力し、 **Webhook URL**欄にFlashdutyのWebhook URLを入力してください。 +5. **Name**欄に名前を入力し、 **Webhook URL**欄にFlashdutyのWebhook URLを入力してください。 -6. **Test Connection**をクリックしてください。 +6. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 -7. 購読を完了するには、 **Save**をクリックしてください。 +7. 購読を完了するには、 **Save**をクリックしてください。 または、 TiDB Cloud Essentialインスタンスの**Alert**ページの右上隅にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -108,22 +108,22 @@ TiDB Cloud、Flashduty、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メー > > TiDB Cloud Premiumの場合、アラートの購読は現在のインスタンス内のすべてのアラートに適用されます。複数のTiDB Cloud Premiumインスタンスをお持ちの場合は、各インスタンスごとに個別に購読する必要があります。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -4. **Subscriber Type**のドロップダウンリストから**Flashduty**を選択してください。 +4. **Subscriber Type**のドロップダウンリストから**Flashduty**を選択してください。 -5. **Name**欄に名前を入力し、 **Webhook URL**欄にFlashdutyのWebhook URLを入力してください。 +5. **Name**欄に名前を入力し、 **Webhook URL**欄にFlashdutyのWebhook URLを入力してください。 -6. **Test Connection**をクリックしてください。 +6. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 -7. 購読を完了するには、 **Save**をクリックしてください。 +7. 購読を完了するには、 **Save**をクリックしてください。 または、 TiDB Cloud Premiumインスタンスの**Alert**ページの右上隅にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -137,28 +137,28 @@ TiDB Cloud、Flashduty、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メー -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Alert Subscription**をクリックします。 -4. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **...** > **Unsubscribe**をクリックします。 -5. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Alert Subscription**をクリックします。 +4. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **...** > **Unsubscribe**をクリックします。 +5. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **...** > **Unsubscribe**をクリックします。 -4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **...** > **Unsubscribe**をクリックします。 +4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **...** > **Unsubscribe**をクリックします。 -4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **...** > **Unsubscribe**をクリックします。 +4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 diff --git a/tidb-cloud/monitor-alert-pagerduty.md b/tidb-cloud/monitor-alert-pagerduty.md index 5427cfd9bc459..01bdf7eb66a44 100644 --- a/tidb-cloud/monitor-alert-pagerduty.md +++ b/tidb-cloud/monitor-alert-pagerduty.md @@ -13,17 +13,17 @@ TiDB Cloud は、PagerDuty、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メ ## 前提条件 {#prerequisites} -- PagerDuty 経由のサブスクライブ機能は、 **Enterprise**または**Premium**[サポートプラン](/tidb-cloud/connected-care-overview.md)にサブスクライブしている組織のみが利用できます。 +- PagerDuty 経由のサブスクライブ機能は、 **Enterprise**または**Premium**[サポートプラン](/tidb-cloud/connected-care-overview.md)にサブスクライブしている組織のみが利用できます。 -- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象プロジェクトへの`Project Owner`アクセス権が必要です。 +- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象プロジェクトへの`Project Owner`アクセス権が必要です。 -- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象インスタンスへの`Project Owner`または`Instance Manager`アクセス権が必要です。 +- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象インスタンスへの`Project Owner`または`Instance Manager`アクセス権が必要です。 @@ -33,8 +33,8 @@ TiDB Cloud は、PagerDuty、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メ ### ステップ1. PagerDutyの統合キーを生成する {#step-1-generate-a-pagerduty-integration-key} -1. [PagerDutyイベントAPI v2の概要](https://developer.pagerduty.com/docs/events-api-v2-overview#getting-started)の概要の手順に従って、**Events API v2**タイプの統合キーを生成します。 -2. 生成された統合キーを保存して、次のステップで使用してください。 +1. [PagerDutyイベントAPI v2の概要](https://developer.pagerduty.com/docs/events-api-v2-overview#getting-started)の概要の手順に従って、**Events API v2**タイプの統合キーを生成します。 +2. 生成された統合キーを保存して、次のステップで使用してください。 ### ステップ2. TiDB Cloudから購読する {#step-2-subscribe-from-tidb-cloud} @@ -46,24 +46,24 @@ TiDB Cloud は、PagerDuty、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メ > > TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスタがある場合でも、購読は一度だけで済みます。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Alert Subscription**をクリックします。 +3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Alert Subscription**をクリックします。 -4. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +4. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -5. **Subscriber Type**ドロップダウンリストから**PagerDuty**を選択してください。 +5. **Subscriber Type**ドロップダウンリストから**PagerDuty**を選択してください。 -6. **Name**欄に名前を入力し、 **Integration Key**欄にPagerDutyの統合キーを入力してください。 +6. **Name**欄に名前を入力し、 **Integration Key**欄にPagerDutyの統合キーを入力してください。 -7. **Test Connection**をクリックしてください。 +7. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 -8. 購読を完了するには、 **Save**をクリックしてください。 +8. 購読を完了するには、 **Save**をクリックしてください。 または、 TiDB Cloud Dedicatedクラスタの**アラート**ページの右上にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -77,22 +77,22 @@ TiDB Cloud は、PagerDuty、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メ > > TiDB Cloud Essentialの場合、アラートの購読は現在のインスタンス内のすべてのアラートに適用されます。複数のインスタンスがある場合は、各インスタンスごとに個別に購読する必要があります。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -4. **Subscriber Type**ドロップダウンリストから**PagerDuty**を選択してください。 +4. **Subscriber Type**ドロップダウンリストから**PagerDuty**を選択してください。 -5. **Name**欄に名前を入力し、 **Integration Key**欄にPagerDutyの統合キーを入力してください。 +5. **Name**欄に名前を入力し、 **Integration Key**欄にPagerDutyの統合キーを入力してください。 -6. **Test Connection**をクリックしてください。 +6. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 -7. 購読を完了するには、 **Save**をクリックしてください。 +7. 購読を完了するには、 **Save**をクリックしてください。 または、 TiDB Cloud Essentialインスタンスの**アラート**ページの右上隅にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -104,22 +104,22 @@ TiDB Cloud は、PagerDuty、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メ > > TiDB Cloud Premiumの場合、アラート購読は現在のインスタンス内のすべてのアラートに適用されます。複数のインスタンスをお持ちの場合は、各インスタンスごとに個別に購読する必要があります。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -4. **Subscriber Type**ドロップダウンリストから**PagerDuty**を選択してください。 +4. **Subscriber Type**ドロップダウンリストから**PagerDuty**を選択してください。 -5. **Name**欄に名前を入力し、 **Integration Key**欄にPagerDutyの統合キーを入力してください。 +5. **Name**欄に名前を入力し、 **Integration Key**欄にPagerDutyの統合キーを入力してください。 -6. **Test Connection**をクリックしてください。 +6. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 -7. 購読を完了するには、 **Save**をクリックしてください。 +7. 購読を完了するには、 **Save**をクリックしてください。 または、 TiDB Cloud Premiumインスタンスの**アラート**ページの右上隅にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -133,28 +133,28 @@ TiDB Cloud は、PagerDuty、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メ -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Alert Subscription**をクリックします。 -4. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 -5. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Alert Subscription**をクリックします。 +4. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 +5. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 -4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 +4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 -4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 +4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 diff --git a/tidb-cloud/monitor-alert-slack.md b/tidb-cloud/monitor-alert-slack.md index c0c08b0395900..697908e3ec97a 100644 --- a/tidb-cloud/monitor-alert-slack.md +++ b/tidb-cloud/monitor-alert-slack.md @@ -13,17 +13,17 @@ TiDB Cloud、Slack、[メール](/tidb-cloud/monitor-alert-email.md)、[Zoom](/t ## 前提条件 {#prerequisites} -- Slack経由での購読機能は、**Enterprise**または**Premium**サポートプランに加入している組織のみが利用できます。 +- Slack経由での購読機能は、**Enterprise**または**Premium**サポートプランに加入している組織のみが利用できます。 -- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象プロジェクトへの`Project Owner`アクセス権が必要です。 +- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象プロジェクトへの`Project Owner`アクセス権が必要です。 -- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象インスタンスへの`Project Owner`または`Instance Manager`アクセス権が必要です。 +- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象インスタンスへの`Project Owner`または`Instance Manager`アクセス権が必要です。 @@ -31,11 +31,11 @@ TiDB Cloud、Slack、[メール](/tidb-cloud/monitor-alert-email.md)、[Zoom](/t ### ステップ1：SlackウェブフックURLを生成する {#step-1-generate-a-slack-webhook-url} -1. まだお持ちでない場合は、 [Slackアプリを作成する](https://api.slack.com/apps/new)。 **Create New App**をクリックし、 **From scratch**を選択します。名前を入力し、アプリを関連付けるワークスペースを選択して、 **Create App**をクリックします。 -2. アプリの設定ページに移動します。[アプリの管理ダッシュボード](https://api.slack.com/apps)から設定をロードできます。 -3. **Incoming Webhooks**タブをクリックし、 **Activate Incoming Webhooks**を**ON**に切り替えます。 -4. **Add New Webhook to Workspace**をクリックします。 -5. アラート通知を受信するチャネルを選択し、 **Authorize**を選択してください。受信Webhookをプライベートチャネルに追加する必要がある場合は、まずそのチャネルに参加している必要があります。 +1. まだお持ちでない場合は、 [Slackアプリを作成する](https://api.slack.com/apps/new)。 **Create New App**をクリックし、 **From scratch**を選択します。名前を入力し、アプリを関連付けるワークスペースを選択して、 **Create App**をクリックします。 +2. アプリの設定ページに移動します。[アプリの管理ダッシュボード](https://api.slack.com/apps)から設定をロードできます。 +3. **Incoming Webhooks**タブをクリックし、 **Activate Incoming Webhooks**を**ON**に切り替えます。 +4. **Add New Webhook to Workspace**をクリックします。 +5. アラート通知を受信するチャネルを選択し、 **Authorize**を選択してください。受信Webhookをプライベートチャネルに追加する必要がある場合は、まずそのチャネルに参加している必要があります。 **ワークスペースの Webhook URL**セクションに、次の形式で新しいエントリが表示されます: `https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX` 。 @@ -51,24 +51,24 @@ TiDB Cloud Dedicatedクラスターのアラート通知を購読するには、 > > TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスタがある場合でも、購読は一度だけで済みます。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションペインで、 **Alert Subscription**の下にある**Project Settings**をクリックします。 +3. 左側のナビゲーションペインで、 **Alert Subscription**の下にある**Project Settings**をクリックします。 -4. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +4. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -5. **購読者タイプの**ドロップダウンリストから**Slack**を選択してください。 +5. **購読者タイプの**ドロップダウンリストから**Slack**を選択してください。 -6. **Name**欄に名前を、**URL**欄にSlackのWebhook URLを入力してください。 +6. **Name**欄に名前を、**URL**欄にSlackのWebhook URLを入力してください。 -7. **Test Connection**をクリックしてください。 +7. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 -8. 購読を完了するには、 **Save**をクリックしてください。 +8. 購読を完了するには、 **Save**をクリックしてください。 または、対象のTiDB Cloud Dedicatedクラスタの**アラート**ページの右上にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -82,22 +82,22 @@ TiDB Cloud Dedicatedクラスターのアラート通知を購読するには、 > > TiDB Cloud Essentialの場合、アラートの購読は現在のインスタンス内のすべてのアラートに適用されます。複数のTiDB Cloud Essentialインスタンスをお持ちの場合は、各インスタンスごとに個別に購読する必要があります。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -4. **購読者タイプの**ドロップダウンリストから**Slack**を選択してください。 +4. **購読者タイプの**ドロップダウンリストから**Slack**を選択してください。 -5. **Name**欄に名前を、**URL**欄にSlackのWebhook URLを入力してください。 +5. **Name**欄に名前を、**URL**欄にSlackのWebhook URLを入力してください。 -6. **Test Connection**をクリックしてください。 +6. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 -7. 購読を完了するには、 **Save**をクリックしてください。 +7. 購読を完了するには、 **Save**をクリックしてください。 または、対象のTiDB Cloud Essentialインスタンスの**アラート**ページの右上隅にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -109,22 +109,22 @@ TiDB Cloud Dedicatedクラスターのアラート通知を購読するには、 > > TiDB Cloud Premiumの場合、アラートの購読は現在のインスタンス内のすべてのアラートに適用されます。複数のTiDB Cloud Premiumインスタンスをお持ちの場合は、各インスタンスごとに個別に購読する必要があります。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -4. **購読者タイプの**ドロップダウンリストから**Slack**を選択してください。 +4. **購読者タイプの**ドロップダウンリストから**Slack**を選択してください。 -5. **Name**欄に名前を、**URL**欄にSlackのWebhook URLを入力してください。 +5. **Name**欄に名前を、**URL**欄にSlackのWebhook URLを入力してください。 -6. **Test Connection**をクリックしてください。 +6. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 -7. 購読を完了するには、 **Save**をクリックしてください。 +7. 購読を完了するには、 **Save**をクリックしてください。 または、対象のTiDB Cloud Premiumインスタンスの**アラート**ページの右上にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -138,28 +138,28 @@ TiDB Cloud Dedicatedクラスターのアラート通知を購読するには、 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Alert Subscription**をクリックします。 -4. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 -5. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Alert Subscription**をクリックします。 +4. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 +5. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 -4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 +4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 -4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 +4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 diff --git a/tidb-cloud/monitor-alert-zoom.md b/tidb-cloud/monitor-alert-zoom.md index a3f673eac1c7d..fa758c3f500ae 100644 --- a/tidb-cloud/monitor-alert-zoom.md +++ b/tidb-cloud/monitor-alert-zoom.md @@ -13,19 +13,19 @@ TiDB Cloud は、Zoom、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メール ## 前提条件 {#prerequisites} -- Zoom経由での登録機能は、**Enterprise**または**Premium**サポートプランに加入している組織のみが利用できます。 +- Zoom経由での登録機能は、**Enterprise**または**Premium**サポートプランに加入している組織のみが利用できます。 -- Zoomで受信Webhookチャットボットを追加および設定するには、Zoomアカウントの管理者権限が必要です。 +- Zoomで受信Webhookチャットボットを追加および設定するには、Zoomアカウントの管理者権限が必要です。 -- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象プロジェクトへの`Project Owner`アクセス権が必要です。 +- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象プロジェクトへの`Project Owner`アクセス権が必要です。 -- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象インスタンスへの`Project Owner`または`Instance Manager`アクセス権が必要です。 +- TiDB Cloudのアラート通知を購読するには、組織への`Organization Owner`アクセス権、またはTiDB Cloudの対象インスタンスへの`Project Owner`または`Instance Manager`アクセス権が必要です。 @@ -33,28 +33,28 @@ 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)ページに移動し、 **Add**をクリックしてこのアプリを追加します。アプリが事前承認されていない場合は、Zoom 管理者に連絡して、アカウントに対してこのアプリを承認してもらいます。詳細については、 [アプリの承認とアプリリクエストの管理](https://support.zoom.us/hc/en-us/articles/360027829671)を参照してください。 -3. アプリが必要とする権限を確認し、 **Authorize**をクリックして受信Webhookアプリを追加します。 +1. [Zoomアプリマーケットプレイス](https://marketplace.zoom.us/)にアカウント管理者としてサインインします。 +2. Zoom App Marketplaceの[受信Webhookアプリ](https://marketplace.zoom.us/apps/eH_dLuquRd-VYcOsNGy-hQ)ページに移動し、 **Add**をクリックしてこのアプリを追加します。アプリが事前承認されていない場合は、Zoom 管理者に連絡して、アカウントに対してこのアプリを承認してもらいます。詳細については、 [アプリの承認とアプリリクエストの管理](https://support.zoom.us/hc/en-us/articles/360027829671)を参照してください。 +3. アプリが必要とする権限を確認し、 **Authorize**をクリックして受信Webhookアプリを追加します。 ### ステップ2. ZoomのWebhook URLを生成する {#step-2-generate-a-zoom-webhook-url} -1. Zoomデスクトップクライアントにサインインしてください。 +1. Zoomデスクトップクライアントにサインインしてください。 -2. **Team Chat**タブをクリックしてください。 +2. **Team Chat**タブをクリックしてください。 -3. **Apps**の下にある**Incoming Webhook**を見つけて選択するか、上記からメッセージを受信したいチャットチャネルを選択してください。 +3. **Apps**の下にある**Incoming Webhook**を見つけて選択するか、上記からメッセージを受信したいチャットチャネルを選択してください。 -4. 新しい接続を作成するには、次のコマンドを入力してください。 `${connectionName}`部分を、接続したい名前（例： `tidbcloud-alerts`に置き換えてください。 +4. 新しい接続を作成するには、次のコマンドを入力してください。 `${connectionName}`部分を、接続したい名前（例： `tidbcloud-alerts`に置き換えてください。 ```shell /inc connect ${connectionName} ``` -5. このコマンドを実行すると、以下の詳細情報が返されます。 +5. このコマンドを実行すると、以下の詳細情報が返されます。 - - **Endpoint**。次の形式のウェブフック URL が提供されます: `https://integrations.zoom.us/chat/webhooks/incomingwebhook/XXXXXXXXXXXXXXXXXXXXXXXX` 。 - - **Verification Token** + - **Endpoint**。次の形式のウェブフック URL が提供されます: `https://integrations.zoom.us/chat/webhooks/incomingwebhook/XXXXXXXXXXXXXXXXXXXXXXXX` 。 + - **Verification Token** ### ステップ3. TiDB Cloudから購読する {#step-3-subscribe-from-tidb-cloud} @@ -68,24 +68,24 @@ TiDB Cloud Dedicatedクラスターのアラート通知を購読するには、 > > TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスタがある場合でも、購読は一度だけで済みます。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションペインで、 **Alert Subscription**の下にある**Project Settings**をクリックします。 +3. 左側のナビゲーションペインで、 **Alert Subscription**の下にある**Project Settings**をクリックします。 -4. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +4. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -5. **購読者タイプの**ドロップダウンリストから**Zoom**を選択してください。 +5. **購読者タイプの**ドロップダウンリストから**Zoom**を選択してください。 -6. **Name**欄に名前を、 **URL**欄にZoomのWebhook URLを、 **Token**欄に認証トークンを入力してください。 +6. **Name**欄に名前を、 **URL**欄にZoomのWebhook URLを、 **Token**欄に認証トークンを入力してください。 -7. **Test Connection**をクリックしてください。 +7. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージに従ってトラブルシューティングを行い、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージに従ってトラブルシューティングを行い、接続を再試行してください。 -8. 購読を完了するには、 **Save**をクリックしてください。 +8. 購読を完了するには、 **Save**をクリックしてください。 または、対象のTiDB Cloud Dedicatedクラスタの**アラート**ページの右上にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -101,22 +101,22 @@ TiDB Cloud Essentialインスタンスのアラート通知を購読するには > > TiDB Cloud Essentialの場合、アラートの購読は現在のインスタンス内のすべてのアラートに適用されます。複数のTiDB Cloud Essentialインスタンスをお持ちの場合は、各インスタンスごとに個別に購読する必要があります。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -4. **購読者タイプの**ドロップダウンリストから**Zoom**を選択してください。 +4. **購読者タイプの**ドロップダウンリストから**Zoom**を選択してください。 -5. **Name**欄に名前を、 **URL**欄にZoomのWebhook URLを、 **Token**欄に認証トークンを入力してください。 +5. **Name**欄に名前を、 **URL**欄にZoomのWebhook URLを、 **Token**欄に認証トークンを入力してください。 -6. **Test Connection**をクリックしてください。 +6. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 -7. 購読を完了するには、 **Save**をクリックしてください。 +7. 購読を完了するには、 **Save**をクリックしてください。 または、対象のTiDB Cloud Essentialインスタンスの**アラート**ページの右上隅にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -130,22 +130,22 @@ TiDB Cloud Premiumインスタンスのアラート通知を購読するには > > TiDB Cloud Premiumの場合、アラートの購読は現在のインスタンス内のすべてのアラートに適用されます。複数のTiDB Cloud Premiumインスタンスをお持ちの場合は、各インスタンスごとに個別に購読する必要があります。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 +3. **Alert Subscription**ページで、右上隅にある**Add Subscriber**をクリックします。 -4. **購読者タイプの**ドロップダウンリストから**Zoom**を選択してください。 +4. **購読者タイプの**ドロップダウンリストから**Zoom**を選択してください。 -5. **Name**欄に名前を、 **URL**欄にZoomのWebhook URLを、 **Token**欄に認証トークンを入力してください。 +5. **Name**欄に名前を、 **URL**欄にZoomのWebhook URLを、 **Token**欄に認証トークンを入力してください。 -6. **Test Connection**をクリックしてください。 +6. **Test Connection**をクリックしてください。 - - テストが成功すると、**Save**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 + - テストが成功すると、**Save**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージの指示に従って問題を解決し、接続を再試行してください。 -7. 購読を完了するには、 **Save**をクリックしてください。 +7. 購読を完了するには、 **Save**をクリックしてください。 または、対象のTiDB Cloud Premiumインスタンスの**アラート**ページの右上にある**Subscribe**をクリックすることもできます。**Alert Subscription**ページに移動します。 @@ -159,28 +159,28 @@ TiDB Cloud Premiumインスタンスのアラート通知を購読するには -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Alert Subscription**をクリックします。 -4. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 -5. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Alert Subscription**をクリックします。 +4. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 +5. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 -4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Essentialインスタンスの名前をクリックして、その概要ページに移動します。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 +4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 -3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 -4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Premiumインスタンスの名前をクリックして、その概要ページに移動します。 +2. 左側のナビゲーションペインで、 **Settings** > **Alert Subscription**をクリックします。 +3. **Alert Subscription**ページで、削除する対象の購読者の行を見つけて、 **[...]** > **Unsubscribe**をクリックします。 +4. 購読解除を確定するには、 **Unsubscribe**をクリックしてください。 diff --git a/tidb-cloud/monitor-built-in-alerting.md b/tidb-cloud/monitor-built-in-alerting.md index 2bcfac4c89efc..bf3b8d640fc2f 100644 --- a/tidb-cloud/monitor-built-in-alerting.md +++ b/tidb-cloud/monitor-built-in-alerting.md @@ -19,19 +19,19 @@ TiDB Cloud を使用すると、アラートの表示、アラートルールの TiDB Cloudでは、**Alerts**ページでアクティブなアラートとクローズされたアラートの両方を表示できます。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 対象のTiDB Cloud EssentialインスタンスまたはTiDB Cloud Dedicatedクラスタの名前をクリックすると、その概要ページに移動します。 +2. 対象のTiDB Cloud EssentialインスタンスまたはTiDB Cloud Dedicatedクラスタの名前をクリックすると、その概要ページに移動します。 -3. 左側のナビゲーションペインにある**Alerts**をクリックします。 +3. 左側のナビゲーションペインにある**Alerts**をクリックします。 -4. **Alerts**ページには、デフォルトで有効なアラートが表示されます。各アラートについて、アラート名、トリガー時刻、期間などの情報を確認できます。 +4. **Alerts**ページには、デフォルトで有効なアラートが表示されます。各アラートについて、アラート名、トリガー時刻、期間などの情報を確認できます。 -5. 解決済みの警告も表示したい場合は、**Status**のドロップダウンリストをクリックして、 **Closed**または**All**を選択してください。 +5. 解決済みの警告も表示したい場合は、**Status**のドロップダウンリストをクリックして、 **Closed**または**All**を選択してください。 @@ -39,19 +39,19 @@ TiDB Cloudでは、**Alerts**ページでアクティブなアラートとクロ TiDB Cloudでは、**Alerts**ページでアクティブなアラートとクローズされたアラートの両方を表示できます。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 対象のTiDB Cloud Premiumインスタンスの名前をクリックすると、その概要ページに移動します。 +2. 対象のTiDB Cloud Premiumインスタンスの名前をクリックすると、その概要ページに移動します。 -3. 左側のナビゲーションペインにある**Alerts**をクリックします。 +3. 左側のナビゲーションペインにある**Alerts**をクリックします。 -4. **Alerts**ページには、デフォルトで有効なアラートが表示されます。各アラートについて、アラート名、トリガー時刻、期間などの情報を確認できます。 +4. **Alerts**ページには、デフォルトで有効なアラートが表示されます。各アラートについて、アラート名、トリガー時刻、期間などの情報を確認できます。 -5. 解決済みの警告も表示したい場合は、**Status**のドロップダウンリストをクリックして、 **Closed**または**All**を選択してください。 +5. 解決済みの警告も表示したい場合は、**Status**のドロップダウンリストをクリックして、 **Closed**または**All**を選択してください。 @@ -59,9 +59,9 @@ TiDB Cloudでは、**Alerts**ページでアクティブなアラートとクロ TiDB Cloudでは、アラートを無効化または有効化したり、アラートのしきい値を更新したりすることで、アラートルールを編集できます。 -1. **Alerts**ページで、 **Edit Rules**をクリックします。 -2. 必要に応じてアラートルールを無効化または有効化してください。 -3. アラートルールのしきい値を更新するには、 **Edit**をクリックします。 +1. **Alerts**ページで、 **Edit Rules**をクリックします。 +2. 必要に応じてアラートルールを無効化または有効化してください。 +3. アラートルールのしきい値を更新するには、 **Edit**をクリックします。 > **Tip:** > @@ -71,13 +71,13 @@ TiDB Cloudでは、アラートを無効化または有効化したり、アラ TiDB Cloudでは、以下のいずれかの方法でアラート通知を購読できます。 -- [メール](/tidb-cloud/monitor-alert-email.md) -- [Slack](/tidb-cloud/monitor-alert-slack.md) -- [Zoom](/tidb-cloud/monitor-alert-zoom.md) -- [FlashDuty](/tidb-cloud/monitor-alert-flashduty.md) -- [PagerDuty](/tidb-cloud/monitor-alert-pagerduty.md) -- [Webhook](/tidb-cloud/monitor-alert-webhook.md) -- [Lark](/tidb-cloud/monitor-alert-lark.md) +- [メール](/tidb-cloud/monitor-alert-email.md) +- [Slack](/tidb-cloud/monitor-alert-slack.md) +- [Zoom](/tidb-cloud/monitor-alert-zoom.md) +- [FlashDuty](/tidb-cloud/monitor-alert-flashduty.md) +- [PagerDuty](/tidb-cloud/monitor-alert-pagerduty.md) +- [Webhook](/tidb-cloud/monitor-alert-webhook.md) +- [Lark](/tidb-cloud/monitor-alert-lark.md) ## TiDB Cloudに組み込まれたアラート条件 {#tidb-cloud-built-in-alert-conditions} @@ -85,9 +85,9 @@ TiDB Cloudでは、以下のいずれかの方法でアラート通知を購読 > **Note:** > -> - これらの警戒状態は必ずしも問題が発生していることを意味するものではありませんが、多くの場合、新たな問題が発生する兆候を示しています。したがって、推奨される対策を講じることをお勧めします。 -> - TiDB Cloudコンソールでアラートのしきい値を編集できます。 -> - 一部のアラートルールはデフォルトで無効になっています。必要に応じて有効にすることができます。 +> - これらの警戒状態は必ずしも問題が発生していることを意味するものではありませんが、多くの場合、新たな問題が発生する兆候を示しています。したがって、推奨される対策を講じることをお勧めします。 +> - TiDB Cloudコンソールでアラートのしきい値を編集できます。 +> - 一部のアラートルールはデフォルトで無効になっています。必要に応じて有効にすることができます。 TiDB Cloudは、そのプランで利用可能[特徴](/tidb-cloud/features.md)に基づいて、 [TiDB Cloudプラン](/tidb-cloud/select-cluster-tier.md)ごとに異なるアラート ルールを提供します。 diff --git a/tidb-cloud/monitor-datadog-integration.md b/tidb-cloud/monitor-datadog-integration.md index 4c72f1fc4131c..4ebd578ee529c 100644 --- a/tidb-cloud/monitor-datadog-integration.md +++ b/tidb-cloud/monitor-datadog-integration.md @@ -19,24 +19,24 @@ TiDB CloudはDatadogとの連携をサポートしています。TiDB Cloudを TiDB Cloudは、2022年3月4日よりプロジェクトレベルのDatadog統合（ベータ版）をサポートしてきました。2025年7月31日より、TiDB CloudレベルのDatadog統合（PREVIEW）を導入します。2025年9月30日より、クラスターレベルのDatadog統合が一般提供（GA）となります。 -- **クラスタレベルのDatadog統合**：2025年7月31日までに組織内に削除されていない従来のプロジェクトレベルのDatadogまたはNew Relic統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスタレベルのDatadog統合を提供します。 -- **従来のプロジェクトレベルの Datadog 統合 (ベータ版)** : 2025 年 7 月 31 日時点で組織内に少なくとも 1 つの従来のプロジェクトレベルの Datadog または New Relic 統合が削除されずに残っている場合、 TiDB Cloudは、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。従来のプロジェクトレベルの Datadog 統合は、2025 年 10 月 31 日に廃止されました。組織がこれらの従来の統合をまだ使用している場合は、[DatadogとNew Relicの統合を移行する](/tidb-cloud/migrate-metrics-integrations.md)手順に従って、新しいクラスタレベルの統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 +- **クラスタレベルのDatadog統合**：2025年7月31日までに組織内に削除されていない従来のプロジェクトレベルのDatadogまたはNew Relic統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスタレベルのDatadog統合を提供します。 +- **従来のプロジェクトレベルの Datadog 統合 (ベータ版)** : 2025 年 7 月 31 日時点で組織内に少なくとも 1 つの従来のプロジェクトレベルの Datadog または New Relic 統合が削除されずに残っている場合、 TiDB Cloudは、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。従来のプロジェクトレベルの Datadog 統合は、2025 年 10 月 31 日に廃止されました。組織がこれらの従来の統合をまだ使用している場合は、[DatadogとNew Relicの統合を移行する](/tidb-cloud/migrate-metrics-integrations.md)手順に従って、新しいクラスタレベルの統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 ## 前提条件 {#prerequisites} -- TiDB CloudをDatadogと連携させるには、Datadogアカウントと[Datadog APIキー](https://app.datadoghq.com/organization-settings/api-keys)必要です。Datadogアカウントを初めて作成すると、DatadogからAPIキーが発行されます。 +- TiDB CloudをDatadogと連携させるには、Datadogアカウントと[Datadog APIキー](https://app.datadoghq.com/organization-settings/api-keys)必要です。Datadogアカウントを初めて作成すると、DatadogからAPIキーが発行されます。 Datadogアカウントをお持ちでない場合は、 [https://app.datadoghq.com/signup](https://app.datadoghq.com/signup)でサインアップしてください。 -- TiDB Cloudのサードパーティ メトリクス統合を設定するには、 TiDB Cloudで`Organization Owner`または`Project Owner`アクセス権が必要です。統合ページを表示したり、提供されたリンクから設定済みのダッシュボードにアクセスしたりするには、TiDB Cloudのプロジェクト内の対象のTiDB Cloud Dedicatedクラスターにアクセスするための`Project Viewer`ロール以上が必要です。 +- TiDB Cloudのサードパーティ メトリクス統合を設定するには、 TiDB Cloudで`Organization Owner`または`Project Owner`アクセス権が必要です。統合ページを表示したり、提供されたリンクから設定済みのダッシュボードにアクセスしたりするには、TiDB Cloudのプロジェクト内の対象のTiDB Cloud Dedicatedクラスターにアクセスするための`Project Viewer`ロール以上が必要です。 ## 制限 {#limitations} -- Datadog統合は、[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)インスタンスでは利用できません。 +- Datadog統合は、[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)インスタンスでは利用できません。 -- クラスターの状態が**CREATING** 、 **RESTORING** 、 **PAUSED** 、 **RESUMING**の場合は、Datadog の統合は利用できません。 +- クラスターの状態が**CREATING** 、 **RESTORING** 、 **PAUSED** 、 **RESUMING**の場合は、Datadog の統合は利用できません。 -- Datadogとの統合が設定されているクラスターが削除されると、それに関連付けられている統合サービスも削除されます。 +- Datadogとの統合が設定されているクラスターが削除されると、それに関連付けられている統合サービスも削除されます。 ## 手順 {#steps} @@ -47,40 +47,40 @@ TiDB Cloudは、2022年3月4日よりプロジェクトレベルのDatadog統合
-1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして、その概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Integrations**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Integrations**をクリックします。 -3. **Integrations**ページで、 **Integration to Datadog**をクリックします。 +3. **Integrations**ページで、 **Integration to Datadog**をクリックします。 -4. Datadog APIキーを入力し、Datadogサイトを選択してください。 +4. Datadog APIキーを入力し、Datadogサイトを選択してください。 -5. **Test Integration**をクリックします。 +5. **Test Integration**をクリックします。 - - テストが成功すると、 **Confirm**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージに従ってトラブルシューティングを行い、統合を再試行してください。 + - テストが成功すると、 **Confirm**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージに従ってトラブルシューティングを行い、統合を再試行してください。 -6. 統合を完了するには、 **Confirm**をクリックしてください。 +6. 統合を完了するには、 **Confirm**をクリックしてください。
-1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Project Settings**をクリックします。 +3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Project Settings**をクリックします。 -4. **Integrations**ページで、 **Integration to Datadog (BETA)**をクリックします。 +4. **Integrations**ページで、 **Integration to Datadog (BETA)**をクリックします。 -5. Datadog APIキーを入力し、Datadogサイトを選択してください。 +5. Datadog APIキーを入力し、Datadogサイトを選択してください。 -6. **Test Integration**をクリックします。 +6. **Test Integration**をクリックします。 - - テストが成功すると、 **Confirm**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージに従ってトラブルシューティングを行い、統合を再試行してください。 + - テストが成功すると、 **Confirm**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージに従ってトラブルシューティングを行い、統合を再試行してください。 -7. 統合を完了するには、 **Confirm**をクリックしてください。 +7. 統合を完了するには、 **Confirm**をクリックしてください。
@@ -91,20 +91,20 @@ TiDB Cloudは、2022年3月4日よりプロジェクトレベルのDatadog統合 > > Datadog にTiDB Cloud統合をすでにインストールしている場合は、このセクションの次の手順をスキップできます。 [**TiDB Cloud Dynamic Tracker**](https://app.datadoghq.com/dash/integration/32021/tidb-cloud-dynamic-tracker)または[**TiDB Cloud Cluster Overview**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview)ダッシュボードは、Datadog [**Dashboard List**](https://app.datadoghq.com/dashboard/lists)で自動的に利用可能になります。 -1. [Datadog](https://app.datadoghq.com)にログインします。 -2. Datadog の[**TiDB Cloud統合**ページ](https://app.datadoghq.com/account/settings#integrations/tidb-cloud)に移動します。 -3. **Configuration**タブで、 **Install Integration**をクリックします。 +1. [Datadog](https://app.datadoghq.com)にログインします。 +2. Datadog の[**TiDB Cloud統合**ページ](https://app.datadoghq.com/account/settings#integrations/tidb-cloud)に移動します。 +3. **Configuration**タブで、 **Install Integration**をクリックします。 - - クラスターレベルの Datadog 統合の場合、 [**TiDB Cloud Dynamic Tracker**](https://app.datadoghq.com/dash/integration/32021/tidb-cloud-dynamic-tracker)ダッシュボードが[**Dashboard List**](https://app.datadoghq.com/dashboard/lists)に表示されます。 - - 従来のプロジェクト レベルの Datadog 統合 (ベータ版) の場合、 [**TiDB Cloud Cluster Overview**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview)ダッシュボードが[**Dashboard List**](https://app.datadoghq.com/dashboard/lists)に表示されます。 + - クラスターレベルの Datadog 統合の場合、 [**TiDB Cloud Dynamic Tracker**](https://app.datadoghq.com/dash/integration/32021/tidb-cloud-dynamic-tracker)ダッシュボードが[**Dashboard List**](https://app.datadoghq.com/dashboard/lists)に表示されます。 + - 従来のプロジェクト レベルの Datadog 統合 (ベータ版) の場合、 [**TiDB Cloud Cluster Overview**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview)ダッシュボードが[**Dashboard List**](https://app.datadoghq.com/dashboard/lists)に表示されます。 ## 事前に構築されたダッシュボードを確認する {#view-the-pre-built-dashboard} -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、 **Integrations**ページに移動します。 -2. **Datadog**セクションの**Dashboard**リンクをクリックしてください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、 **Integrations**ページに移動します。 +2. **Datadog**セクションの**Dashboard**リンクをクリックしてください。 - - クラスタレベルのDatadog統合の場合、**Dashboard**リンクをクリックすると、拡張バージョンで導入された最新のメトリクスを含む新しいダッシュボードが開きます。 - - 従来のプロジェクトレベルのDatadog統合（ベータ版）の場合、**Dashboard**リンクをクリックすると従来のダッシュボードが開きますが、そこにはクラスタレベルのDatadog統合で導入された最新のメトリクスは含まれていません。 + - クラスタレベルのDatadog統合の場合、**Dashboard**リンクをクリックすると、拡張バージョンで導入された最新のメトリクスを含む新しいダッシュボードが開きます。 + - 従来のプロジェクトレベルのDatadog統合（ベータ版）の場合、**Dashboard**リンクをクリックすると従来のダッシュボードが開きますが、そこにはクラスタレベルのDatadog統合で導入された最新のメトリクスは含まれていません。 ## Datadogで利用可能な指標 {#metrics-available-to-datadog} diff --git a/tidb-cloud/monitor-new-relic-integration.md b/tidb-cloud/monitor-new-relic-integration.md index 73dad6835787e..da85c3b81a67b 100644 --- a/tidb-cloud/monitor-new-relic-integration.md +++ b/tidb-cloud/monitor-new-relic-integration.md @@ -11,24 +11,24 @@ TiDB CloudはNew Relicとの連携をサポートしています。TiDB Cloudを TiDB Cloudは、2023年4月11日よりプロジェクトレベルのNew Relic統合（ベータ版）をサポートしてきました。2025年7月31日より、TiDB CloudレベルのNew Relic統合（PREVIEW）を導入します。2025年9月30日より、クラスターレベルのNew Relic統合が一般提供（GA）となります。 -- **クラスタレベルのNew Relic統合**：2025年7月31日までに組織内で削除されていない従来のプロジェクトレベルのDatadogまたはNew Relic統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスタレベルのNew Relic統合を提供します。 -- **従来のプロジェクトレベルの New Relic 統合 (ベータ版)** : 2025 年 7 月 31 日時点で組織内に少なくとも 1 つの従来のプロジェクトレベルの Datadog または New Relic 統合が削除されずに残っている場合、 TiDB Cloud は、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。従来のプロジェクトレベルの New Relic 統合は、2025 年 10 月 31 日に廃止されました。組織がこれらの従来の統合をまだ使用している場合は、[DatadogとNew Relicの統合を移行する](/tidb-cloud/migrate-metrics-integrations.md)手順に従って、新しいクラスタレベルの統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 +- **クラスタレベルのNew Relic統合**：2025年7月31日までに組織内で削除されていない従来のプロジェクトレベルのDatadogまたはNew Relic統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスタレベルのNew Relic統合を提供します。 +- **従来のプロジェクトレベルの New Relic 統合 (ベータ版)** : 2025 年 7 月 31 日時点で組織内に少なくとも 1 つの従来のプロジェクトレベルの Datadog または New Relic 統合が削除されずに残っている場合、 TiDB Cloud は、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。従来のプロジェクトレベルの New Relic 統合は、2025 年 10 月 31 日に廃止されました。組織がこれらの従来の統合をまだ使用している場合は、[DatadogとNew Relicの統合を移行する](/tidb-cloud/migrate-metrics-integrations.md)手順に従って、新しいクラスタレベルの統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 ## 前提条件 {#prerequisites} -- TiDB Cloud をNew Relic と統合するには、[New Relic](https://newrelic.com/)アカウントと、 `Ingest - License`タイプの[New Relic APIキーを作成する](https://one.newrelic.com/admin-portal/api-keys/home?)必要があります。 +- TiDB Cloud をNew Relic と統合するには、[New Relic](https://newrelic.com/)アカウントと、 `Ingest - License`タイプの[New Relic APIキーを作成する](https://one.newrelic.com/admin-portal/api-keys/home?)必要があります。 New Relicのアカウントをお持ちでない場合は、[ここ](https://newrelic.com/signup)ご登録ください。 -- TiDB Cloudのサードパーティ メトリクス統合を設定するには、 TiDB Cloudで`Organization Owner`または`Project Owner`アクセス権が必要です。統合ページを表示したり、提供されたリンクから設定済みのダッシュボードにアクセスしたりするには、TiDB Cloudのプロジェクト内の対象のTiDB Cloud Dedicatedクラスターにアクセスするための`Project Viewer`ロール以上が必要です。 +- TiDB Cloudのサードパーティ メトリクス統合を設定するには、 TiDB Cloudで`Organization Owner`または`Project Owner`アクセス権が必要です。統合ページを表示したり、提供されたリンクから設定済みのダッシュボードにアクセスしたりするには、TiDB Cloudのプロジェクト内の対象のTiDB Cloud Dedicatedクラスターにアクセスするための`Project Viewer`ロール以上が必要です。 ## 制限 {#limitation} -- New Relicとの連携機能は、現在[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでのみ利用可能です。 +- New Relicとの連携機能は、現在[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでのみ利用可能です。 -- クラスターの状態が**CREATING** 、 **RESTORING** 、 **PAUSED** 、 **RESUMING**の場合は、New Relic の統合は利用できません。 +- クラスターの状態が**CREATING** 、 **RESTORING** 、 **PAUSED** 、 **RESUMING**の場合は、New Relic の統合は利用できません。 -- New Relicとの連携が確立されたクラスターが削除されると、それに関連付けられた連携サービスも削除されます。 +- New Relicとの連携が確立されたクラスターが削除されると、それに関連付けられた連携サービスも削除されます。 ## 手順 {#steps} @@ -39,40 +39,40 @@ TiDB Cloudは、2023年4月11日よりプロジェクトレベルのNew Relic統
-1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして、その概要ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Integrations**をクリックします。 +2. 左側のナビゲーションペインで、 **Settings** > **Integrations**をクリックします。 -3. **Integrations**ページで、 **Integration to New Relic**をクリックします。 +3. **Integrations**ページで、 **Integration to New Relic**をクリックします。 -4. New RelicのAPIキーを入力し、New Relicのサイトを選択してください。 +4. New RelicのAPIキーを入力し、New Relicのサイトを選択してください。 -5. **Test Integration**をクリックします。 +5. **Test Integration**をクリックします。 - - テストが成功すると、 **Confirm**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージに従ってトラブルシューティングを行い、統合を再試行してください。 + - テストが成功すると、 **Confirm**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージに従ってトラブルシューティングを行い、統合を再試行してください。 -6. 統合を完了するには、 **Confirm**をクリックしてください。 +6. 統合を完了するには、 **Confirm**をクリックしてください。
-1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Project Settings**をクリックします。 +3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Project Settings**をクリックします。 -4. **Integrations**ページで、 **[New Relic との統合 (ベータ版)]**をクリックします。 +4. **Integrations**ページで、 **[New Relic との統合 (ベータ版)]**をクリックします。 -5. New RelicのAPIキーを入力し、New Relicのサイトを選択してください。 +5. New RelicのAPIキーを入力し、New Relicのサイトを選択してください。 -6. **Test Integration**をクリックします。 +6. **Test Integration**をクリックします。 - - テストが成功すると、 **Confirm**ボタンが表示されます。 - - テストが失敗した場合は、エラーメッセージが表示されます。メッセージに従ってトラブルシューティングを行い、統合を再試行してください。 + - テストが成功すると、 **Confirm**ボタンが表示されます。 + - テストが失敗した場合は、エラーメッセージが表示されます。メッセージに従ってトラブルシューティングを行い、統合を再試行してください。 -7. 統合を完了するには、 **Confirm**をクリックしてください。 +7. 統合を完了するには、 **Confirm**をクリックしてください。
@@ -86,11 +86,11 @@ TiDB Cloudは、2023年4月11日よりプロジェクトレベルのNew Relic統 新しいTiDB Cloudダッシュボードは、保留中の[広報](https://github.com/newrelic/newrelic-quickstarts/pull/2681)New Relicによってマージされた後にNew Relicで利用可能になります。それまでは、以下の手順でダッシュボードをNew Relicに手動でインポートできます。 -1. 新しいダッシュボード用のJSONファイルを準備します。 +1. 新しいダッシュボード用のJSONファイルを準備します。 - 1. テンプレートの JSON ファイルを[ここ](https://github.com/pingcap/diag/blob/integration/integration/dashboards/newrelic-dashboard.json)ダウンロードします。 + 1. テンプレートの JSON ファイルを[ここ](https://github.com/pingcap/diag/blob/integration/integration/dashboards/newrelic-dashboard.json)ダウンロードします。 - 2. JSONファイルで、4行目に`"permissions": "PUBLIC_READ_WRITE"`以下のように追加します。 + 2. JSONファイルで、4行目に`"permissions": "PUBLIC_READ_WRITE"`以下のように追加します。 ```json { @@ -101,7 +101,7 @@ TiDB Cloudは、2023年4月11日よりプロジェクトレベルのNew Relic統 } ``` - 3. JSON ファイル内のすべての`"accountIds": []`フィールドに New Relic アカウント ID を追加してください。 + 3. JSON ファイル内のすべての`"accountIds": []`フィールドに New Relic アカウント ID を追加してください。 例えば： @@ -115,30 +115,30 @@ TiDB Cloudは、2023年4月11日よりプロジェクトレベルのNew Relic統 > > 統合エラーを回避するために、JSON ファイル内のすべての`"accountIds"`フィールドにアカウント ID が追加されていることを確認してください。 -2. [New Relic](https://one.newrelic.com/)にログインし、左側のナビゲーションバーの**Dashboards**をクリックし、右上隅の**Import dashboard**をクリックします。 +2. [New Relic](https://one.newrelic.com/)にログインし、左側のナビゲーションバーの**Dashboards**をクリックし、右上隅の**Import dashboard**をクリックします。 -3. 表示されたダイアログで、準備した JSON ファイルの内容をすべてテキスト エリアに貼り付け、次に**Import dashboard**をクリックします。 +3. 表示されたダイアログで、準備した JSON ファイルの内容をすべてテキスト エリアに貼り付け、次に**Import dashboard**をクリックします。
-1. [New Relic](https://one.newrelic.com/)にログインします。 -2. **Add Data**をクリックし、 `TiDB Cloud`を検索して、 **TiDB Cloud Monitoring**ページに移動します。または、 [リンク](https://one.newrelic.com/marketplace?state=79bf274b-0c01-7960-c85c-3046ca96568e)クリックして直接ページにアクセスすることもできます。 -3. アカウントIDを選択し、New Relicでダッシュボードを作成してください。 +1. [New Relic](https://one.newrelic.com/)にログインします。 +2. **Add Data**をクリックし、 `TiDB Cloud`を検索して、 **TiDB Cloud Monitoring**ページに移動します。または、 [リンク](https://one.newrelic.com/marketplace?state=79bf274b-0c01-7960-c85c-3046ca96568e)クリックして直接ページにアクセスすることもできます。 +3. アカウントIDを選択し、New Relicでダッシュボードを作成してください。
## 事前に構築されたダッシュボードを確認する {#view-the-pre-built-dashboard} -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、 **Integrations**ページに移動します。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、 **Integrations**ページに移動します。 -2. **New Relic**セクションの**New Relic**リンクをクリックすると、TiDBクラスターの事前構築済みダッシュボードが表示されます。 +2. **New Relic**セクションの**New Relic**リンクをクリックすると、TiDBクラスターの事前構築済みダッシュボードが表示されます。 -3. [新しいRelic統合バージョン](#new-relic-integration-version)に応じて、次のいずれかを実行します。 +3. [新しいRelic統合バージョン](#new-relic-integration-version)に応じて、次のいずれかを実行します。 - - クラスタレベルでのNew Relic統合を行うには、 **TiDB Cloud Dynamic Tracker**をクリックして新しいダッシュボードを表示してください。 - - 従来のプロジェクトレベルのNew Relic統合（ベータ版）については、 **TiDB Cloud Monitoring**をクリックして従来のダッシュボードを表示してください。 + - クラスタレベルでのNew Relic統合を行うには、 **TiDB Cloud Dynamic Tracker**をクリックして新しいダッシュボードを表示してください。 + - 従来のプロジェクトレベルのNew Relic統合（ベータ版）については、 **TiDB Cloud Monitoring**をクリックして従来のダッシュボードを表示してください。 ## New Relicで利用可能なメトリクス {#metrics-available-to-new-relic} diff --git a/tidb-cloud/monitor-prometheus-and-grafana-integration.md b/tidb-cloud/monitor-prometheus-and-grafana-integration.md index 561e276289047..a42f1bcdd7a27 100644 --- a/tidb-cloud/monitor-prometheus-and-grafana-integration.md +++ b/tidb-cloud/monitor-prometheus-and-grafana-integration.md @@ -13,9 +13,9 @@ TiDB Cloudは[Prometheus](https://prometheus.io/)APIエンドポイントを提 TiDB Cloudは、2022年3月15日よりプロジェクトレベルのPrometheus統合（ベータ版）をサポートしてきました。2025年10月21日より、TiDB CloudレベルのPrometheus統合（PREVIEW）を導入します。2025年12月2日より、クラスターレベルのPrometheus統合が一般提供（GA）となります。 -- **クラスタレベルのPrometheus統合**：2025年10月21日までに組織内に削除されていない従来のプロジェクトレベルのPrometheus統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスタレベルのPrometheus統合を提供します。 +- **クラスタレベルのPrometheus統合**：2025年10月21日までに組織内に削除されていない従来のプロジェクトレベルのPrometheus統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスタレベルのPrometheus統合を提供します。 -- **従来のプロジェクトレベルの Prometheus 統合 (ベータ版)** : 2025 年 10 月 21 日時点で組織内に少なくとも 1 つの従来のプロジェクトレベルの Prometheus 統合が削除されずに残っている場合、 TiDB Cloud は、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。 +- **従来のプロジェクトレベルの Prometheus 統合 (ベータ版)** : 2025 年 10 月 21 日時点で組織内に少なくとも 1 つの従来のプロジェクトレベルの Prometheus 統合が削除されずに残っている場合、 TiDB Cloud は、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。 > **Note** > @@ -23,14 +23,14 @@ TiDB Cloudは、2022年3月15日よりプロジェクトレベルのPrometheus ## 前提条件 {#prerequisites} -- TiDB CloudをPrometheusと統合するには、自己ホスト型またはマネージド型のPrometheusサービスが必要です。 +- TiDB CloudをPrometheusと統合するには、自己ホスト型またはマネージド型のPrometheusサービスが必要です。 -- TiDB Cloudのサードパーティ メトリクス統合を設定するには、 TiDB Cloudで`Organization Owner`または`Project Owner`アクセス権が必要です。統合ページを表示するには、 TiDB Cloudのプロジェクト内の対象のTiDB Cloud Dedicatedクラスターにアクセスするための`Project Viewer`ロール以上が必要です。 +- TiDB Cloudのサードパーティ メトリクス統合を設定するには、 TiDB Cloudで`Organization Owner`または`Project Owner`アクセス権が必要です。統合ページを表示するには、 TiDB Cloudのプロジェクト内の対象のTiDB Cloud Dedicatedクラスターにアクセスするための`Project Viewer`ロール以上が必要です。 ## 制限 {#limitation} -- PrometheusとGrafanaの統合機能は、現在[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでのみ利用可能です。 -- クラスターの状態が**CREATING** 、 **RESTORING** 、 **PAUSED** 、または**RESUMING**の場合、Prometheus および Grafana の統合は利用できません。 +- PrometheusとGrafanaの統合機能は、現在[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでのみ利用可能です。 +- クラスターの状態が**CREATING** 、 **RESTORING** 、 **PAUSED** 、または**RESUMING**の場合、Prometheus および Grafana の統合は利用できません。 ## 手順 {#steps} @@ -43,21 +43,21 @@ Prometheus サービスでTiDB Cloudのメトリクスを読み取るように
-1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして、その概要ページに移動します。 -2. 左側のナビゲーションペインで、 **Settings** > **Integrations**をクリックします。 -3. **Integrations**ページで、 **Integration to Prometheus**をクリックします。 -4. **Add File**をクリックすると、現在のクラスター用の`scrape_config`ファイルが生成されて表示されます。 -5. `scrape_config`ファイルの内容のコピーを作成して、後で使用してください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして、その概要ページに移動します。 +2. 左側のナビゲーションペインで、 **Settings** > **Integrations**をクリックします。 +3. **Integrations**ページで、 **Integration to Prometheus**をクリックします。 +4. **Add File**をクリックすると、現在のクラスター用の`scrape_config`ファイルが生成されて表示されます。 +5. `scrape_config`ファイルの内容のコピーを作成して、後で使用してください。
-1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 -2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 -3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Integrations**をクリックします。 -4. **Integrations**ページで、 **Integration to Prometheus (BETA)**をクリックします。 -5. **Add File**をクリックすると、現在のプロジェクトのscrape_configファイルが生成されて表示されます。 -6. `scrape_config`ファイルの内容のコピーを作成して、後で使用できるようにします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **Project view**タブをクリックします。 +2. プロジェクトビューで、対象のプロジェクトを見つけて、そのプロジェクトのをクリックします。 +3. 左側のナビゲーションペインで、 **Project Settings**の下にある**Integrations**をクリックします。 +4. **Integrations**ページで、 **Integration to Prometheus (BETA)**をクリックします。 +5. **Add File**をクリックすると、現在のプロジェクトのscrape_configファイルが生成されて表示されます。 +6. `scrape_config`ファイルの内容のコピーを作成して、後で使用できるようにします。
@@ -68,30 +68,30 @@ Prometheus サービスでTiDB Cloudのメトリクスを読み取るように ### ステップ2．Prometheusとの統合 {#step-2-integrate-with-prometheus} -1. Prometheusサービスで指定された監視ディレクトリ内で、Prometheusの設定ファイルを探してください。 +1. Prometheusサービスで指定された監視ディレクトリ内で、Prometheusの設定ファイルを探してください。 例えば、 `/etc/prometheus/prometheus.yml` 。 -2. Prometheus の設定ファイルで、 `scrape_configs`セクションを探し、 TiDB Cloudから取得した`scrape_config`ファイルの内容をそのセクションにコピーします。 +2. Prometheus の設定ファイルで、 `scrape_configs`セクションを探し、 TiDB Cloudから取得した`scrape_config`ファイルの内容をそのセクションにコピーします。 -3. Prometheusサービスで、 **Status** > **[ターゲット]**を確認し、新しい`scrape_config`ファイルが読み込まれていることを確認してください。読み込まれていない場合は、Prometheusサービスを再起動する必要があるかもしれません。 +3. Prometheusサービスで、 **Status** > **[ターゲット]**を確認し、新しい`scrape_config`ファイルが読み込まれていることを確認してください。読み込まれていない場合は、Prometheusサービスを再起動する必要があるかもしれません。 ### ステップ3. Grafana GUIダッシュボードを使用してメトリクスを視覚化する {#step-3-use-grafana-gui-dashboards-to-visualize-the-metrics} PrometheusサービスがTiDB Cloudからメトリクスを読み取るようになったら、Grafana GUIダッシュボードを使用して、次のようにメトリクスを視覚化できます。 -1. [Prometheus統合バージョン](#prometheus-integration-versions)バージョンに応じて、 TiDB Cloud for Prometheus の Grafana ダッシュボード JSON をダウンロードするリンクは異なります。 +1. [Prometheus統合バージョン](#prometheus-integration-versions)バージョンに応じて、 TiDB Cloud for Prometheus の Grafana ダッシュボード JSON をダウンロードするリンクは異なります。 - - クラスターレベルでのPrometheus統合については、 [ここ](https://github.com/pingcap/docs/blob/master/tidb-cloud/monitor-prometheus-and-grafana-integration-tidb-cloud-dynamic-tracker.json)GrafanaダッシュボードJSONファイルをダウンロードしてください。 - - 従来のプロジェクトレベルでのPrometheus統合（ベータ版）については、 [ここ](https://github.com/pingcap/docs/blob/master/tidb-cloud/monitor-prometheus-and-grafana-integration-grafana-dashboard-UI.json)GrafanaダッシュボードJSONファイルをダウンロードしてください。 + - クラスターレベルでのPrometheus統合については、 [ここ](https://github.com/pingcap/docs/blob/master/tidb-cloud/monitor-prometheus-and-grafana-integration-tidb-cloud-dynamic-tracker.json)GrafanaダッシュボードJSONファイルをダウンロードしてください。 + - 従来のプロジェクトレベルでのPrometheus統合（ベータ版）については、 [ここ](https://github.com/pingcap/docs/blob/master/tidb-cloud/monitor-prometheus-and-grafana-integration-grafana-dashboard-UI.json)GrafanaダッシュボードJSONファイルをダウンロードしてください。 -2. メトリクスを視覚化するには、 [このJSONをGrafana GUIにインポートしてください](https://grafana.com/docs/grafana/v8.5/dashboards/export-import/#import-dashboard) +2. メトリクスを視覚化するには、 [このJSONをGrafana GUIにインポートしてください](https://grafana.com/docs/grafana/v8.5/dashboards/export-import/#import-dashboard) > **Note:** > > 既にPrometheusとGrafanaを使用してTiDB Cloudを監視しており、新たに利用可能になったメトリクスを組み込みたい場合は、既存のダッシュボードのJSONを直接更新するのではなく、新しいダッシュボードを作成することをお勧めします。 -3. （オプション）パネルの追加や削除、データソースの変更、表示オプションの修正などにより、必要に応じてダッシュボードをカスタマイズできます。 +3. （オプション）パネルの追加や削除、データソースの変更、表示オプションの修正などにより、必要に応じてダッシュボードをカスタマイズできます。 Grafana の使用方法の詳細については、 [Grafanaのドキュメント](https://grafana.com/docs/grafana/latest/getting-started/getting-started-prometheus/)を参照してください。 @@ -99,10 +99,10 @@ Grafana の使用方法の詳細については、 [Grafanaのドキュメント データセキュリティを向上させるために、 `scrape_config`ファイルベアラートークンを定期的にローテーションすることが一般的なベストプラクティスです。 -1. [ステップ1](#step-1-get-a-scrape_config-file-for-prometheus)に従って、Prometheus 用の新しい`scrape_config`ファイルを作成します。 -2. 新しいファイルの内容をPrometheusの設定ファイルに追加してください。 -3. Prometheus サービスがTiDB Cloudから引き続き読み取れることを確認したら、Prometheus 設定ファイルから古い`scrape_config`ファイルの内容を削除します。 -4. プロジェクトまたはクラスターの**Integrations**ページで、対応する古い`scrape_config`ファイルを削除して、他のユーザーがTiDB Cloud Prometheus エンドポイントから読み取るために使用できないようにします。 +1. [ステップ1](#step-1-get-a-scrape_config-file-for-prometheus)に従って、Prometheus 用の新しい`scrape_config`ファイルを作成します。 +2. 新しいファイルの内容をPrometheusの設定ファイルに追加してください。 +3. Prometheus サービスがTiDB Cloudから引き続き読み取れることを確認したら、Prometheus 設定ファイルから古い`scrape_config`ファイルの内容を削除します。 +4. プロジェクトまたはクラスターの**Integrations**ページで、対応する古い`scrape_config`ファイルを削除して、他のユーザーがTiDB Cloud Prometheus エンドポイントから読み取るために使用できないようにします。 ## Prometheusで利用可能なメトリクス {#metrics-available-to-prometheus} @@ -144,6 +144,6 @@ Prometheusは、TiDBクラスタに関して以下のメトリックデータを ## FAQ {#faq} -- なぜ同じメトリックが、GrafanaとTiDB Cloudコンソールで同時に異なる値を示すのでしょうか？ +- なぜ同じメトリックが、GrafanaとTiDB Cloudコンソールで同時に異なる値を示すのでしょうか？ GrafanaとTiDB Cloudでは集計計算ロジックが異なるため、表示される集計値が異なる場合があります。より詳細なメトリック値を取得するには、Grafanaの`mini step`設定を調整してください。 diff --git a/tidb-cloud/monitor-tidb-cluster.md b/tidb-cloud/monitor-tidb-cluster.md index b3ee66b409786..72ae5ae66d1fe 100644 --- a/tidb-cloud/monitor-tidb-cluster.md +++ b/tidb-cloud/monitor-tidb-cluster.md @@ -80,8 +80,8 @@ summary: TiDB Cloudリソースの監視方法を学びましょう。 TiDB Cloudでは、次のページから、 TiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスタークラスターの一般的に使用されるメトリクスを表示できます。 -- **Overview**ページ -- **Metrics**ページ +- **Overview**ページ +- **Metrics**ページ ### 概要ページ {#overview-page} @@ -89,13 +89,13 @@ TiDB Cloudでは、次のページから、 TiDB C 概要ページで指標を表示するには、以下の手順に従ってください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象リソースの名前をクリックすると、その概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象リソースの名前をクリックすると、その概要ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. **Core Metrics**セクションを確認してください。 +2. **Core Metrics**セクションを確認してください。 ### 指標ページ {#metrics-page} @@ -103,12 +103,12 @@ TiDB Cloudでは、次のページから、 TiDB C **Metrics**ページで指標を表示するには、以下の手順に従ってください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象リソースの名前をクリックすると、その概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象リソースの名前をクリックすると、その概要ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 左側のナビゲーションペインで、 **Monitoring** > **Metrics**をクリックします。 +2. 左側のナビゲーションペインで、 **Monitoring** > **Metrics**をクリックします。 詳細については、 [TiDB Cloud の組み込みメトリクス](/tidb-cloud/built-in-monitoring.md)を参照してください。 diff --git a/tidb-cloud/monitoring-concepts.md b/tidb-cloud/monitoring-concepts.md index f8e22a2138d03..54c097d1dc651 100644 --- a/tidb-cloud/monitoring-concepts.md +++ b/tidb-cloud/monitoring-concepts.md @@ -26,11 +26,11 @@ TiDB Cloudのモニタリング機能は、TiDBのパフォーマンスを監視 組み込みアラートとは、 TiDB Cloud EssentialインスタンスおよびTiDB Cloud Dedicatedクラスタの監視を支援するためにTiDB Cloudが提供するアラートメカニズムのことです。現在、 TiDB Cloudは以下の3種類のアラートを提供しています。 -- リソース使用状況アラート +- リソース使用状況アラート -- データ移行に関する警告 +- データ移行に関する警告 -- 変更フィードアラート +- 変更フィードアラート TiDB Cloudコンソールの「アラート」ページでは、 TiDB Cloud EssentialインスタンスまたはTiDB Cloud Dedicatedクラスタのアラートを表示したり、アラートルールを編集したり、アラート通知メールを購読したりできます。 @@ -40,8 +40,8 @@ TiDB Cloudコンソールの「アラート」ページでは、 TiDB Cloud Esse TiDB Cloudでは、イベントはTiDB Cloudリソースの変更を示します。 -- TiDB Cloud StarterおよびEssentialインスタンスの場合、 TiDB Cloudはインスタンスレベルで履歴イベントをログに記録します。 -- TiDB Cloud Dedicatedクラスタの場合、 TiDB Cloudはクラスタレベルで履歴イベントをログに記録します。 +- TiDB Cloud StarterおよびEssentialインスタンスの場合、 TiDB Cloudはインスタンスレベルで履歴イベントをログに記録します。 +- TiDB Cloud Dedicatedクラスタの場合、 TiDB Cloudはクラスタレベルで履歴イベントをログに記録します。 **Events**ページでは、イベントの種類、ステータス、メッセージ、トリガー時刻、トリガーユーザーなど、記録されたイベントを確認できます。 @@ -53,11 +53,11 @@ TiDB Cloudでは、イベントはTiDB Cloudリソースの変更を示します TiDB Cloud、以下のサードパーティ製メトリクスサービスのいずれかを統合して、 TiDB Cloudアラートを受信したり、 TiDB Cloud Dedicatedクラスタのパフォーマンスメトリクスを表示したりできます。 -- [Datadogとの連携](/tidb-cloud/monitor-datadog-integration.md) +- [Datadogとの連携](/tidb-cloud/monitor-datadog-integration.md) -- [PrometheusとGrafanaの統合](/tidb-cloud/monitor-prometheus-and-grafana-integration.md) +- [PrometheusとGrafanaの統合](/tidb-cloud/monitor-prometheus-and-grafana-integration.md) -- [New Relicとの連携](/tidb-cloud/monitor-new-relic-integration.md) +- [New Relicとの連携](/tidb-cloud/monitor-new-relic-integration.md) diff --git a/tidb-cloud/naming-conventions-for-data-import.md b/tidb-cloud/naming-conventions-for-data-import.md index d69dcf7397f52..72d2e1253dbf0 100644 --- a/tidb-cloud/naming-conventions-for-data-import.md +++ b/tidb-cloud/naming-conventions-for-data-import.md @@ -7,8 +7,8 @@ summary: データインポート時のCSV、Parquet、 Aurora Snapshot、およ TiDB Cloudには、CSV、Parquet、 Aurora Snapshot、SQLといったファイル形式でデータをインポートできます。データが正常にインポートされるようにするには、以下の2種類のファイルを準備する必要があります。 -- **Schema file**。データベーススキーマファイル（オプション）とテーブルスキーマファイルを、両方ともSQL形式（ `.sql` ）で準備します。テーブルスキーマファイルが提供されていない場合は、対象データベースに該当するテーブルを事前に手動で作成する必要があります。 -- **Data file**。データインポート用の命名規則に準拠したデータファイルを用意してください。データファイル名が要件を満たしていない場合は、[**File Pattern**](#file-pattern)を使用してインポートタスクを実行することをお勧めします。そうしないと、インポートタスクはインポート対象のデータファイルをスキャンできません。 +- **Schema file**。データベーススキーマファイル（オプション）とテーブルスキーマファイルを、両方ともSQL形式（ `.sql` ）で準備します。テーブルスキーマファイルが提供されていない場合は、対象データベースに該当するテーブルを事前に手動で作成する必要があります。 +- **Data file**。データインポート用の命名規則に準拠したデータファイルを用意してください。データファイル名が要件を満たしていない場合は、[**File Pattern**](#file-pattern)を使用してインポートタスクを実行することをお勧めします。そうしないと、インポートタスクはインポート対象のデータファイルをスキャンできません。 ## スキーマファイルの命名規則 {#naming-conventions-for-schema-files} @@ -16,13 +16,13 @@ TiDB Cloudには、CSV、Parquet、 Aurora Snapshot、SQLといったファイ スキーマファイルの命名規則は以下のとおりです。 -- データベーススキーマファイル（オプション）： `${db_name}-schema-create.sql` -- テーブルスキーマファイル: `${db_name}.${table_name}-schema.sql` +- データベーススキーマファイル（オプション）： `${db_name}-schema-create.sql` +- テーブルスキーマファイル: `${db_name}.${table_name}-schema.sql` 以下はデータベーススキーマファイルの例です。 -- 名前: `import_db-schema-create.sql` -- ファイルの内容: +- 名前: `import_db-schema-create.sql` +- ファイルの内容: ```sql CREATE DATABASE import_db; @@ -30,8 +30,8 @@ TiDB Cloudには、CSV、Parquet、 Aurora Snapshot、SQLといったファイ 以下はテーブルスキーマファイルの例です。 -- 名前: `import_db.test_table-schema.sql` -- ファイルの内容: +- 名前: `import_db.test_table-schema.sql` +- ファイルの内容: ```sql CREATE TABLE test_table ( @@ -52,19 +52,19 @@ CSVファイルをインポートする際は、データファイルに以下 `${suffix}`はオプションであり、 *`xxx`*任意の数字で、以下のいずれかの形式になります。 -- *`.xxx`* 、例えば`.01` -- *`._xxx_xxx_xxx`* 、例えば`._0_0_01` -- *`_xxx_xxx_xxx`* 、例えば`_0_0_01` +- *`.xxx`* 、例えば`.01` +- *`._xxx_xxx_xxx`* 、例えば`._0_0_01` +- *`_xxx_xxx_xxx`* 、例えば`_0_0_01` `${compress}`は圧縮フォーマットであり、オプションです。TiDB Cloud は、 `.gzip` 、 `.gz` 、 `.zstd` 、 `.zst` 、および`.snappy` 。 例えば、以下のすべてのファイルのターゲットデータベースとテーブルは`import_db`と`test_table`です。 -- `import_db.test_table.csv` -- `import_db.test_table.01.csv` -- `import_db.test_table._0_0_01.csv` -- `import_db.test_table_0_0_01.csv` -- `import_db.test_table_0_0_01.csv.gz` +- `import_db.test_table.csv` +- `import_db.test_table.01.csv` +- `import_db.test_table._0_0_01.csv` +- `import_db.test_table_0_0_01.csv` +- `import_db.test_table_0_0_01.csv.gz` > **Note:** > @@ -78,8 +78,8 @@ Parquetファイルをインポートする際は、データファイルに以 例えば： -- `import_db.test_table.parquet` -- `import_db.test_table.01.parquet` +- `import_db.test_table.parquet` +- `import_db.test_table.01.parquet` ### Auroraのスナップショット {#aurora-snapshot} @@ -87,9 +87,9 @@ Aurora Snapshot ファイルの場合、 `.parquet`フォルダー内の`${db_na 例えば： -- `import_db.test_table/mydata.parquet` -- `import_db.test_table/part001/mydata.parquet` -- `import_db.test_table/part002/mydata-part002.parquet` +- `import_db.test_table/mydata.parquet` +- `import_db.test_table/part001/mydata.parquet` +- `import_db.test_table/part002/mydata-part002.parquet` ### SQL {#sql} @@ -99,17 +99,17 @@ SQLファイルをインポートする際は、データファイルに以下 `${suffix}`はオプションであり、 *`xxx`*任意の数字で、以下のいずれかの形式になります。 -- *`.xxx`* 、例えば`.01` -- *`._xxx_xxx_xxx`* 、例えば`._0_0_01` -- *`_xxx_xxx_xxx`* 、例えば`_0_0_01` +- *`.xxx`* 、例えば`.01` +- *`._xxx_xxx_xxx`* 、例えば`._0_0_01` +- *`_xxx_xxx_xxx`* 、例えば`_0_0_01` `${compress}`は圧縮フォーマットであり、オプションです。TiDB Cloud は、 `.gzip` 、 `.gz` 、 `.zstd` 、 `.zst` 、および`.snappy` 。 例えば： -- `import_db.test_table.sql` -- `import_db.test_table.01.sql` -- `import_db.test_table.01.sql.gz` +- `import_db.test_table.sql` +- `import_db.test_table.01.sql` +- `import_db.test_table.01.sql.gz` TiDB Dumplingを使用してデフォルト設定でSQLファイルをエクスポートした場合、デフォルトで命名規則に準拠します。 @@ -123,5 +123,5 @@ TiDB Dumplingを使用してデフォルト設定でSQLファイルをエクス インポートウィザードの**Destination Mapping**ステップで、 **Use TiDB file naming conventions for automatic mapping**の選択を解除し、 **Source** 、 **Target Database** 、 **Target Table**の各フィールドに入力します。**Source**フィールドには`*`および`?`ワイルドカードをサポートするファイル名パターンを指定できます。 -- CSV ファイルについては[ステップ4. CSVファイルをTiDB Cloudにインポートする](/tidb-cloud/import-csv-files.md#step-4-import-csv-files-to-tidb-cloud)。 -- Parquet ファイルについては、 [ステップ4. ParquetファイルをTiDB Cloudにインポートする](/tidb-cloud/import-parquet-files.md#step-4-import-parquet-files-to-tidb-cloud)。 +- CSV ファイルについては[ステップ4. CSVファイルをTiDB Cloudにインポートする](/tidb-cloud/import-csv-files.md#step-4-import-csv-files-to-tidb-cloud)。 +- Parquet ファイルについては、 [ステップ4. ParquetファイルをTiDB Cloudにインポートする](/tidb-cloud/import-parquet-files.md#step-4-import-parquet-files-to-tidb-cloud)。 diff --git a/tidb-cloud/notifications.md b/tidb-cloud/notifications.md index d6c8b289c0da5..11986cfd6bd60 100644 --- a/tidb-cloud/notifications.md +++ b/tidb-cloud/notifications.md @@ -11,23 +11,23 @@ summary: TiDB Cloudコンソールにおける通知について、通知の種 TiDB Cloudコンソールでは、次のようなさまざまな種類の通知を受け取る可能性があります。 -- **情報通知** +- **情報通知** 機能の使い方に関するヒント、アプリケーションの変更点、今後のイベントのリマインダーなど、役立つ最新情報を提供します。 -- **実行可能な通知** +- **実行可能な通知** クレジットカードの追加など、特定の操作を実行するように促します。 -- **アラート通知** +- **アラート通知** システムエラー、セキュリティ警告、重要なアップデートなど、即時対応が必要な重大な問題や緊急の事態について通知します。 -- **請求通知** +- **請求通知** クレジットや割引に関する最新情報など、請求関連の活動に関する最新情報を配信します。 -- **フィードバック通知** +- **フィードバック通知** 最近の操作を評価したり、アンケートに回答したりするなど、機能の使用体験に関するフィードバックをリクエストしてください。 diff --git a/tidb-cloud/oauth2.md b/tidb-cloud/oauth2.md index 2f7e71353a8bc..623d42355550d 100644 --- a/tidb-cloud/oauth2.md +++ b/tidb-cloud/oauth2.md @@ -11,9 +11,9 @@ OAuth（Open Authorization）は、ユーザーに代わってリソースへの OAuthの最新バージョンである[OAuth 2.0](https://oauth.net/2/)は、認証における業界標準プロトコルとなりました。OAuth 2.0の主な利点は次のとおりです。 -- セキュリティ: トークンベースの認証を使用することで、OAuth 2.0 はパスワードの盗難や不正アクセスのリスクを最小限に抑えます。 -- 利便性: 複数の資格情報を管理することなく、データへのアクセスを許可および取り消すことができます。 -- アクセス制御: サードパーティ アプリケーションに付与するアクセス レベルを正確に指定して、必要な権限のみが付与されるようにすることができます。 +- セキュリティ: トークンベースの認証を使用することで、OAuth 2.0 はパスワードの盗難や不正アクセスのリスクを最小限に抑えます。 +- 利便性: 複数の資格情報を管理することなく、データへのアクセスを許可および取り消すことができます。 +- アクセス制御: サードパーティ アプリケーションに付与するアクセス レベルを正確に指定して、必要な権限のみが付与されるようにすることができます。 ## OAuth 付与タイプ {#oauth-grant-types} @@ -31,8 +31,8 @@ OAuthフレームワークは、さまざまなユースケースに合わせて OAuth 2.0 デバイスコード付与タイプを使用して、 TiDB Cloud CLI にアクセスできます。 -- [ticloud認証ログイン](/tidb-cloud/ticloud-auth-login.md) : TiDB Cloudで認証する -- [ticloud 認証ログアウト](/tidb-cloud/ticloud-auth-logout.md) : TiDB Cloudからログアウト +- [ticloud認証ログイン](/tidb-cloud/ticloud-auth-login.md) : TiDB Cloudで認証する +- [ticloud 認証ログアウト](/tidb-cloud/ticloud-auth-logout.md) : TiDB Cloudからログアウト アプリがOAuthを使用してTiDB Cloudにアクセスする必要がある場合は、 [クラウド＆テクノロジーパートナーになる](https://www.pingcap.com/partners/become-a-partner/) （**Partner Program**で**Cloud & Technology Partner**を選択）にリクエストを送信してください。担当者からご連絡いたします。 @@ -40,8 +40,8 @@ OAuth 2.0 デバイスコード付与タイプを使用して、 TiDB Cloud CLI 次のように、 TiDB Cloudコンソールで承認された OAuth アプリケーションのレコードを表示できます。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、左下隅にあります。 -2. **Account Settings**をクリックします。 -3. **Authorized OAuth Apps**タブをクリックします。承認済みのOAuthアプリケーションが表示されます。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、左下隅にあります。 +2. **Account Settings**をクリックします。 +3. **Authorized OAuth Apps**タブをクリックします。承認済みのOAuthアプリケーションが表示されます。 **Revoke**をクリックすると、いつでも承認を取り消すことができます。 diff --git a/tidb-cloud/pause-or-resume-tidb-cluster.md b/tidb-cloud/pause-or-resume-tidb-cluster.md index 7de445f7c734a..8e18af2c4b301 100644 --- a/tidb-cloud/pause-or-resume-tidb-cluster.md +++ b/tidb-cloud/pause-or-resume-tidb-cluster.md @@ -17,41 +17,41 @@ TiDB Cloudでは、常時稼働していないTiDB Cloud Dedicatedクラスタ ## 制限事項 {#limitations} -- クラスターを一時停止できるのは、クラスターの状態が**Available**の場合のみです。クラスターの状態が**Modifying**などの場合、一時停止する前に現在の操作が完了するまで待つ必要があります。 -- データインポートタスクの実行中は、クラスターを一時停止することはできません。インポートタスクが完了するまで待つか、インポートタスクをキャンセルするかのいずれかを選択してください。 -- バックアップ ジョブの実行中はクラスターを一時停止できません。現在のバックアップ ジョブが完了するまで待つか、 [実行中のバックアップジョブを削除します](/tidb-cloud/backup-and-restore.md#delete-a-running-backup-job)。 -- クラスターに[変更フィード](/tidb-cloud/changefeed-overview.md)がある場合、クラスターを一時停止することはできません。クラスターを一時停止する前に[既存の変更フィードを削除する](/tidb-cloud/changefeed-overview.md#delete-a-changefeed)必要があります。 -- [Point-in-Time Restore (PITR)](/tidb-cloud/backup-and-restore.md#turn-on-point-in-time-restore) が有効になっている場合、クラスターを一時停止することはできません。クラスターを一時停止する前に、**Backup Setting** の **Point-in-time Restore** スイッチをオフにする必要があります。 -- [Data Migration](/tidb-cloud/tidb-cloud-migration-overview.md) ジョブの実行中は、クラスターを一時停止することはできません。クラスターを一時停止する前に、移行ジョブが実行されていないことを確認してください。 +- クラスターを一時停止できるのは、クラスターの状態が**Available**の場合のみです。クラスターの状態が**Modifying**などの場合、一時停止する前に現在の操作が完了するまで待つ必要があります。 +- データインポートタスクの実行中は、クラスターを一時停止することはできません。インポートタスクが完了するまで待つか、インポートタスクをキャンセルするかのいずれかを選択してください。 +- バックアップ ジョブの実行中はクラスターを一時停止できません。現在のバックアップ ジョブが完了するまで待つか、 [実行中のバックアップジョブを削除します](/tidb-cloud/backup-and-restore.md#delete-a-running-backup-job)。 +- クラスターに[変更フィード](/tidb-cloud/changefeed-overview.md)がある場合、クラスターを一時停止することはできません。クラスターを一時停止する前に[既存の変更フィードを削除する](/tidb-cloud/changefeed-overview.md#delete-a-changefeed)必要があります。 +- [Point-in-Time Restore (PITR)](/tidb-cloud/backup-and-restore.md#turn-on-point-in-time-restore) が有効になっている場合、クラスターを一時停止することはできません。クラスターを一時停止する前に、**Backup Setting** の **Point-in-time Restore** スイッチをオフにする必要があります。 +- [Data Migration](/tidb-cloud/tidb-cloud-migration-overview.md) ジョブの実行中は、クラスターを一時停止することはできません。クラスターを一時停止する前に、移行ジョブが実行されていないことを確認してください。 ## TiDBクラスタを一時停止する {#pause-a-tidb-cluster} 一時停止期間と動作は、組織の作成日によって異なります。 -- 2024年11月12日以降に設立された組織は、最大7日間の一時停止期間という標準的な動作に従います。 -- 2024年11月12日以前に設立された組織は、互換性のある一時停止動作に従い、より長い一時停止期間が認められます。これらの組織は、段階的に標準の7日間制限に移行します。 +- 2024年11月12日以降に設立された組織は、最大7日間の一時停止期間という標準的な動作に従います。 +- 2024年11月12日以前に設立された組織は、互換性のある一時停止動作に従い、より長い一時停止期間が認められます。これらの組織は、段階的に標準の7日間制限に移行します。
クラスターが一時停止された場合は、以下の点に注意してください。 -- TiDB Cloudは、クラスタの監視情報の収集を停止します。 +- TiDB Cloudは、クラスタの監視情報の収集を停止します。 -- クラスターからデータを読み取ったり、クラスターにデータを書き込んだりすることはできません。 +- クラスターからデータを読み取ったり、クラスターにデータを書き込んだりすることはできません。 -- データのインポートやバックアップはできません。 +- データのインポートやバックアップはできません。 -- 請求される費用は以下のとおりです。 +- 請求される費用は以下のとおりです。 - - ノードストレージコスト - - データバックアップ費用 + - ノードストレージコスト + - データバックアップ費用 -- TiDB Cloud はクラスターの[自動バックアップ](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)を停止します。 +- TiDB Cloud はクラスターの[自動バックアップ](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)を停止します。 -- 最大一時停止期間は7日間です。7日以内に手動でクラスターを再開しない場合、 TiDB Cloudは自動的に再開します。 +- 最大一時停止期間は7日間です。7日以内に手動でクラスターを再開しない場合、 TiDB Cloudは自動的に再開します。 -- クラスターの概要ページから、自動再開スケジュールを確認できます。TiDB Cloudは、クラスターが自動再開される24時間前に、組織オーナーとプロジェクトオーナーに通知メールを送信します。 +- クラスターの概要ページから、自動再開スケジュールを確認できます。TiDB Cloudは、クラスターが自動再開される24時間前に、組織オーナーとプロジェクトオーナーに通知メールを送信します。
@@ -62,39 +62,39 @@ TiDB Cloudでは、常時稼働していないTiDB Cloud Dedicatedクラスタ クラスターが一時停止された場合は、以下の点に注意してください。 -- TiDB Cloudは、クラスタの監視情報の収集を停止します。 +- TiDB Cloudは、クラスタの監視情報の収集を停止します。 -- クラスターからデータを読み取ったり、クラスターにデータを書き込んだりすることはできません。 +- クラスターからデータを読み取ったり、クラスターにデータを書き込んだりすることはできません。 -- データのインポートやバックアップはできません。 +- データのインポートやバックアップはできません。 -- TiDB Cloudは、一時停止したクラスターを自動的に再開しません。 +- TiDB Cloudは、一時停止したクラスターを自動的に再開しません。 -- 請求される費用は以下のとおりです。 +- 請求される費用は以下のとおりです。 - - ノードストレージコスト - - データバックアップ費用 + - ノードストレージコスト + - データバックアップ費用 -- TiDB Cloud はクラスターの[自動バックアップ](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)を停止します。 +- TiDB Cloud はクラスターの[自動バックアップ](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)を停止します。
クラスターを一時停止するには、以下の手順を実行してください。 -1. TiDB Cloudコンソールで、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. TiDB Cloudコンソールで、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 -2. 一時停止したいTiDB Cloud Dedicatedクラスターの行で、 **...**をクリックします。 +2. 一時停止したいTiDB Cloud Dedicatedクラスターの行で、 **...**をクリックします。 > **Tip:** > > または、[**My TiDB**](https://tidbcloud.com/tidbs)ページで一時停止したいクラスターの名前をクリックし、右上隅の**...**をクリックすることもできます。 -3. ドロップダウンメニューの**Pause**をクリックしてください。 +3. ドロップダウンメニューの**Pause**をクリックしてください。 **Pause your cluster**ダイアログが表示されます。 -4. ダイアログで**Pause**をクリックして選択を確定してください。 +4. ダイアログで**Pause**をクリックして選択を確定してください。 **Pause**をクリックすると、クラスターはまず**Pausing**の状態になります。一時停止操作が完了すると、クラスターは**Paused**の状態に移行します。 @@ -104,21 +104,21 @@ TiDB Cloud API を使用してクラスタを一時停止することもでき 一時停止していたクラスターを再開した後は、以下の点に注意してください。 -- TiDB Cloudはクラスタの監視情報の収集を再開し、クラスタからのデータ読み取りやクラスタへのデータ書き込みが可能になります。 -- TiDB Cloudは、コンピューティングコストとストレージコストの両方の課金を再開します。 -- TiDB Cloud はクラスターの[自動バックアップ](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)を再開します。 +- TiDB Cloudはクラスタの監視情報の収集を再開し、クラスタからのデータ読み取りやクラスタへのデータ書き込みが可能になります。 +- TiDB Cloudは、コンピューティングコストとストレージコストの両方の課金を再開します。 +- TiDB Cloud はクラスターの[自動バックアップ](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)を再開します。 一時停止したクラスターを再開するには、以下の手順を実行してください。 -1. TiDB Cloudコンソールで、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 +1. TiDB Cloudコンソールで、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 -2. 再開したいTiDB Cloud Dedicatedクラスターについて、 **[Resume]**をクリックします。 **[Resume your cluster]**ダイアログが表示されます。 +2. 再開したいTiDB Cloud Dedicatedクラスターについて、 **[Resume]**をクリックします。 **[Resume your cluster]**ダイアログが表示されます。 > **Note:** > > **Pausing**状態のクラスターは再開できません。 -3. ダイアログで**Resume**をクリックして選択を確定します。クラスタの状態が**Resuming**になります。 +3. ダイアログで**Resume**をクリックして選択を確定します。クラスタの状態が**Resuming**になります。 クラスターのサイズによっては、クラスターの再開に数分かかる場合があります。クラスターが再開されると、クラスターの状態が**Resuming**から**Available**に変わります。 diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index 360d387d71373..50e5360812414 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -25,18 +25,18 @@ aliases: ['/ja/tidbcloud/restore-deleted-tidb-cluster'] > **Tip:** > -> - 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 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)を参照してください。 ## バックアップページを確認する {#view-the-backup-page} -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象の{{{ .premium }}}または{{{ .byoc }}}インスタンスの名前をクリックすると、その概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象の{{{ .premium }}}または{{{ .byoc }}}インスタンスの名前をクリックすると、その概要ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 左側のナビゲーションペインで、 **Data** > **Backup**をクリックします。 +2. 左側のナビゲーションペインで、 **Data** > **Backup**をクリックします。 ## 自動バックアップ {#automatic-backups} @@ -144,9 +144,9 @@ PITR を使用すると、保持期間内の任意の時点にデータを復元 {{{ .premium }}}または{{{ .byoc }}}インスタンスの既存のバックアップファイルを削除するには、以下の手順を実行してください。 -1. インスタンスの[**Backup**](#view-the-backup-page)ページに移動します。 +1. インスタンスの[**Backup**](#view-the-backup-page)ページに移動します。 -2. 削除したいバックアップファイルを見つけて、 **[アクション]**列の**[...]** > **[削除]**をクリックします。 +2. 削除したいバックアップファイルを見つけて、 **[アクション]**列の**[...]** > **[削除]**をクリックします。 > **Note:** > @@ -169,23 +169,23 @@ TiDB Cloud Premiumは、自動バックアップに加えて、手動バック ### 主な特徴 {#key-characteristics} -- **保持と削除**：自動バックアップとは異なり、手動バックアップは保持ポリシーに基づいて自動的に削除されません。明示的に削除するまで保持されます。インスタンスを削除すると、その手動バックアップはごみ箱に移動し、手動で削除するまでそこに残ります。 +- **保持と削除**：自動バックアップとは異なり、手動バックアップは保持ポリシーに基づいて自動的に削除されません。明示的に削除するまで保持されます。インスタンスを削除すると、その手動バックアップはごみ箱に移動し、手動で削除するまでそこに残ります。 -- **Storage location**：手動バックアップは、TiDBが管理するクラウドストレージに保存されます。 +- **Storage location**：手動バックアップは、TiDBが管理するクラウドストレージに保存されます。 -- **コスト**：手動バックアップは、削除するまで保持されるため、追加料金が発生します。 +- **コスト**：手動バックアップは、削除するまで保持されるため、追加料金が発生します。 -- **制限事項**：手動バックアップは、ポイントインタイムリカバリ（PITR）や部分バックアップ（テーブルレベルまたはデータベースレベルのバックアップなど）をサポートしていません。手動バックアップを既存のインスタンスに復元することはできません。復元操作ごとに新しいインスタンスが作成されます。 +- **制限事項**：手動バックアップは、ポイントインタイムリカバリ（PITR）や部分バックアップ（テーブルレベルまたはデータベースレベルのバックアップなど）をサポートしていません。手動バックアップを既存のインスタンスに復元することはできません。復元操作ごとに新しいインスタンスが作成されます。 -- **権限**： `Organization Owner`と`Instance Manager`の両方が手動バックアップを作成できます。システム管理の手動バックアップを復元できるのは`Organization Owner`のみです。 +- **権限**： `Organization Owner`と`Instance Manager`の両方が手動バックアップを作成できます。システム管理の手動バックアップを復元できるのは`Organization Owner`のみです。 ### 手動バックアップを作成する {#create-a-manual-backup} -1. インスタンスの[**Backup**](#view-the-backup-page)ページに移動します。 +1. インスタンスの[**Backup**](#view-the-backup-page)ページに移動します。 -2. 右上隅の**...**をクリックし、次に**Manual Backup**をクリックします。 +2. 右上隅の**...**をクリックし、次に**Manual Backup**をクリックします。 -3. 操作を確認してください。バックアップはTiDB Cloudに保存され、**バックアップリスト**に表示されます。 +3. 操作を確認してください。バックアップはTiDB Cloudに保存され、**バックアップリスト**に表示されます。 TiDB Cloudコンソールでは、外部ストレージの認証情報を入力することなく、手動バックアップを直接復元できます。 @@ -197,11 +197,11 @@ TiDB Cloudは、偶発的なデータ損失や破損が発生した場合にデ TiDB Cloudは、インスタンスのスナップショット復元と特定時点への復元をサポートしています。 -- **Snapshot Restore**：特定のバックアップスナップショットからインスタンスを復元します。この方法は、自動バックアップと手動バックアップの両方の復元に使用できます。**Backup List**では、手動バックアップには**Manual**タイプと**Permanent**有効期限ステータスが表示されます。 +- **Snapshot Restore**：特定のバックアップスナップショットからインスタンスを復元します。この方法は、自動バックアップと手動バックアップの両方の復元に使用できます。**Backup List**では、手動バックアップには**Manual**タイプと**Permanent**有効期限ステータスが表示されます。 -- **Point-in-Time Restore**：インスタンスを特定の時点の状態に復元します。 +- **Point-in-Time Restore**：インスタンスを特定の時点の状態に復元します。 - - Premium または BYOC インスタンス：過去7日間の任意の時点に復元できますが、インスタンス作成時刻より前、または現在時刻の1分前より後の時点には復元できません。なお、手動バックアップではPITRはサポートされていません。 + - Premium または BYOC インスタンス：過去7日間の任意の時点に復元できますが、インスタンス作成時刻より前、または現在時刻の1分前より後の時点には復元できません。なお、手動バックアップではPITRはサポートされていません。 ### 復元先 {#restore-destination} @@ -211,32 +211,32 @@ TiDB Cloudは、新しいインスタンスへのデータ復元をサポート 新しい {{{ .premium }}} または {{{ .byoc }}} インスタンスにデータを復元するには、以下の手順に従ってください。 -1. インスタンスの[**Backup**](#view-the-backup-page)ページに移動します。 +1. インスタンスの[**Backup**](#view-the-backup-page)ページに移動します。 -2. **Restore**をクリックしてください。 +2. **Restore**をクリックしてください。 -3. **Select Backup**ページで、使用する**Restore Mode**を選択します。特定のバックアップスナップショットから復元することも、特定の時点に復元することもできます。 +3. **Select Backup**ページで、使用する**Restore Mode**を選択します。特定のバックアップスナップショットから復元することも、特定の時点に復元することもできます。
選択したバックアップスナップショットから復元するには、次の手順を実行します。 - 1. **Snapshot Restore**をクリックします。 - 2. 復元元のバックアップスナップショットを選択してください。 + 1. **Snapshot Restore**をクリックします。 + 2. 復元元のバックアップスナップショットを選択してください。
Premium または BYOC インスタンスを特定の時点に復元するには、以下の手順を実行してください。 - 1. **Point-in-Time Restore**をクリックします。 - 2. 復元したい日時を選択してください。 + 1. **Point-in-Time Restore**をクリックします。 + 2. 復元したい日時を選択してください。
-4. **Next**をクリックして、 **Restore to a New Instance**ページに進んでください。 +4. **Next**をクリックして、 **Restore to a New Instance**ページに進んでください。 5. 新しい {{{ .premium }}} または {{{ .byoc }}} インスタンスを復元用に構成します。手順は [{{{ .premium }}} インスタンスの作成](/tidb-cloud/premium/create-tidb-instance-premium.md)[Create a {{{ .byoc }}} Instance](/tidb-cloud/byoc/create-tidb-instance-byoc.md) を参照してください。 @@ -250,7 +250,7 @@ TiDB Cloudは、新しいインスタンスへのデータ復元をサポート > > 新しいインスタンスは、デフォルトではバックアップと同じクラウドプロバイダーとリージョンを使用します。 -6. **Restore**をクリックして復元プロセスを開始してください。 +6. **Restore**をクリックして復元プロセスを開始してください。 復元処理が開始されると、インスタンスの状態は最初に**Creating**に変わります。作成が完了すると、 **Restoring**に変わります。復元が完了し、状態が**Available**に変わるまで、インスタンスは利用できません。 @@ -258,7 +258,7 @@ TiDB Cloudは、新しいインスタンスへのデータ復元をサポート ごみ箱から削除した {{{ .premium }}} または {{{ .byoc }}} インスタンスを復元するには、以下の手順を実行してください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、右上隅の**[...]**をクリックして、 **Recycle Bin**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、右上隅の**[...]**をクリックして、 **Recycle Bin**をクリックします。 > **Tip:** > @@ -268,9 +268,9 @@ TiDB Cloudは、新しいインスタンスへのデータ復元をサポート 3. 復元したい{{{ .premium }}}{{{ .byoc }}}インスタンスを見つけて、**>** ボタンをクリックし、そのインスタンスで利用可能なバックアップを展開します。 -4. 復元したいバックアップの行で、 **...**をクリックし、次に**Restore**を選択します。 +4. 復元したいバックアップの行で、 **...**をクリックし、次に**Restore**を選択します。 -5. **Restore**ページで、[新しいインスタンスに復元する](#restore-to-a-new-instance)と同じ手順に従って、バックアップを新しいインスタンスに復元します。 +5. **Restore**ページで、[新しいインスタンスに復元する](#restore-to-a-new-instance)と同じ手順に従って、バックアップを新しいインスタンスに復元します。 @@ -280,16 +280,16 @@ TiDB Cloudは、新しいインスタンスへのデータ復元をサポート TiDB Cloud Dedicatedクラスターによって生成されたバックアップを復元するには、次の手順に従ってください。 -1. [TiDB Cloudコンソール](https://tidbcloud.com)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。右上隅にある**[...]**をクリックし、 **Restore from Another Plan**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。右上隅にある**[...]**をクリックし、 **Restore from Another Plan**をクリックします。 -2. **Select Backup**ページで、対象のTiDB Cloud Dedicatedクラスターを含むプロジェクトを選択します。TiDB Cloud Dedicatedクラスターを選択し、復元するバックアップ スナップショットを選択して、 **Next**をクリックします。 +2. **Select Backup**ページで、対象のTiDB Cloud Dedicatedクラスターを含むプロジェクトを選択します。TiDB Cloud Dedicatedクラスターを選択し、復元するバックアップ スナップショットを選択して、 **Next**をクリックします。 > **Note:** > - > - バックアップスナップショットを含むTiDB Cloud Dedicatedクラスターが、選択したプロジェクト内で**Active**または**Deleted**のいずれかの状態になっていることを確認してください。 - > - スナップショットは、 TiDB Cloud Premiumがサポートするリージョン内に配置する必要があります。リージョンがサポートされていない場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)に連絡してTiDB Cloud Premium用の新しいリージョンを開設するか、別のバックアップスナップショットを選択してください。 + > - バックアップスナップショットを含むTiDB Cloud Dedicatedクラスターが、選択したプロジェクト内で**Active**または**Deleted**のいずれかの状態になっていることを確認してください。 + > - スナップショットは、 TiDB Cloud Premiumがサポートするリージョン内に配置する必要があります。リージョンがサポートされていない場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)に連絡してTiDB Cloud Premium用の新しいリージョンを開設するか、別のバックアップスナップショットを選択してください。 -3. **Restore**ページで、[新しいインスタンスに復元する](#restore-to-a-new-instance)と同じ手順に従って、バックアップを新しいインスタンスに復元します。 +3. **Restore**ページで、[新しいインスタンスに復元する](#restore-to-a-new-instance)と同じ手順に従って、バックアップを新しいインスタンスに復元します。 @@ -384,13 +384,13 @@ TiDB Cloud Dedicatedクラスターによって生成されたバックアップ アクセスキーを設定するには、以下の手順に従ってください。 -1. IAMユーザーとアクセスキーを作成します。 +1. IAMユーザーとアクセスキーを作成します。 - 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)を参照してください。 + 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)を参照してください。 -2. IAMユーザーに権限を付与します。 +2. IAMユーザーに権限を付与します。 タスクに必要な権限のみを含むポリシーを作成し、それをIAMユーザーにアタッチします。{{{ .premium }}} または {{{ .byoc }}} インスタンスにデータを復元するには、`s3:GetObject`、`s3:GetBucketLocation`、および `s3:ListBucket` 権限を付与します。 diff --git a/tidb-cloud/premium/built-in-monitoring-premium.md b/tidb-cloud/premium/built-in-monitoring-premium.md index 78cc4e236ef29..cc88c5503add5 100644 --- a/tidb-cloud/premium/built-in-monitoring-premium.md +++ b/tidb-cloud/premium/built-in-monitoring-premium.md @@ -11,13 +11,13 @@ TiDB Cloudは、 TiDB Cloud Premiumインスタンスの標準メトリック一 **Metrics**ページでメトリクスを表示するには、以下の手順に従ってください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Premiumインスタンスの名前をクリックすると、その概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Premiumインスタンスの名前をクリックすると、その概要ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 左側のナビゲーションペインで、 **Monitoring** > **Metrics**をクリックします。 +2. 左側のナビゲーションペインで、 **Monitoring** > **Metrics**をクリックします。 ## メトリクス保持ポリシー {#metrics-retention-policy} @@ -72,8 +72,8 @@ TiDB Cloud Premiumインスタンスの場合、メトリクスデータは7日 ペインにメトリクスが表示されない場合、考えられる理由は以下のとおりです。 -- 対応するTiDB Cloud Premiumインスタンスのワークロードは、このメトリックをトリガーしません。たとえば、失敗したクエリがない場合、失敗したクエリのメトリックは常に空になります。 -- TiDB Cloud PremiumインスタンスのTiDBバージョンが低いです。これらのメトリクスを表示するには、最新バージョンのTiDBにアップグレードする必要があります。 +- 対応するTiDB Cloud Premiumインスタンスのワークロードは、このメトリックをトリガーしません。たとえば、失敗したクエリがない場合、失敗したクエリのメトリックは常に空になります。 +- TiDB Cloud PremiumインスタンスのTiDBバージョンが低いです。これらのメトリクスを表示するには、最新バージョンのTiDBにアップグレードする必要があります。 これらの理由がすべて除外される場合は、トラブルシューティングのために[PingCAPサポートチーム](/tidb-cloud/tidb-cloud-support.md)に連絡できます。 diff --git a/tidb-cloud/premium/configure-ip-access-list-premium.md b/tidb-cloud/premium/configure-ip-access-list-premium.md index 0c11d0fcc6eed..52e005310adc9 100644 --- a/tidb-cloud/premium/configure-ip-access-list-premium.md +++ b/tidb-cloud/premium/configure-ip-access-list-premium.md @@ -13,21 +13,21 @@ TiDB Cloudの各TiDB Cloud Premium インスタンスに対して、IP アクセ TiDB Cloud PremiumインスタンスのIPアクセスリストを設定するには、以下の手順に従ってください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 左側のナビゲーションペインで、 **[設定]** > **[ネットワーク]**をクリックします。 +2. 左側のナビゲーションペインで、 **[設定]** > **[ネットワーク]**をクリックします。 -3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックしてインスタンスがパブリックエンドポイント経由でアクセスできるようにし、 **Add IP Address**をクリックします。 +3. **Networking**ページで、**Public Endpoint**の**Enable**をクリックしてインスタンスがパブリックエンドポイント経由でアクセスできるようにし、 **Add IP Address**をクリックします。 -4. 表示されたダイアログで、以下のいずれかのオプションを選択してください。 +4. 表示されたダイアログで、以下のいずれかのオプションを選択してください。 - - **Allow access from anywhere**：すべてのIPアドレスからTiDB Cloudへのアクセスを許可します。このオプションを選択すると、インスタンスがインターネットに完全に公開されるため、非常に危険です。 - - **Use IP addresses**（推奨）：SQLクライアント経由でTiDB Cloudへのアクセスを許可するIPアドレスとCIDRアドレスのリストを追加できます。 + - **Allow access from anywhere**：すべてのIPアドレスからTiDB Cloudへのアクセスを許可します。このオプションを選択すると、インスタンスがインターネットに完全に公開されるため、非常に危険です。 + - **Use IP addresses**（推奨）：SQLクライアント経由でTiDB Cloudへのアクセスを許可するIPアドレスとCIDRアドレスのリストを追加できます。 -5. **Use IP addresses**を選択した場合は、IPアドレスまたはCIDR範囲を追加し、必要に応じて説明を追加してください。 +5. **Use IP addresses**を選択した場合は、IPアドレスまたはCIDR範囲を追加し、必要に応じて説明を追加してください。 -6. 変更を保存するには、 **Confirm**をクリックしてください。 +6. 変更を保存するには、 **Confirm**をクリックしてください。 diff --git a/tidb-cloud/premium/connect-to-premium-via-alibaba-cloud-private-endpoint.md b/tidb-cloud/premium/connect-to-premium-via-alibaba-cloud-private-endpoint.md index 5162d5e185d79..04e782cc86d35 100644 --- a/tidb-cloud/premium/connect-to-premium-via-alibaba-cloud-private-endpoint.md +++ b/tidb-cloud/premium/connect-to-premium-via-alibaba-cloud-private-endpoint.md @@ -13,8 +13,8 @@ summary: Alibaba Cloud上のプライベートエンドポイントを介してT ## 制限 {#restrictions} -- 現在、TiDB Premiumは、エンドポイントサービスがAWSまたはAlibaba Cloudでホストされている場合に限り、プライベートエンドポイント接続をサポートしています。サービスが他のクラウドプロバイダーでホストされている場合、プライベートエンドポイントは利用できません。 -- リージョンをまたぐプライベートエンドポイント接続はサポートされていません。 +- 現在、TiDB Premiumは、エンドポイントサービスがAWSまたはAlibaba Cloudでホストされている場合に限り、プライベートエンドポイント接続をサポートしています。サービスが他のクラウドプロバイダーでホストされている場合、プライベートエンドポイントは利用できません。 +- リージョンをまたぐプライベートエンドポイント接続はサポートされていません。 ## Alibaba Cloudでプライベートエンドポイントを設定する {#set-up-a-private-endpoint-with-alibaba-cloud} @@ -22,54 +22,54 @@ summary: Alibaba Cloud上のプライベートエンドポイントを介してT ### ステップ1. TiDB Cloud Premiumインスタンスを選択します。 {#step-1-choose-a-tidb-cloud-premium-instance} -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Premiumインスタンスの名前をクリックすると、その概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. **Connection Type**ドロップダウンリストで、 **Private Endpoint**を選択します。 -4. **Service Name**、**Availability Zone ID** 、**Region ID**をメモしておいてください。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Premiumインスタンスの名前をクリックすると、その概要ページに移動します。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +3. **Connection Type**ドロップダウンリストで、 **Private Endpoint**を選択します。 +4. **Service Name**、**Availability Zone ID** 、**Region ID**をメモしておいてください。 ### ステップ2. Alibaba Cloud上にプライベートエンドポイントを作成する {#step-2-create-a-private-endpoint-on-alibaba-cloud} Alibaba Cloud管理コンソールを使用してVPCインターフェースエンドポイントを作成するには、次の手順を実行します。 -1. [Alibaba Cloud管理コンソール](https://account.alibabacloud.com/login/login.htm)にサインインします。 -2. **VPC** >**Endpoints**に移動します。 -3. **Interface Endpoints**タブをクリックし、 **Create Endpoint**をクリックします。 -4. エンドポイントの詳細を入力してください。 - - **リージョン**： TiDB Cloud Premiumインスタンスと同じリージョンを選択してください。 - - **Endpoint Name**：エンドポイントの名前を入力してください。 - - **Endpoint Type**：**Interface Endpoint**を選択してください。 - - **Endpoint Service**： **[その他のエンドポイントサービス]**を選択します。 -5. **Endpoint Service Name**フィールドに、 TiDB Cloudからコピーしたサービス名を貼り付けます。 -6. **Verify**をクリックしてください。緑色のチェックマークが表示されれば、サービスが有効であることを示します。 -7. エンドポイントに関連付ける**VPC** 、**Security Group**、および**ゾーン**を選択してください。 -8. エンドポイントを作成するには、 **OK**をクリックしてください。 -9. エンドポイントの状態が**Active**になり、接続の状態が**Connected**になるまで待ちます。 +1. [Alibaba Cloud管理コンソール](https://account.alibabacloud.com/login/login.htm)にサインインします。 +2. **VPC** >**Endpoints**に移動します。 +3. **Interface Endpoints**タブをクリックし、 **Create Endpoint**をクリックします。 +4. エンドポイントの詳細を入力してください。 + - **リージョン**： TiDB Cloud Premiumインスタンスと同じリージョンを選択してください。 + - **Endpoint Name**：エンドポイントの名前を入力してください。 + - **Endpoint Type**：**Interface Endpoint**を選択してください。 + - **Endpoint Service**： **[その他のエンドポイントサービス]**を選択します。 +5. **Endpoint Service Name**フィールドに、 TiDB Cloudからコピーしたサービス名を貼り付けます。 +6. **Verify**をクリックしてください。緑色のチェックマークが表示されれば、サービスが有効であることを示します。 +7. エンドポイントに関連付ける**VPC** 、**Security Group**、および**ゾーン**を選択してください。 +8. エンドポイントを作成するには、 **OK**をクリックしてください。 +9. エンドポイントの状態が**Active**になり、接続の状態が**Connected**になるまで待ちます。 インターフェースエンドポイントを作成したら、**EndPoints**ページに移動し、新しく作成したエンドポイントを選択します。 -- **Basic Information**セクションで、**Endpoint ID**をコピーしてください。この値は後で*エンドポイントリソースID*として使用します。 +- **Basic Information**セクションで、**Endpoint ID**をコピーしてください。この値は後で*エンドポイントリソースID*として使用します。 -- **Domain name of Endpoint Service**セクションで、 **Default Domain Name**をコピーしてください。この値は後で*ドメイン名*として使用します。 +- **Domain name of Endpoint Service**セクションで、 **Default Domain Name**をコピーしてください。この値は後で*ドメイン名*として使用します。 ![AliCloud private endpoint Information](/media/tidb-cloud/private-endpoint/alicloud-private-endpoint-info.png) ### ステップ3. エンドポイントを受け入れ、エンドポイント接続を作成します。 {#step-3-accept-the-endpoint-and-create-the-endpoint-connection} -1. TiDB Cloudコンソールの**Create Alibaba Cloud Private Endpoint Connection**ダイアログに戻ります。 +1. TiDB Cloudコンソールの**Create Alibaba Cloud Private Endpoint Connection**ダイアログに戻ります。 -2. 先ほどコピーした*エンドポイントリソースID*と*ドメイン名*を、それぞれのフィールドに貼り付けてください。 +2. 先ほどコピーした*エンドポイントリソースID*と*ドメイン名*を、それぞれのフィールドに貼り付けてください。 -3. プライベートエンドポイントからの接続を受け入れるには、 **Create Private Endpoint Connection**をクリックしてください。 +3. プライベートエンドポイントからの接続を受け入れるには、 **Create Private Endpoint Connection**をクリックしてください。 ### ステップ4. TiDB Cloud Premiumインスタンスに接続します {#step-4-connect-to-your-tidb-cloud-premium-instance} エンドポイント接続を承認すると、接続ダイアログにリダイレクトされます。 -1. プライベートエンドポイントの接続ステータスが**Active**になるまでお待ちください（約5分）。ステータスを確認するには、左側のナビゲーションペインで**Settings** > **Networking**をクリックして、 **Networking**ページに移動してください。 +1. プライベートエンドポイントの接続ステータスが**Active**になるまでお待ちください（約5分）。ステータスを確認するには、左側のナビゲーションペインで**Settings** > **Networking**をクリックして、 **Networking**ページに移動してください。 -2. **Connect With**ドロップダウンリストから、希望する接続方法を選択してください。対応する接続​​文字列がダイアログの下部に表示されます。 +2. **Connect With**ドロップダウンリストから、希望する接続方法を選択してください。対応する接続​​文字列がダイアログの下部に表示されます。 -3. 接続文字列を使用してインスタンスに接続してください。 +3. 接続文字列を使用してインスタンスに接続してください。 ## プライベートエンドポイントの状態参照 {#private-endpoint-status-reference} @@ -77,12 +77,12 @@ Alibaba Cloud管理コンソールを使用してVPCインターフェースエ プライベートエンドポイントの可能なステータスは、以下のように説明されます。 -- **Pending**：処理待ち。 -- **Active**：プライベートエンドポイントは使用可能です。 -- **Deleting**：プライベートエンドポイントが削除されています。 -- **Failed**：プライベートエンドポイントの作成に失敗しました。プライベートエンドポイントを削除して、新しいものを作成してください。 +- **Pending**：処理待ち。 +- **Active**：プライベートエンドポイントは使用可能です。 +- **Deleting**：プライベートエンドポイントが削除されています。 +- **Failed**：プライベートエンドポイントの作成に失敗しました。プライベートエンドポイントを削除して、新しいものを作成してください。 プライベートエンドポイントサービスの可能なステータスは、以下のように説明されます。 -- **Creating**：エンドポイントサービスが作成されています。これには3～5分かかります。 -- **Active**：プライベートエンドポイントが作成されるかどうかに関わらず、エンドポイントサービスが作成されます。 +- **Creating**：エンドポイントサービスが作成されています。これには3～5分かかります。 +- **Active**：プライベートエンドポイントが作成されるかどうかに関わらず、エンドポイントサービスが作成されます。 diff --git a/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md b/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md index 837f29b88e76c..4071cb833499e 100644 --- a/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md +++ b/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md @@ -21,13 +21,13 @@ AWS PrivateLink を利用したエンドポイント接続は、安全かつプ プライベートエンドポイントおよびエンドポイントサービスのより詳細な定義については、以下のAWSドキュメントを参照してください。 -- [AWS PrivateLinkとは何ですか？](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) -- [AWS PrivateLinkの概念](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html) +- [AWS PrivateLinkとは何ですか？](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) +- [AWS PrivateLinkの概念](https://docs.aws.amazon.com/vpc/latest/privatelink/concepts.html) ## 制限 {#restrictions} -- 対象インスタンスの `Organization Owner`、`Project Owner`、または `Instance Owner` ロールを持つユーザーのみがプライベートエンドポイント接続を作成できます。 -- 接続先のプライベートエンドポイントと {{{ .premium }}} または {{{ .byoc }}} インスタンスは、**同じリージョン** に配置されている必要があります。 +- 対象インスタンスの `Organization Owner`、`Project Owner`、または `Instance Owner` ロールを持つユーザーのみがプライベートエンドポイント接続を作成できます。 +- 接続先のプライベートエンドポイントと {{{ .premium }}} または {{{ .byoc }}} インスタンスは、**同じリージョン** に配置されている必要があります。 ## 前提条件 {#prerequisites} @@ -199,17 +199,17 @@ AWS マネジメントコンソールでプライベート DNS を有効にす プライベートエンドポイントの可能なステータスは、以下のように説明されます。 -- **Not Configured**：エンドポイントサービスは作成されていますが、プライベートエンドポイントはまだ作成されていません。 -- **Pending**：処理待ちです。 -- **Active**：プライベートエンドポイントは使用可能です。この状態ではプライベートエンドポイントを編集することはできません。 -- **Deleting**：プライベートエンドポイントが削除されています。 -- **Failed**：プライベートエンドポイントの作成に失敗しました。該当行の**Edit**をクリックすると、作成を再試行できます。 +- **Not Configured**：エンドポイントサービスは作成されていますが、プライベートエンドポイントはまだ作成されていません。 +- **Pending**：処理待ちです。 +- **Active**：プライベートエンドポイントは使用可能です。この状態ではプライベートエンドポイントを編集することはできません。 +- **Deleting**：プライベートエンドポイントが削除されています。 +- **Failed**：プライベートエンドポイントの作成に失敗しました。該当行の**Edit**をクリックすると、作成を再試行できます。 プライベートエンドポイントサービスの可能なステータスは、以下のように説明されます。 -- **Creating**：エンドポイントサービスを作成中です。これには3～5分かかります。 -- **Active**：プライベートエンドポイントが作成されるかどうかに関わらず、エンドポイントサービスが作成されます。 -- **Deleting**：エンドポイントサービスまたはインスタンスが削除されています。これには3～5分かかります。 +- **Creating**：エンドポイントサービスを作成中です。これには3～5分かかります。 +- **Active**：プライベートエンドポイントが作成されるかどうかに関わらず、エンドポイントサービスが作成されます。 +- **Deleting**：エンドポイントサービスまたはインスタンスが削除されています。これには3～5分かかります。 ## トラブルシューティング {#troubleshooting} 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 d873ad9228e9f..50137ace4b376 100644 --- a/tidb-cloud/premium/connect-to-premium-via-public-connection.md +++ b/tidb-cloud/premium/connect-to-premium-via-public-connection.md @@ -17,8 +17,8 @@ summary: パブリック接続を介してTiDB Cloud Premiumに接続する方 > **Tip:** > -> - パブリック接続経由​​でTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、 [パブリックエンドポイント経由でTiDB Cloud StarterまたはEssentialに接続します](/tidb-cloud/connect-via-standard-connection-serverless.md)を参照してください。 -> - パブリック エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [パブリック接続経由​​でTiDB Cloud Dedicatedに接続します](/tidb-cloud/connect-via-standard-connection.md)を参照してください。 +> - パブリック接続経由​​でTiDB Cloud 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} @@ -30,25 +30,25 @@ summary: パブリック接続を介してTiDB Cloud Premiumに接続する方 -1. 対象インスタンスの概要ページを開きます。 +1. 対象インスタンスの概要ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象インスタンスの名前をクリックすると、その概要ページに移動します。 + 2. 対象インスタンスの名前をクリックすると、その概要ページに移動します。 -2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 +2. 右上隅の**Connect**をクリックしてください。接続ダイアログが表示されます。 -3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Connection Type**を選択します。 +3. 接続ダイアログで、 **Connection Type**ドロップダウンリストから**Connection Type**を選択します。 IP アクセス リストを設定していない場合は、最初の接続の前に、**Configure IP Access List**をクリックするか、[IP アクセス リストを設定する](/tidb-cloud/premium/configure-ip-access-list-premium.md)の手順に従って設定してください。 -4. **CA cert**をクリックすると、 TiDB Cloud PremiumインスタンスへのTLS接続に必要なCA証明書をダウンロードできます。このCA証明書はデフォルトでTLS 1.2をサポートしています。 +4. **CA cert**をクリックすると、 TiDB Cloud PremiumインスタンスへのTLS接続に必要なCA証明書をダウンロードできます。このCA証明書はデフォルトでTLS 1.2をサポートしています。 -5. ご希望の接続方法を選択し、タブに表示されている接続文字列とサンプルコードを参照してインスタンスに接続してください。 +5. ご希望の接続方法を選択し、タブに表示されている接続文字列とサンプルコードを参照してインスタンスに接続してください。 diff --git a/tidb-cloud/premium/connect-to-tidb-instance.md b/tidb-cloud/premium/connect-to-tidb-instance.md index 533c7f45af2dd..7556c4b0ebcf0 100644 --- a/tidb-cloud/premium/connect-to-tidb-instance.md +++ b/tidb-cloud/premium/connect-to-tidb-instance.md @@ -25,11 +25,11 @@ TiDB Cloud で {{{ .premium }}} または {{{ .byoc } {{{ .premium }}} および {{{ .byoc }}} には、2 種類のネットワーク接続タイプがあります。 -- [プライベートエンドポイント](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)(推奨) +- [プライベートエンドポイント](/tidb-cloud/premium/connect-to-premium-via-aws-private-endpoint.md)(推奨) プライベートエンドポイント接続は、VPC内のSQLクライアントがAWS PrivateLink経由でサービスに安全にアクセスできるようにするプライベートエンドポイントを提供します。AWS PrivateLinkは、簡素化されたネットワーク管理で、データベースサービスへの高度に安全な一方向アクセスを提供します。 -- [公開エンドポイント](/tidb-cloud/premium/connect-to-premium-via-public-connection.md) +- [公開エンドポイント](/tidb-cloud/premium/connect-to-premium-via-public-connection.md) 標準接続では公開エンドポイントが提供されるため、ノートパソコンからSQLクライアントを介して {{{ .premium }}} または {{{ .byoc }}} インスタンスに接続できます。 diff --git a/tidb-cloud/premium/create-tidb-instance-premium.md b/tidb-cloud/premium/create-tidb-instance-premium.md index 27676437b7fa3..6215c03cc7ccf 100644 --- a/tidb-cloud/premium/create-tidb-instance-premium.md +++ b/tidb-cloud/premium/create-tidb-instance-premium.md @@ -17,20 +17,20 @@ TiDB Cloudアカウントをお持ちでない場合は、[ここ](https://tidbc -- TiDB Cloudを使用してパスワードを管理できるように、メールアドレスとパスワードで登録するか、Google、GitHub、またはMicrosoftアカウントで登録することができます。 -- AWS Marketplace をご利用の方は、AWS Marketplace からサインアップすることもできます。サインアップするには、 [AWS Marketplace](https://aws.amazon.com/marketplace)で`TiDB Cloud`を検索し、 TiDB Cloudを購読してから、画面の指示に従ってTiDB Cloudアカウントを設定してください。 -- Azure Marketplace をご利用の方は、Azure Marketplace からサインアップすることもできます。サインアップするには、 [Azure Marketplace](https://azuremarketplace.microsoft.com)で`TiDB Cloud`を検索し、 TiDB Cloudを購読してから、画面の指示に従ってTiDB Cloudアカウントを設定してください。 -- Google Cloud Marketplace をご利用の方は、Google Cloud Marketplace からサインアップすることもできます。サインアップするには、 [Google Cloud Marketplace](https://console.cloud.google.com/marketplace)で`TiDB Cloud`を検索し、 TiDB Cloudを購読してから、画面の指示に従ってTiDB Cloudアカウントを設定してください。 -- Alibaba Cloud Marketplace ユーザーの場合は、Alibaba Cloud Marketplace を通じてサインアップすることもできます。これを行うには、[アリババクラウドマーケットプレイス](https://marketplace.alibabacloud.com/)で`TiDB Cloud`を検索し、 TiDB Cloudにサブスクライブし、画面上の指示に従ってTiDB Cloudアカウントを設定します。 +- TiDB Cloudを使用してパスワードを管理できるように、メールアドレスとパスワードで登録するか、Google、GitHub、またはMicrosoftアカウントで登録することができます。 +- AWS Marketplace をご利用の方は、AWS Marketplace からサインアップすることもできます。サインアップするには、 [AWS Marketplace](https://aws.amazon.com/marketplace)で`TiDB Cloud`を検索し、 TiDB Cloudを購読してから、画面の指示に従ってTiDB Cloudアカウントを設定してください。 +- Azure Marketplace をご利用の方は、Azure Marketplace からサインアップすることもできます。サインアップするには、 [Azure Marketplace](https://azuremarketplace.microsoft.com)で`TiDB Cloud`を検索し、 TiDB Cloudを購読してから、画面の指示に従ってTiDB Cloudアカウントを設定してください。 +- Google Cloud Marketplace をご利用の方は、Google Cloud Marketplace からサインアップすることもできます。サインアップするには、 [Google Cloud Marketplace](https://console.cloud.google.com/marketplace)で`TiDB Cloud`を検索し、 TiDB Cloudを購読してから、画面の指示に従ってTiDB Cloudアカウントを設定してください。 +- Alibaba Cloud Marketplace ユーザーの場合は、Alibaba Cloud Marketplace を通じてサインアップすることもできます。これを行うには、[アリババクラウドマーケットプレイス](https://marketplace.alibabacloud.com/)で`TiDB Cloud`を検索し、 TiDB Cloudにサブスクライブし、画面上の指示に従ってTiDB Cloudアカウントを設定します。 -- TiDB Cloudを使用してパスワードを管理できるように、メールアドレスとパスワードで登録するか、Google、GitHub、またはMicrosoftアカウントで登録することができます。 -- AWS Marketplace をご利用の方は、AWS Marketplace からサインアップすることもできます。サインアップするには、 [AWS Marketplace](https://aws.amazon.com/marketplace)で`TiDB Cloud`を検索し、 TiDB Cloudを購読してから、画面の指示に従ってTiDB Cloudアカウントを設定してください。 -- Azure Marketplace をご利用の方は、Azure Marketplace からサインアップすることもできます。サインアップするには、 [Azure Marketplace](https://azuremarketplace.microsoft.com)で`TiDB Cloud`を検索し、 TiDB Cloudを購読してから、画面の指示に従ってTiDB Cloudアカウントを設定してください。 -- Google Cloud Marketplace をご利用の方は、Google Cloud Marketplace からサインアップすることもできます。サインアップするには、 [Google Cloud Marketplace](https://console.cloud.google.com/marketplace)で`TiDB Cloud`を検索し、 TiDB Cloudを購読してから、画面の指示に従ってTiDB Cloudアカウントを設定してください。 +- TiDB Cloudを使用してパスワードを管理できるように、メールアドレスとパスワードで登録するか、Google、GitHub、またはMicrosoftアカウントで登録することができます。 +- AWS Marketplace をご利用の方は、AWS Marketplace からサインアップすることもできます。サインアップするには、 [AWS Marketplace](https://aws.amazon.com/marketplace)で`TiDB Cloud`を検索し、 TiDB Cloudを購読してから、画面の指示に従ってTiDB Cloudアカウントを設定してください。 +- Azure Marketplace をご利用の方は、Azure Marketplace からサインアップすることもできます。サインアップするには、 [Azure Marketplace](https://azuremarketplace.microsoft.com)で`TiDB Cloud`を検索し、 TiDB Cloudを購読してから、画面の指示に従ってTiDB Cloudアカウントを設定してください。 +- Google Cloud Marketplace をご利用の方は、Google Cloud Marketplace からサインアップすることもできます。サインアップするには、 [Google Cloud Marketplace](https://console.cloud.google.com/marketplace)で`TiDB Cloud`を検索し、 TiDB Cloudを購読してから、画面の指示に従ってTiDB Cloudアカウントを設定してください。 @@ -38,24 +38,24 @@ TiDB Cloudアカウントをお持ちでない場合は、[ここ](https://tidbc `Organization Owner`ロールをお持ちの場合は、次のようにしてTiDB Cloud Premium インスタンスを作成できます。 -1. [TiDB Cloudコンソール](https://tidbcloud.com/tidbs)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、右上隅の**Create Resource**をクリックします。 +1. [TiDB Cloudコンソール](https://tidbcloud.com/tidbs)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、右上隅の**Create Resource**をクリックします。 -2. **Create Resource**ページで、プランとして**Premium**を選択してください。 +2. **Create Resource**ページで、プランとして**Premium**を選択してください。 -3. TiDB Cloud Premiumインスタンスの名前を入力し、インスタンスをホストするクラウドプロバイダーとリージョンを選択してください。 +3. TiDB Cloud Premiumインスタンスの名前を入力し、インスタンスをホストするクラウドプロバイダーとリージョンを選択してください。 -4. （オプション）このTiDB Cloud Premium インスタンスを管理用のプロジェクトにグループ化するには、**Group Your Instance in a Project** をクリックし、インスタンスの対象となるプロジェクトを選択します。組織内にプロジェクトがない場合は、**Create a Project** をクリックして作成できます。 +4. （オプション）このTiDB Cloud Premium インスタンスを管理用のプロジェクトにグループ化するには、**Group Your Instance in a Project** をクリックし、インスタンスの対象となるプロジェクトを選択します。組織内にプロジェクトがない場合は、**Create a Project** をクリックして作成できます。 -5. **Capacity**セクションで、インスタンスの最大リクエストキャパシティユニット（RCU）数を設定します。RCUは、ワークロード用にプロビジョニングされたコンピューティングリソースを表します。TiDB Cloudは、需要に基づいて、この範囲内でインスタンスを自動的にスケーリングします。 +5. **Capacity**セクションで、インスタンスの最大リクエストキャパシティユニット（RCU）数を設定します。RCUは、ワークロード用にプロビジョニングされたコンピューティングリソースを表します。TiDB Cloudは、需要に基づいて、この範囲内でインスタンスを自動的にスケーリングします。 > **Note:** > - > - RCUの最大値は100刻みで設定する必要があります。 - > - お客様には、**Minimum Billing RCU**と呼ばれる最低限のRCU数に基づいて課金されます。この値は、設定された最大RCUの25%と5,000RCUのうち大きい方です。最低請求RCUは、ピークパフォーマンスのために専用リソースが確保されることを保証します。実際の使用量がこれより少ない場合でも、この最低額が課金されます。 + > - RCUの最大値は100刻みで設定する必要があります。 + > - お客様には、**Minimum Billing RCU**と呼ばれる最低限のRCU数に基づいて課金されます。この値は、設定された最大RCUの25%と5,000RCUのうち大きい方です。最低請求RCUは、ピークパフォーマンスのために専用リソースが確保されることを保証します。実際の使用量がこれより少ない場合でも、この最低額が課金されます。 -6. TiDB Cloud Premiumインスタンスでは、リージョンごとの高可用性のみが有効になっており、設定変更はできません。詳細については、[高可用性](/tidb-cloud/serverless-high-availability.md)を参照してください。 +6. TiDB Cloud Premiumインスタンスでは、リージョンごとの高可用性のみが有効になっており、設定変更はできません。詳細については、[高可用性](/tidb-cloud/serverless-high-availability.md)を参照してください。 -7. **Create**をクリックします。 +7. **Create**をクリックします。 インスタンス作成プロセスが開始されます。選択したリージョンで初めてインスタンスを作成する場合、プロビジョニングには通常約30分かかります。選択したリージョンに既にインスタンスが存在する場合は、プロセスはより迅速に行われ、通常約1分以内に完了します。 diff --git a/tidb-cloud/premium/dual-layer-data-encryption-premium.md b/tidb-cloud/premium/dual-layer-data-encryption-premium.md index 1be4444df9fa0..1fa40dea6eb93 100644 --- a/tidb-cloud/premium/dual-layer-data-encryption-premium.md +++ b/tidb-cloud/premium/dual-layer-data-encryption-premium.md @@ -19,16 +19,16 @@ TiDB Cloud Premiumは、デフォルトでインスタンスストレージと TiDB Cloud Premiumは、より高いレベルのデータセキュリティを提供するために、保存データの暗号化に2層アーキテクチャを採用しています。ストレージ層とデータベース層の両方で暗号化を行い、データを保護します。 -- **ストレージ層暗号化** +- **ストレージ層暗号化** - - 基盤となるクラウドサービスプロバイダーは、ストレージストラクチャ上でストレージ層暗号化を提供します。例えば、AWSでは、Amazon Elastic Block Store（EBS）ボリュームの暗号化とAmazon Simple Storage Service（S3）バケットの暗号化が含まれます。 - - このレイヤーは、すべてのTiDB Cloud Premiumインスタンスでデフォルトで有効になっており、無効にすることはできません。これは、保存データに対する基本的なセキュリティ基準を提供します。 + - 基盤となるクラウドサービスプロバイダーは、ストレージストラクチャ上でストレージ層暗号化を提供します。例えば、AWSでは、Amazon Elastic Block Store（EBS）ボリュームの暗号化とAmazon Simple Storage Service（S3）バケットの暗号化が含まれます。 + - このレイヤーは、すべてのTiDB Cloud Premiumインスタンスでデフォルトで有効になっており、無効にすることはできません。これは、保存データに対する基本的なセキュリティ基準を提供します。 -- **データベース層の暗号化** +- **データベース層の暗号化** - - TiDB Cloud Premiumは、ストレージ層の暗号化に加えて、オプションのデータベース層暗号化機能（ TiDB Cloudコンソールでは**Dual-Layer Data Encryption**と表示）をサポートしています。この機能を有効にすると、TiKVに保存されているデータ、変更フィードデータ、およびバックアップデータが暗号化されます。 - - この仕組みにより、データベースシステム内のデータは暗号化された状態に保たれるため、内部処理やデータ移動中のデータ漏洩のリスクが低減されます。 - - ストレージ層の暗号化とは異なり、データベース層の暗号化はユーザーが設定可能です。セキュリティコンプライアンスや運用要件に応じて、顧客管理暗号化キー（CMEK）またはサービス管理暗号化キーのいずれかを選択できます。 + - TiDB Cloud Premiumは、ストレージ層の暗号化に加えて、オプションのデータベース層暗号化機能（ TiDB Cloudコンソールでは**Dual-Layer Data Encryption**と表示）をサポートしています。この機能を有効にすると、TiKVに保存されているデータ、変更フィードデータ、およびバックアップデータが暗号化されます。 + - この仕組みにより、データベースシステム内のデータは暗号化された状態に保たれるため、内部処理やデータ移動中のデータ漏洩のリスクが低減されます。 + - ストレージ層の暗号化とは異なり、データベース層の暗号化はユーザーが設定可能です。セキュリティコンプライアンスや運用要件に応じて、顧客管理暗号化キー（CMEK）またはサービス管理暗号化キーのいずれかを選択できます。 ### バックアップと復元に関する考慮事項 {#backup-and-restore-considerations} @@ -36,14 +36,14 @@ TiDB Cloud Premiumは、より高いレベルのデータセキュリティを バックアップデータへのアクセスには元のKMSマスターキーが必要となるため、以下の要件を満たしていることを確認してください。 -- **キーの可用性を管理**：元のTiDB Cloud Premium インスタンスを削除した場合でも、バックアップデータを復元できるように、関連付けられた KMS マスターキーをアクティブな状態に保ってください。 -- **適切な認証を確保する**：復元操作中は、バックアップに関連付けられているものと全く同じKMSマスターキーを設定し、そのキーにデータアクセスに必要な権限が付与されていることを確認してください。 +- **キーの可用性を管理**：元のTiDB Cloud Premium インスタンスを削除した場合でも、バックアップデータを復元できるように、関連付けられた KMS マスターキーをアクティブな状態に保ってください。 +- **適切な認証を確保する**：復元操作中は、バックアップに関連付けられているものと全く同じKMSマスターキーを設定し、そのキーにデータアクセスに必要な権限が付与されていることを確認してください。 ### 主要管理オプション {#key-management-options} デュアルレイヤーデータ暗号化では、クラウドプロバイダーのKMSを使用して、保存データの暗号化用マスターキーを管理します。キー管理オプションは2種類から選択できます。 -- **Customer-Managed Encryption Key (CMEK)** +- **Customer-Managed Encryption Key (CMEK)** KMSマスターキーは、お客様ご自身で作成、所有、管理できます。このオプションでは暗号化を完全に制御できるため、厳格なセキュリティ要件を持つ組織に適しています。 @@ -51,22 +51,22 @@ TiDB Cloud Premiumは、より高いレベルのデータセキュリティを > > キーのセキュリティと可用性の維持は、お客様の全責任となります。CMEKが削除または完全に破損した場合、インスタンスは使用不能となり、暗号化されたデータは永久に復元できなくなります。 -- **Service-Managed Encryption Key** +- **Service-Managed Encryption Key** TiDB Cloud Premiumは、お客様に代わってKMSマスターキーを自動的に作成および管理します。このオプションは、セキュリティと利便性のバランスが取れており、メンテナンスの手間もかかりません。 - - 鍵となるのは対称暗号鍵です。 - - キーは、指定されたリージョンで最初の暗号化されたTiDB Cloud Premiumインスタンスを作成する際に自動的に生成されます。 - - 組織ごと、地域ごとに1つのキーが作成され、その地域内のすべてのTiDB Cloud Premiumインスタンスで共有されます。 - - キーは、そのキーで暗号化されたすべてのデータが組織から削除された後にのみ、自動的に削除されます。 + - 鍵となるのは対称暗号鍵です。 + - キーは、指定されたリージョンで最初の暗号化されたTiDB Cloud Premiumインスタンスを作成する際に自動的に生成されます。 + - 組織ごと、地域ごとに1つのキーが作成され、その地域内のすべてのTiDB Cloud Premiumインスタンスで共有されます。 + - キーは、そのキーで暗号化されたすべてのデータが組織から削除された後にのみ、自動的に削除されます。 ## 制限事項 {#limitations} -- 現在、この機能はAWS KMSとAlibaba Cloud KMSをサポートしています。 -- データ暗号化は、TiKVに保存されるデータ、変更フィードデータ、およびバックアップデータに適用されます。TiFlashのデータ暗号化への対応は、今後のリリースで予定されています。 -- デュアルレイヤーデータ暗号化を有効にすると、 TiDB Cloud Premiumインスタンスの暗号化設定を変更できなくなります。 -- カスタム暗号化アルゴリズムはサポートされていません。ローテーションできるのはKMSマスターキーのみです。その他の暗号化キーのローテーションはサポートされていません。 -- クラウドプロバイダーのKMSキーは、 TiDB Cloud Premiumインスタンスと同じリージョンに存在する必要があります。そのため、CMEKを使用するバックアップでは、リージョンをまたいだリストア操作はサポートされていません。 +- 現在、この機能はAWS KMSとAlibaba Cloud KMSをサポートしています。 +- データ暗号化は、TiKVに保存されるデータ、変更フィードデータ、およびバックアップデータに適用されます。TiFlashのデータ暗号化への対応は、今後のリリースで予定されています。 +- デュアルレイヤーデータ暗号化を有効にすると、 TiDB Cloud Premiumインスタンスの暗号化設定を変更できなくなります。 +- カスタム暗号化アルゴリズムはサポートされていません。ローテーションできるのはKMSマスターキーのみです。その他の暗号化キーのローテーションはサポートされていません。 +- クラウドプロバイダーのKMSキーは、 TiDB Cloud Premiumインスタンスと同じリージョンに存在する必要があります。そのため、CMEKを使用するバックアップでは、リージョンをまたいだリストア操作はサポートされていません。 ## 二層データ暗号化を有効にする {#enable-dual-layer-data-encryption} @@ -80,45 +80,45 @@ TiDB Cloud Premiumインスタンスを作成する際に、二重層データ 独自の暗号化キーを使用するには、以下の手順に従ってください。 -1. クラウドプロバイダーのKMSで対称暗号化キーを作成してください。 +1. クラウドプロバイダーのKMSで対称暗号化キーを作成してください。 キーは、計画されているTiDB Cloud Premium インスタンスと**同じリージョン**に存在する必要があります。 - - AWS については、 [対称暗号化KMSキーを作成します](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html)を参照してください。 - - Alibaba Cloud については、 [KMSキーの理解](https://www.alibabacloud.com/help/en/kms/key-management-service/user-guide/overview-of-key-management)を参照してください。 + - AWS については、 [対称暗号化KMSキーを作成します](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html)を参照してください。 + - Alibaba Cloud については、 [KMSキーの理解](https://www.alibabacloud.com/help/en/kms/key-management-service/user-guide/overview-of-key-management)を参照してください。 -2. [TiDB Cloudコンソール](https://tidbcloud.com)で CMEK を構成します。 +2. [TiDB Cloudコンソール](https://tidbcloud.com)で CMEK を構成します。 - 1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、 **Create Resource**をクリックします。 + 1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、 **Create Resource**をクリックします。 - 2. TiDB Cloud Premiumプランを選択し、基本設定を完了してください。 + 2. TiDB Cloud Premiumプランを選択し、基本設定を完了してください。 - 3. **Dual-Layer Data Encryption**セクションで、 **Enable**をクリックします。 + 3. **Dual-Layer Data Encryption**セクションで、 **Enable**をクリックします。 - 4. **Customer-Managed Encryption Key (CMEK)**を選択し、 **Add KMS Key ARN**をクリックします。 + 4. **Customer-Managed Encryption Key (CMEK)**を選択し、 **Add KMS Key ARN**をクリックします。 - 5. 表示されているJSONポリシーステートメントをコピーしてください。このポリシーステートメントは、TiDB Cloudに必要なキーアクセス権限を定義します。 + 5. 表示されているJSONポリシーステートメントをコピーしてください。このポリシーステートメントは、TiDB Cloudに必要なキーアクセス権限を定義します。 - 6. クラウドプロバイダーのKMSコンソールで、このポリシーステートメントをキーポリシーに追加してください。 + 6. クラウドプロバイダーのKMSコンソールで、このポリシーステートメントをキーポリシーに追加してください。 - - 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)を参照してください。 + - 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 Key ARN**を入力します。 + 7. TiDB Cloudコンソールに戻り、キー作成ページの一番下までスクロールして、クラウドプロバイダーのKMSから取得した**KMS Key ARN**を入力します。 - 8. 信頼関係を確認するには、 **Test and Add KMS Key ARN**をクリックします。 + 8. 信頼関係を確認するには、 **Test and Add KMS Key ARN**をクリックします。 - 9. 検証が成功したら、 **Create**をクリックして、 TiDB Cloud Premiumインスタンスの作成を完了してください。 + 9. 検証が成功したら、 **Create**をクリックして、 TiDB Cloud Premiumインスタンスの作成を完了してください。 #### オプション2：サービス管理型暗号化キー {#option-2-service-managed-encryption-key} TiDB Cloudに暗号化キーの管理を代行させるには、以下の手順に従ってください。 -1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、 **Create Resource**をクリックします。 -2. TiDB Cloud Premiumプランを選択し、基本設定を完了してください。 -3. **Dual-Layer Data Encryption**セクションで、 **Enable**をクリックします。 -4. **Service-Managed Encryption Key**を選択してください。 -5. **Create**をクリックして、 TiDB Cloud Premiumインスタンスの作成を完了してください。 +1. [**My TiDB**](https://tidbcloud.com/tidbs)ページで、 **Create Resource**をクリックします。 +2. TiDB Cloud Premiumプランを選択し、基本設定を完了してください。 +3. **Dual-Layer Data Encryption**セクションで、 **Enable**をクリックします。 +4. **Service-Managed Encryption Key**を選択してください。 +5. **Create**をクリックして、 TiDB Cloud Premiumインスタンスの作成を完了してください。 ### 既存のインスタンスで暗号化を有効にする {#enable-encryption-for-an-existing-instance} @@ -132,35 +132,35 @@ TiDB Cloudに暗号化キーの管理を代行させるには、以下の手順 開始する前に、クラウドプロバイダーのKMSで対称暗号化キーを作成済みであることを確認してください。次に、以下の手順を実行してください。 -1. TiDB Cloud Premiumインスタンスの**Security**ページで、 **Dual-Layer Data Encryption**セクションの**Enable**をクリックします。 +1. TiDB Cloud Premiumインスタンスの**Security**ページで、 **Dual-Layer Data Encryption**セクションの**Enable**をクリックします。 -2. **Customer-Managed Encryption Key (CMEK)**を選択し、 **Add KMS Key ARN**をクリックします。 +2. **Customer-Managed Encryption Key (CMEK)**を選択し、 **Add KMS Key ARN**をクリックします。 -3. 表示されているJSONポリシーステートメントをコピーしてください。このポリシーステートメントは、TiDB Cloudに必要なキーアクセス権限を定義します。 +3. 表示されているJSONポリシーステートメントをコピーしてください。このポリシーステートメントは、TiDB Cloudに必要なキーアクセス権限を定義します。 -4. クラウドプロバイダーのKMSコンソールで、このポリシーステートメントをキーポリシーに追加してください。 +4. クラウドプロバイダーのKMSコンソールで、このポリシーステートメントをキーポリシーに追加してください。 - - 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)を参照してください。 + - 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 Key ARN**を入力します。 +5. TiDB Cloudコンソールに戻り、ページの一番下までスクロールして、クラウドプロバイダーのKMSから取得した**KMS Key ARN**を入力します。 -6. **Test and Add KMS Key ARN**をクリックして、キーアクセス構成を確認し、二重層データ暗号化を有効にします。 +6. **Test and Add KMS Key ARN**をクリックして、キーアクセス構成を確認し、二重層データ暗号化を有効にします。 #### オプション2：サービス管理型暗号化キー {#option-2-service-managed-encryption-key} TiDB Cloudに暗号化キーの管理を代行させるには、以下の手順に従ってください。 -1. TiDB Cloud Premiumインスタンスの**Security**ページで、 **Dual-Layer Data Encryption**セクションの**Enable**をクリックします。 -2. **Service-Managed Encryption Key**を選択してください。 -3. **Enable**をクリックしてください。 +1. TiDB Cloud Premiumインスタンスの**Security**ページで、 **Dual-Layer Data Encryption**セクションの**Enable**をクリックします。 +2. **Service-Managed Encryption Key**を選択してください。 +3. **Enable**をクリックしてください。 ## 暗号化ステータスを確認する {#view-encryption-status} 暗号化を有効にした後、以下の場所でステータスを確認してください。 -- TiDB Cloud Premiumインスタンスの**Overview**ページでは、 **[暗号化]**フィールドにアクティブなキー管理方法が表示されます。これは、 **[顧客管理暗号化キー（CMEK）で有効]**または**[サービス管理暗号化キーで有効]**のいずれかです。 -- **Security**ページでは、二重層データ暗号化の詳細な設定を確認できます。 +- TiDB Cloud Premiumインスタンスの**Overview**ページでは、 **[暗号化]**フィールドにアクティブなキー管理方法が表示されます。これは、 **[顧客管理暗号化キー（CMEK）で有効]**または**[サービス管理暗号化キーで有効]**のいずれかです。 +- **Security**ページでは、二重層データ暗号化の詳細な設定を確認できます。 ## 暗号化されたバックアップから復元する {#restore-from-an-encrypted-backup} @@ -168,8 +168,8 @@ TiDB Cloudに暗号化キーの管理を代行させるには、以下の手順 > **Warning:** > -> - 現在、暗号化されたバックアップは、元のインスタンスと同じ**アカウント**および**リージョン**にのみ復元できます。リージョン間およびアカウント間の復元操作はサポートされていません。 -> - キーのセキュリティと可用性を維持する責任はあなたにあります。CMEKが削除されたり、完全に破損したりした場合、このキーに関連付けられたバックアップデータもすべて復元できなくなります。 +> - 現在、暗号化されたバックアップは、元のインスタンスと同じ**アカウント**および**リージョン**にのみ復元できます。リージョン間およびアカウント間の復元操作はサポートされていません。 +> - キーのセキュリティと可用性を維持する責任はあなたにあります。CMEKが削除されたり、完全に破損したりした場合、このキーに関連付けられたバックアップデータもすべて復元できなくなります。 ### CMEKで暗号化されたバックアップを復元する {#restore-a-backup-encrypted-with-a-cmek} @@ -177,8 +177,8 @@ TiDB Cloudに暗号化キーの管理を代行させるには、以下の手順 アクセスを確認するには、 **Check**をクリックして信頼ポリシーの検証を開始します。TiDB Cloudは、キーポリシーで承認されたTiDB Cloudアカウントが、元のバックアップに関連付けられているアカウントと一致するかどうかを確認します。 -- アカウントが一致する場合、それ以上の承認は必要ありません。 -- アカウントが一致しない場合は、提供されたキーポリシーをコピーし、クラウドプロバイダーのKMSで更新してください。この更新によりキーが再認証され、新しいインスタンスがキーにアクセスできるようになります。 +- アカウントが一致する場合、それ以上の承認は必要ありません。 +- アカウントが一致しない場合は、提供されたキーポリシーをコピーし、クラウドプロバイダーのKMSで更新してください。この更新によりキーが再認証され、新しいインスタンスがキーにアクセスできるようになります。 ### サービス管理暗号化キーで暗号化されたバックアップを復元する {#restore-a-backup-encrypted-with-a-service-managed-encryption-key} @@ -188,5 +188,5 @@ TiDB Cloudに暗号化キーの管理を代行させるには、以下の手順 クラウドプロバイダーのKMSでCMEKの自動ローテーションを設定できます。TiDB Cloudでは設定の更新は不要です。 -- AWS については、 [CMEK自動回転](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)を参照してください。 -- Alibaba Cloud については、 [キーローテーション](https://www.alibabacloud.com/help/en/kms/key-management-service/user-guide/configure-key-rotation)を参照してください。 +- AWS については、 [CMEK自動回転](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)を参照してください。 +- Alibaba Cloud については、 [キーローテーション](https://www.alibabacloud.com/help/en/kms/key-management-service/user-guide/configure-key-rotation)を参照してください。 diff --git a/tidb-cloud/premium/import-csv-files-premium.md b/tidb-cloud/premium/import-csv-files-premium.md index 4cfe9fc7134bc..8fcfd863560fb 100644 --- a/tidb-cloud/premium/import-csv-files-premium.md +++ b/tidb-cloud/premium/import-csv-files-premium.md @@ -9,8 +9,8 @@ summary: Amazon S3またはAlibaba Cloud Object Storage Service（OSS）からCS > **Tip:** > -> - 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 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)を参照してください。 ## 制限事項 {#limitations} @@ -18,33 +18,33 @@ summary: Amazon S3またはAlibaba Cloud Object Storage Service（OSS）からCS ## ステップ1. CSVファイルを準備する {#step-1-prepare-the-csv-files} -1. CSVファイルが256MiBを超える場合は、それぞれ約256MiBのサイズの小さなファイルに分割することを検討してください。 +1. CSVファイルが256MiBを超える場合は、それぞれ約256MiBのサイズの小さなファイルに分割することを検討してください。 TiDB Cloud Premiumは非常に大きなCSVファイルのインポートをサポートしていますが、サイズが約256MiBの複数の入力ファイルを扱う場合に最高のパフォーマンスを発揮します。これは、 TiDB Cloud Premiumが複数のファイルを並列処理できるため、インポート速度を大幅に向上させることができるからです。 -2. CSVファイルの名前は以下のようにしてください。 +2. CSVファイルの名前は以下のようにしてください。 - - CSV ファイルにテーブル全体のデータがすべて含まれている場合は、ファイル名を`${db_name}.${table_name}.csv`形式で指定してください。この形式は、データをインポートする際に`${db_name}.${table_name}`テーブルにマッピングされます。 + - CSV ファイルにテーブル全体のデータがすべて含まれている場合は、ファイル名を`${db_name}.${table_name}.csv`形式で指定してください。この形式は、データをインポートする際に`${db_name}.${table_name}`テーブルにマッピングされます。 - - 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`や`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 + - 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例えば、 `${db_name}.${table_name}.000001.csv`や`${db_name}.${table_name}.000002.csv`のようにです。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 - - TiDB Cloud Premium は、 `.gzip` 、 `.gz` 、 `.zst` `.zstd` 、{ `.snappy`の形式で圧縮ファイルをインポートできます。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。ここで`${suffix}`省略可能で、「000001」などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 + - TiDB Cloud Premium は、 `.gzip` 、 `.gz` 、 `.zst` `.zstd` 、{ `.snappy`の形式で圧縮ファイルをインポートできます。圧縮 CSV ファイルをインポートする場合は、ファイル名を`${db_name}.${table_name}.${suffix}.csv.${compress}`形式で指定します。ここで`${suffix}`省略可能で、「000001」などの任意の整数を指定できます。例えば、 `trips.000001.csv.gz`ファイルを`bikeshare.trips`テーブルにインポートする場合は、ファイル名を`bikeshare.trips.000001.csv.gz`に変更する必要があります。 > **Note:** > - > - パフォーマンスを向上させるためには、各圧縮ファイルのサイズを100MiBに制限することをお勧めします。 - > - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)に存在する必要があります。 Snappy 圧縮の他のバリアントはサポートされていません。 - > - 非圧縮ファイルの場合、場合によっては前述のルールに従ってCSVファイル名を更新できない場合（たとえば、CSVファイルリンクが他のプログラムでも使用されている場合）、ファイル名を変更せずに、[ステップ4](#step-4-import-csv-files)の**Mapping Settings**を使用してソースデータを単一のターゲットテーブルにインポートできます。 + > - パフォーマンスを向上させるためには、各圧縮ファイルのサイズを100MiBに制限することをお勧めします。 + > - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)に存在する必要があります。 Snappy 圧縮の他のバリアントはサポートされていません。 + > - 非圧縮ファイルの場合、場合によっては前述のルールに従ってCSVファイル名を更新できない場合（たとえば、CSVファイルリンクが他のプログラムでも使用されている場合）、ファイル名を変更せずに、[ステップ4](#step-4-import-csv-files)の**Mapping Settings**を使用してソースデータを単一のターゲットテーブルにインポートできます。 ## ステップ2．対象テーブルのスキーマを作成する {#step-2-create-the-target-table-schemas} CSVファイルにはスキーマ情報が含まれていないため、CSVファイルからTiDB Cloud Premiumにデータをインポートする前に、以下のいずれかの方法を使用してテーブルスキーマを作成する必要があります。 -- 方法1： TiDB Cloud Premiumで、ソースデータ用のターゲットデータベースとテーブルを作成します。 +- 方法1： TiDB Cloud Premiumで、ソースデータ用のターゲットデータベースとテーブルを作成します。 -- 方法2：CSVファイルが保存されているAmazon S3またはAlibaba Cloud Object Storage Service（OSS）ディレクトリに、ソースデータ用のターゲットテーブルスキーマファイルを次のように作成します。 +- 方法2：CSVファイルが保存されているAmazon S3またはAlibaba Cloud Object Storage Service（OSS）ディレクトリに、ソースデータ用のターゲットテーブルスキーマファイルを次のように作成します。 - 1. ソースデータ用のデータベーススキーマファイルを作成します。 + 1. ソースデータ用のデータベーススキーマファイルを作成します。 [ステップ1](#step-1-prepare-the-csv-files)の命名規則に従ってCSVファイルが作成されている場合、データベーススキーマファイルはデータインポートにおいてオプションです。そうでない場合は、データベーススキーマファイルは必須です。 @@ -56,7 +56,7 @@ CSVファイルにはスキーマ情報が含まれていないため、CSVフ CREATE DATABASE mydb; ``` - 2. ソースデータ用のテーブルスキーマファイルを作成します。 + 2. ソースデータ用のテーブルスキーマファイルを作成します。 CSVファイルが保存されているAmazon S3またはAlibaba Cloud Object Storage Serviceディレクトリにテーブルスキーマファイルを含めない場合、 TiDB Cloud Premiumはデータのインポート時に対応するテーブルを作成しません。 @@ -79,11 +79,11 @@ CSVファイルにはスキーマ情報が含まれていないため、CSVフ TiDB Cloud PremiumがAmazon S3またはAlibaba Cloud Object Storage Service（OSS）内のCSVファイルにアクセスできるようにするには、次のいずれかの操作を行います。 -- CSV ファイルが Amazon S3 にある場合は、 TiDB Cloud Premium インスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 +- CSV ファイルが Amazon S3 にある場合は、 TiDB Cloud Premium インスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-csv-files)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 -- CSV ファイルが Alibaba Cloud Object Storage Service (OSS) にある場合は、 TiDB Cloud Premium インスタンスの[Alibaba Cloud Object Storage Service (OSS) へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 +- CSV ファイルが Alibaba Cloud Object Storage Service (OSS) にある場合は、 TiDB Cloud Premium インスタンスの[Alibaba Cloud Object Storage Service (OSS) へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 ## ステップ4．CSVファイルをインポートする {#step-4-import-csv-files} @@ -92,33 +92,33 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の
-1. 対象のTiDB Cloud Premiumインスタンスの**Import**ページを開きます。 +1. 対象のTiDB Cloud Premiumインスタンスの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Amazon S3**を選択してください。 - - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `s3://sampledata/ingest/TableName.01.csv` 。 - - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://sampledata/ingest/` 。 - - **Credential**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 - - **AWS Role ARN** : AWS ロール ARN の値を入力してください。新しいロールを作成する必要がある場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロールを作成] をクリックし**、ガイド付き手順に従って、提供されているテンプレートを起動し、 IAM警告を確認し、スタックを作成し、生成された ARN をTiDB Cloud Premium にコピーしてください。 - - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 - - **Test Bucket Access**：認証情報が正しく入力された後、このボタンをクリックして、 TiDB Cloud Premiumがバケットにアクセスできることを確認してください。 - - **Target Connection**：インポートを実行するTiDBのユーザー名とパスワードを入力してください。必要に応じて、 **Test Connection**をクリックして認証情報を検証してください。 + - **Storage Provider**： **Amazon S3**を選択してください。 + - **Source Files URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `s3://sampledata/ingest/TableName.01.csv` 。 + - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://sampledata/ingest/` 。 + - **Credential**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)を参照してください。 + - **AWS Role ARN** : AWS ロール ARN の値を入力してください。新しいロールを作成する必要がある場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロールを作成] をクリックし**、ガイド付き手順に従って、提供されているテンプレートを起動し、 IAM警告を確認し、スタックを作成し、生成された ARN をTiDB Cloud Premium にコピーしてください。 + - **AWS Access Key**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 + - **Test Bucket Access**：認証情報が正しく入力された後、このボタンをクリックして、 TiDB Cloud Premiumがバケットにアクセスできることを確認してください。 + - **Target Connection**：インポートを実行するTiDBのユーザー名とパスワードを入力してください。必要に応じて、 **Test Connection**をクリックして認証情報を検証してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Source Files Mapping**セクションでは、 TiDB Cloud Premiumがバケットをスキャンし、ソースファイルと宛先テーブル間のマッピングを提案します。 +5. **Source Files Mapping**セクションでは、 TiDB Cloud Premiumがバケットをスキャンし、ソースファイルと宛先テーブル間のマッピングを提案します。 **Source Files URI**でディレクトリが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションがデフォルトで選択されます。 @@ -126,9 +126,9 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloud Premiumは**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - [ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)ソース ファイルとターゲット テーブルに適用するには、自動マッピングを有効のままにしておきます。データ形式として**CSV**を選択したままにしておきます。 + - [ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)ソース ファイルとターゲット テーブルに適用するには、自動マッピングを有効のままにしておきます。データ形式として**CSV**を選択したままにしておきます。 - - **Advanced options**：パネルを展開して`Ignore compatibility checks (advanced)`の切り替えボタンを表示します。スキーマ互換性検証を意図的にバイパスしたい場合を除き、無効のままにしておいてください。 + - **Advanced options**：パネルを展開して`Ignore compatibility checks (advanced)`の切り替えボタンを表示します。スキーマ互換性検証を意図的にバイパスしたい場合を除き、無効のままにしておいてください。 @@ -136,42 +136,42 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の > > 手動マッピング機能は近日中に利用可能になります。切り替え機能が利用可能になったら、自動マッピングオプションをオフにして、マッピングを手動で設定してください。 > - > - **Source**: `TableName.01.csv`のようなファイル名パターンを入力してください。ワイルドカード`*`と`?`がサポートされています (例: `my-data*.csv` )。 - > - **Target Database**と**Target Table**：一致したファイルの宛先オブジェクトを選択します。 + > - **Source**: `TableName.01.csv`のようなファイル名パターンを入力してください。ワイルドカード`*`と`?`がサポートされています (例: `my-data*.csv` )。 + > - **Target Database**と**Target Table**：一致したファイルの宛先オブジェクトを選択します。 -6. TiDB Cloud Premiumはソースパスを自動的にスキャンします。スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックしてください。 +6. TiDB Cloud Premiumはソースパスを自動的にスキャンします。スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックしてください。 -7. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +7. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
-1. 対象のTiDB Cloud Premiumインスタンスの**Import**ページを開きます。 +1. 対象のTiDB Cloud Premiumインスタンスの**Import**ページを開きます。 - 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 + 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動します。 > **Tip:** > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 + 2. 対象のTiDB Cloud Premiumインスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**Data** > **Import**をクリックします。 -2. **Import data from Cloud Storage**をクリックします。 +2. **Import data from Cloud Storage**をクリックします。 -3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 +3. **Import Data from Cloud Storage**ページで、以下の情報を入力してください。 - - **Storage Provider**： **Alibaba Cloud OSS**を選択してください。 - - **Source Files URI** ： - - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `oss://sampledata/ingest/TableName.01.csv` 。 - - 複数のファイルをインポートする場合は、ソースフォルダのURIを`oss://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `oss://sampledata/ingest/` 。 - - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)を参照してください。 - - **Test Bucket Access**：認証情報が正しく入力された後、このボタンをクリックして、 TiDB Cloud Premiumがバケットにアクセスできることを確認してください。 - - **Target Connection**：インポートを実行するTiDBのユーザー名とパスワードを入力してください。必要に応じて、 **Test Connection**をクリックして認証情報を検証してください。 + - **Storage Provider**： **Alibaba Cloud OSS**を選択してください。 + - **Source Files URI** ： + - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `oss://sampledata/ingest/TableName.01.csv` 。 + - 複数のファイルをインポートする場合は、ソースフォルダのURIを`oss://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `oss://sampledata/ingest/` 。 + - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)を参照してください。 + - **Test Bucket Access**：認証情報が正しく入力された後、このボタンをクリックして、 TiDB Cloud Premiumがバケットにアクセスできることを確認してください。 + - **Target Connection**：インポートを実行するTiDBのユーザー名とパスワードを入力してください。必要に応じて、 **Test Connection**をクリックして認証情報を検証してください。 -4. **Next**をクリックしてください。 +4. **Next**をクリックしてください。 -5. **Source Files Mapping**セクションでは、 TiDB Cloud Premiumがバケットをスキャンし、ソースファイルと宛先テーブル間のマッピングを提案します。 +5. **Source Files Mapping**セクションでは、 TiDB Cloud Premiumがバケットをスキャンし、ソースファイルと宛先テーブル間のマッピングを提案します。 **Source Files URI**でディレクトリが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションがデフォルトで選択されます。 @@ -179,9 +179,9 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の > > **Source Files URI**で単一のファイルが指定されている場合、 **自動マッピングにファイル命名規則を使用する**オプションは表示されず、 TiDB Cloud Premiumは**Source**フィールドにファイル名を自動的に入力します。この場合、データインポートの対象となるデータベースとテーブルを選択するだけで済みます。 - - [ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)ソース ファイルとターゲット テーブルに適用するには、自動マッピングを有効のままにしておきます。データ形式として**CSV**を選択したままにしておきます。 + - [ファイル命名規則](/tidb-cloud/naming-conventions-for-data-import.md)ソース ファイルとターゲット テーブルに適用するには、自動マッピングを有効のままにしておきます。データ形式として**CSV**を選択したままにしておきます。 - - **Advanced options**：パネルを展開して`Ignore compatibility checks (advanced)`の切り替えボタンを表示します。スキーマ互換性検証を意図的にバイパスしたい場合を除き、無効のままにしておいてください。 + - **Advanced options**：パネルを展開して`Ignore compatibility checks (advanced)`の切り替えボタンを表示します。スキーマ互換性検証を意図的にバイパスしたい場合を除き、無効のままにしておいてください。 @@ -189,12 +189,12 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の > > 手動マッピング機能は近日中に利用可能になります。切り替え機能が利用可能になったら、自動マッピングオプションをオフにして、マッピングを手動で設定してください。 > - > - **Source**: `TableName.01.csv`のようなファイル名パターンを入力してください。ワイルドカード`*`と`?`がサポートされています (例: `my-data*.csv` )。 - > - **Target Database**と**Target Table**：一致したファイルの宛先オブジェクトを選択します。 + > - **Source**: `TableName.01.csv`のようなファイル名パターンを入力してください。ワイルドカード`*`と`?`がサポートされています (例: `my-data*.csv` )。 + > - **Target Database**と**Target Table**：一致したファイルの宛先オブジェクトを選択します。 -6. TiDB Cloud Premiumはソースパスを自動的にスキャンします。スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックしてください。 +6. TiDB Cloud Premiumはソースパスを自動的にスキャンします。スキャン結果を確認し、検出されたデータファイルと対応するターゲットテーブルをチェックしてから、 **Start Import**をクリックしてください。 -7. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。 +7. インポートの進行状況が**Completed**と表示されたら、インポートされたテーブルを確認してください。
@@ -204,10 +204,10 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の インポートエラーが発生した場合は、以下の手順を実行してください。 -1. 部分的にインポートされたテーブルを削除します。 -2. テーブルスキーマファイルを確認してください。エラーがある場合は、テーブルスキーマファイルを修正してください。 -3. CSVファイル内のデータ型を確認してください。 -4. インポートタスクをもう一度実行してみてください。 +1. 部分的にインポートされたテーブルを削除します。 +2. テーブルスキーマファイルを確認してください。エラーがある場合は、テーブルスキーマファイルを修正してください。 +3. CSVファイル内のデータ型を確認してください。 +4. インポートタスクをもう一度実行してみてください。 ## トラブルシューティング {#troubleshooting} diff --git a/tidb-cloud/premium/import-from-s3-premium.md b/tidb-cloud/premium/import-from-s3-premium.md index 96f5ce869087b..0cd50528f2081 100644 --- a/tidb-cloud/premium/import-from-s3-premium.md +++ b/tidb-cloud/premium/import-from-s3-premium.md @@ -9,23 +9,23 @@ summary: コンソールウィザードを使用して、Amazon S3からTiDB Clo > **Tip:** > -> - 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 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)を参照してください。 ## 制限事項 {#limitations} -- データの一貫性を確保するため、 TiDB Cloud Premium では、CSV ファイルを空のテーブルにのみインポートできます。対象テーブルに既にデータが含まれている場合は、ステージングテーブルにインポートしてから、 `INSERT ... SELECT`ステートメントを使用して行をコピーしてください。 -- パブリックプレビュー期間中は、ユーザーインターフェースはストレージプロバイダーとしてAmazon S3のみをサポートしています。その他のプロバイダーへの対応は、今後のリリースで追加される予定です。 -- 各インポートジョブは、単一のソースパターンを1つの宛先テーブルにマッピングします。 +- データの一貫性を確保するため、 TiDB Cloud Premium では、CSV ファイルを空のテーブルにのみインポートできます。対象テーブルに既にデータが含まれている場合は、ステージングテーブルにインポートしてから、 `INSERT ... SELECT`ステートメントを使用して行をコピーしてください。 +- パブリックプレビュー期間中は、ユーザーインターフェースはストレージプロバイダーとしてAmazon S3のみをサポートしています。その他のプロバイダーへの対応は、今後のリリースで追加される予定です。 +- 各インポートジョブは、単一のソースパターンを1つの宛先テーブルにマッピングします。 ## ステップ1. CSVファイルを準備する {#step-1-prepare-the-csv-files} -1. CSVファイルが256MiBを超える場合は、 TiDB Cloud Premiumが並列処理できるように、256MiB程度の小さなファイルに分割することを検討してください。 -2. CSVファイルの名前は、 Dumplingの命名規則に従ってください。 - - 完全な表ファイルの場合： `${db_name}.${table_name}.csv`形式を使用してください。 - - シャーディングされたファイル: `${db_name}.${table_name}.000001.csv`のような数値サフィックスを追加します。 - - 圧縮ファイル: `${db_name}.${table_name}.${suffix}.csv.${compress}`形式を使用してください。 -3. オプションのスキーマファイル（ `${db_name}-schema-create.sql` 、 `${db_name}.${table_name}-schema.sql` ）を使用すると、 TiDB Cloud Premium はデータベースとテーブルを自動的に作成できます。 +1. CSVファイルが256MiBを超える場合は、 TiDB Cloud Premiumが並列処理できるように、256MiB程度の小さなファイルに分割することを検討してください。 +2. CSVファイルの名前は、 Dumplingの命名規則に従ってください。 + - 完全な表ファイルの場合： `${db_name}.${table_name}.csv`形式を使用してください。 + - シャーディングされたファイル: `${db_name}.${table_name}.000001.csv`のような数値サフィックスを追加します。 + - 圧縮ファイル: `${db_name}.${table_name}.${suffix}.csv.${compress}`形式を使用してください。 +3. オプションのスキーマファイル（ `${db_name}-schema-create.sql` 、 `${db_name}.${table_name}-schema.sql` ）を使用すると、 TiDB Cloud Premium はデータベースとテーブルを自動的に作成できます。 ["TiDB", "SQL Layer", 10] - t10_r2 --> ["TiKV", "KV Engine", 20] - t10_r3 --> ["PD", " Manager", 30] +``` +t10_r1 --> ["TiDB", "SQL Layer", 10] +t10_r2 --> ["TiKV", "KV Engine", 20] +t10_r3 --> ["PD", " Manager", 30] +``` このテーブルには、主キーに加えて、一意ではない通常のセカンダリインデックス`idxAge`があります。`IndexID`が`1`であるとすると、TiKV に保存されるインデックスデータは次のようになります。 - t10_i1_10_1 --> null - t10_i1_20_2 --> null - t10_i1_30_3 --> null +``` +t10_i1_10_1 --> null +t10_i1_20_2 --> null +t10_i1_30_3 --> null +``` 上記の例は、TiDB におけるリレーショナル モデルからキー値モデルへのマッピング ルールと、このマッピング スキームの背後にある考慮事項を示しています。 @@ -111,10 +125,10 @@ SQL コンピューティングの最もシンプルなソリューションは 例えば、SQL文`select count(*) from user where name = "TiDB"`を実行するには、TiDBはテーブル内のすべてのデータを読み取り、フィールド`name`が`TiDB`かどうかを確認し、そうであればその行を返します。このプロセスは以下のとおりです。 -1. キー範囲を構築します。表内のすべての`RowID` `[0, MaxInt64)`範囲に含まれます。行データの`Key`エンコード規則に従って、 `0`と`MaxInt64`を使用すると、左閉じ、右開きの`[StartKey, EndKey)`範囲を構築できます。 -2. キー範囲のスキャン: 上記で構築されたキー範囲に従って TiKV 内のデータを読み取ります。 -3. データのフィルタリング：読み込んだデータ行ごとに、式`name = "TiDB"`を計算します。結果が`true`の場合は、この行に戻ります。そうでない場合は、この行をスキップします。 -4. `Count(*)`を計算します。要件を満たす行ごとに、 `Count(*)`の結果を合計します。 +1. キー範囲を構築します。表内のすべての`RowID` `[0, MaxInt64)`範囲に含まれます。行データの`Key`エンコード規則に従って、 `0`と`MaxInt64`を使用すると、左閉じ、右開きの`[StartKey, EndKey)`範囲を構築できます。 +2. キー範囲のスキャン: 上記で構築されたキー範囲に従って TiKV 内のデータを読み取ります。 +3. データのフィルタリング：読み込んだデータ行ごとに、式`name = "TiDB"`を計算します。結果が`true`の場合は、この行に戻ります。そうでない場合は、この行をスキップします。 +4. `Count(*)`を計算します。要件を満たす行ごとに、 `Count(*)`の結果を合計します。 **全体のプロセスは次のように示されます。** @@ -122,9 +136,9 @@ SQL コンピューティングの最もシンプルなソリューションは このソリューションは直感的で実現可能ですが、分散データベースのシナリオでは明らかな問題がいくつかあります。 -- データがスキャンされる際、各行は少なくとも 1 つの RPC オーバーヘッドを伴う KV 操作を介して TiKV から読み取られますが、スキャンするデータの量が多い場合は、このオーバーヘッドが非常に高くなる可能性があります。 -- すべての行に適用されるわけではありません。条件を満たさないデータは読み取る必要はありません。 -- このクエリの返された結果では、要件に一致する行の数のみが必要であり、それらの行の値は必要ありません。 +- データがスキャンされる際、各行は少なくとも 1 つの RPC オーバーヘッドを伴う KV 操作を介して TiKV から読み取られますが、スキャンするデータの量が多い場合は、このオーバーヘッドが非常に高くなる可能性があります。 +- すべての行に適用されるわけではありません。条件を満たさないデータは読み取る必要はありません。 +- このクエリの返された結果では、要件に一致する行の数のみが必要であり、それらの行の値は必要ありません。 ### 分散SQL操作 {#distributed-sql-operations} diff --git a/tidb-configuration-file.md b/tidb-configuration-file.md index b116efc9b85a5..b04d47c8ed96e 100644 --- a/tidb-configuration-file.md +++ b/tidb-configuration-file.md @@ -17,38 +17,38 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも ### `split-table` {#split-table} -- 各テーブルごとに個別のリージョンを作成するかどうかを決定します。 -- デフォルト値: `true` -- 多数のテーブル（例えば、10万個以上のテーブル）を作成する必要がある場合は`false`に設定することをお勧めします。 +- 各テーブルごとに個別のリージョンを作成するかどうかを決定します。 +- デフォルト値: `true` +- 多数のテーブル（例えば、10万個以上のテーブル）を作成する必要がある場合は`false`に設定することをお勧めします。 ### `tidb-max-reuse-chunk` v6.4.0の新機能 {#tidb-max-reuse-chunk-new-in-v640} -- チャンク割り当てにおけるキャッシュ可能なチャンクオブジェクトの最大数を制御します。この設定項目に大きすぎる値を設定すると、メモリ不足（OOM）のリスクが高まる可能性があります。 -- デフォルト値: `64` -- 最小値: `0` -- 最大値: `2147483647` +- チャンク割り当てにおけるキャッシュ可能なチャンクオブジェクトの最大数を制御します。この設定項目に大きすぎる値を設定すると、メモリ不足（OOM）のリスクが高まる可能性があります。 +- デフォルト値: `64` +- 最小値: `0` +- 最大値: `2147483647` ### `tidb-max-reuse-column` v6.4.0で追加 {#tidb-max-reuse-column-new-in-v640} -- チャンク割り当てにおけるキャッシュ可能な列オブジェクトの最大数を制御します。この設定項目に大きすぎる値を設定すると、メモリ不足（OOM）のリスクが高まる可能性があります。 -- デフォルト値: `256` -- 最小値: `0` -- 最大値: `2147483647` +- チャンク割り当てにおけるキャッシュ可能な列オブジェクトの最大数を制御します。この設定項目に大きすぎる値を設定すると、メモリ不足（OOM）のリスクが高まる可能性があります。 +- デフォルト値: `256` +- 最小値: `0` +- 最大値: `2147483647` ### `token-limit` {#token-limit} -- 同時にリクエストを実行できるセッションの数。 -- 型: Integer -- デフォルト値: `1000` -- 最小値: `1` -- 最大値: `1048576` +- 同時にリクエストを実行できるセッションの数。 +- 型: Integer +- デフォルト値: `1000` +- 最小値: `1` +- 最大値: `1048576` ### `temp-dir` v6.3.0で追加 {#temp-dir-new-in-v630} -- 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 にインポートされます。 -- デフォルト値: `"/tmp/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 にインポートされます。 +- デフォルト値: `"/tmp/tidb"` > **Note:** > @@ -60,56 +60,56 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも > > バージョン 6.3.0 以降、この設定項目は非推奨となり、システム変数[`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom)に置き換えられました。TiDB クラスタをバージョン 6.3.0 以降にアップグレードすると、この変数は`oom-use-tmp-storage`の値で自動的に初期化されます。その後、 `oom-use-tmp-storage`の値を変更しても効果は**ありません**。 -- 単一の SQL ステートメントがシステム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)で指定されたメモリクォータを超えた場合に、一部のオペレーターに対して一時ストレージを有効にするかどうかを制御します。 -- デフォルト値: `true` +- 単一の SQL ステートメントがシステム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)で指定されたメモリクォータを超えた場合に、一部のオペレーターに対して一時ストレージを有効にするかどうかを制御します。 +- デフォルト値: `true` ### `tmp-storage-path` {#tmp-storage-path} -- 単一の SQL ステートメントがシステム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)で指定されたメモリクォータを超えた場合に、一部のオペレーターの一時的なストレージパスを指定します。 -- デフォルト値: `/_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-storage` 。 `MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=`は`Base64`の`:/:`エンコード結果です。 -- この設定は、システム変数[`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom)が`ON`の場合にのみ有効になります。 +- 単一の SQL ステートメントがシステム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)で指定されたメモリクォータを超えた場合に、一部のオペレーターの一時的なストレージパスを指定します。 +- デフォルト値: `/_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-storage` 。 `MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=`は`Base64`の`:/:`エンコード結果です。 +- この設定は、システム変数[`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom)が`ON`の場合にのみ有効になります。 ### `tmp-storage-quota` {#tmp-storage-quota} -- `tmp-storage-path`のストレージのクォータを指定します。単位はバイトです。 -- 単一の SQL ステートメントが一時ディスクを使用し、TiDBサーバーの一時ディスクの合計ボリュームがこの構成値を超えると、現在の SQL 操作はキャンセルされ、 `Out of Global Storage Quota!`エラーが返されます。 -- この設定の値が`0`より小さい場合、上記のチェックと制限は適用されません。 -- デフォルト値: `-1` -- `tmp-storage-path`の残りの使用可能なストレージが`tmp-storage-quota`で定義された値よりも少ない場合、TiDBサーバーは起動時にエラーを報告して終了します。 +- `tmp-storage-path`のストレージのクォータを指定します。単位はバイトです。 +- 単一の SQL ステートメントが一時ディスクを使用し、TiDBサーバーの一時ディスクの合計ボリュームがこの構成値を超えると、現在の SQL 操作はキャンセルされ、 `Out of Global Storage Quota!`エラーが返されます。 +- この設定の値が`0`より小さい場合、上記のチェックと制限は適用されません。 +- デフォルト値: `-1` +- `tmp-storage-path`の残りの使用可能なストレージが`tmp-storage-quota`で定義された値よりも少ない場合、TiDBサーバーは起動時にエラーを報告して終了します。 ### `lease` {#lease} -- DDLリース契約のタイムアウト。 -- デフォルト値: `45s` -- 単位：秒 +- DDLリース契約のタイムアウト。 +- デフォルト値: `45s` +- 単位：秒 ### `compatible-kill-query` {#compatible-kill-query} -- `KILL`ステートメントを MySQL 互換に設定するかどうかを決定します。 -- デフォルト値: `false` -- `compatible-kill-query`は、[`enable-global-kill`](#enable-global-kill-new-in-v610)が`false`に設定されている場合にのみ有効になります。 -- [`enable-global-kill`](#enable-global-kill-new-in-v610)が`false`の場合、 `compatible-kill-query`は、クエリを強制終了する際に`TIDB`キーワードを追加する必要があるかどうかを制御します。 - - `compatible-kill-query`が`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`ステートメントの詳細については、[KILL [TIDB]](/sql-statements/sql-statement-kill.md)を参照してください。 +- `KILL`ステートメントを MySQL 互換に設定するかどうかを決定します。 +- デフォルト値: `false` +- `compatible-kill-query`は、[`enable-global-kill`](#enable-global-kill-new-in-v610)が`false`に設定されている場合にのみ有効になります。 +- [`enable-global-kill`](#enable-global-kill-new-in-v610)が`false`の場合、 `compatible-kill-query`は、クエリを強制終了する際に`TIDB`キーワードを追加する必要があるかどうかを制御します。 + - `compatible-kill-query`が`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`ステートメントの詳細については、[KILL [TIDB]](/sql-statements/sql-statement-kill.md)を参照してください。 ### `check-mb4-value-in-utf8` {#check-mb4-value-in-utf8} -- `utf8mb4`文字チェックを有効にするかどうかを決定します。この機能が有効になっている場合、文字セットが`utf8`で、 `mb4`に`utf8`文字が挿入されると、エラーが返されます。 -- デフォルト値: `false` -- バージョン6.1.0以降、 `utf8mb4`文字チェックを有効にするかどうかは、TiDB構成項目`instance.tidb_check_mb4_value_in_utf8`またはシステム変数`tidb_check_mb4_value_in_utf8`によって決定されます。 `check-mb4-value-in-utf8`は引き続き有効です。ただし、 `check-mb4-value-in-utf8`と`instance.tidb_check_mb4_value_in_utf8`の両方が設定されている場合は、後者が有効になります。 +- `utf8mb4`文字チェックを有効にするかどうかを決定します。この機能が有効になっている場合、文字セットが`utf8`で、 `mb4`に`utf8`文字が挿入されると、エラーが返されます。 +- デフォルト値: `false` +- バージョン6.1.0以降、 `utf8mb4`文字チェックを有効にするかどうかは、TiDB構成項目`instance.tidb_check_mb4_value_in_utf8`またはシステム変数`tidb_check_mb4_value_in_utf8`によって決定されます。 `check-mb4-value-in-utf8`は引き続き有効です。ただし、 `check-mb4-value-in-utf8`と`instance.tidb_check_mb4_value_in_utf8`の両方が設定されている場合は、後者が有効になります。 ### `treat-old-version-utf8-as-utf8mb4` {#treat-old-version-utf8-as-utf8mb4} -- 古いテーブルの`utf8`文字セットを`utf8mb4`として扱うかどうかを決定します。 -- デフォルト値: `true` +- 古いテーブルの`utf8`文字セットを`utf8mb4`として扱うかどうかを決定します。 +- デフォルト値: `true` ### `alter-primary-key`(非推奨) {#alter-primary-key-deprecated} -- 列に主キー制約を追加するか削除するかを決定します。 -- デフォルト値: `false` -- このデフォルト設定では、主キー制約の追加または削除はサポートされていません。 `alter-primary-key`を`true`に設定することで、この機能を有効にできます。ただし、スイッチをオンにする前にテーブルが既に存在し、その主キー列のデータ型が整数である場合、この構成項目を`true`に設定しても、列から主キーを削除することはできません。 +- 列に主キー制約を追加するか削除するかを決定します。 +- デフォルト値: `false` +- このデフォルト設定では、主キー制約の追加または削除はサポートされていません。 `alter-primary-key`を`true`に設定することで、この機能を有効にできます。ただし、スイッチをオンにする前にテーブルが既に存在し、その主キー列のデータ型が整数である場合、この構成項目を`true`に設定しても、列から主キーを削除することはできません。 > **Note:** > @@ -117,11 +117,11 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも ### `server-version` {#server-version} -- 以下の状況において、TiDBが返すバージョン文字列を変更します。 - - 組み込み関数`VERSION()`を使用する場合。 - - TiDB がクライアントへの最初の接続を確立し、サーバーのバージョン文字列を含む最初のハンドシェイク パケットを返すとき。詳細については、 [MySQL 初期ハンドシェイクパケット](https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase.html#sect_protocol_connection_phase_initial_handshake)を参照してください。 -- デフォルト値: "" -- デフォルトでは、TiDB バージョン文字列の形式は`8.0.11-TiDB-${tidb_version}`です。 +- 以下の状況において、TiDBが返すバージョン文字列を変更します。 + - 組み込み関数`VERSION()`を使用する場合。 + - TiDB がクライアントへの最初の接続を確立し、サーバーのバージョン文字列を含む最初のハンドシェイク パケットを返すとき。詳細については、 [MySQL 初期ハンドシェイクパケット](https://dev.mysql.com/doc/dev/mysql-server/latest/page_protocol_connection_phase.html#sect_protocol_connection_phase_initial_handshake)を参照してください。 +- デフォルト値: "" +- デフォルトでは、TiDB バージョン文字列の形式は`8.0.11-TiDB-${tidb_version}`です。 > **Note:** > @@ -129,110 +129,110 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも ### `repair-mode` {#repair-mode} -- 信頼できない修復モードを有効にするかどうかを決定します。 `repair-mode`が`true`に設定されている場合、 `repair-table-list`内の不良テーブルはロードできません。 -- デフォルト値: `false` -- `repair`構文はデフォルトではサポートされていません。つまり、TiDB起動時にすべてのテーブルがロードされます。 +- 信頼できない修復モードを有効にするかどうかを決定します。 `repair-mode`が`true`に設定されている場合、 `repair-table-list`内の不良テーブルはロードできません。 +- デフォルト値: `false` +- `repair`構文はデフォルトではサポートされていません。つまり、TiDB起動時にすべてのテーブルがロードされます。 ### `repair-table-list` {#repair-table-list} -- `repair-table-list`は、[`repair-mode`](#repair-mode)が`true`に設定されている場合にのみ有効です。 `repair-table-list`は、インスタンス内で修復が必要な不良テーブルのリストです。リストの例は次のとおりです: ["db.table1","db.table2"...]。 -- デフォルト値: [] -- リストはデフォルトでは空です。これは、修復が必要な不良テーブルが存在しないことを意味します。 +- `repair-table-list`は、[`repair-mode`](#repair-mode)が`true`に設定されている場合にのみ有効です。 `repair-table-list`は、インスタンス内で修復が必要な不良テーブルのリストです。リストの例は次のとおりです: ["db.table1","db.table2"...]。 +- デフォルト値: [] +- リストはデフォルトでは空です。これは、修復が必要な不良テーブルが存在しないことを意味します。 ### `new_collations_enabled_on_first_bootstrap` {#new_collations_enabled_on_first_bootstrap} -- 新しい照合順序のサポートを有効または無効にします。 -- デフォルト値: `true` -- 注：この設定は、最初に初期化された TiDB クラスタにのみ有効です。初期化後は、この設定項目を使用して新しい照合順序のサポートを有効または無効にすることはできません。 +- 新しい照合順序のサポートを有効または無効にします。 +- デフォルト値: `true` +- 注：この設定は、最初に初期化された TiDB クラスタにのみ有効です。初期化後は、この設定項目を使用して新しい照合順序のサポートを有効または無効にすることはできません。 ### `max-server-connections` {#max-server-connections} -- TiDBで許可される同時クライアント接続の最大数。リソース制御に使用されます。 -- デフォルト値: `0` -- デフォルトでは、TiDB は同時クライアント接続数の制限を設定しません。この設定項目の値が`0`より大きく、実際のクライアント接続数がこの値に達すると、TiDBサーバーは新しいクライアント接続を拒否します。 -- バージョン 6.2.0 以降、TiDB で許可される同時クライアント接続の最大数を設定するには、TiDB 構成項目[`instance.max_connections`](/tidb-configuration-file.md#max_connections)またはシステム変数[`max_connections`](/system-variables.md#max_connections)が使用されます。 `max-server-connections`は引き続き有効です。ただし、 `max-server-connections`と`instance.max_connections`が同時に設定されている場合、後者が有効になります。 +- TiDBで許可される同時クライアント接続の最大数。リソース制御に使用されます。 +- デフォルト値: `0` +- デフォルトでは、TiDB は同時クライアント接続数の制限を設定しません。この設定項目の値が`0`より大きく、実際のクライアント接続数がこの値に達すると、TiDBサーバーは新しいクライアント接続を拒否します。 +- バージョン 6.2.0 以降、TiDB で許可される同時クライアント接続の最大数を設定するには、TiDB 構成項目[`instance.max_connections`](/tidb-configuration-file.md#max_connections)またはシステム変数[`max_connections`](/system-variables.md#max_connections)が使用されます。 `max-server-connections`は引き続き有効です。ただし、 `max-server-connections`と`instance.max_connections`が同時に設定されている場合、後者が有効になります。 ### `max-index-length` {#max-index-length} -- 新しく作成されるインデックスの最大許容長を設定します。 -- デフォルト値: `3072` -- 単位：バイト -- 範囲: `[3072, 3072*4]` -- 互換性： - - MySQL: インデックスの最大長は3072バイトに固定されています。 - - TiDBの以前のバージョン： - - バージョン3.0.7以前：インデックスの最大長は3072×4バイトに固定されています。 - - v3.0.8 ～ v3.0.10: インデックスの最大長は3072バイトに固定されています。 - - v3.0.11以降のバージョンでは、TiDBはさまざまなTiDBバージョンおよびMySQLとの互換性を確保するために、 `max-index-length`構成項目を導入しました。 +- 新しく作成されるインデックスの最大許容長を設定します。 +- デフォルト値: `3072` +- 単位：バイト +- 範囲: `[3072, 3072*4]` +- 互換性： + - MySQL: インデックスの最大長は3072バイトに固定されています。 + - TiDBの以前のバージョン： + - バージョン3.0.7以前：インデックスの最大長は3072×4バイトに固定されています。 + - v3.0.8 ～ v3.0.10: インデックスの最大長は3072バイトに固定されています。 + - v3.0.11以降のバージョンでは、TiDBはさまざまなTiDBバージョンおよびMySQLとの互換性を確保するために、 `max-index-length`構成項目を導入しました。 ### `table-column-count-limit` v5.0の新機能 {#table-column-count-limit-new-in-v50} -- 単一テーブル内の列数の上限を設定します。 -- デフォルト値: `1017` -- 現在、有効な値の範囲は`[1017, 4096]`です。 +- 単一テーブル内の列数の上限を設定します。 +- デフォルト値: `1017` +- 現在、有効な値の範囲は`[1017, 4096]`です。 ### `index-limit` v5.0で追加 {#index-limit-new-in-v50} -- 単一テーブル内のインデックス数の上限を設定します。 -- デフォルト値: `64` -- 現在、有効な値の範囲は`[64, 512]`です。 +- 単一テーブル内のインデックス数の上限を設定します。 +- デフォルト値: `64` +- 現在、有効な値の範囲は`[64, 512]`です。 ### `enable-telemetry` v4.0.2の新機能 {#enable-telemetry-new-in-v402} > **Warning:** > -> - バージョン8.1.0から8.5.2までは、TiDBはテレメトリ機能を削除しており、この設定項目は無効になります。以前のバージョンとの互換性のためにのみ残されています。 -> - バージョン8.5.3から8.5.6までは、TiDBはテレメトリ機能を復活させました。ただし、テレメトリ関連の情報はローカルにのみ記録され、ネットワーク経由でPingCAPにデータは送信されなくなりました。 -> - v8.5.7以降、TiDBはこの設定項目とテレメトリ機能を非推奨にしました。 +> - バージョン8.1.0から8.5.2までは、TiDBはテレメトリ機能を削除しており、この設定項目は無効になります。以前のバージョンとの互換性のためにのみ残されています。 +> - バージョン8.5.3から8.5.6までは、TiDBはテレメトリ機能を復活させました。ただし、テレメトリ関連の情報はローカルにのみ記録され、ネットワーク経由でPingCAPにデータは送信されなくなりました。 +> - v8.5.7以降、TiDBはこの設定項目とテレメトリ機能を非推奨にしました。 -- TiDBインスタンスでテレメトリ収集を有効にするかどうかを制御します。 -- デフォルト値: `false` +- TiDBインスタンスでテレメトリ収集を有効にするかどうかを制御します。 +- デフォルト値: `false` ### `deprecate-integer-display-length` {#deprecate-integer-display-length} -- この構成項目が`true`に設定されている場合、整数型の表示幅は非推奨になります。 -- デフォルト値: `true` 。v8.5.0 より前のバージョンでは、デフォルト値は`false`です。 +- この構成項目が`true`に設定されている場合、整数型の表示幅は非推奨になります。 +- デフォルト値: `true` 。v8.5.0 より前のバージョンでは、デフォルト値は`false`です。 ### `enable-tcp4-only` v5.0の新機能 {#enable-tcp4-only-new-in-v50} -- TCP4のみでのリスニングを有効または無効にします。 -- デフォルト値: `false` -- [TCPヘッダーからの実際のクライアントIP](https://github.com/alibaba/LVS/tree/master/kernel/net/toa)が「tcp4」プロトコルで正しく解析できるため、ロード バランシングのために TiDB を LVS とともに使用する場合、このオプションを有効にすると便利です。 +- TCP4のみでのリスニングを有効または無効にします。 +- デフォルト値: `false` +- [TCPヘッダーからの実際のクライアントIP](https://github.com/alibaba/LVS/tree/master/kernel/net/toa)が「tcp4」プロトコルで正しく解析できるため、ロード バランシングのために TiDB を LVS とともに使用する場合、このオプションを有効にすると便利です。 ### `enable-enum-length-limit` v5.0で追加 {#enable-enum-length-limit-new-in-v50} -- 単一の`ENUM`要素と単一の`SET`要素の最大長を制限するかどうかを決定します。 -- デフォルト値: `true` -- この構成値が`true`の場合、単一の`ENUM`要素と単一の`SET`要素の最大長は 255 文字で、 [MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/string-type-syntax.html)と互換性があります。この構成値が`false`の場合、単一要素の長さに制限はなく、TiDB (v5.0 より前) と互換性があります。 +- 単一の`ENUM`要素と単一の`SET`要素の最大長を制限するかどうかを決定します。 +- デフォルト値: `true` +- この構成値が`true`の場合、単一の`ENUM`要素と単一の`SET`要素の最大長は 255 文字で、 [MySQL 8.0](https://dev.mysql.com/doc/refman/8.0/en/string-type-syntax.html)と互換性があります。この構成値が`false`の場合、単一要素の長さに制限はなく、TiDB (v5.0 より前) と互換性があります。 ### `graceful-wait-before-shutdown` （v5.0の新機能） {#graceful-wait-before-shutdown-new-in-v50} -- TiDBがサーバーをシャットダウンした際に待機する秒数を指定します。この待機時間により、クライアントは切断することができます。 -- デフォルト値: `0` -- TiDBがシャットダウンを待機しているとき（猶予期間中）、HTTPステータスは失敗を示し、ロードバランサーがトラフィックを再ルーティングできるようになります。TiDBは`COM_PING`コマンドに対してもエラーを返します。 +- TiDBがサーバーをシャットダウンした際に待機する秒数を指定します。この待機時間により、クライアントは切断することができます。 +- デフォルト値: `0` +- TiDBがシャットダウンを待機しているとき（猶予期間中）、HTTPステータスは失敗を示し、ロードバランサーがトラフィックを再ルーティングできるようになります。TiDBは`COM_PING`コマンドに対してもエラーを返します。 > **Note:** > > TiDBがサーバーをシャットダウンするまでの待機時間は、以下のパラメータによっても影響を受けます。 > -> - SystemD を使用するプラットフォームの場合、デフォルトの停止タイムアウトは 90 秒です。より長いタイムアウトが必要な場合は、 [`TimeoutStopSec=`](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#TimeoutStopSec=)を設定できます。 +> - SystemD を使用するプラットフォームの場合、デフォルトの停止タイムアウトは 90 秒です。より長いタイムアウトが必要な場合は、 [`TimeoutStopSec=`](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#TimeoutStopSec=)を設定できます。 > -> - TiUP クラスタコンポーネントを使用する場合、デフォルトの[`--wait-timeout`](/tiup/tiup-component-cluster.md#--wait-timeout)は120秒です。 +> - TiUP クラスタコンポーネントを使用する場合、デフォルトの[`--wait-timeout`](/tiup/tiup-component-cluster.md#--wait-timeout)は120秒です。 > -> - Kubernetesを使用する場合、デフォルトの[`terminationGracePeriodSeconds`](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#lifecycle)は30秒です。 +> - Kubernetesを使用する場合、デフォルトの[`terminationGracePeriodSeconds`](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#lifecycle)は30秒です。 ### `enable-global-kill` v6.1.0で追加 {#enable-global-kill-new-in-v610} -- グローバルキル（インスタンスをまたいでクエリや接続を終了する）機能を有効にするかどうかを制御します。 -- デフォルト値: `true` -- 値が`true`の場合、 `KILL`および`KILL TIDB`ステートメントはインスタンス間でクエリまたは接続を終了できるため、クエリまたは接続が誤って終了することを心配する必要はありません。クライアントを使用して任意の TiDB インスタンスに接続し、 `KILL`または`KILL TIDB`ステートメントを実行すると、ステートメントは対象の TiDB インスタンスに転送されます。クライアントと TiDB クラスタの間にプロキシがある場合、 `KILL`および`KILL TIDB`ステートメントも実行のために対象の TiDB インスタンスに転送されます。 -- バージョン7.3.0以降では、 `enable-global-kill`と[`enable-32bits-connection-id`](#enable-32bits-connection-id-new-in-v730)の両方が`true`に設定されている場合、MySQLコマンドラインのControl+Cを使用してクエリまたは接続を終了できます。詳細については、[`KILL`](/sql-statements/sql-statement-kill.md)参照してください。 +- グローバルキル（インスタンスをまたいでクエリや接続を終了する）機能を有効にするかどうかを制御します。 +- デフォルト値: `true` +- 値が`true`の場合、 `KILL`および`KILL TIDB`ステートメントはインスタンス間でクエリまたは接続を終了できるため、クエリまたは接続が誤って終了することを心配する必要はありません。クライアントを使用して任意の TiDB インスタンスに接続し、 `KILL`または`KILL TIDB`ステートメントを実行すると、ステートメントは対象の TiDB インスタンスに転送されます。クライアントと TiDB クラスタの間にプロキシがある場合、 `KILL`および`KILL TIDB`ステートメントも実行のために対象の TiDB インスタンスに転送されます。 +- バージョン7.3.0以降では、 `enable-global-kill`と[`enable-32bits-connection-id`](#enable-32bits-connection-id-new-in-v730)の両方が`true`に設定されている場合、MySQLコマンドラインのControl+Cを使用してクエリまたは接続を終了できます。詳細については、[`KILL`](/sql-statements/sql-statement-kill.md)参照してください。 ### `enable-32bits-connection-id` v7.3.0で追加 {#enable-32bits-connection-id-new-in-v730} -- 32ビット接続ID機能を有効にするかどうかを制御します。 -- デフォルト値: `true` -- この設定項目と[`enable-global-kill`](#enable-global-kill-new-in-v610)の両方が`true`に設定されている場合、TiDBは32ビットの接続IDを生成します。これにより、MySQLコマンドラインのControl+Cを使用してクエリまたは接続を終了できます。 +- 32ビット接続ID機能を有効にするかどうかを制御します。 +- デフォルト値: `true` +- この設定項目と[`enable-global-kill`](#enable-global-kill-new-in-v610)の両方が`true`に設定されている場合、TiDBは32ビットの接続IDを生成します。これにより、MySQLコマンドラインのControl+Cを使用してクエリまたは接続を終了できます。 > **Warning:** > @@ -240,17 +240,17 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも ### `initialize-sql-file` v6.6.0で追加 {#initialize-sql-file-new-in-v660} -- TiDBクラスタが初めて起動されたときに実行されるSQLスクリプトを指定します。 -- デフォルト値: `""` -- このスクリプト内のすべてのSQL文は、権限チェックなしで最高権限で実行されます。指定されたSQLスクリプトの実行に失敗すると、TiDBクラスタの起動に失敗する可能性があります。 -- この構成項目は、システム変数の値の変更、ユーザーの作成、権限の付与などの操作を実行するために使用されます。 +- TiDBクラスタが初めて起動されたときに実行されるSQLスクリプトを指定します。 +- デフォルト値: `""` +- このスクリプト内のすべてのSQL文は、権限チェックなしで最高権限で実行されます。指定されたSQLスクリプトの実行に失敗すると、TiDBクラスタの起動に失敗する可能性があります。 +- この構成項目は、システム変数の値の変更、ユーザーの作成、権限の付与などの操作を実行するために使用されます。 ### `enable-forwarding` v5.0.0の新機能 {#enable-forwarding-new-in-v500} -- TiDB内のPDクライアントとTiKVクライアントが、ネットワークが隔離された場合に、フォロワーを介してリーダーにリクエストを転送するかどうかを制御します。 -- デフォルト値: `false` -- 環境が孤立したネットワークである可能性がある場合、このパラメータを有効にすることで、サービスが利用できなくなる時間を短縮できます。 -- 隔離、ネットワーク障害、またはダウンタイムが発生したかどうかを正確に判断できない場合、このメカニズムを使用すると誤判断のリスクがあり、可用性とパフォーマンスが低下します。ネットワーク障害が一度も発生したことがない場合は、このパラメータを有効にすることは推奨されません。 +- TiDB内のPDクライアントとTiKVクライアントが、ネットワークが隔離された場合に、フォロワーを介してリーダーにリクエストを転送するかどうかを制御します。 +- デフォルト値: `false` +- 環境が孤立したネットワークである可能性がある場合、このパラメータを有効にすることで、サービスが利用できなくなる時間を短縮できます。 +- 隔離、ネットワーク障害、またはダウンタイムが発生したかどうかを正確に判断できない場合、このメカニズムを使用すると誤判断のリスクがあり、可用性とパフォーマンスが低下します。ネットワーク障害が一度も発生したことがない場合は、このパラメータを有効にすることは推奨されません。 ### `enable-table-lock` v4.0.0で追加 {#enable-table-lock-new-in-v400} @@ -258,19 +258,19 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも > > テーブルロック機能は実験的機能です。本番環境での使用は推奨されません。 -- テーブルロック機能を有効にするかどうかを制御します。 -- デフォルト値: `false` -- テーブルロックは、複数のセッション間で同じテーブルへの同時アクセスを調整するために使用されます。現在、 `READ` 、 `WRITE` 、および`WRITE LOCAL`ロックタイプがサポートされています。構成項目が`false`に設定されている場合、 `LOCK TABLES`または`UNLOCK TABLES`ステートメントを実行しても効果がなく、「LOCK/UNLOCK TABLES はサポートされていません」という警告が表示されます。詳細については、[`LOCK TABLES`と`UNLOCK TABLES`](/sql-statements/sql-statement-lock-tables-and-unlock-tables.md)を参照してください。 +- テーブルロック機能を有効にするかどうかを制御します。 +- デフォルト値: `false` +- テーブルロックは、複数のセッション間で同じテーブルへの同時アクセスを調整するために使用されます。現在、 `READ` 、 `WRITE` 、および`WRITE LOCAL`ロックタイプがサポートされています。構成項目が`false`に設定されている場合、 `LOCK TABLES`または`UNLOCK TABLES`ステートメントを実行しても効果がなく、「LOCK/UNLOCK TABLES はサポートされていません」という警告が表示されます。詳細については、[`LOCK TABLES`と`UNLOCK TABLES`](/sql-statements/sql-statement-lock-tables-and-unlock-tables.md)を参照してください。 ### `labels` {#labels} -- サーバーラベルを指定します。例: `{ zone = "us-west-1", dc = "dc1", rack = "rack1", host = "tidb1" }` 。 -- デフォルト値: `{}` +- サーバーラベルを指定します。例: `{ zone = "us-west-1", dc = "dc1", rack = "rack1", host = "tidb1" }` 。 +- デフォルト値: `{}` > **Note:** > -> - TiDBでは、 `zone`ラベルは、サーバーが配置されているゾーンを指定するために特別に使用されます。 `zone`がnull以外の値に設定されている場合、対応する値は[`txn-score`](/system-variables.md#txn_scope)や[`Follower read`](/follower-read.md)などの機能によって自動的に使用されます。 -> - `group`ラベルは、TiDB Operatorにおいて特別な用途があります。[TiDB Operator](/tidb-operator-overview.md)を使用してデプロイされたクラスタでは、 `group`ラベルを手動で指定することは推奨さ**れません**。 +> - TiDBでは、 `zone`ラベルは、サーバーが配置されているゾーンを指定するために特別に使用されます。 `zone`がnull以外の値に設定されている場合、対応する値は[`txn-score`](/system-variables.md#txn_scope)や[`Follower read`](/follower-read.md)などの機能によって自動的に使用されます。 +> - `group`ラベルは、TiDB Operatorにおいて特別な用途があります。[TiDB Operator](/tidb-operator-overview.md)を使用してデプロイされたクラスタでは、 `group`ラベルを手動で指定することは推奨さ**れません**。 ## log {#log} @@ -278,55 +278,55 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも ### `level` {#level} -- ログ出力レベルを指定します。 -- 値のオプション: `debug` 、 `info` 、 `warn` 、 `error` 、および`fatal` 。 -- デフォルト値: `info` +- ログ出力レベルを指定します。 +- 値のオプション: `debug` 、 `info` 、 `warn` 、 `error` 、および`fatal` 。 +- デフォルト値: `info` ### `format` {#format} -- ログ出力形式を指定します。 -- 値のオプション: `json`および`text` 。 -- デフォルト値: `text` +- ログ出力形式を指定します。 +- 値のオプション: `json`および`text` 。 +- デフォルト値: `text` ### `enable-timestamp` {#enable-timestamp} -- ログにタイムスタンプを出力するかどうかを決定します。 -- デフォルト値: `null` -- 値を`false`に設定すると、ログにタイムスタンプが出力されません。 +- ログにタイムスタンプを出力するかどうかを決定します。 +- デフォルト値: `null` +- 値を`false`に設定すると、ログにタイムスタンプが出力されません。 > **Note:** > -> - 下位互換性を維持するため、初期設定項目`disable-timestamp`は有効なままです。ただし、 `disable-timestamp`の値が`enable-timestamp`の値と意味的に競合する場合 (たとえば、 `enable-timestamp`と`disable-timestamp`両方が`true`に設定されている場合)、TiDB は`disable-timestamp`の値を無視します。 -> - 現在、TiDB は`disable-timestamp`を使用して、ログにタイムスタンプを出力するかどうかを判断します。この場合、 `enable-timestamp`の値は`null`になります。 -> - 後のバージョンでは、 `disable-timestamp`の設定は削除されます。 `disable-timestamp`は破棄し、意味的に理解しやすい`enable-timestamp`を使用してください。 +> - 下位互換性を維持するため、初期設定項目`disable-timestamp`は有効なままです。ただし、 `disable-timestamp`の値が`enable-timestamp`の値と意味的に競合する場合 (たとえば、 `enable-timestamp`と`disable-timestamp`両方が`true`に設定されている場合)、TiDB は`disable-timestamp`の値を無視します。 +> - 現在、TiDB は`disable-timestamp`を使用して、ログにタイムスタンプを出力するかどうかを判断します。この場合、 `enable-timestamp`の値は`null`になります。 +> - 後のバージョンでは、 `disable-timestamp`の設定は削除されます。 `disable-timestamp`は破棄し、意味的に理解しやすい`enable-timestamp`を使用してください。 ### `enable-slow-log` {#enable-slow-log} -- スロークエリログを有効にするかどうかを決定します。 -- デフォルト値: `true` -- スロークエリログを有効にするには、 `enable-slow-log`を`true`に設定してください。それ以外の場合は、 `false`に設定してください。 -- バージョン6.1.0以降、スロークエリログを有効にするかどうかは、TiDB構成アイテム[`instance.tidb_enable_slow_log`](/tidb-configuration-file.md#tidb_enable_slow_log)またはシステム変数[`tidb_enable_slow_log`](/system-variables.md#tidb_enable_slow_log)によって決定されます。 `enable-slow-log`は引き続き有効です。ただし、 `enable-slow-log`と`instance.tidb_enable_slow_log`が同時に設定されている場合、後者が有効になります。 +- スロークエリログを有効にするかどうかを決定します。 +- デフォルト値: `true` +- スロークエリログを有効にするには、 `enable-slow-log`を`true`に設定してください。それ以外の場合は、 `false`に設定してください。 +- バージョン6.1.0以降、スロークエリログを有効にするかどうかは、TiDB構成アイテム[`instance.tidb_enable_slow_log`](/tidb-configuration-file.md#tidb_enable_slow_log)またはシステム変数[`tidb_enable_slow_log`](/system-variables.md#tidb_enable_slow_log)によって決定されます。 `enable-slow-log`は引き続き有効です。ただし、 `enable-slow-log`と`instance.tidb_enable_slow_log`が同時に設定されている場合、後者が有効になります。 ### `slow-query-file` {#slow-query-file} -- スロークエリログのファイル名。 -- デフォルト値: `tidb-slow.log` -- TiDB v2.1.8ではスローログのフォーマットが更新され、スローログはスローログファイルに個別に出力されるようになりました。v2.1.8より前のバージョンでは、この変数はデフォルトで「」に設定されています。 -- 設定後、スロークエリのログはこのファイルに別途出力されます。 +- スロークエリログのファイル名。 +- デフォルト値: `tidb-slow.log` +- TiDB v2.1.8ではスローログのフォーマットが更新され、スローログはスローログファイルに個別に出力されるようになりました。v2.1.8より前のバージョンでは、この変数はデフォルトで「」に設定されています。 +- 設定後、スロークエリのログはこのファイルに別途出力されます。 ### `slow-threshold` {#slow-threshold} -- スローログに記録された、消費時間のしきい値を出力します。 -- デフォルト値: `300` -- 単位：ミリ秒 -- クエリの実行時間がこの値よりも長い場合、そのクエリはスロークエリとみなされ、そのログがスロークエリログに出力されます。なお、 [`log.level`](#level)の出力レベルが`"debug"`の場合、このパラメータの設定に関わらず、すべてのクエリがスロークエリログに記録されます。 -- バージョン 6.1.0 以降、スロー ログの消費時間のしきい値は、TiDB 設定項目の[`instance.tidb_slow_log_threshold`](/tidb-configuration-file.md#tidb_slow_log_threshold)またはシステム変数[`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold)で指定されます。 `slow-threshold`は引き続き有効です。ただし、 `slow-threshold`と`instance.tidb_slow_log_threshold`が同時に設定されている場合、後者が有効になります。 +- スローログに記録された、消費時間のしきい値を出力します。 +- デフォルト値: `300` +- 単位：ミリ秒 +- クエリの実行時間がこの値よりも長い場合、そのクエリはスロークエリとみなされ、そのログがスロークエリログに出力されます。なお、 [`log.level`](#level)の出力レベルが`"debug"`の場合、このパラメータの設定に関わらず、すべてのクエリがスロークエリログに記録されます。 +- バージョン 6.1.0 以降、スロー ログの消費時間のしきい値は、TiDB 設定項目の[`instance.tidb_slow_log_threshold`](/tidb-configuration-file.md#tidb_slow_log_threshold)またはシステム変数[`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold)で指定されます。 `slow-threshold`は引き続き有効です。ただし、 `slow-threshold`と`instance.tidb_slow_log_threshold`が同時に設定されている場合、後者が有効になります。 ### `record-plan-in-slow-log` {#record-plan-in-slow-log} -- 実行計画をスローログに記録するかどうかを決定します。 -- デフォルト値: `1` -- バージョン 6.1.0 以降、実行計画をスロー ログに記録するかどうかは、TiDB 設定項目の[`instance.tidb_record_plan_in_slow_log`](/tidb-configuration-file.md#tidb_record_plan_in_slow_log)またはシステム変数[`tidb_record_plan_in_slow_log`](/system-variables.md#tidb_record_plan_in_slow_log)によって決定されます。 `record-plan-in-slow-log`は引き続き有効です。ただし、 `record-plan-in-slow-log`と`instance.tidb_record_plan_in_slow_log`が同時に設定されている場合は、後者が有効になります。 +- 実行計画をスローログに記録するかどうかを決定します。 +- デフォルト値: `1` +- バージョン 6.1.0 以降、実行計画をスロー ログに記録するかどうかは、TiDB 設定項目の[`instance.tidb_record_plan_in_slow_log`](/tidb-configuration-file.md#tidb_record_plan_in_slow_log)またはシステム変数[`tidb_record_plan_in_slow_log`](/system-variables.md#tidb_record_plan_in_slow_log)によって決定されます。 `record-plan-in-slow-log`は引き続き有効です。ただし、 `record-plan-in-slow-log`と`instance.tidb_record_plan_in_slow_log`が同時に設定されている場合は、後者が有効になります。 ### `expensive-threshold` {#expensive-threshold} @@ -334,22 +334,22 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも > > バージョン5.4.0以降、 `expensive-threshold`構成項目は非推奨となり、システム変数[`tidb_expensive_query_time_threshold`](/system-variables.md#tidb_expensive_query_time_threshold)に置き換えられました。 -- `expensive`操作の行数のしきい値を出力します。 -- デフォルト値: `10000` -- クエリ行数（統計に基づく中間結果を含む）がこの値より大きい場合、 `expensive`操作となり、 `[EXPENSIVE_QUERY]`接頭辞が付いたログが出力されます。 +- `expensive`操作の行数のしきい値を出力します。 +- デフォルト値: `10000` +- クエリ行数（統計に基づく中間結果を含む）がこの値より大きい場合、 `expensive`操作となり、 `[EXPENSIVE_QUERY]`接頭辞が付いたログが出力されます。 ### `general-log-file` v8.0.0で追加 {#general-log-file-new-in-v800} -- [一般ログ](/system-variables.md#tidb_general_log)のファイル名。 -- デフォルト値: `""` -- ファイル名を指定すると、一般ログはこの指定されたファイルに書き込まれます。値が空白の場合は、一般ログは TiDB インスタンスのサーバーログに書き込まれます。サーバーログの名前は[`filename`](#filename)を使用して指定できます。 +- [一般ログ](/system-variables.md#tidb_general_log)のファイル名。 +- デフォルト値: `""` +- ファイル名を指定すると、一般ログはこの指定されたファイルに書き込まれます。値が空白の場合は、一般ログは TiDB インスタンスのサーバーログに書き込まれます。サーバーログの名前は[`filename`](#filename)を使用して指定できます。 ### `timeout` v7.1.0の新機能 {#timeout-new-in-v710} -- TiDBにおけるログ書き込み操作のタイムアウトを設定します。ディスク障害によりログの書き込みができない場合、この設定項目によってTiDBプロセスがハングアップするのではなく、panicになることがあります。 -- デフォルト値： `0` 。これはタイムアウトが設定されていないことを示します。 -- 単位：秒 -- 一部のユーザーシナリオでは、TiDBログがホットプラグ対応ディスクまたはネットワーク接続ディスクに保存されることがありますが、これらのディスクが永久的に使用不能になる可能性があります。このような場合、TiDBは自動的に復旧できず、ログ書き込み操作は永久的にブロックされます。TiDBプロセスは実行されているように見えても、実際にはどの要求にも応答しません。この設定項目は、このような状況に対処するために設計されています。 +- TiDBにおけるログ書き込み操作のタイムアウトを設定します。ディスク障害によりログの書き込みができない場合、この設定項目によってTiDBプロセスがハングアップするのではなく、panicになることがあります。 +- デフォルト値： `0` 。これはタイムアウトが設定されていないことを示します。 +- 単位：秒 +- 一部のユーザーシナリオでは、TiDBログがホットプラグ対応ディスクまたはネットワーク接続ディスクに保存されることがありますが、これらのディスクが永久的に使用不能になる可能性があります。このような場合、TiDBは自動的に復旧できず、ログ書き込み操作は永久的にブロックされます。TiDBプロセスは実行されているように見えても、実際にはどの要求にも応答しません。この設定項目は、このような状況に対処するために設計されています。 ### log.file {#logfile} @@ -357,35 +357,35 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも #### `filename` {#filename} -- 一般ログファイルのファイル名。 -- デフォルト値: "" -- 設定すると、ログはこのファイルに出力されます。 +- 一般ログファイルのファイル名。 +- デフォルト値: "" +- 設定すると、ログはこのファイルに出力されます。 #### `max-size` {#max-size} -- ログファイルのサイズ制限。 -- デフォルト値: 300 -- 単位: MB -- 最大値は4096です。 +- ログファイルのサイズ制限。 +- デフォルト値: 300 +- 単位: MB +- 最大値は4096です。 #### `max-days` {#max-days} -- ログが保持される最大日数。 -- デフォルト値: `0` -- デフォルトではログは保持されます。値を設定すると、期限切れのログは`max-days`の後にクリーンアップされます。 +- ログが保持される最大日数。 +- デフォルト値: `0` +- デフォルトではログは保持されます。値を設定すると、期限切れのログは`max-days`の後にクリーンアップされます。 #### `max-backups` {#max-backups} -- 保持するログの最大数。 -- デフォルト値: `0` -- デフォルトでは、すべてのログファイルが保持されます。 `7`に設定すると、最大で 7 つのログファイルが保持されます。 +- 保持するログの最大数。 +- デフォルト値: `0` +- デフォルトでは、すべてのログファイルが保持されます。 `7`に設定すると、最大で 7 つのログファイルが保持されます。 #### `compression` （v8.0.0の新機能） {#compression-new-in-v800} -- ログの圧縮方法。 -- デフォルト値: `""` -- 値のオプション: `""` 、 `"gzip"` -- デフォルト値は`""`で、これは圧縮なしを意味します。gzip 圧縮を有効にするには、この値を`"gzip"`に設定してください。圧縮を有効にすると、 [`slow-query-file`](#slow-query-file)や[`general-log-file`](#general-log-file-new-in-v800)など、すべてのログファイルが影響を受けます。 +- ログの圧縮方法。 +- デフォルト値: `""` +- 値のオプション: `""` 、 `"gzip"` +- デフォルト値は`""`で、これは圧縮なしを意味します。gzip 圧縮を有効にするには、この値を`"gzip"`に設定してください。圧縮を有効にすると、 [`slow-query-file`](#slow-query-file)や[`general-log-file`](#general-log-file-new-in-v800)など、すべてのログファイルが影響を受けます。 ## security {#security} @@ -393,60 +393,60 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも ### `enable-sem` {#enable-sem} -- セキュリティ強化モード（SEM）を有効にします。 -- デフォルト値: `false` -- SEM の状態は、システム変数[`tidb_enable_enhanced_security`](/system-variables.md#tidb_enable_enhanced_security)を通じて確認できます。 +- セキュリティ強化モード（SEM）を有効にします。 +- デフォルト値: `false` +- SEM の状態は、システム変数[`tidb_enable_enhanced_security`](/system-variables.md#tidb_enable_enhanced_security)を通じて確認できます。 ### `ssl-ca` {#ssl-ca} -- 信頼済みCA証明書（PEM形式）のファイルパス。 -- デフォルト値: "" -- このオプションと`--ssl-cert` 、 `--ssl-key`を同時に設定した場合、クライアントが証明書を提示すると、TiDB はこのオプションで指定された信頼済み CA のリストに基づいてクライアント証明書を認証します。認証に失敗した場合、接続は切断されます。 -- このオプションを設定した場合でも、クライアントが証明書を提示しない場合は、クライアント証明書の認証なしでセキュアな接続が継続されます。 +- 信頼済みCA証明書（PEM形式）のファイルパス。 +- デフォルト値: "" +- このオプションと`--ssl-cert` 、 `--ssl-key`を同時に設定した場合、クライアントが証明書を提示すると、TiDB はこのオプションで指定された信頼済み CA のリストに基づいてクライアント証明書を認証します。認証に失敗した場合、接続は切断されます。 +- このオプションを設定した場合でも、クライアントが証明書を提示しない場合は、クライアント証明書の認証なしでセキュアな接続が継続されます。 ### `ssl-cert` {#ssl-cert} -- PEM形式のSSL証明書のファイルパス。 -- デフォルト値: "" -- このオプションと`--ssl-key`を同時に設定すると、TiDB はクライアントが TLS を使用して TiDB に安全に接続することを許可します (ただし、強制はしません)。 -- 指定された証明書または秘密鍵が無効な場合、TiDBは通常どおり起動しますが、安全な接続を受信できません。 +- PEM形式のSSL証明書のファイルパス。 +- デフォルト値: "" +- このオプションと`--ssl-key`を同時に設定すると、TiDB はクライアントが TLS を使用して TiDB に安全に接続することを許可します (ただし、強制はしません)。 +- 指定された証明書または秘密鍵が無効な場合、TiDBは通常どおり起動しますが、安全な接続を受信できません。 ### `ssl-key` {#ssl-key} -- PEM形式のSSL証明書キーのファイルパス、つまり`--ssl-cert`で指定された証明書の秘密鍵。 -- デフォルト値: "" -- 現在、TiDBはパスワードで保護された秘密鍵の読み込みをサポートしていません。 +- PEM形式のSSL証明書キーのファイルパス、つまり`--ssl-cert`で指定された証明書の秘密鍵。 +- デフォルト値: "" +- 現在、TiDBはパスワードで保護された秘密鍵の読み込みをサポートしていません。 ### `cluster-ssl-ca` {#cluster-ssl-ca} -- TiKVまたはPDをTLSで接続するために使用されるCAルート証明書。 -- デフォルト値: "" +- TiKVまたはPDをTLSで接続するために使用されるCAルート証明書。 +- デフォルト値: "" ### `cluster-ssl-cert` {#cluster-ssl-cert} -- TiKVまたはPDをTLSで接続するために使用されるSSL証明書ファイルのパス。 -- デフォルト値: "" +- TiKVまたはPDをTLSで接続するために使用されるSSL証明書ファイルのパス。 +- デフォルト値: "" ### `cluster-ssl-key` {#cluster-ssl-key} -- TiKVまたはPDをTLSで接続するために使用されるSSL秘密鍵ファイルのパス。 -- デフォルト値: "" +- TiKVまたはPDをTLSで接続するために使用されるSSL秘密鍵ファイルのパス。 +- デフォルト値: "" ### `cluster-verify-cn` {#cluster-verify-cn} -- クライアントから提示される証明書において許容されるX.509共通名のリスト。提示された共通名がリスト内のいずれかのエントリと完全に一致する場合にのみ、リクエストが許可されます。 -- デフォルト値: []。これは、クライアント証明書のCNチェックが無効になっていることを意味します。 +- クライアントから提示される証明書において許容されるX.509共通名のリスト。提示された共通名がリスト内のいずれかのエントリと完全に一致する場合にのみ、リクエストが許可されます。 +- デフォルト値: []。これは、クライアント証明書のCNチェックが無効になっていることを意味します。 ### `spilled-file-encryption-method` {#spilled-file-encryption-method} -- 漏洩したファイルをディスクに保存する際に使用する暗号化方式を決定します。 -- デフォルト値： `"plaintext"` 。これは暗号化を無効にします。 -- オプション値： `"plaintext"`および`"aes128-ctr"` +- 漏洩したファイルをディスクに保存する際に使用する暗号化方式を決定します。 +- デフォルト値： `"plaintext"` 。これは暗号化を無効にします。 +- オプション値： `"plaintext"`および`"aes128-ctr"` ### `auto-tls` {#auto-tls} -- 起動時にTLS証明書を自動的に生成するかどうかを決定します。 -- デフォルト値: `false` +- 起動時にTLS証明書を自動的に生成するかどうかを決定します。 +- デフォルト値: `false` ### `tls-version` {#tls-version} @@ -454,38 +454,38 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも > > `"TLSv1.0"`および`"TLSv1.1"`プロトコルは TiDB v7.6.0 で非推奨となり、v8.0.0 で削除されます。 -- MySQLプロトコル接続に使用するTLSの最小バージョンを設定します。 -- デフォルト値は「」で、TLSv1.2以降のバージョンを許可します。TiDB v7.6.0より前のバージョンでは、デフォルト値はTLSv1.1以降のバージョンを許可します。 -- オプション値: `"TLSv1.2"`および`"TLSv1.3"` 。TiDB v8.0.0 より前のバージョンでは、 `"TLSv1.0"`および`"TLSv1.1"`も使用可能です。 +- MySQLプロトコル接続に使用するTLSの最小バージョンを設定します。 +- デフォルト値は「」で、TLSv1.2以降のバージョンを許可します。TiDB v7.6.0より前のバージョンでは、デフォルト値はTLSv1.1以降のバージョンを許可します。 +- オプション値: `"TLSv1.2"`および`"TLSv1.3"` 。TiDB v8.0.0 より前のバージョンでは、 `"TLSv1.0"`および`"TLSv1.1"`も使用可能です。 ### `auth-token-jwks` v6.4.0の新機能 {#auth-token-jwks-new-in-v640} -- [`tidb_auth_token`](/security-compatibility-with-mysql.md#tidb_auth_token)認証方式で使用するJSON Web Key Sets（JWKS）のローカルファイルパスを設定します。 -- デフォルト値: `""` +- [`tidb_auth_token`](/security-compatibility-with-mysql.md#tidb_auth_token)認証方式で使用するJSON Web Key Sets（JWKS）のローカルファイルパスを設定します。 +- デフォルト値: `""` ### `auth-token-refresh-interval` v6.4.0で追加 {#auth-token-refresh-interval-new-in-v640} -- [`tidb_auth_token`](/security-compatibility-with-mysql.md#tidb_auth_token)認証方式のJWKS更新間隔を設定します。 -- デフォルト値: `1h` +- [`tidb_auth_token`](/security-compatibility-with-mysql.md#tidb_auth_token)認証方式のJWKS更新間隔を設定します。 +- デフォルト値: `1h` ### `disconnect-on-expired-password` （v6.5.0の新機能） {#disconnect-on-expired-password-new-in-v650} -- パスワードの有効期限が切れたときに、TiDBがクライアント接続を切断するかどうかを決定します。 -- デフォルト値: `true` -- オプション値: `true` 、 `false` -- `true`に設定すると、パスワードの有効期限が切れたときにクライアント接続が切断されます。 `false`に設定すると、クライアント接続は「サンドボックスモード」に制限され、ユーザーはパスワードリセット操作のみを実行できます。 +- パスワードの有効期限が切れたときに、TiDBがクライアント接続を切断するかどうかを決定します。 +- デフォルト値: `true` +- オプション値: `true` 、 `false` +- `true`に設定すると、パスワードの有効期限が切れたときにクライアント接続が切断されます。 `false`に設定すると、クライアント接続は「サンドボックスモード」に制限され、ユーザーはパスワードリセット操作のみを実行できます。 ### `session-token-signing-cert` v6.4.0 の新機能 {#session-token-signing-cert-new-in-v640} -- [TiProxy](/tiproxy/tiproxy-overview.md)がセッション移行に使用する証明書ファイルのパス。 -- デフォルト値: "" -- 値が空の場合、TiProxy のセッション移行は失敗します。セッション移行を有効にするには、すべての TiDB ノードで同じ証明書とキーを設定する必要があります。つまり、すべての TiDB ノードに同じ証明書とキーを保存する必要があります。 +- [TiProxy](/tiproxy/tiproxy-overview.md)がセッション移行に使用する証明書ファイルのパス。 +- デフォルト値: "" +- 値が空の場合、TiProxy のセッション移行は失敗します。セッション移行を有効にするには、すべての TiDB ノードで同じ証明書とキーを設定する必要があります。つまり、すべての TiDB ノードに同じ証明書とキーを保存する必要があります。 ### `session-token-signing-key` v6.4.0 の新機能 {#session-token-signing-key-new-in-v640} -- [TiProxy](/tiproxy/tiproxy-overview.md)がセッション移行に使用するキーファイルのパス。 -- デフォルト値: "" -- [`session-token-signing-cert`](#session-token-signing-cert-new-in-v640)の説明を参照してください。 +- [TiProxy](/tiproxy/tiproxy-overview.md)がセッション移行に使用するキーファイルのパス。 +- デフォルト値: "" +- [`session-token-signing-cert`](#session-token-signing-cert-new-in-v640)の説明を参照してください。 ## performance {#performance} @@ -493,9 +493,9 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも ### `max-procs` {#max-procs} -- TiDBが使用するCPUの数。 -- デフォルト値: `0` -- デフォルト値の`0`は、マシン上のすべてのCPUを使用することを示します。nに設定すると、TiDBはn個のCPUを使用します。 +- TiDBが使用するCPUの数。 +- デフォルト値: `0` +- デフォルト値の`0`は、マシン上のすべてのCPUを使用することを示します。nに設定すると、TiDBはn個のCPUを使用します。 ### `server-memory-quota` v4.0.9の新機能 {#server-memory-quota-new-in-v409} @@ -503,57 +503,57 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも > > バージョン6.5.0以降、 `server-memory-quota`構成項目は非推奨となり、システム変数[`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)に置き換えられました。 -- tidb-serverインスタンスのメモリ使用量制限。 -- デフォルト値: `0` (バイト単位)。これはメモリ制限がないことを意味します。 +- tidb-serverインスタンスのメモリ使用量制限。 +- デフォルト値: `0` (バイト単位)。これはメモリ制限がないことを意味します。 ### `max-txn-ttl` {#max-txn-ttl} -- 単一のトランザクションがロックを保持できる最長時間。この時間を超えると、他のトランザクションによってトランザクションのロックが解除され、そのトランザクションを正常にコミットできなくなる可能性があります。 -- デフォルト値: `3600000` -- 単位：ミリ秒 -- この時間よりも長くロックを保持しているトランザクションは、コミットまたはロールバックのいずれかしか実行できません。コミットが成功しない場合もあります。 -- [`"bulk"` DMLモード](/system-variables.md#tidb_dml_type-new-in-v800)を使用して実行されるトランザクションの場合、最大TTLはこの設定項目の制限を超えることができます。最大値は、この設定項目と24時間のうち大きい方の値となります。 +- 単一のトランザクションがロックを保持できる最長時間。この時間を超えると、他のトランザクションによってトランザクションのロックが解除され、そのトランザクションを正常にコミットできなくなる可能性があります。 +- デフォルト値: `3600000` +- 単位：ミリ秒 +- この時間よりも長くロックを保持しているトランザクションは、コミットまたはロールバックのいずれかしか実行できません。コミットが成功しない場合もあります。 +- [`"bulk"` DMLモード](/system-variables.md#tidb_dml_type-new-in-v800)を使用して実行されるトランザクションの場合、最大TTLはこの設定項目の制限を超えることができます。最大値は、この設定項目と24時間のうち大きい方の値となります。 ### `stmt-count-limit` {#stmt-count-limit} -- TiDBトランザクション1回で許可されるステートメントの最大数。 -- デフォルト値: `5000` -- ステートメント数が`stmt-count-limit`を超えた後にトランザクションがロールバックまたはコミットされない場合、TiDB は`statement count 5001 exceeds the transaction limitation, autocommit = false`エラーを返します。この設定は、再試行可能な楽観的トランザクションで**のみ**有効です。悲観的トランザクションを使用している場合、またはトランザクションの再試行を無効にしている場合は、トランザクション内のステートメント数はこの設定によって制限されません。 +- TiDBトランザクション1回で許可されるステートメントの最大数。 +- デフォルト値: `5000` +- ステートメント数が`stmt-count-limit`を超えた後にトランザクションがロールバックまたはコミットされない場合、TiDB は`statement count 5001 exceeds the transaction limitation, autocommit = false`エラーを返します。この設定は、再試行可能な楽観的トランザクションで**のみ**有効です。悲観的トランザクションを使用している場合、またはトランザクションの再試行を無効にしている場合は、トランザクション内のステートメント数はこの設定によって制限されません。 ### `txn-entry-size-limit` v4.0.10 および v5.0.0 で追加 {#txn-entry-size-limit-new-in-v4010-and-v500} -- TiDBにおける単一行データのサイズ制限。 -- デフォルト値: `6291456` (バイト単位) -- トランザクション内の単一のキー値レコードのサイズ制限。サイズ制限を超えると、TiDB は`entry too large`エラーを返します。この構成項目の最大値は`125829120` (120 MB) を超えません。 -- バージョン7.6.0以降では、システム変数[`tidb_txn_entry_size_limit`](/system-variables.md#tidb_txn_entry_size_limit-new-in-v760)を使用して、この設定項目の値を動的に変更できます。 -- TiKVにも同様の制限があることに注意してください。単一の書き込みリクエストのデータサイズが、デフォルトで8MBに設定されている[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)を超えると、TiKVはこのリクエストの処理を拒否します。テーブルに大きな行がある場合は、両方の設定を同時に変更する必要があります。 -- [`max_allowed_packet`](/system-variables.md#max_allowed_packet-new-in-v610) （MySQLプロトコルのパケットの最大サイズ）のデフォルト値は67108864（64 MiB）です。行が`max_allowed_packet`より大きい場合、行は切り捨てられます。 -- [`txn-total-size-limit`](#txn-total-size-limit) （TiDBにおける単一トランザクションのサイズ制限）のデフォルト値は100 MiBです。 `txn-entry-size-limit`の値を100 MiB以上に増やす場合は、 `txn-total-size-limit`の値もそれに合わせて増やす必要があります。 +- TiDBにおける単一行データのサイズ制限。 +- デフォルト値: `6291456` (バイト単位) +- トランザクション内の単一のキー値レコードのサイズ制限。サイズ制限を超えると、TiDB は`entry too large`エラーを返します。この構成項目の最大値は`125829120` (120 MB) を超えません。 +- バージョン7.6.0以降では、システム変数[`tidb_txn_entry_size_limit`](/system-variables.md#tidb_txn_entry_size_limit-new-in-v760)を使用して、この設定項目の値を動的に変更できます。 +- TiKVにも同様の制限があることに注意してください。単一の書き込みリクエストのデータサイズが、デフォルトで8MBに設定されている[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)を超えると、TiKVはこのリクエストの処理を拒否します。テーブルに大きな行がある場合は、両方の設定を同時に変更する必要があります。 +- [`max_allowed_packet`](/system-variables.md#max_allowed_packet-new-in-v610) （MySQLプロトコルのパケットの最大サイズ）のデフォルト値は67108864（64 MiB）です。行が`max_allowed_packet`より大きい場合、行は切り捨てられます。 +- [`txn-total-size-limit`](#txn-total-size-limit) （TiDBにおける単一トランザクションのサイズ制限）のデフォルト値は100 MiBです。 `txn-entry-size-limit`の値を100 MiB以上に増やす場合は、 `txn-total-size-limit`の値もそれに合わせて増やす必要があります。 ### `txn-total-size-limit` {#txn-total-size-limit} -- TiDBにおける単一トランザクションのサイズ制限。 -- デフォルト値: `104857600` (バイト単位) -- 単一のトランザクションにおいて、キーと値のレコードの合計サイズはこの値を超えることはできません。このパラメータの最大値は`1099511627776` (1 TB) です。 -- TiDB v6.5.0 以降のバージョンでは、この設定は推奨されなくなりました。トランザクションのメモリサイズはセッションのメモリ使用量に累積され、セッションのメモリしきい値を超えると[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)変数が有効になります。以前のバージョンとの互換性を保つため、以前のバージョンから TiDB v6.5.0 以降にアップグレードする場合、この設定は次のように動作します。 - - この設定が設定されていないか、デフォルト値 ( `104857600` ) に設定されている場合、アップグレード後にトランザクションのメモリサイズがセッションのメモリ使用量に累積され、 `tidb_mem_quota_query`変数が有効になります。 - - この設定がデフォルト設定（ `104857600` ）になっていない場合でも、設定は有効であり、単一トランザクションのサイズを制御する動作はアップグレード前後で変わりません。つまり、トランザクションのメモリサイズは`tidb_mem_quota_query`変数によって制御されません。 -- TiDB が[`tidb_dml_type`](/system-variables.md#tidb_dml_type-new-in-v800) `"bulk"`モードでトランザクションを実行する場合、トランザクションのサイズは TiDB 構成項目[`txn-total-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-total-size-limit)によって制限されません。 +- TiDBにおける単一トランザクションのサイズ制限。 +- デフォルト値: `104857600` (バイト単位) +- 単一のトランザクションにおいて、キーと値のレコードの合計サイズはこの値を超えることはできません。このパラメータの最大値は`1099511627776` (1 TB) です。 +- TiDB v6.5.0 以降のバージョンでは、この設定は推奨されなくなりました。トランザクションのメモリサイズはセッションのメモリ使用量に累積され、セッションのメモリしきい値を超えると[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)変数が有効になります。以前のバージョンとの互換性を保つため、以前のバージョンから TiDB v6.5.0 以降にアップグレードする場合、この設定は次のように動作します。 + - この設定が設定されていないか、デフォルト値 ( `104857600` ) に設定されている場合、アップグレード後にトランザクションのメモリサイズがセッションのメモリ使用量に累積され、 `tidb_mem_quota_query`変数が有効になります。 + - この設定がデフォルト設定（ `104857600` ）になっていない場合でも、設定は有効であり、単一トランザクションのサイズを制御する動作はアップグレード前後で変わりません。つまり、トランザクションのメモリサイズは`tidb_mem_quota_query`変数によって制御されません。 +- TiDB が[`tidb_dml_type`](/system-variables.md#tidb_dml_type-new-in-v800) `"bulk"`モードでトランザクションを実行する場合、トランザクションのサイズは TiDB 構成項目[`txn-total-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-total-size-limit)によって制限されません。 ### `tcp-keep-alive` {#tcp-keep-alive} -- TCPレイヤーで`keepalive`を有効にするかどうかを決定します。 -- デフォルト値: `true` +- TCPレイヤーで`keepalive`を有効にするかどうかを決定します。 +- デフォルト値: `true` ### `tcp-no-delay` {#tcp-no-delay} -- TCPレイヤーでTCP_NODELAYを有効にするかどうかを決定します。有効にすると、TiDBはTCP/IPプロトコルのNagleアルゴリズムを無効にし、小さなデータパケットを送信してネットワークレイテンシーを低減します。これは、送信データ量が少なく、遅延に敏感なアプリケーションに適しています。 -- デフォルト値: `true` +- TCPレイヤーでTCP_NODELAYを有効にするかどうかを決定します。有効にすると、TiDBはTCP/IPプロトコルのNagleアルゴリズムを無効にし、小さなデータパケットを送信してネットワークレイテンシーを低減します。これは、送信データ量が少なく、遅延に敏感なアプリケーションに適しています。 +- デフォルト値: `true` ### `cross-join` {#cross-join} -- デフォルト値: `true` -- TiDB は、デフォルトでは、両方のテーブルの条件 ( `WHERE`フィールド) なしで`JOIN`ステートメントを実行することをサポートしています。値を`false`に設定すると、そのような`JOIN`ステートメントが現れたときにサーバーは実行を拒否します。 +- デフォルト値: `true` +- TiDB は、デフォルトでは、両方のテーブルの条件 ( `WHERE`フィールド) なしで`JOIN`ステートメントを実行することをサポートしています。値を`false`に設定すると、そのような`JOIN`ステートメントが現れたときにサーバーは実行を拒否します。 > **Note:** > @@ -561,31 +561,31 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも ### `stats-lease` {#stats-lease} -- 統計情報の再読み込み、テーブル行数の更新、自動分析の実行が必要かどうかの確認、フィードバックを使用した統計情報の更新、および列の統計情報の読み込みを行う時間間隔。 -- デフォルト値: `3s` - - `stats-lease`間隔で、TiDB は統計情報の更新をチェックし、更新が存在する場合はそれをメモリに更新します。 - - `20 * stats-lease`間隔で、TiDB は DML によって生成された行の総数と変更された行の数をシステム テーブルに更新します。 - - `stats-lease`の間隔で、TiDB は自動分析が必要なテーブルとインデックスをチェックします。 - - `stats-lease`の間隔で、TiDB はメモリにロードする必要のある列統計をチェックします。 - - `200 * stats-lease`の間隔で、TiDB はメモリにキャッシュされたフィードバックをシステム テーブルに書き込みます。 - - `5 * stats-lease`の間隔で、TiDB はシステム テーブル内のフィードバックを読み取り、メモリにキャッシュされた統計情報を更新します。 -- `stats-lease`を 0s に設定すると、TiDB はシステム テーブル内のフィードバックを定期的に読み取り、メモリにキャッシュされた統計情報を 3 秒ごとに更新します。ただし、TiDB は、以下の統計情報関連のシステム テーブルを自動的に変更しなくなります。 - - `mysql.stats_meta` : TiDB は、トランザクションによって変更されたテーブル行の数を自動的に記録し、このシステム テーブルに更新しなくなりました。 - - `mysql.stats_histograms` / `mysql.stats_buckets`および`mysql.stats_top_n` : TiDB は統計情報を自動的に分析して積極的に更新しなくなりました。 - - `mysql.stats_feedback` : TiDB は、クエリされたデータによって返される統計情報の一部に基づいて、テーブルとインデックスの統計情報を更新しなくなりました。 +- 統計情報の再読み込み、テーブル行数の更新、自動分析の実行が必要かどうかの確認、フィードバックを使用した統計情報の更新、および列の統計情報の読み込みを行う時間間隔。 +- デフォルト値: `3s` + - `stats-lease`間隔で、TiDB は統計情報の更新をチェックし、更新が存在する場合はそれをメモリに更新します。 + - `20 * stats-lease`間隔で、TiDB は DML によって生成された行の総数と変更された行の数をシステム テーブルに更新します。 + - `stats-lease`の間隔で、TiDB は自動分析が必要なテーブルとインデックスをチェックします。 + - `stats-lease`の間隔で、TiDB はメモリにロードする必要のある列統計をチェックします。 + - `200 * stats-lease`の間隔で、TiDB はメモリにキャッシュされたフィードバックをシステム テーブルに書き込みます。 + - `5 * stats-lease`の間隔で、TiDB はシステム テーブル内のフィードバックを読み取り、メモリにキャッシュされた統計情報を更新します。 +- `stats-lease`を 0s に設定すると、TiDB はシステム テーブル内のフィードバックを定期的に読み取り、メモリにキャッシュされた統計情報を 3 秒ごとに更新します。ただし、TiDB は、以下の統計情報関連のシステム テーブルを自動的に変更しなくなります。 + - `mysql.stats_meta` : TiDB は、トランザクションによって変更されたテーブル行の数を自動的に記録し、このシステム テーブルに更新しなくなりました。 + - `mysql.stats_histograms` / `mysql.stats_buckets`および`mysql.stats_top_n` : TiDB は統計情報を自動的に分析して積極的に更新しなくなりました。 + - `mysql.stats_feedback` : TiDB は、クエリされたデータによって返される統計情報の一部に基づいて、テーブルとインデックスの統計情報を更新しなくなりました。 ### `pseudo-estimate-ratio` {#pseudo-estimate-ratio} -- テーブル内の（変更された行数）／（総行数）の比率。この値を超えると、システムは統計情報が期限切れになったと判断し、擬似統計情報を使用します。 -- デフォルト値: `0.8` -- 最小値は`0`で、最大値は`1`です。 +- テーブル内の（変更された行数）／（総行数）の比率。この値を超えると、システムは統計情報が期限切れになったと判断し、擬似統計情報を使用します。 +- デフォルト値: `0.8` +- 最小値は`0`で、最大値は`1`です。 ### `force-priority` {#force-priority} -- すべてのステートメントの優先順位を設定します。 -- デフォルト値: `NO_PRIORITY` -- 値のオプション: デフォルト値`NO_PRIORITY` 、ステートメントの優先順位が強制的に変更されないことを意味します。その他のオプションは、昇順で`LOW_PRIORITY`、`DELAYED`、`HIGH_PRIORITY`です。 -- バージョン6.1.0以降、すべてのステートメントの優先順位は、TiDB構成アイテム[`instance.tidb_force_priority`](/tidb-configuration-file.md#tidb_force_priority)またはシステム変数[`tidb_force_priority`](/system-variables.md#tidb_force_priority)によって決定されます。 `force-priority`は引き続き有効です。ただし、 `force-priority`と`instance.tidb_force_priority`が同時に設定されている場合、後者が有効になります。 +- すべてのステートメントの優先順位を設定します。 +- デフォルト値: `NO_PRIORITY` +- 値のオプション: デフォルト値`NO_PRIORITY` 、ステートメントの優先順位が強制的に変更されないことを意味します。その他のオプションは、昇順で`LOW_PRIORITY`、`DELAYED`、`HIGH_PRIORITY`です。 +- バージョン6.1.0以降、すべてのステートメントの優先順位は、TiDB構成アイテム[`instance.tidb_force_priority`](/tidb-configuration-file.md#tidb_force_priority)またはシステム変数[`tidb_force_priority`](/system-variables.md#tidb_force_priority)によって決定されます。 `force-priority`は引き続き有効です。ただし、 `force-priority`と`instance.tidb_force_priority`が同時に設定されている場合、後者が有効になります。 > **Note:** > @@ -593,56 +593,56 @@ TiDB 構成ファイルは、コマンドライン パラメーターよりも ### `distinct-agg-push-down` {#distinct-agg-push-down} -- オプティマイザが`Distinct` (例えば`select count(distinct a) from t` ) を使用して集約関数をコプロセッサにプッシュダウンする操作を実行するかどうかを決定します。 -- デフォルト: `false` -- この変数は、システム変数[`tidb_opt_distinct_agg_push_down`](/system-variables.md#tidb_opt_distinct_agg_push_down)の初期値です。 +- オプティマイザが`Distinct` (例えば`select count(distinct a) from t` ) を使用して集約関数をコプロセッサにプッシュダウンする操作を実行するかどうかを決定します。 +- デフォルト: `false` +- この変数は、システム変数[`tidb_opt_distinct_agg_push_down`](/system-variables.md#tidb_opt_distinct_agg_push_down)の初期値です。 ### `enforce-mpp` {#enforce-mpp} -- オプティマイザのコスト見積もりを無視し、クエリ実行にTiFlashのMPPモードを強制的に使用するかどうかを決定します。 -- デフォルト値: `false` -- この設定項目は、 [`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-new-in-v51)の初期値を制御します。たとえば、この設定項目が`true`に設定されている場合、 `tidb_enforce_mpp`のデフォルト値は`ON`になります。 +- オプティマイザのコスト見積もりを無視し、クエリ実行にTiFlashのMPPモードを強制的に使用するかどうかを決定します。 +- デフォルト値: `false` +- この設定項目は、 [`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-new-in-v51)の初期値を制御します。たとえば、この設定項目が`true`に設定されている場合、 `tidb_enforce_mpp`のデフォルト値は`ON`になります。 ### `enable-stats-cache-mem-quota` v6.1.0で追加 {#enable-stats-cache-mem-quota-new-in-v610} -- 統計キャッシュのメモリ割り当てを有効にするかどうかを制御します。 -- デフォルト値: `true` +- 統計キャッシュのメモリ割り当てを有効にするかどうかを制御します。 +- デフォルト値: `true` ### `stats-load-concurrency` v5.4.0の新機能 {#stats-load-concurrency-new-in-v540} -- TiDBの同期統計情報読み込み機能が同時に処理できる列の最大数。 -- デフォルト値: `0` 。v8.2.0 より前のバージョンでは、デフォルト値は`5`です。 -- 現在、有効な値の範囲は`[0, 128]`です。値`0`は自動モードを意味し、サーバーの設定に基づいて同時実行数を自動的に調整します。v8.2.0 より前のバージョンでは、最小値は`1`でした。 +- TiDBの同期統計情報読み込み機能が同時に処理できる列の最大数。 +- デフォルト値: `0` 。v8.2.0 より前のバージョンでは、デフォルト値は`5`です。 +- 現在、有効な値の範囲は`[0, 128]`です。値`0`は自動モードを意味し、サーバーの設定に基づいて同時実行数を自動的に調整します。v8.2.0 より前のバージョンでは、最小値は`1`でした。 ### `stats-load-queue-size` v5.4.0で追加 {#stats-load-queue-size-new-in-v540} -- TiDBの同期統計情報読み込み機能がキャッシュできる列リクエストの最大数。 -- デフォルト値: `1000` -- 現在、有効な値の範囲は`[1, 100000]`です。 +- TiDBの同期統計情報読み込み機能がキャッシュできる列リクエストの最大数。 +- デフォルト値: `1000` +- 現在、有効な値の範囲は`[1, 100000]`です。 ### `concurrently-init-stats` v8.1.0 および v7.5.2 で追加 {#concurrently-init-stats-new-in-v810-and-v752} -- TiDB の起動時に統計情報を同時に初期化するかどうかを制御します。この設定項目は、 [`lite-init-stats`](#lite-init-stats-new-in-v710)が`false`に設定されている場合にのみ有効になります。 -- デフォルト値: v8.2.0 より前のバージョンでは`false` 、v8.2.0 以降のバージョンでは`true` 。 +- TiDB の起動時に統計情報を同時に初期化するかどうかを制御します。この設定項目は、 [`lite-init-stats`](#lite-init-stats-new-in-v710)が`false`に設定されている場合にのみ有効になります。 +- デフォルト値: v8.2.0 より前のバージョンでは`false` 、v8.2.0 以降のバージョンでは`true` 。 ### `lite-init-stats` v7.1.0の新機能 {#lite-init-stats-new-in-v710} -- 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)を参照してください。 +- 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)を参照してください。 ### `force-init-stats` v6.5.7 および v7.1.0 で追加 {#force-init-stats-new-in-v657-and-v710} -- TiDBの起動時に、サービスを提供する前に統計情報の初期化が完了するまで待機するかどうかを制御します。 -- デフォルト値: v7.2.0 より前のバージョンでは`false` 、v7.2.0 以降のバージョンでは`true` 。 -- `force-init-stats`の値が`true`の場合、TiDB は起動時にサービスを提供する前に、統計情報の初期化が完了するまで待機する必要があります。テーブルとパーティションの数が多く、lite-init-stats の値が`false`の場合、 `force-init-stats`を`true`に設定すると、 [`lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-new-in-v710)がサービスの提供を開始するまでの時間が長くなる可能性があることに注意してください。 -- `force-init-stats`の値が`false`の場合、統計情報の初期化が完了する前に TiDB はサービスを提供できますが、オプティマイザは擬似統計情報を使用して決定を行うため、最適ではない実行計画になる可能性があります。 +- TiDBの起動時に、サービスを提供する前に統計情報の初期化が完了するまで待機するかどうかを制御します。 +- デフォルト値: v7.2.0 より前のバージョンでは`false` 、v7.2.0 以降のバージョンでは`true` 。 +- `force-init-stats`の値が`true`の場合、TiDB は起動時にサービスを提供する前に、統計情報の初期化が完了するまで待機する必要があります。テーブルとパーティションの数が多く、lite-init-stats の値が`false`の場合、 `force-init-stats`を`true`に設定すると、 [`lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-new-in-v710)がサービスの提供を開始するまでの時間が長くなる可能性があることに注意してください。 +- `force-init-stats`の値が`false`の場合、統計情報の初期化が完了する前に TiDB はサービスを提供できますが、オプティマイザは擬似統計情報を使用して決定を行うため、最適ではない実行計画になる可能性があります。 ### `enable-async-batch-get` v8.5.5で追加 {#enable-async-batch-get-new-in-v855} -- TiDBがバッチ取得演算子を実行する際に非同期モードを使用するかどうかを制御します。非同期モードを使用すると、ゴルーチンのオーバーヘッドを削減し、パフォーマンスを向上させることができます。通常、この設定項目を変更する必要はありません。 -- デフォルト値: `false` +- TiDBがバッチ取得演算子を実行する際に非同期モードを使用するかどうかを制御します。非同期モードを使用すると、ゴルーチンのオーバーヘッドを削減し、パフォーマンスを向上させることができます。通常、この設定項目を変更する必要はありません。 +- デフォルト値: `false` ## opentracing {#opentracing} @@ -650,13 +650,13 @@ OpenTracingに関連するコンフィグレーション項目。 ### `enable` {#enable} -- 一部のTiDBコンポーネントの呼び出しオーバーヘッドをトレースするために、opentracingを有効にします。opentracingを有効にすると、パフォーマンスが低下することに注意してください。 -- デフォルト値: `false` +- 一部のTiDBコンポーネントの呼び出しオーバーヘッドをトレースするために、opentracingを有効にします。opentracingを有効にすると、パフォーマンスが低下することに注意してください。 +- デフォルト値: `false` ### `rpc-metrics` {#rpc-metrics} -- RPCメトリクスを有効にします。 -- デフォルト値: `false` +- RPCメトリクスを有効にします。 +- デフォルト値: `false` ### opentracing.sampler {#opentracingsampler} @@ -664,33 +664,33 @@ opentracing.sampler に関連するコンフィグレーション項目。 #### `type` {#type} -- OpenTracingサンプラーのタイプを指定します。文字列値は大文字と小文字を区別しません。 -- デフォルト値: `"const"` -- 値のオプション: `"const"` 、 `"probabilistic"` 、 `"ratelimiting"` 、 `"remote"` +- OpenTracingサンプラーのタイプを指定します。文字列値は大文字と小文字を区別しません。 +- デフォルト値: `"const"` +- 値のオプション: `"const"` 、 `"probabilistic"` 、 `"ratelimiting"` 、 `"remote"` #### `param` {#param} -- OpenTracingサンプラーのパラメータ。 - - `const`タイプの場合、値は`0`または`1`となり、これは`const`サンプラーを有効にするかどうかを示します。 - - `probabilistic`タイプの場合、パラメータはサンプリング確率を指定します。サンプリング確率は、 `0`から`1`までの浮動小数点数になります。 - - `ratelimiting`タイプの場合、パラメータは 1 秒あたりにサンプリングされるスパンの数を指定します。 - - `remote`タイプの場合、パラメータはサンプリング確率を指定します。サンプリング確率は、 `0`から`1`までの浮動小数点数になります。 -- デフォルト値: `1.0` +- OpenTracingサンプラーのパラメータ。 + - `const`タイプの場合、値は`0`または`1`となり、これは`const`サンプラーを有効にするかどうかを示します。 + - `probabilistic`タイプの場合、パラメータはサンプリング確率を指定します。サンプリング確率は、 `0`から`1`までの浮動小数点数になります。 + - `ratelimiting`タイプの場合、パラメータは 1 秒あたりにサンプリングされるスパンの数を指定します。 + - `remote`タイプの場合、パラメータはサンプリング確率を指定します。サンプリング確率は、 `0`から`1`までの浮動小数点数になります。 +- デフォルト値: `1.0` #### `sampling-server-url` {#sampling-server-url} -- jaeger-agent サンプリングサーバーの HTTP URL。 -- デフォルト値: `""` +- jaeger-agent サンプリングサーバーの HTTP URL。 +- デフォルト値: `""` #### `max-operations` {#max-operations} -- サンプラーがトレースできる操作の最大数。操作がトレースされない場合は、デフォルトの確率的サンプラーが使用されます。 -- デフォルト値: `0` +- サンプラーがトレースできる操作の最大数。操作がトレースされない場合は、デフォルトの確率的サンプラーが使用されます。 +- デフォルト値: `0` #### `sampling-refresh-interval` {#sampling-refresh-interval} -- jaeger-agentのサンプリングポリシーをポーリングする頻度を制御します。 -- デフォルト値: `0` +- jaeger-agentのサンプリングポリシーをポーリングする頻度を制御します。 +- デフォルト値: `0` ### opentracing.reporter {#opentracingreporter} @@ -698,58 +698,58 @@ opentracing.reporter に関連するコンフィグレーション項目。 #### `queue-size` {#queue-size} -- レポーターがメモリ内に記録するキューのサイズ。 -- デフォルト値: `0` +- レポーターがメモリ内に記録するキューのサイズ。 +- デフォルト値: `0` #### `buffer-flush-interval` {#buffer-flush-interval} -- レポーターがメモリ内のスパンをストレージにフラッシュする間隔。 -- デフォルト値: `0` +- レポーターがメモリ内のスパンをストレージにフラッシュする間隔。 +- デフォルト値: `0` #### `log-spans` {#log-spans} -- 送信されたすべてのスパンのログを出力するかどうかを決定します。 -- デフォルト値: `false` +- 送信されたすべてのスパンのログを出力するかどうかを決定します。 +- デフォルト値: `false` #### `local-agent-host-port` {#local-agent-host-port} -- レポーターがスパンを jaeger-agent に送信する宛先アドレス。 -- デフォルト値: `""` +- レポーターがスパンを jaeger-agent に送信する宛先アドレス。 +- デフォルト値: `""` ## pd-client {#pd-client} ### `pd-server-timeout` {#pd-server-timeout} -- TiDBがPDクライアントを介してPDノードにリクエストを送信する際のタイムアウト時間。 -- デフォルト値: 3 -- 単位：秒 +- TiDBがPDクライアントを介してPDノードにリクエストを送信する際のタイムアウト時間。 +- デフォルト値: 3 +- 単位：秒 ## tikv-client {#tikv-client} ### `grpc-connection-count` {#grpc-connection-count} -- 各TiKVとの間で確立できる最大接続数。 -- デフォルト値: `4` +- 各TiKVとの間で確立できる最大接続数。 +- デフォルト値: `4` ### `grpc-keepalive-time` {#grpc-keepalive-time} -- TiDBノードとTiKVノード間のRPC接続の`keepalive`時間間隔。指定された時間間隔内にネットワークパケットがない場合、gRPCクライアントは`ping`コマンドをTiKVに実行して、TiKVがアクティブかどうかを確認します。 -- デフォルト: `10` -- 最小値: `1` -- 単位：秒 +- TiDBノードとTiKVノード間のRPC接続の`keepalive`時間間隔。指定された時間間隔内にネットワークパケットがない場合、gRPCクライアントは`ping`コマンドをTiKVに実行して、TiKVがアクティブかどうかを確認します。 +- デフォルト: `10` +- 最小値: `1` +- 単位：秒 ### `grpc-keepalive-timeout` {#grpc-keepalive-timeout} -- TiDBノードとTiKVノード間のRPC `keepalive`チェックのタイムアウト。 -- デフォルト値: `3` -- 最小値: `0.05` -- 単位：秒 +- TiDBノードとTiKVノード間のRPC `keepalive`チェックのタイムアウト。 +- デフォルト値: `3` +- 最小値: `0.05` +- 単位：秒 ### `grpc-compression-type` {#grpc-compression-type} -- TiDBノードからTiKVノードへのデータ転送に使用される圧縮タイプを指定します。デフォルト値は`"none"`で、これは圧縮なしを意味します。gzip圧縮を有効にするには、この値を`"gzip"`に設定します。 -- デフォルト値: `"none"` -- 値のオプション: `"none"` 、 `"gzip"` +- TiDBノードからTiKVノードへのデータ転送に使用される圧縮タイプを指定します。デフォルト値は`"none"`で、これは圧縮なしを意味します。gzip圧縮を有効にするには、この値を`"gzip"`に設定します。 +- デフォルト値: `"none"` +- 値のオプション: `"none"` 、 `"gzip"` > **Note:** > @@ -757,41 +757,41 @@ opentracing.reporter に関連するコンフィグレーション項目。 ### `commit-timeout` {#commit-timeout} -- トランザクションコミット実行時の最大タイムアウト時間。 -- デフォルト値: `41s` -- この値は、 Raft選挙のタイムアウト時間の2倍よりも大きく設定する必要があります。 +- トランザクションコミット実行時の最大タイムアウト時間。 +- デフォルト値: `41s` +- この値は、 Raft選挙のタイムアウト時間の2倍よりも大きく設定する必要があります。 ### `batch-policy` v8.3.0の新機能 {#batch-policy-new-in-v830} -- TiDB から TiKV へのリクエストのバッチ処理戦略を制御します。TiDB は、TiKV にリクエストを送信する際、常に現在の待機キュー内のリクエストを`BatchCommandsRequest`にカプセル化し、パケットとして TiKV に送信します。これが基本的なバッチ処理戦略です。TiKV の負荷スループットが高い場合、TiDB は`batch-policy`の値に基づいて、基本的なバッチ処理の後にさらに待機するかどうかを決定します。この追加のバッチ処理により、より多くのリクエストを単一の`BatchCommandsRequest`にカプセル化できます。 -- デフォルト値: `"standard"` -- 値のオプション: - - `"basic"` : この動作は、v8.3.0 より前のバージョンと一致しており、TiDB は[`tikv-client.max-batch-wait-time`](#max-batch-wait-time)が 0 より大きく、TiKV の負荷が[`tikv-client.overload-threshold`](#overload-threshold)の値を超えた場合にのみ追加のバッチ処理を実行します。 - - `"standard"` : TiDB は、最近のリクエストの到着時間間隔に基づいてリクエストを動的にバッチ処理します。これは、高スループットのシナリオに適しています。 - - `"positive"` : TiDB は常に追加のバッチ処理を実行します。これは、最適なパフォーマンスを実現するために、高スループットのテストシナリオに適しています。ただし、低負荷のシナリオでは、この戦略により不要なバッチ処理の待機時間が発生し、パフォーマンスが低下する可能性があります。 - - `"custom{...}"` : バッチ処理戦略のパラメータをカスタマイズできます。このオプションは TiDB の内部テスト用であり、一般的な使用には**推奨されません**。 +- TiDB から TiKV へのリクエストのバッチ処理戦略を制御します。TiDB は、TiKV にリクエストを送信する際、常に現在の待機キュー内のリクエストを`BatchCommandsRequest`にカプセル化し、パケットとして TiKV に送信します。これが基本的なバッチ処理戦略です。TiKV の負荷スループットが高い場合、TiDB は`batch-policy`の値に基づいて、基本的なバッチ処理の後にさらに待機するかどうかを決定します。この追加のバッチ処理により、より多くのリクエストを単一の`BatchCommandsRequest`にカプセル化できます。 +- デフォルト値: `"standard"` +- 値のオプション: + - `"basic"` : この動作は、v8.3.0 より前のバージョンと一致しており、TiDB は[`tikv-client.max-batch-wait-time`](#max-batch-wait-time)が 0 より大きく、TiKV の負荷が[`tikv-client.overload-threshold`](#overload-threshold)の値を超えた場合にのみ追加のバッチ処理を実行します。 + - `"standard"` : TiDB は、最近のリクエストの到着時間間隔に基づいてリクエストを動的にバッチ処理します。これは、高スループットのシナリオに適しています。 + - `"positive"` : TiDB は常に追加のバッチ処理を実行します。これは、最適なパフォーマンスを実現するために、高スループットのテストシナリオに適しています。ただし、低負荷のシナリオでは、この戦略により不要なバッチ処理の待機時間が発生し、パフォーマンスが低下する可能性があります。 + - `"custom{...}"` : バッチ処理戦略のパラメータをカスタマイズできます。このオプションは TiDB の内部テスト用であり、一般的な使用には**推奨されません**。 ### `max-batch-size` {#max-batch-size} -- バッチで送信されるRPCパケットの最大数。値が`0`でない場合、 `BatchCommands` APIを使用してTiKVにリクエストが送信され、同時実行数が多い場合にRPCのレイテンシーが軽減される可能性があります。この値は変更しないことをお勧めします。 -- デフォルト値: `128` +- バッチで送信されるRPCパケットの最大数。値が`0`でない場合、 `BatchCommands` APIを使用してTiKVにリクエストが送信され、同時実行数が多い場合にRPCのレイテンシーが軽減される可能性があります。この値は変更しないことをお勧めします。 +- デフォルト値: `128` ### `max-batch-wait-time` {#max-batch-wait-time} -- `max-batch-wait-time`がデータパケットをまとめて大きなパケットにカプセル化し、TiKVノードに送信するまで待機します。これは、 `tikv-client.max-batch-size`の値が`0`より大きい場合にのみ有効です。この値を変更しないことを推奨します。 -- デフォルト値: `0` -- 単位：ナノ秒 +- `max-batch-wait-time`がデータパケットをまとめて大きなパケットにカプセル化し、TiKVノードに送信するまで待機します。これは、 `tikv-client.max-batch-size`の値が`0`より大きい場合にのみ有効です。この値を変更しないことを推奨します。 +- デフォルト値: `0` +- 単位：ナノ秒 ### `batch-wait-size` {#batch-wait-size} -- TiKVに一括送信されるパケットの最大数。この値は変更しないことを推奨します。 -- デフォルト値: `8` -- 値が`0`の場合、この機能は無効になります。 +- TiKVに一括送信されるパケットの最大数。この値は変更しないことを推奨します。 +- デフォルト値: `8` +- 値が`0`の場合、この機能は無効になります。 ### `overload-threshold` {#overload-threshold} -- TiKV負荷のしきい値。TiKV負荷がこのしきい値を超えると、TiKVの負荷を軽減するために`batch`パケットがさらに収集されます。この設定項目は、 [`tikv-client.max-batch-size`](#max-batch-size)と[`tikv-client.max-batch-wait-time`](#max-batch-wait-time)の両方が`0`より大きい値に設定されている場合にのみ有効になります。この値を変更しないことをお勧めします。 -- デフォルト値: `200` +- TiKV負荷のしきい値。TiKV負荷がこのしきい値を超えると、TiKVの負荷を軽減するために`batch`パケットがさらに収集されます。この設定項目は、 [`tikv-client.max-batch-size`](#max-batch-size)と[`tikv-client.max-batch-wait-time`](#max-batch-wait-time)の両方が`0`より大きい値に設定されている場合にのみ有効になります。この値を変更しないことをお勧めします。 +- デフォルト値: `200` ### `copr-req-timeout` v7.5.0で追加 {#copr-req-timeout-new-in-v750} @@ -799,9 +799,9 @@ opentracing.reporter に関連するコンフィグレーション項目。 > > この設定パラメータは将来のバージョンで非推奨になる可能性があります。値を変更**しないでください**。 -- 単一のコプロセッサー要求のタイムアウト時間。 -- デフォルト値: `60` -- 単位：秒 +- 単一のコプロセッサー要求のタイムアウト時間。 +- デフォルト値: `60` +- 単位：秒 ### `enable-replica-selector-v2` v8.0.0の新機能 {#enable-replica-selector-v2-new-in-v800} @@ -809,8 +809,8 @@ opentracing.reporter に関連するコンフィグレーション項目。 > > バージョン8.2.0以降、この設定項目は非推奨となりました。TiKVへのRPCリクエスト送信時には、デフォルトで新しいバージョンのリージョンレプリカセレクタが使用されます。 -- TiKVにRPCリクエストを送信する際に、リージョンレプリカセレクターの新しいバージョンを使用するかどうか。 -- デフォルト値: `true` +- TiKVにRPCリクエストを送信する際に、リージョンレプリカセレクターの新しいバージョンを使用するかどうか。 +- デフォルト値: `true` ### tikv-client.copr-cache v4.0.0 の新機能 {#tikv-clientcopr-cache-new-in-v400} @@ -818,10 +818,10 @@ opentracing.reporter に関連するコンフィグレーション項目。 #### `capacity-mb` {#capacity-mb} -- キャッシュされたデータの合計サイズ。キャッシュ領域がいっぱいになると、古いキャッシュエントリが削除されます。値が`0.0`の場合、コプロセッサーキャッシュ機能は無効になります。 -- デフォルト値: `1000.0` -- 単位: MB -- 型: Float +- キャッシュされたデータの合計サイズ。キャッシュ領域がいっぱいになると、古いキャッシュエントリが削除されます。値が`0.0`の場合、コプロセッサーキャッシュ機能は無効になります。 +- デフォルト値: `1000.0` +- 単位: MB +- 型: Float ## txn-local-latches {#txn-local-latches} @@ -829,13 +829,13 @@ opentracing.reporter に関連するコンフィグレーション項目。 ### `enabled` {#enabled} -- トランザクションのメモリロックを有効にするかどうかを決定します。 -- デフォルト値: `false` +- トランザクションのメモリロックを有効にするかどうかを決定します。 +- デフォルト値: `false` ### `capacity` {#capacity} -- ハッシュに対応するスロット数。この値は自動的に2の倍数に調整されます。各スロットは32バイトのメモリを占有します。値が小さすぎると、データ書き込み範囲が比較的広い場合（データのインポートなど）に、実行速度が低下したり、パフォーマンスが低下したりする可能性があります。 -- デフォルト値: `2048000` +- ハッシュに対応するスロット数。この値は自動的に2の倍数に調整されます。各スロットは32バイトのメモリを占有します。値が小さすぎると、データ書き込み範囲が比較的広い場合（データのインポートなど）に、実行速度が低下したり、パフォーマンスが低下したりする可能性があります。 +- デフォルト値: `2048000` ## status {#status} @@ -843,19 +843,19 @@ TiDBサービスの状態に関するコンフィグレーション。 ### `report-status` {#report-status} -- HTTP APIサービスを有効または無効にします。 -- デフォルト値: `true` +- HTTP APIサービスを有効または無効にします。 +- デフォルト値: `true` ### `record-db-qps` {#record-db-qps} -- データベース関連のQPSメトリクスをPrometheusに送信するかどうかを決定します。 -- デフォルト値: `false` +- データベース関連のQPSメトリクスをPrometheusに送信するかどうかを決定します。 +- デフォルト値: `false` ### `record-db-label` {#record-db-label} -- データベース関連のQPSメトリクスをPrometheusに送信するかどうかを決定します。 -- `record-db-qps`よりも多くのメトリックタイプをサポートしています。たとえば、期間やステートメントなどです。 -- デフォルト値: `false` +- データベース関連のQPSメトリクスをPrometheusに送信するかどうかを決定します。 +- `record-db-qps`よりも多くのメトリックタイプをサポートしています。たとえば、期間やステートメントなどです。 +- デフォルト値: `false` ## pessimistic-txn {#pessimistic-txn} @@ -863,33 +863,33 @@ TiDBサービスの状態に関するコンフィグレーション。 ### max-retry-count {#max-retry-count} -- 悲観的トランザクションにおける各ステートメントの最大再試行回数。再試行回数がこの制限を超えると、エラーが発生します。 -- デフォルト値: `256` +- 悲観的トランザクションにおける各ステートメントの最大再試行回数。再試行回数がこの制限を超えると、エラーが発生します。 +- デフォルト値: `256` ### deadlock-history-capacity {#deadlock-history-capacity} -- 単一の TiDBサーバーの[`INFORMATION_SCHEMA.DEADLOCKS`](/information-schema/information-schema-deadlocks.md)テーブルに記録できるデッドロック イベントの最大数。このテーブルが満杯の状態でさらにデッドロック イベントが発生した場合、最新のエラーを記録するために、テーブル内の最も古いレコードが削除されます。 -- デフォルト値: `10` -- 最小値: `0` -- 最大値: `10000` +- 単一の TiDBサーバーの[`INFORMATION_SCHEMA.DEADLOCKS`](/information-schema/information-schema-deadlocks.md)テーブルに記録できるデッドロック イベントの最大数。このテーブルが満杯の状態でさらにデッドロック イベントが発生した場合、最新のエラーを記録するために、テーブル内の最も古いレコードが削除されます。 +- デフォルト値: `10` +- 最小値: `0` +- 最大値: `10000` ### deadlock-history-collect-retryable {#deadlock-history-collect-retryable} -- [`INFORMATION_SCHEMA.DEADLOCKS`](/information-schema/information-schema-deadlocks.md)テーブルが再試行可能なデッドロック エラーの情報を収集するかどうかを制御します。再試行可能なデッドロック エラーの説明については、 [再試行可能なデッドロックエラー](/information-schema/information-schema-deadlocks.md#retryable-deadlock-errors)を参照してください。 -- デフォルト値: `false` +- [`INFORMATION_SCHEMA.DEADLOCKS`](/information-schema/information-schema-deadlocks.md)テーブルが再試行可能なデッドロック エラーの情報を収集するかどうかを制御します。再試行可能なデッドロック エラーの説明については、 [再試行可能なデッドロックエラー](/information-schema/information-schema-deadlocks.md#retryable-deadlock-errors)を参照してください。 +- デフォルト値: `false` ### pessimistic-auto-commit v6.0.0で追加 {#pessimistic-auto-commit-new-in-v600} -- 悲観的トランザクション モードがグローバルに有効になっている場合 ( `tidb_txn_mode='pessimistic'` ) に、自動コミット トランザクションが使用するトランザクション モードを決定します。デフォルトでは、悲観的トランザクション モードがグローバルに有効になっていても、自動コミット トランザクションは楽観的トランザクション モードを使用します。 `pessimistic-auto-commit`を有効にすると ( `true` に設定)、自動コミット トランザクションも悲観的モードを使用するようになり、明示的にコミットされた他の悲観的トランザクションと一貫性が保たれます。 -- 競合が発生するシナリオでは、この設定を有効にすると、TiDB は自動コミットトランザクションをグローバルロック待機管理に組み込み、デッドロックを回避し、デッドロックを引き起こす競合によって発生するレイテンシーの急増を軽減します。 -- 競合のないシナリオで、自動コミット トランザクションが多数ある場合 (具体的な数は実際のシナリオによって決まります。たとえば、自動コミット トランザクションの数がアプリケーションの総数の半分以上を占める場合)、単一のトランザクションが大量のデータを操作すると、この構成を有効にするとパフォーマンスが低下します。たとえば、自動コミット`INSERT INTO SELECT`ステートメントです。 -- セッションレベルのシステム変数[`tidb_dml_type`](/system-variables.md#tidb_dml_type-new-in-v800)が`"bulk"`に設定されている場合、セッションにおけるこの設定の効果は、それを`false`に設定することと同じです。 -- デフォルト値: `false` +- 悲観的トランザクション モードがグローバルに有効になっている場合 ( `tidb_txn_mode='pessimistic'` ) に、自動コミット トランザクションが使用するトランザクション モードを決定します。デフォルトでは、悲観的トランザクション モードがグローバルに有効になっていても、自動コミット トランザクションは楽観的トランザクション モードを使用します。 `pessimistic-auto-commit`を有効にすると ( `true` に設定)、自動コミット トランザクションも悲観的モードを使用するようになり、明示的にコミットされた他の悲観的トランザクションと一貫性が保たれます。 +- 競合が発生するシナリオでは、この設定を有効にすると、TiDB は自動コミットトランザクションをグローバルロック待機管理に組み込み、デッドロックを回避し、デッドロックを引き起こす競合によって発生するレイテンシーの急増を軽減します。 +- 競合のないシナリオで、自動コミット トランザクションが多数ある場合 (具体的な数は実際のシナリオによって決まります。たとえば、自動コミット トランザクションの数がアプリケーションの総数の半分以上を占める場合)、単一のトランザクションが大量のデータを操作すると、この構成を有効にするとパフォーマンスが低下します。たとえば、自動コミット`INSERT INTO SELECT`ステートメントです。 +- セッションレベルのシステム変数[`tidb_dml_type`](/system-variables.md#tidb_dml_type-new-in-v800)が`"bulk"`に設定されている場合、セッションにおけるこの設定の効果は、それを`false`に設定することと同じです。 +- デフォルト値: `false` ### constraint-check-in-place-pessimistic） v6.4.0の新機能 {#constraint-check-in-place-pessimistic-new-in-v640} -- システム変数[`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630)のデフォルト値を制御します。 -- デフォルト値: `true` +- システム変数[`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630)のデフォルト値を制御します。 +- デフォルト値: `true` ## isolation-read {#isolation-read} @@ -897,68 +897,68 @@ TiDBサービスの状態に関するコンフィグレーション。 ### `engines` {#engines} -- TiDBがデータを読み取ることを許可するエンジンを制御する。 -- デフォルト値: ["tikv", "tiflash", "tidb"]。これは、エンジンがオプティマイザによって自動的に選択されることを示します。 -- 値のオプション: 「tikv」、「tiflash」、「tidb」の任意の組み合わせ。例: ["tikv", "tidb"] または ["tiflash", "tidb"] +- TiDBがデータを読み取ることを許可するエンジンを制御する。 +- デフォルト値: ["tikv", "tiflash", "tidb"]。これは、エンジンがオプティマイザによって自動的に選択されることを示します。 +- 値のオプション: 「tikv」、「tiflash」、「tidb」の任意の組み合わせ。例: ["tikv", "tidb"] または ["tiflash", "tidb"] ## instance {#instance} ### `tidb_enable_collect_execution_info` {#tidb_enable_collect_execution_info} -- この設定では、各オペレーターの実行情報をスロークエリログに記録するかどうか、および[インデックスの使用統計](/information-schema/information-schema-tidb-index-usage.md)を記録するかどうかを制御します。 -- デフォルト値: `true` -- v6.1.0より前は、この設定は`enable-collect-execution-info`によって設定されます。 +- この設定では、各オペレーターの実行情報をスロークエリログに記録するかどうか、および[インデックスの使用統計](/information-schema/information-schema-tidb-index-usage.md)を記録するかどうかを制御します。 +- デフォルト値: `true` +- v6.1.0より前は、この設定は`enable-collect-execution-info`によって設定されます。 ### `tidb_enable_slow_log` {#tidb_enable_slow_log} -- この設定は、スローログ機能を有効にするかどうかを制御するために使用されます。 -- デフォルト値: `true` -- 値のオプション: `true`または`false` -- v6.1.0より前は、この設定は`enable-slow-log`によって設定されます。 +- この設定は、スローログ機能を有効にするかどうかを制御するために使用されます。 +- デフォルト値: `true` +- 値のオプション: `true`または`false` +- v6.1.0より前は、この設定は`enable-slow-log`によって設定されます。 ### `tidb_slow_log_threshold` {#tidb_slow_log_threshold} -- スローログが消費する時間のしきい値を出力します。 -- デフォルト値: `300` -- 範囲: `[-1, 9223372036854775807]` -- 単位：ミリ秒 -- クエリの実行時間がこの値よりも長い場合、そのクエリはスロークエリとみなされ、そのログがスロークエリログに出力されます。なお、 [`log.level`](#level)の出力レベルが`"debug"`の場合、このパラメータの設定に関わらず、すべてのクエリがスロークエリログに記録されます。 -- v6.1.0より前は、この設定は`slow-threshold`によって設定されます。 +- スローログが消費する時間のしきい値を出力します。 +- デフォルト値: `300` +- 範囲: `[-1, 9223372036854775807]` +- 単位：ミリ秒 +- クエリの実行時間がこの値よりも長い場合、そのクエリはスロークエリとみなされ、そのログがスロークエリログに出力されます。なお、 [`log.level`](#level)の出力レベルが`"debug"`の場合、このパラメータの設定に関わらず、すべてのクエリがスロークエリログに記録されます。 +- v6.1.0より前は、この設定は`slow-threshold`によって設定されます。 ### `in-mem-slow-query-topn-num` v7.3.0の新機能 {#in-mem-slow-query-topn-num-new-in-v730} -- この設定は、メモリにキャッシュされるスロークエリの上位件数を制御します。 -- デフォルト値: 30 +- この設定は、メモリにキャッシュされるスロークエリの上位件数を制御します。 +- デフォルト値: 30 ### `in-mem-slow-query-recent-num` （v7.3.0で追加） {#in-mem-slow-query-recent-num-new-in-v730} -- この設定は、最近使用されたスロークエリのうち、メモリにキャッシュされるクエリの数を制御します。 -- デフォルト値: 500 +- この設定は、最近使用されたスロークエリのうち、メモリにキャッシュされるクエリの数を制御します。 +- デフォルト値: 500 ### `tidb_expensive_query_time_threshold` {#tidb_expensive_query_time_threshold} -- この設定は、高負荷なクエリログを出力するかどうかを決定するしきい値を設定するために使用されます。高負荷なクエリログと低負荷なクエリログの違いは次のとおりです。 - - スローログは、ステートメントの実行後に出力されます。 - - コストの高いクエリログには、実行時間がしきい値を超えた実行中のステートメントと、それに関連する情報が出力されます。 -- デフォルト値: `60` -- 範囲: `[10, 2147483647]` -- 単位：秒 -- v5.4.0より前は、この設定は`expensive-threshold`によって設定されます。 +- この設定は、高負荷なクエリログを出力するかどうかを決定するしきい値を設定するために使用されます。高負荷なクエリログと低負荷なクエリログの違いは次のとおりです。 + - スローログは、ステートメントの実行後に出力されます。 + - コストの高いクエリログには、実行時間がしきい値を超えた実行中のステートメントと、それに関連する情報が出力されます。 +- デフォルト値: `60` +- 範囲: `[10, 2147483647]` +- 単位：秒 +- v5.4.0より前は、この設定は`expensive-threshold`によって設定されます。 ### `tidb_record_plan_in_slow_log` {#tidb_record_plan_in_slow_log} -- この設定は、スロークエリの実行計画をスローログに含めるかどうかを制御するために使用されます。 -- デフォルト値: `1` -- 値のオプション: `1` (有効、デフォルト) または`0` (無効)。 -- この設定値は、システム変数[`tidb_record_plan_in_slow_log`](/system-variables.md#tidb_record_plan_in_slow_log)の値を初期化します。 -- v6.1.0より前は、この設定は`record-plan-in-slow-log`によって設定されます。 +- この設定は、スロークエリの実行計画をスローログに含めるかどうかを制御するために使用されます。 +- デフォルト値: `1` +- 値のオプション: `1` (有効、デフォルト) または`0` (無効)。 +- この設定値は、システム変数[`tidb_record_plan_in_slow_log`](/system-variables.md#tidb_record_plan_in_slow_log)の値を初期化します。 +- v6.1.0より前は、この設定は`record-plan-in-slow-log`によって設定されます。 ### `tidb_force_priority` {#tidb_force_priority} -- この設定は、TiDBサーバー上で実行されるステートメントのデフォルトの優先度を変更するために使用されます。 -- デフォルト値: `NO_PRIORITY` -- デフォルト値`NO_PRIORITY`は、ステートメントの優先順位が強制的に変更されないことを意味します。その他のオプションは、昇順で`LOW_PRIORITY`、`DELAYED`、`HIGH_PRIORITY`です。 -- v6.1.0より前は、この設定は`force-priority`によって設定されます。 +- この設定は、TiDBサーバー上で実行されるステートメントのデフォルトの優先度を変更するために使用されます。 +- デフォルト値: `NO_PRIORITY` +- デフォルト値`NO_PRIORITY`は、ステートメントの優先順位が強制的に変更されないことを意味します。その他のオプションは、昇順で`LOW_PRIORITY`、`DELAYED`、`HIGH_PRIORITY`です。 +- v6.1.0より前は、この設定は`force-priority`によって設定されます。 > **Note:** > @@ -966,27 +966,27 @@ TiDBサービスの状態に関するコンフィグレーション。 ### `max_connections` {#max_connections} -- 単一のTiDBインスタンスで許可される最大接続数。リソース制御に使用できます。 -- デフォルト値: `0` -- 範囲: `[0, 100000]` -- デフォルト値`0`は制限なしを意味します。この変数の値が`0`より大きく、接続数がその値に達すると、TiDBサーバーはクライアントからの新規接続を拒否します。 -- この設定値は、システム変数[`max_connections`](/system-variables.md#max_connections)の値を初期化します。 -- v6.2.0より前は、この設定は`max-server-connections`によって設定されます。 +- 単一のTiDBインスタンスで許可される最大接続数。リソース制御に使用できます。 +- デフォルト値: `0` +- 範囲: `[0, 100000]` +- デフォルト値`0`は制限なしを意味します。この変数の値が`0`より大きく、接続数がその値に達すると、TiDBサーバーはクライアントからの新規接続を拒否します。 +- この設定値は、システム変数[`max_connections`](/system-variables.md#max_connections)の値を初期化します。 +- v6.2.0より前は、この設定は`max-server-connections`によって設定されます。 ### `tidb_enable_ddl` {#tidb_enable_ddl} -- この設定により、対応するTiDBインスタンスがDDLの所有者になれるかどうかを制御します。 -- デフォルト値: `true` -- 指定可能な値: `OFF` 、 `ON` -- この設定値は、システム変数[`tidb_enable_ddl`](/system-variables.md#tidb_enable_ddl-new-in-v630)の値を初期化します。 -- v6.3.0より前は、この設定は`run-ddl`によって設定されます。 +- この設定により、対応するTiDBインスタンスがDDLの所有者になれるかどうかを制御します。 +- デフォルト値: `true` +- 指定可能な値: `OFF` 、 `ON` +- この設定値は、システム変数[`tidb_enable_ddl`](/system-variables.md#tidb_enable_ddl-new-in-v630)の値を初期化します。 +- v6.3.0より前は、この設定は`run-ddl`によって設定されます。 ### `tidb_enable_stats_owner` v8.4.0で追加 {#tidb_enable_stats_owner-new-in-v840} -- この構成は、対応する TiDB インスタンスが[統計情報の自動更新](/statistics.md#automatic-update)タスクを実行できるかどうかを制御します。 -- デフォルト値: `true` -- 指定可能な値: `true` 、 `false` -- この設定値は、システム変数[`tidb_enable_stats_owner`](/system-variables.md#tidb_enable_stats_owner-new-in-v840)の値を初期化します。 +- この構成は、対応する TiDB インスタンスが[統計情報の自動更新](/statistics.md#automatic-update)タスクを実行できるかどうかを制御します。 +- デフォルト値: `true` +- 指定可能な値: `true` 、 `false` +- この設定値は、システム変数[`tidb_enable_stats_owner`](/system-variables.md#tidb_enable_stats_owner-new-in-v840)の値を初期化します。 ### `tidb_stmt_summary_enable_persistent` v6.6.0で追加 {#tidb_stmt_summary_enable_persistent-new-in-v660} @@ -994,9 +994,9 @@ TiDBサービスの状態に関するコンフィグレーション。 > > 明細書の要約を永続化する機能は実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される場合があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -- 明細書の要約を永続化するかどうかを制御します。 -- デフォルト値: `false` -- 詳細については、 [持続ステートメントの概要](/statement-summary-tables.md#persist-statements-summary)をご覧ください。 +- 明細書の要約を永続化するかどうかを制御します。 +- デフォルト値: `false` +- 詳細については、 [持続ステートメントの概要](/statement-summary-tables.md#persist-statements-summary)をご覧ください。 ### `tidb_stmt_summary_filename` v6.6.0で追加 {#tidb_stmt_summary_filename-new-in-v660} @@ -1004,8 +1004,8 @@ TiDBサービスの状態に関するコンフィグレーション。 > > 明細書の要約を永続化する機能は実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される場合があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -- 明細書の要約データの永続化が有効になっている場合、この設定では永続データが書き込まれるファイルを指定します。 -- デフォルト値: `tidb-statements.log` +- 明細書の要約データの永続化が有効になっている場合、この設定では永続データが書き込まれるファイルを指定します。 +- デフォルト値: `tidb-statements.log` ### `tidb_stmt_summary_file_max_days` v6.6.0で追加 {#tidb_stmt_summary_file_max_days-new-in-v660} @@ -1013,10 +1013,10 @@ TiDBサービスの状態に関するコンフィグレーション。 > > 明細書の要約を永続化する機能は実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される場合があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -- 明細書の要約データの永続化が有効になっている場合、この設定では永続データファイルを保持する最大日数を指定します。 -- デフォルト値: `3` -- 単位：日 -- データ保持要件とディスク容量の使用状況に基づいて値を調整できます。 +- 明細書の要約データの永続化が有効になっている場合、この設定では永続データファイルを保持する最大日数を指定します。 +- デフォルト値: `3` +- 単位：日 +- データ保持要件とディスク容量の使用状況に基づいて値を調整できます。 ### `tidb_stmt_summary_file_max_size` v6.6.0で追加 {#tidb_stmt_summary_file_max_size-new-in-v660} @@ -1024,10 +1024,10 @@ TiDBサービスの状態に関するコンフィグレーション。 > > 明細書の要約を永続化する機能は実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される場合があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -- 明細書の要約の永続化が有効になっている場合、この設定では永続データファイルの最大サイズを指定します。 -- デフォルト値: `64` -- 単位: MiB -- データ保持要件とディスク容量の使用状況に基づいて値を調整できます。 +- 明細書の要約の永続化が有効になっている場合、この設定では永続データファイルの最大サイズを指定します。 +- デフォルト値: `64` +- 単位: MiB +- データ保持要件とディスク容量の使用状況に基づいて値を調整できます。 ### `tidb_stmt_summary_file_max_backups` v6.6.0で追加 {#tidb_stmt_summary_file_max_backups-new-in-v660} @@ -1035,9 +1035,9 @@ TiDBサービスの状態に関するコンフィグレーション。 > > 明細書の要約を永続化する機能は実験的機能です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される場合があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -- ステートメントサマリーの永続化が有効になっている場合、この設定では永続化できるデータファイルの最大数を指定します。 `0`はファイル数に制限がないことを意味します。 -- デフォルト値: `0` -- データ保持要件とディスク容量の使用状況に基づいて値を調整できます。 +- ステートメントサマリーの永続化が有効になっている場合、この設定では永続化できるデータファイルの最大数を指定します。 `0`はファイル数に制限がないことを意味します。 +- デフォルト値: `0` +- データ保持要件とディスク容量の使用状況に基づいて値を調整できます。 ## proxy-protocol {#proxy-protocol} @@ -1045,10 +1045,10 @@ PROXYプロトコルに関連するコンフィグレーション項目。 ### `networks` {#networks} -- [プロキシプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)プロトコルを使用して TiDB に接続できるプロキシ サーバーの IP アドレスのリスト -- デフォルト値: "" -- 一般的に、リバースプロキシ経由でTiDBにアクセスする場合、TiDBはリバースプロキシサーバーのIPアドレスをクライアントのIPアドレスとして認識します。HAProxyなど、PROXYプロトコルをサポートするリバースプロキシは、PROXYプロトコルを有効にすることで、実際のクライアントIPアドレスをTiDBに渡すことができます。 -- このパラメータを設定すると、TiDB は設定された送信元 IP アドレスが PROXY プロトコルを使用して TiDB に接続することを許可します。PROXY 以外のプロトコルが使用されると、この接続は拒否されます。このパラメータを空のままにすると、どの IP アドレスも PROXY プロトコルを使用して TiDB に接続できません。値は`,`を区切り文字とする IP アドレス (192.168.1.50) または CIDR (192.168.1.0/24) です。 `*`は任意の IP アドレスを意味します。 +- [プロキシプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)プロトコルを使用して TiDB に接続できるプロキシ サーバーの IP アドレスのリスト +- デフォルト値: "" +- 一般的に、リバースプロキシ経由でTiDBにアクセスする場合、TiDBはリバースプロキシサーバーのIPアドレスをクライアントのIPアドレスとして認識します。HAProxyなど、PROXYプロトコルをサポートするリバースプロキシは、PROXYプロトコルを有効にすることで、実際のクライアントIPアドレスをTiDBに渡すことができます。 +- このパラメータを設定すると、TiDB は設定された送信元 IP アドレスが PROXY プロトコルを使用して TiDB に接続することを許可します。PROXY 以外のプロトコルが使用されると、この接続は拒否されます。このパラメータを空のままにすると、どの IP アドレスも PROXY プロトコルを使用して TiDB に接続できません。値は`,`を区切り文字とする IP アドレス (192.168.1.50) または CIDR (192.168.1.0/24) です。 `*`は任意の IP アドレスを意味します。 > **Warning:** > @@ -1056,8 +1056,8 @@ PROXYプロトコルに関連するコンフィグレーション項目。 ### `fallbackable` （v6.5.1の新機能） {#fallbackable-new-in-v651} -- PROXYプロトコルのフォールバックモードを有効にするかどうかを制御します。この設定項目が`true`に設定されている場合、TiDBは`proxy-protocol.networks`に属するクライアントがPROXYプロトコル仕様を使用せずに、またはPROXYプロトコルヘッダーを送信せずにTiDBに接続することを受け入れられます。デフォルトでは、TiDBは`proxy-protocol.networks`に属し、PROXYプロトコルヘッダーを送信するクライアント接続のみを受け入れます。 -- デフォルト値: `false` +- PROXYプロトコルのフォールバックモードを有効にするかどうかを制御します。この設定項目が`true`に設定されている場合、TiDBは`proxy-protocol.networks`に属するクライアントがPROXYプロトコル仕様を使用せずに、またはPROXYプロトコルヘッダーを送信せずにTiDBに接続することを受け入れられます。デフォルトでは、TiDBは`proxy-protocol.networks`に属し、PROXYプロトコルヘッダーを送信するクライアント接続のみを受け入れます。 +- デフォルト値: `false` ## experimental {#experimental} @@ -1065,5 +1065,5 @@ PROXYプロトコルに関連するコンフィグレーション項目。 ### `allow-expression-index` v4.0.0の新機能 {#allow-expression-index-new-in-v400} -- 式インデックスを作成できるかどうかを制御します。TiDB v5.2.0 以降では、式内の関数が安全であれば、この設定を有効にしなくても、その関数に基づいて式インデックスを直接作成できます。他の関数に基づいて式インデックスを作成する場合は、この設定を有効にできますが、正確性の問題が発生する可能性があります。 `tidb_allow_function_for_expression_index`変数を照会することで、式の作成に直接使用しても安全な関数を取得できます。 -- デフォルト値: `false` +- 式インデックスを作成できるかどうかを制御します。TiDB v5.2.0 以降では、式内の関数が安全であれば、この設定を有効にしなくても、その関数に基づいて式インデックスを直接作成できます。他の関数に基づいて式インデックスを作成する場合は、この設定を有効にできますが、正確性の問題が発生する可能性があります。 `tidb_allow_function_for_expression_index`変数を照会することで、式の作成に直接使用しても安全な関数を取得できます。 +- デフォルト値: `false` diff --git a/tidb-control.md b/tidb-control.md index ad217e1add317..a135055d3b322 100644 --- a/tidb-control.md +++ b/tidb-control.md @@ -25,37 +25,37 @@ TiUPをインストールした後、 `tiup ctl:v tidb`コマ ### ソースコードからコンパイルする {#compile-from-source-code} -- コンパイル環境要件: [Go](https://golang.org/) 1.25以降 -- コンパイル手順: [TiDB制御プロジェクト](https://github.com/pingcap/tidb-ctl)のルート ディレクトリに移動し、 `make`コマンドを使用してコンパイルし、 `tidb-ctl`を生成します。 -- コンパイル ドキュメント: ヘルプ ファイルは`doc`ディレクトリにあります。ヘルプ ファイルが失われた場合、または更新する場合は、 `make doc`コマンドを使用してヘルプ ファイルを生成します。 +- コンパイル環境要件: [Go](https://golang.org/) 1.25以降 +- コンパイル手順: [TiDB制御プロジェクト](https://github.com/pingcap/tidb-ctl)のルート ディレクトリに移動し、 `make`コマンドを使用してコンパイルし、 `tidb-ctl`を生成します。 +- コンパイル ドキュメント: ヘルプ ファイルは`doc`ディレクトリにあります。ヘルプ ファイルが失われた場合、または更新する場合は、 `make doc`コマンドを使用してヘルプ ファイルを生成します。 ## 使い方の紹介 {#usage-introduction} このセクションでは、 `tidb-ctl`のコマンド、サブコマンド、オプション、およびフラグの使用方法について説明します。 -- コマンド: `-`または`--`のない文字 -- サブコマンド: コマンドの後に続く`-`または`--`のない文字 -- オプション: `-`または`--`の文字 -- フラグ: コマンド/サブコマンドまたはオプションの直後に続く文字。コマンド/サブコマンドまたはオプションに値を渡す。 +- コマンド: `-`または`--`のない文字 +- サブコマンド: コマンドの後に続く`-`または`--`のない文字 +- オプション: `-`または`--`の文字 +- フラグ: コマンド/サブコマンドまたはオプションの直後に続く文字。コマンド/サブコマンドまたはオプションに値を渡す。 使用例: `tidb-ctl schema in mysql -n db` -- `schema` : コマンド -- `in` : `schema`のサブコマンド -- `mysql` ： `in`のフラグ -- `-n` : オプション -- `db` ： `-n`のフラグ +- `schema` : コマンド +- `in` : `schema`のサブコマンド +- `mysql` ： `in`のフラグ +- `-n` : オプション +- `db` ： `-n`のフラグ 現在、TiDB コントロールには次のサブコマンドがあります。 -- `tidb-ctl base64decode` : `BASE64`デコードに使用 -- `tidb-ctl decoder` : `KEY`デコードに使用 -- `tidb-ctl etcd` : etcdの操作に使用 -- `tidb-ctl log` : ログファイルをフォーマットして、単一行のスタック情報を拡張するために使用されます -- `tidb-ctl mvcc` : MVCC情報を取得するために使用される -- `tidb-ctl region` :リージョン情報を取得するために使用される -- `tidb-ctl schema` : スキーマ情報を取得するために使用される -- `tidb-ctl table` : テーブル情報を取得するために使用される +- `tidb-ctl base64decode` : `BASE64`デコードに使用 +- `tidb-ctl decoder` : `KEY`デコードに使用 +- `tidb-ctl etcd` : etcdの操作に使用 +- `tidb-ctl log` : ログファイルをフォーマットして、単一行のスタック情報を拡張するために使用されます +- `tidb-ctl mvcc` : MVCC情報を取得するために使用される +- `tidb-ctl region` :リージョン情報を取得するために使用される +- `tidb-ctl schema` : スキーマ情報を取得するために使用される +- `tidb-ctl table` : テーブル情報を取得するために使用される ### ヘルプを受ける {#get-help} @@ -67,26 +67,26 @@ TiDBコントロールは複数のコマンド層で構成されています。 使用方法の詳細を取得するには、 `tidb-ctl schema -h`を使用します。 `schema`コマンド自体には、 `in`と`tid` 2つのサブコマンドがあります。 -- `in` 、データベース名を通じてデータベース内のすべてのテーブルのテーブル スキーマを取得するために使用されます。 -- `tid` 、データベース全体で一意の`table_id`を使用してテーブル スキーマを取得するために使用されます。 +- `in` 、データベース名を通じてデータベース内のすべてのテーブルのテーブル スキーマを取得するために使用されます。 +- `tid` 、データベース全体で一意の`table_id`を使用してテーブル スキーマを取得するために使用されます。 ### グローバルオプション {#global-options} `tidb-ctl`には、次の接続関連のグローバル オプションがあります。 -- `--host` : TiDB サービスアドレス (デフォルト 127.0.0.1) -- `--port` : TiDBステータスポート（デフォルト10080） -- `--pdhost` : PD サービス アドレス (デフォルト 127.0.0.1) -- `--pdport` : PD サービス ポート (デフォルト 2379) -- `--ca` : TLS接続に使用されるCAファイルパス -- `--ssl-key` : TLS接続に使用されるキーファイルパス -- `--ssl-cert` : TLS接続に使用される証明書ファイルパス +- `--host` : TiDB サービスアドレス (デフォルト 127.0.0.1) +- `--port` : TiDBステータスポート（デフォルト10080） +- `--pdhost` : PD サービス アドレス (デフォルト 127.0.0.1) +- `--pdport` : PD サービス ポート (デフォルト 2379) +- `--ca` : TLS接続に使用されるCAファイルパス +- `--ssl-key` : TLS接続に使用されるキーファイルパス +- `--ssl-cert` : TLS接続に使用される証明書ファイルパス `--pdhost`と`--pdport`主に`etcd`サブコマンドで使用されます。例えば`tidb-ctl etcd ddlinfo`です。アドレスとポートを指定しない場合は、以下のデフォルト値が使用されます。 -- TiDBおよびPDのデフォルトのサービスアドレス： `127.0.0.1` 。サービスアドレスはIPアドレスである必要があります。 -- TiDB のデフォルトのサービス ポート: `10080` 。 -- PD のデフォルトのサービス ポート: `2379` 。 +- TiDBおよびPDのデフォルトのサービスアドレス： `127.0.0.1` 。サービスアドレスはIPアドレスである必要があります。 +- TiDB のデフォルトのサービス ポート: `10080` 。 +- PD のデフォルトのサービス ポート: `2379` 。 ### `schema`コマンド {#the-schema-command} @@ -118,7 +118,7 @@ tidb-ctl schema in 結果はJSON形式で表示されます。（上記の出力は切り捨てられています。） -- テーブル名を指定する場合は、 `tidb-ctl schema in -n `を使用してフィルタリングします。 +- テーブル名を指定する場合は、 `tidb-ctl schema in -n
`を使用してフィルタリングします。 たとえば、 `tidb-ctl schema in mysql -n db` `mysql`データベース内の`db`テーブルのテーブル スキーマを返します。 @@ -169,7 +169,7 @@ tidb-ctl base64decode [db_name.table_name] [base64_data] tidb-ctl base64decode [table_id] [base64_data] ``` -1. 環境を準備するには、次の SQL ステートメントを実行します。 +1. 環境を準備するには、次の SQL ステートメントを実行します。 ```sql use test; @@ -178,7 +178,7 @@ tidb-ctl base64decode [table_id] [base64_data] alter table t add column e varchar(20); ``` -2. HTTP API インターフェースを使用して MVCC データを取得します。 +2. HTTP API インターフェースを使用して MVCC データを取得します。 ```shell $ curl "http://$IP:10080/mvcc/index/test/t/a/1?a=1" @@ -208,7 +208,7 @@ tidb-ctl base64decode [table_id] [base64_data] }% ``` -3. ``handle id (uint64) using `base64decode` ``をデコードします。 +3. ``handle id (uint64) using `base64decode` ``をデコードします。 ```shell $ tidb-ctl base64decode AAAAAAAAAAE= @@ -216,7 +216,7 @@ tidb-ctl base64decode [table_id] [base64_data] uint64: 1 ``` -4. `base64decode`を使用して行データをデコードします。 +4. `base64decode`を使用して行データをデコードします。 ```shell $ ./tidb-ctl base64decode test.t CAIIAggEAhjlk4jlk4ggaGVsbG8IBgAICAmAgIDwjYuu0Rk= @@ -237,7 +237,7 @@ tidb-ctl base64decode [table_id] [base64_data] ### `decoder`コマンド {#the-decoder-command} -- 次の例は、インデックス キーのデコードと同様に、行キーをデコードする方法を示しています。 +- 次の例は、インデックス キーのデコードと同様に、行キーをデコードする方法を示しています。 ```shell $ ./tidb-ctl decoder "t\x00\x00\x00\x00\x00\x00\x00\x1c_r\x00\x00\x00\x00\x00\x00\x00\xfa" @@ -246,7 +246,7 @@ tidb-ctl base64decode [table_id] [base64_data] row_id: -9223372036854775558 row_id: -9223372036854775558 ``` -- 次の例は、 `value`デコードする方法を示しています。 +- 次の例は、 `value`デコードする方法を示しています。 ```shell $ ./tidb-ctl decoder AhZoZWxsbyB3b3JsZAiAEA== @@ -257,9 +257,9 @@ tidb-ctl base64decode [table_id] [base64_data] ### `etcd`コマンド {#the-etcd-command} -- `tidb-ctl etcd ddlinfo` DDL 情報を取得するために使用されます。 +- `tidb-ctl etcd ddlinfo` DDL 情報を取得するために使用されます。 -- `tidb-ctl etcd putkey KEY VALUE` etcd に KEY VALUE を追加するために使用されます (すべての KEY は`/tidb/ddl/all_schema_versions/`ディレクトリに追加されます)。 +- `tidb-ctl etcd putkey KEY VALUE` etcd に KEY VALUE を追加するために使用されます (すべての KEY は`/tidb/ddl/all_schema_versions/`ディレクトリに追加されます)。 ```shell tidb-ctl etcd putkey "foo" "bar" @@ -267,7 +267,7 @@ tidb-ctl base64decode [table_id] [base64_data] 実際には、 KEY が`/tidb/ddl/all_schema_versions/foo`で VALUE が`bar`あるキーと値のペアが etcd に追加されます。 -- `tidb-ctl etcd delkey` etcd 内の KEY を削除します。`/tidb/ddl/fg/owner/`または`/tidb/ddl/all_schema_versions/`プレフィックスを持つ KEY のみ削除できます。 +- `tidb-ctl etcd delkey` etcd 内の KEY を削除します。`/tidb/ddl/fg/owner/`または`/tidb/ddl/all_schema_versions/`プレフィックスを持つ KEY のみ削除できます。 ```shell tidb-ctl etcd delkey "/tidb/ddl/fg/owner/foo" @@ -282,39 +282,45 @@ TiDBエラーログのスタック情報は1行形式です。`tidb-ctl log`を `keyrange`サブコマンドは、16 進形式で出力されるグローバルまたはテーブル関連のキー範囲情報を照会するために使用されます。 -- `tidb-ctl keyrange`コマンドを実行して、グローバル キー範囲情報を確認します。 +- `tidb-ctl keyrange`コマンドを実行して、グローバル キー範囲情報を確認します。 ```shell tidb-ctl keyrange ``` - global ranges: - meta: (6d, 6e) - table: (74, 75) + ``` + global ranges: + meta: (6d, 6e) + table: (74, 75) + ``` -- エンコードされたキーを表示するには、 `--encode`オプションを追加します (TiKV および PD と同じ形式)。 +- エンコードされたキーを表示するには、 `--encode`オプションを追加します (TiKV および PD と同じ形式)。 ```shell tidb-ctl keyrange --encode ``` - global ranges: - meta: (6d00000000000000f8, 6e00000000000000f8) - table: (7400000000000000f8, 7500000000000000f8) + ``` + global ranges: + meta: (6d00000000000000f8, 6e00000000000000f8) + table: (7400000000000000f8, 7500000000000000f8) + ``` -- `tidb-ctl keyrange --database={db} --table={tbl}`コマンドを実行して、グローバルおよびテーブル関連のキー範囲情報を確認します。 +- `tidb-ctl keyrange --database={db} --table={tbl}`コマンドを実行して、グローバルおよびテーブル関連のキー範囲情報を確認します。 ```shell tidb-ctl keyrange --database test --table ttt ``` - global ranges: - meta: (6d, 6e) - table: (74, 75) - table ttt ranges: (NOTE: key range might be changed after DDL) - table: (74800000000000002f, 748000000000000030) - table indexes: (74800000000000002f5f69, 74800000000000002f5f72) - index c2: (74800000000000002f5f698000000000000001, 74800000000000002f5f698000000000000002) - index c3: (74800000000000002f5f698000000000000002, 74800000000000002f5f698000000000000003) - index c4: (74800000000000002f5f698000000000000003, 74800000000000002f5f698000000000000004) - table rows: (74800000000000002f5f72, 748000000000000030) + ``` + global ranges: + meta: (6d, 6e) + table: (74, 75) + table ttt ranges: (NOTE: key range might be changed after DDL) + table: (74800000000000002f, 748000000000000030) + table indexes: (74800000000000002f5f69, 74800000000000002f5f72) + index c2: (74800000000000002f5f698000000000000001, 74800000000000002f5f698000000000000002) + index c3: (74800000000000002f5f698000000000000002, 74800000000000002f5f698000000000000003) + index c4: (74800000000000002f5f698000000000000003, 74800000000000002f5f698000000000000004) + table rows: (74800000000000002f5f72, 748000000000000030) + ``` diff --git a/tidb-distributed-execution-framework.md b/tidb-distributed-execution-framework.md index e48fcaf8e7d31..38911ed8caefb 100644 --- a/tidb-distributed-execution-framework.md +++ b/tidb-distributed-execution-framework.md @@ -17,26 +17,26 @@ TiDBは、優れたスケーラビリティと弾力性を備えたコンピュ データベース管理システムでは、コアとなるトランザクション処理（TP）と分析処理（AP）のワークロードに加えて、DDL操作、 [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md) [`ANALYZE`](/sql-statements/sql-statement-analyze-table.md)バックアップ/リストアといった重要なタスクが存在します。これらのタスクは、データベースオブジェクト（テーブル）内の大量のデータを処理する必要があるため、通常[TTL](/time-to-live.md)次のような特性を持ちます。 -- スキーマまたはデータベース オブジェクト (テーブル) 内のすべてのデータを処理する必要があります。 -- 定期的に実行する必要があるかもしれませんが、頻度は低くなります。 -- リソースが適切に制御されていない場合、TP および AP タスクに影響を与え、データベース サービスの品質が低下する可能性があります。 +- スキーマまたはデータベース オブジェクト (テーブル) 内のすべてのデータを処理する必要があります。 +- 定期的に実行する必要があるかもしれませんが、頻度は低くなります。 +- リソースが適切に制御されていない場合、TP および AP タスクに影響を与え、データベース サービスの品質が低下する可能性があります。 DXF を有効にすると上記の問題が解決され、次の 3 つの利点があります。 -- このフレームワークは、高いスケーラビリティ、高い可用性、および高いパフォーマンスを実現する統合された機能を提供します。 -- DXF はタスクの分散実行をサポートしており、TiDB クラスター全体の利用可能なコンピューティング リソースを柔軟にスケジュールできるため、TiDB クラスター内のコンピューティング リソースをより有効に活用できます。 -- DXF は、全体的タスクと個々のタスクの両方に対して、統合されたリソースの使用および管理機能を提供します。 +- このフレームワークは、高いスケーラビリティ、高い可用性、および高いパフォーマンスを実現する統合された機能を提供します。 +- DXF はタスクの分散実行をサポートしており、TiDB クラスター全体の利用可能なコンピューティング リソースを柔軟にスケジュールできるため、TiDB クラスター内のコンピューティング リソースをより有効に活用できます。 +- DXF は、全体的タスクと個々のタスクの両方に対して、統合されたリソースの使用および管理機能を提供します。 現在、DXF は[`ADD INDEX`](/sql-statements/sql-statement-add-index.md)と[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)ステートメントの分散実行をサポートしています。 -- [`ADD INDEX`](/sql-statements/sql-statement-add-index.md)はインデックスを作成するために使用されるDDL文です。例: +- [`ADD INDEX`](/sql-statements/sql-statement-add-index.md)はインデックスを作成するために使用されるDDL文です。例: ```sql ALTER TABLE t1 ADD INDEX idx1(c1); CREATE INDEX idx1 ON table t1(c1); ``` -- [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)は、CSV、SQL、Parquet などの形式のデータを空のテーブルにインポートするために使用されます。 +- [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)は、CSV、SQL、Parquet などの形式のデータを空のテーブルにインポートするために使用されます。 ## 制限 {#limitation} @@ -48,14 +48,14 @@ DXF を使用して[`ADD INDEX`](/sql-statements/sql-statement-add-index.md)タ -1. 高速オンライン DDL に関連する次のシステム変数を調整します。 +1. 高速オンライン DDL に関連する次のシステム変数を調整します。 - - [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) : 高速オンラインDDLモードを有効にするために使用されます。TiDB v6.5.0以降ではデフォルトで有効になっています。 - - [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630) : 高速オンライン DDL モードで使用できるローカル ディスクの最大クォータを制御するために使用されます。 + - [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) : 高速オンラインDDLモードを有効にするために使用されます。TiDB v6.5.0以降ではデフォルトで有効になっています。 + - [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630) : 高速オンライン DDL モードで使用できるローカル ディスクの最大クォータを制御するために使用されます。 -2. 高速オンライン DDL に関連する次の構成項目を調整します。 +2. 高速オンライン DDL に関連する次の構成項目を調整します。 - - [`temp-dir`](/tidb-configuration-file.md#temp-dir-new-in-v630) : 高速オンライン DDL モードで使用できるローカル ディスク パスを指定します。 + - [`temp-dir`](/tidb-configuration-file.md#temp-dir-new-in-v630) : 高速オンライン DDL モードで使用できるローカル ディスク パスを指定します。 > **Note:** > @@ -67,14 +67,14 @@ DXF を使用して[`ADD INDEX`](/sql-statements/sql-statement-add-index.md)タ 高速オンライン DDL に関連する次のシステム変数を調整します。 -- [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) : 高速オンラインDDLモードを有効にするために使用されます。TiDB v6.5.0以降ではデフォルトで有効になっています。 -- [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630) : 高速オンライン DDL モードで使用できるローカル ディスクの最大クォータを制御するために使用されます。 +- [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) : 高速オンラインDDLモードを有効にするために使用されます。TiDB v6.5.0以降ではデフォルトで有効になっています。 +- [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630) : 高速オンライン DDL モードで使用できるローカル ディスクの最大クォータを制御するために使用されます。 ## 使用法 {#usage} -1. DXFを有効にするには、 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)の値を`ON`に設定します。v8.1.0以降では、この変数はデフォルトで有効になっています。v8.1.0以降のバージョンで新しく作成されたクラスターでは、この手順をスキップできます。 +1. DXFを有効にするには、 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)の値を`ON`に設定します。v8.1.0以降では、この変数はデフォルトで有効になっています。v8.1.0以降のバージョンで新しく作成されたクラスターでは、この手順をスキップできます。 ```sql SET GLOBAL tidb_enable_dist_task = ON; @@ -82,27 +82,27 @@ DXF を使用して[`ADD INDEX`](/sql-statements/sql-statement-add-index.md)タ DXFタスクの実行中、フレームワークでサポートされているステートメント（ [`ADD INDEX`](/sql-statements/sql-statement-add-index.md)や[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)など）が分散的に実行されます。すべてのTiDBノードはデフォルトでDXFタスクを実行します。 -2. 一般に、DDL タスクの分散実行に影響を与える可能性のある次のシステム変数については、デフォルト値を使用することをお勧めします。 +2. 一般に、DDL タスクの分散実行に影響を与える可能性のある次のシステム変数については、デフォルト値を使用することをお勧めします。 - - [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) : デフォルト値`4`を使用します。推奨される最大値は`16`です。 - - [`tidb_ddl_reorg_priority`](/system-variables.md#tidb_ddl_reorg_priority) - - [`tidb_ddl_error_count_limit`](/system-variables.md#tidb_ddl_error_count_limit) - - [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) : デフォルト値を使用します。推奨される最大値は`1024`です。 + - [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) : デフォルト値`4`を使用します。推奨される最大値は`16`です。 + - [`tidb_ddl_reorg_priority`](/system-variables.md#tidb_ddl_reorg_priority) + - [`tidb_ddl_error_count_limit`](/system-variables.md#tidb_ddl_error_count_limit) + - [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) : デフォルト値を使用します。推奨される最大値は`1024`です。 ## タスクのスケジュール {#task-scheduling} デフォルトでは、DXFはすべてのTiDBノードを分散タスクの実行対象としてスケジュールします。v7.4.0以降、TiDB Self-Managedクラスターでは、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)設定することで、DXFが分散タスクの実行対象としてスケジュールするTiDBノードを制御できます。 -- バージョンv7.4.0からv8.0.0までの場合、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)のオプション値は`''`または`background`です。現在のクラスターに`tidb_service_scope = 'background'`のTiDBノードがある場合、DXFはこれらのノードにタスクの実行をスケジュールします。障害または通常のスケールインにより、現在のクラスターに`tidb_service_scope = 'background'` TiDBノードがない場合、DXFは`tidb_service_scope = ''`のノードにタスクの実行をスケジュールします。 +- バージョンv7.4.0からv8.0.0までの場合、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)のオプション値は`''`または`background`です。現在のクラスターに`tidb_service_scope = 'background'`のTiDBノードがある場合、DXFはこれらのノードにタスクの実行をスケジュールします。障害または通常のスケールインにより、現在のクラスターに`tidb_service_scope = 'background'` TiDBノードがない場合、DXFは`tidb_service_scope = ''`のノードにタスクの実行をスケジュールします。 -- v8.1.0以降では、 [`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)値にバインドされ、DXFは同じ[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)値を持つTiDBノードにのみタスクの実行をスケジュールします。ただし、以前のバージョンとの設定互換性を保つため、分散タスクが`tidb_service_scope = ''`ノードに送信され、現在のクラスターに`tidb_service_scope = 'background'`のTiDBノードがある場合、DXFは`tidb_service_scope = 'background'`のTiDBノードにタスクの実行をスケジュールします。 +- v8.1.0以降では、 [`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)値にバインドされ、DXFは同じ[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)値を持つTiDBノードにのみタスクの実行をスケジュールします。ただし、以前のバージョンとの設定互換性を保つため、分散タスクが`tidb_service_scope = ''`ノードに送信され、現在のクラスターに`tidb_service_scope = 'background'`のTiDBノードがある場合、DXFは`tidb_service_scope = 'background'`のTiDBノードにタスクの実行をスケジュールします。 v8.1.0以降、タスク実行中に新しいノードが追加された場合、DXFは前述のルールに基づいて、新しいノードにタスクを実行するかどうかをスケジュールするかどうかを決定します。新しく追加されたノードにタスクを実行させたくない場合は、事前にそれらのノードに異なる[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)設定することをお勧めします。 > **Note:** > -> - バージョンv7.4.0からv8.0.0まで、複数のTiDBノードを持つクラスターでは、2つ以上のTiDBノードで[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)から`background`設定することを強くお勧めします。この変数を1つのTiDBノードにのみ設定した場合、そのノードが再起動または障害を起こした場合、タスクは`tidb_service_scope = ''`が設定されているTiDBノードに再スケジュールされ、これらのTiDBノードで実行されているアプリケーションに影響を及ぼします。 -> - 分散タスクの実行中、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)構成への変更は現在のタスクには適用されませんが、次のタスクからは適用されます。 +> - バージョンv7.4.0からv8.0.0まで、複数のTiDBノードを持つクラスターでは、2つ以上のTiDBノードで[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)から`background`設定することを強くお勧めします。この変数を1つのTiDBノードにのみ設定した場合、そのノードが再起動または障害を起こした場合、タスクは`tidb_service_scope = ''`が設定されているTiDBノードに再スケジュールされ、これらのTiDBノードで実行されているアプリケーションに影響を及ぼします。 +> - 分散タスクの実行中、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)構成への変更は現在のタスクには適用されませんが、次のタスクからは適用されます。 ## 実装原理 {#implementation-principles} @@ -112,20 +112,20 @@ DXF のアーキテクチャは次のとおりです。 上の図に示すように、DXF でのタスクの実行は主に次のモジュールによって処理されます。 -- ディスパッチャ: 各タスクの分散実行計画を生成し、実行プロセスを管理し、タスクの状態を変換し、実行時のタスク情報を収集してフィードバックします。 -- スケジューラ: TiDB ノード間で分散タスクの実行を複製し、タスク実行の効率を向上させます。 -- サブタスクエグゼキュータ：分散サブタスクの実際の実行者。また、サブタスクエグゼキュータはサブタスクの実行状況をスケジューラに返し、スケジューラはサブタスクの実行状況を一元的に更新します。 -- リソース プール: 上記のモジュールのコンピューティング リソースをプールすることにより、リソースの使用状況と管理を定量化する基礎を提供します。 +- ディスパッチャ: 各タスクの分散実行計画を生成し、実行プロセスを管理し、タスクの状態を変換し、実行時のタスク情報を収集してフィードバックします。 +- スケジューラ: TiDB ノード間で分散タスクの実行を複製し、タスク実行の効率を向上させます。 +- サブタスクエグゼキュータ：分散サブタスクの実際の実行者。また、サブタスクエグゼキュータはサブタスクの実行状況をスケジューラに返し、スケジューラはサブタスクの実行状況を一元的に更新します。 +- リソース プール: 上記のモジュールのコンピューティング リソースをプールすることにより、リソースの使用状況と管理を定量化する基礎を提供します。 ## 参照 {#see-also} -- [DDL ステートメントの実行原則とベストプラクティス](/best-practices/ddl-introduction.md) +- [DDL ステートメントの実行原則とベストプラクティス](/best-practices/ddl-introduction.md) -- [DDL ステートメントの実行原則とベストプラクティス](https://docs.pingcap.com/tidb/stable/ddl-introduction) +- [DDL ステートメントの実行原則とベストプラクティス](https://docs.pingcap.com/tidb/stable/ddl-introduction) diff --git a/tidb-external-ts.md b/tidb-external-ts.md index e3228cb97572d..108c18001cad9 100644 --- a/tidb-external-ts.md +++ b/tidb-external-ts.md @@ -23,36 +23,42 @@ summary: tidb_external_ts` 変数を使用して履歴データを読み取る このセクションでは、 `tidb_external_ts`変数を使用して履歴データを読み取る方法を例とともに説明します。 -1. テーブルを作成し、テーブルにいくつかの行を挿入します。 +1. テーブルを作成し、テーブルにいくつかの行を挿入します。 ```sql CREATE TABLE t (c INT); ``` - Query OK, 0 rows affected (0.01 sec) + ``` + Query OK, 0 rows affected (0.01 sec) + ``` ```sql INSERT INTO t VALUES (1), (2), (3); ``` - Query OK, 3 rows affected (0.00 sec) + ``` + Query OK, 3 rows affected (0.00 sec) + ``` -2. 表内のデータを表示する。 +2. 表内のデータを表示する。 ```sql SELECT * FROM t; ``` - +------+ - | c | - +------+ - | 1 | - | 2 | - | 3 | - +------+ - 3 rows in set (0.00 sec) + ``` + +------+ + | c | + +------+ + | 1 | + | 2 | + | 3 | + +------+ + 3 rows in set (0.00 sec) + ``` -3. セット`tidb_external_ts` ～ `@@tidb_current_ts` : +3. セット`tidb_external_ts` ～ `@@tidb_current_ts` : ```sql START TRANSACTION; @@ -60,42 +66,48 @@ summary: tidb_external_ts` 変数を使用して履歴データを読み取る COMMIT; ``` -4. 新しい行を挿入し、挿入されたことを確認します。 +4. 新しい行を挿入し、挿入されたことを確認します。 ```sql INSERT INTO t VALUES (4); ``` - Query OK, 1 row affected (0.001 sec) + ``` + Query OK, 1 row affected (0.001 sec) + ``` ```sql SELECT * FROM t; ``` - +------+ - | id | - +------+ - | 1 | - | 2 | - | 3 | - | 4 | - +------+ - 4 rows in set (0.00 sec) + ``` + +------+ + | id | + +------+ + | 1 | + | 2 | + | 3 | + | 4 | + +------+ + 4 rows in set (0.00 sec) + ``` -5. `tidb_enable_external_ts_read`を`ON`に設定し、表内のデータを表示します。 +5. `tidb_enable_external_ts_read`を`ON`に設定し、表内のデータを表示します。 ```sql SET tidb_enable_external_ts_read=ON; SELECT * FROM t; ``` - +------+ - | c | - +------+ - | 1 | - | 2 | - | 3 | - +------+ - 3 rows in set (0.00 sec) + ``` + +------+ + | c | + +------+ + | 1 | + | 2 | + | 3 | + +------+ + 3 rows in set (0.00 sec) + ``` 新しい行が挿入される前にタイムスタンプに`tidb_external_ts`設定されるため、 `tidb_enable_external_ts_read`有効になった後は新しく挿入された行は返されません。 diff --git a/tidb-global-sort.md b/tidb-global-sort.md index 46d89be61ae3b..f106066cce870 100644 --- a/tidb-global-sort.md +++ b/tidb-global-sort.md @@ -11,8 +11,8 @@ summary: TiDB グローバル ソートの使用例、制限、使用方法、 > **Note:** > -> - 現在、グローバルソート処理はTiDBノードの計算リソースとメモリリソースを大量に消費しています。ユーザーの業務アプリケーションの実行中にオンラインでインデックスを追加するようなシナリオでは、クラスターに新しいTiDBノードを追加し、これらのノードに[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)変数を設定し、これらのノードに接続してタスクを作成することをお勧めします。これにより、分散フレームワークはこれらのノードにタスクをスケジュールし、他のTiDBノードからのワークロードを分離することで、 `ADD INDEX`や`IMPORT INTO`などのバックエンドタスクの実行がユーザーの業務アプリケーションに与える影響を軽減します。 -> - グローバル ソート機能を使用する場合は、OOM を回避するために、少なくとも 16 コアの CPU と 32 GiB のメモリを備えた TiDB ノードを使用することをお勧めします。 +> - 現在、グローバルソート処理はTiDBノードの計算リソースとメモリリソースを大量に消費しています。ユーザーの業務アプリケーションの実行中にオンラインでインデックスを追加するようなシナリオでは、クラスターに新しいTiDBノードを追加し、これらのノードに[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)変数を設定し、これらのノードに接続してタスクを作成することをお勧めします。これにより、分散フレームワークはこれらのノードにタスクをスケジュールし、他のTiDBノードからのワークロードを分離することで、 `ADD INDEX`や`IMPORT INTO`などのバックエンドタスクの実行がユーザーの業務アプリケーションに与える影響を軽減します。 +> - グローバル ソート機能を使用する場合は、OOM を回避するために、少なくとも 16 コアの CPU と 32 GiB のメモリを備えた TiDB ノードを使用することをお勧めします。 > **Note:** > @@ -38,7 +38,7 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ グローバルソートを有効にするには、次の手順に従います。 -1. DXFを有効にするには、値を[`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)から`ON`に設定します。v8.1.0以降では、この変数はデフォルトで有効になっています。v8.1.0以降のバージョンで新しく作成されたクラスターでは、この手順をスキップできます。 +1. DXFを有効にするには、値を[`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)から`ON`に設定します。v8.1.0以降では、この変数はデフォルトで有効になっています。v8.1.0以降のバージョンで新しく作成されたクラスターでは、この手順をスキップできます。 ```sql SET GLOBAL tidb_enable_dist_task = ON; @@ -46,7 +46,7 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ -2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドストレージパスに設定します。[例](/br/backup-and-restore-storages.md)を参照してください。 +2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドストレージパスに設定します。[例](/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)正しいクラウドストレージパスに設定します。[例](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)正しいクラウドストレージパスに設定します。[例](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' @@ -85,17 +85,17 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ ### ステップ1: データをスキャンして準備する {#step-1-scan-and-prepare-data} -1. TiDB ノードが特定の範囲のデータをスキャンした後 (データ ソースは CSV データまたは TiKV のテーブル データのいずれかになります)。 +1. TiDB ノードが特定の範囲のデータをスキャンした後 (データ ソースは CSV データまたは TiKV のテーブル データのいずれかになります)。 - 1. TiDB ノードはそれらをキーと値のペアにエンコードします。 - 2. TiDB ノードは、キーと値のペアを複数のブロック データ セグメントに分類します (データ セグメントはローカルに分類されます)。各セグメントは 1 つのファイルであり、クラウドストレージにアップロードされます。 + 1. TiDB ノードはそれらをキーと値のペアにエンコードします。 + 2. TiDB ノードは、キーと値のペアを複数のブロック データ セグメントに分類します (データ セグメントはローカルに分類されます)。各セグメントは 1 つのファイルであり、クラウドストレージにアップロードされます。 -2. TiDBノードは、各セグメントの実際のキーと値の範囲（統計ファイルと呼ばれます）も連続して記録します。これは、スケーラブルなソート実装のための重要な準備です。これらのファイルは、実際のデータと共にクラウドストレージにアップロードされます。 +2. TiDBノードは、各セグメントの実際のキーと値の範囲（統計ファイルと呼ばれます）も連続して記録します。これは、スケーラブルなソート実装のための重要な準備です。これらのファイルは、実際のデータと共にクラウドストレージにアップロードされます。 ### ステップ2: データを分類して分配する {#step-2-sort-and-distribute-data} ステップ1では、グローバルソートプログラムはソート済みブロックのリストと対応する統計ファイルを取得します。これらの統計ファイルから、ローカルソート済みブロックの数が得られます。また、このプログラムはPDが分割と分散に使用できる実データスコープも備えています。以下の手順が実行されます。 -1. 統計ファイル内のレコードを並べ替えて、ほぼ均等なサイズの範囲に分割します。これは、並列で実行されるサブタスクです。 -2. サブタスクを TiDB ノードに分散して実行します。 -3. 各 TiDB ノードは、サブタスクのデータを範囲ごとに独立して分類し、重複することなく TiKV に取り込みます。 +1. 統計ファイル内のレコードを並べ替えて、ほぼ均等なサイズの範囲に分割します。これは、並列で実行されるサブタスクです。 +2. サブタスクを TiDB ノードに分散して実行します。 +3. 各 TiDB ノードは、サブタスクのデータを範囲ごとに独立して分類し、重複することなく TiKV に取り込みます。 diff --git a/tidb-lightning/data-import-best-practices.md b/tidb-lightning/data-import-best-practices.md index 8d0f422bc0ba4..039b0f13ccf77 100644 --- a/tidb-lightning/data-import-best-practices.md +++ b/tidb-lightning/data-import-best-practices.md @@ -9,91 +9,91 @@ summary: 大量のデータをインポートするためのベスト プラク TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md) ）は、空のテーブルへのデータのインポートや空のクラスタの初期化に使用される包括的かつ効率的なデータインポートツールであり、ファイルをデータソースとして使用します。TiDB Lightningは、単一インスタンスと[並列インポート](/tidb-lightning/tidb-lightning-distributed-import.md)の2つの実行モードを提供します。異なるサイズのソースファイルをインポートできます。 -- ソース ファイルのデータ サイズが 10 TiB 以内の場合は、インポートにTiDB Lightningの単一インスタンスを使用することをお勧めします。 -- ソース ファイルのデータ サイズが 10 TiB を超える場合は、 [並列インポート](/tidb-lightning/tidb-lightning-distributed-import.md)にTiDB Lightningの複数のインスタンスを使用することをお勧めします。 -- ソース ファイルのデータ規模が非常に大きい場合 (50 TiB を超える場合)、並列インポートに加えて、ソース データの特性、テーブル定義、およびパラメータ構成に基づいて特定の準備と最適化を行い、大規模データのインポートをよりスムーズかつ高速に実現する必要があります。 +- ソース ファイルのデータ サイズが 10 TiB 以内の場合は、インポートにTiDB Lightningの単一インスタンスを使用することをお勧めします。 +- ソース ファイルのデータ サイズが 10 TiB を超える場合は、 [並列インポート](/tidb-lightning/tidb-lightning-distributed-import.md)にTiDB Lightningの複数のインスタンスを使用することをお勧めします。 +- ソース ファイルのデータ規模が非常に大きい場合 (50 TiB を超える場合)、並列インポートに加えて、ソース データの特性、テーブル定義、およびパラメータ構成に基づいて特定の準備と最適化を行い、大規模データのインポートをよりスムーズかつ高速に実現する必要があります。 次のセクションは、複数のテーブルのインポートと単一の大きなテーブルのインポートの両方に適用されます。 -- [重要な要素](#key-factors) -- [ソースファイルの準備](#prepare-source-files) -- [ストレージスペースの見積もり](#estimate-storage-space) -- [設定パラメータを変更する](#change-configuration-parameters) -- [「チェックサム不一致」エラーを解決する](#resolve-the-checksum-mismatch-error) -- [チェックポイントを有効にする](#enable-checkpoint) -- [トラブルシューティング](#troubleshooting) +- [重要な要素](#key-factors) +- [ソースファイルの準備](#prepare-source-files) +- [ストレージスペースの見積もり](#estimate-storage-space) +- [設定パラメータを変更する](#change-configuration-parameters) +- [「チェックサム不一致」エラーを解決する](#resolve-the-checksum-mismatch-error) +- [チェックポイントを有効にする](#enable-checkpoint) +- [トラブルシューティング](#troubleshooting) 大きな単一テーブルをインポートするためのベスト プラクティスについては、特別な要件があるため、次のセクションで別途説明します。 -- [大きな単一テーブルをインポートするためのベストプラクティス](#best-practices-for-importing-a-large-single-table) +- [大きな単一テーブルをインポートするためのベストプラクティス](#best-practices-for-importing-a-large-single-table) ## 重要な要素 {#key-factors} データをインポートする際、いくつかの重要な要素がインポートのパフォーマンスに影響を与え、場合によってはインポートが失敗する可能性があります。一般的な重要な要素には、次のようなものがあります。 -- ソースファイル +- ソースファイル - - 単一ファイル内のデータが主キーでソートされているかどうか。ソートされたデータは、最適なインポートパフォーマンスを実現します。 - - 複数のTiDB Lightningインスタンスによってインポートされたソースファイル間に、重複する主キーまたは非NULLの一意インデックスが存在するかどうか。重複が少ないほど、インポートのパフォーマンスは向上します。 + - 単一ファイル内のデータが主キーでソートされているかどうか。ソートされたデータは、最適なインポートパフォーマンスを実現します。 + - 複数のTiDB Lightningインスタンスによってインポートされたソースファイル間に、重複する主キーまたは非NULLの一意インデックスが存在するかどうか。重複が少ないほど、インポートのパフォーマンスは向上します。 -- 表の定義 +- 表の定義 - - テーブルごとのセカンダリインデックスの数とサイズは、インポート速度に影響を与える可能性があります。インデックスの数が少ないほど、インポートが高速化し、インポート後のスペース消費も少なくなります。 - - インデックス データ サイズ = インデックスの数 * インデックス サイズ * 行数。 + - テーブルごとのセカンダリインデックスの数とサイズは、インポート速度に影響を与える可能性があります。インデックスの数が少ないほど、インポートが高速化し、インポート後のスペース消費も少なくなります。 + - インデックス データ サイズ = インデックスの数 \* インデックス サイズ \* 行数。 -- 圧縮比 +- 圧縮比 - - TiDBクラスタにインポートされたデータは圧縮形式で保存されます。圧縮率は事前に計算できません。圧縮率は、データが実際にTiKVクラスタにインポートされた後にのみ判定できます。 - - ベスト プラクティスとして、最初にデータの小さな部分 (たとえば、10%) をインポートしてクラスターの対応する圧縮率を取得し、それを使用してデータ インポート全体の圧縮率を推定することができます。 + - TiDBクラスタにインポートされたデータは圧縮形式で保存されます。圧縮率は事前に計算できません。圧縮率は、データが実際にTiKVクラスタにインポートされた後にのみ判定できます。 + - ベスト プラクティスとして、最初にデータの小さな部分 (たとえば、10%) をインポートしてクラスターの対応する圧縮率を取得し、それを使用してデータ インポート全体の圧縮率を推定することができます。 -- コンフィグレーションパラメータ +- コンフィグレーションパラメータ - - `region-concurrency` : TiDB Lightning のメイン論理処理の同時実行性。 - - `send-kv-pairs` : 1 回のリクエストでTiDB Lightningから TiKV に送信されるキーと値のペアの数。 - - `disk-quota` : 物理インポート モードを使用するときに、 TiDB Lightning のローカル一時ファイルによって使用されるディスク クォータ。 - - `GOMEMLIMIT` : TiDB LightningはGo言語で実装されています。[`GOMEMLIMIT`を適切に設定します](#change-configuration-parameters) + - `region-concurrency` : TiDB Lightning のメイン論理処理の同時実行性。 + - `send-kv-pairs` : 1 回のリクエストでTiDB Lightningから TiKV に送信されるキーと値のペアの数。 + - `disk-quota` : 物理インポート モードを使用するときに、 TiDB Lightning のローカル一時ファイルによって使用されるディスク クォータ。 + - `GOMEMLIMIT` : TiDB LightningはGo言語で実装されています。[`GOMEMLIMIT`を適切に設定します](#change-configuration-parameters) -- データ検証 +- データ検証 データとインデックスのインポートが完了すると、各テーブルに対して[`ADMIN CHECKSUM`](/sql-statements/sql-statement-admin-checksum-table.md)ステートメントが実行され、チェックサム値がTiDB Lightningのローカルチェックサム値と比較されます。テーブル数が多い場合、または個々のテーブルに多数の行がある場合、チェックサムフェーズに長い時間がかかることがあります。 -- 分析操作 +- 分析操作 チェックサムが正常に完了すると、各テーブルに対して[`ANALYZE TABLE`](/sql-statements/sql-statement-analyze-table.md)ステートメントが実行され、最適な実行計画が生成されます。多数のテーブル、または大量のデータを含む個々のテーブルを扱う場合、分析操作には時間がかかることがあります。 -- 関連する問題 +- 関連する問題 50TiB のデータを実際にインポートするプロセスでは、膨大な数のソースファイルや大規模クラスターを扱う場合にのみ発生する特定の問題が発生する可能性があります。製品バージョンを選択する際には、該当する問題が修正されているかどうかを確認することをお勧めします。 v6.5.3、v7.1.0 以降のバージョンでは、次の問題が解決されています。 - - [問題-14745](https://github.com/tikv/tikv/issues/14745) : インポートが完了すると、TiKV インポート ディレクトリに大量の一時ファイルが残ります。 - - [問題-6426](https://github.com/tikv/pd/issues/6426) : PD [レンジスケジュール](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#scope-of-pausing-scheduling-during-import)インターフェースがリージョンの分散に失敗し、タイムアウトの問題が発生する可能性があります。v6.2.0より前では、グローバルスケジューリングはデフォルトで無効になっているため、この問題の発生を回避できます。 - - [問題-43079](https://github.com/pingcap/tidb/pull/43079) : TiDB Lightning は、NotLeader エラーの再試行中にリージョンピア情報を更新できません。 - - [問題-43291](https://github.com/pingcap/tidb/issues/43291) : 一時ファイルが見つからない場合 (「そのようなファイルまたはディレクトリはありません」というエラー)、 TiDB Lightning は再試行しません。 + - [問題-14745](https://github.com/tikv/tikv/issues/14745) : インポートが完了すると、TiKV インポート ディレクトリに大量の一時ファイルが残ります。 + - [問題-6426](https://github.com/tikv/pd/issues/6426) : PD [レンジスケジュール](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#scope-of-pausing-scheduling-during-import)インターフェースがリージョンの分散に失敗し、タイムアウトの問題が発生する可能性があります。v6.2.0より前では、グローバルスケジューリングはデフォルトで無効になっているため、この問題の発生を回避できます。 + - [問題-43079](https://github.com/pingcap/tidb/pull/43079) : TiDB Lightning は、NotLeader エラーの再試行中にリージョンピア情報を更新できません。 + - [問題-43291](https://github.com/pingcap/tidb/issues/43291) : 一時ファイルが見つからない場合 (「そのようなファイルまたはディレクトリはありません」というエラー)、 TiDB Lightning は再試行しません。 ## ソースファイルの準備 {#prepare-source-files} -- ソースファイルを生成する際は、単一ファイル内で主キーでソートすることをお勧めします。テーブル定義に主キーがない場合は、AUTO_INCREMENT主キーを追加できます。この場合、ファイルの内容の順序は関係ありません。 -- ソースファイルを複数のTiDB Lightningインスタンスに割り当てる際は、複数のソースファイル間で重複する主キーやnull以外の一意インデックスが存在する状況を避けるようにしてください。生成されたファイルがグローバルにソートされている場合は、範囲に基づいて異なるTiDB Lightningインスタンスに分散することで、最適なインポートパフォーマンスを実現できます。 -- ファイル生成中に各ファイルのサイズが 96 MiB 未満になるように制御します。 -- ファイルが非常に大きく、256 MiB を超える場合は、 [`strict-format`](/migrate-from-csv-files-to-tidb.md#step-4-tune-the-import-performance-optional)を有効にします。 +- ソースファイルを生成する際は、単一ファイル内で主キーでソートすることをお勧めします。テーブル定義に主キーがない場合は、AUTO_INCREMENT主キーを追加できます。この場合、ファイルの内容の順序は関係ありません。 +- ソースファイルを複数のTiDB Lightningインスタンスに割り当てる際は、複数のソースファイル間で重複する主キーやnull以外の一意インデックスが存在する状況を避けるようにしてください。生成されたファイルがグローバルにソートされている場合は、範囲に基づいて異なるTiDB Lightningインスタンスに分散することで、最適なインポートパフォーマンスを実現できます。 +- ファイル生成中に各ファイルのサイズが 96 MiB 未満になるように制御します。 +- ファイルが非常に大きく、256 MiB を超える場合は、 [`strict-format`](/migrate-from-csv-files-to-tidb.md#step-4-tune-the-import-performance-optional)を有効にします。 ## ストレージスペースの見積もり {#estimate-storage-space} データのインポートに必要なストレージ容量を見積もるには、次の 2 つの方法のいずれかを使用できます。 -- 総データサイズを**A** 、総インデックスサイズを**B** 、レプリケーション係数を**3** 、圧縮率を**α** （通常は約2.5）と仮定すると、全体の占有領域は**(A+B)*3/α**で計算できます。この方法は主に、データのインポートを実行せずにクラスタトポロジを計画する際に、概算を行うために使用されます。 -- データの10%のみをインポートし、実際に使用されている容量に10を掛けることで、そのデータバッチの最終的な容量使用量を推定します。この方法は、特に大量のデータをインポートする場合に、より正確です。 +- 総データサイズを**A** 、総インデックスサイズを**B** 、レプリケーション係数を**3** 、圧縮率を**α** （通常は約2.5）と仮定すると、全体の占有領域は**(A+B)*3/α**で計算できます。この方法は主に、データのインポートを実行せずにクラスタトポロジを計画する際に、概算を行うために使用されます。 +- データの10%のみをインポートし、実際に使用されている容量に10を掛けることで、そのデータバッチの最終的な容量使用量を推定します。この方法は、特に大量のデータをインポートする場合に、より正確です。 なお、圧縮やスナップショットのレプリケーションなどのバックグラウンド タスクもストレージ領域の一部を消費するため、20% のストレージ領域を予約することをお勧めします。 ## 設定パラメータを変更する {#change-configuration-parameters} -- `region-concurrency` : TiDB Lightning のメイン論理処理の同時実行性。並列インポート中は、リソースの過負荷と潜在的な OOM 問題を防ぐため、CPU コアの 75% に設定することをお勧めします。 -- `send-kv-pairs` : TiDB Lightningが1回のリクエストでTiKVに送信するキーと値のペアの数。この値は、send-kv-pairs * row-size < 1 MiBという式に基づいて調整することをお勧めします。v7.2.0以降、このパラメータは`send-kv-size`に置き換えられ、追加の設定は不要です。 -- `disk-quota` : TiDB Lightningのソートディレクトリの容量がデータソースのサイズよりも大きいことを確認することをお勧めします。確保できない場合は、 `disk-quota` TiDB Lightningのソートディレクトリの容量の 80% に設定できます。これにより、 TiDB Lightning は指定された`disk-quota`に従ってデータを一括でソートして書き込みますが、この方法では完全なソート処理と比較してインポートパフォーマンスが低下する可能性があることに注意してください。 -- `GOMEMLIMIT` : TiDB LightningはGo言語で実装されています。インスタンスメモリの80%を`GOMEMLIMIT`に設定することで、GoのGCメカニズムによるOOMの発生確率を低減します。 +- `region-concurrency` : TiDB Lightning のメイン論理処理の同時実行性。並列インポート中は、リソースの過負荷と潜在的な OOM 問題を防ぐため、CPU コアの 75% に設定することをお勧めします。 +- `send-kv-pairs` : TiDB Lightningが1回のリクエストでTiKVに送信するキーと値のペアの数。この値は、send-kv-pairs * row-size < 1 MiBという式に基づいて調整することをお勧めします。v7.2.0以降、このパラメータは`send-kv-size`に置き換えられ、追加の設定は不要です。 +- `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)を参照してください。 @@ -101,9 +101,9 @@ TiDB Lightningパラメータの詳細については、 [TiDB Lightning構成 データ検証中に競合が発生する可能性があります。エラーメッセージは「チェックサムが一致しません」です。この問題を解決するには、必要に応じて以下の手順を実行してください。 -1. ソースデータで主キーまたは一意キーの競合がないか確認し、再インポート前に競合を解決してください。ほとんどの場合、これが最も一般的な原因です。 -2. テーブルの主キーまたは一意キーの定義が適切かどうかを確認してください。適切でない場合は、テーブル定義を修正してデータを再インポートしてください。 -3. 上記の2つの手順を実行しても問題が解決しない場合は、ソースデータに少量（10%未満）の予期しない競合データが存在するかどうかを確認するために、さらに調査する必要があります。TiDB Lightningが競合データを検出して解決できるようにするには、 [競合検出](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#conflict-detection)を有効にしてください。 +1. ソースデータで主キーまたは一意キーの競合がないか確認し、再インポート前に競合を解決してください。ほとんどの場合、これが最も一般的な原因です。 +2. テーブルの主キーまたは一意キーの定義が適切かどうかを確認してください。適切でない場合は、テーブル定義を修正してデータを再インポートしてください。 +3. 上記の2つの手順を実行しても問題が解決しない場合は、ソースデータに少量（10%未満）の予期しない競合データが存在するかどうかを確認するために、さらに調査する必要があります。TiDB Lightningが競合データを検出して解決できるようにするには、 [競合検出](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#conflict-detection)を有効にしてください。 ## チェックポイントを有効にする {#enable-checkpoint} @@ -117,8 +117,8 @@ TiDB Lightningパラメータの詳細については、 [TiDB Lightning構成 このセクションでは、大規模な単一テーブルをインポートするためのベストプラクティスを紹介します。大規模な単一テーブルには厳密な定義はありませんが、一般的には以下のいずれかの基準を満たすものと見なされます。 -- テーブルサイズが10 TiBを超えています。 -- 幅の広い表では行数が 10 億を超え、列数が 50 を超えます。 +- テーブルサイズが10 TiBを超えています。 +- 幅の広い表では行数が 10 億を超え、列数が 50 を超えます。 ### ソースファイルを生成する {#generate-source-files} @@ -134,15 +134,15 @@ TiDB Lightningインスタンスを準備し、各インスタンスが5TiB～10 ### 設定パラメータを変更する {#change-configuration-parameters} -- TiDB Lightningインスタンスのコア数の`region-concurrency` ～ 75% を設定します。 -- `send-kv-pairs`を`3200`に設定します。この方法はTiDB v7.1.0以前のバージョンに適用されます。v7.2.0以降では、このパラメータは`send-kv-size`に置き換えられ、追加の設定は不要です。 -- インスタンスが配置されているノード上のメモリを`GOMEMLIMIT` ～ 80% に調整します。 +- TiDB Lightningインスタンスのコア数の`region-concurrency` ～ 75% を設定します。 +- `send-kv-pairs`を`3200`に設定します。この方法はTiDB v7.1.0以前のバージョンに適用されます。v7.2.0以降では、このパラメータは`send-kv-size`に置き換えられ、追加の設定は不要です。 +- インスタンスが配置されているノード上のメモリを`GOMEMLIMIT` ～ 80% に調整します。 インポートプロセス中の PD 散布リージョンのレイテンシーが30 分を超える場合は、次の最適化を検討してください。 -- TiKV クラスターで I/O ボトルネックが発生しているかどうかを確認します。 -- TiKV `raftstore.apply-pool-size`をデフォルト値の`2`から`4`または`8`に増やします。 -- TiDB Lightning `region-split-concurrency`をCPU コア数の半分に減らします (最小値は`1` )。 +- TiKV クラスターで I/O ボトルネックが発生しているかどうかを確認します。 +- TiKV `raftstore.apply-pool-size`をデフォルト値の`2`から`4`または`8`に増やします。 +- TiDB Lightning `region-split-concurrency`をCPU コア数の半分に減らします (最小値は`1` )。 ### 分析操作を無効にする {#disable-the-analyze-operation} diff --git a/tidb-lightning/deploy-tidb-lightning.md b/tidb-lightning/deploy-tidb-lightning.md index 833e570efb3e8..9fe1f7bac0b58 100644 --- a/tidb-lightning/deploy-tidb-lightning.md +++ b/tidb-lightning/deploy-tidb-lightning.md @@ -7,12 +7,12 @@ summary: TiDB Lightningをデプロイ、大量の新しいデータを迅速に このドキュメントでは、TiDB Lightningを使用してデータをインポートするためのハードウェア要件と、手動でのデプロイ方法について説明します。ハードウェアリソースの要件は、インポートモードによって異なります。詳細については、以下のドキュメントを参照してください。 -- [物理インポートモードの要件と制限](/tidb-lightning/tidb-lightning-physical-import-mode.md#requirements-and-restrictions) -- [論理インポートモードの要件と制限](/tidb-lightning/tidb-lightning-logical-import-mode.md) +- [物理インポートモードの要件と制限](/tidb-lightning/tidb-lightning-physical-import-mode.md#requirements-and-restrictions) +- [論理インポートモードの要件と制限](/tidb-lightning/tidb-lightning-logical-import-mode.md) ## TiUPを使用したオンライン展開 (推奨) {#online-deployment-using-tiup-recommended} -1. 次のコマンドを使用してTiUPをインストールします。 +1. 次のコマンドを使用してTiUPをインストールします。 ```shell curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh @@ -20,7 +20,7 @@ summary: TiDB Lightningをデプロイ、大量の新しいデータを迅速に このコマンドは、 TiUP を環境変数`PATH`に自動的に追加します。 TiUP を使用するには、新しいターミナルセッションを開始するか、 `source ~/.bashrc`を実行する必要があります。（環境によっては`source ~/.profile`を実行する必要がある場合があります。具体的なコマンドについては、 TiUPの出力を確認してください。） -2. TiUPを使用してTiDB Lightningをインストールします。 +2. TiUPを使用してTiDB Lightningをインストールします。 ```shell tiup install tidb-lightning diff --git a/tidb-lightning/import-into-vs-tidb-lightning.md b/tidb-lightning/import-into-vs-tidb-lightning.md index 781c348d68e0a..721a2c802b4e5 100644 --- a/tidb-lightning/import-into-vs-tidb-lightning.md +++ b/tidb-lightning/import-into-vs-tidb-lightning.md @@ -114,15 +114,15 @@ Due to the use of Global Sort, data imported into TiKV does not overlap, resulti 現在、 `IMPORT INTO`はまだいくつかの機能が欠けており、次のようなシナリオではTiDB Lightning を完全に置き換えることはできません。 -- 論理インポート +- 論理インポート `IMPORT INTO`でデータをインポートする前に、ターゲットテーブルは空である必要があります。既にデータが含まれているテーブルにデータをインポートする必要がある場合は、 [`LOAD DATA`](/sql-statements/sql-statement-load-data.md)や直接挿入などの方法を使用することをお勧めします。TiDB v8.0以降、大規模トランザクションの実行には[バルクDML](/system-variables.md#tidb_dml_type-new-in-v800)がサポートされます。 -- 競合データの処理 +- 競合データの処理 `IMPORT INTO`は現在、競合データの処理をサポートしていません。データのインポート前に、インポートするデータが主キー（PK）または一意キー（UK）と競合しないように、テーブルスキーマを適切に定義する必要があります。そうしないと、タスクが失敗する可能性があります。 -- 複数のターゲットテーブルへのデータのインポート +- 複数のターゲットテーブルへのデータのインポート 現在、 `IMPORT INTO` SQL文で指定できるターゲットテーブルは1つだけです。複数のターゲットテーブルにデータをインポートする場合は、 `IMPORT INTO`のSQL文を発行する必要があります。 diff --git a/tidb-lightning/monitor-tidb-lightning.md b/tidb-lightning/monitor-tidb-lightning.md index 2ed494e478c0c..26c57eeb83c28 100644 --- a/tidb-lightning/monitor-tidb-lightning.md +++ b/tidb-lightning/monitor-tidb-lightning.md @@ -127,118 +127,118 @@ scrape_configs: `tidb-lightning`によって提供されるメトリックは、名前空間`lightning_*`下にリストされます。 -- **`lightning_importer_engine`** (カウンター) +- **`lightning_importer_engine`** (カウンター) 開いているエンジン ファイルと閉じているエンジン ファイルの数をカウントします。ラベル: - - **タイプ**： - - `open` - - `closed` + - **タイプ**： + - `open` + - `closed` -- **`lightning_idle_workers`** （ゲージ） +- **`lightning_idle_workers`** （ゲージ） アイドル状態のワーカーをカウントします。ラベル: - - **名前**： - - `table` : `table-concurrency`の余り。通常はプロセス終了まで 0 です。 - - `index` : `index-concurrency`の余り。通常はプロセス終了まで 0 です。 - - `region` : `region-concurrency`の余り。通常はプロセス終了まで 0 です。 - - `io` : `io-concurrency`の余り。通常は設定された値（デフォルトは 5）に近い。0 に近い場合はディスクが遅すぎることを意味する。 - - `closed-engine` : 終了したがまだクリーンアップされていないエンジンの数。通常はインデックス + テーブル同時実行数（デフォルトは8）に近い値です。0に近い値は、TiDB LightningがTiKV Importerよりも高速であることを意味し、 TiDB Lightningが停止する可能性があります。 + - **名前**： + - `table` : `table-concurrency`の余り。通常はプロセス終了まで 0 です。 + - `index` : `index-concurrency`の余り。通常はプロセス終了まで 0 です。 + - `region` : `region-concurrency`の余り。通常はプロセス終了まで 0 です。 + - `io` : `io-concurrency`の余り。通常は設定された値（デフォルトは 5）に近い。0 に近い場合はディスクが遅すぎることを意味する。 + - `closed-engine` : 終了したがまだクリーンアップされていないエンジンの数。通常はインデックス + テーブル同時実行数（デフォルトは8）に近い値です。0に近い値は、TiDB LightningがTiKV Importerよりも高速であることを意味し、 TiDB Lightningが停止する可能性があります。 -- **`lightning_kv_encoder`** (カウンター) +- **`lightning_kv_encoder`** (カウンター) オープンおよびクローズされたKVエンコーダーをカウントします。KVエンコーダーは、SQL `INSERT`文をKVペアに変換するインメモリTiDBインスタンスです。健全な状況では、正味値は制限される必要があります。ラベル： - - **タイプ**： - - `open` - - `closed` + - **タイプ**： + - `open` + - `closed` -- **`lightning_tables`** （カウンター） +- **`lightning_tables`** （カウンター） 処理されたテーブルとそのステータスをカウントします。ラベル: - - **状態**: テーブルの状態。どのフェーズを完了する必要があるかを示します。 - - `pending` : まだ処理されていません - - `written` : すべてのデータがエンコードされて送信されました - - `closed` : 対応するすべてのエンジンファイルが閉じられています - - `imported` : すべてのエンジン ファイルがターゲット クラスターにインポートされました - - `altered_auto_inc` : AUTO_INCREMENT IDが変更されました - - `checksum` : チェックサムを実行 - - `analyzed` : 統計分析を実行しました - - `completed` : テーブルは完全にインポートされ、検証されました - - **結果**: 現在のフェーズの結果 - - `success` : フェーズは正常に完了しました - - `failure` : フェーズが失敗しました (完了しませんでした) - -- **`lightning_engines`** （カウンター） + - **状態**: テーブルの状態。どのフェーズを完了する必要があるかを示します。 + - `pending` : まだ処理されていません + - `written` : すべてのデータがエンコードされて送信されました + - `closed` : 対応するすべてのエンジンファイルが閉じられています + - `imported` : すべてのエンジン ファイルがターゲット クラスターにインポートされました + - `altered_auto_inc` : AUTO_INCREMENT IDが変更されました + - `checksum` : チェックサムを実行 + - `analyzed` : 統計分析を実行しました + - `completed` : テーブルは完全にインポートされ、検証されました + - **結果**: 現在のフェーズの結果 + - `success` : フェーズは正常に完了しました + - `failure` : フェーズが失敗しました (完了しませんでした) + +- **`lightning_engines`** （カウンター） 処理されたエンジンファイルの数とそのステータスをカウントします。ラベル: - - **状態**: エンジンの状態。どのフェーズを完了する必要があるかを示します。 - - `pending` : まだ処理されていません - - `written` : すべてのデータがエンコードされて送信されました - - `closed` : エンジンファイルが閉じられました - - `imported` : エンジンファイルがターゲットクラスターにインポートされました - - `completed` : エンジンが完全にインポートされました - - **結果**: 現在のフェーズの結果 - - `success` : フェーズは正常に完了しました - - `failure` : フェーズが失敗しました (完了しませんでした) + - **状態**: エンジンの状態。どのフェーズを完了する必要があるかを示します。 + - `pending` : まだ処理されていません + - `written` : すべてのデータがエンコードされて送信されました + - `closed` : エンジンファイルが閉じられました + - `imported` : エンジンファイルがターゲットクラスターにインポートされました + - `completed` : エンジンが完全にインポートされました + - **結果**: 現在のフェーズの結果 + - `success` : フェーズは正常に完了しました + - `failure` : フェーズが失敗しました (完了しませんでした) -- **`lightning_chunks`** （カウンター） +- **`lightning_chunks`** （カウンター） 処理されたチャンクの数とそのステータスをカウントします。ラベル: - - **状態**: チャンクのステータス。チャンクがどのフェーズにあるかを示します。 - - `estimated` : (状態ではない) この値は現在のタスク内のチャンクの合計数を示します - - `pending` : 読み込まれているがまだ処理されていない - - `running` : データがエンコードされ送信されています - - `finished` : チャンク全体が処理されました - - `failed` : 処理中にエラーが発生しました + - **状態**: チャンクのステータス。チャンクがどのフェーズにあるかを示します。 + - `estimated` : (状態ではない) この値は現在のタスク内のチャンクの合計数を示します + - `pending` : 読み込まれているがまだ処理されていない + - `running` : データがエンコードされ送信されています + - `finished` : チャンク全体が処理されました + - `failed` : 処理中にエラーが発生しました -- **`lightning_import_seconds`** （ヒストグラム） +- **`lightning_import_seconds`** （ヒストグラム） Bucketed histogram for the time needed to import a table. -- **`lightning_row_read_bytes`** （ヒストグラム） +- **`lightning_row_read_bytes`** （ヒストグラム） 単一の SQL 行のサイズのバケット化されたヒストグラム。 -- **`lightning_row_encode_seconds`** (ヒストグラム) +- **`lightning_row_encode_seconds`** (ヒストグラム) 単一の SQL 行を KV ペアにエンコードするために必要な時間のバケット化されたヒストグラム。 -- **`lightning_row_kv_deliver_seconds`** (ヒストグラム) +- **`lightning_row_kv_deliver_seconds`** (ヒストグラム) 1 つの SQL 行に対応する KV ペアのセットを配信するために必要な時間のバケット化されたヒストグラム。 -- **`lightning_block_deliver_seconds`** （ヒストグラム） +- **`lightning_block_deliver_seconds`** （ヒストグラム） KV ペアのブロックをインポーターに配信するために必要な時間のバケット化されたヒストグラム。 -- **`lightning_block_deliver_bytes`** （ヒストグラム） +- **`lightning_block_deliver_bytes`** （ヒストグラム） インポーターに配信された KV ペアのブロックの非圧縮サイズのバケット化されたヒストグラム。 -- **`lightning_chunk_parser_read_block_seconds`** (ヒストグラム) +- **`lightning_chunk_parser_read_block_seconds`** (ヒストグラム) データ ファイル パーサーがブロックを読み取るために必要な時間のバケット化されたヒストグラム。 -- **`lightning_checksum_seconds`** （ヒストグラム） +- **`lightning_checksum_seconds`** （ヒストグラム） テーブルのチェックサムを計算するために必要な時間のバケット化されたヒストグラム。 -- **`lightning_apply_worker_seconds`** (ヒストグラム) +- **`lightning_apply_worker_seconds`** (ヒストグラム) アイドル状態のワーカーを獲得するのに必要な時間のバケット化されたヒストグラム（ `lightning_idle_workers`ゲージも参照）。ラベル: - - **名前**： - - `table` - - `index` - - `region` - - `io` - - `closed-engine` + - **名前**： + - `table` + - `index` + - `region` + - `io` + - `closed-engine` diff --git a/tidb-lightning/tidb-lightning-checkpoints.md b/tidb-lightning/tidb-lightning-checkpoints.md index 04a587d1eb3ed..c6d432b180c99 100644 --- a/tidb-lightning/tidb-lightning-checkpoints.md +++ b/tidb-lightning/tidb-lightning-checkpoints.md @@ -49,9 +49,9 @@ driver = "file" TiDB Lightning は、ローカル ファイルまたはリモート MySQL 互換データベースの 2 種類のチェックポイントストレージをサポートしています。 -- `driver = "file"`の場合、チェックポイントは`dsn`で指定されたパスのローカルファイルに保存されます。チェックポイントは頻繁に更新されるため、RAMディスクなど、書き込み耐久性が非常に高いドライブにチェックポイントファイルを置くことを強くお勧めします。 +- `driver = "file"`の場合、チェックポイントは`dsn`で指定されたパスのローカルファイルに保存されます。チェックポイントは頻繁に更新されるため、RAMディスクなど、書き込み耐久性が非常に高いドライブにチェックポイントファイルを置くことを強くお勧めします。 -- `driver = "mysql"`の場合、MariaDBやTiDBを含む、 MySQL 5.7以降と互換性のある任意のデータベースにチェックポイントを保存できます。デフォルトでは、チェックポイントはターゲットデータベースに保存されます。 +- `driver = "mysql"`の場合、MariaDBやTiDBを含む、 MySQL 5.7以降と互換性のある任意のデータベースにチェックポイントを保存できます。デフォルトでは、チェックポイントはターゲットデータベースに保存されます。 Lightning は、ターゲットデータベースをチェックポイントのストレージとして使用している場合、大量のデータを同時にインポートします。これにより、ターゲットデータベースに余分な負荷がかかり、通信タイムアウトが発生する場合があります。そのため、**これらのチェックポイントを保存するための一時的な MySQLサーバーをインストールすることを強くお勧めします**。このサーバーは`tidb-lightning`と同じホストにインストールでき、インポート処理が完了したらアンインストールできます。 @@ -67,12 +67,12 @@ tidb-lightning-ctl --checkpoint-error-destroy='`schema`.`table`' このオプションを使用すると、テーブルのインポートを最初からやり直すことができます。スキーマ名とテーブル名はバッククォートで囲む必要があり、大文字と小文字が区別されます。 -- 以前にテーブル`` `schema`.`table` ``インポートに失敗した場合、このオプションは次の操作を実行します。 +- 以前にテーブル`` `schema`.`table` ``インポートに失敗した場合、このオプションは次の操作を実行します。 - 1. ターゲット データベースからテーブル`` `schema`.`table` ``を削除します。つまり、インポートされたすべてのデータが削除されます。 - 2. このテーブルのチェックポイント レコードを「まだ開始されていない」状態にリセットします。 + 1. ターゲット データベースからテーブル`` `schema`.`table` ``を削除します。つまり、インポートされたすべてのデータが削除されます。 + 2. このテーブルのチェックポイント レコードを「まだ開始されていない」状態にリセットします。 -- テーブル`` `schema`.`table` ``に関連するエラーがない場合、この操作は何も実行されません。 +- テーブル`` `schema`.`table` ``に関連するエラーがない場合、この操作は何も実行されません。 これは、すべてのテーブルに上記を適用するのと同じです。これは、チェックポイントエラーの問題を解決するための最も便利で安全かつ保守的な解決策です。 diff --git a/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md b/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md index 71640d699db55..a3e6c367f6aca 100644 --- a/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md +++ b/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md @@ -13,13 +13,13 @@ summary: IMPORT INTO およびTiDB Lightning とログ バックアップおよ ## ログバックアップおよびTiCDCとの互換性 {#compatibility-with-log-backup-and-ticdc} -- TiDB Lightning [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)は、ログ バックアップおよび TiCDC と互換性があります。 +- TiDB Lightning [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)は、ログ バックアップおよび TiCDC と互換性があります。 -- TiDB Lightning [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)は、ログバックアップおよびTiCDCと互換性がありません。これは、物理インポートモードがソースデータのエンコードされたKVペアをTiKVに直接取り込むため、TiKVがこの処理中に該当する変更ログを生成できないためです。変更ログが生成されないと、ログバックアップによる関連データのバックアップやTiCDCによるレプリケーションが実行できません。 +- 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に直接取り込まれるためです。 +- `IMPORT INTO`はログバックアップおよびTiCDCと互換性がありません。これは、 `IMPORT INTO`ではソースデータのエンコードされたKVペアもTiKVに直接取り込まれるためです。 ## TiDB Lightning論理インポートモードのシナリオ {#scenarios-for-tidb-lightning-logical-import-mode} @@ -43,11 +43,11 @@ TiCDC を物理インポート モードで使用することは、短期的に 次のようにさまざまなシナリオで実行できます。 -- シナリオ 1: テーブルを TiCDC によってダウンストリームに複製する必要はありません。 +- シナリオ 1: テーブルを TiCDC によってダウンストリームに複製する必要はありません。 このシナリオでは、TiCDC の changefeed が有効になっている場合、 TiDB Lightning の起動後に互換性チェックでエラーが報告されます。これらのテーブルにバックアップや[ログバックアップ](/br/br-pitr-guide.md)が必要ないことが確実な場合は、 [TiDB Lightning構成ファイル](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)の`Lightning.check-requirements`パラメータを`false`に変更してインポートタスクを再開できます。 -- シナリオ 2: テーブルを TiCDC によってダウンストリームに複製する必要があります。 +- シナリオ 2: テーブルを TiCDC によってダウンストリームに複製する必要があります。 このシナリオでは、TiCDC の changefeed が有効になっている場合、 TiDB Lightning の起動後に互換性チェックでエラーが報告されます。上流 TiDB クラスターの[TiDB Lightning構成ファイル](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)のパラメータ`Lightning.check-requirements`を`false`に変更し、インポートタスクを再起動する必要があります。 @@ -67,11 +67,11 @@ TiCDC を物理インポート モードで使用することは、短期的に 次のようにさまざまなシナリオで実行できます。 -- シナリオ 1: テーブルを TiCDC によってダウンストリームに複製する必要はありません。 +- シナリオ 1: テーブルを TiCDC によってダウンストリームに複製する必要はありません。 このシナリオでは、TiCDC の changefeed が有効になっている場合、 `IMPORT INTO`ステートメントを送信した後に互換性チェックでエラーが報告されます。これらのテーブルを TiCDC で複製する必要がないことが確実な場合は、そのステートメントの[`WithOptions`](/sql-statements/sql-statement-import-into.md#withoptions)に`DISABLE_PRECHECK` (v8.0.0 で導入) を含めて再送信できます。これにより、データインポートタスクは互換性チェックを無視し、データを直接インポートします。 -- シナリオ 2: テーブルを TiCDC によってダウンストリームに複製する必要があります。 +- シナリオ 2: テーブルを TiCDC によってダウンストリームに複製する必要があります。 このシナリオでは、TiCDC の changefeed が有効になっている場合、 `IMPORT INTO`ステートメントを送信した後に互換性チェックでエラーが報告されます。そのステートメントの[`WithOptions`](/sql-statements/sql-statement-import-into.md#withoptions)に`DISABLE_PRECHECK` (v8.0.0 で導入) を含めて再送信することができます。これにより、データインポートタスクは互換性チェックを無視し、データを直接インポートします。 diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index 13e10bbd80910..7943b7f66f719 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -15,46 +15,46 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `status-addr` {#status-addr} -- Prometheus メトリックを取得し、デバッグ データを公開し、サーバーモードでインポート タスクを送信するための HTTP ポート。 -- `0`に設定するとポートが無効になります。 +- Prometheus メトリックを取得し、デバッグ データを公開し、サーバーモードでインポート タスクを送信するための HTTP ポート。 +- `0`に設定するとポートが無効になります。 #### `server-mode` {#server-mode} -- サーバーモードを設定します。 -- デフォルト値: `false` -- 値のオプション: - - `false` : コマンドを実行するとすぐにインポート タスクが開始されます。 - - `true` : コマンド実行後、TiDB LightningはHTTP APIを介してインポート タスクを送信するまで待機します。 +- サーバーモードを設定します。 +- デフォルト値: `false` +- 値のオプション: + - `false` : コマンドを実行するとすぐにインポート タスクが開始されます。 + - `true` : コマンド実行後、TiDB LightningはHTTP APIを介してインポート タスクを送信するまで待機します。 #### `level` {#level} -- 例: `"info"` +- 例: `"info"` #### `file` {#file} -- 例: `"tidb-lightning.log"` +- 例: `"tidb-lightning.log"` #### `max-size` {#max-size} -- 例: `128` +- 例: `128` #### `max-days` {#max-days} -- 例: `28` +- 例: `28` #### `max-backups` {#max-backups} -- 例: `14` +- 例: `14` #### `enable-diagnose-logs` v7.3.0 の新機能 {#enable-diagnose-logs-new-in-v730} -- 診断ログを有効にするかどうかを制御します。 -- デフォルト値: `false` -- 値のオプション: - - `false` : インポートに関連するログのみが出力され、他の依存コンポーネントのログは出力されません。 - - `true` : インポートプロセスとその他の依存コンポーネントの両方からのログが出力され、診断に使用できる GRPC デバッグが有効になります。 +- 診断ログを有効にするかどうかを制御します。 +- デフォルト値: `false` +- 値のオプション: + - `false` : インポートに関連するログのみが出力され、他の依存コンポーネントのログは出力されません。 + - `true` : インポートプロセスとその他の依存コンポーネントの両方からのログが出力され、診断に使用できる GRPC デバッグが有効になります。 ## TiDB Lightning （タスク） {#tidb-lightning-task} @@ -62,55 +62,55 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `check-requirements` {#check-requirements} -- タスクを開始する前にクラスターが最小要件を満たしているかどうかを確認し、実行中に TiKV に 10% を超える空き容量が残っているかどうかを確認します。 +- タスクを開始する前にクラスターが最小要件を満たしているかどうかを確認し、実行中に TiKV に 10% を超える空き容量が残っているかどうかを確認します。 #### `index-concurrency` {#index-concurrency} -- 同時に開くインデックスエンジンの最大数。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時実行数を制御します。通常はデフォルト値を使用してください。 +- 同時に開くインデックスエンジンの最大数。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時実行数を制御します。通常はデフォルト値を使用してください。 #### `table-concurrency` {#table-concurrency} -- 同時に開くことができるデータエンジンの最大数です。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時接続数を制御します。通常はデフォルト値を使用してください。 +- 同時に開くことができるデータエンジンの最大数です。各テーブルは、インデックスを格納する1つの「インデックスエンジン」と、行データを格納する複数の「データエンジン」に分割されます。`index-concurrency`と`table-concurrency`の設定は、各エンジンタイプの最大同時接続数を制御します。通常はデフォルト値を使用してください。 #### `region-concurrency` {#region-concurrency} -- データの同時実行数。他のコンポーネントと一緒にデプロイする場合、CPU使用率を制限するために、論理CPUコアサイズの75%に設定できます。 -- デフォルト値: 論理CPUコアの数 +- データの同時実行数。他のコンポーネントと一緒にデプロイする場合、CPU使用率を制限するために、論理CPUコアサイズの75%に設定できます。 +- デフォルト値: 論理CPUコアの数 #### `io-concurrency` {#io-concurrency} -- 最大I/O同時実行数。I/O同時実行数が多すぎると、ディスクの内部バッファが頻繁に更新されるため、I/Oレイテンシーが増加し、キャッシュミスが発生し、読み取り速度が低下します。ストレージメディアによっては、最適なパフォーマンスを得るためにこの値を調整する必要があるかもしれません。 +- 最大I/O同時実行数。I/O同時実行数が多すぎると、ディスクの内部バッファが頻繁に更新されるため、I/Oレイテンシーが増加し、キャッシュミスが発生し、読み取り速度が低下します。ストレージメディアによっては、最適なパフォーマンスを得るためにこの値を調整する必要があるかもしれません。 #### `max-error` {#max-error} -- TiDB Lightning を停止する前に許容される致命的ではないエラーの最大数。 -- 致命的ではないエラーはいくつかの行に限定されており、それらの行を無視するとインポートプロセスを続行できます。 -- これを N に設定すると、(N+1) 番目のエラーが発生すると、 TiDB Lightning はできるだけ早く停止します。 -- スキップされた行は、ターゲット TiDB の`task info`スキーマ内のテーブルに挿入されます。 -- デフォルト値: `MaxInt64`バイト、つまり`9223372036854775807`バイト。 +- TiDB Lightning を停止する前に許容される致命的ではないエラーの最大数。 +- 致命的ではないエラーはいくつかの行に限定されており、それらの行を無視するとインポートプロセスを続行できます。 +- これを N に設定すると、(N+1) 番目のエラーが発生すると、 TiDB Lightning はできるだけ早く停止します。 +- スキップされた行は、ターゲット TiDB の`task info`スキーマ内のテーブルに挿入されます。 +- デフォルト値: `MaxInt64`バイト、つまり`9223372036854775807`バイト。 #### `task-info-schema-name` {#task-info-schema-name} -- TiDB Lightning実行結果を保存するスキーマまたはデータベースの名前を指定します。 -- エラー記録を無効にするには、これを空の文字列に設定します。 +- TiDB Lightning実行結果を保存するスキーマまたはデータベースの名前を指定します。 +- エラー記録を無効にするには、これを空の文字列に設定します。 #### `meta-schema-name` {#meta-schema-name} -- [並列インポートモード](/tidb-lightning/tidb-lightning-distributed-import.md)では、ターゲットクラスタ内の各TiDB Lightningインスタンスのメタ情報を格納するスキーマ名です。このパラメータは、並列インポートが有効な場合にのみ設定してください。 -- このパラメータに設定する値は、同じ並列インポートに参加する各TiDB Lightningインスタンスで同じである必要があります。そうでない場合、インポートされたデータの正確性は保証されません。 -- 並列インポート モードが有効になっている場合は、インポートに使用されるユーザー (構成`tidb.user` ) に、この構成に対応するデータベースを作成してアクセスする権限があることを確認します。 -- TiDB Lightningはインポート完了後にこのスキーマを削除します。そのため、このパラメータを設定する際に既存のスキーマ名を使用しないでください。 -- デフォルト値: `"lightning_metadata"` +- [並列インポートモード](/tidb-lightning/tidb-lightning-distributed-import.md)では、ターゲットクラスタ内の各TiDB Lightningインスタンスのメタ情報を格納するスキーマ名です。このパラメータは、並列インポートが有効な場合にのみ設定してください。 +- このパラメータに設定する値は、同じ並列インポートに参加する各TiDB Lightningインスタンスで同じである必要があります。そうでない場合、インポートされたデータの正確性は保証されません。 +- 並列インポート モードが有効になっている場合は、インポートに使用されるユーザー (構成`tidb.user` ) に、この構成に対応するデータベースを作成してアクセスする権限があることを確認します。 +- TiDB Lightningはインポート完了後にこのスキーマを削除します。そのため、このパラメータを設定する際に既存のスキーマ名を使用しないでください。 +- デフォルト値: `"lightning_metadata"` ### 安全 {#security} @@ -118,19 +118,19 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `ca-path` {#ca-path-1} -- CAの公開証明書を指定します。TLSを無効にする場合は空白のままにしてください。 +- CAの公開証明書を指定します。TLSを無効にする場合は空白のままにしてください。 #### `cert-path` {#cert-path-1} -- このサービスの公開証明書を指定します。 +- このサービスの公開証明書を指定します。 #### `key-path` {#key-path-1} -- このサービスの秘密鍵を指定します。 +- このサービスの秘密鍵を指定します。 @@ -138,38 +138,38 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `enable` {#enable} -- チェックポイントを有効にするかどうかを制御します。 -- データのインポート中に、 TiDB Lightning はどのテーブルがインポートされたかを記録するため、 TiDB Lightningまたは別のコンポーネントがクラッシュした場合でも、最初から再起動するのではなく、既知の正常な状態から開始できます。 +- チェックポイントを有効にするかどうかを制御します。 +- データのインポート中に、 TiDB Lightning はどのテーブルがインポートされたかを記録するため、 TiDB Lightningまたは別のコンポーネントがクラッシュした場合でも、最初から再起動するのではなく、既知の正常な状態から開始できます。 #### `schema` {#schema-1} -- チェックポイントを保存するスキーマ名 (データベース名) を指定します。 +- チェックポイントを保存するスキーマ名 (データベース名) を指定します。 #### `driver` {#driver} -- チェックポイントを保存する場所。 -- 値のオプション: - - `"file"` : ローカルファイルとして保存します。 - - `"mysql"` : リモートの MySQL 互換データベースに保存します。 +- チェックポイントを保存する場所。 +- 値のオプション: + - `"file"` : ローカルファイルとして保存します。 + - `"mysql"` : リモートの MySQL 互換データベースに保存します。 #### `dsn` {#dsn} -- チェックポイントストレージの場所を示すデータ ソース名 (DSN)。 -- `file`ドライバの場合、DSNはパスです。パスが指定されていない場合、 TiDB Lightningはデフォルト値の`/tmp/CHECKPOINT_SCHEMA.pb`を使用します。 -- `mysql`ドライバーの場合、 DSN は`USER:PASS@tcp(HOST:PORT)/`形式の URL です。 -- URL が指定されていない場合は、 `[tidb]`セクションの TiDBサーバーがチェックポイントの保存に使用されます。 -- ターゲット TiDB クラスターの負荷を軽減するには、別の MySQL 互換データベースサーバーを指定することをお勧めします。 +- チェックポイントストレージの場所を示すデータ ソース名 (DSN)。 +- `file`ドライバの場合、DSNはパスです。パスが指定されていない場合、 TiDB Lightningはデフォルト値の`/tmp/CHECKPOINT_SCHEMA.pb`を使用します。 +- `mysql`ドライバーの場合、 DSN は`USER:PASS@tcp(HOST:PORT)/`形式の URL です。 +- URL が指定されていない場合は、 `[tidb]`セクションの TiDBサーバーがチェックポイントの保存に使用されます。 +- ターゲット TiDB クラスターの負荷を軽減するには、別の MySQL 互換データベースサーバーを指定することをお勧めします。 #### `keep-after-success` {#keep-after-success} -- すべてのデータのインポート後もチェックポイントを保持するかどうかを制御します。`false`の場合、チェックポイントは削除されます。 -- チェックポイントを保持するとデバッグが容易になりますが、データ ソースに関するメタデータが漏洩します。 +- すべてのデータのインポート後もチェックポイントを保持するかどうかを制御します。`false`の場合、チェックポイントは削除されます。 +- チェックポイントを保持するとデバッグが容易になりますが、データ ソースに関するメタデータが漏洩します。 @@ -177,60 +177,60 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### `strategy` {#strategy} -- v7.3.0以降、競合データを処理するための新しい戦略が導入されました。v8.0.0以降、 TiDB Lightningは物理インポートモードと論理インポートモードの両方で競合戦略を最適化します。 -- デフォルト値: `""` -- 値のオプション: - - `""` : - - 物理インポートモードでは、 TiDB Lightning は競合するデータを検出または処理しません。ソースファイルに競合する主キーまたは一意キーのレコードが含まれている場合、後続のステップでエラーが報告されます。 - - 論理インポート モードでは、 TiDB Lightning は処理のために`""`戦略を`"error"`戦略に変換します。 - - `"error"` : インポートされたデータ内で競合する主キー レコードまたは一意のキー レコードが検出されると、 TiDB Lightning はインポートを終了し、エラーを報告します。 - - `"replace"` : 競合する主キー レコードまたは一意のキー レコードが発生した場合、 TiDB Lightning は最新のデータを保持し、古いデータを上書きします。 - - 物理インポート モードを使用すると、競合するデータはターゲット TiDB クラスターの`lightning_task_info.conflict_view`ビューに記録されます。 - - `lightning_task_info.conflict_view`ビューにおいて、行の`is_precheck_conflict`フィールドが`0`の場合、その行に記録された競合データは後処理の競合検出によって検出されたことを意味します。行の`is_precheck_conflict`フィールドが`1`の場合、その行に記録された競合データはインポート前の競合検出によって検出されたことを意味します。アプリケーション要件に基づいて、適切なレコードをターゲットテーブルに手動で挿入できます。 - - ターゲット TiKV は v5.2.0 以降のバージョンである必要があることに注意してください。 - - `"ignore"` : 主キーまたは一意キーのレコードの競合が発生した場合、 TiDB Lightning は古いデータを保持し、新しいデータを無視します。このオプションは論理インポートモードでのみ使用できます。 +- v7.3.0以降、競合データを処理するための新しい戦略が導入されました。v8.0.0以降、 TiDB Lightningは物理インポートモードと論理インポートモードの両方で競合戦略を最適化します。 +- デフォルト値: `""` +- 値のオプション: + - `""` : + - 物理インポートモードでは、 TiDB Lightning は競合するデータを検出または処理しません。ソースファイルに競合する主キーまたは一意キーのレコードが含まれている場合、後続のステップでエラーが報告されます。 + - 論理インポート モードでは、 TiDB Lightning は処理のために`""`戦略を`"error"`戦略に変換します。 + - `"error"` : インポートされたデータ内で競合する主キー レコードまたは一意のキー レコードが検出されると、 TiDB Lightning はインポートを終了し、エラーを報告します。 + - `"replace"` : 競合する主キー レコードまたは一意のキー レコードが発生した場合、 TiDB Lightning は最新のデータを保持し、古いデータを上書きします。 + - 物理インポート モードを使用すると、競合するデータはターゲット TiDB クラスターの`lightning_task_info.conflict_view`ビューに記録されます。 + - `lightning_task_info.conflict_view`ビューにおいて、行の`is_precheck_conflict`フィールドが`0`の場合、その行に記録された競合データは後処理の競合検出によって検出されたことを意味します。行の`is_precheck_conflict`フィールドが`1`の場合、その行に記録された競合データはインポート前の競合検出によって検出されたことを意味します。アプリケーション要件に基づいて、適切なレコードをターゲットテーブルに手動で挿入できます。 + - ターゲット TiKV は v5.2.0 以降のバージョンである必要があることに注意してください。 + - `"ignore"` : 主キーまたは一意キーのレコードの競合が発生した場合、 TiDB Lightning は古いデータを保持し、新しいデータを無視します。このオプションは論理インポートモードでのみ使用できます。 #### `precheck-conflict-before-import` {#precheck-conflict-before-import} -- インポート前の競合検出を有効にするかどうかを制御します。これは、TiDBにインポートする前にデータの競合をチェックします。このパラメータは、物理インポートモードでのみ使用できます。 -- 競合レコードの数が 1,000,000 を超えるシナリオでは、競合検出のパフォーマンスを向上させるために`precheck-conflict-before-import = true`設定することをお勧めします。 -- その他のシナリオでは、無効にすることをお勧めします。 -- デフォルト値: `false` -- 値のオプション: - - `false` : TiDB Lightning はインポート後にのみ競合をチェックします。 - - `true` : TiDB Lightning はインポートの前後の両方で競合をチェックします。 +- インポート前の競合検出を有効にするかどうかを制御します。これは、TiDBにインポートする前にデータの競合をチェックします。このパラメータは、物理インポートモードでのみ使用できます。 +- 競合レコードの数が 1,000,000 を超えるシナリオでは、競合検出のパフォーマンスを向上させるために`precheck-conflict-before-import = true`設定することをお勧めします。 +- その他のシナリオでは、無効にすることをお勧めします。 +- デフォルト値: `false` +- 値のオプション: + - `false` : TiDB Lightning はインポート後にのみ競合をチェックします。 + - `true` : TiDB Lightning はインポートの前後の両方で競合をチェックします。 #### `threshold` {#threshold} -- [`strategy`](#strategy)が`"replace"`または`"ignore"`の場合に処理できる競合エラーの最大数を制御します。`strategy`が`"replace"`または`"ignore"`の場合のみ設定できます。 -- `10000`より大きい値を設定すると、インポートプロセスのパフォーマンスが低下する可能性があります。 -- デフォルト値: `10000` +- [`strategy`](#strategy)が`"replace"`または`"ignore"`の場合に処理できる競合エラーの最大数を制御します。`strategy`が`"replace"`または`"ignore"`の場合のみ設定できます。 +- `10000`より大きい値を設定すると、インポートプロセスのパフォーマンスが低下する可能性があります。 +- デフォルト値: `10000` #### `max-record-rows` {#max-record-rows} -- `conflict_records`テーブル内のレコードの最大数を制御します。 -- v8.1.0 以降では、ユーザー入力に関係なく、 TiDB Lightning が`max-record-rows`の値に[`threshold`](#threshold)の値を自動的に割り当てるため、 `max-record-rows`手動で構成する必要はありません。 -- `max-record-rows`将来のリリースでは非推奨になります。 -- 物理インポートモードでは、戦略が`"replace"`の場合、上書きされる競合レコードが記録されます。 -- 論理インポート モードでは、戦略が`"ignore"`の場合、無視される競合レコードが記録され、戦略が`"replace"`の場合、競合レコードは記録されません。 -- デフォルト値: `10000` +- `conflict_records`テーブル内のレコードの最大数を制御します。 +- v8.1.0 以降では、ユーザー入力に関係なく、 TiDB Lightning が`max-record-rows`の値に[`threshold`](#threshold)の値を自動的に割り当てるため、 `max-record-rows`手動で構成する必要はありません。 +- `max-record-rows`将来のリリースでは非推奨になります。 +- 物理インポートモードでは、戦略が`"replace"`の場合、上書きされる競合レコードが記録されます。 +- 論理インポート モードでは、戦略が`"ignore"`の場合、無視される競合レコードが記録され、戦略が`"replace"`の場合、競合レコードは記録されません。 +- デフォルト値: `10000` ### tikvインポーター {#tikv-importer} #### `backend` {#backend} -- TiDB Lightningのインポート モードを指定します。 -- デフォルト値: `"local"` -- 値のオプション: - - `"local"` : [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md) （デフォルト）です。これは、例えば1 TiBを超えるような大規模なデータセットのインポートに適用されます。ただし、インポート中は下流のTiDBはサービスを提供できません。 - - `"tidb"` : [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md) 。このモードは、例えば1 TiB未満の小さなデータセットのインポートに使用できます。インポート中は、下流のTiDBがサービスを提供できます。 +- TiDB Lightningのインポート モードを指定します。 +- デフォルト値: `"local"` +- 値のオプション: + - `"local"` : [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md) （デフォルト）です。これは、例えば1 TiBを超えるような大規模なデータセットのインポートに適用されます。ただし、インポート中は下流のTiDBはサービスを提供できません。 + - `"tidb"` : [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md) 。このモードは、例えば1 TiB未満の小さなデータセットのインポートに使用できます。インポート中は、下流のTiDBがサービスを提供できます。 #### `parallel-import` {#parallel-import} -- 複数のTiDB Lightningインスタンス（物理インポートモード）が1つ以上のターゲットテーブル[並行して](/tidb-lightning/tidb-lightning-distributed-import.md)にデータをインポートできるようにするかどうかを制御します。このパラメータは、ターゲットテーブルが空の場合にのみ使用されることに注意してください。 -- デフォルト値: `false` -- 値のオプション: `true` 、 `false` -- 並列インポート モードを使用する場合は、パラメータを`true`に設定する必要がありますが、ターゲット テーブルにデータが存在しないことが前提となります。つまり、すべてのデータはTiDB Lightningによってのみインポートできます。 +- 複数のTiDB Lightningインスタンス（物理インポートモード）が1つ以上のターゲットテーブル[並行して](/tidb-lightning/tidb-lightning-distributed-import.md)にデータをインポートできるようにするかどうかを制御します。このパラメータは、ターゲットテーブルが空の場合にのみ使用されることに注意してください。 +- デフォルト値: `false` +- 値のオプション: `true` 、 `false` +- 並列インポート モードを使用する場合は、パラメータを`true`に設定する必要がありますが、ターゲット テーブルにデータが存在しないことが前提となります。つまり、すべてのデータはTiDB Lightningによってのみインポートできます。 #### `duplicate-resolution` {#duplicate-resolution} @@ -238,11 +238,11 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 > > バージョン8.0.0以降、 `duplicate-resolution`パラメータは非推奨となり、将来のリリースで削除される予定です。詳細については、 [競合検出の旧バージョン](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#the-old-version-of-conflict-detection-deprecated-in-v800)を参照してください。 -- 物理インポート モードで重複レコード (一意キーの競合) を検出して解決するかどうかを制御します。 -- デフォルト値: `'none'` -- 値のオプション: - - `'none'` : 重複レコードを検出しません。データソースに重複レコードがある場合、ターゲットTiDBでデータの不整合が発生する可能性があります。`duplicate-resolution = 'none'`を設定し、 `conflict.strategy`を設定していない場合、 TiDB Lightningは自動的に`conflict.strategy`に`""`を割り当てます。 - - `'remove'` : `duplicate-resolution = 'remove'`設定し、 `conflict.strategy`設定しない場合、 TiDB Lightning は自動的に`conflict.strategy`に「置換」を割り当て、新しいバージョンの競合検出を有効にします。 +- 物理インポート モードで重複レコード (一意キーの競合) を検出して解決するかどうかを制御します。 +- デフォルト値: `'none'` +- 値のオプション: + - `'none'` : 重複レコードを検出しません。データソースに重複レコードがある場合、ターゲットTiDBでデータの不整合が発生する可能性があります。`duplicate-resolution = 'none'`を設定し、 `conflict.strategy`を設定していない場合、 TiDB Lightningは自動的に`conflict.strategy`に`""`を割り当てます。 + - `'remove'` : `duplicate-resolution = 'remove'`設定し、 `conflict.strategy`設定しない場合、 TiDB Lightning は自動的に`conflict.strategy`に「置換」を割り当て、新しいバージョンの競合検出を有効にします。 #### `send-kv-pairs` {#send-kv-pairs} @@ -250,180 +250,180 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 > > バージョン7.2.0以降、このパラメータは非推奨となり、設定後は無効になります。1回のリクエストでTiKVに送信されるデータ量を調整したい場合は、代わりに[`send-kv-size`](#send-kv-size-new-in-v720)パラメータを使用してください。 -- 物理インポート モードで TiKV にデータを送信するときに、1 つの要求内の KV ペアの最大数を指定します。 +- 物理インポート モードで TiKV にデータを送信するときに、1 つの要求内の KV ペアの最大数を指定します。 #### `send-kv-size` v7.2.0 の新機能 {#send-kv-size-new-in-v720} -- 物理インポート モードで TiKV にデータを送信するときの 1 つのリクエストの最大サイズを指定します。 -- デフォルト値: `"16K"` +- 物理インポート モードで TiKV にデータを送信するときの 1 つのリクエストの最大サイズを指定します。 +- デフォルト値: `"16K"` #### `compress-kv-pairs` {#compress-kv-pairs} -- 物理インポート モードで KV ペアを TiKV に送信するときに圧縮を有効にするかどうかを制御します。 -- 現在、Gzip圧縮アルゴリズムのみがサポートされています。このアルゴリズムを使用するには、このパラメータに`"gzip"`または`"gz"`を入力してください。 -- デフォルト値: `""` 。圧縮が有効になっていないことを意味します。 -- 値のオプション: `""` 、 `"gzip"` 、 `"gz"` +- 物理インポート モードで KV ペアを TiKV に送信するときに圧縮を有効にするかどうかを制御します。 +- 現在、Gzip圧縮アルゴリズムのみがサポートされています。このアルゴリズムを使用するには、このパラメータに`"gzip"`または`"gz"`を入力してください。 +- デフォルト値: `""` 。圧縮が有効になっていないことを意味します。 +- 値のオプション: `""` 、 `"gzip"` 、 `"gz"` #### `sorted-kv-dir` {#sorted-kv-dir} -- 物理インポートモードにおけるローカルKVソートのディレクトリを指定します。ディスクパフォ​​ーマンスが低い場合（HDDなど）は、インポート速度を向上させるために、 `data-source-dir`とは異なるディスク上のディレクトリを設定することをお勧めします。 +- 物理インポートモードにおけるローカルKVソートのディレクトリを指定します。ディスクパフォ​​ーマンスが低い場合（HDDなど）は、インポート速度を向上させるために、 `data-source-dir`とは異なるディスク上のディレクトリを設定することをお勧めします。 #### `range-concurrency` {#range-concurrency} -- TiKV が物理インポート モードで KV データを書き込む同時実行性を指​​定します。 -- TiDB Lightningと TiKV 間のネットワーク伝送速度が 10 ギガビットを超える場合は、この値を適宜増やすことができます。 -- デフォルト値: `16` +- TiKV が物理インポート モードで KV データを書き込む同時実行性を指​​定します。 +- TiDB Lightningと TiKV 間のネットワーク伝送速度が 10 ギガビットを超える場合は、この値を適宜増やすことができます。 +- デフォルト値: `16` #### `store-write-bwlimit` {#store-write-bwlimit} -- 物理インポート モードでTiDB Lightning が各 TiKV ノードにデータを書き込む帯域幅を制限します。 -- デフォルト値: `0` 、制限がないことを意味します。 +- 物理インポート モードでTiDB Lightning が各 TiKV ノードにデータを書き込む帯域幅を制限します。 +- デフォルト値: `0` 、制限がないことを意味します。 #### `disk-quota` {#disk-quota} -- 物理インポート モードを使用する場合のローカル一時ファイルのディスク クォータを指定します。 -- ディスククォータが不足している場合、 TiDB Lightningはソースデータの読み取りと一時ファイルの書き込みを停止しますが、ソート済みのキーと値のペアをTiKVに書き込むことを優先します。TiDB Lightningがローカルの一時ファイルを削除した後、インポートプロセスは続行されます。 -- このオプションは、 [`backend`](#backend)オプションを`local`に設定した場合にのみ有効になります。 -- デフォルト値: `MaxInt64`バイト、つまり 9223372036854775807 バイト。 +- 物理インポート モードを使用する場合のローカル一時ファイルのディスク クォータを指定します。 +- ディスククォータが不足している場合、 TiDB Lightningはソースデータの読み取りと一時ファイルの書き込みを停止しますが、ソート済みのキーと値のペアをTiKVに書き込むことを優先します。TiDB Lightningがローカルの一時ファイルを削除した後、インポートプロセスは続行されます。 +- このオプションは、 [`backend`](#backend)オプションを`local`に設定した場合にのみ有効になります。 +- デフォルト値: `MaxInt64`バイト、つまり 9223372036854775807 バイト。 #### `add-index-by-sql` {#add-index-by-sql} -- 物理インポート モードで SQL 経由でインデックスを追加するかどうかを指定します。 -- このメカニズムは、過去のバージョンと一貫性があります。SQLを使用してインデックスを追加する利点は、データのインポートとインデックスのインポートを個別に実行できるため、データのインポートが高速化されることです。データのインポート後、インデックスの追加に失敗しても、インポートされたデータの整合性には影響しません。 -- デフォルト値: `false` -- 値のオプション: - - `false` : TiDB Lightningデータとインデックス データの両方を KV ペアにエンコードし、一緒に TiKV にインポートします。 - - `true` : TiDB Lightning は、行データをインポートした後、 `ADD INDEX` SQL ステートメントを介してインデックスを追加します。 +- 物理インポート モードで SQL 経由でインデックスを追加するかどうかを指定します。 +- このメカニズムは、過去のバージョンと一貫性があります。SQLを使用してインデックスを追加する利点は、データのインポートとインデックスのインポートを個別に実行できるため、データのインポートが高速化されることです。データのインポート後、インデックスの追加に失敗しても、インポートされたデータの整合性には影響しません。 +- デフォルト値: `false` +- 値のオプション: + - `false` : TiDB Lightningデータとインデックス データの両方を KV ペアにエンコードし、一緒に TiKV にインポートします。 + - `true` : TiDB Lightning は、行データをインポートした後、 `ADD INDEX` SQL ステートメントを介してインデックスを追加します。 #### `keyspace-name` {#keyspace-name} -- TiDB Lightningを使用してマルチテナント TiDB クラスターをインポートする場合は、このパラメータを使用して対応するキースペース名を指定します。 -- デフォルト値: `""` 。これは、 TiDB Lightning がデータをインポートするために、対応するテナントのキー スペース名を自動的に取得することを意味します。 -- 値を指定すると、指定されたキースペース名がデータのインポートに使用されます。 +- TiDB Lightningを使用してマルチテナント TiDB クラスターをインポートする場合は、このパラメータを使用して対応するキースペース名を指定します。 +- デフォルト値: `""` 。これは、 TiDB Lightning がデータをインポートするために、対応するテナントのキー スペース名を自動的に取得することを意味します。 +- 値を指定すると、指定されたキースペース名がデータのインポートに使用されます。 #### `pause-pd-scheduler-scope`バージョン7.1.0の新機能 {#pause-pd-scheduler-scope-new-in-v710} -- 物理インポート モードでは、このパラメータはTiDB Lightning がPD スケジュールを停止する範囲を制御します。 -- デフォルト値: `"table"` -- 値のオプション: - - `"table"` : ターゲット テーブル データを格納するリージョンのみのスケジュールを一時停止します。 - - `"global"` : グローバルスケジューリングを一時停止します。ビジネストラフィックのないクラスターにデータをインポートする場合は、他のスケジューリングからの干渉を避けるため、このパラメータを`"global"`に設定することをお勧めします。 +- 物理インポート モードでは、このパラメータはTiDB Lightning がPD スケジュールを停止する範囲を制御します。 +- デフォルト値: `"table"` +- 値のオプション: + - `"table"` : ターゲット テーブル データを格納するリージョンのみのスケジュールを一時停止します。 + - `"global"` : グローバルスケジューリングを一時停止します。ビジネストラフィックのないクラスターにデータをインポートする場合は、他のスケジューリングからの干渉を避けるため、このパラメータを`"global"`に設定することをお勧めします。 #### `region-split-batch-size` v7.1.0 の新機能 {#region-split-batch-size-new-in-v710} -- 物理インポート モードでは、このパラメータはバッチでリージョンを分割するときのリージョンの数を制御します。 -- TiDB Lightningインスタンスごとに同時に分割できるリージョンの最大数は次のとおりです: `region-split-batch-size * region-split-concurrency * table-concurrency` -- デフォルト値: `4096` +- 物理インポート モードでは、このパラメータはバッチでリージョンを分割するときのリージョンの数を制御します。 +- TiDB Lightningインスタンスごとに同時に分割できるリージョンの最大数は次のとおりです: `region-split-batch-size * region-split-concurrency * table-concurrency` +- デフォルト値: `4096` #### `region-split-concurrency` v7.1.0 の新機能 {#region-split-concurrency-new-in-v710} -- 物理インポート モードでは、このパラメーターはリージョンを分割する際の同時実行性を制御します。 -- デフォルト値: CPUコアの数 +- 物理インポート モードでは、このパラメーターはリージョンを分割する際の同時実行性を制御します。 +- デフォルト値: CPUコアの数 #### `region-check-backoff-limit`バージョン7.1.0の新機能 {#region-check-backoff-limit-new-in-v710} -- 物理インポート モードでは、このパラメータは、分割および分散操作後にリージョンがオンラインになるまで待機する再試行回数を制御します。 -- 再試行間隔は最大2秒です。再試行の間にいずれかのリージョンがオンラインになった場合でも、再試行回数は増加しません。 -- デフォルト値: `1800` +- 物理インポート モードでは、このパラメータは、分割および分散操作後にリージョンがオンラインになるまで待機する再試行回数を制御します。 +- 再試行間隔は最大2秒です。再試行の間にいずれかのリージョンがオンラインになった場合でも、再試行回数は増加しません。 +- デフォルト値: `1800` #### `block-size` v7.6.0 の新機能 {#block-size-new-in-v760} -- 物理インポートモードでは、このパラメータはローカルファイルのソートに使用するI/Oブロックサイズを制御します。ディスクIOPSがボトルネックになっている場合は、この値を増やすことでデータインポートのパフォーマンスを向上させることができます。 -- 値は`1B`以上である必要があります。数値のみ（例： `16` ）を指定した場合、単位は KiB ではなくバイトになります。 -- デフォルト値: `"16KiB"` +- 物理インポートモードでは、このパラメータはローカルファイルのソートに使用するI/Oブロックサイズを制御します。ディスクIOPSがボトルネックになっている場合は、この値を増やすことでデータインポートのパフォーマンスを向上させることができます。 +- 値は`1B`以上である必要があります。数値のみ（例： `16` ）を指定した場合、単位は KiB ではなくバイトになります。 +- デフォルト値: `"16KiB"` #### `logical-import-batch-size` v8.0.0 の新機能 {#logical-import-batch-size-new-in-v800} -- 論理インポート モードでは、このパラメータはダウンストリーム TiDBサーバーで実行される各 SQL ステートメントのサイズを制御します。 -- 単一のトランザクション内の`INSERT`または`REPLACE`ステートメントの`VALUES`部分の予想サイズを指定します。 -- このパラメータは厳密な制限ではありません。実際に実行されるSQLは、インポートされるコンテンツに応じて、これより長くなったり短くなったりする場合があります。 -- デフォルト値: `"96KiB"` 。これは、 TiDB Lightning がクラスターの唯一のクライアントである場合に、インポート速度が最適化されます。 -- TiDB Lightningの実装上の理由により、この値は96 KiBに制限されています。これより大きな値を設定しても効果はありません。この値を下げることで、大規模なトランザクションによるクラスターへの負荷を軽減できます。 +- 論理インポート モードでは、このパラメータはダウンストリーム TiDBサーバーで実行される各 SQL ステートメントのサイズを制御します。 +- 単一のトランザクション内の`INSERT`または`REPLACE`ステートメントの`VALUES`部分の予想サイズを指定します。 +- このパラメータは厳密な制限ではありません。実際に実行されるSQLは、インポートされるコンテンツに応じて、これより長くなったり短くなったりする場合があります。 +- デフォルト値: `"96KiB"` 。これは、 TiDB Lightning がクラスターの唯一のクライアントである場合に、インポート速度が最適化されます。 +- TiDB Lightningの実装上の理由により、この値は96 KiBに制限されています。これより大きな値を設定しても効果はありません。この値を下げることで、大規模なトランザクションによるクラスターへの負荷を軽減できます。 #### `logical-import-batch-rows` v8.0.0 の新機能 {#logical-import-batch-rows-new-in-v800} -- 論理インポート モードでは、このパラメータはトランザクションごとに挿入される行の最大数を制御します。 -- [`logical-import-batch-size`](#logical-import-batch-size-new-in-v800)と`logical-import-batch-rows`両方を指定した場合、最初にしきい値に達したパラメータが有効になります。 -- この値を減らすと、大規模なトランザクションによるクラスターのストレスを軽減できます。 -- デフォルト値: `65536` +- 論理インポート モードでは、このパラメータはトランザクションごとに挿入される行の最大数を制御します。 +- [`logical-import-batch-size`](#logical-import-batch-size-new-in-v800)と`logical-import-batch-rows`両方を指定した場合、最初にしきい値に達したパラメータが有効になります。 +- この値を減らすと、大規模なトランザクションによるクラスターのストレスを軽減できます。 +- デフォルト値: `65536` #### `logical-import-prep-stmt` {#logical-import-prep-stmt} -- 論理インポート モードでは、このパラメータは、パフォーマンスを向上させるために[準備された文](/sql-statements/sql-statement-prepare.md)およびステートメント キャッシュを使用するかどうかを制御します。 -- デフォルト値: `false` +- 論理インポート モードでは、このパラメータは、パフォーマンスを向上させるために[準備された文](/sql-statements/sql-statement-prepare.md)およびステートメント キャッシュを使用するかどうかを制御します。 +- デフォルト値: `false` ### mydumper {#mydumper} #### `read-block-size` {#read-block-size} -- ファイル読み取り時のブロックサイズを指定します。データソースの最長文字列よりも長く設定してください。 -- デフォルト値: `"64KiB"` +- ファイル読み取り時のブロックサイズを指定します。データソースの最長文字列よりも長く設定してください。 +- デフォルト値: `"64KiB"` #### `batch-import-ratio` {#batch-import-ratio} -- エンジンファイルは順番にインポートする必要があります。並列処理のため、複数のデータエンジンがほぼ同時にインポートされ、キューが生成されてリソースが浪費されます。そのため、 TiDB Lightning、リソースを適切に配分するために、最初の数バッチのサイズをわずかに大きくしています。 -- スケールアップ係数はこのパラメータによって制御されます。このパラメータは、完全な同時実行における「インポート」ステップと「書き込み」ステップの所要時間の比率を表します。これは、約1GiBの単一テーブルにおける比率（インポート所要時間/書き込み所要時間）を使用して計算できます。正確な時間はログで確認できます。 -- 「インポート」の方が高速であれば、バッチ サイズの分散は小さくなり、比率が 0 であればバッチ サイズは均一になります。 -- 範囲: `[0, 1)` +- エンジンファイルは順番にインポートする必要があります。並列処理のため、複数のデータエンジンがほぼ同時にインポートされ、キューが生成されてリソースが浪費されます。そのため、 TiDB Lightning、リソースを適切に配分するために、最初の数バッチのサイズをわずかに大きくしています。 +- スケールアップ係数はこのパラメータによって制御されます。このパラメータは、完全な同時実行における「インポート」ステップと「書き込み」ステップの所要時間の比率を表します。これは、約1GiBの単一テーブルにおける比率（インポート所要時間/書き込み所要時間）を使用して計算できます。正確な時間はログで確認できます。 +- 「インポート」の方が高速であれば、バッチ サイズの分散は小さくなり、比率が 0 であればバッチ サイズは均一になります。 +- 範囲: `[0, 1)` #### `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)を参照してください。 #### `character-set` {#character-set} -- `CREATE TABLE`ステートメントを含むスキーマ ファイルの文字セットを指定します。 -- デフォルト値: `"auto"` -- 値のオプション: - - `"auto"` : スキーマがUTF-8かGB-18030かを自動的に検出します。エンコードがどちらでもない場合はエラーが報告されます。 - - `"utf8mb4"` : スキーマ ファイルは UTF-8 としてエンコードする必要があります。それ以外の場合はエラーが報告されます。 - - `"gb18030"` : スキーマファイルは GB-18030 としてエンコードされている必要があります。そうでない場合はエラーが報告されます。 - - `"latin1"` : スキーマ ファイルは、コード ページ 1252 とも呼ばれる MySQL latin1 エンコードを使用します。 - - `"binary"` : スキーマファイルのデコードを試みない +- `CREATE TABLE`ステートメントを含むスキーマ ファイルの文字セットを指定します。 +- デフォルト値: `"auto"` +- 値のオプション: + - `"auto"` : スキーマがUTF-8かGB-18030かを自動的に検出します。エンコードがどちらでもない場合はエラーが報告されます。 + - `"utf8mb4"` : スキーマ ファイルは UTF-8 としてエンコードする必要があります。それ以外の場合はエラーが報告されます。 + - `"gb18030"` : スキーマファイルは GB-18030 としてエンコードされている必要があります。そうでない場合はエラーが報告されます。 + - `"latin1"` : スキーマ ファイルは、コード ページ 1252 とも呼ばれる MySQL latin1 エンコードを使用します。 + - `"binary"` : スキーマファイルのデコードを試みない #### `data-character-set` {#data-character-set} -- ソースデータファイルの文字セットを指定します。TiDB Lightning は、インポート時にソースファイルを指定された文字セットから UTF-8 エンコードに変換します。 -- 現在、この設定ではCSVファイルの文字セットのみを指定し、以下のオプションがサポートされています。空白のままにすると、デフォルト値の`"binary"`が使用され、Lightningはエンコーディングを変換しません。 -- TiDB Lightning はソース データ ファイルの文字セットを予測せず、この構成に基づいてソース ファイルを変換し、データをインポートするだけです。 -- この構成の値がソース データ ファイルの実際のエンコードと同じでない場合、インポートの失敗、データの損失、またはデータの乱れが発生する可能性があります。 -- デフォルト値: `"binary"` -- 値のオプション: - - `"binary"` : TiDB Lightning がエンコーディングを変換しないことを示します (デフォルト)。 - - `"utf8mb4"` : ソース データ ファイルが UTF-8 エンコードを使用していることを示します。 - - `"GB18030"` : ソース データ ファイルで GB-18030 エンコードが使用されていることを示します。 - - `"GBK"` : ソース データ ファイルは GBK エンコードを使用します (GBK エンコードは GB-2312 文字セットの拡張であり、コード ページ 936 とも呼ばれます)。 - - `"latin1"` : ソース データ ファイルは、コード ページ 1252 とも呼ばれる MySQL latin1 エンコードを使用します。 +- ソースデータファイルの文字セットを指定します。TiDB Lightning は、インポート時にソースファイルを指定された文字セットから UTF-8 エンコードに変換します。 +- 現在、この設定ではCSVファイルの文字セットのみを指定し、以下のオプションがサポートされています。空白のままにすると、デフォルト値の`"binary"`が使用され、Lightningはエンコーディングを変換しません。 +- TiDB Lightning はソース データ ファイルの文字セットを予測せず、この構成に基づいてソース ファイルを変換し、データをインポートするだけです。 +- この構成の値がソース データ ファイルの実際のエンコードと同じでない場合、インポートの失敗、データの損失、またはデータの乱れが発生する可能性があります。 +- デフォルト値: `"binary"` +- 値のオプション: + - `"binary"` : TiDB Lightning がエンコーディングを変換しないことを示します (デフォルト)。 + - `"utf8mb4"` : ソース データ ファイルが UTF-8 エンコードを使用していることを示します。 + - `"GB18030"` : ソース データ ファイルで GB-18030 エンコードが使用されていることを示します。 + - `"GBK"` : ソース データ ファイルは GBK エンコードを使用します (GBK エンコードは GB-2312 文字セットの拡張であり、コード ページ 936 とも呼ばれます)。 + - `"latin1"` : ソース データ ファイルは、コード ページ 1252 とも呼ばれる MySQL latin1 エンコードを使用します。 #### `data-invalid-char-replace` {#data-invalid-char-replace} -- ソース データ ファイルの文字セット変換中に互換性のない文字があった場合に置換する文字を指定します。 -- この設定は、フィールドセパレーター、引用符定義子、改行と重複してはいけません。デフォルト値を変更すると、ソースデータファイルの解析パフォーマンスが低下する可能性があります。 -- デフォルト値: `"\uFFFD"` 。これは、UTF-8 エンコードにおける「エラー」の Rune または Unicode 置換文字です。 +- ソース データ ファイルの文字セット変換中に互換性のない文字があった場合に置換する文字を指定します。 +- この設定は、フィールドセパレーター、引用符定義子、改行と重複してはいけません。デフォルト値を変更すると、ソースデータファイルの解析パフォーマンスが低下する可能性があります。 +- デフォルト値: `"\uFFFD"` 。これは、UTF-8 エンコードにおける「エラー」の Rune または Unicode 置換文字です。 #### `strict-format` {#strict-format} -- 処理速度を上げるには、入力データを[厳格な形式](/tidb-lightning/tidb-lightning-data-source.md#strict-format)で指定します。デフォルト値は、速度ではなく安全性を優先した`false`です。 -- デフォルト値: `false` -- 値のオプション: `true` 、 `false` -- `strict-format = true`次のことが求められます: - - CSV では、引用符で囲まれている場合でも、すべての値にリテラルの改行 ( `U+000A`と`U+000D` 、または`\r`と`\n` ) を含めることはできません。つまり、改行は行を区切るために厳密に使用されます。 - - 厳密なフォーマットにより、 TiDB Lightningは並列処理において大きなファイルの分割位置を迅速に特定できます。ただし、入力データが「厳密」でない場合、有効なデータが半分に分割され、結果が破損する可能性があります。 +- 処理速度を上げるには、入力データを[厳格な形式](/tidb-lightning/tidb-lightning-data-source.md#strict-format)で指定します。デフォルト値は、速度ではなく安全性を優先した`false`です。 +- デフォルト値: `false` +- 値のオプション: `true` 、 `false` +- `strict-format = true`次のことが求められます: + - CSV では、引用符で囲まれている場合でも、すべての値にリテラルの改行 ( `U+000A`と`U+000D` 、または`\r`と`\n` ) を含めることはできません。つまり、改行は行を区切るために厳密に使用されます。 + - 厳密なフォーマットにより、 TiDB Lightningは並列処理において大きなファイルの分割位置を迅速に特定できます。ただし、入力データが「厳密」でない場合、有効なデータが半分に分割され、結果が破損する可能性があります。 #### `max-region-size` {#max-region-size} -- [`strict-format`](#strict-format)が`true`の場合、 TiDB Lightning は大きな CSV ファイルを複数のチャンクに分割して並列処理します。`max-region-size`は分割後の各チャンクの最大サイズです。 -- デフォルト値: `"256MiB"` +- [`strict-format`](#strict-format)が`true`の場合、 TiDB Lightning は大きな CSV ファイルを複数のチャンクに分割して並列処理します。`max-region-size`は分割後の各チャンクの最大サイズです。 +- デフォルト値: `"256MiB"` #### `filter` {#filter} -- これらのワイルドカード ルールに一致するテーブルのみをインポートします。 +- これらのワイルドカード ルールに一致するテーブルのみをインポートします。 @@ -433,33 +433,33 @@ CSV ファイルの解析方法を構成します。 #### `separator` {#separator} -- フィールド間の区切り文字を指定します。1文字以上の文字をサポートします。 -- デフォルト値: `','` +- フィールド間の区切り文字を指定します。1文字以上の文字をサポートします。 +- デフォルト値: `','` #### `delimiter` {#delimiter} -- 引用符の区切り文字を指定します。値が空の場合、引用符は使用されません。 -- デフォルト値: `'"'` +- 引用符の区切り文字を指定します。値が空の場合、引用符は使用されません。 +- デフォルト値: `'"'` #### `terminator` {#terminator} -- 行末記号を指定します。 -- デフォルト値: `""` 。これは、 `"\n"` (LF) と`"\r\n"` (CRLF) の両方が行末文字であることを意味します。 +- 行末記号を指定します。 +- デフォルト値: `""` 。これは、 `"\n"` (LF) と`"\r\n"` (CRLF) の両方が行末文字であることを意味します。 #### `header` {#header} -- CSV ファイルにヘッダーが含まれているかどうかを制御します。 -- 値のオプション: - - `true` : TiDB Lightning は最初の行をテーブル ヘッダーとして扱い、データとしてインポートしません。 - - `false` : 最初の行も CSV データとしてインポートされます。 +- CSV ファイルにヘッダーが含まれているかどうかを制御します。 +- 値のオプション: + - `true` : TiDB Lightning は最初の行をテーブル ヘッダーとして扱い、データとしてインポートしません。 + - `false` : 最初の行も CSV データとしてインポートされます。 #### `header-schema-match` {#header-schema-match} -- CSV ファイル ヘッダー内の列名が、ターゲット テーブルで定義されている列名と一致するかどうかを制御します。 -- デフォルト値は`true`です。これは、CSV ヘッダーの列名がターゲット テーブルの列名と一致していることが確認されたことを意味します。そのため、2 つの列の順序が異なっていても、 TiDB Lightning は列名をマッピングすることでデータを正常にインポートできます。 -- CSVテーブルヘッダーとターゲットテーブルの列名が一致しない（例えば、CSVテーブルヘッダーの一部の列名がターゲットテーブルに見つからない）ものの、列の順序が同じ場合は、この設定を`false`に設定してください。この場合、 TiDB Lightningはエラーを回避するためにCSVヘッダーを無視し、ターゲットテーブルの列の順序でデータを直接インポートします。したがって、列の順序が同じでない場合は、インポート前にCSVファイル内の列の順序をターゲットテーブルの順序と一致するように手動で調整する必要があります。そうしないと、データの不一致が発生する可能性があります。 -- デフォルト値: `true` -- 値のオプション: `true` 、 `false` +- CSV ファイル ヘッダー内の列名が、ターゲット テーブルで定義されている列名と一致するかどうかを制御します。 +- デフォルト値は`true`です。これは、CSV ヘッダーの列名がターゲット テーブルの列名と一致していることが確認されたことを意味します。そのため、2 つの列の順序が異なっていても、 TiDB Lightning は列名をマッピングすることでデータを正常にインポートできます。 +- CSVテーブルヘッダーとターゲットテーブルの列名が一致しない（例えば、CSVテーブルヘッダーの一部の列名がターゲットテーブルに見つからない）ものの、列の順序が同じ場合は、この設定を`false`に設定してください。この場合、 TiDB Lightningはエラーを回避するためにCSVヘッダーを無視し、ターゲットテーブルの列の順序でデータを直接インポートします。したがって、列の順序が同じでない場合は、インポート前にCSVファイル内の列の順序をターゲットテーブルの順序と一致するように手動で調整する必要があります。そうしないと、データの不一致が発生する可能性があります。 +- デフォルト値: `true` +- 値のオプション: `true` 、 `false` > **Note:** > @@ -467,26 +467,26 @@ CSV ファイルの解析方法を構成します。 #### `not-null` {#not-null} -- CSV に NULL 値が含まれているかどうかを制御します。 -- 値のオプション: - - `true` : CSV のすべての列を NULL にすることはできません。 - - `false` : CSV には NULL 値を含めることができます。 +- CSV に NULL 値が含まれているかどうかを制御します。 +- 値のオプション: + - `true` : CSV のすべての列を NULL にすることはできません。 + - `false` : CSV には NULL 値を含めることができます。 #### `null` {#null} -- `not-null`が`false`の場合 (つまり、CSV に NULL を含めることができる場合)、この値に等しいフィールドは NULL として扱われます。 +- `not-null`が`false`の場合 (つまり、CSV に NULL を含めることができる場合)、この値に等しいフィールドは NULL として扱われます。 #### `backslash-escape` {#backslash-escape} -- フィールド内のバックスラッシュエスケープを解釈するかどうかを制御します。 +- フィールド内のバックスラッシュエスケープを解釈するかどうかを制御します。 #### `trim-last-separator` {#trim-last-separator} -- 行がセパレーターで終わる場合にそれを削除するかどうかを制御します。 +- 行がセパレーターで終わる場合にそれを削除するかどうかを制御します。 @@ -494,130 +494,130 @@ CSV ファイルの解析方法を構成します。 #### `pattern` {#pattern} -- AWS Aurora parquet ファイルを解析するために使用される式。 -- 例: `'(?i)^(?:[^/]*/)*([a-z0-9_]+)\.([a-z0-9_]+)/(?:[^/]*/)*(?:[a-z0-9\-_.]+\.(parquet))$'` +- AWS Aurora parquet ファイルを解析するために使用される式。 +- 例: `'(?i)^(?:[^/]*/)*([a-z0-9_]+)\.([a-z0-9_]+)/(?:[^/]*/)*(?:[a-z0-9\-_.]+\.(parquet))$'` #### `schema` {#schema} -- 例: `'$1'` +- 例: `'$1'` #### `table` {#table} -- 例: `'$2'` +- 例: `'$2'` #### `type` {#type} -- 例: `'$3'` +- 例: `'$3'` ### ティッド {#tidb} #### `host` {#host} -- クラスターからの任意の TiDBサーバーのコンフィグレーション。 +- クラスターからの任意の TiDBサーバーのコンフィグレーション。 #### `port` {#port} -- 例: `4000` +- 例: `4000` #### `user` {#user} -- 例: `"root"` +- 例: `"root"` #### `password` {#password} -- TiDBに接続するためのパスワードを設定します。パスワードはプレーンテキストまたはBase64エンコードのいずれかで使用できます。 +- TiDBに接続するためのパスワードを設定します。パスワードはプレーンテキストまたはBase64エンコードのいずれかで使用できます。 #### `status-port` {#status-port} -- TiDB からテーブル スキーマ情報を取得します。 +- TiDB からテーブル スキーマ情報を取得します。 #### `pd-addr` {#pd-addr} -- クラスター内の任意のPDサーバーのアドレスを指定します。v7.6.0以降、TiDBは複数のPDアドレスの設定をサポートします。 +- クラスター内の任意のPDサーバーのアドレスを指定します。v7.6.0以降、TiDBは複数のPDアドレスの設定をサポートします。 #### `log-level` {#log-level} -- TiDB ライブラリのログレベルを制御します。TiDB Lightning はTiDB をライブラリとしてインポートし、いくつかのログを自ら生成します。 +- TiDB ライブラリのログレベルを制御します。TiDB Lightning はTiDB をライブラリとしてインポートし、いくつかのログを自ら生成します。 #### `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)を参照してください。 -- [`checksum-via-sql`](#checksum-via-sql)を`"true"`に設定した場合、 TiDB Lightning は`ADMIN CHECKSUM TABLE
` SQL 文を実行して TiDB のチェックサム演算を実行します。この場合、以下のパラメータ`distsql-scan-concurrency`と`checksum-table-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)を参照してください。 -- [`checksum-via-sql`](#checksum-via-sql)を`"true"`に設定した場合、 TiDB Lightning は`ADMIN CHECKSUM TABLE
` SQL 文を実行して TiDB のチェックサム演算を実行します。この場合、以下のパラメータ`distsql-scan-concurrency`と`checksum-table-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`が無効になります。 #### `sql-mode` {#sql-mode} -- SQL ステートメントを解析および実行するために使用するデフォルトの SQL モードを指定します。 +- SQL ステートメントを解析および実行するために使用するデフォルトの SQL モードを指定します。 #### `max-allowed-packet` {#max-allowed-packet} -- SQL 接続に許可される最大パケット サイズを設定します。 -- これを`0`に設定すると、接続ごとにサーバーから`max_allowed_packet`変数が自動的に取得されます。 +- SQL 接続に許可される最大パケット サイズを設定します。 +- これを`0`に設定すると、接続ごとにサーバーから`max_allowed_packet`変数が自動的に取得されます。 #### `tls` {#tls} -- SQL 接続に TLS を使用するかどうかを制御します。 -- 値のオプション: - - `""` : [`[tidb.security]`](#tidbsecurity)セクションが設定されている場合、TLS を強制します（「cluster」と同じ）。それ以外の場合は`"false"`と同じです。 - - `"false"` : TLS を無効にします。 - - `"cluster"` : TLS を強制し、 [`[tidb.security]`](#tidbsecurity)セクションで指定された CA を使用してサーバーの証明書を検証します。 - - `"skip-verify"` : TLSを強制しますが、サーバーの証明書を検証しません。この設定は安全ではないことに注意してください。 - - `"preferred"` : `"skip-verify"`と同じですが、サーバーがTLS をサポートしていない場合は、暗号化されていない接続にフォールバックします。 +- SQL 接続に TLS を使用するかどうかを制御します。 +- 値のオプション: + - `""` : [`[tidb.security]`](#tidbsecurity)セクションが設定されている場合、TLS を強制します（「cluster」と同じ）。それ以外の場合は`"false"`と同じです。 + - `"false"` : TLS を無効にします。 + - `"cluster"` : TLS を強制し、 [`[tidb.security]`](#tidbsecurity)セクションで指定された CA を使用してサーバーの証明書を検証します。 + - `"skip-verify"` : TLSを強制しますが、サーバーの証明書を検証しません。この設定は安全ではないことに注意してください。 + - `"preferred"` : `"skip-verify"`と同じですが、サーバーがTLS をサポートしていない場合は、暗号化されていない接続にフォールバックします。 ### tidb.セキュリティ {#tidbsecurity} -- TLS 対応の MySQL 接続の証明書とキーを指定します。 -- デフォルト値: [`security`](#security)セクションのコピー。 +- TLS 対応の MySQL 接続の証明書とキーを指定します。 +- デフォルト値: [`security`](#security)セクションのコピー。 #### `ca-path` {#ca-path} -- CA の公開証明書を指定します。SQL の TLS を無効にする場合は、空の文字列に設定します。 +- CA の公開証明書を指定します。SQL の TLS を無効にする場合は、空の文字列に設定します。 #### `cert-path` {#cert-path} -- このサービスの公開証明書を指定します。 -- デフォルト値: [`security.cert-path`](#cert-path)のコピー。 +- このサービスの公開証明書を指定します。 +- デフォルト値: [`security.cert-path`](#cert-path)のコピー。 #### `key-path` {#key-path} -- このサービスの秘密鍵を指定します。 -- デフォルト値: [`security.key-path`](#key-path)のコピー。 +- このサービスの秘密鍵を指定します。 +- デフォルト値: [`security.key-path`](#key-path)のコピー。 @@ -629,55 +629,55 @@ CSV ファイルの解析方法を構成します。 ### 復元後 {#post-restore} -- 物理インポート モードでは、データのインポートが完了すると、 TiDB Lightning はチェックサムと`ANALYZE`操作を自動的に実行できます。 -- 実本番環境ではこれらを true のままにしておくことをお勧めします。 -- 実行順序: チェックサム -> `ANALYZE` 。 -- 論理インポート モードでは、チェックサムと`ANALYZE`操作は必要なく、実際の操作では常にスキップされることに注意してください。 +- 物理インポート モードでは、データのインポートが完了すると、 TiDB Lightning はチェックサムと`ANALYZE`操作を自動的に実行できます。 +- 実本番環境ではこれらを true のままにしておくことをお勧めします。 +- 実行順序: チェックサム -> `ANALYZE` 。 +- 論理インポート モードでは、チェックサムと`ANALYZE`操作は必要なく、実際の操作では常にスキップされることに注意してください。 #### `checksum` {#checksum} -- インポート後にデータの整合性を検証するために、テーブルごとに`ADMIN CHECKSUM TABLE
`を実行するかどうかを指定します。 -- デフォルト値: `"required"` 。v4.0.8 以降では、デフォルト値が`"true"`から`"required"`に変更されます。 -- 値のオプション: - - `"required"` : 管理者チェックサムを実行します。チェックサムが失敗した場合、 TiDB Lightning は失敗して終了します。 - - `"optional"` : 管理者チェックサムを実行します。チェックサムに失敗した場合、 TiDB Lightning はWARN ログを報告しますが、エラーは無視されます。 - - `"off"` : チェックサムを実行しません。 -- チェックサムの失敗は通常、インポート例外（データの損失または不整合）を意味します。チェックサムは常に有効にすることをお勧めします。 -- 下位互換性のため、このフィールドでは bool 値`true`と`false`も許可されます。`true`は`required`に相当し、 `false`は`off`に相当します。 +- インポート後にデータの整合性を検証するために、テーブルごとに`ADMIN CHECKSUM TABLE
`を実行するかどうかを指定します。 +- デフォルト値: `"required"` 。v4.0.8 以降では、デフォルト値が`"true"`から`"required"`に変更されます。 +- 値のオプション: + - `"required"` : 管理者チェックサムを実行します。チェックサムが失敗した場合、 TiDB Lightning は失敗して終了します。 + - `"optional"` : 管理者チェックサムを実行します。チェックサムに失敗した場合、 TiDB Lightning はWARN ログを報告しますが、エラーは無視されます。 + - `"off"` : チェックサムを実行しません。 +- チェックサムの失敗は通常、インポート例外（データの損失または不整合）を意味します。チェックサムは常に有効にすることをお勧めします。 +- 下位互換性のため、このフィールドでは bool 値`true`と`false`も許可されます。`true`は`required`に相当し、 `false`は`off`に相当します。 #### `checksum-via-sql` {#checksum-via-sql} -- `ADMIN CHECKSUM TABLE
`操作が TiDB 経由で実行されるかどうかを指定します。 -- デフォルト値: `"false"` -- 値のオプション: - - `"false"` : `ADMIN CHECKSUM TABLE
`コマンドは、 TiDB Lightning経由で実行するために TiKV に送信されます。 - - `"true"` : この値が`"true"`の場合に同時実行性を調整するには、TiDB で[`tidb_checksum_table_concurrency`](/system-variables.md#tidb_checksum_table_concurrency)変数を設定する必要があります。 -- チェックサムが失敗した場合に問題を特定しやすくするために、この値を`"true"`に設定することをお勧めします。 +- `ADMIN CHECKSUM TABLE
`操作が TiDB 経由で実行されるかどうかを指定します。 +- デフォルト値: `"false"` +- 値のオプション: + - `"false"` : `ADMIN CHECKSUM TABLE
`コマンドは、 TiDB Lightning経由で実行するために TiKV に送信されます。 + - `"true"` : この値が`"true"`の場合に同時実行性を調整するには、TiDB で[`tidb_checksum_table_concurrency`](/system-variables.md#tidb_checksum_table_concurrency)変数を設定する必要があります。 +- チェックサムが失敗した場合に問題を特定しやすくするために、この値を`"true"`に設定することをお勧めします。 #### `analyze` {#analyze} -- チェックサムが完了した後に各テーブルに対して`ANALYZE TABLE
`を実行するかどうかを指定します。 -- デフォルト値: `"optional"` -- 値のオプション: `"required"` 、 `"optional"` 、 `"off"` +- チェックサムが完了した後に各テーブルに対して`ANALYZE TABLE
`を実行するかどうかを指定します。 +- デフォルト値: `"optional"` +- 値のオプション: `"required"` 、 `"optional"` 、 `"off"` ### クローン {#cron} -- バックグラウンドでの定期的なアクションを設定します。 -- サポートされる単位: h (時間)、m (分)、s (秒)。 +- バックグラウンドでの定期的なアクションを設定します。 +- サポートされる単位: h (時間)、m (分)、s (秒)。 #### `switch-mode` {#switch-mode} -- TiDB Lightningがインポートモードのステータスを自動的に更新する間隔を指定します。対応するTiKV設定よりも短くする必要があります。 +- TiDB Lightningがインポートモードのステータスを自動的に更新する間隔を指定します。対応するTiKV設定よりも短くする必要があります。 #### `log-progress` {#log-progress} -- インポートの進行状況をログに出力する間隔を指定します。 +- インポートの進行状況をログに出力する間隔を指定します。 #### `check-disk-quota` {#check-disk-quota} -- 物理インポート モードを使用するときに、ローカル ディスク クォータをチェックする時間間隔を指定します。 -- デフォルト値: `"60s"` 、これは 60 秒を意味します。 +- 物理インポート モードを使用するときに、ローカル ディスク クォータをチェックする時間間隔を指定します。 +- デフォルト値: `"60s"` 、これは 60 秒を意味します。 diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md index 522a8cdff024d..345934a7db8d7 100644 --- a/tidb-lightning/tidb-lightning-data-source.md +++ b/tidb-lightning/tidb-lightning-data-source.md @@ -49,10 +49,10 @@ rename srcdb. tgtdb. *.sql 以下は、正規表現を使用してオンラインで名前を置換する例です。この例では、 -- データファイル`pattern`の一致ルールは`^({schema_regrex})\.({table_regrex})\.({file_serial_regrex})\.(csv|parquet|sql)`です。 -- `schema`を`'$1'`と指定すると、最初の正規表現の値`schema_regrex`は変更されません。または、 `schema` `'tgtdb'`などの文字列として指定すると、固定のターゲットデータベース名になります。 -- `table`を`'$2'`と指定すると、2番目の正規表現の値`table_regrex`は変更されません。または、 `table` `'t1'`などの文字列として指定すると、固定のターゲットテーブル名になります。 -- `type`を`'$3'` （データファイルの種類）として指定します。`type` `"table-schema"` （ `schema.sql`ファイル）または`"schema-schema"` （ `schema-create.sql`ファイル）として指定できます。 +- データファイル`pattern`の一致ルールは`^({schema_regrex})\.({table_regrex})\.({file_serial_regrex})\.(csv|parquet|sql)`です。 +- `schema`を`'$1'`と指定すると、最初の正規表現の値`schema_regrex`は変更されません。または、 `schema` `'tgtdb'`などの文字列として指定すると、固定のターゲットデータベース名になります。 +- `table`を`'$2'`と指定すると、2番目の正規表現の値`table_regrex`は変更されません。または、 `table` `'t1'`などの文字列として指定すると、固定のターゲットテーブル名になります。 +- `type`を`'$3'` （データファイルの種類）として指定します。`type` `"table-schema"` （ `schema.sql`ファイル）または`"schema-schema"` （ `schema-create.sql`ファイル）として指定できます。 ```toml [mydumper] @@ -103,8 +103,8 @@ compression = '$4' CSVファイルはスキーマレスです。CSVファイルをTiDBにインポートするには、テーブルスキーマを提供する必要があります。スキーマは、以下のいずれかの方法で提供できます。 -- DDL ステートメントを含む`${db_name}.${table_name}-schema.sql`および`${db_name}-schema-create.sql`名前のファイルを作成します。 -- TiDB にテーブル スキーマを手動で作成します。 +- DDL ステートメントを含む`${db_name}.${table_name}-schema.sql`および`${db_name}-schema-create.sql`名前のファイルを作成します。 +- TiDB にテーブル スキーマを手動で作成します。 ### コンフィグレーション {#configuration} @@ -145,47 +145,47 @@ trim-last-separator = false #### `separator` {#separator} -- フィールドセパレーターを定義します。 +- フィールドセパレーターを定義します。 -- 1 文字または複数文字を使用できますが、空にすることはできません。 +- 1 文字または複数文字を使用できますが、空にすることはできません。 -- 共通の値: +- 共通の値: - - CSV (カンマ区切り値)の場合は`','` 。 - - TSV (タブ区切り値)の場合は`"\t"` 。 - - `"\u0001"`を指定すると ASCII 文字`0x01`が使用されます。 + - CSV (カンマ区切り値)の場合は`','` 。 + - TSV (タブ区切り値)の場合は`"\t"` 。 + - `"\u0001"`を指定すると ASCII 文字`0x01`が使用されます。 -- LOAD DATA ステートメントの`FIELDS TERMINATED BY`オプションに対応します。 +- LOAD DATA ステートメントの`FIELDS TERMINATED BY`オプションに対応します。 #### `delimiter` {#delimiter} -- 引用符に使用する区切り文字を定義します。 +- 引用符に使用する区切り文字を定義します。 -- `delimiter`が空の場合、すべてのフィールドは引用符で囲まれません。 +- `delimiter`が空の場合、すべてのフィールドは引用符で囲まれません。 -- 共通の値: +- 共通の値: - - `'"'`フィールドを二重引用符で囲みます。 [RFC 4180](https://tools.ietf.org/html/rfc4180)と同じです。 - - `''`引用を無効にします。 + - `'"'`フィールドを二重引用符で囲みます。 [RFC 4180](https://tools.ietf.org/html/rfc4180)と同じです。 + - `''`引用を無効にします。 -- `LOAD DATA`ステートメントの`FIELDS ENCLOSED BY`オプションに対応します。 +- `LOAD DATA`ステートメントの`FIELDS ENCLOSED BY`オプションに対応します。 #### `terminator` {#terminator} -- 行末記号を定義します。 -- `terminator`が空の場合、行末文字として`"\n"` (改行) と`"\r\n"` (復帰 + 改行) の両方が使用されます。 -- `LOAD DATA`ステートメントの`LINES TERMINATED BY`オプションに対応します。 +- 行末記号を定義します。 +- `terminator`が空の場合、行末文字として`"\n"` (改行) と`"\r\n"` (復帰 + 改行) の両方が使用されます。 +- `LOAD DATA`ステートメントの`LINES TERMINATED BY`オプションに対応します。 #### `header` {#header} -- *すべての*CSV ファイルにヘッダー行が含まれているかどうか。 -- `header`が`true`の場合、最初の行は*列名*として使用されます。`header`が`false`の場合、最初の行は通常のデータ行として扱われます。 +- *すべての*CSV ファイルにヘッダー行が含まれているかどうか。 +- `header`が`true`の場合、最初の行は*列名*として使用されます。`header`が`false`の場合、最初の行は通常のデータ行として扱われます。 #### `not-null`と`null` {#not-null-and-null} -- `not-null`設定は、すべてのフィールドが null 不可かどうかを制御します。 -- `not-null`が`false`の場合、 `null`で指定された文字列は特定の値ではなく SQL NULL に変換されます。 -- 引用符で囲んでも、フィールドが null かどうかには影響しません。 +- `not-null`設定は、すべてのフィールドが null 不可かどうかを制御します。 +- `not-null`が`false`の場合、 `null`で指定された文字列は特定の値ではなく SQL NULL に変換されます。 +- 引用符で囲んでも、フィールドが null かどうかには影響しません。 たとえば、次の CSV ファイルでは、 @@ -198,9 +198,9 @@ trim-last-separator = false #### `backslash-escape` {#backslash-escape} -- フィールド内のバックスラッシュをエスケープ文字として解析するかどうか。 +- フィールド内のバックスラッシュをエスケープ文字として解析するかどうか。 -- `backslash-escape`が真の場合、次のシーケンスが認識され、変換されます。 +- `backslash-escape`が真の場合、次のシーケンスが認識され、変換されます。 | シーケンス | 変換された | | ----- | ------------------------ | @@ -213,13 +213,13 @@ trim-last-separator = false それ以外の場合（例えば`\"` ）、バックスラッシュは削除され、次の文字（ `"` ）がフィールドに残ります。残された文字は特別な役割（例えば区切り文字）を持たず、通常の文字として扱われます。 -- 引用符で囲んでも、バックスラッシュがエスケープ文字として解析されるかどうかには影響しません。 +- 引用符で囲んでも、バックスラッシュがエスケープ文字として解析されるかどうかには影響しません。 -- `LOAD DATA`ステートメントの`FIELDS ESCAPED BY '\'`オプションに対応します。 +- `LOAD DATA`ステートメントの`FIELDS ESCAPED BY '\'`オプションに対応します。 #### `trim-last-separator` {#trim-last-separator} -- `separator`行末文字として扱い、すべての末尾の区切り文字を削除するかどうか。 +- `separator`行末文字として扱い、すべての末尾の区切り文字を削除するかどうか。 たとえば、次の CSV ファイルでは、 @@ -227,10 +227,10 @@ trim-last-separator = false A,,B,, ``` - - `trim-last-separator = false`の場合、これは 5 つのフィールド`('A', '', 'B', '', '')`の行として解釈されます。 - - `trim-last-separator = true`の場合、これは 3 つのフィールド`('A', '', 'B')`の行として解釈されます。 + - `trim-last-separator = false`の場合、これは 5 つのフィールド`('A', '', 'B', '', '')`の行として解釈されます。 + - `trim-last-separator = true`の場合、これは 3 つのフィールド`('A', '', 'B')`の行として解釈されます。 -- このオプションは非推奨です。代わりにオプション`terminator`を使用してください。 +- このオプションは非推奨です。代わりにオプション`terminator`を使用してください。 既存の構成が次の場合: @@ -250,8 +250,8 @@ trim-last-separator = false TiDB Lightningは、 `LOAD DATA`文でサポートされているすべてのオプションをサポートしているわけではありません。例えば： -- 行頭語( `LINES STARTING BY` )は使用できません。 -- ヘッダーはスキップできません（ `IGNORE n LINES` ）、有効な列名である必要があります。 +- 行頭語( `LINES STARTING BY` )は使用できません。 +- ヘッダーはスキップできません（ `IGNORE n LINES` ）、有効な列名である必要があります。 ### 厳格なフォーマット {#strict-format} @@ -266,8 +266,8 @@ strict-format = true 厳密なCSVファイルでは、各フィールドは1行のみに収まります。つまり、次のいずれかの条件を満たす必要があります。 -- 区切り文字が空です。 -- 各フィールドにはターミネータ自体が含まれません。デフォルト設定では、これは各フィールドに CR ( `\r` ) または LF ( `\n` ) が含まれないことを意味します。 +- 区切り文字が空です。 +- 各フィールドにはターミネータ自体が含まれません。デフォルト設定では、これは各フィールドに CR ( `\r` ) または LF ( `\n` ) が含まれないことを意味します。 CSV ファイルが厳密ではなく、 `strict-format`が誤って`true`に設定されている場合、複数行にまたがるフィールドが 2 つのチャンクに分割され、解析が失敗したり、破損したデータが暗黙的にインポートされたりする可能性があります。 @@ -367,11 +367,11 @@ TiDB Lightningは現在、 Dumplingでエクスポートされた圧縮ファイ > **Note:** > -> - TiDB Lightningは単一の大きな圧縮ファイルを同時に解凍できないため、圧縮ファイルのサイズはインポート速度に影響します。解凍後のソースファイルは256MiB以下にすることをお勧めします。 -> - TiDB Lightning は個別に圧縮されたデータ ファイルのみをインポートし、複数のデータ ファイルが含まれる単一の圧縮ファイルのインポートはサポートしていません。 -> - TiDB Lightningは、 `db.table.parquet.snappy`などの他の圧縮ツールで圧縮された`parquet`ファイルをサポートしていません。`parquet`ファイルを圧縮する場合は、`parquet`ライターの圧縮形式を設定できます。 -> - TiDB Lightning v6.4.0以降のバージョンでは、 `gzip` 、 `snappy` 、 `zstd` 圧縮データファイルのみがサポートされています。その他の種類のファイルはエラーの原因となります。ソースデータファイルが保存されているディレクトリにサポートされていない圧縮ファイルが存在する場合、タスクはエラーを報告します。このようなエラーを回避するには、サポートされていないファイルをインポートデータディレクトリから移動してください。 -> - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)である必要があります。その他の Snappy 圧縮形式はサポートされていません。 +> - TiDB Lightningは単一の大きな圧縮ファイルを同時に解凍できないため、圧縮ファイルのサイズはインポート速度に影響します。解凍後のソースファイルは256MiB以下にすることをお勧めします。 +> - TiDB Lightning は個別に圧縮されたデータ ファイルのみをインポートし、複数のデータ ファイルが含まれる単一の圧縮ファイルのインポートはサポートしていません。 +> - TiDB Lightningは、 `db.table.parquet.snappy`などの他の圧縮ツールで圧縮された`parquet`ファイルをサポートしていません。`parquet`ファイルを圧縮する場合は、`parquet`ライターの圧縮形式を設定できます。 +> - TiDB Lightning v6.4.0以降のバージョンでは、 `gzip` 、 `snappy` 、 `zstd` 圧縮データファイルのみがサポートされています。その他の種類のファイルはエラーの原因となります。ソースデータファイルが保存されているディレクトリにサポートされていない圧縮ファイルが存在する場合、タスクはエラーを報告します。このようなエラーを回避するには、サポートされていないファイルをインポートデータディレクトリから移動してください。 +> - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)である必要があります。その他の Snappy 圧縮形式はサポートされていません。 ## カスタマイズされたファイルを一致させる {#match-customized-files} @@ -396,36 +396,36 @@ table = '$2' type = '$3' ``` -- **schema** : 対象データベースの名前。値は次のいずれかです。 - - 正規表現を使用して取得されたグループ インデックス (例: `$1` )。 - - インポートするデータベースの名前（例： `db1` ）。一致したすべてのファイルは`db1`にインポートされます。 -- **table** : 対象テーブルの名前。値は次のいずれかです。 - - 正規表現を使用して取得されたグループ インデックス (例: `$2` )。 - - インポートするテーブルの名前（例： `table1` ）。一致したすべてのファイルは`table1`にインポートされます。 -- **type** : ファイルの種類。`sql` 、`parquet` 、`csv`をサポートします。値は次のとおりです。 - - 正規表現を使用して取得されたグループ インデックス (例: `$3` )。 -- **key** : ファイル番号 (例: `${db_name}.${table_name}.001.csv`の場合は`001` 。 - - 正規表現を使用して取得されたグループ インデックス (例: `$4` )。 +- **schema** : 対象データベースの名前。値は次のいずれかです。 + - 正規表現を使用して取得されたグループ インデックス (例: `$1` )。 + - インポートするデータベースの名前（例： `db1` ）。一致したすべてのファイルは`db1`にインポートされます。 +- **table** : 対象テーブルの名前。値は次のいずれかです。 + - 正規表現を使用して取得されたグループ インデックス (例: `$2` )。 + - インポートするテーブルの名前（例： `table1` ）。一致したすべてのファイルは`table1`にインポートされます。 +- **type** : ファイルの種類。`sql` 、`parquet` 、`csv`をサポートします。値は次のとおりです。 + - 正規表現を使用して取得されたグループ インデックス (例: `$3` )。 +- **key** : ファイル番号 (例: `${db_name}.${table_name}.001.csv`の場合は`001` 。 + - 正規表現を使用して取得されたグループ インデックス (例: `$4` )。 ## Amazon S3からデータをインポートする {#import-data-from-amazon-s3} 以下の例は、TiDB Lightningを使用して Amazon S3 からデータをインポートする方法を示しています。詳細なパラメータ設定については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 -- ローカルに設定された権限を使用して S3 データにアクセスします。 +- ローカルに設定された権限を使用して S3 データにアクセスします。 ```bash 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' ``` -- パス形式のリクエストを使用して S3 データにアクセスします。 +- パス形式のリクエストを使用して S3 データにアクセスします。 ```bash 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?force-path-style=true&endpoint=http://10.154.10.132:8088' ``` -- 特定の AWS IAMロール ARN を使用して S3 データにアクセスします。 +- 特定の AWS IAMロール ARN を使用して S3 データにアクセスします。 ```bash tiup tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \ @@ -434,14 +434,14 @@ type = '$3' -- AWS IAMユーザーのアクセスキーを使用して S3 データにアクセスします。 +- AWS IAMユーザーのアクセスキーを使用して S3 データにアクセスします。 ```bash 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/test-data?access_key={my_access_key}&secret_access_key={my_secret_access_key}' ``` -- AWS IAMロールアクセスキーとセッショントークンの組み合わせを使用して、S3 データにアクセスします。 +- AWS IAMロールアクセスキーとセッショントークンの組み合わせを使用して、S3 データにアクセスします。 ```bash tiup tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \ @@ -450,5 +450,5 @@ type = '$3' ## その他のリソース {#more-resources} -- [Dumplingを使用してCSVファイルにエクスポートする](/dumpling-overview.md#export-to-csv-files) -- [`LOAD DATA`](https://dev.mysql.com/doc/refman/8.0/en/load-data.html) +- [Dumplingを使用してCSVファイルにエクスポートする](/dumpling-overview.md#export-to-csv-files) +- [`LOAD DATA`](https://dev.mysql.com/doc/refman/8.0/en/load-data.html) diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md index 8076603abb9e9..6da70cdc03562 100644 --- a/tidb-lightning/tidb-lightning-distributed-import.md +++ b/tidb-lightning/tidb-lightning-distributed-import.md @@ -11,16 +11,16 @@ TiDB Lightning v5.3.0以降、 [物理インポートモード](/tidb-lightning/ TiDB Lightning を使用すると、次のシナリオでデータを並列にインポートできます。 -- シャーディングされたスキーマとシャーディングされたテーブルをインポートします。このシナリオでは、複数の上流データベースインスタンスからの複数のテーブルが、異なるTiDB Lightningインスタンスによって下流 TiDB データベースに並行してインポートされます。 -- 単一テーブルの並列インポート。このシナリオでは、特定のディレクトリまたはクラウドストレージ（Amazon S3など）に保存された単一テーブルが、複数のTiDB Lightningインスタンスによって下流のTiDBクラスタに並列インポートされます。これはTiDB 5.3.0で導入された新機能です。 +- シャーディングされたスキーマとシャーディングされたテーブルをインポートします。このシナリオでは、複数の上流データベースインスタンスからの複数のテーブルが、異なるTiDB Lightningインスタンスによって下流 TiDB データベースに並行してインポートされます。 +- 単一テーブルの並列インポート。このシナリオでは、特定のディレクトリまたはクラウドストレージ（Amazon S3など）に保存された単一テーブルが、複数のTiDB Lightningインスタンスによって下流のTiDBクラスタに並列インポートされます。これはTiDB 5.3.0で導入された新機能です。 > **Note:** > -> - 並列インポートは、TiDB 内の初期化された空のテーブルのみをサポートし、既存のサービスによって書き込まれたデータを含むテーブルへのデータ移行はサポートしません。そうしないと、データの不整合が発生する可能性があります。 +> - 並列インポートは、TiDB 内の初期化された空のテーブルのみをサポートし、既存のサービスによって書き込まれたデータを含むテーブルへのデータ移行はサポートしません。そうしないと、データの不整合が発生する可能性があります。 > -> - 並列インポートは通常、物理インポートモードで使用されます。`parallel-import = true`を設定する必要があります。 +> - 並列インポートは通常、物理インポートモードで使用されます。`parallel-import = true`を設定する必要があります。 > -> - 複数のTiDB Lightningインスタンスを使用して同じターゲットにデータをインポートする場合は、一度に1つのバックエンドのみを適用してください。例えば、同じTiDBクラスターに物理インポートモードと論理インポートモードの両方で同時にデータをインポートすることはできません。 +> - 複数のTiDB Lightningインスタンスを使用して同じターゲットにデータをインポートする場合は、一度に1つのバックエンドのみを適用してください。例えば、同じTiDBクラスターに物理インポートモードと論理インポートモードの両方で同時にデータをインポートすることはできません。 ## 考慮事項 {#considerations} @@ -28,8 +28,8 @@ TiDB Lightning を使用すると、次のシナリオでデータを並列に ただし、データを並行して移行する場合は、次の点を考慮する必要があります。 -- 複数のシャードテーブル間の主キーまたは一意インデックス間の競合を処理する -- インポートパフォーマンスの最適化 +- 複数のシャードテーブル間の主キーまたは一意インデックス間の競合を処理する +- インポートパフォーマンスの最適化 ### 主キーまたは一意インデックス間の競合を処理する {#handle-conflicts-between-primary-keys-or-unique-indexes} @@ -39,31 +39,31 @@ TiDB Lightning を使用すると、次のシナリオでデータを並列に TiDB Lightningは、生成されたキーバリューデータを、対応するリージョンの各コピーが配置されているTiKVノードにアップロードする必要があるため、インポート速度はターゲットクラスタのサイズによって制限されます。ターゲットTiDBクラスタ内のTiKVインスタンスの数とTiDB Lightningインスタンスの数がn:1（nはリージョンのコピー数）より大きくすることを推奨します。同時に、最適なインポートパフォーマンスを実現するには、以下の要件を満たす必要があります。 -- 各TiDB Lightningインスタンスを専用マシンにデプロイします。1つのTiDB LightningインスタンスはデフォルトですべてのCPUリソースを消費するため、1台のマシンに複数のインスタンスをデプロイしてもパフォーマンスは向上しません。 -- 並列インポートを実行する各TiDB Lightningインスタンスのソースファイルの合計サイズは 5 TiB 未満である必要があります。 -- TiDB Lightningインスタンスの合計数は 10 未満である必要があります。 +- 各TiDB Lightningインスタンスを専用マシンにデプロイします。1つのTiDB LightningインスタンスはデフォルトですべてのCPUリソースを消費するため、1台のマシンに複数のインスタンスをデプロイしてもパフォーマンスは向上しません。 +- 並列インポートを実行する各TiDB Lightningインスタンスのソースファイルの合計サイズは 5 TiB 未満である必要があります。 +- TiDB Lightningインスタンスの合計数は 10 未満である必要があります。 TiDB Lightningを使用して共有データベースとテーブルを並列にインポートする場合は、データの量に応じて適切な数のTiDB Lightningインスタンスを選択します。 -- MySQL のデータ量が 2 TiB 未満の場合、1 つのTiDB Lightningインスタンスを並列インポートに使用できます。 -- MySQL データ量が 2 TiB を超え、MySQL インスタンスの合計数が 10 未満の場合、MySQL インスタンスごとに 1 つのTiDB Lightningインスタンスを使用することをお勧めします。また、並列TiDB Lightningインスタンスの数は 10 を超えないようにしてください。 -- MySQL データ量が 2 TiB を超え、MySQL インスタンスの合計数が 10 を超える場合は、これらの MySQL インスタンスによってエクスポートされたデータをインポートするために 5 ～ 10 個のTiDB Lightningインスタンスを割り当てることをお勧めします。 +- MySQL のデータ量が 2 TiB 未満の場合、1 つのTiDB Lightningインスタンスを並列インポートに使用できます。 +- MySQL データ量が 2 TiB を超え、MySQL インスタンスの合計数が 10 未満の場合、MySQL インスタンスごとに 1 つのTiDB Lightningインスタンスを使用することをお勧めします。また、並列TiDB Lightningインスタンスの数は 10 を超えないようにしてください。 +- MySQL データ量が 2 TiB を超え、MySQL インスタンスの合計数が 10 を超える場合は、これらの MySQL インスタンスによってエクスポートされたデータをインポートするために 5 ～ 10 個のTiDB Lightningインスタンスを割り当てることをお勧めします。 次に、このドキュメントでは、2 つの例を使用して、さまざまなシナリオでの並列インポートの操作手順を詳しく説明します。 -- 例1: Dumpling + TiDB Lightningを使用して、シャードデータベースとテーブルをTiDBに並列にインポートする -- 例2: 単一のテーブルを並列にインポートする +- 例1: Dumpling + TiDB Lightningを使用して、シャードデータベースとテーブルをTiDBに並列にインポートする +- 例2: 単一のテーブルを並列にインポートする ### 制限 {#restrictions} TiDB Lightning は実行時に一部のリソースを排他的に使用します。単一のマシン（本番環境では推奨されません）または複数のマシンで共有されるディスクに複数のTiDB Lightningインスタンスを展開する必要がある場合は、以下の使用制限にご注意ください。 -- 各TiDB Lightningインスタンスの一意のパスを`tikv-importer.sorted-kv-dir`に設定してください。複数のインスタンスが同じパスを共有すると、意図しない動作が発生し、インポートの失敗やデータエラーが発生する可能性があります。 -- 各TiDB Lightningチェックポイントは個別に保存してください。チェックポイントの設定の詳細については、 [TiDB Lightningチェックポイント](/tidb-lightning/tidb-lightning-checkpoints.md)を参照してください。 - - checkpoint.driver = "file" (デフォルト) を設定する場合は、チェックポイントへのパスがインスタンスごとに一意であることを確認してください。 - - checkpoint.driver = "mysql" を設定する場合は、インスタンスごとに一意のスキーマを設定する必要があります。 -- 各TiDB Lightningのログファイルは、それぞれ異なるパスに設定する必要があります。同じログファイルを共有すると、ログのクエリやトラブルシューティングに影響します。 -- Debug API またはサーバーモードの HTTP API を使用する場合は、インスタンスごとに`lightning.status-addr`を一意のアドレスに設定する必要があります。そうしないと、ポートの競合によりTiDB Lightningプロセスが起動に失敗します。 +- 各TiDB Lightningインスタンスの一意のパスを`tikv-importer.sorted-kv-dir`に設定してください。複数のインスタンスが同じパスを共有すると、意図しない動作が発生し、インポートの失敗やデータエラーが発生する可能性があります。 +- 各TiDB Lightningチェックポイントは個別に保存してください。チェックポイントの設定の詳細については、 [TiDB Lightningチェックポイント](/tidb-lightning/tidb-lightning-checkpoints.md)を参照してください。 + - checkpoint.driver = "file" (デフォルト) を設定する場合は、チェックポイントへのパスがインスタンスごとに一意であることを確認してください。 + - checkpoint.driver = "mysql" を設定する場合は、インスタンスごとに一意のスキーマを設定する必要があります。 +- 各TiDB Lightningのログファイルは、それぞれ異なるパスに設定する必要があります。同じログファイルを共有すると、ログのクエリやトラブルシューティングに影響します。 +- Debug API またはサーバーモードの HTTP API を使用する場合は、インスタンスごとに`lightning.status-addr`を一意のアドレスに設定する必要があります。そうしないと、ポートの競合によりTiDB Lightningプロセスが起動に失敗します。 ## 例 1: Dumpling + TiDB Lightningを使用して、シャードデータベースとテーブルを TiDB に並列インポートする {#example-1-use-dumpling-tidb-lightning-to-import-sharded-databases-and-tables-into-tidb-in-parallel} @@ -75,8 +75,8 @@ TiDB Lightning は実行時に一部のリソースを排他的に使用しま TiDB Lightningがデプロイされている 5 つのノード上の 2 つのシャード テーブルをエクスポートします。 -- 2つのシャードテーブルが同じMySQLインスタンス内にある場合、 Dumplingのパラメータ`--filter`を使用して直接エクスポートできます。TiDB Lightningを使用してインポートする場合は、 Dumplingがデータをエクスポートするディレクトリとして`data-source-dir`を指定できます。 -- 2つのシャードテーブルのデータが異なるMySQLノードに分散されている場合は、 Dumplingを使用して個別にエクスポートする必要があります。エクスポートしたデータは、同じ親ディレクトリ内、かつ異なるサブディレクトリに配置する必要があります。TiDB Lightningを使用して並列インポートを実行する場合は、親ディレクトリとして`data-source-dir`を指定する必要があります。 +- 2つのシャードテーブルが同じMySQLインスタンス内にある場合、 Dumplingのパラメータ`--filter`を使用して直接エクスポートできます。TiDB Lightningを使用してインポートする場合は、 Dumplingがデータをエクスポートするディレクトリとして`data-source-dir`を指定できます。 +- 2つのシャードテーブルのデータが異なるMySQLノードに分散されている場合は、 Dumplingを使用して個別にエクスポートする必要があります。エクスポートしたデータは、同じ親ディレクトリ内、かつ異なるサブディレクトリに配置する必要があります。TiDB Lightningを使用して並列インポートを実行する場合は、親ディレクトリとして`data-source-dir`を指定する必要があります。 Dumpling を使用してデータをエクスポートする方法の詳細については、 [Dumpling](/dumpling-overview.md)を参照してください。 @@ -126,9 +126,9 @@ nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out & 並列インポート中、 TiDB Lightning はタスクの開始後に次のチェックを自動的に実行します。 -- ローカルディスク（構成`sort-kv-dir`で制御）とTiKVクラスターに、データのインポートに必要な空き容量があるかどうかを確認してください。必要なディスク容量については、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)と[リソース要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)を参照してください。TiDB Lightningはデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。 -- TiKVクラスタ内のリージョンが均等に分散されているか、また空きリージョンが多すぎないかを確認してください。空きリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 -- データソースからデータが順番にインポートされているか確認します。確認結果に基づいて`mydumper.batch-size`のサイズが自動的に調整されます。そのため、 `mydumper.batch-size`構成は利用できなくなります。 +- ローカルディスク（構成`sort-kv-dir`で制御）とTiKVクラスターに、データのインポートに必要な空き容量があるかどうかを確認してください。必要なディスク容量については、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)と[リソース要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)を参照してください。TiDB Lightningはデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。 +- TiKVクラスタ内のリージョンが均等に分散されているか、また空きリージョンが多すぎないかを確認してください。空きリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 +- データソースからデータが順番にインポートされているか確認します。確認結果に基づいて`mydumper.batch-size`のサイズが自動的に調整されます。そのため、 `mydumper.batch-size`構成は利用できなくなります。 チェックをオフにして、 `lightning.check-requirements`設定で強制インポートを実行することもできます。詳細なチェックについては、 [TiDB Lightning事前チェック](/tidb-lightning/tidb-lightning-prechecks.md)を参照してください。 @@ -136,8 +136,8 @@ nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out & インポートを開始した後、次のいずれかの方法で進行状況を確認できます。 -- `grep` log キーワード`progress`で進捗状況を確認します。デフォルトでは5分ごとに更新されます。 -- 監視コンソールで進行状況を確認してください。詳細は[TiDB Lightning監視](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 +- `grep` log キーワード`progress`で進捗状況を確認します。デフォルトでは5分ごとに更新されます。 +- 監視コンソールで進行状況を確認してください。詳細は[TiDB Lightning監視](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 すべてのTiDB Lightningインスタンスが終了するまで待機すると、インポート全体が完了します。 @@ -188,19 +188,19 @@ parallel-import = true 並列インポート中に 1 つ以上のTiDB Lightningノードが異常終了した場合は、ログに記録されたエラーに基づいて原因を特定し、エラーの種類に応じてエラーを処理します。 -- エラーが通常の終了 (たとえば、kill コマンドに応答して終了) または OOM によるオペレーティング システムによる終了を示している場合は、構成を調整してから、 TiDB Lightningノードを再起動します。 +- エラーが通常の終了 (たとえば、kill コマンドに応答して終了) または OOM によるオペレーティング システムによる終了を示している場合は、構成を調整してから、 TiDB Lightningノードを再起動します。 -- ネットワーク タイムアウトなどのエラーがデータの精度に影響を与えない場合は、次の手順を実行します。 +- ネットワーク タイムアウトなどのエラーがデータの精度に影響を与えない場合は、次の手順を実行します。 - 1. チェックポイント ソース データのエラーを消去するには、失敗したすべてのノードで設定`--checkpoint-error-ignore=all`で[`checkpoint-error-ignore`](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-error-ignore)コマンドを実行します。 + 1. チェックポイント ソース データのエラーを消去するには、失敗したすべてのノードで設定`--checkpoint-error-ignore=all`で[`checkpoint-error-ignore`](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-error-ignore)コマンドを実行します。 - 2. チェックポイントからのデータのインポートを続行するには、これらのノードを再起動します。 + 2. チェックポイントからのデータのインポートを続行するには、これらのノードを再起動します。 -- ソース ファイル内の無効なデータを示すチェックサムの不一致など、データの不正確さにつながるエラーがログに記録されている場合は、次の手順を実行してこの問題を解決できます。 +- ソース ファイル内の無効なデータを示すチェックサムの不一致など、データの不正確さにつながるエラーがログに記録されている場合は、次の手順を実行してこの問題を解決できます。 - 1. 成功したノードを含むすべてのLightningノードで[`checkpoint-error-destroy`](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-error-destroy)コマンドを実行します。このコマンドは、失敗したテーブルからインポートされたデータを削除し、これらのテーブルのチェックポイントステータスを「未開始」にリセットします。 + 1. 成功したノードを含むすべてのLightningノードで[`checkpoint-error-destroy`](/tidb-lightning/tidb-lightning-checkpoints.md#--checkpoint-error-destroy)コマンドを実行します。このコマンドは、失敗したテーブルからインポートされたデータを削除し、これらのテーブルのチェックポイントステータスを「未開始」にリセットします。 - 2. 正常に終了するノードを含むすべてのTiDB Lightningノードで[`filter`](/table-filter.md)パラメータを使用して、失敗したテーブルのデータを再構成してインポートします。 + 2. 正常に終了するノードを含むすべてのTiDB Lightningノードで[`filter`](/table-filter.md)パラメータを使用して、失敗したテーブルのデータを再構成してインポートします。 Lightning の並列インポートタスクを再設定する際は、各 Lightning ノードの起動スクリプトに`checkpoint-error-destroy`コマンドを含めないでください。このコマンドを実行すると、複数の並列インポートタスクで使用されている共有メタデータが削除され、データインポート時に問題が発生する可能性があります。例えば、2つ目の Lightning インポートタスクを開始すると、最初のタスクによって書き込まれたメタデータが削除され、データインポートが正常に行われなくなります。 diff --git a/tidb-lightning/tidb-lightning-error-resolution.md b/tidb-lightning/tidb-lightning-error-resolution.md index 66c9ddbf3e0bd..2892f839b5d48 100644 --- a/tidb-lightning/tidb-lightning-error-resolution.md +++ b/tidb-lightning/tidb-lightning-error-resolution.md @@ -9,10 +9,10 @@ v5.4.0以降、 TiDB Lightningを設定して、無効な型変換や一意キ このドキュメントでは、TiDB Lightning のエラーの種類、エラーのクエリ方法、および例を紹介します。以下の設定項目が関係します。 -- `lightning.max-error` : 型エラーの許容閾値 -- `conflict.strategy` : 競合`conflict.max-record-rows` `conflict.threshold`に関連する構成 -- `tikv-importer.duplicate-resolution` (v8.0.0 で非推奨となり、将来のリリースで削除される予定): 物理インポート モードでのみ使用できる競合処理構成 -- `lightning.task-info-schema-name` : TiDB Lightningが競合を検出したときに競合するデータが格納されるデータベース +- `lightning.max-error` : 型エラーの許容閾値 +- `conflict.strategy` : 競合`conflict.max-record-rows` `conflict.threshold`に関連する構成 +- `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)を参照してください。 @@ -29,19 +29,19 @@ max-error = 0 上記の構成では、次のエラーがカバーされます。 -- 無効な値 (例: INT 列に`'Text'`を設定する)。 -- 数値オーバーフロー（例：TINYINT列に`500`を設定する） -- 文字列オーバーフロー（例：VARCHAR(5)列に`'Very Long Text'`を設定する）。 -- 日付と時刻がゼロ (つまり`'0000-00-00'`と`'2021-12-00'` )。 -- NOT NULL 列に NULL を設定します。 -- 生成列式の評価に失敗しました。 -- カラム数が一致しません。行内の値の数がテーブルの列数と一致しません。 -- その他の SQL エラー。 +- 無効な値 (例: INT 列に`'Text'`を設定する)。 +- 数値オーバーフロー（例：TINYINT列に`500`を設定する） +- 文字列オーバーフロー（例：VARCHAR(5)列に`'Very Long Text'`を設定する）。 +- 日付と時刻がゼロ (つまり`'0000-00-00'`と`'2021-12-00'` )。 +- NOT NULL 列に NULL を設定します。 +- 生成列式の評価に失敗しました。 +- カラム数が一致しません。行内の値の数がテーブルの列数と一致しません。 +- その他の SQL エラー。 以下のエラーは常に致命的であり、 `lightning.max-error`を変更してもスキップすることはできません。 -- 元の CSV、SQL、または Parquet ファイルの構文エラー (閉じられていない引用符など)。 -- I/O、ネットワーク、またはシステムの権限エラー。 +- 元の CSV、SQL、または Parquet ファイルの構文エラー (閉じられていない引用符など)。 +- I/O、ネットワーク、またはシステムの権限エラー。 ## 競合エラー {#conflict-errors} @@ -53,13 +53,13 @@ max-error = 0 TiDB Lightning がインポート中にエラーに遭遇した場合、終了時にターミナルとログ ファイルの両方にこれらのエラーに関する統計の概要が出力されます。 -- ターミナルのエラーレポートは次の表のようになります。 +- ターミナルのエラーレポートは次の表のようになります。 | | エラーの種類 | エラー数 | エラーデータテーブル | | - | ------ | ---- | ------------------------------------- | | 1 | データ型 | 1000 | `lightning_task_info` `type_error_v1` | -- TiDB Lightningログ ファイル内のエラー レポートは次のとおりです。 +- TiDB Lightningログ ファイル内のエラー レポートは次のとおりです。 ```shell [2022/03/13 05:33:57.736 +08:00] [WARN] [errormanager.go:459] ["Detect 1000 data type errors in total, please refer to table `lightning_task_info`.`type_error_v1` for more details"] @@ -151,25 +151,25 @@ CREATE VIEW conflict_view AS > > エラーレポートにはファイルオフセットが記録されますが、行番号や列番号を取得するのは非効率的です。以下のコマンドを使用すると、バイト位置（例えば183）の近くまで素早くジャンプできます。 > -> - シェル、最初の数行を出力します。 +> - シェル、最初の数行を出力します。 > > ```shell > head -c 183 file.csv | tail > ``` > -> - シェルは、次の数行を出力します。 +> - シェルは、次の数行を出力します。 > > ```shell > tail -c +183 file.csv | head > ``` > -> - vim — `:goto 183`または`183go` +> - vim — `:goto 183`または`183go` ## 例 {#example} この例では、いくつかの既知のエラーを含むデータ ソースが準備されます。 -1. データベースとテーブル スキーマを準備します。 +1. データベースとテーブル スキーマを準備します。 ```shell mkdir example && cd example @@ -178,7 +178,7 @@ CREATE VIEW conflict_view AS echo 'CREATE TABLE t(a TINYINT PRIMARY KEY, b VARCHAR(12) NOT NULL UNIQUE);' > example.t-schema.sql ``` -2. データを準備します。 +2. データを準備します。 ```shell cat < example.t.1.sql @@ -197,7 +197,7 @@ CREATE VIEW conflict_view AS EOF ``` -3. TiDB Lightningを構成して厳密な SQL モードを有効にし、ローカル バックエンドを使用してデータをインポートし、重複を置き換え、最大 10 個のエラーをスキップします。 +3. TiDB Lightningを構成して厳密な SQL モードを有効にし、ローカル バックエンドを使用してデータをインポートし、重複を置き換え、最大 10 個のエラーをスキップします。 ```shell cat < config.toml @@ -223,13 +223,13 @@ CREATE VIEW conflict_view AS EOF ``` -4. TiDB Lightningを実行します。すべてのエラーがスキップされるため、このコマンドは正常に終了します。 +4. TiDB Lightningを実行します。すべてのエラーがスキップされるため、このコマンドは正常に終了します。 ```shell tiup tidb-lightning -c config.toml ``` -5. インポートされたテーブルに次の 2 つの通常の行のみが含まれていることを確認します。 +5. インポートされたテーブルに次の 2 つの通常の行のみが含まれていることを確認します。 ```sql $ mysql -u root -h 127.0.0.1 -P 4000 -e 'select * from example.t' @@ -241,7 +241,7 @@ CREATE VIEW conflict_view AS +---+-----+ ``` -6. `type_error_v1`テーブルに型変換を含む 3 つの行が含まれているかどうかを確認します。 +6. `type_error_v1`テーブルに型変換を含む 3 つの行が含まれているかどうかを確認します。 ```sql $ mysql -u root -h 127.0.0.1 -P 4000 -e 'select * from lightning_task_info.type_error_v1;' -E @@ -274,7 +274,7 @@ CREATE VIEW conflict_view AS row_data: (600,'six hundred') ``` -7. `conflict_error_v3`テーブルに、一意/主キーの競合がある 4 つの行が含まれているかどうかを確認します。 +7. `conflict_error_v3`テーブルに、一意/主キーの競合がある 4 つの行が含まれているかどうかを確認します。 ```sql $ mysql -u root -h 127.0.0.1 -P 4000 -e 'select * from lightning_task_info.conflict_error_v3;' --binary-as-hex -E diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md index 3bff847040fa0..7cd9a6201951c 100644 --- a/tidb-lightning/tidb-lightning-faq.md +++ b/tidb-lightning/tidb-lightning-faq.md @@ -25,8 +25,8 @@ TiDB Lightningのバージョンはクラスターと同じである必要があ ## TiDB Lightningを適切に再起動するにはどうすればよいですか? {#how-to-properly-restart-tidb-lightning} -1. [`tidb-lightning`プロセスを停止する](#how-to-stop-the-tidb-lightning-process) 。 -2. 新しい`tidb-lightning`タスクを開始します。以前の開始コマンド（例: `nohup tiup tidb-lightning -config tidb-lightning.toml`）を実行します。 +1. [`tidb-lightning`プロセスを停止する](#how-to-stop-the-tidb-lightning-process) 。 +2. 新しい`tidb-lightning`タスクを開始します。以前の開始コマンド（例: `nohup tiup tidb-lightning -config tidb-lightning.toml`）を実行します。 ## インポートされたデータの整合性を確保するにはどうすればよいですか? {#how-to-ensure-the-integrity-of-the-imported-data} @@ -51,8 +51,8 @@ ADMIN CHECKSUM TABLE `schema`.`table`; TiDB Lightning は以下をサポートします: -- [Dumpling](/dumpling-overview.md) 、CSV ファイル、および[Amazon Auroraによって生成された Apache Parquet ファイル](/migrate-aurora-to-tidb.md) 、Apache Hive、Snowflake によってエクスポートされたファイルをインポートします。 -- ローカルディスクまたは Amazon S3ストレージからデータを読み取ります。 +- [Dumpling](/dumpling-overview.md) 、CSV ファイル、および[Amazon Auroraによって生成された Apache Parquet ファイル](/migrate-aurora-to-tidb.md) 、Apache Hive、Snowflake によってエクスポートされたファイルをインポートします。 +- ローカルディスクまたは Amazon S3ストレージからデータを読み取ります。 ## TiDB Lightning はスキーマとテーブルの作成をスキップできますか? {#could-tidb-lightning-skip-creating-schema-and-tables} @@ -77,7 +77,7 @@ sql-mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION" `tidb-lightning`プロセスを停止するには、展開方法に応じて対応する操作を選択できます。 -- 手動デプロイの場合： `tidb-lightning`フォアグラウンドで実行されている場合は、 Ctrl + Cを押して終了します。それ以外の場合は、 `ps aux | grep tidb-lightning`コマンドを使用してプロセス ID を取得し、 `kill -2 ${PID}`コマンドを使用してプロセスを終了します。 +- 手動デプロイの場合： `tidb-lightning`フォアグラウンドで実行されている場合は、 Ctrl + Cを押して終了します。それ以外の場合は、 `ps aux | grep tidb-lightning`コマンドを使用してプロセス ID を取得し、 `kill -2 ${PID}`コマンドを使用してプロセスを終了します。 ## TiDB Lightning は1 ギガビット ネットワーク カードで使用できますか? {#can-tidb-lightning-be-used-with-1-gigabit-network-card} @@ -89,12 +89,12 @@ TiDB Lightning は、10 ギガビット ネットワーク カードで使用す デフォルト設定のレプリカ数3の場合、ターゲットTiKVクラスターに必要な容量はデータソースの6倍になります。「2」という倍数は、以下の要素がデータソースに反映されていないため、控えめな見積もりです。 -- インデックスが占めるスペース -- RocksDBにおける空間増幅 +- インデックスが占めるスペース +- RocksDBにおける空間増幅 ## TiDB Lightningに関連付けられたすべての中間データを完全に破棄するにはどうすればよいですか? {#how-to-completely-destroy-all-intermediate-data-associated-with-tidb-lightning} -1. チェックポイント ファイルを削除します。 +1. チェックポイント ファイルを削除します。 ```sh tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-remove=all @@ -102,14 +102,14 @@ TiDB Lightning は、10 ギガビット ネットワーク カードで使用す 何らかの理由でこのコマンドを実行できない場合は、ファイル`/tmp/tidb_lightning_checkpoint.pb`を手動で削除してみてください。 -2. Local-backend を使用している場合は、構成内の`sorted-kv-dir`ディレクトリを削除します。 +2. Local-backend を使用している場合は、構成内の`sorted-kv-dir`ディレクトリを削除します。 -3. 必要に応じて、TiDB クラスター上に作成されたすべてのテーブルとデータベースを削除します。 +3. 必要に応じて、TiDB クラスター上に作成されたすべてのテーブルとデータベースを削除します。 -4. 残留メタデータをクリーンアップします。以下のいずれかの条件に該当する場合は、メタデータスキーマを手動でクリーンアップする必要があります。 +4. 残留メタデータをクリーンアップします。以下のいずれかの条件に該当する場合は、メタデータスキーマを手動でクリーンアップする必要があります。 - - TiDB Lightning v5.1.xおよびv5.2.xバージョンの場合、 `tidb-lightning-ctl`コマンドではターゲットクラスタ内のメタデータスキーマがクリーンアップされません。手動でクリーンアップする必要があります。 - - チェックポイント ファイルを手動で削除した場合は、ダウンストリーム メタデータ スキーマを手動でクリーンアップする必要があります。そうしないと、後続のインポートの正確性が影響を受ける可能性があります。 + - TiDB Lightning v5.1.xおよびv5.2.xバージョンの場合、 `tidb-lightning-ctl`コマンドではターゲットクラスタ内のメタデータスキーマがクリーンアップされません。手動でクリーンアップする必要があります。 + - チェックポイント ファイルを手動で削除した場合は、ダウンストリーム メタデータ スキーマを手動でクリーンアップする必要があります。そうしないと、後続のインポートの正確性が影響を受ける可能性があります。 メタデータをクリーンアップするには、次のコマンドを使用します。 @@ -119,7 +119,7 @@ TiDB Lightning は、10 ギガビット ネットワーク カードで使用す ## TiDB Lightningのランタイムgoroutine情報を取得する方法 {#how-to-get-the-runtime-goroutine-information-of-tidb-lightning} -1. TiDB Lightningの設定ファイルで[`status-port`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-configuration)が指定されている場合は、この手順をスキップしてください。それ以外の場合は、 `status-port`を有効にするためにTiDB Lightningに USR1 信号を送信する必要があります。 +1. TiDB Lightningの設定ファイルで[`status-port`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-configuration)が指定されている場合は、この手順をスキップしてください。それ以外の場合は、 `status-port`を有効にするためにTiDB Lightningに USR1 信号を送信する必要があります。 `ps`などのコマンドを使用してTiDB Lightningのプロセス ID (PID) を取得し、次のコマンドを実行します。 @@ -129,7 +129,7 @@ TiDB Lightning は、10 ギガビット ネットワーク カードで使用す TiDB Lightningのログを確認します。`starting HTTP server` / `start HTTP server` / `started HTTP server`のログに、新たに有効化された`status-port`が表示されます。 -2. `http://:/debug/pprof/goroutine?debug=2`アクセスして、goroutine 情報を取得します。 +2. `http://:/debug/pprof/goroutine?debug=2`アクセスして、goroutine 情報を取得します。 ## TiDB Lightning がSQL の配置ルールと互換性がないのはなぜですか? {#why-is-tidb-lightning-not-compatible-with-placement-rules-in-sql} @@ -163,22 +163,22 @@ TiDB LightningでSQLの配置ルールを使用するには、データをター 手順は次のとおりです。 -1. データ分散トポロジを計画します。 -2. TiKV および PD に必要なラベルを構成します。 -3. 配置ルール ポリシーを作成し、作成したポリシーをターゲット テーブルに適用します。 -4. TiDB Lightningを使用して、データをターゲット テーブルにインポートします。 +1. データ分散トポロジを計画します。 +2. TiKV および PD に必要なラベルを構成します。 +3. 配置ルール ポリシーを作成し、作成したポリシーをターゲット テーブルに適用します。 +4. TiDB Lightningを使用して、データをターゲット テーブルにインポートします。 ## TiDB LightningとDumplingを使用してスキーマをコピーするにはどうすればよいですか? {#how-can-i-use-tidb-lightning-and-dumpling-to-copy-a-schema} あるスキーマから新しいスキーマにスキーマ定義とテーブルデータの両方をコピーしたい場合は、このセクションの手順に従ってください。この例では、スキーマ`test`のコピーを`test2`という新しいスキーマに作成する方法を説明します。 -1. 必要なスキーマのみを選択するには、 `-B test`を使用して元のスキーマのバックアップを作成します。 +1. 必要なスキーマのみを選択するには、 `-B test`を使用して元のスキーマのバックアップを作成します。 ``` tiup dumpling -B test -o /tmp/bck1 ``` -2. 次の内容のファイルを`/tmp/tidb-lightning.toml`に作成します。 +2. 次の内容のファイルを`/tmp/tidb-lightning.toml`に作成します。 ```toml [tidb] @@ -207,7 +207,7 @@ TiDB LightningでSQLの配置ルールを使用するには、データをター この設定ファイルでは、元のダンプで使用されたスキーマ名とは異なるスキーマ名を使用するため、 `schema = 'test2'`を設定します。ファイル名はテーブル名を決定するために使用されます。 -3. この構成ファイルを使用してインポートを実行します。 +3. この構成ファイルを使用してインポートを実行します。 ``` tiup tidb-lightning -config /tmp/tidb-lightning.toml diff --git a/tidb-lightning/tidb-lightning-glossary.md b/tidb-lightning/tidb-lightning-glossary.md index 73f3b6603a734..938499d6c5f0b 100644 --- a/tidb-lightning/tidb-lightning-glossary.md +++ b/tidb-lightning/tidb-lightning-glossary.md @@ -47,9 +47,9 @@ TiDB Lightningは、インポート中に進行状況をローカルファイル TiDB Lightningでは、テーブルのチェックサムは、そのテーブル内の各KVペアの内容から計算される3つの数値のセットです。これらの数値はそれぞれ以下のとおりです。 -- KVペアの数、 -- すべてのKVペアの合計長さ、および -- 各ペアの[CRC-64-ECMA](https://en.wikipedia.org/wiki/Cyclic_redundancy_check)値のビット単位の XOR です。 +- KVペアの数、 +- すべてのKVペアの合計長さ、および +- 各ペアの[CRC-64-ECMA](https://en.wikipedia.org/wiki/Cyclic_redundancy_check)値のビット単位の XOR です。 TiDB Lightning [インポートされたデータを検証する](/tidb-lightning/tidb-lightning-faq.md#how-to-ensure-the-integrity-of-the-imported-data) 、各テーブルの[ローカル](/tidb-lightning/tidb-lightning-glossary.md#local-checksum)と[リモートチェックサム](/tidb-lightning/tidb-lightning-glossary.md#remote-checksum)を比較することで、このチェックを実行します。いずれのペアも一致しない場合、プログラムは停止します。このチェックは、 `post-restore.checksum`設定を`false`に設定することでスキップできます。 diff --git a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md index a5bed8633e131..7cccf2e40328b 100644 --- a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md @@ -62,9 +62,9 @@ log-level = "error" ## パフォーマンスチューニング {#performance-tuning} -- 論理インポート モードでは、 TiDB Lightningのパフォーマンスはターゲット TiDB クラスターの書き込みパフォーマンスに大きく依存します。クラスターがパフォーマンスのボトルネックに達した場合は、 [高並行書き込みのベストプラクティス](/best-practices/high-concurrency-best-practices.md)を参照してください。 +- 論理インポート モードでは、 TiDB Lightningのパフォーマンスはターゲット TiDB クラスターの書き込みパフォーマンスに大きく依存します。クラスターがパフォーマンスのボトルネックに達した場合は、 [高並行書き込みのベストプラクティス](/best-practices/high-concurrency-best-practices.md)を参照してください。 -- 対象の TiDB クラスタで書き込みボトルネックが発生しない場合は、 TiDB Lightning構成の`region-concurrency`の値を増やすことを検討してください。 `region-concurrency`のデフォルト値は CPU コア数です。 `region-concurrency`の意味は、物理インポート モードと論理インポート モードで異なります。論理インポート モードでは、 `region-concurrency`は書き込み同時実行数です。 +- 対象の TiDB クラスタで書き込みボトルネックが発生しない場合は、 TiDB Lightning構成の`region-concurrency`の値を増やすことを検討してください。 `region-concurrency`のデフォルト値は CPU コア数です。 `region-concurrency`の意味は、物理インポート モードと論理インポート モードで異なります。論理インポート モードでは、 `region-concurrency`は書き込み同時実行数です。 設定例： @@ -73,4 +73,4 @@ log-level = "error" region-concurrency = 32 ``` -- 対象の TiDB クラスターで`raftstore.apply-pool-size`および`raftstore.store-pool-size`の設定項目を調整すると、インポート速度が向上する可能性があります。 +- 対象の TiDB クラスターで`raftstore.apply-pool-size`および`raftstore.store-pool-size`の設定項目を調整すると、インポート速度が向上する可能性があります。 diff --git a/tidb-lightning/tidb-lightning-overview.md b/tidb-lightning/tidb-lightning-overview.md index 3207cb81fa6cc..7c35d34f3216b 100644 --- a/tidb-lightning/tidb-lightning-overview.md +++ b/tidb-lightning/tidb-lightning-overview.md @@ -9,15 +9,15 @@ summary: Lightning とアーキテクチャ全体について学びます。 TiDB Lightning は次のファイル形式をサポートしています。 -- [Dumpling](/dumpling-overview.md)によってエクスポートされたファイル -- CSVファイル -- [Amazon Auroraによって生成された Apache Parquet ファイル](/migrate-aurora-to-tidb.md) 、Apache Hive、またはSnowflake +- [Dumpling](/dumpling-overview.md)によってエクスポートされたファイル +- CSVファイル +- [Amazon Auroraによって生成された Apache Parquet ファイル](/migrate-aurora-to-tidb.md) 、Apache Hive、またはSnowflake TiDB Lightning は次のソースからデータを読み取ることができます。 -- ローカル -- [Amazon S3](/external-storage-uri.md#amazon-s3-uri-format) -- [Google Cloud Storage](/external-storage-uri.md#gcs-uri-format) +- ローカル +- [Amazon S3](/external-storage-uri.md#amazon-s3-uri-format) +- [Google Cloud Storage](/external-storage-uri.md#gcs-uri-format) > **Note:** > @@ -29,9 +29,9 @@ TiDB Lightning は次のソースからデータを読み取ることができ TiDB Lightning は、 `backend`で設定された 2 つのインポート モードをサポートしています。インポート モードによって、TiDB へのデータのインポート方法が決まります。 -- [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md) : TiDB Lightningは、まずデータをキーと値のペアにエンコードし、ローカルの一時ディレクトリに保存します。次に、これらのキーと値のペアを各TiKVノードにアップロードし、最後にTiKV 取り込みインターフェースを呼び出してTiKVのRocksDBにデータを挿入します。初期インポートを実行する必要がある場合は、インポート速度が速い物理インポートモードを検討してください。物理インポートモードのバックエンドは`local`です。 +- [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md) : TiDB Lightningは、まずデータをキーと値のペアにエンコードし、ローカルの一時ディレクトリに保存します。次に、これらのキーと値のペアを各TiKVノードにアップロードし、最後にTiKV 取り込みインターフェースを呼び出してTiKVのRocksDBにデータを挿入します。初期インポートを実行する必要がある場合は、インポート速度が速い物理インポートモードを検討してください。物理インポートモードのバックエンドは`local`です。 -- [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md) : TiDB Lightning はまずデータをSQL文にエンコードし、その後、これらのSQL文を直接実行してデータをインポートします。インポート対象のクラスターが本番の場合、またはインポート対象のテーブルに既にデータが含まれている場合は、論理インポートモードを使用してください。論理インポートモードのバックエンドは`tidb`です。 +- [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md) : TiDB Lightning はまずデータをSQL文にエンコードし、その後、これらのSQL文を直接実行してデータをインポートします。インポート対象のクラスターが本番の場合、またはインポート対象のテーブルに既にデータが含まれている場合は、論理インポートモードを使用してください。論理インポートモードのバックエンドは`tidb`です。 | インポートモード | 物理インポートモード | 論理インポートモード | | :----------------------------- | :--------------------------------------------------------------------------- | :-------------- | diff --git a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md index 154bbdaee5413..4357e5ba59d6f 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md @@ -107,8 +107,8 @@ analyze = "optional" 競合検出には2つのバージョンがあります。 -- `conflict`設定項目によって制御される、新しいバージョンの競合検出。 -- `tikv-importer.duplicate-resolution`設定項目によって制御される、競合検出の旧バージョン（v8.0.0 で非推奨となり、将来のリリースで削除されます）。 +- `conflict`設定項目によって制御される、新しいバージョンの競合検出。 +- `tikv-importer.duplicate-resolution`設定項目によって制御される、競合検出の旧バージョン（v8.0.0 で非推奨となり、将来のリリースで削除されます）。 ### 衝突検出の新しいバージョン {#the-new-version-of-conflict-detection} @@ -128,8 +128,8 @@ analyze = "optional" 新しいバージョンの競合検出機能には、以下の制限事項があります。 -- TiDB Lightning はインポート前に、すべてのデータを読み込んでエンコードすることで、競合する可能性のあるデータを事前チェックします。検出処理中、 TiDB Lightningは`tikv-importer.sorted-kv-dir`を使用して一時ファイルを保存します。検出が完了すると、 TiDB Lightning はインポートフェーズのために結果を保持します。これにより、処理時間、ディスク容量、およびデータ読み取りのための API リクエストに余分なオーバーヘッドが発生します。 -- 新しいバージョンの競合検出は単一ノードでのみ機能し、並列インポートや`disk-quota`パラメーターが有効になっているシナリオには適用されません。 +- TiDB Lightning はインポート前に、すべてのデータを読み込んでエンコードすることで、競合する可能性のあるデータを事前チェックします。検出処理中、 TiDB Lightningは`tikv-importer.sorted-kv-dir`を使用して一時ファイルを保存します。検出が完了すると、 TiDB Lightning はインポートフェーズのために結果を保持します。これにより、処理時間、ディスク容量、およびデータ読み取りのための API リクエストに余分なオーバーヘッドが発生します。 +- 新しいバージョンの競合検出は単一ノードでのみ機能し、並列インポートや`disk-quota`パラメーターが有効になっているシナリオには適用されません。 新しいバージョンの競合検出では`precheck-conflict-before-import`パラメータを使用して、インポート前の競合検出を有効にするかどうかを制御します。元のデータに競合データが多く含まれている場合、インポート前後の競合検出にかかる合計時間は、旧バージョンよりも短くなります。そのため、競合レコードの割合が 1% 以上で、ローカルディスクの空き容量が十分な場合は、インポート前の競合検出を有効にすることをお勧めします。 @@ -137,13 +137,13 @@ analyze = "optional" バージョン 8.0.0 以降、競合検出の旧バージョン ( `tikv-importer.duplicate-resolution` ) は非推奨となります。 `tikv-importer.duplicate-resolution`パラメータは今後のリリースで削除されます。 `tikv-importer.duplicate-resolution`が`remove`であり、 `conflict.strategy`が設定されていない場合、 TiDB Lightning は`conflict.strategy`の値`"replace"` 。 `tikv-importer.duplicate-resolution`と`conflict.strategy`は同時に設定できません。同時に設定するとエラーが発生しますのでご注意ください。 -- バージョン v7.3.0 から v7.6.0 の間では、 `tikv-importer.duplicate-resolution`空文字列でない場合、 TiDB Lightning は古いバージョンの競合検出を有効にします。 -- TiDB Lightningは、v7.2.0以前のバージョンでは、古いバージョンの競合検出のみをサポートしています。 +- バージョン v7.3.0 から v7.6.0 の間では、 `tikv-importer.duplicate-resolution`空文字列でない場合、 TiDB Lightning は古いバージョンの競合検出を有効にします。 +- TiDB Lightningは、v7.2.0以前のバージョンでは、古いバージョンの競合検出のみをサポートしています。 旧バージョンの競合検出では、 TiDB Lightningは2つの戦略を提供していました。 -- `remove` (推奨): ターゲット TiDB の一貫した状態を確保するために、ターゲット テーブルから競合するすべてのレコードを記録して削除します。 -- `none` : 重複レコードを検出しません。 `none` 2 つの戦略の中で最も優れたパフォーマンスを発揮しますが、ターゲット TiDB のデータに不整合が生じる可能性があります。 +- `remove` (推奨): ターゲット TiDB の一貫した状態を確保するために、ターゲット テーブルから競合するすべてのレコードを記録して削除します。 +- `none` : 重複レコードを検出しません。 `none` 2 つの戦略の中で最も優れたパフォーマンスを発揮しますが、ターゲット TiDB のデータに不整合が生じる可能性があります。 バージョン5.3より前のTiDB Lightningは、競合検出をサポートしていません。競合データが存在する場合、インポート処理はチェックサムの段階で失敗します。競合検出が有効になっている場合、競合データが存在すると、 TiDB Lightningはチェックサムの段階をスキップします（常に失敗するため）。 @@ -226,8 +226,8 @@ TPCCを使用してオンラインアプリケーションをシミュレート 前述の表のパーセンテージは、データインポートがTPCCの結果に与える影響を示しています。 -- TPMの列の数値は、TPMの減少率（パーセント）を示しています。 -- P99、P90、およびAVG列の数値は、レイテンシーの増加率を示しています。 +- TPMの列の数値は、TPMの減少率（パーセント）を示しています。 +- P99、P90、およびAVG列の数値は、レイテンシーの増加率を示しています。 テスト結果によると、同時実行数が少ないほど、データインポートがTPCCの結果に与える影響は大きくなる。同時実行数が64以上の場合、データインポートがTPCCの結果に与える影響はごくわずかである。 @@ -237,8 +237,8 @@ TPCCを使用してオンラインアプリケーションをシミュレート **物理インポートモードのインポートパフォーマンスを向上させるための最も直接的かつ効果的な方法は以下のとおりです。** -- **Lightningがデプロイされているノードのハードウェア、特にCPUと`sorted-key-dir`のストレージデバイスをアップグレードしてください。** -- **並列インポート機能を使用して、水平方向のスケーリングを実現します。** +- **Lightningがデプロイされているノードのハードウェア、特にCPUと`sorted-key-dir`のストレージデバイスをアップグレードしてください。** +- **並列インポート機能を使用して、水平方向のスケーリングを実現します。** TiDB Lightningは、物理インポートモードでのインポートパフォーマンスに影響を与える同時実行性関連の設定項目をいくつか提供しています。しかし、長年の経験から、以下の4つの設定項目はデフォルト値のままにしておくことをお勧めします。これらの設定項目を調整しても、パフォーマンスが大幅に向上することはありません。 diff --git a/tidb-lightning/tidb-lightning-physical-import-mode.md b/tidb-lightning/tidb-lightning-physical-import-mode.md index d92ac86db023c..e6061926af624 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode.md @@ -19,31 +19,31 @@ backend = "local" ## 実装 {#implementation} -1. TiDB Lightningは、データをインポートする前に、TiKVノードを自動的に「インポートモード」に切り替えます。これにより、書き込みパフォーマンスが向上し、自動コンパクションが停止します。TiDB Lightningは、 TiDB Lightningのバージョンに応じて、グローバルスケジューリングを一時停止するかどうかを決定します。 +1. TiDB Lightningは、データをインポートする前に、TiKVノードを自動的に「インポートモード」に切り替えます。これにより、書き込みパフォーマンスが向上し、自動コンパクションが停止します。TiDB Lightningは、 TiDB Lightningのバージョンに応じて、グローバルスケジューリングを一時停止するかどうかを決定します。 - - v7.1.0 以降では、 TiDB Lightningパラメータ[`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md)を使用して、一時停止スケジュールの範囲を制御できます。 - - TiDB Lightningバージョン v6.2.0 から v7.0.0 の場合、グローバルスケジューリングの一時停止の動作は TiDB クラスタのバージョンによって異なります。TiDB クラスタが v6.1.0 以上の場合、 TiDB Lightning はターゲットテーブルデータが格納されているリージョンのスケジューリングを一時停止します。インポートが完了すると、 TiDB Lightning はスケジューリングを回復します。その他のバージョンの場合、 TiDB Lightning はグローバルスケジューリングを一時停止します。 - - TiDB Lightning < v6.2.0 の場合、 TiDB Lightning はグローバル スケジューリングを一時停止します。 + - v7.1.0 以降では、 TiDB Lightningパラメータ[`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md)を使用して、一時停止スケジュールの範囲を制御できます。 + - TiDB Lightningバージョン v6.2.0 から v7.0.0 の場合、グローバルスケジューリングの一時停止の動作は TiDB クラスタのバージョンによって異なります。TiDB クラスタが v6.1.0 以上の場合、 TiDB Lightning はターゲットテーブルデータが格納されているリージョンのスケジューリングを一時停止します。インポートが完了すると、 TiDB Lightning はスケジューリングを回復します。その他のバージョンの場合、 TiDB Lightning はグローバルスケジューリングを一時停止します。 + - TiDB Lightning < v6.2.0 の場合、 TiDB Lightning はグローバル スケジューリングを一時停止します。 -2. TiDB Lightning は、ターゲット データベースにテーブル スキーマを作成し、メタデータを取得します。 +2. TiDB Lightning は、ターゲット データベースにテーブル スキーマを作成し、メタデータを取得します。 `add-index-by-sql`を`true`に設定した場合、 `tidb-lightning`はSQLインターフェース経由でインデックスを追加し、データをインポートする前にターゲットテーブルからすべてのセカンダリインデックスを削除します。デフォルト値は`false`で、以前のバージョンと一致しています。 -3. 各テーブルは複数の連続した**ブロック**に分割されるため、 TiDB Lightning は大規模なテーブル (200 GB 以上) からデータを並列にインポートできます。 +3. 各テーブルは複数の連続した**ブロック**に分割されるため、 TiDB Lightning は大規模なテーブル (200 GB 以上) からデータを並列にインポートできます。 -4. TiDB Lightningは、キーと値のペアを処理するために、各ブロックごとに「エンジンファイル」を用意します。TiDB LightningはSQLダンプを並列に読み取り、データソースをTiDBと同じエンコーディングでキーと値のペアに変換し、キーと値のペアをソートしてローカルの一時ストレージファイルに書き込みます。 +4. TiDB Lightningは、キーと値のペアを処理するために、各ブロックごとに「エンジンファイル」を用意します。TiDB LightningはSQLダンプを並列に読み取り、データソースをTiDBと同じエンコーディングでキーと値のペアに変換し、キーと値のペアをソートしてローカルの一時ストレージファイルに書き込みます。 -5. エンジン ファイルが書き込まれると、 TiDB Lightning はターゲット TiKV クラスター上のデータの分割とスケジュールを開始し、その後、データを TiKV クラスターにインポートします。 +5. エンジン ファイルが書き込まれると、 TiDB Lightning はターゲット TiKV クラスター上のデータの分割とスケジュールを開始し、その後、データを TiKV クラスターにインポートします。 エンジンファイルには、**データエンジン**と**インデックスエンジン**という2種類のエンジンが含まれています。各エンジンは、キーと値のペアの種類（行データとセカンダリインデックス）に対応しています。通常、行データはデータソース内で完全に順序付けされており、セカンダリインデックスは順序付けされていません。そのため、データエンジンファイルは対応するブロックが書き込まれた直後にインポートされ、すべてのインデックスエンジンファイルはテーブル全体がエンコードされた後にのみインポートされます。 `tidb-lightning` SQL インターフェイス経由でインデックスを追加する場合 (つまり、 `add-index-by-sql`を`true`に設定する場合)、ターゲット テーブルのセカンダリ インデックスは手順 2 で既に削除されているため、インデックス エンジンはデータを書き込まないことに注意してください。 -6. すべてのエンジンファイルがインポートされた後、 TiDB Lightningはローカルデータソースと下流クラスターのチェックサムを比較し、インポートされたデータが破損していないことを確認します。その後、 TiDB Lightningはステップ2で削除したセカンダリインデックスを追加するか、TiDBに新しいデータを分析させて（ `ANALYZE` ）、将来の操作を最適化します。一方、 `tidb-lightning`は将来の競合を防ぐために`AUTO_INCREMENT`値を調整します。 +6. すべてのエンジンファイルがインポートされた後、 TiDB Lightningはローカルデータソースと下流クラスターのチェックサムを比較し、インポートされたデータが破損していないことを確認します。その後、 TiDB Lightningはステップ2で削除したセカンダリインデックスを追加するか、TiDBに新しいデータを分析させて（ `ANALYZE` ）、将来の操作を最適化します。一方、 `tidb-lightning`は将来の競合を防ぐために`AUTO_INCREMENT`値を調整します。 AUTO_INCREMENT IDは行数の**上限**に基づいて推定され、テーブルデータファイルの合計サイズに比例します。そのため、AUTO_INCREMENT IDは通常、実際の行数よりも大きくなります。これは、AUTO_INCREMENT IDが[必ずしも連続しているわけではない](/mysql-compatibility.md#auto-increment-id)ため、正常な動作です。 -7. すべての手順が完了すると、 TiDB Lightningは自動的にTiKVノードを「通常モード」に切り替えます。グローバルスケジューリングが一時停止されている場合、 TiDB Lightningはグローバルスケジューリングも回復します。その後、TiDBクラスタは通常通りサービスを提供できるようになります。 +7. すべての手順が完了すると、 TiDB Lightningは自動的にTiKVノードを「通常モード」に切り替えます。グローバルスケジューリングが一時停止されている場合、 TiDB Lightningはグローバルスケジューリングも回復します。その後、TiDBクラスタは通常通りサービスを提供できるようになります。 ## 要件と制限 {#requirements-and-restrictions} @@ -67,32 +67,32 @@ CentOS 7の新規インスタンスの使用をお勧めします。仮想マシ ### バージョン要件 {#version-requirements} -- TiDB Lightning >= v4.0.3。 -- TiDB >= v4.0.0。 +- TiDB Lightning >= v4.0.3。 +- TiDB >= v4.0.0。 ### 制限事項 {#limitations} -- 本番のTiDBクラスタにデータを直接インポートする際に、物理インポートモードを使用しないでください。パフォーマンスに重大な影響を及ぼします。必要な場合は、 [テーブルレベルでスケジュールを一時停止する](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#scope-of-pausing-scheduling-during-import)を参照してください。 -- TiDBクラスタにレイテンシの影響を受けやすいアプリケーションがあり、同時実行性が低い場合は、物理インポートモードを使用してクラスタにデータをインポート**しない**ことを強くお勧めします。このモードは、オンラインアプリケーションに重大な影響を与える可能性があります。 -- 複数のTiDB Lightningインスタンスを同時に実行して同じTiDBクラスタにデータをインポートする場合は、 [並列インポート](/tidb-lightning/tidb-lightning-distributed-import.md)を有効にしてインポートを調整できます。各インスタンスが**異なるテーブル**にデータをインポートする場合は、並列インポートオプションは必要ありません。ただし、複数のインスタンスが**同じテーブル**にデータをインポートする場合は、競合を防ぎ、データの整合性を確保するために、並列インポートを有効にする必要があります。 -- 複数のTiDB Lightningを使用して同じターゲットクラスタにデータをインポートする場合、インポートモードを混在させないでください。つまり、物理インポートモードと論理インポートモードを同時に使用しないでください。 -- データのインポート中は、ターゲットテーブルでDDLおよびDML操作を実行しないでください。そうしないと、インポートが失敗したり、データの不整合が生じたりする可能性があります。また、読み取り操作は、読み取ったデータに不整合が生じる可能性があるため、実行しないことをお勧めします。インポート操作が完了したら、読み取りおよび書き込み操作を実行できます。 -- 1 つの Lightning プロセスでインポートできるのは、最大 10 TiB のテーブル 1 つだけです。並列インポートでは、最大 10 個の Lightning インスタンスを使用できます。 +- 本番のTiDBクラスタにデータを直接インポートする際に、物理インポートモードを使用しないでください。パフォーマンスに重大な影響を及ぼします。必要な場合は、 [テーブルレベルでスケジュールを一時停止する](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#scope-of-pausing-scheduling-during-import)を参照してください。 +- TiDBクラスタにレイテンシの影響を受けやすいアプリケーションがあり、同時実行性が低い場合は、物理インポートモードを使用してクラスタにデータをインポート**しない**ことを強くお勧めします。このモードは、オンラインアプリケーションに重大な影響を与える可能性があります。 +- 複数のTiDB Lightningインスタンスを同時に実行して同じTiDBクラスタにデータをインポートする場合は、 [並列インポート](/tidb-lightning/tidb-lightning-distributed-import.md)を有効にしてインポートを調整できます。各インスタンスが**異なるテーブル**にデータをインポートする場合は、並列インポートオプションは必要ありません。ただし、複数のインスタンスが**同じテーブル**にデータをインポートする場合は、競合を防ぎ、データの整合性を確保するために、並列インポートを有効にする必要があります。 +- 複数のTiDB Lightningを使用して同じターゲットクラスタにデータをインポートする場合、インポートモードを混在させないでください。つまり、物理インポートモードと論理インポートモードを同時に使用しないでください。 +- データのインポート中は、ターゲットテーブルでDDLおよびDML操作を実行しないでください。そうしないと、インポートが失敗したり、データの不整合が生じたりする可能性があります。また、読み取り操作は、読み取ったデータに不整合が生じる可能性があるため、実行しないことをお勧めします。インポート操作が完了したら、読み取りおよび書き込み操作を実行できます。 +- 1 つの Lightning プロセスでインポートできるのは、最大 10 TiB のテーブル 1 つだけです。並列インポートでは、最大 10 個の Lightning インスタンスを使用できます。 ### 他のコンポーネントと併用する場合のヒント {#tips-for-using-with-other-components} -- TiDB Lightning をTiFlashと併用する場合は、次の点に注意してください。 +- TiDB Lightning をTiFlashと併用する場合は、次の点に注意してください。 - - テーブルにTiFlashレプリカを作成しているかどうかに関係なく、 TiDB Lightningを使用してテーブルにデータをインポートできます。ただし、インポートは通常のインポートよりも時間がかかる場合があります。インポート時間は、TiDB Lightningがデプロイされているサーバーのネットワーク帯域幅、 TiFlashノードのCPUとディスク負荷、およびTiFlashレプリカの数によって影響を受けます。 + - テーブルにTiFlashレプリカを作成しているかどうかに関係なく、 TiDB Lightningを使用してテーブルにデータをインポートできます。ただし、インポートは通常のインポートよりも時間がかかる場合があります。インポート時間は、TiDB Lightningがデプロイされているサーバーのネットワーク帯域幅、 TiFlashノードのCPUとディスク負荷、およびTiFlashレプリカの数によって影響を受けます。 -- TiDB Lightning文字セット: +- TiDB Lightning文字セット: - - v5.4.0 より前のTiDB Lightningでは、 `charset=GBK`のテーブルをインポートできません。 + - v5.4.0 より前のTiDB Lightningでは、 `charset=GBK`のテーブルをインポートできません。 -- TiDB Lightning をTiCDC と併用する場合の考慮事項については、 [TiDB Lightning物理インポート モードと TiCDC 間の互換性の制限は何ですか?](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-tidb-lightning-physical-import-mode-and-ticdc)を参照してください。 +- TiDB Lightning をTiCDC と併用する場合の考慮事項については、 [TiDB Lightning物理インポート モードと TiCDC 間の互換性の制限は何ですか?](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-tidb-lightning-physical-import-mode-and-ticdc)を参照してください。 -- BRでTiDB Lightning を使用する場合は、次の点に注意してください。 +- BRでTiDB Lightning を使用する場合は、次の点に注意してください。 - - BR がTiDB Lightningによってインポートされているテーブルのスナップショットをバックアップすると、それらのテーブルのバックアップ データが不整合になる可能性があります。 - - BR がAWS EBS ボリュームスナップショットを使用してデータをバックアップすると、 TiDB Lightning はデータのインポートに失敗する可能性があります。 - - TiDB Lightning物理インポート モードでインポートされたデータは[ログバックアップ](/br/br-pitr-guide.md#start-log-backup)をサポートしていないため、Point-in-Time Recovery (PITR) では復元できません。 + - BR がTiDB Lightningによってインポートされているテーブルのスナップショットをバックアップすると、それらのテーブルのバックアップ データが不整合になる可能性があります。 + - BR がAWS EBS ボリュームスナップショットを使用してデータをバックアップすると、 TiDB Lightning はデータのインポートに失敗する可能性があります。 + - TiDB Lightning物理インポート モードでインポートされたデータは[ログバックアップ](/br/br-pitr-guide.md#start-log-backup)をサポートしていないため、Point-in-Time Recovery (PITR) では復元できません。 diff --git a/tidb-lightning/tidb-lightning-requirements.md b/tidb-lightning/tidb-lightning-requirements.md index 84d4a3763aed6..1eb7c97a8b08a 100644 --- a/tidb-lightning/tidb-lightning-requirements.md +++ b/tidb-lightning/tidb-lightning-requirements.md @@ -17,8 +17,8 @@ TiDB Lightningを使用する前に、環境が要件を満たしているかど ターゲットTiKVクラスターには、インポートしたデータを保存するための十分なディスク容量が必要です。[標準的なハードウェア要件](/hardware-and-software-requirements.md)に加え、ターゲットTiKVクラスターのストレージ容量は**データソースのサイズ × レプリカ数 × 2**よりも大きくなければなりません。例えば、クラスターがデフォルトで3つのレプリカを使用する場合、ターゲットTiKVクラスターにはデータソースのサイズの6倍よりも大きなストレージ容量が必要です。式に x 2 が含まれているのは、以下の理由によるものです。 -- インデックスは余分なスペースを占める可能性があります。 -- RocksDB には空間増幅効果があります。 +- インデックスは余分なスペースを占める可能性があります。 +- RocksDB には空間増幅効果があります。 DumplingがMySQLからエクスポートするデータ量を正確に計算することは困難です。ただし、次のSQL文を使用してinformation_schema.tablesテーブルの`DATA_LENGTH`フィールドを集計することで、データ量を概算できます。 diff --git a/tidb-lightning/tidb-lightning-web-interface.md b/tidb-lightning/tidb-lightning-web-interface.md index 1804c50403b47..af3ea64f847a5 100644 --- a/tidb-lightning/tidb-lightning-web-interface.md +++ b/tidb-lightning/tidb-lightning-web-interface.md @@ -59,9 +59,9 @@ TiDB Lightningを起動したら、 `http://127.0.0.1:8289`にアクセスして タイトルバーの下にある3つのパネルには、すべてのテーブルが異なる状態に表示されます。 -- アクティブ: これらのテーブルは現在インポート中です -- 完了: これらのテーブルは正常にインポートされましたか、または失敗しました -- 保留中：これらのテーブルはまだ処理されていません +- アクティブ: これらのテーブルは現在インポート中です +- 完了: これらのテーブルは正常にインポートされましたか、または失敗しました +- 保留中：これらのテーブルはまだ処理されていません 各パネルには、テーブルの状態を説明するカードが入っています。 diff --git a/tidb-lightning/troubleshoot-tidb-lightning.md b/tidb-lightning/troubleshoot-tidb-lightning.md index 6482c849869c0..adee854ddd5f3 100644 --- a/tidb-lightning/troubleshoot-tidb-lightning.md +++ b/tidb-lightning/troubleshoot-tidb-lightning.md @@ -15,9 +15,9 @@ TiDB Lightning が遅くなる理由はいくつかあります。 **原因 1** : `region-concurrency`設定が高すぎるため、スレッドの競合が発生し、パフォーマンスが低下します。 -1. 設定は、ログの先頭から`region-concurrency`を検索すると見つかります。 -2. TiDB Lightning が他のサービス (TiKV Importer など) と同じマシンを共有する場合、 `region-concurrency`をCPU コアの合計数の 75% に**手動で**設定する必要があります。 -3. CPUクォータ（例えばKubernetesの設定による制限）がある場合、 TiDB Lightningはそれを読み取れない可能性があります。この場合も、 `region-concurrency`を**手動で**減らす必要があります。 +1. 設定は、ログの先頭から`region-concurrency`を検索すると見つかります。 +2. TiDB Lightning が他のサービス (TiKV Importer など) と同じマシンを共有する場合、 `region-concurrency`をCPU コアの合計数の 75% に**手動で**設定する必要があります。 +3. CPUクォータ（例えばKubernetesの設定による制限）がある場合、 TiDB Lightningはそれを読み取れない可能性があります。この場合も、 `region-concurrency`を**手動で**減らす必要があります。 **原因 2** : テーブル スキーマが複雑すぎます。 @@ -76,25 +76,25 @@ tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode `checksum mismatched`を含む行は情報`total_kvs: x vs y`を提供します。ここで、 `x`はインポートの完了後にターゲット クラスターによって計算されたキーと値のペア (KV ペア) の数を示し、 `y`はローカル データ ソースによって生成されたキーと値のペアの数を示します。 -- `x`が大きい場合は、ターゲット クラスター内にさらに多くの KV ペアが存在することを意味します。 - - インポート前にこのテーブルが空でなかったために、データのチェックサムに影響が出ている可能性があります。また、 TiDB Lightning が以前に障害を起こしてシャットダウンしたものの、正常に再起動しなかった可能性もあります。 -- `y`が大きい場合は、ローカル データ ソースにさらに多くの KV ペアが存在することを意味します。 - - ターゲットデータベースのチェックサムがすべて0の場合、インポートが実行されていないことを意味します。クラスターがビジー状態のため、データを受信できない可能性があります。 - - エクスポートされたデータに、重複した値を持つ UNIQUE KEY や PRIMARY KEY などの重複データが含まれている可能性があります。また、下流のテーブル構造では大文字と小文字が区別されないのに対し、データは大文字と小文字が区別される可能性があります。 -- その他の考えられる理由 - - データソースが機械生成で、 Dumplingによってバックアップされていない場合は、データがテーブルの制限に準拠していることを確認してください。例えば、AUTO_INCREMENT 列は 0 ではなく正の値である必要があります。 +- `x`が大きい場合は、ターゲット クラスター内にさらに多くの KV ペアが存在することを意味します。 + - インポート前にこのテーブルが空でなかったために、データのチェックサムに影響が出ている可能性があります。また、 TiDB Lightning が以前に障害を起こしてシャットダウンしたものの、正常に再起動しなかった可能性もあります。 +- `y`が大きい場合は、ローカル データ ソースにさらに多くの KV ペアが存在することを意味します。 + - ターゲットデータベースのチェックサムがすべて0の場合、インポートが実行されていないことを意味します。クラスターがビジー状態のため、データを受信できない可能性があります。 + - エクスポートされたデータに、重複した値を持つ UNIQUE KEY や PRIMARY KEY などの重複データが含まれている可能性があります。また、下流のテーブル構造では大文字と小文字が区別されないのに対し、データは大文字と小文字が区別される可能性があります。 +- その他の考えられる理由 + - データソースが機械生成で、 Dumplingによってバックアップされていない場合は、データがテーブルの制限に準拠していることを確認してください。例えば、AUTO_INCREMENT 列は 0 ではなく正の値である必要があります。 **ソリューション**： -1. `tidb-lightning-ctl`を使用して破損したデータを削除し、テーブル構造とデータを確認して、 TiDB Lightningを再起動して、影響を受けるテーブルを再度インポートします。 +1. `tidb-lightning-ctl`を使用して破損したデータを削除し、テーブル構造とデータを確認して、 TiDB Lightningを再起動して、影響を受けるテーブルを再度インポートします。 ```sh tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy=all ``` -2. ターゲット データベースの負荷を軽減するために、チェックポイント (変更`[checkpoint] dsn` ) を保存するために外部データベースの使用を検討してください。 +2. ターゲット データベースの負荷を軽減するために、チェックポイント (変更`[checkpoint] dsn` ) を保存するために外部データベースの使用を検討してください。 -3. TiDB Lightningが不適切に再起動された場合は、 FAQの「 [TiDB Lightningを適切に再起動する方法](/tidb-lightning/tidb-lightning-faq.md#how-to-properly-restart-tidb-lightning) 」セクションも参照してください。 +3. TiDB Lightningが不適切に再起動された場合は、 FAQの「 [TiDB Lightningを適切に再起動する方法](/tidb-lightning/tidb-lightning-faq.md#how-to-properly-restart-tidb-lightning) 」セクションも参照してください。 ### `Checkpoint for … has invalid status:` (エラー コード) {#checkpoint-for--has-invalid-status-error-code} @@ -118,11 +118,11 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= **ソリューション**： -1. ファイル全体が UTF-8 または GB-18030 になるようにスキーマを修正します。 +1. ファイル全体が UTF-8 または GB-18030 になるようにスキーマを修正します。 -2. ターゲット データベース内の影響を受けるテーブルを手動で`CREATE` 。 +2. ターゲット データベース内の影響を受けるテーブルを手動で`CREATE` 。 -3. `[mydumper] character-set = "binary"`を設定するとチェックをスキップします。ただし、これにより対象データベースに文字化けが発生する可能性があります。 +3. `[mydumper] character-set = "binary"`を設定するとチェックをスキップします。ただし、これにより対象データベースに文字化けが発生する可能性があります。 ### `[sql2kv] sql encode error = [types:1292]invalid time format: '{1970 1 1 …}'` {#sql2kv-sql-encode-error--types1292invalid-time-format-1970-1-1-} @@ -130,7 +130,7 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= **ソリューション**： -1. TiDB Lightningとソース データベースが同じタイム ゾーンを使用していることを確認します。 +1. TiDB Lightningとソース データベースが同じタイム ゾーンを使用していることを確認します。 TiDB Lightning を直接実行する場合、 `$TZ`環境変数を使用してタイムゾーンを強制できます。 @@ -139,7 +139,7 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= TZ='Asia/Shanghai' bin/tidb-lightning -config tidb-lightning.toml ``` -2. クラスター全体で同じ最新バージョン`tzdata` (バージョン 2018i 以上) が使用されていることを確認します。 +2. クラスター全体で同じ最新バージョン`tzdata` (バージョン 2018i 以上) が使用されていることを確認します。 CentOS では、 `yum info tzdata`を実行してインストールされているバージョンとアップデートの有無を確認します。`yum upgrade tzdata`を実行してパッケージをアップグレードします。 @@ -149,8 +149,8 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= **解決**： -- 制限を動的に増やすには、 [`tidb_txn_entry_size_limit`](/system-variables.md#tidb_txn_entry_size_limit-new-in-v760)システム変数を使用します。 -- TiKVにも同様の制限があることに注意してください。1回の書き込みリクエストのデータサイズが[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size) （デフォルトでは`8MiB` ）を超えると、TiKVはこのリクエストの処理を拒否します。テーブルに大きなサイズの行がある場合は、両方の設定を変更する必要があります。 +- 制限を動的に増やすには、 [`tidb_txn_entry_size_limit`](/system-variables.md#tidb_txn_entry_size_limit-new-in-v760)システム変数を使用します。 +- TiKVにも同様の制限があることに注意してください。1回の書き込みリクエストのデータサイズが[`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size) （デフォルトでは`8MiB` ）を超えると、TiKVはこのリクエストの処理を拒否します。テーブルに大きなサイズの行がある場合は、両方の設定を変更する必要があります。 ### TiDB Lightningがモードを切り替えるときに、 `rpc error: code = Unimplemented ...` {#encounter-rpc-error-code--unimplemented--when-tidb-lightning-switches-the-mode} @@ -158,8 +158,8 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= **ソリューション**： -- クラスター内にTiFlashノードがある場合は、クラスターを`v4.0.0-rc.2`以上のバージョンに更新できます。 -- クラスターをアップグレードしない場合は、 TiFlash を一時的に無効にします。 +- クラスター内にTiFlashノードがある場合は、クラスターを`v4.0.0-rc.2`以上のバージョンに更新できます。 +- クラスターをアップグレードしない場合は、 TiFlash を一時的に無効にします。 ### `tidb lightning encountered error: TiDB version too old, expected '>=4.0.0', found '3.0.18'` {#tidb-lightning-encountered-error-tidb-version-too-old-expected-400-found-3018} @@ -182,7 +182,7 @@ TiDBはMySQLのすべての文字セットをサポートしているわけで ### `invalid compression type ...` {#invalid-compression-type-} -- TiDB Lightning v6.4.0以降のバージョンでは、 `gzip` `snappy`圧縮データファイルのみがサポートされています。その他の種類の圧縮ファイルを使用するとエラーが発生します。ソースデータファイルが保存されているディレクトリにサポートされていない圧縮ファイルが存在する場合、タスクがエラーを報告します。このようなエラーを回避するには、サポートされていないファイルをインポートデータディレクトリから移動してください。詳細については、 [圧縮ファイル](/tidb-lightning/tidb-lightning-data-source.md#compressed-files)を参照してください。 +- TiDB Lightning v6.4.0以降のバージョンでは、 `gzip` `snappy`圧縮データファイルのみがサポートされています。その他の種類の圧縮ファイルを使用するとエラーが発生します。ソースデータファイルが保存されているディレクトリにサポートされていない圧縮ファイルが存在する場合、タスクがエラーを報告します。このようなエラーを回避するには、サポートされていないファイルをインポートデータディレクトリから移動してください。詳細については、 [圧縮ファイル](/tidb-lightning/tidb-lightning-data-source.md#compressed-files)を参照してください。 > **Note:** > diff --git a/tidb-limitations.md b/tidb-limitations.md index 97c730c34ae26..d1ba325313d45 100644 --- a/tidb-limitations.md +++ b/tidb-limitations.md @@ -49,8 +49,8 @@ summary: TiDB の使用制限について学習します。 -- 上限値`Columns`は[`table-column-count-limit`](/tidb-configuration-file.md#table-column-count-limit-new-in-v50)で変更できます。 -- 上限値`Indexes`は[`index-limit`](/tidb-configuration-file.md#index-limit-new-in-v50)で変更できます。 +- 上限値`Columns`は[`table-column-count-limit`](/tidb-configuration-file.md#table-column-count-limit-new-in-v50)で変更できます。 +- 上限値`Indexes`は[`index-limit`](/tidb-configuration-file.md#index-limit-new-in-v50)で変更できます。 diff --git a/tidb-monitoring-api.md b/tidb-monitoring-api.md index 45c594b394fa0..3ab1b634eac81 100644 --- a/tidb-monitoring-api.md +++ b/tidb-monitoring-api.md @@ -7,8 +7,8 @@ summary: TiDB 監視サービスの API を学習します。 次のタイプのインターフェースを使用して、TiDB クラスターのステータスを監視できます。 -- [ステータスインターフェース](#use-the-status-interface) : このインターフェースはHTTPインターフェースを使用してコンポーネント情報を取得します。このインターフェースを使用すると、現在のTiDBサーバーの[実行ステータス](#running-status)とテーブルの[ストレージ情報](#storage-information)を取得できます。 -- [メトリクスインターフェース](#use-the-metrics-interface) : このインターフェースは Prometheus を使用してコンポーネント内のさまざまな操作の詳細情報を記録し、Grafana を使用してこれらのメトリックを表示します。 +- [ステータスインターフェース](#use-the-status-interface) : このインターフェースはHTTPインターフェースを使用してコンポーネント情報を取得します。このインターフェースを使用すると、現在のTiDBサーバーの[実行ステータス](#running-status)とテーブルの[ストレージ情報](#storage-information)を取得できます。 +- [メトリクスインターフェース](#use-the-metrics-interface) : このインターフェースは Prometheus を使用してコンポーネント内のさまざまな操作の詳細情報を記録し、Grafana を使用してこれらのメトリックを表示します。 ## ステータスインターフェースを使用する {#use-the-status-interface} @@ -16,8 +16,8 @@ summary: TiDB 監視サービスの API を学習します。 ### TiDBサーバー {#tidb-server} -- TiDB API アドレス: `http://${host}:${port}` -- デフォルトポート: `10080` +- TiDB API アドレス: `http://${host}:${port}` +- デフォルトポート: `10080` ### 実行ステータス {#running-status} @@ -74,9 +74,9 @@ curl http://127.0.0.1:10080/schema_storage/test ### PDサーバー {#pd-server} -- 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)を参照してください。 +- 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)を参照してください。 PDインターフェースは、すべてのTiKVサーバーのステータスと負荷分散に関する情報を提供します。単一ノードのTiKVクラスターに関する情報については、次の例を参照してください。 @@ -116,6 +116,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 1be411085daaa..de571d656c73c 100644 --- a/tidb-monitoring-framework.md +++ b/tidb-monitoring-framework.md @@ -13,9 +13,9 @@ TiDB監視フレームワークは、PrometheusとGrafanaという2つのオー Prometheusは複数のコンポーネントで構成されています。現在、TiDBは以下のコンポーネントを使用しています。 -- 時系列データをスクレイピングして保存するためのPrometheusサーバー -- アプリケーションで必要なメトリックをカスタマイズするためのクライアントライブラリ -- アラートメカニズムのためのAlertmanager +- 時系列データをスクレイピングして保存するためのPrometheusサーバー +- アプリケーションで必要なメトリックをカスタマイズするためのクライアントライブラリ +- アラートメカニズムのためのAlertmanager 図は次のとおりです。 @@ -27,25 +27,25 @@ Grafanaは、メトリクスを分析および視覚化するためのオープ ![Grafana monitored\_groups](/media/grafana-monitored-groups.png) -- {TiDB_Cluster_name}-Backup-Restore: バックアップと復元に関連するメトリックを監視します。 -- {TiDB_Cluster_name}-Blackbox_exporter: ネットワーク プローブに関連するメトリックを監視します。 -- {TiDB_Cluster_name}-Disk-Performance: ディスク パフォーマンスに関連するメトリックを監視します。 -- {TiDB_Cluster_name}-Kafka-Overview: Kafka に関連するメトリックを監視します。 -- {TiDB_Cluster_name}-Lightning: TiDB Lightningに関連するメトリックを監視します。 -- {TiDB_Cluster_name}-Node_exporter: オペレーティング システムに関連するメトリックを監視します。 -- {TiDB_Cluster_name}-概要: 重要なコンポーネントに関連する監視の概要。 -- {TiDB_Cluster_name}-PD: PDサーバーに関連するメトリックを監視します。 -- {TiDB_Cluster_name}-Performance-Read: 読み取りパフォーマンスに関連するメトリックを監視します。 -- {TiDB_Cluster_name}-Performance-Write: 書き込みパフォーマンスに関連するメトリックを監視します。 -- {TiDB_Cluster_name}-TiDB: TiDBサーバーに関連する詳細な監視メトリック。 -- {TiDB_Cluster_name}-TiDB-Summary: TiDB に関連する監視の概要。 -- {TiDB_Cluster_name}- TiFlash -Proxy-Summary: TiFlashにデータを複製するために使用されるプロキシサーバーの監視概要。 -- {TiDB_Cluster_name}- TiFlash- 概要: TiFlashに関連する監視の概要。 -- {TiDB_Cluster_name}-TiKV-Details: TiKVサーバーに関連する詳細な監視メトリック。 -- {TiDB_Cluster_name}-TiKV-Summary: TiKVサーバーに関連する監視の概要。 -- {TiDB_Cluster_name}-TiKV-Trouble-Shooting: TiKV エラー診断に関連するメトリックを監視します。 -- {TiDB_Cluster_name}-TiCDC: TiCDC に関連する詳細な監視メトリック。 -- {TiDB_Cluster_name}-TiProxy-Summary: TiProxy に関連する監視の概要。 +- {TiDB_Cluster_name}-Backup-Restore: バックアップと復元に関連するメトリックを監視します。 +- {TiDB_Cluster_name}-Blackbox_exporter: ネットワーク プローブに関連するメトリックを監視します。 +- {TiDB_Cluster_name}-Disk-Performance: ディスク パフォーマンスに関連するメトリックを監視します。 +- {TiDB_Cluster_name}-Kafka-Overview: Kafka に関連するメトリックを監視します。 +- {TiDB_Cluster_name}-Lightning: TiDB Lightningに関連するメトリックを監視します。 +- {TiDB_Cluster_name}-Node_exporter: オペレーティング システムに関連するメトリックを監視します。 +- {TiDB_Cluster_name}-概要: 重要なコンポーネントに関連する監視の概要。 +- {TiDB_Cluster_name}-PD: PDサーバーに関連するメトリックを監視します。 +- {TiDB_Cluster_name}-Performance-Read: 読み取りパフォーマンスに関連するメトリックを監視します。 +- {TiDB_Cluster_name}-Performance-Write: 書き込みパフォーマンスに関連するメトリックを監視します。 +- {TiDB_Cluster_name}-TiDB: TiDBサーバーに関連する詳細な監視メトリック。 +- {TiDB_Cluster_name}-TiDB-Summary: TiDB に関連する監視の概要。 +- {TiDB_Cluster_name}- TiFlash -Proxy-Summary: TiFlashにデータを複製するために使用されるプロキシサーバーの監視概要。 +- {TiDB_Cluster_name}- TiFlash- 概要: TiFlashに関連する監視の概要。 +- {TiDB_Cluster_name}-TiKV-Details: TiKVサーバーに関連する詳細な監視メトリック。 +- {TiDB_Cluster_name}-TiKV-Summary: TiKVサーバーに関連する監視の概要。 +- {TiDB_Cluster_name}-TiKV-Trouble-Shooting: TiKV エラー診断に関連するメトリックを監視します。 +- {TiDB_Cluster_name}-TiCDC: TiCDC に関連する詳細な監視メトリック。 +- {TiDB_Cluster_name}-TiProxy-Summary: TiProxy に関連する監視の概要。 各グループには監視指標の複数のパネルラベルがあり、各パネルには複数の監視指標の詳細情報が表示されます。例えば、 **Overview**監視グループには5つのパネルラベルがあり、各ラベルは1つの監視パネルに対応しています。以下のUIをご覧ください。 diff --git a/tidb-operator-overview.md b/tidb-operator-overview.md index 2ebf6ecbbd919..0aeee1390aa8e 100644 --- a/tidb-operator-overview.md +++ b/tidb-operator-overview.md @@ -9,4 +9,4 @@ summary: Kubernetes 上の TiDB クラスターの自動運用システムでTiD 現在、 TiDB Operator のドキュメント（TiDB on Kubernetes ドキュメントとも呼ばれます）は、TiDB のドキュメントとは独立しています。ドキュメントにアクセスするには、次のリンクをクリックしてください。 -- [Kubernetes 上の TiDB ドキュメント](https://docs.pingcap.com/tidb-in-kubernetes/stable/) +- [Kubernetes 上の TiDB ドキュメント](https://docs.pingcap.com/tidb-in-kubernetes/stable/) diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md index 7a8e974c3b5eb..bc636df1cdecb 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -7,8 +7,8 @@ summary: 主要な設定を構成し、特殊なケースに対処すること このガイドでは、TiDBのパフォーマンスを最適化する方法について説明します。具体的には、以下の内容が含まれます。 -- 一般的なワークロードに対するベストプラクティス。 -- 困難なパフォーマンス状況に対処するための戦略。 +- 一般的なワークロードに対するベストプラクティス。 +- 困難なパフォーマンス状況に対処するための戦略。 > **Note:** > @@ -26,10 +26,10 @@ TiDBのパフォーマンスを最適化するには、さまざまな設定を TiDBのパフォーマンスを最適化するために、一般的に以下の設定が使用されます。 -- [SQLプリペアドプランキャッシュ](/sql-prepared-plan-cache.md)などの実行プランキャッシュ[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)強化します[インスタンスレベルの実行プランキャッシュ](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840) -- [オプティマイザー修正コントロール](/optimizer-fix-controls.md)を使用して TiDB オプティマイザの動作を最適化します。 -- ストレージエンジン[Titan](/storage-engine/titan-overview.md)をより積極的に活用する。 -- 書き込み負荷の高いワークロード下でも最適かつ安定したパフォーマンスを確保するために、TiKVの圧縮およびフロー制御の設定を微調整します。 +- [SQLプリペアドプランキャッシュ](/sql-prepared-plan-cache.md)などの実行プランキャッシュ[非プリペアドプランキャッシュ](/sql-non-prepared-plan-cache.md)強化します[インスタンスレベルの実行プランキャッシュ](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840) +- [オプティマイザー修正コントロール](/optimizer-fix-controls.md)を使用して TiDB オプティマイザの動作を最適化します。 +- ストレージエンジン[Titan](/storage-engine/titan-overview.md)をより積極的に活用する。 +- 書き込み負荷の高いワークロード下でも最適かつ安定したパフォーマンスを確保するために、TiKVの圧縮およびフロー制御の設定を微調整します。 これらの設定は、多くのワークロードのパフォーマンスを大幅に向上させることができます。ただし、他の最適化と同様に、本番に展開する前に、必ずご自身の環境で十分にテストしてください。 @@ -74,12 +74,12 @@ 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)を使用してパーティションテーブルにアクセスします。 -- [`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`演算子を含む実行計画をキャッシュすることを許可します。 -- [`44855:ON`](/optimizer-fix-controls.md#44855-new-in-v654-and-v730) : `IndexJoin`演算子の`Probe`側に`Selection`演算子が含まれている場合、オプティマイザは`IndexJoin`選択します。 -- [`52869:ON`](/optimizer-fix-controls.md#52869-new-in-v810) : オプティマイザがクエリ プランに対して (フル テーブル スキャン以外の) 単一のインデックス スキャン メソッドを選択できる場合、オプティマイザは自動的にインデックス マージを選択します。 +- [`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`演算子を含む実行計画をキャッシュすることを許可します。 +- [`44855:ON`](/optimizer-fix-controls.md#44855-new-in-v654-and-v730) : `IndexJoin`演算子の`Probe`側に`Selection`演算子が含まれている場合、オプティマイザは`IndexJoin`選択します。 +- [`52869:ON`](/optimizer-fix-controls.md#52869-new-in-v810) : オプティマイザがクエリ プランに対して (フル テーブル スキャン以外の) 単一のインデックス スキャン メソッドを選択できる場合、オプティマイザは自動的にインデックス マージを選択します。 ### TiKV構成 {#tikv-configurations} @@ -128,18 +128,18 @@ soft-pending-compaction-bytes-limit = "192GiB" 前述の表に示されている圧縮およびフロー制御構成の調整は、以下の仕様を持つインスタンスへの TiKV デプロイメントに合わせて調整されていることに注意してください。 -- CPU: 32コア -- メモリ: 128 GiB -- ストレージ: 5 TiB EBS -- ディスクスループット：1 GiB/秒 +- CPU: 32コア +- メモリ: 128 GiB +- ストレージ: 5 TiB EBS +- ディスクスループット：1 GiB/秒 #### 書き込み負荷の高いワークロードに対する推奨構成調整 {#recommended-configuration-adjustments-for-write-intensive-workloads} 書き込み負荷の高いワークロードにおける TiKV のパフォーマンスと安定性を最適化するには、インスタンスのハードウェア仕様に基づいて、特定の圧縮およびフロー制御パラメータを調整することをお勧めします。例: -- [`rocksdb.rate-bytes-per-sec`](/tikv-configuration-file.md#rate-bytes-per-sec) : 通常はデフォルト値を使用します。圧縮 I/O がディスク帯域幅のかなりの割合を消費していることに気づいた場合は、レートをディスクの最大スループットの約 60% に制限することを検討してください。これにより、圧縮作業のバランスが取れ、ディスクが飽和状態にならないようになります。たとえば、 **1 GiB/s**の定格のディスクでは、これを約`600MiB`に設定します。 +- [`rocksdb.rate-bytes-per-sec`](/tikv-configuration-file.md#rate-bytes-per-sec) : 通常はデフォルト値を使用します。圧縮 I/O がディスク帯域幅のかなりの割合を消費していることに気づいた場合は、レートをディスクの最大スループットの約 60% に制限することを検討してください。これにより、圧縮作業のバランスが取れ、ディスクが飽和状態にならないようになります。たとえば、 **1 GiB/s**の定格のディスクでは、これを約`600MiB`に設定します。 -- [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1)と[`storage.flow-control.hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit-1) ：これらの制限を、利用可能なディスク容量に比例して増やします（例えば、それぞれ1 TiBと2 TiB）。これにより、圧縮処理のためのバッファが増えます。 +- [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1)と[`storage.flow-control.hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit-1) ：これらの制限を、利用可能なディスク容量に比例して増やします（例えば、それぞれ1 TiBと2 TiB）。これにより、圧縮処理のためのバッファが増えます。 これらの設定は、リソースの効率的な利用を確保し、書き込み負荷がピークに達した際の潜在的なボトルネックを最小限に抑えるのに役立ちます。 @@ -170,10 +170,10 @@ snap-io-max-bytes-per-sec = "300MiB" テスト環境は以下のとおりです。 -- TiDBサーバー3台（16コア、64GiB） -- TiKVサーバー3台（16コア、64GiB） -- TiDBバージョン：v8.4.0 -- 作業負荷: [sysbench oltp_read_only](https://github.com/akopytov/sysbench/blob/master/src/lua/oltp_read_only.lua) +- TiDBサーバー3台（16コア、64GiB） +- TiKVサーバー3台（16コア、64GiB） +- TiDBバージョン：v8.4.0 +- 作業負荷: [sysbench oltp_read_only](https://github.com/akopytov/sysbench/blob/master/src/lua/oltp_read_only.lua) #### 性能比較 {#performance-comparison} @@ -191,44 +191,44 @@ snap-io-max-bytes-per-sec = "300MiB" インスタンスプランキャッシュは、ベースライン構成と比較して大幅なパフォーマンス向上を実現しています。 -- ヒット率の向上：53.82%増加（56.89%から87.51%へ）。 -- メモリ使用量の削減：26.34%減少（95.3 MiBから70.2 MiBへ）。 -- パフォーマンスの向上： +- ヒット率の向上：53.82%増加（56.89%から87.51%へ）。 +- メモリ使用量の削減：26.34%減少（95.3 MiBから70.2 MiBへ）。 +- パフォーマンスの向上： - - QPSは12.38%増加する。 - - 平均レイテンシーは11.01%減少します。 - - P95のレイテンシーは13.41%減少する。 + - QPSは12.38%増加する。 + - 平均レイテンシーは11.01%減少します。 + - P95のレイテンシーは13.41%減少する。 #### 仕組み {#how-it-works} インスタンスプランキャッシュは、以下のメカニズムを通じてパフォーマンスを向上させます。 -- メモリ内の`SELECT`ステートメントの実行計画をキャッシュします。 -- 同じ TiDB インスタンス上のすべての接続 (最大 200) 間で、キャッシュされたプランを共有します。 -- 1,000個のテーブルにわたって、最大5,000 `SELECT`ステートメントのプランを効率的に保存できます。 -- キャッシュミスは主に`BEGIN`と`COMMIT`ステートメントの場合にのみ発生します。 +- メモリ内の`SELECT`ステートメントの実行計画をキャッシュします。 +- 同じ TiDB インスタンス上のすべての接続 (最大 200) 間で、キャッシュされたプランを共有します。 +- 1,000個のテーブルにわたって、最大5,000 `SELECT`ステートメントのプランを効率的に保存できます。 +- キャッシュミスは主に`BEGIN`と`COMMIT`ステートメントの場合にのみ発生します。 #### 実生活におけるメリット {#real-world-benefits} シンプルなsysbench `oltp_read_only`クエリ（プランあたり14KB）を使用したベンチマークではわずかな改善しか見られませんが、実際のアプリケーションではより大きな効果が期待できます。 -- 複雑なクエリは最大20倍高速に実行できます。 -- セッションレベルのプランキャッシュと比較して、メモリ使用量がより効率的です。 +- 複雑なクエリは最大20倍高速に実行できます。 +- セッションレベルのプランキャッシュと比較して、メモリ使用量がより効率的です。 インスタンスプランキャッシュは、特に以下のようなシステムに効果的です。 -- 列数の多い大きな表。 -- 複雑なSQLクエリ。 -- 同時接続数が多い。 -- 多様なクエリパターン。 +- 列数の多い大きな表。 +- 複雑なSQLクエリ。 +- 同時接続数が多い。 +- 多様なクエリパターン。 #### メモリ効率 {#memory-efficiency} インスタンスプランキャッシュは、セッションレベルのプランキャッシュよりもメモリ効率が優れています。その理由は次のとおりです。 -- プランはすべての接続で共有されます -- 各セッションごとに計画を複製する必要はありません -- より高いヒット率を維持しながら、メモリ利用効率を向上させる。 +- プランはすべての接続で共有されます +- 各セッションごとに計画を複製する必要はありません +- より高いヒット率を維持しながら、メモリ利用効率を向上させる。 複数の接続と複雑なクエリが発生するシナリオでは、セッションレベルのプランキャッシュでは同等のヒット率を達成するために相当量のメモリが必要となるため、インスタンスプランキャッシュの方が効率的な選択肢となります。 @@ -256,10 +256,10 @@ sysbench oltp_read_only run --mysql-host={host} --mysql-port={port} --mysql-user テスト環境は以下のとおりです。 -- TiDBサーバー3台（16コア、64GiB） -- TiKVサーバー3台（16コア、64GiB） -- TiDBバージョン：v8.4.0 -- 作業負荷: [go-ycsbワークロード](https://github.com/pingcap/go-ycsb/blob/master/workloads/workloada) +- TiDBサーバー3台（16コア、64GiB） +- TiKVサーバー3台（16コア、64GiB） +- TiDBバージョン：v8.4.0 +- 作業負荷: [go-ycsbワークロード](https://github.com/pingcap/go-ycsb/blob/master/workloads/workloada) #### 性能比較 {#performance-comparison} @@ -276,8 +276,8 @@ sysbench oltp_read_only run --mysql-host={host} --mysql-port={port} --mysql-user 主要設定で確認されたパフォーマンスの向上は、主にTitanがRocksDBの圧縮を削減する能力によるものです。以下の図に示すように、 -- ベースライン：RocksDBの圧縮処理の総スループットは1 GiB/sを超え、ピーク時には3 GiB/sを超える。 -- 主な設定：RocksDBの圧縮処理のピークスループットは100 MiB/sを下回っています。 +- ベースライン：RocksDBの圧縮処理の総スループットは1 GiB/sを超え、ピーク時には3 GiB/sを超える。 +- 主な設定：RocksDBの圧縮処理のピークスループットは100 MiB/sを下回っています。 この圧縮処理オーバーヘッドの大幅な削減は、主要設定構成で見られる全体的なスループットの向上に貢献しています。 @@ -305,23 +305,23 @@ go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p 例外的なケースを特定するには、以下の手順を実行してください。 -1. クエリパターンとワークロード特性を分析する。 -2. システム指標を監視して、パフォーマンスのボトルネックを特定します。 -3. アプリケーション開発チームから、具体的な問題点に関するフィードバックを収集する。 +1. クエリパターンとワークロード特性を分析する。 +2. システム指標を監視して、パフォーマンスのボトルネックを特定します。 +3. アプリケーション開発チームから、具体的な問題点に関するフィードバックを収集する。 ### 一般的なエッジケース {#common-edge-cases} 以下に、よくある例外的なケースをいくつか挙げます。 -- 高頻度の小さなクエリでのTSO待機時間が長い -- さまざまなワークロードに適した最大チャンクサイズを選択してください。 -- 読み込み負荷の高いワークロード向けにコプロセッサキャッシュを調整する -- ワークロード特性に合わせてチャンクサイズを最適化 -- さまざまなワークロードに合わせてトランザクションモードとDMLタイプを最適化する -- TiKVプッシュダウンによる`GROUP BY`および`DISTINCT`オペレーションの最適化 -- インメモリエンジンを使用してMVCCバージョンの蓄積を軽減する -- バッチ処理中の統計情報収集を最適化する -- インスタンスの種類ごとにスレッドプールの設定を最適化する +- 高頻度の小さなクエリでのTSO待機時間が長い +- さまざまなワークロードに適した最大チャンクサイズを選択してください。 +- 読み込み負荷の高いワークロード向けにコプロセッサキャッシュを調整する +- ワークロード特性に合わせてチャンクサイズを最適化 +- さまざまなワークロードに合わせてトランザクションモードとDMLタイプを最適化する +- TiKVプッシュダウンによる`GROUP BY`および`DISTINCT`オペレーションの最適化 +- インメモリエンジンを使用してMVCCバージョンの蓄積を軽減する +- バッチ処理中の統計情報収集を最適化する +- インスタンスの種類ごとにスレッドプールの設定を最適化する 以下のセクションでは、これらの各ケースへの対処方法について説明します。それぞれのシナリオに応じて、異なるパラメータを調整したり、特定のTiDB機能を使用したりする必要があります。 @@ -335,8 +335,8 @@ go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p ワークロードに頻繁に発生する小規模なトランザクションや、タイムスタンプを頻繁に要求するクエリが含まれる場合、 [TSO（タイムスタンプオラクル）](/glossary.md#timestamp-oracle-tso)がパフォーマンスのボトルネックになる可能性があります。TSO の待機時間がシステムに影響を与えているかどうかを確認するには、 [**パフォーマンス概要 > SQL実行時間概要**](/grafana-performance-overview-dashboard.md#sql-execute-time-overview)パネルを確認してください。TSO の待機時間が SQL 実行時間の大部分を占める場合は、次の最適化を検討してください。 -- 厳密な一貫性を必要としない読み取り操作には、低精度TSO（ [`tidb_low_resolution_tso`](/system-variables.md#tidb_low_resolution_tso)を有効にする）を使用します。詳細については、 [解決策1：低精度TSOを使用する](#solution-1-low-precision-tso)を参照してください。 -- 可能な場合は、小さなトランザクションをまとめて大きなトランザクションにします。詳細については、 [解決策2：TSO要求の並列モード](#solution-2-parallel-mode-for-tso-requests)を参照してください。 +- 厳密な一貫性を必要としない読み取り操作には、低精度TSO（ [`tidb_low_resolution_tso`](/system-variables.md#tidb_low_resolution_tso)を有効にする）を使用します。詳細については、 [解決策1：低精度TSOを使用する](#solution-1-low-precision-tso)を参照してください。 +- 可能な場合は、小さなトランザクションをまとめて大きなトランザクションにします。詳細については、 [解決策2：TSO要求の並列モード](#solution-2-parallel-mode-for-tso-requests)を参照してください。 #### 解決策1：低精度TSO {#solution-1-low-precision-tso} @@ -344,14 +344,14 @@ go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p この最適化は、特に以下のシナリオで効果を発揮します。 -- 読み込み負荷の高いワークロードで、多少の古さは許容範囲内。 -- クエリのレイテンシーを削減することが、絶対的な一貫性よりも重要なシナリオ。 -- 最新のコミット状態から数秒遅れた読み取りを許容できるアプリケーション。 +- 読み込み負荷の高いワークロードで、多少の古さは許容範囲内。 +- クエリのレイテンシーを削減することが、絶対的な一貫性よりも重要なシナリオ。 +- 最新のコミット状態から数秒遅れた読み取りを許容できるアプリケーション。 メリットとデメリット： -- キャッシュされたTSOを使用して古いデータの読み取りを有効にすることで、クエリのレイテンシーを削減し、新しいタイムスタンプを要求する必要性をなくします。 -- パフォーマンスとデータの一貫性のバランスを取る：この機能は、古い読み取りデータが許容されるシナリオにのみ適しています。厳密なデータの一貫性が求められる場合には、使用を推奨しません。 +- キャッシュされたTSOを使用して古いデータの読み取りを有効にすることで、クエリのレイテンシーを削減し、新しいタイムスタンプを要求する必要性をなくします。 +- パフォーマンスとデータの一貫性のバランスを取る：この機能は、古い読み取りデータが許容されるシナリオにのみ適しています。厳密なデータの一貫性が求められる場合には、使用を推奨しません。 この最適化を有効にするには： @@ -363,13 +363,13 @@ SET GLOBAL tidb_low_resolution_tso=ON; システム変数[`tidb_tso_client_rpc_mode`](/system-variables.md#tidb_tso_client_rpc_mode-new-in-v840)は、TiDBがPDにTSO RPCリクエストを送信するモードを切り替えます。デフォルト値は`DEFAULT`です。以下の条件を満たす場合、パフォーマンス向上の可能性を考慮して、この変数を`PARALLEL`または`PARALLEL-FAST`に切り替えることを検討してください。 -- TSOの待機時間は、SQLクエリの総実行時間の大部分を占める。 -- PDにおけるTSOの割り当ては、まだボトルネックに達していません。 -- PDノードとTiDBノードは十分なCPUリソースを備えています。 -- TiDBとPD間のネットワークレイテンシーは、PDがTSOを割り当てるのにかかる時間よりもかなり長い（つまり、TSO RPCの実行時間の大部分はネットワークレイテンシーによるものである）。 - - TSO RPCリクエストの所要時間を取得するには、Grafana TiDBダッシュボードのPDクライアントセクションにある**PD TSO RPC所要時間**パネルを確認してください。 - - PD TSO割り当ての期間を確認するには、Grafana PDダッシュボードのTiDBセクションにある**PDサーバーTSOハンドル期間**パネルを確認してください。 -- TiDBとPD間のTSO RPCリクエストの増加（ `PARALLEL`の場合は2倍、 `PARALLEL-FAST`の場合は4倍）によって生じる追加のネットワークトラフィックは許容範囲内です。 +- TSOの待機時間は、SQLクエリの総実行時間の大部分を占める。 +- PDにおけるTSOの割り当ては、まだボトルネックに達していません。 +- PDノードとTiDBノードは十分なCPUリソースを備えています。 +- TiDBとPD間のネットワークレイテンシーは、PDがTSOを割り当てるのにかかる時間よりもかなり長い（つまり、TSO RPCの実行時間の大部分はネットワークレイテンシーによるものである）。 + - TSO RPCリクエストの所要時間を取得するには、Grafana TiDBダッシュボードのPDクライアントセクションにある**PD TSO RPC所要時間**パネルを確認してください。 + - PD TSO割り当ての期間を確認するには、Grafana PDダッシュボードのTiDBセクションにある**PDサーバーTSOハンドル期間**パネルを確認してください。 +- TiDBとPD間のTSO RPCリクエストの増加（ `PARALLEL`の場合は2倍、 `PARALLEL-FAST`の場合は4倍）によって生じる追加のネットワークトラフィックは許容範囲内です。 並列モードを切り替えるには、次のコマンドを実行してください。 @@ -385,9 +385,9 @@ SET GLOBAL tidb_tso_client_rpc_mode=PARALLEL-FAST; [コプロセッサキャッシュ](/coprocessor-cache.md)キャッシュを最適化することで、読み取り負荷の高いワークロードのクエリ パフォーマンスを向上させることができます。このキャッシュにはコプロセッサのリクエスト結果が格納され、頻繁にアクセスされるデータの繰り返し計算が削減されます。キャッシュのパフォーマンスを最適化するには、次の手順を実行します。 -1. [コプロセッサーキャッシュ](/coprocessor-cache.md#view-the-grafana-monitoring-panel)で説明した指標を使用してキャッシュヒット率を監視します。 -2. キャッシュサイズを増やすことで、より大きなワーキングセットにおけるヒット率を向上させることができます。 -3. クエリパターンに基づいて、承認基準値を調整する。 +1. [コプロセッサーキャッシュ](/coprocessor-cache.md#view-the-grafana-monitoring-panel)で説明した指標を使用してキャッシュヒット率を監視します。 +2. キャッシュサイズを増やすことで、より大きなワーキングセットにおけるヒット率を向上させることができます。 +3. クエリパターンに基づいて、承認基準値を調整する。 以下に、読み込み負荷の高いワークロード向けに推奨される設定例をいくつか示します。 @@ -403,21 +403,21 @@ admission-min-process-ms = 0 システム変数[`tidb_max_chunk_size`](/system-variables.md#tidb_max_chunk_size)は、実行プロセス中にチャンク内の最大行数を設定します。ワークロードに応じてこの値を調整することで、パフォーマンスを向上させることができます。 -- 同時実行数が多くトランザクション数が少ないOLTPワークロードの場合： +- 同時実行数が多くトランザクション数が少ないOLTPワークロードの場合： - - 値を`128`から`256`行の間で設定してください（デフォルト値は`1024`です）。 - - これによりメモリ使用量が削減され、制限クエリの処理速度が向上します。 - - 使用例：ポイントクエリ、小範囲スキャン。 + - 値を`128`から`256`行の間で設定してください（デフォルト値は`1024`です）。 + - これによりメモリ使用量が削減され、制限クエリの処理速度が向上します。 + - 使用例：ポイントクエリ、小範囲スキャン。 ```sql SET GLOBAL tidb_max_chunk_size = 128; ``` -- 複雑なクエリと大規模な結果セットを伴うOLAPまたは分析ワークロードの場合： +- 複雑なクエリと大規模な結果セットを伴うOLAPまたは分析ワークロードの場合： - - 値を`1024`から`4096`行の間で設定してください。 - - これにより、大量のデータをスキャンする際のスループットが向上します。 - - 使用例：集計処理、大規模テーブルのスキャン。 + - 値を`1024`から`4096`行の間で設定してください。 + - これにより、大量のデータをスキャンする際のスループットが向上します。 + - 使用例：集計処理、大規模テーブルのスキャン。 ```sql SET GLOBAL tidb_max_chunk_size = 4096; @@ -431,20 +431,20 @@ TiDBは、さまざまなワークロードパターンに合わせてパフォ トランザクションモードは、システム変数[`tidb_txn_mode`](/system-variables.md#tidb_txn_mode)を使用して設定できます。 -- [悲観的トランザクションモード](/pessimistic-transaction.md) （デフォルト）： +- [悲観的トランザクションモード](/pessimistic-transaction.md) （デフォルト）： - - 書き込み競合が発生する可能性のある一般的なワークロードに適しています。 - - より強力な一貫性保証を提供します。 + - 書き込み競合が発生する可能性のある一般的なワークロードに適しています。 + - より強力な一貫性保証を提供します。 ```sql SET SESSION tidb_txn_mode = "pessimistic"; ``` -- [楽観的トランザクションモード](/optimistic-transaction.md) : +- [楽観的トランザクションモード](/optimistic-transaction.md) : - - 書き込み競合が最小限のワークロードに適しています。 - - 複数明細のトランザクションにおけるパフォーマンスが向上しました。 - - 例： `BEGIN; INSERT...; INSERT...; COMMIT;` . + - 書き込み競合が最小限のワークロードに適しています。 + - 複数明細のトランザクションにおけるパフォーマンスが向上しました。 + - 例： `BEGIN; INSERT...; INSERT...; COMMIT;` . ```sql SET SESSION tidb_txn_mode = "optimistic"; @@ -456,8 +456,8 @@ TiDBは、さまざまなワークロードパターンに合わせてパフォ バルクDML実行モードを使用するには、 `tidb_dml_type`を`"bulk"`に設定します。このモードでは、競合のないバルクデータロードが最適化され、大規模な書き込み操作中のメモリ使用量が削減されます。このモードを使用する前に、以下の点を確認してください。 -- [`autocommit`](/system-variables.md#autocommit)が有効です。 -- [`pessimistic-auto-commit`](/tidb-configuration-file.md#pessimistic-auto-commit-new-in-v600)設定項目は`false`に設定されています。 +- [`autocommit`](/system-variables.md#autocommit)が有効です。 +- [`pessimistic-auto-commit`](/tidb-configuration-file.md#pessimistic-auto-commit-new-in-v600)設定項目は`false`に設定されています。 ```sql SET SESSION tidb_dml_type = "bulk"; @@ -469,15 +469,15 @@ TiDBは集計処理をTiKVにプッシュダウンすることで、データ転 #### 使用シナリオ {#usage-scenarios} -- **理想的なシナリオ**（高いパフォーマンス向上）： - - 異なる値が少ない列（NDVが低い）。 - - 重複値が頻繁に含まれるデータ。 - - 例：ステータス列、カテゴリコード、日付部分。 +- **理想的なシナリオ**（高いパフォーマンス向上）： + - 異なる値が少ない列（NDVが低い）。 + - 重複値が頻繁に含まれるデータ。 + - 例：ステータス列、カテゴリコード、日付部分。 -- **理想的でないシナリオ**（潜在的なパフォーマンス低下）： - - ほとんどが一意の値を含む列（NDVが高い）。 - - 固有の識別子またはタイムスタンプ。 - - 例：ユーザーID、トランザクションID。 +- **理想的でないシナリオ**（潜在的なパフォーマンス低下）： + - ほとんどが一意の値を含む列（NDVが高い）。 + - 固有の識別子またはタイムスタンプ。 + - 例：ユーザーID、トランザクションID。 #### コンフィグレーション {#configuration} @@ -512,21 +512,21 @@ enable = true 以下のシナリオでは、システム変数[`tidb_enable_auto_analyze`](/system-variables.md#tidb_enable_auto_analyze-new-in-v610)を`OFF`に設定することでauto analyzeを無効にできます。 -- 大量のデータインポート時。 -- 一括更新処理中。 -- 時間制約のあるバッチ処理向け。 -- 統計情報の収集タイミングを完全に制御する必要がある場合。 +- 大量のデータインポート時。 +- 一括更新処理中。 +- 時間制約のあるバッチ処理向け。 +- 統計情報の収集タイミングを完全に制御する必要がある場合。 #### ベストプラクティス {#best-practices} -- バッチ処理の前に： +- バッチ処理の前に： ```sql -- Disable auto analyze SET GLOBAL tidb_enable_auto_analyze = OFF; ``` -- バッチ処理後： +- バッチ処理後： ```sql -- Manually collect statistics @@ -540,9 +540,9 @@ enable = true TiKVのパフォーマンスを向上させるには、インスタンスのCPUリソースに基づいてスレッドプールを設定してください。以下のガイドラインは、これらの設定を最適化するのに役立ちます。 -- 8～16コアのインスタンスの場合、デフォルト設定で通常は十分です。 +- 8～16コアのインスタンスの場合、デフォルト設定で通常は十分です。 -- 32コア以上のインスタンスでは、リソース利用効率を向上させるためにプールサイズを増やしてください。設定は以下のように調整してください。 +- 32コア以上のインスタンスでは、リソース利用効率を向上させるためにプールサイズを増やしてください。設定は以下のように調整してください。 ```toml [server] diff --git a/tidb-read-staleness.md b/tidb-read-staleness.md index 3520e26e0885a..7b03d4abf4114 100644 --- a/tidb-read-staleness.md +++ b/tidb-read-staleness.md @@ -13,13 +13,13 @@ summary: tidb_read_staleness` システム変数を使用して履歴データ `tidb_read_staleness`有効にした後でも、次の操作を実行できます。 -- 現在のセッションでデータの挿入、変更、削除、またはDML操作を実行します。これらの文は`tidb_read_staleness`の影響を受けません。 -- 現在のセッションで対話型トランザクションを開始します。このトランザクション内のクエリは最新のデータを読み取ります。 +- 現在のセッションでデータの挿入、変更、削除、またはDML操作を実行します。これらの文は`tidb_read_staleness`の影響を受けません。 +- 現在のセッションで対話型トランザクションを開始します。このトランザクション内のクエリは最新のデータを読み取ります。 履歴データを読み取った後、次の 2 つの方法で最新データを読み取ることができます。 -- 新しいセッションを開始します。 -- `SET`ステートメントを使用して、変数`tidb_read_staleness`の値を`""`に設定します。 +- 新しいセッションを開始します。 +- `SET`ステートメントを使用して、変数`tidb_read_staleness`の値を`""`に設定します。 > **Note:** > @@ -29,59 +29,69 @@ summary: tidb_read_staleness` システム変数を使用して履歴データ このセクションでは、 `tidb_read_staleness`使用方法を例とともに説明します。 -1. テーブルを作成し、テーブルに数行のデータを挿入します。 +1. テーブルを作成し、テーブルに数行のデータを挿入します。 ```sql create table t (c int); ``` - Query OK, 0 rows affected (0.01 sec) + ``` + Query OK, 0 rows affected (0.01 sec) + ``` ```sql insert into t values (1), (2), (3); ``` - Query OK, 3 rows affected (0.00 sec) + ``` + Query OK, 3 rows affected (0.00 sec) + ``` -2. 表のデータを確認してください: +2. 表のデータを確認してください: ```sql select * from t; ``` - +------+ - | c | - +------+ - | 1 | - | 2 | - | 3 | - +------+ - 3 rows in set (0.00 sec) + ``` + +------+ + | c | + +------+ + | 1 | + | 2 | + | 3 | + +------+ + 3 rows in set (0.00 sec) + ``` -3. 行内のデータを更新します。 +3. 行内のデータを更新します。 ```sql update t set c=22 where c=2; ``` - Query OK, 1 row affected (0.00 sec) + ``` + Query OK, 1 row affected (0.00 sec) + ``` -4. データが更新されたことを確認します。 +4. データが更新されたことを確認します。 ```sql select * from t; ``` - +------+ - | c | - +------+ - | 1 | - | 22 | - | 3 | - +------+ - 3 rows in set (0.00 sec) + ``` + +------+ + | c | + +------+ + | 1 | + | 22 | + | 3 | + +------+ + 3 rows in set (0.00 sec) + ``` -5. システム変数`tidb_read_staleness`を設定します。 +5. システム変数`tidb_read_staleness`を設定します。 この変数のスコープは`SESSION`です。値を設定すると、TiDB は値で設定された時間より前の最新バージョンのデータを読み取ります。 @@ -91,12 +101,14 @@ summary: tidb_read_staleness` システム変数を使用して履歴データ set @@tidb_read_staleness="-5"; ``` - Query OK, 0 rows affected (0.00 sec) + ``` + Query OK, 0 rows affected (0.00 sec) + ``` > **Note:** > - > - `tidb_read_staleness`の前には`@`ではなく`@@`を使用します。`@@`はシステム変数、 `@`はユーザー変数を意味します。 - > - 履歴時間範囲（値`tidb_read_staleness` ）は、手順 3 と手順 4 に費やした合計時間に応じて設定する必要があります。そうしないと、クエリ結果には履歴データではなく最新のデータが表示されてしまいます。したがって、操作に費やした時間に応じてこの時間範囲を調整する必要があります。例えば、この例では設定時間範囲が 5 秒であるため、手順 3 と手順 4 を 5 秒以内に完了する必要があります。 + > - `tidb_read_staleness`の前には`@`ではなく`@@`を使用します。`@@`はシステム変数、 `@`はユーザー変数を意味します。 + > - 履歴時間範囲（値`tidb_read_staleness` ）は、手順 3 と手順 4 に費やした合計時間に応じて設定する必要があります。そうしないと、クエリ結果には履歴データではなく最新のデータが表示されてしまいます。したがって、操作に費やした時間に応じてこの時間範囲を調整する必要があります。例えば、この例では設定時間範囲が 5 秒であるため、手順 3 と手順 4 を 5 秒以内に完了する必要があります。 ここで読み取られるデータは更新前のデータ、つまり履歴データです。 @@ -104,32 +116,38 @@ summary: tidb_read_staleness` システム変数を使用して履歴データ select * from t; ``` - +------+ - | c | - +------+ - | 1 | - | 2 | - | 3 | - +------+ - 3 rows in set (0.00 sec) + ``` + +------+ + | c | + +------+ + | 1 | + | 2 | + | 3 | + +------+ + 3 rows in set (0.00 sec) + ``` -6. 次のようにこの変数を設定解除すると、TiDB は最新のデータを読み取ることができます。 +6. 次のようにこの変数を設定解除すると、TiDB は最新のデータを読み取ることができます。 ```sql set @@tidb_read_staleness=""; ``` - Query OK, 0 rows affected (0.00 sec) + ``` + Query OK, 0 rows affected (0.00 sec) + ``` ```sql select * from t; ``` - +------+ - | c | - +------+ - | 1 | - | 22 | - | 3 | - +------+ - 3 rows in set (0.00 sec) + ``` + +------+ + | c | + +------+ + | 1 | + | 22 | + | 3 | + +------+ + 3 rows in set (0.00 sec) + ``` diff --git a/tidb-resource-control-background-tasks.md b/tidb-resource-control-background-tasks.md index b0bde3fd5ddde..390902a24ce15 100644 --- a/tidb-resource-control-background-tasks.md +++ b/tidb-resource-control-background-tasks.md @@ -19,28 +19,28 @@ v7.4.0以降、 [TiDB リソース制御](/tidb-resource-control-ru-groups.md) ## `BACKGROUND`パラメータ {#background-parameters} -- `TASK_TYPES` : バックグラウンドタスクとして管理する必要があるタスクの種類を指定します。複数のタスクの種類を指定する場合は、カンマ ( `,` ) で区切ります。 -- `UTILIZATION_LIMIT` : 各 TiKV ノード上でバックグラウンドタスクが消費できるリソースの最大割合（0～100）を制限します。デフォルトでは、TiKV はノードの総リソースとフォアグラウンドタスクが現在占有しているリソースに基づいて、バックグラウンドタスクに利用可能なリソースを計算します。`UTILIZATION_LIMIT`を設定すると、バックグラウンドタスクに割り当てられるリソースはこの制限を超えません。 +- `TASK_TYPES` : バックグラウンドタスクとして管理する必要があるタスクの種類を指定します。複数のタスクの種類を指定する場合は、カンマ ( `,` ) で区切ります。 +- `UTILIZATION_LIMIT` : 各 TiKV ノード上でバックグラウンドタスクが消費できるリソースの最大割合（0～100）を制限します。デフォルトでは、TiKV はノードの総リソースとフォアグラウンドタスクが現在占有しているリソースに基づいて、バックグラウンドタスクに利用可能なリソースを計算します。`UTILIZATION_LIMIT`を設定すると、バックグラウンドタスクに割り当てられるリソースはこの制限を超えません。 TiDB は次の種類のバックグラウンド タスクをサポートしています。 -- `import` : [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してインポートタスクを実行します。TiDB Lightning の物理インポートモードと論理インポートモードの両方がサポートされています。 -- `br` : [BR](/br/backup-and-restore-overview.md)を使用してバックアップおよび復元タスクを実行します。PITR はサポートされていません。 -- `ddl` : Reorg DDL のバッチ データ書き戻しフェーズ中のリソース使用量を制御します。 -- `stats` : 手動で実行されるか、TiDB によって自動的にトリガーされる[統計を収集する](/statistics.md#collect-statistics)タスク。 -- `background` : 予約済みのタスクタイプ。システム変数[`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-new-in-v740)を使用して、現在のセッションのタスクタイプを`background`として指定できます。 +- `import` : [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してインポートタスクを実行します。TiDB Lightning の物理インポートモードと論理インポートモードの両方がサポートされています。 +- `br` : [BR](/br/backup-and-restore-overview.md)を使用してバックアップおよび復元タスクを実行します。PITR はサポートされていません。 +- `ddl` : Reorg DDL のバッチ データ書き戻しフェーズ中のリソース使用量を制御します。 +- `stats` : 手動で実行されるか、TiDB によって自動的にトリガーされる[統計を収集する](/statistics.md#collect-statistics)タスク。 +- `background` : 予約済みのタスクタイプ。システム変数[`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-new-in-v740)を使用して、現在のセッションのタスクタイプを`background`として指定できます。 -- `import` : [TiDB Lightning](https://docs.pingcap.com/tidb/stable/tidb-lightning-overview)を使用してインポートタスクを実行します。TiDB Lightningの物理インポートモードと論理インポートモードの両方がサポートされています。 -- `br` : [BR](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview)を使用してバックアップおよび復元タスクを実行します。PITR はサポートされていません。 -- `ddl` : Reorg DDL のバッチ データ書き戻しフェーズ中のリソース使用量を制御します。 -- `stats` : 手動で実行されるか、TiDB によって自動的にトリガーされる[統計を収集する](/statistics.md#collect-statistics)タスク。 -- `background` : 予約済みのタスクタイプ。システム変数[`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-new-in-v740)を使用して、現在のセッションのタスクタイプを`background`として指定できます。 +- `import` : [TiDB Lightning](https://docs.pingcap.com/tidb/stable/tidb-lightning-overview)を使用してインポートタスクを実行します。TiDB Lightningの物理インポートモードと論理インポートモードの両方がサポートされています。 +- `br` : [BR](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview)を使用してバックアップおよび復元タスクを実行します。PITR はサポートされていません。 +- `ddl` : Reorg DDL のバッチ データ書き戻しフェーズ中のリソース使用量を制御します。 +- `stats` : 手動で実行されるか、TiDB によって自動的にトリガーされる[統計を収集する](/statistics.md#collect-statistics)タスク。 +- `background` : 予約済みのタスクタイプ。システム変数[`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-new-in-v740)を使用して、現在のセッションのタスクタイプを`background`として指定できます。 @@ -52,25 +52,25 @@ TiDB は次の種類のバックグラウンド タスクをサポートして ## 例 {#examples} -1. `br`と`ddl`バックグラウンド タスクとしてマークし、バックグラウンド タスクのリソース制限を 30% に設定して、リソース グループ`default`を変更します。 +1. `br`と`ddl`バックグラウンド タスクとしてマークし、バックグラウンド タスクのリソース制限を 30% に設定して、リソース グループ`default`を変更します。 ```sql ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES='br,ddl', UTILIZATION_LIMIT=30); ``` -2. `default`リソース グループを変更して、バックグラウンド タスクの種類を既定値に戻します。 +2. `default`リソース グループを変更して、バックグラウンド タスクの種類を既定値に戻します。 ```sql ALTER RESOURCE GROUP `default` BACKGROUND=NULL; ``` -3. `default`リソースグループを変更して、バックグラウンドタスクの種類を空に設定します。この場合、このリソースグループのすべてのタスクはバックグラウンドタスクとして扱われません。 +3. `default`リソースグループを変更して、バックグラウンドタスクの種類を空に設定します。この場合、このリソースグループのすべてのタスクはバックグラウンドタスクとして扱われません。 ```sql ALTER RESOURCE GROUP `default` BACKGROUND=(TASK_TYPES=""); ``` -4. `default`リソース グループのバックグラウンド タスクの種類を表示する。 +4. `default`リソース グループのバックグラウンド タスクの種類を表示する。 ```sql SELECT * FROM information_schema.resource_groups WHERE NAME="default"; @@ -86,7 +86,7 @@ TiDB は次の種類のバックグラウンド タスクをサポートして +---------+------------+----------+-----------+-------------+-------------------------------------------+ ``` -5. 現在のセッションのタスクを明示的にバックグラウンドタイプとしてマークするには、 `tidb_request_source_type`を使用してタスクタイプを明示的に指定します。例を以下に示します。 +5. 現在のセッションのタスクを明示的にバックグラウンドタイプとしてマークするには、 `tidb_request_source_type`を使用してタスクタイプを明示的に指定します。例を以下に示します。 ```sql SET @@tidb_request_source_type="background"; diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index 7fd625002c05c..e915d0ddc38e2 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -14,30 +14,30 @@ aliases: ['/ja/tidb/v8.5/tidb-resource-control/','/ja/tidb/stable/tidb-resource- TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能とTiKVレイヤーの優先度スケジューリング機能という2つのレイヤーのリソース管理機能を提供します。これらの2つの機能は、個別に、または同時に有効にすることができます。詳しくは[リソース制御のためのパラメータ](#parameters-for-resource-control)を参照してください。これにより、TiDBレイヤーはリソースグループに設定されたクォータに基づいてユーザーの読み取りおよび書き込み要求のフローを制御し、TiKVレイヤーは読み取りおよび書き込みクォータにマッピングされた優先度に基づいて要求をスケジュールすることができます。この操作を行うことで、アプリケーションのリソース分離を確保し、サービス品質（QoS）要件を満たすことができます。 -- TiDBフロー制御：TiDBフロー制御は[トークンバケットアルゴリズム](https://en.wikipedia.org/wiki/Token_bucket)を使用します。バケットに十分なトークンがなく、リソースグループが`BURSTABLE`オプションを指定していない場合、リソースグループへのリクエストはトークンバケットがトークンを補充するまで待機し、再試行します。再試行はタイムアウトにより失敗する可能性があります。 +- TiDBフロー制御：TiDBフロー制御は[トークンバケットアルゴリズム](https://en.wikipedia.org/wiki/Token_bucket)を使用します。バケットに十分なトークンがなく、リソースグループが`BURSTABLE`オプションを指定していない場合、リソースグループへのリクエストはトークンバケットがトークンを補充するまで待機し、再試行します。再試行はタイムアウトにより失敗する可能性があります。 -- TiKV スケジューリング: 必要に応じて絶対優先度[（ `PRIORITY` ）](/information-schema/information-schema-resource-groups.md#examples)を設定できます。異なるリソースは`PRIORITY`設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。絶対優先度を設定しない場合、TiKV は各リソース グループの`RU_PER_SEC`の値を使用して、各リソース グループの読み取りおよび書き込み要求の優先度を決定します。ストレージレイヤーは、優先度に基づいて優先度キューを使用して要求をスケジュールおよび処理します。 +- TiKV スケジューリング: 必要に応じて絶対優先度[（ `PRIORITY` ）](/information-schema/information-schema-resource-groups.md#examples)を設定できます。異なるリソースは`PRIORITY`設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。絶対優先度を設定しない場合、TiKV は各リソース グループの`RU_PER_SEC`の値を使用して、各リソース グループの読み取りおよび書き込み要求の優先度を決定します。ストレージレイヤーは、優先度に基づいて優先度キューを使用して要求をスケジュールおよび処理します。 バージョン7.4.0以降、リソース制御機能はTiFlashリソースの制御をサポートしています。その原理は、TiDBフロー制御およびTiKVスケジューリングと同様です。 -- TiFlashフロー制御: [TiFlashパイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)を使用すると、 TiFlash はさまざまなクエリの CPU 消費量をより正確に取得し、それを[要求単位数（RU）](#what-is-request-unit-ru)に変換して差し引くことができます。トラフィック制御はトークン バケット アルゴリズムを使用して実装されます。 -- TiFlashスケジューリング: システム リソースが不足している場合、 TiFlash は優先順位に基づいて複数のリソース グループ間でパイプライン タスクをスケジュールします。具体的なロジックは次のとおりです。まず、 TiFlash はリソース グループの`PRIORITY`を評価し、次に CPU 使用率と`RU_PER_SEC`を考慮します。その結果、 `rg1`と`rg2`が同じ`PRIORITY`を持ち、 `RU_PER_SEC`の`rg2`が`rg1`の 2 倍である場合、 `rg2`の CPU 使用率は`rg1`の 2 倍になります。 +- TiFlashフロー制御: [TiFlashパイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)を使用すると、 TiFlash はさまざまなクエリの CPU 消費量をより正確に取得し、それを[要求単位数（RU）](#what-is-request-unit-ru)に変換して差し引くことができます。トラフィック制御はトークン バケット アルゴリズムを使用して実装されます。 +- TiFlashスケジューリング: システム リソースが不足している場合、 TiFlash は優先順位に基づいて複数のリソース グループ間でパイプライン タスクをスケジュールします。具体的なロジックは次のとおりです。まず、 TiFlash はリソース グループの`PRIORITY`を評価し、次に CPU 使用率と`RU_PER_SEC`を考慮します。その結果、 `rg1`と`rg2`が同じ`PRIORITY`を持ち、 `RU_PER_SEC`の`rg2`が`rg1`の 2 倍である場合、 `rg2`の CPU 使用率は`rg1`の 2 倍になります。 -- TiFlashフロー制御: [TiFlashパイプライン実行モデル](http://docs.pingcap.com/tidb/dev/tiflash-pipeline-model)を使用すると、 TiFlash はさまざまなクエリの CPU 消費量をより正確に取得し、それを[要求単位数（RU）](#what-is-request-unit-ru)に変換して差し引くことができます。トラフィック制御はトークン バケット アルゴリズムを使用して実装されます。 -- TiFlashスケジューリング: システム リソースが不足している場合、 TiFlash は優先順位に基づいて複数のリソース グループ間でパイプライン タスクをスケジュールします。具体的なロジックは次のとおりです。まず、 TiFlash はリソース グループの`PRIORITY`を評価し、次に CPU 使用率と`RU_PER_SEC`を考慮します。その結果、 `rg1`と`rg2`が同じ`PRIORITY`を持ち、 `RU_PER_SEC`の`rg2`が`rg1`の 2 倍である場合、 `rg2`の CPU 使用率は`rg1`の 2 倍になります。 +- TiFlashフロー制御: [TiFlashパイプライン実行モデル](http://docs.pingcap.com/tidb/dev/tiflash-pipeline-model)を使用すると、 TiFlash はさまざまなクエリの CPU 消費量をより正確に取得し、それを[要求単位数（RU）](#what-is-request-unit-ru)に変換して差し引くことができます。トラフィック制御はトークン バケット アルゴリズムを使用して実装されます。 +- TiFlashスケジューリング: システム リソースが不足している場合、 TiFlash は優先順位に基づいて複数のリソース グループ間でパイプライン タスクをスケジュールします。具体的なロジックは次のとおりです。まず、 TiFlash はリソース グループの`PRIORITY`を評価し、次に CPU 使用率と`RU_PER_SEC`を考慮します。その結果、 `rg1`と`rg2`が同じ`PRIORITY`を持ち、 `RU_PER_SEC`の`rg2`が`rg1`の 2 倍である場合、 `rg2`の CPU 使用率は`rg1`の 2 倍になります。 バックグラウンドタスクの管理方法や、リソースを大量に消費するクエリ（暴走クエリ）の処理方法については、以下のドキュメントを参照してください。 -- [バックグラウンドタスクの管理にはリソース制御を使用する](/tidb-resource-control-background-tasks.md) -- [想定以上のリソースを消費するクエリ（暴走クエリ）を管理する](/tidb-resource-control-runaway-queries.md) +- [バックグラウンドタスクの管理にはリソース制御を使用する](/tidb-resource-control-background-tasks.md) +- [想定以上のリソースを消費するクエリ（暴走クエリ）を管理する](/tidb-resource-control-runaway-queries.md) ## リソース制御のシナリオ {#scenarios-for-resource-control} @@ -45,16 +45,16 @@ TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能と この機能を使うと、次のことができます。 -- 異なるシステムに存在する複数の中小規模アプリケーションを単一のTiDBクラスタに統合します。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作には影響しません。システムワークロードが低い場合、負荷の高いアプリケーションは設定されたクォータを超えても必要なシステムリソースを割り当てられるため、リソースを最大限に活用できます。 -- すべてのテスト環境を単一のTiDBクラスタに統合するか、より多くのリソースを消費するバッチタスクを単一のリソースグループにまとめるかを選択できます。これにより、ハードウェア利用率を向上させ、運用コストを削減しながら、重要なアプリケーションが常に必要なリソースを確保できるようになります。 -- システム内に複数のワークロードが存在する場合、異なるワークロードを別々のリソースグループに割り当てることができます。リソース制御機能を使用することで、トランザクションアプリケーションの応答時間がデータ分析やバッチ処理アプリケーションの影響を受けないようにすることができます。 -- クラスターで予期しないSQLパフォーマンスの問題が発生した場合、SQLバインディングとリソースグループを併用することで、SQLステートメントのリソース消費を一時的に制限できます。 +- 異なるシステムに存在する複数の中小規模アプリケーションを単一のTiDBクラスタに統合します。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作には影響しません。システムワークロードが低い場合、負荷の高いアプリケーションは設定されたクォータを超えても必要なシステムリソースを割り当てられるため、リソースを最大限に活用できます。 +- すべてのテスト環境を単一のTiDBクラスタに統合するか、より多くのリソースを消費するバッチタスクを単一のリソースグループにまとめるかを選択できます。これにより、ハードウェア利用率を向上させ、運用コストを削減しながら、重要なアプリケーションが常に必要なリソースを確保できるようになります。 +- システム内に複数のワークロードが存在する場合、異なるワークロードを別々のリソースグループに割り当てることができます。リソース制御機能を使用することで、トランザクションアプリケーションの応答時間がデータ分析やバッチ処理アプリケーションの影響を受けないようにすることができます。 +- クラスターで予期しないSQLパフォーマンスの問題が発生した場合、SQLバインディングとリソースグループを併用することで、SQLステートメントのリソース消費を一時的に制限できます。 さらに、リソース制御機能を合理的に活用することで、クラスタ数を削減し、運用・保守の難易度を下げ、管理コストを削減することができます。 > **Note:** > -> - リソース管理の有効性を評価するには、クラスタを独立したコンピューティングノードとストレージノードにデプロイすることをお勧めします。 `tiup playground`で作成されたデプロイメントでは、リソースがインスタンス間で共有されるため、スケジューリングやその他のクラスタのリソースに依存する機能が正しく動作しない場合があります。 +> - リソース管理の有効性を評価するには、クラスタを独立したコンピューティングノードとストレージノードにデプロイすることをお勧めします。 `tiup playground`で作成されたデプロイメントでは、リソースがインスタンス間で共有されるため、スケジューリングやその他のクラスタのリソースに依存する機能が正しく動作しない場合があります。 ## 制限事項 {#limitations} @@ -68,27 +68,27 @@ TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能と > **Note:** > -> - 各書き込み操作は最終的にすべてのレプリカに複製されます（デフォルトでは、TiKVには3つのレプリカがあります）。各複製操作は、それぞれ異なる書き込み操作として扱われます。 -> - 上記の表には、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時間です。 +> - 各書き込み操作は最終的にすべてのレプリカに複製されます（デフォルトでは、TiKVには3つのレプリカがあります）。各複製操作は、それぞれ異なる書き込み操作として扱われます。 +> - 上記の表には、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} リソース制御機能では、以下のシステム変数またはパラメータが導入されます。 -- TiDB: [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660)システム変数を使用して、リソースグループのフロー制御を有効にするかどうかを制御できます。 +- TiDB: [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660)システム変数を使用して、リソースグループのフロー制御を有効にするかどうかを制御できます。 -- TiKV: [`resource-control.enabled`](/tikv-configuration-file.md#resource-control)パラメータを使用すると、リソース グループに基づいてリクエスト スケジューリングを使用するかどうかを制御できます。 -- TiFlash: TiFlashリソース制御を有効にするかどうかは、 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660)システム変数と[`enable_resource_control`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file)構成項目（v7.4.0で導入）を使用して制御できます。 +- TiKV: [`resource-control.enabled`](/tikv-configuration-file.md#resource-control)パラメータを使用すると、リソース グループに基づいてリクエスト スケジューリングを使用するかどうかを制御できます。 +- TiFlash: TiFlashリソース制御を有効にするかどうかは、 [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660)システム変数と[`enable_resource_control`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file)構成項目（v7.4.0で導入）を使用して制御できます。 -- TiKV: TiDB Self-Managed では、 `resource-control.enabled`パラメータを使用して、リソースグループのクォータに基づいてリクエストスケジューリングを使用するかどうかを制御できます。TiDB Cloudでは、 `resource-control.enabled`パラメータのデフォルト値は`true`であり、動的な変更はサポートされていません。 -- TiFlash: TiDB Self-Managedの場合、 `tidb_enable_resource_control`システム変数と`enable_resource_control`構成項目 (v7.4.0 で導入) を使用して、 TiFlashリソース制御を有効にするかどうかを制御できます。 +- TiKV: TiDB Self-Managed では、 `resource-control.enabled`パラメータを使用して、リソースグループのクォータに基づいてリクエストスケジューリングを使用するかどうかを制御できます。TiDB Cloudでは、 `resource-control.enabled`パラメータのデフォルト値は`true`であり、動的な変更はサポートされていません。 +- TiFlash: TiDB Self-Managedの場合、 `tidb_enable_resource_control`システム変数と`enable_resource_control`構成項目 (v7.4.0 で導入) を使用して、 TiFlashリソース制御を有効にするかどうかを制御できます。 @@ -123,8 +123,8 @@ TiDB v7.0.0以降、 `tidb_enable_resource_control`と`resource-control.enabled` リソース計画を行う前に、クラスタ全体の容量を把握しておく必要があります。TiDB では、クラスタ容量を推定するための[`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md)ステートメントが提供されています。以下のいずれかの方法を使用できます。 -- [実際の作業負荷に基づいて容量を推定する](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload) -- [ハードウェアの導入状況に基づいて容量を推定する](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-hardware-deployment) +- [実際の作業負荷に基づいて容量を推定する](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload) +- [ハードウェアの導入状況に基づいて容量を推定する](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-hardware-deployment) TiDB Dashboardで[リソースマネージャーページ](/dashboard/dashboard-resource-manager.md)を表示できます。詳細については、 [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md#methods-for-estimating-capacity)を参照してください。 @@ -152,19 +152,19 @@ TiDB Cloud Dedicated では、`CALIBRATE RESOURCE` ステートメントはサ 以下は、リソースグループを作成する方法の例です。 -1. リソースグループ`rg1`を作成します。リソース制限は毎秒 500 RU で、このリソースグループ内のアプリケーションはリソースを超過することができます。 +1. リソースグループ`rg1`を作成します。リソース制限は毎秒 500 RU で、このリソースグループ内のアプリケーションはリソースを超過することができます。 ```sql CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 BURSTABLE; ``` -2. リソースグループ`rg2`を作成します。RU バックフィルレートは毎秒 600 RU で、このリソースグループ内のアプリケーションがリソースをオーバーランすることを許可しません。 +2. リソースグループ`rg2`を作成します。RU バックフィルレートは毎秒 600 RU で、このリソースグループ内のアプリケーションがリソースをオーバーランすることを許可しません。 ```sql CREATE RESOURCE GROUP IF NOT EXISTS rg2 RU_PER_SEC = 600; ``` -3. 絶対優先度を`HIGH`に設定してリソースグループ`rg3`を作成します。現在の絶対優先度は`LOW|MEDIUM|HIGH`をサポートしています。デフォルト値は`MEDIUM`です。 +3. 絶対優先度を`HIGH`に設定してリソースグループ`rg3`を作成します。現在の絶対優先度は`LOW|MEDIUM|HIGH`をサポートしています。デフォルト値は`MEDIUM`です。 ```sql CREATE RESOURCE GROUP IF NOT EXISTS rg3 RU_PER_SEC = 100 PRIORITY = HIGH; @@ -174,9 +174,9 @@ TiDB Cloud Dedicated では、`CALIBRATE RESOURCE` ステートメントはサ TiDBは、以下の3つのレベルのリソースグループ設定をサポートしています。 -- ユーザーレベル。[`CREATE USER`](/sql-statements/sql-statement-create-user.md)または[`ALTER USER`](/sql-statements/sql-statement-alter-user.md#modify-the-resource-group-bound-to-the-user)ステートメントを使用して、ユーザーを特定のリソースグループにバインドします。ユーザーがリソースグループにバインドされると、そのユーザーが作成したセッションは自動的に対応するリソースグループにバインドされます。 -- セッションレベル。[`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)を使用して、現在のセッションのリソースグループを設定します。 -- ステートメントレベル。[`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name)オプティマイザヒントを使用して、現在のステートメントのリソースグループを設定します。 +- ユーザーレベル。[`CREATE USER`](/sql-statements/sql-statement-create-user.md)または[`ALTER USER`](/sql-statements/sql-statement-alter-user.md#modify-the-resource-group-bound-to-the-user)ステートメントを使用して、ユーザーを特定のリソースグループにバインドします。ユーザーがリソースグループにバインドされると、そのユーザーが作成したセッションは自動的に対応するリソースグループにバインドされます。 +- セッションレベル。[`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)を使用して、現在のセッションのリソースグループを設定します。 +- ステートメントレベル。[`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name)オプティマイザヒントを使用して、現在のステートメントのリソースグループを設定します。 #### ユーザーをリソースグループにバインドする {#bind-users-to-a-resource-group} @@ -198,8 +198,8 @@ ALTER USER usr2 RESOURCE GROUP rg2; > **Note:** > -> - `CREATE USER`または`ALTER USER`を使用してユーザーをリソース グループにバインドすると、その設定はユーザーの既存のセッションには適用されず、ユーザーの新しいセッションにのみ適用されます。 -> - TiDB はクラスタ初期化時に`default`リソース グループを自動的に作成します。このリソース グループの`RU_PER_SEC`のデフォルト値は`UNLIMITED` ( `INT`型の最大値、つまり`2147483647`に相当) で、 `BURSTABLE`モードです。リソース グループにバインドされていないステートメントは、自動的にこのリソース グループにバインドされます。このリソース グループは削除をサポートしていませんが、RU の設定を変更することはできます。 +> - `CREATE USER`または`ALTER USER`を使用してユーザーをリソース グループにバインドすると、その設定はユーザーの既存のセッションには適用されず、ユーザーの新しいセッションにのみ適用されます。 +> - TiDB はクラスタ初期化時に`default`リソース グループを自動的に作成します。このリソース グループの`RU_PER_SEC`のデフォルト値は`UNLIMITED` ( `INT`型の最大値、つまり`2147483647`に相当) で、 `BURSTABLE`モードです。リソース グループにバインドされていないステートメントは、自動的にこのリソース グループにバインドされます。このリソース グループは削除をサポートしていませんが、RU の設定を変更することはできます。 リソース グループからユーザーのバインドを解除するには、次のようにしてユーザーを`default`グループに再度バインドするだけです。 @@ -237,29 +237,29 @@ SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10; -1. リソース制御機能を無効にするには、次のステートメントを実行してください。 +1. リソース制御機能を無効にするには、次のステートメントを実行してください。 ```sql SET GLOBAL tidb_enable_resource_control = 'OFF'; ``` -2. リソース グループの RU に基づくスケジューリングを無効にするには、TiKV パラメータ[`resource-control.enabled`](/tikv-configuration-file.md#resource-control)を`false`に設定します。 +2. リソース グループの RU に基づくスケジューリングを無効にするには、TiKV パラメータ[`resource-control.enabled`](/tikv-configuration-file.md#resource-control)を`false`に設定します。 -3. TiFlashのリソース制御を無効にするには、 TiFlash構成項目[`enable_resource_control`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) `false`に設定します。 +3. TiFlashのリソース制御を無効にするには、 TiFlash構成項目[`enable_resource_control`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) `false`に設定します。 -1. リソース制御機能を無効にするには、次のステートメントを実行してください。 +1. リソース制御機能を無効にするには、次のステートメントを実行してください。 ```sql SET GLOBAL tidb_enable_resource_control = 'OFF'; ``` -2. TiDB Self-Managed では、 `resource-control.enabled`パラメータを使用して、リソースグループのクォータに基づいてリクエストスケジューリングを使用するかどうかを制御できます。TiDB Cloudでは、 `resource-control.enabled`パラメータのデフォルト値は`true`であり、動的な変更はサポートされていません。TiDB Cloud Dedicatedクラスタでこれを無効にする必要がある場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 +2. TiDB Self-Managed では、 `resource-control.enabled`パラメータを使用して、リソースグループのクォータに基づいてリクエストスケジューリングを使用するかどうかを制御できます。TiDB Cloudでは、 `resource-control.enabled`パラメータのデフォルト値は`true`であり、動的な変更はサポートされていません。TiDB Cloud Dedicatedクラスタでこれを無効にする必要がある場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 -3. TiDB Self-Managed では、 `enable_resource_control`設定項目を使用して、 TiFlashリソース制御を有効にするかどうかを制御できます。TiDB Cloudでは、 `enable_resource_control`パラメータのデフォルト値は`true`であり、動的な変更はサポートされていません。TiDB Cloud Dedicatedクラスタでこれを無効にする必要がある場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 +3. TiDB Self-Managed では、 `enable_resource_control`設定項目を使用して、 TiFlashリソース制御を有効にするかどうかを制御できます。TiDB Cloudでは、 `enable_resource_control`パラメータのデフォルト値は`true`であり、動的な変更はサポートされていません。TiDB Cloud Dedicatedクラスタでこれを無効にする必要がある場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 @@ -271,10 +271,10 @@ RUの消費量に関する情報をご覧いただけます。 SQL文のRU消費量は、以下の方法で確認できます。 -- システム変数`tidb_last_query_info` -- `EXPLAIN ANALYZE` -- スロークエリとそれに対応するシステムテーブル -- `statements_summary` +- システム変数`tidb_last_query_info` +- `EXPLAIN ANALYZE` +- スロークエリとそれに対応するシステムテーブル +- `statements_summary` #### システム変数`tidb_last_query_info`を照会することで、前回のSQL実行で消費されたRUを表示する。 {#view-the-rus-consumed-by-the-last-sql-execution-by-querying-the-system-variable-tidb-last-query-info} @@ -282,7 +282,7 @@ TiDBはシステム変数[`tidb_last_query_info`](/system-variables.md#tidb_last 例： -1. `UPDATE`ステートメントを実行します。 +1. `UPDATE`ステートメントを実行します。 ```sql UPDATE sbtest.sbtest1 SET k = k + 1 WHERE id = 1; @@ -293,7 +293,7 @@ TiDBはシステム変数[`tidb_last_query_info`](/system-variables.md#tidb_last Rows matched: 1 Changed: 1 Warnings: 0 ``` -2. 最後に実行されたステートメントの情報を表示するには、システム変数`tidb_last_query_info`を照会します。 +2. 最後に実行されたステートメントの情報を表示するには、システム変数`tidb_last_query_info`を照会します。 ```sql SELECT @@tidb_last_query_info; @@ -389,24 +389,24 @@ TiKVは、Grafanaの**TiKV**ダッシュボードに、さまざまなリソー ## FAQ {#faq} -1. リソースグループを使用しない場合、リソース制御を無効にする必要がありますか？ +1. リソースグループを使用しない場合、リソース制御を無効にする必要がありますか？ いいえ。リソースグループを指定しないユーザーは、リソースが無制限の`default`リソースグループに自動的に割り当てられます。すべてのユーザーが`default`リソースグループに属している場合、リソース割り当て方法は、リソース制御が無効になっている場合と同じです。 -2. データベースユーザーは複数のリソースグループに紐付けられますか？ +2. データベースユーザーは複数のリソースグループに紐付けられますか？ いいえ。データベースユーザーは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` ）がシステム容量を超えた場合、どうなりますか？ +3. すべてのリソースグループの合計リソース割り当て（ `RU_PER_SEC` ）がシステム容量を超えた場合、どうなりますか？ TiDB は、リソース グループを作成する際に容量を検証しません。システムに十分な利用可能なリソースがあれば、TiDB は各リソース グループのリソース要件を満たすことができます。システム リソースが制限を超えると、TiDB は優先度の高いリソース グループからの要求を満たすことを優先します。同じ優先度の要求すべてを満たすことができない場合、TiDB はリソース割り当て ( `RU_PER_SEC` ) に従ってリソースを比例的に割り当てます。 ## 参照 {#see-also} -- [リソースグループを作成する](/sql-statements/sql-statement-create-resource-group.md) -- [アルター・リソース・グループ](/sql-statements/sql-statement-alter-resource-group.md) -- [リソースグループを削除する](/sql-statements/sql-statement-drop-resource-group.md) -- [リソースグループRFC](https://github.com/pingcap/tidb/blob/release-8.5/docs/design/2022-11-25-global-resource-control.md) +- [リソースグループを作成する](/sql-statements/sql-statement-create-resource-group.md) +- [アルター・リソース・グループ](/sql-statements/sql-statement-alter-resource-group.md) +- [リソースグループを削除する](/sql-statements/sql-statement-drop-resource-group.md) +- [リソースグループRFC](https://github.com/pingcap/tidb/blob/release-8.5/docs/design/2022-11-25-global-resource-control.md) ## 関連リソース {#related-resources} diff --git a/tidb-resource-control-runaway-queries.md b/tidb-resource-control-runaway-queries.md index 85820fb3f22e6..2e1ffe55591ea 100644 --- a/tidb-resource-control-runaway-queries.md +++ b/tidb-resource-control-runaway-queries.md @@ -11,8 +11,8 @@ summary: リソース管理機能を使用して、リソースを過剰に消 ランナウェイクエリとは、予想よりも多くの時間やリソースを消費するクエリです。以下では、ランナウェイクエリを管理する機能を説明するために「ランナ**ウェイクエリ」という**用語を使用します。 -- バージョン7.2.0以降、リソース制御機能にランナウェイクエリの管理機能が導入されました。リソースグループに対してランナウェイクエリを特定するための条件を設定し、ランナウェイクエリによるリソースの枯渇や他のクエリへの影響を防ぐためのアクションを自動的に実行できます。[`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md)または[`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md)に`QUERY_LIMIT`フィールドを含めることで、リソースグループのランナウェイクエリを管理できます。 -- バージョン7.3.0以降、リソース制御機能にランナウェイ・ウォッチの手動管理が導入され、特定のSQL文またはダイジェストに対するランナウェイ・クエリを迅速に特定できるようになりました。ステートメント[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)を実行することで、リソースグループ内のランナウェイ・クエリ・ウォッチリストを手動で管理できます。 +- バージョン7.2.0以降、リソース制御機能にランナウェイクエリの管理機能が導入されました。リソースグループに対してランナウェイクエリを特定するための条件を設定し、ランナウェイクエリによるリソースの枯渇や他のクエリへの影響を防ぐためのアクションを自動的に実行できます。[`CREATE RESOURCE GROUP`](/sql-statements/sql-statement-create-resource-group.md)または[`ALTER RESOURCE GROUP`](/sql-statements/sql-statement-alter-resource-group.md)に`QUERY_LIMIT`フィールドを含めることで、リソースグループのランナウェイクエリを管理できます。 +- バージョン7.3.0以降、リソース制御機能にランナウェイ・ウォッチの手動管理が導入され、特定のSQL文またはダイジェストに対するランナウェイ・クエリを迅速に特定できるようになりました。ステートメント[`QUERY WATCH`](/sql-statements/sql-statement-query-watch.md)を実行することで、リソースグループ内のランナウェイ・クエリ・ウォッチリストを手動で管理できます。 リソース制御機能の詳細については、 [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md)を参照してください。 @@ -20,24 +20,24 @@ summary: リソース管理機能を使用して、リソースを過剰に消 クエリが次のいずれかの制限を超えると、ランナウェイ クエリとして識別されます。 -- `EXEC_ELAPSED` : クエリ実行時間が制限を超えていないかどうかを確認します。このルールは、読み取りおよび書き込みDMLステートメントに適用されます。 -- `PROCESSED_KEYS` :コプロセッサーによって処理されるキーの数が制限を超えていないかどうかを確認します。このルールは読み取りステートメントにのみ適用されます。 -- `RU` : ステートメントによって消費される読み取りおよび書き込み RU の合計数が制限を超えているかどうかを確認します。このルールは読み取りステートメントにのみ適用されます。 +- `EXEC_ELAPSED` : クエリ実行時間が制限を超えていないかどうかを確認します。このルールは、読み取りおよび書き込みDMLステートメントに適用されます。 +- `PROCESSED_KEYS` :コプロセッサーによって処理されるキーの数が制限を超えていないかどうかを確認します。このルールは読み取りステートメントにのみ適用されます。 +- `RU` : ステートメントによって消費される読み取りおよび書き込み RU の合計数が制限を超えているかどうかを確認します。このルールは読み取りステートメントにのみ適用されます。 サポートされている操作（ `ACTION` ）： -- `DRYRUN` : アクションは実行されません。ランナウェイクエリのレコードが追加されます。これは主に、条件設定が適切かどうかを観察するために使用されます。 -- `COOLDOWN` : クエリの実行優先度が最低レベルに下げられます。クエリは最低優先度で実行を継続し、他の操作のリソースを占有しません。 -- `KILL` : 識別されたクエリは自動的に終了され、エラー`Query execution was interrupted, identified as runaway query`が報告されます。 -- `SWITCH_GROUP` : v8.4.0 で導入されたこのパラメータは、指定されたクエリを指定されたリソースグループに切り替えて実行を継続します。このクエリが完了すると、後続の SQL 文は元のリソースグループで実行されます。指定されたリソースグループが存在しない場合、クエリは元のリソースグループに残ります。 +- `DRYRUN` : アクションは実行されません。ランナウェイクエリのレコードが追加されます。これは主に、条件設定が適切かどうかを観察するために使用されます。 +- `COOLDOWN` : クエリの実行優先度が最低レベルに下げられます。クエリは最低優先度で実行を継続し、他の操作のリソースを占有しません。 +- `KILL` : 識別されたクエリは自動的に終了され、エラー`Query execution was interrupted, identified as runaway query`が報告されます。 +- `SWITCH_GROUP` : v8.4.0 で導入されたこのパラメータは、指定されたクエリを指定されたリソースグループに切り替えて実行を継続します。このクエリが完了すると、後続の SQL 文は元のリソースグループで実行されます。指定されたリソースグループが存在しない場合、クエリは元のリソースグループに残ります。 システムリソースを枯渇させる過剰な同時実行のランナウェイクエリを回避するために、リソース制御機能では、ランナウェイクエリを迅速に識別して分離できる迅速な識別メカニズムを導入しています。 `WATCH`句を通じてこの機能を使用できます。クエリがランナウェイクエリとして識別されると、このメカニズムはクエリの一致する特徴 ( `WATCH`後のパラメータで定義) を抽出します。次の期間 ( `DURATION`で定義) に、ランナウェイクエリの一致する特徴が監視リストに追加され、TiDB インスタンスはクエリを監視リストと照合します。一致したクエリは、条件によって識別されるのを待たずに、直接ランナウェイクエリとしてマークされ、対応するアクションに従って分離されます。 `KILL`操作はクエリを終了し、エラー`Quarantined and interrupted because of being in runaway watch list`を報告します。 `WATCH`素早く識別するために一致させる方法は 3 つあります。 -- `EXACT` 、まったく同じ SQL テキストを持つ SQL ステートメントのみが迅速に識別されることを示します。 -- `SIMILAR` 、同じパターンを持つすべての SQL ステートメントが SQL ダイジェストに一致し、リテラル値が無視されることを示します。 -- `PLAN` 、同じパターンを持つすべての SQL ステートメントがプラン ダイジェストに一致することを示します。 +- `EXACT` 、まったく同じ SQL テキストを持つ SQL ステートメントのみが迅速に識別されることを示します。 +- `SIMILAR` 、同じパターンを持つすべての SQL ステートメントが SQL ダイジェストに一致し、リテラル値が無視されることを示します。 +- `PLAN` 、同じパターンを持つすべての SQL ステートメントがプラン ダイジェストに一致することを示します。 `WATCH`の`DURATION`オプションは識別項目の有効期間を示し、デフォルトでは無期限です。 @@ -59,19 +59,19 @@ summary: リソース管理機能を使用して、リソースを過剰に消 ## 例 {#examples} -1. 1 秒あたり 500 RU のクォータを持つリソース グループ`rg1`を作成し、60 秒を超えるクエリをランナウェイ クエリとして定義し、ランナウェイ クエリの優先度を下げます。 +1. 1 秒あたり 500 RU のクォータを持つリソース グループ`rg1`を作成し、60 秒を超えるクエリをランナウェイ クエリとして定義し、ランナウェイ クエリの優先度を下げます。 ```sql CREATE RESOURCE GROUP IF NOT EXISTS rg1 RU_PER_SEC = 500 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=COOLDOWN); ``` -2. `rg1`リソース グループを変更して、ランナウェイ クエリを終了し、次の 10 分以内に、同じパターンのクエリをランナウェイ クエリとして直ちにマークします。 +2. `rg1`リソース グループを変更して、ランナウェイ クエリを終了し、次の 10 分以内に、同じパターンのクエリをランナウェイ クエリとして直ちにマークします。 ```sql ALTER RESOURCE GROUP rg1 QUERY_LIMIT=(EXEC_ELAPSED='60s', ACTION=KILL, WATCH=SIMILAR DURATION='10m'); ``` -3. ランナウェイ クエリ チェックをキャンセルするには、 `rg1`リソース グループを変更します。 +3. ランナウェイ クエリ チェックをキャンセルするには、 `rg1`リソース グループを変更します。 ```sql ALTER RESOURCE GROUP rg1 QUERY_LIMIT=NULL; @@ -83,40 +83,40 @@ summary: リソース管理機能を使用して、リソースを過剰に消 パラメータは次のとおりです。 -- `RESOURCE GROUP`リソースグループを指定します。このステートメントによって追加されたランナウェイクエリの一致する特徴は、リソースグループのウォッチリストに追加されます。このパラメータは省略可能です。省略した場合、 `default`リソースグループに適用されます。 +- `RESOURCE GROUP`リソースグループを指定します。このステートメントによって追加されたランナウェイクエリの一致する特徴は、リソースグループのウォッチリストに追加されます。このパラメータは省略可能です。省略した場合、 `default`リソースグループに適用されます。 -- `ACTION`の意味は`QUERY LIMIT`と同じです。このパラメータは省略可能です。省略した場合、識別後の対応するアクションは、リソースグループ内の`QUERY LIMIT`で設定された`ACTION`を採用し、 `QUERY LIMIT`設定によってアクションは変更されません。リソースグループ内に`ACTION`が設定されていない場合は、エラーが報告されます。 +- `ACTION`の意味は`QUERY LIMIT`と同じです。このパラメータは省略可能です。省略した場合、識別後の対応するアクションは、リソースグループ内の`QUERY LIMIT`で設定された`ACTION`を採用し、 `QUERY LIMIT`設定によってアクションは変更されません。リソースグループ内に`ACTION`が設定されていない場合は、エラーが報告されます。 -- `QueryWatchTextOption`パラメータには、 `SQL DIGEST` 、 `PLAN DIGEST` 、 `SQL TEXT` 3 つのオプションがあります。 - - `SQL DIGEST`は`SIMILAR`と同じです。以下のパラメータは、文字列、ユーザー定義変数、または文字列を返すその他の式を受け入れます。文字列の長さは64文字でなければなりません。これはTiDBのダイジェスト定義と同じです。 - - `PLAN DIGEST`は`PLAN`と同じです。次のパラメータはダイジェスト文字列です。 - - `SQL TEXT`入力SQLを生の文字列（ `EXACT` ）として一致させるか、次のパラメータに応じて`SQL DIGEST` （ `SIMILAR` ）または`PLAN DIGEST` （ `PLAN` ）に解析してコンパイルします。 +- `QueryWatchTextOption`パラメータには、 `SQL DIGEST` 、 `PLAN DIGEST` 、 `SQL TEXT` 3 つのオプションがあります。 + - `SQL DIGEST`は`SIMILAR`と同じです。以下のパラメータは、文字列、ユーザー定義変数、または文字列を返すその他の式を受け入れます。文字列の長さは64文字でなければなりません。これはTiDBのダイジェスト定義と同じです。 + - `PLAN DIGEST`は`PLAN`と同じです。次のパラメータはダイジェスト文字列です。 + - `SQL TEXT`入力SQLを生の文字列（ `EXACT` ）として一致させるか、次のパラメータに応じて`SQL DIGEST` （ `SIMILAR` ）または`PLAN DIGEST` （ `PLAN` ）に解析してコンパイルします。 -- デフォルトのリソース グループのランナウェイ クエリ監視リストに一致する機能を追加します (事前にデフォルトのリソース グループに`QUERY LIMIT`設定する必要があります)。 +- デフォルトのリソース グループのランナウェイ クエリ監視リストに一致する機能を追加します (事前にデフォルトのリソース グループに`QUERY LIMIT`設定する必要があります)。 ```sql QUERY WATCH ADD ACTION KILL SQL TEXT EXACT TO 'select * from test.t2'; ``` -- SQLをSQLダイジェストに解析することで、リソースグループ`rg1`のランナウェイクエリ監視リストに一致する機能を追加します。`ACTION`が指定されていない場合は、リソースグループ`rg1`に既に設定されているオプション`ACTION`が使用されます。 +- SQLをSQLダイジェストに解析することで、リソースグループ`rg1`のランナウェイクエリ監視リストに一致する機能を追加します。`ACTION`が指定されていない場合は、リソースグループ`rg1`に既に設定されているオプション`ACTION`が使用されます。 ```sql QUERY WATCH ADD RESOURCE GROUP rg1 SQL TEXT SIMILAR TO 'select * from test.t2'; ``` -- SQL を SQL ダイジェストに解析して、 `rg1`リソース グループのランナウェイ クエリ監視リストに一致する機能を追加し、 `ACTION` `SWITCH_GROUP(rg2)`として指定します。 +- SQL を SQL ダイジェストに解析して、 `rg1`リソース グループのランナウェイ クエリ監視リストに一致する機能を追加し、 `ACTION` `SWITCH_GROUP(rg2)`として指定します。 ```sql QUERY WATCH ADD RESOURCE GROUP rg1 ACTION SWITCH_GROUP(rg2) SQL TEXT SIMILAR TO 'select * from test.t2'; ``` -- `PLAN DIGEST`を使用して`rg1`リソース グループのランナウェイ クエリ監視リストに一致する機能を追加し、 `ACTION` `KILL`として指定します。 +- `PLAN DIGEST`を使用して`rg1`リソース グループのランナウェイ クエリ監視リストに一致する機能を追加し、 `ACTION` `KILL`として指定します。 ```sql QUERY WATCH ADD RESOURCE GROUP rg1 ACTION KILL PLAN DIGEST 'd08bc323a934c39dc41948b0a073725be3398479b6fa4f6dd1db2a9b115f7f57'; ``` -- `INFORMATION_SCHEMA.RUNAWAY_WATCHES`クエリしてウォッチ アイテム ID を取得し、ウォッチ アイテムを削除します。 +- `INFORMATION_SCHEMA.RUNAWAY_WATCHES`クエリしてウォッチ アイテム ID を取得し、ウォッチ アイテムを削除します。 ```sql SELECT * from information_schema.runaway_watches ORDER BY id\G @@ -144,7 +144,7 @@ summary: リソース管理機能を使用して、リソースを過剰に消 ランナウェイ クエリに関する詳細情報は、次のシステム テーブルおよび`INFORMATION_SCHEMA`から取得できます。 -- `mysql.tidb_runaway_queries`テーブルには、過去 7 日間に特定されたすべてのランナウェイクエリの履歴レコードが含まれています。例として、1 つの行を見てみましょう。 +- `mysql.tidb_runaway_queries`テーブルには、過去 7 日間に特定されたすべてのランナウェイクエリの履歴レコードが含まれています。例として、1 つの行を見てみましょう。 ```sql MySQL [(none)]> SELECT * FROM mysql.tidb_runaway_queries LIMIT 1\G @@ -162,10 +162,10 @@ summary: リソース管理機能を使用して、リソースを過剰に消 フィールドの説明: - - `start_time` 、ランナウェイ クエリが識別された時間を示します。 - - `repeats` 、 `start_time`以降にランナウェイクエリが識別された回数を示します。 - - `match_type` 、ランナウェイクエリの識別方法を示します。値は次のいずれかになります。 - - `identify`ランナウェイクエリの条件に一致することを意味します。 - - `watch` 、監視リスト内のクイック識別ルールに一致することを意味します。 + - `start_time` 、ランナウェイ クエリが識別された時間を示します。 + - `repeats` 、 `start_time`以降にランナウェイクエリが識別された回数を示します。 + - `match_type` 、ランナウェイクエリの識別方法を示します。値は次のいずれかになります。 + - `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 734d2719a403b..7c425b5a740f3 100644 --- a/tidb-rowid.md +++ b/tidb-rowid.md @@ -11,15 +11,15 @@ summary: _tidb_rowid`とは何か、いつ利用できるのか、そして安 > **Warning:** > -> - `_tidb_rowid`常にグローバルに一意であるとは限らないことに注意してください。クラスター化インデックスを使用しないパーティションテーブルの場合、 `ALTER TABLE ... EXCHANGE PARTITION`を実行すると、異なるパーティション間で`_tidb_rowid`値が重複する可能性があります。 -> - 安定した一意の識別子が必要な場合は、 `_tidb_rowid`に依存するのではなく、明示的な主キーを定義して使用してください。 +> - `_tidb_rowid`常にグローバルに一意であるとは限らないことに注意してください。クラスター化インデックスを使用しないパーティションテーブルの場合、 `ALTER TABLE ... EXCHANGE PARTITION`を実行すると、異なるパーティション間で`_tidb_rowid`値が重複する可能性があります。 +> - 安定した一意の識別子が必要な場合は、 `_tidb_rowid`に依存するのではなく、明示的な主キーを定義して使用してください。 ## `_tidb_rowid`が利用可能な場合 {#when-tidb-rowid-is-available} TiDBでは、テーブルが一意の行識別子としてクラスター化された主キーを使用しない場合、各行を識別するために`_tidb_rowid`を使用します。実際には、これは次のタイプのテーブルが`_tidb_rowid`を使用することを意味します。 -- 主キーのないテーブル -- 主キーが明示的に`NONCLUSTERED`と定義されているテーブル +- 主キーのないテーブル +- 主キーが明示的に`NONCLUSTERED`と定義されているテーブル `_tidb_rowid`は、クラスター化インデックスを使用するテーブル (つまり、主キーが`CLUSTERED`として定義されているテーブル。主キーが単一列か複合主キーかは関係ありません) では使用できません。 @@ -120,11 +120,11 @@ SELECT _tidb_rowid, a, b FROM t WHERE _tidb_rowid = 100; ## 制限 {#restrictions} -- `_tidb_rowid`という名前のユーザー列を作成することはできません。 -- 既存のユーザー列の名前を`_tidb_rowid`に変更することはできません。 -- `_tidb_rowid`はTiDBの内部列です。ビジネス上の主キーや長期的な識別子として扱わないでください。 -- パーティション化された非クラスター化テーブルでは、 `_tidb_rowid`の値はパーティション間で一意であることが保証されません。`EXCHANGE PARTITION`を実行した後、異なるパーティションに同じ`_tidb_rowid`の値を持つ行が含まれる可能性があります。 -- `_tidb_rowid`存在するかどうかは、テーブルのスキーマによって異なります。クラスター化インデックスを持つテーブルの場合は、行識別子として主キーを使用してください。 +- `_tidb_rowid`という名前のユーザー列を作成することはできません。 +- 既存のユーザー列の名前を`_tidb_rowid`に変更することはできません。 +- `_tidb_rowid`はTiDBの内部列です。ビジネス上の主キーや長期的な識別子として扱わないでください。 +- パーティション化された非クラスター化テーブルでは、 `_tidb_rowid`の値はパーティション間で一意であることが保証されません。`EXCHANGE PARTITION`を実行した後、異なるパーティションに同じ`_tidb_rowid`の値を持つ行が含まれる可能性があります。 +- `_tidb_rowid`存在するかどうかは、テーブルのスキーマによって異なります。クラスター化インデックスを持つテーブルの場合は、行識別子として主キーを使用してください。 ## ホットスポットの問題に対処する {#address-hotspot-issues} @@ -145,13 +145,13 @@ CREATE TABLE t ( ## 関連する記述と変数 {#related-statements-and-variables} -- [`SHOW TABLE NEXT_ROW_ID`](/sql-statements/sql-statement-show-table-next-rowid.md) ：TiDBが次に割り当てる行IDを示します -- [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md) ：ホットスポットを減らすために暗黙の行IDをシャーディングする -- [`Clustered Indexes`](/clustered-indexes.md) : テーブルが`_tidb_rowid`の代わりに主キーを使用する場合を説明します -- [`tidb_opt_write_row_id`](/system-variables.md#tidb_opt_write_row_id) ： `_tidb_rowid`への書き込みを許可するかどうかを制御します +- [`SHOW TABLE NEXT_ROW_ID`](/sql-statements/sql-statement-show-table-next-rowid.md) ：TiDBが次に割り当てる行IDを示します +- [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md) ：ホットスポットを減らすために暗黙の行IDをシャーディングする +- [`Clustered Indexes`](/clustered-indexes.md) : テーブルが`_tidb_rowid`の代わりに主キーを使用する場合を説明します +- [`tidb_opt_write_row_id`](/system-variables.md#tidb_opt_write_row_id) ： `_tidb_rowid`への書き込みを許可するかどうかを制御します ## 関連項目 {#see-also} -- [`CREATE TABLE`](/sql-statements/sql-statement-create-table.md) -- [`AUTO_INCREMENT`](/auto-increment.md) -- [非トランザクションDML](/non-transactional-dml.md) +- [`CREATE TABLE`](/sql-statements/sql-statement-create-table.md) +- [`AUTO_INCREMENT`](/auto-increment.md) +- [非トランザクションDML](/non-transactional-dml.md) diff --git a/tidb-scheduling.md b/tidb-scheduling.md index c028242642856..27c02595bb1cb 100644 --- a/tidb-scheduling.md +++ b/tidb-scheduling.md @@ -13,19 +13,19 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン ここで、次のような状況について考えてみましょう。 -- ストレージスペースを効率的に利用するには、同じリージョンの複数のレプリカを、リージョンのサイズに応じて異なるノードに適切に分散する必要があります。 -- 複数のデータセンター トポロジの場合、1 つのデータセンターに障害が発生すると、すべてのリージョンの 1 つのレプリカのみが失敗します。 -- 新しい TiKV ストアが追加されると、そのストアにデータを再バランスさせることができます。 -- TiKV ストアに障害が発生した場合、PD は次のことを考慮する必要があります。 - - 障害が発生したストアの回復時間。 - - 短い場合（たとえば、サービスが再起動された場合）、スケジュールが必要かどうか。 - - 長時間かかる場合（例えばディスク障害が発生してデータが失われる場合）、どのようにスケジュールを立てるか。 - - すべてのリージョンのレプリカ。 - - 一部のリージョンでレプリカの数が足りない場合、PD はそれらを完了する必要があります。 - - レプリカの数が予想より多い場合 (たとえば、障害が発生したストアがリカバリ後にクラスターに再参加する場合)、PD はそれらを削除する必要があります。 -- 読み取り/書き込み操作はリーダー上で実行されますが、少数の個別のストアにのみ分散することはできません。 -- すべてのリージョンがホットなわけではないので、すべての TiKV ストアの負荷をバランスさせる必要があります。 -- リージョンのバランスが取れている場合、データ転送に多くのネットワーク/ディスク トラフィックと CPU 時間が必要となり、オンライン サービスに影響する可能性があります。 +- ストレージスペースを効率的に利用するには、同じリージョンの複数のレプリカを、リージョンのサイズに応じて異なるノードに適切に分散する必要があります。 +- 複数のデータセンター トポロジの場合、1 つのデータセンターに障害が発生すると、すべてのリージョンの 1 つのレプリカのみが失敗します。 +- 新しい TiKV ストアが追加されると、そのストアにデータを再バランスさせることができます。 +- TiKV ストアに障害が発生した場合、PD は次のことを考慮する必要があります。 + - 障害が発生したストアの回復時間。 + - 短い場合（たとえば、サービスが再起動された場合）、スケジュールが必要かどうか。 + - 長時間かかる場合（例えばディスク障害が発生してデータが失われる場合）、どのようにスケジュールを立てるか。 + - すべてのリージョンのレプリカ。 + - 一部のリージョンでレプリカの数が足りない場合、PD はそれらを完了する必要があります。 + - レプリカの数が予想より多い場合 (たとえば、障害が発生したストアがリカバリ後にクラスターに再参加する場合)、PD はそれらを削除する必要があります。 +- 読み取り/書き込み操作はリーダー上で実行されますが、少数の個別のストアにのみ分散することはできません。 +- すべてのリージョンがホットなわけではないので、すべての TiKV ストアの負荷をバランスさせる必要があります。 +- リージョンのバランスが取れている場合、データ転送に多くのネットワーク/ディスク トラフィックと CPU 時間が必要となり、オンライン サービスに影響する可能性があります。 これらの状況は同時に発生する可能性があり、解決が困難になります。また、システム全体が動的に変化するため、クラスタに関するすべての情報を収集し、クラスタを調整するスケジューラが必要です。そこで、TiDBクラスタにPDが導入されました。 @@ -33,19 +33,19 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン 上記の状況は、次の 2 つのタイプに分類できます。 -1. 分散型で可用性の高いストレージシステムは、次の要件を満たす必要があります。 +1. 分散型で可用性の高いストレージシステムは、次の要件を満たす必要があります。 - - 適切な数のレプリカ。 - - レプリカは、さまざまなトポロジに応じて異なるマシンに分散する必要があります。 - - クラスターは、TiKV ピアの障害からの自動災害復旧を実行できます。 + - 適切な数のレプリカ。 + - レプリカは、さまざまなトポロジに応じて異なるマシンに分散する必要があります。 + - クラスターは、TiKV ピアの障害からの自動災害復旧を実行できます。 -2. 優れた分散システムには、次のような最適化が必要です。 +2. 優れた分散システムには、次のような最適化が必要です。 - - すべてのリージョンリーダーはストアに均等に分散されます。 - - すべての TiKV ピアのストレージ容量がバランスされています。 - - ホットスポットはバランスが取れています。 - - オンライン サービスの安定性を確保するには、リージョンの負荷分散の速度を制限する必要があります。 - - メンテナーはピアを手動でオンライン/オフラインにすることができます。 + - すべてのリージョンリーダーはストアに均等に分散されます。 + - すべての TiKV ピアのストレージ容量がバランスされています。 + - ホットスポットはバランスが取れています。 + - オンライン サービスの安定性を確保するには、リージョンの負荷分散の速度を制限する必要があります。 + - メンテナーはピアを手動でオンライン/オフラインにすることができます。 最初のタイプの要件が満たされると、システムは障害を許容できるようになります。2番目のタイプの要件が満たされると、リソースはより効率的に利用され、システムのスケーラビリティが向上します。 @@ -55,9 +55,9 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン すべてのスケジュール プランには、次の 3 つの基本演算子が含まれています。 -- 新しいレプリカを追加する -- レプリカを削除する -- Raftグループ内のレプリカ間でリージョンリーダーを転送する +- 新しいレプリカを追加する +- レプリカを削除する +- Raftグループ内のレプリカ間でリージョンリーダーを転送する これらは`RemoveReplica` Raftコマンド`AddReplica` 、および`TransferLeader`によって実装されます。 @@ -65,36 +65,36 @@ TiKVは、TiDBが使用する分散キーバリューストレージエンジン スケジューリングは情報収集に基づいています。つまり、PDスケジューリングコンポーネントは、すべてのTiKVピアとすべてのリージョンの状態を把握する必要があります。TiKVピアはPDに以下の情報を報告します。 -- 各 TiKV ピアによって報告される状態情報: +- 各 TiKV ピアによって報告される状態情報: 各 TiKV ピアは定期的に PD にハートビートを送信します。PD はストアが生きているかどうかを確認するだけでなく、ハートビートメッセージで[`StoreState`](https://github.com/pingcap/kvproto/blob/release-8.5/proto/pdpb.proto#L473)も収集します。`StoreState`には次の情報が含まれます。 - - ディスク容量合計 - - 使用可能なディスク容量 - - リージョンの数 - - データの読み取り/書き込み速度 - - 送受信されるスナップショットの数（データはスナップショットを通じてレプリカ間で複製される可能性があります） - - ストアが混雑しているかどうか - - ラベル（ [トポロジーの認識](https://docs.pingcap.com/tidb/stable/schedule-replicas-by-topology-labels)参照） + - ディスク容量合計 + - 使用可能なディスク容量 + - リージョンの数 + - データの読み取り/書き込み速度 + - 送受信されるスナップショットの数（データはスナップショットを通じてレプリカ間で複製される可能性があります） + - ストアが混雑しているかどうか + - ラベル（ [トポロジーの認識](https://docs.pingcap.com/tidb/stable/schedule-replicas-by-topology-labels)参照） PD制御を使用して、TiKVストアのステータス（稼働中、切断、オフライン、ダウン、または廃棄）を確認できます。以下は、すべてのステータスとその関係についての説明です。 - - **Up** : TiKVストアが稼働中です。 - - **切断**：PDとTiKVストア間のハートビートメッセージが20秒以上失われます。失われた期間が`max-store-down-time`で指定された時間を超えると、「切断」ステータスが「ダウン」に変わります。 - - **ダウン**：PDとTiKVストア間のハートビートメッセージが`max-store-down-time` （デフォルトでは30分）以上途絶えています。この状態になると、TiKVストアは各リージョンのレプリカを残存ストアに補充し始めます。 - - **オフライン**: TiKV ストアは、 PD Controlによって手動でオフラインになっています。これは、ストアがオフラインになるまでの中間ステータスです。このステータスのストアは、すべてのリージョンを、再配置条件を満たす他の「稼働中」ストアに移動します。 `leader_count`と`region_count` ( PD Controlから取得) の両方が`0`を示している場合、ストアのステータスは「オフライン」から「廃棄」に変わります。「オフライン」ステータスでは、ストア サービスまたはストアが配置されている物理サーバーを無効に**しないでください**。ストアがオフラインになるプロセス中に、クラスターにリージョンを再配置するターゲット ストアがない場合 (クラスター内にレプリカを保持するのに十分なストアがない場合など)、ストアは常に「オフライン」ステータスになります。 - - **tombstone**：TiKVストアは完全にオフラインです。この状態では、 `remove-tombstone`インターフェースを使用してTiKVを安全にクリーンアップできます。v6.5.0以降、手動で処理しない限り、ノードがtombstoneに変換されてから1か月後にPDは内部的に保存されたtombstoneレコードを自動的に削除します。 + - **Up** : TiKVストアが稼働中です。 + - **切断**：PDとTiKVストア間のハートビートメッセージが20秒以上失われます。失われた期間が`max-store-down-time`で指定された時間を超えると、「切断」ステータスが「ダウン」に変わります。 + - **ダウン**：PDとTiKVストア間のハートビートメッセージが`max-store-down-time` （デフォルトでは30分）以上途絶えています。この状態になると、TiKVストアは各リージョンのレプリカを残存ストアに補充し始めます。 + - **オフライン**: TiKV ストアは、 PD Controlによって手動でオフラインになっています。これは、ストアがオフラインになるまでの中間ステータスです。このステータスのストアは、すべてのリージョンを、再配置条件を満たす他の「稼働中」ストアに移動します。 `leader_count`と`region_count` ( PD Controlから取得) の両方が`0`を示している場合、ストアのステータスは「オフライン」から「廃棄」に変わります。「オフライン」ステータスでは、ストア サービスまたはストアが配置されている物理サーバーを無効に**しないでください**。ストアがオフラインになるプロセス中に、クラスターにリージョンを再配置するターゲット ストアがない場合 (クラスター内にレプリカを保持するのに十分なストアがない場合など)、ストアは常に「オフライン」ステータスになります。 + - **tombstone**：TiKVストアは完全にオフラインです。この状態では、 `remove-tombstone`インターフェースを使用してTiKVを安全にクリーンアップできます。v6.5.0以降、手動で処理しない限り、ノードがtombstoneに変換されてから1か月後にPDは内部的に保存されたtombstoneレコードを自動的に削除します。 ![TiKV store status relationship](/media/tikv-store-status-relationship.png) -- リージョンリーダーから報告された情報: +- リージョンリーダーから報告された情報: 各リージョンリーダーは、定期的に PD にハートビートを送信して、 [`RegionState`](https://github.com/pingcap/kvproto/blob/release-8.5/proto/pdpb.proto#L312)の情報を報告します。1 - - リーダー自身の立場 - - 他のレプリカの位置 - - オフラインレプリカの数 - - データの読み取り/書き込み速度 + - リーダー自身の立場 + - 他のレプリカの位置 + - オフラインレプリカの数 + - データの読み取り/書き込み速度 PD は 2 種類のハートビートによってクラスター情報を収集し、それに基づいて決定を下します。 @@ -110,17 +110,17 @@ PD は 2 種類のハートビートによってクラスター情報を収集 PDは、リージョンリーダーのハートビートから、リージョンのレプリカ数が誤っていることを検知できます。このような状況が発生した場合、PDはレプリカを追加または削除することでレプリカ数を調整できます。レプリカ数が誤っている原因としては、以下のことが考えられます。 -- ストア障害のため、一部のリージョンのレプリカ数が予想より少なくなっています。 -- 障害後のストアのリカバリのため、一部のリージョンのレプリカ数が予想より多くなる場合があります。 -- [`max-replicas`](https://github.com/pingcap/pd/blob/v4.0.0-beta/conf/config.toml#L95)が変更されます。 +- ストア障害のため、一部のリージョンのレプリカ数が予想より少なくなっています。 +- 障害後のストアのリカバリのため、一部のリージョンのレプリカ数が予想より多くなる場合があります。 +- [`max-replicas`](https://github.com/pingcap/pd/blob/v4.0.0-beta/conf/config.toml#L95)が変更されます。 **戦略2:リージョンのレプリカは異なる位置に配置する必要あり** ここでの「位置」は「マシン」とは異なることに注意してください。通常、PDは、ピアの障害によって複数のレプリカが失われるのを防ぐため、リージョンのレプリカが同じピアに存在しないようにすることしかできません。ただし、本番では、次のような要件がある場合があります。 -- 複数の TiKV ピアが 1 台のマシンに存在します。 -- TiKV ピアは複数のラックに配置されており、ラックに障害が発生してもシステムは利用可能であると予想されます。 -- TiKV ピアは複数のデータセンターにあり、データセンターに障害が発生した場合でもシステムは利用可能であると予想されます。 +- 複数の TiKV ピアが 1 台のマシンに存在します。 +- TiKV ピアは複数のラックに配置されており、ラックに障害が発生してもシステムは利用可能であると予想されます。 +- TiKV ピアは複数のデータセンターにあり、データセンターに障害が発生した場合でもシステムは利用可能であると予想されます。 これらの要件の鍵となるのは、ピアが同じ「ポジション」を持つことができることです。これは、障害耐性の最小単位です。リージョンのレプリカは、同じユニットに存在してはなりません。そこで、TiKVピアに[ラベル](https://github.com/tikv/tikv/blob/v4.0.0-beta/etc/config-template.toml#L140)設定し、PDに[場所ラベル](https://github.com/pingcap/pd/blob/v4.0.0-beta/conf/config.toml#L100)設定することで、ポジションのマーキングに使用するラベルを指定できます。 diff --git a/tidb-storage.md b/tidb-storage.md index 0868f13bd2ca5..13f73e764a898 100644 --- a/tidb-storage.md +++ b/tidb-storage.md @@ -13,8 +13,8 @@ summary: TiDB データベースのストレージレイヤーを理解します データストレージシステムで最初に決定すべきことは、データストレージモデル、つまりデータをどのような形式で保存するかです。TiKVはキーバリューモデルを採用しており、順序付けされたトラバーサル手法を提供します。TiKVデータストレージモデルには、以下の2つの重要なポイントがあります。 -- これは、キーと値のペアを格納する巨大なマップ (C++ の`std::Map`に似ています) です。 -- マップ内のキーと値のペアは、キーのバイナリ順序に従って順序付けられます。つまり、特定のキーの位置を Seek し、次に Next メソッドを呼び出して、このキーよりも大きいキーと値のペアを増分順に取得できます。 +- これは、キーと値のペアを格納する巨大なマップ (C++ の`std::Map`に似ています) です。 +- マップ内のキーと値のペアは、キーのバイナリ順序に従って順序付けられます。つまり、特定のキーの位置を Seek し、次に Next メソッドを呼び出して、このキーよりも大きいキーと値のペアを増分順に取得できます。 なお、本ドキュメントで説明するTiKVのKVストレージモデルは、SQLテーブルとは一切関係ありません。本ドキュメントではSQL関連の概念については説明せず、TiKVのような高性能で信頼性の高い分散型キーバリューストレージの実装方法のみに焦点を当てています。 @@ -32,9 +32,9 @@ RocksDBは、Facebookがオープンソース化した優れたスタンドア Raftはコンセンサスアルゴリズムです。このドキュメントではRaftについて簡単に説明します。詳細については[理解しやすいコンセンサスアルゴリズムを求めて](https://raft.github.io/raft.pdf)ご覧ください。Raftにはいくつかの重要な機能があります。 -- Leader選挙 -- メンバーシップの変更（レプリカの追加、レプリカの削除、リーダーの譲渡など） -- ログレプリケーション +- Leader選挙 +- メンバーシップの変更（レプリカの追加、レプリカの削除、リーダーの譲渡など） +- ログレプリケーション TiKVはRaftを使用してデータレプリケーションを実行します。各データ変更はRaftログとして記録されます。Raftログレプリケーションにより、データはRaftグループ内の複数のノードに安全かつ確実に複製されます。ただし、 Raftプロトコルでは、書き込みが成功するには、データが過半数のノードに複製されている必要があります。 @@ -46,8 +46,8 @@ TiKVはRaftを使用してデータレプリケーションを実行します。 理解を容易にするために、すべてのデータにレプリカが1つしかないと仮定しましょう。前述のように、TiKVは大規模で整然としたKVマップと見なすことができ、水平方向のスケーラビリティを実現するために、データは複数のマシンに分散されます。KVシステムでは、複数のマシンにデータを分散させる一般的なソリューションが2つあります。 -- ハッシュ: キーによってハッシュを作成し、ハッシュ値に応じて対応するストレージノードを選択します。 -- 範囲: 範囲をキーで分割します。シリアル キーのセグメントがノードに保存されます。 +- ハッシュ: キーによってハッシュを作成し、ハッシュ値に応じて対応するストレージノードを選択します。 +- 範囲: 範囲をキーで分割します。シリアル キーのセグメントがノードに保存されます。 TiKVは、キーと値の空間全体を連続するキーセグメントに分割する2番目のソリューションを選択します。各セグメントはリージョンと呼ばれます。各リージョンは、左閉区間と右開区間の`[StartKey, EndKey)`で表されます。各リージョンのデフォルトのサイズ制限は256MiBですが、サイズは設定可能です。 @@ -55,16 +55,16 @@ TiKVは、キーと値の空間全体を連続するキーセグメントに分 ここでのリージョンはSQLのテーブルとは何の関係もありません。このドキュメントでは、SQLについては一旦忘れてKVに焦点を当てます。データをリージョンに分割した後、TiKVは次の2つの重要なタスクを実行します。 -- クラスター内のすべてのノードにデータを分散し、リージョンを基本単位として使用します。各ノードのリージョン数がほぼ同じになるようにしてください。 -- リージョン内でRaftレプリケーションとメンバーシップ管理を実行します。 +- クラスター内のすべてのノードにデータを分散し、リージョンを基本単位として使用します。各ノードのリージョン数がほぼ同じになるようにしてください。 +- リージョン内でRaftレプリケーションとメンバーシップ管理を実行します。 これら 2 つのタスクは非常に重要なので、1 つずつ紹介します。 -- まず、データはキーに基づいて複数のリージョンに分割され、各リージョンのデータは1つのノードにのみ保存されます（複数のレプリカは無視されます）。TiDBシステムには、クラスター内のすべてのノードにリージョンを可能な限り均等に分散させるPDコンポーネントがあります。これにより、ストレージ容量が水平方向に拡張され（他のノードのリージョンは新しく追加されたノードに自動的にスケジュールされます）、負荷分散が実現されます（あるノードに大量のデータがある一方で、他のノードにはほとんどデータがないという状況は発生しません）。 +- まず、データはキーに基づいて複数のリージョンに分割され、各リージョンのデータは1つのノードにのみ保存されます（複数のレプリカは無視されます）。TiDBシステムには、クラスター内のすべてのノードにリージョンを可能な限り均等に分散させるPDコンポーネントがあります。これにより、ストレージ容量が水平方向に拡張され（他のノードのリージョンは新しく追加されたノードに自動的にスケジュールされます）、負荷分散が実現されます（あるノードに大量のデータがある一方で、他のノードにはほとんどデータがないという状況は発生しません）。 同時に、上位クライアントが必要なデータにアクセスできるようにするため、システムにはノード上の領域の分布、つまりキーの正確なリージョンと任意のキーを通じて配置されたそのリージョンのノードを記録するコンポーネント(PD) があります。 -- 2つ目のタスクでは、TiKVはリージョン内でデータを複製します。つまり、1つのリージョン内のデータには「レプリカ」という名前のレプリカが複数存在することになります。リージョン内の複数のレプリカは異なるノードに保存され、 Raftグループを形成します。RaftグループはRaftアルゴリズムによって一貫性が維持されます。 +- 2つ目のタスクでは、TiKVはリージョン内でデータを複製します。つまり、1つのリージョン内のデータには「レプリカ」という名前のレプリカが複数存在することになります。リージョン内の複数のレプリカは異なるノードに保存され、 Raftグループを形成します。RaftグループはRaftアルゴリズムによって一貫性が維持されます。 レプリカの1つはグループのLeaderとして機能し、もう1つはFollowerとして機能します。デフォルトでは、すべての読み取りと書き込みはLeaderを介して処理され、リーダーで読み取りが行われ、書き込みはフォロワーに複製されます。次の図は、リージョンとRaftグループの全体像を示しています。 diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index ec121eb3db5c1..40cea84baddc5 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -11,15 +11,15 @@ summary: TiDBでよく発生するエラーのトラブルシューティング ### 1.1 クライアントから`Region is Unavailable`エラーが報告されました {#11-the-client-reports-region-is-unavailable-error} -- 1.1.1 `Region is Unavailable`エラーは通常、リージョンが一定期間利用できないことが原因です。 `TiKV server is busy`が発生する場合や、 `not leader`または`epoch not match` } が原因で TiKV へのリクエストが失敗するか、TiKV へのリクエストがタイムアウトする場合があります。このような場合、TiDB は`backoff`再試行メカニズムを実行します。 `backoff`がしきい値 (デフォルトでは 20 秒) を超えると、エラーがクライアントに送信されます。 `backoff`のしきい値内であれば、このエラーはクライアントには表示されません。 +- 1.1.1 `Region is Unavailable`エラーは通常、リージョンが一定期間利用できないことが原因です。 `TiKV server is busy`が発生する場合や、 `not leader`または`epoch not match` } が原因で TiKV へのリクエストが失敗するか、TiKV へのリクエストがタイムアウトする場合があります。このような場合、TiDB は`backoff`再試行メカニズムを実行します。 `backoff`がしきい値 (デフォルトでは 20 秒) を超えると、エラーがクライアントに送信されます。 `backoff`のしきい値内であれば、このエラーはクライアントには表示されません。 -- 1.1.2 複数のTiKVインスタンスが同時にメモリ不足（OOM）になると、OOM期間中にLeaderが存在しない状態になります。中国語版の[ケース991](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case991.md)を参照してください。 +- 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.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エラーによりサービスが利用できなくなる {#12-pd-errors-cause-service-unavailable} @@ -29,147 +29,147 @@ summary: TiDBでよく発生するエラーのトラブルシューティング ### 2.1 一時的な増加 {#21-transient-increase} -- 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.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.2 持続的かつ著しい増加 {#22-persistent-and-significant-increase} -- 2.2.1 TiKVシングルスレッドのボトルネック +- 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にアップグレードできます。 + - v3.0より前のバージョンでは、raftstoreスレッドまたはapplyスレッドがボトルネックになった場合（ **Grafana** -> **TiKV-details** -> **Thread CPU/raft store CPU**および**Async apply CPU**メトリクスが`80%`を超える場合）、TiKV（v2.x）インスタンスをスケールアウトするか、マルチスレッド対応のv3.xにアップグレードできます。 -- 2.2.2 CPU負荷が増加する。 +- 2.2.2 CPU負荷が増加する。 -- 2.2.3 TiKV の書き込み速度が遅い[4.5](#45-tikv-write-is-slow)を参照してください。 +- 2.2.3 TiKV の書き込み速度が遅い[4.5](#45-tikv-write-is-slow)を参照してください。 -- 2.2.4 TiDB の実行計画が間違っています[3.3](#33-wrong-execution-plan)を参照してください。 +- 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} ### 3.1 DDL {#31-ddl} -- 3.1.1 `ERROR 1105 (HY000): unsupported modify decimal column precision`フィールドの長さを変更すると、エラー`decimal`が報告されます。 TiDB は`decimal`フィールドの長さを変更することをサポートしていません。 +- 3.1.1 `ERROR 1105 (HY000): unsupported modify decimal column precision`フィールドの長さを変更すると、エラー`decimal`が報告されます。 TiDB は`decimal`フィールドの長さを変更することをサポートしていません。 -- 3.1.2 TiDB DDL ジョブがハングアップするか、実行が遅くなる（DDL の進行状況を確認するには`admin show ddl jobs`を使用してください） +- 3.1.2 TiDB DDL ジョブがハングアップするか、実行が遅くなる（DDL の進行状況を確認するには`admin show ddl jobs`を使用してください） - - 原因1：TiDBはv6.3.0で「[メタデータロック](/metadata-lock.md)を導入し、v6.5.0以降のバージョンではデフォルトで有効にしています。DDL操作に関わるテーブルが、コミットされていないトランザクションに関わるテーブルと重複している場合、トランザクションがコミットまたはロールバックされるまでDDL操作はブロックされます。 + - 原因1：TiDBはv6.3.0で「[メタデータロック](/metadata-lock.md)を導入し、v6.5.0以降のバージョンではデフォルトで有効にしています。DDL操作に関わるテーブルが、コミットされていないトランザクションに関わるテーブルと重複している場合、トランザクションがコミットまたはロールバックされるまでDDL操作はブロックされます。 - - 原因2：他のコンポーネント（PD/TiKV）とのネットワークの問題。 + - 原因2：他のコンポーネント（PD/TiKV）とのネットワークの問題。 - - 原因3：TiDBの初期バージョン（v3.0.8より前）は、多数のゴルーチンが高並行性で動作するため、内部負荷が非常に高い。 + - 原因3：TiDBの初期バージョン（v3.0.8より前）は、多数のゴルーチンが高並行性で動作するため、内部負荷が非常に高い。 - - 原因4：初期バージョン（v2.1.15およびv3.0.0-rc1未満のバージョン）では、PDインスタンスがTiDBキーを削除できず、すべてのDDL変更が2リース分待機することになります。 + - 原因4：初期バージョン（v2.1.15およびv3.0.0-rc1未満のバージョン）では、PDインスタンスがTiDBキーを削除できず、すべてのDDL変更が2リース分待機することになります。 - - その他の原因不明の場合は[バグを報告する](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)。 + - その他の原因不明の場合は[バグを報告する](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)。 - - 解決： + - 解決： - - 原因1については、TiDBとTiKV/PD間のネットワーク接続を確認してください。 - - 原因2と3については、後のバージョンで既に修正されています。TiDBを最新バージョンにアップグレードしてください。 - - その他の原因については、DDL所有者を移行するという以下の解決策を使用できます。 + - 原因1については、TiDBとTiKV/PD間のネットワーク接続を確認してください。 + - 原因2と3については、後のバージョンで既に修正されています。TiDBを最新バージョンにアップグレードしてください。 + - その他の原因については、DDL所有者を移行するという以下の解決策を使用できます。 - - DDL所有者の移行: + - DDL所有者の移行: - - TiDBサーバーに接続できる場合は、所有者選出コマンドを再度実行してください： `curl -X POST http://{TiDBIP}:10080/ddl/owner/resign` - - TiDBサーバーに接続できない場合は、 `tidb-ctl`を使用してPDクラスタのetcdからDDLオーナーを削除し、再選出をトリガーしてください： `tidb-ctl etcd delowner [LeaseID] [flags] + ownerKey` + - TiDBサーバーに接続できる場合は、所有者選出コマンドを再度実行してください： `curl -X POST http://{TiDBIP}:10080/ddl/owner/resign` + - TiDBサーバーに接続できない場合は、 `tidb-ctl`を使用してPDクラスタのetcdからDDLオーナーを削除し、再選出をトリガーしてください： `tidb-ctl etcd delowner [LeaseID] [flags] + ownerKey` -- 3.1.3 TiDB のログに`information schema is changed`エラーが報告される +- 3.1.3 TiDB のログに`information schema is changed`エラーが報告される - - 詳細な原因と解決策については、 [`Information schema is changed`エラーが報告される理由](/faq/sql-faq.md#what-triggers-the-information-schema-is-changed-error)を参照してください。 + - 詳細な原因と解決策については、 [`Information schema is changed`エラーが報告される理由](/faq/sql-faq.md#what-triggers-the-information-schema-is-changed-error)を参照してください。 - - 背景： `schema version`の増加数は、各 DDL 変更操作の`schema state`の数と一致しています。たとえば、 `create table`操作ではバージョン変更が 1 回、 `add column`操作ではバージョン変更が 4 回発生します。したがって、列変更操作が多すぎると`schema version`が急速に増加する可能性があります。詳細は[オンラインスキーマの変更](https://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/41376.pdf)を参照してください。 + - 背景： `schema version`の増加数は、各 DDL 変更操作の`schema state`の数と一致しています。たとえば、 `create table`操作ではバージョン変更が 1 回、 `add column`操作ではバージョン変更が 4 回発生します。したがって、列変更操作が多すぎると`schema version`が急速に増加する可能性があります。詳細は[オンラインスキーマの変更](https://static.googleusercontent.com/media/research.google.com/zh-CN//pubs/archive/41376.pdf)を参照してください。 -- 3.1.4 TiDB はログに`information schema is out of date`を報告します +- 3.1.4 TiDB はログに`information schema is out of date`を報告します - - 原因1：DMLステートメントを実行しているTiDBサーバーが`graceful kill`によって停止され、終了準備状態になります。DMLステートメントを含むトランザクションの実行時間が1つのDDLリースを超えています。トランザクションのコミット時にエラーが報告されます。 + - 原因1：DMLステートメントを実行しているTiDBサーバーが`graceful kill`によって停止され、終了準備状態になります。DMLステートメントを含むトランザクションの実行時間が1つのDDLリースを超えています。トランザクションのコミット時にエラーが報告されます。 - - 原因2：TiDBサーバーがDMLステートメントの実行中にPDまたはTiKVに接続できません。その結果、TiDBサーバーは1つのDDLリース（デフォルトでは`45s`内に新しいスキーマをロードできなかったか、TiDBサーバーが`keep alive`設定でPDから切断されました。 + - 原因2：TiDBサーバーがDMLステートメントの実行中にPDまたはTiKVに接続できません。その結果、TiDBサーバーは1つのDDLリース（デフォルトでは`45s`内に新しいスキーマをロードできなかったか、TiDBサーバーが`keep alive`設定でPDから切断されました。 - - 原因3：TiKVの負荷が高いか、ネットワークがタイムアウトしました。Grafana -> **TiDB**と**TiKV**でノードの負荷を確認してください。 + - 原因3：TiKVの負荷が高いか、ネットワークがタイムアウトしました。Grafana -> **TiDB**と**TiKV**でノードの負荷を確認してください。 - - 解決： + - 解決： - - 原因1については、TiDB起動時にDML操作を再試行してください。 - - 原因2については、TiDBサーバーとPD/TiKV間のネットワークを確認してください。 - - 原因 3 については、TiKV がビジーである理由を調査します。 [TiKVに関する4つの問題](#4-tikv-issues)を参照。 + - 原因1については、TiDB起動時にDML操作を再試行してください。 + - 原因2については、TiDBサーバーとPD/TiKV間のネットワークを確認してください。 + - 原因 3 については、TiKV がビジーである理由を調査します。 [TiKVに関する4つの問題](#4-tikv-issues)を参照。 ### 3.2 メモリ不足の問題 {#32-oom-issues} -- 3.2.1 症状 +- 3.2.1 症状 - - クライアント: クライアントからエラー`ERROR 2013 (HY000): Lost connection to MySQL server during query`が報告されました。 + - クライアント: クライアントからエラー`ERROR 2013 (HY000): Lost connection to MySQL server during query`が報告されました。 - - ログを確認してください + - ログを確認してください - - `dmesg -T | grep tidb-server`を実行してください。結果として、エラーが発生した時点付近の OOM-killer ログが表示されます。 + - `dmesg -T | grep tidb-server`を実行してください。結果として、エラーが発生した時点付近の OOM-killer ログが表示されます。 - - エラーが発生した時点（つまり、tidb-serverが再起動した時点）の前後の`tidb.log`にある「Welcome to TiDB」ログをgrepします。 + - エラーが発生した時点（つまり、tidb-serverが再起動した時点）の前後の`tidb.log`にある「Welcome to TiDB」ログをgrepします。 - - `fatal error: runtime: out of memory`または`cannot allocate memory` `tidb_stderr.log`内で検索します。 + - `fatal error: runtime: out of memory`または`cannot allocate memory` `tidb_stderr.log`内で検索します。 - - v2.1.8以前のバージョンでは、 `fatal error: stack overflow`内で`tidb_stderr.log` } を grep できます。 + - v2.1.8以前のバージョンでは、 `fatal error: stack overflow`内で`tidb_stderr.log` } を grep できます。 - - 監視：tidb-serverインスタンスのメモリ使用量が短時間で急激に増加します。 + - 監視：tidb-serverインスタンスのメモリ使用量が短時間で急激に増加します。 -- 3.2.2 OOMを引き起こすSQL文を特定します。（現在、TiDBのすべてのバージョンではSQL文を正確に特定できません。SQL文を特定した後、OOMがそのSQL文によって引き起こされているかどうかを分析する必要があります。） +- 3.2.2 OOMを引き起こすSQL文を特定します。（現在、TiDBのすべてのバージョンではSQL文を正確に特定できません。SQL文を特定した後、OOMがそのSQL文によって引き起こされているかどうかを分析する必要があります。） - - バージョン3.0.0以降の場合、 `tidb.log`内の「expensive_query」をgrepしてください。このログメッセージには、タイムアウトした、またはメモリ割り当て量を超過したSQLクエリが記録されています。 + - バージョン3.0.0以降の場合、 `tidb.log`内の「expensive_query」をgrepしてください。このログメッセージには、タイムアウトした、またはメモリ割り当て量を超過したSQLクエリが記録されています。 - - バージョンが v3.0.0 未満の場合、 `tidb.log`で "メモリ exceeded quota" を grep して、メモリクォータを超える SQL クエリを特定します。 + - バージョンが v3.0.0 未満の場合、 `tidb.log`で "メモリ exceeded quota" を grep して、メモリクォータを超える SQL クエリを特定します。 > **Note:** > > 単一の SQLメモリ使用量のデフォルトのしきい値は`1GB`です。このパラメータは、システム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)を設定することで設定できます。 -- 3.2.3 メモリ不足問題​​の軽減 +- 3.2.3 メモリ不足問題​​の軽減 - - `SWAP`を有効にすることで、大規模クエリによるメモリの過剰使用が原因で発生する OOM の問題を軽減できます。メモリが不足している場合、この方法は I/O オーバーヘッドにより大規模クエリのパフォーマンスに影響を与える可能性があります。パフォーマンスへの影響の程度は、残りのメモリ容量とディスク I/O 速度によって異なります。 + - `SWAP`を有効にすることで、大規模クエリによるメモリの過剰使用が原因で発生する OOM の問題を軽減できます。メモリが不足している場合、この方法は I/O オーバーヘッドにより大規模クエリのパフォーマンスに影響を与える可能性があります。パフォーマンスへの影響の程度は、残りのメモリ容量とディスク I/O 速度によって異なります。 -- 3.2.4 メモリ不足が発生する典型的な理由 +- 3.2.4 メモリ不足が発生する典型的な理由 - - SQL クエリには`join`が含まれています。 `explain`を使用して SQL ステートメントを表示すると、 `join`操作で`HashJoin`アルゴリズムが選択され、 `inner`テーブルが大きいことがわかります。 + - 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)を参照してください。 + - SQL文には`Union`で接続された複数のサブクエリが含まれています。中国語版の[ケース1828](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case1828.md)を参照してください。 OOM のトラブルシューティングの詳細については、 [TiDBのメモリ不足問題​​のトラブルシューティング](/troubleshoot-tidb-oom.md)を参照してください。 ### 3.3 実行計画の誤り {#33-wrong-execution-plan} -- 3.3.1 症状 +- 3.3.1 症状 - - SQLクエリの実行時間が以前の実行時と比べて大幅に長くなっている、または実行計画が突然変更されている場合。実行計画がスローログに記録されている場合は、実行計画を直接比較できます。 + - SQLクエリの実行時間が以前の実行時と比べて大幅に長くなっている、または実行計画が突然変更されている場合。実行計画がスローログに記録されている場合は、実行計画を直接比較できます。 - - SQLクエリの実行時間は、MySQLなどの他のデータベースと比較して非常に長くなっています。 `Join Order`などの他のデータベースと実行計画を比較して違いを確認してください。 + - SQLクエリの実行時間は、MySQLなどの他のデータベースと比較して非常に長くなっています。 `Join Order`などの他のデータベースと実行計画を比較して違いを確認してください。 - - スローログでは、SQL実行時間`Scan Keys`の数が多くなっています。 + - スローログでは、SQL実行時間`Scan Keys`の数が多くなっています。 -- 3.3.2 実行計画の調査 +- 3.3.2 実行計画の調査 - - `explain analyze {SQL}` 。実行時間が許容範囲内であれば、 `explain analyze`の結果の`count`と`execution info`の`row`の数を比較します。 `TableScan/IndexScan`行で大きな差が見つかった場合は、統計情報が間違っている可能性があります。他の行で大きな差が見つかった場合は、統計情報に問題がない可能性があります。 + - `explain analyze {SQL}` 。実行時間が許容範囲内であれば、 `explain analyze`の結果の`count`と`execution info`の`row`の数を比較します。 `TableScan/IndexScan`行で大きな差が見つかった場合は、統計情報が間違っている可能性があります。他の行で大きな差が見つかった場合は、統計情報に問題がない可能性があります。 - - `select count(*)` 。実行計画に`join`操作が含まれている場合、 `explain analyze`の実行に時間がかかる場合があります。 `select count(*)`を実行し、 `TableScan/IndexScan`の結果に含まれる`row count`の情報を比較することで、 `explain`情報にあるかどうかを確認できます。 + - `select count(*)` 。実行計画に`join`操作が含まれている場合、 `explain analyze`の実行に時間がかかる場合があります。 `select count(*)`を実行し、 `TableScan/IndexScan`の結果に含まれる`row count`の情報を比較することで、 `explain`情報にあるかどうかを確認できます。 -- 3.3.3 緩和策 +- 3.3.3 緩和策 - - v3.0以降のバージョンでは、 `SQL Bind`機能を使用して実行計画をバインドします。 + - v3.0以降のバージョンでは、 `SQL Bind`機能を使用して実行計画をバインドします。 - - 統計情報を更新します。問題の原因が統計情報にあるとおおよそ確信できる場合は、[統計情報を捨てる](/statistics.md#export-statistics)。原因が古い統計情報である場合、例えば`modify count/row count`の`show stats_meta`が特定の値 (例えば 0.3) より大きい場合、またはテーブルに時間列のインデックスがある場合、 `analyze table`を使用して復旧を試みることもできます。 `auto analyze`が設定されている場合は、 `tidb_auto_analyze_ratio`システム変数が大きすぎる (例えば 0.3 より大きい) かどうか、および現在時刻が`tidb_auto_analyze_start_time`と`tidb_auto_analyze_end_time`の間にあるかどうかを確認してください。 + - 統計情報を更新します。問題の原因が統計情報にあるとおおよそ確信できる場合は、[統計情報を捨てる](/statistics.md#export-statistics)。原因が古い統計情報である場合、例えば`modify count/row count`の`show stats_meta`が特定の値 (例えば 0.3) より大きい場合、またはテーブルに時間列のインデックスがある場合、 `analyze table`を使用して復旧を試みることもできます。 `auto analyze`が設定されている場合は、 `tidb_auto_analyze_ratio`システム変数が大きすぎる (例えば 0.3 より大きい) かどうか、および現在時刻が`tidb_auto_analyze_start_time`と`tidb_auto_analyze_end_time`の間にあるかどうかを確認してください。 - - その他の状況については、 [バグを報告する](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)。 + - その他の状況については、 [バグを報告する](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)。 ### 3.4 SQL実行エラー {#34-sql-execution-error} -- 3.4.1 クライアントは`ERROR 1265(01000) Data Truncated`エラーを報告します。これは、TiDB が内部的に`Decimal`型の精度を計算する方法が MySQL の計算方法と互換性がないためです。この問題は v3.0.10 ( [#14438](https://github.com/pingcap/tidb/pull/14438) ) で修正されました。 +- 3.4.1 クライアントは`ERROR 1265(01000) Data Truncated`エラーを報告します。これは、TiDB が内部的に`Decimal`型の精度を計算する方法が MySQL の計算方法と互換性がないためです。この問題は v3.0.10 ( [#14438](https://github.com/pingcap/tidb/pull/14438) ) で修正されました。 - - 原因： + - 原因： MySQL では、2 つの大きな精度`Decimal`を割り算し、結果が最大小数精度 ( `30`を超える場合、 `30`桁のみが予約され、エラーは報告されません。 @@ -181,7 +181,7 @@ OOM のトラブルシューティングの詳細については、 [TiDBのメ `Decimal`の乗算では、範囲外が回避され、精度が最大精度制限に設定されるため、この問題は発生しません。 - - 解決策： `Cast(xx as decimal(a, b))`と`a`目標精度として、 `b` } を手動で追加することで、この問題を回避できます。 + - 解決策： `Cast(xx as decimal(a, b))`と`a`目標精度として、 `b` } を手動で追加することで、この問題を回避できます。 ### 3.5 クエリの遅延に関する問題 {#35-slow-query-issues} @@ -211,25 +211,25 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND ### 4.1 TiKVがパニックを起こして起動に失敗する {#41-tikv-panics-and-fails-to-start} -- 4.1.1 TiKVが仮想マシンにデプロイされている場合、仮想マシンが強制終了されたり、物理マシンが電源オフになったりすると、 `entries[X, Y] is unavailable from storage`エラーが報告されます。 +- 4.1.1 TiKVが仮想マシンにデプロイされている場合、仮想マシンが強制終了されたり、物理マシンが電源オフになったりすると、 `entries[X, Y] is unavailable from storage`エラーが報告されます。 この問題は想定内のものです。仮想マシンの`fsync`は信頼性が低いため、 `tikv-ctl`を使用してリージョンを復元する必要があります。 -- 4.1.2 その他の予期せぬ原因については、 [バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 +- 4.1.2 その他の予期せぬ原因については、 [バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 ### 4.2 TiKV OOM {#42-tikv-oom} -- 4.2.1 `block-cache`の設定が大きすぎると、メモリ不足が発生する可能性があります。 +- 4.2.1 `block-cache`の設定が大きすぎると、メモリ不足が発生する可能性があります。 問題の原因を確認するには、モニター**Grafana** -> **TiKV-details**で該当するインスタンスを選択して RocksDB の`block cache size`を確認してください。 一方、 `[storage.block-cache] capacity = # "1GB"`パラメータが正しく設定されているか確認してください。デフォルトでは、TiKV の`block-cache`はマシンの総メモリの`45%`に設定されています。TiKV は物理マシンのメモリを取得するため、コンテナのメモリ制限を超える可能性があるため、コンテナに TiKV をデプロイする際にはこのパラメータを明示的に指定する必要があります。 -- 4.2.2コプロセッサーが多数の大きなクエリを受信し、大量のデータを返します。gRPC は、コプロセッサがデータを返す速度に追いつかず、結果としてメモリ不足エラーが発生します。 +- 4.2.2コプロセッサーが多数の大きなクエリを受信し、大量のデータを返します。gRPC は、コプロセッサがデータを返す速度に追いつかず、結果としてメモリ不足エラーが発生します。 原因を確認するには、モニター**Grafana** -> **TiKV-details** -> coprocessor overview を表示して`response size`が`network outbound`のトラフィックを超えているかどうかを確認でき**ます**。 -- 4.2.3 他のコンポーネントがメモリを過剰に消費している。 +- 4.2.3 他のコンポーネントがメモリを過剰に消費している。 この問題は予期せぬものです。 [バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)ことができます。 @@ -237,286 +237,286 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND ビジー状態の具体的な原因を確認するには、モニター**Grafana** -> **TiKV** -> **errors を**確認してください。 `server is busy` 、TiKV のフロー制御メカニズムが原因で発生しており、TiKV が現在過負荷状態にあるため後で再試行することを`tidb/ti-client`に通知します。 -- 4.3.1 TiKV RocksDB は`write stall`を検出します。 +- 4.3.1 TiKV RocksDB は`write stall`を検出します。 TiKV インスタンスには 2 つの RocksDB インスタンスがあり、1 つは`data/raft`にありRaftログを格納し、もう 1 つは`data/db`にあり実際のデータを格納します。ログで`grep "Stalling" RocksDB`を実行すると、停止の具体的な原因を確認できます。RocksDB ログは`LOG`で始まるファイルで、 `LOG`が現在のログです。 `write stall`は RocksDB にネイティブに組み込まれたパフォーマンス低下メカニズムです。RocksDB で`write stall`が発生すると、システムのパフォーマンスが大幅に低下します。バージョン 5.2.0 より前のバージョンでは、TiDB は`ServerIsBusy`に遭遇すると、 `write stall`エラーをクライアントに直接返すことで、すべての書き込み要求をブロックしようとしますが、これにより QPS パフォーマンスが急激に低下する可能性があります。バージョン 5.2.0 以降、TiKV は、スケジューリングレイヤーで書き込み要求を動的に遅延させることで書き込みを抑制する新しいフロー制御メカニズムを導入し、 `server is busy`が発生したときにクライアントに`write stall`を返す以前のメカニズムに取って代わります。新しいフロー制御メカニズムはデフォルトで有効になっており、TiKV は`write stall`および`KvDB` (memtable を除く) の`RaftDB`メカニズムを自動的に無効にします。ただし、保留中のリクエスト数が一定のしきい値を超えると、フロー制御メカニズムは引き続き有効になり、一部またはすべての書き込みリクエストを拒否し、 `server is busy`エラーをクライアントに返します。詳細な説明としきい値については、 [フロー制御構成](/tikv-configuration-file.md#storageflow-control)を参照してください。 - - `server is busy`エラーが、保留中の圧縮バイト数が多すぎるために発生する場合は、 [`soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)および[`hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit)パラメータの値を増やすことで、この問題を軽減できます。 + - `server is busy`エラーが、保留中の圧縮バイト数が多すぎるために発生する場合は、 [`soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)および[`hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit)パラメータの値を増やすことで、この問題を軽減できます。 - - 保留中の圧縮バイト数が`soft-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`192GiB` ) に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し始めます ( `ServerIsBusy`をクライアントに返します)。この場合、このパラメータの値を増やすことができます。たとえば、 `[storage.flow-control] soft-pending-compaction-bytes-limit = "384GiB"`のようにです。 + - 保留中の圧縮バイト数が`soft-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`192GiB` ) に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し始めます ( `ServerIsBusy`をクライアントに返します)。この場合、このパラメータの値を増やすことができます。たとえば、 `[storage.flow-control] soft-pending-compaction-bytes-limit = "384GiB"`のようにです。 - - 保留中の圧縮バイト数が`hard-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`1024GiB` ) に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し始めます ( `ServerIsBusy`をクライアントに返します)。フロー制御メカニズムは`soft-pending-compaction-bytes-limit`のしきい値に達した後に書き込み速度を遅くするため、このシナリオが発生する可能性は低くなります。発生した場合は、このパラメータの値を増やすことができます (たとえば`[storage.flow-control] hard-pending-compaction-bytes-limit = "2048GiB"`など)。 + - 保留中の圧縮バイト数が`hard-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`1024GiB` ) に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し始めます ( `ServerIsBusy`をクライアントに返します)。フロー制御メカニズムは`soft-pending-compaction-bytes-limit`のしきい値に達した後に書き込み速度を遅くするため、このシナリオが発生する可能性は低くなります。発生した場合は、このパラメータの値を増やすことができます (たとえば`[storage.flow-control] hard-pending-compaction-bytes-limit = "2048GiB"`など)。 - - ディスクのI/O容量が長時間にわたって書き込み速度に追いつかない場合は、ディスクの容量を増やすことをお勧めします。ディスクのスループットが上限に達し、書き込みが停止する場合（例えば、SATA SSDはNVMe SSDよりも大幅に低い）、CPUリソースが十分であれば、より高い圧縮率の圧縮アルゴリズムを適用することができます。こうすることで、CPUリソースをディスクリソースに振り向け、ディスクへの負荷を軽減できます。 + - ディスクのI/O容量が長時間にわたって書き込み速度に追いつかない場合は、ディスクの容量を増やすことをお勧めします。ディスクのスループットが上限に達し、書き込みが停止する場合（例えば、SATA SSDはNVMe SSDよりも大幅に低い）、CPUリソースが十分であれば、より高い圧縮率の圧縮アルゴリズムを適用することができます。こうすることで、CPUリソースをディスクリソースに振り向け、ディスクへの負荷を軽減できます。 - - デフォルトのCF圧縮で高圧が検出された場合は、 `[rocksdb.defaultcf] compression-per-level`パラメータを`["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]`から`["no", "no", "zstd", "zstd", "zstd", "zstd", "zstd"]`に変更します。 + - デフォルトのCF圧縮で高圧が検出された場合は、 `[rocksdb.defaultcf] compression-per-level`パラメータを`["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"]`から`["no", "no", "zstd", "zstd", "zstd", "zstd", "zstd"]`に変更します。 - - memtable が多すぎると、処理が停止します。これは通常、インスタント書き込みの量が多く、memtable がディスクにフラッシュされるのが遅い場合に発生します。ディスク書き込み速度を改善できない場合、またこの問題が業務のピーク時にのみ発生する場合は、対応する CF の`max-write-buffer-number`を増やすことで軽減できます。 + - memtable が多すぎると、処理が停止します。これは通常、インスタント書き込みの量が多く、memtable がディスクにフラッシュされるのが遅い場合に発生します。ディスク書き込み速度を改善できない場合、またこの問題が業務のピーク時にのみ発生する場合は、対応する CF の`max-write-buffer-number`を増やすことで軽減できます。 - - 例えば、 `[rocksdb.defaultcf] max-write-buffer-number`を`8`に設定します (デフォルトでは`5`です)。ただし、これにより、メモリ内に保持される memtable が増えるため、ピーク時のメモリ使用量が増加する可能性があることに注意してください。 + - 例えば、 `[rocksdb.defaultcf] max-write-buffer-number`を`8`に設定します (デフォルトでは`5`です)。ただし、これにより、メモリ内に保持される memtable が増えるため、ピーク時のメモリ使用量が増加する可能性があることに注意してください。 -- 4.3.2 `scheduler too busy` +- 4.3.2 `scheduler too busy` - - 深刻な書き込み競合が発生しています。 `latch wait duration`値が高くなります。モニター**Grafana** -> **TiKV-details** -> **scheduler prewrite** / **scheduler commit**で`latch wait duration`を確認できます。スケジューラで書き込みタスクが蓄積されると、保留中の書き込みタスクが`[storage] scheduler-pending-write-threshold` (100MB) で設定されたしきい値を超えます。 `MVCC_CONFLICT_COUNTER`に対応するメトリックを確認することで、原因を検証できます。 + - 深刻な書き込み競合が発生しています。 `latch wait duration`値が高くなります。モニター**Grafana** -> **TiKV-details** -> **scheduler prewrite** / **scheduler commit**で`latch wait duration`を確認できます。スケジューラで書き込みタスクが蓄積されると、保留中の書き込みタスクが`[storage] scheduler-pending-write-threshold` (100MB) で設定されたしきい値を超えます。 `MVCC_CONFLICT_COUNTER`に対応するメトリックを確認することで、原因を検証できます。 - - 書き込み速度が遅いと、書き込みタスクが蓄積されます。TiKV に書き込まれるデータが`[storage] scheduler-pending-write-threshold` (100MB) で設定されたしきい値を超えています[4.5](#45-tikv-write-is-slow)を参照してください。 + - 書き込み速度が遅いと、書き込みタスクが蓄積されます。TiKV に書き込まれるデータが`[storage] scheduler-pending-write-threshold` (100MB) で設定されたしきい値を超えています[4.5](#45-tikv-write-is-slow)を参照してください。 -- 4.3.3 `raftstore is busy` 。メッセージの処理がメッセージの受信よりも遅くなっています。短期間の`channel full`状態はサービスに影響しませんが、エラーが長時間続くとLeaderの切り替えが発生する可能性があります。 +- 4.3.3 `raftstore is busy` 。メッセージの処理がメッセージの受信よりも遅くなっています。短期間の`channel full`状態はサービスに影響しませんが、エラーが長時間続くとLeaderの切り替えが発生する可能性があります。 - - `append log`は停止に遭遇します[4.3.1](#43-the-client-reports-the-server-is-busy-error)を参照してください。 - - `append log duration`値が高いため、メッセージの処理が遅くなります。 `append log duration`値が高い理由については、 [4.5](#45-tikv-write-is-slow)を参照してください。 - - raftstore は、大量のメッセージを瞬時に受信し (TiKV Raftメッセージ ダッシュボードで確認できます)、処理に失敗します。通常、この一時的な`channel full`ステータスはサービスに影響を与えません。 + - `append log`は停止に遭遇します[4.3.1](#43-the-client-reports-the-server-is-busy-error)を参照してください。 + - `append log duration`値が高いため、メッセージの処理が遅くなります。 `append log duration`値が高い理由については、 [4.5](#45-tikv-write-is-slow)を参照してください。 + - raftstore は、大量のメッセージを瞬時に受信し (TiKV Raftメッセージ ダッシュボードで確認できます)、処理に失敗します。通常、この一時的な`channel full`ステータスはサービスに影響を与えません。 -- 4.3.4 TiKV コプロセッサがキューに入っています。スタックされたタスクの数が`coprocessor threads * readpool.coprocessor.max-tasks-per-worker-[normal|low|high]`を超えています。大きなクエリが多すぎると、コプロセッサでタスクがスタックされます。実行計画の変更によってテーブルスキャン操作が大量に発生していないか確認する必要があります[3.3](#33-wrong-execution-plan)を参照してください。 +- 4.3.4 TiKV コプロセッサがキューに入っています。スタックされたタスクの数が`coprocessor threads * readpool.coprocessor.max-tasks-per-worker-[normal|low|high]`を超えています。大きなクエリが多すぎると、コプロセッサでタスクがスタックされます。実行計画の変更によってテーブルスキャン操作が大量に発生していないか確認する必要があります[3.3](#33-wrong-execution-plan)を参照してください。 ### 4.4 一部のTiKVノードは頻繁にLeaderをドロップする {#44-some-tikv-nodes-drop-leader-frequently} -- 4.4.1 TiKVが再起動されたため再選が行われる +- 4.4.1 TiKVが再起動されたため再選が行われる - - TiKVがパニックを起こした後、systemdによって起動され、正常に動作します。TiKVログを確認することで[バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)panicが発生したかどうかを確認できます。この問題は予期しないため、発生した場合。 + - TiKVがパニックを起こした後、systemdによって起動され、正常に動作します。TiKVログを確認することで[バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)panicが発生したかどうかを確認できます。この問題は予期しないため、発生した場合。 - - TiKV が第三者によって停止または強制終了され、その後 systemd によって起動されました。原因を確認するには`dmesg`と TiKV ログを参照してください。 + - TiKV が第三者によって停止または強制終了され、その後 systemd によって起動されました。原因を確認するには`dmesg`と TiKV ログを参照してください。 - - TiKV がメモリ不足のため再起動します[4.2](#42-tikv-oom)を参照してください。 + - 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)を参照してください。 +- 4.4.2 TiKV RocksDB で書き込み停止が発生し、再選出が行われます。モニター**Grafana** -> **TiKV-details** -> **errors**に`server is busy`が表示されているかどうかを確認してください[4.3.1](#43-the-client-reports-the-server-is-busy-error)を参照してください。 -- 4.4.3 ネットワークの孤立による再選出。 +- 4.4.3 ネットワークの孤立による再選出。 ### 4.5 TiKVへの書き込みが遅い {#45-tikv-write-is-slow} -- 4.5.1 TiKV gRPC の`prewrite/commit/raw-put`の継続時間を表示して、TiKV 書き込みが遅いかどうかを確認します (RawKV クラスターの場合のみ)。一般に、 [パフォーマンスマップ](https://github.com/pingcap/tidb-map/blob/master/maps/performance-map.png)に従って遅い段階を特定できます。よくある状況のいくつかを以下に示します。 +- 4.5.1 TiKV gRPC の`prewrite/commit/raw-put`の継続時間を表示して、TiKV 書き込みが遅いかどうかを確認します (RawKV クラスターの場合のみ)。一般に、 [パフォーマンスマップ](https://github.com/pingcap/tidb-map/blob/master/maps/performance-map.png)に従って遅い段階を特定できます。よくある状況のいくつかを以下に示します。 -- 4.5.2 スケジューラのCPUがビジー状態です（トランザクションkvのみ）。 +- 4.5.2 スケジューラのCPUがビジー状態です（トランザクションkvのみ）。 prewrite/commit の`scheduler command duration`が`scheduler latch wait duration`と`storage async write duration`の合計よりも長くなっています。スケジューラワーカーの CPU 要求が高く、例えば`scheduler-worker-pool-size` * 100% の 80% を超えているか、マシン全体の CPU リソースが比較的限られています。書き込みワークロードが大きい場合は、 `[storage] scheduler-worker-pool-size`の設定が小さすぎないか確認してください。 その他の状況については、 [バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 -- 4.5.3 ログの追加処理が遅い。 +- 4.5.3 ログの追加処理が遅い。 TiKV Grafana の**Raft IO** / `append log duration`値が高い場合、通常はディスク書き込み操作が遅いことが原因です。RocksDB - raft の`WAL Sync Duration max`の値を確認することで原因を特定できます。 その他の状況については、 [バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 -- 4.5.4 raftstore スレッドがビジー状態です。 +- 4.5.4 raftstore スレッドがビジー状態です。 **Raft Propose** / `propose wait duration`は、TiKV Grafana の追記ログ期間よりもかなり長くなっています。以下の方法を試してください。 - - `[raftstore] store-pool-size`の設定値が小さすぎないか確認してください。値は`1`と`5`の間に設定し、大きすぎないようにすることをお勧めします。 - - マシンのCPUリソースが不足していないか確認してください。 + - `[raftstore] store-pool-size`の設定値が小さすぎないか確認してください。値は`1`と`5`の間に設定し、大きすぎないようにすることをお勧めします。 + - マシンのCPUリソースが不足していないか確認してください。 -- 4.5.5 適用処理が遅い。 +- 4.5.5 適用処理が遅い。 TiKV Grafana の**Raft IO** / `apply log duration`が高い状態です。これは通常、 **Raft Propose** / `apply wait duration`が高い状態と関連しています。考えられる原因は以下のとおりです。 - - `[raftstore] apply-pool-size`が小さすぎます ( `1`と`5`の間に値を設定し、大きすぎないようにすることをお勧めします)。また、 **Thread CPU** / `apply CPU`が大きいです。 + - `[raftstore] apply-pool-size`が小さすぎます ( `1`と`5`の間に値を設定し、大きすぎないようにすることをお勧めします)。また、 **Thread CPU** / `apply CPU`が大きいです。 - - マシンのCPUリソースが不足しています。 + - マシンのCPUリソースが不足しています。 - - リージョン書き込みホットスポット。単一の適用スレッドでCPU使用率が高くなっています。現在、単一のリージョンでのホットスポット問題を適切に処理することはできませんが、改善中です。各スレッドのCPU使用率を表示するには、Grafana式を変更して`by (instance, name)`を追加してください。 + - リージョン書き込みホットスポット。単一の適用スレッドでCPU使用率が高くなっています。現在、単一のリージョンでのホットスポット問題を適切に処理することはできませんが、改善中です。各スレッドのCPU使用率を表示するには、Grafana式を変更して`by (instance, name)`を追加してください。 - - RocksDBへの書き込みが遅い。RocksDB**のkv** / `max write duration`が高い。1つのRaftログに複数のKVが含まれる可能性がある。RocksDBへの書き込み時には、1回の書き込みバッチで128個のKVがRocksDBに書き込まれる。そのため、適用ログはRocksDBへの複数の書き込みに関連付けられる可能性がある。 + - RocksDBへの書き込みが遅い。RocksDB**のkv** / `max write duration`が高い。1つのRaftログに複数のKVが含まれる可能性がある。RocksDBへの書き込み時には、1回の書き込みバッチで128個のKVがRocksDBに書き込まれる。そのため、適用ログはRocksDBへの複数の書き込みに関連付けられる可能性がある。 - - その他の状況については、 [バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 + - その他の状況については、 [バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 -- 4.5.6 Raftのコミットログが遅い。 +- 4.5.6 Raftのコミットログが遅い。 TiKV Grafana の**Raft IO** / `commit log duration`が高い (このメトリックは Grafana v4.x 以降でのみサポートされています)。各リージョンは独立したRaftグループに対応します。Raftには、TCP のスライディング ウィンドウ メカニズムと同様のフロー制御メカニズムがあります。スライディング ウィンドウのサイズは`[raftstore] raft-max-inflight-msgs = 256`パラメータを設定することで制御できます。書き込みホットスポットがあり、 `commit log duration`が高い場合は、 `1024`に増やすなど、パラメータを調整できます。 -- 4.5.7 その他の場合は、 [パフォーマンスマップ](https://github.com/pingcap/tidb-map/blob/master/maps/performance-map.png)上の書き込みパスを参照し、原因を分析してください。 +- 4.5.7 その他の場合は、 [パフォーマンスマップ](https://github.com/pingcap/tidb-map/blob/master/maps/performance-map.png)上の書き込みパスを参照し、原因を分析してください。 ## 5. PD問題 {#5-pd-issues} ### 5.1 PDスケジューリング {#51-pd-scheduling} -- 5.1.1 マージ +- 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`の値を増やしてください。 + - リージョンのマージは遅いです。マージされたオペレーターが生成されているかどうかは、 **Grafana** -> **PD** -> **operator**のモニターダッシュボードにアクセスして確認できます。マージを高速化するには、 `merge-schedule-limit`の値を増やしてください。 -- 5.1.2 レプリカの追加またはオンライン/オフラインでのレプリカの削除 +- 5.1.2 レプリカの追加またはオンライン/オフラインでのレプリカの削除 - - TiKVディスクが容量の80%を使用し、PDがレプリカを追加しない場合、ミスピア数が増加するため、TiKVをスケールアウトする必要があります。詳細は中国語版の[ケース801](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case801.md)を参照してください。 + - 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 バランス +- 5.1.3 バランス - - Leader/リージョンの数が均等に分布していません。中国語の[ケース394](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case394.md)と[ケース759](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case759.md)を参照してください。主な原因は、バランス調整がリージョン/Leaderのサイズに基づいてスケジューリングを実行するため、数の分布が不均等になる可能性があることです。TiDB 4.0では、 `[leader-schedule-policy]`パラメータが導入され、Leaderのスケジューリングポリシーを`count`ベースまたは`size`ベースに設定できるようになりました。 + - Leader/リージョンの数が均等に分布していません。中国語の[ケース394](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case394.md)と[ケース759](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case759.md)を参照してください。主な原因は、バランス調整がリージョン/Leaderのサイズに基づいてスケジューリングを実行するため、数の分布が不均等になる可能性があることです。TiDB 4.0では、 `[leader-schedule-policy]`パラメータが導入され、Leaderのスケジューリングポリシーを`count`ベースまたは`size`ベースに設定できるようになりました。 ### 5.2 PD選挙 {#52-pd-election} -- 5.2.1 PD スイッチLeader。 +- 5.2.1 PD スイッチLeader。 - - 原因1：ディスク。PDノードが配置されているディスクのI/O負荷が最大になっています。PDがI/O負荷の高い他のコンポーネントと一緒にデプロイされているかどうか、およびディスクの状態を調査してください。**Grafana** -> **disk performance** -> **latency**/**load**でモニターメトリックを確認することで原因を特定できます。必要に応じて、FIOツールを使用してディスクのチェックを実行することもできます。中国語の[ケース292](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case292.md)を参照してください。 + - 原因1：ディスク。PDノードが配置されているディスクのI/O負荷が最大になっています。PDがI/O負荷の高い他のコンポーネントと一緒にデプロイされているかどうか、およびディスクの状態を調査してください。**Grafana** -> **disk performance** -> **latency**/**load**でモニターメトリックを確認することで原因を特定できます。必要に応じて、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を選出できないか、選挙が遅い。 +- 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 では、 `use-region-storage`を`true`に設定することで`region storage`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。詳細は、 [ケース429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md) （中国語）を参照してください。 + - 選挙が遅い：リージョンの読み込み時間が長い。この問題は、PD ログで`grep "regions cost"`を実行することで確認できます。結果が`load 460927 regions cost 11.77099s`のように秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0 では、 `use-region-storage`を`true`に設定することで`region storage`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。詳細は、 [ケース429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md) （中国語）を参照してください。 -- 5.2.3 TiDBがSQLステートメントを実行する際にPDがタイムアウトしました。 +- 5.2.3 TiDBがSQLステートメントを実行する際にPDがタイムアウトしました。 - - PDにはLeaderが存在しない、またはLeaderが切り替わります[5.2.1](#52-pd-election)および[5.2.2](#52-pd-election)を参照してください。 + - PDにはLeaderが存在しない、またはLeaderが切り替わります[5.2.1](#52-pd-election)および[5.2.2](#52-pd-election)を参照してください。 - - ネットワークの問題です。Grafana -> **blackbox_exporter** -> **ping レイテンシー**モニターにアクセスして、 **TiDB**から PD Leaderへのネットワークが正常に動作しているかどうかを確認してください。 + - ネットワークの問題です。Grafana -> **blackbox_exporter** -> **ping レイテンシー**モニターにアクセスして、 **TiDB**から PD Leaderへのネットワークが正常に動作しているかどうかを確認してください。 - - PD パニック。 [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 + - PD パニック。 [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 - - PDはOOMです[5.3](#53-pd-oom)を参照してください。 + - PDはOOMです[5.3](#53-pd-oom)を参照してください。 - - 問題に他の原因がある場合は、 `curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2`を実行して goroutine を取得し、 [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 + - 問題に他の原因がある場合は、 `curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2`を実行して goroutine を取得し、 [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 -- 5.2.4 その他の問題 +- 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)。 + - その他の状況については、 [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 ### 5.3 PD OOM {#53-pd-oom} -- 5.3.1 `/api/v1/regions`インターフェースを使用する場合、リージョンが多すぎると PD OOM が発生する可能性があります。この問題は v3.0.8 ( [#1986](https://github.com/pingcap/pd/pull/1986) ) で修正されました。 +- 5.3.1 `/api/v1/regions`インターフェースを使用する場合、リージョンが多すぎると PD OOM が発生する可能性があります。この問題は v3.0.8 ( [#1986](https://github.com/pingcap/pd/pull/1986) ) で修正されました。 -- 5.3.2 ローリングアップグレード中にPD OOMが発生します。gRPCメッセージのサイズに制限がなく、モニターにはTCP InSegsが比較的大きいことが示されています。この問題はv3.0.6で修正されました（ [#1952](https://github.com/pingcap/pd/pull/1952) ）。 +- 5.3.2 ローリングアップグレード中にPD OOMが発生します。gRPCメッセージのサイズに制限がなく、モニターにはTCP InSegsが比較的大きいことが示されています。この問題はv3.0.6で修正されました（ [#1952](https://github.com/pingcap/pd/pull/1952) ）。 ### 5.4 Grafanaの表示 {#54-grafana-display} -- 5.4.1 **Grafana** -> **PD** -> **cluster** -> **role**のモニターにフォロワーが表示されます。Grafana の式に関する問題は v3.0.8 で修正されました。 +- 5.4.1 **Grafana** -> **PD** -> **cluster** -> **role**のモニターにフォロワーが表示されます。Grafana の式に関する問題は v3.0.8 で修正されました。 ## 6. エコシステムツール {#6-ecosystem-tools} ### 6.1 データ移行 {#61-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`を実行したとき、またはログを確認したときに表示されます。 +- 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設定ファイル内のデータベース関連のパスワードは`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)を参照してください。 -- 6.1.3 レプリケーション タスクが`driver: bad connection`エラーで中断されました。 +- 6.1.3 レプリケーション タスクが`driver: bad connection`エラーで中断されました。 - - `driver: bad connection`エラーは、DM と下流の TiDB データベース間の接続で異常が発生したこと (ネットワーク障害や TiDB の再起動など) と、現在のリクエストのデータがまだ TiDB に送信されていないことを示しています。 + - `driver: bad connection`エラーは、DM と下流の TiDB データベース間の接続で異常が発生したこと (ネットワーク障害や TiDB の再起動など) と、現在のリクエストのデータがまだ TiDB に送信されていないことを示しています。 - - DM 1.0.0 GA より前のバージョンでは、 `stop-task`を実行してタスクを停止し、 `start-task`を実行してタスクを再起動します。 - - DM 1.0.0 GA以降のバージョンでは、この種のエラーに対する自動再試行メカニズムが追加されています。詳細は[#265](https://github.com/pingcap/dm/pull/265)を参照してください。 + - DM 1.0.0 GA より前のバージョンでは、 `stop-task`を実行してタスクを停止し、 `start-task`を実行してタスクを再起動します。 + - DM 1.0.0 GA以降のバージョンでは、この種のエラーに対する自動再試行メカニズムが追加されています。詳細は[#265](https://github.com/pingcap/dm/pull/265)を参照してください。 -- 6.1.4 レプリケーション タスクが`invalid connection`エラーで中断されました。 +- 6.1.4 レプリケーション タスクが`invalid connection`エラーで中断されました。 - - `invalid connection`エラーは、DM と下流の TiDB データベース間の接続で異常 (ネットワーク障害、TiDB の再起動、TiKV のビジーなど) が発生し、現在のリクエストのデータの一部が TiDB に送信されたことを示しています。DM はレプリケーション タスクで下流にデータを同時にレプリケートする機能があるため、タスクが中断されるといくつかのエラーが発生する可能性があります。これらのエラーは`query-status`または`query-error`を実行して確認できます。 + - `invalid connection`エラーは、DM と下流の TiDB データベース間の接続で異常 (ネットワーク障害、TiDB の再起動、TiKV のビジーなど) が発生し、現在のリクエストのデータの一部が TiDB に送信されたことを示しています。DM はレプリケーション タスクで下流にデータを同時にレプリケートする機能があるため、タスクが中断されるといくつかのエラーが発生する可能性があります。これらのエラーは`query-status`または`query-error`を実行して確認できます。 - - 増分レプリケーション処理中に`invalid connection`エラーのみが発生した場合、DM はタスクを自動的に再試行します。 - - DM がリトライしない、またはバージョン問題のために自動的にリトライできない場合 (自動リトライは v1.0.0-rc.1 で導入されました)、 `stop-task`を使用してタスクを停止し、 `start-task`を使用してタスクを再起動します。 + - 増分レプリケーション処理中に`invalid connection`エラーのみが発生した場合、DM はタスクを自動的に再試行します。 + - DM がリトライしない、またはバージョン問題のために自動的にリトライできない場合 (自動リトライは v1.0.0-rc.1 で導入されました)、 `stop-task`を使用してタスクを停止し、 `start-task`を使用してタスクを再起動します。 -- 6.1.5 リレーユニットがエラー`event from * in * diff from passed-in event *`を報告するか、レプリケーション タスクがbinlogの取得または解析に失敗するエラー（例: `get binlog error ERROR 1236 (HY000) and binlog checksum mismatch, data may be corrupted returned`で中断される。 +- 6.1.5 リレーユニットがエラー`event from * in * diff from passed-in event *`を報告するか、レプリケーション タスクがbinlogの取得または解析に失敗するエラー（例: `get binlog error ERROR 1236 (HY000) and binlog checksum mismatch, data may be corrupted returned`で中断される。 - - DMがリレーログを取得するプロセス、または増分レプリケーションのプロセス中に、アップストリームのbinlogファイルのサイズが4GBを超えると、次の2つのエラーが発生する可能性があります。 + - DMがリレーログを取得するプロセス、または増分レプリケーションのプロセス中に、アップストリームのbinlogファイルのサイズが4GBを超えると、次の2つのエラーが発生する可能性があります。 - - 原因：リレーログを書き込む際、DMはbinlogの位置とbinlogファイルのサイズに基づいてイベント検証を行い、複製されたbinlogの位置をチェックポイントとして保存する必要があります。しかし、公式のMySQLはbinlogの位置を保存するためにuint32を使用しているため、4GBを超えるbinlogファイルのbinlogの位置がオーバーフローし、上記のエラーが発生します。 + - 原因：リレーログを書き込む際、DMはbinlogの位置とbinlogファイルのサイズに基づいてイベント検証を行い、複製されたbinlogの位置をチェックポイントとして保存する必要があります。しかし、公式のMySQLはbinlogの位置を保存するためにuint32を使用しているため、4GBを超えるbinlogファイルのbinlogの位置がオーバーフローし、上記のエラーが発生します。 - - 解決： + - 解決： - - 中継処理装置の場合、 [レプリケーションを手動で復旧する](https://pingcap.com/docs/tidb-data-migration/dev/error-handling/#the-relay-unit-throws-error-event-from--in--diff-from-passed-in-event--or-a-replication-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)。 - - binlogレプリケーション処理ユニットの場合、 [レプリケーションを手動で復旧する](https://pingcap.com/docs/tidb-data-migration/dev/error-handling/#the-relay-unit-throws-error-event-from--in--diff-from-passed-in-event--or-a-replication-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)。 + - 中継処理装置の場合、 [レプリケーションを手動で復旧する](https://pingcap.com/docs/tidb-data-migration/dev/error-handling/#the-relay-unit-throws-error-event-from--in--diff-from-passed-in-event--or-a-replication-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)。 + - binlogレプリケーション処理ユニットの場合、 [レプリケーションを手動で復旧する](https://pingcap.com/docs/tidb-data-migration/dev/error-handling/#the-relay-unit-throws-error-event-from--in--diff-from-passed-in-event--or-a-replication-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)。 -- 6.1.6 DMレプリケーションが中断され、ログに`ERROR 1236 (HY000) The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.`が返されます。 +- 6.1.6 DMレプリケーションが中断され、ログに`ERROR 1236 (HY000) The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires.`が返されます。 - - マスターbinlogがパージされているかどうかを確認してください。 - - `relay.meta`に記録されている位置情報を確認してください。 + - マスターbinlogがパージされているかどうかを確認してください。 + - `relay.meta`に記録されている位置情報を確認してください。 - - `relay.meta`は空の GTID 情報を記録しました。DM-worker は終了時または 30 秒ごとに、メモリ内の GTID 情報を`relay.meta`に保存します。DM-worker が上流の GTID 情報を取得できない場合は、空の GTID 情報を`relay.meta`に保存します。詳細は、 [ケース772](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case772.md) （中国語）を参照してください。 + - `relay.meta`は空の GTID 情報を記録しました。DM-worker は終了時または 30 秒ごとに、メモリ内の GTID 情報を`relay.meta`に保存します。DM-worker が上流の GTID 情報を取得できない場合は、空の GTID 情報を`relay.meta`に保存します。詳細は、 [ケース772](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case772.md) （中国語）を参照してください。 - - `relay.meta`に記録されたbinlogイベントにより、不完全なリカバリプロセスがトリガーされ、誤ったGTID情報が記録されます。この問題はv1.0.2で修正されていますが、それ以前のバージョンでは発生する可能性があります。 + - `relay.meta`に記録されたbinlogイベントにより、不完全なリカバリプロセスがトリガーされ、誤ったGTID情報が記録されます。この問題はv1.0.2で修正されていますが、それ以前のバージョンでは発生する可能性があります。 -- 6.1.7 DM レプリケーション プロセスでエラー`Error 1366: incorrect utf8 value eda0bdedb29d(\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd)`が返されます。 +- 6.1.7 DM レプリケーション プロセスでエラー`Error 1366: incorrect utf8 value eda0bdedb29d(\ufffd\ufffd\ufffd\ufffd\ufffd\ufffd)`が返されます。 - - この値は MySQL 8.0 または TiDB には正常に書き込めませんが、 MySQL 5.7には書き込めます。 `tidb_skip_utf8_check`パラメータを有効にすることで、データ形式のチェックをスキップできます。 + - この値は MySQL 8.0 または TiDB には正常に書き込めませんが、 MySQL 5.7には書き込めます。 `tidb_skip_utf8_check`パラメータを有効にすることで、データ形式のチェックをスキップできます。 ### 6.2 TiDB Lightning {#62-tidb-lightning} -- 6.2.1 TiDB Lightningは、大量のデータを TiDB クラスタに高速に完全インポートするためのツールです。TiDB [TiDB Lightning （GitHub）](https://github.com/pingcap/tidb/tree/release-8.5/lightning)を参照してください。 +- 6.2.1 TiDB Lightningは、大量のデータを TiDB クラスタに高速に完全インポートするためのツールです。TiDB [TiDB Lightning （GitHub）](https://github.com/pingcap/tidb/tree/release-8.5/lightning)を参照してください。 -- 6.2.2 インポート速度が遅すぎる。 +- 6.2.2 インポート速度が遅すぎる。 - - `region-concurrency`設定値が高すぎるため、スレッド競合が発生し、パフォーマンスが低下します。トラブルシューティング方法は次の 3 つです。 + - `region-concurrency`設定値が高すぎるため、スレッド競合が発生し、パフォーマンスが低下します。トラブルシューティング方法は次の 3 つです。 - - 設定は、ログの先頭から`region-concurrency`検索することで見つけることができます。 - - TiDB Lightning が他のサービス (たとえば Importer) とサーバーを共有している場合は、 `region-concurrency`そのサーバーの CPU コアの総数の 75% に手動で設定する必要があります。 - - CPU にクォータが設定されている場合 (例えば、Kubernetes の設定によって制限されている場合)、 TiDB Lightning はこの値を読み取れない可能性があります。この場合、 `region-concurrency`も手動で減らす必要があります。 + - 設定は、ログの先頭から`region-concurrency`検索することで見つけることができます。 + - TiDB Lightning が他のサービス (たとえば Importer) とサーバーを共有している場合は、 `region-concurrency`そのサーバーの CPU コアの総数の 75% に手動で設定する必要があります。 + - CPU にクォータが設定されている場合 (例えば、Kubernetes の設定によって制限されている場合)、 TiDB Lightning はこの値を読み取れない可能性があります。この場合、 `region-concurrency`も手動で減らす必要があります。 - - インデックスを追加するたびに、各行に新しいキーバリューペアが追加されます。インデックスがN個ある場合、実際にインポートされるサイズは、 [Dumpling](/dumpling-overview.md)出力のサイズのおよそ(N+1)倍になります。インデックスが無視できるほど小さい場合は、最初にスキーマからインデックスを削除し、インポート完了後に`CREATE INDEX`を使用して再度追加することができます。 + - インデックスを追加するたびに、各行に新しいキーバリューペアが追加されます。インデックスがN個ある場合、実際にインポートされるサイズは、 [Dumpling](/dumpling-overview.md)出力のサイズのおよそ(N+1)倍になります。インデックスが無視できるほど小さい場合は、最初にスキーマからインデックスを削除し、インポート完了後に`CREATE INDEX`を使用して再度追加することができます。 - - TiDB Lightningのバージョンが古いです。最新バージョンをお試しください。インポート速度が向上する可能性があります。 + - TiDB Lightningのバージョンが古いです。最新バージョンをお試しください。インポート速度が向上する可能性があります。 -- 6.2.3 `checksum failed: checksum mismatched remote vs local` 。 +- 6.2.3 `checksum failed: checksum mismatched remote vs local` 。 - - 原因１：テーブルに既にデータが存在する可能性があります。これらの古いデータは最終的なチェックサムに影響を与える可能性があります。 + - 原因１：テーブルに既にデータが存在する可能性があります。これらの古いデータは最終的なチェックサムに影響を与える可能性があります。 - - 原因2：ターゲットデータベースのチェックサムが0（つまり何もインポートされていない）の場合、クラスタが過熱していてデータの取り込みに失敗している可能性があります。 + - 原因2：ターゲットデータベースのチェックサムが0（つまり何もインポートされていない）の場合、クラスタが過熱していてデータの取り込みに失敗している可能性があります。 - - 原因3：データソースがマシンによって生成され、 [Dumpling](/dumpling-overview.md)によってバックアップされていない場合は、テーブルの制約を遵守していることを確認してください。例： + - 原因3：データソースがマシンによって生成され、 [Dumpling](/dumpling-overview.md)によってバックアップされていない場合は、テーブルの制約を遵守していることを確認してください。例： - - `AUTO_INCREMENT`列は正の値である必要があり、「0」という値を含んではいけません。 - - UNIQUEキーとPRIMARYキーには重複するエントリがあってはなりません。 + - `AUTO_INCREMENT`列は正の値である必要があり、「0」という値を含んではいけません。 + - UNIQUEキーとPRIMARYキーには重複するエントリがあってはなりません。 - - 解決策: [トラブルシューティングソリューション](/tidb-lightning/troubleshoot-tidb-lightning.md#checksum-failed-checksum-mismatched-remote-vs-local)を参照してください。 + - 解決策: [トラブルシューティングソリューション](/tidb-lightning/troubleshoot-tidb-lightning.md#checksum-failed-checksum-mismatched-remote-vs-local)を参照してください。 -- 6.2.4 `Checkpoint for … has invalid status:(error code)` +- 6.2.4 `Checkpoint for … has invalid status:(error code)` - - 原因：チェックポイントが有効になっており、Lightning/Importerが以前に異常終了しています。データの破損を防ぐため、エラーが解消されるまでTiDB Lightningは起動しません。エラーコードは25未満の整数で、 `0, 3, 6, 9, 12, 14, 15, 17, 18, 20 and 21`などの値になります。この整数は、インポート処理で予期しない終了が発生したステップを示します。整数値が大きいほど、終了が発生したステップが遅くなります。 + - 原因：チェックポイントが有効になっており、Lightning/Importerが以前に異常終了しています。データの破損を防ぐため、エラーが解消されるまでTiDB Lightningは起動しません。エラーコードは25未満の整数で、 `0, 3, 6, 9, 12, 14, 15, 17, 18, 20 and 21`などの値になります。この整数は、インポート処理で予期しない終了が発生したステップを示します。整数値が大きいほど、終了が発生したステップが遅くなります。 - - 解決策: [トラブルシューティングソリューション](/tidb-lightning/troubleshoot-tidb-lightning.md#checkpoint-for--has-invalid-status-error-code)を参照してください。 + - 解決策: [トラブルシューティングソリューション](/tidb-lightning/troubleshoot-tidb-lightning.md#checkpoint-for--has-invalid-status-error-code)を参照してください。 -- 6.2.5 `cannot guess encoding for input file, please convert to UTF-8 manually` +- 6.2.5 `cannot guess encoding for input file, please convert to UTF-8 manually` - - 原因： TiDB LightningはUTF-8とGB-18030エンコーディングのみをサポートしています。このエラーは、ファイルがこれらのいずれのエンコーディングでもないことを意味しています。また、過去のALTER TABLE実行により、ファイルにUTF-8の文字列とGB-18030の文字列が混在している可能性もあります。 + - 原因： TiDB LightningはUTF-8とGB-18030エンコーディングのみをサポートしています。このエラーは、ファイルがこれらのいずれのエンコーディングでもないことを意味しています。また、過去のALTER TABLE実行により、ファイルにUTF-8の文字列とGB-18030の文字列が混在している可能性もあります。 - - 解決策: [トラブルシューティングソリューション](/tidb-lightning/troubleshoot-tidb-lightning.md#cannot-guess-encoding-for-input-file-please-convert-to-utf-8-manually)を参照してください。 + - 解決策: [トラブルシューティングソリューション](/tidb-lightning/troubleshoot-tidb-lightning.md#cannot-guess-encoding-for-input-file-please-convert-to-utf-8-manually)を参照してください。 -- 6.2.6 `[sql2kv] sql encode error = [types:1292]invalid time format: '{1970 1 1 0 45 0 0}'` +- 6.2.6 `[sql2kv] sql encode error = [types:1292]invalid time format: '{1970 1 1 0 45 0 0}'` - - 原因：タイムスタンプ型のエントリに、存在しない時刻値が含まれています。これは、夏時間の変更、または時刻値がサポート範囲（1970年1月1日から2038年1月19日まで）を超えていることが原因です。 + - 原因：タイムスタンプ型のエントリに、存在しない時刻値が含まれています。これは、夏時間の変更、または時刻値がサポート範囲（1970年1月1日から2038年1月19日まで）を超えていることが原因です。 - - 解決策: [トラブルシューティングソリューション](/tidb-lightning/troubleshoot-tidb-lightning.md#sql2kv-sql-encode-error--types1292invalid-time-format-1970-1-1-)を参照してください。 + - 解決策: [トラブルシューティングソリューション](/tidb-lightning/troubleshoot-tidb-lightning.md#sql2kv-sql-encode-error--types1292invalid-time-format-1970-1-1-)を参照してください。 ## 7. 一般的なログ分析 {#7-common-log-analysis} ### 7.1 TiDB {#71-tidb} -- 7.1.1 `GC life time is shorter than transaction duration` 。 +- 7.1.1 `GC life time is shorter than transaction duration` 。 トランザクションの実行時間がGCの有効期間（デフォルトでは10分）を超えています。 [`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)システム変数を変更することで、GC の有効期間を延長できます。ただし、このパラメータを変更することは一般的に推奨されません。このトランザクションに`UPDATE`および`DELETE`ステートメントが多数含まれている場合、このパラメータを変更すると、多くの古いバージョンが蓄積される可能性があるためです。 -- 7.1.2 `coprocessor.go`は`request outdated`を報告します。 +- 7.1.2 `coprocessor.go`は`request outdated`を報告します。 このエラーは、TiKVに送信されたコプロセッサ要求がTiKVのキューで60秒以上待機した場合に返されます。 TiKVコプロセッサが長いキューに入っている理由を調査する必要があります。 -- 7.1.3 `region_cache.go`は`switch region peer to next due to send request fail`を多数報告し、エラー メッセージは`context deadline exceeded`です。 +- 7.1.3 `region_cache.go`は`switch region peer to next due to send request fail`を多数報告し、エラー メッセージは`context deadline exceeded`です。 TiKV へのリクエストがタイムアウトし、リージョン キャッシュがリクエストを他のノードに切り替えるようにトリガーされました。ログの`grep " cancelled`フィールドで`addr`コマンドを引き続き実行し、 `grep`の結果に応じて以下の手順を実行してください。 - - `send request is cancelled` : 送信フェーズ中にリクエストがタイムアウトしました。Grafana -> **TiDB** -> **Batch Client** / `Pending Request Count by TiKV`の監視**画面**で、保留中のリクエスト数が 128 を超えているかどうかを確認してください。 + - `send request is cancelled` : 送信フェーズ中にリクエストがタイムアウトしました。Grafana -> **TiDB** -> **Batch Client** / `Pending Request Count by TiKV`の監視**画面**で、保留中のリクエスト数が 128 を超えているかどうかを確認してください。 - - 値が128より大きい場合、送信はKVの処理能力を超え、送信が蓄積されます。 - - 値が128を超えない場合は、ログを確認して、レポートが該当するKVの運用および保守の変更によって発生したかどうかを確認してください。そうでない場合は、このエラーは予期しないものであり、 [バグを報告する](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)必要があります。 + - 値が128より大きい場合、送信はKVの処理能力を超え、送信が蓄積されます。 + - 値が128を超えない場合は、ログを確認して、レポートが該当するKVの運用および保守の変更によって発生したかどうかを確認してください。そうでない場合は、このエラーは予期しないものであり、 [バグを報告する](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)必要があります。 - - `wait response is cancelled` : リクエストが TiKV に送信された後、タイムアウトしました。対応する TiKV アドレスの応答時間と、その時点の PD および KV のリージョンログを確認する必要があります。 + - `wait response is cancelled` : リクエストが TiKV に送信された後、タイムアウトしました。対応する TiKV アドレスの応答時間と、その時点の PD および KV のリージョンログを確認する必要があります。 -- 7.1.4 `distsql.go`は`inconsistent index`を報告します。 +- 7.1.4 `distsql.go`は`inconsistent index`を報告します。 データインデックスに矛盾があるようです。報告されたインデックスが存在するテーブルで`admin check table `コマンドを実行してください。チェックが失敗した場合は、次のコマンドを実行して[バグを報告する](https://github.com/pingcap/tidb/issues/new?labels=type%2Fbug&template=bug-report.md)ガベージコレクションを無効にしてください。: @@ -526,31 +526,31 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND ### 7.2 TiKV {#72-tikv} -- 7.2.1 `key is locked` 。 +- 7.2.1 `key is locked` 。 読み取りと書き込みが競合しています。読み取り要求は、コミットされていないデータに遭遇したため、データがコミットされるまで待機する必要があります。 このエラーの発生件数が少ない場合は業務に影響はありませんが、発生件数が多い場合は、業務において読み書きの競合が深刻であることを示しています。 -- 7.2.2 `write conflict` 。 +- 7.2.2 `write conflict` 。 これは、楽観的トランザクションにおける書き込み競合です。複数のトランザクションが同じキーを変更した場合、1つのトランザクションのみが成功し、他のトランザクションは自動的にタイムスタンプを再取得して操作を再試行するため、業務に影響はありません。 競合が深刻な場合は、複数回の再試行後にトランザクションが失敗する可能性があります。この場合、悲観的ロックを使用することをお勧めします。エラーと解決策の詳細については、[楽観的トランザクションにおける書き込み競合のトラブルシューティング](/troubleshoot-write-conflicts.md)を参照してください。 -- 7.2.3 `TxnLockNotFound` 。 +- 7.2.3 `TxnLockNotFound` 。 このトランザクションのコミットが遅すぎるため、有効期限（TTL）経過後に他のトランザクションによってロールバックされます。このトランザクションは自動的に再試行されるため、通常は業務に影響はありません。トランザクションのサイズが0.25MB以下の場合、デフォルトのTTLは3秒です。詳細については、 [`LockNotFound`エラー](/troubleshoot-lock-conflicts.md#locknotfound-error)を参照してください。 -- 7.2.4 `PessimisticLockNotFound` 。 +- 7.2.4 `PessimisticLockNotFound` 。 `TxnLockNotFound`と同様です。悲観的トランザクションのコミットが遅すぎるため、他のトランザクションによってロールバックされます。 -- 7.2.5 `stale_epoch` 。 +- 7.2.5 `stale_epoch` 。 リクエストのエポックが古いため、TiDB はルーティングを更新した後にリクエストを再送信します。業務への影響はありません。エポックは、リージョンで分割/マージ操作が行われた場合、またはレプリカが移行された場合に変更されます。 -- 7.2.6 `peer is not leader` 。 +- 7.2.6 `peer is not leader` 。 リクエストはLeaderではないレプリカに送信されます。エラー応答で最新のLeaderがどのレプリカであるかが示された場合、TiDB はエラーに基づいてローカルルーティングを更新し、最新のLeaderに新しいリクエストを送信します。通常、業務には影響はありません。 diff --git a/tidb-upgrade-migration-guide.md b/tidb-upgrade-migration-guide.md index 67b7174ba1bf3..df829d009df82 100644 --- a/tidb-upgrade-migration-guide.md +++ b/tidb-upgrade-migration-guide.md @@ -7,17 +7,17 @@ summary: 完全バックアップと復元のためのBRと、増分データレ このドキュメントでは、 [BR](/br/backup-and-restore-overview.md)で完全バックアップとリストアを行い、 [TiCDC](/ticdc/ticdc-overview.md)で増分データレプリケーションを行う TiDB クラスタの移行とアップグレード（ブルーグリーンアップグレードとも呼ばれます）方法について説明します。このソリューションは、デュアルクラスタ冗長性と増分レプリケーションを使用することで、スムーズなトラフィック切り替えと高速ロールバックを実現し、重要なシステムに信頼性が高くリスクの低いアップグレードパスを提供します。パフォーマンスの向上と新機能のメリットを継続的に享受し、安全で効率的なデータベースシステムを維持するために、データベースバージョンを定期的にアップグレードすることをお勧めします。このソリューションの主な利点は次のとおりです。 -- **制御可能なリスク**: 数分以内に元のクラスターへのロールバックをサポートし、ビジネスの継続性を確保します。 -- **データ整合性**: 多段階の検証メカニズムを使用してデータ損失を防ぎます。 -- **ビジネスへの影響は最小限**: 最終的な切り替えには短いメンテナンス期間のみが必要です。 +- **制御可能なリスク**: 数分以内に元のクラスターへのロールバックをサポートし、ビジネスの継続性を確保します。 +- **データ整合性**: 多段階の検証メカニズムを使用してデータ損失を防ぎます。 +- **ビジネスへの影響は最小限**: 最終的な切り替えには短いメンテナンス期間のみが必要です。 移行とアップグレードのコアワークフローは次のとおりです。 -1. **リスクの事前チェック**: クラスターの状態とソリューションの実現可能性を確認します。 -2. **新しいクラスターを準備します**。古いクラスターの完全バックアップから新しいクラスターを作成し、それをターゲット バージョンにアップグレードします。 -3. **増分データを複製する**: TiCDC を使用して順方向データ複製チャネルを確立します。 -4. **切り替えと検証**: 多次元検証を実行し、ビジネス トラフィックを新しいクラスターに切り替え、TiCDC リバース レプリケーション チャネルを設定します。 -5. **ステータスの監視**：リバースレプリケーションチャネルを維持します。監視期間終了後、環境をクリーンアップします。 +1. **リスクの事前チェック**: クラスターの状態とソリューションの実現可能性を確認します。 +2. **新しいクラスターを準備します**。古いクラスターの完全バックアップから新しいクラスターを作成し、それをターゲット バージョンにアップグレードします。 +3. **増分データを複製する**: TiCDC を使用して順方向データ複製チャネルを確立します。 +4. **切り替えと検証**: 多次元検証を実行し、ビジネス トラフィックを新しいクラスターに切り替え、TiCDC リバース レプリケーション チャネルを設定します。 +5. **ステータスの監視**：リバースレプリケーションチャネルを維持します。監視期間終了後、環境をクリーンアップします。 **ロールバック プラン**: 移行およびアップグレード プロセス中に新しいクラスターで問題が発生した場合、いつでもビジネス トラフィックを元のクラスターに戻すことができます。 @@ -27,20 +27,20 @@ summary: 完全バックアップと復元のためのBRと、増分データレ 移行およびアップグレードを行う前に、関連コンポーネントの互換性を評価し、クラスターの健全性状態を確認します。 -- TiDB クラスターのバージョンを確認します。このソリューションは、TiDB v6.5.0 以降のバージョンに適用されます。 +- TiDB クラスターのバージョンを確認します。このソリューションは、TiDB v6.5.0 以降のバージョンに適用されます。 -- TiCDC の互換性を確認します。 +- TiCDC の互換性を確認します。 - - **テーブルスキーマの要件**：レプリケートするテーブルに有効なインデックスが含まれていることを確認してください。詳細については、 [TiCDC有効インデックス](/ticdc/ticdc-overview.md#valid-index)を参照してください。 - - **機能制限**：TiCDCはシーケンスDDLレプリケーションまたはTiFlash DDLレプリケーションをサポートしていません。詳細については、 [TiCDC がサポートしていないシナリオ](/ticdc/ticdc-overview.md#unsupported-scenarios)を参照してください。 - - **ベスト プラクティス**: スイッチオーバー中に TiCDC のアップストリーム クラスターで DDL 操作を実行しないでください。 + - **テーブルスキーマの要件**：レプリケートするテーブルに有効なインデックスが含まれていることを確認してください。詳細については、 [TiCDC有効インデックス](/ticdc/ticdc-overview.md#valid-index)を参照してください。 + - **機能制限**：TiCDCはシーケンスDDLレプリケーションまたはTiFlash DDLレプリケーションをサポートしていません。詳細については、 [TiCDC がサポートしていないシナリオ](/ticdc/ticdc-overview.md#unsupported-scenarios)を参照してください。 + - **ベスト プラクティス**: スイッチオーバー中に TiCDC のアップストリーム クラスターで DDL 操作を実行しないでください。 -- BRの互換性を確認します。 +- 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)健全性やノードのリソース使用率など、クラスターの健全性状態を確認します。 +- [リージョン](/glossary.md#regionpeerraft-group)健全性やノードのリソース使用率など、クラスターの健全性状態を確認します。 ## ステップ2: 新しいクラスターを準備する {#step-2-prepare-the-new-cluster} @@ -65,41 +65,41 @@ SET GLOBAL tidb_gc_life_time=60h; 完全なデータを新しいクラスターに移行するときは、次の点に注意してください。 -- **バージョンの互換性**: バックアップと復元に使用されるBRバージョンは、古いクラスターのメジャー バージョンと一致する必要があります。 +- **バージョンの互換性**: バックアップと復元に使用されるBRバージョンは、古いクラスターのメジャー バージョンと一致する必要があります。 -- **パフォーマンスへの影響**： BRバックアップはシステムリソースを消費します。ビジネスへの影響を最小限に抑えるには、オフピーク時間帯にバックアップを実行してください。 +- **パフォーマンスへの影響**： BRバックアップはシステムリソースを消費します。ビジネスへの影響を最小限に抑えるには、オフピーク時間帯にバックアップを実行してください。 -- **時間の見積もり**: 最適なハードウェア条件 (ディスク I/O またはネットワーク帯域幅のボトルネックがない) では、推定時間は次のとおりです。 +- **時間の見積もり**: 最適なハードウェア条件 (ディスク I/O またはネットワーク帯域幅のボトルネックがない) では、推定時間は次のとおりです。 - - バックアップ速度: 8 つのスレッドで TiKV ノードごとに 1 TiB のデータのバックアップに約 1 時間かかります。 - - 復元速度: TiKV ノードごとに 1 TiB のデータの復元には約 20 分かかります。 + - バックアップ速度: 8 つのスレッドで TiKV ノードごとに 1 TiB のデータのバックアップに約 1 時間かかります。 + - 復元速度: TiKV ノードごとに 1 TiB のデータの復元には約 20 分かかります。 -- **コンフィグレーションの整合性**：古いクラスタと新しいクラスタの構成が[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)であることを確認してください。同一でない場合、 BRの復元は失敗します。 +- **コンフィグレーションの整合性**：古いクラスタと新しいクラスタの構成が[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)であることを確認してください。同一でない場合、 BRの復元は失敗します。 -- **システム テーブルの復元**: BR復元中に`--with-sys-table`オプションを使用して、システム テーブル データを復元します。 +- **システム テーブルの復元**: BR復元中に`--with-sys-table`オプションを使用して、システム テーブル データを復元します。 完全なデータを新しいクラスターに移行するには、次の手順を実行します。 -1. 古いクラスターで完全バックアップを実行します。 +1. 古いクラスターで完全バックアップを実行します。 ```shell tiup br:${cluster_version} backup full --pd ${pd_host}:${pd_port} -s ${backup_location} ``` -2. 後でTiCDC Changefeed を作成するために、古いクラスターの TSO を記録します。 +2. 後でTiCDC Changefeed を作成するために、古いクラスターの TSO を記録します。 ```shell tiup br:${cluster_version} validate decode --field="end-version" \ --storage "s3://xxx?access-key=${access-key}&secret-access-key=${secret-access-key}" | tail -n1 ``` -3. 新しいクラスターをデプロイ。 +3. 新しいクラスターをデプロイ。 ```shell tiup cluster deploy ${new_cluster_name} ${cluster_version} tidb-cluster.yaml ``` -4. 完全バックアップを新しいクラスターに復元します。 +4. 完全バックアップを新しいクラスターに復元します。 ```shell tiup br:${cluster_version} restore full --pd ${pd_host}:${pd_port} -s ${backup_location} --with-sys-table @@ -127,13 +127,13 @@ tiup cluster start # Start the cluster > > TiCDCコンポーネントのバージョンは、古いクラスターのメジャー バージョンと一致する必要があります。 -- Changefeedタスクを作成し、データ損失を防ぐために、増分レプリケーションの開始点（ `${tso}` ）を[ステップ2](#step-2-prepare-the-new-cluster)で記録したバックアップTSOと正確に設定します。 +- Changefeedタスクを作成し、データ損失を防ぐために、増分レプリケーションの開始点（ `${tso}` ）を[ステップ2](#step-2-prepare-the-new-cluster)で記録したバックアップTSOと正確に設定します。 ```shell tiup ctl:${cluster_version} cdc changefeed create --server http://${cdc_host}:${cdc_port} --sink-uri="mysql://${username}:${password}@${tidb_endpoint}:${port}" --config config.toml --start-ts ${tso} ``` -- レプリケーション タスクのステータスを確認し、 `tso`または`checkpoint`継続的に進んでいることを確認します。 +- レプリケーション タスクのステータスを確認し、 `tso`または`checkpoint`継続的に進んでいることを確認します。 ```shell tiup ctl:${cluster_version} cdc changefeed list --server http://${cdc_host}:${cdc_port} @@ -155,11 +155,11 @@ tiup cluster start # Start the cluster 増分データ レプリケーション中は、レプリケーション チャネルの状態を継続的に監視し、必要に応じて設定を調整します。 -- レイテンシ メトリック: `Changefeed checkpoint lag`が 5 分以内などの許容範囲内に留まることを確認します。 -- スループットの健全性: `Sink flush rows/s`が一貫してビジネス書き込みレートを超えていることを確認します。 -- エラーとアラート: TiCDC ログとアラート情報を定期的に確認してください。 -- (オプション) テスト データ レプリケーション: テスト データを更新し、Changefeed がそれを新しいクラスターに正しく複製することを確認します。 -- (オプション) TiCDC 構成項目[`gc-ttl`](/ticdc/ticdc-server-config.md#gc-ttl)を調整します (デフォルトは 24 時間)。 +- レイテンシ メトリック: `Changefeed checkpoint lag`が 5 分以内などの許容範囲内に留まることを確認します。 +- スループットの健全性: `Sink flush rows/s`が一貫してビジネス書き込みレートを超えていることを確認します。 +- エラーとアラート: TiCDC ログとアラート情報を定期的に確認してください。 +- (オプション) テスト データ レプリケーション: テスト データを更新し、Changefeed がそれを新しいクラスターに正しく複製することを確認します。 +- (オプション) TiCDC 構成項目[`gc-ttl`](/ticdc/ticdc-server-config.md#gc-ttl)を調整します (デフォルトは 24 時間)。 レプリケーションタスクが利用できない、または中断され、時間内に解決できない場合、 `gc-ttl` TiCDC に必要なデータがガベージコレクション(GC) によって消去されることなく TiKV に保持されることを保証します。この期間を超えると、レプリケーションタスクは`failed`状態になり、回復できなくなります。この場合、PD の GC セーフポイントは引き続き前進し、プロセスを再開するには新しいバックアップが必要になります。 @@ -169,24 +169,24 @@ tiup cluster start # Start the cluster データのレプリケーションが完了したら、次の方法を使用して、古いクラスターと新しいクラスター間のデータの整合性を確認します。 -- [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)ツールを使用します: +- [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)ツールを使用します: ```shell ./sync_diff_inspector --config=./config.toml ``` -- [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)のスナップショット設定と TiCDC の[同期ポイント](/ticdc/ticdc-upstream-downstream-check.md)機能を組み合わせることで、Changefeed レプリケーションを停止することなくデータの整合性を検証できます。詳細については、 [上流および下流のクラスタのデータ検証とスナップショットの読み取り](/ticdc/ticdc-upstream-downstream-check.md)を参照してください。 +- [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)のスナップショット設定と TiCDC の[同期ポイント](/ticdc/ticdc-upstream-downstream-check.md)機能を組み合わせることで、Changefeed レプリケーションを停止することなくデータの整合性を検証できます。詳細については、 [上流および下流のクラスタのデータ検証とスナップショットの読み取り](/ticdc/ticdc-upstream-downstream-check.md)を参照してください。 -- テーブルの行数の比較など、ビジネス データの手動検証を実行します。 +- テーブルの行数の比較など、ビジネス データの手動検証を実行します。 ### 3. 環境設定を完了する {#3-finalize-the-environment-setup} この移行手順では、 BR `--with-sys-table`オプションを使用して一部のシステムテーブルデータを復元します。対象範囲に含まれないテーブルについては、手動で復元する必要があります。確認および補足すべき一般的な項目は次のとおりです。 -- ユーザー権限： `mysql.user`テーブルを比較します。 -- コンフィグレーション設定: 構成項目とシステム変数が一貫していることを確認します。 -- AUTO_INCREMENT列: 新しいクラスター内のAUTO_INCREMENT ID キャッシュをクリアします。 -- 統計: 統計を手動で収集するか、新しいクラスターで自動収集を有効にします。 +- ユーザー権限： `mysql.user`テーブルを比較します。 +- コンフィグレーション設定: 構成項目とシステム変数が一貫していることを確認します。 +- AUTO_INCREMENT列: 新しいクラスター内のAUTO_INCREMENT ID キャッシュをクリアします。 +- 統計: 統計を手動で収集するか、新しいクラスターで自動収集を有効にします。 さらに、新しいクラスターをスケールアウトして、予想されるワークロードを処理し、アラート サブスクリプション、スケジュールされた統計収集スクリプト、データ バックアップ スクリプトなどの運用タスクを移行することもできます。 @@ -194,90 +194,90 @@ tiup cluster start # Start the cluster ### 1. 切り替えの準備 {#1-prepare-for-the-switchover} -- レプリケーションステータスを確認します。 +- レプリケーションステータスを確認します。 - - TiCDC Changefeedレプリケーションのレイテンシーを監視します。 - - 増分レプリケーションのスループットがピーク時のビジネス書き込み速度以上であることを確認します。 + - TiCDC Changefeedレプリケーションのレイテンシーを監視します。 + - 増分レプリケーションのスループットがピーク時のビジネス書き込み速度以上であることを確認します。 -- 次のような多次元検証を実行します。 +- 次のような多次元検証を実行します。 - - すべてのデータ検証手順が完了していることを確認し、必要な追加チェックを実行します。 - - 新しいクラスター内のアプリケーションに対して健全性テストまたは統合テストを実行します。 + - すべてのデータ検証手順が完了していることを確認し、必要な追加チェックを実行します。 + - 新しいクラスター内のアプリケーションに対して健全性テストまたは統合テストを実行します。 ### 2. 切り替えを実行する {#2-execute-the-switchover} -1. 古いクラスタがビジネストラフィックを処理できないように、アプリケーションサービスを停止します。アクセスをさらに制限するには、次のいずれかの方法を使用します。 +1. 古いクラスタがビジネストラフィックを処理できないように、アプリケーションサービスを停止します。アクセスをさらに制限するには、次のいずれかの方法を使用します。 - - 古いクラスター内のユーザー アカウントをロックします。 + - 古いクラスター内のユーザー アカウントをロックします。 ```sql ALTER USER ACCOUNT LOCK; ``` - - 古いクラスタを読み取り専用モードに設定します。アクティブなビジネスセッションをクリアし、読み取り専用モードに入っていない接続を防止するため、古いクラスタ内のTiDBノードを再起動することをお勧めします。 + - 古いクラスタを読み取り専用モードに設定します。アクティブなビジネスセッションをクリアし、読み取り専用モードに入っていない接続を防止するため、古いクラスタ内のTiDBノードを再起動することをお勧めします。 ```sql SET GLOBAL tidb_super_read_only=ON; ``` -2. TiCDC が追いつくようにする: +2. TiCDC が追いつくようにする: - - 古いクラスターを読み取り専用モードに設定した後、現在の`up-tso`を取得します。 + - 古いクラスターを読み取り専用モードに設定した後、現在の`up-tso`を取得します。 ```sql BEGIN; SELECT TIDB_CURRENT_TSO(); ROLLBACK; ``` - - Changefeed `checkpointTs`を監視して、それが`up-tso`を超えていることを確認します。これは、TiCDC がデータ複製を完了したことを示します。 + - Changefeed `checkpointTs`を監視して、それが`up-tso`を超えていることを確認します。これは、TiCDC がデータ複製を完了したことを示します。 -3. 新しいクラスターと古いクラスター間のデータの整合性を確認します。 +3. 新しいクラスターと古いクラスター間のデータの整合性を確認します。 - - TiCDC が追いついたら、新しいクラスターから`down-tso`を取得します。 - - [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)ツールを使用して、 `up-tso`と`down-tso`の新しいクラスターと古いクラスター間のデータの一貫性を比較します。 + - TiCDC が追いついたら、新しいクラスターから`down-tso`を取得します。 + - [sync-diff-inspector](/sync-diff-inspector/sync-diff-inspector-overview.md)ツールを使用して、 `up-tso`と`down-tso`の新しいクラスターと古いクラスター間のデータの一貫性を比較します。 -4. フォワード Changefeed レプリケーション タスクを一時停止します。 +4. フォワード Changefeed レプリケーション タスクを一時停止します。 ```shell tiup ctl:${cluster_version} cdc changefeed pause --server http://${cdc_host}:${cdc_port} -c ``` -5. 新しいクラスター内の TiDB ノードを再起動して、AUTO_INCREMENT ID キャッシュをクリアします。 +5. 新しいクラスター内の TiDB ノードを再起動して、AUTO_INCREMENT ID キャッシュをクリアします。 -6. 次の方法を使用して、新しいクラスターの動作ステータスを確認します。 +6. 次の方法を使用して、新しいクラスターの動作ステータスを確認します。 - - TiDB のバージョンがターゲット バージョンと一致していることを確認します。 + - TiDB のバージョンがターゲット バージョンと一致していることを確認します。 ```shell tiup cluster display ``` - - データベースにログインし、コンポーネントのバージョンを確認します。 + - データベースにログインし、コンポーネントのバージョンを確認します。 ```sql SELECT * FROM INFORMATION_SCHEMA.CLUSTER_INFO; ``` - - Grafana を使用してサービスの状態を監視します[**概要 > サービスポートステータス**](/grafana-overview-dashboard.md)に移動し、すべてのサービスが**Up**状態であることを確認します。 + - Grafana を使用してサービスの状態を監視します[**概要 > サービスポートステータス**](/grafana-overview-dashboard.md)に移動し、すべてのサービスが**Up**状態であることを確認します。 -7. 新しいクラスターから古いクラスターへのリバースレプリケーションを設定します。 +7. 新しいクラスターから古いクラスターへのリバースレプリケーションを設定します。 - 1. 古いクラスター内のユーザー アカウントのロックを解除し、読み取り/書き込みモードを復元します。 + 1. 古いクラスター内のユーザー アカウントのロックを解除し、読み取り/書き込みモードを復元します。 ```sql ALTER USER ACCOUNT UNLOCK; SET GLOBAL tidb_super_read_only=OFF; ``` - 2. 新しいクラスターの現在の TSO を記録します。 + 2. 新しいクラスターの現在の TSO を記録します。 ```sql BEGIN; SELECT TIDB_CURRENT_TSO(); ROLLBACK; ``` - 3. リバース レプリケーション リンクを構成し、Changefeed タスクが適切に実行されていることを確認します。 + 3. リバース レプリケーション リンクを構成し、Changefeed タスクが適切に実行されていることを確認します。 - - この段階では業務が停止しているため、現在の TSO を使用できます。 - - ループバック書き込みのリスクを回避するために、古いクラスターのアドレスに`sink-uri`が設定されていることを確認します。 + - この段階では業務が停止しているため、現在の TSO を使用できます。 + - ループバック書き込みのリスクを回避するために、古いクラスターのアドレスに`sink-uri`が設定されていることを確認します。 ```shell tiup ctl:${cluster_version} cdc changefeed create --server http://${cdc_host}:${cdc_port} --sink-uri="mysql://${username}:${password}@${tidb_endpoint}:${port}" --config config.toml --start-ts ${tso} @@ -285,12 +285,12 @@ tiup cluster start # Start the cluster tiup ctl:${cluster_version} cdc changefeed list --server http://${cdc_host}:${cdc_port} ``` -8. ビジネス トラフィックを新しいクラスターにリダイレクトします。 +8. ビジネス トラフィックを新しいクラスターにリダイレクトします。 -9. 次の Grafana パネルを使用して、新しいクラスターの負荷と動作ステータスを監視します。 +9. 次の Grafana パネルを使用して、新しいクラスターの負荷と動作ステータスを監視します。 - - [**TiDBダッシュボード > クエリサマリー**](/grafana-tidb-dashboard.md#query-summary) : 期間、QPS、失敗したクエリ OPM メトリックを確認します。 - - [**TiDBダッシュボード > サーバー**](/grafana-tidb-dashboard.md#server) :**接続数**メトリックを監視して、ノード間で接続が均等に分散されていることを確認します。 + - [**TiDBダッシュボード > クエリサマリー**](/grafana-tidb-dashboard.md#query-summary) : 期間、QPS、失敗したクエリ OPM メトリックを確認します。 + - [**TiDBダッシュボード > サーバー**](/grafana-tidb-dashboard.md#server) :**接続数**メトリックを監視して、ノード間で接続が均等に分散されていることを確認します。 この時点で、ビジネス トラフィックは新しいクラスターに正常に切り替えられ、TiCDC リバース レプリケーション チャネルが確立されます。 @@ -298,31 +298,31 @@ tiup cluster start # Start the cluster ロールバック計画は次のとおりです。 -- 新しいクラスターと古いクラスター間のデータの整合性を定期的にチェックし、リバース レプリケーション リンクが適切に動作していることを確認します。 -- 1週間など、指定された期間にわたってシステムを監視します。問題が発生した場合は、古いクラスターに戻してください。 -- 観察期間が終了したら、リバース レプリケーション リンクを削除し、古いクラスターを削除します。 +- 新しいクラスターと古いクラスター間のデータの整合性を定期的にチェックし、リバース レプリケーション リンクが適切に動作していることを確認します。 +- 1週間など、指定された期間にわたってシステムを監視します。問題が発生した場合は、古いクラスターに戻してください。 +- 観察期間が終了したら、リバース レプリケーション リンクを削除し、古いクラスターを削除します。 以下では、トラフィックを古いクラスターにリダイレクトする緊急ロールバックの使用シナリオと手順について説明します。 -- 使用シナリオ: 重大な問題を解決できない場合は、ロールバック プランを実行します。 -- 手順: +- 使用シナリオ: 重大な問題を解決できない場合は、ロールバック プランを実行します。 +- 手順: - 1. 新しいクラスターへのビジネス アクセスを停止します。 - 2. ビジネス アカウントを再認証し、古いクラスターへの読み取り/書き込みアクセスを復元します。 - 3. リバース レプリケーション リンクをチェックし、TiCDC が追いついていることを確認し、新しいクラスターと古いクラスター間のデータの一貫性を検証します。 - 4. ビジネス トラフィックを古いクラスターにリダイレクトします。 + 1. 新しいクラスターへのビジネス アクセスを停止します。 + 2. ビジネス アカウントを再認証し、古いクラスターへの読み取り/書き込みアクセスを復元します。 + 3. リバース レプリケーション リンクをチェックし、TiCDC が追いついていることを確認し、新しいクラスターと古いクラスター間のデータの一貫性を検証します。 + 4. ビジネス トラフィックを古いクラスターにリダイレクトします。 ## ステップ5：クリーンアップ {#step-5-clean-up} 新しいクラスターを一定期間監視し、安定した業務運用を確認した後、TiCDC リバース レプリケーションを削除し、古いクラスターを削除できます。 -- TiCDC リバースレプリケーションを削除します。 +- TiCDC リバースレプリケーションを削除します。 ```shell tiup ctl:${cluster_version} cdc changefeed remove --server http://${cdc_host}:${cdc_port} -c ``` -- 古いクラスターを削除します。保持する場合は、 `tidb_gc_life_time`元の値に戻します。 +- 古いクラスターを削除します。保持する場合は、 `tidb_gc_life_time`元の値に戻します。 ```sql -- Restore to the original value before modification. diff --git a/tiflash-deployment-topology.md b/tiflash-deployment-topology.md index c0a757b766512..5c64064f8f8f4 100644 --- a/tiflash-deployment-topology.md +++ b/tiflash-deployment-topology.md @@ -25,18 +25,18 @@ TiFlashは列指向型ストレージエンジンであり、徐々に標準的 ### トポロジテンプレート {#topology-templates} -- [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) +- [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)を参照してください。 ### 主なパラメータ {#key-parameters} -- PD の[配置ルール](/configure-placement-rules.md)機能を有効にするには、構成テンプレートの`replication.enable-placement-rules`の値を`true`に設定します。 -- `tiflash_servers`のインスタンス レベル`"-host"`構成では、ドメイン名ではなく IP のみがサポートされます。 -- TiFlashパラメータの詳細な説明については、 [TiFlashコンフィグレーション](/tiflash/tiflash-configuration.md)を参照してください。 +- PD の[配置ルール](/configure-placement-rules.md)機能を有効にするには、構成テンプレートの`replication.enable-placement-rules`の値を`true`に設定します。 +- `tiflash_servers`のインスタンス レベル`"-host"`構成では、ドメイン名ではなく IP のみがサポートされます。 +- TiFlashパラメータの詳細な説明については、 [TiFlashコンフィグレーション](/tiflash/tiflash-configuration.md)を参照してください。 > **Note:** > -> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPクラスタコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 -> - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 +> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPクラスタコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 +> - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/tiflash-performance-tuning-methods.md b/tiflash-performance-tuning-methods.md index 56c2d7c560b15..e031b33671474 100644 --- a/tiflash-performance-tuning-methods.md +++ b/tiflash-performance-tuning-methods.md @@ -11,9 +11,9 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ 次の 3 つのメトリックを使用すると、 TiFlashクラスターのリソース使用率を簡単に取得できます。 -- CPU: TiFlashインスタンスごとの CPU 使用率。 -- メモリ: TiFlashインスタンスごとのメモリ使用量。 -- IO 使用率: TiFlashインスタンスごとの IO 使用率。 +- CPU: TiFlashインスタンスごとの CPU 使用率。 +- メモリ: TiFlashインスタンスごとのメモリ使用量。 +- IO 使用率: TiFlashインスタンスごとの IO 使用率。 例: [CH-benCHmark ワークロード](/benchmark/benchmark-tidb-using-ch.md)のリソース使用率 @@ -27,30 +27,30 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ 次のメトリックを使用して、 TiFlashのスループットを取得できます。 -- MPP クエリ数: 各TiFlashインスタンスの MPP クエリ数の瞬間値。TiFlashで処理する必要がある現在の MPP クエリ数 (処理中のクエリとスケジュール待ちのクエリを含む) を反映します。 -- 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。 - - `run_mpp_task` 、および`mpp_establish_conn` `dispatch_mpp_task` MPP 要求です。 - - `batch` : バッチリクエストの数。 - - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサ要求の数。 - - `cop_execution` : 現在実行中のコプロセッサ要求の数。 - - `remote_read` `remote_read_sent`リモート読み取り関連のメトリックです。リモート読み取りの増加は通常`remote_read_constructed`システムに問題があることを示しています。 -- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG 演算子の数。`table_scan`はテーブル スキャン演算子、 `selection`は選択演算子、 `aggregation`は集約演算子、 `top_n`は TopN 演算子、 `limit`は制限演算子、 `join`は結合演算子、 `exchange_sender`はデータ送信演算子、 `exchange_receiver`はデータ受信演算子です。 +- MPP クエリ数: 各TiFlashインスタンスの MPP クエリ数の瞬間値。TiFlashで処理する必要がある現在の MPP クエリ数 (処理中のクエリとスケジュール待ちのクエリを含む) を反映します。 +- 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。 + - `run_mpp_task` 、および`mpp_establish_conn` `dispatch_mpp_task` MPP 要求です。 + - `batch` : バッチリクエストの数。 + - `cop` : コプロセッサ インターフェイスを介して直接送信されるコプロセッサ要求の数。 + - `cop_execution` : 現在実行中のコプロセッサ要求の数。 + - `remote_read` `remote_read_sent`リモート読み取り関連のメトリックです。リモート読み取りの増加は通常`remote_read_constructed`システムに問題があることを示しています。 +- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG 演算子の数。`table_scan`はテーブル スキャン演算子、 `selection`は選択演算子、 `aggregation`は集約演算子、 `top_n`は TopN 演算子、 `limit`は制限演算子、 `join`は結合演算子、 `exchange_sender`はデータ送信演算子、 `exchange_receiver`はデータ受信演算子です。 ### レイテンシメトリクス {#latency-metrics} 次のメトリックを使用して、 TiFlashのレイテンシーを取得できます。 -- リクエスト期間の概要: すべてのTiFlashインスタンスにおけるすべてのリクエスト タイプの 1 秒あたりの合計処理期間の積み上げグラフを提供します。 +- リクエスト期間の概要: すべてのTiFlashインスタンスにおけるすべてのリクエスト タイプの 1 秒あたりの合計処理期間の積み上げグラフを提供します。 - - リクエストのタイプが`run_mpp_task` 、 `dispatch_mpp_task` 、または`mpp_establish_conn`の場合、SQL文の実行がTiFlashに部分的または完全にプッシュダウンされたことを示します。これには通常、結合操作とデータ分散操作が含まれます。これはTiFlashで最も一般的なリクエストタイプです。 - - リクエストのタイプが`cop`の場合、そのリクエストに関連するステートメントがTiFlashに完全にプッシュダウンされていないことを示します。通常、TiDB はデータアクセスとフィルタリングのために、テーブルフルスキャン演算子をTiFlashにプッシュダウンします。積み上げチャートで`cop`が最も多く表示されるリクエストタイプになった場合は、それが妥当かどうかを確認する必要があります。 + - リクエストのタイプが`run_mpp_task` 、 `dispatch_mpp_task` 、または`mpp_establish_conn`の場合、SQL文の実行がTiFlashに部分的または完全にプッシュダウンされたことを示します。これには通常、結合操作とデータ分散操作が含まれます。これはTiFlashで最も一般的なリクエストタイプです。 + - リクエストのタイプが`cop`の場合、そのリクエストに関連するステートメントがTiFlashに完全にプッシュダウンされていないことを示します。通常、TiDB はデータアクセスとフィルタリングのために、テーブルフルスキャン演算子をTiFlashにプッシュダウンします。積み上げチャートで`cop`が最も多く表示されるリクエストタイプになった場合は、それが妥当かどうかを確認する必要があります。 - - SQL ステートメントによってクエリされるデータの量が大きい場合、オプティマイザーはコスト モデルに従って、 TiFlash のフル テーブル スキャンの方がコスト効率が高いと見積もる場合があります。 - - クエリ対象のテーブルのスキーマに適切なインデックスがない場合、クエリ対象のデータ量が少ない場合でも、オプティマイザーはクエリをTiFlashにプッシュダウンしてテーブル全体をスキャンするしかありません。このような場合、適切なインデックスを作成し、TiKVを介してデータにアクセスする方が効率的です。 + - SQL ステートメントによってクエリされるデータの量が大きい場合、オプティマイザーはコスト モデルに従って、 TiFlash のフル テーブル スキャンの方がコスト効率が高いと見積もる場合があります。 + - クエリ対象のテーブルのスキーマに適切なインデックスがない場合、クエリ対象のデータ量が少ない場合でも、オプティマイザーはクエリをTiFlashにプッシュダウンしてテーブル全体をスキャンするしかありません。このような場合、適切なインデックスを作成し、TiKVを介してデータにアクセスする方が効率的です。 -- 要求期間: すべてのTiFlashインスタンス内の各 MPP およびコプロセッサ要求タイプの合計処理期間。これには平均レイテンシーと p99レイテンシーが含まれます。 +- 要求期間: すべてのTiFlashインスタンス内の各 MPP およびコプロセッサ要求タイプの合計処理期間。これには平均レイテンシーと p99レイテンシーが含まれます。 -- リクエスト処理時間: `cop`と`batch cop`リクエストの実行開始から完了までの時間（待機時間を除く）。この指標は、平均レイテンシとP99レイテンシーを含む、 `cop`と`batch cop`リクエストにのみ適用されます。 +- リクエスト処理時間: `cop`と`batch cop`リクエストの実行開始から完了までの時間（待機時間を除く）。この指標は、平均レイテンシとP99レイテンシーを含む、 `cop`と`batch cop`リクエストにのみ適用されます。 例1: TiFlash MPPリクエストの処理時間の概要 @@ -70,33 +70,33 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ 次のメトリックを使用して、 TiFlashのRaftレプリケーション ステータスを取得できます。 -- Raft待機インデックス期間: すべてのTiFlashインスタンスのローカルリージョンインデックスが`read_index`になるまでの待機時間。これは、 `wait_index`操作のレイテンシーを表します。この指標が高すぎる場合、TiKV からTiFlashへのデータレプリケーションに大きなレイテンシーがあることを示しています。考えられる原因は次のとおりです。 +- Raft待機インデックス期間: すべてのTiFlashインスタンスのローカルリージョンインデックスが`read_index`になるまでの待機時間。これは、 `wait_index`操作のレイテンシーを表します。この指標が高すぎる場合、TiKV からTiFlashへのデータレプリケーションに大きなレイテンシーがあることを示しています。考えられる原因は次のとおりです。 - - TiKV リソースが過負荷になっています。 - - TiFlashリソース、特に IO リソースが過負荷になっています。 - - TiKV とTiFlashの間にネットワークのボトルネックがあります。 + - TiKV リソースが過負荷になっています。 + - TiFlashリソース、特に IO リソースが過負荷になっています。 + - TiKV とTiFlashの間にネットワークのボトルネックがあります。 -- Raftバッチ読み取りインデックス期間：すべてのTiFlashインスタンスのレイテンシーは`read_index` 。この指標が高すぎる場合、 TiFlashと TiKV 間のやり取りが遅いことを示しています。考えられる原因は以下のとおりです。 +- Raftバッチ読み取りインデックス期間：すべてのTiFlashインスタンスのレイテンシーは`read_index` 。この指標が高すぎる場合、 TiFlashと TiKV 間のやり取りが遅いことを示しています。考えられる原因は以下のとおりです。 - - TiFlashリソースが過負荷になっています。 - - TiKV リソースが過負荷になっています。 - - TiFlashと TiKV の間にネットワークのボトルネックがあります。 + - TiFlashリソースが過負荷になっています。 + - TiKV リソースが過負荷になっています。 + - TiFlashと TiKV の間にネットワークのボトルネックがあります。 ### IOスループットメトリック {#io-throughput-metrics} 次のメトリックを使用して、 TiFlashの IO スループットを取得できます。 -- インスタンスごとの書き込みスループット：各TiFlashインスタンスによって書き込まれるデータのスループット。RaftデータRaftとRaftスナップショットを適用した場合のスループットも含まれます。 +- インスタンスごとの書き込みスループット：各TiFlashインスタンスによって書き込まれるデータのスループット。RaftデータRaftとRaftスナップショットを適用した場合のスループットも含まれます。 -- 書き込みフロー: すべてのTiFlashインスタンスによるディスク書き込みのトラフィック。 +- 書き込みフロー: すべてのTiFlashインスタンスによるディスク書き込みのトラフィック。 - - ファイル記述子: TiFlashで使用される DeltaTreeストレージエンジンの安定したレイヤー。 - - Page: TiFlashで使用される DeltaTreeストレージエンジンの Delta 変更レイヤーである Pagestore を指します。 + - ファイル記述子: TiFlashで使用される DeltaTreeストレージエンジンの安定したレイヤー。 + - Page: TiFlashで使用される DeltaTreeストレージエンジンの Delta 変更レイヤーである Pagestore を指します。 -- 読み取りフロー: すべてのTiFlashインスタンスのディスク読み取り操作のトラフィック。 +- 読み取りフロー: すべてのTiFlashインスタンスのディスク読み取り操作のトラフィック。 - - ファイル記述子: TiFlashで使用される DeltaTreeストレージエンジンの安定したレイヤー。 - - Page: TiFlashで使用される DeltaTreeストレージエンジンの Delta 変更レイヤーである Pagestore を指します。 + - ファイル記述子: TiFlashで使用される DeltaTreeストレージエンジンの安定したレイヤー。 + - Page: TiFlashで使用される DeltaTreeストレージエンジンの Delta 変更レイヤーである Pagestore を指します。 `(Read flow + Write flow) ÷ total Write Throughput By Instance`式を使用して、 TiFlashクラスター全体の書き込み増幅係数を計算できます。 diff --git a/tiflash-upgrade-guide.md b/tiflash-upgrade-guide.md index 9475153bc0de5..967bbc9457ee6 100644 --- a/tiflash-upgrade-guide.md +++ b/tiflash-upgrade-guide.md @@ -9,35 +9,35 @@ summary: TiFlash をアップグレードする際の注意事項を説明しま 標準的なアップグレード プロセスについては、次のドキュメントを参照してください。 -- [TiUPを使用して TiDB をアップグレードする](/upgrade-tidb-using-tiup.md) -- [Kubernetes 上の TiDB をアップグレードする](https://docs.pingcap.com/tidb-in-kubernetes/stable/upgrade-a-tidb-cluster) +- [TiUPを使用して TiDB をアップグレードする](/upgrade-tidb-using-tiup.md) +- [Kubernetes 上の TiDB をアップグレードする](https://docs.pingcap.com/tidb-in-kubernetes/stable/upgrade-a-tidb-cluster) > **Note:** > -> - [ファストスキャン](/tiflash/use-fastscan.md)はv6.2.0で実験的機能として導入され、v7.0.0で一般提供（GA）されます。強力なデータ整合性を犠牲にして、より効率的なクエリパフォーマンスを実現します。 +> - [ファストスキャン](/tiflash/use-fastscan.md)はv6.2.0で実験的機能として導入され、v7.0.0で一般提供（GA）されます。強力なデータ整合性を犠牲にして、より効率的なクエリパフォーマンスを実現します。 > -> - TiFlashを含む TiDB をメジャーバージョン間でアップグレードすることは推奨されません（例：v4.x から v6.x）。代わりに、まず v4.x から v5.x にアップグレードし、その後 v6.x にアップグレードする必要があります。 +> - TiFlashを含む TiDB をメジャーバージョン間でアップグレードすることは推奨されません（例：v4.x から v6.x）。代わりに、まず v4.x から v5.x にアップグレードし、その後 v6.x にアップグレードする必要があります。 > -> - v4.x のライフサイクルは終了に近づいています。できるだけ早く v5.x 以降にアップグレードすることをお勧めします。詳細については、 [TiDB リリース サポート ポリシー](https://www.pingcap.com/tidb-release-support-policy/)ご覧ください。 +> - v4.x のライフサイクルは終了に近づいています。できるだけ早く v5.x 以降にアップグレードすることをお勧めします。詳細については、 [TiDB リリース サポート ポリシー](https://www.pingcap.com/tidb-release-support-policy/)ご覧ください。 > -> - PingCAPは、v6.0などのLTS以外のバージョンに対するバグ修正を提供していません。可能な限り、v6.1以降のLTSバージョンにアップグレードすることをお勧めします。 +> - PingCAPは、v6.0などのLTS以外のバージョンに対するバグ修正を提供していません。可能な限り、v6.1以降のLTSバージョンにアップグレードすることをお勧めします。 ## TiUPを使用してTiFlashをアップグレードする {#upgrade-tiflash-using-tiup} TiFlashをv5.3.0より前のバージョンからv5.3.0以降にアップグレードするには、 TiFlashを停止してからアップグレードする必要があります。TiUPを使用してTiFlashをアップグレードする際は、以下の点にご注意ください。 -- TiUPクラスタのバージョンがv1.12.0以降の場合、 TiFlashを停止してからアップグレードすることはできません。アップグレード先のバージョンでTiUPクラスタのバージョンがv1.12.0以降が必要な場合は、まず`tiup cluster:v1.11.3 `を使用してTiFlashを中間バージョンにアップグレードし、TiDBクラスタのオンラインアップグレードを実行した後、 TiUPバージョンをアップグレードし、その後TiDBクラスタを停止せずに直接アップグレード先のバージョンにアップグレードすることをお勧めします。 -- TiUPクラスターのバージョンが v1.12.0 より前の場合は、次の手順を実行してTiFlash をアップグレードします。 +- TiUPクラスタのバージョンがv1.12.0以降の場合、 TiFlashを停止してからアップグレードすることはできません。アップグレード先のバージョンでTiUPクラスタのバージョンがv1.12.0以降が必要な場合は、まず`tiup cluster:v1.11.3 `を使用してTiFlashを中間バージョンにアップグレードし、TiDBクラスタのオンラインアップグレードを実行した後、 TiUPバージョンをアップグレードし、その後TiDBクラスタを停止せずに直接アップグレード先のバージョンにアップグレードすることをお勧めします。 +- TiUPクラスターのバージョンが v1.12.0 より前の場合は、次の手順を実行してTiFlash をアップグレードします。 次の手順に従うと、 TiUPを使用して他のコンポーネントを中断せずにTiFlash をアップグレードできます。 -1. TiFlashインスタンスを停止します。 +1. TiFlashインスタンスを停止します。 ```shell tiup cluster stop -R tiflash ``` -2. TiDB クラスターを再起動せずにアップグレードします (ファイルの更新のみ)。 +2. TiDB クラスターを再起動せずにアップグレードします (ファイルの更新のみ)。 ```shell tiup cluster upgrade --offline @@ -49,7 +49,7 @@ TiFlashをv5.3.0より前のバージョンからv5.3.0以降にアップグレ tiup cluster upgrade v5.3.0 --offline ``` -3. TiDB クラスターをリロードします。リロード後、 TiFlashインスタンスが起動するので、手動で起動する必要はありません。 +3. TiDB クラスターをリロードします。リロード後、 TiFlashインスタンスが起動するので、手動で起動する必要はありません。 ```shell tiup cluster reload @@ -73,9 +73,9 @@ TiFlash Proxyはv6.1.0（TiKV v6.0.0と連動）にアップグレードされ [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)を有効にせず、今後も使用しない場合は、このセクションをスキップできます。 -- 新しくインストールされた TiDB v6.1.0: 動的プルーニングがデフォルトで有効になっています。 +- 新しくインストールされた TiDB v6.1.0: 動的プルーニングがデフォルトで有効になっています。 -- TiDB v6.0以前：動的プルーニングはデフォルトで無効になっています。アップグレード後の動的プルーニングの設定は、以前のバージョンの設定を継承します。つまり、アップグレード後も動的プルーニングは自動的に有効化（または無効化）されません。 +- TiDB v6.0以前：動的プルーニングはデフォルトで無効になっています。アップグレード後の動的プルーニングの設定は、以前のバージョンの設定を継承します。つまり、アップグレード後も動的プルーニングは自動的に有効化（または無効化）されません。 アップグレード後、動的プルーニングを有効にするには、 `tidb_partition_prune_mode`を`dynamic`に設定し、パーティションテーブルのグローバル統計を手動で更新してください。詳細については、 [動的プルーニングモード](/partitioned-table.md#dynamic-pruning-mode)を参照してください。 @@ -87,35 +87,35 @@ TiDB v6.2では、 TiFlashのデータストレージフォーマットがV3に TiFlash v6.2.0はデフォルトでPageStorage V3バージョン[`format_version = 4`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file)を使用します。この新しいデータフォーマットは、ピーク時の書き込みI/Oトラフィックを大幅に削減します。更新トラフィックが多く、同時実行性やクエリ負荷が高いシナリオでは、 TiFlashデータGCによる過剰なCPU使用率を効果的に軽減します。また、以前のストレージフォーマットと比較して、V3バージョンはスペース増幅とリソース消費を大幅に削減します。 -- v6.2.0 にアップグレードすると、新しいデータが既存のTiFlashノードに書き込まれると同時に、以前のデータは徐々に新しい形式に変換されます。 -- ただし、アップグレード中に以前のデータを新しい形式に完全に変換することはできません。これは、変換によってある程度のシステムオーバーヘッドが発生するためです（サービスには影響はありませんが、注意が必要です）。アップグレード後、 [`Compact`コマンド](/sql-statements/sql-statement-alter-table-compact.md)を実行してデータを新しい形式に変換することをお勧めします。手順は次のとおりです。 +- v6.2.0 にアップグレードすると、新しいデータが既存のTiFlashノードに書き込まれると同時に、以前のデータは徐々に新しい形式に変換されます。 +- ただし、アップグレード中に以前のデータを新しい形式に完全に変換することはできません。これは、変換によってある程度のシステムオーバーヘッドが発生するためです（サービスには影響はありませんが、注意が必要です）。アップグレード後、 [`Compact`コマンド](/sql-statements/sql-statement-alter-table-compact.md)を実行してデータを新しい形式に変換することをお勧めします。手順は次のとおりです。 - 1. TiFlashレプリカを含む各テーブルに対して次のコマンドを実行します。 + 1. TiFlashレプリカを含む各テーブルに対して次のコマンドを実行します。 ```sql ALTER TABLE COMPACT tiflash replica; ``` - 2. TiFlashノードを再起動します。 + 2. TiFlashノードを再起動します。 テーブルがまだ古いデータ形式を使用しているかどうかを Grafana で確認できます: **TiFlash-Summary** > **Storage Pool** > **Storage Pool Run Mode** 。 -- V2のみ: PageStorage V2を使用しているテーブルの数（パーティションを含む） -- V3のみ: PageStorage V3を使用しているテーブルの数（パーティションを含む） -- 混合モード: PageStorage V2 から PageStorage V3 に変換されたデータ形式を持つテーブルの数 (パーティションを含む) +- V2のみ: PageStorage V2を使用しているテーブルの数（パーティションを含む） +- V3のみ: PageStorage V3を使用しているテーブルの数（パーティションを含む） +- 混合モード: PageStorage V2 から PageStorage V3 に変換されたデータ形式を持つテーブルの数 (パーティションを含む) > **Note:** > > 以下のパッチバージョンには既知の問題（問題[＃9039](https://github.com/pingcap/tiflash/issues/9039) ）があります。これらのバージョンにアップグレードすると、 TiFlashデータが破損する可能性があります。 > -> - v6.5.0 から v6.5.9 -> - バージョン6.6.0 -> - バージョン7.0.0 -> - v7.1.0 から v7.1.5 -> - バージョン7.2.0 -> - バージョン7.3.0 -> - バージョン7.4.0 -> - v7.5.0 から v7.5.1 +> - v6.5.0 から v6.5.9 +> - バージョン6.6.0 +> - バージョン7.0.0 +> - v7.1.0 から v7.1.5 +> - バージョン7.2.0 +> - バージョン7.3.0 +> - バージョン7.4.0 +> - v7.5.0 から v7.5.1 > > この問題が修正された v6.5.10、v7.1.6、v7.5.2 以降のバージョンにアップグレードすることをお勧めします。 diff --git a/tiflash/create-tiflash-replicas.md b/tiflash/create-tiflash-replicas.md index 139210ae1fb4a..a90a7b104b220 100644 --- a/tiflash/create-tiflash-replicas.md +++ b/tiflash/create-tiflash-replicas.md @@ -17,7 +17,7 @@ ALTER TABLE table_name SET TIFLASH REPLICA count; 上記コマンドのパラメータは以下のとおりです。 -- `count`はレプリカの数を示します。値が`0`の場合、レプリカは削除されます。 +- `count`はレプリカの数を示します。値が`0`の場合、レプリカは削除されます。 > **Note:** > @@ -39,24 +39,24 @@ ALTER TABLE `tpch50`.`lineitem` SET TIFLASH REPLICA 0; **注:** -- 上記の DDL ステートメントを使用してテーブル`t`がTiFlashに複製されると、次のステートメントを使用して作成されたテーブルも自動的にTiFlashに複製されます。 +- 上記の DDL ステートメントを使用してテーブル`t`がTiFlashに複製されると、次のステートメントを使用して作成されたテーブルも自動的にTiFlashに複製されます。 ```sql CREATE TABLE table_name like t; ``` -- v4.0.6より前のバージョンでは、 TiDB Lightningを使用してデータをインポートする前にTiFlashレプリカを作成すると、データのインポートに失敗します。テーブルのTiFlashレプリカを作成する前に、テーブルにデータをインポートする必要があります。 +- v4.0.6より前のバージョンでは、 TiDB Lightningを使用してデータをインポートする前にTiFlashレプリカを作成すると、データのインポートに失敗します。テーブルのTiFlashレプリカを作成する前に、テーブルにデータをインポートする必要があります。 -- TiDB とTiDB Lightning の両方が v4.0.6 以降の場合、テーブルにTiFlashレプリカがあるかどうかに関係なく、 TiDB Lightningを使用してそのテーブルにデータをインポートできます。ただし、 TiDB Lightning のプロセスは、TiDB Lightning ホストの NIC 帯域幅、 TiFlashノードの CPU とディスク負荷、およびTiFlashレプリカの数に応じて遅くなる可能性があります。 +- TiDB とTiDB Lightning の両方が v4.0.6 以降の場合、テーブルにTiFlashレプリカがあるかどうかに関係なく、 TiDB Lightningを使用してそのテーブルにデータをインポートできます。ただし、 TiDB Lightning のプロセスは、TiDB Lightning ホストの NIC 帯域幅、 TiFlashノードの CPU とディスク負荷、およびTiFlashレプリカの数に応じて遅くなる可能性があります。 -- PDスケジューリングのパフォーマンスが低下するため、1,000を超えるテーブルを複製することは推奨されません。この制限は、今後のバージョンで削除される予定です。 +- PDスケジューリングのパフォーマンスが低下するため、1,000を超えるテーブルを複製することは推奨されません。この制限は、今後のバージョンで削除される予定です。 -- v5.1以降のバージョンでは、システムテーブルのレプリカ設定はサポートされなくなりました。クラスターをアップグレードする前に、関連するシステムテーブルのレプリカをクリアする必要があります。そうしないと、クラスターを新しいバージョンにアップグレードした後に、システムテーブルのレプリカ設定を変更できなくなります。 +- v5.1以降のバージョンでは、システムテーブルのレプリカ設定はサポートされなくなりました。クラスターをアップグレードする前に、関連するシステムテーブルのレプリカをクリアする必要があります。そうしないと、クラスターを新しいバージョンにアップグレードした後に、システムテーブルのレプリカ設定を変更できなくなります。 -- 現在、TiCDC を使用してテーブルをダウンストリーム TiDB クラスターにレプリケートする場合、テーブルのTiFlashレプリカの作成はサポートされていません。つまり、TiCDC は次のようなTiFlash関連の DDL ステートメントのレプリケートをサポートしていません。 +- 現在、TiCDC を使用してテーブルをダウンストリーム TiDB クラスターにレプリケートする場合、テーブルのTiFlashレプリカの作成はサポートされていません。つまり、TiCDC は次のようなTiFlash関連の DDL ステートメントのレプリケートをサポートしていません。 - - `ALTER TABLE table_name SET TIFLASH REPLICA count;` - - `ALTER DATABASE db_name SET TIFLASH REPLICA count;` + - `ALTER TABLE table_name SET TIFLASH REPLICA count;` + - `ALTER DATABASE db_name SET TIFLASH REPLICA count;` ### レプリケーションの進行状況を確認する {#check-replication-progress} @@ -68,8 +68,8 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = ' 上記のステートメントの結果は次のようになります。 -- `AVAILABLE`は、このテーブルのTiFlashレプリカが使用可能かどうかを示します。`1`は使用可能、 `0`は使用不可を意味します。レプリカが使用可能になると、このステータスは変更されません。DDL ステートメントを使用してレプリカの数を変更すると、レプリケーション ステータスは再計算されます。 -- `PROGRESS`はレプリケーションの進行状況を表します。値は`0.0`から`1.0`までです。`1`は少なくとも 1 つのレプリカがレプリケートされていることを意味します。 +- `AVAILABLE`は、このテーブルのTiFlashレプリカが使用可能かどうかを示します。`1`は使用可能、 `0`は使用不可を意味します。レプリカが使用可能になると、このステータスは変更されません。DDL ステートメントを使用してレプリカの数を変更すると、レプリケーション ステータスは再計算されます。 +- `PROGRESS`はレプリケーションの進行状況を表します。値は`0.0`から`1.0`までです。`1`は少なくとも 1 つのレプリカがレプリケートされていることを意味します。 ## データベースのTiFlashレプリカを作成する {#create-tiflash-replicas-for-databases} @@ -83,13 +83,13 @@ ALTER DATABASE db_name SET TIFLASH REPLICA count; 例: -- データベース`tpch50`内のすべてのテーブルに対して 2 つのレプリカを作成します。 +- データベース`tpch50`内のすべてのテーブルに対して 2 つのレプリカを作成します。 ```sql ALTER DATABASE `tpch50` SET TIFLASH REPLICA 2; ``` -- データベース`tpch50`用に作成されたTiFlashレプリカを削除します。 +- データベース`tpch50`用に作成されたTiFlashレプリカを削除します。 ```sql ALTER DATABASE `tpch50` SET TIFLASH REPLICA 0; @@ -97,18 +97,18 @@ ALTER DATABASE db_name SET TIFLASH REPLICA count; > **Note:** > -> - この文は実際には一連のDDL操作を実行しますが、これらの操作はリソースを大量に消費します。文の実行中に中断された場合、実行済みの操作はロールバックされず、未実行の操作は続行されません。 +> - この文は実際には一連のDDL操作を実行しますが、これらの操作はリソースを大量に消費します。文の実行中に中断された場合、実行済みの操作はロールバックされず、未実行の操作は続行されません。 > -> - ステートメント実行後、**このデータベース内のすべてのテーブルがレプリケートされる**まで、 TiFlashレプリカの数を設定したり、このデータベースに対してDDL操作を実行したりしないでください。そうしないと、次のような予期しない結果が発生する可能性があります。 -> - TiFlashレプリカの数を 2 に設定し、データベース内のすべてのテーブルがレプリケートされる前にその数を 1 に変更した場合、すべてのテーブルのTiFlashレプリカの最終的な数は必ずしも 1 または 2 になるとは限りません。 -> - ステートメントを実行した後、ステートメントの実行が完了する前にこのデータベースにテーブルを作成すると、これらの新しいテーブルに対してTiFlashレプリカが作成される**場合と作成されない場合があります**。 -> - ステートメントを実行した後、ステートメントの実行が完了する前にデータベース内のテーブルのインデックスを追加すると、ステートメントがハングし、インデックスが追加された後にのみ再開される可能性があります。 +> - ステートメント実行後、**このデータベース内のすべてのテーブルがレプリケートされる**まで、 TiFlashレプリカの数を設定したり、このデータベースに対してDDL操作を実行したりしないでください。そうしないと、次のような予期しない結果が発生する可能性があります。 +> - TiFlashレプリカの数を 2 に設定し、データベース内のすべてのテーブルがレプリケートされる前にその数を 1 に変更した場合、すべてのテーブルのTiFlashレプリカの最終的な数は必ずしも 1 または 2 になるとは限りません。 +> - ステートメントを実行した後、ステートメントの実行が完了する前にこのデータベースにテーブルを作成すると、これらの新しいテーブルに対してTiFlashレプリカが作成される**場合と作成されない場合があります**。 +> - ステートメントを実行した後、ステートメントの実行が完了する前にデータベース内のテーブルのインデックスを追加すると、ステートメントがハングし、インデックスが追加された後にのみ再開される可能性があります。 > -> - ステートメントの実行が完了した**後に**このデータベースにテーブルを作成した場合、これらの新しいテーブルに対してTiFlashレプリカは自動的に作成されません。 +> - ステートメントの実行が完了した**後に**このデータベースにテーブルを作成した場合、これらの新しいテーブルに対してTiFlashレプリカは自動的に作成されません。 > -> - このステートメントは、システム テーブル、ビュー、一時テーブル、およびTiFlashでサポートされていない文字セットを持つテーブルをスキップします。 +> - このステートメントは、システム テーブル、ビュー、一時テーブル、およびTiFlashでサポートされていない文字セットを持つテーブルをスキップします。 -> - システム変数[`tidb_batch_pending_tiflash_count`](/system-variables.md#tidb_batch_pending_tiflash_count-new-in-v60)を設定することで、実行中に利用不可のままにできるテーブルの数を制御できます。この値を下げると、レプリケーション中のクラスターへの負荷を軽減できます。ただし、この制限はリアルタイムではないため、設定適用後も利用不可のテーブルの数が制限を超える可能性があります。 +> - システム変数[`tidb_batch_pending_tiflash_count`](/system-variables.md#tidb_batch_pending_tiflash_count-new-in-v60)を設定することで、実行中に利用不可のままにできるテーブルの数を制御できます。この値を下げると、レプリケーション中のクラスターへの負荷を軽減できます。ただし、この制限はリアルタイムではないため、設定適用後も利用不可のテーブルの数が制限を超える可能性があります。 ### レプリケーションの進行状況を確認する {#check-replication-progress} @@ -136,12 +136,12 @@ SELECT TABLE_NAME FROM information_schema.tables where TABLE_SCHEMA = " TiDB クラスターは、次のいずれかの操作を実行すると、 TiFlashレプリカのレプリケーション プロセスをトリガーします。 -- テーブルにTiFlashレプリカを追加します。 -- 新しいTiFlashインスタンスを追加すると、PD は元のインスタンスのTiFlashレプリカを新しいTiFlashインスタンスにスケジュールします。 +- テーブルにTiFlashレプリカを追加します。 +- 新しいTiFlashインスタンスを追加すると、PD は元のインスタンスのTiFlashレプリカを新しいTiFlashインスタンスにスケジュールします。 このプロセス中、各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倍になります。 @@ -180,7 +180,7 @@ TiDB クラスターは、次のいずれかの操作を実行すると、 TiFla tiup ctl:v pd -u http://:2379 store limit all engine tiflash 90 remove-peer ``` -3. TiFlashレプリケーションが完了したら、オンライン サービスへの影響を軽減するために、デフォルト構成に戻します。 +3. TiFlashレプリケーションが完了したら、オンライン サービスへの影響を軽減するために、デフォルト構成に戻します。 デフォルトのレプリカ スケジューリング速度制限を復元するには、次のPD Controlコマンドを実行します。 @@ -208,7 +208,7 @@ TiDB クラスターは、次のいずれかの操作を実行すると、 TiFla レプリカを構成する際に、災害復旧のためにTiFlashレプリカを複数のデータセンターに分散する必要がある場合は、次の手順に従って使用可能なゾーンを構成できます。 -1. クラスター構成ファイルでTiFlashノードのラベルを指定します。 +1. クラスター構成ファイルでTiFlashノードのラベルを指定します。 ``` tiflash_servers: @@ -233,7 +233,7 @@ TiDB クラスターは、次のいずれかの操作を実行すると、 TiFla 以前のバージョンでは、 `flash.proxy.labels`設定では、利用可能なゾーン名に含まれる特殊文字を正しく処理できないことに注意してください。利用可能なゾーン名を設定するには、 `learner_config`の`server.labels`を使用することをお勧めします。 -2. クラスターを起動した後、高可用性を実現するためにTiFlashレプリカの数を指定します。構文は次のとおりです。 +2. クラスターを起動した後、高可用性を実現するためにTiFlashレプリカの数を指定します。構文は次のとおりです。 ```sql ALTER TABLE table_name SET TIFLASH REPLICA count; @@ -245,7 +245,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 diff --git a/tiflash/maintain-tiflash.md b/tiflash/maintain-tiflash.md index 6c9f14dc152f5..35f70d77ce997 100644 --- a/tiflash/maintain-tiflash.md +++ b/tiflash/maintain-tiflash.md @@ -11,7 +11,7 @@ summary: TiFlashクラスターを保守する際の一般的な操作を学習 TiFlash のバージョンを確認するには、次の 2 つの方法があります。 -- TiFlashのバイナリファイル名が`tiflash`の場合、 `./tiflash version`コマンドを実行することでバージョンを確認できます。 +- TiFlashのバイナリファイル名が`tiflash`の場合、 `./tiflash version`コマンドを実行することでバージョンを確認できます。 ただし、上記のコマンドを実行するには、 `libtiflash_proxy.so`動的ライブラリを含むディレクトリパスを`LD_LIBRARY_PATH`環境変数に追加する必要があります。これは、 TiFlashの実行が`libtiflash_proxy.so`動的ライブラリに依存しているためです。 @@ -21,7 +21,7 @@ TiFlash のバージョンを確認するには、次の 2 つの方法があり LD_LIBRARY_PATH=./ ./tiflash version ``` -- TiFlash のログを参照して、 TiFlash のバージョンを確認してください。ログのパスについては、 [`tiflash.toml`ファイル](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file)の`[logger]`部分を参照してください。例えば、以下のようになります。 +- TiFlash のログを参照して、 TiFlash のバージョンを確認してください。ログのパスについては、 [`tiflash.toml`ファイル](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file)の`[logger]`部分を参照してください。例えば、以下のようになります。 ``` : TiFlash version: TiFlash 0.2.0 master-375035282451103999f3863c691e2fc2 diff --git a/tiflash/monitor-tiflash.md b/tiflash/monitor-tiflash.md index 814faa99789b3..9b3a60cb62754 100644 --- a/tiflash/monitor-tiflash.md +++ b/tiflash/monitor-tiflash.md @@ -21,15 +21,15 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## サーバ {#server} -- ストア サイズ: 各TiFlashインスタンスで使用されるストレージサイズ。 -- 使用可能なサイズ: 各TiFlashインスタンスで使用可能なストレージサイズ。 -- 容量サイズ: 各TiFlashインスタンスのストレージ容量。 -- 稼働時間: 前回の再起動以降のTiFlashの実行時間。 -- メモリ: TiFlashインスタンスごとのメモリ使用量。 -- CPU 使用率: TiFlashインスタンスごとの CPU 使用率。 -- FSync OPS: TiFlashインスタンスあたりの 1 秒あたりの fsync 操作の数。 -- ファイルオープン OPS: TiFlashインスタンスあたりの`open`秒あたりの操作数。 -- 開かれたファイル数: 現在各TiFlashインスタンスによって開かれているファイル記述子の数。 +- ストア サイズ: 各TiFlashインスタンスで使用されるストレージサイズ。 +- 使用可能なサイズ: 各TiFlashインスタンスで使用可能なストレージサイズ。 +- 容量サイズ: 各TiFlashインスタンスのストレージ容量。 +- 稼働時間: 前回の再起動以降のTiFlashの実行時間。 +- メモリ: TiFlashインスタンスごとのメモリ使用量。 +- CPU 使用率: TiFlashインスタンスごとの CPU 使用率。 +- FSync OPS: TiFlashインスタンスあたりの 1 秒あたりの fsync 操作の数。 +- ファイルオープン OPS: TiFlashインスタンスあたりの`open`秒あたりの操作数。 +- 開かれたファイル数: 現在各TiFlashインスタンスによって開かれているファイル記述子の数。 > **Note:** > @@ -37,49 +37,49 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## コプロセッサー {#coprocessor} -- 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。`batch`はバッチ要求の数です。`batch_cop`はバッチ要求内のコプロセッサ要求の数です。`cop`はコプロセッサ インターフェイスを介して直接送信されたコプロセッサ要求の数です。`cop_dag`はすべてのコプロセッサ要求内の DAG 要求の数です。`super_batch`はスーパー バッチ機能を有効にするための要求の数です。 -- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。`table_scan`はテーブル スキャン Executor です。`selection`は選択 Executor です。`aggregation`は集約 Executor です。`top_n`は`TopN` Executor です。`limit`は制限 Executor です。 -- リクエスト期間: コプロセッサリクエストを処理するすべてのTiFlashインスタンスの合計期間。合計期間は、コプロセッサリクエストを受信してからリクエストへの応答が完了するまでの期間です。 -- エラー QPS: コプロセッサ要求を処理するすべてのTiFlashインスタンスのエラー数。`meet_lock`は読み取りデータがロックされていることを意味します。`region_not_found`はリージョンが存在しないことを意味します。`epoch_not_match`は読み取りリージョンエポックがローカル エポックと一致していないことを意味します。`kv_client_error`はTiKV との通信でエラーが返されたことを意味します。`internal_error`はTiFlashの内部システム エラーです。`other`はその他のタイプのエラーです。 -- リクエスト処理期間：すべてのTiFlashインスタンスがコプロセッサリクエストを処理する期間。処理時間は、コプロセッサリクエストの実行開始から完了までです。 -- 応答バイト/秒: すべてのTiFlashインスタンスからの応答の合計バイト数。 -- Cop タスクのメモリ使用量: コプロセッサ要求を処理するすべてのTiFlashインスタンスの合計メモリ使用量。 -- 処理要求数: コプロセッサ要求を処理しているすべてのTiFlashインスタンスの総数。要求の分類は、要求QPSと同じです。 -- RPC スレッド: 各TiFlashインスタンスで使用される RPC スレッドのリアルタイム数。 -- RPC の最大スレッド数: 各TiFlashインスタンスで最近使用された RPC スレッドの最大数。 -- スレッド: 各TiFlashインスタンスで使用されるスレッドのリアルタイム数。 -- 最大スレッド数: 各TiFlashインスタンスで最近使用されたスレッドの最大数。 +- 要求 QPS: すべてのTiFlashインスタンスによって受信されたコプロセッサ要求の数。`batch`はバッチ要求の数です。`batch_cop`はバッチ要求内のコプロセッサ要求の数です。`cop`はコプロセッサ インターフェイスを介して直接送信されたコプロセッサ要求の数です。`cop_dag`はすべてのコプロセッサ要求内の DAG 要求の数です。`super_batch`はスーパー バッチ機能を有効にするための要求の数です。 +- Executor QPS: すべてのTiFlashインスタンスが受信したリクエスト内の各タイプの DAG Executor の数。`table_scan`はテーブル スキャン Executor です。`selection`は選択 Executor です。`aggregation`は集約 Executor です。`top_n`は`TopN` Executor です。`limit`は制限 Executor です。 +- リクエスト期間: コプロセッサリクエストを処理するすべてのTiFlashインスタンスの合計期間。合計期間は、コプロセッサリクエストを受信してからリクエストへの応答が完了するまでの期間です。 +- エラー QPS: コプロセッサ要求を処理するすべてのTiFlashインスタンスのエラー数。`meet_lock`は読み取りデータがロックされていることを意味します。`region_not_found`はリージョンが存在しないことを意味します。`epoch_not_match`は読み取りリージョンエポックがローカル エポックと一致していないことを意味します。`kv_client_error`はTiKV との通信でエラーが返されたことを意味します。`internal_error`はTiFlashの内部システム エラーです。`other`はその他のタイプのエラーです。 +- リクエスト処理期間：すべてのTiFlashインスタンスがコプロセッサリクエストを処理する期間。処理時間は、コプロセッサリクエストの実行開始から完了までです。 +- 応答バイト/秒: すべてのTiFlashインスタンスからの応答の合計バイト数。 +- Cop タスクのメモリ使用量: コプロセッサ要求を処理するすべてのTiFlashインスタンスの合計メモリ使用量。 +- 処理要求数: コプロセッサ要求を処理しているすべてのTiFlashインスタンスの総数。要求の分類は、要求QPSと同じです。 +- RPC スレッド: 各TiFlashインスタンスで使用される RPC スレッドのリアルタイム数。 +- RPC の最大スレッド数: 各TiFlashインスタンスで最近使用された RPC スレッドの最大数。 +- スレッド: 各TiFlashインスタンスで使用されるスレッドのリアルタイム数。 +- 最大スレッド数: 各TiFlashインスタンスで最近使用されたスレッドの最大数。 ## タスクスケジューラ {#task-scheduler} -- 最小TSO: 各TiFlashインスタンスで実行されているすべてのクエリの中で最小のTSOです。この値により、最小TSOのクエリの実行スケジュールが確保されます。実行中のクエリがない場合、この値は符号なし64ビット整数の最大値となります。 -- 推定スレッド使用量と制限: 各TiFlashインスタンスで実行されるすべてのクエリによって使用されるスレッドの推定量と、その量に対するソフト制限とハード制限。 -- アクティブおよび待機中のクエリ数: 各TiFlashインスタンスで実行中のクエリの数と待機中のクエリの数。 -- アクティブおよび待機中のタスク数: 各TiFlashインスタンスで実行中のタスクと待機中のタスクの数。 -- ハード制限超過回数: 各TiFlashインスタンスで実行されているクエリによって使用されるスレッドの推定数がハード制限を超えた回数。 -- タスク待機期間: 各TiFlashインスタンスでのタスクの初期化からタスクのスケジュールまでの期間。 +- 最小TSO: 各TiFlashインスタンスで実行されているすべてのクエリの中で最小のTSOです。この値により、最小TSOのクエリの実行スケジュールが確保されます。実行中のクエリがない場合、この値は符号なし64ビット整数の最大値となります。 +- 推定スレッド使用量と制限: 各TiFlashインスタンスで実行されるすべてのクエリによって使用されるスレッドの推定量と、その量に対するソフト制限とハード制限。 +- アクティブおよび待機中のクエリ数: 各TiFlashインスタンスで実行中のクエリの数と待機中のクエリの数。 +- アクティブおよび待機中のタスク数: 各TiFlashインスタンスで実行中のタスクと待機中のタスクの数。 +- ハード制限超過回数: 各TiFlashインスタンスで実行されているクエリによって使用されるスレッドの推定数がハード制限を超えた回数。 +- タスク待機期間: 各TiFlashインスタンスでのタスクの初期化からタスクのスケジュールまでの期間。 ## DDL {#ddl} -- スキーマ バージョン: 各TiFlashインスタンスに現在キャッシュされているスキーマのバージョン。 -- スキーマ適用OPM：すべてのTiFlashインスタンスによって1分間に`apply`操作で同期されたTiDB `schema diff`の数。この項目には、 `diff apply` 、 `full apply` 、 `failed apply`の3種類の`apply`のカウントが含まれます。`diff apply`は単一の適用の通常のプロセスです。`diff apply`が失敗した場合、 `failed apply`が`1`増加し、 TiFlashは`full apply`にロールバックし、最新のスキーマ情報を取得してTiFlashのスキーマバージョンを更新します。 -- スキーマ内部 DDL OPM: すべてのTiFlashインスタンスで 1 分あたりに実行された特定の DDL 操作の数。 -- スキーマ適用期間: すべてのTiFlashインスタンスでの単一の`apply schema`操作に使用される時間。 +- スキーマ バージョン: 各TiFlashインスタンスに現在キャッシュされているスキーマのバージョン。 +- スキーマ適用OPM：すべてのTiFlashインスタンスによって1分間に`apply`操作で同期されたTiDB `schema diff`の数。この項目には、 `diff apply` 、 `full apply` 、 `failed apply`の3種類の`apply`のカウントが含まれます。`diff apply`は単一の適用の通常のプロセスです。`diff apply`が失敗した場合、 `failed apply`が`1`増加し、 TiFlashは`full apply`にロールバックし、最新のスキーマ情報を取得してTiFlashのスキーマバージョンを更新します。 +- スキーマ内部 DDL OPM: すべてのTiFlashインスタンスで 1 分あたりに実行された特定の DDL 操作の数。 +- スキーマ適用期間: すべてのTiFlashインスタンスでの単一の`apply schema`操作に使用される時間。 ## ストレージ {#storage} -- 書き込みコマンド OPS: すべてのTiFlashインスタンスのストレージレイヤーで 1 秒あたりに受信される書き込み要求の数。 -- 書き込み増幅: 各TiFlashインスタンスの書き込み増幅 (実際のディスク書き込みバイト数を論理データの書き込みバイト数で割った値)。`total`はこの開始以降の書き込み増幅で、 `5min`は過去 5 分間の書き込み増幅です。 -- 読み取りタスク OPS: TiFlashインスタンスごとのストレージレイヤーでの 1 秒あたりの読み取りタスクの数。 -- 粗セット フィルタ レート: ストレージストレージの粗セットレイヤーによってフィルタされた、過去 1 分間に各TiFlashインスタンスによって読み取られたパケット数の割合。 -- 内部タスク OPS: すべてのTiFlashインスタンスが 1 秒あたりに内部データ ソート タスクを実行する回数。 -- 内部タスクの所要時間: すべてのTiFlashインスタンスが内部データ ソート タスクに費やした時間。 -- ページ GC タスク OPM: すべてのTiFlashインスタンスが 1 分間に Delta データ ソート タスクを実行する回数。 -- ページ GC タスクの所要時間: Delta データ ソート タスクを実行するためにすべてのTiFlashインスタンスで消費される時間の分布。 -- ディスク書き込み OPS: すべてのTiFlashインスタンスによる 1 秒あたりのディスク書き込み数。 -- ディスク読み取り OPS: すべてのTiFlashインスタンスによる 1 秒あたりのディスク読み取り数。 -- 書き込みフロー: すべてのTiFlashインスタンスによるディスク書き込みのトラフィック。 -- 読み取りフロー: すべてのTiFlashインスタンスによるディスク読み取りのトラフィック。 +- 書き込みコマンド OPS: すべてのTiFlashインスタンスのストレージレイヤーで 1 秒あたりに受信される書き込み要求の数。 +- 書き込み増幅: 各TiFlashインスタンスの書き込み増幅 (実際のディスク書き込みバイト数を論理データの書き込みバイト数で割った値)。`total`はこの開始以降の書き込み増幅で、 `5min`は過去 5 分間の書き込み増幅です。 +- 読み取りタスク OPS: TiFlashインスタンスごとのストレージレイヤーでの 1 秒あたりの読み取りタスクの数。 +- 粗セット フィルタ レート: ストレージストレージの粗セットレイヤーによってフィルタされた、過去 1 分間に各TiFlashインスタンスによって読み取られたパケット数の割合。 +- 内部タスク OPS: すべてのTiFlashインスタンスが 1 秒あたりに内部データ ソート タスクを実行する回数。 +- 内部タスクの所要時間: すべてのTiFlashインスタンスが内部データ ソート タスクに費やした時間。 +- ページ GC タスク OPM: すべてのTiFlashインスタンスが 1 分間に Delta データ ソート タスクを実行する回数。 +- ページ GC タスクの所要時間: Delta データ ソート タスクを実行するためにすべてのTiFlashインスタンスで消費される時間の分布。 +- ディスク書き込み OPS: すべてのTiFlashインスタンスによる 1 秒あたりのディスク書き込み数。 +- ディスク読み取り OPS: すべてのTiFlashインスタンスによる 1 秒あたりのディスク読み取り数。 +- 書き込みフロー: すべてのTiFlashインスタンスによるディスク書き込みのトラフィック。 +- 読み取りフロー: すべてのTiFlashインスタンスによるディスク読み取りのトラフィック。 > **Note:** > @@ -87,20 +87,20 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## ストレージ書き込み停止 {#storage-write-stall} -- 書き込みとデルタ管理スループット: すべてのインスタンスの書き込みとデータ圧縮のスループット。 - - `throughput_write` Raftを介したデータ同期のスループットを意味します。 - - `throughput_delta-management`データ圧縮のスループットを意味します。 - - `total_write` 、前回の開始以降に書き込まれた合計バイト数を意味します。 - - `total_delta-management` 、前回の開始以降に圧縮されたデータの合計バイト数を意味します。 -- 書き込み停止期間: インスタンスごとの書き込みおよびリージョンデータの削除 (範囲の削除) の停止期間。 -- インスタンスごとの書き込みスループット：インスタンスごとの書き込みスループット。RaftRaftコマンドとRaftスナップショットを適用した場合のスループットも含まれます。 -- インスタンス別の書き込みコマンド OPS: インスタンスによって受信されたさまざまな種類のコマンドの合計数。 - - `write block` 、データ ログがRaftを通じて同期されることを意味します。 - - `delete_range` 、一部のリージョンがこのインスタンスから削除されるか、このインスタンスに移動されることを意味します。 - - `ingest` 、いくつかのリージョンスナップショットがこのインスタンスに適用されていることを意味します。 +- 書き込みとデルタ管理スループット: すべてのインスタンスの書き込みとデータ圧縮のスループット。 + - `throughput_write` Raftを介したデータ同期のスループットを意味します。 + - `throughput_delta-management`データ圧縮のスループットを意味します。 + - `total_write` 、前回の開始以降に書き込まれた合計バイト数を意味します。 + - `total_delta-management` 、前回の開始以降に圧縮されたデータの合計バイト数を意味します。 +- 書き込み停止期間: インスタンスごとの書き込みおよびリージョンデータの削除 (範囲の削除) の停止期間。 +- インスタンスごとの書き込みスループット：インスタンスごとの書き込みスループット。RaftRaftコマンドとRaftスナップショットを適用した場合のスループットも含まれます。 +- インスタンス別の書き込みコマンド OPS: インスタンスによって受信されたさまざまな種類のコマンドの合計数。 + - `write block` 、データ ログがRaftを通じて同期されることを意味します。 + - `delete_range` 、一部のリージョンがこのインスタンスから削除されるか、このインスタンスに移動されることを意味します。 + - `ingest` 、いくつかのリージョンスナップショットがこのインスタンスに適用されていることを意味します。 ## Raft {#raft} -- 読み取りインデックス OPS: 各TiFlashインスタンスが`read_index`回のリクエストをトリガーする回数。これはトリガーされたリージョンの数に等しくなります。 -- インデックス読み取り時間: すべてのTiFlashインスタンスの`read_index`が使用する時間。ほとんどの時間は、リージョンリーダーとのやり取りと再試行に使用されます。 -- インデックス待機期間: すべてのTiFlashインスタンスに対して`wait_index`が使用する時間。つまり、 `read_index`要求を受信した後、ローカル インデックス >= read_index になるまで待機する時間です。 +- 読み取りインデックス OPS: 各TiFlashインスタンスが`read_index`回のリクエストをトリガーする回数。これはトリガーされたリージョンの数に等しくなります。 +- インデックス読み取り時間: すべてのTiFlashインスタンスの`read_index`が使用する時間。ほとんどの時間は、リージョンリーダーとのやり取りと再試行に使用されます。 +- インデックス待機期間: すべてのTiFlashインスタンスに対して`wait_index`が使用する時間。つまり、 `read_index`要求を受信した後、ローカル インデックス >= read_index になるまで待機する時間です。 diff --git a/tiflash/tiflash-alert-rules.md b/tiflash/tiflash-alert-rules.md index 817c185f1cf7b..fd52da1d4ccac 100644 --- a/tiflash/tiflash-alert-rules.md +++ b/tiflash/tiflash-alert-rules.md @@ -9,39 +9,39 @@ summary: TiFlashクラスターのアラート ルールについて学習しま ## `TiFlash_schema_error` {#tiflash-schema-error} -- アラートルール: +- アラートルール: `increase(tiflash_schema_apply_count{type="failed"}[15m]) > 0` -- 説明： +- 説明： スキーマ適用エラーが発生すると、アラートがトリガーされます。 -- 解決： +- 解決： このエラーは、何らかの間違ったロジックによって発生した可能性があります。PingCAP またはコミュニティから[サポートを受けて](/support.md)ください。 ## `TiFlash_schema_apply_duration` {#tiflash-schema-apply-duration} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(tiflash_schema_apply_duration_seconds_bucket[1m])) BY (le, instance)) > 20` -- 説明： +- 説明： 適用期間が 20 秒を超える確率が 99% を超えると、アラートがトリガーされます。 -- 解決： +- 解決： これは、 TiFlashストレージエンジンの内部的な問題が原因である可能性があります。PingCAP またはコミュニティから[サポートを受けて](/support.md)ください。 ## `TiFlash_raft_read_index_duration` {#tiflash-raft-read-index-duration} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(tiflash_raft_read_index_duration_seconds_bucket[1m])) BY (le, instance)) > 3` -- 説明： +- 説明： 読み取りインデックスの継続時間が 3 秒を超える確率が 99% を超えると、アラートがトリガーされます。 @@ -49,20 +49,20 @@ summary: TiFlashクラスターのアラート ルールについて学習しま > > `read index`は TiKV リーダーに送信される kvproto リクエストです。TiKV リージョンの再試行、ストアのビジー状態、またはネットワークの問題により、リクエスト時間が`read index`と長くなる可能性があります。 -- 解決： +- 解決： 頻繁な再試行は、TiKV クラスターの頻繁な分割または移行が原因である可能性があります。再試行の理由を特定するには、TiKV クラスターのステータスを確認してください。 ## `TiFlash_raft_wait_index_duration` {#tiflash-raft-wait-index-duration} -- アラートルール: +- アラートルール: `histogram_quantile(0.99, sum(rate(tiflash_raft_wait_index_duration_seconds_bucket[1m])) BY (le, instance)) > 2` -- 説明： +- 説明： TiFlashのリージョン Raft Index の待機時間が 2 秒を超える確率が 99% を超えると、アラートがトリガーされます。 -- 解決： +- 解決： これは、TiKV とプロキシ間の通信エラーが原因である可能性があります。PingCAP またはコミュニティから[サポートを受けて](/support.md)ください。 diff --git a/tiflash/tiflash-command-line-flags.md b/tiflash/tiflash-command-line-flags.md index a24e244de86ba..a2c7ba028914c 100644 --- a/tiflash/tiflash-command-line-flags.md +++ b/tiflash/tiflash-command-line-flags.md @@ -9,33 +9,33 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま ## `server --config-file` {#server---config-file} -- TiFlash構成ファイルのパスを指定します -- デフォルト： "" -- 設定ファイルを指定する必要があります。詳細な設定項目については[TiFlash構成パラメータ](/tiflash/tiflash-configuration.md)を参照してください。 +- TiFlash構成ファイルのパスを指定します +- デフォルト： "" +- 設定ファイルを指定する必要があります。詳細な設定項目については[TiFlash構成パラメータ](/tiflash/tiflash-configuration.md)を参照してください。 ## `dttool migrate` {#dttool-migrate} -- DTFileのファイル形式を移行します（テストまたはダウングレード用）。データは単一のDTFile単位で移行されます。テーブル全体を移行する場合は、 `/t_
/stable/dmf_`に類似するすべてのパスを特定し、1つずつ移行する必要があります。スクリプトを使用して移行を自動化できます。 +- DTFileのファイル形式を移行します（テストまたはダウングレード用）。データは単一のDTFile単位で移行されます。テーブル全体を移行する場合は、 `/t_
/stable/dmf_`に類似するすべてのパスを特定し、1つずつ移行する必要があります。スクリプトを使用して移行を自動化できます。 -- ユーザーシナリオ: +- ユーザーシナリオ: - - データ検証が有効になっているバージョン v5.4.0 以上からバージョン v5.4.0 未満にTiFlash をダウングレードする必要がある場合は、このツールを使用して DTFile のデータ形式をダウングレードできます。 - - TiFlash をバージョン >= v5.4.0 にアップグレードし、既存のデータのデータ検証を有効にする場合は、このツールを使用して DTFile のデータ形式をアップグレードできます。 - - さまざまな構成で DTFile のスペース使用量と読み取り速度をテストします。 - - 小さなファイルのマージが有効になっているバージョン v7.3.0 以上 (つまり、 `storage.format_version` >= 5) のTiFlash をバージョン v7.3.0 未満にダウングレードする必要がある場合は、このツールを使用して DTFile のデータ形式をダウングレードできます。 + - データ検証が有効になっているバージョン v5.4.0 以上からバージョン v5.4.0 未満にTiFlash をダウングレードする必要がある場合は、このツールを使用して DTFile のデータ形式をダウングレードできます。 + - TiFlash をバージョン >= v5.4.0 にアップグレードし、既存のデータのデータ検証を有効にする場合は、このツールを使用して DTFile のデータ形式をアップグレードできます。 + - さまざまな構成で DTFile のスペース使用量と読み取り速度をテストします。 + - 小さなファイルのマージが有効になっているバージョン v7.3.0 以上 (つまり、 `storage.format_version` >= 5) のTiFlash をバージョン v7.3.0 未満にダウングレードする必要がある場合は、このツールを使用して DTFile のデータ形式をダウングレードできます。 -- パラメータ: - - `--imitative` : DTFile の暗号化機能を使用しない場合は、このフラグを使用して構成ファイルの使用と PD への接続を回避できます。 - - `--version` : DTFileのターゲットバージョン。値のオプションは`1` 、 `2` （デフォルト）、 `3`です。 `1`は古いバージョン、 `2`は新しいチェックサムに対応するバージョン、 `3`は小さなファイルのマージをサポートするバージョンです。 - - `--algorithm` : データ検証に使用するハッシュアルゴリズム。値の選択肢は`xxh3` （デフォルト）、 `city128` 、 `crc32` 、 `crc64` 、 `none`です。このパラメータは`version`が`2`の場合にのみ有効です。 - - `--frame` : 検証フレームのサイズ。デフォルト値は`1048576`です。このパラメータは`version`が`2`の場合にのみ有効です。 - - `--compression` : 対象の圧縮アルゴリズム。値のオプションは`LZ4` （デフォルト）、 `LZ4HC` 、 `zstd` 、 `none`です。 - - `--level` : 目標圧縮レベル。指定しない場合は、圧縮アルゴリズムに応じて推奨圧縮レベルがデフォルトで使用されます。`compression`が`LZ4`または`zstd`に設定されている場合、デフォルトのレベルは 1 です。`compression`が`LZ4HC`に設定されている場合、デフォルトのレベルは 9 です。 - - `--config-file` : `dttool migrate`の設定ファイルは[`server`の設定ファイル](/tiflash/tiflash-command-line-flags.md#server---config-file)と同じです。詳細については`--imitative`を参照してください。 - - `--file-id` : DTFileのID。例えば、DTFile `dmf_123`のIDは`123`です。 - - `--workdir` : `dmf_xxx`の親ディレクトリ。 - - `--dry` : ドライランモード。移行プロセスのみが出力されます。 - - `--nokeep` : 元のデータを保持しません。このオプションが有効になっていない場合、 `dmf_xxx.old`ファイルが作成されます。 +- パラメータ: + - `--imitative` : DTFile の暗号化機能を使用しない場合は、このフラグを使用して構成ファイルの使用と PD への接続を回避できます。 + - `--version` : DTFileのターゲットバージョン。値のオプションは`1` 、 `2` （デフォルト）、 `3`です。 `1`は古いバージョン、 `2`は新しいチェックサムに対応するバージョン、 `3`は小さなファイルのマージをサポートするバージョンです。 + - `--algorithm` : データ検証に使用するハッシュアルゴリズム。値の選択肢は`xxh3` （デフォルト）、 `city128` 、 `crc32` 、 `crc64` 、 `none`です。このパラメータは`version`が`2`の場合にのみ有効です。 + - `--frame` : 検証フレームのサイズ。デフォルト値は`1048576`です。このパラメータは`version`が`2`の場合にのみ有効です。 + - `--compression` : 対象の圧縮アルゴリズム。値のオプションは`LZ4` （デフォルト）、 `LZ4HC` 、 `zstd` 、 `none`です。 + - `--level` : 目標圧縮レベル。指定しない場合は、圧縮アルゴリズムに応じて推奨圧縮レベルがデフォルトで使用されます。`compression`が`LZ4`または`zstd`に設定されている場合、デフォルトのレベルは 1 です。`compression`が`LZ4HC`に設定されている場合、デフォルトのレベルは 9 です。 + - `--config-file` : `dttool migrate`の設定ファイルは[`server`の設定ファイル](/tiflash/tiflash-command-line-flags.md#server---config-file)と同じです。詳細については`--imitative`を参照してください。 + - `--file-id` : DTFileのID。例えば、DTFile `dmf_123`のIDは`123`です。 + - `--workdir` : `dmf_xxx`の親ディレクトリ。 + - `--dry` : ドライランモード。移行プロセスのみが出力されます。 + - `--nokeep` : 元のデータを保持しません。このオプションが有効になっていない場合、 `dmf_xxx.old`ファイルが作成されます。 > **Warning:** > @@ -49,33 +49,33 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま ## `dttool bench` {#dttool-bench} -- DTFile の基本的な I/O 速度テストを提供します。 -- パラメータ: +- DTFile の基本的な I/O 速度テストを提供します。 +- パラメータ: - - `--version` : DTFileのバージョン。[`dttool migrate`における`--version`](#dttool-migrate)を参照してください。 - - `--algorithm` : データ検証に使用されるハッシュアルゴリズム。[`dttool migrate`における`--algorithm`](#dttool-migrate)を参照してください。 - - `--frame` : 検証フレームのサイズ。[`dttool migrate`における`--frame`](#dttool-migrate)を参照してください。 - - `--column` : テストするテーブルの列。デフォルト値は`100`です。 - - `--size` : テストするテーブルの行。デフォルト値は`1000`です。 - - `--field` : テスト対象テーブルのフィールド長制限。デフォルト値は`1024`です。 - - `--random` : 乱数シード。このパラメータを指定しない場合、乱数シードはシステムエントロピープールから取得されます。 - - `--encryption` : 暗号化機能を有効にします。 - - `--repeat` : テストを繰り返す回数。デフォルト値は`5`です。 - - `--workdir` : テスト対象のファイルシステム内のパスを指す一時データディレクトリ。デフォルト値は`/tmp/test`です。 + - `--version` : DTFileのバージョン。[`dttool migrate`における`--version`](#dttool-migrate)を参照してください。 + - `--algorithm` : データ検証に使用されるハッシュアルゴリズム。[`dttool migrate`における`--algorithm`](#dttool-migrate)を参照してください。 + - `--frame` : 検証フレームのサイズ。[`dttool migrate`における`--frame`](#dttool-migrate)を参照してください。 + - `--column` : テストするテーブルの列。デフォルト値は`100`です。 + - `--size` : テストするテーブルの行。デフォルト値は`1000`です。 + - `--field` : テスト対象テーブルのフィールド長制限。デフォルト値は`1024`です。 + - `--random` : 乱数シード。このパラメータを指定しない場合、乱数シードはシステムエントロピープールから取得されます。 + - `--encryption` : 暗号化機能を有効にします。 + - `--repeat` : テストを繰り返す回数。デフォルト値は`5`です。 + - `--workdir` : テスト対象のファイルシステム内のパスを指す一時データディレクトリ。デフォルト値は`/tmp/test`です。 ## `dttool inspect` {#dttool-inspect} -- DTFileの整合性をチェックします。データ検証は単一のDTFile単位で実行されます。テーブル全体を検証する場合は、 `/t_
/stable/dmf_`に類似するすべてのパスを特定し、1つずつ検証する必要があります。スクリプトを使用して検証を自動化できます。 +- DTFileの整合性をチェックします。データ検証は単一のDTFile単位で実行されます。テーブル全体を検証する場合は、 `/t_
/stable/dmf_`に類似するすべてのパスを特定し、1つずつ検証する必要があります。スクリプトを使用して検証を自動化できます。 -- ユーザーシナリオ: +- ユーザーシナリオ: - - 形式のアップグレードまたはダウングレードを実行した後、DTFile のデータ整合性を検証できます。 - - DTFile を新しい環境に移行した後、DTFile のデータ整合性を検証できます。 + - 形式のアップグレードまたはダウングレードを実行した後、DTFile のデータ整合性を検証できます。 + - DTFile を新しい環境に移行した後、DTFile のデータ整合性を検証できます。 -- パラメータ: +- パラメータ: - - `--config-file` : `dttool bench`の設定ファイル。[`dttool migrate`における`--config-file`](#dttool-migrate)を参照してください。 - - `--check` : ハッシュ検証を実行します。 - - `--file-id` ：DTFileのID。[`dttool migrate`における`--file-id`](#dttool-migrate)を参照してください。 - - `--imitative` : データベースコンテキストを模倣します。[`dttool migrate`における`--imitative`](#dttool-migrate)を参照してください。 - - `--workdir` : データディレクトリ。[`dttool migrate`における`--workdir`](#dttool-migrate)を参照してください。 + - `--config-file` : `dttool bench`の設定ファイル。[`dttool migrate`における`--config-file`](#dttool-migrate)を参照してください。 + - `--check` : ハッシュ検証を実行します。 + - `--file-id` ：DTFileのID。[`dttool migrate`における`--file-id`](#dttool-migrate)を参照してください。 + - `--imitative` : データベースコンテキストを模倣します。[`dttool migrate`における`--imitative`](#dttool-migrate)を参照してください。 + - `--workdir` : データディレクトリ。[`dttool migrate`における`--workdir`](#dttool-migrate)を参照してください。 diff --git a/tiflash/tiflash-compatibility.md b/tiflash/tiflash-compatibility.md index 964dc0438165b..34b67752d62c5 100644 --- a/tiflash/tiflash-compatibility.md +++ b/tiflash/tiflash-compatibility.md @@ -7,12 +7,12 @@ summary: TiFlashと互換性のない TiDB 機能について説明します。 次の状況では、 TiFlashは TiDB と互換性がありません。 -- TiFlash計算レイヤー: - - オーバーフローした[数値](/data-type-numeric.md)チェックはサポートされていません。例えば、 `BIGINT`の最大値2つを加算して`9223372036854775807 + 9223372036854775807` 。TiDBでは、この計算は`ERROR 1690 (22003): BIGINT value is out of range`エラーを返すことが期待されます。しかし、この計算をTiFlashで実行すると、エラーなしでオーバーフロー値`-2`が返されます。 - - [ウィンドウ関数](/functions-and-operators/window-functions.md)すべてが[プッシュダウン](/tiflash/tiflash-supported-pushdown-calculations.md)でサポートされているわけではありません。 - - TiKV からのデータの読み取りはサポートされていません。 - - 現在、 TiFlashの[`SUM`](/functions-and-operators/aggregate-group-by-functions.md#supported-aggregate-functions)関数は文字列型の引数をサポートしていません。しかし、TiDBはコンパイル時に`SUM`関数に文字列型の引数が渡されたかどうかを識別できません。そのため、 `SELECT SUM(string_col) FROM t`のような文を実行すると、 TiFlashは`[FLASH:Coprocessor:Unimplemented] CastStringAsReal is not supported.`エラーを返します。このようなエラーを回避するには、このSQL文を`SELECT SUM(CAST(string_col AS double)) FROM t`に変更する必要があります。 - - 現在、TiFlash の小数除算計算は TiDB のものと互換性がありません。例えば、小数除算を行う場合、 TiFlash は常にコンパイルから推論された型を使用して計算を実行します。一方、TiDB はコンパイルから推論された型よりも精度の高い型を使用して計算を実行します。そのため、小数除算を含む一部の SQL 文は、TiDB + TiKV と TiDB + TiFlashで実行した場合で異なる実行結果を返します。例えば、次のようになります。 +- TiFlash計算レイヤー: + - オーバーフローした[数値](/data-type-numeric.md)チェックはサポートされていません。例えば、 `BIGINT`の最大値2つを加算して`9223372036854775807 + 9223372036854775807` 。TiDBでは、この計算は`ERROR 1690 (22003): BIGINT value is out of range`エラーを返すことが期待されます。しかし、この計算をTiFlashで実行すると、エラーなしでオーバーフロー値`-2`が返されます。 + - [ウィンドウ関数](/functions-and-operators/window-functions.md)すべてが[プッシュダウン](/tiflash/tiflash-supported-pushdown-calculations.md)でサポートされているわけではありません。 + - TiKV からのデータの読み取りはサポートされていません。 + - 現在、 TiFlashの[`SUM`](/functions-and-operators/aggregate-group-by-functions.md#supported-aggregate-functions)関数は文字列型の引数をサポートしていません。しかし、TiDBはコンパイル時に`SUM`関数に文字列型の引数が渡されたかどうかを識別できません。そのため、 `SELECT SUM(string_col) FROM t`のような文を実行すると、 TiFlashは`[FLASH:Coprocessor:Unimplemented] CastStringAsReal is not supported.`エラーを返します。このようなエラーを回避するには、このSQL文を`SELECT SUM(CAST(string_col AS double)) FROM t`に変更する必要があります。 + - 現在、TiFlash の小数除算計算は TiDB のものと互換性がありません。例えば、小数除算を行う場合、 TiFlash は常にコンパイルから推論された型を使用して計算を実行します。一方、TiDB はコンパイルから推論された型よりも精度の高い型を使用して計算を実行します。そのため、小数除算を含む一部の SQL 文は、TiDB + TiKV と TiDB + TiFlashで実行した場合で異なる実行結果を返します。例えば、次のようになります。 ```sql mysql> CREATE TABLE t (a DECIMAL(3,0), b DECIMAL(10, 0)); diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index 2353338e9a656..221e3f0d3745a 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -19,51 +19,51 @@ summary: TiFlash の設定方法を学びます。 #### `listen_host` {#listen_host} -- TPC/HTTP などのサービスをサポートするためのリスニング ホスト。 -- これを`"0.0.0.0"`に設定することをお勧めします。これは、このマシンのすべての IP アドレスをリッスンすることを意味します。 +- TPC/HTTP などのサービスをサポートするためのリスニング ホスト。 +- これを`"0.0.0.0"`に設定することをお勧めします。これは、このマシンのすべての IP アドレスをリッスンすることを意味します。 #### `tcp_port` {#tcp_port} -- TiFlash TCP サービスポート。このポートは内部テストに使用され、デフォルトでは 9000 に設定されています。 -- TiFlash v7.1.0より前のバージョンでは、このポートはデフォルトで有効になっていますが、セキュリティリスクがあります。セキュリティを強化するため、このポートにアクセス制御を適用し、ホワイトリストに登録されたIPアドレスからのアクセスのみを許可することをお勧めします。TiFlash v7.1.0以降では、このポートの設定をコメントアウトすることでセキュリティリスクを回避できます。TiFlashの設定ファイルでこのポートが指定されていない場合、このポートは無効になります。 -- TiFlashデプロイメントでは、このポートを構成することは推奨され**ません**。(注: TiFlash v7.1.0 以降、 TiUP >= v1.12.5 またはTiDB Operator >= v1.5.0 でデプロイされたTiFlash は、デフォルトでポートを無効にし、より安全になっています。) -- デフォルト値: `9000` +- TiFlash TCP サービスポート。このポートは内部テストに使用され、デフォルトでは 9000 に設定されています。 +- TiFlash v7.1.0より前のバージョンでは、このポートはデフォルトで有効になっていますが、セキュリティリスクがあります。セキュリティを強化するため、このポートにアクセス制御を適用し、ホワイトリストに登録されたIPアドレスからのアクセスのみを許可することをお勧めします。TiFlash v7.1.0以降では、このポートの設定をコメントアウトすることでセキュリティリスクを回避できます。TiFlashの設定ファイルでこのポートが指定されていない場合、このポートは無効になります。 +- TiFlashデプロイメントでは、このポートを構成することは推奨され**ません**。(注: TiFlash v7.1.0 以降、 TiUP >= v1.12.5 またはTiDB Operator >= v1.5.0 でデプロイされたTiFlash は、デフォルトでポートを無効にし、より安全になっています。) +- デフォルト値: `9000` #### `mark_cache_size` {#mark_cache_size} -- データブロックのメタデータのキャッシュサイズ制限。通常、この値を変更する必要はありません。 -- デフォルト値: `1073741824` +- データブロックのメタデータのキャッシュサイズ制限。通常、この値を変更する必要はありません。 +- デフォルト値: `1073741824` #### `minmax_index_cache_size` {#minmax_index_cache_size} -- データブロックの最小-最大インデックスのキャッシュサイズ制限。通常、この値を変更する必要はありません。 -- デフォルト値: `1073741824` +- データブロックの最小-最大インデックスのキャッシュサイズ制限。通常、この値を変更する必要はありません。 +- デフォルト値: `1073741824` #### `delta_index_cache_size` {#delta_index_cache_size} -- DeltaIndex のキャッシュ サイズの制限。 -- デフォルト値: `0` 、制限がないことを意味します。 +- DeltaIndex のキャッシュ サイズの制限。 +- デフォルト値: `0` 、制限がないことを意味します。 #### `path` {#path} -- TiFlashデータのストレージパス。複数のディレクトリがある場合は、各ディレクトリをカンマで区切ってください。 -- TiDB v4.0.9以降、 `path`と[`path_realtime_mode`](#path_realtime_mode)は非推奨となりました。マルチディスク展開シナリオでパフォーマンスを向上させるには、 [`storage`](#storage-new-in-v409)セクションの設定を使用してください。 -- TiDB v5.2.0 以降、 [`storage.io_rate_limit`](#storageio_rate_limit-new-in-v520)構成を使用する必要がある場合は、同時にTiFlashデータのストレージパスを[`storage.main.dir`](#dir)に設定する必要があります。 -- `storage`構成が存在する場合、 `path`と[`path_realtime_mode`](#path_realtime_mode)構成は両方とも無視されます。 +- TiFlashデータのストレージパス。複数のディレクトリがある場合は、各ディレクトリをカンマで区切ってください。 +- TiDB v4.0.9以降、 `path`と[`path_realtime_mode`](#path_realtime_mode)は非推奨となりました。マルチディスク展開シナリオでパフォーマンスを向上させるには、 [`storage`](#storage-new-in-v409)セクションの設定を使用してください。 +- TiDB v5.2.0 以降、 [`storage.io_rate_limit`](#storageio_rate_limit-new-in-v520)構成を使用する必要がある場合は、同時にTiFlashデータのストレージパスを[`storage.main.dir`](#dir)に設定する必要があります。 +- `storage`構成が存在する場合、 `path`と[`path_realtime_mode`](#path_realtime_mode)構成は両方とも無視されます。 #### `path_realtime_mode` {#path_realtime_mode} -- `true`に設定し、 `path`に複数のディレクトリを設定した場合、最初のディレクトリに最新のデータが保存され、残りのディレクトリには古いデータが保存されます。 -- TiDB v4.0.9以降、 [`path`](#path)と`path_realtime_mode`は非推奨となりました。マルチディスク展開シナリオでパフォーマンスを向上させるには、 [`storage`](#storage-new-in-v409)セクションの設定を使用してください。 -- `storage`構成が存在する場合、 [`path`](#path)と`path_realtime_mode`構成は両方とも無視されます。 -- デフォルト値: `false` +- `true`に設定し、 `path`に複数のディレクトリを設定した場合、最初のディレクトリに最新のデータが保存され、残りのディレクトリには古いデータが保存されます。 +- TiDB v4.0.9以降、 [`path`](#path)と`path_realtime_mode`は非推奨となりました。マルチディスク展開シナリオでパフォーマンスを向上させるには、 [`storage`](#storage-new-in-v409)セクションの設定を使用してください。 +- `storage`構成が存在する場合、 [`path`](#path)と`path_realtime_mode`構成は両方とも無視されます。 +- デフォルト値: `false` #### `tmp_path` {#tmp_path} -- TiFlash一時ファイルが保存されるパス。 -- デフォルトでは、 [`path`](#path)の最初のディレクトリ、または[`storage.latest.dir`](#dir-1)に`"/tmp"`を付加したディレクトリになります。 +- TiFlash一時ファイルが保存されるパス。 +- デフォルトでは、 [`path`](#path)の最初のディレクトリ、または[`storage.latest.dir`](#dir-1)に`"/tmp"`を付加したディレクトリになります。 @@ -73,42 +73,42 @@ summary: TiFlash の設定方法を学びます。 ##### `format_version` {#format_version} -- DTFile 形式。 -- デフォルト値: `7` -- `6` `4` `7` `5` `2` `3` - - `format_version = 2` : バージョン v6.0.0 未満のデフォルトの形式。 - - `format_version = 3` : v6.0.0 および v6.1.x のデフォルト形式。より多くのデータ検証機能が提供されます。 - - `format_version = 4` : バージョン v6.2.0 から v7.3.0 までのデフォルトの形式。書き込み増幅とバックグラウンド タスクのリソース消費を削減します。 - - `format_version = 5` : v7.3.0 で導入され、v7.4.0 から v8.3.0 までのバージョンのデフォルト形式で、小さなファイルを結合することで物理ファイルの数を削減します。 - - `format_version = 6` : v8.4.0 で導入され、ベクトル インデックスの構築とストレージを部分的にサポートします。 - - `format_version = 7` : v8.4.0 で導入され、v8.4.0 以降のバージョンのデフォルト形式で、ベクトル インデックスの構築とストレージをサポートします。 +- DTFile 形式。 +- デフォルト値: `7` +- `6` `4` `7` `5` `2` `3` + - `format_version = 2` : バージョン v6.0.0 未満のデフォルトの形式。 + - `format_version = 3` : v6.0.0 および v6.1.x のデフォルト形式。より多くのデータ検証機能が提供されます。 + - `format_version = 4` : バージョン v6.2.0 から v7.3.0 までのデフォルトの形式。書き込み増幅とバックグラウンド タスクのリソース消費を削減します。 + - `format_version = 5` : v7.3.0 で導入され、v7.4.0 から v8.3.0 までのバージョンのデフォルト形式で、小さなファイルを結合することで物理ファイルの数を削減します。 + - `format_version = 6` : v8.4.0 で導入され、ベクトル インデックスの構築とストレージを部分的にサポートします。 + - `format_version = 7` : v8.4.0 で導入され、v8.4.0 以降のバージョンのデフォルト形式で、ベクトル インデックスの構築とストレージをサポートします。 #### storage.main {#storagemain} ##### `dir` {#dir-1} -- メインデータを保存するディレクトリのリスト。例： `[ "/tidb-data/tiflash-9000" ]`または`[ "/ssd0/tidb-data/tiflash", "/ssd1/tidb-data/tiflash" ]` 。 -- 全データの 90% 以上がディレクトリ リストに保存されます。 +- メインデータを保存するディレクトリのリスト。例： `[ "/tidb-data/tiflash-9000" ]`または`[ "/ssd0/tidb-data/tiflash", "/ssd1/tidb-data/tiflash" ]` 。 +- 全データの 90% 以上がディレクトリ リストに保存されます。 ##### `capacity` {#capacity-1} -- [`storage.main.dir`](#dir)内の各ディレクトリの最大ストレージ容量。例: `[10737418240, 10737418240]` 。 -- 設定されていない場合、または`0`倍数に設定されている場合、実際のディスク (ディレクトリが配置されているディスク) の容量が使用されます。 -- 単位: バイト`"10GB"`などの人間が読める数値はまだサポートされていないことに注意してください。 -- `capacity`リストのサイズは[`storage.main.dir`](#dir)リストのサイズと同じである必要があります。 +- [`storage.main.dir`](#dir)内の各ディレクトリの最大ストレージ容量。例: `[10737418240, 10737418240]` 。 +- 設定されていない場合、または`0`倍数に設定されている場合、実際のディスク (ディレクトリが配置されているディスク) の容量が使用されます。 +- 単位: バイト`"10GB"`などの人間が読める数値はまだサポートされていないことに注意してください。 +- `capacity`リストのサイズは[`storage.main.dir`](#dir)リストのサイズと同じである必要があります。 #### storage.latest {#storagelatest} ##### `dir` {#dir-2} -- 最新データを保存するディレクトリのリストです。全データの約10%がこのディレクトリリストに保存されます。ここにリストされているディレクトリ（またはディレクトリ）は、 [`storage.main.dir`](#dir)よりも高いIOPSメトリックを必要とします。 -- 設定されていない場合（デフォルト）、値[`storage.main.dir`](#dir)が使用されます。 +- 最新データを保存するディレクトリのリストです。全データの約10%がこのディレクトリリストに保存されます。ここにリストされているディレクトリ（またはディレクトリ）は、 [`storage.main.dir`](#dir)よりも高いIOPSメトリックを必要とします。 +- 設定されていない場合（デフォルト）、値[`storage.main.dir`](#dir)が使用されます。 ##### `capacity` {#capacity-2} -- [`storage.latest.dir`](#dir-1)内の各ディレクトリの最大ストレージ容量。設定されていない場合、または`0`倍数に設定されている場合は、実際のディスク（ディレクトリが配置されているディスク）の容量が使用されます。 +- [`storage.latest.dir`](#dir-1)内の各ディレクトリの最大ストレージ容量。設定されていない場合、または`0`倍数に設定されている場合は、実際のディスク（ディレクトリが配置されているディスク）の容量が使用されます。 @@ -118,60 +118,60 @@ I/O トラフィック制限設定を構成します。 ##### `max_bytes_per_sec` {#max_bytes_per_sec} -- ディスクの読み取りと書き込みの合計I/O帯域幅。この設定項目は、I/Oトラフィックを制限するかどうかを決定します。デフォルトでは無効になっています。TiFlashにおけるこのトラフィック制限は、ディスク帯域幅が小さく、特定のサイズに制限TiFlashれているクラウドストレージに適しています。 -- デフォルト値: `0` 。これは、I/O トラフィックがデフォルトで制限されないことを意味します。 -- 単位: バイト +- ディスクの読み取りと書き込みの合計I/O帯域幅。この設定項目は、I/Oトラフィックを制限するかどうかを決定します。デフォルトでは無効になっています。TiFlashにおけるこのトラフィック制限は、ディスク帯域幅が小さく、特定のサイズに制限TiFlashれているクラウドストレージに適しています。 +- デフォルト値: `0` 。これは、I/O トラフィックがデフォルトで制限されないことを意味します。 +- 単位: バイト ##### `max_read_bytes_per_sec` {#max_read_bytes_per_sec} -- ディスク読み取りの合計 I/O 帯域幅。 -- 設定項目`max_read_bytes_per_sec`および`max_write_bytes_per_sec` 、ディスクの読み取りと書き込みの I/O 帯域幅を個別に制限します。Google Cloud が提供する Persistent Disk など、ディスクの読み取りと書き込みの I/O 帯域幅の制限を個別に計算するクラウドストレージに使用できます。 -- `max_bytes_per_sec`の値が`0`でない場合は[`max_bytes_per_sec`](#max_bytes_per_sec)が優先されます。 -- デフォルト値: `0` +- ディスク読み取りの合計 I/O 帯域幅。 +- 設定項目`max_read_bytes_per_sec`および`max_write_bytes_per_sec` 、ディスクの読み取りと書き込みの I/O 帯域幅を個別に制限します。Google Cloud が提供する Persistent Disk など、ディスクの読み取りと書き込みの I/O 帯域幅の制限を個別に計算するクラウドストレージに使用できます。 +- `max_bytes_per_sec`の値が`0`でない場合は[`max_bytes_per_sec`](#max_bytes_per_sec)が優先されます。 +- デフォルト値: `0` ##### `max_write_bytes_per_sec` {#max_write_bytes_per_sec} -- ディスク書き込みの合計 I/O 帯域幅。 -- 設定項目`max_read_bytes_per_sec`および`max_write_bytes_per_sec` 、ディスクの読み取りと書き込みの I/O 帯域幅を個別に制限します。Google Cloud が提供する Persistent Disk など、ディスクの読み取りと書き込みの I/O 帯域幅の制限を個別に計算するクラウドストレージに使用できます。 -- `max_bytes_per_sec`の値が`0`でない場合は[`max_bytes_per_sec`](#max_bytes_per_sec)が優先されます。 -- デフォルト値: `0` +- ディスク書き込みの合計 I/O 帯域幅。 +- 設定項目`max_read_bytes_per_sec`および`max_write_bytes_per_sec` 、ディスクの読み取りと書き込みの I/O 帯域幅を個別に制限します。Google Cloud が提供する Persistent Disk など、ディスクの読み取りと書き込みの I/O 帯域幅の制限を個別に計算するクラウドストレージに使用できます。 +- `max_bytes_per_sec`の値が`0`でない場合は[`max_bytes_per_sec`](#max_bytes_per_sec)が優先されます。 +- デフォルト値: `0` ##### `foreground_write_weight` {#foreground_write_weight} -- TiFlashは内部的にI/O要求を4つのタイプに分類します。フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取りです。`foreground_write_weight`はフォアグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は`foreground_write_weight` 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 -- 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 -- デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 +- TiFlashは内部的にI/O要求を4つのタイプに分類します。フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取りです。`foreground_write_weight`はフォアグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- I/O トラフィック制限が初期化されると、 TiFlash は`foreground_write_weight` 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 +- 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 +- デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `background_write_weight` {#background_write_weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_write_weight`は、バックグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 `background_write_weight` 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 -- 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 -- デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 +- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_write_weight`は、バックグラウンド書き込みI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 `background_write_weight` 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 +- 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 +- デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `foreground_read_weight` {#foreground_read_weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`foreground_read_weight`は、フォアグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 `foreground_read_weight` 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 -- 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 -- デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 +- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`foreground_read_weight`は、フォアグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 `foreground_read_weight` 、 [`background_read_weight`](/tiflash/tiflash-configuration.md#background_read_weight)の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 +- 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 +- デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `background_read_weight` {#background_read_weight} -- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_read_weight`は、バックグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 -- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 `background_read_weight`の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 -- 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 -- デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 +- TiFlashは内部的にI/O要求を4つのタイプ（フォアグラウンド書き込み、バックグラウンド書き込み、フォアグラウンド読み取り、バックグラウンド読み取り）に分類します。`background_read_weight`は、バックグラウンド読み取りI/Oトラフィックタイプに割り当てられる帯域幅の重みを制御します。通常、これらのパラメータを調整する必要はありません。 +- I/O トラフィック制限が初期化されると、 TiFlash は[`foreground_write_weight`](/tiflash/tiflash-configuration.md#foreground_write_weight) 、 [`background_write_weight`](/tiflash/tiflash-configuration.md#background_write_weight) 、 [`foreground_read_weight`](/tiflash/tiflash-configuration.md#foreground_read_weight) 、 `background_read_weight`の比率に従って、これら 4 種類の要求に帯域幅を割り当てます。 +- 重みが`0`に設定されている場合、対応する I/O トラフィックは制限されません。 +- デフォルト値: `25` 、帯域幅の 25% の割り当てを表します。 ##### `auto_tune_sec` {#auto_tune_sec} -- TiFlashは、現在のI/O負荷に応じて、異なるI/Oタイプのトラフィック制限を自動的に調整する機能をサポートしています。調整された帯域幅が、上記で設定した重み付け比率を超える場合があります。 -- `auto_tune_sec`自動チューニングの間隔を示します。auto_tune_sec の値が`0`の場合、自動チューニングは無効になります。 -- デフォルト値: `5` -- 単位: 秒 +- TiFlashは、現在のI/O負荷に応じて、異なるI/Oタイプのトラフィック制限を自動的に調整する機能をサポートしています。調整された帯域幅が、上記で設定した重み付け比率を超える場合があります。 +- `auto_tune_sec`自動チューニングの間隔を示します。auto_tune_sec の値が`0`の場合、自動チューニングは無効になります。 +- デフォルト値: `5` +- 単位: 秒 #### storage.s3 {#storages3} @@ -179,118 +179,118 @@ I/O トラフィック制限設定を構成します。 ##### `endpoint` {#endpoint} -- S3エンドポイントアドレス。例: `http://s3.{region}.amazonaws.com` 。 +- S3エンドポイントアドレス。例: `http://s3.{region}.amazonaws.com` 。 ##### `bucket` {#bucket} -- TiFlash はすべてのデータをこのバケットに保存します。 +- TiFlash はすべてのデータをこのバケットに保存します。 ##### `root` {#root} -- S3 バケット内でデータが保存されるルートディレクトリ。例: `/cluster1_data` 。 +- S3 バケット内でデータが保存されるルートディレクトリ。例: `/cluster1_data` 。 ##### `access_key_id` {#access_key_id} -- S3 にアクセスするために使用される ACCESS_KEY_ID。 +- S3 にアクセスするために使用される ACCESS_KEY_ID。 ##### `secret_access_key` {#secret_access_key} -- S3 にアクセスするために使用される SECRET_ACCESS_KEY。 +- S3 にアクセスするために使用される SECRET_ACCESS_KEY。 #### storage.remote.cache {#storageremotecache} ##### `dir` {#dir} -- 分散ストレージおよびコンピューティングアーキテクチャ内のコンピューティング ノードのローカル データ キャッシュ ディレクトリ。 +- 分散ストレージおよびコンピューティングアーキテクチャ内のコンピューティング ノードのローカル データ キャッシュ ディレクトリ。 ##### `capacity` {#capacity} -- 例: `858993459200` (800 GiB) +- 例: `858993459200` (800 GiB) #### フラッシュ {#flash} ##### `service_addr` {#service_addr} -- TiFlashコプロセッサ サービスのリスニング アドレス。 +- TiFlashコプロセッサ サービスのリスニング アドレス。 ##### `compact_log_min_gap` v7.4.0 の新機能 {#compact_log_min_gap-new-in-v740} -- 現在のRaftステート マシンによって進められた`applied_index`と最後のディスク スピル時の`applied_index`との差が`compact_log_min_gap`超えると、 TiFlash はTiKV から`CompactLog`コマンドを実行し、データをディスクにスピルします。 -- このギャップを大きくすると、 TiFlashのディスク書き込み頻度が低下し、ランダム書き込みシナリオにおける読み取りレイテンシーが短縮される可能性がありますが、メモリオーバーヘッドも増加する可能性があります。このギャップを小さくすると、 TiFlashのディスク書き込み頻度が増加し、 TiFlashのメモリ負荷が軽減される可能性があります。ただし、現段階では、このギャップを`0`に設定しても、 TiFlashのディスク書き込み頻度は TiKV よりも高くなることはありません。 -- デフォルト値を維持することをお勧めします。 -- デフォルト値: `200` +- 現在のRaftステート マシンによって進められた`applied_index`と最後のディスク スピル時の`applied_index`との差が`compact_log_min_gap`超えると、 TiFlash はTiKV から`CompactLog`コマンドを実行し、データをディスクにスピルします。 +- このギャップを大きくすると、 TiFlashのディスク書き込み頻度が低下し、ランダム書き込みシナリオにおける読み取りレイテンシーが短縮される可能性がありますが、メモリオーバーヘッドも増加する可能性があります。このギャップを小さくすると、 TiFlashのディスク書き込み頻度が増加し、 TiFlashのメモリ負荷が軽減される可能性があります。ただし、現段階では、このギャップを`0`に設定しても、 TiFlashのディスク書き込み頻度は TiKV よりも高くなることはありません。 +- デフォルト値を維持することをお勧めします。 +- デフォルト値: `200` ##### `compact_log_min_rows`バージョン5.0の新機能 {#compact_log_min_rows-new-in-v50} -- TiFlashによってキャッシュされたリージョン内の行の数またはサイズが`compact_log_min_rows`または`compact_log_min_bytes`超えると、 TiFlash はTiKV から`CompactLog`コマンドを実行し、データをディスクに書き込みます。 -- デフォルト値を維持することをお勧めします。 -- デフォルト値: `40960` +- TiFlashによってキャッシュされたリージョン内の行の数またはサイズが`compact_log_min_rows`または`compact_log_min_bytes`超えると、 TiFlash はTiKV から`CompactLog`コマンドを実行し、データをディスクに書き込みます。 +- デフォルト値を維持することをお勧めします。 +- デフォルト値: `40960` ##### `compact_log_min_bytes`バージョン5.0の新機能 {#compact_log_min_bytes-new-in-v50} -- TiFlashによってキャッシュされたリージョン内の行の数またはサイズが`compact_log_min_rows`または`compact_log_min_bytes`超えると、 TiFlash はTiKV から`CompactLog`コマンドを実行し、データをディスクに書き込みます。 -- デフォルト値を維持することをお勧めします。 -- デフォルト値: `33554432` +- TiFlashによってキャッシュされたリージョン内の行の数またはサイズが`compact_log_min_rows`または`compact_log_min_bytes`超えると、 TiFlash はTiKV から`CompactLog`コマンドを実行し、データをディスクに書き込みます。 +- デフォルト値を維持することをお勧めします。 +- デフォルト値: `33554432` ##### `disaggregated_mode` {#disaggregated_mode} -- この設定項目は、 TiFlash分散ストレージおよびコンピューティングアーキテクチャモードにのみ適用されます。詳細については、 [TiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 サポート](/tiflash/tiflash-disaggregated-and-s3.md)を参照してください。 -- 値`"tiflash_compute"`オプション: `"tiflash_write"` +- この設定項目は、 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} -- TiFlashサーバーをシャットダウンする際の最大待機時間を制御します。この期間中、 TiFlash は未完了の MPP タスクの実行を継続しますが、新しいタスクは受け付けません。実行中のすべての MPP タスクがこのタイムアウト前に終了した場合、 TiFlash は直ちにシャットダウンします。それ以外の場合は、待機時間が経過した後に強制的にシャットダウンされます。 -- デフォルト値: `600` -- 単位: 秒 -- TiFlashサーバーがシャットダウンを待機している間 (猶予期間中)、TiDB は新しい MPP タスクをサーバーに送信しません。 +- TiFlashサーバーをシャットダウンする際の最大待機時間を制御します。この期間中、 TiFlash は未完了の MPP タスクの実行を継続しますが、新しいタスクは受け付けません。実行中のすべての MPP タスクがこのタイムアウト前に終了した場合、 TiFlash は直ちにシャットダウンします。それ以外の場合は、待機時間が経過した後に強制的にシャットダウンされます。 +- デフォルト値: `600` +- 単位: 秒 +- TiFlashサーバーがシャットダウンを待機している間 (猶予期間中)、TiDB は新しい MPP タスクをサーバーに送信しません。 #### フラッシュプロキシ {#flashproxy} ##### `addr` {#addr} -- プロキシのリスニング アドレス。 -- デフォルト値: `"127.0.0.1:20170"` +- プロキシのリスニング アドレス。 +- デフォルト値: `"127.0.0.1:20170"` ##### `advertise-addr` {#advertise-addr} -- 外部アクセスアドレス`addr` 。空のままにした場合、デフォルトで`addr`が使用されます。 -- クラスターを複数のノードに展開する場合は、他のノードが`advertise-addr`を介してアクセスできることを保証する必要があります。 +- 外部アクセスアドレス`addr` 。空のままにした場合、デフォルトで`addr`が使用されます。 +- クラスターを複数のノードに展開する場合は、他のノードが`advertise-addr`を介してアクセスできることを保証する必要があります。 ##### `status-addr` {#status-addr} -- プロキシがメトリックまたはステータス情報を取得するリスニング アドレス。 -- デフォルト値: `"127.0.0.1:20292"` +- プロキシがメトリックまたはステータス情報を取得するリスニング アドレス。 +- デフォルト値: `"127.0.0.1:20292"` ##### `advertise-status-addr` {#advertise-status-addr} -- status-addrの外部アクセスアドレス。空のままにした場合、デフォルトで`status-addr`が使用されます。 -- クラスターを複数のノードに展開する場合は、他のノードが`advertise-status-addr`を介してアクセスできることを保証する必要があります。 +- status-addrの外部アクセスアドレス。空のままにした場合、デフォルトで`status-addr`が使用されます。 +- クラスターを複数のノードに展開する場合は、他のノードが`advertise-status-addr`を介してアクセスできることを保証する必要があります。 ##### `engine-addr` {#engine-addr} -- TiFlashコプロセッサ サービスの外部アクセス アドレス。 +- TiFlashコプロセッサ サービスの外部アクセス アドレス。 ##### `data-dir` {#data-dir} -- プロキシのデータストレージパス。 +- プロキシのデータストレージパス。 ##### `config` {#config} -- プロキシの構成ファイル パス。 +- プロキシの構成ファイル パス。 ##### `log-file` {#log-file} -- プロキシのログ パス。 +- プロキシのログ パス。 @@ -300,162 +300,162 @@ I/O トラフィック制限設定を構成します。 ##### `level` {#level} -- ログ レベル。 -- デフォルト値: `"info"` -- `"info"` `"debug"` `"error"` `"warn"` `"trace"` +- ログ レベル。 +- デフォルト値: `"info"` +- `"info"` `"debug"` `"error"` `"warn"` `"trace"` ##### `log` {#log} -- TiFlashのログです。 +- TiFlashのログです。 ##### `errorlog` {#errorlog} -- TiFlashのエラーログ。レベル`"warn"`とレベル`"error"`ログもこのログファイルに出力されます。 +- TiFlashのエラーログ。レベル`"warn"`とレベル`"error"`ログもこのログファイルに出力されます。 ##### `size` {#size} -- 1 つのログ ファイルのサイズ。 -- デフォルト値: `"100M"` +- 1 つのログ ファイルのサイズ。 +- デフォルト値: `"100M"` ##### `count` {#count} -- 保存できるログファイルの最大数。TiFlashとTiFlashエラーログの場合、保存できるログファイルの最大数はそれぞれ`count`です。 -- デフォルト値: `10` +- 保存できるログファイルの最大数。TiFlashとTiFlashエラーログの場合、保存できるログファイルの最大数はそれぞれ`count`です。 +- デフォルト値: `10` #### ラフト {#raft} ##### `pd_addr` {#pd_addr} -- PD サービス アドレス。 -- 複数のアドレスはカンマで区切られます。例： `"10.0.1.11:2379,10.0.1.12:2379,10.0.1.13:2379"` 。 +- PD サービス アドレス。 +- 複数のアドレスはカンマで区切られます。例： `"10.0.1.11:2379,10.0.1.12:2379,10.0.1.13:2379"` 。 #### 状態 {#status} ##### `metrics_port` {#metrics_port} -- Prometheus がメトリック情報を取得するポート。 -- デフォルト値: `8234` +- Prometheus がメトリック情報を取得するポート。 +- デフォルト値: `8234` #### プロファイル.デフォルト {#profilesdefault} ##### `dt_enable_logical_split` {#dt_enable_logical_split} -- DeltaTreeストレージエンジンのセグメントで論理分割を使用するかどうかを指定します。論理分割を使用すると書き込み増幅を削減できますが、ディスク領域の無駄が発生します。 -- v6.2.0以降のバージョンでは、デフォルト値の`false`を維持し、 `true`に変更しないことを強くお勧めします。詳細については、既知の問題[＃5576](https://github.com/pingcap/tiflash/issues/5576)を参照してください。 -- デフォルト値: `false` +- DeltaTreeストレージエンジンのセグメントで論理分割を使用するかどうかを指定します。論理分割を使用すると書き込み増幅を削減できますが、ディスク領域の無駄が発生します。 +- v6.2.0以降のバージョンでは、デフォルト値の`false`を維持し、 `true`に変更しないことを強くお勧めします。詳細については、既知の問題[＃5576](https://github.com/pingcap/tiflash/issues/5576)を参照してください。 +- デフォルト値: `false` ##### `max_threads` {#max_threads} -- `max_threads`は、 TiFlash がMPP タスクを実行する際の内部スレッド同時実行数を示します。`0`に設定すると、 TiFlash は論理 CPU コアの数を同時実行数として使用します。 -- このパラメータは、システム変数[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610) `-1`に設定されている場合にのみ有効になります。 -- デフォルト値: `0` +- `max_threads`は、 TiFlash がMPP タスクを実行する際の内部スレッド同時実行数を示します。`0`に設定すると、 TiFlash は論理 CPU コアの数を同時実行数として使用します。 +- このパラメータは、システム変数[`tidb_max_tiflash_threads`](/system-variables.md#tidb_max_tiflash_threads-new-in-v610) `-1`に設定されている場合にのみ有効になります。 +- デフォルト値: `0` ##### `max_memory_usage` {#max_memory_usage} -- 単一のクエリで生成される中間データのメモリ使用量の制限。 -- 値が整数の場合、単位はバイトです。例えば、 `34359738368` 32GiBのメモリ制限を意味します。 -- 値が`[0.0, 1.0)`の範囲の浮動小数点数の場合、ノードの総メモリに対する許容メモリ使用量の比率を表します。例えば、 `0.8`総メモリの 80% を意味し、 `0.0`無制限を意味します。 -- クエリがこの制限を超えるメモリを消費しようとすると、クエリは終了され、エラーが報告されます。 -- デフォルト値: `0` 、制限がないことを意味します。 +- 単一のクエリで生成される中間データのメモリ使用量の制限。 +- 値が整数の場合、単位はバイトです。例えば、 `34359738368` 32GiBのメモリ制限を意味します。 +- 値が`[0.0, 1.0)`の範囲の浮動小数点数の場合、ノードの総メモリに対する許容メモリ使用量の比率を表します。例えば、 `0.8`総メモリの 80% を意味し、 `0.0`無制限を意味します。 +- クエリがこの制限を超えるメモリを消費しようとすると、クエリは終了され、エラーが報告されます。 +- デフォルト値: `0` 、制限がないことを意味します。 ##### `max_memory_usage_for_all_queries` {#max_memory_usage_for_all_queries} -- すべてのクエリで生成される中間データのメモリ使用量制限。 -- 値が整数の場合、単位はバイトです。例えば、 `34359738368` 32GiBのメモリ制限を意味し、 `0`制限なしを意味します。 -- v6.6.0以降では、 `[0.0, 1.0)`の範囲の浮動小数点数で値を設定できます。この数値は、許容されるメモリ使用量とノード全体のメモリ使用量の比率を表します。例えば、 `0.8`メモリの80%、 `0.0`無制限を意味します。 -- クエリがこの制限を超えるメモリを消費しようとすると、クエリは終了され、エラーが報告されます。 -- デフォルト値： `0.8` （総メモリの80%を意味します）。v6.6.0より前のバージョンでは、デフォルト値は`0` （無制限を意味します）でした。 +- すべてのクエリで生成される中間データのメモリ使用量制限。 +- 値が整数の場合、単位はバイトです。例えば、 `34359738368` 32GiBのメモリ制限を意味し、 `0`制限なしを意味します。 +- v6.6.0以降では、 `[0.0, 1.0)`の範囲の浮動小数点数で値を設定できます。この数値は、許容されるメモリ使用量とノード全体のメモリ使用量の比率を表します。例えば、 `0.8`メモリの80%、 `0.0`無制限を意味します。 +- クエリがこの制限を超えるメモリを消費しようとすると、クエリは終了され、エラーが報告されます。 +- デフォルト値： `0.8` （総メモリの80%を意味します）。v6.6.0より前のバージョンでは、デフォルト値は`0` （無制限を意味します）でした。 ##### `cop_pool_size`バージョン5.0の新機能 {#cop_pool_size-new-in-v50} -- TiFlashコプロセッサーが同時に実行できるcopリクエストの最大数を指定します。リクエスト数がこの値を超えても、10倍以内の場合、超過したリクエストはキューに入れられます。リクエスト数がこの値の10倍を超える場合、超過したリクエストはTiFlashによって拒否されます。設定値が`0`に設定されている場合、または設定されていない場合は、デフォルト値（物理コア数の2倍）が使用されます。 -- デフォルト値: 物理コア数の2倍 +- TiFlashコプロセッサーが同時に実行できるcopリクエストの最大数を指定します。リクエスト数がこの値を超えても、10倍以内の場合、超過したリクエストはキューに入れられます。リクエスト数がこの値の10倍を超える場合、超過したリクエストはTiFlashによって拒否されます。設定値が`0`に設定されている場合、または設定されていない場合は、デフォルト値（物理コア数の2倍）が使用されます。 +- デフォルト値: 物理コア数の2倍 ##### `cop_pool_handle_limit`バージョン5.0の新機能 {#cop_pool_handle_limit-new-in-v50} -- TiFlashコプロセッサーが同時に処理できるCOPリクエストの最大数を指定します。これには、実行中のリクエストとキューで待機中のリクエストが含まれます。リクエスト数が指定値を超えると、エラー`TiFlash Server is Busy`が返されます。 -- `-1`制限がないことを示し、 `0`デフォルト値の`10 * cop_pool_size`を使用することを示します。 +- TiFlashコプロセッサーが同時に処理できるCOPリクエストの最大数を指定します。これには、実行中のリクエストとキューで待機中のリクエストが含まれます。リクエスト数が指定値を超えると、エラー`TiFlash Server is Busy`が返されます。 +- `-1`制限がないことを示し、 `0`デフォルト値の`10 * cop_pool_size`を使用することを示します。 ##### `cop_pool_max_queued_seconds`バージョン5.0の新機能 {#cop_pool_max_queued_seconds-new-in-v50} -- cop要求がTiFlashにキューイングできる最大時間を指定します。cop要求がこの設定で指定された値よりも長くキュー内で待機した場合、エラー`TiFlash Server is Busy`が返されます。 -- `0`以下の値は制限がないことを示します。 -- デフォルト値: `15` +- cop要求がTiFlashにキューイングできる最大時間を指定します。cop要求がこの設定で指定された値よりも長くキュー内で待機した場合、エラー`TiFlash Server is Busy`が返されます。 +- `0`以下の値は制限がないことを示します。 +- デフォルト値: `15` ##### `batch_cop_pool_size`バージョン5.0の新機能 {#batch_cop_pool_size-new-in-v50} -- TiFlashコプロセッサーが同時に実行するバッチリクエストの最大数を指定します。リクエスト数が指定値を超えた場合、超過分のリクエストはキューに入れられます。設定値が`0`に設定されているか未設定の場合は、デフォルト値（物理コア数の2倍）が使用されます。 -- デフォルト値: 物理コア数の2倍 +- TiFlashコプロセッサーが同時に実行するバッチリクエストの最大数を指定します。リクエスト数が指定値を超えた場合、超過分のリクエストはキューに入れられます。設定値が`0`に設定されているか未設定の場合は、デフォルト値（物理コア数の2倍）が使用されます。 +- デフォルト値: 物理コア数の2倍 ##### `manual_compact_pool_size`バージョン6.1の新機能 {#manual_compact_pool_size-new-in-v61} -- TiFlash がTiDB から`ALTER TABLE ... COMPACT`受信したときに同時に処理できる要求の数を指定します。 -- 値が`0`に設定されている場合、デフォルト値`1`が優先されます。 -- デフォルト値: `1` +- TiFlash がTiDB から`ALTER TABLE ... COMPACT`受信したときに同時に処理できる要求の数を指定します。 +- 値が`0`に設定されている場合、デフォルト値`1`が優先されます。 +- デフォルト値: `1` ##### `enable_elastic_threadpool`バージョン5.4.0の新機能 {#enable_elastic_threadpool-new-in-v540} -- エラスティック スレッド プール機能を有効にするかどうかを制御します。この機能により、 TiFlashの同時実行性の高いシナリオで CPU 使用率が大幅に向上します。 -- デフォルト値: `true` +- エラスティック スレッド プール機能を有効にするかどうかを制御します。この機能により、 TiFlashの同時実行性の高いシナリオで CPU 使用率が大幅に向上します。 +- デフォルト値: `true` ##### `dt_compression_method` {#dt_compression_method} -- TiFlashストレージエンジンの圧縮アルゴリズム。 -- デフォルト値: `LZ4` -- 値のオプション: `LZ4` 、 `zstd` 、 `LZ4HC` 。値は大文字と小文字を区別しません。 +- TiFlashストレージエンジンの圧縮アルゴリズム。 +- デフォルト値: `LZ4` +- 値のオプション: `LZ4` 、 `zstd` 、 `LZ4HC` 。値は大文字と小文字を区別しません。 ##### `dt_compression_level` {#dt_compression_level} -- TiFlashストレージエンジンの圧縮レベル。 -- `dt_compression_method`が`LZ4`の場合は、この値を`1`に設定することをお勧めします。 -- この値は`-1` (圧縮率は低くなりますが、読み取りパフォーマンスは向上します) に設定するか、 `dt_compression_method`が`zstd`の場合は`1`に設定することをお勧めします。 -- `dt_compression_method`が`LZ4HC`の場合は、この値を`9`に設定することをお勧めします。 -- デフォルト値: `1` +- TiFlashストレージエンジンの圧縮レベル。 +- `dt_compression_method`が`LZ4`の場合は、この値を`1`に設定することをお勧めします。 +- この値は`-1` (圧縮率は低くなりますが、読み取りパフォーマンスは向上します) に設定するか、 `dt_compression_method`が`zstd`の場合は`1`に設定することをお勧めします。 +- `dt_compression_method`が`LZ4HC`の場合は、この値を`9`に設定することをお勧めします。 +- デフォルト値: `1` ##### `dt_page_gc_threshold` v6.2.0 の新機能 {#dt_page_gc_threshold-new-in-v620} -- PageStorageデータファイル内の有効データの最小比率を指定します。PageStorageデータファイル内の有効データの比率がこの設定値を下回ると、GCがトリガーされ、ファイル内のデータが圧縮されます。 -- デフォルト値: `0.5` +- PageStorageデータファイル内の有効データの最小比率を指定します。PageStorageデータファイル内の有効データの比率がこの設定値を下回ると、GCがトリガーされ、ファイル内のデータが圧縮されます。 +- デフォルト値: `0.5` ##### `max_bytes_before_external_group_by` v7.0.0 の新機能 {#max_bytes_before_external_group_by-new-in-v700} -- ハッシュ集計演算子（キー`GROUP BY`で使用可能な最大メモリを指定します。この値を超えるとディスクへの書き込みがトリガーされます。メモリ使用量がしきい値を超えると、ハッシュ集計はメモリ使用量を[ディスクへのスピル](/tiflash/tiflash-spill-disk.md)削減します。 -- デフォルト値: `0` 。これは、メモリ使用量が無制限であり、ハッシュ集計にディスクへのスピルが使用されないことを意味します。 +- ハッシュ集計演算子（キー`GROUP BY`で使用可能な最大メモリを指定します。この値を超えるとディスクへの書き込みがトリガーされます。メモリ使用量がしきい値を超えると、ハッシュ集計はメモリ使用量を[ディスクへのスピル](/tiflash/tiflash-spill-disk.md)削減します。 +- デフォルト値: `0` 。これは、メモリ使用量が無制限であり、ハッシュ集計にディスクへのスピルが使用されないことを意味します。 ##### `max_bytes_before_external_sort`バージョン7.0.0の新機能 {#max_bytes_before_external_sort-new-in-v700} -- ソート演算子またはtopN演算子で使用可能な最大メモリを指定します。この値を超えるとディスクへの書き込みがトリガーされます。メモリ使用量がこのしきい値を超えると、ソート演算子またはtopN演算子はメモリ使用量を[ディスクへのスピル](/tiflash/tiflash-spill-disk.md)ずつ減らします。 -- デフォルト値: `0` 。これは、メモリ使用量が無制限であり、ソートや topN にディスクへのスピルが使用されないことを意味します。 +- ソート演算子またはtopN演算子で使用可能な最大メモリを指定します。この値を超えるとディスクへの書き込みがトリガーされます。メモリ使用量がこのしきい値を超えると、ソート演算子またはtopN演算子はメモリ使用量を[ディスクへのスピル](/tiflash/tiflash-spill-disk.md)ずつ減らします。 +- デフォルト値: `0` 。これは、メモリ使用量が無制限であり、ソートや topN にディスクへのスピルが使用されないことを意味します。 ##### `max_bytes_before_external_join`バージョン7.0.0の新機能 {#max_bytes_before_external_join-new-in-v700} -- 等価結合条件を持つハッシュ結合演算子で使用可能な最大メモリを指定します。この値を超えるとディスクへの書き込みがトリガーされます。メモリ使用量がしきい値を超えると、HashJoin はメモリ使用量を[ディスクへのスピル](/tiflash/tiflash-spill-disk.md)減らします。 -- デフォルト値: `0` 。これは、メモリ使用量が無制限であり、等価結合条件によるハッシュ結合ではディスクへのスピルが使用されないことを意味します。 +- 等価結合条件を持つハッシュ結合演算子で使用可能な最大メモリを指定します。この値を超えるとディスクへの書き込みがトリガーされます。メモリ使用量がしきい値を超えると、HashJoin はメモリ使用量を[ディスクへのスピル](/tiflash/tiflash-spill-disk.md)減らします。 +- デフォルト値: `0` 。これは、メモリ使用量が無制限であり、等価結合条件によるハッシュ結合ではディスクへのスピルが使用されないことを意味します。 ##### `enable_resource_control`バージョン7.4.0の新機能 {#enable_resource_control-new-in-v740} -- TiFlashリソース制御機能を有効にするかどうかを制御します。`true`に設定すると、 TiFlashは[パイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)を使用します。 -- デフォルト値: `true` -- 値`false`オプション: `true` +- TiFlashリソース制御機能を有効にするかどうかを制御します。`true`に設定すると、 TiFlashは[パイプライン実行モデル](/tiflash/tiflash-pipeline-model.md)を使用します。 +- デフォルト値: `true` +- 値`false`オプション: `true` ##### `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)を参照してください。 -- デフォルト値: `5000` +- この項目は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)を参照してください。 -- デフォルト値: `10000` +- この項目は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)を参照してください。 -- デフォルト値: バージョン7.4.0より前のバージョンでは、デフォルト値は`vcpu * 0.25`で、これはvCPU数の4分の1を意味します。バージョン7.4.0以降では、デフォルト値は`vcpu * 2`で、これはvCPU数の2倍を意味します。 +- この項目は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-new-in-v405} @@ -463,29 +463,29 @@ I/O トラフィック制限設定を構成します。 ##### `redact_info_log`バージョン5.0の新機能 {#redact_info_log-new-in-v50} -- ログの秘匿化を有効にするかどうかを制御します。 -- デフォルト値: `false` -- 値のオプション: `true` 、 `false` 、 `"on"` 、 `"off"` 、および`"marker"` 。 `"on"` 、 `"off"` 、および`"marker"`オプションは、v8.2.0 で導入されました。 -- 構成項目が`false`または`"off"`に設定されている場合、ログの秘匿化は無効になります。 -- 構成項目が`true`または`"on"`に設定されている場合、ログ内のすべてのユーザー データは`?`に置き換えられます。 -- 設定項目を`"marker"`に設定すると、ログ内のすべてのユーザーデータは`‹ ›`で囲まれます。ユーザーデータに`‹`または`›`が含まれている場合、 `‹`は`‹‹`に、 `›`は`››`にエスケープされます。マークされたログに基づいて、ログを表示する際にマークされた情報を非感度化するかどうかを決定できます。 -- [`tiflash-learner.toml`](#configure-the-tiflash-learnertoml-file)での tiflash-learner のログインにも`security.redact-info-log`設定する必要があることに注意してください。 +- ログの秘匿化を有効にするかどうかを制御します。 +- デフォルト値: `false` +- 値のオプション: `true` 、 `false` 、 `"on"` 、 `"off"` 、および`"marker"` 。 `"on"` 、 `"off"` 、および`"marker"`オプションは、v8.2.0 で導入されました。 +- 構成項目が`false`または`"off"`に設定されている場合、ログの秘匿化は無効になります。 +- 構成項目が`true`または`"on"`に設定されている場合、ログ内のすべてのユーザー データは`?`に置き換えられます。 +- 設定項目を`"marker"`に設定すると、ログ内のすべてのユーザーデータは`‹ ›`で囲まれます。ユーザーデータに`‹`または`›`が含まれている場合、 `‹`は`‹‹`に、 `›`は`››`にエスケープされます。マークされたログに基づいて、ログを表示する際にマークされた情報を非感度化するかどうかを決定できます。 +- [`tiflash-learner.toml`](#configure-the-tiflash-learnertoml-file)での tiflash-learner のログインにも`security.redact-info-log`設定する必要があることに注意してください。 ##### `ca_path` {#ca_path} -- 信頼できるSSL CAのリストを含むファイルのパス。設定する場合は、 [`cert_path`](#cert_path)と[`key_path`](#key_path)必要です。 +- 信頼できるSSL CAのリストを含むファイルのパス。設定する場合は、 [`cert_path`](#cert_path)と[`key_path`](#key_path)必要です。 ##### `cert_path` {#cert_path} -- PEM 形式の X509 証明書が含まれるファイルのパス。 +- PEM 形式の X509 証明書が含まれるファイルのパス。 ##### `key_path` {#key_path} -- PEM 形式の X509 キーを含むファイルのパス。 +- PEM 形式の X509 キーを含むファイルのパス。 @@ -493,90 +493,90 @@ I/O トラフィック制限設定を構成します。 `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`は予約されており、手動で設定することはできません。 +- TiKV と比較して、 TiFlash Proxy には[`raftstore.snap-handle-pool-size`](#snap-handle-pool-size-new-in-v400)追加パラメーターがあります。 +- キーが`engine`の`label`は予約されており、手動で設定することはできません。 #### ログ {#log-1} ##### `level` v5.4.0 の新機能 {#level-new-in-v540} -- TiFlash Proxy のログ レベル。 -- デフォルト値: `"info"` -- `"info"` `"debug"` `"error"` `"warn"` `"trace"` +- TiFlash Proxy のログ レベル。 +- デフォルト値: `"info"` +- `"info"` `"debug"` `"error"` `"warn"` `"trace"` #### ログファイル {#logfile} ##### `max-backups` 5.4.0の新機能 {#max-backups-new-in-v540} -- 保存するログ ファイルの最大数。 -- このパラメータが設定されていないか、デフォルト値`0`に設定されている場合、 TiFlash Proxy はすべてのログ ファイルを保存します。 -- このパラメータを0以外の値に設定すると、 TiFlash Proxyは最大で`max-backups`で指定された数の古いログファイルを保持します。例えば、 `7`に設定すると、 TiFlash Proxyは最大で7つの古いログファイルを保持します。 -- デフォルト値: `0` +- 保存するログ ファイルの最大数。 +- このパラメータが設定されていないか、デフォルト値`0`に設定されている場合、 TiFlash Proxy はすべてのログ ファイルを保存します。 +- このパラメータを0以外の値に設定すると、 TiFlash Proxyは最大で`max-backups`で指定された数の古いログファイルを保持します。例えば、 `7`に設定すると、 TiFlash Proxyは最大で7つの古いログファイルを保持します。 +- デフォルト値: `0` ##### `max-days` v5.4.0 の新機能 {#max-days-new-in-v540} -- ログ ファイルが保持される最大日数。 -- このパラメータが設定されていないか、デフォルト値`0`に設定されている場合、 TiFlash Proxy はすべてのログ ファイルを保持します。 -- このパラメータがゼロ以外の値に設定されている場合、 TiFlash Proxy は`max-days`で指定された日数後に古いログ ファイルをクリーンアップします。 -- デフォルト値: `0` +- ログ ファイルが保持される最大日数。 +- このパラメータが設定されていないか、デフォルト値`0`に設定されている場合、 TiFlash Proxy はすべてのログ ファイルを保持します。 +- このパラメータがゼロ以外の値に設定されている場合、 TiFlash Proxy は`max-days`で指定された日数後に古いログ ファイルをクリーンアップします。 +- デフォルト値: `0` #### ラフトストア {#raftstore} ##### `apply-pool-size` {#apply-pool-size} -- Raftデータをストレージにフラッシュするプール内の許容スレッド数。 +- Raftデータをストレージにフラッシュするプール内の許容スレッド数。 ##### `store-pool-size` {#store-pool-size} -- Raft を処理するスレッドの許容数。これはRaftstoreスレッド プールのサイズです。 +- Raft を処理するスレッドの許容数。これはRaftstoreスレッド プールのサイズです。 ##### `snap-handle-pool-size` v4.0.0 の新機能 {#snap-handle-pool-size-new-in-v400} -- スナップショットを処理するスレッドの数。`0`に設定すると、マルチスレッド最適化は無効になります。 -- デフォルト値: `2` +- スナップショットを処理するスレッドの数。`0`に設定すると、マルチスレッド最適化は無効になります。 +- デフォルト値: `2` #### 安全 {#security} ##### `redact-info-log`バージョン5.0の新機能 {#redact-info-log-new-in-v50} -- ログの秘匿化を有効にするかどうかを制御します。 -- デフォルト値: `false` -- 値のオプション: `true` 、 `false` 、 `"on"` 、 `"off"` 、および`"marker"` 。 `"on"` 、 `"off"` 、および`"marker"`オプションは、v8.3.0 で導入されました。 -- 構成項目が`false`または`"off"`に設定されている場合、ログの秘匿化は無効になります。 -- 構成項目が`true`または`"on"`に設定されている場合、ログ内のすべてのユーザー データは`?`に置き換えられます。 -- 設定項目を`"marker"`に設定すると、ログ内のすべてのユーザーデータは`‹ ›`で囲まれます。ユーザーデータに`‹`または`›`が含まれている場合、 `‹`は`‹‹`に、 `›`は`››`にエスケープされます。マークされたログに基づいて、ログを表示する際にマークされた情報を非感度化するかどうかを決定できます。 +- ログの秘匿化を有効にするかどうかを制御します。 +- デフォルト値: `false` +- 値のオプション: `true` 、 `false` 、 `"on"` 、 `"off"` 、および`"marker"` 。 `"on"` 、 `"off"` 、および`"marker"`オプションは、v8.3.0 で導入されました。 +- 構成項目が`false`または`"off"`に設定されている場合、ログの秘匿化は無効になります。 +- 構成項目が`true`または`"on"`に設定されている場合、ログ内のすべてのユーザー データは`?`に置き換えられます。 +- 設定項目を`"marker"`に設定すると、ログ内のすべてのユーザーデータは`‹ ›`で囲まれます。ユーザーデータに`‹`または`›`が含まれている場合、 `‹`は`‹‹`に、 `›`は`››`にエスケープされます。マークされたログに基づいて、ログを表示する際にマークされた情報を非感度化するかどうかを決定できます。 #### セキュリティ.暗号化 {#securityencryption} ##### `data-encryption-method` {#data-encryption-method} -- データファイルの暗号化方法。`"plaintext"`以外の値は暗号化が有効であることを意味します。その場合はマスターキーを指定する必要があります。 -- デフォルト値: `"plaintext"` 。これは、暗号化がデフォルトで無効になっていることを意味します。 -- `"aes256-ctr"` `"aes192-ctr"`オプション: `"aes128-ctr"` `"sm4-ctr"` `"plaintext"`で導入`"sm4-ctr"`れました。 +- データファイルの暗号化方法。`"plaintext"`以外の値は暗号化が有効であることを意味します。その場合はマスターキーを指定する必要があります。 +- デフォルト値: `"plaintext"` 。これは、暗号化がデフォルトで無効になっていることを意味します。 +- `"aes256-ctr"` `"aes192-ctr"`オプション: `"aes128-ctr"` `"sm4-ctr"` `"plaintext"`で導入`"sm4-ctr"`れました。 ##### `data-key-rotation-period` {#data-key-rotation-period} -- データ暗号化キーをローテーションする頻度を指定します。 -- デフォルト値: `7d` +- データ暗号化キーをローテーションする頻度を指定します。 +- デフォルト値: `7d` #### セキュリティ.暗号化.マスターキー {#securityencryptionmaster-key} -- 暗号化が有効になっている場合、マスターキーを指定します。マスターキーの設定方法については、 [暗号化を設定する](/encryption-at-rest.md#configure-encryption)を参照してください。 +- 暗号化が有効になっている場合、マスターキーを指定します。マスターキーの設定方法については、 [暗号化を設定する](/encryption-at-rest.md#configure-encryption)を参照してください。 #### セキュリティ.暗号化.以前のマスターキー {#securityencryptionprevious-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} diff --git a/tiflash/tiflash-data-validation.md b/tiflash/tiflash-data-validation.md index 96901b5736778..070166b5ada7a 100644 --- a/tiflash/tiflash-data-validation.md +++ b/tiflash/tiflash-data-validation.md @@ -29,11 +29,11 @@ DTFileはデータファイルディレクトリの`stable`フォルダに保存 TiFlash は自動と手動の両方のデータ検証をサポートしています。 -- 自動データ検証: - - v6.0.0 以降のバージョンでは、デフォルトで V3 検証メカニズムが使用されます。 - - v6.0.0 より前のバージョンでは、デフォルトで V2 検証メカニズムが使用されます。 - - 検証メカニズムを手動で切り替えるには、 [TiFlash設定ファイル](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file)を参照してください。ただし、デフォルト設定はテストによって検証されているため、推奨されます。 -- 手動データ検証[`DTTool inspect`](/tiflash/tiflash-command-line-flags.md#dttool-inspect)を参照してください。 +- 自動データ検証: + - v6.0.0 以降のバージョンでは、デフォルトで V3 検証メカニズムが使用されます。 + - v6.0.0 より前のバージョンでは、デフォルトで V2 検証メカニズムが使用されます。 + - 検証メカニズムを手動で切り替えるには、 [TiFlash設定ファイル](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file)を参照してください。ただし、デフォルト設定はテストによって検証されているため、推奨されます。 +- 手動データ検証[`DTTool inspect`](/tiflash/tiflash-command-line-flags.md#dttool-inspect)を参照してください。 > **Warning:** > diff --git a/tiflash/tiflash-disaggregated-and-s3.md b/tiflash/tiflash-disaggregated-and-s3.md index 833eda0156cfd..838445624708c 100644 --- a/tiflash/tiflash-disaggregated-and-s3.md +++ b/tiflash/tiflash-disaggregated-and-s3.md @@ -13,13 +13,13 @@ summary: TiFlash の分散ストレージとコンピューティングアーキ 分散型ストレージおよびコンピューティングアーキテクチャでは、 TiFlashプロセスの異なる機能が分割され、書き込みノードとコンピューティングノードという2種類のノードに割り当てられます。これらの2種類のノードは個別に導入および拡張できるため、必要に応じて導入する書き込みノードとコンピューティングノードの数を決定できます。 -- TiFlash書き込みノード +- TiFlash書き込みノード 書き込みノードは、TiKVからRaftログデータを受け取り、列指向形式に変換し、一定期間内に更新されたすべてのデータを定期的にパッケージ化してS3にアップロードします。さらに、書き込みノードは、クエリパフォーマンスを向上させるための継続的なデータ整理や不要なデータの削除など、S3上のデータを管理します。 書き込みノードは、メモリの過剰な使用を避けるために、ローカル ディスク (通常は NVMe SSD) を使用して最新の書き込みデータをキャッシュします。 -- TiFlashコンピューティングノード +- TiFlashコンピューティングノード コンピューティングノードは、TiDBノードから送信されたクエリリクエストを実行します。まず、書き込みノードにアクセスしてデータのスナップショットを取得し、次に書き込みノードから最新のデータ（つまり、まだS3にアップロードされていないデータ）を読み取り、残りのデータの大部分をS3から読み取ります。 @@ -27,20 +27,20 @@ summary: TiFlash の分散ストレージとコンピューティングアーキ コンピューティングノードはステートレスであり、スケーリング速度は2段階レベルです。この機能を利用することで、以下のようにコストを削減できます。 - - クエリのワークロードが低い場合は、コンピューティングノードの数を減らしてコストを削減します。クエリがない場合、すべてのコンピューティングノードを停止することもできます。 - - クエリのワークロードが増加した場合は、コンピューティング ノードの数を迅速に増やして、クエリのパフォーマンスを確保します。 + - クエリのワークロードが低い場合は、コンピューティングノードの数を減らしてコストを削減します。クエリがない場合、すべてのコンピューティングノードを停止することもできます。 + - クエリのワークロードが増加した場合は、コンピューティング ノードの数を迅速に増やして、クエリのパフォーマンスを確保します。 ## シナリオ {#scenarios} TiFlashの分散型ストレージおよびコンピューティングアーキテクチャは、コスト効率の高いデータ分析サービスに最適です。このアーキテクチャでは、ストレージとコンピューティングリソースを必要に応じて個別に拡張できるため、以下のシナリオで大きなメリットが得られます。 -- データ量は膨大ですが、頻繁にクエリされるデータはごくわずかです。データの大部分はコールドデータであり、クエリ頻度は低いです。このため、頻繁にクエリされるデータは通常、コンピュートノードのローカルSSDにキャッシュされ、高速なクエリパフォーマンスを提供します。一方、その他のコールドデータの大部分は、ストレージコストを節約するために、低コストのS3などのオブジェクトストレージに保存されます。 +- データ量は膨大ですが、頻繁にクエリされるデータはごくわずかです。データの大部分はコールドデータであり、クエリ頻度は低いです。このため、頻繁にクエリされるデータは通常、コンピュートノードのローカルSSDにキャッシュされ、高速なクエリパフォーマンスを提供します。一方、その他のコールドデータの大部分は、ストレージコストを節約するために、低コストのS3などのオブジェクトストレージに保存されます。 -- コンピューティングリソースの需要には明らかなピークと谷があります。例えば、集中的なリコンシリエーションクエリは通常夜間に実行され、多くのコンピューティングリソースを必要とします。このような場合、夜間に一時的にコンピューティングノードを追加することを検討できます。一方、他の時間帯には、通常のクエリタスクを実行するために必要なコンピューティングノードの数は少なくて済みます。 +- コンピューティングリソースの需要には明らかなピークと谷があります。例えば、集中的なリコンシリエーションクエリは通常夜間に実行され、多くのコンピューティングリソースを必要とします。このような場合、夜間に一時的にコンピューティングノードを追加することを検討できます。一方、他の時間帯には、通常のクエリタスクを実行するために必要なコンピューティングノードの数は少なくて済みます。 ## 前提条件 {#prerequisites} -1. TiFlashデータを保存するための Amazon S3 バケットを準備します。 +1. TiFlashデータを保存するための Amazon S3 バケットを準備します。 既存のバケットを使用することもできますが、TiDBクラスターごとに専用のキープレフィックスを予約する必要があります。S3バケットの詳細については、 [AWSドキュメント](https://docs.aws.amazon.com/en_us/AmazonS3/latest/userguide/creating-buckets-s3.html)ご覧ください。 @@ -48,15 +48,15 @@ TiFlashの分散型ストレージおよびコンピューティングアーキ TiFlash はデータにアクセスするために以下の S3 API を使用する必要があります。TiDB クラスター内のTiFlashノードにこれらの API に対する必要な権限が付与されていることを確認してください。 - - オブジェクトを配置する - - GetObject - - オブジェクトのコピー - - オブジェクトの削除 - - リストオブジェクトV2 - - オブジェクトタグ付けの取得 - - PutBucketライフサイクル + - オブジェクトを配置する + - GetObject + - オブジェクトのコピー + - オブジェクトの削除 + - リストオブジェクトV2 + - オブジェクトタグ付けの取得 + - PutBucketライフサイクル -2. TiDBクラスターに、ストレージとコンピューティングを組み合わせたアーキテクチャを使用してデプロイされたTiFlashノードがないことを確認してください。もしある場合は、すべてのテーブルのTiFlashレプリカ数を`0`に設定し、すべてのTiFlashノードを削除してください。例： +2. TiDBクラスターに、ストレージとコンピューティングを組み合わせたアーキテクチャを使用してデプロイされたTiFlashノードがないことを確認してください。もしある場合は、すべてのテーブルのTiFlashレプリカ数を`0`に設定し、すべてのTiFlashノードを削除してください。例： ```sql SELECT * FROM INFORMATION_SCHEMA.TIFLASH_REPLICA; # Query all tables with TiFlash replicas @@ -73,7 +73,7 @@ TiFlashの分散型ストレージおよびコンピューティングアーキ デフォルトでは、 TiUPはTiFlash を結合ストレージおよびコンピューティングアーキテクチャにデプロイします。分離ストレージおよびコンピューティングアーキテクチャにTiFlashをデプロイする必要がある場合は、以下の手順に従って手動で設定してください。 -1. 次の構成を持つ、 `scale-out.topo.yaml`などのTiFlashトポロジ構成ファイルを準備します。 +1. 次の構成を持つ、 `scale-out.topo.yaml`などのTiFlashトポロジ構成ファイルを準備します。 ```yaml tiflash_servers: @@ -126,7 +126,7 @@ TiFlashの分散型ストレージおよびコンピューティングアーキ storage.remote.cache.capacity: 858993459200 # 800 GiB ``` - - 上記の`ACCESS_KEY_ID`と`SECRET_ACCESS_KEY`設定ファイルに直接記述されていることに注意してください。環境変数を使用して個別に設定することもできます。両方の方法で設定した場合、環境変数が優先されます。 + - 上記の`ACCESS_KEY_ID`と`SECRET_ACCESS_KEY`設定ファイルに直接記述されていることに注意してください。環境変数を使用して個別に設定することもできます。両方の方法で設定した場合、環境変数が優先されます。 環境変数を使用して`ACCESS_KEY_ID`と`SECRET_ACCESS_KEY`構成するには、 TiFlashを開始するユーザー環境 (通常は`tidb` ) に切り替え、 `~/.bash_profile`変更して次の構成を追加します。 @@ -135,9 +135,9 @@ TiFlashの分散型ストレージおよびコンピューティングアーキ export S3_SECRET_ACCESS_KEY={SECRET_ACCESS_KEY} ``` - - `storage.s3.endpoint` `http`または`https`モードを使用した S3 接続をサポートしており、URL を直接変更することでモードを設定できます。例: `https://s3.{region}.amazonaws.com` 。 + - `storage.s3.endpoint` `http`または`https`モードを使用した S3 接続をサポートしており、URL を直接変更することでモードを設定できます。例: `https://s3.{region}.amazonaws.com` 。 -2. TiFlashノードを追加し、 TiFlashレプリカの数をリセットします。 +2. TiFlashノードを追加し、 TiFlashレプリカの数をリセットします。 ```shell tiup cluster scale-out mycluster ./scale-out.topo.yaml @@ -147,15 +147,15 @@ TiFlashの分散型ストレージおよびコンピューティングアーキ ALTER TABLE table_name SET TIFLASH REPLICA 1; ``` -3. 分散ストレージおよびコンピューティングアーキテクチャを使用してTiFlash をクエリするように TiDB 構成を変更します。 +3. 分散ストレージおよびコンピューティングアーキテクチャを使用してTiFlash をクエリするように TiDB 構成を変更します。 - 1. TiDB 構成ファイルを編集モードで開きます。 + 1. TiDB 構成ファイルを編集モードで開きます。 ```shell tiup cluster edit-config mycluster ``` - 2. TiDB 構成ファイルに次の構成項目を追加します。 + 2. TiDB 構成ファイルに次の構成項目を追加します。 ```shell server_configs: @@ -163,7 +163,7 @@ TiFlashの分散型ストレージおよびコンピューティングアーキ disaggregated-tiflash: true # Query TiFlash using the disaggregated storage and compute architecture ``` - 3. TiDBを再起動します。 + 3. TiDBを再起動します。 ```shell tiup cluster reload mycluster -R tidb @@ -171,8 +171,8 @@ TiFlashの分散型ストレージおよびコンピューティングアーキ ## 制限 {#restrictions} -- TiFlashは、**分離ストレージおよびコンピューティングアーキテクチャ**と**結合ストレージおよびコンピューティングアーキテクチャ**間のインプレース切り替えをサポートしていません。分離アーキテクチャに切り替える前に、結合アーキテクチャを使用してデプロイされている既存のTiFlashノードをすべて削除する必要があります。 -- あるアーキテクチャから別のアーキテクチャに移行した後、すべてのTiFlashデータを再度複製する必要があります。 -- 同じTiDBクラスター内では、同じアーキテクチャのTiFlashノードのみが許可されます。1つのクラスター内で2つのアーキテクチャを共存させることはできません。 -- 分散型ストレージおよびコンピューティングアーキテクチャはS3 API を使用したオブジェクトストレージのみをサポートしますが、結合型ストレージおよびコンピューティングアーキテクチャはローカルストレージのみをサポートします。 -- S3ストレージを使用する場合、 TiFlashノードは自身のノード上にないファイルのキーを取得できないため、 [保存時の暗号化](/encryption-at-rest.md)機能は使用できません。 +- TiFlashは、**分離ストレージおよびコンピューティングアーキテクチャ**と**結合ストレージおよびコンピューティングアーキテクチャ**間のインプレース切り替えをサポートしていません。分離アーキテクチャに切り替える前に、結合アーキテクチャを使用してデプロイされている既存のTiFlashノードをすべて削除する必要があります。 +- あるアーキテクチャから別のアーキテクチャに移行した後、すべてのTiFlashデータを再度複製する必要があります。 +- 同じTiDBクラスター内では、同じアーキテクチャのTiFlashノードのみが許可されます。1つのクラスター内で2つのアーキテクチャを共存させることはできません。 +- 分散型ストレージおよびコンピューティングアーキテクチャはS3 API を使用したオブジェクトストレージのみをサポートしますが、結合型ストレージおよびコンピューティングアーキテクチャはローカルストレージのみをサポートします。 +- S3ストレージを使用する場合、 TiFlashノードは自身のノード上にないファイルのキーを取得できないため、 [保存時の暗号化](/encryption-at-rest.md)機能は使用できません。 diff --git a/tiflash/tiflash-late-materialization.md b/tiflash/tiflash-late-materialization.md index de5a8e816706d..c90709ab2b020 100644 --- a/tiflash/tiflash-late-materialization.md +++ b/tiflash/tiflash-late-materialization.md @@ -11,8 +11,8 @@ summary: 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 スキャンと計算量が削減されます。 +- 無効にすると、フィルタ条件（ `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)を参照してください。 @@ -64,13 +64,13 @@ SHOW GLOBAL VARIABLES LIKE 'tidb_opt_enable_late_materialization'; `tidb_opt_enable_late_materialization`変数は、セッション レベルまたはグローバル レベルで変更できます。 -- 現在のセッションでTiFlash の遅延マテリアライゼーションを無効にするには、次のステートメントを使用します。 +- 現在のセッションでTiFlash の遅延マテリアライゼーションを無効にするには、次のステートメントを使用します。 ```sql SET SESSION tidb_opt_enable_late_materialization=OFF; ``` -- グローバル レベルでTiFlash の遅延マテリアライゼーションを無効にするには、次のステートメントを使用します。 +- グローバル レベルでTiFlash の遅延マテリアライゼーションを無効にするには、次のステートメントを使用します。 ```sql SET GLOBAL tidb_opt_enable_late_materialization=OFF; @@ -92,8 +92,8 @@ SET GLOBAL tidb_opt_enable_late_materialization=ON; フィルター条件が TableScan オペレーターにプッシュダウンされると、TableScan オペレーターの実行プロセスには主に次の手順が含まれます。 -1. 3 つの列``を読み取り、マルチバージョン同時実行制御 (MVCC) フィルタリングを実行し、MVCC ビットマップを生成します。 -2. フィルター条件に関連する列を読み取り、条件を満たす行をフィルターして、フィルター ビットマップを生成します。 -3. MVCC ビットマップとフィルター ビットマップの間で`AND`演算を実行して、最終ビットマップを生成します。 -4. 最終ビットマップに従って、残りの列の対応する行を読み取ります。 -5. 手順 2 と 4 で読み取ったデータを結合し、結果を返します。 +1. 3 つの列``を読み取り、マルチバージョン同時実行制御 (MVCC) フィルタリングを実行し、MVCC ビットマップを生成します。 +2. フィルター条件に関連する列を読み取り、条件を満たす行をフィルターして、フィルター ビットマップを生成します。 +3. MVCC ビットマップとフィルター ビットマップの間で`AND`演算を実行して、最終ビットマップを生成します。 +4. 最終ビットマップに従って、残りの列の対応する行を読み取ります。 +5. 手順 2 と 4 で読み取ったデータを結合し、結果を返します。 diff --git a/tiflash/tiflash-mintso-scheduler.md b/tiflash/tiflash-mintso-scheduler.md index a27e973868f3e..5ae0cc672c2e1 100644 --- a/tiflash/tiflash-mintso-scheduler.md +++ b/tiflash/tiflash-mintso-scheduler.md @@ -50,8 +50,8 @@ EXPLAIN SELECT count(*) FROM t0 a JOIN t0 b ON a.id = b.id; デッドロックを回避するために、 TiFlash は次の 2 つのレベルのスレッド制限を導入します。 -- thread_soft_limit: システムで使用されるスレッド数を制限するために使用されます。特定のMPPタスクでは、デッドロックを回避するためにこの制限を超えることができます。 -- thread_hard_limit: システムを保護するために使用されます。システムで使用されるスレッド数がハードリミットを超えると、 TiFlashはデッドロックを回避するためにエラーを報告します。 +- thread_soft_limit: システムで使用されるスレッド数を制限するために使用されます。特定のMPPタスクでは、デッドロックを回避するためにこの制限を超えることができます。 +- thread_hard_limit: システムを保護するために使用されます。システムで使用されるスレッド数がハードリミットを超えると、 TiFlashはデッドロックを回避するためにエラーを報告します。 ソフトリミットとハードリミットは、デッドロックを回避するために次のように連携して機能します。ソフトリミットは、すべてのクエリで使用されるスレッドの総数を制限し、スレッドリソースの枯渇を回避しながらリソースを最大限に活用できるようにします。ハードリミットは、いかなる状況においても、システム内の少なくとも1つのクエリがソフトリミットを破り、スレッドリソースを取得して実行を継続できるようにすることで、デッドロックを回避します。スレッド数がハードリミットを超えない限り、システム内には常に1つのクエリが存在し、そのクエリのすべてのMPPタスクが正常に実行され、デッドロックを回避します。 @@ -65,4 +65,4 @@ MinTSO スケジューラのスケジューリング プロセスは次のとお ## 参照 {#see-also} -- [TiFlashを設定する](/tiflash/tiflash-configuration.md) : MinTSO スケジューラを構成する方法を学習します。 +- [TiFlashを設定する](/tiflash/tiflash-configuration.md) : MinTSO スケジューラを構成する方法を学習します。 diff --git a/tiflash/tiflash-overview.md b/tiflash/tiflash-overview.md index 257d88c96be4c..66c594812e621 100644 --- a/tiflash/tiflash-overview.md +++ b/tiflash/tiflash-overview.md @@ -45,10 +45,10 @@ TiFlash内のテーブルのレプリカを作成するための DDL コマン TiFlash には次の主な機能があります。 -- [非同期レプリケーション](#asynchronous-replication) -- [一貫性](#consistency) -- [賢い選択](#intelligent-choice) -- [コンピューティングの加速](#computing-acceleration) +- [非同期レプリケーション](#asynchronous-replication) +- [一貫性](#consistency) +- [賢い選択](#intelligent-choice) +- [コンピューティングの加速](#computing-acceleration) ### 非同期レプリケーション {#asynchronous-replication} @@ -56,8 +56,8 @@ TiFlash内のレプリカは、特別なロールであるRaft Learnerとして このレプリケーション メカニズムは、自動負荷分散と高可用性という TiKV の 2 つの利点を継承しています。 -- TiFlash は追加のレプリケーション チャネルに依存せず、多対多の方法で TiKV からデータを直接受信します。 -- TiKV でデータが失われていない限り、いつでもTiFlashでレプリカを復元できます。 +- TiFlash は追加のレプリケーション チャネルに依存せず、多対多の方法で TiKV からデータを直接受信します。 +- TiKV でデータが失われていない限り、いつでもTiFlashでレプリカを復元できます。 ### 一貫性 {#consistency} @@ -75,8 +75,8 @@ TiDB は、 TiFlash (列単位) または TiKV (行単位) の使用を自動的 TiFlash は、次の 2 つの方法で TiDB のコンピューティングを高速化します。 -- 列型ストレージエンジンは読み取り操作の実行においてより効率的です。 -- TiFlash はTiDB のコンピューティング ワークロードの一部を共有します。 +- 列型ストレージエンジンは読み取り操作の実行においてより効率的です。 +- TiFlash はTiDB のコンピューティング ワークロードの一部を共有します。 TiFlashは、TiKVコプロセッサーと同様にコンピューティングワークロードを分散します。TiDBは、ストレージレイヤーで完了可能なコンピューティングをプッシュダウンします。コンピューティングをプッシュダウンできるかどうかは、 TiFlashのサポート状況によって異なります。詳細については、 [サポートされているプッシュダウン計算](/tiflash/tiflash-supported-pushdown-calculations.md)を参照してください。 @@ -86,9 +86,9 @@ TiFlashを導入した後、データのレプリケーションは自動的に TiDBを使用してTiFlashレプリカを読み取ることができます。詳細については、以下のセクションをご覧ください。 -- [TiFlashレプリカを作成する](/tiflash/create-tiflash-replicas.md) -- [TiDB を使用してTiFlashレプリカを読み取る](/tiflash/use-tidb-to-read-tiflash.md) -- [MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md) +- [TiFlashレプリカを作成する](/tiflash/create-tiflash-replicas.md) +- [TiDB を使用してTiFlashレプリカを読み取る](/tiflash/use-tidb-to-read-tiflash.md) +- [MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md) @@ -100,24 +100,24 @@ TPC-H データセットでのデータのインポートからクエリまで -- 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) 。 -- [TiFlashクラスターを監視する](/tiflash/monitor-tiflash.md) 。 -- [TiFlashアラートルール](/tiflash/tiflash-alert-rules.md)を学びます。 -- [TiFlashクラスターのトラブルシューティング](/tiflash/troubleshoot-tiflash.md) 。 -- [TiFlashでプッシュダウン計算をサポート](/tiflash/tiflash-supported-pushdown-calculations.md) -- [TiFlashでのデータ検証](/tiflash/tiflash-data-validation.md) -- [TiFlashの互換性](/tiflash/tiflash-compatibility.md) +- 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) 。 +- [TiFlashクラスターを監視する](/tiflash/monitor-tiflash.md) 。 +- [TiFlashアラートルール](/tiflash/tiflash-alert-rules.md)を学びます。 +- [TiFlashクラスターのトラブルシューティング](/tiflash/troubleshoot-tiflash.md) 。 +- [TiFlashでプッシュダウン計算をサポート](/tiflash/tiflash-supported-pushdown-calculations.md) +- [TiFlashでのデータ検証](/tiflash/tiflash-data-validation.md) +- [TiFlashの互換性](/tiflash/tiflash-compatibility.md) -- [TiFlashのパフォーマンスを調整する](/tiflash/tune-tiflash-performance.md) 。 -- [TiFlashでプッシュダウン計算をサポート](/tiflash/tiflash-supported-pushdown-calculations.md) -- [TiFlashの互換性](/tiflash/tiflash-compatibility.md) +- [TiFlashのパフォーマンスを調整する](/tiflash/tune-tiflash-performance.md) 。 +- [TiFlashでプッシュダウン計算をサポート](/tiflash/tiflash-supported-pushdown-calculations.md) +- [TiFlashの互換性](/tiflash/tiflash-compatibility.md) diff --git a/tiflash/tiflash-pipeline-model.md b/tiflash/tiflash-pipeline-model.md index 723dcc420903d..8613d1c81e5f5 100644 --- a/tiflash/tiflash-pipeline-model.md +++ b/tiflash/tiflash-pipeline-model.md @@ -9,8 +9,8 @@ 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.2.0 および v7.3.0 の場合: パイプライン実行モデルは実験的であり、 [`tidb_enable_tiflash_pipeline_model`](https://docs-archive.pingcap.com/tidb/v7.2/system-variables/#tidb_enable_tiflash_pipeline_model-new-in-v720)によって制御されます。 +- v7.4.0 以降のバージョンの場合: パイプライン実行モデルが一般提供されます。これはTiFlashの内部機能であり、 TiFlashリソース制御と緊密に統合されています。 TiFlashリソース制御を有効にすると、パイプライン実行モデルが自動的に有効になります。 TiFlashリソース制御の使用方法の詳細については、 [リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md#parameters-for-resource-control)を参照してください。さらに、v7.4.0 以降、システム変数`tidb_enable_tiflash_pipeline_model`は非推奨になりました。 論文[モルセル駆動型並列処理：マルチコア時代に向けたNUMA対応クエリ評価フレームワーク](https://dl.acm.org/doi/10.1145/2588555.2610507)からインスピレーションを得た、 TiFlashパイプライン実行モデルは、従来のスレッド スケジューリング モデルとは異なる、きめの細かいタスク スケジューリング モデルを提供します。これにより、オペレーティング システムのスレッド アプリケーションとスケジューリングのオーバーヘッドが削減され、きめ細かいスケジューリング メカニズムが提供されます。 @@ -20,13 +20,13 @@ TiFlashのオリジナルのストリームモデルは、スレッドスケジ スレッドスケジューリングモデルには、以下の2つの欠陥がある。 -- 高並行処理シナリオでは、スレッド数が多すぎるとコンテキストスイッチが大量に発生し、結果としてスレッドスケジューリングのコストが高くなります。 -- スレッドスケジューリングモデルでは、クエリのリソース使用量を正確に測定したり、きめ細かなリソース制御を行うことはできません。 +- 高並行処理シナリオでは、スレッド数が多すぎるとコンテキストスイッチが大量に発生し、結果としてスレッドスケジューリングのコストが高くなります。 +- スレッドスケジューリングモデルでは、クエリのリソース使用量を正確に測定したり、きめ細かなリソース制御を行うことはできません。 新しいパイプライン実行モデルでは、以下の最適化が行われます。 -- クエリは複数のパイプラインに分割され、順次実行されます。各パイプラインでは、データブロックを可能な限りキャッシュに保持することで、時間的な局所性を向上させ、実行プロセス全体の効率を高めます。 -- オペレーティングシステムのネイティブなスレッドスケジューリングモデルを排除し、よりきめ細かなスケジューリングメカニズムを実装するために、各パイプラインは複数のタスクにインスタンス化され、タスクスケジューリングモデルが使用されます。同時に、オペレーティングシステムのスレッドスケジューリングのオーバーヘッドを削減するために、固定スレッドプールが使用されます。 +- クエリは複数のパイプラインに分割され、順次実行されます。各パイプラインでは、データブロックを可能な限りキャッシュに保持することで、時間的な局所性を向上させ、実行プロセス全体の効率を高めます。 +- オペレーティングシステムのネイティブなスレッドスケジューリングモデルを排除し、よりきめ細かなスケジューリングメカニズムを実装するために、各パイプラインは複数のタスクにインスタンス化され、タスクスケジューリングモデルが使用されます。同時に、オペレーティングシステムのスレッドスケジューリングのオーバーヘッドを削減するために、固定スレッドプールが使用されます。 パイプライン実行モデルのアーキテクチャは以下のとおりです。 @@ -34,7 +34,7 @@ TiFlashのオリジナルのストリームモデルは、スレッドスケジ 前述の図に示すように、パイプライン実行モデルは、パイプラインクエリ実行部とタスクスケジューラという2つの主要な構成要素から成り立っています。 -- パイプラインクエリ実行ツール +- パイプラインクエリ実行ツール パイプラインクエリ実行エンジンは、TiDBノードから送信されたクエリ要求をパイプライン有向非巡回グラフ（DAG）に変換します。 @@ -44,18 +44,18 @@ TiFlashのオリジナルのストリームモデルは、スレッドスケジ クエリがパイプラインDAGに変換された後、パイプラインクエリ実行エンジンは、依存関係に従って各パイプラインを順番に実行します。パイプラインは、クエリの同時実行性に応じて複数のタスクにインスタンス化され、実行のためにタスクスケジューラに送信されます。 -- タスクスケジューラ +- タスクスケジューラ タスクスケジューラは、パイプラインクエリ実行エンジンによって送信されたタスクを実行します。タスクは、実行ロジックに応じて、タスクスケジューラ内のさまざまなコンポーネント間で動的に切り替えられます。 - - CPUタスクスレッドプール + - CPUタスクスレッドプール タスク内のCPU負荷の高い計算ロジック（データフィルタリングや関数計算など）を実行します。 - - IOタスクスレッドプール + - IOタスクスレッドプール タスク内のI/O負荷の高い計算ロジックを実行します。例えば、中間結果をディスクに書き込むなどです。 - - Wait reactor + - Wait reactor タスク内の待機ロジックを実行します。たとえば、ネットワークレイヤーがデータパケットを計算レイヤーに転送するのを待機します。 diff --git a/tiflash/tiflash-results-materialization.md b/tiflash/tiflash-results-materialization.md index 8e5403f239723..5adf1de32f005 100644 --- a/tiflash/tiflash-results-materialization.md +++ b/tiflash/tiflash-results-materialization.md @@ -13,8 +13,8 @@ TiDB v6.5.0以降、 TiFlashクエリ結果をテーブルに保存すること > > デフォルト（ [`tidb_allow_mpp = ON`](/system-variables.md#tidb_allow_mpp-new-in-v50) ）では、オプティマイザは[SQLモード](/sql-mode.md)とTiFlashレプリカのコスト見積もりに基づいて、クエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定します。 > -> - 現在のセッションの[SQLモード](/sql-mode.md)が厳密でない場合（つまり、 `sql_mode`の値に`STRICT_TRANS_TABLES`と`STRICT_ALL_TABLES`が含まれていない場合）、オプティマイザはTiFlashレプリカのコスト見積もりに基づいて、 `INSERT INTO SELECT`の`SELECT`サブクエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定します。このモードでは、オプティマイザのコスト見積もりを無視し、クエリをTiFlashにプッシュダウンすることを強制するには、 [`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-new-in-v51)システム変数を`ON`に設定できます。 -> - 現在のセッションの[SQLモード](/sql-mode.md)が厳密な場合 (つまり、 `sql_mode`の値に`STRICT_TRANS_TABLES`または`STRICT_ALL_TABLES`のいずれかが含まれている場合)、 `INSERT INTO SELECT`の`SELECT`サブクエリをTiFlashにプッシュダウンすることはできません。 +> - 現在のセッションの[SQLモード](/sql-mode.md)が厳密でない場合（つまり、 `sql_mode`の値に`STRICT_TRANS_TABLES`と`STRICT_ALL_TABLES`が含まれていない場合）、オプティマイザはTiFlashレプリカのコスト見積もりに基づいて、 `INSERT INTO SELECT`の`SELECT`サブクエリをTiFlashにプッシュダウンするかどうかをインテリジェントに決定します。このモードでは、オプティマイザのコスト見積もりを無視し、クエリをTiFlashにプッシュダウンすることを強制するには、 [`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-new-in-v51)システム変数を`ON`に設定できます。 +> - 現在のセッションの[SQLモード](/sql-mode.md)が厳密な場合 (つまり、 `sql_mode`の値に`STRICT_TRANS_TABLES`または`STRICT_ALL_TABLES`のいずれかが含まれている場合)、 `INSERT INTO SELECT`の`SELECT`サブクエリをTiFlashにプッシュダウンすることはできません。 `INSERT INTO SELECT`の構文は次のとおりです。 @@ -41,11 +41,11 @@ SELECT app_name, country FROM t1; ## 一般的な推奨使用シナリオ {#typical-and-recommended-usage-scenarios} -- 効率的なBIソリューション +- 効率的なBIソリューション 多くの BI アプリケーションでは、分析クエリ要求が非常に重くなります。たとえば、多くのユーザーが同時にレポートにアクセスして更新する場合、BI アプリケーションは大量の同時クエリ要求を処理する必要があります。この状況に効果的に対処するには、 `INSERT INTO SELECT`を使用してレポートのクエリ結果を TiDB テーブルに保存します。その後、エンドユーザーはレポートが更新されたときに結果テーブルから直接データをクエリできるため、計算と分析が何度も繰り返されるのを回避できます。同様に、履歴分析結果を保存することで、長時間の履歴データ分析の計算量をさらに削減できます。たとえば、日次売上利益を分析するために使用されるレポート`A`がある場合、 `INSERT INTO SELECT`を使用してレポート`A`の結果を結果テーブル`T`に保存できます。その後、先月の売上利益を分析するためにレポート`B`を生成する必要がある場合は、テーブル`T`の日次分析結果を直接使用できます。この方法は、計算量を大幅に削減するだけでなく、クエリ応答速度を向上させ、システム負荷を軽減します。 -- TiFlashによるオンライン アプリケーションの提供 +- TiFlashによるオンライン アプリケーションの提供 TiFlashがサポートする同時リクエスト数は、データ量とクエリの複雑さによって異なりますが、通常は 100 QPS を超えることはありません。`INSERT INTO SELECT`を指定してTiFlashクエリ結果を保存し、クエリ結果テーブルを使用して、同時実行性の高いオンラインリクエストをサポートできます。結果テーブルのデータは、 TiFlash の同時実行制限をはるかに下回る低頻度（例：0.5 秒間隔）でバックグラウンドで更新できますが、データの鮮度は高いレベルで維持されます。 diff --git a/tiflash/tiflash-spill-disk.md b/tiflash/tiflash-spill-disk.md index fdb84c57e470e..fb3193aebd796 100644 --- a/tiflash/tiflash-spill-disk.md +++ b/tiflash/tiflash-spill-disk.md @@ -9,32 +9,32 @@ summary: TiFlash がデータをディスクに書き出す方法と、書き出 バージョン7.0.0以降、 TiFlashはメモリ負荷を軽減するために中間データをディスクに書き出す機能をサポートしています。以下の演算子がサポートされています。 -- 等価結合条件を持つハッシュ結合演算子 -- `GROUP BY`キーを持つハッシュ集計演算子 -- TopN演算子とウィンドウ関数のソート演算子 +- 等価結合条件を持つハッシュ結合演算子 +- `GROUP BY`キーを持つハッシュ集計演算子 +- TopN演算子とウィンドウ関数のソート演算子 ## こぼれを誘発する {#trigger-the-spilling} TiFlash は、データをディスクに書き出すための 2 つのトリガー メカニズムを提供します。 -- オペレータ レベルのスピル: 各オペレータのデータ スピルしきい値を指定することにより、 TiFlash がそのオペレータのデータをディスクにスピルするタイミングを制御できます。 -- クエリ レベルのスピル: TiFlashノードでのクエリの最大メモリ使用量とスピルのメモリ比率を指定することにより、 TiFlash がクエリでサポートされている演算子のデータを必要に応じてディスクにスピルするタイミングを制御できます。 +- オペレータ レベルのスピル: 各オペレータのデータ スピルしきい値を指定することにより、 TiFlash がそのオペレータのデータをディスクにスピルするタイミングを制御できます。 +- クエリ レベルのスピル: TiFlashノードでのクエリの最大メモリ使用量とスピルのメモリ比率を指定することにより、 TiFlash がクエリでサポートされている演算子のデータを必要に応じてディスクにスピルするタイミングを制御できます。 ### オペレータレベルのスピル {#operator-level-spilling} バージョン7.0.0以降、 TiFlashはオペレータレベルでの自動スピルをサポートしています。以下のシステム変数を使用して、各オペレータのデータスピルのしきい値を制御できます。オペレータのメモリ使用量がしきい値を超えると、 TiFlashはそのオペレータのスピルをトリガーします。 -- [`tidb_max_bytes_before_tiflash_external_group_by`](/system-variables.md#tidb_max_bytes_before_tiflash_external_group_by-new-in-v700) -- [`tidb_max_bytes_before_tiflash_external_join`](/system-variables.md#tidb_max_bytes_before_tiflash_external_join-new-in-v700) -- [`tidb_max_bytes_before_tiflash_external_sort`](/system-variables.md#tidb_max_bytes_before_tiflash_external_sort-new-in-v700) +- [`tidb_max_bytes_before_tiflash_external_group_by`](/system-variables.md#tidb_max_bytes_before_tiflash_external_group_by-new-in-v700) +- [`tidb_max_bytes_before_tiflash_external_join`](/system-variables.md#tidb_max_bytes_before_tiflash_external_join-new-in-v700) +- [`tidb_max_bytes_before_tiflash_external_sort`](/system-variables.md#tidb_max_bytes_before_tiflash_external_sort-new-in-v700) #### 例 {#example} この例では、ハッシュ集計演算子のスピルを示すために、大量のメモリを消費する SQL ステートメントを構築します。 -1. 環境を準備します。2ノードのTiFlashクラスターを作成し、TPCH-100データをインポートします。 +1. 環境を準備します。2ノードのTiFlashクラスターを作成し、TPCH-100データをインポートします。 -2. 以下のステートメントを実行してください。これらのステートメントは、 `GROUP BY`キーのハッシュ集計演算子のメモリ使用量を制限しません。 +2. 以下のステートメントを実行してください。これらのステートメントは、 `GROUP BY`キーのハッシュ集計演算子のメモリ使用量を制限しません。 ```sql SET tidb_max_bytes_before_tiflash_external_group_by = 0; @@ -50,13 +50,13 @@ TiFlash は、データをディスクに書き出すための 2 つのトリガ HAVING SUM(l_quantity) > 314; ``` -3. TiFlashのログから、クエリは単一のTiFlashノードで 29.55 GiB のメモリを消費する必要があることがわかります。 +3. TiFlashのログから、クエリは単一のTiFlashノードで 29.55 GiB のメモリを消費する必要があることがわかります。 ``` [DEBUG] [MemoryTracker.cpp:69] ["Peak memory usage (total): 29.55 GiB."] [source=MemoryTracker] [thread_id=468] ``` -4. 次のステートメントを実行します。このステートメントは、キーが`GROUP BY`ハッシュ集計子のメモリ使用量を10737418240（10 GiB）に制限します。 +4. 次のステートメントを実行します。このステートメントは、キーが`GROUP BY`ハッシュ集計子のメモリ使用量を10737418240（10 GiB）に制限します。 ```sql SET tidb_max_bytes_before_tiflash_external_group_by = 10737418240; @@ -72,7 +72,7 @@ TiFlash は、データをディスクに書き出すための 2 つのトリガ HAVING SUM(l_quantity) > 314; ``` -5. TiFlashのログを見ると、 `tidb_max_bytes_before_tiflash_external_group_by`設定するとTiFlash が中間結果のスピルをトリガーし、クエリで使用されるメモリが大幅に削減されることがわかります。 +5. TiFlashのログを見ると、 `tidb_max_bytes_before_tiflash_external_group_by`設定するとTiFlash が中間結果のスピルをトリガーし、クエリで使用されるメモリが大幅に削減されることがわかります。 ``` [DEBUG] [MemoryTracker.cpp:69] ["Peak memory usage (total): 12.80 GiB."] [source=MemoryTracker] [thread_id=110] @@ -82,8 +82,8 @@ TiFlash は、データをディスクに書き出すための 2 つのトリガ TiFlash v7.4.0以降、クエリレベルでの自動スピルをサポートしています。この機能は、以下のシステム変数を使用して制御できます。 -- [`tiflash_mem_quota_query_per_node`](/system-variables.md#tiflash_mem_quota_query_per_node-new-in-v740) : TiFlashノードでのクエリの最大メモリ使用量を制限します。 -- [`tiflash_query_spill_ratio`](/system-variables.md#tiflash_query_spill_ratio-new-in-v740) : データの流出をトリガーするメモリ比率を制御します。 +- [`tiflash_mem_quota_query_per_node`](/system-variables.md#tiflash_mem_quota_query_per_node-new-in-v740) : TiFlashノードでのクエリの最大メモリ使用量を制限します。 +- [`tiflash_query_spill_ratio`](/system-variables.md#tiflash_query_spill_ratio-new-in-v740) : データの流出をトリガーするメモリ比率を制御します。 `tiflash_mem_quota_query_per_node`と`tiflash_query_spill_ratio`両方が 0 より大きい値に設定されている場合、クエリのメモリ使用量が`tiflash_mem_quota_query_per_node * tiflash_query_spill_ratio`超えると、 TiFlash はクエリでサポートされている演算子のスピルを自動的にトリガーします。 @@ -91,9 +91,9 @@ TiFlash v7.4.0以降、クエリレベルでの自動スピルをサポートし この例では、クエリ レベルのスピルを示すために大量のメモリを消費する SQL ステートメントを構築します。 -1. 環境を準備します。2ノードのTiFlashクラスターを作成し、TPCH-100データをインポートします。 +1. 環境を準備します。2ノードのTiFlashクラスターを作成し、TPCH-100データをインポートします。 -2. 以下のステートメントを実行してください。これらのステートメントは、クエリのメモリ使用量や、キーが`GROUP BY`ハッシュ集計演算子のメモリ使用量を制限しません。 +2. 以下のステートメントを実行してください。これらのステートメントは、クエリのメモリ使用量や、キーが`GROUP BY`ハッシュ集計演算子のメモリ使用量を制限しません。 ```sql SET tidb_max_bytes_before_tiflash_external_group_by = 0; @@ -111,13 +111,13 @@ TiFlash v7.4.0以降、クエリレベルでの自動スピルをサポートし HAVING SUM(l_quantity) > 314; ``` -3. TiFlashのログから、クエリが単一のTiFlashノードで 29.55 GiB のメモリを消費していることがわかります。 +3. TiFlashのログから、クエリが単一のTiFlashノードで 29.55 GiB のメモリを消費していることがわかります。 ``` [DEBUG] [MemoryTracker.cpp:69] ["Peak memory usage (total): 29.55 GiB."] [source=MemoryTracker] [thread_id=468] ``` -4. 以下のステートメントを実行します。これらのステートメントは、 TiFlashノード上のクエリの最大メモリ使用量を5GiBに制限します。 +4. 以下のステートメントを実行します。これらのステートメントは、 TiFlashノード上のクエリの最大メモリ使用量を5GiBに制限します。 ```sql SET tiflash_mem_quota_query_per_node = 5368709120; @@ -134,7 +134,7 @@ TiFlash v7.4.0以降、クエリレベルでの自動スピルをサポートし HAVING SUM(l_quantity) > 314; ``` -5. TiFlashのログから、クエリ レベルのスピルを構成すると、 TiFlash中間結果のスピルがトリガーされ、クエリで使用されるメモリが大幅に削減されることがわかります。 +5. TiFlashのログから、クエリ レベルのスピルを構成すると、 TiFlash中間結果のスピルがトリガーされ、クエリで使用されるメモリが大幅に削減されることがわかります。 ``` [DEBUG] [MemoryTracker.cpp:101] ["Peak memory usage (for query): 3.94 GiB."] [source=MemoryTracker] [thread_id=1547] @@ -142,15 +142,15 @@ TiFlash v7.4.0以降、クエリレベルでの自動スピルをサポートし ## 注記 {#notes} -- ハッシュ集計演算子に`GROUP BY`キーがない場合、スピルはサポートされません。ハッシュ集計子に独自の集計関数が含まれている場合でも、スピルはサポートされません。 -- 現在、演算子レベルのスピルのしきい値は各演算子ごとに個別に計算されます。2つのハッシュ集計演算子を含むクエリの場合、クエリレベルのスピルが設定されておらず、集計演算子のしきい値が10 GiBに設定されている場合、2つのハッシュ集計演算子は、それぞれのメモリ使用量が10 GiBを超えた場合にのみデータをスピルします。 -- 現在、ハッシュ集計演算子とTopN/Sort演算子は、リストアフェーズでマージ集計アルゴリズムとマージソートアルゴリズムを使用しています。そのため、これら2つの演算子はスピルを1ラウンドのみトリガーします。メモリ需要が非常に高く、リストアフェーズ中のメモリ使用量が依然としてしきい値を超えている場合、スピルは再度トリガーされません。 -- 現在、ハッシュ結合演算子はパーティションベースのスピル戦略を使用しています。リストアフェーズ中のメモリ使用量が依然としてしきい値を超える場合、スピルは再度トリガーされます。ただし、スピルの規模を制御するため、スピルの回数は3回に制限されています。3回目のスピル後もリストアフェーズ中のメモリ使用量が依然としてしきい値を超える場合、スピルは再度トリガーされません。 -- クエリ レベルのスピルが設定されている場合 (つまり、 [`tiflash_mem_quota_query_per_node`](/system-variables.md#tiflash_mem_quota_query_per_node-new-in-v740)と[`tiflash_query_spill_ratio`](/system-variables.md#tiflash_query_spill_ratio-new-in-v740)両方が 0 より大きい場合)、 TiFlash は個々の演算子のスピルしきい値を無視し、クエリ レベルのスピルしきい値に基づいてクエリ内の関連する演算子のスピルを自動的にトリガーします。 -- クエリレベルのスピルが設定されている場合でも、クエリで使用される演算子がスピルをサポートしていない場合、そのクエリの中間計算結果はディスクにスピルできません。この場合、そのクエリのメモリ使用量が関連するしきい値を超えると、 TiFlashはエラーを返し、クエリを終了します。 -- クエリ レベルのスピルが構成されていて、クエリにスピルをサポートする演算子が含まれている場合でも、次のいずれかのシナリオでメモリしきい値を超えたためにクエリからエラーが返される可能性があります。 +- ハッシュ集計演算子に`GROUP BY`キーがない場合、スピルはサポートされません。ハッシュ集計子に独自の集計関数が含まれている場合でも、スピルはサポートされません。 +- 現在、演算子レベルのスピルのしきい値は各演算子ごとに個別に計算されます。2つのハッシュ集計演算子を含むクエリの場合、クエリレベルのスピルが設定されておらず、集計演算子のしきい値が10 GiBに設定されている場合、2つのハッシュ集計演算子は、それぞれのメモリ使用量が10 GiBを超えた場合にのみデータをスピルします。 +- 現在、ハッシュ集計演算子とTopN/Sort演算子は、リストアフェーズでマージ集計アルゴリズムとマージソートアルゴリズムを使用しています。そのため、これら2つの演算子はスピルを1ラウンドのみトリガーします。メモリ需要が非常に高く、リストアフェーズ中のメモリ使用量が依然としてしきい値を超えている場合、スピルは再度トリガーされません。 +- 現在、ハッシュ結合演算子はパーティションベースのスピル戦略を使用しています。リストアフェーズ中のメモリ使用量が依然としてしきい値を超える場合、スピルは再度トリガーされます。ただし、スピルの規模を制御するため、スピルの回数は3回に制限されています。3回目のスピル後もリストアフェーズ中のメモリ使用量が依然としてしきい値を超える場合、スピルは再度トリガーされません。 +- クエリ レベルのスピルが設定されている場合 (つまり、 [`tiflash_mem_quota_query_per_node`](/system-variables.md#tiflash_mem_quota_query_per_node-new-in-v740)と[`tiflash_query_spill_ratio`](/system-variables.md#tiflash_query_spill_ratio-new-in-v740)両方が 0 より大きい場合)、 TiFlash は個々の演算子のスピルしきい値を無視し、クエリ レベルのスピルしきい値に基づいてクエリ内の関連する演算子のスピルを自動的にトリガーします。 +- クエリレベルのスピルが設定されている場合でも、クエリで使用される演算子がスピルをサポートしていない場合、そのクエリの中間計算結果はディスクにスピルできません。この場合、そのクエリのメモリ使用量が関連するしきい値を超えると、 TiFlashはエラーを返し、クエリを終了します。 +- クエリ レベルのスピルが構成されていて、クエリにスピルをサポートする演算子が含まれている場合でも、次のいずれかのシナリオでメモリしきい値を超えたためにクエリからエラーが返される可能性があります。 - - クエリ内のその他の非スピル演算子はメモリを大量に消費します。 - - スピル演算子は、タイムリーにディスクにスピルしません。 + - クエリ内のその他の非スピル演算子はメモリを大量に消費します。 + - スピル演算子は、タイムリーにディスクにスピルしません。 スピル演算子が時間内にディスクにスピルしない状況に対処するには、メモリしきい値エラーを回避するために[`tiflash_query_spill_ratio`](/system-variables.md#tiflash_query_spill_ratio-new-in-v740)減らすことを試してください。 diff --git a/tiflash/tiflash-supported-pushdown-calculations.md b/tiflash/tiflash-supported-pushdown-calculations.md index 51d05ce4416ec..6d91e99d13461 100644 --- a/tiflash/tiflash-supported-pushdown-calculations.md +++ b/tiflash/tiflash-supported-pushdown-calculations.md @@ -11,23 +11,23 @@ summary: TiFlashでサポートされているプッシュダウン計算につ TiFlash は次の演算子のプッシュダウンをサポートしています。 -- TableScan: テーブルからデータを読み取ります。 -- 選択: データをフィルタリングします。 -- HashAgg: [ハッシュ集計](/explain-aggregation.md#hash-aggregation)アルゴリズムに基づいてデータ集約を実行します。 -- StreamAgg: [ストリーム集計](/explain-aggregation.md#stream-aggregation)アルゴリズムに基づいてデータ集約を実行します。SteamAgg は`GROUP BY`条件なしの集約のみをサポートします。 -- TopN: TopN 計算を実行します。 -- 制限: 制限計算を実行します。 -- 投影: 投影計算を実行します。 -- HashJoin: [ハッシュ結合](/explain-joins.md#hash-join)アルゴリズムを使用して結合計算を実行しますが、次の条件が適用されます。 - - 演算子は[MPPモード](/tiflash/use-tiflash-mpp-mode.md)でのみ押すことができます。 - - サポートされている結合は、Inner Join、Left Join、Semi Join、Anti Semi Join、Left Semi Join、および Anti Left Semi Join です。 - - 上記の結合は、Equi Join と Non-Equi Join（Cartesian Join または Null 対応 Semi Join）の両方をサポートしています。Cartesian Join または Null 対応 Semi Join を計算する際には、Shuffle Hash Join アルゴリズムではなく、Broadcast アルゴリズムが使用されます。 -- [ウィンドウ関数](/functions-and-operators/window-functions.md) : 現在、 TiFlash は`ROW_NUMBER()` 、 `RANK()` 、 `DENSE_RANK()` 、 `LEAD()` 、 `LAG()` 、 `FIRST_VALUE()` 、 `LAST_VALUE()`をサポートしています。 +- TableScan: テーブルからデータを読み取ります。 +- 選択: データをフィルタリングします。 +- HashAgg: [ハッシュ集計](/explain-aggregation.md#hash-aggregation)アルゴリズムに基づいてデータ集約を実行します。 +- StreamAgg: [ストリーム集計](/explain-aggregation.md#stream-aggregation)アルゴリズムに基づいてデータ集約を実行します。SteamAgg は`GROUP BY`条件なしの集約のみをサポートします。 +- TopN: TopN 計算を実行します。 +- 制限: 制限計算を実行します。 +- 投影: 投影計算を実行します。 +- HashJoin: [ハッシュ結合](/explain-joins.md#hash-join)アルゴリズムを使用して結合計算を実行しますが、次の条件が適用されます。 + - 演算子は[MPPモード](/tiflash/use-tiflash-mpp-mode.md)でのみ押すことができます。 + - サポートされている結合は、Inner Join、Left Join、Semi Join、Anti Semi Join、Left Semi Join、および Anti Left Semi Join です。 + - 上記の結合は、Equi Join と Non-Equi Join（Cartesian Join または Null 対応 Semi Join）の両方をサポートしています。Cartesian Join または Null 対応 Semi Join を計算する際には、Shuffle Hash Join アルゴリズムではなく、Broadcast アルゴリズムが使用されます。 +- [ウィンドウ関数](/functions-and-operators/window-functions.md) : 現在、 TiFlash は`ROW_NUMBER()` 、 `RANK()` 、 `DENSE_RANK()` 、 `LEAD()` 、 `LAG()` 、 `FIRST_VALUE()` 、 `LAST_VALUE()`をサポートしています。 TiDBでは、演算子はツリー構造で編成されます。演算子をTiFlashにプッシュダウンするには、以下のすべての前提条件を満たす必要があります。 -- その子演算子はすべてTiFlashにプッシュダウンできます。 -- 演算子に式が含まれている場合 (ほとんどの演算子には式が含まれています)、演算子のすべての式をTiFlashにプッシュダウンできます。 +- その子演算子はすべてTiFlashにプッシュダウンできます。 +- 演算子に式が含まれている場合 (ほとんどの演算子には式が含まれています)、演算子のすべての式をTiFlashにプッシュダウンできます。 ## プッシュダウン式 {#push-down-expressions} @@ -49,17 +49,17 @@ TiFlash は次のプッシュダウン式をサポートしています。 ## 制限 {#restrictions} -- Bit、Set、Geometry 型を含む式は、 TiFlashにプッシュダウンできません。 +- Bit、Set、Geometry 型を含む式は、 TiFlashにプッシュダウンできません。 -- `DATE_ADD()` 、 `DATE_SUB()` 、 `ADDDATE()` 、 `SUBDATE()`関数は、以下の間隔タイプのみをサポートします。他の間隔タイプを使用した場合、 TiFlashはエラーを報告します。 +- `DATE_ADD()` 、 `DATE_SUB()` 、 `ADDDATE()` 、 `SUBDATE()`関数は、以下の間隔タイプのみをサポートします。他の間隔タイプを使用した場合、 TiFlashはエラーを報告します。 - - 日 - - 週 - - 月 - - 年 - - 時間 - - 分 - - 2番 + - 日 + - 週 + - 月 + - 年 + - 時間 + - 分 + - 2番 クエリがサポートされていないプッシュダウン計算に遭遇した場合、TiDBは残りの計算を完了する必要があり、 TiFlashの高速化効果に大きな影響を与える可能性があります。現在サポートされていない演算子と式は、将来のバージョンでサポートされる可能性があります。 diff --git a/tiflash/troubleshoot-tiflash.md b/tiflash/troubleshoot-tiflash.md index 9e54636e768ad..53622237f2dea 100644 --- a/tiflash/troubleshoot-tiflash.md +++ b/tiflash/troubleshoot-tiflash.md @@ -11,7 +11,7 @@ summary: TiFlashクラスターのトラブルシューティングを行う際 TiFlash は様々な理由により正常に起動しない場合があります。以下の手順に従って、段階的に問題を解決してください。 -1. システムが CentOS 8 かどうかを確認します。 +1. システムが CentOS 8 かどうかを確認します。 CentOS 8にはデフォルトでシステムライブラリ`libnsl.so`が含まれていないため、 TiFlashの起動に失敗する可能性があります。以下のコマンドで手動でインストールできます。 @@ -19,15 +19,15 @@ TiFlash は様々な理由により正常に起動しない場合があります dnf install libnsl ``` -2. システムの`ulimit`パラメータ設定を確認してください。 +2. システムの`ulimit`パラメータ設定を確認してください。 ```shell ulimit -n 1000000 ``` -3. PD Controlツールを使用して、ノード（同じIPとポート）上でオフライン化に失敗したTiFlashインスタンスがあるかどうかを確認し、インスタンスを強制的にオフライン化します。詳細な手順については、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)を参照してください。 +3. PD Controlツールを使用して、ノード（同じIPとポート）上でオフライン化に失敗したTiFlashインスタンスがあるかどうかを確認し、インスタンスを強制的にオフライン化します。詳細な手順については、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)を参照してください。 -4. CPU が SIMD 命令をサポートしているかどうかを確認します。 +4. CPU が SIMD 命令をサポートしているかどうかを確認します。 バージョン6.3以降、Linux AMD64アーキテクチャでTiFlashを展開するには、AVX2命令セットをサポートするCPUが必要です。`grep avx2 /proc/cpuinfo`の出力が生成されることを確認してください。Linux ARM64アーキテクチャの場合、CPUはARMv8命令セットアーキテクチャをサポートしている必要があります。`grep 'crc32' /proc/cpuinfo | grep 'asimd'`の出力が生成されることを確認してください。 @@ -45,15 +45,15 @@ TiFlashのワークロードが大きすぎてTiFlashデータのレプリケー データ ファイルの破損を処理するには、次の手順に従います。 -1. 対応するTiFlashノードを停止するには、 [TiFlashノードをダウンさせる](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)を参照してください。 -2. TiFlashノードの関連データを削除します。 -3. クラスター内のTiFlashノードを再デプロイします。 +1. 対応するTiFlashノードを停止するには、 [TiFlashノードをダウンさせる](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)を参照してください。 +2. TiFlashノードの関連データを削除します。 +3. クラスター内のTiFlashノードを再デプロイします。 ## TiFlashノードの削除は遅い {#removing-tiflash-nodes-is-slow} この問題を解決するには、次の手順に従います。 -1. クラスターのスケールイン後に利用可能なTiFlashノードの数よりも多くのTiFlashレプリカがあるテーブルがあるかどうかを確認します。 +1. クラスターのスケールイン後に利用可能なTiFlashノードの数よりも多くのTiFlashレプリカがあるテーブルがあるかどうかを確認します。 ```sql SELECT * FROM information_schema.tiflash_replica WHERE REPLICA_COUNT > 'tobe_left_nodes'; @@ -63,7 +63,7 @@ TiFlashのワークロードが大きすぎてTiFlashデータのレプリケー クエリ結果が空でない場合は、対応するテーブルのTiFlashレプリカ数を変更する必要があります。スケールイン後にTiFlashレプリカ数がTiFlashノード数を超えると、PDは削除対象のTiFlashノードからリージョンピアを移動せず、これらのTiFlashノードの削除が失敗するためです。 -2. すべてのTiFlashノードをクラスターから削除する必要があるシナリオで、表`INFORMATION_SCHEMA.TIFLASH_REPLICA`にクラスター内にTiFlashレプリカが存在しないことが示されていても、 TiFlashノードの削除が依然として失敗する場合は、最近`DROP TABLE .`または`DROP DATABASE `操作を実行したかどうかを確認します。 +2. すべてのTiFlashノードをクラスターから削除する必要があるシナリオで、表`INFORMATION_SCHEMA.TIFLASH_REPLICA`にクラスター内にTiFlashレプリカが存在しないことが示されていても、 TiFlashノードの削除が依然として失敗する場合は、最近`DROP TABLE .`または`DROP DATABASE `操作を実行したかどうかを確認します。 TiFlashレプリカを持つテーブルまたはデータベースの場合、 `DROP TABLE .`または`DROP DATABASE `を実行した後、TiDBはPD内の対応するテーブルのTiFlashレプリケーションルールをすぐに削除しません。代わりに、対応するテーブルがガベージコレクション（GC）条件を満たすまで待機してから、これらのレプリケーションルールを削除します。GCが完了すると、対応するTiFlashノードを正常に削除できます。 @@ -73,7 +73,7 @@ TiFlashのワークロードが大きすぎてTiFlashデータのレプリケー > > テーブルのTiFlashレプリケーション ルールを手動で削除した後、このテーブルに対して`RECOVER TABLE` 、または`FLASHBACK DATABASE` `FLASHBACK TABLE`を実行すると、このテーブルのTiFlashレプリカは復元されません。 - 1. 現在の PD インスタンス内のTiFlashに関連するすべてのデータ複製ルールを表示する。 + 1. 現在の PD インスタンス内のTiFlashに関連するすべてのデータ複製ルールを表示する。 ```shell curl http://:/pd/api/v1/config/rules/group/tiflash @@ -102,7 +102,7 @@ TiFlashのワークロードが大きすぎてTiFlashデータのレプリケー ] ``` - 2. TiFlashに関連するすべてのデータ複製ルールを削除します。例えば、 `id`が`table-45-r`であるルールを例に挙げます。以下のコマンドで削除します。 + 2. TiFlashに関連するすべてのデータ複製ルールを削除します。例えば、 `id`が`table-45-r`であるルールを例に挙げます。以下のコマンドで削除します。 ```shell curl -v -X DELETE http://:/pd/api/v1/config/rule/tiflash/table-45-r @@ -135,18 +135,18 @@ show warnings; TiDB クラスターを展開した後、 TiFlashレプリカの作成が継続的に失敗するか、 TiFlashレプリカが最初は正常に作成されたものの、一定期間後にすべてまたは一部のテーブルの作成に失敗した場合は、次の操作を実行して問題をトラブルシューティングできます。 -1. PDの[配置ルール](/configure-placement-rules.md)機能が有効になっているかどうかを確認します。v5.0以降、この機能はデフォルトで有効になっています。 +1. PDの[配置ルール](/configure-placement-rules.md)機能が有効になっているかどうかを確認します。v5.0以降、この機能はデフォルトで有効になっています。 ```shell echo 'config show replication' | /path/to/pd-ctl -u http://${pd-ip}:${pd-port} ``` - - `true`が返された場合は、次のステップに進みます。 - - `false`が返された場合は[配置ルール機能を有効にする](/configure-placement-rules.md#enable-placement-rules)を実行してから次のステップに進みます。 + - `true`が返された場合は、次のステップに進みます。 + - `false`が返された場合は[配置ルール機能を有効にする](/configure-placement-rules.md#enable-placement-rules)を実行してから次のステップに進みます。 -2. **TiFlash -Summary** Grafana パネルの**UpTime**メトリックをチェックして、 TiFlashプロセスが正常に動作しているかどうかを確認します。 +2. **TiFlash -Summary** Grafana パネルの**UpTime**メトリックをチェックして、 TiFlashプロセスが正常に動作しているかどうかを確認します。 -3. TiFlashとPD間の接続が正常かどうかを確認します。 +3. TiFlashとPD間の接続が正常かどうかを確認します。 ```shell tiup ctl:nightly pd -u http://${pd-ip}:${pd-port} store @@ -154,15 +154,15 @@ TiDB クラスターを展開した後、 TiFlashレプリカの作成が継続 TiFlashの`store.labels` `{"key": "engine", "value": "tiflash"}`のような情報が含まれています。この情報を確認することで、 TiFlashのインスタンスを確認できます。 -4. `default` ID を持つ配置ルールの`count`が正しいかどうかを確認します。 +4. `default` ID を持つ配置ルールの`count`が正しいかどうかを確認します。 ```shell tiup ctl:nightly pd -u http://${pd-ip}:${pd-port} config placement-rules show | grep -C 10 default ``` - - 値`count`がクラスター内の TiKV ノードの数以下の場合は、次の手順に進みます。 + - 値`count`がクラスター内の TiKV ノードの数以下の場合は、次の手順に進みます。 - - `count`の値がクラスタ内の TiKV ノードの数より大きい場合（例えば、テストクラスタに TiKV ノードが 1 つしかなく、 `count`が`3`の場合）、PD はTiFlashノードにリージョンピアを追加しません。この問題に対処するには、 `count`をクラスタ内の TiKV ノードの数以下の整数に変更してください。 + - `count`の値がクラスタ内の TiKV ノードの数より大きい場合（例えば、テストクラスタに TiKV ノードが 1 つしかなく、 `count`が`3`の場合）、PD はTiFlashノードにリージョンピアを追加しません。この問題に対処するには、 `count`をクラスタ内の TiKV ノードの数以下の整数に変更してください。 > **Note:** > @@ -182,25 +182,25 @@ TiDB クラスターを展開した後、 TiFlashレプリカの作成が継続 }' ``` -5. TiFlashノードの残りのディスク容量の割合を確認します。 +5. TiFlashノードの残りのディスク容量の割合を確認します。 TiFlashノードのディスク使用量が[`low-space-ratio`](/pd-configuration-file.md#low-space-ratio) （デフォルト： `0.8` ）を超えると、PDはディスク枯渇を防ぐため、そのノードへの新規データのスケジュールを停止します。すべてのTiFlashノードの空きディスク容量が不足している場合、PDはTiFlashへの新規リージョンピアのスケジュール設定ができないため、レプリカが利用できない状態（つまり、progress < 1）になります。 - - ディスク使用量が`low-space-ratio`以上になった場合、ディスク容量が不足していることを示します。この場合、以下のいずれかの対処を行ってください。 + - ディスク使用量が`low-space-ratio`以上になった場合、ディスク容量が不足していることを示します。この場合、以下のいずれかの対処を行ってください。 - - 値を`low-space-ratio`に変更すると、PD は新しいしきい値に達するまでTiFlashノードへのリージョンのスケジュールを再開できるようになります。 + - 値を`low-space-ratio`に変更すると、PD は新しいしきい値に達するまでTiFlashノードへのリージョンのスケジュールを再開できるようになります。 ``` tiup ctl:nightly pd -u http://${pd-ip}:${pd-port} config set low-space-ratio 0.9 ``` - - 新しいTiFlashノードをスケールアウトします。PD はTiFlashノード間でリージョンのバランスを自動的に取り、十分なディスク容量を持つTiFlashノードへのリージョンのスケジュールを再開します。 + - 新しいTiFlashノードをスケールアウトします。PD はTiFlashノード間でリージョンのバランスを自動的に取り、十分なディスク容量を持つTiFlashノードへのリージョンのスケジュールを再開します。 - - TiFlashノードディスクから、ログファイルやディレクトリ`${data}/flash/`の`space_placeholder_file`ファイルなどの不要なファイルを削除します。必要に応じて、 `tiflash-learner.toml` ～ `0MB`の`storage.reserve-space`を同時に設定し、 TiFlashサービスを一時的に再開します。 + - TiFlashノードディスクから、ログファイルやディレクトリ`${data}/flash/`の`space_placeholder_file`ファイルなどの不要なファイルを削除します。必要に応じて、 `tiflash-learner.toml` ～ `0MB`の`storage.reserve-space`を同時に設定し、 TiFlashサービスを一時的に再開します。 ディスク使用量が`low-space-ratio`未満の場合は、ディスク容量が通常通り利用可能であることを示します。次の手順に進みます。 -6. `down peer`があるかどうかを確認します。 +6. `down peer`があるかどうかを確認します。 ダウンしているピアが残っていると、レプリケーションが停止する可能性があります。以下のコマンドを実行して、 `down peer`が残っているかどうかを確認してください。 @@ -220,33 +220,33 @@ TiDB クラスターを展開した後、 TiFlashレプリカの作成が継続 TiFlashノードをデプロイし、 `ALTER TABLE ... SET TIFLASH REPLICA ...`を実行してレプリケーションを開始したにもかかわらず、データが複製されません。この場合、次の手順を実行することで問題を特定し、対処できます。 -1. `ALTER TABLE ... SET TIFLASH REPLICA ...`を実行してレプリケーションが成功したかどうかを確認し、出力を確認します。 +1. `ALTER TABLE ... SET TIFLASH REPLICA ...`を実行してレプリケーションが成功したかどうかを確認し、出力を確認します。 - - クエリがブロックされている場合は、 `SELECT * FROM information_schema.tiflash_replica`ステートメントを実行して、 TiFlashレプリカが作成されたかどうかを確認します。 - - [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)を通じて、DDL 文が期待どおりに実行されているかどうかを確認します。TiFlash レプリカ文のTiFlashをブロックする可能性のある他の DDL 文 ( `ADD INDEX`など) が実行中かどうかを確認します。 - - 実行中のTiFlashレプリカ ステートメントの変更をブロックする[`SHOW PROCESSLIST`](/sql-statements/sql-statement-show-processlist.md)を通じて、同じテーブルで DML ステートメントが実行されているかどうかを確認します。 - - ブロッキングステートメントが完了するかキャンセルされるまで待ってから、 TiFlashレプリカの設定を再度試してください。問題が発生しない場合は、次の手順に進みます。 + - クエリがブロックされている場合は、 `SELECT * FROM information_schema.tiflash_replica`ステートメントを実行して、 TiFlashレプリカが作成されたかどうかを確認します。 + - [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)を通じて、DDL 文が期待どおりに実行されているかどうかを確認します。TiFlash レプリカ文のTiFlashをブロックする可能性のある他の DDL 文 ( `ADD INDEX`など) が実行中かどうかを確認します。 + - 実行中のTiFlashレプリカ ステートメントの変更をブロックする[`SHOW PROCESSLIST`](/sql-statements/sql-statement-show-processlist.md)を通じて、同じテーブルで DML ステートメントが実行されているかどうかを確認します。 + - ブロッキングステートメントが完了するかキャンセルされるまで待ってから、 TiFlashレプリカの設定を再度試してください。問題が発生しない場合は、次の手順に進みます。 -2. TiFlashリージョンレプリケーションが正しく実行されているかどうかを確認します。 +2. TiFlashリージョンレプリケーションが正しく実行されているかどうかを確認します。 [`information_schema.tiflash_replica`](/information-schema/information-schema-tiflash-replica.md)テーブルをクエリして、 TiFlashレプリカのレプリケーションの進行状況を示す`PROGRESS`フィールドが変化しているかどうかを確認します。または、 `tidb.log`ファイルでキーワード`Tiflash replica is not available`を検索して、関連ログと対応する`progress`値を確認します。 - - レプリケーションの進行状況が変化する場合、 TiFlashレプリケーションは正常に機能しているものの、速度が遅くなっている可能性があります。最適化設定については、 [データの複製が遅い](#data-replication-is-slow)を参照してください。 - - レプリケーションの進行状況に変化がない場合、 TiFlashレプリケーションは異常です。次の手順に進んでください。 + - レプリケーションの進行状況が変化する場合、 TiFlashレプリケーションは正常に機能しているものの、速度が遅くなっている可能性があります。最適化設定については、 [データの複製が遅い](#data-replication-is-slow)を参照してください。 + - レプリケーションの進行状況に変化がない場合、 TiFlashレプリケーションは異常です。次の手順に進んでください。 -3. TiDB がテーブルの配置ルールを正常に作成したかどうかを確認します。 +3. TiDB がテーブルの配置ルールを正常に作成したかどうかを確認します。 TiDB DDL 所有者のログを検索し、TiDB が PD に配置ルールを追加するように通知したかどうかを確認します。 - - パーティション化されていないテーブルの場合は、 `ConfigureTiFlashPDForTable`検索します。 + - パーティション化されていないテーブルの場合は、 `ConfigureTiFlashPDForTable`検索します。 - - パーティション化されたテーブルの場合は、 `ConfigureTiFlashPDForPartitions`検索します。 + - パーティション化されたテーブルの場合は、 `ConfigureTiFlashPDForPartitions`検索します。 - - キーワードが見つかった場合は、次のステップに進みます。 + - キーワードが見つかった場合は、次のステップに進みます。 - - 見つからない場合は、該当するコンポーネントのログを収集し、[サポートを受けて](/support.md)ください。 + - 見つからない場合は、該当するコンポーネントのログを収集し、[サポートを受けて](/support.md)ください。 -4. PD がテーブルの配置ルールを設定しているかどうかを確認します。 +4. PD がテーブルの配置ルールを設定しているかどうかを確認します。 現在の PD 上のすべてのTiFlash配置ルールを表示するには、次のコマンドを実行します。 @@ -254,15 +254,15 @@ TiFlashノードをデプロイし、 `ALTER TABLE ... SET TIFLASH REPLICA ...` curl http://:/pd/api/v1/config/rules/group/tiflash ``` - - ID形式が`table--r`ルールが存在する場合、PDは配置ルールを正常に設定しています。次の手順に進みます。 - - そのようなルールが存在しない場合は、対応するコンポーネントのログを収集し、[サポートを受けて](/support.md)ください。 + - ID形式が`table--r`ルールが存在する場合、PDは配置ルールを正常に設定しています。次の手順に進みます。 + - そのようなルールが存在しない場合は、対応するコンポーネントのログを収集し、[サポートを受けて](/support.md)ください。 -5. PD が適切にスケジュールされているかどうかを確認します。 +5. PD が適切にスケジュールされているかどうかを確認します。 `pd.log`ファイルで`table--r`というキーワードを検索し、 `add operator`ようなスケジューリングログを見つけてください。または、Grafana の PD ダッシュボードの**Operator/Schedule オペレータ作成で**`add-rule-peer`オペレータが存在するかどうかを確認してください。また、Grafana の PD ダッシュボードで**Scheduler/Patrol リージョン時間の**値を確認することもできます。**Patrol リージョン時間**は、PD がすべてのリージョンをスキャンしてスケジューリング操作を生成するまでの所要時間です。値が大きいと、スケジューリングに遅延が発生する可能性があります。 - - `pd.log`キーワード`table--r`と`add operator`スケジュール ログが含まれている場合、または**Scheduler/Patrol リージョン時間**パネルの期間値が正常に表示される場合は、PD スケジュールが適切に機能していることを示します。 - - `add-rule-peer`スケジュールログが見つからない場合、または**パトロールリージョンの時間**が30分を超える場合、PD はスケジュールを正しく実行していないか、スケジュールの実行に時間がかかっています。TiDB、PD、およびTiFlash のログファイルを収集し、[サポートを受けて](/support.md)ください。 + - `pd.log`キーワード`table--r`と`add operator`スケジュール ログが含まれている場合、または**Scheduler/Patrol リージョン時間**パネルの期間値が正常に表示される場合は、PD スケジュールが適切に機能していることを示します。 + - `add-rule-peer`スケジュールログが見つからない場合、または**パトロールリージョンの時間**が30分を超える場合、PD はスケジュールを正しく実行していないか、スケジュールの実行に時間がかかっています。TiDB、PD、およびTiFlash のログファイルを収集し、[サポートを受けて](/support.md)ください。 上記の方法で問題を解決できない場合は、TiDB、PD、およびTiFlashログファイルを収集し、PingCAP またはコミュニティから[サポートを受けて](/support.md)ください。 @@ -270,16 +270,16 @@ TiFlashノードをデプロイし、 `ALTER TABLE ... SET TIFLASH REPLICA ...` 原因はさまざまです。次の手順を実行することで問題を解決できます。 -1. レプリケーションを高速化するには、 [TiFlashレプリケーションの高速化](/tiflash/create-tiflash-replicas.md#speed-up-tiflash-replication)に従います。 +1. レプリケーションを高速化するには、 [TiFlashレプリケーションの高速化](/tiflash/create-tiflash-replicas.md#speed-up-tiflash-replication)に従います。 -2. TiFlashの負荷を調整します。 +2. TiFlashの負荷を調整します。 TiFlashへの負荷が高すぎると、レプリケーションが遅くなる場合があります。Grafanaの**TiFlash -Summary**パネルで、 TiFlashインジケーターの負荷を確認できます。 - - `Applying snapshots Count` ： `TiFlash-summary` > `raft` > `Applying snapshots Count` - - `Snapshot Predecode Duration` ： `TiFlash-summary` > `raft` > `Snapshot Predecode Duration` - - `Snapshot Flush Duration` ： `TiFlash-summary` > `raft` > `Snapshot Flush Duration` - - `Write Stall Duration` ： `TiFlash-summary` > `Storage Write Stall` > `Write Stall Duration` - - `generate snapshot CPU` ： `TiFlash-Proxy-Details` > `Thread CPU` > `Region task worker pre-handle/generate snapshot CPU` + - `Applying snapshots Count` ： `TiFlash-summary` > `raft` > `Applying snapshots Count` + - `Snapshot Predecode Duration` ： `TiFlash-summary` > `raft` > `Snapshot Predecode Duration` + - `Snapshot Flush Duration` ： `TiFlash-summary` > `raft` > `Snapshot Flush Duration` + - `Write Stall Duration` ： `TiFlash-summary` > `Storage Write Stall` > `Write Stall Duration` + - `generate snapshot CPU` ： `TiFlash-Proxy-Details` > `Thread CPU` > `Region task worker pre-handle/generate snapshot CPU` サービスの優先順位に基づいて負荷を調整し、最適なパフォーマンスを実現します。 diff --git a/tiflash/tune-tiflash-performance.md b/tiflash/tune-tiflash-performance.md index 10e52f71e2b05..54b3827b6d835 100644 --- a/tiflash/tune-tiflash-performance.md +++ b/tiflash/tune-tiflash-performance.md @@ -15,13 +15,13 @@ summary: マシン リソースを計画し、TiDB パラメータを調整す このセクションでは、次のような TiDB パラメータを調整してTiFlash のパフォーマンスを向上させる方法について説明します。 -- [MPPモードを強制的に有効にする](#forcibly-enable-the-mpp-mode) -- [集計関数を`Join`または`Union`前の位置へプッシュダウンします](#push-down-aggregate-functions-to-a-position-before-join-or-union) -- [`Distinct`最適化を有効にする](#enable-distinct-optimization) -- [`ALTER TABLE ... COMPACT`ステートメントを使用してデータを圧縮する](#compact-data-using-the-alter-table--compact-statement) -- [シャッフルハッシュ結合をブロードキャストハッシュ結合に置き換える](#replace-shuffled-hash-join-with-broadcast-hash-join) -- [実行同時実行性を高める](#set-a-greater-execution-concurrency) -- [`tiflash_fine_grained_shuffle_stream_count`を設定する](#configure-tiflash_fine_grained_shuffle_stream_count) +- [MPPモードを強制的に有効にする](#forcibly-enable-the-mpp-mode) +- [集計関数を`Join`または`Union`前の位置へプッシュダウンします](#push-down-aggregate-functions-to-a-position-before-join-or-union) +- [`Distinct`最適化を有効にする](#enable-distinct-optimization) +- [`ALTER TABLE ... COMPACT`ステートメントを使用してデータを圧縮する](#compact-data-using-the-alter-table--compact-statement) +- [シャッフルハッシュ結合をブロードキャストハッシュ結合に置き換える](#replace-shuffled-hash-join-with-broadcast-hash-join) +- [実行同時実行性を高める](#set-a-greater-execution-concurrency) +- [`tiflash_fine_grained_shuffle_stream_count`を設定する](#configure-tiflash_fine_grained_shuffle_stream_count) ### MPPモードを強制的に有効にする {#forcibly-enable-the-mpp-mode} @@ -231,13 +231,13 @@ ALTER TABLE employees COMPACT PARTITION pNorth, pEast TIFLASH REPLICA; 小さなテーブルでの`Join`操作の場合、ブロードキャスト ハッシュ結合アルゴリズムにより大きなテーブルの転送を回避できるため、コンピューティング パフォーマンスが向上します。 -- 変数[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50)は、ブロードキャストハッシュ結合アルゴリズムを使用するかどうかを制御します。テーブルサイズ（単位：バイト）がこの変数の値より小さい場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 +- 変数[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50)は、ブロードキャストハッシュ結合アルゴリズムを使用するかどうかを制御します。テーブルサイズ（単位：バイト）がこの変数の値より小さい場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 ```sql set @@tidb_broadcast_join_threshold_size = 2000000; ``` -- 変数[`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50)は、ブロードキャストハッシュ結合アルゴリズムを使用するかどうかも制御します。結合操作のオブジェクトがサブクエリに属する場合、オプティマイザはサブクエリの結果セットのサイズを推定できません。この場合、サイズは結果セットの行数によって決定されます。サブクエリの推定行数がこの変数の値より少ない場合、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 +- 変数[`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50)は、ブロードキャストハッシュ結合アルゴリズムを使用するかどうかも制御します。結合操作のオブジェクトがサブクエリに属する場合、オプティマイザはサブクエリの結果セットのサイズを推定できません。この場合、サイズは結果セットの行数によって決定されます。サブクエリの推定行数がこの変数の値より少ない場合、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 ```sql set @@tidb_broadcast_join_threshold_count = 100000; diff --git a/tiflash/use-fastscan.md b/tiflash/use-fastscan.md index 0b3ca4961e5ef..204fbd6dca14c 100644 --- a/tiflash/use-fastscan.md +++ b/tiflash/use-fastscan.md @@ -50,36 +50,46 @@ TiFlash は古いデータの圧縮をバックグラウンドで自動的に開 デフォルトでは、セッションレベルとグローバルレベルで変数は`tiflash_fastscan=OFF`設定されており、FastScan機能は無効です。変数情報を表示するには、次のステートメントを使用します。 - show variables like 'tiflash_fastscan'; +``` +show variables like 'tiflash_fastscan'; - +------------------+-------+ - | Variable_name | Value | - +------------------+-------+ - | tiflash_fastscan | OFF | - +------------------+-------+ ++------------------+-------+ +| Variable_name | Value | ++------------------+-------+ +| tiflash_fastscan | OFF | ++------------------+-------+ +``` - show global variables like 'tiflash_fastscan'; +``` +show global variables like 'tiflash_fastscan'; - +------------------+-------+ - | Variable_name | Value | - +------------------+-------+ - | tiflash_fastscan | OFF | - +------------------+-------+ ++------------------+-------+ +| Variable_name | Value | ++------------------+-------+ +| tiflash_fastscan | OFF | ++------------------+-------+ +``` 変数`tiflash_fastscan`セッションレベルとグローバルレベルで設定できます。現在のセッションでFastScanを有効にするには、次のステートメントを使用します。 - set session tiflash_fastscan=ON; +``` +set session tiflash_fastscan=ON; +``` グローバルレベルで`tiflash_fastscan`設定することもできます。新しい設定は新しいセッションで有効になりますが、現在のセッションと以前のセッションには適用されません。また、新しいセッションでは、セッションレベルとグローバルレベルの両方の`tiflash_fastscan`に新しい値が設定されます。 - set global tiflash_fastscan=ON; +``` +set global tiflash_fastscan=ON; +``` 次のステートメントを使用して FastScan を無効にすることができます。 - set session tiflash_fastscan=OFF; - set global tiflash_fastscan=OFF; +``` +set session tiflash_fastscan=OFF; +set global tiflash_fastscan=OFF; +``` ## FastScanの仕組み {#mechanism-of-fastscan} @@ -87,9 +97,9 @@ TiFlashのストレージレイヤーのデータは、デルタレイヤーと デフォルトでは、FastScan は有効になっておらず、TableScan オペレーターは次の手順でデータを処理します。 -1. データの読み取り: Deltaレイヤーと Stableレイヤーに個別のデータ ストリームを作成し、それぞれのデータを読み取ります。 -2. ソートマージ: 手順 1 で作成したデータ ストリームをマージします。次に、(主キー列、タイムスタンプ列) の順序でソートしたデータを返します。 -3. 範囲フィルター: データ範囲に従って、手順 2 で生成されたデータをフィルターし、データを返します。 -4. MVCC +カラムフィルター: 手順 3 で生成されたデータを MVCC (つまり、主キー列とタイムスタンプ列に従ってデータ バージョンをフィルター処理) および列 (つまり、不要な列をフィルター処理) を通じてフィルター処理し、データを返します。 +1. データの読み取り: Deltaレイヤーと Stableレイヤーに個別のデータ ストリームを作成し、それぞれのデータを読み取ります。 +2. ソートマージ: 手順 1 で作成したデータ ストリームをマージします。次に、(主キー列、タイムスタンプ列) の順序でソートしたデータを返します。 +3. 範囲フィルター: データ範囲に従って、手順 2 で生成されたデータをフィルターし、データを返します。 +4. MVCC +カラムフィルター: 手順 3 で生成されたデータを MVCC (つまり、主キー列とタイムスタンプ列に従ってデータ バージョンをフィルター処理) および列 (つまり、不要な列をフィルター処理) を通じてフィルター処理し、データを返します。 FastScanは、データの一貫性をある程度犠牲にすることで、クエリ速度を向上させます。通常のスキャンプロセスにおけるステップ2とステップ4のMVCC部分はFastScanでは省略されるため、クエリパフォーマンスが向上します。 diff --git a/tiflash/use-tidb-to-read-tiflash.md b/tiflash/use-tidb-to-read-tiflash.md index 64899a8b9b3f9..41cd80bb41228 100644 --- a/tiflash/use-tidb-to-read-tiflash.md +++ b/tiflash/use-tidb-to-read-tiflash.md @@ -54,7 +54,7 @@ explain analyze select count(*) from test.t; 次の 2 つの構成レベルでエンジンを指定できます。 -- TiDBインスタンスレベル、つまりINSTANCEレベル。TiDB設定ファイルに以下の設定項目を追加します。 +- TiDBインスタンスレベル、つまりINSTANCEレベル。TiDB設定ファイルに以下の設定項目を追加します。 ``` [isolation-read] @@ -63,7 +63,7 @@ explain analyze select count(*) from test.t; **INSTANCE レベルのデフォルト設定は`["tikv", "tidb", "tiflash"]`です。** -- SESSIONレベル。設定するには次のステートメントを使用します。 +- SESSIONレベル。設定するには次のステートメントを使用します。 ```sql set @@session.tidb_isolation_read_engines = "engine list separated by commas"; @@ -131,7 +131,7 @@ select /*+ read_from_storage(tiflash[alias_a,alias_b]) */ ... from table_name_1 > **Note:** > -> - v4.0.3 より前では、読み取り専用でない SQL ステートメント (たとえば、 `INSERT INTO ... SELECT` 、 `SELECT ... FOR UPDATE` 、 `UPDATE ...` 、 `DELETE ...` ) でTiFlashレプリカから読み取る動作は未定義です。 -> - v4.0.3 から v6.2.0 までのバージョンでは、TiDB はデータの正確性を保証するために、非読み取り専用 SQL 文のTiFlashレプリカを内部的に無視します。つまり、 [スマートな選択](#smart-selection)の場合、TiDB はTiFlash以外のレプリカを自動的に選択します。 [エンジン分離](#engine-isolation) （ TiFlashレプリカ**のみを**指定）の場合、TiDB はエラーを報告します。 [手動ヒント](#manual-hint)の場合、TiDB はヒントを無視します。 -> - バージョン v6.3.0 から v7.0.0 では、 TiFlashレプリカが有効になっている場合、 [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630)変数を使用して、TiDB が非読み取り専用 SQL ステートメントにTiFlashレプリカを使用するかどうかを制御できます。 -> - v7.1.0 以降、 TiFlashレプリカが有効になっていて、現在のセッションの[SQLモード](/sql-mode.md)が厳密でない場合 (つまり、 `sql_mode`値に`STRICT_TRANS_TABLES`または`STRICT_ALL_TABLES`が含まれていない場合)、TiDB はコスト見積もりに基づいて、非読み取り専用 SQL ステートメントにTiFlashレプリカを使用するかどうかを自動的に決定します。 +> - v4.0.3 より前では、読み取り専用でない SQL ステートメント (たとえば、 `INSERT INTO ... SELECT` 、 `SELECT ... FOR UPDATE` 、 `UPDATE ...` 、 `DELETE ...` ) でTiFlashレプリカから読み取る動作は未定義です。 +> - v4.0.3 から v6.2.0 までのバージョンでは、TiDB はデータの正確性を保証するために、非読み取り専用 SQL 文のTiFlashレプリカを内部的に無視します。つまり、 [スマートな選択](#smart-selection)の場合、TiDB はTiFlash以外のレプリカを自動的に選択します。 [エンジン分離](#engine-isolation) （ TiFlashレプリカ**のみを**指定）の場合、TiDB はエラーを報告します。 [手動ヒント](#manual-hint)の場合、TiDB はヒントを無視します。 +> - バージョン v6.3.0 から v7.0.0 では、 TiFlashレプリカが有効になっている場合、 [`tidb_enable_tiflash_read_for_write_stmt`](/system-variables.md#tidb_enable_tiflash_read_for_write_stmt-new-in-v630)変数を使用して、TiDB が非読み取り専用 SQL ステートメントにTiFlashレプリカを使用するかどうかを制御できます。 +> - v7.1.0 以降、 TiFlashレプリカが有効になっていて、現在のセッションの[SQLモード](/sql-mode.md)が厳密でない場合 (つまり、 `sql_mode`値に`STRICT_TRANS_TABLES`または`STRICT_ALL_TABLES`が含まれていない場合)、TiDB はコスト見積もりに基づいて、非読み取り専用 SQL ステートメントにTiFlashレプリカを使用するかどうかを自動的に決定します。 diff --git a/tiflash/use-tiflash-mpp-mode.md b/tiflash/use-tiflash-mpp-mode.md index d5f30ac63710e..18fa762e6898a 100644 --- a/tiflash/use-tiflash-mpp-mode.md +++ b/tiflash/use-tiflash-mpp-mode.md @@ -109,9 +109,9 @@ explain select count(*) from customer c join nation n on c.c_nationkey=n.n_natio TiFlash は、ブロードキャスト ハッシュ結合を使用するかどうかを制御する次の 3 つのグローバル/セッション変数を提供します。 -- [`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50) : 値の単位はバイトです。テーブルサイズ（バイト単位）が変数の値より小さい場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 -- [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50) : 値の単位は行です。結合操作のオブジェクトがサブクエリに属する場合、オプティマイザはサブクエリの結果セットのサイズを推定できないため、結果セットの行数によってサイズが決定されます。サブクエリの推定行数がこの変数の値より少ない場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 -- [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-new-in-v710) : ネットワーク転送のオーバーヘッドが最小となるアルゴリズムを使用するかどうかを制御します。この変数を有効にすると、TiDBはネットワークで交換されるデータのサイズをそれぞれ`Broadcast Hash Join`と`Shuffled Hash Join`で推定し、サイズが小さい方を選択します。この変数を有効にすると、 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50)と[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50)無効になります。 +- [`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50) : 値の単位はバイトです。テーブルサイズ（バイト単位）が変数の値より小さい場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 +- [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50) : 値の単位は行です。結合操作のオブジェクトがサブクエリに属する場合、オプティマイザはサブクエリの結果セットのサイズを推定できないため、結果セットの行数によってサイズが決定されます。サブクエリの推定行数がこの変数の値より少ない場合は、ブロードキャストハッシュ結合アルゴリズムが使用されます。それ以外の場合は、シャッフルハッシュ結合アルゴリズムが使用されます。 +- [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-new-in-v710) : ネットワーク転送のオーバーヘッドが最小となるアルゴリズムを使用するかどうかを制御します。この変数を有効にすると、TiDBはネットワークで交換されるデータのサイズをそれぞれ`Broadcast Hash Join`と`Shuffled Hash Join`で推定し、サイズが小さい方を選択します。この変数を有効にすると、 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50)と[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50)無効になります。 ## MPP モードでパーティション テーブルにアクセスする {#access-partitioned-tables-in-the-mpp-mode} diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 731ff4c2fbcfa..29bde8754247f 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -19,295 +19,295 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### `abort-on-panic` {#abort-on-panic} -- TiKVがパニックを起こした際に、 `abort()`を呼び出してプロセスを終了させるかどうかを設定します。このオプションは、TiKVがシステムにコアダンプファイルの生成を許可するかどうかに影響します。 +- TiKVがパニックを起こした際に、 `abort()`を呼び出してプロセスを終了させるかどうかを設定します。このオプションは、TiKVがシステムにコアダンプファイルの生成を許可するかどうかに影響します。 - - この構成項目の値が`false`の場合、TiKV がパニックを起こすと、 `exit()`を呼び出してプロセスを終了します。 - - この設定項目の値が`true`の場合、TiKV がパニックを起こすと、TiKV は`abort()`を呼び出してプロセスを終了します。このとき、TiKV は終了時にコアダンプファイルを生成することをシステムに許可します。コアダンプファイルを生成するには、コアダンプに関連するシステム設定も実行する必要があります (たとえば、 `ulimit -c`コマンドを使用してコアダンプファイルのサイズ制限を設定したり、コアダンプパスを設定したりします。オペレーティングシステムによって関連する設定が異なります)。コアダンプファイルがディスク容量を過剰に占有して TiKV のディスク容量が不足するのを避けるため、コアダンプ生成パスを TiKV データのディスクパーティションとは異なるディスクパーティションに設定することをお勧めします。 + - この構成項目の値が`false`の場合、TiKV がパニックを起こすと、 `exit()`を呼び出してプロセスを終了します。 + - この設定項目の値が`true`の場合、TiKV がパニックを起こすと、TiKV は`abort()`を呼び出してプロセスを終了します。このとき、TiKV は終了時にコアダンプファイルを生成することをシステムに許可します。コアダンプファイルを生成するには、コアダンプに関連するシステム設定も実行する必要があります (たとえば、 `ulimit -c`コマンドを使用してコアダンプファイルのサイズ制限を設定したり、コアダンプパスを設定したりします。オペレーティングシステムによって関連する設定が異なります)。コアダンプファイルがディスク容量を過剰に占有して TiKV のディスク容量が不足するのを避けるため、コアダンプ生成パスを TiKV データのディスクパーティションとは異なるディスクパーティションに設定することをお勧めします。 -- デフォルト値: `false` +- デフォルト値: `false` ### `slow-log-file` {#slow-log-file} -- スローログを保存するファイル -- この設定項目が設定されていないが、 `log.file.filename`が設定されている場合、スローログは`log.file.filename`で指定されたログファイルに出力されます。 -- `slow-log-file`も`log.file.filename`も設定されていない場合、デフォルトではすべてのログが「stderr」に出力されます。 -- 両方の設定項目が設定されている場合、通常のログは`log.file.filename`で指定されたログファイルに出力され、スローログは`slow-log-file`で設定されたログファイルに出力されます。 -- デフォルト値: `""` +- スローログを保存するファイル +- この設定項目が設定されていないが、 `log.file.filename`が設定されている場合、スローログは`log.file.filename`で指定されたログファイルに出力されます。 +- `slow-log-file`も`log.file.filename`も設定されていない場合、デフォルトではすべてのログが「stderr」に出力されます。 +- 両方の設定項目が設定されている場合、通常のログは`log.file.filename`で指定されたログファイルに出力され、スローログは`slow-log-file`で設定されたログファイルに出力されます。 +- デフォルト値: `""` ### `slow-log-threshold` {#slow-log-threshold} -- 処理時間が遅い場合のログ出力のしきい値。処理時間がこのしきい値を超えると、処理時間が遅い場合のログが出力されます。 -- デフォルト値: `"1s"` +- 処理時間が遅い場合のログ出力のしきい値。処理時間がこのしきい値を超えると、処理時間が遅い場合のログが出力されます。 +- デフォルト値: `"1s"` ### `memory-usage-limit` {#memory-usage-limit} -- TiKVインスタンスのメモリ使用量の上限。TiKVのメモリ使用量がこのしきい値に近づくと、内部キャッシュが削除されてメモリが解放されます。 -- ほとんどの場合、TiKVインスタンスはシステムメモリ全体の75%を使用するように設定されているため、この設定項目を明示的に指定する必要はありません。残りの25%のメモリはOSページキャッシュ用に予約されています。詳細は[`storage.block-cache.capacity`](#capacity)を参照してください。 -- 単一の物理マシン上に複数の TiKV ノードをデプロイする場合でも、この構成項目を設定する必要はありません。この場合、TiKV インスタンスは`5/3 * block-cache.capacity`のメモリを使用します。 -- システムメモリ容量ごとのデフォルト値は以下のとおりです。 +- TiKVインスタンスのメモリ使用量の上限。TiKVのメモリ使用量がこのしきい値に近づくと、内部キャッシュが削除されてメモリが解放されます。 +- ほとんどの場合、TiKVインスタンスはシステムメモリ全体の75%を使用するように設定されているため、この設定項目を明示的に指定する必要はありません。残りの25%のメモリはOSページキャッシュ用に予約されています。詳細は[`storage.block-cache.capacity`](#capacity)を参照してください。 +- 単一の物理マシン上に複数の TiKV ノードをデプロイする場合でも、この構成項目を設定する必要はありません。この場合、TiKV インスタンスは`5/3 * block-cache.capacity`のメモリを使用します。 +- システムメモリ容量ごとのデフォルト値は以下のとおりです。 - - システム=8G ブロックキャッシュ=3.6G メモリ使用量制限=6G ページキャッシュ=2G - - システム=16G ブロックキャッシュ=7.2G メモリ使用量制限=12G ページキャッシュ=4G - - システム=32G ブロックキャッシュ=14.4G メモリ使用量制限=24G ページキャッシュ=8G + - システム=8G ブロックキャッシュ=3.6G メモリ使用量制限=6G ページキャッシュ=2G + - システム=16G ブロックキャッシュ=7.2G メモリ使用量制限=12G ページキャッシュ=4G + - システム=32G ブロックキャッシュ=14.4G メモリ使用量制限=24G ページキャッシュ=8G ## log New in v5.4.0 {#log-new-in-v540} -- ログに関連するコンフィグレーション項目。 +- ログに関連するコンフィグレーション項目。 -- バージョン 5.4.0 以降、TiKV と TiDB のログ設定項目を統一するため、TiKV は以前の設定項目`log-rotation-timespan`を非推奨とし、 `log-level` 、 `log-format` 、 `log-file` 、 `log-rotation-size`を以下の項目に変更します。古い設定項目のみを設定し、その値をデフォルト値以外に設定した場合、古い項目は新しい項目と互換性があります。古い設定項目と新しい設定項目の両方を設定した場合、新しい項目が有効になります。 +- バージョン 5.4.0 以降、TiKV と TiDB のログ設定項目を統一するため、TiKV は以前の設定項目`log-rotation-timespan`を非推奨とし、 `log-level` 、 `log-format` 、 `log-file` 、 `log-rotation-size`を以下の項目に変更します。古い設定項目のみを設定し、その値をデフォルト値以外に設定した場合、古い項目は新しい項目と互換性があります。古い設定項目と新しい設定項目の両方を設定した場合、新しい項目が有効になります。 ### `level` v5.4.0 の新機能 {#level-new-in-v540} -- ログレベル -- オプション値: `"debug"` 、 `"info"` 、 `"warn"` 、 `"error"` 、 `"fatal"` -- デフォルト値: `"info"` +- ログレベル +- オプション値: `"debug"` 、 `"info"` 、 `"warn"` 、 `"error"` 、 `"fatal"` +- デフォルト値: `"info"` ### `format` v5.4.0 の新機能 {#format-new-in-v540} -- ログ形式 -- オプション値: `"json"` 、 `"text"` -- デフォルト値: `"text"` +- ログ形式 +- オプション値: `"json"` 、 `"text"` +- デフォルト値: `"text"` ### `enable-timestamp` v5.4.0で追加 {#enable-timestamp-new-in-v540} -- ログ内のタイムスタンプを有効にするか無効にするかを決定します。 -- オプション値: `true` 、 `false` -- デフォルト値: `true` +- ログ内のタイムスタンプを有効にするか無効にするかを決定します。 +- オプション値: `true` 、 `false` +- デフォルト値: `true` ## log.file v5.4.0で追加 {#logfile-new-in-v540} -- ログファイルに関連するコンフィグレーション項目。 +- ログファイルに関連するコンフィグレーション項目。 ### `filename` v5.4.0 で追加 {#filename-new-in-v540} -- ログファイル。この設定項目が設定されていない場合、ログはデフォルトで「stderr」に出力されます。この設定項目が設定されている場合、ログは対応するファイルに出力されます。 -- デフォルト値: `""` +- ログファイル。この設定項目が設定されていない場合、ログはデフォルトで「stderr」に出力されます。この設定項目が設定されている場合、ログは対応するファイルに出力されます。 +- デフォルト値: `""` ### `max-size` v5.4.0の新機能 {#max-size-new-in-v540} -- 単一ログファイルの最大サイズ。ファイルサイズがこの設定項目で設定された値よりも大きい場合、システムは自動的に単一ファイルを複数のファイルに分割します。 -- デフォルト値: `300` -- 最大値: `4096` -- 単位: MiB +- 単一ログファイルの最大サイズ。ファイルサイズがこの設定項目で設定された値よりも大きい場合、システムは自動的に単一ファイルを複数のファイルに分割します。 +- デフォルト値: `300` +- 最大値: `4096` +- 単位: MiB ### `max-days` （v5.4.0の新機能） {#max-days-new-in-v540} -- TiKVがログファイルを保持する最大日数。 - - 設定項目が設定されていない場合、またはその値がデフォルト値`0`に設定されている場合、TiKV はログファイルをクリーンアップしません。 - - パラメータが`0`以外の値に設定されている場合、TiKV は`max-days`の後に期限切れのログファイルをクリーンアップします。 -- デフォルト値: `0` +- TiKVがログファイルを保持する最大日数。 + - 設定項目が設定されていない場合、またはその値がデフォルト値`0`に設定されている場合、TiKV はログファイルをクリーンアップしません。 + - パラメータが`0`以外の値に設定されている場合、TiKV は`max-days`の後に期限切れのログファイルをクリーンアップします。 +- デフォルト値: `0` ### `max-backups` v5.4.0の新機能 {#max-backups-new-in-v540} -- TiKVが保持するログファイルの最大数。 - - 設定項目が設定されていない場合、またはその値がデフォルト値`0`に設定されている場合、TiKV はすべてのログ ファイルを保持します。 - - 設定項目が`0`以外の値に設定されている場合、TiKV は`max-backups`で指定された数までの古いログファイルを保持します。たとえば、値が`7`に設定されている場合、TiKV は最大 7 つの古いログファイルを保持します。 -- デフォルト値: `0` +- TiKVが保持するログファイルの最大数。 + - 設定項目が設定されていない場合、またはその値がデフォルト値`0`に設定されている場合、TiKV はすべてのログ ファイルを保持します。 + - 設定項目が`0`以外の値に設定されている場合、TiKV は`max-backups`で指定された数までの古いログファイルを保持します。たとえば、値が`7`に設定されている場合、TiKV は最大 7 つの古いログファイルを保持します。 +- デフォルト値: `0` ## server {#server} -- サーバーに関連するコンフィグレーション項目。 +- サーバーに関連するコンフィグレーション項目。 ### `addr` {#addr} -- リスニングIPアドレスとリスニングポート -- デフォルト値: `"127.0.0.1:20160"` +- リスニングIPアドレスとリスニングポート +- デフォルト値: `"127.0.0.1:20160"` ### `advertise-addr` {#advertise-addr} -- クライアント通信のためのリスニングアドレスを宣伝する -- この設定項目が設定されていない場合、 `addr`の値が使用されます。 -- デフォルト値: `""` +- クライアント通信のためのリスニングアドレスを宣伝する +- この設定項目が設定されていない場合、 `addr`の値が使用されます。 +- デフォルト値: `""` ### `status-addr` {#status-addr} -- 構成アイテムは`HTTP`アドレスを介して TiKV ステータスを直接報告します。 +- 構成アイテムは`HTTP`アドレスを介して TiKV ステータスを直接報告します。 > **Warning:** > > この値が一般に公開されると、TiKVサーバーの状態情報が漏洩する可能性があります。 -- ステータス アドレスを無効にするには、値を`""`に設定します。 +- ステータス アドレスを無効にするには、値を`""`に設定します。 -- デフォルト値: `"127.0.0.1:20180"` +- デフォルト値: `"127.0.0.1:20180"` ### `status-thread-pool-size` {#status-thread-pool-size} -- `HTTP` APIサービスのワーカースレッド数 -- デフォルト値: `1` -- 最小値: `1` +- `HTTP` APIサービスのワーカースレッド数 +- デフォルト値: `1` +- 最小値: `1` ### `grpc-compression-type` {#grpc-compression-type} -- gRPCメッセージの圧縮アルゴリズム。TiKVノード間のgRPCメッセージに影響します。v6.5.11、v7.1.6、v7.5.3、v8.1.1、v8.2.0以降では、TiKVからTiDBに送信されるgRPC応答メッセージにも影響します。 +- gRPCメッセージの圧縮アルゴリズム。TiKVノード間のgRPCメッセージに影響します。v6.5.11、v7.1.6、v7.5.3、v8.1.1、v8.2.0以降では、TiKVからTiDBに送信されるgRPC応答メッセージにも影響します。 -- オプション値: `"none"` 、 `"deflate"` 、 `"gzip"` +- オプション値: `"none"` 、 `"deflate"` 、 `"gzip"` > **Note:** > > TiDB は`"deflate"`をサポートしていません。したがって、TiKV から TiDB に送信される gRPC 応答メッセージを圧縮する場合は、この設定項目を`"gzip"`に設定してください。 -- デフォルト値: `"none"` +- デフォルト値: `"none"` ### `grpc-concurrency` {#grpc-concurrency} -- gRPC ワーカー スレッドの数。 gRPC スレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- gRPC ワーカー スレッドの数。 gRPC スレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 -- デフォルト値: +- デフォルト値: - - v8.5.4以降、デフォルト値は`grpc-raft-conn-num * 3 + 2`に調整され、 [`grpc-raft-conn-num`](#grpc-raft-conn-num)の値に基づいて計算されます。たとえば、CPUコア数が8の場合、 `grpc-raft-conn-num`のデフォルト値は1になります。したがって、 `grpc-concurrency`のデフォルト値は`1 * 3 + 2 = 5`になります。 - - v8.5.3以前のバージョンでは、デフォルト値は`5`です。 + - v8.5.4以降、デフォルト値は`grpc-raft-conn-num * 3 + 2`に調整され、 [`grpc-raft-conn-num`](#grpc-raft-conn-num)の値に基づいて計算されます。たとえば、CPUコア数が8の場合、 `grpc-raft-conn-num`のデフォルト値は1になります。したがって、 `grpc-concurrency`のデフォルト値は`1 * 3 + 2 = 5`になります。 + - v8.5.3以前のバージョンでは、デフォルト値は`5`です。 -- 最小値: `1` +- 最小値: `1` ### `grpc-concurrent-stream` {#grpc-concurrent-stream} -- gRPCストリームで許可される同時リクエストの最大数 -- デフォルト値: `1024` -- 最小値: `1` +- gRPCストリームで許可される同時リクエストの最大数 +- デフォルト値: `1024` +- 最小値: `1` ### `grpc-memory-pool-quota` {#grpc-memory-pool-quota} -- gRPCが使用できるメモリサイズを制限します。 -- デフォルト値：制限なし -- メモリ不足が発生した場合に備えて、メモリを制限してください。ただし、使用量を制限すると、処理が停止する可能性があることに注意してください。 +- gRPCが使用できるメモリサイズを制限します。 +- デフォルト値：制限なし +- メモリ不足が発生した場合に備えて、メモリを制限してください。ただし、使用量を制限すると、処理が停止する可能性があることに注意してください。 ### `grpc-raft-conn-num` {#grpc-raft-conn-num} -- Raft通信におけるTiKVノード間の最大接続数 +- Raft通信におけるTiKVノード間の最大接続数 -- デフォルト値: +- デフォルト値: - - バージョン8.5.4以降、デフォルト値は`MAX(1, MIN(4, CPU cores / 8))`に調整されます。ここで`MIN(4, CPU cores / 8)`は、CPUコア数が32以上の場合、デフォルトの最大接続数が4であることを示します。 - - v8.5.3以前のバージョンでは、デフォルト値は`1`です。 + - バージョン8.5.4以降、デフォルト値は`MAX(1, MIN(4, CPU cores / 8))`に調整されます。ここで`MIN(4, CPU cores / 8)`は、CPUコア数が32以上の場合、デフォルトの最大接続数が4であることを示します。 + - v8.5.3以前のバージョンでは、デフォルト値は`1`です。 -- 最小値: `1` +- 最小値: `1` ### `max-grpc-send-msg-len` {#max-grpc-send-msg-len} -- 送信可能なgRPCメッセージの最大長を設定します。 -- デフォルト値: `10485760` -- 単位：バイト -- 最大値: `2147483647` +- 送信可能なgRPCメッセージの最大長を設定します。 +- デフォルト値: `10485760` +- 単位：バイト +- 最大値: `2147483647` ### `grpc-stream-initial-window-size` {#grpc-stream-initial-window-size} -- gRPCストリームのウィンドウサイズ -- デフォルト値: `2MiB` -- 単位：KiB｜MiB｜GiB -- 最小値: `"1KiB"` +- gRPCストリームのウィンドウサイズ +- デフォルト値: `2MiB` +- 単位：KiB｜MiB｜GiB +- 最小値: `"1KiB"` ### `grpc-keepalive-time` {#grpc-keepalive-time} -- そのgRPCが`keepalive` Pingメッセージを送信する時間間隔 -- デフォルト値: `"10s"` -- 最小値: `"1s"` +- そのgRPCが`keepalive` Pingメッセージを送信する時間間隔 +- デフォルト値: `"10s"` +- 最小値: `"1s"` ### `grpc-keepalive-timeout` {#grpc-keepalive-timeout} -- gRPCストリームのタイムアウトを無効にします -- デフォルト値: `"3s"` -- 最小値: `"1s"` +- gRPCストリームのタイムアウトを無効にします +- デフォルト値: `"3s"` +- 最小値: `"1s"` ### `graceful-shutdown-timeout` （v8.5.5の新機能） {#graceful-shutdown-timeout-new-in-v855} -- TiKVの正常なシャットダウンのタイムアウト期間を指定します。 - - この値が`0s`より大きい場合、TiKV はシャットダウンする前に、指定されたタイムアウト時間内にこのノード上のすべてのリーダーを他の TiKV ノードに転送しようとします。タイムアウトに達した時点で転送されていないリーダーがまだ存在する場合、TiKV は残りのリーダー転送をスキップし、直接シャットダウン処理に進みます。 - - この値が`0s`の場合、TiKV の正常シャットダウンは無効になります。 -- デフォルト値: `"20s"` -- 最小値: `"0s"` +- TiKVの正常なシャットダウンのタイムアウト期間を指定します。 + - この値が`0s`より大きい場合、TiKV はシャットダウンする前に、指定されたタイムアウト時間内にこのノード上のすべてのリーダーを他の TiKV ノードに転送しようとします。タイムアウトに達した時点で転送されていないリーダーがまだ存在する場合、TiKV は残りのリーダー転送をスキップし、直接シャットダウン処理に進みます。 + - この値が`0s`の場合、TiKV の正常シャットダウンは無効になります。 +- デフォルト値: `"20s"` +- 最小値: `"0s"` ### `concurrent-send-snap-limit` {#concurrent-send-snap-limit} -- 同時に送信できるスナップショットの最大数 -- デフォルト値: `32` -- 最小値: `1` +- 同時に送信できるスナップショットの最大数 +- デフォルト値: `32` +- 最小値: `1` ### `concurrent-recv-snap-limit` {#concurrent-recv-snap-limit} -- 同時に受信できるスナップショットの最大数 -- デフォルト値: `32` -- 最小値: `1` +- 同時に受信できるスナップショットの最大数 +- デフォルト値: `32` +- 最小値: `1` ### `end-point-recursion-limit` {#end-point-recursion-limit} -- TiKVがコプロセッサーDAG式をデコードする際に許可される再帰レベルの最大数 -- デフォルト値: `1000` -- 最小値: `1` +- TiKVがコプロセッサーDAG式をデコードする際に許可される再帰レベルの最大数 +- デフォルト値: `1000` +- 最小値: `1` ### `end-point-request-max-handle-duration` {#end-point-request-max-handle-duration} -- TiDBからTiKVへの処理タスクのプッシュダウン要求に許容される最長期間 -- デフォルト値: `"60s"` -- 最小値: `"1s"` +- TiDBからTiKVへの処理タスクのプッシュダウン要求に許容される最長期間 +- デフォルト値: `"60s"` +- 最小値: `"1s"` ### `end-point-memory-quota` v8.2.0 の新機能 {#end-point-memory-quota-new-in-v820} -- TiKVコプロセッサーのリクエストが使用できるメモリの最大容量。この制限を超えると、以降のコプロセッサーのリクエストは「サーバーがビジー状態です」というエラーで拒否されます。 -- デフォルト値：システムメモリ全体の12.5%と500MiBのうち大きい方の値。 +- TiKVコプロセッサーのリクエストが使用できるメモリの最大容量。この制限を超えると、以降のコプロセッサーのリクエストは「サーバーがビジー状態です」というエラーで拒否されます。 +- デフォルト値：システムメモリ全体の12.5%と500MiBのうち大きい方の値。 ### `snap-io-max-bytes-per-sec` {#snap-io-max-bytes-per-sec} -- スナップショット処理時の最大許容ディスク帯域幅 -- デフォルト値: `"100MiB"` -- 単位：KiB｜MiB｜GiB -- 最小値: `"1KiB"` +- スナップショット処理時の最大許容ディスク帯域幅 +- デフォルト値: `"100MiB"` +- 単位：KiB｜MiB｜GiB +- 最小値: `"1KiB"` ### `snap-min-ingest-size` v8.1.2の新機能 {#snap-min-ingest-size-new-in-v812} -- スナップショットを処理する際に、TiKVが取り込み方式を採用するかどうかの最小しきい値を指定します。 +- スナップショットを処理する際に、TiKVが取り込み方式を採用するかどうかの最小しきい値を指定します。 - - スナップショットのサイズがこのしきい値を超えると、TiKVは取り込み方式を採用し、スナップショットからSSTファイルをRocksDBにインポートします。この方式は、大きなファイルの場合に高速です。 - - スナップショットのサイズがこのしきい値を超えない場合、TiKVは直接書き込み方式を採用し、各データを個別にRocksDBに書き込みます。この方式は、小さなファイルに対してより効率的です。 + - スナップショットのサイズがこのしきい値を超えると、TiKVは取り込み方式を採用し、スナップショットからSSTファイルをRocksDBにインポートします。この方式は、大きなファイルの場合に高速です。 + - スナップショットのサイズがこのしきい値を超えない場合、TiKVは直接書き込み方式を採用し、各データを個別にRocksDBに書き込みます。この方式は、小さなファイルに対してより効率的です。 -- デフォルト値: `"2MiB"` +- デフォルト値: `"2MiB"` -- 単位：KiB｜MiB｜GiB +- 単位：KiB｜MiB｜GiB -- 最小値: `0` +- 最小値: `0` ### `enable-request-batch` {#enable-request-batch} -- リクエストをバッチ処理するかどうかを決定します。 -- デフォルト値: `true` +- リクエストをバッチ処理するかどうかを決定します。 +- デフォルト値: `true` ### `labels` {#labels} -- `{ zone = "us-west-1", disk = "ssd" }`などのサーバー属性を指定します。 -- デフォルト値: `{}` +- `{ zone = "us-west-1", disk = "ssd" }`などのサーバー属性を指定します。 +- デフォルト値: `{}` ### `background-thread-count` {#background-thread-count} -- エンドポイントスレッド、 BRスレッド、スプリットチェックスレッド、リージョンスレッド、および遅延に影響されないタスクのその他のスレッドを含む、バックグラウンドプールの稼働スレッド数。 -- デフォルト値: CPU コア数が 16 未満の場合、デフォルト値は`2`です。それ以外の場合は、デフォルト値は`3`です。 +- エンドポイントスレッド、 BRスレッド、スプリットチェックスレッド、リージョンスレッド、および遅延に影響されないタスクのその他のスレッドを含む、バックグラウンドプールの稼働スレッド数。 +- デフォルト値: CPU コア数が 16 未満の場合、デフォルト値は`2`です。それ以外の場合は、デフォルト値は`3`です。 ### `end-point-slow-log-threshold` {#end-point-slow-log-threshold} -- TiDBのプッシュダウン要求がスローログを出力するまでの時間しきい値。処理時間がこのしきい値を超えると、スローログが出力されます。 -- デフォルト値: `"1s"` -- 最小値: `0` +- TiDBのプッシュダウン要求がスローログを出力するまでの時間しきい値。処理時間がこのしきい値を超えると、スローログが出力されます。 +- デフォルト値: `"1s"` +- 最小値: `0` ### `raft-client-queue-size` {#raft-client-queue-size} -- TiKVにおけるRaftメッセージのキューサイズを指定します。送信期限内に送信されないメッセージが多すぎてバッファがいっぱいになったり、メッセージが破棄されたりする場合は、より大きな値を指定することでシステムの安定性を向上させることができます。 -- デフォルト値: `16384` +- TiKVにおけるRaftメッセージのキューサイズを指定します。送信期限内に送信されないメッセージが多すぎてバッファがいっぱいになったり、メッセージが破棄されたりする場合は、より大きな値を指定することでシステムの安定性を向上させることができます。 +- デフォルト値: `16384` ### `simplify-metrics` v6.2.0の新機能 {#simplify-metrics-new-in-v620} -- 返される監視メトリクスを簡略化するかどうかを指定します。値を`true`に設定すると、TiKV は一部のメトリクスをフィルタリングすることで、各リクエストに対して返されるデータ量を削減します。 -- デフォルト値: `false` +- 返される監視メトリクスを簡略化するかどうかを指定します。値を`true`に設定すると、TiKV は一部のメトリクスをフィルタリングすることで、各リクエストに対して返されるデータ量を削減します。 +- デフォルト値: `false` ### `forward-max-connections-per-address` v5.0.0 で追加 {#forward-max-connections-per-address-new-in-v500} -- サービスおよびサーバーへのリクエスト転送に使用する接続プールのサイズを設定します。値を小さく設定しすぎると、リクエストのレイテンシーや負荷分散に影響が出ます。 -- デフォルト値: `4` +- サービスおよびサーバーへのリクエスト転送に使用する接続プールのサイズを設定します。値を小さく設定しすぎると、リクエストのレイテンシーや負荷分散に影響が出ます。 +- デフォルト値: `4` ### `inspect-network-interval` （v8.5.5で追加） {#inspect-network-interval-new-in-v855} -- TiKV HealthChecker が PD や他の TiKV ノードに対してネットワーク検出をアクティブに実行する間隔を制御します。TiKV はネットワーク検出結果に基づいて`NetworkSlowScore`を計算し、低速ノードのネットワーク状態を PD に報告します。 -- この値を`0`に設定すると、ネットワーク検出が無効になります。値を小さく設定すると検出頻度が高くなり、ネットワークジッターをより迅速に検出できるようになりますが、ネットワーク帯域幅と CPU リソースの消費量も増加します。 -- デフォルト値: `100ms` -- 値の範囲: `0`または`[10ms, +∞)` +- TiKV HealthChecker が PD や他の TiKV ノードに対してネットワーク検出をアクティブに実行する間隔を制御します。TiKV はネットワーク検出結果に基づいて`NetworkSlowScore`を計算し、低速ノードのネットワーク状態を PD に報告します。 +- この値を`0`に設定すると、ネットワーク検出が無効になります。値を小さく設定すると検出頻度が高くなり、ネットワークジッターをより迅速に検出できるようになりますが、ネットワーク帯域幅と CPU リソースの消費量も増加します。 +- デフォルト値: `100ms` +- 値の範囲: `0`または`[10ms, +∞)` ## readpool.unified {#readpoolunified} @@ -315,14 +315,14 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### `min-thread-count` {#min-thread-count} -- 統合リードプールの最小動作スレッド数 -- デフォルト値: `1` +- 統合リードプールの最小動作スレッド数 +- デフォルト値: `1` ### `max-thread-count` {#max-thread-count} -- 統合読み取りプールまたは UnifyReadPool スレッド プールの最大作業スレッド数。このスレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 -- 値の範囲: `[min-thread-count, MAX(4, CPU quota * 10)]` 。 `MAX(4, CPU quota * 10)`は`4`と`CPU quota * 10`からより大きな値を取得します。 -- デフォルト値: MAX(4, CPU * 0.8) +- 統合読み取りプールまたは UnifyReadPool スレッド プールの最大作業スレッド数。このスレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- 値の範囲: `[min-thread-count, MAX(4, CPU quota * 10)]` 。 `MAX(4, CPU quota * 10)`は`4`と`CPU quota * 10`からより大きな値を取得します。 +- デフォルト値: MAX(4, CPU * 0.8) > **Note:** > @@ -330,38 +330,38 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### `stack-size` {#stack-size-1} -- 統合スレッドプール内のスレッドのスタックサイズ -- 型: 整数 + 単位 -- デフォルト値: `"10MiB"` -- 単位：KiB｜MiB｜GiB -- 最小値: `"2MiB"` -- 最大値: システムで実行された`ulimit -sH`コマンドの結果として出力される Kバイト数。 +- 統合スレッドプール内のスレッドのスタックサイズ +- 型: 整数 + 単位 +- デフォルト値: `"10MiB"` +- 単位：KiB｜MiB｜GiB +- 最小値: `"2MiB"` +- 最大値: システムで実行された`ulimit -sH`コマンドの結果として出力される Kバイト数。 ### `max-tasks-per-worker` {#max-tasks-per-worker} -- 統合読み取りプール内の単一スレッドで許可されるタスクの最大数。この値を超えると`Server Is Busy`が返されます。 -- デフォルト値: `2000` -- 最小値: `2` +- 統合読み取りプール内の単一スレッドで許可されるタスクの最大数。この値を超えると`Server Is Busy`が返されます。 +- デフォルト値: `2000` +- 最小値: `2` ### `auto-adjust-pool-size` v6.3.0で追加 {#auto-adjust-pool-size-new-in-v630} -- スレッドプールのサイズを自動的に調整するかどうかを制御します。有効にすると、現在の CPU 使用率に基づいて UnifyReadPool スレッドプールのサイズを自動的に調整することで、TiKV の読み取りパフォーマンスが最適化されます。スレッドプールの可能な範囲は`[max-thread-count, MAX(4, CPU)]`です。最大値は[`max-thread-count`](#max-thread-count)と同じです。 -- デフォルト値: `false` +- スレッドプールのサイズを自動的に調整するかどうかを制御します。有効にすると、現在の CPU 使用率に基づいて UnifyReadPool スレッドプールのサイズを自動的に調整することで、TiKV の読み取りパフォーマンスが最適化されます。スレッドプールの可能な範囲は`[max-thread-count, MAX(4, CPU)]`です。最大値は[`max-thread-count`](#max-thread-count)と同じです。 +- デフォルト値: `false` ### `cpu-threshold` v8.5.5で追加 {#cpu-threshold-new-in-v855} -- 統合読み取りプールのCPU使用率のしきい値を指定します。たとえば、この値を`0.8`に設定すると、スレッドプールはCPUの最大80%を使用できます。 +- 統合読み取りプールのCPU使用率のしきい値を指定します。たとえば、この値を`0.8`に設定すると、スレッドプールはCPUの最大80%を使用できます。 - - デフォルトでは（ `0.0`の場合）、統合読み取りプールの CPU 使用率に制限はありません。スレッドプールのサイズは、ビジースレッドスケーリングアルゴリズムによってのみ決定され、現在のタスクを処理するスレッド数に基づいてサイズが動的に調整されます。 - - `0.0`より大きい値に設定されている場合、TiKVは既存のビジースレッドスケーリングアルゴリズムに加えて、CPUリソースの使用量をより厳密に制御するために、以下のCPU使用率しきい値制約を適用します。 - - 強制的なスケールダウン：統合読み取りプールのCPU使用率が設定値に10%のバッファを加えた値を超えると、TiKVはプールのサイズを強制的に縮小します。 - - スケールアップ防止：統合リードプールを拡張すると、CPU使用率が設定されたしきい値から10%のバッファを引いた値を超える場合、TiKVは統合リードプールのそれ以上の拡張を防止します。 + - デフォルトでは（ `0.0`の場合）、統合読み取りプールの CPU 使用率に制限はありません。スレッドプールのサイズは、ビジースレッドスケーリングアルゴリズムによってのみ決定され、現在のタスクを処理するスレッド数に基づいてサイズが動的に調整されます。 + - `0.0`より大きい値に設定されている場合、TiKVは既存のビジースレッドスケーリングアルゴリズムに加えて、CPUリソースの使用量をより厳密に制御するために、以下のCPU使用率しきい値制約を適用します。 + - 強制的なスケールダウン：統合読み取りプールのCPU使用率が設定値に10%のバッファを加えた値を超えると、TiKVはプールのサイズを強制的に縮小します。 + - スケールアップ防止：統合リードプールを拡張すると、CPU使用率が設定されたしきい値から10%のバッファを引いた値を超える場合、TiKVは統合リードプールのそれ以上の拡張を防止します。 -- この機能は、 [`readpool.unified.auto-adjust-pool-size`](#auto-adjust-pool-size-new-in-v630)が`true`に設定されている場合にのみ有効になります。 +- この機能は、 [`readpool.unified.auto-adjust-pool-size`](#auto-adjust-pool-size-new-in-v630)が`true`に設定されている場合にのみ有効になります。 -- デフォルト値: `0.0` +- デフォルト値: `0.0` -- 値の範囲: `[0.0, 1.0]` +- 値の範囲: `[0.0, 1.0]` ## readpool.storage {#readpoolstorage} @@ -369,53 +369,53 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### `use-unified-pool` {#use-unified-pool-1} -- ストレージ要求に統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメーターの値が`false`の場合、このセクションの残りのパラメーター（ `readpool.storage` ）で構成された別のスレッドプールが使用されます。 -- デフォルト値: このセクション ( `readpool.storage` ) に他の設定がない場合、デフォルト値は`true`です。それ以外の場合は、下位互換性のために、デフォルト値は`false`です。このオプションを有効にする前に、必要に応じて[`readpool.unified`](#readpoolunified)の設定を変更してください。 +- ストレージ要求に統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメーターの値が`false`の場合、このセクションの残りのパラメーター（ `readpool.storage` ）で構成された別のスレッドプールが使用されます。 +- デフォルト値: このセクション ( `readpool.storage` ) に他の設定がない場合、デフォルト値は`true`です。それ以外の場合は、下位互換性のために、デフォルト値は`false`です。このオプションを有効にする前に、必要に応じて[`readpool.unified`](#readpoolunified)の設定を変更してください。 ### `high-concurrency` {#high-concurrency-1} -- 優先度の高い`read`リクエストを処理する同時実行スレッドの許容数 -- `8` ≤ `cpu num` ≤ `16`の場合、デフォルト値は`cpu_num * 0.5`です。 `cpu num`が`8`より小さい場合、デフォルト値は`4`です。 `cpu num`が`16`より大きい場合、デフォルト値は`8`です。 -- 最小値: `1` +- 優先度の高い`read`リクエストを処理する同時実行スレッドの許容数 +- `8` ≤ `cpu num` ≤ `16`の場合、デフォルト値は`cpu_num * 0.5`です。 `cpu num`が`8`より小さい場合、デフォルト値は`4`です。 `cpu num`が`16`より大きい場合、デフォルト値は`8`です。 +- 最小値: `1` ### `normal-concurrency` {#normal-concurrency-1} -- 通常優先度`read`リクエストを処理する同時実行スレッドの許容数 -- `8` ≤ `cpu num` ≤ `16`の場合、デフォルト値は`cpu_num * 0.5`です。 `cpu num`が`8`より小さい場合、デフォルト値は`4`です。 `cpu num`が`16`より大きい場合、デフォルト値は`8`です。 -- 最小値: `1` +- 通常優先度`read`リクエストを処理する同時実行スレッドの許容数 +- `8` ≤ `cpu num` ≤ `16`の場合、デフォルト値は`cpu_num * 0.5`です。 `cpu num`が`8`より小さい場合、デフォルト値は`4`です。 `cpu num`が`16`より大きい場合、デフォルト値は`8`です。 +- 最小値: `1` ### `low-concurrency` {#low-concurrency-1} -- 優先度の低い`read`リクエストを処理する同時実行スレッドの許容数 -- `8` ≤ `cpu num` ≤ `16`の場合、デフォルト値は`cpu_num * 0.5`です。 `cpu num`が`8`より小さい場合、デフォルト値は`4`です。 `cpu num`が`16`より大きい場合、デフォルト値は`8`です。 -- 最小値: `1` +- 優先度の低い`read`リクエストを処理する同時実行スレッドの許容数 +- `8` ≤ `cpu num` ≤ `16`の場合、デフォルト値は`cpu_num * 0.5`です。 `cpu num`が`8`より小さい場合、デフォルト値は`4`です。 `cpu num`が`16`より大きい場合、デフォルト値は`8`です。 +- 最小値: `1` ### `max-tasks-per-worker-high` {#max-tasks-per-worker-high-1} -- 高優先度スレッドプール内の単一スレッドで許可されるタスクの最大数。この値を超えると、 `Server Is Busy`が返されます。 -- デフォルト値: `2000` -- 最小値: `2` +- 高優先度スレッドプール内の単一スレッドで許可されるタスクの最大数。この値を超えると、 `Server Is Busy`が返されます。 +- デフォルト値: `2000` +- 最小値: `2` ### `max-tasks-per-worker-normal` {#max-tasks-per-worker-normal-1} -- 通常優先度スレッドプールにおいて、1つのスレッドで実行可能なタスクの最大数。この値を超えると、 `Server Is Busy`が返されます。 -- デフォルト値: `2000` -- 最小値: `2` +- 通常優先度スレッドプールにおいて、1つのスレッドで実行可能なタスクの最大数。この値を超えると、 `Server Is Busy`が返されます。 +- デフォルト値: `2000` +- 最小値: `2` ### `max-tasks-per-worker-low` {#max-tasks-per-worker-low-1} -- 低優先度スレッドプール内の単一スレッドで許可されるタスクの最大数。この値を超えると`Server Is Busy`が返されます。 -- デフォルト値: `2000` -- 最小値: `2` +- 低優先度スレッドプール内の単一スレッドで許可されるタスクの最大数。この値を超えると`Server Is Busy`が返されます。 +- デフォルト値: `2000` +- 最小値: `2` ### `stack-size` {#stack-size-2} -- ストレージ読み取りスレッドプール内のスレッドのスタックサイズ -- 型: 整数 + 単位 -- デフォルト値: `"10MiB"` -- 単位：KiB｜MiB｜GiB -- 最小値: `"2MiB"` -- 最大値: システムで実行された`ulimit -sH`コマンドの結果として出力される Kバイト数。 +- ストレージ読み取りスレッドプール内のスレッドのスタックサイズ +- 型: 整数 + 単位 +- デフォルト値: `"10MiB"` +- 単位：KiB｜MiB｜GiB +- 最小値: `"2MiB"` +- 最大値: システムで実行された`ulimit -sH`コマンドの結果として出力される Kバイト数。 ## `readpool.coprocessor` {#readpoolcoprocessor} @@ -423,53 +423,53 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### `use-unified-pool` {#use-unified-pool} -- コプロセッサ要求に統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメータの値が`false`の場合、このセクションの残りのパラメータ（ `readpool.coprocessor` ）で構成された別のスレッドプールが使用されます。 -- デフォルト値: このセクションのパラメータ ( `readpool.coprocessor` ) がいずれも設定されていない場合、デフォルト値は`true`です。それ以外の場合は、下位互換性のためにデフォルト値は`false`になります。このパラメータを有効にする前に、 [`readpool.unified`](#readpoolunified)の設定項目を調整してください。 +- コプロセッサ要求に統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメータの値が`false`の場合、このセクションの残りのパラメータ（ `readpool.coprocessor` ）で構成された別のスレッドプールが使用されます。 +- デフォルト値: このセクションのパラメータ ( `readpool.coprocessor` ) がいずれも設定されていない場合、デフォルト値は`true`です。それ以外の場合は、下位互換性のためにデフォルト値は`false`になります。このパラメータを有効にする前に、 [`readpool.unified`](#readpoolunified)の設定項目を調整してください。 ### `high-concurrency` {#high-concurrency} -- チェックポイントなどの優先度の高いコプロセッサー要求を処理する同時実行スレッドの許容数 -- デフォルト値: `CPU * 0.8` -- 最小値: `1` +- チェックポイントなどの優先度の高いコプロセッサー要求を処理する同時実行スレッドの許容数 +- デフォルト値: `CPU * 0.8` +- 最小値: `1` ### `normal-concurrency` {#normal-concurrency} -- 通常優先度のコプロセッサー要求を処理する同時実行スレッドの許容数 -- デフォルト値: `CPU * 0.8` -- 最小値: `1` +- 通常優先度のコプロセッサー要求を処理する同時実行スレッドの許容数 +- デフォルト値: `CPU * 0.8` +- 最小値: `1` ### `low-concurrency` {#low-concurrency} -- テーブルスキャンなどの低優先度コプロセッサー要求を処理する同時実行スレッドの許容数 -- デフォルト値: `CPU * 0.8` -- 最小値: `1` +- テーブルスキャンなどの低優先度コプロセッサー要求を処理する同時実行スレッドの許容数 +- デフォルト値: `CPU * 0.8` +- 最小値: `1` ### `max-tasks-per-worker-high` {#max-tasks-per-worker-high} -- 高優先度スレッドプール内の単一スレッドに許可されるタスク数。この数を超えると、 `Server Is Busy`が返されます。 -- デフォルト値: `2000` -- 最小値: `2` +- 高優先度スレッドプール内の単一スレッドに許可されるタスク数。この数を超えると、 `Server Is Busy`が返されます。 +- デフォルト値: `2000` +- 最小値: `2` ### `max-tasks-per-worker-normal` {#max-tasks-per-worker-normal} -- 通常優先度スレッドプールにおいて、1つのスレッドで実行可能なタスク数。この数を超えると、 `Server Is Busy`が返されます。 -- デフォルト値: `2000` -- 最小値: `2` +- 通常優先度スレッドプールにおいて、1つのスレッドで実行可能なタスク数。この数を超えると、 `Server Is Busy`が返されます。 +- デフォルト値: `2000` +- 最小値: `2` ### `max-tasks-per-worker-low` {#max-tasks-per-worker-low} -- 低優先度スレッドプール内の単一スレッドに許可されるタスク数。この数を超えると、 `Server Is Busy`が返されます。 -- デフォルト値: `2000` -- 最小値: `2` +- 低優先度スレッドプール内の単一スレッドに許可されるタスク数。この数を超えると、 `Server Is Busy`が返されます。 +- デフォルト値: `2000` +- 最小値: `2` ### `stack-size` {#stack-size} -- コプロセッサースレッドプール内のスレッドのスタックサイズ -- 型: 整数 + 単位 -- デフォルト値: `"10MiB"` -- 単位：KiB｜MiB｜GiB -- 最小値: `"2MiB"` -- 最大値: システムで実行された`ulimit -sH`コマンドの結果として出力される Kバイト数。 +- コプロセッサースレッドプール内のスレッドのスタックサイズ +- 型: 整数 + 単位 +- デフォルト値: `"10MiB"` +- 単位：KiB｜MiB｜GiB +- 最小値: `"2MiB"` +- 最大値: システムで実行された`ulimit -sH`コマンドの結果として出力される Kバイト数。 ## storage {#storage} @@ -477,8 +477,8 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### `data-dir` {#data-dir} -- RocksDBディレクトリのストレージパス -- デフォルト値: `"./"` +- RocksDBディレクトリのストレージパス +- デフォルト値: `"./"` ### `engine` v6.6.0 の新機能 {#engine-new-in-v660} @@ -486,90 +486,90 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも > > この機能は実験的です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -- エンジンタイプを指定します。この設定は、新しいクラスターを作成する際にのみ指定でき、一度指定すると変更できません。 -- デフォルト値: `"raft-kv"` -- 値のオプション： +- エンジンタイプを指定します。この設定は、新しいクラスターを作成する際にのみ指定でき、一度指定すると変更できません。 +- デフォルト値: `"raft-kv"` +- 値のオプション： - - `"raft-kv"` : TiDB v6.6.0 より前のバージョンにおけるデフォルトのエンジンタイプ。 - - `"partitioned-raft-kv"` : TiDB v6.6.0 で導入された新しいストレージエンジン タイプ。 + - `"raft-kv"` : TiDB v6.6.0 より前のバージョンにおけるデフォルトのエンジンタイプ。 + - `"partitioned-raft-kv"` : TiDB v6.6.0 で導入された新しいストレージエンジン タイプ。 ### `scheduler-concurrency` {#scheduler-concurrency} -- キーに対する同時操作を防止するための内蔵メモリロック機構。各キーは異なるスロットにハッシュ値が格納されている。 -- デフォルト値: `524288` -- 最小値: `1` +- キーに対する同時操作を防止するための内蔵メモリロック機構。各キーは異なるスロットにハッシュ値が格納されている。 +- デフォルト値: `524288` +- 最小値: `1` ### `scheduler-worker-pool-size` {#scheduler-worker-pool-size} -- スケジューラのスレッド プール内のスレッドの数。スケジューラ スレッドは主に、データの書き込み前にトランザクションの整合性をチェックするために使用されます。 CPU コアの数が`16`以上の場合、デフォルト値は`8`です。それ以外の場合、デフォルト値は`4`です。スケジューラ スレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 -- デフォルト値: `4` -- 値の範囲: `[1, MAX(4, CPU)]` 。 `MAX(4, CPU)`では、 `CPU`は CPU コアの数を意味します。 `MAX(4, CPU)`は`4`と`CPU`のうち大きい方の値を取得します。 +- スケジューラのスレッド プール内のスレッドの数。スケジューラ スレッドは主に、データの書き込み前にトランザクションの整合性をチェックするために使用されます。 CPU コアの数が`16`以上の場合、デフォルト値は`8`です。それ以外の場合、デフォルト値は`4`です。スケジューラ スレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- デフォルト値: `4` +- 値の範囲: `[1, MAX(4, CPU)]` 。 `MAX(4, CPU)`では、 `CPU`は CPU コアの数を意味します。 `MAX(4, CPU)`は`4`と`CPU`のうち大きい方の値を取得します。 ### `scheduler-pending-write-threshold` {#scheduler-pending-write-threshold} -- 書き込みキューの最大サイズ。この値を超えると、TiKVへの新規書き込みに対して`Server Is Busy`エラーが返されます。 -- デフォルト値: `"100MiB"` -- 単位：MiB｜GiB +- 書き込みキューの最大サイズ。この値を超えると、TiKVへの新規書き込みに対して`Server Is Busy`エラーが返されます。 +- デフォルト値: `"100MiB"` +- 単位：MiB｜GiB ### `enable-async-apply-prewrite` {#enable-async-apply-prewrite} -- 非同期コミットトランザクションが、プリライト要求を適用する前にTiKVクライアントに応答するかどうかを決定します。この設定項目を有効にすると、適用時間が長い場合はレイテンシーを容易に短縮でき、適用時間が不安定な場合は遅延ジッターを低減できます。 -- デフォルト値: `false` +- 非同期コミットトランザクションが、プリライト要求を適用する前にTiKVクライアントに応答するかどうかを決定します。この設定項目を有効にすると、適用時間が長い場合はレイテンシーを容易に短縮でき、適用時間が不安定な場合は遅延ジッターを低減できます。 +- デフォルト値: `false` ### `reserve-space` {#reserve-space} -- TiKVが起動すると、ディスク保護のためにディスク上に一定量の領域が確保されます。残りのディスク容量が確保された領域よりも少ない場合、TiKVは一部の書き込み操作を制限します。確保された領域は2つの部分に分けられます。80%はディスク容量が不足した場合の操作に必要な追加ディスク容量として使用され、残りの20%は一時ファイルの保存に使用されます。領域解放の過程で、追加ディスク容量を使いすぎてストレージが枯渇した場合、この一時ファイルがサービス復旧のための最後の保護手段として機能します。 -- 一時ファイルの名前は`space_placeholder_file`で、 `storage.data-dir`ディレクトリにあります。ディスク容量不足で TiKV がオフラインになった場合、TiKV を再起動すると、一時ファイルは自動的に削除され、TiKV は空き容量の確保を試みます。 -- 残りの空き容量が不足している場合、TiKV は一時ファイルを作成しません。保護の有効性は、予約領域のサイズに関係します。予約領域のサイズは、ディスク容量の 5% とこの構成値のうち大きい方の値です。この構成項目が`0`またはサポートされている単位のゼロ値 (たとえば、 `0KiB` 、 `0MiB` 、または`0GiB` ) に設定されている場合、TiKV はこのディスク保護機能を無効にします。 -- デフォルト値: `"5GiB"` -- 単位: B|KB|KiB|MB|MiB|GB|GiB|TB|TiB|PB|PiB +- TiKVが起動すると、ディスク保護のためにディスク上に一定量の領域が確保されます。残りのディスク容量が確保された領域よりも少ない場合、TiKVは一部の書き込み操作を制限します。確保された領域は2つの部分に分けられます。80%はディスク容量が不足した場合の操作に必要な追加ディスク容量として使用され、残りの20%は一時ファイルの保存に使用されます。領域解放の過程で、追加ディスク容量を使いすぎてストレージが枯渇した場合、この一時ファイルがサービス復旧のための最後の保護手段として機能します。 +- 一時ファイルの名前は`space_placeholder_file`で、 `storage.data-dir`ディレクトリにあります。ディスク容量不足で TiKV がオフラインになった場合、TiKV を再起動すると、一時ファイルは自動的に削除され、TiKV は空き容量の確保を試みます。 +- 残りの空き容量が不足している場合、TiKV は一時ファイルを作成しません。保護の有効性は、予約領域のサイズに関係します。予約領域のサイズは、ディスク容量の 5% とこの構成値のうち大きい方の値です。この構成項目が`0`またはサポートされている単位のゼロ値 (たとえば、 `0KiB` 、 `0MiB` 、または`0GiB` ) に設定されている場合、TiKV はこのディスク保護機能を無効にします。 +- デフォルト値: `"5GiB"` +- 単位: B|KB|KiB|MB|MiB|GB|GiB|TB|TiB|PB|PiB ### `enable-ttl` {#enable-ttl} > **Warning:** > -> - `enable-ttl`を`true`または`false`に設定してください。**既存**の TiKV クラスターでは、この構成項目の値を変更**しないでください**。 `enable-ttl`値が異なる TiKV クラスターでは、使用するデータ形式が異なります。そのため、既存の TiKV クラスターでこの項目の値を変更すると、クラスターはデータを異なる形式で保存するため、TiKV クラスターを再起動すると「非 TTL で TTL を有効にできません」というエラーが発生します。 -> - `enable-ttl` TiKV クラスタ**でのみ**使用して**ください**。TiDB ノードを含むクラスタ (つまり、そのようなクラスタでは`enable-ttl`を`true`に設定する) では、 `storage.api-version = 2`が設定されていない限り、この構成項目を使用しないでください。そうしないと、データの破損や TiDB クラスタのアップグレード失敗などの重大な問題が発生します。 +> - `enable-ttl`を`true`または`false`に設定してください。**既存**の TiKV クラスターでは、この構成項目の値を変更**しないでください**。 `enable-ttl`値が異なる TiKV クラスターでは、使用するデータ形式が異なります。そのため、既存の TiKV クラスターでこの項目の値を変更すると、クラスターはデータを異なる形式で保存するため、TiKV クラスターを再起動すると「非 TTL で TTL を有効にできません」というエラーが発生します。 +> - `enable-ttl` TiKV クラスタ**でのみ**使用して**ください**。TiDB ノードを含むクラスタ (つまり、そのようなクラスタでは`enable-ttl`を`true`に設定する) では、 `storage.api-version = 2`が設定されていない限り、この構成項目を使用しないでください。そうしないと、データの破損や TiDB クラスタのアップグレード失敗などの重大な問題が発生します。 -- [TTL](/time-to-live.md)は「Time to live（有効期限）」の略です。この項目を有効にすると、TiKVはTTLに達したデータを自動的に削除します。TTLの値を設定するには、クライアント経由でデータを書き込む際のリクエストで指定する必要があります。TTLが指定されていない場合、TiKVは該当するデータを自動的に削除しません。 -- デフォルト値: `false` +- [TTL](/time-to-live.md)は「Time to live（有効期限）」の略です。この項目を有効にすると、TiKVはTTLに達したデータを自動的に削除します。TTLの値を設定するには、クライアント経由でデータを書き込む際のリクエストで指定する必要があります。TTLが指定されていない場合、TiKVは該当するデータを自動的に削除しません。 +- デフォルト値: `false` ### `ttl-check-poll-interval` {#ttl-check-poll-interval} -- 物理領域を解放するためにデータをチェックする間隔。データがTTL（有効期限）に達すると、TiKVはチェック中に強制的に物理領域を解放します。 -- デフォルト値: `"12h"` -- 最小値: `"0s"` +- 物理領域を解放するためにデータをチェックする間隔。データがTTL（有効期限）に達すると、TiKVはチェック中に強制的に物理領域を解放します。 +- デフォルト値: `"12h"` +- 最小値: `"0s"` ### `background-error-recovery-window` v6.1.0 の新機能 {#background-error-recovery-window-new-in-v610} -- RocksDBが回復可能なバックグラウンドエラーを検出した後、TiKVが回復するまでの最大許容時間。バックグラウンドSSTファイルの一部が破損した場合、RocksDBは破損したSSTファイルが属するピアを特定した後、ハートビートを介してPDに報告します。PDはスケジューリング操作を実行してこのピアを削除します。最後に、破損したSSTファイルが直接削除され、TiKVのバックグラウンドは再び正常に動作するようになります。 -- リカバリが完了するまで、破損したSSTファイルはまだ存在しています。この間、RocksDBはデータの書き込みを継続できますが、破損したデータ部分を読み取ろうとするとエラーが報告されます。 -- この時間枠内にリカバリが完了しない場合、TiKV はpanicになります。 -- デフォルト値: 1時間 +- RocksDBが回復可能なバックグラウンドエラーを検出した後、TiKVが回復するまでの最大許容時間。バックグラウンドSSTファイルの一部が破損した場合、RocksDBは破損したSSTファイルが属するピアを特定した後、ハートビートを介してPDに報告します。PDはスケジューリング操作を実行してこのピアを削除します。最後に、破損したSSTファイルが直接削除され、TiKVのバックグラウンドは再び正常に動作するようになります。 +- リカバリが完了するまで、破損したSSTファイルはまだ存在しています。この間、RocksDBはデータの書き込みを継続できますが、破損したデータ部分を読み取ろうとするとエラーが報告されます。 +- この時間枠内にリカバリが完了しない場合、TiKV はpanicになります。 +- デフォルト値: 1時間 ### `api-version` v6.1.0で追加 {#api-version-new-in-v610} -- TiKVがRawKVストアとして機能する際にTiKVが使用するストレージフォーマットとインターフェースバージョン。 -- 値のオプション： - - `1` : API V1 を使用し、クライアントから渡されたデータをエンコードせず、そのまま保存します。バージョン 6.1.0 より前の TiKV では、デフォルトで API V1 が使用されます。 - - `2` : API V2 を使用します: - - データは[マルチバージョン同時実行制御 (MVCC)](/glossary.md#multi-version-concurrency-control-mvcc)形式で保存され、タイムスタンプは tikv-server によって PD (TSO) から取得されます。 - - データはさまざまな用途に応じて範囲が定められており、API V2では、単一のクラスタ内でTiDB、トランザクションKV、およびRawKVアプリケーションが共存することをサポートしています。 - - API V2 を使用する場合は、 `storage.enable-ttl = true`も同時に設定する必要があります。API V2 は TTL 機能をサポートしているため、 [`enable-ttl`](#enable-ttl)を明示的に有効にする必要があります。そうしないと、 `storage.enable-ttl`が`false`にデフォルト設定されるため、競合が発生します。 - - API V2を有効にする場合、不要になったデータを再利用するために、少なくとも1つのtidb-serverインスタンスをデプロイする必要があります。このtidb-serverインスタンスは、読み取りサービスと書き込みサービスを同時に提供できます。高可用性を確保するため、複数のtidb-serverインスタンスをデプロイすることも可能です。 - - API V2ではクライアント側のサポートが必要です。詳細は、API V2に対応したクライアントの取扱説明書を参照してください。 - - バージョン6.2.0以降、RawKVの変更データキャプチャ（CDC）がサポートされています。[RawKV CDC](https://tikv.org/docs/latest/concepts/explore-tikv-features/cdc/cdc)を参照してください。 -- デフォルト値: `1` +- TiKVがRawKVストアとして機能する際にTiKVが使用するストレージフォーマットとインターフェースバージョン。 +- 値のオプション： + - `1` : API V1 を使用し、クライアントから渡されたデータをエンコードせず、そのまま保存します。バージョン 6.1.0 より前の TiKV では、デフォルトで API V1 が使用されます。 + - `2` : API V2 を使用します: + - データは[マルチバージョン同時実行制御 (MVCC)](/glossary.md#multi-version-concurrency-control-mvcc)形式で保存され、タイムスタンプは tikv-server によって PD (TSO) から取得されます。 + - データはさまざまな用途に応じて範囲が定められており、API V2では、単一のクラスタ内でTiDB、トランザクションKV、およびRawKVアプリケーションが共存することをサポートしています。 + - API V2 を使用する場合は、 `storage.enable-ttl = true`も同時に設定する必要があります。API V2 は TTL 機能をサポートしているため、 [`enable-ttl`](#enable-ttl)を明示的に有効にする必要があります。そうしないと、 `storage.enable-ttl`が`false`にデフォルト設定されるため、競合が発生します。 + - API V2を有効にする場合、不要になったデータを再利用するために、少なくとも1つのtidb-serverインスタンスをデプロイする必要があります。このtidb-serverインスタンスは、読み取りサービスと書き込みサービスを同時に提供できます。高可用性を確保するため、複数のtidb-serverインスタンスをデプロイすることも可能です。 + - API V2ではクライアント側のサポートが必要です。詳細は、API V2に対応したクライアントの取扱説明書を参照してください。 + - バージョン6.2.0以降、RawKVの変更データキャプチャ（CDC）がサポートされています。[RawKV CDC](https://tikv.org/docs/latest/concepts/explore-tikv-features/cdc/cdc)を参照してください。 +- デフォルト値: `1` > **Warning:** -> - API V1 と API V2 はストレージ形式が異なります。 TiKV に TiDB データのみが含まれている場合に**のみ**、API V2 を直接有効または無効にできます。他のシナリオでは、新しいクラスターをデプロイし、 [RawKVのバックアップと復元](https://tikv.org/docs/latest/concepts/explore-tikv-features/backup-restore/)を使用してデータを移行する必要があります。 -> - API V2を有効にした後は、TiKVクラスターをv6.1.0より前のバージョンにダウングレードする**ことはできません**。ダウングレードすると、データ破損が発生する可能性があります。 +> - API V1 と API V2 はストレージ形式が異なります。 TiKV に TiDB データのみが含まれている場合に**のみ**、API V2 を直接有効または無効にできます。他のシナリオでは、新しいクラスターをデプロイし、 [RawKVのバックアップと復元](https://tikv.org/docs/latest/concepts/explore-tikv-features/backup-restore/)を使用してデータを移行する必要があります。 +> - API V2を有効にした後は、TiKVクラスターをv6.1.0より前のバージョンにダウングレードする**ことはできません**。ダウングレードすると、データ破損が発生する可能性があります。 ## `txn-status-cache-capacity` （v7.6.0で追加） {#txn-status-cache-capacity-new-in-v760} -- TiKVにおけるトランザクションステータスキャッシュの容量を設定します。このパラメータは変更しないでください。 -- デフォルト値: `5120000` +- TiKVにおけるトランザクションステータスキャッシュの容量を設定します。このパラメータは変更しないでください。 +- デフォルト値: `5120000` ## storage.block-cache {#storageblock-cache} @@ -577,19 +577,19 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### `capacity` {#capacity-1} -- 共有ブロックキャッシュのサイズ。 +- 共有ブロックキャッシュのサイズ。 -- デフォルト値: +- デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値はシステムメモリ全体のサイズの 45% です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値はシステムメモリ全体のサイズの 30% です。 + - `storage.engine="raft-kv"`の場合、デフォルト値はシステムメモリ全体のサイズの 45% です。 + - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値はシステムメモリ全体のサイズの 30% です。 -- 単位：KiB｜MiB｜GiB +- 単位：KiB｜MiB｜GiB ### `low-pri-pool-ratio` v8.0.0で追加 {#low-pri-pool-ratio-new-in-v800} -- Titanコンポーネントが使用できるブロックキャッシュ全体の割合を制御します。 -- デフォルト値: `0.2` +- Titanコンポーネントが使用できるブロックキャッシュ全体の割合を制御します。 +- デフォルト値: `0.2` ## storage.flow-control {#storageflow-control} @@ -597,38 +597,38 @@ TiKVにおけるフロー制御メカニズムに関連するコンフィグレ ### `enable` {#enable-1} -- フロー制御メカニズムを有効にするかどうかを決定します。有効にすると、TiKV は KvDB の書き込み停止メカニズムと RaftDB の書き込み停止メカニズム (memtable を除く) を自動的に無効にします。 -- デフォルト値: `true` +- フロー制御メカニズムを有効にするかどうかを決定します。有効にすると、TiKV は KvDB の書き込み停止メカニズムと RaftDB の書き込み停止メカニズム (memtable を除く) を自動的に無効にします。 +- デフォルト値: `true` ### `memtables-threshold` {#memtables-threshold} -- kvDB の memtable の数がこのしきい値に達すると、フロー制御メカニズムが動作を開始します。 `enable`が`true`に設定されている場合、この構成項目は`rocksdb.(defaultcf|writecf|lockcf).max-write-buffer-number`を上書きします。 -- デフォルト値: `5` +- kvDB の memtable の数がこのしきい値に達すると、フロー制御メカニズムが動作を開始します。 `enable`が`true`に設定されている場合、この構成項目は`rocksdb.(defaultcf|writecf|lockcf).max-write-buffer-number`を上書きします。 +- デフォルト値: `5` ### `l0-files-threshold` {#l0-files-threshold} -- kvDB L0ファイルの数がこのしきい値に達すると、フロー制御メカニズムが作動を開始します。 +- kvDB L0ファイルの数がこのしきい値に達すると、フロー制御メカニズムが作動を開始します。 > **Note:** > > 特定の条件下では、この構成項目は`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` +- デフォルト値: `20` ### `soft-pending-compaction-bytes-limit` {#soft-pending-compaction-bytes-limit-1} -- KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し始め、 `ServerIsBusy`エラーを報告します。 +- KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し始め、 `ServerIsBusy`エラーを報告します。 > **Note:** > > 特定の条件下では、この構成項目は`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"` +- デフォルト値: `"192GiB"` ### `hard-pending-compaction-bytes-limit` {#hard-pending-compaction-bytes-limit-1} -- KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。 `enable`が`true`に設定されている場合、この構成項目は`rocksdb.(defaultcf|writecf|lockcf).hard-pending-compaction-bytes-limit`を上書きします。 -- デフォルト値: `"1024GiB"` +- KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。 `enable`が`true`に設定されている場合、この構成項目は`rocksdb.(defaultcf|writecf|lockcf).hard-pending-compaction-bytes-limit`を上書きします。 +- デフォルト値: `"1024GiB"` ## storage.io-rate-limit {#storageio-rate-limit} @@ -636,14 +636,14 @@ I/Oレートリミッターに関連するコンフィグレーション項目 ### `max-bytes-per-sec` {#max-bytes-per-sec} -- サーバーがディスクに書き込んだり、ディスクから読み取ったりできる最大I/Oバイト数を1秒間に制限します（この制限値は、下記の`mode`設定項目で決定されます）。この制限に達すると、TiKVはフォアグラウンド操作よりもバックグラウンド操作を優先的にスロットリングします。この設定項目の値は、ディスクの最適なI/O帯域幅（例えば、クラウドディスクベンダーが指定する最大I/O帯域幅）に設定する必要があります。この設定値をゼロに設定すると、ディスクI/O操作は制限されません。 -- デフォルト値: `"0MiB"` +- サーバーがディスクに書き込んだり、ディスクから読み取ったりできる最大I/Oバイト数を1秒間に制限します（この制限値は、下記の`mode`設定項目で決定されます）。この制限に達すると、TiKVはフォアグラウンド操作よりもバックグラウンド操作を優先的にスロットリングします。この設定項目の値は、ディスクの最適なI/O帯域幅（例えば、クラウドディスクベンダーが指定する最大I/O帯域幅）に設定する必要があります。この設定値をゼロに設定すると、ディスクI/O操作は制限されません。 +- デフォルト値: `"0MiB"` ### `mode` {#mode} -- `max-bytes-per-sec`しきい値未満でカウントおよび制限されるI/O操作の種類を決定します。現在、書き込み専用モードのみがサポートされています。 -- 値のオプション: `"read-only"` 、 `"write-only"` 、および`"all-io"` -- デフォルト値: `"write-only"` +- `max-bytes-per-sec`しきい値未満でカウントおよび制限されるI/O操作の種類を決定します。現在、書き込み専用モードのみがサポートされています。 +- 値のオプション: `"read-only"` 、 `"write-only"` 、および`"all-io"` +- デフォルト値: `"write-only"` ## storage.max-ts {#storagemax-ts} @@ -677,32 +677,32 @@ I/Oレートリミッターに関連するコンフィグレーション項目 ### `enable-forwarding` v5.0.0の新機能 {#enable-forwarding-new-in-v500} -- TiKVのPDクライアントが、ネットワークが隔離された可能性がある場合に、フォロワーを介してリーダーにリクエストを転送するかどうかを制御します。 -- デフォルト値: `false` -- 環境が孤立したネットワークである可能性がある場合、このパラメータを有効にすることで、サービスが利用できなくなる時間を短縮できます。 -- 隔離、ネットワーク障害、またはダウンタイムが発生したかどうかを正確に判断できない場合、このメカニズムを使用すると誤判断のリスクがあり、可用性とパフォーマンスが低下します。ネットワーク障害が一度も発生したことがない場合は、このパラメータを有効にすることは推奨されません。 +- TiKVのPDクライアントが、ネットワークが隔離された可能性がある場合に、フォロワーを介してリーダーにリクエストを転送するかどうかを制御します。 +- デフォルト値: `false` +- 環境が孤立したネットワークである可能性がある場合、このパラメータを有効にすることで、サービスが利用できなくなる時間を短縮できます。 +- 隔離、ネットワーク障害、またはダウンタイムが発生したかどうかを正確に判断できない場合、このメカニズムを使用すると誤判断のリスクがあり、可用性とパフォーマンスが低下します。ネットワーク障害が一度も発生したことがない場合は、このパラメータを有効にすることは推奨されません。 ### `endpoints` {#endpoints} -- PDのエンドポイント。複数のエンドポイントを指定する場合は、カンマで区切る必要があります。 -- デフォルト値: `["127.0.0.1:2379"]` +- PDのエンドポイント。複数のエンドポイントを指定する場合は、カンマで区切る必要があります。 +- デフォルト値: `["127.0.0.1:2379"]` ### `retry-interval` {#retry-interval} -- PD接続を再試行する間隔。 -- デフォルト値: `"300ms"` +- PD接続を再試行する間隔。 +- デフォルト値: `"300ms"` ### `retry-log-every` {#retry-log-every} -- PDクライアントがエラーを検出した際に、エラー報告をスキップする頻度を指定します。たとえば、値が`5`の場合、PDクライアントはエラーを検出した後、4回ごとにエラー報告をスキップし、5回ごとにエラーを報告します。 -- この機能を無効にするには、値を`1`に設定してください。 -- デフォルト値: `10` +- PDクライアントがエラーを検出した際に、エラー報告をスキップする頻度を指定します。たとえば、値が`5`の場合、PDクライアントはエラーを検出した後、4回ごとにエラー報告をスキップし、5回ごとにエラーを報告します。 +- この機能を無効にするには、値を`1`に設定してください。 +- デフォルト値: `10` ### `retry-max-count` {#retry-max-count} -- PD接続の初期化を再試行する最大回数 -- 再試行を無効にするには、値を`0`に設定します。再試行回数の制限を解除するには、値を`-1`に設定します。 -- デフォルト値: `-1` +- PD接続の初期化を再試行する最大回数 +- 再試行を無効にするには、値を`0`に設定します。再試行回数の制限を解除するには、値を`-1`に設定します。 +- デフォルト値: `-1` ## raftstore {#raftstore} @@ -710,19 +710,19 @@ Raftstoreに関連するコンフィグレーション項目。 ### `prevote` {#prevote} -- `prevote`を有効または無効にします。この機能を有効にすると、ネットワークパーティションからのリカバリ後のシステム上のジッターを軽減するのに役立ちます。 -- デフォルト値: `true` +- `prevote`を有効または無効にします。この機能を有効にすると、ネットワークパーティションからのリカバリ後のシステム上のジッターを軽減するのに役立ちます。 +- デフォルト値: `true` ### `capacity` {#capacity} -- ストレージ容量。データを保存できる最大サイズです。 `capacity`を指定しない場合、現在のディスクの容量が優先されます。複数の TiKV インスタンスを同じ物理ディスクにデプロイするには、このパラメータを TiKV 構成に追加します。詳細については、 [ハイブリッド展開の主要パラメータ](/hybrid-deployment-topology.md#key-parameters)を参照してください。 -- デフォルト値: `0` -- 単位：KiB｜MiB｜GiB +- ストレージ容量。データを保存できる最大サイズです。 `capacity`を指定しない場合、現在のディスクの容量が優先されます。複数の TiKV インスタンスを同じ物理ディスクにデプロイするには、このパラメータを TiKV 構成に追加します。詳細については、 [ハイブリッド展開の主要パラメータ](/hybrid-deployment-topology.md#key-parameters)を参照してください。 +- デフォルト値: `0` +- 単位：KiB｜MiB｜GiB ### `raftdb-path` {#raftdb-path} -- Raftライブラリへのパス（デフォルトでは`storage.data-dir/raft`） -- デフォルト値: `""` +- Raftライブラリへのパス（デフォルトでは`storage.data-dir/raft`） +- デフォルト値: `""` ### `raft-base-tick-interval` {#raft-base-tick-interval} @@ -730,9 +730,9 @@ Raftstoreに関連するコンフィグレーション項目。 > > この設定項目はSQL文による照会はできませんが、設定ファイル内で設定できます。 -- Raftステートマシンがティックする時間間隔 -- デフォルト値: `"1s"` -- 最小値: `0`より大きい +- Raftステートマシンがティックする時間間隔 +- デフォルト値: `"1s"` +- 最小値: `0`より大きい ### `raft-heartbeat-ticks` {#raft-heartbeat-ticks} @@ -740,9 +740,9 @@ Raftstoreに関連するコンフィグレーション項目。 > > この設定項目はSQL文による照会はできませんが、設定ファイル内で設定できます。 -- ハートビートが送信されるまでの経過ティック数。これは、 `raft-base-tick-interval` * `raft-heartbeat-ticks` の時間間隔でハートビートが送信されます。 -- デフォルト値: `2` -- 最小値: `0`より大きい +- ハートビートが送信されるまでの経過ティック数。これは、 `raft-base-tick-interval` * `raft-heartbeat-ticks` の時間間隔でハートビートが送信されます。 +- デフォルト値: `2` +- 最小値: `0`より大きい ### `raft-election-timeout-ticks` {#raft-election-timeout-ticks} @@ -750,9 +750,9 @@ Raftstoreに関連するコンフィグレーション項目。 > > この設定項目はSQL文による照会はできませんが、設定ファイル内で設定できます。 -- Raft選挙が開始されるまでに経過したティック数。これは、 Raftグループにリーダーがいない場合、リーダー選挙が約`raft-base-tick-interval` * `raft-election-timeout-ticks`の時間間隔後に開始されることを意味します。 -- デフォルト値: `10` -- 最小値: `raft-heartbeat-ticks` +- Raft選挙が開始されるまでに経過したティック数。これは、 Raftグループにリーダーがいない場合、リーダー選挙が約`raft-base-tick-interval` * `raft-election-timeout-ticks`の時間間隔後に開始されることを意味します。 +- デフォルト値: `10` +- 最小値: `raft-heartbeat-ticks` ### `raft-min-election-timeout-ticks` {#raft-min-election-timeout-ticks} @@ -760,9 +760,9 @@ Raftstoreに関連するコンフィグレーション項目。 > > この設定項目はSQL文による照会はできませんが、設定ファイル内で設定できます。 -- Raft選挙が開始される最小ティック数。この数が`0`の場合、 `raft-election-timeout-ticks`の値が使用されます。このパラメータの値は`raft-election-timeout-ticks`以上でなければなりません。 -- デフォルト値: `0` -- 最小値: `0` +- Raft選挙が開始される最小ティック数。この数が`0`の場合、 `raft-election-timeout-ticks`の値が使用されます。このパラメータの値は`raft-election-timeout-ticks`以上でなければなりません。 +- デフォルト値: `0` +- 最小値: `0` ### `raft-max-election-timeout-ticks` {#raft-max-election-timeout-ticks} @@ -770,106 +770,106 @@ Raftstoreに関連するコンフィグレーション項目。 > > この設定項目はSQL文による照会はできませんが、設定ファイル内で設定できます。 -- Raft選挙が開始される最大ティック数。この数が`0`の場合、 `raft-election-timeout-ticks` * `2`の値が使用されます。 -- デフォルト値: `0` -- 最小値: `0` +- Raft選挙が開始される最大ティック数。この数が`0`の場合、 `raft-election-timeout-ticks` * `2`の値が使用されます。 +- デフォルト値: `0` +- 最小値: `0` ### `raft-max-size-per-msg` {#raft-max-size-per-msg} -- 単一メッセージパケットのサイズに対するソフトリミット -- デフォルト値: `"1MiB"` -- 最小値: `0`より大きい -- 最大値: `3GiB` -- 単位：KiB｜MiB｜GiB +- 単一メッセージパケットのサイズに対するソフトリミット +- デフォルト値: `"1MiB"` +- 最小値: `0`より大きい +- 最大値: `3GiB` +- 単位：KiB｜MiB｜GiB ### `raft-max-inflight-msgs` {#raft-max-inflight-msgs} -- 確認が必要なRaftログの数。この数を超えると、 Raftステートマシンはログ送信を遅くします。 -- デフォルト値: `256` -- 最小値: `0`より大きい -- 最大値: `16384` +- 確認が必要なRaftログの数。この数を超えると、 Raftステートマシンはログ送信を遅くします。 +- デフォルト値: `256` +- 最小値: `0`より大きい +- 最大値: `16384` ### `raft-entry-max-size` {#raft-entry-max-size} -- 単一ログの最大サイズに対する厳格な制限 -- デフォルト値: `"8MiB"` -- 最小値: `0` -- 単位：MiB｜GiB +- 単一ログの最大サイズに対する厳格な制限 +- デフォルト値: `"8MiB"` +- 最小値: `0` +- 単位：MiB｜GiB ### `raft-log-compact-sync-interval` v5.3で追加 {#raft-log-compact-sync-interval-new-in-v53} -- 不要なRaftログを圧縮する時間間隔 -- デフォルト値: `"2s"` -- 最小値: `"0s"` +- 不要なRaftログを圧縮する時間間隔 +- デフォルト値: `"2s"` +- 最小値: `"0s"` ### `raft-log-gc-tick-interval` {#raft-log-gc-tick-interval} -- Raftログを削除するポーリング タスクがスケジュールされる時間間隔。 `0`はこの機能が無効になっていることを意味します。 -- デフォルト値: `"3s"` -- 最小値: `"0s"` +- Raftログを削除するポーリング タスクがスケジュールされる時間間隔。 `0`はこの機能が無効になっていることを意味します。 +- デフォルト値: `"3s"` +- 最小値: `"0s"` ### `raft-log-gc-threshold` {#raft-log-gc-threshold} -- 残存するRaftログの最大許容数に関するソフトリミット -- デフォルト値: `50` -- 最小値: `1` +- 残存するRaftログの最大許容数に関するソフトリミット +- デフォルト値: `50` +- 最小値: `1` ### `raft-log-gc-count-limit` {#raft-log-gc-count-limit} -- 残存するRaftログの許容数の上限 -- デフォルト値：各ログが1 KiBであると仮定して計算された、リージョンサイズの4分の3に収まるログの数 -- 最小値: `0` +- 残存するRaftログの許容数の上限 +- デフォルト値：各ログが1 KiBであると仮定して計算された、リージョンサイズの4分の3に収まるログの数 +- 最小値: `0` ### `raft-log-gc-size-limit` {#raft-log-gc-size-limit} -- 残余Raftログの許容サイズに関する厳格な制限 -- デフォルト値：リージョンサイズの3/4 -- 最小値: `0`より大きい +- 残余Raftログの許容サイズに関する厳格な制限 +- デフォルト値：リージョンサイズの3/4 +- 最小値: `0`より大きい ### `raft-log-reserve-max-ticks` v5.3の新機能 {#raft-log-reserve-max-ticks-new-in-v53} -- この設定項目で設定されたティック数が経過した後、残存するRaftログの数が`raft-log-gc-threshold`で設定された値に達しない場合でも、TiKV はこれらのログに対してガベージコレクション(GC) を実行します。 -- デフォルト値: `6` -- 最小値: `0`より大きい +- この設定項目で設定されたティック数が経過した後、残存するRaftログの数が`raft-log-gc-threshold`で設定された値に達しない場合でも、TiKV はこれらのログに対してガベージコレクション(GC) を実行します。 +- デフォルト値: `6` +- 最小値: `0`より大きい ### `raft-engine-purge-interval` {#raft-engine-purge-interval} -- ディスク容量をできるだけ早く再利用するために、古いTiKVログファイルをパージする間隔。Raftエンジンは交換可能なコンポーネントであるため、一部の実装ではパージ処理が必要です。 -- デフォルト値: `"10s"` +- ディスク容量をできるだけ早く再利用するために、古いTiKVログファイルをパージする間隔。Raftエンジンは交換可能なコンポーネントであるため、一部の実装ではパージ処理が必要です。 +- デフォルト値: `"10s"` ### `raft-entry-cache-life-time` {#raft-entry-cache-life-time} -- メモリ内のログキャッシュに許容される最大残り時間 -- デフォルト値: `"30s"` -- 最小値: `0` +- メモリ内のログキャッシュに許容される最大残り時間 +- デフォルト値: `"30s"` +- 最小値: `0` ### `max-apply-unpersisted-log-limit` v8.1.0で追加 {#max-apply-unpersisted-log-limit-new-in-v810} -- 適用可能な、コミット済みだが永続化されていないRaftログの最大数。 +- 適用可能な、コミット済みだが永続化されていないRaftログの最大数。 - - この設定項目を`0`より大きい値に設定すると、TiKVノードはコミット済みだが永続化されていないRaftログを事前に適用できるようになり、そのノードでのIOジッターによって発生するロングテールレイテンシーを効果的に削減できます。ただし、TiKVのメモリ使用量とRaftログが占めるディスク容量が増加する可能性もあります。 - - この設定項目を`0`に設定すると、この機能が無効になります。つまり、TiKV はRaftログがコミットされ、かつ永続化されるまで待機してから適用する必要があります。この動作は、v8.2.0 より前のバージョンの動作と一致しています。 + - この設定項目を`0`より大きい値に設定すると、TiKVノードはコミット済みだが永続化されていないRaftログを事前に適用できるようになり、そのノードでのIOジッターによって発生するロングテールレイテンシーを効果的に削減できます。ただし、TiKVのメモリ使用量とRaftログが占めるディスク容量が増加する可能性もあります。 + - この設定項目を`0`に設定すると、この機能が無効になります。つまり、TiKV はRaftログがコミットされ、かつ永続化されるまで待機してから適用する必要があります。この動作は、v8.2.0 より前のバージョンの動作と一致しています。 -- デフォルト値: `1024` +- デフォルト値: `1024` -- 最小値: `0` +- 最小値: `0` ### `hibernate-regions` {#hibernate-regions} -- 休止リージョンを有効または無効にします。このオプションを有効にすると、長時間アイドル状態が続くリージョンは自動的に休止状態になります。これにより、アイドル状態のリージョンについて、 Raftリーダーとフォロワー間のハートビートメッセージによって発生する余分なオーバーヘッドが軽減されます。休止状態のリージョンのリーダーとフォロワー間のハートビート間隔は`peer-stale-state-check-interval`を使用して変更できます。 -- デフォルト値: v5.0.2 以降のバージョンでは`true` 、v5.0.2 より前のバージョンでは`false` +- 休止リージョンを有効または無効にします。このオプションを有効にすると、長時間アイドル状態が続くリージョンは自動的に休止状態になります。これにより、アイドル状態のリージョンについて、 Raftリーダーとフォロワー間のハートビートメッセージによって発生する余分なオーバーヘッドが軽減されます。休止状態のリージョンのリーダーとフォロワー間のハートビート間隔は`peer-stale-state-check-interval`を使用して変更できます。 +- デフォルト値: v5.0.2 以降のバージョンでは`true` 、v5.0.2 より前のバージョンでは`false` ### `split-region-check-tick-interval` {#split-region-check-tick-interval} -- リージョン分割が必要かどうかを確認する間隔を指定します。 `0`はこの機能が無効になっていることを意味します。 -- デフォルト値: `"10s"` -- 最小値: `0` +- リージョン分割が必要かどうかを確認する間隔を指定します。 `0`はこの機能が無効になっていることを意味します。 +- デフォルト値: `"10s"` +- 最小値: `0` ### `region-split-check-diff` {#region-split-check-diff} -- リージョン分割前にリージョンデータが超過できる最大値 -- デフォルト値：リージョンサイズの1/16。 -- 最小値: `0` +- リージョン分割前にリージョンデータが超過できる最大値 +- デフォルト値：リージョンサイズの1/16。 +- 最小値: `0` ### `region-compact-check-interval` {#region-compact-check-interval} @@ -877,9 +877,9 @@ Raftstoreに関連するコンフィグレーション項目。 > > v7.5.7およびv8.5.4以降、この設定項目は非推奨となり、 [`gc.auto-compaction.check-interval`](#check-interval-new-in-v757-and-v854)に置き換えられました。 -- RocksDB の圧縮を手動でトリガーする必要があるかどうかを確認する時間間隔。 `0`はこの機能が無効になっていることを意味します。 -- デフォルト値: `"5m"` -- 最小値: `0` +- RocksDB の圧縮を手動でトリガーする必要があるかどうかを確認する時間間隔。 `0`はこの機能が無効になっていることを意味します。 +- デフォルト値: `"5m"` +- 最小値: `0` ### `region-compact-check-step` {#region-compact-check-step} @@ -887,12 +887,12 @@ Raftstoreに関連するコンフィグレーション項目。 > > バージョン7.5.7および8.5.4以降、この設定項目は非推奨となりました。 -- 手動圧縮の各ラウンドで一度にチェックされるリージョンの数 -- デフォルト値: +- 手動圧縮の各ラウンドで一度にチェックされるリージョンの数 +- デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は`100`です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`5`です。 -- 最小値: `0` + - `storage.engine="raft-kv"`の場合、デフォルト値は`100`です。 + - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`5`です。 +- 最小値: `0` ### `region-compact-min-tombstones` {#region-compact-min-tombstones} @@ -900,9 +900,9 @@ Raftstoreに関連するコンフィグレーション項目。 > > バージョン7.5.7および8.5.4以降、この設定項目は非推奨となり、 [`gc.auto-compaction.tombstone-num-threshold`](#tombstone-num-threshold-new-in-v757-and-v854)に置き換えられました。 -- RocksDBの圧縮をトリガーするために必要なtombstoneの数 -- デフォルト値: `10000` -- 最小値: `0` +- RocksDBの圧縮をトリガーするために必要なtombstoneの数 +- デフォルト値: `10000` +- 最小値: `0` ### `region-compact-tombstones-percent` {#region-compact-tombstones-percent} @@ -910,10 +910,10 @@ Raftstoreに関連するコンフィグレーション項目。 > > バージョン7.5.7および8.5.4以降、この設定項目は非推奨となり、 [`gc.auto-compaction.tombstone-percent-threshold`](#tombstone-percent-threshold-new-in-v757-and-v854)に置き換えられました。 -- RocksDBの圧縮をトリガーするために必要なtombstoneの割合 -- デフォルト値: `30` -- 最小値: `1` -- 最大値: `100` +- RocksDBの圧縮をトリガーするために必要なtombstoneの割合 +- デフォルト値: `30` +- 最小値: `1` +- 最大値: `100` ### `region-compact-min-redundant-rows` v7.1.0 の新機能 {#region-compact-min-redundant-rows-new-in-v710} @@ -921,9 +921,9 @@ Raftstoreに関連するコンフィグレーション項目。 > > バージョン7.5.7および8.5.4以降、この設定項目は非推奨となり、 [`gc.auto-compaction.redundant-rows-threshold`](#redundant-rows-threshold-new-in-v757-and-v854)に置き換えられました。 -- RocksDBのコンパクションをトリガーするために必要な、冗長なMVCC行の数。 -- デフォルト値: `50000` -- 最小値: `0` +- RocksDBのコンパクションをトリガーするために必要な、冗長なMVCC行の数。 +- デフォルト値: `50000` +- 最小値: `0` ### `region-compact-redundant-rows-percent` v7.1.0の新機能 {#region-compact-redundant-rows-percent-new-in-v710} @@ -931,10 +931,10 @@ Raftstoreに関連するコンフィグレーション項目。 > > v7.5.7 および v8.5.4 以降、この設定項目は非推奨となり、 [`gc.auto-compaction.redundant-rows-percent-threshold`](#redundant-rows-percent-threshold-new-in-v757-and-v854)に置き換えられました。 -- RocksDBのコンパクションをトリガーするために必要な、冗長なMVCC行の割合。 -- デフォルト値: `20` -- 最小値: `1` -- 最大値: `100` +- RocksDBのコンパクションをトリガーするために必要な、冗長なMVCC行の割合。 +- デフォルト値: `20` +- 最小値: `1` +- 最大値: `100` ### `report-region-buckets-tick-interval` v6.1.0で追加 {#report-region-buckets-tick-interval-new-in-v610} @@ -942,20 +942,20 @@ Raftstoreに関連するコンフィグレーション項目。 > > `report-region-buckets-tick-interval`は、TiDB v6.1.0 で導入された実験的機能です。本番環境での使用は推奨されません。 -- `enable-region-bucket`が真の場合に、TiKVがバケット情報をPDに報告する間隔。 -- デフォルト値: `10s` +- `enable-region-bucket`が真の場合に、TiKVがバケット情報をPDに報告する間隔。 +- デフォルト値: `10s` ### `pd-heartbeat-tick-interval` {#pd-heartbeat-tick-interval} -- リージョンからPDへのハートビートがトリガーされる時間間隔。 `0`はこの機能が無効になっていることを意味します。 -- デフォルト値: `"1m"` -- 最小値: `0` +- リージョンからPDへのハートビートがトリガーされる時間間隔。 `0`はこの機能が無効になっていることを意味します。 +- デフォルト値: `"1m"` +- 最小値: `0` ### `pd-store-heartbeat-tick-interval` {#pd-store-heartbeat-tick-interval} -- ストアからPDへのハートビートがトリガーされる時間間隔。 `0`はこの機能が無効になっていることを意味します。 -- デフォルト値: `"10s"` -- 最小値: `0` +- ストアからPDへのハートビートがトリガーされる時間間隔。 `0`はこの機能が無効になっていることを意味します。 +- デフォルト値: `"10s"` +- 最小値: `0` ### `pd-report-min-resolved-ts-interval` v7.6.0で追加 {#pd-report-min-resolved-ts-interval-new-in-v760} @@ -963,97 +963,97 @@ Raftstoreに関連するコンフィグレーション項目。 > > この設定項目は、 [`report-min-resolved-ts-interval`](https://docs.pingcap.com/tidb/v7.5/tikv-configuration-file/#report-min-resolved-ts-interval-new-in-v600)から名前が変更されました。v7.6.0 以降、 `report-min-resolved-ts-interval`は無効になりました。 -- TiKVが解決済みTSをPDリーダーに報告する最小間隔を指定します。これを`0`に設定すると、報告が無効になります。 -- デフォルト値: `"1s"`は、最小の正の値です。v6.3.0 より前のバージョンでは、デフォルト値は`"0s"`でした。 -- 最小値: `0` -- 単位：秒 +- TiKVが解決済みTSをPDリーダーに報告する最小間隔を指定します。これを`0`に設定すると、報告が無効になります。 +- デフォルト値: `"1s"`は、最小の正の値です。v6.3.0 より前のバージョンでは、デフォルト値は`"0s"`でした。 +- 最小値: `0` +- 単位：秒 ### `snap-mgr-gc-tick-interval` {#snap-mgr-gc-tick-interval} -- 期限切れのスナップショットファイルのリサイクルがトリガーされる時間間隔。 `0`はこの機能が無効になっていることを意味します。 -- デフォルト値: `"1m"` -- 最小値: `0` +- 期限切れのスナップショットファイルのリサイクルがトリガーされる時間間隔。 `0`はこの機能が無効になっていることを意味します。 +- デフォルト値: `"1m"` +- 最小値: `0` ### `snap-gc-timeout` {#snap-gc-timeout} -- スナップショットファイルが保存される最長期間 -- デフォルト値: `"4h"` -- 最小値: `0` +- スナップショットファイルが保存される最長期間 +- デフォルト値: `"4h"` +- 最小値: `0` ### `snap-generator-pool-size` v5.4.0の新機能 {#snap-generator-pool-size-new-in-v540} -- `snap-generator`スレッドプールのサイズを設定します。 -- TiKV のリカバリシナリオでリージョンがスナップショットをより高速に生成できるようにするには、対応するワーカーの`snap-generator`スレッドの数を増やす必要があります。この構成項目を使用して、 `snap-generator`スレッド プールのサイズを増やすことができます。 -- デフォルト値: `2` -- 最小値: `1` +- `snap-generator`スレッドプールのサイズを設定します。 +- TiKV のリカバリシナリオでリージョンがスナップショットをより高速に生成できるようにするには、対応するワーカーの`snap-generator`スレッドの数を増やす必要があります。この構成項目を使用して、 `snap-generator`スレッド プールのサイズを増やすことができます。 +- デフォルト値: `2` +- 最小値: `1` ### `lock-cf-compact-interval` {#lock-cf-compact-interval} -- TiKVがロックカラムファミリーの手動圧縮をトリガーする時間間隔 -- デフォルト値: `"10m"` -- 最小値: `0` +- TiKVがロックカラムファミリーの手動圧縮をトリガーする時間間隔 +- デフォルト値: `"10m"` +- 最小値: `0` ### `lock-cf-compact-bytes-threshold` {#lock-cf-compact-bytes-threshold} -- TiKVがロックカラムファミリーの手動圧縮をトリガーするサイズ -- デフォルト値: `"256MiB"` -- 最小値: `0` -- 単位: MiB +- TiKVがロックカラムファミリーの手動圧縮をトリガーするサイズ +- デフォルト値: `"256MiB"` +- 最小値: `0` +- 単位: MiB ### `notify-capacity` {#notify-capacity} -- リージョンメッセージキューの最長。 -- デフォルト値: `40960` -- 最小値: `0` +- リージョンメッセージキューの最長。 +- デフォルト値: `40960` +- 最小値: `0` ### `messages-per-tick` {#messages-per-tick} -- バッチごとに処理されるメッセージの最大数 -- デフォルト値: `4096` -- 最小値: `0` +- バッチごとに処理されるメッセージの最大数 +- デフォルト値: `4096` +- 最小値: `0` ### `max-peer-down-duration` {#max-peer-down-duration} -- ピアに許容される最長の非アクティブ期間。タイムアウトしたピアは`down`とマークされ、PD は後でそれを削除しようとします。 -- デフォルト値: `"10m"` -- 最小値: Hibernate リージョンが有効になっている場合、最小値は`peer-stale-state-check-interval * 2`です。Hibernate リージョンが無効になっている場合、最小値は`0`です。 +- ピアに許容される最長の非アクティブ期間。タイムアウトしたピアは`down`とマークされ、PD は後でそれを削除しようとします。 +- デフォルト値: `"10m"` +- 最小値: Hibernate リージョンが有効になっている場合、最小値は`peer-stale-state-check-interval * 2`です。Hibernate リージョンが無効になっている場合、最小値は`0`です。 ### `max-leader-missing-duration` {#max-leader-missing-duration} -- Raftグループにリーダーが存在しない状態がピアに許容される最長期間。この値を超えると、ピアはPDに対してピアが削除されたかどうかを確認します。 -- デフォルト値: `"2h"` -- 最小値: `abnormal-leader-missing-duration`より大きい +- Raftグループにリーダーが存在しない状態がピアに許容される最長期間。この値を超えると、ピアはPDに対してピアが削除されたかどうかを確認します。 +- デフォルト値: `"2h"` +- 最小値: `abnormal-leader-missing-duration`より大きい ### `abnormal-leader-missing-duration` {#abnormal-leader-missing-duration} -- Raftグループのリーダーが存在しない状態がピアに許容される最長期間。この値を超えると、ピアは異常とみなされ、メトリクスとログに記録されます。 -- デフォルト値: `"10m"` -- 最小値: `peer-stale-state-check-interval`より大きい +- Raftグループのリーダーが存在しない状態がピアに許容される最長期間。この値を超えると、ピアは異常とみなされ、メトリクスとログに記録されます。 +- デフォルト値: `"10m"` +- 最小値: `peer-stale-state-check-interval`より大きい ### `peer-stale-state-check-interval` {#peer-stale-state-check-interval} -- Raftグループにリーダーが存在しない状態にあるかどうかをチェックするトリガーとなる時間間隔。 -- デフォルト値: `"5m"` -- 最小値: `2 * election-timeout`より大きい +- Raftグループにリーダーが存在しない状態にあるかどうかをチェックするトリガーとなる時間間隔。 +- デフォルト値: `"5m"` +- 最小値: `2 * election-timeout`より大きい ### `leader-transfer-max-log-lag` {#leader-transfer-max-log-lag} -- Raftリーダーの交代時に、譲受人に許可される欠落ログの最大数 -- デフォルト値: `128` -- 最小値: `10` +- Raftリーダーの交代時に、譲受人に許可される欠落ログの最大数 +- デフォルト値: `128` +- 最小値: `10` ### `max-snapshot-file-raw-size` v6.1.0で追加 {#max-snapshot-file-raw-size-new-in-v610} -- スナップショットファイルのサイズがこの設定値を超えると、そのファイルは複数のファイルに分割されます。 -- デフォルト値: `100MiB` -- 最小値: `100MiB` +- スナップショットファイルのサイズがこの設定値を超えると、そのファイルは複数のファイルに分割されます。 +- デフォルト値: `100MiB` +- 最小値: `100MiB` ### `snap-apply-batch-size` {#snap-apply-batch-size} -- インポートされたスナップショットファイルがディスクに書き込まれる際に必要なメモリキャッシュサイズ -- デフォルト値: `"10MiB"` -- 最小値: `0` -- 単位: MiB +- インポートされたスナップショットファイルがディスクに書き込まれる際に必要なメモリキャッシュサイズ +- デフォルト値: `"10MiB"` +- 最小値: `0` +- 単位: MiB ### `consistency-check-interval` {#consistency-check-interval} @@ -1061,119 +1061,119 @@ Raftstoreに関連するコンフィグレーション項目。 > > クラスタのパフォーマンスに影響を与え、TiDBのガベージコレクションと互換性がないため、本番環境では整合性チェックを有効にすることは推奨され**ません**。 -- 整合性チェックがトリガーされる時間間隔。 `0`はこの機能が無効になっていることを意味します。 -- デフォルト値: `"0s"` -- 最小値: `0` +- 整合性チェックがトリガーされる時間間隔。 `0`はこの機能が無効になっていることを意味します。 +- デフォルト値: `"0s"` +- 最小値: `0` ### `raft-store-max-leader-lease` {#raft-store-max-leader-lease} -- Raftリーダーとして最も長く信頼された期間 -- デフォルト値: `"9s"` -- 最小値: `0` +- Raftリーダーとして最も長く信頼された期間 +- デフォルト値: `"9s"` +- 最小値: `0` ### `right-derive-when-split` {#right-derive-when-split} -- リージョンが分割されたときに、新しいリージョンの開始キーを指定します。この設定項目が`true`に設定されている場合、開始キーは最大分割キーになります。この設定項目が`false`に設定されている場合、開始キーは元のリージョンの開始キーになります。 -- デフォルト値: `true` +- リージョンが分割されたときに、新しいリージョンの開始キーを指定します。この設定項目が`true`に設定されている場合、開始キーは最大分割キーになります。この設定項目が`false`に設定されている場合、開始キーは元のリージョンの開始キーになります。 +- デフォルト値: `true` ### `merge-max-log-gap` {#merge-max-log-gap} -- `merge`が実行されたときに許容される欠落ログの最大数 -- デフォルト値: `10` -- 最小値: `raft-log-gc-count-limit`より大きい +- `merge`が実行されたときに許容される欠落ログの最大数 +- デフォルト値: `10` +- 最小値: `raft-log-gc-count-limit`より大きい ### `merge-check-tick-interval` {#merge-check-tick-interval} -- TiKVがリージョンのマージが必要かどうかを確認する時間間隔 -- デフォルト値: `"2s"` -- 最小値: `0`より大きい +- TiKVがリージョンのマージが必要かどうかを確認する時間間隔 +- デフォルト値: `"2s"` +- 最小値: `0`より大きい ### `use-delete-range` {#use-delete-range} -- `rocksdb delete_range`インターフェースからデータを削除するかどうかを決定します。 -- デフォルト値: `false` +- `rocksdb delete_range`インターフェースからデータを削除するかどうかを決定します。 +- デフォルト値: `false` ### `cleanup-import-sst-interval` {#cleanup-import-sst-interval} -- 期限切れの SST ファイルがチェックされる時間間隔。 `0`はこの機能が無効になっていることを意味します。 -- デフォルト値: `"10m"` -- 最小値: `0` +- 期限切れの SST ファイルがチェックされる時間間隔。 `0`はこの機能が無効になっていることを意味します。 +- デフォルト値: `"10m"` +- 最小値: `0` ### `local-read-batch-size` {#local-read-batch-size} -- 1バッチで処理される読み取りリクエストの最大数 -- デフォルト値: `1024` -- 最小値: `0`より大きい +- 1バッチで処理される読み取りリクエストの最大数 +- デフォルト値: `1024` +- 最小値: `0`より大きい ### `apply-yield-write-size` v6.4.0で追加 {#apply-yield-write-size-new-in-v640} -- Applyスレッドが1回のポーリングで1つのFSM（有限状態機械）に対して書き込むことができる最大バイト数。これはソフトリミットです。 -- デフォルト値: `"32KiB"` -- 最小値: `0`より大きい -- 単位：KiB｜MiB｜GiB +- Applyスレッドが1回のポーリングで1つのFSM（有限状態機械）に対して書き込むことができる最大バイト数。これはソフトリミットです。 +- デフォルト値: `"32KiB"` +- 最小値: `0`より大きい +- 単位：KiB｜MiB｜GiB ### `apply-max-batch-size` {#apply-max-batch-size} -- Raftステートマシンは、BatchSystemによってデータ書き込み要求をバッチ処理します。この設定項目は、1つのバッチで要求を処理できるRaftステートマシンの最大数を指定します。 -- デフォルト値: `256` -- 最小値: `0`より大きい -- 最大値: `10240` +- Raftステートマシンは、BatchSystemによってデータ書き込み要求をバッチ処理します。この設定項目は、1つのバッチで要求を処理できるRaftステートマシンの最大数を指定します。 +- デフォルト値: `256` +- 最小値: `0`より大きい +- 最大値: `10240` ### `apply-pool-size` {#apply-pool-size} -- データをディスクにフラッシュするプール内のスレッドの許容数。これは、適用スレッド プールのサイズです。このスレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 -- デフォルト値: `2` -- 値の範囲: `[1, CPU * 10]` 。 `CPU`はCPU コアの数を表します。 +- データをディスクにフラッシュするプール内のスレッドの許容数。これは、適用スレッド プールのサイズです。このスレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- デフォルト値: `2` +- 値の範囲: `[1, CPU * 10]` 。 `CPU`はCPU コアの数を表します。 ### `store-max-batch-size` {#store-max-batch-size} -- Raftステートマシンは、BatchSystemによってログをディスクに書き込む要求をバッチ処理します。この設定項目は、1つのバッチで要求を処理できるRaftステートマシンの最大数を指定します。 -- `hibernate-regions`が有効になっている場合、デフォルト値は`256`です。 `hibernate-regions`が無効になっている場合、デフォルト値は`1024`です。 -- 最小値: `0`より大きい -- 最大値: `10240` +- Raftステートマシンは、BatchSystemによってログをディスクに書き込む要求をバッチ処理します。この設定項目は、1つのバッチで要求を処理できるRaftステートマシンの最大数を指定します。 +- `hibernate-regions`が有効になっている場合、デフォルト値は`256`です。 `hibernate-regions`が無効になっている場合、デフォルト値は`1024`です。 +- 最小値: `0`より大きい +- 最大値: `10240` ### `store-pool-size` {#store-pool-size} -- Raftを処理するプール内のスレッドの許容数。これはRaftstoreスレッド プールのサイズです。このスレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 -- デフォルト値: `2` -- 値の範囲: `[1, CPU * 10]` 。 `CPU`はCPU コアの数を表します。 +- Raftを処理するプール内のスレッドの許容数。これはRaftstoreスレッド プールのサイズです。このスレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- デフォルト値: `2` +- 値の範囲: `[1, CPU * 10]` 。 `CPU`はCPU コアの数を表します。 ### `store-io-pool-size` v5.3.0で追加 {#store-io-pool-size-new-in-v530} -- Raft I/O タスクを処理するスレッドの許容数。これは StoreWriter スレッド プールのサイズです。このスレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 -- デフォルト値: `1` (v8.0.0 より前のバージョンでは、デフォルト値は`0`でした) -- 最小値: `0` +- Raft I/O タスクを処理するスレッドの許容数。これは StoreWriter スレッド プールのサイズです。このスレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- デフォルト値: `1` (v8.0.0 より前のバージョンでは、デフォルト値は`0`でした) +- 最小値: `0` ### `future-poll-size` {#future-poll-size} -- `future`を駆動するスレッドの許容数 -- デフォルト値: `1` -- 最小値: `0`より大きい +- `future`を駆動するスレッドの許容数 +- デフォルト値: `1` +- 最小値: `0`より大きい ### `cmd-batch` {#cmd-batch} -- リクエストのバッチ処理を有効にするかどうかを制御します。有効にすると、書き込みパフォーマンスが大幅に向上します。 -- デフォルト値: `true` +- リクエストのバッチ処理を有効にするかどうかを制御します。有効にすると、書き込みパフォーマンスが大幅に向上します。 +- デフォルト値: `true` ### `inspect-interval` {#inspect-interval} -- TiKVは一定間隔でRaftstoreコンポーネントのレイテンシーを検査します。このパラメータは検査間隔を指定します。レイテンシーがこの値を超えると、この検査はタイムアウトとしてマークされます。 -- タイムアウト検査の比率に基づいて、TiKVノードが遅いかどうかを判断します。 -- デフォルト値: `"100ms"` -- 最小値: `"1ms"` +- TiKVは一定間隔でRaftstoreコンポーネントのレイテンシーを検査します。このパラメータは検査間隔を指定します。レイテンシーがこの値を超えると、この検査はタイムアウトとしてマークされます。 +- タイムアウト検査の比率に基づいて、TiKVノードが遅いかどうかを判断します。 +- デフォルト値: `"100ms"` +- 最小値: `"1ms"` ### `raft-write-size-limit` v5.3.0で追加 {#raft-write-size-limit-new-in-v530} -- Raftデータがディスクに書き込まれるしきい値を決定します。データサイズがこの構成項目の値よりも大きい場合、データはディスクに書き込まれます。 `store-io-pool-size`の値が`0`の場合、この構成項目は有効になりません。 -- デフォルト値: `1MiB` -- 最小値: `0` +- Raftデータがディスクに書き込まれるしきい値を決定します。データサイズがこの構成項目の値よりも大きい場合、データはディスクに書き込まれます。 `store-io-pool-size`の値が`0`の場合、この構成項目は有効になりません。 +- デフォルト値: `1MiB` +- 最小値: `0` ### `evict-cache-on-memory-ratio` （v7.5.0で追加） {#evict-cache-on-memory-ratio-new-in-v750} -- TiKV のメモリ使用量がシステムで使用可能なメモリの 90% を超え、 Raftエントリ キャッシュによって占有されているメモリが使用済みメモリ* `evict-cache-on-memory-ratio`を超えると、TiKV はRaftエントリ キャッシュを追い出します。 -- この値が`0`に設定されている場合、この機能は無効になっています。 -- デフォルト値: `0.1` -- 最小値: `0` +- TiKV のメモリ使用量がシステムで使用可能なメモリの 90% を超え、 Raftエントリ キャッシュによって占有されているメモリが使用済みメモリ* `evict-cache-on-memory-ratio`を超えると、TiKV はRaftエントリ キャッシュを追い出します。 +- この値が`0`に設定されている場合、この機能は無効になっています。 +- デフォルト値: `0.1` +- 最小値: `0` ### `periodic-full-compact-start-times` （v7.6.0の新機能） {#periodic-full-compact-start-times-new-in-v760} @@ -1181,52 +1181,52 @@ Raftstoreに関連するコンフィグレーション項目。 > > 定期的な完全圧縮は実験的です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -- TiKVが定期的な完全圧縮を開始する具体的な時刻を設定します。配列で複数の時刻スケジュールを指定できます。例： - - `periodic-full-compact-start-times = ["03:00", "23:00"]`は、TiKVノードの現地時間に基づいて、TiKVが毎日午前3時と午後11時に完全な圧縮を実行することを示しています。 - - `periodic-full-compact-start-times = ["03:00 +0000", "23:00 +0000"]`は、TiKVがUTCタイムゾーンで毎日午前3時と午後11時に完全な圧縮を実行することを示しています。 - - `periodic-full-compact-start-times = ["03:00 +0800", "23:00 +0800"]`は、TiKVがUTC+08:00タイムゾーンで毎日午前3時と午後11時に完全な圧縮を実行することを示しています。 -- デフォルト値: `[]`は、定期的な完全圧縮がデフォルトで無効になっていることを意味します。 +- TiKVが定期的な完全圧縮を開始する具体的な時刻を設定します。配列で複数の時刻スケジュールを指定できます。例： + - `periodic-full-compact-start-times = ["03:00", "23:00"]`は、TiKVノードの現地時間に基づいて、TiKVが毎日午前3時と午後11時に完全な圧縮を実行することを示しています。 + - `periodic-full-compact-start-times = ["03:00 +0000", "23:00 +0000"]`は、TiKVがUTCタイムゾーンで毎日午前3時と午後11時に完全な圧縮を実行することを示しています。 + - `periodic-full-compact-start-times = ["03:00 +0800", "23:00 +0800"]`は、TiKVがUTC+08:00タイムゾーンで毎日午前3時と午後11時に完全な圧縮を実行することを示しています。 +- デフォルト値: `[]`は、定期的な完全圧縮がデフォルトで無効になっていることを意味します。 ### `periodic-full-compact-start-max-cpu` v7.6.0で追加 {#periodic-full-compact-start-max-cpu-new-in-v760} -- TiKVの定期的な完全圧縮におけるCPU使用率の上限を制限します。 -- デフォルト値: `0.1` 、定期的な圧縮処理の最大 CPU 使用率が 10% であることを意味します。 +- TiKVの定期的な完全圧縮におけるCPU使用率の上限を制限します。 +- デフォルト値: `0.1` 、定期的な圧縮処理の最大 CPU 使用率が 10% であることを意味します。 ### `follower-read-max-log-gap` v7.4.0の新機能 {#follower-read-max-log-gap-new-in-v740} -- フォロワーが読み取りリクエストを処理する際に、遅延が許容されるログの最大数。この制限を超えると、読み取りリクエストは拒否されます。 -- デフォルト値: `100` +- フォロワーが読み取りリクエストを処理する際に、遅延が許容されるログの最大数。この制限を超えると、読み取りリクエストは拒否されます。 +- デフォルト値: `100` ### `inspect-cpu-util-thd` v7.6.0で追加 {#inspect-cpu-util-thd-new-in-v760} -- 低速ノード検出時に、TiKVノードがビジー状態かどうかを判断するためのCPU使用率のしきい値。 -- 値の範囲: `[0, 1]` -- デフォルト値: `0.4` 、つまり`40%`です。 +- 低速ノード検出時に、TiKVノードがビジー状態かどうかを判断するためのCPU使用率のしきい値。 +- 値の範囲: `[0, 1]` +- デフォルト値: `0.4` 、つまり`40%`です。 ### `inspect-kvdb-interval` v8.1.2で追加 {#inspect-kvdb-interval-new-in-v812} -- TiKV の低速ノード検出時に KV ディスクをチェックする間隔とタイムアウト。KVDB と RaftDB が同じマウント パスを共有している場合、この値は`0` (検出なし) で上書きされます。 -- デフォルト値: `100ms` 。v8.5.2 以前のバージョンでは、デフォルト値は`2s`です。 +- TiKV の低速ノード検出時に KV ディスクをチェックする間隔とタイムアウト。KVDB と RaftDB が同じマウント パスを共有している場合、この値は`0` (検出なし) で上書きされます。 +- デフォルト値: `100ms` 。v8.5.2 以前のバージョンでは、デフォルト値は`2s`です。 ### `min-pending-apply-region-count` v8.0.0で追加 {#min-pending-apply-region-count-new-in-v800} -- TiKV起動時にRaftログ適用中のビジー状態にあるリージョンの最大数。Raftstoreは、このようなリージョンの数がこの値以下の場合にのみリーダー転送を受け入れ、ローリング再起動時の可用性低下を軽減します。 -- デフォルト値: `10` +- TiKV起動時にRaftログ適用中のビジー状態にあるリージョンの最大数。Raftstoreは、このようなリージョンの数がこの値以下の場合にのみリーダー転送を受け入れ、ローリング再起動時の可用性低下を軽減します。 +- デフォルト値: `10` ### `request-voter-replicated-index-interval` v6.6.0で追加 {#request-voter-replicated-index-interval-new-in-v660} -- Witnessノードが定期的に投票ノードから複製されたRaftログの位置を取得する間隔を制御します。 -- デフォルト値： `5m` 、これは5分を意味します。 +- Witnessノードが定期的に投票ノードから複製されたRaftログの位置を取得する間隔を制御します。 +- デフォルト値： `5m` 、これは5分を意味します。 ### `slow-trend-unsensitive-cause` v6.6.0の新機能 {#slow-trend-unsensitive-cause-new-in-v660} -- TiKVがSlowTrend検出アルゴリズムを使用する場合、この設定項目はレイテンシー検出の感度を制御します。値が大きいほど感度は低くなります。 -- デフォルト値: `10` +- TiKVがSlowTrend検出アルゴリズムを使用する場合、この設定項目はレイテンシー検出の感度を制御します。値が大きいほど感度は低くなります。 +- デフォルト値: `10` ### `slow-trend-unsensitive-result` v6.6.0 の新機能 {#slow-trend-unsensitive-result-new-in-v660} -- TiKVがSlowTrend検出アルゴリズムを使用する場合、この設定項目はQPS検出の感度を制御します。値が大きいほど感度は低くなります。 -- デフォルト値: `0.5` +- TiKVがSlowTrend検出アルゴリズムを使用する場合、この設定項目はQPS検出の感度を制御します。値が大きいほど感度は低くなります。 +- デフォルト値: `0.5` ## coprocessor {#coprocessor} @@ -1234,66 +1234,66 @@ Raftstoreに関連するコンフィグレーション項目。 ### `split-region-on-table` {#split-region-on-table} -- リージョンをテーブルごとに分割するかどうかを決定します。この機能はTiDBモードでのみ使用することをお勧めします。 -- デフォルト値: `false` +- リージョンをテーブルごとに分割するかどうかを決定します。この機能はTiDBモードでのみ使用することをお勧めします。 +- デフォルト値: `false` ### `batch-split-limit` {#batch-split-limit} -- バッチ処理におけるリージョン分割のしきい値。この値を大きくすると、リージョン分割が高速化されます。 -- デフォルト値: `10` -- 最小値: `1` +- バッチ処理におけるリージョン分割のしきい値。この値を大きくすると、リージョン分割が高速化されます。 +- デフォルト値: `10` +- 最小値: `1` ### `region-max-size` {#region-max-size} -- リージョンの最大サイズ。この値を超えると、リージョンは複数のリージョンに分割されます。 -- デフォルト値: `region-split-size / 2 * 3` -- 単位：KiB｜MiB｜GiB +- リージョンの最大サイズ。この値を超えると、リージョンは複数のリージョンに分割されます。 +- デフォルト値: `region-split-size / 2 * 3` +- 単位：KiB｜MiB｜GiB ### `region-split-size` {#region-split-size} -- 分割後のリージョンのサイズ。この値は概算値です。 -- デフォルト値: `"256MiB"` 。v8.4.0 より前のバージョンでは、デフォルト値は`"96MiB"`です。 -- 単位：KiB｜MiB｜GiB +- 分割後のリージョンのサイズ。この値は概算値です。 +- デフォルト値: `"256MiB"` 。v8.4.0 より前のバージョンでは、デフォルト値は`"96MiB"`です。 +- 単位：KiB｜MiB｜GiB ### `region-max-keys` {#region-max-keys} -- リージョン内で許容されるキーの最大数。この値を超えると、リージョンは複数のリージョンに分割されます。 -- デフォルト値: `region-split-keys / 2 * 3` +- リージョン内で許容されるキーの最大数。この値を超えると、リージョンは複数のリージョンに分割されます。 +- デフォルト値: `region-split-keys / 2 * 3` ### `region-split-keys` {#region-split-keys} -- 新しく分割されたリージョン内のキーの数。この値は概算値です。 -- デフォルト値: `2560000` 。v8.4.0 より前のバージョンでは、デフォルト値は`960000`です。 +- 新しく分割されたリージョン内のキーの数。この値は概算値です。 +- デフォルト値: `2560000` 。v8.4.0 より前のバージョンでは、デフォルト値は`960000`です。 ### `consistency-check-method` {#consistency-check-method} -- データ整合性チェックの方法を指定します。 -- MVCCデータの整合性チェックの場合は、値を`"mvcc"`に設定します。生データの整合性チェックの場合は、値を`"raw"`に設定します。 -- デフォルト値: `"mvcc"` +- データ整合性チェックの方法を指定します。 +- MVCCデータの整合性チェックの場合は、値を`"mvcc"`に設定します。生データの整合性チェックの場合は、値を`"raw"`に設定します。 +- デフォルト値: `"mvcc"` ## coprocessor.v2 {#coprocessor-v2} ### `coprocessor-plugin-directory` {#coprocessor-plugin-directory} -- コンパイル済みのコプロセッサプラグインが格納されているディレクトリのパス。このディレクトリ内のプラグインはTiKVによって自動的にロードされます。 -- この設定項目が設定されていない場合、コプロセッサプラグインは無効になります。 -- デフォルト値: なし +- コンパイル済みのコプロセッサプラグインが格納されているディレクトリのパス。このディレクトリ内のプラグインはTiKVによって自動的にロードされます。 +- この設定項目が設定されていない場合、コプロセッサプラグインは無効になります。 +- デフォルト値: なし ### `enable-region-bucket` v6.1.0の新機能 {#enable-region-bucket-new-in-v610} -- リージョンをバケットと呼ばれる小さな範囲に分割するかどうかを決定します。バケットは、スキャンの同時実行性を向上させるために同時クエリの単位として使用されます。バケットの設計の詳細については、 [動的サイズリージョン](https://github.com/tikv/rfcs/blob/master/text/0082-dynamic-size-region.md)を参照してください。 -- デフォルト値：なし。これは、デフォルトで無効になっていることを意味します。 +- リージョンをバケットと呼ばれる小さな範囲に分割するかどうかを決定します。バケットは、スキャンの同時実行性を向上させるために同時クエリの単位として使用されます。バケットの設計の詳細については、 [動的サイズリージョン](https://github.com/tikv/rfcs/blob/master/text/0082-dynamic-size-region.md)を参照してください。 +- デフォルト値：なし。これは、デフォルトで無効になっていることを意味します。 > **Warning:** > -> - `enable-region-bucket`は、TiDB v6.1.0 で導入された実験的機能です。本番環境での使用は推奨されません。 -> - この設定は、 `region-split-size`が`region-bucket-size`の 2 倍以上である場合にのみ有効です。それ以外の場合は、バケットは実際には生成されません。 -> - `region-split-size`をより大きな値に調整すると、パフォーマンスの低下やスケジューリングの遅延のリスクが生じる可能性があります。 +> - `enable-region-bucket`は、TiDB v6.1.0 で導入された実験的機能です。本番環境での使用は推奨されません。 +> - この設定は、 `region-split-size`が`region-bucket-size`の 2 倍以上である場合にのみ有効です。それ以外の場合は、バケットは実際には生成されません。 +> - `region-split-size`をより大きな値に調整すると、パフォーマンスの低下やスケジューリングの遅延のリスクが生じる可能性があります。 ### `region-bucket-size` v6.1.0の新機能 {#region-bucket-size-new-in-v610} -- `enable-region-bucket`が真のときのバケットのサイズ。 -- デフォルト値: v7.3.0 以降、デフォルト値は`96MiB`から`50MiB`に変更されました。 +- `enable-region-bucket`が真のときのバケットのサイズ。 +- デフォルト値: v7.3.0 以降、デフォルト値は`96MiB`から`50MiB`に変更されました。 > **Warning:** > @@ -1305,151 +1305,151 @@ RocksDBに関連するコンフィグレーション項目 ### `max-background-jobs` {#max-background-jobs-1} -- RocksDB のバックグラウンド スレッドの数。 RocksDB スレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 -- デフォルト値: - - CPUコア数が10の場合、デフォルト値は`9`です。 - - CPUコア数が8の場合、デフォルト値は`7`です。 - - CPUコア数が`N`の場合、デフォルト値は`max(2, min(N - 1, 9))`です。 -- 最小値: `2` +- RocksDB のバックグラウンド スレッドの数。 RocksDB スレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- デフォルト値: + - CPUコア数が10の場合、デフォルト値は`9`です。 + - CPUコア数が8の場合、デフォルト値は`7`です。 + - CPUコア数が`N`の場合、デフォルト値は`max(2, min(N - 1, 9))`です。 +- 最小値: `2` ### `max-background-flushes` {#max-background-flushes} -- 同時実行可能なバックグラウンド memtable フラッシュ ジョブの最大数 -- デフォルト値: - - CPUコア数が10の場合、デフォルト値は`3`です。 - - CPUコア数が8の場合、デフォルト値は`2`です。 - - CPUコア数が`N`の場合、デフォルト値は`[(max-background-jobs + 3) / 4]`です。 -- 最小値: `1` +- 同時実行可能なバックグラウンド memtable フラッシュ ジョブの最大数 +- デフォルト値: + - CPUコア数が10の場合、デフォルト値は`3`です。 + - CPUコア数が8の場合、デフォルト値は`2`です。 + - CPUコア数が`N`の場合、デフォルト値は`[(max-background-jobs + 3) / 4]`です。 +- 最小値: `1` ### `max-sub-compactions` {#max-sub-compactions-1} -- RocksDBで同時に実行されたサブコンパクション操作の数 -- デフォルト値: `3` -- 最小値: `1` +- RocksDBで同時に実行されたサブコンパクション操作の数 +- デフォルト値: `3` +- 最小値: `1` ### `max-open-files` {#max-open-files-1} -- RocksDBが開くことができるファイルの総数 -- デフォルト値: `40960` -- 最小値: `-1` +- RocksDBが開くことができるファイルの総数 +- デフォルト値: `40960` +- 最小値: `-1` ### `max-manifest-file-size` {#max-manifest-file-size-1} -- RocksDBマニフェストファイルの最大サイズ -- デフォルト値: `"256MiB"` 。v8.5.3 およびそれ以前の v8.5.x バージョンでは、デフォルト値は`"128MiB"`です。 -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- RocksDBマニフェストファイルの最大サイズ +- デフォルト値: `"256MiB"` 。v8.5.3 およびそれ以前の v8.5.x バージョンでは、デフォルト値は`"128MiB"`です。 +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `create-if-missing` {#create-if-missing-1} -- DBスイッチを自動的に作成するかどうかを決定します -- デフォルト値: `true` +- DBスイッチを自動的に作成するかどうかを決定します +- デフォルト値: `true` ### `wal-recovery-mode` {#wal-recovery-mode} -- WALリカバリモード -- オプション値: - - `"tolerate-corrupted-tail-records"` : すべてのログで不完全な末尾データを持つレコードを許容し、破棄します。 - - `"absolute-consistency"` : 破損したログが見つかった場合、リカバリを中止します - - `"point-in-time"` : 破損したログが最初に見つかるまで、ログを順次復元します。 - - `"skip-any-corrupted-records"` :ディザスタリカバリ。データは可能な限り復旧され、破損したレコードはスキップされます。 -- デフォルト値: `"point-in-time"` +- WALリカバリモード +- オプション値: + - `"tolerate-corrupted-tail-records"` : すべてのログで不完全な末尾データを持つレコードを許容し、破棄します。 + - `"absolute-consistency"` : 破損したログが見つかった場合、リカバリを中止します + - `"point-in-time"` : 破損したログが最初に見つかるまで、ログを順次復元します。 + - `"skip-any-corrupted-records"` :ディザスタリカバリ。データは可能な限り復旧され、破損したレコードはスキップされます。 +- デフォルト値: `"point-in-time"` ### `wal-dir` {#wal-dir-1} -- WALファイルが保存されるディレクトリ。指定しない場合、WALファイルはデータと同じディレクトリに保存されます。 -- デフォルト値: `""` +- WALファイルが保存されるディレクトリ。指定しない場合、WALファイルはデータと同じディレクトリに保存されます。 +- デフォルト値: `""` ### `wal-ttl-seconds` {#wal-ttl-seconds-1} -- アーカイブされたWALファイルの有効期間。この値を超えると、システムはこれらのファイルを削除します。 -- デフォルト値: `0` -- 最小値: `0` -- 単位：秒 +- アーカイブされたWALファイルの有効期間。この値を超えると、システムはこれらのファイルを削除します。 +- デフォルト値: `0` +- 最小値: `0` +- 単位：秒 ### `wal-size-limit` {#wal-size-limit-1} -- アーカイブされたWALファイルのサイズ制限。この値を超えると、システムはこれらのファイルを削除します。 -- デフォルト値: `0` -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- アーカイブされたWALファイルのサイズ制限。この値を超えると、システムはこれらのファイルを削除します。 +- デフォルト値: `0` +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `max-total-wal-size` {#max-total-wal-size-1} -- RocksDB WAL の最大サイズは合計で、 `data-dir`内の`*.log`ファイルのサイズです。 -- デフォルト値: +- RocksDB WAL の最大サイズは合計で、 `data-dir`内の`*.log`ファイルのサイズです。 +- デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は`"4GiB"`です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`1`です。 + - `storage.engine="raft-kv"`の場合、デフォルト値は`"4GiB"`です。 + - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`1`です。 ### `stats-dump-period` {#stats-dump-period-1} -- 統計情報がログに出力される間隔。 -- デフォルト値: +- 統計情報がログに出力される間隔。 +- デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は`"10m"`です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`"0"`です。 + - `storage.engine="raft-kv"`の場合、デフォルト値は`"10m"`です。 + - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`"0"`です。 ### `compaction-readahead-size` {#compaction-readahead-size-1} -- RocksDBの圧縮処理中に先読み機能を有効にし、先読みデータのサイズを指定します。機械式ディスクを使用している場合は、少なくとも2MiBに設定することをお勧めします。 -- デフォルト値: `0` -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- RocksDBの圧縮処理中に先読み機能を有効にし、先読みデータのサイズを指定します。機械式ディスクを使用している場合は、少なくとも2MiBに設定することをお勧めします。 +- デフォルト値: `0` +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `writable-file-max-buffer-size` {#writable-file-max-buffer-size-1} -- WritableFileWriteで使用される最大バッファサイズ -- デフォルト値: `"1MiB"` -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- WritableFileWriteで使用される最大バッファサイズ +- デフォルト値: `"1MiB"` +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `use-direct-io-for-flush-and-compaction` {#use-direct-io-for-flush-and-compaction-1} -- バックグラウンドのフラッシュと圧縮における読み取りと書き込みの両方で`O_DIRECT`を使用するかどうかを決定します。このオプションのパフォーマンスへの影響: `O_DIRECT`を有効にすると、OS バッファ キャッシュの汚染がバイパスされ防止されますが、後続のファイル読み取りではバッファ キャッシュの内容を再読み込みする必要があります。 -- デフォルト値: `false` +- バックグラウンドのフラッシュと圧縮における読み取りと書き込みの両方で`O_DIRECT`を使用するかどうかを決定します。このオプションのパフォーマンスへの影響: `O_DIRECT`を有効にすると、OS バッファ キャッシュの汚染がバイパスされ防止されますが、後続のファイル読み取りではバッファ キャッシュの内容を再読み込みする必要があります。 +- デフォルト値: `false` ### `rate-bytes-per-sec` {#rate-bytes-per-sec} -- Titanが無効になっている場合、この設定項目はRocksDB圧縮のI/Oレートを制限し、トラフィックのピーク時にRocksDB圧縮がフォアグラウンドの読み取りおよび書き込みパフォーマンスに与える影響を軽減します。Titanが有効になっている場合、この設定項目はRocksDB圧縮とTitan GCの合計I/Oレートを制限します。RocksDB圧縮とTitan GCのI/OまたはCPU消費量が大きすぎる場合は、ディスクI/O帯域幅と実際の書き込みトラフィックに応じて、この設定項目を適切な値に設定してください。 -- デフォルト値: `10GiB` -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- Titanが無効になっている場合、この設定項目はRocksDB圧縮のI/Oレートを制限し、トラフィックのピーク時にRocksDB圧縮がフォアグラウンドの読み取りおよび書き込みパフォーマンスに与える影響を軽減します。Titanが有効になっている場合、この設定項目はRocksDB圧縮とTitan GCの合計I/Oレートを制限します。RocksDB圧縮とTitan GCのI/OまたはCPU消費量が大きすぎる場合は、ディスクI/O帯域幅と実際の書き込みトラフィックに応じて、この設定項目を適切な値に設定してください。 +- デフォルト値: `10GiB` +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `rate-limiter-refill-period` {#rate-limiter-refill-period} -- I/Oトークンの補充頻度を制御します。値を小さくするとI/Oバーストは減少しますが、CPU負荷が増加します。 -- デフォルト値: `"100ms"` +- I/Oトークンの補充頻度を制御します。値を小さくするとI/Oバーストは減少しますが、CPU負荷が増加します。 +- デフォルト値: `"100ms"` ### `rate-limiter-mode` {#rate-limiter-mode} -- RocksDBの圧縮速度制限モード -- オプション値: `"read-only"` 、 `"write-only"` 、 `"all-io"` -- デフォルト値: `"write-only"` +- RocksDBの圧縮速度制限モード +- オプション値: `"read-only"` 、 `"write-only"` 、 `"all-io"` +- デフォルト値: `"write-only"` ### `rate-limiter-auto-tuned` v5.0の新機能 {#rate-limiter-auto-tuned-new-in-v50} -- 最近のワークロードに基づいて、RocksDBの圧縮レート制限設定を自動的に最適化するかどうかを決定します。この設定を有効にすると、圧縮待ちバイト数が通常よりも若干多くなります。 -- デフォルト値: `true` +- 最近のワークロードに基づいて、RocksDBの圧縮レート制限設定を自動的に最適化するかどうかを決定します。この設定を有効にすると、圧縮待ちバイト数が通常よりも若干多くなります。 +- デフォルト値: `true` ### `enable-pipelined-write` {#enable-pipelined-write-1} -- パイプライン書き込みを有効にするかどうかを制御します。この設定を有効にすると、従来のパイプライン書き込みが使用されます。この設定を無効にすると、新しいパイプラインコミットメカニズムが使用されます。 -- デフォルト値: `false` +- パイプライン書き込みを有効にするかどうかを制御します。この設定を有効にすると、従来のパイプライン書き込みが使用されます。この設定を無効にすると、新しいパイプラインコミットメカニズムが使用されます。 +- デフォルト値: `false` ### `bytes-per-sync` {#bytes-per-sync-1} -- OSがファイルをディスクに増分的に同期する速度（これらのファイルが非同期的に書き込まれている間） -- デフォルト値: `"1MiB"` -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- OSがファイルをディスクに増分的に同期する速度（これらのファイルが非同期的に書き込まれている間） +- デフォルト値: `"1MiB"` +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `wal-bytes-per-sync` {#wal-bytes-per-sync-1} -- OSがWALファイルの書き込み中にWALファイルをディスクに増分同期する速度 -- デフォルト値: `"512KiB"` -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- OSがWALファイルの書き込み中にWALファイルをディスクに増分同期する速度 +- デフォルト値: `"512KiB"` +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `info-log-max-size` {#info-log-max-size-1} @@ -1457,10 +1457,10 @@ RocksDBに関連するコンフィグレーション項目 > > バージョン5.4.0以降、RocksDBログはTiKVのログモジュールによって管理されます。そのため、この設定項目は非推奨となり、その機能は設定項目[`log.file.max-size`](#max-size-new-in-v540)に置き換えられました。 -- 情報ログの最大サイズ -- デフォルト値: `"1GiB"` -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- 情報ログの最大サイズ +- デフォルト値: `"1GiB"` +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `info-log-roll-time` {#info-log-roll-time-1} @@ -1468,8 +1468,8 @@ RocksDBに関連するコンフィグレーション項目 > > バージョン5.4.0以降、RocksDBログはTiKVのログモジュールによって管理されるようになりました。そのため、この設定項目は非推奨です。TiKVは時間に基づく自動ログ分割をサポートしなくなりました。代わりに、設定項目[`log.file.max-size`](#max-size-new-in-v540)を使用して、ファイルサイズに基づく自動ログ分割のしきい値を設定できます。 -- Infoログが切り捨てられる時間間隔。値が`0s`の場合、ログは切り捨てられません。 -- デフォルト値: `"0s"` +- Infoログが切り捨てられる時間間隔。値が`0s`の場合、ログは切り捨てられません。 +- デフォルト値: `"0s"` ### `info-log-keep-log-file-num` {#info-log-keep-log-file-num-1} @@ -1477,14 +1477,14 @@ RocksDBに関連するコンフィグレーション項目 > > バージョン5.4.0以降、RocksDBログはTiKVのログモジュールによって管理されます。そのため、この設定項目は非推奨となり、その機能は設定項目[`log.file.max-backups`](#max-backups-new-in-v540)に置き換えられました。 -- 保持されるログファイルの最大数 -- デフォルト値: `10` -- 最小値: `0` +- 保持されるログファイルの最大数 +- デフォルト値: `10` +- 最小値: `0` ### `info-log-dir` {#info-log-dir-1} -- ログが保存されるディレクトリ -- デフォルト値: `""` +- ログが保存されるディレクトリ +- デフォルト値: `""` ### `info-log-level` {#info-log-level-1} @@ -1492,8 +1492,8 @@ RocksDBに関連するコンフィグレーション項目 > > バージョン5.4.0以降、RocksDBログはTiKVのログモジュールによって管理されます。そのため、この設定項目は非推奨となり、その機能は設定項目[`log.level`](#level-new-in-v540)に置き換えられました。 -- RocksDBのログレベル -- デフォルト値: `"info"` +- RocksDBのログレベル +- デフォルト値: `"info"` ### `write-buffer-flush-oldest-first` v6.6.0で追加 {#write-buffer-flush-oldest-first-new-in-v660} @@ -1501,12 +1501,12 @@ RocksDBに関連するコンフィグレーション項目 > > この機能は実験的です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -- 現在の RocksDB の`memtable`のメモリ使用量がしきい値に達したときに使用されるフラッシュ戦略を指定します。 -- デフォルト値: `false` -- 値のオプション： +- 現在の RocksDB の`memtable`のメモリ使用量がしきい値に達したときに使用されるフラッシュ戦略を指定します。 +- デフォルト値: `false` +- 値のオプション： - - `false` : データ量が最も大きい`memtable`が SST ファイルに書き込まれます。 - - `true` : 最も早い`memtable`が SST ファイルに書き込まれます。この戦略により`memtable`からコールドデータを消去できるため、コールドデータとホットデータが明確に存在するシナリオに適しています。 + - `false` : データ量が最も大きい`memtable`が SST ファイルに書き込まれます。 + - `true` : 最も早い`memtable`が SST ファイルに書き込まれます。この戦略により`memtable`からコールドデータを消去できるため、コールドデータとホットデータが明確に存在するシナリオに適しています。 ### `write-buffer-limit` v6.6.0で追加 {#write-buffer-limit-new-in-v660} @@ -1514,27 +1514,27 @@ RocksDBに関連するコンフィグレーション項目 > > この機能は実験的です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -- 単一の TiKV 内のすべての RocksDB インスタンスの合計メモリ制限を`memtable`に指定します。 `0`は制限なしを意味します。 +- 単一の TiKV 内のすべての RocksDB インスタンスの合計メモリ制限を`memtable`に指定します。 `0`は制限なしを意味します。 -- デフォルト値: +- デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は none で、制限なしを意味します。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値はシステムメモリ全体のサイズの 20% です。 + - `storage.engine="raft-kv"`の場合、デフォルト値は none で、制限なしを意味します。 + - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値はシステムメモリ全体のサイズの 20% です。 -- 単位：KiB｜MiB｜GiB +- 単位：KiB｜MiB｜GiB ### `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)を参照してください。 -- デフォルト値: `true` -- 値のオプション： - - `true` : WAL ファイルに関する情報を MANIFEST ファイルに記録し、起動時に WAL ファイルの整合性を検証します。 - - `false` : WAL ファイルに関する情報を MANIFEST ファイルに記録せず、起動時に WAL ファイルの整合性を検証しません。 +- RocksDB MANIFEST ファイルに先行書き込みログ (WAL) ファイルに関する情報を記録するかどうか、および起動時に WAL ファイルの整合性を検証するかどうかを制御します。詳細については、RocksDB [マニフェストでWALを追跡する](https://github.com/facebook/rocksdb/wiki/Track-WAL-in-MANIFEST)を参照してください。 +- デフォルト値: `true` +- 値のオプション： + - `true` : WAL ファイルに関する情報を MANIFEST ファイルに記録し、起動時に WAL ファイルの整合性を検証します。 + - `false` : WAL ファイルに関する情報を MANIFEST ファイルに記録せず、起動時に WAL ファイルの整合性を検証しません。 ### `enable-multi-batch-write` v6.2.0で追加 {#enable-multi-batch-write-new-in-v620} -- RocksDBの書き込み最適化を有効にするかどうかを制御します。有効にすると、WriteBatchの内容をmemtableに同時に書き込むことができ、書き込みレイテンシーが削減されます。 -- デフォルト値：なし。ただし、 `false`に明示的に設定するか、 `rocksdb.enable-pipelined-write`または`rocksdb.enable-unordered-write`が有効になっている場合を除き、デフォルトで有効になります。 +- RocksDBの書き込み最適化を有効にするかどうかを制御します。有効にすると、WriteBatchの内容をmemtableに同時に書き込むことができ、書き込みレイテンシーが削減されます。 +- デフォルト値：なし。ただし、 `false`に明示的に設定するか、 `rocksdb.enable-pipelined-write`または`rocksdb.enable-unordered-write`が有効になっている場合を除き、デフォルトで有効になります。 ## rocksdb.titan {#rocksdbtitan} @@ -1544,28 +1544,28 @@ Titanに関連するコンフィグレーション項目。 > **Note:** > -> - ワイドテーブルと JSON データの書き込みおよびポイントクエリのパフォーマンスを向上させるため、TiDB v7.6.0 以降、デフォルト値が`false`から`true`に変更され、Titan がデフォルトで有効になります。 -> - 既存のクラスターをv7.6.0以降のバージョンにアップグレードした場合、元の構成が保持されます。つまり、Titanが明示的に有効になっていない限り、引き続きRocksDBが使用されます。 -> - クラスターが TiDB v7.6.0 以降のバージョンにアップグレードする前に Titan を有効にしていた場合、アップグレード後も Titan は維持され、アップグレード前の[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)設定も維持されます。アップグレード前に明示的に値を設定しなかった場合、アップグレード後のクラスター構成の安定性を確保するため、以前のバージョンのデフォルト値`1KiB`が維持されます。 +> - ワイドテーブルと JSON データの書き込みおよびポイントクエリのパフォーマンスを向上させるため、TiDB v7.6.0 以降、デフォルト値が`false`から`true`に変更され、Titan がデフォルトで有効になります。 +> - 既存のクラスターをv7.6.0以降のバージョンにアップグレードした場合、元の構成が保持されます。つまり、Titanが明示的に有効になっていない限り、引き続きRocksDBが使用されます。 +> - クラスターが TiDB v7.6.0 以降のバージョンにアップグレードする前に Titan を有効にしていた場合、アップグレード後も Titan は維持され、アップグレード前の[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)設定も維持されます。アップグレード前に明示的に値を設定しなかった場合、アップグレード後のクラスター構成の安定性を確保するため、以前のバージョンのデフォルト値`1KiB`が維持されます。 -- Titanを有効または無効にします。 -- デフォルト値: `true` +- Titanを有効または無効にします。 +- デフォルト値: `true` ### `dirname` {#dirname} -- Titan Blobファイルが保存されているディレクトリ -- デフォルト値: `"titandb"` +- Titan Blobファイルが保存されているディレクトリ +- デフォルト値: `"titandb"` ### `disable-gc` {#disable-gc} -- TitanがBlobファイルに対して実行するガベージコレクション（GC）を無効にするかどうかを決定します。 -- デフォルト値: `false` +- TitanがBlobファイルに対して実行するガベージコレクション（GC）を無効にするかどうかを決定します。 +- デフォルト値: `false` ### `max-background-gc` {#max-background-gc} -- TitanにおけるGCスレッドの最大数。TiKV**の詳細** > **スレッドCPU** > **RocksDB CPU**パネルで、Titan GCスレッドが長時間フル稼働状態にあることが確認された場合は、Titan GCスレッドプールのサイズを増やすことを検討してください。 -- デフォルト値: `1` 。v8.0.0 より前のバージョンでは、デフォルト値は`4`です。 -- 最小値: `1` +- TitanにおけるGCスレッドの最大数。TiKV**の詳細** > **スレッドCPU** > **RocksDB CPU**パネルで、Titan GCスレッドが長時間フル稼働状態にあることが確認された場合は、Titan GCスレッドプールのサイズを増やすことを検討してください。 +- デフォルト値: `1` 。v8.0.0 より前のバージョンでは、デフォルト値は`4`です。 +- 最小値: `1` ## rocksdb.defaultcf | rocksdb.writecf | rocksdb.lockcf | rocksdb.raftcf {#rocksdbdefaultcf--rocksdbwritecf--rocksdblockcf--rocksdbraftcf} @@ -1573,11 +1573,11 @@ Titanに関連するコンフィグレーション項目。 ### `block-size` {#block-size} -- RocksDBブロックのデフォルトサイズ -- `defaultcf`および`writecf`のデフォルト値: `"32KiB"` -- `lockcf`のデフォルト値: `"16KiB"` -- 最小値: `"1KiB"` -- 単位：KiB｜MiB｜GiB +- RocksDBブロックのデフォルトサイズ +- `defaultcf`および`writecf`のデフォルト値: `"32KiB"` +- `lockcf`のデフォルト値: `"16KiB"` +- 最小値: `"1KiB"` +- 単位：KiB｜MiB｜GiB ### `block-cache-size` {#block-cache-size} @@ -1585,255 +1585,255 @@ Titanに関連するコンフィグレーション項目。 > > バージョン6.6.0以降、この設定は非推奨となりました。 -- RocksDBブロックのキャッシュサイズ。 -- `defaultcf`のデフォルト値: `Total machine memory * 25%` -- `writecf`のデフォルト値: `Total machine memory * 15%` -- `lockcf`のデフォルト値: `Total machine memory * 2%` -- 最小値: `0` -- 単位：KiB｜MiB｜GiB +- RocksDBブロックのキャッシュサイズ。 +- `defaultcf`のデフォルト値: `Total machine memory * 25%` +- `writecf`のデフォルト値: `Total machine memory * 15%` +- `lockcf`のデフォルト値: `Total machine memory * 2%` +- 最小値: `0` +- 単位：KiB｜MiB｜GiB ### `disable-block-cache` {#disable-block-cache} -- ブロックキャッシュを有効または無効にします -- デフォルト値: `false` +- ブロックキャッシュを有効または無効にします +- デフォルト値: `false` ### `cache-index-and-filter-blocks` {#cache-index-and-filter-blocks} -- インデックスとフィルタのキャッシュを有効または無効にします -- デフォルト値: `true` +- インデックスとフィルタのキャッシュを有効または無効にします +- デフォルト値: `true` ### `pin-l0-filter-and-index-blocks` {#pin-l0-filter-and-index-blocks} -- レベル 0 SST ファイルのインデックス ブロックとフィルタ ブロックをメモリに固定するかどうかを決定します。 -- デフォルト値: `true` +- レベル 0 SST ファイルのインデックス ブロックとフィルタ ブロックをメモリに固定するかどうかを決定します。 +- デフォルト値: `true` ### `use-bloom-filter` {#use-bloom-filter} -- ブルームフィルターを有効または無効にします -- デフォルト値: `true` +- ブルームフィルターを有効または無効にします +- デフォルト値: `true` ### `optimize-filters-for-hits` {#optimize-filters-for-hits} -- フィルターのヒット率を最適化するかどうかを決定します -- `defaultcf`のデフォルト値: `true` -- `writecf`および`lockcf`のデフォルト値: `false` +- フィルターのヒット率を最適化するかどうかを決定します +- `defaultcf`のデフォルト値: `true` +- `writecf`および`lockcf`のデフォルト値: `false` ### `optimize-filters-for-memory` v7.2.0の新機能 {#optimize-filters-for-memory-new-in-v720} -- メモリ内部の断片化を最小限に抑えるブルーム/リボンフィルタを生成するかどうかを決定します。 -- この設定項目は、 [`format-version`](#format-version-new-in-v620) 5以上の場合にのみ有効になることに注意してください。 -- デフォルト値: `false` +- メモリ内部の断片化を最小限に抑えるブルーム/リボンフィルタを生成するかどうかを決定します。 +- この設定項目は、 [`format-version`](#format-version-new-in-v620) 5以上の場合にのみ有効になることに注意してください。 +- デフォルト値: `false` ### `whole-key-filtering` {#whole-key-filtering} -- キー全体をブルームフィルターに適用するかどうかを決定します -- `defaultcf`および`lockcf`のデフォルト値: `true` -- `writecf`のデフォルト値: `false` +- キー全体をブルームフィルターに適用するかどうかを決定します +- `defaultcf`および`lockcf`のデフォルト値: `true` +- `writecf`のデフォルト値: `false` ### `bloom-filter-bits-per-key` {#bloom-filter-bits-per-key} -- ブルームフィルターが各キーに割り当てている長さ -- デフォルト値: `10` -- 単位：バイト +- ブルームフィルターが各キーに割り当てている長さ +- デフォルト値: `10` +- 単位：バイト ### `block-based-bloom-filter` {#block-based-bloom-filter} -- 各ブロックがブルームフィルターを作成するかどうかを決定します -- デフォルト値: `false` +- 各ブロックがブルームフィルターを作成するかどうかを決定します +- デフォルト値: `false` ### `ribbon-filter-above-level` v7.2.0の新機能 {#ribbon-filter-above-level-new-in-v720} -- この値以上のレベルではリボンフィルターを使用し、この値未満のレベルではブロックベースではないブルームフィルターを使用するかどうかを決定します。この設定項目が設定されている場合、 [`block-based-bloom-filter`](#block-based-bloom-filter)は無視されます。 -- この設定項目は、 [`format-version`](#format-version-new-in-v620) 5以上の場合にのみ有効になることに注意してください。 -- デフォルト値：なし。これは、デフォルトで無効になっていることを意味します。 +- この値以上のレベルではリボンフィルターを使用し、この値未満のレベルではブロックベースではないブルームフィルターを使用するかどうかを決定します。この設定項目が設定されている場合、 [`block-based-bloom-filter`](#block-based-bloom-filter)は無視されます。 +- この設定項目は、 [`format-version`](#format-version-new-in-v620) 5以上の場合にのみ有効になることに注意してください。 +- デフォルト値：なし。これは、デフォルトで無効になっていることを意味します。 ### `read-amp-bytes-per-bit` {#read-amp-bytes-per-bit} -- リード増幅の統計情報を有効または無効にします。 -- オプション値: `0` (無効)、> `0` (有効)。 -- デフォルト値: `0` -- 最小値: `0` +- リード増幅の統計情報を有効または無効にします。 +- オプション値: `0` (無効)、> `0` (有効)。 +- デフォルト値: `0` +- 最小値: `0` ### `compression-per-level` {#compression-per-level} -- 各レベルのデフォルトの圧縮アルゴリズム -- `defaultcf`のデフォルト値: ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"] -- `writecf`のデフォルト値: ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"] -- `lockcf`のデフォルト値: ["no", "no", "no", "no", "no", "no", "no"] +- 各レベルのデフォルトの圧縮アルゴリズム +- `defaultcf`のデフォルト値: ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"] +- `writecf`のデフォルト値: ["no", "no", "lz4", "lz4", "lz4", "zstd", "zstd"] +- `lockcf`のデフォルト値: ["no", "no", "no", "no", "no", "no", "no"] ### `bottommost-level-compression` {#bottommost-level-compression} -- 最下層の圧縮アルゴリズムを設定します。この設定項目は`compression-per-level`の設定を上書きします。 -- LSMツリーにデータが書き込まれると、RocksDBは最下層に対して`compression-per-level`配列で指定された最後の圧縮アルゴリズムを直接採用しません。 `bottommost-level-compression`を使用すると、最下層は最初から最も圧縮効果の高い圧縮アルゴリズムを使用できます。 -- 最下層の圧縮アルゴリズムを設定しない場合は、この設定項目の値を`disable`に設定してください。 -- デフォルト値: `"zstd"` +- 最下層の圧縮アルゴリズムを設定します。この設定項目は`compression-per-level`の設定を上書きします。 +- LSMツリーにデータが書き込まれると、RocksDBは最下層に対して`compression-per-level`配列で指定された最後の圧縮アルゴリズムを直接採用しません。 `bottommost-level-compression`を使用すると、最下層は最初から最も圧縮効果の高い圧縮アルゴリズムを使用できます。 +- 最下層の圧縮アルゴリズムを設定しない場合は、この設定項目の値を`disable`に設定してください。 +- デフォルト値: `"zstd"` ### `write-buffer-size` {#write-buffer-size} -- Memtableサイズ -- `defaultcf`および`writecf`のデフォルト値: `"128MiB"` -- `lockcf`のデフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は`"32MiB"`です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`"4MiB"`です。 -- 最小値: `0` -- 単位：KiB｜MiB｜GiB +- Memtableサイズ +- `defaultcf`および`writecf`のデフォルト値: `"128MiB"` +- `lockcf`のデフォルト値: + - `storage.engine="raft-kv"`の場合、デフォルト値は`"32MiB"`です。 + - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`"4MiB"`です。 +- 最小値: `0` +- 単位：KiB｜MiB｜GiB ### `max-write-buffer-number` {#max-write-buffer-number} -- メンテーブルの最大数。 `storage.flow-control.enable`が`true`に設定されている場合、 `storage.flow-control.memtables-threshold`はこの設定項目を上書きします。 -- デフォルト値: `5` -- 最小値: `0` +- メンテーブルの最大数。 `storage.flow-control.enable`が`true`に設定されている場合、 `storage.flow-control.memtables-threshold`はこの設定項目を上書きします。 +- デフォルト値: `5` +- 最小値: `0` ### `min-write-buffer-number-to-merge` {#min-write-buffer-number-to-merge} -- フラッシュをトリガーするために必要な最小のmemtable数 -- デフォルト値: `1` -- 最小値: `0` +- フラッシュをトリガーするために必要な最小のmemtable数 +- デフォルト値: `1` +- 最小値: `0` ### `max-bytes-for-level-base` {#max-bytes-for-level-base} -- ベースレベル（レベル1）における最大バイト数。一般的には、memtableのサイズの4倍に設定されます。レベル1のデータサイズ`max-bytes-for-level-base`の制限値に達すると、レベル1のSSTファイルと、それと重複するレベル2のSSTファイルが圧縮されます。 -- `defaultcf`および`writecf`のデフォルト値: `"512MiB"` -- `lockcf`のデフォルト値: `"128MiB"` -- 最小値: `0` -- 単位：KiB｜MiB｜GiB -- 不要な圧縮を減らすため、 `max-bytes-for-level-base`の値は L0 のデータ量とほぼ等しく設定することをお勧めします。たとえば、圧縮方法が "no:no:lz4:lz4:lz4:lz4:lz4" の場合、L0 と L1 は圧縮されず、L0 の圧縮のトリガー条件は SST ファイルの数が 4 (デフォルト値) に達することであるため、 `max-bytes-for-level-base`の値は`write-buffer-size * 4`にする必要があります。L0 と L1 の両方で圧縮を採用する場合は、RocksDB ログを分析して、memtable から圧縮された SST ファイルのサイズを把握する必要があります。例えば、ファイルサイズが 32 MiB の場合、 `max-bytes-for-level-base`の値を 128 MiB ( `32 MiB * 4` ) に設定することをお勧めします。 +- ベースレベル（レベル1）における最大バイト数。一般的には、memtableのサイズの4倍に設定されます。レベル1のデータサイズ`max-bytes-for-level-base`の制限値に達すると、レベル1のSSTファイルと、それと重複するレベル2のSSTファイルが圧縮されます。 +- `defaultcf`および`writecf`のデフォルト値: `"512MiB"` +- `lockcf`のデフォルト値: `"128MiB"` +- 最小値: `0` +- 単位：KiB｜MiB｜GiB +- 不要な圧縮を減らすため、 `max-bytes-for-level-base`の値は L0 のデータ量とほぼ等しく設定することをお勧めします。たとえば、圧縮方法が "no:no:lz4:lz4:lz4:lz4:lz4" の場合、L0 と L1 は圧縮されず、L0 の圧縮のトリガー条件は SST ファイルの数が 4 (デフォルト値) に達することであるため、 `max-bytes-for-level-base`の値は`write-buffer-size * 4`にする必要があります。L0 と L1 の両方で圧縮を採用する場合は、RocksDB ログを分析して、memtable から圧縮された SST ファイルのサイズを把握する必要があります。例えば、ファイルサイズが 32 MiB の場合、 `max-bytes-for-level-base`の値を 128 MiB ( `32 MiB * 4` ) に設定することをお勧めします。 ### `target-file-size-base` {#target-file-size-base} -- ベースレベルでのターゲットファイルのサイズ。 この値は、 `enable-compaction-guard`の値が`true`の場合、 `compaction-guard-max-output-file-size`によって上書きされます。 -- デフォルト値: None。これは、デフォルトでは`"8MiB"`を意味します。 -- 最小値: `0` -- 単位：KiB｜MiB｜GiB +- ベースレベルでのターゲットファイルのサイズ。 この値は、 `enable-compaction-guard`の値が`true`の場合、 `compaction-guard-max-output-file-size`によって上書きされます。 +- デフォルト値: None。これは、デフォルトでは`"8MiB"`を意味します。 +- 最小値: `0` +- 単位：KiB｜MiB｜GiB ### `level0-file-num-compaction-trigger` {#level0-file-num-compaction-trigger} -- L0 で圧縮をトリガーするファイルの最大数 -- `defaultcf`および`writecf`のデフォルト値: `4` -- `lockcf`のデフォルト値: `1` -- 最小値: `0` +- L0 で圧縮をトリガーするファイルの最大数 +- `defaultcf`および`writecf`のデフォルト値: `4` +- `lockcf`のデフォルト値: `1` +- 最小値: `0` ### `level0-slowdown-writes-trigger` {#level0-slowdown-writes-trigger} -- L0 で書き込み停止を引き起こすファイルの最大数。 -- v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この構成項目の値は[`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって直接上書きされます。 -- バージョン 8.5.5 以降: フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この構成項目の値は、その値が`storage.flow-control.l0-files-threshold`より大きい場合にのみ、 [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。 -- デフォルト値: `20` -- 最小値: `0` +- L0 で書き込み停止を引き起こすファイルの最大数。 +- v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この構成項目の値は[`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって直接上書きされます。 +- バージョン 8.5.5 以降: フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この構成項目の値は、その値が`storage.flow-control.l0-files-threshold`より大きい場合にのみ、 [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。 +- デフォルト値: `20` +- 最小値: `0` ### `level0-stop-writes-trigger` {#level0-stop-writes-trigger} -- L0 で書き込みを完全にブロックするために必要なファイルの最大数 -- デフォルト値: `36` -- 最小値: `0` +- L0 で書き込みを完全にブロックするために必要なファイルの最大数 +- デフォルト値: `36` +- 最小値: `0` ### `max-compaction-bytes` {#max-compaction-bytes} -- 圧縮ごとにディスクに書き込まれる最大バイト数 -- デフォルト値: `"2GiB"` -- 最小値: `0` -- 単位：KiB｜MiB｜GiB +- 圧縮ごとにディスクに書き込まれる最大バイト数 +- デフォルト値: `"2GiB"` +- 最小値: `0` +- 単位：KiB｜MiB｜GiB ### `compaction-pri` {#compaction-pri} -- 優先される圧縮の種類 -- オプション値: - - `"by-compensated-size"` : ファイルサイズ順にファイルを圧縮し、大きなファイルはより高い優先度で圧縮されます。 - - `"oldest-largest-seq-first"` : 更新日時が最も古いファイルの圧縮を優先します。この値は、ホットキーを狭い範囲で更新する場合に**のみ**使用してください。 - - `"oldest-smallest-seq-first"` : 長期間次のレベルに圧縮されていない範囲を持つファイルの圧縮を優先します。キー空間全体でホットキーをランダムに更新する場合、この値は書き込み増幅をわずかに低減できます。 - - `"min-overlapping-ratio"` : 重複率の高いファイルの圧縮を優先します。ファイルの各レベルが小さい場合（ `the file size in the next level` ÷ `the file size in this level`の結果が小さい場合）、TiKV はこのファイルを最初に圧縮します。多くの場合、この値によって書き込み増幅を効果的に削減できます。 -- `defaultcf`および`writecf`のデフォルト値: `"min-overlapping-ratio"` -- `lockcf`のデフォルト値: `"by-compensated-size"` +- 優先される圧縮の種類 +- オプション値: + - `"by-compensated-size"` : ファイルサイズ順にファイルを圧縮し、大きなファイルはより高い優先度で圧縮されます。 + - `"oldest-largest-seq-first"` : 更新日時が最も古いファイルの圧縮を優先します。この値は、ホットキーを狭い範囲で更新する場合に**のみ**使用してください。 + - `"oldest-smallest-seq-first"` : 長期間次のレベルに圧縮されていない範囲を持つファイルの圧縮を優先します。キー空間全体でホットキーをランダムに更新する場合、この値は書き込み増幅をわずかに低減できます。 + - `"min-overlapping-ratio"` : 重複率の高いファイルの圧縮を優先します。ファイルの各レベルが小さい場合（ `the file size in the next level` ÷ `the file size in this level`の結果が小さい場合）、TiKV はこのファイルを最初に圧縮します。多くの場合、この値によって書き込み増幅を効果的に削減できます。 +- `defaultcf`および`writecf`のデフォルト値: `"min-overlapping-ratio"` +- `lockcf`のデフォルト値: `"by-compensated-size"` ### `dynamic-level-bytes` {#dynamic-level-bytes} -- 動的レベルバイトを最適化するかどうかを決定します -- デフォルト値: `true` +- 動的レベルバイトを最適化するかどうかを決定します +- デフォルト値: `true` ### `num-levels` {#num-levels} -- RocksDBファイルの最大レベル数 -- デフォルト値: `7` +- RocksDBファイルの最大レベル数 +- デフォルト値: `7` ### `max-bytes-for-level-multiplier` {#max-bytes-for-level-multiplier} -- レイヤーのデフォルトの増幅倍率 -- デフォルト値: `10` +- レイヤーのデフォルトの増幅倍率 +- デフォルト値: `10` ### `compaction-style` {#compaction-style} -- 圧縮方法 -- オプション値: `"level"` 、 `"universal"` 、 `"fifo"` -- デフォルト値: `"level"` +- 圧縮方法 +- オプション値: `"level"` 、 `"universal"` 、 `"fifo"` +- デフォルト値: `"level"` ### `disable-auto-compactions` {#disable-auto-compactions} -- 自動圧縮を無効にするかどうかを決定します。 -- デフォルト値: `false` +- 自動圧縮を無効にするかどうかを決定します。 +- デフォルト値: `false` ### `soft-pending-compaction-bytes-limit` {#soft-pending-compaction-bytes-limit} -- 保留中の圧縮バイト数のソフトリミット。 -- v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この構成項目は[`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)によって直接上書きされます。 -- バージョン 8.5.5 以降: フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この設定項目は、 [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)値が`storage.flow-control.soft-pending-compaction-bytes-limit`より大きい場合にのみ上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。 -- デフォルト値: `"192GiB"` -- 単位：KiB｜MiB｜GiB +- 保留中の圧縮バイト数のソフトリミット。 +- v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この構成項目は[`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)によって直接上書きされます。 +- バージョン 8.5.5 以降: フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この設定項目は、 [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)値が`storage.flow-control.soft-pending-compaction-bytes-limit`より大きい場合にのみ上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。 +- デフォルト値: `"192GiB"` +- 単位：KiB｜MiB｜GiB ### `hard-pending-compaction-bytes-limit` {#hard-pending-compaction-bytes-limit} -- 保留中の圧縮バイト数の上限値。 `storage.flow-control.enable`が`true`に設定されている場合、 `storage.flow-control.hard-pending-compaction-bytes-limit`がこの設定項目を上書きします。 -- デフォルト値: `"256GiB"` -- 単位：KiB｜MiB｜GiB +- 保留中の圧縮バイト数の上限値。 `storage.flow-control.enable`が`true`に設定されている場合、 `storage.flow-control.hard-pending-compaction-bytes-limit`がこの設定項目を上書きします。 +- デフォルト値: `"256GiB"` +- 単位：KiB｜MiB｜GiB ### `enable-compaction-guard` {#enable-compaction-guard} -- TiKVリージョン境界でSSTファイルを分割する最適化機能である圧縮ガードを有効または無効にします。この最適化により、圧縮I/Oを削減し、TiKVがより大きなSSTファイルサイズ（つまり、SSTファイルの総数）を使用できるようにすると同時に、リージョン移行時に古いデータを効率的にクリーンアップできます。 -- `defaultcf`および`writecf`のデフォルト値: `true` -- `lockcf`のデフォルト値: None。これは、デフォルトで無効になっていることを意味します。 +- TiKVリージョン境界でSSTファイルを分割する最適化機能である圧縮ガードを有効または無効にします。この最適化により、圧縮I/Oを削減し、TiKVがより大きなSSTファイルサイズ（つまり、SSTファイルの総数）を使用できるようにすると同時に、リージョン移行時に古いデータを効率的にクリーンアップできます。 +- `defaultcf`および`writecf`のデフォルト値: `true` +- `lockcf`のデフォルト値: None。これは、デフォルトで無効になっていることを意味します。 ### `compaction-guard-min-output-file-size` {#compaction-guard-min-output-file-size} -- 圧縮ガードが有効になっている場合の、SSTファイルの最小サイズ。この設定により、圧縮ガードが有効になっている場合にSSTファイルが小さくなりすぎるのを防ぎます。 -- デフォルト値: `"8MiB"` -- 単位：KiB｜MiB｜GiB +- 圧縮ガードが有効になっている場合の、SSTファイルの最小サイズ。この設定により、圧縮ガードが有効になっている場合にSSTファイルが小さくなりすぎるのを防ぎます。 +- デフォルト値: `"8MiB"` +- 単位：KiB｜MiB｜GiB ### `compaction-guard-max-output-file-size` {#compaction-guard-max-output-file-size} -- コンパクションガードが有効になっている場合の SST ファイルの最大サイズ。この設定により、コンパクションガードが有効になっている場合に SST ファイルが大きくなりすぎるのを防ぎます。この設定は、同じカラムファミリーの`target-file-size-base`を上書きします。 -- デフォルト値: `"128MiB"` -- 単位：KiB｜MiB｜GiB +- コンパクションガードが有効になっている場合の SST ファイルの最大サイズ。この設定により、コンパクションガードが有効になっている場合に SST ファイルが大きくなりすぎるのを防ぎます。この設定は、同じカラムファミリーの`target-file-size-base`を上書きします。 +- デフォルト値: `"128MiB"` +- 単位：KiB｜MiB｜GiB ### `format-version` v6.2.0の新機能 {#format-version-new-in-v620} -- SSTファイルのフォーマットバージョン。この設定項目は、新規に書き込まれるテーブルにのみ影響します。既存のテーブルについては、バージョン情報はフッターから読み取られます。 -- オプション値: - - `0` : すべての TiKV バージョンで読み取り可能です。デフォルトのチェックサムタイプは CRC32 であり、このバージョンではチェックサムタイプの変更はサポートされていません。 - - `1` : すべての TiKV バージョンで読み取り可能です。xxHash などのデフォルト以外のチェックサム タイプをサポートします。RocksDB は、チェックサム タイプが CRC32 でない場合にのみデータを書き込みます。（バージョン`0`は自動的にアップグレードされます） - - `2` : すべての TiKV バージョンで読み取ることができます。LZ4、BZip2、Zlib 圧縮を使用して圧縮ブロックのエンコーディングを変更します。 - - `3` : TiKV v2.1以降のバージョンで読み取ることができます。インデックスブロック内のキーのエンコーディングを変更します。 - - `4` : TiKV v3.0以降のバージョンで読み取ることができます。インデックスブロック内の値のエンコーディングを変更します。 - - `5` : TiKV v6.1以降のバージョンで読み取ることができます。フルフィルタとパーティションフィルタは、異なるスキーマを使用した、より高速で高精度なブルームフィルタ実装を使用します。 -- デフォルト値: +- SSTファイルのフォーマットバージョン。この設定項目は、新規に書き込まれるテーブルにのみ影響します。既存のテーブルについては、バージョン情報はフッターから読み取られます。 +- オプション値: + - `0` : すべての TiKV バージョンで読み取り可能です。デフォルトのチェックサムタイプは CRC32 であり、このバージョンではチェックサムタイプの変更はサポートされていません。 + - `1` : すべての TiKV バージョンで読み取り可能です。xxHash などのデフォルト以外のチェックサム タイプをサポートします。RocksDB は、チェックサム タイプが CRC32 でない場合にのみデータを書き込みます。（バージョン`0`は自動的にアップグレードされます） + - `2` : すべての TiKV バージョンで読み取ることができます。LZ4、BZip2、Zlib 圧縮を使用して圧縮ブロックのエンコーディングを変更します。 + - `3` : TiKV v2.1以降のバージョンで読み取ることができます。インデックスブロック内のキーのエンコーディングを変更します。 + - `4` : TiKV v3.0以降のバージョンで読み取ることができます。インデックスブロック内の値のエンコーディングを変更します。 + - `5` : TiKV v6.1以降のバージョンで読み取ることができます。フルフィルタとパーティションフィルタは、異なるスキーマを使用した、より高速で高精度なブルームフィルタ実装を使用します。 +- デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は`2`です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`5`です。 + - `storage.engine="raft-kv"`の場合、デフォルト値は`2`です。 + - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`5`です。 ### `ttl` v7.2.0の新機能 {#ttl-new-in-v720} -- TTL（有効期限）よりも古い更新情報を持つSSTファイルは、自動的に圧縮対象として選択されます。これらのSSTファイルは、最下位レベルまたは最下位ファイルまで圧縮されるように、段階的に圧縮処理が行われます。 -- デフォルト値：なし。これは、デフォルトではSSTファイルが選択されていないことを意味します。 -- 単位：s（秒）｜h（時間）｜d（日） +- TTL（有効期限）よりも古い更新情報を持つSSTファイルは、自動的に圧縮対象として選択されます。これらのSSTファイルは、最下位レベルまたは最下位ファイルまで圧縮されるように、段階的に圧縮処理が行われます。 +- デフォルト値：なし。これは、デフォルトではSSTファイルが選択されていないことを意味します。 +- 単位：s（秒）｜h（時間）｜d（日） ### `periodic-compaction-seconds` v7.2.0 の新機能 {#periodic-compaction-seconds-new-in-v720} -- 定期的な圧縮の間隔。この値よりも古い更新履歴を持つSSTファイルが圧縮対象として選択され、元のSSTファイルと同じ階層に書き換えられます。 -- デフォルト値：None。これは、定期的な圧縮がデフォルトで無効になっていることを意味します。 -- 単位：s（秒）｜h（時間）｜d（日） +- 定期的な圧縮の間隔。この値よりも古い更新履歴を持つSSTファイルが圧縮対象として選択され、元のSSTファイルと同じ階層に書き換えられます。 +- デフォルト値：None。これは、定期的な圧縮がデフォルトで無効になっていることを意味します。 +- 単位：s（秒）｜h（時間）｜d（日） ### `max-compactions` （v6.6.0の新機能） {#max-compactions-new-in-v660} -- 同時実行可能な圧縮タスクの最大数。値`0`は制限なしを意味します。 -- デフォルト値: `0` +- 同時実行可能な圧縮タスクの最大数。値`0`は制限なしを意味します。 +- デフォルト値: `0` ## rocksdb.defaultcf.titan {#rocksdbdefaultcftitan} @@ -1847,62 +1847,62 @@ Titanに関連するコンフィグレーション項目。 > **Note:** > -> - TiDB v7.6.0以降、ワイドテーブルおよびJSONデータの書き込みとポイントクエリのパフォーマンスを向上させるため、Titanがデフォルトで有効になっています。 `min-blob-size`のデフォルト値が`1KiB`から`32KiB`に変更されます。これは`32KiB`を超える値はTitanに保存され、その他のデータは引き続きRocksDBに保存されることを意味します。 -> - 構成の一貫性を確保するため、TiDB v7.6.0 以降のバージョンにアップグレードする既存のクラスターでは、アップグレード前に`min-blob-size`を明示的に設定しない場合、TiDB は以前のデフォルト値`1KiB`を保持します。 -> - `32KiB`より小さい値を設定すると、範囲スキャンのパフォーマンスに影響が出る可能性があります。ただし、ワークロードが主に大量の書き込みとポイントクエリで構成されている場合は、パフォーマンス向上のために`min-blob-size`の値を小さくすることを検討してください。 +> - TiDB v7.6.0以降、ワイドテーブルおよびJSONデータの書き込みとポイントクエリのパフォーマンスを向上させるため、Titanがデフォルトで有効になっています。 `min-blob-size`のデフォルト値が`1KiB`から`32KiB`に変更されます。これは`32KiB`を超える値はTitanに保存され、その他のデータは引き続きRocksDBに保存されることを意味します。 +> - 構成の一貫性を確保するため、TiDB v7.6.0 以降のバージョンにアップグレードする既存のクラスターでは、アップグレード前に`min-blob-size`を明示的に設定しない場合、TiDB は以前のデフォルト値`1KiB`を保持します。 +> - `32KiB`より小さい値を設定すると、範囲スキャンのパフォーマンスに影響が出る可能性があります。ただし、ワークロードが主に大量の書き込みとポイントクエリで構成されている場合は、パフォーマンス向上のために`min-blob-size`の値を小さくすることを検討してください。 -- Blobファイルに格納される最小値。指定されたサイズより小さい値はLSMツリーに格納されます。 -- デフォルト値: None。これは、デフォルトでは`"32KiB"`を意味します。 -- 最小値: `0` -- 単位：KiB｜MiB｜GiB +- Blobファイルに格納される最小値。指定されたサイズより小さい値はLSMツリーに格納されます。 +- デフォルト値: None。これは、デフォルトでは`"32KiB"`を意味します。 +- 最小値: `0` +- 単位：KiB｜MiB｜GiB ### `blob-file-compression` {#blob-file-compression} > **Note:** > -> - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)になければなりません。 Snappy 圧縮の他のバリアントはサポートされていません。 -> - TiDB v7.6.0以降、 `blob-file-compression`のデフォルト値が`"lz4"`から`"zstd"`に変更されます。 +> - Snappy 圧縮ファイルは[公式Snappyフォーマット](https://github.com/google/snappy)になければなりません。 Snappy 圧縮の他のバリアントはサポートされていません。 +> - TiDB v7.6.0以降、 `blob-file-compression`のデフォルト値が`"lz4"`から`"zstd"`に変更されます。 -- Blobファイルで使用される圧縮アルゴリズム -- オプション値: `"no"` 、 `"snappy"` 、 `"zlib"` 、 `"bzip2"` 、 `"lz4"` 、 `"lz4hc"` 、 `"zstd"` -- デフォルト値: `"zstd"` +- Blobファイルで使用される圧縮アルゴリズム +- オプション値: `"no"` 、 `"snappy"` 、 `"zlib"` 、 `"bzip2"` 、 `"lz4"` 、 `"lz4hc"` 、 `"zstd"` +- デフォルト値: `"zstd"` ### `zstd-dict-size` {#zstd-dict-size} -- zstd辞書の圧縮サイズ。デフォルト値は`"0KiB"`で、zstd辞書の圧縮を無効にすることを意味します。この場合、Titanは単一の値に基づいてデータを圧縮しますが、RocksDBはブロックに基づいてデータを圧縮します（デフォルトでは`32KiB` ）。Titanの値の平均サイズが`32KiB`より小さい場合、Titanの圧縮率はRocksDBよりも低くなります。JSONを例にとると、TitanのストアサイズはRocksDBよりも30%から50%大きくなる可能性があります。実際の圧縮率は、値の内容が圧縮に適しているかどうか、および異なる値間の類似性によって異なります。 `zstd-dict-size`を設定することで、zstd 辞書圧縮を有効にして圧縮率を高めることができます (例えば、 `16KiB`に設定します)。実際のストアサイズは RocksDB よりも小さくなる可能性があります。ただし、zstd 辞書圧縮は、特定のワークロードにおいて約 10% のパフォーマンス低下を引き起こす可能性があります。 -- デフォルト値: `"0KiB"` -- 単位：KiB｜MiB｜GiB +- zstd辞書の圧縮サイズ。デフォルト値は`"0KiB"`で、zstd辞書の圧縮を無効にすることを意味します。この場合、Titanは単一の値に基づいてデータを圧縮しますが、RocksDBはブロックに基づいてデータを圧縮します（デフォルトでは`32KiB` ）。Titanの値の平均サイズが`32KiB`より小さい場合、Titanの圧縮率はRocksDBよりも低くなります。JSONを例にとると、TitanのストアサイズはRocksDBよりも30%から50%大きくなる可能性があります。実際の圧縮率は、値の内容が圧縮に適しているかどうか、および異なる値間の類似性によって異なります。 `zstd-dict-size`を設定することで、zstd 辞書圧縮を有効にして圧縮率を高めることができます (例えば、 `16KiB`に設定します)。実際のストアサイズは RocksDB よりも小さくなる可能性があります。ただし、zstd 辞書圧縮は、特定のワークロードにおいて約 10% のパフォーマンス低下を引き起こす可能性があります。 +- デフォルト値: `"0KiB"` +- 単位：KiB｜MiB｜GiB ### `blob-cache-size` {#blob-cache-size} -- Blobファイルのキャッシュサイズ -- デフォルト値: `"0GiB"` -- 最小値: `0` -- 推奨値: `0` 。v8.0.0 以降、TiKV は`shared-blob-cache`設定項目を導入し、デフォルトで有効にしているため、 `blob-cache-size`を個別に設定する必要はありません。 `blob-cache-size`の設定は、 `shared-blob-cache`が`false`に設定されている場合にのみ有効になります。 -- 単位：KiB｜MiB｜GiB +- Blobファイルのキャッシュサイズ +- デフォルト値: `"0GiB"` +- 最小値: `0` +- 推奨値: `0` 。v8.0.0 以降、TiKV は`shared-blob-cache`設定項目を導入し、デフォルトで有効にしているため、 `blob-cache-size`を個別に設定する必要はありません。 `blob-cache-size`の設定は、 `shared-blob-cache`が`false`に設定されている場合にのみ有効になります。 +- 単位：KiB｜MiB｜GiB ### `shared-blob-cache` v8.0.0で追加 {#shared-blob-cache-new-in-v800} -- TitanのブロブファイルとRocksDBのブロックファイルに対して共有キャッシュを有効にするかどうかを制御します。 -- デフォルト値: `true` 。共有キャッシュが有効になっている場合、ブロックファイルの優先度が高くなります。つまり、TiKV はブロックファイルのキャッシュ要件を満たすことを優先し、残りのキャッシュをブロブファイルに使用します。 +- TitanのブロブファイルとRocksDBのブロックファイルに対して共有キャッシュを有効にするかどうかを制御します。 +- デフォルト値: `true` 。共有キャッシュが有効になっている場合、ブロックファイルの優先度が高くなります。つまり、TiKV はブロックファイルのキャッシュ要件を満たすことを優先し、残りのキャッシュをブロブファイルに使用します。 ### `min-gc-batch-size` {#min-gc-batch-size} -- 1回のGCを実行するために必要なBlobファイルの最小合計サイズ -- デフォルト値: `"16MiB"` -- 最小値: `0` -- 単位：KiB｜MiB｜GiB +- 1回のGCを実行するために必要なBlobファイルの最小合計サイズ +- デフォルト値: `"16MiB"` +- 最小値: `0` +- 単位：KiB｜MiB｜GiB ### `max-gc-batch-size` {#max-gc-batch-size} -- 1回のGC実行で許可されるBlobファイルの最大合計サイズ -- デフォルト値: `"64MiB"` -- 最小値: `0` -- 単位：KiB｜MiB｜GiB +- 1回のGC実行で許可されるBlobファイルの最大合計サイズ +- デフォルト値: `"64MiB"` +- 最小値: `0` +- 単位：KiB｜MiB｜GiB ### `discardable-ratio` {#discardable-ratio} -- Blob ファイル内の古いデータ (対応するキーが更新または削除されたデータ) の割合が次のしきい値を超えると、Titan GC がトリガーされます。Titan がこの Blob ファイルの有効なデータを別のファイルに書き込むとき、 `discardable-ratio`値を使用して、書き込み増幅とスペース増幅の上限を推定できます (圧縮が無効になっている場合)。 +- Blob ファイル内の古いデータ (対応するキーが更新または削除されたデータ) の割合が次のしきい値を超えると、Titan GC がトリガーされます。Titan がこの Blob ファイルの有効なデータを別のファイルに書き込むとき、 `discardable-ratio`値を使用して、書き込み増幅とスペース増幅の上限を推定できます (圧縮が無効になっている場合)。 書き込み増幅の上限 = 1 / `discardable-ratio` @@ -1910,39 +1910,39 @@ Titanに関連するコンフィグレーション項目。 これら2つの式から、 `discardable_ratio`の値を小さくすると、スペースの増幅を抑えることができますが、TitanでのGCの頻度が高くなります。値を大きくすると、TitanのGCの頻度が減り、それに伴いI/O帯域幅とCPU使用率が低下しますが、ディスク使用率が増加します。 -- デフォルト値: `0.5` +- デフォルト値: `0.5` -- 最小値: `0` +- 最小値: `0` -- 最大値: `1` +- 最大値: `1` ### `sample-ratio` {#sample-ratio} -- GC中にファイルをサンプリングする際の、（Blobファイルから読み取ったデータ量／Blobファイル全体）の比率 -- デフォルト値: `0.1` -- 最小値: `0` -- 最大値: `1` +- GC中にファイルをサンプリングする際の、（Blobファイルから読み取ったデータ量／Blobファイル全体）の比率 +- デフォルト値: `0.1` +- 最小値: `0` +- 最大値: `1` ### `merge-small-file-threshold` {#merge-small-file-threshold} -- Blob ファイルのサイズがこの値より小さい場合でも、Blob ファイルは GC の対象として選択される可能性があります。この場合、 `discardable-ratio`は無視されます。 -- デフォルト値: `"8MiB"` -- 最小値: `0` -- 単位：KiB｜MiB｜GiB +- Blob ファイルのサイズがこの値より小さい場合でも、Blob ファイルは GC の対象として選択される可能性があります。この場合、 `discardable-ratio`は無視されます。 +- デフォルト値: `"8MiB"` +- 最小値: `0` +- 単位：KiB｜MiB｜GiB ### `blob-run-mode` {#blob-run-mode} -- Titanの実行モードを指定します。 -- オプション値: - - `normal` : 値のサイズが[`min-blob-size`](#min-blob-size)を超えると、データを blob ファイルに書き込みます。 - - `read-only` : ブロブファイルへの新しいデータの書き込みを拒否しますが、ブロブファイルから元のデータを読み取ります。 - - `fallback` : ブロブファイル内のデータをLSMに書き込みます。 -- デフォルト値: `normal` +- Titanの実行モードを指定します。 +- オプション値: + - `normal` : 値のサイズが[`min-blob-size`](#min-blob-size)を超えると、データを blob ファイルに書き込みます。 + - `read-only` : ブロブファイルへの新しいデータの書き込みを拒否しますが、ブロブファイルから元のデータを読み取ります。 + - `fallback` : ブロブファイル内のデータをLSMに書き込みます。 +- デフォルト値: `normal` ### `level-merge` {#level-merge} -- 読み取りパフォーマンスを最適化するかどうかを決定します。 `level-merge`が有効になっている場合、書き込み増幅が強化されます。 -- デフォルト値: `false` +- 読み取りパフォーマンスを最適化するかどうかを決定します。 `level-merge`が有効になっている場合、書き込み増幅が強化されます。 +- デフォルト値: `false` ## raftdb {#raftdb} @@ -1950,110 +1950,110 @@ Titanに関連するコンフィグレーション項目。 ### `max-background-jobs` {#max-background-jobs} -- RocksDB のバックグラウンド スレッドの数。 RocksDB スレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 -- デフォルト値: `4` -- 最小値: `2` +- RocksDB のバックグラウンド スレッドの数。 RocksDB スレッド プールのサイズを変更する場合は、 [TiKVスレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 +- デフォルト値: `4` +- 最小値: `2` ### `max-sub-compactions` {#max-sub-compactions} -- RocksDBで同時に実行されるサブコンパクション操作の数 -- デフォルト値: `2` -- 最小値: `1` +- RocksDBで同時に実行されるサブコンパクション操作の数 +- デフォルト値: `2` +- 最小値: `1` ### `max-open-files` {#max-open-files} -- RocksDBが開くことができるファイルの総数 -- デフォルト値: `40960` -- 最小値: `-1` +- RocksDBが開くことができるファイルの総数 +- デフォルト値: `40960` +- 最小値: `-1` ### `max-manifest-file-size` {#max-manifest-file-size} -- RocksDBマニフェストファイルの最大サイズ -- デフォルト値: `"20MiB"` -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- RocksDBマニフェストファイルの最大サイズ +- デフォルト値: `"20MiB"` +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `create-if-missing` {#create-if-missing} -- 値が`true`の場合、データベースが存在しない場合は作成されます。 -- デフォルト値: `true` +- 値が`true`の場合、データベースが存在しない場合は作成されます。 +- デフォルト値: `true` ### `stats-dump-period` {#stats-dump-period} -- 統計情報がログに出力される間隔 -- デフォルト値: `10m` +- 統計情報がログに出力される間隔 +- デフォルト値: `10m` ### `wal-dir` {#wal-dir} -- Raft RocksDB WAL ファイルが保存されるディレクトリ。これは WAL の絶対ディレクトリパスです。この設定項目を[`rocksdb.wal-dir`](#wal-dir)と同じ値に設定**しないでください**。 -- この設定項目が設定されていない場合、ログファイルはデータと同じディレクトリに保存されます。 -- マシンに2つのディスクが搭載されている場合、RocksDBデータとWALログを異なるディスクに保存することでパフォーマンスが向上する可能性があります。 -- デフォルト値: `""` +- Raft RocksDB WAL ファイルが保存されるディレクトリ。これは WAL の絶対ディレクトリパスです。この設定項目を[`rocksdb.wal-dir`](#wal-dir)と同じ値に設定**しないでください**。 +- この設定項目が設定されていない場合、ログファイルはデータと同じディレクトリに保存されます。 +- マシンに2つのディスクが搭載されている場合、RocksDBデータとWALログを異なるディスクに保存することでパフォーマンスが向上する可能性があります。 +- デフォルト値: `""` ### `wal-ttl-seconds` {#wal-ttl-seconds} -- アーカイブされたWALファイルの保持期間を指定します。この値を超えると、システムはこれらのファイルを削除します。 -- デフォルト値: `0` -- 最小値: `0` -- 単位：秒 +- アーカイブされたWALファイルの保持期間を指定します。この値を超えると、システムはこれらのファイルを削除します。 +- デフォルト値: `0` +- 最小値: `0` +- 単位：秒 ### `wal-size-limit` {#wal-size-limit} -- アーカイブされたWALファイルのサイズ制限。この値を超えると、システムはこれらのファイルを削除します。 -- デフォルト値: `0` -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- アーカイブされたWALファイルのサイズ制限。この値を超えると、システムはこれらのファイルを削除します。 +- デフォルト値: `0` +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `max-total-wal-size` {#max-total-wal-size} -- RocksDB WALの最大サイズ合計 -- デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は`"4GiB"`です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`1`です。 +- RocksDB WALの最大サイズ合計 +- デフォルト値: + - `storage.engine="raft-kv"`の場合、デフォルト値は`"4GiB"`です。 + - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`1`です。 ### `compaction-readahead-size` {#compaction-readahead-size} -- RocksDBの圧縮中に先読み機能を有効にするかどうか、および先読みデータのサイズを指定するかどうかを制御します。 -- 機械式ディスクを使用する場合は、値を少なくとも`2MiB`に設定することをお勧めします。 -- デフォルト値: `0` -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- RocksDBの圧縮中に先読み機能を有効にするかどうか、および先読みデータのサイズを指定するかどうかを制御します。 +- 機械式ディスクを使用する場合は、値を少なくとも`2MiB`に設定することをお勧めします。 +- デフォルト値: `0` +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `writable-file-max-buffer-size` {#writable-file-max-buffer-size} -- WritableFileWriteで使用される最大バッファサイズ -- デフォルト値: `"1MiB"` -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- WritableFileWriteで使用される最大バッファサイズ +- デフォルト値: `"1MiB"` +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `use-direct-io-for-flush-and-compaction` {#use-direct-io-for-flush-and-compaction} -- バックグラウンドのフラッシュと圧縮における読み取りと書き込みの両方で`O_DIRECT`を使用するかどうかを決定します。このオプションのパフォーマンスへの影響: `O_DIRECT`を有効にすると、OS バッファ キャッシュの汚染がバイパスされ防止されますが、後続のファイル読み取りではバッファ キャッシュの内容を再読み込みする必要があります。 -- デフォルト値: `false` +- バックグラウンドのフラッシュと圧縮における読み取りと書き込みの両方で`O_DIRECT`を使用するかどうかを決定します。このオプションのパフォーマンスへの影響: `O_DIRECT`を有効にすると、OS バッファ キャッシュの汚染がバイパスされ防止されますが、後続のファイル読み取りではバッファ キャッシュの内容を再読み込みする必要があります。 +- デフォルト値: `false` ### `enable-pipelined-write` {#enable-pipelined-write} -- パイプライン書き込みを有効にするかどうかを制御します。この設定を有効にすると、従来のパイプライン書き込みが使用されます。この設定を無効にすると、新しいパイプラインコミットメカニズムが使用されます。 -- デフォルト値: `true` +- パイプライン書き込みを有効にするかどうかを制御します。この設定を有効にすると、従来のパイプライン書き込みが使用されます。この設定を無効にすると、新しいパイプラインコミットメカニズムが使用されます。 +- デフォルト値: `true` ### `allow-concurrent-memtable-write` {#allow-concurrent-memtable-write} -- 同時memtable書き込みを有効にするかどうかを制御します。 -- デフォルト値: `true` +- 同時memtable書き込みを有効にするかどうかを制御します。 +- デフォルト値: `true` ### `bytes-per-sync` {#bytes-per-sync-2} -- ファイルが非同期的に書き込まれている間に、OSがファイルをディスクに増分的に同期する速度 -- デフォルト値: `"1MiB"` -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- ファイルが非同期的に書き込まれている間に、OSがファイルをディスクに増分的に同期する速度 +- デフォルト値: `"1MiB"` +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `wal-bytes-per-sync` {#wal-bytes-per-sync} -- WALファイルが書き込まれているときに、OSがWALファイルをディスクに増分同期する速度 -- デフォルト値: `"512KiB"` -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- WALファイルが書き込まれているときに、OSがWALファイルをディスクに増分同期する速度 +- デフォルト値: `"512KiB"` +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `info-log-max-size` {#info-log-max-size} @@ -2061,10 +2061,10 @@ Titanに関連するコンフィグレーション項目。 > > バージョン5.4.0以降、RocksDBログはTiKVのログモジュールによって管理されます。そのため、この設定項目は非推奨となり、その機能は設定項目[`log.file.max-size`](#max-size-new-in-v540)に置き換えられました。 -- Infoログの最大サイズ -- デフォルト値: `"1GiB"` -- 最小値: `0` -- 単位: B|KiB|MiB|GiB +- Infoログの最大サイズ +- デフォルト値: `"1GiB"` +- 最小値: `0` +- 単位: B|KiB|MiB|GiB ### `info-log-roll-time` {#info-log-roll-time} @@ -2072,8 +2072,8 @@ Titanに関連するコンフィグレーション項目。 > > バージョン5.4.0以降、RocksDBログはTiKVのログモジュールによって管理されるようになりました。そのため、この設定項目は非推奨です。TiKVは時間に基づく自動ログ分割をサポートしなくなりました。代わりに、設定項目[`log.file.max-size`](#max-size-new-in-v540)を使用して、ファイルサイズに基づく自動ログ分割のしきい値を設定できます。 -- Infoログが切り捨てられる間隔。値が`0s`の場合、ログは切り捨てられません。 -- デフォルト値： `"0s"` （ログが切り捨てられないことを意味します） +- Infoログが切り捨てられる間隔。値が`0s`の場合、ログは切り捨てられません。 +- デフォルト値： `"0s"` （ログが切り捨てられないことを意味します） ### `info-log-keep-log-file-num` {#info-log-keep-log-file-num} @@ -2081,14 +2081,14 @@ Titanに関連するコンフィグレーション項目。 > > バージョン5.4.0以降、RocksDBログはTiKVのログモジュールによって管理されます。そのため、この設定項目は非推奨となり、その機能は設定項目[`log.file.max-backups`](#max-backups-new-in-v540)に置き換えられました。 -- RaftDBに保持される情報ログファイルの最大数 -- デフォルト値: `10` -- 最小値: `0` +- RaftDBに保持される情報ログファイルの最大数 +- デフォルト値: `10` +- 最小値: `0` ### `info-log-dir` {#info-log-dir} -- Infoログが保存されるディレクトリ -- デフォルト値: `""` +- Infoログが保存されるディレクトリ +- デフォルト値: `""` ### `info-log-level` {#info-log-level} @@ -2096,8 +2096,8 @@ Titanに関連するコンフィグレーション項目。 > > バージョン5.4.0以降、RocksDBログはTiKVのログモジュールによって管理されます。そのため、この設定項目は非推奨となり、その機能は設定項目[`log.level`](#level-new-in-v540)に置き換えられました。 -- RaftDBのログレベル -- デフォルト値: `"info"` +- RaftDBのログレベル +- デフォルト値: `"info"` ## Raft Engine {#raft-engine} @@ -2105,39 +2105,39 @@ Raft Engineに関連するコンフィグレーション項目。 > **Note:** > -> - Raft Engineを初めて有効にすると、TiKVはRocksDBからRaft Engineにデータを転送します。そのため、TiKVが起動するまで数十秒余分に待つ必要があります。 -> - TiDB v5.4.0 のRaft Engineのデータ形式は、以前の TiDB バージョンと互換性がありません。そのため、TiDB クラスタを v5.4.0 から以前のバージョンにダウングレードする必要がある場合は、ダウングレードする**前に**、 `enable`を`false`に設定してRaft Engine を無効にし、TiKV を再起動して設定を有効にしてください。 +> - Raft Engineを初めて有効にすると、TiKVはRocksDBからRaft Engineにデータを転送します。そのため、TiKVが起動するまで数十秒余分に待つ必要があります。 +> - TiDB v5.4.0 のRaft Engineのデータ形式は、以前の TiDB バージョンと互換性がありません。そのため、TiDB クラスタを v5.4.0 から以前のバージョンにダウングレードする必要がある場合は、ダウングレードする**前に**、 `enable`を`false`に設定してRaft Engine を無効にし、TiKV を再起動して設定を有効にしてください。 ### `enable` {#enable-2} -- Raftログを保存するためにRaft Engineを使用するかどうかを決定します。有効にすると、 `raftdb`の設定は無視されます。 -- デフォルト値: `true` +- Raftログを保存するためにRaft Engineを使用するかどうかを決定します。有効にすると、 `raftdb`の設定は無視されます。 +- デフォルト値: `true` ### `dir` {#dir} -- Raftのログファイルが保存されるディレクトリ。このディレクトリが存在しない場合は、TiKVの起動時に作成されます。 -- この設定項目が設定されていない場合は、 `{data-dir}/raft-engine`が使用されます。 -- お使いのコンピューターに複数のディスクが搭載されている場合は、TiKVのパフォーマンスを向上させるために、 Raft Engineのデータを別のディスクに保存することをお勧めします。 -- デフォルト値: `""` +- Raftのログファイルが保存されるディレクトリ。このディレクトリが存在しない場合は、TiKVの起動時に作成されます。 +- この設定項目が設定されていない場合は、 `{data-dir}/raft-engine`が使用されます。 +- お使いのコンピューターに複数のディスクが搭載されている場合は、TiKVのパフォーマンスを向上させるために、 Raft Engineのデータを別のディスクに保存することをお勧めします。 +- デフォルト値: `""` ### `spill-dir` v8.4.0の新機能 {#spill-dir-new-in-v840} -- Raftログファイルを保存するための補助ディレクトリです。 `dir`ディレクトリのディスク容量がいっぱいになると、新しいRaftログはこのディレクトリに保存されます。設定後にこの補助ディレクトリが存在しない場合は、TiKVの起動時に自動的に作成されます。 -- この設定が行われていない場合、補助ディレクトリは有効になりません。 +- Raftログファイルを保存するための補助ディレクトリです。 `dir`ディレクトリのディスク容量がいっぱいになると、新しいRaftログはこのディレクトリに保存されます。設定後にこの補助ディレクトリが存在しない場合は、TiKVの起動時に自動的に作成されます。 +- この設定が行われていない場合、補助ディレクトリは有効になりません。 > **Note:** > -> - この設定は、 Raft Engineの`dir`と`spill-dir`が異なるディスクドライブに設定されている場合にのみ有効になります。 -> - この機能を有効にした後、無効にする場合は、TiKVを再起動する前に以下の操作を実行する必要があります。そうしないと、TiKVが起動に失敗します。 -> 1. TiKVを停止してください。 -> 2. `spill-dir`ディレクトリからすべてのRaft Log を[`dir`](/tikv-configuration-file.md#dir)ディレクトリにコピーします。 -> 3. TiKV設定ファイルからこの設定を削除してください。 -> 4. TiKVを再起動してください。 +> - この設定は、 Raft Engineの`dir`と`spill-dir`が異なるディスクドライブに設定されている場合にのみ有効になります。 +> - この機能を有効にした後、無効にする場合は、TiKVを再起動する前に以下の操作を実行する必要があります。そうしないと、TiKVが起動に失敗します。 +> 1. TiKVを停止してください。 +> 2. `spill-dir`ディレクトリからすべてのRaft Log を[`dir`](/tikv-configuration-file.md#dir)ディレクトリにコピーします。 +> 3. TiKV設定ファイルからこの設定を削除してください。 +> 4. TiKVを再起動してください。 ### `batch-compression-threshold` {#batch-compression-threshold} -- ログバッチのしきい値サイズを指定します。この設定値よりも大きいログバッチは圧縮されます。この設定項目を`0`に設定すると、圧縮は無効になります。 -- デフォルト値: `"4KiB"` 。v8.1.0 より前のバージョンでは、デフォルト値は`"8KiB"`です。 +- ログバッチのしきい値サイズを指定します。この設定値よりも大きいログバッチは圧縮されます。この設定項目を`0`に設定すると、圧縮は無効になります。 +- デフォルト値: `"4KiB"` 。v8.1.0 より前のバージョンでは、デフォルト値は`"8KiB"`です。 ### `bytes-per-sync` {#bytes-per-sync} @@ -2145,44 +2145,44 @@ Raft Engineに関連するコンフィグレーション項目。 > > バージョン6.5.0以降、 Raft Engineはログをバッファリングせずに直接ディスクに書き込むようになりました。そのため、この設定項目は非推奨となり、機能しなくなりました。 -- バッファリングされた書き込みの最大累積サイズを指定します。この設定値を超えると、バッファリングされた書き込みはディスクに書き込まれます。 -- この設定項目を`0`に設定すると、増分同期が無効になります。 -- v6.5.0より前のバージョンでは、デフォルト値は`"4MiB"`です。 +- バッファリングされた書き込みの最大累積サイズを指定します。この設定値を超えると、バッファリングされた書き込みはディスクに書き込まれます。 +- この設定項目を`0`に設定すると、増分同期が無効になります。 +- v6.5.0より前のバージョンでは、デフォルト値は`"4MiB"`です。 ### `target-file-size` {#target-file-size} -- ログファイルの最大サイズを指定します。ログファイルがこの値を超えると、ローテーションされます。 -- デフォルト値: `"128MiB"` +- ログファイルの最大サイズを指定します。ログファイルがこの値を超えると、ローテーションされます。 +- デフォルト値: `"128MiB"` ### `purge-threshold` {#purge-threshold} -- メインログキューのしきい値サイズを指定します。この設定値を超えると、メインログキューはクリアされます。 -- この設定を使用すると、 Raft Engineのディスク容量使用量を調整できます。 -- デフォルト値: `"10GiB"` +- メインログキューのしきい値サイズを指定します。この設定値を超えると、メインログキューはクリアされます。 +- この設定を使用すると、 Raft Engineのディスク容量使用量を調整できます。 +- デフォルト値: `"10GiB"` ### `recovery-mode` {#recovery-mode} -- リカバリ中にファイル破損が発生した場合の対処方法を決定します。 -- 値のオプション: `"absolute-consistency"` 、 `"tolerate-tail-corruption"` 、 `"tolerate-any-corruption"` -- デフォルト値: `"tolerate-tail-corruption"` +- リカバリ中にファイル破損が発生した場合の対処方法を決定します。 +- 値のオプション: `"absolute-consistency"` 、 `"tolerate-tail-corruption"` 、 `"tolerate-any-corruption"` +- デフォルト値: `"tolerate-tail-corruption"` ### `recovery-read-block-size` {#recovery-read-block-size} -- リカバリ中にログファイルを読み取るための最小I/Oサイズ。 -- デフォルト値: `"16KiB"` -- 最小値: `"512B"` +- リカバリ中にログファイルを読み取るための最小I/Oサイズ。 +- デフォルト値: `"16KiB"` +- 最小値: `"512B"` ### `recovery-threads` {#recovery-threads} -- ログファイルのスキャンと復元に使用されるスレッド数。 -- デフォルト値: `4` -- 最小値: `1` +- ログファイルのスキャンと復元に使用されるスレッド数。 +- デフォルト値: `4` +- 最小値: `1` ### `memory-limit` {#memory-limit} -- Raft Engineのメモリ使用量の上限を指定します。 -- この設定値が設定されていない場合、利用可能なシステムメモリの15%が使用されます。 -- デフォルト値: `Total machine memory * 15%` +- Raft Engineのメモリ使用量の上限を指定します。 +- この設定値が設定されていない場合、利用可能なシステムメモリの15%が使用されます。 +- デフォルト値: `Total machine memory * 15%` ### `format-version` v6.3.0の新機能 {#format-version-new-in-v630} @@ -2190,17 +2190,17 @@ Raft Engineに関連するコンフィグレーション項目。 > > `format-version`を`2`に設定した後、TiKV クラスターを v6.3.0 から以前のバージョンにダウングレードする必要がある場合は、ダウングレード**の前に**以下の手順を実行してください。 > -> 1. Raft Engineを無効にするには、 [`enable`](/tikv-configuration-file.md#enable-1)を`false`に設定し、TiKVを再起動して設定を有効にします。 -> 2. `format-version`を`1`に設定します。 -> 3. `enable`を`true`に設定してRaft Engineを有効にし、TiKV を再起動して設定を有効にしてください。 - -- Raft Engineのログ ファイルのバージョンを指定します。 -- 値のオプション： - - `1` : TiKV v6.3.0 より前のバージョンのデフォルトのログファイルです。TiKV >= v6.1.0 で読み取ることができます。 - - `2` : ログのリサイクルをサポートします。TiKV >= v6.3.0 で読み取ることができます。 -- デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は`2`です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`5`です。 +> 1. Raft Engineを無効にするには、 [`enable`](/tikv-configuration-file.md#enable-1)を`false`に設定し、TiKVを再起動して設定を有効にします。 +> 2. `format-version`を`1`に設定します。 +> 3. `enable`を`true`に設定してRaft Engineを有効にし、TiKV を再起動して設定を有効にしてください。 + +- Raft Engineのログ ファイルのバージョンを指定します。 +- 値のオプション： + - `1` : TiKV v6.3.0 より前のバージョンのデフォルトのログファイルです。TiKV >= v6.1.0 で読み取ることができます。 + - `2` : ログのリサイクルをサポートします。TiKV >= v6.3.0 で読み取ることができます。 +- デフォルト値: + - `storage.engine="raft-kv"`の場合、デフォルト値は`2`です。 + - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`5`です。 ### `enable-log-recycle` v6.3.0の新機能 {#enable-log-recycle-new-in-v630} @@ -2208,8 +2208,8 @@ Raft Engineに関連するコンフィグレーション項目。 > > この設定項目は、 [`format-version`](#format-version-new-in-v630) >= 2 の場合にのみ利用可能です。 -- Raft Engineで古いログファイルを再利用するかどうかを決定します。有効にすると、論理的に削除されたログファイルが再利用のために予約されます。これにより、書き込みワークロードにおけるロングテールレイテンシーが軽減されます。 -- デフォルト値: `true` +- Raft Engineで古いログファイルを再利用するかどうかを決定します。有効にすると、論理的に削除されたログファイルが再利用のために予約されます。これにより、書き込みワークロードにおけるロングテールレイテンシーが軽減されます。 +- デフォルト値: `true` ### `prefill-for-recycle` （v7.0.0の新機能） {#prefill-for-recycle-new-in-v700} @@ -2217,14 +2217,14 @@ Raft Engineに関連するコンフィグレーション項目。 > > この設定項目は、 [`enable-log-recycle`](#enable-log-recycle-new-in-v630)が`true`に設定されている場合にのみ有効になります。 -- Raft Engineでログのリサイクル用に空のログファイルを生成するかどうかを決定します。有効にすると、 Raft Engine は初期化中にログのリサイクル用に空のログファイルを自動的に生成し、初期化直後からログのリサイクルが有効になります。 -- デフォルト値: `false` +- Raft Engineでログのリサイクル用に空のログファイルを生成するかどうかを決定します。有効にすると、 Raft Engine は初期化中にログのリサイクル用に空のログファイルを自動的に生成し、初期化直後からログのリサイクルが有効になります。 +- デフォルト値: `false` ### `compression-level` v7.4.0で追加 {#compression-level-new-in-v740} -- Raft EngineがRaftログファイルを書き込む際に使用するLZ4アルゴリズムの圧縮効率を設定します。値が小さいほど圧縮速度は速くなりますが、圧縮率は低くなります。 -- 範囲: `[1, 16]` -- デフォルト値: `1` +- Raft EngineがRaftログファイルを書き込む際に使用するLZ4アルゴリズムの圧縮効率を設定します。値が小さいほど圧縮速度は速くなりますが、圧縮率は低くなります。 +- 範囲: `[1, 16]` +- デフォルト値: `1` ## 安全 {#security} @@ -2232,32 +2232,32 @@ Raft Engineに関連するコンフィグレーション項目。 ### `ca-path` {#ca-path} -- CAファイルのパス -- デフォルト値: `""` +- CAファイルのパス +- デフォルト値: `""` ### `cert-path` {#cert-path} -- X.509証明書を含むプライバシー強化メール（PEM）ファイルのパス -- デフォルト値: `""` +- X.509証明書を含むプライバシー強化メール（PEM）ファイルのパス +- デフォルト値: `""` ### `key-path` {#key-path} -- X.509キーを含むPEMファイルのパス -- デフォルト値: `""` +- X.509キーを含むPEMファイルのパス +- デフォルト値: `""` ### `cert-allowed-cn` {#cert-allowed-cn} -- クライアントから提示される証明書において許容されるX.509共通名のリスト。提示された共通名がリスト内のいずれかのエントリと完全に一致する場合にのみ、リクエストが許可されます。 -- デフォルト値: `[]` 。これは、クライアント証明書のCNチェックがデフォルトで無効になっていることを意味します。 +- クライアントから提示される証明書において許容されるX.509共通名のリスト。提示された共通名がリスト内のいずれかのエントリと完全に一致する場合にのみ、リクエストが許可されます。 +- デフォルト値: `[]` 。これは、クライアント証明書のCNチェックがデフォルトで無効になっていることを意味します。 ### `redact-info-log` v4.0.8の新機能 {#redact-info-log-new-in-v408} -- この設定項目は、ログのマスキングを有効または無効にします。値のオプション: `true` 、 `false` 、 `"on"` 、 `"off"` 、および`"marker"` 。 `"on"` 、 `"off"` 、および`"marker"`オプションは、v8.3.0 で導入されました。 -- 設定項目が`false`または`"off"`に設定されている場合、ログの秘匿化は無効になります。 -- 設定項目が`true`または`"on"`に設定されている場合、ログ内のすべてのユーザーデータは`?`に置き換えられます。 -- 設定項目が`"marker"`に設定されている場合、ログ内のすべてのユーザーデータは`‹ ›`で囲まれます。ユーザーデータに`‹`または`›`が含まれている場合、 `‹`は`‹‹`にエスケープされ、 `›`は`››`にエスケープされます。マークされたログに基づいて、ログの表示時にマークされた情報を非機密化するかどうかを決定できます。 -- デフォルト値: `false` -- 詳しい使い方は[TiKV側でのログの秘匿化](/log-redaction.md#log-redaction-in-tikv-side)をご覧ください。 +- この設定項目は、ログのマスキングを有効または無効にします。値のオプション: `true` 、 `false` 、 `"on"` 、 `"off"` 、および`"marker"` 。 `"on"` 、 `"off"` 、および`"marker"`オプションは、v8.3.0 で導入されました。 +- 設定項目が`false`または`"off"`に設定されている場合、ログの秘匿化は無効になります。 +- 設定項目が`true`または`"on"`に設定されている場合、ログ内のすべてのユーザーデータは`?`に置き換えられます。 +- 設定項目が`"marker"`に設定されている場合、ログ内のすべてのユーザーデータは`‹ ›`で囲まれます。ユーザーデータに`‹`または`›`が含まれている場合、 `‹`は`‹‹`にエスケープされ、 `›`は`››`にエスケープされます。マークされたログに基づいて、ログの表示時にマークされた情報を非機密化するかどうかを決定できます。 +- デフォルト値: `false` +- 詳しい使い方は[TiKV側でのログの秘匿化](/log-redaction.md#log-redaction-in-tikv-side)をご覧ください。 ## セキュリティ暗号化 {#securityencryption} @@ -2265,29 +2265,29 @@ Raft Engineに関連するコンフィグレーション項目。 ### `data-encryption-method` {#data-encryption-method} -- データファイルの暗号化方法 -- 値のオプション: "plaintext", "aes128-ctr", "aes192-ctr", "aes256-ctr", "sm4-ctr" (v6.3.0以降でサポート) -- 「plaintext」以外の値を指定すると、暗号化が有効になり、マスターキーを指定する必要があります。 -- デフォルト値: `"plaintext"` +- データファイルの暗号化方法 +- 値のオプション: "plaintext", "aes128-ctr", "aes192-ctr", "aes256-ctr", "sm4-ctr" (v6.3.0以降でサポート) +- 「plaintext」以外の値を指定すると、暗号化が有効になり、マスターキーを指定する必要があります。 +- デフォルト値: `"plaintext"` ### `data-key-rotation-period` {#data-key-rotation-period} -- TiKVがデータ暗号化キーをローテーションする頻度を指定します。 -- デフォルト値: `7d` +- TiKVがデータ暗号化キーをローテーションする頻度を指定します。 +- デフォルト値: `7d` ### `enable-file-dictionary-log` {#enable-file-dictionary-log} -- TiKVが暗号化メタデータを管理する際に、I/Oとミューテックスの競合を軽減するための最適化を有効にします。 -- この構成パラメーターが (デフォルトで) 有効になっている場合に発生する可能性のある互換性の問題を回避するには、詳細については[保存時の暗号化- TiKVバージョン間の互換性](/encryption-at-rest.md#compatibility-between-tikv-versions)を参照してください。 -- デフォルト値: `true` +- TiKVが暗号化メタデータを管理する際に、I/Oとミューテックスの競合を軽減するための最適化を有効にします。 +- この構成パラメーターが (デフォルトで) 有効になっている場合に発生する可能性のある互換性の問題を回避するには、詳細については[保存時の暗号化- TiKVバージョン間の互換性](/encryption-at-rest.md#compatibility-between-tikv-versions)を参照してください。 +- デフォルト値: `true` ### `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} @@ -2295,20 +2295,20 @@ TiDB LightningのインポートおよびBR復元に関連するコンフィグ ### `num-threads` {#num-threads-1} -- RPCリクエストを処理するスレッド数 -- デフォルト値: `8` -- 最小値: `1` +- RPCリクエストを処理するスレッド数 +- デフォルト値: `8` +- 最小値: `1` ### `stream-channel-window` {#stream-channel-window} -- ストリームチャネルのウィンドウサイズ。チャネルが満杯になると、ストリームはブロックされます。 -- デフォルト値: `128` +- ストリームチャネルのウィンドウサイズ。チャネルが満杯になると、ストリームはブロックされます。 +- デフォルト値: `128` ### `memory-use-ratio` v6.5.0で追加 {#memory-use-ratio-new-in-v650} -- バージョン6.5.0以降、PITRはメモリ内のバックアップログファイルに直接アクセスしてデータを復元することをサポートしています。この設定項目は、PITRで使用可能なメモリとTiKVの総メモリの比率を指定します。 -- 値の範囲：[0.0, 0.5] -- デフォルト値は`0.3`で、これはシステムメモリの 30% が PITR に使用可能であることを意味します。値が`0.0`の場合、PITR はログファイルをローカルディレクトリにダウンロードすることによって実行されます。 +- バージョン6.5.0以降、PITRはメモリ内のバックアップログファイルに直接アクセスしてデータを復元することをサポートしています。この設定項目は、PITRで使用可能なメモリとTiKVの総メモリの比率を指定します。 +- 値の範囲：[0.0, 0.5] +- デフォルト値は`0.3`で、これはシステムメモリの 30% が PITR に使用可能であることを意味します。値が`0.0`の場合、PITR はログファイルをローカルディレクトリにダウンロードすることによって実行されます。 > **Note:** > @@ -2318,29 +2318,29 @@ TiDB LightningのインポートおよびBR復元に関連するコンフィグ ### `batch-keys` {#batch-keys} -- 一度にガベージコレクションされるキーの数 -- デフォルト値: `512` +- 一度にガベージコレクションされるキーの数 +- デフォルト値: `512` ### `max-write-bytes-per-sec` {#max-write-bytes-per-sec} -- GCワーカーが1秒間にRocksDBに書き込むことができる最大バイト数。 -- 値が`0`に設定されている場合、制限はありません。 -- デフォルト値: `"0"` +- GCワーカーが1秒間にRocksDBに書き込むことができる最大バイト数。 +- 値が`0`に設定されている場合、制限はありません。 +- デフォルト値: `"0"` ### `enable-compaction-filter` v5.0の新機能 {#enable-compaction-filter-new-in-v50} -- コンパクションフィルタ機能でGCを有効にするかどうかを制御します。 -- デフォルト値: `true` +- コンパクションフィルタ機能でGCを有効にするかどうかを制御します。 +- デフォルト値: `true` ### `ratio-threshold` {#ratio-threshold} -- GCをトリガーするガベージ比率のしきい値。 -- デフォルト値: `1.1` +- GCをトリガーするガベージ比率のしきい値。 +- デフォルト値: `1.1` ### `num-threads` v6.5.8、v7.1.4、v7.5.1、および v7.6.0 で追加 {#num-threads-new-in-v658-v714-v751-and-v760} -- `enable-compaction-filter`が`false`の場合の GC スレッドの数。 -- デフォルト値: `1` +- `enable-compaction-filter`が`false`の場合の GC スレッドの数。 +- デフォルト値: `1` ## gc.自動圧縮 {#gcauto-compaction} @@ -2348,60 +2348,60 @@ TiKVの自動圧縮の動作を設定します。 ### `check-interval` v7.5.7 および v8.5.4 で追加 {#check-interval-new-in-v757-and-v854} -- TiKVが自動圧縮をトリガーするかどうかを確認する間隔。この間隔内では、自動圧縮条件を満たすリージョンが優先度に基づいて処理されます。間隔が経過すると、TiKVはリージョン情報を再スキャンし、優先度を再計算します。 -- デフォルト値: `"300s"` +- TiKVが自動圧縮をトリガーするかどうかを確認する間隔。この間隔内では、自動圧縮条件を満たすリージョンが優先度に基づいて処理されます。間隔が経過すると、TiKVはリージョン情報を再スキャンし、優先度を再計算します。 +- デフォルト値: `"300s"` ### `tombstone-num-threshold` v7.5.7 および v8.5.4 で追加 {#tombstone-num-threshold-new-in-v757-and-v854} -- TiKVの自動圧縮をトリガーするために必要なRocksDBのtombstoneの数。tombstoneの数がこのしきい値に達するか、tombstoneの割合が[`tombstone-percent-threshold`](#tombstone-percent-threshold-new-in-v757-and-v854)に達すると、TiKVは自動圧縮をトリガーします。 -- この設定項目は[圧縮フィルター](/garbage-collection-configuration.md)が無効な場合にのみ有効になります。 -- デフォルト値: `10000` -- 最小値: `0` +- TiKVの自動圧縮をトリガーするために必要なRocksDBのtombstoneの数。tombstoneの数がこのしきい値に達するか、tombstoneの割合が[`tombstone-percent-threshold`](#tombstone-percent-threshold-new-in-v757-and-v854)に達すると、TiKVは自動圧縮をトリガーします。 +- この設定項目は[圧縮フィルター](/garbage-collection-configuration.md)が無効な場合にのみ有効になります。 +- デフォルト値: `10000` +- 最小値: `0` ### `tombstone-percent-threshold` v7.5.7 および v8.5.4 で追加 {#tombstone-percent-threshold-new-in-v757-and-v854} -- TiKVによる自動圧縮をトリガーするために必要なRocksDBのtombstoneの割合。tombstoneの割合がこのしきい値に達するか、tombstoneの数が[`tombstone-num-threshold`](#tombstone-num-threshold-new-in-v757-and-v854)に達すると、TiKVは自動圧縮をトリガーします。 -- この設定項目は[圧縮フィルター](/garbage-collection-configuration.md)が無効な場合にのみ有効になります。 -- デフォルト値: `30` -- 最小値: `0` -- 最大値: `100` +- TiKVによる自動圧縮をトリガーするために必要なRocksDBのtombstoneの割合。tombstoneの割合がこのしきい値に達するか、tombstoneの数が[`tombstone-num-threshold`](#tombstone-num-threshold-new-in-v757-and-v854)に達すると、TiKVは自動圧縮をトリガーします。 +- この設定項目は[圧縮フィルター](/garbage-collection-configuration.md)が無効な場合にのみ有効になります。 +- デフォルト値: `30` +- 最小値: `0` +- 最大値: `100` ### `redundant-rows-threshold` v7.5.7 および v8.5.4 で追加 {#redundant-rows-threshold-new-in-v757-and-v854} -- TiKVの自動圧縮をトリガーするために必要な冗長MVCC行の数。冗長行には、RocksDBのtombstone、TiKVの古いバージョン、およびTiKVの削除tombstoneが含まれます。冗長MVCC行の数がこのしきい値に達するか、これらの行の割合が[`redundant-rows-percent-threshold`](#redundant-rows-percent-threshold-new-in-v757-and-v854)に達すると、TiKVは自動圧縮をトリガーします。 -- この設定項目は[圧縮フィルター](/garbage-collection-configuration.md)が有効な場合にのみ有効になります。 -- デフォルト値: `50000` -- 最小値: `0` +- TiKVの自動圧縮をトリガーするために必要な冗長MVCC行の数。冗長行には、RocksDBのtombstone、TiKVの古いバージョン、およびTiKVの削除tombstoneが含まれます。冗長MVCC行の数がこのしきい値に達するか、これらの行の割合が[`redundant-rows-percent-threshold`](#redundant-rows-percent-threshold-new-in-v757-and-v854)に達すると、TiKVは自動圧縮をトリガーします。 +- この設定項目は[圧縮フィルター](/garbage-collection-configuration.md)が有効な場合にのみ有効になります。 +- デフォルト値: `50000` +- 最小値: `0` ### `redundant-rows-percent-threshold` （v7.5.7およびv8.5.4で追加） {#redundant-rows-percent-threshold-new-in-v757-and-v854} -- TiKV の自動圧縮をトリガーするために必要な冗長 MVCC 行の割合。冗長行には、RocksDB のtombstone、TiKV の古いバージョン、および TiKV の削除tombstoneが含まれます。冗長 MVCC 行の数が[`redundant-rows-threshold`](#redundant-rows-threshold-new-in-v757-and-v854)に達するか、これらの行の割合が`redundant-rows-percent-threshold`に達すると、TiKV は自動圧縮をトリガーします。 -- この設定項目は[圧縮フィルター](/garbage-collection-configuration.md)が有効な場合にのみ有効になります。 -- デフォルト値: `20` -- 最小値: `0` -- 最大値: `100` +- TiKV の自動圧縮をトリガーするために必要な冗長 MVCC 行の割合。冗長行には、RocksDB のtombstone、TiKV の古いバージョン、および TiKV の削除tombstoneが含まれます。冗長 MVCC 行の数が[`redundant-rows-threshold`](#redundant-rows-threshold-new-in-v757-and-v854)に達するか、これらの行の割合が`redundant-rows-percent-threshold`に達すると、TiKV は自動圧縮をトリガーします。 +- この設定項目は[圧縮フィルター](/garbage-collection-configuration.md)が有効な場合にのみ有効になります。 +- デフォルト値: `20` +- 最小値: `0` +- 最大値: `100` ### `bottommost-level-force` v7.5.7 および v8.5.4 で追加 {#bottommost-level-force-new-in-v757-and-v854} -- RocksDBの最下位ファイルに対して強制的に圧縮を実行するかどうかを制御します。 -- デフォルト値: `true` +- RocksDBの最下位ファイルに対して強制的に圧縮を実行するかどうかを制御します。 +- デフォルト値: `true` ### `mvcc-read-aware-enabled` v8.5.6の新機能 {#mvcc-read-aware-enabled-new-in-v856} -- MVCC読み取り対応の圧縮を有効にするかどうかを制御します。有効にすると、TiKVは読み取り要求中にスキャンされたMVCCバージョンの数を追跡し、この情報を使用して、MVCC読み取り増幅率の高いリージョンに対して圧縮を優先します。これにより、スキャン中に多くの古いバージョンに遭遇するホットリージョンの読み取りレイテンシーが削減されます。 -- デフォルト値: `false` +- MVCC読み取り対応の圧縮を有効にするかどうかを制御します。有効にすると、TiKVは読み取り要求中にスキャンされたMVCCバージョンの数を追跡し、この情報を使用して、MVCC読み取り増幅率の高いリージョンに対して圧縮を優先します。これにより、スキャン中に多くの古いバージョンに遭遇するホットリージョンの読み取りレイテンシーが削減されます。 +- デフォルト値: `false` ### `mvcc-scan-threshold` v8.5.6で追加 {#mvcc-scan-threshold-new-in-v856} -- リージョンを圧縮候補としてマークするために、読み取り要求ごとにスキャンされる MVCC バージョンの最小数。この構成項目は、 [`mvcc-read-aware-enabled`](#mvcc-read-aware-enabled-new-in-v856)が`true`に設定されている場合にのみ有効になります。 -- デフォルト値: `1000` -- 最小値: `0` +- リージョンを圧縮候補としてマークするために、読み取り要求ごとにスキャンされる MVCC バージョンの最小数。この構成項目は、 [`mvcc-read-aware-enabled`](#mvcc-read-aware-enabled-new-in-v856)が`true`に設定されている場合にのみ有効になります。 +- デフォルト値: `1000` +- 最小値: `0` ### `mvcc-read-weight` v8.5.6で追加 {#mvcc-read-weight-new-in-v856} -- リージョンの圧縮優先度スコアを計算する際に、MVCC 読み取りアクティビティに適用される重み乗数。値が大きいほど、tombstone密度などの他の圧縮トリガーと比較して、MVCC 読み取り増幅に重みが高くなります。この設定項目は、 [`mvcc-read-aware-enabled`](#mvcc-read-aware-enabled-new-in-v856)が`true`に設定されている場合にのみ有効になります。 -- デフォルト値: `3.0` -- 最小値: `0.0` +- リージョンの圧縮優先度スコアを計算する際に、MVCC 読み取りアクティビティに適用される重み乗数。値が大きいほど、tombstone密度などの他の圧縮トリガーと比較して、MVCC 読み取り増幅に重みが高くなります。この設定項目は、 [`mvcc-read-aware-enabled`](#mvcc-read-aware-enabled-new-in-v856)が`true`に設定されている場合にのみ有効になります。 +- デフォルト値: `3.0` +- 最小値: `0.0` ## バックアップ {#backup} @@ -2409,26 +2409,26 @@ BRバックアップに関連するコンフィグレーション項目。 ### `num-threads` {#num-threads} -- バックアップを処理するワーカー スレッドの数 -- デフォルト値: `MIN(CPU * 0.5, 8)` -- 値の範囲: `[1, CPU]` -- 最小値: `1` +- バックアップを処理するワーカー スレッドの数 +- デフォルト値: `MIN(CPU * 0.5, 8)` +- 値の範囲: `[1, CPU]` +- 最小値: `1` ### `batch-size` {#batch-size} -- 一度にバックアップするデータ範囲の数 -- デフォルト値: `8` +- 一度にバックアップするデータ範囲の数 +- デフォルト値: `8` ### `sst-max-size` {#sst-max-size} -- バックアップSSTファイルのサイズのしきい値。TiKVリージョン内のバックアップファイルのサイズがこのしきい値を超えると、TiKVリージョンが複数のリージョン範囲に分割され、ファイルは複数のファイルにバックアップされます。分割されたリージョン内の各ファイルは、 `sst-max-size`と同じサイズ（またはわずかに大きいサイズ）です。 -- 例えば、 `[a,e)`リージョンのバックアップ ファイルのサイズが`sst-max-size`より大きい場合、そのファイルは { `[a,b)` 、 `[b,c)`および`[c,d)` `[d,e)` } の領域を持つ複数のファイルにバックアップされ、 `[a,b)` 、 `[b,c)` 、 `[c,d)`のサイズは`sst-max-size`と同じ (またはわずかに大きい) です。 -- デフォルト値: `"384MiB"` 。v8.4.0 より前のバージョンでは、デフォルト値は`"144MiB"`です。 +- バックアップSSTファイルのサイズのしきい値。TiKVリージョン内のバックアップファイルのサイズがこのしきい値を超えると、TiKVリージョンが複数のリージョン範囲に分割され、ファイルは複数のファイルにバックアップされます。分割されたリージョン内の各ファイルは、 `sst-max-size`と同じサイズ（またはわずかに大きいサイズ）です。 +- 例えば、 `[a,e)`リージョンのバックアップ ファイルのサイズが`sst-max-size`より大きい場合、そのファイルは { `[a,b)` 、 `[b,c)`および`[c,d)` `[d,e)` } の領域を持つ複数のファイルにバックアップされ、 `[a,b)` 、 `[b,c)` 、 `[c,d)`のサイズは`sst-max-size`と同じ (またはわずかに大きい) です。 +- デフォルト値: `"384MiB"` 。v8.4.0 より前のバージョンでは、デフォルト値は`"144MiB"`です。 ### `enable-auto-tune` v5.4.0の新機能 {#enable-auto-tune-new-in-v540} -- クラスタのリソース使用率が高い場合に、バックアップタスクが使用するリソースを制限してクラスタへの影響を軽減するかどうかを制御します。詳細については、 [BRオートチューン](/br/br-auto-tune.md)を参照してください。 -- デフォルト値: `true` +- クラスタのリソース使用率が高い場合に、バックアップタスクが使用するリソースを制限してクラスタへの影響を軽減するかどうかを制御します。詳細については、 [BRオートチューン](/br/br-auto-tune.md)を参照してください。 +- デフォルト値: `true` ### `s3-multi-part-size` v5.3.2の新機能 {#s3-multi-part-size-new-in-v532} @@ -2436,9 +2436,9 @@ BRバックアップに関連するコンフィグレーション項目。 > > この設定項目は、S3 レート制限によって引き起こされるバックアップの失敗に対処するために導入されました。TiDB v6.1.1 以降では、この値の設定には注意してください。大きく設定しすぎると、ネットワークが不安定な場合に大きなアップロードパートが失敗したりタイムアウトしたりする可能性があります。 -- バックアップ時にS3へのマルチパートアップロードを実行する際に使用されるパートサイズです。この設定値を調整することで、S3に送信されるリクエスト数を制御できます。 -- データが S3 にバックアップされ、バックアップ ファイルがこの設定項目の値より大きい場合、 [マルチパートアップロード](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UploadPart.html)が自動的に有効になります。圧縮率に基づいて、96 MiBリージョンによって生成されるバックアップ ファイルは約 10 MiB ～ 30 MiB になります。 -- デフォルト値: 5MiB +- バックアップ時にS3へのマルチパートアップロードを実行する際に使用されるパートサイズです。この設定値を調整することで、S3に送信されるリクエスト数を制御できます。 +- データが S3 にバックアップされ、バックアップ ファイルがこの設定項目の値より大きい場合、 [マルチパートアップロード](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UploadPart.html)が自動的に有効になります。圧縮率に基づいて、96 MiBリージョンによって生成されるバックアップ ファイルは約 10 MiB ～ 30 MiB になります。 +- デフォルト値: 5MiB ### `gcp-v2-enable` New in v8.5.7 {#gcp-v2-enable-new-in-v857-1} @@ -2452,14 +2452,14 @@ BRバックアップに関連するコンフィグレーション項目。 ### `home` {#home} -- HDFSシェルコマンドの場所を指定し、TiKVがシェルコマンドを見つけられるようにします。この設定項目は、環境変数`$HADOOP_HOME`と同じ効果があります。 -- デフォルト値: `""` +- HDFSシェルコマンドの場所を指定し、TiKVがシェルコマンドを見つけられるようにします。この設定項目は、環境変数`$HADOOP_HOME`と同じ効果があります。 +- デフォルト値: `""` ### `linux-user` {#linux-user} -- TiKVがHDFSシェルコマンドを実行する際に使用するLinuxユーザーを指定します。 -- この設定項目が設定されていない場合、TiKVは現在のLinuxユーザーを使用します。 -- デフォルト値: `""` +- TiKVがHDFSシェルコマンドを実行する際に使用するLinuxユーザーを指定します。 +- この設定項目が設定されていない場合、TiKVは現在のLinuxユーザーを使用します。 +- デフォルト値: `""` ## ログバックアップ {#log-backup} @@ -2467,41 +2467,41 @@ BRバックアップに関連するコンフィグレーション項目。 ### v6.2.0で`enable` {#enable-new-in-v620} -- ログバックアップを有効にするかどうかを決定します。 -- デフォルト値: `true` +- ログバックアップを有効にするかどうかを決定します。 +- デフォルト値: `true` ### `file-size-limit` v6.2.0で追加 {#file-size-limit-new-in-v620} -- 保存するバックアップログデータのサイズ制限。 -- デフォルト値: 256MiB -- 注：通常、 `file-size-limit`の値は、外部ストレージに表示されるバックアップファイルのサイズよりも大きくなります。これは、バックアップファイルが外部ストレージにアップロードされる前に圧縮されるためです。 +- 保存するバックアップログデータのサイズ制限。 +- デフォルト値: 256MiB +- 注：通常、 `file-size-limit`の値は、外部ストレージに表示されるバックアップファイルのサイズよりも大きくなります。これは、バックアップファイルが外部ストレージにアップロードされる前に圧縮されるためです。 ### `initial-scan-pending-memory-quota` v6.2.0 の新機能 {#initial-scan-pending-memory-quota-new-in-v620} -- ログバックアップ中に増分スキャンデータを保存するために使用されるキャッシュの割り当て量。 -- デフォルト値: `min(Total machine memory * 10%, 512 MiB)` +- ログバックアップ中に増分スキャンデータを保存するために使用されるキャッシュの割り当て量。 +- デフォルト値: `min(Total machine memory * 10%, 512 MiB)` ### `initial-scan-rate-limit` v6.2.0で追加 {#initial-scan-rate-limit-new-in-v620} -- ログバックアップ中の増分データスキャンにおけるスループットの制限値。これは、1秒間にディスクから読み取れるデータの最大量を意味します。数値のみを指定した場合（例： `60` ）、単位はKiBではなくバイトになります。 -- デフォルト値: 60MiB -- 最小値: 1MiB +- ログバックアップ中の増分データスキャンにおけるスループットの制限値。これは、1秒間にディスクから読み取れるデータの最大量を意味します。数値のみを指定した場合（例： `60` ）、単位はKiBではなくバイトになります。 +- デフォルト値: 60MiB +- 最小値: 1MiB ### `max-flush-interval` v6.2.0で追加 {#max-flush-interval-new-in-v620} -- ログバックアップにおいて、バックアップデータを外部ストレージに書き込む最大間隔。 -- デフォルト値：3分 +- ログバックアップにおいて、バックアップデータを外部ストレージに書き込む最大間隔。 +- デフォルト値：3分 ### `num-threads` （v6.2.0の新機能） {#num-threads-new-in-v620} -- ログバックアップで使用されるスレッド数。 -- デフォルト値：CPU * 0.5 -- 値の範囲：[2, 12] +- ログバックアップで使用されるスレッド数。 +- デフォルト値：CPU * 0.5 +- 値の範囲：[2, 12] ### `temp-path` v6.2.0で追加 {#temp-path-new-in-v620} -- ログファイルが外部ストレージに書き込まれる前に一時的に保存されるパス。 -- デフォルト値: `${deploy-dir}/data/log-backup-temp` +- ログファイルが外部ストレージに書き込まれる前に一時的に保存されるパス。 +- デフォルト値: `${deploy-dir}/data/log-backup-temp` ### `gcp-v2-enable` New in v8.5.7 {#gcp-v2-enable-new-in-v857} @@ -2517,8 +2517,8 @@ TiCDCに関連するコンフィグレーション項目。 ### `min-ts-interval` {#min-ts-interval} -- 解決済みTSが計算され、転送される間隔。 -- デフォルト値: `"1s"` 。 +- 解決済みTSが計算され、転送される間隔。 +- デフォルト値: `"1s"` 。 > **Note:** > @@ -2526,35 +2526,35 @@ TiCDCに関連するコンフィグレーション項目。 ### `old-value-cache-memory-quota` {#old-value-cache-memory-quota} -- TiCDCの旧値におけるメモリ使用量の上限。 -- デフォルト値: `512MiB` +- TiCDCの旧値におけるメモリ使用量の上限。 +- デフォルト値: `512MiB` ### `sink-memory-quota` {#sink-memory-quota} -- TiCDCデータ変更イベントによるメモリ使用量の上限。 -- デフォルト値: `512MiB` +- TiCDCデータ変更イベントによるメモリ使用量の上限。 +- デフォルト値: `512MiB` ### `incremental-scan-speed-limit` {#incremental-scan-speed-limit} -- 履歴データが段階的にスキャンされる最大速度。 -- デフォルト値： `"128MiB"` 。これは1秒あたり128MiBを意味します。 +- 履歴データが段階的にスキャンされる最大速度。 +- デフォルト値： `"128MiB"` 。これは1秒あたり128MiBを意味します。 ### `incremental-scan-threads` {#incremental-scan-threads} -- 履歴データを増分的にスキャンするタスクに使用するスレッド数。 -- デフォルト値： `4` 、これは4つのスレッドを意味します。 +- 履歴データを増分的にスキャンするタスクに使用するスレッド数。 +- デフォルト値： `4` 、これは4つのスレッドを意味します。 ### `incremental-scan-concurrency` {#incremental-scan-concurrency} -- 履歴データを増分的にスキャンするタスクの同時実行の最大数。 -- デフォルト値： `6` 。これは、最大で6つのタスクを同時に実行できることを意味します。 -- 注： `incremental-scan-concurrency`の値は`incremental-scan-threads`の値以上でなければなりません。そうでない場合、TiKV は起動時にエラーを報告します。 +- 履歴データを増分的にスキャンするタスクの同時実行の最大数。 +- デフォルト値： `6` 。これは、最大で6つのタスクを同時に実行できることを意味します。 +- 注： `incremental-scan-concurrency`の値は`incremental-scan-threads`の値以上でなければなりません。そうでない場合、TiKV は起動時にエラーを報告します。 ### `incremental-scan-concurrency-limit` （v7.6.0で追加） {#incremental-scan-concurrency-limit-new-in-v760} -- 履歴データを増分スキャンするタスクの実行待ちキューの最大長。実行待ちタスク数がこの制限を超えると、新規タスクは拒否されます。 -- デフォルト値： `10000` 。これは、最大で10000個のタスクを実行待ちキューに入れることができることを意味します。 -- 注: `incremental-scan-concurrency-limit`は[`incremental-scan-concurrency`](#incremental-scan-concurrency)以上である必要があります。そうでない場合、TiKV は`incremental-scan-concurrency`を使用してこの設定を上書きします。 +- 履歴データを増分スキャンするタスクの実行待ちキューの最大長。実行待ちタスク数がこの制限を超えると、新規タスクは拒否されます。 +- デフォルト値： `10000` 。これは、最大で10000個のタスクを実行待ちキューに入れることができることを意味します。 +- 注: `incremental-scan-concurrency-limit`は[`incremental-scan-concurrency`](#incremental-scan-concurrency)以上である必要があります。そうでない場合、TiKV は`incremental-scan-concurrency`を使用してこの設定を上書きします。 ## resolved-ts {#resolved-ts} @@ -2562,18 +2562,18 @@ TiCDCに関連するコンフィグレーション項目。 ### `enable` {#enable} -- すべてのリージョンに対して解決済みTSを維持するかどうかを決定します。 -- デフォルト値: `true` +- すべてのリージョンに対して解決済みTSを維持するかどうかを決定します。 +- デフォルト値: `true` ### `advance-ts-interval` {#advance-ts-interval} -- 解決済みTSが計算され、転送される間隔。 -- デフォルト値: `"20s"` +- 解決済みTSが計算され、転送される間隔。 +- デフォルト値: `"20s"` ### `scan-lock-pool-size` {#scan-lock-pool-size} -- Resolved TS を初期化する際に、TiKV が MVCC (マルチバージョン同時実行制御) ロックデータをスキャンするために使用するスレッドの数。 -- デフォルト値: `2`は、2つのスレッドを意味します。 +- Resolved TS を初期化する際に、TiKV が MVCC (マルチバージョン同時実行制御) ロックデータをスキャンするために使用するスレッドの数。 +- デフォルト値: `2`は、2つのスレッドを意味します。 ## pessimistic-txn {#pessimistic-txn} @@ -2581,37 +2581,37 @@ TiCDCに関連するコンフィグレーション項目。 ### `wait-for-lock-timeout` {#wait-for-lock-timeout} -- TiKV の悲観的トランザクションが他のトランザクションがロックを解放するのを待つ最長時間。タイムアウトが発生した場合、TiDB にエラーが返され、TiDB はロックの追加を再試行します。ロック待機タイムアウトは`innodb_lock_wait_timeout`で設定されます。 -- デフォルト値: `"1s"` -- 最小値: `"1ms"` +- TiKV の悲観的トランザクションが他のトランザクションがロックを解放するのを待つ最長時間。タイムアウトが発生した場合、TiDB にエラーが返され、TiDB はロックの追加を再試行します。ロック待機タイムアウトは`innodb_lock_wait_timeout`で設定されます。 +- デフォルト値: `"1s"` +- 最小値: `"1ms"` ### `wake-up-delay-duration` {#wake-up-delay-duration} -- 悲観的トランザクションがロックを解放すると、ロックを待機しているすべてのトランザクションのうち、 `start_ts`が最小のトランザクションのみが起動されます。他のトランザクションは`wake-up-delay-duration`の後に起動されます。 -- デフォルト値: `"20ms"` +- 悲観的トランザクションがロックを解放すると、ロックを待機しているすべてのトランザクションのうち、 `start_ts`が最小のトランザクションのみが起動されます。他のトランザクションは`wake-up-delay-duration`の後に起動されます。 +- デフォルト値: `"20ms"` ### `pipelined` {#pipelined} -- この設定項目を有効にすると、悲観的ロックを追加するパイプライン処理が有効になります。この機能を有効にすると、データがロック可能であることを検出した後、TiKV は直ちに TiDB に通知し、後続のリクエストを実行して悲観的ロックを非同期で書き込みます。これにより、レイテンシーが大幅に削減され、悲観的トランザクションのパフォーマンスが著しく向上します。ただし、悲観的ロックの非同期書き込みが失敗する可能性は依然として低く、その場合、悲観的トランザクションのコミットが失敗する可能性があります。 -- デフォルト値: `true` +- この設定項目を有効にすると、悲観的ロックを追加するパイプライン処理が有効になります。この機能を有効にすると、データがロック可能であることを検出した後、TiKV は直ちに TiDB に通知し、後続のリクエストを実行して悲観的ロックを非同期で書き込みます。これにより、レイテンシーが大幅に削減され、悲観的トランザクションのパフォーマンスが著しく向上します。ただし、悲観的ロックの非同期書き込みが失敗する可能性は依然として低く、その場合、悲観的トランザクションのコミットが失敗する可能性があります。 +- デフォルト値: `true` ### `in-memory` （v6.0.0の新機能） {#in-memory-new-in-v600} -- インメモリ悲観的ロック機能を有効にします。この機能を有効にすると、悲観的トランザクションはロックをディスクに書き込んだり、他のレプリカに複製したりする代わりに、ロックをメモリに保存しようとします。これにより、悲観的トランザクションのパフォーマンスが向上します。ただし、悲観的ロックが失われ、悲観的トランザクションのコミットが失敗する可能性は依然として低いながらも存在します。 -- デフォルト値: `true` -- `in-memory`は、 `pipelined`の値が`true`の場合にのみ有効になることに注意してください。 +- インメモリ悲観的ロック機能を有効にします。この機能を有効にすると、悲観的トランザクションはロックをディスクに書き込んだり、他のレプリカに複製したりする代わりに、ロックをメモリに保存しようとします。これにより、悲観的トランザクションのパフォーマンスが向上します。ただし、悲観的ロックが失われ、悲観的トランザクションのコミットが失敗する可能性は依然として低いながらも存在します。 +- デフォルト値: `true` +- `in-memory`は、 `pipelined`の値が`true`の場合にのみ有効になることに注意してください。 ### `in-memory-peer-size-limit` v8.4.0で追加 {#in-memory-peer-size-limit-new-in-v840} -- リージョン内の[インメモリ悲観的ロック](/pessimistic-transaction.md#in-memory-pessimistic-lock)のメモリ使用制限を制御します。この制限を超えると、TiKV は悲観的ロックを永続的に書き込みます。 -- デフォルト値: `512KiB` -- 単位：KiB｜MiB｜GiB +- リージョン内の[インメモリ悲観的ロック](/pessimistic-transaction.md#in-memory-pessimistic-lock)のメモリ使用制限を制御します。この制限を超えると、TiKV は悲観的ロックを永続的に書き込みます。 +- デフォルト値: `512KiB` +- 単位：KiB｜MiB｜GiB ### `in-memory-instance-size-limit` v8.4.0で追加 {#in-memory-instance-size-limit-new-in-v840} -- TiKV インスタンスの[インメモリ悲観的ロック](/pessimistic-transaction.md#in-memory-pessimistic-lock)のメモリ使用量制限を制御します。この制限を超えると、TiKV は悲観的ロックを永続的に書き込みます。 -- デフォルト値: `100MiB` -- 単位：KiB｜MiB｜GiB +- TiKV インスタンスの[インメモリ悲観的ロック](/pessimistic-transaction.md#in-memory-pessimistic-lock)のメモリ使用量制限を制御します。この制限を超えると、TiKV は悲観的ロックを永続的に書き込みます。 +- デフォルト値: `100MiB` +- 単位：KiB｜MiB｜GiB ## クォータ {#quota} @@ -2619,9 +2619,9 @@ TiCDCに関連するコンフィグレーション項目。 ### `max-delay-duration` v6.0.0で追加 {#max-delay-duration-new-in-v600} -- 単一の読み取りまたは書き込みリクエストがフォアグラウンドで処理されるまでに強制的に待機させられる最大時間。 -- デフォルト値: `500ms` -- 推奨設定：ほとんどの場合、デフォルト値を使用することをお勧めします。インスタンスでメモリ不足（OOM）や激しいパフォーマンスの不安定さが発生する場合は、値を1Sに設定して、リクエストの待機時間を1秒未満に短縮できます。 +- 単一の読み取りまたは書き込みリクエストがフォアグラウンドで処理されるまでに強制的に待機させられる最大時間。 +- デフォルト値: `500ms` +- 推奨設定：ほとんどの場合、デフォルト値を使用することをお勧めします。インスタンスでメモリ不足（OOM）や激しいパフォーマンスの不安定さが発生する場合は、値を1Sに設定して、リクエストの待機時間を1秒未満に短縮できます。 ### フォアグラウンドクォータリミッター {#foreground-quota-limiter} @@ -2631,22 +2631,22 @@ TiKV がデプロイされているマシンにリソースが限られている #### `foreground-cpu-time` v6.0.0の新機能 {#foreground-cpu-time-new-in-v600} -- TiKVフォアグラウンドが読み取りおよび書き込み要求を処理するために使用するCPUリソースのソフトリミット。 -- デフォルト値： `0` （制限なしを意味します） -- 単位：ミリCPU（例： `1500`は、フォアグラウンドリクエストが1.5VのCPUを消費することを意味します） -- 推奨設定: 4 コアを超えるインスタンスの場合は、デフォルト値`0`を使用してください。4 コアのインスタンスの場合は、値を`1000`と`1500`の範囲に設定するとバランスが取れます。2 コアのインスタンスの場合は、値を`1200`より小さくしてください。 +- TiKVフォアグラウンドが読み取りおよび書き込み要求を処理するために使用するCPUリソースのソフトリミット。 +- デフォルト値： `0` （制限なしを意味します） +- 単位：ミリCPU（例： `1500`は、フォアグラウンドリクエストが1.5VのCPUを消費することを意味します） +- 推奨設定: 4 コアを超えるインスタンスの場合は、デフォルト値`0`を使用してください。4 コアのインスタンスの場合は、値を`1000`と`1500`の範囲に設定するとバランスが取れます。2 コアのインスタンスの場合は、値を`1200`より小さくしてください。 #### `foreground-write-bandwidth` v6.0.0の新機能 {#foreground-write-bandwidth-new-in-v600} -- トランザクションがデータを書き込む際の帯域幅に対するソフトリミット。 -- デフォルト値： `0KiB` （制限なしを意味します） -- 推奨設定：ほとんどの場合、デフォルト値の`0`を使用してください。ただし、 `foreground-cpu-time`の設定では書き込み帯域幅を十分に制限できない場合は除きます。例外として、コア数が4以下のインスタンスでは、 `50MiB`よりも小さい値を設定することをお勧めします。 +- トランザクションがデータを書き込む際の帯域幅に対するソフトリミット。 +- デフォルト値： `0KiB` （制限なしを意味します） +- 推奨設定：ほとんどの場合、デフォルト値の`0`を使用してください。ただし、 `foreground-cpu-time`の設定では書き込み帯域幅を十分に制限できない場合は除きます。例外として、コア数が4以下のインスタンスでは、 `50MiB`よりも小さい値を設定することをお勧めします。 #### `foreground-read-bandwidth` v6.0.0の新機能 {#foreground-read-bandwidth-new-in-v600} -- トランザクションとコプロセッサーがデータを読み取る際の帯域幅のソフトリミット。 -- デフォルト値： `0KiB` （制限なしを意味します） -- 推奨設定：ほとんどの場合、デフォルト値の`0`を使用してください。ただし、 `foreground-cpu-time`の設定では読み取り帯域幅を十分に制限できない場合は除きます。例外として、コア数が4以下のインスタンスでは、 `20MiB`よりも小さい値を設定することをお勧めします。 +- トランザクションとコプロセッサーがデータを読み取る際の帯域幅のソフトリミット。 +- デフォルト値： `0KiB` （制限なしを意味します） +- 推奨設定：ほとんどの場合、デフォルト値の`0`を使用してください。ただし、 `foreground-cpu-time`の設定では読み取り帯域幅を十分に制限できない場合は除きます。例外として、コア数が4以下のインスタンスでは、 `20MiB`よりも小さい値を設定することをお勧めします。 ### バックグラウンドクォータリミッター {#background-quota-limiter} @@ -2656,29 +2656,29 @@ TiKV がデプロイされているマシンにリソースが限られている > **Warning:** > -> - バックグラウンドクォータリミッターは、TiDB v6.2.0で導入された実験的機能であり、本番環境での使用は推奨され**ません**。 -> - この機能は、リソースが限られた環境でのみ適しており、TiKVがそのような環境でも安定して動作することを保証します。リソースが豊富な環境でこの機能を有効にすると、リクエスト数がピークに達した際にパフォーマンスが低下する可能性があります。 +> - バックグラウンドクォータリミッターは、TiDB v6.2.0で導入された実験的機能であり、本番環境での使用は推奨され**ません**。 +> - この機能は、リソースが限られた環境でのみ適しており、TiKVがそのような環境でも安定して動作することを保証します。リソースが豊富な環境でこの機能を有効にすると、リクエスト数がピークに達した際にパフォーマンスが低下する可能性があります。 #### `background-cpu-time` v6.2.0の新機能 {#background-cpu-time-new-in-v620} -- TiKVバックグラウンドが読み取りおよび書き込み要求を処理するために使用するCPUリソースのソフトリミット。 -- デフォルト値： `0` （制限なしを意味します） -- 単位：ミリCPU（例： `1500`は、バックグラウンドリクエストが1.5VのCPUを消費することを意味します） +- TiKVバックグラウンドが読み取りおよび書き込み要求を処理するために使用するCPUリソースのソフトリミット。 +- デフォルト値： `0` （制限なしを意味します） +- 単位：ミリCPU（例： `1500`は、バックグラウンドリクエストが1.5VのCPUを消費することを意味します） #### `background-write-bandwidth` v6.2.0の新機能 {#background-write-bandwidth-new-in-v620} -- バックグラウンドトランザクションがデータを書き込む際の帯域幅に対するソフトリミット。 -- デフォルト値： `0KiB` （制限なしを意味します） +- バックグラウンドトランザクションがデータを書き込む際の帯域幅に対するソフトリミット。 +- デフォルト値： `0KiB` （制限なしを意味します） #### `background-read-bandwidth` v6.2.0の新機能 {#background-read-bandwidth-new-in-v620} -- バックグラウンドトランザクションとコプロセッサーがデータを読み取る際の帯域幅のソフトリミット。 -- デフォルト値： `0KiB` （制限なしを意味します） +- バックグラウンドトランザクションとコプロセッサーがデータを読み取る際の帯域幅のソフトリミット。 +- デフォルト値： `0KiB` （制限なしを意味します） #### `enable-auto-tune` v6.2.0の新機能 {#enable-auto-tune-new-in-v620} -- クォータの自動調整を有効にするかどうかを決定します。この設定項目が有効になっている場合、TiKVはTiKVインスタンスの負荷に基づいて、バックグラウンドリクエストのクォータを動的に調整します。 -- デフォルト値： `false` （これは自動チューニングが無効になっていることを意味します） +- クォータの自動調整を有効にするかどうかを決定します。この設定項目が有効になっている場合、TiKVはTiKVインスタンスの負荷に基づいて、バックグラウンドリクエストのクォータを動的に調整します。 +- デフォルト値： `false` （これは自動チューニングが無効になっていることを意味します） ## causal-ts v6.1.0の新機能 {#causal-ts-new-in-v610} @@ -2688,35 +2688,35 @@ TiKV API V2 が有効になっている場合にタイムスタンプを取得 ### `alloc-ahead-buffer` v6.4.0で追加 {#alloc-ahead-buffer-new-in-v640} -- 事前割り当て済みのTSOキャッシュサイズ（期間）。 -- TiKV は、この構成項目で指定された期間に基づいて TSO キャッシュを事前割り当てします。TiKV は、前の期間に基づいて TSO の使用量を推定し、 `alloc-ahead-buffer`を満たす TSO をローカルに要求してキャッシュします。 -- この構成項目は、TiKV API V2 が有効になっている場合の PD 障害の許容度を高めるためによく使用されます ( `storage.api-version = 2` )。 -- この設定項目の値を大きくすると、TSOの消費量とTiKVのメモリオーバーヘッドが増加する可能性があります。十分なTSOを確保するには、PDの設定項目[`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval)の値を下げることをお勧めします。 -- テストによると、 `alloc-ahead-buffer`がデフォルト値の場合、PDリーダーが故障して別のノードに切り替わると、書き込みリクエストのレイテンシーが一時的に増加し、QPSが約15%減少します。 -- ビジネスへの影響を避けるため、PDで`tso-update-physical-interval = "1ms"`を設定し、TiKVで以下の設定項目を設定してください。 - - `causal-ts.alloc-ahead-buffer = "6s"` - - `causal-ts.renew-batch-max-size = 65536` - - `causal-ts.renew-batch-min-size = 2048` -- デフォルト値: `3s` +- 事前割り当て済みのTSOキャッシュサイズ（期間）。 +- TiKV は、この構成項目で指定された期間に基づいて TSO キャッシュを事前割り当てします。TiKV は、前の期間に基づいて TSO の使用量を推定し、 `alloc-ahead-buffer`を満たす TSO をローカルに要求してキャッシュします。 +- この構成項目は、TiKV API V2 が有効になっている場合の PD 障害の許容度を高めるためによく使用されます ( `storage.api-version = 2` )。 +- この設定項目の値を大きくすると、TSOの消費量とTiKVのメモリオーバーヘッドが増加する可能性があります。十分なTSOを確保するには、PDの設定項目[`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval)の値を下げることをお勧めします。 +- テストによると、 `alloc-ahead-buffer`がデフォルト値の場合、PDリーダーが故障して別のノードに切り替わると、書き込みリクエストのレイテンシーが一時的に増加し、QPSが約15%減少します。 +- ビジネスへの影響を避けるため、PDで`tso-update-physical-interval = "1ms"`を設定し、TiKVで以下の設定項目を設定してください。 + - `causal-ts.alloc-ahead-buffer = "6s"` + - `causal-ts.renew-batch-max-size = 65536` + - `causal-ts.renew-batch-min-size = 2048` +- デフォルト値: `3s` ### `renew-interval` {#renew-interval} -- ローカルにキャッシュされたタイムスタンプが更新される間隔。 -- `renew-interval`の間隔で、TiKV はタイムスタンプの更新バッチを開始し、前の期間のタイムスタンプ消費量と[`alloc-ahead-buffer`](#alloc-ahead-buffer-new-in-v640)の設定に応じてキャッシュされたタイムスタンプの数を調整します。このパラメータを大きすぎる値に設定すると、最新の TiKV ワークロードの変更がタイムリーに反映されません。このパラメータを小さすぎる値に設定すると、PD の負荷が増加します。書き込みトラフィックが大きく変動し、タイムスタンプが頻繁に枯渇し、書き込みレイテンシーが増加する場合は、このパラメータを小さめの値に設定できます。同時に、PD の負荷も考慮する必要があります。 -- デフォルト値: `"100ms"` +- ローカルにキャッシュされたタイムスタンプが更新される間隔。 +- `renew-interval`の間隔で、TiKV はタイムスタンプの更新バッチを開始し、前の期間のタイムスタンプ消費量と[`alloc-ahead-buffer`](#alloc-ahead-buffer-new-in-v640)の設定に応じてキャッシュされたタイムスタンプの数を調整します。このパラメータを大きすぎる値に設定すると、最新の TiKV ワークロードの変更がタイムリーに反映されません。このパラメータを小さすぎる値に設定すると、PD の負荷が増加します。書き込みトラフィックが大きく変動し、タイムスタンプが頻繁に枯渇し、書き込みレイテンシーが増加する場合は、このパラメータを小さめの値に設定できます。同時に、PD の負荷も考慮する必要があります。 +- デフォルト値: `"100ms"` ### `renew-batch-min-size` {#renew-batch-min-size} -- タイムスタンプ要求におけるTSOの最小数。 -- TiKV は、前の期間のタイムスタンプ消費量に応じて、キャッシュされたタイムスタンプの数を調整します。必要な TSO が少ない場合は、TiKV は要求される TSO の数を`renew-batch-min-size`に達するまで減らします。アプリケーションで大量のバースト書き込みトラフィックが頻繁に発生する場合は、このパラメータを適切な値に設定できます。このパラメータは、単一の tikv-server のキャッシュ サイズであることに注意してください。このパラメータを大きすぎる値に設定し、クラスタに多数の tikv-server が含まれている場合、TSO の消費が速すぎることになります。 -- Grafana の**TiKV-RAW** \> **Causal timestamp**パネルでは、 **TSO バッチ サイズ**は、アプリケーションのワークロードに応じて動的に調整されるローカル キャッシュされたタイムスタンプの数です。このメトリックを参照して`renew-batch-min-size`を調整できます。 -- デフォルト値: `100` +- タイムスタンプ要求におけるTSOの最小数。 +- TiKV は、前の期間のタイムスタンプ消費量に応じて、キャッシュされたタイムスタンプの数を調整します。必要な TSO が少ない場合は、TiKV は要求される TSO の数を`renew-batch-min-size`に達するまで減らします。アプリケーションで大量のバースト書き込みトラフィックが頻繁に発生する場合は、このパラメータを適切な値に設定できます。このパラメータは、単一の tikv-server のキャッシュ サイズであることに注意してください。このパラメータを大きすぎる値に設定し、クラスタに多数の tikv-server が含まれている場合、TSO の消費が速すぎることになります。 +- Grafana の**TiKV-RAW** \> **Causal timestamp**パネルでは、 **TSO バッチ サイズ**は、アプリケーションのワークロードに応じて動的に調整されるローカル キャッシュされたタイムスタンプの数です。このメトリックを参照して`renew-batch-min-size`を調整できます。 +- デフォルト値: `100` ### `renew-batch-max-size` v6.4.0で追加 {#renew-batch-max-size-new-in-v640} -- タイムスタンプ要求におけるTSOの最大数。 -- デフォルトのTSO物理時間更新間隔（ `50ms` ）では、PDは最大262144個のTSOを提供します。要求されたTSOがこの数を超えると、PDはそれ以上TSOを提供しません。この設定項目は、TSOの枯渇と、TSO枯渇が他の業務に及ぼす逆効果を回避するために使用されます。高可用性を向上させるためにこの設定項目の値を増やす場合は、十分なTSOを確保するために、同時に[`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval)の値を減らす必要があります。 -- デフォルト値: `8192` +- タイムスタンプ要求におけるTSOの最大数。 +- デフォルトのTSO物理時間更新間隔（ `50ms` ）では、PDは最大262144個のTSOを提供します。要求されたTSOがこの数を超えると、PDはそれ以上TSOを提供しません。この設定項目は、TSOの枯渇と、TSO枯渇が他の業務に及ぼす逆効果を回避するために使用されます。高可用性を向上させるためにこの設定項目の値を増やす場合は、十分なTSOを確保するために、同時に[`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval)の値を減らす必要があります。 +- デフォルト値: `8192` ## resource-metering {#resource-metering} @@ -2742,19 +2742,19 @@ TiKVストレージレイヤーのリソース制御に関連するコンフィ ### `enabled` （v6.6.0で新規追加） {#enabled-new-in-v660} -- 対応するリソース グループの[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)に従って、ユーザーのフォアグラウンド読み取り/書き込みリクエストのスケジューリングを有効にするかどうかを制御します。 TiDB リソース グループとリソース制御の詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md)を参照してください。 -- この設定項目を有効にするには、TiDB で[`tidb_enable_resource_control](/system-variables.md#tidb_enable_resource_control-new-in-v660)が有効になっている必要があります。この設定項目が有効になっている場合、TiKV は優先度キューを使用して、フォアグラウンド ユーザーからのキューに登録された読み取り/書き込みリクエストをスケジュールします。リクエストのスケジュール優先度は、そのリクエストを受け取るリソース グループが既に消費しているリソースの量に反比例し、対応するリソース グループのクォータに比例します。 -- デフォルト値: `true` 。これは、リソースグループのRUに基づいたスケジューリングが有効になっていることを意味します。 +- 対応するリソース グループの[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru)に従って、ユーザーのフォアグラウンド読み取り/書き込みリクエストのスケジューリングを有効にするかどうかを制御します。 TiDB リソース グループとリソース制御の詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します](/tidb-resource-control-ru-groups.md)を参照してください。 +- この設定項目を有効にするには、TiDB で[`tidb_enable_resource_control](/system-variables.md#tidb_enable_resource_control-new-in-v660)が有効になっている必要があります。この設定項目が有効になっている場合、TiKV は優先度キューを使用して、フォアグラウンド ユーザーからのキューに登録された読み取り/書き込みリクエストをスケジュールします。リクエストのスケジュール優先度は、そのリクエストを受け取るリソース グループが既に消費しているリソースの量に反比例し、対応するリソース グループのクォータに比例します。 +- デフォルト値: `true` 。これは、リソースグループのRUに基づいたスケジューリングが有効になっていることを意味します。 ### `priority-ctl-strategy` v8.4.0で追加 {#priority-ctl-strategy-new-in-v840} 優先度の低いタスクに対するフロー制御戦略を指定します。TiKVは、優先度の低いタスクにフロー制御を適用することで、優先度の高いタスクの実行を優先します。 -- 値のオプション： - - `aggressive` : このポリシーは優先度の高いタスクのパフォーマンスを優先し、優先度の高いタスクのスループットとレイテンシーにはほとんど影響を与えないようにしますが、優先度の低いタスクの実行速度は低下します。 - - `moderate` : このポリシーは、優先度の低いタスクに対してバランスの取れたフロー制御を課し、優先度の高いタスクへの影響を少なくします。 - - `conservative` : このポリシーは、システム リソースが最大限に活用されることを優先し、優先度の低いタスクが必要に応じてシステムで利用可能なリソースを最大限に活用できるようにするため、優先度の高いタスクのパフォーマンスに大きな影響を与えます。 -- デフォルト値: `moderate` 。 +- 値のオプション： + - `aggressive` : このポリシーは優先度の高いタスクのパフォーマンスを優先し、優先度の高いタスクのスループットとレイテンシーにはほとんど影響を与えないようにしますが、優先度の低いタスクの実行速度は低下します。 + - `moderate` : このポリシーは、優先度の低いタスクに対してバランスの取れたフロー制御を課し、優先度の高いタスクへの影響を少なくします。 + - `conservative` : このポリシーは、システム リソースが最大限に活用されることを優先し、優先度の低いタスクが必要に応じてシステムで利用可能なリソースを最大限に活用できるようにするため、優先度の高いタスクのパフォーマンスに大きな影響を与えます。 +- デフォルト値: `moderate` 。 ### `bg-cpu-throttle-threshold` New in v8.5.7 {#bg-cpu-throttle-threshold-new-in-v857} @@ -2824,44 +2824,44 @@ TiKVストレージレイヤーのリソース制御に関連するコンフィ ### `byte-threshold` v5.0 で追加 {#byte-threshold-new-in-v50} -- リージョンがホットスポットとして識別されるトラフィックのしきい値を制御します。 -- デフォルト値: +- リージョンがホットスポットとして識別されるトラフィックのしきい値を制御します。 +- デフォルト値: - - [`region-split-size`](#region-split-size) 4 GiB 未満の場合、1 秒あたり`30MiB` 。 - - [`region-split-size`](#region-split-size)が 4 GiB 以上の場合、1 秒あたり`100MiB` 。 + - [`region-split-size`](#region-split-size) 4 GiB 未満の場合、1 秒あたり`30MiB` 。 + - [`region-split-size`](#region-split-size)が 4 GiB 以上の場合、1 秒あたり`100MiB` 。 ### `qps-threshold` {#qps-threshold} -- リージョンがホットスポットとして識別されるQPSしきい値を制御します。 -- デフォルト値: +- リージョンがホットスポットとして識別されるQPSしきい値を制御します。 +- デフォルト値: - - [`region-split-size`](#region-split-size) 4 GiB 未満の場合、 `3000` 。 - - [`region-split-size`](#region-split-size)が 4 GiB 以上の場合`7000` 。 + - [`region-split-size`](#region-split-size) 4 GiB 未満の場合、 `3000` 。 + - [`region-split-size`](#region-split-size)が 4 GiB 以上の場合`7000` 。 ### `region-cpu-overload-threshold-ratio` v6.2.0の新機能 {#region-cpu-overload-threshold-ratio-new-in-v620} -- リージョンがホットスポットとして識別される際のCPU使用率のしきい値を制御します。 -- デフォルト値: +- リージョンがホットスポットとして識別される際のCPU使用率のしきい値を制御します。 +- デフォルト値: - - [`region-split-size`](#region-split-size) 4 GiB 未満の場合、 `0.25` 。 - - [`region-split-size`](#region-split-size)が 4 GiB 以上の場合`0.75` 。 + - [`region-split-size`](#region-split-size) 4 GiB 未満の場合、 `0.25` 。 + - [`region-split-size`](#region-split-size)が 4 GiB 以上の場合`0.75` 。 ## メモリv7.5.0の新機能 {#memory-new-in-v750} ### `enable-heap-profiling` v7.5.0の新機能 {#enable-heap-profiling-new-in-v750} -- TiKVのメモリ使用量を追跡するためにヒーププロファイリングを有効にするかどうかを制御します。 -- デフォルト値: `true` +- TiKVのメモリ使用量を追跡するためにヒーププロファイリングを有効にするかどうかを制御します。 +- デフォルト値: `true` ### `profiling-sample-per-bytes` （v7.5.0の新機能） {#profiling-sample-per-bytes-new-in-v750} -- ヒーププロファイリングによって毎回サンプリングされるデータ量を指定します。値は2のべき乗に切り上げられます。 -- デフォルト値: `512KiB` +- ヒーププロファイリングによって毎回サンプリングされるデータ量を指定します。値は2のべき乗に切り上げられます。 +- デフォルト値: `512KiB` ### `enable-thread-exclusive-arena` v8.1.0の新機能 {#enable-thread-exclusive-arena-new-in-v810} -- TiKVスレッドレベルでメモリ割り当て状況を表示して、各TiKVスレッドのメモリ使用量を追跡するかどうかを制御します。 -- デフォルト値: `true` +- TiKVスレッドレベルでメモリ割り当て状況を表示して、各TiKVスレッドのメモリ使用量を追跡するかどうかを制御します。 +- デフォルト値: `true` ## インメモリエンジンv8.5.0の新機能 {#in-memory-engine-new-in-v850} @@ -2873,27 +2873,27 @@ TiKV MVCC インメモリエンジン (IME) のストレージレイヤーに関 > > この設定項目は設定ファイルで設定できますが、SQL文で照会することはできません。 -- インメモリ エンジンを有効にしてマルチバージョン クエリを高速化するかどうか。インメモリ エンジンの詳細については、 [TiKV MVCC インメモリエンジン](/tikv-in-memory-engine.md)を参照してください。 -- デフォルト値: `false` (インメモリエンジンは無効になっています) -- TiKVノードには最低でも8GiBのメモリを搭載することを推奨します。最適なパフォーマンスを得るには、32GiB以上を搭載することをお勧めします。 -- TiKVノードで使用可能なメモリが不足している場合、この設定項目が`true`に設定されていても、インメモリエンジンは有効になりません。このような場合は、TiKVログファイルで`"in-memory engine is disabled because"`を含むメッセージを確認し、インメモリエンジンが有効にならない理由を調べてください。 +- インメモリ エンジンを有効にしてマルチバージョン クエリを高速化するかどうか。インメモリ エンジンの詳細については、 [TiKV MVCC インメモリエンジン](/tikv-in-memory-engine.md)を参照してください。 +- デフォルト値: `false` (インメモリエンジンは無効になっています) +- TiKVノードには最低でも8GiBのメモリを搭載することを推奨します。最適なパフォーマンスを得るには、32GiB以上を搭載することをお勧めします。 +- TiKVノードで使用可能なメモリが不足している場合、この設定項目が`true`に設定されていても、インメモリエンジンは有効になりません。このような場合は、TiKVログファイルで`"in-memory engine is disabled because"`を含むメッセージを確認し、インメモリエンジンが有効にならない理由を調べてください。 ### `capacity` v8.5.0の新機能 {#capacity-new-in-v850} > **Note:** > -> - インメモリエンジンが有効になると、 `block-cache.capacity`は自動的に 10% 減少します。 -> - `capacity`を手動で設定した場合、 `block-cache.capacity`は自動的に減少しません。この場合、メモリ不足エラー（OOM）を回避するために、その値を手動で調整する必要があります。 +> - インメモリエンジンが有効になると、 `block-cache.capacity`は自動的に 10% 減少します。 +> - `capacity`を手動で設定した場合、 `block-cache.capacity`は自動的に減少しません。この場合、メモリ不足エラー（OOM）を回避するために、その値を手動で調整する必要があります。 -- [TiKV MVCC インメモリエンジン](/tikv-in-memory-engine.md)が使用できる最大メモリサイズを制御します。メモリ容量によって、キャッシュできるリージョンの数が決まります。容量がいっぱいになると、インメモリエンジンはリージョンMVCCの冗長性に基づいて新しいリージョンをロードし、キャッシュされたリージョンを削除します。 -- デフォルト値: `min(10% of the total system memory, 5 GiB)` +- [TiKV MVCC インメモリエンジン](/tikv-in-memory-engine.md)が使用できる最大メモリサイズを制御します。メモリ容量によって、キャッシュできるリージョンの数が決まります。容量がいっぱいになると、インメモリエンジンはリージョンMVCCの冗長性に基づいて新しいリージョンをロードし、キャッシュされたリージョンを削除します。 +- デフォルト値: `min(10% of the total system memory, 5 GiB)` ### `gc-run-interval` v8.5.0で追加 {#gc-run-interval-new-in-v850} -- インメモリエンジンGCがMVCCバージョンをキャッシュする時間間隔を制御します。このパラメータを小さくするとGCの頻度が上がり、MVCCバージョンの数を減らすことができますが、GCのCPU使用率が増加し、インメモリエンジンのキャッシュミスが発生する確率が高くなります。 -- デフォルト値: `"3m"` +- インメモリエンジンGCがMVCCバージョンをキャッシュする時間間隔を制御します。このパラメータを小さくするとGCの頻度が上がり、MVCCバージョンの数を減らすことができますが、GCのCPU使用率が増加し、インメモリエンジンのキャッシュミスが発生する確率が高くなります。 +- デフォルト値: `"3m"` ### `mvcc-amplification-threshold` v8.5.0で追加 {#mvcc-amplification-threshold-new-in-v850} -- インメモリエンジンがリージョンを選択してロードする際の、MVCC読み取り増幅のしきい値を制御します。デフォルト値は`10`で、リージョン内の1行を読み取るのに10を超えるMVCCバージョンを処理する必要がある場合は、そのリージョンがインメモリエンジンにロードされる可能性があることを示します。 -- デフォルト値: `10` +- インメモリエンジンがリージョンを選択してロードする際の、MVCC読み取り増幅のしきい値を制御します。デフォルト値は`10`で、リージョン内の1行を読み取るのに10を超えるMVCCバージョンを処理する必要がある場合は、そのリージョンがインメモリエンジンにロードされる可能性があることを示します。 +- デフォルト値: `10` diff --git a/tikv-control.md b/tikv-control.md index a4d799da6fb61..19c43a408c76e 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -7,7 +7,7 @@ summary: TiKV Controlを使用して TiKV クラスターを管理します。 TiKV Control ( `tikv-ctl` ) は、クラスターの管理に使用される TiKV のコマンドラインツールです。インストールディレクトリは次のとおりです。 -- クラスターがTiUPを使用してデプロイされている場合、 `tikv-ctl`ディレクトリは`~/.tiup/components/ctl/{VERSION}/`ディレクトリ内にあります。 +- クラスターがTiUPを使用してデプロイされている場合、 `tikv-ctl`ディレクトリは`~/.tiup/components/ctl/{VERSION}/`ディレクトリ内にあります。 ## TiUPでTiKV Controlを使用する {#use-tikv-control-in-tiup} @@ -21,65 +21,67 @@ TiKV Control ( `tikv-ctl` ) は、クラスターの管理に使用される TiK tiup ctl:v tikv ``` - Starting component `ctl`: /home/tidb/.tiup/components/ctl/v4.0.8/ctl tikv - TiKV Control (tikv-ctl) - Release Version: 4.0.8 - Edition: Community - Git Commit Hash: 83091173e960e5a0f5f417e921a0801d2f6635ae - Git Commit Branch: heads/refs/tags/v4.0.8 - UTC Build Time: 2020-10-30 08:40:33 - Rust Version: rustc 1.42.0-nightly (0de96d37f 2019-12-19) - Enable Features: jemalloc mem-profiling portable sse protobuf-codec - Profile: dist_release - - A tool for interacting with TiKV deployments. - USAGE: - TiKV Control (tikv-ctl) [FLAGS] [OPTIONS] [SUBCOMMAND] - FLAGS: - -h, --help Prints help information - --skip-paranoid-checks Skip paranoid checks when open rocksdb - -V, --version Prints version information - OPTIONS: - --ca-path Set the CA certificate path - --cert-path Set the certificate path - --config TiKV config path, by default it's /conf/tikv.toml - --data-dir TiKV data directory path, check /scripts/run.sh to get it - --decode Decode a key in escaped format - --encode Encode a key in escaped format - --to-hex Convert an escaped key to hex key - --to-escaped Convert a hex key to escaped key - --host Set the remote host - --key-path Set the private key path - --log-level Set the log level [default: warn] - --pd Set the address of pd - SUBCOMMANDS: - bad-regions Get all regions with corrupt raft - cluster Print the cluster id - compact Compact a column family in a specified range - compact-cluster Compact the whole cluster in a specified range in one or more column families - consistency-check Force a consistency-check for a specified region - decrypt-file Decrypt an encrypted file - diff Calculate difference of region keys from different dbs - dump-snap-meta Dump snapshot meta file - encryption-meta Dump encryption metadata - fail Inject failures to TiKV and recovery - help Prints this message or the help of the given subcommand(s) - metrics Print the metrics - modify-tikv-config Modify tikv config, eg. tikv-ctl --host ip:port modify-tikv-config -n - rocksdb.defaultcf.disable-auto-compactions -v true - mvcc Print the mvcc value - print Print the raw value - raft Print a raft log entry - raw-scan Print all raw keys in the range - recover-mvcc Recover mvcc data on one node by deleting corrupted keys - recreate-region Recreate a region with given metadata, but alloc new id for it - region-properties Show region properties - scan Print the range db range - size Print region size - split-region Split the region - store Print the store id - tombstone Set some regions on the node to tombstone by manual - unsafe-recover Unsafely recover the cluster when the majority replicas are failed +``` +Starting component `ctl`: /home/tidb/.tiup/components/ctl/v4.0.8/ctl tikv +TiKV Control (tikv-ctl) +Release Version: 4.0.8 +Edition: Community +Git Commit Hash: 83091173e960e5a0f5f417e921a0801d2f6635ae +Git Commit Branch: heads/refs/tags/v4.0.8 +UTC Build Time: 2020-10-30 08:40:33 +Rust Version: rustc 1.42.0-nightly (0de96d37f 2019-12-19) +Enable Features: jemalloc mem-profiling portable sse protobuf-codec +Profile: dist_release + +A tool for interacting with TiKV deployments. +USAGE: + TiKV Control (tikv-ctl) [FLAGS] [OPTIONS] [SUBCOMMAND] +FLAGS: + -h, --help Prints help information + --skip-paranoid-checks Skip paranoid checks when open rocksdb + -V, --version Prints version information +OPTIONS: + --ca-path Set the CA certificate path + --cert-path Set the certificate path + --config TiKV config path, by default it's /conf/tikv.toml + --data-dir TiKV data directory path, check /scripts/run.sh to get it + --decode Decode a key in escaped format + --encode Encode a key in escaped format + --to-hex Convert an escaped key to hex key + --to-escaped Convert a hex key to escaped key + --host Set the remote host + --key-path Set the private key path + --log-level Set the log level [default: warn] + --pd Set the address of pd +SUBCOMMANDS: + bad-regions Get all regions with corrupt raft + cluster Print the cluster id + compact Compact a column family in a specified range + compact-cluster Compact the whole cluster in a specified range in one or more column families + consistency-check Force a consistency-check for a specified region + decrypt-file Decrypt an encrypted file + diff Calculate difference of region keys from different dbs + dump-snap-meta Dump snapshot meta file + encryption-meta Dump encryption metadata + fail Inject failures to TiKV and recovery + help Prints this message or the help of the given subcommand(s) + metrics Print the metrics + modify-tikv-config Modify tikv config, eg. tikv-ctl --host ip:port modify-tikv-config -n + rocksdb.defaultcf.disable-auto-compactions -v true + mvcc Print the mvcc value + print Print the raw value + raft Print a raft log entry + raw-scan Print all raw keys in the range + recover-mvcc Recover mvcc data on one node by deleting corrupted keys + recreate-region Recreate a region with given metadata, but alloc new id for it + region-properties Show region properties + scan Print the range db range + size Print region size + split-region Split the region + store Print the store id + tombstone Set some regions on the node to tombstone by manual + unsafe-recover Unsafely recover the cluster when the majority replicas are failed +``` `tiup ctl:v tikv`の後に対応するパラメータとサブコマンドを追加できます。 @@ -87,7 +89,7 @@ tiup ctl:v tikv `tikv-ctl`には 2 つの動作モードがあります。 -- リモートモード: `--host`オプションを使用して、TiKVのサービスアドレスを引数として受け入れます +- リモートモード: `--host`オプションを使用して、TiKVのサービスアドレスを引数として受け入れます このモードでは、TiKVでSSLが有効になっている場合、`tikv-ctl`は関連する証明書ファイルも指定する必要があります。例： @@ -101,12 +103,14 @@ tiup ctl:v tikv tikv-ctl --pd 127.0.0.1:2379 compact-cluster ``` - store:"127.0.0.1:20160" compact db:KV cf:default range:([], []) success! + ``` + store:"127.0.0.1:20160" compact db:KV cf:default range:([], []) success! + ``` -- ローカルモード: +- ローカルモード: - - ローカル TiKV データ ディレクトリ パスを指定するには、 `--data-dir`オプションを使用します。 - - ローカル TiKV 構成ファイル パスを指定するには、 `--config`オプションを使用します。 + - ローカル TiKV データ ディレクトリ パスを指定するには、 `--data-dir`オプションを使用します。 + - ローカル TiKV 構成ファイル パスを指定するには、 `--config`オプションを使用します。 このモードでは、実行中の TiKV インスタンスを停止する必要があります。 @@ -139,9 +143,9 @@ AAFF `region`サブコマンドの場合: -- 表示するリージョンを指定するには、 `-r`オプションを使用してください。複数のリージョンを指定する場合は、 `,`で区切ります。また、 `--all-regions`オプションを使用してすべてのリージョンを表示することもできます。`-r`と`--all-regions`は同時に使用できないことに注意してください。 -- 印刷するリージョンの数を制限するには、 `--limit`オプションを使用します (デフォルト: `16` )。 -- 特定のキー範囲に含まれるリージョンを照会するには、 `--start`および`--end`オプションを使用します (デフォルト: 範囲制限なし、16 進形式)。 +- 表示するリージョンを指定するには、 `-r`オプションを使用してください。複数のリージョンを指定する場合は、 `,`で区切ります。また、 `--all-regions`オプションを使用してすべてのリージョンを表示することもできます。`-r`と`--all-regions`は同時に使用できないことに注意してください。 +- 印刷するリージョンの数を制限するには、 `--limit`オプションを使用します (デフォルト: `16` )。 +- 特定のキー範囲に含まれるリージョンを照会するには、 `--start`および`--end`オプションを使用します (デフォルト: 範囲制限なし、16 進形式)。 たとえば、ID `1239`のリージョンを印刷するには、次のコマンドを使用します。 @@ -151,27 +155,29 @@ tikv-ctl --host 127.0.0.1:20160 raft region -r 1239 出力は次のようになります。 - "region id": 1239 - "region state": { - id: 1239, - start_key: 7480000000000000FF4E5F728000000000FF1443770000000000FA, - end_key: 7480000000000000FF4E5F728000000000FF21C4420000000000FA, - region_epoch: {conf_ver: 1 version: 43}, - peers: [ {id: 1240 store_id: 1 role: Voter} ] - } - "raft state": { - hard_state {term: 8 vote: 5 commit: 7} - last_index: 8) - } - "apply state": { - applied_index: 8 commit_index: 8 commit_term: 8 - truncated_state {index: 5 term: 5} - } +``` +"region id": 1239 +"region state": { + id: 1239, + start_key: 7480000000000000FF4E5F728000000000FF1443770000000000FA, + end_key: 7480000000000000FF4E5F728000000000FF21C4420000000000FA, + region_epoch: {conf_ver: 1 version: 43}, + peers: [ {id: 1240 store_id: 1 role: Voter} ] +} +"raft state": { + hard_state {term: 8 vote: 5 commit: 7} + last_index: 8) +} +"apply state": { + applied_index: 8 commit_index: 8 commit_term: 8 + truncated_state {index: 5 term: 5} +} +``` 特定のキー範囲に含まれるリージョンを照会するには、次のコマンドを使用します。 -- キー範囲がリージョン範囲内にある場合は、リージョン情報が出力されます。 -- キー範囲がリージョン範囲と同じ場合、たとえば、指定されたキー範囲がリージョン`1239`と同じ場合、リージョン範囲は左閉じ右開きの間隔であり、リージョン`1009`リージョン`1239`の`end_key` `start_key`として取るため、リージョン`1009`情報も出力されます。 +- キー範囲がリージョン範囲内にある場合は、リージョン情報が出力されます。 +- キー範囲がリージョン範囲と同じ場合、たとえば、指定されたキー範囲がリージョン`1239`と同じ場合、リージョン範囲は左閉じ右開きの間隔であり、リージョン`1009`リージョン`1239`の`end_key` `start_key`として取るため、リージョン`1009`情報も出力されます。 ```shell tikv-ctl --host 127.0.0.1:20160 raft region --start 7480000000000000FF4E5F728000000000FF1443770000000000FA --end 7480000000000000FF4E5F728000000000FF21C4420000000000FA @@ -179,18 +185,20 @@ tikv-ctl --host 127.0.0.1:20160 raft region --start 7480000000000000FF4E5F728000 出力は次のようになります。 - "region state": { - id: 1009 - start_key: 7480000000000000FF4E5F728000000000FF21C4420000000000FA, - end_key: 7480000000000000FF5000000000000000F8, - ... - } - "region state": { - id: 1239 - start_key: 7480000000000000FF4E5F728000000000FF06C6D60000000000FA, - end_key: 7480000000000000FF4E5F728000000000FF1443770000000000FA, - ... - } +``` +"region state": { + id: 1009 + start_key: 7480000000000000FF4E5F728000000000FF21C4420000000000FA, + end_key: 7480000000000000FF5000000000000000F8, + ... +} +"region state": { + id: 1239 + start_key: 7480000000000000FF4E5F728000000000FF06C6D60000000000FA, + end_key: 7480000000000000FF4E5F728000000000FF1443770000000000FA, + ... +} +``` ### リージョンサイズを表示する {#view-the-region-size} @@ -202,10 +210,12 @@ tikv-ctl --data-dir /path/to/tikv size -r 2 出力は次のようになります。 - region id: 2 - cf default region size: 799.703 MB - cf write region size: 41.250 MB - cf lock region size: 27616 +``` +region id: 2 +cf default region size: 799.703 MB +cf write region size: 41.250 MB +cf lock region size: 27616 +``` ### スキャンして特定の範囲のMVCCを表示する {#scan-to-view-mvcc-of-a-specific-range} @@ -215,11 +225,13 @@ tikv-ctl --data-dir /path/to/tikv size -r 2 tikv-ctl --data-dir /path/to/tikv scan --from 'zm' --limit 2 --show-cf lock,default,write ``` - key: zmBootstr\377a\377pKey\000\000\377\000\000\373\000\000\000\000\000\377\000\000s\000\000\000\000\000\372 - write cf value: start_ts: 399650102814441473 commit_ts: 399650102814441475 short_value: "20" - key: zmDB:29\000\000\377\000\374\000\000\000\000\000\000\377\000H\000\000\000\000\000\000\371 - write cf value: start_ts: 399650105239273474 commit_ts: 399650105239273475 short_value: "\000\000\000\000\000\000\000\002" - write cf value: start_ts: 399650105199951882 commit_ts: 399650105213059076 short_value: "\000\000\000\000\000\000\000\001" +``` +key: zmBootstr\377a\377pKey\000\000\377\000\000\373\000\000\000\000\000\377\000\000s\000\000\000\000\000\372 + write cf value: start_ts: 399650102814441473 commit_ts: 399650102814441475 short_value: "20" +key: zmDB:29\000\000\377\000\374\000\000\000\000\000\000\377\000H\000\000\000\000\000\000\371 + write cf value: start_ts: 399650105239273474 commit_ts: 399650105239273475 short_value: "\000\000\000\000\000\000\000\002" + write cf value: start_ts: 399650105199951882 commit_ts: 399650105213059076 short_value: "\000\000\000\000\000\000\000\001" +``` ### 指定されたキーのMVCCを表示する {#view-mvcc-of-a-given-key} @@ -229,9 +241,11 @@ tikv-ctl --data-dir /path/to/tikv scan --from 'zm' --limit 2 --show-cf lock,defa tikv-ctl --data-dir /path/to/tikv mvcc -k "zmDB:29\000\000\377\000\374\000\000\000\000\000\000\377\000H\000\000\000\000\000\000\371" --show-cf=lock,write,default ``` - key: zmDB:29\000\000\377\000\374\000\000\000\000\000\000\377\000H\000\000\000\000\000\000\371 - write cf value: start_ts: 399650105239273474 commit_ts: 399650105239273475 short_value: "\000\000\000\000\000\000\000\002" - write cf value: start_ts: 399650105199951882 commit_ts: 399650105213059076 short_value: "\000\000\000\000\000\000\000\001" +``` +key: zmDB:29\000\000\377\000\374\000\000\000\000\000\000\377\000H\000\000\000\000\000\000\371 + write cf value: start_ts: 399650105239273474 commit_ts: 399650105239273475 short_value: "\000\000\000\000\000\000\000\002" + write cf value: start_ts: 399650105199951882 commit_ts: 399650105213059076 short_value: "\000\000\000\000\000\000\000\001" +``` このコマンドでは、キーは生のキーのエスケープされた形式でもあります。 @@ -245,10 +259,12 @@ tikv-ctl --data-dir /path/to/tikv mvcc -k "zmDB:29\000\000\377\000\374\000\000\0 tikv-ctl --data-dir /var/lib/tikv raw-scan --from 'zt' --limit 2 --cf default ``` - key: "zt\200\000\000\000\000\000\000\377\005_r\200\000\000\000\000\377\000\000\001\000\000\000\000\000\372\372b2,^\033\377\364", value: "\010\002\002\002%\010\004\002\010root\010\006\002\000\010\010\t\002\010\n\t\002\010\014\t\002\010\016\t\002\010\020\t\002\010\022\t\002\010\024\t\002\010\026\t\002\010\030\t\002\010\032\t\002\010\034\t\002\010\036\t\002\010 \t\002\010\"\t\002\010s\t\002\010&\t\002\010(\t\002\010*\t\002\010,\t\002\010.\t\002\0100\t\002\0102\t\002\0104\t\002" - key: "zt\200\000\000\000\000\000\000\377\025_r\200\000\000\000\000\377\000\000\023\000\000\000\000\000\372\372b2,^\033\377\364", value: "\010\002\002&slow_query_log_file\010\004\002P/usr/local/mysql/data/localhost-slow.log" +``` +key: "zt\200\000\000\000\000\000\000\377\005_r\200\000\000\000\000\377\000\000\001\000\000\000\000\000\372\372b2,^\033\377\364", value: "\010\002\002\002%\010\004\002\010root\010\006\002\000\010\010\t\002\010\n\t\002\010\014\t\002\010\016\t\002\010\020\t\002\010\022\t\002\010\024\t\002\010\026\t\002\010\030\t\002\010\032\t\002\010\034\t\002\010\036\t\002\010 \t\002\010\"\t\002\010s\t\002\010&\t\002\010(\t\002\010*\t\002\010,\t\002\010.\t\002\0100\t\002\0102\t\002\0104\t\002" +key: "zt\200\000\000\000\000\000\000\377\025_r\200\000\000\000\000\377\000\000\023\000\000\000\000\000\372\372b2,^\033\377\364", value: "\010\002\002&slow_query_log_file\010\004\002P/usr/local/mysql/data/localhost-slow.log" - Total scanned keys: 2 +Total scanned keys: 2 +``` ### 特定のキー値を印刷する {#print-a-specific-key-value} @@ -262,16 +278,18 @@ tikv-ctl --data-dir /var/lib/tikv raw-scan --from 'zt' --limit 2 --cf default tikv-ctl --host localhost:20160 region-properties -r 2 ``` - num_files: 0 - num_entries: 0 - num_deletes: 0 - mvcc.min_ts: 18446744073709551615 - mvcc.max_ts: 0 - mvcc.num_rows: 0 - mvcc.num_puts: 0 - mvcc.num_versions: 0 - mvcc.max_row_versions: 0 - middle_key_by_approximate_size: +``` +num_files: 0 +num_entries: 0 +num_deletes: 0 +mvcc.min_ts: 18446744073709551615 +mvcc.max_ts: 0 +mvcc.num_rows: 0 +mvcc.num_puts: 0 +mvcc.num_versions: 0 +mvcc.max_row_versions: 0 +middle_key_by_approximate_size: +``` これらのプロパティは、 リージョンが正常かどうかをチェックするために使用できます。正常でない場合は、これらのプロパティを使用してリージョン を修正できます。例えば、 リージョン を手動で`middle_key_approximate_size`ずつ分割するなどです。 @@ -279,28 +297,28 @@ tikv-ctl --host localhost:20160 region-properties -r 2 `compact`コマンドを使用して、各 TiKV のデータを手動で圧縮します。 -- `--from`と`--to`オプションを使用して、エスケープされた生のキーの形式で圧縮範囲を指定します。指定しない場合は、範囲全体が圧縮されます。 +- `--from`と`--to`オプションを使用して、エスケープされた生のキーの形式で圧縮範囲を指定します。指定しない場合は、範囲全体が圧縮されます。 -- 特定のリージョンの範囲を圧縮するには、オプション`--region`を使用します。設定されている場合、 `--from`と`--to`無視されます。 +- 特定のリージョンの範囲を圧縮するには、オプション`--region`を使用します。設定されている場合、 `--from`と`--to`無視されます。 -- カラムファミリー名を指定するには、 `-c`オプションを使用します。デフォルト値は`default`です。オプションの値は`default` 、 `lock` 、 `write`です。 +- カラムファミリー名を指定するには、 `-c`オプションを使用します。デフォルト値は`default`です。オプションの値は`default` 、 `lock` 、 `write`です。 -- 圧縮を実行するRocksDBを指定するには、 `-d`オプションを使用します。デフォルト値は`kv`です。オプション値は`kv`と`raft`です。 +- 圧縮を実行するRocksDBを指定するには、 `-d`オプションを使用します。デフォルト値は`kv`です。オプション値は`kv`と`raft`です。 -- `--threads`オプションを使用すると、TiKV 圧縮の同時実行数を指定できます。デフォルト値は`8`です。一般的に、同時実行数が多いほど圧縮速度は速くなりますが、サービスに影響を与える可能性があります。シナリオに応じて適切な同時実行数を選択する必要があります。 +- `--threads`オプションを使用すると、TiKV 圧縮の同時実行数を指定できます。デフォルト値は`8`です。一般的に、同時実行数が多いほど圧縮速度は速くなりますが、サービスに影響を与える可能性があります。シナリオに応じて適切な同時実行数を選択する必要があります。 -- `--bottommost`オプションを使用すると、TiKV が圧縮を実行する際に最下位のファイルを含めるか除外するかを指定できます。値のオプションは`default` 、 `skip` 、 `force`です。デフォルト値は`default`です。 - - `default` 、圧縮フィルター機能が有効な場合にのみ最下位のファイルが含まれることを意味します。 - - `skip` 、TiKV が圧縮を実行するときに最下部のファイルが除外されることを意味します。 - - `force` 、TiKV が圧縮を実行するときに、最下層のファイルが常に含まれることを意味します。 +- `--bottommost`オプションを使用すると、TiKV が圧縮を実行する際に最下位のファイルを含めるか除外するかを指定できます。値のオプションは`default` 、 `skip` 、 `force`です。デフォルト値は`default`です。 + - `default` 、圧縮フィルター機能が有効な場合にのみ最下位のファイルが含まれることを意味します。 + - `skip` 、TiKV が圧縮を実行するときに最下部のファイルが除外されることを意味します。 + - `force` 、TiKV が圧縮を実行するときに、最下層のファイルが常に含まれることを意味します。 -- ローカル モードでデータを圧縮するには、次のコマンドを使用します。 +- ローカル モードでデータを圧縮するには、次のコマンドを使用します。 ```shell tikv-ctl --data-dir /path/to/tikv compact -d kv ``` -- リモート モードでデータを圧縮するには、次のコマンドを使用します。 +- リモート モードでデータを圧縮するには、次のコマンドを使用します。 ```shell tikv-ctl --host ip:port compact -d kv @@ -310,8 +328,8 @@ tikv-ctl --host localhost:20160 region-properties -r 2 `compact-cluster`コマンドを使用して、TiKV クラスタ全体のデータを手動で圧縮します。このコマンドのフラグは、 `compact`コマンドと同じ意味と使用法を持ちます。唯一の違いは次のとおりです。 -- `compact-cluster`コマンドでは、 `--pd`を使用して PD のアドレスを指定し、 `tikv-ctl`クラスター内のすべての TiKV ノードをコンパクト ターゲットとして見つけられるようにします。 -- `compact`コマンドでは、 `--data-dir`または`--host`を使用して、単一の TiKV をコンパクト ターゲットとして指定します。 +- `compact-cluster`コマンドでは、 `--pd`を使用して PD のアドレスを指定し、 `tikv-ctl`クラスター内のすべての TiKV ノードをコンパクト ターゲットとして見つけられるようにします。 +- `compact`コマンドでは、 `--data-dir`または`--host`を使用して、単一の TiKV をコンパクト ターゲットとして指定します。 ### リージョンをtombstoneに設定する {#set-a-region-to-tombstone} @@ -331,7 +349,9 @@ pd-ctl operator add remove-peer tikv-ctl --data-dir /path/to/tikv tombstone -p 127.0.0.1:2379 -r ``` - success! +``` +success! +``` ただし、場合によっては、このリージョンのこのピアを PD から簡単に削除できないため、 `tikv-ctl`の`--force`のオプションを指定して、ピアを強制的にtombstoneに設定することができます。 @@ -339,12 +359,14 @@ tikv-ctl --data-dir /path/to/tikv tombstone -p 127.0.0.1:2379 -r tikv-ctl --data-dir /path/to/tikv tombstone -p 127.0.0.1:2379 -r , --force ``` - success! +``` +success! +``` > **Note:** > -> - `tombstone`コマンドはローカル モードのみをサポートします。 -> - `-p`オプションの引数は、 `http`プレフィックスのない PD エンドポイントを指定します。PD エンドポイントを指定するのは、PD が安全に Tombstone に切り替えられるかどうかを照会するためです。 +> - `tombstone`コマンドはローカル モードのみをサポートします。 +> - `-p`オプションの引数は、 `http`プレフィックスのない PD エンドポイントを指定します。PD エンドポイントを指定するのは、PD が安全に Tombstone に切り替えられるかどうかを照会するためです。 ### TiKVに`consistency-check`リクエストを送信する {#send-a-consistency-check-request-to-tikv} @@ -359,9 +381,9 @@ DebugClient::check_region_consistency: RpcFailure(RpcStatus { status: Unknown, d > **Note:** > -> - `consistency-check`コマンドは TiDB のガベージコレクションと互換性がなく、誤ってエラーを報告する可能性があるため、使用はお勧めし**ません**。 -> - このコマンドはリモート モードのみをサポートします。 -> - このコマンドが`success!`を返した場合でも、TiKVがパニック状態になるかどうかを確認する必要があります。これは、このコマンドがリーダーの整合性チェックを要求するプロポーザルに過ぎず、チェックプロセス全体が成功したかどうかをクライアント側から知ることができないためです。 +> - `consistency-check`コマンドは TiDB のガベージコレクションと互換性がなく、誤ってエラーを報告する可能性があるため、使用はお勧めし**ません**。 +> - このコマンドはリモート モードのみをサポートします。 +> - このコマンドが`success!`を返した場合でも、TiKVがパニック状態になるかどうかを確認する必要があります。これは、このコマンドがリーダーの整合性チェックを要求するプロポーザルに過ぎず、チェックプロセス全体が成功したかどうかをクライアント側から知ることができないためです。 ### スナップショットのメタをダンプ {#dump-snapshot-meta} @@ -375,19 +397,21 @@ TiKVの起動中にリージョンのチェックを回避するには、 `tombs tikv-ctl --data-dir /path/to/tikv bad-regions ``` - all regions are healthy +``` +all regions are healthy +``` コマンドが正常に実行された場合、上記の情報が出力されます。コマンドが失敗した場合、不良リージョンのリストが出力されます。現在検出可能なエラーには、 `last index` `commit index`不一致と、 Raftログの消失が含まれます。スナップショットファイルの破損など、その他`apply index`条件については、さらなるサポートが必要です。 ### リージョンのプロパティを表示する {#view-region-properties} -- `/path/to/tikv`にデプロイされている TiKV インスタンスのリージョン2 のプロパティをローカルで表示するには、次の手順を実行します。 +- `/path/to/tikv`にデプロイされている TiKV インスタンスのリージョン2 のプロパティをローカルで表示するには、次の手順を実行します。 ```shell tikv-ctl --data-dir /path/to/tikv/data region-properties -r 2 ``` -- `127.0.0.1:20160`で実行されている TiKV インスタンスのリージョン2 のプロパティをオンラインで表示するには: +- `127.0.0.1:20160`で実行されている TiKV インスタンスのリージョン2 のプロパティをオンラインで表示するには: ```shell tikv-ctl --host 127.0.0.1:20160 region-properties -r 2 @@ -397,8 +421,8 @@ tikv-ctl --data-dir /path/to/tikv bad-regions `modify-tikv-config`コマンドを使用して、設定引数を動的に変更できます。現在、動的に変更可能な TiKV 設定項目と詳細な変更は、SQL 文を使用した設定変更と一貫性があります。詳細については、 [TiKV 構成を動的に変更する](/dynamic-config.md#modify-tikv-configuration-dynamically)を参照してください。 -- `-n`設定項目の完全な名前を指定するために使用されます。動的に変更可能な設定項目のリストについては、 [TiKV 構成を動的に変更する](/dynamic-config.md#modify-tikv-configuration-dynamically)を参照してください。 -- `-v`構成値を指定するために使用されます。 +- `-n`設定項目の完全な名前を指定するために使用されます。動的に変更可能な設定項目のリストについては、 [TiKV 構成を動的に変更する](/dynamic-config.md#modify-tikv-configuration-dynamically)を参照してください。 +- `-v`構成値を指定するために使用されます。 `shared block cache`のサイズを設定します: @@ -406,7 +430,9 @@ tikv-ctl --data-dir /path/to/tikv bad-regions tikv-ctl --host ip:port modify-tikv-config -n storage.block-cache.capacity -v 10GB ``` - success +``` +success +``` `shared block cache`が無効の場合は、 `write` CF に`block cache size`設定します。 @@ -414,13 +440,17 @@ tikv-ctl --host ip:port modify-tikv-config -n storage.block-cache.capacity -v 10 tikv-ctl --host ip:port modify-tikv-config -n rocksdb.writecf.block-cache-size -v 256MB ``` - success +``` +success +``` ```shell tikv-ctl --host ip:port modify-tikv-config -n raftdb.defaultcf.disable-auto-compactions -v true ``` - success +``` +success +``` 圧縮レート制限によって圧縮保留バイトが蓄積される場合は、 `rate-limiter-auto-tuned`モードを無効にするか、圧縮フローの制限を高く設定します。 @@ -428,13 +458,17 @@ tikv-ctl --host ip:port modify-tikv-config -n raftdb.defaultcf.disable-auto-comp tikv-ctl --host ip:port modify-tikv-config -n rocksdb.rate-limiter-auto-tuned -v false ``` - success +``` +success +``` ```shell tikv-ctl --host ip:port modify-tikv-config -n rocksdb.rate-bytes-per-sec -v "1GB" ``` - success +``` +success +``` ### 複数のレプリカの障害からリージョンにサービスを強制的に回復させる（非推奨） {#force-regions-to-recover-services-from-failure-of-multiple-replicas-deprecated} @@ -448,15 +482,17 @@ tikv-ctl --host ip:port modify-tikv-config -n rocksdb.rate-bytes-per-sec -v "1GB > **Warning:** > -> - 誤った操作が行われた場合、クラスターの復旧が困難になる可能性があります。潜在的なリスクを認識し、本番環境ではこの機能の使用を避けてください。 -> - `--all-regions`オプションを使用する場合、このコマンドはクラスタに接続されている残りのすべてのストアに対して実行する必要があります。損傷したストアを復旧する前に、これらの正常なストアがサービスの提供を停止していることを確認する必要があります。そうしないと、リージョンレプリカ内のピアリストの不整合により、 `split-region`または`remove-peer`を実行した際にエラーが発生します。これにより、他のメタデータ間の不整合も発生し、最終的にはリージョンが利用できなくなります。 -> - `remove-fail-stores`を実行した後は、削除したノードを再起動したり、クラスターに追加したりすることはできません。そうしないと、メタデータに不整合が生じ、最終的にはリージョンが利用できなくなります。 +> - 誤った操作が行われた場合、クラスターの復旧が困難になる可能性があります。潜在的なリスクを認識し、本番環境ではこの機能の使用を避けてください。 +> - `--all-regions`オプションを使用する場合、このコマンドはクラスタに接続されている残りのすべてのストアに対して実行する必要があります。損傷したストアを復旧する前に、これらの正常なストアがサービスの提供を停止していることを確認する必要があります。そうしないと、リージョンレプリカ内のピアリストの不整合により、 `split-region`または`remove-peer`を実行した際にエラーが発生します。これにより、他のメタデータ間の不整合も発生し、最終的にはリージョンが利用できなくなります。 +> - `remove-fail-stores`を実行した後は、削除したノードを再起動したり、クラスターに追加したりすることはできません。そうしないと、メタデータに不整合が生じ、最終的にはリージョンが利用できなくなります。 ```shell tikv-ctl --data-dir /path/to/tikv unsafe-recover remove-fail-stores -s 3 -r 1001,1002 ``` - success! +``` +success! +``` ```shell tikv-ctl --data-dir /path/to/tikv unsafe-recover remove-fail-stores -s 4,5 --all-regions @@ -466,15 +502,15 @@ TiKVを再起動すると、リージョンは残りの正常なレプリカを > **Note:** > -> - 指定されたリージョンのピアが配置されているすべてのストアに対してこのコマンドを実行する必要があります。 -> - このコマンドはローカルモードのみをサポートします。正常に実行されると`success!`出力。 +> - 指定されたリージョンのピアが配置されているすべてのストアに対してこのコマンドを実行する必要があります。 +> - このコマンドはローカルモードのみをサポートします。正常に実行されると`success!`出力。 ### MVCCデータ破損からの回復 {#recover-from-mvcc-data-corruption} MVCCデータ破損によりTiKVが正常に動作しない場合は、コマンド`recover-mvcc`を使用してください。このコマンドは、3つのCF（「default」、「write」、「lock」）をクロスチェックし、様々な不整合を回復します。 -- `-r`オプションを使用して、関係するリージョンを`region_id`で指定します。 -- PD エンドポイントを指定するには、 `-p`オプションを使用します。 +- `-r`オプションを使用して、関係するリージョンを`region_id`で指定します。 +- PD エンドポイントを指定するには、 `-p`オプションを使用します。 ```shell tikv-ctl --data-dir /path/to/tikv recover-mvcc -r 1001,1002 -p 127.0.0.1:2379 @@ -483,9 +519,9 @@ success! > **Note:** > -> - このコマンドはローカルモードのみをサポートします。正常に実行されると`success!`出力。 -> - `-p`オプションの引数は、 `http`プレフィックスのない PD エンドポイントを指定します。PD エンドポイントを指定することで、指定された`region_id`検証されているかどうかを照会できます。 -> - 指定されたリージョンのピアが配置されているすべてのストアに対してこのコマンドを実行する必要があります。 +> - このコマンドはローカルモードのみをサポートします。正常に実行されると`success!`出力。 +> - `-p`オプションの引数は、 `http`プレフィックスのない PD エンドポイントを指定します。PD エンドポイントを指定することで、指定された`region_id`検証されているかどうかを照会できます。 +> - 指定されたリージョンのピアが配置されているすべてのストアに対してこのコマンドを実行する必要があります。 ### Ldbコマンド {#ldb-command} @@ -515,9 +551,11 @@ tikv-ctl ldb --hex manifest_dump --path=/tmp/db/MANIFEST-000001 データファイルの暗号化情報をダンプするには、サブコマンド`encryption-meta dump-file`を使用します。TiKV デプロイメントに`data-dir`を指定するには、TiKV 構成ファイルを作成する必要があります。 - # conf.toml - [storage] - data-dir = "/path/to/tikv/data" +``` +# conf.toml +[storage] +data-dir = "/path/to/tikv/data" +``` `--path`オプションは、対象のデータファイルへの絶対パスまたは相対パスを指定するために使用できます。データファイルが暗号化されていない場合、コマンドは空の出力を返すことがあります。`--path`を指定しない場合は、すべてのデータファイルの暗号化情報が出力されます。 @@ -525,18 +563,22 @@ tikv-ctl ldb --hex manifest_dump --path=/tmp/db/MANIFEST-000001 tikv-ctl --config=./conf.toml encryption-meta dump-file --path=/path/to/tikv/data/db/CURRENT ``` - /path/to/tikv/data/db/CURRENT: key_id: 9291156302549018620 iv: E3C2FDBF63FC03BFC28F265D7E78283F method: Aes128Ctr +``` +/path/to/tikv/data/db/CURRENT: key_id: 9291156302549018620 iv: E3C2FDBF63FC03BFC28F265D7E78283F method: Aes128Ctr +``` データ暗号化キーをダンプするには、サブコマンド`encryption-meta dump-key`を使用します。 `data-dir`に加えて、設定ファイルで現在使用されているマスターキーも指定する必要があります。マスターキーの設定方法については、 [保存時の暗号化](/encryption-at-rest.md)を参照してください。また、このコマンドでは`security.encryption.previous-master-key`設定は無視され、マスターキーのローテーションは実行されません。 - # conf.toml - [storage] - data-dir = "/path/to/tikv/data" - - [security.encryption.master-key] - type = "kms" - key-id = "0987dcba-09fe-87dc-65ba-ab0987654321" - region = "us-west-2" +``` +# conf.toml +[storage] +data-dir = "/path/to/tikv/data" + +[security.encryption.master-key] +type = "kms" +key-id = "0987dcba-09fe-87dc-65ba-ab0987654321" +region = "us-west-2" +``` マスターキーがAWS KMSキーの場合、 `tikv-ctl` KMSキーへのアクセス権を持っている必要があります。AWS KMSキーへのアクセス権は、環境変数、AWSデフォルト設定ファイル、またはIAMロールのいずれか適切な方法で`tikv-ctl`に付与できます。使用方法についてはAWSドキュメントを参照してください。 @@ -548,18 +590,22 @@ tikv-ctl --config=./conf.toml encryption-meta dump-file --path=/path/to/tikv/dat tikv-ctl --config=./conf.toml encryption-meta dump-key ``` - This action will expose encryption key(s) as plaintext. Do not output the result in file on disk. - Type "I consent" to continue, anything else to exit: I consent - current key id: 9291156302549018620 - 9291156302549018620: key: 8B6B6B8F83D36BE2467ED55D72AE808B method: Aes128Ctr creation_time: 1592938357 +``` +This action will expose encryption key(s) as plaintext. Do not output the result in file on disk. +Type "I consent" to continue, anything else to exit: I consent +current key id: 9291156302549018620 +9291156302549018620: key: 8B6B6B8F83D36BE2467ED55D72AE808B method: Aes128Ctr creation_time: 1592938357 +``` ```shell tikv-ctl --config=./conf.toml encryption-meta dump-key --ids=9291156302549018620 ``` - This action will expose encryption key(s) as plaintext. Do not output the result in file on disk. - Type "I consent" to continue, anything else to exit: I consent - 9291156302549018620: key: 8B6B6B8F83D36BE2467ED55D72AE808B method: Aes128Ctr creation_time: 1592938357 +``` +This action will expose encryption key(s) as plaintext. Do not output the result in file on disk. +Type "I consent" to continue, anything else to exit: I consent +9291156302549018620: key: 8B6B6B8F83D36BE2467ED55D72AE808B method: Aes128Ctr creation_time: 1592938357 +``` > **Note:** > @@ -579,58 +625,64 @@ TiKV内の破損したSSTファイルは、TiKVプロセスにpanicを引き起 tikv-ctl --data-dir bad-ssts --pd ``` - -------------------------------------------------------- - corruption info: - data/tikv-21107/db/000014.sst: Corruption: Bad table magic number: expected 9863518390377041911, found 759105309091689679 in data/tikv-21107/db/000014.sst - - sst meta: - 14:552997[1 .. 5520]['0101' seq:1, type:1 .. '7A7480000000000000FF0F5F728000000000FF0002160000000000FAFA13AB33020BFFFA' seq:2032, type:1] at level 0 for Column family "default" (ID 0) - it isn't easy to handle local data, start key:0101 - - overlap region: - RegionInfo { region: id: 4 end_key: 7480000000000000FF0500000000000000F8 region_epoch { conf_ver: 1 version: 2 } peers { id: 5 store_id: 1 }, leader: Some(id: 5 store_id: 1) } - - refer operations: - tikv-ctl ldb --db=/path/to/tikv/db unsafe_remove_sst_file 000014 - tikv-ctl --data-dir=/path/to/tikv tombstone -r 4 --pd - -------------------------------------------------------- - corruption analysis has completed +``` +-------------------------------------------------------- +corruption info: +data/tikv-21107/db/000014.sst: Corruption: Bad table magic number: expected 9863518390377041911, found 759105309091689679 in data/tikv-21107/db/000014.sst + +sst meta: +14:552997[1 .. 5520]['0101' seq:1, type:1 .. '7A7480000000000000FF0F5F728000000000FF0002160000000000FAFA13AB33020BFFFA' seq:2032, type:1] at level 0 for Column family "default" (ID 0) +it isn't easy to handle local data, start key:0101 + +overlap region: +RegionInfo { region: id: 4 end_key: 7480000000000000FF0500000000000000F8 region_epoch { conf_ver: 1 version: 2 } peers { id: 5 store_id: 1 }, leader: Some(id: 5 store_id: 1) } + +refer operations: +tikv-ctl ldb --db=/path/to/tikv/db unsafe_remove_sst_file 000014 +tikv-ctl --data-dir=/path/to/tikv tombstone -r 4 --pd +-------------------------------------------------------- +corruption analysis has completed +``` 上記の出力から、破損した SST ファイルの情報が最初に印刷され、次にメタ情報が印刷されていることがわかります。 -- `sst meta`部分で、 `14` SST ファイル番号、 `552997`ファイル サイズを意味し、その後に最小および最大のシーケンス番号とその他のメタ情報が続きます。 -- `overlap region`部分は、関係するリージョンの情報を示しています。この情報はPDサーバーから取得されます。 -- パート`suggested operations` 、破損したSSTファイルをクリーンアップするための提案が示されています。この提案に従ってファイルをクリーンアップし、TiKVインスタンスを再起動してください。 +- `sst meta`部分で、 `14` SST ファイル番号、 `552997`ファイル サイズを意味し、その後に最小および最大のシーケンス番号とその他のメタ情報が続きます。 +- `overlap region`部分は、関係するリージョンの情報を示しています。この情報はPDサーバーから取得されます。 +- パート`suggested operations` 、破損したSSTファイルをクリーンアップするための提案が示されています。この提案に従ってファイルをクリーンアップし、TiKVインスタンスを再起動してください。 ### リージョンの`RegionReadProgress`の状態を取得する {#get-the-state-of-a-regions-regionreadprogress} v6.5.4およびv7.3.0以降、TiKVはリゾルバの最新の詳細情報を取得するためのサブコマンド`get-region-read-progress`と`RegionReadProgress`導入しました。リージョンIDとTiKVを指定する必要があります。これらはGrafana（ `Min Resolved TS Region`と`Min Safe TS Region` ）または`DataIsNotReady`ログから取得できます。 -- `--log` （オプション）: 指定すると、TiKVはリージョンのリゾルバ内のロックのうち、最も小さい`start_ts`をレベル`INFO`でこのTiKVに記録します。このオプションは、resolved-tsをブロックする可能性のあるロックを事前に特定するのに役立ちます。 +- `--log` （オプション）: 指定すると、TiKVはリージョンのリゾルバ内のロックのうち、最も小さい`start_ts`をレベル`INFO`でこのTiKVに記録します。このオプションは、resolved-tsをブロックする可能性のあるロックを事前に特定するのに役立ちます。 -- `--min-start-ts` (オプション): 指定すると、TiKV はログからこの値より小さい`start_ts`のロックを除外します。ログに記録するトランザクションを指定する場合に使用できます。デフォルトは`0`で、フィルターなしを意味します。 +- `--min-start-ts` (オプション): 指定すると、TiKV はログからこの値より小さい`start_ts`のロックを除外します。ログに記録するトランザクションを指定する場合に使用できます。デフォルトは`0`で、フィルターなしを意味します。 次に例を示します。 - ./tikv-ctl --host 127.0.0.1:20160 get-region-read-progress -r 14 --log --min-start-ts 0 +``` +./tikv-ctl --host 127.0.0.1:20160 get-region-read-progress -r 14 --log --min-start-ts 0 +``` 出力は次のようになります。 - Region read progress: - exist: true, - safe_ts: 0, - applied_index: 92, - pending front item (oldest) ts: 0, - pending front item (oldest) applied index: 0, - pending back item (latest) ts: 0, - pending back item (latest) applied index: 0, - paused: false, - Resolver: - exist: true, - resolved_ts: 0, - tracked index: 92, - number of locks: 0, - number of transactions: 0, - stopped: false, +``` +Region read progress: + exist: true, + safe_ts: 0, + applied_index: 92, + pending front item (oldest) ts: 0, + pending front item (oldest) applied index: 0, + pending back item (latest) ts: 0, + pending back item (latest) applied index: 0, + paused: false, +Resolver: + exist: true, + resolved_ts: 0, + tracked index: 92, + number of locks: 0, + number of transactions: 0, + stopped: false, +``` このサブコマンドは、 ステイル読み取りおよびsafe-tsに関連する問題の診断に役立ちます。詳細については、 [TiKV におけるステイル読み取りと safe-ts の理解](/troubleshoot-stale-read.md)を参照してください。 diff --git a/tikv-in-memory-engine.md b/tikv-in-memory-engine.md index 16bda249b1db5..6d638e8930b9e 100644 --- a/tikv-in-memory-engine.md +++ b/tikv-in-memory-engine.md @@ -9,8 +9,8 @@ TiKV MVCC インメモリ エンジン (IME) は、主に多数の MVCC 履歴 TiKV MVCCインメモリエンジンは、以下のシナリオに適しています。 -- 頻繁に更新または削除されるレコードを照会する必要があるアプリケーション。 -- TiDBに履歴バージョンをより長い期間（例えば24時間）保持するために、 [`tidb_gc_life_time`](/garbage-collection-configuration.md#garbage-collection-configuration)調整する必要があるアプリケーション。 +- 頻繁に更新または削除されるレコードを照会する必要があるアプリケーション。 +- TiDBに履歴バージョンをより長い期間（例えば24時間）保持するために、 [`tidb_gc_life_time`](/garbage-collection-configuration.md#garbage-collection-configuration)調整する必要があるアプリケーション。 ## 実装原理 {#implementation-principles} @@ -22,13 +22,13 @@ TiKV MVCCインメモリエンジンは、最新の書き込み済みMVCCバー 前述の図は、それぞれ9つのMVCCバージョンを含む2行のレコードを示しています。インメモリエンジンを有効にした場合と無効にした場合の動作比較は以下のとおりです。 -- 左側（インメモリエンジンが無効になっている場合）：テーブルレコードは、主キーに基づいて昇順でRocksDBに格納され、同じ行のすべてのMVCCバージョンが隣接して配置されます。 -- 右側（インメモリエンジン有効）：RocksDB内のデータは左側のデータと同じですが、インメモリエンジンは2つの行それぞれについて最新の2つのMVCCバージョンをキャッシュします。 -- TiKVが範囲`[k1, k2]` 、開始タイムスタンプ`8`のスキャン要求を処理する場合： - - インメモリエンジン（左図）がない場合、11個のMVCCバージョンを処理する必要がある。 - - インメモリエンジン（右図）では、処理するMVCCバージョンは4つだけなので、リクエストのレイテンシーとCPU消費量が削減されます。 -- TiKVが範囲`[k1, k2]` 、開始タイムスタンプ`7`のスキャン要求を処理する場合： - - メモリ内エンジン（右図）に必要な履歴バージョンが欠落しているため、キャッシュが無効になり、TiKVはRocksDBからデータを読み込むようにフォールバックします。 +- 左側（インメモリエンジンが無効になっている場合）：テーブルレコードは、主キーに基づいて昇順でRocksDBに格納され、同じ行のすべてのMVCCバージョンが隣接して配置されます。 +- 右側（インメモリエンジン有効）：RocksDB内のデータは左側のデータと同じですが、インメモリエンジンは2つの行それぞれについて最新の2つのMVCCバージョンをキャッシュします。 +- TiKVが範囲`[k1, k2]` 、開始タイムスタンプ`8`のスキャン要求を処理する場合： + - インメモリエンジン（左図）がない場合、11個のMVCCバージョンを処理する必要がある。 + - インメモリエンジン（右図）では、処理するMVCCバージョンは4つだけなので、リクエストのレイテンシーとCPU消費量が削減されます。 +- TiKVが範囲`[k1, k2]` 、開始タイムスタンプ`7`のスキャン要求を処理する場合： + - メモリ内エンジン（右図）に必要な履歴バージョンが欠落しているため、キャッシュが無効になり、TiKVはRocksDBからデータを読み込むようにフォールバックします。 ## 使用法 {#usage} @@ -59,28 +59,28 @@ mvcc-amplification-threshold = 10 > **Note:** > -> - インメモリエンジンはデフォルトでは無効になっています。有効にした後は、TiKVを再起動する必要があります。 -> - `enable`を除き、その他の設定項目はすべて動的に調整可能です。 +> - インメモリエンジンはデフォルトでは無効になっています。有効にした後は、TiKVを再起動する必要があります。 +> - `enable`を除き、その他の設定項目はすべて動的に調整可能です。 ### 自動読み込み {#automatic-loading} インメモリエンジンを有効にすると、TiKVはリージョンの読み取りトラフィックとMVCC増幅に基づいて、ロードするリージョンを自動的に選択します。具体的な手順は次のとおりです。 -1. リージョンは、最近の`next` （RocksDB Iterator next API）および`prev` （RocksDB Iterator prev API）の呼び出し回数に基づいてソートされます。 -2. 領域は、 `mvcc-amplification-threshold`構成パラメータを使用してフィルタリングされます。デフォルト値は`10`です。MVCC 増幅は、( `next` + `prev` ) / `processed_keys`として計算されるリード増幅を測定します。 -3. MVCC増幅が著しい上位N個の領域がロードされる。ここでNはメモリ推定に基づいて決定される。 +1. リージョンは、最近の`next` （RocksDB Iterator next API）および`prev` （RocksDB Iterator prev API）の呼び出し回数に基づいてソートされます。 +2. 領域は、 `mvcc-amplification-threshold`構成パラメータを使用してフィルタリングされます。デフォルト値は`10`です。MVCC 増幅は、( `next` + `prev` ) / `processed_keys`として計算されるリード増幅を測定します。 +3. MVCC増幅が著しい上位N個の領域がロードされる。ここでNはメモリ推定に基づいて決定される。 インメモリエンジンは定期的にリージョンを削除します。そのプロセスは以下のとおりです。 -1. インメモリエンジンは、読み取りトラフィックが少ない、またはMVCC増幅率が低い領域を削除します。 -2. メモリ使用率が`capacity`の90%に達し、新しいリージョンをロードする必要がある場合、インメモリエンジンは読み取りトラフィックに基づいてリージョンを選択および削除します。 +1. インメモリエンジンは、読み取りトラフィックが少ない、またはMVCC増幅率が低い領域を削除します。 +2. メモリ使用率が`capacity`の90%に達し、新しいリージョンをロードする必要がある場合、インメモリエンジンは読み取りトラフィックに基づいてリージョンを選択および削除します。 ## 互換性 {#compatibility} -- [BR](/br/br-use-overview.md) ：インメモリエンジンはBRと併用できます。ただし、 BRリストア中は、リストア処理に関係するリージョンはインメモリエンジンから削除されます。BRが完了した後、対応するリージョンがホットスポットとして残っている場合は、インメモリエンジンによって自動的にロードされます。 -- [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) ：インメモリエンジンはTiDB Lightningと併用できます。ただし、 TiDB Lightningが物理インポートモードで動作する場合、復元プロセスに関係するリージョンはインメモリエンジンから削除されます。物理インポートが完了すると、対応するリージョンがホットスポットとして残っている場合、それらはインメモリエンジンによって自動的にロードされます。 -- [Follower Read](/develop/dev-guide-use-follower-read.md)と[ステイル読み取り](/develop/dev-guide-use-stale-read.md) ：インメモリエンジンは、これら2つの機能と併用できます。ただし、インメモリエンジンはLeader上のコプロセッサ要求のみを高速化でき、Follower Readとステイル読み取り操作を高速化することはできません。 -- [`FLASHBACK CLUSTER`](/sql-statements/sql-statement-flashback-cluster.md) ：インメモリエンジンはFlashbackと併用できます。ただし、Flashbackはインメモリエンジンのキャッシュを無効化します。Flashback処理が完了すると、インメモリエンジンはホットスポット領域を自動的にロードします。 +- [BR](/br/br-use-overview.md) ：インメモリエンジンはBRと併用できます。ただし、 BRリストア中は、リストア処理に関係するリージョンはインメモリエンジンから削除されます。BRが完了した後、対応するリージョンがホットスポットとして残っている場合は、インメモリエンジンによって自動的にロードされます。 +- [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) ：インメモリエンジンはTiDB Lightningと併用できます。ただし、 TiDB Lightningが物理インポートモードで動作する場合、復元プロセスに関係するリージョンはインメモリエンジンから削除されます。物理インポートが完了すると、対応するリージョンがホットスポットとして残っている場合、それらはインメモリエンジンによって自動的にロードされます。 +- [Follower Read](/develop/dev-guide-use-follower-read.md)と[ステイル読み取り](/develop/dev-guide-use-stale-read.md) ：インメモリエンジンは、これら2つの機能と併用できます。ただし、インメモリエンジンはLeader上のコプロセッサ要求のみを高速化でき、Follower Readとステイル読み取り操作を高速化することはできません。 +- [`FLASHBACK CLUSTER`](/sql-statements/sql-statement-flashback-cluster.md) ：インメモリエンジンはFlashbackと併用できます。ただし、Flashbackはインメモリエンジンのキャッシュを無効化します。Flashback処理が完了すると、インメモリエンジンはホットスポット領域を自動的にロードします。 ## FAQ {#faq} diff --git a/time-to-live.md b/time-to-live.md index 7f9ff6b4bb72b..26bfe67a6b1b0 100644 --- a/time-to-live.md +++ b/time-to-live.md @@ -9,9 +9,9 @@ Time to Live（TTL）は、TiDBデータの有効期間を行レベルで管理 TTL の一般的なシナリオを次に示します。 -- 確認コードと短縮 URL を定期的に削除します。 -- 不要な履歴注文を定期的に削除します。 -- 計算の中間結果を自動的に削除します。 +- 確認コードと短縮 URL を定期的に削除します。 +- 不要な履歴注文を定期的に削除します。 +- 計算の中間結果を自動的に削除します。 TTLは、オンラインの読み取りおよび書き込みワークロードに影響を与えることなく、不要なデータを定期的かつタイムリーにクリーンアップできるように設計されています。TTLは、異なるジョブを異なるTiDBノードに同時にディスパッチし、テーブル単位でデータを並列に削除します。TTLは、すべての期限切れデータが即座に削除されることを保証するものではありません。つまり、一部のデータが期限切れになったとしても、バックグラウンドTTLジョブによってそのデータが削除されるまで、クライアントは有効期限が切れてからしばらく経ってからそのデータを読み取る可能性があります。 @@ -21,7 +21,7 @@ TTLは、オンラインの読み取りおよび書き込みワークロード ### TTL属性を持つテーブルを作成する {#create-a-table-with-a-ttl-attribute} -- TTL 属性を持つテーブルを作成します。 +- TTL 属性を持つテーブルを作成します。 ```sql CREATE TABLE t1 ( @@ -32,7 +32,7 @@ TTLは、オンラインの読み取りおよび書き込みワークロード 上記の例では、テーブル`t1`を作成し、TTLタイムスタンプ列に`created_at`を指定しています。これはデータの作成時刻を示します。また、テーブル内で行が保持できる最長期間を、 `INTERVAL 3 MONTH`によって 3 か月に設定しています。この値を超えて保持されるデータは、後で削除されます。 -- 期限切れのデータをクリーンアップする機能を有効または無効にするには、 `TTL_ENABLE`属性を設定します。 +- 期限切れのデータをクリーンアップする機能を有効または無効にするには、 `TTL_ENABLE`属性を設定します。 ```sql CREATE TABLE t1 ( @@ -43,7 +43,7 @@ TTLは、オンラインの読み取りおよび書き込みワークロード `TTL_ENABLE`を`OFF`に設定した場合、他の TTL オプションが設定されていても、TiDB はこのテーブル内の期限切れデータを自動的にクリーンアップしません。TTL 属性を持つテーブルの場合、デフォルトでは`TTL_ENABLE`が`ON`になります。 -- MySQL との互換性を保つために、コメントを使用して TTL 属性を設定できます。 +- MySQL との互換性を保つために、コメントを使用して TTL 属性を設定できます。 ```sql CREATE TABLE t1 ( @@ -56,7 +56,7 @@ TTLは、オンラインの読み取りおよび書き込みワークロード ### テーブルのTTL属性を変更する {#modify-the-ttl-attribute-of-a-table} -- テーブルの TTL 属性を変更します。 +- テーブルの TTL 属性を変更します。 ```sql ALTER TABLE t1 TTL = `created_at` + INTERVAL 1 MONTH; @@ -64,13 +64,13 @@ TTLは、オンラインの読み取りおよび書き込みワークロード 上記のステートメントを使用して、既存の TTL 属性を持つテーブルを変更したり、TTL 属性のないテーブルに TTL 属性を追加したりできます。 -- TTL 属性を持つテーブルの値を`TTL_ENABLE`に変更します。 +- TTL 属性を持つテーブルの値を`TTL_ENABLE`に変更します。 ```sql ALTER TABLE t1 TTL_ENABLE = 'OFF'; ``` -- テーブルのすべての TTL 属性を削除するには: +- テーブルのすべての TTL 属性を削除するには: ```sql ALTER TABLE t1 REMOVE TTL; @@ -80,7 +80,7 @@ TTLは、オンラインの読み取りおよび書き込みワークロード TTL は[データ型のデフォルト値](/data-type-default-values.md)と組み合わせて使用​​できます。以下に一般的な使用例を2つ示します。 -- 列のデフォルト値を現在の作成時刻に指定し、この列をTTLタイムスタンプ列として使用するには、 `DEFAULT CURRENT_TIMESTAMP`を使用します。3か月前に作成されたレコードは期限切れです。 +- 列のデフォルト値を現在の作成時刻に指定し、この列をTTLタイムスタンプ列として使用するには、 `DEFAULT CURRENT_TIMESTAMP`を使用します。3か月前に作成されたレコードは期限切れです。 ```sql CREATE TABLE t1 ( @@ -89,7 +89,7 @@ TTL は[データ型のデフォルト値](/data-type-default-values.md)と組 ) TTL = `created_at` + INTERVAL 3 MONTH; ``` -- 列のデフォルト値を作成時刻または最終更新時刻として指定し、その列をTTLタイムスタンプ列として使用します。3ヶ月間更新されていないレコードは期限切れとなります。 +- 列のデフォルト値を作成時刻または最終更新時刻として指定し、その列をTTLタイムスタンプ列として使用します。3ヶ月間更新されていないレコードは期限切れとなります。 ```sql CREATE TABLE t1 ( @@ -173,7 +173,7 @@ TiDBはTTLに関する実行時情報を定期的に収集し、Grafanaでこれ さらに、TiDB は TTL ジョブに関する詳細情報を取得するための 3 つのテーブルを提供します。 -- `mysql.tidb_ttl_table_status`テーブルには、すべての TTL テーブルについて、以前に実行された TTL ジョブと進行中の TTL ジョブに関する情報が含まれています。 +- `mysql.tidb_ttl_table_status`テーブルには、すべての TTL テーブルについて、以前に実行された TTL ジョブと進行中の TTL ジョブに関する情報が含まれています。 ```sql TABLE mysql.tidb_ttl_table_status LIMIT 1\G @@ -205,9 +205,9 @@ TiDBはTTLに関する実行時情報を定期的に収集し、Grafanaでこれ 列`{last, current}_job_{start_time, finish_time, ttl_expire}`は、それぞれ、前回または現在実行中のTTLジョブで使用された開始時刻、終了時刻、有効期限を示します。列`last_job_summary`は、前回のTTLタスクの実行ステータス（合計行数、成功行数、失敗行数など）を示します。 -- `mysql.tidb_ttl_task`テーブルには、実行中の TTL サブタスクに関する情報が含まれています。TTL ジョブは複数のサブタスクに分割され、このテーブルには現在実行中のサブタスクが記録されます。 +- `mysql.tidb_ttl_task`テーブルには、実行中の TTL サブタスクに関する情報が含まれています。TTL ジョブは複数のサブタスクに分割され、このテーブルには現在実行中のサブタスクが記録されます。 -- `mysql.tidb_ttl_job_history`テーブルには、実行された TTL ジョブに関する情報が含まれています。TTL ジョブの履歴は 90 日間保存されます。 +- `mysql.tidb_ttl_job_history`テーブルには、実行された TTL ジョブに関する情報が含まれています。TTL ジョブの履歴は 90 日間保存されます。 ```sql TABLE mysql.tidb_ttl_job_history LIMIT 1\G @@ -255,25 +255,25 @@ TTL は、他の TiDB 移行、バックアップ、およびリカバリ ツー 現在、TTL 機能には次の制限があります。 -- TTL 属性は、ローカル一時テーブルやグローバル一時テーブルなどの一時テーブルには設定できません。 -- TTL 属性を持つテーブルは、外部キー制約のプライマリ テーブルとして他のテーブルから参照されることをサポートしていません。 -- すべての期限切れデータが直ちに削除されることは保証されません。期限切れデータが削除されるタイミングは、バックグラウンドクリーンアップジョブのスケジュール間隔とスケジュールウィンドウによって異なります。 -- [クラスター化インデックス](/clustered-indexes.md)を使用するテーブルの場合、次のシナリオでのみ、TTL ジョブを複数のサブタスクに分割できます。 - - 主キーまたは複合主キーの最初の列は、 `INTEGER`またはバイナリ文字列型です。バイナリ文字列型は主に以下のものを指します。 - - `CHAR(N) CHARACTER SET BINARY` - - `VARCHAR(N) CHARACTER SET BINARY` - - `BINARY(N)` - - `VARBINARY(N)` - - `BIT(N)` - - 主キーまたは複合主キーの最初の列の文字セットは`utf8`または`utf8mb4`であり、照合順序は`utf8_bin` 、 `utf8mb4_bin` 、または`utf8mb4_0900_bin`です。 - - 主キーの最初の列の文字セットタイプが`utf8`または`utf8mb4`あるテーブルの場合、サブタスクは表示可能なASCII文字の範囲に基づいてのみ分割されます。多くの主キー値に同じASCIIプレフィックスが付いている場合、タスクの分割が不均一になる可能性があります。 - - TTLジョブを複数のサブタスクに分割できないテーブルの場合、TTLジョブは単一のTiDBノードで順次実行されます。テーブルに大量のデータが含まれている場合、TTLジョブの実行速度が遅くなる可能性があります。 +- TTL 属性は、ローカル一時テーブルやグローバル一時テーブルなどの一時テーブルには設定できません。 +- TTL 属性を持つテーブルは、外部キー制約のプライマリ テーブルとして他のテーブルから参照されることをサポートしていません。 +- すべての期限切れデータが直ちに削除されることは保証されません。期限切れデータが削除されるタイミングは、バックグラウンドクリーンアップジョブのスケジュール間隔とスケジュールウィンドウによって異なります。 +- [クラスター化インデックス](/clustered-indexes.md)を使用するテーブルの場合、次のシナリオでのみ、TTL ジョブを複数のサブタスクに分割できます。 + - 主キーまたは複合主キーの最初の列は、 `INTEGER`またはバイナリ文字列型です。バイナリ文字列型は主に以下のものを指します。 + - `CHAR(N) CHARACTER SET BINARY` + - `VARCHAR(N) CHARACTER SET BINARY` + - `BINARY(N)` + - `VARBINARY(N)` + - `BIT(N)` + - 主キーまたは複合主キーの最初の列の文字セットは`utf8`または`utf8mb4`であり、照合順序は`utf8_bin` 、 `utf8mb4_bin` 、または`utf8mb4_0900_bin`です。 + - 主キーの最初の列の文字セットタイプが`utf8`または`utf8mb4`あるテーブルの場合、サブタスクは表示可能なASCII文字の範囲に基づいてのみ分割されます。多くの主キー値に同じASCIIプレフィックスが付いている場合、タスクの分割が不均一になる可能性があります。 + - TTLジョブを複数のサブタスクに分割できないテーブルの場合、TTLジョブは単一のTiDBノードで順次実行されます。テーブルに大量のデータが含まれている場合、TTLジョブの実行速度が遅くなる可能性があります。 ## よくある質問 {#faqs} -- 削除がデータ サイズを比較的安定させるのに十分な速さであるかどうかをどのように判断すればよいでしょうか? +- 削除がデータ サイズを比較的安定させるのに十分な速さであるかどうかをどのように判断すればよいでしょうか? [Grafana `TiDB`ダッシュボード](/grafana-tidb-dashboard.md)パネル`TTL Insert Rows Per Hour`は、過去 1 時間に挿入された行の総数を記録します。対応する`TTL Delete Rows Per Hour`は 、過去 1 時間に TTL タスクによって削除された行の総数を記録します。`TTL Insert Rows Per Hour`が長期間にわたって`TTL Delete Rows Per Hour`よりも高い場合、挿入率が削除率を上回り、データの総量が増加することを意味します。例: @@ -281,7 +281,7 @@ TTL は、他の TiDB 移行、バックアップ、およびリカバリ ツー TTLは期限切れの行がすぐに削除されることを保証するものではなく、現在挿入されている行は将来のTTLタスクで削除されるため、TTL削除速度が短期間で挿入速度よりも遅い場合でも、必ずしもTTL速度が遅すぎることを意味するわけではないことに注意してください。状況をその文脈で考慮する必要があります。 -- TTL タスクのボトルネックがスキャンにあるか削除にあるかをどのように判断すればよいですか? +- TTL タスクのボトルネックがスキャンにあるか削除にあるかをどのように判断すればよいですか? パネル`TTL Scan Worker Time By Phase`と`TTL Delete Worker Time By Phase`を見てください。スキャンワーカーが`dispatch`フェーズにある時間の割合がかなり多く、削除ワーカーが`idle`フェーズにあることがほとんどない場合、スキャンワーカーは削除ワーカーによる削除の完了を待機しています。この時点でクラスターリソースにまだ余裕がある場合は、 `tidb_ttl_ delete_worker_count`増やして削除ワーカーの数を増やすことを検討してください。例： @@ -293,17 +293,17 @@ TTL は、他の TiDB 移行、バックアップ、およびリカバリ ツー TTLジョブにおけるスキャンと削除の割合はマシン構成とデータ分布に関連しているため、各時点の監視データは実行中のTTLジョブの代表値に過ぎません。表`mysql.tidb_ttl_job_history`を参照することで、特定の時点で実行されているTTLジョブと、そのジョブに対応する表を確認できます。 -- `tidb_ttl_scan_worker_count`と`tidb_ttl_delete_worker_count`適切に設定するにはどうすればいいでしょうか? +- `tidb_ttl_scan_worker_count`と`tidb_ttl_delete_worker_count`適切に設定するにはどうすればいいでしょうか? - 1. `tidb_ttl_scan_worker_count`または`tidb_ttl_delete_worker_count`の値を増やすかどうかを検討するには、「TTL タスクのボトルネックがスキャンにあるか削除にあるかを判断するにはどうすればよいでしょうか」という質問を参照してください。 - 2. TiKV ノードの数が多い場合は、値を`tidb_ttl_scan_worker_count`増やすと、TTL タスクのワークロードのバランスがより取れます。 + 1. `tidb_ttl_scan_worker_count`または`tidb_ttl_delete_worker_count`の値を増やすかどうかを検討するには、「TTL タスクのボトルネックがスキャンにあるか削除にあるかを判断するにはどうすればよいでしょうか」という質問を参照してください。 + 2. TiKV ノードの数が多い場合は、値を`tidb_ttl_scan_worker_count`増やすと、TTL タスクのワークロードのバランスがより取れます。 TTLワーカーが多すぎると負荷が大きくなるため、TiDBのCPUレベルとTiKVのディスクおよびCPU使用率を併せて評価する必要があります。シナリオやニーズ（TTLを可能な限り高速化する必要があるか、他のクエリへのTTLの影響を軽減する必要があるかなど）に応じて、 `tidb_ttl_scan_worker_count`と`tidb_ttl_delete_worker_count`の値を調整することで、TTLスキャンと削除の速度を向上させたり、TTLタスクによるパフォーマンスへの影響を軽減したりできます。 -- `tidb_ttl_scan_worker_count`と`tidb_ttl_delete_worker_count`適切に設定するにはどうすればいいでしょうか? +- `tidb_ttl_scan_worker_count`と`tidb_ttl_delete_worker_count`適切に設定するにはどうすればいいでしょうか? TiKV ノードの数が多い場合は、値を`tidb_ttl_scan_worker_count`増やすと、TTL タスクのワークロードのバランスがより取れます。 diff --git a/tiproxy/tiproxy-api.md b/tiproxy/tiproxy-api.md index b1ec5de152fef..56c7fa0abbeb1 100644 --- a/tiproxy/tiproxy-api.md +++ b/tiproxy/tiproxy-api.md @@ -27,7 +27,7 @@ curl http://127.0.0.1:3080/api/admin/config/ クエリパラメータは次のとおりです。 -- `format` : (オプション) 返される設定の形式を指定します。値のオプションは`json`と`toml`です。デフォルト値は`toml`です。 +- `format` : (オプション) 返される設定の形式を指定します。値のオプションは`json`と`toml`です。デフォルト値は`toml`です。 ### 例 {#example} @@ -58,7 +58,7 @@ level='warning' 次の例では、他の構成項目は変更せずに、 `log.level` `'warning'`に設定します。 -1. 現在の TiProxy 構成を取得します。 +1. 現在の TiProxy 構成を取得します。 ```bash curl http://127.0.0.1:3080/api/admin/config/ @@ -72,7 +72,7 @@ level='warning' level = 'info' ``` -2. `test.toml`ファイルで`log.level`の値を指定し、 `PUT /api/admin/config/`リクエストを送信して`log.level`の値を更新します。 +2. `test.toml`ファイルで`log.level`の値を指定し、 `PUT /api/admin/config/`リクエストを送信して`log.level`の値を更新します。 ```shell $ cat test.toml @@ -81,7 +81,7 @@ level='warning' $ curl -X PUT --data-binary @test.toml http://127.0.0.1:3080/api/admin/config/ ``` -3. 変更された TiProxy 構成を取得します。 +3. 変更された TiProxy 構成を取得します。 ```bash curl http://127.0.0.1:3080/api/admin/config/ diff --git a/tiproxy/tiproxy-command-line-flags.md b/tiproxy/tiproxy-command-line-flags.md index c52f3cfac3f73..ab16c2c75901e 100644 --- a/tiproxy/tiproxy-command-line-flags.md +++ b/tiproxy/tiproxy-command-line-flags.md @@ -13,17 +13,17 @@ summary: TiProxy のコマンドライン起動フラグについて学習しま ### `--advertise-addr` {#advertise-addr} -- クライアントがこの TiProxy インスタンスに接続するために使用するアドレスを指定します。 -- タイプ: `string` -- デフォルト: `""` -- このフラグは、 TiUPまたはTiDB Operatorを使用して TiProxy をデプロイすると自動的に設定されます。設定されていない場合は、TiProxy インスタンスの外部 IP アドレスが使用されます。 +- クライアントがこの TiProxy インスタンスに接続するために使用するアドレスを指定します。 +- タイプ: `string` +- デフォルト: `""` +- このフラグは、 TiUPまたはTiDB Operatorを使用して TiProxy をデプロイすると自動的に設定されます。設定されていない場合は、TiProxy インスタンスの外部 IP アドレスが使用されます。 ### `--config` {#config} -- TiProxy 構成ファイルのパスを指定します。 -- タイプ: `string` -- デフォルト: `""` -- 設定ファイルを指定する必要があります。詳細な設定項目については、 [TiProxy を設定する](/tiproxy/tiproxy-configuration.md)を参照してください。設定ファイルが変更されると、TiProxyは自動的に設定を再読み込みするため、設定ファイルを直接変更しないでください。[`tiup cluster edit-config`](/tiup/tiup-component-cluster-edit-config.md)または[`kubectl edit tc`](https://docs.pingcap.com/tidb-in-kubernetes/stable/modify-tidb-configuration)を実行して設定を変更することをお勧めします。 +- TiProxy 構成ファイルのパスを指定します。 +- タイプ: `string` +- デフォルト: `""` +- 設定ファイルを指定する必要があります。詳細な設定項目については、 [TiProxy を設定する](/tiproxy/tiproxy-configuration.md)を参照してください。設定ファイルが変更されると、TiProxyは自動的に設定を再読み込みするため、設定ファイルを直接変更しないでください。[`tiup cluster edit-config`](/tiup/tiup-component-cluster-edit-config.md)または[`kubectl edit tc`](https://docs.pingcap.com/tidb-in-kubernetes/stable/modify-tidb-configuration)を実行して設定を変更することをお勧めします。 ## TiProxy コントロール {#tiproxy-control} @@ -79,51 +79,51 @@ tiproxyctl --host 127.0.0.1 --port 3080 config get #### `--host` {#host} -- TiProxyサーバーのアドレスを指定します。 -- タイプ: `string` -- デフォルト: `localhost` +- TiProxyサーバーのアドレスを指定します。 +- タイプ: `string` +- デフォルト: `localhost` #### `--port` {#port} -- TiProxy API ゲートウェイのポート番号を指定します。 -- タイプ: `int` -- デフォルト: `3080` +- TiProxy API ゲートウェイのポート番号を指定します。 +- タイプ: `int` +- デフォルト: `3080` #### `--log_encoder` {#log-encoder} -- `tiproxyctl`のログ形式を指定します。 -- タイプ: `string` -- デフォルト: `"tidb"` -- デフォルトではTiDBと同じログ形式が使用されます。ただし、次のいずれかを指定することもできます。 +- `tiproxyctl`のログ形式を指定します。 +- タイプ: `string` +- デフォルト: `"tidb"` +- デフォルトではTiDBと同じログ形式が使用されます。ただし、次のいずれかを指定することもできます。 - - `console` : より人間が読みやすい形式 - - `json` : 構造化されたログ形式 + - `console` : より人間が読みやすい形式 + - `json` : 構造化されたログ形式 #### `--log_level` {#log-level} -- tiproxyctl のログ レベルを指定します。 -- タイプ: `string` -- デフォルト: `"warn"` -- `debug` `info` `error`でき`panic` `warn` +- tiproxyctl のログ レベルを指定します。 +- タイプ: `string` +- デフォルト: `"warn"` +- `debug` `info` `error`でき`panic` `warn` #### `-k, --insecure` {#k-insecure} -- サーバーにダイヤルするときに TLS CA 検証をスキップするかどうかを指定します。 -- タイプ: `boolean` -- デフォルト: `false` -- テストに使用されます。 +- サーバーにダイヤルするときに TLS CA 検証をスキップするかどうかを指定します。 +- タイプ: `boolean` +- デフォルト: `false` +- テストに使用されます。 #### `--ca` {#ca} -- サーバーにダイヤルするときに CA を指定します。 -- タイプ: `string` -- デフォルト: `""` +- サーバーにダイヤルするときに CA を指定します。 +- タイプ: `string` +- デフォルト: `""` #### `--cert` {#cert} -- サーバーにダイヤルするときに証明書を指定します。 -- タイプ: `string` -- デフォルト: `""` +- サーバーにダイヤルするときに証明書を指定します。 +- タイプ: `string` +- デフォルト: `""` ### コマンド {#commands} @@ -163,8 +163,8 @@ level = 'warning' オプション: -- `--output` : (必須) トラフィック ファイルを保存するディレクトリを指定します。 -- `--duration` : (必須) キャプチャ期間を指定します。単位は`m` (分)、 `h` (時間)、 `d` (日) のいずれかです。例えば、 `--duration=1h`を指定すると 1 時間のトラフィックがキャプチャされます。 +- `--output` : (必須) トラフィック ファイルを保存するディレクトリを指定します。 +- `--duration` : (必須) キャプチャ期間を指定します。単位は`m` (分)、 `h` (時間)、 `d` (日) のいずれかです。例えば、 `--duration=1h`を指定すると 1 時間のトラフィックがキャプチャされます。 例： @@ -180,10 +180,10 @@ tiproxyctl traffic capture --host 10.0.1.10 --port 3080 --output="/tmp/traffic" オプション: -- `--username` : (必須) 再生用のデータベース ユーザー名を指定します。 -- `--password` : (オプション) ユーザー名のパスワードを指定します。デフォルト値は空の文字列`""`です。 -- `--input` : (必須) トラフィック ファイルを含むディレクトリを指定します。 -- `--speed` : (オプション) 再生速度の乗数を指定します。範囲は`[0.1, 10]`です。デフォルト値は`1`で、元の速度で再生されます。 +- `--username` : (必須) 再生用のデータベース ユーザー名を指定します。 +- `--password` : (オプション) ユーザー名のパスワードを指定します。デフォルト値は空の文字列`""`です。 +- `--input` : (必須) トラフィック ファイルを含むディレクトリを指定します。 +- `--speed` : (オプション) 再生速度の乗数を指定します。範囲は`[0.1, 10]`です。デフォルト値は`1`で、元の速度で再生されます。 例： @@ -203,9 +203,9 @@ tiproxyctl traffic replay --host 10.0.1.10 --port 3080 --username="u1" --passwor 出力の`status`フィールドはタスクのステータスを示し、次の値が可能です。 -- `done` : タスクは正常に完了しました。 -- `canceled` : タスクはキャンセルされました。理由は`error`フィールドで確認できます。 -- `running` ：タスクは実行中です。完了率は`progress`フィールドで確認できます。 +- `done` : タスクは正常に完了しました。 +- `canceled` : タスクはキャンセルされました。理由は`error`フィールドで確認できます。 +- `running` ：タスクは実行中です。完了率は`progress`フィールドで確認できます。 出力例: diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index bc2bdad048f40..547a5f9d68f18 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -43,55 +43,55 @@ SQL ポートのコンフィグレーション。 #### `addr` {#addr} -- デフォルト値: `0.0.0.0:6000` -- ホットリロードのサポート: いいえ -- SQLサービスのリスニングアドレス。形式は`:`です。この構成項目は、 TiUPまたはTiDB Operatorを使用してTiProxyをデプロイすると自動的に設定されます。 +- デフォルト値: `0.0.0.0:6000` +- ホットリロードのサポート: いいえ +- SQLサービスのリスニングアドレス。形式は`:`です。この構成項目は、 TiUPまたはTiDB Operatorを使用してTiProxyをデプロイすると自動的に設定されます。 #### `advertise-addr` {#advertise-addr} -- デフォルト値: `""` -- ホットリロードのサポート: いいえ -- 他のコンポーネントがこのTiProxyインスタンスに接続するために使用するアドレスを指定します。このアドレスにはホスト名のみが含まれ、ポート番号は含まれません。このアドレスは[`addr`](#addr)のホスト名とは異なる場合があります。例えば、TiProxyのTLS証明書の`Subject Alternative Name`ドメイン名のみが含まれている場合、他のコンポーネントはIP経由でTiProxyに接続できません。この設定項目は、 TiUPまたはTiDB Operatorを使用してTiProxyをデプロイすると自動的に設定されます。設定されていない場合は、TiProxyインスタンスの外部IPアドレスが使用されます。 +- デフォルト値: `""` +- ホットリロードのサポート: いいえ +- 他のコンポーネントがこのTiProxyインスタンスに接続するために使用するアドレスを指定します。このアドレスにはホスト名のみが含まれ、ポート番号は含まれません。このアドレスは[`addr`](#addr)のホスト名とは異なる場合があります。例えば、TiProxyのTLS証明書の`Subject Alternative Name`ドメイン名のみが含まれている場合、他のコンポーネントはIP経由でTiProxyに接続できません。この設定項目は、 TiUPまたはTiDB Operatorを使用してTiProxyをデプロイすると自動的に設定されます。設定されていない場合は、TiProxyインスタンスの外部IPアドレスが使用されます。 #### `graceful-wait-before-shutdown` {#graceful-wait-before-shutdown} -- デフォルト値: `0` -- ホットリロードのサポート: はい -- 単位: 秒 -- TiProxyがシャットダウンすると、HTTPステータスは「unhealthy」を返しますが、SQLポートは`graceful-wait-before-shutdown`秒間は新規接続を受け付けます。その後、新規接続は拒否され、クライアントの負荷が増大します。クライアントとTiProxyの間に他のプロキシ（NLBなど）が存在しない場合は、この値を`0`に設定することをお勧めします。 +- デフォルト値: `0` +- ホットリロードのサポート: はい +- 単位: 秒 +- TiProxyがシャットダウンすると、HTTPステータスは「unhealthy」を返しますが、SQLポートは`graceful-wait-before-shutdown`秒間は新規接続を受け付けます。その後、新規接続は拒否され、クライアントの負荷が増大します。クライアントとTiProxyの間に他のプロキシ（NLBなど）が存在しない場合は、この値を`0`に設定することをお勧めします。 #### `graceful-close-conn-timeout` {#graceful-close-conn-timeout} -- デフォルト値: `15` -- ホットリロードのサポート: はい -- 単位: 秒 -- TiProxy がシャットダウンする際、現在のトランザクション（ドレインクライアントとも呼ばれます）が`graceful-close-conn-timeout`秒以内に完了すると、接続が閉じられます。その後、すべての接続が一度に閉じられます。`graceful-close-conn-timeout`は`graceful-wait-before-shutdown`の後に発生します。このタイムアウトは、トランザクションのライフサイクルよりも長く設定することをお勧めします。 +- デフォルト値: `15` +- ホットリロードのサポート: はい +- 単位: 秒 +- TiProxy がシャットダウンする際、現在のトランザクション（ドレインクライアントとも呼ばれます）が`graceful-close-conn-timeout`秒以内に完了すると、接続が閉じられます。その後、すべての接続が一度に閉じられます。`graceful-close-conn-timeout`は`graceful-wait-before-shutdown`の後に発生します。このタイムアウトは、トランザクションのライフサイクルよりも長く設定することをお勧めします。 #### `max-connections` {#max-connections} -- デフォルト値: `0` -- ホットリロードのサポート: はい -- 各 TiProxy インスタンスは最大`max-connections`接続を受け入れることができます。`0`は制限がないことを意味します。 +- デフォルト値: `0` +- ホットリロードのサポート: はい +- 各 TiProxy インスタンスは最大`max-connections`接続を受け入れることができます。`0`は制限がないことを意味します。 #### `conn-buffer-size` {#conn-buffer-size} -- デフォルト値: `32768` -- ホットリロードのサポート: はい、ただし新規接続のみ -- 範囲: `[1024, 16777216]` -- この設定項目では、接続バッファのサイズを指定できます。各接続は、読み取りバッファと書き込みバッファをそれぞれ1つずつ使用します。これはメモリとパフォーマンスのトレードオフです。バッファサイズを大きくするとパフォーマンスは向上しますが、メモリ消費量も増加します。`0`に設定すると、TiProxy はデフォルトのバッファサイズを使用します。 +- デフォルト値: `32768` +- ホットリロードのサポート: はい、ただし新規接続のみ +- 範囲: `[1024, 16777216]` +- この設定項目では、接続バッファのサイズを指定できます。各接続は、読み取りバッファと書き込みバッファをそれぞれ1つずつ使用します。これはメモリとパフォーマンスのトレードオフです。バッファサイズを大きくするとパフォーマンスは向上しますが、メモリ消費量も増加します。`0`に設定すると、TiProxy はデフォルトのバッファサイズを使用します。 #### `pd-addrs` {#pd-addrs} -- デフォルト値: `127.0.0.1:2379` -- ホットリロードのサポート: いいえ -- TiProxyが接続するPDアドレス。TiProxyはPDからTiDBリストを取得することでTiDBインスタンスを検出します。TiUPまたはTiDB OperatorによってTiProxyがデプロイされると、自動的に設定されます。 +- デフォルト値: `127.0.0.1:2379` +- ホットリロードのサポート: いいえ +- TiProxyが接続するPDアドレス。TiProxyはPDからTiDBリストを取得することでTiDBインスタンスを検出します。TiUPまたはTiDB OperatorによってTiProxyがデプロイされると、自動的に設定されます。 #### `proxy-protocol` {#proxy-protocol} -- デフォルト値: `""` -- ホットリロードのサポート: はい、ただし新規接続のみ -- 可能な`"v2"` : `""` -- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)有効にしてください。PROXYプロトコルを有効にすると、TiProxyは実際のクライアントIPアドレスをTiDBに渡すことができます。`"v2"` PROXYプロトコルバージョン2の使用を示し、 `""` PROXYプロトコルの無効化を示します。TiProxyでPROXYプロトコルが有効になっている場合は、TiDBサーバーでも[PROXYプロトコル](/tidb-configuration-file.md#proxy-protocol)有効にする必要があります。 +- デフォルト値: `""` +- ホットリロードのサポート: はい、ただし新規接続のみ +- 可能な`"v2"` : `""` +- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)有効にしてください。PROXYプロトコルを有効にすると、TiProxyは実際のクライアントIPアドレスをTiDBに渡すことができます。`"v2"` PROXYプロトコルバージョン2の使用を示し、 `""` PROXYプロトコルの無効化を示します。TiProxyでPROXYプロトコルが有効になっている場合は、TiDBサーバーでも[PROXYプロトコル](/tidb-configuration-file.md#proxy-protocol)有効にする必要があります。 ### API {#api} @@ -99,16 +99,16 @@ HTTP ゲートウェイの構成。 #### `addr` {#addr} -- デフォルト値: `0.0.0.0:3080` -- ホットリロードのサポート: いいえ -- APIゲートウェイアドレス。`ip:port`を指定できます。 +- デフォルト値: `0.0.0.0:3080` +- ホットリロードのサポート: いいえ +- APIゲートウェイアドレス。`ip:port`を指定できます。 #### `proxy-protocol` {#proxy-protocol} -- デフォルト値: `""` -- ホットリロードのサポート: いいえ -- 可能な`"v2"` : `""` -- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)有効にします。`"v2"` PROXY プロトコル バージョン 2 を使用することを示し、 `""` PROXY プロトコルを無効にすることを示します。 +- デフォルト値: `""` +- ホットリロードのサポート: いいえ +- 可能な`"v2"` : `""` +- ポートの[PROXYプロトコル](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt)有効にします。`"v2"` PROXY プロトコル バージョン 2 を使用することを示し、 `""` PROXY プロトコルを無効にすることを示します。 ### バランス {#balance} @@ -116,17 +116,17 @@ TiProxy の負荷分散ポリシーの構成。 #### `label-name` {#label-name} -- デフォルト値: `""` -- ホットリロードのサポート: はい -- [ラベルベースの負荷分散](/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)を参照してください。 +- デフォルト値: `""` +- ホットリロードのサポート: はい +- [ラベルベースの負荷分散](/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)を参照してください。 #### `policy` {#policy} -- デフォルト値: `resource` -- ホットリロードのサポート: はい -- `location` `connection`値: `resource` -- 負荷分散ポリシーを指定します。各値の意味については、 [TiProxy 負荷分散ポリシー](/tiproxy/tiproxy-load-balance.md#configure-load-balancing-policies)を参照してください。 +- デフォルト値: `resource` +- ホットリロードのサポート: はい +- `location` `connection`値: `resource` +- 負荷分散ポリシーを指定します。各値の意味については、 [TiProxy 負荷分散ポリシー](/tiproxy/tiproxy-load-balance.md#configure-load-balancing-policies)を参照してください。 ### ハ {#ha} @@ -134,9 +134,9 @@ TiProxy の高可用性構成。 #### `virtual-ip` {#virtual-ip} -- デフォルト値: `""` -- ホットリロードのサポート: いいえ -- 仮想IPアドレスをCIDR形式（例： `"10.0.1.10/24"` ）で指定します。クラスタ内で複数のTiProxyインスタンスを同じ仮想IPで構成した場合、一度にバインドできるインスタンスは1つだけです。このインスタンスがオフラインになると、別のTiProxyインスタンスが自動的に仮想IPを引き継ぎます。これにより、クライアントは常に仮想IPを介して利用可能なTiProxyに接続できるようになります。 +- デフォルト値: `""` +- ホットリロードのサポート: いいえ +- 仮想IPアドレスをCIDR形式（例： `"10.0.1.10/24"` ）で指定します。クラスタ内で複数のTiProxyインスタンスを同じ仮想IPで構成した場合、一度にバインドできるインスタンスは1つだけです。このインスタンスがオフラインになると、別のTiProxyインスタンスが自動的に仮想IPを引き継ぎます。これにより、クライアントは常に仮想IPを介して利用可能なTiProxyに接続できるようになります。 以下に構成例を示します。 @@ -151,66 +151,66 @@ TiProxy v1.3.1以降、複数の仮想IPアドレスの設定がサポートさ > **Note:** > -> - 仮想 IP は Linux オペレーティング システムでのみサポートされます。 -> - TiProxy を実行する Linux ユーザーには、IP アドレスをバインドする権限が必要です。 -> - 1 つの TiProxy インスタンスの実際の IP アドレスと仮想 IP アドレスは、同じ CIDR 範囲内にある必要があります。 +> - 仮想 IP は Linux オペレーティング システムでのみサポートされます。 +> - TiProxy を実行する Linux ユーザーには、IP アドレスをバインドする権限が必要です。 +> - 1 つの TiProxy インスタンスの実際の IP アドレスと仮想 IP アドレスは、同じ CIDR 範囲内にある必要があります。 #### `interface` {#interface} -- デフォルト値: `""` -- ホットリロードのサポート: いいえ -- 仮想IPをバインドするネットワークインターフェースを指定します（例： `"eth0"` ）。仮想IPは、 [`ha.virtual-ip`](#virtual-ip)と`ha.interface`両方が設定されている場合にのみTiProxyインスタンスにバインドされます。 +- デフォルト値: `""` +- ホットリロードのサポート: いいえ +- 仮想IPをバインドするネットワークインターフェースを指定します（例： `"eth0"` ）。仮想IPは、 [`ha.virtual-ip`](#virtual-ip)と`ha.interface`両方が設定されている場合にのみTiProxyインスタンスにバインドされます。 ### `labels` {#labels} -- デフォルト値: `{}` -- ホットリロードのサポート: はい -- サーバーのラベルを指定します。例： `{ zone = "us-west-1", dc = "dc1" }` 。 +- デフォルト値: `{}` +- ホットリロードのサポート: はい +- サーバーのラベルを指定します。例： `{ zone = "us-west-1", dc = "dc1" }` 。 ### ログ {#log} #### `level` {#level} -- デフォルト値: `info` -- ホットリロードのサポート: はい -- `info` `error` `panic` `warn` `debug` -- ログレベルを指定します。レベル`panic`の場合、TiProxyはエラー発生時にpanicになります。 +- デフォルト値: `info` +- ホットリロードのサポート: はい +- `info` `error` `panic` `warn` `debug` +- ログレベルを指定します。レベル`panic`の場合、TiProxyはエラー発生時にpanicになります。 #### `encoder` {#encoder} -- デフォルト値: `tidb` -- 以下を指定できます: +- デフォルト値: `tidb` +- 以下を指定できます: - - `tidb` : TiDBで使用されるフォーマット。詳細は[統合ログ形式](https://github.com/tikv/rfcs/blob/master/text/0018-unified-log-format.md)を参照してください。 - - `json` : 構造化された JSON 形式。 - - `console` : 人間が読めるログ形式。 + - `tidb` : TiDBで使用されるフォーマット。詳細は[統合ログ形式](https://github.com/tikv/rfcs/blob/master/text/0018-unified-log-format.md)を参照してください。 + - `json` : 構造化された JSON 形式。 + - `console` : 人間が読めるログ形式。 ### log.ログファイル {#log-log-file} #### `filename` {#filename} -- デフォルト値: `""` -- ホットリロードのサポート: はい -- ログファイルのパス。空でない値を指定すると、ファイルへのログ記録が有効になります。TiProxy がTiUPと共にデプロイされている場合、ファイル名は自動的に設定されます。 +- デフォルト値: `""` +- ホットリロードのサポート: はい +- ログファイルのパス。空でない値を指定すると、ファイルへのログ記録が有効になります。TiProxy がTiUPと共にデプロイされている場合、ファイル名は自動的に設定されます。 #### `max-size` {#max-size} -- デフォルト値: `300` -- ホットリロードのサポート: はい -- 単位: MB -- ログファイルの最大サイズを指定します。ログファイルのサイズがこの制限を超えると、ログファイルはローテーションされます。 +- デフォルト値: `300` +- ホットリロードのサポート: はい +- 単位: MB +- ログファイルの最大サイズを指定します。ログファイルのサイズがこの制限を超えると、ログファイルはローテーションされます。 #### `max-days` {#max-days} -- デフォルト値: `3` -- ホットリロードのサポート: はい -- 古いログファイルを保存する最大日数を指定します。この期間を過ぎると、古いログファイルは削除されます。 +- デフォルト値: `3` +- ホットリロードのサポート: はい +- 古いログファイルを保存する最大日数を指定します。この期間を過ぎると、古いログファイルは削除されます。 #### `max-backups` {#max-backups} -- デフォルト値: `3` -- ホットリロードのサポート: はい -- 保持するログファイルの最大数を指定します。超過したログファイルは自動的に削除されます。 +- デフォルト値: `3` +- ホットリロードのサポート: はい +- 保持するログファイルの最大数を指定します。超過したログファイルは自動的に削除されます。 ### 安全 {#security} @@ -232,27 +232,27 @@ TiProxy v1.3.1以降、複数の仮想IPアドレスの設定がサポートさ TLS オブジェクト フィールド: -- `ca` : CAを指定する -- `cert` : 証明書を指定します -- `key` : 秘密鍵を指定する -- `auto-certs` : 主にテストに使用されます。証明書またはキーが指定されていない場合は証明書を生成します。 -- `skip-ca` : クライアント オブジェクト上の CA を使用した証明書の検証をスキップするか、サーバーオブジェクト上のサーバー側の検証をスキップします。 -- `min-tls-version` : 最小のTLSバージョンを設定します。設定可能な値は`1.0` 、 `1.1` 、 `1.2` 、 `1.3`です。デフォルト値は`1.2`で、v1.2以上のTLSバージョンが許可されます。 -- `rsa-key-size` : `auto-certs`が有効な場合の RSA キー サイズを設定します。 -- `autocert-expire-duration` : 自動生成された証明書のデフォルトの有効期限を設定します。 +- `ca` : CAを指定する +- `cert` : 証明書を指定します +- `key` : 秘密鍵を指定する +- `auto-certs` : 主にテストに使用されます。証明書またはキーが指定されていない場合は証明書を生成します。 +- `skip-ca` : クライアント オブジェクト上の CA を使用した証明書の検証をスキップするか、サーバーオブジェクト上のサーバー側の検証をスキップします。 +- `min-tls-version` : 最小のTLSバージョンを設定します。設定可能な値は`1.0` 、 `1.1` 、 `1.2` 、 `1.3`です。デフォルト値は`1.2`で、v1.2以上のTLSバージョンが許可されます。 +- `rsa-key-size` : `auto-certs`が有効な場合の RSA キー サイズを設定します。 +- `autocert-expire-duration` : 自動生成された証明書のデフォルトの有効期限を設定します。 オブジェクトは名前によってクライアント オブジェクトまたはサーバーオブジェクトに分類されます。 クライアント TLS オブジェクトの場合: -- サーバー証明書の検証をスキップするには、 `ca`または`skip-ca`を設定する必要があります。 -- オプションで、サーバー側のクライアント検証に合格するために`cert`または`key`設定できます。 -- 役に立たないフィールド: 自動証明書。 +- サーバー証明書の検証をスキップするには、 `ca`または`skip-ca`を設定する必要があります。 +- オプションで、サーバー側のクライアント検証に合格するために`cert`または`key`設定できます。 +- 役に立たないフィールド: 自動証明書。 サーバーTLS オブジェクトの場合: -- TLS接続をサポートするには、 `cert` 、 `key` 、または`auto-certs`のいずれかを設定できます。それ以外の場合、TiProxyはTLS接続をサポートしません。 -- オプションとして、 `ca`空でない場合、サーバー側でのクライアント検証が有効になります。クライアントは証明書を提供する必要があります。また、 `skip-ca`が true かつ`ca`空でない場合、サーバーはクライアントが証明書を提供した場合にのみ検証を行います。 +- TLS接続をサポートするには、 `cert` 、 `key` 、または`auto-certs`のいずれかを設定できます。それ以外の場合、TiProxyはTLS接続をサポートしません。 +- オプションとして、 `ca`空でない場合、サーバー側でのクライアント検証が有効になります。クライアントは証明書を提供する必要があります。また、 `skip-ca`が true かつ`ca`空でない場合、サーバーはクライアントが証明書を提供した場合にのみ検証を行います。 #### `cluster-tls` {#cluster-tls} @@ -260,9 +260,9 @@ TLS オブジェクト フィールド: #### `require-backend-tls` {#require-backend-tls} -- デフォルト値: `false` -- ホットリロードのサポート: はい、ただし新規接続のみ -- TiProxyとTiDBサーバー間のTLS接続を必須にします。TiDBサーバーがTLSをサポートしていない場合、クライアントはTiProxyへの接続時にエラーを報告します。 +- デフォルト値: `false` +- ホットリロードのサポート: はい、ただし新規接続のみ +- TiProxyとTiDBサーバー間のTLS接続を必須にします。TiDBサーバーがTLSをサポートしていない場合、クライアントはTiProxyへの接続時にエラーを報告します。 #### `sql-tls` {#sql-tls} diff --git a/tiproxy/tiproxy-deployment-topology.md b/tiproxy/tiproxy-deployment-topology.md index d8776f4165f7f..b893393713116 100644 --- a/tiproxy/tiproxy-deployment-topology.md +++ b/tiproxy/tiproxy-deployment-topology.md @@ -9,9 +9,9 @@ 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)を参照してください。 +- 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)を参照してください。 TiProxy は TiDB の L7 プロキシサーバーであり、接続のバランスを取り、可能な場合はセッションを移行できます。 @@ -37,10 +37,10 @@ TiProxy のテンプレートの詳細については、 [TiProxyトポロジの ### 主なパラメータ {#key-parameters} -- `tiproxy_servers`のインスタンス レベル`"-host"`構成では、ドメイン名ではなく IP のみがサポートされます。 -- TiProxyパラメータの詳細な説明については、 [TiProxy のコンフィグレーション](/tiproxy/tiproxy-configuration.md)を参照してください。 +- `tiproxy_servers`のインスタンス レベル`"-host"`構成では、ドメイン名ではなく IP のみがサポートされます。 +- TiProxyパラメータの詳細な説明については、 [TiProxy のコンフィグレーション](/tiproxy/tiproxy-configuration.md)を参照してください。 > **Note:** > -> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPTiUPコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 -> - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 +> - 設定ファイルに`tidb`ユーザーを手動で作成する必要はありません。TiUPTiUPコンポーネントは、ターゲットマシンに`tidb`ユーザーを自動的に作成します。ユーザーをカスタマイズすることも、制御マシンと同じユーザーを維持することもできます。 +> - デプロイメント ディレクトリを相対パスとして構成すると、クラスターはユーザーのホーム ディレクトリにデプロイされます。 diff --git a/tiproxy/tiproxy-grafana.md b/tiproxy/tiproxy-grafana.md index ddf41c45c25b3..b57056f89e19e 100644 --- a/tiproxy/tiproxy-grafana.md +++ b/tiproxy/tiproxy-grafana.md @@ -13,69 +13,69 @@ Grafanaダッシュボードは、Overview、PD、TiDB、TiKV、TiProxy、Node_e TiProxy には 4 つのパネルグループがあります。これらのパネルに表示されるメトリックは、TiProxy の現在のステータスを示します。 -- **TiProxy-Server** : インスタンス情報。 -- **TiProxy-Query-Summary** : CPS などの SQL クエリ メトリック。 -- **TiProxy-Backend** : TiProxy が接続する可能性のある TiDB ノードに関する情報。 -- **TiProxy-Balance** : 負荷分散メトリック。 +- **TiProxy-Server** : インスタンス情報。 +- **TiProxy-Query-Summary** : CPS などの SQL クエリ メトリック。 +- **TiProxy-Backend** : TiProxy が接続する可能性のある TiDB ノードに関する情報。 +- **TiProxy-Balance** : 負荷分散メトリック。 ## サーバ {#server} -- CPU使用率: 各TiProxyインスタンスのCPU使用率 -- メモリ使用量: 各 TiProxy インスタンスのメモリ使用量 -- 稼働時間: 前回の再起動以降の各 TiProxy インスタンスの実行時間 -- 接続数: 各 TiProxy インスタンスに接続されているクライアントの数 -- 接続作成 OPM: 各 TiProxy インスタンスで 1 分ごとに作成される接続の数 -- 切断OPM：1分ごとの切断理由別の数。切断理由には以下が含まれます。 - - 成功: クライアントは正常に切断されます - - クライアントネットワークの切断：クライアントが切断前に`QUIT`コマンドを送信しない。ネットワークの問題やクライアントのシャットダウンによっても発生する可能性がある。 - - クライアントのハンドシェイク失敗: クライアントがTiProxyとのハンドシェイクに失敗しました - - 認証失敗: TiDBによってアクセスが拒否されました - - SQL エラー: TiDB は他の SQL エラーを返します - - プロキシのシャットダウン: TiProxy はシャットダウンしています - - 不正なパケット: TiProxy は MySQL パケットを解析できません - - バックエンドの取得失敗: TiProxy は接続に利用可能なバックエンドを見つけることができません - - プロキシエラー: その他の TiProxy エラー - - バックエンドネットワークの中断: TiDBの読み取りまたは書き込みに失敗しました。これは、ネットワークの問題、またはTiDBサーバーのシャットダウンが原因である可能性があります。 - - バックエンドのハンドシェイク失敗: TiProxy が TiDBサーバーとのハンドシェイクに失敗しました -- Goroutine 数: 各 TiProxy インスタンス上の Goroutine の数 -- 所有者: 様々なタスクを実行するTiProxyインスタンス。例えば、 `10.24.31.1:3080 - vip` `10.24.31.1:3080`のTiProxyインスタンスが仮想IPにバインドされていることを示します。タスクには以下が含まれます。 - - vip: 仮想IPをバインドする - - metric_reader: TiDBサーバーから監視データを読み取ります +- CPU使用率: 各TiProxyインスタンスのCPU使用率 +- メモリ使用量: 各 TiProxy インスタンスのメモリ使用量 +- 稼働時間: 前回の再起動以降の各 TiProxy インスタンスの実行時間 +- 接続数: 各 TiProxy インスタンスに接続されているクライアントの数 +- 接続作成 OPM: 各 TiProxy インスタンスで 1 分ごとに作成される接続の数 +- 切断OPM：1分ごとの切断理由別の数。切断理由には以下が含まれます。 + - 成功: クライアントは正常に切断されます + - クライアントネットワークの切断：クライアントが切断前に`QUIT`コマンドを送信しない。ネットワークの問題やクライアントのシャットダウンによっても発生する可能性がある。 + - クライアントのハンドシェイク失敗: クライアントがTiProxyとのハンドシェイクに失敗しました + - 認証失敗: TiDBによってアクセスが拒否されました + - SQL エラー: TiDB は他の SQL エラーを返します + - プロキシのシャットダウン: TiProxy はシャットダウンしています + - 不正なパケット: TiProxy は MySQL パケットを解析できません + - バックエンドの取得失敗: TiProxy は接続に利用可能なバックエンドを見つけることができません + - プロキシエラー: その他の TiProxy エラー + - バックエンドネットワークの中断: TiDBの読み取りまたは書き込みに失敗しました。これは、ネットワークの問題、またはTiDBサーバーのシャットダウンが原因である可能性があります。 + - バックエンドのハンドシェイク失敗: TiProxy が TiDBサーバーとのハンドシェイクに失敗しました +- Goroutine 数: 各 TiProxy インスタンス上の Goroutine の数 +- 所有者: 様々なタスクを実行するTiProxyインスタンス。例えば、 `10.24.31.1:3080 - vip` `10.24.31.1:3080`のTiProxyインスタンスが仮想IPにバインドされていることを示します。タスクには以下が含まれます。 + - vip: 仮想IPをバインドする + - metric_reader: TiDBサーバーから監視データを読み取ります ## クエリサマリー {#query-summary} -- 所要時間: 平均、P95、P99 SQL文の実行時間。TiDBサーバーでのSQL文の実行時間も含まれるため、TiDB Grafanaパネルで表示される時間よりも長くなります。 -- インスタンスごとのP99実行時間: 各TiProxyインスタンスのP99ステートメント実行時間 -- バックエンド別のP99実行時間: 各TiDBインスタンスで実行されるステートメントのP99ステートメント実行時間 -- インスタンスごとの CPS: 各 TiProxy インスタンスの 1 秒あたりのコマンド数 -- バックエンド別の CPS: 各 TiDB インスタンスの 1 秒あたりのコマンド数 -- CPS by CMD: SQL コマンドの種類別にグループ化された 1 秒あたりのコマンド数 -- ハンドシェイク期間: クライアントと TiProxy 間のハンドシェイク フェーズの平均、P95、および P99 期間 +- 所要時間: 平均、P95、P99 SQL文の実行時間。TiDBサーバーでのSQL文の実行時間も含まれるため、TiDB Grafanaパネルで表示される時間よりも長くなります。 +- インスタンスごとのP99実行時間: 各TiProxyインスタンスのP99ステートメント実行時間 +- バックエンド別のP99実行時間: 各TiDBインスタンスで実行されるステートメントのP99ステートメント実行時間 +- インスタンスごとの CPS: 各 TiProxy インスタンスの 1 秒あたりのコマンド数 +- バックエンド別の CPS: 各 TiDB インスタンスの 1 秒あたりのコマンド数 +- CPS by CMD: SQL コマンドの種類別にグループ化された 1 秒あたりのコマンド数 +- ハンドシェイク期間: クライアントと TiProxy 間のハンドシェイク フェーズの平均、P95、および P99 期間 ## バランス {#balance} -- バックエンド接続: 各TiDBインスタンスと各TiProxyインスタンス間の接続数。例えば、 `10.24.31.1:6000 | 10.24.31.2:4000` TiProxyインスタンス`10.24.31.1:6000`とTiDBインスタンス`10.24.31.2:4000`間の接続数を示します。 -- セッション移行OPM: 1分ごとに発生したセッション移行の数。TiDBインスタンスが別のインスタンスに移行したセッションを記録します。たとえば、 `succeed: 10.24.31.2:4000 => 10.24.31.3:4000` TiDBインスタンス`10.24.31.2:4000`からTiDBインスタンス`10.24.31.3:4000`に正常に移行されたセッションの数を示します。 -- セッション移行期間: 平均、P95、P99 セッション移行期間。 -- セッション移行の理由: 1分ごとに発生したセッション移行の数とその理由。理由には以下が含まれます。 - - `status` : TiProxy が[ステータスベースの負荷分散](/tiproxy/tiproxy-load-balance.md#status-based-load-balancing)を実行しました。 - - `label` : TiProxy が[ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)を実行しました。 - - `health` : TiProxy が[ヘルスベースの負荷分散](/tiproxy/tiproxy-load-balance.md#health-based-load-balancing)を実行しました。 - - `memory` : TiProxy が[メモリベースの負荷分散](/tiproxy/tiproxy-load-balance.md#memory-based-load-balancing)を実行しました。 - - `cpu` : TiProxy が[CPUベースの負荷分散](/tiproxy/tiproxy-load-balance.md#cpu-based-load-balancing)を実行しました。 - - `location` : TiProxy が[ロケーションベースの負荷分散](/tiproxy/tiproxy-load-balance.md#location-based-load-balancing)を実行しました。 - - `conn` : TiProxy が[接続数ベースの負荷分散](/tiproxy/tiproxy-load-balance.md#connection-count-based-load-balancing)を実行しました。 +- バックエンド接続: 各TiDBインスタンスと各TiProxyインスタンス間の接続数。例えば、 `10.24.31.1:6000 | 10.24.31.2:4000` TiProxyインスタンス`10.24.31.1:6000`とTiDBインスタンス`10.24.31.2:4000`間の接続数を示します。 +- セッション移行OPM: 1分ごとに発生したセッション移行の数。TiDBインスタンスが別のインスタンスに移行したセッションを記録します。たとえば、 `succeed: 10.24.31.2:4000 => 10.24.31.3:4000` TiDBインスタンス`10.24.31.2:4000`からTiDBインスタンス`10.24.31.3:4000`に正常に移行されたセッションの数を示します。 +- セッション移行期間: 平均、P95、P99 セッション移行期間。 +- セッション移行の理由: 1分ごとに発生したセッション移行の数とその理由。理由には以下が含まれます。 + - `status` : TiProxy が[ステータスベースの負荷分散](/tiproxy/tiproxy-load-balance.md#status-based-load-balancing)を実行しました。 + - `label` : TiProxy が[ラベルベースの負荷分散](/tiproxy/tiproxy-load-balance.md#label-based-load-balancing)を実行しました。 + - `health` : TiProxy が[ヘルスベースの負荷分散](/tiproxy/tiproxy-load-balance.md#health-based-load-balancing)を実行しました。 + - `memory` : TiProxy が[メモリベースの負荷分散](/tiproxy/tiproxy-load-balance.md#memory-based-load-balancing)を実行しました。 + - `cpu` : TiProxy が[CPUベースの負荷分散](/tiproxy/tiproxy-load-balance.md#cpu-based-load-balancing)を実行しました。 + - `location` : TiProxy が[ロケーションベースの負荷分散](/tiproxy/tiproxy-load-balance.md#location-based-load-balancing)を実行しました。 + - `conn` : TiProxy が[接続数ベースの負荷分散](/tiproxy/tiproxy-load-balance.md#connection-count-based-load-balancing)を実行しました。 ## バックエンド {#backend} -- バックエンド期間の取得: TiProxy が TiDB インスタンスに接続する平均、p95、p99 期間 -- Pingバックエンド期間: 各TiProxyインスタンス間のネットワークレイテンシー。例えば、 `10.24.31.1:6000 | 10.24.31.2:4000` TiProxyインスタンス`10.24.31.1:6000`とTiDBインスタンス`10.24.31.2:4000`間のネットワークレイテンシーを示します。 -- ヘルスチェックサイクル: TiProxyインスタンスとすべてのTiDBインスタンス間のヘルスチェックサイクルの所要時間。例えば、 `10.24.31.1:6000` TiProxyインスタンス`10.24.31.1:6000`すべてのTiDBインスタンスに対して実行する最新のヘルスチェックの所要時間を示します。この所要時間が3秒を超える場合、TiProxyはバックエンドのTiDBリストを適切なタイミングで更新できない可能性があります。 +- バックエンド期間の取得: TiProxy が TiDB インスタンスに接続する平均、p95、p99 期間 +- Pingバックエンド期間: 各TiProxyインスタンス間のネットワークレイテンシー。例えば、 `10.24.31.1:6000 | 10.24.31.2:4000` TiProxyインスタンス`10.24.31.1:6000`とTiDBインスタンス`10.24.31.2:4000`間のネットワークレイテンシーを示します。 +- ヘルスチェックサイクル: TiProxyインスタンスとすべてのTiDBインスタンス間のヘルスチェックサイクルの所要時間。例えば、 `10.24.31.1:6000` TiProxyインスタンス`10.24.31.1:6000`すべてのTiDBインスタンスに対して実行する最新のヘルスチェックの所要時間を示します。この所要時間が3秒を超える場合、TiProxyはバックエンドのTiDBリストを適切なタイミングで更新できない可能性があります。 ## 渋滞 {#traffic} -- バックエンドからのバイト/秒: 各 TiDB インスタンスから各 TiProxy インスタンスに 1 秒あたりに送信されたデータの量 (バイト単位)。 -- バックエンドからのパケット/秒: 各 TiDB インスタンスから各 TiProxy インスタンスに 1 秒あたりに送信された MySQL パケットの数。 -- バックエンドへのバイト/秒: 各 TiProxy インスタンスから各 TiDB インスタンスに 1 秒あたりに送信されたデータの量 (バイト単位)。 -- バックエンドへのパケット数/秒: 各 TiProxy インスタンスから各 TiDB インスタンスに 1 秒あたりに送信される MySQL パケットの数。 -- クロスロケーション バイト/秒: 各 TiProxy インスタンスから異なる場所にある TiDB インスタンスに 1 秒あたりに送信されるデータの量 (バイト単位)。 +- バックエンドからのバイト/秒: 各 TiDB インスタンスから各 TiProxy インスタンスに 1 秒あたりに送信されたデータの量 (バイト単位)。 +- バックエンドからのパケット/秒: 各 TiDB インスタンスから各 TiProxy インスタンスに 1 秒あたりに送信された MySQL パケットの数。 +- バックエンドへのバイト/秒: 各 TiProxy インスタンスから各 TiDB インスタンスに 1 秒あたりに送信されたデータの量 (バイト単位)。 +- バックエンドへのパケット数/秒: 各 TiProxy インスタンスから各 TiDB インスタンスに 1 秒あたりに送信される MySQL パケットの数。 +- クロスロケーション バイト/秒: 各 TiProxy インスタンスから異なる場所にある TiDB インスタンスに 1 秒あたりに送信されるデータの量 (バイト単位)。 diff --git a/tiproxy/tiproxy-load-balance.md b/tiproxy/tiproxy-load-balance.md index 163f57e675598..b5d843ba0f154 100644 --- a/tiproxy/tiproxy-load-balance.md +++ b/tiproxy/tiproxy-load-balance.md @@ -9,13 +9,13 @@ TiProxy v1.0.0 は、TiDB サーバーに対してステータスベースおよ デフォルトでは、TiProxy は次の優先順位でこれらのポリシーを適用します。 -1. ステータスベースの負荷分散: TiDBサーバーがシャットダウンすると、TiProxy はその TiDBサーバーからオンラインの TiDBサーバーに接続を移行します。 -2. ラベルベースの負荷分散: TiProxy は、TiProxy インスタンスと同じラベルを共有する TiDB サーバーへのルーティング要求を優先し、コンピューティングレイヤーでのリソースの分離を可能にします。 -3. ヘルスベースの負荷分散: TiDBサーバーのヘルスが異常な場合、TiProxy はその TiDBサーバーから正常な TiDBサーバーに接続を移行します。 -4. メモリベースの負荷分散: TiDBサーバーがメモリ不足 (OOM) になる危険がある場合、TiProxy はその TiDBサーバーからメモリ使用量の少ない TiDBサーバーに接続を移行します。 -5. CPU ベースの負荷分散: TiDBサーバーの CPU 使用率が他の TiDB サーバーよりもはるかに高い場合、TiProxy はその TiDBサーバーから CPU 使用率の低い TiDBサーバーに接続を移行します。 -6. ロケーションベースの負荷分散: TiProxy は、TiProxy に地理的に最も近い TiDBサーバーへのルーティング要求を優先します。 -7. 接続数ベースの負荷分散: TiDBサーバーの接続数が他の TiDB サーバーよりも大幅に多い場合、TiProxy はその TiDBサーバーから接続数の少ない TiDBサーバーに接続を移行します。 +1. ステータスベースの負荷分散: TiDBサーバーがシャットダウンすると、TiProxy はその TiDBサーバーからオンラインの TiDBサーバーに接続を移行します。 +2. ラベルベースの負荷分散: TiProxy は、TiProxy インスタンスと同じラベルを共有する TiDB サーバーへのルーティング要求を優先し、コンピューティングレイヤーでのリソースの分離を可能にします。 +3. ヘルスベースの負荷分散: TiDBサーバーのヘルスが異常な場合、TiProxy はその TiDBサーバーから正常な TiDBサーバーに接続を移行します。 +4. メモリベースの負荷分散: TiDBサーバーがメモリ不足 (OOM) になる危険がある場合、TiProxy はその TiDBサーバーからメモリ使用量の少ない TiDBサーバーに接続を移行します。 +5. CPU ベースの負荷分散: TiDBサーバーの CPU 使用率が他の TiDB サーバーよりもはるかに高い場合、TiProxy はその TiDBサーバーから CPU 使用率の低い TiDBサーバーに接続を移行します。 +6. ロケーションベースの負荷分散: TiProxy は、TiProxy に地理的に最も近い TiDBサーバーへのルーティング要求を優先します。 +7. 接続数ベースの負荷分散: TiDBサーバーの接続数が他の TiDB サーバーよりも大幅に多い場合、TiProxy はその TiDBサーバーから接続数の少ない TiDBサーバーに接続を移行します。 負荷分散ポリシーの優先順位を調整するには、 [負荷分散ポリシーを構成する](#configure-load-balancing-policies)を参照してください。 @@ -29,20 +29,20 @@ TiProxy は、SQL ポートとステータス ポートを使用して、TiDBサ ラベルベースの負荷分散を有効にするには、次の操作を行う必要があります。 -- 一致するラベル名を[`balance.label-name`](/tiproxy/tiproxy-configuration.md#label-name)で指定します。 -- TiProxy で[`labels`](/tiproxy/tiproxy-configuration.md#labels)構成項目を構成します。 -- TiDB サーバーで[`labels`](/tidb-configuration-file.md#labels)構成項目を構成します。 +- 一致するラベル名を[`balance.label-name`](/tiproxy/tiproxy-configuration.md#label-name)で指定します。 +- TiProxy で[`labels`](/tiproxy/tiproxy-configuration.md#labels)構成項目を構成します。 +- TiDB サーバーで[`labels`](/tidb-configuration-file.md#labels)構成項目を構成します。 設定後、TiProxy は`balance.label-name`で指定されたラベル名を使用して、一致するラベル値を持つ TiDB サーバーへの接続をルーティングします。 トランザクションとBIの両方のワークロードを処理するアプリケーションを考えてみましょう。これらのワークロードが互いに干渉しないようにするには、クラスターを次のように構成します。 -1. TiProxy で[`balance.label-name`](/tiproxy/tiproxy-configuration.md#label-name)を`"app"`に設定すると、TiDB サーバーはラベル名`"app"`によって照合され、接続は一致するラベル値を持つ TiDB サーバーにルーティングされます。 -2. 少なくとも 2 つの TiProxy インスタンスをデプロイ。トランザクション ワークロードに使用する TiProxy インスタンスを[`labels`](/tiproxy/tiproxy-configuration.md#labels)で`{"app": "Order"}`に設定し、BI ワークロードに使用するインスタンスを[`labels`](/tiproxy/tiproxy-configuration.md#labels)で`{"app": "BI"}`に設定します。 -3. オプション：高可用性を実現するには、少なくとも4つのTiProxyインスタンスを導入し、ワークロードごとに異なる仮想IPアドレスを設定します。例えば、トランザクションワークロード用のTiProxyインスタンス2つを仮想IP `10.0.1.10/24`に設定し、BIワークロード用のインスタンス2つを仮想IP `10.0.1.20/24`に設定します。この機能を使用するには、TiProxy v1.3.1以降が必要です。 -4. TiDB インスタンスを 2 つのグループに分割し、それぞれ[`labels`](/tidb-configuration-file.md#labels)設定します。一方のグループに`"app": "Order"`ラベルを追加し、もう一方のグループに`"app": "BI"`ラベルを追加します。 -5. オプション:ストレージレイヤーの分離の場合は、 [配置ルール](/configure-placement-rules.md)または[リソース管理](/tidb-resource-control-ru-groups.md)構成します。 -6. 仮想IPが設定されている場合、トランザクションクライアントとBIクライアントはそれぞれ2つの仮想IPアドレスに接続します。仮想IPが設定されていない場合、トランザクションクライアントとBIクライアントはそれぞれ2つのTiProxyアドレスに接続します。 +1. TiProxy で[`balance.label-name`](/tiproxy/tiproxy-configuration.md#label-name)を`"app"`に設定すると、TiDB サーバーはラベル名`"app"`によって照合され、接続は一致するラベル値を持つ TiDB サーバーにルーティングされます。 +2. 少なくとも 2 つの TiProxy インスタンスをデプロイ。トランザクション ワークロードに使用する TiProxy インスタンスを[`labels`](/tiproxy/tiproxy-configuration.md#labels)で`{"app": "Order"}`に設定し、BI ワークロードに使用するインスタンスを[`labels`](/tiproxy/tiproxy-configuration.md#labels)で`{"app": "BI"}`に設定します。 +3. オプション：高可用性を実現するには、少なくとも4つのTiProxyインスタンスを導入し、ワークロードごとに異なる仮想IPアドレスを設定します。例えば、トランザクションワークロード用のTiProxyインスタンス2つを仮想IP `10.0.1.10/24`に設定し、BIワークロード用のインスタンス2つを仮想IP `10.0.1.20/24`に設定します。この機能を使用するには、TiProxy v1.3.1以降が必要です。 +4. TiDB インスタンスを 2 つのグループに分割し、それぞれ[`labels`](/tidb-configuration-file.md#labels)設定します。一方のグループに`"app": "Order"`ラベルを追加し、もう一方のグループに`"app": "BI"`ラベルを追加します。 +5. オプション:ストレージレイヤーの分離の場合は、 [配置ルール](/configure-placement-rules.md)または[リソース管理](/tidb-resource-control-ru-groups.md)構成します。 +6. 仮想IPが設定されている場合、トランザクションクライアントとBIクライアントはそれぞれ2つの仮想IPアドレスに接続します。仮想IPが設定されていない場合、トランザクションクライアントとBIクライアントはそれぞれ2つのTiProxyアドレスに接続します。 ラベルベースの負荷分散 @@ -106,8 +106,8 @@ TiProxyは、TiDBサーバーの健全性を判断します。他のサーバー このポリシーは、次のシナリオに適しています。 -- TiDBサーバーはTiKV へのリクエストの送信に頻繁に失敗し、SQL 実行の失敗が頻繁に発生します。 -- TiDBサーバーはPD へのリクエストの送信に頻繁に失敗し、SQL 実行の失敗が頻繁に発生します。 +- TiDBサーバーはTiKV へのリクエストの送信に頻繁に失敗し、SQL 実行の失敗が頻繁に発生します。 +- TiDBサーバーはPD へのリクエストの送信に頻繁に失敗し、SQL 実行の失敗が頻繁に発生します。 ## メモリベースの負荷分散 {#memory-based-load-balancing} @@ -117,9 +117,9 @@ TiDBサーバーがOOMの危険にさらされている場合、TiProxyはその このポリシーには次の制限があります。 -- TiDBサーバーのメモリ使用量が急激に増加し、30 秒以内に OOM に達した場合、TiProxy は OOM のリスクを時間内に検出できず、接続が終了する可能性があります。 -- TiProxyは、クライアント接続を切断することなく維持することを目的としており、TiDBサーバーのメモリ使用量を削減してOOMを回避することを目的としているわけではありません。そのため、TiDBサーバーは依然としてOOMに遭遇する可能性があります。 -- このポリシーはTiDBサーバーv8.0.0以降のバージョンにのみ適用されます。それより前のバージョンのTiDBサーバーでは、このポリシーは適用されません。 +- TiDBサーバーのメモリ使用量が急激に増加し、30 秒以内に OOM に達した場合、TiProxy は OOM のリスクを時間内に検出できず、接続が終了する可能性があります。 +- TiProxyは、クライアント接続を切断することなく維持することを目的としており、TiDBサーバーのメモリ使用量を削減してOOMを回避することを目的としているわけではありません。そのため、TiDBサーバーは依然としてOOMに遭遇する可能性があります。 +- このポリシーはTiDBサーバーv8.0.0以降のバージョンにのみ適用されます。それより前のバージョンのTiDBサーバーでは、このポリシーは適用されません。 ## CPUベースの負荷分散 {#cpu-based-load-balancing} @@ -127,9 +127,9 @@ TiProxyはTiDBサーバーのCPU使用率を照会し、CPU使用率の高いTiD このポリシーは、次のシナリオに適しています。 -- バックグラウンド タスク ( `ANALYZE`など) が大量の CPU リソースを消費すると、これらのタスクを実行する TiDB サーバーの CPU 使用率が高くなります。 -- 異なる接続でのワークロードが大きく異なる場合、各 TiDBサーバーの接続数が似ていても、CPU 使用率が大幅に異なる可能性があります。 -- クラスター内の TiDB サーバーの CPU リソース構成が異なる場合、接続数が均衡していても、実際の CPU 使用率は不均衡になる可能性があります。 +- バックグラウンド タスク ( `ANALYZE`など) が大量の CPU リソースを消費すると、これらのタスクを実行する TiDB サーバーの CPU 使用率が高くなります。 +- 異なる接続でのワークロードが大きく異なる場合、各 TiDBサーバーの接続数が似ていても、CPU 使用率が大幅に異なる可能性があります。 +- クラスター内の TiDB サーバーの CPU リソース構成が異なる場合、接続数が均衡していても、実際の CPU 使用率は不均衡になる可能性があります。 ## ロケーションベースの負荷分散 {#location-based-load-balancing} @@ -137,15 +137,15 @@ TiProxy は、TiProxy サーバーと TiDB サーバーの場所に基づいて このポリシーは、次のシナリオに適しています。 -- TiDB クラスターがクラウド内のアベイラビリティ ゾーン全体に展開されている場合、TiProxy と TiDB サーバー間のアベイラビリティ ゾーン間のトラフィック コストを削減するために、TiProxy は同じアベイラビリティ ゾーン内の TiDB サーバーへのルーティング要求を優先します。 -- TiDB クラスターがデータ センター全体に展開されている場合、TiProxy と TiDB サーバー間のネットワークレイテンシーを削減するために、TiProxy は同じデータ センター内の TiDB サーバーへのルーティング要求を優先します。 +- TiDB クラスターがクラウド内のアベイラビリティ ゾーン全体に展開されている場合、TiProxy と TiDB サーバー間のアベイラビリティ ゾーン間のトラフィック コストを削減するために、TiProxy は同じアベイラビリティ ゾーン内の TiDB サーバーへのルーティング要求を優先します。 +- TiDB クラスターがデータ センター全体に展開されている場合、TiProxy と TiDB サーバー間のネットワークレイテンシーを削減するために、TiProxy は同じデータ センター内の TiDB サーバーへのルーティング要求を優先します。 デフォルトでは、このポリシーの優先度は、ヘルスベース、メモリベース、CPUベースの負荷分散ポリシーよりも低くなっています。優先度を[`policy`](/tiproxy/tiproxy-configuration.md#policy)から`location`に設定することで、優先度を上げることができます。可用性とパフォーマンスを維持するには、少なくとも3台のTiDBサーバーを同じ場所に配置することを推奨します。 TiProxyは、ラベル`zone`に基づいて自身と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サーバーの設定項目[`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)を参照してください。 @@ -193,16 +193,16 @@ TiProxyは、接続数の多いTiDBサーバーから接続数の少ないサー 通常、TiProxy は CPU 使用率に基づいて TiDB サーバーの負荷を特定します。このポリシーは通常、以下のシナリオで有効になります。 -- TiDB クラスターの起動直後は、すべての TiDB サーバーの CPU 使用率は 0 に近くなります。この場合、このポリシーにより、起動時の負荷の不均衡が防止されます。 -- [CPUベースの負荷分散](#cpu-based-load-balancing)が有効になっていない場合、このポリシーは負荷分散を保証します。 +- TiDB クラスターの起動直後は、すべての TiDB サーバーの CPU 使用率は 0 に近くなります。この場合、このポリシーにより、起動時の負荷の不均衡が防止されます。 +- [CPUベースの負荷分散](#cpu-based-load-balancing)が有効になっていない場合、このポリシーは負荷分散を保証します。 ## 負荷分散ポリシーを構成する {#configure-load-balancing-policies} TiProxy では、 [`policy`](/tiproxy/tiproxy-configuration.md#policy)構成項目を通じて負荷分散ポリシーの組み合わせと優先順位を設定できます。 -- `resource` : リソース優先度ポリシーは、ステータス、ラベル、ヘルス、メモリ、CPU、場所、接続数の優先順位に基づいて負荷分散を実行します。 -- `location` : 場所の優先順位ポリシーは、ステータス、ラベル、場所、正常性、メモリ、CPU、接続数の優先順位に基づいて負荷分散を実行します。 -- `connection` : 最小接続数ポリシーは、ステータス、ラベル、接続数の優先順位に基づいて負荷分散を実行します。 +- `resource` : リソース優先度ポリシーは、ステータス、ラベル、ヘルス、メモリ、CPU、場所、接続数の優先順位に基づいて負荷分散を実行します。 +- `location` : 場所の優先順位ポリシーは、ステータス、ラベル、場所、正常性、メモリ、CPU、接続数の優先順位に基づいて負荷分散を実行します。 +- `connection` : 最小接続数ポリシーは、ステータス、ラベル、接続数の優先順位に基づいて負荷分散を実行します。 ## その他のリソース {#more-resources} diff --git a/tiproxy/tiproxy-overview.md b/tiproxy/tiproxy-overview.md index d44ae8ad06e2c..aede63092422d 100644 --- a/tiproxy/tiproxy-overview.md +++ b/tiproxy/tiproxy-overview.md @@ -62,8 +62,8 @@ graph TD 接続移行は通常、次のようなシナリオで発生します。 -- TiDBサーバーがスケールイン、ローリングアップグレード、またはローリング再起動を実行する場合、TiProxyはオフラインになりそうなTiDBサーバーから他のTiDBサーバーに接続を移行して、クライアント接続を維持することができます。 -- TiDBサーバーがスケールアウトを実行する際、TiProxyは既存の接続を新しいTiDBサーバーに移行することで、クライアント接続プールをリセットすることなくリアルタイムの負荷分散を実現できます。 +- TiDBサーバーがスケールイン、ローリングアップグレード、またはローリング再起動を実行する場合、TiProxyはオフラインになりそうなTiDBサーバーから他のTiDBサーバーに接続を移行して、クライアント接続を維持することができます。 +- TiDBサーバーがスケールアウトを実行する際、TiProxyは既存の接続を新しいTiDBサーバーに移行することで、クライアント接続プールをリセットすることなくリアルタイムの負荷分散を実現できます。 ### フェイルオーバー {#failover} @@ -81,16 +81,16 @@ TiProxyは[TiUP](https://github.com/pingcap/tiup)、[TiDB Operator](https://gith 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)を参照してください。 +- 接続の維持：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)を参照してください。 TiProxyは、以下のシナリオには適していません。 -- パフォーマンスに敏感: TiProxy のパフォーマンスは HAProxy や他のロードバランサーよりも低いため、TiProxy を使用する場合は、同様のパフォーマンスレベルを維持するためにより多くの CPU リソースを確保する必要があります。詳細については、 [TiProxyのパフォーマンステストレポート](/tiproxy/tiproxy-performance-test.md)を参照してください。 -- コストに敏感な場合：TiDBクラスタがハードウェアロードバランサー、仮想IP、またはKubernetesが提供するロードバランサーを使用している場合、TiProxyを追加するとコストが増加します。さらに、クラウド上のアベイラビリティゾーンにまたがってTiDBクラスタをデプロイする場合、TiProxyを追加するとアベイラビリティゾーン間のトラフィックコストも増加します。 -- 予期せぬTiDBサーバーのダウンタイムに対するフェイルオーバー：TiProxyは、TiDBサーバーがオフラインになった場合、または計画通りに再起動された場合にのみ、クライアント接続を維持できます。TiDBサーバーが予期せずオフラインになった場合、接続は切断されます。 +- パフォーマンスに敏感: TiProxy のパフォーマンスは HAProxy や他のロードバランサーよりも低いため、TiProxy を使用する場合は、同様のパフォーマンスレベルを維持するためにより多くの CPU リソースを確保する必要があります。詳細については、 [TiProxyのパフォーマンステストレポート](/tiproxy/tiproxy-performance-test.md)を参照してください。 +- コストに敏感な場合：TiDBクラスタがハードウェアロードバランサー、仮想IP、またはKubernetesが提供するロードバランサーを使用している場合、TiProxyを追加するとコストが増加します。さらに、クラウド上のアベイラビリティゾーンにまたがってTiDBクラスタをデプロイする場合、TiProxyを追加するとアベイラビリティゾーン間のトラフィックコストも増加します。 +- 予期せぬTiDBサーバーのダウンタイムに対するフェイルオーバー：TiProxyは、TiDBサーバーがオフラインになった場合、または計画通りに再起動された場合にのみ、クライアント接続を維持できます。TiDBサーバーが予期せずオフラインになった場合、接続は切断されます。 TiProxyが適しているシナリオではTiProxyを使用し、アプリケーションのパフォーマンスが重要な場合はHAProxyなどの他のプロキシを使用することをお勧めします。 @@ -104,14 +104,14 @@ 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)を参照してください。 +- TiDB Operatorを使用して TiProxy をデプロイするには、 [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-tiproxy)ドキュメントを参照してください。 +- TiUPを使用して TiProxy をローカルにすばやくデプロイするには、 [TiProxyをデプロイ](/tiup/tiup-playground.md#deploy-tiproxy)を参照してください。 ### TiProxyでクラスターを作成する {#create-a-cluster-with-tiproxy} 以下の手順では、新しいクラスタを作成する際に TiProxy をデプロイする方法について説明します。 -1. TiDBインスタンスを設定します。 +1. TiDBインスタンスを設定します。 TiProxyを使用する場合は、TiDB用に[`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)を設定する必要があります。この値は、アプリケーションの最長トランザクションの継続時間より少なくとも10秒長く設定する必要があります。これにより、TiDBサーバーがオフラインになったときにクライアント接続が中断されるのを防ぎます。トランザクションの継続時間は[TiDB監視ダッシュボードのトランザクションメトリクス](/grafana-tidb-dashboard.md#transaction)で確認できます。詳細については、 [制限事項](#limitations)を参照してください。 @@ -123,15 +123,15 @@ TiProxyが適しているシナリオではTiProxyを使用し、アプリケー graceful-wait-before-shutdown: 30 ``` -2. TiProxyインスタンスを設定します。 +2. TiProxyインスタンスを設定します。 TiProxyの高い可用性を確保するためには、少なくとも2つのTiProxyインスタンスをデプロイし、 [`ha.virtual-ip`](/tiproxy/tiproxy-configuration.md#virtual-ip)と[`ha.interface`](/tiproxy/tiproxy-configuration.md#interface)を設定して仮想IPを構成し、トラフィックを利用可能な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)を参照してください。 - - トポロジ構成ファイルでTiProxyのバージョンを指定することをお勧めします。これにより、TiDBクラスタをアップグレードするためにコマンド[`tiup cluster upgrade`](/tiup/tiup-component-cluster-upgrade.md)を実行した際に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)を参照してください。 + - トポロジ構成ファイルで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)を参照してください。 @@ -155,11 +155,11 @@ TiProxyが適しているシナリオではTiProxyを使用し、アプリケー status_port: 3080 ``` -3. クラスターを起動します。 +3. クラスターを起動します。 TiUPを使用してクラスターを起動するには、 [TiUPドキュメント](/tiup/tiup-documentation-guide.md)を参照してください。 -4. TiProxyに接続します。 +4. TiProxyに接続します。 クラスタがデプロイされると、TiDBサーバーポートとTiProxyポートが同時に公開されます。クライアントはTiDBサーバーに直接接続するのではなく、TiProxyポートに接続する必要があります。 @@ -167,7 +167,7 @@ TiProxyが適しているシナリオではTiProxyを使用し、アプリケー TiProxyがデプロイされていないクラスターの場合、TiProxyインスタンスをスケールアウトすることでTiProxyを有効にできます。 -1. TiProxyインスタンスを設定します。 +1. TiProxyインスタンスを設定します。 TiProxyを別のトポロジーファイルで設定します。例: `tiproxy.toml` : @@ -189,7 +189,7 @@ TiProxyがデプロイされていないクラスターの場合、TiProxyイン status_port: 3080 ``` -2. TiProxyをスケールアウトする。 +2. TiProxyをスケールアウトする。 TiProxyインスタンスをスケールアウトするには、 [`tiup cluster scale-out`](/tiup/tiup-component-cluster-scale-out.md)コマンドを使用します。例： @@ -199,7 +199,7 @@ TiProxyがデプロイされていないクラスターの場合、TiProxyイン TiProxyをスケールアウトすると、 TiUPはTiDB用に自己署名証明書[`security.session-token-signing-cert`](/tidb-configuration-file.md#session-token-signing-cert-new-in-v640)と[`security.session-token-signing-key`](/tidb-configuration-file.md#session-token-signing-key-new-in-v640)自動的に構成します。この証明書は接続の移行に使用されます。 -3. TiDBの設定を変更してください。 +3. TiDBの設定を変更してください。 TiProxyを使用する場合は、TiDB用に[`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)を設定する必要があります。この値は、TiDBサーバーがオフラインになったときにクライアント接続が中断されないように、アプリケーションの最長トランザクションの継続時間より少なくとも10秒長くする必要があります。トランザクションの継続時間は[TiDB監視ダッシュボードのトランザクションメトリクス](/grafana-tidb-dashboard.md#transaction)で確認できます。詳細については、 [制限事項](#limitations)を参照してください。 @@ -211,7 +211,7 @@ TiProxyがデプロイされていないクラスターの場合、TiProxyイン graceful-wait-before-shutdown: 30 ``` -4. TiDBの設定を再読み込みしてください。 +4. TiDBの設定を再読み込みしてください。 TiDBは自己署名証明書と`graceful-wait-before-shutdown`で構成されているため、それらを有効にするには[`tiup cluster reload`](/tiup/tiup-component-cluster-reload.md)コマンドを使用して構成を再読み込みする必要があります。構成を再読み込みすると、TiDBはローリング再起動を実行し、クライアント接続が切断されることに注意してください。 @@ -219,7 +219,7 @@ TiProxyがデプロイされていないクラスターの場合、TiProxyイン tiup cluster reload -R tidb ``` -5. TiProxyに接続します。 +5. TiProxyに接続します。 TiProxyを有効にすると、クライアントはTiDBサーバーポートではなく、TiProxyポートに接続するようになります。 @@ -251,48 +251,48 @@ tiup cluster upgrade --tiproxy-version **Note:** > - > - TiProxy は、既存の接続と新しく作成された接続を含むすべての接続のトラフィックをキャプチャします。 - > - TiProxy プライマリ/セカンダリ モードで、プライマリ TiProxy インスタンスに接続します。 - > - TiProxy が仮想 IP で構成されている場合は、仮想 IP アドレスに接続することをお勧めします。 - > - TiProxyのCPU使用率が高いほど、トラフィックキャプチャによるQPSへの影響が大きくなります。本番クラスタへの影響を軽減するには、CPU容量の少なくとも30%を予約することをお勧めします。これにより、平均QPSが約3%低下します。詳細なパフォーマンスデータについては、 [トラフィックキャプチャテスト](/tiproxy/tiproxy-performance-test.md#traffic-capture-test)ご覧ください。 - > - TiProxyはトラフィックを再度キャプチャする際に、以前のキャプチャファイルを自動的に削除しません。手動で削除する必要があります。 + > - TiProxy は、既存の接続と新しく作成された接続を含むすべての接続のトラフィックをキャプチャします。 + > - TiProxy プライマリ/セカンダリ モードで、プライマリ TiProxy インスタンスに接続します。 + > - TiProxy が仮想 IP で構成されている場合は、仮想 IP アドレスに接続することをお勧めします。 + > - TiProxyのCPU使用率が高いほど、トラフィックキャプチャによるQPSへの影響が大きくなります。本番クラスタへの影響を軽減するには、CPU容量の少なくとも30%を予約することをお勧めします。これにより、平均QPSが約3%低下します。詳細なパフォーマンスデータについては、 [トラフィックキャプチャテスト](/tiproxy/tiproxy-performance-test.md#traffic-capture-test)ご覧ください。 + > - TiProxyはトラフィックを再度キャプチャする際に、以前のキャプチャファイルを自動的に削除しません。手動で削除する必要があります。 たとえば、次のコマンドは、 `10.0.1.10:3080`の TiProxy インスタンスに接続し、1 時間のトラフィックをキャプチャし、それを TiProxy インスタンスの`/tmp/traffic`ディレクトリに保存します。 @@ -61,9 +61,9 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア 詳細については[`tiproxyctl traffic capture`](/tiproxy/tiproxy-command-line-flags.md#traffic-capture)を参照してください。 -3. トラフィック ファイル ディレクトリをテスト クラスターの TiProxy インスタンスにコピーします。 +3. トラフィック ファイル ディレクトリをテスト クラスターの TiProxy インスタンスにコピーします。 -4. [`tiproxyctl traffic replay`](/tiproxy/tiproxy-command-line-flags.md#traffic-replay)を使用してテスト クラスターの TiProxy インスタンスに接続し、トラフィックの再生を開始します。 +4. [`tiproxyctl traffic replay`](/tiproxy/tiproxy-command-line-flags.md#traffic-replay)を使用してテスト クラスターの TiProxy インスタンスに接続し、トラフィックの再生を開始します。 デフォルトでは、SQL ステートメントは本番クラスターと同じ速度で実行され、各データベース接続は本番クラスター内の接続に対応して、本番負荷をシミュレートし、一貫したトランザクション実行順序を確保します。 @@ -77,20 +77,20 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア 詳細については[`tiproxyctl traffic replay`](/tiproxy/tiproxy-command-line-flags.md#traffic-replay)を参照してください。 -5. リプレイレポートを確認する。 +5. リプレイレポートを確認する。 再生が完了すると、レポートはテストクラスターのデータベース`tiproxy_traffic_replay`に保存されます。このデータベースには、テーブル`fail`と`other_errors` 2つのテーブルが含まれています。 `fail`テーブルには、次のフィールドを持つ失敗した SQL ステートメントが格納されます。 - - `cmd_type` : 失敗したコマンドのタイプ。例: `Query` (通常のステートメントを実行)、 `Prepare` (ステートメントを準備)、 `Execute` (プリペアドステートメントを実行)。 - - `digest` : 失敗した SQL ステートメントのダイジェスト。 - - `sample_stmt` : ステートメントが最初に失敗したときの SQL テキスト。 - - `sample_err_msg` : SQL ステートメントが失敗した場合のエラー メッセージ。 - - `sample_conn_id` : SQL文のトラフィックファイルに記録された接続ID。これを使用して、トラフィックファイル内の実行コンテキストを表示できます。 - - `sample_capture_time` : トラフィックファイルに記録されたSQL文の実行時間。これを使用して、トラフィックファイル内の実行コンテキストを確認できます。 - - `sample_replay_time` : 再生中にSQL文が失敗した時刻。これを使用して、TiDBログファイルでエラー情報を確認できます。 - - `count` : SQL ステートメントが失敗した回数。 + - `cmd_type` : 失敗したコマンドのタイプ。例: `Query` (通常のステートメントを実行)、 `Prepare` (ステートメントを準備)、 `Execute` (プリペアドステートメントを実行)。 + - `digest` : 失敗した SQL ステートメントのダイジェスト。 + - `sample_stmt` : ステートメントが最初に失敗したときの SQL テキスト。 + - `sample_err_msg` : SQL ステートメントが失敗した場合のエラー メッセージ。 + - `sample_conn_id` : SQL文のトラフィックファイルに記録された接続ID。これを使用して、トラフィックファイル内の実行コンテキストを表示できます。 + - `sample_capture_time` : トラフィックファイルに記録されたSQL文の実行時間。これを使用して、トラフィックファイル内の実行コンテキストを確認できます。 + - `sample_replay_time` : 再生中にSQL文が失敗した時刻。これを使用して、TiDBログファイルでエラー情報を確認できます。 + - `count` : SQL ステートメントが失敗した回数。 以下はテーブル`fail`の出力例です。 @@ -112,10 +112,10 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア `other_errors`テーブルには、ネットワーク エラーやデータベース接続エラーなどの予期しないエラーが次のフィールドに格納されます。 - - `err_type` : エラーの種類。簡潔なエラーメッセージとして表示されます。例: `i/o timeout` 。 - - `sample_err_msg` : エラーが最初に発生したときの完全なエラー メッセージ。 - - `sample_replay_time` : 再生中にエラーが発生した時刻。これを使用して、TiDBログファイルでエラー情報を確認できます。 - - `count` : このエラーの発生回数。 + - `err_type` : エラーの種類。簡潔なエラーメッセージとして表示されます。例: `i/o timeout` 。 + - `sample_err_msg` : エラーが最初に発生したときの完全なエラー メッセージ。 + - `sample_replay_time` : 再生中にエラーが発生した時刻。これを使用して、TiDBログファイルでエラー情報を確認できます。 + - `count` : このエラーの発生回数。 以下はテーブル`other_errors`の出力例です。 @@ -133,9 +133,9 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア > **Note:** > - > - `tiproxy_traffic_replay`のテーブルスキーマは将来のバージョンで変更される可能性があります。アプリケーションやツールの開発において、 `tiproxy_traffic_replay`のデータを直接読み取ることは推奨されません。 - > - リプレイでは、接続間のトランザクション実行順序がキャプチャシーケンスと完全に一致することが保証されません。そのため、誤ったエラーレポートが生成される可能性があります。 - > - TiProxyはトラフィックを再生する際に、以前の再生レポートを自動的に削除しません。手動で削除する必要があります。 + > - `tiproxy_traffic_replay`のテーブルスキーマは将来のバージョンで変更される可能性があります。アプリケーションやツールの開発において、 `tiproxy_traffic_replay`のデータを直接読み取ることは推奨されません。 + > - リプレイでは、接続間のトランザクション実行順序がキャプチャシーケンスと完全に一致することが保証されません。そのため、誤ったエラーレポートが生成される可能性があります。 + > - TiProxyはトラフィックを再生する際に、以前の再生レポートを自動的に削除しません。手動で削除する必要があります。 ## テストスループット {#test-throughput} @@ -184,10 +184,10 @@ tiproxyctl traffic cancel --host 10.0.1.10 --port 3080 ## 制限事項 {#limitations} -- TiProxyは、TiProxyによってキャプチャされたトラフィックファイルの再生のみをサポートしており、他のファイル形式はサポートしていません。そのため、まずはTiProxyを使用して本番クラスタからトラフィックをキャプチャしてください。 -- TiProxyトラフィックの再生はSQLタイプのフィルタリングをサポートしておらず、DMLおよびDDL文が再生されます。そのため、再度再生する前に、クラスターデータを再生前の状態に復元する必要があります。 -- TiProxy トラフィック再生では、トラフィックの再生に同じユーザー名が使用されるため、テスト[リソース管理](/tidb-resource-control-ru-groups.md)と[権限管理](/privilege-management.md)サポートされません。 -- TiProxy は[`LOAD DATA`](/sql-statements/sql-statement-load-data.md)ステートメントの再生をサポートしていません。 +- TiProxyは、TiProxyによってキャプチャされたトラフィックファイルの再生のみをサポートしており、他のファイル形式はサポートしていません。そのため、まずはTiProxyを使用して本番クラスタからトラフィックをキャプチャしてください。 +- TiProxyトラフィックの再生はSQLタイプのフィルタリングをサポートしておらず、DMLおよびDDL文が再生されます。そのため、再度再生する前に、クラスターデータを再生前の状態に復元する必要があります。 +- TiProxy トラフィック再生では、トラフィックの再生に同じユーザー名が使用されるため、テスト[リソース管理](/tidb-resource-control-ru-groups.md)と[権限管理](/privilege-management.md)サポートされません。 +- TiProxy は[`LOAD DATA`](/sql-statements/sql-statement-load-data.md)ステートメントの再生をサポートしていません。 ## その他のリソース {#more-resources} diff --git a/tiproxy/troubleshoot-tiproxy.md b/tiproxy/troubleshoot-tiproxy.md index 0495b111799eb..01db7fda454d0 100644 --- a/tiproxy/troubleshoot-tiproxy.md +++ b/tiproxy/troubleshoot-tiproxy.md @@ -11,38 +11,38 @@ summary: TiProxy の一般的な問題、原因、および解決策について 次の手順に従って、問題をトラブルシューティングできます。 -1. [コネクタバージョン](/tiproxy/tiproxy-overview.md#supported-connectors)がサポートされているかどうかを確認してください。コネクタがリストにない場合は、コネクタが[認証プラグイン](https://dev.mysql.com/doc/refman/8.0/en/pluggable-authentication.html)サポートしているかどうかを確認してください。 -2. クライアントが`No available TiDB instances, please make sure TiDB is available`報告する場合は、TiDBサーバーが存在するかどうか、および TiDBサーバーの SQL ポートと HTTP ステータス ポートに正常に接続できるかどうかを確認します。 -3. クライアントが`Require TLS enabled on TiProxy when require-backend-tls=true`報告する場合は、TiProxy が TLS 証明書で正しく構成されているかどうかを確認します。 -4. クライアントが`Verify TiDB capability failed, please upgrade TiDB`報告する場合は、TiDBサーバーのバージョンが v6.5.0 以降であるかどうかを確認します。 -5. クライアントが`TiProxy fails to connect to TiDB, please make sure TiDB is available`報告した場合は、 TiProxy ノードが TiDBサーバーに接続できるかどうかを確認します。 -6. クライアントが`Require TLS enabled on TiDB when require-backend-tls=true`報告する場合は、TiDB が TLS 証明書で正しく構成されているかどうかを確認します。 -7. クライアントが`TiProxy fails to connect to TiDB, please make sure TiDB proxy-protocol is set correctly`報告した場合は、 TiProxy で[`proxy.proxy-protocol`](/tiproxy/tiproxy-configuration.md#proxy-protocol)有効になっているかどうか、 TiDBサーバーで[`proxy-protocol`](/tidb-configuration-file.md#proxy-protocol)有効になっていないかどうかを確認します。 -8. TiProxy が[`max-connections`](/tiproxy/tiproxy-configuration.md#max-connections)に設定されており、TiProxy 上の接続数が最大接続制限を超えているかどうかを確認します。 -9. TiProxy ログでエラー メッセージを確認してください。 +1. [コネクタバージョン](/tiproxy/tiproxy-overview.md#supported-connectors)がサポートされているかどうかを確認してください。コネクタがリストにない場合は、コネクタが[認証プラグイン](https://dev.mysql.com/doc/refman/8.0/en/pluggable-authentication.html)サポートしているかどうかを確認してください。 +2. クライアントが`No available TiDB instances, please make sure TiDB is available`報告する場合は、TiDBサーバーが存在するかどうか、および TiDBサーバーの SQL ポートと HTTP ステータス ポートに正常に接続できるかどうかを確認します。 +3. クライアントが`Require TLS enabled on TiProxy when require-backend-tls=true`報告する場合は、TiProxy が TLS 証明書で正しく構成されているかどうかを確認します。 +4. クライアントが`Verify TiDB capability failed, please upgrade TiDB`報告する場合は、TiDBサーバーのバージョンが v6.5.0 以降であるかどうかを確認します。 +5. クライアントが`TiProxy fails to connect to TiDB, please make sure TiDB is available`報告した場合は、 TiProxy ノードが TiDBサーバーに接続できるかどうかを確認します。 +6. クライアントが`Require TLS enabled on TiDB when require-backend-tls=true`報告する場合は、TiDB が TLS 証明書で正しく構成されているかどうかを確認します。 +7. クライアントが`TiProxy fails to connect to TiDB, please make sure TiDB proxy-protocol is set correctly`報告した場合は、 TiProxy で[`proxy.proxy-protocol`](/tiproxy/tiproxy-configuration.md#proxy-protocol)有効になっているかどうか、 TiDBサーバーで[`proxy-protocol`](/tidb-configuration-file.md#proxy-protocol)有効になっていないかどうかを確認します。 +8. TiProxy が[`max-connections`](/tiproxy/tiproxy-configuration.md#max-connections)に設定されており、TiProxy 上の接続数が最大接続制限を超えているかどうかを確認します。 +9. TiProxy ログでエラー メッセージを確認してください。 ## TiProxyは接続を移行しません {#tiproxy-does-not-migrate-connections} 次の手順に従って、問題をトラブルシューティングできます。 -1. [TiProxyの制限](/tiproxy/tiproxy-overview.md#limitations)満たされていないかどうか。TiProxy ログを確認することで、これをさらに確認できます。 -2. [`security.session-token-signing-cert`](/tidb-configuration-file.md#session-token-signing-cert-new-in-v640) [`security.session-token-signing-key`](/tidb-configuration-file.md#session-token-signing-key-new-in-v640) [`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)で正しく構成されているかどうか。 +1. [TiProxyの制限](/tiproxy/tiproxy-overview.md#limitations)満たされていないかどうか。TiProxy ログを確認することで、これをさらに確認できます。 +2. [`security.session-token-signing-cert`](/tidb-configuration-file.md#session-token-signing-cert-new-in-v640) [`security.session-token-signing-key`](/tidb-configuration-file.md#session-token-signing-key-new-in-v640) [`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)で正しく構成されているかどうか。 ## TiDBサーバーの CPU 使用率が不均衡 {#unbalanced-cpu-usage-on-tidb-server} 次の手順に従って、問題をトラブルシューティングできます。 -1. TiDBサーバー間でCPU使用率に大きな差があるかどうかを確認します。TiProxyは、TiDBサーバー間でCPU使用率が同一であることを保証するものではありません。CPU使用率の差がクエリのレイテンシーに影響を与えるほど大きい場合にのみ、 [負荷分散](/tiproxy/tiproxy-load-balance.md)を実行します。 -2. TiDBサーバーの接続数が徐々にゼロに減少する場合、他の負荷分散ポリシーの影響を受けている可能性があります。Grafanaで[`Session Migration Reasons`](/tiproxy/tiproxy-grafana.md#balance)メトリックを確認することで、他のポリシーに基づく移行が発生しているかどうかを確認できます。 -3. TiProxy 設定項目[`policy`](/tiproxy/tiproxy-configuration.md#policy) `location`に設定されているかどうかを確認してください。ロケーションベースの優先順位付けが有効になっている場合、TiProxy は異なるロケーション間で CPU 使用率を分散しません。 -4. TiProxyのバージョンを確認してください。CPUベースの負荷分散はv1.1.0以降のバージョンでのみサポートされます。それ以前のバージョンでは、最小接続数に基づく負荷分散ポリシーが使用されます。 -5. 上記のいずれの状況にも該当しない場合は、接続の移行が失敗した可能性があります。さらにトラブルシューティングを行うには、 [TiProxyは接続を移行しません](#tiproxy-does-not-migrate-connections)を参照してください。 +1. TiDBサーバー間でCPU使用率に大きな差があるかどうかを確認します。TiProxyは、TiDBサーバー間でCPU使用率が同一であることを保証するものではありません。CPU使用率の差がクエリのレイテンシーに影響を与えるほど大きい場合にのみ、 [負荷分散](/tiproxy/tiproxy-load-balance.md)を実行します。 +2. TiDBサーバーの接続数が徐々にゼロに減少する場合、他の負荷分散ポリシーの影響を受けている可能性があります。Grafanaで[`Session Migration Reasons`](/tiproxy/tiproxy-grafana.md#balance)メトリックを確認することで、他のポリシーに基づく移行が発生しているかどうかを確認できます。 +3. TiProxy 設定項目[`policy`](/tiproxy/tiproxy-configuration.md#policy) `location`に設定されているかどうかを確認してください。ロケーションベースの優先順位付けが有効になっている場合、TiProxy は異なるロケーション間で CPU 使用率を分散しません。 +4. TiProxyのバージョンを確認してください。CPUベースの負荷分散はv1.1.0以降のバージョンでのみサポートされます。それ以前のバージョンでは、最小接続数に基づく負荷分散ポリシーが使用されます。 +5. 上記のいずれの状況にも該当しない場合は、接続の移行が失敗した可能性があります。さらにトラブルシューティングを行うには、 [TiProxyは接続を移行しません](#tiproxy-does-not-migrate-connections)を参照してください。 ## レイテンシーが大幅に増加 {#latency-is-significantly-increased} 次の手順に従って、問題をトラブルシューティングできます。 -1. Grafana を使って TiProxy のレイテンシーを確認します。TiProxy のレイテンシーが高くない場合は、クライアントの負荷が高いか、クライアントと TiProxy 間のネットワークレイテンシーが高いことを意味します。 -2. Grafanaを使用してTiDBサーバーのレイテンシーを確認します。TiDBサーバーのレイテンシーが高い場合は、手順[レイテンシーが大幅に増加する](/tidb-troubleshooting-map.md#2-latency-increases-significantly)に従ってトラブルシューティングを行ってください。 -3. Grafana を通じて[TiProxyとTiDBサーバー間のネットワーク継続時間](/tiproxy/tiproxy-grafana.md#backend)を確認します。 -4. TiProxyのCPU使用率を確認してください。CPU使用率が90%を超える場合は、TiProxyをスケールアウトする必要があります。 +1. Grafana を使って TiProxy のレイテンシーを確認します。TiProxy のレイテンシーが高くない場合は、クライアントの負荷が高いか、クライアントと TiProxy 間のネットワークレイテンシーが高いことを意味します。 +2. Grafanaを使用してTiDBサーバーのレイテンシーを確認します。TiDBサーバーのレイテンシーが高い場合は、手順[レイテンシーが大幅に増加する](/tidb-troubleshooting-map.md#2-latency-increases-significantly)に従ってトラブルシューティングを行ってください。 +3. Grafana を通じて[TiProxyとTiDBサーバー間のネットワーク継続時間](/tiproxy/tiproxy-grafana.md#backend)を確認します。 +4. TiProxyのCPU使用率を確認してください。CPU使用率が90%を超える場合は、TiProxyをスケールアウトする必要があります。 diff --git a/tiup/customized-montior-in-tiup-environment.md b/tiup/customized-montior-in-tiup-environment.md index 6bfed9f77e14c..be1dd8c6fcd41 100644 --- a/tiup/customized-montior-in-tiup-environment.md +++ b/tiup/customized-montior-in-tiup-environment.md @@ -11,11 +11,11 @@ TiUPを使用して TiDB クラスターをデプロイすると、 TiUP はProm > **Note:** > -> - 監視サーバーの構成ファイルを直接変更しないでください。これらの変更は、デプロイメント、スケールアウト、スケールイン、リロードなどの後続のTiUP操作によって上書きされるためです。 +> - 監視サーバーの構成ファイルを直接変更しないでください。これらの変更は、デプロイメント、スケールアウト、スケールイン、リロードなどの後続のTiUP操作によって上書きされるためです。 > -> - 監視サーバーがTiUPによって展開および管理されていない場合は、このドキュメントを参照する代わりに、監視サーバーの構成ファイルを直接変更できます。 +> - 監視サーバーがTiUPによって展開および管理されていない場合は、このドキュメントを参照する代わりに、監視サーバーの構成ファイルを直接変更できます。 > -> - この機能はTiUP v1.9.0以降でサポートされています。そのため、この機能を使用する前にTiUPのバージョンをご確認ください。 +> - この機能はTiUP v1.9.0以降でサポートされています。そのため、この機能を使用する前にTiUPのバージョンをご確認ください。 ## Prometheusの設定をカスタマイズする {#customize-prometheus-configurations} @@ -23,48 +23,52 @@ TiUPを使用して TiDB クラスターをデプロイすると、 TiUP はProm ### Prometheusルール設定をカスタマイズする {#customize-prometheus-rule-configuration} -1. ルール構成ファイルをカスタマイズし、 TiUP が配置されているマシンのディレクトリの下に配置します。 +1. ルール構成ファイルをカスタマイズし、 TiUP が配置されているマシンのディレクトリの下に配置します。 -2. topology.yaml ファイルで、カスタマイズされたルール構成ファイルのディレクトリに`rule_dir`設定します。 +2. topology.yaml ファイルで、カスタマイズされたルール構成ファイルのディレクトリに`rule_dir`設定します。 以下は、topology.yaml ファイル内の monitored_servers の構成例です。 - # # Server configs are used to specify the configuration of Prometheus Server. - monitoring_servers: - # # The ip address of the Monitoring Server. - - host: 127.0.0.1 - rule_dir: /home/tidb/prometheus_rule # prometheus rule dir on TiUP machine + ``` + # # Server configs are used to specify the configuration of Prometheus Server. + monitoring_servers: + # # The ip address of the Monitoring Server. + - host: 127.0.0.1 + rule_dir: /home/tidb/prometheus_rule # prometheus rule dir on TiUP machine + ``` 上記の構成が完了したら、TiDB クラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUPは`rule_dir` (たとえば、 `/home/tidb/prometheus_rule` ) からカスタマイズされたルール構成をロードし、それを Prometheus サーバーに送信してデフォルトのルール構成を置き換えます。 ### Prometheusのスクレイプ設定をカスタマイズする {#customize-prometheus-scrape-configuration} -1. TiDB クラスターの topology.yaml ファイルを開きます。 +1. TiDB クラスターの topology.yaml ファイルを開きます。 -2. `monitoring_servers`構成で、 `additional_scrape_conf`フィールドを追加します。 +2. `monitoring_servers`構成で、 `additional_scrape_conf`フィールドを追加します。 以下は、topology.yaml ファイル内の monitored_servers の構成例です。 - monitoring_servers: - - host: xxxxxxx - ssh_port: 22 - port: 9090 - deploy_dir: /tidb-deploy/prometheus-9090 - data_dir: /tidb-data/prometheus-9090 - log_dir: /tidb-deploy/prometheus-9090/log - external_alertmanagers: [] - arch: amd64 - os: linux - additional_scrape_conf: - metric_relabel_configs: - - source_labels: [__name__] - separator: ; - regex: tikv_thread_nonvoluntary_context_switches|tikv_thread_voluntary_context_switches|tikv_threads_io_bytes_total - action: drop - - source_labels: [__name__,name] - separator: ; - regex: tikv_thread_cpu_seconds_total;(tokio|rocksdb).+ - action: drop + ``` + monitoring_servers: + - host: xxxxxxx + ssh_port: 22 + port: 9090 + deploy_dir: /tidb-deploy/prometheus-9090 + data_dir: /tidb-data/prometheus-9090 + log_dir: /tidb-deploy/prometheus-9090/log + external_alertmanagers: [] + arch: amd64 + os: linux + additional_scrape_conf: + metric_relabel_configs: + - source_labels: [__name__] + separator: ; + regex: tikv_thread_nonvoluntary_context_switches|tikv_thread_voluntary_context_switches|tikv_threads_io_bytes_total + action: drop + - source_labels: [__name__,name] + separator: ; + regex: tikv_thread_cpu_seconds_total;(tokio|rocksdb).+ + action: drop + ``` 上記の構成が完了したら、TiDB クラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUP は`additional_scrape_conf`フィールドの内容を Prometheus 構成ファイルの対応するパラメーターに追加します。 @@ -98,39 +102,43 @@ TiUP v1.17.0 以降では、トポロジーファイルで Prometheus グロー ### Grafanaダッシュボードをカスタマイズする {#customize-grafana-dashboard} -1. Grafana ダッシュボードの構成ファイルをカスタマイズし、 TiUPが配置されているマシンのディレクトリの下に配置します。 +1. Grafana ダッシュボードの構成ファイルをカスタマイズし、 TiUPが配置されているマシンのディレクトリの下に配置します。 -2. topology.yaml ファイルで、カスタマイズされたダッシュボード構成ファイルのディレクトリに`dashboard_dir`設定します。 +2. topology.yaml ファイルで、カスタマイズされたダッシュボード構成ファイルのディレクトリに`dashboard_dir`設定します。 以下は、topology.yaml ファイル内の grafana_servers の構成例です。 - # # Server configs are used to specify the configuration of Grafana Servers. - grafana_servers: - # # The ip address of the Grafana Server. - - host: 127.0.0.1 - dashboard_dir: /home/tidb/dashboards # grafana dashboard dir on TiUP machine + ``` + # # Server configs are used to specify the configuration of Grafana Servers. + grafana_servers: + # # The ip address of the Grafana Server. + - host: 127.0.0.1 + dashboard_dir: /home/tidb/dashboards # grafana dashboard dir on TiUP machine + ``` 上記の構成が完了したら、TiDB クラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUPは`dashboard_dir` (たとえば、 `/home/tidb/dashboards` ) からカスタマイズされたダッシュボード構成をロードし、その構成を Grafana サーバーに送信してデフォルトのダッシュボード構成を置き換えます。 ### その他のGrafana設定をカスタマイズする {#customize-other-grafana-configurations} -1. TiDB クラスターの topology.yaml ファイルを開きます。 +1. TiDB クラスターの topology.yaml ファイルを開きます。 -2. `grafana_servers`構成に他の構成項目を追加します。 +2. `grafana_servers`構成に他の構成項目を追加します。 以下は、topology.yaml ファイルの`[log.file] level`フィールドと`smtp`フィールドの構成例です。 - # # Server configs are used to specify the configuration of Grafana Servers. - grafana_servers: - # # The ip address of the Grafana Server. - - host: 127.0.0.1 - config: - log.file.level: warning - smtp.enabled: true - smtp.host: {IP}:{port} - smtp.user: example@pingcap.com - smtp.password: {password} - smtp.skip_verify: true + ``` + # # Server configs are used to specify the configuration of Grafana Servers. + grafana_servers: + # # The ip address of the Grafana Server. + - host: 127.0.0.1 + config: + log.file.level: warning + smtp.enabled: true + smtp.host: {IP}:{port} + smtp.user: example@pingcap.com + smtp.password: {password} + smtp.skip_verify: true + ``` 上記の構成が完了したら、TiDB クラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUP は`config`フィールドの内容を Grafana 構成ファイル`grafana.ini`に追加します。 @@ -142,11 +150,13 @@ TiUPによってデプロイされた Alertmanager は、デフォルトで`aler 次の例では、 `listen_host`フィールドを 0.0.0.0 に設定します。 - alertmanager_servers: - # # The ip address of the Alertmanager Server. - - host: 172.16.7.147 - listen_host: 0.0.0.0 - # # SSH port of the server. - ssh_port: 22 +``` +alertmanager_servers: + # # The ip address of the Alertmanager Server. + - host: 172.16.7.147 + listen_host: 0.0.0.0 + # # SSH port of the server. + ssh_port: 22 +``` 上記の構成が完了したら、TiDB クラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUP はAlertmanager 起動パラメータの`listen_host`フィールドの内容を`--web.listen-address`に追加します。 diff --git a/tiup/tiup-bench.md b/tiup/tiup-bench.md index 17a95ff01982c..a893c206ea552 100644 --- a/tiup/tiup-bench.md +++ b/tiup/tiup-bench.md @@ -42,12 +42,12 @@ tiup bench rawsql # Benchmark a database using arbitrary SQL files -U, --user string Database user (default to "root") ``` -- `--host`と`--port`にカンマ区切りの値を指定すると、クライアント側の負荷分散が有効になります。例えば`--host 172.16.4.1,172.16.4.2 --port 4000,4001`を指定すると、プログラムはラウンドロビン方式で選択された 172.16.4.1:4000、172.16.4.1:4001、172.16.4.2:4000、172.16.4.2:4001 に接続します。 -- ローカルデプロイメントの場合、デフォルトのデータベースホストアドレスは`127.0.0.1`です。リモートデータベースに接続する場合は、ホストとその他の関連パラメータを指定する必要があります。例: `tiup bench tpcc -H 192.168.169.31 -P 4000 -D tpcc -U root -p tidb --warehouses 4 --parts 4 prepare` -- `--conn-params` [クエリ文字列](https://en.wikipedia.org/wiki/Query_string)の形式に従う必要があります。データベースによってパラメータが異なる場合があります。例: - - `--conn-params tidb_isolation_read_engines='tiflash'` TiDB にTiFlashからの読み取りを強制します。 - - `--conn-params sslmode=disable` 、PostgreSQL に接続するときに SSL を無効にします。 -- CH-benCHmark を実行する場合、 `--ap-host` 、 `--ap-port` 、 `--ap-conn-params`を使用して、OLAP クエリ用のスタンドアロン TiDBサーバーを指定できます。 +- `--host`と`--port`にカンマ区切りの値を指定すると、クライアント側の負荷分散が有効になります。例えば`--host 172.16.4.1,172.16.4.2 --port 4000,4001`を指定すると、プログラムはラウンドロビン方式で選択された 172.16.4.1:4000、172.16.4.1:4001、172.16.4.2:4000、172.16.4.2:4001 に接続します。 +- ローカルデプロイメントの場合、デフォルトのデータベースホストアドレスは`127.0.0.1`です。リモートデータベースに接続する場合は、ホストとその他の関連パラメータを指定する必要があります。例: `tiup bench tpcc -H 192.168.169.31 -P 4000 -D tpcc -U root -p tidb --warehouses 4 --parts 4 prepare` +- `--conn-params` [クエリ文字列](https://en.wikipedia.org/wiki/Query_string)の形式に従う必要があります。データベースによってパラメータが異なる場合があります。例: + - `--conn-params tidb_isolation_read_engines='tiflash'` TiDB にTiFlashからの読み取りを強制します。 + - `--conn-params sslmode=disable` 、PostgreSQL に接続するときに SSL を無効にします。 +- CH-benCHmark を実行する場合、 `--ap-host` 、 `--ap-port` 、 `--ap-conn-params`を使用して、OLAP クエリ用のスタンドアロン TiDBサーバーを指定できます。 次のセクションでは、 TiUPを使用して TPC-C、TPC-H、YCSB テストを実行する方法について説明します。 @@ -75,25 +75,25 @@ Flags: TPC-Cテストを実行するための簡略化された手順を以下に示します。詳細な手順については、 [TiDBでTPC-Cテストを実行する方法](/benchmark/benchmark-tidb-using-tpcc.md)を参照してください。 -1. ハッシュを使用して 4 つのパーティションを使用して 4 つの倉庫を作成します。 +1. ハッシュを使用して 4 つのパーティションを使用して 4 つの倉庫を作成します。 ```shell tiup bench tpcc --warehouses 4 --parts 4 prepare ``` -2. TPC-C テストを実行します。 +2. TPC-C テストを実行します。 ```shell tiup bench tpcc --warehouses 4 --time 10m run ``` -3. 一貫性を確認します。 +3. 一貫性を確認します。 ```shell tiup bench tpcc --warehouses 4 check ``` -4. データをクリーンアップします: +4. データをクリーンアップします: ```shell tiup bench tpcc --warehouses 4 cleanup @@ -101,13 +101,13 @@ TPC-Cテストを実行するための簡略化された手順を以下に示し 大規模なデータセットでベンチマークを実行する場合、SQLによるデータ準備は遅くなる可能性があります。その場合は、以下のコマンドでCSV形式のデータを生成し、 [TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)経由でTiDBにインポートできます。 -- CSV ファイルを生成します。 +- CSV ファイルを生成します。 ```shell tiup bench tpcc --warehouses 4 prepare --output-dir data --output-type=csv ``` -- 指定されたテーブルの CSV ファイルを生成します。 +- 指定されたテーブルの CSV ファイルを生成します。 ```shell tiup bench tpcc --warehouses 4 prepare --output-dir data --output-type=csv --tables history,orders @@ -132,13 +132,13 @@ Flags: ### テスト手順 {#test-procedures} -1. データを準備します: +1. データを準備します: ```shell tiup bench tpch --sf=1 prepare ``` -2. 統計を収集します。 +2. 統計を収集します。 OLAPシナリオでは、TiDBオプティマイザーが最適な実行計画を生成できるように、以下のSQL文を実行して事前に統計情報を収集してください。**`tidb_analyze_column_options` `ALL`に設定してください。そうしないと、統計情報を収集するとクエリのパフォーマンスが大幅に低下する可能性があります。** @@ -146,21 +146,21 @@ Flags: set global tidb_analyze_column_options='ALL'; ``` -3. 次のいずれかのコマンドを実行して、TPC-H テストを実行します。 +3. 次のいずれかのコマンドを実行して、TPC-H テストを実行します。 - - 結果を確認する場合は、次のコマンドを実行します。 + - 結果を確認する場合は、次のコマンドを実行します。 ```shell tiup bench tpch --count=22 --sf=1 --check=true run ``` - - 結果を確認しない場合は、次のコマンドを実行します。 + - 結果を確認しない場合は、次のコマンドを実行します。 ```shell tiup bench tpch --count=22 --sf=1 run ``` -4. データをクリーンアップします: +4. データをクリーンアップします: ```shell tiup bench tpch cleanup @@ -172,13 +172,13 @@ YCSB を介して TiDB と TiKV の両方をストレス テストできます ### ストレステスト TiDB {#stress-test-tidb} -1. データを準備します: +1. データを準備します: ```shell tiup bench ycsb load tidb -p tidb.instances="127.0.0.1:4000" -p recordcount=10000 ``` -2. YCSB ワークロードを実行します。 +2. YCSB ワークロードを実行します。 ```shell # The read-write percent is 95% by default @@ -187,13 +187,13 @@ YCSB を介して TiDB と TiKV の両方をストレス テストできます ### ストレステスト TiKV {#stress-test-tikv} -1. データを準備します: +1. データを準備します: ```shell tiup bench ycsb load tikv -p tikv.pd="127.0.0.1:2379" -p recordcount=10000 ``` -2. YCSB ワークロードを実行します。 +2. YCSB ワークロードを実行します。 ```shell # The read-write percent is 95% by default @@ -204,7 +204,7 @@ YCSB を介して TiDB と TiKV の両方をストレス テストできます 任意のクエリを SQL ファイルに記述し、次のように`tiup bench rawsql`を実行してテストに使用することができます。 -1. データとクエリを準備します。 +1. データとクエリを準備します。 ```sql -- Prepare data @@ -215,7 +215,7 @@ YCSB を介して TiDB と TiKV の両方をストレス テストできます SELECT a, sleep(rand()) FROM t WHERE a < 4*rand(); ``` -2. RawSQL テストを実行します。 +2. RawSQL テストを実行します。 ```shell tiup bench rawsql run --count 60 --query-files demo.sql diff --git a/tiup/tiup-cluster-no-sudo-mode.md b/tiup/tiup-cluster-no-sudo-mode.md index b443941baa0b7..0e2b35d9f0a27 100644 --- a/tiup/tiup-cluster-no-sudo-mode.md +++ b/tiup/tiup-cluster-no-sudo-mode.md @@ -15,19 +15,19 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ このドキュメントでは、 `tidb`ユーザーを例に挙げます。 -1. すべてのターゲット マシンに`root`ユーザーとしてログインし、 `tidb`という名前のユーザーを作成し、このユーザーのシステム リソース制限を次のように構成します。 +1. すべてのターゲット マシンに`root`ユーザーとしてログインし、 `tidb`という名前のユーザーを作成し、このユーザーのシステム リソース制限を次のように構成します。 > **Note:** > > no-sudo モードでは、 `tidb`ユーザーに対してパスワードなしの sudo を構成する必要はありません。つまり、 `tidb`ユーザーを`sudoers`ファイルに追加する必要はありません。 - 1. `tidb`ユーザーを追加します: + 1. `tidb`ユーザーを追加します: ```shell adduser tidb ``` - 2. `tidb`ユーザーのリソース制限を構成します。 + 2. `tidb`ユーザーのリソース制限を構成します。 ```shell cat << EOF >>/etc/security/limits.conf @@ -40,9 +40,9 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ EOF ``` -2. 各ターゲットマシンで、ユーザー`tidb`の`systemd user`モードを起動します。この手順は必須ですので、スキップしないでください。 +2. 各ターゲットマシンで、ユーザー`tidb`の`systemd user`モードを起動します。この手順は必須ですので、スキップしないでください。 - 1. `tidb`ユーザーを使用して`XDG_RUNTIME_DIR`環境変数を設定します。 + 1. `tidb`ユーザーを使用して`XDG_RUNTIME_DIR`環境変数を設定します。 ```shell sudo -iu tidb # Switch to the tidb user @@ -51,7 +51,7 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ source ~/.bashrc.d/systemd ``` - 2. `root`ユーザーを使用してユーザー サービスを開始します。 + 2. `root`ユーザーを使用してユーザー サービスを開始します。 ```shell $ uid=$(id -u tidb) # Get the ID of the tidb user @@ -74,9 +74,9 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ └─3358 /usr/bin/pulseaudio --daemonize=no --log-target=journal ``` - 3. `systemctl --user`を実行します。エラーが発生しない場合は、 `systemd user`モードが正常に開始されたことを示します。 + 3. `systemctl --user`を実行します。エラーが発生しない場合は、 `systemd user`モードが正常に開始されたことを示します。 -3. `root`ユーザーを使用して次のコマンドを実行し、 systemd ユーザー`tidb`の lingering を有効にします。 +3. `root`ユーザーを使用して次のコマンドを実行し、 systemd ユーザー`tidb`の lingering を有効にします。 ```shell loginctl enable-linger tidb @@ -85,15 +85,15 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ 参考として、systemd のドキュメント[systemd ユーザーインスタンスの自動起動](https://wiki.archlinux.org/title/Systemd/User#Automatic_start-up_of_systemd_user_instances)を読んでみてください。 -4. 制御マシンで`ssh-keygen`を使用してキーを生成します。 +4. 制御マシンで`ssh-keygen`を使用してキーを生成します。 ```shell ssh-keygen ``` -5. SSH 信頼を確立するには、公開キーをクラスター内の他のマシンにコピーします。 +5. SSH 信頼を確立するには、公開キーをクラスター内の他のマシンにコピーします。 - - `tidb`ユーザーにパスワードを設定している場合は、 `ssh-copy-id`コマンドを使用して公開キーをターゲット マシンにコピーできます。 + - `tidb`ユーザーにパスワードを設定している場合は、 `ssh-copy-id`コマンドを使用して公開キーをターゲット マシンにコピーできます。 ```shell ssh-copy-id tidb@host @@ -101,7 +101,7 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ `host`をターゲット マシンのホスト名に置き換え、クラスター内の他の各マシンでこのコマンドを実行する必要があります。 - - 別の方法で公開鍵をコピーする場合は、コピー後に`/home/tidb/.ssh/authorized_keys`ファイルの権限を必ず確認してください。 + - 別の方法で公開鍵をコピーする場合は、コピー後に`/home/tidb/.ssh/authorized_keys`ファイルの権限を必ず確認してください。 ```shell chown -R tidb:tidb /home/tidb/.ssh/authorized_keys @@ -110,13 +110,13 @@ summary: TiUP no-sudo モードを使用してオンライン TiDB クラスタ ## トポロジファイルを準備する {#prepare-the-topology-file} -1. 次のコマンドを実行してトポロジ ファイルを生成します。 +1. 次のコマンドを実行してトポロジ ファイルを生成します。 ```shell tiup cluster template > topology.yaml ``` -2. トポロジ ファイルを編集します。 +2. トポロジ ファイルを編集します。 通常モードと比較して、 TiUPをno-sudoモードで使用する場合は、 `topology.yaml`ファイルの`global`モジュールに`systemd_mode: "user"`の行を追加する必要があります。`systemd_mode`パラメータは、`systemd user`モードを使用するかどうかを設定するために使用されます。このパラメータが設定されていない場合、デフォルト値は`system`で、sudo権限が必要であることを意味します。 diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md index 4beb3947d82c5..9f8921cd2e407 100644 --- a/tiup/tiup-cluster-topology-reference.md +++ b/tiup/tiup-cluster-topology-reference.md @@ -15,82 +15,82 @@ TiUPを使用して TiDB クラスターをデプロイすると、Prometheus、 TiUPを使用した TiDB デプロイメントのトポロジ構成ファイルには、次のセクションが含まれる場合があります。 -- [グローバル](#global) : クラスターのグローバル設定。一部の設定項目はデフォルト値を使用しますが、インスタンスごとに個別に設定できます。 -- [監視](#monitored) : 監視サービス（blackbox_exporterと`node_exporter`のコンフィグレーション。各マシンに`node_exporter`と`blackbox_exporter`がデプロイされています。 -- [サーバー構成](#server_configs) : コンポーネントのグローバル設定。各コンポーネントを個別に設定できます。インスタンスに同じ名前の設定項目がある場合は、インスタンスの設定項目が有効になります。 -- [コンポーネントバージョン](#component_versions) : コンポーネントバージョン。コンポーネントがクラスタバージョンを使用しない場合に設定します。このセクションはtiup-cluster v1.14.0で導入されました。 -- [pd_servers](#pd_servers) : PDインスタンスの構成。この構成では、PDコンポーネントがデプロイされるマシンを指定します。 -- [tidb_servers](#tidb_servers) : TiDBインスタンスの構成。この構成では、TiDBコンポーネントがデプロイされるマシンを指定します。 -- [tikv_servers](#tikv_servers) : TiKVインスタンスの構成。この構成では、TiKVコンポーネントがデプロイされるマシンを指定します。 -- [tiflash_servers](#tiflash_servers) : TiFlashインスタンスの構成。この構成では、 TiFlashコンポーネントがデプロイされるマシンを指定します。 -- [tiproxy_servers](#tiproxy_servers) : TiProxyインスタンスの構成。この構成は、TiProxyコンポーネントがデプロイされるマシンを指定します。 -- [kvcdc_servers](#kvcdc_servers) : インスタンス[TiKV-CDC](https://tikv.org/docs/7.1/concepts/explore-tikv-features/cdc/cdc/)の構成。この構成では、TiKV-CDCコンポーネントがデプロイされるマシンを指定します。 -- [cdc_servers](#cdc_servers) : TiCDCインスタンスの構成。この構成では、TiCDCコンポーネントがデプロイされるマシンを指定します。 -- [tso_servers](/tiup/tiup-cluster-topology-reference.md#tso_servers) : TSOインスタンスの設定。この設定は、 `tso`マイクロサービスがデプロイされるマシンを指定します（ [PDマイクロサービス](/pd-microservices.md)を有効にするには、 [`global`](#global)で`pd_mode: "ms"`を設定する必要があります）。 -- [スケジューリングサーバー](/tiup/tiup-cluster-topology-reference.md#scheduling_servers) : スケジューリングインスタンスの設定。この設定では、 `scheduling`マイクロサービスがデプロイされるマシンを指定します（ [PDマイクロサービス](/pd-microservices.md)を有効にするには、 [`global`](#global)で`pd_mode: "ms"`を設定する必要があります）。 -- [監視サーバー](#monitoring_servers) : PrometheusとNGMonitoringがデプロイされるマシンを指定します。TiUPは複数のPrometheusインスタンスのデプロイをサポートしていますが、最初のインスタンスのみが使用されます。 -- [grafana_servers](#grafana_servers) : Grafanaインスタンスの設定。この設定では、Grafanaがデプロイされるマシンを指定します。 -- [Alertmanagerサーバー](#alertmanager_servers) : Alertmanagerインスタンスの設定。この設定では、Alertmanagerがデプロイされるマシンを指定します。 +- [グローバル](#global) : クラスターのグローバル設定。一部の設定項目はデフォルト値を使用しますが、インスタンスごとに個別に設定できます。 +- [監視](#monitored) : 監視サービス（blackbox_exporterと`node_exporter`のコンフィグレーション。各マシンに`node_exporter`と`blackbox_exporter`がデプロイされています。 +- [サーバー構成](#server_configs) : コンポーネントのグローバル設定。各コンポーネントを個別に設定できます。インスタンスに同じ名前の設定項目がある場合は、インスタンスの設定項目が有効になります。 +- [コンポーネントバージョン](#component_versions) : コンポーネントバージョン。コンポーネントがクラスタバージョンを使用しない場合に設定します。このセクションはtiup-cluster v1.14.0で導入されました。 +- [pd_servers](#pd_servers) : PDインスタンスの構成。この構成では、PDコンポーネントがデプロイされるマシンを指定します。 +- [tidb_servers](#tidb_servers) : TiDBインスタンスの構成。この構成では、TiDBコンポーネントがデプロイされるマシンを指定します。 +- [tikv_servers](#tikv_servers) : TiKVインスタンスの構成。この構成では、TiKVコンポーネントがデプロイされるマシンを指定します。 +- [tiflash_servers](#tiflash_servers) : TiFlashインスタンスの構成。この構成では、 TiFlashコンポーネントがデプロイされるマシンを指定します。 +- [tiproxy_servers](#tiproxy_servers) : TiProxyインスタンスの構成。この構成は、TiProxyコンポーネントがデプロイされるマシンを指定します。 +- [kvcdc_servers](#kvcdc_servers) : インスタンス[TiKV-CDC](https://tikv.org/docs/7.1/concepts/explore-tikv-features/cdc/cdc/)の構成。この構成では、TiKV-CDCコンポーネントがデプロイされるマシンを指定します。 +- [cdc_servers](#cdc_servers) : TiCDCインスタンスの構成。この構成では、TiCDCコンポーネントがデプロイされるマシンを指定します。 +- [tso_servers](/tiup/tiup-cluster-topology-reference.md#tso_servers) : TSOインスタンスの設定。この設定は、 `tso`マイクロサービスがデプロイされるマシンを指定します（ [PDマイクロサービス](/pd-microservices.md)を有効にするには、 [`global`](#global)で`pd_mode: "ms"`を設定する必要があります）。 +- [スケジューリングサーバー](/tiup/tiup-cluster-topology-reference.md#scheduling_servers) : スケジューリングインスタンスの設定。この設定では、 `scheduling`マイクロサービスがデプロイされるマシンを指定します（ [PDマイクロサービス](/pd-microservices.md)を有効にするには、 [`global`](#global)で`pd_mode: "ms"`を設定する必要があります）。 +- [監視サーバー](#monitoring_servers) : PrometheusとNGMonitoringがデプロイされるマシンを指定します。TiUPは複数のPrometheusインスタンスのデプロイをサポートしていますが、最初のインスタンスのみが使用されます。 +- [grafana_servers](#grafana_servers) : Grafanaインスタンスの設定。この設定では、Grafanaがデプロイされるマシンを指定します。 +- [Alertmanagerサーバー](#alertmanager_servers) : Alertmanagerインスタンスの設定。この設定では、Alertmanagerがデプロイされるマシンを指定します。 ### `global` {#global} `global`セクションはクラスターのグローバル構成に対応し、次のフィールドがあります。 -- `user` : デプロイされたクラスターを起動するために使用するユーザー。デフォルト値は`"tidb"`です。``フィールドに指定されたユーザーがターゲットマシン上に存在しない場合、このユーザーは自動的に作成されます。 +- `user` : デプロイされたクラスターを起動するために使用するユーザー。デフォルト値は`"tidb"`です。``フィールドに指定されたユーザーがターゲットマシン上に存在しない場合、このユーザーは自動的に作成されます。 -- `group` : ユーザーが所属するユーザーグループ。ユーザー作成時に指定されます。デフォルト値は``フィールドの値です。指定されたグループが存在しない場合は、自動的に作成されます。 +- `group` : ユーザーが所属するユーザーグループ。ユーザー作成時に指定されます。デフォルト値は``フィールドの値です。指定されたグループが存在しない場合は、自動的に作成されます。 -- `systemd_mode` : クラスタのデプロイメント時にターゲットマシンで使用される`systemd`モードを指定します。デフォルト値は`system`です。 `user`に設定すると、ターゲットマシンでsudo権限は不要になり、 [TiUP no-sudo モード](/tiup/tiup-cluster-no-sudo-mode.md)が使用されます。 +- `systemd_mode` : クラスタのデプロイメント時にターゲットマシンで使用される`systemd`モードを指定します。デフォルト値は`system`です。 `user`に設定すると、ターゲットマシンでsudo権限は不要になり、 [TiUP no-sudo モード](/tiup/tiup-cluster-no-sudo-mode.md)が使用されます。 -- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。デフォルト値は`22`です。 +- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。デフォルト値は`22`です。 -- `enable_tls` : クラスタでTLSを有効にするかどうかを指定します。TLSを有効にすると、生成されたTLS証明書はコンポーネント間またはクライアントとコンポーネント間の接続に使用する必要があります。デフォルト値は`false`です。 +- `enable_tls` : クラスタでTLSを有効にするかどうかを指定します。TLSを有効にすると、生成されたTLS証明書はコンポーネント間またはクライアントとコンポーネント間の接続に使用する必要があります。デフォルト値は`false`です。 -- `listen_host` : デフォルトのリスニングIPアドレスを指定します。空の場合、各インスタンスは、 `host`フィールドに`:`含まれているかどうかに基づいて、自動的に`::`または`0.0.0.0`に設​​定します。このフィールドはtiup-cluster v1.14.0で導入されました。 +- `listen_host` : デフォルトのリスニングIPアドレスを指定します。空の場合、各インスタンスは、 `host`フィールドに`:`含まれているかどうかに基づいて、自動的に`::`または`0.0.0.0`に設​​定します。このフィールドはtiup-cluster v1.14.0で導入されました。 -- `deploy_dir` : 各コンポーネントの配置ディレクトリ。デフォルト値は`"deployed"`です。適用ルールは以下のとおりです。 +- `deploy_dir` : 各コンポーネントの配置ディレクトリ。デフォルト値は`"deployed"`です。適用ルールは以下のとおりです。 - - インスタンス レベルで絶対パス`deploy_dir`が設定されている場合、実際のデプロイメント ディレクトリはインスタンスに対して`deploy_dir`設定されます。 + - インスタンス レベルで絶対パス`deploy_dir`が設定されている場合、実際のデプロイメント ディレクトリはインスタンスに対して`deploy_dir`設定されます。 - - 各インスタンスに対して`deploy_dir`設定しない場合、デフォルト値は相対パス`-`になります。 + - 各インスタンスに対して`deploy_dir`設定しない場合、デフォルト値は相対パス`-`になります。 - - `global.deploy_dir`が絶対パスの場合、コンポーネントは`/`ディレクトリにデプロイされます。 + - `global.deploy_dir`が絶対パスの場合、コンポーネントは`/`ディレクトリにデプロイされます。 - - `global.deploy_dir`相対パスの場合、コンポーネントは`/home///`ディレクトリにデプロイされます。 + - `global.deploy_dir`相対パスの場合、コンポーネントは`/home///`ディレクトリにデプロイされます。 -- `data_dir` : データディレクトリ。デフォルト値: `"data"` 。適用ルールは以下のとおりです。 +- `data_dir` : データディレクトリ。デフォルト値: `"data"` 。適用ルールは以下のとおりです。 - - インスタンス レベルで絶対パス`data_dir`が設定されている場合、実際のデプロイメント ディレクトリはインスタンスに対して`data_dir`設定されます。 + - インスタンス レベルで絶対パス`data_dir`が設定されている場合、実際のデプロイメント ディレクトリはインスタンスに対して`data_dir`設定されます。 - - 各インスタンスに対して`data_dir`設定しない場合、デフォルト値は``になります。 + - 各インスタンスに対して`data_dir`設定しない場合、デフォルト値は``になります。 - - `data_dir`相対パスの場合、コンポーネントデータは`/`に配置されます。 ``の計算規則については、 `deploy_dir`フィールドの適用規則を参照してください。 + - `data_dir`相対パスの場合、コンポーネントデータは`/`に配置されます。 ``の計算規則については、 `deploy_dir`フィールドの適用規則を参照してください。 -- `log_dir` : ログディレクトリ。デフォルト値: `"log"` 。適用ルールは以下のとおりです。 +- `log_dir` : ログディレクトリ。デフォルト値: `"log"` 。適用ルールは以下のとおりです。 - - 絶対パス`log_dir`インスタンス レベルで構成されている場合、実際のログ ディレクトリはインスタンスに構成されている`log_dir`になります。 + - 絶対パス`log_dir`インスタンス レベルで構成されている場合、実際のログ ディレクトリはインスタンスに構成されている`log_dir`になります。 - - 各インスタンスで`log_dir`設定しない場合、デフォルト値は``になります。 + - 各インスタンスで`log_dir`設定しない場合、デフォルト値は``になります。 - - `log_dir`相対パスの場合、コンポーネントログは`/`に配置されます。 ``の計算規則については、 `deploy_dir`フィールドの適用規則を参照してください。 + - `log_dir`相対パスの場合、コンポーネントログは`/`に配置されます。 ``の計算規則については、 `deploy_dir`フィールドの適用規則を参照してください。 -- `os` : ターゲットマシンのオペレーティングシステム。このフィールドは、ターゲットマシンにプッシュされるコンポーネントをどのオペレーティングシステムに適応させるかを制御します。デフォルト値は「linux」です。 +- `os` : ターゲットマシンのオペレーティングシステム。このフィールドは、ターゲットマシンにプッシュされるコンポーネントをどのオペレーティングシステムに適応させるかを制御します。デフォルト値は「linux」です。 -- `arch` : ターゲットマシンのCPUアーキテクチャ。このフィールドは、ターゲットマシンにプッシュされるバイナリパッケージをどのプラットフォームに適合させるかを制御します。サポートされている値は「amd64」と「arm64」です。デフォルト値は「amd64」です。 +- `arch` : ターゲットマシンのCPUアーキテクチャ。このフィールドは、ターゲットマシンにプッシュされるバイナリパッケージをどのプラットフォームに適合させるかを制御します。サポートされている値は「amd64」と「arm64」です。デフォルト値は「amd64」です。 -- `pd_mode` : PD動作モード。このフィールドは、 [PDマイクロサービス](/pd-microservices.md)を有効にするかどうかを制御します。サポートされる値は「ms」です。このフィールドを指定すると、PDマイクロサービスが有効になります。 +- `pd_mode` : PD動作モード。このフィールドは、 [PDマイクロサービス](/pd-microservices.md)を有効にするかどうかを制御します。サポートされる値は「ms」です。このフィールドを指定すると、PDマイクロサービスが有効になります。 -- `resource_control` : ランタイムリソース制御。このフィールドのすべての設定は、systemd のサービスファイルに書き込まれます。デフォルトでは制限はありません。制御可能なリソースは以下のとおりです。 +- `resource_control` : ランタイムリソース制御。このフィールドのすべての設定は、systemd のサービスファイルに書き込まれます。デフォルトでは制限はありません。制御可能なリソースは以下のとおりです。 - - `memory_limit` : 最大ランタイムメモリを制限します。たとえば、「2G」は最大2GBのメモリが使用できることを意味します。 + - `memory_limit` : 最大ランタイムメモリを制限します。たとえば、「2G」は最大2GBのメモリが使用できることを意味します。 - - `cpu_quota` : 実行時のCPU使用率の上限を制限します。例：200% + - `cpu_quota` : 実行時のCPU使用率の上限を制限します。例：200% - - `io_read_bandwidth_max` : ディスク読み取りの最大I/O帯域幅を制限します。例： `"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 100M"` 。 + - `io_read_bandwidth_max` : ディスク読み取りの最大I/O帯域幅を制限します。例： `"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 100M"` 。 - - `io_write_bandwidth_max` : ディスク書き込みの最大I/O帯域幅を制限します。例： `/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 100M` 。 + - `io_write_bandwidth_max` : ディスク書き込みの最大I/O帯域幅を制限します。例： `/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0 100M` 。 - - `limit_core` : コアダンプのサイズを制御します。 + - `limit_core` : コアダンプのサイズを制御します。 `global`構成の例は次のとおりです。 @@ -107,15 +107,15 @@ global: `monitored`はターゲットマシン上の監視サービスを設定するために使用されます: [`node_exporter`](https://github.com/prometheus/node_exporter)および[`blackbox_exporter`](https://github.com/prometheus/blackbox_exporter) 。以下のフィールドが含まれます: -- `node_exporter_port` : サービスポート`node_exporter`デフォルト値は`9100`です。 +- `node_exporter_port` : サービスポート`node_exporter`デフォルト値は`9100`です。 -- `blackbox_exporter_port` : サービスポート`blackbox_exporter`デフォルト値は`9115`です。 +- `blackbox_exporter_port` : サービスポート`blackbox_exporter`デフォルト値は`9115`です。 -- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 +- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 -- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 +- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 -- `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_dir`ディレクトリに従ってログが生成されます。 +- `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_dir`ディレクトリに従ってログが生成されます。 `monitored`構成の例は次のとおりです。 @@ -131,23 +131,23 @@ monitored: `server_configs`は、サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。`global`と同様に、このセクションの設定は、インスタンス内の同名の設定によって上書きできます。`server_configs`は主に以下のフィールドが含まれます。 -- `tidb` : TiDBサービス関連の設定。詳細な設定については[TiDB構成ファイル](/tidb-configuration-file.md)を参照してください。 +- `tidb` : TiDBサービス関連の設定。詳細な設定については[TiDB構成ファイル](/tidb-configuration-file.md)を参照してください。 -- `tikv` : TiKVサービス関連の設定。詳細な設定については[TiKV設定ファイル](/tikv-configuration-file.md)を参照してください。 +- `tikv` : TiKVサービス関連の設定。詳細な設定については[TiKV設定ファイル](/tikv-configuration-file.md)を参照してください。 -- `pd` : PDサービス関連の設定。詳細な設定については[PD設定ファイル](/pd-configuration-file.md)を参照してください。 +- `pd` : PDサービス関連の設定。詳細な設定については[PD設定ファイル](/pd-configuration-file.md)を参照してください。 -- `tiflash` : TiFlashサービス関連の設定。詳細な設定については[TiFlash設定ファイル](/tiflash/tiflash-configuration.md)を参照してください。 +- `tiflash` : TiFlashサービス関連の設定。詳細な設定については[TiFlash設定ファイル](/tiflash/tiflash-configuration.md)を参照してください。 -- `tiflash_learner` : 各TiFlashノードには特別な TiKV が組み込まれています。この設定項目は、この特別な TiKV を設定するために使用されます。通常、この設定項目の内容を変更することは推奨されません。 +- `tiflash_learner` : 各TiFlashノードには特別な TiKV が組み込まれています。この設定項目は、この特別な TiKV を設定するために使用されます。通常、この設定項目の内容を変更することは推奨されません。 -- `tiproxy` : TiProxyサービス関連の設定。詳細な設定については[TiProxy設定ファイル](/tiproxy/tiproxy-configuration.md)を参照してください。 +- `tiproxy` : TiProxyサービス関連の設定。詳細な設定については[TiProxy設定ファイル](/tiproxy/tiproxy-configuration.md)を参照してください。 -- `cdc` : TiCDCサービス関連の設定。詳細な設定については[TiCDCをデプロイ](/ticdc/deploy-ticdc.md)を参照してください。 +- `cdc` : TiCDCサービス関連の設定。詳細な設定については[TiCDCをデプロイ](/ticdc/deploy-ticdc.md)を参照してください。 -- `tso` : `tso`マイクロサービス関連の設定。完全な設定については[TSO構成ファイル](/tso-configuration-file.md)を参照してください。 +- `tso` : `tso`マイクロサービス関連の設定。完全な設定については[TSO構成ファイル](/tso-configuration-file.md)を参照してください。 -- `scheduling` : `scheduling`マイクロサービス関連の設定。完全な設定については[スケジュール設定ファイル](/scheduling-configuration-file.md)を参照してください。 +- `scheduling` : `scheduling`マイクロサービス関連の設定。完全な設定については[スケジュール設定ファイル](/scheduling-configuration-file.md)を参照してください。 `server_configs`構成の例は次のとおりです。 @@ -173,25 +173,25 @@ server_configs: `component_versions`は、特定のコンポーネントのバージョン番号を指定するために使用されます。 -- `component_versions`が設定されていない場合、各コンポーネントはTiDB クラスターと同じバージョン番号 (PD や TiKV など) を使用するか、最新バージョン (Alertmanager など) を使用します。 -- `component_versions`設定されている場合、対応するコンポーネントは指定されたバージョンを使用し、このバージョンは後続のクラスターのスケーリングおよびアップグレード操作で使用されます。 +- `component_versions`が設定されていない場合、各コンポーネントはTiDB クラスターと同じバージョン番号 (PD や TiKV など) を使用するか、最新バージョン (Alertmanager など) を使用します。 +- `component_versions`設定されている場合、対応するコンポーネントは指定されたバージョンを使用し、このバージョンは後続のクラスターのスケーリングおよびアップグレード操作で使用されます。 特定のバージョンのコンポーネントを使用する必要がある場合にのみ構成するようにしてください。 `component_versions`は次のフィールドが含まれます。 -- `tikv` : TiKVコンポーネントのバージョン -- `tiflash` : TiFlashコンポーネントのバージョン -- `pd` : PDコンポーネントのバージョン -- `tidb_dashboard` : スタンドアロンの TiDB Dashboardコンポーネントのバージョン -- `cdc` : CDCコンポーネントのバージョン -- `kvcdc` : TiKV-CDCコンポーネントのバージョン -- `tiproxy` : TiProxyコンポーネントのバージョン -- `prometheus` : Prometheusコンポーネントのバージョン -- `grafana` : Grafanaコンポーネントのバージョン -- `alertmanager` : Alertmanagerコンポーネントのバージョン -- `tso` : TSOコンポーネントのバージョン -- `scheduling` : スケジュールコンポーネントのバージョン +- `tikv` : TiKVコンポーネントのバージョン +- `tiflash` : TiFlashコンポーネントのバージョン +- `pd` : PDコンポーネントのバージョン +- `tidb_dashboard` : スタンドアロンの TiDB Dashboardコンポーネントのバージョン +- `cdc` : CDCコンポーネントのバージョン +- `kvcdc` : TiKV-CDCコンポーネントのバージョン +- `tiproxy` : TiProxyコンポーネントのバージョン +- `prometheus` : Prometheusコンポーネントのバージョン +- `grafana` : Grafanaコンポーネントのバージョン +- `alertmanager` : Alertmanagerコンポーネントのバージョン +- `tso` : TSOコンポーネントのバージョン +- `scheduling` : スケジュールコンポーネントのバージョン 以下は`component_versions`の構成例です。 @@ -206,46 +206,46 @@ component_versions: `pd_servers` 、PD サービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します`pd_servers`は配列であり、配列の各要素には以下のフィールドが含まれます。 -- `host` : PDサービスがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。 +- `host` : PDサービスがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。 -- `listen_host` : マシンに複数のIPアドレスがある場合、 `listen_host`サービスのリスニングIPアドレスを指定します。デフォルト値は`0.0.0.0`です。 +- `listen_host` : マシンに複数のIPアドレスがある場合、 `listen_host`サービスのリスニングIPアドレスを指定します。デフォルト値は`0.0.0.0`です。 -- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 +- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 -- `name` : PDインスタンスの名前を指定します。異なるインスタンスにはそれぞれ一意の名前を付ける必要があります。そうでない場合、インスタンスをデプロイできません。 +- `name` : PDインスタンスの名前を指定します。異なるインスタンスにはそれぞれ一意の名前を付ける必要があります。そうでない場合、インスタンスをデプロイできません。 -- `client_port` : PDがクライアントへの接続に使用するポートを指定します。デフォルト値は`2379`です。 +- `client_port` : PDがクライアントへの接続に使用するポートを指定します。デフォルト値は`2379`です。 -- `peer_port` : PD間の通信ポートを指定します。デフォルト値は`2380`です。 +- `peer_port` : PD間の通信ポートを指定します。デフォルト値は`2380`です。 -- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 +- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 -- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 +- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 -- `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_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`の`pd`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`pd`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `config` : このフィールドの設定ルールは、 `server_configs`の`pd`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`pd`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 -- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 +- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 -- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 +- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。 -- `host` -- `listen_host` -- `name` -- `client_port` -- `peer_port` -- `deploy_dir` -- `data_dir` -- `log_dir` -- `arch` -- `os` +- `host` +- `listen_host` +- `name` +- `client_port` +- `peer_port` +- `deploy_dir` +- `data_dir` +- `log_dir` +- `arch` +- `os` `pd_servers`構成の例は次のとおりです。 @@ -264,40 +264,40 @@ pd_servers: `tidb_servers` TiDB サービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します`tidb_servers`は配列であり、配列の各要素には以下のフィールドが含まれます。 -- `host` : TiDBサービスがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。 +- `host` : TiDBサービスがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。 -- `listen_host` : マシンに複数のIPアドレスがある場合、 `listen_host`サービスのリスニングIPアドレスを指定します。デフォルト値は`0.0.0.0`です。 +- `listen_host` : マシンに複数のIPアドレスがある場合、 `listen_host`サービスのリスニングIPアドレスを指定します。デフォルト値は`0.0.0.0`です。 -- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 +- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 -- `port` : TiDBサービスのリスニングポート。MySQLクライアントへの接続に使用されます。デフォルト値は`4000`です。 +- `port` : TiDBサービスのリスニングポート。MySQLクライアントへの接続に使用されます。デフォルト値は`4000`です。 -- `status_port` : TiDBステータスサービスのリスニングポート。HTTPリクエストを介して外部からTiDBサービスのステータスを確認するために使用されます。デフォルト値は`10080`です。 +- `status_port` : TiDBステータスサービスのリスニングポート。HTTPリクエストを介して外部からTiDBサービスのステータスを確認するために使用されます。デフォルト値は`10080`です。 -- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 +- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 -- `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_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`の`tidb`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tidb`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `config` : このフィールドの設定ルールは、 `server_configs`の`tidb`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tidb`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 -- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 +- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 -- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 +- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。 -- `host` -- `listen_host` -- `port` -- `status_port` -- `deploy_dir` -- `log_dir` -- `arch` -- `os` +- `host` +- `listen_host` +- `port` +- `status_port` +- `deploy_dir` +- `log_dir` +- `arch` +- `os` `tidb_servers`構成の例は次のとおりです。 @@ -314,43 +314,43 @@ tidb_servers: `tikv_servers` TiKV サービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します`tikv_servers`は配列であり、配列の各要素には以下のフィールドが含まれます。 -- `host` : TiKVサービスがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。 +- `host` : TiKVサービスがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。 -- `listen_host` : マシンに複数のIPアドレスがある場合、 `listen_host`サービスのリスニングIPアドレスを指定します。デフォルト値は`0.0.0.0`です。 +- `listen_host` : マシンに複数のIPアドレスがある場合、 `listen_host`サービスのリスニングIPアドレスを指定します。デフォルト値は`0.0.0.0`です。 -- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 +- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 -- `port` : TiKVサービスのリスニングポート。デフォルト値は`20160`です。 +- `port` : TiKVサービスのリスニングポート。デフォルト値は`20160`です。 -- `status_port` : TiKVステータスサービスのリスニングポート。デフォルト値は`20180`です。 +- `status_port` : TiKVステータスサービスのリスニングポート。デフォルト値は`20180`です。 -- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 +- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 -- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 +- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 -- `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_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`の`tikv`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tikv`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `config` : このフィールドの設定ルールは、 `server_configs`の`tikv`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tikv`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 -- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 +- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 -- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 +- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。 -- `host` -- `listen_host` -- `port` -- `status_port` -- `deploy_dir` -- `data_dir` -- `log_dir` -- `arch` -- `os` +- `host` +- `listen_host` +- `port` +- `status_port` +- `deploy_dir` +- `data_dir` +- `log_dir` +- `arch` +- `os` `tikv_servers`構成の例は次のとおりです。 @@ -368,53 +368,53 @@ tikv_servers: `tiflash_servers` 、 TiFlashサービスが展開されるマシンを指定します。また、各マシンにおけるサービス構成も指定します。このセクションは配列であり、配列の各要素には以下のフィールドが含まれます。 -- `host` : TiFlashサービスが展開されるマシンを指定します。このフィールド値は IP アドレスで、必須です。 +- `host` : TiFlashサービスが展開されるマシンを指定します。このフィールド値は IP アドレスで、必須です。 -- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 +- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 -- `tcp_port` : 内部テスト用のTiFlash TCPサービスのポート。デフォルト値は`9000`です。TiUP v1.12.5以降、この設定項目はv7.1.0以降のクラスターでは有効になりません。 +- `tcp_port` : 内部テスト用のTiFlash TCPサービスのポート。デフォルト値は`9000`です。TiUP v1.12.5以降、この設定項目はv7.1.0以降のクラスターでは有効になりません。 -- `flash_service_port` : TiFlashがサービスを提供するポート。TiDBはこのポートを介してTiFlashからデータを読み取ります。デフォルト値は`3930`です。 +- `flash_service_port` : TiFlashがサービスを提供するポート。TiDBはこのポートを介してTiFlashからデータを読み取ります。デフォルト値は`3930`です。 -- `metrics_port` : TiFlashのステータスポート。メトリックデータの出力に使用されます。デフォルト値は`8234`です。 +- `metrics_port` : TiFlashのステータスポート。メトリックデータの出力に使用されます。デフォルト値は`8234`です。 -- `flash_proxy_port` : 内蔵TiKVのポート。デフォルト値は`20170`です。 +- `flash_proxy_port` : 内蔵TiKVのポート。デフォルト値は`20170`です。 -- `flash_proxy_status_port` : 内蔵TiKVのステータスポート。デフォルト値は`20292`です。 +- `flash_proxy_status_port` : 内蔵TiKVのステータスポート。デフォルト値は`20292`です。 -- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 +- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 -- `data_dir` : データディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。TiFlashは、カンマで区切られた複数の`data_dir`ディレクトリをサポートしています。 +- `data_dir` : データディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。TiFlashは、カンマで区切られた複数の`data_dir`ディレクトリをサポートしています。 -- `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_dir`ディレクトリに従ってログが生成されます。 +- `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_dir`ディレクトリに従ってログが生成されます。 -- `tmp_path` : TiFlash一時ファイルのストレージパス。デフォルト値は[ `path`または`storage.latest.dir`の最初のディレクトリ] + "/tmp"です。 +- `tmp_path` : TiFlash一時ファイルのストレージパス。デフォルト値は[ `path`または`storage.latest.dir`の最初のディレクトリ] + "/tmp"です。 -- `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`の`tiflash`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tiflash`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `config` : このフィールドの設定ルールは、 `server_configs`の`tiflash`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tiflash`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 -- `learner_config` : 各TiFlashノードには特別な TiKV が組み込まれています。この設定項目は、この特別な TiKV を設定するために使用されます。通常、この設定項目の内容を変更することは推奨されません。 +- `learner_config` : 各TiFlashノードには特別な TiKV が組み込まれています。この設定項目は、この特別な TiKV を設定するために使用されます。通常、この設定項目の内容を変更することは推奨されません。 -- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 +- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 -- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 +- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 デプロイメント後、上記のフィールドではディレクトリを`data_dir`にのみ追加できます。以下のフィールドでは、これらのフィールドを変更することはできません。 -- `host` -- `tcp_port` -- `flash_service_port` -- `flash_proxy_port` -- `flash_proxy_status_port` -- `metrics_port` -- `deploy_dir` -- `log_dir` -- `tmp_path` -- `arch` -- `os` +- `host` +- `tcp_port` +- `flash_service_port` +- `flash_proxy_port` +- `flash_proxy_status_port` +- `metrics_port` +- `deploy_dir` +- `log_dir` +- `tmp_path` +- `arch` +- `os` `tiflash_servers`構成の例は次のとおりです。 @@ -428,31 +428,31 @@ tiflash_servers: `tiproxy_servers`は、TiProxy サービスが展開されるマシンと、各マシン上のサービスの構成を指定します。`tiproxy_servers`は配列であり、配列の各要素には次のフィールドが含まれます。 -- `host` : TiProxyサービスがデプロイされているマシンのIPアドレスを指定します。このフィールドは必須です。 +- `host` : TiProxyサービスがデプロイされているマシンのIPアドレスを指定します。このフィールドは必須です。 -- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 +- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 -- `port` : TiProxy SQL サービスのリスニングポート。デフォルト値は`6000`です。 +- `port` : TiProxy SQL サービスのリスニングポート。デフォルト値は`6000`です。 -- `status_port` : TiProxyステータスサービスのリスニングポート。HTTPリクエストを介して外部からTiProxyサービスのステータスを確認するために使用されます。デフォルト値は`3080`です。 +- `status_port` : TiProxyステータスサービスのリスニングポート。HTTPリクエストを介して外部からTiProxyサービスのステータスを確認するために使用されます。デフォルト値は`3080`です。 -- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに基づいてディレクトリが生成されます。 +- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_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`の`tiproxy`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tiproxy`内容とマージされます。これら 2 つのフィールドが重複している場合、このフィールドの内容が有効になります。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `config` : このフィールドの設定ルールは、 `server_configs`の`tiproxy`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tiproxy`内容とマージされます。これら 2 つのフィールドが重複している場合、このフィールドの内容が有効になります。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 -- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 +- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 -- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 +- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 上記のフィールドのうち、次の設定済みフィールドは、デプロイメント後に変更できません。 -- `host` -- `port` -- `deploy_dir` -- `arch` -- `os` +- `host` +- `port` +- `deploy_dir` +- `arch` +- `os` `tiproxy_servers`構成の例は次のとおりです。 @@ -476,41 +476,41 @@ tiproxy_servers: `kvcdc_servers` 、 [TiKV-CDC](https://tikv.org/docs/7.1/concepts/explore-tikv-features/cdc/cdc/)サービスがデプロイされるマシンを指定します。また、各マシンにおけるサービス構成も指定します`kvcdc_servers`は配列です。各配列要素には、以下のフィールドが含まれます。 -- `host` : TiKV-CDC サービスがデプロイされるマシンを指定します。このフィールド値は IP アドレスで、必須です。 +- `host` : TiKV-CDC サービスがデプロイされるマシンを指定します。このフィールド値は IP アドレスで、必須です。 -- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 +- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 -- `port` : TiKV-CDCサービスのリスニングポート。デフォルト値は`8600`です。 +- `port` : TiKV-CDCサービスのリスニングポート。デフォルト値は`8600`です。 -- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 +- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 -- `data-dir` : TiKV-CDC が主にソート用の一時ファイルを保存するディレクトリを指定します（オプション）。このディレクトリの空きディスク容量は500 GiB以上が推奨されます。 +- `data-dir` : TiKV-CDC が主にソート用の一時ファイルを保存するディレクトリを指定します（オプション）。このディレクトリの空きディスク容量は500 GiB以上が推奨されます。 -- `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_dir`ディレクトリに従ってログが生成されます。 +- `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_dir`ディレクトリに従ってログが生成されます。 -- `gc-ttl` : TiKV-CDC（オプション）によってPDに設定されるサービスレベルGCセーフポイントのTTL（Time to Live、秒単位）。これはレプリケーションタスクを一時停止できる期間で、デフォルトは`86400` （24時間）です。レプリケーションタスクの一時停止は、TiKVガベージコレクションセーフポイントの進行状況に影響することに注意してください。 `gc-ttl`長いほど、変更フィードを一時停止できる時間は長くなりますが、同時に、より多くの古いデータが保持され、より多くのスペースを占有することになります。逆もまた同様です。 +- `gc-ttl` : TiKV-CDC（オプション）によってPDに設定されるサービスレベルGCセーフポイントのTTL（Time to Live、秒単位）。これはレプリケーションタスクを一時停止できる期間で、デフォルトは`86400` （24時間）です。レプリケーションタスクの一時停止は、TiKVガベージコレクションセーフポイントの進行状況に影響することに注意してください。 `gc-ttl`長いほど、変更フィードを一時停止できる時間は長くなりますが、同時に、より多くの古いデータが保持され、より多くのスペースを占有することになります。逆もまた同様です。 -- `tz` : TiKV-CDCサービスが使用するタイムゾーン。TiKV-CDCは、タイムスタンプなどの時間データ型を内部的に変換する際、および下流にデータを複製する際にこのタイムゾーンを使用します。デフォルト値は、プロセスが実行されるローカルタイムゾーンです。 +- `tz` : TiKV-CDCサービスが使用するタイムゾーン。TiKV-CDCは、タイムスタンプなどの時間データ型を内部的に変換する際、および下流にデータを複製する際にこのタイムゾーンを使用します。デフォルト値は、プロセスが実行されるローカルタイムゾーンです。 -- `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` : TiKV-CDC が使用する構成ファイルのアドレス (オプション)。 +- `config` : TiKV-CDC が使用する構成ファイルのアドレス (オプション)。 -- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 +- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 -- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 +- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。 -- `host` -- `port` -- `deploy_dir` -- `data_dir` -- `log_dir` -- `arch` -- `os` +- `host` +- `port` +- `deploy_dir` +- `data_dir` +- `log_dir` +- `arch` +- `os` `kvcdc_servers`構成の例は次のとおりです。 @@ -524,44 +524,44 @@ kvcdc_servers: `cdc_servers` TiCDCサービスがデプロイされるマシンを指定します。また、各マシンにおけるサービス構成も指定します`cdc_servers`は配列です。各配列要素には以下のフィールドが含まれます。 -- `host` : TiCDC サービスがデプロイされるマシンを指定します。このフィールド値は IP アドレスで、必須です。 +- `host` : TiCDC サービスがデプロイされるマシンを指定します。このフィールド値は IP アドレスで、必須です。 -- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 +- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 -- `port` : TiCDCサービスのリスニングポート。デフォルト値は`8300`です。 +- `port` : TiCDCサービスのリスニングポート。デフォルト値は`8300`です。 -- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 +- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 -- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 +- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 -- `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_dir`ディレクトリに従ってログが生成されます。 +- `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_dir`ディレクトリに従ってログが生成されます。 -- `gc-ttl` : TiCDCによってPDに設定されるサービスレベルGCセーフポイントのTime To Live（TTL）期間（秒）。デフォルト値は`86400` （24時間）です。 +- `gc-ttl` : TiCDCによってPDに設定されるサービスレベルGCセーフポイントのTime To Live（TTL）期間（秒）。デフォルト値は`86400` （24時間）です。 -- `tz` : TiCDCサービスが使用するタイムゾーン。TiCDCは、タイムスタンプなどの時間データ型を内部的に変換する際、および下流にデータを複製する際にこのタイムゾーンを使用します。デフォルト値は、プロセスが実行されるローカルタイムゾーンです。 +- `tz` : TiCDCサービスが使用するタイムゾーン。TiCDCは、タイムスタンプなどの時間データ型を内部的に変換する際、および下流にデータを複製する際にこのタイムゾーンを使用します。デフォルト値は、プロセスが実行されるローカルタイムゾーンです。 -- `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`の`cdc`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `config` : フィールドの内容は`server_configs`の`cdc`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 -- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 +- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 -- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 +- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 -- `ticdc_cluster_id` : サービスに対応するTiCDCクラスタIDを指定します。このフィールドが指定されていない場合、サービスはデフォルトのTiCDCクラスタに参加します。このフィールドはTiDB v6.3.0以降のバージョンでのみ有効です。 +- `ticdc_cluster_id` : サービスに対応するTiCDCクラスタIDを指定します。このフィールドが指定されていない場合、サービスはデフォルトのTiCDCクラスタに参加します。このフィールドはTiDB v6.3.0以降のバージョンでのみ有効です。 上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。 -- `host` -- `port` -- `deploy_dir` -- `data_dir` -- `log_dir` -- `arch` -- `os` -- `ticdc_cluster_id` +- `host` +- `port` +- `deploy_dir` +- `data_dir` +- `log_dir` +- `arch` +- `os` +- `ticdc_cluster_id` `cdc_servers`構成の例は次のとおりです。 @@ -579,23 +579,23 @@ cdc_servers: `tso_servers`は 、 `tso`マイクロサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。`tso_servers`は配列であり、配列の各要素には以下のフィールドが含まれます。 -- `host` : `tso`マイクロサービスがデプロイされているマシンのIPアドレスを指定します。このフィールド値は必須です。 -- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 -- `port` : `tso`マイクロサービスのリスニングポートを指定します。デフォルト値は`3379`です。 -- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 -- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 -- `config` : このフィールドの設定ルールは、 `server_configs`の`tso`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tso`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 -- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 -- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 +- `host` : `tso`マイクロサービスがデプロイされているマシンのIPアドレスを指定します。このフィールド値は必須です。 +- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 +- `port` : `tso`マイクロサービスのリスニングポートを指定します。デフォルト値は`3379`です。 +- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 +- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 +- `config` : このフィールドの設定ルールは、 `server_configs`の`tso`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`tso`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 +- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 上記のフィールドのうち、デプロイメント後に次のフィールドを変更することはできません。 -- `host` -- `port` -- `deploy_dir` -- `data_dir` -- `arch` -- `os` +- `host` +- `port` +- `deploy_dir` +- `data_dir` +- `arch` +- `os` `tso_servers`構成の例は次のとおりです。 @@ -609,23 +609,23 @@ tso_servers: `scheduling_servers`は 、 `scheduling`マイクロサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します。`scheduling_servers`は配列であり、配列の各要素には以下のフィールドが含まれます。 -- `host` : `scheduling`マイクロサービスがデプロイされているマシンのIPアドレスを指定します。このフィールドは必須です。 -- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 -- `port` : `scheduling`マイクロサービスのリスニングポートを指定します。デフォルト値は`3379`です。 -- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 -- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 -- `config` : このフィールドの設定ルールは、 `server_configs`の`scheduling`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`scheduling`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 -- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 -- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 +- `host` : `scheduling`マイクロサービスがデプロイされているマシンのIPアドレスを指定します。このフィールドは必須です。 +- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 +- `port` : `scheduling`マイクロサービスのリスニングポートを指定します。デフォルト値は`3379`です。 +- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 +- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 +- `config` : このフィールドの設定ルールは、 `server_configs`の`scheduling`設定ルールと同じです。このフィールドが設定されている場合、フィールドの内容は`server_configs`の`scheduling`内容とマージされます（2 つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、設定ファイルが生成され、 `host`で指定されたマシンに送信されます。 +- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 +- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 上記のフィールドのうち、デプロイメント後に次のフィールドを変更することはできません。 -- `host` -- `port` -- `deploy_dir` -- `data_dir` -- `arch` -- `os` +- `host` +- `port` +- `deploy_dir` +- `data_dir` +- `arch` +- `os` `scheduling_servers`構成の例は次のとおりです。 @@ -639,53 +639,53 @@ scheduling_servers: `monitoring_servers` 、Prometheus サービスがデプロイされるマシンを指定します。また、各マシンのサービス設定も指定します`monitoring_servers`は配列です。各配列要素には以下のフィールドが含まれます。 -- `host` : 監視サービスがデプロイされているマシンを指定します。このフィールド値はIPアドレスで、必須です。 +- `host` : 監視サービスがデプロイされているマシンを指定します。このフィールド値はIPアドレスで、必須です。 -- `ng_port` : NgMonitoringがリッスンするポートを指定します。TiUP v1.7.0で導入されたこのフィールドは、 [継続的なプロファイリング](/dashboard/dashboard-profiling.md)と[Top SQL](/dashboard/top-sql.md)をサポートします。デフォルト値は`12020`です。 +- `ng_port` : NgMonitoringがリッスンするポートを指定します。TiUP v1.7.0で導入されたこのフィールドは、 [継続的なプロファイリング](/dashboard/dashboard-profiling.md)と[Top SQL](/dashboard/top-sql.md)をサポートします。デフォルト値は`12020`です。 -- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 +- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 -- `port` : Prometheusサービスのリスニングポート。デフォルト値は`9090`です。 +- `port` : Prometheusサービスのリスニングポート。デフォルト値は`9090`です。 -- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 +- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 -- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 +- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 -- `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_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監視データの保持期間。デフォルト値は`"30d"`です。 +- `storage_retention` : Prometheus監視データの保持期間。デフォルト値は`"30d"`です。 -- `rule_dir` : `*.rules.yml`ファイルすべてを含むローカルディレクトリを指定します。これらのファイルは、Prometheusのルールとして、クラスター構成の初期化フェーズ中にターゲットマシンに転送されます。 +- `rule_dir` : `*.rules.yml`ファイルすべてを含むローカルディレクトリを指定します。これらのファイルは、Prometheusのルールとして、クラスター構成の初期化フェーズ中にターゲットマシンに転送されます。 -- `remote_config` : Prometheusデータのリモートへの書き込み、またはリモートからのデータの読み取りをサポートします。このフィールドには2つの設定があります。 - - `remote_write` : Prometheus ドキュメント[``](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write)を参照してください。 - - `remote_read` : Prometheus ドキュメント[``](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_read)を参照してください。 +- `remote_config` : Prometheusデータのリモートへの書き込み、またはリモートからのデータの読み取りをサポートします。このフィールドには2つの設定があります。 + - `remote_write` : Prometheus ドキュメント[``](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write)を参照してください。 + - `remote_read` : Prometheus ドキュメント[``](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_read)を参照してください。 -- `external_alertmanagers` : `external_alertmanagers`フィールドが設定されている場合、Prometheusはクラスター外のAlertmanagerに構成動作を通知します。このフィールドは配列であり、各要素は外部Alertmanagerであり、 `host`と`web_port`フィールドで構成されます。 +- `external_alertmanagers` : `external_alertmanagers`フィールドが設定されている場合、Prometheusはクラスター外のAlertmanagerに構成動作を通知します。このフィールドは配列であり、各要素は外部Alertmanagerであり、 `host`と`web_port`フィールドで構成されます。 -- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 +- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 -- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 +- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 -- `additional_args` : TiUP v1.15.0で導入されたこのフィールドは、Prometheusの実行に必要な追加パラメータを設定します。このフィールドは配列であり、配列の各要素はPrometheusの実行パラメータです。例えば、Prometheusのホットリロード機能を有効にするには、このフィールドを`--web.enable-lifecycle`に設定します。 +- `additional_args` : TiUP v1.15.0で導入されたこのフィールドは、Prometheusの実行に必要な追加パラメータを設定します。このフィールドは配列であり、配列の各要素はPrometheusの実行パラメータです。例えば、Prometheusのホットリロード機能を有効にするには、このフィールドを`--web.enable-lifecycle`に設定します。 -- `external_labels` : TiUP v1.17.0で導入されたこのフィールドは、Prometheus グローバル `external_labels` をキーと値のペアとして設定します。このフィールドを使用して、Prometheus `remote_write`、federation、および alerting を通じて伝播される安定したメタデータを付加します。TiUP は `cluster` ラベルと `monitor` ラベルを予約し、自動的に管理するため、このフィールドで設定してはいけません。`__` で始まるラベル名も予約されています。さらに、すべてのラベル名は Prometheus のラベル命名規則に準拠する必要があります。このフィールドをサポートしない以前のバージョンの TiUP がトポロジーファイルを読み取ると、TiUP はこのフィールドを無視するのではなく、トポロジーの解析に失敗します。 +- `external_labels` : TiUP v1.17.0で導入されたこのフィールドは、Prometheus グローバル `external_labels` をキーと値のペアとして設定します。このフィールドを使用して、Prometheus `remote_write`、federation、および alerting を通じて伝播される安定したメタデータを付加します。TiUP は `cluster` ラベルと `monitor` ラベルを予約し、自動的に管理するため、このフィールドで設定してはいけません。`__` で始まるラベル名も予約されています。さらに、すべてのラベル名は Prometheus のラベル命名規則に準拠する必要があります。このフィールドをサポートしない以前のバージョンの TiUP がトポロジーファイルを読み取ると、TiUP はこのフィールドを無視するのではなく、トポロジーの解析に失敗します。 -- `additional_scrape_conf` : カスタマイズされたPrometheusスクレイプ設定。TiDBクラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUPは`additional_scrape_conf`フィールドの内容をPrometheus設定ファイルの対応するパラメータに追加します。詳細については、 [Prometheusのスクレイプ設定をカスタマイズする](/tiup/customized-montior-in-tiup-environment.md#customize-prometheus-scrape-configuration)を参照してください。 +- `additional_scrape_conf` : カスタマイズされたPrometheusスクレイプ設定。TiDBクラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUPは`additional_scrape_conf`フィールドの内容をPrometheus設定ファイルの対応するパラメータに追加します。詳細については、 [Prometheusのスクレイプ設定をカスタマイズする](/tiup/customized-montior-in-tiup-environment.md#customize-prometheus-scrape-configuration)を参照してください。 上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。 -- `host` -- `port` -- `deploy_dir` -- `data_dir` -- `log_dir` -- `arch` -- `os` +- `host` +- `port` +- `deploy_dir` +- `data_dir` +- `log_dir` +- `arch` +- `os` `monitoring_servers`構成の例は次のとおりです。 @@ -719,42 +719,42 @@ monitoring_servers: `grafana_servers` 、Grafana サービスがデプロイされるマシンを指定します。また、各マシンにおけるサービス設定も指定します`grafana_servers`は配列です。各配列要素には以下のフィールドが含まれます。 -- `host` : Grafanaサービスがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。 +- `host` : Grafanaサービスがデプロイされるマシンを指定します。このフィールド値はIPアドレスで、必須です。 -- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 +- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 -- `port` : Grafanaサービスのリスニングポート。デフォルト値は`3000`です。 +- `port` : Grafanaサービスのリスニングポート。デフォルト値は`3000`です。 -- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 +- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 -- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 +- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 -- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 +- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `username` : Grafana ログイン インターフェース上のユーザー名。 +- `username` : Grafana ログイン インターフェース上のユーザー名。 -- `password` : Grafanaに対応するパスワード。 +- `password` : Grafanaに対応するパスワード。 -- `dashboard_dir` : `dashboard(*.json)`ファイルすべてを含むローカルディレクトリを指定します。これらのファイルは、クラスター構成の初期化フェーズ中に、Grafanaのダッシュボードとしてターゲットマシンに転送されます。 +- `dashboard_dir` : `dashboard(*.json)`ファイルすべてを含むローカルディレクトリを指定します。これらのファイルは、クラスター構成の初期化フェーズ中に、Grafanaのダッシュボードとしてターゲットマシンに転送されます。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 -- `config` : このフィールドは、Grafanaにカスタム設定を追加するために使用されます。TiDBクラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUPは`config`フィールドの内容をGrafana設定ファイル`grafana.ini`に追加します。詳細については、 [その他のGrafana設定をカスタマイズする](/tiup/customized-montior-in-tiup-environment.md#customize-other-grafana-configurations)を参照してください。 +- `config` : このフィールドは、Grafanaにカスタム設定を追加するために使用されます。TiDBクラスターをデプロイ、スケールアウト、スケールイン、またはリロードすると、 TiUPは`config`フィールドの内容をGrafana設定ファイル`grafana.ini`に追加します。詳細については、 [その他のGrafana設定をカスタマイズする](/tiup/customized-montior-in-tiup-environment.md#customize-other-grafana-configurations)を参照してください。 > **Note:** > > `dashboard_dir`フィールドが`grafana_servers`に設定されている場合、クラスターの名前を変更する`tiup cluster rename`コマンドを実行した後、次の操作を実行する必要があります。 > -> 1. ローカル ダッシュボード ディレクトリ内の`*.json`ファイルについては、 `datasource`フィールドの値を新しいクラスター名に更新します ( `datasource`クラスター名に基づいて命名されているため)。 -> 2. `tiup cluster reload -R grafana`コマンドを実行します。 +> 1. ローカル ダッシュボード ディレクトリ内の`*.json`ファイルについては、 `datasource`フィールドの値を新しいクラスター名に更新します ( `datasource`クラスター名に基づいて命名されているため)。 +> 2. `tiup cluster reload -R grafana`コマンドを実行します。 上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。 -- `host` -- `port` -- `deploy_dir` -- `arch` -- `os` +- `host` +- `port` +- `deploy_dir` +- `arch` +- `os` `grafana_servers`構成の例は次のとおりです。 @@ -768,42 +768,42 @@ grafana_servers: `alertmanager_servers` 、Alertmanager サービスがデプロイされるマシンを指定します。また、各マシンのサービス構成も指定します`alertmanager_servers`は配列です。各配列要素には、以下のフィールドが含まれます。 -- `host` : Alertmanager サービスがデプロイされているマシンを指定します。このフィールド値は IP アドレスで、必須です。 +- `host` : Alertmanager サービスがデプロイされているマシンを指定します。このフィールド値は IP アドレスで、必須です。 -- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 +- `ssh_port` : 操作のために対象マシンに接続するためのSSHポートを指定します。指定されていない場合は、 `global`セクションのうち`ssh_port`のセクションが使用されます。 -- `web_port` : AlertmanagerがWebサービスを提供するために使用するポートを指定します。デフォルト値は`9093`です。 +- `web_port` : AlertmanagerがWebサービスを提供するために使用するポートを指定します。デフォルト値は`9093`です。 -- `cluster_port` : Alertmanager間の通信ポートを指定します。デフォルト値は`9094`です。 +- `cluster_port` : Alertmanager間の通信ポートを指定します。デフォルト値は`9094`です。 -- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 +- `deploy_dir` : デプロイメントディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`deploy_dir`ディレクトリに従ってディレクトリが生成されます。 -- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 +- `data_dir` : データディレクトリを指定します。指定されない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`data_dir`ディレクトリに従ってディレクトリが生成されます。 -- `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_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 の構成としてターゲット マシンに転送されるローカル ファイルを指定します。 +- `config_file` : クラスター構成の初期化フェーズ中に、Alertmanager の構成としてターゲット マシンに転送されるローカル ファイルを指定します。 -- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 +- `os` : `host`で指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`の`os`値になります。 -- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 +- `arch` : `host`で指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`の`arch`値になります。 -- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 +- `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます。`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 -- `listen_host` : Alertmanager にプロキシ経由でアクセスできるように、リスニングアドレスを指定します。 `0.0.0.0`に設定することをお勧めします。詳細については、 [Alertmanager 設定をカスタマイズする](/tiup/customized-montior-in-tiup-environment.md#customize-alertmanager-configurations)を参照してください。 +- `listen_host` : Alertmanager にプロキシ経由でアクセスできるように、リスニングアドレスを指定します。 `0.0.0.0`に設定することをお勧めします。詳細については、 [Alertmanager 設定をカスタマイズする](/tiup/customized-montior-in-tiup-environment.md#customize-alertmanager-configurations)を参照してください。 上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。 -- `host` -- `web_port` -- `cluster_port` -- `deploy_dir` -- `data_dir` -- `log_dir` -- `arch` -- `os` +- `host` +- `web_port` +- `cluster_port` +- `deploy_dir` +- `data_dir` +- `log_dir` +- `arch` +- `os` `alertmanager_servers`構成の例は次のとおりです。 diff --git a/tiup/tiup-cluster.md b/tiup/tiup-cluster.md index 4160dc4380a41..273b25b3af3c9 100644 --- a/tiup/tiup-cluster.md +++ b/tiup/tiup-cluster.md @@ -15,41 +15,43 @@ summary: TiUPを使用してオンライン TiDB クラスターを展開およ tiup cluster ``` - Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.12.3/cluster - Deploy a TiDB cluster for production - - Usage: - tiup cluster [command] - - Available Commands: - check Precheck a cluster - deploy Deploy a cluster for production - start Start a TiDB cluster - stop Stop a TiDB cluster - restart Restart a TiDB cluster - scale-in Scale in a TiDB cluster - scale-out Scale out a TiDB cluster - destroy Destroy a specified cluster - clean (Experimental) Clean up a specified cluster - upgrade Upgrade a specified TiDB cluster - display Display information of a TiDB cluster - list List all clusters - audit Show audit log of cluster operation - import Import an existing TiDB cluster from TiDB-Ansible - edit-config Edit TiDB cluster config - reload Reload a TiDB cluster's config and restart if needed - patch Replace the remote package with a specified package and restart the service - help Help about any command - - Flags: - -c, --concurrency int Maximum number of concurrent tasks allowed (defaults to `5`) - --format string (EXPERIMENTAL) The format of output, available values are [default, json] (default "default") - -h, --help help for tiup - --ssh string (Experimental) The executor type. Optional values are 'builtin', 'system', and 'none'. - --ssh-timeout uint Timeout in seconds to connect a host via SSH. Operations that don't need an SSH connection are ignored. (default 5) - -v, --version TiUP version - --wait-timeout uint Timeout in seconds to wait for an operation to complete. Inapplicable operations are ignored. (defaults to `120`) - -y, --yes Skip all confirmations and assumes 'yes' +``` +Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.12.3/cluster +Deploy a TiDB cluster for production + +Usage: + tiup cluster [command] + +Available Commands: + check Precheck a cluster + deploy Deploy a cluster for production + start Start a TiDB cluster + stop Stop a TiDB cluster + restart Restart a TiDB cluster + scale-in Scale in a TiDB cluster + scale-out Scale out a TiDB cluster + destroy Destroy a specified cluster + clean (Experimental) Clean up a specified cluster + upgrade Upgrade a specified TiDB cluster + display Display information of a TiDB cluster + list List all clusters + audit Show audit log of cluster operation + import Import an existing TiDB cluster from TiDB-Ansible + edit-config Edit TiDB cluster config + reload Reload a TiDB cluster's config and restart if needed + patch Replace the remote package with a specified package and restart the service + help Help about any command + +Flags: + -c, --concurrency int Maximum number of concurrent tasks allowed (defaults to `5`) + --format string (EXPERIMENTAL) The format of output, available values are [default, json] (default "default") + -h, --help help for tiup + --ssh string (Experimental) The executor type. Optional values are 'builtin', 'system', and 'none'. + --ssh-timeout uint Timeout in seconds to connect a host via SSH. Operations that don't need an SSH connection are ignored. (default 5) + -v, --version TiUP version + --wait-timeout uint Timeout in seconds to wait for an operation to complete. Inapplicable operations are ignored. (defaults to `120`) + -y, --yes Skip all confirmations and assumes 'yes' +``` ## クラスターをデプロイ {#deploy-the-cluster} @@ -168,10 +170,12 @@ Deployed cluster `prod-cluster` successfully tiup cluster list ``` - Starting /root/.tiup/components/cluster/v1.12.3/cluster list - Name User Version Path PrivateKey - ---- ---- ------- ---- ---------- - prod-cluster tidb v8.5.4 /root/.tiup/storage/cluster/clusters/prod-cluster /root/.tiup/storage/cluster/clusters/prod-cluster/ssh/id_rsa +``` +Starting /root/.tiup/components/cluster/v1.12.3/cluster list +Name User Version Path PrivateKey +---- ---- ------- ---- ---------- +prod-cluster tidb v8.5.4 /root/.tiup/storage/cluster/clusters/prod-cluster /root/.tiup/storage/cluster/clusters/prod-cluster/ssh/id_rsa +``` ## クラスターを起動する {#start-the-cluster} @@ -193,26 +197,28 @@ TiUPは、クラスター内の各コンポーネントのステータスを表 tiup cluster display prod-cluster ``` - Starting /root/.tiup/components/cluster/v1.12.3/cluster display prod-cluster - TiDB Cluster: prod-cluster - TiDB Version: v8.5.4 - ID Role Host Ports OS/Arch Status Data Dir Deploy Dir - -- ---- ---- ----- ------- ------ -------- ---------- - 172.16.5.134:3000 grafana 172.16.5.134 3000 linux/x86_64 Up - deploy/grafana-3000 - 172.16.5.134:2379 pd 172.16.5.134 2379/2380 linux/x86_64 Up|L data/pd-2379 deploy/pd-2379 - 172.16.5.139:2379 pd 172.16.5.139 2379/2380 linux/x86_64 Up|UI data/pd-2379 deploy/pd-2379 - 172.16.5.140:2379 pd 172.16.5.140 2379/2380 linux/x86_64 Up data/pd-2379 deploy/pd-2379 - 172.16.5.134:9090 prometheus 172.16.5.134 9090 linux/x86_64 Up data/prometheus-9090 deploy/prometheus-9090 - 172.16.5.134:4000 tidb 172.16.5.134 4000/10080 linux/x86_64 Up - deploy/tidb-4000 - 172.16.5.139:4000 tidb 172.16.5.139 4000/10080 linux/x86_64 Up - deploy/tidb-4000 - 172.16.5.140:4000 tidb 172.16.5.140 4000/10080 linux/x86_64 Up - deploy/tidb-4000 - 172.16.5.141:9000 tiflash 172.16.5.141 9000/8123/3930/20170/20292/8234 linux/x86_64 Up data/tiflash-9000 deploy/tiflash-9000 - 172.16.5.142:9000 tiflash 172.16.5.142 9000/8123/3930/20170/20292/8234 linux/x86_64 Up data/tiflash-9000 deploy/tiflash-9000 - 172.16.5.143:9000 tiflash 172.16.5.143 9000/8123/3930/20170/20292/8234 linux/x86_64 Up data/tiflash-9000 deploy/tiflash-9000 - 172.16.5.134:20160 tikv 172.16.5.134 20160/20180 linux/x86_64 Up data/tikv-20160 deploy/tikv-20160 - 172.16.5.139:20160 tikv 172.16.5.139 20160/20180 linux/x86_64 Up data/tikv-20160 deploy/tikv-20160 - 172.16.5.140:20160 tikv 172.16.5.140 20160/20180 linux/x86_64 Up data/tikv-20160 deploy/tikv-20160 - 172.16.5.144:6000 tiproxy 172.16.5.144 6000/3080 linux/x86_64 Up - deploy/tiproxy-6000 +``` +Starting /root/.tiup/components/cluster/v1.12.3/cluster display prod-cluster +TiDB Cluster: prod-cluster +TiDB Version: v8.5.4 +ID Role Host Ports OS/Arch Status Data Dir Deploy Dir +-- ---- ---- ----- ------- ------ -------- ---------- +172.16.5.134:3000 grafana 172.16.5.134 3000 linux/x86_64 Up - deploy/grafana-3000 +172.16.5.134:2379 pd 172.16.5.134 2379/2380 linux/x86_64 Up|L data/pd-2379 deploy/pd-2379 +172.16.5.139:2379 pd 172.16.5.139 2379/2380 linux/x86_64 Up|UI data/pd-2379 deploy/pd-2379 +172.16.5.140:2379 pd 172.16.5.140 2379/2380 linux/x86_64 Up data/pd-2379 deploy/pd-2379 +172.16.5.134:9090 prometheus 172.16.5.134 9090 linux/x86_64 Up data/prometheus-9090 deploy/prometheus-9090 +172.16.5.134:4000 tidb 172.16.5.134 4000/10080 linux/x86_64 Up - deploy/tidb-4000 +172.16.5.139:4000 tidb 172.16.5.139 4000/10080 linux/x86_64 Up - deploy/tidb-4000 +172.16.5.140:4000 tidb 172.16.5.140 4000/10080 linux/x86_64 Up - deploy/tidb-4000 +172.16.5.141:9000 tiflash 172.16.5.141 9000/8123/3930/20170/20292/8234 linux/x86_64 Up data/tiflash-9000 deploy/tiflash-9000 +172.16.5.142:9000 tiflash 172.16.5.142 9000/8123/3930/20170/20292/8234 linux/x86_64 Up data/tiflash-9000 deploy/tiflash-9000 +172.16.5.143:9000 tiflash 172.16.5.143 9000/8123/3930/20170/20292/8234 linux/x86_64 Up data/tiflash-9000 deploy/tiflash-9000 +172.16.5.134:20160 tikv 172.16.5.134 20160/20180 linux/x86_64 Up data/tikv-20160 deploy/tikv-20160 +172.16.5.139:20160 tikv 172.16.5.139 20160/20180 linux/x86_64 Up data/tikv-20160 deploy/tikv-20160 +172.16.5.140:20160 tikv 172.16.5.140 20160/20180 linux/x86_64 Up data/tikv-20160 deploy/tikv-20160 +172.16.5.144:6000 tiproxy 172.16.5.144 6000/3080 linux/x86_64 Up - deploy/tiproxy-6000 +``` `Status`列は、 `Up`または`Down`を使用して、サービスが正常に実行されているかどうかを示します。 @@ -228,19 +234,19 @@ PDコンポーネントの場合、 `|L`または`|UI`が`Up`または`Down`に TiKV およびTiFlashコンポーネントのオフライン プロセスは非同期 (API 経由でノードを削除する必要がある) であり、プロセスに長い時間がかかる (ノードが正常にオフラインになったかどうかを継続的に監視する必要がある) ため、TiKV およびTiFlashコンポーネントには特別な処理が行われます。 -- TiKV およびTiFlashの場合: +- TiKV およびTiFlashの場合: - - TiUPクラスターは API を介してノードをオフラインにし、プロセスが完了するのを待たずに直接終了します。 - - その後、クラスタ操作に関連するコマンドが実行されると、 TiUPクラスタはオフラインになったTiKVノードまたはTiFlashノードがあるかどうかを確認します。オフラインになったノードがない場合、 TiUPクラスタは指定された操作を続行します。オフラインになったノードがある場合、 TiUPクラスタは以下の手順を実行します。 + - TiUPクラスターは API を介してノードをオフラインにし、プロセスが完了するのを待たずに直接終了します。 + - その後、クラスタ操作に関連するコマンドが実行されると、 TiUPクラスタはオフラインになったTiKVノードまたはTiFlashノードがあるかどうかを確認します。オフラインになったノードがない場合、 TiUPクラスタは指定された操作を続行します。オフラインになったノードがある場合、 TiUPクラスタは以下の手順を実行します。 - 1. オフラインになったノードのサービスを停止します。 - 2. ノードに関連するデータ ファイルをクリーンアップします。 - 3. クラスター トポロジからノードを削除します。 + 1. オフラインになったノードのサービスを停止します。 + 2. ノードに関連するデータ ファイルをクリーンアップします。 + 3. クラスター トポロジからノードを削除します。 -- その他のコンポーネントの場合: +- その他のコンポーネントの場合: - - PDコンポーネントをダウンさせる場合、 TiUPクラスターは API を介して指定されたノードをクラスターから迅速に削除し、指定された PD ノードのサービスを停止し、関連するデータ ファイルを削除します。 - - 他のコンポーネントを停止する場合、 TiUPクラスターはノード サービスを直接停止し、関連するデータ ファイルを削除します。 + - PDコンポーネントをダウンさせる場合、 TiUPクラスターは API を介して指定されたノードをクラスターから迅速に削除し、指定された PD ノードのサービスを停止し、関連するデータ ファイルを削除します。 + - 他のコンポーネントを停止する場合、 TiUPクラスターはノード サービスを直接停止し、関連するデータ ファイルを削除します。 スケールイン コマンドの基本的な使用方法: @@ -262,26 +268,28 @@ tiup cluster scale-in prod-cluster -N 172.16.5.140:20160 tiup cluster display prod-cluster ``` - Starting /root/.tiup/components/cluster/v1.12.3/cluster display prod-cluster - TiDB Cluster: prod-cluster - TiDB Version: v8.5.4 - ID Role Host Ports OS/Arch Status Data Dir Deploy Dir - -- ---- ---- ----- ------- ------ -------- ---------- - 172.16.5.134:3000 grafana 172.16.5.134 3000 linux/x86_64 Up - deploy/grafana-3000 - 172.16.5.134:2379 pd 172.16.5.134 2379/2380 linux/x86_64 Up|L data/pd-2379 deploy/pd-2379 - 172.16.5.139:2379 pd 172.16.5.139 2379/2380 linux/x86_64 Up|UI data/pd-2379 deploy/pd-2379 - 172.16.5.140:2379 pd 172.16.5.140 2379/2380 linux/x86_64 Up data/pd-2379 deploy/pd-2379 - 172.16.5.134:9090 prometheus 172.16.5.134 9090 linux/x86_64 Up data/prometheus-9090 deploy/prometheus-9090 - 172.16.5.134:4000 tidb 172.16.5.134 4000/10080 linux/x86_64 Up - deploy/tidb-4000 - 172.16.5.139:4000 tidb 172.16.5.139 4000/10080 linux/x86_64 Up - deploy/tidb-4000 - 172.16.5.140:4000 tidb 172.16.5.140 4000/10080 linux/x86_64 Up - deploy/tidb-4000 - 172.16.5.141:9000 tiflash 172.16.5.141 9000/8123/3930/20170/20292/8234 linux/x86_64 Up data/tiflash-9000 deploy/tiflash-9000 - 172.16.5.142:9000 tiflash 172.16.5.142 9000/8123/3930/20170/20292/8234 linux/x86_64 Up data/tiflash-9000 deploy/tiflash-9000 - 172.16.5.143:9000 tiflash 172.16.5.143 9000/8123/3930/20170/20292/8234 linux/x86_64 Up data/tiflash-9000 deploy/tiflash-9000 - 172.16.5.134:20160 tikv 172.16.5.134 20160/20180 linux/x86_64 Up data/tikv-20160 deploy/tikv-20160 - 172.16.5.139:20160 tikv 172.16.5.139 20160/20180 linux/x86_64 Up data/tikv-20160 deploy/tikv-20160 - 172.16.5.140:20160 tikv 172.16.5.140 20160/20180 linux/x86_64 Offline data/tikv-20160 deploy/tikv-20160 - 172.16.5.144:6000 tiproxy 172.16.5.144 6000/3080 linux/x86_64 Up - deploy/tiproxy-6000 +``` +Starting /root/.tiup/components/cluster/v1.12.3/cluster display prod-cluster +TiDB Cluster: prod-cluster +TiDB Version: v8.5.4 +ID Role Host Ports OS/Arch Status Data Dir Deploy Dir +-- ---- ---- ----- ------- ------ -------- ---------- +172.16.5.134:3000 grafana 172.16.5.134 3000 linux/x86_64 Up - deploy/grafana-3000 +172.16.5.134:2379 pd 172.16.5.134 2379/2380 linux/x86_64 Up|L data/pd-2379 deploy/pd-2379 +172.16.5.139:2379 pd 172.16.5.139 2379/2380 linux/x86_64 Up|UI data/pd-2379 deploy/pd-2379 +172.16.5.140:2379 pd 172.16.5.140 2379/2380 linux/x86_64 Up data/pd-2379 deploy/pd-2379 +172.16.5.134:9090 prometheus 172.16.5.134 9090 linux/x86_64 Up data/prometheus-9090 deploy/prometheus-9090 +172.16.5.134:4000 tidb 172.16.5.134 4000/10080 linux/x86_64 Up - deploy/tidb-4000 +172.16.5.139:4000 tidb 172.16.5.139 4000/10080 linux/x86_64 Up - deploy/tidb-4000 +172.16.5.140:4000 tidb 172.16.5.140 4000/10080 linux/x86_64 Up - deploy/tidb-4000 +172.16.5.141:9000 tiflash 172.16.5.141 9000/8123/3930/20170/20292/8234 linux/x86_64 Up data/tiflash-9000 deploy/tiflash-9000 +172.16.5.142:9000 tiflash 172.16.5.142 9000/8123/3930/20170/20292/8234 linux/x86_64 Up data/tiflash-9000 deploy/tiflash-9000 +172.16.5.143:9000 tiflash 172.16.5.143 9000/8123/3930/20170/20292/8234 linux/x86_64 Up data/tiflash-9000 deploy/tiflash-9000 +172.16.5.134:20160 tikv 172.16.5.134 20160/20180 linux/x86_64 Up data/tikv-20160 deploy/tikv-20160 +172.16.5.139:20160 tikv 172.16.5.139 20160/20180 linux/x86_64 Up data/tikv-20160 deploy/tikv-20160 +172.16.5.140:20160 tikv 172.16.5.140 20160/20180 linux/x86_64 Offline data/tikv-20160 deploy/tikv-20160 +172.16.5.144:6000 tiproxy 172.16.5.144 6000/3080 linux/x86_64 Up - deploy/tiproxy-6000 +``` PD がノード上のデータを他の TiKV ノードにスケジュールすると、このノードは自動的に削除されます。 @@ -299,7 +307,7 @@ PDをスケールアウトすると、ノードが`join`によってクラスタ `tidb-test`クラスターに TiKV ノードと PD ノードを追加するには、次の手順を実行します。 -1. `scale.yaml`ファイルを作成し、新しい TiKV ノードと PD ノードの IP を追加します。 +1. `scale.yaml`ファイルを作成し、新しい TiKV ノードと PD ノードの IP を追加します。 > **Note:** > @@ -315,7 +323,7 @@ PDをスケールアウトすると、ノードが`join`によってクラスタ - host: 172.16.5.140 ``` -2. スケールアウト操作を実行します。TiUP クラスターは、 `scale.yaml`で説明したポート、ディレクトリ、その他の情報に従って、対応するノードをクラスターに追加します。 +2. スケールアウト操作を実行します。TiUP クラスターは、 `scale.yaml`で説明したポート、ディレクトリ、その他の情報に従って、対応するノードをクラスターに追加します。 ```shell tiup cluster scale-out tidb-test scale.yaml @@ -335,23 +343,23 @@ PDをスケールアウトすると、ノードが`join`によってクラスタ ### 異なるノードに対する操作 {#operations-for-different-nodes} -- PDノードをアップグレードする +- PDノードをアップグレードする - - まず、リーダー以外のノードをアップグレードします。 - - リーダー以外のノードがすべてアップグレードされたら、Leaderノードをアップグレードします。 - - アップグレード ツールは、Leaderをすでにアップグレードされたノードに移行するコマンドを PD に送信します。 - - Leaderの役割が別のノードに切り替えられた後、以前のLeaderノードをアップグレードします。 - - アップグレード中に異常なノードが検出された場合、ツールはアップグレード操作を停止して終了します。手動で原因を分析し、問題を修正してから、アップグレードを再度実行する必要があります。 + - まず、リーダー以外のノードをアップグレードします。 + - リーダー以外のノードがすべてアップグレードされたら、Leaderノードをアップグレードします。 + - アップグレード ツールは、Leaderをすでにアップグレードされたノードに移行するコマンドを PD に送信します。 + - Leaderの役割が別のノードに切り替えられた後、以前のLeaderノードをアップグレードします。 + - アップグレード中に異常なノードが検出された場合、ツールはアップグレード操作を停止して終了します。手動で原因を分析し、問題を修正してから、アップグレードを再度実行する必要があります。 -- TiKVノードをアップグレードする +- TiKVノードをアップグレードする - - まず、PD にこの TiKV ノードのリージョンLeaderを移行するスケジュール操作を追加します。これにより、アップグレードプロセスがビジネスに影響を与えないことが保証されます。 - - Leaderが移行された後、この TiKV ノードをアップグレードします。 - - アップグレードした TiKV が正常に起動したら、Leaderのスケジュールを削除します。 + - まず、PD にこの TiKV ノードのリージョンLeaderを移行するスケジュール操作を追加します。これにより、アップグレードプロセスがビジネスに影響を与えないことが保証されます。 + - Leaderが移行された後、この TiKV ノードをアップグレードします。 + - アップグレードした TiKV が正常に起動したら、Leaderのスケジュールを削除します。 -- 他のサービスをアップグレードする +- 他のサービスをアップグレードする - - サービスを通常どおり停止し、ノードを更新します。 + - サービスを通常どおり停止し、ノードを更新します。 ### アップグレードコマンド {#upgrade-command} @@ -419,9 +427,9 @@ alertmanager_servers: 指定されたパスの下にあるファイルの内容と形式の要件は次のとおりです。 -- `grafana_servers`の`dashboard_dir`フィールドで指定されたフォルダーには、完全な`*.json`ファイルが含まれている必要があります。 -- `monitoring_servers`の`rule_dir`フィールドで指定されたフォルダーには、完全な`*.rules.yml`ファイルが含まれている必要があります。 -- `alertmanager_servers`の`config_file`欄に指定するファイルの形式については[Alertmanager 構成テンプレート](https://github.com/pingcap/tiup/blob/master/embed/templates/config/alertmanager.yml)を参照してください。 +- `grafana_servers`の`dashboard_dir`フィールドで指定されたフォルダーには、完全な`*.json`ファイルが含まれている必要があります。 +- `monitoring_servers`の`rule_dir`フィールドで指定されたフォルダーには、完全な`*.rules.yml`ファイルが含まれている必要があります。 +- `alertmanager_servers`の`config_file`欄に指定するファイルの形式については[Alertmanager 構成テンプレート](https://github.com/pingcap/tiup/blob/master/embed/templates/config/alertmanager.yml)を参照してください。 `tiup reload`を実行すると、 TiUP はまずターゲットマシン上の古い設定ファイルをすべて削除し、次にコントロールマシンから対応する設定ファイルをターゲットマシンの対応する設定ディレクトリにアップロードします。したがって、特定の設定ファイルを変更する場合は、すべての設定ファイル（変更されていないものも含む）が同じディレクトリにあることを確認してください。例えば、Grafana の`tidb.json`ファイルを変更するには、まず Grafana の`dashboards`ディレクトリにある`*.json`ファイルすべてをローカルディレクトリにコピーする必要があります。そうしないと、ターゲットマシンから他の JSON ファイルが失われます。 @@ -429,9 +437,9 @@ alertmanager_servers: > > `dashboard_dir`フィールドを`grafana_servers`に設定した場合、 `tiup cluster rename`コマンドを実行してクラスターの名前を変更した後、次の操作を完了する必要があります。 > -> 1. ローカル`dashboards`ディレクトリで、クラスター名を新しいクラスター名に変更します。 -> 2. ローカルの`dashboards`ディレクトリで、 `datasource`はクラスター名に基づいて命名されているため、 `datasource`を新しいクラスター名に変更します。 -> 3. `tiup cluster reload -R grafana`コマンドを実行します。 +> 1. ローカル`dashboards`ディレクトリで、クラスター名を新しいクラスター名に変更します。 +> 2. ローカルの`dashboards`ディレクトリで、 `datasource`はクラスター名に基づいて命名されているため、 `datasource`を新しいクラスター名に変更します。 +> 3. `tiup cluster reload -R grafana`コマンドを実行します。 ## コンポーネントの更新 {#update-component} @@ -441,26 +449,28 @@ alertmanager_servers: tiup cluster patch --help ``` - Replace the remote package with a specified package and restart the service +``` +Replace the remote package with a specified package and restart the service - Usage: - cluster patch [flags] +Usage: + cluster patch [flags] - Flags: - -h, --help help for patch - -N, --node strings Specify the nodes - --offline Patch a stopped cluster - --overwrite Use this package in the future scale-out operations - -R, --role strings Specify the roles - --transfer-timeout uint Timeout in seconds when transferring PD and TiKV store leaders, also for TiCDC drain one capture (default 600) +Flags: + -h, --help help for patch + -N, --node strings Specify the nodes + --offline Patch a stopped cluster + --overwrite Use this package in the future scale-out operations + -R, --role strings Specify the roles + --transfer-timeout uint Timeout in seconds when transferring PD and TiKV store leaders, also for TiCDC drain one capture (default 600) - Global Flags: - -c, --concurrency int max number of parallel tasks allowed (default 5) - --format string (EXPERIMENTAL) The format of output, available values are [default, json] (default "default") - --ssh string (EXPERIMENTAL) The executor type: 'builtin', 'system', 'none'. - --ssh-timeout uint Timeout in seconds to connect host via SSH, ignored for operations that don't need an SSH connection. (default 5) - --wait-timeout uint Timeout in seconds to wait for an operation to complete, ignored for operations that don't fit. (default 120) - -y, --yes Skip all confirmations and assumes 'yes' +Global Flags: + -c, --concurrency int max number of parallel tasks allowed (default 5) + --format string (EXPERIMENTAL) The format of output, available values are [default, json] (default "default") + --ssh string (EXPERIMENTAL) The executor type: 'builtin', 'system', 'none'. + --ssh-timeout uint Timeout in seconds to connect host via SSH, ignored for operations that don't need an SSH connection. (default 5) + --wait-timeout uint Timeout in seconds to wait for an operation to complete, ignored for operations that don't fit. (default 120) + -y, --yes Skip all confirmations and assumes 'yes' +``` TiDB ホットフィックス パッケージが`/tmp/tidb-hotfix.tar.gz`にあり、クラスター内のすべての TiDB パッケージを置き換える場合は、次のコマンドを実行します。 @@ -484,23 +494,25 @@ TiUPがリリースされる前は、TiDBクラスタのデプロイにTiDB Ansi tiup cluster import --help ``` - Import an exist TiDB cluster from TiDB-Ansible +``` +Import an exist TiDB cluster from TiDB-Ansible - Usage: - cluster import [flags] +Usage: + cluster import [flags] - Flags: - -d, --dir string The path to TiDB-Ansible directory - -h, --help help for import - --inventory string The name of inventory file (default "inventory.ini") - --no-backup Don't backup ansible dir, useful when there're multiple inventory files - -r, --rename NAME Rename the imported cluster to NAME +Flags: + -d, --dir string The path to TiDB-Ansible directory + -h, --help help for import + --inventory string The name of inventory file (default "inventory.ini") + --no-backup Don't backup ansible dir, useful when there're multiple inventory files + -r, --rename NAME Rename the imported cluster to NAME - Global Flags: - --ssh string (Experimental) The executor type. Optional values are 'builtin', 'system', and 'none'. - --wait-timeout int Timeout of waiting the operation - --ssh-timeout int Timeout in seconds to connect host via SSH, ignored for operations that don't need an SSH connection. (default 5) - -y, --yes Skip all confirmations and assumes 'yes' +Global Flags: + --ssh string (Experimental) The executor type. Optional values are 'builtin', 'system', and 'none'. + --wait-timeout int Timeout of waiting the operation + --ssh-timeout int Timeout in seconds to connect host via SSH, ignored for operations that don't need an SSH connection. (default 5) + -y, --yes Skip all confirmations and assumes 'yes' +``` 次のいずれかのコマンドを使用して、TiDB Ansible クラスターをインポートできます。 @@ -531,14 +543,16 @@ Flags: tiup cluster audit ``` - Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.12.3/cluster audit - ID Time Command - -- ---- ------- - 4BLhr0 2025-11-27T23:55:09+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.5.4 /tmp/topology.yaml - 4BKWjF 2025-11-27T23:36:57+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.5.4 /tmp/topology.yaml - 4BKVwH 2025-11-27T23:02:08+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.5.4 /tmp/topology.yaml - 4BKKH1 2025-11-27T16:39:04+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster destroy test - 4BKKDx 2025-11-27T16:36:57+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.5.4 /tmp/topology.yaml +``` +Starting component `cluster`: /home/tidb/.tiup/components/cluster/v1.12.3/cluster audit +ID Time Command +-- ---- ------- +4BLhr0 2025-11-27T23:55:09+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.5.4 /tmp/topology.yaml +4BKWjF 2025-11-27T23:36:57+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.5.4 /tmp/topology.yaml +4BKVwH 2025-11-27T23:02:08+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.5.4 /tmp/topology.yaml +4BKKH1 2025-11-27T16:39:04+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster destroy test +4BKKDx 2025-11-27T16:36:57+08:00 /home/tidb/.tiup/components/cluster/v1.12.3/cluster deploy test v8.5.4 /tmp/topology.yaml +``` 最初の列は`audit-id`です。特定のコマンドの実行ログを表示するには、次のようにコマンドの`audit-id`をフラグとして渡します。 @@ -629,9 +643,9 @@ tiup cluster check --cluster CPUスレッド数チェック、メモリサイズチェック、ディスクパフォ​​ーマンスチェックはデフォルトで無効になっています。本番環境では、最高のパフォーマンスを得るために、これら3つのチェックを有効にし、それらがパスすることを確認することをお勧めします。 -- CPU: スレッド数が 16 以上の場合、チェックに合格します。 -- メモリ: 物理メモリの合計サイズが 32 GB 以上の場合、チェックは合格です。 -- ディスク: `data_dir`のパーティションに対して`fio`テストを実行し、結果を記録します。 +- CPU: スレッド数が 16 以上の場合、チェックに合格します。 +- メモリ: 物理メモリの合計サイズが 32 GB 以上の場合、チェックは合格です。 +- ディスク: `data_dir`のパーティションに対して`fio`テストを実行し、結果を記録します。 チェック実行時にフラグ`--apply`が指定されている場合、プログラムは失敗した項目を自動的に修復します。自動修復は、設定またはシステムパラメータの変更によって調整可能な一部の項目に限定されます。修復されないその他の項目は、実際の状況に応じて手動で処理する必要があります。 @@ -641,14 +655,14 @@ CPUスレッド数チェック、メモリサイズチェック、ディスク クラスタマシン上で実行される上記のすべての操作は、 TiUPに組み込まれたSSHクライアントを使用してクラスタに接続し、コマンドを実行します。ただし、シナリオによっては、制御マシンシステムにネイティブなSSHクライアントを使用してクラスタ操作を実行する必要がある場合もあります。例： -- 認証にSSHプラグインを使用するには -- カスタマイズされたSSHクライアントを使用するには +- 認証にSSHプラグインを使用するには +- カスタマイズされたSSHクライアントを使用するには 次に、 `--ssh=system`コマンドライン フラグを使用して、システムネイティブのコマンドライン ツールを有効にできます。 -- クラスターをデプロイ: `tiup cluster deploy --ssh=system` . ``にクラスターの名前、 ``にデプロイする TiDB バージョン ( `v8.5.4`など)、 ``にトポロジ ファイルを入力します。 -- クラスターを開始する: `tiup cluster start --ssh=system` -- クラスターのアップグレード: `tiup cluster upgrade ... --ssh=system` +- クラスターをデプロイ: `tiup cluster deploy --ssh=system` . ``にクラスターの名前、 ``にデプロイする TiDB バージョン ( `v8.5.4`など)、 ``にトポロジ ファイルを入力します。 +- クラスターを開始する: `tiup cluster start --ssh=system` +- クラスターのアップグレード: `tiup cluster upgrade ... --ssh=system` 上記のすべてのクラスター操作コマンドに`--ssh=system`を追加すると、システムのネイティブ SSH クライアントを使用できます。 @@ -672,10 +686,10 @@ export TIUP_NATIVE_SSH=enable TiUPデータは、ユーザーのホームディレクトリ内の`.tiup`ディレクトリに保存されます。コントロールマシンを移行するには、以下の手順に従って`.tiup`ディレクトリを対応するターゲットマシンにコピーします。 -1. 元のマシンのホームディレクトリで`tar czvf tiup.tar.gz .tiup`を実行します。 -2. `tiup.tar.gz`をターゲット マシンのホーム ディレクトリにコピーします。 -3. 対象マシンのホームディレクトリで`tar xzvf tiup.tar.gz`を実行します。 -4. `.tiup`ディレクトリを`PATH`環境変数に追加します。 +1. 元のマシンのホームディレクトリで`tar czvf tiup.tar.gz .tiup`を実行します。 +2. `tiup.tar.gz`をターゲット マシンのホーム ディレクトリにコピーします。 +3. 対象マシンのホームディレクトリで`tar xzvf tiup.tar.gz`を実行します。 +4. `.tiup`ディレクトリを`PATH`環境変数に追加します。 `bash`を使用し、 `tidb`ユーザーの場合は、 `~/.bashrc`に`export PATH=/home/tidb/.tiup/bin:$PATH`を追加して`source ~/.bashrc`を実行します。その後、使用するシェルとユーザーに応じて調整してください。 diff --git a/tiup/tiup-command-clean.md b/tiup/tiup-command-clean.md index cd7094bf28da7..a0ed808b0effb 100644 --- a/tiup/tiup-command-clean.md +++ b/tiup/tiup-command-clean.md @@ -19,9 +19,9 @@ tiup clean [name] [flags] ### --all {#all} -- すべての操作記録をクリアします -- データ型: ブール値 -- デフォルト: false +- すべての操作記録をクリアします +- データ型: ブール値 +- デフォルト: false ## 出力 {#output} diff --git a/tiup/tiup-command-completion.md b/tiup/tiup-command-completion.md index b3cbeeb81c111..d38a892c7f68c 100644 --- a/tiup/tiup-command-completion.md +++ b/tiup/tiup-command-completion.md @@ -9,8 +9,8 @@ summary: TiUPは、 tiup completionコマンドを使用して、bash`および` `bash`コマンドを実行するには、まず`bash-completion`をインストールする必要があります。以下の手順をご覧ください。 -- macOS の場合: bash バージョンが 4.1 より前の場合は`brew install bash-completion`を実行し、それ以外の場合は`brew install bash-completion@2`を実行します。 -- Linuxの場合：パッケージマネージャーを使用して`bash-completion`インストールします。たとえば、 `yum install bash-completion`または`apt install bash-completion`を実行します。 +- macOS の場合: bash バージョンが 4.1 より前の場合は`brew install bash-completion`を実行し、それ以外の場合は`brew install bash-completion@2`を実行します。 +- Linuxの場合：パッケージマネージャーを使用して`bash-completion`インストールします。たとえば、 `yum install bash-completion`または`apt install bash-completion`を実行します。 ## 構文 {#syntax} diff --git a/tiup/tiup-command-env.md b/tiup/tiup-command-env.md index 641470afcbc92..aabd19e6d7c68 100644 --- a/tiup/tiup-command-env.md +++ b/tiup/tiup-command-env.md @@ -21,8 +21,8 @@ tiup env [name1...N] ## 出力 {#output} -- `[name1...N]`を指定しない場合は「{key}」="{value}"のリストが出力されます。 -- `[name1...N]`を指定した場合は、「{value}」リストが順に出力されます。 +- `[name1...N]`を指定しない場合は「{key}」="{value}"のリストが出力されます。 +- `[name1...N]`を指定した場合は、「{value}」リストが順に出力されます。 上記の出力で、 `value`が空の場合、環境変数の値が設定されていないことを意味します。この場合、 TiUP はデフォルト値を使用します。 diff --git a/tiup/tiup-command-install.md b/tiup/tiup-command-install.md index bf7353f375949..c9f9599df1efd 100644 --- a/tiup/tiup-command-install.md +++ b/tiup/tiup-command-install.md @@ -21,8 +21,8 @@ tiup install [:version] [component2...N] [flags] ## 出力 {#output} -- 通常、コンポーネントのダウンロード情報を出力します。 -- コンポーネントが存在しない場合は、エラー`The component "%s" not found`が報告されます。 -- バージョンが存在しない場合は、エラー`version %s not supported by component %s`が報告されます。 +- 通常、コンポーネントのダウンロード情報を出力します。 +- コンポーネントが存在しない場合は、エラー`The component "%s" not found`が報告されます。 +- バージョンが存在しない場合は、エラー`version %s not supported by component %s`が報告されます。 [<< 前のページに戻る - TiUPリファレンスコマンドリスト](/tiup/tiup-reference.md#command-list) diff --git a/tiup/tiup-command-list.md b/tiup/tiup-command-list.md index de23cd518d00d..5cb7971723945 100644 --- a/tiup/tiup-command-list.md +++ b/tiup/tiup-command-list.md @@ -19,29 +19,29 @@ tiup list [component] [flags] ### --all {#all} -- すべてのコンポーネントを表示します。デフォルトでは、 TiUP は非表示のコンポーネントを表示しません。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- すべてのコンポーネントを表示します。デフォルトでは、 TiUP は非表示のコンポーネントを表示しません。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### --installed {#installed} -- インストールされているコンポーネントとバージョンのみを表示します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- インストールされているコンポーネントとバージョンのみを表示します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### --verbose {#verbose} -- コンポーネント リストにインストールされているコンポーネントのバージョンを表示します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- コンポーネント リストにインストールされているコンポーネントのバージョンを表示します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#outputs} -- `[component]`が設定されていない場合: - - `--verbose`を指定した場合: TiUP は、 `Name` (コンポーネント名)、 `Installed` (インストールされているバージョン)、 `Owner` (コンポーネント所有者)、および`Description` (コンポーネントの説明) で構成されるコンポーネント情報リストを出力します。 - - `--verbose`が指定されていない場合: TiUP は、 `Name` (コンポーネント名)、 `Owner` (コンポーネント所有者)、および`Description` (コンポーネントの説明) で構成されるコンポーネント情報リストを出力します。 -- `[component]`が設定されている場合: - - 指定されたコンポーネントが存在する場合: TiUP は、指定されたコンポーネントのバージョン情報リストを出力します。リストは、 `Version` (バージョン番号)、 `Installed` (インストール状態)、 `Release` (リリース日)、および`Platforms` (サポートされているプラットフォーム) で構成されます。 - - 指定されたコンポーネントが存在しない場合: TiUP はエラー`failed to fetch component: unknown component`を報告します。 +- `[component]`が設定されていない場合: + - `--verbose`を指定した場合: TiUP は、 `Name` (コンポーネント名)、 `Installed` (インストールされているバージョン)、 `Owner` (コンポーネント所有者)、および`Description` (コンポーネントの説明) で構成されるコンポーネント情報リストを出力します。 + - `--verbose`が指定されていない場合: TiUP は、 `Name` (コンポーネント名)、 `Owner` (コンポーネント所有者)、および`Description` (コンポーネントの説明) で構成されるコンポーネント情報リストを出力します。 +- `[component]`が設定されている場合: + - 指定されたコンポーネントが存在する場合: TiUP は、指定されたコンポーネントのバージョン情報リストを出力します。リストは、 `Version` (バージョン番号)、 `Installed` (インストール状態)、 `Release` (リリース日)、および`Platforms` (サポートされているプラットフォーム) で構成されます。 + - 指定されたコンポーネントが存在しない場合: TiUP はエラー`failed to fetch component: unknown component`を報告します。 [<< 前のページに戻る - TiUPリファレンスコマンドリスト](/tiup/tiup-reference.md#command-list) diff --git a/tiup/tiup-command-mirror-clone.md b/tiup/tiup-command-mirror-clone.md index cf3ca92f13f3e..674d18f728a48 100644 --- a/tiup/tiup-command-mirror-clone.md +++ b/tiup/tiup-command-mirror-clone.md @@ -13,39 +13,39 @@ summary: tiup mirror clone`コマンドは、既存のミラーまたはその tiup mirror clone [global version] [flags] ``` -- `` 、クローンミラーへのローカルパスを設定するために使用されます。パスが存在しない場合は、 TiUPによって自動的に作成されます。 -- `[global version]`を指定した場合、 TiUP は指定されたバージョンのすべてのコンポーネントのクローンを作成しようとします。指定されたバージョンを持たないコンポーネントがある場合は、 TiUP はその最新バージョンのクローンを作成します。 +- `` 、クローンミラーへのローカルパスを設定するために使用されます。パスが存在しない場合は、 TiUPによって自動的に作成されます。 +- `[global version]`を指定した場合、 TiUP は指定されたバージョンのすべてのコンポーネントのクローンを作成しようとします。指定されたバージョンを持たないコンポーネントがある場合は、 TiUP はその最新バージョンのクローンを作成します。 ## オプション {#options} ### -f, --full {#f-full} -- ミラー全体をクローンするかどうか。このオプションを設定すると、他のオプションは無視され、 TiUP は対象のミラーからすべてのバージョンのすべてのコンポーネントを完全にクローンします。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- ミラー全体をクローンするかどうか。このオプションを設定すると、他のオプションは無視され、 TiUP は対象のミラーからすべてのバージョンのすべてのコンポーネントを完全にクローンします。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### -a, --arch {#a-arch} -- 指定されたプラットフォームで実行できるコンポーネントのみを複製します。 -- データ型: `STRING` -- デフォルト: "amd64,arm64" +- 指定されたプラットフォームで実行できるコンポーネントのみを複製します。 +- データ型: `STRING` +- デフォルト: "amd64,arm64" ### -o, --os {#o-os} -- 指定されたオペレーティング システムで実行できるコンポーネントのみを複製します。 -- データ型: `STRING` -- デフォルト: "linux,darwin" +- 指定されたオペレーティング システムで実行できるコンポーネントのみを複製します。 +- データ型: `STRING` +- デフォルト: "linux,darwin" ### --prefix {#prefix} -- バージョンのプレフィックスのみを一致させるかどうか。デフォルトでは、 TiUP は厳密に一致するコンポーネントバージョンをダウンロードします。このオプションを設定すると、プレフィックスが一致するコンポーネントバージョンもダウンロードされます。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- バージョンのプレフィックスのみを一致させるかどうか。デフォルトでは、 TiUP は厳密に一致するコンポーネントバージョンをダウンロードします。このオプションを設定すると、プレフィックスが一致するコンポーネントバージョンもダウンロードされます。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### --{component} {#component} -- クローンするコンポーネントのバージョンリストを指定します。`{component}`にコンポーネント名を入力してください。[`tiup list --all`](/tiup/tiup-command-list.md)を実行すると、使用可能なコンポーネント名が表示されます。 -- データ型: 文字列 -- デフォルト: Null +- クローンするコンポーネントのバージョンリストを指定します。`{component}`にコンポーネント名を入力してください。[`tiup list --all`](/tiup/tiup-command-list.md)を実行すると、使用可能なコンポーネント名が表示されます。 +- データ型: 文字列 +- デフォルト: Null [<< 前のページに戻る - TiUPミラーコマンドリスト](/tiup/tiup-command-mirror.md#command-list) diff --git a/tiup/tiup-command-mirror-genkey.md b/tiup/tiup-command-mirror-genkey.md index 31a96ca934b65..960fc867dbef5 100644 --- a/tiup/tiup-command-mirror-genkey.md +++ b/tiup/tiup-command-mirror-genkey.md @@ -7,9 +7,9 @@ summary: TiUP mirror genkey は、 TiUP用の秘密鍵を生成するための TiUP [ミラー](/tiup/tiup-mirror-reference.md)の定義によれば、ユーザーには 3 つの役割があります。 -- ミラー管理者: `root.json` 、 `index.json` 、 `snapshot.json` 、 `timestamp.json`を変更する権限があります。 -- コンポーネント所有者: 対応するコンポーネントを変更する権限を持ちます。 -- 通常ユーザー: コンポーネントをダウンロードして使用できます。 +- ミラー管理者: `root.json` 、 `index.json` 、 `snapshot.json` 、 `timestamp.json`を変更する権限があります。 +- コンポーネント所有者: 対応するコンポーネントを変更する権限を持ちます。 +- 通常ユーザー: コンポーネントをダウンロードして使用できます。 TiUPファイルを変更するには対応する所有者/管理者の署名が必要となるため、所有者/管理者は独自の秘密鍵を保有している必要があります。コマンド`tiup mirror genkey`は秘密鍵を生成するために使用されます。 @@ -27,30 +27,30 @@ tiup mirror genkey [flags] ### -n, --name {#n-name} -- キーの名前を指定します。この名前は、最終的に生成されるファイルの名前も決定します。生成される秘密鍵ファイルのパスは`${TIUP_HOME}/keys/{name}.json`です。 `TIUP_HOME`は TiUPのホームディレクトリ（デフォルトでは`$HOME/.tiup`を指します。 `name`は `-n/--name`で指定される秘密鍵の名前を指します。 -- データ型: `STRING` -- デフォルト:「private」 +- キーの名前を指定します。この名前は、最終的に生成されるファイルの名前も決定します。生成される秘密鍵ファイルのパスは`${TIUP_HOME}/keys/{name}.json`です。 `TIUP_HOME`は TiUPのホームディレクトリ（デフォルトでは`$HOME/.tiup`を指します。 `name`は `-n/--name`で指定される秘密鍵の名前を指します。 +- データ型: `STRING` +- デフォルト:「private」 ### -p, --public {#p-public} -- オプション`-n/--name`で指定された秘密鍵に対応する公開鍵を表示します。 -- `-p/--public`が指定された場合、 TiUP は新しい秘密鍵を作成しません。`-n/--name`で指定された秘密鍵が存在しない場合、 TiUP はエラーを返します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- オプション`-n/--name`で指定された秘密鍵に対応する公開鍵を表示します。 +- `-p/--public`が指定された場合、 TiUP は新しい秘密鍵を作成しません。`-n/--name`で指定された秘密鍵が存在しない場合、 TiUP はエラーを返します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### --save {#save} -- 公開鍵の情報を現在のディレクトリにファイルとして保存します。ファイル名は`{hash-prefix}-public.json`です。`hash-prefix`は鍵IDの最初の16ビットです。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- 公開鍵の情報を現在のディレクトリにファイルとして保存します。ファイル名は`{hash-prefix}-public.json`です。`hash-prefix`は鍵IDの最初の16ビットです。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#outputs} -- `-p/--public`が指定されていない場合: - - `-n/--name`で指定された秘密鍵が存在する場合: TiUP は`Key already exists, skipped`を出力します。 - - `-n/--name`で指定された秘密鍵が存在しない場合: TiUP は`private key have been write to ${TIUP_HOME}/keys/{name}.json`を出力します。 -- `-p/--public`を指定した場合: - - `-n/--name`で指定された秘密鍵が存在しない場合: TiUP はエラー`Error: open ${TIUP_HOME}/keys/{name}.json: no such file or directory`を報告します。 - - `-n/--name`で指定された秘密鍵が存在する場合： TiUPは対応する公開鍵の内容を出力します。 +- `-p/--public`が指定されていない場合: + - `-n/--name`で指定された秘密鍵が存在する場合: TiUP は`Key already exists, skipped`を出力します。 + - `-n/--name`で指定された秘密鍵が存在しない場合: TiUP は`private key have been write to ${TIUP_HOME}/keys/{name}.json`を出力します。 +- `-p/--public`を指定した場合: + - `-n/--name`で指定された秘密鍵が存在しない場合: TiUP はエラー`Error: open ${TIUP_HOME}/keys/{name}.json: no such file or directory`を報告します。 + - `-n/--name`で指定された秘密鍵が存在する場合： TiUPは対応する公開鍵の内容を出力します。 [<< 前のページに戻る - TiUPミラーコマンドリスト](/tiup/tiup-command-mirror.md#command-list) diff --git a/tiup/tiup-command-mirror-grant.md b/tiup/tiup-command-mirror-grant.md index 2cecc2117da7f..87d453f368b9a 100644 --- a/tiup/tiup-command-mirror-grant.md +++ b/tiup/tiup-command-mirror-grant.md @@ -25,21 +25,21 @@ tiup mirror grant [flags] ### -k, --key {#k-key} -- 導入されたコンポーネントの所有者のキーを指定します。このキーは公開キーまたは秘密キーのいずれかです。秘密キーの場合、 TiUP はそれを対応する公開キーに変換してからミラーに保存します。 -- キーは 1 つのコンポーネント所有者のみが使用できます。 -- データ型: `STRING` -- デフォルト: "${TIUP_HOME}/keys/private.json" +- 導入されたコンポーネントの所有者のキーを指定します。このキーは公開キーまたは秘密キーのいずれかです。秘密キーの場合、 TiUP はそれを対応する公開キーに変換してからミラーに保存します。 +- キーは 1 つのコンポーネント所有者のみが使用できます。 +- データ型: `STRING` +- デフォルト: "${TIUP_HOME}/keys/private.json" ### -n, --name {#n-name} -- コンポーネント所有者の名前を指定します。名前はコンポーネントリストの`Owner`フィールドに表示されます。`-n/--name`が指定されていない場合は、 ``がコンポーネント所有者の名前として使用されます。 -- データ型: `STRING` -- デフォルト: `` +- コンポーネント所有者の名前を指定します。名前はコンポーネントリストの`Owner`フィールドに表示されます。`-n/--name`が指定されていない場合は、 ``がコンポーネント所有者の名前として使用されます。 +- データ型: `STRING` +- デフォルト: `` ### 出力 {#outputs} -- コマンドが正常に実行された場合、出力はありません。 -- コンポーネント所有者の ID が重複している場合、 TiUP はエラー`Error: owner %s exists`報告します。 -- キーが別のコンポーネント所有者によって使用されている場合、 TiUP はエラー`Error: key %s exists`報告します。 +- コマンドが正常に実行された場合、出力はありません。 +- コンポーネント所有者の ID が重複している場合、 TiUP はエラー`Error: owner %s exists`報告します。 +- キーが別のコンポーネント所有者によって使用されている場合、 TiUP はエラー`Error: key %s exists`報告します。 [<< 前のページに戻る - TiUPミラーコマンドリスト](/tiup/tiup-command-mirror.md#command-list) diff --git a/tiup/tiup-command-mirror-init.md b/tiup/tiup-command-mirror-init.md index c25bb0c6eea23..fef572e09f66a 100644 --- a/tiup/tiup-command-mirror-init.md +++ b/tiup/tiup-command-mirror-init.md @@ -34,14 +34,14 @@ tiup mirror init [flags] ### -k, --key-dir {#k-key-dir} -- TiUPが秘密鍵ファイルを生成するディレクトリを指定します。指定されたディレクトリが存在しない場合は、 TiUPが自動的に作成します。 -- データ型: `STRING` -- コマンドでこのオプションを指定しない場合、 TiUP はデフォルトで`{path}/keys`に秘密鍵ファイルを生成します。 +- TiUPが秘密鍵ファイルを生成するディレクトリを指定します。指定されたディレクトリが存在しない場合は、 TiUPが自動的に作成します。 +- データ型: `STRING` +- コマンドでこのオプションを指定しない場合、 TiUP はデフォルトで`{path}/keys`に秘密鍵ファイルを生成します。 ### 出力 {#outputs} -- コマンドが正常に実行された場合、出力はありません。 -- 指定された``空でない場合、 TiUP はエラー`Error: the target path '%s' is not an empty directory`報告します。 -- 指定された``ディレクトリでない場合、 TiUP はエラー`Error: fdopendir: not a directory`報告します。 +- コマンドが正常に実行された場合、出力はありません。 +- 指定された``空でない場合、 TiUP はエラー`Error: the target path '%s' is not an empty directory`報告します。 +- 指定された``ディレクトリでない場合、 TiUP はエラー`Error: fdopendir: not a directory`報告します。 [<< 前のページに戻る - TiUPミラーコマンドリスト](/tiup/tiup-command-mirror.md#command-list) diff --git a/tiup/tiup-command-mirror-merge.md b/tiup/tiup-command-mirror-merge.md index b5bd6133e1a98..49e18ad818d61 100644 --- a/tiup/tiup-command-mirror-merge.md +++ b/tiup/tiup-command-mirror-merge.md @@ -9,8 +9,8 @@ summary: 「tiup mirror merge」コマンドは、1つまたは複数のミラ このコマンドを実行するには、次の条件を満たしている必要があります。 -- ターゲット ミラーのすべてのコンポーネントの所有者 ID が現在のミラーに存在します。 -- このコマンドを実行するユーザーの`${TIUP_HOME}/keys`ディレクトリには、現在のミラー内の上記の所有者 ID に対応するすべての秘密鍵が含まれています (コマンド[`tiup mirror set`](/tiup/tiup-command-mirror-set.md)を使用して、現在のミラーを現在変更が許可されているミラーに切り替えることができます)。 +- ターゲット ミラーのすべてのコンポーネントの所有者 ID が現在のミラーに存在します。 +- このコマンドを実行するユーザーの`${TIUP_HOME}/keys`ディレクトリには、現在のミラー内の上記の所有者 ID に対応するすべての秘密鍵が含まれています (コマンド[`tiup mirror set`](/tiup/tiup-command-mirror-set.md)を使用して、現在のミラーを現在変更が許可されているミラーに切り替えることができます)。 ## 構文 {#syntax} @@ -18,8 +18,8 @@ summary: 「tiup mirror merge」コマンドは、1つまたは複数のミラ tiup mirror merge [mirror-dir-N] [flags] ``` -- `` : 現在のミラーにマージされる最初のミラー -- `[mirror-dir-N]` : 現在のミラーにマージされる N 番目のミラー +- `` : 現在のミラーにマージされる最初のミラー +- `[mirror-dir-N]` : 現在のミラーにマージされる N 番目のミラー ## オプション {#option} @@ -27,7 +27,7 @@ tiup mirror merge [mirror-dir-N] [flags] ## 出力 {#outputs} -- コマンドが正常に実行された場合、出力はありません。 -- 現在のミラーにターゲット ミラーのコンポーネント所有者がいない場合、または`${TIUP_HOME}/keys`に所有者の秘密キーがない場合、 TiUP は`Error: missing owner keys for owner %s on component %s`エラーを報告します。 +- コマンドが正常に実行された場合、出力はありません。 +- 現在のミラーにターゲット ミラーのコンポーネント所有者がいない場合、または`${TIUP_HOME}/keys`に所有者の秘密キーがない場合、 TiUP は`Error: missing owner keys for owner %s on component %s`エラーを報告します。 [<< 前のページに戻る - TiUPミラーコマンドリスト](/tiup/tiup-command-mirror.md#command-list) diff --git a/tiup/tiup-command-mirror-modify.md b/tiup/tiup-command-mirror-modify.md index fba67347f2c5b..e15551492360d 100644 --- a/tiup/tiup-command-mirror-modify.md +++ b/tiup/tiup-command-mirror-modify.md @@ -15,31 +15,31 @@ tiup mirror modify [:version] [flags] 各パラメータの説明は次のとおりです。 -- `` :コンポーネント名 -- `[version]` : 変更するコンポーネントのバージョン。指定されていない場合は、コンポーネント全体が変更されます。 +- `` :コンポーネント名 +- `[version]` : 変更するコンポーネントのバージョン。指定されていない場合は、コンポーネント全体が変更されます。 ## オプション {#options} ### -k, --key {#k-key} -- コンポーネント情報の署名に使用されるコンポーネント所有者の秘密鍵を指定する（ `{component}.json` ）。 -- データ型: `STRING` -- コマンドでこのオプションが指定されていない場合、コンポーネント情報の署名にはデフォルトで`"${TIUP_HOME}/keys/private.json"`が使用されます。 +- コンポーネント情報の署名に使用されるコンポーネント所有者の秘密鍵を指定する（ `{component}.json` ）。 +- データ型: `STRING` +- コマンドでこのオプションが指定されていない場合、コンポーネント情報の署名にはデフォルトで`"${TIUP_HOME}/keys/private.json"`が使用されます。 ### --yank {#yank} 指定されたコンポーネントまたはバージョンを使用不可としてマークします。 -- コンポーネントが使用不可としてマークされると、そのコンポーネントは`tiup list`の結果リストに表示されなくなり、コンポーネントの新しいバージョンをインストールすることもできなくなります。 -- コンポーネントバージョンが使用不可としてマークされると、そのバージョンは`tiup list `の結果リストに表示されず、インストールもできなくなります。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- コンポーネントが使用不可としてマークされると、そのコンポーネントは`tiup list`の結果リストに表示されなくなり、コンポーネントの新しいバージョンをインストールすることもできなくなります。 +- コンポーネントバージョンが使用不可としてマークされると、そのバージョンは`tiup list `の結果リストに表示されず、インストールもできなくなります。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### --hide {#hide} -- コンポーネントを非表示にするかどうかを指定します。コンポーネントが非表示の場合、 `tiup list`の結果リストには表示されません。非表示のコンポーネントを表示するには、 `tiup list --all`を使用します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- コンポーネントを非表示にするかどうかを指定します。コンポーネントが非表示の場合、 `tiup list`の結果リストには表示されません。非表示のコンポーネントを表示するには、 `tiup list --all`を使用します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 > **Note:** > @@ -47,9 +47,9 @@ tiup mirror modify [:version] [flags] ### --standalone {#standalone} -- コンポーネントをスタンドアロンで実行できるかどうかを制御します。このオプションは現在**利用できません**。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- コンポーネントをスタンドアロンで実行できるかどうかを制御します。このオプションは現在**利用できません**。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 > **Note:** > @@ -57,9 +57,9 @@ tiup mirror modify [:version] [flags] ## 出力 {#outputs} -- コマンドが正常に実行された場合、出力はありません。 -- コンポーネント所有者にターゲットコンポーネントを変更する権限がない場合: - - ミラーがリモート ミラーの場合、 TiUP はエラー`Error: The server refused, make sure you have access to this component`を報告します。 - - ミラーがローカル ミラーの場合、 TiUP はエラー`Error: the signature is not correct`を報告します。 +- コマンドが正常に実行された場合、出力はありません。 +- コンポーネント所有者にターゲットコンポーネントを変更する権限がない場合: + - ミラーがリモート ミラーの場合、 TiUP はエラー`Error: The server refused, make sure you have access to this component`を報告します。 + - ミラーがローカル ミラーの場合、 TiUP はエラー`Error: the signature is not correct`を報告します。 [<< 前のページに戻る - TiUPミラーコマンドリスト](/tiup/tiup-command-mirror.md#command-list) diff --git a/tiup/tiup-command-mirror-publish.md b/tiup/tiup-command-mirror-publish.md index 06704fbb210b4..a80b122a9691a 100644 --- a/tiup/tiup-command-mirror-publish.md +++ b/tiup/tiup-command-mirror-publish.md @@ -15,30 +15,30 @@ tiup mirror publish [flags] 各パラメータの意味は次のとおりです。 -- `` : コンポーネントの名前（例： `tidb` ）。正規表現`^[a-z\d](?:[a-z\d]|-(?=[a-z\d])){0,38}$`に一致する文字列を使用することをお勧めします。 -- `` : 公開するコンポーネントのバージョン。バージョン番号は[セマンティックバージョニング](https://semver.org/)の要件に従う必要があります。 -- `` : パッケージ`.tar.gz`のローカルディレクトリ。このパッケージには、依存関係とコンポーネントの実行ファイルを格納する必要があります。TiUPはこのパッケージをミラーにアップロードします。 -- `` : ``内のコンポーネントの実行可能ファイルの場所。 +- `` : コンポーネントの名前（例： `tidb` ）。正規表現`^[a-z\d](?:[a-z\d]|-(?=[a-z\d])){0,38}$`に一致する文字列を使用することをお勧めします。 +- `` : 公開するコンポーネントのバージョン。バージョン番号は[セマンティックバージョニング](https://semver.org/)の要件に従う必要があります。 +- `` : パッケージ`.tar.gz`のローカルディレクトリ。このパッケージには、依存関係とコンポーネントの実行ファイルを格納する必要があります。TiUPはこのパッケージをミラーにアップロードします。 +- `` : ``内のコンポーネントの実行可能ファイルの場所。 ## オプション {#options} ### -k, --key {#k-key} -- コンポーネント所有者の秘密鍵を指定します。クライアントは秘密鍵を使用して`{component}.json`ファイルに署名します。 -- データ型: `STRING` -- デフォルト: "${TIUP_HOME}/keys/private.json" +- コンポーネント所有者の秘密鍵を指定します。クライアントは秘密鍵を使用して`{component}.json`ファイルに署名します。 +- データ型: `STRING` +- デフォルト: "${TIUP_HOME}/keys/private.json" ### - アーチ {#arch} -- ``のバイナリファイルが実行できるプラットフォームを指定します。単一の``パッケージの場合、プラットフォームは以下のオプションからのみ選択できます。 +- ``のバイナリファイルが実行できるプラットフォームを指定します。単一の``パッケージの場合、プラットフォームは以下のオプションからのみ選択できます。 - - `amd64` : ファイルが AMD64 マシンで実行されることを示します。 - - `arm64` : ファイルが ARM64 マシンで実行されることを示します。 - - `any` : スクリプトなどのファイルが AMD64 マシンと ARM64 マシンの両方で実行されることを示します。 + - `amd64` : ファイルが AMD64 マシンで実行されることを示します。 + - `arm64` : ファイルが ARM64 マシンで実行されることを示します。 + - `any` : スクリプトなどのファイルが AMD64 マシンと ARM64 マシンの両方で実行されることを示します。 -- データ型: `STRING` +- データ型: `STRING` -- デフォルト: "${GOARCH}" +- デフォルト: "${GOARCH}" > **Note:** > @@ -46,15 +46,15 @@ tiup mirror publish [flags] ### --os {#os} -- ``のバイナリファイルが実行できるオペレーティングシステムを指定します。``パッケージの場合、オペレーティングシステムは以下のオプションからのみ選択できます。 +- ``のバイナリファイルが実行できるオペレーティングシステムを指定します。``パッケージの場合、オペレーティングシステムは以下のオプションからのみ選択できます。 - - `linux` : ファイルが Linux オペレーティング システムで実行されることを示します。 - - `darwin` : ファイルが Darwin オペレーティング システムで実行されることを示します。 - - `any` : スクリプトなどのファイルが Linux と Darwin の両方のオペレーティング システムで実行されることを示します。 + - `linux` : ファイルが Linux オペレーティング システムで実行されることを示します。 + - `darwin` : ファイルが Darwin オペレーティング システムで実行されることを示します。 + - `any` : スクリプトなどのファイルが Linux と Darwin の両方のオペレーティング システムで実行されることを示します。 -- データ型: `STRING` +- データ型: `STRING` -- デフォルト: "${GOOS}" +- デフォルト: "${GOOS}" > **Note:** > @@ -62,27 +62,27 @@ tiup mirror publish [flags] ### --desc {#desc} -- コンポーネントの説明を指定します。 -- データ型: `String` -- デフォルト: NULL +- コンポーネントの説明を指定します。 +- データ型: `String` +- デフォルト: NULL ### - 隠れる {#hide} -- コンポーネントが非表示かどうかを指定します。非表示のコンポーネントの場合、 `tiup list -all`の結果リストには表示されますが、 `tiup list`の結果リストには表示されません。 -- データ型: `STRING` -- デフォルト: NULL +- コンポーネントが非表示かどうかを指定します。非表示のコンポーネントの場合、 `tiup list -all`の結果リストには表示されますが、 `tiup list`の結果リストには表示されません。 +- データ型: `STRING` +- デフォルト: NULL ### --standalone {#standalone} -- コンポーネントをスタンドアロンで実行できるかどうかを制御します。このオプションは現在**利用できません**。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- コンポーネントをスタンドアロンで実行できるかどうかを制御します。このオプションは現在**利用できません**。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#outputs} -- コマンドが正常に実行された場合、出力はありません。 -- コンポーネント所有者にターゲットコンポーネントを変更する権限がない場合: - - ミラーがリモート ミラーの場合、 TiUP はエラー`Error: The server refused, make sure you have access to this component`報告します。 - - ミラーがローカル ミラーの場合、 TiUP はエラー`Error: the signature is not correct`報告します。 +- コマンドが正常に実行された場合、出力はありません。 +- コンポーネント所有者にターゲットコンポーネントを変更する権限がない場合: + - ミラーがリモート ミラーの場合、 TiUP はエラー`Error: The server refused, make sure you have access to this component`報告します。 + - ミラーがローカル ミラーの場合、 TiUP はエラー`Error: the signature is not correct`報告します。 [<< 前のページに戻る - TiUPミラーコマンドリスト](/tiup/tiup-command-mirror.md#command-list) diff --git a/tiup/tiup-command-mirror-rotate.md b/tiup/tiup-command-mirror-rotate.md index 5844cff05965b..82849b6ab4036 100644 --- a/tiup/tiup-command-mirror-rotate.md +++ b/tiup/tiup-command-mirror-rotate.md @@ -7,36 +7,36 @@ summary: TiUPミラーローテートは、 TiUPミラー内のroot.jsonファ `root.json`はTiUPミラーにおける重要なファイルです。システム全体に必要な公開鍵が格納され、 TiUPにおける信頼チェーンの基盤となります。主に以下の部分から構成されます。 -- ミラー管理者の署名。公式ミラーの場合、署名は5つあります。初期化されたミラーの場合、デフォルトで署名は3つあります。 -- 次のファイルを検証するために使用される公開鍵: - - root.json - - index.json - - snapshot.json - - timestamp.json -- `root.json`の有効期限。公式ミラーの場合、有効期限は作成日`root.json`の 1 年後となります。 +- ミラー管理者の署名。公式ミラーの場合、署名は5つあります。初期化されたミラーの場合、デフォルトで署名は3つあります。 +- 次のファイルを検証するために使用される公開鍵: + - root.json + - index.json + - snapshot.json + - timestamp.json +- `root.json`の有効期限。公式ミラーの場合、有効期限は作成日`root.json`の 1 年後となります。 TiUPミラーの詳細については、 [TiUPミラーリファレンス](/tiup/tiup-mirror-reference.md)を参照してください。 以下の場合には`root.json`を更新する必要があります。 -- ミラーのキーを交換してください。 -- 証明書ファイルの有効期限を更新します。 +- ミラーのキーを交換してください。 +- 証明書ファイルの有効期限を更新します。 `root.json`の内容が更新された後、ファイルはすべての管理者によって再署名される必要があります。そうでない場合、クライアントはファイルを拒否します。更新プロセスは以下のとおりです。 -1. ユーザー（クライアント）は`root.json`のコンテンツを更新します。 -2. すべての管理者が新しい`root.json`ファイルに署名します。 -3. tiup-server は`snapshot.json`を更新して、新しい`root.json`ファイルのバージョンを記録します。 -4. tiup-server は新しい`snapshot.json`ファイルに署名します。 -5. tiup-server は`timestamp.json`を更新して、新しい`snapshot.json`ファイルのハッシュ値を記録します。 -6. tiup-server は新しい`timestamp.json`ファイルに署名します。 +1. ユーザー（クライアント）は`root.json`のコンテンツを更新します。 +2. すべての管理者が新しい`root.json`ファイルに署名します。 +3. tiup-server は`snapshot.json`を更新して、新しい`root.json`ファイルのバージョンを記録します。 +4. tiup-server は新しい`snapshot.json`ファイルに署名します。 +5. tiup-server は`timestamp.json`を更新して、新しい`snapshot.json`ファイルのハッシュ値を記録します。 +6. tiup-server は新しい`timestamp.json`ファイルに署名します。 TiUP はコマンド`tiup mirror rotate`を使用して上記のプロセスを自動化します。 > **Note:** > -> - TiUPバージョン1.5.0より前のバージョンでは、このコマンドを実行しても正しい新しい`root.json`ファイルが返されません。[＃983](https://github.com/pingcap/tiup/issues/983)を参照してください。 -> - このコマンドを使用する前に、すべてのTiUPクライアントが v1.5.0 以降のバージョンにアップグレードされていることを確認してください。 +> - TiUPバージョン1.5.0より前のバージョンでは、このコマンドを実行しても正しい新しい`root.json`ファイルが返されません。[＃983](https://github.com/pingcap/tiup/issues/983)を参照してください。 +> - このコマンドを使用する前に、すべてのTiUPクライアントが v1.5.0 以降のバージョンにアップグレードされていることを確認してください。 ## 構文 {#syntax} @@ -52,9 +52,9 @@ tiup mirror rotate [flags] ### --addr {#addr} -- 一時サーバーのリスニングアドレスを指定します。他のミラー管理者が[`sign`コマンド](/tiup/tiup-command-mirror-sign.md)を使用してファイルに署名できるように、このアドレスにアクセスできることを確認する必要があります。 -- データ型: `STRING` -- コマンドでこのオプションを指定しない場合、 TiUP はデフォルトで`0.0.0.0:8080`でリッスンします。 +- 一時サーバーのリスニングアドレスを指定します。他のミラー管理者が[`sign`コマンド](/tiup/tiup-command-mirror-sign.md)を使用してファイルに署名できるように、このアドレスにアクセスできることを確認する必要があります。 +- データ型: `STRING` +- コマンドでこのオプションを指定しない場合、 TiUP はデフォルトで`0.0.0.0:8080`でリッスンします。 ## 出力 {#outputs} diff --git a/tiup/tiup-command-mirror-set.md b/tiup/tiup-command-mirror-set.md index 3ac4da9e03f33..a33af6964f9f9 100644 --- a/tiup/tiup-command-mirror-set.md +++ b/tiup/tiup-command-mirror-set.md @@ -17,8 +17,8 @@ tiup mirror set [flags] ``はミラー アドレスであり、次の 2 つの形式があります。 -- ネットワークアドレス: `http`または`https`で始まります。例: `http://172.16.5.5:8080` 、 `https://tiup-mirrors.pingcap.com` 。 -- ローカルファイルパス: ミラーディレクトリの絶対パス。例: `/path/to/local-tiup-mirror` 。 +- ネットワークアドレス: `http`または`https`で始まります。例: `http://172.16.5.5:8080` 、 `https://tiup-mirrors.pingcap.com` 。 +- ローカルファイルパス: ミラーディレクトリの絶対パス。例: `/path/to/local-tiup-mirror` 。 ## オプション {#option} @@ -40,8 +40,8 @@ tiup mirror set -r /path/to/local/root.json 上記の手順では、 `wget`コマンドの前にミラーが攻撃された場合、ルート証明書が正しくないことが分かります。`wget`コマンドの後にミラーが攻撃された場合、 TiUPはミラーがルート証明書と一致しないことを検出します。 -- データ型: `String` -- デフォルト: `{mirror-dir}/root.json` +- データ型: `String` +- デフォルト: `{mirror-dir}/root.json` ## 出力 {#output} diff --git a/tiup/tiup-command-mirror-sign.md b/tiup/tiup-command-mirror-sign.md index 5662df4889b30..949fac409b4ee 100644 --- a/tiup/tiup-command-mirror-sign.md +++ b/tiup/tiup-command-mirror-sign.md @@ -15,27 +15,27 @@ tiup mirror sign [flags] ``は署名するファイルのアドレスであり、次の 2 つの形式があります。 -- HTTPまたはHTTPSで始まるネットワークアドレス（例： `http://172.16.5.5:8080/rotate/root.json` -- ローカルファイルパス（相対パスまたは絶対パス） +- HTTPまたはHTTPSで始まるネットワークアドレス（例： `http://172.16.5.5:8080/rotate/root.json` +- ローカルファイルパス（相対パスまたは絶対パス） ネットワーク アドレスの場合、このアドレスは次の機能を提供する必要があります。 -- 署名されたファイルの完全な内容 ( `signatures`フィールドを含む) を返す`http get`経由のアクセスをサポートします。 -- `http post`経由のアクセスをサポートします。クライアントは`http get`から返されたコンテンツの`signatures`フィールドに署名を追加し、このネットワークアドレスに投稿します。 +- 署名されたファイルの完全な内容 ( `signatures`フィールドを含む) を返す`http get`経由のアクセスをサポートします。 +- `http post`経由のアクセスをサポートします。クライアントは`http get`から返されたコンテンツの`signatures`フィールドに署名を追加し、このネットワークアドレスに投稿します。 ## オプション {#options} ### -k, --key {#k-key} -- `{component}.json`ファイルの署名に使用される秘密キーの場所を指定します。 -- データ型: `STRING` -- - このオプションがコマンドで指定されていない場合は、デフォルトで`"${TIUP_HOME}/keys/private.json"`が使用されます。 +- `{component}.json`ファイルの署名に使用される秘密キーの場所を指定します。 +- データ型: `STRING` +- - このオプションがコマンドで指定されていない場合は、デフォルトで`"${TIUP_HOME}/keys/private.json"`が使用されます。 ### - タイムアウト {#timeout} -- ネットワーク経由での署名のアクセスタイムアウト時間を指定します。単位は秒です。 -- データ型: `INT` -- デフォルト: 10 +- ネットワーク経由での署名のアクセスタイムアウト時間を指定します。単位は秒です。 +- データ型: `INT` +- デフォルト: 10 > **Note:** > @@ -43,8 +43,8 @@ tiup mirror sign [flags] ## 出力 {#output} -- コマンドが正常に実行された場合、出力はありません。 -- ファイルが指定されたキーで署名されている場合、 TiUP はエラー`Error: this manifest file has already been signed by specified key`報告します。 -- ファイルが有効なマニフェストでない場合、 TiUP はエラー`Error: unmarshal manifest: %s`報告します。 +- コマンドが正常に実行された場合、出力はありません。 +- ファイルが指定されたキーで署名されている場合、 TiUP はエラー`Error: this manifest file has already been signed by specified key`報告します。 +- ファイルが有効なマニフェストでない場合、 TiUP はエラー`Error: unmarshal manifest: %s`報告します。 [<< 前のページに戻る - TiUPミラーコマンドリスト](/tiup/tiup-command-mirror.md#command-list) diff --git a/tiup/tiup-command-mirror.md b/tiup/tiup-command-mirror.md index e8e72f7cffbaa..94caf374b8753 100644 --- a/tiup/tiup-command-mirror.md +++ b/tiup/tiup-command-mirror.md @@ -7,8 +7,8 @@ summary: TiUPミラーはTiUPの重要な概念であり、ローカルおよび TiUPでは、 [ミラー](/tiup/tiup-mirror-reference.md)は重要な概念です。TiUPは現在、2つの形式のミラーリングをサポートしています。 -- ローカル ミラー: TiUPクライアントとミラーは同じマシン上にあり、クライアントはファイル システムを介してミラーにアクセスします。 -- リモート ミラー: TiUPクライアントとミラーは同じマシン上に存在せず、クライアントはネットワーク経由でミラーにアクセスします。 +- ローカル ミラー: TiUPクライアントとミラーは同じマシン上にあり、クライアントはファイル システムを介してミラーにアクセスします。 +- リモート ミラー: TiUPクライアントとミラーは同じマシン上に存在せず、クライアントはネットワーク経由でミラーにアクセスします。 `tiup mirror`コマンドはミラーの管理に使用され、ミラーの作成、コンポーネントの配布、キーの管理を行う方法を提供します。 @@ -26,15 +26,15 @@ tiup mirror [flags] ## コマンドリスト {#command-list} -- [genkey](/tiup/tiup-command-mirror-genkey.md) : 秘密鍵ファイルを生成する -- [sign](/tiup/tiup-command-mirror-sign.md) : 秘密鍵ファイルを使用して特定のファイルに署名します -- [init](/tiup/tiup-command-mirror-init.md) : 空のミラーを開始する -- [set](/tiup/tiup-command-mirror-set.md) : 現在のミラーを設定する -- [grant](/tiup/tiup-command-mirror-grant.md) : 現在のミラーに新しいコンポーネント所有者を付与します -- [publish](/tiup/tiup-command-mirror-publish.md) : 新しいコンポーネントを現在のミラーに公開します -- [modify](/tiup/tiup-command-mirror-modify.md) : 現在のミラー内のコンポーネントの属性を変更します -- [rotate](/tiup/tiup-command-mirror-rotate.md) : 現在のミラーのルート証明書を更新します -- [clone](/tiup/tiup-command-mirror-clone.md) : 既存のミラーから新しいミラーを複製します -- [merge](/tiup/tiup-command-mirror-merge.md) : ミラーをマージする +- [genkey](/tiup/tiup-command-mirror-genkey.md) : 秘密鍵ファイルを生成する +- [sign](/tiup/tiup-command-mirror-sign.md) : 秘密鍵ファイルを使用して特定のファイルに署名します +- [init](/tiup/tiup-command-mirror-init.md) : 空のミラーを開始する +- [set](/tiup/tiup-command-mirror-set.md) : 現在のミラーを設定する +- [grant](/tiup/tiup-command-mirror-grant.md) : 現在のミラーに新しいコンポーネント所有者を付与します +- [publish](/tiup/tiup-command-mirror-publish.md) : 新しいコンポーネントを現在のミラーに公開します +- [modify](/tiup/tiup-command-mirror-modify.md) : 現在のミラー内のコンポーネントの属性を変更します +- [rotate](/tiup/tiup-command-mirror-rotate.md) : 現在のミラーのルート証明書を更新します +- [clone](/tiup/tiup-command-mirror-clone.md) : 既存のミラーから新しいミラーを複製します +- [merge](/tiup/tiup-command-mirror-merge.md) : ミラーをマージする [<< 前のページに戻る - TiUPリファレンスコマンドリスト](/tiup/tiup-reference.md#command-list) diff --git a/tiup/tiup-command-status.md b/tiup/tiup-command-status.md index fca6ea3d2b15c..6e71aa40ca023 100644 --- a/tiup/tiup-command-status.md +++ b/tiup/tiup-command-status.md @@ -11,8 +11,8 @@ summary: 「tiup status」コマンドは、「tiup <コンポーネント>」 > > 確認できるのは以下のコンポーネントの情報のみです。 > -> - まだ稼働中のコンポーネント -> - `tiup -T/--tag`で指定されたタグを通過するコンポーネント +> - まだ稼働中のコンポーネント +> - `tiup -T/--tag`で指定されたタグを通過するコンポーネント ## 構文 {#syntax} @@ -28,24 +28,24 @@ tiup status [flags] 次のフィールドで構成されるテーブル: -- `Name` : `-T/--tag`で指定されたタグ名。指定されていない場合はランダムな文字列になります。 -- `Component` : 動作コンポーネント。 -- `PID` : 動作コンポーネントに対応するプロセス ID。 -- `Status` : 動作中のコンポーネントのステータス。 -- `Created Time` : コンポーネントの開始時刻。 -- `Directory` : コンポーネントのデータ ディレクトリ。 -- `Binary` : コンポーネントのバイナリ ファイル パス。 -- `Args` : 操作コンポーネントの開始引数。 +- `Name` : `-T/--tag`で指定されたタグ名。指定されていない場合はランダムな文字列になります。 +- `Component` : 動作コンポーネント。 +- `PID` : 動作コンポーネントに対応するプロセス ID。 +- `Status` : 動作中のコンポーネントのステータス。 +- `Created Time` : コンポーネントの開始時刻。 +- `Directory` : コンポーネントのデータ ディレクトリ。 +- `Binary` : コンポーネントのバイナリ ファイル パス。 +- `Args` : 操作コンポーネントの開始引数。 ### コンポーネントのステータス {#component-status} コンポーネントは次のいずれかのステータスで実行できます。 -- 稼働中:コンポーネントは正常に動作しています。 -- ダウンまたは到達不能:コンポーネントが実行されていないか、対応するホストにネットワークの問題が発生しています。 -- tombstone:コンポーネント上のデータが完全に移行され、スケールインが完了しました。このステータスは TiKV またはTiFlashでのみ存在します。 -- オフライン保留中:コンポーネント上のデータは移行中で、スケールインが進行中です。このステータスは TiKV またはTiFlashでのみ表示されます。 -- 不明:コンポーネントの実行ステータスは不明です。 +- 稼働中:コンポーネントは正常に動作しています。 +- ダウンまたは到達不能:コンポーネントが実行されていないか、対応するホストにネットワークの問題が発生しています。 +- tombstone:コンポーネント上のデータが完全に移行され、スケールインが完了しました。このステータスは TiKV またはTiFlashでのみ存在します。 +- オフライン保留中:コンポーネント上のデータは移行中で、スケールインが進行中です。このステータスは TiKV またはTiFlashでのみ表示されます。 +- 不明:コンポーネントの実行ステータスは不明です。 > **Note:** > diff --git a/tiup/tiup-command-telemetry.md b/tiup/tiup-command-telemetry.md index 862e4dc2092e7..fbc76682a6b9a 100644 --- a/tiup/tiup-command-telemetry.md +++ b/tiup/tiup-command-telemetry.md @@ -9,15 +9,15 @@ v1.11.3 以降、新規に導入されたTiUPではテレメトリがデフォ TiUPテレメトリが有効になっている場合、 TiUPコマンドの実行時に、次のような使用状況情報が PingCAP と共有されます (ただし、これに限定されません)。 -- ランダムに生成されたテレメトリ識別子。 -- コマンド実行が成功したかどうか、コマンド実行の継続時間などのTiUPコマンドの実行ステータス。 -- ターゲット マシンのハードウェア情報、コンポーネントのバージョン番号、変更された展開構成名など、展開にTiUPを使用する状況。 +- ランダムに生成されたテレメトリ識別子。 +- コマンド実行が成功したかどうか、コマンド実行の継続時間などのTiUPコマンドの実行ステータス。 +- ターゲット マシンのハードウェア情報、コンポーネントのバージョン番号、変更された展開構成名など、展開にTiUPを使用する状況。 以下の情報は共有されません。 -- クラスターの正確な名前 -- クラスタートポロジー -- クラスタ構成ファイル +- クラスターの正確な名前 +- クラスタートポロジー +- クラスタ構成ファイル TiUP は`tiup telemetry`コマンドを使用してテレメトリを制御します。 @@ -35,8 +35,8 @@ tiup telemetry `tiup telemetry status`コマンドは、現在のテレメトリ設定を表示し、次の情報を出力するために使用します。 -- `status` : テレメトリ`(enable|disable)`有効化または無効化を指定します。 -- `uuid` : ランダムに生成されたテレメトリ識別子を指定します。 +- `status` : テレメトリ`(enable|disable)`有効化または無効化を指定します。 +- `uuid` : ランダムに生成されたテレメトリ識別子を指定します。 ### リセット {#reset} diff --git a/tiup/tiup-command-uninstall.md b/tiup/tiup-command-uninstall.md index e165f839563c7..d23fae20892ec 100644 --- a/tiup/tiup-command-uninstall.md +++ b/tiup/tiup-command-uninstall.md @@ -13,27 +13,27 @@ summary: tiup uninstallコマンドは、インストール済みのコンポー tiup uninstall : [component2...N] [flags] ``` -- `` : アンインストールするコンポーネントの名前。 -- `` : アンインストールするバージョン。このフィールドを省略すると、コンポーネントのすべてのインストール済みバージョンがアンインストールされます。セキュリティ上の理由から、 ``省略する場合は`--all`オプションを追加する必要があります。これは、コンポーネントのすべてのバージョンをアンインストールする必要があることを示します。 -- `[component2...N]` : アンインストールするコンポーネントまたはバージョンが複数あります。 +- `` : アンインストールするコンポーネントの名前。 +- `` : アンインストールするバージョン。このフィールドを省略すると、コンポーネントのすべてのインストール済みバージョンがアンインストールされます。セキュリティ上の理由から、 ``省略する場合は`--all`オプションを追加する必要があります。これは、コンポーネントのすべてのバージョンをアンインストールする必要があることを示します。 +- `[component2...N]` : アンインストールするコンポーネントまたはバージョンが複数あります。 ## オプション {#options} ### --all {#all} -- 指定されたコンポーネントのインストール済みバージョンをすべてアンインストールします。``省略した場合は、このオプションを使用する必要があります。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- 指定されたコンポーネントのインストール済みバージョンをすべてアンインストールします。``省略した場合は、このオプションを使用する必要があります。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### - 自己 {#self} -- TiUP自体をアンインストールします。このオプションを使用すると、ミラーからダウンロードされたすべてのデータが削除されますが、 TiUPとそのコンポーネントによって生成されたデータは保持されます。データは環境変数`TIUP_HOME`で指定されたディレクトリに保存されます。`TIUP_HOME`が設定されていない場合、デフォルト値は`~/.tiup/`です。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- TiUP自体をアンインストールします。このオプションを使用すると、ミラーからダウンロードされたすべてのデータが削除されますが、 TiUPとそのコンポーネントによって生成されたデータは保持されます。データは環境変数`TIUP_HOME`で指定されたディレクトリに保存されます。`TIUP_HOME`が設定されていない場合、デフォルト値は`~/.tiup/`です。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#outputs} -- コマンドがエラーなしで終了した場合は`Uninstalled component "%s" successfully!`が出力されます。 -- ``も`--all`も指定されていない場合は、 `Use "tiup uninstall tidbx --all" if you want to remove all versions.`エラーが報告されます。 +- コマンドがエラーなしで終了した場合は`Uninstalled component "%s" successfully!`が出力されます。 +- ``も`--all`も指定されていない場合は、 `Use "tiup uninstall tidbx --all" if you want to remove all versions.`エラーが報告されます。 [<< 前のページに戻る - TiUPリファレンスコマンドリスト](/tiup/tiup-reference.md#command-list) diff --git a/tiup/tiup-command-update.md b/tiup/tiup-command-update.md index 9deb3bb93aff7..46efaac932964 100644 --- a/tiup/tiup-command-update.md +++ b/tiup/tiup-command-update.md @@ -13,9 +13,9 @@ summary: tiup updateコマンドは、インストール済みのコンポーネ tiup update [component1][:version] [component2..N] [flags] ``` -- `[component1]` : 更新するコンポーネントの名前。 -- `[version]` : 更新するバージョン。このフィールドを省略すると、コンポーネントの最新の安定バージョンに更新することを意味します。 -- `[component2...N]` : 複数のコンポーネントまたはバージョンの更新を指定します。コンポーネントが指定されていない場合（つまり`[component1][:version] [component2..N]`が空の場合）、 `--all`または`--self`オプションを併用する必要があります。 +- `[component1]` : 更新するコンポーネントの名前。 +- `[version]` : 更新するバージョン。このフィールドを省略すると、コンポーネントの最新の安定バージョンに更新することを意味します。 +- `[component2...N]` : 複数のコンポーネントまたはバージョンの更新を指定します。コンポーネントが指定されていない場合（つまり`[component1][:version] [component2..N]`が空の場合）、 `--all`または`--self`オプションを併用する必要があります。 更新操作では古いバージョンは削除されません。実行時に古いバージョンを使用することを指定できます。 @@ -23,31 +23,31 @@ tiup update [component1][:version] [component2..N] [flags] ### --all {#all} -- コンポーネントが指定されていない場合は、このオプションを指定する必要があります。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- コンポーネントが指定されていない場合は、このオプションを指定する必要があります。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### --force {#force} -- 指定されたバージョンのコンポーネントが既にインストールされている場合、デフォルトでは更新操作はスキップされます。このオプションを指定すると、インストールされているバージョンが強制的に更新されます。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- 指定されたバージョンのコンポーネントが既にインストールされている場合、デフォルトでは更新操作はスキップされます。このオプションを指定すると、インストールされているバージョンが強制的に更新されます。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### --nightly {#nightly} -- 指定されたコンポーネントをナイトリーバージョンに更新します。このオプションを指定した`tiup update`コマンドは、 `tiup update :nightly`コマンドと同等です。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- 指定されたコンポーネントをナイトリーバージョンに更新します。このオプションを指定した`tiup update`コマンドは、 `tiup update :nightly`コマンドと同等です。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### - 自己 {#self} -- TiUP自体を更新します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- TiUP自体を更新します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#outputs} -- 更新が成功すると`Updated successfully!`が出力されます。 -- 対象バージョンが存在しない場合は、エラー`Error: version %s not supported by component %s`が報告されます。 +- 更新が成功すると`Updated successfully!`が出力されます。 +- 対象バージョンが存在しない場合は、エラー`Error: version %s not supported by component %s`が報告されます。 [<< 前のページに戻る - TiUPリファレンスコマンドリスト](/tiup/tiup-reference.md#command-list) diff --git a/tiup/tiup-component-cluster-audit-cleanup.md b/tiup/tiup-component-cluster-audit-cleanup.md index a519260f95f0a..66dfaf2b407cf 100644 --- a/tiup/tiup-component-cluster-audit-cleanup.md +++ b/tiup/tiup-component-cluster-audit-cleanup.md @@ -17,17 +17,17 @@ tiup cluster audit cleanup [flags] ### --retain-days {#retain-days} -- ログを保持する日数を指定します。 -- データ型: `INT` -- デフォルト値: `60` (日単位)。 -- デフォルトでは、過去 60 日以内に生成されたログが保持されます。つまり、60 日より前に生成されたログは削除されます。 +- ログを保持する日数を指定します。 +- データ型: `INT` +- デフォルト値: `60` (日単位)。 +- デフォルトでは、過去 60 日以内に生成されたログが保持されます。つまり、60 日より前に生成されたログは削除されます。 ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト値: `false` -- このオプションを有効にするには、このオプションをコマンドに追加し、値`true`を渡すか、値を渡さないようにします。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト値: `false` +- このオプションを有効にするには、このオプションをコマンドに追加し、値`true`を渡すか、値を渡さないようにします。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-audit.md b/tiup/tiup-component-cluster-audit.md index 980c24125d718..4d20d4c0a987e 100644 --- a/tiup/tiup-component-cluster-audit.md +++ b/tiup/tiup-component-cluster-audit.md @@ -13,23 +13,23 @@ summary: tiup cluster auditコマンドは、すべてのクラスタで実行 tiup cluster audit [audit-id] [flags] ``` -- `[audit-id]`を記入しない場合、操作記録表は逆時系列で出力されます。最初の列は`audit-id`です。 -- `[audit-id]`を記入した場合は、指定した`audit-id`の実行ログを確認することを意味します。 +- `[audit-id]`を記入しない場合、操作記録表は逆時系列で出力されます。最初の列は`audit-id`です。 +- `[audit-id]`を記入した場合は、指定した`audit-id`の実行ログを確認することを意味します。 ## オプション {#option} ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `Boolean` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- ヘルプ情報を出力します。 +- データ型: `Boolean` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#outputs} -- `[audit-id]`を指定した場合、対応する実行ログが出力されます。 -- `[audit-id]`を指定しない場合は、次のフィールドを含むテーブルが出力されます。 - - ID: レコードに対応する`audit-id` - - 時間: レコードに対応するコマンドの実行時間 - - コマンド: レコードに対応するコマンド +- `[audit-id]`を指定した場合、対応する実行ログが出力されます。 +- `[audit-id]`を指定しない場合は、次のフィールドを含むテーブルが出力されます。 + - ID: レコードに対応する`audit-id` + - 時間: レコードに対応するコマンドの実行時間 + - コマンド: レコードに対応するコマンド [<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-check.md b/tiup/tiup-component-cluster-check.md index 344a888aa77cf..b150c9fa1ffcd 100644 --- a/tiup/tiup-component-cluster-check.md +++ b/tiup/tiup-component-cluster-check.md @@ -41,12 +41,12 @@ summary: TiUP クラスタは、ハードウェアとソフトウェア環境が 次のカーネル パラメータの値を確認します。 -- `net.ipv4.tcp_tw_recycle` : 0 -- `net.ipv4.tcp_syncookies` : 0 -- `net.core.somaxconn` : 32768 -- `vm.swappiness` : 0 -- `vm.overcommit_memory` ：0または1 -- `fs.file-max` : 1000000 +- `net.ipv4.tcp_tw_recycle` : 0 +- `net.ipv4.tcp_syncookies` : 0 +- `net.core.somaxconn` : 32768 +- `vm.swappiness` : 0 +- `vm.overcommit_memory` ：0または1 +- `fs.file-max` : 1000000 ### 透過的な巨大ページ (THP) {#transparent-huge-pages-thp} @@ -122,9 +122,9 @@ ext4パーティションのマウントオプションを確認してくださ フレキシブル I/O テスター (fio) を使用して、次の 3 つのテスト項目を含む、 `data_dir`が配置されているディスクのパフォーマンスをテストします。 -- fio_randread_write_latency -- fio_randread_write -- fio_randread +- fio_randread_write_latency +- fio_randread_write +- fio_randread > **Note:** > @@ -136,9 +136,9 @@ ext4パーティションのマウントオプションを確認してくださ tiup cluster check [flags] ``` -- クラスターがまだデプロイされていない場合は、クラスターのデプロイに使用する[トポロジー.yml](/tiup/tiup-cluster-topology-reference.md)ファイルを渡す必要があります。このファイルの内容に従って、 tiup-clusterは対応するマシンに接続し、チェックを実行します。 -- クラスターがすでにデプロイされている場合は、チェック オブジェクトとして``を使用できます。 -- 既存のクラスターのスケールアウト YAML ファイルをチェックする場合は、チェック オブジェクトとして``と``両方を使用できます。 +- クラスターがまだデプロイされていない場合は、クラスターのデプロイに使用する[トポロジー.yml](/tiup/tiup-cluster-topology-reference.md)ファイルを渡す必要があります。このファイルの内容に従って、 tiup-clusterは対応するマシンに接続し、チェックを実行します。 +- クラスターがすでにデプロイされている場合は、チェック オブジェクトとして``を使用できます。 +- 既存のクラスターのスケールアウト YAML ファイルをチェックする場合は、チェック オブジェクトとして``と``両方を使用できます。 > **Note:** > @@ -148,15 +148,15 @@ tiup cluster check [flags] ### - 適用する {#apply} -- 失敗したチェック項目の自動修復を試みます。現在、 tiup-cluster は以下のチェック項目のみを修復しようとします。 - - SELinux - - ファイアウォール - - irqバランス - - カーネルパラメータ - - システム制限 - - THP (透過的巨大ページ) -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- 失敗したチェック項目の自動修復を試みます。現在、 tiup-cluster は以下のチェック項目のみを修復しようとします。 + - SELinux + - ファイアウォール + - irqバランス + - カーネルパラメータ + - システム制限 + - THP (透過的巨大ページ) +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 > **Note:** > @@ -168,10 +168,10 @@ tiup cluster check [flags] ### - クラスタ {#cluster} -- チェックがデプロイ済みのクラスターを対象としていることを示します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 -- コマンド形式: +- チェックがデプロイ済みのクラスターを対象としていることを示します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- コマンド形式: ```shell tiup cluster check --cluster [flags] @@ -179,8 +179,8 @@ tiup cluster check [flags] > **Note:** > -> - `tiup cluster check `コマンドを使用する場合は、 `--cluster`オプション`tiup cluster check --cluster`を追加する必要があります。 -> - `tiup cluster check`では、次のコマンド形式を使用して、既存のクラスターの`scale-out.yml`ファイルを確認することもサポートされています。 +> - `tiup cluster check `コマンドを使用する場合は、 `--cluster`オプション`tiup cluster check --cluster`を追加する必要があります。 +> - `tiup cluster check`では、次のコマンド形式を使用して、既存のクラスターの`scale-out.yml`ファイルを確認することもサポートされています。 > > ```shell > tiup cluster check scale-out.yml --cluster --user root [-p] [-i /home/root/.ssh/gcp_rsa] @@ -188,9 +188,9 @@ tiup cluster check [flags] ### -N, --node {#n-node} -- チェックするノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、デフォルトですべてのノードがチェックされます。 +- チェックするノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、デフォルトですべてのノードがチェックされます。 > **Note:** > @@ -198,9 +198,9 @@ tiup cluster check [flags] ### -R, --role {#r-role} -- チェックするロールを指定します。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、すべてのロールがデフォルトでチェックされます。 +- チェックするロールを指定します。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、すべてのロールがデフォルトでチェックされます。 > **Note:** > @@ -208,27 +208,27 @@ tiup cluster check [flags] ### --enable-CPU {#enable-cpu} -- CPUコア数のチェックを有効にします。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- CPUコア数のチェックを有効にします。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### --enable-disk {#enable-disk} -- fio ディスク パフォーマンス テストを有効にします。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- fio ディスク パフォーマンス テストを有効にします。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### --enable-mem {#enable-mem} -- メモリサイズのチェックを有効にします。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- メモリサイズのチェックを有効にします。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### --u, --user {#u-user} -- ターゲットマシンに接続するためのユーザー名を指定します。指定されたユーザーは、ターゲットマシン上でパスワード不要のsudo root権限を持っている必要があります。 -- データ型: `STRING` -- コマンドでこのオプションを指定しない場合は、コマンドを実行したユーザーがデフォルト値として使用されます。 +- ターゲットマシンに接続するためのユーザー名を指定します。指定されたユーザーは、ターゲットマシン上でパスワード不要のsudo root権限を持っている必要があります。 +- データ型: `STRING` +- コマンドでこのオプションを指定しない場合は、コマンドを実行したユーザーがデフォルト値として使用されます。 > **Note:** > @@ -236,9 +236,9 @@ tiup cluster check [flags] ### -i, --identity_file {#i-identity-file} -- ターゲット マシンに接続するためのキー ファイルを指定します。 -- データ型: `STRING` -- このオプションはデフォルトで有効になっており、 `~/.ssh/id_rsa` (デフォルト値) が渡されます。 +- ターゲット マシンに接続するためのキー ファイルを指定します。 +- データ型: `STRING` +- このオプションはデフォルトで有効になっており、 `~/.ssh/id_rsa` (デフォルト値) が渡されます。 > **Note:** > @@ -246,25 +246,25 @@ tiup cluster check [flags] ### -p, --password {#p-password} -- ターゲットマシンに接続するときにパスワードを使用してログインします。 - - クラスターに`--cluster`オプションが追加された場合、パスワードはクラスターのデプロイ時にトポロジ ファイルに指定されたユーザーのパスワードになります。 - - クラスターにオプション`--cluster`が追加されていない場合、パスワードはオプション`-u/--user`で指定されたユーザーのパスワードになります。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ターゲットマシンに接続するときにパスワードを使用してログインします。 + - クラスターに`--cluster`オプションが追加された場合、パスワードはクラスターのデプロイ時にトポロジ ファイルに指定されたユーザーのパスワードになります。 + - クラスターにオプション`--cluster`が追加されていない場合、パスワードはオプション`-u/--user`で指定されたユーザーのパスワードになります。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### -h, --help {#h-help} -- 関連するコマンドのヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- 関連するコマンドのヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 出力 {#output} 次のフィールドを含むテーブル: -- `Node` : ターゲットノード -- `Check` : チェック項目 -- `Result` : チェック結果（合格、警告、不合格） -- `Message` : 結果の説明 +- `Node` : ターゲットノード +- `Check` : チェック項目 +- `Result` : チェック結果（合格、警告、不合格） +- `Message` : 結果の説明 [<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-clean.md b/tiup/tiup-component-cluster-clean.md index 6c4f1aadd51a0..234b03068a90a 100644 --- a/tiup/tiup-component-cluster-clean.md +++ b/tiup/tiup-component-cluster-clean.md @@ -23,42 +23,42 @@ tiup cluster clean [flags] ### --all {#all} -- データとログを同時に消去します。`--data`と`--log`を同時に指定するのと同じです。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 -- 指定されていない場合は、少なくとも次のいずれかのオプションを指定する必要があります。 - - --data: データをクリーンアップする - - --log: ログを消去する +- データとログを同時に消去します。`--data`と`--log`を同時に指定するのと同じです。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- 指定されていない場合は、少なくとも次のいずれかのオプションを指定する必要があります。 + - --data: データをクリーンアップする + - --log: ログを消去する ### --data {#data} -- データをクリーンアップします。どちらも指定されていない場合、または`--all`が指定されていない場合は、データはクリーンアップされません。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- データをクリーンアップします。どちらも指定されていない場合、または`--all`が指定されていない場合は、データはクリーンアップされません。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### --log {#log} -- ログを消去します。 `--all`も指定されていない場合、ログは消去されません。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- ログを消去します。 `--all`も指定されていない場合、ログは消去されません。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### --ignore-node {#ignore-node} -- クリーニングが不要なノードを指定します。複数のノードを指定するには、このオプションを複数回使用します。例： `--ignore-node --ignore-node ` 。 -- データ型: `StringArray` -- デフォルト: 空 +- クリーニングが不要なノードを指定します。複数のノードを指定するには、このオプションを複数回使用します。例： `--ignore-node --ignore-node ` 。 +- データ型: `StringArray` +- デフォルト: 空 ### --ignore-role {#ignore-role} -- クリーニングが不要なロールを指定します。複数のロールを指定するには、このオプションを複数回使用します。例： `--ignore-role --ignore-role ` 。 -- データ型: `StringArray` -- デフォルト: 空 +- クリーニングが不要なロールを指定します。複数のロールを指定するには、このオプションを複数回使用します。例： `--ignore-role --ignore-role ` 。 +- データ型: `StringArray` +- デフォルト: 空 ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-deploy.md b/tiup/tiup-component-cluster-deploy.md index e2d62574f54d2..60e240c0b51ac 100644 --- a/tiup/tiup-component-cluster-deploy.md +++ b/tiup/tiup-component-cluster-deploy.md @@ -13,55 +13,55 @@ summary: tiup cluster deployコマンドは、クラスタ名、バージョン tiup cluster deploy [flags] ``` -- `` : 新しいクラスターの名前。既存のクラスター名と同じにすることはできません。 -- `` : デプロイする TiDB クラスターのバージョン番号 (例: `v8.5.3` )。 -- `` : 準備された[トポロジファイル](/tiup/tiup-cluster-topology-reference.md) 。 +- `` : 新しいクラスターの名前。既存のクラスター名と同じにすることはできません。 +- `` : デプロイする TiDB クラスターのバージョン番号 (例: `v8.5.3` )。 +- `` : 準備された[トポロジファイル](/tiup/tiup-cluster-topology-reference.md) 。 ## オプション {#options} ### -u, --user {#u-user} -- ターゲットマシンへの接続に使用するユーザー名を指定します。このユーザーは、ターゲットマシン上でシークレットフリーのsudo root権限を持っている必要があります。 -- データ型: `STRING` -- デフォルト: コマンドを実行する現在のユーザー。 +- ターゲットマシンへの接続に使用するユーザー名を指定します。このユーザーは、ターゲットマシン上でシークレットフリーのsudo root権限を持っている必要があります。 +- データ型: `STRING` +- デフォルト: コマンドを実行する現在のユーザー。 ### -i, --identity_file {#i-identity-file} -- ターゲット マシンに接続するために使用するキー ファイルを指定します。 -- データ型: `STRING` -- コマンドでこのオプションを指定しない場合は、デフォルトで`~/.ssh/id_rsa`ファイルを使用してターゲット マシンに接続します。 +- ターゲット マシンに接続するために使用するキー ファイルを指定します。 +- データ型: `STRING` +- コマンドでこのオプションを指定しない場合は、デフォルトで`~/.ssh/id_rsa`ファイルを使用してターゲット マシンに接続します。 ### -p, --password {#p-password} -- ターゲットマシンへの接続に使用するパスワードを指定します。このオプションは`-i/--identity_file`と同時に使用しないでください。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- ターゲットマシンへの接続に使用するパスワードを指定します。このオプションは`-i/--identity_file`と同時に使用しないでください。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### --ignore-config-check {#ignore-config-check} -- このオプションは、構成チェックをスキップするために使用されます。コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `を使用してTiDB、TiKV、およびPDコンポーネントの構成がチェックされます。``は、デプロイされたバイナリファイルのパスです。``は、ユーザー設定に基づいて生成された構成ファイルです。 -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 -- デフォルト: false +- このオプションは、構成チェックをスキップするために使用されます。コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `を使用してTiDB、TiKV、およびPDコンポーネントの構成がチェックされます。``は、デプロイされたバイナリファイルのパスです。``は、ユーザー設定に基づいて生成された構成ファイルです。 +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- デフォルト: false ### --no-labels {#no-labels} -- このオプションはラベル チェックをスキップするために使用されます。 -- 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、PDがクラスタトポロジを学習できないため、同じ物理マシン上の異なるTiKVノードにリージョンの複数のレプリカをスケジュールし、その物理マシンを単一のポイントにしてしまうというリスクが生じます。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)を参照してください。 -- テスト環境では、このリスクが重要になる可能性があるため、 `--no-labels`を使用してチェックをスキップできます。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- このオプションはラベル チェックをスキップするために使用されます。 +- 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、PDがクラスタトポロジを学習できないため、同じ物理マシン上の異なるTiKVノードにリージョンの複数のレプリカをスケジュールし、その物理マシンを単一のポイントにしてしまうというリスクが生じます。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)を参照してください。 +- テスト環境では、このリスクが重要になる可能性があるため、 `--no-labels`を使用してチェックをスキップできます。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### --skip-create-user {#skip-create-user} -- クラスタのデプロイメント中、 tiup-cluster はトポロジファイルで指定されたユーザー名が存在するかどうかを確認します。存在しない場合は、ユーザー名を作成します。このチェックをスキップするには、 `--skip-create-user`オプションを使用します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- クラスタのデプロイメント中、 tiup-cluster はトポロジファイルで指定されたユーザー名が存在するかどうかを確認します。存在しない場合は、ユーザー名を作成します。このチェックをスキップするには、 `--skip-create-user`オプションを使用します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-destroy.md b/tiup/tiup-component-cluster-destroy.md index b78895d7689a6..80bcdc2790161 100644 --- a/tiup/tiup-component-cluster-destroy.md +++ b/tiup/tiup-component-cluster-destroy.md @@ -7,9 +7,9 @@ summary: tiup cluster destroyコマンドは、クラスターを停止し、各 アプリケーションがオフラインになった後、クラスターが占有していたマシンを解放して他のアプリケーションで使用できるようにするには、クラスター上のデータとデプロイされたバイナリファイルをクリーンアップする必要があります。クラスターを破棄するには、 `tiup cluster destroy`コマンドで以下の操作を実行します。 -- クラスターを停止します。 -- 各サービスについて、ログ ディレクトリ、デプロイメント ディレクトリ、およびデータ ディレクトリを削除します。 -- tiup-clusterによって各サービスのデータディレクトリまたはデプロイメントディレクトリの親ディレクトリが作成されている場合は、親ディレクトリも削除します。 +- クラスターを停止します。 +- 各サービスについて、ログ ディレクトリ、デプロイメント ディレクトリ、およびデータ ディレクトリを削除します。 +- tiup-clusterによって各サービスのデータディレクトリまたはデプロイメントディレクトリの親ディレクトリが作成されている場合は、親ディレクトリも削除します。 ## 構文 {#syntax} @@ -23,27 +23,27 @@ tiup cluster destroy [flags] ### --force {#force} -- 場合によっては、クラスタ内の一部のノードがダウンし、SSH経由でノードに接続して操作できなくなることがあります。このような場合は、 `--force`オプションを使用してこれらのエラーを無視できます。 -- データ型: `Boolean` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- 場合によっては、クラスタ内の一部のノードがダウンし、SSH経由でノードに接続して操作できなくなることがあります。このような場合は、 `--force`オプションを使用してこれらのエラーを無視できます。 +- データ型: `Boolean` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### --retain-node-data {#retain-node-data} -- データを保持する必要があるノードを指定します。複数のノードを指定する必要がある場合は、このオプションを複数回使用します（ `--retain-node-data --retain-node-data ` ）。 -- データ型: `StringArray` -- デフォルト: 空 +- データを保持する必要があるノードを指定します。複数のノードを指定する必要がある場合は、このオプションを複数回使用します（ `--retain-node-data --retain-node-data ` ）。 +- データ型: `StringArray` +- デフォルト: 空 ### --retain-role-data {#retain-role-data} -- データを保持する必要があるロールを指定します。複数のロールを指定する必要がある場合は、このオプションを複数回使用します（ `--retain-role-data --retain-role-data ` ）。 -- データ型: `StringArray` -- デフォルト: 空 +- データを保持する必要があるロールを指定します。複数のロールを指定する必要がある場合は、このオプションを複数回使用します（ `--retain-role-data --retain-role-data ` ）。 +- データ型: `StringArray` +- デフォルト: 空 ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `Boolean` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- ヘルプ情報を出力します。 +- データ型: `Boolean` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-disable.md b/tiup/tiup-component-cluster-disable.md index 8f75c698ca229..5651c6f2c9910 100644 --- a/tiup/tiup-component-cluster-disable.md +++ b/tiup/tiup-component-cluster-disable.md @@ -19,9 +19,9 @@ tiup cluster disable [flags] ### -N, --node {#n-node} -- サービスの自動有効化を無効にするノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスタステータステーブルの最初の列から取得できます。 -- データ型: `STRINGS` -- このオプションがコマンドで指定されていない場合、すべてのノードの自動有効化はデフォルトで無効になります。 +- サービスの自動有効化を無効にするノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスタステータステーブルの最初の列から取得できます。 +- データ型: `STRINGS` +- このオプションがコマンドで指定されていない場合、すべてのノードの自動有効化はデフォルトで無効になります。 > **Note:** > @@ -29,9 +29,9 @@ tiup cluster disable [flags] ### -R, --role {#r-role} -- サービスの自動有効化を無効にするロールを指定します。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合、すべてのロールの自動有効化はデフォルトで無効になります。 +- サービスの自動有効化を無効にするロールを指定します。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合、すべてのロールの自動有効化はデフォルトで無効になります。 > **Note:** > @@ -39,9 +39,9 @@ tiup cluster disable [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-display.md b/tiup/tiup-component-cluster-display.md index 333f93d7fbe33..9573c728d76d5 100644 --- a/tiup/tiup-component-cluster-display.md +++ b/tiup/tiup-component-cluster-display.md @@ -19,15 +19,15 @@ tiup cluster display [flags] ### --dashboard {#dashboard} -- デフォルトでは、クラスター全体のすべてのノード情報が表示されます。`--dashboard`オプションを指定すると、ダッシュボード情報のみが表示されます。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- デフォルトでは、クラスター全体のすべてのノード情報が表示されます。`--dashboard`オプションを指定すると、ダッシュボード情報のみが表示されます。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### -N, --node {#n-node} -- 表示するノードを指定します。このオプションを指定しない場合は、すべてのノードが表示されます。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードのIDが不明な場合は、コマンドでこのオプションを省略して、すべてのノードのIDとステータスを出力に表示できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、デフォルトですべてのノードがチェックされます。 +- 表示するノードを指定します。このオプションを指定しない場合は、すべてのノードが表示されます。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードのIDが不明な場合は、コマンドでこのオプションを省略して、すべてのノードのIDとステータスを出力に表示できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、デフォルトですべてのノードがチェックされます。 > **Note:** > @@ -35,9 +35,9 @@ tiup cluster display [flags] ### -R, --role {#r-role} -- 表示するロールを指定します。指定しない場合は、すべてのロールが表示されます。このオプションの値は、ノードロールのカンマ区切りのリストです。ノードにデプロイされているロールが不明な場合は、コマンドでこのオプションを省略して、すべてのノードのロールとステータスを出力に表示できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、デフォルトですべてのロールが表示されます。 +- 表示するロールを指定します。指定しない場合は、すべてのロールが表示されます。このオプションの値は、ノードロールのカンマ区切りのリストです。ノードにデプロイされているロールが不明な場合は、コマンドでこのオプションを省略して、すべてのノードのロールとステータスを出力に表示できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、デフォルトですべてのロールが表示されます。 > **Note:** > @@ -45,55 +45,55 @@ tiup cluster display [flags] ### - プロセス {#process} -- このオプションを有効にすると、ノードのCPUとメモリの使用状況が表示されます。このオプションはデフォルトでは無効になっています。 -- データ型: `BOOLEAN` -- デフォルト値: `false` -- このオプションを有効にするには、このオプションをコマンドに追加し、値`true`を渡すか、値を渡さないようにします。 +- このオプションを有効にすると、ノードのCPUとメモリの使用状況が表示されます。このオプションはデフォルトでは無効になっています。 +- データ型: `BOOLEAN` +- デフォルト値: `false` +- このオプションを有効にするには、このオプションをコマンドに追加し、値`true`を渡すか、値を渡さないようにします。 ### --uptime {#uptime} -- このオプションを有効にすると、ノードの`uptime`情報が表示されます。このオプションはデフォルトでは無効です。 -- データ型: `BOOLEAN` -- デフォルト値: `false` -- このオプションを有効にするには、このオプションをコマンドに追加し、値`true`を渡すか、値を渡さないようにします。 +- このオプションを有効にすると、ノードの`uptime`情報が表示されます。このオプションはデフォルトでは無効です。 +- データ型: `BOOLEAN` +- デフォルト値: `false` +- このオプションを有効にするには、このオプションをコマンドに追加し、値`true`を渡すか、値を渡さないようにします。 ### --status-timeout {#status-timeout} -- ノードステータス情報を取得するためのタイムアウト期間を指定します。 -- データ型: `INT` -- デフォルト値: `10` 、単位は秒。 +- ノードステータス情報を取得するためのタイムアウト期間を指定します。 +- データ型: `INT` +- デフォルト値: `10` 、単位は秒。 ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#outputs} -- クラスター名 -- クラスターバージョン -- SSHクライアントタイプ -- ダッシュボードアドレス -- 次のフィールドを持つテーブル: - - ID: `IP:PORT`の - - ロール: このノードにデプロイされたサービス ロール (TiDB、TiKV など) - - ホスト: ノードに対応するマシンのIP - - ポート: サービスが占有するポート番号 - - OS/アーキテクチャ: このノードのオペレーティングシステムとマシンアーキテクチャ - - ステータス: ノードサービスの現在のステータス - - データ ディレクトリ: サービスのデータ ディレクトリ。`-`はデータ ディレクトリがないことを意味します。 - - デプロイディレクトリ: サービスのデプロイディレクトリ +- クラスター名 +- クラスターバージョン +- SSHクライアントタイプ +- ダッシュボードアドレス +- 次のフィールドを持つテーブル: + - ID: `IP:PORT`の + - ロール: このノードにデプロイされたサービス ロール (TiDB、TiKV など) + - ホスト: ノードに対応するマシンのIP + - ポート: サービスが占有するポート番号 + - OS/アーキテクチャ: このノードのオペレーティングシステムとマシンアーキテクチャ + - ステータス: ノードサービスの現在のステータス + - データ ディレクトリ: サービスのデータ ディレクトリ。`-`はデータ ディレクトリがないことを意味します。 + - デプロイディレクトリ: サービスのデプロイディレクトリ ### ノードサービスステータス {#node-service-status} ノード サービスは次のいずれかのステータスで実行できます。 -- 稼働中: ノード サービスは正常に実行されています。 -- ダウンまたは到達不能: ノード サービスが実行されていないか、対応するホストにネットワークの問題が発生しています。 -- tombstone: ノードサービス上のデータが完全に移行され、スケールインが完了しました。このステータスは TiKV またはTiFlashでのみ存在します。 -- オフライン保留中: ノードサービス上のデータが移行中で、スケールインが進行中です。このステータスは TiKV またはTiFlashでのみ表示されます。 -- 不明: ノード サービスの実行ステータスは不明です。 +- 稼働中: ノード サービスは正常に実行されています。 +- ダウンまたは到達不能: ノード サービスが実行されていないか、対応するホストにネットワークの問題が発生しています。 +- tombstone: ノードサービス上のデータが完全に移行され、スケールインが完了しました。このステータスは TiKV またはTiFlashでのみ存在します。 +- オフライン保留中: ノードサービス上のデータが移行中で、スケールインが進行中です。このステータスは TiKV またはTiFlashでのみ表示されます。 +- 不明: ノード サービスの実行ステータスは不明です。 > **Note:** > diff --git a/tiup/tiup-component-cluster-edit-config.md b/tiup/tiup-component-cluster-edit-config.md index 68338f5f989e1..f9f1e16e3dc22 100644 --- a/tiup/tiup-component-cluster-edit-config.md +++ b/tiup/tiup-component-cluster-edit-config.md @@ -9,8 +9,8 @@ summary: tiup cluster edit-config` コマンドを使用すると、デプロイ > **Note:** > -> - 設定を変更すると、マシンの追加や削除はできなくなります。マシンの追加方法については[クラスターをスケールアウトする](/tiup/tiup-component-cluster-scale-out.md)を参照してください。マシンの削除方法については[クラスターのスケールイン](/tiup/tiup-component-cluster-scale-in.md)を参照してください。 -> - `tiup cluster edit-config`コマンドを実行すると、コントロールマシン上でのみ設定が変更されます。その後、 `tiup cluster reload`コマンドを実行して設定を再読み込みする必要があります。 +> - 設定を変更すると、マシンの追加や削除はできなくなります。マシンの追加方法については[クラスターをスケールアウトする](/tiup/tiup-component-cluster-scale-out.md)を参照してください。マシンの削除方法については[クラスターのスケールイン](/tiup/tiup-component-cluster-scale-in.md)を参照してください。 +> - `tiup cluster edit-config`コマンドを実行すると、コントロールマシン上でのみ設定が変更されます。その後、 `tiup cluster reload`コマンドを実行して設定を再読み込みする必要があります。 ## 構文 {#syntax} @@ -24,13 +24,13 @@ tiup cluster edit-config [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#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-enable.md b/tiup/tiup-component-cluster-enable.md index 4af91469e4e31..d83ecf1fd6f30 100644 --- a/tiup/tiup-component-cluster-enable.md +++ b/tiup/tiup-component-cluster-enable.md @@ -23,9 +23,9 @@ tiup cluster enable [flags] ### -N, --node {#n-node} -- サービスの自動有効化を有効にするノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、すべてのノードの自動有効化がデフォルトで有効になります。 +- サービスの自動有効化を有効にするノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、すべてのノードの自動有効化がデフォルトで有効になります。 > **Note:** > @@ -33,9 +33,9 @@ tiup cluster enable [flags] ### -R, --role {#r-role} -- サービスの自動有効化を有効にするロールを指定します。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、すべてのロールの自動有効化がデフォルトで有効になります。 +- サービスの自動有効化を有効にするロールを指定します。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、すべてのロールの自動有効化がデフォルトで有効になります。 > **Note:** > @@ -43,9 +43,9 @@ tiup cluster enable [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-help.md b/tiup/tiup-component-cluster-help.md index d6d10f121677d..93a7e0ce817bb 100644 --- a/tiup/tiup-component-cluster-help.md +++ b/tiup/tiup-component-cluster-help.md @@ -17,9 +17,9 @@ tiup cluster help [command] [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト: false ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-import.md b/tiup/tiup-component-cluster-import.md index d083882fec6b0..d4209ba1e89d4 100644 --- a/tiup/tiup-component-cluster-import.md +++ b/tiup/tiup-component-cluster-import.md @@ -9,16 +9,16 @@ TiDB v4.0より前のバージョンでは、TiDBクラスターは主にTiDB An > **Note:** > -> - TiDB Ansible設定を管理用にTiUPにインポートした後は、クラスタ操作にTiDB Ansibleを使用し**ないでください**。メタ情報の不一致により競合が発生する可能性があります。 -> - TiDB Ansible を使用してデプロイされたクラスターが次のいずれかの状況にある場合は、 `import`コマンドを使用しないでください。 -> - TLS暗号化が有効になっているクラスター -> - 純粋な KV クラスター (TiDB インスタンスのないクラスター) -> - Kafka が有効になっているクラスター -> - Sparkが有効になっているクラスター -> - TiDB Lightning/TiKVインポーターが有効になっているクラスター -> - 監視メトリックを収集するために古いモード`push`をまだ使用しているクラスター (デフォルト モード`pull`を変更しない場合は、 `import`コマンドの使用がサポートされます) -> - デフォルト以外のポート（ `group_vars`ディレクトリに設定されているポートは互換性がある）が`node_exporter_port` / `blackbox_exporter_port`を使用して`inventory.ini`構成ファイルで個別に設定されているクラスタ -> - TiDB Ansibleを使用してデプロイしたクラスター内の一部のノードに監視コンポーネントがデプロイされていない場合は、まずTiDB Ansibleを使用して`inventory.ini`ファイルの`monitored_servers`セクションに対応するノード情報を追加し、その後`deploy.yaml`プレイブックを使用して監視コンポーネントを完全にデプロイする必要があります。そうしないと、クラスターをTiUPにインポートした後にメンテナンス操作を実行すると、監視コンポーネントの不足によりエラーが発生する可能性があります。 +> - TiDB Ansible設定を管理用にTiUPにインポートした後は、クラスタ操作にTiDB Ansibleを使用し**ないでください**。メタ情報の不一致により競合が発生する可能性があります。 +> - TiDB Ansible を使用してデプロイされたクラスターが次のいずれかの状況にある場合は、 `import`コマンドを使用しないでください。 +> - TLS暗号化が有効になっているクラスター +> - 純粋な KV クラスター (TiDB インスタンスのないクラスター) +> - Kafka が有効になっているクラスター +> - Sparkが有効になっているクラスター +> - TiDB Lightning/TiKVインポーターが有効になっているクラスター +> - 監視メトリックを収集するために古いモード`push`をまだ使用しているクラスター (デフォルト モード`pull`を変更しない場合は、 `import`コマンドの使用がサポートされます) +> - デフォルト以外のポート（ `group_vars`ディレクトリに設定されているポートは互換性がある）が`node_exporter_port` / `blackbox_exporter_port`を使用して`inventory.ini`構成ファイルで個別に設定されているクラスタ +> - TiDB Ansibleを使用してデプロイしたクラスター内の一部のノードに監視コンポーネントがデプロイされていない場合は、まずTiDB Ansibleを使用して`inventory.ini`ファイルの`monitored_servers`セクションに対応するノード情報を追加し、その後`deploy.yaml`プレイブックを使用して監視コンポーネントを完全にデプロイする必要があります。そうしないと、クラスターをTiUPにインポートした後にメンテナンス操作を実行すると、監視コンポーネントの不足によりエラーが発生する可能性があります。 ## 構文 {#syntax} @@ -30,39 +30,39 @@ tiup cluster import [flags] ### -d, --dir {#d-dir} -- TiDB Ansible が配置されているディレクトリを指定します。 -- データ型: `STRING` -- このオプションは、現在のディレクトリ (デフォルト値) が渡され、デフォルトで有効になります。 +- TiDB Ansible が配置されているディレクトリを指定します。 +- データ型: `STRING` +- このオプションは、現在のディレクトリ (デフォルト値) が渡され、デフォルトで有効になります。 ### --ansible-config {#ansible-config} -- Ansible 構成ファイルのパスを指定します。 -- データ型: `STRING` -- このオプションはデフォルトで有効になっており、 `. /ansible.cfg` (デフォルト値) が渡されます。 +- Ansible 構成ファイルのパスを指定します。 +- データ型: `STRING` +- このオプションはデフォルトで有効になっており、 `. /ansible.cfg` (デフォルト値) が渡されます。 ### --inventory {#inventory} -- Ansible インベントリ ファイルの名前を指定します。 -- データ型: `STRING` -- このオプションはデフォルトで有効になっており、 `inventory.ini` (デフォルト値) が渡されます。 +- Ansible インベントリ ファイルの名前を指定します。 +- データ型: `STRING` +- このオプションはデフォルトで有効になっており、 `inventory.ini` (デフォルト値) が渡されます。 ### --no-backup {#no-backup} -- TiDB Ansible が配置されているディレクトリ内のファイルのバックアップを無効にするかどうかを制御します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`に設定されており、無効になっています。インポートが成功すると、オプション`-dir`で指定されたディレクトリ内のすべてのデータがディレクトリ`${TIUP_HOME}/.tiup/storage/cluster/clusters/{cluster-name}/ansible-backup`にバックアップされます。このディレクトリに複数のインベントリファイルがある場合（複数のクラスタがデプロイされている場合）、このオプションを有効にすることをお勧めします。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- TiDB Ansible が配置されているディレクトリ内のファイルのバックアップを無効にするかどうかを制御します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`に設定されており、無効になっています。インポートが成功すると、オプション`-dir`で指定されたディレクトリ内のすべてのデータがディレクトリ`${TIUP_HOME}/.tiup/storage/cluster/clusters/{cluster-name}/ansible-backup`にバックアップされます。このディレクトリに複数のインベントリファイルがある場合（複数のクラスタがデプロイされている場合）、このオプションを有効にすることをお勧めします。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### --rename {#rename} -- インポートされたクラスターの名前を変更します。 -- データ型: `STRING` -- デフォルト: NULL。このオプションがコマンドで指定されていない場合、インベントリで指定されたcluster_nameがクラスター名として使用されます。 +- インポートされたクラスターの名前を変更します。 +- データ型: `STRING` +- デフォルト: NULL。このオプションがコマンドで指定されていない場合、インベントリで指定されたcluster_nameがクラスター名として使用されます。 ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-list.md b/tiup/tiup-component-cluster-list.md index 5bbebab6b149d..f06ee9e446104 100644 --- a/tiup/tiup-component-cluster-list.md +++ b/tiup/tiup-component-cluster-list.md @@ -21,18 +21,18 @@ tiup cluster list [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#outputs} 次のフィールドを含むテーブルを出力します。 -- 名前: クラスター名 -- ユーザー: デプロイメントユーザー -- バージョン: クラスターのバージョン -- パス: 制御マシン上のクラスタ展開データのパス -- PrivateKey: クラスターへの接続に使用される秘密鍵のパス +- 名前: クラスター名 +- ユーザー: デプロイメントユーザー +- バージョン: クラスターのバージョン +- パス: 制御マシン上のクラスタ展開データのパス +- PrivateKey: クラスターへの接続に使用される秘密鍵のパス [<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-meta-backup.md b/tiup/tiup-component-cluster-meta-backup.md index c66a476f11fb0..e1062f60df99b 100644 --- a/tiup/tiup-component-cluster-meta-backup.md +++ b/tiup/tiup-component-cluster-meta-backup.md @@ -23,9 +23,9 @@ TiUPメタ バックアップ ファイルを保存するターゲット ディ ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `Boolean` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- ヘルプ情報を出力します。 +- データ型: `Boolean` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-meta-restore.md b/tiup/tiup-component-cluster-meta-restore.md index fb5c8905fe67d..2113c137a4229 100644 --- a/tiup/tiup-component-cluster-meta-restore.md +++ b/tiup/tiup-component-cluster-meta-restore.md @@ -13,8 +13,8 @@ TiUPメタ ファイルを復元するには、 `tiup cluster meta restore`コ tiup cluster meta restore [flags] ``` -- ``は操作対象となるクラスターの名前です。 -- ``はTiUPメタ バックアップ ファイルへのパスです。 +- ``は操作対象となるクラスターの名前です。 +- ``はTiUPメタ バックアップ ファイルへのパスです。 > **Note:** > @@ -24,9 +24,9 @@ tiup cluster meta restore [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `Boolean` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- ヘルプ情報を出力します。 +- データ型: `Boolean` +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-patch.md b/tiup/tiup-component-cluster-patch.md index 3d717230c1391..eb01f54e249a2 100644 --- a/tiup/tiup-component-cluster-patch.md +++ b/tiup/tiup-component-cluster-patch.md @@ -7,11 +7,11 @@ summary: tiup cluster patch` コマンドを使用すると、実行中のクラ クラスターの実行中にサービスのバイナリを動的に置き換える必要がある場合（つまり、置き換えプロセス中もクラスターを利用可能な状態に保つ必要がある場合）、 `tiup cluster patch`コマンドを使用できます。コマンドの実行後、 TiUP は以下の処理を実行します。 -- 置換用のバイナリ パッケージをターゲット マシンにアップロードします。 -- ターゲット サービスが TiKV やTiFlashなどのストレージサービスの場合、 TiUP はまず API 経由で関連ノードをオフラインにします。 -- 対象サービスを停止します。 -- バイナリ パッケージを解凍し、サービスを置き換えます。 -- 対象サービスを開始します。 +- 置換用のバイナリ パッケージをターゲット マシンにアップロードします。 +- ターゲット サービスが TiKV やTiFlashなどのストレージサービスの場合、 TiUP はまず API 経由で関連ノードをオフラインにします。 +- 対象サービスを停止します。 +- バイナリ パッケージを解凍し、サービスを置き換えます。 +- 対象サービスを開始します。 ## 構文 {#syntax} @@ -19,47 +19,47 @@ summary: tiup cluster patch` コマンドを使用すると、実行中のクラ tiup cluster patch [flags] ``` -- `` : 操作対象となるクラスターの名前。 -- `` : 置換に使用されるバイナリ パッケージへのパス。 +- `` : 操作対象となるクラスターの名前。 +- `` : 置換に使用されるバイナリ パッケージへのパス。 ### 準備 {#preparation} `tiup cluster patch`コマンドを実行する前に、必要なバイナリパッケージをパックする必要があります。以下の手順に従ってください。 -1. 次の変数を決定します。 +1. 次の変数を決定します。 - - `${component}` : 置換するコンポーネントの名前 ( `tidb` 、 `tikv` 、 `pd`など)。 - - `${version}` :コンポーネントのバージョン ( `v8.5.3`や`v7.5.4`など)。 - - `${os}` :オペレーティングシステム（ `linux` ）。 - - `${arch}` :コンポーネントが実行されるプラットフォーム ( `amd64` 、 `arm64` )。 + - `${component}` : 置換するコンポーネントの名前 ( `tidb` 、 `tikv` 、 `pd`など)。 + - `${version}` :コンポーネントのバージョン ( `v8.5.3`や`v7.5.4`など)。 + - `${os}` :オペレーティングシステム（ `linux` ）。 + - `${arch}` :コンポーネントが実行されるプラットフォーム ( `amd64` 、 `arm64` )。 -2. 次のコマンドを使用して、現在のコンポーネントパッケージをダウンロードします。 +2. 次のコマンドを使用して、現在のコンポーネントパッケージをダウンロードします。 ```shell wget https://tiup-mirrors.pingcap.com/${component}-${version}-${os}-${arch}.tar.gz -O /tmp/${component}-${version}-${os}-${arch}.tar.gz ``` -3. ファイルをパックするための一時ディレクトリを作成し、そこに移動します。 +3. ファイルをパックするための一時ディレクトリを作成し、そこに移動します。 ```shell mkdir -p /tmp/package && cd /tmp/package ``` -4. 元のバイナリ パッケージを抽出します。 +4. 元のバイナリ パッケージを抽出します。 ```shell tar xf /tmp/${component}-${version}-${os}-${arch}.tar.gz ``` -5. 一時ディレクトリ内のファイル構造を確認します。 +5. 一時ディレクトリ内のファイル構造を確認します。 ```shell find . ``` -6. バイナリ ファイルまたは構成ファイルを一時ディレクトリ内の対応する場所にコピーします。 +6. バイナリ ファイルまたは構成ファイルを一時ディレクトリ内の対応する場所にコピーします。 -7. すべてのファイルを一時ディレクトリにパックします。 +7. すべてのファイルを一時ディレクトリにパックします。 ```shell tar czf /tmp/${component}-hotfix-${os}-${arch}.tar.gz * @@ -71,15 +71,15 @@ tiup cluster patch [flags] ### --overwrite {#overwrite} -- 特定のコンポーネント（TiDBやTiKVなど）にパッチを適用した後、TiUPクラスタがそのコンポーネントをスケールアウトすると、 TiUPはデフォルトで元のコンポーネントバージョンを使用します。将来クラスタがスケールアウトする際にパッチを適用したバージョンを使用するには、コマンドでオプション`--overwrite`を指定する必要があります。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- 特定のコンポーネント（TiDBやTiKVなど）にパッチを適用した後、TiUPクラスタがそのコンポーネントをスケールアウトすると、 TiUPはデフォルトで元のコンポーネントバージョンを使用します。将来クラスタがスケールアウトする際にパッチを適用したバージョンを使用するには、コマンドでオプション`--overwrite`を指定する必要があります。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### --transfer-timeout {#transfer-timeout} -- PDまたはTiKVサービスを再起動する際、TiKV/PDはまず再起動対象ノードのリーダーを別のノードに切り替えます。切り替え処理には時間がかかるため、オプション`--transfer-timeout`を使用して最大待機時間（秒単位）を設定できます。タイムアウト後、 TiUPはサービスを直接再起動します。 -- データ型: `UINT` -- このオプションを指定しない場合、 TiUP は`600`秒待機した後、サービスを直接再起動します。 +- PDまたはTiKVサービスを再起動する際、TiKV/PDはまず再起動対象ノードのリーダーを別のノードに切り替えます。切り替え処理には時間がかかるため、オプション`--transfer-timeout`を使用して最大待機時間（秒単位）を設定できます。タイムアウト後、 TiUPはサービスを直接再起動します。 +- データ型: `UINT` +- このオプションを指定しない場合、 TiUP は`600`秒待機した後、サービスを直接再起動します。 > **Note:** > @@ -87,9 +87,9 @@ tiup cluster patch [flags] ### -N, --node {#n-node} -- 置換するノードを指定します。このオプションの値は、カンマ区切りのノードIDのリストです。ノードIDは、 `tiup cluster display`コマンドで返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の1列目から取得できます。 -- データ型: `STRINGS` -- このオプションを指定しないと、 TiUP はデフォルトで置換するノードを選択しません。 +- 置換するノードを指定します。このオプションの値は、カンマ区切りのノードIDのリストです。ノードIDは、 `tiup cluster display`コマンドで返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の1列目から取得できます。 +- データ型: `STRINGS` +- このオプションを指定しないと、 TiUP はデフォルトで置換するノードを選択しません。 > **Note:** > @@ -97,9 +97,9 @@ tiup cluster patch [flags] ### -R, --role {#r-role} -- 置換するロールを指定します。このオプションの値は、ノードのロールのコンマ区切りリストです。ノードにデプロイされているロールは、 `tiup cluster display`コマンドで返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の2列目から取得できます。 -- データ型: `STRINGS` -- このオプションを指定しないと、 TiUP はデフォルトで置き換えるロールを選択しません。 +- 置換するロールを指定します。このオプションの値は、ノードのロールのコンマ区切りリストです。ノードにデプロイされているロールは、 `tiup cluster display`コマンドで返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の2列目から取得できます。 +- データ型: `STRINGS` +- このオプションを指定しないと、 TiUP はデフォルトで置き換えるロールを選択しません。 > **Note:** > @@ -107,15 +107,15 @@ tiup cluster patch [flags] ### --offline {#offline} -- 現在のクラスターが実行中でないことを宣言します。このオプションが指定されると、 TiUP はサービスリーダーを別のノードに移動させたり、サービスを再起動したりせず、クラスターコンポーネントのバイナリファイルのみを置き換えます。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- 現在のクラスターが実行中でないことを宣言します。このオプションが指定されると、 TiUP はサービスリーダーを別のノードに移動させたり、サービスを再起動したりせず、クラスターコンポーネントのバイナリファイルのみを置き換えます。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 出力 {#outputs} diff --git a/tiup/tiup-component-cluster-prune.md b/tiup/tiup-component-cluster-prune.md index d2042ccaf98fc..98960c1ca5fc5 100644 --- a/tiup/tiup-component-cluster-prune.md +++ b/tiup/tiup-component-cluster-prune.md @@ -17,9 +17,9 @@ tiup cluster prune [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト: false ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-reload.md b/tiup/tiup-component-cluster-reload.md index 30c43b093c74c..1ca02e3777e36 100644 --- a/tiup/tiup-component-cluster-reload.md +++ b/tiup/tiup-component-cluster-reload.md @@ -19,15 +19,15 @@ tiup cluster reload [flags] ### --force {#--force} -- 再ロード プロセス中のエラーを無視し、強制的に再ロードします。 -- データ型: `BOOLEAN` -- デフォルト: false +- 再ロード プロセス中のエラーを無視し、強制的に再ロードします。 +- データ型: `BOOLEAN` +- デフォルト: false ### --transfer-timeout {#--transfer-timeout} -- PDまたはTiKVを再起動する際、再起動されたノードのリーダーノードが最初に他のノードに移行されるため、移行プロセスには時間がかかります。最大待機時間（秒単位）を`-transfer-timeout`に設定できます。タイムアウト後、サービスは待機せずに直接再起動できます。 -- データ型: `UINT` -- デフォルト: 600 +- PDまたはTiKVを再起動する際、再起動されたノードのリーダーノードが最初に他のノードに移行されるため、移行プロセスには時間がかかります。最大待機時間（秒単位）を`-transfer-timeout`に設定できます。タイムアウト後、サービスは待機せずに直接再起動できます。 +- データ型: `UINT` +- デフォルト: 600 > **Note:** > @@ -35,49 +35,49 @@ tiup cluster reload [flags] ### --ignore-config-check {#--ignore-config-check} -- コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `を使用して TiDB、TiKV、PD コンポーネントの設定がチェックされます。``は、デプロイされたバイナリファイルのパスです。``は、ユーザー設定に基づいて生成された設定ファイルです。このチェックをスキップしたい場合は、このオプションを使用できます。 -- データ型: `BOOLEAN` -- デフォルト: false +- コンポーネントのバイナリファイルがデプロイされた後、 ` --config-check `を使用して TiDB、TiKV、PD コンポーネントの設定がチェックされます。``は、デプロイされたバイナリファイルのパスです。``は、ユーザー設定に基づいて生成された設定ファイルです。このチェックをスキップしたい場合は、このオプションを使用できます。 +- データ型: `BOOLEAN` +- デフォルト: false ### -N, --node {#-n---node} -- 再起動するノードを指定します。指定しない場合は、すべてのノードが再起動されます。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 -- データ型: `STRINGS` -- このオプションがコマンドで指定されていない場合は、デフォルトですべてのノードが選択されます。 +- 再起動するノードを指定します。指定しない場合は、すべてのノードが再起動されます。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 +- データ型: `STRINGS` +- このオプションがコマンドで指定されていない場合は、デフォルトですべてのノードが選択されます。 > **Note:** > -> - `-R, --role`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 -> - オプション`--skip-restart`を指定した場合、オプション`-N, --node`は無効になります。 +> - `-R, --role`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 +> - オプション`--skip-restart`を指定した場合、オプション`-N, --node`は無効になります。 ### -R, --role {#-r---role} -- 再起動するロールを指定します。指定しない場合は、すべてのロールが再起動されます。このオプションの値は、ノードロールのカンマ区切りのリストです。ロールは、表[クラスターステータス](/tiup/tiup-component-cluster-display.md)の2番目の列です。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、すべてのロールがデフォルトで選択されます。 +- 再起動するロールを指定します。指定しない場合は、すべてのロールが再起動されます。このオプションの値は、ノードロールのカンマ区切りのリストです。ロールは、表[クラスターステータス](/tiup/tiup-component-cluster-display.md)の2番目の列です。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、すべてのロールがデフォルトで選択されます。 > **Note:** > -> 1. `-N, --node`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 -> 2. オプション`--skip-restart`を指定した場合、オプション`-R, --role`は無効になります。 +> 1. `-N, --node`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 +> 2. オプション`--skip-restart`を指定した場合、オプション`-R, --role`は無効になります。 ### --skip-restart {#--skip-restart} `tiup cluster reload`コマンドは 2 つの操作を実行します。 -- すべてのノード構成を更新します -- 指定されたノードを再起動します +- すべてのノード構成を更新します +- 指定されたノードを再起動します `--skip-restart`オプションを指定すると、ノードを再起動せずに構成のみが更新されるため、更新された構成は適用されず、対応するサービスの次回の再起動まで有効になりません。 -- データ型: `BOOLEAN` -- デフォルト: false +- データ型: `BOOLEAN` +- デフォルト: false ### -h, --help {#-h---help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト: false ### --pre-restart-script {#--pre-restart-script} @@ -85,9 +85,9 @@ tiup cluster reload [flags] > > このオプションは実験的であり、本番での展開には推奨されません。 -- リロード前にスクリプトを実行します。 -- データ型: `STRINGS` -- このオプションは、リロードするノードで実行されるスクリプトのパスを指定します。`--skip-restart`を`true`に設定した場合は無効になります。 +- リロード前にスクリプトを実行します。 +- データ型: `STRINGS` +- このオプションは、リロードするノードで実行されるスクリプトのパスを指定します。`--skip-restart`を`true`に設定した場合は無効になります。 ### --post-restart-script {#--post-restart-script} @@ -95,9 +95,9 @@ tiup cluster reload [flags] > > このオプションは実験的であり、本番での展開には推奨されません。 -- リロード後にスクリプトを実行します。 -- データ型: `STRINGS` -- このオプションは、ノードのリロード後に実行されるスクリプトのパスを指定します。`--skip-restart`が`true`に設定されている場合は有効になりません。 +- リロード後にスクリプトを実行します。 +- データ型: `STRINGS` +- このオプションは、ノードのリロード後に実行されるスクリプトのパスを指定します。`--skip-restart`が`true`に設定されている場合は有効になりません。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-rename.md b/tiup/tiup-component-cluster-rename.md index da090e890d2de..626e24a9ec42c 100644 --- a/tiup/tiup-component-cluster-rename.md +++ b/tiup/tiup-component-cluster-rename.md @@ -11,8 +11,8 @@ summary: tiup cluster renameコマンドは、デプロイ後にクラスター > > TiUPクラスターの`dashboard_dir`フィールドが`grafana_servers`に設定されている場合、コマンド`tiup cluster rename`を実行してクラスターの名前を変更した後、次の追加手順が必要になります。 > -> - ローカル ダッシュボード ディレクトリ内の`*.json`ファイルについては、各ファイルの`datasource`フィールドを新しいクラスター名に更新します。`datasource`の値はクラスターの名前である必要があるためです。 -> - コマンド`tiup cluster reload -R grafana`を実行します。 +> - ローカル ダッシュボード ディレクトリ内の`*.json`ファイルについては、各ファイルの`datasource`フィールドを新しいクラスター名に更新します。`datasource`の値はクラスターの名前である必要があるためです。 +> - コマンド`tiup cluster reload -R grafana`を実行します。 ## 構文 {#syntax} @@ -20,16 +20,16 @@ summary: tiup cluster renameコマンドは、デプロイ後にクラスター tiup cluster rename [flags] ``` -- `` : 古いクラスター名。 -- `` : 新しいクラスター名。 +- `` : 古いクラスター名。 +- `` : 新しいクラスター名。 ## オプション {#options} ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 出力 {#outputs} diff --git a/tiup/tiup-component-cluster-replay.md b/tiup/tiup-component-cluster-replay.md index a22ed66ed0a97..3a9c8b14bf054 100644 --- a/tiup/tiup-component-cluster-replay.md +++ b/tiup/tiup-component-cluster-replay.md @@ -13,7 +13,7 @@ summary: tiup cluster replay` コマンドを使用すると、失敗したク tiup cluster replay [flags] ``` -- `` : 再試行するコマンドの`audit-id` 。[`tiup cluster audit`](/tiup/tiup-component-cluster-audit.md)を使用すると、履歴コマンドとその`audit-id`を表示できます。 +- `` : 再試行するコマンドの`audit-id` 。[`tiup cluster audit`](/tiup/tiup-component-cluster-audit.md)を使用すると、履歴コマンドとその`audit-id`を表示できます。 ## オプション {#option} diff --git a/tiup/tiup-component-cluster-restart.md b/tiup/tiup-component-cluster-restart.md index 612a759c4ecd9..d7d86e34c5617 100644 --- a/tiup/tiup-component-cluster-restart.md +++ b/tiup/tiup-component-cluster-restart.md @@ -23,9 +23,9 @@ tiup cluster restart [flags] ### -N, --node {#n-node} -- 再起動するノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、コマンド`tiup cluster display`で返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の最初の列から取得できます。 -- データ型: `STRING` -- このオプションを指定しない場合、 TiUP はデフォルトですべてのノードを再起動します。 +- 再起動するノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、コマンド`tiup cluster display`で返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の最初の列から取得できます。 +- データ型: `STRING` +- このオプションを指定しない場合、 TiUP はデフォルトですべてのノードを再起動します。 > **Note:** > @@ -33,9 +33,9 @@ tiup cluster restart [flags] ### -R, --role {#r-role} -- 再起動するノードのロールを指定します。このオプションの値は、ノードのロールをカンマ区切りでリストしたものです。ノードのロールは、 `tiup cluster display`コマンドで返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の2列目から取得できます。 -- データ型: `STRING` -- このオプションを指定しない場合、 TiUP はデフォルトですべてのロールのノードを再起動します。 +- 再起動するノードのロールを指定します。このオプションの値は、ノードのロールをカンマ区切りでリストしたものです。ノードのロールは、 `tiup cluster display`コマンドで返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の2列目から取得できます。 +- データ型: `STRING` +- このオプションを指定しない場合、 TiUP はデフォルトですべてのロールのノードを再起動します。 > **Note:** > @@ -43,9 +43,9 @@ tiup cluster restart [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 出力 {#outputs} diff --git a/tiup/tiup-component-cluster-scale-in.md b/tiup/tiup-component-cluster-scale-in.md index 7205400d67996..bec6efc90b35c 100644 --- a/tiup/tiup-component-cluster-scale-in.md +++ b/tiup/tiup-component-cluster-scale-in.md @@ -11,20 +11,20 @@ summary: 「tiup cluster scale-in」コマンドは、指定されたノード TiKV およびTiFlashコンポーネントは非同期的にオフラインになるため (最初にTiUP がAPI を介してノードを削除する必要がある)、停止プロセスには長い時間がかかる (ノードが正常にオフラインになったかどうかをTiUPが継続的に確認する必要がある) ため、TiKV およびTiFlashコンポーネントは特に次のように処理されます。 -- TiKV およびTiFlashコンポーネントの場合: +- TiKV およびTiFlashコンポーネントの場合: - 1. TiUPクラスタはAPI を介してノードをオフラインにし、プロセスが完了するのを待たずにすぐに終了します。 - 2. スケールインされているノードのステータスを確認するには、 `tiup cluster display`コマンドを実行し、ステータスが`Tombstone`になるまで待つ必要があります。 - 3. ステータス`Tombstone`のノードをクリーンアップするには、コマンド`tiup cluster prune`を実行する必要があります。コマンド`tiup cluster prune`は以下の操作を実行します。 + 1. TiUPクラスタはAPI を介してノードをオフラインにし、プロセスが完了するのを待たずにすぐに終了します。 + 2. スケールインされているノードのステータスを確認するには、 `tiup cluster display`コマンドを実行し、ステータスが`Tombstone`になるまで待つ必要があります。 + 3. ステータス`Tombstone`のノードをクリーンアップするには、コマンド`tiup cluster prune`を実行する必要があります。コマンド`tiup cluster prune`は以下の操作を実行します。 - - オフラインになったノードのサービスを停止します。 - - オフラインになったノードのデータ ファイルをクリーンアップします。 - - クラスター トポロジを更新し、オフラインになったノードを削除します。 + - オフラインになったノードのサービスを停止します。 + - オフラインになったノードのデータ ファイルをクリーンアップします。 + - クラスター トポロジを更新し、オフラインになったノードを削除します。 その他のコンポーネントの場合: -- PD コンポーネントをオフラインにする場合、 TiUP クラスタ はAPI を介して指定されたノードをクラスターからすばやく削除し、指定された PD ノードのサービスを停止し、ノードから関連データ ファイルを削除します。 -- 他のコンポーネントを停止する場合、 TiUP クラスタ はノード サービスを直接停止し、指定されたノードから関連データ ファイルを削除します。 +- PD コンポーネントをオフラインにする場合、 TiUP クラスタ はAPI を介して指定されたノードをクラスターからすばやく削除し、指定された PD ノードのサービスを停止し、ノードから関連データ ファイルを削除します。 +- 他のコンポーネントを停止する場合、 TiUP クラスタ はノード サービスを直接停止し、指定されたノードから関連データ ファイルを削除します。 ## 構文 {#syntax} @@ -38,15 +38,15 @@ tiup cluster scale-in [flags] ### -N, --node {#n-node} -- 停止するノードを指定します。複数のノードはカンマで区切られます。 -- データ型: `STRING` -- デフォルト値はありません。このオプションは必須であり、値はnull以外である必要があります。 +- 停止するノードを指定します。複数のノードはカンマで区切られます。 +- データ型: `STRING` +- デフォルト値はありません。このオプションは必須であり、値はnull以外である必要があります。 ### --force {#force} -- 指定されたノードをクラスタから強制的に削除するかどうかを制御します。オフラインにするノードのホストがダウンしている場合、SSH経由でノードに接続して操作を行うことができないことがあります。その場合は、 `--force`オプションを使用してノードをクラスタから強制的に削除できます。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- 指定されたノードをクラスタから強制的に削除するかどうかを制御します。オフラインにするノードのホストがダウンしている場合、SSH経由でノードに接続して操作を行うことができないことがあります。その場合は、 `--force`オプションを使用してノードをクラスタから強制的に削除できます。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 > **Warning:** > @@ -54,9 +54,9 @@ tiup cluster scale-in [flags] ### --transfer-timeout {#transfer-timeout} -- PDノードまたはTiKVノードを削除する場合、まずそのノードのリージョンリーダーが別のノードに転送されます。転送プロセスには時間がかかるため、 `--transfer-timeout`を設定することで最大待機時間（秒単位）を設定できます。タイムアウト後、 `tiup cluster scale-in`コマンドは待機をスキップし、スケールインを直接開始します。 -- データ型: `UINT` -- このオプションはデフォルトで有効になっており、 `600`秒 (デフォルト値) が渡されます。 +- PDノードまたはTiKVノードを削除する場合、まずそのノードのリージョンリーダーが別のノードに転送されます。転送プロセスには時間がかかるため、 `--transfer-timeout`を設定することで最大待機時間（秒単位）を設定できます。タイムアウト後、 `tiup cluster scale-in`コマンドは待機をスキップし、スケールインを直接開始します。 +- データ型: `UINT` +- このオプションはデフォルトで有効になっており、 `600`秒 (デフォルト値) が渡されます。 > **Note:** > @@ -64,9 +64,9 @@ tiup cluster scale-in [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-scale-out.md b/tiup/tiup-component-cluster-scale-out.md index 52c088b7ed28a..b6469b665bed8 100644 --- a/tiup/tiup-component-cluster-scale-out.md +++ b/tiup/tiup-component-cluster-scale-out.md @@ -23,41 +23,41 @@ tiup cluster scale-out [flags] ### -u, --user {#u-user} -- ターゲットマシンへの接続に使用するユーザー名を指定します。このユーザーは、ターゲットマシン上でシークレットフリーのsudo root権限を持っている必要があります。 -- データ型: `STRING` -- デフォルト: コマンドを実行する現在のユーザー。 +- ターゲットマシンへの接続に使用するユーザー名を指定します。このユーザーは、ターゲットマシン上でシークレットフリーのsudo root権限を持っている必要があります。 +- データ型: `STRING` +- デフォルト: コマンドを実行する現在のユーザー。 ### -i, --identity_file {#i-identity-file} -- ターゲット マシンに接続するために使用するキー ファイルを指定します。 -- データ型: `STRING` -- コマンドでこのオプションを指定しない場合は、デフォルトで`~/.ssh/id_rsa`ファイルを使用してターゲット マシンに接続します。 +- ターゲット マシンに接続するために使用するキー ファイルを指定します。 +- データ型: `STRING` +- コマンドでこのオプションを指定しない場合は、デフォルトで`~/.ssh/id_rsa`ファイルを使用してターゲット マシンに接続します。 ### -p, --password {#p-password} -- ターゲットマシンへの接続に使用するパスワードを指定します。このオプションと`-i/--identity_file`同時に使用しないでください。 -- データ型: `BOOLEAN` -- デフォルト: false +- ターゲットマシンへの接続に使用するパスワードを指定します。このオプションと`-i/--identity_file`同時に使用しないでください。 +- データ型: `BOOLEAN` +- デフォルト: false ### --no-labels {#no-labels} -- このオプションはラベル チェックをスキップするために使用されます。 -- 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、リスクが生じます。PDはクラスタトポロジを把握していないため、同じ物理マシン上の異なるTiKVノードにリージョンのレプリカを複数スケジュールしてしまう可能性があり、その結果、この物理マシンが単一障害点となります。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)を参照してください。 -- テスト環境では、このリスクは問題にならない可能性があり、 `--no-labels`を使用してチェックをスキップできます。 -- データ型: `BOOLEAN` -- デフォルト: false +- このオプションはラベル チェックをスキップするために使用されます。 +- 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、リスクが生じます。PDはクラスタトポロジを把握していないため、同じ物理マシン上の異なるTiKVノードにリージョンのレプリカを複数スケジュールしてしまう可能性があり、その結果、この物理マシンが単一障害点となります。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)を参照してください。 +- テスト環境では、このリスクは問題にならない可能性があり、 `--no-labels`を使用してチェックをスキップできます。 +- データ型: `BOOLEAN` +- デフォルト: false ### --skip-create-user {#skip-create-user} -- クラスタのデプロイメント中、 tiup-cluster はトポロジファイルで指定されたユーザー名が存在するかどうかを確認します。存在しない場合は、ユーザー名を作成します。このチェックをスキップするには、 `--skip-create-user`オプションを使用します。 -- データ型: `BOOLEAN` -- デフォルト: false +- クラスタのデプロイメント中、 tiup-cluster はトポロジファイルで指定されたユーザー名が存在するかどうかを確認します。存在しない場合は、ユーザー名を作成します。このチェックをスキップするには、 `--skip-create-user`オプションを使用します。 +- データ型: `BOOLEAN` +- デフォルト: false ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト: false ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-start.md b/tiup/tiup-component-cluster-start.md index 3b96a4239a050..90e7570a6568a 100644 --- a/tiup/tiup-component-cluster-start.md +++ b/tiup/tiup-component-cluster-start.md @@ -23,14 +23,14 @@ tiup cluster start [flags] > **Note:** > -> - TiDBクラスタを安全に起動した後は、パスワードなしでrootユーザーを使用してデータベースにログインすることはできません。そのため、今後のログインのために、コマンドラインから返されるパスワードを記録しておく必要があります。 -> - パスワードは一度だけ生成されます。パスワードを記録していない場合、または忘れた場合は、 [`root`パスワードを忘れた](/user-account-management.md#forget-the-root-password)を参照してパスワードを変更してください。 +> - TiDBクラスタを安全に起動した後は、パスワードなしでrootユーザーを使用してデータベースにログインすることはできません。そのため、今後のログインのために、コマンドラインから返されるパスワードを記録しておく必要があります。 +> - パスワードは一度だけ生成されます。パスワードを記録していない場合、または忘れた場合は、 [`root`パスワードを忘れた](/user-account-management.md#forget-the-root-password)を参照してパスワードを変更してください。 ### -N, --node {#n-node} -- 起動するノードを指定します。このオプションの値は、カンマ区切りのノードIDのリストです。ノードIDは、コマンド`tiup cluster display`で返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の1列目から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、すべてのノードがデフォルトで起動されます。 +- 起動するノードを指定します。このオプションの値は、カンマ区切りのノードIDのリストです。ノードIDは、コマンド`tiup cluster display`で返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の1列目から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、すべてのノードがデフォルトで起動されます。 > **Note:** > @@ -38,9 +38,9 @@ tiup cluster start [flags] ### -R, --role {#r-role} -- 起動するノードのロールを指定します。このオプションの値は、ノードのロールをカンマで区切ったリストです。ノードのロールは、 `tiup cluster display`コマンドで返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の2列目から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、すべてのロールがデフォルトで開始されます。 +- 起動するノードのロールを指定します。このオプションの値は、ノードのロールをカンマで区切ったリストです。ノードのロールは、 `tiup cluster display`コマンドで返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の2列目から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、すべてのロールがデフォルトで開始されます。 > **Note:** > @@ -48,9 +48,9 @@ tiup cluster start [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-stop.md b/tiup/tiup-component-cluster-stop.md index 869bffa63c1b1..bd75909659d24 100644 --- a/tiup/tiup-component-cluster-stop.md +++ b/tiup/tiup-component-cluster-stop.md @@ -23,9 +23,9 @@ tiup cluster stop [flags] ### -N, --node {#n-node} -- 停止するノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、コマンド`tiup cluster display`で返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の1列目から取得できます。 -- データ型: `STRINGS` -- このオプションがコマンドで指定されていない場合、コマンドはデフォルトですべてのノードを停止します。 +- 停止するノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、コマンド`tiup cluster display`で返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の1列目から取得できます。 +- データ型: `STRINGS` +- このオプションがコマンドで指定されていない場合、コマンドはデフォルトですべてのノードを停止します。 > **Note:** > @@ -33,9 +33,9 @@ tiup cluster stop [flags] ### -R, --role {#r-role} -- 停止するノードのロールを指定します。このオプションの値は、ノードのロールをカンマで区切ったリストです。ノードのロールは、 `tiup cluster display`コマンドで返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の2列目から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合、コマンドはデフォルトですべてのロールを停止します。 +- 停止するノードのロールを指定します。このオプションの値は、ノードのロールをカンマで区切ったリストです。ノードのロールは、 `tiup cluster display`コマンドで返される[クラスターステータステーブル](/tiup/tiup-component-cluster-display.md)の2列目から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合、コマンドはデフォルトですべてのロールを停止します。 > **Note:** > @@ -43,9 +43,9 @@ tiup cluster stop [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-template.md b/tiup/tiup-component-cluster-template.md index 7b04bd28ef057..715bbfaecb8e5 100644 --- a/tiup/tiup-component-cluster-template.md +++ b/tiup/tiup-component-cluster-template.md @@ -15,30 +15,30 @@ tiup cluster template [flags] このオプションを指定しない場合、出力のデフォルト テンプレートには次のインスタンスが含まれます。 -- 3つのPDインスタンス -- 3 つの TiKV インスタンス -- 3 つの TiDB インスタンス -- 2 つのTiFlashインスタンス -- 1つのPrometheusインスタンス -- 1 つの Grafana インスタンス -- 1 つの Alertmanager インスタンス +- 3つのPDインスタンス +- 3 つの TiKV インスタンス +- 3 つの TiDB インスタンス +- 2 つのTiFlashインスタンス +- 1つのPrometheusインスタンス +- 1 つの Grafana インスタンス +- 1 つの Alertmanager インスタンス ## オプション {#options} ### --full {#full} -- 設定可能なパラメータがコメント化された詳細なトポロジテンプレートを出力します。このオプションを有効にするには、コマンドに追加します。 -- このオプションを指定しない場合は、デフォルトで単純なトポロジ テンプレートが出力されます。 +- 設定可能なパラメータがコメント化された詳細なトポロジテンプレートを出力します。このオプションを有効にするには、コマンドに追加します。 +- このオプションを指定しない場合は、デフォルトで単純なトポロジ テンプレートが出力されます。 ### --local {#local} -- ローカル クラスターの単純なトポロジ テンプレートを出力します。これは直接使用でき、 `global`パラメータは必要に応じて調整できます。 -- このテンプレートは、PD サービス、TiDB サービス、TiKV サービス、Prometheus サービス、および Grafana サービスを作成します。 +- ローカル クラスターの単純なトポロジ テンプレートを出力します。これは直接使用でき、 `global`パラメータは必要に応じて調整できます。 +- このテンプレートは、PD サービス、TiDB サービス、TiKV サービス、Prometheus サービス、および Grafana サービスを作成します。 ### --multi-dc {#multi-dc} -- 複数のデータセンターのトポロジテンプレートを出力します。このオプションを有効にするには、コマンドに追加してください。 -- このオプションを指定しない場合は、デフォルトで単一のデータセンターのトポロジ テンプレートが出力されます。 +- 複数のデータセンターのトポロジテンプレートを出力します。このオプションを有効にするには、コマンドに追加してください。 +- このオプションを指定しない場合は、デフォルトで単一のデータセンターのトポロジ テンプレートが出力されます。 ### -h, --help {#h-help} diff --git a/tiup/tiup-component-cluster-tls.md b/tiup/tiup-component-cluster-tls.md index 86cd25cffd8a6..e8ed25785ecd1 100644 --- a/tiup/tiup-component-cluster-tls.md +++ b/tiup/tiup-component-cluster-tls.md @@ -23,30 +23,30 @@ tiup cluster tls [flags] ### --clean-certificate {#clean-certificate} -- TLSを無効にする場合は、このオプションを使用して以前に生成された証明書を削除してください。 -- データタイプ: `BOOLEAN` -- デフォルト: `false` -- このオプションを指定しない場合、TLSを再度有効にした際に、古い証明書が再利用される可能性があります。 +- TLSを無効にする場合は、このオプションを使用して以前に生成された証明書を削除してください。 +- データタイプ: `BOOLEAN` +- デフォルト: `false` +- このオプションを指定しない場合、TLSを再度有効にした際に、古い証明書が再利用される可能性があります。 ### --force {#force} -- クラスターの現在のTLSステータスに関係なく、TLSを強制的に有効または無効にします。 -- データタイプ: `BOOLEAN` -- デフォルト: `false` -- このオプションを指定しない場合、クラスターが既に要求された状態にある場合は、操作はスキップされます。 +- クラスターの現在のTLSステータスに関係なく、TLSを強制的に有効または無効にします。 +- データタイプ: `BOOLEAN` +- デフォルト: `false` +- このオプションを指定しない場合、クラスターが既に要求された状態にある場合は、操作はスキップされます。 ### --reload-certificate {#reload-certificate} -- TLSを有効にする場合は、このオプションを使用して証明書を再生成してください。 -- データタイプ: `BOOLEAN` -- デフォルト: `false` -- このオプションを指定しない場合、既に証明書が存在する場合は、新しい証明書は生成されません。 +- TLSを有効にする場合は、このオプションを使用して証明書を再生成してください。 +- データタイプ: `BOOLEAN` +- デフォルト: `false` +- このオプションを指定しない場合、既に証明書が存在する場合は、新しい証明書は生成されません。 ### -h, --help {#h-help} -- ヘルプ情報を表示します。 -- データタイプ: `BOOLEAN` -- デフォルト: `false` +- ヘルプ情報を表示します。 +- データタイプ: `BOOLEAN` +- デフォルト: `false` ## 出力 {#output} diff --git a/tiup/tiup-component-cluster-upgrade.md b/tiup/tiup-component-cluster-upgrade.md index a27ed9e342675..aa3bb19337dd1 100644 --- a/tiup/tiup-component-cluster-upgrade.md +++ b/tiup/tiup-component-cluster-upgrade.md @@ -13,16 +13,16 @@ summary: tiup cluster upgradeコマンドは、指定したクラスターを特 tiup cluster upgrade [flags] ``` -- `` : 操作対象のクラスタ名。クラスタ名を忘れた場合は、 [クラスターリスト](/tiup/tiup-component-cluster-list.md)コマンドで確認できます。 -- `` : アップグレード先のバージョン（例： `v8.5.3` ）。現在、現在のクラスターよりも上位のバージョンへのアップグレードのみが許可されており、ダウングレードは許可されていません。また、ナイトリーバージョンへのアップグレードも許可されていません。 +- `` : 操作対象のクラスタ名。クラスタ名を忘れた場合は、 [クラスターリスト](/tiup/tiup-component-cluster-list.md)コマンドで確認できます。 +- `` : アップグレード先のバージョン（例： `v8.5.3` ）。現在、現在のクラスターよりも上位のバージョンへのアップグレードのみが許可されており、ダウングレードは許可されていません。また、ナイトリーバージョンへのアップグレードも許可されていません。 ## オプション {#options} ### --force {#--force} -- クラスターをアップグレードするには、クラスターが現在起動していることを確認する必要があります。場合によっては、クラスターが起動していない状態でアップグレードを実行したい場合があります。その場合は、 `--force`を使用すると、アップグレード中のエラーを無視し、バイナリファイルを強制的に置き換えてクラスターを起動できます。 -- データ型: `BOOLEAN` -- デフォルト: false +- クラスターをアップグレードするには、クラスターが現在起動していることを確認する必要があります。場合によっては、クラスターが起動していない状態でアップグレードを実行したい場合があります。その場合は、 `--force`を使用すると、アップグレード中のエラーを無視し、バイナリファイルを強制的に置き換えてクラスターを起動できます。 +- データ型: `BOOLEAN` +- デフォルト: false > **Note:** > @@ -30,9 +30,9 @@ tiup cluster upgrade [flags] ### --transfer-timeout {#--transfer-timeout} -- PDまたはTiKVをアップグレードする場合、アップグレード対象ノードのリーダーノードが最初に他のノードに移行されます。移行プロセスには時間がかかります。`-transfer-timeout`で最大待機時間（秒単位）を設定できます。タイムアウト後、待機はスキップされ、サービスは直接アップグレードされます。 -- データ型: `uint` -- デフォルト: 600 +- PDまたはTiKVをアップグレードする場合、アップグレード対象ノードのリーダーノードが最初に他のノードに移行されます。移行プロセスには時間がかかります。`-transfer-timeout`で最大待機時間（秒単位）を設定できます。タイムアウト後、待機はスキップされ、サービスは直接アップグレードされます。 +- データ型: `uint` +- デフォルト: 600 > **Note:** > @@ -40,94 +40,94 @@ tiup cluster upgrade [flags] ### --ignore-config-check {#--ignore-config-check} -- バイナリの更新後、 ` --config-check `を使用して TiDB、TiKV、PD コンポーネントの構成チェックが実行されます。``は、新しくデプロイされたバイナリへのパスであり、 ``は、ユーザー設定に基づいて生成された構成ファイルです。このチェックをスキップするには、 `--ignore-config-check`オプションを使用します。 -- データ型: `BOOLEAN` -- デフォルト: false +- バイナリの更新後、 ` --config-check `を使用して TiDB、TiKV、PD コンポーネントの構成チェックが実行されます。``は、新しくデプロイされたバイナリへのパスであり、 ``は、ユーザー設定に基づいて生成された構成ファイルです。このチェックをスキップするには、 `--ignore-config-check`オプションを使用します。 +- データ型: `BOOLEAN` +- デフォルト: false ### --ignore-version-check {#--ignore-version-check} -- アップグレード前に、 TiUP はターゲットバージョンが現在のバージョン以上であるかどうかを確認します。このチェックを省略するには、オプション`--ignore-version-check`を使用します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- アップグレード前に、 TiUP はターゲットバージョンが現在のバージョン以上であるかどうかを確認します。このチェックを省略するには、オプション`--ignore-version-check`を使用します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### --offline {#--offline} -- 現在のクラスターが実行中でないことを宣言します。このオプションが指定されると、 TiUP はサービスリーダーを別のノードに移動させたり、サービスを再起動したりせず、クラスターコンポーネントのバイナリファイルのみを置き換えます。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- 現在のクラスターが実行中でないことを宣言します。このオプションが指定されると、 TiUP はサービスリーダーを別のノードに移動させたり、サービスを再起動したりせず、クラスターコンポーネントのバイナリファイルのみを置き換えます。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### --pdバージョン {#--pd-version} -- PDのバージョンを指定します。このオプションを設定すると、PDのバージョンとクラスターのバージョンが一致しなくなります。 -- データ型: `STRINGS` -- このオプションが設定されていない場合、PD のバージョンはクラスターのバージョンと一致し続けます。 +- PDのバージョンを指定します。このオプションを設定すると、PDのバージョンとクラスターのバージョンが一致しなくなります。 +- データ型: `STRINGS` +- このオプションが設定されていない場合、PD のバージョンはクラスターのバージョンと一致し続けます。 ### --tikv バージョン {#--tikv-version} -- TiKVのバージョンを指定します。このオプションを設定すると、TiKVのバージョンはクラスターのバージョンと一致しなくなります。 -- データ型: `STRINGS` -- このオプションが設定されていない場合、TiKV のバージョンはクラスターのバージョンと一致し続けます。 +- TiKVのバージョンを指定します。このオプションを設定すると、TiKVのバージョンはクラスターのバージョンと一致しなくなります。 +- データ型: `STRINGS` +- このオプションが設定されていない場合、TiKV のバージョンはクラスターのバージョンと一致し続けます。 ### --tikv-cdc-バージョン {#--tikv-cdc-version} -- TiKV CDCのバージョンを指定します。このオプションを設定すると、TiKV CDCのバージョンはクラスタのバージョンと一致しなくなります。 -- データ型: `STRINGS` -- このオプションが設定されていない場合、TiKV CDC のバージョンはクラスターのバージョンと一致し続けます。 +- TiKV CDCのバージョンを指定します。このオプションを設定すると、TiKV CDCのバージョンはクラスタのバージョンと一致しなくなります。 +- データ型: `STRINGS` +- このオプションが設定されていない場合、TiKV CDC のバージョンはクラスターのバージョンと一致し続けます。 ### --tiflash-version {#--tiflash-version} -- TiFlashのバージョンを指定します。このオプションを設定すると、 TiFlashのバージョンはクラスターのバージョンと一致しなくなります。 -- データ型: `STRINGS` -- このオプションが設定されていない場合、 TiFlashのバージョンはクラスターのバージョンと一致したままになります。 +- TiFlashのバージョンを指定します。このオプションを設定すると、 TiFlashのバージョンはクラスターのバージョンと一致しなくなります。 +- データ型: `STRINGS` +- このオプションが設定されていない場合、 TiFlashのバージョンはクラスターのバージョンと一致したままになります。 ### --cdc バージョン {#--cdc-version} -- TiCDCのバージョンを指定します。このオプションを設定すると、TiCDCのバージョンはクラスターのバージョンと一致しなくなります。 -- データ型: `STRINGS` -- このオプションが設定されていない場合、TiCDC のバージョンはクラスターのバージョンと一致し続けます。 +- TiCDCのバージョンを指定します。このオプションを設定すると、TiCDCのバージョンはクラスターのバージョンと一致しなくなります。 +- データ型: `STRINGS` +- このオプションが設定されていない場合、TiCDC のバージョンはクラスターのバージョンと一致し続けます。 ### --tiproxy バージョン {#--tiproxy-version} -- TiProxyのバージョンを指定します。このオプションを設定すると、TiProxyのバージョンはクラスタのバージョンと一致しなくなります。 -- データ型: `STRINGS` -- このオプションが設定されていない場合、TiProxy のバージョンはクラスターのバージョンと一致したままになります。 +- TiProxyのバージョンを指定します。このオプションを設定すると、TiProxyのバージョンはクラスタのバージョンと一致しなくなります。 +- データ型: `STRINGS` +- このオプションが設定されていない場合、TiProxy のバージョンはクラスターのバージョンと一致したままになります。 ### --tidb-ダッシュボードバージョン {#--tidb-dashboard-version} -- TiDB Dashboardのバージョンを指定します。このオプションを設定すると、TiDB Dashboardのバージョンはクラスターのバージョンと一致しなくなります。 -- データ型: `STRINGS` -- このオプションが設定されていない場合、TiDB Dashboardのバージョンはクラスターのバージョンと一致したままになります。 +- TiDB Dashboardのバージョンを指定します。このオプションを設定すると、TiDB Dashboardのバージョンはクラスターのバージョンと一致しなくなります。 +- データ型: `STRINGS` +- このオプションが設定されていない場合、TiDB Dashboardのバージョンはクラスターのバージョンと一致したままになります。 ### --alertmanager-バージョン {#--alertmanager-version} -- Alertmanagerのバージョンを指定します。このオプションを設定すると、Alertmanagerのバージョンはクラスターのバージョンと一致しなくなります。 -- データ型: `STRINGS` -- このオプションが設定されていない場合、アラート マネージャーのバージョンはクラスターのバージョンと一致したままになります。 +- Alertmanagerのバージョンを指定します。このオプションを設定すると、Alertmanagerのバージョンはクラスターのバージョンと一致しなくなります。 +- データ型: `STRINGS` +- このオプションが設定されていない場合、アラート マネージャーのバージョンはクラスターのバージョンと一致したままになります。 ### --blackbox-exporter-version {#--blackbox-exporter-version} -- Blackbox Exporterのバージョンを指定します。このオプションを設定すると、Blackbox Exporterのバージョンとクラスタのバージョンが一致しなくなります。 -- データ型: `STRINGS` -- このオプションが設定されていない場合、Blackbox Exporter のバージョンはクラスターのバージョンと一致したままになります。 +- Blackbox Exporterのバージョンを指定します。このオプションを設定すると、Blackbox Exporterのバージョンとクラスタのバージョンが一致しなくなります。 +- データ型: `STRINGS` +- このオプションが設定されていない場合、Blackbox Exporter のバージョンはクラスターのバージョンと一致したままになります。 ### --node-exporter-version {#--node-exporter-version} -- Node Exporterのバージョンを指定します。このオプションを設定すると、Node Exporterのバージョンとクラスターのバージョンが一致しなくなります。 -- データ型: `STRINGS` -- このオプションが設定されていない場合、Node Exporter のバージョンはクラスターのバージョンと一致したままになります。 +- Node Exporterのバージョンを指定します。このオプションを設定すると、Node Exporterのバージョンとクラスターのバージョンが一致しなくなります。 +- データ型: `STRINGS` +- このオプションが設定されていない場合、Node Exporter のバージョンはクラスターのバージョンと一致したままになります。 ### --restart-timeout {#--restart-timeout} -- ローリング アップグレード中にコンポーネントをアップグレードした後の待機時間を指定します。 -- データ型: `STRINGS` [`golang time.ParseDuration`](https://pkg.go.dev/time#ParseDuration)で解析できるすべての型がサポートされます。 -- デフォルト: `0` -- このオプションを指定しないと、コンポーネントのアップグレード後に待機時間は発生しません。 +- ローリング アップグレード中にコンポーネントをアップグレードした後の待機時間を指定します。 +- データ型: `STRINGS` [`golang time.ParseDuration`](https://pkg.go.dev/time#ParseDuration)で解析できるすべての型がサポートされます。 +- デフォルト: `0` +- このオプションを指定しないと、コンポーネントのアップグレード後に待機時間は発生しません。 ### -h, --help {#-h---help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### ---pre-upgrade-script {#---pre-upgrade-script} @@ -135,9 +135,9 @@ tiup cluster upgrade [flags] > > このオプションは実験的であり、本番での展開には推奨されません。 -- アップグレード前にスクリプトを実行します。 -- データ型: `STRINGS` -- このオプションは、アップグレードするノードで実行されるスクリプトのパスを指定します。 +- アップグレード前にスクリプトを実行します。 +- データ型: `STRINGS` +- このオプションは、アップグレードするノードで実行されるスクリプトのパスを指定します。 ### ---post-upgrade-script {#---post-upgrade-script} @@ -145,9 +145,9 @@ tiup cluster upgrade [flags] > > このオプションは実験的であり、本番での展開には推奨されません。 -- アップグレード後にスクリプトを実行します。 -- データ型: `STRINGS` -- このオプションは、ノードのアップグレード後に実行されるスクリプトのパスを指定します。このスクリプトは、アップグレードされたノード自体で実行されます。 +- アップグレード後にスクリプトを実行します。 +- データ型: `STRINGS` +- このオプションは、ノードのアップグレード後に実行されるスクリプトのパスを指定します。このスクリプトは、アップグレードされたノード自体で実行されます。 ## 出力 {#output} diff --git a/tiup/tiup-component-cluster.md b/tiup/tiup-component-cluster.md index 695d4002dfa37..0f6b08ed6fe15 100644 --- a/tiup/tiup-component-cluster.md +++ b/tiup/tiup-component-cluster.md @@ -19,74 +19,74 @@ tiup cluster [command] [flags] ### --ssh {#--ssh} -- コマンド実行のためにリモート エンド (TiDB サービスがデプロイされているマシン) に接続する SSH クライアントを指定します。 +- コマンド実行のためにリモート エンド (TiDB サービスがデプロイされているマシン) に接続する SSH クライアントを指定します。 -- データ型: `STRING` +- データ型: `STRING` -- サポートされる値: +- サポートされる値: - - `builtin` : tiup-clusterに組み込まれている easyssh クライアントを SSH クライアントとして使用します。 - - `system` : 現在のオペレーティング システムのデフォルトの SSH クライアントを使用します。 - - `none` : SSHクライアントは使用されません。デプロイメントは現在のマシンのみに適用されます。 + - `builtin` : tiup-clusterに組み込まれている easyssh クライアントを SSH クライアントとして使用します。 + - `system` : 現在のオペレーティング システムのデフォルトの SSH クライアントを使用します。 + - `none` : SSHクライアントは使用されません。デプロイメントは現在のマシンのみに適用されます。 -- コマンドでこのオプションを指定しない場合は、デフォルト値として`builtin`が使用されます。 +- コマンドでこのオプションを指定しない場合は、デフォルト値として`builtin`が使用されます。 ### --sshタイムアウト {#--ssh-timeout} -- SSH 接続のタイムアウトを秒単位で指定します。 -- データ型: `UINT` -- コマンドでこのオプションを指定しない場合、デフォルトのタイムアウトは`5`秒になります。 +- SSH 接続のタイムアウトを秒単位で指定します。 +- データ型: `UINT` +- コマンドでこのオプションを指定しない場合、デフォルトのタイムアウトは`5`秒になります。 ### --wait-timeout {#--wait-timeout} -- 操作プロセスの各ステップの最大待機時間（秒単位）を指定します。操作プロセスは、systemctl によるサービスの開始または停止の指定、ポートのオンラインまたはオフラインの待機など、多くのステップで構成されます。各ステップは数秒かかる場合があります。ステップの実行時間が指定されたタイムアウトを超えた場合、そのステップはエラーで終了します。 -- データ型: `UINT` -- コマンドでこのオプションを指定しない場合、各ステップの最大待機時間は`120`秒になります。 +- 操作プロセスの各ステップの最大待機時間（秒単位）を指定します。操作プロセスは、systemctl によるサービスの開始または停止の指定、ポートのオンラインまたはオフラインの待機など、多くのステップで構成されます。各ステップは数秒かかる場合があります。ステップの実行時間が指定されたタイムアウトを超えた場合、そのステップはエラーで終了します。 +- データ型: `UINT` +- コマンドでこのオプションを指定しない場合、各ステップの最大待機時間は`120`秒になります。 ### -y, --yes {#-y---yes} -- すべてのリスクのある操作の2次確認をスキップします。スクリプトを使用してTiUPを呼び出す場合を除き、このオプションの使用は推奨されません。 -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- すべてのリスクのある操作の2次確認をスキップします。スクリプトを使用してTiUPを呼び出す場合を除き、このオプションの使用は推奨されません。 +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### -v, --version {#-v---version} -- TiUP クラスタの現在のバージョンを出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- TiUP クラスタの現在のバージョンを出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### -h, --help {#-h---help} -- 関連するコマンドのヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- 関連するコマンドのヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## コマンドリスト {#command-list} -- [import](/tiup/tiup-component-cluster-import.md) : Ansibleによってデプロイされたクラスターをインポートします -- [template](/tiup/tiup-component-cluster-template.md) : トポロジテンプレートを出力する -- [check](/tiup/tiup-component-cluster-check.md) : デプロイメントの前後にクラスターをチェックします -- [deploy](/tiup/tiup-component-cluster-deploy.md) : 指定されたトポロジに基づいてクラスターを展開します -- [list](/tiup/tiup-component-cluster-list.md) : デプロイされたクラスタのリストを照会する -- [display](/tiup/tiup-component-cluster-display.md) : 指定されたクラスターのステータスを表示します -- [start](/tiup/tiup-component-cluster-start.md) : 指定されたクラスターを起動します -- [stop](/tiup/tiup-component-cluster-stop.md) : 指定されたクラスターを停止します -- [restart](/tiup/tiup-component-cluster-restart.md) : 指定されたクラスターを再起動します -- [scale-in](/tiup/tiup-component-cluster-scale-in.md) : 指定されたクラスター内でスケールする -- [scale-out](/tiup/tiup-component-cluster-scale-out.md) : 指定されたクラスターをスケールアウトする -- [upgrade](/tiup/tiup-component-cluster-upgrade.md) : 指定されたクラスターをアップグレードします -- [prune](/tiup/tiup-component-cluster-prune.md) : 指定されたクラスターの Tombstone ステータスのインスタンスをクリーンアップします -- [edit-config](/tiup/tiup-component-cluster-edit-config.md) : 指定されたクラスターの構成を変更します -- [reload](/tiup/tiup-component-cluster-reload.md) : 指定されたクラスタの構成を再読み込みします -- [patch](/tiup/tiup-component-cluster-patch.md) : デプロイされたクラスター内のサービスを置き換えます -- [rename](/tiup/tiup-component-cluster-rename.md) : クラスターの名前を変更する -- [clean](/tiup/tiup-component-cluster-clean.md) : 指定されたクラスターからデータを削除します -- [destroy](/tiup/tiup-component-cluster-destroy.md) : 指定されたクラスターを破棄する -- [audit](/tiup/tiup-component-cluster-audit.md) : 指定されたクラスタの操作監査ログを照会します -- [replay](/tiup/tiup-component-cluster-replay.md) : 指定されたコマンドを再試行します -- [enable](/tiup/tiup-component-cluster-enable.md) : マシンの再起動後にクラスタ サービスの自動有効化を有効にします -- [disable](/tiup/tiup-component-cluster-disable.md) : マシンの再起動後にクラスタ サービスの自動有効化を無効にします -- [meta backup](/tiup/tiup-component-cluster-meta-backup.md) : 指定されたクラスタの運用と保守に必要なTiUPメタファイルをバックアップします -- [meta restore](/tiup/tiup-component-cluster-meta-restore.md) : 指定されたクラスターのTiUPメタファイルを復元します -- [help](/tiup/tiup-component-cluster-help.md) : ヘルプ情報を出力 +- [import](/tiup/tiup-component-cluster-import.md) : Ansibleによってデプロイされたクラスターをインポートします +- [template](/tiup/tiup-component-cluster-template.md) : トポロジテンプレートを出力する +- [check](/tiup/tiup-component-cluster-check.md) : デプロイメントの前後にクラスターをチェックします +- [deploy](/tiup/tiup-component-cluster-deploy.md) : 指定されたトポロジに基づいてクラスターを展開します +- [list](/tiup/tiup-component-cluster-list.md) : デプロイされたクラスタのリストを照会する +- [display](/tiup/tiup-component-cluster-display.md) : 指定されたクラスターのステータスを表示します +- [start](/tiup/tiup-component-cluster-start.md) : 指定されたクラスターを起動します +- [stop](/tiup/tiup-component-cluster-stop.md) : 指定されたクラスターを停止します +- [restart](/tiup/tiup-component-cluster-restart.md) : 指定されたクラスターを再起動します +- [scale-in](/tiup/tiup-component-cluster-scale-in.md) : 指定されたクラスター内でスケールする +- [scale-out](/tiup/tiup-component-cluster-scale-out.md) : 指定されたクラスターをスケールアウトする +- [upgrade](/tiup/tiup-component-cluster-upgrade.md) : 指定されたクラスターをアップグレードします +- [prune](/tiup/tiup-component-cluster-prune.md) : 指定されたクラスターの Tombstone ステータスのインスタンスをクリーンアップします +- [edit-config](/tiup/tiup-component-cluster-edit-config.md) : 指定されたクラスターの構成を変更します +- [reload](/tiup/tiup-component-cluster-reload.md) : 指定されたクラスタの構成を再読み込みします +- [patch](/tiup/tiup-component-cluster-patch.md) : デプロイされたクラスター内のサービスを置き換えます +- [rename](/tiup/tiup-component-cluster-rename.md) : クラスターの名前を変更する +- [clean](/tiup/tiup-component-cluster-clean.md) : 指定されたクラスターからデータを削除します +- [destroy](/tiup/tiup-component-cluster-destroy.md) : 指定されたクラスターを破棄する +- [audit](/tiup/tiup-component-cluster-audit.md) : 指定されたクラスタの操作監査ログを照会します +- [replay](/tiup/tiup-component-cluster-replay.md) : 指定されたコマンドを再試行します +- [enable](/tiup/tiup-component-cluster-enable.md) : マシンの再起動後にクラスタ サービスの自動有効化を有効にします +- [disable](/tiup/tiup-component-cluster-disable.md) : マシンの再起動後にクラスタ サービスの自動有効化を無効にします +- [meta backup](/tiup/tiup-component-cluster-meta-backup.md) : 指定されたクラスタの運用と保守に必要なTiUPメタファイルをバックアップします +- [meta restore](/tiup/tiup-component-cluster-meta-restore.md) : 指定されたクラスターのTiUPメタファイルを復元します +- [help](/tiup/tiup-component-cluster-help.md) : ヘルプ情報を出力 [<< 前のページに戻る - TiUP参照コンポーネントリスト](/tiup/tiup-reference.md#component-list) diff --git a/tiup/tiup-component-dm-audit.md b/tiup/tiup-component-dm-audit.md index c889588fe9440..36d3c08e271bf 100644 --- a/tiup/tiup-component-dm-audit.md +++ b/tiup/tiup-component-dm-audit.md @@ -13,23 +13,23 @@ summary: tiup dm audit`コマンドは、全クラスタで実行されたコマ tiup dm audit [audit-id] [flags] ``` -- `[audit-id]`を記入しない場合、操作記録表は逆時系列で出力されます。最初の列は`audit-id`です。 -- `[audit-id]`を記入すると、指定した`audit-id`の実行ログがチェックされます。 +- `[audit-id]`を記入しない場合、操作記録表は逆時系列で出力されます。最初の列は`audit-id`です。 +- `[audit-id]`を記入すると、指定した`audit-id`の実行ログがチェックされます。 ## オプション {#option} ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト: false ## 出力 {#output} -- `[audit-id]`を指定した場合、対応する実行ログが出力されます。 -- `[audit-id]`を指定しない場合は、次のフィールドを含むテーブルが出力されます。 - - ID: このレコードに対応する`audit-id` - - 時間: レコードに対応するコマンドの実行時間 - - コマンド: レコードに対応するコマンド +- `[audit-id]`を指定した場合、対応する実行ログが出力されます。 +- `[audit-id]`を指定しない場合は、次のフィールドを含むテーブルが出力されます。 + - ID: このレコードに対応する`audit-id` + - 時間: レコードに対応するコマンドの実行時間 + - コマンド: レコードに対応するコマンド [<< 前のページに戻る - TiUP DMコマンドリスト](/tiup/tiup-component-dm.md#command-list) diff --git a/tiup/tiup-component-dm-deploy.md b/tiup/tiup-component-dm-deploy.md index 19d3df77bde75..fd6bf77a4b690 100644 --- a/tiup/tiup-component-dm-deploy.md +++ b/tiup/tiup-component-dm-deploy.md @@ -13,35 +13,35 @@ summary: tiup dm deploy`コマンドは、新しいクラスタをデプロイ tiup dm deploy [flags] ``` -- `` : 新しいクラスターの名前。既存のクラスター名と同じにすることはできません。 -- `` : デプロイする DM クラスターのバージョン番号 (例: `v2.0.0` )。 -- `` : 準備された[トポロジファイル](/tiup/tiup-dm-topology-reference.md) 。 +- `` : 新しいクラスターの名前。既存のクラスター名と同じにすることはできません。 +- `` : デプロイする DM クラスターのバージョン番号 (例: `v2.0.0` )。 +- `` : 準備された[トポロジファイル](/tiup/tiup-dm-topology-reference.md) 。 ## オプション {#options} ### -u, --user {#u-user} -- ターゲットマシンへの接続に使用するユーザー名を指定します。このユーザーは、ターゲットマシン上でシークレットフリーのsudo root権限を持っている必要があります。 -- データ型: `STRING` -- デフォルト: コマンドを実行する現在のユーザー。 +- ターゲットマシンへの接続に使用するユーザー名を指定します。このユーザーは、ターゲットマシン上でシークレットフリーのsudo root権限を持っている必要があります。 +- データ型: `STRING` +- デフォルト: コマンドを実行する現在のユーザー。 ### -i, --identity_file {#i-identity-file} -- ターゲット マシンに接続するために使用するキー ファイルを指定します。 -- データ型: `STRING` -- デフォルト: `~/.ssh/id_rsa` +- ターゲット マシンに接続するために使用するキー ファイルを指定します。 +- データ型: `STRING` +- デフォルト: `~/.ssh/id_rsa` ### -p, --password {#p-password} -- ターゲットマシンへの接続に使用するパスワードを指定します。このオプションと`-i/--identity_file`同時に使用しないでください。 -- データ型: `BOOLEAN` -- デフォルト: false +- ターゲットマシンへの接続に使用するパスワードを指定します。このオプションと`-i/--identity_file`同時に使用しないでください。 +- データ型: `BOOLEAN` +- デフォルト: false ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト: false ## 出力 {#output} diff --git a/tiup/tiup-component-dm-destroy.md b/tiup/tiup-component-dm-destroy.md index d51a157f9e3c5..4bf22909314d4 100644 --- a/tiup/tiup-component-dm-destroy.md +++ b/tiup/tiup-component-dm-destroy.md @@ -7,9 +7,9 @@ summary: tiup dm destroy`コマンドはクラスタを停止し、各サービ アプリケーションがオフラインになった後、クラスターが占有していたマシンを解放して他のアプリケーションで使用できるようにするには、クラスター上のデータとデプロイされたバイナリファイルをクリーンアップする必要があります。クラスターを破棄するには、 `tiup dm destroy`コマンドで以下の操作を実行します。 -- クラスターを停止します。 -- 各サービスについて、ログ ディレクトリ、デプロイメント ディレクトリ、およびデータ ディレクトリを削除します。 -- `tiup-dm`で各サービスのデータディレクトリやデプロイメントディレクトリの親ディレクトリが作成されている場合は、親ディレクトリも削除します。 +- クラスターを停止します。 +- 各サービスについて、ログ ディレクトリ、デプロイメント ディレクトリ、およびデータ ディレクトリを削除します。 +- `tiup-dm`で各サービスのデータディレクトリやデプロイメントディレクトリの親ディレクトリが作成されている場合は、親ディレクトリも削除します。 ## 構文 {#syntax} @@ -23,9 +23,9 @@ tiup dm destroy [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `Boolean` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `Boolean` +- デフォルト: false ## 出力 {#output} diff --git a/tiup/tiup-component-dm-disable.md b/tiup/tiup-component-dm-disable.md index 9c6073ed60eae..846b12252158c 100644 --- a/tiup/tiup-component-dm-disable.md +++ b/tiup/tiup-component-dm-disable.md @@ -19,9 +19,9 @@ tiup dm disable [flags] ### -N, --node {#n-node} -- サービスの自動有効化を無効にするノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスタステータステーブルの最初の列から取得できます。 -- データ型: `STRINGS` -- このオプションがコマンドで指定されていない場合、すべてのノードの自動有効化はデフォルトで無効になります。 +- サービスの自動有効化を無効にするノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスタステータステーブルの最初の列から取得できます。 +- データ型: `STRINGS` +- このオプションがコマンドで指定されていない場合、すべてのノードの自動有効化はデフォルトで無効になります。 > **Note:** > @@ -29,9 +29,9 @@ tiup dm disable [flags] ### -R, --role {#r-role} -- サービスの自動有効化を無効にするロールを指定します。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合、すべてのロールの自動有効化はデフォルトで無効になります。 +- サービスの自動有効化を無効にするロールを指定します。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合、すべてのロールの自動有効化はデフォルトで無効になります。 > **Note:** > diff --git a/tiup/tiup-component-dm-display.md b/tiup/tiup-component-dm-display.md index c525531de175e..416caac5a77f7 100644 --- a/tiup/tiup-component-dm-display.md +++ b/tiup/tiup-component-dm-display.md @@ -19,9 +19,9 @@ tiup dm display [flags] ### -N, --node {#n-node} -- クエリ対象のノードのIDを指定します。複数のノードを指定する場合は、カンマで区切ってください。ノードのIDが不明な場合は、コマンドでこのオプションを省略すると、出力にすべてのノードのIDとステータスが表示されます。 -- データ型: `STRING` -- このオプションは、 `[]` (すべてのノードを意味する) が渡されるとデフォルトで有効になります。 +- クエリ対象のノードのIDを指定します。複数のノードを指定する場合は、カンマで区切ってください。ノードのIDが不明な場合は、コマンドでこのオプションを省略すると、出力にすべてのノードのIDとステータスが表示されます。 +- データ型: `STRING` +- このオプションは、 `[]` (すべてのノードを意味する) が渡されるとデフォルトで有効になります。 > **Note:** > @@ -29,9 +29,9 @@ tiup dm display [flags] ### -R, --role {#r-role} -- クエリするロールを指定します。複数のロールを指定する場合は、カンマで区切ってください。ノードにデプロイされているロールが不明な場合は、コマンドでこのオプションを省略して、すべてのノードのロールとステータスを出力に表示できます。 -- データ型: `STRING` -- このオプションは、 `[]` (すべてのロールを意味する) が渡されるとデフォルトで有効になります。 +- クエリするロールを指定します。複数のロールを指定する場合は、カンマで区切ってください。ノードにデプロイされているロールが不明な場合は、コマンドでこのオプションを省略して、すべてのノードのロールとステータスを出力に表示できます。 +- データ型: `STRING` +- このオプションは、 `[]` (すべてのロールを意味する) が渡されるとデフォルトで有効になります。 > **Note:** > @@ -39,23 +39,23 @@ tiup dm display [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 出力 {#output} -- クラスタ名 -- クラスタバージョン -- SSHクライアントの種類 -- 次のフィールドを含むテーブル: - - `ID` : IP:PORT で構成されるノード ID。 - - `Role` : ノードにデプロイされたサービス ロール (たとえば、TiDB または TiKV)。 - - `Host` : ノードに対応するマシンの IP アドレス。 - - `Ports` : サービスで使用されるポート番号。 - - `OS/Arch` : ノードのオペレーティング システムとマシンアーキテクチャ。 - - `Status` : ノード上のサービスの現在のステータス。 - - `Data Dir` : サービスのデータ ディレクトリ。`-`はデータ ディレクトリが存在しないことを意味します。 - - `Deploy Dir` : サービスのデプロイメント ディレクトリ。 +- クラスタ名 +- クラスタバージョン +- SSHクライアントの種類 +- 次のフィールドを含むテーブル: + - `ID` : IP:PORT で構成されるノード ID。 + - `Role` : ノードにデプロイされたサービス ロール (たとえば、TiDB または TiKV)。 + - `Host` : ノードに対応するマシンの IP アドレス。 + - `Ports` : サービスで使用されるポート番号。 + - `OS/Arch` : ノードのオペレーティング システムとマシンアーキテクチャ。 + - `Status` : ノード上のサービスの現在のステータス。 + - `Data Dir` : サービスのデータ ディレクトリ。`-`はデータ ディレクトリが存在しないことを意味します。 + - `Deploy Dir` : サービスのデプロイメント ディレクトリ。 [<< 前のページに戻る - TiUP DMコマンドリスト](/tiup/tiup-component-dm.md#command-list) diff --git a/tiup/tiup-component-dm-edit-config.md b/tiup/tiup-component-dm-edit-config.md index 28f008d92f347..833f13609e8e3 100644 --- a/tiup/tiup-component-dm-edit-config.md +++ b/tiup/tiup-component-dm-edit-config.md @@ -9,8 +9,8 @@ summary: tiup dm edit-config`コマンドを使用すると、デプロイメン > **Note:** > -> - 設定を変更すると、マシンの追加や削除はできなくなります。マシンの追加方法については[クラスターをスケールアウトする](/tiup/tiup-component-dm-scale-out.md)を参照してください。マシンの削除方法については[クラスターのスケールイン](/tiup/tiup-component-dm-scale-in.md)を参照してください。 -> - `tiup dm edit-config`コマンドを実行すると、コントロールマシン上でのみ設定が変更されます。その後、 `tiup dm reload`コマンドを実行して設定を再読み込みする必要があります。 +> - 設定を変更すると、マシンの追加や削除はできなくなります。マシンの追加方法については[クラスターをスケールアウトする](/tiup/tiup-component-dm-scale-out.md)を参照してください。マシンの削除方法については[クラスターのスケールイン](/tiup/tiup-component-dm-scale-in.md)を参照してください。 +> - `tiup dm edit-config`コマンドを実行すると、コントロールマシン上でのみ設定が変更されます。その後、 `tiup dm reload`コマンドを実行して設定を再読み込みする必要があります。 ## 構文 {#syntax} @@ -24,13 +24,13 @@ tiup dm edit-config [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト: false ## 出力 {#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-component-dm-enable.md b/tiup/tiup-component-dm-enable.md index 6e1be2dfed43b..51dc42d7cd366 100644 --- a/tiup/tiup-component-dm-enable.md +++ b/tiup/tiup-component-dm-enable.md @@ -19,9 +19,9 @@ tiup dm enable [flags] ### -N, --node {#n-node} -- サービスの自動有効化を有効にするノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、すべてのノードの自動有効化がデフォルトで有効になります。 +- サービスの自動有効化を有効にするノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、すべてのノードの自動有効化がデフォルトで有効になります。 > **Note:** > @@ -29,9 +29,9 @@ tiup dm enable [flags] ### -R, --role {#r-role} -- サービスの自動有効化を有効にするロールを指定します。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、すべてのロールの自動有効化がデフォルトで有効になります。 +- サービスの自動有効化を有効にするロールを指定します。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、すべてのロールの自動有効化がデフォルトで有効になります。 > **Note:** > diff --git a/tiup/tiup-component-dm-help.md b/tiup/tiup-component-dm-help.md index fb62ec5277a16..47436fa663171 100644 --- a/tiup/tiup-component-dm-help.md +++ b/tiup/tiup-component-dm-help.md @@ -17,9 +17,9 @@ tiup dm help [command] [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト: false ## 出力 {#output} diff --git a/tiup/tiup-component-dm-import.md b/tiup/tiup-component-dm-import.md index 897ff26c5741e..c130ff1b728f3 100644 --- a/tiup/tiup-component-dm-import.md +++ b/tiup/tiup-component-dm-import.md @@ -15,14 +15,14 @@ DM v1.0では、クラスターは基本的にTiDB Ansibleを使用してデプ > **Note:** > -> - このコマンドは、DM v1.0 クラスターからの DM Portal コンポーネントのインポートをサポートしていません。 -> - クラスターをインポートする前に、まず元のクラスターの実行を停止します。 -> - v2.0 にアップグレードする必要があるデータ移行タスクの場合、これらのタスクで`stop-task`を実行しないでください。 -> - このコマンドは、DM v2.0.0-rc.2 以降のバージョンへのインポートのみをサポートします。 -> - `import`コマンドは、DM v1.0 クラスタを新しい DM v2.0 クラスタにインポートするために使用されます。既存の v2.0 クラスタにデータ移行タスクをインポートする必要がある場合は、 [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`コマンド](/tiup/tiup-component-dm-scale-out.md)を参照してください。 +> - このコマンドは、DM v1.0 クラスターからの DM Portal コンポーネントのインポートをサポートしていません。 +> - クラスターをインポートする前に、まず元のクラスターの実行を停止します。 +> - v2.0 にアップグレードする必要があるデータ移行タスクの場合、これらのタスクで`stop-task`を実行しないでください。 +> - このコマンドは、DM v2.0.0-rc.2 以降のバージョンへのインポートのみをサポートします。 +> - `import`コマンドは、DM v1.0 クラスタを新しい DM v2.0 クラスタにインポートするために使用されます。既存の v2.0 クラスタにデータ移行タスクをインポートする必要がある場合は、 [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`コマンド](/tiup/tiup-component-dm-scale-out.md)を参照してください。 ## 構文 {#syntax} @@ -34,33 +34,33 @@ tiup dm import [flags] ### -v, --cluster-version {#v-cluster-version} -- 再デプロイするバージョン番号を指定します。v2.0.0-rc.2（v2.0.0-rc.2を含む）以降のバージョンを使用する必要があります。 -- データ型: `STRING` -- コマンドを実行するにはこのオプションが**必要**です。 +- 再デプロイするバージョン番号を指定します。v2.0.0-rc.2（v2.0.0-rc.2を含む）以降のバージョンを使用する必要があります。 +- データ型: `STRING` +- コマンドを実行するにはこのオプションが**必要**です。 ### -d, --dir {#d-dir} -- TiDB Ansible のディレクトリを指定します。 -- データ型: `STRING` -- コマンドでこのオプションを指定しない場合は、現在のディレクトリがデフォルトのディレクトリになります。 +- TiDB Ansible のディレクトリを指定します。 +- データ型: `STRING` +- コマンドでこのオプションを指定しない場合は、現在のディレクトリがデフォルトのディレクトリになります。 ### --inventory {#inventory} -- Ansible インベントリ ファイルの名前を指定します。 -- データ型: `STRING` -- このオプションがコマンドで指定されていない場合、デフォルトのファイル名は`"inventory.ini"`になります。 +- Ansible インベントリ ファイルの名前を指定します。 +- データ型: `STRING` +- このオプションがコマンドで指定されていない場合、デフォルトのファイル名は`"inventory.ini"`になります。 ### --rename {#rename} -- インポートされたクラスターの名前を変更します。 -- データ型: `STRING` -- このオプションがコマンドで指定されていない場合、デフォルトのクラスター名はインベントリ ファイルに指定された`cluster_name`になります。 +- インポートされたクラスターの名前を変更します。 +- データ型: `STRING` +- このオプションがコマンドで指定されていない場合、デフォルトのクラスター名はインベントリ ファイルに指定された`cluster_name`になります。 ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 出力 {#outputs} diff --git a/tiup/tiup-component-dm-list.md b/tiup/tiup-component-dm-list.md index 6f88dabf2eaa6..d073abaf6fbe4 100644 --- a/tiup/tiup-component-dm-list.md +++ b/tiup/tiup-component-dm-list.md @@ -21,18 +21,18 @@ tiup dm list [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 出力 {#output} 次のフィールドで構成されるテーブル: -- `Name` : クラスター名。 -- `User` : クラスターをデプロイしたユーザー。 -- `Version` : クラスターのバージョン。 -- `Path` : 制御マシン上のクラスター展開データのパス。 -- `PrivateKey` : クラスターへの秘密鍵のパス。 +- `Name` : クラスター名。 +- `User` : クラスターをデプロイしたユーザー。 +- `Version` : クラスターのバージョン。 +- `Path` : 制御マシン上のクラスター展開データのパス。 +- `PrivateKey` : クラスターへの秘密鍵のパス。 [<< 前のページに戻る - TiUP DMコマンドリスト](/tiup/tiup-component-dm.md#command-list) diff --git a/tiup/tiup-component-dm-patch.md b/tiup/tiup-component-dm-patch.md index a4cfcd876679a..dffdbefa7512f 100644 --- a/tiup/tiup-component-dm-patch.md +++ b/tiup/tiup-component-dm-patch.md @@ -7,11 +7,11 @@ summary: DM クラスターにホットフィックス パッチを適用する クラスターの実行中にサービスのバイナリを動的に置き換える必要がある場合（つまり、置き換え中もクラスターを利用可能な状態に保つ必要がある場合）、 `tiup dm patch`コマンドを使用できます。このコマンドは、以下の処理を実行します。 -- 置換用のバイナリ パッケージをターゲット マシンにアップロードします。 -- API を使用して関連するノードをオフラインにします。 -- 対象サービスを停止します。 -- バイナリ パッケージを解凍し、サービスを置き換えます。 -- 対象サービスを開始します。 +- 置換用のバイナリ パッケージをターゲット マシンにアップロードします。 +- API を使用して関連するノードをオフラインにします。 +- 対象サービスを停止します。 +- バイナリ パッケージを解凍し、サービスを置き換えます。 +- 対象サービスを開始します。 ## 構文 {#syntax} @@ -19,35 +19,35 @@ summary: DM クラスターにホットフィックス パッチを適用する tiup dm patch [flags] ``` -- `` : 操作対象となるクラスタの名前 -- `` : 置換に使用するバイナリパッケージへのパス +- `` : 操作対象となるクラスタの名前 +- `` : 置換に使用するバイナリパッケージへのパス ### 準備 {#preparation} 以下の手順に従って、このコマンドに必要なバイナリ パッケージを事前にパックする必要があります。 -- 置換するコンポーネントの名前`${component}` (dm-master、dm-worker ...)、コンポーネントの`${version}` (v2.0.0、v2.0.1 ...)、およびコンポーネントが実行されるオペレーティング システム`${os}`とプラットフォーム`${arch}`を決定します。 -- コマンド`wget https://tiup-mirrors.pingcap.com/${component}-${version}-${os}-${arch}.tar.gz -O /tmp/${component}-${version}-${os}-${arch}.tar.gz`を使用して現在のコンポーネントパッケージをダウンロードします。 -- `mkdir -p /tmp/package && cd /tmp/package`を実行して、ファイルをパックするための一時ディレクトリを作成します。 -- `tar xf /tmp/${component}-${version}-${os}-${arch}.tar.gz`を実行して元のバイナリ パッケージを解凍します。 -- `find .`を実行して、一時パッケージ ディレクトリ内のファイル構造を表示します。 -- バイナリ ファイルまたは構成ファイルを一時ディレクトリ内の対応する場所にコピーします。 -- `tar czf /tmp/${component}-hotfix-${os}-${arch}.tar.gz *`を実行して、一時ディレクトリにファイルをパックします。 -- 最後に、 `tiup dm patch`コマンドの``の値として`/tmp/${component}-hotfix-${os}-${arch}.tar.gz`を使用できます。 +- 置換するコンポーネントの名前`${component}` (dm-master、dm-worker ...)、コンポーネントの`${version}` (v2.0.0、v2.0.1 ...)、およびコンポーネントが実行されるオペレーティング システム`${os}`とプラットフォーム`${arch}`を決定します。 +- コマンド`wget https://tiup-mirrors.pingcap.com/${component}-${version}-${os}-${arch}.tar.gz -O /tmp/${component}-${version}-${os}-${arch}.tar.gz`を使用して現在のコンポーネントパッケージをダウンロードします。 +- `mkdir -p /tmp/package && cd /tmp/package`を実行して、ファイルをパックするための一時ディレクトリを作成します。 +- `tar xf /tmp/${component}-${version}-${os}-${arch}.tar.gz`を実行して元のバイナリ パッケージを解凍します。 +- `find .`を実行して、一時パッケージ ディレクトリ内のファイル構造を表示します。 +- バイナリ ファイルまたは構成ファイルを一時ディレクトリ内の対応する場所にコピーします。 +- `tar czf /tmp/${component}-hotfix-${os}-${arch}.tar.gz *`を実行して、一時ディレクトリにファイルをパックします。 +- 最後に、 `tiup dm patch`コマンドの``の値として`/tmp/${component}-hotfix-${os}-${arch}.tar.gz`を使用できます。 ## オプション {#options} ### --overwrite {#overwrite} -- 特定のコンポーネント（dm-workerなど）にパッチを適用した後、tiup-dmがそのコンポーネントをスケールアウトすると、tiup-dmはデフォルトで元のコンポーネントバージョンを使用します。将来クラスタがスケールアウトした際にパッチを適用したバージョンを使用するには、コマンドでオプション`--overwrite`を指定する必要があります。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- 特定のコンポーネント（dm-workerなど）にパッチを適用した後、tiup-dmがそのコンポーネントをスケールアウトすると、tiup-dmはデフォルトで元のコンポーネントバージョンを使用します。将来クラスタがスケールアウトした際にパッチを適用したバージョンを使用するには、コマンドでオプション`--overwrite`を指定する必要があります。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### -N, --node {#n-node} -- 置換するノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 `[tiup dm display](/tiup/tiup-component-dm-display.md)`コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 -- データ型: `STRING` -- このオプションを指定しない場合、 TiUP はデフォルトで置換するすべてのノードを選択します。 +- 置換するノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 `[tiup dm display](/tiup/tiup-component-dm-display.md)`コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 +- データ型: `STRING` +- このオプションを指定しない場合、 TiUP はデフォルトで置換するすべてのノードを選択します。 > **Note:** > @@ -55,9 +55,9 @@ tiup dm patch [flags] ### -R, --role {#r-role} -- 置換するロールを指定します。このオプションの値は、ノードのロールをカンマ区切りでリストしたものです。ノードのロールは、 `[tiup dm display](/tiup/tiup-component-dm-display.md)`コマンドで返されるクラスターステータステーブルの2列目から取得できます。 -- データ型: `STRING` -- このオプションを指定しない場合、 TiUP はデフォルトですべてのロールを選択して置き換えます。 +- 置換するロールを指定します。このオプションの値は、ノードのロールをカンマ区切りでリストしたものです。ノードのロールは、 `[tiup dm display](/tiup/tiup-component-dm-display.md)`コマンドで返されるクラスターステータステーブルの2列目から取得できます。 +- データ型: `STRING` +- このオプションを指定しない場合、 TiUP はデフォルトですべてのロールを選択して置き換えます。 > **Note:** > @@ -65,13 +65,13 @@ tiup dm patch [flags] ### --offline {#offline} -- 現在のクラスタがオフラインであることを宣言します。このオプションを指定すると、 TiUP DMはサービスを再起動せずに、クラスタコンポーネントのバイナリファイルのみを置き換えます。 +- 現在のクラスタがオフラインであることを宣言します。このオプションを指定すると、 TiUP DMはサービスを再起動せずに、クラスタコンポーネントのバイナリファイルのみを置き換えます。 ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 例 {#example} @@ -91,16 +91,18 @@ tiup dm patch [flags] 出力： - Release Version: v5.3.0 +``` +Release Version: v5.3.0 - Git Commit Hash: 20626babf21fc381d4364646c40dd84598533d66 - Git Branch: heads/refs/tags/v5.3.0 - UTC Build Time: 2021-11-29 08:29:49 - Go Version: go version go1.16.4 linux/amd64 +Git Commit Hash: 20626babf21fc381d4364646c40dd84598533d66 +Git Branch: heads/refs/tags/v5.3.0 +UTC Build Time: 2021-11-29 08:29:49 +Go Version: go version go1.16.4 linux/amd64 +``` ### パッチパッケージを準備し、DMクラスタに適用する {#prepare-the-patch-package-and-apply-it-to-the-dm-cluster} -1. 現在のバージョンに一致する DM ソフトウェア パッケージを準備します。 +1. 現在のバージョンに一致する DM ソフトウェア パッケージを準備します。 ```shell mkdir -p /tmp/package @@ -108,7 +110,7 @@ tiup dm patch [flags] tar -zxvf /root/.tiup/storage/dm/packages/dm-worker-v5.3.0-linux-amd64.tar.gz -C /tmp/package/ ``` -2. バイナリ ファイルを修正プログラム パッケージに置き換えます。 +2. バイナリ ファイルを修正プログラム パッケージに置き換えます。 ```shell # Decompress the hotfix package and use it to replace the binary file. @@ -121,7 +123,7 @@ tiup dm patch [flags] cd /tmp/package/ && tar -czvf dm-worker-hotfix-linux-amd64.tar.gz dm-worker/ ``` -3. 修正プログラムを適用します。 +3. 修正プログラムを適用します。 クラスターのステータスを照会します。以下は、クラスター`dm-test`を例にしています。 @@ -131,30 +133,34 @@ tiup dm patch [flags] 出力： - Cluster type: dm - Cluster name: dm-test - Cluster version: v5.3.0 - Deploy user: tidb - SSH type: builtin - ID Role Host Ports OS/Arch Status Data Dir Deploy Dir - -- ---- ---- ----- ------- ------ -------- ---------- - 172.16.100.21:9093 alertmanager 172.16.100.21 9093/9094 linux/x86_64 Up /home/tidb/dm/data/alertmanager-9093 /home/tidb/dm/deploy/alertmanager-9093 - 172.16.100.21:8261 dm-master 172.16.100.21 8261/8291 linux/x86_64 Healthy|L /home/tidb/dm/data/dm-master-8261 /home/tidb/dm/deploy/dm-master-8261 - 172.16.100.21:8262 dm-worker 172.16.100.21 8262 linux/x86_64 Free /home/tidb/dm/data/dm-worker-8262 /home/tidb/dm/deploy/dm-worker-8262 - 172.16.100.21:3000 grafana 172.16.100.21 3000 linux/x86_64 Up - /home/tidb/dm/deploy/grafana-3000 - 172.16.100.21:9090 prometheus 172.16.100.21 9090 linux/x86_64 Up /home/tidb/dm/data/prometheus-9090 /home/tidb/dm/deploy/prometheus-9090 - Total nodes: 5 + ``` + Cluster type: dm + Cluster name: dm-test + Cluster version: v5.3.0 + Deploy user: tidb + SSH type: builtin + ID Role Host Ports OS/Arch Status Data Dir Deploy Dir + -- ---- ---- ----- ------- ------ -------- ---------- + 172.16.100.21:9093 alertmanager 172.16.100.21 9093/9094 linux/x86_64 Up /home/tidb/dm/data/alertmanager-9093 /home/tidb/dm/deploy/alertmanager-9093 + 172.16.100.21:8261 dm-master 172.16.100.21 8261/8291 linux/x86_64 Healthy|L /home/tidb/dm/data/dm-master-8261 /home/tidb/dm/deploy/dm-master-8261 + 172.16.100.21:8262 dm-worker 172.16.100.21 8262 linux/x86_64 Free /home/tidb/dm/data/dm-worker-8262 /home/tidb/dm/deploy/dm-worker-8262 + 172.16.100.21:3000 grafana 172.16.100.21 3000 linux/x86_64 Up - /home/tidb/dm/deploy/grafana-3000 + 172.16.100.21:9090 prometheus 172.16.100.21 9090 linux/x86_64 Up /home/tidb/dm/data/prometheus-9090 /home/tidb/dm/deploy/prometheus-9090 + Total nodes: 5 + ``` 指定されたノードまたは指定されたロールにホットフィックスを適用します。`-N`と`-R`の両方が指定されている場合は、共通部分が採用されます。 - # Apply hotfix to a specified node. - tiup dm patch dm-test dm-master-hotfix-linux-amd64.tar.gz -N 172.16.100.21:8261 - tiup dm patch dm-test dm-worker-hotfix-linux-amd64.tar.gz -N 172.16.100.21:8262 - # Apply hotfix to a specified role. - tiup dm patch dm-test dm-master-hotfix-linux-amd64.tar.gz -R dm-master - tiup dm patch dm-test dm-worker-hotfix-linux-amd64.tar.gz -R dm-worker + ``` + # Apply hotfix to a specified node. + tiup dm patch dm-test dm-master-hotfix-linux-amd64.tar.gz -N 172.16.100.21:8261 + tiup dm patch dm-test dm-worker-hotfix-linux-amd64.tar.gz -N 172.16.100.21:8262 + # Apply hotfix to a specified role. + tiup dm patch dm-test dm-master-hotfix-linux-amd64.tar.gz -R dm-master + tiup dm patch dm-test dm-worker-hotfix-linux-amd64.tar.gz -R dm-worker + ``` -4. 修正プログラムの適用結果を照会します。 +4. 修正プログラムの適用結果を照会します。 ```shell /home/tidb/dm/deploy/dm-master-8261/bin/dm-master/dm-master -V @@ -162,11 +168,13 @@ tiup dm patch [flags] 出力： - Release Version: v5.3.0-20211230 - Git Commit Hash: ca7070c45013c24d34bd9c1e936071253451d707 - Git Branch: heads/refs/tags/v5.3.0-20211230 - UTC Build Time: 2022-01-05 14:19:02 - Go Version: go version go1.16.4 linux/amd64 + ``` + Release Version: v5.3.0-20211230 + Git Commit Hash: ca7070c45013c24d34bd9c1e936071253451d707 + Git Branch: heads/refs/tags/v5.3.0-20211230 + UTC Build Time: 2022-01-05 14:19:02 + Go Version: go version go1.16.4 linux/amd64 + ``` クラスター情報はそれに応じて変更されます。 @@ -176,19 +184,21 @@ tiup dm patch [flags] 出力： - Starting component `dm`: /root/.tiup/components/dm/v1.8.1/tiup-dm display dm-test - Cluster type: dm - Cluster name: dm-test - Cluster version: v5.3.0 - Deploy user: tidb - SSH type: builtin - ID Role Host Ports OS/Arch Status Data Dir Deploy Dir - -- ---- ---- ----- ------- ------ -------- ---------- - 172.16.100.21:9093 alertmanager 172.16.100.21 9093/9094 linux/x86_64 Up /home/tidb/dm/data/alertmanager-9093 /home/tidb/dm/deploy/alertmanager-9093 - 172.16.100.21:8261 dm-master (patched) 172.16.100.21 8261/8291 linux/x86_64 Healthy|L /home/tidb/dm/data/dm-master-8261 /home/tidb/dm/deploy/dm-master-8261 - 172.16.100.21:8262 dm-worker (patched) 172.16.100.21 8262 linux/x86_64 Free /home/tidb/dm/data/dm-worker-8262 /home/tidb/dm/deploy/dm-worker-8262 - 172.16.100.21:3000 grafana 172.16.100.21 3000 linux/x86_64 Up - /home/tidb/dm/deploy/grafana-3000 - 172.16.100.21:9090 prometheus 172.16.100.21 9090 linux/x86_64 Up /home/tidb/dm/data/prometheus-9090 /home/tidb/dm/deploy/prometheus-9090 - Total nodes: 5 + ``` + Starting component `dm`: /root/.tiup/components/dm/v1.8.1/tiup-dm display dm-test + Cluster type: dm + Cluster name: dm-test + Cluster version: v5.3.0 + Deploy user: tidb + SSH type: builtin + ID Role Host Ports OS/Arch Status Data Dir Deploy Dir + -- ---- ---- ----- ------- ------ -------- ---------- + 172.16.100.21:9093 alertmanager 172.16.100.21 9093/9094 linux/x86_64 Up /home/tidb/dm/data/alertmanager-9093 /home/tidb/dm/deploy/alertmanager-9093 + 172.16.100.21:8261 dm-master (patched) 172.16.100.21 8261/8291 linux/x86_64 Healthy|L /home/tidb/dm/data/dm-master-8261 /home/tidb/dm/deploy/dm-master-8261 + 172.16.100.21:8262 dm-worker (patched) 172.16.100.21 8262 linux/x86_64 Free /home/tidb/dm/data/dm-worker-8262 /home/tidb/dm/deploy/dm-worker-8262 + 172.16.100.21:3000 grafana 172.16.100.21 3000 linux/x86_64 Up - /home/tidb/dm/deploy/grafana-3000 + 172.16.100.21:9090 prometheus 172.16.100.21 9090 linux/x86_64 Up /home/tidb/dm/data/prometheus-9090 /home/tidb/dm/deploy/prometheus-9090 + Total nodes: 5 + ``` [<< 前のページに戻る - TiUP DMコマンドリスト](/tiup/tiup-component-dm.md#command-list) diff --git a/tiup/tiup-component-dm-prune.md b/tiup/tiup-component-dm-prune.md index 1b63deb5a2d0f..65862f8d03e9c 100644 --- a/tiup/tiup-component-dm-prune.md +++ b/tiup/tiup-component-dm-prune.md @@ -17,9 +17,9 @@ tiup dm prune [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト: false ## 出力 {#output} diff --git a/tiup/tiup-component-dm-reload.md b/tiup/tiup-component-dm-reload.md index ba1a2756ef5ae..b2049a55e20a7 100644 --- a/tiup/tiup-component-dm-reload.md +++ b/tiup/tiup-component-dm-reload.md @@ -19,43 +19,43 @@ tiup dm reload [flags] ### -N, --node {#n-node} -- 再起動するノードを指定します。指定しない場合は、すべてのノードが再起動されます。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 -- データ型: `STRINGS` -- このオプションがコマンドで指定されていない場合は、デフォルトですべてのノードが選択されます。 +- 再起動するノードを指定します。指定しない場合は、すべてのノードが再起動されます。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 +- データ型: `STRINGS` +- このオプションがコマンドで指定されていない場合は、デフォルトですべてのノードが選択されます。 > **Note:** > -> - `-R, --role`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 -> - オプション`--skip-restart`を指定した場合、オプション`-N, --node`は無効になります。 +> - `-R, --role`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 +> - オプション`--skip-restart`を指定した場合、オプション`-N, --node`は無効になります。 ### -R, --role {#r-role} -- 再起動するロールを指定します。指定しない場合は、すべてのロールが再起動されます。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、すべてのロールがデフォルトで選択されます。 +- 再起動するロールを指定します。指定しない場合は、すべてのロールが再起動されます。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、すべてのロールがデフォルトで選択されます。 > **Note:** > -> - `-N, --node`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 -> - オプション`--skip-restart`を指定した場合、オプション`-R, --role`は無効になります。 +> - `-N, --node`オプションを同時に指定した場合は、 `-N, --node`と`-R, --role`両方の指定に一致するサービス ノードのみが再起動されます。 +> - オプション`--skip-restart`を指定した場合、オプション`-R, --role`は無効になります。 ### --skip-restart {#skip-restart} `tiup dm reload`コマンドは 2 つの操作を実行します。 -- すべてのノード構成を更新します -- 指定されたノードを再起動します +- すべてのノード構成を更新します +- 指定されたノードを再起動します `--skip-restart`オプションを指定すると、ノードを再起動せずに構成のみが更新されるため、更新された構成は適用されず、対応するサービスの次回の再起動まで有効になりません。 -- データ型: `BOOLEAN` -- デフォルト: false +- データ型: `BOOLEAN` +- デフォルト: false ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト: false ## 出力 {#output} diff --git a/tiup/tiup-component-dm-replay.md b/tiup/tiup-component-dm-replay.md index e805b5e1004f4..b55cac17f992c 100644 --- a/tiup/tiup-component-dm-replay.md +++ b/tiup/tiup-component-dm-replay.md @@ -13,7 +13,7 @@ summary: tiup dm replay` コマンドを使用すると、失敗したクラス tiup dm replay [flags] ``` -- `` : 再試行するコマンドの`audit-id` 。[`tiup dm audit`](/tiup/tiup-component-dm-audit.md)を使用すると、履歴コマンドとその`audit-id`を表示できます。 +- `` : 再試行するコマンドの`audit-id` 。[`tiup dm audit`](/tiup/tiup-component-dm-audit.md)を使用すると、履歴コマンドとその`audit-id`を表示できます。 ## オプション {#option} diff --git a/tiup/tiup-component-dm-restart.md b/tiup/tiup-component-dm-restart.md index 51d957ad29fa1..2b1fc8f4e81cc 100644 --- a/tiup/tiup-component-dm-restart.md +++ b/tiup/tiup-component-dm-restart.md @@ -23,9 +23,9 @@ tiup dm restart [flags] ### -N, --node {#n-node} -- 再起動するノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 `[tiup dm display](/tiup/tiup-component-dm-display.md)`コマンドで返されるクラスタステータステーブルの最初の列から取得できます。 -- データ型: `STRING` -- このオプションを指定しない場合、 TiUP はデフォルトですべてのノードを再起動します。 +- 再起動するノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 `[tiup dm display](/tiup/tiup-component-dm-display.md)`コマンドで返されるクラスタステータステーブルの最初の列から取得できます。 +- データ型: `STRING` +- このオプションを指定しない場合、 TiUP はデフォルトですべてのノードを再起動します。 > **Note:** > @@ -33,9 +33,9 @@ tiup dm restart [flags] ### -R, --role {#r-role} -- 再起動するノードの役割を指定します。このオプションの値は、ノードの役割をカンマ区切りでリストしたものです。ノードの役割は、 `[tiup dm display](/tiup/tiup-component-dm-display.md)`コマンドで返されるクラスターステータステーブルの2列目から取得できます。 -- データ型: `STRING` -- このオプションを指定しない場合、 TiUP はデフォルトですべてのロールのノードを再起動します。 +- 再起動するノードの役割を指定します。このオプションの値は、ノードの役割をカンマ区切りでリストしたものです。ノードの役割は、 `[tiup dm display](/tiup/tiup-component-dm-display.md)`コマンドで返されるクラスターステータステーブルの2列目から取得できます。 +- データ型: `STRING` +- このオプションを指定しない場合、 TiUP はデフォルトですべてのロールのノードを再起動します。 > **Note:** > @@ -43,9 +43,9 @@ tiup dm restart [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 出力 {#outputs} diff --git a/tiup/tiup-component-dm-scale-in.md b/tiup/tiup-component-dm-scale-in.md index 4fc2b55000fcd..f93af95abc327 100644 --- a/tiup/tiup-component-dm-scale-in.md +++ b/tiup/tiup-component-dm-scale-in.md @@ -19,21 +19,21 @@ tiup dm scale-in [flags] ### -N, --node {#n-node} -- スケールインするノードを指定します。複数のノードをスケールインする必要がある場合は、カンマで区切ります。 -- データ型: `STRINGS` -- デフォルト: no。このオプションは必須であり、値は null であってはなりません。 +- スケールインするノードを指定します。複数のノードをスケールインする必要がある場合は、カンマで区切ります。 +- データ型: `STRINGS` +- デフォルト: no。このオプションは必須であり、値は null であってはなりません。 ### --force {#force} -- 場合によっては、クラスタ内の一部のスケールインノードがダウンし、SSH経由でノードに接続して操作できなくなることがあります。このような場合は、 `--force`オプションを使用してこれらのノードをクラスタから削除できます。 -- データ型: `BOOLEAN` -- デフォルト：false。このオプションがコマンドで指定されていない場合、指定されたノードは強制的に削除されません。 +- 場合によっては、クラスタ内の一部のスケールインノードがダウンし、SSH経由でノードに接続して操作できなくなることがあります。このような場合は、 `--force`オプションを使用してこれらのノードをクラスタから削除できます。 +- データ型: `BOOLEAN` +- デフォルト：false。このオプションがコマンドで指定されていない場合、指定されたノードは強制的に削除されません。 ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト: false ## 出力 {#output} diff --git a/tiup/tiup-component-dm-scale-out.md b/tiup/tiup-component-dm-scale-out.md index 8c69f1982d88e..4b8696c86a667 100644 --- a/tiup/tiup-component-dm-scale-out.md +++ b/tiup/tiup-component-dm-scale-out.md @@ -21,27 +21,27 @@ tiup dm scale-out [flags] ### -u, --user {#u-user} -- ターゲットマシンへの接続に使用するユーザー名を指定します。このユーザーは、ターゲットマシン上でシークレットフリーのsudo root権限を持っている必要があります。 -- データ型: `STRING` -- デフォルト: コマンドを実行する現在のユーザー。 +- ターゲットマシンへの接続に使用するユーザー名を指定します。このユーザーは、ターゲットマシン上でシークレットフリーのsudo root権限を持っている必要があります。 +- データ型: `STRING` +- デフォルト: コマンドを実行する現在のユーザー。 ### -i, --identity_file {#i-identity-file} -- ターゲット マシンに接続するために使用するキー ファイルを指定します。 -- データ型: `STRING` -- コマンドでこのオプションを指定しない場合は、デフォルトで`~/.ssh/id_rsa`ファイルを使用してターゲット マシンに接続します。 +- ターゲット マシンに接続するために使用するキー ファイルを指定します。 +- データ型: `STRING` +- コマンドでこのオプションを指定しない場合は、デフォルトで`~/.ssh/id_rsa`ファイルを使用してターゲット マシンに接続します。 ### -p, --password {#p-password} -- ターゲットマシンへの接続に使用するパスワードを指定します。このオプションと`-i/--identity_file`同時に使用しないでください。 -- データ型: `BOOLEAN` -- デフォルト: false +- ターゲットマシンへの接続に使用するパスワードを指定します。このオプションと`-i/--identity_file`同時に使用しないでください。 +- データ型: `BOOLEAN` +- デフォルト: false ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト: false ## 出力 {#output} diff --git a/tiup/tiup-component-dm-start.md b/tiup/tiup-component-dm-start.md index 0a277a4141a34..022760681c971 100644 --- a/tiup/tiup-component-dm-start.md +++ b/tiup/tiup-component-dm-start.md @@ -19,9 +19,9 @@ tiup dm start [flags] ### -N, --node {#n-node} -- 起動するノードを指定します。指定しない場合は、すべてのノードが起動されます。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、すべてのノードが起動されます。 +- 起動するノードを指定します。指定しない場合は、すべてのノードが起動されます。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、すべてのノードが起動されます。 > **Note:** > @@ -29,9 +29,9 @@ tiup dm start [flags] ### -R, --role {#r-role} -- 起動するロールを指定します。指定しない場合は、すべてのロールが起動されます。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、すべてのロールが開始されます。 +- 起動するロールを指定します。指定しない場合は、すべてのロールが起動されます。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、すべてのロールが開始されます。 > **Note:** > @@ -39,9 +39,9 @@ tiup dm start [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト: false ## 出力 {#output} diff --git a/tiup/tiup-component-dm-stop.md b/tiup/tiup-component-dm-stop.md index f0546eb5f0a6d..57153bc93a935 100644 --- a/tiup/tiup-component-dm-stop.md +++ b/tiup/tiup-component-dm-stop.md @@ -23,9 +23,9 @@ tiup dm stop [flags] ### -N, --node {#n-node} -- 停止するノードを指定します。指定しない場合は、すべてのノードが停止されます。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 -- データ型: `STRINGS` -- このオプションがコマンドで指定されていない場合は、デフォルトですべてのノードが選択されます。 +- 停止するノードを指定します。指定しない場合は、すべてのノードが停止されます。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 +- データ型: `STRINGS` +- このオプションがコマンドで指定されていない場合は、デフォルトですべてのノードが選択されます。 > **Note:** > @@ -33,9 +33,9 @@ tiup dm stop [flags] ### -R, --role {#r-role} -- 停止するロールを指定します。指定しない場合は、すべてのロールが停止されます。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 -- データ型: `STRINGS` -- コマンドでこのオプションを指定しない場合は、すべてのロールがデフォルトで選択されます。 +- 停止するロールを指定します。指定しない場合は、すべてのロールが停止されます。このオプションの値は、ノードロールのコンマ区切りのリストです。ノードのロールは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの2列目から取得できます。 +- データ型: `STRINGS` +- コマンドでこのオプションを指定しない場合は、すべてのロールがデフォルトで選択されます。 > **Note:** > @@ -43,9 +43,9 @@ tiup dm stop [flags] ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- デフォルト: false +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- デフォルト: false ## 出力 {#output} diff --git a/tiup/tiup-component-dm-template.md b/tiup/tiup-component-dm-template.md index 11253332382e8..0f39b761315a3 100644 --- a/tiup/tiup-component-dm-template.md +++ b/tiup/tiup-component-dm-template.md @@ -15,18 +15,18 @@ tiup dm template [flags] このオプションを指定しない場合、出力のデフォルト テンプレートには次のインスタンスが含まれます。 -- 3 つの DM マスター インスタンス -- 3 つの DM ワーカー インスタンス -- 1つのPrometheusインスタンス -- 1 つの Grafana インスタンス -- 1 つの Alertmanager インスタンス +- 3 つの DM マスター インスタンス +- 3 つの DM ワーカー インスタンス +- 1つのPrometheusインスタンス +- 1 つの Grafana インスタンス +- 1 つの Alertmanager インスタンス ## オプション {#options} ### --full {#full} -- 設定可能なパラメータがコメント化された詳細なトポロジテンプレートを出力します。このオプションを有効にするには、コマンドに追加します。 -- このオプションを指定しない場合は、デフォルトで単純なトポロジ テンプレートが出力されます。 +- 設定可能なパラメータがコメント化された詳細なトポロジテンプレートを出力します。このオプションを有効にするには、コマンドに追加します。 +- このオプションを指定しない場合は、デフォルトで単純なトポロジ テンプレートが出力されます。 ### -h, --help {#h-help} diff --git a/tiup/tiup-component-dm-upgrade.md b/tiup/tiup-component-dm-upgrade.md index d6a4dcb24ab92..12944f18bfa42 100644 --- a/tiup/tiup-component-dm-upgrade.md +++ b/tiup/tiup-component-dm-upgrade.md @@ -13,20 +13,20 @@ summary: tiup dm upgrade`コマンドは、指定されたクラスタを特定 tiup dm upgrade [flags] ``` -- ``は操作対象となるクラスターの名前です。クラスター名を忘れた場合は、 [`tiup dm list`](/tiup/tiup-component-dm-list.md)コマンドで確認できます。 -- ``はアップグレード先のバージョン（例： `v8.5.3`です。現在、新しいバージョンへのアップグレードのみが許可されており、古いバージョンへのアップグレードは許可されていません。つまり、ダウングレードは許可されていません。また、ナイトリーバージョンへのアップグレードも許可されていません。 +- ``は操作対象となるクラスターの名前です。クラスター名を忘れた場合は、 [`tiup dm list`](/tiup/tiup-component-dm-list.md)コマンドで確認できます。 +- ``はアップグレード先のバージョン（例： `v8.5.3`です。現在、新しいバージョンへのアップグレードのみが許可されており、古いバージョンへのアップグレードは許可されていません。つまり、ダウングレードは許可されていません。また、ナイトリーバージョンへのアップグレードも許可されていません。 ## オプション {#options} ### --offline {#offline} -- 現在のクラスタがオフラインであることを宣言します。このオプションを指定すると、 TiUP DMはサービスを再起動せずに、クラスタコンポーネントのバイナリファイルのみを置き換えます。 +- 現在のクラスタがオフラインであることを宣言します。このオプションを指定すると、 TiUP DMはサービスを再起動せずに、クラスタコンポーネントのバイナリファイルのみを置き換えます。 ### -h, --help {#h-help} -- ヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- ヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## 出力 {#output} diff --git a/tiup/tiup-component-dm.md b/tiup/tiup-component-dm.md index e673c2265995a..2c839b27f833b 100644 --- a/tiup/tiup-component-dm.md +++ b/tiup/tiup-component-dm.md @@ -19,70 +19,70 @@ tiup dm [command] [flags] ### --ssh {#ssh} -- コマンド実行のためにリモート エンド (TiDB サービスがデプロイされているマシン) に接続する SSH クライアントを指定します。 +- コマンド実行のためにリモート エンド (TiDB サービスがデプロイされているマシン) に接続する SSH クライアントを指定します。 -- データ型: `STRING` +- データ型: `STRING` -- サポート値: +- サポート値: - - `builtin` : tiup-clusterの組み込み easyssh クライアントを SSH クライアントとして使用します。 - - `system` : 現在のオペレーティング システムのデフォルトの SSH クライアントを使用します。 - - `none` : SSHクライアントは使用されません。デプロイメントは現在のマシンのみに適用されます。 + - `builtin` : tiup-clusterの組み込み easyssh クライアントを SSH クライアントとして使用します。 + - `system` : 現在のオペレーティング システムのデフォルトの SSH クライアントを使用します。 + - `none` : SSHクライアントは使用されません。デプロイメントは現在のマシンのみに適用されます。 -- コマンドでこのオプションを指定しない場合は、デフォルト値として`builtin`が使用されます。 +- コマンドでこのオプションを指定しない場合は、デフォルト値として`builtin`が使用されます。 ### --sshタイムアウト {#ssh-timeout} -- SSH 接続のタイムアウトを秒単位で指定します。 -- データ型: `UINT` -- コマンドでこのオプションを指定しない場合、デフォルトのタイムアウトは`5`秒になります。 +- SSH 接続のタイムアウトを秒単位で指定します。 +- データ型: `UINT` +- コマンドでこのオプションを指定しない場合、デフォルトのタイムアウトは`5`秒になります。 ### --wait-timeout {#wait-timeout} -- 操作プロセスの各ステップの最大待機時間（秒単位）を指定します。操作プロセスは、systemctl によるサービスの開始または停止の指定、ポートのオンラインまたはオフラインの待機など、多くのステップで構成されます。各ステップは数秒かかる場合があります。ステップの実行時間が指定されたタイムアウトを超えた場合、そのステップはエラーで終了します。 -- データ型: `UINT` -- コマンドでこのオプションを指定しない場合、各ステップの最大待機時間は`120`秒になります。 +- 操作プロセスの各ステップの最大待機時間（秒単位）を指定します。操作プロセスは、systemctl によるサービスの開始または停止の指定、ポートのオンラインまたはオフラインの待機など、多くのステップで構成されます。各ステップは数秒かかる場合があります。ステップの実行時間が指定されたタイムアウトを超えた場合、そのステップはエラーで終了します。 +- データ型: `UINT` +- コマンドでこのオプションを指定しない場合、各ステップの最大待機時間は`120`秒になります。 ### -y, --yes {#y-yes} -- すべてのリスクのある操作の2次確認をスキップします。スクリプトを使用してTiUPを呼び出す場合を除き、このオプションの使用は推奨されません。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- すべてのリスクのある操作の2次確認をスキップします。スクリプトを使用してTiUPを呼び出す場合を除き、このオプションの使用は推奨されません。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### -v, --version {#v-version} -- TiUP DMの現在のバージョンを印刷します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- TiUP DMの現在のバージョンを印刷します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### -h, --help {#h-help} -- 指定されたコマンドに関するヘルプ情報を出力します。 -- データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- 指定されたコマンドに関するヘルプ情報を出力します。 +- データ型: `BOOLEAN` +- このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ## コマンドリスト {#command-list} -- [import](/tiup/tiup-component-dm-import.md) : DM-Ansible によってデプロイされた DM v1.0 クラスターをインポートします。 -- [template](/tiup/tiup-component-dm-template.md) : トポロジ テンプレートを出力します。 -- [deploy](/tiup/tiup-component-dm-deploy.md) : 指定されたトポロジに基づいてクラスターをデプロイします。 -- [list](/tiup/tiup-component-dm-list.md) : デプロイされたクラスターのリストを照会します。 -- [display](/tiup/tiup-component-dm-display.md) : 指定されたクラスターのステータスを表示します。 -- [start](/tiup/tiup-component-dm-start.md) : 指定されたクラスターを起動します。 -- [stop](/tiup/tiup-component-dm-stop.md) : 指定されたクラスターを停止します。 -- [restart](/tiup/tiup-component-dm-restart.md) : 指定されたクラスターを再起動します。 -- [scale-in](/tiup/tiup-component-dm-scale-in.md) : 指定されたクラスター内でスケールします。 -- [scale-out](/tiup/tiup-component-dm-scale-out.md) : 指定されたクラスターをスケールアウトします。 -- [upgrade](/tiup/tiup-component-dm-upgrade.md) : 指定されたクラスターをアップグレードします。 -- [prune](/tiup/tiup-component-dm-prune.md) : 指定されたクラスターの Tombstone ステータスのインスタンスをクリーンアップします。 -- [edit-config](/tiup/tiup-component-dm-edit-config.md) : 指定されたクラスターの構成を変更します。 -- [reload](/tiup/tiup-component-dm-reload.md) : 指定されたクラスターの構成を再読み込みします。 -- [patch](/tiup/tiup-component-dm-patch.md) : デプロイされたクラスター内の指定されたサービスを置き換えます。 -- [destroy](/tiup/tiup-component-dm-destroy.md) : 指定されたクラスターを破棄します。 -- [audit](/tiup/tiup-component-dm-audit.md) : 指定されたクラスターの操作監査ログを照会します。 -- [replay](/tiup/tiup-component-dm-replay.md) : 指定されたコマンドを再生する -- [enable](/tiup/tiup-component-dm-enable.md) : マシンの再起動後にクラスター サービスを自動的に有効化します。 -- [disable](/tiup/tiup-component-dm-disable.md) : マシンの再起動後にクラスター サービスの自動有効化を無効にします。 -- [help](/tiup/tiup-component-dm-help.md) : ヘルプ情報を出力します。 +- [import](/tiup/tiup-component-dm-import.md) : DM-Ansible によってデプロイされた DM v1.0 クラスターをインポートします。 +- [template](/tiup/tiup-component-dm-template.md) : トポロジ テンプレートを出力します。 +- [deploy](/tiup/tiup-component-dm-deploy.md) : 指定されたトポロジに基づいてクラスターをデプロイします。 +- [list](/tiup/tiup-component-dm-list.md) : デプロイされたクラスターのリストを照会します。 +- [display](/tiup/tiup-component-dm-display.md) : 指定されたクラスターのステータスを表示します。 +- [start](/tiup/tiup-component-dm-start.md) : 指定されたクラスターを起動します。 +- [stop](/tiup/tiup-component-dm-stop.md) : 指定されたクラスターを停止します。 +- [restart](/tiup/tiup-component-dm-restart.md) : 指定されたクラスターを再起動します。 +- [scale-in](/tiup/tiup-component-dm-scale-in.md) : 指定されたクラスター内でスケールします。 +- [scale-out](/tiup/tiup-component-dm-scale-out.md) : 指定されたクラスターをスケールアウトします。 +- [upgrade](/tiup/tiup-component-dm-upgrade.md) : 指定されたクラスターをアップグレードします。 +- [prune](/tiup/tiup-component-dm-prune.md) : 指定されたクラスターの Tombstone ステータスのインスタンスをクリーンアップします。 +- [edit-config](/tiup/tiup-component-dm-edit-config.md) : 指定されたクラスターの構成を変更します。 +- [reload](/tiup/tiup-component-dm-reload.md) : 指定されたクラスターの構成を再読み込みします。 +- [patch](/tiup/tiup-component-dm-patch.md) : デプロイされたクラスター内の指定されたサービスを置き換えます。 +- [destroy](/tiup/tiup-component-dm-destroy.md) : 指定されたクラスターを破棄します。 +- [audit](/tiup/tiup-component-dm-audit.md) : 指定されたクラスターの操作監査ログを照会します。 +- [replay](/tiup/tiup-component-dm-replay.md) : 指定されたコマンドを再生する +- [enable](/tiup/tiup-component-dm-enable.md) : マシンの再起動後にクラスター サービスを自動的に有効化します。 +- [disable](/tiup/tiup-component-dm-disable.md) : マシンの再起動後にクラスター サービスの自動有効化を無効にします。 +- [help](/tiup/tiup-component-dm-help.md) : ヘルプ情報を出力します。 [<< 前のページに戻る - TiUP参照コンポーネントリスト](/tiup/tiup-reference.md#component-list) diff --git a/tiup/tiup-component-management.md b/tiup/tiup-component-management.md index 6de7c261ec2e3..04aa3993b268e 100644 --- a/tiup/tiup-component-management.md +++ b/tiup/tiup-component-management.md @@ -7,15 +7,15 @@ summary: TiUPコマンドを使用してTiUPコンポーネントを管理する 次のTiUPコマンドを使用して、 TiUPエコシステム内のコンポーネントを管理できます。 -- list:コンポーネントリストを照会します。このTiUPコマンドを使用すると、インストールするすべてのオプションコンポーネントと、各コンポーネントのすべてのオプションバージョンを確認できます。 -- install:コンポーネントの特定のバージョンをインストールします。 -- update:コンポーネントを最新バージョンに更新します。 -- uninstall:コンポーネントをアンインストールします。 -- status: 実行中のコンポーネントのステータスを確認します。 -- clean:コンポーネントがデプロイされているインスタンスをクリーンアップします。 -- help: ヘルプ情報を出力します。このコマンドに別のTiUPコマンドを追加すると、追加したコマンドの使用方法が表示されます。 -- link:コンポーネントのバイナリを実行可能ディレクトリ（ `$TIUP_HOME/bin/` ）にリンクします。 -- unlink: `tiup link`コマンドによって生成されたソフト リンクを削除します。 +- list:コンポーネントリストを照会します。このTiUPコマンドを使用すると、インストールするすべてのオプションコンポーネントと、各コンポーネントのすべてのオプションバージョンを確認できます。 +- install:コンポーネントの特定のバージョンをインストールします。 +- update:コンポーネントを最新バージョンに更新します。 +- uninstall:コンポーネントをアンインストールします。 +- status: 実行中のコンポーネントのステータスを確認します。 +- clean:コンポーネントがデプロイされているインスタンスをクリーンアップします。 +- help: ヘルプ情報を出力します。このコマンドに別のTiUPコマンドを追加すると、追加したコマンドの使用方法が表示されます。 +- link:コンポーネントのバイナリを実行可能ディレクトリ（ `$TIUP_HOME/bin/` ）にリンクします。 +- unlink: `tiup link`コマンドによって生成されたソフト リンクを削除します。 このドキュメントでは、一般的なコンポーネント管理操作と対応するTiUPコマンドについて説明します。 @@ -23,12 +23,12 @@ summary: TiUPコマンドを使用してTiUPコンポーネントを管理する `tiup list`コマンドを使用してコンポーネントリストを照会できます。このコマンドの使用方法は以下のとおりです。 -- `tiup list` : インストールできるコンポーネントを確認します。 -- `tiup list ${component}` : 特定のコンポーネントのどのバージョンをインストールできるかを確認します。 +- `tiup list` : インストールできるコンポーネントを確認します。 +- `tiup list ${component}` : 特定のコンポーネントのどのバージョンをインストールできるかを確認します。 上記のコマンドでは次のフラグを使用することもできます。 -- `--installed` : ローカルにインストールされているコンポーネントまたは特定のコンポーネントのどのバージョンかを確認します。 - `--all` : 非表示のコンポーネントも含め、すべてのコンポーネントを表示します - `--verbose` : すべての列を表示します (インストールされているバージョンとサポートされているプラットフォームを含む) +- `--installed` : ローカルにインストールされているコンポーネントまたは特定のコンポーネントのどのバージョンかを確認します。 - `--all` : 非表示のコンポーネントも含め、すべてのコンポーネントを表示します - `--verbose` : すべての列を表示します (インストールされているバージョンとサポートされているプラットフォームを含む) 例 1: 現在インストールされているすべてのコンポーネントを表示する。 @@ -46,8 +46,8 @@ tiup list tikv `tiup install`コマンドを使用してコンポーネントリストを照会できます。このコマンドの使用方法は以下のとおりです。 -- `tiup install ` : 指定されたコンポーネントの最新の安定バージョンをインストールします。 -- `tiup install :[version]` : 指定されたコンポーネントの指定されたバージョンをインストールします。 +- `tiup install ` : 指定されたコンポーネントの最新の安定バージョンをインストールします。 +- `tiup install :[version]` : 指定されたコンポーネントの指定されたバージョンをインストールします。 例 1: TiUPを使用して、TiDB の最新の安定バージョンをインストールします。 @@ -71,10 +71,10 @@ tiup install tikv:v8.5.3 コンポーネントの新しいバージョンが公開された後、 `tiup update`コマンドを使用してこのコンポーネントをアップグレードできます。このコマンドの使用方法は、以下のフラグを除いて、基本的に`tiup install`コマンドと同じです。 -- `--all` : すべてのコンポーネントをアップグレードします。 -- `--nightly` : ナイトリーバージョンにアップグレードします。 -- `--self` : TiUP自体を最新バージョンにアップグレードします。 -- `--force` : 強制的に最新バージョンにアップグレードします。 +- `--all` : すべてのコンポーネントをアップグレードします。 +- `--nightly` : ナイトリーバージョンにアップグレードします。 +- `--self` : TiUP自体を最新バージョンにアップグレードします。 +- `--force` : 強制的に最新バージョンにアップグレードします。 例 1: すべてのコンポーネントを最新バージョンにアップグレードします。 @@ -133,14 +133,14 @@ tiup status このコマンドを実行すると、インスタンスのリストが1行に1つずつ表示されます。リストには以下の列が含まれます。 -- `Name` : インスタンスのタグ名。 -- `Component` : インスタンスのコンポーネント名。 -- `PID` : 動作中のインスタンスのプロセス ID。 -- `Status` : インスタンスのステータス。`RUNNING`はインスタンスが動作中であることを意味します。`TERM`はインスタンスが終了していることを意味します。 -- `Created Time` : インスタンスの開始時刻。 -- `Directory` : インスタンスの作業ディレクトリは`--tag`を使用して指定できます。 -- `Binary` : インスタンスの実行可能プログラムは`--binpath`を使用して指定できます。 -- `Args` : 操作インスタンスの引数。 +- `Name` : インスタンスのタグ名。 +- `Component` : インスタンスのコンポーネント名。 +- `PID` : 動作中のインスタンスのプロセス ID。 +- `Status` : インスタンスのステータス。`RUNNING`はインスタンスが動作中であることを意味します。`TERM`はインスタンスが終了していることを意味します。 +- `Created Time` : インスタンスの開始時刻。 +- `Directory` : インスタンスの作業ディレクトリは`--tag`を使用して指定できます。 +- `Binary` : インスタンスの実行可能プログラムは`--binpath`を使用して指定できます。 +- `Args` : 操作インスタンスの引数。 ### クリーンなコンポーネントインスタンス {#clean-component-instance} @@ -152,7 +152,7 @@ tiup clean [tag] [flags] 次のフラグがサポートされています: -- `--all` : すべてのインスタンス情報をクリーンアップします。 +- `--all` : すべてのインスタンス情報をクリーンアップします。 上記のコマンドでは、 `tag`はクリーンアップするインスタンスタグです。`--all`を使用すると、タグは渡されません。 @@ -180,13 +180,13 @@ tiup uninstall [component][:version] [flags] このコマンドでは次のフラグがサポートされています。 -- `--all` : すべてのコンポーネントまたはバージョンをアンインストールします。 -- `--self` : TiUP自体をアンインストールします。 +- `--all` : すべてのコンポーネントまたはバージョンをアンインストールします。 +- `--self` : TiUP自体をアンインストールします。 `component`はアンインストールするコンポーネントです。`version`はアンインストールするバージョンです。`tiup uninstall`では、 `component`と`version`どちらも無視できます。どちらか一方を無視する場合は、 `--all`フラグを追加する必要があります。 -- バージョンを無視する場合、 `--all`を追加すると、このコンポーネントのすべてのバージョンがアンインストールされます。 -- バージョンとコンポーネントの両方が無視される場合、 `--all`追加すると、すべてのバージョンのすべてのコンポーネントがアンインストールされます。 +- バージョンを無視する場合、 `--all`を追加すると、このコンポーネントのすべてのバージョンがアンインストールされます。 +- バージョンとコンポーネントの両方が無視される場合、 `--all`追加すると、すべてのバージョンのすべてのコンポーネントがアンインストールされます。 例 1: TiDB v8.5.3 をアンインストールします。 diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index ca724f176ecdd..09d06d0094ad1 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -13,42 +13,42 @@ TiDB Data Migration (DM)クラスターをデプロイまたは拡張するに TiUPを使用した DM クラスターのデプロイメントのトポロジ構成ファイルには、次のセクションが含まれる場合があります。 -- [グローバル](#global) : クラスターのグローバル設定。一部の設定項目はクラスターのデフォルト値を使用しますが、インスタンスごとに個別に設定できます。 -- [サーバー構成](#server_configs) : コンポーネントのグローバル設定。各コンポーネントを個別に設定できます。インスタンスに同じキーの設定項目がある場合、そのインスタンスの設定項目が有効になります。 -- [マスターサーバー](#master_servers) : DMマスターインスタンスの構成。この構成では、DMコンポーネントのマスターサービスがデプロイされるマシンを指定します。 -- [ワーカーサーバー](#worker_servers) : DMワーカーインスタンスの設定。この設定では、DMコンポーネントのワーカーサービスがデプロイされるマシンを指定します。 -- [監視サーバー](#monitoring_servers) : Prometheusインスタンスがデプロイされるマシンを指定します。TiUPは複数のPrometheusインスタンスのデプロイをサポートしていますが、最初のインスタンスのみが使用されます。 -- [grafana_servers](#grafana_servers) : Grafanaインスタンスの設定。この設定では、Grafanaインスタンスがデプロイされるマシンを指定します。 -- [Alertmanagerサーバー](#alertmanager_servers) : Alertmanagerインスタンスの設定。この設定では、Alertmanagerインスタンスがデプロイされるマシンを指定します。 +- [グローバル](#global) : クラスターのグローバル設定。一部の設定項目はクラスターのデフォルト値を使用しますが、インスタンスごとに個別に設定できます。 +- [サーバー構成](#server_configs) : コンポーネントのグローバル設定。各コンポーネントを個別に設定できます。インスタンスに同じキーの設定項目がある場合、そのインスタンスの設定項目が有効になります。 +- [マスターサーバー](#master_servers) : DMマスターインスタンスの構成。この構成では、DMコンポーネントのマスターサービスがデプロイされるマシンを指定します。 +- [ワーカーサーバー](#worker_servers) : DMワーカーインスタンスの設定。この設定では、DMコンポーネントのワーカーサービスがデプロイされるマシンを指定します。 +- [監視サーバー](#monitoring_servers) : Prometheusインスタンスがデプロイされるマシンを指定します。TiUPは複数のPrometheusインスタンスのデプロイをサポートしていますが、最初のインスタンスのみが使用されます。 +- [grafana_servers](#grafana_servers) : Grafanaインスタンスの設定。この設定では、Grafanaインスタンスがデプロイされるマシンを指定します。 +- [Alertmanagerサーバー](#alertmanager_servers) : Alertmanagerインスタンスの設定。この設定では、Alertmanagerインスタンスがデプロイされるマシンを指定します。 ### `global` {#global} `global`セクションはクラスターのグローバル構成に対応し、次のフィールドがあります。 -- `user` : デプロイされたクラスタを起動するユーザー。デフォルト値は「tidb」です。``に指定されたユーザーがターゲットマシン上に存在しない場合、 TiUP は自動的にユーザーの作成を試みます。 -- `group` : ユーザーが自動作成された際に所属するユーザーグループ。デフォルト値は``フィールドと同じです。指定されたグループが存在しない場合は、自動的に作成されます。 -- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポート。デフォルト値は「22」です。 -- `deploy_dir` : 各コンポーネントのデプロイメントディレクトリ。デフォルト値は「deploy」です。構築ルールは以下のとおりです。 - - 絶対パス`deploy_dir`インスタンス レベルで構成されている場合、実際のデプロイメント ディレクトリはインスタンスに対して構成されている`deploy_dir`なります。 - - 各インスタンスに対して`deploy_dir`設定しない場合、デフォルト値は相対パス`-`なります。 - - `global.deploy_dir`絶対パスに設定すると、コンポーネントは`/`ディレクトリにデプロイされます。 - - `global.deploy_dir`相対パスに設定すると、コンポーネントは`/home///`ディレクトリにデプロイされます。 -- `data_dir` : データディレクトリ。デフォルト値は「data」です。構築ルールは以下のとおりです。 - - 絶対パス`data_dir`インスタンス レベルで構成されている場合、実際のデータ ディレクトリはインスタンスに構成されている`data_dir`なります。 - - 各インスタンスに対して`data_dir`が設定されていない場合、デフォルト値は``なります。 - - `data_dir`相対パスに設定されている場合、コンポーネントデータは`/`に保存されます。 ``の構築規則については、 `deploy_dir`フィールドの構築規則を参照してください。 -- `log_dir` : データディレクトリ。デフォルト値は「log」です。構築ルールは以下のとおりです。 - - インスタンス レベルで絶対パス`log_dir`が設定されている場合、実際のログ ディレクトリはインスタンスに設定されている`log_dir`なります。 - - 各インスタンスについて、ユーザーが`log_dir`設定しない場合、デフォルト値は``なります。 - - `log_dir`が相対パスの場合、コンポーネントログは`/`に保存されます。 ``の構築ルールについては、 `deploy_dir`フィールドの構築ルールを参照してください。 -- `os` : ターゲットマシンのオペレーティングシステム。このフィールドは、ターゲットマシンにプッシュされるコンポーネントをどのオペレーティングシステムに適応させるかを制御します。デフォルト値は「linux」です。 -- `arch` : ターゲットマシンのCPUアーキテクチャ。このフィールドは、ターゲットマシンにプッシュされるバイナリパッケージをどのプラットフォームに適合させるかを制御します。サポートされている値は「amd64」と「arm64」です。デフォルト値は「amd64」です。 -- `resource_control` : ランタイムリソース制御。このフィールドのすべての設定は、systemd のサービスファイルに書き込まれます。デフォルトでは制限はありません。制御可能なリソースは以下のとおりです。 - - `memory_limit` : 実行時の最大メモリを制限します。例えば、「2G」は最大2GBのメモリが使用できることを意味します。 - - `cpu_quota` : 実行時のCPU使用率の上限を制限します。例: 「200%」 - - `io_read_bandwidth_max` : ディスク読み取りの最大I/O帯域幅を制限します。例： `"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M"` 。 - - `io_write_bandwidth_max` : ディスク書き込みの最大I/O帯域幅を制限します。例： `"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M"` 。 - - `limit_core` : コアダンプのサイズを制御します。 +- `user` : デプロイされたクラスタを起動するユーザー。デフォルト値は「tidb」です。``に指定されたユーザーがターゲットマシン上に存在しない場合、 TiUP は自動的にユーザーの作成を試みます。 +- `group` : ユーザーが自動作成された際に所属するユーザーグループ。デフォルト値は``フィールドと同じです。指定されたグループが存在しない場合は、自動的に作成されます。 +- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポート。デフォルト値は「22」です。 +- `deploy_dir` : 各コンポーネントのデプロイメントディレクトリ。デフォルト値は「deploy」です。構築ルールは以下のとおりです。 + - 絶対パス`deploy_dir`インスタンス レベルで構成されている場合、実際のデプロイメント ディレクトリはインスタンスに対して構成されている`deploy_dir`なります。 + - 各インスタンスに対して`deploy_dir`設定しない場合、デフォルト値は相対パス`-`なります。 + - `global.deploy_dir`絶対パスに設定すると、コンポーネントは`/`ディレクトリにデプロイされます。 + - `global.deploy_dir`相対パスに設定すると、コンポーネントは`/home///`ディレクトリにデプロイされます。 +- `data_dir` : データディレクトリ。デフォルト値は「data」です。構築ルールは以下のとおりです。 + - 絶対パス`data_dir`インスタンス レベルで構成されている場合、実際のデータ ディレクトリはインスタンスに構成されている`data_dir`なります。 + - 各インスタンスに対して`data_dir`が設定されていない場合、デフォルト値は``なります。 + - `data_dir`相対パスに設定されている場合、コンポーネントデータは`/`に保存されます。 ``の構築規則については、 `deploy_dir`フィールドの構築規則を参照してください。 +- `log_dir` : データディレクトリ。デフォルト値は「log」です。構築ルールは以下のとおりです。 + - インスタンス レベルで絶対パス`log_dir`が設定されている場合、実際のログ ディレクトリはインスタンスに設定されている`log_dir`なります。 + - 各インスタンスについて、ユーザーが`log_dir`設定しない場合、デフォルト値は``なります。 + - `log_dir`が相対パスの場合、コンポーネントログは`/`に保存されます。 ``の構築ルールについては、 `deploy_dir`フィールドの構築ルールを参照してください。 +- `os` : ターゲットマシンのオペレーティングシステム。このフィールドは、ターゲットマシンにプッシュされるコンポーネントをどのオペレーティングシステムに適応させるかを制御します。デフォルト値は「linux」です。 +- `arch` : ターゲットマシンのCPUアーキテクチャ。このフィールドは、ターゲットマシンにプッシュされるバイナリパッケージをどのプラットフォームに適合させるかを制御します。サポートされている値は「amd64」と「arm64」です。デフォルト値は「amd64」です。 +- `resource_control` : ランタイムリソース制御。このフィールドのすべての設定は、systemd のサービスファイルに書き込まれます。デフォルトでは制限はありません。制御可能なリソースは以下のとおりです。 + - `memory_limit` : 実行時の最大メモリを制限します。例えば、「2G」は最大2GBのメモリが使用できることを意味します。 + - `cpu_quota` : 実行時のCPU使用率の上限を制限します。例: 「200%」 + - `io_read_bandwidth_max` : ディスク読み取りの最大I/O帯域幅を制限します。例： `"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M"` 。 + - `io_write_bandwidth_max` : ディスク書き込みの最大I/O帯域幅を制限します。例： `"/dev/disk/by-path/pci-0000:00:1f.2-scsi-0:0:0:0:0 100M"` 。 + - `limit_core` : コアダンプのサイズを制御します。 `global`構成例: @@ -65,8 +65,8 @@ global: `server_configs`は、サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。`global`セクションと同様に、 `server_configs`セクションの設定は、インスタンス内の同じキーを持つ設定によって上書きできます。`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`構成の例は次のとおりです。 @@ -85,33 +85,33 @@ server_configs: `master_servers` 、DMコンポーネントのマスターノードがデプロイされるマシンを指定します。また、各マシンのサービス構成を指定することもできます。`master_servers`は配列です。各配列要素には以下のフィールドが含まれます。 -- `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 -- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 -- `name` : DMマスターインスタンスの名前を指定します。名前はインスタンスごとに一意である必要があります。一意でない場合、クラスターをデプロイできません。 -- `port` : DMマスターがサービスを提供するポートを指定します。デフォルト値は「8261」です。 -- `peer_port` : DMマスター間の通信ポートを指定します。デフォルト値は「8291」です。 -- `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"）です。 -- `config` ：このフィールドの設定ルールは、セクション`server_configs`の`master`と同じです。`config`を指定した場合、`config`の設定が`server_configs`セクションの`master`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。 -- `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`os`値です。 -- `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`arch`値になります。 -- `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。 -- `v1_source_path` : v1.0.x からアップグレードする場合、このフィールドに V1 ソースの構成ファイルが配置されているディレクトリを指定できます。 +- `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 +- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 +- `name` : DMマスターインスタンスの名前を指定します。名前はインスタンスごとに一意である必要があります。一意でない場合、クラスターをデプロイできません。 +- `port` : DMマスターがサービスを提供するポートを指定します。デフォルト値は「8261」です。 +- `peer_port` : DMマスター間の通信ポートを指定します。デフォルト値は「8291」です。 +- `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"）です。 +- `config` ：このフィールドの設定ルールは、セクション`server_configs`の`master`と同じです。`config`を指定した場合、`config`の設定が`server_configs`セクションの`master`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。 +- `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`os`値です。 +- `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`arch`値になります。 +- `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。 +- `v1_source_path` : v1.0.x からアップグレードする場合、このフィールドに V1 ソースの構成ファイルが配置されているディレクトリを指定できます。 `master_servers`セクションでは、デプロイメントが完了した後は、次のフィールドを変更することはできません。 -- `host` -- `name` -- `port` -- `peer_port` -- `deploy_dir` -- `data_dir` -- `log_dir` -- `arch` -- `os` -- `v1_source_path` +- `host` +- `name` +- `port` +- `peer_port` +- `deploy_dir` +- `data_dir` +- `log_dir` +- `arch` +- `os` +- `v1_source_path` `master_servers`構成の例は次のとおりです。 @@ -142,29 +142,29 @@ master_servers: `worker_servers` 、DMコンポーネントのマスターノードがデプロイされるマシンを指定します。また、各マシンのサービス構成を指定することもできます。`worker_servers`は配列です。各配列要素には以下のフィールドが含まれます。 -- `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 -- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 -- `name` : DMワーカーインスタンスの名前を指定します。名前はインスタンスごとに一意である必要があります。一意でない場合、クラスターをデプロイできません。 -- `port` : DMワーカーがサービスを提供するポートを指定します。デフォルト値は「8262」です。 -- `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"）です。 -- `config` ：このフィールドの設定ルールは、セクション`server_configs`の`worker`と同じです。`config`を指定した場合、`config`の設定が`server_configs`セクションの`worker`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。 -- `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`os`値です。 -- `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`arch`値になります。 -- `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。 +- `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 +- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 +- `name` : DMワーカーインスタンスの名前を指定します。名前はインスタンスごとに一意である必要があります。一意でない場合、クラスターをデプロイできません。 +- `port` : DMワーカーがサービスを提供するポートを指定します。デフォルト値は「8262」です。 +- `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"）です。 +- `config` ：このフィールドの設定ルールは、セクション`server_configs`の`worker`と同じです。`config`を指定した場合、`config`の設定が`server_configs`セクションの`worker`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。 +- `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`os`値です。 +- `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`arch`値になります。 +- `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。 `worker_servers`セクションでは、デプロイメントが完了した後は、次のフィールドを変更することはできません。 -- `host` -- `name` -- `port` -- `deploy_dir` -- `data_dir` -- `log_dir` -- `arch` -- `os` +- `host` +- `name` +- `port` +- `deploy_dir` +- `data_dir` +- `log_dir` +- `arch` +- `os` `worker_servers`構成の例は次のとおりです。 @@ -186,33 +186,33 @@ worker_servers: `monitoring_servers` 、Prometheus サービスがデプロイされるマシンを指定します。また、マシン上のサービス設定も指定できます。`monitoring_servers`は配列です。各配列要素には以下のフィールドが含まれます。 -- `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 -- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 -- `port` : Prometheusがサービスを提供するポートを指定します。デフォルト値は「9090」です。 -- `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"）です。 -- `storage_retention` : Prometheus監視データの保持期間を指定します。デフォルト値は「15日」です。 -- `rule_dir` : `*.rules.yml`のファイルすべてが保存されているローカルディレクトリを指定します。指定されたディレクトリ内のファイルは、クラスター構成の初期化フェーズでPrometheusルールとしてターゲットマシンに送信されます。 -- `remote_config` : Prometheusデータのリモートへの書き込み、またはリモートからのデータの読み取りをサポートします。このフィールドには2つの設定があります。 - - `remote_write` : Prometheus ドキュメント[``](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write)を参照してください。 - - `remote_read` : Prometheus ドキュメント[``](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_read)を参照してください。 -- `external_alertmanagers` : フィールド`external_alertmanagers`が設定されている場合、Prometheusはクラスター外のAlertmanagerに構成動作を通知します。このフィールドは配列であり、各要素は外部Alertmanagerであり、フィールド`host`とフィールド`web_port`で構成されます。 -- `external_labels` : TiUP v1.17.0 で導入されたこのフィールドは、Prometheus グローバル `external_labels` をキーと値のペアとして設定します。このフィールドを使用して、Prometheus `remote_write`、federation、および alerting を通じて伝播される安定したメタデータを付加します。TiUP は `cluster` および `monitor` ラベルを予約し、自動的に管理するため、このフィールドでこれらを設定してはいけません。`__` で始まるラベル名も予約されています。さらに、すべてのラベル名は Prometheus のラベル命名規則に準拠する必要があります。このフィールドをサポートしていない以前のバージョンの TiUP がトポロジーファイルを読み取ると、TiUP はこのフィールドを無視するのではなく、トポロジーの解析に失敗します。 -- `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`os`値です。 -- `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`arch`値になります。 -- `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。 +- `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 +- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 +- `port` : Prometheusがサービスを提供するポートを指定します。デフォルト値は「9090」です。 +- `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"）です。 +- `storage_retention` : Prometheus監視データの保持期間を指定します。デフォルト値は「15日」です。 +- `rule_dir` : `*.rules.yml`のファイルすべてが保存されているローカルディレクトリを指定します。指定されたディレクトリ内のファイルは、クラスター構成の初期化フェーズでPrometheusルールとしてターゲットマシンに送信されます。 +- `remote_config` : Prometheusデータのリモートへの書き込み、またはリモートからのデータの読み取りをサポートします。このフィールドには2つの設定があります。 + - `remote_write` : Prometheus ドキュメント[``](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write)を参照してください。 + - `remote_read` : Prometheus ドキュメント[``](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_read)を参照してください。 +- `external_alertmanagers` : フィールド`external_alertmanagers`が設定されている場合、Prometheusはクラスター外のAlertmanagerに構成動作を通知します。このフィールドは配列であり、各要素は外部Alertmanagerであり、フィールド`host`とフィールド`web_port`で構成されます。 +- `external_labels` : TiUP v1.17.0 で導入されたこのフィールドは、Prometheus グローバル `external_labels` をキーと値のペアとして設定します。このフィールドを使用して、Prometheus `remote_write`、federation、および alerting を通じて伝播される安定したメタデータを付加します。TiUP は `cluster` および `monitor` ラベルを予約し、自動的に管理するため、このフィールドでこれらを設定してはいけません。`__` で始まるラベル名も予約されています。さらに、すべてのラベル名は Prometheus のラベル命名規則に準拠する必要があります。このフィールドをサポートしていない以前のバージョンの TiUP がトポロジーファイルを読み取ると、TiUP はこのフィールドを無視するのではなく、トポロジーの解析に失敗します。 +- `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`os`値です。 +- `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`arch`値になります。 +- `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。 `monitoring_servers`セクションでは、デプロイメントが完了した後は、次のフィールドを変更することはできません。 -- `host` -- `port` -- `deploy_dir` -- `data_dir` -- `log_dir` -- `arch` -- `os` +- `host` +- `port` +- `deploy_dir` +- `data_dir` +- `log_dir` +- `arch` +- `os` `monitoring_servers`構成の例は次のとおりです。 @@ -244,31 +244,31 @@ monitoring_servers: `grafana_servers` 、Grafana サービスがデプロイされるマシンを指定します。また、マシン上のサービス設定も指定できます。`grafana_servers`は配列です。各配列要素には以下のフィールドが含まれます。 -- `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 -- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 -- `port` : Grafanaがサービスを提供するポートを指定します。デフォルト値は「3000」です。 -- `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 -- `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`os`値です。 -- `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`arch`値になります。 -- `username` : Grafana ログイン画面のユーザー名を指定します。 -- `password` : Grafana の対応するパスワードを指定します。 -- `dashboard_dir` : `dashboard(*.json)`のファイルすべてが保存されているローカルディレクトリを指定します。指定されたディレクトリ内のファイルは、クラスター構成の初期化フェーズ中にGrafanaダッシュボードとしてターゲットマシンに送信されます。 -- `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。 +- `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 +- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 +- `port` : Grafanaがサービスを提供するポートを指定します。デフォルト値は「3000」です。 +- `deploy_dir` : デプロイメントディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、デプロイメントディレクトリは`global`セクションの`deploy_dir`設定に従って生成されます。 +- `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`os`値です。 +- `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`arch`値になります。 +- `username` : Grafana ログイン画面のユーザー名を指定します。 +- `password` : Grafana の対応するパスワードを指定します。 +- `dashboard_dir` : `dashboard(*.json)`のファイルすべてが保存されているローカルディレクトリを指定します。指定されたディレクトリ内のファイルは、クラスター構成の初期化フェーズ中にGrafanaダッシュボードとしてターゲットマシンに送信されます。 +- `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。 > **Note:** > > `dashboard_dir`フィールドが`grafana_servers`設定されている場合、クラスターの名前を変更する`tiup cluster rename`コマンドを実行した後、次の操作を実行する必要があります。 > -> 1. ローカルの`dashboards`ディレクトリで、 `datasource`フィールドの値を新しいクラスター名に更新します ( `datasource`クラスター名に基づいて名前が付けられます)。 -> 2. `tiup cluster reload -R grafana`コマンドを実行します。 +> 1. ローカルの`dashboards`ディレクトリで、 `datasource`フィールドの値を新しいクラスター名に更新します ( `datasource`クラスター名に基づいて名前が付けられます)。 +> 2. `tiup cluster reload -R grafana`コマンドを実行します。 `grafana_servers`では、デプロイメントが完了した後は、次のフィールドを変更できません。 -- `host` -- `port` -- `deploy_dir` -- `arch` -- `os` +- `host` +- `port` +- `deploy_dir` +- `arch` +- `os` `grafana_servers`構成の例は次のとおりです。 @@ -282,29 +282,29 @@ grafana_servers: `alertmanager_servers` 、Alertmanagerサービスがデプロイされるマシンを指定します。また、各マシンのサービス構成を指定することもできます。`alertmanager_servers`は配列です。各配列要素には以下のフィールドが含まれます。 -- `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 -- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 -- `web_port` : AlertmanagerがWebサービスを提供するポートを指定します。デフォルト値は「9093」です。 -- `cluster_port` : Alertmanager間の通信ポートを指定します。デフォルト値は「9094」です。 -- `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"）です。 -- `config_file` : ローカルファイルを指定します。指定されたファイルは、クラスター構成の初期化フェーズ中に、Alertmanager の構成としてターゲットマシンに送信されます。 -- `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`os`値です。 -- `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`arch`値になります。 -- `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。 +- `host` : デプロイ先のマシンを指定します。このフィールド値はIPアドレスで、必須です。 +- `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。このフィールドが指定されていない場合は、セクション`global`の`ssh_port`が使用されます。 +- `web_port` : AlertmanagerがWebサービスを提供するポートを指定します。デフォルト値は「9093」です。 +- `cluster_port` : Alertmanager間の通信ポートを指定します。デフォルト値は「9094」です。 +- `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"）です。 +- `config_file` : ローカルファイルを指定します。指定されたファイルは、クラスター構成の初期化フェーズ中に、Alertmanager の構成としてターゲットマシンに送信されます。 +- `os` : `host`のフィールドで指定されたマシンのオペレーティングシステム。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`os`値です。 +- `arch` : `host`のフィールドで指定されたマシンのアーキテクチャ。このフィールドが指定されていない場合、デフォルト値は`global`セクションで設定された`arch`値になります。 +- `resource_control` : このサービスにおけるリソース制御。このフィールドが指定された場合、このフィールドの設定はセクション`global`の`resource_control`の設定とマージされ（2つのフィールドが重複している場合は、このフィールドの設定が有効になります）、systemdの設定ファイルが生成され、セクション`host`で指定されたマシンに配布されます。このフィールドの設定ルールは、セクション`global`の`resource_control`の設定ルールと同じです。 `alertmanager_servers`では、デプロイメントが完了した後は、次のフィールドを変更できません。 -- `host` -- `web_port` -- `cluster_port` -- `deploy_dir` -- `data_dir` -- `log_dir` -- `arch` -- `os` +- `host` +- `web_port` +- `cluster_port` +- `deploy_dir` +- `data_dir` +- `log_dir` +- `arch` +- `os` `alertmanager_servers`構成の例は次のとおりです。 diff --git a/tiup/tiup-documentation-guide.md b/tiup/tiup-documentation-guide.md index c152cf384ca7f..dd0d948a530da 100644 --- a/tiup/tiup-documentation-guide.md +++ b/tiup/tiup-documentation-guide.md @@ -7,14 +7,14 @@ summary: リンクと紹介を使用してTiUPドキュメントを案内しま ## ユーザーガイド {#user-guide} -- [TiUPの概要](/tiup/tiup-overview.md) : TiUPのインストール方法や使用方法、関連する用語など、 TiUPの全体的な概要を説明します。 -- [TiUPの用語と概念](/tiup/tiup-terminology-and-concepts.md) : TiUPを使用する際に遭遇する可能性のある用語を説明し、 TiUPの主要な概念を理解するのに役立ちます。 -- [TiUPコンポーネント管理](/tiup/tiup-component-management.md) : すべてのTiUPコマンドの詳細と、 TiUPを使用してコンポーネントをダウンロード、更新、削除する方法を紹介します。 -- [TiUPFAQ](/tiup/tiup-faq.md) : TiUPのサードパーティ コンポーネントに関する FAQ など、 TiUPを使用する際によくある問題を紹介します。 -- [TiUPトラブルシューティングガイド](/tiup/tiup-troubleshooting-guide.md) : TiUPの使用中に問題が発生した場合のトラブルシューティング方法と解決策を紹介します -- [TiUPリファレンスガイド](/tiup/tiup-reference.md) : コマンド、コンポーネント、ミラーなどの詳細なリファレンスを紹介します。 +- [TiUPの概要](/tiup/tiup-overview.md) : TiUPのインストール方法や使用方法、関連する用語など、 TiUPの全体的な概要を説明します。 +- [TiUPの用語と概念](/tiup/tiup-terminology-and-concepts.md) : TiUPを使用する際に遭遇する可能性のある用語を説明し、 TiUPの主要な概念を理解するのに役立ちます。 +- [TiUPコンポーネント管理](/tiup/tiup-component-management.md) : すべてのTiUPコマンドの詳細と、 TiUPを使用してコンポーネントをダウンロード、更新、削除する方法を紹介します。 +- [TiUPFAQ](/tiup/tiup-faq.md) : TiUPのサードパーティ コンポーネントに関する FAQ など、 TiUPを使用する際によくある問題を紹介します。 +- [TiUPトラブルシューティングガイド](/tiup/tiup-troubleshooting-guide.md) : TiUPの使用中に問題が発生した場合のトラブルシューティング方法と解決策を紹介します +- [TiUPリファレンスガイド](/tiup/tiup-reference.md) : コマンド、コンポーネント、ミラーなどの詳細なリファレンスを紹介します。 ## TiUPリソース {#tiup-resources} -- [TiUPリリースノート](https://github.com/pingcap/tiup/releases) -- [TiUPの問題](https://github.com/pingcap/tiup/issues) : TiUP GitHub の問題を一覧表示します +- [TiUPリリースノート](https://github.com/pingcap/tiup/releases) +- [TiUPの問題](https://github.com/pingcap/tiup/issues) : TiUP GitHub の問題を一覧表示します diff --git a/tiup/tiup-faq.md b/tiup/tiup-faq.md index a1b5e5e96f66b..5b1a8b1884b7f 100644 --- a/tiup/tiup-faq.md +++ b/tiup/tiup-faq.md @@ -13,8 +13,8 @@ TiUPは、環境変数`TIUP_MIRRORS`を介してミラーソースを指定す 非公式ミラーを使用した後、公式ミラーに戻して使用する場合は、以下のいずれかの措置を講じてください。 -- `TIUP_MIRRORS`変数を公式ミラー アドレス`https://tiup-mirrors.pingcap.com`に設定します。 -- `TIUP_MIRRORS`変数が設定されていないことを確認してから、 `tiup mirror set https://tiup-mirrors.pingcap.com`コマンドを実行します。 +- `TIUP_MIRRORS`変数を公式ミラー アドレス`https://tiup-mirrors.pingcap.com`に設定します。 +- `TIUP_MIRRORS`変数が設定されていないことを確認してから、 `tiup mirror set https://tiup-mirrors.pingcap.com`コマンドを実行します。 ## 独自のコンポーネントをTiUPミラーに組み込むにはどうすればよいでしょうか? {#how-do-i-put-my-own-component-into-the-tiup-mirrors} @@ -28,9 +28,9 @@ TiUP Playgroundコンポーネントは、主にLinuxまたはmacOSオペレー トポロジファイルの作成方法については、 [これらのテンプレート](https://github.com/pingcap/tiup/tree/master/embed/examples/cluster)を参照してください。テンプレートには以下が含まれます。 -- マルチDC展開トポロジ -- 最小限の展開トポロジ -- 完全なトポロジファイル +- マルチDC展開トポロジ +- 最小限の展開トポロジ +- 完全なトポロジファイル テンプレートとニーズに基づいてトポロジ ファイルを編集できます。 diff --git a/tiup/tiup-mirror-reference.md b/tiup/tiup-mirror-reference.md index 2139dbd4170bd..5440a557acf77 100644 --- a/tiup/tiup-mirror-reference.md +++ b/tiup/tiup-mirror-reference.md @@ -7,15 +7,15 @@ summary: TiUPミラーの一般情報を学びます。 TiUPミラーは、コンポーネントとそのメタデータを保存するTiUPのコンポーネントウェアハウスです。TiUPミラーには、次の2つの形式があります。 -- ローカル ディスク上のディレクトリ: このドキュメントではローカル ミラーと呼ばれるローカルTiUPクライアントを提供します。 -- リモート ディスク ディレクトリに基づいて開始された HTTP ミラー: このドキュメントではリモート ミラーと呼ばれるリモートTiUPクライアントにサービスを提供します。 +- ローカル ディスク上のディレクトリ: このドキュメントではローカル ミラーと呼ばれるローカルTiUPクライアントを提供します。 +- リモート ディスク ディレクトリに基づいて開始された HTTP ミラー: このドキュメントではリモート ミラーと呼ばれるリモートTiUPクライアントにサービスを提供します。 ## ミラーの作成と更新 {#create-and-update-mirror} 次の 2 つの方法のいずれかを使用してTiUPミラーを作成できます。 -- ミラーを最初から作成するには、 `tiup mirror init`を実行します。 -- 既存のミラーからクローンを作成するには、 `tiup mirror clone`を実行します。 +- ミラーを最初から作成するには、 `tiup mirror init`を実行します。 +- 既存のミラーからクローンを作成するには、 `tiup mirror clone`を実行します。 ミラーを作成した後、 `tiup mirror`コマンドを使用してミラーにコンポーネントを追加したり、ミラーからコンポーネントを削除したりできます。TiUPは、ミラーからファイルを削除するのではなく、ファイルを追加して新しいバージョン番号を割り当てることでミラーを更新します。 @@ -23,32 +23,34 @@ TiUPミラーは、コンポーネントとそのメタデータを保存するT 一般的なミラー構造は次のとおりです。 - + # Mirror's root directory - |-- root.json # Mirror's root certificate - |-- {2..N}.root.json # Mirror's root certificate - |-- {1..N}.index.json # Component/user index - |-- {1..N}.{component}.json # Component metadata - |-- {component}-{version}-{os}-{arch}.tar.gz # Component binary package - |-- snapshot.json # Mirror's latest snapshot - |-- timestamp.json # Mirror's latest timestamp - |--+ commits # Mirror's update log (deletable) - |--+ commit-{ts1..tsN} - |-- {N}.root.json - |-- {N}.{component}.json - |-- {N}.index.json - |-- {component}-{version}-{os}-{arch}.tar.gz - |-- snapshot.json - |-- timestamp.json - |--+ keys # Mirror's private key (can be moved to other locations) - |-- {hash1..hashN}-root.json # Private key of the root certificate - |-- {hash}-index.json # Private key of the indexes - |-- {hash}-snapshot.json # Private key of the snapshots - |-- {hash}-timestamp.json # Private key of the timestamps +``` ++ # Mirror's root directory +|-- root.json # Mirror's root certificate +|-- {2..N}.root.json # Mirror's root certificate +|-- {1..N}.index.json # Component/user index +|-- {1..N}.{component}.json # Component metadata +|-- {component}-{version}-{os}-{arch}.tar.gz # Component binary package +|-- snapshot.json # Mirror's latest snapshot +|-- timestamp.json # Mirror's latest timestamp +|--+ commits # Mirror's update log (deletable) + |--+ commit-{ts1..tsN} + |-- {N}.root.json + |-- {N}.{component}.json + |-- {N}.index.json + |-- {component}-{version}-{os}-{arch}.tar.gz + |-- snapshot.json + |-- timestamp.json +|--+ keys # Mirror's private key (can be moved to other locations) + |-- {hash1..hashN}-root.json # Private key of the root certificate + |-- {hash}-index.json # Private key of the indexes + |-- {hash}-snapshot.json # Private key of the snapshots + |-- {hash}-timestamp.json # Private key of the timestamps +``` > **Note:** > -> - `commits`ディレクトリには、ミラー更新プロセスで生成されたログが保存され、ミラーのロールバックに使用されます。ディスク容量が不足している場合は、古いログディレクトリを定期的に削除できます。 -> - `keys`ディレクトリに保存されている秘密鍵は機密情報です。別途保管することをお勧めします。 +> - `commits`ディレクトリには、ミラー更新プロセスで生成されたログが保存され、ミラーのロールバックに使用されます。ディスク容量が不足している場合は、古いログディレクトリを定期的に削除できます。 +> - `keys`ディレクトリに保存されている秘密鍵は機密情報です。別途保管することをお勧めします。 ### ルートディレクトリ {#root-directory} @@ -56,47 +58,49 @@ TiUPミラーでは、ルート証明書は他のメタデータファイルの ルート証明書の形式は次のとおりです。 - { - "signatures": [ # Each metadata file has some signatures which are signed by several private keys corresponding to the file. - { - "keyid": "{id-of-root-key-1}", # The ID of the first private key that participates in the signature. This ID is obtained by hashing the content of the public key that corresponds to the private key. - "sig": "{signature-by-root-key-1}" # The signed part of this file by this private key. - }, - ... - { - "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature. - "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key. - } - ], - "signed": { # The signed part. - "_type": "root", # The type of this file. root.json's type is root. - "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file. - "roles": { # Records the keys used to sign each metadata file. - "{role:index,root,snapshot,timestamp}": { # Each involved metadata file includes index, root, snapshot, and timestamp. - "keys": { # Only the key's signature recorded in `keys` is valid. - "{id-of-the-key-1}": { # The ID of the first key used to sign {role}. - "keytype": "rsa", # The key's type. Currently, the key type is fixed as rsa. - "keyval": { # The key's payload. - "public": "{public-key-content}" # The public key's content. - }, - "scheme": "rsassa-pss-sha256" # Currently, the scheme is fixed as rsassa-pss-sha256. +``` +{ + "signatures": [ # Each metadata file has some signatures which are signed by several private keys corresponding to the file. + { + "keyid": "{id-of-root-key-1}", # The ID of the first private key that participates in the signature. This ID is obtained by hashing the content of the public key that corresponds to the private key. + "sig": "{signature-by-root-key-1}" # The signed part of this file by this private key. + }, + ... + { + "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature. + "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key. + } + ], + "signed": { # The signed part. + "_type": "root", # The type of this file. root.json's type is root. + "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file. + "roles": { # Records the keys used to sign each metadata file. + "{role:index,root,snapshot,timestamp}": { # Each involved metadata file includes index, root, snapshot, and timestamp. + "keys": { # Only the key's signature recorded in `keys` is valid. + "{id-of-the-key-1}": { # The ID of the first key used to sign {role}. + "keytype": "rsa", # The key's type. Currently, the key type is fixed as rsa. + "keyval": { # The key's payload. + "public": "{public-key-content}" # The public key's content. }, - "{id-of-the-key-N}": { # The ID of the Nth key used to sign {role}. - "keytype": "rsa", - "keyval": { - "public": "{public-key-content}" - }, - "scheme": "rsassa-pss-sha256" - } + "scheme": "rsassa-pss-sha256" # Currently, the scheme is fixed as rsassa-pss-sha256. }, - "threshold": {N}, # Indicates that the metadata file needs at least N key signatures. - "url": "/{role}.json" # The address from which the file can be obtained. For index files, prefix it with the version number (for example, /{N}.index.json). - } - }, - "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0. - "version": {N} # The version number of this file. You need to create a new {N+1}.root.json every time you update the file, and set its version to N + 1. - } + "{id-of-the-key-N}": { # The ID of the Nth key used to sign {role}. + "keytype": "rsa", + "keyval": { + "public": "{public-key-content}" + }, + "scheme": "rsassa-pss-sha256" + } + }, + "threshold": {N}, # Indicates that the metadata file needs at least N key signatures. + "url": "/{role}.json" # The address from which the file can be obtained. For index files, prefix it with the version number (for example, /{N}.index.json). + } + }, + "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0. + "version": {N} # The version number of this file. You need to create a new {N+1}.root.json every time you update the file, and set its version to N + 1. } +} +``` ### 索引 {#index} @@ -104,62 +108,64 @@ TiUPミラーでは、ルート証明書は他のメタデータファイルの インデックス ファイルの形式は次のとおりです。 - { - "signatures": [ # The file's signature. - { - "keyid": "{id-of-index-key-1}", # The ID of the first private key that participates in the signature. - "sig": "{signature-by-index-key-1}", # The signed part of this file by this private key. +``` +{ + "signatures": [ # The file's signature. + { + "keyid": "{id-of-index-key-1}", # The ID of the first private key that participates in the signature. + "sig": "{signature-by-index-key-1}", # The signed part of this file by this private key. + }, + ... + { + "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature. + "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key. + } + ], + "signed": { + "_type": "index", # The file type. + "components": { # The component list. + "{component1}": { # The name of the first component. + "hidden": {bool}, # Whether it is a hidden component. + "owner": "{owner-id}", # The component owner's ID. + "standalone": {bool}, # Whether it is a standalone component. + "url": "/{component}.json", # The address from which the component can be obtained. You need to prefix it with the version number (for example, /{N}.{component}.json). + "yanked": {bool} # Indicates whether the component is marked as deleted. }, ... - { - "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature. - "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key. - } - ], - "signed": { - "_type": "index", # The file type. - "components": { # The component list. - "{component1}": { # The name of the first component. - "hidden": {bool}, # Whether it is a hidden component. - "owner": "{owner-id}", # The component owner's ID. - "standalone": {bool}, # Whether it is a standalone component. - "url": "/{component}.json", # The address from which the component can be obtained. You need to prefix it with the version number (for example, /{N}.{component}.json). - "yanked": {bool} # Indicates whether the component is marked as deleted. - }, + "{componentN}": { # The name of the Nth component. ... - "{componentN}": { # The name of the Nth component. - ... - }, }, - "default_components": ["{component1}".."{componentN}"], # The default component that a mirror must contain. Currently, this field defaults to empty (disabled). - "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file. - "owners": { - "{owner1}": { # The ID of the first owner. - "keys": { # Only the key's signature recorded in `keys` is valid. - "{id-of-the-key-1}": { # The first key of the owner. - "keytype": "rsa", # The key's type. Currently, the key type is fixed as rsa. - "keyval": { # The key's payload. - "public": "{public-key-content}" # The public key's content. - }, - "scheme": "rsassa-pss-sha256" # Currently, the scheme is fixed as rsassa-pss-sha256. + }, + "default_components": ["{component1}".."{componentN}"], # The default component that a mirror must contain. Currently, this field defaults to empty (disabled). + "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file. + "owners": { + "{owner1}": { # The ID of the first owner. + "keys": { # Only the key's signature recorded in `keys` is valid. + "{id-of-the-key-1}": { # The first key of the owner. + "keytype": "rsa", # The key's type. Currently, the key type is fixed as rsa. + "keyval": { # The key's payload. + "public": "{public-key-content}" # The public key's content. }, - ... - "{id-of-the-key-N}": { # The Nth key of the owner. - ... - } + "scheme": "rsassa-pss-sha256" # Currently, the scheme is fixed as rsassa-pss-sha256. }, - "name": "{owner-name}", # The name of the owner. - "threshold": {N} # Indicates that the components owned by the owner must have at least N valid signatures. + ... + "{id-of-the-key-N}": { # The Nth key of the owner. + ... + } }, + "name": "{owner-name}", # The name of the owner. + "threshold": {N} # Indicates that the components owned by the owner must have at least N valid signatures. + }, + ... + "{ownerN}": { # The ID of the Nth owner. ... - "{ownerN}": { # The ID of the Nth owner. - ... - } } - "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0. - "version": {N} # The version number of this file. You need to create a new {N+1}.index.json every time you update the file, and set its version to N + 1. } + "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0. + "version": {N} # The version number of this file. You need to create a new {N+1}.index.json every time you update the file, and set its version to N + 1. } +} +``` ### コンポーネント {#component} @@ -167,47 +173,49 @@ TiUPミラーでは、ルート証明書は他のメタデータファイルの コンポーネントメタデータ ファイルの形式は次のとおりです。 - { - "signatures": [ # The file's signature. - { - "keyid": "{id-of-index-key-1}", # The ID of the first private key that participates in the signature. - "sig": "{signature-by-index-key-1}", # The signed part of this file by this private key. +``` +{ + "signatures": [ # The file's signature. + { + "keyid": "{id-of-index-key-1}", # The ID of the first private key that participates in the signature. + "sig": "{signature-by-index-key-1}", # The signed part of this file by this private key. + }, + ... + { + "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature. + "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key. + } + ], + "signed": { + "_type": "component", # The file type. + "description": "{description-of-the-component}", # The description of the component. + "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file. + "id": "{component-id}", # The globally unique ID of the component. + "nightly": "{nightly-cursor}", # The nightly cursor, and the value is the latest nightly version number (for example, v5.0.0-nightly-20201209). + "platforms": { # The component's supported platforms (such as darwin/amd64, linux/arm64). + "{platform-pair-1}": { + "{version-1}": { # The semantic version number (for example, v1.0.0). + "dependencies": null, # Specifies the dependency relationship between components. The field is not used yet and is fixed as null. + "entry": "{entry}", # The relative path of the entry binary file in the tar package. + "hashs": { # The checksum of the tar package. sha256 and sha512 are used. + "sha256": "{sum-of-sha256}", + "sha512": "{sum-of-sha512}", + }, + "length": {length-of-tar}, # The length of the tar package. + "released": "{release-time}", # The release date of the version. + "url": "{url-of-tar}", # The download address of the tar package. + "yanked": {bool} # Indicates whether this version is disabled. + } }, ... - { - "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature. - "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key. - } - ], - "signed": { - "_type": "component", # The file type. - "description": "{description-of-the-component}", # The description of the component. - "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file. - "id": "{component-id}", # The globally unique ID of the component. - "nightly": "{nightly-cursor}", # The nightly cursor, and the value is the latest nightly version number (for example, v5.0.0-nightly-20201209). - "platforms": { # The component's supported platforms (such as darwin/amd64, linux/arm64). - "{platform-pair-1}": { - "{version-1}": { # The semantic version number (for example, v1.0.0). - "dependencies": null, # Specifies the dependency relationship between components. The field is not used yet and is fixed as null. - "entry": "{entry}", # The relative path of the entry binary file in the tar package. - "hashs": { # The checksum of the tar package. sha256 and sha512 are used. - "sha256": "{sum-of-sha256}", - "sha512": "{sum-of-sha512}", - }, - "length": {length-of-tar}, # The length of the tar package. - "released": "{release-time}", # The release date of the version. - "url": "{url-of-tar}", # The download address of the tar package. - "yanked": {bool} # Indicates whether this version is disabled. - } - }, + "{platform-pair-N}": { ... - "{platform-pair-N}": { - ... - } - }, - "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0. - "version": {N} # The version number of this file. You need to create a new {N+1}.{component}.json every time you update the file, and set its version to N + 1. - } + } + }, + "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0. + "version": {N} # The version number of this file. You need to create a new {N+1}.{component}.json every time you update the file, and set its version to N + 1. +} +``` ### スナップショット {#snapshot} @@ -215,42 +223,44 @@ TiUPミラーでは、ルート証明書は他のメタデータファイルの スナップショット ファイルの構造は次のとおりです。 - { - "signatures": [ # The file's signature. - { - "keyid": "{id-of-index-key-1}", # The ID of the first private key that participates in the signature. - "sig": "{signature-by-index-key-1}", # The signed part of this file by this private key. +``` +{ + "signatures": [ # The file's signature. + { + "keyid": "{id-of-index-key-1}", # The ID of the first private key that participates in the signature. + "sig": "{signature-by-index-key-1}", # The signed part of this file by this private key. + }, + ... + { + "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature. + "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key. + } + ], + "signed": { + "_type": "snapshot", # The file type. + "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file. + "meta": { # Other metadata files' information. + "/root.json": { + "length": {length-of-json-file}, # The length of root.json + "version": {version-of-json-file} # The version of root.json + }, + "/index.json": { + "length": {length-of-json-file}, + "version": {version-of-json-file} + }, + "/{component-1}.json": { + "length": {length-of-json-file}, + "version": {version-of-json-file} }, ... - { - "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature. - "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key. - } - ], - "signed": { - "_type": "snapshot", # The file type. - "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file. - "meta": { # Other metadata files' information. - "/root.json": { - "length": {length-of-json-file}, # The length of root.json - "version": {version-of-json-file} # The version of root.json - }, - "/index.json": { - "length": {length-of-json-file}, - "version": {version-of-json-file} - }, - "/{component-1}.json": { - "length": {length-of-json-file}, - "version": {version-of-json-file} - }, + "/{component-N}.json": { ... - "/{component-N}.json": { - ... - } - }, - "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0. - "version": 0 # The version number of this file, which is fixed as 0. - } + } + }, + "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0. + "version": 0 # The version number of this file, which is fixed as 0. + } +``` ### タイムスタンプ {#timestamp} @@ -258,42 +268,44 @@ TiUPミラーでは、ルート証明書は他のメタデータファイルの タイムスタンプ ファイルの形式は次のとおりです。 - { - "signatures": [ # The file's signature. - { - "keyid": "{id-of-index-key-1}", # The ID of the first private key that participates in the signature. - "sig": "{signature-by-index-key-1}", # The signed part of this file by this private key. - }, - ... - { - "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature. - "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key. +``` +{ + "signatures": [ # The file's signature. + { + "keyid": "{id-of-index-key-1}", # The ID of the first private key that participates in the signature. + "sig": "{signature-by-index-key-1}", # The signed part of this file by this private key. + }, + ... + { + "keyid": "{id-of-root-key-N}", # The ID of the Nth private key that participates in the signature. + "sig": "{signature-by-root-key-N}" # The signed part of this file by this private key. + } + ], + "signed": { + "_type": "timestamp", # The file type. + "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file. + "meta": { # The information of snapshot.json. + "/snapshot.json": { + "hashes": { + "sha256": "{sum-of-sha256}" # snapshot.json's sha256. + }, + "length": {length-of-json-file} # The length of snapshot.json. } - ], - "signed": { - "_type": "timestamp", # The file type. - "expires": "{expiration-date-of-this-file}", # The expiration time of the file. If the file expires, the client rejects the file. - "meta": { # The information of snapshot.json. - "/snapshot.json": { - "hashes": { - "sha256": "{sum-of-sha256}" # snapshot.json's sha256. - }, - "length": {length-of-json-file} # The length of snapshot.json. - } - }, - "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0. - "version": {N} # The version number of this file. You need to overwrite timestamp.json every time you update the file, and set its version to N + 1. + }, + "spec_version": "0.1.0", # The specified version followed by this file. If the file structure is changed in the future, the version number needs to be upgraded. The current version number is 0.1.0. + "version": {N} # The version number of this file. You need to overwrite timestamp.json every time you update the file, and set its version to N + 1. +``` ## クライアントワークフロー {#client-workflow} クライアントは次のロジックを使用して、ミラーからダウンロードされたファイルが安全であることを確認します。 -- クライアントがインストールされると、バイナリに`root.json`ファイルが含まれます。 -- 実行中のクライアントは、既存の`root.json`に基づいて次のタスクを実行します。 - 1. `root.json`からバージョンを取得し、 `N`としてマークします。 - 2. ミラーに`{N+1}.root.json`を要求します。要求が成功した場合、 `root.json`で記録した公開鍵を使用して、ファイルが有効かどうかを検証します。 - 3. ミラーから`timestamp.json`を要求し、 `root.json`に記録された公開鍵を使用してファイルが有効かどうかを確認します。 - 4. `timestamp.json`に記録された`snapshot.json`のチェックサムがローカルの`snapshot.json`のチェックサムと一致するかどうかを確認します。一致しない場合は、ミラーから最新の`snapshot.json`を要求し、 `root.json`に記録された公開鍵を使用してファイルの有効性を検証します。 - 5. `snapshot.json`からファイル`index.json`のバージョン番号`N`を取得し、ミラーに`{N}.index.json`を要求します。次に、 `root.json`に記録されている公開鍵を使用して、ファイルが有効かどうかを検証します。 - 6. `tidb.json`や`tikv.json`などのコンポーネントについては、クライアントは`snapshot.json`からコンポーネントのバージョン番号`N`を取得し、ミラーに`{N}.{component}.json`を要求します。次に、クライアントは`index.json`に記録されている公開鍵を使用して、ファイルの有効性を検証します。 - 7. コンポーネントのtarファイルの場合、クライアントは`{component}.json`からファイルのURLとチェックサムを取得し、tarパッケージのURLを要求します。そして、クライアントはチェックサムが正しいかどうかを検証します。 +- クライアントがインストールされると、バイナリに`root.json`ファイルが含まれます。 +- 実行中のクライアントは、既存の`root.json`に基づいて次のタスクを実行します。 + 1. `root.json`からバージョンを取得し、 `N`としてマークします。 + 2. ミラーに`{N+1}.root.json`を要求します。要求が成功した場合、 `root.json`で記録した公開鍵を使用して、ファイルが有効かどうかを検証します。 + 3. ミラーから`timestamp.json`を要求し、 `root.json`に記録された公開鍵を使用してファイルが有効かどうかを確認します。 + 4. `timestamp.json`に記録された`snapshot.json`のチェックサムがローカルの`snapshot.json`のチェックサムと一致するかどうかを確認します。一致しない場合は、ミラーから最新の`snapshot.json`を要求し、 `root.json`に記録された公開鍵を使用してファイルの有効性を検証します。 + 5. `snapshot.json`からファイル`index.json`のバージョン番号`N`を取得し、ミラーに`{N}.index.json`を要求します。次に、 `root.json`に記録されている公開鍵を使用して、ファイルが有効かどうかを検証します。 + 6. `tidb.json`や`tikv.json`などのコンポーネントについては、クライアントは`snapshot.json`からコンポーネントのバージョン番号`N`を取得し、ミラーに`{N}.{component}.json`を要求します。次に、クライアントは`index.json`に記録されている公開鍵を使用して、ファイルの有効性を検証します。 + 7. コンポーネントのtarファイルの場合、クライアントは`{component}.json`からファイルのURLとチェックサムを取得し、tarパッケージのURLを要求します。そして、クライアントはチェックサムが正しいかどうかを検証します。 diff --git a/tiup/tiup-mirror.md b/tiup/tiup-mirror.md index e9327ac6c8c79..14ee220768bae 100644 --- a/tiup/tiup-mirror.md +++ b/tiup/tiup-mirror.md @@ -53,16 +53,16 @@ Use "tiup mirror [command] --help" for more information about a command. tiup mirror clone [global-version] [flags] ``` -- `target-dir` : クローンデータが保存されるディレクトリを指定するために使用されます。 -- `global-version` : すべてのコンポーネントのグローバル バージョンをすばやく設定するために使用されます。 +- `target-dir` : クローンデータが保存されるディレクトリを指定するために使用されます。 +- `global-version` : すべてのコンポーネントのグローバル バージョンをすばやく設定するために使用されます。 `tiup mirror clone`コマンドは多くのオプションフラグを提供します（将来的にはさらに追加される可能性があります）。これらのフラグは、その用途に応じて以下のカテゴリに分類できます。 -- クローン作成時にバージョンを一致させるためにプレフィックスマッチングを使用するかどうかを決定します +- クローン作成時にバージョンを一致させるためにプレフィックスマッチングを使用するかどうかを決定します フラグ`--prefix`が指定された場合、クローンのバージョン番号はプレフィックスによって照合されます。例えば、 `--prefix` 「v5.0.0」と指定した場合、「v5.0.0-rc」と「v5.0.0」が一致します。 -- 完全なクローンを使用するかどうかを決定します +- 完全なクローンを使用するかどうかを決定します `--full`フラグを指定すると、公式ミラーを完全にクローンできます。 @@ -70,21 +70,21 @@ tiup mirror clone [global-version] [flags] > > フラグ`--full` 、およびコンポーネントバージョン`global-version`が指定されていない場合は、一部のメタ情報のみが複製されます。 -- 特定のプラットフォームからパッケージをクローンするかどうかを決定します +- 特定のプラットフォームからパッケージをクローンするかどうかを決定します 特定のプラットフォーム用のパッケージのみをクローンしたい場合は、 `-os`と`-arch`使ってプラットフォームを指定します。例： - - Linux のクローンを作成するには、 `tiup mirror clone [global-version] --os=linux`コマンドを実行します。 - - amd64 のクローンを作成するには、 `tiup mirror clone [global-version] --arch=amd64`コマンドを実行します。 - - linux/amd64 のクローンを作成するには、 `tiup mirror clone [global-version] --os=linux --arch=amd64`コマンドを実行します。 + - Linux のクローンを作成するには、 `tiup mirror clone [global-version] --os=linux`コマンドを実行します。 + - amd64 のクローンを作成するには、 `tiup mirror clone [global-version] --arch=amd64`コマンドを実行します。 + - linux/amd64 のクローンを作成するには、 `tiup mirror clone [global-version] --os=linux --arch=amd64`コマンドを実行します。 -- パッケージの特定のバージョンをクローンするかどうかを決定します +- パッケージの特定のバージョンをクローンするかどうかを決定します コンポーネントの1つのバージョンのみ（すべてのバージョンではなく）を複製したい場合は、 `--=`を使用してそのバージョンを指定します。例： - - `tiup mirror clone --tidb v8.5.3`コマンドを実行して、TiDBコンポーネントの v8.5.3 バージョンのクローンを作成します。 - - `tiup mirror clone --tidb v8.5.3 --tikv all`コマンドを実行して、TiDBコンポーネントの v8.5.3 バージョンと TiKVコンポーネントのすべてのバージョンのクローンを作成します。 - - `tiup mirror clone v8.5.3`コマンドを実行して、クラスター内のすべてのコンポーネントの v8.5.3 バージョンを複製します。 + - `tiup mirror clone --tidb v8.5.3`コマンドを実行して、TiDBコンポーネントの v8.5.3 バージョンのクローンを作成します。 + - `tiup mirror clone --tidb v8.5.3 --tikv all`コマンドを実行して、TiDBコンポーネントの v8.5.3 バージョンと TiKVコンポーネントのすべてのバージョンのクローンを作成します。 + - `tiup mirror clone v8.5.3`コマンドを実行して、クラスター内のすべてのコンポーネントの v8.5.3 バージョンを複製します。 クローン作成後、署名キーが自動的に設定されます。 @@ -152,7 +152,7 @@ tiup mirror grant jdoe ### カスタムコンポーネントの操作 {#work-with-custom-components} -1. hello というカスタムコンポーネントを作成します。 +1. hello というカスタムコンポーネントを作成します。 ```bash $ cat > hello.c << END @@ -168,7 +168,7 @@ tiup mirror grant jdoe `package/hello-v0.0.1-linux-amd64.tar.gz`が作成されます。 -2. リポジトリと秘密鍵を作成し、リポジトリに所有権を付与します。 +2. リポジトリと秘密鍵を作成し、リポジトリに所有権を付与します。 ```bash $ tiup mirror init /tmp/m @@ -181,7 +181,7 @@ tiup mirror grant jdoe tiup mirror publish hello v0.0.1 package/hello-v0.0.1-linux-amd64.tar.gz hello ``` -3. コンポーネントを実行します。まだインストールされていない場合は、最初にダウンロードされます。 +3. コンポーネントを実行します。まだインストールされていない場合は、最初にダウンロードされます。 ```bash $ tiup hello diff --git a/tiup/tiup-overview.md b/tiup/tiup-overview.md index 9cfcdf1264da1..e0f6895483db5 100644 --- a/tiup/tiup-overview.md +++ b/tiup/tiup-overview.md @@ -99,31 +99,31 @@ Use "tiup [command] --help" for more information about a command. 出力は長くなりますが、次の 2 つの部分だけに注目してください。 -- 利用可能なコマンド - - install:コンポーネントの特定のバージョンをインストールするために使用されます - - list: 利用可能な TiDB コンポーネントまたはコンポーネントの利用可能なバージョンのリストを表示するために使用されます。 - - uninstall: コンポーネントまたはコンポーネントのバージョンをアンインストールするために使用されます - - update:コンポーネントのバージョンを更新するために使用されます - - status: コンポーネントの実行履歴を表示するために使用されます - - clean: コンポーネントの実行ログをクリアするために使用されます - - mirror: 公式ミラーからプライベートミラーを複製するために使用されます - - telemetry: テレメトリ機能を制御するために使用されます - - env: TiUPに関連するシステム環境変数のリストを表示するために使用されます - - history: TiUPの実行履歴を表示するために使用されます (デフォルトでは 100 行) - - link:コンポーネントバイナリを $TIUP_HOME/bin/ にリンクするために使用されます。 - - unlink:コンポーネントバイナリを$TIUP_HOME/bin/からリンク解除するために使用されます。 - - help: ヘルプ情報を出力するために使用されます - - completion: 指定されたシェル (bash、zsh、fish、powershell を含む) のコマンドライン自動補完スクリプトを生成するために使用されます。 -- 利用可能なコンポーネント - - Playground: TiDB クラスターをローカルで起動するために使用されます - - client: TiUP Playground への接続に使用するクライアント - - cluster:本番環境用の TiDB クラスターを展開するために使用されます - - bench: データベースのストレステストに使用 +- 利用可能なコマンド + - install:コンポーネントの特定のバージョンをインストールするために使用されます + - list: 利用可能な TiDB コンポーネントまたはコンポーネントの利用可能なバージョンのリストを表示するために使用されます。 + - uninstall: コンポーネントまたはコンポーネントのバージョンをアンインストールするために使用されます + - update:コンポーネントのバージョンを更新するために使用されます + - status: コンポーネントの実行履歴を表示するために使用されます + - clean: コンポーネントの実行ログをクリアするために使用されます + - mirror: 公式ミラーからプライベートミラーを複製するために使用されます + - telemetry: テレメトリ機能を制御するために使用されます + - env: TiUPに関連するシステム環境変数のリストを表示するために使用されます + - history: TiUPの実行履歴を表示するために使用されます (デフォルトでは 100 行) + - link:コンポーネントバイナリを $TIUP_HOME/bin/ にリンクするために使用されます。 + - unlink:コンポーネントバイナリを$TIUP_HOME/bin/からリンク解除するために使用されます。 + - help: ヘルプ情報を出力するために使用されます + - completion: 指定されたシェル (bash、zsh、fish、powershell を含む) のコマンドライン自動補完スクリプトを生成するために使用されます。 +- 利用可能なコンポーネント + - Playground: TiDB クラスターをローカルで起動するために使用されます + - client: TiUP Playground への接続に使用するクライアント + - cluster:本番環境用の TiDB クラスターを展開するために使用されます + - bench: データベースのストレステストに使用 > **Note:** > -> - 利用可能なコンポーネントの数は今後も増え続ける予定です。最新のサポート対象コンポーネントを確認するには、 `tiup list`コマンドを実行してください。 -> - 利用可能なコンポーネントのバージョンリストも引き続き拡大されます。サポートされている最新のコンポーネントバージョンを確認するには、 `tiup list `コマンドを実行してください。 +> - 利用可能なコンポーネントの数は今後も増え続ける予定です。最新のサポート対象コンポーネントを確認するには、 `tiup list`コマンドを実行してください。 +> - 利用可能なコンポーネントのバージョンリストも引き続き拡大されます。サポートされている最新のコンポーネントバージョンを確認するには、 `tiup list `コマンドを実行してください。 TiUPコマンドは TiUP の内部コードに実装され、パッケージ管理操作に使用されますが、 TiUPコンポーネントはTiUPコマンドによってインストールされる独立したコンポーネントパッケージです。 diff --git a/tiup/tiup-playground.md b/tiup/tiup-playground.md index 3f2f6a71e8e64..686c6c5231fab 100644 --- a/tiup/tiup-playground.md +++ b/tiup/tiup-playground.md @@ -19,11 +19,11 @@ tiup playground ${version} [flags] このコマンドは実際には以下の操作を実行します。 -- このコマンドではPlaygroundコンポーネントのバージョンが指定されていないため、 TiUP はまずインストールされているPlaygroundコンポーネントの最新バージョンを確認します。最新バージョンが v1.12.3 であると仮定すると、このコマンドは`tiup playground:v1.12.3`と同じように動作します。 -- TiUP playgroundを使用してTiDB、TiKV、およびPDコンポーネントをインストールしていない場合、playgroundコンポーネントはこれらのコンポーネントの最新の安定版をインストールし、その後これらのインスタンスを起動します。 -- このコマンドでは TiDB、PD、TiKVコンポーネントのバージョンが指定されていないため、 TiUP playground はデフォルトで各コンポーネントの最新バージョンを使用します。最新バージョンが v8.5.4 であると仮定すると、このコマンドは`tiup playground:v1.12.3 v8.5.4`と同じように動作します。 -- このコマンドでは各コンポーネントの数を指定しないため、 TiUP playground はデフォルトで、TiDB インスタンス、TiKV インスタンス、PD インスタンス、 TiFlashインスタンスがそれぞれ 1 つずつで構成される最小のクラスタを起動します。 -- TiDB の各コンポーネントを起動した後、 TiUP Playgroundはクラスターが正常に起動したことを通知し、MySQL クライアントを介して TiDB クラスターに接続する方法や、 [TiDB Dashboard](/dashboard/dashboard-intro.md)にアクセスする方法など、いくつかの有用な情報を提供します。 +- このコマンドではPlaygroundコンポーネントのバージョンが指定されていないため、 TiUP はまずインストールされているPlaygroundコンポーネントの最新バージョンを確認します。最新バージョンが v1.12.3 であると仮定すると、このコマンドは`tiup playground:v1.12.3`と同じように動作します。 +- TiUP playgroundを使用してTiDB、TiKV、およびPDコンポーネントをインストールしていない場合、playgroundコンポーネントはこれらのコンポーネントの最新の安定版をインストールし、その後これらのインスタンスを起動します。 +- このコマンドでは TiDB、PD、TiKVコンポーネントのバージョンが指定されていないため、 TiUP playground はデフォルトで各コンポーネントの最新バージョンを使用します。最新バージョンが v8.5.4 であると仮定すると、このコマンドは`tiup playground:v1.12.3 v8.5.4`と同じように動作します。 +- このコマンドでは各コンポーネントの数を指定しないため、 TiUP playground はデフォルトで、TiDB インスタンス、TiKV インスタンス、PD インスタンス、 TiFlashインスタンスがそれぞれ 1 つずつで構成される最小のクラスタを起動します。 +- TiDB の各コンポーネントを起動した後、 TiUP Playgroundはクラスターが正常に起動したことを通知し、MySQL クライアントを介して TiDB クラスターに接続する方法や、 [TiDB Dashboard](/dashboard/dashboard-intro.md)にアクセスする方法など、いくつかの有用な情報を提供します。 Playgroundコンポーネントのコマンドラインフラグを表示するには、次のコマンドを使用できます。 @@ -93,15 +93,15 @@ tiup playground --tag ${tag_name} TiUP playgroundを使用してTiDBクラスタを起動すると、ブラウザで次のアドレスにアクセスすることで、 [TiDB Dashboard](/dashboard/dashboard-intro.md)とGrafanaにアクセスできます。 -- TiDB Dashboard： `http://127.0.0.1:2379/dashboard` +- TiDB Dashboard： `http://127.0.0.1:2379/dashboard` - - デフォルトのユーザー名: `root` - - デフォルトパスワード: `` (空欄の場合は、直接`Enter`を押してください) + - デフォルトのユーザー名: `root` + - デフォルトパスワード: `` (空欄の場合は、直接`Enter`を押してください) -- Grafana： `http://127.0.0.1:3000` +- Grafana： `http://127.0.0.1:3000` - - デフォルトのユーザー名: `admin` - - デフォルトパスワード: `admin` + - デフォルトのユーザー名: `admin` + - デフォルトパスワード: `admin` > **Note:** > @@ -156,7 +156,7 @@ tiup playground scale-in --pid 86526 TiUP v1.15.0以降では、 TiUP Playgroundを使用してクラスターにTiProxyをデプロイできます。 -1. ファイル`tidb.toml`を作成し、以下の設定を追加してください。 +1. ファイル`tidb.toml`を作成し、以下の設定を追加してください。 ``` graceful-wait-before-shutdown=15 @@ -164,7 +164,7 @@ TiUP v1.15.0以降では、 TiUP Playgroundを使用してクラスターにTiPr この設定項目は、TiDBがサーバーをシャットダウンするまでの待機時間（秒単位）を制御し、クラスタのスケールイン操作中にクライアントが切断されるのを防ぎます。 -2. TiDBクラスタを起動します。 +2. TiDBクラスタを起動します。 ```shell tiup playground v8.5.4 --tiproxy 1 --db.config tidb.toml @@ -195,7 +195,7 @@ TiProxyクライアントプログラム`tiproxyctl`を使用するには、 [Ti tiup playground v8.5.4 --pd.mode ms --pd 3 --tso 2 --scheduling 2 ``` -- `--pd.mode` ：これを`ms`に設定すると、PDのマイクロサービスモードが有効になります。 -- `--pd ` : PDマイクロサービスのAPIの数を指定します。少なくとも`1`ある必要があります。 -- `--tso ` ： `tso`マイクロサービスにデプロイするインスタンスの数を指定します。 -- `--scheduling ` ： `scheduling`マイクロサービスにデプロイするインスタンスの数を指定します。 +- `--pd.mode` ：これを`ms`に設定すると、PDのマイクロサービスモードが有効になります。 +- `--pd ` : PDマイクロサービスのAPIの数を指定します。少なくとも`1`ある必要があります。 +- `--tso ` ： `tso`マイクロサービスにデプロイするインスタンスの数を指定します。 +- `--scheduling ` ： `scheduling`マイクロサービスにデプロイするインスタンスの数を指定します。 diff --git a/tiup/tiup-reference.md b/tiup/tiup-reference.md index 536be803da635..97043d4f8714d 100644 --- a/tiup/tiup-reference.md +++ b/tiup/tiup-reference.md @@ -23,14 +23,14 @@ tiup [flags] [args...] # Runs a component ### --binary {#binary} -- このオプションを有効にすると、指定されたバイナリ ファイルのパスが出力されます。 +- このオプションを有効にすると、指定されたバイナリ ファイルのパスが出力されます。 - - `tiup --binary `を実行すると、最新の安定版がインストールされた``コンポーネントのパスが表示されます。``がインストールされていない場合はエラーが返されます。 - - `tiup --binary :`を実行すると、インストールされた``コンポーネントの``パスが出力されます。この``が出力されない場合は、エラーが返されます。 + - `tiup --binary `を実行すると、最新の安定版がインストールされた``コンポーネントのパスが表示されます。``がインストールされていない場合はエラーが返されます。 + - `tiup --binary :`を実行すると、インストールされた``コンポーネントの``パスが出力されます。この``が出力されない場合は、エラーが返されます。 -- データ型: `BOOLEAN` +- データ型: `BOOLEAN` -- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 +- このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 > **Note:** > @@ -42,13 +42,13 @@ tiup [flags] [args...] # Runs a component > > このオプションは、 `tiup [flags] [args...]`形式のコマンドでのみ使用できます。 -- 実行するコンポーネントのパスを指定します。コンポーネントの実行時にTiUPミラー内のバイナリファイルを使用しない場合は、このオプションを追加することで、カスタムパス内のバイナリファイルを使用するように指定できます。 -- データ型: `STRING` +- 実行するコンポーネントのパスを指定します。コンポーネントの実行時にTiUPミラー内のバイナリファイルを使用しない場合は、このオプションを追加することで、カスタムパス内のバイナリファイルを使用するように指定できます。 +- データ型: `STRING` ### -T, --tag {#t-tag} -- 起動するコンポーネントのタグを指定します。一部のコンポーネントは実行中にディスクストレージを使用する必要があり、 TiUP はこの実行のために一時的なストレージディレクトリを割り当てます。TiUPに固定のディレクトリを割り当てたい場合は、ディレクトリ名に`-T/--tag`を指定します。これにより、同じタグを持つ複数の実行で、同じファイルバッチの読み取りと書き込みが可能になります。 -- データ型: `STRING` +- 起動するコンポーネントのタグを指定します。一部のコンポーネントは実行中にディスクストレージを使用する必要があり、 TiUP はこの実行のために一時的なストレージディレクトリを割り当てます。TiUPに固定のディレクトリを割り当てたい場合は、ディレクトリ名に`-T/--tag`を指定します。これにより、同じタグを持つ複数の実行で、同じファイルバッチの読み取りと書き込みが可能になります。 +- データ型: `STRING` ### -v, --version {#v-version} @@ -62,19 +62,19 @@ TiUPバージョンを出力します。 TiUPには複数のコマンドがあり、これらのコマンドには複数のサブコマンドがあります。具体的なコマンドとその詳細な説明については、以下のリストにある対応するリンクをクリックしてください。 -- [install](/tiup/tiup-command-install.md) :コンポーネントをインストールします。 -- [list](/tiup/tiup-command-list.md) :コンポーネントリストを表示します。 -- [uninstall](/tiup/tiup-command-uninstall.md) :コンポーネントをアンインストールします。 -- [update](/tiup/tiup-command-update.md) : インストールされているコンポーネントを更新します。 -- [status](/tiup/tiup-command-status.md) :コンポーネントの実行ステータスを表示します。 -- [clean](/tiup/tiup-command-clean.md) :コンポーネントのデータディレクトリをクリーンアップします。 -- [mirror](/tiup/tiup-command-mirror.md) : ミラーを管理します。 -- [telemetry](/tiup/tiup-command-telemetry.md) : テレメトリを有効または無効にします。 -- [completion](/tiup/tiup-command-completion.md) : TiUPコマンドを完了します。 -- [env](/tiup/tiup-command-env.md) : TiUP関連の環境変数を表示します。 -- [help](/tiup/tiup-command-help.md) : コマンドまたはコンポーネントのヘルプ情報を表示します。 +- [install](/tiup/tiup-command-install.md) :コンポーネントをインストールします。 +- [list](/tiup/tiup-command-list.md) :コンポーネントリストを表示します。 +- [uninstall](/tiup/tiup-command-uninstall.md) :コンポーネントをアンインストールします。 +- [update](/tiup/tiup-command-update.md) : インストールされているコンポーネントを更新します。 +- [status](/tiup/tiup-command-status.md) :コンポーネントの実行ステータスを表示します。 +- [clean](/tiup/tiup-command-clean.md) :コンポーネントのデータディレクトリをクリーンアップします。 +- [mirror](/tiup/tiup-command-mirror.md) : ミラーを管理します。 +- [telemetry](/tiup/tiup-command-telemetry.md) : テレメトリを有効または無効にします。 +- [completion](/tiup/tiup-command-completion.md) : TiUPコマンドを完了します。 +- [env](/tiup/tiup-command-env.md) : TiUP関連の環境変数を表示します。 +- [help](/tiup/tiup-command-help.md) : コマンドまたはコンポーネントのヘルプ情報を表示します。 ## コンポーネントリスト {#component-list} -- [cluster](/tiup/tiup-component-cluster.md) :本番環境で TiDB クラスターを管理します。 -- [dm](/tiup/tiup-component-dm.md) :本番環境で TiDB Data Migration (DM) クラスターを管理します。 +- [cluster](/tiup/tiup-component-cluster.md) :本番環境で TiDB クラスターを管理します。 +- [dm](/tiup/tiup-component-dm.md) :本番環境で TiDB Data Migration (DM) クラスターを管理します。 diff --git a/tiup/tiup-terminology-and-concepts.md b/tiup/tiup-terminology-and-concepts.md index 9d526e0845366..b3b280e5e0e60 100644 --- a/tiup/tiup-terminology-and-concepts.md +++ b/tiup/tiup-terminology-and-concepts.md @@ -13,16 +13,16 @@ TiUPプログラムには、コンポーネントのダウンロード、アッ `tiup `コマンドを実行すると、 TiUPでサポートされているコンポーネントを実行できます。実行ロジックは以下のとおりです。 -- `tiup [:version]`を通じてコンポーネントのバージョンを指定する場合: +- `tiup [:version]`を通じてコンポーネントのバージョンを指定する場合: - - コンポーネントにローカルにバージョンがインストールされていない場合、 TiUP はミラーサーバーから最新の安定バージョンをダウンロードします。 - - コンポーネントにローカルに 1 つ以上のバージョンがインストールされていて、指定されたバージョンがない場合、 TiUP はミラーサーバーから指定されたバージョンをダウンロードします。 - - 指定されたバージョンのコンポーネントがローカルにインストールされている場合、 TiUP はインストールされているバージョンを実行するように環境変数を設定します。 + - コンポーネントにローカルにバージョンがインストールされていない場合、 TiUP はミラーサーバーから最新の安定バージョンをダウンロードします。 + - コンポーネントにローカルに 1 つ以上のバージョンがインストールされていて、指定されたバージョンがない場合、 TiUP はミラーサーバーから指定されたバージョンをダウンロードします。 + - 指定されたバージョンのコンポーネントがローカルにインストールされている場合、 TiUP はインストールされているバージョンを実行するように環境変数を設定します。 -- コンポーネントを`tiup `まで実行し、バージョンを指定しない場合: +- コンポーネントを`tiup `まで実行し、バージョンを指定しない場合: - - コンポーネントにローカルにバージョンがインストールされていない場合、 TiUP はミラーサーバーから最新の安定バージョンをダウンロードします。 - - 1 つ以上のバージョンがローカルにインストールされている場合、 TiUP はインストールされている最新バージョンを実行するように環境変数を設定します。 + - コンポーネントにローカルにバージョンがインストールされていない場合、 TiUP はミラーサーバーから最新の安定バージョンをダウンロードします。 + - 1 つ以上のバージョンがローカルにインストールされている場合、 TiUP はインストールされている最新バージョンを実行するように環境変数を設定します。 ## TiUPミラー {#tiup-mirrors} @@ -30,5 +30,5 @@ TiUPのすべてのコンポーネントは、 TiUPミラーからダウンロ TiUPミラーは、ローカル ファイル ディレクトリまたはオンライン HTTPサーバーになります。 -- `TIUP_MIRRORS=/path/to/local tiup list` -- `TIUP_MIRRORS=https://private-mirrors.example.com tiup list` +- `TIUP_MIRRORS=/path/to/local tiup list` +- `TIUP_MIRRORS=https://private-mirrors.example.com tiup list` diff --git a/tiup/tiup-troubleshooting-guide.md b/tiup/tiup-troubleshooting-guide.md index 4243d3b8f61f3..bf053afbf7059 100644 --- a/tiup/tiup-troubleshooting-guide.md +++ b/tiup/tiup-troubleshooting-guide.md @@ -33,9 +33,9 @@ CDNサーバーのキャッシュ時間が短いため、新しいチェック この問題を解決するには、 `tiup cluster deploy -i identity_file`を実行して秘密鍵を指定したかどうかを確認します。 -- `-i`フラグが指定されていない場合、 TiUP は秘密鍵のパスを自動的に検出しない可能性があります。`-i`を使用して秘密鍵のパスを明示的に指定することをお勧めします。 -- フラグ`-i`が指定されている場合、 TiUPは指定された秘密鍵を使用してリモートホストにログインできない可能性があります。`ssh -i identity_file user@remote`コマンドを手動で実行することで確認できます。 -- リモート ホストへのログインにパスワードを使用する場合は、フラグ`-p`を指定して正しいログイン パスワードを入力したことを確認してください。 +- `-i`フラグが指定されていない場合、 TiUP は秘密鍵のパスを自動的に検出しない可能性があります。`-i`を使用して秘密鍵のパスを明示的に指定することをお勧めします。 +- フラグ`-i`が指定されている場合、 TiUPは指定された秘密鍵を使用してリモートホストにログインできない可能性があります。`ssh -i identity_file user@remote`コマンドを手動で実行することで確認できます。 +- リモート ホストへのログインにパスワードを使用する場合は、フラグ`-p`を指定して正しいログイン パスワードを入力したことを確認してください。 ### TiUPクラスタコンポーネントを使用したクラスタのアップグレード プロセスが中断されます {#the-process-of-upgrading-the-cluster-using-the-tiup-cluster-component-is-interrupted} @@ -43,9 +43,9 @@ CDNサーバーのキャッシュ時間が短いため、新しいチェック アップグレード プロセスは次の手順に分けられます。 -1. すべてのノード上のコンポーネントの古いバージョンをバックアップします -2. 新しいコンポーネントをリモートに配布 -3. すべてのコンポーネントのローリング再起動を実行します +1. すべてのノード上のコンポーネントの古いバージョンをバックアップします +2. 新しいコンポーネントをリモートに配布 +3. すべてのコンポーネントのローリング再起動を実行します ローリング再起動中にアップグレードが中断された場合は、操作`tiup cluster upgrade`を繰り返す代わりに、操作`tiup cluster restart -N -N `を使用して、再起動が完了していないノードを再起動できます。 diff --git a/transaction-isolation-levels.md b/transaction-isolation-levels.md index 04d0083be42bc..6a4e8af414991 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -73,10 +73,10 @@ TiDB v4.0.0-beta 以降、TiDB は Read Committed 分離レベルをサポート v6.0.0以降、TiDBは、読み取り/書き込み競合が稀なシナリオにおいて、タイムスタンプ取得を最適化するためにシステム変数[`tidb_rc_read_check_ts`](/system-variables.md#tidb_rc_read_check_ts-new-in-v600)使用をサポートします。この変数を有効にすると、TiDBは`SELECT`実行時に、前回の有効なタイムスタンプを使用してデータを読み取ろうとします。この変数の初期値は、トランザクションの`start_ts`です。 -- TiDB は読み取りプロセス中にデータ更新が発生しなかった場合、結果をクライアントに返し、 `SELECT`ステートメントが正常に実行されます。 -- TiDB が読み取りプロセス中にデータ更新を検出した場合: - - TiDB がまだ結果をクライアントに送信していない場合、TiDB は新しいタイムスタンプを取得してこのステートメントを再試行します。 - - TiDBが既に部分的なデータをクライアントに送信している場合、TiDBはクライアントにエラーを報告します。クライアントに送信されるデータの量は、 [`tidb_init_chunk_size`](/system-variables.md#tidb_init_chunk_size)と[`tidb_max_chunk_size`](/system-variables.md#tidb_max_chunk_size)によって制御されます。 +- TiDB は読み取りプロセス中にデータ更新が発生しなかった場合、結果をクライアントに返し、 `SELECT`ステートメントが正常に実行されます。 +- TiDB が読み取りプロセス中にデータ更新を検出した場合: + - TiDB がまだ結果をクライアントに送信していない場合、TiDB は新しいタイムスタンプを取得してこのステートメントを再試行します。 + - TiDBが既に部分的なデータをクライアントに送信している場合、TiDBはクライアントにエラーを報告します。クライアントに送信されるデータの量は、 [`tidb_init_chunk_size`](/system-variables.md#tidb_init_chunk_size)と[`tidb_max_chunk_size`](/system-variables.md#tidb_max_chunk_size)によって制御されます。 分離レベル`READ-COMMITTED`が使用され、ステートメントが`SELECT`多く、読み取り/書き込みの競合がまれなシナリオでは、この変数を有効にすると、グローバル タイムスタンプを取得する際のレイテンシーとコストを回避できます。 @@ -84,10 +84,10 @@ v6.3.0以降、TiDBはポイント書き込みの競合が少ないシナリオ 現在、適用可能なポイント書き込みステートメントの種類は`UPDATE` 、 `DELETE` 、 `SELECT ...... FOR UPDATE`です。ポイント書き込みステートメントとは、主キーまたは一意キーをフィルター条件として使用し、最終実行演算子に`POINT-GET`含まれる書き込みステートメントを指します。現在、3種類のポイント書き込みステートメントに共通するのは、まずキー値に基づいてポイントクエリを実行することです。キーが存在する場合は、キーをロックします。キーが存在しない場合は、空のセットを返します。 -- ポイント書き込みステートメントの読み取りプロセス全体で更新されたデータ バージョンが検出されない場合、TiDB は引き続き現在のトランザクションのタイムスタンプを使用してデータをロックします。 - - ロック取得プロセス中に古いタイムスタンプが原因で書き込み競合が発生した場合、TiDB は最新のグローバル タイムスタンプを取得してロック取得プロセスを再試行します。 - - ロック取得プロセス中に書き込み競合やその他のエラーが発生しない場合、ロックは正常に取得されます。 -- 読み取りプロセス中に更新されたデータ バージョンが検出されると、TiDB は新しいタイムスタンプを取得してこのステートメントを再試行します。 +- ポイント書き込みステートメントの読み取りプロセス全体で更新されたデータ バージョンが検出されない場合、TiDB は引き続き現在のトランザクションのタイムスタンプを使用してデータをロックします。 + - ロック取得プロセス中に古いタイムスタンプが原因で書き込み競合が発生した場合、TiDB は最新のグローバル タイムスタンプを取得してロック取得プロセスを再試行します。 + - ロック取得プロセス中に書き込み競合やその他のエラーが発生しない場合、ロックは正常に取得されます。 +- 読み取りプロセス中に更新されたデータ バージョンが検出されると、TiDB は新しいタイムスタンプを取得してこのステートメントを再試行します。 ポイント書き込みステートメントは多いが、分離レベル`READ-COMMITTED`でのポイント書き込み競合が少ないトランザクションでは、この変数を有効にすると、グローバル タイムスタンプの取得のレイテンシーとオーバーヘッドを回避できます。 @@ -113,6 +113,6 @@ SET SESSION transaction_isolation = 'READ-COMMITTED'; トランザクション分離レベルの構成と使用の詳細については、次のドキュメントを参照してください。 -- [システム変数`transaction_isolation`](/system-variables.md#transaction_isolation) -- [分離レベル](/pessimistic-transaction.md#isolation-level) -- [`SET TRANSACTION`](/sql-statements/sql-statement-set-transaction.md) +- [システム変数`transaction_isolation`](/system-variables.md#transaction_isolation) +- [分離レベル](/pessimistic-transaction.md#isolation-level) +- [`SET TRANSACTION`](/sql-statements/sql-statement-set-transaction.md) diff --git a/transaction-overview.md b/transaction-overview.md index 1e2aba4660687..bf468a37e1dee 100644 --- a/transaction-overview.md +++ b/transaction-overview.md @@ -216,8 +216,8 @@ mysql> SELECT * FROM t1; -- MySQL returns 1 2; TiDB returns 1. > **Note:** > -> - この最適化は楽観的トランザクションにのみ適用されます。 -> - この最適化は`INSERT IGNORE`と`INSERT ON DUPLICATE KEY UPDATE`には適用されず、通常の`INSERT`ステートメントにのみ適用されます。 +> - この最適化は楽観的トランザクションにのみ適用されます。 +> - この最適化は`INSERT IGNORE`と`INSERT ON DUPLICATE KEY UPDATE`には適用されず、通常の`INSERT`ステートメントにのみ適用されます。 ## ステートメントのロールバック {#statement-rollback} @@ -292,9 +292,9 @@ TiDBはデフォルトで線形一貫性を保証します。線形一貫性の 因果一貫性が有効になっている 2 つのトランザクションには、次の特性があります。 -- [潜在的な因果関係を持つトランザクションは、一貫した論理順序と物理的なコミット順序を持つ](#transactions-with-potential-causal-relationship-have-the-consistent-logical-order-and-physical-commit-order) -- [因果関係のないトランザクションは、一貫した論理順序と物理的なコミット順序を保証しません](#transactions-with-no-causal-relationship-do-not-guarantee-consistent-logical-order-and-physical-commit-order) -- [ロックなしの読み取りでは因果関係は生まれない](#reads-without-lock-do-not-create-causal-relationship) +- [潜在的な因果関係を持つトランザクションは、一貫した論理順序と物理的なコミット順序を持つ](#transactions-with-potential-causal-relationship-have-the-consistent-logical-order-and-physical-commit-order) +- [因果関係のないトランザクションは、一貫した論理順序と物理的なコミット順序を保証しません](#transactions-with-no-causal-relationship-do-not-guarantee-consistent-logical-order-and-physical-commit-order) +- [ロックなしの読み取りでは因果関係は生まれない](#reads-without-lock-do-not-create-causal-relationship) ### 潜在的な因果関係を持つトランザクションは、一貫した論理順序と物理的なコミット順序を持つ {#transactions-with-potential-causal-relationship-have-the-consistent-logical-order-and-physical-commit-order} diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index 8d49281a89ba4..5d9e0f654ce25 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -15,9 +15,9 @@ summary: 読み取りおよび書き込みのレイテンシーが長くなる #### 現象 {#phenomenon} -- スローログにクエリ実行計画が出力されている場合は、プランを直接確認できます。`select tidb_decode_plan('xxx...')`ステートメントを実行すると、詳細な実行計画を解析できます。 -- モニター内のスキャンされたキーの数が異常に増加し、スローログでは`Scan Keys`の数が多くなります。 -- TiDBにおけるSQL実行時間は、MySQLなどの他のデータベースと比べて大きく異なります。他のデータベースの実行計画と比較することで、例えば`Join Order`異なるかどうかなどを確認できます。 +- スローログにクエリ実行計画が出力されている場合は、プランを直接確認できます。`select tidb_decode_plan('xxx...')`ステートメントを実行すると、詳細な実行計画を解析できます。 +- モニター内のスキャンされたキーの数が異常に増加し、スローログでは`Scan Keys`の数が多くなります。 +- TiDBにおけるSQL実行時間は、MySQLなどの他のデータベースと比べて大きく異なります。他のデータベースの実行計画と比較することで、例えば`Join Order`異なるかどうかなどを確認できます。 #### 考えられる理由 {#possible-reason} @@ -25,16 +25,16 @@ summary: 読み取りおよび書き込みのレイテンシーが長くなる #### トラブルシューティング方法 {#troubleshooting-methods} -- 統計情報を更新する - - `analyze table`手動で実行し、統計の正確性を維持するために、 `crontab`コマンドを使用して`analyze`定期的に実行します。 - - `auto analyze`を自動的に実行します。`analyze ratio`のしきい値を下げ、情報収集の頻度を上げ、実行の開始時刻と終了時刻を設定します。以下の例をご覧ください。 - - `set global tidb_auto_analyze_ratio=0.2;` - - `set global tidb_auto_analyze_start_time='00:00 +0800';` - - `set global tidb_auto_analyze_end_time='06:00 +0800';` -- 実行計画をバインドする - - アプリケーションの SQL ステートメントを変更し、 `use index`を実行して、列のインデックスを一貫して使用します。 - - 3.0バージョンでは、アプリケーションのSQL文を変更する必要はありません。`create global binding`を使用して、 `force index`のバインディングSQL文を作成します。 - - 4.0 バージョンでは[SQLプラン管理](/sql-plan-management.md)サポートされており、不安定な実行計画によるパフォーマンスの低下を回避します。 +- 統計情報を更新する + - `analyze table`手動で実行し、統計の正確性を維持するために、 `crontab`コマンドを使用して`analyze`定期的に実行します。 + - `auto analyze`を自動的に実行します。`analyze ratio`のしきい値を下げ、情報収集の頻度を上げ、実行の開始時刻と終了時刻を設定します。以下の例をご覧ください。 + - `set global tidb_auto_analyze_ratio=0.2;` + - `set global tidb_auto_analyze_start_time='00:00 +0800';` + - `set global tidb_auto_analyze_end_time='06:00 +0800';` +- 実行計画をバインドする + - アプリケーションの SQL ステートメントを変更し、 `use index`を実行して、列のインデックスを一貫して使用します。 + - 3.0バージョンでは、アプリケーションのSQL文を変更する必要はありません。`create global binding`を使用して、 `force index`のバインディングSQL文を作成します。 + - 4.0 バージョンでは[SQLプラン管理](/sql-plan-management.md)サポートされており、不安定な実行計画によるパフォーマンスの低下を回避します。 ### PD異常 {#pd-anomalies} @@ -44,27 +44,27 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ #### 考えられる理由 {#possible-reasons} -- ディスクの問題です。PDノードが配置されているディスクのI/O負荷が最大になっています。PDノードが、I/O需要の高い他のコンポーネントと同時にデプロイされていないか、またディスクの健全性を確認してください。Grafanaのモニターメトリクス（**ディスクパフォーマンス**、**レイテンシー**/**負荷**）を確認することで原因を確認できます。必要に応じて、FIOツールを使用してディスクのチェックを実行することもできます。 +- ディスクの問題です。PDノードが配置されているディスクのI/O負荷が最大になっています。PDノードが、I/O需要の高い他のコンポーネントと同時にデプロイされていないか、またディスクの健全性を確認してください。Grafanaのモニターメトリクス（**ディスクパフォーマンス**、**レイテンシー**/**負荷**）を確認することで原因を確認できます。必要に応じて、FIOツールを使用してディスクのチェックを実行することもできます。 -- PDピア間のネットワークに問題が発生しています。PDログには`lost the TCP streaming connection`が表示されています。Grafana -> **PD** -> **etcd**モニターの`round trip`を確認して、PDノード間のネットワークに問題が発生し**て**いないか確認し、原因を検証する必要があります。 +- PDピア間のネットワークに問題が発生しています。PDログには`lost the TCP streaming connection`が表示されています。Grafana -> **PD** -> **etcd**モニターの`round trip`を確認して、PDノード間のネットワークに問題が発生し**て**いないか確認し、原因を検証する必要があります。 -- サーバーの負荷が高いです。ログには`server is likely overloaded`が表示されています。 +- サーバーの負荷が高いです。ログには`server is likely overloaded`が表示されています。 -- PD がLeaderを選出できません: PD ログには`lease is not expired`が表示されます。[この号](https://github.com/etcd-io/etcd/issues/10355)は v3.0.x および v2.1.19 で修正されました。 +- PD がLeaderを選出できません: PD ログには`lease is not expired`が表示されます。[この号](https://github.com/etcd-io/etcd/issues/10355)は v3.0.x および v2.1.19 で修正されました。 -- リーダー選出が遅い。リージョンの読み込み時間が長い。この問題は、PDログで`grep "regions cost"`を実行することで確認できます。結果が`load 460927 regions cost 11.77099s`秒など秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0では、 `use-region-storage`を`true`に設定することで`region storage`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。 +- リーダー選出が遅い。リージョンの読み込み時間が長い。この問題は、PDログで`grep "regions cost"`を実行することで確認できます。結果が`load 460927 regions cost 11.77099s`秒など秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0では、 `use-region-storage`を`true`に設定することで`region storage`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。 -- TiDBとPD間のネットワークに問題があります。Grafana -> **blackbox_exporter** -> **ping レイテンシー**モニターにアクセスして、TiDBからPD Leaderへのネットワークが正常に動作しているかどうかを確認してください。 +- TiDBとPD間のネットワークに問題があります。Grafana -> **blackbox_exporter** -> **ping レイテンシー**モニターにアクセスして、TiDBからPD Leaderへのネットワークが正常に動作しているかどうかを確認してください。 -- PDは`FATAL`エラーを報告しますが、ログには`range failed to find revision pair`が表示されます。この問題はv3.0.8（ [＃2040](https://github.com/pingcap/pd/pull/2040) ）で修正されました。 +- PDは`FATAL`エラーを報告しますが、ログには`range failed to find revision pair`が表示されます。この問題はv3.0.8（ [＃2040](https://github.com/pingcap/pd/pull/2040) ）で修正されました。 -- `/api/v1/regions`インターフェースを使用する場合、リージョンが多すぎるとPD OOMが発生する可能性があります。この問題はv3.0.8 ( [＃1986](https://github.com/pingcap/pd/pull/1986) ) で修正されました。 +- `/api/v1/regions`インターフェースを使用する場合、リージョンが多すぎるとPD OOMが発生する可能性があります。この問題はv3.0.8 ( [＃1986](https://github.com/pingcap/pd/pull/1986) ) で修正されました。 -- ローリングアップグレード中にPD OOMが発生しました。gRPCメッセージのサイズに制限がなく、モニターでは`TCP InSegs`が比較的大きいと表示されます。この問題はv3.0.6（ [＃1952](https://github.com/pingcap/pd/pull/1952) ）で修正されました。 +- ローリングアップグレード中にPD OOMが発生しました。gRPCメッセージのサイズに制限がなく、モニターでは`TCP InSegs`が比較的大きいと表示されます。この問題はv3.0.6（ [＃1952](https://github.com/pingcap/pd/pull/1952) ）で修正されました。 -- PDがパニックになります。[バグを報告する](https://github.com/tikv/pd/issues/new?labels=kind/bug&template=bug-report.md) 。 +- PDがパニックになります。[バグを報告する](https://github.com/tikv/pd/issues/new?labels=kind/bug&template=bug-report.md) 。 -- その他の原因。`curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2`を実行してgoroutineを取得し、 [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 +- その他の原因。`curl http://127.0.0.1:2379/debug/pprof/goroutine?debug=2`を実行してgoroutineを取得し、 [バグを報告する](https://github.com/pingcap/pd/issues/new?labels=kind%2Fbug&template=bug-report.md)。 ### TiKVの異常 {#tikv-anomalies} @@ -74,28 +74,28 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ #### 考えられる理由 {#possible-reasons} -- `gRPC duration`のメトリックを確認してください。このメトリックは、TiKVにおけるgRPCリクエストの合計実行時間を表します。TiKVの`gRPC duration`とTiDBの`KV duration`を比較することで、潜在的なネットワークの問題を特定できます。例えば、gRPCの実行時間は短いのにTiDBのKV実行時間が長い場合、TiDBとTiKV間のネットワークレイテンシーが高いか、TiDBとTiKV間のNIC帯域幅が完全に占有されている可能性があります。 +- `gRPC duration`のメトリックを確認してください。このメトリックは、TiKVにおけるgRPCリクエストの合計実行時間を表します。TiKVの`gRPC duration`とTiDBの`KV duration`を比較することで、潜在的なネットワークの問題を特定できます。例えば、gRPCの実行時間は短いのにTiDBのKV実行時間が長い場合、TiDBとTiKV間のネットワークレイテンシーが高いか、TiDBとTiKV間のNIC帯域幅が完全に占有されている可能性があります。 -- TiKVが再開されたため再選。 - - TiKVがパニック状態になった後、 `systemd`引き上げられ、正常に動作します。panicが発生したかどうかは、TiKVのログを確認することで確認できます。この問題は予期せぬものであるため、発生した場合は[バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md) 。 - - TiKVは第三者によって停止または強制終了され、その後`systemd`によってプルアップされます。`dmesg`とTiKVログを確認して原因を確認してください。 - - TiKV は OOM であり、再起動を引き起こします。 - - `THP` (Transparent Hugepage) を動的に調整しているため、TiKV がハングします。 +- TiKVが再開されたため再選。 + - TiKVがパニック状態になった後、 `systemd`引き上げられ、正常に動作します。panicが発生したかどうかは、TiKVのログを確認することで確認できます。この問題は予期せぬものであるため、発生した場合は[バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md) 。 + - TiKVは第三者によって停止または強制終了され、その後`systemd`によってプルアップされます。`dmesg`とTiKVログを確認して原因を確認してください。 + - TiKV は OOM であり、再起動を引き起こします。 + - `THP` (Transparent Hugepage) を動的に調整しているため、TiKV がハングします。 -- モニターを確認してください：TiKV RocksDB が書き込みストールに遭遇し、再選出が行われます。モニター**Grafana** -> **TiKV-details** -> **errors**に`server is busy`が表示されているかどうかを確認してください。 +- モニターを確認してください：TiKV RocksDB が書き込みストールに遭遇し、再選出が行われます。モニター**Grafana** -> **TiKV-details** -> **errors**に`server is busy`が表示されているかどうかを確認してください。 -- ネットワーク分離のため再選。 +- ネットワーク分離のため再選。 -- `block-cache`設定が大きすぎる場合、TiKV OOM が発生する可能性があります。問題の原因を確認するには、 **Grafana**モニターで該当するインスタンスを選択し、RocksDB の`block cache size`を確認してください。同時に、 `[storage.block-cache] capacity = # "1GB"`パラメータが正しく設定されているかどうかを確認してください。デフォルトでは、 **TiKV**の`block-cache`マシンの総メモリの`45%`に設定されています。コンテナに TiKV をデプロイする際には、このパラメータを明示的に指定する必要があります。TiKV は物理マシンのメモリを取得するため、コンテナのメモリ制限を超える可能性があります。 +- `block-cache`設定が大きすぎる場合、TiKV OOM が発生する可能性があります。問題の原因を確認するには、 **Grafana**モニターで該当するインスタンスを選択し、RocksDB の`block cache size`を確認してください。同時に、 `[storage.block-cache] capacity = # "1GB"`パラメータが正しく設定されているかどうかを確認してください。デフォルトでは、 **TiKV**の`block-cache`マシンの総メモリの`45%`に設定されています。コンテナに TiKV をデプロイする際には、このパラメータを明示的に指定する必要があります。TiKV は物理マシンのメモリを取得するため、コンテナのメモリ制限を超える可能性があります。 -- コプロセッサーは大量の大きなクエリを受信し、大量のデータを返します。gRPCはコプロセッサがデータを返すのに間に合うようにデータを送信できず、OOMが発生します。原因を確認するには、モニター**Grafana** -> **TiKV詳細**->**コプロセッサ概要**で、 `response size` `network outbound`トラフィックを超えているかどうかを確認してください。 +- コプロセッサーは大量の大きなクエリを受信し、大量のデータを返します。gRPCはコプロセッサがデータを返すのに間に合うようにデータを送信できず、OOMが発生します。原因を確認するには、モニター**Grafana** -> **TiKV詳細**->**コプロセッサ概要**で、 `response size` `network outbound`トラフィックを超えているかどうかを確認してください。 ### 単一の TiKV スレッドのボトルネック {#bottleneck-of-a-single-tikv-thread} TiKV にはボトルネックになる可能性のある単一スレッドがいくつかあります。 -- TiKVインスタンス内のリージョンが多すぎると、単一のgRPCスレッドがボトルネックになります（ **Grafana** -> **TiKV詳細**->**スレッドCPU/gRPC CPU Per Thread**メトリックを確認してください）。v3.x以降のバージョンでは、 `Hibernate Region`有効にするとこの問題を解決できます。 -- v3.0 より前のバージョンでは、raftstore スレッドまたは apply スレッドがボトルネックになる場合 ( **Grafana** -> **TiKV-details** -> **Thread CPU/raft store CPU**および**Async apply CPU**メトリックが`80%`超える)、TiKV (v2.x) インスタンスをスケールアウトするか、マルチスレッド対応の v3.x にアップグレードできます。 +- TiKVインスタンス内のリージョンが多すぎると、単一のgRPCスレッドがボトルネックになります（ **Grafana** -> **TiKV詳細**->**スレッドCPU/gRPC CPU Per Thread**メトリックを確認してください）。v3.x以降のバージョンでは、 `Hibernate Region`有効にするとこの問題を解決できます。 +- v3.0 より前のバージョンでは、raftstore スレッドまたは apply スレッドがボトルネックになる場合 ( **Grafana** -> **TiKV-details** -> **Thread CPU/raft store CPU**および**Async apply CPU**メトリックが`80%`超える)、TiKV (v2.x) インスタンスをスケールアウトするか、マルチスレッド対応の v3.x にアップグレードできます。 ### CPU負荷が増加する {#cpu-load-increases} @@ -105,8 +105,8 @@ CPU リソースの使用量がボトルネックになります。 #### 考えられる理由 {#possible-reasons} -- ホットスポットの問題 -- 全体的な負荷が高い。TiDBのスロークエリと負荷の高いクエリを確認してください。インデックスを追加するか、クエリをバッチ処理で実行することで、実行中のクエリを最適化してください。別の解決策としては、クラスターをスケールアウトすることです。 +- ホットスポットの問題 +- 全体的な負荷が高い。TiDBのスロークエリと負荷の高いクエリを確認してください。インデックスを追加するか、クエリをバッチ処理で実行することで、実行中のクエリを最適化してください。別の解決策としては、クラスターをスケールアウトすることです。 ## その他の原因 {#other-causes} @@ -134,6 +134,6 @@ CPU リソースの使用量がボトルネックになります。 TiDBのトランザクションは、マルチバージョン同時実行制御（MVCC）メカニズムを採用しています。新しく書き込まれたデータが古いデータを上書きする場合、古いデータは置き換えられず、両方のバージョンのデータが保存されます。タイムスタンプは異なるバージョンを区別するために使用されます。GCのタスクは、古くなったデータをクリアすることです。 -- ロック解決フェーズでは、TiKVに大量のリクエスト`scan_lock`が作成されます。これはgRPC関連のメトリクスで確認できます。これらのリクエスト`scan_lock`は、すべてのリージョンを呼び出します。 -- 範囲の削除のフェーズでは、TiKV に少数の (またはまったくない) `unsafe_destroy_range`が送信されます。これは、gRPC 関連のメトリックと**GC タスク**パネルで確認できます。 -- Do GC フェーズでは、各 TiKV はデフォルトでマシン上のリーダーリージョンをスキャンし、各リーダーに対して GC を実行します。これは、 **GC タスク**パネルで確認できます。 +- ロック解決フェーズでは、TiKVに大量のリクエスト`scan_lock`が作成されます。これはgRPC関連のメトリクスで確認できます。これらのリクエスト`scan_lock`は、すべてのリージョンを呼び出します。 +- 範囲の削除のフェーズでは、TiKV に少数の (またはまったくない) `unsafe_destroy_range`が送信されます。これは、gRPC 関連のメトリックと**GC タスク**パネルで確認できます。 +- Do GC フェーズでは、各 TiKV はデフォルトでマシン上のリーダーリージョンをスキャンし、各リーダーに対して GC を実行します。これは、 **GC タスク**パネルで確認できます。 diff --git a/troubleshoot-data-inconsistency-errors.md b/troubleshoot-data-inconsistency-errors.md index ffe911f23cf67..23e0d3e61f0d1 100644 --- a/troubleshoot-data-inconsistency-errors.md +++ b/troubleshoot-data-inconsistency-errors.md @@ -73,8 +73,8 @@ TiDBは、トランザクションまたは[`ADMIN CHECK [TABLE|INDEX]`](/sql-st このエラーは、表`t`のインデックス`c2`の列`c2`の値に次の不一致があることを示しています。 -- ハンドルが`2`である行のインデックス キーと値のペアでは、列`c2`の値は`13`です。 -- 行レコードのキーと値のペアでは、列`c2`の値は`12`です。 +- ハンドルが`2`である行のインデックス キーと値のペアでは、列`c2`の値は`13`です。 +- 行レコードのキーと値のペアでは、列`c2`の値は`12`です。 #### エラー8223 {#error-8223} @@ -104,8 +104,8 @@ TiDBは、トランザクションまたは[`ADMIN CHECK [TABLE|INDEX]`](/sql-st トランザクション実行時に報告される次のエラーについては、対応するチェックをバイパスできます。 -- エラー 8138、8139、および 8140 のチェックをバイパスするには、 `set @@tidb_enable_mutation_checker=0`設定します。 -- エラー 8141 のチェックをバイパスするには、 `set @@tidb_txn_assertion_level=OFF`設定します。 +- エラー 8138、8139、および 8140 のチェックをバイパスするには、 `set @@tidb_enable_mutation_checker=0`設定します。 +- エラー 8141 のチェックをバイパスするには、 `set @@tidb_txn_assertion_level=OFF`設定します。 > **Note:** > diff --git a/troubleshoot-high-disk-io.md b/troubleshoot-high-disk-io.md index bfef8da04101a..241b8923a4122 100644 --- a/troubleshoot-high-disk-io.md +++ b/troubleshoot-high-disk-io.md @@ -19,8 +19,8 @@ I/Oの問題を特定する最も簡単な方法は、 TiUPによってデフォ **Overview** > **System Info** > **IO Util**では、クラスター内の各マシンのI/Oステータスを確認できます。この指標はLinux `iostat`モニターの`util`に似ています。パーセンテージが高いほど、ディスクI/O使用率が高いことを示します。 -- モニターで I/O 使用率が高いマシンが 1 台だけの場合、現在このマシンに読み取りおよび書き込みのホットスポットがある可能性があります。 -- モニター内のほとんどのマシンの I/O 使用率が高い場合、クラスターの I/O 負荷が高くなっています。 +- モニターで I/O 使用率が高いマシンが 1 台だけの場合、現在このマシンに読み取りおよび書き込みのホットスポットがある可能性があります。 +- モニター内のほとんどのマシンの I/O 使用率が高い場合、クラスターの I/O 負荷が高くなっています。 上記の最初の状況（I/O使用率が高いマシンが1台のみ）の場合、**ディスクパフォーマンスダッシュボード**のI/Oメトリック（ `Disk Latency`や`Disk Load`など）をさらに観察し、異常の有無を確認できます。必要に応じて、fioツールを使用してディスクをチェックしてください。 @@ -30,8 +30,8 @@ TiDBクラスターのメインストレージコンポーネントはTiKVです **TiKV-Details** > **Raft IO**では、これら 2 つのインスタンスのディスク書き込みに関連するメトリックを確認できます。 -- `Append log duration` : このメトリックは、 Raftログを保存するRockDBへの書き込みの応答時間を示します。`.99`の応答時間は50ミリ秒以内である必要があります。 -- `Apply log duration` ：このメトリックは、実データを格納するRockDBへの書き込みの応答時間を示します。 `.99`時間は100ミリ秒以内である必要があります。 +- `Append log duration` : このメトリックは、 Raftログを保存するRockDBへの書き込みの応答時間を示します。`.99`の応答時間は50ミリ秒以内である必要があります。 +- `Apply log duration` ：このメトリックは、実データを格納するRockDBへの書き込みの応答時間を示します。 `.99`時間は100ミリ秒以内である必要があります。 これら 2 つのメトリックには、書き込みホットスポットを表示するのに役立つ**サーバーごとの**監視パネルもあります。 @@ -39,37 +39,37 @@ TiDBクラスターのメインストレージコンポーネントはTiKVです **TiKV-Details** > **Storage**には、ストレージに関連する監視メトリックがあります。 -- `Storage command total` : 受信した異なるコマンドの数を示します。 -- `Storage async write duration` : `disk sync duration`などの監視メトリックが含まれます。これらはRaft I/Oに関連する可能性があります。異常な状況が発生した場合は、ログを確認して関連コンポーネントの動作状態を確認してください。 +- `Storage command total` : 受信した異なるコマンドの数を示します。 +- `Storage async write duration` : `disk sync duration`などの監視メトリックが含まれます。これらはRaft I/Oに関連する可能性があります。異常な状況が発生した場合は、ログを確認して関連コンポーネントの動作状態を確認してください。 #### その他のパネル {#other-panels} さらに、他のパネル指標もボトルネックがI/Oかどうかを判断するのに役立つ場合があります。また、パラメータの設定を試してみることもできます。TiKV gRPCのprewrite/commit/raw-put（rawキーバリュークラスターのみ）の所要時間を確認することで、ボトルネックがTiKV書き込みの遅さにあることを判断できます。TiKV書き込みが遅い場合の一般的な状況は以下のとおりです。 -- `append log`は遅いです。TiKV Grafana の`Raft I/O`と`append log duration`指標は比較的高くなっていますが、これは多くの場合、ディスク書き込みの遅延が原因です。RocksDB **-raft**で`WAL Sync Duration max`の値を確認することで、 `append log`の遅い原因を特定できます。そうでない場合は、バグを報告する必要があるかもしれません。 +- `append log`は遅いです。TiKV Grafana の`Raft I/O`と`append log duration`指標は比較的高くなっていますが、これは多くの場合、ディスク書き込みの遅延が原因です。RocksDB **-raft**で`WAL Sync Duration max`の値を確認することで、 `append log`の遅い原因を特定できます。そうでない場合は、バグを報告する必要があるかもしれません。 -- `raftstore`スレッドがビジー状態です。TiKV Grafana では、 `Raft Propose` / `propose wait duration` `append log duration`よりも大幅に高い値です。トラブルシューティングのために、以下の点を確認してください。 +- `raftstore`スレッドがビジー状態です。TiKV Grafana では、 `Raft Propose` / `propose wait duration` `append log duration`よりも大幅に高い値です。トラブルシューティングのために、以下の点を確認してください。 - - `[raftstore]`のうち`store-pool-size`の値が小さすぎないか。この値は`[1,5]` 、大きすぎない範囲に設定することをお勧めします。 - - マシンのCPUリソースが不足しているかどうか。 + - `[raftstore]`のうち`store-pool-size`の値が小さすぎないか。この値は`[1,5]` 、大きすぎない範囲に設定することをお勧めします。 + - マシンのCPUリソースが不足しているかどうか。 -- `apply log`は遅いです。TiKV Grafana の`Raft I/O`と`apply log duration`指標は比較的高く、これは通常、 `Raft Propose` / `apply wait duration`指標も比較的高い場合に発生します。考えられる原因は次のとおりです。 +- `apply log`は遅いです。TiKV Grafana の`Raft I/O`と`apply log duration`指標は比較的高く、これは通常、 `Raft Propose` / `apply wait duration`指標も比較的高い場合に発生します。考えられる原因は次のとおりです。 - - `[raftstore]`のうち`apply-pool-size`は小さすぎます。この値は`[1, 5]`の範囲で、大きすぎないように設定することをお勧めします。`Thread CPU`/`apply cpu`の値も比較的高くなっています。 - - マシンの CPU リソースが不足しています。 - - 単一リージョンの書き込みホットスポットの問題（現在、この問題の解決は進行中です）。単一スレッド`apply`のCPU使用率が高くなっています（Grafana式に`by (instance, name)`追加することで確認できます）。 - - RocksDBへの書き込み速度が遅く、 `RocksDB kv` / `max write duration`高い値です。1つのRaftログには複数のキーと値のペア（kv）が含まれる場合があります。128 kvが一括でRocksDBに書き込まれるため、 `apply`ログ1つにつきRocksDBへの書き込みが複数回発生する可能性があります。 - - その他の原因の場合は、バグとして報告してください。 + - `[raftstore]`のうち`apply-pool-size`は小さすぎます。この値は`[1, 5]`の範囲で、大きすぎないように設定することをお勧めします。`Thread CPU`/`apply cpu`の値も比較的高くなっています。 + - マシンの CPU リソースが不足しています。 + - 単一リージョンの書き込みホットスポットの問題（現在、この問題の解決は進行中です）。単一スレッド`apply`のCPU使用率が高くなっています（Grafana式に`by (instance, name)`追加することで確認できます）。 + - RocksDBへの書き込み速度が遅く、 `RocksDB kv` / `max write duration`高い値です。1つのRaftログには複数のキーと値のペア（kv）が含まれる場合があります。128 kvが一括でRocksDBに書き込まれるため、 `apply`ログ1つにつきRocksDBへの書き込みが複数回発生する可能性があります。 + - その他の原因の場合は、バグとして報告してください。 -- `raft commit log`は遅いです。TiKV Grafanaでは、 `Raft I/O`と`commit log duration` （Grafana 4.xのみで利用可能）のメトリックは比較的高いです。各リージョンは独立したRaftグループに対応しています。Raftは、TCPのスライディングウィンドウ機構に似たフロー制御機構を備えています。スライディングウィンドウのサイズを制御するには、 `[raftstore] raft-max-inflight-msgs`パラメータを調整します。書き込みホットスポットがあり、 `commit log duration`が大きい場合は、このパラメータを`1024`などのより大きな値に設定することで適切に対処できます。 +- `raft commit log`は遅いです。TiKV Grafanaでは、 `Raft I/O`と`commit log duration` （Grafana 4.xのみで利用可能）のメトリックは比較的高いです。各リージョンは独立したRaftグループに対応しています。Raftは、TCPのスライディングウィンドウ機構に似たフロー制御機構を備えています。スライディングウィンドウのサイズを制御するには、 `[raftstore] raft-max-inflight-msgs`パラメータを調整します。書き込みホットスポットがあり、 `commit log duration`が大きい場合は、このパラメータを`1024`などのより大きな値に設定することで適切に対処できます。 ### ログからI/Oの問題を特定する {#locate-i-o-issues-from-log} -- クライアントが`server is busy`や特に`raftstore is busy`などのエラーを報告する場合、エラーは I/O の問題に関連している可能性があります。 +- クライアントが`server is busy`や特に`raftstore is busy`などのエラーを報告する場合、エラーは I/O の問題に関連している可能性があります。 `busy`エラーの具体的な原因を確認するには、監視パネル（ **Grafana** -> **TiKV** -> **errors** ）を確認してください。`server is busy`はTiKVのフロー制御メカニズムです。これにより、TiKVは`tidb/ti-client` 、現在のTiKVの負荷が高すぎるため、クライアントは後で再試行する必要があることを通知します。 -- TiKV RocksDB ログに`Write stall`が表示されます。 +- TiKV RocksDB ログに`Write stall`が表示されます。 レベル0のSSTファイルが多すぎると書き込みストールが発生している可能性があります。この問題に対処するには、パラメータ`[rocksdb] max-sub-compactions = 2 (or 3)`を追加してレベル0のSSTファイルの圧縮を高速化できます。このパラメータは、レベル0からレベル1への圧縮タスクを`max-sub-compactions`サブタスクに分割し、マルチスレッドで同時実行できるようにすることを意味します。 @@ -81,15 +81,15 @@ TiDBクラスターのメインストレージコンポーネントはTiKVです クラスターデプロイメントツール（TiUP）は、デフォルトでアラート項目としきい値が組み込まれたアラートコンポーネントを使用してクラスターをデプロイします。以下のアラート項目はI/Oに関連しています。 -- TiKV_write_stall -- TiKV_raft_log_lag -- TiKV_async_request_snapshot_duration_seconds -- TiKV_async_request_write_duration_seconds -- TiKV_raft_append_log_duration_secs -- TiKV_raft_apply_log_duration_secs +- TiKV_write_stall +- TiKV_raft_log_lag +- TiKV_async_request_snapshot_duration_seconds +- TiKV_async_request_write_duration_seconds +- TiKV_raft_append_log_duration_secs +- TiKV_raft_apply_log_duration_secs ## I/Oの問題を処理する {#handle-i-o-issues} -- I/O ホットスポットの問題が発生していることが確認された場合は、「TiDB ホットスポットの問題の処理」を参照して I/O ホットスポットを排除する必要があります。 -- 全体的な I/O パフォーマンスがボトルネックになっていることが確認され、アプリケーション側で I/O パフォーマンスが低下し続けると判断できる場合は、分散データベースのスケーリング機能を活用し、TiKV ノードの数を増やして全体的な I/O スループットを向上させることができます。 -- 上記のようにいくつかのパラメータを調整し、コンピューティング/メモリリソースを使用してディスクストレージリソースを補います。 +- I/O ホットスポットの問題が発生していることが確認された場合は、「TiDB ホットスポットの問題の処理」を参照して I/O ホットスポットを排除する必要があります。 +- 全体的な I/O パフォーマンスがボトルネックになっていることが確認され、アプリケーション側で I/O パフォーマンスが低下し続けると判断できる場合は、分散データベースのスケーリング機能を活用し、TiKV ノードの数を増やして全体的な I/O スループットを向上させることができます。 +- 上記のようにいくつかのパラメータを調整し、コンピューティング/メモリリソースを使用してディスクストレージリソースを補います。 diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index d3ac5174da5b9..90dde2a862512 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -37,8 +37,8 @@ Value: rowID インデックス データには、一意インデックスと非一意インデックスの 2 種類があります。 -- 一意インデックスの場合は、上記のコーディング規則に従うことができます。 -- 非一意インデックスの場合、このエンコーディングでは一意キーを構築できません。これは、同じインデックスの`tablePrefix{TableID}_indexPrefixSep{IndexID}`は同じですが、複数の行の`ColumnsValue`は同じになる可能性があるためです。非一意インデックスのエンコーディング規則は次のとおりです。 +- 一意インデックスの場合は、上記のコーディング規則に従うことができます。 +- 非一意インデックスの場合、このエンコーディングでは一意キーを構築できません。これは、同じインデックスの`tablePrefix{TableID}_indexPrefixSep{IndexID}`は同じですが、複数の行の`ColumnsValue`は同じになる可能性があるためです。非一意インデックスのエンコーディング規則は次のとおりです。 ``` Key: tablePrefix{TableID}_indexPrefixSep{IndexID}_indexedColumnsValue_rowID @@ -63,9 +63,9 @@ TiDBのコーディングルールによれば、同一テーブルのデータ パフォーマンスの問題は必ずしもホットスポットが原因であるとは限らず、複数の要因が絡み合っている可能性があります。問題のトラブルシューティングを行う前に、ホットスポットに関連しているかどうかを確認してください。 -- 書き込みホットスポットを判断するには、 **TiKV トラブルシューティング**監視パネルで**Hot Write**を開き、任意の TiKV ノードのRaftstore CPU メトリック値が他のノードの値よりも大幅に高いかどうかを確認します。 +- 書き込みホットスポットを判断するには、 **TiKV トラブルシューティング**監視パネルで**Hot Write**を開き、任意の TiKV ノードのRaftstore CPU メトリック値が他のノードの値よりも大幅に高いかどうかを確認します。 -- 読み取りホットスポットを判断するには、 **TiKV 詳細**監視パネルで**Thread_CPU**を開き、いずれかの TiKV ノードのコプロセッサ CPU メトリック値が特に高いかどうかを確認します。 +- 読み取りホットスポットを判断するには、 **TiKV 詳細**監視パネルで**Thread_CPU**を開き、いずれかの TiKV ノードのコプロセッサ CPU メトリック値が特に高いかどうかを確認します。 ### TiDB Dashboardを使用してホットスポットテーブルを見つける {#use-tidb-dashboard-to-locate-hotspot-tables} @@ -172,8 +172,8 @@ TiDBのコプロセッサーキャッシュ機能は、計算結果のキャッ **参照:** -- [高同時実行書き込みのベストプラクティス](/best-practices/high-concurrency-best-practices.md) -- [分割リージョン](/sql-statements/sql-statement-split-region.md) +- [高同時実行書き込みのベストプラクティス](/best-practices/high-concurrency-best-practices.md) +- [分割リージョン](/sql-statements/sql-statement-split-region.md) ## 散在する読み取りホットスポット {#scatter-read-hotspots} diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index e3802c1722162..2a22b400d14aa 100644 --- a/troubleshoot-lock-conflicts.md +++ b/troubleshoot-lock-conflicts.md @@ -17,9 +17,9 @@ TiDBはバージョン5.1以降、ロックビュー機能をサポートして これらのテーブルの詳細な紹介については、次のドキュメントを参照してください。 -- [`TIDB_TRX`および`CLUSTER_TIDB_TRX`](/information-schema/information-schema-tidb-trx.md) : 現在の TiDB ノードまたはクラスター全体で実行中のすべてのトランザクションの情報 (トランザクションがロック待機状態にあるかどうか、ロック待機時間、トランザクションで実行されたステートメントのダイジェストなど) を提供します。 -- [`DATA_LOCK_WAITS`](/information-schema/information-schema-data-lock-waits.md) : ブロックしているトランザクションとブロックされたトランザクションの`start_ts` 、ブロックされた SQL ステートメントのダイジェスト、待機が発生したキーなど、悲観的ロック待機情報を TiKV で提供します。 -- [`DEADLOCKS`と`CLUSTER_DEADLOCKS`](/information-schema/information-schema-deadlocks.md) : デッドロック ループ内のトランザクション間の待機関係、トランザクションで現在実行されているステートメントのダイジェスト、待機が発生しているキーなど、現在の TiDB ノードまたはクラスター全体で最近発生したいくつかのデッドロック イベントの情報を提供します。 +- [`TIDB_TRX`および`CLUSTER_TIDB_TRX`](/information-schema/information-schema-tidb-trx.md) : 現在の TiDB ノードまたはクラスター全体で実行中のすべてのトランザクションの情報 (トランザクションがロック待機状態にあるかどうか、ロック待機時間、トランザクションで実行されたステートメントのダイジェストなど) を提供します。 +- [`DATA_LOCK_WAITS`](/information-schema/information-schema-data-lock-waits.md) : ブロックしているトランザクションとブロックされたトランザクションの`start_ts` 、ブロックされた SQL ステートメントのダイジェスト、待機が発生したキーなど、悲観的ロック待機情報を TiKV で提供します。 +- [`DEADLOCKS`と`CLUSTER_DEADLOCKS`](/information-schema/information-schema-deadlocks.md) : デッドロック ループ内のトランザクション間の待機関係、トランザクションで現在実行されているステートメントのダイジェスト、待機が発生しているキーなど、現在の TiDB ノードまたはクラスター全体で最近発生したいくつかのデッドロック イベントの情報を提供します。 > **Note:** > @@ -171,15 +171,15 @@ Txn0はPrewriteフェーズを完了し、Commitフェーズに入ります。 TiDB クラスター内の読み取り/書き込み競合は、次の方法で検出できます。 -1. TiDBサーバーのメトリックとログの監視 +1. TiDBサーバーのメトリックとログの監視 - - Grafanaによるデータの監視 + - Grafanaによるデータの監視 TiDBダッシュボードの`KV Errors`パネル目では、 `Lock Resolve OPS`の`not_expired`と`KV Backoff OPS`の`tikvLockFast` `resolve`トランザクションにおける読み取り/書き込み競合を確認するために使用できる監視メトリックです。すべてのメトリックの値が上昇している場合、読み取り/書き込み競合が多数発生している可能性があります。`not_expired`項目は、トランザクションのロックがタイムアウトしていないことを意味します。`resolve`項目は、他のトランザクションがロックのクリーンアップを試みていることを意味します。`tikvLockFast`項目は、読み取り/書き込み競合が発生していることを意味します。 ![KV-backoff-txnLockFast-optimistic](/media/troubleshooting-lock-pic-09.png) ![KV-Errors-resolve-optimistic](/media/troubleshooting-lock-pic-08.png) - - TiDBサーバーのログ + - TiDBサーバーのログ 読み取り/書き込みの競合がある場合は、TiDB ログに次のメッセージが表示されます。 @@ -187,12 +187,12 @@ TiDB クラスター内の読み取り/書き込み競合は、次の方法で [INFO] [coprocessor.go:743] ["[TIME_COP_PROCESS] resp_time:406.038899ms txnStartTS:416643508703592451 region_id:8297 store_addr:10.8.1.208:20160 backoff_ms:255 backoff_types:[txnLockFast,txnLockFast] kv_process_ms:333 scan_total_write:0 scan_processed_write:0 scan_total_data:0 scan_processed_data:0 scan_total_lock:0 scan_processed_lock:0"] ``` - - txnStartTS: 読み取り要求を送信しているトランザクションのstart_ts。上記のログでは、 `416643508703592451`がstart_tsです。 - - backoff_types: 読み取り/書き込み競合が発生し、読み取り要求がバックオフと再試行を実行する場合、再試行のタイプは`TxnLockFast`なります。 - - backoff_ms: 読み取りリクエストがバックオフとリトライに要した時間。単位はミリ秒です。上記のログでは、読み取りリクエストはバックオフとリトライに255ミリ秒を費やしています。 - - region_id: 読み取り要求のターゲット キーに対応するリージョンID。 + - txnStartTS: 読み取り要求を送信しているトランザクションのstart_ts。上記のログでは、 `416643508703592451`がstart_tsです。 + - backoff_types: 読み取り/書き込み競合が発生し、読み取り要求がバックオフと再試行を実行する場合、再試行のタイプは`TxnLockFast`なります。 + - backoff_ms: 読み取りリクエストがバックオフとリトライに要した時間。単位はミリ秒です。上記のログでは、読み取りリクエストはバックオフとリトライに255ミリ秒を費やしています。 + - region_id: 読み取り要求のターゲット キーに対応するリージョンID。 -2. TiKVサーバーのログ +2. TiKVサーバーのログ 読み取り/書き込みの競合がある場合は、TiKV ログに次のメッセージが表示されます。 @@ -202,17 +202,17 @@ TiDB クラスター内の読み取り/書き込み競合は、次の方法で このメッセージは、TiDBで読み取り/書き込み競合が発生したことを示しています。読み取り要求のターゲットキーは別のトランザクションによってロックされています。ロックは、コミットされていない楽観的トランザクションと、プリライトフェーズ後のコミットされていない悲観的トランザクションによって発生しています。 - - primary_lock: ターゲット キーがプライマリ ロックによってロックされていることを示します。 - - lock_version: ロックを所有するトランザクションの start_ts。 - - key: ロックされる対象キー。 - - lock_ttl: ロックの TTL (Time To Live) - - txn_size: ロックを所有するトランザクションのリージョン内にあるキーの数。 + - primary_lock: ターゲット キーがプライマリ ロックによってロックされていることを示します。 + - lock_version: ロックを所有するトランザクションの start_ts。 + - key: ロックされる対象キー。 + - lock_ttl: ロックの TTL (Time To Live) + - txn_size: ロックを所有するトランザクションのリージョン内にあるキーの数。 解決策: -- 読み取り/書き込み競合が発生すると、自動的にバックオフと再試行が実行されます。上記の例のように、Txn1 にはバックオフと再試行が適用されます。再試行の初回時間は10ミリ秒、最長は3000ミリ秒、合計時間は最大20000ミリ秒です。 +- 読み取り/書き込み競合が発生すると、自動的にバックオフと再試行が実行されます。上記の例のように、Txn1 にはバックオフと再試行が適用されます。再試行の初回時間は10ミリ秒、最長は3000ミリ秒、合計時間は最大20000ミリ秒です。 -- TiDB コントロールのサブコマンド[`decoder`](/tidb-control.md#the-decoder-command)を使用して、指定したキーに対応する行のテーブル ID と行 ID を表示できます。 +- TiDB コントロールのサブコマンド[`decoder`](/tidb-control.md#the-decoder-command)を使用して、指定したキーに対応する行のテーブル ID と行 ID を表示できます。 ```sh ./tidb-ctl decoder "t\x00\x00\x00\x00\x00\x00\x00\x1c_r\x00\x00\x00\x00\x00\x00\x00\xfa" @@ -233,9 +233,9 @@ TiDBダッシュボードの`KV Errors`パネルには、トランザクショ 解決策: -- 監視中にtxnLockが少量発生しても、あまり気にする必要はありません。バックオフとリトライはバックグラウンドで自動的に実行されます。リトライの初回は100ミリ秒、最大1回のリトライ時間は3000ミリ秒です。 -- `KV Backoff OPS`に「txnLock」操作が多すぎる場合は、アプリケーション側から書き込み競合の原因を分析することをお勧めします。 -- アプリケーションで書き込み-書き込み競合が発生するシナリオの場合は、悲観的トランザクション モードを使用することを強くお勧めします。 +- 監視中にtxnLockが少量発生しても、あまり気にする必要はありません。バックオフとリトライはバックグラウンドで自動的に実行されます。リトライの初回は100ミリ秒、最大1回のリトライ時間は3000ミリ秒です。 +- `KV Backoff OPS`に「txnLock」操作が多すぎる場合は、アプリケーション側から書き込み競合の原因を分析することをお勧めします。 +- アプリケーションで書き込み-書き込み競合が発生するシナリオの場合は、悲観的トランザクション モードを使用することを強くお勧めします。 ### LockNotFoundエラー {#locknotfound-error} @@ -243,7 +243,7 @@ TiDBダッシュボードの`KV Errors`パネルには、トランザクショ 「LockNotFound」エラーがあるかどうかは、次の方法で確認できます。 -1. TiDBサーバーのログを確認する +1. TiDBサーバーのログを確認する 「TxnLockNotFound」エラーが発生した場合、TiDB ログ メッセージは次のようになります。 @@ -251,10 +251,10 @@ TiDBダッシュボードの`KV Errors`パネルには、トランザクショ [WARN] [session.go:446] ["commit failed"] [conn=149370] ["finished txn"="Txn{state=invalid}"] [error="[kv:6]Error: KV error safe to retry tikv restarts txn: Txn(Mvcc(TxnLockNotFound{ start_ts: 412720515987275779, commit_ts: 412720519984971777, key: [116, 128, 0, 0, 0, 0, 1, 111, 16, 95, 114, 128, 0, 0, 0, 0, 0, 0, 2] })) [try again later]"] ``` - - start_ts: 他のトランザクションによってロックがロールバックされたためにエラー`TxnLockNotFound`を出力したトランザクションのstart_ts。上記のログでは、 `412720515987275779`がstart_tsです。 - - commit_ts: エラー`TxnLockNotFound`を出力したトランザクションのcommit_ts。上記のログでは、 `412720519984971777`がcommit_tsです。 + - start_ts: 他のトランザクションによってロックがロールバックされたためにエラー`TxnLockNotFound`を出力したトランザクションのstart_ts。上記のログでは、 `412720515987275779`がstart_tsです。 + - commit_ts: エラー`TxnLockNotFound`を出力したトランザクションのcommit_ts。上記のログでは、 `412720519984971777`がcommit_tsです。 -2. TiKVサーバーのログを確認する +2. TiKVサーバーのログを確認する 「TxnLockNotFound」エラーが発生した場合、TiKV ログ メッセージは次のようになります。 @@ -264,7 +264,7 @@ TiDBダッシュボードの`KV Errors`パネルには、トランザクショ 解決策: -- start_ts と commit_ts 間の時間間隔を確認することで、コミット時間が TTL 時間を超えているかどうかを確認できます。 +- start_ts と commit_ts 間の時間間隔を確認することで、コミット時間が TTL 時間を超えているかどうかを確認できます。 PD 制御ツールを使用して時間間隔を確認します。 @@ -273,9 +273,9 @@ TiDBダッシュボードの`KV Errors`パネルには、トランザクショ tiup ctl:v pd tso [commit_ts] ``` -- 書き込みパフォーマンスが遅いかどうかをチェックすることをお勧めします。書き込みパフォーマンスが遅いと、トランザクションのコミットの効率が低下し、ロックがクリアされる可能性があります。 +- 書き込みパフォーマンスが遅いかどうかをチェックすることをお勧めします。書き込みパフォーマンスが遅いと、トランザクションのコミットの効率が低下し、ロックがクリアされる可能性があります。 -- TiDB トランザクションの再試行を無効にする場合は、アプリケーション側で例外をキャッチして再試行する必要があります。 +- TiDB トランザクションの再試行を無効にする場合は、アプリケーション側で例外をキャッチして再試行する必要があります。 ## 悲観的ロックの競合のトラブルシューティング {#troubleshoot-pessimistic-lock-conflicts} @@ -303,8 +303,8 @@ err="pessimistic lock retry limit reached" 解決策: -- 上記エラーが頻繁に発生する場合は、アプリケーション側からの調整をお勧めします。 -- 同一行（同一キー）への同時ロックが多く、頻繁に競合が発生する業務の場合は、システム変数[`tidb_pessimistic_txn_fair_locking`](/system-variables.md#tidb_pessimistic_txn_fair_locking-new-in-v700)の有効化を検討してください。ただし、この変数を有効にすると、ロック競合が発生するトランザクションのスループット低下（平均レイテンシーの増加）が多少発生する可能性がある点にご注意ください。新規に導入されたクラスターでは、この変数はデフォルトで有効化（ `ON` ）されています。 +- 上記エラーが頻繁に発生する場合は、アプリケーション側からの調整をお勧めします。 +- 同一行（同一キー）への同時ロックが多く、頻繁に競合が発生する業務の場合は、システム変数[`tidb_pessimistic_txn_fair_locking`](/system-variables.md#tidb_pessimistic_txn_fair_locking-new-in-v700)の有効化を検討してください。ただし、この変数を有効にすると、ロック競合が発生するトランザクションのスループット低下（平均レイテンシーの増加）が多少発生する可能性がある点にご注意ください。新規に導入されたクラスターでは、この変数はデフォルトで有効化（ `ON` ）されています。 ### ロック待機タイムアウトを超えました {#lock-wait-timeout-exceeded} @@ -318,7 +318,7 @@ ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction 解決策: -- 上記のエラーが頻繁に発生する場合は、アプリケーションロジックを調整することをお勧めします。 +- 上記のエラーが頻繁に発生する場合は、アプリケーションロジックを調整することをお勧めします。 ### TTLマネージャがタイムアウトしました {#ttl-manager-has-timed-out} @@ -332,8 +332,8 @@ TTL manager has timed out, pessimistic locks may expire, please commit or rollba 解決策: -- まず、アプリケーションロジックを最適化できるかどうかを確認します。例えば、大規模なトランザクションはTiDBのトランザクションサイズ制限に達する可能性があり、それを複数の小さなトランザクションに分割できます。 -- また、アプリケーションのトランザクション ロジックに合わせて関連パラメータを適切に調整することもできます。 +- まず、アプリケーションロジックを最適化できるかどうかを確認します。例えば、大規模なトランザクションはTiDBのトランザクションサイズ制限に達する可能性があり、それを複数の小さなトランザクションに分割できます。 +- また、アプリケーションのトランザクション ロジックに合わせて関連パラメータを適切に調整することもできます。 ### ロックを取得しようとしたときにデッドロックが見つかりました {#deadlock-found-when-trying-to-get-lock} @@ -347,5 +347,5 @@ TTL manager has timed out, pessimistic locks may expire, please commit or rollba 解決策: -- デッドロックの原因を確認するのが難しい場合は、v5.1以降のバージョンでは、 `INFORMATION_SCHEMA.DEADLOCKS`または`INFORMATION_SCHEMA.CLUSTER_DEADLOCKS`システムテーブルをクエリして、デッドロック待機チェーンの情報を取得することをお勧めします。詳細については、 [デッドロックエラー](#deadlock-errors)セクションと[`DEADLOCKS`テーブル](/information-schema/information-schema-deadlocks.md)ドキュメントを参照してください。 -- デッドロックが頻繁に発生する場合は、そのような発生を減らすために、アプリケーション内のトランザクション クエリ ロジックを調整する必要があります。 +- デッドロックの原因を確認するのが難しい場合は、v5.1以降のバージョンでは、 `INFORMATION_SCHEMA.DEADLOCKS`または`INFORMATION_SCHEMA.CLUSTER_DEADLOCKS`システムテーブルをクエリして、デッドロック待機チェーンの情報を取得することをお勧めします。詳細については、 [デッドロックエラー](#deadlock-errors)セクションと[`DEADLOCKS`テーブル](/information-schema/information-schema-deadlocks.md)ドキュメントを参照してください。 +- デッドロックが頻繁に発生する場合は、そのような発生を減らすために、アプリケーション内のトランザクション クエリ ロジックを調整する必要があります。 diff --git a/troubleshoot-stale-read.md b/troubleshoot-stale-read.md index 7657c5b8858e1..4b45b656e83ea 100644 --- a/troubleshoot-stale-read.md +++ b/troubleshoot-stale-read.md @@ -55,9 +55,9 @@ resolved-ts は、この値より小さいタイムスタンプを持つすべ ステイル読み取りの有効性に影響を及ぼす最も一般的な原因は次のとおりです。 -- コミットに長い時間を要するトランザクション。 -- トランザクションがコミットされるまでの期間が長すぎます。 -- CheckLeader の情報をリーダーからフォロワーにプッシュする際の遅延。 +- コミットに長い時間を要するトランザクション。 +- トランザクションがコミットされるまでの期間が長すぎます。 +- CheckLeader の情報をリーダーからフォロワーにプッシュする際の遅延。 ### Grafanaを使って診断する {#use-grafana-to-diagnose} @@ -96,17 +96,17 @@ Resolver: 上記の出力は、次のことを判断するのに役立ちます。 -- ロックがresolved-tsをブロックしているかどうか。 -- 適用インデックスが小さすぎて safe-ts を更新できないかどうか。 -- フォロワー ピアが存在する場合に、リーダーが十分に更新されたresolved-tsを送信しているかどうか。 +- ロックがresolved-tsをブロックしているかどうか。 +- 適用インデックスが小さすぎて safe-ts を更新できないかどうか。 +- フォロワー ピアが存在する場合に、リーダーが十分に更新されたresolved-tsを送信しているかどうか。 ### ログを使用して診断する {#use-logs-to-diagnose} TiKV は 10 秒ごとに次のメトリックをチェックします。 -- resolved-tsが最小であるリージョンリーダー -- safe-tsが最小のリージョンフォロワー -- resolved-tsが最小であるリージョンフォロワー +- resolved-tsが最小であるリージョンリーダー +- safe-tsが最小のリージョンフォロワー +- resolved-tsが最小であるリージョンフォロワー これらのタイムスタンプのいずれかが異常に小さい場合、TiKV はログを出力します。 @@ -130,9 +130,9 @@ TiKV は 10 秒ごとに次のメトリックをチェックします。 以下に実行できるアクションをいくつか示します。 -- `tikv-ctl`コマンドで`--log`オプションを指定し、TiKV ログをチェックして、start_ts を持つ特定のロックを見つけます。 +- `tikv-ctl`コマンドで`--log`オプションを指定し、TiKV ログをチェックして、start_ts を持つ特定のロックを見つけます。 -- トランザクションの問題を特定するには、TiDB ログと TiKV ログの両方で start_ts を検索します。 +- トランザクションの問題を特定するには、TiDB ログと TiKV ログの両方で start_ts を検索します。 クエリの実行時間が60秒を超える場合、SQL文に`expensive_query`ログが出力されます。start_tsの値を使用して、ログと一致させることができます。以下に例を示します。 @@ -140,9 +140,9 @@ TiKV は 10 秒ごとに次のメトリックをチェックします。 [2023/07/17 19:32:09.403 +08:00] [WARN] [expensivequery.go:145] [expensive_query] [cost_time=60.025022732s] [cop_time=0.00346666s] [process_time=8.358409508s] [wait_time=0.013582596s] [request_count=278] [total_keys=9943616] [process_keys=9943360] [num_cop_tasks=278] [process_avg_time=0.030066221s] [process_p90_time=0.045296042s] [process_max_time=0.052828934s] [process_max_addr=192.168.31.244:20160] [wait_avg_time=0.000048858s] [wait_p90_time=0.00006057s] [wait_max_time=0.00040991s] [wait_max_addr=192.168.31.244:20160] [stats=t:442916666913587201] [conn=2826881778407440457] [user=root] [database=test] [table_ids="[100]"] [**txn_start_ts**=442916790435840001] [mem_max="2514229289 Bytes (2.34 GB)"] [sql="update t set b = b + 1"] ``` -- ログからロックに関する十分な情報を取得できない場合は、テーブル[`CLUSTER_TIDB_TRX`](/information-schema/information-schema-tidb-trx.md#cluster_tidb_trx)を使用してアクティブなトランザクションを見つけます。 +- ログからロックに関する十分な情報を取得できない場合は、テーブル[`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は表示されません。 進行中の大規模トランザクションが原因でロックが存在する場合は、これらのロックによって解決の進行が妨げられる可能性があるため、アプリケーション ロジックの変更を検討してください。 @@ -154,11 +154,11 @@ TiKV は 10 秒ごとに次のメトリックをチェックします。 この問題に対処するには: -- トランザクションの特定：まず、ロックに関連するトランザクションを特定します。ロックが存在する理由を理解することが重要です。ログを活用すると特に役立ちます。 +- トランザクションの特定：まず、ロックに関連するトランザクションを特定します。ロックが存在する理由を理解することが重要です。ログを活用すると特に役立ちます。 -- アプリケーション ロジックを調べる: トランザクションの所要時間が長くなっている原因がアプリケーションのロジックにある場合は、そのような事態が発生しないようにロジックを修正することを検討してください。 +- アプリケーション ロジックを調べる: トランザクションの所要時間が長くなっている原因がアプリケーションのロジックにある場合は、そのような事態が発生しないようにロジックを修正することを検討してください。 -- スロークエリに対処する: スロークエリが原因でトランザクションの期間が長くなる場合は、これらのクエリの解決を優先して問題を軽減します。 +- スロークエリに対処する: スロークエリが原因でトランザクションの期間が長くなる場合は、これらのクエリの解決を優先して問題を軽減します。 ### CheckLeaderの問題に対処する {#address-checkleader-issues} diff --git a/troubleshoot-tidb-cluster.md b/troubleshoot-tidb-cluster.md index 8924fc884e818..b2985ae86cf18 100644 --- a/troubleshoot-tidb-cluster.md +++ b/troubleshoot-tidb-cluster.md @@ -7,71 +7,71 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 このガイドは、TiDBの使用中に発生する基本的な問題の診断と解決に役立ちます。問題が解決しない場合は、以下の情報を収集して、 [バグを報告する](/support.md) . -- 正確なエラーメッセージとエラー発生時の操作 -- すべてのコンポーネントの状態 -- エラーを報告するコンポーネントのログ内の`error` / `fatal` / `panic`情報 -- 構成と展開トポロジ -- `dmesg`のTiDBコンポーネント関連の問題 +- 正確なエラーメッセージとエラー発生時の操作 +- すべてのコンポーネントの状態 +- エラーを報告するコンポーネントのログ内の`error` / `fatal` / `panic`情報 +- 構成と展開トポロジ +- `dmesg`のTiDBコンポーネント関連の問題 その他の情報については[よくある質問（FAQ）](/faq/tidb-faq.md)を参照してください。 ## データベースに接続できません {#cannot-connect-to-the-database} -1. `tidb-server` 、 `pd-server` 、 `tikv-server`を含むすべてのサービスが開始されていることを確認します +1. `tidb-server` 、 `pd-server` 、 `tikv-server`を含むすべてのサービスが開始されていることを確認します -2. `ps`コマンドを使用して、すべてのプロセスが実行中かどうかを確認します。 +2. `ps`コマンドを使用して、すべてのプロセスが実行中かどうかを確認します。 - - 特定のプロセスが実行されていない場合は、次の対応するセクションを参照して問題を診断し、解決してください。 + - 特定のプロセスが実行されていない場合は、次の対応するセクションを参照して問題を診断し、解決してください。 - - すべてのプロセスが実行中の場合は、 `tidb-server`ログをチェックして、次のメッセージが表示されているかどうかを確認します。 - - 情報スキーマが古くなっています: `tikv-server`に接続できない場合にこのメッセージが表示されます。`pd-server`と`tikv-server`の状態とログを確認してください。 - - panic：プログラムに問題が発生した場合、このメッセージが表示されます。詳細なpanicログをご提供いただければ、 [バグを報告する](/support.md) . + - すべてのプロセスが実行中の場合は、 `tidb-server`ログをチェックして、次のメッセージが表示されているかどうかを確認します。 + - 情報スキーマが古くなっています: `tikv-server`に接続できない場合にこのメッセージが表示されます。`pd-server`と`tikv-server`の状態とログを確認してください。 + - panic：プログラムに問題が発生した場合、このメッセージが表示されます。詳細なpanicログをご提供いただければ、 [バグを報告する](/support.md) . -3. データがクリアされ、サービスが再デプロイされる場合は、次の点を確認してください。 +3. データがクリアされ、サービスが再デプロイされる場合は、次の点を確認してください。 - - `tikv-server`と`pd-server`のデータはすべてクリアされます。特定のデータは`tikv-server`に保存され、メタデータは`pd-server`に保存されます。2つのサーバーのうち1つだけがクリアされると、データの整合性が失われます。 - - `pd-server`と`tikv-server`のデータがクリアされ、 `pd-server`と`tikv-server`再起動された後、 `tidb-server`も再起動する必要があります。クラスタIDは`pd-server`初期化される際にランダムに割り当てられます。そのため、クラスタが再デプロイされるとクラスタIDが変更され、新しいクラスタIDを取得するには`tidb-server`再起動する必要があります。 + - `tikv-server`と`pd-server`のデータはすべてクリアされます。特定のデータは`tikv-server`に保存され、メタデータは`pd-server`に保存されます。2つのサーバーのうち1つだけがクリアされると、データの整合性が失われます。 + - `pd-server`と`tikv-server`のデータがクリアされ、 `pd-server`と`tikv-server`再起動された後、 `tidb-server`も再起動する必要があります。クラスタIDは`pd-server`初期化される際にランダムに割り当てられます。そのため、クラスタが再デプロイされるとクラスタIDが変更され、新しいクラスタIDを取得するには`tidb-server`再起動する必要があります。 ## `tidb-server`を起動できません {#cannot-start-tidb-server} `tidb-server`起動できない場合の状況については以下を参照してください。 -- 起動パラメータにエラーがあります。 +- 起動パラメータにエラーがあります。 [TiDB の構成とオプション](/command-line-flags-for-tidb-configuration.md)を参照してください。 -- ポートが使用中です。 +- ポートが使用中です。 `lsof -i:port`コマンドを使用して、特定のポートに関連するすべてのネットワークを表示し、 `tidb-server`開始するポートが使用されていないことを確認します。 -- `pd-server`に接続できません。 +- `pd-server`に接続できません。 - - TiDB と PD 間のネットワークがスムーズに動作しているかどうか、ネットワークに ping できるかどうか、ファイアウォールの構成に問題があるかどうかなどを確認します。 - - ネットワークに問題がない場合は、 `pd-server`プロセスの状態とログを確認します。 + - TiDB と PD 間のネットワークがスムーズに動作しているかどうか、ネットワークに ping できるかどうか、ファイアウォールの構成に問題があるかどうかなどを確認します。 + - ネットワークに問題がない場合は、 `pd-server`プロセスの状態とログを確認します。 ## `tikv-server`を起動できません {#cannot-start-tikv-server} `tikv-server`起動できない場合の状況については以下を参照してください。 -- 起動パラメータのエラー: [TiKVの設定とオプション](/command-line-flags-for-tikv-configuration.md)を参照してください。 +- 起動パラメータのエラー: [TiKVの設定とオプション](/command-line-flags-for-tikv-configuration.md)を参照してください。 -- ポートが使用中です: `lsof -i:port`コマンドを使用して、特定のポートに関連するすべてのネットワークを表示し、 `tikv-server`開始するポートが使用されていないことを確認します。 +- ポートが使用中です: `lsof -i:port`コマンドを使用して、特定のポートに関連するすべてのネットワークを表示し、 `tikv-server`開始するポートが使用されていないことを確認します。 -- `pd-server`に接続できません。 +- `pd-server`に接続できません。 - - TiDB と PD 間のネットワークがスムーズに動作しているかどうか、ネットワークに ping できるかどうか、ファイアウォールの構成に問題があるかどうかなどを確認します。 + - TiDB と PD 間のネットワークがスムーズに動作しているかどうか、ネットワークに ping できるかどうか、ファイアウォールの構成に問題があるかどうかなどを確認します。 - - ネットワークに問題がない場合は、 `pd-server`プロセスの状態とログを確認します。 + - ネットワークに問題がない場合は、 `pd-server`プロセスの状態とログを確認します。 -- ファイルは使用中です。 +- ファイルは使用中です。 1 つのデータベース ファイル ディレクトリで 2 つの TiKV ファイルを開かないでください。 @@ -79,19 +79,19 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 `pd-server`起動できない場合の状況については以下を参照してください。 -- 起動パラメータにエラーがあります。 +- 起動パラメータにエラーがあります。 [PD構成とオプション](/command-line-flags-for-pd-configuration.md)を参照してください。 -- ポートが使用中です。 +- ポートが使用中です。 `lsof -i:port`コマンドを使用して、特定のポートに関連するすべてのネットワークを表示し、 `pd-server`開始するポートが使用されていないことを確認します。 ## TiDB/TiKV/PDプロセスが予期せず中止される {#the-tidb-tikv-pd-process-aborts-unexpectedly} -- プロセスはフォアグラウンドで開始されていますか? クライアントが中止したためにプロセスが終了する可能性があります。 +- プロセスはフォアグラウンドで開始されていますか? クライアントが中止したためにプロセスが終了する可能性があります。 -- `nohup+&`コマンドラインで実行されていますか？hup シグナルを受信するため、プロセスが中止される可能性があります。起動コマンドはスクリプトで記述して実行することをお勧めします。 +- `nohup+&`コマンドラインで実行されていますか？hup シグナルを受信するため、プロセスが中止される可能性があります。起動コマンドはスクリプトで記述して実行することをお勧めします。 ## TiDB panic {#tidb-panic} @@ -101,8 +101,8 @@ panicログをご提供いただければ、 [バグを報告する](/support.md オペレーティング システムのネットワーク パラメータが正しいことを確認します。これには以下が含まれますが、これらに限定されません。 -- 接続文字列内のポートは、開始ポート`tidb-server`と一致します。 -- ファイアウォールは正しく設定されています。 +- 接続文字列内のポートは、開始ポート`tidb-server`と一致します。 +- ファイアウォールは正しく設定されています。 ## 開いているファイルが多すぎる {#open-too-many-files} @@ -114,22 +114,22 @@ panicログをご提供いただければ、 [バグを報告する](/support.md 問題を解決できなかった場合は、次の情報を提供してください。 -- 展開トポロジ +- 展開トポロジ - - `tidb-server` / `pd-server` / `tikv-server`インスタンスはいくつデプロイされていますか? - - これらのインスタンスはマシン内でどのように分散されるのでしょうか? + - `tidb-server` / `pd-server` / `tikv-server`インスタンスはいくつデプロイされていますか? + - これらのインスタンスはマシン内でどのように分散されるのでしょうか? -- これらのインスタンスがデプロイされているマシンのハードウェア構成: +- これらのインスタンスがデプロイされているマシンのハードウェア構成: - - CPUコアの数 - - メモリのサイズ - - ディスクの種類（SSD またはハードドライブディスク） - - それらは物理マシンですか、それとも仮想マシンですか? + - CPUコアの数 + - メモリのサイズ + - ディスクの種類（SSD またはハードドライブディスク） + - それらは物理マシンですか、それとも仮想マシンですか? -- TiDB クラスター以外のサービスはありますか? -- `pd-server`と`tikv-server`は別々に展開されますか? -- 現在の操作は何ですか? -- `top -H`コマンドを使用して CPU スレッド名を確認します。 -- 最近、ネットワークまたは IO 監視データに例外はありますか? +- TiDB クラスター以外のサービスはありますか? +- `pd-server`と`tikv-server`は別々に展開されますか? +- 現在の操作は何ですか? +- `top -H`コマンドを使用して CPU スレッド名を確認します。 +- 最近、ネットワークまたは IO 監視データに例外はありますか? diff --git a/troubleshoot-tidb-oom.md b/troubleshoot-tidb-oom.md index 4a4de468c76fe..947e84253bb1a 100644 --- a/troubleshoot-tidb-oom.md +++ b/troubleshoot-tidb-oom.md @@ -11,22 +11,22 @@ summary: TiDB OOM (メモリ不足) の問題を診断して解決する方法 以下に、典型的な OOM 現象をいくつか示します。 -- クライアント側で次のエラーが報告されます: `SQL error, errno = 2013, state = 'HY000': Lost connection to MySQL server during query` 。 +- クライアント側で次のエラーが報告されます: `SQL error, errno = 2013, state = 'HY000': Lost connection to MySQL server during query` 。 -- Grafana ダッシュボードには次の内容が表示されます。 - - **TiDB** >**Server**>**メモリ使用量**では、 `process/heapInUse`メトリックが上昇し続け、しきい値に達した後、突然 0 に低下することが示されています。 - - **TiDB** >**Server**>**稼働時間**が突然ゼロに低下します。 - - **TiDB-Runtime** >**メモリ使用量**では、 `estimate-inuse`メトリックが上昇し続けていることがわかります。 +- Grafana ダッシュボードには次の内容が表示されます。 + - **TiDB** >**Server**>**メモリ使用量**では、 `process/heapInUse`メトリックが上昇し続け、しきい値に達した後、突然 0 に低下することが示されています。 + - **TiDB** >**Server**>**稼働時間**が突然ゼロに低下します。 + - **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)を参照してください。 - - 再起動に関するログエントリ: `[INFO] [printer.go:33] ["Welcome to TiDB."]` 。 +- `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)を参照してください。 + - 再起動に関するログエントリ: `[INFO] [printer.go:33] ["Welcome to TiDB."]` 。 ## 全体的なトラブルシューティングプロセス {#overall-troubleshooting-process} OOM の問題をトラブルシューティングする場合は、次のプロセスに従います。 -1. OOM の問題であるかどうかを確認します。 +1. OOM の問題であるかどうかを確認します。 以下のコマンドを実行して、オペレーティングシステムのログを確認します。問題が発生した時刻付近に`oom-killer`ログがある場合は、OOMの問題であることが確認できます。 @@ -49,13 +49,13 @@ OOM の問題をトラブルシューティングする場合は、次のプロ ...... ``` -2. OOM の問題であることを確認した後、OOM の原因がデプロイメントによるものかデータベースによるものかをさらに調査できます。 +2. OOM の問題であることを確認した後、OOM の原因がデプロイメントによるものかデータベースによるものかをさらに調査できます。 - - OOM が展開の問題によって発生した場合は、リソース構成とハイブリッド展開の影響を調査する必要があります。 - - OOM がデータベースの問題によって発生した場合、次のような原因が考えられます。 - - TiDB は、大規模なクエリ、大規模な書き込み、データのインポートなどの大規模なデータ トラフィックを処理します。 - - TiDB は、複数の SQL ステートメントが同時にリソースを消費したり、オペレーターの同時実行性が高くなったりする、同時実行性の高いシナリオです。 - - TiDB にメモリリークがあり、リソースが解放されません。 + - OOM が展開の問題によって発生した場合は、リソース構成とハイブリッド展開の影響を調査する必要があります。 + - OOM がデータベースの問題によって発生した場合、次のような原因が考えられます。 + - TiDB は、大規模なクエリ、大規模な書き込み、データのインポートなどの大規模なデータ トラフィックを処理します。 + - TiDB は、複数の SQL ステートメントが同時にリソースを消費したり、オペレーターの同時実行性が高くなったりする、同時実行性の高いシナリオです。 + - TiDB にメモリリークがあり、リソースが解放されません。 具体的なトラブルシューティング方法については、次のセクションを参照してください。 @@ -63,17 +63,17 @@ OOM の問題をトラブルシューティングする場合は、次のプロ OOM の問題は通常、次の原因で発生します。 -- [展開の問題](#deployment-issues) -- [データベースの問題](#database-issues) -- [クライアント側の問題](#client-side-issues) +- [展開の問題](#deployment-issues) +- [データベースの問題](#database-issues) +- [クライアント側の問題](#client-side-issues) ### 展開の問題 {#deployment-issues} 不適切な展開による OOM の原因は次のとおりです。 -- オペレーティング システムのメモリ容量が小さすぎます。 -- TiUP構成[`resource_control`](/tiup/tiup-cluster-topology-reference.md#global)は適切ではありません。 -- ハイブリッド デプロイメント (つまり、TiDB と他のアプリケーションが同じサーバーにデプロイされている) の場合、リソース不足により、TiDB が`oom-killer`によって誤って強制終了されることがあります。 +- オペレーティング システムのメモリ容量が小さすぎます。 +- TiUP構成[`resource_control`](/tiup/tiup-cluster-topology-reference.md#global)は適切ではありません。 +- ハイブリッド デプロイメント (つまり、TiDB と他のアプリケーションが同じサーバーにデプロイされている) の場合、リソース不足により、TiDB が`oom-killer`によって誤って強制終了されることがあります。 ### データベースの問題 {#database-issues} @@ -87,21 +87,21 @@ OOM の問題は通常、次の原因で発生します。 OOM 問題のさまざまな原因に応じて、SQL ステートメントのメモリ使用量を削減するために次の対策を講じることができます。 -- SQL実行計画が最適でない場合（適切なインデックスの欠如、古い統計情報、オプティマイザのバグなど）、誤ったSQL実行計画が選択される可能性があり、その結果、膨大な中間結果セットがメモリに蓄積されます。このような場合は、以下の対策を検討してください。 - - 適切なインデックスを追加します。 - - 実行演算子には[ディスクスピル](/configure-memory-usage.md#disk-spill)機能を使用します。 - - テーブル間の JOIN 順序を調整します。 - - ヒントを使用して SQL ステートメントを最適化します。 +- SQL実行計画が最適でない場合（適切なインデックスの欠如、古い統計情報、オプティマイザのバグなど）、誤ったSQL実行計画が選択される可能性があり、その結果、膨大な中間結果セットがメモリに蓄積されます。このような場合は、以下の対策を検討してください。 + - 適切なインデックスを追加します。 + - 実行演算子には[ディスクスピル](/configure-memory-usage.md#disk-spill)機能を使用します。 + - テーブル間の JOIN 順序を調整します。 + - ヒントを使用して SQL ステートメントを最適化します。 -- 一部の演算子と関数はストレージレベルへのプッシュダウンがサポートされていないため、中間結果セットが大量に蓄積されます。このような場合は、SQL文を修正するか、ヒントを使用して最適化し、プッシュダウンをサポートする関数または演算子を使用する必要があります。 +- 一部の演算子と関数はストレージレベルへのプッシュダウンがサポートされていないため、中間結果セットが大量に蓄積されます。このような場合は、SQL文を修正するか、ヒントを使用して最適化し、プッシュダウンをサポートする関数または演算子を使用する必要があります。 -- 実行計画にはHashAgg演算子が含まれています。HashAggは複数のスレッドで同時に実行されるため、高速ですがメモリ消費量は多くなります。代わりに`STREAM_AGG()`を使用することもできます。 +- 実行計画にはHashAgg演算子が含まれています。HashAggは複数のスレッドで同時に実行されるため、高速ですがメモリ消費量は多くなります。代わりに`STREAM_AGG()`を使用することもできます。 -- 同時実行数の増加によるメモリ問題を回避するには、同時に読み取る領域の数を減らすか、演算子の同時実行数を減らしてください。対応するシステム変数は次のとおりです。 - - [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) - - [`tidb_executor_concurrency`](/system-variables.md#tidb_executor_concurrency-new-in-v50) +- 同時実行数の増加によるメモリ問題を回避するには、同時に読み取る領域の数を減らすか、演算子の同時実行数を減らしてください。対応するシステム変数は次のとおりです。 + - [`tidb_distsql_scan_concurrency`](/system-variables.md#tidb_distsql_scan_concurrency) + - [`tidb_executor_concurrency`](/system-variables.md#tidb_executor_concurrency-new-in-v50) -- 問題発生時点付近では、セッションの同時実行性が高すぎます。この場合は、TiDBノードを追加してTiDBクラスターをスケールアウトすることを検討してください。 +- 問題発生時点付近では、セッションの同時実行性が高すぎます。この場合は、TiDBノードを追加してTiDBクラスターをスケールアウトすることを検討してください。 #### 大規模なトランザクションや大規模な書き込みはメモリを大量に消費します {#large-transactions-or-large-writes-consume-too-much-memory} @@ -113,9 +113,9 @@ 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 が統計を更新するときに最大メモリ使用量を制御できます。 +- サンプリング レートを指定し、特定の列の統計情報のみを収集し、`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 が統計を更新するときに最大メモリ使用量を制御できます。 詳細については[統計入門](/statistics.md)を参照してください。 @@ -125,9 +125,9 @@ TiDBノードは起動後、統計情報をメモリに読み込む必要があ この問題を解決するには、次の対策を検討してください。 -- セッションのライフサイクルを調整します。 -- [接続プールの`wait_timeout`と`max_execution_time`](/develop/dev-guide-connection-parameters.md#timeout-related-parameters)を調整します。 -- システム変数[`max_prepared_stmt_count`](/system-variables.md#max_prepared_stmt_count)を使用して、セッションで準備されるステートメントの最大数を制御します。 +- セッションのライフサイクルを調整します。 +- [接続プールの`wait_timeout`と`max_execution_time`](/develop/dev-guide-connection-parameters.md#timeout-related-parameters)を調整します。 +- システム変数[`max_prepared_stmt_count`](/system-variables.md#max_prepared_stmt_count)を使用して、セッションで準備されるステートメントの最大数を制御します。 #### `tidb_enable_rate_limit_action`が正しく設定されていません {#tidb-enable-rate-limit-action-is-not-configured-properly} @@ -139,53 +139,53 @@ TiDBノードは起動後、統計情報をメモリに読み込む必要があ クライアント側で OOM が発生した場合は、次の点を調査します。 -- **Grafana TiDB Details** > **Server** > **Client Data Traffic**で傾向と速度を確認し、ネットワークのブロックがあるかどうかを確認します。 -- 誤ったJDBC設定パラメータによってアプリケーションのOOMが発生していないか確認してください。例えば、ストリーミング読み取りのパラメータ`defaultFetchSize`が正しく設定されていない場合、クライアント側に大量のデータが蓄積される可能性があります。 +- **Grafana TiDB Details** > **Server** > **Client Data Traffic**で傾向と速度を確認し、ネットワークのブロックがあるかどうかを確認します。 +- 誤ったJDBC設定パラメータによってアプリケーションのOOMが発生していないか確認してください。例えば、ストリーミング読み取りのパラメータ`defaultFetchSize`が正しく設定されていない場合、クライアント側に大量のデータが蓄積される可能性があります。 ## OOM の問題をトラブルシューティングするために収集される診断情報 {#diagnostic-information-to-be-collected-to-troubleshoot-oom-issues} OOM 問題の根本原因を特定するには、次の情報を収集する必要があります。 -- オペレーティング システムのメモリ関連の構成を収集します。 - - TiUP構成: `resource_control.memory_limit` - - オペレーティング システムの構成: - - メモリ情報: `cat /proc/meminfo` - - カーネルパラメータ: `vm.overcommit_memory` - - NUMA情報: - - `numactl --hardware` - - `numactl --show` - -- データベースのバージョン情報とメモリ関連の構成を収集します。 - - TiDBバージョン - - `tidb_mem_quota_query` - - `memory-usage-alarm-ratio` - - `mem-quota-query` - - `oom-action` - - `tidb_enable_rate_limit_action` - - `tidb_server_memory_limit` - - `oom-use-tmp-storage` - - `tmp-storage-path` - - `tmp-storage-quota` - - `tidb_analyze_version` - -- Grafana ダッシュボードで TiDBメモリの毎日の使用量を確認します: **TiDB** > **Server** > **Memory Usage** 。 - -- より多くのメモリを消費する SQL ステートメントを確認します。 - - - TiDB Dashboardで、SQL ステートメントの分析、スロークエリ、メモリ使用量を確認する。 - - `INFORMATION_SCHEMA`の`SLOW_QUERY`と`CLUSTER_SLOW_QUERY`を確認してください。 - - 各 TiDB ノードで`tidb_slow_query.log`をチェックします。 - - `grep "expensive_query" tidb.log`を実行して、対応するログ エントリを確認します。 - - `EXPLAIN ANALYZE`を実行して、演算子のメモリ使用量を確認します。 - - `SELECT * FROM information_schema.processlist;`を実行して`MEM`列の値を確認します。 - -- メモリ使用量が多いときに TiDB プロファイル情報を収集するには、次のコマンドを実行します。 +- オペレーティング システムのメモリ関連の構成を収集します。 + - TiUP構成: `resource_control.memory_limit` + - オペレーティング システムの構成: + - メモリ情報: `cat /proc/meminfo` + - カーネルパラメータ: `vm.overcommit_memory` + - NUMA情報: + - `numactl --hardware` + - `numactl --show` + +- データベースのバージョン情報とメモリ関連の構成を収集します。 + - TiDBバージョン + - `tidb_mem_quota_query` + - `memory-usage-alarm-ratio` + - `mem-quota-query` + - `oom-action` + - `tidb_enable_rate_limit_action` + - `tidb_server_memory_limit` + - `oom-use-tmp-storage` + - `tmp-storage-path` + - `tmp-storage-quota` + - `tidb_analyze_version` + +- Grafana ダッシュボードで TiDBメモリの毎日の使用量を確認します: **TiDB** > **Server** > **Memory Usage** 。 + +- より多くのメモリを消費する SQL ステートメントを確認します。 + + - TiDB Dashboardで、SQL ステートメントの分析、スロークエリ、メモリ使用量を確認する。 + - `INFORMATION_SCHEMA`の`SLOW_QUERY`と`CLUSTER_SLOW_QUERY`を確認してください。 + - 各 TiDB ノードで`tidb_slow_query.log`をチェックします。 + - `grep "expensive_query" tidb.log`を実行して、対応するログ エントリを確認します。 + - `EXPLAIN ANALYZE`を実行して、演算子のメモリ使用量を確認します。 + - `SELECT * FROM information_schema.processlist;`を実行して`MEM`列の値を確認します。 + +- メモリ使用量が多いときに TiDB プロファイル情報を収集するには、次のコマンドを実行します。 ```shell curl -G "http://{TiDBIP}:10080/debug/zip?seconds=10" > profile.zip ``` -- `grep "tidb-server has the risk of OOM" tidb.log`を実行して、TiDB サーバーによって収集されたアラートファイルのパスを確認します。出力例を以下に示します。 +- `grep "tidb-server has the risk of OOM" tidb.log`を実行して、TiDB サーバーによって収集されたアラートファイルのパスを確認します。出力例を以下に示します。 ```shell ["tidb-server has the risk of OOM because of memory usage exceeds alarm ratio. Running SQLs and heap profile will be recorded in record path"] ["is tidb_server_memory_limit set"=false] ["system memory total"=14388137984] ["system memory usage"=11897434112] ["tidb-server memory usage"=11223572312] [memory-usage-alarm-ratio=0.8] ["record path"="/tmp/0_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-storage/record"] @@ -193,5 +193,5 @@ OOM 問題の根本原因を特定するには、次の情報を収集する必 ## 参照 {#see-also} -- [TiDB メモリ制御](/configure-memory-usage.md) -- [TiKVメモリパラメータのパフォーマンスを調整する](/tune-tikv-memory-performance.md) +- [TiDB メモリ制御](/configure-memory-usage.md) +- [TiKVメモリパラメータのパフォーマンスを調整する](/tune-tikv-memory-performance.md) diff --git a/troubleshoot-write-conflicts.md b/troubleshoot-write-conflicts.md index 2cafd6d71174c..cae0226543144 100644 --- a/troubleshoot-write-conflicts.md +++ b/troubleshoot-write-conflicts.md @@ -15,12 +15,12 @@ TiDBは[Percolator](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/ クライアントが TiDB に`COMMIT`リクエストを送信すると、TiDB は 2PC プロセスを開始します。 -1. TiDB は、トランザクション内のすべてのキーから 1 つのキーをトランザクションの主キーとして選択します。 -2. TiDBは、このコミットに関係するすべてのTiKVリージョンに`prewrite`リクエストを送信します。TiKVは、すべてのキーが正常にプレビューできるかどうかを判断します。 -3. TiDB は、 `prewrite`リクエストがすべて成功したという結果を受け取ります。 -4. TiDB は PD から`commit_ts`を取得します。 -5. TiDBは、トランザクションの主キーを含むTiKVリージョンに`commit`リクエストを送信します。TiKVは`commit`リクエストを受信すると、データの有効性を確認し、 `prewrite`ステージに残っているロックを解除します。 -6. `commit`リクエストが正常に返されると、TiDB はクライアントに成功を返します。 +1. TiDB は、トランザクション内のすべてのキーから 1 つのキーをトランザクションの主キーとして選択します。 +2. TiDBは、このコミットに関係するすべてのTiKVリージョンに`prewrite`リクエストを送信します。TiKVは、すべてのキーが正常にプレビューできるかどうかを判断します。 +3. TiDB は、 `prewrite`リクエストがすべて成功したという結果を受け取ります。 +4. TiDB は PD から`commit_ts`を取得します。 +5. TiDBは、トランザクションの主キーを含むTiKVリージョンに`commit`リクエストを送信します。TiKVは`commit`リクエストを受信すると、データの有効性を確認し、 `prewrite`ステージに残っているロックを解除します。 +6. `commit`リクエストが正常に返されると、TiDB はクライアントに成功を返します。 書き込み競合はステージ`prewrite`で発生します。トランザクションが、別のトランザクションが現在のキー（ `data.commit_ts` > `txn.start_ts` ）に書き込みを行っていることを検出すると、書き込み競合が発生します。 @@ -28,21 +28,21 @@ TiDBは[Percolator](https://www.usenix.org/legacy/event/osdi10/tech/full_papers/ TiDB Grafana パネルで、 **KV エラー**の下にある次の監視メトリックを確認します。 -- **KV バックオフ OPS は**、TiKV によって返される 1 秒あたりのエラー メッセージの数を示します。 +- **KV バックオフ OPS は**、TiKV によって返される 1 秒あたりのエラー メッセージの数を示します。 ![kv-backoff-ops](/media/troubleshooting-write-conflict-kv-backoff-ops.png) メトリック`txnlock`は書き込み競合を示します。メトリック`txnLockFast`は読み取り競合を示します。 -- **ロック解決 OPS は、** 1 秒あたりのトランザクション競合に関連する項目の数を示します。 +- **ロック解決 OPS は、** 1 秒あたりのトランザクション競合に関連する項目の数を示します。 ![lock-resolve-ops](/media/troubleshooting-write-conflict-lock-resolve-ops.png) - - `not_expired` 、ロックのTTLが期限切れになっていないことを示します。競合トランザクションは、TTLが期限切れになるまでロックを解決できません。 - - `wait_expired` 、トランザクションがロックの有効期限が切れるまで待機する必要があることを示します。 - - `expired`ロックのTTLが期限切れであることを示します。その後、競合トランザクションはこのロックを解決できます。 + - `not_expired` 、ロックのTTLが期限切れになっていないことを示します。競合トランザクションは、TTLが期限切れになるまでロックを解決できません。 + - `wait_expired` 、トランザクションがロックの有効期限が切れるまで待機する必要があることを示します。 + - `expired`ロックのTTLが期限切れであることを示します。その後、競合トランザクションはこのロックを解決できます。 -- **KV 再試行期間は、** KV 要求を再送信する期間を示します。 +- **KV 再試行期間は、** KV 要求を再送信する期間を示します。 ![kv-retry-duration](/media/troubleshooting-write-conflict-kv-retry-duration.png) @@ -58,12 +58,12 @@ TiDBログを検索するキーワードとして`[kv:9007]Write conflict`を使 上記のログの説明は次のとおりです。 -- `[kv:9007]Write conflict` : 書き込み間の競合を示します。 -- `txnStartTS=416617006551793665` : 現在のトランザクションの`start_ts`を示します。`pd-ctl`ツールを使用して、 `start_ts`を物理時間に変換できます。 -- `conflictStartTS=416617018650001409` : 書き込み競合トランザクションの`start_ts`を示します。 -- `conflictCommitTS=416617023093080065` : 書き込み競合トランザクションの`commit_ts`を示します。 -- `key={tableID=47, indexID=1, indexValues={string, }}` : 書き込み競合キーを示します。`tableID`は書き込み競合テーブルのIDを示します。`indexID`は書き込み競合インデックスのIDを示します。書き込み競合キーがレコードキーの場合、ログには競合が発生しているレコード（行）を示す`handle=x`が出力されます。`indexValues`は競合が発生しているインデックスの値を示します。 -- `primary={tableID=47, indexID=1, indexValues={string, }}` : 現在のトランザクションの主キー情報を示します。 +- `[kv:9007]Write conflict` : 書き込み間の競合を示します。 +- `txnStartTS=416617006551793665` : 現在のトランザクションの`start_ts`を示します。`pd-ctl`ツールを使用して、 `start_ts`を物理時間に変換できます。 +- `conflictStartTS=416617018650001409` : 書き込み競合トランザクションの`start_ts`を示します。 +- `conflictCommitTS=416617023093080065` : 書き込み競合トランザクションの`commit_ts`を示します。 +- `key={tableID=47, indexID=1, indexValues={string, }}` : 書き込み競合キーを示します。`tableID`は書き込み競合テーブルのIDを示します。`indexID`は書き込み競合インデックスのIDを示します。書き込み競合キーがレコードキーの場合、ログには競合が発生しているレコード（行）を示す`handle=x`が出力されます。`indexValues`は競合が発生しているインデックスの値を示します。 +- `primary={tableID=47, indexID=1, indexValues={string, }}` : 現在のトランザクションの主キー情報を示します。 `pd-ctl`ツールを使用して、タイムスタンプを読み取り可能な時間に変換できます。 diff --git a/tso-configuration-file.md b/tso-configuration-file.md index 621db83da71f4..808ae214712cb 100644 --- a/tso-configuration-file.md +++ b/tso-configuration-file.md @@ -15,46 +15,46 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ### `name` {#name} -- TSOノードの名前 -- デフォルト値: `"TSO"` -- 複数の TSO ノードを起動するには、各ノードに一意の名前を使用します。 +- TSOノードの名前 +- デフォルト値: `"TSO"` +- 複数の TSO ノードを起動するには、各ノードに一意の名前を使用します。 ### `data-dir` {#data-dir} -- TSOノードがデータを保存するディレクトリ -- デフォルト値: `"default.${name}"` +- TSOノードがデータを保存するディレクトリ +- デフォルト値: `"default.${name}"` ### `listen-addr` {#listen-addr} -- 現在のTSOノードがリッスンするクライアントURL -- デフォルト値: `"http://127.0.0.1:3379"` -- クラスターをデプロイする際は、現在のホストのIPアドレスを`listen-addr` （例： `"http://192.168.100.113:3379"` ）に指定する必要があります。ノードがDocker上で実行されている場合は、DockerのIPアドレスを`"http://0.0.0.0:3379"`に指定してください。 +- 現在のTSOノードがリッスンするクライアントURL +- デフォルト値: `"http://127.0.0.1:3379"` +- クラスターをデプロイする際は、現在のホストのIPアドレスを`listen-addr` （例： `"http://192.168.100.113:3379"` ）に指定する必要があります。ノードがDocker上で実行されている場合は、DockerのIPアドレスを`"http://0.0.0.0:3379"`に指定してください。 ### `advertise-listen-addr` {#advertise-listen-addr} -- クライアントがTSOノードにアクセスするためのURL -- デフォルト値: `"${listen-addr}"` -- Docker や NAT ネットワーク環境などの状況では、クライアントが TSO ノードによってリッスンされるデフォルトのクライアント URL を通じて TSO ノードにアクセスできない場合は、クライアント アクセスに手動で`advertise-listen-addr`設定する必要があります。 -- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 3379:3379`に設定されています。この場合、 `advertise-listen-addr="http://192.168.100.113:3379"`設定できます。そうすることで、クライアントは`http://192.168.100.113:3379`を通じてこのサービスを見つけることができるようになります。 +- クライアントがTSOノードにアクセスするためのURL +- デフォルト値: `"${listen-addr}"` +- Docker や NAT ネットワーク環境などの状況では、クライアントが TSO ノードによってリッスンされるデフォルトのクライアント URL を通じて TSO ノードにアクセスできない場合は、クライアント アクセスに手動で`advertise-listen-addr`設定する必要があります。 +- 例えば、Dockerの内部IPアドレスは`172.17.0.1`ですが、ホストのIPアドレスは`192.168.100.113`で、ポートマッピングは`-p 3379:3379`に設定されています。この場合、 `advertise-listen-addr="http://192.168.100.113:3379"`設定できます。そうすることで、クライアントは`http://192.168.100.113:3379`を通じてこのサービスを見つけることができるようになります。 ### `backend-endpoints` {#backend-endpoints} -- 現在の TSO ノードがリッスンしている他の TSO ノードのバックエンド エンドポイントのリスト -- デフォルト値: `"http://127.0.0.1:2379"` +- 現在の TSO ノードがリッスンしている他の TSO ノードのバックエンド エンドポイントのリスト +- デフォルト値: `"http://127.0.0.1:2379"` ### `lease` {#lease} -- TSOプライマリキーリースのタイムアウト。タイムアウト後、システムはプライマリを再選出します。 -- デフォルト値: `3` -- 単位: 秒 +- TSOプライマリキーリースのタイムアウト。タイムアウト後、システムはプライマリを再選出します。 +- デフォルト値: `3` +- 単位: 秒 ### `tso-update-physical-interval` {#tso-update-physical-interval} -- TSO 物理時間が更新される間隔。 -- TSO物理時間のデフォルトの更新間隔（ `50ms` ）内で、TSOサーバーは最大262144個のTSOを提供します。より多くのTSOを取得するには、この設定項目の値を減らすことができます。最小値は`1ms`です。 -- この間隔を短くすると、TSOサーバーのCPU使用率が増加する可能性があります。テストによると、更新間隔が`50ms`の場合と比較して、間隔が`1ms`の場合、TSOサーバーのCPU使用率は[CPU使用率](https://man7.org/linux/man-pages/man1/top.1.html)で約10%増加します。 -- デフォルト値: `50ms` -- 最小値: `1ms` +- TSO 物理時間が更新される間隔。 +- TSO物理時間のデフォルトの更新間隔（ `50ms` ）内で、TSOサーバーは最大262144個のTSOを提供します。より多くのTSOを取得するには、この設定項目の値を減らすことができます。最小値は`1ms`です。 +- この間隔を短くすると、TSOサーバーのCPU使用率が増加する可能性があります。テストによると、更新間隔が`50ms`の場合と比較して、間隔が`1ms`の場合、TSOサーバーのCPU使用率は[CPU使用率](https://man7.org/linux/man-pages/man1/top.1.html)で約10%増加します。 +- デフォルト値: `50ms` +- 最小値: `1ms` ## security {#security} @@ -62,24 +62,24 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ### `cacert-path` {#cacert-path} -- CAファイルのパス -- デフォルト値: "" +- CAファイルのパス +- デフォルト値: "" ### `cert-path` {#cert-path} -- X.509証明書を含むPrivacy Enhanced Mail（PEM）ファイルのパス -- デフォルト値: "" +- X.509証明書を含むPrivacy Enhanced Mail（PEM）ファイルのパス +- デフォルト値: "" ### `key-path` {#key-path} -- X.509キーを含むPEMファイルのパス -- デフォルト値: "" +- X.509キーを含むPEMファイルのパス +- デフォルト値: "" ### `redact-info-log` {#redact-info-log} -- TSO ノード ログでログの秘匿化を有効にするかどうかを制御します。 -- 構成値を`true`に設定すると、TSO ノード ログでユーザー データが秘匿化されます。 -- デフォルト値: `false` +- TSO ノード ログでログの秘匿化を有効にするかどうかを制御します。 +- 構成値を`true`に設定すると、TSO ノード ログでユーザー データが秘匿化されます。 +- デフォルト値: `false` ## log {#log} @@ -87,20 +87,20 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ### `level` {#level} -- 出力ログのレベルを指定します。 -- `"warn"` `"fatal"` `"error"` `"debug"` `"info"` -- デフォルト値: `"info"` +- 出力ログのレベルを指定します。 +- `"warn"` `"fatal"` `"error"` `"debug"` `"info"` +- デフォルト値: `"info"` ### `format` {#format} -- ログ形式 -- オプション`"json"` : `"text"` -- デフォルト値: `"text"` +- ログ形式 +- オプション`"json"` : `"text"` +- デフォルト値: `"text"` ### `disable-timestamp` {#disable-timestamp} -- ログ内の自動生成されたタイムスタンプを無効にするかどうかを制御します。 -- デフォルト値: `false` +- ログ内の自動生成されたタイムスタンプを無効にするかどうかを制御します。 +- デフォルト値: `false` ## log.file {#log-file} @@ -108,22 +108,22 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ### `max-size` {#max-size} -- 1つのログファイルの最大サイズ。この値を超えると、システムは自動的にログを複数のファイルに分割します。 -- デフォルト値: `300` -- 単位: MiB -- 最小値: `1` +- 1つのログファイルの最大サイズ。この値を超えると、システムは自動的にログを複数のファイルに分割します。 +- デフォルト値: `300` +- 単位: MiB +- 最小値: `1` ### `max-days` {#max-days} -- ログが保持される最大日数。 -- 構成項目が設定されていないか、デフォルト値`0`に設定されている場合、TSO はログ ファイルをクリーンアップしません。 -- デフォルト値: `0` +- ログが保持される最大日数。 +- 構成項目が設定されていないか、デフォルト値`0`に設定されている場合、TSO はログ ファイルをクリーンアップしません。 +- デフォルト値: `0` ### `max-backups` {#max-backups} -- 保持されるログ ファイルの最大数。 -- 構成項目が設定されていないか、デフォルト値`0`に設定されている場合、TSO はすべてのログ ファイルを保持します。 -- デフォルト値: `0` +- 保持されるログ ファイルの最大数。 +- 構成項目が設定されていないか、デフォルト値`0`に設定されている場合、TSO はすべてのログ ファイルを保持します。 +- デフォルト値: `0` ## metric {#metric} @@ -131,5 +131,5 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ### `interval` {#interval} -- 監視メトリックデータがPrometheusにプッシュされる間隔 -- デフォルト値: `15s` +- 監視メトリックデータがPrometheusにプッシュされる間隔 +- デフォルト値: `15s` diff --git a/tso.md b/tso.md index f9dd472d5e10d..4295f2fde3e71 100644 --- a/tso.md +++ b/tso.md @@ -28,8 +28,8 @@ TSO タイムスタンプはトランザクションごとに割り当てられ 前の例で取得したTSOタイムスタンプは10進数です。タイムスタンプを解析するには、以下のSQL関数を使用できます。 -- [`TIDB_PARSE_TSO()`](/functions-and-operators/tidb-functions.md#tidb_parse_tso) -- [`TIDB_PARSE_TSO_LOGICAL()`](/functions-and-operators/tidb-functions.md) +- [`TIDB_PARSE_TSO()`](/functions-and-operators/tidb-functions.md#tidb_parse_tso) +- [`TIDB_PARSE_TSO_LOGICAL()`](/functions-and-operators/tidb-functions.md) ```sql SELECT TIDB_PARSE_TSO(443852055297916932); @@ -61,8 +61,8 @@ SELECT TIDB_PARSE_TSO_LOGICAL(443852055297916932); TSO タイムスタンプには 2 つの部分があります。 -- 物理タイムスタンプ: 1970 年 1 月 1 日からのミリ秒単位の UNIX タイムスタンプ。 -- 論理タイムスタンプ：増分するカウンターで、同じミリ秒内に複数のタイムスタンプが必要なシナリオや、特定のイベントによって時計の進行が逆転する可能性がある場合に使用されます。このような場合、物理タイムスタンプは変化せず、論理タイムスタンプは着実に進みます。このメカニズムにより、TSOタイムスタンプの整合性が確保されます。TSOタイムスタンプは常に前進し、後退することはありません。 +- 物理タイムスタンプ: 1970 年 1 月 1 日からのミリ秒単位の UNIX タイムスタンプ。 +- 論理タイムスタンプ：増分するカウンターで、同じミリ秒内に複数のタイムスタンプが必要なシナリオや、特定のイベントによって時計の進行が逆転する可能性がある場合に使用されます。このような場合、物理タイムスタンプは変化せず、論理タイムスタンプは着実に進みます。このメカニズムにより、TSOタイムスタンプの整合性が確保されます。TSOタイムスタンプは常に前進し、後退することはありません。 この知識があれば、SQL で TSO タイムスタンプをもう少し詳しく調べることができます。 diff --git a/tune-operating-system.md b/tune-operating-system.md index 6daf8adeaaab9..f17df36610617 100644 --- a/tune-operating-system.md +++ b/tune-operating-system.md @@ -9,8 +9,8 @@ summary: オペレーティング システムのパラメータを調整する > **Note:** > -> - CentOS 7オペレーティングシステムのデフォルト構成は、中程度のワークロードで実行されるほとんどのサービスに適しています。特定のサブシステムのパフォーマンスを調整すると、他のサブシステムに悪影響を与える可能性があります。そのため、システムをチューニングする前に、すべてのユーザーデータと設定情報をバックアップしてください。 -> - すべての変更を本番環境に適用する前に、テスト環境で完全にテストします。 +> - CentOS 7オペレーティングシステムのデフォルト構成は、中程度のワークロードで実行されるほとんどのサービスに適しています。特定のサブシステムのパフォーマンスを調整すると、他のサブシステムに悪影響を与える可能性があります。そのため、システムをチューニングする前に、すべてのユーザーデータと設定情報をバックアップしてください。 +> - すべての変更を本番環境に適用する前に、テスト環境で完全にテストします。 ## パフォーマンス分析方法 {#performance-analysis-methods} @@ -20,16 +20,16 @@ summary: オペレーティング システムのパラメータを調整する [*60,000ミリ秒でLinuxのパフォーマンス分析*](http://www.brendangregg.com/Articles/Netflix_Linux_Perf_Analysis_60s.pdf) 、著者のBrendan Gregg氏とNetflixパフォーマンスエンジニアリングチームによって公開されています。使用されているツールはすべてLinuxの公式リリースから入手できます。以下のリスト項目の出力を分析することで、最も一般的なパフォーマンス問題のトラブルシューティングを行うことができます。 -- `uptime` -- `dmesg | tail` -- `vmstat 1` -- `mpstat -P ALL 1` -- `pidstat 1` -- `iostat -xz 1` -- `free -m` -- `sar -n DEV 1` -- `sar -n TCP,ETCP 1` -- `top` +- `uptime` +- `dmesg | tail` +- `vmstat 1` +- `mpstat -P ALL 1` +- `pidstat 1` +- `iostat -xz 1` +- `free -m` +- `sar -n DEV 1` +- `sar -n TCP,ETCP 1` +- `top` 詳しい使用方法については、対応する`man`説明を参照してください。 @@ -51,12 +51,12 @@ cpufreq は、CPU周波数を動的に調整するモジュールです。5つ ### CPU—割り込み親和性 {#cpuinterrupt-affinity} -- `irqbalance`サービスを通じて自動バランスを実現できます。 -- 手動バランス: - - 割り込みのバランスをとる必要があるデバイスを特定します。CentOS 7.5以降では、 `be2iscsi`ドライバとNVMe設定を使用するデバイスなど、特定のデバイスとそのドライバに対して、システムが最適な割り込みアフィニティを自動的に設定します。これらのデバイスに対しては、手動で割り込みアフィニティを設定することはできなくなりました。 - - その他のデバイスについては、チップのマニュアルを参照して、これらのデバイスが割り込み分散をサポートしているかどうかを確認してください。 - - そうでない場合、これらのデバイスのすべての割り込みは同じ CPU にルーティングされ、変更できなくなります。 - - 該当する場合は、 `smp_affinity`マスクを計算し、対応する設定ファイルを設定します。詳細については、 [カーネルドキュメント](https://www.kernel.org/doc/Documentation/IRQ-affinity.txt)を参照してください。 +- `irqbalance`サービスを通じて自動バランスを実現できます。 +- 手動バランス: + - 割り込みのバランスをとる必要があるデバイスを特定します。CentOS 7.5以降では、 `be2iscsi`ドライバとNVMe設定を使用するデバイスなど、特定のデバイスとそのドライバに対して、システムが最適な割り込みアフィニティを自動的に設定します。これらのデバイスに対しては、手動で割り込みアフィニティを設定することはできなくなりました。 + - その他のデバイスについては、チップのマニュアルを参照して、これらのデバイスが割り込み分散をサポートしているかどうかを確認してください。 + - そうでない場合、これらのデバイスのすべての割り込みは同じ CPU にルーティングされ、変更できなくなります。 + - 該当する場合は、 `smp_affinity`マスクを計算し、対応する設定ファイルを設定します。詳細については、 [カーネルドキュメント](https://www.kernel.org/doc/Documentation/IRQ-affinity.txt)を参照してください。 ### NUMA CPU バインディング {#numa-cpu-binding} @@ -74,8 +74,8 @@ grubby --update-kernel="$KERNEL" --args='transparent_hugepage=never' ### メモリ - 仮想メモリパラメータ {#memoryvirtual-memory-parameters} -- `dirty_ratio`パーセント比。ダーティページキャッシュの総量がシステムメモリ全体のこのパーセント比に達すると、システムは`pdflush`オペレーションを使用してダーティページキャッシュをディスクに書き込みます。デフォルト値の`dirty_ratio`は 20% であり、通常は調整する必要はありません。NVMe デバイスなどの高性能 SSD の場合、この値を下げるとメモリ回収の効率が向上します。 -- `dirty_background_ratio`パーセント比。ダーティページキャッシュの総量がシステムメモリ全体のこのパーセント比に達すると、システムはバックグラウンドでダーティページキャッシュをディスクに書き込み始めます。デフォルト値の`dirty_background_ratio`は 10% であり、通常は調整する必要はありません。NVMe デバイスなどの高性能 SSD の場合、値を低く設定するとメモリ回収の効率が向上します。 +- `dirty_ratio`パーセント比。ダーティページキャッシュの総量がシステムメモリ全体のこのパーセント比に達すると、システムは`pdflush`オペレーションを使用してダーティページキャッシュをディスクに書き込みます。デフォルト値の`dirty_ratio`は 20% であり、通常は調整する必要はありません。NVMe デバイスなどの高性能 SSD の場合、この値を下げるとメモリ回収の効率が向上します。 +- `dirty_background_ratio`パーセント比。ダーティページキャッシュの総量がシステムメモリ全体のこのパーセント比に達すると、システムはバックグラウンドでダーティページキャッシュをディスクに書き込み始めます。デフォルト値の`dirty_background_ratio`は 10% であり、通常は調整する必要はありません。NVMe デバイスなどの高性能 SSD の場合、値を低く設定するとメモリ回収の効率が向上します。 ### ストレージとファイルシステム {#storage-and-file-system} @@ -109,20 +109,20 @@ 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ハードウェアキャッシュ：ハードウェアレベルでパケットロスを正しく監視するには、コマンド`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 を使用しているか、そしてそれらを最適化できるかどうかを特定する必要があります。 +- ソフトウェア割り込み： `/proc/net/softnet_stat`の監視を監視します。3列目以外の列の値が増加している場合は、 `softirq`の`net.core.netdev_budget`または`net.core.dev_weight`の値を適切に調整して、CPU 時間を増やします。さらに、CPU 使用率も確認し、どのタスクが頻繁に CPU を使用しているか、そしてそれらを最適化できるかどうかを特定する必要があります。 -- アプリケーションソケットの受信キュー： `ss -nmp`の`Resv-q`列を監視します。キューがいっぱいの場合は、アプリケーションソケットのキャッシュサイズを増やすか、自動キャッシュ調整機能の使用を検討してください。さらに、アプリケーションレイヤーのアーキテクチャを最適化し、ソケットの読み取り間隔を短縮できるかどうかも検討してください。 +- アプリケーションソケットの受信キュー： `ss -nmp`の`Resv-q`列を監視します。キューがいっぱいの場合は、アプリケーションソケットのキャッシュサイズを増やすか、自動キャッシュ調整機能の使用を検討してください。さらに、アプリケーションレイヤーのアーキテクチャを最適化し、ソケットの読み取り間隔を短縮できるかどうかも検討してください。 -- イーサネット フロー制御: NIC とスイッチがフロー制御機能をサポートしている場合は、この機能を使用して、カーネルが NIC キュー内のデータを処理するための時間を確保し、NIC バッファ オーバーフローの問題を回避できます。 +- イーサネット フロー制御: NIC とスイッチがフロー制御機能をサポートしている場合は、この機能を使用して、カーネルが NIC キュー内のデータを処理するための時間を確保し、NIC バッファ オーバーフローの問題を回避できます。 -- 割り込みの統合：ハードウェア割り込みが多すぎるとシステムパフォーマンスが低下し、ハードウェア割り込みが遅すぎるとパケット損失が発生します。新しいNICは割り込み統合機能をサポートしており、ドライバがハードウェア割り込みの数を自動的に調整できます。この機能を有効にするには`ethtool -c ${NIC_DEV_NAME}` 、有効にするには`ethtool -C ${NIC_DEV_NAME}`を実行します。アダプティブモードでは、NICが割り込み統合を自動的に調整します。このモードでは、ドライバはトラフィックモードとカーネル受信モードをチェックし、パケット損失を防ぐためにリアルタイムで統合設定を評価します。NICのブランドによって機能やデフォルト設定が異なります。詳細については、NICのマニュアルを参照してください。 +- 割り込みの統合：ハードウェア割り込みが多すぎるとシステムパフォーマンスが低下し、ハードウェア割り込みが遅すぎるとパケット損失が発生します。新しいNICは割り込み統合機能をサポートしており、ドライバがハードウェア割り込みの数を自動的に調整できます。この機能を有効にするには`ethtool -c ${NIC_DEV_NAME}` 、有効にするには`ethtool -C ${NIC_DEV_NAME}`を実行します。アダプティブモードでは、NICが割り込み統合を自動的に調整します。このモードでは、ドライバはトラフィックモードとカーネル受信モードをチェックし、パケット損失を防ぐためにリアルタイムで統合設定を評価します。NICのブランドによって機能やデフォルト設定が異なります。詳細については、NICのマニュアルを参照してください。 -- アダプタキュー：カーネルはプロトコルスタックを処理する前に、このキューを使用してNICが受信したデータをバッファリングします。各CPUには独自のバックログキューがあります。このキューにキャッシュできるパケットの最大数は`netdev_max_backlog`です。2列目の`/proc/net/softnet_stat`に注目してください。行の2列目が増加し続ける場合、CPU [行-1]キューがいっぱいになり、データパケットが失われていることを意味します。この問題を解決するには、 `net.core.netdev_max_backlog`値を2倍に増やし続けます。 +- アダプタキュー：カーネルはプロトコルスタックを処理する前に、このキューを使用してNICが受信したデータをバッファリングします。各CPUには独自のバックログキューがあります。このキューにキャッシュできるパケットの最大数は`netdev_max_backlog`です。2列目の`/proc/net/softnet_stat`に注目してください。行の2列目が増加し続ける場合、CPU [行-1]キューがいっぱいになり、データパケットが失われていることを意味します。この問題を解決するには、 `net.core.netdev_max_backlog`値を2倍に増やし続けます。 -- 送信キュー：送信キューの長さは、送信前にキューイングできるパケット数を決定します。デフォルト値は`1000`で、10 Gbps には十分です。ただし、 `ip -s link`の出力から TX errors の値を確認した場合は、これを倍の`ip link set dev ${NIC_DEV_NAME} txqueuelen 2000`に設定してみてください。 +- 送信キュー：送信キューの長さは、送信前にキューイングできるパケット数を決定します。デフォルト値は`1000`で、10 Gbps には十分です。ただし、 `ip -s link`の出力から TX errors の値を確認した場合は、これを倍の`ip link set dev ${NIC_DEV_NAME} txqueuelen 2000`に設定してみてください。 -- Driver：NICドライバは通常、チューニングパラメータを提供します。デバイスのハードウェアマニュアルとドライバのドキュメントを参照してください。 +- Driver：NICドライバは通常、チューニングパラメータを提供します。デバイスのハードウェアマニュアルとドライバのドキュメントを参照してください。 diff --git a/tune-region-performance.md b/tune-region-performance.md index 22beb5ba1860e..daac54f085909 100644 --- a/tune-region-performance.md +++ b/tune-region-performance.md @@ -15,9 +15,9 @@ TiKVは自動的に[最下層のデータを分割する](/best-practices/tidb-b > **Note:** > -> - v6.1.0 では、TiDB は実験的機能としてリージョンサイズのカスタマイズをサポートしています。 -> - v6.5.0 以降、この機能は一般提供 (GA) されます。 -> - v8.4.0以降、リージョンのデフォルトサイズが96MiBから256MiBに変更されました。リージョンサイズを増やすと、リージョンの数を減らすことができます。 +> - v6.1.0 では、TiDB は実験的機能としてリージョンサイズのカスタマイズをサポートしています。 +> - v6.5.0 以降、この機能は一般提供 (GA) されます。 +> - v8.4.0以降、リージョンのデフォルトサイズが96MiBから256MiBに変更されました。リージョンサイズを増やすと、リージョンの数を減らすことができます。 多くのリージョンのパフォーマンスオーバーヘッドを削減するには、 [休止状態リージョン](/best-practices/massive-regions-best-practices.md#method-4-increase-the-number-of-tikv-instances)または[`Region Merge`](/best-practices/massive-regions-best-practices.md#method-5-adjust-raft-base-tick-interval)有効にすることもできます。 @@ -27,9 +27,9 @@ TiKVは自動的に[最下層のデータを分割する](/best-practices/tidb-b > > リージョンサイズの推奨範囲は[48 MiB、256 MiB]です。一般的に使用されるサイズは96 MiB、128 MiB、256 MiBです。リージョンサイズを1 GiBを超える値に設定することは推奨されません。10 GiBを超えるサイズの設定は避けてください。リージョンサイズが大きすぎると、以下の副作用が発生する可能性があります。 > -> - パフォーマンスのジッター -> - クエリパフォーマンスの低下（特に広範囲のデータを扱うクエリの場合） -> - 遅いリージョンスケジュール +> - パフォーマンスのジッター +> - クエリパフォーマンスの低下（特に広範囲のデータを扱うクエリの場合） +> - 遅いリージョンスケジュール リージョンサイズを調整するには、 [`coprocessor.region-split-size`](/tikv-configuration-file.md#region-split-size)設定項目を使用します。TiFlashまたはTiFlashツールを使用する場合、リージョンサイズは1GiBを超えないようにしてください。リージョンサイズを増やした後、 Dumplingツールを使用する場合は同時実行性を下げる必要があります。そうしないと、TiDBのメモリが発生する可能性があります。 @@ -49,5 +49,5 @@ TiKVは自動的に[最下層のデータを分割する](/best-practices/tidb-b PD は、リージョン同期ストリームのステータスを維持し、TiKV client-go のフォールバック メカニズムを使用することで、TiDB 内のリージョン情報が常に最新であることを保証します。 -- PDリーダーとフォロワー間のネットワークが不安定な場合、またはフォロワーが利用できない場合、リージョン同期ストリームは切断され、PDフォロワーはリージョン情報要求を拒否します。この場合、TiDBはPDリーダーへの要求を自動的に再試行し、フォロワーを一時的に利用不可としてマークします。 -- ネットワークが安定している場合でも、リーダーとフォロワー間の同期に遅延が生じる可能性があり、フォロワーから取得したリージョン情報の一部が古くなっている可能性があります。この場合、当該リージョンに対応するKV要求が失敗すると、TiDBはPDリーダーに最新のリージョン情報を自動的に再要求し、TiKVに再度KV要求を送信します。 +- PDリーダーとフォロワー間のネットワークが不安定な場合、またはフォロワーが利用できない場合、リージョン同期ストリームは切断され、PDフォロワーはリージョン情報要求を拒否します。この場合、TiDBはPDリーダーへの要求を自動的に再試行し、フォロワーを一時的に利用不可としてマークします。 +- ネットワークが安定している場合でも、リーダーとフォロワー間の同期に遅延が生じる可能性があり、フォロワーから取得したリージョン情報の一部が古くなっている可能性があります。この場合、当該リージョンに対応するKV要求が失敗すると、TiDBはPDリーダーに最新のリージョン情報を自動的に再要求し、TiKVに再度KV要求を送信します。 diff --git a/tune-tikv-memory-performance.md b/tune-tikv-memory-performance.md index 7d569b60f352b..abd818fdb888b 100644 --- a/tune-tikv-memory-performance.md +++ b/tune-tikv-memory-performance.md @@ -11,15 +11,15 @@ TiKVは、TiKVアーキテクチャの最下層における永続ストレージ TiKV は RocksDB から`Column Families` (CF) を実装します。 -- デフォルトの RocksDB インスタンスは、KV データを`default` `write`および`lock` CF に保存します。 +- デフォルトの RocksDB インスタンスは、KV データを`default` `write`および`lock` CF に保存します。 - - `default` CFには実際のデータが保存されます。対応するパラメータは`[rocksdb.defaultcf]`にあります。 - - `write` CF は、マルチバージョン同時実行制御（MVCC）のバージョン情報とインデックス関連データを格納します。対応するパラメータは`[rocksdb.writecf]`にあります。 - - `lock`はロック情報を保存し、システムはデフォルトのパラメータを使用します。 + - `default` CFには実際のデータが保存されます。対応するパラメータは`[rocksdb.defaultcf]`にあります。 + - `write` CF は、マルチバージョン同時実行制御（MVCC）のバージョン情報とインデックス関連データを格納します。対応するパラメータは`[rocksdb.writecf]`にあります。 + - `lock`はロック情報を保存し、システムはデフォルトのパラメータを使用します。 -- Raft RocksDB (RaftDB) インスタンスはRaftログを保存します。 +- Raft RocksDB (RaftDB) インスタンスはRaftログを保存します。 - - `default` CF はRaftログを保存します。対応するパラメータは`[raftdb.defaultcf]`にあります。 + - `default` CF はRaftログを保存します。対応するパラメータは`[raftdb.defaultcf]`にあります。 TiKV 3.0以降では、デフォルトですべてのCFが1つのブロックキャッシュインスタンスを共有します。キャッシュのサイズは、 `[storage.block-cache]`の下の`capacity`パラメータを設定することで設定できます。ブロックキャッシュが大きいほど、より多くのホットデータをキャッシュでき、データの読み取りが容易になりますが、同時にシステムメモリの占有量も大きくなります。 @@ -243,14 +243,14 @@ target-file-size-base = "32MiB" システムメモリを占有する`block cache`と`write buffer`他に、次のシナリオでもシステムメモリが占​​有されます。 -- メモリの一部はシステムのページ キャッシュとして予約されています。 +- メモリの一部はシステムのページ キャッシュとして予約されています。 -- TiKVは`select * from ...`ような大規模なクエリを処理する際、データを読み取り、対応するデータ構造をメモリ上に生成し、その構造をTiDBに返します。この処理中、TiKVはメモリの一部を占有します。 +- TiKVは`select * from ...`ような大規模なクエリを処理する際、データを読み取り、対応するデータ構造をメモリ上に生成し、その構造をTiDBに返します。この処理中、TiKVはメモリの一部を占有します。 ## TiKVの推奨構成 {#recommended-configuration-of-tikv} -- 本番環境では、CPU コアが 8 個未満、またはメモリが 32 GiB 未満のマシンに TiKV を展開することは推奨されません。 +- 本番環境では、CPU コアが 8 個未満、またはメモリが 32 GiB 未満のマシンに TiKV を展開することは推奨されません。 -- 高い書き込みスループットが求められる場合は、スループット容量の優れたディスクを使用することをお勧めします。 +- 高い書き込みスループットが求められる場合は、スループット容量の優れたディスクを使用することをお勧めします。 -- 非常に低い読み取り/書き込みレイテンシーを要求する場合は、高 IOPS の SSD を使用することをお勧めします。 +- 非常に低い読み取り/書き込みレイテンシーを要求する場合は、高 IOPS の SSD を使用することをお勧めします。 diff --git a/tune-tikv-thread-performance.md b/tune-tikv-thread-performance.md index 3de9b35169e20..bcad78ec337b6 100644 --- a/tune-tikv-thread-performance.md +++ b/tune-tikv-thread-performance.md @@ -11,73 +11,73 @@ summary: 最適なパフォーマンスを得るために TiKV スレッド プ TiKVスレッドプールは、主にgRPC、Scheduler、UnifyReadPool、 Raftstore、StoreWriter、Apply、RocksDB、そしてCPUをあまり消費しないいくつかのスケジュールタスクと検出コンポーネントで構成されています。このドキュメントでは、主に読み取りおよび書き込みリクエストのパフォーマンスに影響を与える、CPUを大量に消費するスレッドプールをいくつか紹介します。 -- gRPC スレッド プール: すべてのネットワーク リクエストを処理し、さまざまなタスク タイプのリクエストをさまざまなスレッド プールに転送します。 +- gRPC スレッド プール: すべてのネットワーク リクエストを処理し、さまざまなタスク タイプのリクエストをさまざまなスレッド プールに転送します。 -- スケジューラ スレッド プール: 書き込みトランザクションの競合を検出し、2 フェーズ コミット、悲観的ロック、トランザクション ロールバックなどの要求をキーと値のペアの配列に変換し、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 +- スケジューラ スレッド プール: 書き込みトランザクションの競合を検出し、2 フェーズ コミット、悲観的ロック、トランザクション ロールバックなどの要求をキーと値のペアの配列に変換し、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 -- Raftstoreスレッド プール: +- Raftstoreスレッド プール: - - すべてのRaftメッセージと新しいログを追加する提案を処理します。 - - Raftログをディスクに書き込みます。[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)の値が`0`の場合、 Raftstoreスレッドはログをディスクに書き込みます。値が`0`でない場合、 RaftstoreスレッドはログをStoreWriterスレッドに送信します。 - - 大部分のレプリカのRaftログが整合している場合、 Raftstoreスレッドはログを適用スレッドに送信します。 + - すべてのRaftメッセージと新しいログを追加する提案を処理します。 + - Raftログをディスクに書き込みます。[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)の値が`0`の場合、 Raftstoreスレッドはログをディスクに書き込みます。値が`0`でない場合、 RaftstoreスレッドはログをStoreWriterスレッドに送信します。 + - 大部分のレプリカのRaftログが整合している場合、 Raftstoreスレッドはログを適用スレッドに送信します。 -- StoreWriter スレッド プール: すべてのRaftログをディスクに書き込み、結果をRaftstoreスレッドに返します。 +- StoreWriter スレッド プール: すべてのRaftログをディスクに書き込み、結果をRaftstoreスレッドに返します。 -- Apply スレッド プール: Raftstoreスレッド プールから送信された送信ログを受信し、それをキー値要求として解析し、RocksDB に書き込み、コールバック関数を呼び出して gRPC スレッド プールに書き込み要求が完了したことを通知し、結果をクライアントに返します。 +- Apply スレッド プール: Raftstoreスレッド プールから送信された送信ログを受信し、それをキー値要求として解析し、RocksDB に書き込み、コールバック関数を呼び出して gRPC スレッド プールに書き込み要求が完了したことを通知し、結果をクライアントに返します。 -- RocksDBスレッドプール：RocksDBがタスクを圧縮およびフラッシュするためのスレッドプールです。RocksDBのアーキテクチャと`Compact`操作については、 [RocksDB: フラッシュと RAM ストレージ用の永続的なキーバリューストア](https://github.com/facebook/rocksdb)を参照してください。 +- RocksDBスレッドプール：RocksDBがタスクを圧縮およびフラッシュするためのスレッドプールです。RocksDBのアーキテクチャと`Compact`操作については、 [RocksDB: フラッシュと RAM ストレージ用の永続的なキーバリューストア](https://github.com/facebook/rocksdb)を参照してください。 -- UnifyReadPool スレッドプール:コプロセッサースレッドプールとストレージ読み取りプールを組み合わせたものです。kv get、kv batch get、raw kv get、コプロセッサなどのすべての読み取り要求はこのスレッドプールで実行されます。 +- UnifyReadPool スレッドプール:コプロセッサースレッドプールとストレージ読み取りプールを組み合わせたものです。kv get、kv batch get、raw kv get、コプロセッサなどのすべての読み取り要求はこのスレッドプールで実行されます。 ## TiKV読み取り専用リクエスト {#tikv-read-only-requests} TiKV の読み取り要求は次の種類に分類されます。 -- ストレージ読み取りプールで実行される、特定の行または複数の行を指定する単純なクエリ。 -- コプロセッサー読み取りプールで実行される複雑な集計計算と範囲クエリ。 +- ストレージ読み取りプールで実行される、特定の行または複数の行を指定する単純なクエリ。 +- コプロセッサー読み取りプールで実行される複雑な集計計算と範囲クエリ。 TiKV v5.0以降、すべての読み取りリクエストはデフォルトでクエリ用の統合スレッドプールを使用します。TiKVクラスターをTiKV v4.0からアップグレードし、アップグレード前に`readpool.storage`の`use-unified-pool`設定が`false`に設定されていた場合、アップグレード後もすべての読み取りリクエストは引き続き異なるスレッドプールを使用します。このシナリオでは、すべての読み取りリクエストがクエリ用の統合スレッドプールを使用するようにするには、 `readpool.storage.use-unified-pool`を`true`に設定します。 ## TiKV スレッドプールのパフォーマンスチューニング {#performance-tuning-for-tikv-thread-pools} -- gRPC スレッド プール。 +- gRPC スレッド プール。 v8.5.4以降、gRPCスレッドプールのデフォルトサイズ（ `server.grpc-concurrency`で設定）が固定値の`5`から、CPUコア数に基づいて計算される適応値に変更されました。詳細な計算式については、 [`server.grpc-concurrency`](/tikv-configuration-file.md#grpc-concurrency)を参照してください。このスレッドプールはコンピューティングオーバーヘッドがほとんどなく、主にネットワークI/Oとデシリアライズリクエストを処理するため、通常はデフォルト設定を調整する必要はありません。 - - TiKV で展開されたマシンの CPU コア数が少ない (8 個以下) 場合は、 `server.grpc-concurrency`構成項目を`2`に設定することを検討してください。 - - TiKV を導入したマシンの構成が非常に高く、TiKV が大量の読み取りおよび書き込み要求を処理し、Grafana でスレッド CPU を監視する値`gRPC poll CPU`が`server.grpc-concurrency`の 80% を超える場合は、スレッド プールの使用率を 80% 未満 (つまり、Grafana のメトリックが`80% * server.grpc-concurrency`未満) に保つために値`server.grpc-concurrency`を増やすことを検討してください。 + - TiKV で展開されたマシンの CPU コア数が少ない (8 個以下) 場合は、 `server.grpc-concurrency`構成項目を`2`に設定することを検討してください。 + - TiKV を導入したマシンの構成が非常に高く、TiKV が大量の読み取りおよび書き込み要求を処理し、Grafana でスレッド CPU を監視する値`gRPC poll CPU`が`server.grpc-concurrency`の 80% を超える場合は、スレッド プールの使用率を 80% 未満 (つまり、Grafana のメトリックが`80% * server.grpc-concurrency`未満) に保つために値`server.grpc-concurrency`を増やすことを検討してください。 -- スケジューラ スレッド プール。 +- スケジューラ スレッド プール。 TiKV がマシンの CPU コアの数が 16 以上であることを検出すると、スケジューラ スレッド プールのデフォルト サイズ ( `storage.scheduler-worker-pool-size`に設定) は`8`なります。TiKV がマシンの CPU コアの数が 16 未満であることを検出すると、デフォルト サイズは`4`なります。 このスレッドプールは主に、複雑なトランザクションリクエストを単純なキー値の読み取り/書き込みリクエストに変換するために使用されます。ただし、**スケジューラスレッドプール自体は書き込み操作を実行しません**。 - - トランザクションの競合が検出されると、このスレッド プールは競合の結果を事前にクライアントに返します。 - - 競合が検出されない場合、このスレッド プールは書き込み操作を実行するキー値要求をRaftログにマージし、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 + - トランザクションの競合が検出されると、このスレッド プールは競合の結果を事前にクライアントに返します。 + - 競合が検出されない場合、このスレッド プールは書き込み操作を実行するキー値要求をRaftログにマージし、 RaftログのレプリケーションのためにRaftstoreスレッドに送信します。 一般的に、過度のスレッド切り替えを避けるには、スケジューラのスレッドプールの使用率を50%～75%に保つことが最善です。スレッドプールのサイズが`8`の場合、Grafanaでは400%～600%の範囲で`TiKV-Details.Thread CPU.scheduler worker CPU`を維持することをお勧めします。 -- Raftstoreスレッド プール。 +- Raftstoreスレッド プール。 Raftstoreスレッドプールは、TiKV で最も複雑なスレッドプールです。このスレッドプールのデフォルトサイズ（ `raftstore.store-pool-size`で設定）は`2`です。StoreWriter スレッドプールのデフォルトサイズ（ `raftstore.store-io-pool-size`で設定）は`1`です。 - - StoreWriterスレッドプールのサイズが0の場合、すべての書き込みリクエストはRaftstoreスレッドによって`fsync`としてRocksDBに書き込まれます。この場合、以下の方法でパフォーマンスをチューニングすることをお勧めします。 + - StoreWriterスレッドプールのサイズが0の場合、すべての書き込みリクエストはRaftstoreスレッドによって`fsync`としてRocksDBに書き込まれます。この場合、以下の方法でパフォーマンスをチューニングすることをお勧めします。 - - Raftstoreスレッド全体の CPU 使用率を 60% 未満に保ちます。Raftstoreスレッド数が 2 の場合、Grafana 上の**TiKV-Details** 、 **Thread CPU** 、 **Raft store CPU を**120% 未満に保ちます。I/O リクエストにより、 Raftstoreスレッドの CPU 使用率は理論上は常に 100% 未満になります。 - - 書き込みパフォーマンスを向上させるために、 Raftstoreスレッド プールのサイズを慎重に検討せずに増やさないでください。そうすると、ディスクの負荷が増加し、パフォーマンスが低下する可能性があります。 + - Raftstoreスレッド全体の CPU 使用率を 60% 未満に保ちます。Raftstoreスレッド数が 2 の場合、Grafana 上の**TiKV-Details** 、 **Thread CPU** 、 **Raft store CPU を**120% 未満に保ちます。I/O リクエストにより、 Raftstoreスレッドの CPU 使用率は理論上は常に 100% 未満になります。 + - 書き込みパフォーマンスを向上させるために、 Raftstoreスレッド プールのサイズを慎重に検討せずに増やさないでください。そうすると、ディスクの負荷が増加し、パフォーマンスが低下する可能性があります。 - - StoreWriterスレッドプールのサイズが0でない場合、すべての書き込みリクエストはStoreWriterスレッドによって`fsync`としてRocksDBに書き込まれます。この場合、以下の方法でパフォーマンスをチューニングすることをお勧めします。 + - StoreWriterスレッドプールのサイズが0でない場合、すべての書き込みリクエストはStoreWriterスレッドによって`fsync`としてRocksDBに書き込まれます。この場合、以下の方法でパフォーマンスをチューニングすることをお勧めします。 - - StoreWriterスレッドプールは、CPUリソース全体が十分である場合にのみ有効にしてください。StoreWriterスレッドプールを有効にする際は、StoreWriterスレッドとRaftstoreスレッドのCPU使用率を80%未満に抑えてください。 + - StoreWriterスレッドプールは、CPUリソース全体が十分である場合にのみ有効にしてください。StoreWriterスレッドプールを有効にする際は、StoreWriterスレッドとRaftstoreスレッドのCPU使用率を80%未満に抑えてください。 書き込み要求がRaftstoreスレッドで処理される場合と比較して、理論上は、書き込み要求が StoreWriter スレッドで処理される場合、書き込みレイテンシーとデータ読み取りのテールレイテンシーが大幅に削減されます。ただし、書き込み速度が高速化すると、それに応じてRaftログの数が増加します。これにより、 Raftstoreスレッド、Apply スレッド、および gRPC スレッドの CPU オーバーヘッドが増加する可能性があります。この場合、CPU リソースが不足するとチューニング効果が打ち消され、結果として書き込み速度が以前よりも遅くなる可能性があります。したがって、CPU リソースが十分でない場合は、StoreWriter スレッドを有効にすることは推奨されません。Raftstore スレッドはほとんどの I/O 要求をStoreWriterスレッドに送信するため、 Raftstoreスレッドの CPU 使用率を 80% 未満に抑える必要があります。 - - ほとんどの場合、StoreWriter スレッドプールのサイズは 1 または 2 に設定してください。これは、StoreWriter スレッドプールのサイズがRaftログの数に影響するため、スレッドプールのサイズを大きくしすぎないようにするためです。CPU 使用率が 80% を超える場合は、スレッドプールのサイズを増やすことを検討してください。 + - ほとんどの場合、StoreWriter スレッドプールのサイズは 1 または 2 に設定してください。これは、StoreWriter スレッドプールのサイズがRaftログの数に影響するため、スレッドプールのサイズを大きくしすぎないようにするためです。CPU 使用率が 80% を超える場合は、スレッドプールのサイズを増やすことを検討してください。 - - Raftログの増加が他のスレッドプールのCPUオーバーヘッドに与える影響に注意してください。必要に応じて、 Raftstoreスレッド、Applyスレッド、gRPCスレッドの数を増やす必要があります。 + - Raftログの増加が他のスレッドプールのCPUオーバーヘッドに与える影響に注意してください。必要に応じて、 Raftstoreスレッド、Applyスレッド、gRPCスレッドの数を増やす必要があります。 -- UnifyReadPool スレッド プール。 +- UnifyReadPool スレッド プール。 UnifyReadPool はすべての読み取りリクエストの処理を担当します。デフォルトのサイズ（ `readpool.unified.max-thread-count`に設定）は、マシンの CPU コア数の 80% です。例えば、マシンの CPU コア数が 16 の場合、デフォルトのスレッドプールサイズは 12 です。アプリケーションのワークロードに応じて CPU 使用率を調整し、スレッドプールサイズの 60% から 90% の範囲に維持することをお勧めします。 @@ -85,16 +85,16 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで v6.3.0以降、TiKVは現在のCPU使用率に基づいてUnifyReadPoolスレッドプールサイズを自動調整する機能をサポートしています。この機能を有効にするには、 [`readpool.unified.auto-adjust-pool-size = true`](/tikv-configuration-file.md#auto-adjust-pool-size-new-in-v630)を設定します。再読み取りが行われ、最大CPU使用率が80%を超えるクラスターについては、スレッドプールサイズを自動調整することをお勧めします。 -- RocksDB スレッド プール。 +- RocksDB スレッド プール。 RocksDBスレッドプールは、RocksDBがタスクを圧縮およびフラッシュするためのスレッドプールです。通常は設定する必要はありません。 - - マシンの CPU コア数が少ない場合は、 `rocksdb.max-background-jobs`と`raftdb.max-background-jobs`両方を`4`に設定します。 - - 書き込みストールが発生した場合は、Grafana の**RocksDB-kv**の Write Stall Reason に移動し、 `0`以外のメトリックを確認します。 + - マシンの CPU コア数が少ない場合は、 `rocksdb.max-background-jobs`と`raftdb.max-background-jobs`両方を`4`に設定します。 + - 書き込みストールが発生した場合は、Grafana の**RocksDB-kv**の Write Stall Reason に移動し、 `0`以外のメトリックを確認します。 - - 保留中の圧縮バイトに関連する理由によって発生した場合は、 `rocksdb.max-sub-compactions`を`2`または`3`に設定してください。この設定項目は、単一の圧縮ジョブで許可されるサブスレッドの数を示します。デフォルト値は、TiKV 4.0 では`3` 、TiKV 3.0 では`1`です。 - - 理由が memtable 数に関連している場合は、すべての列の`max-write-buffer-number` (デフォルトでは`5` ) を増やすことをお勧めします。 - - 理由がレベル 0 のファイル制限に関連している場合は、次のパラメータの値を`64`以上に増やすことをお勧めします。 + - 保留中の圧縮バイトに関連する理由によって発生した場合は、 `rocksdb.max-sub-compactions`を`2`または`3`に設定してください。この設定項目は、単一の圧縮ジョブで許可されるサブスレッドの数を示します。デフォルト値は、TiKV 4.0 では`3` 、TiKV 3.0 では`1`です。 + - 理由が memtable 数に関連している場合は、すべての列の`max-write-buffer-number` (デフォルトでは`5` ) を増やすことをお勧めします。 + - 理由がレベル 0 のファイル制限に関連している場合は、次のパラメータの値を`64`以上に増やすことをお勧めします。 ``` rocksdb.defaultcf.level0-slowdown-writes-trigger diff --git a/two-data-centers-in-one-city-deployment.md b/two-data-centers-in-one-city-deployment.md index 69932529b1655..0765bd0b31026 100644 --- a/two-data-centers-in-one-city-deployment.md +++ b/two-data-centers-in-one-city-deployment.md @@ -21,16 +21,16 @@ TiDBは通常、高可用性と災害復旧機能を確保するために、マ クラスター展開のアーキテクチャは次のとおりです。 -- クラスターには6つのレプリカがあります。AZ1には3つのVoterレプリカ、AZ2には2つのVoterレプリカと1つのLearnerレプリカがあります。TiKVコンポーネントでは、各ラックに適切なラベルが付けられています。 -- ユーザーにとって透過的なデータの一貫性と高可用性を確保するために、 Raftプロトコルが採用されています。 +- クラスターには6つのレプリカがあります。AZ1には3つのVoterレプリカ、AZ2には2つのVoterレプリカと1つのLearnerレプリカがあります。TiKVコンポーネントでは、各ラックに適切なラベルが付けられています。 +- ユーザーにとって透過的なデータの一貫性と高可用性を確保するために、 Raftプロトコルが採用されています。 ![2-AZ-in-1-region architecture](/media/two-dc-replication-1.png) このデプロイメントソリューションでは、クラスタのレプリケーション状態を制御および識別するために3つのステータスを定義しており、これによりTiKVのレプリケーションモードが制限されます。クラスタのレプリケーションモードは、3つのステータス間を自動的かつ適応的に切り替えることができます。詳細については、セクション[ステータススイッチ](#status-switch)をご覧ください。 -- **sync** : 同期レプリケーションモード。このモードでは、災害復旧AZ内の少なくとも1つのレプリカがプライマリAZと同期します。RaftRaftにより、各ログはラベルに基づいてDRに複製されます。 -- **async** : 非同期レプリケーションモード。このモードでは、ディザスタリカバリAZはプライマリAZと完全には同期されません。RaftアルゴリズムはRaftプロトコルに従ってログを複製します。 -- **sync-recover** : 同期リカバリモード。このモードでは、ディザスタリカバリAZはプライマリAZと完全には同期されていません。Raftは徐々にラベルレプリケーションモードに切り替え、ラベル情報をPDに報告します。 +- **sync** : 同期レプリケーションモード。このモードでは、災害復旧AZ内の少なくとも1つのレプリカがプライマリAZと同期します。RaftRaftにより、各ログはラベルに基づいてDRに複製されます。 +- **async** : 非同期レプリケーションモード。このモードでは、ディザスタリカバリAZはプライマリAZと完全には同期されません。RaftアルゴリズムはRaftプロトコルに従ってログを複製します。 +- **sync-recover** : 同期リカバリモード。このモードでは、ディザスタリカバリAZはプライマリAZと完全には同期されていません。Raftは徐々にラベルレプリケーションモードに切り替え、ラベル情報をPDに報告します。 ## コンフィグレーション {#configuration} @@ -204,7 +204,7 @@ cat default.json レプリケーションモードはPDによって制御されます。PD設定ファイルでレプリケーションモードを設定するには、以下のいずれかの方法を使用します。 -- 方法 1: PD 構成ファイルを構成し、クラスターをデプロイします。 +- 方法 1: PD 構成ファイルを構成し、クラスターをデプロイします。 ```toml [replication-mode] @@ -220,7 +220,7 @@ cat default.json pause-region-split = false ``` -- 方法 2: クラスターをデプロイしている場合は、pd-ctl コマンドを使用して PD の構成を変更します。 +- 方法 2: クラスターをデプロイしている場合は、pd-ctl コマンドを使用して PD の構成を変更します。 ```shell config set replication-mode dr-auto-sync @@ -233,13 +233,13 @@ cat default.json 構成項目の説明: -- `replication-mode`は有効にするレプリケーションモードです。上記の例では`dr-auto-sync`に設定されています。デフォルトでは、多数決プロトコルが使用されます。 -- `label-key`は異なる AZ を区別するために使用され、配置ルールに一致する必要があります。この例では、プライマリ AZ は「east」、災害復旧 AZ は「west」です。 -- `primary-replicas`はプライマリ AZ 内の Voter レプリカの数です。 -- `dr-replicas`は、災害復旧 (DR) AZ 内の投票者レプリカの数です。 -- `wait-store-timeout`は、ネットワークの分離または障害発生時に非同期レプリケーションモードに切り替えるまでの待機時間です。ネットワーク障害の時間が待機時間を超えると、非同期レプリケーションモードが有効になります。デフォルトの待機時間は60秒です。 -- `wait-recover-timeout`は、ネットワークが回復した後に状態`sync-recover`に戻るまでの待機時間です。デフォルト値は0秒です。 -- `pause-region-split`は、ステータス`async_wait`および`async`においてリージョン分割操作を一時停止するかどうかを制御します。リージョン分割を一時停止すると、ステータス`sync-recover`でデータを同期する際に DR AZ で一時的な部分的なデータ損失が発生するのを防ぐことができます。デフォルト値は`false`です。 +- `replication-mode`は有効にするレプリケーションモードです。上記の例では`dr-auto-sync`に設定されています。デフォルトでは、多数決プロトコルが使用されます。 +- `label-key`は異なる AZ を区別するために使用され、配置ルールに一致する必要があります。この例では、プライマリ AZ は「east」、災害復旧 AZ は「west」です。 +- `primary-replicas`はプライマリ AZ 内の Voter レプリカの数です。 +- `dr-replicas`は、災害復旧 (DR) AZ 内の投票者レプリカの数です。 +- `wait-store-timeout`は、ネットワークの分離または障害発生時に非同期レプリケーションモードに切り替えるまでの待機時間です。ネットワーク障害の時間が待機時間を超えると、非同期レプリケーションモードが有効になります。デフォルトの待機時間は60秒です。 +- `wait-recover-timeout`は、ネットワークが回復した後に状態`sync-recover`に戻るまでの待機時間です。デフォルト値は0秒です。 +- `pause-region-split`は、ステータス`async_wait`および`async`においてリージョン分割操作を一時停止するかどうかを制御します。リージョン分割を一時停止すると、ステータス`sync-recover`でデータを同期する際に DR AZ で一時的な部分的なデータ損失が発生するのを防ぐことができます。デフォルト値は`false`です。 クラスターの現在のレプリケーション ステータスを確認するには、次の API を使用します。 @@ -261,17 +261,17 @@ curl http://pd_ip:pd_port/pd/api/v1/replication_mode/status クラスターのレプリケーション モードは、次の 3 つのステータス間を自動的かつ適応的に切り替えることができます。 -- クラスターが正常な場合、同期レプリケーション モードが有効になり、災害復旧 AZ のデータ整合性が最大限に高まります。 -- 2 つの AZ 間のネットワーク接続に障害が発生した場合、または災害復旧 AZ が故障した場合、事前に設定された保護間隔の後に、クラスターは非同期レプリケーション モードを有効にして、アプリケーションの可用性を確保します。 -- ネットワークが再接続するか、災害復旧AZが復旧すると、TiKVノードはクラスターに再び参加し、データを段階的にレプリケーションします。最終的に、クラスターは同期レプリケーションモードに切り替わります。 +- クラスターが正常な場合、同期レプリケーション モードが有効になり、災害復旧 AZ のデータ整合性が最大限に高まります。 +- 2 つの AZ 間のネットワーク接続に障害が発生した場合、または災害復旧 AZ が故障した場合、事前に設定された保護間隔の後に、クラスターは非同期レプリケーション モードを有効にして、アプリケーションの可用性を確保します。 +- ネットワークが再接続するか、災害復旧AZが復旧すると、TiKVノードはクラスターに再び参加し、データを段階的にレプリケーションします。最終的に、クラスターは同期レプリケーションモードに切り替わります。 ステータススイッチの詳細は次のとおりです。 -1. **初期化**：初期化段階では、クラスターは同期レプリケーションモードになります。PDはステータス情報をTiKVに送信し、すべてのTiKVノードは同期レプリケーションモードに厳密に従って動作します。 +1. **初期化**：初期化段階では、クラスターは同期レプリケーションモードになります。PDはステータス情報をTiKVに送信し、すべてのTiKVノードは同期レプリケーションモードに厳密に従って動作します。 -2. **同期から非同期への切り替え**：PDは定期的にTiKVのハートビート情報をチェックし、TiKVノードに障害が発生したか、切断されているかを判断します。障害が発生したノードの数がプライマリAZ（ `primary-replicas` ）と災害復旧AZ（ `dr-replicas` ）のレプリカ数を超えると、同期レプリケーションモードではデータレプリケーションを提供できなくなり、ステータスを切り替える必要があります。障害または切断の時間が`wait-store-timeout`で設定された時間を超えると、PDはクラスターのステータスを非同期モードに切り替えます。次に、PDはすべてのTiKVノードに非同期のステータスを送信し、TiKVのレプリケーションモードは2つのアベイラビリティゾーンのレプリケーションからネイティブのRaftマジョリティに切り替わります。 +2. **同期から非同期への切り替え**：PDは定期的にTiKVのハートビート情報をチェックし、TiKVノードに障害が発生したか、切断されているかを判断します。障害が発生したノードの数がプライマリAZ（ `primary-replicas` ）と災害復旧AZ（ `dr-replicas` ）のレプリカ数を超えると、同期レプリケーションモードではデータレプリケーションを提供できなくなり、ステータスを切り替える必要があります。障害または切断の時間が`wait-store-timeout`で設定された時間を超えると、PDはクラスターのステータスを非同期モードに切り替えます。次に、PDはすべてのTiKVノードに非同期のステータスを送信し、TiKVのレプリケーションモードは2つのアベイラビリティゾーンのレプリケーションからネイティブのRaftマジョリティに切り替わります。 -3. **非同期から同期への切り替え**: PD は TiKV のハートビート情報を定期的にチェックし、TiKV ノードが再接続されたかどうかを判断します。障害が発生したノードの数がプライマリ AZ ( `primary-replicas` ) と災害復旧 AZ ( `dr-replicas` ) のレプリカ数より少ない場合、同期レプリケーション モードを再度有効にできます。PD は最初にクラスターのステータスを sync-recover に切り替え、そのステータス情報をすべての TiKV ノードに送信します。TiKV のすべてのリージョンは、2 つのアベイラビリティ ゾーンの同期レプリケーション モードに徐々に切り替わり、ハートビート情報を PD に報告します。PD は TiKV リージョンのステータスを記録し、リカバリの進行状況を計算します。すべての TiKV リージョンで切り替えが完了すると、PD はレプリケーション モードを同期に切り替えます。 +3. **非同期から同期への切り替え**: PD は TiKV のハートビート情報を定期的にチェックし、TiKV ノードが再接続されたかどうかを判断します。障害が発生したノードの数がプライマリ AZ ( `primary-replicas` ) と災害復旧 AZ ( `dr-replicas` ) のレプリカ数より少ない場合、同期レプリケーション モードを再度有効にできます。PD は最初にクラスターのステータスを sync-recover に切り替え、そのステータス情報をすべての TiKV ノードに送信します。TiKV のすべてのリージョンは、2 つのアベイラビリティ ゾーンの同期レプリケーション モードに徐々に切り替わり、ハートビート情報を PD に報告します。PD は TiKV リージョンのステータスを記録し、リカバリの進行状況を計算します。すべての TiKV リージョンで切り替えが完了すると、PD はレプリケーション モードを同期に切り替えます。 ### 災害復旧 {#disaster-recovery} @@ -279,10 +279,10 @@ 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 レプリカが失われた場合、クラスターは自動的に非同期レプリケーション モードに切り替わります。 +- 災害復旧 AZ に障害が発生し、いくつかの Voter レプリカが失われた場合、クラスターは自動的に非同期レプリケーション モードに切り替わります。 同期レプリケーションモードになっていないクラスタに災害が発生し、 `RPO = 0`でデータリカバリを実行できない場合: -- Voterレプリカの大部分が失われた場合は、専門ツールを用いた手動介入が必要です。PingCAPまたはコミュニティから復旧ソリューションを[サポートを受ける](/support.md)こともできます。 +- Voterレプリカの大部分が失われた場合は、専門ツールを用いた手動介入が必要です。PingCAPまたはコミュニティから復旧ソリューションを[サポートを受ける](/support.md)こともできます。 diff --git a/upgrade-monitoring-services.md b/upgrade-monitoring-services.md index 09230da4b4d7e..9ae898cbe4417 100644 --- a/upgrade-monitoring-services.md +++ b/upgrade-monitoring-services.md @@ -11,10 +11,10 @@ TiDB クラスターをデプロイすると、 TiUP はクラスターの監視 > **Note:** > -> - 監視サービスが[手動で展開](/deploy-monitoring-services.md)の場合、 TiUPを使用する代わりに、このドキュメントを参照せずに直接アップグレードできます。 -> - TiDBと新しいバージョンの監視サービスとの互換性はテストされていないため、アップグレード後、一部の機能が期待どおりに動作しない可能性があります。問題が発生した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を作成してください。 -> - このドキュメントのアップグレード手順は、 TiUPバージョン 1.9.0 以降に適用されます。そのため、アップグレード前にTiUP のバージョンをご確認ください。 -> - TiUPを使用して TiDB クラスターをアップグレードすると、 TiUP は監視サービスをデフォルトバージョンに再デプロイします。TiDB のアップグレード後、監視サービスのアップグレードを再度実行する必要があります。 +> - 監視サービスが[手動で展開](/deploy-monitoring-services.md)の場合、 TiUPを使用する代わりに、このドキュメントを参照せずに直接アップグレードできます。 +> - TiDBと新しいバージョンの監視サービスとの互換性はテストされていないため、アップグレード後、一部の機能が期待どおりに動作しない可能性があります。問題が発生した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を作成してください。 +> - このドキュメントのアップグレード手順は、 TiUPバージョン 1.9.0 以降に適用されます。そのため、アップグレード前にTiUP のバージョンをご確認ください。 +> - TiUPを使用して TiDB クラスターをアップグレードすると、 TiUP は監視サービスをデフォルトバージョンに再デプロイします。TiDB のアップグレード後、監視サービスのアップグレードを再度実行する必要があります。 ## Prometheusのアップグレード {#upgrade-prometheus} @@ -28,7 +28,7 @@ TiDBとの互換性を高めるため、TiDBインストールパッケージに ### ステップ2. TiDBが提供するPrometheusインストールパッケージをダウンロードする {#step-2-download-the-prometheus-installation-package-provided-by-tidb} -1. TiDBサーバーパッケージをダウンロードし、解凍してください。ダウンロードすることにより、 [プライバシーポリシー](https://www.pingcap.com/privacy-policy/)に同意したことになります。 +1. TiDBサーバーパッケージをダウンロードし、解凍してください。ダウンロードすることにより、 [プライバシーポリシー](https://www.pingcap.com/privacy-policy/)に同意したことになります。 ``` https://download.pingcap.com/tidb-community-server-{version}-linux-{arch}.tar.gz @@ -38,7 +38,7 @@ TiDBとの互換性を高めるため、TiDBインストールパッケージに > > リンク内の`{version}` TiDBのバージョン番号を示し、 `{arch}`システムのアーキテクチャ（ `amd64`または`arm64`を示します。例えば、 `amd64`アーキテクチャの`v8.5.4`のダウンロードリンクは`https://download.pingcap.com/tidb-community-toolkit-v8.5.4-linux-amd64.tar.gz`です。 -2. 抽出したファイルで、 `prometheus-v{version}-linux-amd64.tar.gz`を見つけて抽出します。 +2. 抽出したファイルで、 `prometheus-v{version}-linux-amd64.tar.gz`を見つけて抽出します。 ```bash tar -xzf prometheus-v{version}-linux-amd64.tar.gz @@ -46,8 +46,8 @@ TiDBとの互換性を高めるため、TiDBインストールパッケージに ### ステップ3. TiUPが使用できる新しいPrometheusパッケージを作成する {#step-3-create-a-new-prometheus-package-that-tiup-can-use} -1. [ステップ1](#step-1-download-a-new-prometheus-installation-package-from-the-prometheus-website)で抽出したファイルをコピーし、コピーしたファイルを使用して[ステップ2](#step-2-download-the-prometheus-installation-package-provided-by-tidb)で抽出した`./prometheus-v{version}-linux-amd64/prometheus`ディレクトリ内のファイルを置き換えます。 -2. `./prometheus-v{version}-linux-amd64`ディレクトリを再圧縮し、新しい圧縮パッケージに`prometheus-v{new-version}.tar.gz`という名前を付けます。`{new-version}`は必要に応じて指定できます。 +1. [ステップ1](#step-1-download-a-new-prometheus-installation-package-from-the-prometheus-website)で抽出したファイルをコピーし、コピーしたファイルを使用して[ステップ2](#step-2-download-the-prometheus-installation-package-provided-by-tidb)で抽出した`./prometheus-v{version}-linux-amd64/prometheus`ディレクトリ内のファイルを置き換えます。 +2. `./prometheus-v{version}-linux-amd64`ディレクトリを再圧縮し、新しい圧縮パッケージに`prometheus-v{new-version}.tar.gz`という名前を付けます。`{new-version}`は必要に応じて指定できます。 ```bash cd prometheus-v{version}-linux-amd64 @@ -72,12 +72,12 @@ TiDBとの互換性を高めるため、TiDBインストールパッケージに ### ステップ1. Grafanaのウェブサイトから新しいGrafanaインストールパッケージをダウンロードします。 {#step-1-download-a-new-grafana-installation-package-from-the-grafana-website} -1. [Grafanaのダウンロードページ](https://grafana.com/grafana/download?pg=get&plcmt=selfmanaged-box1-cta1)から新しいインストールパッケージをダウンロードしてください。ニーズに応じて、 `OSS`または`Enterprise`エディションのいずれかを選択できます。 -2. ダウンロードしたパッケージを解凍します。 +1. [Grafanaのダウンロードページ](https://grafana.com/grafana/download?pg=get&plcmt=selfmanaged-box1-cta1)から新しいインストールパッケージをダウンロードしてください。ニーズに応じて、 `OSS`または`Enterprise`エディションのいずれかを選択できます。 +2. ダウンロードしたパッケージを解凍します。 ### ステップ2. TiDBが提供するGrafanaインストールパッケージをダウンロードする {#step-2-download-the-grafana-installation-package-provided-by-tidb} -1. TiDBサーバーパッケージをダウンロードし、解凍してください。ダウンロードすることにより、 [プライバシーポリシー](https://www.pingcap.com/privacy-policy/)に同意したことになります。 +1. TiDBサーバーパッケージをダウンロードし、解凍してください。ダウンロードすることにより、 [プライバシーポリシー](https://www.pingcap.com/privacy-policy/)に同意したことになります。 ``` https://download.pingcap.com/tidb-community-server-{version}-linux-{arch}.tar.gz @@ -87,7 +87,7 @@ TiDBとの互換性を高めるため、TiDBインストールパッケージに > > リンク内の`{version}` TiDBのバージョン番号を示し、 `{arch}`システムのアーキテクチャ（ `amd64`または`arm64`を示します。例えば、 `amd64`アーキテクチャの`v8.5.4`のダウンロードリンクは`https://download.pingcap.com/tidb-community-toolkit-v8.5.4-linux-amd64.tar.gz`です。 -2. 抽出したファイルで、 `grafana-v{version}-linux-amd64.tar.gz`を見つけて抽出します。 +2. 抽出したファイルで、 `grafana-v{version}-linux-amd64.tar.gz`を見つけて抽出します。 ```bash tar -xzf grafana-v{version}-linux-amd64.tar.gz @@ -95,8 +95,8 @@ TiDBとの互換性を高めるため、TiDBインストールパッケージに ### ステップ3. TiUPが使用できる新しいGrafanaパッケージを作成する {#step-3-create-a-new-grafana-package-that-tiup-can-use} -1. [ステップ1](#step-1-download-a-new-grafana-installation-package-from-the-grafana-website)で抽出したファイルをコピーし、コピーしたファイルを使用して[ステップ2](#step-2-download-the-grafana-installation-package-provided-by-tidb)で抽出した`./grafana-v{version}-linux-amd64/`ディレクトリ内のファイルを置き換えます。 -2. `./grafana-v{version}-linux-amd64`ディレクトリを再圧縮し、新しい圧縮パッケージに`grafana-v{new-version}.tar.gz`という名前を付けます。`{new-version}`は必要に応じて指定できます。 +1. [ステップ1](#step-1-download-a-new-grafana-installation-package-from-the-grafana-website)で抽出したファイルをコピーし、コピーしたファイルを使用して[ステップ2](#step-2-download-the-grafana-installation-package-provided-by-tidb)で抽出した`./grafana-v{version}-linux-amd64/`ディレクトリ内のファイルを置き換えます。 +2. `./grafana-v{version}-linux-amd64`ディレクトリを再圧縮し、新しい圧縮パッケージに`grafana-v{new-version}.tar.gz`という名前を付けます。`{new-version}`は必要に応じて指定できます。 ```bash cd grafana-v{version}-linux-amd64 diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index 4bb37a4d1d668..9917acc58b836 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -9,29 +9,29 @@ summary: TiUPを使用してTiDBをアップグレードする方法を学びま > **Warning:** > -> 1. TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 CentOS Linux 7 で実行されているクラスターを v8.5 にアップグレードする場合は、クラスターが使用できなくなるリスクを避けるために、必ず TiDB v8.5.1 以降のバージョンを使用してください。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 -> 2. TiFlash を5.3 より前のバージョンから 5.3 以降にオンラインでアップグレードすることはできません。代わりに、まず以前のバージョンのTiFlashインスタンスをすべて停止し、その後オフラインでクラスタをアップグレードする必要があります。TiDB や TiKV などの他のコンポーネントがオンラインアップグレードをサポートしていない場合は、[オンラインアップグレード](#online-upgrade)の警告の手順に従ってください。 -> 3. アップグレード処理中はDDLステートメントを実行**しないでください**。実行すると、未定義の動作が発生する可能性があります。 -> 4. TiDB クラスターで DDL ステートメントが実行されている間は、クラスターをアップグレード**しないでください**(通常、 `ADD INDEX`や列型の変更など、時間のかかる DDL ステートメントの場合)。アップグレードの前に、 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)コマンドを使用して、TiDB クラスターで DDL ジョブが実行中かどうかを確認することをお勧めします。クラスターで DDL ジョブが実行されている場合は、クラスターをアップグレードする前に、DDL の実行が完了するまで待つか、 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md)コマンドを使用して DDL ジョブをキャンセルしてください。 -> 5. アップグレード前の TiDB バージョンが 7.1.0 以降の場合は、前述の警告 3 と 4 を無視してかまいません。詳細については、 [TiDB スムーズアップグレードの使用に関する制限](/smooth-upgrade-tidb.md#limitations)を参照してください。 -> 6. TiUPを使用して TiDB クラスターをアップグレードする前に、 [ユーザー操作に関する制限](/smooth-upgrade-tidb.md#limitations-on-user-operations)を必ずお読みください。 +> 1. TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 CentOS Linux 7 で実行されているクラスターを v8.5 にアップグレードする場合は、クラスターが使用できなくなるリスクを避けるために、必ず TiDB v8.5.1 以降のバージョンを使用してください。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 +> 2. TiFlash を5.3 より前のバージョンから 5.3 以降にオンラインでアップグレードすることはできません。代わりに、まず以前のバージョンのTiFlashインスタンスをすべて停止し、その後オフラインでクラスタをアップグレードする必要があります。TiDB や TiKV などの他のコンポーネントがオンラインアップグレードをサポートしていない場合は、[オンラインアップグレード](#online-upgrade)の警告の手順に従ってください。 +> 3. アップグレード処理中はDDLステートメントを実行**しないでください**。実行すると、未定義の動作が発生する可能性があります。 +> 4. TiDB クラスターで DDL ステートメントが実行されている間は、クラスターをアップグレード**しないでください**(通常、 `ADD INDEX`や列型の変更など、時間のかかる DDL ステートメントの場合)。アップグレードの前に、 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)コマンドを使用して、TiDB クラスターで DDL ジョブが実行中かどうかを確認することをお勧めします。クラスターで DDL ジョブが実行されている場合は、クラスターをアップグレードする前に、DDL の実行が完了するまで待つか、 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md)コマンドを使用して DDL ジョブをキャンセルしてください。 +> 5. アップグレード前の TiDB バージョンが 7.1.0 以降の場合は、前述の警告 3 と 4 を無視してかまいません。詳細については、 [TiDB スムーズアップグレードの使用に関する制限](/smooth-upgrade-tidb.md#limitations)を参照してください。 +> 6. TiUPを使用して TiDB クラスターをアップグレードする前に、 [ユーザー操作に関する制限](/smooth-upgrade-tidb.md#limitations-on-user-operations)を必ずお読みください。 > **Note:** > -> - アップグレードするクラスターが v6.2 より前の場合、シナリオによってはクラスターを v6.2 以降のバージョンにアップグレードすると、アップグレードが停止する可能性があります。 [問題を解決する方法](#how-to-fix-the-issue-that-the-upgrade-gets-stuck-when-upgrading-to-v620-or-later-versions)を参照してください。 -> - TiDBノードは[`server-version`](/tidb-configuration-file.md#server-version)構成項目の値を使用して現在のTiDBバージョンを確認します。そのため、予期しない動作を避けるため、TiDBクラスタをアップグレードする前に、 `server-version`の値を空にするか、現在のTiDBクラスタの実際のバージョンに設定する必要があります。 -> - [`performance.force-init-stats`](/tidb-configuration-file.md#force-init-stats-new-in-v657-and-v710)設定項目を`ON`に設定すると、TiDB の起動時間が長くなり、起動タイムアウトやアップグレードの失敗が発生する可能性があります。この問題を回避するには、 TiUPの待機タイムアウトを長く設定することをお勧めします。 -> - 影響を受ける可能性のあるシナリオ： -> - 元のクラスタバージョンはv6.5.7およびv7.1.0（ `performance.force-init-stats`をまだサポートしていない）より前のバージョンであり、ターゲットバージョンはv7.2.0以降です。 -> - 元のクラスタバージョンはv6.5.7およびv7.1.0以降であり、 `performance.force-init-stats`構成項目は`ON`に設定されています。 +> - アップグレードするクラスターが v6.2 より前の場合、シナリオによってはクラスターを v6.2 以降のバージョンにアップグレードすると、アップグレードが停止する可能性があります。 [問題を解決する方法](#how-to-fix-the-issue-that-the-upgrade-gets-stuck-when-upgrading-to-v620-or-later-versions)を参照してください。 +> - TiDBノードは[`server-version`](/tidb-configuration-file.md#server-version)構成項目の値を使用して現在のTiDBバージョンを確認します。そのため、予期しない動作を避けるため、TiDBクラスタをアップグレードする前に、 `server-version`の値を空にするか、現在のTiDBクラスタの実際のバージョンに設定する必要があります。 +> - [`performance.force-init-stats`](/tidb-configuration-file.md#force-init-stats-new-in-v657-and-v710)設定項目を`ON`に設定すると、TiDB の起動時間が長くなり、起動タイムアウトやアップグレードの失敗が発生する可能性があります。この問題を回避するには、 TiUPの待機タイムアウトを長く設定することをお勧めします。 +> - 影響を受ける可能性のあるシナリオ： +> - 元のクラスタバージョンはv6.5.7およびv7.1.0（ `performance.force-init-stats`をまだサポートしていない）より前のバージョンであり、ターゲットバージョンはv7.2.0以降です。 +> - 元のクラスタバージョンはv6.5.7およびv7.1.0以降であり、 `performance.force-init-stats`構成項目は`ON`に設定されています。 > -> - `performance.force-init-stats`設定項目の値を確認してください。 +> - `performance.force-init-stats`設定項目の値を確認してください。 > > ``` > SHOW CONFIG WHERE type = 'tidb' AND name = 'performance.force-init-stats'; > ``` > -> - TiUPの待機タイムアウトは、コマンドラインオプション[`--wait-timeout`](/tiup/tiup-component-cluster.md#--wait-timeout)を追加することで延長できます。例えば、以下のコマンドを実行すると、待機タイムアウトを1200秒（20分）に設定できます。 +> - TiUPの待機タイムアウトは、コマンドラインオプション[`--wait-timeout`](/tiup/tiup-component-cluster.md#--wait-timeout)を追加することで延長できます。例えば、以下のコマンドを実行すると、待機タイムアウトを1200秒（20分）に設定できます。 > > ```shell > tiup update cluster --wait-timeout 1200 [other options] @@ -45,16 +45,16 @@ summary: TiUPを使用してTiDBをアップグレードする方法を学びま > > 元のクラスターが v7.1.0 以前の場合、v7.2.0 以降にアップグレードすると、 [`performance.lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-new-in-v710)の導入により、統計情報の読み込み時間が大幅に短縮されます。この場合、アップグレード前の`init stats info time`は、アップグレード後の読み込み時間よりも長くなります。 > -> - TiDB のローリング アップグレード期間を短縮したい場合、およびアップグレード中の初期統計情報の欠落による潜在的なパフォーマンスへの影響がクラスターで許容できる場合は、TiUP を使用して対象インスタンスの設定を変更することで、アップグレード前に`performance.force-init-stats` `OFF`に[TiUPを使用して対象インスタンスの設定を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)。アップグレードの完了後、必要に応じてこの設定を再評価して元に戻すことができます。 +> - TiDB のローリング アップグレード期間を短縮したい場合、およびアップグレード中の初期統計情報の欠落による潜在的なパフォーマンスへの影響がクラスターで許容できる場合は、TiUP を使用して対象インスタンスの設定を変更することで、アップグレード前に`performance.force-init-stats` `OFF`に[TiUPを使用して対象インスタンスの設定を変更する](/maintain-tidb-using-tiup.md#modify-the-configuration)。アップグレードの完了後、必要に応じてこの設定を再評価して元に戻すことができます。 ## アップグレードに関する注意事項 {#upgrade-caveat} -- TiDBは現在、アップグレード後にバージョンをダウングレードしたり、以前のバージョンに戻したりすることをサポートしていません。 -- TiCDC、 TiFlash、およびその他のコンポーネントのバージョンアップグレードをサポートします。 -- クラスターが TiCDC クラシックアーキテクチャ(v8.1.2 など) を使用している場合は、メジャー バージョン間のアップグレード中に変更フィードを実行し続けないでください。この場合、次の手順を順番に実行します。すべての変更フィードを一時停止し、TiCDC をアップグレードし、TiDB クラスターをアップグレードし、すべての変更フィードを再開します。詳細については、 [以前のバージョンからのアップグレードに関する互換性に関する注意事項](/ticdc/ticdc-compatibility.md#compatibility-notes-for-upgrading-from-earlier-versions)を参照してください。 -- 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)を参照してください。 +- TiDBは現在、アップグレード後にバージョンをダウングレードしたり、以前のバージョンに戻したりすることをサポートしていません。 +- TiCDC、 TiFlash、およびその他のコンポーネントのバージョンアップグレードをサポートします。 +- クラスターが 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)を参照してください。 ## 準備 {#preparations} @@ -66,14 +66,14 @@ TiDBのリリースノートに記載されている互換性の変更点を確 以下は、v8.4.0 から最新バージョン (v8.5.4) にアップグレードする際に必要なリリースノートです。v8.3.0 以前のバージョンから最新バージョンにアップグレードする場合は、中間バージョンの[リリースノート](/releases/_index.md)も確認する必要があるかもしれません。 -- TiDB v8.5.0 [互換性の変更](/releases/release-8.5.0.md#compatibility-changes) -- TiDB v8.5.1[リリースノート](/releases/release-8.5.1.md) -- TiDB v8.5.2[リリースノート](/releases/release-8.5.2.md) -- TiDB v8.5.3 [互換性の変更](/releases/release-8.5.3.md#compatibility-changes) -- TiDB v8.5.4 [互換性の変更](/releases/release-8.5.4.md#compatibility-changes) -- TiDB v8.5.5 [互換性の変更](https://docs.pingcap.com/tidb/stable/release-8.5.5/#compatibility-changes) -- TiDB v8.5.6 [互換性の変更](https://docs.pingcap.com/tidb/stable/release-8.5.6/#compatibility-changes) -- TiDB v8.5.7 [互換性の変更](https://docs.pingcap.com/tidb/stable/release-8.5.7/#compatibility-changes) +- TiDB v8.5.0 [互換性の変更](/releases/release-8.5.0.md#compatibility-changes) +- TiDB v8.5.1[リリースノート](/releases/release-8.5.1.md) +- TiDB v8.5.2[リリースノート](/releases/release-8.5.2.md) +- TiDB v8.5.3 [互換性の変更](/releases/release-8.5.3.md#compatibility-changes) +- TiDB v8.5.4 [互換性の変更](/releases/release-8.5.4.md#compatibility-changes) +- TiDB v8.5.5 [互換性の変更](https://docs.pingcap.com/tidb/stable/release-8.5.5/#compatibility-changes) +- TiDB v8.5.6 [互換性の変更](https://docs.pingcap.com/tidb/stable/release-8.5.6/#compatibility-changes) +- TiDB v8.5.7 [互換性の変更](https://docs.pingcap.com/tidb/stable/release-8.5.7/#compatibility-changes) ### ステップ2： TiUPまたはTiUPオフラインミラーをアップグレードする {#step-2-upgrade-tiup-or-tiup-offline-mirror} @@ -85,14 +85,14 @@ TiDBクラスタをアップグレードする前に、まずTiUPまたはTiUP > > アップグレードするクラスターの制御マシンが`https://tiup-mirrors.pingcap.com`にアクセスできない場合は、このセクションをスキップして、 [TiUPオフラインミラーをアップグレード](#upgrade-tiup-offline-mirror)を参照してください。 -1. TiUPのバージョンをアップグレードしてください。TiUPのバージョンは`1.11.3`以降を推奨します。 +1. TiUPのバージョンをアップグレードしてください。TiUPのバージョンは`1.11.3`以降を推奨します。 ```shell tiup update --self tiup --version ``` -2. TiUP クラスタのバージョンをアップグレードしてください。TiUP クラスタのTiUPは`1.11.3`以降を推奨します。 +2. TiUP クラスタのバージョンをアップグレードしてください。TiUP クラスタのTiUPは`1.11.3`以降を推奨します。 ```shell tiup update cluster @@ -137,29 +137,29 @@ tiup update cluster > > 以下のいずれかの状況に該当する場合は、この手順をスキップしてください。 > -> - 元のクラスターの構成パラメータを変更していません。または、 `tiup cluster`を使用して構成パラメータを変更しましたが、それ以上の変更は必要ありません。 -> - アップグレード後、変更されていない設定項目については、v8.5.4のデフォルトのパラメータ値を使用します。 +> - 元のクラスターの構成パラメータを変更していません。または、 `tiup cluster`を使用して構成パラメータを変更しましたが、それ以上の変更は必要ありません。 +> - アップグレード後、変更されていない設定項目については、v8.5.4のデフォルトのパラメータ値を使用します。 -1. トポロジーファイルを編集するには、 `vi`編集モードに入ります。 +1. トポロジーファイルを編集するには、 `vi`編集モードに入ります。 ```shell tiup cluster edit-config ``` -2. [トポロジー](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)設定テンプレートのフォーマットを参照し、トポロジファイルの`server_configs`セクションに変更したいパラメータを入力します。 +2. [トポロジー](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml)設定テンプレートのフォーマットを参照し、トポロジファイルの`server_configs`セクションに変更したいパラメータを入力します。 -3. 変更後、 「: + w + q」と入力して変更を保存し、編集モードを終了します。変更を確定するには「Y」と入力してください。 +3. 変更後、 「: + w + q」と入力して変更を保存し、編集モードを終了します。変更を確定するには「Y」と入力してください。 ### ステップ4：クラスターのDDLとバックアップの状態を確認します {#step-4-check-the-ddl-and-backup-status-of-the-cluster} アップグレード中に予期せぬ動作やその他の問題が発生するのを避けるため、アップグレード前に以下の項目を確認することをお勧めします。 -- クラスタDDL: +- クラスタDDL: - - [スムーズなアップグレード](/smooth-upgrade-tidb.md)を使用して TiDB を v8.1.0 以降にアップグレードし、[分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)が有効になっている場合は、アップグレードする前に DXF を無効にすることをお勧めします。そうしないと、アップグレード プロセス中に追加されたインデックスがデータと矛盾し、アップグレードが失敗する可能性があります。 - - な を使用しない場合は、 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)[スムーズなアップグレード](/smooth-upgrade-tidb.md)を使用して、実行中の DDL ジョブが存在するかどうかを確認することをお勧めします。実行中の DDL ジョブが存在する場合は、アップグレードを実行する前に、ジョブの実行が完了するまで待つか、 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md)ステートメントを使用してキャンセルしてください。 + - [スムーズなアップグレード](/smooth-upgrade-tidb.md)を使用して TiDB を v8.1.0 以降にアップグレードし、[分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)が有効になっている場合は、アップグレードする前に DXF を無効にすることをお勧めします。そうしないと、アップグレード プロセス中に追加されたインデックスがデータと矛盾し、アップグレードが失敗する可能性があります。 + - な を使用しない場合は、 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)[スムーズなアップグレード](/smooth-upgrade-tidb.md)を使用して、実行中の DDL ジョブが存在するかどうかを確認することをお勧めします。実行中の DDL ジョブが存在する場合は、アップグレードを実行する前に、ジョブの実行が完了するまで待つか、 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md)ステートメントを使用してキャンセルしてください。 -- クラスタのバックアップ：クラスタ内でバックアップまたはリストアタスクが実行中かどうかを確認するには[`SHOW [BACKUPS|RESTORES]`](/sql-statements/sql-statement-show-backups.md)コマンドを実行することをお勧めします。実行中の場合は、アップグレードを実行する前にタスクが完了するまでお待ちください。 +- クラスタのバックアップ：クラスタ内でバックアップまたはリストアタスクが実行中かどうかを確認するには[`SHOW [BACKUPS|RESTORES]`](/sql-statements/sql-statement-show-backups.md)コマンドを実行することをお勧めします。実行中の場合は、アップグレードを実行する前にタスクが完了するまでお待ちください。 ### ステップ5：現在のクラスターの健全性状態を確認する {#step-5-check-the-health-status-of-the-current-cluster} @@ -171,8 +171,8 @@ tiup cluster check --cluster コマンドが実行されると、「リージョンステータス」のチェック結果が出力されます。 -- 結果が「すべてのリージョンは正常です」であれば、現在のクラスター内のすべてのリージョンは正常であり、アップグレードを続行できます。 -- 結果が「リージョンが完全に正常ではありません：m個のミスピア、n個の保留ピア」で、「他の操作を行う前に、異常なリージョンを修正してください。」というメッセージが表示される場合、現在のクラスタ内の一部のリージョンに異常があります。チェック結果が「すべてのリージョンが正常です」になるまで、異常のトラブルシューティングを行う必要があります。その後、アップグレードを続行できます。 +- 結果が「すべてのリージョンは正常です」であれば、現在のクラスター内のすべてのリージョンは正常であり、アップグレードを続行できます。 +- 結果が「リージョンが完全に正常ではありません：m個のミスピア、n個の保留ピア」で、「他の操作を行う前に、異常なリージョンを修正してください。」というメッセージが表示される場合、現在のクラスタ内の一部のリージョンに異常があります。チェック結果が「すべてのリージョンが正常です」になるまで、異常のトラブルシューティングを行う必要があります。その後、アップグレードを続行できます。 ## TiDBクラスタをアップグレードする {#upgrade-the-tidb-cluster} @@ -200,16 +200,16 @@ tiup cluster upgrade v8.5.4 > **Note:** > -> - オンラインアップグレードは、TiUPの固定コンポーネントアップグレード順序に従って行われます。各コンポーネントタイプ内では、インスタンスが順次アップグレードされます。 +> - オンラインアップグレードは、TiUPの固定コンポーネントアップグレード順序に従って行われます。各コンポーネントタイプ内では、インスタンスが順次アップグレードされます。 > -> - **TiFlash** ： TiFlashは常に最初にアップグレードされます。クラスタにTiFlashが含まれている場合、 TiUPは他のコンポーネント（PD、TiKV、TiDBなど）に進む前に、すべてのTiFlashインスタンスのローリングアップグレードを実行します。クラスタにデプロイされていないコンポーネントタイプはスキップされます。 -> - **TiKV** ：TiKVのアップグレード中、 TiUPはインスタンスを停止する前に、PDを介してTiKVストアからすべてのリージョンリーダーを削除します。リーダー転送のデフォルトのタイムアウトは5分（300秒）です。タイムアウトに達すると、 TiUPはリーダー削除の完了を待たずにインスタンスを直接停止します。 +> - **TiFlash** ： TiFlashは常に最初にアップグレードされます。クラスタにTiFlashが含まれている場合、 TiUPは他のコンポーネント（PD、TiKV、TiDBなど）に進む前に、すべてのTiFlashインスタンスのローリングアップグレードを実行します。クラスタにデプロイされていないコンポーネントタイプはスキップされます。 +> - **TiKV** ：TiKVのアップグレード中、 TiUPはインスタンスを停止する前に、PDを介してTiKVストアからすべてのリージョンリーダーを削除します。リーダー転送のデフォルトのタイムアウトは5分（300秒）です。タイムアウトに達すると、 TiUPはリーダー削除の完了を待たずにインスタンスを直接停止します。 > -> - `--force`パラメータを使用すると、リーダーを削除せずにクラスターを即座にアップグレードできます。ただし、アップグレード中に発生したエラーは無視されるため、アップグレードの失敗に関する通知は届きません。したがって、 `--force`パラメータは慎重に使用してください。 +> - `--force`パラメータを使用すると、リーダーを削除せずにクラスターを即座にアップグレードできます。ただし、アップグレード中に発生したエラーは無視されるため、アップグレードの失敗に関する通知は届きません。したがって、 `--force`パラメータは慎重に使用してください。 > -> - 安定したパフォーマンスを維持するには、TiKV インスタンスを停止する前に、インスタンス内のすべてのリーダーが強制終了されていることを確認してください。 `--transfer-timeout`を、例えば`--transfer-timeout 3600` (単位: 秒) のように、より大きな値に設定できます。 +> - 安定したパフォーマンスを維持するには、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} @@ -236,19 +236,19 @@ tiup cluster upgrade -h | grep "version" #### オフラインアップグレード {#offline-upgrade} -1. オフラインアップグレードを行う前に、まずクラスター全体を停止する必要があります。 +1. オフラインアップグレードを行う前に、まずクラスター全体を停止する必要があります。 ```shell tiup cluster stop ``` -2. `upgrade`コマンドに`--offline`オプションを指定して、オフラインアップグレードを実行します。 ``にはクラスタ名を、 ``にはアップグレード先のバージョン（例: `v8.5.4`）を入力します。 +2. `upgrade`コマンドに`--offline`オプションを指定して、オフラインアップグレードを実行します。 ``にはクラスタ名を、 ``にはアップグレード先のバージョン（例: `v8.5.4`）を入力します。 ```shell tiup cluster upgrade --offline ``` -3. アップグレード後、クラスターは自動的に再起動されません。 `start`コマンドを使用して再起動する必要があります。 +3. アップグレード後、クラスターは自動的に再起動されません。 `start`コマンドを使用して再起動する必要があります。 ```shell tiup cluster start @@ -276,7 +276,7 @@ Cluster version: v8.5.4 アップグレードを再開するには、 `tiup cluster upgrade`コマンドを再度実行してください。アップグレード操作では、既にアップグレード済みのノードが再起動されます。アップグレード済みのノードを再起動したくない場合は、 `replay`サブコマンドを使用して操作を再試行してください。 -1. 操作記録を表示するには、 `tiup cluster audit`を実行してください。 +1. 操作記録を表示するには、 `tiup cluster audit`を実行してください。 ```shell tiup cluster audit @@ -284,7 +284,7 @@ Cluster version: v8.5.4 失敗したアップグレード操作レコードを見つけて、その操作レコードのIDを控えてください。このIDは、次のステップで``値として使用されます。 -2. 対応する操作を再試行するには、 `tiup cluster replay `を実行してください。 +2. 対応する操作を再試行するには、 `tiup cluster replay `を実行してください。 ```shell tiup cluster replay @@ -294,25 +294,25 @@ Cluster version: v8.5.4 バージョン6.2.0以降、TiDBはデフォルトで[並行DDLフレームワーク](/best-practices/ddl-introduction.md#how-the-online-ddl-asynchronous-change-works-in-tidb)を有効にし、同時DDLの実行を可能にしました。このフレームワークは、DDLジョブのストレージをKVキューからテーブルキューに変更します。この変更により、一部のシナリオではアップグレードが停止する可能性があります。この問題が発生する可能性のあるシナリオと、それに対応する解決策を以下に示します。 -- プラグインの読み込みが原因でアップグレードが停止します +- プラグインの読み込みが原因でアップグレードが停止します アップグレード中に、DDLステートメントの実行を必要とする特定のプラグインを読み込むと、アップグレードが停止する可能性があります。 **解決策**：アップグレード中はプラグインをロードしないようにしてください。代わりに、アップグレードが完了した後にのみプラグインをロードしてください。 -- オフラインアップグレードに`kill -9`コマンドを使用しているため、アップグレードが停止します。 +- オフラインアップグレードに`kill -9`コマンドを使用しているため、アップグレードが停止します。 - - 注意事項： `kill -9`コマンドを使用してオフラインアップグレードを実行することは避けてください。どうしても必要な場合は、2 分後に新しいバージョンの TiDB ノードを再起動してください。 - - アップグレードが既に停止している場合は、影響を受けているTiDBノードを再起動してください。問題が発生したばかりの場合は、2分後にノードを再起動することをお勧めします。 + - 注意事項： `kill -9`コマンドを使用してオフラインアップグレードを実行することは避けてください。どうしても必要な場合は、2 分後に新しいバージョンの TiDB ノードを再起動してください。 + - アップグレードが既に停止している場合は、影響を受けているTiDBノードを再起動してください。問題が発生したばかりの場合は、2分後にノードを再起動することをお勧めします。 -- DDL所有者の変更によりアップグレードが停止する +- DDL所有者の変更によりアップグレードが停止する マルチインスタンス環境では、ネットワーク障害やハードウェア障害によってDDL所有者が変更される可能性があります。アップグレードフェーズで未完了のDDLステートメントが存在する場合、アップグレードが停止する可能性があります。 **解決**： - 1. 停止した TiDB ノードを終了します ( `kill -9`の使用は避けてください)。 - 2. 新しいバージョンのTiDBノードを再起動してください。 + 1. 停止した TiDB ノードを終了します ( `kill -9`の使用は避けてください)。 + 2. 新しいバージョンのTiDBノードを再起動してください。 ### 退去リーダーはアップグレード中に待ち時間が長すぎました。この手順をスキップしてアップグレードを迅速に行うにはどうすればよいでしょうか？ {#the-evict-leader-has-waited-too-long-during-the-upgrade-how-to-skip-this-step-for-a-quick-upgrade} diff --git a/user-account-management.md b/user-account-management.md index e5fd4c8678483..8d8a63c054cbc 100644 --- a/user-account-management.md +++ b/user-account-management.md @@ -27,8 +27,8 @@ 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)更新が不完全になる可能性があるため、アカウントの作成または変更にはこの方法を使用しないことをお勧めします。 +- アカウントを作成して権限を確立するための標準のアカウント管理 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)更新が不完全になる可能性があるため、アカウントの作成または変更にはこの方法を使用しないことをお勧めします。 [サードパーティのGUIツール](/develop/dev-guide-third-party-support.md#gui)を使用してアカウントを作成することもできます。 @@ -44,9 +44,9 @@ CREATE USER 'test'@'127.0.0.1' IDENTIFIED BY 'xxx'; TiDBアカウント名はユーザー名とホスト名で構成されます。アカウント名の構文は「user_name@host_name」です。 -- `user_name`は大文字と小文字が区別されます。 +- `user_name`は大文字と小文字が区別されます。 -- `host_name`はホスト名またはIPアドレスで、ワイルドカード`%`または`_`をサポートします。例えば、ホスト名`'%'`はすべてのホストに一致し、ホスト名`'192.168.1.%'`はサブネット内のすべてのホストに一致します。 +- `host_name`はホスト名またはIPアドレスで、ワイルドカード`%`または`_`をサポートします。例えば、ホスト名`'%'`はすべてのホストに一致し、ホスト名`'192.168.1.%'`はサブネット内のすべてのホストに一致します。 ホストはあいまい一致をサポートします: @@ -151,13 +151,13 @@ TiDBは、リソースグループを使用してユーザーが消費するリ TiDBはパスワードを[`mysql.user`](/mysql-schema/mysql-schema-user.md)システムテーブルに保存します。パスワードの割り当てまたは更新操作は、 `CREATE USER`権限、または`mysql`データベース権限（新規アカウント作成の`INSERT`権限、既存アカウント更新の`UPDATE`権限）を持つユーザーのみに許可されます。 -- 新しいアカウントを作成するときにパスワードを割り当てるには、 [`CREATE USER`](/sql-statements/sql-statement-create-user.md)を使用し、 `IDENTIFIED BY`句を含めます。 +- 新しいアカウントを作成するときにパスワードを割り当てるには、 [`CREATE USER`](/sql-statements/sql-statement-create-user.md)を使用し、 `IDENTIFIED BY`句を含めます。 ```sql CREATE USER 'test'@'localhost' IDENTIFIED BY 'mypass'; ``` -- To assign or change a password for an existing account, use [`SET PASSWORD FOR`](/sql-statements/sql-statement-set-password.md) or [`ALTER USER`](/sql-statements/sql-statement-alter-user.md): +- To assign or change a password for an existing account, use [`SET PASSWORD FOR`](/sql-statements/sql-statement-set-password.md) or [`ALTER USER`](/sql-statements/sql-statement-alter-user.md): ```sql SET PASSWORD FOR 'root'@'%' = 'xxx'; @@ -171,47 +171,47 @@ TiDBはパスワードを[`mysql.user`](/mysql-schema/mysql-schema-user.md)シ ## `root`パスワードを忘れた {#forget-the-root-password} -1. 設定ファイルを変更します。 +1. 設定ファイルを変更します。 - 1. tidb-server インスタンスの 1 つが配置されているマシンにログインします。 - 2. TiDB ノードのデプロイメント ディレクトリの下の`conf`ディレクトリに入り、 `tidb.toml`構成ファイルを見つけます。 - 3. 設定ファイルの[`security`](/tidb-configuration-file.md#security)セクションに設定項目[`skip-grant-table`](/tidb-configuration-file.md)を追加します。`security`がない場合は、 `tidb.toml`設定ファイルの末尾に次の2行を追加します。 + 1. tidb-server インスタンスの 1 つが配置されているマシンにログインします。 + 2. TiDB ノードのデプロイメント ディレクトリの下の`conf`ディレクトリに入り、 `tidb.toml`構成ファイルを見つけます。 + 3. 設定ファイルの[`security`](/tidb-configuration-file.md#security)セクションに設定項目[`skip-grant-table`](/tidb-configuration-file.md)を追加します。`security`がない場合は、 `tidb.toml`設定ファイルの末尾に次の2行を追加します。 ``` [security] skip-grant-table = true ``` -2. tidb-server プロセスを停止します。 +2. tidb-server プロセスを停止します。 - 1. tidb-server プロセスを表示する。 + 1. tidb-server プロセスを表示する。 ```bash ps aux | grep tidb-server ``` - 2. tidb-server に対応するプロセス ID (PID) を見つけて、 `kill`コマンドを使用してプロセスを停止します。 + 2. tidb-server に対応するプロセス ID (PID) を見つけて、 `kill`コマンドを使用してプロセスを停止します。 ```bash kill -9 ``` -3. 変更した構成を使用して TiDB を起動します。 +3. 変更した構成を使用して TiDB を起動します。 > **Note:** > > TiDBプロセスを開始する前に`skip-grant-table`を設定すると、オペレーティングシステムのユーザーチェックが開始されます。オペレーティングシステムの`root`ユーザーのみがTiDBプロセスを開始できます。 - 1. TiDB ノードのデプロイメント ディレクトリの下の`scripts`ディレクトリを入力します。 - 2. Switch to the `root` account of the operating system. - 3. ディレクトリ内の`run_tidb.sh`スクリプトをフォアグラウンドで実行します。 - 4. 新しいターミナル ウィンドウで`root`としてログインし、パスワードを変更します。 + 1. TiDB ノードのデプロイメント ディレクトリの下の`scripts`ディレクトリを入力します。 + 2. Switch to the `root` account of the operating system. + 3. ディレクトリ内の`run_tidb.sh`スクリプトをフォアグラウンドで実行します。 + 4. 新しいターミナル ウィンドウで`root`としてログインし、パスワードを変更します。 ```bash mysql -h 127.0.0.1 -P 4000 -u root ``` -4. `run_tidb.sh`スクリプトの実行を停止し、手順 1 で TiDB 構成ファイルに追加された内容を削除し、tidb-server が自動的に起動するのを待ちます。 +4. `run_tidb.sh`スクリプトの実行を停止し、手順 1 で TiDB 構成ファイルに追加された内容を削除し、tidb-server が自動的に起動するのを待ちます。 ## `FLUSH PRIVILEGES` {#flush-privileges} diff --git a/user-defined-variables.md b/user-defined-variables.md index 4321b44e6df2a..500cd7c149398 100644 --- a/user-defined-variables.md +++ b/user-defined-variables.md @@ -51,11 +51,13 @@ SET @c = b'1000001' + b'1000001'; SELECT @a1, @a2, @a3 ``` - +------+------+------+ - | @a1 | @a2 | @a3 | - +------+------+------+ - | 1 | 2 | 4 | - +------+------+------+ +``` ++------+------+------+ +| @a1 | @a2 | @a3 | ++------+------+------+ +| 1 | 2 | 4 | ++------+------+------+ +``` `SELECT`ステートメントで値を割り当てることもできます。 @@ -63,11 +65,13 @@ SELECT @a1, @a2, @a3 SELECT @a1, @a2, @a3, @a4 := @a1+@a2+@a3; ``` - +------+------+------+--------------------+ - | @a1 | @a2 | @a3 | @a4 := @a1+@a2+@a3 | - +------+------+------+--------------------+ - | 1 | 2 | 4 | 7 | - +------+------+------+--------------------+ +``` ++------+------+------+--------------------+ +| @a1 | @a2 | @a3 | @a4 := @a1+@a2+@a3 | ++------+------+------+--------------------+ +| 1 | 2 | 4 | 7 | ++------+------+------+--------------------+ +``` 変数`@a4`が変更される前、または接続が閉じられる前は、その値は常に`7`です。 @@ -83,11 +87,13 @@ SET @v3 = CAST(b'1000001' AS UNSIGNED); SELECT @v1, @v2, @v3; ``` - +------+------+------+ - | @v1 | @v2 | @v3 | - +------+------+------+ - | A | 65 | 65 | - +------+------+------+ +``` ++------+------+------+ +| @v1 | @v2 | @v3 | ++------+------+------+ +| A | 65 | 65 | ++------+------+------+ +``` 初期化されていないユーザー定義変数を参照すると、その値は NULL で、型は文字列になります。 @@ -95,11 +101,13 @@ SELECT @v1, @v2, @v3; SELECT @not_exist; ``` - +------------+ - | @not_exist | - +------------+ - | NULL | - +------------+ +``` ++------------+ +| @not_exist | ++------------+ +| NULL | ++------------+ +``` ユーザー定義変数の読み取りには`SELECT`文を使用するほか、 `PREPARE`文もよく使用されます。例えば、次のようになります。 @@ -111,11 +119,13 @@ SET @b = 8; EXECUTE stmt USING @a, @b; ``` - +------------+ - | hypotenuse | - +------------+ - | 10 | - +------------+ +``` ++------------+ +| hypotenuse | ++------------+ +| 10 | ++------------+ +``` ユーザー定義変数の内容は、SQL文では識別子として認識されません。例: @@ -123,22 +133,26 @@ EXECUTE stmt USING @a, @b; SELECT * from t; ``` - +---+ - | a | - +---+ - | 1 | - +---+ +``` ++---+ +| a | ++---+ +| 1 | ++---+ +``` ```sql SET @col = "`a`"; SELECT @col FROM t; ``` - +------+ - | @col | - +------+ - | `a` | - +------+ +``` ++------+ +| @col | ++------+ +| `a` | ++------+ +``` ## MySQLとの互換性 {#mysql-compatibility} diff --git a/views.md b/views.md index eaed91678c092..85d5836332ced 100644 --- a/views.md +++ b/views.md @@ -7,8 +7,8 @@ summary: TiDB でビューを使用する方法を学習します。 TiDBはビューをサポートしています。ビューは仮想テーブルとして機能し、そのスキーマはビューを作成する`SELECT`ステートメントによって定義されます。ビューを使用すると、次のような利点があります。 -- 安全なフィールドとデータのみをユーザーに公開し、基になるテーブルに保存されている機密フィールドとデータのセキュリティを確保します。 -- 頻繁に表示される複雑なクエリをビューとして定義し、複雑なクエリをより簡単に、より便利にします。 +- 安全なフィールドとデータのみをユーザーに公開し、基になるテーブルに保存されている機密フィールドとデータのセキュリティを確保します。 +- 頻繁に表示される複雑なクエリをビューとして定義し、複雑なクエリをより簡単に、より便利にします。 ## クエリビュー {#query-views} @@ -66,81 +66,83 @@ curl http://127.0.0.1:10080/schema/test/v `http://{TiDBIP}:10080/schema/{db}/{view}`アクセスすると、ビューのすべてのメタデータを取得できます。 - { - "id": 122, - "name": { - "O": "v", - "L": "v" - }, - "charset": "utf8", - "collate": "utf8_general_ci", - "cols": [ - { - "id": 1, - "name": { - "O": "a", - "L": "a" - }, - "offset": 0, - "origin_default": null, - "default": null, - "default_bit": null, - "default_is_expr": false, - "generated_expr_string": "", - "generated_stored": false, - "dependences": null, - "type": { - "Tp": 0, - "Flag": 0, - "Flen": 0, - "Decimal": 0, - "Charset": "", - "Collate": "", - "Elems": null - }, - "state": 5, - "comment": "", - "hidden": false, - "version": 0 - } - ], - "index_info": null, - "fk_info": null, - "state": 5, - "pk_is_handle": false, - "is_common_handle": false, - "comment": "", - "auto_inc_id": 0, - "auto_id_cache": 0, - "auto_rand_id": 0, - "max_col_id": 1, - "max_idx_id": 0, - "update_timestamp": 416801600091455490, - "ShardRowIDBits": 0, - "max_shard_row_id_bits": 0, - "auto_random_bits": 0, - "pre_split_regions": 0, - "partition": null, - "compression": "", - "view": { - "view_algorithm": 0, - "view_definer": { - "Username": "root", - "Hostname": "127.0.0.1", - "CurrentUser": false, - "AuthUsername": "root", - "AuthHostname": "%" - }, - "view_security": 0, - "view_select": "SELECT `s`.`a` FROM `test`.`t` LEFT JOIN `test`.`s` ON `t`.`a`=`s`.`a`", - "view_checkoption": 1, - "view_cols": null - }, - "sequence": null, - "Lock": null, - "version": 3, - "tiflash_replica": null - } +``` +{ + "id": 122, + "name": { + "O": "v", + "L": "v" + }, + "charset": "utf8", + "collate": "utf8_general_ci", + "cols": [ + { + "id": 1, + "name": { + "O": "a", + "L": "a" + }, + "offset": 0, + "origin_default": null, + "default": null, + "default_bit": null, + "default_is_expr": false, + "generated_expr_string": "", + "generated_stored": false, + "dependences": null, + "type": { + "Tp": 0, + "Flag": 0, + "Flen": 0, + "Decimal": 0, + "Charset": "", + "Collate": "", + "Elems": null + }, + "state": 5, + "comment": "", + "hidden": false, + "version": 0 + } + ], + "index_info": null, + "fk_info": null, + "state": 5, + "pk_is_handle": false, + "is_common_handle": false, + "comment": "", + "auto_inc_id": 0, + "auto_id_cache": 0, + "auto_rand_id": 0, + "max_col_id": 1, + "max_idx_id": 0, + "update_timestamp": 416801600091455490, + "ShardRowIDBits": 0, + "max_shard_row_id_bits": 0, + "auto_random_bits": 0, + "pre_split_regions": 0, + "partition": null, + "compression": "", + "view": { + "view_algorithm": 0, + "view_definer": { + "Username": "root", + "Hostname": "127.0.0.1", + "CurrentUser": false, + "AuthUsername": "root", + "AuthHostname": "%" + }, + "view_security": 0, + "view_select": "SELECT `s`.`a` FROM `test`.`t` LEFT JOIN `test`.`s` ON `t`.`a`=`s`.`a`", + "view_checkoption": 1, + "view_cols": null + }, + "sequence": null, + "Lock": null, + "version": 3, + "tiflash_replica": null +} +``` ## 例 {#example} @@ -150,62 +152,76 @@ curl http://127.0.0.1:10080/schema/test/v create table t(a int, b int); ``` - Query OK, 0 rows affected (0.01 sec) +``` +Query OK, 0 rows affected (0.01 sec) +``` ```sql insert into t values(1, 1),(2,2),(3,3); ``` - Query OK, 3 rows affected (0.00 sec) - Records: 3 Duplicates: 0 Warnings: 0 +``` +Query OK, 3 rows affected (0.00 sec) +Records: 3 Duplicates: 0 Warnings: 0 +``` ```sql create table s(a int); ``` - Query OK, 0 rows affected (0.01 sec) +``` +Query OK, 0 rows affected (0.01 sec) +``` ```sql insert into s values(2),(3); ``` - Query OK, 2 rows affected (0.01 sec) - Records: 2 Duplicates: 0 Warnings: 0 +``` +Query OK, 2 rows affected (0.01 sec) +Records: 2 Duplicates: 0 Warnings: 0 +``` ```sql create view v as select s.a from t left join s on t.a = s.a; ``` - Query OK, 0 rows affected (0.01 sec) +``` +Query OK, 0 rows affected (0.01 sec) +``` ```sql select * from v; ``` - +------+ - | a | - +------+ - | NULL | - | 2 | - | 3 | - +------+ - 3 rows in set (0.00 sec) +``` ++------+ +| a | ++------+ +| NULL | +| 2 | +| 3 | ++------+ +3 rows in set (0.00 sec) +``` ```sql drop view v; ``` - Query OK, 0 rows affected (0.02 sec) +``` +Query OK, 0 rows affected (0.02 sec) +``` ## 制限事項 {#limitations} 現在、TiDB のビューには次の制限があります。 -- マテリアライズド ビューはまだサポートされていません。 -- TiDB のビューは読み取り専用であり、 `UPDATE` 、 `INSERT` 、 `DELETE` 、 `TRUNCATE`などの書き込み操作はサポートされません。 -- 作成されたビューの場合、サポートされるDDL操作は`DROP [VIEW | TABLE]`です。 +- マテリアライズド ビューはまだサポートされていません。 +- TiDB のビューは読み取り専用であり、 `UPDATE` 、 `INSERT` 、 `DELETE` 、 `TRUNCATE`などの書き込み操作はサポートされません。 +- 作成されたビューの場合、サポートされるDDL操作は`DROP [VIEW | TABLE]`です。 ## 参照 {#see-also} -- [CREATE VIEW](/sql-statements/sql-statement-create-view.md) -- [DROP VIEW](/sql-statements/sql-statement-drop-view.md) +- [CREATE VIEW](/sql-statements/sql-statement-create-view.md) +- [DROP VIEW](/sql-statements/sql-statement-drop-view.md) diff --git a/wrong-index-solution.md b/wrong-index-solution.md index 629a361585899..146f87d507971 100644 --- a/wrong-index-solution.md +++ b/wrong-index-solution.md @@ -9,11 +9,11 @@ summary: 間違ったインデックスの問題を解決する方法を学び オプティマイザーが予期しないインデックスを選択する理由は複数あります。 -- **古い統計**：オプティマイザーはクエリコストを推定するために統計を使用します。統計が古い場合、オプティマイザーは最適ではない選択を行う可能性があります。 -- **統計の不一致**: 統計が最新であっても、データの分布を正確に反映していない可能性があり、コストの見積もりが不正確になる可能性があります。 -- **コスト計算が正しくありません**: クエリ構造やデータ分散が複雑なため、オプティマイザーがインデックスの使用コストを誤って計算する場合があります。 -- **不適切なエンジンの選択**: 場合によっては、オプティマイザーがクエリに最適ではないストレージエンジンを選択することがあります。 -- **関数のプッシュダウンの制限**: 特定の関数または操作がストレージエンジンにプッシュダウンされない可能性があり、クエリのパフォーマンスに影響する可能性があります。 +- **古い統計**：オプティマイザーはクエリコストを推定するために統計を使用します。統計が古い場合、オプティマイザーは最適ではない選択を行う可能性があります。 +- **統計の不一致**: 統計が最新であっても、データの分布を正確に反映していない可能性があり、コストの見積もりが不正確になる可能性があります。 +- **コスト計算が正しくありません**: クエリ構造やデータ分散が複雑なため、オプティマイザーがインデックスの使用コストを誤って計算する場合があります。 +- **不適切なエンジンの選択**: 場合によっては、オプティマイザーがクエリに最適ではないストレージエンジンを選択することがあります。 +- **関数のプッシュダウンの制限**: 特定の関数または操作がストレージエンジンにプッシュダウンされない可能性があり、クエリのパフォーマンスに影響する可能性があります。 ## 統計の健康 {#statistics-health} @@ -61,7 +61,7 @@ summary: 間違ったインデックスの問題を解決する方法を学び ## 参照 {#see-also} -- [統計](/statistics.md) -- [インデックスの選択](/choose-index.md) -- [オプティマイザーヒント](/optimizer-hints.md) -- [SQLプラン管理](/sql-plan-management.md) +- [統計](/statistics.md) +- [インデックスの選択](/choose-index.md) +- [オプティマイザーヒント](/optimizer-hints.md) +- [SQLプラン管理](/sql-plan-management.md)