diff --git a/TOC-tidb-cloud-essential.md b/TOC-tidb-cloud-essential.md index 96f5a155f3c5c..9c33397aab717 100644 --- a/TOC-tidb-cloud-essential.md +++ b/TOC-tidb-cloud-essential.md @@ -144,9 +144,12 @@ - [Amazon S3からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング](/tidb-cloud/troubleshoot-import-access-denied-error.md) - [AWS DMSをTiDB Cloudに接続する](/tidb-cloud/tidb-cloud-connect-aws-dms.md) - ストリームデータ ![PREVIEW](/media/tidb-cloud/blank_transparent_placeholder.png) - - [変更フィードの概要](/tidb-cloud/essential-changefeed-overview.md) + - [変更フィード](/tidb-cloud/essential-changefeed-overview.md) - [MySQLへのシンク](/tidb-cloud/essential-changefeed-sink-to-mysql.md) - [Apache Kafkaへのシンク](/tidb-cloud/essential-changefeed-sink-to-kafka.md) + - [TiDB Cloud Lake へのシンク](/tidb-cloud/data-pipeline-essential-sink-to-lake.md) + - 参照 + - [TiDB Cloud Lake 向け Data Pipeline SQL 互換性](/tidb-cloud/data-pipeline-lake-sql-compatibility.md) - セキュリティ - [セキュリティ概要](/tidb-cloud/security-overview.md) - IDアクセス制御 diff --git a/TOC-tidb-cloud-premium.md b/TOC-tidb-cloud-premium.md index 216e22345d37d..a5058d70d2f86 100644 --- a/TOC-tidb-cloud-premium.md +++ b/TOC-tidb-cloud-premium.md @@ -139,14 +139,21 @@ - [Amazon S3からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング](/tidb-cloud/troubleshoot-import-access-denied-error.md) - [AWS DMSをTiDB Cloudに接続する](/tidb-cloud/tidb-cloud-connect-aws-dms.md) - ストリームデータ - - [変更フィードの概要](/tidb-cloud/changefeed-overview.md) + - [概要](/tidb-cloud/stream-data-overview.md) + - [変更フィード](/tidb-cloud/changefeed-overview.md) + - [Data Pipeline](/tidb-cloud/data-pipeline.md) - [MySQLシンクへ](/tidb-cloud/changefeed-sink-to-mysql.md) - [Kafkaシンクへ](/tidb-cloud/changefeed-sink-to-apache-kafka.md) - [Cloud Storage へ](/tidb-cloud/changefeed-sink-to-cloud-storage.md) + - [TiDB Cloud Lake へ](/tidb-cloud/data-pipeline-sink-to-lake.md) - 参照 - [AWSでセルフホスト型のKafkaプライベートリンクサービスをセットアップする](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md) - [Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md) - [AWS PrivateLink 経由で Amazon MSK Provisioned クラスターをセットアップする](/tidb-cloud/setup-aws-msk-provisioned-private-link-service.md) + - [TiDB Cloud Data Pipeline 用の外部 stage を設定する (AWS)](/tidb-cloud/data-pipeline-configure-external-stage-aws.md) + - [TiDB Cloud Data Pipeline 用の外部 stage を設定する (Alibaba Cloud)](/tidb-cloud/data-pipeline-configure-external-stage-alibaba-cloud.md) + - [TiDB Cloud Lake 向け Data Pipeline SQL 互換性](/tidb-cloud/data-pipeline-lake-sql-compatibility.md) + - [Data Pipeline FAQ](/tidb-cloud/data-pipeline-lake-faq.md) - セキュリティ - [セキュリティ概要](/tidb-cloud/security-overview.md) - IDアクセス制御 @@ -503,3 +510,12 @@ - よくある質問 - [TiDB Cloudよくある質問](/tidb-cloud/tidb-cloud-faq.md) - [用語集](/tidb-cloud/tidb-cloud-glossary.md) + +## _BUILD_ALLOWLIST + +- 階層型ストレージを使用する + - [階層型ストレージの概要](/tidb-cloud/tiered-storage-overview.md) + - [階層型ストレージの設定と管理](/tidb-cloud/tiered-storage-guide.md) + - [階層型ストレージの可観測性](/tidb-cloud/tiered-storage-observability.md) + - [階層型ストレージの制限事項](/tidb-cloud/tiered-storage-limitations.md) + - [階層型ストレージに関する FAQ](/tidb-cloud/tiered-storage-faq.md) diff --git a/TOC-tidb-cloud-releases.md b/TOC-tidb-cloud-releases.md index b8362d3279dc9..f09b4e8750c4c 100644 --- a/TOC-tidb-cloud-releases.md +++ b/TOC-tidb-cloud-releases.md @@ -21,6 +21,7 @@ ## TiDB X KERNEL リリースノート - [TiDB Cloud Premium 向けカーネルバージョニング](/tidb-cloud/releases/tidb-cloud-kernel-versioning.md) +- [TiDB-X-CLOUD.202603.1 リリースノート](/tidb-cloud/releases/tidb-x-cloud.202603.1.md) - [TiDB-X-CLOUD.202510.1 リリースノート](/tidb-cloud/releases/tidb-x-cloud.202510.1.md) ## メンテナンス通知 diff --git a/TOC-tidb-cloud.md b/TOC-tidb-cloud.md index a76677cd23959..7fe3edd22e375 100644 --- a/TOC-tidb-cloud.md +++ b/TOC-tidb-cloud.md @@ -191,17 +191,19 @@ - [データアプリ設定ファイル](/tidb-cloud/data-service-app-config-files.md) - [応答とステータスコード](/tidb-cloud/data-service-response-and-status-code.md) - ストリームデータ - - [変更フィードの概要](/tidb-cloud/changefeed-overview.md) + - [変更フィード](/tidb-cloud/changefeed-overview.md) - [MySQLシンクへ](/tidb-cloud/changefeed-sink-to-mysql.md) - [Kafkaシンクへ](/tidb-cloud/changefeed-sink-to-apache-kafka.md) - [Pulsarシンクへ](/tidb-cloud/changefeed-sink-to-apache-pulsar.md) - [TiDB Cloud Sinkへ](/tidb-cloud/changefeed-sink-to-tidb-cloud.md) - [クラウドストレージへ](/tidb-cloud/changefeed-sink-to-cloud-storage.md) + - [TiDB Cloud Lake へ](/tidb-cloud/data-pipeline-dedicated-sink-to-lake.md) - 参照 - [AWSでセルフホスト型のKafkaプライベートリンクサービスをセットアップする](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md) - [Azureでセルフホスト型Kafkaプライベートリンクサービスをセットアップする](/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md) - [Google Cloud でセルフホスト型の Kafka プライベートサービスコネクトを設定する](/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md) - [Changefeeds用のプライベートエンドポイントを設定する](/tidb-cloud/set-up-sink-private-endpoint.md) + - [TiDB Cloud Lake 向け Data Pipeline SQL 互換性](/tidb-cloud/data-pipeline-lake-sql-compatibility.md) - セキュリティ - [セキュリティ概要](/tidb-cloud/security-overview.md) - IDアクセス制御 diff --git a/TOC.md b/TOC.md index cd14c41ed1627..b29e1b0e9ce91 100644 --- a/TOC.md +++ b/TOC.md @@ -816,7 +816,7 @@ - [日付と時刻の種類](/data-type-date-and-time.md) - [文字列型](/data-type-string.md) - [JSONタイプ](/data-type-json.md) - - [ベクトルタイプ](/ai/reference/vector-search-data-types.md) + - [ベクトル型](https://docs.pingcap.com/ai/vector-search-data-types/) - 関数と演算子 - [概要](/functions-and-operators/functions-and-operators-overview.md) - [式評価における型変換](/functions-and-operators/type-conversion-in-expression-evaluation.md) @@ -830,7 +830,7 @@ - [暗号化および圧縮機能](/functions-and-operators/encryption-and-compression-functions.md) - [ロック機能](/functions-and-operators/locking-functions.md) - [情報関数](/functions-and-operators/information-functions.md) - - [ベクトル関数と演算子](/ai/reference/vector-search-functions-and-operators.md) + - [ベクトル関数と演算子](https://docs.pingcap.com/ai/vector-search-functions-and-operators/) - JSON関数 - [概要](/functions-and-operators/json-functions.md) - [JSONを作成する関数](/functions-and-operators/json-functions/json-functions-create.md) @@ -853,7 +853,7 @@ - [OracleとTiDBの関数と構文の比較](/oracle-functions-to-tidb.md) - [クラスター化インデックス](/clustered-indexes.md) - [グローバルインデックス](/global-indexes.md) - - [ベクトルインデックス](/ai/reference/vector-search-index.md) + - [ベクトルインデックス](https://docs.pingcap.com/ai/vector-search-index/) - [制約](/constraints.md) - [生成列](/generated-columns.md) - [SQLモード](/sql-mode.md) diff --git a/ai/ti/guides/ti-git-workspace-for-agents-example.md b/ai/ti/guides/ti-git-workspace-for-agents-example.md index 3375f12c1b414..67d739e8f8dd4 100644 --- a/ai/ti/guides/ti-git-workspace-for-agents-example.md +++ b/ai/ti/guides/ti-git-workspace-for-agents-example.md @@ -1,11 +1,11 @@ --- title: TiDB Cloud Filesystem 上でエージェント向けの Git ワークスペースを準備する -summary: 大規模な Git ワークスペースをすばやく利用可能にし、クリーンオブジェクトをバックグラウンドで hydrate して、完全なダウンロードが終わる前にエージェントが作業を開始できるようにします。 +summary: 大規模な Git リポジトリのダウンロードが完了する前にエージェントタスクを開始し、マシンを削除する前に作業を保持する方法を学びます。 --- # TiDB Cloud Filesystem 上でエージェント向けの Git ワークスペースを準備する -このワークフローでは、エージェントタスクの開始におけるクリティカルパスから、大規模リポジトリのクローンを取り除きます。完全なダウンロードが完了する前に、一時的なエージェントが大規模リポジトリを調査または変更する必要がある場合に使用します。 +大規模なリポジトリのダウンロードが完了する前にエージェントタスクを開始します。一時的なマシン上のエージェントがすぐにファイルを調査または編集する必要がある場合は、バックグラウンド hydration を有効にした blobless Git ワークスペースを使用します。 > **Note:** > @@ -13,7 +13,9 @@ summary: 大規模な Git ワークスペースをすばやく利用可能にし ## 仕組み {#how-it-works} -`ti fs-git clone-git-workspace --blobless --hydrate background` は、置き換え可能なエージェントランタイム間で共有できる Git ワークスペースを登録し、すべてのクリーン ブロブのダウンロードが完了する前にそのファイルツリーを公開します。このコマンドはすぐに戻るため、`ti` がバックグラウンドでクリーンツリーとローカル Git オブジェクトデータベースを hydrate している間に、エージェントはパスを調査して作業を開始できます。通常の clone とは異なり、初期オブジェクト転送はワークフロー全体をブロックしません。ネイティブの blobless partial clone のみを使う場合と異なり、バックグラウンド hydration により、エージェントのクリティカルパス上で繰り返し発生するオンデマンドフェッチを減らせます。hydration の完了前に到着した読み取りは、正確性を保つために引き続き Git の lazy fetch にフォールバックします。編集、commit、fetch、push は通常どおり Git が担当します。 +`ti fs-git clone-git-workspace --blobless --hydrate background` は Git ワークスペースを登録し、すべてのクリーンブロブのダウンロードが完了する前にそのファイルツリーを公開します。`ti` が残りのクリーンなファイル内容をダウンロードしてローカル Git オブジェクトデータベースにデータを格納している間に、エージェントは作業を開始できます。hydration と呼ばれるこのバックグラウンドプロセスにより、繰り返し発生するオンデマンドフェッチが減ります。hydration が完了する前の読み取りでは、不足しているデータを取得するために Git の lazy fetch が使用されます。 + +置き換え後のエージェントランタイムは、登録済みのワークスペースにアクセスできます。元のマシンを破棄する前に、以下のクリーンアップガイダンスで説明されているように、ローカル Git 履歴を保持してください。ファイルの編集には通常のツールを使用し、commit、fetch、push には Git コマンドを使用します。 ## 前提条件 {#prerequisites} @@ -71,7 +73,7 @@ ti fs-git add-git-worktree \ git -C /path/to/workspace/tidb-agent-task status ``` -worktree を削除する前に、必要な変更を commit または push してください。 +worktree を削除する前に、必要な変更を commit してください。マシンを破棄する前に、push またはローカル Git メタデータの検証済みバックアップを使用して、[Git 履歴を保持して検証](/tidb-cloud-filesystem/manage-git-workspaces.md#preserve-work-before-leaving-a-machine)してください。 ## クリーンアップ {#cleanup} @@ -88,7 +90,7 @@ ti fs unmount-file-system --mount-path /path/to/workspace - リポジトリ認証情報は `ti` ではなく Git によって管理されます。 - `coding-agent` マウントプロファイルは、パフォーマンスのために Git メタデータ、依存関係ディレクトリ、キャッシュ、ビルド出力、およびその他の生成ファイルをローカルマシン上に保持します。 -- `coding-agent` プロファイルによってローカルに保持されるファイルは、一時的なマシンとともに消えます。必要な Git の変更は commit または push し、再構築できないその他のローカルファイルを保持するには、明示的な `--path` 値を指定して [`pack-file-system`](/ai/ti/reference/ti-fs-pack-file-system.md) を使用してください。 +- `coding-agent` プロファイルによってローカルに保持されるファイルは、一時的なマシンとともに消えます。ローカル commit だけでは、マシン間で Git 履歴は保持されません。必要な commit は push して検証し、再構築できないその他のローカルファイルを保持するには、明示的な `--path` 値を指定して [`pack-file-system`](/ai/ti/reference/ti-fs-pack-file-system.md) を使用してください。 ## 次のステップ {#what-s-next} diff --git a/ai/ti/reference/ti-fs-copy-file.md b/ai/ti/reference/ti-fs-copy-file.md index 0a43f1eba2a44..9f51cc8df46ef 100644 --- a/ai/ti/reference/ti-fs-copy-file.md +++ b/ai/ti/reference/ti-fs-copy-file.md @@ -50,13 +50,13 @@ ti fs copy-file ## オプション {#options} -- `--append`: ローカルファイルの内容を TiDB Cloud ファイルシステム内のファイルに追記します。 -- `--create-parents`: TiDB Cloud ファイルシステムからコピーする際に、不足しているローカルの親ディレクトリを作成します。 +- `--append`: ローカルファイルの内容をファイルシステム内のファイルに追記します。 +- `--create-parents`: ファイルシステムからコピーする際に、不足しているローカルの親ディレクトリを作成します。 - `--description `: `--to-remote` 操作のファイル説明です。 - `--dry-run`: 変更を適用せずにリクエストを検証します。 - `--file-system-id `: ファイルシステムを選択します。`TI_FS_FILE_SYSTEM_ID` を設定することもできます。 - `--from-local `: ローカルのソースパスです。 -- `--from-remote `: TiDB Cloud ファイルシステム内のソースパスです。 +- `--from-remote `: ファイルシステム内のソースパスです。 - `--from-stdin`: 標準入力から読み取り、`--to-remote` に書き込みます。 - `--fs-token `: ファイルシステムトークンを設定します。省略した場合、コマンドは `TI_FS_TOKEN` 環境変数を使用します。どちらも指定されていない場合、選択したファイルシステム用にローカルに保存されているトークンを使用します。 - `--help`: ヘルプ情報を表示します。 @@ -66,7 +66,7 @@ ti fs copy-file - `--resume`: 実行中のコピー操作を再開します。 - `--tag `: `--to-remote` 操作用に `key=value` 形式のタグを作成します。複数回指定できます。 - `--to-local `: ローカルの宛先パスです。 -- `--to-remote `: TiDB Cloud ファイルシステム内の宛先パスです。 +- `--to-remote `: ファイルシステム内の宛先パスです。 - `--to-stdout`: `--from-remote` を標準出力に書き込みます。 - `--version`: バージョン情報を表示します。 diff --git a/ai/ti/reference/ti-fs-create-hardlink.md b/ai/ti/reference/ti-fs-create-hardlink.md index 836c987d37c12..bddd013e5c104 100644 --- a/ai/ti/reference/ti-fs-create-hardlink.md +++ b/ai/ti/reference/ti-fs-create-hardlink.md @@ -26,8 +26,8 @@ ti fs create-hardlink ## オプション {#options} -- `--link-path `: TiDB Cloud ファイルシステム内で作成するハードリンクのファイルパスです。\[required] -- `--source-path `: TiDB Cloud ファイルシステム内の既存のファイルパスです。\[required] +- `--link-path `: ファイルシステム内で作成するハードリンクのファイルパスです。\[required] +- `--source-path `: ファイルシステム内の既存のファイルパスです。\[required] - `--dry-run`: 変更を適用せずにリクエストを検証します。 - `--file-system-id `: ファイルシステムを選択します。`TI_FS_FILE_SYSTEM_ID` を設定することもできます。 - `--fs-token `: ファイルシステムトークンを設定します。省略した場合、このコマンドは `TI_FS_TOKEN` 環境変数を使用します。どちらも指定されていない場合、このコマンドは選択したファイルシステム用にローカルに保存されているトークンを使用します。 diff --git a/ai/ti/reference/ti-fs-create-layer.md b/ai/ti/reference/ti-fs-create-layer.md index 596a2756e88b3..0db5de92d86ee 100644 --- a/ai/ti/reference/ti-fs-create-layer.md +++ b/ai/ti/reference/ti-fs-create-layer.md @@ -30,7 +30,7 @@ ti fs create-layer ## オプション {#options} -- `--base-root-path `: TiDB Cloud ファイルシステム内のベースルートパスです。\[required] +- `--base-root-path `: ファイルシステム内のベースルートパスです。\[required] - `--actor-id `: レイヤーの所有者を識別するアクター ID です（例: エージェント名）。 - `--dry-run`: 変更を適用せずにリクエストを検証します。 - `--durability-mode `: レイヤーの耐久性モードを設定します。明示的にサポートされている値は `restore-safe` のみで、これを指定するとリモートレイヤー内の変更が保持され、ローカル環境の終了後もレイヤーを復元できます。省略した場合、サービスは `restore-safe` を使用します。 diff --git a/ai/ti/reference/ti-fs-delete-file-system-token.md b/ai/ti/reference/ti-fs-delete-file-system-token.md index 4317a0977b4ee..a44891bf6fbd9 100644 --- a/ai/ti/reference/ti-fs-delete-file-system-token.md +++ b/ai/ti/reference/ti-fs-delete-file-system-token.md @@ -27,7 +27,7 @@ ti fs delete-file-system-token - `--file-system-id `: トークンを所有するファイルシステムを指定します。TiDB Cloud API 認証情報を使用する場合は必須です。オーナートークンが ID を提供する場合は省略可能です。 - `--token-id `: list コマンドが返す不変のトークン ID を指定します。このオプションは必須です。 -- `--fs-token `: ファイルシステムのオーナートークンを使用してリクエストを認可します。省略した場合、コマンドは `TI_FS_TOKEN` 環境変数を使用します。どちらも指定されていない場合、コマンドは選択したファイルシステム用にローカルに保存されたトークンを使用します。利用可能なファイルシステムトークンがない場合、コマンドは設定済みの TiDB Cloud API キーを使用します。 +- `--fs-token `: ファイルシステムのオーナートークンを使用してリクエストを認可します。省略した場合、コマンドは `TI_FS_TOKEN` 環境変数を使用します。どちらも指定されていない場合、コマンドは TiDB Cloud API 認証情報と `--file-system-id` を必要とします。ローカルに保存されたオーナートークンは自動的には使用されません。 - `--dry-run`: トークンを取り消さずに、認証情報、識別子、および既知のローカルマウント競合を検証します。 - `--help`: ヘルプ情報を表示します。 - `--version`: バージョン情報を表示します。 diff --git a/ai/ti/reference/ti-fs-delete-file.md b/ai/ti/reference/ti-fs-delete-file.md index ba820584eb2aa..84107d0ee02da 100644 --- a/ai/ti/reference/ti-fs-delete-file.md +++ b/ai/ti/reference/ti-fs-delete-file.md @@ -26,7 +26,7 @@ ti fs delete-file ## オプション {#options} -- `--path `: TiDB Cloud ファイルシステム内のファイルまたはディレクトリのパス。\[required] +- `--path `: ファイルシステム内のファイルまたはディレクトリのパス。\[required] - `--dry-run`: 変更を適用せずにリクエストを検証します。 - `--file-system-id `: ファイルシステムを選択します。`TI_FS_FILE_SYSTEM_ID` を設定することもできます。 - `--fs-token `: ファイルシステムトークンを設定します。省略した場合、このコマンドは `TI_FS_TOKEN` 環境変数を使用します。どちらも指定されていない場合、このコマンドは選択したファイルシステム用にローカルに保存されたトークンを使用します。 diff --git a/ai/ti/reference/ti-fs-describe-file.md b/ai/ti/reference/ti-fs-describe-file.md index f06d6be70f584..c0b30ed4728ce 100644 --- a/ai/ti/reference/ti-fs-describe-file.md +++ b/ai/ti/reference/ti-fs-describe-file.md @@ -24,7 +24,7 @@ ti fs describe-file ## オプション {#options} -- `--path `: TiDB Cloud ファイルシステム内のファイルまたはディレクトリのパス。\[required] +- `--path `: ファイルシステム内のファイルまたはディレクトリのパス。\[required] - `--file-system-id `: ファイルシステムを選択します。`TI_FS_FILE_SYSTEM_ID` を設定することもできます。 - `--fs-token `: ファイルシステムトークンを設定します。省略した場合、このコマンドは `TI_FS_TOKEN` 環境変数を使用します。どちらも指定されていない場合、このコマンドは選択したファイルシステム用にローカルに保存されているトークンを使用します。 - `--help`: ヘルプ情報を表示します。 diff --git a/ai/ti/reference/ti-fs-disable-file-system-token.md b/ai/ti/reference/ti-fs-disable-file-system-token.md index 23183112cf122..c2868d3af1c28 100644 --- a/ai/ti/reference/ti-fs-disable-file-system-token.md +++ b/ai/ti/reference/ti-fs-disable-file-system-token.md @@ -27,7 +27,7 @@ ti fs disable-file-system-token - `--file-system-id `: トークンを所有するファイルシステムを指定します。TiDB Cloud API 認証情報を使用する場合は必須です。オーナートークンが ID を提供する場合は省略できます。 - `--token-id `: list コマンドが返す変更不可のトークン ID を指定します。このオプションは必須です。 -- `--fs-token `: ファイルシステムのオーナートークンを使用してリクエストを認証します。省略した場合、コマンドは `TI_FS_TOKEN` 環境変数を使用します。どちらも指定されていない場合、コマンドは選択したファイルシステム用にローカルに保存されているトークンを使用します。利用可能なファイルシステムトークンがない場合、コマンドは設定済みの TiDB Cloud API キーを使用します。 +- `--fs-token `: ファイルシステムのオーナートークンを使用してリクエストを認証します。省略した場合、コマンドは `TI_FS_TOKEN` 環境変数を使用します。どちらも指定されていない場合、コマンドは TiDB Cloud API 認証情報と `--file-system-id` を必要とします。ローカルに保存されているオーナートークンは自動的には使用されません。 - `--dry-run`: トークンを無効化せずに、認証情報、識別子、および既知のローカルマウント競合を検証します。 - `--help`: ヘルプ情報を表示します。 - `--version`: バージョン情報を表示します。 diff --git a/ai/ti/reference/ti-fs-enable-file-system-token.md b/ai/ti/reference/ti-fs-enable-file-system-token.md index aadd2ff32a74b..43e6dc14d8d36 100644 --- a/ai/ti/reference/ti-fs-enable-file-system-token.md +++ b/ai/ti/reference/ti-fs-enable-file-system-token.md @@ -27,7 +27,7 @@ ti fs enable-file-system-token - `--file-system-id `: トークンを所有するファイルシステムを指定します。TiDB Cloud API 認証情報を使用する場合は必須です。オーナートークンが ID を提供する場合は省略可能です。 - `--token-id `: list コマンドで返される変更不可のトークン ID を指定します。このオプションは必須です。 -- `--fs-token `: ファイルシステムオーナートークンを使用してリクエストを認可します。省略した場合、コマンドは `TI_FS_TOKEN` 環境変数を使用します。どちらも指定されていない場合、コマンドは選択したファイルシステム用にローカルに保存されたトークンを使用します。利用可能なファイルシステムトークンがない場合、コマンドは設定済みの TiDB Cloud API キーを使用します。 +- `--fs-token `: ファイルシステムオーナートークンを使用してリクエストを認可します。省略した場合、コマンドは `TI_FS_TOKEN` 環境変数を使用します。どちらも指定されていない場合、コマンドには TiDB Cloud API 認証情報と `--file-system-id` が必要です。ローカルに保存されたオーナートークンは自動的には使用されません。 - `--dry-run`: リモートのトークン状態を変更せずにリクエストを検証します。 - `--help`: ヘルプ情報を表示します。 - `--version`: バージョン情報を表示します。 diff --git a/ai/ti/reference/ti-fs-list-file-system-tokens.md b/ai/ti/reference/ti-fs-list-file-system-tokens.md index c90a6f861c3b7..7dc83b0e50b17 100644 --- a/ai/ti/reference/ti-fs-list-file-system-tokens.md +++ b/ai/ti/reference/ti-fs-list-file-system-tokens.md @@ -27,7 +27,7 @@ ti fs list-file-system-tokens ## オプション {#options} - `--file-system-id `: トークンを一覧表示するファイルシステムを指定します。TiDB Cloud API 認証情報を使用する場合は必須です。`--fs-token` または `TI_FS_TOKEN` で所有者トークンが指定されている場合は、`ti` がそのトークンから ID を導出するため、省略可能です。 -- `--fs-token `: ファイルシステム所有者トークンを使用してリクエストを認可します。省略した場合、このコマンドは `TI_FS_TOKEN` 環境変数を使用します。どちらも指定されていない場合、このコマンドは選択したファイルシステム用にローカルに保存されているトークンを使用します。利用可能なファイルシステムトークンがない場合、このコマンドは設定済みの TiDB Cloud API キーを使用します。スコープ付きトークンではトークンメタデータを一覧表示できません。 +- `--fs-token `: ファイルシステム所有者トークンを使用してリクエストを認可します。省略した場合、このコマンドは `TI_FS_TOKEN` 環境変数を使用します。どちらも指定されていない場合、このコマンドでは TiDB Cloud API 認証情報と `--file-system-id` が必要です。ローカルに保存されている所有者トークンは自動的には使用されません。スコープ付きトークンではトークンメタデータを一覧表示できません。 - `--include-expired`: 期限切れのトークンメタデータを含めます。失効済みトークンはサービスから返されません。 - `--help`: ヘルプ情報を表示します。 - `--offset `: 0 ベースのトークンオフセットを設定します [default: 0]。 diff --git a/ai/ti/reference/ti-fs-mount-file-system.md b/ai/ti/reference/ti-fs-mount-file-system.md index 2eb851cb2bbd0..a387f65316dbc 100644 --- a/ai/ti/reference/ti-fs-mount-file-system.md +++ b/ai/ti/reference/ti-fs-mount-file-system.md @@ -1,17 +1,17 @@ --- title: ti fs mount-file-system -summary: ファイルシステムをマウントします。 +summary: FUSE、WebDAV、読み取り専用アクセス、レイヤー、チェックポイントなど、TiDB Cloud ファイルシステムのローカルマウントを設定する方法を学びます。 --- # ti fs mount-file-system -自動、FUSE、または WebDAV モードでファイルシステムをマウントします。このコマンドのエイリアスは `ti fs mount` です。 +FUSE または WebDAV を使用してファイルシステムをマウントします。デフォルトでは、CLI がドライバーを自動的に選択します。このコマンドのエイリアスは `ti fs mount` です。 このコマンドはバックグラウンドでマウント処理を開始し、マウントの準備が完了するまで待機してから、結果を出力します。起動に失敗した場合、エラーには診断用のログパスが含まれます。マウントを終了するには `ti fs unmount-file-system` を使用します。 > **Important:** > -> レイヤーおよびチェックポイントのマウントには FUSE が必要です。通常自動選択で WebDAV が使用される macOS では、macFUSE をインストールし、`--driver fuse` を指定してください。チェックポイントのマウントは常に読み取り専用です。 +> レイヤーおよびチェックポイントのマウントには FUSE が必要です。macOS では、これらの機能を使用するために macFUSE をインストールし、`--driver fuse` を指定してください。チェックポイントのマウントは常に読み取り専用です。 > **Note:** > @@ -63,9 +63,9 @@ ti fs mount-file-system - `--read-cache-max-file-mb `: FUSE 読み取りキャッシュに格納できる最大ファイルサイズ（MiB）。0 を指定するとデフォルト値を使用します。\[default: 4] - `--read-cache-size-mb `: FUSE 読み取りキャッシュサイズ（MiB）。0 を指定するとデフォルト値を使用します。\[default: 128] - `--read-cache-ttl `: FUSE 読み取りキャッシュの有効期間。\[default: `30s`] -- `--read-only`: 読み取り専用マウントモード。 -- `--ready-timeout `: バックグラウンドマウントの準備完了を待機する時間。\[default: `30s`] -- `--remote-path `: マウントする TiDB Cloud ファイルシステムのルートパス。\[default: /] +- `--read-only`: 読み取り専用マウントモード。FUSE が必要です。WebDAV ではこのオプションは拒否されます。`--driver fuse` を明示的に使用するか、スコープ付きトークンを使用してサービスレベルで読み取り専用アクセスを強制してください。 +- `--ready-timeout `: バックグラウンドマウントの準備完了を待機する時間。これは起動時のタイムアウトであり、その後のファイルの読み取りや書き込みのタイムアウトではありません。[マウント後にファイル I/O を確認する](/tidb-cloud-filesystem/filesystem-mount.md#verify-a-mount-before-using-it)。\[default: `30s`] +- `--remote-path `: マウントするファイルシステムのルートパス。\[default: /] - `--unpack-archive-path `: マウント前にパックされたアーカイブを復元します。 - `--version`: バージョン情報を表示します。 - `--write-back-cache`: フラッシュ時にファイルシステムへ書き込む前に、FUSE の書き込みをローカルに永続化します。この動作はデフォルトで有効です。無効にするには `--write-back-cache=false` を指定します。常に読み取り専用であるチェックポイントマウントでは使用できません。\[default: true] diff --git a/ai/ti/reference/ti-fs-pack-file-system.md b/ai/ti/reference/ti-fs-pack-file-system.md index 2f424a24112bb..57890ce6d876a 100644 --- a/ai/ti/reference/ti-fs-pack-file-system.md +++ b/ai/ti/reference/ti-fs-pack-file-system.md @@ -39,7 +39,7 @@ ti fs pack-file-system - `--mount-path `: ローカルのマウント済みパスです。 - `--mount-profile `: [マウントプロファイル](/ai/ti/reference/ti-filesystem.md#mount-profiles-and-local-overlays) を選択します: `coding-agent`、`portable`、または `none`。省略した場合は `none` を使用します。 - `--path `: パック対象のローカルオーバーレイパスです。繰り返し指定できます。 -- `--remote-root `: ローカルオーバーレイで表される TiDB Cloud ファイルシステムのルートです。\[default: /] +- `--remote-root `: ローカルオーバーレイで表されるファイルシステムのルートです。\[default: /] - `--version`: バージョン情報を表示します。 すべてのコマンドで共通のオプションについては、[グローバルオプション](/ai/ti/reference/ti-cli-reference.md#global-options)を参照してください。 diff --git a/ai/ti/ti-quick-start.md b/ai/ti/ti-quick-start.md index 4e4fcd05805f1..89fccd0501e96 100644 --- a/ai/ti/ti-quick-start.md +++ b/ai/ti/ti-quick-start.md @@ -130,7 +130,7 @@ TiDB Cloud Filesystem は、ローカルマシン、CI ジョブ、サンドボ 2. ファイルシステムを使用する環境で、前の手順のオーナートークンを `TI_FS_TOKEN` として設定し、次のようにファイルシステムをローカルパスにマウントします。この環境は、ファイルシステムを作成した同じマシン、別のマシン、または AI エージェントのサンドボックスのいずれでもかまいません。 ```bash - export TI_FS_TOKEN="" # Skip this line if you are continuing in the same terminal as step 1, where TI_FS_TOKEN is already set. + # export TI_FS_TOKEN="" # 手順 1 とは別の環境で続行する場合は、ここで手順 1 で取得した TI_FS_TOKEN を渡します。 mkdir ~/mnt-test ti fs mount-file-system --mount-path ~/mnt-test --region aws-us-west-2 echo 'Hello from TiDB Cloud Filesystem' >> ~/mnt-test/hello.txt diff --git a/best-practices/haproxy-best-practices.md b/best-practices/haproxy-best-practices.md index 15eb66b16d698..89041917d1467 100644 --- a/best-practices/haproxy-best-practices.md +++ b/best-practices/haproxy-best-practices.md @@ -35,7 +35,7 @@ HAProxy をデプロイする前に、ハードウェアとソフトウェアの ### ハードウェア要件 {#hardware-requirements} -[HAProxyドキュメント](https://www.haproxy.com/documentation/haproxy-enterprise/getting-started/installation/linux/)によると、HAProxyの最小ハードウェア構成は以下の表の通りです。Sysbench `oltp_read_write`ワークロードでは、この構成での最大QPSは約50Kです。負荷分散環境に応じてサーバー構成を増やすことができます。 +[HAProxyドキュメント](https://www.haproxy.com/documentation/haproxy-enterprise/getting-started/installation/linux/)によると、HAProxyの最小ハードウェア構成は以下の表の通りです。Sysbench `oltp_read_write`ワークロードでは、この構成での最大QPSは約50Kです。負荷分散環境に応じてサーバー構成をアップグレードできます。 | ハードウェアリソース | 最小仕様 | | :---------------- | :------------- | diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index eccb373a3d041..550d5f4a28c64 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -95,7 +95,7 @@ MySQLで培った多くの経験は、TiDBにも応用できます。ただし 前述のとおり、インデックスは重要ですが、インデックスの数は適切であるべきです。アプリケーションの特性に応じて適切なインデックスを作成する必要があります。原則として、パフォーマンスを向上させるためには、クエリに関係する列にインデックスを作成する必要があります。インデックスを作成する必要がある状況は以下のとおりです。 - - 差異の度合いが高い列の場合、インデックスによってフィルタリングされた行数は著しく削減されます。 + - カーディナリティの高いカラムの場合、インデックスによってフィルタリングされる行数は著しく削減されます。 - 複数のクエリ条件がある場合は、複合インデックスを選択できます。複合インデックスの前に、同等の条件を持つ列を配置することに注意してください。 例えば、よく使われるクエリが`select * from t where c1 = 10 and c2 = 100 and c3 > 10`の場合、複合インデックス`Index cidx (c1, c2, c3)`を作成できます。このようにして、クエリ条件を使用してインデックスのプレフィックスを作成し、スキャンを実行できます。 diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md index 8da603b8c61a7..5414a6fd0136c 100644 --- a/br/backup-and-restore-storages.md +++ b/br/backup-and-restore-storages.md @@ -192,7 +192,7 @@ TiKV で GCS WIF または ADC を使用する場合は、 `gcp_v2`外部スト systemctl edit tikv-24000 ``` - 2. TiKV 設定ファイルを編集して、次の3つの環境変数を構成します。 + 2. systemd サービス設定を編集して、次の3つの環境変数を設定します。 ``` [Service] diff --git a/clinic/clinic-user-guide-for-tiup.md b/clinic/clinic-user-guide-for-tiup.md index 84a381d98e26a..389bf87d5876a 100644 --- a/clinic/clinic-user-guide-for-tiup.md +++ b/clinic/clinic-user-guide-for-tiup.md @@ -218,7 +218,7 @@ Diag を使用すると、 TiUPを使用してデプロイされた TiDB クラ - カーネルパラメータのリスト: `sysctl.conf` - カーネルログ: `dmesg.log` - データ収集中のネットワーク接続: `ss.txt` -- 設定データ：各ノードの`config.json`ディレクトリ +- 設定データ：各ノードのディレクトリ配下の`config.json`ファイル - クラスター自体のメタ情報: in `meta.yaml` (このファイルは収集されたデータを保存するディレクトリの最上位にあります) - 監視データ： `/monitor`ファイルディレクトリ内。監視データはデフォルトで圧縮されており、直接表示できません。監視データを含むJSONファイルを直接表示するには、データ収集時に`--compress-metrics=false`パラメータで圧縮を無効にしてください。 diff --git a/dm/dm-best-practices.md b/dm/dm-best-practices.md index 1e960231a16a4..81e8bf201862b 100644 --- a/dm/dm-best-practices.md +++ b/dm/dm-best-practices.md @@ -145,7 +145,7 @@ MySQLシャードの移行とマージを行う際、上流のシャードの種 | シナリオ | DM-masterのデプロイ | DM-workerのデプロイ | | :-------------------------------------------------------------------- | :----------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------- | -|
  • 小さなデータセット（1 TiB 未満）
  • 一度限りのデータ移行
    • | 1つのDM-masterノードをデプロイ | 上流データソースの数に応じて、1～N 台の DM-workerノードをデプロイ。通常は 1台の DM-workerノードを推奨します。 | +|
  • 小さなデータセット（1 TiB 未満）
  • 一度限りのデータ移行
    • | 1つのDM-masterノードをデプロイ | 1台からN台のDM-workerノードをデプロイ。Nは上流データソースの数です。通常は 1台の DM-workerノードを推奨します。 | |
  • 大規模なデータセット（1 TiB 以上）と MySQL シャードの移行およびマージ
  • 一度限りのデータ移行
    • | 長時間のデータ移行中に DM クラスターの可用性を確保するために、3つの DM-masterノードをデプロイすることをお勧めします。 | データソースまたは移行タスクの数に応じて、DM-workerノードをデプロイ。稼働中のDM-workerノードに加えて、アイドル状態のDM-workerノードを1～3台デプロイすることをお勧めします。 | | 長期データ複製 | DM-masterノードは3台必要です。クラウド上にDM-masterノードをデプロイする場合は、異なるアベイラビリティゾーン（AZ）にデプロイするようにしてください。 | データソース数や移行タスク数に応じて、DM-workerノードをデプロイ。実際に必要なDM-workerノード数の1.5～2倍をデプロイする必要があります。 | diff --git a/dm/dm-faq.md b/dm/dm-faq.md index bc7ba5dab8ae2..2337a6b40d6f9 100644 --- a/dm/dm-faq.md +++ b/dm/dm-faq.md @@ -146,7 +146,7 @@ DM v2.0 以降、増分データレプリケーションを続行するために 設定項目`block-allow-list`と`table-route`を確認します。 - `block-allow-list`の下にある上流のデータベースとテーブルの名前を設定する必要があります。`do-tables`の前に"~"を追加すると、正規表現を使用して名前を一致させることができます。 -- `table-route`は、テーブル名の一致に正規表現ではなくワイルドカード文字を使用します。例えば、 `table_parttern_[0-63]`は、 `table_parttern_0`から`table_pattern_6`までの 7つのテーブルのみに一致します。 +- `table-route`は、テーブル名の一致に正規表現ではなくワイルドカード文字を使用します。例えば、 `table_pattern_[0-63]`は、 `table_pattern_0`から`table_pattern_6`までの 7つのテーブルのみに一致します。 ## DM がアップストリームからレプリケートしていないのに、 `replicate lag`モニター メトリックにデータが表示されないのはなぜですか? {#why-does-the-replicate-lag-monitor-metric-show-no-data-when-dm-is-not-replicating-from-upstream} diff --git a/filter-binlog-event.md b/filter-binlog-event.md index fc41031410d27..6d3dde5644573 100644 --- a/filter-binlog-event.md +++ b/filter-binlog-event.md @@ -14,7 +14,7 @@ summary: データを移行するときにbinlogイベントをフィルター ## 設定 {#configuration} -binlogイベントフィルターを使用するには、以下に示すように、DM のタスク設定ファイルに`filter`を追加します。 +binlogイベントフィルターを使用するには、以下に示すように、DM のタスク設定ファイルに`filters`フィールドを追加します。 ```yaml filters: diff --git a/functions-and-operators/tidb-functions.md b/functions-and-operators/tidb-functions.md index f070a38854236..26d2c59503131 100644 --- a/functions-and-operators/tidb-functions.md +++ b/functions-and-operators/tidb-functions.md @@ -17,7 +17,7 @@ summary: TiDB 固有の関数の使用法について学習します。 | [`TIDB_DECODE_BINARY_PLAN()`](#tidb_decode_binary_plan) | バイナリ プランをデコードします。 | | [`TIDB_DECODE_KEY()`](#tidb_decode_key) | TiDBエンコードされたキーエントリを、 `_tidb_rowid`と`table_id`含むJSON構造にデコードします。これらのエンコードされたキーは、一部のシステムテーブルやログ出力で確認できます。 | | [`TIDB_DECODE_PLAN()`](#tidb_decode_plan) | TiDB 実行計画をデコードします。 | -| [`TIDB_DECODE_SQL_DIGESTS()`](#tidb_decode_sql_digests) | クラスター内の一連の SQL ダイジェストに対応する正規化された SQL文 (形式と引数のない形式) を照会します。 | +| [`TIDB_DECODE_SQL_DIGESTS()`](#tidb_decode_sql_digests) | クラスター内の一連の SQL ダイジェストに対応する正規化された SQL文（リテラル値が `?` や `...` などのプレースホルダーに置き換えられたもの）を照会します。 | | [`TIDB_ENCODE_INDEX_KEY()`](#tidb_encode_index_key) | インデックスキーをエンコードします。 | | [`TIDB_ENCODE_RECORD_KEY()`](#tidb_encode_record_key) | レコード キーをエンコードします。 | | [`TIDB_ENCODE_SQL_DIGEST()`](#tidb_encode_sql_digest) | クエリ文字列のダイジェストを取得します。 | @@ -42,7 +42,7 @@ summary: TiDB 固有の関数の使用法について学習します。 | [`TIDB_DECODE_BINARY_PLAN()`](#tidb_decode_binary_plan) | バイナリ プランをデコードします。 | | [`TIDB_DECODE_KEY()`](#tidb_decode_key) | TiDBエンコードされたキーエントリを、 `_tidb_rowid`と`table_id`含むJSON構造にデコードします。これらのエンコードされたキーは、一部のシステムテーブルやログ出力で確認できます。 | | [`TIDB_DECODE_PLAN()`](#tidb_decode_plan) | TiDB 実行計画をデコードします。 | -| [`TIDB_DECODE_SQL_DIGESTS()`](#tidb_decode_sql_digests) | クラスター内の一連の SQL ダイジェストに対応する正規化された SQL文 (形式と引数のない形式) を照会します。 | +| [`TIDB_DECODE_SQL_DIGESTS()`](#tidb_decode_sql_digests) | クラスター内の一連の SQL ダイジェストに対応する正規化された SQL文（リテラル値が `?` や `...` などのプレースホルダーに置き換えられたもの）を照会します。 | | [`TIDB_ENCODE_INDEX_KEY()`](#tidb_encode_index_key) | インデックスキーをエンコードします。 | | [`TIDB_ENCODE_RECORD_KEY()`](#tidb_encode_record_key) | レコード キーをエンコードします。 | | [`TIDB_ENCODE_SQL_DIGEST()`](#tidb_encode_sql_digest) | クエリ文字列のダイジェストを取得します。 | @@ -294,12 +294,12 @@ SELECT tidb_decode_plan('8QIYMAkzMV83CQEH8E85LjA0CWRhdGE6U2VsZWN0aW9uXzYJOTYwCXR ## TIDB_DECODE_SQL_DIGESTS {#tidb_decode_sql_digests} -`TIDB_DECODE_SQL_DIGESTS()`関数は、クラスタ内のSQLダイジェストセットに対応する正規化されたSQL文（フォーマットと引数のない形式）を照会するために使用されます。この関数は1つまたは2つの引数を取ります。 +`TIDB_DECODE_SQL_DIGESTS()`関数は、クラスタ内のSQLダイジェストセットに対応する正規化されたSQL文（リテラル値が `?` や `...` などのプレースホルダーに置き換えられたもの）を照会するために使用されます。この関数は1つまたは2つの引数を取ります。 - `digests` : 文字列。このパラメータはJSON文字列配列の形式であり、配列内の各文字列はSQLダイジェストです。 - `stmtTruncateLength` : 整数（オプション）。返される結果内の各SQL文の長さを制限するために使用されます。SQL文が指定された長さを超えた場合、文は切り捨てられます。`0`は長さが無制限であることを意味します。 -この関数は、JSON文字列配列形式の文字列を返します。配列の*i*番目の項目は、 `digests`パラメータの*i*番目の要素に対応する正規化されたSQL文です。 `digests`パラメータの要素が有効なSQLダイジェストでないか、システムが対応するSQL文を見つけられない場合、返される結果の対応する項目は`null`なります。切り捨て長が指定されている場合（ `stmtTruncateLength > 0` ）、返される結果のこの長さを超える各文については、最初の`stmtTruncateLength`文字が保持され、切り捨てを示すために末尾にサフィックス`"..."`が追加されます。 `digests`パラメータが`NULL`の場合、関数の戻り値は`NULL`なります。 +この関数は、JSON文字列配列形式の文字列を返します。配列の*i*番目の項目は、 `digests`パラメータの*i*番目の要素に対応する正規化されたSQL文です。 `digests`パラメータの要素が有効なSQLダイジェストでないか、システムが対応するSQL文を見つけられない場合、返される結果の対応する項目は`null`になります。切り捨て長が指定されている場合（ `stmtTruncateLength > 0` ）、返される結果のこの長さを超える各文については、最初の`stmtTruncateLength`文字が保持され、切り捨てを示すために末尾にサフィックス`"..."`が追加されます。 `digests`パラメータが`NULL`の場合、関数の戻り値は`NULL`になります。 > **Note:** > diff --git a/latest_translation_commit.json b/latest_translation_commit.json index 3fec2a432f142..dbb83a9272650 100644 --- a/latest_translation_commit.json +++ b/latest_translation_commit.json @@ -1,4 +1,4 @@ { "target": "release-8.5", - "sha": "e9461decf11f08770c5adbf74a5f96047ffa0de6" + "sha": "49ed15df968aedb44b0290df53e124ef740c6a67" } diff --git a/metrics-schema.md b/metrics-schema.md index e1810964443b0..786ee4c621c7e 100644 --- a/metrics-schema.md +++ b/metrics-schema.md @@ -89,7 +89,7 @@ SHOW TABLES; 626 rows in set (0.00 sec) ``` -`METRICS_SCHEMA` 、（ [`metrics_summary`](/information-schema/information-schema-metrics-summary.md) 、 [`metrics_summary_by_label`](/information-schema/information-schema-metrics-summary.md) 、 [`inspection_summary`](/information-schema/information-schema-inspection-summary.md)などの監視関連の要約テーブルのデータソースとして使用されます。 +`METRICS_SCHEMA` は、[`metrics_summary`](/information-schema/information-schema-metrics-summary.md)、[`metrics_summary_by_label`](/information-schema/information-schema-metrics-summary.md) および [`inspection_summary`](/information-schema/information-schema-inspection-summary.md) などの監視関連の要約テーブルのデータソースとして使用されます。 ## 追加の例 {#additional-examples} diff --git a/migrate-with-more-columns-downstream.md b/migrate-with-more-columns-downstream.md index 10bd599b1c088..f1e3e8854e425 100644 --- a/migrate-with-more-columns-downstream.md +++ b/migrate-with-more-columns-downstream.md @@ -77,7 +77,7 @@ DM がダウンストリームテーブルスキーマを使用してアップ | パラメータ | 説明 | | :------------------ | :--------------------------------------------------------------------------------------------------------------- | - | `-master-addr` | dmctl が接続されるクラスター内の任意の DM-masterノードの`${advertise-addr}`を指定します。`${advertise-addr}`は 、DM-masterが外部にアドバタイズするアドレスを示します。 | + | `--master-addr` | dmctl が接続されるクラスター内の任意の DM-masterノードの`${advertise-addr}`を指定します。`${advertise-addr}`は 、DM-masterが外部にアドバタイズするアドレスを示します。 | | `binlog-schema set` | スキーマ情報を手動で設定します。 | | `-s` | ソースを指定します。`${source-id}`は MySQL データのソース ID を示します。 | | `${task-name}` | データ移行タスクの`task.yaml`設定ファイルで定義されている移行タスクの名前を指定します。 | diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index a8ff4e6b62d90..184d611c50ef5 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -418,7 +418,7 @@ QPSは34.9kから40.9kに増加し、`execute`フェーズで最も時間がか これらのシナリオでは、シナリオ 2 はアプリケーションがクエリ インターフェイスを使用する一般的なシナリオであり、シナリオ 5 はアプリケーションがプリペアドステートメント インターフェイスを使用する理想的なシナリオです。 -- シナリオ 5 とシナリオ 2 を比較すると、 Javaアプリケーション開発のベストプラクティスを使用し、クライアント側で Prepared Statement オブジェクトをキャッシュすることで、各 SQL文で実行プランキャッシュをヒットするために必要なコマンドとデータベース操作が 1つだけになり、クエリのレイテンシーが 38% 短縮され、QPS が 28% 増加し、TiDB の平均 CPU 使用率が 936% から 577% に低下していることがわかります。 +- シナリオ 5 とシナリオ 2 を比較すると、 Javaアプリケーション開発のベストプラクティスを使用し、クライアント側で Prepared Statement オブジェクトをキャッシュすることで、各 SQL文で実行プランキャッシュをヒットするために必要なコマンドとデータベース操作が 1つだけになり、クエリのレイテンシーが 38% 短縮され、QPS が 28% 増加し、TiDB の平均 CPU 使用率が 874% から 577% に低下していることがわかります。 - シナリオ 7 とシナリオ 3 を比較すると、シナリオ 5 に RC 読み取りや小さなテーブル キャッシュなどの最新の TiDB 最適化機能を追加すると、レイテンシーが41% 削減され、QPS が 108% 増加し、平均 TiDB CPU 使用率が 936% から 478% に低下することがわかります。 各シナリオのパフォーマンスを比較すると、次のような結論を導き出すことができます。 diff --git a/releases/release-4.0.16.md b/releases/release-4.0.16.md index 4fcbabdae1445..843796828a77a 100644 --- a/releases/release-4.0.16.md +++ b/releases/release-4.0.16.md @@ -109,5 +109,5 @@ TiDBバージョン: 4.0.16 - `force-replicate`が有効になっているときに、有効なインデックスのない一部のパーティションテーブルが無視される可能性がある問題を修正[#2834](https://github.com/pingcap/tiflow/issues/2834) - 新しい変更フィードを作成するときに発生するメモリリークの問題を修正しました [#2389](https://github.com/pingcap/tiflow/issues/2389) - シンクコンポーネントの前進によりデータの不整合が発生する可能性がある問題を修正しました[#3503](https://github.com/pingcap/tiflow/issues/3503) - - 株価データのスキャンに時間がかかりすぎると、TiKV が GC を実行するため株価データのスキャンが失敗する可能性がある問題を修正しました[#2470](https://github.com/pingcap/tiflow/issues/2470) + - changefeed の初期化に時間がかかりすぎて TiKV が GC safepoint を進めた場合に、changefeed が失敗する可能性がある問題を修正しました[#2470](https://github.com/pingcap/tiflow/issues/2470) - changefeed update コマンドがグローバルコマンドラインパラメータを認識しない問題を修正[#2803](https://github.com/pingcap/tiflow/issues/2803) diff --git a/releases/release-5.0.6.md b/releases/release-5.0.6.md index 7a60f4e2c6772..e3cabfddbb01a 100644 --- a/releases/release-5.0.6.md +++ b/releases/release-5.0.6.md @@ -157,7 +157,7 @@ TiDB バージョン: 5.0.6 - `tikv_cdc_min_resolved_ts_no_change_for_1m`チェンジフィードがないときに警告が続く問題を修正[#11017](https://github.com/tikv/tikv/issues/11017) - etcd でタスクステータスを手動でクリーンアップするときに発生する TiCDC panicの問題を修正しました [#2980](https://github.com/pingcap/tiflow/issues/2980) - ErrGCTTLExceeded エラーが発生したときに changefeed が十分に速く失敗しない問題を修正しました[#3111](https://github.com/pingcap/ticdc/issues/3111) - - 株価データのスキャンに時間がかかりすぎると、TiKV が GC を実行するため株価データのスキャンが失敗する可能性がある問題を修正しました[#2470](https://github.com/pingcap/tiflow/issues/2470) + - 初期化に時間がかかりすぎて TiKV が GC safepoint を進めた場合に、changefeed が失敗する可能性がある問題を修正しました[#2470](https://github.com/pingcap/tiflow/issues/2470) - コンテナ環境におけるOOMの修正[#1798](https://github.com/pingcap/ticdc/issues/1798) - Backup & Restore (BR) diff --git a/releases/release-5.1.5.md b/releases/release-5.1.5.md index 4f2ac871ed9f5..f9e907450eac0 100644 --- a/releases/release-5.1.5.md +++ b/releases/release-5.1.5.md @@ -69,7 +69,7 @@ TiDBバージョン：5.1.5 - PD - - PDリーダーの移籍後に削除されたtombstoneストアが再び表示される問題を修正しました[#4941](https://github.com/tikv/pd/issues/4941) + - PDリーダーの移籍後に削除されたtombstoneストアが再び表示される問題を修正しました [#4941](https://github.com/tikv/pd/issues/4941) - PDリーダーの転送後すぐにスケジューリングを開始できない問題を修正します [#4769](https://github.com/tikv/pd/issues/4769) - `not leader` の誤ったステータスコードを修正します。 [#4797](https://github.com/tikv/pd/issues/4797) - PDがダッシュボードプロキシリクエストを正しく処理できない問題を修正 [#5321](https://github.com/tikv/pd/issues/5321) diff --git a/releases/release-5.2.0.md b/releases/release-5.2.0.md index aa4a4258d8099..46f6e14c92e8b 100644 --- a/releases/release-5.2.0.md +++ b/releases/release-5.2.0.md @@ -112,7 +112,7 @@ TiDB バージョン: 5.2.0 バージョン5.2では、ロックビューに以下の機能強化が加えられました。 - ロックビュー関連テーブルのSQLダイジェスト列に加えて、対応する正規化されたSQLテキストを表示する列をこれらのテーブルに追加してください。SQLダイジェストに対応するステートメントを手動でクエリする必要はありません。 - - `TIDB_DECODE_SQL_DIGESTS`関数を追加して、クラスタ内の一連の SQL ダイジェストに対応する正規化された SQL文 (フォーマットや引数のない形式) を照会します。これにより、トランザクションによって過去に実行された文の照会操作が簡素化されます。 + - `TIDB_DECODE_SQL_DIGESTS`関数を追加して、クラスタ内の一連の SQL ダイジェストに対応する正規化された SQL文（リテラル値が `?` や `...` などのプレースホルダーに置き換えられたもの）を照会します。これにより、トランザクションによって過去に実行された文の照会操作が簡素化されます。 - `DATA_LOCK_WAITS`および`DEADLOCKS`システムテーブルに、テーブル名、行 ID、インデックス値、およびキーから解釈されるその他のキー情報を表示する列を追加します。これにより、キーが属するテーブルの検索やキー情報の解釈などの操作が簡素化されます。 - `DEADLOCKS`テーブルで再試行可能なデッドロックエラーの情報を収集する機能をサポートします。これにより、そのようなエラーによって発生する問題のトラブルシューティングが容易になります。エラー収集はデフォルトでは無効になっており、 `pessimistic-txn.deadlock-history-collect-retryable`設定を使用して有効にできます。 - `TIDB_TRX`システムテーブルで、クエリ実行中のトランザクションとアイドル状態のトランザクションを区別できるようにしました。 `Normal`状態は`Running`と`Idle`の状態に分割されました。 diff --git a/releases/release-5.2.2.md b/releases/release-5.2.2.md index 3bbccf748f22e..18b9ad7baa0cf 100644 --- a/releases/release-5.2.2.md +++ b/releases/release-5.2.2.md @@ -37,7 +37,7 @@ TiDB バージョン: 5.2.2 - Kafka シンク設定項目`MaxMessageBytes`のデフォルト値を 64 MB から 1 MB に減らし、大きなメッセージが Kafka ブローカーによって拒否される問題を修正しました。 [#3104](https://github.com/pingcap/tiflow/pull/3104) - レプリケーションパイプラインのメモリ使用量を削減する[#2553](https://github.com/pingcap/tiflow/issues/2553) [#3037](https://github.com/pingcap/tiflow/pull/3037) [#2726](https://github.com/pingcap/tiflow/pull/2726) - - 監視項目とアラートルールを最適化して、同期リンク、メモリGC、在庫データスキャンプロセスの可観測性を向上させる[#2735](https://github.com/pingcap/tiflow/pull/2735) [#1606](https://github.com/pingcap/tiflow/issues/1606) [#3000](https://github.com/pingcap/tiflow/pull/3000) [#2985](https://github.com/pingcap/tiflow/issues/2985) [#2156](https://github.com/pingcap/tiflow/issues/2156) + - 監視項目とアラートルールを最適化して、同期リンク、メモリGC、増分スキャンプロセスの可観測性を向上させる[#2735](https://github.com/pingcap/tiflow/pull/2735) [#1606](https://github.com/pingcap/tiflow/issues/1606) [#3000](https://github.com/pingcap/tiflow/pull/3000) [#2985](https://github.com/pingcap/tiflow/issues/2985) [#2156](https://github.com/pingcap/tiflow/issues/2156) - 同期タスクのステータスが正常であれば、ユーザーの誤解を避けるために過去のエラーメッセージは表示されなくなります[#2242](https://github.com/pingcap/tiflow/issues/2242) ## バグ修正 {#bug-fixes} @@ -110,7 +110,7 @@ TiDB バージョン: 5.2.2 - TiCDCによって生成されるKafkaメッセージの量が`max-message-size` に制限されない問題を修正 [#2962](https://github.com/pingcap/tiflow/issues/2962) - Kafka メッセージの書き込み中にエラーが発生すると TiCDC 同期タスクが一時停止する可能性がある問題を修正[#2978](https://github.com/pingcap/tiflow/issues/2978) - `force-replicate`が有効になっているときに、有効なインデックスのない一部のパーティションテーブルが無視される可能性がある問題を修正[#2834](https://github.com/pingcap/tiflow/issues/2834) - - 株価データのスキャンに時間がかかりすぎると、TiKV が GC を実行するため株価データのスキャンが失敗する可能性がある問題を修正しました[#2470](https://github.com/pingcap/tiflow/issues/2470) + - 初期化に時間がかかりすぎて TiKV が GC safepoint を進めると、changefeed が失敗する可能性がある問題を修正しました[#2470](https://github.com/pingcap/tiflow/issues/2470) - 一部のタイプの列を Open Protocol 形式にエンコードするときに発生する可能性のあるpanic問題を修正しました。 [#2758](https://github.com/pingcap/tiflow/issues/2758) - 一部のタイプの列をAvro形式にエンコードする際に発生する可能性のあるpanic問題を修正しました [#2648](https://github.com/pingcap/tiflow/issues/2648) diff --git a/releases/release-5.3.0.md b/releases/release-5.3.0.md index b5a998261209b..f13881472bbe9 100644 --- a/releases/release-5.3.0.md +++ b/releases/release-5.3.0.md @@ -331,7 +331,7 @@ TiCDC v5.3.0以降、TiDBクラスター間の循環レプリケーション機 - Kafka シンク設定項目`MaxMessageBytes`のデフォルト値を 64 MB から 1 MB に減らし、大きなメッセージが Kafka ブローカーによって拒否される問題を修正しました。 [#3104](https://github.com/pingcap/tiflow/pull/3104) - レプリケーションパイプラインのメモリ使用量を削減する[#2553](https://github.com/pingcap/tiflow/issues/2553) [#3037](https://github.com/pingcap/tiflow/pull/3037) [#2726](https://github.com/pingcap/tiflow/pull/2726) - - 監視項目とアラートルールを最適化して、同期リンク、メモリGC、および在庫データスキャンプロセスの可観測性を向上させる[#2735](https://github.com/pingcap/tiflow/pull/2735) [#1606](https://github.com/pingcap/tiflow/issues/1606) [#3000](https://github.com/pingcap/tiflow/pull/3000) [#2985](https://github.com/pingcap/tiflow/issues/2985) [#2156](https://github.com/pingcap/tiflow/issues/2156) + - 監視項目とアラートルールを最適化して、同期リンク、メモリGC、および増分スキャンプロセスの可観測性を向上させる[#2735](https://github.com/pingcap/tiflow/pull/2735) [#1606](https://github.com/pingcap/tiflow/issues/1606) [#3000](https://github.com/pingcap/tiflow/pull/3000) [#2985](https://github.com/pingcap/tiflow/issues/2985) [#2156](https://github.com/pingcap/tiflow/issues/2156) - 同期タスクのステータスが正常であれば、ユーザーの誤解を避けるために、過去のエラーメッセージは表示されなくなります[#2242](https://github.com/pingcap/tiflow/issues/2242) ## バグ修正 {#bug-fixes} @@ -422,7 +422,7 @@ TiCDC v5.3.0以降、TiDBクラスター間の循環レプリケーション機 - TiCDCによって生成されるKafkaメッセージの量が`max-message-size` に制限されない問題を修正 [#2962](https://github.com/pingcap/tiflow/issues/2962) - Kafka メッセージの書き込み中にエラーが発生すると、TiCDC 同期タスクが一時停止する可能性がある問題を修正しました[#2978](https://github.com/pingcap/tiflow/issues/2978) - `force-replicate`が有効になっているときに、有効なインデックスのない一部のパーティションテーブルが無視される可能性がある問題を修正[#2834](https://github.com/pingcap/tiflow/issues/2834) - - 株価データのスキャンに時間がかかりすぎると、TiKV が GC を実行するため株価データのスキャンが失敗する可能性がある問題を修正しました[#2470](https://github.com/pingcap/tiflow/issues/2470) + - 初期化に時間がかかりすぎて TiKV が GC safepoint を進めた場合に、changefeed が失敗する可能性がある問題を修正しました[#2470](https://github.com/pingcap/tiflow/issues/2470) - 一部のタイプの列を Open Protocol 形式にエンコードするときに発生する可能性のあるpanic問題を修正しました。 [#2758](https://github.com/pingcap/tiflow/issues/2758) - 一部のタイプの列をAvro形式にエンコードする際に発生する可能性のあるpanic問題を修正しました [#2648](https://github.com/pingcap/tiflow/issues/2648) diff --git a/releases/release-5.4.3.md b/releases/release-5.4.3.md index 1c0312e0bbf96..b70a88ad48f84 100644 --- a/releases/release-5.4.3.md +++ b/releases/release-5.4.3.md @@ -33,7 +33,7 @@ TiDB バージョン: 5.4.3 - `SHOW CREATE PLACEMENT POLICY`の誤った出力を修正[#37526](https://github.com/pingcap/tidb/issues/37526) - クラスターのPDノードが交換された後、一部のDDL文が一定期間スタックする可能性がある問題を修正しました[#33908](https://github.com/pingcap/tidb/issues/33908) - `KILL TIDB`アイドル接続時にすぐに効果を発揮できない問題を修正[#24031](https://github.com/pingcap/tidb/issues/24031) - - `INFORMSTION_SCHEMA.COLUMNS`システムテーブルをクエリするときに`DATA_TYPE`と`COLUMN_TYPE`列に誤った結果が返される問題を修正しました[#36496](https://github.com/pingcap/tidb/issues/36496) + - `INFORMATION_SCHEMA.COLUMNS`システムテーブルをクエリするときに`DATA_TYPE`と`COLUMN_TYPE`列に誤った結果が返される問題を修正しました[#36496](https://github.com/pingcap/tidb/issues/36496) - TiDB Binlogが有効な場合、 `ALTER SEQUENCE`文を実行するとメタデータバージョンが間違って発生し、 Drainerが終了する可能性がある問題を修正しました[#36276](https://github.com/pingcap/tidb/issues/36276) - `UNION`演算子が予期しない空の結果を返す可能性がある問題を修正しました[#36903](https://github.com/pingcap/tidb/issues/36903) - TiFlashのパーティションテーブルでダイナミックモードを有効にしたときに発生する誤った結果を修正しました[#37254](https://github.com/pingcap/tidb/issues/37254) diff --git a/releases/release-6.5.7.md b/releases/release-6.5.7.md index 10cba6bc0c469..bec0659f173f1 100644 --- a/releases/release-6.5.7.md +++ b/releases/release-6.5.7.md @@ -59,7 +59,7 @@ TiDB バージョン: 6.5.7 - `WITH RECURSIVE` CTE を含む`UPDATE`または`DELETE`文で誤った結果が生成される可能性がある問題を修正しました[#48969](https://github.com/pingcap/tidb/issues/48969) @[winoros](https://github.com/winoros) - データの末尾にスペースが含まれている場合に`LIKE`で`_`ワイルドカードを使用すると、クエリ結果が不正確になる可能性がある問題を修正しました[#48983](https://github.com/pingcap/tidb/issues/48983) @[time-and-fate](https://github.com/time-and-fate) - メモリが`tidb_mem_quota_query` を超えると IndexHashJoin オペレーターを含むクエリが停止する問題を修正しました [#49033](https://github.com/pingcap/tidb/issues/49033) @[XuHuaiyu](https://github.com/XuHuaiyu) - - ネストされた`UNION`クエリで`LIMIT`と`OPRDERBY`無効になる可能性がある問題を修正しました [#49377](https://github.com/pingcap/tidb/issues/49377) @[AilinKid](https://github.com/AilinKid) + - ネストされた`UNION`クエリで`LIMIT`と`ORDER BY`が無効になる可能性がある問題を修正しました [#49377](https://github.com/pingcap/tidb/issues/49377) @[AilinKid](https://github.com/AilinKid) - 非厳密モード（ `sql_mode = ''` ）で、 `INSERT`実行中に切り捨てが行われてもエラーが報告される問題を修正しました。 [#49369](https://github.com/pingcap/tidb/issues/49369) @[tiancaiamao](https://github.com/tiancaiamao) - TiDBがパニックを起こしてエラーを報告する問題を修正`invalid memory address or nil pointer dereference` [#42739](https://github.com/pingcap/tidb/issues/42739) @[CbcWestwolf](https://github.com/CbcWestwolf) - CTEクエリが再試行プロセス中にエラー`type assertion for CTEStorageMap failed`を報告する可能性がある問題を修正しました [#46522](https://github.com/pingcap/tidb/issues/46522) @[tiancaiamao](https://github.com/tiancaiamao) diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md index 27d75ab12e232..aeea58075edfe 100644 --- a/releases/release-6.6.0.md +++ b/releases/release-6.6.0.md @@ -537,7 +537,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - TiCDC - - `transaction_atomicity`と`protocol`が設定ファイル経由で更新できない問題を修正しました [#7935](https://github.com/pingcap/tiflow/issues/7935) @[CharlesCheung96](https://github.com/CharlesCheung96) + - `transaction-atomicity`と`protocol`が設定ファイル経由で更新できない問題を修正しました [#7935](https://github.com/pingcap/tiflow/issues/7935) @[CharlesCheung96](https://github.com/CharlesCheung96) - リドゥログのストレージパスで事前チェックが実行されない問題を修正 [#6335](https://github.com/pingcap/tiflow/issues/6335) @[CharlesCheung96](https://github.com/CharlesCheung96) - S3ストレージ障害時にリドゥログが許容できる期間が不十分であるという問題を修正 [#8089](https://github.com/pingcap/tiflow/issues/8089) @[CharlesCheung96](https://github.com/CharlesCheung96) - TiKVまたはTiCDCノードのスケールインまたはスケールアウト時などの特殊なシナリオでchangefeedが停止する可能性がある問題を修正しました [#8174](https://github.com/pingcap/tiflow/issues/8174) @[hicqu](https://github.com/hicqu) diff --git a/releases/release-7.1.4.md b/releases/release-7.1.4.md index 552f7becf6170..241cc9d9fafe1 100644 --- a/releases/release-7.1.4.md +++ b/releases/release-7.1.4.md @@ -89,7 +89,7 @@ TiDBバージョン: 7.1.4 - 定数伝播で`ENUM`または`SET`型を処理するときに TiDB が間違ったクエリ結果を返す問題を修正しました [#49440](https://github.com/pingcap/tidb/issues/49440) @[winoros](https://github.com/winoros) - 依存関係のある 2つの DDL タスクの完了時間がと誤って順序付けられる問題を修正しました。 [#49498](https://github.com/pingcap/tidb/issues/49498) @[tangenta](https://github.com/tangenta) - `tidb_enable_prepared_plan_cache`システム変数が有効になってから無効になった後に`EXECUTE`文を使用して`PREPARE STMT`を実行すると、TiDB がpanicになる可能性がある問題を修正しました[#49344](https://github.com/pingcap/tidb/issues/49344) @[qw4990](https://github.com/qw4990) - - ネストされた`UNION`のクエリで`LIMIT`と`OPRDERBY`無効になる可能性がある問題を修正しました [#49377](https://github.com/pingcap/tidb/issues/49377) @[AilinKid](https://github.com/AilinKid) + - ネストされた`UNION`のクエリで`LIMIT`と`ORDER BY`が無効になる可能性がある問題を修正しました [#49377](https://github.com/pingcap/tidb/issues/49377) @[AilinKid](https://github.com/AilinKid) - `LEADING`ヒントが`UNION ALL`ステートメントで有効にならない問題を修正しました [#50067](https://github.com/pingcap/tidb/issues/50067) @[hawkingrei](https://github.com/hawkingrei) - `COM_STMT_EXECUTE`まで実行された`COMMIT`または`ROLLBACK`操作が、タイムアウトしたトランザクションを終了できない問題を修正しました。 [#49151](https://github.com/pingcap/tidb/issues/49151) @[zyguan](https://github.com/zyguan) - 無効なオプティマイザヒントによって有効なヒントが無効になる可能性がある問題を修正[#49308](https://github.com/pingcap/tidb/issues/49308) @[hawkingrei](https://github.com/hawkingrei) diff --git a/releases/release-7.5.1.md b/releases/release-7.5.1.md index 0250e7a193661..33f40324036f4 100644 --- a/releases/release-7.5.1.md +++ b/releases/release-7.5.1.md @@ -145,7 +145,7 @@ TiDB バージョン: 7.5.1 - `STREAM_AGG()` CI を誤って処理したためにクエリ結果が正しくない問題を修正しました [#49902](https://github.com/pingcap/tidb/issues/49902) @[wshwsh12](https://github.com/wshwsh12) - 多数のテーブルまたはパーティションを処理するときに TiDB ノードが OOM エラーに遭遇する可能性がある問題を軽減します。 [#50077](https://github.com/pingcap/tidb/issues/50077) @[zimulala](https://github.com/zimulala) - `LEADING`ヒントが`UNION ALL`ステートメントで有効にならない問題を修正しました [#50067](https://github.com/pingcap/tidb/issues/50067) @[hawkingrei](https://github.com/hawkingrei) - - ネストされた`UNION`のクエリで`LIMIT`と`OPRDERBY`無効になる可能性がある問題を修正しました [#49377](https://github.com/pingcap/tidb/issues/49377) @[AilinKid](https://github.com/AilinKid) + - ネストされた`UNION`のクエリで`LIMIT`と`ORDER BY`が無効になる可能性がある問題を修正しました [#49377](https://github.com/pingcap/tidb/issues/49377) @[AilinKid](https://github.com/AilinKid) - メモリが`tidb_mem_quota_query` を超えると IndexHashJoin オペレーターを含むクエリが停止する問題を修正しました [#49033](https://github.com/pingcap/tidb/issues/49033) @[XuHuaiyu](https://github.com/XuHuaiyu) - 定数伝播で`ENUM`または`SET`型を処理するときに TiDB が間違ったクエリ結果を返す問題を修正しました [#49440](https://github.com/pingcap/tidb/issues/49440) @[winoros](https://github.com/winoros) - `PREPARE`メソッドを使用して`SELECT INTO OUTFILE`を実行すると、エラーではなく、誤って成功メッセージが返される問題を修正しました。 [#49166](https://github.com/pingcap/tidb/issues/49166) @[qw4990](https://github.com/qw4990) diff --git a/sql-mode.md b/sql-mode.md index fb2a10a8f78a7..9d696725350b2 100644 --- a/sql-mode.md +++ b/sql-mode.md @@ -40,7 +40,7 @@ TiDB の起動後、 `SET [ SESSION | GLOBAL ] sql_mode='modes'`ステートメ | `STRICT_ALL_TABLES` | トランザクションテーブルの場合、無効な値が挿入された後にトランザクションステートメント全体をロールバックします。（完全サポート） | | `NO_ZERO_IN_DATE` | 厳格モードでは、月または日の一部が`0`である日付は受け入れられません。 `IGNORE`オプションを使用すると、TiDB は同様の日付に対して '0000-00-00' を挿入します。非厳格モードでは、この日付は受け入れられますが、警告が表示されます。（完全サポート） | | `NO_ZERO_DATE` | 厳格モードでは、'0000-00-00'を有効な日付として使用しません。ただし`IGNORE`オプションを使用すれば、ゼロの日付を挿入することは可能です。非厳格モードでは、この日付は受け入れられますが、警告が表示されます。（完全サポート） | -| `ALLOW_INVALID_DATES` | このモードでは、システムはすべての日付の有効性をチェックするわけではありません。 `1`から`12`までの月の値と、 `1`から`31`までの日付の値のみをチェックします。このモードは`DATE`列と`DATATIME`列にのみ適用されます。 `TIMESTAMP`列はすべて完全な有効性チェックが必要です。（完全サポート） | +| `ALLOW_INVALID_DATES` | このモードでは、システムはすべての日付の有効性をチェックするわけではありません。 `1`から`12`までの月の値と、 `1`から`31`までの日付の値のみをチェックします。このモードは`DATE`列と`DATETIME`列にのみ適用されます。 `TIMESTAMP`列はすべて完全な有効性チェックが必要です。（完全サポート） | | `ERROR_FOR_DIVISION_BY_ZERO` | このモードが有効になっている場合、システムはデータ変更操作（ `INSERT`または`UPDATE` ）で`0`による除算を処理する際にエラーを返します。
    このモードが有効になっていない場合、システムは警告を返し、代わりに`NULL`が使用されます。（完全サポート） | | `NO_AUTO_CREATE_USER` | `GRANT` 、指定されたパスワード以外の新規ユーザーを自動的に作成することを防止します（完全サポート）。 | | `HIGH_NOT_PRECEDENCE` | NOT演算子の優先順位は、 `NOT a BETWEEN b AND c`のような式`NOT (a BETWEEN b AND c)`として解析されるように設定されています。MySQLの古いバージョンでは、この式は`(NOT a) BETWEEN b AND c`として解析されます。（完全サポート） | diff --git a/sql-statements/sql-statement-admin-show-ddl.md b/sql-statements/sql-statement-admin-show-ddl.md index 70158d88bd3dc..097344e467739 100644 --- a/sql-statements/sql-statement-admin-show-ddl.md +++ b/sql-statements/sql-statement-admin-show-ddl.md @@ -87,7 +87,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `cancelling` : 操作がキャンセルされていることを示します。この状態は、 [`ADMIN CANCEL DDL JOBS`](/sql-statements/sql-statement-admin-cancel-ddl.md)コマンドを使用して DDL ジョブをキャンセルした場合にのみ表示されます。 - `cancelled` : 操作がキャンセルされたことを示します。 - `pausing` : 操作を一時停止中であることを示します。 - - `paused` : 操作が一時停止されていることを示します。この状態は、 [`ADMIN PAUSED DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)コマンドを使用して DDL ジョブを一時停止した場合にのみ表示されます。 [`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)コマンドを使用して DDL ジョブを再開できます。 + - `paused` : 操作が一時停止されていることを示します。この状態は、 [`ADMIN PAUSE DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)コマンドを使用して DDL ジョブを一時停止した場合にのみ表示されます。 [`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)コマンドを使用して DDL ジョブを再開できます。 - `done` : 操作は TiDB 所有者ノードで正常に実行されたが、他の TiDB ノードではこの DDL ジョブによって実行された変更がまだ同期されていないことを示します。 - `COMMENTS` : 診断目的の追加情報が含まれます。 - `ingest` : [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)で構成された、高速化されたインデックス追加バックフィルのための取り込み（ingest）タスク。 @@ -122,7 +122,7 @@ OWNER_ADDRESS: 0.0.0.0:4000 - `rollback done` : 操作が失敗し、ロールバックが完了したことを示します。 - `rollingback` : 操作が失敗し、ロールバック中であることを示します。 - `cancelling` : 操作がキャンセルされていることを示します。この状態は、 [`ADMIN CANCEL DDL JOBS`](/sql-statements/sql-statement-admin-cancel-ddl.md)コマンドを使用して DDL ジョブをキャンセルした場合にのみ表示されます。 - - `paused` : 操作が一時停止されていることを示します。この状態は、 [`ADMIN PAUSED DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)コマンドを使用して DDL ジョブを一時停止した場合にのみ表示されます。 [`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)コマンドを使用して DDL ジョブを再開できます。 + - `paused` : 操作が一時停止されていることを示します。この状態は、 [`ADMIN PAUSE DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)コマンドを使用して DDL ジョブを一時停止した場合にのみ表示されます。 [`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)コマンドを使用して DDL ジョブを再開できます。 diff --git a/sql-statements/sql-statement-admin.md b/sql-statements/sql-statement-admin.md index b200ec0a6dc4f..9a6c7245a7b2b 100644 --- a/sql-statements/sql-statement-admin.md +++ b/sql-statements/sql-statement-admin.md @@ -46,7 +46,7 @@ summary: TiDBデータベースにおけるADMINの使用方法の概要。 ADMIN RELOAD expr_pushdown_blacklist; ``` -上記のステートメントは、式によってプッシュダウンされたブロックリストを再読み込みするために使用されます。 +上記のステートメントは、式プッシュダウンのブロックリストを再読み込みするために使用されます。 ```sql ADMIN RELOAD opt_rule_blacklist; @@ -90,7 +90,7 @@ ADMIN CAPTURE BINDINGS; ADMIN EVOLVE BINDINGS; ``` -自動バインディング機能が有効になると、SQL プランのバインディング情報の進化は`bind-info-leave`ごと（デフォルト値は`3s` ）にトリガーされます。上記のステートメントは、この進化を事前にトリガーするために使用されます。 +自動バインディング機能が有効になると、SQL プランのバインディング情報の進化は`bind-info-lease`ごと（デフォルト値は`3s` ）にトリガーされます。上記のステートメントは、この進化を事前にトリガーするために使用されます。 ```sql ADMIN RELOAD BINDINGS; @@ -295,7 +295,7 @@ ADMIN SHOW DDL JOBS 5 WHERE state != 'synced' AND db_name = 'test'; - `rollback done` : 操作が失敗し、ロールバックが完了したことを示します。 - `rollingback` : 操作が失敗し、ロールバックされていることを示します。 - `cancelling` : これは、操作がキャンセルされていることを示します。この状態は、 [`ADMIN CANCEL DDL JOBS`](/sql-statements/sql-statement-admin-cancel-ddl.md)コマンドを使用して DDL ジョブをキャンセルした場合にのみ発生します。 - - `paused` : 操作が一時停止されていることを示します。この状態は[`ADMIN PAUSED DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)コマンドを使用して DDL ジョブを一時停止した場合にのみ表示されます。[`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)コマンドを使用して DDL ジョブを再開できます。 + - `paused` : 操作が一時停止されていることを示します。この状態は[`ADMIN PAUSE DDL JOBS`](/sql-statements/sql-statement-admin-pause-ddl.md)コマンドを使用して DDL ジョブを一時停止した場合にのみ表示されます。[`ADMIN RESUME DDL JOBS`](/sql-statements/sql-statement-admin-resume-ddl.md)コマンドを使用して DDL ジョブを再開できます。 ## MySQLとの互換性 {#mysql-compatibility} diff --git a/sql-statements/sql-statement-commit.md b/sql-statements/sql-statement-commit.md index e681a4fb455f3..1bad5b9fb817f 100644 --- a/sql-statements/sql-statement-commit.md +++ b/sql-statements/sql-statement-commit.md @@ -40,7 +40,7 @@ Query OK, 0 rows affected (0.01 sec) - 現在、TiDBはメタデータロック（MDL）を使用して、DDL文によるトランザクションで使用されるテーブルの変更をデフォルトで防止しています。メタデータロックの動作はTiDBとMySQLで異なります。詳細については、 [メタデータロック](/metadata-lock.md)を参照してください。 - TiDB 3.0.8以降のバージョンでは、デフォルトで[悲観的ロック](/pessimistic-transaction.md)が使用されます。 [楽観的ロック](/optimistic-transaction.md)を使用する場合は、別のトランザクションによって行が変更されているために`COMMIT`文が失敗する可能性があることを考慮することが重要です。 -- 楽観的ロックが有効な場合、`UNIQUE`と`PRIMARY KEY`の制約チェックは文のコミットまで延期されます。これにより、`COMMIT`文が失敗する状況が増えます。この動作は`tidb_constraint_check_in_place=ON`を設定することで変更できます。 +- 楽観的ロックが有効な場合、`UNIQUE`と`PRIMARY KEY`の制約チェックはトランザクションがコミットされるまで延期されます。これにより、`COMMIT`文が失敗する状況が増えます。この動作は`tidb_constraint_check_in_place=ON`を設定することで変更できます。 - TiDBは構文`ROLLBACK AND [NO] RELEASE`を解析しますが、無視します。この機能はMySQLでトランザクションのコミット直後にクライアントセッションを切断するために使用されます。TiDBでは、代わりにクライアントドライバの`mysql_close()`機能を使用することをお勧めします。 - TiDBは構文`ROLLBACK AND [NO] CHAIN`を解析しますが、無視します。この機能はMySQLで使用され、現在のトランザクションがコミットされている間に、同じ分離レベルで新しいトランザクションを即座に開始します。TiDBでは、代わりに新しいトランザクションを開始することが推奨されます。 diff --git a/sql-statements/sql-statement-create-database.md b/sql-statements/sql-statement-create-database.md index 79232925b7eb6..69af090bb77be 100644 --- a/sql-statements/sql-statement-create-database.md +++ b/sql-statements/sql-statement-create-database.md @@ -47,7 +47,7 @@ create_specification: | [DEFAULT] COLLATE [=] collation_name ``` -既存のデータベースを作成し、 `IF NOT EXISTS`を指定しないと、エラーが表示されます。 +既存のデータベースを作成する際に、 `IF NOT EXISTS`を指定しないと、エラーが表示されます。 `create_specification`オプションは、データベース内の特定の`CHARACTER SET`と`COLLATE`を指定するために使用されます。現在、TiDB は一部の文字セットと照合順序のみをサポートしています。詳細については、 [文字セットと照合順序のサポート](/character-set-and-collation.md)を参照してください。 diff --git a/sql-statements/sql-statement-create-index.md b/sql-statements/sql-statement-create-index.md index 49cfac35d0612..27a96fce13697 100644 --- a/sql-statements/sql-statement-create-index.md +++ b/sql-statements/sql-statement-create-index.md @@ -366,7 +366,9 @@ Query OK, 1 row affected (0.00 sec) - テーブルが多値インデックスを使用している場合、 BR、TiCDC、またはTiDB Lightningを使用して、v6.6.0より前のTiDBクラスタにテーブルをバックアップ、レプリケート、またはインポートすることはできません。 - 複雑な条件を含むクエリの場合、TiDB は多値インデックスを選択できない場合があります。多値インデックスでサポートされる条件パターンについては、 [多値インデックスを使用する](/choose-index.md#use-multi-valued-indexes)を参照してください。 -## 部分インデックス v8.5.7 の新機能 {#partial-indexes-new-in-v857} +## 部分インデックス {#partial-indexes} + +TiDB Self-Managed と TiDB Cloud Dedicated では v8.5.7 の新機能であり、TiDB Cloud Essential と Premium では CLOUD.202603.1 の新機能です 部分インデックスは、テーブル内の行のサブセットに対して構築されるインデックスです。部分インデックスを作成する際には、その行のサブセットを定義するために、述語とも呼ばれる条件式を指定できます。インデックスには、その述語を満たす行に対するエントリのみが含まれます。 diff --git a/sql-statements/sql-statement-create-sequence.md b/sql-statements/sql-statement-create-sequence.md index 11b3ccdbd8d00..fa84814c05e25 100644 --- a/sql-statements/sql-statement-create-sequence.md +++ b/sql-statements/sql-statement-create-sequence.md @@ -59,7 +59,7 @@ CREATE [TEMPORARY] SEQUENCE [IF NOT EXISTS] sequence_name | `MAXVALUE` | `9223372036854775806`または`-1` | シーケンスの最大値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`9223372036854775806`です。`INCREMENT` < `0`の場合、デフォルト値は`-1`です。 | | `START` | `MINVALUE`または`MAXVALUE` | シーケンスの初期値を指定します。`INCREMENT` > `0`の場合、デフォルト値は`MINVALUE`です。`INCREMENT` < `0`の場合、デフォルト値は`MAXVALUE`です。 | | `CACHE` | `1000` | TiDB 内のシーケンスのローカルキャッシュサイズを指定します。 | -| `CYCLE` | `NO CYCLE` | シーケンスを最小値（降順シーケンスの場合は最大値）から再開するかどうかを指定します。`INCREMENT` > `0`の場合、デフォルト値は`MINVALUE`です。`INCREMENT` < `0`の場合、デフォルト値は`MAXVALUE`です。 | +| `CYCLE` | `NO CYCLE` | シーケンスが使い果たされた後に最小値（降順シーケンスの場合は最大値）から再開するかどうかを指定します。`CYCLE`モードでは、`INCREMENT` > `0`の場合、シーケンスは使い果たされた後に`MINVALUE`から再開します。`INCREMENT` < `0`の場合、`MAXVALUE`から再開します。 | ## `SEQUENCE`関数 {#sequence-function} diff --git a/sql-statements/sql-statement-create-user.md b/sql-statements/sql-statement-create-user.md index 7ec1b102b6174..a702d7acc2163 100644 --- a/sql-statements/sql-statement-create-user.md +++ b/sql-statements/sql-statement-create-user.md @@ -59,7 +59,7 @@ mysql> CREATE USER 'newuser' IDENTIFIED BY 'newuserpassword'; Query OK, 1 row affected (0.04 sec) ``` -`192.168.1.1`のみにログインできるユーザーを作成します。 +`192.168.1.1`からのみログインできるユーザーを作成します。 ```sql mysql> CREATE USER 'newuser2'@'192.168.1.1' IDENTIFIED BY 'newuserpassword'; diff --git a/sql-statements/sql-statement-distribute-table.md b/sql-statements/sql-statement-distribute-table.md index f45192a63b2c1..ac0594633ac3a 100644 --- a/sql-statements/sql-statement-distribute-table.md +++ b/sql-statements/sql-statement-distribute-table.md @@ -19,7 +19,7 @@ summary: TiDBデータベースにおけるDISTRIBUTE TABLEの使用方法の概 ```ebnf+diagram DistributeTableStmt ::= - "DISTRIBUTE" "TABLE" TableName PartitionNameListOpt "RULE" EqOrAssignmentEq Identifier "ENGINE" EqOrAssignmentEq Identifier "TIMEOUT" EqOrAssignmentEq Identifier + "DISTRIBUTE" "TABLE" TableName PartitionNameListOpt "RULE" EqOrAssignmentEq Identifier "ENGINE" EqOrAssignmentEq Identifier ("TIMEOUT" EqOrAssignmentEq Identifier)? TableName ::= (SchemaName ".")? Identifier diff --git a/sql-statements/sql-statement-drop-binding.md b/sql-statements/sql-statement-drop-binding.md index 74fa684d2bee9..8eb49eeebb967 100644 --- a/sql-statements/sql-statement-drop-binding.md +++ b/sql-statements/sql-statement-drop-binding.md @@ -35,7 +35,7 @@ SQL文または SQL ダイジェストに従ってバインディングを削除 SQL ダイジェストに従ってバインディングを削除する場合は、対応する SQL ダイジェストを指定する必要があります。 -- プランダイジェストを指定するには、文字列リテラルまたは文字列型のユーザー変数のいずれかを使用できます。 +- SQL ダイジェストを指定するには、文字列リテラルまたは文字列型のユーザー変数のいずれかを使用できます。 - 複数の文字列値を指定し、各文字列に複数のダイジェストを含めることができます。文字列またはダイジェストはカンマで区切る必要があることに注意してください。 次の例は、SQL文に従ってバインディングを削除する方法を示しています。 diff --git a/sql-statements/sql-statement-drop-placement-policy.md b/sql-statements/sql-statement-drop-placement-policy.md index 03080c2d53531..72ead6d0327c0 100644 --- a/sql-statements/sql-statement-drop-placement-policy.md +++ b/sql-statements/sql-statement-drop-placement-policy.md @@ -1,6 +1,6 @@ --- title: DROP PLACEMENT POLICY -summary: TiDBにおけるALTER PLACEMENT POLICYの使用方法。 +summary: TiDBにおけるDROP PLACEMENT POLICYの使用方法。 --- # DROP PLACEMENT POLICY {#drop-placement-policy} diff --git a/sql-statements/sql-statement-modify-column.md b/sql-statements/sql-statement-modify-column.md index f199b75420dfe..bafab68ef733d 100644 --- a/sql-statements/sql-statement-modify-column.md +++ b/sql-statements/sql-statement-modify-column.md @@ -15,7 +15,7 @@ TiDB v5.1.0以降、Reorg-Dataを必要とする列型の変更がサポート - `DECIMAL`精度の変更 - `VARCHAR(10)`の長さを`VARCHAR(5)`に短縮する -v8.5.5以降、TiDBは、以前はReorg-Dataを必要としていた一部の列型変更を最適化します。以下の条件が満たされた場合、TiDBはテーブル全体ではなく、影響を受けるインデックスのみを再構築するため、実行効率が向上します。 +TiDB Self-Managed および TiDB Cloud Dedicated では v8.5.5 以降、TiDB Cloud Essential および Premium では CLOUD.202603.1 以降、TiDBは、以前はReorg-Dataを必要としていた一部の列型変更を最適化します。以下の条件が満たされた場合、TiDBはテーブル全体ではなく、影響を受けるインデックスのみを再構築するため、実行効率が向上します。 - 現在のセッションでは、厳密な[SQLモード](/sql-mode.md) ( `sql_mode`は`STRICT_TRANS_TABLES`または`STRICT_ALL_TABLES`が含まれます ) が使用されます。 - テーブルにはTiFlashレプリカがありません。 diff --git a/sql-statements/sql-statement-overview.md b/sql-statements/sql-statement-overview.md index df90388d4f636..34ceaaa1054fb 100644 --- a/sql-statements/sql-statement-overview.md +++ b/sql-statements/sql-statement-overview.md @@ -306,7 +306,7 @@ TiDBは、ISO/IEC SQL標準に準拠することを目的としたSQL文を使 > **Note:** > -> [TiCDC](https://docs.pingcap.com/tidb/stable/ticdc-overview)は、TiDB Self-ManagedのTiDBデータをアップストリームに複製するためのツールです。TiCDCのほとんどのSQL文はTiDB Cloudには適用できません。TiDB Cloudの場合は、代わりに[TiDB Cloudコンソール](https://tidbcloud.com)の[変更フィード](/tidb-cloud/changefeed-overview.md)機能を使用してデータをストリーミングできます。 +> [TiCDC](https://docs.pingcap.com/tidb/stable/ticdc-overview)は、TiDB Self-ManagedのTiDBデータをダウンストリームに複製するためのツールです。TiCDCのほとんどのSQL文はTiDB Cloudには適用できません。TiDB Cloudの場合は、代わりに[TiDB Cloudコンソール](https://tidbcloud.com)の[変更フィード](/tidb-cloud/changefeed-overview.md)機能を使用してデータをストリーミングできます。 | SQL文 | 説明 | | --------------------------------------------------------------------------- | -------------------- | diff --git a/sql-statements/sql-statement-select.md b/sql-statements/sql-statement-select.md index d5e8e54685d83..cdc78f2d0bf29 100644 --- a/sql-statements/sql-statement-select.md +++ b/sql-statements/sql-statement-select.md @@ -91,7 +91,7 @@ TableSample ::= | `HIGH_PRIORITY` | `HIGH_PRIORITY`は、現在のステートメントに他のステートメントよりも高い優先順位を与えます。 | | `SQL_CALC_FOUND_ROWS` | TiDBはこの機能をサポートしておらず、 [`tidb_enable_noop_functions=1`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)が設定されていない限りエラーを返します。 | | `SQL_CACHE` 、 `SQL_NO_CACHE` | `SQL_CACHE`と`SQL_NO_CACHE`は、リクエストの結果を TiKV (RocksDB) の`BlockCache`にキャッシュするかどうかを制御するために使用されます。 `count(*)`クエリのように、大量のデータに対して一度だけクエリを実行する場合は、 `BlockCache`内のホットなユーザーデータがフラッシュされないように、 `SQL_NO_CACHE`を指定することを推奨します。 | -| `STRAIGHT_JOIN` | `STRAIGHT_JOIN`は、 `FROM`句で使用されているテーブルの順序で UNION クエリを実行するようにオプティマイザを強制します。オプティマイザが適切な結合順序を選択しない場合、この構文を使用してクエリの実行速度を向上させることができます。 | +| `STRAIGHT_JOIN` | `STRAIGHT_JOIN`は、 `FROM`句で使用されているテーブルの順序で JOIN クエリを実行するようにオプティマイザを強制します。オプティマイザが適切な結合順序を選択しない場合、この構文を使用してクエリの実行速度を向上させることができます。 | | `select_expr` | `select_expr`は、取得する列を示します。列名と式が含まれます。 `\*`はすべての列を表します。 | | `FROM table_references` | `FROM table_references`句は、行を取得するテーブル ( `select * from t;`など)、複数のテーブル ( `select * from t1 join t2;`など)、または 0 個のテーブル ( `select 1+1 from dual;`など、 `select 1+1;`と同等) を指定します。 | | `WHERE where_condition` | `WHERE`句が指定されている場合、行が選択される条件を示します。結果には、その条件を満たすデータのみが含まれます。 | @@ -101,12 +101,12 @@ TableSample ::= | `LIMIT` | `LIMIT`句を使用すると、行数を制限できます。 `LIMIT`は、1つまたは 2つの数値引数を取ります。引数が 1つの場合、引数は返される行の最大数を指定します。返される最初の行は、デフォルトではテーブルの最初の行です。引数が 2つの場合、最初の引数は返される最初の行のオフセットを指定し、2 番目の引数は返される行の最大数を指定します。TiDB は、 `FETCH FIRST/NEXT n ROW/ROWS ONLY`と同じ効果を持つ`LIMIT n`構文もサポートしています。この構文では`n`を省略でき、その効果は`LIMIT 1`と同じです。 | | `Window window_definition` | これはウィンドウ関数の構文であり、通常は分析計算を行うために使用されます。詳細については、 [ウィンドウ関数](/functions-and-operators/window-functions.md)を参照してください。 | | `FOR UPDATE` | `SELECT FOR UPDATE`句は、結果セット内のすべてのデータをロックして、他のトランザクションからの同時更新を検出します。クエリ条件に一致するが結果セットに存在しないデータは、読み取りロックされません。たとえば、現在のトランザクションが開始された後に他のトランザクションによって書き込まれた行データなどです。TiDB が[楽観的トランザクションモード](/optimistic-transaction.md)を使用する場合、ステートメント実行フェーズではトランザクションの競合は検出されません。したがって、現在のトランザクションは、PostgreSQL などの他のデータベースのように、他のトランザクションが`UPDATE` 、 `DELETE` 、または`SELECT FOR UPDATE`を実行するのをブロックしません。コミットフェーズでは、 `SELECT FOR UPDATE`によって読み取られた行は 2つのフェーズでコミットされるため、競合検出に参加することもできます。書き込み競合が発生した場合、 `SELECT FOR UPDATE`句を含むすべてのトランザクションのコミットは失敗します。競合が検出されなかった場合、コミットは成功します。また、ロックされた行に対して新しいバージョンが生成されるため、コミットされていない他のトランザクションが後でコミットされるときに書き込み競合を検出できます。 TiDB が[悲観的なトランザクションモード](/pessimistic-transaction.md)を使用する場合、動作は基本的に他のデータベースと同じです。詳細については、 [MySQL InnoDBとの違い](/pessimistic-transaction.md#differences-from-mysql-innodb)を参照してください。 TiDB は`FOR UPDATE`の`NOWAIT`修飾子をサポートしています。詳細については[TiDB悲観的トランザクションモード](/pessimistic-transaction.md#behaviors)を参照してください。 | -| `LOCK IN SHARE MODE` | 互換性を保証するため、TiDBはこれら3つの修飾子を解析しますが、無視します。 | +| `LOCK IN SHARE MODE` | 互換性を保証するため、TiDBはこの修飾子を解析しますが、無視します。 | | `TABLESAMPLE` | テーブルから行のサンプルを取得します。 | > **Note:** > -> - バージョン 8.5.6 以降、TiDB は`FOR UPDATE OF`句でテーブルエイリアスの使用をサポートしています。下位互換性を維持するために、エイリアスが定義されている場合でもベーステーブル名を参照できますが、明示的なエイリアスの使用を推奨する警告が表示されます。クエリが異なるデータベースにまたがる同じ名前の複数のテーブル (たとえば`FROM db1.t, db2.t FOR UPDATE OF t` ) に関係する場合、TiDB は現在のデータベースコンテキストではなく、 `FROM`句の順序に基づいて、対象テーブルを左から右に照合するようになりました。曖昧さを避けるため、 `FOR UPDATE OF`句でデータベース名を指定するか、エイリアスを使用することをお勧めします。 +> - TiDB Self-Managed と TiDB Cloud Dedicated では v8.5.6 以降、TiDB Cloud Essential と Premium では CLOUD.202603.1 以降、TiDB は`FOR UPDATE OF`句でテーブルエイリアスの使用をサポートしています。下位互換性を維持するために、エイリアスが定義されている場合でもベーステーブル名を参照できますが、明示的なエイリアスの使用を推奨する警告が表示されます。クエリが異なるデータベースにまたがる同じ名前の複数のテーブル (たとえば`FROM db1.t, db2.t FOR UPDATE OF t` ) に関係する場合、TiDB は現在のデータベースコンテキストではなく、 `FROM`句の順序に基づいて、対象テーブルを左から右に照合するようになりました。曖昧さを避けるため、 `FOR UPDATE OF`句でデータベース名を指定するか、エイリアスを使用することをお勧めします。 > - v6.6.0以降、TiDBは[リソース制御](/tidb-resource-control-ru-groups.md)をサポートしています。この機能を使用すると、異なるリソースグループで異なる優先度のSQL文を実行できます。これらのリソースグループに適切なクォータと優先度を設定することで、異なる優先度のSQL文のスケジューリングをより適切に制御できます。リソース制御が有効になっている場合、文の優先度（ `HIGH_PRIORITY` ）は適用されなくなります。異なるSQL文のリソース使用量を管理するには、[リソース制御](/tidb-resource-control-ru-groups.md)を使用することをお勧めします。 ## 例 {#examples} diff --git a/sql-statements/sql-statement-set-resource-group.md b/sql-statements/sql-statement-set-resource-group.md index ec374ae3c41d4..70b6bd5c00996 100644 --- a/sql-statements/sql-statement-set-resource-group.md +++ b/sql-statements/sql-statement-set-resource-group.md @@ -38,6 +38,7 @@ ResourceGroupName ::= ```sql CREATE USER 'user1'; CREATE RESOURCE GROUP 'rg1' RU_PER_SEC = 1000; +CREATE RESOURCE GROUP 'rg2' RU_PER_SEC = 2000; ALTER USER 'user1' RESOURCE GROUP `rg1`; ``` diff --git a/sql-statements/sql-statement-show-analyze-status.md b/sql-statements/sql-statement-show-analyze-status.md index fe9d2b1cf878b..879db00c4067e 100644 --- a/sql-statements/sql-statement-show-analyze-status.md +++ b/sql-statements/sql-statement-show-analyze-status.md @@ -23,10 +23,14 @@ TiDB v7.3.0 以降では、システムテーブル`mysql.analyze_jobs`または | `Job_info` | タスク情報。インデックスが分析される場合、この情報にはインデックス名が含まれます。`tidb_analyze_version =2`の場合、この情報にはサンプルレートなどの設定項目が含まれます。 | | `Processed_rows` | 分析された行数 | | `Start_time` | タスクが開始される時間 | +| `End_time` | タスクが終了する時間 | | `State` | `pending` 、 `running` 、 `finished` 、 `failed`を含むタスクの状態 | | `Fail_reason` | タスクが失敗した理由。実行が成功した場合、値は`NULL`になります。 | | `Instance` | タスクを実行するTiDBインスタンス | -| `Process_id` | タスクを実行するプロセスID | +| `Process_ID` | タスクを実行するプロセスID | +| `Remaining_seconds` | タスク完了までの推定残り時間（秒） | +| `Progress` | タスクの進行状況 | +| `Estimated_total_rows` | タスクで分析する必要がある総行数 | ## 概要 {#synopsis} @@ -58,7 +62,7 @@ mysql> show analyze status; | test | t | p0 | analyze columns | 0 | 2022-05-27 11:29:46 | 2022-05-27 11:29:46 | finished | NULL | 127.0.0.1:4000 | NULL | NULL | NULL | NULL | | test | t1 | p0 | analyze columns | 28523259 | 2022-05-27 11:29:46 | 2022-05-27 11:29:46 | running | NULL | 127.0.0.1:4000 | 690208308 | 0s | 0.9843 | 28978290 | +--------------+------------+----------------+-------------------+----------------+---------------------+---------------------+----------+-------------+----------------+------------+------------------+----------+---------------------+ -4 rows in set (0.01 sec) +5 rows in set (0.01 sec) mysql> set @@tidb_analyze_version = 2; Query OK, 0 rows affected (0.00 sec) diff --git a/sql-statements/sql-statement-show-bindings.md b/sql-statements/sql-statement-show-bindings.md index 7e5eac646d088..b44ab37423948 100644 --- a/sql-statements/sql-statement-show-bindings.md +++ b/sql-statements/sql-statement-show-bindings.md @@ -20,7 +20,7 @@ ShowLikeOrWhere ::= ## 構文の説明 {#syntax-description} -この文は、GLOBALまたはSESSIONレベルの実行プランバインディングを出力します。デフォルトのスコープはSESSIONです。現在、 `SHOW BINDINGS`は以下に示すように8つの列を出力します。 +この文は、GLOBALまたはSESSIONレベルの実行プランバインディングを出力します。デフォルトのスコープはSESSIONです。現在、 `SHOW BINDINGS`は以下に示すように11個の列を出力します。 | カラム名 | 説明 | | :------- | :---------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -33,6 +33,8 @@ ShowLikeOrWhere ::= | charset | 文字セット | | collation | ソートルール | | source | バインディングが作成される方法には、 `manual` ( `create [global] binding` SQL文によって作成される)、 `capture` (TiDB によって自動的にキャプチャされる)、および`evolve` (TiDB によって自動的に進化される) が含まれます。 | +| sql_digest | 正規化されたSQL文のダイジェスト | +| plan_digest | 実行プランのダイジェスト | ## 例 {#examples} diff --git a/sql-statements/sql-statement-show-placement.md b/sql-statements/sql-statement-show-placement.md index 38fb6df58fada..5f99479090a55 100644 --- a/sql-statements/sql-statement-show-placement.md +++ b/sql-statements/sql-statement-show-placement.md @@ -44,7 +44,7 @@ Query OK, 0 rows affected (0.00 sec) | DATABASE test | PRIMARY_REGION="us-east-1" REGIONS="us-east-1,us-west-1" FOLLOWERS=4 | INPROGRESS | | TABLE test.t1 | PRIMARY_REGION="us-east-1" REGIONS="us-east-1,us-west-1" FOLLOWERS=4 | INPROGRESS | +---------------+----------------------------------------------------------------------+------------------+ -4 rows in set (0.00 sec) +3 rows in set (0.00 sec) ``` ## MySQLとの互換性 {#mysql-compatibility} diff --git a/sql-statements/sql-statement-show-stats-histograms.md b/sql-statements/sql-statement-show-stats-histograms.md index 20618b3578af2..34a8335912799 100644 --- a/sql-statements/sql-statement-show-stats-histograms.md +++ b/sql-statements/sql-statement-show-stats-histograms.md @@ -23,7 +23,7 @@ summary: TiDB データベースの SHOW STATS_HISTOGRAMS の使用法の概要 | `Correlation` | この列と整数主キー列の間のピアソン相関係数。2つの列間の関連の度合いを示します。 | | `Load_status` | 読み込みステータス（ `allEvicted` 、 `allLoaded`など） | | `Total_mem_usage` | 総メモリ使用量 | -| `Hist_mem_usage` | 過去のメモリ使用量 | +| `Hist_mem_usage` | ヒストグラムのメモリ使用量 | | `Topn_mem_usage` | TopNのメモリ使用量 | | `Cms_mem_usage` | CMSのメモリ使用量 | diff --git a/sql-statements/sql-statement-split-region.md b/sql-statements/sql-statement-split-region.md index b7a4cb7955d3a..74ae544a7ec94 100644 --- a/sql-statements/sql-statement-split-region.md +++ b/sql-statements/sql-statement-split-region.md @@ -134,7 +134,7 @@ t22_i5abc 1 つのテーブル内の同じインデックスデータの`table_id`と`index_id`は同じです。インデックスリージョンを分割するには、 `index_value`に基づいてリージョンを分割する必要があります。 -#### 均等に分割 {#even-spilt} +#### 均等に分割 {#even-split} インデックスを均等に分割する方法は、データを均等に分割する方法と同じです。ただし、 `index_value`が整数にならない可能性があるため、ステップの値を計算するのはより複雑になります。 @@ -154,7 +154,7 @@ SPLIT TABLE t INDEX idx BETWEEN (-9223372036854775808) AND (9223372036854775807) SPLIT TABLE t INDEX idx1 BETWEEN ("a") AND ("z") REGIONS 25; ``` -このステートメントは、インデックス idx1 を a~z の 25 個のリージョンに分割します。リージョン1 の範囲は`[minIndexValue, b)`です。リージョン2 の範囲は`[b, c)`です。…リージョン25 の範囲は`[y, minIndexValue]`です。 `idx`インデックスの場合、 `a`接頭辞を持つデータはリージョン1 に書き込まれ、 `b`接頭辞を持つデータはリージョン2 に書き込まれます。 +このステートメントは、インデックス idx1 を a~z の 25 個のリージョンに分割します。リージョン1 の範囲は`[minIndexValue, b)`です。リージョン2 の範囲は`[b, c)`です。…リージョン25 の範囲は`[y, maxIndexValue]`です。 `idx`インデックスの場合、 `a`接頭辞を持つデータはリージョン1 に書き込まれ、 `b`接頭辞を持つデータはリージョン2 に書き込まれます。 上記の分割方法では、 `y`と`z`の接頭辞が付いたデータの両方がリージョン25 に書き込まれます。これは、上限が`z`ではなく`{` (ASCII で`z`の次の文字) であるためです。したがって、より正確な分割方法は次のようになります。 @@ -184,7 +184,7 @@ SPLIT TABLE t INDEX idx2 BETWEEN ("2020-06-01 00:00:00") AND ("2020-07-01 00:00: 結合インデックスのデータリージョン分割の場合、唯一の違いは、複数の列の値を指定できる点です。 -例えば、インデックス`idx3 (a, b)`には 2つの列が含まれており、列`a`はタイムスタンプ型、列`b`は int 型です。列`a`に基づいて時間範囲を分割するだけであれば、単一列の時間インデックスを分割する SQL文を使用できます。この場合、 `lower_value`と`upper_velue`では列`b`の値を指定しないでください。 +例えば、インデックス`idx3 (a, b)`には 2つの列が含まれており、列`a`はタイムスタンプ型、列`b`は int 型です。列`a`に基づいて時間範囲を分割するだけであれば、単一列の時間インデックスを分割する SQL文を使用できます。この場合、 `lower_value`と`upper_value`では列`b`の値を指定しないでください。 ```sql SPLIT TABLE t INDEX idx3 BETWEEN ("2010-01-01 00:00:00") AND ("2020-01-01 00:00:00") REGIONS 10; @@ -268,7 +268,7 @@ region4 [("c", "") , maxIndexValue ) split partition table t between (0) and (10000) regions 4; ``` - 上記の記述において、 `0`と`10000`はそれぞれ、分散したいホットスポットデータに対応する上側境界と下側境界の`row_id`を表します。 + 上記の記述において、 `0`と`10000`はそれぞれ、分散したいホットスポットデータに対応する下側境界と上側境界の`row_id`を表します。 > **Note:** > diff --git a/tidb-cloud/branch-manage.md b/tidb-cloud/branch-manage.md index d29f72046e377..695c2fa2f3c8b 100644 --- a/tidb-cloud/branch-manage.md +++ b/tidb-cloud/branch-manage.md @@ -10,7 +10,7 @@ summary: TiDB Cloudブランチの管理方法を学びましょう。 ## 必要なアクセス {#required-access} - [ブランチを作成する](#create-a-branch)または[ブランチに接続する](#connect-to-a-branch)には、組織の`Organization Owner`ロール、またはターゲット プロジェクトの`Project Owner`ロールに属している必要があります。 -- プロジェクト内のクラスターの[ブランチを表示](#create-a-branch)するには、そのプロジェクトに属している必要があります。 +- プロジェクト内のクラスターの[ブランチを表示](#view-branches)するには、そのプロジェクトに属している必要があります。 権限の詳細については、 [ユーザーロール](/tidb-cloud/manage-user-access.md#user-roles)を参照してください。 diff --git a/tidb-cloud/changefeed-overview.md b/tidb-cloud/changefeed-overview.md index 36497622c26e2..54cb2bfc551c4 100644 --- a/tidb-cloud/changefeed-overview.md +++ b/tidb-cloud/changefeed-overview.md @@ -7,12 +7,12 @@ summary: TiDB Cloud changefeed を使用すると、TiDB Cloudから他のデー -TiDB Cloud changefeed を使用すると、 TiDB Cloudから他のデータサービスにデータをストリーミングできます。現在、 TiDB Cloud Dedicated は、 Apache Kafka、MySQL、 TiDB Cloud、およびクラウドストレージへのデータストリーミングをサポートしています。 +TiDB Cloud changefeed を使用すると、 TiDB Cloudから他のデータサービスにデータをストリーミングできます。現在、 TiDB Cloud Dedicated は、 changefeed を介した Apache Kafka、MySQL、 TiDB Cloud、およびクラウドストレージへのデータストリーミングをサポートしています。 -TiDB Cloud changefeed を使用すると、 TiDB Cloudから他のデータサービスへデータをストリーミングできます。現在、 TiDB Cloud Premium は Apache Kafka と MySQL へのデータストリーミングをサポートしています。 +TiDB Cloud changefeed を使用すると、 TiDB Cloudから他のデータサービスへデータをストリーミングできます。現在、 TiDB Cloud Premium は changefeed を介した Apache Kafka と MySQL へのデータストリーミングをサポートしています。 diff --git a/tidb-cloud/changefeed-sink-to-apache-kafka.md b/tidb-cloud/changefeed-sink-to-apache-kafka.md index d0b72f81ac50e..b6c614745d49c 100644 --- a/tidb-cloud/changefeed-sink-to-apache-kafka.md +++ b/tidb-cloud/changefeed-sink-to-apache-kafka.md @@ -252,7 +252,7 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン - **Case Sensitive**：フィルタルールにおけるデータベース名とテーブル名の照合において、大文字小文字を区別するかどうかを設定できます。デフォルトでは、大文字小文字は区別されません。 - **Filter Rules**：この列でフィルタルールを設定できます。デフォルトでは、すべてのテーブルを複製するルール`*.*`が設定されています。新しいルールを追加すると、 TiDB Cloud はTiDB 内のすべてのテーブルをクエリし、右側のボックスにルールに一致するテーブルのみを表示します。フィルタルールは最大 100 個まで追加できます。 - **Tables with valid keys**：この列には、主キーや一意インデックスなど、有効なキーを持つテーブルが表示されます。 - - **Tables without valid keys**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`"!test.tbl1"`を使用して、テーブル`test.tbl1`を除外できます。 + - **Tables without valid keys**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`!test.tbl1`を使用して、テーブル`test.tbl1`を除外できます。 2. **Event Filter**をカスタマイズして、複製したいイベントを絞り込みます。 diff --git a/tidb-cloud/changefeed-sink-to-apache-pulsar.md b/tidb-cloud/changefeed-sink-to-apache-pulsar.md index 24b56a47b19f8..f4cade9796bec 100644 --- a/tidb-cloud/changefeed-sink-to-apache-pulsar.md +++ b/tidb-cloud/changefeed-sink-to-apache-pulsar.md @@ -116,7 +116,7 @@ Apache PulsarサービスにパブリックIPアクセスを提供する場合 - **Case Sensitive**：フィルタルールにおけるデータベース名とテーブル名の照合において、大文字小文字を区別するかどうかを設定できます。デフォルトでは、大文字小文字は区別されません。 - **Filter Rules**：この列でフィルタルールを設定できます。デフォルトでは、すべてのテーブルを複製するルール`*.*`が設定されています。新しいルールを追加すると、 TiDB Cloud はTiDB 内のすべてのテーブルをクエリし、右側のボックスにルールに一致するテーブルのみを表示します。フィルタルールは最大 100 個まで追加できます。 - **Tables with valid keys**：この列には、主キーや一意インデックスなど、有効なキーを持つテーブルが表示されます。 - - **Tables without valid keys**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`"!test.tbl1"`を使用して、テーブル`test.tbl1`を除外できます。 + - **Tables without valid keys**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`!test.tbl1`を使用して、テーブル`test.tbl1`を除外できます。 2. **Event Filter**をカスタマイズして、複製したいイベントを絞り込みます。 diff --git a/tidb-cloud/changefeed-sink-to-cloud-storage.md b/tidb-cloud/changefeed-sink-to-cloud-storage.md index 5d64010e807cf..96cdd2b1cc8b7 100644 --- a/tidb-cloud/changefeed-sink-to-cloud-storage.md +++ b/tidb-cloud/changefeed-sink-to-cloud-storage.md @@ -260,7 +260,7 @@ access key を使用して認証するには、以下の手順に従ってくだ - **Case Sensitive**：フィルタルールにおけるデータベース名とテーブル名の照合において、大文字小文字を区別するかどうかを設定できます。デフォルトでは、大文字小文字は区別されません。 - **Filter Rules**：この列でフィルタルールを設定できます。デフォルトでは、すべてのテーブルを複製するルール`*.*`が設定されています。新しいルールを追加すると、 TiDB Cloud はTiDB 内のすべてのテーブルをクエリし、右側のボックスにルールに一致するテーブルのみを表示します。フィルタルールは最大 100 個まで追加できます。 - **Tables with valid keys**：この列には、主キーや一意インデックスなど、有効なキーを持つテーブルが表示されます。 - - **Tables without valid keys**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、下流で重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを使用してこれらのテーブルを除外することもできます。たとえば、ルール`test.tbl1`を使用して、テーブル`"!test.tbl1"` 。 + - **Tables without valid keys**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、下流で重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを使用してこれらのテーブルを除外することもできます。たとえば、ルール`!test.tbl1`を使用して、テーブル`test.tbl1`を除外できます。 2. **Event Filter**をカスタマイズして、複製したいイベントを絞り込みます。 diff --git a/tidb-cloud/changefeed-sink-to-mysql.md b/tidb-cloud/changefeed-sink-to-mysql.md index 14698d0775e45..0af9765a97259 100644 --- a/tidb-cloud/changefeed-sink-to-mysql.md +++ b/tidb-cloud/changefeed-sink-to-mysql.md @@ -152,7 +152,7 @@ TiDB Cloud PremiumインスタンスがMySQLサービスに接続できること - **Case Sensitive**：フィルタルールにおけるデータベース名とテーブル名の照合において、大文字小文字を区別するかどうかを設定できます。デフォルトでは、大文字小文字は区別されません。 - **Filter Rules**：この列でフィルタルールを設定できます。デフォルトでは、すべてのテーブルを複製するルール`*.*`が設定されています。新しいルールを追加すると、 TiDB Cloud はTiDB 内のすべてのテーブルをクエリし、右側のボックスにルールに一致するテーブルのみを表示します。フィルタルールは最大 100 個まで追加できます。 - **Tables with valid keys**：この列には、主キーや一意インデックスなど、有効なキーを持つテーブルが表示されます。 - - **Tables without valid keys**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`"!test.tbl1"`を使用して、テーブル`test.tbl1`を除外できます。 + - **Tables without valid keys**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`!test.tbl1`を使用して、テーブル`test.tbl1`を除外できます。 7. **Event Filter**をカスタマイズして、複製したいイベントを絞り込みます。 diff --git a/tidb-cloud/changefeed-sink-to-tidb-cloud.md b/tidb-cloud/changefeed-sink-to-tidb-cloud.md index 412369280cb4a..dc55f465c7856 100644 --- a/tidb-cloud/changefeed-sink-to-tidb-cloud.md +++ b/tidb-cloud/changefeed-sink-to-tidb-cloud.md @@ -81,7 +81,7 @@ summary: このドキュメントでは、TiDB Cloud Dedicatedクラスタから - **Case Sensitive**：フィルタルールにおけるデータベース名とテーブル名の照合において、大文字小文字を区別するかどうかを設定できます。デフォルトでは、大文字小文字は区別されません。 - **Filter Rules**：この列でフィルタルールを設定できます。デフォルトでは、すべてのテーブルを複製するルール`*.*`が設定されています。新しいルールを追加すると、 TiDB Cloud はTiDB 内のすべてのテーブルをクエリし、右側のボックスにルールに一致するテーブルのみを表示します。フィルタルールは最大 100 個まで追加できます。 - **Tables with valid keys**：この列には、主キーや一意インデックスなど、有効なキーを持つテーブルが表示されます。 - - **Tables without valid keys**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`"!test.tbl1"`を使用して、テーブル`test.tbl1`を除外できます。 + - **Tables without valid keys**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`!test.tbl1`を使用して、テーブル`test.tbl1`を除外できます。 6. **Event Filter**をカスタマイズして、複製したいイベントを絞り込みます。 diff --git a/tidb-cloud/configure-external-storage-access.md b/tidb-cloud/configure-external-storage-access.md index fc89bb58c7f15..26beabfcaa930 100644 --- a/tidb-cloud/configure-external-storage-access.md +++ b/tidb-cloud/configure-external-storage-access.md @@ -61,6 +61,14 @@ TiDB Cloud Starter、 Essential、またはPremiumインスタンスがAmazon S3 3. AWS CloudFormationテンプレートを使用してロールARNを作成します。 + + + > **Note:** + > + > {{{ .byoc }}} の場合、IAM ロールを作成した後、データのインポートに Role ARN を使用する前に、ロールに `tidbcloud.com/allow-dataplane-access=true` タグを追加してください。このタグは、TiDB Cloud がそのロールを使用して BYOC データプレーンにアクセスするために必要です。 + + + 1. **Add New ARN**ダイアログで、 **AWS Console with CloudFormation Template**をクリックします。 2. [AWS マネジメントコンソール](https://console.aws.amazon.com)にログインすると、AWS CloudFormation の**Quick create stack**ページにリダイレクトされます。 diff --git a/tidb-cloud/data-pipeline-configure-external-stage-alibaba-cloud.md b/tidb-cloud/data-pipeline-configure-external-stage-alibaba-cloud.md new file mode 100644 index 0000000000000..8f3c865d15341 --- /dev/null +++ b/tidb-cloud/data-pipeline-configure-external-stage-alibaba-cloud.md @@ -0,0 +1,87 @@ +--- +title: TiDB Cloud Data Pipeline 用の外部 stage を設定する (Alibaba Cloud) +summary: RAM ユーザーとアクセスキーを含め、Alibaba Cloud OSS バケットを TiDB Cloud Data Pipeline の外部 stage として設定する方法を説明します。 +--- + +# TiDB Cloud Data Pipeline 用の外部 stage を設定する (Alibaba Cloud) + +このガイドでは、[TiDB Cloud Data Pipeline](/tidb-cloud/data-pipeline.md) の外部 stage として Alibaba Cloud Object Storage Service (OSS) バケットを準備する方法を説明します。外部 stage は、TiDB Cloud がエクスポートしたスナップショットと行変更を書き込み、TiDB Cloud Lake がそこから読み取って対象の Warehouse にデータをロード (load) するための中間バケットです。 + +TiDB Cloud は増分データとスナップショットを OSS バケットに書き込み、TiDB Cloud Lake はそのバケットからデータを読み取ります。 + +> **Restriction:** +> +> - サポートされる認証方式は **Access Key** のみです。OSS では Role ARN は使用できません。 +> - SQS を使用したイベント駆動の取り込みはサポートされていません。パイプラインはポーリングのみを使用します。 + +## 前提条件 {#prerequisites} + +- OSS と RAM リソースを管理する権限を持つ Alibaba Cloud アカウント +- TiDB Cloud Lake の Warehouse を持つ TiDB Cloud アカウント + +## ステップ 1. OSS バケットを作成する {#step-1-create-an-oss-bucket} + +> **Tip:** +> +> すでに使用可能な OSS バケットがある場合は、この手順をスキップしてください。TiDB Cloud インスタンスと同じリージョンを使用することを推奨しますが、OSS では必須ではありません。 + +1. [OSS Console](https://oss.console.aliyun.com/) を開き、新しいバケットを作成します。 +2. リージョンを選択します。TiDB Cloud インスタンスと同じリージョンを使用することを推奨します。 +3. 必要に応じて、バケット内にフォルダー (プレフィックス) を作成し、TiDB Cloud データを整理します (例: `oss://tidb-cloud-lake-data/my-cluster/`)。 +4. 後続の手順で必要になるため、次の値を記録しておきます。 + + - **Bucket Name:** 例: `tidb-cloud-lake-data` + - **OSS URI (with prefix):** 例: `oss://tidb-cloud-lake-data/my-cluster/` + +## ステップ 2. RAM ユーザーと AccessKey ペアを作成する {#step-2-create-a-ram-user-and-accesskey-pair} + +1. [RAM Console](https://ram.console.aliyun.com/) を開き、**Users > Create user** に移動します。 +2. 表示名 (例: `tidb-cloud-lake-user`) を入力し、アクセス方法として **OpenAPI calling** を選択します。 +3. **Next** をクリックし、**AccessKey ID** と **AccessKey Secret** をコピーして保存します。 + + > **Note:** + > + > AccessKey Secret は作成時に一度だけ表示されます。必ずすぐに保存してください。 + +4. **Users** ページに戻り、作成したユーザー名をクリックして **Permissions** タブに移動し、**Add permissions** をクリックします。 +5. **Custom policy** を選択し、**Create policy** をクリックしてから、**Script** タブを選択し、次の JSON からポリシーを作成します。 + + ```json + { + "Version": "1", + "Statement": [ + { + "Effect": "Allow", + "Action": [ + "oss:HeadBucket", + "oss:ListObjects", + "oss:GetObject", + "oss:PutObject", + "oss:DeleteObject", + "oss:GetBucketLocation" + ], + "Resource": [ + "acs:oss:*:*:YOUR_BUCKET_NAME", + "acs:oss:*:*:YOUR_BUCKET_NAME/*" + ] + } + ] + } + ``` + + > **Note:** `YOUR_BUCKET_NAME` を OSS バケット名に置き換えてください。 + +6. ポリシー名 (例: `tidb-cloud-lake-access`) を入力し、**OK** をクリックします。 +7. このポリシーを RAM ユーザーにアタッチします。 +8. TiDB Cloud の設定時に必要になるため、次の値を記録しておきます。 + - **Access Key ID:** 例: `LTAI5t...` + - **Access Key Secret:** 作成時に保存した値 + +## 次のステップ {#what-s-next} + +Alibaba Cloud の設定が完了すると、External Stage の設定に必要な値がすべてそろいます。 + +- **OSS URI**: ステップ 1 で取得 +- **Access Key ID** と **Access Key Secret**: ステップ 2 で取得 + +[TiDB Cloud コンソール](https://tidbcloud.com) で、対象の TiDB Cloud インスタンスの Data Pipeline 設定ページに移動し、**External Stage** 設定にこれらの値を入力して、データパイプラインの設定を完了してください。 diff --git a/tidb-cloud/data-pipeline-configure-external-stage-aws.md b/tidb-cloud/data-pipeline-configure-external-stage-aws.md new file mode 100644 index 0000000000000..a222ce75c4cde --- /dev/null +++ b/tidb-cloud/data-pipeline-configure-external-stage-aws.md @@ -0,0 +1,293 @@ +--- +title: TiDB Cloud Data Pipeline 用の外部 stage を設定する (AWS) +summary: Amazon S3 バケットを TiDB Cloud Data Pipeline の外部 stage として設定する方法について、バケットアクセスや SQS による取り込みを含めて説明します。 +--- + +# TiDB Cloud Data Pipeline 用の外部 stage を設定する (AWS) + +このガイドでは、[TiDB Cloud Data Pipeline](/tidb-cloud/data-pipeline.md) の外部 stage として Amazon S3 バケットを準備する方法を説明します。外部 stage は、TiDB Cloud がエクスポートしたスナップショットと行変更を書き込む中間バケットであり、TiDB Cloud Lake はそこからデータを読み取って対象の Warehouse にロードします。 + +TiDB Cloud はデータをお使いの S3 バケットに書き込み、TiDB Cloud Lake はそこからデータを読み取ります。 + +## 前提条件 {#prerequisites} + +- IAM、S3、および必要に応じて SQS リソースを管理する権限を持つ AWS アカウント +- TiDB Cloud Lake Warehouse を持つ TiDB Cloud アカウント +- TiDB Cloud インスタンスと同じリージョンにある S3 バケット。まだない場合は、[S3 バケットを作成する](#step-1-create-an-s3-bucket) で作成してください。 + +## ステップ 1. S3 バケットを作成する {#step-1-create-an-s3-bucket} + +> **Tip:** +> +> すでに S3 バケットを用意している場合は、この手順をスキップし、バケットのリージョンが TiDB Cloud インスタンスのリージョンと一致していることだけ確認してください。 + +1. [AWS S3 Console](https://console.aws.amazon.com/s3/) を開き、新しいバケットを作成します。 +2. リージョンを選択し、そのリージョンが TiDB Cloud インスタンスのリージョンと一致していることを確認します。 +3. （任意）バケット内にフォルダ（プレフィックス）を作成して、TiDB Cloud データを整理します（例: `s3://tidb-cloud-lake-data/my-cluster/`）。 + +## ステップ 2. バケットアクセスを設定する {#step-2-configure-bucket-access} + +以下のいずれかのバケットアクセス方法を選択し、対応するセクションの手順を完了してください。 + +* **オプション 1: ロール ARN によるバケットアクセス (CloudFormation)**（推奨） +* **オプション 2: ロール ARN によるバケットアクセス (手動設定)** +* **オプション 3: アクセスキーによるバケットアクセス (非推奨)** + +> **Tip:** +> +> **開始前に、イベント駆動の取り込みを有効にするかどうかを決めてください。** +> +> デフォルトでは、TiDB Cloud Lake はデータパイプライン作成後、新しいデータがないか定期的にバケットをスキャンします。より低いデータレイテンシーが必要な場合は、SQS キューを使ったイベント駆動の取り込みを任意で有効にできます。新しいデータがバケットに書き込まれると、S3 イベント通知が SQS キューに送信され、TiDB Cloud Lake は次回の定期スキャンを待たずに新しいデータを検出してロードできます。changefeed は引き続き、設定された間隔に従ってデータをバケットにフラッシュします。イベント駆動の取り込みにより TiDB Cloud Lake がより頻繁にデータをロードする可能性があるため、TiDB Cloud Lake サービスのホスティングコストが増加する場合があります。 +> +> - **オプション 1** では、イベント駆動の取り込みを有効にする場合、スタック作成時に CloudFormation スタックで SQS キューを作成することも、後から手動で SQS キューを追加することもできます。 +> - **オプション 2 と 3** では、イベント駆動の取り込みを有効にする場合、SQS キューを手動で作成して設定する必要があります。 + +### オプション 1. ロール ARN によるバケットアクセス (CloudFormation) {#option-1-bucket-access-with-role-arn-cloudformation} + +1 つの IAM ロールを TiDB Cloud（バケットへの書き込み）と TiDB Cloud Lake（バケットからの読み取り）で共有します。このロールの信頼ポリシーにより、両者はそれぞれ独自の外部 ID で保護された状態でロールを引き受けられるため、長期間有効な認証情報を保存する必要がありません。CloudFormation スタックがロール、その信頼関係、その権限、さらに必要に応じて SQS キューとそのポリシーを一括で作成するため、これが推奨される方法です。 + +#### 1.1 CloudFormation でロールを作成する {#11-create-the-role-with-cloudformation} + +1. TiDB Cloud コンソールで **Create Data Pipeline** ページを開き、**External Stage** エリアに移動して **Bucket URI** を入力します。 +2. **Bucket Access** で **AWS Role ARN** を選択し、フィールドの下にある CloudFormation リンクをクリックしてダイアログを開きます。 +3. **AWS Console with CloudFormation Template** をクリックします。すべてのパラメータが事前入力された状態で、AWS CloudFormation コンソールが新しいブラウザタブで開きます。 +4. 新しいタブで **stack name** を入力し、イベント駆動の取り込みが必要な場合は任意で **SQS queue name** を入力します。CloudFormation はキューとその通知ポリシーを自動的に作成します。不要な場合は SQS フィールドを空のままにしてください。 +5. スタックを作成し、ステータスが `CREATE_COMPLETE` になるまで待ちます。 +6. スタックの **Outputs** タブで、TiDB Cloud コンソールで External Stage を設定する際に必要な以下の値を記録します。 + + - **Role ARN**: `RoleARN` の値 + - **SQS queue URL**（SQS を有効にした場合のみ）: `https://sqs..amazonaws.com//` 形式のキュー URL + +#### 1.2 （任意）S3 バケット通知を設定する {#12-optional-configure-the-s3-bucket-notification} + +[1.1](#11-create-the-role-with-cloudformation) で SQS を有効にした場合、キューとそのポリシーはすでにスタックによって作成されています。残る手順は、既存のバケットに対する通知設定のみです。提供されている CloudFormation スタックは、バケットがすでに存在するためこの設定は行いません。[2.3.2](#232-configure-the-s3-bucket-notification) の手動通知設定手順に従ってください。 + +### オプション 2. ロール ARN によるバケットアクセス (手動設定) {#option-2-bucket-access-with-role-arn-manual-setup} + +CloudFormation を使用できない場合、または組織の要件によりすべての IAM リソースを手動で作成・レビューする必要がある場合は、この方法を使用します。IAM ロール自体はオプション 1 と同じで、異なるのは作成方法だけです。 + +#### 2.1 必要な値を収集する {#21-collect-the-required-values} + +1. TiDB Cloud コンソールで **Create Data Pipeline** ページを開き、**External Stage** エリアに移動して **Bucket URI** を入力します。 +2. **Bucket Access** で **AWS Role ARN** を選択し、フィールドの下にある CloudFormation リンクをクリックしてダイアログを開きます。 +3. ダイアログの **Having trouble?** エリアから以下の値をコピーします。これらはすべて [2.2](#22-create-the-role-and-attach-the-policies) の信頼ポリシーで必要です。 + + - TiDB Cloud account ID + - TiDB Cloud external ID + - Lake external ID + - Lake platform setup & validation role ARN + - Lake platform data loading role ARN + +#### 2.2 ロールを作成し、ポリシーをアタッチする {#22-create-the-role-and-attach-the-policies} + +1. [IAM Console](https://console.aws.amazon.com/iam/) を開き、**Roles > Create role** に移動します。 +2. **Trusted entity type** で **Custom trust policy** を選択し、以下をポリシードキュメントに貼り付けます。プレースホルダーの値は収集した値に置き換えてください。 + + ```json + { + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "AllowTiDBCloudAssumeRole", + "Effect": "Allow", + "Principal": { "AWS": "" }, + "Action": "sts:AssumeRole", + "Condition": { "StringEquals": { "sts:ExternalId": "" } } + }, + { + "Sid": "AllowLakeSetupAssumeRole", + "Effect": "Allow", + "Principal": { "AWS": "" }, + "Action": "sts:AssumeRole", + "Condition": { "StringEquals": { "sts:ExternalId": "" } } + }, + { + "Sid": "AllowLakeLoadAssumeRole", + "Effect": "Allow", + "Principal": { "AWS": "" }, + "Action": "sts:AssumeRole", + "Condition": { "StringEquals": { "sts:ExternalId": "" } } + } + ] + } + ``` + +3. ロール名を入力し（例: `tidb-cloud-lake-role`）、**Create role** をクリックします。 +4. 作成したロールを開き、**Permissions** タブに移動して **Add permissions > Create inline policy** をクリックします。 +5. **JSON** タブを選択し、以下を貼り付けます。`YOUR_BUCKET_NAME` と `your-prefix` は実際の値に置き換え、イベント駆動の取り込みが不要な場合は `SQSConsumeAccess` ステートメントを削除してください。 + + ```json + { + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "S3BucketMetadata", + "Effect": "Allow", + "Action": ["s3:ListBucket", "s3:GetBucketLocation"], + "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME" + }, + { + "Sid": "S3ObjectReadWrite", + "Effect": "Allow", + "Action": ["s3:GetObject", "s3:PutObject"], + "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/your-prefix/*" + }, + { + "Sid": "SQSConsumeAccess", + "Effect": "Allow", + "Action": ["sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes", "sqs:ChangeMessageVisibility"], + "Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:YOUR_QUEUE_NAME" + } + ] + } + ``` + +6. ポリシー名を入力し（例: `tidb-cloud-lake-access`）、**Create policy** をクリックします。 +7. ロール詳細ページから ロール ARN をコピーします。これは TiDB Cloud コンソールで External Stage を設定する際に必要です。例: `arn:aws:iam::123456789012:role/tidb-cloud-lake-role` + +#### 2.3 （任意）SQS でイベント駆動の取り込みを有効にする {#23-optional-enable-event-driven-ingestion-with-sqs} + +ワークロードで定期スキャンを許容できる場合は、このセクションをスキップしてください。SQS を使用するタイミングの詳細については、[ステップ 2. バケットアクセスを設定する](#step-2-configure-bucket-access) の Tip を参照してください。 + +##### 2.3.1 SQS キューを作成し、キューポリシーを設定する {#231-create-the-sqs-queue-and-configure-the-queue-policy} + +1. [SQS Console](https://console.aws.amazon.com/sqs/) を開き、**Create queue** をクリックして **Standard** タイプを選択し、名前を入力します（例: `tidb-cloud-lake-sqs`）。その後、**Create queue** をクリックします。 +2. キューを開き、**Access policy** タブに移動して、ポリシーを以下の内容に置き換えます。これにより、S3 がキューに通知を送信できるようになります。 + + ```json + { + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "AllowS3ToSendMessage", + "Effect": "Allow", + "Principal": { "Service": "s3.amazonaws.com" }, + "Action": "sqs:SendMessage", + "Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:YOUR_QUEUE_NAME", + "Condition": { + "ArnLike": { "aws:SourceArn": "arn:aws:s3:::YOUR_BUCKET_NAME" }, + "StringEquals": { "aws:SourceAccount": "ACCOUNT_ID" } + } + } + ] + } + ``` + + > **Note:** `REGION`、`ACCOUNT_ID`、`YOUR_QUEUE_NAME`、`YOUR_BUCKET_NAME` は実際の値に置き換えてください。 + +3. [2.2](#22-create-the-role-and-attach-the-policies) の `SQSConsumeAccess` ステートメントがロールの権限ポリシーに含まれていることを確認します。 +4. SQS コンソールのキュー詳細ページからキュー URL を記録します。これは TiDB Cloud コンソールで External Stage を設定する際に必要で、形式は `https://sqs..amazonaws.com//` です。 + +##### 2.3.2 S3 バケット通知を設定する {#232-configure-the-s3-bucket-notification} + +S3 イベント通知を設定して、バケットからのオブジェクト作成イベントを SQS キューに送信します。 + +1. [AWS S3 Console](https://console.aws.amazon.com/s3/) を開き、対象のバケットに移動します。 +2. **Properties > Event notifications > Create event notification** に移動します。 +3. 以下を設定します。 + - **Event types:** **All object create events** を選択します。 + - **Destination:** **SQS queue** を選択し、先ほど作成したキューを選びます。 +4. **Save changes** をクリックします。 + +### オプション 3. アクセスキーによるバケットアクセス (非推奨) {#option-3-bucket-access-with-access-key-not-recommended} + +> **Note:** +> +> Access Key/Secret Key (AK/SK) を使用する場合、認証情報を手動で管理およびローテーションする必要があり、誤って漏洩するリスクも高くなります。管理を簡素化し、セキュリティを高めるため、[オプション 1](#option-1-bucket-access-with-role-arn-cloudformation) または [オプション 2](#option-2-bucket-access-with-role-arn-manual-setup) の手順に従って Role ARN を作成することを推奨します。 + +この方法では、IAM ユーザーを作成し、その **Access Key ID** と **Secret Access Key** を TiDB Cloud に提供します。TiDB Cloud はこれらの認証情報を使用して、お使いの S3 バケットに直接アクセスします。 + +#### 3.1 IAM ユーザーとアクセスキーを作成する {#31-create-an-iam-user-and-access-key} + +1. [IAM Console](https://console.aws.amazon.com/iam/) を開き、**Users > Create user** に移動します。 +2. ユーザー名（例: `tidb-cloud-lake-user`）を入力し、**Next** をクリックします。 +3. **Set permissions** ページで、必要な S3 権限と、必要に応じて SQS 権限を付与するポリシーを作成またはアタッチします。`YOUR_BUCKET_NAME` と `your-prefix` は実際の値に置き換えてください。イベント駆動の取り込みが不要な場合は、`SQSConsumerAccess` ステートメントを削除してください。 + + ```json + { + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "S3BucketAccess", + "Effect": "Allow", + "Action": [ + "s3:GetObject", + "s3:PutObject", + "s3:ListBucket", + "s3:GetBucketLocation" + ], + "Resource": [ + "arn:aws:s3:::YOUR_BUCKET_NAME", + "arn:aws:s3:::YOUR_BUCKET_NAME/your-prefix/*" + ] + }, + { + "Sid": "SQSConsumerAccess", + "Effect": "Allow", + "Action": [ + "sqs:ReceiveMessage", + "sqs:DeleteMessage", + "sqs:GetQueueAttributes", + "sqs:ChangeMessageVisibility" + ], + "Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:YOUR_QUEUE_NAME" + } + ] + } + ``` + +4. **Next** をクリックします。**Review and create** ページでユーザー設定を確認し、**Create user** をクリックします。 +5. **Users** ページで、作成したユーザー名をクリックし、**Security credentials** タブに移動します。 +6. **Access keys** セクションで **Create access key** をクリックします。**Access key best practices & alternatives** ページで **Other** を選択し、**Next** をクリックしてアクセスキーを作成します。 +7. **Access Key ID** と **Secret Access Key** を保存します。これらは TiDB Cloud コンソールで External Stage を設定するときに必要です。 + + > **Note:** + > + > Secret Access Key は作成時に一度だけ表示されます。必ずすぐに保存してください。 + +#### 3.2 （任意）SQS でイベント駆動の取り込みを有効にする {#32-optional-enable-event-driven-ingestion-with-sqs} + +ワークロードで定期スキャンを許容できる場合は、このセクションをスキップしてください。 + +1. [SQS Console](https://console.aws.amazon.com/sqs/) を開き、**Create queue** をクリックして、**Standard** タイプを選択し、名前（例: `tidb-cloud-lake-sqs`）を入力します。**Create queue** をクリックします。 +2. キューを開き、**Access policy** タブに移動して、S3 がそのキューに通知を送信できるように、ポリシーを次の内容に置き換えます。プレースホルダーの値は実際の値に置き換えてください。 + + ```json + { + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "AllowS3ToSendMessage", + "Effect": "Allow", + "Principal": { "Service": "s3.amazonaws.com" }, + "Action": "sqs:SendMessage", + "Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:YOUR_QUEUE_NAME", + "Condition": { + "ArnLike": { "aws:SourceArn": "arn:aws:s3:::YOUR_BUCKET_NAME" }, + "StringEquals": { "aws:SourceAccount": "ACCOUNT_ID" } + } + } + ] + } + ``` + +3. バケットで通知を設定します。 + + 1. [AWS S3 Console](https://console.aws.amazon.com/s3/) を開き、対象のバケットに移動します。 + 2. **Properties > Event notifications > Create event notification** に移動します。 + 3. 次のように設定します。 + - **Event types:** **All object create events** を選択します。 + - **Destination:** **SQS queue** を選択し、先ほど作成したキューを選びます。 + 4. **Save changes** をクリックします。 + +4. SQS コンソールのキュー詳細ページでキュー URL を記録します。これは TiDB Cloud コンソールで External Stage を設定するときに必要です。形式は `https://sqs..amazonaws.com//` です。 + +## 次のステップ {#what-s-next} + +AWS の設定が完了すると、External Stage の設定に必要な値がすべてそろいます。 + +- **S3 URI**: **ステップ 1. S3 バケットを作成する** で取得します。 +- **Bucket access**: Role ARN（オプション 1 と 2）、または Access Key ID と Secret Access Key（オプション 3）。 +- **SQS queue URL**（任意）。 + +[TiDB Cloud コンソール](https://tidbcloud.com) で TiDB Cloud インスタンスの Data Pipeline 設定ページに移動し、**External Stage** 設定にこれらの値を入力して、データパイプラインのセットアップを完了してください。 diff --git a/tidb-cloud/data-pipeline-dedicated-sink-to-lake.md b/tidb-cloud/data-pipeline-dedicated-sink-to-lake.md new file mode 100644 index 0000000000000..3d30c4f82807f --- /dev/null +++ b/tidb-cloud/data-pipeline-dedicated-sink-to-lake.md @@ -0,0 +1,155 @@ +--- +title: TiDB Cloud Lake へのシンク +summary: Dumpling と changefeed を使用して、TiDB Cloud Dedicated クラスター上に TiDB Cloud Lake データパイプラインを構築するための手動セットアップガイドです。 +--- + +# TiDB Cloud Lake へのシンク + +このガイドでは、TiDB Cloud Dedicated クラスターから TiDB Cloud Lake へのデータパイプラインをエンドツーエンドで設定する手順を説明します。[Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview) を使用して完全スナップショットを Amazon S3 にエクスポートし、[変更フィード](/tidb-cloud/changefeed-overview.md) を作成して増分変更を同じ S3 ロケーションに継続的に書き込み、TiDB Cloud Lake を設定してスナップショットと増分データの両方をロードします。 + +## 制限事項 {#restrictions} + +- TiDB Cloud Lake の Warehouse は、{{{ .dedicated }}} クラスターと**同じリージョン**に存在する必要があります。 +- 増分レプリケーションできるのは、**主キー**を持つテーブルのみです。 +- クラウドストレージ changefeed を作成するには、{{{ .dedicated }}} クラスターが v7.1.1 以降で動作している必要があります。詳細は、[クラウドストレージへのシンク](/tidb-cloud/changefeed-sink-to-cloud-storage.md) を参照してください。 +- このパイプラインでは、AWS IAM リソースと認証情報、changefeed、TiDB Cloud Lake 統合の手動セットアップと保守が必要です。 +- DDL、DML、およびカラム型のサポートの詳細は、[TiDB Cloud Lake 向け Data Pipeline SQL 互換性](/tidb-cloud/data-pipeline-lake-sql-compatibility.md) を参照してください。 + +## 前提条件 {#prerequisites} + +開始する前に、以下を用意してください。 + +- {{{ .dedicated }}} クラスター。デプロイされているリージョンを確認しておいてください。 +- Dumpling を実行するマシンからクラスターへのネットワーク接続。パブリック接続、VPC ピアリング、またはプライベートエンドポイントを使用できます。このガイドでは例としてパブリック接続を使用します。 +- ソーステーブルを読み取れる SQL ユーザー。このガイドでは例として `root` を使用します。必要な権限については、[必要な権限](https://docs.pingcap.com/tidb/stable/dumpling-overview#required-privileges) を参照してください。 +- {{{ .dedicated }}} クラスターと同じリージョンにある Amazon S3 バケット（例: `s3://my-datapipeline-bucket`）。 +- {{{ .dedicated }}} クラスターと同じリージョンにある TiDB Cloud Lake の Warehouse。 + +> **Note:** +> +> このガイドでは、レプリケートしたいデータがすでにソース TiDB データベースに存在していることを前提としています。サンプルデータが必要な場合は、先に準備してから続行してください。 + +## ステップ 1. S3 バケットへのアクセスを準備する {#step-1-prepare-s3-bucket-access} + +データパイプラインの各コンポーネント（Dumpling、changefeed、TiDB Cloud Lake）は、すべて同じ S3 バケットへのアクセスが必要です。対象の S3 バケットに必要な権限を持つ IAM ユーザーを作成し、そのユーザーのアクセスキーを作成して、3 つのコンポーネントすべてで同じアクセスキーを使用します。 + +1. [IAM Console](https://console.aws.amazon.com/iam/) を開き、IAM ユーザー（例: `tidb-cloud-datapipeline-user`）を作成します。 +2. 次の権限ポリシーをユーザーにアタッチします。`` と `` は実際の値に置き換えてください。 + + ```json + { + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "S3BucketAccess", + "Effect": "Allow", + "Action": [ + "s3:ListBucket", + "s3:GetBucketLocation" + ], + "Resource": "arn:aws:s3:::" + }, + { + "Sid": "S3ObjectAccess", + "Effect": "Allow", + "Action": [ + "s3:GetObject", + "s3:PutObject", + "s3:DeleteObject", + "s3:GetObjectVersion", + "s3:DeleteObjectVersion" + ], + "Resource": "arn:aws:s3::://*" + } + ] + } + ``` + +3. ユーザーのアクセスキーを作成し、**Access Key ID** と **Secret Access Key** を記録します。これらは、スナップショットのエクスポート、changefeed の作成、TiDB Cloud Lake の設定時に必要です。 + +> **Note:** +> +> このガイドでは、S3 バケットへのアクセスにアクセスキーを使用します。changefeed は Role ARN もサポートしています。詳細は、[クラウドストレージへのシンク](/tidb-cloud/changefeed-sink-to-cloud-storage.md#step-1-configure-destination) を参照してください。 + +## ステップ 2. Dumpling で完全スナップショットをエクスポートする {#step-2-export-a-full-snapshot-with-dumpling} + +TiDB Cloud Dedicated では TiDB Cloud コンソールでエクスポート機能が提供されていないため、[Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview) を使用して完全スナップショットをエクスポートします。 + +### 1. ネットワークと SQL ユーザーを準備する {#1-prepare-the-network-and-sql-user} + +1. {{{ .dedicated }}} クラスターに、Dumpling を実行するマシンから到達できることを確認します。このガイドではパブリック接続を使用します。パブリック接続を使用する場合は、そのマシンの IP アドレスをクラスターの IP アクセスリストに追加してください。詳細は、[パブリック接続経由でTiDB Cloud Dedicatedに接続します](/tidb-cloud/connect-via-standard-connection.md) および [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md) を参照してください。 +2. [TiDB Cloud コンソール](https://tidbcloud.com/) で、クラスターの概要ページにある **Connect** をクリックし、接続先のホストとポートを記録します。これらは Dumpling コマンドで必要です。 +3. Dumpling に必要な権限を持つ SQL ユーザーを準備します。このガイドでは例として `root` を使用します。専用ユーザーを使用する場合は、そのユーザーに [Dumpling に必要な権限](https://docs.pingcap.com/tidb/stable/dumpling-overview#required-privileges) を付与してください。 + +### 2. Dumpling でスナップショットをエクスポートする {#2-export-the-snapshot-with-dumpling} + +{{{ .dedicated }}} クラスターに接続できるマシンで Dumpling を実行します。AWS アクセスキーは、`access-key` および `secret-access-key` パラメータを使って `-o` URI に渡します。 + +```shell +tiup dumpling \ + -h "" \ + -P \ + -u "" \ + -p "" \ + --filetype csv \ + --csv-output-dialect snowflake \ + --escape-backslash=false \ + -o "s3:////snapshot/?access-key=&secret-access-key=" \ + --s3.region "" +``` + +パラメータの説明: + +- `--filetype csv` と `--csv-output-dialect snowflake`: データを **Snowflake** 方言の CSV 形式でエクスポートします。 +- `--escape-backslash=false`: バックスラッシュのエスケープを無効にします。 +- 圧縮はデフォルトで無効です。 +- `-o` と `--s3.region`: エクスポートしたファイルを S3 バケットに書き込みます。`-o` URI 内の `access-key` および `secret-access-key` パラメータは、バケット用の認証情報を提供します。 + +> **Note:** +> +> Secret Access Key に `+`、`/`、`=` などの URI 特殊文字が含まれている場合は、先に URL エンコードしてください。あるいは、`AWS_ACCESS_KEY_ID` と `AWS_SECRET_ACCESS_KEY` 環境変数を設定するか、`~/.aws/credentials` ファイルを使用し、`-o` URI から `access-key` と `secret-access-key` パラメータを省略することもできます。 + +エクスポートが正常に完了すると、コマンド出力に JSON サマリーが含まれます。出力内の `SessionParams.tidb_snapshot` フィールドを見つけ、その値を記録してください。この値は **snapshot TSO** です。エクスポートしたスナップショットの続きから増分レプリケーションを開始するため、changefeed の作成時に必要になります。 + +## ステップ 3. 増分データ用の changefeed を作成する {#step-3-create-a-changefeed-for-incremental-data} + +TiDB Cloud コンソールでは、TiDB Cloud Dedicated クラスター用のクラウドストレージ changefeed を作成できます。完全な手順については、[クラウドストレージへのシンク](/tidb-cloud/changefeed-sink-to-cloud-storage.md) を参照してください。changefeed を設定する際は、次の設定に注意してください。 + +- **S3 URI**: スナップショットと同じプレフィックス配下の `incremental/` サブパスを使用します。たとえば `s3:////incremental/` です。 +- **Bucket Access**: **AWS Access Key** を選択し、[ステップ 1. S3 バケットへのアクセスを準備する](#step-1-prepare-s3-bucket-access) のアクセスキーを入力します。権限の対象に `incremental/` パスが含まれていることを確認してください。 +- **Start Replication Position**: **Start replication from a specific TSO** を選択し、[ステップ 2. Dumpling で完全スナップショットをエクスポートする](#step-2-export-a-full-snapshot-with-dumpling) で記録した snapshot TSO を入力します。 +- **Data Format**: **Canal-JSON** を選択し、**Enable TiDB Extension** と **Enable Canal Content Compatibility** の両方を有効にします。これらの設定により、TiDB Cloud Lake 統合と互換性のある形式でデータが生成されます。 + +## ステップ 4. TiDB Cloud Lake を設定する {#step-4-configure-tidb-cloud-lake} + +TiDB Cloud Lake では、S3 バケットからデータをロードするために、データソースと統合を作成する必要があります。 + +### 1. データソースを作成する {#1-create-a-data-source} + +1. [TiDB Cloud Lake console](https://lake.tidbcloud.com/) で、**Data > Data Sources > Create** に移動します。 +2. **Service: TiDB** を選択します。 +3. アクセスキー認証を選択し、以下を入力します。 + - **Access Key ID** と **Secret Access Key**: [ステップ 1. S3 バケットへのアクセスを準備する](#step-1-prepare-s3-bucket-access) の認証情報。 + - **S3 Bucket Name**: バケット名のみ（例: `my-datapipeline-bucket`。完全な URI ではありません）。 + - **S3 Region**: {{{ .dedicated }}} クラスターと同じリージョン。 +4. **SQS Queue URL** は任意です。イベント駆動の取り込みを有効にしたい場合は、SQS キューをセットアップし、S3 バケット通知を設定し、IAM ユーザーに必要な SQS 権限を付与してください。詳細は、[TiDB Cloud Lake 用の Amazon SQS および S3 IAM Role](https://docs.pingcap.com/tidbcloudlake/amazon-sqs-s3-iam-role/) を参照してください。 + +### 2. 統合を作成する {#2-create-an-integration} + +1. [TiDB Cloud Lake console](https://lake.tidbcloud.com/) で、**Data > Integration > Create** に移動します。 +2. 次のフィールドを入力します。 + - **Data Source**: 上で作成したデータソースを選択します。 + - **Name**: この統合タスクの名前。 + - **Sync Mode**: `Snapshot + CDC` を選択して、最初に完全スナップショットをロードし、その後に増分変更を継続的に適用します。 + - **Table Rules**: エクスポートしたすべてのテーブルを同期するには `*.*` を指定します。 + - **Changefeed S3 Prefix**: `/incremental/`。 + - **Dumpling S3 Prefix**: `/snapshot/`。 + - **Poll Interval**: TiDB Cloud Lake が外部 stage をスキャンして新しいデータを検出する間隔です。デフォルト値は 60 秒です。間隔を短くするとデータレイテンシーは減少しますが、TiDB Cloud Lake のホスティングコストは増加します。 + - **Merge Interval**: TiDB Cloud Lake が増分データを Warehouse にマージする間隔です。デフォルト値は 30 秒です。間隔を短くするとデータレイテンシーは減少しますが、TiDB Cloud Lake のホスティングコストは増加します。 + - **Warehouse**: 対象の Warehouse を選択します。 +3. **Create** をクリックします。 +4. 作成後、統合はデフォルトで **Stopped** です。統合のアクションボタン > **Start** をクリックして、データロードを開始します。 + +## 関連情報 {#see-also} + +- DDL、DML、およびカラム型のサポートの詳細は、[TiDB Cloud Lake 向け Data Pipeline SQL 互換性](/tidb-cloud/data-pipeline-lake-sql-compatibility.md) を参照してください。 diff --git a/tidb-cloud/data-pipeline-essential-sink-to-lake.md b/tidb-cloud/data-pipeline-essential-sink-to-lake.md new file mode 100644 index 0000000000000..d0a46d6d7ba90 --- /dev/null +++ b/tidb-cloud/data-pipeline-essential-sink-to-lake.md @@ -0,0 +1,337 @@ +--- +title: TiDB Cloud Lake へのシンク +summary: エクスポート、changefeed、および TiDB Cloud Lake 統合を使用して、TiDB Cloud Essential インスタンス上に TiDB Cloud Lake データパイプラインを構築するための手動セットアップガイドです。 +--- + +# TiDB Cloud Lake へのシンク + +このガイドでは、TiDB Cloud Essential インスタンスから TiDB Cloud Lake へのデータパイプラインをエンドツーエンドで設定する方法を説明します。Amazon S3 に完全スナップショットをエクスポートし、同じ S3 ロケーションに増分変更を継続的に書き込むための [変更フィード](/tidb-cloud/changefeed-overview.md) を作成し、スナップショットデータと増分データの両方をロード (load) するように TiDB Cloud Lake を設定します。 + +## 制限事項 {#restrictions} + +- TiDB Cloud Lake の Warehouse は、Essential インスタンスと **同じリージョン**に存在する必要があります。 +- 増分レプリケーションできるのは、**主キー**を持つテーブルのみです。 +- このパイプラインでは、AWS IAM リソースと認証情報、changefeed、および TiDB Cloud Lake 統合の手動セットアップと保守が必要です。 +- DDL、DML、およびカラム型のサポートの詳細については、[TiDB Cloud Lake 向け Data Pipeline SQL 互換性](/tidb-cloud/data-pipeline-lake-sql-compatibility.md) を参照してください。 + +## 前提条件 {#prerequisites} + +開始する前に、以下を用意してください。 + +- 特定のリージョンにデプロイされた TiDB Cloud Essential インスタンス。 +- この組織の TiDB Cloud API へのアクセス権。API キーは [TiDB Cloud コンソール](https://tidbcloud.com/) の [TiDB Cloud API Keys](https://tidbcloud.com/org-settings/api-keys) ページで作成できます。このガイド内のすべての API 呼び出しで必要になるため、**Public Key** と **Private Key** は必ず保存してください。 +- TiDB Cloud Essential インスタンスと同じリージョンにある Amazon S3 バケット（例: `s3://my-datapipeline-bucket`）。 +- TiDB Cloud Essential インスタンスと同じリージョンにある TiDB Cloud Lake Warehouse。 + +> **Note:** +> +> このガイドでは、レプリケートしたいデータがすでにソース TiDB データベース内に存在していることを前提としています。サンプルデータが必要な場合は、先に準備してから続行してください。 + +## ステップ 1. S3 バケットへのアクセスを準備する {#step-1-prepare-s3-bucket-access} + +データパイプラインのコンポーネント（エクスポート、changefeed、TiDB Cloud Lake）はすべて、同じ S3 バケットへのアクセスを必要とします。S3 バケットにアクセスするには、次のいずれかの方法を選択してください。 + +- **Role ARN**（AWS でホストされている TiDB Cloud Essential インスタンス向け）: 3 つのコンポーネントすべてで共有する単一の IAM ロールです。この方法では長期間有効な認証情報を使わずに済み、セキュリティも高まります。 +- **Access Key**: セットアップがより簡単で、Role ARN を利用できない場合に必要です。ただし、認証情報の手動管理とローテーションが必要になります。 + +### 方法 1: Role ARN を使用する {#method-1-use-a-role-arn} + +この方法では、まず TiDB Cloud コンソールの Export 機能が提供する CloudFormation スタックを使用して、Export 用に設定された IAM ロールを作成します。次に、その同じロールの信頼ポリシーと権限を拡張し、changefeed と TiDB Cloud Lake もそのロールを使用して S3 バケットにアクセスできるようにします。 + +#### 1. Export CloudFormation でロールを作成する {#1-create-the-role-with-export-cloudformation} + +1. [TiDB Cloud コンソール](https://tidbcloud.com/) で、TiDB Cloud Essential インスタンスの概要ページに移動します。 +2. 左側のナビゲーションペインで **Data > Import** をクリックし、右上の **Export Data to** をクリックします。 +3. **Amazon S3** を選択します。**Role ARN** 認証で S3 の宛先を設定すると、TiDB Cloud から CloudFormation リンクが提供されます。これを使用して IAM ロールを作成します。 + +スタックの作成後、スタックの **Outputs** から **Role ARN**（例: `arn:aws:iam:::role/`）を記録してください。 + +#### 2. 信頼関係を統合する {#2-consolidate-trust-relationships} + +前の手順で作成した IAM ロールは、最初は TiDB Cloud Essential から S3 へデータをエクスポートするために設定されています。同じロールは changefeed と TiDB Cloud Lake による S3 バケットアクセスにも使用されるため、これらのコンポーネントもロールを引き受けられるように信頼ポリシーを更新します。 + +追加の信頼関係に必要な以下の値を収集し、その後ロールの信頼ポリシーを更新します。AWS Console で [1. Export CloudFormation でロールを作成する](#1-create-the-role-with-export-cloudformation) で作成したロールに移動し、**Trust relationships** タブを開いて **Edit trust policy** をクリックします。 + +- **Export**: 信頼ポリシーを置き換える前に、既存の Export 用の AWS アカウント ID と外部 ID を記録し、この信頼関係を統合ポリシー内に保持できるようにします。 +- **Changefeed**: 必要な値を取得するために TiDB Cloud API を呼び出します。 + + ```shell + curl -L -X GET 'https://serverless.tidbapi.com/v1beta1/clusters/{clusterId}/changefeeds:getCloudStorageAuthConfig' \ + -u ':' --digest + ``` + + レスポンスから `tidbCloudAccountId` と `tidbCloudAccountExternalId` を記録します。 + +- **TiDB Cloud Lake**: [TiDB Cloud Lake console](https://lake.tidbcloud.com/) で **Data > Data Sources > Create** に移動します。**Basic Info** セクションで **Service: TiDB** を選択し、**Trust Cloud Platform roles** の下に表示される以下の値を記録します。 + - Lake Setup & Validation Role ARN + - Lake Data Loading Role ARN + - Lake External ID + +以下の統合ポリシーでロールの信頼ポリシーを **置き換えて**ください。 + +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "AllowExportAssumeRole", + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws:iam:::root" + }, + "Action": "sts:AssumeRole", + "Condition": { + "StringEquals": { + "sts:ExternalId": "" + } + } + }, + { + "Sid": "AllowChangefeedAssumeRole", + "Effect": "Allow", + "Principal": { + "AWS": "arn:aws:iam:::root" + }, + "Action": "sts:AssumeRole", + "Condition": { + "StringEquals": { + "sts:ExternalId": "" + } + } + }, + { + "Sid": "AllowLakeSetupAssumeRole", + "Effect": "Allow", + "Principal": { + "AWS": "" + }, + "Action": "sts:AssumeRole", + "Condition": { + "StringEquals": { + "sts:ExternalId": "" + } + } + }, + { + "Sid": "AllowLakeLoadAssumeRole", + "Effect": "Allow", + "Principal": { + "AWS": "" + }, + "Action": "sts:AssumeRole", + "Condition": { + "StringEquals": { + "sts:ExternalId": "" + } + } + } + ] +} +``` + +#### 3. パイプライン全体のプレフィックスを対象とするように権限を拡張する {#3-expand-permissions-to-cover-the-full-pipeline-prefix} + +CloudFormation で作成された権限ポリシーは、スナップショットのエクスポート先パスのみを対象としています。changefeed は `{prefix}/incremental/` に書き込み、TiDB Cloud Lake は `{prefix}/snapshot/` と `{prefix}/incremental/` の両方から読み取るため、ポリシーの対象に親プレフィックスを含める必要があります。 + +AWS Console でステップ 1 で作成したロールに移動し、**Permissions** タブでポリシー名をクリックして、リソーススコープを置き換えるようにポリシーを編集します。 + +以下の内容でロールのインライン権限ポリシーを **置き換えて**ください。 + +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "S3BucketAccess", + "Effect": "Allow", + "Action": [ + "s3:ListBucket", + "s3:GetBucketLocation" + ], + "Resource": "arn:aws:s3:::" + }, + { + "Sid": "S3ObjectAccess", + "Effect": "Allow", + "Action": [ + "s3:GetObject", + "s3:PutObject", + "s3:DeleteObject", + "s3:GetObjectVersion", + "s3:DeleteObjectVersion" + ], + "Resource": "arn:aws:s3::://*" + } + ] +} +``` + +> **Note:** +> +> CloudFormation で作成されたポリシーでは、`arn:aws:s3:::bucket/prefix/snapshot/*` のような、より限定的なリソースが使用されます。changefeed（`prefix/incremental/` に書き込む）と TiDB Cloud Lake（両方のサブパスから読み取る）の両方が十分なアクセス権を持てるように、これを `arn:aws:s3:::bucket/prefix/*` に変更する必要があります。 + +### 方法 2: Access Key を使用する {#method-2-use-an-access-key} + +> **Note:** +> +> Access Key と Secret Key (AK/SK) を使用する場合、認証情報の管理とローテーションを手動で行う必要があり、セキュリティリスクが高まります。より強固なセキュリティのため、代わりに **Role ARN** を使用してください。 + +Access Key 認証を使用する場合は、以下の権限を持つ IAM ユーザーを作成し、Export、changefeed、TiDB Cloud Lake の設定時にその認証情報を指定してください。 + +**権限ポリシー:** + +```json +{ + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "S3BucketAccess", + "Effect": "Allow", + "Action": [ + "s3:ListBucket", + "s3:GetBucketLocation" + ], + "Resource": "arn:aws:s3:::" + }, + { + "Sid": "S3ObjectAccess", + "Effect": "Allow", + "Action": [ + "s3:GetObject", + "s3:PutObject", + "s3:DeleteObject", + "s3:GetObjectVersion", + "s3:DeleteObjectVersion" + ], + "Resource": "arn:aws:s3::://*" + } + ] +} +``` + +後続の手順で使用するため、**Access Key ID** と **Secret Access Key** を記録しておいてください。 + +## ステップ 2. Amazon S3 に完全スナップショットをエクスポートする {#step-2-export-full-snapshot-to-amazon-s3} + +TiDB Cloud コンソールで **Data > Import** に移動し、右上の **Export Data to** をクリックして **Amazon S3** を選択し、新しいエクスポートタスクを作成します。 + +**設定:** + +- **Selected Data**: エクスポートするデータベースとテーブルを選択します。 +- **Data Format**: `CSV` + - **Edit CSV Configuration** をクリックし、以下を設定します。 + - **Dialect**: `Snowflake` + - **Escape backslash**: `false` +- **Compression**: `None` +- **Amazon S3 Settings**: + - **Bucket URI**: `s3:////snapshot/`（推奨される snapshot サブパスを使用） + - **Role ARN** または **Access Key**: [ステップ 1. S3 バケットへのアクセスを準備する](#step-1-prepare-s3-bucket-access) の認証情報を使用します。 + +エクスポートタスクの完了後、タスク詳細を開いて **Snapshot TSO** の値を記録してください。この TSO は changefeed の作成時に必要です。 + +## ステップ 3. 増分データ用の changefeed を作成する {#step-3-create-a-changefeed-for-incremental-data} + +現在、TiDB Cloud Essential では TiDB Cloud コンソールからクラウドストレージシンクを作成できないため、TiDB Cloud API を使用する必要があります。 + +以下の必須フィールドを指定して changefeed 作成 API を呼び出します。 + +| フィールド | 必須の値 | +|-------|---------------| +| `sink.cloudStorage.dataFormat.protocol` | `CANAL_JSON` | +| `sink.cloudStorage.dataFormat.canalJsonConfig.enableTidbExtension` | `true` | +| `sink.cloudStorage.dataFormat.contentCompatible` | `true` | +| `startPosition.mode` | `FROM_TSO` | +| `startPosition.tso` | `` | + +**リクエスト例:** + +```shell +curl -L -X POST 'https://serverless.tidbapi.com/v1beta1/clusters/{clusterId}/changefeeds' \ + -H 'Content-Type: application/json' \ + -u ':' --digest \ + -d '{ + "displayName": "", + "sink": { + "type": "CLOUD_STORAGE", + "cloudStorage": { + "storage": { + "type": "S3", + "s3": { + "uri": "s3:////incremental/", + "authType": "ROLE_ARN", + "roleArn": "" + } + }, + "dataFormat": { + "protocol": "CANAL_JSON", + "contentCompatible": true, + "canalJsonConfig": { + "enableTidbExtension": true + } + } + } + }, + "filter": { + "mode": "IGNORE_NOT_SUPPORT_TABLE", + "filterRule": ["*.*"] + }, + "startPosition": { + "mode": "FROM_TSO", + "tso": "" + }, + "rcu": 2 + }' +``` + +> **Note:** +> +> changefeed の URI では、エクスポートスナップショットと同じプレフィックス配下の `incremental/` サブパスを使用する必要があります。IAM ロールの権限（[3. パイプライン全体のプレフィックスを対象とするように権限を拡張する](#3-expand-permissions-to-cover-the-full-pipeline-prefix) を参照）は、このパスを対象に含めている必要があります。 +> +> **Access Key** を Role ARN の代わりに使用する場合は、リクエストボディ内の `s3` ブロックを次の内容に置き換えてください。 +> +> ```json +> "s3": { +> "uri": "s3:////incremental/", +> "authType": "ACCESS_KEY", +> "accessKey": { +> "id": "", +> "secret": "" +> } +> } +> ``` +> + +## ステップ 4. TiDB Cloud Lake を設定する {#step-4-configure-tidb-cloud-lake} + +TiDB Cloud Lake では、S3 バケットからデータをロード (load) するために、データソースと統合を作成する必要があります。 + +### 1. データソースを作成する {#1-create-a-data-source} + +1. [TiDB Cloud Lake console](https://lake.tidbcloud.com/) で **Data > Data Sources > Create** に移動します。 +2. **Service: TiDB** を選択します。 +3. **Role ARN** または **Access Key** 認証を選択し、以下を入力します。 + - **Role ARN**: [1. Export CloudFormation でロールを作成する](#1-create-the-role-with-export-cloudformation) の ARN、または [方法 2: Access Key を使用する](#method-2-use-an-access-key) の **Access Key ID** / **Secret Access Key**。 + - **S3 Bucket Name**: バケット名のみ（例: `my-datapipeline-bucket`。完全な URI ではありません）。 + - **S3 Region**: Essential インスタンスと同じリージョン。 +4. **SQS Queue URL** は任意です。イベント駆動の取り込みを有効にする場合は、先に SQS キューをセットアップし、S3 バケット通知を設定してください。詳細は [TiDB Cloud Lake 用の Amazon SQS および S3 IAM Role](https://docs.pingcap.com/tidbcloudlake/amazon-sqs-s3-iam-role/) を参照してください。 +5. **Trust Cloud Platform roles** で、TiDB Cloud Lake のプラットフォームロールと外部 ID が、[2. 信頼関係を統合する](#2-consolidate-trust-relationships) の統合済み信頼ポリシーに追加した値と一致していることを確認します。 + +### 2. 統合を作成する {#2-create-an-integration} + +1. [TiDB Cloud Lake console](https://lake.tidbcloud.com/) で **Data > Integration > Create** に移動します。 +2. 以下のフィールドを入力します。 + - **Data Source**: 上で作成したデータソースを選択します。 + - **Name**: この統合タスクの名前。 + - **Sync Mode**: `Snapshot + CDC` を選択して、最初に完全スナップショットをロードし、その後増分変更を継続的に適用します。 + - **Table Rules**: エクスポートしたすべてのテーブルを同期するには `*.*` を指定します。 + - **Changefeed S3 Prefix**: `/incremental/`。 + - **Dumpling S3 Prefix**: `/snapshot/`。 + - **Poll Interval**: TiDB Cloud Lake が外部 stage をスキャンして新しいデータを検出する間隔です。デフォルト値は 60 秒です。間隔を短くするとデータレイテンシーは減少しますが、TiDB Cloud Lake のホスティングコストは増加します。 + - **Merge Interval**: TiDB Cloud Lake が増分データを Warehouse にマージする間隔です。デフォルト値は 30 秒です。間隔を短くするとデータレイテンシーは減少しますが、TiDB Cloud Lake のホスティングコストは増加します。 + - **Warehouse**: 対象の Warehouse を選択します。 +3. **Create** をクリックします。 +4. 作成後、統合はデフォルトで **Stopped** です。統合のアクションボタンをクリックし、**Start** を選択してデータロードを開始します。 + +## 関連情報 {#see-also} + +- DDL、DML、およびカラム型のサポートの詳細については、[TiDB Cloud Lake 向け Data Pipeline SQL 互換性](/tidb-cloud/data-pipeline-lake-sql-compatibility.md) を参照してください。 diff --git a/tidb-cloud/data-pipeline-lake-faq.md b/tidb-cloud/data-pipeline-lake-faq.md new file mode 100644 index 0000000000000..f103ce675bcfd --- /dev/null +++ b/tidb-cloud/data-pipeline-lake-faq.md @@ -0,0 +1,34 @@ +--- +title: Data Pipeline FAQ +summary: 外部 stage、イベント駆動の取り込み、課金など、TiDB Cloud Data Pipeline から TiDB Cloud Lake への連携に関するよくある質問です。 +--- + +# Data Pipeline FAQ + +このドキュメントでは、TiDB Cloud Data Pipeline から TiDB Cloud Lake への連携に関する一般的な質問に回答します。 + +## データパイプラインで外部 stage が必要なのはなぜですか？ {#why-does-a-data-pipeline-require-an-external-stage} + +信頼性を確保するために、外部 stage が必要です。データを直接転送するのではなく、両側が stage を介して動作することで、TiDB Cloud 側の書き込みレートは TiDB Cloud Lake の消費レートから切り離されます。 + +- 書き込みスループットが高い場合でも、変更データは stage に永続的に保存され、TiDB Cloud Lake へのロードが遅延または中断した場合でも、TiDB Cloud Lake がロードできる状態で保持されます。 +- stage は書き込み負荷をバッファリングし、データ生成レートと取り込みレートの一時的な差異が TiDB Cloud Lake の取り込みに直接影響するのを防ぎます。 +- TiDB Cloud Lake 側の取り込み頻度は書き込みレートから切り離されるため、TiDB Cloud Lake 側のコストを制御する手段が得られます。 + +## SQS キューを使用したイベント駆動の取り込みを有効にする必要がありますか？ {#do-i-need-to-enable-event-driven-ingestion-with-an-sqs-queue} + +デフォルトのポーリングモードよりも**低いデータレイテンシー**が必要な場合は、イベント駆動の取り込みを有効にしてください。 + +デフォルトモードでは、Data Pipeline は、changefeed が増分データを外部 stage にフラッシュする間隔と、TiDB Cloud Lake が新しいデータを検出するために stage をスキャンする間隔に依存します。{{{ .premium }}} および {{{ .byoc }}} では、設定された **Sync Interval** が、これらの段階全体におけるエンドツーエンドのレイテンシー目標になります。 + +イベント駆動モードでは、changefeed は設定された間隔で引き続きデータを外部 stage にフラッシュしますが、各フラッシュは同時に SQS キューへの **S3 イベント通知** もトリガーします。SQS 通知により、TiDB Cloud Lake は次回の定期スキャンを待つことなく、新しいデータをより早く検出できます。 + +**トレードオフ:** イベント駆動モードでは、TiDB Cloud Lake は新しいデータをより高頻度で取り込めるため、warehouse が **active** 状態のままより長く維持される可能性があります。これにより、warehouse のホスティングコストが増加します。 + +## データパイプラインでは TiDB Cloud Lake に追加料金が発生しますか？ {#does-a-data-pipeline-incur-additional-tidb-cloud-lake-charges} + +データパイプラインによって、別個の課金カテゴリが追加されることはありません。コストは、パイプラインに関与する既存のコンポーネントから発生します。 + +- **Export**（1 回限り）: 完全なスナップショットのエクスポートに対して課金されます。 +- **Changefeed**（継続）: 増分レプリケーションが有効な場合、継続的なレプリケーションに使用される changefeed リソースに対して課金されます。 +- **TiDB Cloud Lake**（継続）: データストレージと Warehouse コンピュートに対して課金されます。詳細は、[TiDB Cloud Lake Pricing & Billing](https://docs.pingcap.com/tidbcloudlake/pricing-billing/) を参照してください。 diff --git a/tidb-cloud/data-pipeline-lake-sql-compatibility.md b/tidb-cloud/data-pipeline-lake-sql-compatibility.md new file mode 100644 index 0000000000000..6798128b0fecc --- /dev/null +++ b/tidb-cloud/data-pipeline-lake-sql-compatibility.md @@ -0,0 +1,110 @@ +--- +title: TiDB Cloud Lake 向け Data Pipeline SQL 互換性 +summary: TiDB Cloud Data Pipeline における DDL、DML、および TiDB から TiDB Cloud Lake への型マッピング動作のリファレンスです。 +--- + +# TiDB Cloud Lake 向け Data Pipeline SQL 互換性 + +このドキュメントでは、TiDB Cloud Data Pipeline が TiDB Cloud Lake にデータをレプリケートする際の DDL、DML、およびカラム型のサポートについて説明します。パイプラインの計画、スキーマ互換性の検証、または型変換のトラブルシューティングに利用してください。 + +> **Note:** +> +> サポートされる動作は、使用している TiCDC と TiDB Cloud Lake のバージョンによって異なります。異なる動作が見られる場合は、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。 + +## DDL サポートの概要 {#ddl-support-summary} + +| DDL 操作 | ステータス | 注記 | +| -------------------- | -----: | ----- | +| `CREATE TABLE` | ✅ | | +| `ADD COLUMN` | ✅ | | +| `ADD COLUMN ... NOT NULL DEFAULT ...` | ✅ | | +| `DROP COLUMN` | ✅ | | +| `RENAME COLUMN` | ✅ | | +| `MODIFY COLUMN` | ⚠️ 部分サポート | 以下に示す Schema Evolution のケースのみサポートされます。その他の変換は保証されず、下流での取り込みをブロックする可能性があります。 | + +### サポートされる `MODIFY COLUMN` 変換 {#supported-modify-column-conversions} + +| 変換元 | 変換先 | 注記 | +| ---- | -- | ----- | +| `VARCHAR` | `TEXT` | Schema Evolution 中によくある拡張変換です。 | +| `TINYINT` | `INT` | 整数の格納幅を拡張します。 | +| `INT` | `BIGINT` | Schema Evolution 中によくある拡張変換です。 | +| `INT` | `VARCHAR` / `TEXT` | ターゲット型が文字列表現に変換される場合に使用されます。 | + +ここに記載されていない DDL 操作はパイプラインで処理されず、影響を受けるテーブルの後続の取り込みをブロックする可能性があります。また、単一の `ALTER TABLE` 文で複数の変更を組み合わせることはサポートされていません。 + +## DML サポートの概要 {#dml-support-summary} + +| DML 操作 | ステータス | +| ------------ | -----: | +| `INSERT` | ✅ | +| `UPDATE` | ✅ | +| `DELETE` | ✅ | + +ここに記載されていない DML 操作は宛先に伝播されません。 + +## 型マッピングリファレンス {#type-mapping-reference} + +### 整数型 {#integer-types} + +| TiDB 型 | TiDB Cloud Lake 型 | +| --------- | -------------------- | +| `TINYINT` | `INT8` | +| `TINYINT UNSIGNED` | `UINT8` | +| `SMALLINT` | `INT16` | +| `SMALLINT UNSIGNED` | `UINT16` | +| `MEDIUMINT` | `INT32` | +| `INT` / `INTEGER` | `INT32` | +| `MEDIUMINT UNSIGNED` / `INT UNSIGNED` / `INTEGER UNSIGNED` | `UINT32` | +| `BIGINT` | `INT64` | +| `BIGINT UNSIGNED` | `UINT64` | + +### 浮動小数点型 {#floating-point-types} + +| TiDB 型 | TiDB Cloud Lake 型 | +| --------- | -------------------- | +| `FLOAT` | `FLOAT32` | +| `DOUBLE` / `REAL` | `FLOAT64` | + +### 固定小数点型 {#exact-numeric-types} + +| TiDB 型 | TiDB Cloud Lake 型 | 注記 | +| --------- | -------------------- | ----- | +| `DECIMAL(P,S)` | `DECIMAL(P,S)` | 精度とスケールはそのまま正確に保持されます。これは `NUMERIC(P,S)` にも同様に適用されます。 | +| `DECIMAL` (精度指定なし) | `DECIMAL(76,30)` | 暗黙の切り捨てを避けるため、有効な最大精度まで自動的に拡張されます。 | +| `NUMERIC` (精度指定なし) | `DECIMAL(76,30)` | 上記と同じです。 | + +### 日付と時刻の型 {#date-and-time-types} + +| TiDB 型 | TiDB Cloud Lake 型 | 注記 | +| --------- | -------------------- | ----- | +| `DATE` | `DATE` | | +| `DATETIME` / `DATETIME(n)` | `TIMESTAMP` | 秒未満の精度がサポートされます。 | +| `TIMESTAMP` / `TIMESTAMP(n)` | `TIMESTAMP` | 秒未満の精度がサポートされます。 | +| `TIME` | `VARCHAR` | TiDB Cloud Lake には独立した `TIME` 型がないため、テキストとして保存されます。 | +| `YEAR` | `INT16` | 日付/時刻型ではなく整数としてマッピングされます。 | + +### 文字列型 {#string-types} + +| TiDB 型 | TiDB Cloud Lake 型 | 注記 | +| --------- | -------------------- | ----- | +| `CHAR` / `VARCHAR` | `VARCHAR` | 長さは保持されません。 | +| `TINYTEXT` / `TEXT` / `MEDIUMTEXT` / `LONGTEXT` | `VARCHAR` | | +| `ENUM` | `VARCHAR` | enum のテキストを保持するには、`content-compatible=true` の changefeed が必要です。 | +| `SET` | `VARCHAR` | 要素のテキストを保持するには、`content-compatible=true` の changefeed が必要です。 | + +### バイナリ型 {#binary-types} + +| TiDB 型 | TiDB Cloud Lake 型 | +| --------- | -------------------- | +| `BINARY` / `VARBINARY` | `BINARY` | +| `TINYBLOB` / `BLOB` / `MEDIUMBLOB` / `LONGBLOB` | `BINARY` | + +### その他の型 {#other-types} + +| TiDB 型 | TiDB Cloud Lake 型 | 注記 | +| --------- | -------------------- | ----- | +| `BOOLEAN` / `BOOL` | `BOOLEAN` | | +| `BIT` | `UINT64` | 常に符号なしとしてマッピングされます。すべて 1 の `BIT(64)` は、符号付き `INT64` の範囲を超えます。 | +| `JSON` | `VARIANT` | | +| 不明な型 / 記載のない型 | `VARCHAR` | フォールバックマッピングです。型としてのセマンティクスは失われます。 | diff --git a/tidb-cloud/data-pipeline-sink-to-lake.md b/tidb-cloud/data-pipeline-sink-to-lake.md new file mode 100644 index 0000000000000..9092e64094635 --- /dev/null +++ b/tidb-cloud/data-pipeline-sink-to-lake.md @@ -0,0 +1,178 @@ +--- +title: TiDB Cloud Lake へのシンク +summary: TiDB Cloud インスタンスから TiDB Cloud Lake にデータをレプリケートするデータパイプラインを作成、監視、管理する方法を学びます。 +--- + +# TiDB Cloud Lake へのシンク + +TiDB Cloud では、サードパーティの ETL ツールを使わずに、Data Pipeline を使用して {{{ .premium }}}{{{ .byoc }}} インスタンスから TiDB Cloud Lake に完全データと増分変更をレプリケートできます。まず、選択したソースデータの完全スナップショットをエクスポートし、その後は行の変更を継続的にレプリケートできるため、TiDB Cloud Lake 内のデータを最新の状態に保てます。 + +> **Note:** +> +> - TiDB Cloud Lake への Data Pipeline は現在、{{{ .premium }}}{{{ .byoc }}} 向けに**プライベートプレビュー**として提供されており、リクエストに応じてのみ利用できます。この機能をリクエストするには、[TiDB Cloud コンソール](https://tidbcloud.com)の右下にある **?** をクリックし、**Support Tickets** をクリックして [ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals) に移動します。チケットを作成し、**Description** フィールドに "Apply for `Data Pipeline to TiDB Cloud Lake`" と入力して、**Submit** をクリックします。 +> - Data Pipeline 機能は TiCDC をベースに構築されているため、[TiCDC と同じ制限](https://docs.pingcap.com/tidb/stable/ticdc-overview#unsupported-scenarios)があります。 + +## 制限事項 {#restrictions} + +- TiDB Cloud Lake の Warehouse は、TiDB Cloud インスタンスと**同じリージョン**に存在する必要があります。 +- 増分レプリケーションを行えるのは、**主キー**を持つテーブルのみです。主キーのないテーブルは、パイプライン作成時の **Filter results** パネルに表示されます。同期対象に含めた場合でも、それらの増分レプリケーションはスキップされます。 +- {{{ .premium }}}{{{ .byoc }}} インスタンスごとに、最大 100 個の changefeed を作成できます。増分レプリケーションを含む各データパイプラインは、1 つの changefeed スロットを消費します。 +- データパイプラインを削除しても、TiDB Cloud Lake にすでに書き込まれたデータや、Warehouse 内のターゲットデータベースおよびテーブルは**削除されません**。 + +## 前提条件 {#prerequisites} + +開始する前に、以下を用意してください。 + +- {{{ .premium }}}{{{ .byoc }}} インスタンス。デプロイされているリージョンを確認しておいてください。 +- インスタンスと同じリージョンにある TiDB Cloud Lake の Warehouse。まだない場合は、まず [TiDB Cloud Lake コンソール](https://lake.tidbcloud.com/) で作成してください。データパイプライン作成時に選択できるのは、インスタンスと同じリージョンの Warehouse のみです。 +- 外部 stage バケット: Amazon S3 バケットまたは Alibaba Cloud OSS バケット。インスタンスと同じリージョンに作成してください。 +- ソーステーブルを読み取れる TiDB データベースユーザーのユーザー名とパスワード。 + +## データパイプラインを作成する {#create-a-data-pipeline} + +データパイプラインを作成するには、送信先、外部 stage、およびレプリケーションを設定する必要があります。 + +### ステップ 1. 送信先を設定する {#step-1-configure-the-destination} + +1. [TiDB Cloud コンソール](https://tidbcloud.com/) で、対象の {{{ .premium }}}{{{ .byoc }}} インスタンスの概要ページに移動し、左側のナビゲーションペインで **Data** > **Data Pipeline** をクリックして、右上の **Create Data Pipeline** をクリックします。 +2. **Destination** エリアで、以下のフィールドを設定します。 + + - **Destination**: **TiDB Cloud Lake** を選択します。 + - **Warehouse**: ターゲットの Warehouse を選択します。表示されるのは、インスタンスと同じリージョンにある Warehouse のみです。利用可能な Warehouse がない場合は、まず [TiDB Cloud Lake](https://lake.tidbcloud.com/) で作成し、その後リストを更新してください。 + +3. （任意）**Database Prefix**、**Database Suffix**、**Table Prefix**、**Table Suffix** フィールドでターゲットの命名規則を設定します。デフォルトでは 4 つのフィールドはすべて空であり、この場合 TiDB Cloud Lake に作成されるデータベース名とテーブル名はソースと同じ名前になります。 + + - データベース名: `` + - テーブル名: `
    ` + +### ステップ 2. 外部 stage を設定する {#step-2-configure-the-external-stage} + +外部 stage は、データパイプラインの両側をつなぐオブジェクトストレージです。TiDB Cloud はエクスポートしたスナップショットとキャプチャした行変更を stage に書き込み、TiDB Cloud Lake は stage からデータをロード (load) してターゲット Warehouse に取り込みます。詳細は、[データパイプラインで外部 stage が必要なのはなぜですか？](/tidb-cloud/data-pipeline-lake-faq.md#why-does-a-data-pipeline-require-an-external-stage) を参照してください。 + +TiDB Cloud Data Pipeline は、外部 stage として Amazon S3 および Alibaba Cloud OSS をサポートしています。バケットは {{{ .premium }}}{{{ .byoc }}} インスタンスと同じリージョンに作成し、先にクラウドプロバイダー側の設定を完了してください。設定手順はクラウドプロバイダーによって異なります。 + + +
    + +1. **External Stage** エリアで、S3 バケットの **Bucket URI** を `s3:////` 形式で入力します。 + + それ以外のフィールドは、いったん空のままにしてください。後続のセクションで説明するいずれかの方法でバケットアクセスを設定した後に入力します。 + +2. TiDB Cloud が外部 stage にデータを書き込み、TiDB Cloud Lake がそこからデータを読み取れるようにするには、**Bucket Access** エリアでバケットアクセスを設定します。以下のいずれかの方法を選択し、それに応じて認可を完了してください。 + + - 方法 1: AWS Role ARN を使用する（推奨） + + 1 つの IAM ロールを TiDB Cloud（stage への書き込み）と TiDB Cloud Lake（stage からの読み取り）で共有するため、認可設定は 1 回で済み、長期有効なアクセスキーを保存する必要もありません。TiDB Cloud が提供する CloudFormation テンプレートを使ってロールを作成することも、AWS で手動設定することもできます。 + + AWS 側の完全な設定については、[TiDB Cloud Data Pipeline 用の外部 stage を設定する (AWS)](/tidb-cloud/data-pipeline-configure-external-stage-aws.md) を参照してください。ロールを作成したら、TiDB Cloud コンソールで `RoleARN` の出力値を **Role ARN** フィールドに貼り付け、SQS キューも作成した場合は、そのキュー URL を **SQS Queue URL** フィールドに貼り付けます。 + + - 方法 2: AWS アクセスキーを使用する + + > **Note:** + > + > アクセスキーとシークレットキー（AK/SK）を使用する場合、認証情報の管理とローテーションを手動で行う必要があり、セキュリティリスクが高まります。より強固なセキュリティのため、代わりに **AWS Role ARN** を使用してください。 + + IAM ユーザー、その権限、および任意の SQS キューを含む AWS 側の完全な設定については、[アクセスキーによるバケットアクセス](/tidb-cloud/data-pipeline-configure-external-stage-aws.md#option-3-bucket-access-with-access-key-not-recommended) を参照してください。その後、TiDB Cloud コンソールで **AWS Access Key** を選択し、**Access Key ID** と **Secret Access Key** を入力します。 + + 選択した方法に必要な情報を入力したら、**Test Connection** をクリックして TiDB Cloud がバケットにアクセスできることを確認します。チェックに失敗した場合は、バケットのリージョンと、ロールまたはアクセスキーに付与した権限を確認してから、再度接続をテストしてください。 + +
    + +
    + +RAM ユーザー、その権限、およびアクセスキーを含む OSS 側の完全な設定については、[TiDB Cloud Data Pipeline 用の外部 stage を設定する (Alibaba Cloud)](/tidb-cloud/data-pipeline-configure-external-stage-alibaba-cloud.md) を参照してください。 + +1. **External Stage** エリアで、OSS バケットの **Bucket URI** を `oss:////` 形式で入力します。 +2. 以下のフィールドを入力します。 + + - **Access Key ID**: RAM ユーザーの AccessKey ID。 + - **Access Key Secret**: RAM ユーザーの AccessKey Secret。 + +3. **Test Connection** をクリックして、TiDB Cloud がバケットにアクセスできることを確認します。チェックに失敗した場合は、バケットのリージョンと、RAM ユーザーに付与した権限を確認してから、再度接続をテストしてください。 + +> **Note:** +> +> Alibaba Cloud OSS では、アクセスキー認証のみがサポートされており、SQS を使用したイベント駆動の取り込みは利用できません。 + +
    + +     + +### ステップ 3. レプリケーションを設定する {#step-3-configure-replication} + +**Replication Data** エリアで、データのレプリケーション方法を設定します。 + +1. **Sync Mode**: 同期モードを選択します。 + + - **Full Data + Incremental Data**（デフォルト）: 選択したソースデータの完全スナップショットをエクスポートし、その後、行変更を継続的にレプリケートします。継続的な同期にはこのモードを推奨します。 + - **Full Data**: 選択したソースデータの完全スナップショットを 1 回だけエクスポートします。増分データはレプリケートされず、スナップショット取得後にソースで行われた変更は無視されます。 + +2. **Sync Interval**: データパイプラインのエンドツーエンドのレイテンシー目標です。changefeed のフラッシュサイクルと TiDB Cloud Lake のポーリングサイクルの両方が、エンドツーエンドのレイテンシーに影響します。間隔を短くするとデータレイテンシーは減少しますが、クラウドストレージへの API 呼び出し回数は増加します。デフォルト値はコンソールに表示されます。 + +3. **Changefeed Capacity Units**: 増分レプリケーションに割り当てる処理能力で、サポートされる最大レプリケーションスループットとともに表示されます。たとえば、`2 CCUs (the maximum replication throughput is 5,000 rows/s)` のように表示されます。 + + > **Note:** + > + > Changefeed Capacity Units は、データストリーミングに割り当てられる処理能力を表します。この設定によって増分レプリケーションの性能が決まります。同期モードとして **Full Data** を選択した場合、増分レプリケーションは実行されないため、CCU は消費されません。 + +4. **TiDB Username** と **TiDB Password**: TiDB データベースユーザーのユーザー名とパスワードを入力します。データパイプラインはこのアカウントを使用して完全スナップショットをエクスポートするため、このアカウントにはソーステーブルへの読み取り権限が必要です。増分の行変更は、changefeed によって別途キャプチャされます。 + +5. **Sync Objects**: レプリケートするオブジェクトを選択します。 + + - **Customize**（デフォルト）: **Table Filter Rules** で明示的なルールを指定します。ルール構文は [TiCDC のテーブルフィルタールール](https://docs.pingcap.com/tidb/stable/ticdc-filter#table-filter) と同じです。デフォルトでは、1 つの `*.*` ルールですべての非システムテーブルをレプリケートします。**Filter results** パネルには、ルールに一致するデータベースとテーブルが表示されます。 + - **All**: すべてのデータベースのすべてのテーブルをレプリケートします。テーブルフィルタールールの設定は非表示になります。 + + 必要に応じて **Case-sensitive** を選択すると、フィルタールール内のデータベース名とテーブル名の一致判定で大文字と小文字を区別します。デフォルトでは、大文字と小文字は区別されません。 + + > **Note:** + > + > 増分レプリケーションを行えるのは、主キーを持つテーブルのみです。主キーのないテーブルは **Filter results** パネルに別途表示され、増分レプリケーションではスキップされます。データパイプラインを作成する前にこれらのテーブルへ主キーを追加するか、`"!test.tbl1"` のようなフィルタールールで除外してください。 + +6. **Pipeline Name**: データパイプラインの名前を入力します。 + +7. **Create** をクリックします。 + + 完全スナップショットのエクスポート中、パイプラインは **Creating** 状態になります。**Full Data + Incremental Data** の場合、増分レプリケーションが開始されるとステータスは **Running** に変わります。 + +## データパイプラインを管理する {#manage-the-data-pipeline} + +### データパイプラインを編集する {#edit-a-data-pipeline} + +データパイプラインを編集するには、対象の {{{ .premium }}}{{{ .byoc }}} インスタンスの **Data Pipeline** に移動し、対象パイプラインの行にある **...** をクリックして、**Edit** をクリックします。 + +データパイプラインが `Running` の間は編集できません。まずパイプラインを一時停止し、その後編集して、変更を適用するために再開してください。 + +送信先タイプと同期モードは、パイプライン作成後に変更できません。 + +> **Note:** +> +> テーブルフィルタールールの変更は、以後の増分データにのみ影響します。 +> +> - 新しいルールで除外されたテーブルには、以後増分データは取り込まれません。すでに書き込まれたデータは保持されます。 +> - 新しいルールで追加されたテーブルには、増分データのみが取り込まれます。過去データのバックフィルは行われません。 + +### データパイプラインを一時停止および再開する {#pause-and-resume-a-data-pipeline} + +- **Pause**: データレプリケーションを停止し、パイプラインを `Paused` としてマークします。データが失われることはなく、レプリケーションの進行状況も保持されます。パイプラインの作成中または完全スナップショットのエクスポート中は、一時停止できません。 +- **Resume**: 一時停止した位置からレプリケーションを再開します。これには TiDB Cloud Lake への取り込みも含まれます。 + +データパイプラインを一時停止または再開するには、対象の {{{ .premium }}}{{{ .byoc }}} インスタンスの **Data Pipeline** に移動し、対象パイプラインの行にある **...** をクリックして、**Pause** または **Resume** をクリックします。 + +### データパイプラインを削除する {#delete-a-data-pipeline} + +データパイプラインを削除するには、次の手順を実行します。 + +1. 対象の {{{ .premium }}}{{{ .byoc }}} インスタンスの **Data Pipeline** に移動し、対象パイプラインの行にある **...** をクリックして、**Delete** をクリックします。 +2. 警告を読み、操作を確認します。データパイプラインを削除すると、次のようになります。 + + - すべてのデータレプリケーションが即座に停止します。 + - パイプラインに関連付けられた TiDB Cloud Lake のデータソースと統合タスクの削除を試みます。削除に失敗した場合、これらのリソースが残り、手動でのクリーンアップが必要になることがあります。 + - TiDB Cloud Lake にすでに書き込まれたデータは**削除されません**。 + - Warehouse 内のターゲットデータベースまたはテーブルは**削除されません**。 + +この操作は元に戻せません。 + +## 関連情報 {#see-also} + +- Data Pipeline に関するよくある質問については、[Data Pipeline FAQ](/tidb-cloud/data-pipeline-lake-faq.md) を参照してください。 +- DDL、DML、およびカラム型のサポートの詳細については、[TiDB Cloud Lake 向け Data Pipeline SQL 互換性](/tidb-cloud/data-pipeline-lake-sql-compatibility.md) を参照してください。 diff --git a/tidb-cloud/data-pipeline.md b/tidb-cloud/data-pipeline.md new file mode 100644 index 0000000000000..ed2210c2a584e --- /dev/null +++ b/tidb-cloud/data-pipeline.md @@ -0,0 +1,120 @@ +--- +title: Data Pipeline +summary: TiDB Cloud から TiDB Cloud Lake に完全データと増分データをレプリケートするデータパイプラインの作成方法と管理方法を学びます。 +--- + +# Data Pipeline + +TiDB Cloud Data Pipeline は、サードパーティの ETL ツールを必要とせずに、TiDB Cloud インスタンスから TiDB Cloud Lake に完全データと増分変更をレプリケートします。継続的なレプリケーションでは、まず選択したソースデータの完全スナップショットをエクスポートし、その後、行の変更を継続的にレプリケートすることで、TiDB Cloud Lake 内のデータを最新の状態に保ちます。 + +Data Pipeline は、次のシナリオで使用できます。 + +- **一度限りのデータロード**: 初期データロードまたは移行のために、完全スナップショットを TiDB Cloud Lake にエクスポートします。 +- **継続的なデータ同期**: 分析およびレポートのワークロード向けに、TiDB Cloud Lake を TiDB Cloud インスタンスと同期した状態に保ちます。 + +## 仕組み {#how-it-works} + +継続的レプリケーションを伴うデータパイプラインは、2 つのフェーズで動作します。 + +1. **完全スナップショットのエクスポート**: 選択したソーステーブルを外部 stage に一度だけエクスポートし、そこから TiDB Cloud Lake がスナップショットをロードします。 +2. **増分レプリケーション**: 行の変更（挿入、更新、削除）を継続的にキャプチャしてレプリケートし、TiDB Cloud Lake をソースの最新状態に保ちます。 + +継続的なレプリケーションを行わず、完全スナップショットのみをエクスポートするようにパイプラインを設定することもできます。 + +**外部 stage**（Amazon S3 または Alibaba Cloud OSS）は、TiDB Cloud インスタンスと TiDB Cloud Lake の間の中間ストレージとして使用されます。TiDB Cloud は、エクスポートしたスナップショットとキャプチャした行変更を stage に書き込み、TiDB Cloud Lake は stage からターゲット Warehouse にデータをロードします。これにより、書き込みレートと消費レートが分離され、信頼性が向上するとともに、コストとレイテンシーを制御できます。 + +詳細については、[Data Pipeline FAQ](/tidb-cloud/data-pipeline-lake-faq.md) を参照してください。 + +## 利用可能状況 {#availability} + + + +| プラン | ステータス | +| ---- | ------ | +| {{{ .premium }}} | Data Pipeline は [TiDB Cloud コンソール](https://tidbcloud.com) でプライベートプレビューとして提供されており、リクエストに応じて利用できます。 | +| {{{ .dedicated }}} | Data Pipeline はまだ TiDB Cloud コンソールでは利用できません。データパイプラインを使用するには、手動でセットアップする必要があります。 | +| {{{ .essential }}} | Data Pipeline はまだ TiDB Cloud コンソールでは利用できません。データパイプラインを使用するには、手動でセットアップする必要があります。 | + + + + +| プラン | ステータス | +| ---- | ------ | +| {{{ .premium }}} | Data Pipeline は [TiDB Cloud コンソール](https://tidbcloud.com) でプライベートプレビューとして提供されており、リクエストに応じて利用できます。 | +| {{{ .byoc }}} | Data Pipeline は [TiDB Cloud コンソール](https://tidbcloud.com) でプライベートプレビューとして提供されており、リクエストに応じて利用できます。 | +| {{{ .dedicated }}} | Data Pipeline はまだ TiDB Cloud コンソールでは利用できません。データパイプラインを使用するには、手動でセットアップする必要があります。 | +| {{{ .essential }}} | Data Pipeline はまだ TiDB Cloud コンソールでは利用できません。データパイプラインを使用するには、手動でセットアップする必要があります。 | + + +> **Note:** +> +> 現在、Data Pipeline は送信先として TiDB Cloud Lake をサポートしています。 + +## データパイプラインを作成する {#create-a-data-pipeline} + +ご利用のプランに応じたガイドを参照してください。 + +- TiDB Cloud Premium および {{{ .byoc }}}: [TiDB Cloud Lake への Data Pipeline をセットアップする](/tidb-cloud/data-pipeline-sink-to-lake.md) +- TiDB Cloud Dedicated: [TiDB Cloud Lake にデータをレプリケートするデータパイプラインを手動でセットアップする](/tidb-cloud/data-pipeline-dedicated-sink-to-lake.md) +- TiDB Cloud Essential: [TiDB Cloud Lake にデータをレプリケートするデータパイプラインを手動でセットアップする](/tidb-cloud/data-pipeline-essential-sink-to-lake.md) + +## Data Pipeline ページを表示する {#view-the-data-pipeline-page} + +> **Note:** +> +> **Data Pipeline** ページおよびこのセクションの管理操作は、{{{ .premium }}} および {{{ .byoc }}} でのみ利用できます。{{{ .dedicated }}} と {{{ .essential }}} では、データパイプラインを手動で設定および管理します。 + +データパイプラインを表示および管理するには、次の手順を実行します。 + +1. [TiDB Cloud コンソール](https://tidbcloud.com) で、[**My TiDB**](https://tidbcloud.com/tidbs) ページに移動します。 + + > **Tip:** + > + > 複数の組織に所属している場合は、まず左上のコンボボックスを使用して対象の組織に切り替えてください。 + +2. 対象の {{{ .premium }}} または {{{ .byoc }}} インスタンス名をクリックして概要ページに移動し、左側のナビゲーションペインで **Data** > **Data Pipeline** をクリックします。**Data Pipeline** ページが表示されます。 + +**Data Pipeline** ページでは、データパイプラインの作成、既存のデータパイプライン一覧の表示、および既存のデータパイプラインの管理（パイプラインの一時停止、再開、編集、削除など）ができます。 + +## データパイプラインを管理する {#manage-a-data-pipeline} + +### データパイプラインを一時停止および再開する {#pause-and-resume-a-data-pipeline} + +- **Pause**: データレプリケーションを停止し、パイプラインを `Paused` としてマークします。データが失われることはなく、レプリケーションの進行状況は保持されます。パイプラインの作成中、または完全スナップショットのエクスポート中は、一時停止できません。 +- **Resume**: 一時停止した位置からレプリケーションを再開します。これには TiDB Cloud Lake への取り込みも含まれます。 + +データパイプラインを一時停止または再開するには、対象の {{{ .premium }}} または {{{ .byoc }}} インスタンスの **Data Pipeline** ページに移動し、パイプラインの行にある **...** をクリックしてから、**Pause** または **Resume** をクリックします。 + +### データパイプラインを編集する {#edit-a-data-pipeline} + +データパイプラインを編集するには、対象の {{{ .premium }}} または {{{ .byoc }}} インスタンスの **Data Pipeline** ページに移動し、パイプラインの行にある **...** をクリックしてから、**Edit** をクリックします。 + +データパイプラインが `Running` の間は編集できません。まずパイプラインを一時停止し、その後編集して、変更を適用するために再開してください。 + +送信先タイプと同期モードは、パイプライン作成後に変更できません。 + +> **Note:** +> +> テーブルフィルタールールの変更は、以降の増分データにのみ影響します。 +> +> - 新しいルールで除外されたテーブルには、以後増分データは取り込まれません。すでに書き込まれたデータは保持されます。 +> - 新しいルールで追加されたテーブルには、増分データのみが取り込まれます。過去データのバックフィルは行われません。 + +### データパイプラインを削除する {#delete-a-data-pipeline} + +データパイプラインを削除するには、次の手順を実行します。 + +1. 対象の {{{ .premium }}} または {{{ .byoc }}} インスタンスの **Data Pipeline** ページに移動し、パイプラインの行にある **...** をクリックしてから、**Delete** をクリックします。 +2. 警告を確認し、操作を確定します。データパイプラインを削除すると、次のようになります。 + + - すべてのデータレプリケーションが直ちに停止します。 + - パイプラインに関連付けられた TiDB Cloud Lake のデータソースと統合タスクの削除を試みます。削除に失敗した場合、これらのリソースが残り、手動でのクリーンアップが必要になることがあります。 + - TiDB Cloud Lake にすでに書き込まれたデータは**削除されません**。 + - Warehouse 内のターゲットデータベースまたはテーブルは**削除されません**。 + +この操作は元に戻せません。 + +## 関連情報 {#see-also} + +- Data Pipeline に関するよくある質問については、[Data Pipeline FAQ](/tidb-cloud/data-pipeline-lake-faq.md) を参照してください。 +- DDL、DML、およびカラム型のサポートの詳細については、[TiDB Cloud Lake 向け Data Pipeline SQL 互換性](/tidb-cloud/data-pipeline-lake-sql-compatibility.md) を参照してください。 diff --git a/tidb-cloud/data-service-api-key.md b/tidb-cloud/data-service-api-key.md index 4cd992fc210c8..66c7f829a2cff 100644 --- a/tidb-cloud/data-service-api-key.md +++ b/tidb-cloud/data-service-api-key.md @@ -8,7 +8,7 @@ summary: データアプリのAPIキーの作成、編集、削除方法を学 TiDB Cloud Data API は[基本認証](https://en.wikipedia.org/wiki/Basic_access_authentication)と[ダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)の両方をサポートしています。 - [基本認証](https://en.wikipedia.org/wiki/Basic_access_authentication)は、暗号化されていない Base64 エンコーディングを使用して、公開キーと秘密キーを送信します。 HTTPS により通信のセキュリティが確保されます。詳細については、 [RFC 7617 - 'Basic'HTTP認証方式](https://datatracker.ietf.org/doc/html/rfc7617)を参照してください。 -- [ダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)は、ネットワーク送信前に公開キー、秘密キー、サーバー提供のノンス値、HTTP メソッド、およびリクエストされた URI をハッシュすることにより、追加のセキュリティレイヤーを提供します。これにより、秘密キーが暗号化され、秘密キーが平文で送信されるのを防ぎます。詳細については、 [RFC 7616 - HTTPダイジェストアクセス認証](https://datatracker.ietf.org/doc/html/rfc7616)を参照してください。 +- [ダイジェスト認証](https://en.wikipedia.org/wiki/Digest_access_authentication)は、ネットワーク送信前に公開キー、秘密キー、サーバー提供のノンス値、HTTP メソッド、およびリクエストされた URI をハッシュすることにより、追加のセキュリティレイヤーを提供します。これにより、秘密キー自体が平文で送信されることはありません。詳細については、 [RFC 7616 - HTTPダイジェストアクセス認証](https://datatracker.ietf.org/doc/html/rfc7616)を参照してください。 > **Note:** > diff --git a/tidb-cloud/data-service-manage-endpoint.md b/tidb-cloud/data-service-manage-endpoint.md index 39e60141cfb8f..ce571a7fea033 100644 --- a/tidb-cloud/data-service-manage-endpoint.md +++ b/tidb-cloud/data-service-manage-endpoint.md @@ -401,8 +401,8 @@ TiDB Cloud Data Serviceは、エンドポイントを呼び出すのに役立つ - 環境：ニーズに応じて、**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`オプションが追加されています。 diff --git a/tidb-cloud/data-service-manage-github-connection.md b/tidb-cloud/data-service-manage-github-connection.md index 53361b41cedbc..a27fde6bc8f20 100644 --- a/tidb-cloud/data-service-manage-github-connection.md +++ b/tidb-cloud/data-service-manage-github-connection.md @@ -98,7 +98,7 @@ GitHub接続で**Auto Sync & Deployment**が有効になっている場合、Git | `data_source/cluster.json` | このファイルを更新する際は、リンクされているTiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスターにアクセスできることを確認してください。TiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスターの ID は、その URL から取得できます。たとえば、URL が`https://tidbcloud.com/tidbs/1234567891234567890/overview?orgId=`の場合、ID は`1234567891234567890`です。 | | `http_endpoints/config.json` | エンドポイントを変更する場合は、 [HTTPエンドポイント構成](/tidb-cloud/data-service-app-config-files.md#http-endpoint-configuration)で説明されているルールに従ってください。 | | `http_endpoints/sql/method-.sql` | `http_endpoints/sql`ディレクトリに SQL ファイルを追加または削除するには、対応するエンドポイント構成も更新する必要があります。 | -| `datapp_config.json` | `dataapp_config.json`ファイルが別のデータアプリからコピーされたもので、現在のデータアプリの ID に更新したい場合を除き、このファイルの`app_id`フィールドを変更しないでください。そうしないと、この変更によってトリガーされるデプロイが失敗します。 | +| `dataapp_config.json` | `dataapp_config.json`ファイルが別のデータアプリからコピーされたもので、現在のデータアプリの ID に更新したい場合を除き、このファイルの`app_id`フィールドを変更しないでください。そうしないと、この変更によってトリガーされるデプロイが失敗します。 | これらのファイルのフィールド構成の詳細については、 [データアプリの設定ファイル](/tidb-cloud/data-service-app-config-files.md)を参照してください。 @@ -129,7 +129,7 @@ TiDB Cloudコンソールで[データアプリのエンドポイントを変更 4. 新しいデータアプリのIDと名前を取得します。左側のペインで新しいデータアプリの名前をクリックすると、右側のペインの**Data App Properties**領域にアプリのIDと名前が表示されます。 -5. GitHub の新しいパスで、 `datapp_config.json`ファイル内の`app_id`と`app_name`を取得した ID と名前に更新し、変更をプッシュしてください。 +5. GitHub の新しいパスで、 `dataapp_config.json`ファイル内の`app_id`と`app_name`を取得した ID と名前に更新し、変更をプッシュしてください。 ファイルの変更がGitHubにプッシュされると、 TiDB Cloudは最新の変更内容を反映した新しいデータアプリを自動的にデプロイします。 diff --git a/tidb-cloud/data-service-oas-with-nextjs.md b/tidb-cloud/data-service-oas-with-nextjs.md index ae39b5fc68d22..5a58a4d39f22f 100644 --- a/tidb-cloud/data-service-oas-with-nextjs.md +++ b/tidb-cloud/data-service-oas-with-nextjs.md @@ -192,7 +192,7 @@ SELECT * FROM test.repository; > }); > ``` > - > `basePath`をデータアプリの実際のエンドポイントパスに置き換えてください。 `${YOUR_REGION}`と`{YOUR_DATA_APP_ID}`を取得するには、エンドポイントの**Properties**パネルで**Endpoint URL**を確認してください。 + > `basePath`をデータアプリの実際のエンドポイントパスに置き換えてください。 `${YOUR_REGION}`と`${YOUR_DATA_APP_ID}`を取得するには、エンドポイントの**Properties**パネルで**Endpoint URL**を確認してください。 ## ステップ5．Next.jsアプリケーションをプレビューする {#step-5-preview-your-next-js-application} diff --git a/tidb-cloud/essential-changefeed-sink-to-kafka.md b/tidb-cloud/essential-changefeed-sink-to-kafka.md index 68f08b67c34f0..3baf853a7ad20 100644 --- a/tidb-cloud/essential-changefeed-sink-to-kafka.md +++ b/tidb-cloud/essential-changefeed-sink-to-kafka.md @@ -134,7 +134,7 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト - **Filter Rules**：この列でフィルタルールを設定できます。デフォルトでは、すべてのテーブルを複製するルール`*.*`が設定されています。新しいルールを追加して**Apply**をクリックすると、 TiDB Cloud はTiDB 内のすべてのテーブルをクエリし、**Filter results**の下にルールに一致するテーブルのみを表示します。 - **Case Sensitive**：フィルタルールにおけるデータベース名とテーブル名の照合において、大文字小文字を区別するかどうかを設定できます。デフォルトでは、大文字小文字は区別されません。 - **有効なキーで結果をフィルタリングする**：この列には、主キーや一意インデックスなど、有効なキーを持つテーブルが表示されます。 - - **有効なキーのない結果をフィルタリングする**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`"!test.tbl1"`を使用して、テーブル`test.tbl1`を除外できます。 + - **有効なキーのない結果をフィルタリングする**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`!test.tbl1`を使用して、テーブル`test.tbl1`を除外できます。 2. **Event Filter**をカスタマイズして、複製したいイベントを絞り込みます。 diff --git a/tidb-cloud/essential-changefeed-sink-to-mysql.md b/tidb-cloud/essential-changefeed-sink-to-mysql.md index e2104a535f448..bcbf4b43ee42e 100644 --- a/tidb-cloud/essential-changefeed-sink-to-mysql.md +++ b/tidb-cloud/essential-changefeed-sink-to-mysql.md @@ -105,7 +105,7 @@ MySQLサービスがパブリックネットワーク経由でアクセスでき - **Filter Rules**：この列でフィルタルールを設定できます。デフォルトでは、すべてのテーブルを複製するルール`*.*`が設定されています。新しいルールを追加して**Apply**をクリックすると、 TiDB Cloud はTiDB 内のすべてのテーブルをクエリし、**Filter results**の下にルールに一致するテーブルのみを表示します。 - **Case Sensitive**：フィルタルールにおけるデータベース名とテーブル名の照合において、大文字小文字を区別するかどうかを設定できます。デフォルトでは、大文字小文字は区別されません。 - **有効なキーで結果をフィルタリングする**：この列には、主キーや一意インデックスなど、有効なキーを持つテーブルが表示されます。 - - **有効なキーのない結果をフィルタリングする**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`"!test.tbl1"`を使用して、テーブル`test.tbl1`を除外できます。 + - **有効なキーのない結果をフィルタリングする**: この列には、主キーまたは一意キーがないテーブルが表示されます。一意の識別子がないと、ダウンストリームが重複イベントを処理する際にデータの一貫性が失われる可能性があるため、これらのテーブルはレプリケーション中に問題となります。データの一貫性を確保するには、レプリケーションを開始する前に、これらのテーブルに一意キーまたは主キーを追加することをお勧めします。または、フィルタルールを追加してこれらのテーブルを除外することもできます。たとえば、ルール`!test.tbl1`を使用して、テーブル`test.tbl1`を除外できます。 7. **Event Filter**をカスタマイズして、複製したいイベントを絞り込みます。 diff --git a/tidb-cloud/monitor-built-in-alerting.md b/tidb-cloud/monitor-built-in-alerting.md index c690ac3474175..05141d8866132 100644 --- a/tidb-cloud/monitor-built-in-alerting.md +++ b/tidb-cloud/monitor-built-in-alerting.md @@ -130,24 +130,49 @@ TiDB Cloudは、そのプランで利用可能[特徴](/tidb-cloud/features.md) - + -### パフォーマンス概要アラート {#performance-overview-alerts} +### {{{ .premium }}} のパフォーマンス概要アラート {#performance-overview-alerts-for-premium} -| 状態 | 推奨される行動 | -| :-------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 1秒あたりのリクエストユニット数（RU/s）が最大RCUの80%を超えています |
    1. RUのメトリクスをレビューして、増加が緩やかなものか、急激な増加なのかを判断してください。
    2. 増加が緩やかな場合は、クエリの実行時間が長くなっているかどうかを確認してください。もしそうであれば、現在の最大RCUでは不十分な可能性があります。
    3. TiDB Cloudコンソールで最大RCUを手動で増やすことで、容量を拡張できます。

    問題を解決できない場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 | -| QPSが80%減少 |
    1. クエリのレイテンシーの増加がドロップの原因かどうかを確認してください。
    2. アプリケーションが正常に動作していることを確認してください。意図的なドロップの場合は、このアラートを無視してください。ドロップが意図的でなく、根本原因が特定できない場合は、直ちに[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。
    | -| クエリP99のレイテンシーが200msを超えた |
    1. スロークエリを調査するには、スロークエリのページに移動し、最近の期間でフィルタリングして、新しく導入されたクエリや実行速度がスロークエリを特定します。
    2. アプリケーションのデプロイ、スキーマの変更、データインポートジョブなど、トラフィックパターンに影響を与えた可能性のある最近の変更点を確認してください。

    根本原因が特定できない場合は、直ちに[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にご連絡ください。 | -| クエリP95のレイテンシーが200msを超えた |
    1. スロークエリを調査するには、スロークエリのページに移動し、最近の期間でフィルタリングして、新しく導入されたクエリや実行速度がスロークエリを特定します。
    2. アプリケーションのデプロイ、スキーマの変更、データインポートジョブなど、トラフィックパターンに影響を与えた可能性のある最近の変更点を確認してください。

    根本原因が特定できない場合は、直ちに[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にご連絡ください。 | -| リクエストエラー率が10%を超えています。 | クラスターにおける最近のエラーと全体的なステートメント実行状況を確認してください。 | +| 条件 | 推奨アクション | +|:--- |:--- | +| 1 秒あたりのリクエストユニット (RU/s) が最大 RCU の 80% を超える |
    1. RU メトリクスを確認し、増加が緩やかなものか、急激なスパイクかを判断します。
    2. 増加が緩やかな場合は、クエリ実行時間が増加していないか確認します。増加している場合、現在の最大 RCU では不足している可能性があります。
    3. TiDB Cloud コンソールで最大 RCU を手動で増やして、容量をスケールします。

    問題を解決できない場合は、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。| +| QPS が 80% 低下する |
    1. 低下の原因がクエリのレイテンシー増加によるものか確認します。
    2. アプリケーションが正常に動作していることを確認します。低下が意図的なものであれば、このアラートは無視してください。意図しない低下であり、根本原因を特定できない場合は、直ちに [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。
    | +| クエリ P99 レイテンシーが 200 ms を超える |
    1. 低速クエリを調査します。Slow Query ページに移動し、直近の時間範囲でフィルタリングして、新たに発生したクエリや実行が遅くなったクエリを特定します。
    2. トラフィックパターンに影響した可能性がある、アプリケーションのデプロイ、スキーマ変更、データインポートジョブなどの最近の変更を確認します。

    根本原因を特定できない場合は、直ちに [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。| +| クエリ P95 レイテンシーが 200 ms を超える |
    1. 低速クエリを調査します。Slow Query ページに移動し、直近の時間範囲でフィルタリングして、新たに発生したクエリや実行が遅くなったクエリを特定します。
    2. トラフィックパターンに影響した可能性がある、アプリケーションのデプロイ、スキーマ変更、データインポートジョブなどの最近の変更を確認します。

    根本原因を特定できない場合は、直ちに [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。| +| リクエストエラー率が 10% を超える | 最近のエラーと、クラスター全体のステートメント実行状況を確認します。| +| 1 分以内に 20 件を超える SQL ステートメントが 256 ms のレイテンシーしきい値を超える | 最近のスキーマまたはインデックスの変更がないか確認します。TiDB Cloud コンソールで低速クエリの一覧を確認します。対応する低速クエリの記録が表示されるまでに数分かかる場合があります。根本原因を特定できない場合は、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。| +| 1 分以内に 20 件を超える SQL ステートメントが 512 ms のレイテンシーしきい値を超える | 最近のスキーマまたはインデックスの変更がないか確認します。TiDB Cloud コンソールで低速クエリの一覧を確認します。対応する低速クエリの記録が表示されるまでに数分かかる場合があります。根本原因を特定できない場合は、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。| +| 1 分以内に 20 件を超える SQL ステートメントが 4,096 ms のレイテンシーしきい値を超える | 最近のスキーマまたはインデックスの変更がないか確認します。TiDB Cloud コンソールで低速クエリの一覧を確認します。対応する低速クエリの記録が表示されるまでに数分かかる場合があります。根本原因を特定できない場合は、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。| -### TiDB Cloud EssentialおよびTiDB Cloud Premiumの変更フィードアラート {#changefeed-alerts-for-tidb-cloud-essential-and-tidb-cloud-premium} +### {{{ .premium }}} の Changefeed アラート {#changefeed-alerts-for-premium} -| 状態 | 推奨される行動 | -| :------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 変更フィードのレイテンシーが600秒を超えています。 | TiDB Cloudコンソールの**Changefeed**ページと**Changefeed Detail**ページで変更フィードのステータスを確認してください。これらのページには、この問題の診断に役立つエラーメッセージがいくつか表示されています。
    このアラートが発生する可能性のある理由としては、以下のようなものが挙げられます。
    • アップストリーム全体のトラフィックが増加したため、既存のチェンジフィード仕様では対応しきれなくなりました。トラフィックの増加が一時的なものであれば、トラフィックが正常に戻ればチェンジフィードのレイテンシーは自動的に回復します。トラフィックの増加が継続する場合は、チェンジフィードをスケールアップする必要があります。
    • 下流側またはネットワークに異常が発生しています。この場合は、まずこの異常を解消してください。
    • ダウンストリームがRDSの場合、テーブルにインデックスが不足しているため、書き込みパフォーマンスの低下やレイテンシーの増加が発生する可能性があります。この場合、アップストリームまたはダウンストリームに必要なインデックスを追加する必要があります。
    お客様側で問題を解決できない場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 | -| 変更フィードの状態は`FAILED`です。 | TiDB Cloudコンソールの**Changefeed**ページと**Changefeed Detail**ページで変更フィードのステータスを確認してください。これらのページには、この問題の診断に役立つエラーメッセージがいくつか表示されています。
    お客様側で問題を解決できない場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 | -| 変更フィードの状態は`WARNING`です。 | TiDB Cloudコンソールの**Changefeed**ページと**Changefeed Detail**ページで変更フィードのステータスを確認してください。これらのページには、この問題の診断に役立つエラーメッセージがいくつか表示されています。
    お客様側で問題を解決できない場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 | +| 条件 | 推奨アクション | +|:--------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| changefeed のレイテンシーが 600 秒を超えています。 | TiDB Cloud コンソールの **Changefeed** ページおよび **Changefeed Detail** ページで changefeed のステータスを確認してください。問題の診断に役立つエラーメッセージを確認できます。
    このアラートが発生する原因として、次のようなものがあります。
    • アップストリーム全体のトラフィックが増加し、既存の changefeed のスペックでは処理しきれなくなっている。トラフィックの増加が一時的な場合、トラフィックが正常に戻ると changefeed のレイテンシーは自動的に回復します。トラフィックの増加が継続的な場合は、changefeed をスケールアップする必要があります。
    • ダウンストリームまたはネットワークに異常がある。この場合は、まずその異常を解消してください。
    • ダウンストリームが RDS の場合、テーブルにインデックスが不足している可能性があり、書き込み性能の低下と高レイテンシーの原因になることがあります。この場合は、アップストリームまたはダウンストリームに必要なインデックスを追加する必要があります。
    問題をお客様側で解決できない場合は、追加のサポートについて [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。 | +| changefeed のステータスが `FAILED` です。 | TiDB Cloud コンソールの **Changefeed** ページおよび **Changefeed Detail** ページで changefeed のステータスを確認してください。問題の診断に役立つエラーメッセージを確認できます。
    問題をお客様側で解決できない場合は、追加のサポートについて [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。| +| changefeed のステータスが `WARNING` です。 | TiDB Cloud コンソールの **Changefeed** ページおよび **Changefeed Detail** ページで changefeed のステータスを確認してください。問題の診断に役立つエラーメッセージを確認できます。
    問題をお客様側で解決できない場合は、追加のサポートについて [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。| + +     + + + +### {{{ .essential }}} のパフォーマンス概要アラート {#performance-overview-alerts-for-essential} + +| 条件 | 推奨アクション | +|:--- |:--- | +| 1 秒あたりのリクエストユニット (RU/s) が最大 RCU の 80% を超える |
    1. RU メトリクスを確認し、増加が緩やかなものか、急激なスパイクかを判断します。
    2. 増加が緩やかな場合は、クエリ実行時間が増加していないか確認します。増加している場合、現在の最大 RCU では不足している可能性があります。
    3. TiDB Cloud コンソールで最大 RCU を手動で増やして、容量をスケールします。

    問題を解決できない場合は、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。| +| QPS が 80% 低下する |
    1. 低下の原因がクエリのレイテンシー増加によるものか確認します。
    2. アプリケーションが正常に動作していることを確認します。低下が意図的なものであれば、このアラートは無視してください。意図しない低下であり、根本原因を特定できない場合は、直ちに [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。
    | +| クエリ P99 レイテンシーが 200 ms を超える |
    1. 低速クエリを調査します。Slow Query ページに移動し、直近の時間範囲でフィルタリングして、新たに発生したクエリや実行が遅くなったクエリを特定します。
    2. トラフィックパターンに影響した可能性がある、アプリケーションのデプロイ、スキーマ変更、データインポートジョブなどの最近の変更を確認します。

    根本原因を特定できない場合は、直ちに [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。| +| クエリ P95 レイテンシーが 200 ms を超える |
    1. 低速クエリを調査します。Slow Query ページに移動し、直近の時間範囲でフィルタリングして、新たに発生したクエリや実行が遅くなったクエリを特定します。
    2. トラフィックパターンに影響した可能性がある、アプリケーションのデプロイ、スキーマ変更、データインポートジョブなどの最近の変更を確認します。

    根本原因を特定できない場合は、直ちに [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。| +| リクエストエラー率が 10% を超える | 最近のエラーと、クラスター全体のステートメント実行状況を確認します。| + +### {{{ .essential }}} の Changefeed アラート {#changefeed-alerts-for-essential} + +| 条件 | 推奨アクション | +|:--------------------------------------------|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| changefeed のレイテンシーが 600 秒を超えています。 | TiDB Cloud コンソールの **Changefeed** ページおよび **Changefeed Detail** ページで changefeed のステータスを確認してください。問題の診断に役立つエラーメッセージを確認できます。
    このアラートが発生する原因として、次のようなものがあります。
    • アップストリーム全体のトラフィックが増加し、既存の changefeed のスペックでは処理しきれなくなっている。トラフィックの増加が一時的な場合、トラフィックが正常に戻ると changefeed のレイテンシーは自動的に回復します。トラフィックの増加が継続的な場合は、changefeed をスケールアップする必要があります。
    • ダウンストリームまたはネットワークに異常がある。この場合は、まずその異常を解消してください。
    • ダウンストリームが RDS の場合、テーブルにインデックスが不足している可能性があり、書き込み性能の低下と高レイテンシーの原因になることがあります。この場合は、アップストリームまたはダウンストリームに必要なインデックスを追加する必要があります。
    問題をお客様側で解決できない場合は、追加のサポートについて [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。 | +| changefeed のステータスが `FAILED` です。 | TiDB Cloud コンソールの **Changefeed** ページおよび **Changefeed Detail** ページで changefeed のステータスを確認してください。問題の診断に役立つエラーメッセージを確認できます。
    問題をお客様側で解決できない場合は、追加のサポートについて [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。| +| changefeed のステータスが `WARNING` です。 | TiDB Cloud コンソールの **Changefeed** ページおよび **Changefeed Detail** ページで changefeed のステータスを確認してください。問題の診断に役立つエラーメッセージを確認できます。
    問題をお客様側で解決できない場合は、追加のサポートについて [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。|     diff --git a/tidb-cloud/premium/import-csv-files-premium.md b/tidb-cloud/premium/import-csv-files-premium.md index d1ca8e90b89cf..1f0aa049479c1 100644 --- a/tidb-cloud/premium/import-csv-files-premium.md +++ b/tidb-cloud/premium/import-csv-files-premium.md @@ -83,6 +83,12 @@ TiDB Cloud PremiumがAmazon S3またはAlibaba Cloud Object Storage Service（OS バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-csv-files)で必要となるため、アクセスキー (アクセスキー ID とシークレットアクセスキーを含む) またはロール ARN の値をメモしておいてください。 + + + {{{ .byoc }}} の場合、AWS Role ARN を使用する場合は、インポートを開始する前に、IAM ロールにタグ `tidbcloud.com/allow-dataplane-access=true` が設定されていることを確認してください。 + + + - 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} diff --git a/tidb-cloud/premium/import-from-s3-premium.md b/tidb-cloud/premium/import-from-s3-premium.md index e8818d7fbf90b..3b0a2c485ff83 100644 --- a/tidb-cloud/premium/import-from-s3-premium.md +++ b/tidb-cloud/premium/import-from-s3-premium.md @@ -44,6 +44,12 @@ TiDB Cloud Premiumがバケットを読み取れるようにするには、以 ウィザードには**Click here to create a new one with AWS CloudFormation**というラベルの付いたヘルプリンクが含まれています。TiDB Cloud Premium で CloudFormation スタックを事前に設定してロールを作成する必要がある場合は、このリンクをクリックしてください。 + + +{{{ .byoc }}} インスタンスで AWS Role ARN を使用する場合、IAM ロールには `tidbcloud.com/allow-dataplane-access=true` タグが必要です。このタグがない場合は、インポートを開始する前にロールに追加してください。 + + + ## ステップ4. Amazon S3からCSVファイルをインポートする {#step-4-import-csv-files-from-amazon-s3} 1. [TiDB Cloudコンソール](https://tidbcloud.com/tidbs)で、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、 TiDB Cloud Premiumインスタンスの名前をクリックします。 diff --git a/tidb-cloud/premium/tidb-cloud-auditing-premium.md b/tidb-cloud/premium/tidb-cloud-auditing-premium.md index e6c1c67f14969..cb5dc070bef1a 100644 --- a/tidb-cloud/premium/tidb-cloud-auditing-premium.md +++ b/tidb-cloud/premium/tidb-cloud-auditing-premium.md @@ -82,6 +82,14 @@ TiDB Cloudが監査ログを書き込む宛先として、組織が所有するA - はいの場合、後で使用するために一致したロールを記録してください。 - そうでない場合は、 **Create role**をクリックし、信頼エンティティタイプとして**Another AWS account**を選択してから、 **Account ID**フィールドにTiDB CloudアカウントIDの値を入力します。次に、 **Require External ID**オプションを選択し、**External ID**フィールドにTiDB Cloud外部IDの値を入力します。 + + + {{{ .byoc }}} の場合、顧客が作成した `tidbx-byoc-auditlog-role` IAM ロールに `tidbcloud.com/allow-dataplane-access=true` タグが付いていることを確認してください。 + + タグがない場合は、監査ログを有効にする前にそのタグをロールに追加してください。タグを追加する前に監査ログを有効にしていた場合は、タグを更新した後で監査ログを無効化してから再度有効にしてください。 + + + 4. **IAM** > **Access Management** > **Roles**で、前の手順で確認したロール名をクリックして**Summary**ページに移動し、以下の手順を実行します。 1. **Permissions**タブで、 `s3:PutObject`書き込み専用アクセス許可を持つ記録済みポリシーがロールに添付されているかどうかを確認します。添付されていない場合は、 **Attach Policies**を選択し、必要なポリシーを検索して、 **Attach Policy**をクリックします。 diff --git a/tidb-cloud/releases/_index.md b/tidb-cloud/releases/_index.md index 3ae9c7d80b8d0..c4c7d06e083c6 100644 --- a/tidb-cloud/releases/_index.md +++ b/tidb-cloud/releases/_index.md @@ -19,16 +19,12 @@ TiDB Cloud には、[クラウドプラットフォーム リリース](#cloud-p データベース カーネルは、SQL クエリを処理し、データを管理するコア エンジンです。TiDB Cloud プランに応じて、ご利用のリソースは異なるカーネルで実行され、それぞれ独自のリリース サイクルを持ちます。 -| Plan | Kernel information and release notes | -| --- | --- | -| TiDB Cloud **Starter** | クラシック [TiDB v8.5.3](https://docs.pingcap.com/tidb/stable/release-8.5.3/) カーネルをベースにしたカスタマイズ版 [TiDB X](/tidb-cloud/tidb-x-architecture.md) エンジンで実行されます。 | -| TiDB Cloud **Essential** | デフォルトでは、クラシック [TiDB v8.5.3](https://docs.pingcap.com/tidb/stable/release-8.5.3/) カーネルをベースにしたカスタマイズ版 [TiDB X](/tidb-cloud/tidb-x-architecture.md) エンジンで実行されます。 | -| TiDB Cloud **Premium** | [TiDB X](/tidb-cloud/tidb-x-architecture.md) カーネルの [`TiDB-X-CLOUD.202510.1`](/tidb-cloud/releases/tidb-x-cloud.202510.1.md) バージョンで実行されます。 | -| TiDB Cloud **Dedicated** | クラシック TiDB カーネルで実行され、カーネルバージョンは TiDB Self-Managed のバージョンに直接対応します。現在、新しく作成された TiDB Cloud Dedicated クラスターのデフォルト TiDB バージョンは [v8.5.8](https://docs.pingcap.com/tidb/stable/release-8.5.8/) です。 | - -> **Note:** -> -> TiDB Cloud Essential インスタンスを TiDB Cloud Premium と同じカーネルで実行したい場合は、[TiDB Cloud Support](https://docs.pingcap.com/tidbcloud/tidb-cloud-support) にお問い合わせください。 +| Plan | Kernel | Default kernel version for newly created instances or clusters | +| --- | --- | --- | +| TiDB Cloud **Starter** | クラシック TiDB カーネルをベースにしたカスタマイズ版 [TiDB X](/tidb-cloud/tidb-x-architecture.md) エンジンで実行されます。 | [TiDB v8.5.3](https://docs.pingcap.com/tidb/stable/release-8.5.3/) | +| TiDB Cloud **Essential** | 2026 年 6 月 30 日以降に作成された TiDB Cloud Essential インスタンスは、[TiDB X](/tidb-cloud/tidb-x-architecture.md) カーネルで実行されます。 | [TiDB-X-CLOUD.202603.1](/tidb-cloud/releases/tidb-x-cloud.202603.1.md) | +| TiDB Cloud **Premium** | [TiDB X](/tidb-cloud/tidb-x-architecture.md) カーネルで実行されます。 | [TiDB-X-CLOUD.202603.1](/tidb-cloud/releases/tidb-x-cloud.202603.1.md) | +| TiDB Cloud **Dedicated** | クラシック TiDB カーネルで実行されます。 | [TiDB v8.5.8](https://docs.pingcap.com/tidb/stable/release-8.5.8/) | ## メンテナンス通知 {#maintenance-notifications} diff --git a/tidb-cloud/releases/tidb-cloud-kernel-versioning.md b/tidb-cloud/releases/tidb-cloud-kernel-versioning.md index 469cb6538a077..63da836d10347 100644 --- a/tidb-cloud/releases/tidb-cloud-kernel-versioning.md +++ b/tidb-cloud/releases/tidb-cloud-kernel-versioning.md @@ -12,7 +12,7 @@ summary: TiDB Cloud Premium のカーネルのバージョニング規則と形 > このドキュメントで説明するカーネルバージョニング規則は、TiDB Cloud Premium にのみ適用されます。その他の TiDB Cloud プランでは、異なるカーネルバージョニングモデルが使用されます。 > > - TiDB Cloud Starter インスタンスは、従来の TiDB v8.5.3 カーネルをベースにしたカスタマイズ済みの TiDB X エンジン上で動作します。このカーネルは、TiDB Cloud Premium のカーネルとは若干異なります。 -> - TiDB Cloud Essential インスタンスは、デフォルトで従来の TiDB v8.5.3 カーネルをベースにしたカスタマイズ済みの TiDB X エンジン上で動作します。TiDB Cloud Essential インスタンスを TiDB Cloud Premium と同じカーネルで動作させたい場合は、[TiDB Cloud Support](https://docs.pingcap.com/tidbcloud/tidb-cloud-support) にお問い合わせください。 +> - 2026 年 6 月 30 日以降、新しく作成された TiDB Cloud Essential インスタンスは、TiDB Cloud Premium と同じ [TiDB X](/tidb-cloud/tidb-x-architecture.md) カーネル上で動作します。 > - TiDB Cloud Dedicated クラスターは、従来の TiDB カーネル上で動作し、そのカーネルバージョンは TiDB Self-Managed のバージョンに直接対応します。 ## カーネルバージョニング {#kernel-versioning} @@ -38,7 +38,7 @@ TiDB-X-CLOUD.202510.1 カーネルの開発スケジュールとリリーススケジュールは独立しているため、カーネルバージョンはベースラインブランチの作成から数か月後にリリースされる場合があります。 -TiDB Cloud Premium は独自のカーネルリリースサイクルに従うため、[TiDB Cloud Premium リリースノート](/tidb-cloud/releases/tidb-x-cloud.202510.1.md) は [TiDB Self-Managed リリースノート](https://docs.pingcap.com/releases/tidb-self-managed/) とは別に公開されます。 +TiDB Cloud Premium は独自のカーネルリリースサイクルに従うため、[TiDB Cloud Premium リリースノート](/tidb-cloud/releases/tidb-x-cloud.202603.1.md) は [TiDB Self-Managed リリースノート](https://docs.pingcap.com/releases/tidb-self-managed/) とは別に公開されます。 ## FAQ {#faq} diff --git a/tidb-cloud/releases/tidb-cloud-release-notes.md b/tidb-cloud/releases/tidb-cloud-release-notes.md index 80fb187910455..8f5faa4528732 100644 --- a/tidb-cloud/releases/tidb-cloud-release-notes.md +++ b/tidb-cloud/releases/tidb-cloud-release-notes.md @@ -8,6 +8,28 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes', このページには、2026年の[TiDB Cloud](https://www.pingcap.com/tidb-cloud/)のリリースノートが掲載されています。 +## 2026年9月29日 {#september-29-2026} + +**一般的な変更** + +- **TiDB Cloud Premium** + + - TiDB Cloud Premium に、クエリのレイテンシー件数しきい値アラートが追加されました。 + + TiDB Cloud Premium では、1 分以内に 20 件を超える SQL ステートメントが 256 ms、512 ms、または 4096 ms のレイテンシーしきい値を超えた場合に通知する、3 つの組み込みアラートルールが提供されるようになりました。これらのアラートは、低速な SQL ステートメントの数が異常に多い期間を検出するのに役立ちます。 + + 詳細は、[TiDB Cloudの組み込みアラート機能](https://docs.pingcap.com/tidbcloud/built-in-monitoring-premium/?plan=premium) を参照してください。 + +- **TiDB Cloud Dedicated** + + - TiDB Cloud Dedicated が、リージョン間の AWS PrivateLink 接続をサポートしました。 + + この機能により、あるリージョンで AWS インターフェースエンドポイントを作成し、別のリージョンにある TiDB Cloud Dedicated クラスターにプライベート接続できます。リージョン間接続では、同じ接続文字列を使用します。 + + 現在、この機能はリクエストに応じて利用可能です。リージョン間 PrivateLink サービス料金は追加されたリージョンごとに適用され、リージョンを削除しても既存の接続には影響しません。この機能をリクエストするには、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。 + + 詳細は、[AWS PrivateLink を介して TiDB Cloud Dedicated クラスターに接続する](https://docs.pingcap.com/tidbcloud/set-up-private-endpoint-connections/) を参照してください。 + ## 2026年9月22日 {#september-22-2026} **一般的な変更** diff --git a/tidb-cloud/releases/tidb-x-cloud.202603.1.md b/tidb-cloud/releases/tidb-x-cloud.202603.1.md new file mode 100644 index 0000000000000..7292113523d53 --- /dev/null +++ b/tidb-cloud/releases/tidb-x-cloud.202603.1.md @@ -0,0 +1,91 @@ +--- +title: TiDB-X-CLOUD.202603.1 リリースノート +summary: TiDB-X-CLOUD.202603.1 カーネルの機能について説明します。 +--- + +# TiDB-X-CLOUD.202603.1 リリースノート + +**リリース日**: 2026年7月16日 + +**適用対象の TiDB Cloud プラン**: {{{ .essential }}} および {{{ .premium }}} + +**TiDB X カーネルバージョン**: `TiDB-X-CLOUD.202603.1` + +2026年7月16日以降、新しく作成される {{{ .essential }}} および {{{ .premium }}} インスタンスのデフォルトのカーネルバージョンは `TiDB-X-CLOUD.202603.1` です。 + +`TiDB-X-CLOUD.202603.1` では、次のようになります。 + +- `202603` は、このカーネルバージョンのベースラインコードブランチが 2026年3月に作成されたことを示しており、リリース日とは異なります。 +- `1` は、`TiDB-X-CLOUD.202603` ベースラインブランチからビルドされた最初のパッチリリースであることを示します。 + +## 機能 {#features} + +### パフォーマンス {#performance} + +* 特定の損失のある DDL 操作（`BIGINT → INT` や `CHAR(120) → VARCHAR(60)` など）に対して大幅なパフォーマンス改善を導入しました。データ切り捨てが発生しない場合、これらの操作の実行時間を数時間から数分、数秒、さらには数ミリ秒まで短縮でき、数十倍から数十万倍の性能向上を実現します [#63366](https://github.com/pingcap/tidb/issues/63366) @[wjhuang2016](https://github.com/wjhuang2016) @[tangenta](https://github.com/tangenta) @[fzzf678](https://github.com/fzzf678) + + 最適化戦略は次のとおりです。 + + - 厳密な SQL モードでは、TiDB は型変換時の潜在的なデータ切り捨てリスクを事前チェックします。 + - データ切り捨てリスクが検出されない場合、TiDB はメタデータのみを更新し、可能な限りインデックスの再構築を回避します。 + - インデックスの再構築が必要な場合、TiDB はより効率的な取り込みプロセスを使用して、インデックス再構築のパフォーマンスを大幅に向上させます。 + + 次の表は、114 GiB のデータと 6 億行を持つテーブルに対するベンチマークテストに基づく性能改善の例を示しています。テストクラスターは 3 台の TiDB ノード、6 台の TiKV ノード、1 台の PD ノードで構成されています。すべてのノードは 16 CPU コアと 32 GiB のメモリで構成されています。 + + | シナリオ | 操作タイプ | 最適化前 | 最適化後 | 性能改善 | + |----------|----------------|---------------------|--------------------|--------------------------| + | インデックスなしカラム | `BIGINT → INT` | 2時間34分 | 1分5秒 | 142倍高速 | + | インデックス付きカラム | `BIGINT → INT` | 6時間25分 | 0.05秒 | 460,000倍高速 | + | インデックス付きカラム | `CHAR(120) → VARCHAR(60)` | 7時間16分 | 12分56秒 | 34倍高速 | + + 上記のテスト結果は、DDL 実行中にデータ切り捨てが発生しないことを前提としています。これらの最適化は、符号付き整数型と符号なし整数型の間の変換、文字セット間の変換、または TiFlash レプリカを持つテーブルには適用されません。 + + 詳細は、[ドキュメント](https://docs.pingcap.com/tidbcloud/sql-statement-modify-column/?plan=premium)を参照してください。 + +### 可観測性 {#observability} + +* スロークエリに対して、多次元かつきめ細かなトリガールールの定義をサポートしました [#62959](https://github.com/pingcap/tidb/issues/62959) [#64010](https://github.com/pingcap/tidb/issues/64010) @[zimulala](https://github.com/zimulala) + + TiDB Cloud では、デフォルトで 300 ミリ秒を超える SQL クエリがスロークエリと見なされます。スロークエリは、[TiDB Cloud コンソール](https://tidbcloud.com/)の [**Diagnosis**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page) ページにある [**Slow Query**](/tidb-cloud/tune-performance.md#slow-query) タブで確認できます。 + + TiDB Cloud では、スロークエリログの出力をより柔軟に制御できるようになりました。[`tidb_slow_log_rules`](https://docs.pingcap.com/tidbcloud/system-variables/?plan=premium#tidb_slow_log_rules) システム変数を使用すると、`Query_time`、`Digest`、`Mem_max`、`KV_total` などの条件に基づいて、セッションレベルおよび SQL レベルで多次元のスロークエリログ出力ルールを定義できます。`WRITE_SLOW_LOG` ヒントを使用すると、特定の SQL 文に対してスロークエリログ出力を強制できます。これにより、スロークエリログをより柔軟かつきめ細かく制御できます。 + + 詳細は、[ドキュメント](https://docs.pingcap.com/tidbcloud/config-slow-query-trigger-rules/?plan=premium)を参照してください。 + +### SQL {#sql} + +* `FOR UPDATE OF` 句でのテーブルエイリアスの使用をサポートしました [#63035](https://github.com/pingcap/tidb/issues/63035) @[cryo-zd](https://github.com/cryo-zd) + + このリリース以前は、`SELECT ... FOR UPDATE OF
    ` 文のロック句でテーブルエイリアスを参照すると、TiDB がそのエイリアスを正しく解決できず、エイリアスが有効であっても `table not exists` エラーを返すことがありました。 + + TiDB は `FOR UPDATE OF` 句でのテーブルエイリアスの使用をサポートします。TiDB は、エイリアス付きテーブルを含む `FROM` 句からロック対象を正しく解決できるようになり、行ロックが期待どおりに有効になります。これにより、MySQL 互換性が向上し、テーブルエイリアスを使用するクエリにおける `SELECT ... FOR UPDATE OF` 文の安定性と信頼性が高まります。 + + 詳細は、[ドキュメント](https://docs.pingcap.com/tidbcloud/sql-statement-select/?plan=premium)を参照してください。 + +* インデックスストレージと DML メンテナンスのオーバーヘッドを削減する部分インデックスをサポートしました [#62664](https://github.com/pingcap/tidb/issues/62664) [#62761](https://github.com/pingcap/tidb/issues/62761) [#62758](https://github.com/pingcap/tidb/issues/62758) [#63447](https://github.com/pingcap/tidb/issues/63447) [#64344](https://github.com/pingcap/tidb/issues/64344) @[YangKeao](https://github.com/YangKeao) @[winoros](https://github.com/winoros) @[wjhuang2016](https://github.com/wjhuang2016) + + TiDB は部分インデックスをサポートするようになりました。部分インデックスは、インデックスの `WHERE` 句で定義された述語を満たす行だけをインデックス化します。部分インデックスは、`CREATE INDEX ... WHERE ...`、`ALTER TABLE ... ADD INDEX ... WHERE ...`、または `CREATE TABLE` 内のインデックス定義を使用して作成できます。 + + 部分インデックスは、特定の条件に基づく行のサブセットを頻繁にクエリする場合や、特定の条件下でのみ適用される一意制約が必要な場合に有用です。述語の対象外となる行はインデックスに書き込まれないため、部分インデックスはインデックスストレージの削減に役立ち、`INSERT`、`UPDATE`、`DELETE` 操作時のインデックスメンテナンスのオーバーヘッドも低減できます。 + + 部分インデックスを効果的に使用するには、一般的なクエリのフィルターに一致する述語を定義してください。TiDB は、クエリ述語が部分インデックスの述語に一致するか、それを含意する場合にのみ部分インデックスを選択します。現在、部分インデックスの述語では、基本的な比較演算子（`=`, `!=`, `<`, `<=`, `>`, `>=`）、`IS NULL`、`IS NOT NULL`、および定数値を使った `IN` 述語をサポートしています。 + + 詳細は、[ドキュメント](https://docs.pingcap.com/tidbcloud/sql-statement-create-index/?plan=premium#partial-indexes)を参照してください。 + +## 互換性の変更 {#compatibility-changes} + +### MySQL 互換性 {#mysql-compatibility} + +* Dumpling は、更新された MySQL バイナリログ命名に対応することで、MySQL 8.4 からのデータエクスポートをサポートします。[#53082](https://github.com/pingcap/tidb/issues/53082) @[dveeden](https://github.com/dveeden) + +## 改善 {#improvements} + +- Parquet ファイルの解析メカニズムを強化し、Parquet 形式データのインポート性能を向上させました [#62906](https://github.com/pingcap/tidb/issues/62906) @[joechenrh](https://github.com/joechenrh) +- `tidb_analyze_column_options` のデフォルト値を `ALL` に変更し、デフォルトで全カラムの統計情報を収集するようにしました [#64992](https://github.com/pingcap/tidb/issues/64992) @[0xPoe](https://github.com/0xPoe) +- 特定の JOIN シナリオで増分処理を使用することで `IndexHashJoin` 演算子の実行ロジックを最適化し、一度に大量のデータをロードすることを回避して、メモリ使用量を大幅に削減し、パフォーマンスを向上させました [#63303](https://github.com/pingcap/tidb/issues/63303) @[ChangRui-Ryan](https://github.com/ChangRui-Ryan) +- グローバルシステム変数 `tidb_enable_batch_query_region` を追加し、TiDB が PD に対してバッチ化されたリージョン問い合わせを使用するかどうかを制御できるようにしました。これにより、リージョン情報取得の効率が向上します。この変数はデフォルトで無効です [#58439](https://github.com/pingcap/tidb/issues/58439) [#8690](https://github.com/tikv/pd/issues/8690) @[JmPotato](https://github.com/JmPotato) +- コスト見積もりの前に無関係なインデックスをプルーニングすることで、多数のインデックスを持つテーブルに対するクエリのオプティマイザ性能を向上させ、クエリ計画時間を短縮し、不要な全範囲の範囲外見積もりを回避します [#63856](https://github.com/pingcap/tidb/issues/63856) @[terry1purcell](https://github.com/terry1purcell) @[qw4990](https://github.com/qw4990) +- 一致するプレフィックスインデックス上の `ORDER BY ... LIMIT/OFFSET` クエリに対する部分順序付きインデックス最適化をサポートしました。`tidb_opt_partial_ordered_index_for_topn` を `COST` に設定すると、TiDB はインデックスの部分順序性を利用してフルテーブルスキャンを削減し、`TOPN` クエリのパフォーマンスを向上できます [#63280](https://github.com/pingcap/tidb/issues/63280) [#65813](https://github.com/pingcap/tidb/issues/65813) [#66338](https://github.com/pingcap/tidb/issues/66338) @[elsa0520](https://github.com/elsa0520) @[xzhangxian1008](https://github.com/xzhangxian1008) @[winoros](https://github.com/winoros) +- ローカルインデックスを持つ高度にパーティション化されたテーブル上の `IndexLookUp` クエリにおけるコプロセッサーリクエストのバーストを緩和し、クエリの安定性を向上させ、性能スパイクを低減しました [#67545](https://github.com/pingcap/tidb/issues/67545) @[gengliqi](https://github.com/gengliqi) +- 実行中の不要な式バッファ割り当てを削減することで、`INSERT ... ON DUPLICATE KEY UPDATE` 文の CPU およびメモリ使用量を最適化しました [#65003](https://github.com/pingcap/tidb/issues/65003) @[windtalker](https://github.com/windtalker) +- タイムスタンプ進行および Leader 選出のロジックを最適化しました [#9981](https://github.com/tikv/pd/issues/9981) @[bufferflies](https://github.com/bufferflies) diff --git a/tidb-cloud/set-up-private-endpoint-connections.md b/tidb-cloud/set-up-private-endpoint-connections.md index 33e90a9bdc1b1..56bfdb29b16b8 100644 --- a/tidb-cloud/set-up-private-endpoint-connections.md +++ b/tidb-cloud/set-up-private-endpoint-connections.md @@ -29,11 +29,11 @@ AWS PrivateLink を利用することで、エンドポイント接続は安全 ## 制限 {#restrictions} - プライベートエンドポイントを作成できるのは、`Organization Owner`または`Project Owner`ロールを持つユーザーのみです。 -- プライベートエンドポイントと接続先の TiDB クラスターは同じリージョンに配置されている必要があります。 +- デフォルトでは、プライベートエンドポイントと接続先の TiDB クラスターは同じリージョンに配置されている必要があります。別のリージョンから接続するには、対象のノードグループにそのリージョンを許可します。詳細については、[プライベートエンドポイント経由でリージョン間接続を使用する](#use-cross-region-connections-over-a-private-endpoint)を参照してください。 ほとんどのシナリオでは、VPC ピアリングではなくプライベートエンドポイント接続を使用することをお勧めします。ただし、以下のシナリオでは、プライベートエンドポイント接続ではなく VPC ピアリングを使用する必要があります。 -- 高可用性を実現するために、ソースTiDBクラスターからターゲットTiDBクラスターへリージョンをまたいでデータをレプリケートするために、 [TiCDC](https://docs.pingcap.com/tidb/stable/ticdc-overview)クラスターを使用しています。現在、プライベートエンドポイントはリージョン間接続をサポートしていません。 +- 高可用性のために、ソースTiDBクラスターからターゲットTiDBクラスターへリージョンをまたいでデータをレプリケートするために、 [TiCDC](https://docs.pingcap.com/tidb/stable/ticdc-overview)クラスターを使用していますが、組織でリージョン間接続が有効になっていません。リージョン間接続が有効で、ソースリージョンが対象のノードグループに対して許可されている場合は、代わりにプライベートエンドポイントを使用できます。詳細については、[プライベートエンドポイント経由でリージョン間接続を使用する](#use-cross-region-connections-over-a-private-endpoint)を参照してください。 - TiCDC クラスターを使用してダウンストリームクラスター (Amazon Aurora、MySQL、Kafka など) にデータをレプリケートしていますが、エンドポイントサービスを独自に維持することはできません。 - PD または TiKV ノードに直接接続しています。 @@ -69,6 +69,7 @@ AWS VPC設定でDNSホスト名とDNS解決の両方が有効になっている > > - IPv6 経由でクラスターに接続する場合は、追加の IPv6 設定について[プライベートエンドポイント経由で IPv6 接続を使用する](#use-ipv6-connectivity-over-a-private-endpoint)を参照してください。 > - 2023 年 3月 28日以降に作成されたTiDB Cloud Dedicated クラスターごとに、クラスターの作成後 3 ～ 4分後に対応するエンドポイントサービスが自動的に作成されます。 +> - リージョン間接続の場合、生成されるコマンド内の`${your_region}`は、クラスターのリージョンとは異なる、VPC のリージョンである必要があります。AWS CLI を使用する場合は、`--service-region ${your_cluster_region}`も渡します。詳細については、[プライベートエンドポイント経由でリージョン間接続を使用する](#use-cross-region-connections-over-a-private-endpoint)を参照してください。 `TiDB Private Link Service is ready`メッセージが表示された場合、対応するエンドポイントサービスは準備完了です。エンドポイントを作成するには、以下の情報を提供してください。 @@ -79,12 +80,12 @@ AWS VPC設定でDNSホスト名とDNS解決の両方が有効になっている aws ec2 create-vpc-endpoint --vpc-id ${your_vpc_id} --region ${your_region} --service-name ${your_endpoint_service_name} --vpc-endpoint-type Interface --subnet-ids ${your_application_subnet_ids} ``` -次に、AWS CLI または[AWS マネジメントコンソール](https://aws.amazon.com/console/)を使用して AWS インターフェイスエンドポイントを作成できます。 +次に、AWS CLI または[AWS マネジメントコンソール](https://aws.amazon.com/console/)を使用して AWS インターフェースエンドポイントを作成できます。
    -AWS CLI を使用して VPC インターフェイスエンドポイントを作成するには、次の手順を実行します。 +AWS CLI を使用して VPC インターフェースエンドポイントを作成するには、次の手順を実行します。 1. 生成されたコマンドをコピーしてターミナルで実行します。 2. 作成した VPC エンドポイント ID を記録します。 @@ -98,7 +99,7 @@ AWS CLI を使用して VPC インターフェイスエンドポイントを作
    -AWS マネジメントコンソールを使用して VPC インターフェイスエンドポイントを作成するには、次の手順を実行します。 +AWS マネジメントコンソールを使用して VPC インターフェースエンドポイントを作成するには、次の手順を実行します。 1. [AWS マネジメントコンソール](https://aws.amazon.com/console/)にサインインし、 [https://console.aws.amazon.com/vpc/](https://console.aws.amazon.com/vpc/)で Amazon VPC コンソールを開きます。 @@ -156,9 +157,13 @@ AWS でプライベート DNS を有効にします。AWS CLI または AWS マ AWS CLI を使用してプライベート DNS を有効にするには、 **Create Private Endpoint Connection**ページから次の`aws ec2 modify-vpc-endpoint`コマンドをコピーし、AWS CLI で実行します。 ```bash -aws ec2 modify-vpc-endpoint --vpc-endpoint-id ${your_vpc_endpoint_id} --private-dns-enabled +aws ec2 modify-vpc-endpoint --vpc-endpoint-id ${your_vpc_endpoint_id} --region ${your_vpc_region} --private-dns-enabled ``` +> **Note:** +> +> `${your_vpc_region}`は、VPC エンドポイントが作成されるリージョンです。リージョン間接続の場合、これは TiDB クラスターのリージョンではなく、VPC エンドポイントのリージョンです。誤ったリージョンでコマンドを実行すると、`InvalidVpcEndpointId.NotFound`で失敗します。 + または、クラスターの**Networking**ページでコマンドを見つけることもできます。プライベートエンドポイントを探し、 **Action**列の**...** > **Enable DNS**をクリックします。
    @@ -248,6 +253,50 @@ IP プロトコルタイプは、クラスターの作成後にのみ変更で その後、[ステップ3](#step-3-create-a-private-endpoint-connection) から [ステップ5](#step-5-connect-to-your-tidb-cluster) までを完了して、プライベートエンドポイント接続を作成し、IPv6 経由でクラスターに接続します。 +## プライベートエンドポイント経由でリージョン間接続を使用する {#use-cross-region-connections-over-a-private-endpoint} + +デフォルトでは、プライベートエンドポイントと、それが接続する TiDB Cloud Dedicated クラスターは、同じ AWS リージョン内に存在する必要があります。TiDB Cloud Dedicated はリージョン間接続もサポートしており、これにより、あるリージョンで VPC エンドポイントを作成し、別のリージョンのクラスターに接続できます。接続文字列と DNS の使用方法は、同一リージョン接続の場合と同じです。 + +> **Note:** +> +> 現在、リージョン間接続機能はリクエストベースでのみ利用できます。この機能を利用するには、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) に連絡し、組織 ID を提供してください。 + +TiDB Cloud では、[TiDB ノードグループ](/tidb-cloud/tidb-node-group-management.md)ごとに接続スコープを個別に設定できます。別のリージョンからクラスターに接続するには、対象のノードグループにそのリージョンを許可してから、自分のリージョンに AWS インターフェースエンドポイントを作成します。 + +### ステップ1. VPC エンドポイントのリージョンを許可する {#step-1-allow-the-region-of-your-vpc-endpoint} + +1. 組織の [**My TiDB**](https://tidbcloud.com/tidbs) ページに移動し、対象クラスターの名前をクリックして概要ページに移動してから、左側のナビゲーションペインで **Settings** > **Networking** をクリックします。 +2. 各 TiDB Cloud Dedicated クラスターには、デフォルトの [TiDB ノードグループ](/tidb-cloud/tidb-node-group-management.md) があります。クラスターに複数のノードグループがある場合は、右上隅の **TiDB Node Group** リストから対象の TiDB ノードグループを選択します。 +3. **AWS Private Endpoints** セクションで、**Edit** をクリックします。 +4. **AWS Private Endpoints Connection Settings** ダイアログで、**Connection Scope** に **Cross-Region** を選択し、許可するリージョンを選択して、**Save** をクリックします。 + +設定が保存されると、許可されたリージョンが **AWS Private Endpoints** セクションの **Connection Scope** 領域に表示されます。 + +> **Note:** +> +> - 設定を保存しても、許可するリージョンが記録されるだけです。TiDB Cloud は更新を非同期に適用するため、表示された後でも許可されたリージョンの調整がまだ進行中である場合があります。次のステップで VPC エンドポイントを作成する前に、**Connection Scope** の更新が正常に完了するまで待ってください。そうしないと、リージョンがすでに表示されていても、エンドポイントの作成が失敗する可能性があります。更新が失敗した場合は、再試行するか、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) に連絡してください。 +> - リージョン間接続には料金が発生します。AWS は、許可した各リージョンごとではなく、少なくとも 1 つの接続済みインターフェースエンドポイントがある **active** なリモートリージョンごとに、サービスプロバイダーに課金します。VPC エンドポイントの所有者として、標準のエンドポイント時間料金とデータ処理使用量、およびリージョン間データ転送料金も課金されます。さらに、TiDB Cloud はリージョン間 PrivateLink サービス料金を請求します。詳細については、[AWS PrivateLink pricing](https://aws.amazon.com/privatelink/pricing/) と [TiDB Cloud Dedicated pricing details](https://www.pingcap.com/tidb-dedicated-pricing-details/) を参照してください。 +> - リージョンを削除したり、**Connection Scope** を **Current Region Only** に戻したりしても、そのリージョン内の既存の接続には影響しません。そこで新しいプライベートエンドポイントを作成できなくなるだけで、既存のエンドポイントは切断されないため、それらのエンドポイントが削除されるまで AWS の課金が継続する可能性があります。許可されなくなったリージョン内の接続には、**AWS Private Endpoints** リストで警告が表示されます。 + +### ステップ2. リージョン間 AWS インターフェースエンドポイントを作成する {#step-2-create-a-cross-region-aws-interface-endpoint} + +[ステップ2. AWSインターフェースエンドポイントを作成する](#step-2-create-an-aws-interface-endpoint) の説明に従って AWS インターフェースエンドポイントを作成し、次の点に注意してください。 + +- エンドポイントは、TiDB Cloud Dedicated クラスターのリージョンとは異なる、アプリケーションが実行される AWS リージョンに作成します。AWS マネジメントコンソールでは、**Enable Cross Region endpoint** を選択し、**Service Region** を TiDB Cloud Dedicated クラスターのリージョンに設定します。 +- **Subnets** では、リージョン間アクセスをサポートするアベイラビリティゾーン内のサブネットを選択します。リージョン内のすべてのアベイラビリティゾーンがリージョン間アクセスをサポートしているわけではありません。サブネットがサポートされていないアベイラビリティゾーンにある場合、作成は失敗し、サポートされているアベイラビリティゾーンを一覧表示するエラーが表示されるため、代わりに一覧に表示されたアベイラビリティゾーン内のサブネットを選択できます。 +- リージョン間エンドポイントを作成する前に、呼び出し元の ID ポリシーと適用される Service Control Policy で `vpce:AllowMultiRegion` が許可されていることを確認してください。 +- AWS CLI を使用する場合は、`--service-region ${your_cluster_region}` でクラスターのリージョンを渡します。 + + ```bash + aws ec2 create-vpc-endpoint --vpc-id ${your_vpc_id} --region ${your_vpc_region} --service-name ${your_endpoint_service_name} --vpc-endpoint-type Interface --subnet-ids ${your_application_subnet_ids} --service-region ${your_cluster_region} + ``` + +次に、[ステップ3. プライベートエンドポイント接続を作成する](#step-3-create-a-private-endpoint-connection) から [ステップ5. TiDBクラスターに接続する](#step-5-connect-to-your-tidb-cluster) までを完了して、プライベートエンドポイント接続を作成し、別のリージョンからクラスターに接続します。 + +> **Note:** +> +> VPC エンドポイントを作成するリージョンが対象ノードグループの許可リージョンでない場合、プライベートエンドポイント接続を作成できず、TiDB Cloud はエラーを報告します。 + ## トラブルシューティング {#troubleshooting} ### プライベートDNSを有効にした後、プライベートエンドポイント経由でTiDBクラスターに接続できません。なぜですか？ {#i-cannot-connect-to-a-tidb-cluster-via-a-private-endpoint-after-enabling-private-dns-why} diff --git a/tidb-cloud/stream-data-overview.md b/tidb-cloud/stream-data-overview.md new file mode 100644 index 0000000000000..9f620bdd61531 --- /dev/null +++ b/tidb-cloud/stream-data-overview.md @@ -0,0 +1,25 @@ +--- +title: データをストリーミングする +summary: Changefeed や Data Pipeline を含む、TiDB Cloud からダウンストリームシステムへデータ変更をストリーミングするためのオプションについて説明します。 +--- + +# データをストリーミングする + +TiDB Cloud は、TiDB Cloud インスタンスからダウンストリームシステムへデータ変更を継続的にストリーミングできます。データをストリーミングするために、次のオプションを提供しています。 + +- **Changefeed**: Apache Kafka、MySQL、TiDB Cloud、クラウドストレージなどのダウンストリームシステムに増分の行変更をストリーミングします。 +- **Data Pipeline**: 選択したデータの完全なスナップショットをエクスポートし、その後、行変更を TiDB Cloud Lake に継続的にレプリケートします。 + +## Changefeed {#changefeed} + +changefeed は、TiDB Cloud からダウンストリームシステムへ増分データ変更をストリーミングします。増分変更のみを継続的にレプリケートする必要があり、かつダウンストリームシステムが増分イベントを処理できる場合に使用します。 + +TiDB Cloud コンソールの **Changefeed** ページで changefeed を作成および管理できます。詳細は、[変更フィード](/tidb-cloud/changefeed-overview.md) を参照してください。 + +## Data Pipeline (PREVIEW) {#data-pipeline-preview} + +Data Pipeline は、TiDB Cloud インスタンスから TiDB Cloud Lake に完全なデータと増分変更をレプリケートします。Amazon S3 や Alibaba Cloud OSS などの外部 stage を使用してソースと宛先の間でデータをバッファリングするため、信頼性が向上し、コストとレイテンシーを制御できます。詳細は、[Data Pipeline](/tidb-cloud/data-pipeline.md) を参照してください。 + +> **Note:** +> +> TiDB Cloud コンソールの Data Pipeline 機能は現在プライベートプレビュー中で、リクエストに応じて利用できます。この機能をリクエストするには、[TiDB Cloud コンソール](https://tidbcloud.com) の右下にある **?** をクリックし、**Support Tickets** をクリックして [ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals) に移動します。チケットを作成し、**Description** フィールドに "Apply for `Data Pipeline to TiDB Cloud Lake`" と入力して、**Submit** をクリックします。 diff --git a/tidb-cloud/tidb-cloud-billing.md b/tidb-cloud/tidb-cloud-billing.md index cd849eedfcca7..2deba311353b1 100644 --- a/tidb-cloud/tidb-cloud-billing.md +++ b/tidb-cloud/tidb-cloud-billing.md @@ -103,20 +103,13 @@ TiDB Cloud Lake の料金は、ウェアハウス、ストレージ、クラウ > **Note:** > -> **Bills** データと **Cost Explorer** または **Usage Details** の CSV ダウンロード内のデータは、異なる粒度レベルで処理および表示されます。**Bills** データは月次精算用に計算される一方、**Cost Explorer** と **Usage Details** の CSV ダウンロードでは、日、サービス、プロジェクト、クラスター、またはリソースごとのような、より細かい内訳が提供されます。その結果、異なる集計レベルでの丸めにより、合計値がわずかに異なる場合があります。 -> -> **Cost Explorer** と **Usage Details** の CSV ダウンロードは、使用量とコストの分析を目的としています。これらのデータソースに差異がある場合、請求書に表示される金額が最終的に支払うべき金額です。 +> - **Bills** データと **Cost Explorer** または **Usage Details** の CSV ダウンロード内のデータは、異なる粒度レベルで処理および表示されます。**Bills** データは月次精算用に計算される一方、**Cost Explorer** と **Usage Details** の CSV ダウンロードでは、日、サービス、プロジェクト、クラスター、またはリソースごとのような、より細かい内訳が提供されます。その結果、異なる集計レベルでの丸めにより、合計値がわずかに異なる場合があります。 +> - **Cost Explorer** と **Usage Details** の CSV ダウンロードは、使用量とコストの分析を目的としています。これらのデータソースに差異がある場合、請求書に表示される金額が最終的に支払うべき金額です。 ストレージに関連する請求の説明は次のとおりです。 - **Row-based storage**: TiDB テーブルはデフォルトで行ベースのストレージを使用し、データは **TiKV** に保存されます。 -- **Row-based storage with IA**: Infrequent Access (IA) を使用する行ベースのストレージでは、データは **外部オブジェクトストレージ** に保存され、アクセス頻度は低いもののオンラインクエリで利用可能である必要があるデータ向けに設計されています。 - - > **Note:** - > - > Infrequent Access は現在プライベートプレビューであり、リクエストがあった場合にのみ利用できます。 - - **Columnar storage**: 列指向ストレージは **TiFlash** エンジンによって提供されます。 - **Dual-layer encryption**: 行ベースのストレージと列指向ストレージはどちらもデュアルレイヤー暗号化をサポートしています。このメカニズムは、2つの独立した暗号化レイヤーでデータを保護し、1つのレイヤーが侵害された場合でもデータが保護された状態を維持できるようにします。 diff --git a/tidb-cloud/tiered-storage-faq.md b/tidb-cloud/tiered-storage-faq.md new file mode 100644 index 0000000000000..1c9610054b3ec --- /dev/null +++ b/tidb-cloud/tiered-storage-faq.md @@ -0,0 +1,85 @@ +--- +title: 階層型ストレージに関する FAQ +summary: TiDB Cloud Premium と BYOC における階層型ストレージの一般的な質問について、DML、レプリカ、オブジェクトストレージ障害などを含めて説明します。 +--- + +# 階層型ストレージに関する FAQ + +このドキュメントでは、Infrequent Access (IA) ストレージに関する一般的な質問に回答します。内容には、DML の動作、レプリカの扱い、変換の進行状況、キャッシュ設定、オブジェクトストレージ障害などの運用上の影響が含まれます。 + +> **Note:** +> +> 階層型ストレージは、{{{ .premium }}} と {{{ .byoc }}} で **プライベートプレビュー** として提供されており、デフォルトでは無効です。利用するには、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) に連絡して、インスタンスで有効化してもらう必要があります。このページで説明している動作は、現在のプレビュー実装に基づくものであり、一般提供 (GA) 前に変更される可能性があります。 + +## IA テーブルで `UPDATE`/`DELETE` を実行できますか？ {#can-ia-tables-execute-update-delete} + +はい。`UPDATE` 操作では、まず対応するデータをオブジェクトストレージから IA キャッシュにロードし、変更を実行してから、新しい SST ファイルを書き込みます。これは通常の `UPDATE` と同じフローです。パフォーマンスはコールドリードの影響を受けます。 + +## IA テーブルの TiFlash レプリカも IA に設定できますか？ {#can-tiflash-replicas-of-ia-tables-be-set-to-ia} + +いいえ。TiFlash は、元テーブルの IA 属性には従いません。 + +## オブジェクトストレージで障害が発生した場合、IA テーブルはどうなりますか？ {#what-happens-to-ia-tables-when-the-object-storage-experiences-an-outage} + +IA テーブルは影響を受け、利用できなくなります。これは、すべてのデータがリモートに存在し、読み取りリクエストがオブジェクトストレージからの取得を必要とするためです。さらに、オブジェクトストレージの帯域幅が飽和すると、IA の読み書き性能にも影響します。 + +## IA を設定する前に、どのデータがコールドかをシステムで判別できますか？ {#can-the-system-tell-me-which-data-is-cold-before-i-set-ia} + +TiDB には、コールドデータ / ホットデータを検出する組み込みツールはありません。データアクセスパターンは、自身の業務知識に基づいて評価する必要があります。一般的な目安として、時間でパーティション分割されたテーブルでは、古いパーティションほどアクセス頻度が低くなる傾向があります。 + +## データがコールドストレージ (IA 階層) に保存される場合、3 つのレプリカすべてが保存されますか？ それとも 1 コピーだけですか？ {#when-data-is-stored-in-cold-storage-ia-tier-are-all-three-replicas-stored-or-just-one-copy} + +Amazon S3 に保存されるのは 1 コピーだけで、3 つのレプリカは同じオブジェクトを共有します。 + +クラウドストレージエンジンのアーキテクチャでは、SST/blob データファイルは、もともとオブジェクトストレージ (S3/DFS) 上に 1 コピーしかありません。ファイルはフラッシュまたはコンパクションによって 1 回だけアップロードされ、S3 キーにはノードやレプリカの情報は含まれず、3 つの Raft レプリカは Raft によって複製される ChangeSet を通じて同じファイル ID を参照します。3 レプリカの仕組みが適用されるのは、Raft ログ、メタデータ、および各ノードのローカルキャッシュのみであり、オブジェクトストレージ上のデータには適用されません。 + +**コストへの影響**: S3 上のストレージ使用量は常にデータサイズの約 1 倍であり、レプリカ数に応じて増えることはありません。IA 階層によって削減されるのは各ノードのローカルディスク使用量であり、データの耐久性はレプリカ数とは独立して、オブジェクトストレージ自体によって保証されます。 + +## ストレージクラスの変換にはどれくらい時間がかかりますか？ 進行状況はどう追跡できますか？ {#how-long-does-a-storage-class-conversion-take-and-how-do-i-track-its-progress} + +変換の進行中に `SHOW STORAGE_CLASS TRANSITIONS` を実行してください。完了率は `PROGRESS` で確認でき、値は `0` から `1` の範囲です。あるいは、`COMPLETED_REPLICAS` と `TOTAL_REPLICAS` を比較することでも確認できます。経過時間 (秒) は `DURATION` で確認できます。進行状況は 10 秒ごとに収集されるため、これらの値はリアルタイムではありません。 + +変換時間は主にデータ量と変換方向に依存します。テーブルを IA に設定する場合はメタデータの更新のみで済むため高速ですが、Standard に戻す場合はすべてのデータをオブジェクトストレージからダウンロードする必要があるため、はるかに時間がかかります。自身のクラスターで所要時間を見積もるには、`mysql.tidb_storage_class_transition_history` 内の、`state = 'COMPLETED'` で絞り込んだ過去の類似変換の `duration` を問い合わせてください。 + +完全なカラムリファレンスとクエリ例については、[階層型ストレージの可観測性](/tidb-cloud/tiered-storage-observability.md) を参照してください。 + +## 変換が `RUNNING` のままで、進行状況が進まない場合はどうすればよいですか？ {#what-if-a-conversion-stays-in-running-and-the-progress-does-not-increase} + +変換が停止している原因として、TiKV のローリング再起動、一時的なリソース不足、短時間のオブジェクトストレージ利用不可などのシステム例外が考えられます。停止しているケースと正常進行中のケースは、`DURATION` と `COMPLETED_REPLICAS` をあわせて確認することで見分けられます。両方が増え続けている場合、変換は正常に進行しており、単にデータ量が大きいだけです。 + +停止した変換を自分で解消することはできません。[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) に連絡してください。問題が解決すると、追加の操作を行わなくても変換は継続されます。 + +## 前回の変換が完了する前に、逆方向の `ALTER TABLE` を実行するとどうなりますか？ {#what-happens-if-i-run-the-reverse-alter-table-before-the-previous-conversion-finishes} + +前回の変換は無効になります。`SHOW STORAGE_CLASS TRANSITIONS` では、そのテーブルまたはパーティションの行が新しい変換に置き換えられます。方向が変更され、進行状況は再び最初からカウントされます。 + +`mysql.tidb_storage_class_transition_history` にある無効化された変換の履歴レコードは、`state = 'SUPERSEDED'` に更新されます。その `finish_time` は新しい変換の開始時刻となり、`completed_replicas` と `total_replicas` は無効化される直前に観測された最後の値になります。変換を逆転させても、必ずしも完了済みの作業がすべて破棄されるわけではありません。すでに新しいターゲットに一致しているリージョンはスキップでき、該当する場合は既存のローカルファイルを再利用できます。 + +変換時間の統計を計算する場合は、`state = 'COMPLETED'` で絞り込んでください。`SUPERSEDED` レコードの `duration` は、完全な変換時間ではなく、無効化されるまでの時間だけを表します。 + +## IA データのローカルキャッシュを増やせますか？ また、その場合コストは増えますか？ {#can-i-increase-the-local-cache-for-ia-data-and-does-it-cost-more} + +はい。ただし、キャッシュレベルの調整には、階層型ストレージのプライベートプレビュー有効化に加えて別途許可リストへの登録が必要です。まず [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) に連絡して有効化してください。その後、**Overview** > **Capacity** > **Update Capacity** > **Storage Acceleration** で、より高い IA キャッシュレベルを選択できます。利用可能なレベルは **Economy**、**Default**、**Balanced**、**Deep** です。高いレベルほど、より多くの IA データをローカルディスクにキャッシュするため、コールドリード性能が向上します。 + +コストは増えます。{{{ .premium }}} では、各キャッシュレベルに IA ストレージ換算係数があり、**Economy** の 0.9x から **Deep** の 1.8x まで設定されています。この係数は、請求額計算時に報告される IA ストレージ使用量に適用されます。{{{ .byoc }}} では係数は適用されません。追加リソースは自身のクラウドアカウント内でプロビジョニングされ、クラウドプロバイダーから課金されます。この変更はホットアップデートであり、再起動は不要です。各レベルの係数については、[TiDB Cloud課金](/tidb-cloud/tidb-cloud-billing.md) を参照してください。 + +なお、キャッシュレベルは個々の論理インスタンスではなく、基盤となる TiKV 物理クラスターに適用されます。アカウントで同じ物理クラスター上に複数の論理インスタンスを実行している場合、1 つのインスタンスでの変更は他のインスタンスにも適用されます。 + +## キャッシュレベルやセグメントサイズを変更すると、オブジェクトストレージ内のデータは書き換えられますか？ {#does-changing-the-cache-level-or-the-segment-size-rewrite-data-in-object-storage} + +いいえ。キャッシュレベルの変更は、ローカルキャッシュに保持するデータ量を調整するだけであり、ホットアップデートとして反映されます。 + +セグメントサイズ (`kvengine.ia.segment-size`、{{{ .byoc }}} でのみ利用可能) は、オブジェクトストレージからデータを読み取り、ローカルキャッシュに書き込む際の粒度を変更するだけです。SST ファイルはオブジェクトストレージ内で 1 つのオブジェクト全体として保存され、セグメント単位で構成されているわけではないため、オブジェクトストレージ内の内容が書き換えられることはありません。このパラメータは起動時にのみ有効になるため、TiKV ノードのローリング再起動が必要です。その後、ローカルキャッシュは新しい粒度で徐々に再構築されます。 + +## テーブルを IA のままにすべきかどうかは、どう判断すればよいですか？ {#how-do-i-decide-whether-a-table-should-stay-in-ia} + +ステートメントサマリーテーブル内の `IA_EXEC_COUNT` と `EXEC_COUNT` を比較して、IA データを読み取る実行の割合を確認し、クラスター全体の **IA Cache Hit Rate** パネルも確認してください。 + +- テーブルにアクセスする大半のステートメントでコールドリード比率が高いままであれば、キャッシュヒット率が IA に対して低すぎます。テーブルを Standard に戻すか、キャッシュレベルを上げることを検討してください。 +- コールドリード比率が低くても、一部のステートメントが毎回大量のデータを読み取る場合は、テーブル全体を Standard に戻すのではなく、それらのステートメントを最適化してください。 + +## IA キャッシュヒット率はどこで確認できますか？ {#where-can-i-see-the-ia-cache-hit-rate} + +Cloud Console で **Monitoring** > **Metrics** > **Instance Overview** に移動し、**IA Cache Performance** パネルグループを開いてください。ここには、キャッシュヒット率、キャッシュミス率、リモート読み取りセグメントの数とデータ量、リモート読み取り待機時間が含まれます。 + +ヒット率が 85% を下回ると、黄色のインジケーターが表示されます。クラスターに IA テーブルがない場合、パネルには **No IA data** と表示されます。 diff --git a/tidb-cloud/tiered-storage-guide.md b/tidb-cloud/tiered-storage-guide.md new file mode 100644 index 0000000000000..cb0ed6d98ee17 --- /dev/null +++ b/tidb-cloud/tiered-storage-guide.md @@ -0,0 +1,346 @@ +--- +title: 階層型ストレージの設定と管理 +summary: TiDB Cloud Premium または BYOC で、DDL、パーティションセレクター、ベストプラクティスを含む階層型ストレージを設定および管理する方法を学びます。 +--- + +# 階層型ストレージの設定と管理 + +このドキュメントでは、ストレージクラス設定、パーティションセレクター、および推奨される運用プラクティスを含む、Infrequent Access (IA) ストレージの設定と管理方法について説明します。 + +> **Note:** +> +> 階層型ストレージは、{{{ .premium }}} および {{{ .byoc }}} 向けに **プライベートプレビュー** として提供されており、デフォルトでは無効になっています。使用するには、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) に連絡して、インスタンスで有効化してもらってください。このページで説明している動作は、現在のプレビュー実装に基づくものであり、一般提供 (GA) 前に変更される可能性があります。 + +## 使用方法 {#how-to-use} + +このセクションでは、ストレージクラス設定、パーティションセレクター、および推奨される運用プラクティスを含む、IA ストレージの設定と管理方法について説明します。 + +### ストレージクラスのサポートマトリクス {#storage-class-support-matrix} + +このセクションでは、サポートされるストレージクラス値、テーブルタイプ、およびインデックスや関連オブジェクトの継承ルールについて説明します。 + +#### ストレージクラス値 {#storage-class-values} + +| 値 | 意味 | デフォルト | +|-|-|-| +| `Standard` | ローカルのホットストレージ。すべてのデータがローカルディスク上に存在 | はい | +| `IA` | リモートのコールドストレージ。すべてのデータはオブジェクトストレージにあり、ローカルではオンデマンドキャッシュされる | いいえ | + +値では大文字と小文字は区別されません。 + +#### サポートされるテーブルタイプ {#supported-table-types} + +| テーブルタイプ | IA サポート | 注記 | +|-|-|-| +| 通常の非パーティションテーブル | サポート対象 | `STORAGE_CLASS` の糖衣構文または `ENGINE_ATTRIBUTE` を使用 | +| Range パーティション | サポート対象 | `ENGINE_ATTRIBUTE` を使用する必要があります | +| Range Columns パーティション | サポート対象 | `ENGINE_ATTRIBUTE` を使用する必要があります | +| List パーティション | サポート対象 | `ENGINE_ATTRIBUTE` を使用する必要があります | +| List Columns パーティション | サポート対象 | `ENGINE_ATTRIBUTE` を使用する必要があります | +| Hash パーティション | **サポート対象外** | — | +| Key パーティション | **サポート対象外** | — | + +#### インデックスおよび関連オブジェクトのストレージタイプ継承ルール {#storage-type-inheritance-rules-for-indexes-and-related-objects} + +| オブジェクト | 継承ルール | +|-|-| +| 通常テーブルのインデックス | テーブルと同じ | +| パーティションテーブルの Local Index | 所有するパーティションと同じ | +| パーティションテーブルの Global Index | テーブルレベル設定と同じ | +| TiFlash | **テーブルのストレージ設定には従いません** | + +### 通常テーブルの DDL {#regular-table-ddl} + +このセクションでは、通常の（非パーティション）テーブルに対して IA ストレージを設定する方法を説明します。 + +#### 作成時に指定する {#specify-at-create-time} + +糖衣構文（推奨）: + +```sql +CREATE TABLE t_ia ( + id BIGINT PRIMARY KEY, + created_at DATETIME NOT NULL, + payload VARCHAR(256) NOT NULL +) ENGINE=InnoDB STORAGE_CLASS='IA'; +``` + +`ENGINE_ATTRIBUTE` を使用する方法: + +```sql +CREATE TABLE t_ia ( + id BIGINT PRIMARY KEY +) ENGINE_ATTRIBUTE='{"storage_class":"IA"}'; +``` + +**競合制約**: `STORAGE_CLASS` の糖衣構文と `ENGINE_ATTRIBUTE` の `storage_class` は、**同時に指定できません**。指定すると、システムはエラーを返して拒否します。 + +#### 既存テーブルを変更する {#modify-an-existing-table} + +```sql +-- Standard → IA +ALTER TABLE t1 STORAGE_CLASS='IA'; +ALTER TABLE t1 ENGINE_ATTRIBUTE='{"storage_class":"IA"}'; + +-- IA → Standard +ALTER TABLE t1 STORAGE_CLASS='STANDARD'; +ALTER TABLE t1 ENGINE_ATTRIBUTE='{"storage_class":"STANDARD"}'; +``` + +`ALTER` 操作ではすべてのデータへのアクセスが維持され、変換中も SQL による読み取りと書き込みを実行できます。 + +### パーティションテーブルの DDL {#partitioned-table-ddl} + +パーティションテーブルは `STORAGE_CLASS` の糖衣構文を**サポートしておらず**、`ENGINE_ATTRIBUTE` を使用する必要があります。 + +パーティション属性では、3 種類のセレクター（混在不可）に加えて、テーブルレベルのデフォルトをサポートします。 + +| 設定方法 | 構文 | 適用可能なパーティションタイプ | 目的 | +|-|-|-|-| +| テーブルレベルのデフォルト | `{"storage_class":"IA"}` | すべて | すべてのパーティションを一律に IA に設定 | +| パーティション名による指定 | `"names_in":["p1","p2"]` | すべて | パーティション名の正確なリストを指定 | +| 範囲による指定 | `"less_than":"2024-01-01"` | RANGE / RANGE COLUMNS | 境界値でパーティションをマッチ | +| リスト値による指定 | `"values_in":["1","2"]` | LIST / LIST COLUMNS | リスト値でパーティションをマッチ | + +#### 例 A: テーブルレベルで IA を設定し、特定のパーティションを Standard に上書きする {#example-a-table-level-ia-with-specific-partitions-overridden-to-standard} + +```sql +CREATE TABLE orders ( + order_id BIGINT NOT NULL, + created_at DATETIME NOT NULL, + PRIMARY KEY (order_id, created_at) +) ENGINE_ATTRIBUTE='{ + "storage_class":[ + {"tier":"ia"}, + {"tier":"standard","names_in":["p2025","p_future"]} + ] +}' +PARTITION BY RANGE (YEAR(created_at)) ( + PARTITION p2023 VALUES LESS THAN (2024), + PARTITION p2024 VALUES LESS THAN (2025), + PARTITION p2025 VALUES LESS THAN (2026), + PARTITION p_future VALUES LESS THAN MAXVALUE +); +``` + +結果: p2023 / p2024 → IA、p2025 / p_future → Standard。 + +#### 例 B: range セレクター {#example-b-range-selector} + +```sql +CREATE TABLE users ( + user_id BIGINT NOT NULL, + PRIMARY KEY (user_id) +) ENGINE_ATTRIBUTE='{ + "storage_class":[ + {"tier":"ia","less_than":"2000000"} + ] +}' +PARTITION BY RANGE (user_id) ( + PARTITION p0 VALUES LESS THAN (1000000), + PARTITION p1 VALUES LESS THAN (2000000), + PARTITION p2 VALUES LESS THAN (3000000), + PARTITION p3 VALUES LESS THAN MAXVALUE +); +``` + +結果: p0 / p1 → IA、p2 / p3 → Standard。 + +#### 例 C: list 値セレクター {#example-c-list-value-selector} + +```sql +CREATE TABLE order_status_log ( + log_id BIGINT NOT NULL, + status INT NOT NULL, + PRIMARY KEY (log_id, status) +) ENGINE_ATTRIBUTE='{ + "storage_class":[ + {"tier":"ia","values_in":["1","2"]} + ] +}' +PARTITION BY LIST (status) ( + PARTITION p_pending VALUES IN (1), + PARTITION p_paid VALUES IN (2), + PARTITION p_shipped VALUES IN (3), + PARTITION p_completed VALUES IN (4) +); +``` + +結果: p_pending / p_paid → IA、p_shipped / p_completed → Standard。 + +#### パーティションセレクタールール {#partition-selector-rules} + +- **優先順位**: パーティションレベルの設定は、テーブルレベルの設定を**上書き**します +- **相互排他**: 同じセレクター内で複数のマッチ方法（例: `"names_in"` と `"less_than"`）を同時に使用することはできません。使用するとエラーになります +- **前方互換性**: 後から追加された新しいパーティション（`ADD PARTITION` / `REORGANIZE PARTITION`）は、永続化されたストレージクラスルールに対して自動的に評価されます。一致するパーティションはその設定を継承します + +### 表示と監視 {#view-and-monitor} + +```sql +-- View DDL definition +SHOW CREATE TABLE t1\G + +-- View table-level storage type +SELECT TABLE_NAME, TIDB_STORAGE_CLASS +FROM INFORMATION_SCHEMA.TABLES +WHERE TABLE_SCHEMA = 'your_database' + AND TABLE_NAME = 'your_table'; + +-- View partition-level storage type +SELECT PARTITION_NAME, TIDB_STORAGE_CLASS +FROM INFORMATION_SCHEMA.PARTITIONS +WHERE TABLE_SCHEMA = 'your_database' + AND TABLE_NAME = 'your_table'; +``` + +#### IA ストレージ容量を監視する {#monitor-ia-storage-space} + +TiDB Cloud コンソールで確認します。 + +- パス: **Overview** > **Monitoring** > **Metrics** > **Instance Overview** (または **Overview** > **Core Metrics**) +- 新しいメトリクス: + - `Row-based IA Storage` — IA ストレージクラス内のデータのストレージ容量 + - `Row-based Standard Storage` — Standard テーブル容量の合計 +- 関係: `Row-based Storage` = `Row-based IA Storage` + `Row-based Standard Storage` + +> **Note:** +> +> IA ストレージ容量には、テーブルの L1 以降のより深いレイヤーのみが含まれます。memtable と L0 ファイルはローカルディスク上に残るため、IA ストレージとしてはカウントされません。理由については、[LSM-Tree の書き込みパス](/tidb-cloud/tiered-storage-overview.md#lsm-tree-write-path) を参照してください。 + +単一テーブルの容量を問い合わせる方法は変更ありません。 + +> **Note:** +> +> この方法はテーブル統計情報に依存するため、推定誤差が大きくなる可能性があります。また、テーブル全体を対象とするため、結果を `Row-based IA Storage` と直接比較することはできません。 + +```sql +SELECT TABLE_NAME, + ROUND(DATA_LENGTH / 1024 / 1024, 2) AS Data_MB, + ROUND(INDEX_LENGTH / 1024 / 1024, 2) AS Index_MB, + TABLE_ROWS +FROM INFORMATION_SCHEMA.TABLES +WHERE TABLE_SCHEMA = 'your_database' + AND TABLE_NAME = 'your_table' +ORDER BY (DATA_LENGTH + INDEX_LENGTH) DESC; +``` + +### IA キャッシュレベルを設定する {#configure-the-ia-cache-level} + +IA キャッシュレベルは、どれだけの IA データをローカルディスクにキャッシュするかを制御します。レベルが高いほど、より多くのデータがキャッシュされ、コールドリード性能は向上しますが、コストも増加します。 + +> **Note:** +> +> - IA キャッシュレベルの調整には、階層型ストレージのプライベートプレビュー有効化に加えて、別途許可リストへの登録が必要です。インスタンスで有効にするには、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) にお問い合わせください。 +> - キャッシュレベルは、個々の論理インスタンスではなく、基盤となる TiKV 物理クラスターのレベルで有効になります。複数の論理インスタンスが同じ物理クラスターを共有している場合、1 つのインスタンスでキャッシュレベルを変更すると、すべてのインスタンスに反映されます。{{{ .premium }}} と {{{ .byoc }}} では、基盤となる TiKV 物理クラスターはお客様専用であるため、他の顧客には影響しません。論理インスタンスレベルでの制御は、今後のリリースで提供予定です。 + +| キャッシュレベル | ユースケース | +|-|-| +| **Economy** | コールドリードがまれで、ローカルディスクのコストを最小化したい場合 | +| **Default** | システムのデフォルトで、一般的なワークロードに適しています | +| **Balanced** | コストとコールドリードレイテンシーのバランスを取りたい場合 | +| **Deep** | ワークロードにおいてコールドリードレイテンシーが重要な場合 | + +キャッシュレベルを変更するには、次の手順を実行します。 + +1. Cloud Console で **Overview** > **Capacity** に移動し、**Update Capacity** をクリックします。 +2. **Storage Acceleration** ブロックで、キャッシュレベルを選択します。 +3. **Summary** ペインでコストへの影響を確認し、**Update Capacity** をクリックします。 + +変更は再起動なしで有効になり、通常は 1 分以内に反映されます。TiDB Cloud が基盤リソースを自動的にプロビジョニングするため、利用可能な空き容量を確認したり、スケーリング方法を選択したりする必要はありません。プロビジョニングには多少時間がかかる場合があります。 + +{{{ .premium }}} では、各キャッシュレベルに IA ストレージ換算係数があり、請求額の計算時に報告された IA ストレージ使用量へ適用されるため、レベルが高いほどコストも高くなります。{{{ .byoc }}} では係数は適用されません。追加のローカルキャッシュリソースはお客様自身のクラウドアカウント内にプロビジョニングされ、クラウドプロバイダーから課金されます。各レベルの係数については、[TiDB Cloud課金](/tidb-cloud/tidb-cloud-billing.md) を参照してください。 + +### IA セグメントサイズを調整する（BYOC のみ） {#adjust-the-ia-segment-size-byoc-only} + +セグメントは、TiKV がオブジェクトストレージから読み取り、ローカルキャッシュへ書き込む最小単位です。デフォルトサイズは 1 MiB です。 + +{{{ .byoc }}} では、TiKV 設定パラメーター `kvengine.ia.segment-size` を `128 KiB`、`256 KiB`、`512 KiB`、`1 MiB`、または `2 MiB` に設定できます。このパラメーターは {{{ .premium }}} では使用できません。 + +`kvengine.ia.segment-size` は起動時にのみ有効になります。変更後は、できればオフピーク時間帯に TiKV ノードのローリング再起動を実行してください。 + +セグメントサイズを変更しても、オブジェクトストレージ内のファイルが書き換えられることはありません。SST ファイルはオブジェクト全体として保存され、セグメント単位で構成されているわけではないため、変わるのはローカルディスク上での読み取り粒度とキャッシュ粒度だけです。再起動後、ローカルキャッシュはクエリの到着に応じて新しい粒度で徐々に再構築されます。 + +## 可観測性 {#observability} + +ストレージクラス移行の進行状況、`EXPLAIN ANALYZE` フィールド、ステートメントサマリーとスロークエリのメトリクス、クラスターレベルの IA キャッシュ性能パネルを含む IA の可観測性については、[階層型ストレージの可観測性](/tidb-cloud/tiered-storage-observability.md) を参照してください。 + +## ベストプラクティス {#best-practices} + +このセクションでは、階層化戦略、ロールアウト戦略、書き込み最適化、クエリ最適化、キャッシュレベルのチューニング、セグメントサイズの選択、切り戻し時の考慮事項、設定の安定性など、IA ストレージに関する推奨運用プラクティスを説明します。 + +### 階層化戦略: パーティションレベル IA を優先する {#tiering-strategy-prefer-partition-level-ia} + +パーティションテーブルでは、テーブルレベル IA よりも **常にパーティションレベル IA を優先** してください。これにより、コールド/ホット境界を正確に制御できます。 + +- 過去のコールドパーティション（例: `p2023`）→ IA +- 最近のホットパーティション（例: `p2025`）→ Standard +- 将来のパーティション（例: `p_future`）→ Standard + +### ロールアウト戦略: 最も古く最も小さいパーティションから開始する {#rollout-strategy-start-with-the-smallest-oldest-partition} + +``` +Step 1: Select the oldest and smallest partition → ALTER PARTITION → IA +Step 2: Observe for one full business day (at least 24h) +Step 3: Verify QPS / TPS / P99 Latency / CPU metrics show no degradation +Step 4: Set the next cold partition → IA one by one +Step 5: Repeat Steps 2-4 until all target partitions are covered +``` + +**すべてのパーティションを一度にまとめて IA に設定しないでください。** + +### 書き込み最適化 {#write-optimization} + +- このチューニングを適用する前に、同じスレッド数、ワークロード、パーティション分布で並行書き込みをベンチマークしてください。あるテスト環境では、IA パーティションへのランダム書き込みは平均 50k rows/sec、1 つの IA パーティションへの固定単一スレッド書き込みは平均 70k rows/sec でした。ただし、これらの結果を直接比較することはできません。 +- 新しくインポートされたデータは、フラッシュまたはコンパクションの後にのみ IA モードへ移行します。インポート直後の大きな範囲クエリでは、コールドキャッシュに遭遇する可能性があります。 + +これらの数値はテスト環境から得られたものであり、実際の本番シナリオを表すものではありません。正確なデータは、お客様自身の業務テストに基づいて取得してください。 + +### クエリ最適化 {#query-optimization} + +- IA パーティションにまたがるクエリは、**3 パーティション以下** に抑えることを推奨します。これを超えると、応答時間が大幅に悪化する可能性があります +- IA テーブルに対する並行 `SELECT *` フルテーブルスキャンを同時に実行することは避けてください +- `EXPLAIN ANALYZE` とスロークエリを通じて IA リモート読み取り量を監視し、必要に応じて調整してください + +### IA キャッシュレベルをチューニングする {#tune-the-ia-cache-level} + +キャッシュレベルを変更するかどうかは、**IA Cache Hit Rate** パネルを使って判断します。 + +- ヒット率が 85% を下回った状態が続く場合は、キャッシュレベルを上げてください。**Balanced** は妥当な開始点です。 +- 変更のたびに、再度変更する前に少なくとも 1 営業日分の期間、ヒット率を観察してください。 +- ヒット率が一貫して高く、コストを下げたい場合は、キャッシュレベルを **Economy** に下げてください。 + +このチューニングループで使用するパネルとステートメントレベルのメトリクスについては、[階層型ストレージの可観測性](/tidb-cloud/tiered-storage-observability.md) を参照してください。 + +### セグメントサイズを選択する（BYOC のみ） {#choose-the-segment-size-byoc-only} + +セグメントサイズは、読み取り増幅とオブジェクトストレージリクエスト数のトレードオフになります。 + +| セグメントサイズ | キャッシュミスごとの読み取り増幅 | オブジェクトストレージリクエスト | 適した用途 | +|-|-|-|-| +| 1 MiB 未満 | 低い | 多い | リクエストコストが問題にならない場合の、低レイテンシーなオブジェクトストレージに対するポイントクエリ | +| 1 MiB (デフォルト) | 中程度 | 中程度 | 一般的なワークロード | +| 1 MiB より大きい | 高い | 少ない | 十分なネットワーク帯域幅がある大規模範囲スキャン | + +このパラメーターを変更する前に、お客様自身のワークロードでベンチマークを行い、ローリング再起動はオフピーク時間帯に実施してください。 + +### 切り戻し時の考慮事項 {#switch-back-considerations} + +- IA → Standard への変換では、すべてのデータをオブジェクトストレージからダウンロードするため、大量のコールドストレージ帯域幅を消費します +- 帯域幅使用量を監視してスムーズな運用を確保してください。必要に応じて、**事前に TiDB Cloud チームへ連絡し**、共同で監視を行ってください +- 変換中も業務 SQL の読み書きには影響しませんが、性能（例: QPS/TPS）にはわずかな影響が出る可能性があります (テスト環境では 5% 未満) +- 開始前に、変更作業に必要な時間枠を見積もるため、`mysql.tidb_storage_class_transition_history` を `state = 'COMPLETED'` で絞り込んで、クラスター上で過去に行われた類似変換の所要時間を確認してください +- 変換中は、`SHOW STORAGE_CLASS TRANSITIONS` を実行して進行状況を追跡し、変換の停止を検出してください + +### 設定の安定性 {#configuration-stability} + +ストレージクラス設定は安定した状態に保ち、IA と Standard の間で頻繁に切り替えないでください。切り替えのたびに、次の処理が発生します。 + +- リージョンのリロード +- オブジェクトストレージデータのダウンロード、またはメタデータの再構築 +- IA キャッシュデータのフラッシュ + +これらの処理の累積コストは無視できません。 + +前回の変換がまだ実行中の間に逆方向の変換を発行すると、前回の変換は無効になり、それまでの進捗は破棄されます。進行中の変換を反転すると、追加のリージョンのリロードやデータダウンロードが発生する可能性があります。既存のローカルファイルの一部は再利用できるため、追加作業の量は、変換がどこまで進んでいたか、およびどのデータがローカルで引き続き利用可能かによって異なります。不要な I/O とリソース使用量を減らすため、IA と Standard の間で頻繁に切り替えることは避けてください。無効化された変換を識別する方法については、[階層型ストレージの可観測性](/tidb-cloud/tiered-storage-observability.md) を参照してください。 + +これは、テーブルまたはパーティションのストレージクラスに適用されます。IA キャッシュレベルの調整は別の操作です。これはホットアップデートであり、ストレージクラス間でデータを移動せず、コストと性能の目標に応じて必要な頻度で変更できます。 diff --git a/tidb-cloud/tiered-storage-limitations.md b/tidb-cloud/tiered-storage-limitations.md new file mode 100644 index 0000000000000..eeb022e020a55 --- /dev/null +++ b/tidb-cloud/tiered-storage-limitations.md @@ -0,0 +1,99 @@ +--- +title: 階層型ストレージの制限事項 +summary: TiDB Cloud Premium または BYOC における階層型ストレージの制限事項、スロットリング、互換性、およびクエリ性能の不確実性について説明します。 +--- + +# 階層型ストレージの制限事項 + +このドキュメントでは、Infrequent Access (IA) ストレージの現在の制限事項と運用上の影響について説明します。これには、機能上の制約、コールドリードのスロットリング、ツール互換性、およびクエリ性能の不確実性が含まれます。 + +> **Note:** +> +> 階層型ストレージは {{{ .premium }}} および {{{ .byoc }}} 向けに **プライベートプレビュー** として提供されており、デフォルトでは無効です。利用するには、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) に連絡してインスタンスで有効化してもらう必要があります。このページで説明する動作は現在のプレビュー実装に基づいており、一般提供 (GA) 前に変更される可能性があります。 + +## 機能上の制限事項 {#feature-limitations} + +| 制限事項 | 説明 | +|-|-| +| Hash / Key パーティション | IA に設定できません | +| インデックス単位の設定 | インデックスに対して個別に IA を設定することはできません | +| TTL による自動階層化 | 業務フィールドに基づくコールドデータとホットデータの自動階層化はサポートされていません | +| 構文の競合 | `STORAGE_CLASS` と `ENGINE_ATTRIBUTE` は同時に指定できません | +| パーティションセレクターの混在 | `names_in` / `less_than` / `values_in` は同時に使用できません | +| TiFlash | IA には従わず、データは常にローカルに保持されます | +| キャッシュレベルの適用範囲 | IA のキャッシュレベルは、個別の論理インスタンスや特定のテーブルまたはパーティションではなく、基盤となる TiKV 物理クラスターのレベルで適用されます。同じ物理クラスターを共有するすべての論理インスタンスは、そのうちのいずれか 1 つでキャッシュレベルを変更すると影響を受けます。論理インスタンスレベルでの制御は将来のリリースで予定されています | +| キャッシュレベルの有効化 | IA のキャッシュレベルを変更するには、階層型ストレージのプライベートプレビュー有効化に加えて別途許可リストへの登録が必要であり、デフォルトでは無効です。有効化するには [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) に連絡してください | +| セグメントサイズの調整 | `kvengine.ia.segment-size` は {{{ .byoc }}} でのみ変更でき、TiKV ノードのローリング再起動後にのみ有効になります | +| キャッシュレベルのプロビジョニング | キャッシュレベルの変更自体はホットアップデートとして反映されますが、基盤リソースは TiDB Cloud によって自動的にプロビジョニングされるため、反映までに時間がかかる場合があります | +| 変換進行状況の可視性 | `INFORMATION_SCHEMA.TIKV_STORAGE_CLASS_TRANSITIONS` の行は、そのテーブルに対する `ALL` 権限を持っている場合にのみ表示されます。アクセスできないテーブルの行は、エラーを出さずにスキップされます | +| 変換進行状況の鮮度 | 変換の進行状況は 10 秒ごとに収集されるため、`INFORMATION_SCHEMA.TIKV_STORAGE_CLASS_TRANSITIONS` の値はリアルタイムではありません | + +## アクセススロットリングの制約 {#access-throttling-constraints} + +共有物理クラスターではオブジェクトストレージの帯域幅に限りがあるため、IA コールドストレージへのアクセスは次の制限に従う必要があります。 + +| 制約の観点 | 制限 | 理由 | +|-|-|-| +| 単一 SQL のコールドリードスループット | ≤ 100 MiB/s | 1 つのクエリが過剰な帯域幅を消費するのを防ぐため | +| コールドリードの同時実行スループット合計 | ≤ 1 GiB/s (同時実行数 ≤ 10) | クラスター内の他のテナントを保護するため | +| TiKV の 1 回のキャッシュミスあたりのロードサイズ | ≤ ~3 MiB (推定) | 3 つの LSM レベルからのセグメント | + +> **Note:** +> +> TiKV での 1 回のキャッシュミスは、クエリでの 1 回のキャッシュミスを意味するわけではありません。たとえば、1 つのクエリで TiKV のキャッシュミスが複数回（例: 1000 回）発生する場合があります。5 台の TiKV ノードがそのクエリを処理する場合、各 TiKV は平均 200 回のキャッシュミスを処理し、結果として 200 回のリモートコールドデータクエリが発生します。各 TiKV 内では並行して処理されるものの、200 回のキャッシュミスの処理には非常に長い時間がかかるため、最終的なクエリレイテンシーが極めて高くなる可能性があります。 + +**業務でコールドデータへの継続的かつ高負荷なアクセスがある場合、IA は推奨されません。テーブルを Standard ストレージに戻してください。** システムの安定性を確保するため、将来の技術リリースではコールドデータアクセスに対するハードスロットリングが追加される予定です。現時点では、上記の制約を順守する必要があります。 + +単一 SQL によるコールドデータアクセス量は、Cloud Console → Monitoring → Diagnosis → Slow Query → Coprocessor の `IA Remote Read Segment Size` パネルで監視できます。クラスター全体の IA キャッシュ動作を監視するには、[階層型ストレージの可観測性](/tidb-cloud/tiered-storage-observability.md) で説明されている **IA Cache Performance** パネルを使用してください。 + +## 周辺ツールへの影響 {#impact-on-peripheral-tools} + +| ツール | 影響 | 互換性 | +|-|-|-| +| **TiCDC** | 論理データのセマンティクスは変わりません。init scan や古いデータの読み取りではレイテンシーが高くなる可能性があります。リージョン変更は通常どおり処理されます | 互換性あり | +| **BR backup & restore** | ストレージクラスのメタデータを保持します。リストア後も、IA テーブルは引き続き IA のセマンティクスでロードされます | 互換性あり | +| **IMPORT INTO** | インポートされたデータはフラッシュまたはコンパクションを通じて IA に移行します。インポート後の大範囲検証ではキャッシュにデータがない状態 (コールドキャッシュ) になる場合があります | 互換性あり | +| **PITR** | ストレージクラスのメタデータを保持します。リストア後に schema manager が再同期を行います | 互換性あり | + +## リスク分離メカニズム {#risk-isolation-mechanisms} + +テーブルに IA を設定した後、システムは IA テーブルと非 IA テーブルを分離するために次の対策を使用します。 + +**リージョンレベル**: + +- IA テーブル/パーティションは専用のリージョンを占有し、必要に応じて分割が発生します +- ストレージクラスが異なる隣接リージョンはマージが制限され、ホットデータとコールドデータの混在を防ぎます +- 1 つのリージョンは完全に IA であるか、完全に非 IA であるかのいずれかです + +**コンピュートレイヤー**: + +- Standard テーブルと IA テーブルはコンピュートレイヤーでは分離されません。TiDB にはこの 2 種類のテーブルに対する個別の分離戦略はありません + +**ストレージレイヤー**: + +- コールドリードのレート制限 + +> **Note:** +> +> 共有リソース（CPU、ネットワーク、ローカルディスク、オブジェクトストレージ帯域幅）は完全には分離できません。極端な場合、大規模な IA スキャンが他のテナントに影響する可能性があります。これがアクセススロットリングの制約が存在する根本的な理由です。 + +## 緊急リカバリ方法 {#emergency-recovery-methods} + +IA テーブルで問題が発生した場合、ユーザーと TiDB Cloud チームは次の方法を使用できます。 + +| 方法 | シナリオ | 優先度 | 説明 | +|-|-|-|-| +| IA → Standard への切り戻し | 性能が許容できないと判断した場合 | **ユーザーの第一の選択肢** | システムがデータをローカルにリロードし、リモートパスをバイパスします | +| **Flow Control (already available)** | IA テーブルとオブジェクトストレージ間のトラフィックを制御する | TiDB Cloud チームの選択肢 | レート制限によってクラスターの安定性を保護します。TiDB Cloud チームが管理します | +| TiDB Cloud サポートに連絡する | ストレージクラス変換が停止している場合: `DURATION` が増え続ける一方で `COMPLETED_REPLICAS` が増加しない、または `NULL` のままである | 必須 | 停止した変換はユーザー自身では解決できません。検出方法については、[階層型ストレージの可観測性](/tidb-cloud/tiered-storage-observability.md) を参照してください | + +## IA ローカルキャッシュとクエリ性能の不確実性 {#ia-local-cache-and-query-performance-uncertainty} + +階層型ストレージは、最近アクセスされたコールドデータへの繰り返しアクセスを高速化するために、ローカル IA データキャッシュ（IaManager により管理）を維持します。ただし、次の重要な点を理解しておく必要があります。 + +- **キャッシュ容量は調整可能ですが、キャッシュ動作は引き続きシステム管理です**: Cloud Console で IA キャッシュレベルを選択し、ローカルディスク上にキャッシュする IA データ量を制御できます。ただし、エビクションポリシーは引き続きシステムによって管理されます。どのデータをキャッシュに残すかを指定することはできず、キャッシュレベルは個別の論理インスタンス、テーブル、またはパーティションではなく、基盤となる TiKV 物理クラスターに適用されます。キャッシュヒット率は実際のアクセスパターンに依存します。アクセスが集中していれば 95% を超えることがありますが、アクセスが分散している場合は 95% を下回ることがあります。 +- **IA クエリの応答時間は一定ではありません**: クエリがローカルキャッシュにヒットした場合、性能は Standard テーブルに近くなります。しかし、データをリモートオブジェクトストレージからロードする必要がある場合（キャッシュミス）、各リモートリクエストで約 500ms~2s のレイテンシーが追加されます。1 回の SQL 実行で複数回のリモートロードが発生することがあり、その結果レイテンシーが累積します。そのため、IA テーブルのクエリ応答時間は Standard テーブルほど予測可能ではありません。業務側ではこの点を考慮して計画する必要があります。 +- **推奨: パーティションテーブルを使用してコールドデータの範囲を正確に制御する**: パーティションテーブルを使用し、低頻度アクセスであることが確認された履歴パーティションのみを IA に設定し、アクティブなパーティションは Standard のままにしてください。これにより、キャッシュの不確実性を明確に定義されたデータ範囲に限定でき、テーブル全体のクエリ性能をキャッシュミスリスクにさらさずに済みます。 +- **キャッシュ領域を増やすことはコスト増加を意味します**: より高いキャッシュレベルでは、より多くの IA データがローカルディスクに保持されるため、より多くのローカルディスクおよび TiKV リソースを消費します。{{{ .premium }}} では、より高いキャッシュレベルにより課金対象の IA ストレージ量が増加します。{{{ .byoc }}} では、追加リソースはお客様自身のクラウドアカウント内にプロビジョニングされ、クラウドプロバイダーから課金され、プロビジョニング完了までに時間がかかります。業務要件に応じて、コールドリード性能とコストのバランスを取ってください。 + +**要するに:** IA ストレージは、ストレージコストを削減する代わりに、クエリ性能の予測可能性を低下させます。これは設計上避けられないトレードオフです。どのデータをコールドデータとするかを正確に定義し、その影響をそのデータに限定するために、パーティションテーブルを使用してください。業務で予測可能なクエリ応答時間が必要な場合は、レイテンシーに敏感なデータを Standard ストレージに保持してください。 diff --git a/tidb-cloud/tiered-storage-observability.md b/tidb-cloud/tiered-storage-observability.md new file mode 100644 index 0000000000000..ac81a1b0a3df6 --- /dev/null +++ b/tidb-cloud/tiered-storage-observability.md @@ -0,0 +1,304 @@ +--- +title: 階層型ストレージの可観測性 +summary: TiDB Cloud Premium または BYOC で階層型ストレージを監視する方法（変換の進行状況、IA 読み取りメトリクス、キャッシュ性能パネルを含む）を学びます。 +--- + +# 階層型ストレージの可観測性 + +このドキュメントでは、Infrequent Access (IA) ストレージを監視する方法について説明します。これには、ストレージクラス移行の進行状況、SQL レベルでの IA 読み取りメトリクス、クラスターレベルでの IA キャッシュ性能が含まれます。 + +> **Note:** +> +> 階層型ストレージは、{{{ .premium }}} および {{{ .byoc }}} 向けに **プライベートプレビュー** として提供されており、デフォルトでは無効です。利用するには、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) に連絡して、インスタンスで有効化してもらう必要があります。このページで説明している動作は現在のプレビュー実装に基づいており、一般提供 (GA) 前に変更される可能性があります。 + +## ストレージクラス移行を監視する {#monitor-storage-class-transitions} + +このセクションでは、ストレージクラス変換の進行状況を追跡する方法と、過去の変換を確認する方法について説明します。 + +変換の進行状況は、ストレージクラスを変更する方法にかかわらず、同じ方法で追跡されます。 + +- `STORAGE_CLASS` の糖衣構文。例: `ALTER TABLE t1 STORAGE_CLASS='IA'` +- `ENGINE_ATTRIBUTE` 形式。例: `ALTER TABLE t1 ENGINE_ATTRIBUTE='{"storage_class":"IA"}'` +- `ENGINE_ATTRIBUTE` を使用したパーティションレベルの変更 + +パーティションテーブルは `ENGINE_ATTRIBUTE` のみをサポートするため、パーティション変換はテーブルレベルの変換と同じビューに表示されます。テーブルまたはパーティションが最初から IA ストレージクラスで作成された場合、移行するデータがないため、これらのビューには表示されません。 + +`ALTER TABLE` 文自体は、数秒以内にスキーマメタデータを更新します。その後のリージョンレベルのデータ移行は TiKV 内で非同期に実行され、DDL ライフサイクルとは分離されているため、`ADMIN SHOW DDL JOBS` では進行状況は報告されません。進行中の変換を追跡するには `SHOW STORAGE_CLASS TRANSITIONS` を使用し、過去および進行中の変換を確認するには `mysql.tidb_storage_class_transition_history` をクエリします。履歴テーブルには、変換開始時に `state = 'RUNNING'` のレコードが挿入され、変換が最終状態に達するとその場で更新されます。 + +### 進行中の移行を表示する {#view-in-progress-transitions} + +```sql +SHOW STORAGE_CLASS TRANSITIONS; +SHOW STORAGE_CLASS TRANSITIONS LIKE 'table_name'; +SHOW STORAGE_CLASS TRANSITIONS WHERE DIRECTION = 'TO_STANDARD'; +``` + +`SHOW STORAGE_CLASS TRANSITIONS` は `SELECT * FROM INFORMATION_SCHEMA.TIKV_STORAGE_CLASS_TRANSITIONS` と等価です。 + +`INFORMATION_SCHEMA.TIKV_STORAGE_CLASS_TRANSITIONS` テーブルには、現在進行中の変換が一覧表示されます。このテーブルには state カラムはありません。含まれるすべての行が進行中の変換だからです。このテーブルには次のカラムがあります。 + +| カラム | 型 | 説明 | +|-|-|-| +| `TABLE_SCHEMA` | VARCHAR(64) | データベース名 | +| `TABLE_NAME` | VARCHAR(64) | テーブル名 | +| `TABLE_ID` | BIGINT(21) | テーブルの内部 ID | +| `PARTITION_NAME` | VARCHAR(64) | パーティション名。テーブルレベルの変換では値は `NULL` | +| `PARTITION_ID` | BIGINT(21) | パーティションの内部 ID。テーブルレベルの変換では値は `NULL` | +| `DIRECTION` | VARCHAR(16) | 変換方向: `TO_IA` または `TO_STANDARD` | +| `TOTAL_REPLICAS` | BIGINT(21) UNSIGNED | 変換に関与するレプリカの総数。最初の観測が成功する前は値は `NULL` | +| `COMPLETED_REPLICAS` | BIGINT(21) UNSIGNED | 準備完了となったレプリカ数。最初の観測が成功する前は値は `NULL` | +| `PROGRESS` | DOUBLE | `COMPLETED_REPLICAS` を `TOTAL_REPLICAS` で割った比率。`0` から `1` の範囲です。百分率にするには 100 を掛けます。有効な進捗率が観測されるまでは値は `NULL` です。これは `TOTAL_REPLICAS` と `COMPLETED_REPLICAS` が最初に埋まる観測より後になる場合があります | +| `START_TIME` | DATETIME(6) | 変換開始時刻（セッションタイムゾーン） | +| `DURATION` | BIGINT(21) UNSIGNED | 変換開始から現在までの経過時間（秒） | +| `LAST_UPDATE_TIME` | DATETIME(6) | 直近で成功した進捗観測の時刻 | + +> **Note:** +> +> - 行が表示されるのは、そのテーブルに対して `ALL` 権限を持っている場合のみです。アクセスできないテーブルの行は、エラーや警告なしでスキップされます。 +> - 進捗は 10 秒ごとに収集されるため、値はリアルタイムではありません。 + +特定の変換の進行状況と経過時間を確認するには、次を実行します。 + +```sql +SELECT TABLE_NAME, DIRECTION, COMPLETED_REPLICAS, TOTAL_REPLICAS, + ROUND(PROGRESS * 100, 1) AS PROGRESS_PCT, + DURATION, LAST_UPDATE_TIME +FROM INFORMATION_SCHEMA.TIKV_STORAGE_CLASS_TRANSITIONS +WHERE TABLE_SCHEMA = 'db_name' AND TABLE_NAME = 'table_name'; +``` + +変換は 1 つの進行中状態を経て、2 つの最終状態のいずれかで終了します。各状態は `mysql.tidb_storage_class_transition_history` にも記録されます。 + +| 状態 | 記録場所 | 説明 | +|-|-|-| +| `RUNNING` | `INFORMATION_SCHEMA.TIKV_STORAGE_CLASS_TRANSITIONS` および `mysql.tidb_storage_class_transition_history` の `state` カラム | リージョンレベルの変換が進行中です。`INFORMATION_SCHEMA` テーブルにはこの変換のみが一覧表示され、state カラムはありません。変換が `RUNNING` の間、履歴レコードの `finish_time`、`duration`、`total_replicas`、`completed_replicas` は `NULL` です。進捗は `PROGRESS`、`COMPLETED_REPLICAS`、`TOTAL_REPLICAS` で、経過時間は `DURATION` で追跡します | +| `COMPLETED` | `mysql.tidb_storage_class_transition_history` の `state` カラム | すべてのレプリカの準備が完了しています。変換は `INFORMATION_SCHEMA.TIKV_STORAGE_CLASS_TRANSITIONS` から削除され、履歴レコードは `COMPLETED` に更新されます | +| `SUPERSEDED` | `mysql.tidb_storage_class_transition_history` の `state` カラム | 完了前に逆方向の変換が発行されたため、この変換は無効化されました。履歴レコードは `SUPERSEDED` に更新されます | + +### 変換が停止しているかどうかを判断する {#determine-whether-a-conversion-is-stuck} + +`LAST_UPDATE_TIME`、`COMPLETED_REPLICAS`、`DURATION` をあわせて確認してください。 + +- `COMPLETED_REPLICAS` が増加し、`LAST_UPDATE_TIME` も更新され続けている場合: 変換は正常に進行しており、単にデータ量が大きいだけです。 +- `DURATION` は増え続けているのに、`COMPLETED_REPLICAS` が長時間増加しない場合: TiKV のローリング再起動、一時的なリソース不足、短時間のオブジェクトストレージ利用不可などのシステム例外により、変換が停止している可能性があります。 +- `TOTAL_REPLICAS`、`COMPLETED_REPLICAS`、`PROGRESS`、`LAST_UPDATE_TIME` がすべて `NULL` のままの場合: まだ成功した観測が行われていません。これらのカラムはまとめて設定・クリアされるため、`LAST_UPDATE_TIME` だけでは観測の試行が継続しているかどうかは判断できません。代わりに `DURATION` を確認してください。これは変換が追跡されている間は常に増加します。これらのカラムが `NULL` のままで `DURATION` だけが増え続けている場合、ポーリングは継続中ですが、有効な観測結果がまだ返ってきていません。 + +停止した変換を自分で解消することはできません。[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) に連絡してください。問題が解消されると、`COMPLETED_REPLICAS` は `COMPLETED` に達するまで再び増加し続け、追加の操作は不要です。 + +### まだ進行中の変換を逆方向に戻す {#reverse-a-conversion-that-is-still-in-progress} + +テーブルまたはパーティションに対して、前回の変換がまだ進行中の間に逆方向の変換を発行すると、前回の変換は無効化されます。 + +- `INFORMATION_SCHEMA.TIKV_STORAGE_CLASS_TRANSITIONS` では、そのテーブルまたはパーティションの行が新しい変換に置き換えられます。`DIRECTION` には新しい方向が表示され、`START_TIME` は新しい変換の開始時刻になり、進捗は再び最初からカウントされます。そのテーブルまたはパーティションには 1 行だけが残ります。 +- 無効化された変換の `mysql.tidb_storage_class_transition_history` 内の履歴レコードは、`state = 'SUPERSEDED'` に更新されます。その `finish_time` は新しい変換の開始時刻になり、`total_replicas` と `completed_replicas` は無効化される直前に最後に観測された値になります。まだ何も観測されていなかった場合、両方のカラムは `NULL` です。 + +無効化された変換がどこまで進んでいたかを確認するには、履歴テーブルで `state = 'SUPERSEDED'` のレコードをクエリしてください。 + +### 移行履歴をクエリする {#query-transition-history} + +すべての変換は、開始時に `mysql.tidb_storage_class_transition_history` テーブルに記録され、進行に応じてそのレコードが更新されます。このテーブルには次のカラムがあります。 + +| カラム | 型 | 説明 | +|-|-|-| +| `table_schema` | VARCHAR(64) | データベース名 | +| `table_name` | VARCHAR(64) | テーブル名 | +| `table_id` | BIGINT | テーブルの内部 ID。`start_ts` および `direction` とあわせて、このテーブルの主キーを構成します | +| `partition_name` | VARCHAR(64) | パーティション名。テーブルレベルの変換では値は `NULL` | +| `partition_id` | BIGINT | パーティションの内部 ID。テーブルレベルの変換では値は `NULL` | +| `direction` | VARCHAR(16) | 変換方向: `TO_IA` または `TO_STANDARD` | +| `state` | VARCHAR(16) | 変換状態: `RUNNING`、`COMPLETED`、または `SUPERSEDED` | +| `total_replicas` | BIGINT UNSIGNED | 変換に関与するレプリカの総数。`SUPERSEDED` レコードでは、変換が無効化される前に最後に観測された値、または何も観測されていなければ `NULL` です。変換が `RUNNING` の間は値は `NULL` です | +| `completed_replicas` | BIGINT UNSIGNED | 準備完了だったレプリカ数。`COMPLETED` レコードでは、これは `total_replicas` と等しくなります。`SUPERSEDED` レコードでは、変換が無効化される前に最後に観測された値、または何も観測されていなければ `NULL` です。変換が `RUNNING` の間は値は `NULL` です | +| `schema_version` | BIGINT | この変換が属する TiDB スキーマバージョン | +| `start_ts` | BIGINT UNSIGNED | 変換の開始 TSO。`table_id` および `direction` とあわせて変換を識別します | +| `start_time` | DATETIME(6) | 変換開始時刻 | +| `finish_time` | DATETIME(6) | 変換が最終状態に達した時刻。`COMPLETED` レコードでは、すべてのレプリカの準備が完了した時刻です。`SUPERSEDED` レコードでは、新しい変換の開始時刻です。変換が最終状態に達するまでは値は `NULL` です | +| `duration` | BIGINT UNSIGNED | 総所要時間（秒）。`SUPERSEDED` レコードでは、これは開始から無効化されるまでの時間のみを表し、完全な変換時間ではありません。変換がまだ `RUNNING` の間は値は `NULL` です | + +このテーブルを使用すると、テスト環境の参考値よりも信頼性高く、自分のクラスターで類似の変換にどれくらい時間がかかるかを見積もれます。 + +```sql +-- Average duration of completed conversions, grouped by direction. +-- Filter on state = 'COMPLETED': the duration of a SUPERSEDED record +-- does not represent a full conversion. +SELECT direction, + COUNT(*) AS total_conversions, + ROUND(AVG(duration), 0) AS avg_duration_sec, + MIN(duration) AS min_duration_sec, + MAX(duration) AS max_duration_sec +FROM mysql.tidb_storage_class_transition_history +WHERE state = 'COMPLETED' +GROUP BY direction; + +-- The most recent finished conversion of a specific table +SELECT table_name, direction, state, duration AS total_duration_sec, + total_replicas, completed_replicas, start_time, finish_time +FROM mysql.tidb_storage_class_transition_history +WHERE table_schema = 'db_name' AND table_name = 'table_name' + AND state <> 'RUNNING' +ORDER BY finish_time DESC +LIMIT 1; + +-- Conversions that were voided by a reverse conversion +SELECT table_schema, table_name, partition_name, direction, + completed_replicas, total_replicas, start_time, finish_time, duration +FROM mysql.tidb_storage_class_transition_history +WHERE state = 'SUPERSEDED' +ORDER BY finish_time DESC; +``` + +#### 履歴レコードの保持 {#retention-of-history-records} + +`mysql.tidb_storage_class_transition_history` に保持されるレコードの最大数は、システム変数 [`tidb_storage_class_transition_history_size`](#tidb_storage_class_transition_history_size) によって制御されます。レコード数がこの上限を超えると、`finish_time` の古い順に最も古いレコードから削除されます。保持制御は最大でも 1 分に 1 回しか実行されないため、行数が一時的に上限を超えることがあります。 + +```sql +-- View the current retention limit +SELECT @@tidb_storage_class_transition_history_size; + +-- Retain up to 500 records +SET GLOBAL tidb_storage_class_transition_history_size = 500; +``` + +#### tidb_storage_class_transition_history_size {#tidb_storage_class_transition_history_size} + +- Scope: GLOBAL +- Persists to cluster: Yes +- Applies to hint [SET_VAR](/optimizer-hints.md#set_varvar_namevar_value): No +- Type: Integer +- Default value: `1000` +- Range: `[100, 100000]` +- この変数は、`mysql.tidb_storage_class_transition_history` テーブルに保持するストレージクラス移行レコードの最大数を設定するために使用されます。値を大きくすると、より長期間履歴を保持できますが、`mysql` データベースで使用する領域も増えます。 + +## SQL レベルで IA 読み取りを監視する {#monitor-ia-reads-at-the-sql-level} + +このセクションでは、`EXPLAIN ANALYZE`、ステートメントサマリーテーブル、スロークエリログ、および TiDB Cloud コンソールで利用できる IA メトリクスについて説明します。 + +### EXPLAIN ANALYZE {#explain-analyze} + +クエリにリモートデータロードが含まれる場合、`scan_detail` には次のフィールドが含まれます。 + +```sql +EXPLAIN ANALYZE SELECT * FROM t_ia WHERE id BETWEEN 1 AND 50000; +-- The output includes: +-- ia_remote_read_segment_size: 2320453 -- Total bytes loaded remotely +-- ia_remote_read_segment_count: 3 -- Number of remote loading events +-- ia_remote_read_segment_wait_time: 0.008 -- Remote wait time (seconds) +``` + +> **Note:** +> +> IA シグナルは、テーブルレベルで安定したフラグではなく、リクエスト単位の読み取りパスの証拠です。同じクエリでも、初回実行では IA 情報が表示されても、キャッシュヒット後には表示されないことがあります。 +> +> また、`ia_remote_read_segment_wait_time` はすべてのリモートリクエスト時間の合計です。TiKV の基盤となる並列読み取りメカニズムにより、この値は SQL の実際の実行時間を上回る場合があります。 + +### ステートメントサマリー {#statement-summary} + +`STATEMENTS_SUMMARY`、`STATEMENTS_SUMMARY_HISTORY`、およびそれらの `CLUSTER_` 対応ビューには、次の IA カラムが含まれます。 + +| カラム | 説明 | +|-|-| +| `IA_EXEC_COUNT` | 少なくとも 1 回の IA リモート読み取りを発生させた実行回数。`EXEC_COUNT` と比較することで、IA データにアクセスした実行の割合を把握できます。たとえば、`IA_EXEC_COUNT = 2` かつ `EXEC_COUNT = 1000` は、実行のうち IA データにアクセスしたのが 0.2% のみであることを意味します | +| `AVG_IA_REMOTE_READ_SEGMENT_COUNT` | 実行ごとのリモート読み取りセグメント数の平均 | +| `MAX_IA_REMOTE_READ_SEGMENT_COUNT` | 1 回の実行で読み取られたリモートセグメント数の最大値 | +| `AVG_IA_REMOTE_READ_SEGMENT_SIZE` | 実行ごとのリモート読み取りデータ量の平均 | +| `MAX_IA_REMOTE_READ_SEGMENT_SIZE` | 1 回の実行でのリモート読み取りデータ量の最大値 | +| `AVG_IA_REMOTE_READ_SEGMENT_WAIT_TIME` | 実行ごとのリモート待機時間の平均 | +| `MAX_IA_REMOTE_READ_SEGMENT_WAIT_TIME` | 1 回の実行でのリモート待機時間の最大値 | + +`AVG_` および `MAX_` の各カラムは、各実行でどれだけのデータをリモートから読み取ったかを示し、`IA_EXEC_COUNT` は、そもそも何回の実行がリモート読み取りを行ったかを示します。これら 2 つの観点を組み合わせて使用してください。たとえば、`AVG_IA_REMOTE_READ_SEGMENT_SIZE` は小さい一方で `IA_EXEC_COUNT / EXEC_COUNT` の比率が高いステートメントは、少量のコールドデータに頻繁にアクセスしていることを意味します。 + +IA テーブルを含まないクエリでは、これらのカラムは `0` または `NULL` になります。 + +コールドリード実行の割合が最も高いステートメントを見つけるには、次の SQL を使用します。 + +```sql +SELECT DIGEST_TEXT, EXEC_COUNT, IA_EXEC_COUNT, + ROUND(IA_EXEC_COUNT / EXEC_COUNT * 100, 2) AS ia_exec_pct, + AVG_IA_REMOTE_READ_SEGMENT_SIZE +FROM INFORMATION_SCHEMA.CLUSTER_STATEMENTS_SUMMARY_HISTORY +WHERE IA_EXEC_COUNT > 0 +ORDER BY ia_exec_pct DESC +LIMIT 10; +``` + +### スロークエリ {#slow-queries} + +`INFORMATION_SCHEMA.CLUSTER_SLOW_QUERY` には、次の IA カラムが含まれます。 + +- `IA_remote_read_segment_count` +- `IA_remote_read_segment_size` +- `IA_remote_read_segment_wait_time` + +同じフィールドは `ADMIN SHOW SLOW` の出力でも利用できます。 + +```sql +ADMIN SHOW SLOW RECENT 10; +ADMIN SHOW SLOW TOP INTERNAL 10; +ADMIN SHOW SLOW TOP ALL 10; +``` + +フィールドの意味と単位は、`SLOW_QUERY` テーブルと同じです。IA テーブルを含まないクエリでは、値は `NULL` または `0` になります。対応するフィールドは、TiDB Cloud コンソールのスロークエリ詳細にも表示されます。 + +### コンソールの SQL ステートメントリスト {#sql-statement-list-in-the-console} + +`IA_EXEC_COUNT` カラムは、SQL ステートメント診断リストにも表示されます。 + +- **Cloud Console**: **Monitoring** > **Diagnosis** > **SQL Statement** +- **Clinic**: **Diagnosis** > **SQL Statements** + +このカラム名は **Exec Count of IA** で、**Executions Count** の直後に配置されるため、2 つの値を直接比較できます。他のカラムと同様に、昇順および降順のソートをサポートします。IA テーブルを含まないステートメントでは、値は `0` です。 + +## クラスターレベルで IA キャッシュ性能を監視する {#monitor-ia-cache-performance-at-the-cluster-level} + +このセクションでは、TiDB Cloud コンソールで IA キャッシュの挙動を確認するためのクラスターレベルのパネルについて説明します。 + +### IA Cache Performance パネル {#ia-cache-performance-panels} + +パス: **Monitoring** > **Metrics** > **Instance Overview** > **IA Cache Performance**。 + +| パネル | 説明 | +|-|-| +| **IA Cache Hit Rate (%)** | クラスター全体の IA キャッシュヒット率。値が 85% を下回ると黄色のインジケーターが表示されます | +| **IA Cache Miss Rate (ops/s)** | IA キャッシュミスの発生頻度。通常、この値は低く保たれます。急増した場合は、大量のコールドリードまたはキャッシュへの負荷を示します | +| **IA Remote Read Segment** | オブジェクトストレージから読み取られたセグメントの頻度 (Count) とデータ量 (Size)。オブジェクトストレージへのリクエスト量と帯域幅消費の評価に使用します | +| **IA Remote Read Segment Wait Time** | 1 回のリモート読み取りの待機時間。P99 と Avg で表示されます。継続的な増加は、オブジェクトストレージのレイテンシー悪化または帯域幅制限を示します | + +時間選択ツールで時間範囲を変更すると、より長期的な傾向を観察できます。クラスターに IA テーブルがない場合、パネルには `0%` やエラーの代わりに **No IA data** が表示されます。 + +単一ステートメントのコールドデータ量を監視するには、**Monitoring** > **Diagnosis** > **Slow Query** > **Coprocessor** にある `IA Remote Read Segment Size` パネルを使用します。 + +### パネルの見方 {#interpret-the-panels} + +キャッシュヒット率は、実際のアクセスパターンに依存します。アクセスが集中していれば 95% を超えることもありますが、アクセスが分散している場合は 95% を下回ることがあります。 + +- **ヒット率の急低下**: 同時に **IA Cache Miss Rate** が上昇しているか確認してください。同時に上昇していれば、収集上の問題ではなく、コールドリードが実際に増加していることを示します。その後、ステートメントサマリーテーブルの `IA_EXEC_COUNT` を使って、どのステートメントがコールドリードを引き起こしたかを特定します。 +- **ヒット率が継続的に低い**: キャッシュがコールドデータによって圧迫されています。IA キャッシュレベルを引き上げるか、IA に設定するデータ量を減らすことを検討してください。[階層型ストレージの設定と管理](/tidb-cloud/tiered-storage-guide.md) を参照してください。 +- **テーブルが IA に適しているかの評価**: パーティションを IA に設定した後、少なくとも 1 営業日分は **IA Cache Hit Rate** を観察してください。ヒット率が安定していれば、そのアクセスパターンは IA に適しています。大きな変動や低い平均値は、そのデータへのアクセスが IA に対して分散しすぎていることを意味します。 + +## 診断ワークフロー {#diagnostic-workflows} + +### 変更前に変換ウィンドウを見積もる {#estimate-the-conversion-window-before-a-change} + +1. `SHOW STORAGE_CLASS TRANSITIONS` を実行して、他の変換がすでに進行中かどうかを確認します。このテーブルには、進行中の変換のみが表示されます。 +2. `mysql.tidb_storage_class_transition_history` をクエリし、`state = 'COMPLETED'` で絞り込んだうえで、クラスター内の類似する過去の変換の `duration` を確認します。 +3. 変換中は、`DURATION` と `PROGRESS` を組み合わせて残り時間を見積もります。 + +### キャッシュヒット率の急低下を調査する {#investigate-a-sudden-drop-in-cache-hit-rate} + +1. **IA Cache Hit Rate** の低下を確認し、同時に **IA Cache Miss Rate** が上昇しているかを確認します。 +2. ステートメントサマリーテーブルで、`IA_EXEC_COUNT / EXEC_COUNT` の比率が高いステートメントを特定します。 +3. 多くのステートメントで同時にこの比率が上昇している場合、分析クエリのバッチが IA テーブルをスキャンし、キャッシュからホットデータを追い出している可能性があります。 +4. IA キャッシュレベルを引き上げるか、影響を受けたデータを Standard ストレージに戻すかを判断します。 + +### テーブルを IA に保持するかどうかを判断する {#decide-whether-to-keep-a-table-in-ia} + +1. そのテーブルにアクセスするステートメントについて、`IA_EXEC_COUNT / EXEC_COUNT` を集計します。 +2. ほとんどのステートメントでコールドリード比率が高いままであれば、IA に対してキャッシュヒット率が低すぎます。テーブルを Standard に戻すことを検討してください。 +3. コールドリード比率が低くても、一部のステートメントが毎回大量のデータを読み取る場合は、テーブル全体を戻すのではなく、それらのステートメントを最適化してください。 + +## 参照 {#see-also} + +- [階層型ストレージの概要](/tidb-cloud/tiered-storage-overview.md) +- [階層型ストレージの設定と管理](/tidb-cloud/tiered-storage-guide.md) +- [階層型ストレージの制限事項](/tidb-cloud/tiered-storage-limitations.md) +- [階層型ストレージに関する FAQ](/tidb-cloud/tiered-storage-faq.md) diff --git a/tidb-cloud/tiered-storage-overview.md b/tidb-cloud/tiered-storage-overview.md new file mode 100644 index 0000000000000..b9cbd07dae516 --- /dev/null +++ b/tidb-cloud/tiered-storage-overview.md @@ -0,0 +1,195 @@ +--- +title: 階層型ストレージの概要 +summary: TiDB Cloud Premium と BYOC における階層型ストレージの概念、アーキテクチャ、ユースケース、実装原理について説明します。 +--- + +# 階層型ストレージの概要 + +階層型ストレージを使用すると、アクセス頻度の低いテーブルまたはパーティションのデータを、SQL のセマンティクスを変えずに、より低コストなストレージ階層へ移動できます。このページでは、Infrequent Access (IA) ストレージを使用するかどうかを判断できるように、アーキテクチャ、トレードオフ、適用シナリオのガイドラインを説明します。 + +> **Note:** +> +> 階層型ストレージは、{{{ .premium }}} と {{{ .byoc }}} 向けに **プライベートプレビュー** として提供されており、デフォルトでは無効です。使用するには、[TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md) に連絡して、インスタンスで有効化してもらう必要があります。このページで説明する動作は、現在のプレビュー実装に基づいており、一般提供 (GA) 前に変更される可能性があります。 + +## はじめに {#introduction} + +階層型ストレージは、{{{ .premium }}} と {{{ .byoc }}} で利用できる、**テーブルレベルおよびパーティションレベルのストレージ階層化機能**です。アクセス頻度の低いデータ向けに設計されています。テーブルまたはパーティションを Infrequent Access (IA) ストレージクラスに割り当てることができます。システムは完全なデータセットをリモートオブジェクトストレージ（Amazon S3 や Alibaba Cloud OSS など）に保存し、ローカルストレージにはメタデータと、必要に応じてキャッシュされるホットデータセグメントのみを保持します。 + +アプリケーションの観点では、IA テーブルは Standard テーブルと同様に動作します。すべてのクエリ、トランザクション、バックアップ、リカバリのセマンティクスは変わりません。主な違いはコストと性能のトレードオフにあります。ローカルストレージの使用量は大幅に削減されますが、コールドリード（必要なデータがローカルキャッシュにない場合）は、まずリモートオブジェクトストレージからデータを取得する必要があるため、レイテンシーが高くなります。 + +主な機能: + +- **透過的なセマンティクス**: `SELECT`、`INSERT`、`UPDATE`、`DELETE` を含むすべての SQL 操作は、Standard テーブルと同じように動作します。 +- **低いストレージコスト**: データは低コストなオブジェクトストレージに保存され、ホットデータのみがローカルにキャッシュされます。一般的なシナリオでは、ストレージコストを約 50% 削減できます。実際の削減率は、選択した IA キャッシュレベルによって異なります。詳細は [TiDB Cloud課金](/tidb-cloud/tidb-cloud-billing.md) を参照してください。 +- **きめ細かな制御**: テーブルレベルとパーティションレベルの両方のストレージ階層化をサポートします。パーティションレベルの設定はテーブルレベルの設定より優先されます。 +- **柔軟な変換**: IA と Standard の各ストレージクラス間で、データ損失なく双方向に変換できます。 +- **シームレスな統合**: Raft リージョン、MVCC、BR によるバックアップとリストア、TiCDC、およびその他の TiDB コンポーネントと完全に統合されています。 +- **可観測性と調整可能性**: 変換の進行状況、IA 読み取りメトリクス、クラスター全体のキャッシュヒット率は SQL 出力および Cloud Console で確認でき、IA キャッシュレベルも設定可能です。 + +## 使用シナリオ {#usage-scenarios} + +このセクションでは、IA ストレージの推奨シナリオと非推奨シナリオ、および IA を使用するかどうかを判断するためのチェックリストを説明します。 + +### 推奨シナリオ {#recommended-scenarios} + +| ビジネスシナリオ | データ特性 | 推奨されるコールド/ホット境界 | +|-|-|-| +| EC の履歴注文 / 金融トランザクション | 書き込みが頻繁、直近データの読み書きが多い、履歴データの変更はまれ | 6 か月 | +| 会計伝票 / 監査ログ / 請求書 | 一度書き込んだらほとんど変更されず、7～15 年保持 | 2 年 | +| アプリケーションログ / 監視メトリクス / API 呼び出し | 高スループット書き込み、直近のトラブルシューティングで頻繁に参照 | 90 日 | +| ソーシャルメディアの投稿 / コメント / 写真メタデータ | 初期にピークがあり、その後時間とともに減少 | 30～90 日 | +| 産業用センサー / コネクテッドカー | 非常に高い書き込みスループット、直近データのリアルタイム監視 | 1 年 | +| データウェアハウスの履歴分析 | バルク書き込み、更新は少ない、履歴トレンド分析 | 90 日 | +| AI 対話履歴 / メモリ | セッションベースの書き込み、直近アクセスは高頻度、履歴はユーザープロファイリングに利用 | 180 日 | +| LLM 学習用データセット | 学習中は高頻度、完了後は急激に低下 | 学習終了 + 30 日 | +| AI 推論ログ / 結果 | 高並行書き込み、直近監視、履歴最適化 | 90 日 | +| ベクトルデータベース | 更新はまれ、直近クエリは頻繁 | 30～90 日 | + +**一般的な目安**: データ量が大きい + 時間とともにアクセス頻度が低下する + 応答時間に厳しい要件のないクエリが時々ある → IA に適しています。 + +### 非推奨シナリオ {#not-recommended-scenarios} + +- 厳しいレイテンシー要件がある **ホット OLTP テーブル**（ミリ秒単位の遅延にも敏感な中核となるオンライントランザクションテーブル） +- **広範囲スキャンを頻繁に必要とする**データセット（大量のコールドデータに継続的にアクセスする AP クエリ） +- IA と Standard の間で **頻繁な切り替え** が必要なテーブル +- アクセスパターンが **非常に分散** しており、局所性がほとんどないデータ +- アクセスパターンが「時間とともに減少する」傾向に従わないシナリオ + +### 判断チェックリスト {#decision-checklist} + +IA を設定する前に、各項目を確認してください。 + +- [ ] テーブル/パーティションのデータアクセス頻度が、業務上の観点から低下していることを確認済みである +- [ ] テーブルをパーティションテーブルに変更できる。パーティションテーブルの方がコールド/ホットデータ分離を管理しやすいため +- [ ] 通常テーブルでコールド/ホット分離を行う場合、ホットデータがテーブル全体の 10% 未満である +- [ ] コールドデータのアクセス頻度が非常に低い。たとえば、オブジェクトストレージ帯域を飽和させないよう、クエリ QPS が 10 を超えない +- [ ] IA テーブルに対して、広範囲の AP スキャンを頻繁に実行する必要がない +- [ ] コールドリードのレイテンシーを許容できる。1 つの SQL 実行で複数のリモートリクエストが発生する可能性があり、レイテンシーはキャッシュ状態、リクエスト並列度、アクセスするコールドデータ量によって変動する +- [ ] コールドリードには読み取り増幅があることを理解している。100 バイトの単一レコードでも、最大 30,000 倍の増幅（約 3 MiB のコールドデータ）を示す可能性がある +- [ ] 1 クエリで関与するコールドデータ量が 100 MiB を超えない +- [ ] 1 クエリでアクセスするコールドデータの行数が 100 行を超えない +- [ ] 観察期間を計画済みである（最初のパーティションについて少なくとも 1 営業日全体） +- [ ] IA → Standard への切り戻しには長時間かかり、大きな帯域コストが発生することを理解している + +## 実装原理 {#implementation-principles} + +このセクションでは、階層型ストレージのアーキテクチャ、データストレージ階層、読み取り増幅の分析、および LSM-Tree の書き込みパスについて説明します。 + +### アーキテクチャの概要 {#architecture-overview} + +階層型ストレージの実装は、TiDB → TiKV → Object Store の 3 層アーキテクチャにまたがります。 + +``` +┌──────────────────────────────────────────────────────────────────┐ +│ TiDB Schema Layer │ +│ · STORAGE_CLASS / ENGINE_ATTRIBUTE written to TiDB schema │ +└──────────────────────────────────────────────────────────────────┘ + ↓ +┌──────────────────────────────────────────────────────────────────┐ +│ TiKV Region Management Layer │ +│ · IA tables/partitions occupy dedicated regions, avoiding │ +│ hot/cold data in the same shard │ +└──────────────────────────────────────────────────────────────────┘ + ↓ +┌──────────────────────────────────────────────────────────────────┐ +│ TiKV IA Cache Management Layer (IaManager) │ +│ · Local cache for cold storage data │ +└──────────────────────────────────────────────────────────────────┘ + ↓ +┌──────────────────────────────────────────────────────────────────┐ +│ Remote Object Storage (S3/OSS) │ +│ · Full SST data stored as whole objects, not by segment │ +└──────────────────────────────────────────────────────────────────┘ +``` + +**Raft ChangeSet により一貫性を保証**: ストレージクラスの変更は、Raft ChangeSet を介してすべてのレプリカに複製されます。これにより、再起動、リカバリ、分割、マージをまたいでも、関連するすべてのシャードが一貫したストレージクラス状態を維持し、リージョントポロジーの変更によるデータ損失や破損を防ぎます。 + +### ローカルキャッシュとキャッシュレベル {#local-cache-and-cache-level} + +IaManager レイヤーは、各 TiKV ノード上に IA データのローカルキャッシュを保持します。どれだけのデータをキャッシュできるかは IA キャッシュレベルによって決まり、キャッシュ用に予約されたローカルディスク容量が上限となります。 + +キャッシュレベルはクラスター全体の設定で、**Economy**、**Default**、**Balanced**、**Deep** の 4 つのオプションがあります。レベルが高いほど、より大きな割合の IA データがキャッシュされ、キャッシュヒット率とコストが上がります。エビクションはシステムによって管理されるため、どのデータをキャッシュに残すかを指定することはできず、個々のテーブルやパーティションごとに異なるレベルを設定することもできません。キャッシュレベルの変更方法については、[階層型ストレージの設定と管理](/tidb-cloud/tiered-storage-guide.md) を参照してください。 + +### データストレージ階層 {#data-storage-hierarchy} + +SSTable の内部階層は上から下へ次のとおりです。 + +``` +SSTable ──→ Segment ──→ Block ──→ KV Pair +(file) (1 MiB) (32 KiB) (single record) +``` + +| レイヤー | デフォルトサイズ | 役割 | +|-|-|-| +| **Segment** | 1 MiB | TiKV がオブジェクトストレージから読み取り、ローカルキャッシュへ書き込む **最小単位**。API 呼び出しコストや QPS 制限を招く可能性のある過剰な小リクエストを回避します | +| **Block** | 32 KiB | ローカルファイル読み取り、圧縮、および **メモリ/ディスクキャッシュ** の基本単位 | + +これは、キャッシュミス時に単一の KV レコードだけを取得するのではなく、Segment 全体をローカルストレージにロードすることを意味します。その後のクエリが同じセグメント内のデータにヒットすれば、ホットリード性能の恩恵を受けられます。一方で、後続アクセスのない一度きりのクエリでは、読み取り増幅のペナルティが比較的大きくなります。 + +Segment はローカルキャッシュのみを構成します。オブジェクトストレージでは、SST ファイルは単一の完全なオブジェクトとして保存され、セグメントに分割されません。そのため、セグメントサイズを変更しても、オブジェクトストレージ内のデータが再書き込みされることはありません。{{{ .byoc }}} では、セグメントサイズを設定できます。詳細は [階層型ストレージの設定と管理](/tidb-cloud/tiered-storage-guide.md) を参照してください。 + +### 読み取り増幅の分析 {#read-amplification-analysis} + +**キャッシュミス時の読み取り増幅パス**: + +``` +User queries 1 record (100 Bytes) +→ Block cache miss +→ TiKV loads segments from 3 LSM levels from object storage +→ Approximately 3 MiB data fetched from object storage to local +→ Read amplification: ~30,000× +``` + +キャッシュミスごとに取得されるデータ量は、セグメントサイズに比例して増加します。上記の数値は、デフォルトのセグメントサイズ 1 MiB を前提としています。 + +この増幅は、次の 2 つのシナリオで異なる形で現れます。 + +- **後続の再利用がある場合**: ロードされたセグメントは IA キャッシュに保持され、その後のヒットはホットリードになるため、初回の増幅コストが償却されます +- **一度きりのクエリ**: たとえば、大規模な範囲スキャンを実行するアドホック分析では、ロードされたデータが再利用されず、読み取りコストが非常に高くなります。さらに、新たにロードされたデータによってローカルキャッシュから「古いデータ」が追い出されます。この古いデータが実際のホットスポットである場合、その追い出しによって新たなキャッシュミスが発生し、連鎖的な性能影響を引き起こす可能性があります + +したがって、階層型ストレージは、頻繁な広範囲スキャンよりも、**小さく集中したクエリパターン** に最も適しています。 + +### LSM-Tree の書き込みパス {#lsm-tree-write-path} + +書き込みパスは Standard テーブルと同じです。 + +``` +INSERT/UPDATE/DELETE +→ Memtable (hot write, unaffected by IA) +→ L0 SST (hot write, unaffected by IA) +→ L1+ SST (after compaction, opened in IA mode based on storage class) +``` + +- 書き込みは引き続き最初に memtable/L0 に入るため、ローカルのホットパスが直接リモート書き込みになることはありません +- IA 条件に一致する L1+ ファイルは、リロードまたはコンパクションの後に IA モードで開かれます +- `memtable` や `L0` のようなホット書き込みパスは、直接 IA に入ることはありません +- IA の主な対象は Write CF の L1+ レイヤーです + +このことは、ストレージコスト削減が厳密な値ではなく概算になる理由も説明しています。IA ストレージ領域がカバーするのは、テーブルの L1 以深のレイヤーのみです。memtable と L0 ファイルはローカルディスク上に残り、IA ストレージとしてはカウントされません。そのため、テーブル全体の容量は memtable、L0、L1+ データの合計になります。テーブルのどの程度が実際に IA ストレージへ移動したかは、書き込みレートとコンパクションの進行状況に依存します。 + +## 変換効率 {#conversion-efficiency} + +`STORAGE_CLASS` 形式でも `ENGINE_ATTRIBUTE` 形式でも、ストレージクラスを変更する `ALTER TABLE` 文は、スキーマメタデータを更新するだけなので数秒で完了します。その後、リージョンレベルのデータ移行が TiKV で非同期に実行されるため、全体の所要時間はデータ量と変換方向に依存します。 + +### Standard → IA {#standard-ia} + +テスト参考値: 約 1 TB の論理データ（インデックスを含む）は 5 分以内に変換が完了し、その間の QPS とレイテンシーへの影響はごくわずかでした。単一 TiKV の CPU 使用量は約 0.5c 増加し、約 5 分以内に回復しました。 + +``` +TiDB schema takes effect → Schema Manager sync (30s) → TiKV broadcast +→ Region alignment / Split → ChangeSet updates Shard → Reload files +``` + +### IA → Standard {#ia-standard} + +テスト参考値: 2.09 TB の論理データ（インデックスを含む）は約 3 時間 10 分を要しました（TiKV あたり約 1.61k リージョン/時）。オブジェクトストレージの GET スループットは約 1.6 GiB/s でした。変換中、Standard パーティションの QPS は約 3.78% 低下し、P99 は約 18.63% 増加し、単一 TiKV の CPU 使用量は約 0.5c 増加しました。 + +``` +Same chain as above + full object storage data download to local +``` + +> **Note:** +> +> これらの数値はテスト環境から得られたものであり、実際の本番シナリオを表すものではありません。正確なデータは、自身の業務テストに基づいて取得してください。 + +進行中の変換を `SHOW STORAGE_CLASS TRANSITIONS` で追跡する方法、または過去の変換時間を `mysql.tidb_storage_class_transition_history` で確認する方法については、[階層型ストレージの可観測性](/tidb-cloud/tiered-storage-observability.md) を参照してください。 diff --git a/tidb-lightning/monitor-tidb-lightning.md b/tidb-lightning/monitor-tidb-lightning.md index c248f65e6683a..17d8096da9a3e 100644 --- a/tidb-lightning/monitor-tidb-lightning.md +++ b/tidb-lightning/monitor-tidb-lightning.md @@ -140,10 +140,10 @@ scrape_configs: アイドル状態のワーカーをカウントします。ラベル: - **name**: - - `table` : `table-concurrency`の余り。通常はプロセス終了まで 0 です。 - - `index` : `index-concurrency`の余り。通常はプロセス終了まで 0 です。 - - `region` : `region-concurrency`の余り。通常はプロセス終了まで 0 です。 - - `io` : `io-concurrency`の余り。通常は設定された値（デフォルトは 5）に近い。0 に近い場合はディスクが遅すぎることを意味する。 + - `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`** (カウンター) diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index 67ffcb4aec2cd..60beadf0e4303 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -181,7 +181,7 @@ OOM のトラブルシューティングの詳細については、 [TiDBのメ `Decimal`の乗算では、範囲外が回避され、精度が最大精度制限に設定されるため、この問題は発生しません。 - - 解決策： `a`と`b`が目標精度である`Cast(xx as decimal(a, b))`を手動で追加することで、この問題を回避できます。 + - 解決策： `a`が目標精度、`b`が目標スケールである`Cast(xx as decimal(a, b))`を手動で追加することで、この問題を回避できます。 ### 3.5 クエリの遅延に関する問題 {#35-slow-query-issues}