diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 6003977744ebe..0809c8ac63244 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -74,7 +74,7 @@ TiDB 用の新しいドキュメントを作成する場合は、当社のスタ 1. プロジェクトを訪問: [https://github.com/pingcap/docs](https://github.com/pingcap/docs) 2. 右上の**フォーク**ボタンをクリックし、完了するまで待ちます。 -### ステップ2: フォークしたリポジトリをローカルstorageにクローンする {#step-2-clone-the-forked-repository-to-local-storage} +### ステップ2: フォークしたリポジトリをローカルストレージにクローンする {#step-2-clone-the-forked-repository-to-local-ストレージ} cd $working_dir # Comes to the directory that you want put the fork in, for example, "cd ~/Documents/GitHub" git clone git@github.com:$user/docs.git # Replace "$user" with your GitHub ID diff --git a/TOC-ai.md b/TOC-ai.md index 0f95bdf3aab9d..0b4fb910e111a 100644 --- a/TOC-ai.md +++ b/TOC-ai.md @@ -30,7 +30,7 @@ - [再ランキング](/ai/guides/reranking.md) - [結合クエリ](/ai/guides/join-queries.md) - [生のSQLクエリ](/ai/guides/raw-queries.md) - - [取引](/ai/guides/transactions.md) + - [トランザクション](/ai/guides/transactions.md) ## 例 {#examples} @@ -58,7 +58,7 @@ - [Google ジェミニ](/ai/integrations/vector-search-auto-embedding-gemini.md) - [抱きしめる顔](/ai/integrations/vector-search-auto-embedding-huggingface.md) - [NVIDIA NIM](/ai/integrations/vector-search-auto-embedding-nvidia-nim.md) - - [アマゾンタイタン](/ai/integrations/vector-search-auto-embedding-amazon-titan.md) + - [Amazon Titan](/ai/integrations/vector-search-auto-embedding-amazon-titan.md) - AIフレームワーク - [ランチェーン](/ai/integrations/vector-search-integrate-with-langchain.md) - [ラマインデックス](/ai/integrations/vector-search-integrate-with-llamaindex.md) diff --git a/TOC-api.md b/TOC-api.md index f96aac82c2989..5e4a6a0a2fdb4 100644 --- a/TOC-api.md +++ b/TOC-api.md @@ -11,7 +11,7 @@ - [API v1beta1](/api/tidb-cloud-api-v1beta1.md) - [API v1beta](/api/tidb-cloud-api-v1beta.md) -## TIDB セルフマネージド {#tidb-self-managed} +## TIDB Self-Managed {#tidb-self-managed} - [TiProxy API](/api/tiproxy-api-overview.md) - [データ移行API](/api/dm-api-overview.md) diff --git a/TOC-develop.md b/TOC-develop.md index ee0f2cadac9e2..41b474d001664 100644 --- a/TOC-develop.md +++ b/TOC-develop.md @@ -75,7 +75,7 @@ - [複数テーブル結合クエリ](/develop/dev-guide-join-tables.md) - [サブクエリ](/develop/dev-guide-use-subqueries.md) - [結果のページ分割](/develop/dev-guide-paginate-results.md) - - [閲覧数](/develop/dev-guide-use-views.md) + - [ビュー](/develop/dev-guide-use-views.md) - [一時テーブル](/develop/dev-guide-use-temporary-tables.md) - [共通テーブル式](/develop/dev-guide-use-common-table-expression.md) - レプリカデータの読み取り @@ -83,9 +83,9 @@ - [ステイル読み取り](/develop/dev-guide-use-stale-read.md) - [HTAPクエリ](/develop/dev-guide-hybrid-oltp-and-olap-queries.md) - [ベクトル検索](/develop/dev-guide-vector-search.md)![BETA](/media/tidb-cloud/blank_transparent_placeholder.png) -- 取引の管理 +- トランザクションの管理 - [概要](/develop/dev-guide-transaction-overview.md) - - [楽観的取引と悲観的取引](/develop/dev-guide-optimistic-and-pessimistic-transaction.md) + - [楽観的トランザクションと悲観的トランザクション](/develop/dev-guide-optimistic-and-pessimistic-transaction.md) - [トランザクション制限](/develop/dev-guide-transaction-restraints.md) - [トランザクションエラーの処理](/develop/dev-guide-transaction-troubleshoot.md) - 最適化する diff --git a/TOC-tidb-cloud-essential.md b/TOC-tidb-cloud-essential.md index 42fb6b07d4cae..169a1614a8793 100644 --- a/TOC-tidb-cloud-essential.md +++ b/TOC-tidb-cloud-essential.md @@ -18,7 +18,7 @@ - [概要](/tidb-cloud/key-concepts.md) - [アーキテクチャ](/tidb-cloud/architecture-concepts.md) - [データベーススキーマ](/tidb-cloud/database-schema-concepts.md) - - [取引](/tidb-cloud/transaction-concepts.md) + - [トランザクション](/tidb-cloud/transaction-concepts.md) - [SQL](/tidb-cloud/sql-concepts.md) - [AI機能](/tidb-cloud/ai-feature-concepts.md) - [拡張性](/tidb-cloud/scalability-concepts.md) @@ -78,7 +78,7 @@ - [MPPに関する質問](/explain-mpp.md) - [サブクエリ](/explain-subqueries.md) - [集計](/explain-aggregation.md) - - [閲覧数](/explain-views.md) + - [ビュー](/explain-views.md) - [パーティション](/explain-partitions.md) - [インデックスマージ](/explain-index-merge.md) - SQL最適化プロセス @@ -113,9 +113,9 @@ - [オプティマイザー修正コントロール](/optimizer-fix-controls.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) - - ごみ収集（GC） + - ガベージコレクション（GC） - [概要](/garbage-collection-overview.md) - - [コンフィグレーション](/garbage-collection-configuration.md) + - [設定](/garbage-collection-configuration.md) - [TiFlashのパフォーマンスをチューニング](/tiflash/tune-tiflash-performance.md) - [TiDBのバージョンをアップグレードする](/tidb-cloud/upgrade-tidb-cluster.md) - [TiDB Cloud Essentialインスタンスを削除する](/tidb-cloud/delete-tidb-cluster.md) @@ -124,7 +124,7 @@ - TiDB Cloudへのデータ移行 - [データ移行を使用して既存データと増分データを移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md) - [データ移行を使用して増分データを移行する](/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md) - - [TiDBセルフマネージドからTiDB Cloudへの移行](/tidb-cloud/migrate-from-op-tidb.md) + - [TiDB Self-ManagedからTiDB Cloudへの移行](/tidb-cloud/migrate-from-op-tidb.md) - [大規模データセットのMySQLシャードを移行およびマージする](/tidb-cloud/migrate-sql-shards.md) - [AWS DMSを使用してAmazon RDS for Oracleから移行する](/tidb-cloud/migrate-from-oracle-using-aws-dms.md) - TiDB Cloudにデータをインポートする @@ -135,7 +135,7 @@ - [クラウドストレージからスナップショットファイルをインポートする](/tidb-cloud/import-snapshot-files-serverless.md) - [MySQL CLI を使用したインポート](/tidb-cloud/import-with-mysql-cli-serverless.md) - 参照 - - [TiDB Cloudの外部ストレージアクセスを設定する](/tidb-cloud/configure-external-storage-access.md) + - [TiDB Cloudの外部ストレージアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md) - [データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md) - [データインポートのためのCSV設定](/tidb-cloud/csv-config-for-import-data.md) - [Amazon S3からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング](/tidb-cloud/troubleshoot-import-access-denied-error.md) @@ -193,21 +193,21 @@ - [`tidbcloud_serverless_export`リソースを使用する](/tidb-cloud/terraform-use-serverless-export-resource.md) - [`tidbcloud_sql_user`リソースを使用する](/tidb-cloud/terraform-use-sql-user-resource.md) - [`tidbcloud_import`リソースを使用する](/tidb-cloud/terraform-use-import-resource.md) - - [クラスタリソースの移行](/tidb-cloud/terraform-migrate-cluster-resource.md) + - [クラスターリソースの移行](/tidb-cloud/terraform-migrate-cluster-resource.md) - [ヴェルセル](/tidb-cloud/integrate-tidbcloud-with-vercel.md) - [ザピアー](/tidb-cloud/integrate-tidbcloud-with-zapier.md) ## 参照 {#reference} - SQLリファレンス - - [TiDBでSQLを探求しよう](/basic-sql-operations.md) + - [TiDBでのSQL基本操作](/basic-sql-operations.md) - SQL言語の構造と構文 - 属性 - [自動インクリメント](/auto-increment.md) - - [自動乱数](/auto-random.md) + - [AUTO_RANDOM](/auto-random.md) - [_tidb_rowid](/tidb-rowid.md) - [SHARD_ROW_ID_BITS](/shard-row-id-bits.md) - - [文字通りの値](/literal-values.md) + - [リテラル値](/literal-values.md) - [スキーマオブジェクト名](/schema-object-names.md) - [キーワードと予約語](/keywords.md) - [ユーザー定義変数](/user-defined-variables.md) @@ -385,13 +385,13 @@ - [生成された列](/generated-columns.md) - [SQLモード](/sql-mode.md) - [テーブル属性](/table-attributes.md) - - 取引 + - トランザクション - [概要](/transaction-overview.md) - [隔離レベル](/transaction-isolation-levels.md) - - [楽観的な取引](/optimistic-transaction.md) - - [悲観的な取引](/pessimistic-transaction.md) + - [楽観的なトランザクション](/optimistic-transaction.md) + - [悲観的なトランザクション](/pessimistic-transaction.md) - [非トランザクションDMLステートメント](/non-transactional-dml.md) - - [閲覧数](/views.md) + - [ビュー](/views.md) - [パーティショニング](/partitioned-table.md) - [一時テーブル](/temporary-tables.md) - [キャッシュされたテーブル](/cached-tables.md) @@ -438,7 +438,7 @@ - [`STATISTICS`](/information-schema/information-schema-statistics.md) - [`TABLES`](/information-schema/information-schema-tables.md) - [`TABLE_CONSTRAINTS`](/information-schema/information-schema-table-constraints.md) - - [`TABLE_STORAGE_STATS`](/information-schema/information-schema-table-storage-stats.md) + - [`TABLE_STORAGE_STATS`](/information-schema/information-schema-table-ストレージ-stats.md) - [`TIDB_CHECK_CONSTRAINTS`](/information-schema/information-schema-tidb-check-constraints.md) - [`TIDB_INDEXES`](/information-schema/information-schema-tidb-indexes.md) - [`TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md) @@ -529,15 +529,15 @@ - 一般参考資料 - TiDBクラシックアーキテクチャ - [概要](/tidb-architecture.md) - - [ストレージ](/tidb-storage.md) + - [ストレージ](/tidb-ストレージ.md) - [コンピューティング](/tidb-computing.md) - [スケジュール](/tidb-scheduling.md) - [TSO](/tso.md) - [TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md) - ストレージエンジン - - ティクヴ + - TiKV - [TiKVの概要](/tikv-overview.md) - - [RocksDBの概要](/storage-engine/rocksdb-overview.md) + - [RocksDBの概要](/ストレージ-engine/rocksdb-overview.md) - TiFlash - [TiFlashの概要](/tiflash/tiflash-overview.md) - [ディスクに書き出す](/tiflash/tiflash-spill-disk.md) @@ -551,7 +551,7 @@ - [システム変数](/system-variables.md) - [サーバー状態変数](/status-variables.md) - [テーブルフィルター](/table-filter.md) - - [外部ストレージサービスのURI形式](/external-storage-uri.md) + - [外部ストレージサービスのURI形式](/external-ストレージ-uri.md) - [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md) - [通知](/tidb-cloud/notifications.md) - [TiDB Cloud StarterおよびEssential向けプロジェクトAPI移行ガイド](/tidb-cloud/tidbx-starter-essential-project-api-migration-guide.md) diff --git a/TOC-tidb-cloud-premium.md b/TOC-tidb-cloud-premium.md index f9776b9a1c034..ca65ff7b708ab 100644 --- a/TOC-tidb-cloud-premium.md +++ b/TOC-tidb-cloud-premium.md @@ -17,7 +17,7 @@ - [概要](/tidb-cloud/key-concepts.md) - [アーキテクチャ](/tidb-cloud/architecture-concepts.md) - [データベーススキーマ](/tidb-cloud/database-schema-concepts.md) - - [取引](/tidb-cloud/transaction-concepts.md) + - [トランザクション](/tidb-cloud/transaction-concepts.md) - [SQL](/tidb-cloud/sql-concepts.md) - [AI機能](/tidb-cloud/ai-feature-concepts.md) - [拡張性](/tidb-cloud/scalability-concepts.md) @@ -72,7 +72,7 @@ - [MPPに関する質問](/explain-mpp.md) - [サブクエリ](/explain-subqueries.md) - [集計](/explain-aggregation.md) - - [閲覧数](/explain-views.md) + - [ビュー](/explain-views.md) - [パーティション](/explain-partitions.md) - [インデックスマージ](/explain-index-merge.md) - SQL最適化プロセス @@ -125,7 +125,7 @@ - [クラウドストレージからスナップショットファイルをインポートする](/tidb-cloud/import-snapshot-files-serverless.md) - [MySQL CLI を使用したデータのインポート](/tidb-cloud/premium/import-with-mysql-cli-premium.md) - 参照 - - [TiDB Cloudの外部ストレージアクセスを設定する](/tidb-cloud/configure-external-storage-access.md) + - [TiDB Cloudの外部ストレージアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md) - [データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md) - [データインポートのためのCSV設定](/tidb-cloud/csv-config-for-import-data.md) - [Amazon S3からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング](/tidb-cloud/troubleshoot-import-access-denied-error.md) @@ -179,14 +179,14 @@ ## 参照 {#reference} - SQLリファレンス - - [TiDBでSQLを探求しよう](/basic-sql-operations.md) + - [TiDBでのSQL基本操作](/basic-sql-operations.md) - SQL言語の構造と構文 - 属性 - [自動インクリメント](/auto-increment.md) - - [自動乱数](/auto-random.md) + - [AUTO_RANDOM](/auto-random.md) - [_tidb_rowid](/tidb-rowid.md) - [SHARD_ROW_ID_BITS](/shard-row-id-bits.md) - - [文字通りの値](/literal-values.md) + - [リテラル値](/literal-values.md) - [スキーマオブジェクト名](/schema-object-names.md) - [キーワードと予約語](/keywords.md) - [ユーザー定義変数](/user-defined-variables.md) @@ -364,13 +364,13 @@ - [生成された列](/generated-columns.md) - [SQLモード](/sql-mode.md) - [テーブル属性](/table-attributes.md) - - 取引 + - トランザクション - [概要](/transaction-overview.md) - [隔離レベル](/transaction-isolation-levels.md) - - [楽観的な取引](/optimistic-transaction.md) - - [悲観的な取引](/pessimistic-transaction.md) + - [楽観的なトランザクション](/optimistic-transaction.md) + - [悲観的なトランザクション](/pessimistic-transaction.md) - [非トランザクションDMLステートメント](/non-transactional-dml.md) - - [閲覧数](/views.md) + - [ビュー](/views.md) - [パーティショニング](/partitioned-table.md) - [一時テーブル](/temporary-tables.md) - [キャッシュされたテーブル](/cached-tables.md) @@ -417,7 +417,7 @@ - [`STATISTICS`](/information-schema/information-schema-statistics.md) - [`TABLES`](/information-schema/information-schema-tables.md) - [`TABLE_CONSTRAINTS`](/information-schema/information-schema-table-constraints.md) - - [`TABLE_STORAGE_STATS`](/information-schema/information-schema-table-storage-stats.md) + - [`TABLE_STORAGE_STATS`](/information-schema/information-schema-table-ストレージ-stats.md) - [`TIDB_CHECK_CONSTRAINTS`](/information-schema/information-schema-tidb-check-constraints.md) - [`TIDB_INDEXES`](/information-schema/information-schema-tidb-indexes.md) - [`TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md) @@ -440,15 +440,15 @@ - 一般参考資料 - TiDBクラシックアーキテクチャ - [概要](/tidb-architecture.md) - - [ストレージ](/tidb-storage.md) + - [ストレージ](/tidb-ストレージ.md) - [コンピューティング](/tidb-computing.md) - [スケジュール](/tidb-scheduling.md) - [TSO](/tso.md) - [TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md) - ストレージエンジン - - ティクヴ + - TiKV - [TiKVの概要](/tikv-overview.md) - - [RocksDBの概要](/storage-engine/rocksdb-overview.md) + - [RocksDBの概要](/ストレージ-engine/rocksdb-overview.md) - TiFlash - [TiFlashの概要](/tiflash/tiflash-overview.md) - [ディスクに書き出す](/tiflash/tiflash-spill-disk.md) @@ -461,7 +461,7 @@ - [システム変数](/system-variables.md) - [サーバー状態変数](/status-variables.md) - [テーブルフィルター](/table-filter.md) - - [外部ストレージサービスのURI形式](/external-storage-uri.md) + - [外部ストレージサービスのURI形式](/external-ストレージ-uri.md) - [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md) - [通知](/tidb-cloud/notifications.md) - サポートプラン diff --git a/TOC-tidb-cloud-starter.md b/TOC-tidb-cloud-starter.md index c104ab3e657a5..049478fbd4da6 100644 --- a/TOC-tidb-cloud-starter.md +++ b/TOC-tidb-cloud-starter.md @@ -19,7 +19,7 @@ - [概要](/tidb-cloud/key-concepts.md) - [アーキテクチャ](/tidb-cloud/architecture-concepts.md) - [データベーススキーマ](/tidb-cloud/database-schema-concepts.md) - - [取引](/tidb-cloud/transaction-concepts.md) + - [トランザクション](/tidb-cloud/transaction-concepts.md) - [SQL](/tidb-cloud/sql-concepts.md) - [AI機能](/tidb-cloud/ai-feature-concepts.md) - [データサービス](/tidb-cloud/data-service-concepts.md)![BETA](/media/tidb-cloud/blank_transparent_placeholder.png) @@ -75,7 +75,7 @@ - [MPPに関する質問](/explain-mpp.md) - [サブクエリ](/explain-subqueries.md) - [集計](/explain-aggregation.md) - - [閲覧数](/explain-views.md) + - [ビュー](/explain-views.md) - [パーティション](/explain-partitions.md) - [インデックスマージ](/explain-index-merge.md) - SQL最適化プロセス @@ -110,16 +110,16 @@ - [オプティマイザー修正コントロール](/optimizer-fix-controls.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) - - ごみ収集（GC） + - ガベージコレクション（GC） - [概要](/garbage-collection-overview.md) - - [コンフィグレーション](/garbage-collection-configuration.md) + - [設定](/garbage-collection-configuration.md) - [TiFlashのパフォーマンスをチューニング](/tiflash/tune-tiflash-performance.md) - [TiDBのバージョンをアップグレードする](/tidb-cloud/upgrade-tidb-cluster.md) - [TiDB Cloud Starterインスタンスを削除する](/tidb-cloud/delete-tidb-cluster.md) - データの移行またはインポート - [概要](/tidb-cloud/tidb-cloud-migration-overview.md) - TiDB Cloudへのデータ移行 - - [TiDBセルフマネージドからTiDB Cloudへの移行](/tidb-cloud/migrate-from-op-tidb.md) + - [TiDB Self-ManagedからTiDB Cloudへの移行](/tidb-cloud/migrate-from-op-tidb.md) - [大規模データセットのMySQLシャードを移行およびマージする](/tidb-cloud/migrate-sql-shards.md) - [AWS DMSを使用してAmazon RDS for Oracleから移行する](/tidb-cloud/migrate-from-oracle-using-aws-dms.md) - TiDB Cloudにデータをインポートする @@ -130,7 +130,7 @@ - [クラウドストレージからスナップショットファイルをインポートする](/tidb-cloud/import-snapshot-files-serverless.md) - [MySQL CLI を使用したインポート](/tidb-cloud/import-with-mysql-cli-serverless.md) - 参照 - - [TiDB Cloudの外部ストレージアクセスを設定する](/tidb-cloud/configure-external-storage-access.md) + - [TiDB Cloudの外部ストレージアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md) - [データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md) - [データインポートのためのCSV設定](/tidb-cloud/csv-config-for-import-data.md) - [Amazon S3からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング](/tidb-cloud/troubleshoot-import-access-denied-error.md) @@ -153,7 +153,7 @@ - [Postmanで実行](/tidb-cloud/data-service-postman-integration.md) - [GitHubで自動デプロイ](/tidb-cloud/data-service-manage-github-connection.md) - [Next.jsでOpenAPI仕様を使用する](/tidb-cloud/data-service-oas-with-nextjs.md) - - [データアプリコンフィグレーションファイル](/tidb-cloud/data-service-app-config-files.md) + - [データアプリ設定ファイル](/tidb-cloud/data-service-app-config-files.md) - [応答とステータスコード](/tidb-cloud/data-service-response-and-status-code.md) - Security - [Security概要](/tidb-cloud/security-overview.md) @@ -197,21 +197,21 @@ - [`tidbcloud_serverless_export`リソースを使用する](/tidb-cloud/terraform-use-serverless-export-resource.md) - [`tidbcloud_sql_user`リソースを使用する](/tidb-cloud/terraform-use-sql-user-resource.md) - [`tidbcloud_import`リソースを使用する](/tidb-cloud/terraform-use-import-resource.md) - - [クラスタリソースの移行](/tidb-cloud/terraform-migrate-cluster-resource.md) + - [クラスターリソースの移行](/tidb-cloud/terraform-migrate-cluster-resource.md) - [ヴェルセル](/tidb-cloud/integrate-tidbcloud-with-vercel.md) - [ザピアー](/tidb-cloud/integrate-tidbcloud-with-zapier.md) ## 参照 {#reference} - SQLリファレンス - - [TiDBでSQLを探求しよう](/basic-sql-operations.md) + - [TiDBでのSQL基本操作](/basic-sql-operations.md) - SQL言語の構造と構文 - 属性 - [自動インクリメント](/auto-increment.md) - - [自動乱数](/auto-random.md) + - [AUTO_RANDOM](/auto-random.md) - [_tidb_rowid](/tidb-rowid.md) - [SHARD_ROW_ID_BITS](/shard-row-id-bits.md) - - [文字通りの値](/literal-values.md) + - [リテラル値](/literal-values.md) - [スキーマオブジェクト名](/schema-object-names.md) - [キーワードと予約語](/keywords.md) - [ユーザー定義変数](/user-defined-variables.md) @@ -389,13 +389,13 @@ - [生成された列](/generated-columns.md) - [SQLモード](/sql-mode.md) - [テーブル属性](/table-attributes.md) - - 取引 + - トランザクション - [概要](/transaction-overview.md) - [隔離レベル](/transaction-isolation-levels.md) - - [楽観的な取引](/optimistic-transaction.md) - - [悲観的な取引](/pessimistic-transaction.md) + - [楽観的なトランザクション](/optimistic-transaction.md) + - [悲観的なトランザクション](/pessimistic-transaction.md) - [非トランザクションDMLステートメント](/non-transactional-dml.md) - - [閲覧数](/views.md) + - [ビュー](/views.md) - [パーティショニング](/partitioned-table.md) - [一時テーブル](/temporary-tables.md) - [キャッシュされたテーブル](/cached-tables.md) @@ -442,7 +442,7 @@ - [`STATISTICS`](/information-schema/information-schema-statistics.md) - [`TABLES`](/information-schema/information-schema-tables.md) - [`TABLE_CONSTRAINTS`](/information-schema/information-schema-table-constraints.md) - - [`TABLE_STORAGE_STATS`](/information-schema/information-schema-table-storage-stats.md) + - [`TABLE_STORAGE_STATS`](/information-schema/information-schema-table-ストレージ-stats.md) - [`TIDB_CHECK_CONSTRAINTS`](/information-schema/information-schema-tidb-check-constraints.md) - [`TIDB_INDEXES`](/information-schema/information-schema-tidb-indexes.md) - [`TIDB_INDEX_USAGE`](/information-schema/information-schema-tidb-index-usage.md) @@ -520,15 +520,15 @@ - 一般参考資料 - TiDBクラシックアーキテクチャ - [概要](/tidb-architecture.md) - - [ストレージ](/tidb-storage.md) + - [ストレージ](/tidb-ストレージ.md) - [コンピューティング](/tidb-computing.md) - [スケジュール](/tidb-scheduling.md) - [TSO](/tso.md) - [TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md) - ストレージエンジン - - ティクヴ + - TiKV - [TiKVの概要](/tikv-overview.md) - - [RocksDBの概要](/storage-engine/rocksdb-overview.md) + - [RocksDBの概要](/ストレージ-engine/rocksdb-overview.md) - TiFlash - [TiFlashの概要](/tiflash/tiflash-overview.md) - [ディスクに書き出す](/tiflash/tiflash-spill-disk.md) @@ -542,7 +542,7 @@ - [システム変数](/system-variables.md) - [サーバー状態変数](/status-variables.md) - [テーブルフィルター](/table-filter.md) - - [外部ストレージサービスのURI形式](/external-storage-uri.md) + - [外部ストレージサービスのURI形式](/external-ストレージ-uri.md) - [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md) - [通知](/tidb-cloud/notifications.md) - [TiDB Cloud StarterおよびEssential向けプロジェクトAPI移行ガイド](/tidb-cloud/tidbx-starter-essential-project-api-migration-guide.md) diff --git a/TOC-tidb-cloud.md b/TOC-tidb-cloud.md index 3e1862d85706d..8ec5d7c2542f9 100644 --- a/TOC-tidb-cloud.md +++ b/TOC-tidb-cloud.md @@ -18,7 +18,7 @@ - [概要](/tidb-cloud/key-concepts.md) - [アーキテクチャ](/tidb-cloud/architecture-concepts.md) - [データベーススキーマ](/tidb-cloud/database-schema-concepts.md) - - [取引](/tidb-cloud/transaction-concepts.md) + - [トランザクション](/tidb-cloud/transaction-concepts.md) - [SQL](/tidb-cloud/sql-concepts.md) - [AI機能](/tidb-cloud/ai-feature-concepts.md) - [データサービス](/tidb-cloud/data-service-concepts.md)![BETA](/media/tidb-cloud/blank_transparent_placeholder.png) @@ -31,14 +31,14 @@ ## ガイド {#guides} -- クラスタを計画する +- クラスターを計画する - [プランを選択してください](/tidb-cloud/select-cluster-tier.md) - [TiDBサイズを決定する](/tidb-cloud/size-your-cluster.md) - [TiDB Cloudパフォーマンスリファレンス](/tidb-cloud/tidb-cloud-performance-reference.md) - [TiDB Cloudのリソースとプロジェクトを管理する](/tidb-cloud/manage-projects-and-resources.md) - TiDB Cloud Dedicatedクラスターの管理 - - [TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md) - - TiDB Cloud Dedicatedクラスタに接続します + - [TiDB Cloud Dedicatedクラスターを作成する](/tidb-cloud/create-tidb-cluster.md) + - TiDB Cloud Dedicatedクラスターに接続します - [ネットワーク接続の概要](/tidb-cloud/connect-to-tidb-cluster.md) - [公共接続経由で接続する](/tidb-cloud/connect-via-standard-connection.md) - [AWS のプライベートエンドポイント経由で接続します](/tidb-cloud/set-up-private-endpoint-connections.md) @@ -46,9 +46,9 @@ - [プライベートエンドポイント経由でGoogle Cloudに接続します](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md) - [VPCピアリング経由で接続](/tidb-cloud/set-up-vpc-peering-connections.md) - [SQL Shell経由で接続する](/tidb-cloud/connect-via-sql-shell.md) - - [TiDB Cloud Dedicatedクラスタを拡張する](/tidb-cloud/scale-tidb-cluster.md) + - [TiDB Cloud Dedicatedクラスターを拡張する](/tidb-cloud/scale-tidb-cluster.md) - [TiDB Cloud Dedicatedデータのバックアップと復元](/tidb-cloud/backup-and-restore.md) - - [TiDB Cloud Dedicatedクラスタの一時停止または再開](/tidb-cloud/pause-or-resume-tidb-cluster.md) + - [TiDB Cloud Dedicatedクラスターの一時停止または再開](/tidb-cloud/pause-or-resume-tidb-cluster.md) - [メンテナンスウィンドウの設定](/tidb-cloud/configure-maintenance-window.md) - HTAPにはTiFlashを使用してください - [TiFlashの概要](/tiflash/tiflash-overview.md) @@ -90,7 +90,7 @@ - [MPPに関する問い合わせ](/explain-mpp.md) - [サブクエリ](/explain-subqueries.md) - [集計](/explain-aggregation.md) - - [閲覧数](/explain-views.md) + - [ビュー](/explain-views.md) - [パーティション](/explain-partitions.md) - [インデックスマージ](/explain-index-merge.md) - SQL最適化プロセス @@ -126,9 +126,9 @@ - [インデックスアドバイザー](/index-advisor.md) - [TiKV Follower Readの調整](/follower-read.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) - - ごみ収集（GC） + - ガベージコレクション（GC） - [概要](/garbage-collection-overview.md) - - [コンフィグレーション](/garbage-collection-configuration.md) + - [設定](/garbage-collection-configuration.md) - [TiFlashのパフォーマンスをチューニング](/tiflash/tune-tiflash-performance.md) - リソース割り当ての最適化 - [リソース割り当ての概要](/tidb-cloud/optimize-resource-allocation.md) @@ -143,14 +143,14 @@ - [TiProxyの概要](/tidb-cloud/tiproxy-overview-for-cloud.md) - [TiProxyを管理する](/tidb-cloud/tiproxy-management.md) - [TiDBのバージョンをアップグレードする](/tidb-cloud/upgrade-tidb-cluster.md) - - [TiDB Cloud Dedicatedクラスタを削除する](/tidb-cloud/delete-tidb-cluster.md) + - [TiDB Cloud Dedicatedクラスターを削除する](/tidb-cloud/delete-tidb-cluster.md) - データの移行またはインポート - [概要](/tidb-cloud/tidb-cloud-migration-overview.md) - TiDB Cloudへのデータ移行 - [データ移行を使用して既存データと増分データを移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md) - [データ移行を使用して増分データを移行する](/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md) - [大規模データセットのMySQLシャードを移行およびマージする](/tidb-cloud/migrate-sql-shards.md) - - [TiDBセルフマネージドからTiDB Cloudへの移行](/tidb-cloud/migrate-from-op-tidb.md) + - [TiDB Self-ManagedからTiDB Cloudへの移行](/tidb-cloud/migrate-from-op-tidb.md) - [AWS DMSを使用してMySQL互換データベースから移行する](/tidb-cloud/migrate-from-mysql-using-aws-dms.md) - [AWS DMSを使用してAmazon RDS for Oracleから移行する](/tidb-cloud/migrate-from-oracle-using-aws-dms.md) - TiDB Cloud Dedicatedへのデータインポート @@ -160,7 +160,7 @@ - [クラウドストレージからスナップショットファイルをインポートする](/tidb-cloud/import-snapshot-files.md) - [MySQL CLI を使用したインポート](/tidb-cloud/import-with-mysql-cli.md) - 参照 - - [TiDB Cloud Dedicatedの外部ストレージアクセスを構成する](/tidb-cloud/dedicated-external-storage.md) + - [TiDB Cloud Dedicatedの外部ストレージアクセスを構成する](/tidb-cloud/dedicated-external-ストレージ.md) - [データインポートの命名規則](/tidb-cloud/naming-conventions-for-data-import.md) - [データインポートのためのCSV設定](/tidb-cloud/csv-config-for-import-data.md) - [Amazon S3からのデータインポート中に発生するアクセス拒否エラーのトラブルシューティング](/tidb-cloud/troubleshoot-import-access-denied-error.md) @@ -184,7 +184,7 @@ - [Postmanで実行](/tidb-cloud/data-service-postman-integration.md) - [GitHubで自動デプロイ](/tidb-cloud/data-service-manage-github-connection.md) - [Next.jsでOpenAPI仕様を使用する](/tidb-cloud/data-service-oas-with-nextjs.md) - - [データアプリコンフィグレーションファイル](/tidb-cloud/data-service-app-config-files.md) + - [データアプリ設定ファイル](/tidb-cloud/data-service-app-config-files.md) - [応答とステータスコード](/tidb-cloud/data-service-response-and-status-code.md) - ストリームデータ - [変更フィードの概要](/tidb-cloud/changefeed-overview.md) @@ -192,7 +192,7 @@ - [カフカシンクへ](/tidb-cloud/changefeed-sink-to-apache-kafka.md) - [パルサーシンクへ](/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/changefeed-sink-to-cloud-ストレージ.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) @@ -217,7 +217,7 @@ - [AWS 上で顧客管理暗号化キーを使用した保存時の暗号化](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md) - [Azure 上で顧客管理暗号化キーを使用した保存時の暗号化](/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md) - データベースアクセス制御 - - [クラスタパスワード設定の構成](/tidb-cloud/configure-security-settings.md) + - [クラスターパスワード設定の構成](/tidb-cloud/configure-security-settings.md) - 監査管理 - [TiDB Cloud Dedicatedデータベース監査ログ](/tidb-cloud/tidb-cloud-auditing.md) - [コンソール監査ログ](/tidb-cloud/tidb-cloud-console-auditing.md) @@ -257,21 +257,21 @@ - [`tidbcloud_backup`リソースを使用する](/tidb-cloud/terraform-use-backup-resource.md) - [`tidbcloud_restore`リソースを使用する](/tidb-cloud/terraform-use-restore-resource.md) - [`tidbcloud_import`リソースを使用する](/tidb-cloud/terraform-use-import-resource.md) - - [クラスタリソースの移行](/tidb-cloud/terraform-migrate-cluster-resource.md) + - [クラスターリソースの移行](/tidb-cloud/terraform-migrate-cluster-resource.md) - [ヴェルセル](/tidb-cloud/integrate-tidbcloud-with-vercel.md) - [ザピアー](/tidb-cloud/integrate-tidbcloud-with-zapier.md) ## 参照 {#reference} - SQLリファレンス - - [TiDBでSQLを探求しよう](/basic-sql-operations.md) + - [TiDBでのSQL基本操作](/basic-sql-operations.md) - SQL言語の構造と構文 - 属性 - [自動インクリメント](/auto-increment.md) - - [自動乱数](/auto-random.md) + - [AUTO_RANDOM](/auto-random.md) - [_tidb_rowid](/tidb-rowid.md) - [SHARD_ROW_ID_BITS](/shard-row-id-bits.md) - - [文字通りの値](/literal-values.md) + - [リテラル値](/literal-values.md) - [スキーマオブジェクト名](/schema-object-names.md) - [キーワードと予約語](/keywords.md) - [ユーザー定義変数](/user-defined-variables.md) @@ -478,14 +478,14 @@ - [生成された列](/generated-columns.md) - [SQLモード](/sql-mode.md) - [テーブル属性](/table-attributes.md) - - 取引 + - トランザクション - [概要](/transaction-overview.md) - [隔離レベル](/transaction-isolation-levels.md) - - [楽観的な取引](/optimistic-transaction.md) - - [悲観的な取引](/pessimistic-transaction.md) + - [楽観的なトランザクション](/optimistic-transaction.md) + - [悲観的なトランザクション](/pessimistic-transaction.md) - [非トランザクションDMLステートメント](/non-transactional-dml.md) - [パイプラインDML](/pipelined-dml.md) - - [閲覧数](/views.md) + - [ビュー](/views.md) - [パーティショニング](/partitioned-table.md) - [一時テーブル](/temporary-tables.md) - [キャッシュされたテーブル](/cached-tables.md) @@ -539,7 +539,7 @@ - [`STATISTICS`](/information-schema/information-schema-statistics.md) - [`TABLES`](/information-schema/information-schema-tables.md) - [`TABLE_CONSTRAINTS`](/information-schema/information-schema-table-constraints.md) - - [`TABLE_STORAGE_STATS`](/information-schema/information-schema-table-storage-stats.md) + - [`TABLE_STORAGE_STATS`](/information-schema/information-schema-table-ストレージ-stats.md) - [`TIDB_CHECK_CONSTRAINTS`](/information-schema/information-schema-tidb-check-constraints.md) - [`TIDB_HOT_REGIONS_HISTORY`](/information-schema/information-schema-tidb-hot-regions-history.md) - [`TIDB_INDEXES`](/information-schema/information-schema-tidb-indexes.md) @@ -569,15 +569,15 @@ - 一般参考資料 - TiDBクラシックアーキテクチャ - [概要](/tidb-architecture.md) - - [ストレージ](/tidb-storage.md) + - [ストレージ](/tidb-ストレージ.md) - [コンピューティング](/tidb-computing.md) - [スケジュール](/tidb-scheduling.md) - [TSO](/tso.md) - [TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md) - ストレージエンジン - - ティクヴ + - TiKV - [TiKVの概要](/tikv-overview.md) - - [RocksDBの概要](/storage-engine/rocksdb-overview.md) + - [RocksDBの概要](/ストレージ-engine/rocksdb-overview.md) - TiFlash - [TiFlashの概要](/tiflash/tiflash-overview.md) - [ディスクに書き出す](/tiflash/tiflash-spill-disk.md) @@ -611,7 +611,7 @@ - [システム変数](/system-variables.md) - [サーバー状態変数](/status-variables.md) - [テーブルフィルター](/table-filter.md) - - [外部ストレージサービスのURI形式](/external-storage-uri.md) + - [外部ストレージサービスのURI形式](/external-ストレージ-uri.md) - [DDLステートメントに埋め込まれた`ANALYZE`](/ddl_embedded_analyze.md) - [バッチ処理](/batch-processing.md) - [データとインデックス間の不整合のトラブルシューティング](/troubleshoot-data-inconsistency-errors.md) diff --git a/TOC.md b/TOC.md index 3e4a62aa7d3f8..beda7f3d6c67b 100644 --- a/TOC.md +++ b/TOC.md @@ -2,8 +2,8 @@ -- TiDBセルフマネージドについて - - [TiDBセルフマネージドとは何ですか？](/overview.md) +- TiDB Self-Managedについて + - [TiDB Self-Managedとは何ですか？](/overview.md) - [TiDB 8.5 リリースノート](/releases/release-8.5.0.md) - [特徴](/basic-features.md) - [MySQLとの互換性](/mysql-compatibility.md) @@ -12,13 +12,13 @@ - さあ始めましょう - [TiDB クイックスタート](/quick-start-with-tidb.md) - [HTAP クイックスタート](/quick-start-with-htap.md) - - [TiDBでSQLを探求しよう](/basic-sql-operations.md) - - [HTAPを探索する](/explore-htap.md) + - [TiDBでのSQL基本操作](/basic-sql-operations.md) + - [HTAP入門](/explore-htap.md) - [サンプルデータベースのインポート](/import-example-data.md) - デプロイ - [ソフトウェアおよびハードウェアの要件](/hardware-and-software-requirements.md) - - [環境コンフィグレーションチェックリスト](/check-before-deployment.md) - - プランクラスタトポロジ + - [環境設定チェックリスト](/check-before-deployment.md) + - プランクラスタートポロジ - [最小トポロジー](/minimal-deployment-topology.md) - [TiFlashトポロジー](/tiflash-deployment-topology.md) - [PDマイクロサービストポロジー](/pd-microservices-deployment-topology.md) @@ -28,8 +28,8 @@ - [ハイブリッドトポロジー](/hybrid-deployment-topology.md) - [TiUPを使用してデプロイ](/production-deployment-using-tiup.md) - [Kubernetesにデプロイ](/tidb-in-kubernetes.md) - - [クラスタの状態を確認する](/post-installation-check.md) - - テストクラスタのパフォーマンス + - [クラスターの状態を確認する](/post-installation-check.md) + - テストクラスターのパフォーマンス - [Sysbenchを使用してTiDBをテストする](/benchmark/benchmark-tidb-using-sysbench.md) - [TPC-Cを使用してTiDBをテストする](/benchmark/benchmark-tidb-using-tpcc.md) - [CH-benCHmarkを使用してTiDBをテストする](/benchmark/benchmark-tidb-using-ch.md) @@ -37,7 +37,7 @@ - [概要](/migration-overview.md) - [移行ツール](/migration-tools.md) - [ベストプラクティスの導入](/tidb-lightning/data-import-best-practices.md) - - 移住シナリオ + - 移行シナリオ - [Auroraから移行する](/migrate-aurora-to-tidb.md) - [MySQLから小規模データセットを移行する](/migrate-small-mysql-to-tidb.md) - [MySQLから大規模データセットを移行する](/migrate-large-mysql-to-tidb.md) @@ -48,7 +48,7 @@ - [CSVファイルからの移行](/migrate-from-csv-files-to-tidb.md) - [SQLファイルからの移行](/migrate-from-sql-files-to-tidb.md) - [Parquetファイルからの移行](/migrate-from-parquet-files-to-tidb.md) - - [ある TiDBクラスタから別の TiDBクラスタへ移行する](/migrate-from-tidb-to-tidb.md) + - [ある TiDBクラスターから別の TiDBクラスターへ移行する](/migrate-from-tidb-to-tidb.md) - [TiDBからMySQL互換データベースへの移行](/migrate-from-tidb-to-mysql.md) - 高度な移行 - [gh-ostまたはpt-oscを使用した継続的なレプリケーション](/migrate-with-pt-ghost.md) @@ -64,7 +64,7 @@ - [データをMySQL互換データベースに複製する](/ticdc/ticdc-sink-to-mysql.md) - [データをKafkaに複製する](/ticdc/ticdc-sink-to-kafka.md) - [データをPulsarに複製する](/ticdc/ticdc-sink-to-pulsar.md) - - [データをストレージサービスに複製する](/ticdc/ticdc-sink-to-cloud-storage.md) + - [データをストレージサービスに複製する](/ticdc/ticdc-sink-to-cloud-ストレージ.md) - [変更フィードを管理する](/ticdc/ticdc-manage-changefeed.md) - [ログフィルター](/ticdc/ticdc-filter.md) - [DDLレプリケーション](/ticdc/ticdc-ddl.md) @@ -86,7 +86,7 @@ - [TiCDC Changefeedフィード構成](/ticdc/ticdc-changefeed-config.md) - [TiCDCクライアント認証](/ticdc/ticdc-client-authentication.md) - [単一行データのデータ整合性検証](/ticdc/ticdc-integrity-check.md) - - [アップストリームおよびダウンストリームTiDBクラスタのデータ整合性検証](/ticdc/ticdc-upstream-downstream-check.md) + - [アップストリームおよびダウンストリームTiDBクラスターのデータ整合性検証](/ticdc/ticdc-upstream-downstream-check.md) - [TiCDCにおけるUPDATEイベント分割時の動作](/ticdc/ticdc-split-update-behavior.md) - 出力プロトコル - [TiCDC Avroプロトコル](/ticdc/ticdc-avro-protocol.md) @@ -99,14 +99,14 @@ - [TiCDCオープンAPI v1](/ticdc/ticdc-open-api.md) - TiCDCのデータ消費量 - [TiCDC行データチェックサム検証（Avroベース）](/ticdc/ticdc-avro-checksum-verification.md) - - [ストレージシンク消費者の開発ガイド](/ticdc/ticdc-storage-consumer-dev-guide.md) + - [ストレージシンク消費者の開発ガイド](/ticdc/ticdc-ストレージ-consumer-dev-guide.md) - [TiCDCとの互換性](/ticdc/ticdc-compatibility.md) - [トラブルシューティング](/ticdc/troubleshoot-ticdc.md) - [よくある質問](/ticdc/ticdc-faq.md) - [用語集](/ticdc/ticdc-glossary.md) - 管理 - - Security - - [TiDBSecurityコンフィグレーションのベストプラクティス](/best-practices-for-security-configuration.md) + - セキュリティ + - [TiDBセキュリティ設定のベストプラクティス](/best-practices-for-security-configuration.md) - [TiDBクライアントとサーバー間でTLSを有効にする](/enable-tls-between-clients-and-servers.md) - [TiDBコンポーネント間でTLSを有効にする](/enable-tls-between-components.md) - [自己署名証明書を生成する](/generate-self-signed-certificates.md) @@ -117,7 +117,7 @@ - [TiUPを使用する](/upgrade-tidb-using-tiup.md) - [TiDB Operatorを使用する](https://docs.pingcap.com/tidb-in-kubernetes/stable/upgrade-a-tidb-cluster) - [TiDB スムーズアップグレード](/smooth-upgrade-tidb.md) - - [TiDBクラスタの移行とアップグレード](/tidb-upgrade-migration-guide.md) + - [TiDBクラスターの移行とアップグレード](/tidb-upgrade-migration-guide.md) - [TiFlashアップグレードガイド](/tiflash-upgrade-guide.md) - 規模 - [TiUPを使用する（推奨）](/scale-tidb-using-tiup.md) @@ -134,7 +134,7 @@ - [ログバックアップとPITRガイド](/br/br-pitr-guide.md) - [コンパクトログバックアップ](/br/br-compact-log-backup.md) - [ユースケース](/br/backup-and-restore-use-cases.md) - - [バックアップストレージ](/br/backup-and-restore-storages.md) + - [バックアップストレージ](/br/backup-and-restore-ストレージs.md) - BR CLIマニュアル - [概要](/br/use-br-command-line-tool.md) - [スナップショットバックアップおよび復元コマンドマニュアル](/br/br-snapshot-manual.md) @@ -148,10 +148,10 @@ - [DumplingとTiDB Lightningを使用してデータをバックアップおよび復元する](/backup-and-restore-using-dumpling-lightning.md) - [RawKVのバックアップと復元](/br/rawkv-backup-and-restore.md) - [増分バックアップと復元](/br/br-incremental-guide.md) - - クラスタ災害復旧（DR） + - クラスター災害復旧（DR） - [DRソリューションの概要](/dr-solution-introduction.md) - [初等・中等教育DR](/dr-secondary-cluster.md) - - [マルチレプリカクラスタDR](/dr-multi-replica.md) + - [マルチレプリカクラスターDR](/dr-multi-replica.md) - [BRベースのDR](/dr-backup-restore.md) - リソースマネージャー - [リソース制御を使用して、リソースグループの制限とフロー制御を実現します。](/tidb-resource-control-ru-groups.md) @@ -161,9 +161,9 @@ - [毎日のチェックリスト](/daily-check.md) - [TiFlashの管理](/tiflash/maintain-tiflash.md) - [TiUPを使用してTiDBを管理](/maintain-tidb-using-tiup.md) - - [コンフィグレーションを動的に変更する](/dynamic-config.md) + - [設定を動的に変更する](/dynamic-config.md) - [オンラインの安全でない復旧](/online-unsafe-recovery.md) - - [プライマリクラスタとセカンダリクラスタ間でデータを複製する](/replicate-between-primary-and-secondary-clusters.md) + - [プライマリクラスターとセカンダリクラスター間でデータを複製する](/replicate-between-primary-and-secondary-clusters.md) - 監視と警告 - [モニタリングフレームワークの概要](/tidb-monitoring-framework.md) - [モニタリングAPI](/tidb-monitoring-api.md) @@ -178,7 +178,7 @@ - [セキュリティ](/dashboard/dashboard-ops-security.md) - [アクセス](/dashboard/dashboard-access.md) - [概要ページ](/dashboard/dashboard-overview.md) - - [クラスタ情報ページ](/dashboard/dashboard-cluster-info.md) + - [クラスター情報ページ](/dashboard/dashboard-cluster-info.md) - [Top SQLページ](/dashboard/top-sql.md) - [キービジュアライザーページ](/dashboard/dashboard-key-visualizer.md) - [指標関係グラフ](/dashboard/dashboard-metrics-relation.md) @@ -186,8 +186,8 @@ - [SQLステートメントページ](/dashboard/dashboard-statement-list.md) - [SQL詳細ページ](/dashboard/dashboard-statement-details.md) - [スロークエリページ](/dashboard/dashboard-slow-query.md) - - クラスタ診断 - - [クラスタ診断ページにアクセス](/dashboard/dashboard-diagnostics-access.md) + - クラスター診断 + - [クラスター診断ページにアクセス](/dashboard/dashboard-diagnostics-access.md) - [診断レポートをビュー](/dashboard/dashboard-diagnostics-report.md) - [診断機能を使用する](/dashboard/dashboard-diagnostics-usage.md) - [監視ページ](/dashboard/dashboard-monitoring.md) @@ -196,19 +196,19 @@ - インスタンスプロファイリング - [手動プロファイリング](/dashboard/dashboard-profiling.md) - [継続的なプロファイリング](/dashboard/continuous-profiling.md) - - セッション管理とコンフィグレーション + - セッション管理と設定 - [セッションを共有](/dashboard/dashboard-session-share.md) - [SSOの設定](/dashboard/dashboard-session-sso.md) - [FAQ](/dashboard/dashboard-faq.md) - [Grafanaスナップショットのエクスポート](/exporting-grafana-snapshots.md) - - [TiDBクラスタアラートルール](/alert-rules.md) + - [TiDBクラスターアラートルール](/alert-rules.md) - [TiFlashアラートルール](/tiflash/tiflash-alert-rules.md) - [監視サーバーの設定をカスタマイズする](/tiup/customized-montior-in-tiup-environment.md) - [BR監視およびアラート](/br/br-monitoring-and-alert.md) - トラブルシューティング - 問題の概要 - [TiDBトラブルシューティングマップ](/tidb-troubleshooting-map.md) - - [TiDBクラスタ設定のトラブルシューティング](/troubleshoot-tidb-cluster.md) + - [TiDBクラスター設定のトラブルシューティング](/troubleshoot-tidb-cluster.md) - [TiFlashのトラブルシューティング](/tiflash/troubleshoot-tiflash.md) - 問題シナリオ - 遅いクエリ @@ -226,7 +226,7 @@ - [明細書概要表](/statement-summary-tables.md) - [Top SQLを使用して高コストなクエリを特定する](/dashboard/top-sql.md) - [ログを使用して高負荷なクエリを特定する](/identify-expensive-queries.md) - - [クラスタのオンサイト情報を保存および復元する](/sql-plan-replayer.md) + - [クラスターのオンサイト情報を保存および復元する](/sql-plan-replayer.md) - [TiKVにおけるステイル読み取りとsafe-tsの理解](/troubleshoot-stale-read.md) - [サポートリソース](/support.md) - 性能チューニング @@ -240,7 +240,7 @@ - [TiFlashの性能分析方法](/tiflash-performance-tuning-methods.md) - [TiCDCの性能分析方法](/ticdc-performance-tuning-methods.md) - [レイテンシーの内訳](/latency-breakdown.md) - - コンフィグレーション調整 + - 設定調整 - [オペレーティングシステムのパフォーマンスを調整します](/tune-operating-system.md) - [TiDBメモリのチューニング](/configure-memory-usage.md) - [TiKVスレッドを調整](/tune-tikv-thread-performance.md) @@ -250,9 +250,9 @@ - [チューニングリージョンのパフォーマンス](/tune-region-performance.md) - [TiFlashのパフォーマンスをチューニング](/tiflash/tune-tiflash-performance.md) - [コプロセッサーキャッシュ](/coprocessor-cache.md) - - ごみ収集（GC） + - ガベージコレクション（GC） - [概要](/garbage-collection-overview.md) - - [コンフィグレーション](/garbage-collection-configuration.md) + - [設定](/garbage-collection-configuration.md) - SQLチューニング - [概要](/sql-tuning-overview.md) - クエリ実行プランの理解 @@ -263,7 +263,7 @@ - [MPPに関する質問](/explain-mpp.md) - [サブクエリ](/explain-subqueries.md) - [集計](/explain-aggregation.md) - - [閲覧数](/explain-views.md) + - [ビュー](/explain-views.md) - [パーティション](/explain-partitions.md) - [インデックスマージ](/explain-index-merge.md) - SQL最適化プロセス @@ -310,15 +310,15 @@ - [`tidb_snapshot`システム変数を使用する](/read-historical-data.md) - [配置ルールを使用する](/configure-placement-rules.md) - [ロードベース分割を使用する](/configure-load-base-split.md) - - [店舗利用制限](/configure-store-limit.md) + - [ストア制限](/configure-store-limit.md) - [バッチ処理](/batch-processing.md) - PDマイクロサービスを使用する - [PDマイクロサービスの概要](/pd-microservices.md) - [TiUPを使用してPDマイクロサービスノードをスケーリングする](/scale-microservices-using-tiup.md) - - [TSOコンフィグレーションファイル](/tso-configuration-file.md) - - [TSOコンフィグレーションフラグ](/command-line-flags-for-tso-configuration.md) - - [スケジュールコンフィグレーションファイル](/scheduling-configuration-file.md) - - [スケジューリングコンフィグレーションフラグ](/command-line-flags-for-scheduling-configuration.md) + - [TSO設定ファイル](/tso-configuration-file.md) + - [TSO設定フラグ](/command-line-flags-for-tso-configuration.md) + - [スケジュール設定ファイル](/scheduling-configuration-file.md) + - [スケジューリング設定フラグ](/command-line-flags-for-scheduling-configuration.md) - TiDBツール - [概要](/ecosystem-tool-user-guide.md) - [ユースケース](/ecosystem-tool-user-case.md) @@ -355,7 +355,7 @@ - [tiup telemetry](/tiup/tiup-command-telemetry.md) - [tiup uninstall](/tiup/tiup-command-uninstall.md) - [tiup update](/tiup/tiup-command-update.md) - - TiUPクラスタコマンド + - TiUPクラスターコマンド - [概要](/tiup/tiup-component-cluster.md) - [tiup cluster audit](/tiup/tiup-component-cluster-audit.md) - [tiup cluster auditクリーンアップ](/tiup/tiup-component-cluster-audit-cleanup.md) @@ -408,8 +408,8 @@ - [tiup dm 停止](/tiup/tiup-component-dm-stop.md) - [tiup dm template](/tiup/tiup-component-dm-template.md) - [tiup dm upgrade](/tiup/tiup-component-dm-upgrade.md) - - [TiDBクラスタトポロジーリファレンス](/tiup/tiup-cluster-topology-reference.md) - - [DMクラスタトポロジーリファレンス](/tiup/tiup-dm-topology-reference.md) + - [TiDBクラスタートポロジーリファレンス](/tiup/tiup-cluster-topology-reference.md) + - [DMクラスタートポロジーリファレンス](/tiup/tiup-dm-topology-reference.md) - [ミラーリファレンスガイド](/tiup/tiup-mirror-reference.md) - TiUPコンポーネント - [tiup-playground](/tiup/tiup-playground.md) @@ -457,8 +457,8 @@ - [より多くの列を持つ下流のTiDBテーブルにデータを移行する](/migrate-with-more-columns-downstream.md) - [継続的なデータ検証](/dm/dm-continuous-data-validation.md) - 管理 - - クラスタのアップグレード - - [TiUPを使用してDMクラスタを管理（推奨）](/dm/maintain-dm-using-tiup.md) + - クラスターのアップグレード + - [TiUPを使用してDMクラスターを管理（推奨）](/dm/maintain-dm-using-tiup.md) - [v1.0.xからv2.0+への手動アップグレード](/dm/manually-upgrade-dm-1.0-to-2.0.md) - ツール - [WebUIを使用して管理する](/dm/dm-webui-guide.md) @@ -486,12 +486,12 @@ - [DML複製メカニズム](/dm/dm-replication-logic.md) - コマンドライン - [DMマスター＆DMワーカー](/dm/dm-command-line-flags.md) - - コンフィグレーションファイル + - 設定ファイル - [概要](/dm/dm-config-overview.md) - [上流データベース構成](/dm/dm-source-configuration-file.md) - [タスク構成](/dm/task-configuration-file-full.md) - - [DMマスターコンフィグレーション](/dm/dm-master-configuration-file.md) - - [DMワーカーのコンフィグレーション](/dm/dm-worker-configuration-file.md) + - [DMマスター設定](/dm/dm-master-configuration-file.md) + - [DMワーカーの設定](/dm/dm-worker-configuration-file.md) - [テーブルセレクター](/dm/table-selector.md) - [OpenAPI](/dm/dm-open-api.md) - [互換性カタログ](/dm/dm-compatibility-catalog.md) @@ -540,7 +540,7 @@ - [エラー解決](/tidb-lightning/tidb-lightning-error-resolution.md) - [トラブルシューティング](/tidb-lightning/troubleshoot-tidb-lightning.md) - 参照 - - [コンフィグレーションファイル](/tidb-lightning/tidb-lightning-configuration.md) + - [設定ファイル](/tidb-lightning/tidb-lightning-configuration.md) - [コマンドラインフラグ](/tidb-lightning/tidb-lightning-command-line-full.md) - [監視](/tidb-lightning/monitor-tidb-lightning.md) - [ウェブインターフェース](/tidb-lightning/tidb-lightning-web-interface.md) @@ -560,26 +560,26 @@ - TiProxy - [概要](/tiproxy/tiproxy-overview.md) - [負荷分散ポリシー](/tiproxy/tiproxy-load-balance.md) - - [交通情報リプレイ](/tiproxy/tiproxy-traffic-replay.md) - - [コンフィグレーション](/tiproxy/tiproxy-configuration.md) + - [トラフィックリプレイ](/tiproxy/tiproxy-traffic-replay.md) + - [設定](/tiproxy/tiproxy-configuration.md) - [コマンドラインパラメータ](/tiproxy/tiproxy-command-line-flags.md) - [モニタリング指標](/tiproxy/tiproxy-grafana.md) - [API](/tiproxy/tiproxy-api.md) - [トラブルシューティング](/tiproxy/troubleshoot-tiproxy.md) - [性能テスト](/tiproxy/tiproxy-performance-test.md) - 参照 - - クラスタアーキテクチャ + - クラスターアーキテクチャ - [概要](/tidb-architecture.md) - - [ストレージ](/tidb-storage.md) + - [ストレージ](/tidb-ストレージ.md) - [コンピューティング](/tidb-computing.md) - [スケジュール](/tidb-scheduling.md) - [TSO](/tso.md) - ストレージエンジン - TiKV - [TiKVの概要](/tikv-overview.md) - - [RocksDBの概要](/storage-engine/rocksdb-overview.md) - - [タイタンの概要](/storage-engine/titan-overview.md) - - [タイタンコンフィグレーション](/storage-engine/titan-configuration.md) - - [分割されたRaftKV](/partitioned-raft-kv.md) + - [RocksDBの概要](/ストレージ-engine/rocksdb-overview.md) + - [Titanの概要](/ストレージ-engine/titan-overview.md) + - [Titan設定](/ストレージ-engine/titan-configuration.md) + - [パーティション化されたRaftKV](/partitioned-raft-kv.md) - ストレージエンジン - TiFlash - [概要](/tiflash/tiflash-overview.md) - [TiFlashレプリカを作成する](/tiflash/create-tiflash-replicas.md) @@ -601,7 +601,7 @@ - [システム変数](/system-variables.md) - [システム変数リファレンス](/system-variable-reference.md) - [サーバー状態変数](/status-variables.md) - - コンフィグレーションファイルパラメータ + - 設定ファイルパラメータ - [tidb-server](/tidb-configuration-file.md) - [tikvサーバー](/tikv-configuration-file.md) - [tiflash-server](/tiflash/tiflash-configuration.md) @@ -621,12 +621,12 @@ - [パフォーマンス概要](/grafana-performance-overview-dashboard.md) - [TiDB](/grafana-tidb-dashboard.md) - [PD](/grafana-pd-dashboard.md) - - [ティクヴ](/grafana-tikv-dashboard.md) + - [TiKV](/grafana-tikv-dashboard.md) - [TiFlash](/tiflash/monitor-tiflash.md) - [TiCDC](/ticdc/monitor-ticdc.md) - [リソース制御](/grafana-resource-control-dashboard.md) - 権限 - - [MySQLとのSecurity互換性](/security-compatibility-with-mysql.md) + - [MySQLとのセキュリティ互換性](/security-compatibility-with-mysql.md) - [権限管理](/privilege-management.md) - [列レベルの権限管理](/column-privilege-management.md) - [ユーザーアカウント管理](/user-account-management.md) @@ -637,10 +637,10 @@ - SQL言語の構造と構文 - 属性 - [自動インクリメント](/auto-increment.md) - - [自動乱数](/auto-random.md) + - [AUTO_RANDOM](/auto-random.md) - [_tidb_rowid](/tidb-rowid.md) - [SHARD_ROW_ID_BITS](/shard-row-id-bits.md) - - [文字通りの値](/literal-values.md) + - [リテラル値](/literal-values.md) - [スキーマオブジェクト名](/schema-object-names.md) - [キーワードと予約語](/keywords.md) - [ユーザー定義変数](/user-defined-variables.md) @@ -855,14 +855,14 @@ - [生成された列](/generated-columns.md) - [SQLモード](/sql-mode.md) - [テーブル属性](/table-attributes.md) - - 取引 + - トランザクション - [概要](/transaction-overview.md) - [隔離レベル](/transaction-isolation-levels.md) - - [楽観的な取引](/optimistic-transaction.md) - - [悲観的な取引](/pessimistic-transaction.md) + - [楽観的なトランザクション](/optimistic-transaction.md) + - [悲観的なトランザクション](/pessimistic-transaction.md) - [非トランザクションDMLステートメント](/non-transactional-dml.md) - [パイプラインDML](/pipelined-dml.md) - - [閲覧数](/views.md) + - [ビュー](/views.md) - [パーティショニング](/partitioned-table.md) - [一時テーブル](/temporary-tables.md) - [キャッシュされたテーブル](/cached-tables.md) @@ -921,7 +921,7 @@ - [`STATISTICS`](/information-schema/information-schema-statistics.md) - [`TABLES`](/information-schema/information-schema-tables.md) - [`TABLE_CONSTRAINTS`](/information-schema/information-schema-table-constraints.md) - - [`TABLE_STORAGE_STATS`](/information-schema/information-schema-table-storage-stats.md) + - [`TABLE_STORAGE_STATS`](/information-schema/information-schema-table-ストレージ-stats.md) - [`TIDB_CHECK_CONSTRAINTS`](/information-schema/information-schema-tidb-check-constraints.md) - [`TIDB_HOT_REGIONS`](/information-schema/information-schema-tidb-hot-regions.md) - [`TIDB_HOT_REGIONS_HISTORY`](/information-schema/information-schema-tidb-hot-regions-history.md) @@ -955,7 +955,7 @@ - [テーブルフィルター](/table-filter.md) - [TiDBインストールパッケージ](/binary-package.md) - [トポロジーラベルによるレプリカのスケジュール設定](/schedule-replicas-by-topology-labels.md) - - [外部ストレージサービスのURI形式](/external-storage-uri.md) + - [外部ストレージサービスのURI形式](/external-ストレージ-uri.md) - [オンラインワークロードと`ADD INDEX`操作に関する相互作用テスト](/benchmark/online-workloads-and-add-index-operations.md) - [DDLステートメントに埋め込まれた`ANALYZE`](/ddl_embedded_analyze.md) - よくある質問 @@ -966,7 +966,7 @@ - [移行に関するよくある質問](/faq/migration-tidb-faq.md) - [アップグレードに関するよくある質問](/faq/upgrade-faq.md) - [監視に関するよくある質問](/faq/monitor-faq.md) - - [クラスタ管理に関するよくある質問](/faq/manage-cluster-faq.md) + - [クラスター管理に関するよくある質問](/faq/manage-cluster-faq.md) - [高可用性に関するよくある質問](/faq/high-availability-faq.md) - [高信頼性に関するよくある質問](/faq/high-reliability-faq.md) - [バックアップと復元に関するよくある質問](/faq/backup-and-restore-faq.md) diff --git a/_docHome.md b/_docHome.md index c174676698ce8..3a8c26ccd7cc7 100644 --- a/_docHome.md +++ b/_docHome.md @@ -94,7 +94,7 @@ TiDB は、MySQL プロトコルおよびMySQL 5.7と MySQL 8.0 の共通機能 -オープンソースの TiDB プラットフォームは Apache 2.0 ライセンスの下でリリースされ、コミュニティによってサポートされています[GitHubでビュー](https://github.com/pingcap/tidb) +オープンソースの TiDB プラットフォームは Apache 2.0 ライセンスの下でリリースされ、コミュニティによってサポートされています[GitHubで確認](https://github.com/pingcap/tidb) diff --git a/_index.md b/_index.md index 31100cf94607f..ff4e6513b15b5 100644 --- a/_index.md +++ b/_index.md @@ -17,7 +17,7 @@ summary: TiDBは、ハイブリッドトランザクションおよび分析処 -[TiDBセルフマネージドとは](https://docs.pingcap.com/tidb/v8.5/overview) +[TiDB Self-Managedとは](https://docs.pingcap.com/tidb/v8.5/overview) [特徴](https://docs.pingcap.com/tidb/v8.5/basic-features) @@ -27,7 +27,7 @@ summary: TiDBは、ハイブリッドトランザクションおよび分析処 -[TiDBセルフマネージドを試してみる](https://docs.pingcap.com/tidb/v8.5/quick-start-with-tidb) +[TiDB Self-Managedを試してみる](https://docs.pingcap.com/tidb/v8.5/quick-start-with-tidb) [HTAPを試してみる](https://docs.pingcap.com/tidb/v8.5/quick-start-with-htap) @@ -49,9 +49,9 @@ summary: TiDBは、ハイブリッドトランザクションおよび分析処 [ソフトウェアおよびハードウェア要件](https://docs.pingcap.com/tidb/v8.5/hardware-and-software-requirements) -[TiUPを使用して TiDBクラスタをデプロイ](https://docs.pingcap.com/tidb/v8.5/production-deployment-using-tiup) +[TiUPを使用して TiDBクラスターをデプロイ](https://docs.pingcap.com/tidb/v8.5/production-deployment-using-tiup) -[Kubernetes に TiDBクラスタをデプロイ](https://docs.pingcap.com/tidb-in-kubernetes/stable) +[Kubernetes に TiDBクラスターをデプロイ](https://docs.pingcap.com/tidb-in-kubernetes/stable) @@ -67,11 +67,11 @@ summary: TiDBは、ハイブリッドトランザクションおよび分析処 -[クラスタのアップグレード](https://docs.pingcap.com/tidb/v8.5/upgrade-tidb-using-tiup) +[クラスターのアップグレード](https://docs.pingcap.com/tidb/v8.5/upgrade-tidb-using-tiup) -[クラスタのスケール](https://docs.pingcap.com/tidb/v8.5/scale-tidb-using-tiup) +[クラスターのスケール](https://docs.pingcap.com/tidb/v8.5/scale-tidb-using-tiup) -[クラスタデータのバックアップと復元](https://docs.pingcap.com/tidb/v8.5/backup-and-restore-overview) +[クラスターデータのバックアップと復元](https://docs.pingcap.com/tidb/v8.5/backup-and-restore-overview) [毎日のチェック](https://docs.pingcap.com/tidb/v8.5/daily-check) @@ -127,7 +127,7 @@ summary: TiDBは、ハイブリッドトランザクションおよび分析処 -[TiDBコンフィグレーションファイルのパラメータ](https://docs.pingcap.com/tidb/v8.5/tidb-configuration-file) +[TiDB設定ファイルのパラメータ](https://docs.pingcap.com/tidb/v8.5/tidb-configuration-file) [TiDB コマンドラインフラグ](https://docs.pingcap.com/tidb/v8.5/command-line-flags-for-tidb-configuration) diff --git a/accelerated-table-creation.md b/accelerated-table-creation.md index 89d6e8972f286..ec0001abe00f8 100644 --- a/accelerated-table-creation.md +++ b/accelerated-table-creation.md @@ -23,7 +23,7 @@ TiDB v7.6.0 では、テーブル作成の高速化をサポートするシス システム変数[`tidb_enable_fast_create_table`](/system-variables.md#tidb_enable_fast_create_table-new-in-v800)の値を指定することで、テーブル作成時のパフォーマンス最適化を有効または無効にすることができます。 -TiDB v8.5.0以降、新しく作成されたクラスタでは、高速テーブル作成機能がデフォルトで有効になり、 `tidb_enable_fast_create_table`が`ON`に設定されます。v8.4.0以前のバージョンからアップグレードされたクラスタの場合、 `tidb_enable_fast_create_table`のデフォルト値は変更されません。 +TiDB v8.5.0以降、新しく作成されたクラスターでは、高速テーブル作成機能がデフォルトで有効になり、 `tidb_enable_fast_create_table`が`ON`に設定されます。v8.4.0以前のバージョンからアップグレードされたクラスターの場合、 `tidb_enable_fast_create_table`のデフォルト値は変更されません。 テーブル作成時のパフォーマンス最適化を有効にするには、この変数の値を`ON`に設定してください。 diff --git a/ai/concepts/vector-search-overview.md b/ai/concepts/vector-search-overview.md index a63fea6016020..3044e0669dede 100644 --- a/ai/concepts/vector-search-overview.md +++ b/ai/concepts/vector-search-overview.md @@ -11,7 +11,7 @@ aliases: ['/ja/tidb/stable/vector-search-overview/','/ja/tidb/dev/vector-search- > **注記：** > > - ベクター検索機能はベータ版です。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - ベクトル検索機能は、 [TiDBセルフマネージド](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## 概念 {#concepts} @@ -29,7 +29,7 @@ aliases: ['/ja/tidb/stable/vector-search-overview/','/ja/tidb/dev/vector-search- ベクトル埋め込みは機械学習において不可欠であり、意味的類似性検索の基盤となる。 -TiDB は、ベクトル埋め込みのstorageと検索を最適化するように設計された、シームレス [ベクトルデータ型](/ai/reference/vector-search-data-types.md)と[ベクトル検索インデックス](/ai/reference/vector-search-index.md)を導入し、AI アプリケーションでの使用を強化します。ベクトル エンベディングを TiDB に保存し、ベクトル検索クエリを実行して、これらのデータ タイプを使用して最も関連性の高いデータを見つけることができます。 +TiDB は、ベクトル埋め込みのストレージと検索を最適化するように設計された、シームレス [ベクトルデータ型](/ai/reference/vector-search-data-types.md)と[ベクトル検索インデックス](/ai/reference/vector-search-index.md)を導入し、AI アプリケーションでの使用を強化します。ベクトル エンベディングを TiDB に保存し、ベクトル検索クエリを実行して、これらのデータ タイプを使用して最も関連性の高いデータを見つけることができます。 ### 埋め込みモデル {#embedding-model} @@ -47,7 +47,7 @@ TiDBベクトル検索は、 [距離関数](/ai/reference/vector-search-function ![The Schematic TiDB Vector Search](/media/vector-search/embedding-search.png) -TiDBは、ベクトル検索機能を統合したリレーショナルデータベースとして、データとその対応するベクトル表現（つまり、ベクトル埋め込み）を1つのデータベースにまとめて保存できます。storage方法は以下のいずれかを選択できます。 +TiDBは、ベクトル検索機能を統合したリレーショナルデータベースとして、データとその対応するベクトル表現（つまり、ベクトル埋め込み）を1つのデータベースにまとめて保存できます。ストレージ方法は以下のいずれかを選択できます。 - データとその対応するベクトル表現を、同じテーブルの異なる列に格納します。 - データとその対応するベクトル表現を別々のテーブルに格納します。このため、データを取得する際には`JOIN`クエリを使用してテーブルを結合する必要があります。 diff --git a/ai/examples/auto-embedding-with-pytidb.md b/ai/examples/auto-embedding-with-pytidb.md index 5076d884f1b7e..a279b4f0f791b 100644 --- a/ai/examples/auto-embedding-with-pytidb.md +++ b/ai/examples/auto-embedding-with-pytidb.md @@ -84,4 +84,4 @@ id: 3, text: LlamaIndex is a Python library for building AI-powered applications ## 関連リソース {#related-resources} -- **ソースコード**： [GitHubでビュー](https://github.com/pingcap/pytidb/tree/main/examples/auto_embedding) +- **ソースコード**： [GitHubで確認](https://github.com/pingcap/pytidb/tree/main/examples/auto_embedding) diff --git a/ai/examples/basic-with-pytidb.md b/ai/examples/basic-with-pytidb.md index cb6e96d84a567..75c40227f1015 100644 --- a/ai/examples/basic-with-pytidb.md +++ b/ai/examples/basic-with-pytidb.md @@ -96,4 +96,4 @@ Basic CRUD operations completed! ## 関連リソース {#related-resources} -- **ソースコード**： [GitHubでビュー](https://github.com/pingcap/pytidb/tree/main/examples/basic) +- **ソースコード**： [GitHubで確認](https://github.com/pingcap/pytidb/tree/main/examples/basic) diff --git a/ai/examples/fulltext-search-with-pytidb.md b/ai/examples/fulltext-search-with-pytidb.md index f82d3e0a156e9..bac9d361510de 100644 --- a/ai/examples/fulltext-search-with-pytidb.md +++ b/ai/examples/fulltext-search-with-pytidb.md @@ -61,4 +61,4 @@ streamlit run app.py ## 関連リソース {#related-resources} -- **ソースコード**： [GitHubでビュー](https://github.com/pingcap/pytidb/tree/main/examples/fulltext_search) +- **ソースコード**： [GitHubで確認](https://github.com/pingcap/pytidb/tree/main/examples/fulltext_search) diff --git a/ai/examples/hybrid-search-with-pytidb.md b/ai/examples/hybrid-search-with-pytidb.md index 8b6e603afac29..19b07ccfbb68d 100644 --- a/ai/examples/hybrid-search-with-pytidb.md +++ b/ai/examples/hybrid-search-with-pytidb.md @@ -118,4 +118,4 @@ python example.py ## 関連リソース {#related-resources} -- **ソースコード**： [GitHubでビュー](https://github.com/pingcap/pytidb/tree/main/examples/hybrid_search) +- **ソースコード**： [GitHubで確認](https://github.com/pingcap/pytidb/tree/main/examples/hybrid_search) diff --git a/ai/examples/image-search-with-pytidb.md b/ai/examples/image-search-with-pytidb.md index 30a3cb320cac1..a98291b6c75e9 100644 --- a/ai/examples/image-search-with-pytidb.md +++ b/ai/examples/image-search-with-pytidb.md @@ -96,4 +96,4 @@ streamlit run app.py ## 関連リソース {#related-resources} -- **ソースコード**： [GitHubでビュー](https://github.com/pingcap/pytidb/tree/main/examples/image_search) +- **ソースコード**： [GitHubで確認](https://github.com/pingcap/pytidb/tree/main/examples/image_search) diff --git a/ai/examples/memory-with-pytidb.md b/ai/examples/memory-with-pytidb.md index 577184c94b050..8e32e3daa69e8 100644 --- a/ai/examples/memory-with-pytidb.md +++ b/ai/examples/memory-with-pytidb.md @@ -132,4 +132,4 @@ Goodbye! ## 関連リソース {#related-resources} -- **ソースコード**： [GitHubでビュー](https://github.com/pingcap/pytidb/tree/main/examples/memory) +- **ソースコード**： [GitHubで確認](https://github.com/pingcap/pytidb/tree/main/examples/memory) diff --git a/ai/examples/rag-with-pytidb.md b/ai/examples/rag-with-pytidb.md index 9c02efe53b87d..b4ec94f5fc5cf 100644 --- a/ai/examples/rag-with-pytidb.md +++ b/ai/examples/rag-with-pytidb.md @@ -94,4 +94,4 @@ streamlit run main.py ## 関連リソース {#related-resources} -- **ソースコード**： [GitHubでビュー](https://github.com/pingcap/pytidb/tree/main/examples/rag) +- **ソースコード**： [GitHubで確認](https://github.com/pingcap/pytidb/tree/main/examples/rag) diff --git a/ai/examples/text2sql-with-pytidb.md b/ai/examples/text2sql-with-pytidb.md index b4d6ba5411cad..b7b8c4fe40a84 100644 --- a/ai/examples/text2sql-with-pytidb.md +++ b/ai/examples/text2sql-with-pytidb.md @@ -47,4 +47,4 @@ streamlit run app.py ## 関連リソース {#related-resources} -- **ソースコード**： [GitHubでビュー](https://github.com/pingcap/pytidb/tree/main/examples/text2sql) +- **ソースコード**： [GitHubで確認](https://github.com/pingcap/pytidb/tree/main/examples/text2sql) diff --git a/ai/examples/vector-search-with-pytidb.md b/ai/examples/vector-search-with-pytidb.md index 483abda0f9d70..ed70a1c5fa9fe 100644 --- a/ai/examples/vector-search-with-pytidb.md +++ b/ai/examples/vector-search-with-pytidb.md @@ -79,4 +79,4 @@ streamlit run app.py ## 関連リソース {#related-resources} -- **ソースコード**： [GitHubでビュー](https://github.com/pingcap/pytidb/tree/main/examples/vector_search) +- **ソースコード**： [GitHubで確認](https://github.com/pingcap/pytidb/tree/main/examples/vector_search) diff --git a/ai/guides/connect.md b/ai/guides/connect.md index b86c0bcecce72..fdf6f7d8b7049 100644 --- a/ai/guides/connect.md +++ b/ai/guides/connect.md @@ -51,7 +51,7 @@ db = TiDBClient.connect(
-[TiDBセルフマネージドのクイックスタート](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb/#deploy-a-local-test-cluster)スタートに従って、テスト用にTiDBクラスターをデプロイします。 +[TiDB Self-Managedのクイックスタート](https://docs.pingcap.com/tidb/stable/quick-start-with-tidb/#deploy-a-local-test-cluster)スタートに従って、テスト用にTiDBクラスターをデプロイします。 サンプルコード： @@ -69,7 +69,7 @@ db = TiDBClient.connect( > **注記：** > -> テスト用にTiDBクラスタをデプロイするために`tiup playground`を使用する場合、デフォルトのホストは`127.0.0.1`で、デフォルトのパスワードは空です。 +> テスト用にTiDBクラスターをデプロイするために`tiup playground`を使用する場合、デフォルトのホストは`127.0.0.1`で、デフォルトのパスワードは空です。
@@ -116,7 +116,7 @@ db = TiDBClient.connect( > **注記：** > -> `tiup playground`を使用してテスト用のTiDBクラスタをデプロイする場合、接続文字列は次のとおりです。 +> `tiup playground`を使用してテスト用のTiDBクラスターをデプロイする場合、接続文字列は次のとおりです。 > > mysql+pymysql://root:@127.0.0.1:4000/test diff --git a/ai/guides/transactions.md b/ai/guides/transactions.md index 0b88c90cd7c96..b1a6b52a52b34 100644 --- a/ai/guides/transactions.md +++ b/ai/guides/transactions.md @@ -3,7 +3,7 @@ title: Transactions summary: アプリケーションでトランザクションを使用する方法を学びます。 --- -# 取引 {#transactions} +# トランザクション {#transactions} TiDB は、データの一貫性と信頼性を確保するためにACIDトランザクションをサポートします。 diff --git a/ai/integrations/tidb-mcp-claude-code.md b/ai/integrations/tidb-mcp-claude-code.md index d4e6df92b05e1..0adcbfd41853e 100644 --- a/ai/integrations/tidb-mcp-claude-code.md +++ b/ai/integrations/tidb-mcp-claude-code.md @@ -33,7 +33,7 @@ TiDB Cloudコンソールを使用して、すぐに実行できるClaude Code 5. **「Claude Code」**タブを選択し、セットアップコマンドをコピーして、ターミナルで実行してください。 -## 手動設定（任意のTiDBクラスタ） {#manual-configuration-any-tidb-cluster} +## 手動設定（任意のTiDBクラスター） {#manual-configuration-any-tidb-cluster} 手動で設定する場合は、以下のいずれかの方法を使用し、プレースホルダーを接続パラメータに置き換えてください。 diff --git a/ai/integrations/tidb-mcp-cursor.md b/ai/integrations/tidb-mcp-cursor.md index 48f1a29d57c28..cdee311f63dd0 100644 --- a/ai/integrations/tidb-mcp-cursor.md +++ b/ai/integrations/tidb-mcp-cursor.md @@ -37,7 +37,7 @@ TiDB Cloudコンソールを使用して、 TiDB Cloud Starterインスタンス 5. **「カーソル」**タブを選択し、 **「カーソルに追加」**をクリックしてから、「カーソルに**インストール」を**クリックします。 -## 手動設定（任意のTiDBクラスタ） {#manual-configuration-any-tidb-cluster} +## 手動設定（任意のTiDBクラスター） {#manual-configuration-any-tidb-cluster} 手動で設定する場合は、 `.cursor/mcp.json`ファイルに次の設定を追加し、プレースホルダーを接続パラメータに置き換えてください。 diff --git a/ai/integrations/tidb-mcp-vscode.md b/ai/integrations/tidb-mcp-vscode.md index 8a04a0c2aac3b..e9f35114aca4c 100644 --- a/ai/integrations/tidb-mcp-vscode.md +++ b/ai/integrations/tidb-mcp-vscode.md @@ -33,7 +33,7 @@ TiDB Cloudコンソールを使用して、VS Code構成を生成します。 5. **VS Code**タブを選択し、 **「VS Codeに追加」**をクリックしてから、「VS Codeに**インストール」**をクリックします。 -## 手動設定（任意のTiDBクラスタ） {#manual-configuration-any-tidb-cluster} +## 手動設定（任意のTiDBクラスター） {#manual-configuration-any-tidb-cluster} 手動で設定する場合は、 `.vscode/mcp.json`ファイルに次の設定を追加し、プレースホルダーを接続パラメータに置き換えてください。 diff --git a/ai/integrations/tidb-mcp-windsurf.md b/ai/integrations/tidb-mcp-windsurf.md index 9332381650ef7..9e8e4346e8d73 100644 --- a/ai/integrations/tidb-mcp-windsurf.md +++ b/ai/integrations/tidb-mcp-windsurf.md @@ -35,7 +35,7 @@ TiDB Cloudコンソールを使用して接続の詳細を取得し、Windsurf 6. コピーした値を使用して`mcp_config.json`ファイルを更新します。詳細については、 [Windsurf MCP ドキュメント](https://docs.windsurf.com/windsurf/cascade/mcp#adding-a-new-mcp-plugin)を参照してください。 -## 手動設定（任意のTiDBクラスタ） {#manual-configuration-any-tidb-cluster} +## 手動設定（任意のTiDBクラスター） {#manual-configuration-any-tidb-cluster} 手動で設定する場合は、 `mcp_config.json`ファイルを次のように更新し、プレースホルダーを接続パラメータに置き換えてください。 diff --git a/ai/integrations/vector-search-auto-embedding-cohere.md b/ai/integrations/vector-search-auto-embedding-cohere.md index 5b97e4579ce23..b4a74f5cb50a5 100644 --- a/ai/integrations/vector-search-auto-embedding-cohere.md +++ b/ai/integrations/vector-search-auto-embedding-cohere.md @@ -14,7 +14,7 @@ aliases: ['/ja/tidbcloud/vector-search-auto-embedding-cohere/'] ## 利用可能なモデル {#available-models} -TiDB Cloud は、次の[調和する](https://cohere.com/)埋め込みモデルをネイティブに提供します。 API キーは必要ありません。 +TiDB Cloud は、次の[Cohere](https://cohere.com/)埋め込みモデルをネイティブに提供します。 API キーは必要ありません。 **Cohere Embed v3 モデル** @@ -115,7 +115,7 @@ LIMIT 2; - `search_document` : ドキュメントから埋め込みを生成し、ベクトルデータベースに保存します。 - `search_query` : クエリから埋め込みを生成し、ベクトルデータベースに保存されている埋め込みに対して検索を行います。 - `classification` : テキスト分類器への入力として使用される埋め込みを生成します。 - - `clustering` : クラスタリングタスク用の埋め込みを生成します。 + - `clustering` : クラスターリングタスク用の埋め込みを生成します。 - `truncate` （オプション）：APIが最大トークン長を超える入力をどのように処理するかを制御します。以下のいずれかの値を指定できます。 diff --git a/ai/integrations/vector-search-auto-embedding-gemini.md b/ai/integrations/vector-search-auto-embedding-gemini.md index 96d9c86f28359..fdf93b93d9546 100644 --- a/ai/integrations/vector-search-auto-embedding-gemini.md +++ b/ai/integrations/vector-search-auto-embedding-gemini.md @@ -243,7 +243,7 @@ embedding: list[float] = EmbeddingFunction( -パフォーマンス要件とstorageの制約に基づいて、次元を選択してください。次元数を増やすと精度は向上しますが、より多くのstorageと計算リソースが必要になります。 +パフォーマンス要件とストレージの制約に基づいて、次元を選択してください。次元数を増やすと精度は向上しますが、より多くのストレージと計算リソースが必要になります。 ## オプション {#options} diff --git a/ai/integrations/vector-search-auto-embedding-overview.md b/ai/integrations/vector-search-auto-embedding-overview.md index 96d2f9a129ff3..7fb68ed346130 100644 --- a/ai/integrations/vector-search-auto-embedding-overview.md +++ b/ai/integrations/vector-search-auto-embedding-overview.md @@ -110,9 +110,9 @@ TiDB Cloudは様々な埋め込みモデルをサポートしています。ニ | 埋め込みモデル | 文書 | TiDB Cloud 1がホストしています | BYOK 2 | | -------- | ---------------------------------------------------------------------------------- | -------------------------------- | ----------------- | -| アマゾンタイタン | [Amazon Titan 埋め込み](/ai/integrations/vector-search-auto-embedding-amazon-titan.md) | ✅ | | -| 調和する | [Cohere埋め込み](/ai/integrations/vector-search-auto-embedding-cohere.md) | ✅ | ✅ | -| ジナAI | [Jina AI埋め込み](/ai/integrations/vector-search-auto-embedding-jina-ai.md) | | ✅ | +| Amazon Titan | [Amazon Titan 埋め込み](/ai/integrations/vector-search-auto-embedding-amazon-titan.md) | ✅ | | +| Cohere | [Cohere埋め込み](/ai/integrations/vector-search-auto-embedding-cohere.md) | ✅ | ✅ | +| Jina AI | [Jina AI埋め込み](/ai/integrations/vector-search-auto-embedding-jina-ai.md) | | ✅ | | OpenAI | [OpenAI埋め込み](/ai/integrations/vector-search-auto-embedding-openai.md) | | ✅ | | 双子座 | [ジェミニ埋め込み](/ai/integrations/vector-search-auto-embedding-gemini.md) | | ✅ | diff --git a/ai/integrations/vector-search-integrate-with-amazon-bedrock.md b/ai/integrations/vector-search-integrate-with-amazon-bedrock.md index d2160ea8a627c..46bc0d37f3475 100644 --- a/ai/integrations/vector-search-integrate-with-amazon-bedrock.md +++ b/ai/integrations/vector-search-integrate-with-amazon-bedrock.md @@ -15,7 +15,7 @@ aliases: ['/ja/tidbcloud/vector-search-integrate-with-amazon-bedrock/'] > **注記：** > > - ベクター検索機能はベータ版です。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - ベクトル検索機能は、 [TiDBセルフマネージド](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 > **ヒント** > diff --git a/ai/integrations/vector-search-integrate-with-django-orm.md b/ai/integrations/vector-search-integrate-with-django-orm.md index 2f4ff3448f1a5..ea920446cc859 100644 --- a/ai/integrations/vector-search-integrate-with-django-orm.md +++ b/ai/integrations/vector-search-integrate-with-django-orm.md @@ -11,7 +11,7 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-django-orm/','/ja/tidb/d > **注記：** > > - ベクター検索機能はベータ版です。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - ベクトル検索機能は、 [TiDBセルフマネージド](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## 前提条件 {#prerequisites} @@ -19,12 +19,12 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-django-orm/','/ja/tidb/d - [Python 3.8以降](https://www.python.org/downloads/)インストールされています。 - [Git](https://git-scm.com/downloads)がインストールされました。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## サンプルアプリを実行します {#run-the-sample-app} @@ -107,8 +107,8 @@ TiDB Cloud StarterまたはEssentialインスタンスの場合、接続文字 5. Python プロジェクトのルートディレクトリに`.env`ファイルを作成し、接続パラメータを対応する環境変数に貼り付けます。 - - `TIDB_HOST` : TiDBクラスタのホスト。 - - `TIDB_PORT` : TiDB クラスタのポート。 + - `TIDB_HOST` : TiDBクラスターのホスト。 + - `TIDB_PORT` : TiDB クラスターのポート。 - `TIDB_USERNAME` : TiDBに接続するためのユーザー名。 - `TIDB_PASSWORD` : TiDBに接続するためのパスワード。 - `TIDB_DATABASE` : 接続するデータベース名。 @@ -128,7 +128,7 @@ TiDB Cloud StarterまたはEssentialインスタンスの場合、接続文字
-TiDBセルフマネージドクラスタの場合、Pythonプロジェクトのルートディレクトリに`.env`ファイルを作成します。次の内容を`.env`ファイルにコピーし、TiDBクラスタの接続パラメータに応じて環境変数の値を変更します。 +TiDB Self-Managedクラスターの場合、Pythonプロジェクトのルートディレクトリに`.env`ファイルを作成します。次の内容を`.env`ファイルにコピーし、TiDBクラスターの接続パラメータに応じて環境変数の値を変更します。 ```dotenv TIDB_HOST=127.0.0.1 @@ -142,10 +142,10 @@ TiDBをローカルマシンで実行している場合、 `TIDB_HOST`はデフ 各パラメータの説明は以下のとおりです。 -- `TIDB_HOST` : TiDB セルフマネージド クラスタのホスト。 -- `TIDB_PORT` : TiDB セルフマネージド クラスタのポート。 -- `TIDB_USERNAME` : TiDB セルフマネージド クラスタに接続するためのユーザー名。 -- `TIDB_PASSWORD` : TiDB セルフマネージド クラスタに接続するためのパスワード。 +- `TIDB_HOST` : TiDB Self-Managed クラスターのホスト。 +- `TIDB_PORT` : TiDB Self-Managed クラスターのポート。 +- `TIDB_USERNAME` : TiDB Self-Managed クラスターに接続するためのユーザー名。 +- `TIDB_PASSWORD` : TiDB Self-Managed クラスターに接続するためのパスワード。 - `TIDB_DATABASE` : 接続するデータベースの名前。
diff --git a/ai/integrations/vector-search-integrate-with-jinaai-embedding.md b/ai/integrations/vector-search-integrate-with-jinaai-embedding.md index 182b3e88984cd..d25751b33595f 100644 --- a/ai/integrations/vector-search-integrate-with-jinaai-embedding.md +++ b/ai/integrations/vector-search-integrate-with-jinaai-embedding.md @@ -6,12 +6,12 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-jinaai-embedding/','/ja/ # TiDBベクトル検索をJina AI埋め込みAPIと統合する {#integrate-tidb-vector-search-with-jina-ai-embeddings-api} -このチュートリアルでは[ジナAI](https://jina.ai/)を使用してテキスト埋め込みを生成し、TiDBに保存し、埋め込みに基づいて類似のテキストを検索する方法を順を追って説明します。 +このチュートリアルでは[Jina AI](https://jina.ai/)を使用してテキスト埋め込みを生成し、TiDBに保存し、埋め込みに基づいて類似のテキストを検索する方法を順を追って説明します。 > **注記：** > > - ベクター検索機能はベータ版です。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - ベクトル検索機能は、 [TiDBセルフマネージド](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## 前提条件 {#prerequisites} @@ -19,12 +19,12 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-jinaai-embedding/','/ja/ - [Python 3.8以降](https://www.python.org/downloads/)インストールされています。 - [Git](https://git-scm.com/downloads)がインストールされました。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## サンプルアプリを実行します {#run-the-sample-app} @@ -105,7 +105,7 @@ TiDB Cloud StarterまたはEssentialインスタンスの場合、接続文字
-TiDBセルフマネージドクラスタの場合、ターミナルで次のように環境変数を設定してTiDBクラスタに接続します。 +TiDB Self-Managedクラスターの場合、ターミナルで次のように環境変数を設定してTiDBクラスターに接続します。 ```shell export JINA_API_KEY="****" @@ -113,14 +113,14 @@ export TIDB_DATABASE_URL="mysql+pymysql://:@:/`はデフォルトで`127.0.0.1`になります。初期値の``は空なので、クラスタを初めて起動する場合はこのフィールドを省略できます。 +ご使用の TiDB クラスターに合わせて、上記のコマンドのパラメータを置き換える必要があります。ローカル マシンで TiDB を実行している場合、 ``はデフォルトで`127.0.0.1`になります。初期値の``は空なので、クラスターを初めて起動する場合はこのフィールドを省略できます。 各パラメータの説明は以下のとおりです。 - `` : TiDBに接続するためのユーザー名。 - `` : TiDBに接続するためのパスワード。 -- `` : TiDBクラスタのホスト。 -- `` : TiDB クラスタのポート。 +- `` : TiDBクラスターのホスト。 +- `` : TiDB クラスターのポート。 - `` : 接続するデータベースの名前。
diff --git a/ai/integrations/vector-search-integrate-with-langchain.md b/ai/integrations/vector-search-integrate-with-langchain.md index 817f6e5f9d8bb..96b9b82b98668 100644 --- a/ai/integrations/vector-search-integrate-with-langchain.md +++ b/ai/integrations/vector-search-integrate-with-langchain.md @@ -11,7 +11,7 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-langchain/','/ja/tidb/de > **注記：** > > - ベクター検索機能はベータ版です。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - ベクトル検索機能は、 [TiDBセルフマネージド](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 > **ヒント** > @@ -24,12 +24,12 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-langchain/','/ja/tidb/de - [Python 3.8以降](https://www.python.org/downloads/)インストールされています。 - [ジュピターノートブック](https://jupyter.org/install)がインストールされました。 - [Git](https://git-scm.com/downloads)がインストールされました。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## さあ始めましょう {#get-started} @@ -123,21 +123,21 @@ tidb_connection_string = getpass.getpass("TiDB Connection String:") os.environ["OPENAI_API_KEY"] = getpass.getpass("OpenAI API Key:") ``` -macOSを例にとると、クラスタ接続文字列は次のようになります。 +macOSを例にとると、クラスター接続文字列は次のようになります。 ```dotenv TIDB_DATABASE_URL="mysql+pymysql://:@:/" # For example: TIDB_DATABASE_URL="mysql+pymysql://root@127.0.0.1:4000/test" ``` -TiDBクラスタに合わせて接続パラメータの値を変更する必要があります。ローカルマシンでTiDBを実行している場合、 ``はデフォルトで`127.0.0.1`になります。初期値の``は空なので、クラスタを初めて起動する場合はこのフィールドを省略できます。 +TiDBクラスターに合わせて接続パラメータの値を変更する必要があります。ローカルマシンでTiDBを実行している場合、 ``はデフォルトで`127.0.0.1`になります。初期値の``は空なので、クラスターを初めて起動する場合はこのフィールドを省略できます。 各パラメータの説明は以下のとおりです。 - `` : TiDBに接続するためのユーザー名。 - `` : TiDBに接続するためのパスワード。 -- `` : TiDBクラスタのホスト。 -- `` : TiDB クラスタのポート。 +- `` : TiDBクラスターのホスト。 +- `` : TiDB クラスターのポート。 - `` : 接続するデータベースの名前。 diff --git a/ai/integrations/vector-search-integrate-with-llamaindex.md b/ai/integrations/vector-search-integrate-with-llamaindex.md index f67a0aea94090..4194069673023 100644 --- a/ai/integrations/vector-search-integrate-with-llamaindex.md +++ b/ai/integrations/vector-search-integrate-with-llamaindex.md @@ -11,7 +11,7 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-llamaindex/','/ja/tidb/d > **注記：** > > - ベクター検索機能はベータ版です。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - ベクトル検索機能は、 [TiDBセルフマネージド](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 > **ヒント** > @@ -24,12 +24,12 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-llamaindex/','/ja/tidb/d - [Python 3.8以降](https://www.python.org/downloads/)インストールされています。 - [ジュピターノートブック](https://jupyter.org/install)がインストールされました。 - [Git](https://git-scm.com/downloads)がインストールされました。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## さあ始めましょう {#get-started} @@ -122,21 +122,21 @@ tidb_connection_string = getpass.getpass("TiDB Connection String:") os.environ["OPENAI_API_KEY"] = getpass.getpass("OpenAI API Key:") ``` -macOSを例にとると、クラスタ接続文字列は次のようになります。 +macOSを例にとると、クラスター接続文字列は次のようになります。 ```dotenv TIDB_DATABASE_URL="mysql+pymysql://:@:/" # For example: TIDB_DATABASE_URL="mysql+pymysql://root@127.0.0.1:4000/test" ``` -TiDBクラスタに合わせて、接続文字列のパラメータを変更する必要があります。ローカルマシンでTiDBを実行している場合、 ``はデフォルトで`127.0.0.1`になります。初期値の``は空なので、クラスタを初めて起動する場合は、このフィールドを省略できます。 +TiDBクラスターに合わせて、接続文字列のパラメータを変更する必要があります。ローカルマシンでTiDBを実行している場合、 ``はデフォルトで`127.0.0.1`になります。初期値の``は空なので、クラスターを初めて起動する場合は、このフィールドを省略できます。 各パラメータの説明は以下のとおりです。 - `` : TiDBに接続するためのユーザー名。 - `` : TiDBに接続するためのパスワード。 -- `` : TiDBクラスタのホスト。 -- `` : TiDB クラスタのポート。 +- `` : TiDBクラスターのホスト。 +- `` : TiDB クラスターのポート。 - `` : 接続するデータベースの名前。 @@ -189,9 +189,9 @@ tidbvec = TiDBVectorStore( 以下のコードは、ドキュメントを解析し、埋め込みを生成し、それらをTiDBベクトルストアに保存します。 ```python -storage_context = StorageContext.from_defaults(vector_store=tidbvec) +ストレージ_context = StorageContext.from_defaults(vector_store=tidbvec) index = VectorStoreIndex.from_documents( - documents, storage_context=storage_context, show_progress=True + documents, ストレージ_context=ストレージ_context, show_progress=True ) ``` @@ -214,7 +214,7 @@ print(textwrap.fill(str(response), 100)) > **注記** > -> `TiDBVectorStore` [`default`](https://docs.llamaindex.ai/en/stable/api_reference/storage/vector_store/?h=vectorstorequerymode#llama_index.core.vector_stores.types.VectorStoreQueryMode)クエリ モードのみをサポートしています。 +> `TiDBVectorStore` [`default`](https://docs.llamaindex.ai/en/stable/api_reference/ストレージ/vector_store/?h=vectorstorequerymode#llama_index.core.vector_stores.types.VectorStoreQueryMode)クエリ モードのみをサポートしています。 期待される出力は以下のとおりです。 diff --git a/ai/integrations/vector-search-integrate-with-peewee.md b/ai/integrations/vector-search-integrate-with-peewee.md index 36579535ccac6..000ef152f1049 100644 --- a/ai/integrations/vector-search-integrate-with-peewee.md +++ b/ai/integrations/vector-search-integrate-with-peewee.md @@ -11,7 +11,7 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-peewee/','/ja/tidb/dev/v > **注記：** > > - ベクター検索機能はベータ版です。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - ベクトル検索機能は、 [TiDBセルフマネージド](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## 前提条件 {#prerequisites} @@ -19,12 +19,12 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-peewee/','/ja/tidb/dev/v - [Python 3.8以降](https://www.python.org/downloads/)インストールされています。 - [Git](https://git-scm.com/downloads)がインストールされました。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## サンプルアプリを実行します {#run-the-sample-app} @@ -118,7 +118,7 @@ TiDB Cloud StarterまたはEssentialインスタンスの場合、接続文字
-TiDBセルフマネージドクラスタの場合、Pythonプロジェクトのルートディレクトリに`.env`ファイルを作成します。次の内容を`.env`ファイルにコピーし、TiDBクラスタの接続パラメータに応じて環境変数の値を変更します。 +TiDB Self-Managedクラスターの場合、Pythonプロジェクトのルートディレクトリに`.env`ファイルを作成します。次の内容を`.env`ファイルにコピーし、TiDBクラスターの接続パラメータに応じて環境変数の値を変更します。 ```dotenv TIDB_HOST=127.0.0.1 @@ -132,10 +132,10 @@ TiDBをローカルマシンで実行している場合、 `TIDB_HOST`はデフ 各パラメータの説明は以下のとおりです。 -- `TIDB_HOST` : TiDB セルフマネージド クラスタのホスト。 -- `TIDB_PORT` : TiDB セルフマネージド クラスタのポート。 -- `TIDB_USERNAME` : TiDB セルフマネージド クラスタに接続するためのユーザー名。 -- `TIDB_PASSWORD` : TiDB セルフマネージド クラスタに接続するためのパスワード。 +- `TIDB_HOST` : TiDB Self-Managed クラスターのホスト。 +- `TIDB_PORT` : TiDB Self-Managed クラスターのポート。 +- `TIDB_USERNAME` : TiDB Self-Managed クラスターに接続するためのユーザー名。 +- `TIDB_PASSWORD` : TiDB Self-Managed クラスターに接続するためのパスワード。 - `TIDB_DATABASE` : 接続するデータベースの名前。
diff --git a/ai/integrations/vector-search-integrate-with-sqlalchemy.md b/ai/integrations/vector-search-integrate-with-sqlalchemy.md index ae75cafd43ed1..ad6297a528854 100644 --- a/ai/integrations/vector-search-integrate-with-sqlalchemy.md +++ b/ai/integrations/vector-search-integrate-with-sqlalchemy.md @@ -11,7 +11,7 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-sqlalchemy/','/ja/tidb/d > **注記：** > > - ベクター検索機能はベータ版です。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - ベクトル検索機能は、 [TiDBセルフマネージド](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## 前提条件 {#prerequisites} @@ -19,12 +19,12 @@ aliases: ['/ja/tidb/stable/vector-search-integrate-with-sqlalchemy/','/ja/tidb/d - [Python 3.8以降](https://www.python.org/downloads/)インストールされています。 - [Git](https://git-scm.com/downloads)がインストールされました。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## サンプルアプリを実行します {#run-the-sample-app} @@ -106,7 +106,7 @@ TiDB Cloud StarterまたはEssentialインスタンスの場合、接続文字
-TiDBセルフマネージドクラスタの場合、Pythonプロジェクトのルートディレクトリに`.env`ファイルを作成します。次の内容を`.env`ファイルにコピーし、TiDBクラスタの接続パラメータに応じて環境変数の値を変更します。 +TiDB Self-Managedクラスターの場合、Pythonプロジェクトのルートディレクトリに`.env`ファイルを作成します。次の内容を`.env`ファイルにコピーし、TiDBクラスターの接続パラメータに応じて環境変数の値を変更します。 ```dotenv TIDB_DATABASE_URL="mysql+pymysql://:@:/" @@ -119,8 +119,8 @@ TiDBをローカルマシンで実行している場合、 ``はデフォ - `` : TiDBに接続するためのユーザー名。 - `` : TiDBに接続するためのパスワード。 -- `` : TiDBクラスタのホスト。 -- `` : TiDB クラスタのポート。 +- `` : TiDBクラスターのホスト。 +- `` : TiDB クラスターのポート。 - `` : 接続するデータベースの名前。
diff --git a/ai/integrations/vector-search-integration-overview.md b/ai/integrations/vector-search-integration-overview.md index 7adf89de3c634..7906c16706590 100644 --- a/ai/integrations/vector-search-integration-overview.md +++ b/ai/integrations/vector-search-integration-overview.md @@ -11,7 +11,7 @@ aliases: ['/ja/tidb/stable/vector-search-integration-overview/','/ja/tidb/dev/ve > **注記：** > > - ベクター検索機能はベータ版です。予告なく変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告を行ってください。 -> - ベクトル検索機能は[TiDBセルフマネージド](/overview.md) 、 [TiDB Cloudスターター](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloudエッセンシャル](/tidb-cloud/select-cluster-tier.md#essential) 、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用可能です。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は[TiDB Self-Managed](/overview.md) 、 [TiDB Cloudスターター](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloudエッセンシャル](/tidb-cloud/select-cluster-tier.md#essential) 、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用可能です。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## AIフレームワーク {#ai-frameworks} @@ -22,7 +22,7 @@ TiDB は以下の AI フレームワークを公式にサポートしており | ランチェーン | [LangChainとベクトル検索を統合する](/ai/integrations/vector-search-integrate-with-langchain.md) | | ラマインデックス | [LlamaIndexとベクター検索を統合する](/ai/integrations/vector-search-integrate-with-llamaindex.md) | -また、TiDB は、ドキュメントのstorageや AI アプリケーションのナレッジ グラフのstorageなど、さまざまなタスクにも使用できます。 +また、TiDB は、ドキュメントのストレージや AI アプリケーションのナレッジ グラフのストレージなど、さまざまなタスクにも使用できます。 ## モデルとサービスの埋め込み {#embedding-models-and-services} diff --git a/ai/quickstart-via-python.md b/ai/quickstart-via-python.md index ea98a171ab824..8efe336fedb8d 100644 --- a/ai/quickstart-via-python.md +++ b/ai/quickstart-via-python.md @@ -18,7 +18,7 @@ aliases: ['/ja/tidb/stable/vector-search-get-started-using-python/','/ja/tidb/de > **注記：** > > - ベクトル検索機能はベータ版であり、予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告してください。 -> - ベクトル検索機能は、 [TiDBセルフマネージド](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## 前提条件 {#prerequisites} @@ -82,7 +82,7 @@ client = TiDBClient.connect(
-TiDBセルフマネージドクラスタに接続するための基本的な例を以下に示します。 +TiDB Self-Managedクラスターに接続するための基本的な例を以下に示します。 ```python from pytidb import TiDBClient @@ -127,7 +127,7 @@ text_embed = EmbeddingFunction(
-埋め込み用のAPIキーを作成するには、[ジナAI](https://jina.ai/embeddings/)にアクセスしてください。 +埋め込み用のAPIキーを作成するには、[Jina AI](https://jina.ai/embeddings/)にアクセスしてください。 ```python from pytidb.embeddings import EmbeddingFunction diff --git a/ai/quickstart-via-sql.md b/ai/quickstart-via-sql.md index 1d89af19df580..be5aa97d8cbb0 100644 --- a/ai/quickstart-via-sql.md +++ b/ai/quickstart-via-sql.md @@ -18,19 +18,19 @@ TiDB は、MySQL 構文を拡張して[ベクトル検索](/ai/concepts/vector-s > **注記：** > > - ベクトル検索機能はベータ版であり、予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告してください。 -> - ベクトル検索機能は、 [TiDBセルフマネージド](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## 前提条件 {#prerequisites} この文書の手順を完了するには、以下が必要です。 - [MySQLコマンドラインクライアント](https://dev.mysql.com/doc/refman/8.4/en/mysql.html)(MySQL CLI)がマシンにインストールされています。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## さあ始めましょう {#get-started} @@ -58,7 +58,7 @@ TiDB は、MySQL 構文を拡張して[ベクトル検索](/ai/concepts/vector-s
-TiDBセルフマネージドクラスタが起動したら、ターミナルでクラスタ接続コマンドを実行してください。 +TiDB Self-Managedクラスターが起動したら、ターミナルでクラスター接続コマンドを実行してください。 以下はmacOSにおける接続コマンドの例です。 diff --git a/ai/reference/vector-search-data-types.md b/ai/reference/vector-search-data-types.md index b5c0140b68715..7447546cac4ff 100644 --- a/ai/reference/vector-search-data-types.md +++ b/ai/reference/vector-search-data-types.md @@ -11,7 +11,7 @@ aliases: ['/ja/tidb/stable/vector-search-data-types/','/ja/tidbcloud/vector-sear > **注記：** > > - ベクターデータ型はベータ版であり、予告なく変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告を行ってください。 -> - ベクトルデータ型は[TiDBセルフマネージド](/overview.md) 、 [TiDB Cloudスターター](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloudエッセンシャル](/tidb-cloud/select-cluster-tier.md#essential) 、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で使用できます。TiDB Self-Managed およびTiDB Cloud Dedicated の場合、TiDB バージョンは v8.4.0 以降である必要があります（v8.5.0 以降を推奨）。 +> - ベクトルデータ型は[TiDB Self-Managed](/overview.md) 、 [TiDB Cloudスターター](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloudエッセンシャル](/tidb-cloud/select-cluster-tier.md#essential) 、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で使用できます。TiDB Self-Managed およびTiDB Cloud Dedicated の場合、TiDB バージョンは v8.4.0 以降である必要があります（v8.5.0 以降を推奨）。 現在、次のベクター データ型が利用可能です。 @@ -22,7 +22,7 @@ aliases: ['/ja/tidb/stable/vector-search-data-types/','/ja/tidbcloud/vector-sear - ベクトル インデックスのサポート: ベクトルの検索を高速化するために[ベクター検索インデックス](/ai/reference/vector-search-index.md)を構築できます。 - 次元の強制: 異なる次元のベクトルの挿入を禁止する次元を指定できます。 -- 最適化されたstorage形式: ベクター データ型はベクター データの処理に最適化されており、 `JSON`型と比較して優れたスペース効率とパフォーマンスを実現します。 +- 最適化されたストレージ形式: ベクター データ型はベクター データの処理に最適化されており、 `JSON`型と比較して優れたスペース効率とパフォーマンスを実現します。 ## 構文 {#syntax} diff --git a/ai/reference/vector-search-functions-and-operators.md b/ai/reference/vector-search-functions-and-operators.md index e82e7c70b7b75..0c51fec853a35 100644 --- a/ai/reference/vector-search-functions-and-operators.md +++ b/ai/reference/vector-search-functions-and-operators.md @@ -11,7 +11,7 @@ aliases: ['/ja/tidb/stable/vector-search-functions-and-operators/','/ja/tidbclou > **注記：** > > - ベクトル関数と演算子はベータ版であり、予告なく変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告を行ってください。 -> - ベクトルデータ型とこれらのベクトル関数は、 [TiDBセルフマネージド](/overview.md) 、 [TiDB Cloudスターター](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloudエッセンシャル](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で使用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトルデータ型とこれらのベクトル関数は、 [TiDB Self-Managed](/overview.md) 、 [TiDB Cloudスターター](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloudエッセンシャル](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で使用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## ベクトル関数 {#vector-functions} diff --git a/ai/reference/vector-search-improve-performance.md b/ai/reference/vector-search-improve-performance.md index 9f09604feafa1..f418e9d61adff 100644 --- a/ai/reference/vector-search-improve-performance.md +++ b/ai/reference/vector-search-improve-performance.md @@ -11,7 +11,7 @@ TiDB Vector Searchを使用すると、画像、ドキュメント、その他 > **注記：** > > - ベクター検索機能はベータ版です。予告なく変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告を行ってください。 -> - ベクトル検索機能は[TiDBセルフマネージド](/overview.md) 、 [TiDB Cloudスターター](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloudエッセンシャル](/tidb-cloud/select-cluster-tier.md#essential) 、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用可能です。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は[TiDB Self-Managed](/overview.md) 、 [TiDB Cloudスターター](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloudエッセンシャル](/tidb-cloud/select-cluster-tier.md#essential) 、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用可能です。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## ベクトル列にベクトル検索インデックスを追加する {#add-vector-search-index-for-vector-columns} @@ -37,6 +37,6 @@ OpenAI `text-embedding-3-large`などの特定の埋め込みモデルは[埋め ## インデックスをウォームアップする {#warm-up-the-index} -一度も使用されていない、または長期間アクセスされていないインデックス（コールドアクセス）にアクセスする場合、TiDBはインデックス全体をメモリではなくクラウドstorageまたはディスクから読み込む必要があります。このプロセスには時間がかかり、多くの場合、クエリのレイテンシーが長くなります。さらに、長期間（例えば数時間）SQLクエリが実行されない場合、コンピューティングリソースが再利用されるため、以降のアクセスはコールドアクセスになります。 +一度も使用されていない、または長期間アクセスされていないインデックス（コールドアクセス）にアクセスする場合、TiDBはインデックス全体をメモリではなくクラウドストレージまたはディスクから読み込む必要があります。このプロセスには時間がかかり、多くの場合、クエリのレイテンシーが長くなります。さらに、長期間（例えば数時間）SQLクエリが実行されない場合、コンピューティングリソースが再利用されるため、以降のアクセスはコールドアクセスになります。 このようなクエリのレイテンシーを回避するには、実際のワークロードの前に、ベクトル インデックスにヒットする同様のベクトル検索クエリを実行して、インデックスをウォームアップします。 diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md index 41dad3014d978..3fc4a4a126bf9 100644 --- a/ai/reference/vector-search-index.md +++ b/ai/reference/vector-search-index.md @@ -13,7 +13,7 @@ aliases: ['/ja/tidb/stable/vector-search-index/','/ja/tidbcloud/vector-search-in > **注記：** > > - ベクター検索機能はベータ版です。予告なく変更される可能性があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)報告を行ってください。 -> - ベクトル検索機能は[TiDBセルフマネージド](/overview.md) 、 [TiDB Cloudスターター](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloudエッセンシャル](/tidb-cloud/select-cluster-tier.md#essential) 、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用可能です。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は[TiDB Self-Managed](/overview.md) 、 [TiDB Cloudスターター](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloudエッセンシャル](/tidb-cloud/select-cluster-tier.md#essential) 、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用可能です。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 現在、TiDB は[HNSW（階層的ナビゲート可能なスモールワールド）](https://en.wikipedia.org/wiki/Hierarchical_navigable_small_world)ベクトル検索インデックス アルゴリズムをサポートしています。 @@ -134,7 +134,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES; 参考までに、768次元の500MiBベクターデータセットのインデックス作成には最大20分かかる場合があります。インデクサーは複数のテーブルに対して並列実行できます。現在、インデクサーの優先度や速度の調整はサポートされていません。 -- デルタレイヤーの行数は`ROWS_DELTA_NOT_INDEXED`列目で確認できます。TiFlashのstorageレイヤーのデータは、デルタレイヤーとステーブルレイヤーの2つのレイヤーに保存されます。デルタレイヤーには最近挿入または更新された行が保存され、書き込みワークロードに応じて定期的にステーブルレイヤーにマージされます。このマージプロセスはコンパクションと呼ばれます。 +- デルタレイヤーの行数は`ROWS_DELTA_NOT_INDEXED`列目で確認できます。TiFlashのストレージレイヤーのデータは、デルタレイヤーとステーブルレイヤーの2つのレイヤーに保存されます。デルタレイヤーには最近挿入または更新された行が保存され、書き込みワークロードに応じて定期的にステーブルレイヤーにマージされます。このマージプロセスはコンパクションと呼ばれます。 Deltaレイヤーは常にインデックス化されません。最適なパフォーマンスを実現するには、DeltaレイヤーをStableレイヤーに強制的にマージし、すべてのデータがインデックス化されるようにすることができます。 diff --git a/ai/reference/vector-search-limitations.md b/ai/reference/vector-search-limitations.md index dfa15e52685a9..0fd4a7c0e9c5f 100644 --- a/ai/reference/vector-search-limitations.md +++ b/ai/reference/vector-search-limitations.md @@ -11,7 +11,7 @@ aliases: ['/ja/tidb/stable/vector-search-limitations/','/ja/tidb/dev/vector-sear > **注記：** > > - ベクトル検索機能はベータ版です。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - ベクトル検索機能は、 [TiDBセルフマネージド](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## ベクトルデータ型の制限 {#vector-data-type-limitations} @@ -35,7 +35,7 @@ aliases: ['/ja/tidb/stable/vector-search-limitations/','/ja/tidb/dev/vector-sear - [TiDB Cloudコンソールのデータ移行機能](/tidb-cloud/migrate-from-mysql-using-data-migration.md)MySQL ベクター データ型のTiDB Cloudへの移行または複製をサポートしていません。 -- TiDBセルフマネージドツール： +- TiDB Self-Managedツール： - データのバックアップと復元には、 [BR](/br/backup-and-restore-overview.md)のバージョン8.4.0以降を使用していることを確認してください。ベクトルデータ型のテーブルをTiDBバージョン8.4.0より前のバージョンに復元することはサポートされていません。 - [TiDBデータ移行（DM）](/dm/dm-overview.md) MySQLベクトルデータ型をTiDBに移行または複製することをサポートしていません。 diff --git a/ai/vector-search-get-started-using-python.md b/ai/vector-search-get-started-using-python.md index 5b7c8f7e697be..2a26458cd99ed 100644 --- a/ai/vector-search-get-started-using-python.md +++ b/ai/vector-search-get-started-using-python.md @@ -13,7 +13,7 @@ aliases: ['/ja/tidb/stable/vector-search-get-started-using-python/','/ja/tidb/de > **注記：** > > - ベクター検索機能はベータ版です。予告なく変更される場合があります。バグを発見した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - ベクトル検索機能は、 [TiDBセルフマネージド](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 +> - ベクトル検索機能は、 [TiDB Self-Managed](/overview.md)[TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential) 、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)で利用できます。TiDB Self-ManagedおよびTiDB Cloud Dedicatedの場合、TiDBのバージョンはv8.4.0以降である必要があります（v8.5.0以降を推奨）。 ## 前提条件 {#prerequisites} @@ -21,12 +21,12 @@ aliases: ['/ja/tidb/stable/vector-search-get-started-using-python/','/ja/tidb/de - [Python 3.8以降](https://www.python.org/downloads/)インストールされています。 - [Git](https://git-scm.com/downloads)がインストールされました。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## さあ始めましょう {#get-started} @@ -97,7 +97,7 @@ TiDB Cloud Starterインスタンスの場合、接続文字列を取得し、
-TiDBセルフマネージドクラスタの場合、Pythonプロジェクトのルートディレクトリに`.env`ファイルを作成します。次の内容を`.env`ファイルにコピーし、TiDBクラスタの接続パラメータに応じて環境変数の値を変更します。 +TiDB Self-Managedクラスターの場合、Pythonプロジェクトのルートディレクトリに`.env`ファイルを作成します。次の内容を`.env`ファイルにコピーし、TiDBクラスターの接続パラメータに応じて環境変数の値を変更します。 ```dotenv TIDB_DATABASE_URL="mysql+pymysql://:@:/" @@ -110,8 +110,8 @@ TiDBをローカルマシンで実行している場合、 ``はデフォ - `` : TiDBに接続するためのユーザー名。 - `` : TiDBに接続するためのパスワード。 -- `` : TiDBクラスタのホスト。 -- `` : TiDB クラスタのポート。 +- `` : TiDBクラスターのホスト。 +- `` : TiDB クラスターのポート。 - `` : 接続するデータベースの名前。
diff --git a/alert-rules.md b/alert-rules.md index 82a1aa934a6fe..169520d61d363 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -5,7 +5,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま -# TiDBクラスタアラートルール {#tidb-cluster-alert-rules} +# TiDBクラスターアラートルール {#tidb-cluster-alert-rules} このドキュメントでは、TiDB、TiKV、PD、 TiFlash、TiCDC、Node_exporter、Blackbox_exporter のアラート項目のルールの説明と解決策を含む、TiDB クラスター内のさまざまなコンポーネントのアラート ルールについて説明します。 @@ -49,7 +49,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 解決： - リーダーのバランスが取れているかどうかを確認するには、ビュー[**TiKV詳細**>**クラスタ**ダッシュボード](/grafana-tikv-dashboard.md#cluster)ビュー。 + リーダーのバランスが取れているかどうかを確認するには、ビュー[**TiKV詳細**>**クラスター**ダッシュボード](/grafana-tikv-dashboard.md#cluster)ビュー。 #### TiDB_domain_load_schema_total {#code-tidb-domain-load-schema-total-code} @@ -283,7 +283,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - 説明： - PDノード間のネットワークレイテンシーが高くなっています。リーダータイムアウトやTSOディスクstorageタイムアウトが発生し、クラスターのサービスに影響を与える可能性があります。 + PDノード間のネットワークレイテンシーが高くなっています。リーダータイムアウトやTSOディスクストレージタイムアウトが発生し、クラスターのサービスに影響を与える可能性があります。 - 解決： @@ -358,7 +358,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - アラートルール: - `sum(pd_cluster_status{type="storage_size"}) / sum(pd_cluster_status{type="storage_capacity"}) * 100 > 80` + `sum(pd_cluster_status{type="ストレージ_size"}) / sum(pd_cluster_status{type="ストレージ_capacity"}) * 100 > 80` - 説明： @@ -413,7 +413,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - [**TiKV詳細**> **PD**ダッシュボード](/grafana-tikv-dashboard.md#pd)監視し、ストア低速スコアのメトリックを確認します。メトリック値が80を超えるノードを特定し、低速ノードとして検出します。 - [**TiKV-詳細**> **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。 - レイテンシーのタイムアウト制限を増やすには、 [`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval)構成項目を大きな値に設定します。 - - アラート対象の TiKV ノードのパフォーマンスの問題とチューニング方法の詳細な分析については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md#storage-async-write-duration-store-duration-and-apply-duration)参照してください。 + - アラート対象の TiKV ノードのパフォーマンスの問題とチューニング方法の詳細な分析については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md#ストレージ-async-write-duration-store-duration-and-apply-duration)参照してください。 ## TiKVアラートルール {#tikv-alert-rules} @@ -515,7 +515,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - アラートルール: - `histogram_quantile(0.99, sum(rate(tikv_storage_engine_async_request_duration_seconds_bucket{type="snapshot"}[1m])) by (le, instance, type)) > 1` + `histogram_quantile(0.99, sum(rate(tikv_ストレージ_engine_async_request_duration_seconds_bucket{type="snapshot"}[1m])) by (le, instance, type)) > 1` - 説明： @@ -529,7 +529,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま - アラートルール: - `histogram_quantile(0.99, sum(rate(tikv_storage_engine_async_request_duration_seconds_bucket{type="write"}[1m])) by (le, instance, type)) > 1` + `histogram_quantile(0.99, sum(rate(tikv_ストレージ_engine_async_request_duration_seconds_bucket{type="write"}[1m])) by (le, instance, type)) > 1` - 説明： @@ -539,7 +539,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 1. [**TiKV詳細**> **Raft提案**ダッシュボード](/grafana-tikv-dashboard.md#raft-propose)監視し、アラート対象の TiKV ノードの**サーバーあたりの 99% Propose 待機期間**メトリックが他の TiKV ノードと比べて大幅に高いかどうかを確認します。高い場合、この TiKV ノードにホットスポットが存在することを示し、ホットスポットのスケジューリングが適切に機能しているかどうかを確認する必要があります。 2. [**TiKV詳細**> **Raft IO**ダッシュボード](/grafana-tikv-dashboard.md#raft-io)監視し、レイテンシーが増加していないか確認してください。レイテンシーが高い場合は、ディスクにボトルネックが発生している可能性があります。 - 3. アラート対象の TiKV ノードのパフォーマンスの問題とチューニング方法の詳細な分析については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md#storage-async-write-duration-store-duration-and-apply-duration)参照してください。 + 3. アラート対象の TiKV ノードのパフォーマンスの問題とチューニング方法の詳細な分析については、 [パフォーマンス分析とチューニング](/performance-tuning-methods.md#ストレージ-async-write-duration-store-duration-and-apply-duration)参照してください。 #### TiKV_coprocessor_request_wait_seconds {#code-tikv-coprocessor-request-wait-seconds-code} @@ -607,7 +607,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 1. `Scheduler`および`Scheduler-${cmd}` ( `${cmd}`はクエリへの書き込みコマンド) のモニターでスケジューラ コマンドの実行時間を表示して、最も時間のかかるコマンドを特定します。 2. `Scheduler`と`Scheduler-${cmd}`モニターのスケジューラ スキャンの詳細で`total`と`process`値を確認し、 `total`と`process`一致するかどうかを確認します。 - 3. ストレージ モニターでstorageの非同期スナップショット/書き込み期間をビュー、 Raft操作が時間どおりに実行されているかどうかを確認します。 + 3. ストレージ モニターでストレージの非同期スナップショット/書き込み期間をビュー、 Raft操作が時間どおりに実行されているかどうかを確認します。 #### TiKV_thread_apply_worker_cpu_seconds {#code-tikv-thread-apply-worker-cpu-seconds-code} diff --git a/api/_index.md b/api/_index.md index 39303cd308377..d7d8b73cf012c 100644 --- a/api/_index.md +++ b/api/_index.md @@ -5,26 +5,26 @@ summary: TiDB CloudおよびTiDB Self-Managedで利用可能なAPIについて # TiDB APIの概要 {#tidb-api-overview} -TiDBは、クラスタのクエリと操作、データレプリケーションの管理、システムステータスの監視などを行うためのさまざまなAPIを提供します。このドキュメントでは[TiDB Cloud](https://docs.pingcap.com/tidbcloud/)と[TiDBセルフマネージド](https://docs.pingcap.com/tidb/stable/)両方で利用可能なAPIの概要を説明します。 . +TiDBは、クラスターのクエリと操作、データレプリケーションの管理、システムステータスの監視などを行うためのさまざまなAPIを提供します。このドキュメントでは[TiDB Cloud](https://docs.pingcap.com/tidbcloud/)と[TiDB Self-Managed](https://docs.pingcap.com/tidb/stable/)両方で利用可能なAPIの概要を説明します。 . ## TiDB CloudAPI（ベータ版） {#tidb-cloud-api-beta} -[TiDB CloudAPI](/api/tidb-cloud-api-overview.md)は[RESTインターフェース](https://en.wikipedia.org/wiki/Representational_state_transfer)APIであり、プロジェクト、クラスタ、バックアップ、リストア、インポート、請求、データサービスリソースなど、 TiDB Cloud内の管理オブジェクトをプログラムで管理するためのアクセスを提供します。 +[TiDB CloudAPI](/api/tidb-cloud-api-overview.md)は[RESTインターフェース](https://en.wikipedia.org/wiki/Representational_state_transfer)APIであり、プロジェクト、クラスター、バックアップ、リストア、インポート、請求、データサービスリソースなど、 TiDB Cloud内の管理オブジェクトをプログラムで管理するためのアクセスを提供します。 | API | 説明 | | ----------------------------------------- | ---------------------------------------------------------------------------- | | [v1beta2](/api/tidb-cloud-api-v1beta2.md) | TiDB Cloud Premiumインスタンスを管理します。 | -| [v1beta1](/api/tidb-cloud-api-v1beta1.md) | TiDB Cloud Starter、 Essential、およびDedicatedクラスタに加え、課金、データサービス、 IAMリソースを管理します。 | +| [v1beta1](/api/tidb-cloud-api-v1beta1.md) | TiDB Cloud Starter、 Essential、およびDedicatedクラスターに加え、課金、データサービス、 IAMリソースを管理します。 | | [v1beta](/api/tidb-cloud-api-v1beta.md) | TiDB Cloudのプロジェクト、クラスター、バックアップ、インポート、およびリストアを管理します。 | -## TiDBセルフマネージドAPI {#tidb-self-managed-api} +## TiDB Self-ManagedAPI {#tidb-self-managed-api} -TiDB Self-Managedは、TiDBツール用のさまざまなAPIを提供し、クラスタコンポーネントの管理、システムステータスの監視、データレプリケーションワークフローの制御を支援します。 +TiDB Self-Managedは、TiDBツール用のさまざまなAPIを提供し、クラスターコンポーネントの管理、システムステータスの監視、データレプリケーションワークフローの制御を支援します。 | API | 説明 | | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | [TiProxy API](/tiproxy/tiproxy-api.md) | TiProxyの設定、稼働状況、および監視データにアクセスできます。 | | [データ移行API](/dm/dm-open-api.md) | DMマスターノードとDMワーカーノード、データソース、およびデータレプリケーションタスクを管理します。 | -| [モニタリングAPI](/tidb-monitoring-api.md) | TiDBサーバーの実行状況、テーブルstorage情報、およびTiKVクラスタの詳細を取得します。 | +| [モニタリングAPI](/tidb-monitoring-api.md) | TiDBサーバーの実行状況、テーブルストレージ情報、およびTiKVクラスターの詳細を取得します。 | | [TiCDC API](/ticdc/ticdc-open-api-v2.md) | TiCDCノードの状態を照会し、レプリケーションタスク（作成、一時停止、再開、更新操作など）を管理します。 | -| [TiDB OperatorAPI](https://github.com/pingcap/tidb-operator/blob/%7B%7B%7B.tidb-operator-version%7D%7D%7D/docs/api-references/docs.md) | Kubernetes 上で TiDB クラスタを管理します。これには、デプロイ、アップグレード、スケーリング、バックアップ、フェイルオーバーなどが含まれます。 | +| [TiDB OperatorAPI](https://github.com/pingcap/tidb-operator/blob/%7B%7B%7B.tidb-operator-version%7D%7D%7D/docs/api-references/docs.md) | Kubernetes 上で TiDB クラスターを管理します。これには、デプロイ、アップグレード、スケーリング、バックアップ、フェイルオーバーなどが含まれます。 | diff --git a/api/dm-api-overview.md b/api/dm-api-overview.md index 269f3c72be9ec..a8b2b2c24a428 100644 --- a/api/dm-api-overview.md +++ b/api/dm-api-overview.md @@ -11,7 +11,7 @@ DM は、 [dmctlツール](/dm/dmctl-introduction.md)と同様に、DM クラス DM API を使用して、DM クラスターで次のメンテナンス操作を実行できます。 -- [クラスタ管理](/dm/dm-open-api.md#apis-for-managing-clusters) : DM マスター ノードと DM ワーカー ノードに関する情報を取得したり、停止したりします。 +- [クラスター管理](/dm/dm-open-api.md#apis-for-managing-clusters) : DM マスター ノードと DM ワーカー ノードに関する情報を取得したり、停止したりします。 - [データソース管理](/dm/dm-open-api.md#apis-for-managing-data-sources) : データ ソースを作成、更新、削除、有効化、無効化し、リレー ログ機能を管理し、データ ソースと DM ワーカー間のバインディングを変更します。 - [レプリケーションタスク管理](/dm/dm-open-api.md#apis-for-managing-replication-tasks) : レプリケーション タスクを作成、更新、削除、開始、または停止し、スキーマと移行ルールを管理します。 diff --git a/api/monitoring-api-overview.md b/api/monitoring-api-overview.md index b5ad18d5d873a..4e8a328655290 100644 --- a/api/monitoring-api-overview.md +++ b/api/monitoring-api-overview.md @@ -9,7 +9,7 @@ TiDB モニタリングフレームワークは、 [プロメテウス](https:// 次のインターフェースを使用して、TiDB クラスターのステータスを監視できます。 -- [ステータスインターフェース](/tidb-monitoring-api.md#use-the-status-interface) : 現在の TiDBサーバーの[実行ステータス](/tidb-monitoring-api.md#running-status)とテーブルの[storage情報](/tidb-monitoring-api.md#storage-information)を監視します。 +- [ステータスインターフェース](/tidb-monitoring-api.md#use-the-status-interface) : 現在の TiDBサーバーの[実行ステータス](/tidb-monitoring-api.md#running-status)とテーブルの[ストレージ情報](/tidb-monitoring-api.md#ストレージ-information)を監視します。 - [メトリクスインターフェース](/tidb-monitoring-api.md#use-the-metrics-interface) : コンポーネント内のさまざまな操作に関する詳細情報を取得し、Grafana を使用してこれらのメトリックを表示します。 リクエストパラメータ、レスポンス例、使用方法など、各 API の詳細については、 [TiDB モニタリング API](/tidb-monitoring-api.md)参照してください。 diff --git a/api/tidb-cloud-api-overview.md b/api/tidb-cloud-api-overview.md index bc5adfc4bee55..71064674495ab 100644 --- a/api/tidb-cloud-api-overview.md +++ b/api/tidb-cloud-api-overview.md @@ -1,6 +1,6 @@ --- title: TiDB Cloud API Overview -summary: TiDB Cloud APIとは何か、その機能、そしてAPIを使用してTiDB Cloudクラスタを管理する方法について学びましょう。 +summary: TiDB Cloud APIとは何か、その機能、そしてAPIを使用してTiDB Cloudクラスターを管理する方法について学びましょう。 aliases: ['/ja/tidbcloud/api-overview/'] --- @@ -10,7 +10,7 @@ aliases: ['/ja/tidbcloud/api-overview/'] > > TiDB Cloud APIはベータ版です。 -TiDB Cloud APIは[RESTインターフェース](https://en.wikipedia.org/wiki/Representational_state_transfer)APIであり、 TiDB Cloud内の管理オブジェクトをプログラムで管理するためのアクセスを提供します。このAPIを使用すると、プロジェクト、クラスタ、バックアップ、リストア、インポート、請求、データ[データサービス](https://docs.pingcap.com/tidbcloud/data-service-overview)内のリソースなどのリソースを自動的かつ効率的に管理できます。 +TiDB Cloud APIは[RESTインターフェース](https://en.wikipedia.org/wiki/Representational_state_transfer)APIであり、 TiDB Cloud内の管理オブジェクトをプログラムで管理するためのアクセスを提供します。このAPIを使用すると、プロジェクト、クラスター、バックアップ、リストア、インポート、請求、データ[データサービス](https://docs.pingcap.com/tidbcloud/data-service-overview)内のリソースなどのリソースを自動的かつ効率的に管理できます。 このAPIには以下の機能があります。 @@ -21,5 +21,5 @@ TiDB Cloud APIは[RESTインターフェース](https://en.wikipedia.org/wiki/Re TiDB Cloud APIは、以下のバージョンで利用可能です。 - [v1beta2](/api/tidb-cloud-api-v1beta2.md) ： TiDB Cloud Premiumインスタンスを管理します。 -- [v1beta1](/api/tidb-cloud-api-v1beta1.md) ： TiDB Cloud Starter、 Essential、およびDedicatedクラスタ、ならびに課金、データサービス、およびIAMリソースを管理します。 +- [v1beta1](/api/tidb-cloud-api-v1beta1.md) ： TiDB Cloud Starter、 Essential、およびDedicatedクラスター、ならびに課金、データサービス、およびIAMリソースを管理します。 - [v1beta](/api/tidb-cloud-api-v1beta.md) : TiDB Cloudのプロジェクト、クラスター、バックアップ、インポート、リストアを管理します。 diff --git a/api/tidb-cloud-api-v1beta.md b/api/tidb-cloud-api-v1beta.md index d16a5bc5d9214..600830f97ad46 100644 --- a/api/tidb-cloud-api-v1beta.md +++ b/api/tidb-cloud-api-v1beta.md @@ -10,7 +10,7 @@ summary: TiDB Cloudの v1beta API について学習します。 現在、次の v1beta API を使用してTiDB Cloud内のリソースを管理できます。 - [プロジェクト](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Project) -- [クラスタ](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Cluster) +- [クラスター](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Cluster) - [バックアップ](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Backup) - [インポート（非推奨）](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Import) - [復元する](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Restore) diff --git a/api/tidb-cloud-api-v1beta1.md b/api/tidb-cloud-api-v1beta1.md index 0604523051f20..3f20070acbff9 100644 --- a/api/tidb-cloud-api-v1beta1.md +++ b/api/tidb-cloud-api-v1beta1.md @@ -5,13 +5,13 @@ summary: TiDB Cloudの v1beta1 API について学習します。 # TiDB CloudAPI v1beta1 の概要 {#tidb-cloud-api-v1beta1-overview} -TiDB Cloud API v1beta1 は、 TiDB Cloud内の管理オブジェクトをプログラム的に管理するためのアクセスを提供する RESTful API です。この API を使用すると、クラスタレベルのリソース（クラスタやブランチなど）や組織レベルまたはプロジェクトレベルのリソース（課金、データサービス、 IAMなど）を自動的かつ効率的に管理できます。 +TiDB Cloud API v1beta1 は、 TiDB Cloud内の管理オブジェクトをプログラム的に管理するためのアクセスを提供する RESTful API です。この API を使用すると、クラスターレベルのリソース（クラスターやブランチなど）や組織レベルまたはプロジェクトレベルのリソース（課金、データサービス、 IAMなど）を自動的かつ効率的に管理できます。 現在、次の v1beta1 API を使用してTiDB Cloud内のリソースを管理できます。 - クラスターレベルのリソース: - - [TiDB Cloud Starter または Essential クラスタ](https://docs.pingcap.com/tidbcloud/api/v1beta1/serverless) : TiDB Cloud Starter または Essential クラスターのクラスター、ブランチ、データ エクスポート タスク、およびデータ インポート タスクを管理します。 - - [TiDB Cloud専用クラスタ](https://docs.pingcap.com/tidbcloud/api/v1beta1/dedicated) : TiDB Cloud Dedicated クラスターのクラスター、リージョン、プライベート エンドポイント接続、およびデータ インポート タスクを管理します。 + - [TiDB Cloud Starter または Essential クラスター](https://docs.pingcap.com/tidbcloud/api/v1beta1/serverless) : TiDB Cloud Starter または Essential クラスターのクラスター、ブランチ、データ エクスポート タスク、およびデータ インポート タスクを管理します。 + - [TiDB Cloud専用クラスター](https://docs.pingcap.com/tidbcloud/api/v1beta1/dedicated) : TiDB Cloud Dedicated クラスターのクラスター、リージョン、プライベート エンドポイント接続、およびデータ インポート タスクを管理します。 - 組織またはプロジェクトレベルのリソース: - [請求する](https://docs.pingcap.com/tidbcloud/api/v1beta1/billing) : TiDB Cloudクラスターの課金を管理します。 - [データサービス](https://docs.pingcap.com/tidbcloud/api/v1beta1/dataservice) : TiDB Cloudクラスターのデータ サービス内のリソースを管理します。 diff --git a/api/tidb-operator-api-overview.md b/api/tidb-operator-api-overview.md index f10dd8e69b8b7..e7c7140e7a8ac 100644 --- a/api/tidb-operator-api-overview.md +++ b/api/tidb-operator-api-overview.md @@ -5,7 +5,7 @@ summary: TiDB Operatorの API を学習します。 # TiDB OperatorAPI の概要 {#tidb-operator-api-overview} -[TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable/)は、Kubernetes上のTiDBクラスタの自動運用システムです。デプロイメント、アップグレード、スケーリング、バックアップ、フェイルオーバー、設定変更など、TiDBのライフサイクル全体にわたる管理を提供します。TiDB Operatorを使用することで、パブリッククラウドまたはプライベートクラウドにデプロイされたKubernetesクラスタ内でTiDBをシームレスに実行できます。 +[TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable/)は、Kubernetes上のTiDBクラスターの自動運用システムです。デプロイメント、アップグレード、スケーリング、バックアップ、フェイルオーバー、設定変更など、TiDBのライフサイクル全体にわたる管理を提供します。TiDB Operatorを使用することで、パブリッククラウドまたはプライベートクラウドにデプロイされたKubernetesクラスター内でTiDBをシームレスに実行できます。 Kubernetes 上で TiDB クラスターを管理するには、次のTiDB OperatorAPI を使用できます。 @@ -13,7 +13,7 @@ Kubernetes 上で TiDB クラスターを管理するには、次のTiDB Operato - [バックアップスケジュール](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#backupschedule) - [DMCluster](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#dmcluster) - [復元する](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#restore) -- [Tidbクラスタ](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#tidbcluster) +- [Tidbクラスター](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#tidbcluster) - [Tidbイニシャライザー](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#tidbinitializer) - [Tidbモニター](https://github.com/pingcap/tidb-operator/blob/v1.6.4/docs/api-references/docs.md#tidbmonitor) diff --git a/auto-increment.md b/auto-increment.md index 27dc00f232618..8c71c3bda1926 100644 --- a/auto-increment.md +++ b/auto-increment.md @@ -88,7 +88,7 @@ mysql> SELECT * FROM t; TiDB は`AUTO_INCREMENT`暗黙的な割り当てを次のように実装します。 -各自動インクリメント列には、割り当てられたIDの最大値を記録するために、グローバルに参照可能なキーと値のペアが使用されます。分散環境では、ノード間の通信にはオーバーヘッドが伴います。そのため、ライトアンプリフィケーションの問題を回避するために、各TiDBノードはIDを割り当てる際に、連続するIDのバッチをキャッシュとして適用し、最初のバッチが割り当てられた後、次のIDのバッチを適用します。したがって、TiDBノードはIDを割り当てるたびに、storageノードにIDを要求しません。例： +各自動インクリメント列には、割り当てられたIDの最大値を記録するために、グローバルに参照可能なキーと値のペアが使用されます。分散環境では、ノード間の通信にはオーバーヘッドが伴います。そのため、ライトアンプリフィケーションの問題を回避するために、各TiDBノードはIDを割り当てる際に、連続するIDのバッチをキャッシュとして適用し、最初のバッチが割り当てられた後、次のIDのバッチを適用します。したがって、TiDBノードはIDを割り当てるたびに、ストレージノードにIDを要求しません。例： ```sql CREATE TABLE t(id int UNIQUE KEY AUTO_INCREMENT, c int); @@ -108,7 +108,7 @@ INSERT INTO t (c) VALUES (1) > **警告：** > -> クラスタに複数のTiDBインスタンスがあり、テーブルスキーマに自動インクリメントIDが含まれている場合、明示的な挿入と暗黙的な割り当て（自動インクリメント列のデフォルト値とカスタム値の使用）を同時に使用しないことを推奨します。そうしないと、暗黙的に割り当てられた値の一意性が損なわれる可能性があります。 +> クラスターに複数のTiDBインスタンスがあり、テーブルスキーマに自動インクリメントIDが含まれている場合、明示的な挿入と暗黙的な割り当て（自動インクリメント列のデフォルト値とカスタム値の使用）を同時に使用しないことを推奨します。そうしないと、暗黙的に割り当てられた値の一意性が損なわれる可能性があります。 上記の例では、次の操作を順番に実行します。 @@ -344,13 +344,13 @@ SELECT * FROM t; - [データ移行（DM）](/dm/dm-overview.md)使用した増分レプリケーションのシナリオでは、レプリケーションが完了すると、下流の TiDB へのデータ書き込みは DM からアプリケーションの書き込み操作に切り替わります。同時に、自動インクリメント列の ID 書き込みモードは通常、明示的な挿入から暗黙的な割り当てに切り替わります。 -- TiDB Lightningはデータのインポートを完了すると、自動増分IDキャッシュを自動的にクリアします。しかし、TiCDCは増分データ同期後にキャッシュを自動的にクリアしません。そのため、TiCDCを停止した後、フェイルオーバーを実行する前に、下流クラスタの自動増分IDキャッシュを手動でクリアする必要があります。 +- TiDB Lightningはデータのインポートを完了すると、自動増分IDキャッシュを自動的にクリアします。しかし、TiCDCは増分データ同期後にキャッシュを自動的にクリアしません。そのため、TiCDCを停止した後、フェイルオーバーを実行する前に、下流クラスターの自動増分IDキャッシュを手動でクリアする必要があります。 - [データ移行](/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md)機能を使用した増分レプリケーションのシナリオでは、レプリケーションが完了すると、下流 TiDB へのデータ書き込みは DM からアプリケーションの書き込み操作に切り替わります。同時に、自動インクリメント列の ID 書き込みモードは通常、明示的な挿入から暗黙的な割り当てに切り替わります。 -- TiDB Lightningはデータのインポートを完了すると、自動増分IDキャッシュを自動的にクリアします。しかし、TiCDCは増分データ同期後にキャッシュを自動的にクリアしません。そのため、TiCDCを停止した後、フェイルオーバーを実行する前に、下流クラスタの自動増分IDキャッシュを手動でクリアする必要があります。 +- TiDB Lightningはデータのインポートを完了すると、自動増分IDキャッシュを自動的にクリアします。しかし、TiCDCは増分データ同期後にキャッシュを自動的にクリアしません。そのため、TiCDCを停止した後、フェイルオーバーを実行する前に、下流クラスターの自動増分IDキャッシュを手動でクリアする必要があります。 diff --git a/auto-random.md b/auto-random.md index e44c1c354ac46..0213d4b81bf93 100644 --- a/auto-random.md +++ b/auto-random.md @@ -7,7 +7,7 @@ summary: AUTO_RANDOM 属性について学習します。 ## ユーザーシナリオ {#user-scenario} -`AUTO_RANDOM`の値はランダムかつ一意であるため、TiDBが連続したIDを割り当てることで単一storageノードに書き込みホットスポットが発生するのを回避するため、 [`AUTO_INCREMENT`](/auto-increment.md)の代わりに`AUTO_RANDOM`使用されることがよくあります。現在の`AUTO_INCREMENT`列が主キーで、型が`BIGINT`場合、 `ALTER TABLE t MODIFY COLUMN id BIGINT AUTO_RANDOM(5);`ステートメントを実行して`AUTO_INCREMENT`から`AUTO_RANDOM`に切り替えることができます。 +`AUTO_RANDOM`の値はランダムかつ一意であるため、TiDBが連続したIDを割り当てることで単一ストレージノードに書き込みホットスポットが発生するのを回避するため、 [`AUTO_INCREMENT`](/auto-increment.md)の代わりに`AUTO_RANDOM`使用されることがよくあります。現在の`AUTO_INCREMENT`列が主キーで、型が`BIGINT`場合、 `ALTER TABLE t MODIFY COLUMN id BIGINT AUTO_RANDOM(5);`ステートメントを実行して`AUTO_INCREMENT`から`AUTO_RANDOM`に切り替えることができます。 @@ -121,7 +121,7 @@ TiDB によって自動的に割り当てられる`AUTO_RANDOM(S, R)`列の値 - 符号ビットの長さは、属性`UNSIGNED`有無によって決まります。属性`UNSIGNED`がある場合、長さは`0`です。そうでない場合、長さは`1`です。 - 予約ビットの長さは`64-R`です。予約ビットは常に`0`です。 - シャードビットの内容は、現在のトランザクションの開始時刻のハッシュ値を計算することで得られます。異なるシャードビット長（10など）を使用する場合は、テーブル作成時に`AUTO_RANDOM(10)`指定します。 -- 自動インクリメントビットの値はstorageエンジンに格納され、順次割り当てられます。新しい値が割り当てられるたびに、値は1ずつ増加します。自動インクリメントビットは、 `AUTO_RANDOM`の値がグローバルに一意であることを保証します。自動インクリメントビットが使い果たされると、値が再び割り当てられる際にエラー`Failed to read auto-increment value from storage engine`が報告されます。 +- 自動インクリメントビットの値はストレージエンジンに格納され、順次割り当てられます。新しい値が割り当てられるたびに、値は1ずつ増加します。自動インクリメントビットは、 `AUTO_RANDOM`の値がグローバルに一意であることを保証します。自動インクリメントビットが使い果たされると、値が再び割り当てられる際にエラー`Failed to read auto-increment value from ストレージ engine`が報告されます。 - 値の範囲：最終的に生成される値の最大ビット数 = シャードビット数 + 自動インクリメントビット数。符号付き列の範囲は`[-(2^(R-1))+1, (2^(R-1))-1]` 、符号なし列の範囲は`[0, (2^R)-1]`です。 - `AUTO_RANDOM` `PRE_SPLIT_REGIONS`と組み合わせて使用できます。テーブルが正常に作成されると、 `PRE_SPLIT_REGIONS`テーブル内のデータを`2^(PRE_SPLIT_REGIONS)`で指定された数のリージョンに事前に分割します。 @@ -130,7 +130,7 @@ TiDB によって自動的に割り当てられる`AUTO_RANDOM(S, R)`列の値 > シャードビットの選択（ `S` ）： > > - 利用可能なビット数は合計64ビットであるため、シャードビット長は自動インクリメントビット長に影響します。つまり、シャードビット長が増加すると自動インクリメントビット長は減少し、逆もまた同様です。したがって、割り当てられた値のランダム性と利用可能なスペースのバランスをとる必要があります。 -> - ベストプラクティスは、シャードビットを`log(2, x)`に設定することです。ここで、 `x`現在のstorageエンジンの数です。例えば、TiDB クラスターに TiKV ノードが 16 個ある場合、シャードビットを`log(2, 16)` （つまり`4`に設定できます。すべてのリージョンが各 TiKV ノードに均等にスケジュールされると、一括書き込みの負荷が複数の TiKV ノードに均等に分散され、リソース使用率を最大化できます。 +> - ベストプラクティスは、シャードビットを`log(2, x)`に設定することです。ここで、 `x`現在のストレージエンジンの数です。例えば、TiDB クラスターに TiKV ノードが 16 個ある場合、シャードビットを`log(2, 16)` （つまり`4`に設定できます。すべてのリージョンが各 TiKV ノードに均等にスケジュールされると、一括書き込みの負荷が複数の TiKV ノードに均等に分散され、リソース使用率を最大化できます。 > > 範囲の選択（ `R` ）： > diff --git a/backup-and-restore-using-dumpling-lightning.md b/backup-and-restore-using-dumpling-lightning.md index bad4b0a67329e..67bc6f41bbabe 100644 --- a/backup-and-restore-using-dumpling-lightning.md +++ b/backup-and-restore-using-dumpling-lightning.md @@ -37,11 +37,11 @@ summary: DumplingとTiDB Lightningを使用して TiDB の完全なデータを **ディスク容量**: -外部storageとしては、Amazon S3、Google Cloud Storage（GCS）、またはAzure Blob Storageの使用をお勧めします。これらのクラウドstorageを使用すれば、ディスク容量に制限されることなく、バックアップファイルを迅速に保存できます。 +外部ストレージとしては、Amazon S3、Google Cloud Storage（GCS）、またはAzure Blob Storageの使用をお勧めします。これらのクラウドストレージを使用すれば、ディスク容量に制限されることなく、バックアップファイルを迅速に保存できます。 1 つのバックアップ タスクのデータをローカル ディスクに保存する必要がある場合は、次の制限に注意してください。 -- Dumpling には、データソース全体（またはエクスポートする上流テーブルすべて）を保存できるディスク容量が必要です。必要な容量を計算するには、 [下流のstorageスペース要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)参照してください。 +- Dumpling には、データソース全体（またはエクスポートする上流テーブルすべて）を保存できるディスク容量が必要です。必要な容量を計算するには、 [下流のストレージスペース要件](/tidb-lightning/tidb-lightning-requirements.md#ストレージ-space-of-the-target-database)参照してください。 - インポート中、 TiDB Lightning はソートされたキーと値のペアを保存するために一時的なスペースを必要とします。ディスク容量は、データソースの最大の単一テーブルを保存できる十分な量である必要があります。 **注意**: MySQL からDumplingによってエクスポートされる正確なデータ量を計算することは困難ですが、次の SQL 文を使用して`information_schema.tables`テーブルの`DATA_LENGTH`フィールドを要約することで、データ量を見積もることができます。 @@ -77,7 +77,7 @@ LIMIT ### ターゲット TiKV クラスターのディスク容量 {#disk-space-for-the-target-tikv-cluster} -ターゲットTiKVクラスターには、インポートしたデータを保存するための十分なディスク容量が必要です。1 [標準的なハードウェア要件](/hardware-and-software-requirements.md)加えて、ターゲットTiKVクラスターのstorage容量**は、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。例えば、クラスターがデフォルトで3つのレプリカを使用する場合、ターゲットTiKVクラスターには、データソースのサイズの6倍よりも大きなstorage容量が必要です。式に x 2 が含まれているのは、以下の理由によるものです。 +ターゲットTiKVクラスターには、インポートしたデータを保存するための十分なディスク容量が必要です。1 [標準的なハードウェア要件](/hardware-and-software-requirements.md)加えて、ターゲットTiKVクラスターのストレージ容量**は、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。例えば、クラスターがデフォルトで3つのレプリカを使用する場合、ターゲットTiKVクラスターには、データソースのサイズの6倍よりも大きなストレージ容量が必要です。式に x 2 が含まれているのは、以下の理由によるものです。 - インデックスは追加のスペースを占める可能性があります。 - RocksDB には空間増幅効果があります。 @@ -110,7 +110,7 @@ LIMIT # "local": Default backend. The local backend is recommended to import large volumes of data (1 TiB or more). During the import, the target TiDB cluster cannot provide any service. # "tidb": The "tidb" backend is recommended to import data less than 1 TiB. During the import, the target TiDB cluster can provide service normally. For more information on the backends, refer to https://docs.pingcap.com/tidb/stable/tidb-lightning-backends. backend = "local" - # Sets the temporary storage directory for the sorted Key-Value files. The directory must be empty, and the storage space must be greater than the size of the dataset to be imported. For better import performance, it is recommended to use a directory different from `data-source-dir` and use flash storage, which can use I/O exclusively. + # Sets the temporary ストレージ directory for the sorted Key-Value files. The directory must be empty, and the ストレージ space must be greater than the size of the dataset to be imported. For better import performance, it is recommended to use a directory different from `data-source-dir` and use flash ストレージ, which can use I/O exclusively. sorted-kv-dir = "${sorted-kv-dir}" [mydumper] @@ -127,11 +127,11 @@ LIMIT pd-addr = "${ip}:${port}" # The address of the PD cluster, e.g.: 172.16.31.3:2379. TiDB Lightning obtains some information from PD. When backend = "local", you must specify status-port and pd-addr correctly. Otherwise, the import will be abnormal. ``` - TiDB Lightning構成の詳細については、 [TiDB Lightningコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 + TiDB Lightning構成の詳細については、 [TiDB Lightning設定](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 2. `tidb-lightning`実行してインポートを開始します。コマンドラインでプログラムを直接起動すると、 `SIGHUP`シグナルを受け取った後にプロセスが予期せず終了する可能性があります。その場合は、 `nohup`または`screen`ツールを使用してプログラムを実行することをお勧めします。例: - S3からデータをインポートする場合は、S3storageパスへのアクセス権を持つSecretKeyとAccessKeyを環境変数としてTiDB Lightningノードに渡します。また、 `~/.aws/credentials`から認証情報を読み取ることもできます。 + S3からデータをインポートする場合は、S3ストレージパスへのアクセス権を持つSecretKeyとAccessKeyを環境変数としてTiDB Lightningノードに渡します。また、 `~/.aws/credentials`から認証情報を読み取ることもできます。 ```shell export AWS_ACCESS_KEY_ID=${access_key} diff --git a/basic-features.md b/basic-features.md index 72b3c120b6f17..22421767e6210 100644 --- a/basic-features.md +++ b/basic-features.md @@ -50,18 +50,18 @@ summary: TiDBの機能概要について学びましょう。 | インデックスと制約 | 8.5 | 8.1 | 7.5 | 7.1 | 6.5 | 6.1 | 5.4 | | ------------------------------------------------------------------------------------------- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | [発現インデックス](/sql-statements/sql-statement-create-index.md#expression-index)[^2] | Y | Y | Y | Y | Y | E | E | -| [カラム型storage（TiFlash）](/tiflash/tiflash-overview.md) | Y | Y | Y | Y | Y | Y | Y | +| [カラム型ストレージ（TiFlash）](/tiflash/tiflash-overview.md) | Y | Y | Y | Y | Y | Y | Y | | [FastScanを使用してOLAPシナリオにおけるクエリを高速化する](/tiflash/use-fastscan.md) | Y | Y | Y | Y | E | N | N | -| [RocksDBエンジン](/storage-engine/rocksdb-overview.md) | Y | Y | Y | Y | Y | Y | Y | -| [Titanプラグイン](/storage-engine/titan-overview.md) | Y | Y | Y | Y | Y | Y | Y | -| [タイタンレベルマージ](/storage-engine/titan-configuration.md#level-merge-experimental) | E | E | E | E | E | E | E | +| [RocksDBエンジン](/ストレージ-engine/rocksdb-overview.md) | Y | Y | Y | Y | Y | Y | Y | +| [Titanプラグイン](/ストレージ-engine/titan-overview.md) | Y | Y | Y | Y | Y | Y | Y | +| [Titanレベルマージ](/ストレージ-engine/titan-configuration.md#level-merge-experimental) | E | E | E | E | E | E | E | | [バケットを使用してスキャンの同時実行性を向上させる](/tune-region-performance.md#use-bucket-to-increase-concurrency) | E | E | E | E | E | E | N | | [見えないインデックス](/sql-statements/sql-statement-create-index.md#invisible-index) | Y | Y | Y | Y | Y | Y | Y | | [複合`PRIMARY KEY`](/constraints.md) | Y | Y | Y | Y | Y | Y | Y | | [`CHECK`制約](/constraints.md#check) | Y | Y | Y | N | N | N | N | | [一意のインデックス](/constraints.md) | Y | Y | Y | Y | Y | Y | Y | -| [整数型の`PRIMARY KEY`に対するクラスタ化インデックス](/clustered-indexes.md) | Y | Y | Y | Y | Y | Y | Y | -| [複合キーまたは非整数キーに対するクラスタ化インデックス](/clustered-indexes.md) | Y | Y | Y | Y | Y | Y | Y | +| [整数型の`PRIMARY KEY`に対するクラスター化インデックス](/clustered-indexes.md) | Y | Y | Y | Y | Y | Y | Y | +| [複合キーまたは非整数キーに対するクラスター化インデックス](/clustered-indexes.md) | Y | Y | Y | Y | Y | Y | Y | | [多値インデックス](/sql-statements/sql-statement-create-index.md#multi-valued-indexes) | Y | Y | Y | Y | N | N | N | | [外部キー](/foreign-key.md) | Y | E | E | E | N | N | N | | [TiFlashの遅延実現](/tiflash/tiflash-late-materialization.md) | Y | Y | Y | Y | N | N | N | @@ -124,7 +124,7 @@ summary: TiDBの機能概要について学びましょう。 | ------------------------------------------------------------------------------------------------------------------------ | :-: | :-: | :-: | :-: | :---: | :-: | :-: | | 基本`CREATE` 、 `DROP` 、 `ALTER` 、 `RENAME` 、 `TRUNCATE` | Y | Y | Y | Y | Y | Y | Y | | [生成された列](/generated-columns.md) | Y | Y | Y | Y | E | E | E | -| [閲覧数](/views.md) | Y | Y | Y | Y | Y | Y | Y | +| [ビュー](/views.md) | Y | Y | Y | Y | Y | Y | Y | | [シーケンス](/sql-statements/sql-statement-create-sequence.md) | Y | Y | Y | Y | Y | Y | Y | | [自動インクリメント](/auto-increment.md) | Y | Y | Y | Y | Y[^4] | Y | Y | | [自動ランダム](/auto-random.md) | Y | Y | Y | Y | Y | Y | Y | @@ -141,15 +141,15 @@ summary: TiDBの機能概要について学びましょう。 | [TiDB高速テーブル作成](/accelerated-table-creation.md) | Y | E | N | N | N | N | N | | [BDRロールを構成して、BDRモードでDDLステートメントを複製するようにします。](/sql-statements/sql-statement-admin-bdr-role.md#admin-setshowunset-bdr-role) | Y | E | N | N | N | N | N | -## 取引 {#transactions} +## トランザクション {#transactions} -| 取引 | 8.5 | 8.1 | 7.5 | 7.1 | 6.5 | 6.1 | 5.4 | +| トランザクション | 8.5 | 8.1 | 7.5 | 7.1 | 6.5 | 6.1 | 5.4 | | ---------------------------------------------------------------------------------------------------- | :-: | :-: | :-: | :-: | :-: | :-: | :-: | | [非同期コミット](/system-variables.md#tidb_enable_async_commit-new-in-v50) | Y | Y | Y | Y | Y | Y | Y | | [1個](/system-variables.md#tidb_enable_1pc-new-in-v50) | Y | Y | Y | Y | Y | Y | Y | | [大規模トランザクション（1 TiB）](/transaction-overview.md#transaction-size-limit) | Y | Y | Y | Y | Y | Y | Y | -| [悲観的な取引](/pessimistic-transaction.md) | Y | Y | Y | Y | Y | Y | Y | -| [楽観的な取引](/optimistic-transaction.md) | Y | Y | Y | Y | Y | Y | Y | +| [悲観的なトランザクション](/pessimistic-transaction.md) | Y | Y | Y | Y | Y | Y | Y | +| [楽観的なトランザクション](/optimistic-transaction.md) | Y | Y | Y | Y | Y | Y | Y | | [反復読み取り分離（スナップショット分離）](/transaction-isolation-levels.md) | Y | Y | Y | Y | Y | Y | Y | | [リードコミット隔離](/transaction-isolation-levels.md) | Y | Y | Y | Y | Y | Y | Y | | [長時間実行されているアイドル状態のトランザクションを自動的に終了する](/system-variables.md#tidb_idle_transaction_timeout-new-in-v760) | Y | Y | N | N | N | N | N | @@ -223,8 +223,8 @@ summary: TiDBの機能概要について学びましょう。 | [データベース移行ツールキット（DM）](/migration-overview.md) | Y | Y | Y | Y | Y | Y | Y | | [TiDBBinlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/) [^6] | 削除済み | Y | Y | Y | Y | Y | Y | | [変更データキャプチャ（CDC）](/ticdc/ticdc-overview.md) | Y | Y | Y | Y | Y | Y | Y | -| [TiCDCを介してAmazon S3、GCS、Azure Blob Storage、NFSにデータをストリーミングする](/ticdc/ticdc-sink-to-cloud-storage.md) | Y | Y | Y | Y | E | N | N | -| [TiCDCは、2つのTiDBクラスタ間での双方向レプリケーションをサポートしています。](/ticdc/ticdc-bidirectional-replication.md) | Y | Y | Y | Y | Y | N | N | +| [TiCDCを介してAmazon S3、GCS、Azure Blob Storage、NFSにデータをストリーミングする](/ticdc/ticdc-sink-to-cloud-ストレージ.md) | Y | Y | Y | Y | E | N | N | +| [TiCDCは、2つのTiDBクラスター間での双方向レプリケーションをサポートしています。](/ticdc/ticdc-bidirectional-replication.md) | Y | Y | Y | Y | Y | N | N | | [TiCDC OpenAPI v2](/ticdc/ticdc-open-api-v2.md) | Y | Y | Y | Y | N | N | N | | [DM](/dm/dm-overview.md) MySQL 8.0の移行をサポートしています | Y | Y | E | E | E | E | N | @@ -236,7 +236,7 @@ summary: TiDBの機能概要について学びましょう。 | [TiDBダッシュボードの継続的プロファイリング](/dashboard/continuous-profiling.md) | Y | Y | Y | Y | Y | Y | E | | [TiDBダッシュボードのTop SQL](/dashboard/top-sql.md) | Y | Y | Y | Y | Y | Y | E | | [TiDBダッシュボードのSQL診断](/information-schema/information-schema-sql-diagnostics.md) | Y | Y | Y | Y | Y | E | E | -| [TiDBダッシュボードクラスタ診​​断](/dashboard/dashboard-diagnostics-access.md) | Y | Y | Y | Y | Y | E | E | +| [TiDBダッシュボードクラスター診​​断](/dashboard/dashboard-diagnostics-access.md) | Y | Y | Y | Y | Y | E | E | | [TiKV-FastTuneダッシュボード](/grafana-tikv-dashboard.md#tikv-fasttune-dashboard) | E | E | E | E | E | E | E | | [情報スキーマ](/information-schema/information-schema.md) | Y | Y | Y | Y | Y | Y | Y | | [メトリクススキーマ](/metrics-schema.md) | Y | Y | Y | Y | Y | Y | Y | @@ -281,4 +281,4 @@ summary: TiDBの機能概要について学びましょう。 [^5]: [TiDB v7.0.0](/releases/release-7.0.0.md)以降、新しいパラメータ`FIELDS DEFINED NULL BY`と S3 および GCS からのデータインポートのサポートは実験的機能です[v7.6.0](/releases/release-7.6.0.md)以降、TiDB は`LOAD DATA`トランザクションで MySQL と同じように処理します。トランザクション内の`LOAD DATA`ステートメントは、現在のトランザクションを自動的にコミットしたり、新しいトランザクションを開始したりしなくなりました。さらに、トランザクション内の`LOAD DATA`ステートメントを明示的にコミットまたはロールバックできます。また、 `LOAD DATA`ステートメントは、TiDB トランザクション モード設定 (楽観的トランザクションまたは悲観的トランザクション) の影響を受けます。 -[^6]: バージョン 7.5.0 以降、 [TiDBBinlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)レプリケーションは非推奨となりました。バージョン 8.3.0 以降、TiDB Binlogは完全に非推奨となりました。バージョン 8.4.0 以降、TiDB Binlogは削除されました。増分データレプリケーションには、代わりに[TiCDC](/ticdc/ticdc-overview.md)を使用してください。ポイントインタイムリカバリ(PITR) には、 [PITR](/br/br-pitr-guide.md)を使用してください。TiDB クラスタをバージョン 8.4.0 以降にアップグレードする前に、必ず TiCDC と PITR に切り替えてください。 +[^6]: バージョン 7.5.0 以降、 [TiDBBinlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)レプリケーションは非推奨となりました。バージョン 8.3.0 以降、TiDB Binlogは完全に非推奨となりました。バージョン 8.4.0 以降、TiDB Binlogは削除されました。増分データレプリケーションには、代わりに[TiCDC](/ticdc/ticdc-overview.md)を使用してください。ポイントインタイムリカバリ(PITR) には、 [PITR](/br/br-pitr-guide.md)を使用してください。TiDB クラスターをバージョン 8.4.0 以降にアップグレードする前に、必ず TiCDC と PITR に切り替えてください。 diff --git a/basic-sql-operations.md b/basic-sql-operations.md index 08217dfe92f54..7b0a9e761fb97 100644 --- a/basic-sql-operations.md +++ b/basic-sql-operations.md @@ -3,7 +3,7 @@ title: Explore SQL with TiDB summary: TiDB データベースの基本的な SQL ステートメントについて学習します。 --- -# TiDB で SQL を探索する {#explore-sql-with-tidb} +# TiDBでのSQL基本操作 {#explore-sql-with-tidb} TiDBはMySQLと互換性があり、ほとんどの場合MySQLステートメントを直接使用できます。サポートされていない機能については、 [MySQLとの互換性](/mysql-compatibility.md#unsupported-features)参照してください。 diff --git a/batch-processing.md b/batch-processing.md index 3da81974e746a..19c327f21fe10 100644 --- a/batch-processing.md +++ b/batch-processing.md @@ -57,7 +57,7 @@ summary: パイプライン DML、非トランザクション DML、IMPORT INTO` #### 主なメリット {#key-benefits} -- Streams data to the storage layer during transaction execution instead of buffering it entirely in memory, allowing transaction size no longer limited by TiDB memory and supporting ultra-large-scale data processing +- Streams data to the ストレージ layer during transaction execution instead of buffering it entirely in memory, allowing transaction size no longer limited by TiDB memory and supporting ultra-large-scale data processing - 標準のDMLに比べて優れたパフォーマンスを実現 - SQL を変更せずにシステム変数を通じて有効にすることができます diff --git a/benchmark/benchmark-sysbench-v2.md b/benchmark/benchmark-sysbench-v2.md index 7a0a4293e23d8..0006cea72a82a 100644 --- a/benchmark/benchmark-sysbench-v2.md +++ b/benchmark/benchmark-sysbench-v2.md @@ -34,7 +34,7 @@ IDCマシン ### バージョン1.0.8 {#v1-0-8} -| 成分 | ギットハッシュ | +| コンポーネント | ギットハッシュ | | ---- | ---------------------------------------- | | TiDB | 571f0bbd28a0b8155a5ee831992c986b90d21ab7 | | TiKV | 4ef5889947019e3cb55cc744f487aa63b42540e7 | @@ -42,7 +42,7 @@ IDCマシン ### v2.0.0-rc6 {#v2-0-0-rc6} -| 成分 | ギットハッシュ | +| コンポーネント | ギットハッシュ | | :--: | :--------------------------------------: | | TiDB | 82d35f1b7f9047c478f4e1e82aa0002abc8107e7 | | TiKV | 7ed4f6a91f92cad5cd5323aaebe7d9f04b77cc79 | @@ -63,19 +63,19 @@ IDCマシン grpc-raft-conn-num = 24 use-delete-range: false -### クラスタトポロジー {#cluster-topology} +### クラスタートポロジー {#cluster-topology} | マシンIP | デプロイメントインスタンス | | ----------- | ------------------------ | | 172.16.21.1 | 1 *tidb、1* pd、1*sysbench | | 172.16.21.2 | 1 *tidb、1* pd、1*sysbench | | 172.16.21.3 | 1 *tidb、1* pd、1*sysbench | -| 172.16.11.4 | 1*ティクヴ | -| 172.16.11.5 | 1*ティクヴ | -| 172.16.11.6 | 1*ティクヴ | -| 172.16.11.7 | 1*ティクヴ | -| 172.16.11.8 | 1*ティクヴ | -| 172.16.11.9 | 1*ティクヴ | +| 172.16.11.4 | 1*TiKV | +| 172.16.11.5 | 1*TiKV | +| 172.16.11.6 | 1*TiKV | +| 172.16.11.7 | 1*TiKV | +| 172.16.11.8 | 1*TiKV | +| 172.16.11.9 | 1*TiKV | ## テスト結果 {#test-result} diff --git a/benchmark/benchmark-sysbench-v3.md b/benchmark/benchmark-sysbench-v3.md index 82aa9a7d805df..abbc6efe10b60 100644 --- a/benchmark/benchmark-sysbench-v3.md +++ b/benchmark/benchmark-sysbench-v3.md @@ -38,7 +38,7 @@ Sysbenchを使用して、**各テーブルに10,000,000行が含まれる16個 ### v2.1.0-rc.2 {#v2-1-0-rc-2} -| 成分 | ギットハッシュ | +| コンポーネント | ギットハッシュ | | :--: | :--------------------------------------: | | TiDB | 08e56cd3bae166b2af3c2f52354fbc9818717f62 | | TiKV | 57e684016dafb17dc8a6837d30224be66cbc7246 | @@ -46,7 +46,7 @@ Sysbenchを使用して、**各テーブルに10,000,000行が含まれる16個 ### バージョン2.0.6 {#v2-0-6} -| 成分 | ギットハッシュ | +| コンポーネント | ギットハッシュ | | :--: | :--------------------------------------: | | TiDB | b13bc08462a584a085f377625a7bab0cc0351570 | | TiKV | 57c83dc4ebc93d38d77dc8f7d66db224760766cc | @@ -73,7 +73,7 @@ block-cache-size = "60GB" block-cache-size = "20GB" ``` -### クラスタトポロジー {#cluster-topology} +### クラスタートポロジー {#cluster-topology} | マシンIP | デプロイメントインスタンス | | :----------: | :------------------: | diff --git a/benchmark/benchmark-sysbench-v4-vs-v3.md b/benchmark/benchmark-sysbench-v4-vs-v3.md index bdfc4ffdeb0ad..688cec176c86d 100644 --- a/benchmark/benchmark-sysbench-v4-vs-v3.md +++ b/benchmark/benchmark-sysbench-v4-vs-v3.md @@ -43,7 +43,7 @@ tikv-client.max-batch-wait-time: 2000000 #### TiKV v3.0 の構成 {#tikv-v3-0-configuration} ```yaml -storage.scheduler-worker-pool-size: 5 +ストレージ.scheduler-worker-pool-size: 5 raftstore.store-pool-size: 3 raftstore.apply-pool-size: 3 rocksdb.max-background-jobs: 3 @@ -66,7 +66,7 @@ tikv-client.max-batch-wait-time: 2000000 #### TiKV v4.0 の構成 {#tikv-v4-0-configuration} ```yaml -storage.scheduler-worker-pool-size: 5 +ストレージ.scheduler-worker-pool-size: 5 raftstore.store-pool-size: 3 raftstore.apply-pool-size: 3 rocksdb.max-background-jobs: 3 diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md index 1b9821105d88e..9240a21595e5d 100644 --- a/benchmark/benchmark-tidb-using-sysbench.md +++ b/benchmark/benchmark-tidb-using-sysbench.md @@ -48,7 +48,7 @@ server_configs: ```yaml server_configs: tikv: - storage.block-cache.capacity: "30GB" + ストレージ.block-cache.capacity: "30GB" ``` TiKV パフォーマンス チューニングの詳細については、 [TiKVパフォーマンスの調整](/tune-tikv-memory-performance.md)参照してください。 @@ -164,7 +164,7 @@ HAproxyを例に挙げましょう。パラメータ`nbproc`指定すると、 TiKV 全体の CPU 使用率は低いですが、クラスター内の一部のモジュールの CPU 使用率は高くなる可能性があります。 -storage読み取りプール、コプロセッサ、gRPC など、TiKV 上の他のモジュールの最大同時実行制限は、TiKV 構成ファイルを通じて調整できます。 +ストレージ読み取りプール、コプロセッサ、gRPC など、TiKV 上の他のモジュールの最大同時実行制限は、TiKV 構成ファイルを通じて調整できます。 実際のCPU使用率は、GrafanaのTiKVスレッドCPUモニターパネルで確認できます。モジュールにボトルネックがある場合は、モジュールの同時実行性を高めることで調整できます。 diff --git a/benchmark/benchmark-tidb-using-tpcc.md b/benchmark/benchmark-tidb-using-tpcc.md index f1e39475b320d..69eb092120726 100644 --- a/benchmark/benchmark-tidb-using-tpcc.md +++ b/benchmark/benchmark-tidb-using-tpcc.md @@ -22,7 +22,7 @@ TPC-Cベンチマークでは、テスト前にデータベースの初期状態 - `STOCK`テーブルにはW * 100,000件のレコードがあります（各倉庫は100,000点の在庫データに対応します） - `DISTRICT`テーブルにはW * 10のレコードがあります（各倉庫は10の地区にサービスを提供しています） - `CUSTOMER`テーブルには W * 10 * 3,000 のレコードがあります (各地区には 3,000 人の顧客がいます) -- `HISTORY`テーブルには W * 10 * 3,000 件のレコードがあります (各顧客には 1 つの取引履歴があります) +- `HISTORY`テーブルには W * 10 * 3,000 件のレコードがあります (各顧客には 1 つのトランザクション履歴があります) - `ORDER`テーブルには W * 10 * 3,000 件のレコードがあります (各地区には 3,000 件の注文があり、生成された最後の 900 件の注文が`NEW-ORDER`テーブルに追加されます。各注文は 5 ~ 15 件の ORDER-LINE レコードをランダムに生成します。) このドキュメントでは、TiDB をテストするために、例として 1,000 個のウェアハウスを使用します。 diff --git a/benchmark/benchmark-tpch.md b/benchmark/benchmark-tpch.md index af24807345074..a21edb0397ec9 100644 --- a/benchmark/benchmark-tpch.md +++ b/benchmark/benchmark-tpch.md @@ -41,7 +41,7 @@ summary: TiDB TPC-H 50Gパフォーマンステストでは、OLAPシナリオ [tidb-bench/tpch](https://github.com/pingcap/tidb-bench/tree/master/tpch) -### クラスタトポロジー {#cluster-topology} +### クラスタートポロジー {#cluster-topology} | マシンIP | デプロイメントインスタンス | | ------------ | ------------- | @@ -57,7 +57,7 @@ summary: TiDB TPC-H 50Gパフォーマンステストでは、OLAPシナリオ TiDB 1.0: -| 成分 | バージョン | コミットハッシュ | +| コンポーネント | バージョン | コミットハッシュ | | ---- | ---------- | ---------------------------------------- | | TiDB | バージョン1.0.9 | 4c7ee3580cd0a69319b2c0c08abdc59900df7344 | | TiKV | バージョン1.0.8 | 2bb923a4cd23dbf68f0d16169fd526dc5c1a9f4a | @@ -65,7 +65,7 @@ TiDB 1.0: TiDB 2.0: -| 成分 | バージョン | コミットハッシュ | +| コンポーネント | バージョン | コミットハッシュ | | ---- | ----------- | ---------------------------------------- | | TiDB | v2.0.0-rc.6 | 82d35f1b7f9047c478f4e1e82aa0002abc8107e7 | | TiKV | v2.0.0-rc.6 | 8bd5c54966c6ef42578a27519bce4915c5b0c81f | diff --git a/benchmark/online-workloads-and-add-index-operations.md b/benchmark/online-workloads-and-add-index-operations.md index 3a87212b985e3..d7cd606ca8143 100644 --- a/benchmark/online-workloads-and-add-index-operations.md +++ b/benchmark/online-workloads-and-add-index-operations.md @@ -23,7 +23,7 @@ TiDB バージョン: v3.0.1 ### バージョン情報 {#version-information} -| 成分 | ギットハッシュ | +| コンポーネント | ギットハッシュ | | :--- | :----------------------------------------- | | TiDB | `9e4e8da3c58c65123db5f26409759fe1847529f8` | | TiKV | `4151dc8878985df191b47851d67ca21365396133` | @@ -35,7 +35,7 @@ Sysbench バージョン: 1.0.17 TiDB、TiKV、PD はすべてデフォルトの[TiDB Operator](https://github.com/pingcap/tidb-operator)構成を使用します。 -### クラスタトポロジー {#cluster-topology} +### クラスタートポロジー {#cluster-topology} | マシンIP | デプロイメントインスタンス | | :--------------------------------------- | :------------ | diff --git a/benchmark/v3.0-performance-benchmarking-with-sysbench.md b/benchmark/v3.0-performance-benchmarking-with-sysbench.md index dcadf26fe2e1f..fe448f696306b 100644 --- a/benchmark/v3.0-performance-benchmarking-with-sysbench.md +++ b/benchmark/v3.0-performance-benchmarking-with-sysbench.md @@ -1,6 +1,6 @@ --- title: TiDB Sysbench Performance Test Report -- v3.0 vs. v2.1 -summary: TiDB v3.0は、すべてのテストにおいてv2.1を上回り、QPSの向上とレイテンシーの低減を実現しました。v3.0におけるコンフィグレーションの変更が、パフォーマンスの向上に貢献しました。 +summary: TiDB v3.0は、すべてのテストにおいてv2.1を上回り、QPSの向上とレイテンシーの低減を実現しました。v3.0における設定の変更が、パフォーマンスの向上に貢献しました。 --- # TiDB Sysbench パフォーマンス テスト レポート - v3.0 と v2.1 の比較 {#tidb-sysbench-performance-test-report-v3-0-vs-v2-1} @@ -21,7 +21,7 @@ TiDB バージョン: v3.0.0 と v2.1.13 このテストはAWS EC2上で実行され、CentOS-7.6.1810-Nitro (ami-028946f4cffc8b916) イメージを使用します。インスタンスのコンポーネントとタイプは次のとおりです。 -| 成分 | インスタンスタイプ | +| コンポーネント | インスタンスタイプ | | :--- | :---------- | | PD | r5d.xlarge | | TiKV | c5d.4xlarge | @@ -70,7 +70,7 @@ sysbench $testname \ ### バージョン3.0.0 {#v3-0-0} -| 成分 | ギットハッシュ | +| コンポーネント | ギットハッシュ | | :--- | :----------------------------------------- | | TiDB | `8efbe62313e2c1c42fd76d35c6f020087eef22c2` | | TiKV | `a467f410d235fa9c5b3c355e3b620f81d3ac0e0c` | @@ -78,7 +78,7 @@ sysbench $testname \ ### バージョン2.1.13 {#v2-1-13} -| 成分 | ギットハッシュ | +| コンポーネント | ギットハッシュ | | :--- | :----------------------------------------- | | TiDB | `6b5b1a6802f9b8f5a22d8aab24ac80729331e1bc` | | TiKV | `b3cf3c8d642534ea6fa93d475a46da285cc6acbf` | @@ -140,7 +140,7 @@ apply-pool-size = 3 store-pool-size = 3 ``` -### クラスタトポロジー {#cluster-topology} +### クラスタートポロジー {#cluster-topology} | マシンIP | デプロイメントインスタンス | | :--------------------------------------- | :------------ | diff --git a/benchmark/v3.0-performance-benchmarking-with-tpcc.md b/benchmark/v3.0-performance-benchmarking-with-tpcc.md index 2b3ac775af734..bae8c1a4ff3bb 100644 --- a/benchmark/v3.0-performance-benchmarking-with-tpcc.md +++ b/benchmark/v3.0-performance-benchmarking-with-tpcc.md @@ -42,7 +42,7 @@ BenchmarkSQLを使用して、 **1,000個のウェアハウス**のデータをT ### バージョン3.0.0 {#v3-0-0} -| 成分 | ギットハッシュ | +| コンポーネント | ギットハッシュ | | :--- | :--------------------------------------- | | TiDB | 46c38e15eba43346fb3001280c5034385171ee20 | | TiKV | a467f410d235fa9c5b3c355e3b620f81d3ac0e0c | @@ -50,7 +50,7 @@ BenchmarkSQLを使用して、 **1,000個のウェアハウス**のデータをT ### バージョン2.1.13 {#v2-1-13} -| 成分 | ギットハッシュ | +| コンポーネント | ギットハッシュ | | :--- | :--------------------------------------- | | TiDB | 6b5b1a6802f9b8f5a22d8aab24ac80729331e1bc | | TiKV | b3cf3c8d642534ea6fa93d475a46da285cc6acbf | @@ -71,7 +71,7 @@ enabled = true デフォルトの TiKV 構成は、v2.1 と v3.0 の両方で使用されます。 -### クラスタトポロジー {#cluster-topology} +### クラスタートポロジー {#cluster-topology} | マシンIP | デプロイメントインスタンス | | :---------- | :----------------- | diff --git a/benchmark/v4.0-performance-benchmarking-with-tpcc.md b/benchmark/v4.0-performance-benchmarking-with-tpcc.md index 2d368859259cb..7cb2da1c44da4 100644 --- a/benchmark/v4.0-performance-benchmarking-with-tpcc.md +++ b/benchmark/v4.0-performance-benchmarking-with-tpcc.md @@ -43,7 +43,7 @@ tikv-client.max-batch-wait-time: 2000000 #### TiKV v3.0 の構成 {#tikv-v3-0-configuration} ```yaml -storage.scheduler-worker-pool-size: 5 +ストレージ.scheduler-worker-pool-size: 5 raftstore.store-pool-size: 3 raftstore.apply-pool-size: 3 rocksdb.max-background-jobs: 3 @@ -66,7 +66,7 @@ tikv-client.max-batch-wait-time: 2000000 #### TiKV v4.0 の構成 {#tikv-v4-0-configuration} ```yaml -storage.scheduler-worker-pool-size: 5 +ストレージ.scheduler-worker-pool-size: 5 raftstore.store-pool-size: 3 raftstore.apply-pool-size: 3 rocksdb.max-background-jobs: 3 diff --git a/best-practices-for-security-configuration.md b/best-practices-for-security-configuration.md index c748d199fd712..946ffb7b73c94 100644 --- a/best-practices-for-security-configuration.md +++ b/best-practices-for-security-configuration.md @@ -3,9 +3,9 @@ title: Best Practices for TiDB Security Configuration summary: 潜在的なセキュリティ リスクを軽減するために、TiDB セキュリティ構成のベスト プラクティスを学習します。 --- -# TiDBSecurityコンフィグレーションのベストプラクティス {#best-practices-for-tidb-security-configuration} +# TiDBSecurity設定のベストプラクティス {#best-practices-for-tidb-security-configuration} -TiDBのセキュリティは、データの整合性と機密性を保護するために不可欠です。このドキュメントでは、導入時にTiDBクラスタを安全に構成するためのガイドラインを示します。これらのベストプラクティスに従うことで、潜在的なセキュリティリスクを効果的に軽減し、データ侵害を防ぎ、TiDBデータベースシステムの継続的かつ安定した信頼性の高い運用を確保できます。 +TiDBのセキュリティは、データの整合性と機密性を保護するために不可欠です。このドキュメントでは、導入時にTiDBクラスターを安全に構成するためのガイドラインを示します。これらのベストプラクティスに従うことで、潜在的なセキュリティリスクを効果的に軽減し、データ侵害を防ぎ、TiDBデータベースシステムの継続的かつ安定した信頼性の高い運用を確保できます。 > **注記：** > @@ -13,11 +13,11 @@ TiDBのセキュリティは、データの整合性と機密性を保護する ## ルートユーザーの初期パスワードを設定する {#set-the-initial-password-for-the-root-user} -デフォルトでは、新規作成されたTiDBクラスタのrootユーザーにはパスワードが設定されていないため、潜在的なセキュリティリスクが生じます。パスワードが設定されていない場合、誰でもrootユーザーとしてTiDBデータベースにログインを試みることができ、データにアクセスして変更される可能性があります。 +デフォルトでは、新規作成されたTiDBクラスターのrootユーザーにはパスワードが設定されていないため、潜在的なセキュリティリスクが生じます。パスワードが設定されていない場合、誰でもrootユーザーとしてTiDBデータベースにログインを試みることができ、データにアクセスして変更される可能性があります。 このリスクを回避するには、デプロイメント中にルート パスワードを設定することをお勧めします。 -- TiUPを使用したデプロイメントの場合は、 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md#step-7-start-a-tidb-cluster)を参照して、ルート ユーザーのランダム パスワードを生成します。 +- TiUPを使用したデプロイメントの場合は、 [TiUPを使用して TiDBクラスターをデプロイ](/production-deployment-using-tiup.md#step-7-start-a-tidb-cluster)を参照して、ルート ユーザーのランダム パスワードを生成します。 - TiDB Operatorを使用したデプロイメントの場合は、 [初期アカウントとパスワードを設定する](https://docs.pingcap.com/tidb-in-kubernetes/stable/initialize-a-cluster#set-initial-account-and-password)を参照して root パスワードを設定してください。 [`--initialize-secure`](/command-line-flags-for-tidb-configuration.md#--initialize-secure)オプションを使用して、初期ルート ユーザーのネットワーク アクセスを制限することもできます。 @@ -64,9 +64,9 @@ TiDBダッシュボードは、デフォルトでは信頼できるユーザー ## 内部ポートを保護する {#protect-internal-ports} -TiDBのインストールには、デフォルトでコンポーネント間通信用の特権インターフェースがいくつか含まれています。これらのポートは主に内部通信用であるため、通常、ユーザーがアクセスできるようにする必要はありません。これらのポートをパブリックネットワークに公開すると、攻撃対象領域が拡大し、最小権限の原則に違反し、セキュリティ脆弱性のリスクが高まります。次の表は、TiDBクラスタのデフォルトのリスニングポートを示しています。 +TiDBのインストールには、デフォルトでコンポーネント間通信用の特権インターフェースがいくつか含まれています。これらのポートは主に内部通信用であるため、通常、ユーザーがアクセスできるようにする必要はありません。これらのポートをパブリックネットワークに公開すると、攻撃対象領域が拡大し、最小権限の原則に違反し、セキュリティ脆弱性のリスクが高まります。次の表は、TiDBクラスターのデフォルトのリスニングポートを示しています。 -| 成分 | デフォルトポート | プロトコル | +| コンポーネント | デフォルトポート | プロトコル | | --------------- | -------- | ---------- | | TiDB | 4000 | MySQL | | TiDB | 10080 | HTTP | diff --git a/best-practices/_index.md b/best-practices/_index.md index 95daa1595fa0a..26ee44bbd8b07 100644 --- a/best-practices/_index.md +++ b/best-practices/_index.md @@ -49,11 +49,11 @@ TiDBにおけるスキーマ設計のベストプラクティスを学びまし ## パフォーマンスチューニング {#performance-tuning} -TiKVやPDなどのTiDBコンポーネントのチューニング方法、および読み取り専用storageノードなどの機能を使用してさまざまなワークロード下でのパフォーマンスを向上させる方法を理解する。 +TiKVやPDなどのTiDBコンポーネントのチューニング方法、および読み取り専用ストレージノードなどの機能を使用してさまざまなワークロード下でのパフォーマンスを向上させる方法を理解する。 | ベストプラクティスのトピック | 説明 | | -------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | -| [SaaSマルチテナント環境で数百万のテーブルを処理する](/best-practices/saas-best-practices.md) | SaaS（Software as a Service）のマルチテナント環境、特に単一クラスタ内のテーブル数が100万を超えるようなシナリオにおいて、TiDBを使用するためのベストプラクティス。 | +| [SaaSマルチテナント環境で数百万のテーブルを処理する](/best-practices/saas-best-practices.md) | SaaS（Software as a Service）のマルチテナント環境、特に単一クラスター内のテーブル数が100万を超えるようなシナリオにおいて、TiDBを使用するためのベストプラクティス。 | | [高同時書き込みの処理](/best-practices/high-concurrency-best-practices.md) | TiDBにおいて、書き込み負荷の高い高並行ワークロードを処理し、書き込みホットスポットを回避してパフォーマンスを最適化するためのベストプラクティス。 | | [大規模リージョンを使用したTiKVパフォーマンスの調整](/best-practices/massive-regions-best-practices.md) | 数百万のリージョンを管理する際に、TiKVのパフォーマンスを最適化し、ハートビートのオーバーヘッドを削減するためのベストプラクティス。 | | [PDスケジューリングの調整](/best-practices/pd-scheduling-best-practices.md) | 負荷分散と障害リカバリの迅速化のためにPDポリシーを調整するためのベストプラクティス。 | diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md index 66681547af3fa..d7af2824aa095 100644 --- a/best-practices/best-practices-on-public-cloud.md +++ b/best-practices/best-practices-on-public-cloud.md @@ -8,17 +8,17 @@ aliases: ['/ja/tidb/stable/best-practices-on-public-cloud/'] パブリッククラウドインフラストラクチャは、TiDBの導入と管理においてますます人気の選択肢となっています。しかし、パブリッククラウドにTiDBを導入するには、パフォーマンスチューニング、コスト最適化、信頼性、スケーラビリティなど、いくつかの重要な要素を慎重に検討する必要があります。 -このドキュメントでは、KV RocksDB におけるコンパクション I/O フローの削減、 Raft Engine専用ディスクの使用、AZ 間トラフィックのコスト最適化、Google Cloud ライブマイグレーションイベントの軽減、大規模クラスタにおける PDサーバーの微調整など、パブリッククラウドへの TiDB の導入に関する様々な重要なベストプラクティスを解説します。これらのベストプラクティスに従うことで、パブリッククラウドにおける TiDB 導入のパフォーマンス、コスト効率、信頼性、スケーラビリティを最大限に高めることができます。 +このドキュメントでは、KV RocksDB におけるコンパクション I/O フローの削減、 Raft Engine専用ディスクの使用、AZ 間トラフィックのコスト最適化、Google Cloud ライブマイグレーションイベントの軽減、大規模クラスターにおける PDサーバーの微調整など、パブリッククラウドへの TiDB の導入に関する様々な重要なベストプラクティスを解説します。これらのベストプラクティスに従うことで、パブリッククラウドにおける TiDB 導入のパフォーマンス、コスト効率、信頼性、スケーラビリティを最大限に高めることができます。 ## KV RocksDB の圧縮 I/O フローを削減 {#reduce-compaction-i-o-flow-in-kv-rocksdb} -TiKVのstorageエンジンである[ロックスDB](https://rocksdb.org/) 、ユーザーデータの保存に使用されます。クラウドEBSのプロビジョニングされたIOスループットは通常、コスト上の理由から制限されているため、RocksDBは書き込み増幅率が高くなり、ディスクスループットがワークロードのボトルネックになる可能性があります。その結果、保留中のコンパクションバイトの総数は時間の経過とともに増加し、フロー制御がトリガーされます。これは、TiKVがフォアグラウンド書き込みフローに対応するための十分なディスク帯域幅を欠いていることを示しています。 +TiKVのストレージエンジンである[ロックスDB](https://rocksdb.org/) 、ユーザーデータの保存に使用されます。クラウドEBSのプロビジョニングされたIOスループットは通常、コスト上の理由から制限されているため、RocksDBは書き込み増幅率が高くなり、ディスクスループットがワークロードのボトルネックになる可能性があります。その結果、保留中のコンパクションバイトの総数は時間の経過とともに増加し、フロー制御がトリガーされます。これは、TiKVがフォアグラウンド書き込みフローに対応するための十分なディスク帯域幅を欠いていることを示しています。 -ディスクスループットの制限によるボトルネックを軽減するには、パフォーマンスを[タイタンを有効にする](#enable-titan)向上させることができます。平均行サイズが 512 バイト未満の場合は、Titan は適用できません。この場合、パフォーマンスを[すべての圧縮レベルを上げる](#increase-all-the-compression-levels)向上させることができます。 +ディスクスループットの制限によるボトルネックを軽減するには、パフォーマンスを[Titanを有効にする](#enable-titan)向上させることができます。平均行サイズが 512 バイト未満の場合は、Titan は適用できません。この場合、パフォーマンスを[すべての圧縮レベルを上げる](#increase-all-the-compression-levels)向上させることができます。 -### タイタンを有効にする {#enable-titan} +### Titanを有効にする {#enable-titan} -[タイタン](/storage-engine/titan-overview.md)は、キーと値の分離のための高性能な[ロックスDB](https://github.com/facebook/rocksdb)プラグインであり、大きな値が使用されるときに RocksDB での書き込み増幅を減らすことができます。 +[Titan](/ストレージ-engine/titan-overview.md)は、キーと値の分離のための高性能な[ロックスDB](https://github.com/facebook/rocksdb)プラグインであり、大きな値が使用されるときに RocksDB での書き込み増幅を減らすことができます。 平均行サイズが 512 バイトより大きい場合は、次のように`min-blob-size` `"512B"`または`"1KB"`に設定し、 `blob-file-compression`を`"zstd"`に設定して、Titan による圧縮 I/O フローの削減を有効にすることができます。 @@ -32,7 +32,7 @@ blob-file-compression = "zstd" > **注記：** > -> Titanを有効にすると、主キーの範囲スキャンのパフォーマンスが若干低下する可能性があります。詳細については、 [`min-blob-size`がパフォーマンスに与える影響](/storage-engine/titan-overview.md#impact-of-min-blob-size-on-performance)参照してください。 +> Titanを有効にすると、主キーの範囲スキャンのパフォーマンスが若干低下する可能性があります。詳細については、 [`min-blob-size`がパフォーマンスに与える影響](/ストレージ-engine/titan-overview.md#impact-of-min-blob-size-on-performance)参照してください。 ### すべての圧縮レベルを上げる {#increase-all-the-compression-levels} @@ -51,7 +51,7 @@ TiKVの[Raft Engine](/glossary.md#raft-engine) 、従来のデータベースに sdb 1649.00 209030.67 1293.33 304644.00 13.33 5.09 48.37 sdd 1033.00 4132.00 1141.33 31685.33 571.00 0.94 100.00 -デバイス`sdb`はKV RocksDBに使用され、 `sdd` Raft Engineのログを復元するために使用されます`sdd`には、デバイスの1秒あたりのフラッシュ要求完了数を表す`f/s`値が大幅に高いことに注目してください。Raft Raft Engineでは、バッチ内の書き込みが同期としてマークされている場合、バッチリーダーは書き込み後に`fdatasync()`呼び出し、バッファリングされたデータがstorageにフラッシュされることを保証します。Raft Raft Engine専用のディスクを使用することで、TiKVはリクエストの平均キュー長を短縮し、最適で安定した書き込みレイテンシーを保証します。 +デバイス`sdb`はKV RocksDBに使用され、 `sdd` Raft Engineのログを復元するために使用されます`sdd`には、デバイスの1秒あたりのフラッシュ要求完了数を表す`f/s`値が大幅に高いことに注目してください。Raft Raft Engineでは、バッチ内の書き込みが同期としてマークされている場合、バッチリーダーは書き込み後に`fdatasync()`呼び出し、バッファリングされたデータがストレージにフラッシュされることを保証します。Raft Raft Engine専用のディスクを使用することで、TiKVはリクエストの平均キュー長を短縮し、最適で安定した書き込みレイテンシーを保証します。 クラウドプロバイダーによって、IOPSやMBPSなどのパフォーマンス特性が異なる様々なディスクタイプが提供されています。そのため、ワークロードに応じて適切なクラウドプロバイダー、ディスクタイプ、ディスクサイズを選択することが重要です。 @@ -111,7 +111,7 @@ Azure 上のRaft Engineに専用の 32 GB [ウルトラディスク](https://lea ### 例 3: TiKV マニフェストのRaft Engine用に Google Cloud に専用の pd-ssd ディスクを接続する {#example-3-attach-a-dedicated-pd-ssd-disk-on-google-cloud-for-raft-engine-on-tikv-manifest} -次の TiKV 構成例は、 [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable)によってデプロイされた Google Cloud 上のクラスタに 512 GB の追加のディスク[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)を接続し、この特定のディスクにRaft Engineログを保存するように`raft-engine.dir`構成する方法を示しています。 +次の TiKV 構成例は、 [TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/stable)によってデプロイされた Google Cloud 上のクラスターに 512 GB の追加のディスク[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)を接続し、この特定のディスクにRaft Engineログを保存するように`raft-engine.dir`構成する方法を示しています。 tikv: config: | @@ -120,12 +120,12 @@ Azure 上のRaft Engineに専用の 32 GB [ウルトラディスク](https://lea enable = true enable-log-recycle = true requests: - storage: 4Ti - storageClassName: pd-ssd - storageVolumes: + ストレージ: 4Ti + ストレージClassName: pd-ssd + ストレージVolumes: - mountPath: /var/lib/raft-pv-ssd name: raft-pv-ssd - storageSize: 512Gi + ストレージSize: 512Gi ## AZ間ネットワークトラフィックのコストを最適化する {#optimize-cost-for-cross-az-network-traffic} @@ -137,9 +137,9 @@ TiFlash MPPタスクのデータシャッフルによって発生するネット ## Google Cloud でのライブ マイグレーション メンテナンス イベントを軽減する {#mitigate-live-migration-maintenance-events-on-google-cloud} -Google Cloud の[ライブマイグレーション機能](https://cloud.google.com/compute/docs/instances/live-migration-process)は、ダウンタイムを発生させることなく、ホスト間でVMをシームレスに移行できます。しかし、これらの移行イベントは頻度は低いものの、TiDBクラスタで実行されているVMを含むVMのパフォーマンスに重大な影響を与える可能性があります。このようなイベントが発生すると、影響を受けるVMのパフォーマンスが低下し、TiDBクラスタでのクエリ処理時間が長くなる可能性があります。 +Google Cloud の[ライブマイグレーション機能](https://cloud.google.com/compute/docs/instances/live-migration-process)は、ダウンタイムを発生させることなく、ホスト間でVMをシームレスに移行できます。しかし、これらの移行イベントは頻度は低いものの、TiDBクラスターで実行されているVMを含むVMのパフォーマンスに重大な影響を与える可能性があります。このようなイベントが発生すると、影響を受けるVMのパフォーマンスが低下し、TiDBクラスターでのクエリ処理時間が長くなる可能性があります。 -Google Cloud によって開始されたライブマイグレーション イベントを検出し、これらのイベントによるパフォーマンスへの影響を軽減するために、TiDB は Google のメタデータ[例](https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/compute/metadata/main.py)に基づく[スクリプトを見る](https://github.com/PingCAP-QE/tidb-google-maintenance)提供します。このスクリプトを TiDB、TiKV、PD ノードにデプロイして、メンテナンス イベントを検出できます。メンテナンス イベントが検出されると、中断を最小限に抑え、クラスタの動作を最適化するために、次のように適切なアクションが自動的に実行されます。 +Google Cloud によって開始されたライブマイグレーション イベントを検出し、これらのイベントによるパフォーマンスへの影響を軽減するために、TiDB は Google のメタデータ[例](https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/compute/metadata/main.py)に基づく[スクリプトを見る](https://github.com/PingCAP-QE/tidb-google-maintenance)提供します。このスクリプトを TiDB、TiKV、PD ノードにデプロイして、メンテナンス イベントを検出できます。メンテナンス イベントが検出されると、中断を最小限に抑え、クラスターの動作を最適化するために、次のように適切なアクションが自動的に実行されます。 - TiDB: TiDBノードをオフラインにし、TiDBポッドを削除します。これは、TiDBインスタンスのノードプールが自動スケールに設定され、TiDB専用になっていることを前提としています。ノード上で実行されている他のポッドに中断が発生する可能性があり、切断されたノードは自動スケーラーによって回収されることが想定されます。 - TiKV: メンテナンス中に、影響を受ける TiKV ストアのリーダーを削除します。 @@ -147,11 +147,11 @@ Google Cloud によって開始されたライブマイグレーション イベ この監視スクリプトは、Kubernetes 環境での TiDB の強化された管理機能を提供する[TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/v1.6/tidb-operator-overview)を使用してデプロイされた TiDB クラスター用に特別に設計されていることに注意することが重要です。 -監視スクリプトを活用し、メンテナンス イベント中に必要なアクションを実行することで、TiDB クラスタは Google Cloud 上のライブ マイグレーション イベントをより適切に処理し、クエリ処理と応答時間への影響を最小限に抑えながら、よりスムーズな操作を実現できます。 +監視スクリプトを活用し、メンテナンス イベント中に必要なアクションを実行することで、TiDB クラスターは Google Cloud 上のライブ マイグレーション イベントをより適切に処理し、クエリ処理と応答時間への影響を最小限に抑えながら、よりスムーズな操作を実現できます。 -## 高QPSの大規模TiDBクラスタのPDをチューニングする {#tune-pd-for-a-large-scale-tidb-cluster-with-high-qps} +## 高QPSの大規模TiDBクラスターのPDをチューニングする {#tune-pd-for-a-large-scale-tidb-cluster-with-high-qps} -TiDBクラスタでは、TSO（Timestamp Oracle）の提供やリクエストの処理といった重要なタスクを、単一のアクティブなPlacement Driver （PD）サーバーで処理します。しかし、単一のアクティブなPDサーバーに依存すると、TiDBクラスタのスケーラビリティが制限される可能性があります。 +TiDBクラスターでは、TSO（Timestamp Oracle）の提供やリクエストの処理といった重要なタスクを、単一のアクティブなPlacement Driver （PD）サーバーで処理します。しかし、単一のアクティブなPDサーバーに依存すると、TiDBクラスターのスケーラビリティが制限される可能性があります。 ### PD制限の症状 {#symptoms-of-pd-limitation} diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md index 39399f3e175fc..81972b3dd5e23 100644 --- a/best-practices/ddl-introduction.md +++ b/best-practices/ddl-introduction.md @@ -36,7 +36,7 @@ TiDBはオンラインDDLをサポートしています。つまり、データ ### TiDB DDLモジュール {#tidb-ddl-module} -TiDB DDLモジュールは、DDLオーナー（またはオーナー）の役割を導入します。これは、TiDBクラスタ内のすべてのDDL文を実行するプロキシとして機能します。現在の実装では、クラスタ全体から一度にオーナーとして選出できるTiDBノードは1つだけです。TiDBノードがオーナーとして選出されると、そのTiDBノードで起動されたワーカーがクラスタ内のDDLタスクを処理できるようになります。 +TiDB DDLモジュールは、DDLオーナー（またはオーナー）の役割を導入します。これは、TiDBクラスター内のすべてのDDL文を実行するプロキシとして機能します。現在の実装では、クラスター全体から一度にオーナーとして選出できるTiDBノードは1つだけです。TiDBノードがオーナーとして選出されると、そのTiDBノードで起動されたワーカーがクラスター内のDDLタスクを処理できるようになります。 TiDBは、etcdの選出メカニズムを用いて、複数のTiDBノードからオーナーをホストするノードを選出します。デフォルトでは、各TiDBノードがオーナーとして選出される可能性があります（選出へのノードの参加を管理するには、 `run-ddl`設定します）。選出されたオーナーノードには任期があり、更新することで積極的に任期を維持します。オーナーノードがダウンした場合、etcdを介して別のノードが新しいオーナーとして選出され、クラスター内でDDLタスクの実行を継続できます。 @@ -63,7 +63,7 @@ ADMIN SHOW DDL; TiDB DDL モジュールは設計当初からオンライン非同期変更モードを選択しており、これによりダウンタイムを経験することなくアプリケーションを変更できます。 -DDL変更は、ある状態から別の状態への遷移を伴い、通常は「変更前」の状態から「変更後」の状態へと遷移します。オンラインDDL変更では、この遷移は、相互に互換性のある複数の小さなバージョン状態を導入することによって発生します。DDL文の実行中、同じクラスタ内のTiDBノードは、変更オブジェクトの小さなバージョン間の差異が2バージョン以内であれば、異なる小さなバージョン変更を持つことができます。これは、隣接する小さなバージョンが相互に互換性を持つことができるためです。 +DDL変更は、ある状態から別の状態への遷移を伴い、通常は「変更前」の状態から「変更後」の状態へと遷移します。オンラインDDL変更では、この遷移は、相互に互換性のある複数の小さなバージョン状態を導入することによって発生します。DDL文の実行中、同じクラスター内のTiDBノードは、変更オブジェクトの小さなバージョン間の差異が2バージョン以内であれば、異なる小さなバージョン変更を持つことができます。これは、隣接する小さなバージョンが相互に互換性を持つことができるためです。 このように、複数の小さなバージョンを経ることで、複数のTiDBノード間でメタデータが正しく同期されます。これにより、プロセス中にデータの変更を伴うユーザートランザクションの正確性と一貫性が維持されます。 diff --git a/best-practices/grafana-monitor-best-practices.md b/best-practices/grafana-monitor-best-practices.md index 7dc410d137bd9..145361dc521fc 100644 --- a/best-practices/grafana-monitor-best-practices.md +++ b/best-practices/grafana-monitor-best-practices.md @@ -6,7 +6,7 @@ aliases: ['/ja/docs/dev/best-practices/grafana-monitor-best-practices/','/ja/doc # Grafana を使用した TiDB 監視のベストプラクティス {#best-practices-for-monitoring-tidb-using-grafana} -トポロジ構成にGrafanaとPrometheus [TiUPを使用してTiDBクラスタをデプロイする](/production-deployment-using-tiup.md)追加すると、TiDBクラスター内の様々なコンポーネントとマシンのメトリクスを収集・表示するために、 [Grafana + Prometheus 監視プラットフォーム](/tidb-monitoring-framework.md)のツールセットが同時にデプロイされます。このドキュメントでは、Grafanaを用いたTiDBの監視に関するベストプラクティスについて説明します。メトリクスを用いてTiDBクラスターの状態を分析し、問題を診断するのに役立つことを目的としています。 +トポロジ構成にGrafanaとPrometheus [TiUPを使用してTiDBクラスターをデプロイする](/production-deployment-using-tiup.md)追加すると、TiDBクラスター内の様々なコンポーネントとマシンのメトリクスを収集・表示するために、 [Grafana + Prometheus 監視プラットフォーム](/tidb-monitoring-framework.md)のツールセットが同時にデプロイされます。このドキュメントでは、Grafanaを用いたTiDBの監視に関するベストプラクティスについて説明します。メトリクスを用いてTiDBクラスターの状態を分析し、問題を診断するのに役立つことを目的としています。 ## 監視アーキテクチャ {#monitoring-architecture} @@ -24,7 +24,7 @@ TiDB 2.1.3以降のバージョンでは、TiDBモニタリングはプル方式 TiDBの3つのコアコンポーネント（TiDBサーバー、TiKVサーバー、PDサーバー）は、HTTPインターフェースを介してメトリクスを取得します。これらのメトリクスはプログラムコードから収集され、デフォルトのポートは次のとおりです。 -| 成分 | ポート | +| コンポーネント | ポート | | :------- | :---- | | TiDBサーバー | 10080 | | TiKVサーバー | 20180 | diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md index 17ca36481bab4..4e19f0c32384f 100644 --- a/best-practices/high-concurrency-best-practices.md +++ b/best-practices/high-concurrency-best-practices.md @@ -12,7 +12,7 @@ aliases: ['/ja/tidb/stable/high-concurrency-best-practices/','/ja/tidb/dev/high- このドキュメントは、読者がTiDBの基礎を理解していることを前提としています。まず、TiDBの基礎を解説した以下の3つのブログ記事と、 [TiDB ベストプラクティス](https://www.pingcap.com/blog/tidb-best-practice/)読みいただくことをお勧めします。 -- [データストレージ](https://www.pingcap.com/blog/tidb-internal-data-storage/) +- [データストレージ](https://www.pingcap.com/blog/tidb-internal-data-ストレージ/) - [コンピューティング](https://www.pingcap.com/blog/tidb-internal-computing/) - [スケジュール](https://www.pingcap.com/blog/tidb-internal-scheduling/) @@ -88,7 +88,7 @@ FROM 理論上、上記の操作はTiDBのベストプラクティスに準拠しているように見え、アプリケーションにホットスポットは発生しません。十分なマシン数があれば、TiDBの分散処理能力を最大限に活用できます。これが本当にベストプラクティスに準拠しているかどうかを検証するために、以下の実験的環境でテストを実施しました。 -クラスタトポロジーには、TiDBノード2台、PDノード3台、TiKVノード6台が配置されています。このテストはベンチマークではなく原理説明を目的としているため、QPSパフォーマンスは無視してください。 +クラスタートポロジーには、TiDBノード2台、PDノード3台、TiKVノード6台が配置されています。このテストはベンチマークではなく原理説明を目的としているため、QPSパフォーマンスは無視してください。 ![QPS1](/media/best-practices/QPS1.png) @@ -120,7 +120,7 @@ PD の監視メトリックでも、ホットスポットが発生したこと ![QPS5](/media/best-practices/QPS5.png) -一定期間の連続書き込みの後、PDはTiKVクラスタ全体の負荷が均等に分散される状態を自動的にスケジュールします。その時点で、クラスタ全体の容量を最大限に活用できるようになります。 +一定期間の連続書き込みの後、PDはTiKVクラスター全体の負荷が均等に分散される状態を自動的にスケジュールします。その時点で、クラスター全体の容量を最大限に活用できるようになります。 ほとんどの場合、ホットスポットが発生する上記のプロセスは正常であり、これはデータベースのリージョンウォームアップフェーズです。ただし、同時書き込みが集中するシナリオでは、このフェーズを回避する必要があります。 diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md index c8a33b0861b49..46e61154cfd6a 100644 --- a/best-practices/index-management-best-practices.md +++ b/best-practices/index-management-best-practices.md @@ -8,14 +8,14 @@ aliases: ['/ja/tidb/stable/index-management-best-practices/'] インデックスは、データベースクエリのパフォーマンスを最適化し、大量のデータのスキャンの必要性を減らすために不可欠です。しかし、アプリケーションの進化、ビジネスロジックの変化、データ量の増加に伴い、元のインデックス設計では以下のような問題が発生することがあります。 -- 未使用のインデックス: これらのインデックスはかつては関連していましたが、クエリ オプティマイザーによって選択されなくなり、storageを消費し、書き込み操作に不要なオーバーヘッドが追加されます。 +- 未使用のインデックス: これらのインデックスはかつては関連していましたが、クエリ オプティマイザーによって選択されなくなり、ストレージを消費し、書き込み操作に不要なオーバーヘッドが追加されます。 - 非効率的なインデックス: 一部のインデックスはオプティマイザーによって使用されますが、予想よりも多くのデータをスキャンするため、ディスク I/O が増加し、クエリのパフォーマンスが低下します。 -これらのインデックス作成の問題を放置すると、storageコストの増加、パフォーマンスの低下、運用効率の低下につながる可能性があります。TiDBのような分散SQLデータベースでは、分散クエリの規模と複数ノード間の調整の複雑さにより、インデックス作成の非効率性の影響はさらに大きくなります。そのため、データベースを最適化した状態に保つには、定期的なインデックス監査が不可欠です。 +これらのインデックス作成の問題を放置すると、ストレージコストの増加、パフォーマンスの低下、運用効率の低下につながる可能性があります。TiDBのような分散SQLデータベースでは、分散クエリの規模と複数ノード間の調整の複雑さにより、インデックス作成の非効率性の影響はさらに大きくなります。そのため、データベースを最適化した状態に保つには、定期的なインデックス監査が不可欠です。 インデックスを積極的に識別して最適化すると、次のことが可能になります。 -- storageのオーバーヘッドを削減: 未使用のインデックスを削除すると、ディスク領域が解放され、長期的なstorageコストが削減されます。 +- ストレージのオーバーヘッドを削減: 未使用のインデックスを削除すると、ディスク領域が解放され、長期的なストレージコストが削減されます。 - 書き込みパフォーマンスの向上: 不要なインデックスメンテナンスが排除されると、書き込みが多いワークロード ( `INSERT` 、 `UPDATE` 、 `DELETE`など) のパフォーマンスが向上します。 - クエリ実行の最適化: 効率的なインデックスによりスキャンされる行数が削減され、クエリ速度と応答時​​間が向上します。 - データベース管理を合理化します。インデックスが少なく、適切に最適化されているため、バックアップ、リカバリ、スキーマの変更が簡素化されます。 @@ -159,7 +159,7 @@ ORDER BY total_queries DESC; パフォーマンスへの影響を最小限に抑えるため、 `CLUSTER_TIDB_INDEX_USAGE`即座に更新されません。インデックス使用状況の指標は最大 5 分ほど遅延する場合があります。クエリを分析する際は、このレイテンシーにご注意ください。 -- メモリベースのstorage +- メモリベースのストレージ `TIDB_INDEX_USAGE`と同様に、このシステムテーブルはノードの再起動後にデータを保持しません。ノードがダウンした場合、記録されたインデックス使用状況データは失われます。 @@ -171,7 +171,7 @@ ORDER BY total_queries DESC; これにより、次の操作を簡単に実行できるようになります。 -- 使用されなくなったインデックスを識別し、不要なstorageコストを削減します。 +- 使用されなくなったインデックスを識別し、不要なストレージコストを削減します。 - `INSERT` 、 `UPDATE` 、 `DELETE`クエリにオーバーヘッドを追加するインデックスを削除することで、DML 操作を高速化します。 - クエリ パターンを手動で分析する必要なく、インデックス監査を合理化します。 @@ -236,7 +236,7 @@ SELECT * FROM sys.schema_unused_indexes; 非表示インデックスの主な利点は次のとおりです。 - **安全なインデックステスト**：クエリはインデックスを使用しなくなりますが、関連するオプティマイザ統計は引き続き維持されます。必要に応じていつでも簡単に復元できます。 -- **インデックスstorageの中断はゼロ**: インデックスはそのまま残るため、コストのかかる再作成は不要です。 +- **インデックスストレージの中断はゼロ**: インデックスはそのまま残るため、コストのかかる再作成は不要です。 - **パフォーマンス監視**: DBA は、最終決定を下す前に、インデックスなしでクエリの動作を観察できます。 ### インデックスを非表示にする {#make-an-index-invisible} @@ -284,7 +284,7 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; 3. **既存のインデックスを最適化します。** - - 冗長なインデックスを統合することで、storageのオーバーヘッドを削減し、書き込みパフォーマンスを向上させることができます。複数のインデックスが類似したクエリを処理している場合は、それらを単一の、より効率的なインデックスに統合することを検討してください。 + - 冗長なインデックスを統合することで、ストレージのオーバーヘッドを削減し、書き込みパフォーマンスを向上させることができます。複数のインデックスが類似したクエリを処理している場合は、それらを単一の、より効率的なインデックスに統合することを検討してください。 - 重複するプレフィックスを持つインデックス (冗長性を示している可能性があります) を検索するには、次の SQL ステートメントを実行します。 @@ -315,4 +315,4 @@ ALTER TABLE bookshop.users ALTER INDEX nickname INVISIBLE; - TiDB の実行プラン分析ツールを使用して、インデックスが最適に使用されているかどうかを確認します。 - 新しいインデックスを追加するときは、予期しない回帰を防ぐために、まず分離された環境でテストしてください。 -これらのベスト プラクティスに従うことで、効率的なクエリ実行を実現し、不要なstorageオーバーヘッドを削減し、最適なデータベース パフォーマンスを維持できます。 +これらのベスト プラクティスに従うことで、効率的なクエリ実行を実現し、不要なストレージオーバーヘッドを削減し、最適なデータベース パフォーマンスを維持できます。 diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md index 2e5e85012c950..01ac14c8795b6 100644 --- a/best-practices/massive-regions-best-practices.md +++ b/best-practices/massive-regions-best-practices.md @@ -20,7 +20,7 @@ TiKVインスタンスには複数のリージョンが存在します。Raftsto > > この図はRaftstoreのワークフローを示すものであり、実際のコード構造を表すものではありません。 -上の図から、TiDB サーバーからのリクエストは、gRPC モジュールとstorageモジュールを通過した後、KV (キーと値のペア) の読み取りおよび書き込みメッセージになり、対応するリージョンに送信されることがわかります。これらのメッセージはすぐに処理されず、一時的に保存されます。Raftstoreは、各リージョンに処理するメッセージがあるかどうかをポーリングして確認します。リージョンに処理するメッセージがある場合、 Raftstore はこのリージョンのRaftステート マシンを駆動してこれらのメッセージを処理し、これらのメッセージの状態変化に応じて後続の操作を実行します。たとえば、書き込みリクエストが到着すると、 Raftステート マシンはログをディスクに保存し、他のリージョンのレプリカにログを送信します。ハートビート間隔に達すると、 Raftステート マシンはハートビート情報を他のリージョンのレプリカに送信します。 +上の図から、TiDB サーバーからのリクエストは、gRPC モジュールとストレージモジュールを通過した後、KV (キーと値のペア) の読み取りおよび書き込みメッセージになり、対応するリージョンに送信されることがわかります。これらのメッセージはすぐに処理されず、一時的に保存されます。Raftstoreは、各リージョンに処理するメッセージがあるかどうかをポーリングして確認します。リージョンに処理するメッセージがある場合、 Raftstore はこのリージョンのRaftステート マシンを駆動してこれらのメッセージを処理し、これらのメッセージの状態変化に応じて後続の操作を実行します。たとえば、書き込みリクエストが到着すると、 Raftステート マシンはログをディスクに保存し、他のリージョンのレプリカにログを送信します。ハートビート間隔に達すると、 Raftステート マシンはハートビート情報を他のリージョンのレプリカに送信します。 ## パフォーマンスの問題 {#performance-problem} @@ -152,7 +152,7 @@ TiKVノード間のRaft通信に使用される最大接続数を調整するに PDは、PDLeaderノードの切り替え後、迅速にリージョンルーティングサービスを再開できるように、etcdにリージョンメタ情報を保持する必要があります。リージョン数が増えると、etcdのパフォーマンス問題が発生し、PDがリーダーLeaderを切り替える際に、etcdからリージョンメタ情報を取得するのに時間がかかります。数百万のリージョンが存在する場合、etcdからメタ情報を取得するのに10秒以上、場合によっては数十秒かかることがあります。 -この問題に対処するため、TiDB v3.0以降、PDではデフォルトで`use-region-storage`有効になっています。この機能を有効にすると、PDはリージョンメタ情報をローカルLevelDBに保存し、他のメカニズムを通じてPDノード間で情報を同期します。 +この問題に対処するため、TiDB v3.0以降、PDではデフォルトで`use-region-ストレージ`有効になっています。この機能を有効にすると、PDはリージョンメタ情報をローカルLevelDBに保存し、他のメカニズムを通じてPDノード間で情報を同期します。 ### PDルーティング情報が時間内に更新されない {#pd-routing-information-is-not-updated-in-time} diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md index 4608c9f8a4a84..2cc8f72ff6069 100644 --- a/best-practices/pd-scheduling-best-practices.md +++ b/best-practices/pd-scheduling-best-practices.md @@ -8,7 +8,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ このドキュメントでは、PDスケジューリングの原則と戦略を、一般的なシナリオを通して詳細に解説し、アプリケーション開発の効率化を図ります。このドキュメントは、TiDB、TiKV、PDの基本的な知識と、以下のコアコンセプトを理解していることを前提としています。 -- [リーダー/フォロワー/学習者](/glossary.md#leaderfollowerlearner) +- [リーダー/フォロワー/ラーナー](/glossary.md#leaderfollowerlearner) - [オペレーター](/glossary.md#operator) - [演算子ステップ](/glossary.md#operator-step) - [保留中/ダウン](/glossary.md#pendingdown) @@ -33,7 +33,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ 各 TiKV ノードは、次の 2 種類のハートビートを定期的に PD に報告します。 - - `StoreHeartbeat` : ディスク容量、使用可能なstorage、読み取り/書き込みトラフィックなど、ストアの全体的な情報が含まれます。 + - `StoreHeartbeat` : ディスク容量、使用可能なストレージ、読み取り/書き込みトラフィックなど、ストアの全体的な情報が含まれます。 - `RegionHeartbeat` : 各リージョンの範囲、ピア分布、ピアステータス、データ量、読み取り/書き込みトラフィックなど、リージョンの全体的な情報が含まれます。 PD はスケジュール決定のためにこの情報を収集し、復元します。 @@ -61,17 +61,17 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ ### 負荷分散 {#load-balancing} -リージョンは、負荷分散を実現するために、主にスケジューラ`balance-leader`と`balance-region`に依存しています。どちらのスケジューラも、クラスター内のすべてのストアにリージョンを均等に分散させることを目標としていますが、それぞれの重点は異なります。スケジューラ`balance-leader`はリージョンリーダーと連携してクライアントからの受信リクエストのバランスを取り、スケジューラ`balance-region`は各リージョンピアと連携してstorageの負荷を再分配し、storage容量不足などの例外を回避します。 +リージョンは、負荷分散を実現するために、主にスケジューラ`balance-leader`と`balance-region`に依存しています。どちらのスケジューラも、クラスター内のすべてのストアにリージョンを均等に分散させることを目標としていますが、それぞれの重点は異なります。スケジューラ`balance-leader`はリージョンリーダーと連携してクライアントからの受信リクエストのバランスを取り、スケジューラ`balance-region`は各リージョンピアと連携してストレージの負荷を再分配し、ストレージ容量不足などの例外を回避します。 `balance-leader`と`balance-region`は同様のスケジュール プロセスを共有します。 1. リソースの可用性に応じて店舗を評価します。 2. `balance-leader`または`balance-region` 、高スコアの店舗から低スコアの店舗へ、リーダーまたは同僚を継続的に異動させます。 -しかし、評価方法は異なります。1 `balance-leader`ストア内のリーダーに対応するすべての領域サイズの合計を使用しますが、 `balance-region`の方法は比較的複雑です。各ノードの具体的なstorage容量に応じて、 `balance-region`の評価方法は以下のようになります。 +しかし、評価方法は異なります。1 `balance-leader`ストア内のリーダーに対応するすべての領域サイズの合計を使用しますが、 `balance-region`の方法は比較的複雑です。各ノードの具体的なストレージ容量に応じて、 `balance-region`の評価方法は以下のようになります。 -- 十分なstorageがある場合のデータ量に基づいて（ノード間でデータ分散のバランスをとるため）。 -- storageが不足している場合は、使用可能なstorageに基づいて割り当てます (異なるノード上のstorageの可用性のバランスをとるため)。 +- 十分なストレージがある場合のデータ量に基づいて（ノード間でデータ分散のバランスをとるため）。 +- ストレージが不足している場合は、使用可能なストレージに基づいて割り当てます (異なるノード上のストレージの可用性のバランスをとるため)。 - どちらの状況も当てはまらない場合は、上記の 2 つの要素の加重合計に基づきます。 ノードによってパフォーマンスが異なる場合があるため、ストアごとにロードバランシングの重みを設定することもできます。1と`region-weight` `leader-weight`それぞれリーダー重みとリージョン重みを制御します（どちらもデフォルトは「1」です）。例えば、あるストアの`leader-weight` 「2」に設定すると、スケジューリングが安定した後、そのノードのリーダー数は他のノードの約2倍になります。同様に、あるストアの`leader-weight` 「0.5」に設定すると、そのノードのリーダー数は他のノードの約半分になります。 @@ -86,9 +86,9 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ ホット書き込み領域の場合、 `hot-region-scheduler`領域ピアとリーダーの両方の再配布を試行します。ホット読み取り領域の場合、 `hot-region-scheduler`領域リーダーのみを再配布します。 -### クラスタトポロジの認識 {#cluster-topology-awareness} +### クラスタートポロジの認識 {#cluster-topology-awareness} -クラスタトポロジーの認識により、PDはリージョンのレプリカを可能な限り分散させることができます。これにより、TiKVは高可用性と災害復旧能力を確保します。PDはバックグラウンドですべてのリージョンを継続的にスキャンします。リージョンの分散が最適ではないと判断された場合、PDはピアを置き換えてリージョンを再分散するためのオペレーターを生成します。 +クラスタートポロジーの認識により、PDはリージョンのレプリカを可能な限り分散させることができます。これにより、TiKVは高可用性と災害復旧能力を確保します。PDはバックグラウンドですべてのリージョンを継続的にスキャンします。リージョンの分散が最適ではないと判断された場合、PDはピアを置き換えてリージョンを再分散するためのオペレーターを生成します。 リージョン分散をチェックするコンポーネントは`replicaChecker`です。これは、無効にできないことを除いてスケジューラに似ています。 `replicaChecker` `location-labels`の設定に基づいてスケジュールします。たとえば、 `[zone,rack,host]`クラスターの 3 層トポロジを定義します。PD は、最初にリージョン ピアを異なるゾーンにスケジュールしようとします。ゾーンが不十分な場合は (たとえば、レプリカ 3 つに対してゾーン 2 つ)、またはラックが不十分な場合は異なるホストにスケジュールしようとします。 @@ -131,7 +131,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/ - 店舗リーダー/地域スコア: 各店舗のスコア - 店舗リーダー/地域数: 各店舗のリーダー/地域の数 -- 利用可能な店舗: 各店舗で利用可能なstorage +- 利用可能な店舗: 各店舗で利用可能なストレージ pd-ctl のストア コマンドを使用して、各ストアの残高ステータスを照会できます。 @@ -152,7 +152,7 @@ pd-ctl のストア コマンドを使用して、各ストアの残高ステー ### リージョンの健康 {#region-health} -**Grafana PD/クラスタ/リージョンのヘルス**パネルには、異常な状態にあるリージョンに関するメトリックが表示されます。 +**Grafana PD/クラスター/リージョンのヘルス**パネルには、異常な状態にあるリージョンに関するメトリックが表示されます。 領域チェック コマンドを使用して pd-ctl を使用すると、異常状態にある領域のリストを照会できます。 @@ -198,7 +198,7 @@ pd-ctl の`config show`コマンドを使用してスケジュール設定を確 ### リーダー/地域が均等に分布していない {#leaders-regions-are-not-evenly-distributed} -PDの評価メカニズムでは、異なるストアのリーダー数とリージョン数だけでは負荷分散状況を完全に反映できないと判断されます。そのため、TiKVの実際の負荷やstorage使用量から、負荷の不均衡が発生しているかどうかを確認する必要があります。 +PDの評価メカニズムでは、異なるストアのリーダー数とリージョン数だけでは負荷分散状況を完全に反映できないと判断されます。そのため、TiKVの実際の負荷やストレージ使用量から、負荷の不均衡が発生しているかどうかを確認する必要があります。 リーダー/地域が均等に分散されていないことを確認したら、さまざまなストアの評価を確認する必要があります。 @@ -221,7 +221,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー - スケジューラが有効化されていません。例えば、対応するスケジューラが削除されているか、制限が「​​0」に設定されている可能性があります。 - その他の制約。例えば、システム内の制約`evict-leader-scheduler`により、リーダーが対応するストアに移行できない、あるいはラベルプロパティが設定されているため、一部のストアがリーダーを拒否するといった状況です。 - - クラスタトポロジによる制約。例えば、3つのデータセンターにまたがる3つのレプリカを持つクラスタでは、レプリカ分離のため、各リージョンの3つのレプリカが異なるデータセンターに分散されます。これらのデータセンター間でストア数が異なる場合、スケジューリングは各データセンター内ではバランスの取れた状態になりますが、グローバルではバランスが取れません。 + - クラスタートポロジによる制約。例えば、3つのデータセンターにまたがる3つのレプリカを持つクラスターでは、レプリカ分離のため、各リージョンの3つのレプリカが異なるデータセンターに分散されます。これらのデータセンター間でストア数が異なる場合、スケジューリングは各データセンター内ではバランスの取れた状態になりますが、グローバルではバランスが取れません。 ### ノードをオフラインにするのは遅い {#taking-nodes-offline-is-slow} @@ -236,7 +236,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー 対応する演算子の生成に失敗した場合、考えられる理由は次のとおりです。 - オペレータが停止しているか、 `replica-schedule-limit` "0" に設定されます。 -- リージョン移行に適したノードが存在しません。例えば、同じラベルの置き換えノードの利用可能な容量が20%未満の場合、PDはそのノードのstorage不足を回避するためにスケジューリングを停止します。このような場合は、ノードを追加するか、データを削除してスペースを解放する必要があります。 +- リージョン移行に適したノードが存在しません。例えば、同じラベルの置き換えノードの利用可能な容量が20%未満の場合、PDはそのノードのストレージ不足を回避するためにスケジューリングを停止します。このような場合は、ノードを追加するか、データを削除してスペースを解放する必要があります。 ### ノードをオンラインにするのは遅い {#bringing-nodes-online-is-slow} diff --git a/best-practices/readonly-nodes.md b/best-practices/readonly-nodes.md index 810917b6a240a..23db56900b32c 100644 --- a/best-practices/readonly-nodes.md +++ b/best-practices/readonly-nodes.md @@ -1,12 +1,12 @@ --- title: Best Practices for Read-Only Storage Nodes -summary: このドキュメントでは、オンラインサービスから高許容遅延負荷を分離するための読み取り専用storageノードの設定方法を紹介します。手順としては、TiKVノードを読み取り専用としてマークし、配置ルールを使用して読み取り専用ノードに学習者としてデータを保存し、Follower Readを使用して読み取り専用ノードからデータを読み取ることが含まれます。 +summary: このドキュメントでは、オンラインサービスから高許容遅延負荷を分離するための読み取り専用ストレージノードの設定方法を紹介します。手順としては、TiKVノードを読み取り専用としてマークし、配置ルールを使用して読み取り専用ノードにラーナーとしてデータを保存し、Follower Readを使用して読み取り専用ノードからデータを読み取ることが含まれます。 aliases: ['/ja/tidb/stable/readonly-nodes/','/ja/tidb/dev/readonly-nodes/'] --- -# 読み取り専用ストレージノードのベストプラクティス {#best-practices-for-read-only-storage-nodes} +# 読み取り専用ストレージノードのベストプラクティス {#best-practices-for-read-only-ストレージ-nodes} -このドキュメントでは、読み取り専用storageノードの設定方法と、バックアップ、分析、テストなどのトラフィックをこれらのノードに誘導する方法を紹介します。これにより、遅延許容度の高い負荷を重要なオンラインサービスから物理的に分離できます。 +このドキュメントでは、読み取り専用ストレージノードの設定方法と、バックアップ、分析、テストなどのトラフィックをこれらのノードに誘導する方法を紹介します。これにより、遅延許容度の高い負荷を重要なオンラインサービスから物理的に分離できます。 ## 手順 {#procedures} @@ -22,7 +22,7 @@ aliases: ['/ja/tidb/stable/readonly-nodes/','/ja/tidb/dev/readonly-nodes/'] labels: $mode: readonly -### 2. 配置ルールを使用して、学習者として読み取り専用ノードにデータを保存する {#2-use-placement-rules-to-store-data-on-read-only-nodes-as-learners} +### 2. 配置ルールを使用して、ラーナーとして読み取り専用ノードにデータを保存する {#2-use-placement-rules-to-store-data-on-read-only-nodes-as-learners} 1. `pd-ctl config placement-rules`コマンドを実行して、デフォルトの配置ルールをエクスポートします。 @@ -52,7 +52,7 @@ aliases: ['/ja/tidb/stable/readonly-nodes/','/ja/tidb/dev/readonly-nodes/'] ] ``` -2. すべてのデータを学習者として読み取り専用ノードに保存します。以下の例はデフォルトの設定に基づいています。 +2. すべてのデータをラーナーとして読み取り専用ノードに保存します。以下の例はデフォルトの設定に基づいています。 ```json [ @@ -101,7 +101,7 @@ aliases: ['/ja/tidb/stable/readonly-nodes/','/ja/tidb/dev/readonly-nodes/'] > **注記：** > > - 大規模なデータセットを持つクラスターで上記の操作を実行すると、クラスター全体のデータが読み取り専用ノードに完全に複製されるまでに時間がかかる場合があります。この間、読み取り専用ノードはサービスを提供できない可能性があります。 -> - バックアップの特別な実装のため、各ラベルの学習者数は 1 を超えることはできません。そうでない場合、バックアップ中に重複データが生成されます。 +> - バックアップの特別な実装のため、各ラベルのラーナー数は 1 を超えることはできません。そうでない場合、バックアップ中に重複データが生成されます。 ### 3. Follower Readを使用して読み取り専用ノードからデータを読み取る {#3-use-follower-read-to-read-data-from-read-only-nodes} diff --git a/best-practices/three-dc-local-read.md b/best-practices/three-dc-local-read.md index 835772ab766cc..0a90ef216b48e 100644 --- a/best-practices/three-dc-local-read.md +++ b/best-practices/three-dc-local-read.md @@ -6,13 +6,13 @@ aliases: ['/ja/tidb/stable/three-dc-local-read/'] # 3つのデータセンター展開におけるローカル読み取りのベストプラクティス {#best-practices-for-local-reads-in-three-data-center-deployments} -3つのデータセンターモデルでは、リージョンには各データセンターに分離された3つのレプリカが存在します。しかし、強力な整合性のある読み取りが求められるため、TiDBはすべてのクエリにおいて、対応するデータのLeaderレプリカにアクセスする必要があります。クエリがLeaderレプリカとは異なるデータセンターで生成された場合、TiDBは別のデータセンターからデータを読み取る必要があり、アクセスレイテンシーが増加します。 +3つのデータセンターモデルでは、リージョンには各データセンターに分離された3つのレプリカが存在します。しかし、強力な整合性のある読み取りが求められるため、TiDBはすべてのクエリにおいて、対応するデータのリーダーレプリカにアクセスする必要があります。クエリがリーダーレプリカとは異なるデータセンターで生成された場合、TiDBは別のデータセンターからデータを読み取る必要があり、アクセスレイテンシーが増加します。 このドキュメントでは、 [ステイル読み取り](/stale-read.md)機能を使用して、センター間アクセスを回避し、リアルタイムのデータ可用性を犠牲にしてアクセスのレイテンシーを減らす方法について説明します。 -## 3つのデータセンターのTiDBクラスタをデプロイ {#deploy-a-tidb-cluster-of-three-data-centers} +## 3つのデータセンターのTiDBクラスターをデプロイ {#deploy-a-tidb-cluster-of-three-data-centers} -3 つのデータセンターの展開方法については、 [1 つの地域展開における複数のデータセンター](/multi-data-centers-in-one-city-deployment.md)を参照してください。 +3 つのデータセンターの展開方法については、 [1 つの地域に配置された複数のデータセンター](/multi-data-centers-in-one-city-deployment.md)を参照してください。 TiKVノードとTiDBノードの両方に構成項目`labels`設定されている場合、同じデータセンター内のTiKVノードとTiDBノードのラベル`zone`の値は同一である必要があります。例えば、TiKVノードとTiDBノードの両方がデータセンター`dc-1`にある場合、2つのノードに以下のラベルを設定する必要があります。 @@ -21,7 +21,7 @@ TiKVノードとTiDBノードの両方に構成項目`labels`設定されてい ## ステイル読み取りを使用してローカル読み取りを実行する {#perform-local-read-using-stale-read} -[ステイル読み取り](/stale-read.md)は、TiDBがユーザーに履歴データ読み取りのために提供するメカニズムです。このメカニズムを使用することで、特定の時点または指定された時間範囲内の対応する履歴データを読み取ることができ、storageノード間のデータ複製によって生じるレイテンシーを削減できます。地理的に分散されたデプロイメントの一部のシナリオでステイル読み取りを使用する場合、TiDBはリアルタイムパフォーマンスを犠牲にして現在のデータセンター内のレプリカにアクセスし、対応するデータを読み取ります。これにより、センター間接続によって生じるネットワークレイテンシーを回避し、クエリプロセス全体のアクセスレイテンシーを削減します。 +[ステイル読み取り](/stale-read.md)は、TiDBがユーザーに履歴データ読み取りのために提供するメカニズムです。このメカニズムを使用することで、特定の時点または指定された時間範囲内の対応する履歴データを読み取ることができ、ストレージノード間のデータ複製によって生じるレイテンシーを削減できます。地理的に分散されたデプロイメントの一部のシナリオでステイル読み取りを使用する場合、TiDBはリアルタイムパフォーマンスを犠牲にして現在のデータセンター内のレプリカにアクセスし、対応するデータを読み取ります。これにより、センター間接続によって生じるネットワークレイテンシーを回避し、クエリプロセス全体のアクセスレイテンシーを削減します。 TiDB がステイル読み取りクエリを受信すると、その TiDB ノードの`zone`ラベルが設定されていて、 [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)が`closest-replicas`に設定されている場合、TiDB は対応するデータ レプリカが存在する同じ`zone`ラベルを持つ TiKV ノードに要求を送信します。 diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md index bbdbb1cc321ab..3dc731ade4ca5 100644 --- a/best-practices/three-nodes-hybrid-deployment.md +++ b/best-practices/three-nodes-hybrid-deployment.md @@ -1,6 +1,6 @@ --- title: Best Practices for Three-Node Hybrid Deployment -summary: TiDBクラスタは、3台のマシンでコスト効率よく導入できます。このハイブリッド導入におけるベストプラクティスとしては、安定性とパフォーマンスを向上させるためのパラメータ調整が挙げられます。リソース消費量の制限とスレッドプールサイズの調整は、クラスタを最適化する上で重要です。TiKVバックグラウンドタスクとTiDB実行オペレータのパラメータ調整も重要です。 +summary: TiDBクラスターは、3台のマシンでコスト効率よく導入できます。このハイブリッド導入におけるベストプラクティスとしては、安定性とパフォーマンスを向上させるためのパラメータ調整が挙げられます。リソース消費量の制限とスレッドプールサイズの調整は、クラスターを最適化する上で重要です。TiKVバックグラウンドタスクとTiDB実行オペレータのパラメータ調整も重要です。 aliases: ['/ja/tidb/stable/three-nodes-hybrid-deployment/'] --- @@ -36,7 +36,7 @@ PDとTiKVはどちらもディスク上に情報を保存するため、ディ tikv: readpool.unified.max-thread-count: 6 server.grpc-concurrency: 2 - storage.scheduler-worker-pool-size: 2 + ストレージ.scheduler-worker-pool-size: 2 gc.max-write-bytes-per-sec: 300K rocksdb.max-background-jobs: 3 rocksdb.max-sub-compactions: 1 @@ -48,7 +48,7 @@ tikv: 次のセクションでは、これらのパラメータの意味と調整方法を紹介します。 -### TiKVスレッドプールサイズのコンフィグレーション {#configuration-of-tikv-thread-pool-size} +### TiKVスレッドプールサイズの設定 {#configuration-of-tikv-thread-pool-size} このセクションでは、フォアグラウンドアプリケーションのスレッドプールのリソース割り当てに関連するパラメータを調整するためのベストプラクティスを紹介します。これらのスレッドプールサイズを縮小するとパフォーマンスが低下しますが、リソースが限られているハイブリッド展開シナリオでは、クラスター自体で高いパフォーマンスを達成することは困難です。このシナリオでは、パフォーマンスよりもクラスター全体の安定性が優先されます。 @@ -66,11 +66,11 @@ tikv: ![gRPC Pool CPU](/media/best-practices/three-nodes-grpc-pool-usage.png) -#### storage.scheduler-worker-pool-size {#code-storage-scheduler-worker-pool-size-code} +#### ストレージ.scheduler-worker-pool-size {#code-ストレージ-scheduler-worker-pool-size-code} TiKVがマシンのCPUコア数が`16`以上であることを検出すると、このパラメータ値はデフォルトで`8`に設定されます。CPUコア数が`16`未満の場合、このパラメータ値はデフォルトで`4`に設定されます。このパラメータは、TiKVが複雑なトランザクション要求を単純なキー値の読み取りまたは書き込みに変換するものの、スケジューラスレッドプールが書き込みを実行しない場合に使用されます。 -理想的には、スケジューラスレッドプールの使用率は50%～75%に維持されます。gRPCスレッドプールと同様に、ハイブリッド展開中はパラメータ`storage.scheduler-worker-pool-size`がデフォルトで大きな値に設定されるため、リソースの使用量が不足します。このテストでは、このパラメータの値はベストプラクティスに沿って`2`に設定されており、これは**スケジューラワーカーCPU**パネルの対応するメトリックを観察した結果に基づいています。 +理想的には、スケジューラスレッドプールの使用率は50%～75%に維持されます。gRPCスレッドプールと同様に、ハイブリッド展開中はパラメータ`ストレージ.scheduler-worker-pool-size`がデフォルトで大きな値に設定されるため、リソースの使用量が不足します。このテストでは、このパラメータの値はベストプラクティスに沿って`2`に設定されており、これは**スケジューラワーカーCPU**パネルの対応するメトリックを観察した結果に基づいています。 ![Scheduler Worker CPU](/media/best-practices/three-nodes-scheduler-pool-usage.png) diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index 8933ecff4ae0f..b21fd0da94f2e 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -10,7 +10,7 @@ aliases: ['/ja/docs/dev/tidb-best-practices/','/ja/tidb/stable/tidb-best-practic このドキュメントを読む前に、TiDB の技術的原理を紹介する次の 3 つのブログ投稿を読むことをお勧めします。 -- [TiDB 内部 (I) - データストレージ](https://www.pingcap.com/blog/tidb-internal-data-storage/) +- [TiDB 内部 (I) - データストレージ](https://www.pingcap.com/blog/tidb-internal-data-ストレージ/) - [TiDB 内部 (II) - コンピューティング](https://www.pingcap.com/blog/tidb-internal-computing/) - [TiDB内部（III） - スケジューリング](https://www.pingcap.com/blog/tidb-internal-scheduling/) @@ -18,7 +18,7 @@ aliases: ['/ja/docs/dev/tidb-best-practices/','/ja/tidb/stable/tidb-best-practic データベースは汎用的なインフラストラクチャシステムです。開発プロセスにおいては、様々なユーザーシナリオを考慮し、具体的なビジネスシナリオにおける実際の状況に応じて、データのパラメータや利用方法を調整することが重要です。 -TiDBは、MySQLのプロトコルと構文と互換性のある分散データベースです。ただし、内部実装と分散storageおよびトランザクションのサポートにより、TiDBの使用方法はMySQLとは異なります。 +TiDBは、MySQLのプロトコルと構文と互換性のある分散データベースです。ただし、内部実装と分散ストレージおよびトランザクションのサポートにより、TiDBの使用方法はMySQLとは異なります。 ## 基本概念 {#basic-concepts} @@ -36,7 +36,7 @@ Raftは、強力な一貫性を備えたデータ複製を保証するコンセ TiDBは完全な分散トランザクションを提供し、そのモデルは[Google パーコレーター](https://research.google/pubs/large-scale-incremental-processing-using-distributed-transactions-and-notifications/)に基づいていくつかの最適化が施されています。このドキュメントでは、以下の機能を紹介します。 -- 楽観的取引モデル +- 楽観的トランザクションモデル TiDBの楽観的トランザクションモデルは、コミットフェーズまで競合を検出しません。競合が発生した場合、トランザクションは再試行する必要があります。しかし、競合が深刻な場合、再試行前の操作は無効となり、再度実行する必要があるため、このモデルは非効率的です。 @@ -87,7 +87,7 @@ MySQLで培った豊富な経験はTiDBにも活かすことができます。Ti - セカンダリインデックスが多ければ多いほど良いのでしょうか? - セカンダリインデックスはクエリを高速化できますが、インデックスを追加すると副作用があります。前のセクションでは、インデックスのstorageモデルについて説明しました。追加したインデックスごとに、行を挿入する際にKey-Valueが1つ増えます。そのため、インデックスの数が増えるほど、書き込み速度が遅くなり、必要なスペースも増えます。 + セカンダリインデックスはクエリを高速化できますが、インデックスを追加すると副作用があります。前のセクションでは、インデックスのストレージモデルについて説明しました。追加したインデックスごとに、行を挿入する際にKey-Valueが1つ増えます。そのため、インデックスの数が増えるほど、書き込み速度が遅くなり、必要なスペースも増えます。 さらに、インデックスが多すぎるとオプティマイザの実行時間に影響し、不適切なインデックスはオプティマイザに誤判断を促します。したがって、セカンダリインデックスの数が増えてもパフォーマンスが向上するとは限りません。 @@ -144,7 +144,7 @@ MySQLで培った豊富な経験はTiDBにも活かすことができます。Ti 展開する前に、 [TiDB のソフトウェアおよびハードウェア要件](/hardware-and-software-requirements.md)お読みください。 -TiDBクラスタは[TiUP](/production-deployment-using-tiup.md)を使用してデプロイすることをお勧めします。このツールはクラスタ全体のデプロイ、停止、破棄、アップグレードを実行できるため、非常に便利です。TiDBクラスタを手動でデプロイすることは推奨されません。後々のメンテナンスやアップグレードが面倒になる可能性があります。 +TiDBクラスターは[TiUP](/production-deployment-using-tiup.md)を使用してデプロイすることをお勧めします。このツールはクラスター全体のデプロイ、停止、破棄、アップグレードを実行できるため、非常に便利です。TiDBクラスターを手動でデプロイすることは推奨されません。後々のメンテナンスやアップグレードが面倒になる可能性があります。 ### データのインポート {#data-import} @@ -183,25 +183,25 @@ for i from 0 to 23: アプリケーションシナリオにOLTPとOLAPの両方のワークロードが含まれる場合、OLTPリクエストとOLAPリクエストを異なるTiDBサーバーに送信することで、OLAPがOLTPに与える影響を軽減できます。OLAPワークロードを処理するTiDBサーバーには、高性能ハードウェア（例えば、プロセッサコア数やメモリが大きい）を搭載したマシンを使用することをお勧めします。 -OLTPとOLAPのワークロードを完全に分離するには、OLAPアプリケーションをTiFlash上​​で実行することをお勧めします。TiFlashは、OLAPワークロードで優れたパフォーマンスを発揮する列指向storageエンジンです。TiFlashはstorageレイヤーでの物理的な分離を実現し、一貫性のある読み取りを保証します。 +OLTPとOLAPのワークロードを完全に分離するには、OLAPアプリケーションをTiFlash上​​で実行することをお勧めします。TiFlashは、OLAPワークロードで優れたパフォーマンスを発揮する列指向ストレージエンジンです。TiFlashはストレージレイヤーでの物理的な分離を実現し、一貫性のある読み取りを保証します。 ### 監視とログ {#monitoring-and-log} -監視メトリクスは、システムの状態を把握するための最適な方法です。TiDBクラスタと併せて監視システムを導入することをお勧めします。 +監視メトリクスは、システムの状態を把握するための最適な方法です。TiDBクラスターと併せて監視システムを導入することをお勧めします。 TiDBはシステムステータスを監視するために[グラファナ + プロメテウス](/tidb-monitoring-framework.md)使用します。TiUPを使用してTiDBをデプロイすると、監視システムは自動的にデプロイおよび設定されます。 監視システムには多くの項目があり、そのほとんどはTiDB開発者向けです。ソースコードの詳細な知識がなくても、これらの項目を理解する必要はありません。アプリケーションやシステムの主要コンポーネントの状態に関連する項目は、ユーザー向けに`overview`のパネルにまとめられています。 -監視に加えて、システムログも閲覧できます。TiDBの3つのコンポーネント、tidb-server、tikv-server、pd-serverにはそれぞれ`--log-file`パラメータがあります。クラスタ起動時にこのパラメータが設定されている場合、ログはパラメータで設定されたファイルに保存され、ログファイルは毎日自動的にアーカイブされます。3 `--log-file`パラメータが設定されていない場合、ログは`stderr`に出力されます。 +監視に加えて、システムログも閲覧できます。TiDBの3つのコンポーネント、tidb-server、tikv-server、pd-serverにはそれぞれ`--log-file`パラメータがあります。クラスター起動時にこのパラメータが設定されている場合、ログはパラメータで設定されたファイルに保存され、ログファイルは毎日自動的にアーカイブされます。3 `--log-file`パラメータが設定されていない場合、ログは`stderr`に出力されます。 -TiDB 4.0以降、TiDBはユーザビリティを向上させるために[TiDBダッシュボード](/dashboard/dashboard-intro.md) UIを提供します。ブラウザで[http://${PD_IP}:${PD_PORT}/ダッシュボード](http://$%7BPD_IP%7D:$%7BPD_PORT%7D/dashboard)にアクセスすると、TiDBダッシュボードにアクセスできます。TiDBダッシュボードでは、クラスタステータスの表示、パフォーマンス分析、トラフィックの可視化、クラスタ診​​断、ログ検索などの機能が提供されます。 +TiDB 4.0以降、TiDBはユーザビリティを向上させるために[TiDBダッシュボード](/dashboard/dashboard-intro.md) UIを提供します。ブラウザで[http://${PD_IP}:${PD_PORT}/ダッシュボード](http://$%7BPD_IP%7D:$%7BPD_PORT%7D/dashboard)にアクセスすると、TiDBダッシュボードにアクセスできます。TiDBダッシュボードでは、クラスターステータスの表示、パフォーマンス分析、トラフィックの可視化、クラスター診​​断、ログ検索などの機能が提供されます。 ### ドキュメント {#documentation} システムについて学んだり問題を解決したりする最良の方法は、システムのドキュメントを読んで実装の原則を理解することです。 -TiDBには、中国語と英語の両方で多数の公式ドキュメントがあります。問題が発生した場合は、 [FAQ](/faq/tidb-faq.md)と[TiDBクラスタシューティング ガイド](/troubleshoot-tidb-cluster.md)から始めることができます。また、問題リストを検索したり、 [GitHub の TiDB リポジトリ](https://github.com/pingcap/tidb)で問題を作成したりすることもできます。 +TiDBには、中国語と英語の両方で多数の公式ドキュメントがあります。問題が発生した場合は、 [FAQ](/faq/tidb-faq.md)と[TiDBクラスターシューティング ガイド](/troubleshoot-tidb-cluster.md)から始めることができます。また、問題リストを検索したり、 [GitHub の TiDB リポジトリ](https://github.com/pingcap/tidb)で問題を作成したりすることもできます。 TiDBには便利な移行ツールも多数あります。詳細は[移行ツールの概要](/ecosystem-tool-user-guide.md)ご覧ください。 @@ -215,4 +215,4 @@ TiDB は次のシナリオに適しています。 - シャーディングはしたくない - アクセスモードには明らかなホットスポットがない - トランザクション、強力な一貫性、災害復旧が必須 -- リアルタイムのハイブリッドトランザクション/分析処理（HTAP）分析を実現し、storageリンクを削減したいと考えています。 +- リアルタイムのハイブリッドトランザクション/分析処理（HTAP）分析を実現し、ストレージリンクを削減したいと考えています。 diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md index bff819efdf4e2..5eebaf9b00975 100644 --- a/best-practices/tidb-partitioned-tables-best-practices.md +++ b/best-practices/tidb-partitioned-tables-best-practices.md @@ -114,7 +114,7 @@ WHERE `fa`.`sid` IN ( 次の表は、365 個の範囲パーティションを持つテーブルから 400 行を返すクエリの結果を示しています。 -| コンフィグレーション | 平均クエリ時間 | タスクの収集（インデックススキャン） | 警官タスク（テーブル検索） | 警官の合計タスク | +| 設定 | 平均クエリ時間 | タスクの収集（インデックススキャン） | 警官タスク（テーブル検索） | 警官の合計タスク | | ------------------------- | ------- | ------------------ | ------------- | -------- | | パーティションテーブル | 12.6ミリ秒 | 72 | 79 | 151 | | ローカルインデックスを持つパーティションテーブル | 108ミリ秒 | 600 | 375 | 975 | @@ -348,7 +348,7 @@ ALTER TABLE A DROP PARTITION A_2024363; ## ホットスポットの問題を軽減する {#mitigate-hotspot-issues} -TiDB では、読み取りまたは書き込みトラフィックが[地域](/tidb-storage.md#region)に不均等に分散されている場合にホットスポットが発生します。ホットスポットは、次のような場合によく発生します。 +TiDB では、読み取りまたは書き込みトラフィックが[地域](/tidb-ストレージ.md#region)に不均等に分散されている場合にホットスポットが発生します。ホットスポットは、次のような場合によく発生します。 - 単調に増加する主キー ( `AUTO_INCREMENT`主キーと`AUTO_ID_CACHE=1`など)。 - デフォルト値が`CURRENT_TIMESTAMP`である datetime 列のセカンダリ インデックス。 @@ -464,11 +464,11 @@ TiDBでは、新しく作成されたパーティションは、最初は1つの | テーブルタイプ | リージョンの事前分割 | 読み取りパフォーマンス | 書き込みスケーラビリティ | パーティションごとのデータクリーンアップ | | -------------------- | ---------- | ------------ | ------------ | -------------------- | -| 非クラスタ化パーティションテーブル | 自動 | 下位（追加の検索が必要） | 高い | サポートされている | +| 非クラスター化パーティションテーブル | 自動 | 下位（追加の検索が必要） | 高い | サポートされている | | クラスター化されたパーティションテーブル | マニュアル | 高（検索回数が少ない） | 高（手動管理あり） | サポートされている | -| クラスタ化された非パーティションテーブル | 該当なし | 高い | 安定した | サポートされていません | +| クラスター化された非パーティションテーブル | 該当なし | 高い | 安定した | サポートされていません | -### 非クラスタ化パーティションテーブルのソリューション {#solutions-for-non-clustered-partitioned-tables} +### 非クラスター化パーティションテーブルのソリューション {#solutions-for-non-clustered-partitioned-tables} #### 利点 {#advantages} @@ -593,9 +593,9 @@ SHOW TABLE employees PARTITION (p4) regions; #### ベストプラクティス {#best-practices} -新しい範囲パーティションによって発生するホットスポットの問題を軽減するには、 [非クラスタ化パーティションテーブルのベストプラクティス](#best-practices)手順に従います。 +新しい範囲パーティションによって発生するホットスポットの問題を軽減するには、 [非クラスター化パーティションテーブルのベストプラクティス](#best-practices)手順に従います。 -### クラスタ化された非パーティションテーブルのソリューション {#solutions-for-clustered-non-partitioned-tables} +### クラスター化された非パーティションテーブルのソリューション {#solutions-for-clustered-non-partitioned-tables} #### 利点 {#advantages} diff --git a/best-practices/uuid.md b/best-practices/uuid.md index 0f14f1766c80b..47482cabc2737 100644 --- a/best-practices/uuid.md +++ b/best-practices/uuid.md @@ -56,7 +56,7 @@ CREATE TABLE `uuid_demo_2` ( Key Visualizer の詳細については、次のドキュメントを参照してください。 -- TiDBセルフマネージドの場合は[キービジュアライザー](/dashboard/dashboard-key-visualizer.md) +- TiDB Self-Managedの場合は[キービジュアライザー](/dashboard/dashboard-key-visualizer.md) - TiDB Cloudの場合は[キービジュアライザー](/tidb-cloud/tune-performance.md#key-visualizer) ## MySQLの互換性 {#mysql-compatibility} diff --git a/binary-package.md b/binary-package.md index 81d242642c415..c987fd60bf322 100644 --- a/binary-package.md +++ b/binary-package.md @@ -60,7 +60,7 @@ TiDBバイナリパッケージは、amd64およびarm64アーキテクチャで | dba-{バージョン}-linux-{アーキテクチャ}.tar.gz | | | PCC-{バージョン}-linux-{アーキテクチャ}.tar.gz | | | 同期差分インスペクター | | -| レパロ | | +| Reparo | | | サーバー-{バージョン}-linux-{アーキテクチャ}.tar.gz | バージョン6.2.0の新機能 | | grafana-{バージョン}-linux-{アーキテクチャ}.tar.gz | バージョン6.2.0の新機能 | | アラートマネージャー-{バージョン}-linux-{アーキテクチャ}.tar.gz | バージョン6.2.0の新機能 | diff --git a/br/backup-and-restore-design.md b/br/backup-and-restore-design.md index d09f24bce8873..ddcf794c945de 100644 --- a/br/backup-and-restore-design.md +++ b/br/backup-and-restore-design.md @@ -1,6 +1,6 @@ --- title: Overview of TiDB Backup & Restore Architecture -summary: TiDBは、Backup & Restore（BR）とTiDB Operatorを使用したクラスタデータのバックアップとリストアをサポートしています。TiKVノードからデータをバックアップし、TiKVノードにデータをリストアするタスクを作成できます。アーキテクチャには、フルデータバックアップとリストア、データ変更ログバックアップ、ポイントインタイムリカバリ（PITR）が含まれます。詳細については、各機能のドキュメントを参照してください。 +summary: TiDBは、Backup & Restore（BR）とTiDB Operatorを使用したクラスターデータのバックアップとリストアをサポートしています。TiKVノードからデータをバックアップし、TiKVノードにデータをリストアするタスクを作成できます。アーキテクチャには、フルデータバックアップとリストア、データ変更ログバックアップ、ポイントインタイムリカバリ（PITR）が含まれます。詳細については、各機能のドキュメントを参照してください。 --- # TiDB バックアップとリストアのアーキテクチャの概要 {#overview-of-tidb-backup-x26-restore-architecture} diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index bb2f1d7937a7a..9b1ddeed199da 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -1,11 +1,11 @@ --- title: TiDB Backup & Restore Overview -summary: TiDB Backup & Restore (BR) は、クラスタの高可用性とデータの安全性を確保します。短い RPO でディザスタリカバリをサポートし、誤操作を処理し、履歴データの監査機能を提供します。バックアップ操作はオフピーク時に実行し、バックアップデータは互換性のあるstorageシステムに保存することをお勧めします。BRは、フルバックアップとログバックアップ、および任意の時点へのデータ復元をサポートします。バックアップと復元には、TiDB クラスタと同じメジャーバージョンのBRを使用することが重要です。 +summary: TiDB Backup & Restore (BR) は、クラスターの高可用性とデータの安全性を確保します。短い RPO でディザスタリカバリをサポートし、誤操作を処理し、履歴データの監査機能を提供します。バックアップ操作はオフピーク時に実行し、バックアップデータは互換性のあるストレージシステムに保存することをお勧めします。BRは、フルバックアップとログバックアップ、および任意の時点へのデータ復元をサポートします。バックアップと復元には、TiDB クラスターと同じメジャーバージョンのBRを使用することが重要です。 --- # TiDBのバックアップと復元の概要 {#tidb-backup-x26-restore-overview} -TiDBは、 Raftプロトコルと適切なデプロイメントトポロジーに基づいて、クラスタの高い可用性を実現しています。クラスタ内のノードがいくつか故障しても、クラスタは引き続き利用可能です。さらにデータの安全性を確保するため、TiDBは、自然災害や誤操作からデータを復旧するための最終手段として、バックアップ＆リストア（BR）機能を提供しています。 +TiDBは、 Raftプロトコルと適切なデプロイメントトポロジーに基づいて、クラスターの高い可用性を実現しています。クラスター内のノードがいくつか故障しても、クラスターは引き続き利用可能です。さらにデータの安全性を確保するため、TiDBは、自然災害や誤操作からデータを復旧するための最終手段として、バックアップ＆リストア（BR）機能を提供しています。 BRは以下の要件を満たしています。 @@ -24,27 +24,27 @@ BRは以下の要件を満たしています。 - PITRは、システムテーブルからユーザーテーブルまたは権限テーブルのデータを復元することをサポートしていません。 - BRは、クラスター上で複数のバックアップタスクを**同時に**実行することをサポートしていません。 - 復元中のテーブルをバックアップすることは推奨されません。バックアップされたデータに問題が発生する可能性があるためです。 -- PITRを使用してクラスタを復元する場合、ログバックアップタスクを実行したり、TiCDCを使用してデータをダウンストリームクラスタにレプリケートしたりすることはできません。 +- PITRを使用してクラスターを復元する場合、ログバックアップタスクを実行したり、TiCDCを使用してデータをダウンストリームクラスターにレプリケートしたりすることはできません。 ### いくつかのヒント {#some-tips} スナップショットバックアップ: - アプリケーションへの影響を最小限に抑えるため、バックアップ作業はピーク時以外の時間帯に行うことをお勧めします。 -- 複数のバックアップまたはリストアタスクは、一つずつ実行することをお勧めします。複数のバックアップタスクを並行して実行すると、パフォーマンスが低下します。さらに悪いことに、複数のタスク間の連携が不足すると、タスクの失敗やクラスタのパフォーマンス低下につながる可能性があります。 +- 複数のバックアップまたはリストアタスクは、一つずつ実行することをお勧めします。複数のバックアップタスクを並行して実行すると、パフォーマンスが低下します。さらに悪いことに、複数のタスク間の連携が不足すると、タスクの失敗やクラスターのパフォーマンス低下につながる可能性があります。 スナップショット復元: - BRはターゲットクラスターのリソースを最大限に活用します。そのため、新しいクラスターまたはオフラインのクラスターにデータを復元することをお勧めします。本番のクラスターにデータを復元することは避けてください。そうしないと、アプリケーションに必ず影響が出ます。 -バックアップstorageとネットワーク構成： +バックアップストレージとネットワーク構成： -- バックアップデータは、Amazon S3、GCS、またはAzure Blob Storageと互換性のあるstorageシステムに保存することをお勧めします。 -- BR、TiKV、およびバックアップstorageシステムに十分なネットワーク帯域幅があり、バックアップstorageシステムが十分な読み取り/書き込み性能（IOPS）を提供できることを確認する必要があります。そうでない場合、バックアップおよびリストア時にパフォーマンスのボトルネックになる可能性があります。 +- バックアップデータは、Amazon S3、GCS、またはAzure Blob Storageと互換性のあるストレージシステムに保存することをお勧めします。 +- BR、TiKV、およびバックアップストレージシステムに十分なネットワーク帯域幅があり、バックアップストレージシステムが十分な読み取り/書き込み性能（IOPS）を提供できることを確認する必要があります。そうでない場合、バックアップおよびリストア時にパフォーマンスのボトルネックになる可能性があります。 ## バックアップと復元を使用する {#use-backup-and-restore} -BRの使用方法は、TiDBの導入方法によって異なります。このドキュメントでは、オンプレミス環境において、brコマンドラインツールを使用してTiDBクラスタデータをバックアップおよび復元する方法について説明します。 +BRの使用方法は、TiDBの導入方法によって異なります。このドキュメントでは、オンプレミス環境において、brコマンドラインツールを使用してTiDBクラスターデータをバックアップおよび復元する方法について説明します。 他の導入シナリオでこの機能を使用する方法については、以下のドキュメントを参照してください。 @@ -55,7 +55,7 @@ BRの使用方法は、TiDBの導入方法によって異なります。この TiDB BRは以下の機能を提供します。 -- クラスタデータのバックアップ: 特定の時点におけるクラスタの完全なデータ (**フルバックアップ**) をバックアップすることも、TiDB のデータ変更 (**ログバックアップ**、ここでログとは TiKV の KV の変更を意味します) をバックアップすることもできます。 +- クラスターデータのバックアップ: 特定の時点におけるクラスターの完全なデータ (**フルバックアップ**) をバックアップすることも、TiDB のデータ変更 (**ログバックアップ**、ここでログとは TiKV の KV の変更を意味します) をバックアップすることもできます。 - バックアップデータを復元する： @@ -64,19 +64,19 @@ TiDB BRは以下の機能を提供します。 ### クラスターデータのバックアップ {#back-up-cluster-data} -フルバックアップは、特定の時点におけるクラスタのすべてのデータをバックアップします。TiDBは、以下のフルバックアップ方法をサポートしています。 +フルバックアップは、特定の時点におけるクラスターのすべてのデータをバックアップします。TiDBは、以下のフルバックアップ方法をサポートしています。 - クラスターのスナップショットをバックアップする: TiDB クラスターのスナップショットには、特定の時点でのトランザクション的に一貫したデータが含まれています。詳細については、 [スナップショットバックアップ](/br/br-snapshot-guide.md#back-up-cluster-snapshots)を参照してください。 -フルバックアップは多くのstorage容量を消費し、特定の時点のクラスタデータのみを含みます。必要に応じて復元ポイントを選択する、つまりポイントインタイムリカバリ（PITR）を実行する場合は、以下の2つのバックアップ方法を同時に使用できます。 +フルバックアップは多くのストレージ容量を消費し、特定の時点のクラスターデータのみを含みます。必要に応じて復元ポイントを選択する、つまりポイントインタイムリカバリ（PITR）を実行する場合は、以下の2つのバックアップ方法を同時に使用できます。 -- [ログバックアップ](/br/br-pitr-guide.md#start-log-backup)バックアップが開始されると、タスクはすべてのTiKVノードで実行され続け、TiDBの増分データを定期的に小バッチで指定されたstorageにバックアップします。 -- 定期的にスナップショットバックアップを実行してください。クラスタ全体のデータをバックアップstorageにバックアップします。例えば、毎日午前0時にクラスタのスナップショットバックアップを実行します。 +- [ログバックアップ](/br/br-pitr-guide.md#start-log-backup)バックアップが開始されると、タスクはすべてのTiKVノードで実行され続け、TiDBの増分データを定期的に小バッチで指定されたストレージにバックアップします。 +- 定期的にスナップショットバックアップを実行してください。クラスター全体のデータをバックアップストレージにバックアップします。例えば、毎日午前0時にクラスターのスナップショットバックアップを実行します。 -#### バックアップのパフォーマンスとTiDBクラスタへの影響 {#backup-performance-and-impact-on-tidb-clusters} +#### バックアップのパフォーマンスとTiDBクラスターへの影響 {#backup-performance-and-impact-on-tidb-clusters} -- クラスタのCPUとI/Oリソースが十分な場合、スナップショットバックアップがTiDBクラスタに与える影響は限定的で、通常は20%未満に抑えられます。TiDBクラスタを適切に構成することで、この影響をさらに10%以下にまで最小限に抑えることができます。CPUとI/Oリソースが不足している場合は、TiKV構成項目[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整して、バックアップタスクで使用されるワーカースレッド数を変更し、バックアップタスクがTiDBクラスタに与える影響を軽減できます。TiKVノードのバックアップ速度はスケーラブルで、50MB/秒から100MB/秒の範囲です。詳細については、 と[バックアップのパフォーマンスと影響](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-backup)参照してください。 -- ログバックアップタスクのみの場合、クラスタへの影響は約5%です。ログバックアップは、3～5分ごとに最後の更新後に生成されたすべての変更をバックアップstorageにフラッシュするため、**最短5分のリカバリポイント目標（RPO）を実現できます**。 +- クラスターのCPUとI/Oリソースが十分な場合、スナップショットバックアップがTiDBクラスターに与える影響は限定的で、通常は20%未満に抑えられます。TiDBクラスターを適切に構成することで、この影響をさらに10%以下にまで最小限に抑えることができます。CPUとI/Oリソースが不足している場合は、TiKV構成項目[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整して、バックアップタスクで使用されるワーカースレッド数を変更し、バックアップタスクがTiDBクラスターに与える影響を軽減できます。TiKVノードのバックアップ速度はスケーラブルで、50MB/秒から100MB/秒の範囲です。詳細については、 と[バックアップのパフォーマンスと影響](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-backup)参照してください。 +- ログバックアップタスクのみの場合、クラスターへの影響は約5%です。ログバックアップは、3～5分ごとに最後の更新後に生成されたすべての変更をバックアップストレージにフラッシュするため、**最短5分のリカバリポイント目標（RPO）を実現できます**。 ### バックアップデータを復元する {#restore-backup-data} @@ -88,19 +88,19 @@ TiDB BRは以下の機能を提供します。 - 任意の時点へのデータ復元（PITR） - - `br restore point`コマンドを実行すると、リカバリ時点より前の最新のスナップショットバックアップデータを復元し、指​​定した時点までのバックアップデータをログに記録できます。BRは復元範囲を自動的に判断し、バックアップデータにアクセスして、ターゲットクラスタにデータを復元します。 + - `br restore point`コマンドを実行すると、リカバリ時点より前の最新のスナップショットバックアップデータを復元し、指​​定した時点までのバックアップデータをログに記録できます。BRは復元範囲を自動的に判断し、バックアップデータにアクセスして、ターゲットクラスターにデータを復元します。 #### TiDBクラスターのパフォーマンスと影響を回復する {#restore-performance-and-impact-on-tidb-clusters} - データの復元はスケーラブルな速度で実行されます。通常、速度は TiKV ノードあたり 1 GiB/秒です。詳細については、 [パフォーマンスとインパクトを回復](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-restore)をご覧ください。 - 各 TiKV ノードでは、PITR は 30 GiB/h でログ データを復元できます。詳細については、 [PITRのパフォーマンスと影響](/br/br-pitr-guide.md#performance-capabilities-of-pitr)ご覧ください。 -## バックアップstorage {#backup-storage} +## バックアップストレージ {#backup-ストレージ} -TiDBは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、NFS、およびその他のS3互換ファイルstorageサービスへのデータバックアップをサポートしています。詳細については、以下のドキュメントを参照してください。 +TiDBは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、NFS、およびその他のS3互換ファイルストレージサービスへのデータバックアップをサポートしています。詳細については、以下のドキュメントを参照してください。 -- [URIでバックアップstorageを指定します](/external-storage-uri.md) -- [バックアップストレージへのアクセス権限を設定する](/br/backup-and-restore-storages.md#authentication) +- [URIでバックアップストレージを指定します](/external-ストレージ-uri.md) +- [バックアップストレージへのアクセス権限を設定する](/br/backup-and-restore-ストレージs.md#authentication) ## 互換性 {#compatibility} @@ -110,23 +110,23 @@ TiDBの一部の機能が有効化または無効化されている場合、バ | 特徴 | 問題 | 解決 | | --------------------- | ------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| GBK文字セット | | v5.4.0より前のバージョンのBRは`charset=GBK`テーブルの復元をサポートしていません。また、v5.4.0より前のTiDBクラスタへの`charset=GBK`テーブルのリカバリをサポートするBRのバージョンもありません。 | +| GBK文字セット | | v5.4.0より前のバージョンのBRは`charset=GBK`テーブルの復元をサポートしていません。また、v5.4.0より前のTiDBクラスターへの`charset=GBK`テーブルのリカバリをサポートするBRのバージョンもありません。 | | クラスター化インデックス | [#565](https://github.com/pingcap/br/issues/565) | リストア時にグローバル変数`tidb_enable_clustered_index`の値がバックアップ時の値と一致していることを確認してください。一致しない場合、 `default not found`エラーやデータインデックスの不整合など、データの不整合が発生する可能性があります。 | | 新しい照合順序 | [#352](https://github.com/pingcap/br/issues/352) | 復元中の`new_collation_enabled`テーブル内の`mysql.tidb`変数の値がバックアップ中の値と一致していることを確認してください。そうしないと、データ インデックスの不整合が発生し、チェックサムが失敗する可能性があります。詳細については、 [FAQ - BRが`new_collations_enabled_on_first_bootstrap`不一致を報告するのはなぜですか？](/faq/backup-and-restore-faq.md#why-is-new_collation_enabled-mismatch-reported-during-restore)参照してください。 | | グローバル一時テーブル | | データのバックアップと復元には、 BRのバージョン5.3.0以降を使用していることを確認してください。そうでない場合、バックアップ対象のグローバル一時テーブルの定義でエラーが発生します。 | | TiDB Lightning物理インポート | | アップストリーム データベースがTiDB Lightningの物理インポート モードを使用している場合、ログ バックアップでデータをバックアップできません。データのインポート後に完全バックアップを実行することをお勧めします。詳細については、 [上流データベースがTiDB Lightningを使用して物理インポートモードでデータをインポートすると、ログバックアップ機能が利用できなくなります。なぜでしょうか？](/faq/backup-and-restore-faq.md#when-the-upstream-database-imports-data-using-tidb-lightning-in-the-physical-import-mode-the-log-backup-feature-becomes-unavailable-why)参照してください。 | | TiCDC | | BR v8.2.0 以降: リストア対象のクラスターにチェンジフィードがあり、チェンジフィードの[CheckpointTS](/ticdc/ticdc-classic-architecture.md#checkpointts)が BackupTS より前の場合、 BR はリストアを実行しません。 BRバージョン v8.2.0 より前: リストア対象のクラスターにアクティブな TiCDC チェンジフィードがある場合、 BR はリストアを実行しません。 | -| ベクトル検索 | | データのバックアップと復元には、 BR v8.4.0 以降のバージョンを使用していることを確認してください。テーブルを で復元することは [ベクトルデータ型](/ai/reference/vector-search-data-types.md)v8.4.0 より前の TiDB クラスタではサポートされていません。 | +| ベクトル検索 | | データのバックアップと復元には、 BR v8.4.0 以降のバージョンを使用していることを確認してください。テーブルを で復元することは [ベクトルデータ型](/ai/reference/vector-search-data-types.md)v8.4.0 より前の TiDB クラスターではサポートされていません。 | ### バージョン互換性 {#version-compatibility} > **注記：** > -> バックアップおよび復元には、TiDBクラスタと同じメジャーバージョンのBRを使用することをお勧めします。 +> バックアップおよび復元には、TiDBクラスターと同じメジャーバージョンのBRを使用することをお勧めします。 -バックアップとリストアを実行する前に、 BR はTiDB クラスタのバージョンを自身のバージョンと比較し、互換性を確認します。バージョンに互換性がない場合、 BR はエラーを報告して終了します。バージョンチェックを強制的にスキップするには、 `--check-requirements=false`を設定します。バージョンチェックをスキップすると、データに互換性の問題が生じる可能性があることに注意してください。 +バックアップとリストアを実行する前に、 BR はTiDB クラスターのバージョンを自身のバージョンと比較し、互換性を確認します。バージョンに互換性がない場合、 BR はエラーを報告して終了します。バージョンチェックを強制的にスキップするには、 `--check-requirements=false`を設定します。バージョンチェックをスキップすると、データに互換性の問題が生じる可能性があることに注意してください。 -バージョン 7.0.0 以降、TiDB は SQL ステートメントによるバックアップおよびリストア操作を段階的にサポートしています。そのため、クラスタ データのバックアップおよびリストアを行う際には、TiDB クラスタと同じメジャー バージョンのBRツールを使用することを強く推奨します。また、メジャー バージョンをまたいでのデータ バックアップおよびリストア操作は避けてください。これにより、リストア操作のスムーズな実行とデータの一貫性が確保されます。バージョン 7.6.0 以降、 BR はデフォルトで一部の`mysql`システム テーブルにデータをリストアします。つまり、 `--with-sys-table`オプションはデフォルトで`true`に設定されます。異なるバージョンの TiDB クラスタにデータを復元する際に、システム テーブルのスキーマが異なるために`[BR:Restore:ErrRestoreIncompatibleSys]incompatible system table`と同様のエラーが発生した場合は、 `--with-sys-table=false`を設定してシステム テーブルの復元をスキップし、このエラーを回避できます。 +バージョン 7.0.0 以降、TiDB は SQL ステートメントによるバックアップおよびリストア操作を段階的にサポートしています。そのため、クラスター データのバックアップおよびリストアを行う際には、TiDB クラスターと同じメジャー バージョンのBRツールを使用することを強く推奨します。また、メジャー バージョンをまたいでのデータ バックアップおよびリストア操作は避けてください。これにより、リストア操作のスムーズな実行とデータの一貫性が確保されます。バージョン 7.6.0 以降、 BR はデフォルトで一部の`mysql`システム テーブルにデータをリストアします。つまり、 `--with-sys-table`オプションはデフォルトで`true`に設定されます。異なるバージョンの TiDB クラスターにデータを復元する際に、システム テーブルのスキーマが異なるために`[BR:Restore:ErrRestoreIncompatibleSys]incompatible system table`と同様のエラーが発生した場合は、 `--with-sys-table=false`を設定してシステム テーブルの復元をスキップし、このエラーを回避できます。 #### TiDB v6.6.0以前のBRバージョン互換性マトリックス {#br-version-compatibility-matrix-before-tidb-v6-6-0} @@ -143,8 +143,8 @@ TiDB v6.6.0より前のBRの互換性情報は以下のとおりです。 > **注記：** > -> - 既知の問題：v7.2.0以降、新規作成されたクラスタの一部のシステムテーブルフィールドは、大文字と小文字を区別しなくなります。ただし、v7.2.0より前のバージョンからv7.2.0以降に**オンラインでアップグレードされ**たクラスタの場合、対応するシステムテーブルフィールドは引き続き大文字と小文字を区別します。これら2種類のクラスタ間でシステムテーブルを含むバックアップおよびリストア操作を行うと、失敗する可能性があります。詳細については、 [問題番号43717](https://github.com/pingcap/tidb/issues/43717)を参照してください。 -> - バージョン8.5.5以降、 BRは`--sys-check-collation`パラメータを使用してシステムテーブルを復元する際に、照合順序の互換性チェックをサポートするようになりました。復元中、 BRはターゲットクラスタ照合順序で大文字小文字の競合が存在するかどうかを確認します。データがターゲット照合順序と互換性がある場合、 BRは以前のバージョンからのバックアップを正常に復元できます。そうでない場合、 BRはエラーを報告して復元を終了します。 +> - 既知の問題：v7.2.0以降、新規作成されたクラスターの一部のシステムテーブルフィールドは、大文字と小文字を区別しなくなります。ただし、v7.2.0より前のバージョンからv7.2.0以降に**オンラインでアップグレードされ**たクラスターの場合、対応するシステムテーブルフィールドは引き続き大文字と小文字を区別します。これら2種類のクラスター間でシステムテーブルを含むバックアップおよびリストア操作を行うと、失敗する可能性があります。詳細については、 [問題番号43717](https://github.com/pingcap/tidb/issues/43717)を参照してください。 +> - バージョン8.5.5以降、 BRは`--sys-check-collation`パラメータを使用してシステムテーブルを復元する際に、照合順序の互換性チェックをサポートするようになりました。復元中、 BRはターゲットクラスター照合順序で大文字小文字の競合が存在するかどうかを確認します。データがターゲット照合順序と互換性がある場合、 BRは以前のバージョンからのバックアップを正常に復元できます。そうでない場合、 BRはエラーを報告して復元を終了します。 以下の表は、フルバックアップの互換性マトリックスを示しています。なお、表の情報はすべて新規作成されたクラスターに適用されます。v7.2.0より前のバージョンからv7.2.0以降にアップグレードされたクラスターについては、v7.1.0のバックアップと同様の動作となります。 @@ -156,7 +156,7 @@ TiDB v6.6.0より前のBRの互換性情報は以下のとおりです。 | v8.1.0 | バージョン8.1.0以降 | - | | v8.5.0 | バージョン8.5.0以降 | - | -以下の表は、ログバックアップの互換性マトリックスを示しています。なお、表の情報はすべて新規作成されたクラスタに適用されます。v7.2.0より前のバージョンからv7.2.0以降にアップグレードされたクラスタについては、v7.1.0のバックアップと同様の動作となります。 +以下の表は、ログバックアップの互換性マトリックスを示しています。なお、表の情報はすべて新規作成されたクラスターに適用されます。v7.2.0より前のバージョンからv7.2.0以降にアップグレードされたクラスターについては、v7.1.0のバックアップと同様の動作となります。 | バックアップバージョン | 互換性のある復元バージョン | 互換性のない復元バージョン | | :---------- | :------------ | :------------ | @@ -176,7 +176,7 @@ TiDB v6.6.0より前のBRの互換性情報は以下のとおりです。 - [TiDBスナップショットのバックアップと復元ガイド](/br/br-snapshot-guide.md) - [TiDBログバックアップおよびPITRガイド](/br/br-pitr-guide.md) -- [バックアップストレージ](/br/backup-and-restore-storages.md) +- [バックアップストレージ](/br/backup-and-restore-ストレージs.md) ## 関連リソース {#related-resources} diff --git a/br/backup-and-restore-storages.md b/br/backup-and-restore-storages.md index 823f2ed5909dc..8928b772e1259 100644 --- a/br/backup-and-restore-storages.md +++ b/br/backup-and-restore-storages.md @@ -1,11 +1,11 @@ --- title: Backup Storages -summary: TiDBは、Amazon S3、Google Cloud Storage、Azure Blob Storage、NFSへのバックアップstorageをサポートしています。各storageサービスのURIと認証情報を指定できます。S3、GCS、またはAzure Blob Storageを使用する場合、 BRはデフォルトでTiKVに認証情報を送信します。クラウド環境では、この機能を無効にすることができます。各storageサービスのURI形式と認証方法を指定します。Amazon S3とAzure Blob Storageでは、サーバー側暗号化がサポートされています。BR v6.3.0はAWS S3オブジェクトロックもサポートしています。 +summary: TiDBは、Amazon S3、Google Cloud Storage、Azure Blob Storage、NFSへのバックアップストレージをサポートしています。各ストレージサービスのURIと認証情報を指定できます。S3、GCS、またはAzure Blob Storageを使用する場合、 BRはデフォルトでTiKVに認証情報を送信します。クラウド環境では、この機能を無効にすることができます。各ストレージサービスのURI形式と認証方法を指定します。Amazon S3とAzure Blob Storageでは、サーバー側暗号化がサポートされています。BR v6.3.0はAWS S3オブジェクトロックもサポートしています。 --- -# バックアップストレージ {#backup-storages} +# バックアップストレージ {#backup-ストレージs} -TiDBは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、NFSへのバックアップデータの保存をサポートしています。具体的には、 `br`コマンドの`--storage`または`-s`のパラメータでバックアップstorageのURIを指定できます。このドキュメントでは、 [URI形式](#uri-format)と[認証](#authentication)の外部ストレージサービスと、 [サーバー側の暗号化](#server-side-encryption)の外部storageサービスを紹介します。 +TiDBは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、NFSへのバックアップデータの保存をサポートしています。具体的には、 `br`コマンドの`--ストレージ`または`-s`のパラメータでバックアップストレージのURIを指定できます。このドキュメントでは、 [URI形式](#uri-format)と[認証](#authentication)の外部ストレージサービスと、 [サーバー側の暗号化](#server-side-encryption)の外部ストレージサービスを紹介します。 ## TiKVに資格情報を送信する {#send-credentials-to-tikv} @@ -13,12 +13,12 @@ TiDBは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、NFS | :--------------------------- | :------------------------------------- | :----- | | `--send-credentials-to-tikv` | BRによって取得された資格情報を TiKV に送信するかどうかを制御します。 | `true` | -デフォルトでは、 BRはAmazon S3、GCS、またはAzure Blob Storageをstorageシステムとして使用する場合、各TiKVノードに認証情報を送信します。この動作は設定を簡素化し、パラメータ`--send-credentials-to-tikv` （または短縮形`-c` ）によって制御されます。 +デフォルトでは、 BRはAmazon S3、GCS、またはAzure Blob Storageをストレージシステムとして使用する場合、各TiKVノードに認証情報を送信します。この動作は設定を簡素化し、パラメータ`--send-credentials-to-tikv` （または短縮形`-c` ）によって制御されます。 この操作はクラウド環境には適用されないことに注意してください。IAMロール認証を使用する場合、各ノードには独自のロールと権限が付与されます。この場合、認証情報の送信を無効にするには、 `--send-credentials-to-tikv=false` （または`-c=0` ）を設定する必要があります。 ```bash -tiup br backup full -c=0 -u pd-service:2379 --storage 's3://bucket-name/prefix' +tiup br backup full -c=0 -u pd-service:2379 --ストレージ 's3://bucket-name/prefix' ``` [`BACKUP`](/sql-statements/sql-statement-backup.md)および[`RESTORE`](/sql-statements/sql-statement-restore.md)ステートメントを使用してデータをバックアップまたは復元する場合は、 `SEND_CREDENTIALS_TO_TIKV = FALSE`オプションを追加できます。 @@ -31,33 +31,33 @@ BACKUP DATABASE * TO 's3://bucket-name/prefix' SEND_CREDENTIALS_TO_TIKV = FALSE; ### URI形式の説明 {#uri-format-description} -外部storageサービスの URI 形式は次のとおりです。 +外部ストレージサービスの URI 形式は次のとおりです。 ```shell [scheme]://[host]/[path]?[parameters] ``` -URI 形式の詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +URI 形式の詳細については、 [外部ストレージサービスのURI形式](/external-ストレージ-uri.md)参照してください。 ### URIの例 {#uri-examples} このセクションでは、 `host`パラメータとして`external` (前のセクションでは`bucket name`または`container name` ) を使用した URI の例をいくつか示します。 - +
**スナップショットデータをAmazon S3にバックアップする** ```shell tiup br backup full -u "${PD_IP}:2379" \ ---storage "s3://external/backup-20220915?access-key=${access-key}&secret-access-key=${secret-access-key}" +--ストレージ "s3://external/backup-20220915?access-key=${access-key}&secret-access-key=${secret-access-key}" ``` **Amazon S3からスナップショットデータを復元する** ```shell tiup br restore full -u "${PD_IP}:2379" \ ---storage "s3://external/backup-20220915?access-key=${access-key}&secret-access-key=${secret-access-key}" +--ストレージ "s3://external/backup-20220915?access-key=${access-key}&secret-access-key=${secret-access-key}" ```
@@ -67,14 +67,14 @@ tiup br restore full -u "${PD_IP}:2379" \ ```shell tiup br backup full --pd "${PD_IP}:2379" \ ---storage "gcs://external/backup-20220915?credentials-file=${credentials-file-path}" +--ストレージ "gcs://external/backup-20220915?credentials-file=${credentials-file-path}" ``` **GCSからスナップショットデータを復元する** ```shell tiup br restore full --pd "${PD_IP}:2379" \ ---storage "gcs://external/backup-20220915?credentials-file=${credentials-file-path}" +--ストレージ "gcs://external/backup-20220915?credentials-file=${credentials-file-path}" ``` @@ -84,14 +84,14 @@ tiup br restore full --pd "${PD_IP}:2379" \ ```shell tiup br backup full -u "${PD_IP}:2379" \ ---storage "azure://external/backup-20220915?account-name=${account-name}&account-key=${account-key}" +--ストレージ "azure://external/backup-20220915?account-name=${account-name}&account-key=${account-key}" ``` **Azure Blob Storage のスナップショット バックアップ データから`test`データベースを復元します。** ```shell tiup br restore db --db test -u "${PD_IP}:2379" \ ---storage "azure://external/backup-20220915account-name=${account-name}&account-key=${account-key}" +--ストレージ "azure://external/backup-20220915account-name=${account-name}&account-key=${account-key}" ``` @@ -99,9 +99,9 @@ tiup br restore db --db test -u "${PD_IP}:2379" \ ## 認証 {#authentication} -クラウドstorageシステムにバックアップデータを保存する場合、クラウドサービスプロバイダーに応じて認証パラメータを設定する必要があります。このセクションでは、Amazon S3、GCS、Azure Blob Storageで使用される認証方法と、それぞれのstorageサービスにアクセスするために使用するアカウントの設定方法について説明します。 +クラウドストレージシステムにバックアップデータを保存する場合、クラウドサービスプロバイダーに応じて認証パラメータを設定する必要があります。このセクションでは、Amazon S3、GCS、Azure Blob Storageで使用される認証方法と、それぞれのストレージサービスにアクセスするために使用するアカウントの設定方法について説明します。 - +
バックアップの前に、S3 上のバックアップ ディレクトリにアクセスするための次の権限を設定します。 @@ -132,7 +132,7 @@ tiup br restore db --db test -u "${PD_IP}:2379" \ ```shell tiup br backup full --pd "${PD_IP}:2379" \ - --storage "s3://${host}/${path}" + --ストレージ "s3://${host}/${path}" ```
@@ -197,14 +197,14 @@ GCSへのアクセスに使用するアカウントは、アクセスキーを ```shell tiup br backup full -u "${PD_IP}:2379" \ - --storage "azure://external/backup-20220915?account-name=${account-name}" + --ストレージ "azure://external/backup-20220915?account-name=${account-name}" ``` - 方法4: AzureマネージドIDを使用する v8.5.5 以降では、TiDB クラスターとBRが Azure 仮想マシン (VM) または Azure Kubernetes Service (AKS) 環境で実行されており、Azure マネージド ID がノードに割り当てられている場合は、認証に Azure マネージド ID を使用できます。 - この方法を使用する前に、 [Azureポータル](https://azure.microsoft.com/)内のターゲットstorageアカウントにアクセスするためのアクセス許可 ( `Storage Blob Data Contributor`など) が対応するマネージド ID に付与されていることを確認してください。 + この方法を使用する前に、 [Azureポータル](https://azure.microsoft.com/)内のターゲットストレージアカウントにアクセスするためのアクセス許可 ( `Storage Blob Data Contributor`など) が対応するマネージド ID に付与されていることを確認してください。 - **システム割り当てマネージド ID** : @@ -212,7 +212,7 @@ GCSへのアクセスに使用するアカウントは、アクセスキーを ```shell tiup br backup full -u "${PD_IP}:2379" \ - --storage "azure://external/backup-20220915?account-name=${account-name}" + --ストレージ "azure://external/backup-20220915?account-name=${account-name}" ``` > **注記：** @@ -257,7 +257,7 @@ GCSへのアクセスに使用するアカウントは、アクセスキーを ```shell tiup br backup full -u "${PD_IP}:2379" \ - --storage "azure://external/backup-20220915?account-name=${account-name}" + --ストレージ "azure://external/backup-20220915?account-name=${account-name}" ``` @@ -269,11 +269,11 @@ GCSへのアクセスに使用するアカウントは、アクセスキーを BR は、Amazon S3 へのデータバックアップ時にサーバー側暗号化をサポートします。また、 BRを使用して S3 のサーバー側暗号化用に作成した AWS KMS キーを使用することもできます。詳細については、 [BR S3 サーバー側暗号化](/encryption-at-rest.md#br-s3-server-side-encryption)参照してください。 -### Azure Blob Storage のサーバー側暗号化 {#azure-blob-storage-server-side-encryption} +### Azure Blob Storage のサーバー側暗号化 {#azure-blob-ストレージ-server-side-encryption} -BRは、Azure Blob Storageへのデータのバックアップ時に、Azureサーバー側暗号化スコープの指定、または暗号化キーの提供をサポートしています。この機能により、同じstorageアカウントの異なるバックアップデータに対してセキュリティ境界を確立できます。詳細については、 [BR Azure Blob Storage サーバー側暗号化](/encryption-at-rest.md#br-azure-blob-storage-server-side-encryption)ご覧ください。 +BRは、Azure Blob Storageへのデータのバックアップ時に、Azureサーバー側暗号化スコープの指定、または暗号化キーの提供をサポートしています。この機能により、同じストレージアカウントの異なるバックアップデータに対してセキュリティ境界を確立できます。詳細については、 [BR Azure Blob Storage サーバー側暗号化](/encryption-at-rest.md#br-azure-blob-ストレージ-server-side-encryption)ご覧ください。 -## storageサービスでサポートされているその他の機能 {#other-features-supported-by-the-storage-service} +## ストレージサービスでサポートされているその他の機能 {#other-features-supported-by-the-ストレージ-service} Amazon [S3 オブジェクトロック](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html) 、指定された保持期間中のバックアップデータの偶発的または意図的な削除を防ぎ、データのセキュリティと整合性を強化します。バージョン6.3.0以降、 BRはスナップショットバックアップでAmazon S3オブジェクトロックをサポートし、フルバックアップのレイヤーをさらに強化します。バージョン8.0.0以降、PITRもAmazon S3オブジェクトロックをサポートします。フルバックアップでもログデータバックアップでも、オブジェクトロック機能はより信頼性の高いデータ保護を実現し、データのバックアップとリカバリのセキュリティをさらに強化し、規制要件を満たします。 diff --git a/br/backup-and-restore-use-cases.md b/br/backup-and-restore-use-cases.md index 317423eefb6b6..6cc6ddac09e3b 100644 --- a/br/backup-and-restore-use-cases.md +++ b/br/backup-and-restore-use-cases.md @@ -1,6 +1,6 @@ --- title: TiDB Backup and Restore Use Cases -summary: TiDBは、タイムリーなデータリカバリやビジネス監査など、特定のユースケース向けにスナップショットおよびログバックアップソリューションを提供します。ポイントインタイムリカバリ（PITR）を使用するには、TiDBクラスター（v6.2.0以上）をデプロイし、 BRをTiDBクラスターと同じバージョンに更新してください。Amazon S3にバックアップstorageを設定し、データ損失とリカバリの要件を満たすバックアップポリシーを設定してください。ログバックアップとスナップショットバックアップを実行し、PITRを使用して特定の時点にデータを復元します。古くなったデータは定期的にクリーンアップしてください。詳細な手順については、TiDBのドキュメントをご覧ください。 +summary: TiDBは、タイムリーなデータリカバリやビジネス監査など、特定のユースケース向けにスナップショットおよびログバックアップソリューションを提供します。ポイントインタイムリカバリ（PITR）を使用するには、TiDBクラスター（v6.2.0以上）をデプロイし、 BRをTiDBクラスターと同じバージョンに更新してください。Amazon S3にバックアップストレージを設定し、データ損失とリカバリの要件を満たすバックアップポリシーを設定してください。ログバックアップとスナップショットバックアップを実行し、PITRを使用して特定の時点にデータを復元します。古くなったデータは定期的にクリーンアップしてください。詳細な手順については、TiDBのドキュメントをご覧ください。 --- # TiDB バックアップと復元のユースケース {#tidb-backup-and-restore-use-cases} @@ -14,13 +14,13 @@ AWS に TiDB本番クラスターをデプロイし、ビジネスチームが PITR を使用すると、前述の要件を満たすことができます。 -## TiDBクラスタとBRをデプロイ {#deploy-the-tidb-cluster-and-br} +## TiDBクラスターとBRをデプロイ {#deploy-the-tidb-cluster-and-br} -PITRを使用するには、TiDBクラスタ（v6.2.0以上）をデプロイし、 BRをTiDBクラスタと同じバージョンにアップデートする必要があります。このドキュメントでは、例としてv8.5.5を使用しています。 +PITRを使用するには、TiDBクラスター（v6.2.0以上）をデプロイし、 BRをTiDBクラスターと同じバージョンにアップデートする必要があります。このドキュメントでは、例としてv8.5.5を使用しています。 次の表は、TiDB クラスターで PITR を使用するために推奨されるハードウェア リソースを示しています。 -| 成分 | CPU | メモリ | ディスク | AWSインスタンス | インスタンス数 | +| コンポーネント | CPU | メモリ | ディスク | AWSインスタンス | インスタンス数 | | ---- | ----- | ------- | ---- | --------- | ------- | | TiDB | 8コア以上 | 16 GB以上 | SAS | c5.2特大 | 2 | | PD | 8コア以上 | 16 GB以上 | SSD | c5.2特大 | 3 | @@ -35,8 +35,8 @@ PITRを使用するには、TiDBクラスタ（v6.2.0以上）をデプロイし TiUPを使用して TiDB クラスターをデプロイまたはアップグレードします。 -- 新しい TiDB クラスターをデプロイするには、 [TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)を参照してください。 -- TiDB クラスターが v6.2.0 より前の場合は、 [TiDBクラスタのアップグレード](/upgrade-tidb-using-tiup.md)を参照してアップグレードしてください。 +- 新しい TiDB クラスターをデプロイするには、 [TiDBクラスターをデプロイ](/production-deployment-using-tiup.md)を参照してください。 +- TiDB クラスターが v6.2.0 より前の場合は、 [TiDBクラスターのアップグレード](/upgrade-tidb-using-tiup.md)を参照してアップグレードしてください。 TiUPを使用してBRをインストールまたはアップグレードします。 @@ -52,9 +52,9 @@ TiUPを使用してBRをインストールまたはアップグレードしま tiup update br:v8.5.5 ``` -## バックアップstorage（Amazon S3）を構成する {#configure-backup-storage-amazon-s3} +## バックアップストレージ（Amazon S3）を構成する {#configure-backup-ストレージ-amazon-s3} -バックアップ タスクを開始する前に、次の点を含めてバックアップstorageを準備します。 +バックアップ タスクを開始する前に、次の点を含めてバックアップストレージを準備します。 1. バックアップデータを保存する S3 バケットとディレクトリを準備します。 2. S3 バケットにアクセスするための権限を設定します。 @@ -87,11 +87,11 @@ TiUPを使用してBRをインストールまたはアップグレードしま ## ログバックアップを実行する {#run-log-backup} -ログバックアップタスクが開始されると、TiKVクラスター内でログバックアッププロセスが実行され、データベース内のデータ変更がS3storageに継続的に送信されます。ログバックアップタスクを開始するには、次のコマンドを実行します。 +ログバックアップタスクが開始されると、TiKVクラスター内でログバックアッププロセスが実行され、データベース内のデータ変更がS3ストレージに継続的に送信されます。ログバックアップタスクを開始するには、次のコマンドを実行します。 ```shell tiup br log start --task-name=pitr --pd="${PD_IP}:2379" \ ---storage='s3://tidb-pitr-bucket/backup-data/log-backup' +--ストレージ='s3://tidb-pitr-bucket/backup-data/log-backup' ``` ログ バックアップ タスクの実行中に、バックアップ ステータスを照会できます。 @@ -105,7 +105,7 @@ tiup br log status --task-name=pitr --pd="${PD_IP}:2379" status: ● NORMAL start: 2022-05-13 11:09:40.7 +0800 end: 2035-01-01 00:00:00 +0800 - storage: s3://tidb-pitr-bucket/backup-data/log-backup + ストレージ: s3://tidb-pitr-bucket/backup-data/log-backup speed(est.): 0.00 ops/s checkpoint[global]: 2022-05-13 11:31:47.2 +0800; gap=4m53s ``` @@ -120,7 +120,7 @@ crontabなどの自動ツールを使えば、スナップショットバック ```shell tiup br backup full --pd="${PD_IP}:2379" \ - --storage='s3://tidb-pitr-bucket/backup-data/snapshot-20220514000000' \ + --ストレージ='s3://tidb-pitr-bucket/backup-data/snapshot-20220514000000' \ --backupts='2022/05/14 00:00:00 +08:00' ``` @@ -128,7 +128,7 @@ crontabなどの自動ツールを使えば、スナップショットバック ```shell tiup br backup full --pd="${PD_IP}:2379" \ - --storage='s3://tidb-pitr-bucket/backup-data/snapshot-20220516000000' \ + --ストレージ='s3://tidb-pitr-bucket/backup-data/snapshot-20220516000000' \ --backupts='2022/05/16 00:00:00 +08:00' ``` @@ -140,8 +140,8 @@ crontabなどの自動ツールを使えば、スナップショットバック ```shell tiup br restore point --pd="${PD_IP}:2379" \ ---storage='s3://tidb-pitr-bucket/backup-data/log-backup' \ ---full-backup-storage='s3://tidb-pitr-bucket/backup-data/snapshot-20220514000000' \ +--ストレージ='s3://tidb-pitr-bucket/backup-data/log-backup' \ +--full-backup-ストレージ='s3://tidb-pitr-bucket/backup-data/snapshot-20220514000000' \ --restored-ts '2022-05-15 18:00:00+0800' Split&Scatter Region <--------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00% @@ -168,11 +168,11 @@ crontab などの自動ツールを使用して、2 日ごとに古いデータ - 2022/05/14 00:00:00より前のログバックアップデータを削除します ```shell - tiup br log truncate --until='2022-05-14 00:00:00 +0800' --storage='s3://tidb-pitr-bucket/backup-data/log-backup' + tiup br log truncate --until='2022-05-14 00:00:00 +0800' --ストレージ='s3://tidb-pitr-bucket/backup-data/log-backup' ``` ## 参照 {#see-also} -- [バックアップストレージ](/br/backup-and-restore-storages.md) +- [バックアップストレージ](/br/backup-and-restore-ストレージs.md) - [スナップショットのバックアップと復元コマンドマニュアル](/br/br-snapshot-manual.md) - [ログバックアップとPITRコマンドマニュアル](/br/br-pitr-manual.md) diff --git a/br/br-auto-tune.md b/br/br-auto-tune.md index 1651751b09c7f..b61071dadeff7 100644 --- a/br/br-auto-tune.md +++ b/br/br-auto-tune.md @@ -1,17 +1,17 @@ --- title: Backup Auto-Tune -summary: TiDB v5.4.0では、バックアップタスクの自動チューニング機能が導入され、デフォルトで有効になっています。この機能は、バックアップタスクが使用するリソースを制限し、クラスタへの影響を軽減します。この機能は、クラスタを再起動することなく、動的に有効化または無効化できます。ただし、自動チューニング機能の制限により、クラスタへのバックアップの影響を完全に排除できない場合があります。バックアップタスクで使用されるスレッド数を調整することで、特定のシナリオでの影響を軽減できる場合があります。 +summary: TiDB v5.4.0では、バックアップタスクの自動チューニング機能が導入され、デフォルトで有効になっています。この機能は、バックアップタスクが使用するリソースを制限し、クラスターへの影響を軽減します。この機能は、クラスターを再起動することなく、動的に有効化または無効化できます。ただし、自動チューニング機能の制限により、クラスターへのバックアップの影響を完全に排除できない場合があります。バックアップタスクで使用されるスレッド数を調整することで、特定のシナリオでの影響を軽減できる場合があります。 --- # バックアップオートチューンv5.4.0 の新機能 {#backup-auto-tune-span-class-version-mark-new-in-v5-4-0-span} TiDB v5.4.0より前のバージョンでは、バックアップ＆リストア（BR）を使用してデータをバックアップすると、バックアップに使用されるスレッド数が論理CPUコアの75%を占めていました。速度制限がない場合、バックアッププロセスは大量のクラスターリソースを消費し、オンラインクラスターのパフォーマンスに大きな影響を与える可能性があります。スレッドプールのサイズを調整することでバックアップの影響を軽減することはできますが、CPU負荷を監視し、手動でスレッドプールのサイズを調整するのは面倒な作業です。 -バックアップタスクがクラスタに与える影響を軽減するため、TiDB v5.4.0では自動チューニング機能が導入されました。この機能はデフォルトで有効になっています。クラスタリソースの使用率が高い場合、 BRはバックアップタスクが使用するリソースを自動的に制限し、クラスタへの影響を軽減します。自動チューニング機能はデフォルトで有効になっています。 +バックアップタスクがクラスターに与える影響を軽減するため、TiDB v5.4.0では自動チューニング機能が導入されました。この機能はデフォルトで有効になっています。クラスターリソースの使用率が高い場合、 BRはバックアップタスクが使用するリソースを自動的に制限し、クラスターへの影響を軽減します。自動チューニング機能はデフォルトで有効になっています。 ## 使用シナリオ {#usage-scenario} -バックアップタスクがクラスタに与える影響を軽減したい場合は、自動チューニング機能を有効にできます。この機能を有効にすると、TiDBはクラスタに過度の影響を与えることなく、可能な限り高速にバックアップタスクを実行します。 +バックアップタスクがクラスターに与える影響を軽減したい場合は、自動チューニング機能を有効にできます。この機能を有効にすると、TiDBはクラスターに過度の影響を与えることなく、可能な限り高速にバックアップタスクを実行します。 あるいは、TiKV設定項目[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)またはパラメータ`--ratelimit`を使用してバックアップ速度を制限することもできます。 `--ratelimit`設定されている場合、タスクが多すぎて速度制限を超えてしまうのを防ぐため、br のパラメータ`concurrency`自動的に`1`に調整されます。 @@ -39,7 +39,7 @@ tikv-ctl modify-tikv-config -n backup.enable-auto-tune -v 自動調整機能には、次の問題と対応する解決策があります。 -- 問題1：**書き込み負荷の高いクラスタ**では、自動チューニングによってワークロードとバックアップタスクが「正のフィードバックループ」に陥る可能性があります。つまり、バックアップタスクが過剰なリソースを消費し、クラスタが使用するリソースが少なくなるのです。この時点で、自動チューニングはクラスタのワークロードがそれほど高くないと誤って判断し、バックアップの実行速度を速めてしまう可能性があります。このような場合、自動チューニングは効果を発揮しません。 +- 問題1：**書き込み負荷の高いクラスター**では、自動チューニングによってワークロードとバックアップタスクが「正のフィードバックループ」に陥る可能性があります。つまり、バックアップタスクが過剰なリソースを消費し、クラスターが使用するリソースが少なくなるのです。この時点で、自動チューニングはクラスターのワークロードがそれほど高くないと誤って判断し、バックアップの実行速度を速めてしまう可能性があります。このような場合、自動チューニングは効果を発揮しません。 - 解決策：バックアップタスクで使用されるスレッド数を制限したい場合は、手動で`backup.num-threads`小さい数値に調整してください。動作原理は以下のとおりです。 diff --git a/br/br-batch-create-table.md b/br/br-batch-create-table.md index 57675fa561034..b16c6dcddc280 100644 --- a/br/br-batch-create-table.md +++ b/br/br-batch-create-table.md @@ -28,7 +28,7 @@ BRはデフォルトでバッチテーブル作成機能を有効にします。 ```shell tiup br restore full \ ---storage local:///br_data/ --pd "${PD_IP}:2379" --log-file restore.log \ +--ストレージ local:///br_data/ --pd "${PD_IP}:2379" --log-file restore.log \ --ddl-batch-size=1 ``` @@ -48,7 +48,7 @@ tiup br restore full \ このセクションでは、バッチテーブル作成機能に関するテスト情報について説明します。テスト環境は次のとおりです。 -- クラスタ構成: +- クラスター構成: - 15 個の TiKV インスタンス。各 TiKV インスタンスには、16 個の CPU コア、80 GB のメモリ、および RPC リクエストを処理するための 16 個のスレッド ( [`import.num-threads`](/tikv-configuration-file.md#num-threads) = 16) が搭載されています。 - 3 つの TiDB インスタンス。各 TiDB インスタンスには、16 個の CPU コアと 32 GB のメモリが搭載されています。 diff --git a/br/br-checkpoint-backup.md b/br/br-checkpoint-backup.md index 114d5899ffb4d..8a8f644f8cfc9 100644 --- a/br/br-checkpoint-backup.md +++ b/br/br-checkpoint-backup.md @@ -11,15 +11,15 @@ TiDB v6.5.0では、バックアップとリストア（BR）にチェックポ ## アプリケーションシナリオ {#application-scenarios} -TiDBクラスタが大規模で、障害発生後に再度バックアップを行う余裕がない場合は、チェックポイントバックアップ機能を使用できます。brコマンドラインツール（以下、 `br` ）は、バックアップ済みのシャードを定期的に記録します。これにより、次回のバックアップ再試行では、異常終了時のバックアップの進捗状況を使用できます。 +TiDBクラスターが大規模で、障害発生後に再度バックアップを行う余裕がない場合は、チェックポイントバックアップ機能を使用できます。brコマンドラインツール（以下、 `br` ）は、バックアップ済みのシャードを定期的に記録します。これにより、次回のバックアップ再試行では、異常終了時のバックアップの進捗状況を使用できます。 ## 実装の詳細 {#implementation-details} スナップショットバックアップ中、 `br`テーブルを対応するキー空間にエンコードし、バックアップRPCリクエストを生成してTiKVノードに送信します。バックアップリクエストを受信すると、TiKVノードは要求された範囲内のデータをバックアップします。TiKVノードは、リージョンのデータのバックアップを完了するたびに、この範囲のバックアップ情報を`br`に返します。 -`br` TiKV ノードから返された情報を記録し、 `br`バックアップされたキー範囲を取得するのに役立ちます。チェックポイント・バックアップ機能は、定期的に新しいバックアップ情報を外部storageにアップロードし、バックアップされたキー範囲を永続化します。 +`br` TiKV ノードから返された情報を記録し、 `br`バックアップされたキー範囲を取得するのに役立ちます。チェックポイント・バックアップ機能は、定期的に新しいバックアップ情報を外部ストレージにアップロードし、バックアップされたキー範囲を永続化します。 -`br`バックアップを再試行する際、外部storageからバックアップ済みのキー範囲を読み取り、バックアップタスクのキー範囲と比較します。この差分データは、 `br`チェックポイントバックアップでまだバックアップする必要があるキー範囲を特定するのに役立ちます。 +`br`バックアップを再試行する際、外部ストレージからバックアップ済みのキー範囲を読み取り、バックアップタスクのキー範囲と比較します。この差分データは、 `br`チェックポイントバックアップでまだバックアップする必要があるキー範囲を特定するのに役立ちます。 ## 使用制限 {#usage-limitations} @@ -35,7 +35,7 @@ TiDBクラスタが大規模で、障害発生後に再度バックアップを ```shell tiup br backup full \ ---storage local:///br_data/ --pd "${PD_IP}:2379" \ +--ストレージ local:///br_data/ --pd "${PD_IP}:2379" \ --gcttl 54000 ``` @@ -49,4 +49,4 @@ tiup br backup full \ - 中断の原因がエラーである場合、 `br`終了前にバックアップされたデータのメタ情報を保持します。この場合、次回の再試行では、バックアップ中のデータのみを再度バックアップする必要があります。 -- `br`プロセスがシステムによって中断された場合、 `br`外部storageにバックアップされたデータのメタ情報を永続化できません。5 `br` 30秒ごとにメタ情報を永続化するため、中断前の30秒間にバックアップされたデータは永続化できず、次回の再試行時に再度バックアップする必要があります。 +- `br`プロセスがシステムによって中断された場合、 `br`外部ストレージにバックアップされたデータのメタ情報を永続化できません。5 `br` 30秒ごとにメタ情報を永続化するため、中断前の30秒間にバックアップされたデータは永続化できず、次回の再試行時に再度バックアップする必要があります。 diff --git a/br/br-checkpoint-restore.md b/br/br-checkpoint-restore.md index f45180754207b..3220d8baa734c 100644 --- a/br/br-checkpoint-restore.md +++ b/br/br-checkpoint-restore.md @@ -11,17 +11,17 @@ TiDB v7.1.0以降、バックアップ＆リストア（BR）にチェックポ ## アプリケーションシナリオ {#application-scenarios} -TiDBクラスタが大規模で、障害発生後に再度リストアを行う余裕がない場合は、チェックポイントリストア機能を使用できます。brコマンドラインツール（以下、 `br` ）は、リストアされたシャードを定期的に記録します。これにより、次回のリストア再試行では、異常終了に近いリカバリ進捗ポイントを使用できます。 +TiDBクラスターが大規模で、障害発生後に再度リストアを行う余裕がない場合は、チェックポイントリストア機能を使用できます。brコマンドラインツール（以下、 `br` ）は、リストアされたシャードを定期的に記録します。これにより、次回のリストア再試行では、異常終了に近いリカバリ進捗ポイントを使用できます。 ## 実施原則 {#implementation-principles} -チェックポイント復元の実装は、スナップショット復元とログ復元の2つの部分に分かれています。詳細については、 [実装の詳細: チェックポイントデータを下流のクラスタに保存する](#implementation-details-store-checkpoint-data-in-the-downstream-cluster)と[実装の詳細: チェックポイントデータを外部storageに保存する](#implementation-details-store-checkpoint-data-in-the-external-storage)参照してください。 +チェックポイント復元の実装は、スナップショット復元とログ復元の2つの部分に分かれています。詳細については、 [実装の詳細: チェックポイントデータを下流のクラスターに保存する](#implementation-details-store-checkpoint-data-in-the-downstream-cluster)と[実装の詳細: チェックポイントデータを外部ストレージに保存する](#implementation-details-store-checkpoint-data-in-the-external-ストレージ)参照してください。 ### スナップショットの復元 {#snapshot-restore} -スナップショット復元の実装は[スナップショットバックアップ](/br/br-checkpoint-backup.md#implementation-details)と同様です。3 `br` 、キー範囲（リージョン）内のすべてのSSTファイルを一括して復元します。復元が完了すると、 `br`この範囲と復元されたクラスタテーブルのテーブルIDを記録します。チェックポイント復元機能は、復元されたキー範囲を永続化するために、新しい復元情報を定期的に外部storageにアップロードします。 +スナップショット復元の実装は[スナップショットバックアップ](/br/br-checkpoint-backup.md#implementation-details)と同様です。3 `br` 、キー範囲（リージョン）内のすべてのSSTファイルを一括して復元します。復元が完了すると、 `br`この範囲と復元されたクラスターテーブルのテーブルIDを記録します。チェックポイント復元機能は、復元されたキー範囲を永続化するために、新しい復元情報を定期的に外部ストレージにアップロードします。 -`br`復元を再試行する際、外部storageから復元されたキー範囲を読み取り、対応するテーブルIDと照合します。復元中、 `br`チェックポイント復元で記録されたキー範囲と重複し、同じテーブルIDを持つキー範囲をスキップします。 +`br`復元を再試行する際、外部ストレージから復元されたキー範囲を読み取り、対応するテーブルIDと照合します。復元中、 `br`チェックポイント復元で記録されたキー範囲と重複し、同じテーブルIDを持つキー範囲をスキップします。 `br`リストアを再試行する前にテーブルを削除した場合、再試行時に新しく作成されたテーブルのテーブルIDは、以前にチェックポイントリストアに記録されたテーブルIDと異なります。この場合、 `br`以前のチェックポイントリストア情報をバイパスし、テーブルを再度リストアします。つまり、新しいIDを持つ同じテーブルは、古いIDのチェックポイントリストア情報を無視し、新しいIDに対応する新しいチェックポイントリストア情報を記録することになります。 @@ -31,7 +31,7 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた ### ログの復元 {#log-restore} -ログリストアは、TiKVノードによってバックアップされたデータメタデータ（メタKV）をタイムスタンプ順に復元するプロセスです。チェックポイントリストアではまず、メタKVデータに基づいて、バックアップクラスタと復元されたクラスタ間の1対1のIDマッピング関係を確立します。これにより、メタKVのIDは複数回のリストア試行を通じて一貫性を保ち、メタKVを再度リストアできるようになります。 +ログリストアは、TiKVノードによってバックアップされたデータメタデータ（メタKV）をタイムスタンプ順に復元するプロセスです。チェックポイントリストアではまず、メタKVデータに基づいて、バックアップクラスターと復元されたクラスター間の1対1のIDマッピング関係を確立します。これにより、メタKVのIDは複数回のリストア試行を通じて一貫性を保ち、メタKVを再度リストアできるようになります。 スナップショットバックアップファイルとは異なり、ログバックアップファイルの範囲は重複する可能性があります。そのため、キー範囲を復旧進捗メタデータとして直接使用することはできません。また、ログバックアップファイルの数が多すぎる場合もあります。ただし、各ログバックアップファイルは、ログバックアップメタデータ内で固定の位置を持ちます。つまり、ログバックアップメタデータ内の一意の位置を、復旧進捗メタデータとして各ログバックアップファイルに割り当てることができます。 @@ -55,57 +55,57 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた - 中断の原因がエラーである場合、 `br`終了前に復元されたデータのメタ情報を保持します。この場合、次回の再試行では復元中のデータのみを再度復元する必要があります。 -- `br`プロセスがシステムによって中断された場合、 `br`外部storageに復元されたデータのメタ情報を永続化できません。5 `br` 30秒ごとにメタ情報を永続化するため、中断前の30秒間に復元されたデータは永続化できず、次回の再試行時に再度復元する必要があります。 +- `br`プロセスがシステムによって中断された場合、 `br`外部ストレージに復元されたデータのメタ情報を永続化できません。5 `br` 30秒ごとにメタ情報を永続化するため、中断前の30秒間に復元されたデータは永続化できず、次回の再試行時に再度復元する必要があります。 -### 復元中にクラスタデータを変更しないようにする {#avoid-modifying-cluster-data-during-the-restore} +### 復元中にクラスターデータを変更しないようにする {#avoid-modifying-cluster-data-during-the-restore} -リストアに失敗した後は、クラスタ内でのテーブルの書き込み、削除、または作成は避けてください。バックアップデータには、テーブル名変更のためのDDL操作が含まれている可能性があるためです。クラスタデータを変更すると、チェックポイントリストアでは、削除されたテーブルまたは既存のテーブルが外部操作によるものかどうかを判断できず、次回のリストア再試行の精度に影響します。 +リストアに失敗した後は、クラスター内でのテーブルの書き込み、削除、または作成は避けてください。バックアップデータには、テーブル名変更のためのDDL操作が含まれている可能性があるためです。クラスターデータを変更すると、チェックポイントリストアでは、削除されたテーブルまたは既存のテーブルが外部操作によるものかどうかを判断できず、次回のリストア再試行の精度に影響します。 ### クロスメジャーバージョンのチェックポイントリカバリは推奨されません {#cross-major-version-checkpoint-recovery-is-not-recommended} メジャーバージョン間のチェックポイントリカバリは推奨されません。v8.5.0より前のLong-Term Support (LTS)バージョンを使用して`br`リカバリが失敗したクラスターの場合、v8.5.0以降のLTSバージョンを使用してリカバリを続行することはできません。また、その逆も同様です。 -## 実装の詳細: チェックポイントデータを下流のクラスタに保存する {#implementation-details-store-checkpoint-data-in-the-downstream-cluster} +## 実装の詳細: チェックポイントデータを下流のクラスターに保存する {#implementation-details-store-checkpoint-data-in-the-downstream-cluster} > **注記：** > -> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。1パラメータを使用して`--checkpoint-storage`チェックポイントデータのstorageを指定できます。 +> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。1パラメータを使用して`--checkpoint-ストレージ`チェックポイントデータのストレージを指定できます。 チェックポイント復元操作は、スナップショット復元と PITR 復元の 2 つの部分に分かれています。 ### スナップショットの復元 {#snapshot-restore} -初期復元中に、 `br`ターゲットクラスタに`__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、上流クラスタID、およびバックアップデータの BackupTS が記録されます。 +初期復元中に、 `br`ターゲットクラスターに`__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、上流クラスターID、およびバックアップデータの BackupTS が記録されます。 復元が失敗した場合は、同じコマンドを使用して再試行できます。1 `br` `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 -復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、 `br`エラーを報告します。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。 +復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスターに復元しようとすると、 `br`エラーを報告します。これは、現在の上流クラスターIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスターがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。 ### PITR復元 {#pitr-restore} [PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)スナップショットの復元フェーズとログの復元フェーズで構成されます。 -初期リストアでは、 `br`スナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。 +初期リストアでは、 `br`スナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスターID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `__TiDB_BR_Temporary_Snapshot_Restore_Checkpoint`データベースに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。 初期復元中にログ復元フェーズに入ると、 `br`ターゲットクラスターに`__TiDB_BR_Temporary_Log_Restore_Checkpoint`データベースを作成します。このデータベースには、チェックポイントデータ、アップストリームクラスターID、および復元時間範囲（ `start-ts`と`restored-ts` ）が記録されます。このフェーズで復元に失敗した場合は、再試行時にチェックポイントデータベースに記録されているのと同じ`start-ts`と`restored-ts`指定する必要があります。そうでない場合、 `br`エラーを報告し、現在指定されている復元時間範囲またはアップストリームクラスターIDがチェックポイントレコードと異なることを通知します。復元クラスターがクリーンアップされている場合は、 `__TiDB_BR_Temporary_Log_Restore_Checkpoint`データベースを手動で削除し、別のバックアップで再試行できます。 -初期リストア中のログリストアフェーズに入る前に、 `br` `restored-ts`時点における上流および下流のクラスタデータベースとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、システムテーブル`mysql.tidb_pitr_id_map`に保存されます。mysql.tidb_pitr_id_map**からデータを恣意的に削除すると`mysql.tidb_pitr_id_map` PITRリストアデータの不整合が発生する可能性があります。** +初期リストア中のログリストアフェーズに入る前に、 `br` `restored-ts`時点における上流および下流のクラスターデータベースとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、システムテーブル`mysql.tidb_pitr_id_map`に保存されます。mysql.tidb_pitr_id_map**からデータを恣意的に削除すると`mysql.tidb_pitr_id_map` PITRリストアデータの不整合が発生する可能性があります。** > **注記：** > > 以前のバージョンのクラスターとの互換性を確保するため、v8.5.5以降では、復元クラスターにシステムテーブル`mysql.tidb_pitr_id_map`存在しない場合、 `pitr_id_map`データがログバックアップディレクトリに書き込まれます。ファイル名は`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`です。 -## 実装の詳細: チェックポイントデータを外部storageに保存する {#implementation-details-store-checkpoint-data-in-the-external-storage} +## 実装の詳細: チェックポイントデータを外部ストレージに保存する {#implementation-details-store-checkpoint-data-in-the-external-ストレージ} > **注記：** > -> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。1パラメータを使用して`--checkpoint-storage`チェックポイントデータの外部storageを指定できます。例： +> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。1パラメータを使用して`--checkpoint-ストレージ`チェックポイントデータの外部ストレージを指定できます。例： > > ```shell -> ./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-storage "s3://temp-bucket/checkpoints" +> ./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-ストレージ "s3://temp-bucket/checkpoints" > ``` -外部storageでは、チェックポイント データのディレクトリ構造は次のようになります。 +外部ストレージでは、チェックポイント データのディレクトリ構造は次のようになります。 - ルート パス`restore-{downstream-cluster-ID}` 、ダウンストリーム クラスター ID `{downstream-cluster-ID}`を使用して、異なる復元クラスターを区別します。 - パス`restore-{downstream-cluster-ID}/log`は、ログ復元フェーズ中にログ ファイルのチェックポイント データが保存されます。 @@ -141,22 +141,22 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた ### スナップショットの復元 {#snapshot-restore} -初期復元中に、 `br`指定された外部storageに`restore-{downstream-cluster-ID}/snapshot`パス`br`作成します。このパスには、チェックポイントデータ、上流クラスタID、およびバックアップデータのBackupTSが記録されます。 +初期復元中に、 `br`指定された外部ストレージに`restore-{downstream-cluster-ID}/snapshot`パス`br`作成します。このパスには、チェックポイントデータ、上流クラスターID、およびバックアップデータのBackupTSが記録されます。 -復元が失敗した場合は、同じコマンドを使用して再試行できます。1 `br` 、指定された外部storageパスからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 +復元が失敗した場合は、同じコマンドを使用して再試行できます。1 `br` 、指定された外部ストレージパスからチェックポイント情報を自動的に読み取り、最後の復元ポイントから再開します。 -復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスタに復元しようとすると、エラーコード`br`報告されます。これは、現在の上流クラスタIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスタがすでにクリーンアップされている場合は、外部storage内のチェックポイントデータを手動でクリーンアップするか、チェックポイントデータを保存する別の外部storageパスを指定して、別のバックアップで再試行してください。 +復元に失敗し、異なるチェックポイント情報を持つバックアップデータを同じクラスターに復元しようとすると、エラーコード`br`報告されます。これは、現在の上流クラスターIDまたはBackupTSがチェックポイントレコードと異なることを示しています。復元クラスターがすでにクリーンアップされている場合は、外部ストレージ内のチェックポイントデータを手動でクリーンアップするか、チェックポイントデータを保存する別の外部ストレージパスを指定して、別のバックアップで再試行してください。 ### PITR復元 {#pitr-restore} [PITR（ポイントインタイムリカバリ）](/br/br-pitr-guide.md)スナップショットの復元フェーズとログの復元フェーズで構成されます。 -初期リストアでは、 `br`スナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスタID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `restore-{downstream-cluster-ID}/snapshot`パスに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。 +初期リストアでは、 `br`スナップショットリストアフェーズに入ります。BRは、チェックポイントデータ、上流クラスターID、バックアップデータのBackupTS（つまり、ログリストアの開始時点`start-ts` ）、およびログリストアの復元時点`restored-ts` `restore-{downstream-cluster-ID}/snapshot`パスに記録します。このフェーズでリストアに失敗した場合、チェックポイントリストアを再開する際に、ログリストアの`start-ts`と`restored-ts`を調整することはできません。 -初期復元中にログ復元フェーズに入ると、 `br`​​指定された外部storageに`restore-{downstream-cluster-ID}/log`パスを作成します。このパスには、チェックポイント データ、アップストリーム クラスタ ID、および復元時間範囲 ( `start-ts`と`restored-ts` ) が記録されます。このフェーズで復元が失敗した場合は、再試行時にチェックポイント データベースに記録されているのと同じ`start-ts`と`restored-ts`指定する必要があります。そうでない場合、 `br`はエラーを報告し、現在指定されている復元時間範囲またはアップストリーム クラスタ ID がチェックポイント レコードと異なることを通知します。復元クラスタがクリーンアップされている場合は、外部storage内のチェックポイント データを手動でクリーンアップするか、チェックポイント データを保存するための別の外部storageパスを指定して、別のバックアップで再試行できます。 +初期復元中にログ復元フェーズに入ると、 `br`​​指定された外部ストレージに`restore-{downstream-cluster-ID}/log`パスを作成します。このパスには、チェックポイント データ、アップストリーム クラスター ID、および復元時間範囲 ( `start-ts`と`restored-ts` ) が記録されます。このフェーズで復元が失敗した場合は、再試行時にチェックポイント データベースに記録されているのと同じ`start-ts`と`restored-ts`指定する必要があります。そうでない場合、 `br`はエラーを報告し、現在指定されている復元時間範囲またはアップストリーム クラスター ID がチェックポイント レコードと異なることを通知します。復元クラスターがクリーンアップされている場合は、外部ストレージ内のチェックポイント データを手動でクリーンアップするか、チェックポイント データを保存するための別の外部ストレージパスを指定して、別のバックアップで再試行できます。 -初期リストア中のログリストアフェーズに入る前に、 `br` `restored-ts`時点における上流クラスタと下流クラスタのデータベースIDとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、ファイル名`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`でチェックポイントstorageに保存されます。pitr_id_maps **`pitr_id_maps`からファイルを恣意的に削除すると、PITR リストアデータの不整合が発生する可能性があります。** +初期リストア中のログリストアフェーズに入る前に、 `br` `restored-ts`時点における上流クラスターと下流クラスターのデータベースIDとテーブルIDのマッピングを構築することに注意してください。このマッピングは、データベースIDとテーブルIDの重複割り当てを防ぐため、ファイル名`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`でチェックポイントストレージに保存されます。pitr_id_maps **`pitr_id_maps`からファイルを恣意的に削除すると、PITR リストアデータの不整合が発生する可能性があります。** > **注記：** > -> 以前のバージョンのクラスターとの互換性を確保するため、v8.5.5以降では、復元クラスターにシステムテーブル`mysql.tidb_pitr_id_map`が存在せず、パラメータ`--checkpoint-storage`が指定されていない場合、 `pitr_id_map`データはログバックアップディレクトリに書き込まれます。ファイル名は`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`です。 +> 以前のバージョンのクラスターとの互換性を確保するため、v8.5.5以降では、復元クラスターにシステムテーブル`mysql.tidb_pitr_id_map`が存在せず、パラメータ`--checkpoint-ストレージ`が指定されていない場合、 `pitr_id_map`データはログバックアップディレクトリに書き込まれます。ファイル名は`pitr_id_maps/pitr_id_map.cluster_id:{downstream-cluster-ID}.restored_ts:{restored-ts}`です。 diff --git a/br/br-compact-log-backup.md b/br/br-compact-log-backup.md index 8b865d76e2a66..6d4728447ca57 100644 --- a/br/br-compact-log-backup.md +++ b/br/br-compact-log-backup.md @@ -18,12 +18,12 @@ summary: ログ バックアップを SST 形式に圧縮することで、ポ バージョン8.5.5以降、コンパクトログバックアップ機能にオフラインコンパクション機能が追加され、非構造化ログバックアップデータを構造化SSTファイルに変換できるようになりました。これにより、以下の改善がもたらされます。 - SST ファイルをクラスターに迅速にインポートできるため、**リカバリ パフォーマンスが向上します**。 -- 圧縮中に冗長データが削除され、**storageスペースの消費量が削減されます**。 +- 圧縮中に冗長データが削除され、**ストレージスペースの消費量が削減されます**。 - リカバリ時間目標 (RTO) を確保しながら、より長い完全バックアップ間隔を設定できるため、**アプリケーションへの影響を軽減できます**。 ## 制限事項 {#limitations} -- コンパクトログバックアップは完全バックアップの代替手段ではありません。定期的な完全バックアップと併用する必要があります。PITR機能を確保するため、圧縮プロセスではすべてのMVCCバージョンが保持されます。完全バックアップを長期間実行しないと、storage使用量が過剰になり、後でデータを復元する際に問題が発生する可能性があります。 +- コンパクトログバックアップは完全バックアップの代替手段ではありません。定期的な完全バックアップと併用する必要があります。PITR機能を確保するため、圧縮プロセスではすべてのMVCCバージョンが保持されます。完全バックアップを長期間実行しないと、ストレージ使用量が過剰になり、後でデータを復元する際に問題が発生する可能性があります。 - 現在、ローカル暗号化を有効にしたバックアップの圧縮はサポートされていません。 ## コンパクトログバックアップを使用する {#use-compact-log-backup} @@ -38,22 +38,22 @@ summary: ログ バックアップを SST 形式に圧縮することで、ポ ログ バックアップを手動で圧縮するには、 `tikv-ctl`と`br` 2 つのツールが必要です。 -#### ステップ1:storageをBase64でエンコードする {#step-1-encode-storage-to-base64} +#### ステップ1:ストレージをBase64でエンコードする {#step-1-encode-ストレージ-to-base64} 次のエンコード コマンドを実行します。 ```shell -br operator base64ify --storage "s3://your/log/backup/storage/here" --load-creds +br operator base64ify --ストレージ "s3://your/log/backup/ストレージ/here" --load-creds ``` > **注記：** > > - 上記のコマンドを実行する際にオプション`--load-creds`を指定した場合、エンコードされたBase64文字列には、現在のBR環境から読み込まれた認証情報が含まれます。適切なセキュリティとアクセス制御を確保するためにご注意ください。 -> - `--storage`値は、ログ バックアップ タスクの`log status`コマンドからのstorage出力と一致します。 +> - `--ストレージ`値は、ログ バックアップ タスクの`log status`コマンドからのストレージ出力と一致します。 #### ステップ2: ログ圧縮を実行する {#step-2-execute-log-compaction} -Base64エンコードstorageでは、 `tikv-ctl`で圧縮を開始できます。デフォルトのログレベルは`tikv-ctl`ですが、 `warning`です。より詳細な情報を取得するには`--log-level info`使用してください。 +Base64エンコードストレージでは、 `tikv-ctl`で圧縮を開始できます。デフォルトのログレベルは`tikv-ctl`ですが、 `warning`です。より詳細な情報を取得するには`--log-level info`使用してください。 ```shell tikv-ctl --log-level info compact-log-backup \ @@ -63,7 +63,7 @@ tikv-ctl --log-level info compact-log-backup \ パラメータの説明: -- `-s` : 先ほど取得した Base64 でエンコードされたstorage文字列。 +- `-s` : 先ほど取得した Base64 でエンコードされたストレージ文字列。 - `-N` : 同時ログ圧縮タスクの最大数。 - `--from` : 圧縮の開始タイムスタンプ。 - `--until` : 圧縮の終了タイムスタンプ。 diff --git a/br/br-incremental-guide.md b/br/br-incremental-guide.md index 02dd3ca0af672..f0b55d789c2b3 100644 --- a/br/br-incremental-guide.md +++ b/br/br-incremental-guide.md @@ -28,21 +28,21 @@ TiDBクラスターの増分データは、期間の開始スナップショッ 増分データをバックアップするには、 `tiup br backup`コマンドを、**最終バックアップのタイムスタンプ**`--lastbackupts`を指定して実行します。これにより、br コマンドラインツールは`lastbackupts`から現在時刻の間に生成された増分データを自動的にバックアップします。9 `--lastbackupts`取得するには、 `validate`コマンドを実行します。以下は例です。 ```shell -LAST_BACKUP_TS=`tiup br validate decode --field="end-version" --storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"| tail -n1` +LAST_BACKUP_TS=`tiup br validate decode --field="end-version" --ストレージ "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}"| tail -n1` ``` 次のコマンドは、 `(LAST_BACKUP_TS, current PD timestamp]`とこの期間中に生成された DDL 間の増分データをバックアップします。 ```shell tiup br backup full --pd "${PD_IP}:2379" \ ---storage "s3://backup-101/snapshot-202209081330/incr?access-key=${access-key}&secret-access-key=${secret-access-key}" \ +--ストレージ "s3://backup-101/snapshot-202209081330/incr?access-key=${access-key}&secret-access-key=${secret-access-key}" \ --lastbackupts ${LAST_BACKUP_TS} \ --ratelimit 128 ``` - `--lastbackupts` : 最後のバックアップのタイムスタンプ。 - `--ratelimit` : バックアップ タスクを実行する**TiKV あたりの**最大速度 (MiB/秒)。 -- `storage` : バックアップデータのstorageパス。増分バックアップデータは、前回のスナップショットバックアップとは異なるパスに保存する必要があります。上記の例では、増分バックアップデータはフルバックアップデータの下の`incr`ディレクトリに保存されます。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `ストレージ` : バックアップデータのストレージパス。増分バックアップデータは、前回のスナップショットバックアップとは異なるパスに保存する必要があります。上記の例では、増分バックアップデータはフルバックアップデータの下の`incr`ディレクトリに保存されます。詳細は[外部ストレージサービスのURI形式](/external-ストレージ-uri.md)参照してください。 ## 増分データを復元する {#restore-incremental-data} @@ -52,12 +52,12 @@ tiup br backup full --pd "${PD_IP}:2379" \ ```shell tiup br restore full --pd "${PD_IP}:2379" \ ---storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" +--ストレージ "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" ``` 次のコマンドは、 `backup-101/snapshot-202209081330/incr`ディレクトリに保存されている増分バックアップ データを復元します。 ```shell tiup br restore full --pd "${PD_IP}:2379" \ ---storage "s3://backup-101/snapshot-202209081330/incr?access-key=${access-key}&secret-access-key=${secret-access-key}" +--ストレージ "s3://backup-101/snapshot-202209081330/incr?access-key=${access-key}&secret-access-key=${secret-access-key}" ``` diff --git a/br/br-log-architecture.md b/br/br-log-architecture.md index 247dbfdacf4c6..e91b46e4f116d 100644 --- a/br/br-log-architecture.md +++ b/br/br-log-architecture.md @@ -15,7 +15,7 @@ summary: TiDBのログバックアップとPITRアーキテクチャは、バッ ## ログバックアップのプロセス {#process-of-log-backup} -クラスタログのバックアップ手順は以下のとおりです。 +クラスターログのバックアップ手順は以下のとおりです。 ```mermaid sequenceDiagram @@ -50,16 +50,16 @@ sequenceDiagram ログバックアッププロセスに関わるシステムコンポーネントと主要概念： - **ローカルメタデータ**：ローカルチェックポイントts、グローバルチェックポイントts、バックアップファイル情報など、単一のTiKVノードによってバックアップされたメタデータを示します。 -- **ローカルチェックポイント ts** (ローカルメタデータ内): この TiKV ノードでローカルチェックポイント ts より前に生成されたすべてのログがターゲットstorageにバックアップされたことを示します。 -- **グローバルチェックポイント ts** ：すべての TiKV ノードでグローバルチェックポイント ts より前に生成されたすべてのログがターゲットstorageにバックアップされたことを示します。TiDB コーディネーターは、すべての TiKV ノードのローカルチェックポイント ts を収集してこのタイムスタンプを計算し、PD に報告します。 +- **ローカルチェックポイント ts** (ローカルメタデータ内): この TiKV ノードでローカルチェックポイント ts より前に生成されたすべてのログがターゲットストレージにバックアップされたことを示します。 +- **グローバルチェックポイント ts** ：すべての TiKV ノードでグローバルチェックポイント ts より前に生成されたすべてのログがターゲットストレージにバックアップされたことを示します。TiDB コーディネーターは、すべての TiKV ノードのローカルチェックポイント ts を収集してこのタイムスタンプを計算し、PD に報告します。 - **TiDBコーディネーター**：TiDBノードがコーディネーターとして選出され、ログバックアップタスク全体（グローバルチェックポイントタスク）の進捗状況を収集および計算する役割を担います。このコンポーネントはステートレスな設計となっており、障害発生後は、稼働中のTiDBノードから新しいコーディネーターが選出されます。 -- **TiKVログバックアップオブザーバー**：TiDBクラスタ内の各TiKVノードで実行され、ログデータのバックアップを担当します。TiKVノードに障害が発生した場合、リージョン再選出後、そのノード上のデータ範囲のバックアップは他のTiKVノードによって引き継がれ、これらのノードはグローバルチェックポイントtsから始まる障害範囲のデータをバックアップします。 +- **TiKVログバックアップオブザーバー**：TiDBクラスター内の各TiKVノードで実行され、ログデータのバックアップを担当します。TiKVノードに障害が発生した場合、リージョン再選出後、そのノード上のデータ範囲のバックアップは他のTiKVノードによって引き継がれ、これらのノードはグローバルチェックポイントtsから始まる障害範囲のデータをバックアップします。 バックアップの全手順は以下のとおりです。 1. BR は`br log start`コマンドを受信します。 - - BRは、バックアップタスクのチェックポイントts（ログバックアップの開始時刻）とstorageパスを解析します。 + - BRは、バックアップタスクのチェックポイントts（ログバックアップの開始時刻）とストレージパスを解析します。 - **ログバックアップタスクの登録**： BRはPDにログバックアップタスクを登録します。 2. TiKVは、ログバックアップタスクの作成と更新を監視します。 @@ -71,7 +71,7 @@ sequenceDiagram - **Read kv Change data** : KV 変更データを読み取り、変更ログ[カスタム形式でバックアップファイル](#log-backup-files)に保存します。 - **グローバルチェックポイントtsの取得**：PDからグローバルチェックポイントtsを取得します。 - **ローカルメタデータの生成**：ローカルチェックポイントts、グローバルチェックポイントts、バックアップファイル情報など、バックアップタスクのローカルメタデータを生成します。 - - **ログデータとメタデータのアップロード**：バックアップファイルとローカルメタデータを定期的にターゲットstorageにアップロードします。 + - **ログデータとメタデータのアップロード**：バックアップファイルとローカルメタデータを定期的にターゲットストレージにアップロードします。 - **GC の設定**: PD に対して、バックアップされていないデータ (ローカル チェックポイント ts より大きいデータ) が[TiDB GCメカニズム](/garbage-collection-overview.md)によって再利用されないように要求します。 4. TiDBコーディネーターは、ログバックアップタスクの進行状況を監視します。 @@ -132,8 +132,8 @@ PITRの全プロセスは以下のとおりです。 5. TiKVはログバックアップデータを復元します。 - - **KVのダウンロード**：ログ復元ワーカーは、ログ復元要求に従って、バックアップstorageから対応するバックアップデータをローカルディレクトリにダウンロードします。 - - **KVの書き換え**：ログ復元ワーカーは、復元クラスタテーブルのテーブルIDに基づいてバックアップデータのKVデータを書き換えます。つまり、 [キー値](/tidb-computing.md#mapping-table-data-to-key-value)内の元のテーブルIDを新しいテーブルIDに置き換えます。復元ワーカーは、インデックスIDも同様に書き換えます。 + - **KVのダウンロード**：ログ復元ワーカーは、ログ復元要求に従って、バックアップストレージから対応するバックアップデータをローカルディレクトリにダウンロードします。 + - **KVの書き換え**：ログ復元ワーカーは、復元クラスターテーブルのテーブルIDに基づいてバックアップデータのKVデータを書き換えます。つまり、 [キー値](/tidb-computing.md#mapping-table-data-to-key-value)内の元のテーブルIDを新しいテーブルIDに置き換えます。復元ワーカーは、インデックスIDも同様に書き換えます。 - **KVの適用**：ログ復元ワーカーは、処理されたKVデータをRaftインターフェースを介してストア（RocksDB）に書き込みます。 - **レポート復元結果**: ログ復元ワーカーは復元結果をBRに返します。 @@ -150,7 +150,7 @@ PITRの全プロセスは以下のとおりです。 - `{flushTs}-{minDefaultTs}-{minTs}-{maxTs}.meta`ファイル: 各 TiKV ノードがログ バックアップ データをアップロードするたびに生成され、今回アップロードされたすべてのログ バックアップ データ ファイルのメタデータが保存されます。ファイル名の各フィールドの意味については、[バックアップファイルの構造](#structure-of-backup-files)参照してください。 - `{store_id}.ts`ファイル: 各 TiKV ノードがログバックアップデータをアップロードするたびに、グローバルチェックポイント ts で更新されます。 `{store_id}`は TiKV ノードのストア ID です。 - `{min_ts}-{uuid}.log`ファイル: バックアップ タスクの KV 変更ログ データを格納します。 `{min_ts}`は、ファイル内の KV 変更ログ データの最小 TSO タイムスタンプであり、 `{uuid}`はファイル作成時にランダムに生成されます。 -- `v1_stream_truncate_safepoint.txt`ファイル: `br log truncate`によって削除されたstorage内の最新のバックアップデータに対応するタイムスタンプを保存します。 +- `v1_stream_truncate_safepoint.txt`ファイル: `br log truncate`によって削除されたストレージ内の最新のバックアップデータに対応するタイムスタンプを保存します。 ### バックアップファイルの構造 {#structure-of-backup-files} @@ -172,15 +172,15 @@ PITRの全プロセスは以下のとおりです。 - `backupmeta`ディレクトリ: バックアップメタデータファイルを保存します。v8.5.3 以降、これらのファイルの命名規則は`{resolved_ts}-{uuid}.meta`から`{flushTs}-{minDefaultTs}-{minTs}-{maxTs}.meta`に変更されます。ファイル名には、次のタイムスタンプフィールドが含まれます。 - - `flushTs` : バックアップファイルが定期的に外部storageにアップロードされる際のタイムスタンプ。この値はPDから取得され、グローバルに一意です。 + - `flushTs` : バックアップファイルが定期的に外部ストレージにアップロードされる際のタイムスタンプ。この値はPDから取得され、グローバルに一意です。 - `minDefaultTs` （書き込みCFファイルのみに適用）：このバックアップでカバーされる最も早いトランザクション開始時刻。 - `minTs`および`maxTs` : バックアップ ファイルに含まれるすべてのキー値データの最小および最大タイムスタンプ。 - これらのタイムスタンプはすべて、長さが一定になるように左側にゼロを埋め込んだ、固定長の16桁の16進数文字列としてエンコードされます。このエンコード方式により、ファイル名が自然に辞書順にソートされるため、外部storageシステムでのバッチリスト表示や範囲フィルタリング操作を効率的に実行できます。 + これらのタイムスタンプはすべて、長さが一定になるように左側にゼロを埋め込んだ、固定長の16桁の16進数文字列としてエンコードされます。このエンコード方式により、ファイル名が自然に辞書順にソートされるため、外部ストレージシステムでのバッチリスト表示や範囲フィルタリング操作を効率的に実行できます。 - `global_checkpoint` : グローバルバックアップの進行状況を表します。これは`br restore point`を使用してデータを復元できる最新の時点を記録します。 -- `{date}/{hour}` ：対応する日付と時刻のバックアップデータを保存します。storageをクリーンアップする際は、手動でデータを削除するのではなく、必ず`br log truncate`を使用してください。これは、メタデータがこのディレクトリ内のデータを参照しているため、手動で削除すると復元失敗や復元後のデータ不整合が発生する可能性があるためです。 +- `{date}/{hour}` ：対応する日付と時刻のバックアップデータを保存します。ストレージをクリーンアップする際は、手動でデータを削除するのではなく、必ず`br log truncate`を使用してください。これは、メタデータがこのディレクトリ内のデータを参照しているため、手動で削除すると復元失敗や復元後のデータ不整合が発生する可能性があるためです。 以下は一例です。 diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md index a967364400780..a9f8a5757437d 100644 --- a/br/br-monitoring-and-alert.md +++ b/br/br-monitoring-and-alert.md @@ -18,7 +18,7 @@ summary: このドキュメントでは、ログバックアップの監視、 ### 監視構成 {#monitoring-configuration} - TiUPを使用してデプロイされたクラスターの場合、Prometheus は監視メトリックを自動的に収集します。 -- 手動でデプロイされたクラスターの場合は、 [TiDBクラスタ監視の展開](/deploy-monitoring-services.md)の手順に従って、Prometheus 構成ファイルの`scrape_configs`セクションに TiKV 関連のジョブを追加します。 +- 手動でデプロイされたクラスターの場合は、 [TiDBクラスター監視の展開](/deploy-monitoring-services.md)の手順に従って、Prometheus 構成ファイルの`scrape_configs`セクションに TiKV 関連のジョブを追加します。 ### Grafanaの設定 {#grafana-configuration} @@ -42,7 +42,7 @@ summary: このドキュメントでは、ログバックアップの監視、 | **tikv_log_backup_on_event_duration_seconds** | ヒストグラム | KV イベントを一時ファイルに保存する期間。
`stage :: {"write_to_tempfile", "syscall_write"}` | | **tikv_log_backup_store_checkpoint_ts** | ゲージ | ストアレベルのチェックポイントTSは非推奨です。現在のストアによって登録されたGCセーフポイントに近いです。
`task :: string` | | **tidb_log_backup_last_checkpoint** | ゲージ | グローバルチェックポイントTS。ログデータがバックアップされている時点です。
`task :: string` | -| **tikv_log_backup_flush_duration_sec** | ヒストグラム | ローカルの一時ファイルを外部storageに移動する時間。
`stage :: {"generate_metadata", "save_files", "clear_temp_files"}` | +| **tikv_log_backup_flush_duration_sec** | ヒストグラム | ローカルの一時ファイルを外部ストレージに移動する時間。
`stage :: {"generate_metadata", "save_files", "clear_temp_files"}` | | **tikv_log_backup_flush_file_size** | ヒストグラム | バックアップ中に生成されたファイルのサイズの統計。 | | **tikv_log_backup_initial_scan_duration_sec** | ヒストグラム | 初期スキャンの全体的な所要時間の統計。 | | **tikv_log_backup_skip_retry_observe** | カウンタ | ログ バックアップ中に無視できるエラーの統計、または再試行がスキップされる理由。
`reason :: {"region-absent", "not-leader", "stale-command"}` | @@ -70,7 +70,7 @@ PITR でアラート項目を構成するには、次の手順に従います。 - 警告項目: `max(time() - tidb_log_backup_last_checkpoint / 262144000) by (task) / 60 > 10 and max(tidb_log_backup_last_checkpoint) by (task) > 0 and max(tikv_log_backup_task_status) by (task) == 0` - 警戒レベル：警告 -- 説明: ログデータが10分以上storageに保存されていません。このアラートはリマインダーです。ほとんどの場合、ログバックアップには影響しません。 +- 説明: ログデータが10分以上ストレージに保存されていません。このアラートはリマインダーです。ほとんどの場合、ログバックアップには影響しません。 このアラート項目の構成サンプルは次のとおりです。 @@ -91,7 +91,7 @@ groups: - 警告項目: `max(time() - tidb_log_backup_last_checkpoint / 262144000) by (task) / 60 > 30 and max(tidb_log_backup_last_checkpoint) by (task) > 0 and max(tikv_log_backup_task_status) by (task) == 0` - 警戒レベル: 重大 -- 説明: ログデータが30分以上storageに保存されていません。このアラートは多くの場合、異常を示しています。原因を特定するには、TiKVログを確認してください。 +- 説明: ログデータが30分以上ストレージに保存されていません。このアラートは多くの場合、異常を示しています。原因を特定するには、TiKVログを確認してください。 #### ログバックアップ一時停止中 (2 時間以上) {#logbackuppausingmorethan2h} diff --git a/br/br-pitr-guide.md b/br/br-pitr-guide.md index 7402da3092da8..fe1ded9db2d88 100644 --- a/br/br-pitr-guide.md +++ b/br/br-pitr-guide.md @@ -5,29 +5,29 @@ summary: TiDB ログバックアップおよび PITR ガイドでは、br コマ # TiDB ログバックアップと PITR ガイド {#tidb-log-backup-and-pitr-guide} -フルバックアップ（スナップショットバックアップ）には、ある時点におけるクラスタ全体のデータが含まれますが、TiDBログバックアップは、アプリケーションによって書き込まれたデータを指定されたstorageにタイムリーにバックアップできます。必要に応じて復元ポイントを選択、つまりポイントインタイムリカバリ（PITR）を実行したい場合は、 [ログバックアップを開始する](#start-log-backup)と[定期的に完全バックアップを実行する](#run-full-backup-regularly)選択できます。 +フルバックアップ（スナップショットバックアップ）には、ある時点におけるクラスター全体のデータが含まれますが、TiDBログバックアップは、アプリケーションによって書き込まれたデータを指定されたストレージにタイムリーにバックアップできます。必要に応じて復元ポイントを選択、つまりポイントインタイムリカバリ（PITR）を実行したい場合は、 [ログバックアップを開始する](#start-log-backup)と[定期的に完全バックアップを実行する](#run-full-backup-regularly)選択できます。 br コマンドライン ツール (以下、 `br`と呼びます) を使用してデータをバックアップまたは復元する前に、まず[インストール`br`](/br/br-use-overview.md#deploy-and-use-br)行う必要があります。 -## TiDBクラスタのバックアップ {#back-up-tidb-cluster} +## TiDBクラスターのバックアップ {#back-up-tidb-cluster} ### ログバックアップを開始する {#start-log-backup} > **注記：** > > - 以下の例では、Amazon S3 アクセスキーとシークレットキーを使用して権限を承認することを前提としています。IAM ロールを使用して権限を承認する場合は、 `--send-credentials-to-tikv`を`false`に設定する必要があります。 -> - 他のstorageシステムまたは認証方法を使用して権限を認証する場合は、 [バックアップストレージ](/br/backup-and-restore-storages.md)に従ってパラメータ設定を調整します。 +> - 他のストレージシステムまたは認証方法を使用して権限を認証する場合は、 [バックアップストレージ](/br/backup-and-restore-ストレージs.md)に従ってパラメータ設定を調整します。 ログ バックアップを開始するには、 `tiup br log start`実行します。クラスターは 1 回につき 1 つのログ バックアップ タスクのみ実行できます。 ```shell tiup br log start --task-name=pitr --pd "${PD_IP}:2379" \ ---storage 's3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' +--ストレージ 's3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' ``` ### ログバックアップのステータスを照会する {#query-the-status-of-the-log-backup} -ログバックアップタスクは開始後、手動で停止するまでTiDBクラスタのバックグラウンドで実行されます。このプロセス中、TiDBの変更ログは指定されたstorageに小さなバッチで定期的にバックアップされます。ログバックアップタスクのステータスを確認するには、次のコマンドを実行します。 +ログバックアップタスクは開始後、手動で停止するまでTiDBクラスターのバックグラウンドで実行されます。このプロセス中、TiDBの変更ログは指定されたストレージに小さなバッチで定期的にバックアップされます。ログバックアップタスクのステータスを確認するには、次のコマンドを実行します。 ```shell tiup br log status --task-name=pitr --pd "${PD_IP}:2379" @@ -41,7 +41,7 @@ tiup br log status --task-name=pitr --pd "${PD_IP}:2379" status: ● NORMAL start: 2022-05-13 11:09:40.7 +0800 end: 2035-01-01 00:00:00 +0800 - storage: s3://backup-101/log-backup + ストレージ: s3://backup-101/log-backup speed(est.): 0.00 ops/s checkpoint[global]: 2022-05-13 11:31:47.2 +0800; gap=4m53s @@ -51,7 +51,7 @@ tiup br log status --task-name=pitr --pd "${PD_IP}:2379" - `status` : ログ バックアップ タスクのステータス`NORMAL` 、 `PAUSED` 、 `ERROR`を含む)。 - `start` : ログ バックアップ タスクの開始タイムスタンプ。 - `end` : ログバックアップタスクの終了タイムスタンプ。現在、このフィールドは無効です。 -- `storage` : ログ バックアップの外部storageの URI。 +- `ストレージ` : ログ バックアップの外部ストレージの URI。 - `speed(est.)` : ログバックアップの現在のデータ転送速度。この値は、過去数秒間に取得されたトラフィックサンプルに基づいて推定されます。より正確なトラフィック統計情報については、Grafanaの**TiKV-Details**ダッシュボードの`Log Backup`行目を確認してください。 - `checkpoint[global]` : ログバックアップの現在の進行状況。PITRを使用して、このタイムスタンプより前の時点に復元できます。 @@ -70,11 +70,11 @@ tiup br log status --task-name=pitr --pd "${PD_IP}:2379" ### 定期的に完全バックアップを実行する {#run-full-backup-regularly} -スナップショットバックアップは、フルバックアップの方法として使用できます。1 `tiup br backup full`実行すると、固定スケジュール（たとえば2日ごと）に従ってクラスタースナップショットをバックアップstorageにバックアップできます。 +スナップショットバックアップは、フルバックアップの方法として使用できます。1 `tiup br backup full`実行すると、固定スケジュール（たとえば2日ごと）に従ってクラスタースナップショットをバックアップストレージにバックアップできます。 ```shell tiup br backup full --pd "${PD_IP}:2379" \ ---storage 's3://backup-101/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}' +--ストレージ 's3://backup-101/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}' ``` ## PITRを実行する {#run-pitr} @@ -83,8 +83,8 @@ tiup br backup full --pd "${PD_IP}:2379" \ ```shell tiup br restore point --pd "${PD_IP}:2379" \ ---storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' \ ---full-backup-storage='s3://backup-101/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}' \ +--ストレージ='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' \ +--full-backup-ストレージ='s3://backup-101/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}' \ --restored-ts '2022-05-15 18:00:00+0800' ``` @@ -115,13 +115,13 @@ PITRを実行するには、復元ポイントより前のフルバックアッ 2. `validate`コマンドを使用して、バックアップに対応する時点を取得します。2022/09/01 より前のバックアップデータを消去する必要がある場合、この時点より前の最後の完全バックアップを探し、それが消去されないことを確認する必要があります。 ```shell - FULL_BACKUP_TS=`tiup br validate decode --field="end-version" --storage "s3://backup-101/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}"| tail -n1` + FULL_BACKUP_TS=`tiup br validate decode --field="end-version" --ストレージ "s3://backup-101/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}"| tail -n1` ``` 3. スナップショットバックアップ`FULL_BACKUP_TS`より前のログバックアップデータを削除します。 ```shell - tiup br log truncate --until=${FULL_BACKUP_TS} --storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' + tiup br log truncate --until=${FULL_BACKUP_TS} --ストレージ='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' ``` 4. スナップショットバックアップ`FULL_BACKUP_TS`より前のスナップショットデータを削除します。 @@ -142,7 +142,7 @@ PITRを実行するには、復元ポイントより前のフルバックアッ > - スナップショットデータの復元速度 = クラスター内のすべての TiKV ノードで復元されたスナップショットデータの合計サイズ / (所要時間 * TiKV ノードの数) > - ログデータの復元速度 = クラスター内のすべての TiKV ノードに復元されたログデータの合計サイズ / (期間 * TiKV ノードの数) > -> 外部storageには、単一のレプリカの KV データのみが含まれます。そのため、外部storageのデータ サイズは、クラスターで復元された実際のデータ サイズを表すものではありません。BRは、クラスターに設定されているレプリカの数に応じて、すべてのレプリカを復元します。レプリカの数が多いほど、実際に復元できるデータも多くなります。テストのすべてのクラスターのデフォルトのレプリカ数は 3 です。全体的な復元パフォーマンスを向上させるには、TiKV 設定ファイルの[`import.num-threads`](/tikv-configuration-file.md#import)項目とBRコマンドの[`pitr-concurrency`](/br/br-pitr-manual.md#restore-to-a-specified-point-in-time-pitr)オプションを変更できます。アップストリーム クラスターに**多くのリージョン**があり、**フラッシュ間隔が短い**場合、PITR によって多数の小さなファイルが生成されます。これにより、復元中のバッチ処理とディスパッチのオーバーヘッドが増加します。バッチごとに処理されるファイル数を増やすには、次のパラメーターの値を**適度に**増やすことができます。 +> 外部ストレージには、単一のレプリカの KV データのみが含まれます。そのため、外部ストレージのデータ サイズは、クラスターで復元された実際のデータ サイズを表すものではありません。BRは、クラスターに設定されているレプリカの数に応じて、すべてのレプリカを復元します。レプリカの数が多いほど、実際に復元できるデータも多くなります。テストのすべてのクラスターのデフォルトのレプリカ数は 3 です。全体的な復元パフォーマンスを向上させるには、TiKV 設定ファイルの[`import.num-threads`](/tikv-configuration-file.md#import)項目とBRコマンドの[`pitr-concurrency`](/br/br-pitr-manual.md#restore-to-a-specified-point-in-time-pitr)オプションを変更できます。アップストリーム クラスターに**多くのリージョン**があり、**フラッシュ間隔が短い**場合、PITR によって多数の小さなファイルが生成されます。これにより、復元中のバッチ処理とディスパッチのオーバーヘッドが増加します。バッチごとに処理されるファイル数を増やすには、次のパラメーターの値を**適度に**増やすことができます。 > > - `pitr-batch-size` :**バッチあたりの累積バイト数**(デフォルト**16 MiB** )。 > - `pitr-batch-count` :**バッチあたりのファイル数**(デフォルトは**8** )。 @@ -169,7 +169,7 @@ PITRを実行するには、復元ポイントより前のフルバックアッ ## 監視と警告 {#monitoring-and-alert} -ログバックアップタスクが分散されると、各TiKVノードは継続的にデータを外部storageに書き込みます。このプロセスの監視データは**、「TiKV詳細」>「バックアップログ」**ダッシュボードで確認できます。 +ログバックアップタスクが分散されると、各TiKVノードは継続的にデータを外部ストレージに書き込みます。このプロセスの監視データは**、「TiKV詳細」>「バックアップログ」**ダッシュボードで確認できます。 メトリックが通常の範囲から外れた場合の通知を受信するには、 [ログバックアップアラート](/br/br-monitoring-and-alert.md#log-backup-alerts)参照してアラート ルールを構成してください。 diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index a99f0994e27dc..874adfee8ada6 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -41,12 +41,12 @@ Available Commands: - `tiup br log pause` : ログ バックアップ タスクを一時停止します。 - `tiup br log resume` : 一時停止されたログ バックアップ タスクを再開します。 - `tiup br log stop` : ログ バックアップ タスクを停止し、タスク メタデータを削除します。 -- `tiup br log truncate` : バックアップstorageからログ バックアップ データをクリーンアップします。 +- `tiup br log truncate` : バックアップストレージからログ バックアップ データをクリーンアップします。 - `tiup br log metadata` : ログ バックアップ データのメタデータを照会します。 ### ログバックアップタスクを開始する {#start-a-log-backup-task} -`tiup br log start`コマンドを実行すると、ログバックアップタスクを開始できます。このタスクはTiDBクラスターのバックグラウンドで実行され、KVstorageの変更ログをバックアップstorageに自動的にバックアップします。 +`tiup br log start`コマンドを実行すると、ログバックアップタスクを開始できます。このタスクはTiDBクラスターのバックグラウンドで実行され、KVストレージの変更ログをバックアップストレージに自動的にバックアップします。 ヘルプ情報を表示するには、 `tiup br log start --help`実行します。 @@ -67,7 +67,7 @@ Global Flags: --cert string Certificate path for TLS connection --key string Private key path for TLS connection -u, --pd strings PD address (default [127.0.0.1:2379]) - -s, --storage string specify the url where backup storage, eg, "s3://bucket/path/prefix" + -s, --ストレージ string specify the url where backup ストレージ, eg, "s3://bucket/path/prefix" ``` @@ -77,7 +77,7 @@ Global Flags: - `task-name` : ログバックアップのタスク名を指定します。この名前は、バックアップタスクのクエリ、一時停止、再開にも使用されます。 - `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`指定します。 - `--pd` : バックアップ クラスターの PD アドレスを指定します。BRはログ バックアップ タスクを開始するために PD にアクセスする必要があります。 -- `--storage` : バックアップstorageのアドレスを指定します。現在、 BRはログバックアップのstorageとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--ストレージ` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのストレージとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-ストレージ-uri.md)参照してください。 使用例: @@ -85,12 +85,12 @@ Global Flags: tiup br log start \ --task-name=pitr \ --pd="${PD_IP}:2379" \ - --storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' + --ストレージ='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' ``` ### ログバックアップデータを暗号化する {#encrypt-the-log-backup-data} -BR を使用すると、ログ バックアップ データをバックアップstorageにアップロードする前に暗号化できます。 +BR を使用すると、ログ バックアップ データをバックアップストレージにアップロードする前に暗号化できます。 TiDB v8.4.0 以降では、ログ バックアップ コマンドで次のパラメータ ( [スナップショットバックアップの暗号化](/br/br-snapshot-manual.md#encrypt-the-backup-data)に類似) を渡すことで、ログ バックアップ データを暗号化できます。 @@ -104,7 +104,7 @@ TiDB v8.4.0 以降では、ログ バックアップ コマンドで次のパラ tiup br log start \ --task-name=pitr-with-encryption --pd ${PD_IP}:2379 \ - --storage "s3://${BACKUP_COLLECTION_ADDR}/snapshot-${DATE}?access-key=${AWS_ACCESS_KEY}&secret-access-key=${AWS_SECRET_ACCESS_KEY}" \ + --ストレージ "s3://${BACKUP_COLLECTION_ADDR}/snapshot-${DATE}?access-key=${AWS_ACCESS_KEY}&secret-access-key=${AWS_SECRET_ACCESS_KEY}" \ --log.crypter.method aes128-ctr \ --log.crypter.key 0123456789abcdef0123456789abcdef ``` @@ -120,7 +120,7 @@ tiup br log start \ tiup br log start \ --task-name=pitr-with-encryption \ --pd ${PD_IP}:2379 \ - --storage "s3://${BACKUP_COLLECTION_ADDR}/snapshot-${DATE}?access-key=${AWS_ACCESS_KEY}&secret-access-key=${AWS_SECRET_ACCESS_KEY}" \ + --ストレージ "s3://${BACKUP_COLLECTION_ADDR}/snapshot-${DATE}?access-key=${AWS_ACCESS_KEY}&secret-access-key=${AWS_SECRET_ACCESS_KEY}" \ --master-key-crypter-method aes128-ctr \ --master-key "local:///path/to/master.key" ``` @@ -131,7 +131,7 @@ AWS KMS によって管理されるマスターキーを使用して暗号化し tiup br log start \ --task-name=pitr-with-encryption \ --pd ${PD_IP}:2379 \ - --storage "s3://${BACKUP_COLLECTION_ADDR}/snapshot-${DATE}?access-key=${AWS_ACCESS_KEY}&secret-access-key=${AWS_SECRET_ACCESS_KEY}" \ + --ストレージ "s3://${BACKUP_COLLECTION_ADDR}/snapshot-${DATE}?access-key=${AWS_ACCESS_KEY}&secret-access-key=${AWS_SECRET_ACCESS_KEY}" \ --master-key-crypter-method aes128-ctr \ --master-key "aws-kms:///${AWS_KMS_KEY_ID}?AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY}&AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}®ION=${AWS_REGION}" ``` @@ -142,7 +142,7 @@ Google Cloud KMS によって管理されるマスターキーを使用して暗 tiup br log start \ --task-name=pitr-with-encryption \ --pd ${PD_IP}:2379 \ - --storage "s3://${BACKUP_COLLECTION_ADDR}/snapshot-${DATE}?access-key=${AWS_ACCESS_KEY}&secret-access-key=${AWS_SECRET_ACCESS_KEY}" \ + --ストレージ "s3://${BACKUP_COLLECTION_ADDR}/snapshot-${DATE}?access-key=${AWS_ACCESS_KEY}&secret-access-key=${AWS_SECRET_ACCESS_KEY}" \ --master-key-crypter-method aes128-ctr \ --master-key "gcp-kms:///projects/$GCP_PROJECT_ID/locations/$GCP_LOCATION/keyRings/$GCP_KEY_RING/cryptoKeys/$GCP_KEY_NAME?AUTH=specified&CREDENTIALS=$GCP_CREDENTIALS_PATH" ``` @@ -195,7 +195,7 @@ tiup br log status --task-name=pitr --pd="${PD_IP}:2379" status: ● NORMAL start: 2022-07-14 20:08:03.268 +0800 end: 2090-11-18 22:07:45.624 +0800 - storage: s3://backup-101/logbackup + ストレージ: s3://backup-101/logbackup speed(est.): 0.82 ops/s checkpoint[global]: 2022-07-25 22:52:15.518 +0800; gap=2m52s ``` @@ -204,10 +204,10 @@ checkpoint[global]: 2022-07-25 22:52:15.518 +0800; gap=2m52s - `status` : バックアップ タスクのステータス。 `NORMAL` 、 `ERROR` 、または`PAUSE`になります。 - `start` : バックアップタスクの開始時刻。バックアップタスクの開始時に指定された`start-ts`です。 -- `storage` : バックアップstorageアドレス。 +- `ストレージ` : バックアップストレージアドレス。 - `speed` : バックアップタスクの合計 QPS。QPS は 1 秒あたりにバックアップされるログの数を意味します。 -- `checkpoint [global]` : このチェックポイントより前のすべてのデータがバックアップstorageにバックアップされています。これは、バックアップデータの復元に使用できる最新のタイムスタンプです。 -- `error [store]` : ログ バックアップ プログラムがstorageノード上で検出したエラー。 +- `checkpoint [global]` : このチェックポイントより前のすべてのデータがバックアップストレージにバックアップされています。これは、バックアップデータの復元に使用できる最新のタイムスタンプです。 +- `error [store]` : ログ バックアップ プログラムがストレージノード上で検出したエラー。 ### ログバックアップタスクを一時停止して再開する {#pause-and-resume-a-log-backup-task} @@ -237,7 +237,7 @@ Global Flags: > **注記：** > > - ログバックアップタスクが一時停止された後、変更ログを生成するMVCCデータが削除されるのを防ぐため、バックアッププログラムは現在のバックアップチェックポイントをサービスセーフポイントとして自動的に設定します。このサービスセーフポイントには、過去24時間以内のMVCCデータが保持されます。バックアップタスクが24時間以上一時停止された場合、対応するデータはガベージコレクションされ、バックアップされません。 -> - MVCCデータを過剰に保持すると、TiDBクラスターのstorage容量とパフォーマンスに悪影響を及ぼします。そのため、バックアップタスクを適切なタイミングで再開することをお勧めします。 +> - MVCCデータを過剰に保持すると、TiDBクラスターのストレージ容量とパフォーマンスに悪影響を及ぼします。そのため、バックアップタスクを適切なタイミングで再開することをお勧めします。 使用例: @@ -277,7 +277,7 @@ tiup br log resume --task-name=pitr --pd="${PD_IP}:2379" ### ログバックアップタスクを停止して再開する {#stop-and-restart-a-log-backup-task} -`tiup br log stop`コマンドを実行してログ バックアップ タスクを停止し、元の`--storage`ディレクトリを使用して停止したログ バックアップ タスクを再開できます。 +`tiup br log stop`コマンドを実行してログ バックアップ タスクを停止し、元の`--ストレージ`ディレクトリを使用して停止したログ バックアップ タスクを再開できます。 ### ログバックアップタスクを停止する {#stop-a-log-backup-task} @@ -315,11 +315,11 @@ tiup br log stop --task-name=pitr --pd="${PD_IP}:2379" #### ログバックアップタスクを再開する {#restart-a-log-backup-task} -`tiup br log stop`コマンドを実行してログバックアップタスクを停止した後、別の`--storage`ディレクトリに新しいログバックアップタスクを作成するか、 `tiup br log start`コマンドを実行して元の`--storage`ディレクトリでログバックアップタスクを再開できます。元の`--storage`ディレクトリでタスクを再開する場合は、以下の点に注意してください。 +`tiup br log stop`コマンドを実行してログバックアップタスクを停止した後、別の`--ストレージ`ディレクトリに新しいログバックアップタスクを作成するか、 `tiup br log start`コマンドを実行して元の`--ストレージ`ディレクトリでログバックアップタスクを再開できます。元の`--ストレージ`ディレクトリでタスクを再開する場合は、以下の点に注意してください。 -- タスクを再開するための`--storage`ディレクトリのパラメータは、停止されたタスクと同じである必要があります。 +- タスクを再開するための`--ストレージ`ディレクトリのパラメータは、停止されたタスクと同じである必要があります。 - `--start-ts`指定する必要はありません。BRは最後のバックアップ チェックポイントから自動的にバックアップを開始します。 -- タスクが長時間停止し、複数のバージョンのデータがガベージコレクションされている場合、タスクを再開しようとするとエラー`BR:Backup:ErrBackupGCSafepointExceeded`が報告されます。この場合、別のディレクトリ`--storage`に新しいログバックアップタスクを作成する必要があります。 +- タスクが長時間停止し、複数のバージョンのデータがガベージコレクションされている場合、タスクを再開しようとするとエラー`BR:Backup:ErrBackupGCSafepointExceeded`が報告されます。この場合、別のディレクトリ`--ストレージ`に新しいログバックアップタスクを作成する必要があります。 ### ログバックアップデータをクリーンアップする {#clean-up-log-backup-data} @@ -342,20 +342,20 @@ Flags: Global Flags: - -s, --storage string specify the url where backup storage, eg, "s3://bucket/path/prefix" + -s, --ストレージ string specify the url where backup ストレージ, eg, "s3://bucket/path/prefix" ``` -このコマンドはバックアップstorageにのみアクセスし、TiDBクラスターにはアクセスしません。パラメータの説明は以下のとおりです。 +このコマンドはバックアップストレージにのみアクセスし、TiDBクラスターにはアクセスしません。パラメータの説明は以下のとおりです。 - `--dry-run` : コマンドを実行しますが、実際にはファイルを削除しません。 - `--until` : 指定されたタイムスタンプより前のすべてのログ バックアップ データを削除します。 -- `--storage` : バックアップstorageのアドレス。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--ストレージ` : バックアップストレージのアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-ストレージ-uri.md)参照してください。 使用例: ```shell tiup br log truncate --until='2022-07-26 21:20:00+0800' \ ---storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' +--ストレージ='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' ``` 期待される出力: @@ -370,13 +370,13 @@ Removing metadata... DONE; take = 24.038962ms ### ログバックアップのメタデータをビュー {#view-the-log-backup-metadata} -`tiup br log metadata`コマンドを実行すると、復元できる最も古いタイムスタンプや最新のタイムスタンプなど、storageシステム内のログ バックアップ メタデータを表示できます。 +`tiup br log metadata`コマンドを実行すると、復元できる最も古いタイムスタンプや最新のタイムスタンプなど、ストレージシステム内のログ バックアップ メタデータを表示できます。 ヘルプ情報を表示するには、 `tiup br log metadata --help`実行します。 ```shell tiup br log metadata --help -get the metadata of log backup storage +get the metadata of log backup ストレージ Usage: br log metadata [flags] @@ -385,17 +385,17 @@ Flags: -h, --help help for metadata Global Flags: - -s, --storage string specify the url where backup storage, eg, "s3://bucket/path/prefix" + -s, --ストレージ string specify the url where backup ストレージ, eg, "s3://bucket/path/prefix" ``` -このコマンドはバックアップstorageにのみアクセスし、TiDB クラスターにはアクセスしません。 +このコマンドはバックアップストレージにのみアクセスし、TiDB クラスターにはアクセスしません。 -`--storage`パラメータはバックアップstorageのアドレスを指定するために使用されます。現在、 BR はログバックアップのstorageとして Amazon S3、GCS、または Azure Blob Storage をサポートしています。詳細については[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +`--ストレージ`パラメータはバックアップストレージのアドレスを指定するために使用されます。現在、 BR はログバックアップのストレージとして Amazon S3、GCS、または Azure Blob Storage をサポートしています。詳細については[外部ストレージサービスのURI形式](/external-ストレージ-uri.md)参照してください。 使用例: ```shell -tiup br log metadata --storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' +tiup br log metadata --ストレージ='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' ``` 期待される出力: @@ -408,7 +408,7 @@ tiup br log metadata --storage='s3://backup-101/logbackup?access-key=${access-ke > **注記：** > -> `restore point`の増分バックアップ アドレスとして`--full-backup-storage`指定した場合、このバックアップと以前の増分バックアップを復元するには、増分バックアップと後続のログ バックアップとの互換性を確保するために、パラメータ`--allow-pitr-from-incremental` `true`に設定する必要があります。 +> `restore point`の増分バックアップ アドレスとして`--full-backup-ストレージ`指定した場合、このバックアップと以前の増分バックアップを復元するには、増分バックアップと後続のログ バックアップとの互換性を確保するために、パラメータ`--allow-pitr-from-incremental` `true`に設定する必要があります。 `tiup br restore point`コマンドを実行して、新しいクラスターで PITR を実行したり、ログ バックアップ データを復元したりできます。 @@ -422,7 +422,7 @@ Usage: br restore point [flags] Flags: - --full-backup-storage string specify the backup full storage. fill it if want restore full backup before restore log. + --full-backup-ストレージ string specify the backup full ストレージ. fill it if want restore full backup before restore log. -h, --help help for point --pitr-batch-count uint32 specify the batch count to restore log. (default 8) --pitr-batch-size uint32 specify the batch size to restore log. (default 16777216) @@ -436,12 +436,12 @@ Global Flags: --cert string Certificate path for TLS connection --key string Private key path for TLS connection -u, --pd strings PD address (default [127.0.0.1:2379]) - -s, --storage string specify the url where backup storage, eg, "s3://bucket/path/prefix" + -s, --ストレージ string specify the url where backup ストレージ, eg, "s3://bucket/path/prefix" ``` 出力例には共通パラメータのみが表示されています。これらのパラメータは以下のように記述されます。 -- `--full-backup-storage` : スナップショット（フル）バックアップのstorageアドレス。PITRを使用する場合は、このパラメータを指定して、復元タイムスタンプ前の最新のスナップショットバックアップを選択します。ログバックアップデータのみを復元する場合は、このパラメータを省略できます。リカバリクラスターを初めて初期化する場合は、スナップショットバックアップを指定する必要があります。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、Azure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--full-backup-ストレージ` : スナップショット（フル）バックアップのストレージアドレス。PITRを使用する場合は、このパラメータを指定して、復元タイムスタンプ前の最新のスナップショットバックアップを選択します。ログバックアップデータのみを復元する場合は、このパラメータを省略できます。リカバリクラスターを初めて初期化する場合は、スナップショットバックアップを指定する必要があります。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、Azure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-ストレージ-uri.md)参照してください。 - `--pitr-batch-count` : ログデータを復元する際の、1バッチあたりのファイル数の上限。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。 - `--pitr-batch-size` : ログデータを復元する際の単一バッチの最大データサイズ（バイト単位）。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。 - `--pitr-concurrency` : ログ復元中の同時タスク数。各同時タスクは、一度に1バッチのログデータを復元します。 @@ -449,14 +449,14 @@ Global Flags: - `--start-ts` : ログバックアップデータを復元する開始タイムスタンプ。ログバックアップデータのみを復元する必要がある場合は、このパラメータを指定する必要があります。 - `--pd` : 復元クラスターの PD アドレス。 - `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`指定します。 -- `--storage` : ログバックアップのstorageアドレス。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--ストレージ` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-ストレージ-uri.md)参照してください。 使用例: ```shell tiup br restore point --pd="${PD_IP}:2379" ---storage='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' ---full-backup-storage='s3://backup-101/snapshot-202205120000?access-key=${access-key}&secret-access-key=${secret-access-key}' +--ストレージ='s3://backup-101/logbackup?access-key=${access-key}&secret-access-key=${secret-access-key}' +--full-backup-ストレージ='s3://backup-101/snapshot-202205120000?access-key=${access-key}&secret-access-key=${secret-access-key}' Split&Scatter Region <--------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00% Download&Ingest SST <--------------------------------------------------------------------------------------------------------------------------------------------------------> 100.00% @@ -481,8 +481,8 @@ Restore KV Files <-------------------------------------------------------------- ```shell tiup br restore point --pd="${PD_IP}:2379" ---storage='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' ---full-backup-storage='s3://backup-101/snapshot-202205120000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' +--ストレージ='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' +--full-backup-ストレージ='s3://backup-101/snapshot-202205120000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' --crypter.method aes128-ctr --crypter.key 0123456789abcdef0123456789abcdef --log.crypter.method aes128-ctr @@ -493,8 +493,8 @@ tiup br restore point --pd="${PD_IP}:2379" ```shell tiup br restore point --pd="${PD_IP}:2379" ---storage='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' ---full-backup-storage='s3://backup-101/snapshot-202205120000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' +--ストレージ='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' +--full-backup-ストレージ='s3://backup-101/snapshot-202205120000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' --crypter.method aes128-ctr --crypter.key 0123456789abcdef0123456789abcdef --master-key-crypter-method aes128-ctr @@ -518,24 +518,24 @@ TiDB v8.5.5 以降では、PITR 中にフィルターを使用して特定のデ ```shell # restore specific databases tiup br restore point --pd="${PD_IP}:2379" \ ---storage='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ ---full-backup-storage='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--ストレージ='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--full-backup-ストレージ='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ --start-ts "2025-06-02 00:00:00+0800" \ --restored-ts "2025-06-03 18:00:00+0800" \ --filter 'db1.*' --filter 'db2.*' # restore specific tables tiup br restore point --pd="${PD_IP}:2379" \ ---storage='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ ---full-backup-storage='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--ストレージ='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--full-backup-ストレージ='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ --start-ts "2025-06-02 00:00:00+0800" \ --restored-ts "2025-06-03 18:00:00+0800" \ --filter 'db1.users' --filter 'db1.orders' # restore using pattern matching tiup br restore point --pd="${PD_IP}:2379" \ ---storage='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ ---full-backup-storage='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--ストレージ='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--full-backup-ストレージ='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ --start-ts "2025-06-02 00:00:00+0800" \ --restored-ts "2025-06-03 18:00:00+0800" \ --filter 'db*.tbl*' @@ -562,16 +562,16 @@ TiDB v8.5.5以降では、複数のPITRリストアタスクを同時に実行 ```shell # terminal 1 - restore database db1 tiup br restore point --pd="${PD_IP}:2379" \ ---storage='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ ---full-backup-storage='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--ストレージ='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--full-backup-ストレージ='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ --start-ts "2025-06-02 00:00:00+0800" \ --restored-ts "2025-06-03 18:00:00+0800" \ --filter 'db1.*' # terminal 2 - restore database db2 (can run simultaneously) tiup br restore point --pd="${PD_IP}:2379" \ ---storage='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ ---full-backup-storage='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--ストレージ='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--full-backup-ストレージ='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ --start-ts "2025-06-02 00:00:00+0800" \ --restored-ts "2025-06-03 18:00:00+0800" \ --filter 'db2.*' @@ -587,10 +587,10 @@ tiup br restore point --pd="${PD_IP}:2379" \ v8.5.5 以降では、ログ バックアップ タスクの実行中に、次の条件がすべて満たされている場合は、スナップショット リストア ( `br restore [full|database|table]` ) を実行し、進行中のログ バックアップ (以下、「ログ バックアップ」) によってリストアされたデータを適切に記録することができます。 - バックアップおよび復元操作を実行するノードには、次の必要な権限があります。 - - スナップショットの復元のための、バックアップソースを含む外部storageへの読み取りアクセス - - ログバックアップで使用されるターゲット外部storageへの書き込みアクセス -- ログバックアップの対象となる外部storageは、Amazon S3（ `s3://` ）、Google Cloud Storage（ `gcs://` ）、またはAzure Blob Storage（ `azblob://` ）です。 -- 復元するデータは、ログ バックアップのターゲットstorageと同じ種類の外部storageを使用します。 + - スナップショットの復元のための、バックアップソースを含む外部ストレージへの読み取りアクセス + - ログバックアップで使用されるターゲット外部ストレージへの書き込みアクセス +- ログバックアップの対象となる外部ストレージは、Amazon S3（ `s3://` ）、Google Cloud Storage（ `gcs://` ）、またはAzure Blob Storage（ `azblob://` ）です。 +- 復元するデータは、ログ バックアップのターゲットストレージと同じ種類の外部ストレージを使用します。 - 復元対象のデータとログバックアップのどちらにもローカル暗号化が有効になっていません。詳細については、 [ログバックアップの暗号化](#encrypt-the-log-backup-data)と[スナップショットバックアップの暗号化](/br/br-snapshot-manual.md#encrypt-the-backup-data)参照してください。 上記の条件のいずれかが満たされていない場合は、次の手順に従ってデータを復元できます。 @@ -610,7 +610,7 @@ TiDB v8.5.5以降では、ログバックアップタスクの実行中にPITR #### 継続的なログバックアップを伴うPITRの重要な制限 {#important-limitation-for-pitr-with-ongoing-log-backup} -ログバックアップの実行中にPITR操作を実行すると、復元されたデータは進行中のログバックアップにも記録されます。ただし、ログ復元操作の性質上、復元ウィンドウ内でデータの不整合が発生する可能性があります。システムは、整合性が保証できない時間範囲とデータ範囲の両方を示すメタデータを外部storageに書き込みます。 +ログバックアップの実行中にPITR操作を実行すると、復元されたデータは進行中のログバックアップにも記録されます。ただし、ログ復元操作の性質上、復元ウィンドウ内でデータの不整合が発生する可能性があります。システムは、整合性が保証できない時間範囲とデータ範囲の両方を示すメタデータを外部ストレージに書き込みます。 期間`[t1, t2)`にこのような不整合が発生した場合、この期間のデータを直接復元することはできません。代わりに、以下のいずれかの方法を選択してください。 @@ -619,7 +619,7 @@ TiDB v8.5.5以降では、ログバックアップタスクの実行中にPITR ### 復元操作を中止する {#abort-restore-operations} -復元操作が失敗した場合、 `tiup br abort`コマンドを使用してレジストリエントリとチェックポイントデータをクリーンアップできます。このコマンドは、元の復元パラメータに基づいて、 `mysql.tidb_restore_registry`テーブルのエントリやチェックポイントデータ（ローカルデータベースに保存されているか外部storageに保存されているかに関係なく）を含む関連メタデータを自動的に検索して削除します。 +復元操作が失敗した場合、 `tiup br abort`コマンドを使用してレジストリエントリとチェックポイントデータをクリーンアップできます。このコマンドは、元の復元パラメータに基づいて、 `mysql.tidb_restore_registry`テーブルのエントリやチェックポイントデータ（ローカルデータベースに保存されているか外部ストレージに保存されているかに関係なく）を含む関連メタデータを自動的に検索して削除します。 > **注記：** > @@ -630,26 +630,26 @@ TiDB v8.5.5以降では、ログバックアップタスクの実行中にPITR ```shell # Abort a PITR operation tiup br abort restore point --pd="${PD_IP}:2379" \ ---storage='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ ---full-backup-storage='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' +--ストレージ='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--full-backup-ストレージ='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' # Abort a PITR operation with filters tiup br abort restore point --pd="${PD_IP}:2379" \ ---storage='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ ---full-backup-storage='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--ストレージ='s3://backup-101/logbackup?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--full-backup-ストレージ='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ --filter 'db1.*' # Abort a full restore tiup br abort restore full --pd="${PD_IP}:2379" \ ---storage='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' +--ストレージ='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' # Abort a database restore tiup br abort restore db --pd="${PD_IP}:2379" \ ---storage='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--ストレージ='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ --db database_name # Abort a table restore tiup br abort restore table --pd="${PD_IP}:2379" \ ---storage='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ +--ストレージ='s3://backup-101/snapshot-20250602000000?access-key=${ACCESS-KEY}&secret-access-key=${SECRET-ACCESS-KEY}' \ --db database_name --table table_name ``` diff --git a/br/br-snapshot-architecture.md b/br/br-snapshot-architecture.md index add257a37013d..9fe78e1baf634 100644 --- a/br/br-snapshot-architecture.md +++ b/br/br-snapshot-architecture.md @@ -1,6 +1,6 @@ --- title: TiDB Snapshot Backup and Restore Architecture -summary: TiDBスナップショットバックアップおよびリストアアーキテクチャでは、バックアップ＆リストア（BR）ツールを使用したプロセスについて説明します。このアーキテクチャには、バックアップおよびリストアプロセス、バックアップファイルの種類、命名形式、storage形式、およびバックアップファイルの構造が含まれます。バックアッププロセスには、スケジューリング、データバックアップ、およびメタデータバックアップが含まれます。リストアプロセスには、スケジューリング、スキーマリストア、リージョン割り当て、データリストア、およびレポートが含まれます。バックアップファイルの種類には、SSTファイル、backupmetaファイル、およびbackup.lockファイルがあります。SSTファイルの命名形式とstorage形式については、詳細に説明します。詳細については、TiDBスナップショットバックアップおよびリストアガイドを参照してください。 +summary: TiDBスナップショットバックアップおよびリストアアーキテクチャでは、バックアップ＆リストア（BR）ツールを使用したプロセスについて説明します。このアーキテクチャには、バックアップおよびリストアプロセス、バックアップファイルの種類、命名形式、ストレージ形式、およびバックアップファイルの構造が含まれます。バックアッププロセスには、スケジューリング、データバックアップ、およびメタデータバックアップが含まれます。リストアプロセスには、スケジューリング、スキーマリストア、リージョン割り当て、データリストア、およびレポートが含まれます。バックアップファイルの種類には、SSTファイル、backupmetaファイル、およびbackup.lockファイルがあります。SSTファイルの命名形式とストレージ形式については、詳細に説明します。詳細については、TiDBスナップショットバックアップおよびリストアガイドを参照してください。 --- # TiDBスナップショットバックアップおよびリストアアーキテクチャ {#tidb-snapshot-backup-and-restore-architecture} @@ -15,7 +15,7 @@ TiDBのスナップショットバックアップおよびリストアのアー ## バックアップのプロセス {#process-of-backup} -クラスタスナップショットバックアップの手順は以下のとおりです。 +クラスタースナップショットバックアップの手順は以下のとおりです。 ```mermaid sequenceDiagram @@ -44,13 +44,13 @@ sequenceDiagram 1. BR は`br backup full`コマンドを受け取ります。 - - バックアップの日時とstorage場所を取得します。 + - バックアップの日時とストレージ場所を取得します。 2. BRはバックアップデータのスケジュールを設定します。 - **GCの一時停止**： BRは、TiDB [TiDB GCメカニズム](/garbage-collection-overview.md)によってバックアップデータがクリーンアップされないように、TiDB GCの時間を設定します。 - - **TiKV とリージョン情報の取得**: BR はPD にアクセスして、すべての TiKV ノードのアドレスとデータの[リージョン](/tidb-storage.md#region)分布を取得します。 - - **TiKVにデータバックアップを依頼する**： BRはバックアップ依頼を作成し、すべてのTiKVノードに送信します。バックアップ依頼には、バックアップのタイミング、バックアップ対象のリージョン、およびstorageパスが含まれます。 + - **TiKV とリージョン情報の取得**: BR はPD にアクセスして、すべての TiKV ノードのアドレスとデータの[リージョン](/tidb-ストレージ.md#region)分布を取得します。 + - **TiKVにデータバックアップを依頼する**： BRはバックアップ依頼を作成し、すべてのTiKVノードに送信します。バックアップ依頼には、バックアップのタイミング、バックアップ対象のリージョン、およびストレージパスが含まれます。 3. TiKVはバックアップ要求を受け入れ、バックアップワーカーを起動します。 @@ -58,7 +58,7 @@ sequenceDiagram - **KVのスキャン**：バックアップワーカーは、リーダーが存在するリージョンから、バックアップ時点に対応するデータを読み取ります。 - **SST の生成**: バックアップ ワーカーはデータを SST ファイルに保存し、メモリに保存します。 - - **SSTファイルのアップロード**：バックアップワーカーがSSTファイルをstorageパスにアップロードします。 + - **SSTファイルのアップロード**：バックアップワーカーがSSTファイルをストレージパスにアップロードします。 5. BRは各TiKVノードからバックアップ結果を受け取ります。 @@ -69,11 +69,11 @@ sequenceDiagram 6. BRはメタデータをバックアップします。 - **スキーマのバックアップ**： BRはテーブルスキーマをバックアップし、テーブルデータのチェックサムを計算します。 - - **メタデータのアップロード**： BRはバックアップメタデータを生成し、storageパスにアップロードします。バックアップメタデータには、バックアップタイムスタンプ、テーブルと対応するバックアップファイル、データチェックサム、およびファイルチェックサムが含まれます。 + - **メタデータのアップロード**： BRはバックアップメタデータを生成し、ストレージパスにアップロードします。バックアップメタデータには、バックアップタイムスタンプ、テーブルと対応するバックアップファイル、データチェックサム、およびファイルチェックサムが含まれます。 ## 復元プロセス {#process-of-restore} -クラスタスナップショットの復元プロセスは以下のとおりです。 +クラスタースナップショットの復元プロセスは以下のとおりです。 ```mermaid sequenceDiagram @@ -101,14 +101,14 @@ sequenceDiagram 1. BR は`br restore`コマンドを受け取ります。 - - 復元するデータstorageパスとデータベースまたはテーブルを取得します。 + - 復元するデータストレージパスとデータベースまたはテーブルを取得します。 - 復元対象のテーブルが存在するか、また復元要件を満たしているかを確認します。 2. BRは復元データのスケジュールを設定します。 - **リージョンスケジュールの一時停止**： BRは、復元中に自動リージョンスケジューリングを一時停止するようPDに要求します。 - **スキーマの復元**： BRはバックアップデータのスキーマ、および復元対象のデータベースとテーブルを取得します。新しく作成されたテーブルのIDは、バックアップデータのIDと異なる場合があることに注意してください。 - - **分割領域と分散リージョン**： BRはPDにバックアップデータに基づいて領域（分割リージョン）を割り当てるよう要求し、storageノードに均等に分散されるように領域（分散リージョン）をスケジュールします。各リージョンには、指定されたデータ範囲`[start key, end key)`があります。 + - **分割領域と分散リージョン**： BRはPDにバックアップデータに基づいて領域（分割リージョン）を割り当てるよう要求し、ストレージノードに均等に分散されるように領域（分散リージョン）をスケジュールします。各リージョンには、指定されたデータ範囲`[start key, end key)`があります。 - **TiKVにデータ復元を依頼する**： BRは復元依頼を作成し、リージョン分割の結果に応じて対応するTiKVノードに送信します。復元依頼には、復元するデータと書き換えルールが含まれます。 3. TiKVは復元要求を受け入れ、復元ワーカーを起動します。 @@ -117,7 +117,7 @@ sequenceDiagram 4. TiKVはデータを復元します。 - - **SSTファイルのダウンロード**：復元ワーカーは、storageパスから対応するSSTファイルをローカルディレクトリにダウンロードします。 + - **SSTファイルのダウンロード**：復元ワーカーは、ストレージパスから対応するSSTファイルをローカルディレクトリにダウンロードします。 - **KVの書き換え**：復元ワーカーは、新しいテーブルIDに基づいてKVデータを書き換えます。つまり、 [キー値](/tidb-computing.md#mapping-table-data-to-key-value)内の元のテーブルIDを新しいテーブルIDに置き換えます。復元ワーカーは、インデックスIDも同様に書き換えます。 - **SSTの取り込み**: リストアワーカーは、処理済みの SST ファイルを RocksDB に取り込みます。 - **復元結果の報告**: 復元ワーカーは復元結果をBRに報告します。 @@ -157,9 +157,9 @@ sequenceDiagram - `timestamp`は、TiKV によって生成された SST ファイルの Unix タイムスタンプです。 - `cf` RocksDB のカラムファミリーを示します ( `cf`が`default`または`write`であるデータのみを復元します)。 -### SSTファイルの保存形式 {#storage-format-of-sst-files} +### SSTファイルの保存形式 {#ストレージ-format-of-sst-files} -- SST ファイルのstorage形式の詳細については、 [RocksDBブロックベーステーブル形式](https://github.com/facebook/rocksdb/wiki/Rocksdb-BlockBasedTable-Format)を参照してください。 +- SST ファイルのストレージ形式の詳細については、 [RocksDBブロックベーステーブル形式](https://github.com/facebook/rocksdb/wiki/Rocksdb-BlockBasedTable-Format)を参照してください。 - SST ファイルのバックアップ データのエンコード形式の詳細については、「テーブルデータ[テーブルデータのキー値へのマッピング](/tidb-computing.md#mapping-table-data-to-key-value)参照してください。 ### バックアップファイルの構造 {#structure-of-backup-files} diff --git a/br/br-snapshot-guide.md b/br/br-snapshot-guide.md index 890f39a5ca250..40245993146e4 100644 --- a/br/br-snapshot-guide.md +++ b/br/br-snapshot-guide.md @@ -7,7 +7,7 @@ summary: このドキュメントでは、br コマンドラインツールを このドキュメントでは、br コマンドラインツール（以下、 `br`と呼びます）を使用して TiDB スナップショットをバックアップおよび復元する方法について説明します。データのバックアップと復元を行う前に、まず[brコマンドラインツールをインストールする](/br/br-use-overview.md#deploy-and-use-br)行う必要があります。 -スナップショットバックアップは、クラスタ全体をバックアップする実装です。1 [マルチバージョン同時実行制御 (MVCC)](/tidb-storage.md#mvcc)ベースとし、指定されたスナップショット内のすべてのデータをターゲットstorageにバックアップします。バックアップデータのサイズは、クラスタ内の圧縮された単一レプリカのサイズとほぼ同等です。バックアップ完了後、バックアップデータを空のクラスタまたは競合データを含まないクラスタ（同一スキーマまたは同一テーブル）に復元したり、スナップショットバックアップの時点にクラスタを復元したり、クラスタレプリカ設定に従って複数のレプリカを復元したりできます。 +スナップショットバックアップは、クラスター全体をバックアップする実装です。1 [マルチバージョン同時実行制御 (MVCC)](/tidb-ストレージ.md#mvcc)ベースとし、指定されたスナップショット内のすべてのデータをターゲットストレージにバックアップします。バックアップデータのサイズは、クラスター内の圧縮された単一レプリカのサイズとほぼ同等です。バックアップ完了後、バックアップデータを空のクラスターまたは競合データを含まないクラスター（同一スキーマまたは同一テーブル）に復元したり、スナップショットバックアップの時点にクラスターを復元したり、クラスターレプリカ設定に従って複数のレプリカを復元したりできます。 基本的なバックアップと復元に加えて、スナップショット バックアップと復元では次の機能も提供されます。 @@ -19,20 +19,20 @@ summary: このドキュメントでは、br コマンドラインツールを > **注記：** > > - 以下の例では、Amazon S3 アクセスキーとシークレットキーを使用して権限を承認することを前提としています。IAM ロールを使用して権限を承認する場合は、 `--send-credentials-to-tikv`を`false`に設定する必要があります。 -> - 他のstorageシステムまたは認証方法を使用して権限を認証する場合は、 [バックアップストレージ](/br/backup-and-restore-storages.md)に従ってパラメータ設定を調整します。 +> - 他のストレージシステムまたは認証方法を使用して権限を認証する場合は、 [バックアップストレージ](/br/backup-and-restore-ストレージs.md)に従ってパラメータ設定を調整します。 `tiup br backup full`コマンドを実行すると、TiDB クラスターのスナップショットをバックアップできます。ヘルプ情報を表示するには、 `tiup br backup full --help`を実行します。 ```shell tiup br backup full --pd "${PD_IP}:2379" \ --backupts '2022-09-08 13:30:00 +08:00' \ - --storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" + --ストレージ "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" ``` 上記のコマンドでは、次のようになります。 - `--backupts` : スナップショットの時点。形式は[TSO](/tso.md)またはタイムスタンプ（例： `400036290571534337` 、 `2018-05-11 01:42:23 +08:00`です。このスナップショットのデータがガベージコレクションされた場合、 `tiup br backup`コマンドはエラーを返し、 `br`終了します。タイムスタンプを使用してバックアップする場合は、タイムゾーンも指定することをお勧めします。指定しない場合、 `br`デフォルトでローカルタイムゾーンを使用してタイムスタンプを作成するため、バックアップの時点が不正確になる可能性があります。このパラメータを指定しない場合、 `br`バックアップ開始時刻に対応するスナップショットを選択します。 -- `--storage` : バックアップデータのstorageアドレス。スナップショットバックアップは、Amazon S3、Google Cloud Storage、Azure Blob Storageをバックアップstorageとしてサポートしています。上記のコマンドでは、例としてAmazon S3を使用しています。詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--ストレージ` : バックアップデータのストレージアドレス。スナップショットバックアップは、Amazon S3、Google Cloud Storage、Azure Blob Storageをバックアップストレージとしてサポートしています。上記のコマンドでは、例としてAmazon S3を使用しています。詳細については、 [外部ストレージサービスのURI形式](/external-ストレージ-uri.md)参照してください。 バックアップ中は、ターミナルに以下のようにプログレスバーが表示されます。プログレスバーが100%に達すると、バックアップタスクが完了し、合計バックアップ時間、平均バックアップ速度、バックアップデータサイズなどの統計情報が表示されます。 @@ -55,7 +55,7 @@ Checksum <---------------------------------------------------------------------- ```shell tiup br validate decode --field="end-version" \ ---storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" | tail -n1 +--ストレージ "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" | tail -n1 ``` 出力は次のようになり、物理時間`2022-09-08 13:30:00 +0800 CST`に対応します。 @@ -78,7 +78,7 @@ tiup br validate decode --field="end-version" \ ```shell tiup br restore full --pd "${PD_IP}:2379" \ ---storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" +--ストレージ "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" ``` 復元中は、ターミナルに以下のようにプログレスバーが表示されます。プログレスバーが100%に達すると、復元タスクが完了し、合計復元時間、平均復元速度、合計データサイズなどの統計情報が表示されます。 @@ -114,7 +114,7 @@ BRは、バックアップデータから指定されたデータベースまた tiup br restore db \ --pd "${PD_IP}:2379" \ --db "test" \ ---storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" +--ストレージ "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" ``` 上記のコマンドでは、 `--db`復元するデータベースの名前を指定します。 @@ -127,7 +127,7 @@ tiup br restore db \ tiup br restore table --pd "${PD_IP}:2379" \ --db "test" \ --table "usertable" \ ---storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" +--ストレージ "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" ``` 上記のコマンドでは、 `--db`復元するデータベースの名前を指定し、 `--table`復元するテーブルの名前を指定します。 @@ -140,7 +140,7 @@ tiup br restore table --pd "${PD_IP}:2379" \ tiup br restore full \ --pd "${PD_IP}:2379" \ --filter 'db*.tbl*' \ ---storage "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" +--ストレージ "s3://backup-101/snapshot-202209081330?access-key=${access-key}&secret-access-key=${secret-access-key}" ``` ### mysqlスキーマ内のテーブルを復元する {#restore-tables-in-the-code-mysql-code-schema} @@ -191,11 +191,11 @@ tiup br restore full \ | tidb | +-----------------------------------------------------+ -システム権限に関連するデータを復元する場合、 BR は復元前に、ターゲット クラスタ内のシステム テーブルがバックアップ データ内のシステム テーブルと互換性があるかどうかを確認します。「互換性がある」とは、以下のすべての条件が満たされていることを意味します。 +システム権限に関連するデータを復元する場合、 BR は復元前に、ターゲット クラスター内のシステム テーブルがバックアップ データ内のシステム テーブルと互換性があるかどうかを確認します。「互換性がある」とは、以下のすべての条件が満たされていることを意味します。 - ターゲット クラスターには、バックアップ データと同じシステム テーブルがあります。 -- ターゲットクラスタのシステム権限テーブルの**列数は**、バックアップデータと同じになります。列の順序は重要ではありません。 -- ターゲットクラスタのシステム権限テーブルの列は、バックアップデータの列と互換性があります。列のデータ型が長さを持つ型（整数や文字列など）の場合、ターゲットクラスタの長さはバックアップデータの長さ以上である必要があります。列のデータ型が`ENUM`の場合、ターゲットクラスタの`ENUM`の値の数は、バックアップデータの値のスーパーセットである必要があります。 +- ターゲットクラスターのシステム権限テーブルの**列数は**、バックアップデータと同じになります。列の順序は重要ではありません。 +- ターゲットクラスターのシステム権限テーブルの列は、バックアップデータの列と互換性があります。列のデータ型が長さを持つ型（整数や文字列など）の場合、ターゲットクラスターの長さはバックアップデータの長さ以上である必要があります。列のデータ型が`ENUM`の場合、ターゲットクラスターの`ENUM`の値の数は、バックアップデータの値のスーパーセットである必要があります。 ## パフォーマンスと影響 {#performance-and-impact} @@ -214,7 +214,7 @@ tiup br restore full \ - 推奨方法：バックアップタスクで使用されるワーカースレッドの数を制御するTiKV構成パラメータ[`backup.num-threads`](/tikv-configuration-file.md#num-threads-1)を調整します。バックアップはCPUを大量に消費する処理であるため、このパラメータを調整することでTiKVのCPU使用率をより正確に制御し、リソースの分離と予測可能性を向上させることができます。ほとんどのシナリオでは、 `num-threads`調整するだけで、バックアップがクラスターに与える影響を制限するのに十分です。社内テストでは、スレッド数を`8`以下に設定し、クラスター全体のCPU使用率が60%未満であれば、バックアップがフォアグラウンドワークロードに与える影響はごくわずかであることが示されています。 -- 代替方法：既に`backup.num-threads`小さな値（例えば`1` ）に設定しているものの、バックアップがクラスターに与える影響をさらに軽減したい場合は、 `--ratelimit`パラメータの使用を検討してください。このオプションは、バックアップファイルを外部storageに書き込む際に使用する帯域幅を MiB/s 単位で制限します。実際のレート制限効果は、圧縮データのサイズによって異なります。詳細については、ログの`backup data size (after compressed)`フィールドを参照してください。 `--ratelimit`有効にすると、 BR は同時リクエスト数を減らすために自動的に`--concurrency`を`1`に設定します。 +- 代替方法：既に`backup.num-threads`小さな値（例えば`1` ）に設定しているものの、バックアップがクラスターに与える影響をさらに軽減したい場合は、 `--ratelimit`パラメータの使用を検討してください。このオプションは、バックアップファイルを外部ストレージに書き込む際に使用する帯域幅を MiB/s 単位で制限します。実際のレート制限効果は、圧縮データのサイズによって異なります。詳細については、ログの`backup data size (after compressed)`フィールドを参照してください。 `--ratelimit`有効にすると、 BR は同時リクエスト数を減らすために自動的に`--concurrency`を`1`に設定します。 > **注記：** > @@ -229,12 +229,12 @@ tiup br restore full \ ### スナップショット復元のパフォーマンスと影響 {#performance-and-impact-of-snapshot-restore} -- データ復元中、TiDBはTiKVのCPU、ディスクIO、ネットワーク帯域幅のリソースを最大限に活用しようとします。そのため、実行中のアプリケーションへの影響を避けるため、バックアップデータは空のクラスタ上で復元することをお勧めします。 -- バックアップデータの復元速度は、クラスタ構成、デプロイメント、実行中のアプリケーションに大きく依存します。スナップショット復元のパフォーマンスと影響は、ユーザーシナリオによって異なるため、実際の環境でテストする必要があります。 +- データ復元中、TiDBはTiKVのCPU、ディスクIO、ネットワーク帯域幅のリソースを最大限に活用しようとします。そのため、実行中のアプリケーションへの影響を避けるため、バックアップデータは空のクラスター上で復元することをお勧めします。 +- バックアップデータの復元速度は、クラスター構成、デプロイメント、実行中のアプリケーションに大きく依存します。スナップショット復元のパフォーマンスと影響は、ユーザーシナリオによって異なるため、実際の環境でテストする必要があります。 - BRは、大規模リージョンシナリオにおけるリージョン復元を高速化するために、粗粒度のリージョン分散アルゴリズムを提供します。このアルゴリズムにより、各TiKVノードが安定的かつ均等に分散されたダウンロードタスクを受け取ることができるため、各TiKVノードのリソースを最大限に活用し、迅速な並列リカバリを実現できます。いくつかの実例において、大規模リージョンシナリオにおいて、クラスターのスナップショット復元速度が約3倍向上しました。 - v8.0.0以降、コマンドラインツール`br`に、TiKVノードごとにBRがダウンロードおよびインジェストするファイルの最大数を制御するためのパラメータ`--tikv-max-restore-concurrency`が導入されました。このパラメータを設定することで、ジョブキューの最大長（ジョブキューの最大長 = 32 * TiKVノード数 * `--tikv-max-restore-concurrency` ）も制御でき、 BRノードのメモリ消費量を制御できます。 - 通常、 `--tikv-max-restore-concurrency`クラスタ構成に基づいて自動的に調整されるため、手動での設定は不要です。Grafana の**TiKV-Details** > **Backup & Import** > **Import RPC count**監視メトリックで、 BR がダウンロードするファイル数が長時間 0 に近い状態が続く一方で、 BR が取り込むファイル数が常に上限に達している場合は、ファイル取り込みタスクが山積みになり、ジョブキューが最大長に達していることを示しています。この場合、タスク山積みの問題を軽減するために、以下の対策を講じることができます。 + 通常、 `--tikv-max-restore-concurrency`クラスター構成に基づいて自動的に調整されるため、手動での設定は不要です。Grafana の**TiKV-Details** > **Backup & Import** > **Import RPC count**監視メトリックで、 BR がダウンロードするファイル数が長時間 0 に近い状態が続く一方で、 BR が取り込むファイル数が常に上限に達している場合は、ファイル取り込みタスクが山積みになり、ジョブキューが最大長に達していることを示しています。この場合、タスク山積みの問題を軽減するために、以下の対策を講じることができます。 - パラメータ`--ratelimit`を設定するとダウンロード速度が制限され、ファイル取り込みタスクに十分なリソースが確保されます。例えば、TiKVノードのディスクスループットが`x MiB/s`で、バックアップファイルのダウンロードに必要なネットワーク帯域幅が`x/2 MiB/s`超える場合は、パラメータを`--ratelimit x/2`に設定できます。TiKVノードのディスクスループットが`x MiB/s`で、バックアップファイルのダウンロードに必要なネットワーク帯域幅が`x/2 MiB/s`以下の場合は、パラメータ`--ratelimit`を設定せずにそのままにしておくことができます。 - ジョブ キューの最大長を増やすには、 `--tikv-max-restore-concurrency`を増やします。 diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md index c66858254d1b7..4e838dc9b2601 100644 --- a/br/br-snapshot-manual.md +++ b/br/br-snapshot-manual.md @@ -35,7 +35,7 @@ summary: TiDBスナップショットのバックアップと復元コマンド tiup br backup full \ --pd "${PD_IP}:2379" \ --backupts '2024-06-28 13:30:00 +08:00' \ - --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ + --ストレージ "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ --log-file backupfull.log ``` @@ -69,7 +69,7 @@ Full Backup <---------/................................................> 17.12%. tiup br backup db \ --pd "${PD_IP}:2379" \ --db test \ - --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ + --ストレージ "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ --log-file backuptable.log ``` @@ -86,7 +86,7 @@ tiup br backup table \ --pd "${PD_IP}:2379" \ --db test \ --table usertable \ - --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ + --ストレージ "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ --log-file backuptable.log ``` @@ -102,7 +102,7 @@ tiup br backup table \ tiup br backup full \ --pd "${PD_IP}:2379" \ --filter 'db*.tbl*' \ - --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ + --ストレージ "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ --log-file backupfull.log ``` @@ -116,7 +116,7 @@ TiDB v7.5.0以降、 `br`コマンドラインツールに`--ignore-stats`パラ ```shell tiup br backup full \ ---storage local:///br_data/ --pd "${PD_IP}:2379" --log-file restore.log \ +--ストレージ local:///br_data/ --pd "${PD_IP}:2379" --log-file restore.log \ --ignore-stats=false ``` @@ -124,7 +124,7 @@ tiup br backup full \ ```shell tiup br restore full \ ---storage local:///br_data/ --pd "${PD_IP}:2379" --log-file restore.log +--ストレージ local:///br_data/ --pd "${PD_IP}:2379" --log-file restore.log ``` > **注記：** @@ -139,12 +139,12 @@ v8.5.5以降、 BRは`--fast-load-sys-tables`パラメータを導入し、デ ```shell tiup br restore full \ ---storage local:///br_data/ --pd "${PD_IP}:2379" --log-file restore.log --load-stats --fast-load-sys-tables +--ストレージ local:///br_data/ --pd "${PD_IP}:2379" --log-file restore.log --load-stats --fast-load-sys-tables ``` ## バックアップデータを暗号化する {#encrypt-the-backup-data} -BRはバックアップ側でのバックアップデータの暗号化と[Amazon S3にバックアップする際のstorage側](/br/backup-and-restore-storages.md#amazon-s3-server-side-encryption)サポートしています。必要に応じていずれかの暗号化方式を選択できます。 +BRはバックアップ側でのバックアップデータの暗号化と[Amazon S3にバックアップする際のストレージ側](/br/backup-and-restore-ストレージs.md#amazon-s3-server-side-encryption)サポートしています。必要に応じていずれかの暗号化方式を選択できます。 TiDB v5.3.0 以降では、次のパラメータを設定することでバックアップ データを暗号化できます。 @@ -157,7 +157,7 @@ TiDB v5.3.0 以降では、次のパラメータを設定することでバッ ```shell tiup br backup full\ --pd ${PD_IP}:2379 \ - --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ + --ストレージ "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ --crypter.method aes128-ctr \ --crypter.key 0123456789abcdef0123456789abcdef ``` @@ -165,7 +165,7 @@ tiup br backup full\ > **注記：** > > - キーが失われると、バックアップ データをクラスターに復元できなくなります。 -> - 暗号化機能は、 `br`および TiDB クラスタ v5.3.0 以降で使用する必要があります。暗号化されたバックアップデータは、v5.3.0 より前のクラスタでは復元できません。 +> - 暗号化機能は、 `br`および TiDB クラスター v5.3.0 以降で使用する必要があります。暗号化されたバックアップデータは、v5.3.0 より前のクラスターでは復元できません。 ## クラスタースナップショットを復元する {#restore-cluster-snapshots} @@ -175,7 +175,7 @@ tiup br backup full\ tiup br restore full \ --pd "${PD_IP}:2379" \ --with-sys-table \ - --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ + --ストレージ "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ --ratelimit 128 \ --log-file restorefull.log ``` @@ -201,7 +201,7 @@ tiup br restore full \ --pd "${PD_IP}:2379" \ --with-sys-table \ --fast-load-sys-tables \ - --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ + --ストレージ "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ --ratelimit 128 \ --log-file restorefull.log ``` @@ -225,7 +225,7 @@ tiup br restore db \ --pd "${PD_IP}:2379" \ --db "test" \ --ratelimit 128 \ - --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ + --ストレージ "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ --log-file restore_db.log ``` @@ -233,7 +233,7 @@ tiup br restore db \ > **注記：** > -> バックアップデータをリストアする際、 `--db`で指定したデータベース名は、バックアップコマンドの`-- db`で指定したデータベース名と一致している必要があります。一致しない場合、リストアは失敗します。これは、バックアップデータのメタファイル（ `backupmeta`ファイル）にデータベース名が記録されており、同じ名前のデータベースにしかリストアできないためです。推奨される方法は、別のクラスタにある同じ名前のデータベースにバックアップデータをリストアすることです。 +> バックアップデータをリストアする際、 `--db`で指定したデータベース名は、バックアップコマンドの`-- db`で指定したデータベース名と一致している必要があります。一致しない場合、リストアは失敗します。これは、バックアップデータのメタファイル（ `backupmeta`ファイル）にデータベース名が記録されており、同じ名前のデータベースにしかリストアできないためです。推奨される方法は、別のクラスターにある同じ名前のデータベースにバックアップデータをリストアすることです。 ### テーブルを復元する {#restore-a-table} @@ -247,7 +247,7 @@ tiup br restore table \ --db "test" \ --table "usertable" \ --ratelimit 128 \ - --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ + --ストレージ "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ --log-file restore_table.log ``` @@ -263,7 +263,7 @@ tiup br restore table \ tiup br restore full \ --pd "${PD_IP}:2379" \ --filter 'db*.tbl*' \ - --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ + --ストレージ "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ --log-file restorefull.log ``` @@ -279,7 +279,7 @@ tiup br restore full \ --filter 'mysql.bind_info' \ --with-sys-table \ --ratelimit 128 \ - --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ + --ストレージ "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ --log-file restore_system_table.log ``` @@ -307,7 +307,7 @@ ADMIN RELOAD BINDINGS; ```shell tiup br restore full\ --pd "${PD_IP}:2379" \ - --storage "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ + --ストレージ "s3://${backup_collection_addr}/snapshot-${date}?access-key=${access-key}&secret-access-key=${secret-access-key}" \ --crypter.method aes128-ctr \ --crypter.key 0123456789abcdef0123456789abcdef ``` diff --git a/br/br-use-overview.md b/br/br-use-overview.md index a53336a23e7ce..4f10ca28ae1c5 100644 --- a/br/br-use-overview.md +++ b/br/br-use-overview.md @@ -1,6 +1,6 @@ --- title: Usage Overview of TiDB Backup and Restore -summary: TiDB バックアップ＆リストアは、バックアップ方法の選択、バックアップデータの管理、ツールの導入に関するベストプラクティスを提供します。フルバックアップとログバックアップの両方の使用、推奨storageシステムへのデータの保存、バックアップ保持期間の設定が推奨されています。ツールは、コマンドラインツール、SQL文、またはKubernetes上のTiDB Operatorを使用して導入できます。詳細な使用方法については、付属のドキュメントをご覧ください。 +summary: TiDB バックアップ＆リストアは、バックアップ方法の選択、バックアップデータの管理、ツールの導入に関するベストプラクティスを提供します。フルバックアップとログバックアップの両方の使用、推奨ストレージシステムへのデータの保存、バックアップ保持期間の設定が推奨されています。ツールは、コマンドラインツール、SQL文、またはKubernetes上のTiDB Operatorを使用して導入できます。詳細な使用方法については、付属のドキュメントをご覧ください。 --- # TiDB バックアップとリストアの使用概要 {#usage-overview-of-tidb-backup-and-restore} @@ -15,32 +15,32 @@ TiDB のバックアップおよび復元機能を使用する前に、推奨さ **TiDBには2種類のバックアップがあります。どちらを使用すればよいでしょうか？**フルバックアップには、特定の時点におけるクラスターの全データが含まれます。ログバックアップには、TiDBに書き込まれたデータの変更が含まれます。両方のバックアップを同時に使用することをお勧めします。 -- **ログバックアップの開始**： `tiup br log start`のコマンドを実行してログバックアップタスクを開始します。その後、タスクはすべてのTiKVノードで実行され続け、TiDBデータの変更を小さなバッチで指定されたstorageに定期的にバックアップします。 -- **スナップショット（フル）バックアップを定期的に実行する**： `tiup br backup full`のコマンドを実行して、クラスターのスナップショットを指定されたstorageにバックアップします。例えば、毎日午前0時にクラスターのスナップショットをバックアップします。 +- **ログバックアップの開始**： `tiup br log start`のコマンドを実行してログバックアップタスクを開始します。その後、タスクはすべてのTiKVノードで実行され続け、TiDBデータの変更を小さなバッチで指定されたストレージに定期的にバックアップします。 +- **スナップショット（フル）バックアップを定期的に実行する**： `tiup br backup full`のコマンドを実行して、クラスターのスナップショットを指定されたストレージにバックアップします。例えば、毎日午前0時にクラスターのスナップショットをバックアップします。 ### バックアップデータを管理するにはどうすればいいですか? {#how-to-manage-backup-data} BRは基本的なバックアップと復元機能のみを提供し、バックアップ管理はサポートしていません。そのため、バックアップデータの管理方法をご自身で決定する必要があります。具体的には、以下のような点についてご検討ください。 -- どのバックアップstorageシステムを選択すればよいですか? +- どのバックアップストレージシステムを選択すればよいですか? - バックアップ タスク中にバックアップ データをどのディレクトリに配置すればよいですか? - フルバックアップデータとログバックアップデータのディレクトリはどのように整理すればよいですか? -- storageシステム内の履歴バックアップ データをどのように処理しますか? +- ストレージシステム内の履歴バックアップ データをどのように処理しますか? 次のセクションでは、これらの質問に 1 つずつ答えていきます。 -**バックアップstorageシステムを選択する** +**バックアップストレージシステムを選択する** バックアップデータはAmazon S3、Google Cloud Storage（GCS）、またはAzure Blob Storageに保存することをお勧めします。これらのシステムを使用すれば、バックアップ容量や帯域幅の割り当てを気にする必要がありません。 TiDB クラスターを独自に構築したデータ センターに導入する場合は、次のプラクティスが推奨されます。 -- バックアップstorageシステムとして[ミニオ](https://docs.min.io/docs/minio-quickstart-guide.html)構築し、S3 プロトコルを使用してデータを MinIO にバックアップします。 +- バックアップストレージシステムとして[ミニオ](https://docs.min.io/docs/minio-quickstart-guide.html)構築し、S3 プロトコルを使用してデータを MinIO にバックアップします。 - ネットワーク ファイル システム (NFS、NAS など) ディスクを br コマンドライン ツールとすべての TiKV インスタンスにマウントし、POSIX ファイル システム インターフェイスを使用して、バックアップ データを対応する NFS ディレクトリに書き込みます。 > **注記：** > -> NFS、またはAmazon S3、GCS、Azure Blob Storageプロトコルをサポートするstorageシステムを選択しない場合、バックアップデータは各TiKVノードで生成されます。バックアップデータの収集によりデータの冗長性や運用・保守上の問題が発生する可能性があるため、 **BRを使用する方法としては推奨されません**。 +> NFS、またはAmazon S3、GCS、Azure Blob Storageプロトコルをサポートするストレージシステムを選択しない場合、バックアップデータは各TiKVノードで生成されます。バックアップデータの収集によりデータの冗長性や運用・保守上の問題が発生する可能性があるため、 **BRを使用する方法としては推奨されません**。 **バックアップデータディレクトリを整理する** @@ -64,8 +64,8 @@ TiDB クラスターを独自に構築したデータ センターに導入す BRを展開するには、次の要件が満たされていることを確認してください。 -- BR、TiKVノード、およびバックアップstorageシステムは、バックアップ速度よりも大きなネットワーク帯域幅を提供します。ターゲットクラスターが非常に大規模な場合、バックアップおよびリストア速度のしきい値は、バックアップネットワークの帯域幅によって制限されます。 -- バックアップstorageシステムは、十分な読み取りおよび書き込みパフォーマンス（IOPS）を提供します。そうでない場合、バックアップまたは復元中にパフォーマンスのボトルネックになる可能性があります。 +- BR、TiKVノード、およびバックアップストレージシステムは、バックアップ速度よりも大きなネットワーク帯域幅を提供します。ターゲットクラスターが非常に大規模な場合、バックアップおよびリストア速度のしきい値は、バックアップネットワークの帯域幅によって制限されます。 +- バックアップストレージシステムは、十分な読み取りおよび書き込みパフォーマンス（IOPS）を提供します。そうでない場合、バックアップまたは復元中にパフォーマンスのボトルネックになる可能性があります。 - TiKVノードには、バックアップ用に少なくとも2つの追加CPUコアと高性能ディスクが搭載されています。そうでない場合、バックアップがクラスターで実行されているサービスに影響を及ぼす可能性があります。 - BR は、8 個以上のコアと 16 GiB のメモリを備えたノードで実行されます。 diff --git a/br/use-br-command-line-tool.md b/br/use-br-command-line-tool.md index d1e02d34843e0..cc08b007aa184 100644 --- a/br/use-br-command-line-tool.md +++ b/br/use-br-command-line-tool.md @@ -1,6 +1,6 @@ --- title: br Command-line Manual -summary: br` コマンドラインツールは、TiDB クラスターのスナップショットバックアップ、ログバックアップ、およびポイントインタイムリカバリ (PITR) に使用されます。サブコマンド、オプション、およびパラメータで構成されており、PD サービスアドレスの `--pd` やstorageパスの `-s` などの共通オプションがあります。サブコマンドには、それぞれ特定の機能を持つ `tiup br backup`、`tiup br log`、`tiup br restore` などがあります。バックアップコマンドには `full`、`db`、`table` オプションがあり、ログバックアップおよびリストアコマンドには、バックアップ操作を管理するためのさまざまなタスクがあります。 +summary: br` コマンドラインツールは、TiDB クラスターのスナップショットバックアップ、ログバックアップ、およびポイントインタイムリカバリ (PITR) に使用されます。サブコマンド、オプション、およびパラメータで構成されており、PD サービスアドレスの `--pd` やストレージパスの `-s` などの共通オプションがあります。サブコマンドには、それぞれ特定の機能を持つ `tiup br backup`、`tiup br log`、`tiup br restore` などがあります。バックアップコマンドには `full`、`db`、`table` オプションがあり、ログバックアップおよびリストアコマンドには、バックアップ操作を管理するためのさまざまなタスクがあります。 --- # br コマンドラインマニュアル {#br-command-line-manual} @@ -15,14 +15,14 @@ summary: br` コマンドラインツールは、TiDB クラスターのスナ ```shell tiup br backup full --pd "${PD_IP}:2379" \ ---storage "s3://backup-data/snapshot-202209081330/" +--ストレージ "s3://backup-data/snapshot-202209081330/" ``` 上記のコマンドの説明は次のとおりです。 - `backup` : `tiup br`のサブコマンド。 - `full` : `tiup br backup`のサブコマンド。 -- `-s` (または`--storage` ): バックアップ ファイルが保存されるパスを指定するオプション。4 は`"s3://backup-data/snapshot-202209081330/"` `-s`パラメーターです。 +- `-s` (または`--ストレージ` ): バックアップ ファイルが保存されるパスを指定するオプション。4 は`"s3://backup-data/snapshot-202209081330/"` `-s`パラメーターです。 - `--pd` : PD サービス アドレスを指定するオプション`"${PD_IP}:2379"`は`--pd`のパラメーターです。 ### コマンドとサブコマンド {#commands-and-sub-commands} @@ -52,7 +52,7 @@ tiup br backup full --pd "${PD_IP}:2379" \ ### 一般的なオプション {#common-options} - `--pd` : PDサービスアドレスを指定します。例： `"${PD_IP}:2379"` 。 -- `-s` （または`--storage` ）: バックアップファイルを保存するパスを指定します。バックアップデータの保存には、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、NFSがサポートされています。詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 +- `-s` （または`--ストレージ` ）: バックアップファイルを保存するパスを指定します。バックアップデータの保存には、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage、NFSがサポートされています。詳細については、 [外部ストレージサービスのURI形式](/external-ストレージ-uri.md)を参照してください。 - `--ca` : PEM 形式の信頼された CA 証明書へのパスを指定します。 - `--cert` : PEM 形式の SSL 証明書へのパスを指定します。 - `--key` : PEM 形式の SSL 証明書キーへのパスを指定します。 @@ -71,7 +71,7 @@ tiup br backup full --pd "${PD_IP}:2379" \ - [データベースをバックアップする](/br/br-snapshot-manual.md#back-up-a-database) - [テーブルをバックアップする](/br/br-snapshot-manual.md#back-up-a-table) - [テーブルフィルターを使用して複数のテーブルをバックアップする](/br/br-snapshot-manual.md#back-up-multiple-tables-with-table-filter) -- [スナップショットを暗号化する](/br/backup-and-restore-storages.md#server-side-encryption) +- [スナップショットを暗号化する](/br/backup-and-restore-ストレージs.md#server-side-encryption) ## ログバックアップのコマンド {#commands-of-log-backup} diff --git a/cached-tables.md b/cached-tables.md index a916e4c5b18d9..756a242ff9fcd 100644 --- a/cached-tables.md +++ b/cached-tables.md @@ -19,7 +19,7 @@ TiDB v6.0.0では、頻繁にアクセスされるものの更新頻度の低い テーブルのデータ量が少ないにもかかわらず、データへのアクセス頻度が高い場合、TiKVではデータが特定のリージョンに集中し、ホットスポットリージョンと呼ばれるリージョンがパフォーマンスに影響を与えます。そのため、キャッシュテーブルの典型的な使用シナリオは以下のようになります。 -- アプリケーションが構成情報を読み取るコンフィグレーションテーブル。 +- アプリケーションが構成情報を読み取る設定テーブル。 - 金融セクターの為替レート表。これらの表は1日に1回のみ更新され、リアルタイムではありません。 - ほとんど更新されない銀行支店またはネットワーク情報テーブル。 diff --git a/check-before-deployment.md b/check-before-deployment.md index a5e326c191085..e63188e9d9a70 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -3,7 +3,7 @@ title: TiDB Environment and System Configuration Check summary: TiDB をデプロイする前に環境チェック操作について学習します。 --- -# TiDB環境とシステムコンフィグレーションのチェック {#tidb-environment-and-system-configuration-check} +# TiDB環境とシステム設定のチェック {#tidb-environment-and-system-configuration-check} このドキュメントでは、TiDB をデプロイする前に行う環境チェック手順について説明します。以下の手順は優先度順に説明されています。 @@ -123,7 +123,7 @@ TiDBの一部の操作では、サーバーへの一時ファイルの書き込 - TiDB作業領域 - ハッシュテーブルの構築やソートなど、大量のメモリを消費する操作では、メモリ消費量を削減し、安定性を向上させるために、一時データをディスクに書き込むことがあります。書き込み先のディスク上の場所は、設定項目[`tmp-storage-path`](/tidb-configuration-file.md#tmp-storage-path)で定義されます。デフォルト設定では、TiDBを実行するユーザーに、オペレーティングシステムの一時フォルダ（通常は`/tmp` ）への読み取りおよび書き込み権限があることを確認してください。 + ハッシュテーブルの構築やソートなど、大量のメモリを消費する操作では、メモリ消費量を削減し、安定性を向上させるために、一時データをディスクに書き込むことがあります。書き込み先のディスク上の場所は、設定項目[`tmp-ストレージ-path`](/tidb-configuration-file.md#tmp-ストレージ-path)で定義されます。デフォルト設定では、TiDBを実行するユーザーに、オペレーティングシステムの一時フォルダ（通常は`/tmp` ）への読み取りおよび書き込み権限があることを確認してください。 - `Fast Online DDL`作業領域 @@ -219,7 +219,7 @@ firewall-cmd --zone=trusted --list-all ### ファイアウォールを設定する {#configure-the-firewall} -TiDBクラスタコンポーネントのファイアウォールを設定するには、以下のコマンドを使用します。これらの例は参考用です。ゾーン名、ポート、サービスは、実際の環境に合わせて調整してください。 +TiDBクラスターコンポーネントのファイアウォールを設定するには、以下のコマンドを使用します。これらの例は参考用です。ゾーン名、ポート、サービスは、実際の環境に合わせて調整してください。 TiDBコンポーネントのファイアウォールを構成します。 @@ -381,10 +381,10 @@ sudo systemctl enable ntpd.service - [透過的巨大ページ（THP）](/tune-operating-system.md#memorytransparent-huge-page-thp)無効にします。データベースのメモリアクセスは通常、スパースです。高位メモリが著しく断片化されると、THP によるメモリ割り当てのレイテンシーが増大する可能性があります。したがって、パフォーマンスの変動を避けるため、THP を無効にすることをお勧めします。 -- storage媒体の[I/Oスケジューラ](/tune-operating-system.md#io-scheduler)設定します。 +- ストレージ媒体の[I/Oスケジューラ](/tune-operating-system.md#io-scheduler)設定します。 - - 高速SSDstorageの場合、カーネルのデフォルトのI/Oスケジューリング操作によってパフォーマンスが低下する可能性があります。 I/Oスケジューラを`noop`や`none`などの先入先出（FIFO）に設定することをお勧めします。この設定により、カーネルはI/Oリクエストをスケジューリングなしで直接ハードウェアに渡すことができるため、パフォーマンスが向上します。 - - NVMestorageの場合、デフォルトのI/Oスケジューラは`none`なので、調整は必要ありません。 + - 高速SSDストレージの場合、カーネルのデフォルトのI/Oスケジューリング操作によってパフォーマンスが低下する可能性があります。 I/Oスケジューラを`noop`や`none`などの先入先出（FIFO）に設定することをお勧めします。この設定により、カーネルはI/Oリクエストをスケジューリングなしで直接ハードウェアに渡すことができるため、パフォーマンスが向上します。 + - NVMeストレージの場合、デフォルトのI/Oスケジューラは`none`なので、調整は必要ありません。 - CPU周波数を動的に制御する[cpufreqモジュール](/tune-operating-system.md#cpufrequency-scaling)の`performance`モードを選択します。CPU周波数を動的な調整なしでサポートされている最高動作周波数に固定すると、パフォーマンスが最大限に発揮されます。 @@ -679,7 +679,7 @@ sudo systemctl enable ntpd.service SSH相互信頼を設定する際は、すべてのターゲットノードで`tidb`ユーザーを作成して使用することをお勧めします。通常、TiDBではすべてのノードで同じユーザーを使用する必要はありません。ただし、以下のシナリオではユーザーの一貫性に注意してください。 - バックアップと復元 (BR) の使用: すべてのBRおよび TiDB 関連の操作を同じユーザーで実行することを強くお勧めします。 -- NFSなどのネットワークstorageを使用する場合：ユーザーがすべてのノードで同じUIDとGIDを持っていることを確認してください。NFSは、基盤となるUIDとGIDに基づいてファイルアクセス権限を決定します。ノード間でUIDまたはGIDが異なる場合、またはBRを実行しているユーザーがTiDBを実行しているユーザーと異なる場合（特に`sudo`権限がない場合）、バックアップまたはリストア操作中に権限拒否エラーが発生する可能性があります。 +- NFSなどのネットワークストレージを使用する場合：ユーザーがすべてのノードで同じUIDとGIDを持っていることを確認してください。NFSは、基盤となるUIDとGIDに基づいてファイルアクセス権限を決定します。ノード間でUIDまたはGIDが異なる場合、またはBRを実行しているユーザーがTiDBを実行しているユーザーと異なる場合（特に`sudo`権限がない場合）、バックアップまたはリストア操作中に権限拒否エラーが発生する可能性があります。 1. それぞれ`root`ユーザー アカウントを使用してターゲット マシンにログインし、 `tidb`ユーザーを作成してログイン パスワードを設定します。 @@ -738,7 +738,7 @@ sudo yum -y install numactl **方法 2** : `tiup cluster exec`コマンドを実行して、既存のクラスターに NUMA を一括インストールします。 -1. [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)に従ってクラスター`tidb-test`を展開します。TiDB クラスターをインストールしている場合は、この手順をスキップできます。 +1. [TiUPを使用して TiDBクラスターをデプロイ](/production-deployment-using-tiup.md)に従ってクラスター`tidb-test`を展開します。TiDB クラスターをインストールしている場合は、この手順をスキップできます。 ```bash tiup cluster deploy tidb-test v6.1.0 ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa] diff --git a/choose-index.md b/choose-index.md index 5bf3a6359299d..c53ef1c104974 100644 --- a/choose-index.md +++ b/choose-index.md @@ -5,7 +5,7 @@ summary: TiDBクエリ最適化に最適なインデックスを選択してく # インデックス選択 {#index-selection} -storageエンジンからのデータ読み込みは、SQL実行において最も時間のかかるステップの一つです。現在、TiDBは様々なstorageエンジンとインデックスからのデータ読み込みをサポートしています。クエリ実行のパフォーマンスは、適切なインデックスを選択できるかどうかに大きく左右されます。 +ストレージエンジンからのデータ読み込みは、SQL実行において最も時間のかかるステップの一つです。現在、TiDBは様々なストレージエンジンとインデックスからのデータ読み込みをサポートしています。クエリ実行のパフォーマンスは、適切なインデックスを選択できるかどうかに大きく左右されます。 このドキュメントでは、テーブルにアクセスするためのインデックスの選択方法と、インデックス選択を制御するための関連方法について説明します。 @@ -19,14 +19,14 @@ storageエンジンからのデータ読み込みは、SQL実行において最 | :----------------------- | :---------------------------------------------- | :-------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------- | | PointGet / BatchPointGet | 1つ以上の単一ポイント範囲内のテーブルにアクセスする場合。 | どのようなシナリオでも | トリガーされた場合、通常は最も高速な演算子と考えられています。これは、コプロセッサインターフェースを呼び出すのではなく、kvgetインターフェースを直接呼び出して計算を実行するためです。 | | テーブルリーダー | なし | どのようなシナリオでも | この TableReader オペレーターは TiKV 用です。一般的に、TiKVレイヤーからテーブルデータを直接スキャンするオペレーターの中で最も効率が悪いと考えられています。 `_tidb_rowid`列に範囲クエリがある場合、またはテーブルにアクセスするための他のオペレーターが選択できない場合にのみ選択できます。 | -| テーブルリーダー | テーブルはTiFlashノード上に複製されます。 | 読み込む列の数は少ないが、評価する行の数は多い。 | この TableReader 演算子はTiFlash用です。TiFlashは列ベースのstorageです。列数が少なく行数が多い場合、この演算子を選択することをお勧めします。 | +| テーブルリーダー | テーブルはTiFlashノード上に複製されます。 | 読み込む列の数は少ないが、評価する行の数は多い。 | この TableReader 演算子はTiFlash用です。TiFlashは列ベースのストレージです。列数が少なく行数が多い場合、この演算子を選択することをお勧めします。 | | インデックスリーダー | テーブルには1つ以上のインデックスがあり、計算に必要な列はインデックスに含まれています。 | インデックスに対してより狭い範囲のクエリを実行する場合、またはインデックス付き列に順序要件がある場合。 | 複数の指標が存在する場合は、コスト見積もりに基づいて適切な指標が選択されます。 | | IndexLookupReader | テーブルには1つ以上のインデックスがあり、計算に必要な列がインデックスに完全に含まれていない。 | IndexReaderと同じです。 | インデックスは計算列を完全にカバーしていないため、TiDBはインデックスを読み取った後にテーブルから行を取得する必要があります。これはIndexReaderオペレーターと比較して追加のコストがかかります。 | | インデックスマージ | テーブルには複数のインデックス、または複数値インデックスが存在する。 | 複数値インデックスまたは複数のインデックスが使用される場合。 | 演算子を使用するには、[オプティマイザのヒント](/optimizer-hints.md)を指定するか、コスト見積もりに基づいてオプティマイザにこの演算子を自動的に選択させることができます。詳細については、[インデックスマージを使用した説明文](/explain-index-merge.md)を参照してください。 | > **注記：** > -> TableReader演算子は`_tidb_rowid`列インデックスに基づいており、 TiFlashは列storageインデックスを使用するため、インデックスの選択はテーブルにアクセスするための演算子の選択となります。 +> TableReader演算子は`_tidb_rowid`列インデックスに基づいており、 TiFlashは列ストレージインデックスを使用するため、インデックスの選択はテーブルにアクセスするための演算子の選択となります。 ## インデックス選択ルール {#index-selection-rules} @@ -114,7 +114,7 @@ mysql> SHOW WARNINGS; スカイライン剪定ルールを使用して不適切なインデックスを除外した後、インデックスの選択は完全にコスト見積もりに基づいて行われます。テーブルへのアクセスにかかるコスト見積もりには、以下の点を考慮する必要があります。 -- storageエンジン内のインデックス付きデータの各行の平均長。 +- ストレージエンジン内のインデックス付きデータの各行の平均長。 - インデックスによって生成されたクエリ範囲内の行数。 - テーブルから行を取得するのにかかるコスト。 - クエリ実行中にインデックスによって生成される範囲の数。 @@ -141,7 +141,7 @@ mysql> SHOW WARNINGS; - `USE_INDEX` / `IGNORE_INDEX`オプティマイザに特定のインデックスを使用/使用しないように強制できます。 `FORCE_INDEX`と`USE_INDEX`は同じ効果があります。 -- `READ_FROM_STORAGE`オプティマイザに特定のテーブルに対してクエリを実行するために TiKV / TiFlashstorageエンジンを選択するように強制できます。 +- `READ_FROM_STORAGE`オプティマイザに特定のテーブルに対してクエリを実行するために TiKV / TiFlashストレージエンジンを選択するように強制できます。 ## 複数値インデックスを使用する {#use-multi-valued-indexes} diff --git a/clinic/clinic-data-instruction-for-tiup.md b/clinic/clinic-data-instruction-for-tiup.md index 9f1085953a79d..a21fb1442fa51 100644 --- a/clinic/clinic-data-instruction-for-tiup.md +++ b/clinic/clinic-data-instruction-for-tiup.md @@ -5,11 +5,11 @@ summary: PingCAPクリニック診断サービスは、 TiUPを使用してTiDB # PingCAPクリニック診断データ {#pingcap-clinic-diagnostic-data} -このドキュメントでは、 TiUPを使用して展開された TiDB および DM クラスタからPingCAPクリニック診断サービス (PingCAPクリニック ) によって収集できる診断データの種類について説明します。また、各データの種類に対応するデータ収集パラメータも示します。1 [Diagクライアント（Diag）を使用してデータを収集する](/clinic/clinic-user-guide-for-tiup.md)コマンドを実行する際に、収集するデータの種類に応じて必要なパラメータをコマンドに追加できます。 +このドキュメントでは、 TiUPを使用して展開された TiDB および DM クラスターからPingCAPクリニック診断サービス (PingCAPクリニック ) によって収集できる診断データの種類について説明します。また、各データの種類に対応するデータ収集パラメータも示します。1 [Diagクライアント（Diag）を使用してデータを収集する](/clinic/clinic-user-guide-for-tiup.md)コマンドを実行する際に、収集するデータの種類に応じて必要なパラメータをコマンドに追加できます。 PingCAPクリニックによって収集された診断データは、クラスターの問題のトラブルシューティングに**のみ**使用されます。 -クラウドに展開される診断サービスである Clinic Server は、データのstorage場所に応じて 2 つの独立したサービスを提供します。 +クラウドに展開される診断サービスである Clinic Server は、データのストレージ場所に応じて 2 つの独立したサービスを提供します。 - [海外ユーザー向けクリニックサーバー](https://clinic.pingcap.com) ：収集したデータを海外ユーザー向けのClinic Serverにアップロードすると、データはPingCAPがAWS米国リージョンに展開するAmazon S3サービスに保存されます。PingCAPは厳格なデータアクセスポリシーを採用しており、承認されたテクニカルサポート担当者のみがデータにアクセスできます。 - [中国本土のユーザー向けクリニックサーバー](https://clinic.pingcap.com.cn) ：収集したデータを中国本土のユーザー向けクリニックサーバーにアップロードすると、データはPingCAPが中国（北京）リージョンに展開するAmazon S3サービスに保存されます。PingCAPは厳格なデータアクセスポリシーを採用しており、承認されたテクニカルサポート担当者のみがデータにアクセスできます。 @@ -18,7 +18,7 @@ PingCAPクリニックによって収集された診断データは、クラス このセクションでは、 TiUPを使用して展開された TiDB クラスターから[診断](https://github.com/pingcap/diag)によって収集できる診断データの種類を示します。 -### TiDB クラスタ情報 {#tidb-cluster-information} +### TiDB クラスター情報 {#tidb-cluster-information} | データ型 | エクスポートされたファイル | PingCAPクリニックによるデータ収集パラメータ | | :------------------- | :------------- | :------------------------ | @@ -33,7 +33,7 @@ PingCAPクリニックによって収集された診断データは、クラス | エラーログ | `tidb_stderr.log` | `--include=log` | | スローログ | `tidb_slow_query.log` | `--include=log` | | 監査ログ | `tidb-audit.log.json` | `--include=log` | -| コンフィグレーションファイル | `tidb.toml` | `--include=config` | +| 設定ファイル | `tidb.toml` | `--include=config` | | リアルタイム構成 | `config.json` | `--include=config` | ### TiKV診断データ {#tikv-diagnostic-data} @@ -42,7 +42,7 @@ PingCAPクリニックによって収集された診断データは、クラス | :------------- | :---------------- | :------------------------ | | ログ | `tikv.log` | `--include=log` | | エラーログ | `tikv_stderr.log` | `--include=log` | -| コンフィグレーションファイル | `tikv.toml` | `--include=config` | +| 設定ファイル | `tikv.toml` | `--include=config` | | リアルタイム構成 | `config.json` | `--include=config` | ### PD診断データ {#pd-diagnostic-data} @@ -51,7 +51,7 @@ PingCAPクリニックによって収集された診断データは、クラス | :--------------------------------------------------------------------------------------------- | :-------------------- | :------------------------ | | ログ | `pd.log` | `--include=log` | | エラーログ | `pd_stderr.log` | `--include=log` | -| コンフィグレーションファイル | `pd.toml` | `--include=config` | +| 設定ファイル | `pd.toml` | `--include=config` | | リアルタイム構成 | `config.json` | `--include=config` | | コマンド`tiup ctl:v pd -u http://${pd IP}:${PORT} store`の出力 | `store.json` | `--include=config` | | コマンド`tiup ctl:v pd -u http://${pd IP}:${PORT} config placement-rules show`の出力 | `placement-rule.json` | `--include=config` | @@ -62,7 +62,7 @@ PingCAPクリニックによって収集された診断データは、クラス | :------------- | :---------------------------------------------------------------- | :------------------------ | | ログ | `tiflash.log` | `--include=log` | | エラーログ | `tiflash_stderr.log` | `--include=log` | -| コンフィグレーションファイル | `tiflash-learner.toml` `tiflash-preprocessed.toml` `tiflash.toml` | `--include=config` | +| 設定ファイル | `tiflash-learner.toml` `tiflash-preprocessed.toml` `tiflash.toml` | `--include=config` | | リアルタイム構成 | `config.json` | `--include=config` | ### TiCDC診断データ {#ticdc-diagnostic-data} @@ -71,7 +71,7 @@ PingCAPクリニックによって収集された診断データは、クラス | :------------- | :------------------------------------------------------------------------ | :------------------------------------------------ | | ログ | `ticdc.log` | `--include=log` | | エラーログ | `ticdc_stderr.log` | `--include=log` | -| コンフィグレーションファイル | `ticdc.toml` | `--include=config` | +| 設定ファイル | `ticdc.toml` | `--include=config` | | デバッグデータ | `info.txt` `status.txt` `changefeeds.txt` `captures.txt` `processors.txt` | `--include=debug` (Diag はデフォルトではこのデータ タイプを収集しません) | ### プロメテウス監視データ {#prometheus-monitoring-data} @@ -88,7 +88,7 @@ PingCAPクリニックによって収集された診断データは、クラス | TiDB システム変数 | `mysql.tidb.csv` | `--include=db_vars` (Diag はデフォルトではこのデータ タイプを収集しません。このデータ タイプを収集する必要がある場合は、データベース資格情報が必要です) | | | `global_variables.csv` | `--include=db_vars` (Diag はデフォルトではこのデータ タイプを収集しません) | -### クラスタノードのシステム情報 {#system-information-of-the-cluster-node} +### クラスターノードのシステム情報 {#system-information-of-the-cluster-node} | データ型 | エクスポートされたファイル | PingCAPクリニックによるデータ収集パラメータ | | :----------------------------- | :------------- | :------------------------ | @@ -115,7 +115,7 @@ PingCAPクリニックによって収集された診断データは、クラス | :------------- | :--------------------- | :------------------------ | | ログ | `dm-master.log` | `--include=log` | | エラーログ | `dm-master_stderr.log` | `--include=log` | -| コンフィグレーションファイル | `dm-master.toml` | `--include=config` | +| 設定ファイル | `dm-master.toml` | `--include=config` | ### dm-worker診断データ {#dm-worker-diagnostic-data} @@ -123,7 +123,7 @@ PingCAPクリニックによって収集された診断データは、クラス | :------------- | :--------------------- | :------------------------ | | ログ | `dm-worker.log` | `--include=log` | | エラーログ | `dm-worker_stderr.log` | `--include=log` | -| コンフィグレーションファイル | `dm-work.toml` | `--include=config` | +| 設定ファイル | `dm-work.toml` | `--include=config` | ### プロメテウス監視データ {#prometheus-monitoring-data} @@ -132,7 +132,7 @@ PingCAPクリニックによって収集された診断データは、クラス | すべての指標データ | `{metric_name}.json` | `--include=monitor` | | すべてのアラートデータ | `alerts.json` | `--include=monitor` | -### クラスタノードのシステム情報 {#system-information-of-the-cluster-node} +### クラスターノードのシステム情報 {#system-information-of-the-cluster-node} | データ型 | エクスポートされたファイル | PingCAPクリニックによるデータ収集パラメータ | | :--------------------------------- | :------------- | :------------------------ | diff --git a/clinic/clinic-introduction.md b/clinic/clinic-introduction.md index 1b4f8824133fc..17a85924b1dee 100644 --- a/clinic/clinic-introduction.md +++ b/clinic/clinic-introduction.md @@ -1,17 +1,17 @@ --- title: PingCAP Clinic Overview -summary: PingCAPクリニックは、 TiUPまたはTiDB Operatorを使用して導入されたTiDBクラスタ向けの診断サービスです。クラスタの問題をリモートでトラブルシューティングし、安定した運用を保証し、クラスタの状態を迅速に確認できます。このサービスには、データ収集用のDiagクライアントと、オンライン診断レポート用のClinic Serverが含まれています。ユーザーはリモートで問題をトラブルシューティングし、クラスタの状態を迅速に確認できます。Diagはさまざまな方法で診断データを収集しますが、Clinic Serverにはクラスタ、storage、およびデータサイズに制限があります。このサービスは2025年4月15日まで無料でご利用いただけます。今後の展開としては、 PingCAPクリニックをさまざまな環境で活用していく予定です。 +summary: PingCAPクリニックは、 TiUPまたはTiDB Operatorを使用して導入されたTiDBクラスター向けの診断サービスです。クラスターの問題をリモートでトラブルシューティングし、安定した運用を保証し、クラスターの状態を迅速に確認できます。このサービスには、データ収集用のDiagクライアントと、オンライン診断レポート用のClinic Serverが含まれています。ユーザーはリモートで問題をトラブルシューティングし、クラスターの状態を迅速に確認できます。Diagはさまざまな方法で診断データを収集しますが、Clinic Serverにはクラスター、ストレージ、およびデータサイズに制限があります。このサービスは2025年4月15日まで無料でご利用いただけます。今後の展開としては、 PingCAPクリニックをさまざまな環境で活用していく予定です。 --- # PingCAPクリニックの概要 {#pingcap-clinic-overview} -PingCAPクリニック診断サービス（PingCAPクリニック）は、 TiUPまたはTiDB Operatorを使用して導入されたTiDBクラスタ向けにPingCAPが提供する診断サービスです。このサービスは、クラスタの問題をリモートでトラブルシューティングし、ローカルでクラスタの状態を迅速に確認するのに役立ちます。PingCAP PingCAPクリニックを利用することで、TiDBクラスタのライフサイクル全体にわたる安定した運用を確保し、潜在的な問題を予測し、問題発生の可能性を低減し、クラスタの問題を迅速にトラブルシューティングして修復することができます。 +PingCAPクリニック診断サービス（PingCAPクリニック）は、 TiUPまたはTiDB Operatorを使用して導入されたTiDBクラスター向けにPingCAPが提供する診断サービスです。このサービスは、クラスターの問題をリモートでトラブルシューティングし、ローカルでクラスターの状態を迅速に確認するのに役立ちます。PingCAP PingCAPクリニックを利用することで、TiDBクラスターのライフサイクル全体にわたる安定した運用を確保し、潜在的な問題を予測し、問題発生の可能性を低減し、クラスターの問題を迅速にトラブルシューティングして修復することができます。 PingCAPクリニック は、クラスターの問題を診断するために次の 2 つのコンポーネントを提供します。 - [診断クライアント](https://github.com/pingcap/diag) : - Diagクライアント（Diag）は、クラスタ側にデプロイされるオープンソースの診断ツールです。Diagは、クラスタ診断データの収集、Clinic Serverへの診断データのアップロード、そしてクラスタ上でローカルで簡単なヘルスチェックを実行するために使用されます。Diagで収集できる診断データの全リストについては、 [PingCAPクリニック診断データ](/clinic/clinic-data-instruction-for-tiup.md)ご覧ください。 + Diagクライアント（Diag）は、クラスター側にデプロイされるオープンソースの診断ツールです。Diagは、クラスター診断データの収集、Clinic Serverへの診断データのアップロード、そしてクラスター上でローカルで簡単なヘルスチェックを実行するために使用されます。Diagで収集できる診断データの全リストについては、 [PingCAPクリニック診断データ](/clinic/clinic-data-instruction-for-tiup.md)ご覧ください。 > **注記：** > @@ -19,26 +19,26 @@ PingCAPクリニック は、クラスターの問題を診断するために次 - クリニックサーバー: - Clinic Serverはクラウド上に展開されるクラウドサービスです。SaaSモデルで診断サービスを提供することで、Clinic Serverはアップロードされた診断データを受信するだけでなく、データの保存、閲覧、クラスター診断レポートの提供など、オンライン診断環境として機能します。Clinic Serverは、storage場所に応じて2つの独立したサービスを提供します。 + Clinic Serverはクラウド上に展開されるクラウドサービスです。SaaSモデルで診断サービスを提供することで、Clinic Serverはアップロードされた診断データを受信するだけでなく、データの保存、閲覧、クラスター診断レポートの提供など、オンライン診断環境として機能します。Clinic Serverは、ストレージ場所に応じて2つの独立したサービスを提供します。 - [海外ユーザー向けクリニックサーバー](https://clinic.pingcap.com) : データは米国の AWS に保存されます。 - [中国本土のユーザー向けクリニックサーバー](https://clinic.pingcap.com.cn) : データは中国 (北京) リージョンの AWS に保存されます。 ## ユーザーシナリオ {#user-scenarios} -- クラスタの問題をリモートでトラブルシューティングする +- クラスターの問題をリモートでトラブルシューティングする - クラスターにすぐに解決できない問題が発生した場合、PingCAPまたはコミュニティから[サポートを受ける](/support.md)選択できます。リモートアシスタンスのためにテクニカルサポートに連絡する場合、クラスターからさまざまな診断データを保存し、サポートスタッフに転送する必要があります。この場合、Diagを使用すると、ワンクリックで診断データを収集できます。Diagを使用すると、完全な診断データを迅速に収集できるため、複雑な手動データ収集操作を回避できます。データを収集した後、PingCAPテクニカルサポートスタッフがクラスターの問題をトラブルシューティングできるように、データをクリニックサーバーにアップロードできます。クリニックサーバーは、アップロードされた診断データを安全にstorageし、オンライン診断をサポートすることで、トラブルシューティングの効率を大幅に向上させます。 + クラスターにすぐに解決できない問題が発生した場合、PingCAPまたはコミュニティから[サポートを受ける](/support.md)選択できます。リモートアシスタンスのためにテクニカルサポートに連絡する場合、クラスターからさまざまな診断データを保存し、サポートスタッフに転送する必要があります。この場合、Diagを使用すると、ワンクリックで診断データを収集できます。Diagを使用すると、完全な診断データを迅速に収集できるため、複雑な手動データ収集操作を回避できます。データを収集した後、PingCAPテクニカルサポートスタッフがクラスターの問題をトラブルシューティングできるように、データをクリニックサーバーにアップロードできます。クリニックサーバーは、アップロードされた診断データを安全にストレージし、オンライン診断をサポートすることで、トラブルシューティングの効率を大幅に向上させます。 - クラスターのステータスを素早く確認 - クラスタが現時点で安定して動作している場合でも、潜在的な安定性リスクを検出するために、定期的にクラスタを検査する必要があります。PingCAP PingCAPクリニックが提供するローカルおよびサーバー側のクイックチェック機能を使用することで、クラスタの潜在的な健全性リスクを特定できます。 + クラスターが現時点で安定して動作している場合でも、潜在的な安定性リスクを検出するために、定期的にクラスターを検査する必要があります。PingCAP PingCAPクリニックが提供するローカルおよびサーバー側のクイックチェック機能を使用することで、クラスターの潜在的な健全性リスクを特定できます。 ## 実施原則 {#implementation-principles} このセクションでは、Diag がクラスターから診断データを収集する実装原則について説明します。 -まず、Diag はデプロイメントツールTiUP (tiup-cluster) またはTiDB Operator ( tidb-operator ) からクラスタトポロジ情報を取得します。次に、Diag は以下のような様々なデータ収集方法を通じて、様々な種類の診断データを収集します。 +まず、Diag はデプロイメントツールTiUP (tiup-cluster) またはTiDB Operator ( tidb-operator ) からクラスタートポロジ情報を取得します。次に、Diag は以下のような様々なデータ収集方法を通じて、様々な種類の診断データを収集します。 - SCP 経由でサーバーファイルを転送する @@ -80,5 +80,5 @@ PingCAPクリニック は、クラスターの問題を診断するために次 - [PingCAPクリニック診断データ](/clinic/clinic-data-instruction-for-tiup.md) - Kubernetes でPingCAPクリニックを使用する - - [PingCAPクリニックを使用して TiDBクラスタのトラブルシューティングを行う](https://docs.pingcap.com/tidb-in-kubernetes/stable/clinic-user-guide) + - [PingCAPクリニックを使用して TiDBクラスターのトラブルシューティングを行う](https://docs.pingcap.com/tidb-in-kubernetes/stable/clinic-user-guide) - [PingCAPクリニック診断データ](https://docs.pingcap.com/tidb-in-kubernetes/stable/clinic-data-collection) diff --git a/clinic/clinic-user-guide-for-tiup.md b/clinic/clinic-user-guide-for-tiup.md index 502b85aea1c94..de5fb0edbd05b 100644 --- a/clinic/clinic-user-guide-for-tiup.md +++ b/clinic/clinic-user-guide-for-tiup.md @@ -15,14 +15,14 @@ TiUPを使用して導入された TiDB クラスターおよび DM クラスタ ## ユーザーシナリオ {#user-scenarios} -- [クラスタの問題をリモートでトラブルシューティングする](#troubleshoot-cluster-problems-remotely) +- [クラスターの問題をリモートでトラブルシューティングする](#troubleshoot-cluster-problems-remotely) - クラスターに問題がある場合、PingCAP から[サポートを受ける](/support.md)取得する必要があります。リモート トラブルシューティングを容易にするために、Diag を使用して診断データを収集し、収集したデータを Clinic Server にアップロードし、データ アクセス リンクをテクニカル サポート スタッフに提供するための次の操作を実行できます。 - クラスターに何らかの問題があり、すぐに問題を分析できない場合は、Diag を使用してデータを収集し、後で分析できるように保存することができます。 -- [ローカルでクラスタのステータスをクイックチェックする](#perform-a-quick-check-on-the-cluster-status-locally) +- [ローカルでクラスターのステータスをクイックチェックする](#perform-a-quick-check-on-the-cluster-status-locally) - クラスタが現在安定して動作している場合でも、潜在的な安定性リスクを検出するために、定期的にクラスタを検査する必要があります。PingCAP PingCAPクリニックが提供するローカルクイックチェック機能を使用すると、クラスタの潜在的なヘルスリスクを特定できます。ローカルチェックでは構成のみがチェックされます。メトリックやログなど、より多くの項目をチェックするには、診断データをClinic Serverにアップロードし、ヘルスレポート機能を使用することをお勧めします。 + クラスターが現在安定して動作している場合でも、潜在的な安定性リスクを検出するために、定期的にクラスターを検査する必要があります。PingCAP PingCAPクリニックが提供するローカルクイックチェック機能を使用すると、クラスターの潜在的なヘルスリスクを特定できます。ローカルチェックでは構成のみがチェックされます。メトリックやログなど、より多くの項目をチェックするには、診断データをClinic Serverにアップロードし、ヘルスレポート機能を使用することをお勧めします。 ## 前提条件 {#prerequisites} @@ -44,7 +44,7 @@ PingCAPクリニックを使用する前に、Diag（ PingCAPクリニックが > **注記：** > - > - インターネット接続のないクラスタでは、Diagをオフラインで展開する必要があります。詳細については、 [TiUPをオフラインでデプロイ: 方法2](/production-deployment-using-tiup.md#deploy-tiup-offline)を参照してください。 + > - インターネット接続のないクラスターでは、Diagをオフラインで展開する必要があります。詳細については、 [TiUPをオフラインでデプロイ: 方法2](/production-deployment-using-tiup.md#deploy-tiup-offline)を参照してください。 > - Diag は、TiDB Server オフライン ミラー パッケージ v5.4.0 以降で**のみ**提供されます。 2. データをアップロードするためのアクセス トークン (トークン) を取得して設定します。 @@ -69,7 +69,7 @@ PingCAPクリニックを使用する前に、Diag（ PingCAPクリニックが - - クラスタページの右下隅にあるアイコンをクリックし、 **「診断ツールのアクセストークンを取得」**を選択して、ポップアップウィンドウの**「+」**をクリックします。表示されるトークンをコピーして保存してください。 + - クラスターページの右下隅にあるアイコンをクリックし、 **「診断ツールのアクセストークンを取得」**を選択して、ポップアップウィンドウの**「+」**をクリックします。表示されるトークンをコピーして保存してください。 ![Get the Token](/media/clinic-get-token.png) @@ -120,7 +120,7 @@ PingCAPクリニックを使用する前に、Diag（ PingCAPクリニックが TiDBが詳細なログ情報を提供する場合、ログに機密情報（ユーザーデータなど）が出力される可能性があります。ローカルログおよびClinic Serverへの機密情報の漏洩を防ぎたい場合は、TiDB側でログ編集を有効にすることができます。詳細については、 [ログ編集](/log-redaction.md#log-redaction-in-tidb-side)ご覧ください。 -## クラスタの問題をリモートでトラブルシューティングする {#troubleshoot-cluster-problems-remotely} +## クラスターの問題をリモートでトラブルシューティングする {#troubleshoot-cluster-problems-remotely} Diag を使用すると、監視データや構成情報などの診断データを TiDB クラスターおよび DM クラスターから迅速に収集できます。 @@ -184,7 +184,7 @@ Diag を使用すると、 TiUPを使用して展開された TiDB クラスタ > curl -s 'http://${prometheus-host}:${prometheus-port}/api/v1/label/__name__/values' | jq -r '.data[]' | cut -d\_ -f1 | uniq -c | sort -rn > ``` - コマンドを実行した後、Diag はすぐにデータの収集を開始するわけではありません。代わりに、Diag は推定データサイズとターゲットデータstorageパスを出力に表示し、続行するかどうかを確認します。例: + コマンドを実行した後、Diag はすぐにデータの収集を開始するわけではありません。代わりに、Diag は推定データサイズとターゲットデータストレージパスを出力に表示し、続行するかどうかを確認します。例: ```bash Estimated size of data to collect: @@ -211,14 +211,14 @@ Diag を使用すると、 TiUPを使用して展開された TiDB クラスタ ### ステップ3. ローカルでデータをビュー（オプション） {#step-3-view-data-locally-optional} -収集されたデータは、データソースに基づいて個別のサブディレクトリに保存されます。これらのサブディレクトリは、マシン名とポート番号に基づいて名前が付けられます。各ノードの設定、ログ、その他のファイルのstorage場所は、TiDBクラスターの実サーバーにおける相対的なstorageパスと同じです。 +収集されたデータは、データソースに基づいて個別のサブディレクトリに保存されます。これらのサブディレクトリは、マシン名とポート番号に基づいて名前が付けられます。各ノードの設定、ログ、その他のファイルのストレージ場所は、TiDBクラスターの実サーバーにおける相対的なストレージパスと同じです。 - システムとハードウェアの基本情報： `insight.json` - システム`/etc/security/limits.conf`の内容： `limits.conf` - カーネルパラメータのリスト: `sysctl.conf` - カーネルログ: `dmesg.log` - データ収集中のネットワーク接続: `ss.txt` -- コンフィグレーションデータ：各ノードの`config.json`ディレクトリ +- 設定データ：各ノードの`config.json`ディレクトリ - クラスター自体のメタ情報: in `meta.yaml` (このファイルは収集されたデータを保存するディレクトリの最上位にあります) - 監視データ： `/monitor`ファイルディレクトリ内。監視データはデフォルトで圧縮されており、直接表示できません。監視データを含むJSONファイルを直接表示するには、データ収集時に`--compress-metrics=false`パラメータで圧縮を無効にしてください。 @@ -282,9 +282,9 @@ tiup diag upload 3. アップロードが完了したら、 `Download URL`のリンクを開いてアップロードされたデータを確認するか、以前に連絡した PingCAP テクニカル サポート スタッフにリンクを送信することができます。 -## ローカルでクラスタのステータスをクイックチェックする {#perform-a-quick-check-on-the-cluster-status-locally} +## ローカルでクラスターのステータスをクイックチェックする {#perform-a-quick-check-on-the-cluster-status-locally} -Diag を使用すると、クラスタの状態をローカルで簡単に確認できます。クラスタが現在安定して動作している場合でも、潜在的な安定性リスクを検出するために、定期的にクラスタの状態を確認する必要があります。PingCAP PingCAPクリニックが提供するローカルクイックチェック機能を使用すると、クラスタの潜在的なヘルスリスクを特定できます。ローカルチェックでは構成のみがチェックされます。メトリックやログなど、より多くの項目を確認するには、診断データを Clinic サーバーにアップロードし、ヘルスレポート機能を使用することをお勧めします。 +Diag を使用すると、クラスターの状態をローカルで簡単に確認できます。クラスターが現在安定して動作している場合でも、潜在的な安定性リスクを検出するために、定期的にクラスターの状態を確認する必要があります。PingCAP PingCAPクリニックが提供するローカルクイックチェック機能を使用すると、クラスターの潜在的なヘルスリスクを特定できます。ローカルチェックでは構成のみがチェックされます。メトリックやログなど、より多くの項目を確認するには、診断データを Clinic サーバーにアップロードし、ヘルスレポート機能を使用することをお勧めします。 1. 構成データを収集します。 @@ -292,7 +292,7 @@ Diag を使用すると、クラスタの状態をローカルで簡単に確認 tiup diag collect ${cluster-name} --include="config" ``` - 設定ファイルのデータは比較的小さく、収集後、デフォルトで現在のパスに保存されます。テスト環境では、18ノードのクラスタの場合、設定ファイルのデータサイズは10KB未満でした。 + 設定ファイルのデータは比較的小さく、収集後、デフォルトで現在のパスに保存されます。テスト環境では、18ノードのクラスターの場合、設定ファイルのデータサイズは10KB未満でした。 2. 構成データを診断します。 diff --git a/clinic/quick-start-with-clinic.md b/clinic/quick-start-with-clinic.md index 3d6a202518faa..ccfeea8a27693 100644 --- a/clinic/quick-start-with-clinic.md +++ b/clinic/quick-start-with-clinic.md @@ -111,7 +111,7 @@ PingCAPクリニックを使用する前に、Diag をインストールし、 tiup diag collect ${cluster-name} -f="-4h" -t="-2h" ``` - コマンドを実行しても、Diag はすぐにデータ収集を開始するわけではありません。代わりに、Diag は推定データサイズとターゲットデータstorageパスを出力に表示し、続行するかどうかを確認します。データ収集を開始するには、 `Y`と入力してください。 + コマンドを実行しても、Diag はすぐにデータ収集を開始するわけではありません。代わりに、Diag は推定データサイズとターゲットデータストレージパスを出力に表示し、続行するかどうかを確認します。データ収集を開始するには、 `Y`と入力してください。 収集が完了すると、Diag は収集されたデータが保存されているフォルダー パスを提供します。 diff --git a/clustered-indexes.md b/clustered-indexes.md index 89628f00e7a8b..b12850dfabef4 100644 --- a/clustered-indexes.md +++ b/clustered-indexes.md @@ -1,45 +1,45 @@ --- title: Clustered Indexes -summary: クラスタ化インデックスの概念、ユーザーシナリオ、使用方法、制限事項、および互換性について学びます。 +summary: クラスター化インデックスの概念、ユーザーシナリオ、使用方法、制限事項、および互換性について学びます。 --- # クラスター化インデックス {#clustered-indexes} -TiDBはバージョン5.0以降、クラスタ化インデックス機能をサポートしています。この機能は、主キーを含むテーブルへのデータの格納方法を制御します。これにより、TiDBは特定のクエリのパフォーマンスを向上させるような方法でテーブルを整理することができます。 +TiDBはバージョン5.0以降、クラスター化インデックス機能をサポートしています。この機能は、主キーを含むテーブルへのデータの格納方法を制御します。これにより、TiDBは特定のクエリのパフォーマンスを向上させるような方法でテーブルを整理することができます。 -この文脈における*「クラスタ化」*という用語は*、データの格納方法の構成を*指し、*連携して動作するデータベースサーバーのグループを*指すものではありません。一部のデータベース管理システムでは、クラスタ化されたインデックステーブルを*インデックス構成テーブル*（IOT）と呼んでいます。 +この文脈における*「クラスター化」*という用語は*、データの格納方法の構成を*指し、*連携して動作するデータベースサーバーのグループを*指すものではありません。一部のデータベース管理システムでは、クラスター化されたインデックステーブルを*インデックス構成テーブル*（IOT）と呼んでいます。 現在、TiDBの主キーを含むテーブルは、以下の2つのカテゴリに分類されます。 - `NONCLUSTERED` : テーブルの主キーは非クラスター化インデックスです。非クラスター化インデックスを持つテーブルでは、行データのキーは、TiDB によって暗黙的に割り当てられる内部の[`_tidb_rowid`](/tidb-rowid.md)値で構成されます。主キーは基本的に一意のインデックスであるため、非クラスター化インデックスを持つテーブルでは、行を格納するために少なくとも 2 つのキーと値のペアが必要です。それらは次のとおりです。 - `_tidb_rowid` （キー） - 行データ（値） - 主キーデータ（キー） - `_tidb_rowid` （値） -- `CLUSTERED` : テーブルの主キーはクラスタ化インデックスです。クラスタ化インデックスを持つテーブルでは、行データのキーはユーザーが指定した主キーデータで構成されます。したがって、クラスタ化インデックスを持つテーブルでは、行を格納するために必要なキーと値のペアは1つだけです。それは次のとおりです。 +- `CLUSTERED` : テーブルの主キーはクラスター化インデックスです。クラスター化インデックスを持つテーブルでは、行データのキーはユーザーが指定した主キーデータで構成されます。したがって、クラスター化インデックスを持つテーブルでは、行を格納するために必要なキーと値のペアは1つだけです。それは次のとおりです。 - 主キーデータ（キー） - 行データ（値） > **注記：** > -> TiDB は、テーブルの`PRIMARY KEY`によるクラスタリングのみをサポートしています。クラスタ化インデックスが有効になっている場合、 *{* `PRIMARY KEY`と*クラスタ化インデックス*という用語は同じ意味で使用されることがあります。 `PRIMARY KEY`は制約 (論理プロパティ) を指し、クラスタ化インデックスはデータの格納方法の物理的な実装を表します。 +> TiDB は、テーブルの`PRIMARY KEY`によるクラスターリングのみをサポートしています。クラスター化インデックスが有効になっている場合、 *{* `PRIMARY KEY`と*クラスター化インデックス*という用語は同じ意味で使用されることがあります。 `PRIMARY KEY`は制約 (論理プロパティ) を指し、クラスター化インデックスはデータの格納方法の物理的な実装を表します。 ## ユーザーシナリオ {#user-scenarios} クラスター化インデックスを持たないテーブルと比較して、クラスター化インデックスを持つテーブルは、以下のシナリオにおいて、より優れたパフォーマンスとスループットのメリットを提供します。 -- データが挿入される際、クラスタ化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 -- 同等の条件を持つクエリが主キーのみに関係する場合、クラスタ化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 -- 範囲条件を含むクエリが主キーのみに関係する場合、クラスタ化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 -- 同等条件または範囲条件を含むクエリが主キーのプレフィックスのみに関係する場合、クラスタ化インデックスはネットワークからのインデックスデータの複数回の読み取りを削減します。 +- データが挿入される際、クラスター化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 +- 同等の条件を持つクエリが主キーのみに関係する場合、クラスター化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 +- 範囲条件を含むクエリが主キーのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 +- 同等条件または範囲条件を含むクエリが主キーのプレフィックスのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの複数回の読み取りを削減します。 -一方、クラスタ化インデックスを持つテーブルにはいくつかの欠点があります。以下をご覧ください。 +一方、クラスター化インデックスを持つテーブルにはいくつかの欠点があります。以下をご覧ください。 - 値が近い多数の主キーを挿入する場合、書き込みホットスポットの問題が発生する可能性があります。 -- 主キーのデータ型が64ビットより大きい場合、特にセカンダリインデックスが複数存在する場合は、テーブルデータがより多くのstorage容量を消費します。 +- 主キーのデータ型が64ビットより大きい場合、特にセカンダリインデックスが複数存在する場合は、テーブルデータがより多くのストレージ容量を消費します。 ## 使用例 {#usages} ### クラスター化インデックスを持つテーブルを作成する {#create-a-table-with-clustered-indexes} -TiDB v5.0以降では、 `CLUSTERED`の`NONCLUSTERED`の後に、予約語ではないキーワード`PRIMARY KEY`または`CREATE TABLE`を追加することで、テーブルの主キーがクラスタ化インデックスであるかどうかを指定できます。例： +TiDB v5.0以降では、 `CLUSTERED`の`NONCLUSTERED`の後に、予約語ではないキーワード`PRIMARY KEY`または`CREATE TABLE`を追加することで、テーブルの主キーがクラスター化インデックスであるかどうかを指定できます。例： ```sql CREATE TABLE t (a BIGINT PRIMARY KEY CLUSTERED, b VARCHAR(255)); @@ -64,14 +64,14 @@ CREATE TABLE t (a BIGINT, b VARCHAR(255), PRIMARY KEY(a, b) /*T![clustered_index キーワード`CLUSTERED` / `NONCLUSTERED`明示的に指定しないステートメントの場合、デフォルトの動作はシステム変数[`@@global.tidb_enable_clustered_index`](/system-variables.md#tidb_enable_clustered_index-new-in-v50)によって制御されます。この変数でサポートされている値は次のとおりです。 - `OFF`は、プライマリキーがデフォルトで非クラスター化インデックスとして作成されることを示します。 -- `ON`は、プライマリキーがデフォルトでクラスタ化インデックスとして作成されることを示します。 -- `INT_ONLY`は、動作が構成項目`alter-primary-key`によって制御されることを示します。 `alter-primary-key`が`true`に設定されている場合、プライマリ キーはデフォルトで非クラスタ化インデックスとして作成されます。 `false`に設定されている場合、整数列で構成されるプライマリ キーのみがクラスタ化インデックスとして作成されます。 +- `ON`は、プライマリキーがデフォルトでクラスター化インデックスとして作成されることを示します。 +- `INT_ONLY`は、動作が構成項目`alter-primary-key`によって制御されることを示します。 `alter-primary-key`が`true`に設定されている場合、プライマリ キーはデフォルトで非クラスター化インデックスとして作成されます。 `false`に設定されている場合、整数列で構成されるプライマリ キーのみがクラスター化インデックスとして作成されます。 `@@global.tidb_enable_clustered_index`のデフォルト値は`ON`です。 ### クラスター化インデックスの追加または削除 {#add-or-drop-clustered-indexes} -TiDB は、テーブル作成後にクラスタ化インデックスを追加または削除することをサポートしていません。また、クラスタ化インデックスと非クラスタ化インデックス間の相互変換もサポートしていません。例: +TiDB は、テーブル作成後にクラスター化インデックスを追加または削除することをサポートしていません。また、クラスター化インデックスと非クラスター化インデックス間の相互変換もサポートしていません。例: ```sql ALTER TABLE t ADD PRIMARY KEY(b, a) CLUSTERED; -- Currently not supported. @@ -90,9 +90,9 @@ ALTER TABLE t DROP PRIMARY KEY; ALTER TABLE t DROP INDEX `PRIMARY`; ``` -### 主キーがクラスタ化インデックスであるかどうかを確認してください。 {#check-whether-the-primary-key-is-a-clustered-index} +### 主キーがクラスター化インデックスであるかどうかを確認してください。 {#check-whether-the-primary-key-is-a-clustered-index} -テーブルの主キーがクラスタ化インデックスであるかどうかは、以下のいずれかの方法で確認できます。 +テーブルの主キーがクラスター化インデックスであるかどうかは、以下のいずれかの方法で確認できます。 - コマンド`SHOW CREATE TABLE`を実行します。 - コマンド`SHOW INDEX FROM`を実行します。 @@ -140,15 +140,15 @@ mysql> SELECT TIDB_PK_TYPE FROM information_schema.tables WHERE table_schema = ' ## 制限事項 {#limitations} -現在、クラスタ化インデックス機能にはいくつかの異なる制限があります。以下を参照してください。 +現在、クラスター化インデックス機能にはいくつかの異なる制限があります。以下を参照してください。 - サポート対象外であり、サポートプランにも含まれていない状況： - クラスター化インデックスと属性[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)を併用することはサポートされていません。また、属性[`PRE_SPLIT_REGIONS`](/sql-statements/sql-statement-split-region.md#pre_split_regions) [`AUTO_RANDOM`](/auto-random.md)ではないクラスター化インデックスを持つテーブルには適用されません。 - - クラスタ化インデックスを持つテーブルのダウングレードはサポートされていません。そのようなテーブルをダウングレードする必要がある場合は、代わりに論理バックアップツールを使用してデータを移行してください。 + - クラスター化インデックスを持つテーブルのダウングレードはサポートされていません。そのようなテーブルをダウングレードする必要がある場合は、代わりに論理バックアップツールを使用してデータを移行してください。 - まだサポートされていないが、サポート計画に含まれている状況： - - `ALTER TABLE`ステートメントを使用したクラスタ化インデックスの追加、削除、および変更はサポートされていません。 + - `ALTER TABLE`ステートメントを使用したクラスター化インデックスの追加、削除、および変更はサポートされていません。 -クラスタ化インデックスを属性`SHARD_ROW_ID_BITS`と一緒に使用すると、TiDB は次のエラーを報告します。 +クラスター化インデックスを属性`SHARD_ROW_ID_BITS`と一緒に使用すると、TiDB は次のエラーを報告します。 ```sql mysql> CREATE TABLE t (a VARCHAR(255) PRIMARY KEY CLUSTERED) SHARD_ROW_ID_BITS = 3; @@ -159,9 +159,9 @@ ERROR 8200 (HY000): Unsupported shard_row_id_bits for table with primary key as ### 以前のバージョンおよび後のバージョンのTiDBとの互換性 {#compatibility-with-earlier-and-later-tidb-versions} -TiDBは、クラスタ化インデックスを持つテーブルのアップグレードはサポートしていますが、ダウングレードはサポートしていません。つまり、新しいバージョンのTiDBにあるクラスタ化インデックスを持つテーブルのデータは、古いバージョンでは利用できません。 +TiDBは、クラスター化インデックスを持つテーブルのアップグレードはサポートしていますが、ダウングレードはサポートしていません。つまり、新しいバージョンのTiDBにあるクラスター化インデックスを持つテーブルのデータは、古いバージョンでは利用できません。 -クラスタ化インデックス機能は、TiDB v3.0およびv4.0で部分的にサポートされています。以下の要件がすべて満たされている場合、デフォルトで有効になります。 +クラスター化インデックス機能は、TiDB v3.0およびv4.0で部分的にサポートされています。以下の要件がすべて満たされている場合、デフォルトで有効になります。 - テーブルには`PRIMARY KEY`が含まれています。 - `PRIMARY KEY`は 1 つの列のみで構成されています。 @@ -175,7 +175,7 @@ TiDB固有のコメント構文では、キーワード`CLUSTERED`と`NONCLUSTER ### TiDB移行ツールとの互換性 {#compatibility-with-tidb-migration-tools} -クラスタ化インデックス機能は、v5.0以降のバージョンにおいて、以下の移行ツールとのみ互換性があります。 +クラスター化インデックス機能は、v5.0以降のバージョンにおいて、以下の移行ツールとのみ互換性があります。 - バックアップおよび復元ツール： BR、 Dumpling、 TiDB Lightning。 - データ移行およびレプリケーションツール：DMとTiCDC。 @@ -184,7 +184,7 @@ TiDB固有のコメント構文では、キーワード`CLUSTERED`と`NONCLUSTER ### 他のTiDB機能との互換性 {#compatibility-with-other-tidb-features} -結合主キーまたは単一の非整数主キーを持つテーブルの場合、主キーを非クラスタ化インデックスからクラスタ化インデックスに変更すると、行データのキーも変更されます。そのため、TiDB バージョン 5.0 より前のバージョンで実行可能だった`SPLIT TABLE BY/BETWEEN`ステートメントは、TiDB バージョン 5.0 以降では動作しなくなります。 `SPLIT TABLE BY/BETWEEN`を使用してクラスタ化インデックスを持つテーブルを分割する場合は、整数値を指定する代わりに、主キー列の値を指定する必要があります。次の例を参照してください。 +結合主キーまたは単一の非整数主キーを持つテーブルの場合、主キーを非クラスター化インデックスからクラスター化インデックスに変更すると、行データのキーも変更されます。そのため、TiDB バージョン 5.0 より前のバージョンで実行可能だった`SPLIT TABLE BY/BETWEEN`ステートメントは、TiDB バージョン 5.0 以降では動作しなくなります。 `SPLIT TABLE BY/BETWEEN`を使用してクラスター化インデックスを持つテーブルを分割する場合は、整数値を指定する代わりに、主キー列の値を指定する必要があります。次の例を参照してください。 ```sql mysql> create table t (a int, b varchar(255), primary key(a, b) clustered); @@ -209,7 +209,7 @@ mysql> split table t by (0, ''), (50000, ''), (100000, ''); 1 row in set (0.01 sec) ``` -[`AUTO_RANDOM`](/auto-random.md)属性は、クラスタ化インデックスでのみ使用できます。それ以外の場合、TiDBは次のエラーを返します。 +[`AUTO_RANDOM`](/auto-random.md)属性は、クラスター化インデックスでのみ使用できます。それ以外の場合、TiDBは次のエラーを返します。 ```sql mysql> create table t (a bigint primary key nonclustered auto_random); diff --git a/command-line-flags-for-pd-configuration.md b/command-line-flags-for-pd-configuration.md index 1c14e69836321..654eb87bb019d 100644 --- a/command-line-flags-for-pd-configuration.md +++ b/command-line-flags-for-pd-configuration.md @@ -3,7 +3,7 @@ title: PD Configuration Flags summary: PD のいくつかの構成フラグについて学習します。 --- -# PDコンフィグレーションフラグ {#pd-configuration-flags} +# PD設定フラグ {#pd-configuration-flags} PD は、コマンドラインフラグと環境変数を使用して構成できます。 @@ -46,7 +46,7 @@ PD は、コマンドラインフラグと環境変数を使用して構成で ## --initial-cluster {#code-initial-cluster-code} -- ブートストラップのための初期クラスタ構成 +- ブートストラップのための初期クラスター構成 - デフォルト: `"{name}=http://{advertise-peer-url}"` - たとえば、 `name`が「pd」、 `advertise-peer-urls`が`"http://192.168.100.113:2380"`の場合、 `initial-cluster`は`"pd=http://192.168.100.113:2380"`なります。 - 3 つの PD サーバーを起動する必要がある場合、 `initial-cluster`は次のようになります。 diff --git a/command-line-flags-for-scheduling-configuration.md b/command-line-flags-for-scheduling-configuration.md index 2f8f5c0f48ff9..68b7dd86b4d57 100644 --- a/command-line-flags-for-scheduling-configuration.md +++ b/command-line-flags-for-scheduling-configuration.md @@ -3,7 +3,7 @@ title: Scheduling Configuration Flags summary: スケジュール構成フラグは、コマンド ライン フラグまたは環境変数を介して構成できます。 --- -# スケジュールコンフィグレーションフラグ {#scheduling-configuration-flags} +# スケジュール設定フラグ {#scheduling-configuration-flags} スケジューリングノードは、PD用の`scheduling`マイクロサービスを提供するために使用されます。コマンドラインフラグまたは環境変数を使用して設定できます。 diff --git a/command-line-flags-for-tidb-configuration.md b/command-line-flags-for-tidb-configuration.md index 87eb0fd3f8945..d6a1a0a6e6eb7 100644 --- a/command-line-flags-for-tidb-configuration.md +++ b/command-line-flags-for-tidb-configuration.md @@ -3,9 +3,9 @@ title: Configuration Options summary: TiDB の構成オプションについて学習します。 --- -# コンフィグレーションオプション {#configuration-options} +# 設定オプション {#configuration-options} -TiDBクラスタを起動する際には、コマンドラインオプションまたは環境変数を使用して設定できます。このドキュメントでは、TiDBのコマンドオプションについて説明します。デフォルトのTiDBポートは、クライアントリクエスト用に`4000` 、ステータスレポート用に`10080`です。 +TiDBクラスターを起動する際には、コマンドラインオプションまたは環境変数を使用して設定できます。このドキュメントでは、TiDBのコマンドオプションについて説明します。デフォルトのTiDBポートは、クライアントリクエスト用に`4000` 、ステータスレポート用に`10080`です。 ## --advertise-address {#code-advertise-address-code} @@ -17,7 +17,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション - 設定ファイル - デフォルト: `""` -- 設定ファイルが指定されている場合、TiDB は設定ファイルを読み取ります。対応する設定がコマンドラインオプションにも存在する場合、TiDB はコマンドラインオプションの設定を使用して設定ファイルの設定を上書きします。詳細な設定情報については、 [TiDBコンフィグレーションファイルの説明](/tidb-configuration-file.md)参照してください。 +- 設定ファイルが指定されている場合、TiDB は設定ファイルを読み取ります。対応する設定がコマンドラインオプションにも存在する場合、TiDB はコマンドラインオプションの設定を使用して設定ファイルの設定を上書きします。詳細な設定情報については、 [TiDB設定ファイルの説明](/tidb-configuration-file.md)参照してください。 ## --config-check {#code-config-check-code} @@ -53,7 +53,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## --initialize-sql-file {#code-initialize-sql-file-code} -- TiDBクラスタの初回起動時に実行されるSQLスクリプト。詳細は[構成項目`initialize-sql-file`](/tidb-configuration-file.md#initialize-sql-file-new-in-v660)参照。 +- TiDBクラスターの初回起動時に実行されるSQLスクリプト。詳細は[構成項目`initialize-sql-file`](/tidb-configuration-file.md#initialize-sql-file-new-in-v660)参照。 - デフォルト: `""` ## -L {#code-l-code} @@ -106,9 +106,9 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## --path {#code-path-code} -- 「unistore」のようなローカルstorageエンジンのデータディレクトリへのパス +- 「unistore」のようなローカルストレージエンジンのデータディレクトリへのパス - `--store = tikv`場合、パスを指定する必要があります。 `--store = unistore`場合、パスを指定しないとデフォルト値が使用されます。 -- TiKVのような分散storageエンジンの場合、 `--path`実際のPDアドレスを指定します。PDサーバーを192.168.100.113:2379、192.168.100.114:2379、192.168.100.115:2379にデプロイすると仮定すると、 `--path`値は「192.168.100.113:2379、192.168.100.114:2379、192.168.100.115:2379」となります。 +- TiKVのような分散ストレージエンジンの場合、 `--path`実際のPDアドレスを指定します。PDサーバーを192.168.100.113:2379、192.168.100.114:2379、192.168.100.115:2379にデプロイすると仮定すると、 `--path`値は「192.168.100.113:2379、192.168.100.114:2379、192.168.100.115:2379」となります。 - デフォルト: `"/tmp/tidb"` - 純粋なインメモリ TiDB を有効にするには、 `tidb-server --store=unistore --path=""`使用します。 @@ -153,7 +153,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## --run-ddl {#code-run-ddl-code} -- `tidb-server` DDL文を実行するかどうかを確認し、クラスタ内の`tidb-server`の数が2を超える場合に設定する +- `tidb-server` DDL文を実行するかどうかを確認し、クラスター内の`tidb-server`の数が2を超える場合に設定する - デフォルト: `true` - 値は (true) または (false) になります。 (true) は、 `tidb-server` DDL 自体を実行することを示します。 (false) は、 `tidb-server` DDL 自体を実行しないことを示します。 @@ -178,9 +178,9 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## --store {#code-store-code} -- 最レイヤーで TiDB が使用するstorageエンジンを指定します +- 最レイヤーで TiDB が使用するストレージエンジンを指定します - デフォルト: `"unistore"` -- 「unistore」または「tikv」を選択できます。（「unistore」はローカルstorageエンジン、「tikv」は分散storageエンジンです） +- 「unistore」または「tikv」を選択できます。（「unistore」はローカルストレージエンジン、「tikv」は分散ストレージエンジンです） ## --temp-dir {#code-temp-dir-code} @@ -205,7 +205,7 @@ TiDBクラスタを起動する際には、コマンドラインオプション ## --plugin-dir {#code-plugin-dir-code} -- プラグインのstorageディレクトリ。 +- プラグインのストレージディレクトリ。 - デフォルト: `"/data/deploy/plugin"` ## --plugin-load {#code-plugin-load-code} diff --git a/command-line-flags-for-tikv-configuration.md b/command-line-flags-for-tikv-configuration.md index 8f4e812096a65..045a3a17b491e 100644 --- a/command-line-flags-for-tikv-configuration.md +++ b/command-line-flags-for-tikv-configuration.md @@ -3,7 +3,7 @@ title: TiKV Configuration Flags summary: TiKV のいくつかの構成フラグについて学習します。 --- -# TiKVコンフィグレーションフラグ {#tikv-configuration-flags} +# TiKV設定フラグ {#tikv-configuration-flags} TiKV は、コマンドラインパラメータに対していくつかの読み取り可能な単位変換をサポートしています。 diff --git a/command-line-flags-for-tso-configuration.md b/command-line-flags-for-tso-configuration.md index e213aebf49f9d..39e8c8ef6d4df 100644 --- a/command-line-flags-for-tso-configuration.md +++ b/command-line-flags-for-tso-configuration.md @@ -3,7 +3,7 @@ title: TSO Configuration Flags summary: TSO 構成フラグは、コマンド ライン フラグまたは環境変数を介して構成できます。 --- -# TSOコンフィグレーションフラグ {#tso-configuration-flags} +# TSO設定フラグ {#tso-configuration-flags} TSOノードは、PD用の`tso`マイクロサービスを提供するために使用されます。コマンドラインフラグまたは環境変数を使用して設定できます。 diff --git a/configure-memory-usage.md b/configure-memory-usage.md index 424f95392ad44..462642af68158 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -137,7 +137,7 @@ TiDBが使用するトランザクションモデルでは、トランザクシ TiDBは、実行演算子のディスクへの書き込みをサポートしています。SQL実行のメモリ使用量がメモリクォータを超えた場合、tidb-serverは実行演算子の中間データをディスクに書き出すことで、メモリ負荷を軽減します。ディスクへの書き込みをサポートする演算子には、Sort、MergeJoin、HashJoin、HashAggなどがあります。 -- ディスクスピル動作は、 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 、 [`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom) 、 [`tmp-storage-path`](/tidb-configuration-file.md#tmp-storage-path) 、および[`tmp-storage-quota`](/tidb-configuration-file.md#tmp-storage-quota)パラメータによって共同で制御されます。 +- ディスクスピル動作は、 [`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) 、 [`tidb_enable_tmp_ストレージ_on_oom`](/system-variables.md#tidb_enable_tmp_ストレージ_on_oom) 、 [`tmp-ストレージ-path`](/tidb-configuration-file.md#tmp-ストレージ-path) 、および[`tmp-ストレージ-quota`](/tidb-configuration-file.md#tmp-ストレージ-quota)パラメータによって共同で制御されます。 - ディスク スピルがトリガーされると、TiDB はキーワード`memory exceeds quota, spill to disk now`または`memory exceeds quota, set aggregate mode to spill-mode`含むログを出力します。 - Sort、MergeJoin、およびHashJoin演算子のディスクスピルはv4.0.0で導入されました。HashAgg演算子の非並列アルゴリズムのディスクスピルはv5.2.0で導入されました。HashAgg演算子の並列アルゴリズムのディスクスピルはv8.0.0で実験的機能として導入され、v8.2.0で一般提供（GA）されました。TopN演算子のディスクスピルはv8.3.0で導入されました。 - [`tidb_enable_parallel_hashagg_spill`](/system-variables.md#tidb_enable_parallel_hashagg_spill-new-in-v800)システム変数を使用して、ディスクスピルをサポートする並列HashAggアルゴリズムを有効にするかどうかを制御できます。この変数は将来のリリースで廃止される予定です。 diff --git a/configure-placement-rules.md b/configure-placement-rules.md index a5baa405f41ee..b9495c77787a9 100644 --- a/configure-placement-rules.md +++ b/configure-placement-rules.md @@ -9,7 +9,7 @@ summary: 配置ルールを構成する方法を学習します。 > > このドキュメントでは、Placement Driver (PD) で配置ルールを手動で指定する方法を紹介します。現在は[SQLの配置ルール](/placement-rules-in-sql.md)使用が推奨されています。これにより、テーブルとパーティションの配置をより簡単に設定できます。 -バージョン5.0で導入された配置ルールは、PDが様々なデータタイプに対応するスケジュールを生成するためのレプリカルールシステムです。様々なスケジューリングルールを組み合わせることで、レプリカ数、storage場所、ホストタイプ、 Raft選出への参加、 Raftリーダーとしての役割など、任意の連続データ範囲の属性を細かく制御できます。 +バージョン5.0で導入された配置ルールは、PDが様々なデータタイプに対応するスケジュールを生成するためのレプリカルールシステムです。様々なスケジューリングルールを組み合わせることで、レプリカ数、ストレージ場所、ホストタイプ、 Raft選出への参加、 Raftリーダーとしての役割など、任意の連続データ範囲の属性を細かく制御できます。 TiDBバージョン5.0以降では、配置ルール機能はデフォルトで有効になっています。無効にするには、 [配置ルールを無効にする](#disable-placement-rules)を参照してください。 @@ -35,7 +35,7 @@ TiDBバージョン5.0以降では、配置ルール機能はデフォルトで | `Override` | `true` / `false` | グループ内のより小さいインデックスを持つルールを上書きするかどうか。 | | `StartKey` | `string` （16進数形式） | 範囲の開始キーに適用されます。 | | `EndKey` | `string` （16進数形式） | 範囲の終了キーに適用されます。 | -| `Role` | `string` | 投票者/リーダー/フォロワー/学習者などのレプリカロール。 | +| `Role` | `string` | 投票者/リーダー/フォロワー/ラーナーなどのレプリカロール。 | | `Count` | `int` 、正の整数 | レプリカの数。 | | `LabelConstraint` | `[]Constraint` | ラベルに基づいてノードをフィルタリングします。 | | `LocationLabels` | `[]string` | 物理的な分離に使用されます。 | @@ -50,7 +50,7 @@ TiDBバージョン5.0以降では、配置ルール機能はデフォルトで `LocationLabels`の意味と機能は、v4.0 以前のバージョンと同じです。例えば、 `[zone,rack,host]`デプロイし、3 層トポロジを定義しているとします。クラスターには複数のゾーン（アベイラビリティゾーン）があり、各ゾーンには複数のラックがあり、各ラックには複数のホストがあります。スケジュールを実行する際、PD はまずリージョンのピアを異なるゾーンに配置しようとします。この試行が失敗した場合（レプリカは 3 つあるがゾーンは合計 2 つしかない場合など）、PD はこれらのレプリカを異なるラックに配置することを保証します。ラック数が分離を保証するのに十分でない場合、PD はホストレベルの分離を試みます。 -`IsolationLevel`の意味と機能については[クラスタトポロジ構成](/schedule-replicas-by-topology-labels.md)で詳しく説明します。例えば、 `LocationLabels`を含む3層トポロジを定義する`[zone,rack,host]`デプロイし、 `IsolationLevel`を`zone`に設定した場合、PDはスケジューリング中に各リージョンのすべてのピアが異なるゾーンに配置されるように保証します。 `IsolationLevel`の最小分離レベル制限を満たすことができない場合（例えば、レプリカが3つ設定されているが、データゾーンが合計で2つしかない場合）、PDはこの制限を満たすために調整を試みません。デフォルト値`IsolationLevel`は空の文字列であり、無効であることを意味します。 +`IsolationLevel`の意味と機能については[クラスタートポロジ構成](/schedule-replicas-by-topology-labels.md)で詳しく説明します。例えば、 `LocationLabels`を含む3層トポロジを定義する`[zone,rack,host]`デプロイし、 `IsolationLevel`を`zone`に設定した場合、PDはスケジューリング中に各リージョンのすべてのピアが異なるゾーンに配置されるように保証します。 `IsolationLevel`の最小分離レベル制限を満たすことができない場合（例えば、レプリカが3つ設定されているが、データゾーンが合計で2つしかない場合）、PDはこの制限を満たすために調整を試みません。デフォルト値`IsolationLevel`は空の文字列であり、無効であることを意味します。 ### ルールグループのフィールド {#fields-of-the-rule-group} @@ -306,7 +306,7 @@ table ttt ranges: (NOTE: key range might be changed after DDL) このセクションでは、配置ルールの一般的な使用シナリオを紹介します。 -### シナリオ 1: 通常のテーブルに 3 つのレプリカを使用し、メタデータに 5 つのレプリカを使用してクラスタの耐障害性を向上させる {#scenario-1-use-three-replicas-for-normal-tables-and-five-replicas-for-the-metadata-to-improve-cluster-disaster-tolerance} +### シナリオ 1: 通常のテーブルに 3 つのレプリカを使用し、メタデータに 5 つのレプリカを使用してクラスターの耐障害性を向上させる {#scenario-1-use-three-replicas-for-normal-tables-and-five-replicas-for-the-metadata-to-improve-cluster-disaster-tolerance} キーの範囲をメタデータの範囲に制限するルールを追加し、値を`count`から`5`に設定するだけです。このルールの例を以下に示します。 diff --git a/configure-store-limit.md b/configure-store-limit.md index 1608ad90030c7..d17f277b4799a 100644 --- a/configure-store-limit.md +++ b/configure-store-limit.md @@ -15,11 +15,11 @@ PDはオペレータ単位でスケジューリングを実行します。オペ 上記の例では、 `replace-down-replica`演算子には次の特定の演算が含まれています。 -1. ID `20` ～ `store 3`の学習者ピアを追加します。 -2. ID `20` on `store 3`の学習者ピアを投票者に昇格します。 +1. ID `20` ～ `store 3`のラーナーピアを追加します。 +2. ID `20` on `store 3`のラーナーピアを投票者に昇格します。 3. `store 2`のピアを削除します。 -ストア制限は、ストアIDとトークンバケットのマッピングをメモリ内に保持することで、ストアレベルの速度制限を実現します。ここでの異なる操作は、それぞれ異なるトークンバケットに対応しています。現在、ストア制限は、学習者/ピアの追加とピアの削除という2つの操作の速度制限のみをサポートしています。つまり、各ストアには2種類のトークンバケットがあります。 +ストア制限は、ストアIDとトークンバケットのマッピングをメモリ内に保持することで、ストアレベルの速度制限を実現します。ここでの異なる操作は、それぞれ異なるトークンバケットに対応しています。現在、ストア制限は、ラーナー/ピアの追加とピアの削除という2つの操作の速度制限のみをサポートしています。つまり、各ストアには2種類のトークンバケットがあります。 オペレータが生成されるたびに、そのオペレータはトークンバケットにその操作に必要なトークンが十分にあるかどうかを確認します。十分なトークンがある場合、オペレータはスケジューリングキューに追加され、対応するトークンがトークンバケットから取得されます。十分なトークンがない場合、オペレータは破棄されます。トークンバケットは一定の速度でトークンを補充するため、速度制限はこのように達成されます。 @@ -51,7 +51,7 @@ tiup ctl:v pd store limit all 5 add-peer // All stores tiup ctl:v pd store limit all 5 remove-peer // All stores can at most delete 5 peers per minute. ``` -v8.5.5 以降では、次の例に示すように、特定のstorageエンジン タイプのすべてのストアに対してピア削除操作の速度制限を設定できます。 +v8.5.5 以降では、次の例に示すように、特定のストレージエンジン タイプのすべてのストアに対してピア削除操作の速度制限を設定できます。 ```bash tiup ctl:v pd store limit all engine tikv 5 remove-peer // All TiKV stores can at most remove 5 peers per minute. diff --git a/configure-time-zone.md b/configure-time-zone.md index 27270d834c03a..c4bcf835e3ec1 100644 --- a/configure-time-zone.md +++ b/configure-time-zone.md @@ -5,7 +5,7 @@ summary: TiDBのタイムゾーン設定は、time_zone`システム変数によ # タイムゾーンのサポート {#time-zone-support} -TiDBのタイムゾーンは、システム変数[`time_zone`](/system-variables.md#time_zone)によって決定されます。セッションレベルまたはグローバルレベルで設定できます。デフォルト値は`time_zone`で、 `SYSTEM`です`SYSTEM`に対応する実際のタイムゾーンは、TiDBクラスタのブートストラップが初期化される際に設定されます。詳細なロジックは次のとおりです。 +TiDBのタイムゾーンは、システム変数[`time_zone`](/system-variables.md#time_zone)によって決定されます。セッションレベルまたはグローバルレベルで設定できます。デフォルト値は`time_zone`で、 `SYSTEM`です`SYSTEM`に対応する実際のタイムゾーンは、TiDBクラスターのブートストラップが初期化される際に設定されます。詳細なロジックは次のとおりです。 1. TiDB は`TZ`環境変数の使用を優先します。 2. `TZ`環境変数が失敗した場合、TiDB は`/etc/localtime`ソフト リンクからタイム ゾーンを読み取ります。 diff --git a/constraints.md b/constraints.md index 4f71a9eb39b35..c000ece6e6adf 100644 --- a/constraints.md +++ b/constraints.md @@ -135,7 +135,7 @@ ALTER TABLE t ALTER CONSTRAINT c1 NOT ENFORCED; 一意制約とは、一意のインデックスと主キー列内のすべての非 NULL 値が一意であることを意味します。 -### 楽観的な取引 {#optimistic-transactions} +### 楽観的なトランザクション {#optimistic-transactions} デフォルトでは、楽観的トランザクションの場合、TiDB は実行フェーズで一意制約[怠惰に](/transaction-overview.md#lazy-check-of-constraints)チェックし、コミット フェーズで厳密にチェックします。これにより、ネットワーク オーバーヘッドが削減され、パフォーマンスが向上します。 @@ -210,7 +210,7 @@ INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill'); 最初の`INSERT`ステートメントで重複キーエラーが発生しました。これによりネットワーク通信のオーバーヘッドが増加し、挿入操作のスループットが低下する可能性があります。 -### 悲観的な取引 {#pessimistic-transactions} +### 悲観的なトランザクション {#pessimistic-transactions} 悲観的トランザクションでは、一意のインデックスの挿入または更新を必要とする SQL ステートメントが実行されると、TiDB はデフォルトで`UNIQUE`制約をチェックします。 diff --git a/control-execution-plan.md b/control-execution-plan.md index e06b5be31f4ef..4bfddab5c893f 100644 --- a/control-execution-plan.md +++ b/control-execution-plan.md @@ -1,6 +1,6 @@ --- title: Control Execution Plan -summary: この章では、TiDB における実行プランの生成を制御する方法について説明します。これには、ヒントの使用、SQL プラン管理、および最適化ルールのブロックリストが含まれます。さらに、システム変数と tidb_opt_fix_control` 変数を変更することで、実行プランを制御できます。これらの方法は、クラスタのアップグレード後にオプティマイザの動作が変更されることによって発生するパフォーマンスの低下を防ぐのに役立ちます。 +summary: この章では、TiDB における実行プランの生成を制御する方法について説明します。これには、ヒントの使用、SQL プラン管理、および最適化ルールのブロックリストが含まれます。さらに、システム変数と tidb_opt_fix_control` 変数を変更することで、実行プランを制御できます。これらの方法は、クラスターのアップグレード後にオプティマイザの動作が変更されることによって発生するパフォーマンスの低下を防ぐのに役立ちます。 --- # コントロール実行計画 {#control-execution-plan} @@ -8,7 +8,7 @@ summary: この章では、TiDB における実行プランの生成を制御す SQLチューニングの最初の2章では、TiDBの実行プランの理解方法と、TiDBが実行プランを生成する方法について解説します。本章では、実行プランの問題点を特定した際に、実行プランの生成を制御するために使用できる方法について説明します。本章の主な内容は以下の3点です。 - [オプティマイザのヒント](/optimizer-hints.md)では、TiDB が実行計画を生成するようにヒントを使用する方法を学びます。 -- しかし、ヒントはSQL文を侵襲的に変更します。場合によっては、ヒントを単純に挿入することはできません。SQL [SQLプラン管理](/sql-plan-management.md)では、TiDBが別の構文を使用して実行プランの生成を非侵襲的に制御する方法と、バックグラウンドで実行プランを自動的に進化させる方法について説明しています。この方法は、バージョンアップグレードやクラスタのパフォーマンス低下によって引き起こされる実行プランの不安定性などの問題に対処するのに役立ちます。 +- しかし、ヒントはSQL文を侵襲的に変更します。場合によっては、ヒントを単純に挿入することはできません。SQL [SQLプラン管理](/sql-plan-management.md)では、TiDBが別の構文を使用して実行プランの生成を非侵襲的に制御する方法と、バックグラウンドで実行プランを自動的に進化させる方法について説明しています。この方法は、バージョンアップグレードやクラスターのパフォーマンス低下によって引き起こされる実行プランの不安定性などの問題に対処するのに役立ちます。 - 最後に、[最適化ルールと式のプッシュダウンのブロックリスト](/blocklist-control-plan.md)でブロックリストの使用方法を学びます。 -上記の方法に加えて、実行プランはいくつかのシステム変数にも影響されます。システムレベルまたはセッションレベルでこれらの変数を変更することで、実行プランの生成を制御できます。v6.5.3およびv7.1.0以降、TiDBは比較的特殊な変数[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)を導入しました。この変数は複数の制御項目を受け入れることができ、クラスタのアップグレード後にオプティマイザの動作変更によって発生するパフォーマンスの低下を防ぐために、オプティマイザの動作をよりきめ細かく制御できます。詳細については[オプティマイザー修正コントロール](/optimizer-fix-controls.md)を参照してください。 +上記の方法に加えて、実行プランはいくつかのシステム変数にも影響されます。システムレベルまたはセッションレベルでこれらの変数を変更することで、実行プランの生成を制御できます。v6.5.3およびv7.1.0以降、TiDBは比較的特殊な変数[`tidb_opt_fix_control`](/system-variables.md#tidb_opt_fix_control-new-in-v653-and-v710)を導入しました。この変数は複数の制御項目を受け入れることができ、クラスターのアップグレード後にオプティマイザの動作変更によって発生するパフォーマンスの低下を防ぐために、オプティマイザの動作をよりきめ細かく制御できます。詳細については[オプティマイザー修正コントロール](/optimizer-fix-controls.md)を参照してください。 diff --git a/coprocessor-cache.md b/coprocessor-cache.md index 2d975018555e4..ff1e630a8bc44 100644 --- a/coprocessor-cache.md +++ b/coprocessor-cache.md @@ -7,11 +7,11 @@ summary: コプロセッサーキャッシュの機能について学習しま v4.0 以降、TiDB インスタンスは TiKV (コプロセッサーキャッシュ機能) にプッシュダウンされる計算結果のキャッシュをサポートしており、これにより一部のシナリオで計算プロセスを高速化できます。 -## コンフィグレーション {#configuration} +## 設定 {#configuration} -コプロセッサーキャッシュは、TiDB設定ファイルの`tikv-client.copr-cache`設定項目で設定できます。コプロセッサーキャッシュの有効化と設定方法の詳細については、 [TiDBコンフィグレーションファイル](/tidb-configuration-file.md#tikv-clientcopr-cache-new-in-v400)参照してください。 +コプロセッサーキャッシュは、TiDB設定ファイルの`tikv-client.copr-cache`設定項目で設定できます。コプロセッサーキャッシュの有効化と設定方法の詳細については、 [TiDB設定ファイル](/tidb-configuration-file.md#tikv-clientcopr-cache-new-in-v400)参照してください。 diff --git a/daily-check.md b/daily-check.md index 60ff5b1c02180..7c938d091278f 100644 --- a/daily-check.md +++ b/daily-check.md @@ -1,6 +1,6 @@ --- title: Daily Check -summary: TiDBクラスタのパフォーマンス指標について学びましょう。 +summary: TiDBクラスターのパフォーマンス指標について学びましょう。 --- # 日々のチェック {#daily-check} @@ -11,7 +11,7 @@ summary: TiDBクラスタのパフォーマンス指標について学びまし バージョン4.0以降、TiDBは新しい運用保守管理ツール[TiDBダッシュボード](/dashboard/dashboard-intro.md)を提供します。このツールはPDコンポーネントに統合されています。TiDBダッシュボードにはデフォルトのアドレス`http://${pd-ip}:${pd_port}/dashboard`からアクセスできます。 -TiDBダッシュボードは、TiDBデータベースの運用と保守を簡素化します。単一のインターフェースから、TiDBクラスタ全体の稼働状況を確認できます。以下に、いくつかのパフォーマンス指標について説明します。 +TiDBダッシュボードは、TiDBデータベースの運用と保守を簡素化します。単一のインターフェースから、TiDBクラスター全体の稼働状況を確認できます。以下に、いくつかのパフォーマンス指標について説明します。 ### インスタンスパネル {#instance-panel} @@ -31,7 +31,7 @@ CPU、メモリ、ディスクの使用状況を確認できます。いずれ ![SQL analysis panel](/media/sql-analysis-panel.png) -クラスタ内で実行されている処理の遅いSQL文を特定できます。その後、その特定のSQL文を最適化できます。 +クラスター内で実行されている処理の遅いSQL文を特定できます。その後、その特定のSQL文を最適化できます。 ### リージョンパネル {#region-panel} @@ -40,7 +40,7 @@ CPU、メモリ、ディスクの使用状況を確認できます。いずれ - `down-peer-region-count` ： Raftリーダーによって報告された、応答しないピアを持つリージョンの数。 - `empty-region-count` ：サイズが1MiB未満の空のリージョンの数。これらのリージョンは、 `TRUNCATE TABLE` / `DROP TABLE`ステートメントを実行することによって生成されます。この数が多い場合は、 `Region Merge`有効にして複数のテーブル間でリージョンをマージすることを検討してください。 - `extra-peer-region-count` ：追加のレプリカを持つリージョンの数。これらのリージョンはスケジューリング処理中に生成されます。 -- `learner-peer-region-count` ：学習者ピアが存在するリージョンの数。学習者ピアのソースは様々で、例えば、 TiFlashの学習者ピアや、設定済みの配置ルールに含まれる学習者ピアなどがあります。 +- `learner-peer-region-count` ：ラーナーピアが存在するリージョンの数。ラーナーピアのソースは様々で、例えば、 TiFlashのラーナーピアや、設定済みの配置ルールに含まれるラーナーピアなどがあります。 - `miss-peer-region-count` ：レプリカが不足しているリージョンの数。この値は必ずしも`0`より大きいとは限りません。 - `offline-peer-region-count` ：ピアオフライン処理中のリージョン数。 - `oversized-region-count` : サイズが`region-max-size`または`region-max-keys`より大きい領域の数。 @@ -69,7 +69,7 @@ TiDBがPDからTSOを取得するのにかかる時間。待ち時間が長く ![Overview panel](/media/overview-panel.png) -負荷、利用可能なメモリ、ネットワークトラフィック、およびI/Oユーティリティを確認できます。ボトルネックが見つかった場合は、容量を拡張するか、クラスタトポロジ、SQL、およびクラスタパラメータを最適化することをお勧めします。 +負荷、利用可能なメモリ、ネットワークトラフィック、およびI/Oユーティリティを確認できます。ボトルネックが見つかった場合は、容量を拡張するか、クラスタートポロジ、SQL、およびクラスターパラメータを最適化することをお勧めします。 ### 例外 {#exceptions} diff --git a/dashboard/dashboard-cluster-info.md b/dashboard/dashboard-cluster-info.md index 54c3b6298e35a..d2e77387d979c 100644 --- a/dashboard/dashboard-cluster-info.md +++ b/dashboard/dashboard-cluster-info.md @@ -1,9 +1,9 @@ --- title: TiDB Dashboard Cluster Information Page -summary: TiDBダッシュボードのクラスタ情報ページでは、クラスタ全体のTiDB、TiKV、PD、 TiFlashコンポーネントの稼働状況、およびこれらのコンポーネントが配置されているホストの稼働状況を確認できます。このページにアクセスするには、TiDBダッシュボードにログインし、左側のナビゲーションメニューで「クラスタ情報」をクリックするか、ブラウザで特定のURLにアクセスしてください。このページには、インスタンス、ホスト、ディスクのリストが表示され、各コンポーネントの詳細情報と稼働状況が表示されます。 +summary: TiDBダッシュボードのクラスター情報ページでは、クラスター全体のTiDB、TiKV、PD、 TiFlashコンポーネントの稼働状況、およびこれらのコンポーネントが配置されているホストの稼働状況を確認できます。このページにアクセスするには、TiDBダッシュボードにログインし、左側のナビゲーションメニューで「クラスター情報」をクリックするか、ブラウザで特定のURLにアクセスしてください。このページには、インスタンス、ホスト、ディスクのリストが表示され、各コンポーネントの詳細情報と稼働状況が表示されます。 --- -# TiDBダッシュボードのクラスタ情報ページ {#tidb-dashboard-cluster-information-page} +# TiDBダッシュボードのクラスター情報ページ {#tidb-dashboard-cluster-information-page} クラスター情報ページでは、クラスター全体の TiDB、TiKV、PD、 TiFlashコンポーネントの実行状態と、これらのコンポーネントが配置されているホストの実行状態を表示できます。 @@ -11,7 +11,7 @@ summary: TiDBダッシュボードのクラスタ情報ページでは、クラ クラスター情報ページにアクセスするには、次の 2 つの方法のいずれかを使用できます。 -- TiDB ダッシュボードにログインしたら、左側のナビゲーション メニューで**[クラスタ情報]**をクリックします。 +- TiDB ダッシュボードにログインしたら、左側のナビゲーション メニューで**[クラスター情報]**をクリックします。 - ブラウザで[http://127.0.0.1:2379/ダッシュボード/#/cluster_info/インスタンス](http://127.0.0.1:2379/dashboard/#/cluster_info/instance)アクセスしてください。3 `127.0.0.1:2379`実際のPDインスタンスのアドレスとポートに置き換えてください。 diff --git a/dashboard/dashboard-diagnostics-access.md b/dashboard/dashboard-diagnostics-access.md index e05ebd9dcb203..0106c18ba51e0 100644 --- a/dashboard/dashboard-diagnostics-access.md +++ b/dashboard/dashboard-diagnostics-access.md @@ -1,11 +1,11 @@ --- title: TiDB Dashboard Cluster Diagnostic Page -summary: TiDBダッシュボードのクラスタ診断機能は、クラスタの問題を診断し、結果をWebページにまとめます。ダッシュボードまたはブラウザからこのページにアクセスできます。指定した期間の診断レポートと比較レポートを生成します。履歴レポートも利用可能です。 +summary: TiDBダッシュボードのクラスター診断機能は、クラスターの問題を診断し、結果をWebページにまとめます。ダッシュボードまたはブラウザからこのページにアクセスできます。指定した期間の診断レポートと比較レポートを生成します。履歴レポートも利用可能です。 --- -# TiDBダッシュボードのクラスタ診断ページ {#tidb-dashboard-cluster-diagnostics-page} +# TiDBダッシュボードのクラスター診断ページ {#tidb-dashboard-cluster-diagnostics-page} -TiDBダッシュボードのクラスタ診断機能は、指定された時間範囲内でクラスタに存在する可能性のある問題を診断し、診断結果とクラスタ関連の負荷監視情報を診断レポートにまとめます。この診断レポートはウェブページ形式で提供されます。ブラウザからページを保存した後、オフラインでページを閲覧したり、このページのリンクを配布したりできます。 +TiDBダッシュボードのクラスター診断機能は、指定された時間範囲内でクラスターに存在する可能性のある問題を診断し、診断結果とクラスター関連の負荷監視情報を診断レポートにまとめます。この診断レポートはウェブページ形式で提供されます。ブラウザからページを保存した後、オフラインでページを閲覧したり、このページのリンクを配布したりできます。 > **注記：** > @@ -15,7 +15,7 @@ TiDBダッシュボードのクラスタ診断機能は、指定された時間 クラスター診断ページにアクセスするには、次のいずれかの方法を使用できます。 -- TiDB ダッシュボードにログインしたら、左側のナビゲーション メニューで**[クラスタ診断]**をクリックします。 +- TiDB ダッシュボードにログインしたら、左側のナビゲーション メニューで**[クラスター診断]**をクリックします。 ![Access Cluster Diagnostics page](/media/dashboard/dashboard-diagnostics-access-v650.png) diff --git a/dashboard/dashboard-diagnostics-report.md b/dashboard/dashboard-diagnostics-report.md index a3ea23fa3cb01..aacd9cc4f3077 100644 --- a/dashboard/dashboard-diagnostics-report.md +++ b/dashboard/dashboard-diagnostics-report.md @@ -5,7 +5,7 @@ summary: TiDBダッシュボード診断レポートでは、基本情報、診 # TiDBダッシュボード診断レポート {#tidb-dashboard-diagnostic-report} -このドキュメントでは、診断レポートの内容と表示に関するヒントを紹介します。クラスター診断ページにアクセスしてレポートを生成するには、 [TiDBダッシュボードのクラスタ診断ページ](/dashboard/dashboard-diagnostics-access.md)参照してください。 +このドキュメントでは、診断レポートの内容と表示に関するヒントを紹介します。クラスター診断ページにアクセスしてレポートを生成するには、 [TiDBダッシュボードのクラスター診断ページ](/dashboard/dashboard-diagnostics-access.md)参照してください。 ## レポートをビュー {#view-report} @@ -16,7 +16,7 @@ summary: TiDBダッシュボード診断レポートでは、基本情報、診 - 負荷情報:サーバー、TiDB、PD、または TiKV の CPU、メモリ、その他の負荷情報が含まれます。 - 概要情報: 各 TiDB、PD、または TiKV モジュールの消費時間とエラー情報が含まれます。 - TiDB/PD/TiKV 監視情報:各コンポーネントの監視情報が含まれます。 -- コンフィグレーション情報: 各コンポーネントの構成情報が含まれます。 +- 設定情報: 各コンポーネントの構成情報が含まれます。 診断レポートの例は次のとおりです。 @@ -44,9 +44,9 @@ summary: TiDBダッシュボード診断レポートでは、基本情報、診 ![Report time range](/media/dashboard/dashboard-diagnostics-report-time-range.png) -#### クラスタハードウェア情報 {#cluster-hardware-info} +#### クラスターハードウェア情報 {#cluster-hardware-info} -クラスタハードウェア情報には、クラスター内の各サーバーの CPU、メモリ、ディスクなどの情報が含まれます。 +クラスターハードウェア情報には、クラスター内の各サーバーの CPU、メモリ、ディスクなどの情報が含まれます。 ![Cluster hardware report](/media/dashboard/dashboard-diagnostics-cluster-hardware.png) @@ -59,9 +59,9 @@ summary: TiDBダッシュボード診断レポートでは、基本情報、診 - `DISK` :サーバーのディスクサイズを示します。単位はGBです。 - `UPTIME` :サーバーの稼働時間。単位は日です。 -#### クラスタトポロジ情報 {#cluster-topology-info} +#### クラスタートポロジ情報 {#cluster-topology-info} -表`Cluster Info`はクラスタトポロジ情報を示しています。この表の情報はTiDB [情報スキーマ.クラスタ情報](/information-schema/information-schema-cluster-info.md)システムテーブルから取得されています。 +表`Cluster Info`はクラスタートポロジ情報を示しています。この表の情報はTiDB [情報スキーマ.クラスター情報](/information-schema/information-schema-cluster-info.md)システムテーブルから取得されています。 ![Cluster info](/media/dashboard/dashboard-diagnostics-cluster-info.png) @@ -185,12 +185,12 @@ TiDBには自動診断結果が組み込まれています。各フィールド - `tikv_scheduler_command`時間の消費で、次の部分が含まれます。 - `tikv_scheduler_processing_read` : 読み取り要求の処理に費やされた時間。 - - スナップショットを`tikv_storage_async_request`で取得するのにかかった時間 (スナップショットはこの監視メトリックのラベルです)。 + - スナップショットを`tikv_ストレージ_async_request`で取得するのにかかった時間 (スナップショットはこの監視メトリックのラベルです)。 - 書き込みリクエストの処理にかかる時間。この時間消費には以下の部分が含まれます。 - `tikv_scheduler_latch_wait` : ラッチを待機するのにかかる時間。 - - `tikv_storage_async_request`の書き込みの消費時間 (書き込みはこの監視メトリックのラベルです)。 + - `tikv_ストレージ_async_request`の書き込みの消費時間 (書き込みはこの監視メトリックのラベルです)。 -上記のメトリックのうち、 `tikv_storage_async_request`の書き込み時間の消費は、次の部分を含むRaft KV の書き込み時間の消費を指します。 +上記のメトリックのうち、 `tikv_ストレージ_async_request`の書き込み時間の消費は、次の部分を含むRaft KV の書き込み時間の消費を指します。 - `tikv_raft_propose_wait` - `tikv_raft_process` 、主に`tikv_raft_append_log`含む @@ -247,7 +247,7 @@ TiDBには自動診断結果が組み込まれています。各フィールド ![TiDB DDL Owner Report](/media/dashboard/dashboard-diagnostics-tidb-ddl.png) -上記の表は、 `2020-05-21 14:40:00`から5ノード目にあるクラスタの`DDL OWNER`ノード`10.0.1.13:10080`であることを示しています。所有者が変更された場合、上記の表には複数のデータ行が存在し、 `Min_Time`列目は対応する既知の所有者の最小時間を示します。 +上記の表は、 `2020-05-21 14:40:00`から5ノード目にあるクラスターの`DDL OWNER`ノード`10.0.1.13:10080`であることを示しています。所有者が変更された場合、上記の表には複数のデータ行が存在し、 `Min_Time`列目は対応する既知の所有者の最小時間を示します。 > **注記：** > @@ -266,7 +266,7 @@ PD モジュールの監視情報に関連するテーブルは次のとおり - `Time Consumed by PD Component` : PD 内の関連モジュールの監視メトリックによって消費された時間。 - `Blance Leader/Region` : `tikv_note_1`からスケジュールアウトされたリーダーの数や、スケジュールインされたリーダーの数など、レポート時間範囲内でクラスター内で`balance-region`と`balance leader`の監視情報が発生しました。 -- `Cluster Status` : TiKV ノードの合計数、クラスターの合計storage容量、リージョンの数、オフラインの TiKV ノードの数などのクラスターのステータス情報。 +- `Cluster Status` : TiKV ノードの合計数、クラスターの合計ストレージ容量、リージョンの数、オフラインの TiKV ノードの数などのクラスターのステータス情報。 - `Store Status` :リージョンスコア、リーダー スコア、リージョン/リーダーの数など、各 TiKV ノードのステータス情報を記録します。 - `Etcd Status` : PD 内の etcd 関連情報。 @@ -284,7 +284,7 @@ TiKV モジュールの監視情報に関連するテーブルは次のとおり - `GC Info` : TiKV 内のガベージ コレクション (GC) 関連の監視情報。 - `Cache Hit` : TiKV 内の RocksDB の各キャッシュのヒット率情報。 -### コンフィグレーション情報 {#configuration-information} +### 設定情報 {#configuration-information} 設定情報では、一部のモジュールの設定値はレポート期間内に表示されます。ただし、これらのモジュールの他の設定値については履歴値を取得できないため、表示される値はレポート生成時点の現在の値となります。 diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index 5e0d9780ed68a..875c11eaaae94 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -33,7 +33,7 @@ Prometheusインスタンスをデプロイしてもこの問題が引き続き デプロイメントツールがTiUPの場合は、以下の手順に従って問題を解決してください。その他のデプロイメントツールについては、それぞれのツールのドキュメントを参照してください。 -1. TiUPおよびTiUPクラスタのアップグレード: +1. TiUPおよびTiUPクラスターのアップグレード: ```bash tiup update --self @@ -48,7 +48,7 @@ Prometheusインスタンスをデプロイしてもこの問題が引き続き tiup cluster start CLUSTER_NAME ``` - クラスタが起動している場合でも、このコマンドを実行してください。このコマンドはクラスタ内の通常のアプリケーションには影響を与えませんが、メトリクスアドレスを更新してレポートするため、TiDBダッシュボードに監視メトリクスが正常に表示されるようになります。 + クラスターが起動している場合でも、このコマンドを実行してください。このコマンドはクラスター内の通常のアプリケーションには影響を与えませんが、メトリクスアドレスを更新してレポートするため、TiDBダッシュボードに監視メトリクスが正常に表示されるようになります。 ### スロークエリページにinvalid connectionエラーが表示されます {#an-code-invalid-connection-code-error-is-shown-on-the-strong-slow-queries-strong-page} @@ -114,7 +114,7 @@ TiDB Operatorのドキュメントのセクション[継続的なプロファイ
TiUP Playgroundを使用したクラスターの開始 -クラスタを起動すると、 TiUP Playground (>= v1.8.0) は NgMonitoringコンポーネントを自動的に起動します。TiUP Playgroundを最新バージョンに更新するには、次のコマンドを実行します。 +クラスターを起動すると、 TiUP Playground (>= v1.8.0) は NgMonitoringコンポーネントを自動的に起動します。TiUP Playgroundを最新バージョンに更新するには、次のコマンドを実行します。 ```shell tiup update --self diff --git a/dashboard/dashboard-intro.md b/dashboard/dashboard-intro.md index 80cafdc3a01cd..b35aa64b9b76f 100644 --- a/dashboard/dashboard-intro.md +++ b/dashboard/dashboard-intro.md @@ -1,6 +1,6 @@ --- title: TiDB Dashboard Introduction -summary: TiDBダッシュボードは、TiDBクラスタの監視、診断、管理のためのWeb UIです。クラスタ全体の稼働状況、コンポーネントとホストのステータス、トラフィック分布、SQL文の実行情報、スロークエリ、クラスタ診​​断、ログ検索、リソース制御、プロファイリングデータ収集などを表示します。 +summary: TiDBダッシュボードは、TiDBクラスターの監視、診断、管理のためのWeb UIです。クラスター全体の稼働状況、コンポーネントとホストのステータス、トラフィック分布、SQL文の実行情報、スロークエリ、クラスター診​​断、ログ検索、リソース制御、プロファイリングデータ収集などを表示します。 --- # TiDBダッシュボードの紹介 {#tidb-dashboard-introduction} @@ -17,7 +17,7 @@ TiDB ダッシュボードは[GitHub](https://github.com/pingcap-incubator/tidb- このドキュメントでは、TiDBダッシュボードの主な機能を紹介します。詳細については、以下のセクションのリンクをクリックしてください。 -## TiDBクラスタの全体的な実行ステータスを表示します {#show-the-overall-running-status-of-the-tidb-cluster} +## TiDBクラスターの全体的な実行ステータスを表示します {#show-the-overall-running-status-of-the-tidb-cluster} TiDB ダッシュボードを使用すると、TiDB クラスターの 1 秒あたりのクエリ数 (QPS)、実行時間、最も多くのリソースを消費する SQL ステートメントの種類などの概要情報を確認できます。 @@ -27,7 +27,7 @@ TiDB ダッシュボードを使用すると、TiDB クラスターの 1 秒あ TiDB ダッシュボードを使用すると、クラスター全体の TiDB、TiKV、PD、 TiFlashコンポーネントの実行状態と、これらのコンポーネントが配置されているホストの実行状態を表示できます。 -詳細は[TiDBダッシュボードのクラスタ情報ページ](/dashboard/dashboard-cluster-info.md)参照。 +詳細は[TiDBダッシュボードのクラスター情報ページ](/dashboard/dashboard-cluster-info.md)参照。 ## 読み取りおよび書き込みトラフィックの分布と傾向を表示します {#show-distribution-and-trends-of-read-and-write-traffic} @@ -51,7 +51,7 @@ TiDBダッシュボードの「スロークエリ」ページには、実行に TiDB ダッシュボードの診断機能は、クラスター内に一般的なリスク (不一致な構成など) や問題が存在するかどうかを自動的に判断し、レポートを生成して操作の提案を行ったり、異なる時間範囲で各クラスター メトリックの状態を比較して、起こりうる問題を分析したりします。 -詳細は[TiDBダッシュボードのクラスタ診​​断ページ](/dashboard/dashboard-diagnostics-access.md)参照。 +詳細は[TiDBダッシュボードのクラスター診​​断ページ](/dashboard/dashboard-diagnostics-access.md)参照。 ## すべてのコンポーネントのクエリログ {#query-logs-of-all-components} diff --git a/dashboard/dashboard-key-visualizer.md b/dashboard/dashboard-key-visualizer.md index ddcaaa0530799..9a57480948d9c 100644 --- a/dashboard/dashboard-key-visualizer.md +++ b/dashboard/dashboard-key-visualizer.md @@ -1,11 +1,11 @@ --- title: Key Visualizer Page -summary: TiDBダッシュボードのKey Visualizerページでは、TiDBクラスタ内のトラフィックのホットスポットを分析およびトラブルシューティングできます。トラフィックの変化を時間経過とともに視覚的に表示し、特定の期間または地域範囲を拡大表示できます。また、明るさの調整、指標の選択、ヒートマップの更新などの設定も行えます。一般的なヒートマップの種類を特定し、ホットスポットの問題に対処するためのソリューションを提供します。 +summary: TiDBダッシュボードのKey Visualizerページでは、TiDBクラスター内のトラフィックのホットスポットを分析およびトラブルシューティングできます。トラフィックの変化を時間経過とともに視覚的に表示し、特定の期間または地域範囲を拡大表示できます。また、明るさの調整、指標の選択、ヒートマップの更新などの設定も行えます。一般的なヒートマップの種類を特定し、ホットスポットの問題に対処するためのソリューションを提供します。 --- # キービジュアライザーページ {#key-visualizer-page} -TiDBダッシュボードのKey Visualizerページは、TiDBの使用状況を分析し、トラフィックのホットスポットをトラブルシューティングするために使用します。このページでは、一定期間にわたるTiDBクラスタのトラフィックを視覚的に表示します。 +TiDBダッシュボードのKey Visualizerページは、TiDBの使用状況を分析し、トラフィックのホットスポットをトラブルシューティングするために使用します。このページでは、一定期間にわたるTiDBクラスターのトラフィックを視覚的に表示します。 ## アクセスキービジュアライザーページ {#access-key-visualizer-page} @@ -35,9 +35,9 @@ Key Visualizer ページにアクセスするには、次の 2 つの方法の ### リージョン {#region} -TiDBクラスタでは、保存されたデータはTiKVインスタンス間に分散されます。論理的には、TiKVは巨大で整然としたキーバリューマップです。キーバリュー空間全体は多数のセグメントに分割され、各セグメントは隣接するキーの列で構成されます。このようなセグメントは`Region`と呼ばれます。 +TiDBクラスターでは、保存されたデータはTiKVインスタンス間に分散されます。論理的には、TiKVは巨大で整然としたキーバリューマップです。キーバリュー空間全体は多数のセグメントに分割され、各セグメントは隣接するキーの列で構成されます。このようなセグメントは`Region`と呼ばれます。 -リージョンの詳しい紹介については[TiDB 内部 (I) - データストレージ](https://www.pingcap.com/blog/tidb-internal-data-storage/)を参照してください。 +リージョンの詳しい紹介については[TiDB 内部 (I) - データストレージ](https://www.pingcap.com/blog/tidb-internal-data-ストレージ/)を参照してください。 ### ホットスポット {#hotspot} diff --git a/dashboard/dashboard-metrics-relation.md b/dashboard/dashboard-metrics-relation.md index 4640b7ab4d1eb..61ade6a166562 100644 --- a/dashboard/dashboard-metrics-relation.md +++ b/dashboard/dashboard-metrics-relation.md @@ -1,15 +1,15 @@ --- title: TiDB Dashboard Metrics Relation Graph -summary: TiDBダッシュボードに、TiDBクラスタ内の各内部プロセスの所要時間を把握するのに役立つメトリクス関係グラフという機能が導入されました。ログイン後、ユーザーはグラフにアクセスし、各監視メトリクスの所要時間がクエリ総所要時間に対する割合を確認できます。各ボックス領域は監視メトリクスを表し、総所要時間やクエリ総所要時間に対する割合などの情報を提供します。グラフにはノード間の親子関係も表示されるため、各監視メトリクスの関係を理解するのに役立ちます。 +summary: TiDBダッシュボードに、TiDBクラスター内の各内部プロセスの所要時間を把握するのに役立つメトリクス関係グラフという機能が導入されました。ログイン後、ユーザーはグラフにアクセスし、各監視メトリクスの所要時間がクエリ総所要時間に対する割合を確認できます。各ボックス領域は監視メトリクスを表し、総所要時間やクエリ総所要時間に対する割合などの情報を提供します。グラフにはノード間の親子関係も表示されるため、各監視メトリクスの関係を理解するのに役立ちます。 --- # TiDBダッシュボードメトリクス関係グラフ {#tidb-dashboard-metrics-relation-graph} -TiDBダッシュボードのメトリクス関係グラフは、v4.0.7で導入された機能です。この機能は、TiDBクラスタ内の各内部プロセスの実行時間に関する監視データの関係グラフを表示します。これにより、各プロセスの実行時間とそれらの関係を迅速に把握できるようになります。 +TiDBダッシュボードのメトリクス関係グラフは、v4.0.7で導入された機能です。この機能は、TiDBクラスター内の各内部プロセスの実行時間に関する監視データの関係グラフを表示します。これにより、各プロセスの実行時間とそれらの関係を迅速に把握できるようになります。 ## アクセスグラフ {#access-graph} -TiDB ダッシュボードにログイン後、左側のナビゲーション メニューで**[クラスタ診断]**をクリックすると、メトリック関係グラフを生成するページが表示されます。 +TiDB ダッシュボードにログイン後、左側のナビゲーション メニューで**[クラスター診断]**をクリックすると、メトリック関係グラフを生成するページが表示されます。 ![Metrics relation graph homepage](/media/dashboard/dashboard-metrics-relation-home-v650.png) diff --git a/dashboard/dashboard-monitoring.md b/dashboard/dashboard-monitoring.md index d04166bb907bd..e4f9886231a09 100644 --- a/dashboard/dashboard-monitoring.md +++ b/dashboard/dashboard-monitoring.md @@ -1,6 +1,6 @@ --- title: TiDB Dashboard Monitoring Page -summary: TiDBダッシュボードのモニタリングページでは、パフォーマンスを効率的に分析し、データベースのボトルネックを特定できます。主要なメトリクスには、データベース時間、SQL実行時間、QPS、接続数、TiDBおよびTiKVのCPU使用率、接続アイドル時間、解析・コンパイル・実行時間、TiDB KVリクエスト時間、TiKV gRPC時間、PD TSO待機/RPC時間、storage非同期書き込み時間、保存時間、適用時間、ログ追加時間、ログコミット時間、ログ適用時間などがあります。 +summary: TiDBダッシュボードのモニタリングページでは、パフォーマンスを効率的に分析し、データベースのボトルネックを特定できます。主要なメトリクスには、データベース時間、SQL実行時間、QPS、接続数、TiDBおよびTiKVのCPU使用率、接続アイドル時間、解析・コンパイル・実行時間、TiDB KVリクエスト時間、TiKV gRPC時間、PD TSO待機/RPC時間、ストレージ非同期書き込み時間、保存時間、適用時間、ログ追加時間、ログコミット時間、ログ適用時間などがあります。 --- # TiDBダッシュボード監視ページ {#tidb-dashboard-monitoring-page} @@ -106,7 +106,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 ### トラフィックを読む {#read-traffic} - `TiDB -> Client` : TiDBからクライアントへの送信トラフィック統計 -- `Rocksdb -> TiKV` :storageレイヤー内での読み取り操作中に TiKV が RocksDB から取得するデータフロー +- `Rocksdb -> TiKV` :ストレージレイヤー内での読み取り操作中に TiKV が RocksDB から取得するデータフロー ### 書き込みトラフィック {#write-traffic} @@ -161,7 +161,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 - `wait - 99` : すべての TiDB インスタンスで PD が TSO を返すのを待つ P99 時間 - `rpc - 99` : PDにTSOリクエストを送信してからすべてのTiDBインスタンスでTSOを受信するまでのP99時間 -### ストレージ非同期書き込み期間、保存期間、適用期間 {#storage-async-write-duration-store-duration-and-apply-duration} +### ストレージ非同期書き込み期間、保存期間、適用期間 {#ストレージ-async-write-duration-store-duration-and-apply-duration} - `Storage Async Write Duration` : 非同期書き込みにかかった時間 - `Store Duration` : 非同期書き込み中のストアループで消費された時間 @@ -169,7 +169,7 @@ SQL実行フェーズは緑色で、その他のフェーズは全体的に赤 これら 3 つのメトリックにはすべて、すべての TiKV インスタンスの平均期間と P99 期間が含まれます。 -平均storage非同期書き込み時間 = 平均保存時間 + 平均適用時間 +平均ストレージ非同期書き込み時間 = 平均保存時間 + 平均適用時間 ### 追加ログ期間、コミットログ期間、適用ログ期間 {#append-log-duration-commit-log-duration-and-apply-log-duration} diff --git a/dashboard/dashboard-ops-deploy.md b/dashboard/dashboard-ops-deploy.md index 47ad387d3e886..7167731d3f1c5 100644 --- a/dashboard/dashboard-ops-deploy.md +++ b/dashboard/dashboard-ops-deploy.md @@ -13,7 +13,7 @@ TiDBダッシュボードUIは、v4.0以降のバージョンのPDコンポー 標準の TiDB クラスターをデプロイする方法については、次のドキュメントを参照してください。 -- [TiDBセルフマネージドのクイックスタート](/quick-start-with-tidb.md) +- [TiDB Self-Managedのクイックスタート](/quick-start-with-tidb.md) - [本番環境にTiDBをデプロイ](/production-deployment-using-tiup.md) - [Kubernetes環境のデプロイメント](https://docs.pingcap.com/tidb-in-kubernetes/stable/access-dashboard) @@ -53,7 +53,7 @@ http://192.168.0.123:2379/dashboard/ > > この機能は、 `tiup cluster`デプロイメント ツールの新しいバージョン (v1.0.3 以降) でのみ使用できます。 > ->
TiUPクラスタのアップグレード +>
TiUPクラスターのアップグレード > > ```bash > tiup update --self diff --git a/dashboard/dashboard-ops-reverse-proxy.md b/dashboard/dashboard-ops-reverse-proxy.md index 4d2859faa5f99..f2eb8e46e9c11 100644 --- a/dashboard/dashboard-ops-reverse-proxy.md +++ b/dashboard/dashboard-ops-reverse-proxy.md @@ -29,7 +29,7 @@ http://192.168.0.123:2379/dashboard/ > > この機能は、 `tiup cluster`デプロイメント ツールの新しいバージョン (v1.0.3 以降) でのみ使用できます。 > ->
TiUPクラスタのアップグレード +>
TiUPクラスターのアップグレード > > ```bash > tiup update --self @@ -117,7 +117,7 @@ server_configs:
TiUPを使用して新しいクラスターを展開するときに構成を変更する -新しいクラスタをデプロイする場合は、上記の設定を`topology.yaml` TiUPトポロジファイルに追加してクラスタをデプロイできます。具体的な手順については、 [TiUP展開ドキュメント](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)参照してください。 +新しいクラスターをデプロイする場合は、上記の設定を`topology.yaml` TiUPトポロジファイルに追加してクラスターをデプロイできます。具体的な手順については、 [TiUP展開ドキュメント](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)参照してください。
diff --git a/dashboard/dashboard-ops-security.md b/dashboard/dashboard-ops-security.md index 86928ad3ac31e..69a8590a8ede5 100644 --- a/dashboard/dashboard-ops-security.md +++ b/dashboard/dashboard-ops-security.md @@ -61,7 +61,7 @@ tiup cluster display CLUSTER_NAME --dashboard > > この機能は、 `tiup cluster`デプロイメント ツールの新しいバージョン (v1.0.3 以降) でのみ使用できます。 > ->
TiUPクラスタのアップグレード +>
TiUPクラスターのアップグレード > > ```bash > tiup update --self diff --git a/dashboard/dashboard-overview.md b/dashboard/dashboard-overview.md index 0d8010f7a931e..50927feb082e7 100644 --- a/dashboard/dashboard-overview.md +++ b/dashboard/dashboard-overview.md @@ -74,10 +74,10 @@ TiDB ダッシュボードにログインすると、デフォルトで概要ペ 上の画像のステータスは次のように説明されます。 -- 稼働中: インスタンスは正常に実行されています (オフラインstorageインスタンスを含む)。 +- 稼働中: インスタンスは正常に実行されています (オフラインストレージインスタンスを含む)。 - ダウン: ネットワーク切断やプロセスクラッシュなど、インスタンスが異常な状態で動作しています。 -**インスタンスの**タイトルをクリックすると、各インスタンスの詳細な実行ステータスを示す[クラスタ情報ページ](/dashboard/dashboard-cluster-info.md)が表示されます。 +**インスタンスの**タイトルをクリックすると、各インスタンスの詳細な実行ステータスを示す[クラスター情報ページ](/dashboard/dashboard-cluster-info.md)が表示されます。 ## 監視と警告 {#monitor-and-alert} diff --git a/dashboard/dashboard-resource-manager.md b/dashboard/dashboard-resource-manager.md index 0ea040e48782a..ebfba7dc84063 100644 --- a/dashboard/dashboard-resource-manager.md +++ b/dashboard/dashboard-resource-manager.md @@ -1,11 +1,11 @@ --- title: TiDB Dashboard Resource Manager Page -summary: TiDBダッシュボードのリソースマネージャページは、クラスタ管理者がリソースグループを作成し、クォータを設定することでリソース分離を実装するのに役立ちます。クラスタ容量を推定し、リソース消費量を監視するための方法を提供します。このページには、TiDBダッシュボードまたはブラウザからアクセスできます。このページには、構成、容量推定、およびメトリックのセクションがあります。容量推定方法には、ハードウェアの展開と実際のワークロードが含まれます。監視メトリックには、消費されたRUの合計、リソースグループによる消費RU、TiDB CPUクォータと使用量、TiKV CPUクォータと使用量、TiKV IO MBpsが含まれます。 +summary: TiDBダッシュボードのリソースマネージャページは、クラスター管理者がリソースグループを作成し、クォータを設定することでリソース分離を実装するのに役立ちます。クラスター容量を推定し、リソース消費量を監視するための方法を提供します。このページには、TiDBダッシュボードまたはブラウザからアクセスできます。このページには、構成、容量推定、およびメトリックのセクションがあります。容量推定方法には、ハードウェアの展開と実際のワークロードが含まれます。監視メトリックには、消費されたRUの合計、リソースグループによる消費RU、TiDB CPUクォータと使用量、TiKV CPUクォータと使用量、TiKV IO MBpsが含まれます。 --- # TiDBダッシュボードリソースマネージャーページ {#tidb-dashboard-resource-manager-page} -[リソース管理](/tidb-resource-control-ru-groups.md)機能を使用してリソース分離を実装するには、クラスタ管理者がリソースグループを作成し、各グループにクォータを設定する必要があります。リソースプランニングを行う前に、クラスタ全体の容量を把握しておく必要があります。このドキュメントでは、リソース制御に関する情報を参照することで、リソースプランニング前にクラスタの容量を見積もり、より効果的にリソースを割り当てることができます。 +[リソース管理](/tidb-resource-control-ru-groups.md)機能を使用してリソース分離を実装するには、クラスター管理者がリソースグループを作成し、各グループにクォータを設定する必要があります。リソースプランニングを行う前に、クラスター全体の容量を把握しておく必要があります。このドキュメントでは、リソース制御に関する情報を参照することで、リソースプランニング前にクラスターの容量を見積もり、より効果的にリソースを割り当てることができます。 ## ページにアクセスする {#access-the-page} @@ -23,7 +23,7 @@ summary: TiDBダッシュボードのリソースマネージャページは、 リソース マネージャー ページには、次の 3 つのセクションがあります。 -- コンフィグレーション: このセクションには、TiDBの`RESOURCE_GROUPS`テーブルから取得したデータが表示されます。すべてのリソースグループに関する情報が含まれています。詳細については、 [`RESOURCE_GROUPS`](/information-schema/information-schema-resource-groups.md)参照してください。 +- 設定: このセクションには、TiDBの`RESOURCE_GROUPS`テーブルから取得したデータが表示されます。すべてのリソースグループに関する情報が含まれています。詳細については、 [`RESOURCE_GROUPS`](/information-schema/information-schema-resource-groups.md)参照してください。 - 容量の見積もり：リソース計画を立てる前に、クラスター全体の容量を把握する必要があります。以下のいずれかの方法を使用できます。 diff --git a/dashboard/dashboard-slow-query.md b/dashboard/dashboard-slow-query.md index 887b1e35d4e5f..afcc08988257a 100644 --- a/dashboard/dashboard-slow-query.md +++ b/dashboard/dashboard-slow-query.md @@ -1,11 +1,11 @@ --- title: Slow Queries Page of TiDB Dashboard -summary: TiDBダッシュボードの「低速クエリ」ページでは、クラスタ内の低速クエリを検索して表示できます。実行時間が300ミリ秒を超えるクエリは低速とみなされます。ユーザーはしきい値を調整したり、ダッシュボードまたはブラウザからこのページにアクセスしたりできます。また、フィルタの変更、表示する列の追加、クエリのエクスポート、実行の詳細の表示も可能です。 +summary: TiDBダッシュボードの「低速クエリ」ページでは、クラスター内の低速クエリを検索して表示できます。実行時間が300ミリ秒を超えるクエリは低速とみなされます。ユーザーはしきい値を調整したり、ダッシュボードまたはブラウザからこのページにアクセスしたりできます。また、フィルタの変更、表示する列の追加、クエリのエクスポート、実行の詳細の表示も可能です。 --- # TiDBダッシュボードの低速クエリページ {#slow-queries-page-of-tidb-dashboard} -TiDBダッシュボードの「低速クエリ」ページでは、クラスタ内のすべての低速クエリを検索して表示できます。 +TiDBダッシュボードの「低速クエリ」ページでは、クラスター内のすべての低速クエリを検索して表示できます。 デフォルトでは、実行時間が300ミリ秒を超えるSQLクエリはスロークエリとみなされます。これらのクエリは[スロークエリログ](/identify-slow-queries.md)に記録され、TiDBダッシュボードから検索できます。スロークエリのしきい値は、セッション変数[`tidb_slow_log_threshold`](/system-variables.md#tidb_slow_log_threshold)またはTiDBパラメータ[`instance.tidb_slow_log_threshold`](/tidb-configuration-file.md#tidb_slow_log_threshold)で調整できます。 diff --git a/dashboard/top-sql.md b/dashboard/top-sql.md index 041c983f865fa..7fce781e60f30 100644 --- a/dashboard/top-sql.md +++ b/dashboard/top-sql.md @@ -1,6 +1,6 @@ --- title: TiDB Dashboard Top SQL page -summary: TiDB Dashboard Top SQLは、データベース内のSQLステートメントのCPUオーバーヘッドをリアルタイムで監視および可視化します。CPU負荷の高いステートメントを特定することでパフォーマンスの最適化を支援し、詳細な実行情報を提供します。パフォーマンス問題の分析に適しており、TiDB Dashboardまたはブラウザからアクセスできます。この機能はクラスタのパフォーマンスにわずかな影響を与えますが、現在、本番本番での利用が可能です。 +summary: TiDB Dashboard Top SQLは、データベース内のSQLステートメントのCPUオーバーヘッドをリアルタイムで監視および可視化します。CPU負荷の高いステートメントを特定することでパフォーマンスの最適化を支援し、詳細な実行情報を提供します。パフォーマンス問題の分析に適しており、TiDB Dashboardまたはブラウザからアクセスできます。この機能はクラスターのパフォーマンスにわずかな影響を与えますが、現在、本番環境での利用が可能です。 --- # TiDBダッシュボードのTop SQLページ {#tidb-dashboard-top-sql-page} @@ -18,10 +18,10 @@ Top SQLは以下の機能を提供します。 Top SQLは、パフォーマンスの問題を分析するのに適しています。以下に、 Top SQLの典型的なシナリオをいくつか示します。 -- Grafanaのグラフから、クラスタ内の特定のTiKVインスタンスのCPU使用率が非常に高いことが分かりました。どのSQL文がCPU使用率のホットスポットを引き起こしているのかを知り、それらを最適化して分散リソースをより効果的に活用したいと考えています。 +- Grafanaのグラフから、クラスター内の特定のTiKVインスタンスのCPU使用率が非常に高いことが分かりました。どのSQL文がCPU使用率のホットスポットを引き起こしているのかを知り、それらを最適化して分散リソースをより効果的に活用したいと考えています。 - クラスター全体のCPU使用率が非常に高く、クエリの実行速度が遅いことが判明しました。どのSQL文が現在最も多くのCPUリソースを消費しているかを迅速に特定し、最適化したいと考えています。 - クラスターのCPU使用率が劇的に変化しており、その主な原因を知りたいと考えている。 -- クラスタ内で最もリソースを消費するSQL文を分析し、最適化することでハードウェアコストを削減します。 +- クラスター内で最もリソースを消費するSQL文を分析し、最適化することでハードウェアコストを削減します。 以下のシナリオでは、Top SQLは使用できません。 @@ -44,7 +44,7 @@ Top SQLは、パフォーマンスの問題を分析するのに適していま > > Top SQLを使用するには、クラスターが最新バージョンのTiUP （v1.9.0以降）またはTiDB Operator （v1.3.0以降）を使用してデプロイまたはアップグレードされている必要があります。以前のバージョンのTiUPまたはTiDB Operatorを使用してクラスターをアップグレードした場合は、 [FAQ](/dashboard/dashboard-faq.md#a-required-component-ngmonitoring-is-not-started-error-is-shown)参照して手順を確認してください。 -Top SQLは、有効にするとクラスタのパフォーマンスにわずかな影響（平均で3%以内）を与えるため、デフォルトでは有効になっていません。Top Top SQLを有効にするには、以下の手順に従ってください。 +Top SQLは、有効にするとクラスターのパフォーマンスにわずかな影響（平均で3%以内）を与えるため、デフォルトでは有効になっていません。Top Top SQLを有効にするには、以下の手順に従ってください。 1. [Top SQLページ](#access-the-page)にアクセスしてください。 2. **「設定を開く」**をクリックします。**設定**領域の右側で、 **「機能を有効にする」**をオンにします。 @@ -68,7 +68,7 @@ SET GLOBAL tidb_enable_top_sql = 1; ![Select Instance](/media/dashboard/top-sql-usage-select-instance.png) - どの TiDB または TiKV インスタンスを監視すればよいか不明な場合は、任意のインスタンスを選択できます。また、クラスタの CPU 負荷が極端に偏っている場合は、まず Grafana のグラフを使用して、監視したい特定のインスタンスを特定できます。 + どの TiDB または TiKV インスタンスを監視すればよいか不明な場合は、任意のインスタンスを選択できます。また、クラスターの CPU 負荷が極端に偏っている場合は、まず Grafana のグラフを使用して、監視したい特定のインスタンスを特定できます。 3. Top SQLが提示するグラフと表をご覧ください。 @@ -123,7 +123,7 @@ SET GLOBAL tidb_enable_top_sql = 0; **2.Top SQLを有効にすると、パフォーマンスに影響が出ますか？** -この機能はクラスタのパフォーマンスにわずかな影響を与えます。弊社のベンチマークによると、この機能を有効にした場合の平均パフォーマンスへの影響は通常3%未満です。 +この機能はクラスターのパフォーマンスにわずかな影響を与えます。弊社のベンチマークによると、この機能を有効にした場合の平均パフォーマンスへの影響は通常3%未満です。 **3. この機能の現状はどうなっていますか？** diff --git a/data-type-numeric.md b/data-type-numeric.md index 2664782d6be82..cace1aaf8f013 100644 --- a/data-type-numeric.md +++ b/data-type-numeric.md @@ -39,7 +39,7 @@ TiDBは、 `INTEGER` / `INT` 、 `TINYINT` 、 `SMALLINT` 、 `MEDIUMINT` 、 `B | 署名なし | UNSIGNED。省略した場合はSIGNEDになります。 | | ゼロフィル | 数値列に ZEROFILL を指定すると、TiDB は列に UNSIGNED 属性を自動的に追加します。 | -次の表は、TiDB でサポートされる整数型に必要なstorageと範囲をまとめたものです。 +次の表は、TiDB でサポートされる整数型に必要なストレージと範囲をまとめたものです。 | データ型 | 必要なストレージ容量（バイト） | 最小値（符号付き/符号なし） | 最大値（符号付き/符号なし） | | ----------- | --------------- | ------------------------ | ------------------------------------------ | @@ -51,7 +51,7 @@ TiDBは、 `INTEGER` / `INT` 、 `TINYINT` 、 `SMALLINT` 、 `MEDIUMINT` 、 `B ### BITタイプ {#code-bit-code-type} -BITデータ型。BIT(M)型はMビット値をstorageします。Mは1から64までの範囲で指定でき、デフォルト値は1です。 +BITデータ型。BIT(M)型はMビット値をストレージします。Mは1から64までの範囲で指定でき、デフォルト値は1です。 ```sql BIT[(M)] @@ -124,7 +124,7 @@ TiDBは、 `FLOAT` 、 `DOUBLE`含むすべてのMySQL浮動小数点型をサ | 署名なし | UNSIGNED。省略した場合はSIGNEDになります。 | | ゼロフィル | 数値列に ZEROFILL を指定すると、TiDB は列に UNSIGNED 属性を自動的に追加します。 | -次の表は、TiDB でサポートされる浮動小数点型に必要なstorageをまとめたものです。 +次の表は、TiDB でサポートされる浮動小数点型に必要なストレージをまとめたものです。 | データ型 | 必要なストレージ容量（バイト） | | ---------- | ------------------------------------------------ | diff --git a/data-type-string.md b/data-type-string.md index 9b7a2dba11d73..c037b187218d6 100644 --- a/data-type-string.md +++ b/data-type-string.md @@ -55,12 +55,12 @@ TINYTEXT [CHARACTER SET charset_name] [COLLATE collation_name] -`MEDIUMTEXT`型は[`TEXT`タイプ](#text-type)と似ています。違いは、 `MEDIUMTEXT`の最大列長が16,777,215である点です。ただし、 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDBの1行の最大storageサイズはデフォルトで6MiBですが、設定を変更することで120MiBまで増やすことができます。 +`MEDIUMTEXT`型は[`TEXT`タイプ](#text-type)と似ています。違いは、 `MEDIUMTEXT`の最大列長が16,777,215である点です。ただし、 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDBの1行の最大ストレージサイズはデフォルトで6MiBですが、設定を変更することで120MiBまで増やすことができます。 -`MEDIUMTEXT`型は[`TEXT`タイプ](#text-type)と似ています。違いは、 `MEDIUMTEXT`の最大列長が16,777,215である点です。ただし、 [`txn-entry-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDBの1行の最大storageサイズはデフォルトで6MiBですが、設定を変更することで120MiBまで増やすことができます。 +`MEDIUMTEXT`型は[`TEXT`タイプ](#text-type)と似ています。違いは、 `MEDIUMTEXT`の最大列長が16,777,215である点です。ただし、 [`txn-entry-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDBの1行の最大ストレージサイズはデフォルトで6MiBですが、設定を変更することで120MiBまで増やすことができます。 @@ -72,12 +72,12 @@ MEDIUMTEXT [CHARACTER SET charset_name] [COLLATE collation_name] -`LONGTEXT`型は[`TEXT`タイプ](#text-type)型と似ています。違いは、 `LONGTEXT`の最大列長が 4,294,967,295 である点です。ただし、 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDB の単一行の最大storageサイズはデフォルトで 6 MiB となり、設定を変更することで 120 MiB まで増やすことができます。 +`LONGTEXT`型は[`TEXT`タイプ](#text-type)型と似ています。違いは、 `LONGTEXT`の最大列長が 4,294,967,295 である点です。ただし、 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDB の単一行の最大ストレージサイズはデフォルトで 6 MiB となり、設定を変更することで 120 MiB まで増やすことができます。 -`LONGTEXT`型は[`TEXT`タイプ](#text-type)型と似ています。違いは、 `LONGTEXT`の最大列長が 4,294,967,295 である点です。ただし、 [`txn-entry-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDB の単一行の最大storageサイズはデフォルトで 6 MiB となり、設定を変更することで 120 MiB まで増やすことができます。 +`LONGTEXT`型は[`TEXT`タイプ](#text-type)型と似ています。違いは、 `LONGTEXT`の最大列長が 4,294,967,295 である点です。ただし、 [`txn-entry-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDB の単一行の最大ストレージサイズはデフォルトで 6 MiB となり、設定を変更することで 120 MiB まで増やすことができます。 @@ -121,12 +121,12 @@ TINYBLOB -`MEDIUMBLOB`型は[`BLOB`型](#blob-type)と似ています。違いは、 `MEDIUMBLOB`の最大列長が16,777,215である点です。ただし、 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDBの1行の最大storageサイズはデフォルトで6MiBですが、設定を変更することで120MiBまで増やすことができます。 +`MEDIUMBLOB`型は[`BLOB`型](#blob-type)と似ています。違いは、 `MEDIUMBLOB`の最大列長が16,777,215である点です。ただし、 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDBの1行の最大ストレージサイズはデフォルトで6MiBですが、設定を変更することで120MiBまで増やすことができます。 -`MEDIUMBLOB`型は[`BLOB`型](#blob-type)と似ています。違いは、 `MEDIUMBLOB`の最大列長が16,777,215である点です。ただし、 [`txn-entry-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDBの1行の最大storageサイズはデフォルトで6MiBですが、設定を変更することで120MiBまで増やすことができます。 +`MEDIUMBLOB`型は[`BLOB`型](#blob-type)と似ています。違いは、 `MEDIUMBLOB`の最大列長が16,777,215である点です。ただし、 [`txn-entry-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDBの1行の最大ストレージサイズはデフォルトで6MiBですが、設定を変更することで120MiBまで増やすことができます。 @@ -138,12 +138,12 @@ MEDIUMBLOB -`LONGBLOB`型は[`BLOB`型](#blob-type)型と似ています。違いは、 `LONGBLOB`の最大列長が 4,294,967,295 である点です。ただし、 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDB の単一行の最大storageサイズはデフォルトで 6 MiB となり、設定を変更することで 120 MiB まで増やすことができます。 +`LONGBLOB`型は[`BLOB`型](#blob-type)型と似ています。違いは、 `LONGBLOB`の最大列長が 4,294,967,295 である点です。ただし、 [`txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDB の単一行の最大ストレージサイズはデフォルトで 6 MiB となり、設定を変更することで 120 MiB まで増やすことができます。 -`LONGBLOB`型は[`BLOB`型](#blob-type)型と似ています。違いは、 `LONGBLOB`の最大列長が 4,294,967,295 である点です。ただし、 [`txn-entry-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDB の単一行の最大storageサイズはデフォルトで 6 MiB となり、設定を変更することで 120 MiB まで増やすことができます。 +`LONGBLOB`型は[`BLOB`型](#blob-type)型と似ています。違いは、 `LONGBLOB`の最大列長が 4,294,967,295 である点です。ただし、 [`txn-entry-size-limit`](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#txn-entry-size-limit-new-in-v4010-and-v500)の制限により、TiDB の単一行の最大ストレージサイズはデフォルトで 6 MiB となり、設定を変更することで 120 MiB まで増やすことができます。 diff --git a/deploy-monitoring-services.md b/deploy-monitoring-services.md index 82988d3e6bd41..b42d0b291c16e 100644 --- a/deploy-monitoring-services.md +++ b/deploy-monitoring-services.md @@ -3,7 +3,7 @@ title: Deploy Monitoring Services for the TiDB Cluster summary: TiDB クラスターの監視サービスをデプロイする方法を学習します。 --- -# TiDBクラスタの監視サービスをデプロイ {#deploy-monitoring-services-for-the-tidb-cluster} +# TiDBクラスターの監視サービスをデプロイ {#deploy-monitoring-services-for-the-tidb-cluster} このドキュメントは、TiDB 監視およびアラートサービスを手動でデプロイしたいユーザーを対象としています。TiUPを使用して TiDB クラスターをデプロイする場合、監視およびアラートサービスは自動的にデプロイされるため、手動でのデプロイは不要です。1 [TiDBダッシュボード](/dashboard/dashboard-intro.md) PDコンポーネントに組み込まれているため、別途デプロイする必要はありません。 @@ -131,8 +131,8 @@ $ ./prometheus \ --web.external-url="http://192.168.199.113:9090/" \ --web.enable-admin-api \ --log.level="info" \ - --storage.tsdb.path="./data.metrics" \ - --storage.tsdb.retention="15d" & + --ストレージ.tsdb.path="./data.metrics" \ + --ストレージ.tsdb.retention="15d" & ``` ### ステップ 4: Node1 で Grafana を開始する {#step-4-start-grafana-on-node1} @@ -210,7 +210,7 @@ Grafana サービスを開始します。 > > **パスワードの変更**手順では、 **「スキップ」**を選択できます。 -2. Grafana サイドバー メニューで、**コンフィグレーション**内の**データ ソース**をクリックします。 +2. Grafana サイドバー メニューで、**設定**内の**データ ソース**をクリックします。 3. **データ ソースの追加を**クリックします。 diff --git a/develop/dev-guide-bookshop-schema-design.md b/develop/dev-guide-bookshop-schema-design.md index a65fa3dfc135f..e4bf206729b36 100644 --- a/develop/dev-guide-bookshop-schema-design.md +++ b/develop/dev-guide-bookshop-schema-design.md @@ -14,12 +14,12 @@ Bookshopは、さまざまなジャンルの本を購入したり、読んだ本 Bookshopアプリケーションのテーブル構造とデータをインポートするには、以下のインポート方法のいずれかを選択してください。 -- [TiDB セルフマネージド: `tiup demo`経由](#tidb-self-managed-via-tiup-demo)。 +- [TiDB Self-Managed: `tiup demo`経由](#tidb-self-managed-via-tiup-demo)。 - [TiDB Cloud：インポート機能経由](#tidb-cloud-via-the-import-feature)。 -### TiDB セルフマネージド: tiup demo経由 {#tidb-self-managed-via-code-tiup-demo-code} +### TiDB Self-Managed: tiup demo経由 {#tidb-self-managed-via-code-tiup-demo-code} -[TiUP](/tiup/tiup-reference.md#tiup-reference)を使用してTiDBセルフマネージドクラスタをデプロイしている場合、またはTiDBサーバーに接続できる場合は、次のコマンドを実行することで、Bookshopアプリケーション用のサンプルデータをすばやく生成してインポートできます。 +[TiUP](/tiup/tiup-reference.md#tiup-reference)を使用してTiDB Self-Managedクラスターをデプロイしている場合、またはTiDBサーバーに接続できる場合は、次のコマンドを実行することで、Bookshopアプリケーション用のサンプルデータをすばやく生成してインポートできます。 ```shell tiup demo bookshop prepare diff --git a/develop/dev-guide-choose-driver-or-orm.md b/develop/dev-guide-choose-driver-or-orm.md index fbf721e12c44a..7ab8ed8816538 100644 --- a/develop/dev-guide-choose-driver-or-orm.md +++ b/develop/dev-guide-choose-driver-or-orm.md @@ -307,4 +307,4 @@ peewee を使用して TiDB アプリケーションを構築する例につい - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-connection-parameters.md b/develop/dev-guide-connection-parameters.md index dd03846753b5b..27fe07110569b 100644 --- a/develop/dev-guide-connection-parameters.md +++ b/develop/dev-guide-connection-parameters.md @@ -128,7 +128,7 @@ SSDを使用する場合は、経験に基づき、以下の式を使用する 最適なサイズを選ぶための基本的なルールをいくつかご紹介します。 -- ネットワークまたはstorageのレイテンシーが高い場合は、最大接続数を増やしてレイテンシーによる待ち時間を短縮してください。スレッドがレイテンシーによってブロックされた場合でも、他のスレッドが処理を引き継いで処理を続行できます。 +- ネットワークまたはストレージのレイテンシーが高い場合は、最大接続数を増やしてレイテンシーによる待ち時間を短縮してください。スレッドがレイテンシーによってブロックされた場合でも、他のスレッドが処理を引き継いで処理を続行できます。 - サーバー上に複数のサービスがデプロイされており、各サービスがそれぞれ独立した接続プールを持っている場合は、すべての接続プールへの最大接続数の合計を考慮してください。 ## 接続パラメータ {#connection-parameters} @@ -176,7 +176,7 @@ JDBCでは通常、以下の2つの処理方法が使用されます。 TiDBは両方の方法をサポートしていますが、実装がよりシンプルで実行効率も優れているため、 `FetchSize`から`Integer.MIN_VALUE`に設定する最初の方法を使用することをお勧めします。 -2番目の方法では、TiDBはまずすべてのデータをTiDBノードにロードし、次に`FetchSize`に従ってクライアントにデータを返します。そのため、通常は最初の方法よりも多くのメモリを消費します。3 [`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom) `ON`設定されている場合、TiDBは結果を一時的にハードディスクに書き込む可能性があります。 +2番目の方法では、TiDBはまずすべてのデータをTiDBノードにロードし、次に`FetchSize`に従ってクライアントにデータを返します。そのため、通常は最初の方法よりも多くのメモリを消費します。3 [`tidb_enable_tmp_ストレージ_on_oom`](/system-variables.md#tidb_enable_tmp_ストレージ_on_oom) `ON`設定されている場合、TiDBは結果を一時的にハードディスクに書き込む可能性があります。 システム変数[`tidb_enable_lazy_cursor_fetch`](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830) `ON`に設定されている場合、TiDB はクライアントがデータを取得するときにのみデータの一部を読み取ろうとします。これによりメモリ使用量が削減されます。詳細および制限事項については、 [`tidb_enable_lazy_cursor_fetch`システム変数の完全な説明](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830)を参照してください。 @@ -288,7 +288,7 @@ UPDATE `t` SET `a` = 10 WHERE `id` = 1; UPDATE `t` SET `a` = 11 WHERE `id` = 2; #### パラメータを統合する {#integrate-parameters} -監視を通じて、アプリケーションが TiDB クラスタに対して実行する操作は`INSERT`だけであるにもかかわらず、冗長な`SELECT`ステートメントが多数あることに気づくかもしれません。通常、これは JDBC が設定を照会するためにいくつかの SQL ステートメントを送信することによって発生します (例: `select @@session.transaction_read_only` )。これらの SQL ステートメントは TiDB にとって不要なので、余分なオーバーヘッドを避けるために`useConfigs=maxPerformance`を設定することをお勧めします。 +監視を通じて、アプリケーションが TiDB クラスターに対して実行する操作は`INSERT`だけであるにもかかわらず、冗長な`SELECT`ステートメントが多数あることに気づくかもしれません。通常、これは JDBC が設定を照会するためにいくつかの SQL ステートメントを送信することによって発生します (例: `select @@session.transaction_read_only` )。これらの SQL ステートメントは TiDB にとって不要なので、余分なオーバーヘッドを避けるために`useConfigs=maxPerformance`を設定することをお勧めします。 `useConfigs=maxPerformance`には設定のグループが含まれています。MySQL Connector/J 8.0およびMySQL Connector/J 5.1の詳細な設定については、それぞれ[mysql-connector-j 8.0](https://github.com/mysql/mysql-connector-j/blob/release/8.0/src/main/resources/com/mysql/cj/configurations/maxPerformance.properties)および[mysql-connector-j 5.1](https://github.com/mysql/mysql-connector-j/blob/release/5.1/src/com/mysql/jdbc/configs/maxPerformance.properties)を参照してください。 diff --git a/develop/dev-guide-create-secondary-indexes.md b/develop/dev-guide-create-secondary-indexes.md index dda3dfd839448..b111ddf23741b 100644 --- a/develop/dev-guide-create-secondary-indexes.md +++ b/develop/dev-guide-create-secondary-indexes.md @@ -138,7 +138,7 @@ CREATE INDEX `idx_book_published_at` ON `bookshop`.`books` (`bookshop`.`books`.` SQLパフォーマンスチューニングの詳細については、以下のドキュメントを参照してください。 - [TiDB CloudのSQLチューニング概要](/tidb-cloud/tidb-cloud-sql-tuning-overview.md) -- [TiDBセルフマネージドのSQLチューニング概要](/sql-tuning-overview.md) +- [TiDB Self-ManagedのSQLチューニング概要](/sql-tuning-overview.md) > **注記：** > diff --git a/develop/dev-guide-create-table.md b/develop/dev-guide-create-table.md index 4da56f8cadc73..873611e5e7342 100644 --- a/develop/dev-guide-create-table.md +++ b/develop/dev-guide-create-table.md @@ -101,11 +101,11 @@ CREATE TABLE `bookshop`.`books` ( > **注記：** > -> TiDBにおける**プライマリキー**のデフォルト定義は、 [InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html) （MySQLの一般的なstorageエンジン）における定義とは異なります。 +> TiDBにおける**プライマリキー**のデフォルト定義は、 [InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-ストレージ-engine.html) （MySQLの一般的なストレージエンジン）における定義とは異なります。 > -> - **InnoDB**では、**プライマリキー**は一意であり、nullではなく、**インデックスはクラスタ化されています**。 +> - **InnoDB**では、**プライマリキー**は一意であり、nullではなく、**インデックスはクラスター化されています**。 > -> - TiDBでは、**プライマリキー**は一意であり、NULLであってはなりません。ただし、プライマリキーが**クラスタ化インデックス**であることは保証されていません。代わりに、別のキーワードセット`CLUSTERED` / `NONCLUSTERED`によって、**プライマリキーが****クラスタ化インデックス**であるかどうかが制御されます。キーワードが指定されていない場合は、システム変数`@@global.tidb_enable_clustered_index`によって制御されます（化を参照[クラスター化インデックス](https://docs.pingcap.com/tidb/stable/clustered-indexes)。 +> - TiDBでは、**プライマリキー**は一意であり、NULLであってはなりません。ただし、プライマリキーが**クラスター化インデックス**であることは保証されていません。代わりに、別のキーワードセット`CLUSTERED` / `NONCLUSTERED`によって、**プライマリキーが****クラスター化インデックス**であるかどうかが制御されます。キーワードが指定されていない場合は、システム変数`@@global.tidb_enable_clustered_index`によって制御されます（化を参照[クラスター化インデックス](https://docs.pingcap.com/tidb/stable/clustered-indexes)。 **主キー**は`CREATE TABLE`ステートメントで定義されます。[主キー制約](/constraints.md#primary-key)制約付き列すべてに NULL 以外の値のみが含まれることを要求します。 @@ -113,7 +113,7 @@ CREATE TABLE `bookshop`.`books` ( テーブルの**主キー**が[整数型](/data-type-numeric.md#integer-types)で`AUTO_INCREMENT`が使用されている場合、 `SHARD_ROW_ID_BITS`を使用してもホットスポットを回避することはできません。ホットスポットを回避する必要があり、かつ連続的かつ増分的な主キーが必要ない場合は、 `AUTO_INCREMENT`の代わりに[`AUTO_RANDOM`](/auto-random.md)を使用して行 ID の連続性を排除できます。 -TiDB セルフマネージドでホットスポットの問題を処理する方法の詳細については、[ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md)。 +TiDB Self-Managedでホットスポットの問題を処理する方法の詳細については、[ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md)。 [主キーの選択に関するガイドライン](#guidelines-to-follow-when-selecting-primary-key)に従って、次の例は、 `AUTO_RANDOM`の主キーが`users`テーブルでどのように定義されるかを示しています。 @@ -130,21 +130,21 @@ CREATE TABLE `bookshop`.`users` ( TiDB は v5.0 以降、[クラスター化インデックス](/clustered-indexes.md)機能をサポートしています。この機能は、主キーを含むテーブルにデータを格納する方法を制御します。これにより、特定のクエリのパフォーマンスを向上できる方法でテーブルを編成する機能が TiDB に提供されます。 -この文脈における「クラスタ化」という用語は、データの格納方法の構成を指し、連携して動作するデータベースサーバーのグループを指すものではありません。一部のデータベース管理システムでは、クラスタ化されたインデックステーブルをインデックス構成テーブル（IOT）と呼んでいます。 +この文脈における「クラスター化」という用語は、データの格納方法の構成を指し、連携して動作するデータベースサーバーのグループを指すものではありません。一部のデータベース管理システムでは、クラスター化されたインデックステーブルをインデックス構成テーブル（IOT）と呼んでいます。 現在、TiDBの***主キーを含む***テーブルは、以下の2つのカテゴリに分類されます。 - `NONCLUSTERED` : テーブルの主キーは非クラスター化インデックスです。非クラスター化インデックスを持つテーブルでは、行データのキーは、TiDB によって暗黙的に割り当てられる内部`_tidb_rowid`で構成されます。主キーは基本的に一意のインデックスであるため、非クラスター化インデックスを持つテーブルでは、行を格納するために少なくとも 2 つのキーと値のペアが必要です。それらは次のとおりです。 - `_tidb_rowid` （キー） - 行データ（値） - 主キーデータ（キー） - `_tidb_rowid` （値） -- `CLUSTERED` : テーブルの主キーはクラスタ化インデックスです。クラスタ化インデックスを持つテーブルでは、行データのキーはユーザーが指定した主キーデータで構成されます。したがって、クラスタ化インデックスを持つテーブルでは、行を格納するために必要なキーと値のペアは1つだけです。それは次のとおりです。 +- `CLUSTERED` : テーブルの主キーはクラスター化インデックスです。クラスター化インデックスを持つテーブルでは、行データのキーはユーザーが指定した主キーデータで構成されます。したがって、クラスター化インデックスを持つテーブルでは、行を格納するために必要なキーと値のペアは1つだけです。それは次のとおりです。 - 主キーデータ（キー） - 行データ（値） [プライマリキーを選択](#select-primary-key)で説明されているように、**クラスター化インデックス**は TiDB でキーワード`CLUSTERED`および`NONCLUSTERED`を使用して制御されます。 > **注記：** > -> TiDB は、テーブルの`PRIMARY KEY`によるクラスタリングのみをサポートしています。クラスタ化インデックスが有効になっている場合、 *{* `PRIMARY KEY`と*クラスタ化インデックス*という用語は同じ意味で使用されることがあります。 `PRIMARY KEY`は制約 (論理プロパティ) を指し、クラスタ化インデックスはデータの格納方法の物理的な実装を表します。 +> TiDB は、テーブルの`PRIMARY KEY`によるクラスターリングのみをサポートしています。クラスター化インデックスが有効になっている場合、 *{* `PRIMARY KEY`と*クラスター化インデックス*という用語は同じ意味で使用されることがあります。 `PRIMARY KEY`は制約 (論理プロパティ) を指し、クラスター化インデックスはデータの格納方法の物理的な実装を表します。 [クラスター化インデックスを選択するためのガイドライン](#guidelines-to-follow-when-selecting-clustered-index)ためのガイドラインに従って、次の例では、 `books`と`users` } の間の関連付けを持つテーブルを作成します。これは、 `ratings` `book`を表します。 `users` .この例では、テーブルを作成し、 `book_id`と`user_id`を使用して複合主キーを構築し、その**主キー**に**クラスター化インデックス**を作成します。 @@ -228,13 +228,13 @@ CREATE TABLE `bookshop`.`users` ( > **注記：** > -> このセクションで説明する手順は、クイック スタートとテスト***のみ***を目的としています。 TiDB での HTAP の使用法の詳細については、 [HTAPを探索する](/explore-htap.md)参照してください。 +> このセクションで説明する手順は、クイック スタートとテスト***のみ***を目的としています。 TiDB での HTAP の使用法の詳細については、 [HTAP入門](/explore-htap.md)参照してください。 `ratings`アプリケーションを使用して`bookshop`テーブルに対して OLAP 分析を実行したいとします。たとえば、**書籍の評価と評価のタイミングに有意な相関関係があるかどうかを**クエリし、ユーザーによる書籍の評価が客観的かどうかを分析したいとします。この場合`score`フィールドと`rated_at` `ratings` } フィールドをクエリする必要があります。この操作は、OLTP 専用データベースではリソースを大量に消費します。または、ETL やその他のデータ同期ツールを使用して、OLTP データベースから専用の OLAP データベースにデータをエクスポートして分析することもできます。 このシナリオでは、OLTPとOLAPの両方のシナリオをサポートする**HTAP（ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング）**データベースであるTiDBが、理想的なワンストップデータベースソリューションとなります。 -TiDBでは、オンライン・トランザクション処理（OLTP）には行ベースのstorageエンジンである[ティクヴ](/tikv-overview.md)、オンライン分析処理（OLAP）には列指向storageエンジンである[TiFlash](/tiflash/tiflash-overview.md)を使用できます。設定後、 TiFlashはRaft Learnerコンセンサスアルゴリズムに従ってTiKVからリアルタイムでデータを複製し、TiKVとTiFlash間のデータの一貫性を厳密に確保します。 +TiDBでは、オンライン・トランザクション処理（OLTP）には行ベースのストレージエンジンである[TiKV](/tikv-overview.md)、オンライン分析処理（OLAP）には列指向ストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)を使用できます。設定後、 TiFlashはRaftラーナーコンセンサスアルゴリズムに従ってTiKVからリアルタイムでデータを複製し、TiKVとTiFlash間のデータの一貫性を厳密に確保します。 ### 列ベースのデータを複製する {#replicate-column-based-data} @@ -340,7 +340,7 @@ SHOW TABLES IN `bookshop`; - 列のサポート[データ型](/data-type-overview.md)を確認し、データ型の制約に従ってデータを整理してください。列に格納するデータに適した型を選択してください。 - 主キーの選択に関する[従うべきガイドライン](#guidelines-to-follow-when-selecting-primary-key)を確認し、主キー列を使用するかどうかを決定します。 -- クラスタ化インデックスを選択するための[従うべきガイドライン](#guidelines-to-follow-when-selecting-clustered-index)ガイドラインを確認し、**クラスタ化インデックス**を指定するかどうかを決定してください。 +- クラスター化インデックスを選択するための[従うべきガイドライン](#guidelines-to-follow-when-selecting-clustered-index)ガイドラインを確認し、**クラスター化インデックス**を指定するかどうかを決定してください。 - [列制約を追加する](#add-column-constraints)チェックし、列に制約を追加するかどうかを決定します。 - 意味のある列名を使用してください。会社または組織のテーブル命名規則に従うことをお勧めします。会社または組織に対応する命名規則がない場合は、 [列名の命名規則](/develop/dev-guide-object-naming-guidelines.md#column-naming-convention)を参照してください。 @@ -359,14 +359,14 @@ SHOW TABLES IN `bookshop`; - **クラスター化インデックス**を構築するには、 [主キーの選択に関するガイドライン](#guidelines-to-follow-when-selecting-primary-key)に従ってください。 - クラスター化インデックスを持たないテーブルと比較して、クラスター化インデックスを持つテーブルは、以下のシナリオにおいて、より優れたパフォーマンスとスループットのメリットを提供します。 - - データが挿入される際、クラスタ化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 - - 同等の条件を持つクエリが主キーのみに関係する場合、クラスタ化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 - - 範囲条件を含むクエリが主キーのみに関係する場合、クラスタ化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 - - 同等条件または範囲条件を含むクエリが主キーのプレフィックスのみに関係する場合、クラスタ化インデックスはネットワークからのインデックスデータの複数回の読み取りを削減します。 + - データが挿入される際、クラスター化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 + - 同等の条件を持つクエリが主キーのみに関係する場合、クラスター化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 + - 範囲条件を含むクエリが主キーのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 + - 同等条件または範囲条件を含むクエリが主キーのプレフィックスのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの複数回の読み取りを削減します。 - 一方、クラスター化インデックスを持つテーブルには、次のような問題が発生する可能性があります。 - 近い値を持つ主キーを多数挿入すると、書き込みホットスポットの問題が発生する可能性があります。 [主キーを選択する際に従うべきガイドライン](#guidelines-to-follow-when-selecting-primary-key)てください。 - - 主キーのデータ型が64ビットより大きい場合、特にセカンダリインデックスが複数存在する場合は、テーブルデータがより多くのstorage容量を消費します。 + - 主キーのデータ型が64ビットより大きい場合、特にセカンダリインデックスが複数存在する場合は、テーブルデータがより多くのストレージ容量を消費します。 - [クラスター化インデックスを使用するかどうかのデフォルトの動作](/clustered-indexes.md#create-a-table-with-clustered-indexes)を制御するには、システム変数`@@global.tidb_enable_clustered_index`と構成`alter-primary-key` } を使用する代わりに、クラスター化インデックスを使用するかどうかを明示的に指定できます。 diff --git a/develop/dev-guide-get-data-from-single-table.md b/develop/dev-guide-get-data-from-single-table.md index 0bec43b3652b9..317331735c201 100644 --- a/develop/dev-guide-get-data-from-single-table.md +++ b/develop/dev-guide-get-data-from-single-table.md @@ -26,7 +26,7 @@ aliases: ['/ja/tidb/stable/dev-guide-get-data-from-single-table/','/ja/tidb/dev/
-1. [TiDBセルフマネージドクラスタをデプロイ](/production-deployment-using-tiup.md)。 +1. [TiDB Self-Managedクラスターをデプロイ](/production-deployment-using-tiup.md)。 2. [Bookshopアプリケーションのテーブルスキーマとサンプルデータをインポートします。](/develop/dev-guide-bookshop-schema-design.md#import-table-structures-and-data) 3. [TiDBに接続する](/develop/dev-guide-connect-to-tidb.md)。 diff --git a/develop/dev-guide-gui-datagrip.md b/develop/dev-guide-gui-datagrip.md index a09b718c03a9f..7f190f59ea131 100644 --- a/develop/dev-guide-gui-datagrip.md +++ b/develop/dev-guide-gui-datagrip.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-gui-datagrip/','/ja/tidb/dev/dev-guide-gui- # JetBrains DataGripを使用してTiDBに接続する {#connect-to-tidb-with-jetbrains-datagrip} -TiDBはMySQL互換のデータベースであり、 [JetBrains DataGrip](https://www.jetbrains.com/help/datagrip/getting-started.html)データベースとSQLのための強力な統合開発環境（IDE）です。このチュートリアルでは、DataGripを使用してTiDBクラスタに接続する手順を説明します。 +TiDBはMySQL互換のデータベースであり、 [JetBrains DataGrip](https://www.jetbrains.com/help/datagrip/getting-started.html)データベースとSQLのための強力な統合開発環境（IDE）です。このチュートリアルでは、DataGripを使用してTiDBクラスターに接続する手順を説明します。 > **注記：** > @@ -24,12 +24,12 @@ DataGripは2つの方法で使用できます。 このチュートリアルを完了するには、以下が必要です。 - [DataGrip **2023.2.1**以降](https://www.jetbrains.com/datagrip/download/)、または非コミュニティ エディションの[ジェットブレインズ](https://www.jetbrains.com/)IDE。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続する {#connect-to-tidb} @@ -120,7 +120,7 @@ DataGripは2つの方法で使用できます。
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -128,7 +128,7 @@ DataGripは2つの方法で使用できます。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. DataGripを起動し、接続を管理するためのプロジェクトを作成します。 @@ -180,9 +180,9 @@ DataGripは2つの方法で使用できます。 3. 以下の接続パラメータを設定してください。 - - **ホスト**：TiDBセルフマネージドクラスタのIPアドレスまたはドメイン名。 - - **ポート**：TiDBセルフマネージドクラスタのポート番号。 - - **ユーザー**：TiDBセルフマネージドクラスタに接続するために使用するユーザー名。 + - **ホスト**：TiDB Self-ManagedクラスターのIPアドレスまたはドメイン名。 + - **ポート**：TiDB Self-Managedクラスターのポート番号。 + - **ユーザー**：TiDB Self-Managedクラスターに接続するために使用するユーザー名。 - **パスワード**：ユーザー名のパスワード。 例えば、以下のような例があります。 @@ -191,7 +191,7 @@ DataGripは2つの方法で使用できます。 **「不足しているドライバファイルをダウンロードしてください」**という警告が表示された場合は、 **「ダウンロード」**をクリックしてドライバファイルを入手してください。 -4. **「接続テスト」**をクリックして、TiDBセルフマネージドクラスタへの接続を検証してください。 +4. **「接続テスト」**をクリックして、TiDB Self-Managedクラスターへの接続を検証してください。 ![Test the connection to a TiDB Self-Managed cluster](/media/develop/datagrip-self-hosted-test-connection.jpg) @@ -203,7 +203,7 @@ DataGripは2つの方法で使用できます。 ## 次のステップ {#next-steps} - DataGrip の使用法の詳細については[DataGripのドキュメント](https://www.jetbrains.com/help/datagrip/getting-started.html)ご覧ください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-gui-dbeaver.md b/develop/dev-guide-gui-dbeaver.md index 7d5851a830341..3a011499a7295 100644 --- a/develop/dev-guide-gui-dbeaver.md +++ b/develop/dev-guide-gui-dbeaver.md @@ -19,12 +19,12 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt このチュートリアルを完了するには、以下が必要です。 - [DBeaver Community **23.0.3**以降](https://dbeaver.io/download/)。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) さらに、 **Windows**上の DBeaver からTiDB Cloud StarterまたはTiDB Cloud Essential のパブリックエンドポイントに接続するには、以下の手順で追加の SSL 証明書 (ISRG Root X1) を設定する必要があります。設定しない場合、接続は失敗します。その他のオペレーティングシステムの場合は、これらの手順はスキップできます。 @@ -128,7 +128,7 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -136,7 +136,7 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. DBeaverを起動し、左上隅の**「新しいデータベース接続」**をクリックします。 **「データベースへの接続**」ダイアログで、リストから**TiDBを**選択し、 **「次へ」**をクリックします。 @@ -176,16 +176,16 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt 2. 以下の接続パラメータを設定してください。 - - **サーバーホスト**：TiDBセルフマネージドクラスタのIPアドレスまたはドメイン名。 - - **ポート**：TiDBセルフマネージドクラスタのポート番号。 - - **ユーザー名**：TiDBセルフマネージドクラスタに接続するために使用するユーザー名。 + - **サーバーホスト**：TiDB Self-ManagedクラスターのIPアドレスまたはドメイン名。 + - **ポート**：TiDB Self-Managedクラスターのポート番号。 + - **ユーザー名**：TiDB Self-Managedクラスターに接続するために使用するユーザー名。 - **パスワード**：ユーザー名のパスワード。 例えば、以下のような例があります。 ![Configure connection settings for TiDB Self-Managed](/media/develop/dbeaver-connection-settings-self-hosted.jpg) -3. **「接続テスト」**をクリックして、TiDBセルフマネージドクラスタへの接続を検証してください。 +3. **「接続テスト」**をクリックして、TiDB Self-Managedクラスターへの接続を検証してください。 **「ドライバファイルのダウンロード」**ダイアログが表示されたら、 **「ダウンロード」**をクリックしてドライバファイルを入手してください。 @@ -203,7 +203,7 @@ TiDBはMySQL互換データベースであり、 [DBeaverコミュニティ](htt ## 次のステップ {#next-steps} - DBeaver の使用法の詳細については[DBeaverのドキュメント](https://github.com/dbeaver/dbeaver/wiki)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-gui-mysql-workbench.md b/develop/dev-guide-gui-mysql-workbench.md index ebea00ff7f971..5fe7a85658796 100644 --- a/develop/dev-guide-gui-mysql-workbench.md +++ b/develop/dev-guide-gui-mysql-workbench.md @@ -24,12 +24,12 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my このチュートリアルを完了するには、以下が必要です。 - [MySQL Workchen](https://dev.mysql.com/downloads/workbench/) **8.0.31**以降のバージョン。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続する {#connect-to-tidb} @@ -116,7 +116,7 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -124,7 +124,7 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. MySQL Workbenchを起動し、 **「MySQL Connections」**タイトルの横にある**「+」**をクリックします。 @@ -136,7 +136,7 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my - **ホスト名**： TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 - **ポート**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 - **ユーザー名**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 - - **パスワード**： **[キーチェーンに保存...]**をクリックし、 TiDB Cloud Dedicatedクラスタのパスワードを入力して、 **[OK]**をクリックするとパスワードが保存されます。 + - **パスワード**： **[キーチェーンに保存...]**をクリックし、 TiDB Cloud Dedicatedクラスターのパスワードを入力して、 **[OK]**をクリックするとパスワードが保存されます。 ![MySQL Workbench: store the password of TiDB Cloud Dedicated in keychain](/media/develop/mysql-workbench-store-dedicated-password-in-keychain.png) @@ -158,10 +158,10 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my 2. **「新しい接続の設定**」ダイアログで、以下の接続パラメータを設定します。 - **接続名**：この接続に分かりやすい名前を付けてください。 - - **ホスト名**：TiDBセルフマネージドクラスタのIPアドレスまたはドメイン名を入力してください。 - - **ポート**：TiDBセルフマネージドクラスタのポート番号を入力してください。 + - **ホスト名**：TiDB Self-ManagedクラスターのIPアドレスまたはドメイン名を入力してください。 + - **ポート**：TiDB Self-Managedクラスターのポート番号を入力してください。 - **ユーザー名**：TiDBに接続するために使用するユーザー名を入力してください。 - - **パスワード**： **[キーチェーンに保存...]**をクリックし、TiDBセルフマネージドクラスタへの接続に使用するパスワードを入力して、 **[OK]**をクリックしてパスワードを保存します。 + - **パスワード**： **[キーチェーンに保存...]**をクリックし、TiDB Self-Managedクラスターへの接続に使用するパスワードを入力して、 **[OK]**をクリックしてパスワードを保存します。 ![MySQL Workbench: store the password of TiDB Self-Managed in keychain](/media/develop/mysql-workbench-store-self-hosted-password-in-keychain.png) @@ -169,7 +169,7 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my ![MySQL Workbench: configure connection settings for TiDB Self-Managed](/media/develop/mysql-workbench-connection-config-self-hosted-parameters.png) -3. **「接続テスト」**をクリックして、TiDBセルフマネージドクラスタへの接続を検証してください。 +3. **「接続テスト」**をクリックして、TiDB Self-Managedクラスターへの接続を検証してください。 4. 接続テストが成功すると、 **「MySQL接続が正常に確立されました」という**メッセージが表示されます。 **「OK」**をクリックして接続設定を保存してください。 @@ -192,7 +192,7 @@ TiDBはMySQL互換データベースであり、 [MySQL Workchen](https://www.my ## 次のステップ {#next-steps} - MySQL Workbench の使用法の詳細については[MySQL Workbenchのドキュメント](https://dev.mysql.com/doc/workbench/en/)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-gui-navicat.md b/develop/dev-guide-gui-navicat.md index 5f043c7b492ed..e26c0219eaaaf 100644 --- a/develop/dev-guide-gui-navicat.md +++ b/develop/dev-guide-gui-navicat.md @@ -20,12 +20,12 @@ TiDBはMySQL互換データベースであり、[ナビキャット](https://www - [Navicat Premium](https://www.navicat.com) **17.1.6**以降のバージョン。 - Navicat Premiumの有料アカウント。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続する {#connect-to-tidb} @@ -114,7 +114,7 @@ TiDBはMySQL互換データベースであり、[ナビキャット](https://www
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -122,7 +122,7 @@ TiDBはMySQL互換データベースであり、[ナビキャット](https://www IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. **CA証明書をダウンロードするには、「CA証明書**」をクリックしてください。 @@ -136,7 +136,7 @@ TiDBはMySQL互換データベースであり、[ナビキャット](https://www - **ホスト**: TiDB Cloud接続ダイアログから`HOST`パラメータを入力します。 - **ポート**: TiDB Cloud接続ダイアログから`PORT`パラメータを入力します。 - **ユーザー名**： TiDB Cloud接続ダイアログから`USERNAME`パラメータを入力してください。 - - **パスワード**： TiDB Cloud Dedicatedクラスタのパスワードを入力してください。 + - **パスワード**： TiDB Cloud Dedicatedクラスターのパスワードを入力してください。 ![Navicat: configure connection general panel for TiDB Cloud Dedicated](/media/develop/navicat-premium-connection-config-dedicated-general.png) @@ -158,14 +158,14 @@ TiDBはMySQL互換データベースであり、[ナビキャット](https://www 2. 「**新規接続（TiDB）」**ダイアログで、以下の接続パラメータを設定します。 - **接続名**：この接続に分かりやすい名前を付けてください。 - - **ホスト**：TiDBセルフマネージドクラスタのIPアドレスまたはドメイン名を入力してください。 - - **ポート**：TiDBセルフマネージドクラスタのポート番号を入力してください。 + - **ホスト**：TiDB Self-ManagedクラスターのIPアドレスまたはドメイン名を入力してください。 + - **ポート**：TiDB Self-Managedクラスターのポート番号を入力してください。 - **ユーザー名**：TiDBに接続するために使用するユーザー名を入力してください。 - **パスワード**：TiDBに接続するために使用するパスワードを入力してください。 ![Navicat: configure connection general panel for self-hosted TiDB](/media/develop/navicat-premium-connection-config-self-hosted-general.png) -3. **「接続テスト」**をクリックして、TiDBセルフマネージドクラスタへの接続を検証してください。 +3. **「接続テスト」**をクリックして、TiDB Self-Managedクラスターへの接続を検証してください。 4. 接続テストが成功すると、 **「接続成功」という**メッセージが表示されます。 **「OK」**をクリックして接続設定を完了してください。 @@ -174,7 +174,7 @@ TiDBはMySQL互換データベースであり、[ナビキャット](https://www ## 次のステップ {#next-steps} -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-gui-vscode-sqltools.md b/develop/dev-guide-gui-vscode-sqltools.md index bf14331d63d35..630c67092b588 100644 --- a/develop/dev-guide-gui-vscode-sqltools.md +++ b/develop/dev-guide-gui-vscode-sqltools.md @@ -24,12 +24,12 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code - このリンクをクリックするとVS Codeが起動し、拡張機能を直接インストールできます。 - [VS Code マーケットプレイス](https://marketplace.visualstudio.com/items?itemName=mtxr.sqltools-driver-mysql)に移動し、 **[インストール]**をクリックします。 - VS Code の**[拡張機能]**タブで`mtxr.sqltools-driver-mysql`を検索して**SQLTools MySQL/MariaDB/TiDB**拡張機能を取得し、 **[インストール] を**クリックします。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続する {#connect-to-tidb} @@ -142,7 +142,7 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -150,7 +150,7 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. VS Codeを起動し、ナビゲーションペインで**SQLTools**拡張機能を選択します。 **[接続]**セクションで**[新しい接続を追加]**をクリックし、データベースドライバとして**TiDB**を選択します。 @@ -176,7 +176,7 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code 6. **「接続テスト」**をクリックして、 TiDB Cloud Dedicatedクラスターへの接続を検証してください。 1. ポップアップウィンドウで**「許可」**をクリックします。 - 2. **SQLToolsDriver認証情報**ダイアログで、 TiDB Cloud Dedicatedクラスタのパスワードを入力します。 + 2. **SQLToolsDriver認証情報**ダイアログで、 TiDB Cloud Dedicatedクラスターのパスワードを入力します。 ![VS Code SQLTools: enter password to connect to TiDB Cloud Dedicated](/media/develop/vsc-sqltools-password.jpg) @@ -197,13 +197,13 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code - **接続方法**：**サーバーとポート**を選択してください。 - - **サーバーアドレス**：TiDBセルフマネージドクラスタのIPアドレスまたはドメイン名を入力してください。 + - **サーバーアドレス**：TiDB Self-ManagedクラスターのIPアドレスまたはドメイン名を入力してください。 - - **ポート**：TiDBセルフマネージドクラスタのポート番号を入力してください。 + - **ポート**：TiDB Self-Managedクラスターのポート番号を入力してください。 - **データベース**：接続したいデータベースを入力してください。 - - **ユーザー名**：TiDBセルフマネージドクラスタに接続するために使用するユーザー名を入力してください。 + - **ユーザー名**：TiDB Self-Managedクラスターに接続するために使用するユーザー名を入力してください。 - **パスワードモード**： @@ -217,9 +217,9 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code ![VS Code SQLTools: configure connection settings for TiDB Self-Managed](/media/develop/vsc-sqltools-connection-config-self-hosted.jpg) -3. **「接続テスト」**をクリックして、TiDBセルフマネージドクラスタへの接続を検証してください。 +3. **「接続テスト」**をクリックして、TiDB Self-Managedクラスターへの接続を検証してください。 - パスワードが空欄でない場合は、ポップアップウィンドウで**「許可」**をクリックし、TiDBセルフマネージドクラスタのパスワードを入力してください。 + パスワードが空欄でない場合は、ポップアップウィンドウで**「許可」**をクリックし、TiDB Self-Managedクラスターのパスワードを入力してください。 ![VS Code SQLTools: enter password to connect to TiDB Self-Managed](/media/develop/vsc-sqltools-password.jpg) @@ -232,7 +232,7 @@ TiDB は MySQL 互換データベースであり、 [Visual Studio Code (VS Code - Visual Studio Code の使用法の詳細については[Visual Studio Code のドキュメント](https://code.visualstudio.com/docs)参照してください。 - VS Code SQLTools 拡張機能の使用法について詳しくは、SQLTools の[ドキュメント](https://marketplace.visualstudio.com/items?itemName=mtxr.sqltools)および[GitHubリポジトリ](https://github.com/mtxr/vscode-sqltools)ご覧ください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-hybrid-oltp-and-olap-queries.md b/develop/dev-guide-hybrid-oltp-and-olap-queries.md index 615b85ef6d9ff..2368b8cb8a91b 100644 --- a/develop/dev-guide-hybrid-oltp-and-olap-queries.md +++ b/develop/dev-guide-hybrid-oltp-and-olap-queries.md @@ -8,7 +8,7 @@ aliases: ['/ja/tidb/stable/dev-guide-hybrid-oltp-and-olap-queries/','/ja/tidbclo HTAPは、Hybrid Transactional and Analytical Processing（ハイブリッド・トランザクション・アンド・アナリティカル・プロセッシング）の略です。従来、データベースはトランザクション処理または分析シナリオ向けに設計されることが多く、データプラットフォームはトランザクション処理と分析処理に分割する必要があり、分析クエリへの迅速な応答のために、トランザクションデータベースから分析データベースにデータを複製する必要がありました。TiDBデータベースはトランザクションと分析の両方のタスクを実行できるため、データプラットフォームの構築が大幅に簡素化され、ユーザーはより新鮮なデータを分析に使用できるようになります。 -TiDBは、オンライントランザクション処理（OLTP）には行ベースのstorageエンジンであるTiKVを使用し、オンライン分析処理（OLAP）には列指向storageエンジンであるTiFlashを使用します。HTAPでは、行ベースのstorageエンジンと列指向storageエンジンが共存します。どちらのstorageエンジンも、データを自動的に複製し、強力な一貫性を維持できます。行ベースのstorageエンジンはOLTPのパフォーマンスを最適化し、列指向storageエンジンはOLAPのパフォーマンスを最適化します。 +TiDBは、オンライントランザクション処理（OLTP）には行ベースのストレージエンジンであるTiKVを使用し、オンライン分析処理（OLAP）には列指向ストレージエンジンであるTiFlashを使用します。HTAPでは、行ベースのストレージエンジンと列指向ストレージエンジンが共存します。どちらのストレージエンジンも、データを自動的に複製し、強力な一貫性を維持できます。行ベースのストレージエンジンはOLTPのパフォーマンスを最適化し、列指向ストレージエンジンはOLAPのパフォーマンスを最適化します。 セクション[テーブルを作成する](/develop/dev-guide-create-table.md#use-htap-capabilities)では、TiDBのHTAP機能を有効にする方法を紹介します。以下では、HTAPを使用してデータをより高速に分析する方法について説明します。 @@ -143,7 +143,7 @@ TiDB は、より多くの分析ステートメントのために、集約され ### TiFlashレプリカを作成する {#create-tiflash-replicas} -TiDB はデフォルトで行ベースのstorageエンジン TiKV を使用します。列指向storageエンジンTiFlashを使用するには、 [HTAP機能を有効にする](/develop/dev-guide-create-table.md#use-htap-capabilities)参照してください。TiFlashを介してデータをクエリする前に、次のステートメントを使用して`books`および`orders`テーブルのTiFlashレプリカを作成する必要があります。 +TiDB はデフォルトで行ベースのストレージエンジン TiKV を使用します。列指向ストレージエンジンTiFlashを使用するには、 [HTAP機能を有効にする](/develop/dev-guide-create-table.md#use-htap-capabilities)参照してください。TiFlashを介してデータをクエリする前に、次のステートメントを使用して`books`および`orders`テーブルのTiFlashレプリカを作成する必要があります。 ```sql ALTER TABLE books SET TIFLASH REPLICA 1; @@ -204,17 +204,17 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'bookshop' TiDBはコストベースオプティマイザー（CBO）を使用して、コスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に選択します。ただし、クエリがトランザクションクエリか分析クエリかが明確な場合は、 [オプティマイザヒント](/optimizer-hints.md)を使用して使用するクエリエンジンを指定できます。 -クエリで使用するエンジンを指定するには、次のステートメントのように`/*+ read_from_storage(engine_name[table_name]) */`ヒントを使用できます。 +クエリで使用するエンジンを指定するには、次のステートメントのように`/*+ read_from_ストレージ(engine_name[table_name]) */`ヒントを使用できます。 > **注記：** > > - テーブルに別名がある場合は、ヒントでテーブル名の代わりに別名を使用します。そうしないと、ヒントは機能しません。 -> - `read_from_storage`ヒントは[共通テーブル式](/develop/dev-guide-use-common-table-expression.md)には機能しません。 +> - `read_from_ストレージ`ヒントは[共通テーブル式](/develop/dev-guide-use-common-table-expression.md)には機能しません。 ```sql WITH orders_group_by_month AS ( SELECT - /*+ read_from_storage(tikv[o]) */ + /*+ read_from_ストレージ(tikv[o]) */ b.type AS book_type, DATE_FORMAT(ordered_at, '%Y-%c') AS month, COUNT(*) AS orders @@ -233,14 +233,14 @@ WITH orders_group_by_month AS ( SELECT * FROM acc; ``` -`EXPLAIN`ステートメントを使用して、上記のSQL文の実行プランを確認できます。タスク列に`cop[tiflash]`と`cop[tikv]`同時に表示される場合、 TiFlashと TiKV の両方がこのクエリを完了するようにスケジュールされていることを意味します。TiFlash と TiKV のstorageエンジンは通常、異なる TiDB ノードを使用するため、2 つのクエリタイプは互いに影響を受けません。 +`EXPLAIN`ステートメントを使用して、上記のSQL文の実行プランを確認できます。タスク列に`cop[tiflash]`と`cop[tikv]`同時に表示される場合、 TiFlashと TiKV の両方がこのクエリを完了するようにスケジュールされていることを意味します。TiFlash と TiKV のストレージエンジンは通常、異なる TiDB ノードを使用するため、2 つのクエリタイプは互いに影響を受けません。 TiDBがTiFlashをどのように使用するかの詳細については、 [TiDBを使用してTiFlashレプリカを読み取る](/tiflash/use-tidb-to-read-tiflash.md)参照してください。 ## 続きを読む {#read-more} - [TiDB Cloudの HTAP クイックスタート](/tidb-cloud/tidb-cloud-htap-quickstart.md) -- [TiDBセルフマネージド向けHTAPクイックスタート](/quick-start-with-htap.md)と[TiDBセルフマネージドのHTAPを探索する](/explore-htap.md) +- [TiDB Self-Managed向けHTAPクイックスタート](/quick-start-with-htap.md)と[HTAP入門](/explore-htap.md) - [ウィンドウ関数](/functions-and-operators/window-functions.md) - [TiFlashを使用する](/tiflash/tiflash-overview.md#use-tiflash) @@ -248,4 +248,4 @@ TiDBがTiFlashをどのように使用するかの詳細については、 [TiDB - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-implicit-type-conversion.md b/develop/dev-guide-implicit-type-conversion.md index 299d7a9fde565..b2cb8896b2806 100644 --- a/develop/dev-guide-implicit-type-conversion.md +++ b/develop/dev-guide-implicit-type-conversion.md @@ -82,4 +82,4 @@ SELECT * FROM `t1` WHERE `a` BETWEEN '12123123' AND '1111222211111111200000'; - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-index-best-practice.md b/develop/dev-guide-index-best-practice.md index e15ba4bebcaea..e2b9daad1d989 100644 --- a/develop/dev-guide-index-best-practice.md +++ b/develop/dev-guide-index-best-practice.md @@ -135,4 +135,4 @@ CREATE TABLE `books` ( - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-insert-data.md b/develop/dev-guide-insert-data.md index 67fbafaac03ef..1b964a1ce0867 100644 --- a/develop/dev-guide-insert-data.md +++ b/develop/dev-guide-insert-data.md @@ -79,7 +79,7 @@ try (Connection connection = ds.getConnection()) { MySQL JDBCDriverのデフォルト設定では、一括挿入のパフォーマンスを向上させるために、いくつかのパラメータを変更する必要があります。 -| パラメータ | 手段 | 推奨シナリオ | 推奨コンフィグレーション | +| パラメータ | 手段 | 推奨シナリオ | 推奨設定 | | :------------------------: | :------------------------------: | :-----------------------------------------------------------------------------------------------------------------------------------------: | :---------------------------: | | `useServerPrepStmts` | サーバー側を使用してプリペアドステートメントを有効にするかどうか | プリペアドステートメントを複数回使用する必要がある場合 | `true` | | `cachePrepStmts` | クライアントが準備済みステートメントをキャッシュするかどうか | `useServerPrepStmts=true` | `true` | @@ -232,8 +232,8 @@ TiDBに大量のデータを迅速にインポートする必要がある場合
-- データエクスポート： [Dumpling](/dumpling-overview.md)を使用して、MySQLまたはTiDBデータをローカルストレージまたはクラウドstorageにエクスポートします。TiDB Cloud StarterまたはEssentialインスタンスの場合は、 [TiDB Cloudコンソール](https://tidbcloud.com/)の[輸出](/tidb-cloud/serverless-export.md)機能を使用して、より効率的にデータをエクスポートすることもできます。 -- データのインポート: [TiDB Cloudコンソール](https://tidbcloud.com/)の[輸入](/tidb-cloud/import-sample-data.md)機能を使用します。 Dumplingでエクスポートしたデータをインポートしたり、ローカルの CSV ファイルをインポートしたり、[クラウドstorageからCSVファイルをTiDB Cloudにインポートする](/tidb-cloud/import-csv-files.md)ことができます。 +- データエクスポート： [Dumpling](/dumpling-overview.md)を使用して、MySQLまたはTiDBデータをローカルストレージまたはクラウドストレージにエクスポートします。TiDB Cloud StarterまたはEssentialインスタンスの場合は、 [TiDB Cloudコンソール](https://tidbcloud.com/)の[輸出](/tidb-cloud/serverless-export.md)機能を使用して、より効率的にデータをエクスポートすることもできます。 +- データのインポート: [TiDB Cloudコンソール](https://tidbcloud.com/)の[輸入](/tidb-cloud/import-sample-data.md)機能を使用します。 Dumplingでエクスポートしたデータをインポートしたり、ローカルの CSV ファイルをインポートしたり、[クラウドストレージからCSVファイルをTiDB Cloudにインポートする](/tidb-cloud/import-csv-files.md)ことができます。 - データレプリケーション： [TiDB Cloudコンソール](https://tidbcloud.com/)の[TiDBデータ移行](/tidb-cloud/migrate-from-mysql-using-data-migration.md)機能を使用します。 MySQL 互換データベースを TiDB にレプリケートできます。また、ソースデータベースからのシャーディングされたインスタンスとテーブルのマージおよび移行もサポートしています。 - データのバックアップと復元: [TiDB Cloudコンソール](https://tidbcloud.com/)の[バックアップ](/tidb-cloud/backup-and-restore.md)機能を使用します。 Dumplingと比較して、バックアップと復元はビッグ データのシナリオにより適しています。 @@ -252,7 +252,7 @@ TiDBに大量のデータを迅速にインポートする必要がある場合 テーブルを設計するときは、多数の挿入操作があるかどうかを考慮する必要があります。その場合、テーブルの設計中にホットスポットを回避する必要があります。 [主キーを選択](/develop/dev-guide-create-table.md#select-primary-key)セクションを参照し、 [主キーを選択する際のルール](/develop/dev-guide-create-table.md#guidelines-to-follow-when-selecting-primary-key)に従ってください。 -TiDB セルフマネージドでホットスポットの問題を処理する方法の詳細については、[ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md)。 +TiDB Self-Managedでホットスポットの問題を処理する方法の詳細については、[ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md)。 ## AUTO_RANDOMを主キーとするテーブルにデータを挿入する {#insert-data-to-a-table-with-the-code-auto-random-code-primary-key} diff --git a/develop/dev-guide-join-tables.md b/develop/dev-guide-join-tables.md index de3d70a7ddf38..417b6cbd40bdc 100644 --- a/develop/dev-guide-join-tables.md +++ b/develop/dev-guide-join-tables.md @@ -253,4 +253,4 @@ WHERE b.id = ba.book_id AND ba.author_id = a.id; - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-mysql-tools.md b/develop/dev-guide-mysql-tools.md index 2c2c502f1725b..81ef1ebb062da 100644 --- a/develop/dev-guide-mysql-tools.md +++ b/develop/dev-guide-mysql-tools.md @@ -61,4 +61,4 @@ mysqlsh --sql mysql://root@:4000 - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-object-naming-guidelines.md b/develop/dev-guide-object-naming-guidelines.md index 91a285a6a14b6..7a7b56fee0924 100644 --- a/develop/dev-guide-object-naming-guidelines.md +++ b/develop/dev-guide-object-naming-guidelines.md @@ -50,4 +50,4 @@ aliases: ['/ja/tidb/stable/dev-guide-object-naming-guidelines/','/ja/tidbcloud/d - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-optimistic-and-pessimistic-transaction.md b/develop/dev-guide-optimistic-and-pessimistic-transaction.md index b12c53d273a49..5a31f3aaaaefa 100644 --- a/develop/dev-guide-optimistic-and-pessimistic-transaction.md +++ b/develop/dev-guide-optimistic-and-pessimistic-transaction.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-optimistic-and-pessimistic-transaction/','/ # 楽観的なトランザクションと悲観的なトランザクション {#optimistic-transactions-and-pessimistic-transactions} -[楽観的取引](/optimistic-transaction.md)モデルではトランザクションを直接コミットし、競合が発生した場合はロールバックします。一方、 [悲観的取引](/pessimistic-transaction.md)モデルでは、トランザクションを実際にコミットする前に、変更が必要なリソースをロックしようとし、トランザクションが正常に実行できることが確認できた場合にのみコミットを開始します。 +[楽観的トランザクション](/optimistic-transaction.md)モデルではトランザクションを直接コミットし、競合が発生した場合はロールバックします。一方、 [悲観的トランザクション](/pessimistic-transaction.md)モデルでは、トランザクションを実際にコミットする前に、変更が必要なリソースをロックしようとし、トランザクションが正常に実行できることが確認できた場合にのみコミットを開始します。 楽観的トランザクションモデルは、直接コミットの成功確率が高いため、競合率が低いシナリオに適しています。しかし、トランザクションの競合が発生すると、ロールバックのコストが比較的高くなります。 @@ -14,7 +14,7 @@ aliases: ['/ja/tidb/stable/dev-guide-optimistic-and-pessimistic-transaction/','/ 悲観的トランザクションモデルはより直感的で、アプリケーション側での実装が容易です。一方、楽観的トランザクションモデルでは、アプリケーション側で複雑な再試行メカニズムが必要になります。 -以下は[書店](/develop/dev-guide-bookshop-schema-design.md)の例です。本の購入を例に挙げ、楽観的取引と悲観的取引の長所と短所を示しています。本の購入プロセスは主に以下の流れで構成されます。 +以下は[書店](/develop/dev-guide-bookshop-schema-design.md)の例です。本の購入を例に挙げ、楽観的トランザクションと悲観的トランザクションの長所と短所を示しています。本の購入プロセスは主に以下の流れで構成されます。 1. 在庫数量を更新する 2. 注文を作成する @@ -22,7 +22,7 @@ aliases: ['/ja/tidb/stable/dev-guide-optimistic-and-pessimistic-transaction/','/ これらの操作はすべて成功するか、すべて失敗するかのいずれかになります。同時トランザクションが発生した場合、過剰販売が発生しないようにする必要があります。 -## 悲観的な取引 {#pessimistic-transactions} +## 悲観的なトランザクション {#pessimistic-transactions} 以下のコードは、2つのスレッドを使用して、2人のユーザーが同じ本を悲観的トランザクションモードで購入するプロセスをシミュレートします。書店には10冊の本が残っています。ボブは6冊、アリスは4冊を購入します。2人はほぼ同時に注文を完了します。その結果、在庫にあるすべての本が売り切れます。 @@ -100,13 +100,13 @@ func (tx *TiDBSqlTx) Rollback() error { -### 悲観的取引の例を書く {#write-a-pessimistic-transaction-example} +### 悲観的トランザクションの例を書く {#write-a-pessimistic-transaction-example}
-**コンフィグレーションファイル** +**設定ファイル** Mavenを使用してパッケージを管理する場合は、 `pom.xml`の``ノードに以下の依存関係を追加して`HikariCP`インポートし、パッケージ化ターゲットとJARパッケージのメインクラスを起動するように設定します。以下は`pom.xml`の例です。 @@ -997,7 +997,7 @@ mysql> SELECT * FROM users; 2 rows in set (0.01 sec) ``` -## 楽観的な取引 {#optimistic-transactions} +## 楽観的なトランザクション {#optimistic-transactions} 以下のコードは、2つのスレッドを使用して、悲観的トランザクションの例と同様に、2人のユーザーが楽観的トランザクションで同じ本を購入するプロセスをシミュレートします。在庫には10冊の本が残っています。ボブは6冊、アリスは4冊購入します。2人はほぼ同時に注文を完了します。最終的に、在庫には本が残っていません。 @@ -1165,7 +1165,7 @@ public class TxnExample { } ``` -**コンフィグレーションの変更** +**設定の変更** `pom.xml`の起動クラスを変更します。 @@ -1183,13 +1183,13 @@ public class TxnExample {
-セクション[悲観的取引の例を書く](#write-a-pessimistic-transaction-example)のGolang の例では、すでに楽観的トランザクションがサポートされており、変更せずに直接使用できます。 +セクション[悲観的トランザクションの例を書く](#write-a-pessimistic-transaction-example)のGolang の例では、すでに楽観的トランザクションがサポートされており、変更せずに直接使用できます。
-セクション[悲観的取引の例を書く](#write-a-pessimistic-transaction-example)の Python の例では、すでに楽観的トランザクションがサポートされており、変更せずに直接使用できます。 +セクション[悲観的トランザクションの例を書く](#write-a-pessimistic-transaction-example)の Python の例では、すでに楽観的トランザクションがサポートされており、変更せずに直接使用できます。
@@ -1372,4 +1372,4 @@ mysql> SELECT * FROM users; - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-optimize-sql-best-practices.md b/develop/dev-guide-optimize-sql-best-practices.md index 70c7df46ee087..2725069770b46 100644 --- a/develop/dev-guide-optimize-sql-best-practices.md +++ b/develop/dev-guide-optimize-sql-best-practices.md @@ -166,4 +166,4 @@ SET @@global.tidb_ddl_reorg_batch_size = 128; - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-optimize-sql-overview.md b/develop/dev-guide-optimize-sql-overview.md index 812fcb75921c2..01413c570a194 100644 --- a/develop/dev-guide-optimize-sql-overview.md +++ b/develop/dev-guide-optimize-sql-overview.md @@ -18,7 +18,7 @@ aliases: ['/ja/tidb/stable/dev-guide-optimize-sql-overview/','/ja/tidbcloud/dev- - スキャンする行数はできるだけ少なくしてください。必要なデータのみをスキャンし、余分なデータのスキャンは避けることをお勧めします。 - 適切なインデックスを使用してください。SQLの`WHERE`節の列に対応するインデックスがあることを確認してください。インデックスがない場合、文はフルテーブルスキャンを必要とし、パフォーマンスが低下します。 - 適切な結合タイプを使用してください。クエリに含まれるテーブルの相対的なサイズに基づいて、適切な結合タイプを選択することが重要です。通常、TiDBのコストベースオプティマイザは、パフォーマンスが最も高い結合タイプを選択します。ただし、場合によっては、より適切な結合タイプを手動で指定する必要があることもあります。 -- 適切なstorageエンジンを使用してください。OLTPとOLAPのハイブリッドワークロードには、 TiFlashエンジンが推奨されます。詳細については、 [HTAPクエリ](/develop/dev-guide-hybrid-oltp-and-olap-queries.md)参照してください。 +- 適切なストレージエンジンを使用してください。OLTPとOLAPのハイブリッドワークロードには、 TiFlashエンジンが推奨されます。詳細については、 [HTAPクエリ](/develop/dev-guide-hybrid-oltp-and-olap-queries.md)参照してください。 ## スキーマ設計 {#schema-design} @@ -30,10 +30,10 @@ aliases: ['/ja/tidb/stable/dev-guide-optimize-sql-overview/','/ja/tidbcloud/dev- ### 参照 {#see-also} - [TiDB Cloudの SQL性能チューニング](/tidb-cloud/tidb-cloud-sql-tuning-overview.md) -- [TiDBセルフマネージドのSQL性能チューニング](/sql-tuning-overview.md) +- [TiDB Self-ManagedのSQL性能チューニング](/sql-tuning-overview.md) ## ヘルプが必要ですか? {#need-help} - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-optimize-sql.md b/develop/dev-guide-optimize-sql.md index 6defe3235af42..60e4c64177e47 100644 --- a/develop/dev-guide-optimize-sql.md +++ b/develop/dev-guide-optimize-sql.md @@ -250,4 +250,4 @@ EXPLAIN SELECT * FROM books WHERE id = 896; - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-paginate-results.md b/develop/dev-guide-paginate-results.md index 12c9e61651651..d15c5c3623fd9 100644 --- a/develop/dev-guide-paginate-results.md +++ b/develop/dev-guide-paginate-results.md @@ -333,4 +333,4 @@ ORDER BY book_id, user_id; - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-playground-gitpod.md b/develop/dev-guide-playground-gitpod.md index ab013072fe21a..f9a9601f3df70 100644 --- a/develop/dev-guide-playground-gitpod.md +++ b/develop/dev-guide-playground-gitpod.md @@ -172,4 +172,4 @@ Gitpodは、完全かつ自動化された、事前設定済みのクラウド - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-prepared-statement.md b/develop/dev-guide-prepared-statement.md index b1990468710b3..2ab7340168f89 100644 --- a/develop/dev-guide-prepared-statement.md +++ b/develop/dev-guide-prepared-statement.md @@ -189,7 +189,7 @@ try (Connection connection = ds.getConnection()) { 次の構成は、JDBC で TiDB サーバー側の準備済みステートメントを使用するのに役立ちます。 -| パラメータ | 手段 | 推奨シナリオ | 推奨コンフィグレーション | +| パラメータ | 手段 | 推奨シナリオ | 推奨設定 | | :---------------------: | :--------------------------------: | :-------------------------: | :---------------------------: | | `useServerPrepStmts` | サーバー側を使用して準備済みステートメントを有効にするかどうか | プリペアドステートメントを複数回使用する必要がある場合 | `true` | | `cachePrepStmts` | クライアントが準備されたステートメントをキャッシュするかどうか | `useServerPrepStmts=true` | `true` | @@ -216,4 +216,4 @@ Javaの完全な例については、以下を参照してください。 - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-proxysql-integration.md b/develop/dev-guide-proxysql-integration.md index cf4d7aa14e8fc..4c185b9774377 100644 --- a/develop/dev-guide-proxysql-integration.md +++ b/develop/dev-guide-proxysql-integration.md @@ -578,7 +578,7 @@ systemctl start docker -6. TiDBセルフマネージドクラスタに接続した後、次のSQLステートメントを使用して接続を検証できます。 +6. TiDB Self-Managedクラスターに接続した後、次のSQLステートメントを使用して接続を検証できます。 ```sql SELECT VERSION(); @@ -633,7 +633,7 @@ ProxySQLは様々なプラットフォームにインストールできます。 サポートされているプラ​​ットフォームと対応するバージョン要件の完全なリストについては、 [ProxySQLのドキュメント](https://proxysql.com/documentation/installing-proxysql/)参照してください。 -#### ステップ1. TiDB Cloud Dedicatedクラスタを作成する {#step-1-create-a-tidb-cloud-dedicated-cluster} +#### ステップ1. TiDB Cloud Dedicatedクラスターを作成する {#step-1-create-a-tidb-cloud-dedicated-cluster} 詳細な手順については、 [TiDB Cloud Dedicatedクラスターを作成する](https://docs.pingcap.com/tidbcloud/create-tidb-cluster)参照してください。 @@ -699,11 +699,11 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 > **注記：** > - > - `hostgroup_id` : ホストグループの ID を指定します。ProxySQL はホストグループを使用してクラスタを管理します。SQL トラフィックをこれらのクラスタに均等に分散するには、負荷分散が必要な複数のクラスタを同じホストグループに構成できます。読み取りと書き込みなどの目的でクラスタを区別するには、異なるホストグループを使用するように構成できます。 + > - `hostgroup_id` : ホストグループの ID を指定します。ProxySQL はホストグループを使用してクラスターを管理します。SQL トラフィックをこれらのクラスターに均等に分散するには、負荷分散が必要な複数のクラスターを同じホストグループに構成できます。読み取りと書き込みなどの目的でクラスターを区別するには、異なるホストグループを使用するように構成できます。 > - `hostname` : TiDB Cloud Dedicatedクラスターのエンドポイント。 > - `port` : TiDB Cloud Dedicatedクラスターのポート。 -3. プロキシログインユーザーを設定して、ユーザーがTiDB Cloud Dedicatedクラスタに対して適切な権限を持っていることを確認してください。以下のステートメントでは、「 *tidb cloud dedicated cluster username* 」と「 *tidb cloud dedicated cluster password* 」を、実際のTiDB Cloud Dedicatedクラスタのユーザー名とパスワードに置き換えてください。 +3. プロキシログインユーザーを設定して、ユーザーがTiDB Cloud Dedicatedクラスターに対して適切な権限を持っていることを確認してください。以下のステートメントでは、「 *tidb cloud dedicated cluster username* 」と「 *tidb cloud dedicated cluster password* 」を、実際のTiDB Cloud Dedicatedクラスターのユーザー名とパスワードに置き換えてください。 ```sql INSERT INTO mysql_users( @@ -890,7 +890,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 全てが順調に進めば、以下のコンテナが起動されます。 - - ポート`4001`および`4002`を介して公開される TiDB クラスタの 2 つの Docker コンテナ + - ポート`4001`および`4002`を介して公開される TiDB クラスターの 2 つの Docker コンテナ - ポート`6034`を介して公開される ProxySQL Docker コンテナが 1 つあります。 4. 2 つの TiDB コンテナでは、 `mysql`を使用して同様のスキーマ定義を持つテーブルを作成し、次に異なるデータ ( `'tidb-server01-port-4001'` 、 `'tidb-server02-port-4002'` ) を挿入してこれらのコンテナを識別します。 @@ -987,10 +987,10 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 > > `proxysql-prepare.sql`は以下のことを行います。 > - > - `hostgroup_id`を持つ TiDB クラスタを`0`および`1`として ProxySQL に追加します。 + > - `hostgroup_id`を持つ TiDB クラスターを`0`および`1`として ProxySQL に追加します。 > - 空のパスワードを持つユーザー`root`を追加し、 `default_hostgroup`を`0`に設定します。 - > - `^SELECT.*FOR UPDATE$`ルールを追加し、 `rule_id`を`1`として、 `destination_hostgroup`を`0`として追加します。SQL ステートメントがこのルールに一致する場合、リクエストは`hostgroup`を`0`として TiDB クラスタに転送されます。 - > - `^SELECT`ルールを追加し、 `rule_id`を`2`として、 `destination_hostgroup`を`1`として追加します。SQL ステートメントがこのルールに一致する場合、リクエストは`hostgroup`を`1`として TiDB クラスタに転送されます。 + > - `^SELECT.*FOR UPDATE$`ルールを追加し、 `rule_id`を`1`として、 `destination_hostgroup`を`0`として追加します。SQL ステートメントがこのルールに一致する場合、リクエストは`hostgroup`を`0`として TiDB クラスターに転送されます。 + > - `^SELECT`ルールを追加し、 `rule_id`を`2`として、 `destination_hostgroup`を`1`として追加します。SQL ステートメントがこのルールに一致する場合、リクエストは`hostgroup`を`1`として TiDB クラスターに転送されます。 > > より深く理解するには、 `proxysql-prepare.sql`ファイルを確認することを強くお勧めします。 ProxySQL 構成の詳細については、 [ProxySQLのドキュメント](https://proxysql.com/documentation/proxysql-configuration/)参照してください。 @@ -1043,7 +1043,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 SELECT * FROM test.tidb_server; ``` - このステートメントは、ルールID `2`に一致し、ステートメントを`hostgroup 1`上の TiDB クラスタに転送します。 + このステートメントは、ルールID `2`に一致し、ステートメントを`hostgroup 1`上の TiDB クラスターに転送します。 - `SELECT ... FOR UPDATE`ステートメントを実行します。 @@ -1051,9 +1051,9 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 SELECT * FROM test.tidb_server FOR UPDATE; ``` - このステートメントは、ルールID `1`に一致し、ステートメントを`hostgroup 0`上の TiDB クラスタに転送します。 + このステートメントは、ルールID `1`に一致し、ステートメントを`hostgroup 0`上の TiDB クラスターに転送します。 - - 取引を開始する: + - トランザクションを開始する: ```sql BEGIN; @@ -1062,7 +1062,7 @@ ProxySQL を TiDB のプロキシとして使用するには、ProxySQL を構 ROLLBACK; ``` - このトランザクションでは、 `BEGIN`ステートメントはどのルールにも一致しません。デフォルトのホストグループ (この例では`hostgroup 0`が使用されます。ProxySQL はデフォルトでユーザー transaction_persistent を有効にしており、同じホストグループ内で同じトランザクション内のすべてのステートメントを実行するため、 `INSERT`および`SELECT * FROM test.tidb_server;`ステートメントも TiDB クラスタ`hostgroup 0`に転送されます。 + このトランザクションでは、 `BEGIN`ステートメントはどのルールにも一致しません。デフォルトのホストグループ (この例では`hostgroup 0`が使用されます。ProxySQL はデフォルトでユーザー transaction_persistent を有効にしており、同じホストグループ内で同じトランザクション内のすべてのステートメントを実行するため、 `INSERT`および`SELECT * FROM test.tidb_server;`ステートメントも TiDB クラスター`hostgroup 0`に転送されます。 以下は出力例です。同様の出力が得られれば、ProxySQLによるクエリルールの設定は正常に完了しています。 diff --git a/develop/dev-guide-sample-application-aws-lambda.md b/develop/dev-guide-sample-application-aws-lambda.md index 77064da69a8c4..d88022fa2a76c 100644 --- a/develop/dev-guide-sample-application-aws-lambda.md +++ b/develop/dev-guide-sample-application-aws-lambda.md @@ -25,15 +25,15 @@ TiDBはMySQL互換データベース、 [AWS Lambda関数](https://aws.amazon.co - [Node.js **18**](https://nodejs.org/en/download/)以降。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 - 管理者権限を持つ[AWSユーザー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)。 - [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) - [AWS SAM CLI](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/install-sam-cli.html) -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) AWSアカウントまたはユーザーをお持ちでない場合は、 [Lambda入門](https://docs.aws.amazon.com/lambda/latest/dg/getting-started.html)ガイドの手順に従って作成できます。 @@ -285,7 +285,7 @@ AWS Lambda関数は、 [SAM CLI](#sam-cli-deployment-recommended)または[AWS L 5. Lambda 関数で[対応する接続​​文字列をコピーして設定します。](https://docs.aws.amazon.com/lambda/latest/dg/configuration-envvars.html) - 1. Lambda コンソールの[機能](https://console.aws.amazon.com/lambda/home#/functions)ページで、 **[コンフィグレーション]**タブを選択し、 **[環境変数]**を選択します。 + 1. Lambda コンソールの[機能](https://console.aws.amazon.com/lambda/home#/functions)ページで、 **[設定]**タブを選択し、 **[環境変数]**を選択します。 2. **「編集」**を選択してください。 3. データベースへのアクセス資格情報を追加するには、以下の手順を実行してください。 - **「環境変数の追加」**を選択し、 **「キー」**に`TIDB_HOST`と入力し、 **「値」**にホスト名を入力します。 @@ -395,7 +395,7 @@ console.log(rsh.affectedRows); - AWS Lambda関数でTiDBを使用する方法の詳細については、 [TiDB-Lambda統合/aws-lambda-bookstoreデモ](https://github.com/pingcap/TiDB-Lambda-integration/blob/main/aws-lambda-bookstore/README.md)ご覧ください。また、AWS API Gatewayを使用して、アプリケーション用のRESTful APIを構築することもできます。 - `mysql2`の使用法について詳しくは、 [`mysql2`のドキュメント](https://sidorares.github.io/node-mysql2/docs/documentation)ご覧ください。 - AWS Lambda の使用方法の詳細については[AWS `Lambda`の開発者ガイド](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)ご覧ください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-golang-gorm.md b/develop/dev-guide-sample-application-golang-gorm.md index 048035712e321..131e3b5fb298c 100644 --- a/develop/dev-guide-sample-application-golang-gorm.md +++ b/develop/dev-guide-sample-application-golang-gorm.md @@ -24,12 +24,12 @@ TiDB は MySQL 互換データベースであり、[ゴーム](https://gorm.io/i - [行く](https://go.dev/)**1.20**以上。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -144,7 +144,7 @@ cd tidb-golang-gorm-quickstart
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -152,7 +152,7 @@ cd tidb-golang-gorm-quickstart IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -274,7 +274,7 @@ db.Delete(&Player{ID: "id"}) ## 次のステップ {#next-steps} - GORM の使用法の詳細については[GORMのドキュメント](https://gorm.io/docs/index.html)と[GORMのドキュメントにあるTiDBのセクション](https://gorm.io/docs/connecting_to_the_database.html#TiDB)ご覧ください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-golang-sql-driver.md b/develop/dev-guide-sample-application-golang-sql-driver.md index b55f9bac998ba..a77b6542ea034 100644 --- a/develop/dev-guide-sample-application-golang-sql-driver.md +++ b/develop/dev-guide-sample-application-golang-sql-driver.md @@ -24,12 +24,12 @@ TiDBはMySQL互換データベースであり、 [Go-MySQL-Driver](https://githu - [行く](https://go.dev/)**1.20**以上。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -144,7 +144,7 @@ cd tidb-golang-sql-driver-quickstart
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -152,7 +152,7 @@ cd tidb-golang-sql-driver-quickstart IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -324,7 +324,7 @@ Golangドライバはデータベースへの低レベルアクセスを提供 ## 次のステップ {#next-steps} - Go-MySQL-Driver の使用法の詳細については[Go-MySQL-Driverのドキュメント](https://github.com/go-sql-driver/mysql/blob/master/README.md)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)」、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」など[単一テーブルの読み取り](/develop/dev-guide-get-data-from-single-table.md)章を読んで、TiDB アプリケーション開発のベスト [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)」、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」など[単一テーブルの読み取り](/develop/dev-guide-get-data-from-single-table.md)章を読んで、TiDB アプリケーション開発のベスト [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-java-hibernate.md b/develop/dev-guide-sample-application-java-hibernate.md index 1a2889123ef56..7bb79e5829cfd 100644 --- a/develop/dev-guide-sample-application-java-hibernate.md +++ b/develop/dev-guide-sample-application-java-hibernate.md @@ -25,12 +25,12 @@ TiDBはMySQL互換データベースであり、[ハイバネイト](https://hib - **Java Development Kit (JDK) 17**以降が必要です。業務要件や個人のニーズに応じて、 [OpenJDK](https://openjdk.org/)または[Oracle JDK](https://www.oracle.com/hk/java/technologies/downloads/)を選択できます。 - [メイブン](https://maven.apache.org/install.html)**3.8**以上。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -145,7 +145,7 @@ cd tidb-java-hibernate-quickstart
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -153,7 +153,7 @@ cd tidb-java-hibernate-quickstart IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 @@ -330,7 +330,7 @@ SET GLOBAL tidb_enable_check_constraint=ON; ## 次のステップ {#next-steps} - Hibernate の使用法の詳細については[Hibernateのドキュメント](https://hibernate.org/orm/documentation)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 - Java開発者向けのコース「 [JavaからTiDBを操作する](https://eng.edu.pingcap.com/catalog/info/id:212)を通じて学習します。 diff --git a/develop/dev-guide-sample-application-java-jdbc.md b/develop/dev-guide-sample-application-java-jdbc.md index 03c47599159bd..55ae24a425c2a 100644 --- a/develop/dev-guide-sample-application-java-jdbc.md +++ b/develop/dev-guide-sample-application-java-jdbc.md @@ -26,12 +26,12 @@ TiDBはMySQL互換データベースであり、JDBC（Java Database Connectivit - **Java Development Kit (JDK) 17**以降が必要です。業務要件や個人のニーズに応じて、 [OpenJDK](https://openjdk.org/)または[Oracle JDK](https://www.oracle.com/hk/java/technologies/downloads/)を選択できます。 - [メイブン](https://maven.apache.org/install.html)**3.8**以上。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -148,7 +148,7 @@ cd tidb-java-jdbc-quickstart
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -156,7 +156,7 @@ cd tidb-java-jdbc-quickstart IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 @@ -344,7 +344,7 @@ TiDB v8.5.4以降、TiDBはMySQLの動作に準拠するようになりました ## 次のステップ {#next-steps} - MySQL Connector/J の使用法の詳細については[MySQL Connector/J のドキュメント](https://dev.mysql.com/doc/connector-j/en/)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 - Java開発者向けのコース「 [JavaからTiDBを操作する](https://eng.edu.pingcap.com/catalog/info/id:212)を通じて学習します。 diff --git a/develop/dev-guide-sample-application-java-mybatis.md b/develop/dev-guide-sample-application-java-mybatis.md index 224c837da9aa3..2f279798ee4b7 100644 --- a/develop/dev-guide-sample-application-java-mybatis.md +++ b/develop/dev-guide-sample-application-java-mybatis.md @@ -25,12 +25,12 @@ TiDBはMySQL互換のデータベースであり、 [MyBatis](https://mybatis.or - **Java Development Kit (JDK) 17**以降が必要です。業務要件や個人のニーズに応じて、 [OpenJDK](https://openjdk.org/)または[Oracle JDK](https://www.oracle.com/hk/java/technologies/downloads/)を選択できます。 - [メイブン](https://maven.apache.org/install.html)**3.8**以上。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -145,7 +145,7 @@ cd tidb-java-mybatis-quickstart
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -153,7 +153,7 @@ cd tidb-java-mybatis-quickstart IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 @@ -346,7 +346,7 @@ public SqlSessionFactory getSessionFactory() { ## 次のステップ {#next-steps} - MyBatis の使用法について詳しくは[MyBatisのドキュメント](http://www.mybatis.org/mybatis-3/)ご覧ください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 - Java開発者向けのコース「 [JavaからTiDBを操作する](https://eng.edu.pingcap.com/catalog/info/id:212)を通じて学習します。 diff --git a/develop/dev-guide-sample-application-java-spring-boot.md b/develop/dev-guide-sample-application-java-spring-boot.md index 799b1484a3a6d..10f6c376a490c 100644 --- a/develop/dev-guide-sample-application-java-spring-boot.md +++ b/develop/dev-guide-sample-application-java-spring-boot.md @@ -25,12 +25,12 @@ aliases: ['/ja/tidbcloud/dev-guide-sample-application-spring-boot','/ja/tidb/dev - **Java Development Kit (JDK) 17**以降が必要です。業務要件や個人のニーズに応じて、 [OpenJDK](https://openjdk.org/)または[Oracle JDK](https://www.oracle.com/hk/java/technologies/downloads/)を選択できます。 - [メイブン](https://maven.apache.org/install.html)**3.8**以上。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -145,7 +145,7 @@ cd tidb-java-springboot-jpa-quickstart
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -153,7 +153,7 @@ cd tidb-java-springboot-jpa-quickstart IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `env.sh.example`をコピーして`env.sh`に名前を変更するには、次のコマンドを実行します。 @@ -299,7 +299,7 @@ playerRepository.deleteById(id); - [Spring Data JPAのドキュメント](https://spring.io/projects/spring-data-jpa) - [Hibernateのドキュメント](https://hibernate.org/orm/documentation) -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 diff --git a/develop/dev-guide-sample-application-nextjs.md b/develop/dev-guide-sample-application-nextjs.md index 8d82ee7c0f51a..5aefc58096a15 100644 --- a/develop/dev-guide-sample-application-nextjs.md +++ b/develop/dev-guide-sample-application-nextjs.md @@ -24,12 +24,12 @@ TiDBはMySQL互換のデータベースであり、 [mysql2](https://github.com/ - [Node.js **18**](https://nodejs.org/en/download/)以降。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -322,7 +322,7 @@ console.log(rsh.affectedRows); - ORM と Next.js を使用して複雑なアプリケーションを構築する方法の詳細については、 [書店デモ](https://github.com/pingcap/tidb-prisma-vercel-demo)を参照してください。 - node-mysql2 ドライバーの使用方法の詳細については[node-mysql2 のドキュメント](https://sidorares.github.io/node-mysql2/docs/documentation)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-nodejs-mysql2.md b/develop/dev-guide-sample-application-nodejs-mysql2.md index a190717fba04b..95bb34b63f25b 100644 --- a/develop/dev-guide-sample-application-nodejs-mysql2.md +++ b/develop/dev-guide-sample-application-nodejs-mysql2.md @@ -24,12 +24,12 @@ TiDBはMySQL互換のデータベースであり、 [node-mysql2](https://github - お使いのコンピューターに[Node.js](https://nodejs.org/en) >= 16.xがインストールされていること。 - お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています。 -- TiDBクラスタが稼働中です。 +- TiDBクラスターが稼働中です。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -149,7 +149,7 @@ npm install mysql2 dotenv --save
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -157,7 +157,7 @@ npm install mysql2 dotenv --save IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -335,7 +335,7 @@ console.log(rsh.affectedRows); ## 次のステップ {#next-steps} - node-mysql2 ドライバーの使用方法の詳細については[node-mysql2 のドキュメント](https://github.com/sidorares/node-mysql2#readme)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-nodejs-mysqljs.md b/develop/dev-guide-sample-application-nodejs-mysqljs.md index 7fc0444ea82c1..5ca7c395c6dde 100644 --- a/develop/dev-guide-sample-application-nodejs-mysqljs.md +++ b/develop/dev-guide-sample-application-nodejs-mysqljs.md @@ -24,12 +24,12 @@ TiDBはMySQL互換データベースであり、 [mysql.js](https://github.com/m - お使いのコンピューターに[Node.js](https://nodejs.org/en) >= 16.xがインストールされていること。 - お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています。 -- TiDBクラスタが稼働中です。 +- TiDBクラスターが稼働中です。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -149,7 +149,7 @@ npm install mysql dotenv --save
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -157,7 +157,7 @@ npm install mysql dotenv --save IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -360,7 +360,7 @@ conn.query('DELETE FROM players WHERE id = ?;', [1], (err, ok) => { ## 次のステップ {#next-steps} - mysql.js ドライバーの使用方法の詳細については[mysql.jsのドキュメント](https://github.com/mysqljs/mysql#readme)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-nodejs-prisma.md b/develop/dev-guide-sample-application-nodejs-prisma.md index 08fde73c9fe8b..8e062b66b5b5b 100644 --- a/develop/dev-guide-sample-application-nodejs-prisma.md +++ b/develop/dev-guide-sample-application-nodejs-prisma.md @@ -24,12 +24,12 @@ TiDB は MySQL 互換データベースであり、[プリズマ](https://github - お使いのコンピューターに[Node.js](https://nodejs.org/en) >= 16.xがインストールされていること。 - お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています。 -- TiDBクラスタが稼働中です。 +- TiDBクラスターが稼働中です。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -157,7 +157,7 @@ npm install prisma typescript ts-node @types/node --save-dev
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -165,7 +165,7 @@ npm install prisma typescript ts-node @types/node --save-dev IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -400,7 +400,7 @@ await prisma.player.delete({ ## 次のステップ {#next-steps} - ORM フレームワーク Prisma ドライバーの使用方法の詳細については[Prismaのドキュメント](https://www.prisma.io/docs)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-nodejs-sequelize.md b/develop/dev-guide-sample-application-nodejs-sequelize.md index 6f54666508573..95bb26826e00f 100644 --- a/develop/dev-guide-sample-application-nodejs-sequelize.md +++ b/develop/dev-guide-sample-application-nodejs-sequelize.md @@ -24,12 +24,12 @@ TiDB は MySQL 互換データベースであり、[シークエライズ](https - [Node.js **18**](https://nodejs.org/en/download/)以降。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -153,7 +153,7 @@ npm install
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -161,7 +161,7 @@ npm install IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -353,7 +353,7 @@ logger.info(deletedNewPlayer?.toJSON()); ## 次のステップ {#next-steps} - ORM フレームワーク Sequelize ドライバーの使用法の詳細については[Sequelizeのドキュメント](https://sequelize.org/)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)」、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」など[単一テーブルの読み取り](/develop/dev-guide-get-data-from-single-table.md)章を読んで、TiDB アプリケーション開発のベスト [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)」、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」など[単一テーブルの読み取り](/develop/dev-guide-get-data-from-single-table.md)章を読んで、TiDB アプリケーション開発のベスト [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-nodejs-typeorm.md b/develop/dev-guide-sample-application-nodejs-typeorm.md index 1bf04394a01e0..cbc0c81de52e8 100644 --- a/develop/dev-guide-sample-application-nodejs-typeorm.md +++ b/develop/dev-guide-sample-application-nodejs-typeorm.md @@ -24,12 +24,12 @@ TiDBはMySQL互換のデータベースであり、 [TypeORM](https://github.com - お使いのコンピューターに[Node.js](https://nodejs.org/en) >= 16.xがインストールされていること。 - お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています。 -- TiDBクラスタが稼働中です。 +- TiDBクラスターが稼働中です。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -157,7 +157,7 @@ npm install @types/node ts-node typescript --save-dev
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -165,7 +165,7 @@ npm install @types/node ts-node typescript --save-dev IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -394,7 +394,7 @@ export class ActionLog { ## 次のステップ {#next-steps} - TypeORM の使用法の詳細については[TypeORMのドキュメント](https://typeorm.io/)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、 [クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読んで、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-python-django.md b/develop/dev-guide-sample-application-python-django.md index 5b9b44c08fa47..a5137474ed67c 100644 --- a/develop/dev-guide-sample-application-python-django.md +++ b/develop/dev-guide-sample-application-python-django.md @@ -24,12 +24,12 @@ TiDBはMySQL互換のデータベースであり、[ジャンゴ](https://www.dj - [Python 3.8以降](https://www.python.org/downloads/)。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -161,7 +161,7 @@ mysqlclient でインストールの問題が発生した場合は、 [mysqlclie
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -169,7 +169,7 @@ mysqlclient でインストールの問題が発生した場合は、 [mysqlclie IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -247,7 +247,7 @@ python manage.py migrate - 全プレイヤーをビュー。 - プレイヤーを更新する。 - プレイヤーを削除する。 - - 2人のプレイヤー間で商品を取引する。 + - 2人のプレイヤー間で商品をトランザクションを使用して移動する。 ## サンプルコードスニペット {#sample-code-snippets} @@ -360,7 +360,7 @@ Player.objects.filter(coins=100).delete() ## 次のステップ {#next-steps} - Django の使用法の詳細については[Djangoのドキュメント](https://www.djangoproject.com/)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-python-mysql-connector.md b/develop/dev-guide-sample-application-python-mysql-connector.md index ba119d2040626..704891505a23f 100644 --- a/develop/dev-guide-sample-application-python-mysql-connector.md +++ b/develop/dev-guide-sample-application-python-mysql-connector.md @@ -24,12 +24,12 @@ TiDB は MySQL 互換データベースであり、 [MySQLコネクタ/Python](h - [Python 3.8以降](https://www.python.org/downloads/)。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -149,7 +149,7 @@ pip install -r requirements.txt
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -157,7 +157,7 @@ pip install -r requirements.txt IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -311,7 +311,7 @@ Pythonドライバはデータベースへの低レベルアクセスを提供 ## 次のステップ {#next-steps} - mysql-connector-python の使用法の詳細については[MySQL Connector/Python のドキュメント](https://dev.mysql.com/doc/connector-python/en/)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-python-mysqlclient.md b/develop/dev-guide-sample-application-python-mysqlclient.md index dadca5ea99384..3aa8d2fcd0f02 100644 --- a/develop/dev-guide-sample-application-python-mysqlclient.md +++ b/develop/dev-guide-sample-application-python-mysqlclient.md @@ -24,12 +24,12 @@ TiDBはMySQL互換のデータベースであり、 [mysqlclient](https://github - [Python **3.10**以降](https://www.python.org/downloads/)。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -154,7 +154,7 @@ pip install -r requirements.txt
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -162,7 +162,7 @@ pip install -r requirements.txt IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -314,7 +314,7 @@ Pythonドライバはデータベースへの低レベルアクセスを提供 ## 次のステップ {#next-steps} - `mysqlclient`の使用法の詳細については[mysqlclient のドキュメント](https://mysqlclient.readthedocs.io/)ご覧ください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-python-peewee.md b/develop/dev-guide-sample-application-python-peewee.md index 49f52a7ee15f4..67f30e22fd0d9 100644 --- a/develop/dev-guide-sample-application-python-peewee.md +++ b/develop/dev-guide-sample-application-python-peewee.md @@ -24,12 +24,12 @@ TiDBはMySQL互換のデータベースであり、PythonはPythonで人気の[ - [Python 3.8以降](https://www.python.org/downloads/)。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -153,7 +153,7 @@ peeweeは、複数のデータベースを扱うORMライブラリです。デ
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -161,7 +161,7 @@ peeweeは、複数のデータベースを扱うORMライブラリです。デ IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -336,7 +336,7 @@ Player.delete().where(Player.coins == 100).execute() ## 次のステップ {#next-steps} - ピーウィーの使い方の詳細については、ピーウィー[ピーウィーのドキュメント](https://docs.peewee-orm.com/)ご覧ください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-python-pymysql.md b/develop/dev-guide-sample-application-python-pymysql.md index b105a36fb5c3f..9e23df1e17105 100644 --- a/develop/dev-guide-sample-application-python-pymysql.md +++ b/develop/dev-guide-sample-application-python-pymysql.md @@ -24,12 +24,12 @@ TiDBはMySQL互換のデータベースであり、 [PyMySQL](https://github.com - [Python 3.8以降](https://www.python.org/downloads/)。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -149,7 +149,7 @@ pip install -r requirements.txt
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -157,7 +157,7 @@ pip install -r requirements.txt IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -316,7 +316,7 @@ Pythonドライバはデータベースへの低レベルアクセスを提供 ## 次のステップ {#next-steps} - PyMySQL の使用法の詳細については[PyMySQLのドキュメント](https://pymysql.readthedocs.io)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-python-sqlalchemy.md b/develop/dev-guide-sample-application-python-sqlalchemy.md index 06124b7f74f5c..c11a4da6911c2 100644 --- a/develop/dev-guide-sample-application-python-sqlalchemy.md +++ b/develop/dev-guide-sample-application-python-sqlalchemy.md @@ -24,12 +24,12 @@ TiDBはMySQL互換のデータベースであり、 [SQLAlchemy](https://www.sql - [Python 3.8以降](https://www.python.org/downloads/)。 - [Git](https://git-scm.com/downloads) 。 -- TiDBクラスタ。 +- TiDBクラスター。 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -159,7 +159,7 @@ SQLAlchemyは、複数のデータベースを扱うORMライブラリです。
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -167,7 +167,7 @@ SQLAlchemyは、複数のデータベースを扱うORMライブラリです。 IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -329,7 +329,7 @@ with Session() as session: ## 次のステップ {#next-steps} - SQLAlchemy の使用法の詳細については[SQLAlchemyのドキュメント](https://www.sqlalchemy.org/)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)[データの更新](/develop/dev-guide-update-data.md)、[データを削除する](/develop/dev-guide-delete-data.md)、「SQL パフォーマンス最適化」などの章[単一表の読み取り](/develop/dev-guide-get-data-from-single-table.md)読んで、TiDB アプリケーション [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-ruby-mysql2.md b/develop/dev-guide-sample-application-ruby-mysql2.md index 2fc140bddad2d..9262c52ab643c 100644 --- a/develop/dev-guide-sample-application-ruby-mysql2.md +++ b/develop/dev-guide-sample-application-ruby-mysql2.md @@ -25,12 +25,12 @@ TiDBはMySQL互換のデータベースであり、 [mysql2](https://github.com/ - [ルビー](https://www.ruby-lang.org/en/)>= 3.0 がマシンにインストールされている - あなたのマシンにインストールされている[バンドラー](https://bundler.io/) - お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています -- TiDBクラスタが稼働中 +- TiDBクラスターが稼働中 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -150,7 +150,7 @@ bundle add mysql2 dotenv
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -158,7 +158,7 @@ bundle add mysql2 dotenv IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -180,7 +180,7 @@ bundle add mysql2 dotenv > **注記** > - > TiDB Cloud Dedicatedクラスタへの接続にパブリックエンドポイントを使用する場合は、TLS接続を有効にすることをお勧めします。 + > TiDB Cloud Dedicatedクラスターへの接続にパブリックエンドポイントを使用する場合は、TLS接続を有効にすることをお勧めします。 > > TLS接続を有効にするには、 `DATABASE_ENABLE_SSL`を`true`に変更し、 `DATABASE_SSL_CA`を使用して、接続ダイアログからダウンロードしたCA証明書のファイルパスを指定します。 @@ -336,7 +336,7 @@ CA証明書のパスを手動で指定することも可能ですが、異なる ## 次のステップ {#next-steps} - mysql2 ドライバーの使用方法の詳細については[mysql2のドキュメント](https://github.com/brianmario/mysql2#readme)参照してください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)SQL [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読ん[クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読ん[クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-sample-application-ruby-rails.md b/develop/dev-guide-sample-application-ruby-rails.md index dc71e73de1563..fa26dec51f53b 100644 --- a/develop/dev-guide-sample-application-ruby-rails.md +++ b/develop/dev-guide-sample-application-ruby-rails.md @@ -25,12 +25,12 @@ TiDBはMySQL互換のデータベースであり、 [Rails](https://github.com/r - [ルビー](https://www.ruby-lang.org/en/)>= 3.0 がマシンにインストールされている - あなたのマシンにインストールされている[バンドラー](https://bundler.io/) - お使いのマシンに[Git](https://git-scm.com/downloads)がインストールされています -- TiDBクラスタが稼働中 +- TiDBクラスターが稼働中 -**TiDBクラスタをお持ちでない場合は、以下の手順で作成できます。** +**TiDBクラスターをお持ちでない場合は、以下の手順で作成できます。** - (推奨) [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md)。 -- [ローカルテスト用のTiDBセルフマネージドクラスタをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番本番のTiDBセルフマネージドクラスタをデプロイ。](/production-deployment-using-tiup.md) +- [ローカルテスト用のTiDB Self-Managedクラスターをデプロイ。](/quick-start-with-tidb.md#deploy-a-local-test-cluster)または[本番環境のTiDB Self-Managedクラスターをデプロイ。](/production-deployment-using-tiup.md) ## TiDBに接続するには、サンプルアプリを実行してください。 {#run-the-sample-app-to-connect-to-tidb} @@ -135,7 +135,7 @@ bundle add mysql2 dotenv
-1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -143,7 +143,7 @@ bundle add mysql2 dotenv IP アクセス リストを設定していない場合は、最初の接続の前に、 **[IP アクセス リストの設定] をクリックするか、「IP アクセス リストを設定する」**の手順に従って[IPアクセスリストを設定する](https://docs.pingcap.com/tidbcloud/configure-ip-access-list)。 - TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 + TiDB Cloud Dedicated は、**パブリック**接続タイプに加えて、**プライベート エンドポイント**および**VPC ピアリング**接続タイプもサポートしています。詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster)参照してください。 4. `.env.example`をコピーして`.env`に名前を変更するには、次のコマンドを実行します。 @@ -305,7 +305,7 @@ CA証明書のパスを手動で指定することも可能ですが、異なる ## 次のステップ {#next-steps} - ActiveRecord ORM の使用法について詳しくは[ActiveRecordのドキュメント](https://guides.rubyonrails.org/active_record_basics.html)ご覧ください。 -- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)SQL [取引](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読ん[クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 +- [開発者ガイド](https://docs.pingcap.com/developer/)[データを挿入する](/develop/dev-guide-insert-data.md)、[データの更新](/develop/dev-guide-update-data.md)[データを削除する](/develop/dev-guide-delete-data.md)SQL [トランザクション](/develop/dev-guide-transaction-overview.md)[SQLパフォーマンス最適化](/develop/dev-guide-optimize-sql-overview.md)などの章を読ん[クエリデータ](/develop/dev-guide-get-data-from-single-table.md)、TiDB アプリケーション開発のベスト プラクティスを学びましょう。 - プロフェッショナルな[TiDB開発者向けコース](https://www.pingcap.com/education/)コースを通じて学習し、試験に合格すると[TiDB認定資格](https://www.pingcap.com/education/certification/)を取得します。 ## お困りですか？ {#need-help} diff --git a/develop/dev-guide-schema-design-overview.md b/develop/dev-guide-schema-design-overview.md index e4aaa9dce0984..c732dd2f9f42b 100644 --- a/develop/dev-guide-schema-design-overview.md +++ b/develop/dev-guide-schema-design-overview.md @@ -41,10 +41,10 @@ TiDBには`test`という名前のデフォルトデータベースが付属し > **注記：** > -> TiDBでは、**プライマリキー**のデフォルト定義は[InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-storage-engine.html) （MySQLの一般的なstorageエンジン）とは異なります。 +> TiDBでは、**プライマリキー**のデフォルト定義は[InnoDB](https://dev.mysql.com/doc/refman/8.0/en/innodb-ストレージ-engine.html) （MySQLの一般的なストレージエンジン）とは異なります。 > -> - InnoDBでは、**プライマリキー**の定義は一意であり、nullではなく、**クラスタ化されたインデックス**です。 -> - TiDB では、**プライマリ キー**の定義は一意であり、NULL ではありません。ただし、プライマリ キーが**クラスタ化インデックス**であるとは限りません。プライマリ キーがクラスタ化インデックスであるかどうかを指定するには、 `CLUSTERED`ステートメントの`NONCLUSTERED`の後に、予約されていないキーワード`PRIMARY KEY`または`CREATE TABLE`追加します。ステートメントでこれらのキーワードが明示的に指定されていない場合、デフォルトの動作はシステム変数`@@global.tidb_enable_clustered_index`によって制御されます。詳細については、[クラスター化インデックス](/clustered-indexes.md)参照してください。 +> - InnoDBでは、**プライマリキー**の定義は一意であり、nullではなく、**クラスター化されたインデックス**です。 +> - TiDB では、**プライマリ キー**の定義は一意であり、NULL ではありません。ただし、プライマリ キーが**クラスター化インデックス**であるとは限りません。プライマリ キーがクラスター化インデックスであるかどうかを指定するには、 `CLUSTERED`ステートメントの`NONCLUSTERED`の後に、予約されていないキーワード`PRIMARY KEY`または`CREATE TABLE`追加します。ステートメントでこれらのキーワードが明示的に指定されていない場合、デフォルトの動作はシステム変数`@@global.tidb_enable_clustered_index`によって制御されます。詳細については、[クラスター化インデックス](/clustered-indexes.md)参照してください。 #### 専門索引 {#specialized-indexes} diff --git a/develop/dev-guide-sql-development-specification.md b/develop/dev-guide-sql-development-specification.md index fc87b985392f0..ba44c4801e968 100644 --- a/develop/dev-guide-sql-development-specification.md +++ b/develop/dev-guide-sql-development-specification.md @@ -45,7 +45,7 @@ aliases: ['/ja/tidb/stable/dev-guide-sql-development-specification/','/ja/tidbcl - `OR` `IN`または`UNION`に置き換えてください。7 の数は`IN` `300`でなければなりません。 - あいまいプレフィックスクエリには`%`プレフィックスを使用しないでください。 - アプリケーションが**マルチステートメント**を使用して SQL を実行する場合、つまり複数の SQL がセミコロンで結合され、一度にクライアントに送信されて実行される場合、TiDB は最初の SQL 実行の結果のみを返します。 -- 式を使用する場合は、その式がstorageレイヤー（TiKVまたはTiFlash ）へのコンピューティングのプッシュダウンをサポートしているかどうかを確認してください。サポートされていない場合は、TiDBレイヤーでメモリ消費量が増加し、OOMが発生する可能性が高くなります。storageレイヤーにプッシュダウンできるコンピューティングは以下の通りです。 +- 式を使用する場合は、その式がストレージレイヤー（TiKVまたはTiFlash ）へのコンピューティングのプッシュダウンをサポートしているかどうかを確認してください。サポートされていない場合は、TiDBレイヤーでメモリ消費量が増加し、OOMが発生する可能性が高くなります。ストレージレイヤーにプッシュダウンできるコンピューティングは以下の通りです。 - [TiFlashはプッシュダウン計算をサポート](/tiflash/tiflash-supported-pushdown-calculations.md) 。 - [TiKV - プッシュダウンの式一覧](/functions-and-operators/expressions-pushed-down.md) 。 - [述語プッシュダウン](/predicate-push-down.md) 。 @@ -54,4 +54,4 @@ aliases: ['/ja/tidb/stable/dev-guide-sql-development-specification/','/ja/tidbcl - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-third-party-support.md b/develop/dev-guide-third-party-support.md index 670a5255d442c..778a6c012349d 100644 --- a/develop/dev-guide-third-party-support.md +++ b/develop/dev-guide-third-party-support.md @@ -65,4 +65,4 @@ PingCAP はコミュニティと連携し、サードパーティ ツールに - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-third-party-tools-compatibility.md b/develop/dev-guide-third-party-tools-compatibility.md index c2432a6049361..a7fd7c1d0937b 100644 --- a/develop/dev-guide-third-party-tools-compatibility.md +++ b/develop/dev-guide-third-party-tools-compatibility.md @@ -43,8 +43,8 @@ MySQLは、データベースに対して実行された操作の合計数を追 これらの変数は使用しないでください。よくあるシナリオの一つは監視です。TiDBは監視性に優れているため、サーバーステータス変数からのクエリは必要ありません。監視サービスの詳細については、以下のドキュメントを参照してください。 -- TiDB Cloudドキュメント: [TiDBクラスタを監視する](/tidb-cloud/monitor-tidb-cluster.md) . -- TiDB セルフマネージド ドキュメント: [TiDB 監視フレームワークの概要](/tidb-monitoring-framework.md) . +- TiDB Cloudドキュメント: [TiDBクラスターを監視する](/tidb-cloud/monitor-tidb-cluster.md) . +- TiDB Self-Managed ドキュメント: [TiDB 監視フレームワークの概要](/tidb-monitoring-framework.md) . ### TiDBはエラーメッセージでTIMESTAMPとDATETIMEを区別します {#tidb-distinguishes-between-code-timestamp-code-and-code-datetime-code-in-error-messages} @@ -220,4 +220,4 @@ TiDB がサポートする分離レベル`REPEATABLE-READ`または`READ-COMMITT - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-tidb-basics.md b/develop/dev-guide-tidb-basics.md index 96d8396617933..27e41f8f84b92 100644 --- a/develop/dev-guide-tidb-basics.md +++ b/develop/dev-guide-tidb-basics.md @@ -13,7 +13,7 @@ TiDB を使い始める前に、TiDB がどのように動作するかに関す ## TiDBトランザクションメカニズム {#tidb-transaction-mechanisms} -TiDBは分散トランザクションをサポートし、モード[楽観的取引](/optimistic-transaction.md)とモード[悲観的取引](/pessimistic-transaction.md)の両方を提供しています。現在のバージョンのTiDBでは、デフォルトで**悲観的トランザクション**モードが採用されており、従来のモノリシックデータベース（MySQLなど）と同様にTiDBでトランザクションを実行できます。 +TiDBは分散トランザクションをサポートし、モード[楽観的トランザクション](/optimistic-transaction.md)とモード[悲観的トランザクション](/pessimistic-transaction.md)の両方を提供しています。現在のバージョンのTiDBでは、デフォルトで**悲観的トランザクション**モードが採用されており、従来のモノリシックデータベース（MySQLなど）と同様にTiDBでトランザクションを実行できます。 [`BEGIN`](/sql-statements/sql-statement-begin.md)でトランザクションを開始するか、 `BEGIN PESSIMISTIC`で**悲観的トランザクションを**明示的に指定するか、 `BEGIN OPTIMISTIC`で**楽観的トランザクション**を明示的に指定することができます。その後、トランザクションをコミット（ [`COMMIT`](/sql-statements/sql-statement-commit.md) ）またはロールバック（ [`ROLLBACK`](/sql-statements/sql-statement-rollback.md) ）することができます。 @@ -43,4 +43,4 @@ TiDB は MySQL プロトコルおよび MySQL 構文と互換性があるため - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-tidb-crud-sql.md b/develop/dev-guide-tidb-crud-sql.md index ea25c67e7c1c9..6e72c583a0d27 100644 --- a/develop/dev-guide-tidb-crud-sql.md +++ b/develop/dev-guide-tidb-crud-sql.md @@ -12,11 +12,11 @@ aliases: ['/ja/tidb/stable/dev-guide-tidb-crud-sql/','/ja/tidb/dev/dev-guide-tid TiDB に接続していることを確認してください。そうでない場合は、 [TiDB Cloud Starterインスタンスを作成する](/develop/dev-guide-build-cluster-in-cloud.md#step-1-create-a-starter-instance)、最初に接続します。 -## TiDBでSQLを探求しよう {#explore-sql-with-tidb} +## TiDBでのSQL基本操作 {#explore-sql-with-tidb} > **注記：** > -> このドキュメントは[TiDBでSQLを探求しよう](/basic-sql-operations.md)を参照し、簡略化しています。詳細については、 [TiDBでSQLを探求しよう](/basic-sql-operations.md)参照してください。 +> このドキュメントは[TiDBでのSQL基本操作](/basic-sql-operations.md)を参照し、簡略化しています。詳細については、 [TiDBでのSQL基本操作](/basic-sql-operations.md)参照してください。 TiDB は MySQL と互換性があり、ほとんどの場合、MySQL ステートメントを直接使用できます。サポートされていない機能については、 [MySQLとの互換性](/mysql-compatibility.md#unsupported-features)を参照してください。 @@ -36,7 +36,7 @@ SQLは、その関数に応じて以下の4種類に分類されます。 - **DCL（データ制御言語）** ：アクセス権限とセキュリティレベルを定義するために使用されます。 -以下では主にDMLとDQLについて紹介します。 DDL と DCL の詳細については、 [TiDBでSQLを探求しよう](/basic-sql-operations.md)または[SQLステートメントの概要](/sql-statements/sql-statement-overview.md)参照してください。 +以下では主にDMLとDQLについて紹介します。 DDL と DCL の詳細については、 [TiDBでのSQL基本操作](/basic-sql-operations.md)または[SQLステートメントの概要](/sql-statements/sql-statement-overview.md)参照してください。 ## データ操作言語 {#data-manipulation-language} diff --git a/develop/dev-guide-timeouts-in-tidb.md b/develop/dev-guide-timeouts-in-tidb.md index d320b3775e86f..f0ad48ea63bb6 100644 --- a/develop/dev-guide-timeouts-in-tidb.md +++ b/develop/dev-guide-timeouts-in-tidb.md @@ -25,7 +25,7 @@ TiDBのトランザクション実装では、MVCC（Multiple Version Concurrenc - v5.0 より前の TiDB バージョンの場合: TiDB の`mysql.tidb`のテーブルの`tikv_gc_life_time`調整します。 - TiDB v5.0 以降のバージョンの場合: システム変数[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50)を調整します。 -システム変数の設定はグローバルかつ即座に反映されます。値を増やすと既存のスナップショットの有効期間が延長され、値を減らすとすべてのスナップショットの有効期間が即座に短縮されます。MVCCのバージョンが多すぎると、TiDBクラスタのパフォーマンスに影響します。そのため、この変数は適切なタイミングで以前の設定に戻す必要があります。 +システム変数の設定はグローバルかつ即座に反映されます。値を増やすと既存のスナップショットの有効期間が延長され、値を減らすとすべてのスナップショットの有効期間が即座に短縮されます。MVCCのバージョンが多すぎると、TiDBクラスターのパフォーマンスに影響します。そのため、この変数は適切なタイミングで以前の設定に戻す必要があります。 > **ヒント：** > @@ -77,4 +77,4 @@ TiDB は、次の MySQL 互換のタイムアウト制御パラメータを提 - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-transaction-overview.md b/develop/dev-guide-transaction-overview.md index 29e45553969fa..e183cde34b14b 100644 --- a/develop/dev-guide-transaction-overview.md +++ b/develop/dev-guide-transaction-overview.md @@ -6,13 +6,13 @@ aliases: ['/ja/tidb/stable/dev-guide-transaction-overview/','/ja/tidbcloud/dev-g # トランザクションの概要 {#transaction-overview} -TiDBは完全な分散トランザクションをサポートし、 [楽観的取引](/optimistic-transaction.md)と[悲観的取引](/pessimistic-transaction.md) （TiDB 3.0で導入）を提供します。この記事では主に、トランザクションステートメント、楽観的トランザクションと悲観的トランザクション、トランザクション分離レベル、そして楽観的トランザクションにおけるアプリケーション側の再試行とエラー処理について紹介します。 +TiDBは完全な分散トランザクションをサポートし、 [楽観的トランザクション](/optimistic-transaction.md)と[悲観的トランザクション](/pessimistic-transaction.md) （TiDB 3.0で導入）を提供します。この記事では主に、トランザクションステートメント、楽観的トランザクションと悲観的トランザクション、トランザクション分離レベル、そして楽観的トランザクションにおけるアプリケーション側の再試行とエラー処理について紹介します。 ## 一般的な発言 {#common-statements} この章では、TiDBにおけるトランザクションの使用方法を紹介します。以下の例は、単純なトランザクションの処理を示しています。 -ボブはアリスに20ドルを送金したいと考えています。この取引には2つの操作が含まれます。 +ボブはアリスに20ドルを送金したいと考えています。このトランザクションには2つの操作が含まれます。 - ボブの口座残高は 20 ドル減少します。 - アリスの口座残高は 20 ドル増加しました。 @@ -49,7 +49,7 @@ COMMIT; ``` -### 取引を開始する {#start-a-transaction} +### トランザクションを開始する {#start-a-transaction} 新しいトランザクションを明示的に開始するには、 `BEGIN`または`START TRANSACTION`いずれかを使用できます。 @@ -61,7 +61,7 @@ BEGIN; START TRANSACTION; ``` -TiDBのデフォルトのトランザクションモードは悲観的です。1 [楽観的取引モデル](/develop/dev-guide-optimistic-and-pessimistic-transaction.md)明示的に指定することもできます。 +TiDBのデフォルトのトランザクションモードは悲観的です。1 [楽観的トランザクションモデル](/develop/dev-guide-optimistic-and-pessimistic-transaction.md)明示的に指定することもできます。 ```sql BEGIN OPTIMISTIC; @@ -165,4 +165,4 @@ TiDBは、MySQLとの整合性を確保するために、スナップショッ - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-transaction-restraints.md b/develop/dev-guide-transaction-restraints.md index f3cef816357a6..f215b40ab102a 100644 --- a/develop/dev-guide-transaction-restraints.md +++ b/develop/dev-guide-transaction-restraints.md @@ -706,7 +706,7 @@ mysql> SELECT * FROM T2; +------+ ``` -## 大口取引制限 {#large-transaction-restrictions} +## 大口トランザクション制限 {#large-transaction-restrictions} 基本原則は、トランザクションのサイズを制限することです。KVレベルでは、TiDBは単一トランザクションのサイズに制限を設けています。SQLレベルでは、1行のデータが1つのKVエントリにマッピングされ、インデックスを追加するたびに1つのKVエントリが追加されます。SQLレベルでの制限は以下のとおりです。 diff --git a/develop/dev-guide-transaction-troubleshoot.md b/develop/dev-guide-transaction-troubleshoot.md index b572bbb1dbcec..ea56b57298737 100644 --- a/develop/dev-guide-transaction-troubleshoot.md +++ b/develop/dev-guide-transaction-troubleshoot.md @@ -130,4 +130,4 @@ while True: - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-troubleshoot-overview.md b/develop/dev-guide-troubleshoot-overview.md index 8bb1893838ab0..302a933e4880f 100644 --- a/develop/dev-guide-troubleshoot-overview.md +++ b/develop/dev-guide-troubleshoot-overview.md @@ -34,7 +34,7 @@ SQL クエリのパフォーマンスを向上させる場合は、 [SQL性能 SQL 操作について質問がある場合は、 [SQLに関するよくある質問](/faq/sql-faq.md)参照してください。 -## 取引に関する問題のトラブルシューティング {#troubleshoot-transaction-issues} +## トランザクションに関する問題のトラブルシューティング {#troubleshoot-transaction-issues} [トランザクションエラーを処理する](/develop/dev-guide-transaction-troubleshoot.md)参照。 @@ -42,10 +42,10 @@ SQL 操作について質問がある場合は、 [SQLに関するよくある - [サポートされていない機能](/mysql-compatibility.md#unsupported-features) - [TiDB Cloudに関するよくある質問](/tidb-cloud/tidb-cloud-faq.md) -- [TiDBセルフマネージドに関するFAQ](/faq/faq-overview.md) +- [TiDB Self-Managedに関するFAQ](/faq/faq-overview.md) ## ヘルプが必要ですか? {#need-help} - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-unique-serial-number-generation.md b/develop/dev-guide-unique-serial-number-generation.md index 73e403eaf278c..108a1825aa6a4 100644 --- a/develop/dev-guide-unique-serial-number-generation.md +++ b/develop/dev-guide-unique-serial-number-generation.md @@ -53,4 +53,4 @@ Snowflakeは、Twitterが提案する分散ID生成ソリューションです - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-unstable-result-set.md b/develop/dev-guide-unstable-result-set.md index a023212f2b38a..3740584529df7 100644 --- a/develop/dev-guide-unstable-result-set.md +++ b/develop/dev-guide-unstable-result-set.md @@ -116,7 +116,7 @@ ERROR 1055 (42000): Expression #2 of ORDER BY is not in GROUP BY clause and cont ## 注文方法 {#order-by} -SQLセマンティクスでは、 `ORDER BY`構文が使用されている場合にのみ結果セットが順序通りに出力されます。単一インスタンスのデータベースでは、データが1つのサーバーに保存されるため、複数回実行してもデータの再編成なしで結果が安定することがよくあります。一部のデータベース（特にMySQL InnoDBstorageエンジン）では、主キーまたはインデックスの順序で結果セットを出力することも可能です。 +SQLセマンティクスでは、 `ORDER BY`構文が使用されている場合にのみ結果セットが順序通りに出力されます。単一インスタンスのデータベースでは、データが1つのサーバーに保存されるため、複数回実行してもデータの再編成なしで結果が安定することがよくあります。一部のデータベース（特にMySQL InnoDBストレージエンジン）では、主キーまたはインデックスの順序で結果セットを出力することも可能です。 分散データベースであるTiDBは、複数のサーバーにデータを保存しています。また、TiDBレイヤーはデータページをキャッシュしないため、 `ORDER BY`を含まないSQL文の結果セットの順序は不安定であると認識されやすくなります。連続した結果セットを出力するには、SQLセマンティクスに準拠した`ORDER BY`節に明示的に順序フィールドを追加する必要があります。 @@ -172,7 +172,7 @@ mysql> select a.class, a.stuname, b.course, b.courscore from stu_info a join stu ## GROUP_CONCAT()で order by が使用されていないため、結果セットは不安定です。 {#the-result-set-is-unstable-because-order-by-is-not-used-in-code-group-concat-code} -TiDB はstorageレイヤーからデータを並列に読み取るため、結果セットは不安定になります。そのため、 `ORDER BY`なしで`GROUP_CONCAT()`によって返される結果セットの順序は不安定であると簡単に認識されます。 +TiDB はストレージレイヤーからデータを並列に読み取るため、結果セットは不安定になります。そのため、 `ORDER BY`なしで`GROUP_CONCAT()`によって返される結果セットの順序は不安定であると簡単に認識されます。 `GROUP_CONCAT()`結果セットの出力を順序通りにするには、SQLセマンティクスに準拠した`ORDER BY`節にソートフィールドを追加する必要があります。次の例では、 `ORDER BY`を除いた`customer_id`を連結する`GROUP_CONCAT()`によって、結果セットが不安定になります。 @@ -226,10 +226,10 @@ TiDB はstorageレイヤーからデータを並列に読み取るため、結 ## SELECT * FROM T LIMIT Nで結果が不安定になる {#unstable-results-in-code-select-from-t-limit-n-code} -返される結果は、storageノード（TiKV）上のデータの分散状況に関係します。複数のクエリを実行すると、storageノード（TiKV）の異なるstorageユニット（リージョン）から異なる速度で結果が返されるため、結果が不安定になる可能性があります。 +返される結果は、ストレージノード（TiKV）上のデータの分散状況に関係します。複数のクエリを実行すると、ストレージノード（TiKV）の異なるストレージユニット（リージョン）から異なる速度で結果が返されるため、結果が不安定になる可能性があります。 ## ヘルプが必要ですか? {#need-help} - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-update-data.md b/develop/dev-guide-update-data.md index 1986d81daf58e..2aaf71a191c08 100644 --- a/develop/dev-guide-update-data.md +++ b/develop/dev-guide-update-data.md @@ -50,7 +50,7 @@ UPDATE {table} SET {update_column} = {update_value} WHERE {filter_column} = {fil データ更新に関するベストプラクティスを以下に示します。 - `WHERE`ステートメントには、必ず`UPDATE`句を指定してください。 `UPDATE`ステートメントに`WHERE`句がない場合、TiDB はテーブル内の***すべての行***を更新します。 -- 大量の行 (たとえば、1 万行以上) を更新する必要がある場合は[一括更新](#bulk-update)使用します。 TiDB は 1 つのトランザクションのサイズを制限しているため ( [トランザクションの合計サイズ制限](/tidb-configuration-file.md#txn-total-size-limit)、デフォルトでは 100 MB)、一度にあまりにも多くのデータ更新が行われると、長時間ロックが保持されすぎたり ([悲観的取引](/pessimistic-transaction.md))、競合が発生したり ([楽観的取引](/optimistic-transaction.md)) されます。 +- 大量の行 (たとえば、1 万行以上) を更新する必要がある場合は[一括更新](#bulk-update)使用します。 TiDB は 1 つのトランザクションのサイズを制限しているため ( [トランザクションの合計サイズ制限](/tidb-configuration-file.md#txn-total-size-limit)、デフォルトでは 100 MB)、一度にあまりにも多くのデータ更新が行われると、長時間ロックが保持されすぎたり ([悲観的トランザクション](/pessimistic-transaction.md))、競合が発生したり ([楽観的トランザクション](/optimistic-transaction.md)) されます。 ### UPDATE例 {#code-update-code-example} @@ -152,7 +152,7 @@ VALUES (?, ?, ?, NOW()) ON DUPLICATE KEY UPDATE `score` = ?, `rated_at` = NOW()" テーブル内の複数のデータ行を更新する必要がある場合は、 [`INSERT ON DUPLICATE KEY UPDATE`使用する](#use-insert-on-duplicate-key-update)`WHERE`句を使用して、更新する必要のあるデータをフィルタリングできます。 -ただし、多数の行 (たとえば、1 万行以上) を更新する必要がある場合は、データを繰り返し更新すること、つまり、更新が完了するまで各繰り返しでデータの一部のみを更新することをお勧めします。これは、TiDB が単一トランザクションのサイズを制限しているためです ( [トランザクションの合計サイズ制限](/tidb-configuration-file.md#txn-total-size-limit)、デフォルトでは 100 MB)。一度にあまりに多くのデータ更新を行うと、長時間ロックが保持されたり ([悲観的取引](/pessimistic-transaction.md)、競合が発生したり ([楽観的取引](/optimistic-transaction.md)) されます。プログラムまたはスクリプトでループを使用すると、操作を完了できます。 +ただし、多数の行 (たとえば、1 万行以上) を更新する必要がある場合は、データを繰り返し更新すること、つまり、更新が完了するまで各繰り返しでデータの一部のみを更新することをお勧めします。これは、TiDB が単一トランザクションのサイズを制限しているためです ( [トランザクションの合計サイズ制限](/tidb-configuration-file.md#txn-total-size-limit)、デフォルトでは 100 MB)。一度にあまりに多くのデータ更新を行うと、長時間ロックが保持されたり ([悲観的トランザクション](/pessimistic-transaction.md)、競合が発生したり ([楽観的トランザクション](/optimistic-transaction.md)) されます。プログラムまたはスクリプトでループを使用すると、操作を完了できます。 このセクションでは、反復的な更新を処理するスクリプトの記述例を示します。この例では`SELECT`と`UPDATE`を組み合わせて一括更新を完了する方法を示します。 diff --git a/develop/dev-guide-use-common-table-expression.md b/develop/dev-guide-use-common-table-expression.md index 5002d67c227a6..a66d36d5cb741 100644 --- a/develop/dev-guide-use-common-table-expression.md +++ b/develop/dev-guide-use-common-table-expression.md @@ -214,4 +214,4 @@ SELECT * FROM fibonacci; - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-use-follower-read.md b/develop/dev-guide-use-follower-read.md index 3e41b2ce77387..8c8523120b8c2 100644 --- a/develop/dev-guide-use-follower-read.md +++ b/develop/dev-guide-use-follower-read.md @@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/dev-guide-use-follower-read/','/ja/tidbcloud/dev-guid ## 導入 {#introduction} -TiDBは、 [リージョン](/tidb-storage.md#region)基本単位として、クラスター内のすべてのノードにデータを分散します。リージョンには複数のレプリカを配置でき、レプリカはリーダーと複数のフォロワーに分割されます。リーダーのデータが変更されると、TiDBはフォロワーのデータも同期的に更新します。 +TiDBは、 [リージョン](/tidb-ストレージ.md#region)基本単位として、クラスター内のすべてのノードにデータを分散します。リージョンには複数のレプリカを配置でき、レプリカはリーダーと複数のフォロワーに分割されます。リーダーのデータが変更されると、TiDBはフォロワーのデータも同期的に更新します。 デフォルトでは、TiDB は同じリージョンのリーダーに対してのみデータの読み取りと書き込みを行います。リージョン内で読み取りホットスポットが発生すると、リージョンリーダーがシステム全体の読み取りボトルネックになる可能性があります。このような状況では、Follower Read機能を有効にすると、リーダーの負荷を大幅に軽減し、複数のフォロワー間で負荷を分散することでシステム全体のスループットを向上させることができます。 @@ -21,7 +21,7 @@ TiDBは、 [リージョン](/tidb-storage.md#region)基本単位として、ク 次のいずれかを実行すると、アプリケーションにホットスポットリージョンがあるかどうかを視覚的に分析できます。 - TiDB Cloud: [TiDB Cloudコンソールのキー ビジュアライザー](/tidb-cloud/tune-performance.md#key-visualizer)に移動し、「メトリック選択ボックス」を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 -- TiDB セルフマネージド: [TiDBダッシュボードのキービジュアライザー](/dashboard/dashboard-key-visualizer.md)に移動し、「メトリック選択ボックス」を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 +- TiDB Self-Managed: [TiDBダッシュボードのキービジュアライザー](/dashboard/dashboard-key-visualizer.md)に移動し、「メトリック選択ボックス」を`Read (bytes)`または`Read (keys)`に選択して、読み取りホットスポットが発生するかどうかを確認します。 ホットスポットの問題が存在する場合は、 [TiDBホットスポットの問題の処理](/troubleshoot-hot-spot-issues.md)を参照してトラブルシューティングを行うことができます。これにより、アプリケーション レベルでのホットスポットの生成を回避することができます。 @@ -140,10 +140,10 @@ public static class AuthorDAO { - [Follower Read](/follower-read.md) - [ホットスポットの問題のトラブルシューティング](/troubleshoot-hot-spot-issues.md) - [TiDB Cloudコンソールのキー ビジュアライザー](/tidb-cloud/tune-performance.md#key-visualizer) -- [TiDBセルフマネージド向けTiDBダッシュボードのキービジュアライザー](/dashboard/dashboard-key-visualizer.md) +- [TiDB Self-Managed向けTiDBダッシュボードのキービジュアライザー](/dashboard/dashboard-key-visualizer.md) ## ヘルプが必要ですか? {#need-help} - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-use-stale-read.md b/develop/dev-guide-use-stale-read.md index 9d9674c33aec4..c8833d60a9bee 100644 --- a/develop/dev-guide-use-stale-read.md +++ b/develop/dev-guide-use-stale-read.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-use-stale-read/','/ja/tidbcloud/dev-guide-u # ステイル読み取り {#stale-read} -ステイル読み取りは、TiDBがTiDBに保存されているデータの履歴バージョンを読み取るために適用するメカニズムです。このメカニズムを使用すると、特定の時刻または指定された時間範囲内で対応する履歴データを読み取ることができ、storageノード間のデータレプリケーションによって発生するレイテンシーを削減できます。Stale ステイル読み取りを使用する場合、TiDBはデータ読み取り用のレプリカをランダムに選択します。つまり、すべてのレプリカがデータ読み取りに利用可能になります。 +ステイル読み取りは、TiDBがTiDBに保存されているデータの履歴バージョンを読み取るために適用するメカニズムです。このメカニズムを使用すると、特定の時刻または指定された時間範囲内で対応する履歴データを読み取ることができ、ストレージノード間のデータレプリケーションによって発生するレイテンシーを削減できます。Stale ステイル読み取りを使用する場合、TiDBはデータ読み取り用のレプリカをランダムに選択します。つまり、すべてのレプリカがデータ読み取りに利用可能になります。 実際には、 [使用シナリオ](/stale-read.md#usage-scenarios-of-stale-read)に基づいて、TiDB でステイル読み取り を有効にすることが適切かどうかを慎重に検討してください。アプリケーションが非リアルタイム データの読み取りを許容できない場合は、 ステイル読み取りを有効にしないでください。 @@ -483,4 +483,4 @@ public static class StaleReadHelper{ - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-use-subqueries.md b/develop/dev-guide-use-subqueries.md index c6ce8c96510ab..acd944d001190 100644 --- a/develop/dev-guide-use-subqueries.md +++ b/develop/dev-guide-use-subqueries.md @@ -132,4 +132,4 @@ WHERE - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-use-temporary-tables.md b/develop/dev-guide-use-temporary-tables.md index 3f6ce1f721f08..7740e349e6bed 100644 --- a/develop/dev-guide-use-temporary-tables.md +++ b/develop/dev-guide-use-temporary-tables.md @@ -36,7 +36,7 @@ LIMIT 50; +------------+---------------------+------+ 50 rows in set (0.01 sec) -後続のクエリの利便性のために、このクエリの結果をキャッシュする必要があります。汎用テーブルをstorageとして使用する場合は、異なるセッション間でのテーブル名の重複問題を回避する方法と、バッチクエリ後にこれらのテーブルが使用されない場合があるため、中間結果を適時にクリーンアップする必要があることに注意する必要があります。 +後続のクエリの利便性のために、このクエリの結果をキャッシュする必要があります。汎用テーブルをストレージとして使用する場合は、異なるセッション間でのテーブル名の重複問題を回避する方法と、バッチクエリ後にこれらのテーブルが使用されない場合があるため、中間結果を適時にクリーンアップする必要があることに注意する必要があります。 ## 一時テーブルを作成する {#create-a-temporary-table} @@ -47,7 +47,7 @@ LIMIT 50; TiDB の一時テーブルは、ローカル一時テーブルとグローバル一時テーブルの 2 種類に分かれています。 - ローカル一時テーブルの場合、テーブル定義とテーブル内のデータは現在のセッションでのみ参照可能です。このタイプは、セッション中の中間データを一時的に保存するのに適しています。 -- グローバル一時テーブルの場合、テーブル定義はTiDBクラスタ全体から参照可能で、テーブル内のデータは現在のトランザクションからのみ参照可能です。このタイプは、トランザクション中の中間データを一時的に保存するのに適しています。 +- グローバル一時テーブルの場合、テーブル定義はTiDBクラスター全体から参照可能で、テーブル内のデータは現在のトランザクションからのみ参照可能です。このタイプは、トランザクション中の中間データを一時的に保存するのに適しています。 ### ローカル一時テーブルを作成する {#create-a-local-temporary-table} @@ -257,4 +257,4 @@ TiDB の一時テーブルの制限については、 [他の TiDB 機能との - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/dev-guide-use-views.md b/develop/dev-guide-use-views.md index 8b64b2f868efe..ac8ee5ff837db 100644 --- a/develop/dev-guide-use-views.md +++ b/develop/dev-guide-use-views.md @@ -124,4 +124,4 @@ TiDB のビューの制限については、 [ビューの制限](/views.md#limi - [不和](https://discord.gg/DQZ2dy3cuc?utm_source=doc)または[スラック](https://slack.tidb.io/invite?team=tidb-community&channel=everyone&ref=pingcap-docs)コミュニティに問い合わせてください。 - [TiDB Cloudのサポートチケットを送信する](https://tidb.support.pingcap.com/servicedesk/customer/portals) -- [TiDBセルフマネージドのサポートチケットを送信する](/support.md) +- [TiDB Self-Managedのサポートチケットを送信する](/support.md) diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index c73b120e1757e..fcbd13a807995 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -74,7 +74,7 @@ JDBCでは通常、以下の2つの処理方法が使用されます。 TiDBは両方の方法をサポートしていますが、実装がよりシンプルで実行効率も優れているため、 `FetchSize`を`Integer.MIN_VALUE`に設定する最初の方法を使用することをお勧めします。 -2番目の方法では、TiDBはまずすべてのデータをTiDBノードにロードし、 `FetchSize`に従ってクライアントにデータを返します。そのため、通常は最初の方法よりも多くのメモリを消費します。tidb_enable_tmp_storage_on_oom [`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom) `ON`に設定されている場合、TiDBは結果を一時的にハードディスクに書き込む可能性があります。 +2番目の方法では、TiDBはまずすべてのデータをTiDBノードにロードし、 `FetchSize`に従ってクライアントにデータを返します。そのため、通常は最初の方法よりも多くのメモリを消費します。tidb_enable_tmp_ストレージ_on_oom [`tidb_enable_tmp_ストレージ_on_oom`](/system-variables.md#tidb_enable_tmp_ストレージ_on_oom) `ON`に設定されている場合、TiDBは結果を一時的にハードディスクに書き込む可能性があります。 [`tidb_enable_lazy_cursor_fetch`](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830)システム変数が`ON`に設定されている場合、TiDB はクライアントがデータをフェッチするときにのみデータの一部を読み取ろうとします。これにより、使用されるメモリが少なくなります。詳細と制限については、 [`tidb_enable_lazy_cursor_fetch`システム変数の完全な説明](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830)を参照してください。 diff --git a/develop/serverless-driver.md b/develop/serverless-driver.md index b3be40edd2cd0..8fee49258c2ed 100644 --- a/develop/serverless-driver.md +++ b/develop/serverless-driver.md @@ -331,7 +331,7 @@ TiDB Cloudのサーバーレスドライバーは、以下のORMと統合され ## 価格設定 {#pricing} -サーバーレスドライバー自体は無料ですが、ドライバーを使用してデータにアクセスすると[要求単位（RU）](https://docs.pingcap.com/tidbcloud/tidb-cloud-glossary#request-unit-ru)とstorageの使用量が発生します。 +サーバーレスドライバー自体は無料ですが、ドライバーを使用してデータにアクセスすると[要求単位（RU）](https://docs.pingcap.com/tidbcloud/tidb-cloud-glossary#request-unit-ru)とストレージの使用量が発生します。 - TiDB Cloud Starterインスタンスの料金は、 [TiDB Cloud Starter の価格](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)モデルに従います。 - TiDB Cloud Essentialインスタンスの場合、価格は[TiDB Cloud Essential の価格設定](https://www.pingcap.com/tidb-cloud-essential-pricing-details/)モデルに従います。 diff --git a/dm/deploy-a-dm-cluster-using-binary.md b/dm/deploy-a-dm-cluster-using-binary.md index a6643a7192269..9ea387cff48e9 100644 --- a/dm/deploy-a-dm-cluster-using-binary.md +++ b/dm/deploy-a-dm-cluster-using-binary.md @@ -9,7 +9,7 @@ summary: DM バイナリを使用してデータ移行クラスターをデプ > **注記：** > -> 本番環境では、 [TiUPを使用してDMクラスタを展開する](/dm/deploy-a-dm-cluster-using-tiup.md)を推奨します。 +> 本番環境では、 [TiUPを使用してDMクラスターを展開する](/dm/deploy-a-dm-cluster-using-tiup.md)を推奨します。 ## DMバイナリをダウンロード {#download-dm-binary} diff --git a/dm/deploy-a-dm-cluster-using-tiup-offline.md b/dm/deploy-a-dm-cluster-using-tiup-offline.md index 333bccef7ece4..72feaecf42d40 100644 --- a/dm/deploy-a-dm-cluster-using-tiup-offline.md +++ b/dm/deploy-a-dm-cluster-using-tiup-offline.md @@ -3,7 +3,7 @@ title: Deploy a DM Cluster Offline Using TiUP summary: TiUPを使用して DM クラスターをオフラインで展開する方法を紹介します。 --- -# TiUPを使用して DMクラスタをオフラインでデプロイ {#deploy-a-dm-cluster-offline-using-tiup} +# TiUPを使用して DMクラスターをオフラインでデプロイ {#deploy-a-dm-cluster-offline-using-tiup} このドキュメントでは、 TiUPを使用して DM クラスターをオフラインで展開する方法について説明します。 @@ -141,7 +141,7 @@ tiup dm deploy dm-test ${version} ./topology.yaml --user root [-p] [-i /home/roo 上記のコマンドでは、 - デプロイされた DM クラスターの名前は`dm-test`です。 -- DMクラスタのバージョンは`${version}`です。TiUPでサポートされている最新バージョンを確認するには、 `tiup list dm-master`実行します。 +- DMクラスターのバージョンは`${version}`です。TiUPでサポートされている最新バージョンを確認するには、 `tiup list dm-master`実行します。 - 初期化構成ファイルは`topology.yaml`です。 - `--user root` : `root`キーを使用してターゲット マシンにログインし、クラスターの展開を完了するか、 `ssh`および`sudo`権限を持つ他のユーザーを使用して展開を完了することができます。 - `[-i]`と`[-p]` : オプション。ターゲットマシンへのログインをパスワードなしで設定している場合、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。4 `[-i]` 、ターゲットマシンにアクセスできる`root`ユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。10 `[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 @@ -155,15 +155,15 @@ tiup dm deploy dm-test ${version} ./topology.yaml --user root [-p] [-i /home/roo tiup dm list ``` -TiUP は複数の DM クラスタの管理をサポートしています。上記のコマンドは、現在TiUPによって管理されているすべてのクラスタの情報を出力します。これには、名前、デプロイメントユーザー、バージョン、秘密鍵の情報が含まれます。 +TiUP は複数の DM クラスターの管理をサポートしています。上記のコマンドは、現在TiUPによって管理されているすべてのクラスターの情報を出力します。これには、名前、デプロイメントユーザー、バージョン、秘密鍵の情報が含まれます。 ```log Name User Version Path PrivateKey ---- ---- ------- ---- ---------- -dm-test tidb ${version} /root/.tiup/storage/dm/clusters/dm-test /root/.tiup/storage/dm/clusters/dm-test/ssh/id_rsa +dm-test tidb ${version} /root/.tiup/ストレージ/dm/clusters/dm-test /root/.tiup/ストレージ/dm/clusters/dm-test/ssh/id_rsa ``` -## ステップ6: 展開されたDMクラスタのステータスを確認する {#step-6-check-the-status-of-the-deployed-dm-cluster} +## ステップ6: 展開されたDMクラスターのステータスを確認する {#step-6-check-the-status-of-the-deployed-dm-cluster} `dm-test`クラスターのステータスを確認するには、次のコマンドを実行します。 diff --git a/dm/deploy-a-dm-cluster-using-tiup.md b/dm/deploy-a-dm-cluster-using-tiup.md index 224442273a0dd..14dc2a0f5d746 100644 --- a/dm/deploy-a-dm-cluster-using-tiup.md +++ b/dm/deploy-a-dm-cluster-using-tiup.md @@ -3,11 +3,11 @@ title: Deploy a DM Cluster Using TiUP summary: TiUP DMを使用して TiDB データ移行を展開する方法を学習します。 --- -# TiUPを使用して DMクラスタをデプロイ {#deploy-a-dm-cluster-using-tiup} +# TiUPを使用して DMクラスターをデプロイ {#deploy-a-dm-cluster-using-tiup} -[TiUP](https://github.com/pingcap/tiup) 、TiDB 4.0で導入されたクラスタ運用・保守ツールです。TiUPは、 Golangで記述されたクラスタ管理コンポーネントである[TiUP DM](/dm/maintain-dm-using-tiup.md)提供します。TiUP TiUP DMを使用すると、DMクラスタのデプロイ、起動、停止、破棄、スケーリング、アップグレードなど、日常的なTiDBデータ移行（DM）操作を簡単に実行でき、DMクラスタパラメータの管理も可能です。 +[TiUP](https://github.com/pingcap/tiup) 、TiDB 4.0で導入されたクラスター運用・保守ツールです。TiUPは、 Golangで記述されたクラスター管理コンポーネントである[TiUP DM](/dm/maintain-dm-using-tiup.md)提供します。TiUP TiUP DMを使用すると、DMクラスターのデプロイ、起動、停止、破棄、スケーリング、アップグレードなど、日常的なTiDBデータ移行（DM）操作を簡単に実行でき、DMクラスターパラメータの管理も可能です。 -TiUPはDM v2.0以降のバージョンの導入をサポートしています。このドキュメントでは、さまざまなトポロジのDMクラスタを導入する方法について説明します。 +TiUPはDM v2.0以降のバージョンの導入をサポートしています。このドキュメントでは、さまざまなトポロジのDMクラスターを導入する方法について説明します。 > **注記：** > @@ -15,7 +15,7 @@ TiUPはDM v2.0以降のバージョンの導入をサポートしています。 ## 前提条件 {#prerequisites} -- DMが完全なデータレプリケーションタスクを実行する場合、DMワーカーは1つの上流データベースのみにバインドされます。DMワーカーはまずローカルで全データをエクスポートし、その後、下流データベースにインポートします。そのため、ワーカーのホスト領域には、エクスポートするすべての上流テーブルを保存できる十分な大きさが必要です。storageパスは、タスク作成時に後で指定します。 +- DMが完全なデータレプリケーションタスクを実行する場合、DMワーカーは1つの上流データベースのみにバインドされます。DMワーカーはまずローカルで全データをエクスポートし、その後、下流データベースにインポートします。そのため、ワーカーのホスト領域には、エクスポートするすべての上流テーブルを保存できる十分な大きさが必要です。ストレージパスは、タスク作成時に後で指定します。 - DM クラスターを展開する場合は、 [ハードウェアとソフトウェアの要件](/dm/dm-hardware-and-software-requirements.md)満たす必要があります。 @@ -23,7 +23,7 @@ TiUPはDM v2.0以降のバージョンの導入をサポートしています。 ## ステップ1: 制御マシンにTiUPをインストールする {#step-1-install-tiup-on-the-control-machine} -通常のユーザーアカウント（ユーザー`tidb`例に挙げます）を使用して制御マシンにログインします。以下のTiUPのインストールとクラスタ管理操作はすべて、ユーザー`tidb`で実行できます。 +通常のユーザーアカウント（ユーザー`tidb`例に挙げます）を使用して制御マシンにログインします。以下のTiUPのインストールとクラスター管理操作はすべて、ユーザー`tidb`で実行できます。 1. 次のコマンドを実行してTiUPをインストールします。 @@ -176,15 +176,15 @@ tiup dm deploy ${name} ${version} ./topology.yaml -u ${ssh_user} [-p] [-i /home/ tiup dm list ``` -TiUP は複数の DM クラスタの管理をサポートしています。上記のコマンドは、現在TiUPによって管理されているすべてのクラスタの情報を出力します。これには、名前、デプロイメントユーザー、バージョン、秘密鍵の情報が含まれます。 +TiUP は複数の DM クラスターの管理をサポートしています。上記のコマンドは、現在TiUPによって管理されているすべてのクラスターの情報を出力します。これには、名前、デプロイメントユーザー、バージョン、秘密鍵の情報が含まれます。 ```log Name User Version Path PrivateKey ---- ---- ------- ---- ---------- -dm-test tidb ${version} /root/.tiup/storage/dm/clusters/dm-test /root/.tiup/storage/dm/clusters/dm-test/ssh/id_rsa +dm-test tidb ${version} /root/.tiup/ストレージ/dm/clusters/dm-test /root/.tiup/ストレージ/dm/clusters/dm-test/ssh/id_rsa ``` -## ステップ5: 展開されたDMクラスタのステータスを確認する {#step-5-check-the-status-of-the-deployed-dm-cluster} +## ステップ5: 展開されたDMクラスターのステータスを確認する {#step-5-check-the-status-of-the-deployed-dm-cluster} `dm-test`クラスターのステータスを確認するには、次のコマンドを実行します。 @@ -202,7 +202,7 @@ tiup dm start dm-test 出力ログに``Started cluster `dm-test` successfully``が含まれていれば起動は成功です。 -## ステップ7: DMクラスタの実行状態を確認する {#step-7-verify-the-running-status-of-the-dm-cluster} +## ステップ7: DMクラスターの実行状態を確認する {#step-7-verify-the-running-status-of-the-dm-cluster} TiUPを使用して DM クラスターのステータスを確認します。 @@ -214,7 +214,7 @@ tiup dm display dm-test ## ステップ8: dmctlを使用して移行タスクを管理する {#step-8-managing-migration-tasks-using-dmctl} -dmctl は、DM クラスタを制御するためのコマンドラインツールです[TiUP経由でdmctlを使用する](/dm/maintain-dm-using-tiup.md#dmctl)を使用することをお勧めします。 +dmctl は、DM クラスターを制御するためのコマンドラインツールです[TiUP経由でdmctlを使用する](/dm/maintain-dm-using-tiup.md#dmctl)を使用することをお勧めします。 dmctlはコマンドモードと対話モードの両方をサポートしています。詳細については[dmctl を使用して DM クラスターを管理](/dm/dmctl-introduction.md#maintain-dm-clusters-using-dmctl)参照してください。 diff --git a/dm/dm-arch.md b/dm/dm-arch.md index a5a6ef2b2422e..45532d71b0984 100644 --- a/dm/dm-arch.md +++ b/dm/dm-arch.md @@ -1,6 +1,6 @@ --- title: Data Migration Architecture -summary: データ移行（DM）アーキテクチャは、DMマスター、DMワーカー、dmctlの3つのコンポーネントで構成されています。DMマスターはデータ移行タスクを管理し、DMワーカーは特定のタスクを実行し、dmctlはクラスタ制御用のコマンドラインツールです。高可用性は、複数のDMマスターノードと自動タスクスケジューリングによって実現されます。MySQLとDMワーカーの制限により、完全なエクスポートおよびインポートタスクは高可用性をサポートしません。 +summary: データ移行（DM）アーキテクチャは、DMマスター、DMワーカー、dmctlの3つのコンポーネントで構成されています。DMマスターはデータ移行タスクを管理し、DMワーカーは特定のタスクを実行し、dmctlはクラスター制御用のコマンドラインツールです。高可用性は、複数のDMマスターノードと自動タスクスケジューリングによって実現されます。MySQLとDMワーカーの制限により、完全なエクスポートおよびインポートタスクは高可用性をサポートしません。 --- # データ移行アーキテクチャ {#data-migration-architecture} @@ -17,7 +17,7 @@ DM は、DM マスター、DM ワーカー、dmctl の 3 つのコンポーネ DM-master は、データ移行タスクの操作を管理およびスケジュールします。 -- DMクラスタのトポロジ情報の保存 +- DMクラスターのトポロジ情報の保存 - DMワーカープロセスの実行状態の監視 - データ移行タスクの実行状態の監視 - データ移行タスクを管理するための統合ポータルを提供する @@ -27,7 +27,7 @@ DM-master は、データ移行タスクの操作を管理およびスケジュ DM-worker は特定のデータ移行タスクを実行します。 -- binlogデータをローカルstorage +- binlogデータをローカルストレージ - データ移行サブタスクの構成情報を保存する - データ移行サブタスクの操作のオーケストレーション - データ移行サブタスクの実行状態の監視 @@ -47,7 +47,7 @@ dmctl は、DM クラスターを制御するために使用されるコマン ### 高可用性 {#high-availability} -複数のDMマスターノードをデプロイする場合、すべてのDMマスターノードは組み込みのetcdを使用してクラスタを形成します。DMマスタークラスタは、クラスタノード情報やタスク設定などのメタデータを保存するために使用されます。etcdによって選出されたリーダーノードは、クラスタ管理やデータ移行タスク管理などのサービスを提供します。したがって、利用可能なDMマスターノードの数がデプロイされたノードの半数を超えても、DMクラスタは正常にサービスを提供できます。 +複数のDMマスターノードをデプロイする場合、すべてのDMマスターノードは組み込みのetcdを使用してクラスターを形成します。DMマスタークラスターは、クラスターノード情報やタスク設定などのメタデータを保存するために使用されます。etcdによって選出されたリーダーノードは、クラスター管理やデータ移行タスク管理などのサービスを提供します。したがって、利用可能なDMマスターノードの数がデプロイされたノードの半数を超えても、DMクラスターは正常にサービスを提供できます。 デプロイされた DM ワーカーノードの数が上流の MySQL/MariaDB ノードの数を超える場合、超過した DM ワーカーノードはデフォルトでアイドル状態になります。DM ワーカーノードがオフラインになったり、DM マスターリーダーから分離したりした場合、DM マスターは元の DM ワーカーノードのデータ移行タスクを他のアイドル状態の DM ワーカーノードに自動的にスケジュールします。（DM ワーカーノードが分離されると、そのノード上のデータ移行タスクが自動的に停止されます。）利用可能なアイドル状態の DM ワーカーノードがない場合、元の DM ワーカーのデータ移行タスクは、1 つの DM ワーカーノードがアイドル状態になるまで一時的に停止され、その後タスクが自動的に再開されます。 diff --git a/dm/dm-best-practices.md b/dm/dm-best-practices.md index 741af5d750513..1a864a92468d5 100644 --- a/dm/dm-best-practices.md +++ b/dm/dm-best-practices.md @@ -49,7 +49,7 @@ TiDBの`AUTO_INCREMENT`はMySQLの`AUTO_INCREMENT`と互換性があります。 - クラスター化インデックス - [クラスター化インデックス](/clustered-indexes.md) 、データstorageのハンドルID（行ID）として主キーを使用します。主キーを使用してクエリを実行すると、テーブル参照を回避できるため、クエリのパフォーマンスが効果的に向上します。ただし、テーブルが書き込み中心で、主キーに[`AUTO_INCREMENT`](/auto-increment.md)使用している場合、 [書き込みホットスポットの問題](/best-practices/high-concurrency-best-practices.md#highly-concurrent-write-intensive-scenario)発生する可能性が高く、クラスターのパフォーマンスが低下し、単一のstorageノードのパフォーマンスボトルネックが発生します。 + [クラスター化インデックス](/clustered-indexes.md) 、データストレージのハンドルID（行ID）として主キーを使用します。主キーを使用してクエリを実行すると、テーブル参照を回避できるため、クエリのパフォーマンスが効果的に向上します。ただし、テーブルが書き込み中心で、主キーに[`AUTO_INCREMENT`](/auto-increment.md)使用している場合、 [書き込みホットスポットの問題](/best-practices/high-concurrency-best-practices.md#highly-concurrent-write-intensive-scenario)発生する可能性が高く、クラスターのパフォーマンスが低下し、単一のストレージノードのパフォーマンスボトルネックが発生します。 - 非クラスター化インデックス + `shard row id bit` @@ -175,10 +175,10 @@ TiDBスキーマ名はデフォルトでは大文字と小文字を区別しま #### フィルタールール {#filter-rules} -データソースの設定を開始するとすぐに、フィルタールールを設定できます。詳細については、 [データ移行タスクコンフィグレーションガイド](/dm/dm-task-configuration-guide.md)参照してください。フィルタールールを設定することの利点は次のとおりです。 +データソースの設定を開始するとすぐに、フィルタールールを設定できます。詳細については、 [データ移行タスク設定ガイド](/dm/dm-task-configuration-guide.md)参照してください。フィルタールールを設定することの利点は次のとおりです。 - ダウンストリームで処理する必要があるBinlogイベントの数を減らし、移行の効率を向上させます。 -- 不要なリレーログのstorageを削減し、ディスク領域を節約します。 +- 不要なリレーログのストレージを削減し、ディスク領域を節約します。 > **注記：** > @@ -186,7 +186,7 @@ TiDBスキーマ名はデフォルトでは大文字と小文字を区別しま #### リレーログを使用する {#use-the-relay-log} -MySQLのマスター/スタンバイメカニズムでは、非同期レプリケーションの信頼性と効率性を確保するために、スタンバイノードがリレーログのコピーを保存します。DMは、DMワーカーへのリレーログのコピーの保存もサポートしています。storage場所や有効期限などの情報を設定できます。この機能は、以下のシナリオに適用されます。 +MySQLのマスター/スタンバイメカニズムでは、非同期レプリケーションの信頼性と効率性を確保するために、スタンバイノードがリレーログのコピーを保存します。DMは、DMワーカーへのリレーログのコピーの保存もサポートしています。ストレージ場所や有効期限などの情報を設定できます。この機能は、以下のシナリオに適用されます。 - 完全データ移行および増分データ移行において、完全データの量が多い場合、上流のバイナリログのアーカイブにかかる時間よりも、全体の処理に時間がかかります。その結果、増分レプリケーションタスクが正常に開始されないことがあります。リレーログを有効にすると、完全移行の開始時にDM-workerがリレーログの受信を開始します。これにより、増分タスクの失敗を回避できます。 @@ -231,4 +231,4 @@ DM v6.2.0以降、DMは増分レプリケーションにおける継続的なデ ## 長期データ複製 {#long-term-data-replication} -DMを使用して長期的なデータレプリケーションタスクを実行する場合、メタデータのバックアップは必須です。メタデータのバックアップは、移行クラスタの再構築を確実にする一方で、移行タスクのバージョン管理を実現できます。詳細については、 [データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション](/dm/dm-export-import-config.md)参照してください。 +DMを使用して長期的なデータレプリケーションタスクを実行する場合、メタデータのバックアップは必須です。メタデータのバックアップは、移行クラスターの再構築を確実にする一方で、移行タスクのバージョン管理を実現できます。詳細については、 [データソースのエクスポートとインポート、およびクラスターのタスク設定](/dm/dm-export-import-config.md)参照してください。 diff --git a/dm/dm-binlog-event-filter.md b/dm/dm-binlog-event-filter.md index 90584fb510b03..dc84c1fda66e2 100644 --- a/dm/dm-binlog-event-filter.md +++ b/dm/dm-binlog-event-filter.md @@ -21,7 +21,7 @@ filters: ​action: Ignore ``` -DM v2.0.2以降では、ソース設定ファイルでbinlogイベントフィルターを設定できます。詳細については、 [上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)参照してください。 +DM v2.0.2以降では、ソース設定ファイルでbinlogイベントフィルターを設定できます。詳細については、 [上流データベース設定ファイル](/dm/dm-source-configuration-file.md)参照してください。 一致するスキーマとテーブルにワイルドカードを使用する場合は、次の点に注意してください。 @@ -72,7 +72,7 @@ DM v2.0.2以降では、ソース設定ファイルでbinlogイベントフィ | `modify charset` | 互換性のないDDL | 列の文字セットを変更するDDL文（ `ALTER TABLE MODIFY CHARSET`文など） | | `modify collation` | 互換性のないDDL | 列の照合順序を変更するDDL文（ `ALTER TABLE MODIFY COLLATE`文など） | | `remove auto increment` | 互換性のないDDL | 自動増分キーを削除するDDL文 | - | `modify storage engine` | 互換性のないDDL | テーブルstorageエンジンを変更するDDL文（ `ALTER TABLE ENGINE = MyISAM`文など） | + | `modify ストレージ engine` | 互換性のないDDL | テーブルストレージエンジンを変更するDDL文（ `ALTER TABLE ENGINE = MyISAM`文など） | | `reorganize table partition` | 互換性のないDDL | テーブル内のパーティションを再編成するDDL文`ALTER TABLE REORGANIZE PARTITION`文など） | | `rebuild table partition` | 互換性のないDDL | テーブルパーティションを再構築するDDL文（ `ALTER TABLE REBUILD PARTITION`文など） | | `exchange table partition` | 互換性のないDDL | 2つのテーブル間でパーティションを交換するDDL文（ `ALTER TABLE EXCHANGE PARTITION`文など） | diff --git a/dm/dm-command-line-flags.md b/dm/dm-command-line-flags.md index 66a7525ed867c..5cb6d376390de 100644 --- a/dm/dm-command-line-flags.md +++ b/dm/dm-command-line-flags.md @@ -35,15 +35,15 @@ summary: DM のコマンドライン フラグについて学習します。 ### --initial-cluster {#code-initial-cluster-code} -- DMマスタークラスタのブートストラップに使用される`"{node name}={external address}"`リスト +- DMマスタークラスターのブートストラップに使用される`"{node name}={external address}"`リスト - デフォルト値は`"{name}={advertise-peer-urls}"`です -- `join`フラグが指定されていない場合は、このフラグを指定する必要があります。3ノードクラスタの構成例は`"dm-master-1=http://172.16.15.11:8291,dm-master-2=http://172.16.15.12:8291,dm-master-3=http://172.16.15.13:8291"`です。 +- `join`フラグが指定されていない場合は、このフラグを指定する必要があります。3ノードクラスターの構成例は`"dm-master-1=http://172.16.15.11:8291,dm-master-2=http://172.16.15.12:8291,dm-master-3=http://172.16.15.13:8291"`です。 ### --join {#code-join-code} -- DMマスターノードがこのクラスタに参加したときの既存のクラスタの`advertise-addr`リスト +- DMマスターノードがこのクラスターに参加したときの既存のクラスターの`advertise-addr`リスト - デフォルト値は`""`です -- `initial-cluster`フラグが指定されていない場合は、このフラグを指定する必要があります。2ノードのクラスタに新しいノードが参加する場合、設定例は`"172.16.15.11:8261,172.16.15.12:8261"`です。 +- `initial-cluster`フラグが指定されていない場合は、このフラグを指定する必要があります。2ノードのクラスターに新しいノードが参加する場合、設定例は`"172.16.15.11:8261,172.16.15.12:8261"`です。 ### --log-file {#code-log-file-code} @@ -97,9 +97,9 @@ summary: DM のコマンドライン フラグについて学習します。 ### --join {#code-join-code} -- DMワーカーがこのクラスタに登録したときのクラスタ内のDMマスターノードの`{advertise-addr}`のリスト +- DMワーカーがこのクラスターに登録したときのクラスター内のDMマスターノードの`{advertise-addr}`のリスト - デフォルト値は`""`です -- 必須フラグ。3ノード（DMマスターノード）クラスタの構成例は`"172.16.15.11:8261,172.16.15.12:8261,172.16.15.13:8261"`です。 +- 必須フラグ。3ノード（DMマスターノード）クラスターの構成例は`"172.16.15.11:8261,172.16.15.12:8261,172.16.15.13:8261"`です。 ### --log-file {#code-log-file-code} @@ -135,6 +135,6 @@ summary: DM のコマンドライン フラグについて学習します。 ### --master-addr {#code-master-addr-code} -- dmctlによって接続されるクラスタ内の任意のDMマスターノードの`{advertise-addr}` +- dmctlによって接続されるクラスター内の任意のDMマスターノードの`{advertise-addr}` - デフォルト値は`""`です - これは、dmctlがDMマスターと対話するときに必要なフラグです。 diff --git a/dm/dm-compatibility-catalog.md b/dm/dm-compatibility-catalog.md index ca7db6ac0c488..74f084a256d44 100644 --- a/dm/dm-compatibility-catalog.md +++ b/dm/dm-compatibility-catalog.md @@ -5,7 +5,7 @@ summary: このドキュメントでは、TiDBデータ移行（DM）と上流 # TiDBデータ移行の互換性カタログ {#compatibility-catalog-of-tidb-data-migration} -DMは、さまざまなソースからTiDBクラスタへのデータ移行をサポートしています。データソースの種類に基づいて、DMには4つの互換性レベルがあります。 +DMは、さまざまなソースからTiDBクラスターへのデータ移行をサポートしています。データソースの種類に基づいて、DMには4つの互換性レベルがあります。 - **一般提供開始（GA）** ：アプリケーションシナリオが検証され、GAテストに合格しました。 - **Experimental**：一般的なアプリケーションシナリオは検証済みですが、対象範囲は限定的であるか、ごく少数のユーザーのみが対象となっています。まれに問題が発生する可能性があるため、ご使用のシナリオにおける互換性を確認する必要があります。 diff --git a/dm/dm-config-overview.md b/dm/dm-config-overview.md index e773c705da53f..78c5fbfbfe934 100644 --- a/dm/dm-config-overview.md +++ b/dm/dm-config-overview.md @@ -3,15 +3,15 @@ title: Data Migration Configuration File Overview summary: このドキュメントでは、データ移行構成ファイルの概要を説明します。 --- -# データ移行コンフィグレーションファイルの概要 {#data-migration-configuration-file-overview} +# データ移行設定ファイルの概要 {#data-migration-configuration-file-overview} このドキュメントでは、DM (データ移行) の構成ファイルの概要を説明します。 ## DMプロセス構成ファイル {#dm-process-configuration-files} -- `dm-master.toml` : DMマスタープロセスの実行に関する設定ファイル。DMマスターのトポロジ情報とログが含まれます。詳細については、 [DMマスターコンフィグレーションファイル](/dm/dm-master-configuration-file.md)を参照してください。 -- `dm-worker.toml` : DMワーカープロセスの実行に関する設定ファイル。DMワーカーのトポロジ情報とログが含まれます。詳細は[DMワーカーコンフィグレーションファイル](/dm/dm-worker-configuration-file.md)を参照してください。 -- `source.yaml` : MySQLやMariaDBなどの上流データベースの設定。詳細は[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)を参照してください。 +- `dm-master.toml` : DMマスタープロセスの実行に関する設定ファイル。DMマスターのトポロジ情報とログが含まれます。詳細については、 [DMマスター設定ファイル](/dm/dm-master-configuration-file.md)を参照してください。 +- `dm-worker.toml` : DMワーカープロセスの実行に関する設定ファイル。DMワーカーのトポロジ情報とログが含まれます。詳細は[DMワーカー設定ファイル](/dm/dm-worker-configuration-file.md)を参照してください。 +- `source.yaml` : MySQLやMariaDBなどの上流データベースの設定。詳細は[上流データベース設定ファイル](/dm/dm-source-configuration-file.md)を参照してください。 ## DM移行タスクの構成 {#dm-migration-task-configuration} @@ -20,14 +20,14 @@ summary: このドキュメントでは、データ移行構成ファイルの データ移行タスクを作成するには、次の手順に従います。 1. [dmctl を使用してデータ ソース構成を DM クラスターにロードします。](/dm/dm-manage-source.md#operate-data-source) 。 -2. [タスクコンフィグレーションガイド](/dm/dm-task-configuration-guide.md)の説明を参考に設定ファイル`your_task.yaml`を作成します。 +2. [タスク設定ガイド](/dm/dm-task-configuration-guide.md)の説明を参考に設定ファイル`your_task.yaml`を作成します。 3. [dmctlを使用してデータ移行タスクを作成する](/dm/dm-create-task.md) 。 ### 重要な概念 {#important-concepts} このセクションでは、いくつかの重要な概念について説明します。 -| コンセプト | 説明 | コンフィグレーションファイル | +| コンセプト | 説明 | 設定ファイル | | :---------- | :-------------------------------------------------------------------------- | :--------------------------------------------------------- | | `source-id` | MySQLまたはMariaDBインスタンス、あるいはプライマリ/セカンダリ構造の移行グループを一意に表します。1の最大長は`source-id`です。 | `source_id` / `source.yaml` ;
`task.yaml`中`source-id` | | DMマスターID | DMマスターを一意に表す（ `dm-master.toml`の`master-addr`パラメータによって） | `master-addr` / `dm-master.toml` | diff --git a/dm/dm-continuous-data-validation.md b/dm/dm-continuous-data-validation.md index 71f83eb3bbddb..7a4271f6a8e18 100644 --- a/dm/dm-continuous-data-validation.md +++ b/dm/dm-continuous-data-validation.md @@ -9,7 +9,7 @@ summary: 継続的なデータ検証の使用方法と継続的なデータ検 ## ユーザーシナリオ {#user-scenario} -上流データベースから下流データベースへのデータの段階的移行プロセスでは、データフローによってデータの破損や損失が発生する可能性がわずかにあります。信用取引や証券業界など、データの整合性が求められるシナリオでは、移行完了後に完全なデータ検証を実施し、データの整合性を確保することができます。 +上流データベースから下流データベースへのデータの段階的移行プロセスでは、データフローによってデータの破損や損失が発生する可能性がわずかにあります。信用トランザクションや証券業界など、データの整合性が求められるシナリオでは、移行完了後に完全なデータ検証を実施し、データの整合性を確保することができます。 しかし、増分移行シナリオでは、上流と下流の両方で継続的にデータが書き込まれます。上流と下流の両方でデータが絶えず変化するため、テーブル内のすべてのデータに対して完全なデータ検証（例えば、 [同期差分インスペクター](/sync-diff-inspector/sync-diff-inspector-overview.md)を使用する）を実行することは困難です。 @@ -48,7 +48,7 @@ validators: - `worker-count` : バックグラウンドで実行される検証ワーカーの数。各ワーカーはゴルーチンです。 - `row-error-delay` : 指定された時間内に行が検証に合格できない場合、エラー行としてマークされます。デフォルト値は30分です。 -完全な構成については、 [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 +完全な構成については、 [DM 高度なタスク設定ファイル](/dm/task-configuration-file-full.md)を参照してください。 ### 方法2: dmctlを使用して有効にする {#method-2-enable-using-dmctl} diff --git a/dm/dm-ddl-compatible.md b/dm/dm-ddl-compatible.md index 4a7c6f0a524b2..15b6deadeef3d 100644 --- a/dm/dm-ddl-compatible.md +++ b/dm/dm-ddl-compatible.md @@ -11,7 +11,7 @@ TiDB データ移行 (DM) はデータを移行する際に、DDL ステート 次のステートメントは DM ではサポートされていないため、DM は解析後すぐにスキップします。 -
説明SQL
取引^SAVEPOINT
すべてのフラッシュSQLをスキップする^FLUSH
テーブルのメンテナンス^OPTIMIZE\\s+TABLE
^ANALYZE\\s+TABLE
^REPAIR\\s+TABLE
一時テーブル^DROP\\s+(\\/\\*\\!40005\\s+)?TEMPORARY\\s+(\\*\\/\\s+)?TABLE
トリガー^CREATE\\s+(DEFINER\\s?=.+?)?TRIGGER
^DROP\\s+TRIGGER
手順^DROP\\s+PROCEDURE
^CREATE\\s+(DEFINER\\s?=.+?)?PROCEDURE
^ALTER\\s+PROCEDURE
ビュー^CREATE\\s*(OR REPLACE)?\\s+(ALGORITHM\\s?=.+?)?(DEFINER\\s?=.+?)?\\s+(SQL SECURITY DEFINER)?VIEW
^DROP\\s+VIEW
^ALTER\\s+(ALGORITHM\\s?=.+?)?(DEFINER\\s?=.+?)?(SQL SECURITY DEFINER)?VIEW
関数^CREATE\\s+(AGGREGATE)?\\s*?FUNCTION
^CREATE\\s+(DEFINER\\s?=.+?)?FUNCTION
^ALTER\\s+FUNCTION
^DROP\\s+FUNCTION
テーブルスペース^CREATE\\s+TABLESPACE
^ALTER\\s+TABLESPACE
^DROP\\s+TABLESPACE
イベント^CREATE\\s+(DEFINER\\s?=.+?)?EVENT
^ALTER\\s+(DEFINER\\s?=.+?)?EVENT
^DROP\\s+EVENT
アカウント管理^GRANT
^REVOKE
^CREATE\\s+USER
^ALTER\\s+USER
^RENAME\\s+USER
^DROP\\s+USER
^DROP\\s+USER
+
説明SQL
トランザクション^SAVEPOINT
すべてのフラッシュSQLをスキップする^FLUSH
テーブルのメンテナンス^OPTIMIZE\\s+TABLE
^ANALYZE\\s+TABLE
^REPAIR\\s+TABLE
一時テーブル^DROP\\s+(\\/\\*\\!40005\\s+)?TEMPORARY\\s+(\\*\\/\\s+)?TABLE
トリガー^CREATE\\s+(DEFINER\\s?=.+?)?TRIGGER
^DROP\\s+TRIGGER
手順^DROP\\s+PROCEDURE
^CREATE\\s+(DEFINER\\s?=.+?)?PROCEDURE
^ALTER\\s+PROCEDURE
ビュー^CREATE\\s*(OR REPLACE)?\\s+(ALGORITHM\\s?=.+?)?(DEFINER\\s?=.+?)?\\s+(SQL SECURITY DEFINER)?VIEW
^DROP\\s+VIEW
^ALTER\\s+(ALGORITHM\\s?=.+?)?(DEFINER\\s?=.+?)?(SQL SECURITY DEFINER)?VIEW
関数^CREATE\\s+(AGGREGATE)?\\s*?FUNCTION
^CREATE\\s+(DEFINER\\s?=.+?)?FUNCTION
^ALTER\\s+FUNCTION
^DROP\\s+FUNCTION
テーブルスペース^CREATE\\s+TABLESPACE
^ALTER\\s+TABLESPACE
^DROP\\s+TABLESPACE
イベント^CREATE\\s+(DEFINER\\s?=.+?)?EVENT
^ALTER\\s+(DEFINER\\s?=.+?)?EVENT
^DROP\\s+EVENT
アカウント管理^GRANT
^REVOKE
^CREATE\\s+USER
^ALTER\\s+USER
^RENAME\\s+USER
^DROP\\s+USER
^DROP\\s+USER
## DDL文を書き換える {#rewrite-ddl-statements} diff --git a/dm/dm-enable-tls.md b/dm/dm-enable-tls.md index 21a130e8624e8..b63340f1a3e8f 100644 --- a/dm/dm-enable-tls.md +++ b/dm/dm-enable-tls.md @@ -49,7 +49,7 @@ summary: DM 接続で TLS を有効にする方法を学習します。 - dmctl - DMクラスタで暗号化通信を有効にした後、dmctlを使用してクラスタに接続する必要がある場合は、クライアント証明書を指定します。例： + DMクラスターで暗号化通信を有効にした後、dmctlを使用してクラスターに接続する必要がある場合は、クライアント証明書を指定します。例： ```bash ./dmctl --master-addr=127.0.0.1:8261 --ssl-ca /path/to/ca.pem --ssl-cert /path/to/client-cert.pem --ssl-key /path/to/client-key.pem diff --git a/dm/dm-export-import-config.md b/dm/dm-export-import-config.md index 4065efc818b30..fb0ff087bd6fa 100644 --- a/dm/dm-export-import-config.md +++ b/dm/dm-export-import-config.md @@ -3,7 +3,7 @@ title: Export and Import Data Sources and Task Configuration of Clusters summary: DM を使用するときに、データ ソースとクラスターのタスク構成をエクスポートおよびインポートする方法を学習します。 --- -# データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション {#export-and-import-data-sources-and-task-configuration-of-clusters} +# データソースのエクスポートとインポート、およびクラスターのタスク設定 {#export-and-import-data-sources-and-task-configuration-of-clusters} `config`コマンドは、クラスターのデータ ソースとタスク構成をエクスポートおよびインポートするために使用されます。 diff --git a/dm/dm-faq.md b/dm/dm-faq.md index 4a10484d3ba95..6308dec0e1093 100644 --- a/dm/dm-faq.md +++ b/dm/dm-faq.md @@ -123,7 +123,7 @@ MySQLはエクスポート時にスナップショットを指定できないた 以下のパラメータをデフォルトの 67108864 (64M) より大きい値に設定します。 - TiDBサーバーのグローバル変数: `max_allowed_packet` 。 -- タスク設定ファイル内の設定項目： `target-database.max-allowed-packet` 。詳細は[DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 +- タスク設定ファイル内の設定項目： `target-database.max-allowed-packet` 。詳細は[DM 高度なタスク設定ファイル](/dm/task-configuration-file-full.md)を参照してください。 ## DM 1.0 クラスターの既存の DM 移行タスクが DM 2.0 以降のクラスターで実行されているときに発生するエラーError 1054: Unknown column 'binlog_gtid' in 'field list'を処理する方法を教えてください。 {#how-to-handle-the-error-code-error-1054-unknown-column-binlog-gtid-in-field-list-code-that-occurs-when-existing-dm-migration-tasks-of-an-dm-1-0-cluster-are-running-on-a-dm-2-0-or-newer-cluster} diff --git a/dm/dm-generate-self-signed-certificates.md b/dm/dm-generate-self-signed-certificates.md index b0c9d600913a6..ae43730f61f50 100644 --- a/dm/dm-generate-self-signed-certificates.md +++ b/dm/dm-generate-self-signed-certificates.md @@ -58,7 +58,7 @@ summary: openssl` を使用して自己署名証明書を生成します。 ## 個々のコンポーネントの証明書を発行する {#issue-certificates-for-individual-components} -### クラスタで使用される可能性のある証明書 {#certificates-that-might-be-used-in-the-cluster} +### クラスターで使用される可能性のある証明書 {#certificates-that-might-be-used-in-the-cluster} - DM-master が他のコンポーネントに対して DM-master を認証するために使用する`master`証明書。 - DM-worker が他のコンポーネントに対して DM-worker を認証するために使用する`worker`証明書。 @@ -86,7 +86,7 @@ DM マスター インスタンスに証明書を発行するには、次の手 find / -name openssl.cnf ``` -3. `openssl.cnf`編集し、 `[ req ]`フィールドに`req_extensions = v3_req`を追加し、 `[ v3_req ]`フィールドに`subjectAltName = @alt_names`追加します。最後に、新しいフィールドを作成し、上記のクラスタトポロジの説明に従って`Subject Alternative Name` (SAN) の情報を編集します。 +3. `openssl.cnf`編集し、 `[ req ]`フィールドに`req_extensions = v3_req`を追加し、 `[ v3_req ]`フィールドに`subjectAltName = @alt_names`追加します。最後に、新しいフィールドを作成し、上記のクラスタートポロジの説明に従って`Subject Alternative Name` (SAN) の情報を編集します。 [ alt_names ] IP.1 = 127.0.0.1 diff --git a/dm/dm-handle-alerts.md b/dm/dm-handle-alerts.md index a95f3a81a9ebc..343855bfd615b 100644 --- a/dm/dm-handle-alerts.md +++ b/dm/dm-handle-alerts.md @@ -80,7 +80,7 @@ summary: DM 内のアラート情報を処理する方法を理解します。 [DMのトラブルシューティング](/dm/dm-error-handling.md#troubleshooting)を参照してください。 -### DM_remain_storage_of_relay_log {#code-dm-remain-storage-of-relay-log-code} +### DM_remain_ストレージ_of_relay_log {#code-dm-remain-ストレージ-of-relay-log-code} - 説明： diff --git a/dm/dm-hardware-and-software-requirements.md b/dm/dm-hardware-and-software-requirements.md index 4933893ed7955..a9aa7cbba832c 100644 --- a/dm/dm-hardware-and-software-requirements.md +++ b/dm/dm-hardware-and-software-requirements.md @@ -22,7 +22,7 @@ DMは、64ビット汎用ハードウェアサーバープラットフォーム ### 開発およびテスト環境 {#development-and-test-environments} -| 成分 | CPU | メモリ | ローカルストレージ | ネットワーク | インスタンス数（最小要件） | +| コンポーネント | CPU | メモリ | ローカルストレージ | ネットワーク | インスタンス数（最小要件） | | ------ | ----- | ------ | ---------------------------- | -------------- | --------------------- | | DMマスター | 4コア以上 | 8GB以上 | SAS、200 GB以上 | ギガビットネットワークカード | 1 | | DMワーカー | 8コア以上 | 16GB以上 | SAS、200 GB以上（移行データのサイズより大きい） | ギガビットネットワークカード | アップストリームMySQLインスタンスの数 | @@ -30,13 +30,13 @@ DMは、64ビット汎用ハードウェアサーバープラットフォーム > **注記：** > > - テスト環境では、機能検証に使用する DM-master と DM-worker を同じサーバー上に配置できます。 -> - パフォーマンス テスト結果の精度を損なわないようにするために、低パフォーマンスのstorageおよびネットワーク ハードウェア構成を使用することは**お勧めしません**。 +> - パフォーマンス テスト結果の精度を損なわないようにするために、低パフォーマンスのストレージおよびネットワーク ハードウェア構成を使用することは**お勧めしません**。 > - 機能の検証のみが必要な場合は、DMマスターを1台のマシンにデプロイできます。デプロイするDMワーカーの数は、上流のMySQLインスタンスの数以上である必要があります。高可用性を確保するには、より多くのDMワーカーをデプロイすることをお勧めします。 > - DM-workerはフェーズ`dump`とフェーズ`load`で全データを保存します。そのため、DM-workerのディスク容量は、移行するデータの総量よりも大きくする必要があります。移行タスクでリレーログが有効になっている場合、DM-workerは上流のbinlogデータを保存するために追加のディスク容量を必要とします。 ### 生産環境 {#production-environment} -| 成分 | CPU | メモリ | ハードディスクの種類 | ネットワーク | インスタンス数（最小要件） | +| コンポーネント | CPU | メモリ | ハードディスクの種類 | ネットワーク | インスタンス数（最小要件） | | ------ | ------ | ------- | ---------------------------- | ---------------- | --------------------------- | | DMマスター | 4コア以上 | 8GB以上 | SAS、200 GB以上 | ギガビットネットワークカード | 3 | | DMワーカー | 16コア以上 | 32 GB以上 | SSD、200 GB以上（移行データのサイズより大きい） | 10ギガビットネットワークカード | アップストリームのMySQLインスタンスの数より大きい | @@ -45,11 +45,11 @@ DMは、64ビット汎用ハードウェアサーバープラットフォーム > **注記：** > > - 本番環境では、DM-master と DM-worker を同じサーバーに導入して実行することは推奨されません。DM-worker がディスクにデータを書き込むと、DM-master の高可用性コンポーネントによるディスクの使用が妨げられる可能性があるためです。 -> - パフォーマンスの問題が発生した場合は、ドキュメント[DMのコンフィグレーションを最適化する](/dm/dm-tune-configuration.md)に従ってタスク設定ファイルを変更することをお勧めします。設定ファイルを調整してもパフォーマンスが効果的に最適化されない場合は、サーバーのハードウェアをアップグレードしてみてください。 +> - パフォーマンスの問題が発生した場合は、ドキュメント[DMの設定を最適化する](/dm/dm-tune-configuration.md)に従ってタスク設定ファイルを変更することをお勧めします。設定ファイルを調整してもパフォーマンスが効果的に最適化されない場合は、サーバーのハードウェアをアップグレードしてみてください。 -## 下流のstorageスペース要件 {#downstream-storage-space-requirements} +## 下流のストレージスペース要件 {#downstream-ストレージ-space-requirements} -ターゲットTiKVクラスターには、インポートしたデータを保存するための十分なディスク容量が必要です。1 に加え[標準的なハードウェア要件](/hardware-and-software-requirements.md) 、ターゲットTiKVクラスターのstorage容量**は、データソースのサイズ × レプリカ数 × 2**よりも大きくなければなりません。例えば、クラスターがデフォルトで3つのレプリカを使用する場合、ターゲットTiKVクラスターには、データソースのサイズの6倍よりも大きなstorage容量が必要です。式に`x 2`含まれているのは、以下の理由からです。 +ターゲットTiKVクラスターには、インポートしたデータを保存するための十分なディスク容量が必要です。1 に加え[標準的なハードウェア要件](/hardware-and-software-requirements.md) 、ターゲットTiKVクラスターのストレージ容量**は、データソースのサイズ × レプリカ数 × 2**よりも大きくなければなりません。例えば、クラスターがデフォルトで3つのレプリカを使用する場合、ターゲットTiKVクラスターには、データソースのサイズの6倍よりも大きなストレージ容量が必要です。式に`x 2`含まれているのは、以下の理由からです。 - インデックスは余分なスペースを占める可能性があります。 - RocksDB には空間増幅効果があります。 diff --git a/dm/dm-manage-schema.md b/dm/dm-manage-schema.md index 648bc3ac07e2e..d439ae2ef9d95 100644 --- a/dm/dm-manage-schema.md +++ b/dm/dm-manage-schema.md @@ -30,7 +30,7 @@ DMが増分レプリケーションを実行する際、まず上流のbinlogを ほとんどの場合、前述の 4 つのテーブル スキーマは一貫しています。 -上流データベースがテーブルスキーマを変更するDDL操作を実行すると、 `schema-U`変更されます。このDDL操作を内部スキーマトラッカーコンポーネントと下流TiDBクラスタに適用することで、DMは`schema-I`と`schema-D`順序正しく更新し、 `schema-U`との整合性を維持します。これにより、DMは`schema-B`テーブルスキーマに対応するbinlogイベントを正常に処理できます。つまり、DDL操作`schema-B`正常に移行された後も、 `schema-U` `schema-I`および`schema-D`整合性を維持します。 +上流データベースがテーブルスキーマを変更するDDL操作を実行すると、 `schema-U`変更されます。このDDL操作を内部スキーマトラッカーコンポーネントと下流TiDBクラスターに適用することで、DMは`schema-I`と`schema-D`順序正しく更新し、 `schema-U`との整合性を維持します。これにより、DMは`schema-B`テーブルスキーマに対応するbinlogイベントを正常に処理できます。つまり、DDL操作`schema-B`正常に移行された後も、 `schema-U` `schema-I`および`schema-D`整合性を維持します。 不整合が発生する可能性がある次の状況に注意してください。 diff --git a/dm/dm-manage-source.md b/dm/dm-manage-source.md index dc6525d105058..bed7f5dc18e61 100644 --- a/dm/dm-manage-source.md +++ b/dm/dm-manage-source.md @@ -61,7 +61,7 @@ help operate-source operate-source create ./source.yaml ``` -`source.yaml`の設定については[アップストリームデータベースコンフィグレーションファイルの概要](/dm/dm-source-configuration-file.md)を参照してください。 +`source.yaml`の設定については[アップストリームデータベース設定ファイルの概要](/dm/dm-source-configuration-file.md)を参照してください。 返される結果の例を次に示します。 diff --git a/dm/dm-master-configuration-file.md b/dm/dm-master-configuration-file.md index 5061928a2adfb..8075f66505c0f 100644 --- a/dm/dm-master-configuration-file.md +++ b/dm/dm-master-configuration-file.md @@ -3,11 +3,11 @@ title: DM-master Configuration File summary: DM-master の設定ファイルについて説明します。 --- -# DMマスターコンフィグレーションファイル {#dm-master-configuration-file} +# DMマスター設定ファイル {#dm-master-configuration-file} このドキュメントでは、構成ファイル テンプレートと、このファイル内の各構成パラメータの説明を含む、DM-master の構成について説明します。 -## コンフィグレーションファイルテンプレート {#configuration-file-template} +## 設定ファイルテンプレート {#configuration-file-template} 以下は DM-master の設定ファイル テンプレートです。 @@ -38,7 +38,7 @@ cert-allowed-cn = ["dm"] secret-key-path = "/path/to/secret/key" ``` -## コンフィグレーションパラメータ {#configuration-parameters} +## 設定パラメータ {#configuration-parameters} このセクションでは、DM マスターの構成パラメータについて説明します。 diff --git a/dm/dm-overview.md b/dm/dm-overview.md index 4fa3af0711d44..e218f04f59046 100644 --- a/dm/dm-overview.md +++ b/dm/dm-overview.md @@ -19,7 +19,7 @@ summary: データ移行ツール、そのアーキテクチャ、主要コン - **DMLおよびDDLイベントの複製。MySQL**binlog内のDMLおよびDDLイベントの解析と複製をサポートします。 - **MySQLシャードの移行とマージ。DM**は、複数のMySQLデータベースインスタンスを上流から下流の1つのTiDBデータベースに移行およびマージすることをサポートします。さまざまな移行シナリオに合わせてレプリケーションルールをカスタマイズできます。上流のMySQLシャードのDDL変更を自動的に検出して処理できるため、運用コストを大幅に削減できます。 - **さまざまな種類のフィルタ。**イベントタイプ、正規表現、SQL式を事前に定義することで、データ移行プロセス中にMySQLbinlogイベントをフィルタリングできます。 -- **集中管理。DM**はクラスタ内の数千ノードをサポートし、多数のデータ移行タスクを同時に実行および管理できます。 +- **集中管理。DM**はクラスター内の数千ノードをサポートし、多数のデータ移行タスクを同時に実行および管理できます。 - **サードパーティのオンラインスキーマ変更プロセスの最適化。MySQL**エコシステムでは、gh-ostやpt-oscなどのツールが広く使用されています。DMは、中間データの不要な移行を回避するために変更プロセスを最適化します。詳細は、[オンラインDDL](/dm/dm-online-ddl-tool-support.md)参照してください。 - **高可用性。DM**は、データ移行タスクを異なるノードに自由にスケジュールすることをサポートします。少数のノードがクラッシュしても、実行中のタスクには影響しません。 @@ -55,7 +55,7 @@ DMツールを使用する前に、以下の制限事項にご注意ください - DM は、互換性のない DDL ステートメントが発生するとエラーを報告します。このエラーを解決するには、dmctl を使用して手動で処理し、この DDL ステートメントをスキップするか、指定された DDL ステートメントに置き換える必要があります。詳細については、 [異常な SQL ステートメントをスキップまたは置換します](/dm/dm-faq.md#how-to-handle-incompatible-ddl-statements)参照してください。 - - DMは、ビュー関連のDDLステートメントおよびDMLステートメントをダウンストリームのTiDBクラスタに複製しません。ダウンストリームのTiDBクラスタでビューを手動で作成することをお勧めします。 + - DMは、ビュー関連のDDLステートメントおよびDMLステートメントをダウンストリームのTiDBクラスターに複製しません。ダウンストリームのTiDBクラスターでビューを手動で作成することをお勧めします。 - GBK文字セットとの互換性 diff --git a/dm/dm-performance-test.md b/dm/dm-performance-test.md index 9877176f15e49..138bb77d0be06 100644 --- a/dm/dm-performance-test.md +++ b/dm/dm-performance-test.md @@ -3,7 +3,7 @@ title: DM Cluster Performance Test summary: DM クラスターのパフォーマンスをテストする方法を学びます。 --- -# DMクラスタパフォーマンステスト {#dm-cluster-performance-test} +# DMクラスターパフォーマンステスト {#dm-cluster-performance-test} このドキュメントでは、データ移行に関する速度テストやレイテンシーテストなど、DM クラスターでパフォーマンス テストを実行するためのテスト シナリオの構築方法について説明します。 diff --git a/dm/dm-source-configuration-file.md b/dm/dm-source-configuration-file.md index 3462e5e1f55ed..b5e4357d2300a 100644 --- a/dm/dm-source-configuration-file.md +++ b/dm/dm-source-configuration-file.md @@ -3,11 +3,11 @@ title: Upstream Database Configuration File of TiDB Data Migration summary: アップストリームデータベースの設定ファイルを学ぶ --- -# TiDB データ移行の上流データベースコンフィグレーションファイル {#upstream-database-configuration-file-of-tidb-data-migration} +# TiDB データ移行の上流データベース設定ファイル {#upstream-database-configuration-file-of-tidb-data-migration} このドキュメントでは、アップストリーム データベースの構成ファイルについて紹介します。これには、構成ファイル テンプレートと、このファイル内の各構成パラメータの説明が含まれます。 -## コンフィグレーションファイルテンプレート {#configuration-file-template} +## 設定ファイルテンプレート {#configuration-file-template} 以下は、アップストリーム データベースの構成ファイル テンプレートです。 @@ -59,7 +59,7 @@ from: > > DM v2.0.1では、 `enable-gtid`と`enable-relay`を同時に`true`に設定しないでください。そうしないと、増分データが失われる可能性があります。 -## コンフィグレーションパラメータ {#configuration-parameters} +## 設定パラメータ {#configuration-parameters} このセクションでは、構成ファイル内の各構成パラメータについて説明します。 diff --git a/dm/dm-task-configuration-guide.md b/dm/dm-task-configuration-guide.md index 107acec680a80..db73e6caeadc6 100644 --- a/dm/dm-task-configuration-guide.md +++ b/dm/dm-task-configuration-guide.md @@ -3,7 +3,7 @@ title: Data Migration Task Configuration Guide summary: Data Migration (DM) でデータ移行タスクを構成する方法を学習します。 --- -# データ移行タスクコンフィグレーションガイド {#data-migration-task-configuration-guide} +# データ移行タスク設定ガイド {#data-migration-task-configuration-guide} このドキュメントでは、Data Migration (DM) でデータ移行タスクを構成する方法について説明します。 @@ -29,7 +29,7 @@ mysql-instances: - source-id: "mysql-replica-02" # Migrate data from the data source whose `source-id` is `mysql-replica-02`. ``` -## ダウンストリームTiDBクラスタを構成する {#configure-the-downstream-tidb-cluster} +## ダウンストリームTiDBクラスターを構成する {#configure-the-downstream-tidb-cluster} 次の例`target-database`は、データ移行タスクの移行先となるターゲット TiDB クラスターを構成する方法を示しています。 diff --git a/dm/dm-tune-configuration.md b/dm/dm-tune-configuration.md index 3f795f71a494c..9e1e9748f8475 100644 --- a/dm/dm-tune-configuration.md +++ b/dm/dm-tune-configuration.md @@ -3,7 +3,7 @@ title: Optimize Configuration of DM summary: データ移行タスクの構成を最適化して、データ移行のパフォーマンスを向上させる方法を学習します。 --- -# DMのコンフィグレーションを最適化する {#optimize-configuration-of-dm} +# DMの設定を最適化する {#optimize-configuration-of-dm} このドキュメントでは、データ移行タスクの構成を最適化して、データ移行のパフォーマンスを向上させる方法を紹介します。 diff --git a/dm/dm-webui-guide.md b/dm/dm-webui-guide.md index 8f51a1a3881a5..0f107c7b539a4 100644 --- a/dm/dm-webui-guide.md +++ b/dm/dm-webui-guide.md @@ -16,12 +16,12 @@ DM WebUIは、TiDBデータ移行（DM）タスクを管理するためのWebベ DM WebUI には次のページがあります。 -- **移住** +- **移行** - **タスク**: タスク作成のエントリを提供し、各移行タスクの詳細情報を表示します。このページでは、移行タスクの監視、作成、削除、および設定を行うことができます。 - **ソース**: 移行タスクのアップストリームデータソースの情報を設定します。このページでは、アップストリーム設定の作成と削除、アップストリーム設定に対応するタスクステータスの監視、アップストリーム設定の変更など、データ移行環境におけるアップストリーム設定を管理できます。 - **レプリケーション詳細**：移行タスクの詳細なステータス情報を表示します。このページでは、指定したフィルターに基づいて、上流および下流の構成情報やデータベース名、ソーステーブルとターゲットテーブルの関係など、詳細な構成情報とステータス情報を確認できます。 -- **クラスタ** - - **メンバー**：DMクラスタ内のすべてのマスターノードとワーカーノードのリスト、およびワーカーノードとソースノード間のバインディング関係を表示します。このページでは、現在のDMクラスタの構成情報と各ワーカーのステータス情報を確認できます。また、基本的な管理機能もこのページで提供されます。 +- **クラスター** + - **メンバー**：DMクラスター内のすべてのマスターノードとワーカーノードのリスト、およびワーカーノードとソースノード間のバインディング関係を表示します。このページでは、現在のDMクラスターの構成情報と各ワーカーのステータス情報を確認できます。また、基本的な管理機能もこのページで提供されます。 インターフェースは次のとおりです。 @@ -31,7 +31,7 @@ DM WebUI には次のページがあります。 [オープンAPI](/dm/dm-open-api.md#maintain-dm-clusters-using-openapi)有効にすると、DM クラスターの任意のマスターノードからDM WebUIにアクセスできます。アクセスポートはデフォルトで`8261`で、DM OpenAPI のポートと同じです。アクセスアドレスの例： `http://{master_ip}:{master_port}/dashboard/` 。 -## 移住 {#migration} +## 移行 {#migration} **移行には**、**ソース**、**タスク**、および**レプリケーションの詳細**ページが含まれます。 @@ -66,7 +66,7 @@ DMでは、移行タスクの各サブタスクは、フルダンプ -> フ クエリ結果には、アップストリーム テーブルとダウンストリーム テーブルの対応する情報が含まれるため、クエリ結果が多すぎるとページの応答が遅くなる可能性があるため、 `.*`使用するときは注意してください。 -## クラスタ {#cluster} +## クラスター {#cluster} ### メンバー {#members} diff --git a/dm/dm-worker-configuration-file.md b/dm/dm-worker-configuration-file.md index 73ecc921f2555..95d2bbbe35baf 100644 --- a/dm/dm-worker-configuration-file.md +++ b/dm/dm-worker-configuration-file.md @@ -3,11 +3,11 @@ title: DM-worker Configuration File summary: DM-worker の設定ファイルについて学習します。 --- -# DMワーカーコンフィグレーションファイル {#dm-worker-configuration-file} +# DMワーカー設定ファイル {#dm-worker-configuration-file} このドキュメントでは、構成ファイル テンプレートと、このファイル内の各構成パラメータの説明を含む、DM ワーカーの構成について説明します。 -## コンフィグレーションファイルテンプレート {#configuration-file-template} +## 設定ファイルテンプレート {#configuration-file-template} 以下は、DM ワーカーの構成ファイル テンプレートです。 @@ -34,7 +34,7 @@ ssl-key = "/path/to/key.pem" cert-allowed-cn = ["dm"] ``` -## コンフィグレーションパラメータ {#configuration-parameters} +## 設定パラメータ {#configuration-parameters} ### グローバル {#global} diff --git a/dm/dm-worker-intro.md b/dm/dm-worker-intro.md index a756e38bf80ad..258caaebba44d 100644 --- a/dm/dm-worker-intro.md +++ b/dm/dm-worker-intro.md @@ -10,7 +10,7 @@ DM-worker は、MySQL/MariaDB から TiDB にデータを移行するために 以下の機能があります: - 任意のMySQLまたはMariaDBインスタンスのセカンダリデータベースとして機能します -- MySQL/MariaDBからbinlogイベントを読み取り、ローカルstorageに保存します。 +- MySQL/MariaDBからbinlogイベントを読み取り、ローカルストレージに保存します。 - 単一の DM ワーカーは、1 つの MySQL/MariaDB インスタンスのデータを複数の TiDB インスタンスに移行することをサポートします。 - 複数の DM ワーカーは、複数の MySQL/MariaDB インスタンスのデータを 1 つの TiDB インスタンスに移行することをサポートします。 diff --git a/dm/dmctl-introduction.md b/dm/dmctl-introduction.md index cd4a3928c3bb8..893bd289322dd 100644 --- a/dm/dmctl-introduction.md +++ b/dm/dmctl-introduction.md @@ -9,7 +9,7 @@ summary: dmctl を使用して DM クラスターを保守する方法を学習 > > TiUPを使用してデプロイされた DM クラスターの場合は、クラスターを維持するために[`tiup dmctl`](/dm/maintain-dm-using-tiup.md#dmctl)直接使用することをお勧めします。 -dmctl は、DM クラスタのメンテナンスに使用するコマンドラインツールです。対話モードとコマンドモードの両方をサポートしています。 +dmctl は、DM クラスターのメンテナンスに使用するコマンドラインツールです。対話モードとコマンドモードの両方をサポートしています。 ## インタラクティブモード {#interactive-mode} diff --git a/dm/feature-shard-merge-optimistic.md b/dm/feature-shard-merge-optimistic.md index 995a0fda21975..112b96b431889 100644 --- a/dm/feature-shard-merge-optimistic.md +++ b/dm/feature-shard-merge-optimistic.md @@ -19,9 +19,9 @@ DMは、シャーディングDDLと呼ばれるシャーディングテーブル そのため、「楽観的モード」が必要になります。このモードでは、シャードテーブルに対して実行されたDDL文は、他のシャードテーブルと互換性のある文に自動的に変換され、すぐに下流に移行されます。これにより、DDL文がシャードテーブルによるDML移行の実行をブロックすることはありません。 -## 楽観的モードのコンフィグレーション {#configuration-of-the-optimistic-mode} +## 楽観的モードの設定 {#configuration-of-the-optimistic-mode} -楽観的モードを使用するには、タスク設定ファイルの`shard-mode`項目を`optimistic`に指定します。5 `strict-optimistic-shard-mode`の設定を有効にすると、楽観的モードの動作を制限できます。詳細なサンプル設定ファイルについては、 [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)参照してください。 +楽観的モードを使用するには、タスク設定ファイルの`shard-mode`項目を`optimistic`に指定します。5 `strict-optimistic-shard-mode`の設定を有効にすると、楽観的モードの動作を制限できます。詳細なサンプル設定ファイルについては、 [DM 高度なタスク設定ファイル](/dm/task-configuration-file-full.md)参照してください。 ## 制限 {#restrictions} diff --git a/dm/feature-shard-merge-pessimistic.md b/dm/feature-shard-merge-pessimistic.md index a93fbe0991e4e..ba5b5166eb0e6 100644 --- a/dm/feature-shard-merge-pessimistic.md +++ b/dm/feature-shard-merge-pessimistic.md @@ -99,7 +99,7 @@ sequenceDiagram 複数のDMワーカー間でシャーディングDDL移行を処理するDMの特性は、以下のようにまとめられます。 -- タスク構成とDMクラスタ展開トポロジ情報に基づいて、DDL移行を調整するための論理シャーディンググループ`DM-master`に構築されます。グループメンバーは、移行タスクから分割された各サブタスクを処理するDMワーカーです。 +- タスク構成とDMクラスター展開トポロジ情報に基づいて、DDL移行を調整するための論理シャーディンググループ`DM-master`に構築されます。グループメンバーは、移行タスクから分割された各サブタスクを処理するDMワーカーです。 - binlogイベントから DDL ステートメントを受け取った後、各 DM-worker は DDL 情報を`DM-master`に送信します。 - `DM-master`各 DM-worker から受信した DDL 情報とシャーディング グループ情報に基づいて、DDL ロックを作成または更新します。 - シャーディンググループのすべてのメンバーが同じ特定のDDLステートメントを受信した場合、これは、アップストリームのシャーディングされたテーブルでのDDL実行前のすべてのDMLステートメントが完全に移行されたことを示しており、このDDLステートメントを実行できます。その後、DMは後続のDMLステートメントの移行を続行できます。 diff --git a/dm/maintain-dm-using-tiup.md b/dm/maintain-dm-using-tiup.md index a287f9d509a29..f6f2d0c4281b6 100644 --- a/dm/maintain-dm-using-tiup.md +++ b/dm/maintain-dm-using-tiup.md @@ -3,11 +3,11 @@ title: Maintain a DM Cluster Using TiUP summary: TiUPを使用して DM クラスターを保守する方法を学びます。 --- -# TiUPを使用して DMクラスタを管理 {#maintain-a-dm-cluster-using-tiup} +# TiUPを使用して DMクラスターを管理 {#maintain-a-dm-cluster-using-tiup} このドキュメントでは、TiUP DMコンポーネントを使用して DM クラスターを保守する方法について説明します。 -DM クラスターをまだ展開していない場合は、手順[TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)を参照してください。 +DM クラスターをまだ展開していない場合は、手順[TiUPを使用して DMクラスターをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)を参照してください。 > **注記：** > @@ -67,7 +67,7 @@ tiup dm list Name User Version Path PrivateKey ---- ---- ------- ---- ---------- - prod-cluster tidb ${version} /root/.tiup/storage/dm/clusters/test /root/.tiup/storage/dm/clusters/test/ssh/id_rsa + prod-cluster tidb ${version} /root/.tiup/ストレージ/dm/clusters/test /root/.tiup/ストレージ/dm/clusters/test/ssh/id_rsa ## クラスターを起動する {#start-the-cluster} @@ -81,7 +81,7 @@ tiup dm start prod-cluster ## クラスターのステータスを確認する {#check-the-cluster-status} -TiUPは、クラスタ内の各コンポーネントのステータスを表示するためのコマンド`tiup dm display`を提供しています。このコマンドを使用すると、コンポーネントのステータスを確認するために各マシンにログインする必要がなくなります。コマンドの使用方法は次のとおりです。 +TiUPは、クラスター内の各コンポーネントのステータスを表示するためのコマンド`tiup dm display`を提供しています。このコマンドを使用すると、コンポーネントのステータスを確認するために各マシンにログインする必要がなくなります。コマンドの使用方法は次のとおりです。 ```bash tiup dm display prod-cluster @@ -161,7 +161,7 @@ tiup dm scale-in prod-cluster -N 172.16.5.140:8262 > **注記：** > -> v2.0.5 以降、dmctl は[データソースのエクスポートとインポート、およびクラスターのタスクコンフィグレーション](/dm/dm-export-import-config.md)サポートします。 +> v2.0.5 以降、dmctl は[データソースのエクスポートとインポート、およびクラスターのタスク設定](/dm/dm-export-import-config.md)サポートします。 > > アップグレード前に、 `config export`使用してクラスターの設定ファイルをエクスポートできます。アップグレード後に以前のバージョンにダウングレードする必要がある場合は、まず以前のクラスターを再デプロイし、 `config import`使用して以前の設定ファイルをインポートできます。 > @@ -173,7 +173,7 @@ tiup dm scale-in prod-cluster -N 172.16.5.140:8262 ### アップグレードコマンド {#upgrade-command} -DMクラスタをアップグレードするには、コマンド`tiup dm upgrade`を実行します。例えば、次のコマンドはクラスタを`${version}`にアップグレードします。このコマンドを実行する前に、 `${version}`必要なバージョンに変更してください。 +DMクラスターをアップグレードするには、コマンド`tiup dm upgrade`を実行します。例えば、次のコマンドはクラスターを`${version}`にアップグレードします。このコマンドを実行する前に、 `${version}`必要なバージョンに変更してください。 > **注記：** > @@ -185,7 +185,7 @@ tiup dm upgrade prod-cluster ${version} ## 構成の更新 {#update-configuration} -コンポーネント構成を動的に更新する場合、 TiUP DMコンポーネントは各クラスタの現在の構成を保存します。この構成を編集するには、 `tiup dm edit-config `コマンドを実行します。例： +コンポーネント構成を動的に更新する場合、 TiUP DMコンポーネントは各クラスターの現在の構成を保存します。この構成を編集するには、 `tiup dm edit-config `コマンドを実行します。例： ```bash tiup dm edit-config prod-cluster @@ -246,7 +246,7 @@ tiup dm patch prod-cluster /tmp/dm--hotfix.tar.gz -N 172.16.4.5:8261 > - 2.0 にアップグレードする必要があるタスクでは`stop-task`実行しないでください。 > - TiUP は、v2.0.0-rc.2 以降のバージョンの DM クラスターへのインポートのみをサポートします。 > - `import`コマンドは、DM 1.0 クラスターから新しい DM 2.0 クラスターにデータをインポートするために使用されます。既存の DM 2.0 クラスターに DM 移行タスクをインポートする必要がある場合は、 [TiDB データ移行を v1.0.x から v2.0+ に手動でアップグレードする](/dm/manually-upgrade-dm-1.0-to-2.0.md)参照してください。 -> - 一部のコンポーネントのデプロイメントディレクトリは、元のクラスタのものと異なります。詳細を確認するには、 `display`コマンドを実行してください。 +> - 一部のコンポーネントのデプロイメントディレクトリは、元のクラスターのものと異なります。詳細を確認するには、 `display`コマンドを実行してください。 > - インポートする前に`tiup update --self && tiup update dm`実行して、 TiUP DMコンポーネントが最新バージョンであることを確認します。 > - インポート後、クラスターにはDMマスターノードが1つだけ存在します。DMマスターをスケールアウトするには、 [クラスターをスケールアウトする](#scale-out-a-cluster)を参照してください。 @@ -299,7 +299,7 @@ tiup dm audit 4D5kQY ## DM クラスター内のホストでコマンドを実行する {#run-commands-on-a-host-in-the-dm-cluster} -DMクラスタ内のホストでコマンドを実行するには、 `exec`コマンドを使用します。3 `exec`のコマンドの使用方法は次のとおりです。 +DMクラスター内のホストでコマンドを実行するには、 `exec`コマンドを使用します。3 `exec`のコマンドの使用方法は次のとおりです。 ```bash Usage: @@ -321,7 +321,7 @@ tiup dm exec prod-cluster --command='ls /tmp' ## dmctl {#dmctl} -TiUP はDM クラスタ コントローラ`dmctl`を統合します。 +TiUP はDM クラスター コントローラ`dmctl`を統合します。 dmctl を使用するには、次のコマンドを実行します。 @@ -339,9 +339,9 @@ dmctlのバージョンを指定します。このコマンドを実行する前 tiup dmctl --master-addr master1:8261 operate-source create /tmp/source1.yml ``` -## システムのネイティブSSHクライアントを使用してクラスタに接続します {#use-the-system-s-native-ssh-client-to-connect-to-cluster} +## システムのネイティブSSHクライアントを使用してクラスターに接続します {#use-the-system-s-native-ssh-client-to-connect-to-cluster} -クラスタマシン上で実行される上記のすべての操作は、 TiUPに組み込まれたSSHクライアントを使用してクラスタに接続し、コマンドを実行します。ただし、シナリオによっては、制御マシンシステムにネイティブなSSHクライアントを使用してクラスタ操作を実行する必要がある場合もあります。例： +クラスターマシン上で実行される上記のすべての操作は、 TiUPに組み込まれたSSHクライアントを使用してクラスターに接続し、コマンドを実行します。ただし、シナリオによっては、制御マシンシステムにネイティブなSSHクライアントを使用してクラスター操作を実行する必要がある場合もあります。例： - 認証にSSHプラグインを使用するには - カスタマイズされたSSHクライアントを使用するには diff --git a/dm/manually-upgrade-dm-1.0-to-2.0.md b/dm/manually-upgrade-dm-1.0-to-2.0.md index e406169fffcd3..5bd2607c46db8 100644 --- a/dm/manually-upgrade-dm-1.0-to-2.0.md +++ b/dm/manually-upgrade-dm-1.0-to-2.0.md @@ -5,15 +5,15 @@ summary: TiDBデータ移行をv1.0.xからv2.0+へ手動でアップグレー # TiDBデータ移行をv1.0.xからv2.0+へ手動でアップグレードする {#manually-upgrade-tidb-data-migration-from-v1-0-x-to-v2-0} -このドキュメントでは、TiDB DMツールをv1.0.xからv2.0+に手動でアップグレードする方法について説明します。主な手順は、v1.0.xのグローバルチェックポイント情報を使用して、v2.0+クラスタで新しいデータ移行タスクを開始することです。 +このドキュメントでは、TiDB DMツールをv1.0.xからv2.0+に手動でアップグレードする方法について説明します。主な手順は、v1.0.xのグローバルチェックポイント情報を使用して、v2.0+クラスターで新しいデータ移行タスクを開始することです。 TiDB DM ツールを v1.0.x から v2.0+ に自動的にアップグレードする方法については、 [TiUPを使用して、DM-Ansibleによってデプロイされた1.0クラスターを自動的にインポートする](/dm/maintain-dm-using-tiup.md#import-and-upgrade-a-dm-10-cluster-deployed-using-dm-ansible)。 > **注記：** > > - 現在、データ移行タスクが完全エクスポートまたは完全インポートの処理中の場合、DMをv1.0.xからv2.0+にアップグレードすることはサポートされていません。 -> - DMクラスタのコンポーネント間の通信に使用されるgRPCプロトコルが大幅に更新されるため、アップグレードの前後でDMコンポーネント（dmctlを含む）が同じバージョンを使用していることを確認する必要があります。 -> - DMクラスタのメタデータstorage（チェックポイント、シャードDDLロックステータス、オンラインDDLメタデータなど）が大幅に更新されるため、v1.0.xのメタデータはv2.0+で自動的に再利用できません。そのため、アップグレード操作を実行する前に、以下の要件を満たしていることを確認する必要があります。 +> - DMクラスターのコンポーネント間の通信に使用されるgRPCプロトコルが大幅に更新されるため、アップグレードの前後でDMコンポーネント（dmctlを含む）が同じバージョンを使用していることを確認する必要があります。 +> - DMクラスターのメタデータストレージ（チェックポイント、シャードDDLロックステータス、オンラインDDLメタデータなど）が大幅に更新されるため、v1.0.xのメタデータはv2.0+で自動的に再利用できません。そのため、アップグレード操作を実行する前に、以下の要件を満たしていることを確認する必要があります。 > - すべてのデータ移行タスクがシャードDDL調整プロセスに含まれるわけではありません。 > - すべてのデータ移行タスクがオンラインDDL調整プロセスに含まれているわけではありません。 @@ -108,17 +108,17 @@ from: [TiUPを使用する](/dm/deploy-a-dm-cluster-using-tiup.md)必要なノード数に応じて新しい v2.0+ クラスターをデプロイします。 -## ステップ3：v1.0.xクラスタを停止します {#step-3-stop-the-v1-0-x-cluster} +## ステップ3：v1.0.xクラスターを停止します {#step-3-stop-the-v1-0-x-cluster} -元の v1.0.x クラスターが DM-Ansible によってデプロイされている場合は、 [DM-Ansibleを使用してv1.0.xクラスタを停止します。](https://docs-archive.pingcap.com/tidb-data-migration/v1.0/cluster-operations#stop-a-cluster) 。 +元の v1.0.x クラスターが DM-Ansible によってデプロイされている場合は、 [DM-Ansibleを使用してv1.0.xクラスターを停止します。](https://docs-archive.pingcap.com/tidb-data-migration/v1.0/cluster-operations#stop-a-cluster) 。 -元のv1.0.xクラスタがバイナリでデプロイされている場合は、DM-workerプロセスとDM-masterプロセスを直接停止できます。 +元のv1.0.xクラスターがバイナリでデプロイされている場合は、DM-workerプロセスとDM-masterプロセスを直接停止できます。 ## ステップ4：データ移行タスクのアップグレード {#step-4-upgrade-data-migration-task} 1. [`operate-source`](/dm/dm-manage-source.md#operate-data-source)コマンドを使用して、アップストリーム データベース ソース構成を[ステップ1](#step-1-prepare-v20-configuration-file)から v2.0+ クラスターにロードします。 -2. 下流のTiDBクラスタでは、v1.0.xデータ移行タスクの増分チェックポイントテーブルから、対応するグローバルチェックポイント情報を取得します。 +2. 下流のTiDBクラスターでは、v1.0.xデータ移行タスクの増分チェックポイントテーブルから、対応するグローバルチェックポイント情報を取得します。 - v1.0.x データ移行構成で`meta-schema`が指定されていない（またはデフォルト値`dm_meta`として指定されている）場合、対応するタスク名が`task_v1`であると仮定すると、対応するチェックポイント情報は、ダウンストリーム TiDB の`` `dm_meta`.`task_v1_syncer_checkpoint` ``テーブルにあります。 - データ移行タスクに対応するすべての上流データベースソースのグローバルチェックポイント情報を取得するには、以下のSQL文を使用します。 diff --git a/dm/migrate-data-using-dm.md b/dm/migrate-data-using-dm.md index ba1cd9acfdd32..ad1c9e88ddba9 100644 --- a/dm/migrate-data-using-dm.md +++ b/dm/migrate-data-using-dm.md @@ -16,13 +16,13 @@ summary: データ移行ツールを使用して、全データと増分デー > - すべての DM 構成ファイルのデータベース パスワードには、 `dmctl`で暗号化されたパスワードを使用することをお勧めします。データベースのパスワードが空の場合、暗号化する必要はありません。 [dmctlを使用してデータベースのパスワードを暗号化します。](/dm/dm-manage-source.md#encrypt-the-database-password)参照してください。 > - 上流および下流データベースのユーザーは、対応する読み取り権限と書き込み権限を持っている必要があります。 -## ステップ2：クラスタ情報を確認する {#step-2-check-the-cluster-information} +## ステップ2：クラスター情報を確認する {#step-2-check-the-cluster-information} -TiUPを使用してDMクラスタをデプロイした後、構成情報は以下のようになります。 +TiUPを使用してDMクラスターをデプロイした後、構成情報は以下のようになります。 -- DMクラスタ内の関連コンポーネントの構成情報： +- DMクラスター内の関連コンポーネントの構成情報： - | 成分 | ホスト | ポート | + | コンポーネント | ホスト | ポート | | ---------- | ------------ | ---- | | dm_worker1 | 172.16.10.72 | 8262 | | dm_worker2 | 172.16.10.73 | 8262 | @@ -56,7 +56,7 @@ MySQL ホストで必要な権限のリストは[事前チェック](/dm/dm-prec port: 3306 ``` -2. ターミナルで次のコマンドを実行し、 `tiup dmctl`を使用してMySQL-1データソース構成をDMクラスタにロードします。 +2. ターミナルで次のコマンドを実行し、 `tiup dmctl`を使用してMySQL-1データソース構成をDMクラスターにロードします。 ```bash tiup dmctl --master-addr 172.16.10.71:8261 operate-source create conf/source1.yaml @@ -176,9 +176,9 @@ tiup dmctl --master-addr 172.16.10.71:8261 stop-task test ## ステップ8：タスクを監視し、ログを確認する {#step-8-monitor-the-task-and-check-logs} -TiUPを使用して DM クラスタのデプロイとともに Prometheus、Alertmanager、および Grafana が正常にデプロイされ、Grafana のアドレスが`172.16.10.71`であると仮定します。DM に関連するアラート情報を表示するには、ブラウザで[http://172.16.10.71:9093](http://172.16.10.71:9093)を開き、Alertmanager にアクセスします。監視メトリックを確認するには、 [http://172.16.10.71:3000](http://172.16.10.71:3000)にアクセスし、DM ダッシュボードを選択します。 +TiUPを使用して DM クラスターのデプロイとともに Prometheus、Alertmanager、および Grafana が正常にデプロイされ、Grafana のアドレスが`172.16.10.71`であると仮定します。DM に関連するアラート情報を表示するには、ブラウザで[http://172.16.10.71:9093](http://172.16.10.71:9093)を開き、Alertmanager にアクセスします。監視メトリックを確認するには、 [http://172.16.10.71:3000](http://172.16.10.71:3000)にアクセスし、DM ダッシュボードを選択します。 -DMクラスタの実行中、DMマスター、DMワーカー、およびdmctlは、監視メトリクス情報をログに出力します。各コンポーネントのログディレクトリは以下のとおりです。 +DMクラスターの実行中、DMマスター、DMワーカー、およびdmctlは、監視メトリクス情報をログに出力します。各コンポーネントのログディレクトリは以下のとおりです。 - DMマスターのログディレクトリ：これは`--log-file` DMマスタープロセスパラメータで指定されます。DMがTiUPを使用してデプロイされている場合、ログディレクトリはDMマスターノードの`{log_dir}`になります。 - DMワーカーのログディレクトリ：これは`--log-file` DMワーカープロセスパラメータで指定されます。DMがTiUPを使用してデプロイされている場合、ログディレクトリはDMワーカーノードの`{log_dir}`になります。 diff --git a/dm/monitor-a-dm-cluster.md b/dm/monitor-a-dm-cluster.md index 6d6e18b0e4fdd..f94322bdef8ab 100644 --- a/dm/monitor-a-dm-cluster.md +++ b/dm/monitor-a-dm-cluster.md @@ -18,8 +18,8 @@ Grafana ダッシュボードでは、DM のデフォルト名は`DM-task`です | メトリック名 | 説明 | 警告 | 重大度レベル | | :--------------------------- | :-------------------------------------------------------------------------------- | :--- | :----- | | タスク状態 | 移行のサブタスクの状態 | 該当なし | 該当なし | -| storage容量 | リレーログが占めるディスクの総storage容量 | 該当なし | 該当なし | -| storage残り | リレーログが占めるディスクの残りstorage容量 | 該当なし | 該当なし | +| ストレージ容量 | リレーログが占めるディスクの総ストレージ容量 | 該当なし | 該当なし | +| ストレージ残り | リレーログが占めるディスクの残りストレージ容量 | 該当なし | 該当なし | | マスターとリレー間のbinlogファイルのギャップ | `relay`処理ユニットが上流マスターより遅れているbinlogファイルの数 | 該当なし | 該当なし | | 読み込みの進行状況 | ロードユニットの完了したロードプロセスの割合。値は0%～100%です。 | 該当なし | 該当なし | | マスターと同期サーバー間のbinlogファイルのギャップ | binlogレプリケーションユニットが上流マスターより遅れているbinlogファイルの数 | 該当なし | 該当なし | @@ -100,7 +100,7 @@ Grafana ダッシュボードでは、DM のデフォルト名は`DM-task`です | シャードロックの解決 | 現在のサブタスクがシャードDDLロックの解決を待機しているかどうか。0より大きい値は、シャードDDLロックの解決を待機していることを示します。 | 該当なし | 該当なし | | 理想的なQPS | DMの実行時間が0のときに達成できる最高のQPS | 該当なし | 該当なし | | binlogイベント行 | binlogイベントの行数 | 該当なし | 該当なし | -| 完了した取引の合計 | 完了した取引の合計数 | 該当なし | 該当なし | +| 完了したトランザクションの合計 | 完了したトランザクションの合計数 | 該当なし | 該当なし | | レプリケーショントランザクションバッチ | 下流に実行されたトランザクション内のSQL行の数 | 該当なし | 該当なし | | フラッシュチェックポイントの時間間隔 | チェックポイントをフラッシュする時間間隔（秒） | 該当なし | 該当なし | @@ -112,8 +112,8 @@ Grafana ダッシュボードでは、DM のデフォルト名は`DM-task`です | メトリック名 | 説明 | 警告 | 重大度レベル | | :------------------------ | :------------------------------------------------------------ | :------------------------------------------------------------------------------ | :----- | -| storage容量 | リレーログが占有するディスクのstorage容量 | 該当なし | 該当なし | -| storage残り | リレーログが占有するディスクの残りstorage容量 | 値が10G未満になるとアラートが必要になります | 致命的 | +| ストレージ容量 | リレーログが占有するディスクのストレージ容量 | 該当なし | 該当なし | +| ストレージ残り | リレーログが占有するディスクの残りストレージ容量 | 値が10G未満になるとアラートが必要になります | 致命的 | | プロセスはエラーで終了しました | リレーログはDMワーカー内でエラーが発生し、終了します。 | 即時アラート | 致命的 | | リレーログデータの破損 | 破損したリレーログファイルの数 | 即時アラート | 緊急 | | マスターからのbinlogの読み取りに失敗しました | リレーログが上流のMySQLからbinlogを読み込む際に発生したエラーの数 | 即時アラート | 致命的 | @@ -133,8 +133,8 @@ Grafana ダッシュボードでは、インスタンスのデフォルト名は | メトリック名 | 説明 | 警告 | 重大度レベル | | :------------------------ | :------------------------------------------------------------ | :------------------------------------------------------------------------------ | :----- | -| storage容量 | リレーログが占有するディスクの総storage容量 | 該当なし | 該当なし | -| storage残り | リレーログが占めるディスク内の残りのstorage容量 | 値が10G未満になるとアラートが発生します | 致命的 | +| ストレージ容量 | リレーログが占有するディスクの総ストレージ容量 | 該当なし | 該当なし | +| ストレージ残り | リレーログが占めるディスク内の残りのストレージ容量 | 値が10G未満になるとアラートが発生します | 致命的 | | プロセスはエラーで終了しました | リレーログはDMワーカーでエラーが発生し、終了します | 即時アラート | 致命的 | | リレーログデータの破損 | 破損したリレーログの数 | 即時アラート | 緊急 | | マスターからのbinlogの読み取りに失敗しました | リレーログが上流のMySQLからbinlogを読み込む際に発生したエラーの数 | 即時アラート | 致命的 | diff --git a/dm/quick-start-create-source.md b/dm/quick-start-create-source.md index c5d26ac7db588..671af9535545e 100644 --- a/dm/quick-start-create-source.md +++ b/dm/quick-start-create-source.md @@ -7,7 +7,7 @@ summary: データ移行 (DM) のデータ ソースを作成する方法を学 > **注記：** > -> データ ソースを作成する前に、 [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)実行する必要があります。 +> データ ソースを作成する前に、 [TiUPを使用して DMクラスターをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)実行する必要があります。 このドキュメントでは、TiDB データ移行 (DM) のデータ移行タスク用のデータ ソースを作成する方法について説明します。 @@ -53,7 +53,7 @@ summary: データ移行 (DM) のデータ ソースを作成する方法を学 tiup dmctl --master-addr operate-source create ./source-mysql-01.yaml ``` -その他の設定パラメータについては[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)を参照してください。 +その他の設定パラメータについては[上流データベース設定ファイル](/dm/dm-source-configuration-file.md)を参照してください。 返される結果は次のとおりです。 diff --git a/dm/quick-start-create-task.md b/dm/quick-start-create-task.md index 7c8c223d4dd18..c6a6a125b562c 100644 --- a/dm/quick-start-create-task.md +++ b/dm/quick-start-create-task.md @@ -209,4 +209,4 @@ MySQL2 の場合、上記のコマンドの設定ファイルを MySQL2 の設 ## データを検証する {#verify-data} -アップストリームのMySQLシャードテーブルのデータを変更できます。その後、 [同期差分インスペクター](/sync-diff-inspector/shard-diff.md)使用して、アップストリームとダウンストリームのデータの整合性を確認します。データの整合性は、移行タスクが正常に機能していることを意味し、クラスタが正常に動作していることも示しています。 +アップストリームのMySQLシャードテーブルのデータを変更できます。その後、 [同期差分インスペクター](/sync-diff-inspector/shard-diff.md)使用して、アップストリームとダウンストリームのデータの整合性を確認します。データの整合性は、移行タスクが正常に機能していることを意味し、クラスターが正常に動作していることも示しています。 diff --git a/dm/quick-start-with-dm.md b/dm/quick-start-with-dm.md index 71ed030cc9edc..ab57b390162c1 100644 --- a/dm/quick-start-with-dm.md +++ b/dm/quick-start-with-dm.md @@ -9,11 +9,11 @@ summary: TiUP Playground を使用してデータ移行環境をすばやくセ > **注記：** > -> 本番への展開については、 [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)参照してください。 +> 本番への展開については、 [TiUPを使用して DMクラスターをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)参照してください。 ## ステップ1: テスト環境をセットアップする {#step-1-set-up-the-test-environment} -[TiUP](/tiup/tiup-overview.md)はクラスタ運用・保守ツールです。Playground機能を使用すると、開発・テスト用にTiDBデータベースとTiDB DMを備えた一時的なローカル環境を迅速に起動できます。 +[TiUP](/tiup/tiup-overview.md)はクラスター運用・保守ツールです。Playground機能を使用すると、開発・テスト用にTiDBデータベースとTiDB DMを備えた一時的なローカル環境を迅速に起動できます。 1. TiUPをインストールします: diff --git a/dm/relay-log.md b/dm/relay-log.md index 61b1093945ee3..dd83dbed66ac3 100644 --- a/dm/relay-log.md +++ b/dm/relay-log.md @@ -7,11 +7,11 @@ summary: DM リレー ログのディレクトリ構造、初期移行ルール データ移行 (DM) リレー ログは、データベースの変更を記述するイベントを含む番号付きファイルの複数のセットと、使用されたすべてのリレー ログ ファイルの名前を含むインデックス ファイルで構成されます。 -リレーログを有効にすると、DM-workerはアップストリームのbinlogをローカル設定ディレクトリに自動的に移行します（DMがTiUPを使用してデプロイされている場合、デフォルトの移行ディレクトリは`/`です）。デフォルト値は``で、 `relay-dir`に設定されていますが、 [上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)で変更できます。v5.4.0以降では、 [DMワーカー構成ファイル](/dm/dm-worker-configuration-file.md)の`relay-dir`でローカル設定ディレクトリを設定できます。これは、アップストリームデータベースの設定ファイルよりも優先されます。 +リレーログを有効にすると、DM-workerはアップストリームのbinlogをローカル設定ディレクトリに自動的に移行します（DMがTiUPを使用してデプロイされている場合、デフォルトの移行ディレクトリは`/`です）。デフォルト値は``で、 `relay-dir`に設定されていますが、 [上流データベース設定ファイル](/dm/dm-source-configuration-file.md)で変更できます。v5.4.0以降では、 [DMワーカー構成ファイル](/dm/dm-worker-configuration-file.md)の`relay-dir`でローカル設定ディレクトリを設定できます。これは、アップストリームデータベースの設定ファイルよりも優先されます。 ## ユーザーシナリオ {#user-scenarios} -MySQLではstorage容量が限られているため、最大保存期間に達するとbinlogは自動的に消去されます。上流データベースがbinlogを消去すると、DMは消去されたbinlogを取得できず、移行タスクは失敗します。移行タスクごとに、DMは上流データベースに接続を作成し、binlogを取得します。接続数が多すぎると、上流データベースの負荷が増大する可能性があります。 +MySQLではストレージ容量が限られているため、最大保存期間に達するとbinlogは自動的に消去されます。上流データベースがbinlogを消去すると、DMは消去されたbinlogを取得できず、移行タスクは失敗します。移行タスクごとに、DMは上流データベースに接続を作成し、binlogを取得します。接続数が多すぎると、上流データベースの負荷が増大する可能性があります。 リレーログを有効にすると、同じ上流データベースを持つ複数の移行タスクで、ローカルディスクにプルされたリレーログを再利用できます。これにより**、上流データベースへの負荷が軽減されます**。 @@ -37,7 +37,7 @@ MySQLではstorage容量が限られているため、最大保存期間に達 v5.4.0以降のバージョンでは、 `enable-relay`を`true`に設定することでリレーログを有効にできます。v5.4.0以降では、上流データソースをバインドする際に、DM-workerはデータソースの設定で`enable-relay`をチェックします。 `enable-relay`が`true`場合、このデータソースに対してリレーログ機能が有効になります。 -詳しい設定方法については[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)参照してください。 +詳しい設定方法については[上流データベース設定ファイル](/dm/dm-source-configuration-file.md)参照してください。 さらに、 `start-relay`または`stop-relay`コマンドを使用してデータ ソースの`enable-relay`構成を動的に調整し、リレー ログイン時間を有効または無効にすることもできます。 @@ -90,7 +90,7 @@ stop-relay -s mysql-replica-01 worker1 worker2 DM バージョン 2.0.2 より前のバージョン（v2.0.2 は含まない）では、DM ワーカーを上流データソースにバインドする際に、ソース設定ファイルの設定項目`enable-relay`チェックされます。3 `enable-relay` `true`に設定されている場合、DM はデータソースのリレーログ機能を有効にします。 -設定項目`enable-relay`設定方法については[上流データベースコンフィグレーションファイル](/dm/dm-source-configuration-file.md)参照してください。 +設定項目`enable-relay`設定方法については[上流データベース設定ファイル](/dm/dm-source-configuration-file.md)参照してください。
@@ -288,7 +288,7 @@ purge: ### ディレクトリ構造 {#directory-structure} -リレーログのローカルstorageのディレクトリ構造の例: +リレーログのローカルストレージのディレクトリ構造の例: // |-- 7e427cc0-091c-11e9-9e45-72b7c59d52d7.000001 diff --git a/dm/shard-merge-best-practices.md b/dm/shard-merge-best-practices.md index 6340310e55c18..a58328d027458 100644 --- a/dm/shard-merge-best-practices.md +++ b/dm/shard-merge-best-practices.md @@ -161,4 +161,4 @@ CREATE TABLE `tbl_multi_pk` ( ## 速度制限と交通流制御 {#speed-limits-and-traffic-flow-control} -複数の上流MySQLまたはMariaDBインスタンスから下流の同じTiDBクラスタにデータがマージされ移行されると、各上流インスタンスに対応するすべてのDMワーカーが、フルデータレプリケーションと増分データレプリケーションを同時に実行します。つまり、DMワーカーの数が増えるにつれて、デフォルトの同時実行度（フルデータ移行では`pool-size` 、増分データレプリケーションでは`worker-count` ）が蓄積され、下流データベースに過負荷がかかる可能性があります。このような場合、TiDBとDMの監視メトリクスに基づいて予備的なパフォーマンス分析を実施し、各同時実行パラメータの値を調整する必要があります。将来的には、DMは部分的に自動化されたトラフィックフロー制御をサポートする予定です。 +複数の上流MySQLまたはMariaDBインスタンスから下流の同じTiDBクラスターにデータがマージされ移行されると、各上流インスタンスに対応するすべてのDMワーカーが、フルデータレプリケーションと増分データレプリケーションを同時に実行します。つまり、DMワーカーの数が増えるにつれて、デフォルトの同時実行度（フルデータ移行では`pool-size` 、増分データレプリケーションでは`worker-count` ）が蓄積され、下流データベースに過負荷がかかる可能性があります。このような場合、TiDBとDMの監視メトリクスに基づいて予備的なパフォーマンス分析を実施し、各同時実行パラメータの値を調整する必要があります。将来的には、DMは部分的に自動化されたトラフィックフロー制御をサポートする予定です。 diff --git a/dm/task-configuration-file-full.md b/dm/task-configuration-file-full.md index d6769fd982d1a..9d46aa0e84141 100644 --- a/dm/task-configuration-file-full.md +++ b/dm/task-configuration-file-full.md @@ -3,7 +3,7 @@ title: DM Advanced Task Configuration File summary: このドキュメントでは、データ移行（DM）の高度なタスク設定ファイルについて、グローバル設定とインスタンス設定の両面から解説します。グローバル設定には基本設定と機能設定が含まれ、インスタンス設定では、上流側の1つまたは複数のMySQLインスタンスから下流側の同じインスタンスへのデータ移行のためのサブタスクを定義します。 --- -# DM 高度タスクコンフィグレーションファイル {#dm-advanced-task-configuration-file} +# DM 高度タスク設定ファイル {#dm-advanced-task-configuration-file} このドキュメントでは[インスタンス構成](#instance-configuration)[グローバル設定](#global-configuration)とインスタンス構成を含む、データ移行 (DM) の高度なタスク設定ファイルを紹介します。 @@ -239,7 +239,7 @@ mysql-instances: syncer-thread: 16 # The number of threads that the sync processing unit uses for replicating incremental data. `syncer-thread` corresponds to the `worker-count` configuration item of the syncers configuration. `syncer-thread` has overriding priority when the two items are both configured. When multiple instances are migrating data to TiDB at the same time, reduce the value according to the load. ``` -## コンフィグレーション順序 {#configuration-order} +## 設定順序 {#configuration-order} サンプル設定ファイルから、設定ファイルが`Global configuration`と`Instance configuration`の 2 つの部分から構成されていることがわかります。ここで、 `Global configuration`には`Basic configuration`と`Feature configuration set`が含まれています。設定順序は次のとおりです。 @@ -276,15 +276,15 @@ mysql-instances: #### mydumpers {#code-mydumpers-code} -- ダンプ処理ユニットのコンフィグレーション引数。デフォルト設定で要件を満たしている場合は、この項目を設定する必要はありません。または、 `thread`のみを使用して`mydumper-thread` } を設定することもできます。 +- ダンプ処理ユニットの設定引数。デフォルト設定で要件を満たしている場合は、この項目を設定する必要はありません。または、 `thread`のみを使用して`mydumper-thread` } を設定することもできます。 #### loaders {#code-loaders-code} -- 負荷処理ユニットのコンフィグレーション引数。デフォルト設定で要件を満たしている場合は、この項目を設定する必要はありません。または、 `pool-size`のみを使用して`loader-thread` } を設定することもできます。 +- 負荷処理ユニットの設定引数。デフォルト設定で要件を満たしている場合は、この項目を設定する必要はありません。または、 `pool-size`のみを使用して`loader-thread` } を設定することもできます。 #### syncers {#code-syncers-code} -- 同期処理ユニットのコンフィグレーション引数。デフォルト設定で要件を満たしている場合は、この項目を設定する必要はありません。または、 `worker-count`のみを使用して`syncer-thread` } を設定することもできます。 +- 同期処理ユニットの設定引数。デフォルト設定で要件を満たしている場合は、この項目を設定する必要はありません。または、 `worker-count`のみを使用して`syncer-thread` } を設定することもできます。 ## インスタンス構成 {#instance-configuration} diff --git a/dm/usage-scenario-master-slave-switch.md b/dm/usage-scenario-master-slave-switch.md index 7cce9a31bb1bd..58afa389efcf6 100644 --- a/dm/usage-scenario-master-slave-switch.md +++ b/dm/usage-scenario-master-slave-switch.md @@ -12,7 +12,7 @@ DM-worker が接続するアップストリーム MySQL インスタンスでダ > - DM ワーカー接続は、同じプライマリ - セカンダリ移行クラスター内のインスタンスにのみ切り替えることができます。 > - 新しく接続する MySQL インスタンスには、DM-worker に必要なbinlogが必要です。 > - DM ワーカーは GTID セット モードで動作する必要があります。つまり、対応するソース構成ファイルで`enable-gtid: true`指定する必要があります。 -> - 接続切り替えは以下の2つのシナリオのみをサポートします。各シナリオの手順を厳密に守ってください。そうしないと、新しく接続されたMySQLインスタンスに合わせてDMクラスタを再デプロイし、データ移行タスクを最初からやり直す必要がある場合があります。 +> - 接続切り替えは以下の2つのシナリオのみをサポートします。各シナリオの手順を厳密に守ってください。そうしないと、新しく接続されたMySQLインスタンスに合わせてDMクラスターを再デプロイし、データ移行タスクを最初からやり直す必要がある場合があります。 GTID セットの詳細については、 [MySQLドキュメント](https://dev.mysql.com/doc/refman/8.0/en/replication-gtids-concepts.html#replication-gtids-concepts-gtid-sets)を参照してください。 diff --git a/dr-backup-restore.md b/dr-backup-restore.md index e1600dd3fa3d9..591a896a72581 100644 --- a/dr-backup-restore.md +++ b/dr-backup-restore.md @@ -5,10 +5,10 @@ summary: TiDB のバックアップと復元機能に基づいて災害復旧を # BRに基づくDRソリューション {#dr-solution-based-on-br} -TiDBクラスタは複数のレプリカを持つため、単一のデータセンターまたはリージョンの障害にも耐え、サービス提供を継続できます。自然災害、ソフトウェアの脆弱性、ハードウェア障害、ウイルス攻撃、誤操作など、単一のデータセンターまたはリージョンよりも広い範囲に影響を及ぼすような事態が発生した場合、TiDBのバックアップ＆リストア（BR）機能により、独立した災害復旧（DR）storageデバイスにデータをバックアップし、ユーザーデータを損害から保護することができます。他のDRソリューションと比較して、 BR機能はより柔軟性、信頼性、復旧性、そして費用対効果に優れています。 +TiDBクラスターは複数のレプリカを持つため、単一のデータセンターまたはリージョンの障害にも耐え、サービス提供を継続できます。自然災害、ソフトウェアの脆弱性、ハードウェア障害、ウイルス攻撃、誤操作など、単一のデータセンターまたはリージョンよりも広い範囲に影響を及ぼすような事態が発生した場合、TiDBのバックアップ＆リストア（BR）機能により、独立した災害復旧（DR）ストレージデバイスにデータをバックアップし、ユーザーデータを損害から保護することができます。他のDRソリューションと比較して、 BR機能はより柔軟性、信頼性、復旧性、そして費用対効果に優れています。 - 柔軟性：いつでも、どの頻度でもデータをバックアップできます。これにより、バックアップとリストアが柔軟になり、さまざまなビジネスシナリオに適応しやすくなります。 -- 信頼性: バックアップ データは通常、独立したstorageデバイスに保存されるため、データのセキュリティが強化されます。 +- 信頼性: バックアップ データは通常、独立したストレージデバイスに保存されるため、データのセキュリティが強化されます。 - 回復性：予期せぬ状況によって元のデータが失われたり損傷したりした場合でも、バックアップデータを復元することで回復できます。これにより、 BR機能の回復性は高まり、データベースの正常な使用が保証されます。 - コスト効率: BRを使用すると、多額の費用をかけずにデータベースを保護できます。 @@ -18,13 +18,13 @@ TiDBクラスタは複数のレプリカを持つため、単一のデータセ ![BR log backup and PITR architecture](/media/dr/dr-backup-and-restore.png) -前述のアーキテクチャに示すように、他のリージョンにあるDRstorageデバイスにデータをバックアップし、必要に応じてバックアップデータからデータを復旧できます。つまり、クラスターは単一リージョンの障害に対して、最大5分の復旧ポイント目標（RPO）、数十分から数時間の復旧時間目標（RTO）で耐えることができます。ただし、データベースのサイズが大きい場合は、RTOが長くなる可能性があります。 +前述のアーキテクチャに示すように、他のリージョンにあるDRストレージデバイスにデータをバックアップし、必要に応じてバックアップデータからデータを復旧できます。つまり、クラスターは単一リージョンの障害に対して、最大5分の復旧ポイント目標（RPO）、数十分から数時間の復旧時間目標（RTO）で耐えることができます。ただし、データベースのサイズが大きい場合は、RTOが長くなる可能性があります。 > **注記：** > > このドキュメントの「地域」という用語は物理的な場所を意味します。 -一方、TiDBはブロックstorageのスナップショットに基づくバックアップとリストアを提供します。この機能により、リカバリ時間を数時間、あるいは1時間未満に短縮できます。TiDBは、より良いサービスを提供するために、バックアップとリストア機能を継続的に改善・最適化しています。 +一方、TiDBはブロックストレージのスナップショットに基づくバックアップとリストアを提供します。この機能により、リカバリ時間を数時間、あるいは1時間未満に短縮できます。TiDBは、より良いサービスを提供するために、バックアップとリストア機能を継続的に改善・最適化しています。 TiDBは、DRシナリオにおけるバックアップとリストア機能の使用方法を理解するのに役立つ詳細なドキュメントも提供しています。その中には、 diff --git a/dr-multi-replica.md b/dr-multi-replica.md index d1f23e7d40b6b..41c4cc2170784 100644 --- a/dr-multi-replica.md +++ b/dr-multi-replica.md @@ -3,9 +3,9 @@ title: DR Solution Based on Multiple Replicas in a Single Cluster summary: 単一クラスターのマルチレプリカ災害復旧ソリューションについて学習します。 --- -# 単一クラスタ内の複数のレプリカに基づく DR ソリューション {#dr-solution-based-on-multiple-replicas-in-a-single-cluster} +# 単一クラスター内の複数のレプリカに基づく DR ソリューション {#dr-solution-based-on-multiple-replicas-in-a-single-cluster} -このドキュメントでは、単一クラスタ内の複数のレプリカに基づく災害復旧（DR）ソリューションについて説明します。このドキュメントは、以下の構成になっています。 +このドキュメントでは、単一クラスター内の複数のレプリカに基づく災害復旧（DR）ソリューションについて説明します。このドキュメントは、以下の構成になっています。 - ソリューション紹介 - クラスターをセットアップしてレプリカを構成する方法 diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index 8ddc29ab876be..ae2cc36810d46 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -3,48 +3,48 @@ title: DR Solution Based on Primary and Secondary Clusters summary: TiCDCに基づいたプライマリ・セカンダリディザスタリカバリの実装方法を学びましょう。 --- -# プライマリクラスタとセカンダリクラスタに基づく災害復旧ソリューション {#dr-solution-based-on-primary-and-secondary-clusters} +# プライマリクラスターとセカンダリクラスターに基づく災害復旧ソリューション {#dr-solution-based-on-primary-and-secondary-clusters} -プライマリデータベースとセカンダリデータベースに基づく災害リカバリ（DR）は、一般的なソリューションです。このソリューションでは、DRシステムはプライマリクラスタとセカンダリクラスタで構成されます。プライマリクラスタはユーザーからのリクエストを処理し、セカンダリクラスタはプライマリクラスタからデータをバックアップします。プライマリクラスタに障害が発生した場合、セカンダリクラスタがサービスを引き継ぎ、バックアップデータを使用してサービスの提供を継続します。これにより、障害による中断なく、ビジネスシステムが正常に稼働し続けることが保証されます。 +プライマリデータベースとセカンダリデータベースに基づく災害リカバリ（DR）は、一般的なソリューションです。このソリューションでは、DRシステムはプライマリクラスターとセカンダリクラスターで構成されます。プライマリクラスターはユーザーからのリクエストを処理し、セカンダリクラスターはプライマリクラスターからデータをバックアップします。プライマリクラスターに障害が発生した場合、セカンダリクラスターがサービスを引き継ぎ、バックアップデータを使用してサービスの提供を継続します。これにより、障害による中断なく、ビジネスシステムが正常に稼働し続けることが保証されます。 プライマリ・セカンダリ型災害復旧ソリューションには、以下の利点があります。 - 高可用性：プライマリ・セカンダリアーキテクチャによりシステムの可用性が向上し、あらゆる障害からの迅速なリカバリが保証されます。 -- 高速切り替え：プライマリクラスタに障害が発生した場合、システムはセカンダリクラスタに迅速に切り替えてサービスの提供を継続できます。 -- データの一貫性：セカンダリクラスタは、プライマリクラスタのデータをほぼリアルタイムでバックアップします。これにより、システムが障害発生時にセカンダリクラスタに切り替わった場合でも、データは基本的に最新の状態に保たれます。 +- 高速切り替え：プライマリクラスターに障害が発生した場合、システムはセカンダリクラスターに迅速に切り替えてサービスの提供を継続できます。 +- データの一貫性：セカンダリクラスターは、プライマリクラスターのデータをほぼリアルタイムでバックアップします。これにより、システムが障害発生時にセカンダリクラスターに切り替わった場合でも、データは基本的に最新の状態に保たれます。 この文書には以下の内容が含まれています。 -- プライマリクラスタとセカンダリクラスタを設定します。 -- プライマリクラスタからセカンダリクラスタへデータを複製します。 +- プライマリクラスターとセカンダリクラスターを設定します。 +- プライマリクラスターからセカンダリクラスターへデータを複製します。 - クラスターを監視する。 - DR（災害復旧）システムの切り替えを実行します。 -一方、このドキュメントでは、セカンダリクラスタ上のビジネスデータを照会する方法、およびプライマリクラスタとセカンダリクラスタ間で双方向レプリケーションを実行する方法についても説明します。 +一方、このドキュメントでは、セカンダリクラスター上のビジネスデータを照会する方法、およびプライマリクラスターとセカンダリクラスター間で双方向レプリケーションを実行する方法についても説明します。 -## TiCDCに基づいてプライマリおよびセカンダリクラスタをセットアップする {#set-up-primary-and-secondary-clusters-based-on-ticdc} +## TiCDCに基づいてプライマリおよびセカンダリクラスターをセットアップする {#set-up-primary-and-secondary-clusters-based-on-ticdc} ### アーキテクチャ {#architecture} ![TiCDC secondary cluster architecture](/media/dr/dr-ticdc-secondary-cluster.png) -前述のアーキテクチャは、プライマリクラスタとセカンダリクラスタという2つのTiDBクラスタで構成されています。 +前述のアーキテクチャは、プライマリクラスターとセカンダリクラスターという2つのTiDBクラスターで構成されています。 - プライマリークラスター：リージョン1で稼働するアクティブなクラスターで、3つのレプリカを持ちます。このクラスターは読み取りおよび書き込みリクエストを処理します。 - セカンダリークラスター：リージョン2で稼働し、TiCDCを介してプライマリークラスターからデータを複製するスタンバイクラスター。 -このDRアーキテクチャはシンプルで使いやすい。リージョン障害に対応できるため、プライマリクラスタの書き込みパフォーマンスが低下しないことが保証され、セカンダリクラスタはレイテンシに影響されない読み取り専用処理を処理できる。このソリューションのリカバリポイント目標（RPO）は秒単位、リカバリ時間目標（RTO）は数分、あるいはそれ以下となる。多くのデータベースベンダーが重要な本番システム向けに推奨しているソリューションである。 +このDRアーキテクチャはシンプルで使いやすい。リージョン障害に対応できるため、プライマリクラスターの書き込みパフォーマンスが低下しないことが保証され、セカンダリクラスターはレイテンシに影響されない読み取り専用処理を処理できる。このソリューションのリカバリポイント目標（RPO）は秒単位、リカバリ時間目標（RTO）は数分、あるいはそれ以下となる。多くのデータベースベンダーが重要な本番システム向けに推奨しているソリューションである。 > **注記：** > > - [TiKVの「リージョン」](/glossary.md#regionpeerraft-group)はデータの範囲を意味し、「領域」という用語は物理的な場所を意味します。この2つの用語は互換性がありません。 -> - セカンダリクラスタへのデータ複製のために複数のチェンジフィードを実行したり、既にセカンダリクラスタが存在する状態で別のセカンダリクラスタを実行したりしないでください。そうしないと、セカンダリクラスタのデータトランザクションの整合性が保証されません。 +> - セカンダリクラスターへのデータ複製のために複数のチェンジフィードを実行したり、既にセカンダリクラスターが存在する状態で別のセカンダリクラスターを実行したりしないでください。そうしないと、セカンダリクラスターのデータトランザクションの整合性が保証されません。 ### プライマリクラスターとセカンダリクラスターを設定する {#set-up-primary-and-secondary-clusters} -このドキュメントでは、TiDBのプライマリクラスタとセカンダリクラスタは2つの異なるリージョン（リージョン1とリージョン2）にデプロイされています。プライマリクラスタとセカンダリクラスタの間には一定のネットワークレイテンシーがあるため、TiCDCはセカンダリクラスタと共にデプロイされます。TiCDCをセカンダリクラスタと共にデプロイすることで、ネットワークレイテンシーの影響を回避し、最適なレプリケーションパフォーマンスを実現できます。このドキュメントで提供する例のデプロイトポロジーは以下のとおりです（1つのコンポーネントノードが1つのサーバーにデプロイされます）。 +このドキュメントでは、TiDBのプライマリクラスターとセカンダリクラスターは2つの異なるリージョン（リージョン1とリージョン2）にデプロイされています。プライマリクラスターとセカンダリクラスターの間には一定のネットワークレイテンシーがあるため、TiCDCはセカンダリクラスターと共にデプロイされます。TiCDCをセカンダリクラスターと共にデプロイすることで、ネットワークレイテンシーの影響を回避し、最適なレプリケーションパフォーマンスを実現できます。このドキュメントで提供する例のデプロイトポロジーは以下のとおりです（1つのコンポーネントノードが1つのサーバーにデプロイされます）。 -| リージョン | ホスト | クラスタ | 成分 | +| リージョン | ホスト | クラスター | コンポーネント | | ------ | -------------------------- | ---- | ------------------------------- | | リージョン1 | 10.0.1.9 | 主要な | Monitor、Grafana、またはAlterManager | | リージョン2 | 10.0.1.11 | 二次 | Monitor、Grafana、またはAlterManager | @@ -53,20 +53,20 @@ summary: TiCDCに基づいたプライマリ・セカンダリディザスタリ | リージョン2 | 10.1.1.9/10.1.1.10 | 主要な | TiCDC | | リージョン1 | 10.0.1.4/10.0.1.5 | 主要な | TiDB | | リージョン2 | 10.1.1.4/10.1.1.5 | 二次 | TiDB | -| リージョン1 | 10.0.1.6/10.0.1.7/10.0.1.8 | 主要な | ティクヴ | -| リージョン2 | 10.1.1.6/10.1.1.7/10.1.1.8 | 二次 | ティクヴ | +| リージョン1 | 10.0.1.6/10.0.1.7/10.0.1.8 | 主要な | TiKV | +| リージョン2 | 10.1.1.6/10.1.1.7/10.1.1.8 | 二次 | TiKV | サーバーの設定については、以下のドキュメントを参照してください。 - [TiDB向けのソフトウェアおよびハードウェアに関する推奨事項](/hardware-and-software-requirements.md) - [TiCDC向けのソフトウェアおよびハードウェアに関する推奨事項](/ticdc/deploy-ticdc.md#software-and-hardware-recommendations) -TiDBプライマリクラスタとセカンダリクラスタのデプロイ方法の詳細については、 [TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)参照してください。 +TiDBプライマリクラスターとセカンダリクラスターのデプロイ方法の詳細については、 [TiDBクラスターをデプロイ](/production-deployment-using-tiup.md)参照してください。 -TiCDCを導入する際は、セカンダリクラスタとTiCDCを一緒に導入・管理する必要があり、両者間のネットワークが接続されている必要があることに注意してください。 +TiCDCを導入する際は、セカンダリクラスターとTiCDCを一緒に導入・管理する必要があり、両者間のネットワークが接続されている必要があることに注意してください。 - 既存のプライマリ クラスターに TiCDC をデプロイするには、 [TiCDCをデプロイ](/ticdc/deploy-ticdc.md#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup)参照してください。 -- 新しいプライマリクラスタとTiCDCをデプロイするには、以下のデプロイテンプレートを使用し、必要に応じて構成パラメータを変更してください。 +- 新しいプライマリクラスターとTiCDCをデプロイするには、以下のデプロイテンプレートを使用し、必要に応じて構成パラメータを変更してください。 ```yaml global: @@ -105,16 +105,16 @@ TiCDCを導入する際は、セカンダリクラスタとTiCDCを一緒に導 ### プライマリークラスターからセカンダリークラスターへデータを複製する {#replicate-data-from-the-primary-cluster-to-the-secondary-cluster} -TiDBのプライマリクラスタとセカンダリクラスタを設定した後、まずプライマリクラスタからセカンダリクラスタへデータを移行し、次にプライマリクラスタからセカンダリクラスタへリアルタイムの変更データを複製するためのレプリケーションタスクを作成します。 +TiDBのプライマリクラスターとセカンダリクラスターを設定した後、まずプライマリクラスターからセカンダリクラスターへデータを移行し、次にプライマリクラスターからセカンダリクラスターへリアルタイムの変更データを複製するためのレプリケーションタスクを作成します。 -#### 外部storageを選択してください {#select-an-external-storage} +#### 外部ストレージを選択してください {#select-an-external-ストレージ} -データの移行やリアルタイム変更データの複製には、外部storageを使用します。Amazon S3 が推奨されます。TiDB クラスターを自社構築のデータセンターにデプロイする場合は、以下の方法が推奨されます。 +データの移行やリアルタイム変更データの複製には、外部ストレージを使用します。Amazon S3 が推奨されます。TiDB クラスターを自社構築のデータセンターにデプロイする場合は、以下の方法が推奨されます。 -- バックアップstorageシステムとして構築[ミニオ](https://docs.min.io/docs/minio-quickstart-guide.html)使用し、S3プロトコルを使用してデータをMinIOにバックアップします。 +- バックアップストレージシステムとして構築[ミニオ](https://docs.min.io/docs/minio-quickstart-guide.html)使用し、S3プロトコルを使用してデータをMinIOにバックアップします。 - ネットワークファイルシステム（NFS、NASなど）ディスクをbrコマンドラインツール、TiKV、およびTiCDCインスタンスにマウントし、POSIXファイルシステムインターフェースを使用してバックアップデータを対応するNFSディレクトリに書き込みます。 -以下の例では、storageシステムとしてMinIOを使用していますが、これはあくまで参考例です。リージョン1またはリージョン2にMinIOをデプロイするには、別途サーバーを用意する必要があることに注意してください。 +以下の例では、ストレージシステムとしてMinIOを使用していますが、これはあくまで参考例です。リージョン1またはリージョン2にMinIOをデプロイするには、別途サーバーを用意する必要があることに注意してください。 ```shell wget https://dl.min.io/server/minio/release/linux-amd64/minio @@ -122,7 +122,7 @@ chmod +x minio # Configure access-key and access-secret-id to access MinIO export HOST_IP='10.0.1.10' # Replace it with the IP address of MinIO export MINIO_ROOT_USER='minio' -export MINIO_ROOT_PASSWORD='miniostorage' +export MINIO_ROOT_PASSWORD='minioストレージ' # Create the redo and backup directories. `backup` and `redo` are bucket names. mkdir -p data/redo mkdir -p data/backup @@ -134,18 +134,18 @@ nohup ./minio server ./data --address :6060 & - `endpoint` : `http://10.0.1.10:6060/` - `access-key` : `minio` -- `secret-access-key` : `miniostorage` +- `secret-access-key` : `minioストレージ` - `bucket` : `redo` / `backup` リンクは以下のとおりです。 - s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true + s3://backup?access-key=minio&secret-access-key=minioストレージ&endpoint=http://10.0.1.10:6060&force-path-style=true #### データの移行 {#migrate-data} [バックアップと復元機能](/br/backup-and-restore-overview.md)を使用して、プライマリ クラスターからセカンダリ クラスターにデータを移行します。 -1. GCを無効にします。増分移行中に新しく書き込まれたデータが削除されないようにするには、バックアップ前にアップストリームクラスタのGCを無効にする必要があります。こうすることで、履歴データが削除されるのを防ぐことができます。 +1. GCを無効にします。増分移行中に新しく書き込まれたデータが削除されないようにするには、バックアップ前にアップストリームクラスターのGCを無効にする必要があります。こうすることで、履歴データが削除されるのを防ぐことができます。 GCを無効にするには、次のステートメントを実行してください。 @@ -170,12 +170,12 @@ nohup ./minio server ./data --address :6060 & > **注記：** > - > 本番のクラスタでは、GCを無効にした状態でバックアップを実行すると、クラスタのパフォーマンスに影響が出る可能性があります。パフォーマンスの低下を避けるため、データのバックアップはピーク時以外の時間帯に行い、 `RATE_LIMIT`適切な値に設定することをお勧めします。 + > 本番のクラスターでは、GCを無効にした状態でバックアップを実行すると、クラスターのパフォーマンスに影響が出る可能性があります。パフォーマンスの低下を避けるため、データのバックアップはピーク時以外の時間帯に行い、 `RATE_LIMIT`適切な値に設定することをお勧めします。 -2. データのバックアップ。アップストリームクラスタで以下のステートメント`BACKUP`を実行してデータをバックアップします。 +2. データのバックアップ。アップストリームクラスターで以下のステートメント`BACKUP`を実行してデータをバックアップします。 ```sql - BACKUP DATABASE * TO '`s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true`'; + BACKUP DATABASE * TO '`s3://backup?access-key=minio&secret-access-key=minioストレージ&endpoint=http://10.0.1.10:6060&force-path-style=true`'; ``` +----------------------+----------+--------------------+---------------------+---------------------+ @@ -187,10 +187,10 @@ nohup ./minio server ./data --address :6060 & `BACKUP`のステートメントが実行されると、TiDBはバックアップデータに関するメタデータを返します。3 `BackupTS`のステートメントには注意してください。これは、バックアップ前に生成されたデータが含まれているためです。このドキュメントでは、 `BackupTS`**を増分マイグレーションの開始**として使用します。 -3. データの復元。セカンダリクラスタで以下のステートメント`RESTORE`を実行してデータを復元します。 +3. データの復元。セカンダリクラスターで以下のステートメント`RESTORE`を実行してデータを復元します。 ```sql - RESTORE DATABASE * FROM '`s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true`'; + RESTORE DATABASE * FROM '`s3://backup?access-key=minio&secret-access-key=minioストレージ&endpoint=http://10.0.1.10:6060&force-path-style=true`'; ``` +----------------------+----------+----------+---------------------+---------------------+ @@ -217,10 +217,10 @@ nohup ./minio server ./data --address :6060 & # The interval for refreshing or uploading redo logs to Amazon S3, in milliseconds. The default value is 1000, and the recommended value range is 500-2000. flush-interval = 2000 # The path where redo logs are saved. - storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true" + ストレージ = "s3://redo?access-key=minio&secret-access-key=minioストレージ&endpoint=http://10.0.1.10:6060&force-path-style=true" ``` - プライマリクラスタで、次のコマンドを実行して、プライマリクラスタからセカンダリクラスタへの変更フィードを作成します。 + プライマリクラスターで、次のコマンドを実行して、プライマリクラスターからセカンダリクラスターへの変更フィードを作成します。 ```shell tiup cdc cli changefeed create --server=http://10.1.1.9:8300 --sink-uri="mysql://{username}:{password}@10.1.1.4:4000" --changefeed-id="dr-primary-to-secondary" --start-ts="431434047157698561" --config changefeed.toml @@ -245,7 +245,7 @@ nohup ./minio server ./data --address :6060 & 3. GCを有効にする。 - TiCDCは、履歴データがレプリケートされる前にガベージコレクションされないようにします。そのため、プライマリクラスタからセカンダリクラスタに変更フィードを作成した後、次のステートメントを実行してGCを再度有効にすることができます。 + TiCDCは、履歴データがレプリケートされる前にガベージコレクションされないようにします。そのため、プライマリクラスターからセカンダリクラスターに変更フィードを作成した後、次のステートメントを実行してGCを再度有効にすることができます。 GCを有効にするには、次のステートメントを実行してください。 @@ -270,14 +270,14 @@ nohup ./minio server ./data --address :6060 & ### プライマリークラスターとセカンダリークラスターを監視する {#monitor-the-primary-and-secondary-clusters} -現在、TiDBにはDRダッシュボードは用意されていません。以下のダッシュボードを使用してTiDBのプライマリクラスタとセカンダリクラスタの状態を確認し、DR切り替えを実行するかどうかを判断してください。 +現在、TiDBにはDRダッシュボードは用意されていません。以下のダッシュボードを使用してTiDBのプライマリクラスターとセカンダリクラスターの状態を確認し、DR切り替えを実行するかどうかを判断してください。 - [TiDBの主要指標](/grafana-overview-dashboard.md) - [変更フィード指標](/ticdc/monitor-ticdc.md#changefeed) ### DR切り替えを実行する {#perform-dr-switchover} -このセクションでは、計画的な災害復旧（DR）切り替え、災害発生時のDR切り替え、およびセカンダリクラスタを再構築する手順について説明します。 +このセクションでは、計画的な災害復旧（DR）切り替え、災害発生時のDR切り替え、およびセカンダリクラスターを再構築する手順について説明します。 #### 計画されたプライマリおよびセカンダリ切り替え {#planned-primary-and-secondary-switchover} @@ -285,7 +285,7 @@ nohup ./minio server ./data --address :6060 & 1. プライマリークラスターへの業務書き込みを停止します。 -2. 書き込みがなくなったら、TiDBクラスタの最新のTSO（ `Position` ）を照会します。 +2. 書き込みがなくなったら、TiDBクラスターの最新のTSO（ `Position` ）を照会します。 ```sql BEGIN; SELECT TIDB_CURRENT_TSO(); ROLLBACK; @@ -325,37 +325,37 @@ nohup ./minio server ./data --address :6060 & 5. パラメータ`start-ts`を指定せずにチェンジフィード`dr-secondary-to-primary`を作成します。このチェンジフィードは現在時刻からデータの複製を開始します。 -6. ビジネスアプリケーションのデータベースアクセス設定を変更します。セカンダリクラスタにアクセスできるように、ビジネスアプリケーションを再起動します。 +6. ビジネスアプリケーションのデータベースアクセス設定を変更します。セカンダリクラスターにアクセスできるように、ビジネスアプリケーションを再起動します。 7. 業務アプリケーションが正常に動作しているかどうかを確認してください。 -上記の手順を繰り返すことで、以前のプライマリおよびセカンダリクラスタ構成を復元できます。 +上記の手順を繰り返すことで、以前のプライマリおよびセカンダリクラスター構成を復元できます。 #### 災害発生時の一次および二次切り替え {#primary-and-secondary-switchover-upon-disasters} -例えば、プライマリクラスタが設置されている地域で停電などの災害が発生した場合、プライマリクラスタとセカンダリクラスタ間のレプリケーションが突然中断される可能性があります。その結果、セカンダリクラスタ内のデータがプライマリクラスタ内のデータと矛盾することになります。 +例えば、プライマリクラスターが設置されている地域で停電などの災害が発生した場合、プライマリクラスターとセカンダリクラスター間のレプリケーションが突然中断される可能性があります。その結果、セカンダリクラスター内のデータがプライマリクラスター内のデータと矛盾することになります。 -1. セカンダリクラスタをトランザクション整合性のある状態に復元します。具体的には、リージョン2内の任意のTiCDCノードで次のコマンドを実行して、リドゥログをセカンダリクラスタに適用します。 +1. セカンダリクラスターをトランザクション整合性のある状態に復元します。具体的には、リージョン2内の任意のTiCDCノードで次のコマンドを実行して、リドゥログをセカンダリクラスターに適用します。 ```shell - tiup cdc redo apply --storage "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true" --tmp-dir /tmp/redo --sink-uri "mysql://{username}:{password}@10.1.1.4:4000" + tiup cdc redo apply --ストレージ "s3://redo?access-key=minio&secret-access-key=minioストレージ&endpoint=http://10.0.1.10:6060&force-path-style=true" --tmp-dir /tmp/redo --sink-uri "mysql://{username}:{password}@10.1.1.4:4000" ``` このコマンドにおけるパラメータの説明は以下のとおりです。 - - `--storage` ：Amazon S3にリドゥログが保存されるパス + - `--ストレージ` ：Amazon S3にリドゥログが保存されるパス - `--tmp-dir` : Amazon S3 からリドゥログをダウンロードするためのキャッシュディレクトリ - - `--sink-uri` ：セカンダリクラスタのアドレス + - `--sink-uri` ：セカンダリクラスターのアドレス -2. ビジネスアプリケーションのデータベースアクセス設定を変更します。セカンダリクラスタにアクセスできるように、ビジネスアプリケーションを再起動します。 +2. ビジネスアプリケーションのデータベースアクセス設定を変更します。セカンダリクラスターにアクセスできるように、ビジネスアプリケーションを再起動します。 3. 業務アプリケーションが正常に動作しているかどうかを確認してください。 #### プライマリクラスターとセカンダリクラスターを再構築する {#rebuild-the-primary-and-secondary-clusters} -プライマリクラスタで発生した障害が解決した場合、またはプライマリクラスタが一時的に復旧できない場合、セカンダリクラスタのみがプライマリクラスタとして稼働するため、TiDBクラスタは脆弱な状態になります。システムの信頼性を維持するには、DRクラスタを再構築する必要があります。 +プライマリクラスターで発生した障害が解決した場合、またはプライマリクラスターが一時的に復旧できない場合、セカンダリクラスターのみがプライマリクラスターとして稼働するため、TiDBクラスターは脆弱な状態になります。システムの信頼性を維持するには、DRクラスターを再構築する必要があります。 -TiDBのプライマリクラスタとセカンダリクラスタを再構築するには、新しいクラスタをデプロイして新しいDRシステムを構築できます。詳細については、以下のドキュメントを参照してください。 +TiDBのプライマリクラスターとセカンダリクラスターを再構築するには、新しいクラスターをデプロイして新しいDRシステムを構築できます。詳細については、以下のドキュメントを参照してください。 - [プライマリクラスターとセカンダリクラスターを設定する](#set-up-primary-and-secondary-clusters-based-on-ticdc) - [プライマリークラスターからセカンダリークラスターへデータを複製する](#replicate-data-from-the-primary-cluster-to-the-secondary-cluster) @@ -363,15 +363,15 @@ TiDBのプライマリクラスタとセカンダリクラスタを再構築す > **注記：** > -> プライマリクラスタとセカンダリクラスタ間のデータ不整合が解消できる場合は、新しいクラスタをデプロイする代わりに、修復されたクラスタを使用してDRシステムを再構築できます。 +> プライマリクラスターとセカンダリクラスター間のデータ不整合が解消できる場合は、新しいクラスターをデプロイする代わりに、修復されたクラスターを使用してDRシステムを再構築できます。 -### セカンダリクラスタでビジネスデータを照会する {#query-business-data-on-the-secondary-cluster} +### セカンダリクラスターでビジネスデータを照会する {#query-business-data-on-the-secondary-cluster} -プライマリ/セカンダリDRシナリオでは、セカンダリクラスタを読み取り専用クラスタとして使用し、レイテンシに影響されないクエリを実行するのが一般的です。TiDBも、プライマリ/セカンダリDRソリューションにおいてこの機能を提供しています。 +プライマリ/セカンダリDRシナリオでは、セカンダリクラスターを読み取り専用クラスターとして使用し、レイテンシに影響されないクエリを実行するのが一般的です。TiDBも、プライマリ/セカンダリDRソリューションにおいてこの機能を提供しています。 -変更フィードを作成する際に、構成ファイルで同期ポイント機能を有効にします。すると、変更フィードは定期的に（ `sync-point-interval`タイミングで）、セカンダリクラスタ上で`SET GLOBAL tidb_external_ts = @@tidb_current_ts`実行することにより、セカンダリクラスタに複製された一貫性のあるスナップショットポイントを設定します。 +変更フィードを作成する際に、構成ファイルで同期ポイント機能を有効にします。すると、変更フィードは定期的に（ `sync-point-interval`タイミングで）、セカンダリクラスター上で`SET GLOBAL tidb_external_ts = @@tidb_current_ts`実行することにより、セカンダリクラスターに複製された一貫性のあるスナップショットポイントを設定します。 -セカンダリクラスタからデータを照会するには、ビジネスアプリケーションで`SET GLOBAL|SESSION tidb_enable_external_ts_read = ON;`設定します。そうすることで、プライマリクラスタとトランザクション的に整合性のあるデータを取得できます。 +セカンダリクラスターからデータを照会するには、ビジネスアプリケーションで`SET GLOBAL|SESSION tidb_enable_external_ts_read = ON;`設定します。そうすることで、プライマリクラスターとトランザクション的に整合性のあるデータを取得できます。 ```toml # Starting from v6.4.0, only the changefeed with the SYSTEM_VARIABLES_ADMIN or SUPER privilege can use the TiCDC Syncpoint feature. @@ -393,22 +393,22 @@ max-log-size = 64 # Interval for refreshing or uploading redo logs to Amazon S3, in milliseconds. The default value is 1000, and the recommended value range is 500-2000. flush-interval = 2000 # The path where redo logs are saved. -storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=http://10.0.1.10:6060&force-path-style=true" +ストレージ = "s3://redo?access-key=minio&secret-access-key=minioストレージ&endpoint=http://10.0.1.10:6060&force-path-style=true" ``` > **注記：** > -> プライマリ・セカンダリ型の災害復旧アーキテクチャでは、セカンダリクラスタは1つのチェンジフィードからのデータしか複製できません。そうでない場合、セカンダリクラスタのデータトランザクションの整合性は保証されません。 +> プライマリ・セカンダリ型の災害復旧アーキテクチャでは、セカンダリクラスターは1つのチェンジフィードからのデータしか複製できません。そうでない場合、セカンダリクラスターのデータトランザクションの整合性は保証されません。 ### プライマリクラスターとセカンダリクラスター間で双方向レプリケーションを実行する {#perform-bidirectional-replication-between-the-primary-and-secondary-clusters} -このDRシナリオでは、2つのリージョンにあるTiDBクラスタが互いのディザスタリカバリクラスタとして機能します。リージョン構成に基づいて、ビジネストラフィックは対応するTiDBクラスタに書き込まれ、2つのTiDBクラスタは互いのデータをバックアップします。 +このDRシナリオでは、2つのリージョンにあるTiDBクラスターが互いのディザスタリカバリクラスターとして機能します。リージョン構成に基づいて、ビジネストラフィックは対応するTiDBクラスターに書き込まれ、2つのTiDBクラスターは互いのデータをバックアップします。 ![TiCDC bidirectional replication](/media/dr/bdr-ticdc.png) -双方向レプリケーション機能により、2つのリージョンにあるTiDBクラスタ間でデータのレプリケーションが可能になります。このDRソリューションは、データのセキュリティと信頼性を保証するとともに、データベースの書き込みパフォーマンスも確保します。計画的なDR切り替えでは、新しいチェンジフィードを開始する前に実行中のチェンジフィードを停止する必要がないため、運用とメンテナンスが簡素化されます。 +双方向レプリケーション機能により、2つのリージョンにあるTiDBクラスター間でデータのレプリケーションが可能になります。このDRソリューションは、データのセキュリティと信頼性を保証するとともに、データベースの書き込みパフォーマンスも確保します。計画的なDR切り替えでは、新しいチェンジフィードを開始する前に実行中のチェンジフィードを停止する必要がないため、運用とメンテナンスが簡素化されます。 -双方向DRクラスタを構築するには、 [TiCDCの双方向複製](/ticdc/ticdc-bidirectional-replication.md)参照してください。 +双方向DRクラスターを構築するには、 [TiCDCの双方向複製](/ticdc/ticdc-bidirectional-replication.md)参照してください。 ## トラブルシューティング {#troubleshooting} diff --git a/dr-solution-introduction.md b/dr-solution-introduction.md index bba874044a4e2..022a6f2163a1b 100644 --- a/dr-solution-introduction.md +++ b/dr-solution-introduction.md @@ -1,6 +1,6 @@ --- title: Overview of TiDB Disaster Recovery Solutions -summary: TiDBが提供するディザスタリカバリソリューションについて学びましょう。これには、プライマリ/セカンダリクラスタに基づくディザスタリカバリ、単一クラスタ内の複数レプリカに基づくディザスタリカバリ、バックアップとリストアに基づくディザスタリカバリなどが含まれます。 +summary: TiDBが提供するディザスタリカバリソリューションについて学びましょう。これには、プライマリ/セカンダリクラスターに基づくディザスタリカバリ、単一クラスター内の複数レプリカに基づくディザスタリカバリ、バックアップとリストアに基づくディザスタリカバリなどが含まれます。 --- # TiDB災害復旧ソリューションの概要 {#overview-of-tidb-disaster-recovery-solutions} @@ -32,11 +32,11 @@ summary: TiDBが提供するディザスタリカバリソリューションに ![TiDB architecture](/media/dr/tidb-architecture.png) -TiDBは、コンピューティングとstorageを分離したアーキテクチャで設計されています。 +TiDBは、コンピューティングとストレージを分離したアーキテクチャで設計されています。 - TiDBは、システムのSQLコンピューティングレイヤーです。 -- TiKVはシステムのstorageレイヤーであり、行ベースのstorageエンジンです。[リージョン](/glossary.md#regionpeerraft-group)TiKVにおけるデータスケジューリングの基本単位です。リージョンは、ソートされたデータ行の集合です。リージョン内のデータは少なくとも3つのレプリカに保存され、データの変更はRaftプロトコルを介してログレイヤーに複製されます。 -- オプションコンポーネントTiFlashは、分析クエリの高速化に使用できるカラム型storageエンジンです。データは、 Raftグループの学習者ロールを介してTiKVからTiFlashに複製されます。 +- TiKVはシステムのストレージレイヤーであり、行ベースのストレージエンジンです。[リージョン](/glossary.md#regionpeerraft-group)TiKVにおけるデータスケジューリングの基本単位です。リージョンは、ソートされたデータ行の集合です。リージョン内のデータは少なくとも3つのレプリカに保存され、データの変更はRaftプロトコルを介してログレイヤーに複製されます。 +- オプションコンポーネントTiFlashは、分析クエリの高速化に使用できるカラム型ストレージエンジンです。データは、 Raftグループのラーナーロールを介してTiKVからTiFlashに複製されます。 TiDBは3つの完全なデータレプリカを保存します。そのため、複数のレプリカに基づく災害復旧（DR）を自然に実現できます。同時に、TiDBはRaftログを使用してトランザクションログを複製するため、トランザクションログの複製に基づくDRも提供できます。 @@ -55,23 +55,23 @@ TiDBの増分データレプリケーションツールとして、TiCDCはPDの ![BR architecture](/media/br/br-snapshot-arch.png) -TiDBのバックアップおよび復元ツールとして、 BRは特定の時点に基づいた完全なスナップショットバックアップと、TiDBクラスタの継続的なログバックアップを実行できます。TiDBクラスタが完全に利用不能になった場合でも、バックアップファイルを新しいクラスタに復元できます。BRは通常、データセキュリティにおける最終手段とみなされます。 +TiDBのバックアップおよび復元ツールとして、 BRは特定の時点に基づいた完全なスナップショットバックアップと、TiDBクラスターの継続的なログバックアップを実行できます。TiDBクラスターが完全に利用不能になった場合でも、バックアップファイルを新しいクラスターに復元できます。BRは通常、データセキュリティにおける最終手段とみなされます。 ## ソリューションの紹介 {#solutions-introduction} -### プライマリおよびセカンダリクラスタに基づくDRソリューション {#dr-solution-based-on-primary-and-secondary-clusters} +### プライマリおよびセカンダリクラスターに基づくDRソリューション {#dr-solution-based-on-primary-and-secondary-clusters} ![Primary-secondary cluster DR](/media/dr/ticdc-dr.png) -前述のアーキテクチャは、2つのTiDBクラスタで構成されています。クラスタ1はリージョン1で動作し、読み取りおよび書き込み要求を処理します。クラスタ2はリージョン2で動作し、セカンダリクラスタとして機能します。クラスタ1で障害が発生した場合、クラスタ2がサービスを引き継ぎます。データ変更は、TiCDCを使用して2つのクラスタ間で複製されます。このアーキテクチャは、「1対1」の災害復旧ソリューションとも呼ばれます。 +前述のアーキテクチャは、2つのTiDBクラスターで構成されています。クラスター1はリージョン1で動作し、読み取りおよび書き込み要求を処理します。クラスター2はリージョン2で動作し、セカンダリクラスターとして機能します。クラスター1で障害が発生した場合、クラスター2がサービスを引き継ぎます。データ変更は、TiCDCを使用して2つのクラスター間で複製されます。このアーキテクチャは、「1対1」の災害復旧ソリューションとも呼ばれます。 -このアーキテクチャはシンプルで可用性が高く、領域レベルのエラー許容目標、スケーラブルな書き込み機能、第 2 レベルの RPO、分単位以下の RTO を備えています。本番システムで RPO をゼロにする必要がない場合は、この DR ソリューションをお勧めします。このソリューションの詳細については、[プライマリおよびセカンダリクラスタに基づくDRソリューション](/dr-secondary-cluster.md)参照してください。 +このアーキテクチャはシンプルで可用性が高く、領域レベルのエラー許容目標、スケーラブルな書き込み機能、第 2 レベルの RPO、分単位以下の RTO を備えています。本番システムで RPO をゼロにする必要がない場合は、この DR ソリューションをお勧めします。このソリューションの詳細については、[プライマリおよびセカンダリクラスターに基づくDRソリューション](/dr-secondary-cluster.md)参照してください。 ### 単一クラスター内の複数のレプリカに基づく災害復旧ソリューション {#dr-solution-based-on-multiple-replicas-in-a-single-cluster} ![Multi-replica cluster DR](/media/dr/multi-replica-dr.png) -前述のアーキテクチャでは、各リージョンに、異なるアベイラブルゾーン（AZ）に配置された2つの完全なデータレプリカがあります。クラスタ全体は3つのリージョンにまたがっています。リージョン1は、読み取りおよび書き込み要求を処理するプライマリリージョンです。リージョン1が災害により完全に利用不能になった場合、リージョン2をDRリージョンとして使用できます。リージョン3は、多数決プロトコルを満たすために使用されるレプリカです。このアーキテクチャは「2-2-1」ソリューションとも呼ばれます。 +前述のアーキテクチャでは、各リージョンに、異なるアベイラブルゾーン（AZ）に配置された2つの完全なデータレプリカがあります。クラスター全体は3つのリージョンにまたがっています。リージョン1は、読み取りおよび書き込み要求を処理するプライマリリージョンです。リージョン1が災害により完全に利用不能になった場合、リージョン2をDRリージョンとして使用できます。リージョン3は、多数決プロトコルを満たすために使用されるレプリカです。このアーキテクチャは「2-2-1」ソリューションとも呼ばれます。 このソリューションは、領域レベルのエラー耐性、スケーラブルな書き込み機能、ゼロ RPO、分単位以下の RTO を提供します。本番システムでゼロ RPO が必要な場合は、この DR ソリューションを使用することをお勧めします。このソリューションの詳細については、[単一クラスター内の複数のレプリカに基づく災害復旧ソリューション](/dr-multi-replica.md)を参照してください。 @@ -81,9 +81,9 @@ TiDBのバックアップおよび復元ツールとして、 BRは特定の時 ![TiCDC-based multi-replica cluster DR](/media/dr/ticdc-multi-replica-dr.png) -前述のアーキテクチャでは、TiDBクラスタは2つ存在します。クラスタ1は、3つのリージョンにまたがる5つのレプリカで構成されています。リージョン1には、プライマリリージョンとして機能し、書き込みリクエストを処理する2つのレプリカがあります。リージョン2には、リージョン1のDRリージョンとして機能する2つのレプリカがあります。このリージョンは、レイテンシーの影響を受けにくい読み取りサービスを提供します。リージョン3にある最後のレプリカは、投票に使用されます。 +前述のアーキテクチャでは、TiDBクラスターは2つ存在します。クラスター1は、3つのリージョンにまたがる5つのレプリカで構成されています。リージョン1には、プライマリリージョンとして機能し、書き込みリクエストを処理する2つのレプリカがあります。リージョン2には、リージョン1のDRリージョンとして機能する2つのレプリカがあります。このリージョンは、レイテンシーの影響を受けにくい読み取りサービスを提供します。リージョン3にある最後のレプリカは、投票に使用されます。 -リージョン1とリージョン2のDRクラスタとして、クラスタ2はリージョン3で稼働し、3つのレプリカを含みます。TiCDCはクラスタ1からデータを複製します。このアーキテクチャは複雑に見えますが、複数のリージョンに対するエラー許容目標を高めることができます。複数のリージョンが同時に利用不能になった場合にRPOがゼロである必要がない場合は、このアーキテクチャは良い選択肢です。このアーキテクチャは「2-2-1:1」ソリューションとも呼ばれます。 +リージョン1とリージョン2のDRクラスターとして、クラスター2はリージョン3で稼働し、3つのレプリカを含みます。TiCDCはクラスター1からデータを複製します。このアーキテクチャは複雑に見えますが、複数のリージョンに対するエラー許容目標を高めることができます。複数のリージョンが同時に利用不能になった場合にRPOがゼロである必要がない場合は、このアーキテクチャは良い選択肢です。このアーキテクチャは「2-2-1:1」ソリューションとも呼ばれます。 もちろん、エラー許容範囲が複数のリージョンに及び、RPOがゼロでなければならない場合は、5つのリージョンにまたがる少なくとも9つのレプリカを持つクラスターを作成することも検討できます。このアーキテクチャは「2-2-2-2-1」ソリューションとも呼ばれます。 @@ -91,11 +91,11 @@ TiDBのバックアップおよび復元ツールとして、 BRは特定の時 ![BR-based cluster DR](/media/dr/br-dr.png) -このアーキテクチャでは、TiDBクラスタ1がリージョン1にデプロイされます。BRはクラスタ1のデータを定期的にリージョン2にバックアップし、さらにこのクラスタのデータ変更ログも継続的にリージョン2にバックアップします。リージョン1で災害が発生し、クラスタ1が復旧できない場合、バックアップデータとデータ変更ログを使用して、リージョン2に新しいクラスタ（クラスタ2）を復元し、サービスを提供できます。 +このアーキテクチャでは、TiDBクラスター1がリージョン1にデプロイされます。BRはクラスター1のデータを定期的にリージョン2にバックアップし、さらにこのクラスターのデータ変更ログも継続的にリージョン2にバックアップします。リージョン1で災害が発生し、クラスター1が復旧できない場合、バックアップデータとデータ変更ログを使用して、リージョン2に新しいクラスター（クラスター2）を復元し、サービスを提供できます。 BRに基づく DR ソリューションは、5 分未満の RPO と、復元するデータのサイズに応じて変化する RTO を提供します。 BR v6.5.0 の場合、復元速度については[スナップショット復元のパフォーマンスと影響](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-restore)パフォーマンス[PITRのパフォーマンスと影響](/br/br-pitr-guide.md#performance-capabilities-of-pitr)を参照してください。通常、リージョン間のバックアップ機能はデータ セキュリティの最後の手段とみなされ、ほとんどのシステムにとって必須のソリューションでもあります。このソリューションの詳細については、 [BRに基づくDRソリューション](/dr-backup-restore.md)を参照してください。 -一方、 BR はv6.5.0 以降、 [EBSボリュームのスナップショットからTiDBクラスタを復元する](https://docs.pingcap.com/tidb-in-kubernetes/stable/restore-from-ebs-snapshot-across-multiple-kubernetes)サポートします。クラスターが Kubernetes 上で実行されており、クラスターに影響を与えずにできるだけ早くクラスターを復元したい場合は、この機能を使用してシステムの RTO を短縮できます。 +一方、 BR はv6.5.0 以降、 [EBSボリュームのスナップショットからTiDBクラスターを復元する](https://docs.pingcap.com/tidb-in-kubernetes/stable/restore-from-ebs-snapshot-across-multiple-kubernetes)サポートします。クラスターが Kubernetes 上で実行されており、クラスターに影響を与えずにできるだけ早くクラスターを復元したい場合は、この機能を使用してシステムの RTO を短縮できます。 ### その他の災害復旧ソリューション {#other-dr-solutions} diff --git a/dumpling-overview.md b/dumpling-overview.md index 203dcc3d53887..7e8bec6c5d31f 100644 --- a/dumpling-overview.md +++ b/dumpling-overview.md @@ -31,7 +31,7 @@ tiup install dumpling Dumplingの詳しい使用方法については、 `--help`オプションを使用するか、 [Dumplingのオプション一覧](#option-list-of-dumpling)を参照してください。 -Dumplingを使用する場合は、実行中のクラスタ上でexportコマンドを実行する必要があります。 +Dumplingを使用する場合は、実行中のクラスター上でexportコマンドを実行する必要があります。 @@ -51,10 +51,10 @@ Dumplingには次のような利点があります。 - SQLやCSVなど、複数の形式でのデータエクスポートをサポートします。 - データのフィルタリングを容易にする[テーブルフィルター](https://github.com/pingcap/tidb-tools/blob/master/pkg/table-filter/README.md)機能をサポートします。 -- Amazon S3クラウドstorageへのデータエクスポートをサポートします。 +- Amazon S3クラウドストレージへのデータエクスポートをサポートします。 - TiDB向けにさらなる最適化が行われました。 - TiDB SQLステートメントのメモリ制限を設定する機能をサポートします。 - - Dumpling がTiDB クラスタの PD アドレスと[`INFORMATION_SCHEMA.CLUSTER_INFO`](/information-schema/information-schema-cluster-info.md)テーブルにアクセスできる場合、 Dumpling はTiDB v4.0.0 以降のバージョンでブロック GC を実行するために[GC](/garbage-collection-overview.md)セーフポイント時間を自動的に調整することをサポートします。 + - Dumpling がTiDB クラスターの PD アドレスと[`INFORMATION_SCHEMA.CLUSTER_INFO`](/information-schema/information-schema-cluster-info.md)テーブルにアクセスできる場合、 Dumpling はTiDB v4.0.0 以降のバージョンでブロック GC を実行するために[GC](/garbage-collection-overview.md)セーフポイント時間を自動的に調整することをサポートします。 - TiDBの非表示列`_tidb_rowid`を使用して、単一テーブルからの同時データエクスポートのパフォーマンスを最適化します。 - TiDB の場合、 [`tidb_snapshot`](/read-historical-data.md#how-tidb-reads-data-from-history-versions)の値を設定することで、データバックアップの時点を指定できます。これにより、 `FLUSH TABLES WITH READ LOCK`を使用して一貫性を確保する代わりに、バックアップの一貫性が確保されます。 @@ -62,7 +62,7 @@ Dumplingには次のような利点があります。 > > Dumplingは、以下のシナリオではPDに接続できません。 > -> - TiDBクラスタはKubernetes上で動作します（ただし、 Dumpling自体がKubernetes環境内で動作している場合は除きます）。 +> - TiDBクラスターはKubernetes上で動作します（ただし、 Dumpling自体がKubernetes環境内で動作している場合は除きます）。 > - TiDBクラスターはTiDB Cloud上で稼働しています。 > > このような場合、エクスポートの失敗を避けるために手動で[TiDBのGC時間を調整する](#manually-set-the-tidb-gc-time)必要があります。 @@ -71,7 +71,7 @@ Dumplingには次のような利点があります。 ### 必要な権限 {#required-privileges} -- プロセス：クラスタ情報を照会してPDアドレスを取得し、PDを介してGCを制御する必要があります。 +- プロセス：クラスター情報を照会してPDアドレスを取得し、PDを介してGCを制御する必要があります。 - SELECT: テーブルをエクスポートする際に必須です。 - RELOAD: `consistency`のレベルが`flush`の場合に必要です。アップストリームが RDS データベースまたはマネージド サービスの場合は、この権限を無視できます。 - テーブルのロック: `consistency`のレベルが`lock`の場合に必要です。この権限は、エクスポートするすべてのデータベースとテーブルに対して付与する必要があります。 @@ -92,7 +92,7 @@ tiup dumpling -u root -P 4000 -h 127.0.0.1 --filetype sql -t 8 -o /tmp/test -r 2 - `-h` 、 `-P` 、および`-u`オプションは、それぞれアドレス、ポート、およびユーザーを意味します。認証にパスワードが必要な場合は、 `-p $YOUR_SECRET_PASSWORD`を使用してパスワードをDumplingに渡すことができます。 -- `-o` (または`--output` ) オプションは、storageのエクスポート ディレクトリを指定します。これは、絶対ローカル ファイル パスまたは[外部storageURI](/external-storage-uri.md)をサポートします。 +- `-o` (または`--output` ) オプションは、ストレージのエクスポート ディレクトリを指定します。これは、絶対ローカル ファイル パスまたは[外部ストレージURI](/external-ストレージ-uri.md)をサポートします。 - `-t`オプションは、エクスポートに使用するスレッド数を指定します。スレッド数を増やすと、Dumplingの並列処理能力とエクスポート速度が向上しますが、データベースのメモリ使用量も増加します。そのため、スレッド数をあまり大きく設定することは推奨されません。通常は 64 未満に設定します。 @@ -107,15 +107,15 @@ tiup dumpling -u root -P 4000 -h 127.0.0.1 --filetype sql -t 8 -o /tmp/test -r 2 > > エクスポートされた単一のテーブルのサイズが 10 GB を超える場合は、 `-r`および`-F`オプション**を使用することを**強くお勧めします。 -#### storageサービスのURI形式 {#uri-formats-of-the-storage-services} +#### ストレージサービスのURI形式 {#uri-formats-of-the-ストレージ-services} -このセクションでは、Amazon S3、GCS、Azure Blob StorageなどのstorageサービスのURI形式について説明します。URI形式は以下のとおりです。 +このセクションでは、Amazon S3、GCS、Azure Blob StorageなどのストレージサービスのURI形式について説明します。URI形式は以下のとおりです。 ```shell [scheme]://[host]/[path]?[parameters] ``` -詳細については、[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 +詳細については、[外部ストレージサービスのURI形式](/external-ストレージ-uri.md)を参照してください。 ### CSVファイルにエクスポート {#export-to-csv-files} @@ -213,20 +213,20 @@ tiup dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test --filetype csv --sql 'se - `*-schema-view.sql` 、 `*-schema-trigger.sql` 、 `*-schema-post.sql` : その他のエクスポートされたファイル -### データをAmazon S3クラウドstorageにエクスポートする {#export-data-to-amazon-s3-cloud-storage} +### データをAmazon S3クラウドストレージにエクスポートする {#export-data-to-amazon-s3-cloud-ストレージ} -バージョン4.0.8以降、 Dumplingはクラウドストレージへのデータエクスポートをサポートしています。Amazon S3にデータをバックアップする必要がある場合は、 `-o`パラメータでAmazon S3storageパスを指定する必要があります。 +バージョン4.0.8以降、 Dumplingはクラウドストレージへのデータエクスポートをサポートしています。Amazon S3にデータをバックアップする必要がある場合は、 `-o`パラメータでAmazon S3ストレージパスを指定する必要があります。 指定されたリージョンに Amazon S3 バケットを作成する必要があります ( [Amazonドキュメント - S3バケットの作成方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)参照)。バケット内にフォルダーを作成する必要がある場合は、 [Amazonドキュメント - フォルダの作成](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-folder.html)参照してください。 -Amazon S3バックエンドstorageへのアクセス権限を持つアカウントの`SecretKey`と`AccessKey`を環境変数としてDumplingノードに渡します。 +Amazon S3バックエンドストレージへのアクセス権限を持つアカウントの`SecretKey`と`AccessKey`を環境変数としてDumplingノードに渡します。 ```shell export AWS_ACCESS_KEY_ID=${AccessKey} export AWS_SECRET_ACCESS_KEY=${SecretKey} ``` -Dumpling は、 `~/.aws/credentials`からの認証情報ファイルの読み取りもサポートしています。 URI パラメーターの説明の詳細については、[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 +Dumpling は、 `~/.aws/credentials`からの認証情報ファイルの読み取りもサポートしています。 URI パラメーターの説明の詳細については、[外部ストレージサービスのURI形式](/external-ストレージ-uri.md)を参照してください。 ```shell tiup dumpling -u root -P 4000 -h 127.0.0.1 -r 200000 -o "s3://${Bucket}/${Folder}" @@ -274,7 +274,7 @@ Dumpling、 `-B`オプションを使用して特定のデータベースをエ - `-t`オプションは、エクスポートに使用するスレッド数を指定します。スレッド数を増やすと、Dumplingの並列処理能力とエクスポート速度が向上しますが、データベースのメモリ使用量も増加します。そのため、スレッド数をあまり大きく設定することはお勧めしません。 - `-r`オプションは、テーブル内同時実行を有効にしてエクスポートを高速化します。デフォルト値は`0`で、無効を意味します。0 より大きい値は有効を意味し、値は`INT`型です。ソース データベースが TiDB の場合、0 より大きい`-r`値は、TiDB リージョン情報が分割に使用され、メモリ使用量が削減されることを示します。特定の`-r`値は、分割アルゴリズムに影響しません。ソースデータベースがMySQLで、主キーまたは複合主キーの最初の列が`INT`型の場合、 `-r`を指定することで、テーブル内同時実行を有効にすることもできます。 -- `--compress `オプションは、ダンプの圧縮形式を指定します。このオプションは、 `gzip` 、 `snappy` 、および`zstd`の圧縮アルゴリズムをサポートしています。storageがボトルネックになっている場合や、storage容量が懸念される場合は、このオプションを使用するとデータのダンプを高速化できます。ただし、CPU 使用率が増加するという欠点があります。各ファイルは個別に圧縮されます。 +- `--compress `オプションは、ダンプの圧縮形式を指定します。このオプションは、 `gzip` 、 `snappy` 、および`zstd`の圧縮アルゴリズムをサポートしています。ストレージがボトルネックになっている場合や、ストレージ容量が懸念される場合は、このオプションを使用するとデータのダンプを高速化できます。ただし、CPU 使用率が増加するという欠点があります。各ファイルは個別に圧縮されます。 上記のオプションを指定することで、 Dumplingはより高速なデータエクスポートを実現できます。 @@ -330,12 +330,12 @@ DumplingがTiDBから大きな単一テーブルをエクスポートする際 ### TiDBのGC時間を手動で設定する {#manually-set-the-tidb-gc-time} -TiDBからデータをエクスポートする場合（1TB未満）、TiDBのバージョンがv4.0.0以降で、 DumplingがTiDBクラスタのPDアドレスと[`INFORMATION_SCHEMA.CLUSTER_INFO`](/information-schema/information-schema-cluster-info.md)テーブルにアクセスできる場合、 DumplingはGCセーフポイントを自動的に調整し、元のクラスタに影響を与えることなくGCをブロックします。 +TiDBからデータをエクスポートする場合（1TB未満）、TiDBのバージョンがv4.0.0以降で、 DumplingがTiDBクラスターのPDアドレスと[`INFORMATION_SCHEMA.CLUSTER_INFO`](/information-schema/information-schema-cluster-info.md)テーブルにアクセスできる場合、 DumplingはGCセーフポイントを自動的に調整し、元のクラスターに影響を与えることなくGCをブロックします。 ただし、以下のいずれかのシナリオでは、 DumplingはGC時間を自動的に調整できません。 - データサイズが非常に大きい（1TB以上）。 -- TiDBクラスタがTiDB Cloud上、またはDumplingとは別のKubernetes上にある場合、 DumplingはPDに直接接続できません。 +- TiDBクラスターがTiDB Cloud上、またはDumplingとは別のKubernetes上にある場合、 DumplingはPDに直接接続できません。 このような場合、エクスポート処理中にガベージコレクション（GC）が原因でエクスポートが失敗しないように、事前にGC時間を手動で延長する必要があります。 @@ -373,7 +373,7 @@ SET GLOBAL tidb_gc_life_time = '10m'; | `-s`または`--statement-size` | `INSERT`ステートメントのサイズを制御します。単位はバイトです。 | | | `-F`または`--filesize` | 分割されたテーブルのファイルサイズ。単位は`128B` 、 `64KiB` 、 `32MiB` 、 `1.5GiB`のように指定する必要があります。 | | | `--filetype` | エクスポートされたファイル形式（csv/sql） | 「sql」 | -| `-o`または`--output` | データのエクスポートに使用する絶対ローカルファイルパス、または[外部storageURI](/external-storage-uri.md)を指定してください。 | "./export-${time}" | +| `-o`または`--output` | データのエクスポートに使用する絶対ローカルファイルパス、または[外部ストレージURI](/external-ストレージ-uri.md)を指定してください。 | "./export-${time}" | | `-S`または`--sql` | 指定されたSQL文に従ってデータをエクスポートします。このコマンドは同時エクスポートをサポートしていません。 | | | `--consistency` | フラッシュ: ダンプの前にFTWRLを使用してください
スナップショット: TSO の特定のスナップショットの TiDB データをダンプします
ロック: ダンプ対象のすべてのテーブルに対して`lock tables read`を実行します
none: ロックを追加せずにダンプします。これは一貫性を保証できません。
auto: MySQL の場合は --consistency flush を使用し、TiDB の場合は --consistency snapshot を使用します。 | 「自動」 | | `--snapshot` | スナップショットTSO。 `consistency=snapshot`の場合のみ有効。 | | diff --git a/dynamic-config.md b/dynamic-config.md index c6e8e6a7e2489..4ecf7aeb01acb 100644 --- a/dynamic-config.md +++ b/dynamic-config.md @@ -3,11 +3,11 @@ title: Modify Configuration Dynamically summary: クラスター構成を動的に変更する方法を学習します。 --- -# コンフィグレーションを動的に変更する {#modify-configuration-dynamically} +# 設定を動的に変更する {#modify-configuration-dynamically} このドキュメントでは、クラスター構成を動的に変更する方法について説明します。 -クラスタコンポーネントを再起動することなく、SQL文を使用してコンポーネント（TiDB、TiKV、PDを含む）の構成を動的に更新できます。現在、TiDBインスタンスの構成変更方法は、他のコンポーネント（TiKVやPDなど）の構成変更方法とは異なります。 +クラスターコンポーネントを再起動することなく、SQL文を使用してコンポーネント（TiDB、TiKV、PDを含む）の構成を動的に更新できます。現在、TiDBインスタンスの構成変更方法は、他のコンポーネント（TiKVやPDなど）の構成変更方法とは異なります。 > **注記：** > @@ -111,7 +111,7 @@ show warnings; 次の TiKV 構成項目は動的に変更できます。 -| コンフィグレーション項目 | 説明 | +| 設定項目 | 説明 | | :-------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------- | | ログレベル | ログ レベル。 | | `raftstore.raft-max-inflight-msgs` | 確認するRaftログの数。この数を超えると、 Raftステートマシンはログの送信速度を低下させます。 | @@ -177,7 +177,7 @@ show warnings; | `gc.batch-keys` | 1バッチで処理されるキーの数 | | `gc.max-write-bytes-per-sec` | RocksDBに1秒あたり書き込める最大バイト数 | | `gc.enable-compaction-filter` | 圧縮フィルタを有効にするかどうか | -| `gc.compaction-filter-skip-version-check` | 圧縮フィルタのクラスタバージョンチェックをスキップするかどうか（未リリース） | +| `gc.compaction-filter-skip-version-check` | 圧縮フィルタのクラスターバージョンチェックをスキップするかどうか（未リリース） | | `gc.auto-compaction.check-interval` | TiKVが自動（RocksDB）圧縮をトリガーするかどうかを確認する間隔 | | `gc.auto-compaction.tombstone-num-threshold` | TiKV自動（RocksDB）圧縮をトリガーするために必要なRocksDBトゥームストーンの数 | | `gc.auto-compaction.tombstone-percent-threshold` | TiKV自動（RocksDB）圧縮をトリガーするために必要なRocksDBトゥームストーンの割合 | @@ -216,13 +216,13 @@ show warnings; | `server.concurrent-recv-snap-limit` | 同時に受信するスナップショットの最大数を設定します | | `server.raft-msg-max-batch-size` | 1つのgRPCメッセージに含まれるRaftメッセージの最大数を設定します。 | | `server.simplify-metrics` | サンプリング監視メトリックを簡素化するかどうかを制御します | -| `storage.block-cache.capacity` | 共有ブロックキャッシュのサイズ（v4.0.3以降でサポート） | -| storage.フロー制御.有効 | フロー制御メカニズムを有効にするかどうかを決定します | -| storage.フロー制御.memtables-threshold | フロー制御をトリガーするkvDB memtablesの最大数 | -| storage.flow-control.l0-files-threshold | フロー制御をトリガーするkvDB L0ファイルの最大数 | -| storage.flow-control.soft-pending-compaction-bytes-limit | フロー制御メカニズムが一部の書き込み要求を拒否するトリガーとなる、kvDB保留圧縮バイトのしきい値 | -| storage.フロー制御.ハード保留圧縮バイト制限 | フロー制御メカニズムがすべての書き込み要求を拒否するトリガーとなる、kvDB保留圧縮バイトのしきい値 | -| `storage.scheduler-worker-pool-size` | スケジューラスレッドプール内のスレッド数 | +| `ストレージ.block-cache.capacity` | 共有ブロックキャッシュのサイズ（v4.0.3以降でサポート） | +| ストレージ.フロー制御.有効 | フロー制御メカニズムを有効にするかどうかを決定します | +| ストレージ.フロー制御.memtables-threshold | フロー制御をトリガーするkvDB memtablesの最大数 | +| ストレージ.flow-control.l0-files-threshold | フロー制御をトリガーするkvDB L0ファイルの最大数 | +| ストレージ.flow-control.soft-pending-compaction-bytes-limit | フロー制御メカニズムが一部の書き込み要求を拒否するトリガーとなる、kvDB保留圧縮バイトのしきい値 | +| ストレージ.フロー制御.ハード保留圧縮バイト制限 | フロー制御メカニズムがすべての書き込み要求を拒否するトリガーとなる、kvDB保留圧縮バイトのしきい値 | +| `ストレージ.scheduler-worker-pool-size` | スケジューラスレッドプール内のスレッド数 | | `import.num-threads` | 復元またはインポート RPC 要求を処理するスレッドの数 (動的な変更は v8.1.2 以降でサポートされます) | | `backup.num-threads` | バックアップ スレッドの数 (v4.0.3 以降でサポート) | | `split.qps-threshold` | リージョンで`load-base-split`実行するためのしきい値。リージョンの読み取りリクエストのQPSが10秒連続で`qps-threshold`超える場合、このリージョンは分割される必要があります。 | @@ -241,7 +241,7 @@ show warnings; - `db-name`が`rocksdb`の場合、 `cf-name`のオプションの値は`defaultcf` 、 `writecf` 、 `lockcf` 、および`raftcf`です。 - `db-name`が`raftdb`とき、 `cf-name`の値は`defaultcf`になります。 -詳細なパラメータの説明については[TiKVコンフィグレーションファイル](/tikv-configuration-file.md)を参照してください。 +詳細なパラメータの説明については[TiKV設定ファイル](/tikv-configuration-file.md)を参照してください。 ### PD構成を動的に変更する {#modify-pd-configuration-dynamically} @@ -263,7 +263,7 @@ Query OK, 0 rows affected (0.01 sec) 次の PD 構成項目は動的に変更できます。 -| コンフィグレーション項目 | 説明 | +| 設定項目 | 説明 | | :--------------------------------------------------- | :--------------------------------------------------------- | | `log.level` | ログレベル | | `cluster-version` | クラスターバージョン | @@ -304,14 +304,14 @@ Query OK, 0 rows affected (0.01 sec) | `schedule.store-limit-version` | [店舗制限](/configure-store-limit.md)のバージョンを制御します | | `schedule.patrol-region-worker-count` | リージョンのヘルス状態を検査するときにチェッカーによって作成される同時オペレータの数を制御します | | `replication.max-replicas` | レプリカの最大数を設定します | -| `replication.location-labels` | TiKVクラスタのトポロジ情報 | +| `replication.location-labels` | TiKVクラスターのトポロジ情報 | | `replication.enable-placement-rules` | 配置ルールを有効にする | | `replication.strictly-match-label` | ラベルチェックを有効にする | -| `replication.isolation-level` | TiKVクラスタの最小トポロジカル分離レベル | -| `pd-server.use-region-storage` | 独立したリージョンstorageを有効にする | +| `replication.isolation-level` | TiKVクラスターの最小トポロジカル分離レベル | +| `pd-server.use-region-ストレージ` | 独立したリージョンストレージを有効にする | | `pd-server.max-gap-reset-ts` | タイムスタンプをリセットする最大間隔を設定します（BR） | -| `pd-server.key-type` | クラスタキータイプを設定します | -| `pd-server.metric-storage` | クラスターメトリックのstorageアドレスを設定します | +| `pd-server.key-type` | クラスターキータイプを設定します | +| `pd-server.metric-ストレージ` | クラスターメトリックのストレージアドレスを設定します | | `pd-server.dashboard-address` | ダッシュボードのアドレスを設定します | | `pd-server.flow-round-by-digit` | リージョンフロー情報の丸めの最小桁数を指定します | | `pd-server.min-resolved-ts-persistence-interval` | 最小解決タイムスタンプがPDに永続的に保持される間隔を決定します。 | @@ -329,7 +329,7 @@ Query OK, 0 rows affected (0.01 sec) | `replication-mode.dr-auto-sync.wait-recover-timeout` | ネットワークが回復した後、 `sync-recover`状態に戻るまでの待機時間 | | `replication-mode.dr-auto-sync.pause-region-split` | `async_wait`と`async`ステータスでリージョン分割操作を一時停止するかどうかを制御します | -詳細なパラメータの説明については[PDコンフィグレーションファイル](/pd-configuration-file.md)を参照してください。 +詳細なパラメータの説明については[PD設定ファイル](/pd-configuration-file.md)を参照してください。 ### TiDB構成を動的に変更する {#modify-tidb-configuration-dynamically} @@ -362,7 +362,7 @@ select @@tidb_slow_log_threshold; 次の TiDB 構成項目は動的に変更できます。 -| コンフィグレーション項目 | SQL変数 | 説明 | +| 設定項目 | SQL変数 | 説明 | | ------------------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------------------- | | `instance.tidb_enable_slow_log` | `tidb_enable_slow_log` | スローログを有効にするかどうかを制御します | | `instance.tidb_slow_log_threshold` | `tidb_slow_log_threshold` | スローログのしきい値を指定します | diff --git a/ecosystem-tool-user-case.md b/ecosystem-tool-user-case.md index 9551810da886a..73c33d1b7d2bc 100644 --- a/ecosystem-tool-user-case.md +++ b/ecosystem-tool-user-case.md @@ -29,7 +29,7 @@ MySQL/ Auroraから全データと増分データの両方を移行する必要 全データ量が大きい場合 (TB レベル)、最初に[Dumpling](/dumpling-overview.md)と[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)使用して全データ移行を実行し、次に DM を使用して増分データ移行を実行できます。 -## TiDB クラスタのバックアップと復元 {#back-up-and-restore-tidb-cluster} +## TiDB クラスターのバックアップと復元 {#back-up-and-restore-tidb-cluster} TiDB クラスターをバックアップする必要がある場合、またはバックアップしたデータをクラスターに復元する必要がある場合は、 [BR](/br/backup-and-restore-overview.md) (バックアップと復元) を使用します。 diff --git a/ecosystem-tool-user-guide.md b/ecosystem-tool-user-guide.md index 112c23b2eabef..bf8874683d782 100644 --- a/ecosystem-tool-user-guide.md +++ b/ecosystem-tool-user-guide.md @@ -15,18 +15,18 @@ TiDB は、さまざまなシステム環境での展開および運用のニー [TiUP](/tiup/tiup-overview.md)は、物理マシンまたは仮想マシン上のTiDBパッケージマネージャです。TiUPは、TiDB、PD、TiKVなどの複数のTiDBコンポーネントを管理できます。TiDBエコシステム内の任意のコンポーネントを起動するには、 TiUPコマンドを1行実行するだけです。 -TiUPは、 Golangで記述されたクラスタ管理コンポーネントで[TiUPクラスター](https://github.com/pingcap/tiup/tree/master/components/cluster)提供します。TiUPクラスタを使用することで、 TiUPクラスタのデプロイ、起動、停止、破棄、スケーリング、アップグレードといった日常的なデータベース操作や、TiDBクラスタパラメータの管理を容易に行うことができます。 +TiUPは、 Golangで記述されたクラスター管理コンポーネントで[TiUPクラスター](https://github.com/pingcap/tiup/tree/master/components/cluster)提供します。TiUPクラスターを使用することで、 TiUPクラスターのデプロイ、起動、停止、破棄、スケーリング、アップグレードといった日常的なデータベース操作や、TiDBクラスターパラメータの管理を容易に行うことができます。 TiUPの基本は次のとおりです。 - [用語と概念](/tiup/tiup-terminology-and-concepts.md) -- [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md) +- [TiUPを使用して TiDBクラスターをデプロイ](/production-deployment-using-tiup.md) - [TiUPコマンドを使用してTiUPコンポーネントを管理する](/tiup/tiup-component-management.md) - 適用可能な TiDB バージョン: v4.0 以降 ### Kubernetes 上で TiDBをデプロイて運用する - TiDB Operator {#deploy-and-operate-tidb-on-kubernetes-tidb-operator} -[TiDB Operator](https://github.com/pingcap/tidb-operator) 、Kubernetes上でTiDBクラスタを管理するための自動運用システムです。デプロイメント、アップグレード、スケーリング、バックアップ、設定変更など、TiDBのライフサイクル全体にわたる管理を提供します。TiDB Operatorを使用することで、パブリッククラウドまたはプライベートクラウドにデプロイされたKubernetesクラスタ内でTiDBをシームレスに実行できます。 +[TiDB Operator](https://github.com/pingcap/tidb-operator) 、Kubernetes上でTiDBクラスターを管理するための自動運用システムです。デプロイメント、アップグレード、スケーリング、バックアップ、設定変更など、TiDBのライフサイクル全体にわたる管理を提供します。TiDB Operatorを使用することで、パブリッククラウドまたはプライベートクラウドにデプロイされたKubernetesクラスター内でTiDBをシームレスに実行できます。 TiDB Operatorの基本は次のとおりです。 diff --git a/enable-disk-spill-encrypt.md b/enable-disk-spill-encrypt.md index 1f8113af7895e..1948016fde23b 100644 --- a/enable-disk-spill-encrypt.md +++ b/enable-disk-spill-encrypt.md @@ -5,7 +5,7 @@ summary: TiDB でディスク スピルの暗号化を有効にする方法を # ディスク流出時の暗号化機能を有効にする {#enable-encryption-for-disk-spill} -システム変数[`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom) `ON`に設定されている場合、単一の SQL ステートメントのメモリ使用量がシステム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)の制限を超えると、一部の演算子は実行中に中間結果を一時ファイルとしてディスクに保存し、クエリの完了後にそのファイルを削除することができます。 +システム変数[`tidb_enable_tmp_ストレージ_on_oom`](/system-variables.md#tidb_enable_tmp_ストレージ_on_oom) `ON`に設定されている場合、単一の SQL ステートメントのメモリ使用量がシステム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)の制限を超えると、一部の演算子は実行中に中間結果を一時ファイルとしてディスクに保存し、クエリの完了後にそのファイルを削除することができます。 ディスクスピルの暗号化を有効にすると、攻撃者がこれらの一時ファイルを読み取ってデータにアクセスするのを防ぐことができます。 diff --git a/enable-tls-between-clients-and-servers.md b/enable-tls-between-clients-and-servers.md index 0b3c4188f3512..db3b114d43c88 100644 --- a/enable-tls-between-clients-and-servers.md +++ b/enable-tls-between-clients-and-servers.md @@ -69,7 +69,7 @@ MySQL 8.x クライアントには、このパラメータに加えて 2 つの MySQL 5.7および MariaDB クライアント以前では、 `--ssl-verify-server-cert`使用してサーバー証明書の検証を有効にすることができます。 -詳細については、MySQL の[暗号化接続のクライアント側コンフィグレーション](https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration)参照してください。 +詳細については、MySQL の[暗号化接続のクライアント側設定](https://dev.mysql.com/doc/refman/8.0/en/using-encrypted-connections.html#using-encrypted-connections-client-side-configuration)参照してください。 ## 認証を有効にする {#enable-authentication} diff --git a/enable-tls-between-components.md b/enable-tls-between-components.md index 542c1180e5819..73f0d6d5b77d0 100644 --- a/enable-tls-between-components.md +++ b/enable-tls-between-components.md @@ -5,11 +5,11 @@ summary: TiDB コンポーネント間の TLS 認証を有効にする方法を # TiDB コンポーネント間の TLS を有効にする {#enable-tls-between-tidb-components} -このドキュメントでは、TiDBクラスタ内のコンポーネント間で暗号化されたデータ転送を有効にする方法について説明します。有効にすると、以下のコンポーネント間で暗号化された転送が使用されます。 +このドキュメントでは、TiDBクラスター内のコンポーネント間で暗号化されたデータ転送を有効にする方法について説明します。有効にすると、以下のコンポーネント間で暗号化された転送が使用されます。 - TiDB、TiKV、PD、 TiFlash間の通信 - TiDB コントロールと TiDB、 TiKV Controlと TiKV、 PD Controlと PD -- 各 TiDB、TiKV、PD、およびTiFlashクラスタ内の内部通信 +- 各 TiDB、TiKV、PD、およびTiFlashクラスター内の内部通信 現在、特定のコンポーネントの暗号化された送信のみを有効にすることはサポートされていません。 @@ -237,11 +237,11 @@ TiDBコンポーネント間の通信にTLSを設定したら、以下のコマ - TiProxy は 1 時間に 1 回、ディスクから証明書を再読み込みします。 -- TiDB クラスタを自社マネージドクラウドにデプロイしている場合は、TLS 証明書の発行がクラウドプロバイダーの証明書管理サービスと統合されていることを確認してください。TiDB、PD、TiKV、 TiFlash、および TiCDC コンポーネントの TLS 証明書は、TiDB クラスタを再起動することなく自動的にローテーションできます。 +- TiDB クラスターを自社マネージドクラウドにデプロイしている場合は、TLS 証明書の発行がクラウドプロバイダーの証明書管理サービスと統合されていることを確認してください。TiDB、PD、TiKV、 TiFlash、および TiCDC コンポーネントの TLS 証明書は、TiDB クラスターを再起動することなく自動的にローテーションできます。 ## 証明書の有効期限 {#certificate-validity} -TiDBクラスタ内の各コンポーネントのTLS証明書の有効期間をカスタマイズできます。例えば、OpenSSLを使用してTLS証明書を発行・生成する場合、 **days**パラメータを使用して有効期間を設定できます。詳細については、 [自己署名証明書を生成する](/generate-self-signed-certificates.md)参照してください。 +TiDBクラスター内の各コンポーネントのTLS証明書の有効期間をカスタマイズできます。例えば、OpenSSLを使用してTLS証明書を発行・生成する場合、 **days**パラメータを使用して有効期間を設定できます。詳細については、 [自己署名証明書を生成する](/generate-self-signed-certificates.md)参照してください。 ## 参照 {#see-also} diff --git a/encryption-at-rest.md b/encryption-at-rest.md index b3328b5203fe0..46b20766fcc7c 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -7,13 +7,13 @@ summary: 機密データを保護するために保存時の暗号化を有効 > **注記：** > -> クラスターがAWS上にデプロイされており、EBSstorageを使用している場合は、EBS暗号化を使用することをお勧めします。1 [AWS ドキュメント - EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)参照してください。AWS上でローカルNVMestorageなど、EBS以外のstorageを使用している場合は、このドキュメントで紹介されている保存時の暗号化を使用することをお勧めします。 +> クラスターがAWS上にデプロイされており、EBSストレージを使用している場合は、EBS暗号化を使用することをお勧めします。1 [AWS ドキュメント - EBS 暗号化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html)参照してください。AWS上でローカルNVMeストレージなど、EBS以外のストレージを使用している場合は、このドキュメントで紹介されている保存時の暗号化を使用することをお勧めします。 -保存時の暗号化とは、データが保存時に暗号化されることを意味します。データベースの場合、この機能はTDE（透過的データ暗号化）とも呼ばれます。これは、転送中の暗号化（TLS）や使用中の暗号化（ほとんど使用されません）とは対照的です。保存時の暗号化はSSDドライブ、ファイルシステム、クラウドベンダーなど、さまざまな方法で実行できますが、TiKVがstorage前に暗号化を行うことで、攻撃者がデータにアクセスするにはデータベースへの認証が必要となることを確実にします。例えば、攻撃者が物理マシンにアクセスできたとしても、ディスク上のファイルをコピーするだけではデータにアクセスできません。 +保存時の暗号化とは、データが保存時に暗号化されることを意味します。データベースの場合、この機能はTDE（透過的データ暗号化）とも呼ばれます。これは、転送中の暗号化（TLS）や使用中の暗号化（ほとんど使用されません）とは対照的です。保存時の暗号化はSSDドライブ、ファイルシステム、クラウドベンダーなど、さまざまな方法で実行できますが、TiKVがストレージ前に暗号化を行うことで、攻撃者がデータにアクセスするにはデータベースへの認証が必要となることを確実にします。例えば、攻撃者が物理マシンにアクセスできたとしても、ディスク上のファイルをコピーするだけではデータにアクセスできません。 ## さまざまな TiDB コンポーネントでの暗号化サポート {#encryption-support-in-different-tidb-components} -TiDBクラスタでは、コンポーネントごとに異なる暗号化方式が使用されます。このセクションでは、TiKV、 TiFlash、PD、バックアップ＆リストア（BR）など、TiDBの各コンポーネントにおける暗号化サポートについて説明します。 +TiDBクラスターでは、コンポーネントごとに異なる暗号化方式が使用されます。このセクションでは、TiKV、 TiFlash、PD、バックアップ＆リストア（BR）など、TiDBの各コンポーネントにおける暗号化サポートについて説明します。 TiDBクラスターをデプロイすると、ユーザーデータの大部分はTiKVノードとTiFlashノードに保存されます。一部のメタデータはPDノードに保存されます（例：TiKVリージョン境界として使用されるセカンダリインデックスキー）。保存データの暗号化のメリットを最大限に活用するには、すべてのコンポーネントで暗号化を有効にする必要があります。暗号化を実装する際には、バックアップ、ログファイル、ネットワーク経由で送信されるデータも考慮する必要があります。 @@ -25,9 +25,9 @@ TiKVは保存時の暗号化をサポートしています。この機能によ TiKVは現在、コアダンプから暗号鍵とユーザーデータを除外していません。保存時の暗号化を使用する場合は、TiKVプロセスのコアダンプを無効にすることをお勧めします。これは現在、TiKV自体では処理されていません。 -TiKVは、暗号化されたデータファイルをファイルの絶対パスを使用して追跡します。そのため、TiKVノードで暗号化が有効になった後は、ユーザーは`storage.data-dir`などのデータファイルパス設定を変更`rocksdb.wal-dir` `raftdb.wal-dir`で`raftstore.raftdb-path` 。 +TiKVは、暗号化されたデータファイルをファイルの絶対パスを使用して追跡します。そのため、TiKVノードで暗号化が有効になった後は、ユーザーは`ストレージ.data-dir`などのデータファイルパス設定を変更`rocksdb.wal-dir` `raftdb.wal-dir`で`raftstore.raftdb-path` 。 -SM4暗号化はTiKVバージョン6.3.0以降でのみサポートされます。TiKVバージョン6.3.0より前のバージョンではAES暗号化のみがサポートされます。SM4暗号化はパフォーマンスに影響を与えます。最悪の場合、スループットが50%～80%低下する可能性があります。ただし、 [`storage.block-cache`](/tikv-configuration-file.md#storageblock-cache)を十分に大きな値に設定することで、この影響を大幅に軽減し、スループットの低下を約10%に抑えることができます。 +SM4暗号化はTiKVバージョン6.3.0以降でのみサポートされます。TiKVバージョン6.3.0より前のバージョンではAES暗号化のみがサポートされます。SM4暗号化はパフォーマンスに影響を与えます。最悪の場合、スループットが50%～80%低下する可能性があります。ただし、 [`ストレージ.block-cache`](/tikv-configuration-file.md#ストレージblock-cache)を十分に大きな値に設定することで、この影響を大幅に軽減し、スループットの低下を約10%に抑えることができます。 ### TiFlash {#tiflash} @@ -62,7 +62,7 @@ TiKVは現在、 CTRモードでAES128、AES192、AES256、またはSM4（バー あるいは、カスタムキーを使用したい場合は、ファイル経由でマスターキーを提供することもできます。ファイルには、16進文字列としてエンコードされた256ビット（32バイト）のキーが含まれ、改行文字（つまり`\n` ）で終了し、他に何も含まれていない必要があります。ただし、キーをディスクに保存するとキーが漏洩するため、キーファイルはRAMの`tempfs`に保存するのに適しています。 -データキーは、基盤となるstorageエンジン（RocksDB）に渡されます。SSTファイル、WALファイル、MANIFESTファイルなど、RocksDBによって書き込まれるすべてのファイルは、現在のデータキーで暗号化されます。TiKVが使用するその他の一時ファイル（ユーザーデータが含まれる場合がある）も、同じデータキーを使用して暗号化されます。データキーは、デフォルトではTiKVによって毎週自動的にローテーションされますが、期間は設定可能です。キーのローテーションでは、TiKVは既存のすべてのファイルを書き換えてキーを置き換えるわけではありませんが、クラスターに一定の書き込みワークロードがかかっている場合、RocksDBの圧縮機能によって、最新のデータキーを使用して古いデータが新しいデータファイルに書き換えられることが期待されます。TiKVは、各ファイルの暗号化に使用されたキーと暗号化方式を追跡し、読み取り時にその情報を使用してコンテンツを復号化します。 +データキーは、基盤となるストレージエンジン（RocksDB）に渡されます。SSTファイル、WALファイル、MANIFESTファイルなど、RocksDBによって書き込まれるすべてのファイルは、現在のデータキーで暗号化されます。TiKVが使用するその他の一時ファイル（ユーザーデータが含まれる場合がある）も、同じデータキーを使用して暗号化されます。データキーは、デフォルトではTiKVによって毎週自動的にローテーションされますが、期間は設定可能です。キーのローテーションでは、TiKVは既存のすべてのファイルを書き換えてキーを置き換えるわけではありませんが、クラスターに一定の書き込みワークロードがかかっている場合、RocksDBの圧縮機能によって、最新のデータキーを使用して古いデータが新しいデータファイルに書き換えられることが期待されます。TiKVは、各ファイルの暗号化に使用されたキーと暗号化方式を追跡し、読み取り時にその情報を使用してコンテンツを復号化します。 データ暗号化方式に関わらず、データキーはGCMモードでAES256を使用して暗号化され、追加の認証を行います。そのため、KMSではなくファイルから渡す場合、マスターキーは256ビット（32バイト）である必要があります。 @@ -238,7 +238,7 @@ TiKVをGrafanaでデプロイしている場合は、保存時の暗号化を監 - 暗号化の初期化: TiKV起動時に暗号化が初期化された場合は1、それ以外の場合は0。マスターキーのローテーションの場合、暗号化が初期化された後は、TiKVは以前のマスターキーにアクセスする必要はありません。 - 暗号化データキー：既存のデータキーの数。データキーのローテーションが発生するたびに、この数は1ずつ増加します。この指標を使用して、データキーのローテーションが期待どおりに機能しているかどうかを監視します。 -- 暗号化ファイル: 現在存在する暗号化データファイルの数。この数とデータディレクトリ内の既存のデータファイル数を比較することで、暗号化されていないクラスタの暗号化を有効にする際に、暗号化されるデータの量を推定できます。 +- 暗号化ファイル: 現在存在する暗号化データファイルの数。この数とデータディレクトリ内の既存のデータファイル数を比較することで、暗号化されていないクラスターの暗号化を有効にする際に、暗号化されるデータの量を推定できます。 - 暗号化メタファイル サイズ: 暗号化メタデータ ファイルのサイズ。 - 読み取り/書き込み暗号化メタ期間: 暗号化のメタデータを操作するための追加のオーバーヘッド。 @@ -364,17 +364,17 @@ TiFlashもv4.0.9で暗号化メタデータ操作を最適化しており、そ BRを使用して S3 にバックアップする際に S3 サーバー側の暗号化を有効にするには、引数を`--s3.sse`渡し、値を "aws:kms" に設定します。S3 は暗号化に独自の KMS キーを使用します。例: - tiup br backup full --pd --storage "s3:///" --s3.sse aws:kms + tiup br backup full --pd --ストレージ "s3:///" --s3.sse aws:kms 独自に作成し所有するカスタム AWS KMS CMK を使用するには、 `--s3.sse-kms-key-id`追加で渡します。この場合、 BRプロセスとクラスター内のすべての TiKV ノードの両方が KMS CMK にアクセスする必要があり（例：AWS IAM経由）、KMS CMK はバックアップの保存に使用する S3 バケットと同じ AWS リージョンに存在する必要があります。BR プロセスと TiKV ノードにBR IAM経由で KMS CMK へのアクセスを許可することをお勧めします[IAMは](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html)の使用方法については、AWS ドキュメントを参照してください。例： - tiup br backup full --pd --storage "s3:///" --s3.sse aws:kms --s3.sse-kms-key-id 0987dcba-09fe-87dc-65ba-ab0987654321 + tiup br backup full --pd --ストレージ "s3:///" --s3.sse aws:kms --s3.sse-kms-key-id 0987dcba-09fe-87dc-65ba-ab0987654321 バックアップを復元する際、 `--s3.sse`と`--s3.sse-kms-key-id`両方を使用しないでください。S3は暗号化設定を自動的に判断します。バックアップを復元するクラスター内のBRプロセスとTiKVノードもKMS CMKにアクセスする必要があります。アクセスできない場合、復元は失敗します。例： - tiup br restore full --pd --storage "s3:///" + tiup br restore full --pd --ストレージ "s3:///" -## BR Azure Blob Storage サーバー側暗号化 {#br-azure-blob-storage-server-side-encryption} +## BR Azure Blob Storage サーバー側暗号化 {#br-azure-blob-ストレージ-server-side-encryption} BRを使用して Azure Blob Storage にデータをバックアップする場合、サーバー側の暗号化の暗号化スコープまたは暗号化キーのいずれかを指定できます。 @@ -385,21 +385,21 @@ BRを使用して Azure Blob Storage にデータをバックアップする場 - `backup`コマンドに`--azblob.encryption-scope`オプションを含め、スコープ名に設定します。 ```shell - tiup br backup full --pd --storage "azure:///" --azblob.encryption-scope scope1 + tiup br backup full --pd --ストレージ "azure:///" --azblob.encryption-scope scope1 ``` - URI に`encryption-scope`を含め、スコープ名に設定します。 ```shell - tiup br backup full --pd --storage "azure:///?encryption-scope=scope1" + tiup br backup full --pd --ストレージ "azure:///?encryption-scope=scope1" ``` -詳細については、Azure のドキュメントを参照してください: [暗号化スコープ付きのBLOBをアップロードする](https://learn.microsoft.com/en-us/azure/storage/blobs/encryption-scope-manage?tabs=powershell#upload-a-blob-with-an-encryption-scope) 。 +詳細については、Azure のドキュメントを参照してください: [暗号化スコープ付きのBLOBをアップロードする](https://learn.microsoft.com/en-us/azure/ストレージ/blobs/encryption-scope-manage?tabs=powershell#upload-a-blob-with-an-encryption-scope) 。 バックアップを復元する際に、暗号化の範囲を指定する必要はありません。Azure Blob Storage は自動的にデータを復号化します。例: ```shell -tiup br restore full --pd --storage "azure:///" +tiup br restore full --pd --ストレージ "azure:///" ``` ### 方法2: 暗号化キーを使用する {#method-2-use-an-encryption-key} @@ -409,41 +409,41 @@ tiup br restore full --pd --storage "azure:///" - `backup`コマンドに`--azblob.encryption-key`オプションを含め、AES256 暗号化キーを設定します。 ```shell - tiup br backup full --pd --storage "azure:///" --azblob.encryption-key + tiup br backup full --pd --ストレージ "azure:///" --azblob.encryption-key ``` - URIに`encryption-key`を含め、AES256暗号化キーを設定します。キーに`&`や`%`などのURI予約文字が含まれている場合は、事前にパーセントエンコードする必要があります。 ```shell - tiup br backup full --pd --storage "azure:///?encryption-key=" + tiup br backup full --pd --ストレージ "azure:///?encryption-key=" ``` - 環境変数`AZURE_ENCRYPTION_KEY`にAES256暗号化キーを設定します。実行前に、環境変数に設定された暗号化キーを忘れないように必ず覚えておいてください。 ```shell export AZURE_ENCRYPTION_KEY= - tiup br backup full --pd --storage "azure:///" + tiup br backup full --pd --ストレージ "azure:///" ``` -詳細については、Azure のドキュメントを参照してください: [Blobstorageへのリクエストに暗号化キーを提供する](https://learn.microsoft.com/en-us/azure/storage/blobs/encryption-customer-provided-keys) 。 +詳細については、Azure のドキュメントを参照してください: [Blobストレージへのリクエストに暗号化キーを提供する](https://learn.microsoft.com/en-us/azure/ストレージ/blobs/encryption-customer-provided-keys) 。 バックアップを復元する際には、暗号化キーを指定する必要があります。例： - `restore`コマンドに`--azblob.encryption-key`オプションを含めます。 ```shell - tiup br restore full --pd --storage "azure:///" --azblob.encryption-key + tiup br restore full --pd --ストレージ "azure:///" --azblob.encryption-key ``` - URIに`encryption-key`を含めます: ```shell - tiup br restore full --pd --storage "azure:///?encryption-key=" + tiup br restore full --pd --ストレージ "azure:///?encryption-key=" ``` - `AZURE_ENCRYPTION_KEY`環境変数を設定します。 ```shell export AZURE_ENCRYPTION_KEY= - tiup br restore full --pd --storage "azure:///" + tiup br restore full --pd --ストレージ "azure:///" ``` diff --git a/error-codes.md b/error-codes.md index f515b8e8c620b..88c1bc30b72d3 100644 --- a/error-codes.md +++ b/error-codes.md @@ -369,7 +369,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8158 - 指定されたパスは無効です。具体的な対処方法については、エラーメッセージを参照してください。Amazon S3 または GCS のパス設定については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 + 指定されたパスは無効です。具体的な対処方法については、エラーメッセージを参照してください。Amazon S3 または GCS のパス設定については、 [外部ストレージサービスのURI形式](/external-ストレージ-uri.md)参照してください。 - エラー番号: 8159 @@ -525,7 +525,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 - エラー番号: 8263 - このDDLは特定のBDRロールでは実行できません。クラスタが[双方向レプリケーション](/ticdc/ticdc-bidirectional-replication.md)になっていることを確認してください。クラスタが双方向レプリケーションになっていない場合は、 `ADMIN UNSET BDR ROLE;`使用してDDLを正常化できます。 + このDDLは特定のBDRロールでは実行できません。クラスターが[双方向レプリケーション](/ticdc/ticdc-bidirectional-replication.md)になっていることを確認してください。クラスターが双方向レプリケーションになっていない場合は、 `ADMIN UNSET BDR ROLE;`使用してDDLを正常化できます。 - エラー番号: 9001 @@ -579,7 +579,7 @@ TiDBはMySQLのエラーコードと互換性があり、ほとんどの場合 > **注記：** > - > 「30m」は、30 分前に生成されたデータのみをクリーンアップすることを意味します。これにより、追加のstorageスペースが消費される可能性があります。 + > 「30m」は、30 分前に生成されたデータのみをクリーンアップすることを意味します。これにより、追加のストレージスペースが消費される可能性があります。 - エラー番号: 9500 diff --git a/explain-joins.md b/explain-joins.md index 630c575b711a0..2a4409e1bb9cb 100644 --- a/explain-joins.md +++ b/explain-joins.md @@ -169,7 +169,7 @@ EXPLAIN ANALYZE SELECT * FROM t1 INNER JOIN t2 ON t1.id = t2.t1_id WHERE t1.int_ ヒント[`INL_JOIN`](/optimizer-hints.md#inl_joint1_name--tl_name-)使用したインデックス結合操作では、外部テーブルに結合する前に中間結果のハッシュテーブルが作成されます。TiDBは、ヒント[`INL_HASH_JOIN`](/optimizer-hints.md#inl_hash_join)を使用した外部テーブルへのハッシュテーブルの作成もサポートしています。これらのインデックス結合の各バリエーションは、SQLオプティマイザによって自動的に選択されます。 -### コンフィグレーション {#configuration} +### 設定 {#configuration} インデックス結合のパフォーマンスは、次のシステム変数の影響を受けます。 @@ -211,7 +211,7 @@ EXPLAIN SELECT /*+ HASH_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; ### 実行時統計 {#runtime-statistics} -[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) (デフォルト値: 1 GB) を超え、 [`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom)値が`ON` (デフォルト) の場合、TiDB は一時storageの使用を試み、ハッシュ結合の一部として使用される`Build`演算子をディスク上に作成する可能性があります。メモリ使用量などの実行時統計は、結果テーブル`EXPLAIN ANALYZE`の`execution info`に記録されます。次の例は、1 GB (デフォルト) と`tidb_mem_quota_query`の 500 MB のクォータで`EXPLAIN ANALYZE`実行した場合の出力を示しています。500 MB の場合、ディスクは一時storageとして使用されます。 +[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query) (デフォルト値: 1 GB) を超え、 [`tidb_enable_tmp_ストレージ_on_oom`](/system-variables.md#tidb_enable_tmp_ストレージ_on_oom)値が`ON` (デフォルト) の場合、TiDB は一時ストレージの使用を試み、ハッシュ結合の一部として使用される`Build`演算子をディスク上に作成する可能性があります。メモリ使用量などの実行時統計は、結果テーブル`EXPLAIN ANALYZE`の`execution info`に記録されます。次の例は、1 GB (デフォルト) と`tidb_mem_quota_query`の 500 MB のクォータで`EXPLAIN ANALYZE`実行した場合の出力を示しています。500 MB の場合、ディスクは一時ストレージとして使用されます。 ```sql EXPLAIN ANALYZE SELECT /*+ HASH_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; @@ -245,7 +245,7 @@ Query OK, 0 rows affected (0.00 sec) 5 rows in set (0.98 sec) ``` -### コンフィグレーション {#configuration} +### 設定 {#configuration} ハッシュ結合のパフォーマンスは、次のシステム変数の影響を受けます。 diff --git a/explain-mpp.md b/explain-mpp.md index 1e0068164ec30..97bbc20d42660 100644 --- a/explain-mpp.md +++ b/explain-mpp.md @@ -27,9 +27,9 @@ EXPLAIN SELECT COUNT(*) FROM t1 GROUP BY id; このクエリはMPPモードでは2つのフラグメントに分割されます。1つは第1段階の集計用、もう1つは第2段階の集計（最終集計）用です。このクエリが実行されると、各クエリフラグメントは1つ以上のMPPタスクにインスタンス化されます。 -## 取引所運営者 {#exchange-operators} +## エクスチェンジ演算子 {#exchange-operators} -`ExchangeReceiver`と`ExchangeSender` 、MPP実行プランに特有の2つの交換演算子です。4 演算子`ExchangeReceiver`下流のクエリフラグメントからデータを読み取り、 `ExchangeSender`演算子は下流のクエリフラグメントから上流のクエリフラグメントにデータを送信します。MPPモードでは、各MPPクエリフラグメントのルート演算子は`ExchangeSender`です。つまり、クエリフラグメントは`ExchangeSender`演算子によって区切られます。 +`ExchangeReceiver`と`ExchangeSender` 、MPP実行プランに特有の2つのエクスチェンジ演算子です。4 演算子`ExchangeReceiver`下流のクエリフラグメントからデータを読み取り、 `ExchangeSender`演算子は下流のクエリフラグメントから上流のクエリフラグメントにデータを送信します。MPPモードでは、各MPPクエリフラグメントのルート演算子は`ExchangeSender`です。つまり、クエリフラグメントは`ExchangeSender`演算子によって区切られます。 以下は単純な MPP 実行プランです。 diff --git a/explore-htap.md b/explore-htap.md index c951282c6734e..036338ebf75a8 100644 --- a/explore-htap.md +++ b/explore-htap.md @@ -3,7 +3,7 @@ title: Explore HTAP summary: TiDB HTAPの機能を探究し、活用する方法を学びましょう。 --- -# HTAPを探索する {#explore-htap} +# HTAP入門 {#explore-htap} このガイドでは、TiDB ハイブリッドトランザクションおよび分析処理 (HTAP) の機能の探索方法と使用方法について説明します。 @@ -35,7 +35,7 @@ TiDBの全体的なパフォーマンスを向上させるため、以下の技 - 分析処理性能を向上させる - アプリケーションに集計や結合操作などの複雑な分析クエリが含まれ、これらのクエリが大量のデータ（1,000万行以上）に対して実行される場合、これらのクエリ内のテーブルがインデックスを効果的に使用できないか、インデックスの選択性が低い場合、行ベースのstorageエンジン[ティクヴ](/tikv-overview.md)はパフォーマンス要件を満たせない可能性があります。 + アプリケーションに集計や結合操作などの複雑な分析クエリが含まれ、これらのクエリが大量のデータ（1,000万行以上）に対して実行される場合、これらのクエリ内のテーブルがインデックスを効果的に使用できないか、インデックスの選択性が低い場合、行ベースのストレージエンジン[TiKV](/tikv-overview.md)はパフォーマンス要件を満たせない可能性があります。 - ハイブリッドワークロードの分離 @@ -51,20 +51,20 @@ TiDBの全体的なパフォーマンスを向上させるため、以下の技 ## アーキテクチャ {#architecture} -TiDBでは、オンライン・トランザクション処理（OLTP）用の行ベースのstorageエンジン[ティクヴ](/tikv-overview.md)と、オンライン分析処理（OLAP）用の列ベースのstorageエンジンである[TiFlash](/tiflash/tiflash-overview.md)が共存し、データを自動的に複製し、強力な一貫性を維持します。 +TiDBでは、オンライン・トランザクション処理（OLTP）用の行ベースのストレージエンジン[TiKV](/tikv-overview.md)と、オンライン分析処理（OLAP）用の列ベースのストレージエンジンである[TiFlash](/tiflash/tiflash-overview.md)が共存し、データを自動的に複製し、強力な一貫性を維持します。 アーキテクチャの詳細については、 [TiDB HTAPのアーキテクチャ](/tiflash/tiflash-overview.md#architecture)を参照してください。 ## 環境準備 {#environment-preparation} -TiDB HTAPの機能を検討する前に、TiDBとそのカラム型storageエンジンであるTiFlashを導入する必要があります。データ量が大きい場合（例えば100テラバイト）、ソリューションとしてTiFlashの大規模並列処理（MPP）を使用することをお勧めします。 +TiDB HTAPの機能を検討する前に、TiDBとそのカラム型ストレージエンジンであるTiFlashを導入する必要があります。データ量が大きい場合（例えば100テラバイト）、ソリューションとしてTiFlashの大規模並列処理（MPP）を使用することをお勧めします。 - TiFlashノードのない TiDB クラスターをデプロイした場合は、現在の TiDB クラスターにTiFlashノードを追加します。詳細については、 [TiFlashクラスターをスケールアウトする](/scale-tidb-using-tiup.md#scale-out-a-tiflash-cluster)参照してください。 -- TiDB クラスターをデプロイしていない場合は、 [TiUPを使用してTiDBクラスタをデプロイ](/production-deployment-using-tiup.md)参照してください。最小限の TiDB トポロジーに基づいて、 [TiFlashのトポロジー](/tiflash-deployment-topology.md)もデプロイする必要があります。 +- TiDB クラスターをデプロイしていない場合は、 [TiUPを使用してTiDBクラスターをデプロイ](/production-deployment-using-tiup.md)参照してください。最小限の TiDB トポロジーに基づいて、 [TiFlashのトポロジー](/tiflash-deployment-topology.md)もデプロイする必要があります。 - TiFlashノードの数を決定する際には、以下のシナリオを考慮してください。 - 小規模な分析処理とアドホッククエリを伴うOLTPが必要な場合は、1台または複数台のTiFlashノードを導入してください。分析クエリの速度を劇的に向上させることができます。 - - OLTPのスループットがTiFlashノードのI/O使用率に大きな負荷をかけない場合、各TiFlashノードは計算により多くのリソースを使用するため、 TiFlashクラスタはほぼ線形のスケーラビリティを実現できます。TiFlashノードの数は、期待されるパフォーマンスと応答時間に基づいて調整する必要があります。 + - OLTPのスループットがTiFlashノードのI/O使用率に大きな負荷をかけない場合、各TiFlashノードは計算により多くのリソースを使用するため、 TiFlashクラスターはほぼ線形のスケーラビリティを実現できます。TiFlashノードの数は、期待されるパフォーマンスと応答時間に基づいて調整する必要があります。 - OLTPのスループットが比較的高い場合（例えば、書き込みまたは更新のスループットが1時間あたり1,000万行を超える場合）、ネットワークディスクと物理ディスクの書き込み容量が限られているため、TiKVとTiFlash間のI/Oがボトルネックとなり、読み書きのホットスポットが発生しやすくなります。この場合、 TiFlashノードの数は解析処理の計算量と複雑な非線形関係にあるため、システムの実際の状態に基づいてTiFlashノードの数を調整する必要があります。 >client: success ``` -1. クライアントが取引を開始します。 +1. クライアントがトランザクションを開始します。 TiDB は、現在のトランザクションの一意のトランザクション ID として、PD からタイムスタンプ (時間とともに単調増加し、グローバルに一意) を取得します。これを`start_ts`と呼びます。TiDB はマルチバージョン同時実行制御を実装しているため、 `start_ts`このトランザクションによって取得されたデータベース スナップショットのバージョンとしても機能します。つまり、トランザクションは`start_ts`のデータベースからのみデータを読み取ることができます。 @@ -115,9 +115,9 @@ sequenceDiagram > **注記：** > -> バージョン8.0.0以降、 [`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry)システム変数は非推奨となり、TiDBは楽観的トランザクションの自動再試行をサポートしなくなりました。[悲観的な取引モード](/pessimistic-transaction.md)使用をお勧めします。楽観的トランザクションの競合が発生した場合は、エラーを捕捉してアプリケーションでトランザクションを再試行できます。 +> バージョン8.0.0以降、 [`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry)システム変数は非推奨となり、TiDBは楽観的トランザクションの自動再試行をサポートしなくなりました。[悲観的なトランザクションモード](/pessimistic-transaction.md)使用をお勧めします。楽観的トランザクションの競合が発生した場合は、エラーを捕捉してアプリケーションでトランザクションを再試行できます。 -楽観的トランザクションモデルでは、競合が激しいシナリオで書き込み競合が発生し、トランザクションのコミットが失敗する可能性があります。TiDBはv3.0.8以降、MySQLと同様にデフォルトで[悲観的取引モード](/pessimistic-transaction.md)を使用します。これは、TiDBとMySQLが書き込みタイプのSQLステートメントの実行中にロックを追加し、Repeatable Read分離レベルによって現在の読み取りが可能になるため、コミット時に例外が発生しないことを意味します。 +楽観的トランザクションモデルでは、競合が激しいシナリオで書き込み競合が発生し、トランザクションのコミットが失敗する可能性があります。TiDBはv3.0.8以降、MySQLと同様にデフォルトで[悲観的トランザクションモード](/pessimistic-transaction.md)を使用します。これは、TiDBとMySQLが書き込みタイプのSQLステートメントの実行中にロックを追加し、Repeatable Read分離レベルによって現在の読み取りが可能になるため、コミット時に例外が発生しないことを意味します。 ### 自動再試行 {#automatic-retry} @@ -178,7 +178,7 @@ tidb_retry_limit = 10 ## 競合検出 {#conflict-detection} -分散データベースであるTiDBは、主に書き込み前段階で、TiKVレイヤーにおいてインメモリ競合検出を実行します。TiDBインスタンスはステートレスであり、互いの存在を認識しないため、自身の書き込みがクラスタ全体で競合を引き起こすかどうかを知ることはできません。したがって、競合検出はTiKVレイヤーで実行されます。 +分散データベースであるTiDBは、主に書き込み前段階で、TiKVレイヤーにおいてインメモリ競合検出を実行します。TiDBインスタンスはステートレスであり、互いの存在を認識しないため、自身の書き込みがクラスター全体で競合を引き起こすかどうかを知ることはできません。したがって、競合検出はTiKVレイヤーで実行されます。 構成は以下のとおりです。 diff --git a/optimizer-fix-controls.md b/optimizer-fix-controls.md index 67d7981289f0b..1b4a8cce13d97 100644 --- a/optimizer-fix-controls.md +++ b/optimizer-fix-controls.md @@ -81,7 +81,7 @@ SET SESSION tidb_opt_fix_control = '44262:ON,44389:ON'; - デフォルト値: `ON` 。v8.5.0 より前では、デフォルト値は`OFF`です。 - 可能`OFF`値: `ON` -- この変数は、強制されていないプランを見つけた後、クエリの最適化中にオプティマイザーが強制されているプランを探索するかどうかを制御します。 +- この変数は、強制されていないプランを見つけた後、クエリの最適化中にオプティマイザーが強制されているプランを確認するかどうかを制御します。 ### 47400バージョン8.4.0の新機能 {#a-href-https-github-com-pingcap-tidb-issues-47400-code-47400-code-a-span-class-version-mark-new-in-v8-4-0-span} diff --git a/optimizer-hints.md b/optimizer-hints.md index 7632763f26595..0be332037bb8e 100644 --- a/optimizer-hints.md +++ b/optimizer-hints.md @@ -232,7 +232,7 @@ SELECT /*+ SHUFFLE_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; > **注記：** > -> - このヒントを使用する前に、現在のTiDBクラスタがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 +> - このヒントを使用する前に、現在のTiDBクラスターがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 > - このヒントは、 [`HASH_JOIN_BUILD`ヒント](#hash_join_buildt1_name--tl_name-)および[`HASH_JOIN_PROBE`ヒント](#hash_join_probet1_name--tl_name-)と組み合わせて使用して、シャッフル結合アルゴリズムのビルド側とプローブ側を制御できます。 ### BROADCAST_JOIN(t1_name [, tl_name ...]) {#broadcast-join-t1-name-tl-name} @@ -245,7 +245,7 @@ SELECT /*+ BROADCAST_JOIN(t1, t2) */ * FROM t1, t2 WHERE t1.id = t2.id; > **注記：** > -> - このヒントを使用する前に、現在のTiDBクラスタがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 +> - このヒントを使用する前に、現在のTiDBクラスターがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 > - このヒントは、 [`HASH_JOIN_BUILD`ヒント](#hash_join_buildt1_name--tl_name-)および[`HASH_JOIN_PROBE`ヒント](#hash_join_probet1_name--tl_name-)と組み合わせて使用して、ブロードキャスト結合アルゴリズムのビルド側とプローブ側を制御できます。 ### NO_DECORRELATE() {#no-decorrelate} @@ -334,7 +334,7 @@ SELECT /*+ MPP_1PHASE_AGG() */ COUNT(*) FROM t1, t2 WHERE t1.a > 10 GROUP BY t1. > **注記：** > -> このヒントを使用する前に、現在のTiDBクラスタがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 +> このヒントを使用する前に、現在のTiDBクラスターがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 ### MPP_2PHASE_AGG() {#mpp-2phase-agg} @@ -346,7 +346,7 @@ SELECT /*+ MPP_2PHASE_AGG() */ COUNT(*) FROM t1, t2 WHERE t1.a > 10 GROUP BY t1. > **注記：** > -> このヒントを使用する前に、現在のTiDBクラスタがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 +> このヒントを使用する前に、現在のTiDBクラスターがクエリでTiFlash MPPモードの使用をサポートしていることを確認してください。詳細については、 [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください。 ### USE_INDEX(t1_name, idx1_name [, idx2_name ...]) {#use-index-t1-name-idx1-name-idx2-name} @@ -510,9 +510,9 @@ select /*+ AGG_TO_COP() */ sum(t1.a) from t t1; SELECT /*+ LIMIT_TO_COP() */ * FROM t WHERE a = 1 AND b > 10 ORDER BY c LIMIT 1; ``` -### READ_FROM_STORAGE(TIFLASH[t1_name [, tl_name ...]], TIKV[t2_name [, tl_name ...]]) {#read-from-storage-tiflash-t1-name-tl-name-tikv-t2-name-tl-name} +### READ_FROM_STORAGE(TIFLASH[t1_name [, tl_name ...]], TIKV[t2_name [, tl_name ...]]) {#read-from-ストレージ-tiflash-t1-name-tl-name-tikv-t2-name-tl-name} -ヒント`READ_FROM_STORAGE(TIFLASH[t1_name [, tl_name ...]], TIKV[t2_name [, tl_name ...]])`は、オプティマイザに特定のstorageエンジンから特定のテーブルを読み取るように指示します。現在、このヒントは`TIKV`と`TIFLASH`の2つのstorageエンジンパラメータをサポートしています。テーブルにエイリアスがある場合は、そのエイリアスを`READ_FROM_STORAGE()`のパラメータとして使用します。テーブルにエイリアスがない場合は、テーブルの元の名前をパラメータとして使用します。例： +ヒント`READ_FROM_STORAGE(TIFLASH[t1_name [, tl_name ...]], TIKV[t2_name [, tl_name ...]])`は、オプティマイザに特定のストレージエンジンから特定のテーブルを読み取るように指示します。現在、このヒントは`TIKV`と`TIFLASH`の2つのストレージエンジンパラメータをサポートしています。テーブルにエイリアスがある場合は、そのエイリアスを`READ_FROM_STORAGE()`のパラメータとして使用します。テーブルにエイリアスがない場合は、テーブルの元の名前をパラメータとして使用します。例： ```sql select /*+ READ_FROM_STORAGE(TIFLASH[t1], TIKV[t2]) */ t1.a from t t1, t t2 where t1.a = t2.a; diff --git a/overview.md b/overview.md index cc989e4a4b3d0..92f77ca226933 100644 --- a/overview.md +++ b/overview.md @@ -3,7 +3,7 @@ title: What is TiDB Self-Managed summary: TiDBの主な機能と使用例について学びましょう。 --- -# TiDBセルフマネージドとは何ですか？ {#what-is-tidb-self-managed} +# TiDB Self-Managedとは何ですか？ {#what-is-tidb-self-managed} @@ -54,7 +54,7 @@ PD設定ファイルは、コマンドラインパラメータよりも多くの ### initial-cluster {#code-initial-cluster-code} -- ブートストラップのための初期クラスタ構成 +- ブートストラップのための初期クラスター構成 - デフォルト値: `"{name}=http://{advertise-peer-url}"` - たとえば、 `name`が「pd」、 `advertise-peer-urls`が`"http://192.168.100.113:2380"`の場合、 `initial-cluster`は`"pd=http://192.168.100.113:2380"`なります。 - 3 つの PD サーバーを起動する必要がある場合、 `initial-cluster`は次のようになります。 @@ -80,7 +80,7 @@ PD設定ファイルは、コマンドラインパラメータよりも多くの ### quota-backend-bytes {#code-quota-backend-bytes-code} -- メタ情報データベースのstorageサイズはデフォルトで8GiBです +- メタ情報データベースのストレージサイズはデフォルトで8GiBです - デフォルト値: `8589934592` ### auto-compaction-mod {#code-auto-compaction-mod-code} @@ -125,7 +125,7 @@ PD設定ファイルは、コマンドラインパラメータよりも多くの ## pdサーバー {#pd-server} -pd-server関連のコンフィグレーション項目 +pd-server関連の設定項目 ### server-memory-limit v6.6.0 の新機能 {#code-server-memory-limit-code-span-class-version-mark-new-in-v6-6-0-span} @@ -191,7 +191,7 @@ pd-server関連のコンフィグレーション項目 ## 安全 {#security} -セキュリティ関連のコンフィグレーション項目 +セキュリティ関連の設定項目 ### cacert-path {#code-cacert-path-code} @@ -217,7 +217,7 @@ pd-server関連のコンフィグレーション項目 ## log {#code-log-code} -ログ関連のコンフィグレーション項目 +ログ関連の設定項目 ### level {#code-level-code} @@ -238,7 +238,7 @@ pd-server関連のコンフィグレーション項目 ## log.file {#code-log-file-code} -ログファイルに関連するコンフィグレーション項目 +ログファイルに関連する設定項目 ### max-size {#code-max-size-code} @@ -261,7 +261,7 @@ pd-server関連のコンフィグレーション項目 ## metric {#code-metric-code} -監視に関連するコンフィグレーション項目 +監視に関連する設定項目 ### interval {#code-interval-code} @@ -270,7 +270,7 @@ pd-server関連のコンフィグレーション項目 ## schedule {#code-schedule-code} -スケジュールに関連するコンフィグレーション項目 +スケジュールに関連する設定項目 > **注記：** > @@ -456,7 +456,7 @@ pd-server関連のコンフィグレーション項目 ## replication {#code-replication-code} -レプリカに関連するコンフィグレーション項目 +レプリカに関連する設定項目 ### max-replicas {#code-max-replicas-code} @@ -465,15 +465,15 @@ pd-server関連のコンフィグレーション項目 ### location-labels {#code-location-labels-code} -- TiKVクラスタのトポロジ情報 +- TiKVクラスターのトポロジ情報 - デフォルト値: `[]` -- [クラスタトポロジ構成](/schedule-replicas-by-topology-labels.md) +- [クラスタートポロジ構成](/schedule-replicas-by-topology-labels.md) ### isolation-level {#code-isolation-level-code} -- TiKVクラスタの最小トポロジカル分離レベル +- TiKVクラスターの最小トポロジカル分離レベル - デフォルト値: `""` -- [クラスタトポロジ構成](/schedule-replicas-by-topology-labels.md) +- [クラスタートポロジ構成](/schedule-replicas-by-topology-labels.md) ### strictly-match-label {#code-strictly-match-label-code} @@ -488,7 +488,7 @@ pd-server関連のコンフィグレーション項目 ## label-property （非推奨） {#code-label-property-code-deprecated} -ラベルに関連するコンフィグレーション項目`reject-leader`型のみをサポートします。 +ラベルに関連する設定項目`reject-leader`型のみをサポートします。 > **注記：** > @@ -506,7 +506,7 @@ pd-server関連のコンフィグレーション項目 ## dashboard {#code-dashboard-code} -[TiDBダッシュボード](/dashboard/dashboard-intro.md)内蔵 PD に関するコンフィグレーション項目です。 +[TiDBダッシュボード](/dashboard/dashboard-intro.md)内蔵 PD に関する設定項目です。 ### disable-custom-prom-addr {#code-disable-custom-prom-addr-code} @@ -546,7 +546,7 @@ pd-server関連のコンフィグレーション項目 ## replication-mode {#code-replication-mode-code} -全リージョンのレプリケーションモードに関するコンフィグレーション項目です。詳細は[DR自動同期モードを有効にする](/two-data-centers-in-one-city-deployment.md#enable-the-dr-auto-sync-mode)ご覧ください。 +全リージョンのレプリケーションモードに関する設定項目です。詳細は[DR自動同期モードを有効にする](/two-data-centers-in-one-city-deployment.md#enable-the-dr-auto-sync-mode)ご覧ください。 ## コントローラ {#controller} diff --git a/pd-control.md b/pd-control.md index af38553604eb0..6284de16ea350 100644 --- a/pd-control.md +++ b/pd-control.md @@ -393,7 +393,7 @@ config set service-middleware audit enable-audit false - `GetRegion` : 指定されたリージョンに関する情報を取得する - `GetStore` : 指定された店舗の情報を取得する -- `GetMembers` : PDクラスタメンバーに関する情報を取得する +- `GetMembers` : PDクラスターメンバーに関する情報を取得する gRPC API リクエストの最大レート（ `GetRegion` API リクエストなど）を制御するには、次のコマンドを実行します。 @@ -1103,7 +1103,7 @@ scheduler config balance-leader-scheduler set batch 3 // Set the size of the ope > **注記：** > - > クラスタコンポーネントがv5.2より前のバージョンの場合、 `query`次元の設定は有効になりません。一部のコンポーネントをv5.2以降にアップグレードした場合でも、 `byte`と`key`次元はデフォルトでホットリージョンスケジューリングの優先権を持ちます。クラスタのすべてのコンポーネントをv5.2以降にアップグレードした後も、互換性のためにこれらの設定は有効になります。7 `pd-ctl`を使用してリアルタイム設定を表示できます。通常、これらの設定を変更する必要はありません。 + > クラスターコンポーネントがv5.2より前のバージョンの場合、 `query`次元の設定は有効になりません。一部のコンポーネントをv5.2以降にアップグレードした場合でも、 `byte`と`key`次元はデフォルトでホットリージョンスケジューリングの優先権を持ちます。クラスターのすべてのコンポーネントをv5.2以降にアップグレードした後も、互換性のためにこれらの設定は有効になります。7 `pd-ctl`を使用してリアルタイム設定を表示できます。通常、これらの設定を変更する必要はありません。 ```bash scheduler config balance-hot-region-scheduler set read-priorities query,byte diff --git a/pd-microservices-deployment-topology.md b/pd-microservices-deployment-topology.md index c230996024e65..45b11f30a7d4c 100644 --- a/pd-microservices-deployment-topology.md +++ b/pd-microservices-deployment-topology.md @@ -9,7 +9,7 @@ summary: 最小限の TiDB トポロジに基づく PD マイクロサービス ## トポロジ情報 {#topology-information} -| 実例 | カウント | 物理マシン構成 | IP | コンフィグレーション | +| 実例 | カウント | 物理マシン構成 | IP | 設定 | | :------------- | :--- | :----------------------------- | :-------------------------------------- | :------------------------- | | TiDB | 2 | 16 VCore 32GB * 1 | 10.0.1.1
10.0.1.2 | デフォルトポート
グローバルディレクトリ構成 | | PD | 3 | 4 VCore 8GB * 1 | 10.0.1.3
10.0.1.4
10.0.1.5 | デフォルトポート
グローバルディレクトリ構成 | diff --git a/pd-microservices.md b/pd-microservices.md index 7d15867516ad5..afc0cd00bbcd3 100644 --- a/pd-microservices.md +++ b/pd-microservices.md @@ -5,7 +5,7 @@ summary: PD のマイクロサービス モードを有効にしてサービス # PDマイクロサービス {#pd-microservices} -バージョン8.0.0以降、PDはマイクロサービスモードをサポートします。このモードでは、PDのタイムスタンプ割り当て機能とクラスタスケジューリング関数が、独立してデプロイされた以下の2つのマイクロサービスに分割されます。これにより、これらの2つの関数はPDのルーティング機能から分離され、PDはメタデータのルーティングサービスに集中できるようになります。 +バージョン8.0.0以降、PDはマイクロサービスモードをサポートします。このモードでは、PDのタイムスタンプ割り当て機能とクラスタースケジューリング関数が、独立してデプロイされた以下の2つのマイクロサービスに分割されます。これにより、これらの2つの関数はPDのルーティング機能から分離され、PDはメタデータのルーティングサービスに集中できるようになります。 - `tso`マイクロサービス: クラスター全体に対して単調に増加するタイムスタンプ割り当てを提供します。 - `scheduling`マイクロサービス: 負荷分散、ホットスポット処理、レプリカ修復、レプリカ配置など、クラスター全体のスケジュール関数を提供します。 @@ -21,7 +21,7 @@ summary: PD のマイクロサービス モードを有効にしてサービス PDマイクロサービスは通常、PDにおけるパフォーマンスのボトルネックを解消し、PDサービスの品質を向上させるために使用されます。この機能により、以下の問題を回避できます。 - PD クラスターの過剰な圧力により、TSO 割り当てにおけるロングテールのレイテンシーまたはジッターが発生する -- スケジューリングモジュールの障害により、クラスタ全体のサービスが利用できなくなります +- スケジューリングモジュールの障害により、クラスター全体のサービスが利用できなくなります - PDのみに起因するボトルネックの問題 さらに、スケジューリング モジュールが変更された場合、PD を再起動せずに`scheduling`マイクロサービスを個別に更新できるため、クラスターのサービス全体への影響を回避できます。 diff --git a/pd-recover.md b/pd-recover.md index c7b7a4a093dd2..7bed8ffb84ac8 100644 --- a/pd-recover.md +++ b/pd-recover.md @@ -1,11 +1,11 @@ --- title: PD Recover User Guide -summary: PD Recover を使用すると、正常に起動またはサービスを提供できない PD クラスタを復旧できます。 +summary: PD Recover を使用すると、正常に起動またはサービスを提供できない PD クラスターを復旧できます。 --- # PDリカバリーユーザーガイド {#pd-recover-user-guide} -PD RecoverはPDのディザスタリカバリツールであり、正常に起動またはサービスを提供できないPDクラスタを復旧するために使用されます。 +PD RecoverはPDのディザスタリカバリツールであり、正常に起動またはサービスを提供できないPDクラスターを復旧するために使用されます。 ## ソースコードからコンパイル {#compile-from-source-code} @@ -20,15 +20,15 @@ PD RecoverはPDのディザスタリカバリツールであり、正常に起 PD Recover インストール パッケージはTiDB Toolkitに含まれています。TiDB Toolkit をダウンロードするには、 [TiDBツールをダウンロード](/download-ecosystem-tools.md)参照してください。 -以下のセクションでは、PDクラスタを復旧するための2つの方法、すなわち、稼働中のPDノードからの復旧と、PDクラスタ全体の再構築について説明します。 +以下のセクションでは、PDクラスターを復旧するための2つの方法、すなわち、稼働中のPDノードからの復旧と、PDクラスター全体の再構築について説明します。 -## 方法1：残存するPDノードを使用してPDクラスタを復旧する {#method-1-recover-a-pd-cluster-using-a-surviving-pd-node} +## 方法1：残存するPDノードを使用してPDクラスターを復旧する {#method-1-recover-a-pd-cluster-using-a-surviving-pd-node} -クラスタ内のPDノードの過半数で回復不能なエラーが発生すると、クラスタはサービスを提供できなくなります。PDノードが残っている場合は、残っているPDノードを選択し、 Raftグループのメンバーを強制的に変更することでサービスを復旧できます。手順は以下のとおりです。 +クラスター内のPDノードの過半数で回復不能なエラーが発生すると、クラスターはサービスを提供できなくなります。PDノードが残っている場合は、残っているPDノードを選択し、 Raftグループのメンバーを強制的に変更することでサービスを復旧できます。手順は以下のとおりです。 ### ステップ1：すべてのノードを停止する {#step-1-stop-all-nodes} -リカバリプロセス中にPDパラメータとの相互作用によって発生するデータ破損やその他の回復不能なエラーを防ぐため、クラスタ内のTiDB、TiKV、およびTiFlashプロセスを停止してください。 +リカバリプロセス中にPDパラメータとの相互作用によって発生するデータ破損やその他の回復不能なエラーを防ぐため、クラスター内のTiDB、TiKV、およびTiFlashプロセスを停止してください。 ### ステップ2：生存しているPDノードを起動する {#step-2-start-the-surviving-pd-node} @@ -45,7 +45,7 @@ PD Recover インストール パッケージはTiDB Toolkitに含まれてい ### ステップ3： pd-recoverを使用してメタデータを修復する {#step-3-repair-metadata-using-code-pd-recover-code} -この方法は少数派のPDノードがサービスを復旧することに依存するため、ノードに古いデータが含まれている可能性があります。1 `alloc_id` `tso`データがロールバックされると、クラスタデータが破損したり、利用できなくなったりする可能性があります。これを防ぐには、 `pd-recover`使用してメタデータを変更し、ノードが正しい割り当てIDとTSOサービスを提供できるようにする必要があります。以下に例を示します。 +この方法は少数派のPDノードがサービスを復旧することに依存するため、ノードに古いデータが含まれている可能性があります。1 `alloc_id` `tso`データがロールバックされると、クラスターデータが破損したり、利用できなくなったりする可能性があります。これを防ぐには、 `pd-recover`使用してメタデータを変更し、ノードが正しい割り当てIDとTSOサービスを提供できるようにする必要があります。以下に例を示します。 ```shell ./bin/pd-recover --from-old-member --endpoints=http://127.0.0.1:2379 # Specify the corresponding PD address @@ -53,7 +53,7 @@ PD Recover インストール パッケージはTiDB Toolkitに含まれてい > **注記：** > -> このステップでは、storage内の「 `alloc_id`が自動的に安全な値である`100000000`だけ増加します。その結果、後続のクラスタはより大きなIDを割り当てることになります。 +> このステップでは、ストレージ内の「 `alloc_id`が自動的に安全な値である`100000000`だけ増加します。その結果、後続のクラスターはより大きなIDを割り当てることになります。 > > さらに、手順`pd-recover`ではTSOは変更されません。したがって、この手順を実行する前に、ローカル時刻が障害発生時刻よりも後であることを確認し、障害発生前にPDコンポーネント間でNTPクロック同期サービスが有効になっていることを確認してください。有効になっていない場合は、TSOのロールバックを防ぐために、ローカルクロックを将来の時刻に調整する必要があります。 @@ -63,19 +63,19 @@ PD Recover インストール パッケージはTiDB Toolkitに含まれてい ### ステップ5：PDをスケールアウトしてクラスターを起動する {#step-5-scale-out-pd-and-start-the-cluster} -デプロイツールを使用してPDクラスタをスケールアウトし、クラスタ内の他のコンポーネントを起動します。これでPDサービスが利用可能になります。 +デプロイツールを使用してPDクラスターをスケールアウトし、クラスター内の他のコンポーネントを起動します。これでPDサービスが利用可能になります。 -## 方法2：PDクラスタを完全に再構築する {#method-2-entirely-rebuild-a-pd-cluster} +## 方法2：PDクラスターを完全に再構築する {#method-2-entirely-rebuild-a-pd-cluster} この方法は、PDデータがすべて失われたものの、TiDB、TiKV、 TiFlashなどの他のコンポーネントのデータは残っているようなシナリオに適用可能です。 ### ステップ1：クラスターIDを取得する {#step-1-get-cluster-id} -クラスタIDは、PD、TiKV、またはTiDBのログから取得できます。クラスタIDを取得するには、サーバー上でログを直接表示してください。 +クラスターIDは、PD、TiKV、またはTiDBのログから取得できます。クラスターIDを取得するには、サーバー上でログを直接表示してください。 -#### PDログからクラスタIDを取得する（推奨） {#get-cluster-id-from-pd-log-recommended} +#### PDログからクラスターIDを取得する（推奨） {#get-cluster-id-from-pd-log-recommended} -PDログからクラスタIDを取得するには、次のコマンドを実行します。 +PDログからクラスターIDを取得するには、次のコマンドを実行します。 ```bash grep "init cluster id" {{/path/to}}/pd.log @@ -86,9 +86,9 @@ grep "init cluster id" {{/path/to}}/pd.log ... ``` -#### TiDBログからクラスタIDを取得する {#get-cluster-id-from-tidb-log} +#### TiDBログからクラスターIDを取得する {#get-cluster-id-from-tidb-log} -TiDBログからクラスタIDを取得するには、次のコマンドを実行します。 +TiDBログからクラスターIDを取得するには、次のコマンドを実行します。 ```bash grep "init cluster id" {{/path/to}}/tidb.log @@ -99,9 +99,9 @@ grep "init cluster id" {{/path/to}}/tidb.log ... ``` -#### TiKVログからクラスタIDを取得する {#get-cluster-id-from-tikv-log} +#### TiKVログからクラスターIDを取得する {#get-cluster-id-from-tikv-log} -TiKVログからクラスタIDを取得するには、次のコマンドを実行します。 +TiKVログからクラスターIDを取得するには、次のコマンドを実行します。 ```bash grep "connect to PD cluster" {{/path/to}}/tikv.log @@ -135,7 +135,7 @@ grep "idAllocator allocates a new id" {{/path/to}}/pd*.log | awk -F'=' '{print または、上記のコマンドをすべてのPDサーバーで実行して、最大のサーバーを見つけることもできます。 -### ステップ3：新しいPDクラスタをデプロイ {#step-3-deploy-a-new-pd-cluster} +### ステップ3：新しいPDクラスターをデプロイ {#step-3-deploy-a-new-pd-cluster} 新しい PD クラスターをデプロイする前に、既存の PD クラスターを停止し、以前のデータ ディレクトリを削除するか、 `--data-dir`を使用して新しいデータ ディレクトリを指定する必要があります。 @@ -155,8 +155,8 @@ PDノード1でのみ`pd-recover`プログラムを実行してください。 ### クラスターIDを取得する際に、複数のクラスターIDが見つかりました。 {#multiple-cluster-ids-are-found-when-getting-the-cluster-id} -PDクラスタが作成されると、新しいクラスタIDが生成されます。古いクラスタのクラスタIDは、ログを確認することで確認できます。 +PDクラスターが作成されると、新しいクラスターIDが生成されます。古いクラスターのクラスターIDは、ログを確認することで確認できます。 ### pd-recoverを実行すると、エラー「 dial tcp 10.0.1.13:2379: connect: connection refusedが返されます。 {#the-error-code-dial-tcp-10-0-1-13-2379-connect-connection-refused-code-is-returned-when-executing-code-pd-recover-code} -PD サービスは、 `pd-recover`実行する際に必要です。PD Recover を使用する前に、PD クラスタをデプロイ起動してください。 +PD サービスは、 `pd-recover`実行する際に必要です。PD Recover を使用する前に、PD クラスターをデプロイ起動してください。 diff --git a/performance-tuning-methods.md b/performance-tuning-methods.md index c48c806d758f3..a54efeb753a20 100644 --- a/performance-tuning-methods.md +++ b/performance-tuning-methods.md @@ -137,7 +137,7 @@ TiDBは、SQL処理パスとデータベース時間を継続的に測定・収 - SQL フェーズ別のデータベース時間: ほとんどの時間は緑色の実行フェーズで消費されます。 - SQL 実行時間の概要: 紫色で表示される`tiflash_mpp`のリクエストは、SQL 実行中に最も多くの時間を消費します。次に、青色の`Cop`のリクエストを含む KV リクエストと、緑色の`Prewrite`番目のリクエストと`Commit`リクエストが続きます。 -### TiDB の主要メトリクスとクラスタ リソースの使用率 {#tidb-key-metrics-and-cluster-resource-utilization} +### TiDB の主要メトリクスとクラスター リソースの使用率 {#tidb-key-metrics-and-cluster-resource-utilization} #### 1秒あたりのクエリ数、1秒あたりのコマンド数、準備済みプランキャッシュ {#query-per-second-command-per-second-and-prepared-plan-cache} @@ -246,7 +246,7 @@ TiDB、TiKV、PDのCPU/メモリパネルでは、平均CPU、最大CPU、デル - トラフィックを読み取る - `TiDB -> Client` : TiDBからクライアントへの送信トラフィック統計 - - `Rocksdb -> TiKV` :storageレイヤー内での読み取り操作中に TiKV が RocksDB から取得するデータフロー + - `Rocksdb -> TiKV` :ストレージレイヤー内での読み取り操作中に TiKV が RocksDB から取得するデータフロー - トラフィックを書き込む @@ -328,7 +328,7 @@ TiDB、TiKV、PDのCPU/メモリパネルでは、平均CPU、最大CPU、デル - クライアントサーバーの構成が低すぎるため、CPU リソースが使い果たされています。 - HAProxy は TiDB クラスター プロキシとして使用され、HAProxy CPU リソースが使い果たされています。 - HAProxy は TiDB クラスター プロキシとして使用され、高ワークロードでは HAProxyサーバーのネットワーク帯域幅が消費されます。 -- アプリケーションサーバーからデータベースへのネットワークレイテンシーが高い。例えば、パブリッククラウド環境では、アプリケーションとTiDBクラスタが同じリージョンに存在しない、またはDNSワークロードバランサとTiDBクラスタが同じリージョンに存在しない場合、ネットワークレイテンシーが高くなります。 +- アプリケーションサーバーからデータベースへのネットワークレイテンシーが高い。例えば、パブリッククラウド環境では、アプリケーションとTiDBクラスターが同じリージョンに存在しない、またはDNSワークロードバランサとTiDBクラスターが同じリージョンに存在しない場合、ネットワークレイテンシーが高くなります。 - ボトルネックとなっているのはクライアントアプリケーションです。アプリケーションサーバーのCPUコアとNumaリソースを最大限に活用できていません。例えば、TiDBへの数千ものJDBC接続を確立するのに、たった1つのJVMしか使用されていません。 「接続数」パネルでは、総接続数と各TiDBノードの接続数を確認できます。これにより、総接続数が正常かどうか、また各TiDBノードの接続数が不均衡かどうかを確認できます。1 `active connections`アクティブな接続数を示し、これは1秒あたりのデータベース時間に相当します。右側のY軸（ `disconnection/s` ）は、クラスター内の1秒あたりの切断数を示しており、アプリケーションが短い接続を使用しているかどうかを判断するのに役立ちます。 @@ -341,7 +341,7 @@ TiDB、TiKV、PDのCPU/メモリパネルでは、平均CPU、最大CPU、デル - すべての SQL ステートメントの平均レイテンシーと P99レイテンシーは、それぞれ 10.8 ミリ秒と 84.1 ミリ秒です。 - トランザクション`avg-in-txn`の平均接続アイドル時間は 9.4 ミリ秒です。 -- クラスタへの総接続数は3,700で、各TiDBノードへの接続数は1,800です。アクティブ接続の平均数は40.3で、ほとんどの接続がアイドル状態であることを示しています。1 `disconnection/s`平均数は55.8で、アプリケーションが頻繁に接続と切断を繰り返していることを示しています。短い接続の動作は、TiDBのリソースと応答時間に一定の影響を与えます。 +- クラスターへの総接続数は3,700で、各TiDBノードへの接続数は1,800です。アクティブ接続の平均数は40.3で、ほとんどの接続がアイドル状態であることを示しています。1 `disconnection/s`平均数は55.8で、アプリケーションが頻繁に接続と切断を繰り返していることを示しています。短い接続の動作は、TiDBのリソースと応答時間に一定の影響を与えます。 **例2: TiDBがユーザー応答時間のボトルネックとなっている** @@ -423,30 +423,30 @@ TSO待機時間は`TSO WAIT`と記録され、TSO要求のネットワーク時 - 同じデータセンター内: 差は通常 2 ミリ秒未満です。 - 同じリージョン内の異なるアベイラビリティゾーンの場合: 差は通常 5 ミリ秒未満です。 -**例1: 同じデータセンターに展開されたクラスタのワークロードが低い** +**例1: 同じデータセンターに展開されたクラスターのワークロードが低い** ![Same Data Center](/media/performance/oltp_kv_tso.png) このワークロードでは、TiDBの平均`Prewrite`レイテンシーは925マイクロ秒、TiKV内の平均`kv_prewrite`処理レイテンシーは720マイクロ秒でした。この差は約200マイクロ秒で、これは同じデータセンターでは一般的な値です。TSOの平均待機レイテンシーは206マイクロ秒、RPC時間は144マイクロ秒でした。 -**例2: パブリッククラウドクラスタ上の通常のワークロード** +**例2: パブリッククラウドクラスター上の通常のワークロード** ![Cloud Env ](/media/performance/cloud_kv_tso.png) -この例では、TiDBクラスタは同じリージョン内の異なるデータセンターにデプロイされています。TiDBの平均`commit`レイテンシーは12.7ミリ秒、TiKV内の平均`kv_commit`処理レイテンシーは10.2ミリ秒で、約2.5ミリ秒の差があります。平均TSO待機レイテンシーは3.12ミリ秒、RPC時間は693マイクロ秒です。 +この例では、TiDBクラスターは同じリージョン内の異なるデータセンターにデプロイされています。TiDBの平均`commit`レイテンシーは12.7ミリ秒、TiKV内の平均`kv_commit`処理レイテンシーは10.2ミリ秒で、約2.5ミリ秒の差があります。平均TSO待機レイテンシーは3.12ミリ秒、RPC時間は693マイクロ秒です。 -**例3: パブリッククラウドクラスタのリソース過負荷** +**例3: パブリッククラウドクラスターのリソース過負荷** ![Cloud Env, TiDB Overloaded](/media/performance/cloud_kv_tso_overloaded.png) -この例では、TiDBクラスタは同一リージョン内の異なるデータセンターに展開されており、TiDBネットワークとCPUリソースが深刻な過負荷状態にあります。TiDBの平均`BatchGet`レイテンシーは38.6ms、TiKV内部の平均`kv_batch_get`処理レイテンシーは6.15msです。その差は32ms以上で、正常値を大幅に上回っています。平均TSO待機レイテンシーは9.45ms、RPC時間は14.3msです。 +この例では、TiDBクラスターは同一リージョン内の異なるデータセンターに展開されており、TiDBネットワークとCPUリソースが深刻な過負荷状態にあります。TiDBの平均`BatchGet`レイテンシーは38.6ms、TiKV内部の平均`kv_batch_get`処理レイテンシーは6.15msです。その差は32ms以上で、正常値を大幅に上回っています。平均TSO待機レイテンシーは9.45ms、RPC時間は14.3msです。 -#### ストレージ非同期書き込み期間、保存期間、適用期間 {#storage-async-write-duration-store-duration-and-apply-duration} +#### ストレージ非同期書き込み期間、保存期間、適用期間 {#ストレージ-async-write-duration-store-duration-and-apply-duration} TiKV は次の手順で書き込み要求を処理します。 - `scheduler worker`書き込み要求を処理し、トランザクションの一貫性チェックを実行し、書き込み要求を`raftstore`モジュールに送信するキーと値のペアに変換します。 -- TiKV コンセンサス モジュール`raftstore` 、 Raftコンセンサス アルゴリズムを適用して、storageレイヤー(複数の TiKV で構成) をフォールト トレラントにします。 +- TiKV コンセンサス モジュール`raftstore` 、 Raftコンセンサス アルゴリズムを適用して、ストレージレイヤー(複数の TiKV で構成) をフォールト トレラントにします。 Raftstore は`Store`スレッドと`Apply`スレッドで構成されています。 diff --git a/performance-tuning-overview.md b/performance-tuning-overview.md index 5436ea1ae5448..14d42744a20fd 100644 --- a/performance-tuning-overview.md +++ b/performance-tuning-overview.md @@ -86,7 +86,7 @@ summary: このドキュメントでは、ユーザー応答時間、スルー - CPU、IO、ネットワークなどのリソース使用率 -- アプリケーション構成、データベース構成、オペレーティング システム構成などのコンフィグレーション情報 +- アプリケーション構成、データベース構成、オペレーティング システム構成などの設定情報 ### ステップ3. ユーザー応答時間のボトルネックを特定する {#step-3-identify-bottlenecks-in-user-response-time} diff --git a/performance-tuning-practices.md b/performance-tuning-practices.md index f3c179f632440..24858f45a27df 100644 --- a/performance-tuning-practices.md +++ b/performance-tuning-practices.md @@ -64,7 +64,7 @@ TiDB は、TiDB ダッシュボードの[Top SQL](/dashboard/top-sql.md)と[継 - クエリ期間では、レイテンシー`execute`と`compile`割合が最も高くなります。 - 平均QPS = 56.8k -クラスタのリソース消費量を確認すると、TiDB CPUの平均使用率は925%、TiKV CPUの平均使用率は201%、TiKV IOの平均スループットは18.7 MB/sでした。TiDBのリソース消費量が大幅に高くなっています。 +クラスターのリソース消費量を確認すると、TiDB CPUの平均使用率は925%、TiKV CPUの平均使用率は201%、TiKV IOの平均スループットは18.7 MB/sでした。TiDBのリソース消費量が大幅に高くなっています。 ![performance-overview-2-for-query-interface](/media/performance/5.png) diff --git a/pessimistic-transaction.md b/pessimistic-transaction.md index b56e54cf91a7c..ed412a27e8217 100644 --- a/pessimistic-transaction.md +++ b/pessimistic-transaction.md @@ -9,11 +9,11 @@ TiDBを従来のデータベースに近い形で利用できるようにし、 > **注記：** > -> バージョン3.0.8以降、新規作成されたTiDBクラスタはデフォルトで悲観的トランザクションモードを使用します。ただし、既存のクラスタをバージョン3.0.7以前から3.0.8以降にアップグレードする場合は、この変更は影響しません。つまり、**悲観的トランザクションモードがデフォルトで使用されるのは、新規作成されたクラスタのみです**。 +> バージョン3.0.8以降、新規作成されたTiDBクラスターはデフォルトで悲観的トランザクションモードを使用します。ただし、既存のクラスターをバージョン3.0.7以前から3.0.8以降にアップグレードする場合は、この変更は影響しません。つまり、**悲観的トランザクションモードがデフォルトで使用されるのは、新規作成されたクラスターのみです**。 -## 取引モードを切り替える {#switch-transaction-mode} +## トランザクションモードを切り替える {#switch-transaction-mode} -トランザクションモードは、システム変数[`tidb_txn_mode`](/system-variables.md#tidb_txn_mode)設定することで変更できます。以下のコマンドは、クラスタ内で新しく作成されたセッションによって実行されるすべての明示的トランザクション（つまり、自動コミットされないトランザクション）を悲観的トランザクションモードに設定します。 +トランザクションモードは、システム変数[`tidb_txn_mode`](/system-variables.md#tidb_txn_mode)設定することで変更できます。以下のコマンドは、クラスター内で新しく作成されたセッションによって実行されるすべての明示的トランザクション（つまり、自動コミットされないトランザクション）を悲観的トランザクションモードに設定します。 ```sql SET GLOBAL tidb_txn_mode = 'pessimistic'; @@ -67,7 +67,7 @@ TiDB の悲観的なトランザクションは、MySQL のトランザクショ - トランザクションは、新しいロックを取得するために最大`innodb_lock_wait_timeout`秒 (デフォルト: 50) 待機します。このタイムアウトに達すると、MySQL 互換のエラー コード`1205`が返されます。複数のトランザクションが同じロックを待機している場合、優先順位はトランザクションの`start ts`に基づいておおよそ決定されます。 -- TiDBは、同一クラスタ内で楽観的トランザクションモードと悲観的トランザクションモードの両方をサポートしています。トランザクションの実行には、どちらのモードでも指定できます。 +- TiDBは、同一クラスター内で楽観的トランザクションモードと悲観的トランザクションモードの両方をサポートしています。トランザクションの実行には、どちらのモードでも指定できます。 - TiDBは`FOR UPDATE NOWAIT`構文をサポートしており、ロックが解放されるまでブロックして待機しません。代わりに、MySQL互換のエラーコード`3572`が返されます。 @@ -239,7 +239,7 @@ sequenceDiagram -アプリケーションロジックがロックまたはロック待機メカニズムに依存している場合、あるいはTiKVクラスタの異常が発生した場合でもトランザクションコミットの成功率を可能な限り保証したい場合は、パイプラインロック機能を無効にする必要があります。 +アプリケーションロジックがロックまたはロック待機メカニズムに依存している場合、あるいはTiKVクラスターの異常が発生した場合でもトランザクションコミットの成功率を可能な限り保証したい場合は、パイプラインロック機能を無効にする必要があります。 ```mermaid --- @@ -298,9 +298,9 @@ TiKV v6.0.0では、インメモリ悲観的ロック機能が導入されまし -インメモリ悲観的ロックは、パイプラインによるロック処理と同様の動作をし、クラスタが正常な状態ではロックの取得に影響を与えません。しかし、TiKVでネットワーク分離が発生した場合、またはTiKVノードがダウンした場合、取得した悲観的ロックが失われる可能性があります。 +インメモリ悲観的ロックは、パイプラインによるロック処理と同様の動作をし、クラスターが正常な状態ではロックの取得に影響を与えません。しかし、TiKVでネットワーク分離が発生した場合、またはTiKVノードがダウンした場合、取得した悲観的ロックが失われる可能性があります。 -アプリケーションロジックがロック取得またはロック待機メカニズムに依存している場合、あるいはクラスタが異常状態にある場合でもトランザクションコミットの成功率を可能な限り保証したい場合は、インメモリ悲観的ロック機能**を無効にする**必要があります。 +アプリケーションロジックがロック取得またはロック待機メカニズムに依存している場合、あるいはクラスターが異常状態にある場合でもトランザクションコミットの成功率を可能な限り保証したい場合は、インメモリ悲観的ロック機能**を無効にする**必要があります。 この機能はデフォルトで有効になっています。無効にするには、TiKVの設定を変更してください。 diff --git a/pipelined-dml.md b/pipelined-dml.md index 207028d8d4707..7bf60461c25d8 100644 --- a/pipelined-dml.md +++ b/pipelined-dml.md @@ -13,7 +13,7 @@ summary: パイプラインDMLのユースケース、メソッド、制限事 ## 概要 {#overview} -パイプラインDMLは、大規模データ書き込み操作のパフォーマンスを向上させるためにTiDB v8.0.0で導入された実験的機能です。この機能を有効にすると、TiDBはDML操作中にデータをメモリに完全にバッファリングするのではなく、storageレイヤーに直接ストリーミングします。このパイプラインのようなアプローチは、データの読み取り（入力）とstorageレイヤーへの書き込み（出力）を同時に行うことで、大規模DML操作における一般的な課題を以下のように効果的に解決します。 +パイプラインDMLは、大規模データ書き込み操作のパフォーマンスを向上させるためにTiDB v8.0.0で導入された実験的機能です。この機能を有効にすると、TiDBはDML操作中にデータをメモリに完全にバッファリングするのではなく、ストレージレイヤーに直接ストリーミングします。このパイプラインのようなアプローチは、データの読み取り（入力）とストレージレイヤーへの書き込み（出力）を同時に行うことで、大規模DML操作における一般的な課題を以下のように効果的に解決します。 - メモリ制限: 従来の DML 操作では、大規模なデータセットを処理するときにメモリ不足 (OOM) エラーが発生する可能性があります。 - パフォーマンスのボトルネック: 大規模なトランザクションは非効率になることが多く、ワークロードの変動を引き起こしやすくなります。 diff --git a/placement-rules-in-sql.md b/placement-rules-in-sql.md index 28c61bead0924..7e428490a694e 100644 --- a/placement-rules-in-sql.md +++ b/placement-rules-in-sql.md @@ -5,7 +5,7 @@ summary: SQL文を使用してテーブルとパーティションの配置を # SQLにおける配置ルール {#placement-rules-in-sql} -SQLの配置ルールは、SQL文を使用してTiKVクラスタ内のデータの保存場所を指定できる機能です。この機能を使用すると、クラスタ、データベース、テーブル、またはパーティションのデータを、特定のリージョン、データセンター、ラック、またはホストにスケジュールできます。 +SQLの配置ルールは、SQL文を使用してTiKVクラスター内のデータの保存場所を指定できる機能です。この機能を使用すると、クラスター、データベース、テーブル、またはパーティションのデータを、特定のリージョン、データセンター、ラック、またはホストにスケジュールできます。 この機能は、以下のユースケースに対応できます。 @@ -23,7 +23,7 @@ SQL の配置ルール機能を使用すると、配置ポリシー[配置ポリ | レベル | 説明 | | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| クラスタ | デフォルトでは、TiDB はクラスターに対して 3 つのレプリカのポリシーを構成します。クラスターのグローバル配置ポリシーを構成できます。詳細については、 [クラスターのレプリカ数をグローバルに指定します。](#specify-the-number-of-replicas-globally-for-a-cluster)参照してください。 | +| クラスター | デフォルトでは、TiDB はクラスターに対して 3 つのレプリカのポリシーを構成します。クラスターのグローバル配置ポリシーを構成できます。詳細については、 [クラスターのレプリカ数をグローバルに指定します。](#specify-the-number-of-replicas-globally-for-a-cluster)参照してください。 | | データベース | 特定のデータベースの配置ポリシーを構成できます。詳細については、 [データベースのデフォルトの配置ポリシーを指定します。](#specify-a-default-placement-policy-for-a-database)参照してください。 | | テーブル | 特定のテーブルの配置ポリシーを構成できます。詳細については、[テーブルの配置ポリシーを指定します。](#specify-a-placement-policy-for-a-table)参照してください。 | | パーティション | テーブル内のさまざまな行にパーティションを作成し、パーティションの配置ポリシーを個別に構成できます。詳細については、 [パーティションテーブルの配置ポリシーを指定します。](#specify-a-placement-policy-for-a-partitioned-table)参照してください。 | @@ -44,7 +44,7 @@ SQL の配置ルール機能を使用すると、配置ポリシー[配置ポリ -配置ポリシーを作成する際、TiDB はポリシーで指定されたラベルが存在するかどうかをチェックしません。代わりに、TiDB はポリシーをアタッチする際にチェックを実行します。したがって、配置ポリシーをアタッチする前に、各 TiKV ノードに正しいラベルが設定されていることを確認してください。TiDB セルフマネージド クラスタの構成方法は以下のとおりです。 +配置ポリシーを作成する際、TiDB はポリシーで指定されたラベルが存在するかどうかをチェックしません。代わりに、TiDB はポリシーをアタッチする際にチェックを実行します。したがって、配置ポリシーをアタッチする前に、各 TiKV ノードに正しいラベルが設定されていることを確認してください。TiDB Self-Managed クラスターの構成方法は以下のとおりです。 tikv-server --labels region=,zone=,host= @@ -54,7 +54,7 @@ SQL の配置ルール機能を使用すると、配置ポリシー[配置ポリ | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | 手動展開 | [トポロジーラベルに基づいてレプリカをスケジュールする](/schedule-replicas-by-topology-labels.md) | | TiUPを使用した展開 | [地理的に分散した展開トポロジー](/geo-distributed-deployment-topology.md) | -| TiDB Operatorを使用したデプロイメント | [KubernetesでTiDBクラスタを構成する](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster#high-availability-of-data) | +| TiDB Operatorを使用したデプロイメント | [KubernetesでTiDBクラスターを構成する](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster#high-availability-of-data) | > **注記：** > @@ -135,7 +135,7 @@ SHOW PLACEMENT LABELS; 1 row in set (0.00 sec) ``` -- クラスタ内の配置ポリシーの定義を表示するには、 [`INFORMATION_SCHEMA.PLACEMENT_POLICIES`](/information-schema/information-schema-placement-policies.md)システム テーブルをクエリします。 +- クラスター内の配置ポリシーの定義を表示するには、 [`INFORMATION_SCHEMA.PLACEMENT_POLICIES`](/information-schema/information-schema-placement-policies.md)システム テーブルをクエリします。 ```sql SELECT * FROM information_schema.placement_policies\G @@ -155,13 +155,13 @@ SHOW PLACEMENT LABELS; 1 row in set ``` -- クラスタ内の配置ポリシーに関連付けられているすべてのテーブルを表示するには、 `tidb_placement_policy_name`システムテーブルの`information_schema.tables`列をクエリします。 +- クラスター内の配置ポリシーに関連付けられているすべてのテーブルを表示するには、 `tidb_placement_policy_name`システムテーブルの`information_schema.tables`列をクエリします。 ```sql SELECT * FROM information_schema.tables WHERE tidb_placement_policy_name IS NOT NULL; ``` -- クラスタ内の配置ポリシーが関連付けられているすべてのパーティションを表示するには、 `tidb_placement_policy_name`システムテーブルの`information_schema.partitions`列をクエリします。 +- クラスター内の配置ポリシーが関連付けられているすべてのパーティションを表示するには、 `tidb_placement_policy_name`システムテーブルの`information_schema.partitions`列をクエリします。 ```sql SELECT * FROM information_schema.partitions WHERE tidb_placement_policy_name IS NOT NULL; @@ -212,15 +212,15 @@ DROP PLACEMENT POLICY myplacementpolicy; ### 高度な配置オプション {#advanced-placement-options} -高度な構成オプションを使用すると、複雑なシナリオの要件を満たすために、データの配置に関してより柔軟な設定が可能になります。ただし、高度なオプションの設定は通常のオプションよりも複雑であり、クラスタトポロジーとTiDBのデータシャーディングに関する深い理解が必要です。 +高度な構成オプションを使用すると、複雑なシナリオの要件を満たすために、データの配置に関してより柔軟な設定が可能になります。ただし、高度なオプションの設定は通常のオプションよりも複雑であり、クラスタートポロジーとTiDBのデータシャーディングに関する深い理解が必要です。 | オプション名 | 説明 | | ---------------------- | ---------------------------------------------------------------------------- | | `CONSTRAINTS` | すべての役割に適用される制約のリスト。例: `CONSTRAINTS="[+disk=ssd]"` 。 | | `LEADER_CONSTRAINTS` | Leaderにのみ適用される制約のリスト。 | | `FOLLOWER_CONSTRAINTS` | フォロワーにのみ適用される制約事項のリスト。 | -| `LEARNER_CONSTRAINTS` | 学習者のみに適用される制約事項のリスト。 | -| `LEARNERS` | 学習者の数。 | +| `LEARNER_CONSTRAINTS` | ラーナーのみに適用される制約事項のリスト。 | +| `LEARNERS` | ラーナーの数。 | | `SURVIVAL_PREFERENCE` | ラベルの災害耐性レベルに応じたレプリカ配置の優先順位。例： `SURVIVAL_PREFERENCE="[region, zone, host]"` 。 | ### 制約形式 {#constraints-formats} @@ -295,25 +295,25 @@ ALTER TABLE t PLACEMENT POLICY=default; -- Removes the placement policy 'five_re パーティションテーブルまたはパーティションに対して、配置ポリシーを指定することもできます。例： ```sql -CREATE PLACEMENT POLICY storageforhistorydata CONSTRAINTS="[+node=history]"; -CREATE PLACEMENT POLICY storagefornewdata CONSTRAINTS="[+node=new]"; +CREATE PLACEMENT POLICY ストレージforhistorydata CONSTRAINTS="[+node=history]"; +CREATE PLACEMENT POLICY ストレージfornewdata CONSTRAINTS="[+node=new]"; CREATE PLACEMENT POLICY companystandardpolicy CONSTRAINTS=""; CREATE TABLE t1 (id INT, name VARCHAR(50), purchased DATE, UNIQUE INDEX idx(id) GLOBAL) PLACEMENT POLICY=companystandardpolicy PARTITION BY RANGE( YEAR(purchased) ) ( - PARTITION p0 VALUES LESS THAN (2000) PLACEMENT POLICY=storageforhistorydata, + PARTITION p0 VALUES LESS THAN (2000) PLACEMENT POLICY=ストレージforhistorydata, PARTITION p1 VALUES LESS THAN (2005), PARTITION p2 VALUES LESS THAN (2010), PARTITION p3 VALUES LESS THAN (2015), - PARTITION p4 VALUES LESS THAN MAXVALUE PLACEMENT POLICY=storagefornewdata + PARTITION p4 VALUES LESS THAN MAXVALUE PLACEMENT POLICY=ストレージfornewdata ); ``` テーブル内のパーティションに配置ポリシーが指定されていない場合、パーティションはテーブルからポリシー（存在する場合）を継承しようとします。テーブルに[グローバルインデックス](/global-indexes.md)がある場合、インデックスはテーブルと同じ配置ポリシーを適用します。上記の例では、次のようになります。 -- `p0`パーティションには`storageforhistorydata`ポリシーが適用されます。 -- `p4`パーティションには`storagefornewdata`ポリシーが適用されます。 +- `p0`パーティションには`ストレージforhistorydata`ポリシーが適用されます。 +- `p4`パーティションには`ストレージfornewdata`ポリシーが適用されます。 - `p1` 、 `p2` 、および`p3`パーティションは、テーブル`companystandardpolicy`から継承された`t1`ポリシーを適用します。 - グローバルインデックス`idx`は、テーブル`companystandardpolicy`と同じ`t1`配置ポリシーを適用します。 - テーブル`t1`に対して配置ポリシーが指定されていない場合、 `p1` 、 `p2` 、 `p3`パーティションとグローバルインデックス`idx`データベースのデフォルトポリシーまたはグローバルのデフォルトポリシーを継承します。 @@ -321,7 +321,7 @@ PARTITION BY RANGE( YEAR(purchased) ) ( これらのパーティションに配置ポリシーを適用した後、次の例のように、特定のパーティションの配置ポリシーを変更できます。 ```sql -ALTER TABLE t1 PARTITION p1 PLACEMENT POLICY=storageforhistorydata; +ALTER TABLE t1 PARTITION p1 PLACEMENT POLICY=ストレージforhistorydata; ``` ## 高可用性の例 {#high-availability-examples} @@ -350,7 +350,7 @@ SELECT store_id,address,label from INFORMATION_SCHEMA.TIKV_STORE_STATUS; データの正確な分散方法には特にこだわらず、ディザスタリカバリ要件を満たすことを優先する場合は、 `SURVIVAL_PREFERENCES`オプションを使用して、データの生存に関する設定を指定できます。 -前述の例と同様に、TiDB クラスタは 3 つのリージョンに分散され、各リージョンには 3 つのゾーンが含まれています。このクラスタの配置ポリシーを作成する場合、 `SURVIVAL_PREFERENCES`を次のように構成することを想定します。 +前述の例と同様に、TiDB クラスターは 3 つのリージョンに分散され、各リージョンには 3 つのゾーンが含まれています。このクラスターの配置ポリシーを作成する場合、 `SURVIVAL_PREFERENCES`を次のように構成することを想定します。 ```sql CREATE PLACEMENT POLICY multiaz SURVIVAL_PREFERENCES="[region, zone, host]"; @@ -410,7 +410,7 @@ SHOW PLACEMENT; CREATE PLACEMENT POLICY deploy221_primary_east1 LEADER_CONSTRAINTS="[+region=us-east-1]" FOLLOWER_CONSTRAINTS='{"+region=us-east-1": 1, "+region=us-east-2": 2, "+region=us-west-1": 1}'; ``` -この配置ポリシーが作成され、目的のデータに適用されると、データのRaftLeaderレプリカは`us-east-1`オプションで指定された`LEADER_CONSTRAINTS`リージョンに配置され、その他のデータのレプリカは`FOLLOWER_CONSTRAINTS`オプションで指定されたリージョンに配置されます。クラスターが障害を起こした場合（たとえば、 `us-east-1`リージョンでノードが停止した場合など）、これらのリージョン`FOLLOWER_CONSTRAINTS`で指定されていても、他のリージョンから新しいLeaderが選出されることに注意してください。つまり、サービスの可用性を確保することが最優先事項となります。 +この配置ポリシーが作成され、目的のデータに適用されると、データのRaftリーダーレプリカは`us-east-1`オプションで指定された`LEADER_CONSTRAINTS`リージョンに配置され、その他のデータのレプリカは`FOLLOWER_CONSTRAINTS`オプションで指定されたリージョンに配置されます。クラスターが障害を起こした場合（たとえば、 `us-east-1`リージョンでノードが停止した場合など）、これらのリージョン`FOLLOWER_CONSTRAINTS`で指定されていても、他のリージョンから新しいLeaderが選出されることに注意してください。つまり、サービスの可用性を確保することが最優先事項となります。 `us-east-1`領域で障害が発生した場合、 `us-west-1`に新しいリーダーを配置したくない場合は、特別な`evict-leader`属性を設定して、その領域で新たに選出されたリーダーを排除することができます。 @@ -420,7 +420,7 @@ CREATE PLACEMENT POLICY deploy221_primary_east1 LEADER_CONSTRAINTS="[+region=us- #### PRIMARY_REGIONを使用する {#use-code-primary-region-code} -クラスタトポロジに`region`ラベルが設定されている場合、 `PRIMARY_REGION`および`REGIONS`オプションを使用して、フォロワーの配置ポリシーを指定することもできます。 +クラスタートポロジに`region`ラベルが設定されている場合、 `PRIMARY_REGION`および`REGIONS`オプションを使用して、フォロワーの配置ポリシーを指定することもできます。 ```sql CREATE PLACEMENT POLICY eastandwest PRIMARY_REGION="us-east-1" REGIONS="us-east-1,us-east-2,us-west-1" SCHEDULE="MAJORITY_IN_PRIMARY" FOLLOWERS=4; @@ -430,7 +430,7 @@ CREATE TABLE t1 (a INT) PLACEMENT POLICY=eastandwest; - `PRIMARY_REGION`リーダーの配布地域を指定します。このオプションでは、1 つの地域のみを指定できます。 - `SCHEDULE`オプションは、TiDB がフォロワーの分布をどのようにバランスさせるかを指定します。 - デフォルトの`EVEN`スケジューリングルールは、すべてのリージョンにわたってフォロワーが均等に分散されることを保証します。 - - `PRIMARY_REGION` (つまり`us-east-1` ) に十分な数のFollowerレプリカを配置したい場合は、 `MAJORITY_IN_PRIMARY`スケジューリングルールを使用できます。このスケジューリングルールは、可用性を多少犠牲にする代わりに、トランザクションのレイテンシーを低減します。プライマリリージョンが障害を起こした場合、 `MAJORITY_IN_PRIMARY`自動フェイルオーバーを提供しません。 + - `PRIMARY_REGION` (つまり`us-east-1` ) に十分な数のフォロワーレプリカを配置したい場合は、 `MAJORITY_IN_PRIMARY`スケジューリングルールを使用できます。このスケジューリングルールは、可用性を多少犠牲にする代わりに、トランザクションのレイテンシーを低減します。プライマリリージョンが障害を起こした場合、 `MAJORITY_IN_PRIMARY`自動フェイルオーバーを提供しません。 ## データ分離の例 {#data-isolation-examples} @@ -447,7 +447,7 @@ PLACEMENT POLICY=app_list この例では、制約は`[+app=order]`のようなリスト形式で指定されています。また、 `{+app=order: 3}`のような辞書形式で指定することもできます。 -例のステートメントを実行すると、TiDB は`app_order`データを`app`ラベルの TiKV ノードに`order`として配置し、 `app_list`データを`app`ラベルの TiKV ノードに`list_collection`として配置し、storage内の物理的なデータ分離を実現します。 +例のステートメントを実行すると、TiDB は`app_order`データを`app`ラベルの TiKV ノードに`order`として配置し、 `app_list`データを`app`ラベルの TiKV ノードに`list_collection`として配置し、ストレージ内の物理的なデータ分離を実現します。 ## 互換性 {#compatibility} diff --git a/post-installation-check.md b/post-installation-check.md index dbfc16fca79c8..7f30f9c22778d 100644 --- a/post-installation-check.md +++ b/post-installation-check.md @@ -3,17 +3,17 @@ title: Check Cluster Status summary: TiDB クラスターの実行ステータスを確認する方法を学習します。 --- -# クラスタのステータスを確認する {#check-cluster-status} +# クラスターのステータスを確認する {#check-cluster-status} -TiDBクラスタをデプロイした後、クラスタが正常に動作しているかどうかを確認する必要があります。このドキュメントでは、 TiUPコマンド[TiDBダッシュボード](/dashboard/dashboard-intro.md)とGrafanaを使用してクラスタの状態を確認する方法と、TiDBデータベースにログインして簡単なSQL操作を実行する方法を紹介します。 +TiDBクラスターをデプロイした後、クラスターが正常に動作しているかどうかを確認する必要があります。このドキュメントでは、 TiUPコマンド[TiDBダッシュボード](/dashboard/dashboard-intro.md)とGrafanaを使用してクラスターの状態を確認する方法と、TiDBデータベースにログインして簡単なSQL操作を実行する方法を紹介します。 -## TiDBクラスタのステータスを確認する {#check-the-tidb-cluster-status} +## TiDBクラスターのステータスを確認する {#check-the-tidb-cluster-status} このセクションでは、 TiUPコマンド[TiDBダッシュボード](/dashboard/dashboard-intro.md)および Grafana を使用して TiDB クラスターのステータスを確認する方法について説明します。 ### TiUPを使用する {#use-tiup} -`tiup cluster display `コマンドを使用してクラスタのステータスを確認します。例: +`tiup cluster display `コマンドを使用してクラスターのステータスを確認します。例: ```shell tiup cluster display tidb-test @@ -51,7 +51,7 @@ tiup cluster display tidb-test mysql -u root -h ${tidb_server_host_IP_address} -P 4000 ``` -`${tidb_server_host_IP_address}` 、 `10.0.1.7`などの[クラスタトポロジファイルを初期化する](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)の場合に`tidb_servers`に設定される IP アドレスの 1 つです。 +`${tidb_server_host_IP_address}` 、 `10.0.1.7`などの[クラスタートポロジファイルを初期化する](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)の場合に`tidb_servers`に設定される IP アドレスの 1 つです。 次の情報はログインが成功したことを示します。 diff --git a/predicate-push-down.md b/predicate-push-down.md index 55019596724c7..b9e6d28fe9b5f 100644 --- a/predicate-push-down.md +++ b/predicate-push-down.md @@ -13,7 +13,7 @@ PPD は、選択演算子をデータ ソースに可能な限り近づけて、 以下のケースでは、PPD の最適化について説明します。ケース 1、2、3 は PPD が適用可能なシナリオであり、ケース 4、5、6 は PPD が適用できないシナリオです。 -### ケース1: 述語をstorageレイヤーにプッシュする {#case-1-push-predicates-to-storage-layer} +### ケース1: 述語をストレージレイヤーにプッシュする {#case-1-push-predicates-to-ストレージ-layer} ```sql create table t(id int primary key, a int); @@ -30,7 +30,7 @@ explain select * from t where a < 1; このクエリでは、述語`a < 1` TiKVレイヤーにプッシュダウンしてデータをフィルター処理すると、ネットワーク転送のオーバーヘッドを削減できます。 -### ケース2: 述語をstorageレイヤーにプッシュする {#case-2-push-predicates-to-storage-layer} +### ケース2: 述語をストレージレイヤーにプッシュする {#case-2-push-predicates-to-ストレージ-layer} ```sql create table t(id int primary key, a int not null); @@ -70,7 +70,7 @@ explain select * from t join s on t.a = s.a where t.a < 1; さらに、このSQL文では内部結合が実行され、条件`ON`は`t.a = s.a`です。述語`s.a <1` `t.a < 1`から導出され、結合演算子の下のテーブル`s`にプッシュダウンされます。テーブル`s`フィルタリングすることで、結合の計算オーバーヘッドをさらに削減できます。 -### ケース4:storage層でサポートされていない述語はプッシュダウンできない {#case-4-predicates-that-are-not-supported-by-storage-layers-cannot-be-pushed-down} +### ケース4:ストレージ層でサポートされていない述語はプッシュダウンできない {#case-4-predicates-that-are-not-supported-by-ストレージ-layers-cannot-be-pushed-down} ```sql create table t(id int primary key, a varchar(10) not null); diff --git a/privilege-management.md b/privilege-management.md index a234c77d9e7ce..ba829665353a6 100644 --- a/privilege-management.md +++ b/privilege-management.md @@ -244,7 +244,7 @@ SHOW GRANTS FOR `rw_user`@`192.168.%`; - `RESTRICTED_VARIABLES_ADMIN`は、SEM が有効になっている場合に、権限所有者がすべてのシステム変数を表示できるようにします。 - `RESTRICTED_USER_ADMIN` SEM が有効になっている場合、特権所有者が SUPER ユーザーによってアクセス権を取り消されることを禁止します。 - `RESTRICTED_CONNECTION_ADMIN`権限所有者が`RESTRICTED_USER_ADMIN`ユーザーの接続を強制終了することを許可します。この権限は`KILL`および`KILL TIDB`ステートメントに影響します。 -- `RESTRICTED_REPLICA_WRITER_ADMIN`使用すると、TiDB クラスタで読み取り専用モードが有効になっている場合でも、権限所有者は影響を受けることなく書き込みまたは更新操作を実行できます。詳細については、 [`tidb_restricted_read_only`](/system-variables.md#tidb_restricted_read_only-new-in-v520)参照してください。 +- `RESTRICTED_REPLICA_WRITER_ADMIN`使用すると、TiDB クラスターで読み取り専用モードが有効になっている場合でも、権限所有者は影響を受けることなく書き込みまたは更新操作を実行できます。詳細については、 [`tidb_restricted_read_only`](/system-variables.md#tidb_restricted_read_only-new-in-v520)参照してください。 動的権限の全セットを確認するには、 `SHOW PRIVILEGES`ステートメントを実行してください。プラグインは新しい権限を追加できるため、割り当て可能な権限のリストは、TiDB のインストール環境によって異なる場合があります。 diff --git a/production-deployment-using-tiup.md b/production-deployment-using-tiup.md index e3b165531905e..1318370289937 100644 --- a/production-deployment-using-tiup.md +++ b/production-deployment-using-tiup.md @@ -1,24 +1,24 @@ --- title: Deploy a TiDB Cluster Using TiUP -summary: TiUPを使用してTiDBクラスタを簡単にデプロイする方法を学びましょう。 +summary: TiUPを使用してTiDBクラスターを簡単にデプロイする方法を学びましょう。 --- -# TiUPを使用してTiDBクラスタをデプロイ {#deploy-a-tidb-cluster-using-tiup} +# TiUPを使用してTiDBクラスターをデプロイ {#deploy-a-tidb-cluster-using-tiup} -このガイドでは、本番環境で[TiUP](https://github.com/pingcap/tiup)を使用してTiDBセルフマネージドクラスタをデプロイする方法について説明します。 +このガイドでは、本番環境で[TiUP](https://github.com/pingcap/tiup)を使用してTiDB Self-Managedクラスターをデプロイする方法について説明します。 -TiUPは、TiDB v4.0で導入されたクラスタ運用・保守ツールです。TiUP [TiUPクラスター](https://github.com/pingcap/tiup/tree/master/components/cluster)は、TiDBクラスタを管理するためのGolangベースのコンポーネントです。TiUPクラスタを使用することで、 TiUPクラスタのデプロイ、起動、停止、削除、スケーリング、アップグレード、およびTiDBクラスタパラメータの管理といった、日常的なデータベース操作を容易に実行できます。 +TiUPは、TiDB v4.0で導入されたクラスター運用・保守ツールです。TiUP [TiUPクラスター](https://github.com/pingcap/tiup/tree/master/components/cluster)は、TiDBクラスターを管理するためのGolangベースのコンポーネントです。TiUPクラスターを使用することで、 TiUPクラスターのデプロイ、起動、停止、削除、スケーリング、アップグレード、およびTiDBクラスターパラメータの管理といった、日常的なデータベース操作を容易に実行できます。 -TiUPは、TiDB、 TiFlash、TiCDC、および監視システムのデプロイもサポートしています。このガイドでは、さまざまなトポロジーでTiDBクラスタをデプロイする方法について説明します。 +TiUPは、TiDB、 TiFlash、TiCDC、および監視システムのデプロイもサポートしています。このガイドでは、さまざまなトポロジーでTiDBクラスターをデプロイする方法について説明します。 ## ステップ1．前提条件と事前確認 {#step-1-prerequisites-and-prechecks} 以下の文書を必ずお読みください。 - [TiDBのソフトウェアおよびハードウェア要件](/hardware-and-software-requirements.md) -- [TiDB環境およびシステムコンフィグレーションチェック](/check-before-deployment.md) +- [TiDB環境およびシステム設定チェック](/check-before-deployment.md) -さらに、 [TiDBSecurityコンフィグレーションのベストプラクティス](/best-practices-for-security-configuration.md)学習することをお勧めします。 +さらに、 [TiDBSecurity設定のベストプラクティス](/best-practices-for-security-configuration.md)学習することをお勧めします。 ## ステップ2. 制御機にTiUPをデプロイ {#step-2-deploy-tiup-on-the-control-machine} @@ -30,7 +30,7 @@ TiUPを制御マシンに展開するには、オンライン展開とオフラ > > TiUP環境がオフラインに切り替わった場合は、 [TiUPをオフラインでデプロイ](#deploy-tiup-offline)デプロイ」の展開を参照してください。そうしないと、 TiUP が正常に動作しません。 -通常のユーザーアカウントを使用して制御マシンにログインします（例として`tidb`ユーザーを使用します）。その後のTiUPのインストールとクラスタ管理は`tidb`ユーザーが実行できます。 +通常のユーザーアカウントを使用して制御マシンにログインします（例として`tidb`ユーザーを使用します）。その後のTiUPのインストールとクラスター管理は`tidb`ユーザーが実行できます。 1. 以下のコマンドを実行してTiUPをインストールしてください。 @@ -52,19 +52,19 @@ TiUPを制御マシンに展開するには、オンライン展開とオフラ which tiup ``` -3. TiUPクラスタコンポーネントをインストールします。 +3. TiUPクラスターコンポーネントをインストールします。 ```shell tiup cluster ``` -4. TiUPが既にインストールされている場合は、 TiUPクラスタコンポーネントを最新バージョンにアップデートしてください。 +4. TiUPが既にインストールされている場合は、 TiUPクラスターコンポーネントを最新バージョンにアップデートしてください。 ```shell tiup update --self && tiup update cluster ``` - `Updated successfully!`が表示された場合、 TiUPクラスタは正常に更新されています。 + `Updated successfully!`が表示された場合、 TiUPクラスターは正常に更新されています。 5. TiUPクラスターの現在のバージョンを確認してください。 @@ -74,7 +74,7 @@ TiUPを制御マシンに展開するには、オンライン展開とオフラ ### TiUPをオフラインでデプロイ {#deploy-tiup-offline} -TiUPを使用してTiDBクラスタをオフラインでデプロイするには、このセクションで以下の手順を実行します。 +TiUPを使用してTiDBクラスターをオフラインでデプロイするには、このセクションで以下の手順を実行します。 #### TiUPオフラインコンポーネントパッケージを準備する {#prepare-the-tiup-offline-component-package} @@ -134,7 +134,7 @@ TiUPを使用してTiDBクラスタをオフラインでデプロイするには 既存のオフラインミラーを調整する場合（コンポーネントの新しいバージョンを追加する場合など）、以下の手順に従ってください。 - 1. オフラインミラーを取得する際、コンポーネントやバージョン情報などの特定の情報をパラメータで指定することで、不完全なオフラインミラーを取得できます。たとえば、次のコマンドを実行すると、 TiUP v1.12.3 とTiUP クラスタ v1.12.3 のオフラインミラーのみを含むオフラインミラーを取得できます。 + 1. オフラインミラーを取得する際、コンポーネントやバージョン情報などの特定の情報をパラメータで指定することで、不完全なオフラインミラーを取得できます。たとえば、次のコマンドを実行すると、 TiUP v1.12.3 とTiUP クラスター v1.12.3 のオフラインミラーのみを含むオフラインミラーを取得できます。 ```bash tiup mirror clone tiup-custom-mirror-v1.12.3 --tiup v1.12.3 --cluster v1.12.3 @@ -170,7 +170,7 @@ TiUPを使用してTiDBクラスタをオフラインでデプロイするには #### オフラインのTiUPコンポーネントをデプロイ {#deploy-the-offline-tiup-component} -対象クラスタの制御マシンにパッケージを送信した後、以下のコマンドを実行してTiUPコンポーネントをインストールします。 +対象クラスターの制御マシンにパッケージを送信した後、以下のコマンドを実行してTiUPコンポーネントをインストールします。 ```bash tar xzvf tidb-community-server-${version}-linux-amd64.tar.gz && \ @@ -196,9 +196,9 @@ tiup mirror merge ../tidb-community-toolkit-${version}-linux-amd64 ミラーを別のディレクトリに切り替えるには、 `tiup mirror set `コマンドを実行します。ミラーをオンライン環境に切り替えるには、 `tiup mirror set https://tiup-mirrors.pingcap.com`コマンドを実行します。 -## ステップ3. クラスタトポロジーファイルを初期化する {#step-3-initialize-the-cluster-topology-file} +## ステップ3. クラスタートポロジーファイルを初期化する {#step-3-initialize-the-cluster-topology-file} -クラスタトポロジーファイルを作成するには、次のコマンドを実行します。 +クラスタートポロジーファイルを作成するには、次のコマンドを実行します。 ```shell tiup cluster template > topology.yaml @@ -249,13 +249,13 @@ alertmanager_servers: 以下の例では、6つの一般的なシナリオを取り上げています。対応するリンク先のトポロジーの説明とテンプレートに従って、構成ファイル（ `topology.yaml`という名前）を変更する必要があります。その他のシナリオについては、構成テンプレートを適切に編集してください。 -| 応用 | コンフィグレーションタスク | コンフィグレーションファイルテンプレート | トポロジーの説明 | +| 応用 | 設定タスク | 設定ファイルテンプレート | トポロジーの説明 | | :----------------------------------------------- | :------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------- | -| OLTP | [最小限のトポロジーをデプロイ](/minimal-deployment-topology.md) | [シンプルな最小限の構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-mini.yaml)
[完全な最小構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-mini.yaml) | これは、tidb-server、tikv-server、およびpd-serverを含む基本的なクラスタトポロジーです。 | -| HTAP | [TiFlashトポロジーをデプロイ](/tiflash-deployment-topology.md) | [シンプルなTiFlash設定テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiflash.yaml)
[TiFlashの完全な構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-tiflash.yaml) | これは、最小限のクラスタトポロジーとともにTiFlashをデプロイするためのものです。TiFlashはカラム型storageエンジンであり、徐々に標準的なクラスタトポロジーへと進化していきます。 | -| [TiCDC](/ticdc/ticdc-overview.md)を使用して増分データを複製する | [TiCDCトポロジーをデプロイ](/ticdc-deployment-topology.md) | [シンプルなTiCDC構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-cdc.yaml)
[TiCDC構成テンプレート全体](https://github.com/pingcap/docs/blob/master/config-templates/complex-cdc.yaml) | これは、最小限のクラスタトポロジーとともにTiCDCをデプロイするためのものです。TiCDCは、TiDB、MySQL、Kafka、MQ、storageサービスなど、複数のダウンストリームプラットフォームをサポートしています。 | +| OLTP | [最小限のトポロジーをデプロイ](/minimal-deployment-topology.md) | [シンプルな最小限の構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-mini.yaml)
[完全な最小構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-mini.yaml) | これは、tidb-server、tikv-server、およびpd-serverを含む基本的なクラスタートポロジーです。 | +| HTAP | [TiFlashトポロジーをデプロイ](/tiflash-deployment-topology.md) | [シンプルなTiFlash設定テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiflash.yaml)
[TiFlashの完全な構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-tiflash.yaml) | これは、最小限のクラスタートポロジーとともにTiFlashをデプロイするためのものです。TiFlashはカラム型ストレージエンジンであり、徐々に標準的なクラスタートポロジーへと進化していきます。 | +| [TiCDC](/ticdc/ticdc-overview.md)を使用して増分データを複製する | [TiCDCトポロジーをデプロイ](/ticdc-deployment-topology.md) | [シンプルなTiCDC構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-cdc.yaml)
[TiCDC構成テンプレート全体](https://github.com/pingcap/docs/blob/master/config-templates/complex-cdc.yaml) | これは、最小限のクラスタートポロジーとともにTiCDCをデプロイするためのものです。TiCDCは、TiDB、MySQL、Kafka、MQ、ストレージサービスなど、複数のダウンストリームプラットフォームをサポートしています。 | | 1台のマシンに複数のインスタンスをデプロイ | [ハイブリッドトポロジーをデプロイ](/hybrid-deployment-topology.md) | [ハイブリッド展開用のシンプルな構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-multi-instance.yaml)
[ハイブリッド展開用の完全な構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-multi-instance.yaml) | ディレクトリ、ポート、リソース比率、ラベルなどの追加設定が必要な場合にも、デプロイメントトポロジーが適用されます。 | -| TiDBクラスターをデータセンター全体にデプロイ | [地理的に分散したデプロイメントトポロジーをデプロイ](/geo-distributed-deployment-topology.md) | [地理的に分散したデプロイメントのためのコンフィグレーションテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/geo-redundancy-deployment.yaml) | このトポロジーは、2つの都市に3つのデータセンターを配置する典型的なアーキテクチャを例として取り上げています。地理的に分散したデプロイメントアーキテクチャと、注意すべき重要な構成について解説します。 | +| TiDBクラスターをデータセンター全体にデプロイ | [地理的に分散したデプロイメントトポロジーをデプロイ](/geo-distributed-deployment-topology.md) | [地理的に分散したデプロイメントのための設定テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/geo-redundancy-deployment.yaml) | このトポロジーは、2つの都市に3つのデータセンターを配置する典型的なアーキテクチャを例として取り上げています。地理的に分散したデプロイメントアーキテクチャと、注意すべき重要な構成について解説します。 | > **注記：** > @@ -275,7 +275,7 @@ alertmanager_servers: > **注記：** > -> TiUP ( `--user`で指定) を介してクラスタをデプロイする際に初期化に使用するユーザーを、キーまたはクロスパスワードのいずれかを使用して安全に認証できます。 +> TiUP ( `--user`で指定) を介してクラスターをデプロイする際に初期化に使用するユーザーを、キーまたはクロスパスワードのいずれかを使用して安全に認証できます。 > > - 秘密鍵を使用する場合は、 `-i`または`--identity_file`を使用して鍵のパスを指定します。 > - パスワードを使用する場合は、 `-p`フラグを追加して、パスワード入力ウィンドウを開きます。 @@ -302,7 +302,7 @@ alertmanager_servers: tiup cluster check ./topology.yaml --apply --user root [-p] [-i /home/root/.ssh/gcp_rsa] ``` -3. TiDBクラスタをデプロイ： +3. TiDBクラスターをデプロイ： ```shell tiup cluster deploy tidb-test v8.5.4 ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa] @@ -310,10 +310,10 @@ alertmanager_servers: 上記の`tiup cluster deploy`コマンドでは、次のようになります。 -- `tidb-test`は、デプロイされる TiDB クラスタの名前です。 -- `v8.5.4`は、デプロイする TiDB クラスタのバージョンです。 `tiup list tidb`を実行すると、サポートされている最新バージョンを確認できます。 +- `tidb-test`は、デプロイされる TiDB クラスターの名前です。 +- `v8.5.4`は、デプロイする TiDB クラスターのバージョンです。 `tiup list tidb`を実行すると、サポートされている最新バージョンを確認できます。 - `topology.yaml`は初期化設定ファイルです。 -- `--user root` `root`ユーザーとしてターゲット マシンにログインし、クラスタのデプロイを完了することを示します。 `root`ユーザーは、ターゲット マシンに対して`ssh`および`sudo`の権限を持っている必要があります。あるいは、 `ssh`および`sudo`の権限を持つ他のユーザーを使用してデプロイを完了することもできます。 +- `--user root` `root`ユーザーとしてターゲット マシンにログインし、クラスターのデプロイを完了することを示します。 `root`ユーザーは、ターゲット マシンに対して`ssh`および`sudo`の権限を持っている必要があります。あるいは、 `ssh`および`sudo`の権限を持つ他のユーザーを使用してデプロイを完了することもできます。 - `[-i]`と`[-p]`はオプションです。ターゲット マシンへのログインをパスワードなしで設定している場合は、これらのパラメーターは不要です。そうでない場合は、2 つのパラメーターのいずれかを選択してください。 `[-i]`は、ターゲット マシンへのアクセス権を持つルート ユーザー (または`--user`で指定された他のユーザー) の秘密鍵です。 `[-p]`は、ユーザー パスワードを対話的に入力するために使用されます。 出力ログの最後に``Deployed cluster `tidb-test` successfully``と表示されます。これは、デプロイが成功したことを示しています。 @@ -324,9 +324,9 @@ alertmanager_servers: tiup cluster list ``` -TiUPは複数のTiDBクラスタの管理をサポートしています。上記のコマンドは、クラスタ名、デプロイメントユーザー、バージョン、秘密鍵情報など、現在TiUPによって管理されているすべてのクラスタの情報を出力します。 +TiUPは複数のTiDBクラスターの管理をサポートしています。上記のコマンドは、クラスター名、デプロイメントユーザー、バージョン、秘密鍵情報など、現在TiUPによって管理されているすべてのクラスターの情報を出力します。 -## ステップ6. デプロイされたTiDBクラスタの状態を確認します。 {#step-6-check-the-status-of-the-deployed-tidb-cluster} +## ステップ6. デプロイされたTiDBクラスターの状態を確認します。 {#step-6-check-the-status-of-the-deployed-tidb-cluster} 例えば、次のコマンドを実行して、 `tidb-test`クラスターの状態を確認します。 @@ -336,7 +336,7 @@ tiup cluster display tidb-test 期待される出力には、インスタンス ID、ロール、ホスト、リスニング ポート、ステータス (クラスターがまだ起動していないため、ステータスは`Down` / `inactive`です)、およびディレクトリ情報が含まれます。 -## ステップ7. TiDBクラスタを起動する {#step-7-start-a-tidb-cluster} +## ステップ7. TiDBクラスターを起動する {#step-7-start-a-tidb-cluster} TiUP cluster v1.9.0以降、新しい起動方法としてセーフスタートが導入されました。この方法でデータベースを起動すると、データベースのセキュリティが向上します。この方法を使用することをお勧めします。 @@ -344,7 +344,7 @@ TiUP cluster v1.9.0以降、新しい起動方法としてセーフスタート > **注記：** > -> - TiDBクラスタの安全な起動後、パスワードなしでrootユーザーとしてTiDBにログインすることはできません。そのため、今後のログインのために、コマンド出力に表示されるパスワードを記録しておく必要があります。 +> - TiDBクラスターの安全な起動後、パスワードなしでrootユーザーとしてTiDBにログインすることはできません。そのため、今後のログインのために、コマンド出力に表示されるパスワードを記録しておく必要があります。 > - パスワードは 1 回だけ生成されます。記録していない場合、または忘れた場合は、 [`root`パスワードを忘れる](/user-account-management.md#forget-the-root-password)を参照してパスワードを変更してください。 方法1：セーフスタート @@ -371,7 +371,7 @@ tiup cluster start tidb-test 出力ログに``Started cluster `tidb-test` successfully``が含まれていれば、起動は成功です。標準起動後、パスワードなしでrootユーザーを使用してデータベースにログインできます。 -## ステップ8．TiDBクラスタの実行状態を確認する {#step-8-verify-the-running-status-of-the-tidb-cluster} +## ステップ8．TiDBクラスターの実行状態を確認する {#step-8-verify-the-running-status-of-the-tidb-cluster} ```shell tiup cluster display tidb-test @@ -381,21 +381,21 @@ tiup cluster display tidb-test ## 関連項目 {#see-also} -TiDBクラスタとともに[TiFlash](/tiflash/tiflash-overview.md)をデプロイしている場合は、以下のドキュメントを参照してください。 +TiDBクラスターとともに[TiFlash](/tiflash/tiflash-overview.md)をデプロイしている場合は、以下のドキュメントを参照してください。 - [TiFlashを使用する](/tiflash/tiflash-overview.md#use-tiflash) -- [TiFlashクラスタの管理](/tiflash/maintain-tiflash.md) +- [TiFlashクラスターの管理](/tiflash/maintain-tiflash.md) - [TiFlashアラートのルールと解決策](/tiflash/tiflash-alert-rules.md) - [TiFlashのトラブルシューティング](/tiflash/troubleshoot-tiflash.md) -TiDBクラスタとともに[TiCDC](/ticdc/ticdc-overview.md)をデプロイしている場合は、データのストリーミング方法について以下のドキュメントを参照してください。 +TiDBクラスターとともに[TiCDC](/ticdc/ticdc-overview.md)をデプロイしている場合は、データのストリーミング方法について以下のドキュメントを参照してください。 - [変更フィードの概要](/ticdc/ticdc-changefeed-overview.md) - [変更フィードを管理する](/ticdc/ticdc-manage-changefeed.md) - [TiCDCのトラブルシューティング](/ticdc/troubleshoot-ticdc.md) - [TiCDCに関するよくある質問](/ticdc/ticdc-faq.md) -オンライン サービスを中断せずに TiDB クラスターをスケールアウトまたはスケールインしたい場合は、 [TiUPを使用してTiDBクラスタをスケーリングする](/scale-tidb-using-tiup.md)参照してください。 +オンライン サービスを中断せずに TiDB クラスターをスケールアウトまたはスケールインしたい場合は、 [TiUPを使用してTiDBクラスターをスケーリングする](/scale-tidb-using-tiup.md)参照してください。 ## 関連リソース {#related-resources} diff --git a/quick-start-with-htap.md b/quick-start-with-htap.md index 2e8788ea94b93..86b4c7bac7187 100644 --- a/quick-start-with-htap.md +++ b/quick-start-with-htap.md @@ -9,14 +9,14 @@ summary: TiDB HTAPをすぐに使い始める方法を学びます。 > **注記：** > -> このガイドで紹介する手順は、テスト環境での迅速な開始のみを目的としています。本番環境では、 [HTAPを探索する](/explore-htap.md)推奨します。 +> このガイドで紹介する手順は、テスト環境での迅速な開始のみを目的としています。本番環境では、 [HTAP入門](/explore-htap.md)推奨します。 ## 基本概念 {#basic-concepts} -TiDB HTAP を使用する前に、 [TiKV](/tikv-overview.md) 、TiDB オンライン トランザクション処理 (OLTP) 用の行ベースのストレージ エンジン、および[TiFlash](/tiflash/tiflash-overview.md) 、TiDB オンライン分析処理 (OLAP) 用の列ベースのstoragestorageに関する基本的な知識が必要です。 +TiDB HTAP を使用する前に、 [TiKV](/tikv-overview.md) 、TiDB オンライン トランザクション処理 (OLTP) 用の行ベースのストレージ エンジン、および[TiFlash](/tiflash/tiflash-overview.md) 、TiDB オンライン分析処理 (OLAP) 用の列ベースのストレージストレージに関する基本的な知識が必要です。 -- HTAPのストレージエンジン：HTAPでは、行ベースstorageエンジンと列指向storageエンジンが共存します。どちらのstorageエンジンもデータを自動的に複製し、強力な一貫性を維持できます。行ベースstorageエンジンはOLTPパフォーマンスを最適化し、列指向storageエンジンはOLAPパフォーマンスを最適化します。 -- HTAP のデータ一貫性: 分散型トランザクション キー値データベースである TiKV は、 ACID準拠のトランザクション インターフェイスを提供し、 [Raftコンセンサスアルゴリズム](https://raft.github.io/raft.pdf)の実装により複数のレプリカ間のデータ一貫性と高可用性を保証します。TiKV の列指向storage拡張機能であるTiFlash は、 Raft Learnerコンセンサス アルゴリズムに従って TiKV からデータをリアルタイムで複製し、TiKV とTiFlash間でデータの強力な一貫性を保証します。 +- HTAPのストレージエンジン：HTAPでは、行ベースストレージエンジンと列指向ストレージエンジンが共存します。どちらのストレージエンジンもデータを自動的に複製し、強力な一貫性を維持できます。行ベースストレージエンジンはOLTPパフォーマンスを最適化し、列指向ストレージエンジンはOLAPパフォーマンスを最適化します。 +- HTAP のデータ一貫性: 分散型トランザクション キー値データベースである TiKV は、 ACID準拠のトランザクション インターフェイスを提供し、 [Raftコンセンサスアルゴリズム](https://raft.github.io/raft.pdf)の実装により複数のレプリカ間のデータ一貫性と高可用性を保証します。TiKV の列指向ストレージ拡張機能であるTiFlash は、 Raftラーナーコンセンサス アルゴリズムに従って TiKV からデータをリアルタイムで複製し、TiKV とTiFlash間でデータの強力な一貫性を保証します。 - HTAP のデータ分離: HTAP リソース分離の問題を解決するために、必要に応じて TiKV とTiFlash を異なるマシンに展開できます。 - MPPコンピューティングエンジン： [MPP](/tiflash/use-tiflash-mpp-mode.md#control-whether-to-select-the-mpp-mode)は、TiDB 5.0以降TiFlashエンジンによって提供される分散コンピューティングフレームワークであり、ノード間のデータ交換を可能にし、高性能かつ高スループットのSQLアルゴリズムを提供します。MPPモードでは、分析クエリの実行時間を大幅に短縮できます。 @@ -26,7 +26,7 @@ TiDB HTAP を使用する前に、 [TiKV](/tikv-overview.md) 、TiDB オンラ ### ステップ1. ローカルテスト環境をデプロイ {#step-1-deploy-a-local-test-environment} -TiDB HTAPを使用する前に、 [TiDBセルフマネージドのクイックスタート](/quick-start-with-tidb.md)の手順に従ってローカル テスト環境を準備し、次のコマンドを実行して TiDB クラスターをデプロイします。 +TiDB HTAPを使用する前に、 [TiDB Self-Managedのクイックスタート](/quick-start-with-tidb.md)の手順に従ってローカル テスト環境を準備し、次のコマンドを実行して TiDB クラスターをデプロイします。 ```shell tiup playground @@ -93,9 +93,9 @@ tiup playground これは商用発注システムのデータベースです。テーブル`test.nation`は国に関する情報、テーブル`test.region`は地域に関する情報、テーブル`test.part`は部品に関する情報、テーブル`test.supplier`はサプライヤーに関する情報、テーブル`test.partsupp`はサプライヤーの部品に関する情報、テーブル`test.customer`は顧客に関する情報、テーブル`test.customer`は注文に関する情報、テーブル`test.lineitem`はオンライン商品に関する情報を示しています。 -### ステップ3. 行ベースのstorageエンジンでデータをクエリする {#step-3-query-data-with-the-row-based-storage-engine} +### ステップ3. 行ベースのストレージエンジンでデータをクエリする {#step-3-query-data-with-the-row-based-ストレージ-engine} -行ベースのstorageエンジンのみを使用した TiDB のパフォーマンスを確認するには、次の SQL ステートメントを実行します。 +行ベースのストレージエンジンのみを使用した TiDB のパフォーマンスを確認するには、次の SQL ステートメントを実行します。 ```sql USE test; @@ -128,7 +128,7 @@ limit 10; これは配送優先度クエリで、指定日までに発送されていない、最も収益の高い注文の優先度と潜在収益を取得します。潜在収益は`l_extendedprice * (1-l_discount)`の合計として定義されます。注文は収益の降順でリストされます。この例では、このクエリは潜在収益が上位10件の未発送注文をリストします。 -### ステップ4. テストデータを列指向storageエンジンに複製する {#step-4-replicate-the-test-data-to-the-columnar-storage-engine} +### ステップ4. テストデータを列指向ストレージエンジンに複製する {#step-4-replicate-the-test-data-to-the-columnar-ストレージ-engine} TiFlashを導入した後、TiKV はデータをすぐにTiFlashに複製しません。複製するテーブルを指定するには、TiDB の MySQL クライアントで以下の DDL 文を実行する必要があります。その後、TiDB は指定されたレプリカをTiFlashに作成します。 @@ -153,7 +153,7 @@ SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'test' and ### ステップ5. HTAPを使用してデータをより速く分析する {#step-5-analyze-data-faster-using-htap} -もう一度[ステップ3](#step-3-query-data-with-the-row-based-storage-engine)の SQL 文を実行すると、 TiDB HTAPのパフォーマンスを確認できます。 +もう一度[ステップ3](#step-3-query-data-with-the-row-based-ストレージ-engine)の SQL 文を実行すると、 TiDB HTAPのパフォーマンスを確認できます。 TiFlashレプリカを持つテーブルの場合、TiDBオプティマイザーはコスト見積もりに基づいてTiFlashレプリカを使用するかどうかを自動的に決定します。TiFlashが選択されているかどうかを確認するには、 `desc`または`explain analyze`ステートメントを使用します。例： @@ -195,5 +195,5 @@ limit 10; ## 次は何？ {#what-s-next} - [TiDB HTAPのアーキテクチャ](/tiflash/tiflash-overview.md#architecture) -- [HTAPを探索する](/explore-htap.md) +- [HTAP入門](/explore-htap.md) - [TiFlashを使用する](/tiflash/tiflash-overview.md#use-tiflash) diff --git a/quick-start-with-tidb.md b/quick-start-with-tidb.md index 5ca941fed8554..c7e54f664a6ca 100644 --- a/quick-start-with-tidb.md +++ b/quick-start-with-tidb.md @@ -1,14 +1,14 @@ --- title: Quick Start with TiDB Self-Managed -summary: TiUPプレイグラウンドを使ってTiDBセルフマネージドを素早く使い始める方法を学び、TiDBがあなたにとって最適な選択肢かどうかを確認しましょう。 +summary: TiUPプレイグラウンドを使ってTiDB Self-Managedを素早く使い始める方法を学び、TiDBがあなたにとって最適な選択肢かどうかを確認しましょう。 --- -# TiDBセルフマネージドのクイックスタート {#quick-start-with-tidb-self-managed} +# TiDB Self-Managedのクイックスタート {#quick-start-with-tidb-self-managed} このガイドでは、TiDB Self-Managed を最も迅速に使い始める方法を説明します。非本番環境では、以下のいずれかの方法で TiDB データベースをデプロイできます。 - [ローカルテストクラスターをデプロイ](#deploy-a-local-test-cluster)(macOSおよびLinux用) -- [単一のマシン上で本番本番への展開をシミュレーションする](#simulate-production-deployment-on-a-single-machine)(Linux のみ) +- [単一のマシン上で本番環境へのデプロイをシミュレートする](#simulate-production-deployment-on-a-single-machine)(Linux のみ) さらに、 [TiDB Playground](https://play.tidbcloud.com/?utm_source=docs&utm_medium=tidb_quick_start)でTiDBの機能を試すこともできます。 @@ -22,12 +22,12 @@ summary: TiUPプレイグラウンドを使ってTiDBセルフマネージドを ## ローカルテストクラスターをデプロイ {#deploy-a-local-test-cluster} -このセクションでは、単一のmacOSまたはLinuxサーバー上でテスト用のローカルTiDBクラスタを迅速にデプロイする方法について説明します。このようなクラスタをデプロイすることで、TiDBデータベースの基本的なアーキテクチャと、TiDB、TiKV、PD、監視コンポーネントなどの各コンポーネントの動作を習得できます。 +このセクションでは、単一のmacOSまたはLinuxサーバー上でテスト用のローカルTiDBクラスターを迅速にデプロイする方法について説明します。このようなクラスターをデプロイすることで、TiDBデータベースの基本的なアーキテクチャと、TiDB、TiKV、PD、監視コンポーネントなどの各コンポーネントの動作を習得できます。
-分散システムである基本的なTiDBテストクラスタは、通常、2つのTiDBインスタンス、3つのTiKVインスタンス、3つのPDインスタンス、およびオプションのTiFlashインスタンスで構成されます。TiUP Playgroundを使用すると、以下の手順に従ってテストクラスタをすばやくセットアップできます。 +分散システムである基本的なTiDBテストクラスターは、通常、2つのTiDBインスタンス、3つのTiKVインスタンス、3つのPDインスタンス、およびオプションのTiFlashインスタンスで構成されます。TiUP Playgroundを使用すると、以下の手順に従ってテストクラスターをすばやくセットアップできます。 1. TiUPをダウンロードしてインストールしてください： @@ -69,20 +69,20 @@ summary: TiUPプレイグラウンドを使ってTiDBセルフマネージドを > **注記：** > - > - 以下の方法で運用されるプレイグラウンドの場合、デプロイとテストが完了すると、 TiUPは自動的にクラスタデータをクリーンアップします。コマンドを再実行すると、新しいクラスタが作成されます。 - > - データをstorageに保持する場合は、クラスターの起動時に`--tag`フラグを追加します。詳細については、 [TiDBクラスタの起動時に、データを保存するタグを指定します。](/tiup/tiup-playground.md#specify-a-tag-when-starting-the-tidb-cluster-to-store-the-data)参照してください。 + > - 以下の方法で運用されるプレイグラウンドの場合、デプロイとテストが完了すると、 TiUPは自動的にクラスターデータをクリーンアップします。コマンドを再実行すると、新しいクラスターが作成されます。 + > - データをストレージに保持する場合は、クラスターの起動時に`--tag`フラグを追加します。詳細については、 [TiDBクラスターの起動時に、データを保存するタグを指定します。](/tiup/tiup-playground.md#specify-a-tag-when-starting-the-tidb-cluster-to-store-the-data)参照してください。 > > ```shell > tiup playground --tag ${tag_name} > ``` - - 最新バージョンの TiDB クラスタを、TiDB インスタンス 1 つ、TiKV インスタンス 1 つ、PD インスタンス 1 つ、 TiFlashインスタンス 1 つで起動するには、次のコマンドを実行します。 + - 最新バージョンの TiDB クラスターを、TiDB インスタンス 1 つ、TiKV インスタンス 1 つ、PD インスタンス 1 つ、 TiFlashインスタンス 1 つで起動するには、次のコマンドを実行します。 ```shell tiup playground ``` - このコマンドを初めて実行する場合、 TiUPは最新バージョンのTiDBをダウンロードし、クラスタを起動します。 + このコマンドを初めて実行する場合、 TiUPは最新バージョンのTiDBをダウンロードし、クラスターを起動します。 出力には、クラスターのエンドポイントのリストが表示されます。 @@ -104,7 +104,7 @@ summary: TiUPプレイグラウンドを使ってTiDBセルフマネージドを 利用可能なすべてのバージョンを表示するには、 `tiup list tidb`を実行してください。 -4. TiDBクラスタのエンドポイントにアクセスするには、新しいセッションを開始してください。 +4. TiDBクラスターのエンドポイントにアクセスするには、新しいセッションを開始してください。 - TiDBデータベースに接続します。 @@ -145,7 +145,7 @@ summary: TiUPプレイグラウンドを使ってTiDBセルフマネージドを
-分散システムである基本的なTiDBテストクラスタは、通常、2つのTiDBインスタンス、3つのTiKVインスタンス、3つのPDインスタンス、およびオプションのTiFlashインスタンスで構成されます。TiUP Playgroundを使用すると、以下の手順に従ってテストクラスタをすばやくセットアップできます。 +分散システムである基本的なTiDBテストクラスターは、通常、2つのTiDBインスタンス、3つのTiKVインスタンス、3つのPDインスタンス、およびオプションのTiFlashインスタンスで構成されます。TiUP Playgroundを使用すると、以下の手順に従ってテストクラスターをすばやくセットアップできます。 1. TiUPをダウンロードしてインストールしてください： @@ -183,20 +183,20 @@ summary: TiUPプレイグラウンドを使ってTiDBセルフマネージドを > **注記：** > - > - 以下の方法で運用されるプレイグラウンドの場合、デプロイとテストが完了すると、 TiUPは自動的にクラスタデータをクリーンアップします。コマンドを再実行すると、新しいクラスタが作成されます。 - > - データをstorageに保持する場合は、クラスターの起動時に`--tag`フラグを追加します。詳細については、 [TiDBクラスタの起動時に、データを保存するタグを指定します。](/tiup/tiup-playground.md#specify-a-tag-when-starting-the-tidb-cluster-to-store-the-data)参照してください。 + > - 以下の方法で運用されるプレイグラウンドの場合、デプロイとテストが完了すると、 TiUPは自動的にクラスターデータをクリーンアップします。コマンドを再実行すると、新しいクラスターが作成されます。 + > - データをストレージに保持する場合は、クラスターの起動時に`--tag`フラグを追加します。詳細については、 [TiDBクラスターの起動時に、データを保存するタグを指定します。](/tiup/tiup-playground.md#specify-a-tag-when-starting-the-tidb-cluster-to-store-the-data)参照してください。 > > ```shell > tiup playground --tag ${tag_name} > ``` - - 最新バージョンの TiDB クラスタを、TiDB インスタンス 1 つ、TiKV インスタンス 1 つ、PD インスタンス 1 つ、 TiFlashインスタンス 1 つで起動するには、次のコマンドを実行します。 + - 最新バージョンの TiDB クラスターを、TiDB インスタンス 1 つ、TiKV インスタンス 1 つ、PD インスタンス 1 つ、 TiFlashインスタンス 1 つで起動するには、次のコマンドを実行します。 ```shell tiup playground ``` - このコマンドを初めて実行する場合、 TiUPは最新バージョンのTiDBをダウンロードし、クラスタを起動します。 + このコマンドを初めて実行する場合、 TiUPは最新バージョンのTiDBをダウンロードし、クラスターを起動します。 出力には、クラスターのエンドポイントのリストが表示されます。 @@ -216,7 +216,7 @@ summary: TiUPプレイグラウンドを使ってTiDBセルフマネージドを 利用可能なすべてのバージョンを表示するには、 `tiup list tidb`を実行してください。 -4. TiDBクラスタのエンドポイントにアクセスするには、新しいセッションを開始してください。 +4. TiDBクラスターのエンドポイントにアクセスするには、新しいセッションを開始してください。 - TiDBデータベースに接続します。 @@ -257,28 +257,28 @@ summary: TiUPプレイグラウンドを使ってTiDBセルフマネージドを
-## 単一のマシン上で本番本番への展開をシミュレーションする {#simulate-production-deployment-on-a-single-machine} +## 単一のマシン上で本番環境へのデプロイをシミュレートする {#simulate-production-deployment-on-a-single-machine} -このセクションでは、完全なトポロジーを持つ最小のTiDBクラスタをセットアップし、単一のLinuxサーバー上で本番へのデプロイ手順をシミュレートする方法について説明します。 +このセクションでは、完全なトポロジーを持つ最小のTiDBクラスターをセットアップし、単一のLinuxサーバー上で本番へのデプロイ手順をシミュレートする方法について説明します。 -以下では、 TiUPの最小トポロジーの YAML ファイルを使用して TiDB クラスタをデプロイする方法について説明します。 +以下では、 TiUPの最小トポロジーの YAML ファイルを使用して TiDB クラスターをデプロイする方法について説明します。 ### 準備する {#prepare} -TiDBクラスタをデプロイする前に、ターゲットマシンが以下の要件を満たしていることを確認してください。 +TiDBクラスターをデプロイする前に、ターゲットマシンが以下の要件を満たしていることを確認してください。 - CentOS 7.3以降のバージョンがインストールされています。 - Linux OSはインターネットにアクセスできる環境にあり、TiDBおよび関連ソフトウェアのインストールパッケージをダウンロードするにはインターネット接続が必要です。 -TiDBクラスタの最小トポロジーは、以下のインスタンスで構成されます。 +TiDBクラスターの最小トポロジーは、以下のインスタンスで構成されます。 -| 実例 | カウント | IP | コンフィグレーション | +| インスタンス | 数量 | IP | 構成 | | :------ | :--- | :------- | :----------------------------- | -| ティクヴ | 3 | 10.0.1.1 | 競合を避けるために、ポート番号は増分番号を使用してください。 | +| TiKV | 3 | 10.0.1.1 | 競合を避けるために、ポート番号は増分番号を使用してください。 | | TiDB | 1 | 10.0.1.1 | デフォルトのポートおよびその他の設定を使用する | | PD | 1 | 10.0.1.1 | デフォルトのポートおよびその他の設定を使用する | | TiFlash | 1 | 10.0.1.1 | デフォルトのポートおよびその他の設定を使用する | -| モニター | 1 | 10.0.1.1 | デフォルトのポートおよびその他の設定を使用する | +| モニタリング | 1 | 10.0.1.1 | デフォルトのポートおよびその他の設定を使用する | > **注記：** > @@ -288,7 +288,7 @@ TiDBクラスタの最小トポロジーは、以下のインスタンスで構 - `root`ユーザーとそのパスワードが必要です。 - [対象マシンのファイアウォールサービスを停止します。](/check-before-deployment.md#check-the-firewall-service-of-target-machines) 、または、TiDB クラスターノードに必要なポートを開きます。 -- 現在、 TiUPクラスタは、x86_64（AMD64）およびARMアーキテクチャへのTiDBのデプロイをサポートしています。 +- 現在、 TiUPクラスターは、x86_64（AMD64）およびARMアーキテクチャへのTiDBのデプロイをサポートしています。 - AMD64アーキテクチャでは、CentOS 7.3以降のバージョンを使用することをお勧めします。 - ARMアーキテクチャではCentOS 7.6（1810）を使用することをお勧めします。 @@ -315,13 +315,13 @@ TiDBクラスタの最小トポロジーは、以下のインスタンスで構 source ${your_shell_profile} ``` -3. TiUPのクラスタコンポーネントをインストールします。 +3. TiUPのクラスターコンポーネントをインストールします。 ```shell tiup cluster ``` -4. TiUPクラスタが既にマシンにインストールされている場合は、ソフトウェアバージョンを更新してください。 +4. TiUPクラスターが既にマシンにインストールされている場合は、ソフトウェアバージョンを更新してください。 ```shell tiup update --self && tiup update cluster @@ -401,7 +401,7 @@ TiDBクラスタの最小トポロジーは、以下のインスタンスで構 - host: 10.0.1.1 ``` - - `user: "tidb"` : `tidb`システムユーザー (デプロイ時に自動的に作成されます) を使用して、クラスタの内部管理を実行します。デフォルトでは、ポート 22 を使用して SSH 経由でターゲット マシンにログインします。 + - `user: "tidb"` : `tidb`システムユーザー (デプロイ時に自動的に作成されます) を使用して、クラスターの内部管理を実行します。デフォルトでは、ポート 22 を使用して SSH 経由でターゲット マシンにログインします。 - `replication.enable-placement-rules` : このPDパラメータは、 TiFlashが正常に動作するように設定されます。 - `host` : ターゲットマシンのIPアドレス。 @@ -412,7 +412,7 @@ TiDBクラスタの最小トポロジーは、以下のインスタンスで構 ``` - `` : クラスター名を設定します。 - - `` : TiDB クラスタのバージョンを設定します (例`v8.5.4` 。サポートされているすべての TiDB バージョンは`tiup list tidb`コマンドを実行することで確認できます。 + - `` : TiDB クラスターのバージョンを設定します (例`v8.5.4` 。サポートされているすべての TiDB バージョンは`tiup list tidb`コマンドを実行することで確認できます。 - `--user` : 環境を初期化するユーザーを指定します。 - `-p` : ターゲットマシンへの接続に使用するパスワードを指定します。 @@ -433,7 +433,7 @@ TiDBクラスタの最小トポロジーは、以下のインスタンスで構 tiup cluster start ``` -9. クラスタエンドポイントにアクセスします。 +9. クラスターエンドポイントにアクセスします。 - MySQLクライアントをインストールしてください。既にインストール済みの場合は、この手順をスキップしてください。 @@ -451,7 +451,7 @@ TiDBクラスタの最小トポロジーは、以下のインスタンスで構 - TiDB [http://{pd-ip}:2379/dashboard](http://%7Bpd-ip%7D:2379/dashboard) [TiDBダッシュボード](/dashboard/dashboard-intro.md)。デフォルトのユーザー名は`root`で、パスワードは空です。 -10. （オプション）クラスタ一覧とトポロジーをビュー。 +10. （オプション）クラスター一覧とトポロジーを確認する。 - クラスター一覧を表示するには： @@ -465,7 +465,7 @@ TiDBクラスタの最小トポロジーは、以下のインスタンスで構 tiup cluster display ``` - `tiup cluster`コマンドの詳細については、 [TiUPクラスタコマンド](/tiup/tiup-component-cluster.md)参照してください。 + `tiup cluster`コマンドの詳細については、 [TiUPクラスターコマンド](/tiup/tiup-component-cluster.md)参照してください。 11. テスト後にクラスターをクリーンアップしてください。 @@ -479,13 +479,13 @@ TiDBクラスタの最小トポロジーは、以下のインスタンスで構 ## 次は？ {#what-s-next} -ローカルテスト環境用にTiDBクラスタをデプロイしたばかりの場合は、次の手順を実行してください。 +ローカルテスト環境用にTiDBクラスターをデプロイしたばかりの場合は、次の手順を実行してください。 -- TiDB における基本的な SQL 操作については、 [TiDBにおける基本的なSQL操作](/basic-sql-operations.md)参照してください。 +- TiDB における基本的な SQL 操作については、 [TiDBでのSQL基本操作](/basic-sql-operations.md)参照してください。 - データをTiDBに移行するを参照して、TiDBにデータを[データをTiDBに移行する](/migration-overview.md)することもできます。 - TiUPを使用して TiDB クラスターを管理する方法について詳しくは、 [TiUPの概要](/tiup/tiup-overview.md)を参照してください。 -本番環境にTiDBクラスタをデプロイする準備が整ったら、次の手順に進んでください。 +本番環境にTiDBクラスターをデプロイする準備が整ったら、次の手順に進んでください。 - [TiUPを使用してTiDBをデプロイ](/production-deployment-using-tiup.md) - あるいは、 [Kubernetes 上の TiDB](https://docs.pingcap.com/tidb-in-kubernetes/stable)ドキュメントを参照して、 TiDB Operator を使用してクラウド上に TiDB をデプロイすることもできます。 diff --git a/read-historical-data.md b/read-historical-data.md index b5faa5e4bbfbf..8a5c05080780e 100644 --- a/read-historical-data.md +++ b/read-historical-data.md @@ -38,7 +38,7 @@ TiDB は、特別なクライアントやドライバーを使用せずに、標 ## TiDBがデータバージョンを管理する方法 {#how-tidb-manages-the-data-versions} -TiDBは、データのバージョン管理にマルチバージョン同時実行制御（MVCC）を実装しています。データの履歴バージョンは保持されます。これは、更新/削除のたびにデータオブジェクトの新しいバージョンが作成されるためです。データオブジェクトをその場で更新/削除するのではなく、新しいバージョンが作成されます。ただし、すべてのバージョンが保持されるわけではありません。特定の時間よりも古いバージョンは完全に削除され、履歴バージョンの過剰によって発生するstorageの占有量とパフォーマンスのオーバーヘッドを削減します。 +TiDBは、データのバージョン管理にマルチバージョン同時実行制御（MVCC）を実装しています。データの履歴バージョンは保持されます。これは、更新/削除のたびにデータオブジェクトの新しいバージョンが作成されるためです。データオブジェクトをその場で更新/削除するのではなく、新しいバージョンが作成されます。ただし、すべてのバージョンが保持されるわけではありません。特定の時間よりも古いバージョンは完全に削除され、履歴バージョンの過剰によって発生するストレージの占有量とパフォーマンスのオーバーヘッドを削減します。 TiDBでは、ガベージコレクション（GC）が定期的に実行され、古いデータバージョンが削除されます。GCの詳細については、 [TiDB ガベージコレクション (GC)](/garbage-collection-overview.md)参照してください。 diff --git a/releases/release-1.0-ga.md b/releases/release-1.0-ga.md index 476d8afd5019e..e0e87afc3a910 100644 --- a/releases/release-1.0-ga.md +++ b/releases/release-1.0-ga.md @@ -15,7 +15,7 @@ summary: TiDB 1.0は、MySQLとの互換性、SQLの最適化、安定性、そ - 関数シグネチャプッシュダウン - 内部データ形式を最適化して中間データのサイズを削減します - MySQLの互換性を強化する -- `NO_SQL_CACHE`構文をサポートし、storageエンジンのキャッシュ使用量を制限します +- `NO_SQL_CACHE`構文をサポートし、ストレージエンジンのキャッシュ使用量を制限します - ハッシュアグリゲータ演算子をリファクタリングしてメモリ使用量を削減する - ストリームアグリゲーターオペレーターをサポートする diff --git a/releases/release-1.1-alpha.md b/releases/release-1.1-alpha.md index 22c86cd7e2cf4..cf4c26a0e49ff 100644 --- a/releases/release-1.1-alpha.md +++ b/releases/release-1.1-alpha.md @@ -38,7 +38,7 @@ summary: 2018年1月19日にリリースされたTiDB 1.1 Alphaでは、MySQLと ## TiKV {#tikv} -- Raft学習者をサポート +- Raftラーナーをサポート - Raftスナップショットを最適化し、I/Oオーバーヘッドを削減する - TLSをサポート - RocksDB 構成を最適化してパフォーマンスを向上させる diff --git a/releases/release-2.0-ga.md b/releases/release-2.0-ga.md index 23156709160d7..2ff3f9dae738d 100644 --- a/releases/release-2.0-ga.md +++ b/releases/release-2.0-ga.md @@ -59,7 +59,7 @@ summary: 2018年4月27日にリリースされたTiDB 2.0 GAでは、MySQLとの ## PD {#pd} - サポート`Region Merge` 、データを削除した後に空の領域を結合する [実験的] -- サポート`Raft Learner` [実験的] +- サポート`Raftラーナー` [実験的] - スケジューラを最適化する - スケジューラをさまざまなリージョンサイズに適応させる - TiKV 障害時のデータ復元の優先度と速度を向上 diff --git a/releases/release-2.0-rc.5.md b/releases/release-2.0-rc.5.md index b6098b2c48d95..597c3925cb89d 100644 --- a/releases/release-2.0-rc.5.md +++ b/releases/release-2.0-rc.5.md @@ -1,6 +1,6 @@ --- title: TiDB 2.0 RC5 Release Notes -summary: TiDB 2.0 RC5は2018年4月17日にリリースされ、MySQLとの互換性、SQLの最適化、安定性が向上しました。TiDB、PD、TiKVの各コンポーネントに修正と最適化が施され、 Raft Learnerのサポート、スケジューリングのオーバーヘッド削減、新しいバッチ操作の追加などが行われました。また、メモリ使用量、エラー報告、設定調整に関する問題にも対処しました。 +summary: TiDB 2.0 RC5は2018年4月17日にリリースされ、MySQLとの互換性、SQLの最適化、安定性が向上しました。TiDB、PD、TiKVの各コンポーネントに修正と最適化が施され、 Raftラーナーのサポート、スケジューリングのオーバーヘッド削減、新しいバッチ操作の追加などが行われました。また、メモリ使用量、エラー報告、設定調整に関する問題にも対処しました。 --- # TiDB 2.0 RC5 リリースノート {#tidb-2-0-rc5-release-notes} @@ -12,7 +12,7 @@ summary: TiDB 2.0 RC5は2018年4月17日にリリースされ、MySQLとの互 - `Top-N`プッシュダウンルールの適用に関する問題を修正 - NULL値を含む列の行数の推定を修正 - バイナリ型のゼロ値を修正する -- 取引内の`BatchGet`問題を修正する +- トランザクション内の`BatchGet`問題を修正する - 消費スペースを削減するために、 `Add Index`操作をロールバックしながら書き込まれたデータをクリーンアップします。 - `insert on duplicate key update`ステートメントを最適化すると、パフォーマンスが10倍向上します - `UNIX_TIMESTAMP`関数によって返される結果の型に関する問題を修正しました @@ -23,7 +23,7 @@ summary: TiDB 2.0 RC5は2018年4月17日にリリースされ、MySQLとの互 ## PD {#pd} -- Raft Learnerのサポートを追加 +- Raftラーナーのサポートを追加 - バランスリージョンスケジューラを最適化してスケジューリングのオーバーヘッドを削減します - `schedule-limit`構成のデフォルト値を調整する - IDを頻繁に割り当てる問題を修正 diff --git a/releases/release-2.0.1.md b/releases/release-2.0.1.md index 8543bed6591dd..c27d9c4494240 100644 --- a/releases/release-2.0.1.md +++ b/releases/release-2.0.1.md @@ -30,11 +30,11 @@ summary: TiDB 2.0.1は2018年5月16日にリリースされ、MySQLとの互換 - 指定されたキー範囲でリージョンのバランスをとるための`Scatter Range`スケジューラを追加します。 - 新しく分割されたリージョンがマージされないように、マージリージョンのスケジュールを最適化します。 -- Learner関連の指標を追加する +- ラーナー関連の指標を追加する - 再起動後にスケジューラが誤って削除される問題を修正 - 設定ファイルの解析時に発生するエラーを修正 - etcdリーダーとPDリーダーが複製されない問題を修正 -- Learnerを閉じた後も表示される問題を修正しました +- ラーナーを閉じた後も表示される問題を修正しました - パケットサイズが大きすぎるためにリージョンの読み込みに失敗する問題を修正しました ## TiKV {#tikv} @@ -43,7 +43,7 @@ summary: TiDB 2.0.1は2018年5月16日にリリースされ、MySQLとの互換 - スロークエリログを最適化する - `thread_yield`の通話回数を減らす - スナップショットを生成する際に raftstore が誤ってブロックされるバグを修正しました -- 特別な状況でLearnerを正常に選出できない問題を修正しました +- 特別な状況でラーナーを正常に選出できない問題を修正しました - 極端な状況で分割によりダーティリードが発生する可能性がある問題を修正 - 読み取りスレッドプール構成のデフォルト値を修正します - 範囲削除の高速化 diff --git a/releases/release-2.0.2.md b/releases/release-2.0.2.md index 4299498a89344..2fb52cd0966dd 100644 --- a/releases/release-2.0.2.md +++ b/releases/release-2.0.2.md @@ -26,5 +26,5 @@ summary: TiDB 2.0.2は2018年5月21日にリリースされ、システムの安 - Raftログが印刷されない問題を修正 - より多くの gRPC 関連パラメータの設定をサポート - リーダー選出のタイムアウト範囲の設定をサポート -- 古くなった学習者が削除されない問題を修正 +- 古くなったラーナーが削除されない問題を修正 - Fix the issue that the snapshot intermediate file is mistakenly deleted diff --git a/releases/release-2.0.3.md b/releases/release-2.0.3.md index 31a465cebb719..88e0052324519 100644 --- a/releases/release-2.0.3.md +++ b/releases/release-2.0.3.md @@ -33,5 +33,5 @@ summary: TiDB 2.0.3は、システムの互換性と安定性の向上を伴い ## TiKV {#tikv} -- 学習者フラグが誤ってPDに報告されるバグを修正 +- ラーナーフラグが誤ってPDに報告されるバグを修正 - `do_div_mod`のうち`divisor/dividend`が 0 の場合、結果を取得する代わりにエラーを報告します。 diff --git a/releases/release-2.1-beta.md b/releases/release-2.1-beta.md index 7b6450dc0a4f8..d03a897edd8e1 100644 --- a/releases/release-2.1-beta.md +++ b/releases/release-2.1-beta.md @@ -1,6 +1,6 @@ --- title: TiDB 2.1 Beta Release Notes -summary: TiDB 2.1ベータリリースには、安定性、SQLオプティマイザー、統計情報、実行エンジンの改善が含まれています。MySQL構文のサポートが拡大し、メモリ使用量が削減され、DDLおよびDML文が最適化されています。PDはRaft PreVoteの有効化、スケジューラー問題の最適化、メトリクスの追加を行いました。TiKVはRustのアップグレード、メトリクスの追加、パフォーマンスの向上を行いました。互換性に関する注意事項として、新バージョンではv2.0.xへのロールバックがサポートされないこと、およびRaft Learnerがデフォルトで有効化されることなどが挙げられます。 +summary: TiDB 2.1ベータリリースには、安定性、SQLオプティマイザー、統計情報、実行エンジンの改善が含まれています。MySQL構文のサポートが拡大し、メモリ使用量が削減され、DDLおよびDML文が最適化されています。PDはRaft PreVoteの有効化、スケジューラー問題の最適化、メトリクスの追加を行いました。TiKVはRustのアップグレード、メトリクスの追加、パフォーマンスの向上を行いました。互換性に関する注意事項として、新バージョンではv2.0.xへのロールバックがサポートされないこと、およびRaftラーナーがデフォルトで有効化されることなどが挙げられます。 --- # TiDB 2.1 ベータ版リリースノート {#tidb-2-1-beta-release-notes} @@ -23,7 +23,7 @@ summary: TiDB 2.1ベータリリースには、安定性、SQLオプティマイ - いくつかのシナリオで`INSERT … ON DUPLICATE KEY UPDATE …`の誤った結果を修正しました - 組み込み関数`CONCAT_WS` 、 `FLOOR` 、 `CEIL` 、 `DIV`の誤った結果を修正しました - サーバ - - HTTP APIを追加して、TiKVクラスタ内のテーブルリージョンの分散を分散します。 + - HTTP APIを追加して、TiKVクラスター内のテーブルリージョンの分散を分散します。 - 自動`Analyze`のしきい値を制御するための`auto_analyze_ratio`システム変数を追加します - 一般ログを開くかどうかを制御するHTTP APIを追加します - ログレベルをオンラインで変更するためのHTTP APIを追加します @@ -68,8 +68,8 @@ summary: TiDB 2.1ベータリリースには、安定性、SQLオプティマイ - tikv-ctl unsafe リカバリ後にリージョン情報が更新されない問題を修正しました - 一部のシナリオでレプリカの移行によって TiKV ディスク領域が使い果たされる問題を修正しました - 互換性に関する注意事項 - - 新しいバージョンのstorageエンジンの更新により、v2.0.x 以前へのロールバックはサポートされません。 - - 新しいバージョンのPDでは、デフォルトで`raft learner`が有効になっています。クラスタを1.xから2.1にアップグレードする場合は、アップグレード前にマシンを停止するか、最初にTiKVにローリングアップデートを適用してからPDを適用する必要があります。 + - 新しいバージョンのストレージエンジンの更新により、v2.0.x 以前へのロールバックはサポートされません。 + - 新しいバージョンのPDでは、デフォルトで`raft learner`が有効になっています。クラスターを1.xから2.1にアップグレードする場合は、アップグレード前にマシンを停止するか、最初にTiKVにローリングアップデートを適用してからPDを適用する必要があります。 ## TiKV {#tikv} diff --git a/releases/release-2.1-ga.md b/releases/release-2.1-ga.md index c35fa1d637ba3..b145755988532 100644 --- a/releases/release-2.1-ga.md +++ b/releases/release-2.1-ga.md @@ -1,6 +1,6 @@ --- title: TiDB 2.1 GA Release Notes -summary: TiDB 2.1 GA は 2018 年 11 月 30 日にリリースされ、安定性、パフォーマンス、互換性、および使いやすさが大幅に向上しました。このリリースには、SQL オプティマイザー、SQL エグゼキューター、統計、式、サーバー、DDL、互換性、配置Driver(PD)、TiKV、およびツールの最適化が含まれています。また、高速なフルデータ インポートを実現するTiDB Lightning導入されています。ただし、TiDB 2.1 では、新しいstorageエンジンの採用により、v2.0.x 以前へのダウングレードはサポートされていません。さらに、TiDB 2.1 では並列 DDL が有効になっているため、バージョン 2.0.1 より前の TiDB を使用しているクラスターは、ローリング アップデートを使用して 2.1 にアップグレードできません。TiDB 2.0.6 以前から TiDB 2.1 にアップグレードする場合、進行中の DDL 操作によってアップグレード プロセスが遅くなる可能性があります。 +summary: TiDB 2.1 GA は 2018 年 11 月 30 日にリリースされ、安定性、パフォーマンス、互換性、および使いやすさが大幅に向上しました。このリリースには、SQL オプティマイザー、SQL エグゼキューター、統計、式、サーバー、DDL、互換性、配置Driver(PD)、TiKV、およびツールの最適化が含まれています。また、高速なフルデータ インポートを実現するTiDB Lightning導入されています。ただし、TiDB 2.1 では、新しいストレージエンジンの採用により、v2.0.x 以前へのダウングレードはサポートされていません。さらに、TiDB 2.1 では並列 DDL が有効になっているため、バージョン 2.0.1 より前の TiDB を使用しているクラスターは、ローリング アップデートを使用して 2.1 にアップグレードできません。TiDB 2.0.6 以前から TiDB 2.1 にアップグレードする場合、進行中の DDL 操作によってアップグレード プロセスが遅くなる可能性があります。 --- # TiDB 2.1 GA リリースノート {#tidb-2-1-ga-release-notes} @@ -83,13 +83,13 @@ summary: TiDB 2.1 GA は 2018 年 11 月 30 日にリリースされ、安定性 - [HTTP API](https://github.com/pingcap/tidb/blob/release-2.1/docs/tidb_http_api.md)を足す - - TiKVクラスタ内のテーブル領域の分布を散布する + - TiKVクラスター内のテーブル領域の分布を散布する - `general log`開くかどうかを制御します - ログレベルのオンライン変更をサポート - - TiDBクラスタ情報を確認する + - TiDBクラスター情報を確認する @@ -141,7 +141,7 @@ summary: TiDB 2.1 GA は 2018 年 11 月 30 日にリリースされ、安定性 - 可用性を最適化する - - バージョン管理メカニズムを導入し、クラスタのローリングアップデートを互換性を持ってサポートする + - バージョン管理メカニズムを導入し、クラスターのローリングアップデートを互換性を持ってサポートする - ネットワーク分離後にネットワークが回復したときにリーダーの再選出を回避するためにPDノード間で[`Raft PreVote`を有効にする](https://github.com/pingcap/pd/blob/5c7b18cf3af91098f07cf46df0b59fbf8c7c5462/conf/config.toml#L22) @@ -272,11 +272,11 @@ summary: TiDB 2.1 GA は 2018 年 11 月 30 日にリリースされ、安定性 ## アップグレードの注意事項 {#upgrade-caveat} -- TiDB 2.1は、新しいstorageエンジンの採用により、v2.0.x以前へのダウングレードをサポートしていません。 +- TiDB 2.1は、新しいストレージエンジンの採用により、v2.0.x以前へのダウングレードをサポートしていません。 -- TiDB 2.1では並列DDLが有効になっているため、TiDBバージョン2.0.1より前のクラスタはローリングアップデートを使用して2.1にアップグレードできません。以下の2つのオプションのいずれかを選択できます。 +- TiDB 2.1では並列DDLが有効になっているため、TiDBバージョン2.0.1より前のクラスターはローリングアップデートを使用して2.1にアップグレードできません。以下の2つのオプションのいずれかを選択できます。 - クラスターを停止し、2.1に直接アップグレードします - 2.0.1 以降の 2.0.x バージョンにロール アップデートし、その後 2.1 バージョンにロール アップデートします。 diff --git a/releases/release-2.1-rc.1.md b/releases/release-2.1-rc.1.md index d4bd9a7bebd2a..f39e08cd105ce 100644 --- a/releases/release-2.1-rc.1.md +++ b/releases/release-2.1-rc.1.md @@ -102,7 +102,7 @@ summary: TiDB 2.1 RC1は2018年8月24日にリリースされ、安定性、SQL ## PD {#pd} - 特徴 - - バージョン管理メカニズムを導入し、互換性を保ちながらクラスタのローリングアップデートをサポートする + - バージョン管理メカニズムを導入し、互換性を保ちながらクラスターのローリングアップデートをサポートする - `region merge`機能を有効にする - `GetPrevRegion`インターフェースをサポート - バッチでのリージョン分割をサポート diff --git a/releases/release-2.1-rc.2.md b/releases/release-2.1-rc.2.md index 386cce0b4cda2..5af30a8a2ca1c 100644 --- a/releases/release-2.1-rc.2.md +++ b/releases/release-2.1-rc.2.md @@ -44,9 +44,9 @@ summary: TiDB 2.1 RC2は2018年9月14日にリリースされ、安定性、SQL - TiDBの起動中に内部SQLを高優先度に設定する[＃7616](https://github.com/pingcap/tidb/pull/7616) - 監視メトリクス[＃7631](https://github.com/pingcap/tidb/pull/7631)で内部SQLとユーザーSQLをフィルタリングするために異なるラベルを使用する - 過去1週間の遅いクエリ上位30件をTiDBサーバー[＃7646](https://github.com/pingcap/tidb/pull/7646)に保存する - - TiDBクラスタ[＃7656](https://github.com/pingcap/tidb/pull/7656)のグローバルシステムタイムゾーンを設定する提案を提出する + - TiDBクラスター[＃7656](https://github.com/pingcap/tidb/pull/7656)のグローバルシステムタイムゾーンを設定する提案を提出する - 「GCの有効期間がトランザクション期間より短い」というエラーメッセージを充実させる[＃7658](https://github.com/pingcap/tidb/pull/7658) - - TiDBクラスタ[＃7638](https://github.com/pingcap/tidb/pull/7638)を起動するときにグローバルシステムのタイムゾーンを設定する + - TiDBクラスター[＃7638](https://github.com/pingcap/tidb/pull/7638)を起動するときにグローバルシステムのタイムゾーンを設定する - 互換性 - `Year`型[＃7542](https://github.com/pingcap/tidb/pull/7542)に符号なしフラグを追加 - `Prepare`モード[＃7525](https://github.com/pingcap/tidb/pull/7525)で`Year`型の結果の長さ`Execute`設定する問題を修正 diff --git a/releases/release-2.1-rc.3.md b/releases/release-2.1-rc.3.md index ffc5ba338a4c9..6a516e205409a 100644 --- a/releases/release-2.1-rc.3.md +++ b/releases/release-2.1-rc.3.md @@ -37,7 +37,7 @@ summary: TiDB 2.1 RC3は2018年9月29日にリリースされ、安定性、互 - DDL - タイムスタンプ型[＃7724](https://github.com/pingcap/tidb/pull/7724)の新しい列に新しいインデックスを作成するときに、インデックス値がタイムゾーン間で変換されない問題を修正しました。 - 列挙型[＃7767](https://github.com/pingcap/tidb/pull/7767)に新しい値を追加することをサポート - - etcdセッションの迅速な作成をサポートし、ネットワーク分離後のクラスタの可用性を向上します[＃7774](https://github.com/pingcap/tidb/pull/7774) + - etcdセッションの迅速な作成をサポートし、ネットワーク分離後のクラスターの可用性を向上します[＃7774](https://github.com/pingcap/tidb/pull/7774) ## PD {#pd} diff --git a/releases/release-2.1-rc.5.md b/releases/release-2.1-rc.5.md index cd09d2b03e799..2001bca3c70b7 100644 --- a/releases/release-2.1-rc.5.md +++ b/releases/release-2.1-rc.5.md @@ -33,7 +33,7 @@ summary: TiDB 2.1 RC5は2018年11月12日にリリースされ、安定性、SQL - `infoschema.profiling` [＃8096](https://github.com/pingcap/tidb/pull/8096)のテーブルデータを取得する際に発生したエラーを修正 - - バイナリログを書き込むために、UNIXソケットをポンプクライアントに置き換えます[＃8098](https://github.com/pingcap/tidb/pull/8098) + - バイナリログを書き込むために、UNIXソケットをPumpクライアントに置き換えます[＃8098](https://github.com/pingcap/tidb/pull/8098) - `tidb_slow_log_threshold`環境変数のしきい値を追加して、スローログ[＃8094](https://github.com/pingcap/tidb/pull/8094)動的に設定します。 - `tidb_query_log_max_len`環境変数が動的にログ[＃8200](https://github.com/pingcap/tidb/pull/8200)を設定する間に切り捨てられたSQL文の元の長さを追加します - `tidb_opt_write_row_id`環境変数を追加して、書き込みを許可するかどうかを制御する`_tidb_rowid` [＃8218](https://github.com/pingcap/tidb/pull/8218) diff --git a/releases/release-2.1.10.md b/releases/release-2.1.10.md index e05fd1bab33e7..3c609ddc21fdb 100644 --- a/releases/release-2.1.10.md +++ b/releases/release-2.1.10.md @@ -20,7 +20,7 @@ TiDB Ansible バージョン: 2.1.10 - `SLOW_QUERY`テーブルを使用してスローログ[＃10412](https://github.com/pingcap/tidb/pull/10412)をクエリするときに、スローログの 1 行が長すぎるとエラー レポートが発生する問題を修正しました。 - `DATETIME` + `INTERVAL`の結果が MySQL の結果と一致しないケースがある問題を修正[＃10416](https://github.com/pingcap/tidb/pull/10416) , [＃10418](https://github.com/pingcap/tidb/pull/10418) - うるう年の2月の無効な時刻のチェックを追加[＃10417](https://github.com/pingcap/tidb/pull/10417) -- クラスタ[＃10426](https://github.com/pingcap/tidb/pull/10426)初期化時に多数の競合エラーレポートを回避するために、DDL所有者でのみ内部初期化操作の制限を実行します。 +- クラスター[＃10426](https://github.com/pingcap/tidb/pull/10426)初期化時に多数の競合エラーレポートを回避するために、DDL所有者でのみ内部初期化操作の制限を実行します。 - 出力タイムスタンプ列のデフォルト値が`default current_timestamp on update current_timestamp` [＃10337](https://github.com/pingcap/tidb/issues/10337)の場合、 `DESC` MySQLと互換性がない問題を修正しました。 - `Update`文[＃10439](https://github.com/pingcap/tidb/pull/10439)の権限チェック中にエラーが発生する問題を修正 - `RANGE`の計算を間違えると、場合によっては`CHAR`列に間違った結果が出る問題を修正しました[＃10455](https://github.com/pingcap/tidb/pull/10455) @@ -53,7 +53,7 @@ TiDB Ansible バージョン: 2.1.10 - TiDB Lightning - TiDB Lightningが`importer` [＃176](https://github.com/pingcap/tidb-lightning/pull/176)へのデータ送信に失敗した場合の再試行機能を追加 - TiDBBinlog - - トラブルシューティングを容易にするためにPumpstorageログを最適化します[＃607](https://github.com/pingcap/tidb-binlog/pull/607) + - トラブルシューティングを容易にするためにPumpストレージログを最適化します[＃607](https://github.com/pingcap/tidb-binlog/pull/607) ## TiDB アンシブル {#tidb-ansible} diff --git a/releases/release-2.1.11.md b/releases/release-2.1.11.md index 40c36b00f6524..4b82800deb262 100644 --- a/releases/release-2.1.11.md +++ b/releases/release-2.1.11.md @@ -33,7 +33,7 @@ TiDB Ansible バージョン: 2.1.11 ## TiKV {#tikv} -- リーダーと学習者が[＃4751](https://github.com/tikv/tikv/pull/4751)人ずつしかいない場合に学習者が空のインデックスを読み取る問題を修正しました。 +- リーダーとラーナーが[＃4751](https://github.com/tikv/tikv/pull/4751)人ずつしかいない場合にラーナーが空のインデックスを読み取る問題を修正しました。 - スレッドプール内のプロセス`ScanLock`と`ResolveLock`高優先度に設定し、通常優先度[＃4791](https://github.com/tikv/tikv/pull/4791)コマンドへの影響を軽減します。 - 受信したスナップショット[＃4811](https://github.com/tikv/tikv/pull/4811)のすべてのファイルを同期する diff --git a/releases/release-2.1.13.md b/releases/release-2.1.13.md index 56a9807629f0c..aa5928081a2ef 100644 --- a/releases/release-2.1.13.md +++ b/releases/release-2.1.13.md @@ -14,7 +14,7 @@ TiDB Ansible バージョン: 2.1.13 ## TiDB {#tidb} - ホットスポットの問題を軽減するために、列に`AUTO_INCREMENT`属性が含まれている場合に`SHARD_ROW_ID_BITS`使用して行 ID を分散させる機能を追加します[＃10788](https://github.com/pingcap/tidb/pull/10788) -- 無効な DDL メタデータの有効期間を最適化して、TiDB クラスタ[＃10789](https://github.com/pingcap/tidb/pull/10789)アップグレード後に DDL 操作の通常の実行を回復する速度を向上します。 +- 無効な DDL メタデータの有効期間を最適化して、TiDB クラスター[＃10789](https://github.com/pingcap/tidb/pull/10789)アップグレード後に DDL 操作の通常の実行を回復する速度を向上します。 - `execdetails.ExecDetails`ポインタ[＃10833](https://github.com/pingcap/tidb/pull/10833)の結果としてコプロセッサーリソースを迅速に解放できないことによって引き起こされる、高同時シナリオでのOOM問題を修正しました。 - 統計情報を更新するかどうかを制御する`update-stats`構成項目を追加します[＃10772](https://github.com/pingcap/tidb/pull/10772) - ホットスポット問題を解決するために、リージョンプリスプリットをサポートする次の TiDB 固有の構文を追加します。 diff --git a/releases/release-2.1.18.md b/releases/release-2.1.18.md index 17d33b0b95a93..4fe03cf397ad1 100644 --- a/releases/release-2.1.18.md +++ b/releases/release-2.1.18.md @@ -65,7 +65,7 @@ TiDB Ansible バージョン: 2.1.18 - TiDBBinlog - `ALTER DATABASE`関連する DDL 操作によりDrainerが異常終了する問題を修正[＃770](https://github.com/pingcap/tidb-binlog/pull/770) - レプリケーション効率を向上させるためにコミットbinlog のトランザクション ステータス情報のクエリをサポートする[＃761](https://github.com/pingcap/tidb-binlog/pull/761) - - ドレイナーの`start_ts`ポンプの最大値`commit_ts` [＃759](https://github.com/pingcap/tidb-binlog/pull/759)より大きい場合にPumppanicが発生する可能性がある問題を修正しました。 + - Drainerの`start_ts`Pumpの最大値`commit_ts` [＃759](https://github.com/pingcap/tidb-binlog/pull/759)より大きい場合にPumppanicが発生する可能性がある問題を修正しました。 ## TiDB アンシブル {#tidb-ansible} diff --git a/releases/release-2.1.2.md b/releases/release-2.1.2.md index 5b6801b95744d..f6c79c39175aa 100644 --- a/releases/release-2.1.2.md +++ b/releases/release-2.1.2.md @@ -30,7 +30,7 @@ summary: TiDB 2.1.2およびTiDB Ansible 2.1.2は、2018年12月22日にリリ ## ツール {#tools} - TiDB Lightning - - Lightning でサポートされる最小のクラスタバージョンを TiDB 2.1.0 にする + - Lightning でサポートされる最小のクラスターバージョンを TiDB 2.1.0 にする - Lightning [＃144](https://github.com/pingcap/tidb-tools/issues/144)で解析された`JSON`データを含むファイルのコンテンツエラーを修正しました - チェックポイントを使用してLightningを再起動した後に`Too many open engines`発生する問題を修正しました - TiDBBinlog diff --git a/releases/release-2.1.3.md b/releases/release-2.1.3.md index 854a563cb0705..658dbb297ffc0 100644 --- a/releases/release-2.1.3.md +++ b/releases/release-2.1.3.md @@ -15,7 +15,7 @@ summary: TiDB 2.1.3 および TiDB Ansible 2.1.3 がリリースされ、シス - `SQL_MODE`厳密でない場合に文字列が無効な`TIME`形式の場合、 `CAST(str AS TIME(N))` nullを返すようにする[＃8966](https://github.com/pingcap/tidb/pull/8966) - `UPDATE`の処理中に生成されるカラムのpanic問題を修正[＃8980](https://github.com/pingcap/tidb/pull/8980) - いくつかのケースにおける統計ヒストグラムの上限オーバーフロー問題を修正[＃8989](https://github.com/pingcap/tidb/pull/8989) - - `_tidb_rowid`構築クエリの範囲をサポートし、テーブル全体のスキャンを回避してクラスタのストレスを軽減します[＃9059](https://github.com/pingcap/tidb/pull/9059) + - `_tidb_rowid`構築クエリの範囲をサポートし、テーブル全体のスキャンを回避してクラスターのストレスを軽減します[＃9059](https://github.com/pingcap/tidb/pull/9059) - `CAST(AS TIME)`精度が大きすぎる場合はエラーを返す[＃9058](https://github.com/pingcap/tidb/pull/9058) - 直積[＃9037](https://github.com/pingcap/tidb/pull/9037)で`Sort Merge Join`使用を許可する - 一部のケースで統計ワーカーがpanic後に再開できない問題を修正[＃9085](https://github.com/pingcap/tidb/pull/9085) diff --git a/releases/release-2.1.4.md b/releases/release-2.1.4.md index 55fc9fee6413f..37fb5b3958e94 100644 --- a/releases/release-2.1.4.md +++ b/releases/release-2.1.4.md @@ -35,6 +35,6 @@ summary: TiDB 2.1.4およびTiDB Ansible 2.1.4は、2019年2月15日にリリー - ダンプファイルの読み取りI/O同時実行を制限し、キャッシュミスが多すぎることによるパフォーマンスの低下を回避します[＃110](https://github.com/pingcap/tidb-lightning/pull/110) - インポートの安定性を向上させるために、単一のテーブルへのデータのバッチインポートをサポートします[＃110](https://github.com/pingcap/tidb-lightning/pull/113) - TiKV [＃4199](https://github.com/tikv/tikv/pull/4199)のインポートモードで自動圧縮を有効にする - - TiKV クラスタバージョンが 2.1.4 以降の場合、インポートモードでレベル 1 圧縮が自動的に実行されるため、TiKV 定期的なレベル 1 圧縮パラメータを無効にすることをサポートします[＃119](https://github.com/pingcap/tidb-lightning/pull/119) + - TiKV クラスターバージョンが 2.1.4 以降の場合、インポートモードでレベル 1 圧縮が自動的に実行されるため、TiKV 定期的なレベル 1 圧縮パラメータを無効にすることをサポートします[＃119](https://github.com/pingcap/tidb-lightning/pull/119) - インポーターのディスク容量を過度に消費しないようにインポートエンジンの数を制限する[＃119](https://github.com/pingcap/tidb-lightning/pull/119) - sync-diff-inspector [＃197](https://github.com/pingcap/tidb-tools/pull/197)の TiDB 統計を使用したチャンクの分割をサポート diff --git a/releases/release-2.1.8.md b/releases/release-2.1.8.md index 32465eb27a84f..1806d81d4ecfc 100644 --- a/releases/release-2.1.8.md +++ b/releases/release-2.1.8.md @@ -52,7 +52,7 @@ TiDB Ansible バージョン: 2.1.8 - Lightning のテーブルインポートの順序を最適化して、インポートプロセス中にクラスター上で`Checksum`と`Analyze`実行する大きなテーブルの影響を軽減し、 `Checksum`と`Analyze`の成功率を向上させます[＃156](https://github.com/pingcap/tidb-lightning/pull/156) - KVエンコーダ[＃145](https://github.com/pingcap/tidb-lightning/pull/145)の追加解析作業を回避するために、データソースファイルの内容をTiDBの`types.Datum`に直接解析することで、LightningのエンコードSQLパフォーマンスを50％向上しました。 -- TiDB Binlog Pumpに`storage.sync-log`構成項目を追加して、 Pump [＃529](https://github.com/pingcap/tidb-binlog/pull/529)でローカルstorageのディスクを非同期にフラッシュすることをサポートします。 +- TiDB Binlog Pumpに`ストレージ.sync-log`構成項目を追加して、 Pump [＃529](https://github.com/pingcap/tidb-binlog/pull/529)でローカルストレージのディスクを非同期にフラッシュすることをサポートします。 - TiDB Binlog PumpとDrainer [＃530](https://github.com/pingcap/tidb-binlog/pull/530)間の通信のトラフィック圧縮をサポート - TiDB Binlog Drainerに`syncer.sql-mode`構成項目を追加して、異なる`sql-mode` sを使用してDDLクエリを解析できるようにします[＃513](https://github.com/pingcap/tidb-binlog/pull/513) - TiDB Binlog Drainerに`syncer.ignore-table`構成項目を追加して、複製しないテーブルのフィルタリングをサポートします[＃526](https://github.com/pingcap/tidb-binlog/pull/526) diff --git a/releases/release-3.0-beta.md b/releases/release-3.0-beta.md index 008fc4716e733..8a3a3a5c9816d 100644 --- a/releases/release-3.0-beta.md +++ b/releases/release-3.0-beta.md @@ -22,7 +22,7 @@ summary: 2019年1月19日にリリースされたTiDB 3.0ベータ版は、安 - 外部結合の定数伝播を最適化し、結合結果の外部テーブルに関連するフィルタリング条件を外部結合を介して外部テーブルにプッシュダウンできるようにすることで、外部結合の無駄な計算を減らし、実行パフォーマンスを向上させます[＃7794](https://github.com/pingcap/tidb/pull/7794) - 投影除去の最適化ルールを集計除去の後の位置に調整し、冗長な`Project`演算子[＃7909](https://github.com/pingcap/tidb/pull/7909)回避する - `IFNULL`関数を最適化し、入力パラメータに NULL 以外の属性がある場合はこの関数を削除します[＃7924](https://github.com/pingcap/tidb/pull/7924) - - `_tidb_rowid`構築クエリの範囲をサポートし、テーブル全体のスキャンを回避してクラスタのストレスを軽減します[＃8047](https://github.com/pingcap/tidb/pull/8047) + - `_tidb_rowid`構築クエリの範囲をサポートし、テーブル全体のスキャンを回避してクラスターのストレスを軽減します[＃8047](https://github.com/pingcap/tidb/pull/8047) - `IN`サブクエリを最適化して集計後に内部結合を実行し、この最適化ルールを有効にしてデフォルトで開くかどうかを制御する`tidb_opt_insubq_to_join_and_agg`変数を追加します[＃7531](https://github.com/pingcap/tidb/pull/7531) - `DO`文[＃8343](https://github.com/pingcap/tidb/pull/8343)でのサブクエリの使用をサポート - 不要なテーブルスキャンと結合操作を削減し、実行パフォーマンスを向上させるために、外部結合除去の最適化ルールを追加します[＃8021](https://github.com/pingcap/tidb/pull/8021) @@ -100,7 +100,7 @@ summary: 2019年1月19日にリリースされたTiDB 3.0ベータ版は、安 - HTTPを使用した監視情報の取得をサポート[＃3855](https://github.com/tikv/tikv/pull/3855) - DST をより良くサポート[＃3786](https://github.com/tikv/tikv/pull/3786) - バッチ[＃3931](https://github.com/tikv/tikv/pull/3913)でのRaftメッセージの受信と送信をサポート -- 新しいstorageエンジン Titan [＃3985](https://github.com/tikv/tikv/pull/3985)を導入 +- 新しいストレージエンジン Titan [＃3985](https://github.com/tikv/tikv/pull/3985)を導入 - gRPCをv1.17.2にアップグレード[＃4023](https://github.com/tikv/tikv/pull/4023) - バッチ[＃4043](https://github.com/tikv/tikv/pull/4043)でクライアント要求を受信し、応答を送信することをサポートします。 - マルチスレッド対応[＃4044](https://github.com/tikv/tikv/pull/4044)適用 diff --git a/releases/release-3.0-ga.md b/releases/release-3.0-ga.md index b4098398c5ccd..5e42756f8331c 100644 --- a/releases/release-3.0-ga.md +++ b/releases/release-3.0-ga.md @@ -15,7 +15,7 @@ TiDB Ansible バージョン: 3.0.0 2019年6月28日にTiDB 3.0 GAがリリースされました。対応するTiDB Ansibleバージョンは3.0.0です。このリリースでは、TiDB 2.1と比較して、以下の点が大幅に改善されています。 -- 安定性。TiDB 3.0 は、最大 150 以上のノードと 300 TB 以上のstorageを備えた大規模クラスターで長期的な安定性を実証しています。 +- 安定性。TiDB 3.0 は、最大 150 以上のノードと 300 TB 以上のストレージを備えた大規模クラスターで長期的な安定性を実証しています。 - 使いやすさ。TiDB 3.0 では、標準化されたスロー クエリ ログ、十分に開発されたログ ファイル仕様、ユーザーの操作コストを削減する`EXPLAIN ANALYZE`や SQL トレースなどの新機能など、使いやすさが多面的に向上しています。 - パフォーマンス。TiDB 3.0のパフォーマンスは、TPC-CベンチマークではTiDB 2.1の4.5倍、Sysbenchベンチマークでは1.5倍以上です。Viewsのサポートにより、TPC-H 50G Q15は正常に動作できるようになりました。 - 新しい機能には、ウィンドウ関数、ビュー (**Experimental**)、パーティション テーブル、プラグイン フレームワーク、悲観的ロック (**Experimental**)、および`SQL Plan Management`含まれます。 @@ -77,8 +77,8 @@ TiDB Ansible バージョン: 3.0.0 - ホットスポットの問題を軽減するために、SQL ステートメントを使用して指定されたテーブルのインデックスと範囲でリージョンを分割することをサポートします。 - DDLタスクの再試行回数を制限するために`ddl_error_count_limit`グローバル変数を追加します。 - ホットスポットの問題を軽減するために、列に AUTO_INCREMENT 属性が含まれている場合に行 ID を分散するために`SHARD_ROW_ID_BITS`使用する機能を追加します。 - - 無効な DDL メタデータの有効期間を最適化して、TiDB クラスタのアップグレード後に DDL 操作の通常の実行を回復する速度を向上します。 -- 取引 + - 無効な DDL メタデータの有効期間を最適化して、TiDB クラスターのアップグレード後に DDL 操作の通常の実行を回復する速度を向上します。 +- トランザクション - 悲観的トランザクションモードをサポート（**Experimental**） - より多くのシナリオに適応するためにトランザクション処理ロジックを最適化します。 - デフォルト値の`tidb_disable_txn_auto_retry`を`on`に変更します。これは、自動コミットされないトランザクションは再試行されないことを意味します。 @@ -119,7 +119,7 @@ TiDB Ansible バージョン: 3.0.0 ## PD {#pd} - 単一ノードからのクラスターの再作成をサポート -- 大規模クラスタのetcdのstorageボトルネックを解決するために、リージョンメタデータをetcdからgo-leveldbstorageエンジンに移行します。 +- 大規模クラスターのetcdのストレージボトルネックを解決するために、リージョンメタデータをetcdからgo-leveldbストレージエンジンに移行します。 - API - トゥームストーンストアをクリアするための`remove-tombstone` API を追加します - リージョン情報を一括クエリするAPI `ScanRegions`を追加 diff --git a/releases/release-3.0.0-beta.1.md b/releases/release-3.0.0-beta.1.md index cfb4e0e0e3bad..4b92416b3eb30 100644 --- a/releases/release-3.0.0-beta.1.md +++ b/releases/release-3.0.0-beta.1.md @@ -49,7 +49,7 @@ TiDB Ansible バージョン: 3.0.0-beta.1 - - クエリコンテキストに基づいてChunkサイズを最適化し、SQL文の実行時間とクラスタのリソース消費を削減します[＃6489](https://github.com/pingcap/tidb/issues/6489) + - クエリコンテキストに基づいてChunkサイズを最適化し、SQL文の実行時間とクラスターのリソース消費を削減します[＃6489](https://github.com/pingcap/tidb/issues/6489) - 権限管理 - サポート`SET ROLE`と`CURRENT_ROLE` [＃9581](https://github.com/pingcap/tidb/pull/9581) - サポート`DROP ROLE` [＃9616](https://github.com/pingcap/tidb/pull/9616) @@ -107,7 +107,7 @@ TiDB Ansible バージョン: 3.0.0-beta.1 - 複製する必要のないファイルのフィルタリングをサポート - 生成された列の複製をサポート - 稲妻 - - TiKVの定期的なレベル1圧縮を無効にすることをサポートし、TiKVクラスタバージョンが2.1.4以降の場合、レベル1圧縮はインポートモード[＃119](https://github.com/pingcap/tidb-lightning/pull/119)で自動的に実行されます[＃4199](https://github.com/tikv/tikv/pull/4199) + - TiKVの定期的なレベル1圧縮を無効にすることをサポートし、TiKVクラスターバージョンが2.1.4以降の場合、レベル1圧縮はインポートモード[＃119](https://github.com/pingcap/tidb-lightning/pull/119)で自動的に実行されます[＃4199](https://github.com/tikv/tikv/pull/4199) - `table_concurrency`構成項目を追加して、インポートエンジンの数（デフォルトでは「16」）を制限し、インポーターのディスクスペース[＃119](https://github.com/pingcap/tidb-lightning/pull/119)過剰な使用を回避します。 - メモリ使用量を削減するために、中間状態SSTをディスクに保存することをサポート[＃4369](https://github.com/tikv/tikv/pull/4369) - TiKV-Importer のインポートパフォーマンスを最適化し、大規模なテーブルのデータとインデックスの個別インポートをサポートします[＃132](https://github.com/pingcap/tidb-lightning/pull/132) diff --git a/releases/release-3.0.0-rc.1.md b/releases/release-3.0.0-rc.1.md index 4cc04ea377002..6b7fed4f24eb5 100644 --- a/releases/release-3.0.0-rc.1.md +++ b/releases/release-3.0.0-rc.1.md @@ -82,7 +82,7 @@ TiDB Ansible バージョン: 3.0.0-rc.1 - 読み取りトラフィックの統計情報が不正確になる可能性がある問題を修正[＃4436](https://github.com/tikv/tikv/pull/4436) - 範囲[＃4503](https://github.com/tikv/tikv/pull/4503)削除するときにプレフィックス抽出プログラムがpanicを起こす可能性がある問題を修正しました - メモリ管理を最適化してメモリ割り当てとコピーを削減`Iterator Key Bound Option` [＃4537](https://github.com/tikv/tikv/pull/4537) - - 学習者のログギャップを考慮しないと、場合によってはpanicが発生する可能性がある問題を修正しました[＃4559](https://github.com/tikv/tikv/pull/4559) + - ラーナーのログギャップを考慮しないと、場合によってはpanicが発生する可能性がある問題を修正しました[＃4559](https://github.com/tikv/tikv/pull/4559) - 異なる`column families` [＃4612](https://github.com/tikv/tikv/pull/4612)間での`block cache`共有をサポート - サーバ @@ -112,7 +112,7 @@ TiDB Ansible バージョン: 3.0.0-rc.1 - TiDBBinlog - unsigned int 型の主キー列のbinlogデータが負の[＃573](https://github.com/pingcap/tidb-binlog/pull/573)場合にレプリケーションが中止される問題を修正しました。 - ダウンストリームが`pb`場合は圧縮オプションを提供しません。ダウンストリーム名を`pb`から`file`に変更します[＃559](https://github.com/pingcap/tidb-binlog/pull/559) - - Pumpにローカルstorage[＃509](https://github.com/pingcap/tidb-binlog/pull/509)への非同期フラッシュを許可する`storage.sync-log`設定項目を追加する + - Pumpにローカルストレージ[＃509](https://github.com/pingcap/tidb-binlog/pull/509)への非同期フラッシュを許可する`ストレージ.sync-log`設定項目を追加する - PumpとDrainer[＃495](https://github.com/pingcap/tidb-binlog/pull/495)間の通信のトラフィック圧縮をサポート - 異なるSQLモード[＃511](https://github.com/pingcap/tidb-binlog/pull/511)でのDDLクエリの解析をサポートするために、 Drainerに`syncer.sql-mode`構成項目を追加します。 - レプリケーションを必要としないテーブルを除外するための構成項目を`syncer.ignore-table`追加します[＃520](https://github.com/pingcap/tidb-binlog/pull/520) diff --git a/releases/release-3.0.0-rc.2.md b/releases/release-3.0.0-rc.2.md index 5d4f29a1477e3..a313f590c6c59 100644 --- a/releases/release-3.0.0-rc.2.md +++ b/releases/release-3.0.0-rc.2.md @@ -46,7 +46,7 @@ TiDB Ansible バージョン: 3.0.0-rc.2 - `tidb_low_resolution_tso`変数を追加して、バッチで取得されるTSOの数を制御し、TSOを取得するトランザクションの回数を減らし、データの一貫性がそれほど厳密に要求されないシナリオに適応します[＃10428](https://github.com/pingcap/tidb/pull/10428) - DDL - - TiDB [＃10272](https://github.com/pingcap/tidb/pull/10272)の旧バージョンのstorage内の文字セット名の大文字の問題を修正しました + - TiDB [＃10272](https://github.com/pingcap/tidb/pull/10272)の旧バージョンのストレージ内の文字セット名の大文字の問題を修正しました - テーブル作成時にテーブル領域を事前割り当てして、 [＃10221](https://github.com/pingcap/tidb/pull/10221)作成後の書き込みホットスポットを回避するテーブルパーティションのサポート`preSplit` - TiDBがPDのバージョン情報を誤って更新する場合がある問題を修正[＃10324](https://github.com/pingcap/tidb/pull/10324) - `ALTER DATABASE`文[＃10393](https://github.com/pingcap/tidb/pull/10393)を使用して文字セットと照合順序を変更することをサポートします @@ -59,7 +59,7 @@ TiDB Ansible バージョン: 3.0.0-rc.2 ## PD {#pd} -- リージョンメタデータを保存するために、デフォルトでリージョンstorageを有効にします[＃1524](https://github.com/pingcap/pd/pull/1524) +- リージョンメタデータを保存するために、デフォルトでリージョンストレージを有効にします[＃1524](https://github.com/pingcap/pd/pull/1524) - ホットリージョンのスケジューリングが別のスケジューラによって優先される問題を修正[＃1522](https://github.com/pingcap/pd/pull/1522) - リーダーの優先順位が有効にならない問題を修正[＃1533](https://github.com/pingcap/pd/pull/1533) - `ScanRegions` [＃1535](https://github.com/pingcap/pd/pull/1535)の gRPC インターフェースを追加する @@ -78,7 +78,7 @@ TiDB Ansible バージョン: 3.0.0-rc.2 - Raftstore - ラフトストアCPUの消費を減らすために休止状態領域をサポートする[＃4591](https://github.com/tikv/tikv/pull/4591) - - リーダーが学習者[＃4653](https://github.com/tikv/tikv/pull/4653) `ReadIndex`リクエストに返信しない問題を修正 + - リーダーがラーナー[＃4653](https://github.com/tikv/tikv/pull/4653) `ReadIndex`リクエストに返信しない問題を修正 - 一部のケースでリーダーの転送に失敗する問題を修正[＃4684](https://github.com/tikv/tikv/pull/4684) - いくつかのケースでダーティリードの問題を修正[＃4688](https://github.com/tikv/tikv/pull/4688) - スナップショットで適用されたデータが失われる場合がある問題を修正[＃4716](https://github.com/tikv/tikv/pull/4716) diff --git a/releases/release-3.0.0-rc.3.md b/releases/release-3.0.0-rc.3.md index b7b840bf61c1d..e0ae5b38b5314 100644 --- a/releases/release-3.0.0-rc.3.md +++ b/releases/release-3.0.0-rc.3.md @@ -55,12 +55,12 @@ TiDB Ansible バージョン: 3.0.0-rc.3 - `alter table`を使用して文字セットを変更すると`blob`型が変更される問題を修正[＃10698](https://github.com/pingcap/tidb/pull/10698) - ホットスポットの問題を軽減するために、列に`AUTO_INCREMENT`属性が含まれている場合に`SHARD_ROW_ID_BITS`使用して行 ID を分散させる機能を追加します[＃10794](https://github.com/pingcap/tidb/pull/10794) - `alter table`文[＃10808](https://github.com/pingcap/tidb/pull/10808)を使用して、保存された生成列の追加を禁止します。 - - DDLメタデータの無効な生存時間を最適化し、クラスタのアップグレード後にDDL操作が遅くなる期間を短縮します[＃10795](https://github.com/pingcap/tidb/pull/10795) + - DDLメタデータの無効な生存時間を最適化し、クラスターのアップグレード後にDDL操作が遅くなる期間を短縮します[＃10795](https://github.com/pingcap/tidb/pull/10795) ## PD {#pd} - 一方向のマージのみを許可するには、 `enable-two-way-merge`構成項目を追加します[＃1583](https://github.com/pingcap/pd/pull/1583) -- `AddLightLearner`と`AddLightPeer`スケジューリング操作を追加して、 リージョン Scatterスケジューリングを制限メカニズム[＃1563](https://github.com/pingcap/pd/pull/1563)によって制限されないようにします。 +- `AddLightラーナー`と`AddLightPeer`スケジューリング操作を追加して、 リージョン Scatterスケジューリングを制限メカニズム[＃1563](https://github.com/pingcap/pd/pull/1563)によって制限されないようにします。 - システムの起動時にデータのレプリカレプリケーションが 1 つしか存在しないため信頼性が不十分になる問題を修正しました[＃1581](https://github.com/pingcap/pd/pull/1581) - 構成チェックロジックを最適化して構成項目エラーを回避する[＃1585](https://github.com/pingcap/pd/pull/1585) - `store-balance-rate`構成の定義を、1分あたりに生成されるバランスオペレータ数の上限[＃1591](https://github.com/pingcap/pd/pull/1591)に調整します。 diff --git a/releases/release-3.0.11.md b/releases/release-3.0.11.md index 11018a6626978..cbcdc64ae5ff1 100644 --- a/releases/release-3.0.11.md +++ b/releases/release-3.0.11.md @@ -26,7 +26,7 @@ TiDB Ansible バージョン: 3.0.11 - `information_schema.PARTITIONS`テーブル[＃14849](https://github.com/pingcap/tidb/pull/14849)のパーティションテーブルのメタ情報の表示をサポート - TiDBBinlog - - TiDBクラスタ間の双方向データレプリケーションをサポート[＃884](https://github.com/pingcap/tidb-binlog/pull/884) [＃909](https://github.com/pingcap/tidb-binlog/pull/909) + - TiDBクラスター間の双方向データレプリケーションをサポート[＃884](https://github.com/pingcap/tidb-binlog/pull/884) [＃909](https://github.com/pingcap/tidb-binlog/pull/909) - TiDB Lightning - TLS構成[＃44](https://github.com/tikv/importer/pull/44) [＃270](https://github.com/pingcap/tidb-lightning/pull/270)をサポートする diff --git a/releases/release-3.0.14.md b/releases/release-3.0.14.md index 9815b0efb6b76..aeb00834d9f9a 100644 --- a/releases/release-3.0.14.md +++ b/releases/release-3.0.14.md @@ -40,7 +40,7 @@ TiDB バージョン: 3.0.14 - クライアントに TLS [＃15415](https://github.com/pingcap/tidb/pull/15415)使用を強制する`require-secure-transport`起動オプションをサポートする - TLS が設定されている場合に TiDB コンポーネント間の HTTP 通信をサポートする[＃15419](https://github.com/pingcap/tidb/pull/15419) - 現在のトランザクションの`start_ts`情報を`information_schema.processlist`テーブル[＃16160](https://github.com/pingcap/tidb/pull/16160)に追加します - - クラスタ間の通信に使用されるTLS証明書情報の自動再読み込みをサポート[＃15162](https://github.com/pingcap/tidb/pull/15162) + - クラスター間の通信に使用されるTLS証明書情報の自動再読み込みをサポート[＃15162](https://github.com/pingcap/tidb/pull/15162) - パーティションプルーニング[＃15628](https://github.com/pingcap/tidb/pull/15628)を再構築することで、パーティションテーブルの読み取りパフォーマンスが向上します。 - `range`パーティションテーブル[＃16521](https://github.com/pingcap/tidb/pull/16521)のパーティション式として`floor(unix_timestamp(a))`使用される場合のパーティションプルーニング機能をサポートします。 - `view`を含む`update`文の実行を許可し、 `view` [＃16787](https://github.com/pingcap/tidb/pull/16787)を更新しない @@ -105,9 +105,9 @@ TiDB バージョン: 3.0.14 - 一部のケースで分離回復後にノードを正しく削除できない問題を修正[＃7703](https://github.com/tikv/tikv/pull/7703) - リージョンマージ操作[＃7679](https://github.com/tikv/tikv/pull/7679)によってネットワーク分離中に発生するデータ損失の問題を修正 - - 学習者が正しく削除されない場合がある問題を修正[＃7598](https://github.com/tikv/tikv/pull/7598) + - ラーナーが正しく削除されない場合がある問題を修正[＃7598](https://github.com/tikv/tikv/pull/7598) - 生のキーと値のペアのスキャン結果が順序どおりに行われない可能性がある問題を修正[＃7597](https://github.com/tikv/tikv/pull/7597) - Raftメッセージのバッチが大きすぎる場合の再接続の問題を修正[＃7542](https://github.com/tikv/tikv/pull/7542) - 空のリクエスト[＃7538](https://github.com/tikv/tikv/pull/7538)によって引き起こされるgRPCスレッドデッドロックの問題を修正 - - マージ処理中に学習者を再起動する処理ロジックが正しくない問題を修正[＃7457](https://github.com/tikv/tikv/pull/7457) + - マージ処理中にラーナーを再起動する処理ロジックが正しくない問題を修正[＃7457](https://github.com/tikv/tikv/pull/7457) - ロックのクリーンアップの繰り返しリクエストによりトランザクションの原子性が破壊される可能性がある問題を修正[＃7388](https://github.com/tikv/tikv/pull/7388) diff --git a/releases/release-3.0.15.md b/releases/release-3.0.15.md index 83cc015734881..cd685d5dbde06 100644 --- a/releases/release-3.0.15.md +++ b/releases/release-3.0.15.md @@ -31,7 +31,7 @@ TiDB バージョン: 3.0.15 - ディープコピーを使用して、 `Hash`集計関数の`enum`と`set`型のデータをコピーします。正確性の問題を修正しました[＃16890](https://github.com/pingcap/tidb/pull/16890) - 整数オーバーフロー[＃16753](https://github.com/pingcap/tidb/pull/16753)の処理ロジックが間違っているため、 `PointGet`誤った結果を返す問題を修正しました - クエリ述語[＃16557](https://github.com/pingcap/tidb/pull/16557)で関数`CHAR()`使用されている場合に、誤った処理ロジックによって誤った結果が発生する問題を修正しました。 - - `IsTrue`と`IsFalse`関数[＃16627](https://github.com/pingcap/tidb/pull/16627)のstorageレイヤーと計算レイヤーで結果が一致しない問題を修正 + - `IsTrue`と`IsFalse`関数[＃16627](https://github.com/pingcap/tidb/pull/16627)のストレージレイヤーと計算レイヤーで結果が一致しない問題を修正 - いくつかの式における誤った`NotNull`フラグ（ `case when` [＃16993](https://github.com/pingcap/tidb/pull/16993)など）を修正します。 - 一部のシナリオでオプティマイザが`TableDual`物理プランを見つけられない問題を修正[＃17014](https://github.com/pingcap/tidb/pull/17014) - ハッシュパーティションテーブル[＃17051](https://github.com/pingcap/tidb/pull/17051)でパーティション選択の構文が正しく反映されない問題を修正しました。 diff --git a/releases/release-3.0.17.md b/releases/release-3.0.17.md index 4e75686d9688d..6399a68111b28 100644 --- a/releases/release-3.0.17.md +++ b/releases/release-3.0.17.md @@ -13,9 +13,9 @@ TiDB バージョン: 3.0.17 - TiDB - - `query-feedback-limit`構成項目のデフォルト値を1024から512に減らし、統計フィードバックメカニズムを改善してクラスタ[＃18770](https://github.com/pingcap/tidb/pull/18770)への影響を軽減します。 + - `query-feedback-limit`構成項目のデフォルト値を1024から512に減らし、統計フィードバックメカニズムを改善してクラスター[＃18770](https://github.com/pingcap/tidb/pull/18770)への影響を軽減します。 - 1 回のリクエストのバッチ分割数を制限する[＃18694](https://github.com/pingcap/tidb/pull/18694) - - TiDB クラスタ[＃18386](https://github.com/pingcap/tidb/pull/18386)に多くの履歴 DDL ジョブがある場合に`/tiflash/replica` HTTP API を高速化する + - TiDB クラスター[＃18386](https://github.com/pingcap/tidb/pull/18386)に多くの履歴 DDL ジョブがある場合に`/tiflash/replica` HTTP API を高速化する - インデックスの等価条件[＃17609](https://github.com/pingcap/tidb/pull/17609)行数推定の改善 - `kill tidb conn_id` [＃18506](https://github.com/pingcap/tidb/pull/18506)の実行を高速化する diff --git a/releases/release-3.0.2.md b/releases/release-3.0.2.md index 5a037aab17919..3a950f521bdd9 100644 --- a/releases/release-3.0.2.md +++ b/releases/release-3.0.2.md @@ -100,10 +100,10 @@ TiDB Ansible バージョン: 3.0.2 - TiKV パニック後にpanic情報がログファイルに書き込まれないバグを修正[＃5198](https://github.com/tikv/tikv/pull/5198) - 悲観的トランザクション[＃5203](https://github.com/tikv/tikv/pull/5203)で挿入操作が誤って実行される可能性があるバグを修正しました - 手動介入を必要としない一部のログの出力レベルをINFO [＃5193](https://github.com/tikv/tikv/pull/5193)に下げます。 -- storageエンジンサイズ[＃5200](https://github.com/tikv/tikv/pull/5200)監視精度を向上 +- ストレージエンジンサイズ[＃5200](https://github.com/tikv/tikv/pull/5200)監視精度を向上 - tikv-ctl [＃5195](https://github.com/tikv/tikv/pull/5195)のリージョンサイズの精度を向上 - 悲観的ロックのデッドロック検出器のパフォーマンスを向上させる[＃5192](https://github.com/tikv/tikv/pull/5192) -- Titanstorageエンジン[＃5197](https://github.com/tikv/tikv/pull/5197)のGCのパフォーマンスを向上 +- Titanストレージエンジン[＃5197](https://github.com/tikv/tikv/pull/5197)のGCのパフォーマンスを向上 ## PD {#pd} diff --git a/releases/release-3.0.3.md b/releases/release-3.0.3.md index c95365d7b7550..1f260ae2234bf 100644 --- a/releases/release-3.0.3.md +++ b/releases/release-3.0.3.md @@ -66,7 +66,7 @@ TiDB Ansible バージョン: 3.0.3 - TiDBBinlog - Drainerの起動時にOOMが発生する可能性を減らすため、 Drainerのデフォルト値`defaultBinlogItemCount`を65536から512に変更しました[＃721](https://github.com/pingcap/tidb-binlog/pull/721) - - ポンプサーバーのオフラインロジックを最適化して、潜在的なオフライン輻輳を回避する[＃701](https://github.com/pingcap/tidb-binlog/pull/701) + - Pumpサーバーのオフラインロジックを最適化して、潜在的なオフライン輻輳を回避する[＃701](https://github.com/pingcap/tidb-binlog/pull/701) - TiDB Lightning: - [＃225](https://github.com/pingcap/tidb-lightning/pull/225)インポートするときに、デフォルトでシステムデータベース`mysql` `performance_schema`スキップ`sys`ます`information_schema` diff --git a/releases/release-3.0.4.md b/releases/release-3.0.4.md index c00846bd9981b..9eb0cda5eee5f 100644 --- a/releases/release-3.0.4.md +++ b/releases/release-3.0.4.md @@ -18,7 +18,7 @@ TiDB Ansible バージョン: 3.0.4 - 改善点 - TiKV でバッチリージョン分割コマンドと空分割コマンドをサポートし、分割パフォーマンスを向上 - TiKV で RocksDB の二重リンクリストをサポートし、逆スキャンのパフォーマンスを向上 - - クラスタの状態をより適切に診断するために、TiDB Ansibleに2つのperfツール`iosnoop`と`funcslower`追加します。 + - クラスターの状態をより適切に診断するために、TiDB Ansibleに2つのperfツール`iosnoop`と`funcslower`追加します。 - 冗長なフィールドを削除して、TiDB のスロークエリログの出力を最適化します。 - 行動の変化 - デフォルト値の`txn-local-latches.enable`を`false`に更新して、TiDB のローカルトランザクションの競合をチェックするデフォルトの動作を無効にします。 @@ -122,7 +122,7 @@ TiDB Ansible バージョン: 3.0.4 - TiSparkをv2.2.0 [＃926](https://github.com/pingcap/tidb-ansible/pull/926)にアップグレード - TiDB構成項目`pessimistic_txn`のデフォルト値を`true` [＃933](https://github.com/pingcap/tidb-ansible/pull/933)に更新します。 - `node_exporter` [＃938](https://github.com/pingcap/tidb-ansible/pull/938)にシステムレベルの監視メトリックを追加します -- クラスタの状態をより適切に診断するために、TiDB Ansibleに2つのperfツール`iosnoop`と`funcslower`追加します[＃946](https://github.com/pingcap/tidb-ansible/pull/946) +- クラスターの状態をより適切に診断するために、TiDB Ansibleに2つのperfツール`iosnoop`と`funcslower`追加します[＃946](https://github.com/pingcap/tidb-ansible/pull/946) - パスワードの有効期限が切れた場合などに発生する長い待機時間に対処するために、rawモジュールをシェルモジュールに置き換えます[＃949](https://github.com/pingcap/tidb-ansible/pull/949) - TiDB構成項目`txn_local_latches`のデフォルト値を`false`に更新します - Grafanaダッシュボードの監視メトリックとアラートルールを最適化する[＃962](https://github.com/pingcap/tidb-ansible/pull/962) [＃963](https://github.com/pingcap/tidb-ansible/pull/963) [＃969](https://github.com/pingcap/tidb-ansible/pull/963) diff --git a/releases/release-3.0.5.md b/releases/release-3.0.5.md index 7336164f8d0c3..5fd50aa96ac3c 100644 --- a/releases/release-3.0.5.md +++ b/releases/release-3.0.5.md @@ -1,6 +1,6 @@ --- title: TiDB 3.0.5 Release Notes -summary: TiDB 3.0.5は、2019年10月25日にリリースされ、様々な改善とバグ修正が行われました。このリリースには、SQLオプティマイザー、SQL実行エンジン、サーバー、DDL、モニター、TiKV、PD、TiDB Binlog、 TiDB Lightning、TiDB Ansibleの機能強化が含まれています。改善点には、ウィンドウ関数の境界チェックのサポート、インデックス結合と外部結合の問題の修正、各種操作の監視メトリクスの追加などがあります。さらに、TiKVではstorageとパフォーマンスの最適化が行われ、PDではstorage精度とHTTPリクエスト処理が改善されました。TiDB Ansibleでは、監視メトリクスのアップデートと設定ファイルの簡素化も行われました。 +summary: TiDB 3.0.5は、2019年10月25日にリリースされ、様々な改善とバグ修正が行われました。このリリースには、SQLオプティマイザー、SQL実行エンジン、サーバー、DDL、モニター、TiKV、PD、TiDB Binlog、 TiDB Lightning、TiDB Ansibleの機能強化が含まれています。改善点には、ウィンドウ関数の境界チェックのサポート、インデックス結合と外部結合の問題の修正、各種操作の監視メトリクスの追加などがあります。さらに、TiKVではストレージとパフォーマンスの最適化が行われ、PDではストレージ精度とHTTPリクエスト処理が改善されました。TiDB Ansibleでは、監視メトリクスのアップデートと設定ファイルの簡素化も行われました。 --- # TiDB 3.0.5 リリースノート {#tidb-3-0-5-release-notes} @@ -69,7 +69,7 @@ TiDB Ansible バージョン: 3.0.5 ## PD {#pd} -- リージョン[＃1782](https://github.com/pingcap/pd/pull/1782)が占有するstorageの精度を向上 +- リージョン[＃1782](https://github.com/pingcap/pd/pull/1782)が占有するストレージの精度を向上 - `--help`コマンド[＃1763](https://github.com/pingcap/pd/pull/1763)の出力を改善する - TLS を有効にした後に HTTP リクエストがリダイレクトに失敗する問題を修正[＃1777](https://github.com/pingcap/pd/pull/1777) - pd-ctlが`store shows limit`コマンド[＃1808](https://github.com/pingcap/pd/pull/1808)使用する際に発生するpanic問題を修正 @@ -80,7 +80,7 @@ TiDB Ansible バージョン: 3.0.5 - Tidb Binlog - `ALTER DATABASE`関連する DDL 操作によりDrainerが異常終了する問題を修正[＃769](https://github.com/pingcap/tidb-binlog/pull/769) - レプリケーション効率を向上させるためにコミットbinlog のトランザクション ステータス情報のクエリをサポートする[＃757](https://github.com/pingcap/tidb-binlog/pull/757) - - ドレイナーの`start_ts`ポンプの最大値`commit_ts` [＃758](https://github.com/pingcap/tidb-binlog/pull/758)より大きい場合にPumppanicが発生する可能性がある問題を修正しました。 + - Drainerの`start_ts`Pumpの最大値`commit_ts` [＃758](https://github.com/pingcap/tidb-binlog/pull/758)より大きい場合にPumppanicが発生する可能性がある問題を修正しました。 - TiDB Lightning - Loaderの完全なロジックインポート機能を統合し、バックエンドモード[＃221](https://github.com/pingcap/tidb-lightning/pull/221)構成をサポートします。 diff --git a/releases/release-3.0.6.md b/releases/release-3.0.6.md index 36ef9aa028aca..c3f971131d7cd 100644 --- a/releases/release-3.0.6.md +++ b/releases/release-3.0.6.md @@ -92,7 +92,7 @@ TiDB Ansible バージョン: 3.0.6 - TiDBBinlog - Drainer [＃788](https://github.com/pingcap/tidb-binlog/pull/788)で`initial-commit-ts` 「-1」に設定されている場合にPDから初期レプリケーションタイムスタンプを取得します。 - - Drainerの`Checkpoint`storageを下流から分離し、MySQLまたはローカルファイル[＃790](https://github.com/pingcap/tidb-binlog/pull/790)への保存`Checkpoint`サポートします。 + - Drainerの`Checkpoint`ストレージを下流から分離し、MySQLまたはローカルファイル[＃790](https://github.com/pingcap/tidb-binlog/pull/790)への保存`Checkpoint`サポートします。 - レプリケーションデータベース/テーブルフィルタリングを構成する際に空の値を使用することで発生するDrainerpanicの問題を修正しました[＃801](https://github.com/pingcap/tidb-binlog/pull/801) - Drainer が下流にbinlogファイルを適用できないためにpanicが発生した後、プロセスが終了せずにデッドロック状態になる問題を修正しました[＃807](https://github.com/pingcap/tidb-binlog/pull/807) - gRPC の`GracefulStop` [＃817](https://github.com/pingcap/tidb-binlog/pull/817)が原因で、Pumpが終了時にブロックされる問題を修正しました。 diff --git a/releases/release-3.1.0-beta.2.md b/releases/release-3.1.0-beta.2.md index 708ccdd324a33..1e6d38b23a0d1 100644 --- a/releases/release-3.1.0-beta.2.md +++ b/releases/release-3.1.0-beta.2.md @@ -19,7 +19,7 @@ TiDB Ansible バージョン: 3.1.0-beta.2 - ツール - TiDB Lightning - - 構成ファイル[＃255](https://github.com/pingcap/tidb-lightning/pull/255)で設定されていない特定の項目については、 [TiDB Lightningコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md)で指定されたデフォルト設定を使用します。 + - 構成ファイル[＃255](https://github.com/pingcap/tidb-lightning/pull/255)で設定されていない特定の項目については、 [TiDB Lightning設定](/tidb-lightning/tidb-lightning-configuration.md)で指定されたデフォルト設定を使用します。 - TiDBパスワードを設定するための`--tidb-password` CLIパラメータを追加する[＃253](https://github.com/pingcap/tidb-lightning/pull/253) ## 新機能 {#new-features} @@ -27,8 +27,8 @@ TiDB Ansible バージョン: 3.1.0-beta.2 - TiDB - 列属性に`AutoRandom`キーワードを追加することで、TiDB が主キーにランダムな整数を自動的に割り当てるようになり、主キー`AUTO_INCREMENT`によって発生する書き込みホットスポットを回避します[＃14555](https://github.com/pingcap/tidb/pull/14555) - DDL ステートメント[＃14537](https://github.com/pingcap/tidb/pull/14537)による列ストアのレプリカの作成または削除のサポート - - オプティマイザが異なるstorageエンジンを独立して選択できる機能を追加[＃14537](https://github.com/pingcap/tidb/pull/14537) - - SQLヒントが異なるstorageエンジンをサポートする機能を追加[＃14537](https://github.com/pingcap/tidb/pull/14537) + - オプティマイザが異なるストレージエンジンを独立して選択できる機能を追加[＃14537](https://github.com/pingcap/tidb/pull/14537) + - SQLヒントが異なるストレージエンジンをサポートする機能を追加[＃14537](https://github.com/pingcap/tidb/pull/14537) - `tidb_replica_read`システム変数[＃13464](https://github.com/pingcap/tidb/pull/13464)を使用してフォロワーからのデータの読み取りをサポート - TiKV - Raftstore diff --git a/releases/release-3.1.0-ga.md b/releases/release-3.1.0-ga.md index a6ba1c9c9e513..0ee3c0ecd6308 100644 --- a/releases/release-3.1.0-ga.md +++ b/releases/release-3.1.0-ga.md @@ -62,7 +62,7 @@ TiDB Ansible バージョン: 3.1.0 GA - `TypeNull`クラスが可変長型[＃15739](https://github.com/pingcap/tidb/pull/15739)と誤認されるために左結合の`sort`演算子がpanic問題を修正 - 監視セッション再試行エラーの数が不正確になる問題を修正[＃16120](https://github.com/pingcap/tidb/pull/16120) - `ALLOW_INVALID_DATES`モード[＃16171](https://github.com/pingcap/tidb/pull/16171)で`weekday`の間違った結果の問題を修正 - - クラスタにTiFlashノード[＃15761](https://github.com/pingcap/tidb/pull/15761)がある場合にガベージコレクション（GC）が正常に動作しない可能性がある問題を修正しました + - クラスターにTiFlashノード[＃15761](https://github.com/pingcap/tidb/pull/15761)がある場合にガベージコレクション（GC）が正常に動作しない可能性がある問題を修正しました - ハッシュパーティションテーブル[＃16219](https://github.com/pingcap/tidb/pull/16219)を作成する際にユーザーが大きなパーティション数を設定すると、TiDBがメモリ（OOM）になる問題を修正しました。 - 警告がエラーと誤認される問題を修正し、 `UNION`文が`SELECT`文と同じ動作になるようにします[＃16138](https://github.com/pingcap/tidb/pull/16138) - `TopN` mocktikv [＃16200](https://github.com/pingcap/tidb/pull/16200)にプッシュダウンしたときの実行エラーを修正しました @@ -78,7 +78,7 @@ TiDB Ansible バージョン: 3.1.0 GA - TiDBからスキーマを複製する際の`rename table`操作の潜在的な問題を修正 - 複数のデータパス構成で`rename table`操作によって発生するデータ損失の問題を修正しました - - 一部のシナリオでTiFlash が誤ったstorage容量を報告する問題を修正しました + - 一部のシナリオでTiFlash が誤ったストレージ容量を報告する問題を修正しました - リージョン結合が有効なときにTiFlashから読み取ることによって発生する可能性のある問題を修正しました - ツール diff --git a/releases/release-3.1.0-rc.md b/releases/release-3.1.0-rc.md index f29e28b63d12a..a5367de5671b5 100644 --- a/releases/release-3.1.0-rc.md +++ b/releases/release-3.1.0-rc.md @@ -41,7 +41,7 @@ TiDB Ansible バージョン: 3.1.0-rc - PD - - `shuffle-region-scheduler` [＃2235](https://github.com/pingcap/pd/pull/2235)を使用して学習者のスケジュール管理をサポート + - `shuffle-region-scheduler` [＃2235](https://github.com/pingcap/pd/pull/2235)を使用してラーナーのスケジュール管理をサポート - pd-ctlに配置ルール[＃2306](https://github.com/pingcap/pd/pull/2306)を設定するためのコマンドを追加する - ツール @@ -110,4 +110,4 @@ TiDB Ansible バージョン: 3.1.0-rc - バックアップと復元 (BR) - - BRがTiFlashクラスタデータを復元できない問題を修正[＃194](https://github.com/pingcap/br/pull/194) + - BRがTiFlashクラスターデータを復元できない問題を修正[＃194](https://github.com/pingcap/br/pull/194) diff --git a/releases/release-3.1.1.md b/releases/release-3.1.1.md index 9a06e5a321e7a..4bb106c0e8779 100644 --- a/releases/release-3.1.1.md +++ b/releases/release-3.1.1.md @@ -1,6 +1,6 @@ --- title: TiDB 3.1.1 Release Notes -summary: TiDB 3.1.1は2020年4月30日にリリースされました。新機能には、auto_rand_base`のテーブルオプションと`Feature ID`コメントが含まれます。バグ修正には、分離読み取り設定、パーティション選択構文、ネストされたクエリからの誤った結果が含まれます。TiFlash、バグ修正とデータ読み取りおよびstorageパス変更の改善が行われました。バックアップとリストア（BR）では、テーブルの復元とデータ挿入に関する問題が修正されました。 +summary: TiDB 3.1.1は2020年4月30日にリリースされました。新機能には、auto_rand_base`のテーブルオプションと`Feature ID`コメントが含まれます。バグ修正には、分離読み取り設定、パーティション選択構文、ネストされたクエリからの誤った結果が含まれます。TiFlash、バグ修正とデータ読み取りおよびストレージパス変更の改善が行われました。バックアップとリストア（BR）では、テーブルの復元とデータ挿入に関する問題が修正されました。 --- # TiDB 3.1.1 リリースノート {#tidb-3-1-1-release-notes} @@ -38,7 +38,7 @@ TiDB Ansible バージョン: 3.1.1 - 異常状態にあるリージョンからデータを読み取る際にエラーが発生する問題を修正しました - TiFlashのテーブル名のマッピングを修正して、 `recover table` / `flashback table`正しくサポートする - - テーブル名を変更するときに発生する可能性のあるデータ損失の問題を修正するためにstorageパスを変更します + - テーブル名を変更するときに発生する可能性のあるデータ損失の問題を修正するためにストレージパスを変更します - オンライン更新シナリオの読み取りモードを変更して読み取りパフォーマンスを向上させる - データベース/テーブル名に特殊文字が含まれている場合、アップグレード後にTiFlash が正常に起動しない問題を修正しました。 diff --git a/releases/release-3.1.2.md b/releases/release-3.1.2.md index 595cfc87785ba..678e55e3fa6aa 100644 --- a/releases/release-3.1.2.md +++ b/releases/release-3.1.2.md @@ -1,6 +1,6 @@ --- title: TiDB 3.1.2 Release Notes -summary: TiDB 3.1.2は2020年6月4日にリリースされました。バグ修正には、S3およびGCSを使用したバックアップおよびリストア時のエラー処理、およびリストア中の「DefaultNotFound」エラーが含まれます。バックアップ＆リストア（BR）などのツールは、ネットワーク状態が悪い場合に自動的に再試行するようになり、リストアの失敗やデータ損失の問題を修正し、S3storageを使用したサーバー側暗号化のためのAWS KMSをサポートします。 +summary: TiDB 3.1.2は2020年6月4日にリリースされました。バグ修正には、S3およびGCSを使用したバックアップおよびリストア時のエラー処理、およびリストア中の「DefaultNotFound」エラーが含まれます。バックアップ＆リストア（BR）などのツールは、ネットワーク状態が悪い場合に自動的に再試行するようになり、リストアの失敗やデータ損失の問題を修正し、S3ストレージを使用したサーバー側暗号化のためのAWS KMSをサポートします。 --- # TiDB 3.1.2 リリースノート {#tidb-3-1-2-release-notes} @@ -24,4 +24,4 @@ TiDB バージョン: 3.1.2 - 小さなテーブルを復元するときにリージョンリーダーが見つからないために発生する復元エラーを修正[＃303](https://github.com/pingcap/br/pull/303) - テーブルの行IDが`2^(63)` [＃323](https://github.com/pingcap/br/pull/323)を超えると復元中にデータ損失が発生する問題を修正しました - 空のデータベースとテーブルを復元できない問題を修正[＃318](https://github.com/pingcap/br/pull/318) - - S3storageをターゲットとする場合、サーバー側暗号化（SSE）にAWS KMSを使用するサポート[＃261](https://github.com/pingcap/br/pull/261) + - S3ストレージをターゲットとする場合、サーバー側暗号化（SSE）にAWS KMSを使用するサポート[＃261](https://github.com/pingcap/br/pull/261) diff --git a/releases/release-4.0-ga.md b/releases/release-4.0-ga.md index 7c63120fd6594..a5ee468394b98 100644 --- a/releases/release-4.0-ga.md +++ b/releases/release-4.0-ga.md @@ -33,7 +33,7 @@ TiDB バージョン: 4.0.0 - TiDB - 再試行コミットフェーズ[＃16849](https://github.com/pingcap/tidb/pull/16849)の`goroutines`数を制御するための`committer-concurrency`構成項目を追加します。 - `show table partition regions`構文[＃17294](https://github.com/pingcap/tidb/pull/17294)サポートする - - TiDBサーバー[＃15700](https://github.com/pingcap/tidb/pull/15700)が使用する一時ディスク領域を制限するための`tmp-storage-quota`構成項目を追加します + - TiDBサーバー[＃15700](https://github.com/pingcap/tidb/pull/15700)が使用する一時ディスク領域を制限するための`tmp-ストレージ-quota`構成項目を追加します - テーブルの作成時および変更時に、パーティションテーブルが一意のプレフィックスインデックスを使用しているかどうかのチェックをサポート[＃17213](https://github.com/pingcap/tidb/pull/17213) - `insert/replace into tbl_name partition` （ `partition_name_list` ）の声明[＃17313](https://github.com/pingcap/tidb/pull/17313)支持する - `Distinct`関数[＃17240](https://github.com/pingcap/tidb/pull/17240)使用するときに`collations`の値をチェックする機能をサポート @@ -42,7 +42,7 @@ TiDB バージョン: 4.0.0 - `in`式[＃17320](https://github.com/pingcap/tidb/pull/17320)範囲パーティションプルーニングをサポート - TiFlash - - Learnerがデータを読み取る際に、 `Lock CF`の`TSO`から`min commit ts`の条件を満たすデータをフィルタリングすることをサポートします。 + - ラーナーがデータを読み取る際に、 `Lock CF`の`TSO`から`min commit ts`の条件を満たすデータをフィルタリングすることをサポートします。 - `TIMESTAMP`種類の値が`1970-01-01 00:00:00`未満の場合に誤った計算結果を回避するために、システムが明示的にエラーを報告する機能を追加します。 - ログ検索時に正規表現でフラグの使用をサポート @@ -98,8 +98,8 @@ TiDB バージョン: 4.0.0 - 順序が乱れた`ReadIndex`パケット[＃7930](https://github.com/tikv/tikv/pull/7930)によるシステムパニックを修正 - 読み取り要求コールバック関数が呼び出されないために予期しないエラーが返される問題を修正[＃7921](https://github.com/tikv/tikv/pull/7921) - TiKV の再起動時にスナップショットファイルを誤って削除することで発生するシステムパニックを修正[＃7927](https://github.com/tikv/tikv/pull/7927) - - storage暗号化[＃7898](https://github.com/tikv/tikv/pull/7898)処理ロジックが正しくないため、 `master key`回転できない問題を修正しました - - storage暗号化が有効になっているときに、スナップショットの受信ファイル`lock cf`が暗号化されない問題を修正しました[＃7922](https://github.com/tikv/tikv/pull/7922) + - ストレージ暗号化[＃7898](https://github.com/tikv/tikv/pull/7898)処理ロジックが正しくないため、 `master key`回転できない問題を修正しました + - ストレージ暗号化が有効になっているときに、スナップショットの受信ファイル`lock cf`が暗号化されない問題を修正しました[＃7922](https://github.com/tikv/tikv/pull/7922) - PD @@ -109,7 +109,7 @@ TiDB バージョン: 4.0.0 - ツール - バックアップと復元 (BR) - - BRがクラウドstorage[＃298](https://github.com/pingcap/br/pull/298)からデータを復元する際にネットワークの問題によりデータの復元が失敗する問題を修正 + - BRがクラウドストレージ[＃298](https://github.com/pingcap/br/pull/298)からデータを復元する際にネットワークの問題によりデータの復元が失敗する問題を修正 - TiCDC - データ競合によるシステムパニックを修正[＃565](https://github.com/pingcap/tiflow/pull/565) [＃566](https://github.com/pingcap/tiflow/pull/566) - 誤った処理ロジックによるリソースリークやシステムブロックを修正する[＃574](https://github.com/pingcap/tiflow/pull/574) [＃586](https://github.com/pingcap/tiflow/pull/586) diff --git a/releases/release-4.0.0-beta.1.md b/releases/release-4.0.0-beta.1.md index cca981b33e649..8da58989b0116 100644 --- a/releases/release-4.0.0-beta.1.md +++ b/releases/release-4.0.0-beta.1.md @@ -51,7 +51,7 @@ TiDB Ansible バージョン: 4.0.0-beta.1 - `json_objectagg`集計関数[＃11154](https://github.com/pingcap/tidb/pull/11154)追加する - 監査ログに拒否された接続試行を記録することをサポート[＃14594](https://github.com/pingcap/tidb/pull/14594) - 1つのサーバーへの接続数を制御するために、 `max-server-connections`構成項目（デフォルトでは`4096` ）を追加します[＃14409](https://github.com/pingcap/tidb/pull/14409) - - サーバーレベル[＃14440](https://github.com/pingcap/tidb/pull/14440)で複数のstorageエンジンを指定して分離読み取りをサポート + - サーバーレベル[＃14440](https://github.com/pingcap/tidb/pull/14440)で複数のストレージエンジンを指定して分離読み取りをサポート - `Apply`オペレータと`Sort`オペレータのコストモデルを最適化して安定性を向上させる[＃13550](https://github.com/pingcap/tidb/pull/13550) [＃14708](https://github.com/pingcap/tidb/pull/14708) - TiKV diff --git a/releases/release-4.0.0-beta.2.md b/releases/release-4.0.0-beta.2.md index 153339d53926d..af861c0c7533c 100644 --- a/releases/release-4.0.0-beta.2.md +++ b/releases/release-4.0.0-beta.2.md @@ -27,7 +27,7 @@ TiDB Ansible バージョン: 4.0.0-beta.2 - ツール - TiDBBinlog - - TiDBクラスタ間の双方向データレプリケーションをサポート[＃879](https://github.com/pingcap/tidb-binlog/pull/879) [＃903](https://github.com/pingcap/tidb-binlog/pull/903) + - TiDBクラスター間の双方向データレプリケーションをサポート[＃879](https://github.com/pingcap/tidb-binlog/pull/879) [＃903](https://github.com/pingcap/tidb-binlog/pull/903) - TiDB Lightning - TLS構成[＃40](https://github.com/tikv/importer/pull/40) [＃270](https://github.com/pingcap/tidb-lightning/pull/270)をサポートする - TiCDC diff --git a/releases/release-4.0.0-beta.md b/releases/release-4.0.0-beta.md index 74e6bfb017adc..ccc0c25e97600 100644 --- a/releases/release-4.0.0-beta.md +++ b/releases/release-4.0.0-beta.md @@ -23,7 +23,7 @@ TiDB Ansible バージョン: 4.0.0-beta - インデックスマージ機能をサポートすることでテーブルクエリのパフォーマンスが向上します[＃10121](https://github.com/pingcap/tidb/pull/10121) [＃10512](https://github.com/pingcap/tidb/pull/10512) [＃11245](https://github.com/pingcap/tidb/pull/11245) [＃12225](https://github.com/pingcap/tidb/pull/12225) [＃12248](https://github.com/pingcap/tidb/pull/12248) [＃12305](https://github.com/pingcap/tidb/pull/12305) [＃12843](https://github.com/pingcap/tidb/pull/12843) - インデックス結果をキャッシュし、重複する結果を排除することで、範囲計算のパフォーマンスを向上させ、CPUオーバーヘッドを削減します[＃12856](https://github.com/pingcap/tidb/pull/12856) - スローログのレベルを通常のログのレベルから切り離す[＃12359](https://github.com/pingcap/tidb/pull/12359) -- `oom-use-tmp-storage`パラメータ（デフォルトは`true` ）を追加して、単一の SQL 文の実行でメモリ使用量が`mem-quota-query`超え、SQL に`Hash Join` [＃11832](https://github.com/pingcap/tidb/pull/11832) [＃11937](https://github.com/pingcap/tidb/pull/11937) [＃12116](https://github.com/pingcap/tidb/pull/12116) [＃12067](https://github.com/pingcap/tidb/pull/12067)が含まれている場合に、一時ファイルを使用して中間結果をキャッシュするかどうかを制御します。 +- `oom-use-tmp-ストレージ`パラメータ（デフォルトは`true` ）を追加して、単一の SQL 文の実行でメモリ使用量が`mem-quota-query`超え、SQL に`Hash Join` [＃11832](https://github.com/pingcap/tidb/pull/11832) [＃11937](https://github.com/pingcap/tidb/pull/11937) [＃12116](https://github.com/pingcap/tidb/pull/12116) [＃12067](https://github.com/pingcap/tidb/pull/12067)が含まれている場合に、一時ファイルを使用して中間結果をキャッシュするかどうかを制御します。 - `create index`を使用して式インデックスを作成し、 `drop index`を使用して式インデックス[＃14117](https://github.com/pingcap/tidb/pull/14117)を削除すること`alter table`サポートします。 - 切り捨てられたSQL出力の数を減らすには、パラメータ`query-log-max-len`のデフォルト値を`4096`に増やしてください。このパラメータは動的に調整できます[＃12491](https://github.com/pingcap/tidb/pull/12491) - 列属性に`AutoRandom`キーワードを追加して、システムが主キーにランダムな整数を自動的に割り当てるかどうかを制御できるようになりました。これにより、 `AUTO_INCREMENT`主キー[＃13127](https://github.com/pingcap/tidb/pull/13127)によって引き起こされるホットスポット問題が回避されます。 @@ -41,7 +41,7 @@ TiDB Ansible バージョン: 4.0.0-beta - `Chunk`を使用してTiKVによる通信のエンコード形式を最適化し、通信パフォーマンスを向上させる[＃12023](https://github.com/pingcap/tidb/pull/12023) [＃12536](https://github.com/pingcap/tidb/pull/12536) [＃12613](https://github.com/pingcap/tidb/pull/12613) [＃12621](https://github.com/pingcap/tidb/pull/12621) [＃12899](https://github.com/pingcap/tidb/pull/12899) [＃13060](https://github.com/pingcap/tidb/pull/13060) [＃13349](https://github.com/pingcap/tidb/pull/13349) - ワイドテーブル[＃12634](https://github.com/pingcap/tidb/pull/12634)のパフォーマンスを向上させるために新しい行ストア形式をサポートします。 - `Recover Binlog`インターフェースを最適化して、すべてのトランザクションがコミットされてからクライアント[＃13740](https://github.com/pingcap/tidb/pull/13740)に戻るようにする -- HTTP `info/all`インターフェース[＃13025](https://github.com/pingcap/tidb/pull/13025)を介してクラスタ内の TiDB サーバーによって有効になっているbinlogのステータスを照会する機能をサポート +- HTTP `info/all`インターフェース[＃13025](https://github.com/pingcap/tidb/pull/13025)を介してクラスター内の TiDB サーバーによって有効になっているbinlogのステータスを照会する機能をサポート - 悲観的トランザクションモード[＃14087](https://github.com/pingcap/tidb/pull/14087)を使用する場合、MySQL互換の`Read Committed`トランザクション分離レベルをサポートします。 - 大規模トランザクションをサポートします。トランザクションサイズは物理メモリのサイズによって制限されます。 - [＃11999](https://github.com/pingcap/tidb/pull/11999) [＃11986](https://github.com/pingcap/tidb/pull/11986) [＃11974](https://github.com/pingcap/tidb/pull/11974) [＃11817](https://github.com/pingcap/tidb/pull/11817) [＃11807](https://github.com/pingcap/tidb/pull/11807) @@ -74,7 +74,7 @@ TiDB Ansible バージョン: 4.0.0-beta - [＃6198](https://github.com/tikv/tikv/pull/6198) [＃6186](https://github.com/tikv/tikv/pull/6186) [＃6177](https://github.com/tikv/tikv/pull/6177) [＃6146](https://github.com/tikv/tikv/pull/6146) [＃6071](https://github.com/tikv/tikv/pull/6071) - [＃6042](https://github.com/tikv/tikv/pull/6042) [＃5877](https://github.com/tikv/tikv/pull/5877) [＃5806](https://github.com/tikv/tikv/pull/5806) [＃5803](https://github.com/tikv/tikv/pull/5803) [＃5800](https://github.com/tikv/tikv/pull/5800) - [＃5781](https://github.com/tikv/tikv/pull/5781) [＃5772](https://github.com/tikv/tikv/pull/5772) [＃5689](https://github.com/tikv/tikv/pull/5689) [＃5683](https://github.com/tikv/tikv/pull/5683) -- Followerレプリカからのデータの読み取りをサポート +- フォロワーレプリカからのデータの読み取りをサポート - [＃5051](https://github.com/tikv/tikv/pull/5051) [＃5118](https://github.com/tikv/tikv/pull/5118) [＃5213](https://github.com/tikv/tikv/pull/5213) [＃5316](https://github.com/tikv/tikv/pull/5316) [＃5401](https://github.com/tikv/tikv/pull/5401) - [＃5919](https://github.com/tikv/tikv/pull/5919) [＃5887](https://github.com/tikv/tikv/pull/5887) [＃6340](https://github.com/tikv/tikv/pull/6340) [＃6348](https://github.com/tikv/tikv/pull/6348) [＃6396](https://github.com/tikv/tikv/pull/6396) - インデックス[＃5682](https://github.com/tikv/tikv/pull/5682)を介したTiDBの読み取りデータのパフォーマンスを向上 @@ -91,14 +91,14 @@ TiDB Ansible バージョン: 4.0.0-beta ## PD {#pd} -- storageノードの負荷情報に応じてホットスポットのスケジュールを最適化することをサポート +- ストレージノードの負荷情報に応じてホットスポットのスケジュールを最適化することをサポート - [＃1870](https://github.com/pingcap/pd/pull/1870) [＃1982](https://github.com/pingcap/pd/pull/1982) [＃1998](https://github.com/pingcap/pd/pull/1998) [＃1843](https://github.com/pingcap/pd/pull/1843) [＃1750](https://github.com/pingcap/pd/pull/1750) -- さまざまなスケジュールルールを組み合わせて、任意のデータ範囲のレプリカ数、storageの場所、storageホストの種類、およびロールを制御できる配置ルール機能を追加します。 +- さまざまなスケジュールルールを組み合わせて、任意のデータ範囲のレプリカ数、ストレージの場所、ストレージホストの種類、およびロールを制御できる配置ルール機能を追加します。 - [＃2051](https://github.com/pingcap/pd/pull/2051) [＃1999](https://github.com/pingcap/pd/pull/1999) [＃2042](https://github.com/pingcap/pd/pull/2042) [＃1917](https://github.com/pingcap/pd/pull/1917) [＃1904](https://github.com/pingcap/pd/pull/1904) - [＃1897](https://github.com/pingcap/pd/pull/1897) [＃1894](https://github.com/pingcap/pd/pull/1894) [＃1865](https://github.com/pingcap/pd/pull/1865) [＃1855](https://github.com/pingcap/pd/pull/1855) [＃1834](https://github.com/pingcap/pd/pull/1834) - プラグインの使用によるサポート（実験的） [＃1799](https://github.com/pingcap/pd/pull/1799) - スケジューラがカスタマイズされた構成とキー範囲をサポートする機能を追加します（実験的） [＃1735](https://github.com/pingcap/pd/pull/1735) [＃1783](https://github.com/pingcap/pd/pull/1783) [＃1791](https://github.com/pingcap/pd/pull/1791) -- クラスタ負荷情報に応じてスケジュール速度を自動的に調整する機能をサポート（実験的、デフォルトでは無効） [＃1875](https://github.com/pingcap/pd/pull/1875) [＃1887](https://github.com/pingcap/pd/pull/1887) [＃1902](https://github.com/pingcap/pd/pull/1902) +- クラスター負荷情報に応じてスケジュール速度を自動的に調整する機能をサポート（実験的、デフォルトでは無効） [＃1875](https://github.com/pingcap/pd/pull/1875) [＃1887](https://github.com/pingcap/pd/pull/1887) [＃1902](https://github.com/pingcap/pd/pull/1902) ## ツール {#tools} diff --git a/releases/release-4.0.0-rc.1.md b/releases/release-4.0.0-rc.1.md index 895b6fc2aae8e..615c94a73ca9f 100644 --- a/releases/release-4.0.0-rc.1.md +++ b/releases/release-4.0.0-rc.1.md @@ -38,7 +38,7 @@ TiDB バージョン: 4.0.0-rc.1 - マージされたリージョンからデータを読み取るときにエラーが発生する問題を修正しました - 異常状態にあるリージョンからデータを読み取る際にエラーが発生する問題を修正しました - TiFlashのテーブル名のマッピングを修正して、 `recover table` / `flashback table`正しくサポートする - - テーブル名を変更する際に発生する可能性のあるデータ損失の問題を修正するためにstorageパスを変更します。 + - テーブル名を変更する際に発生する可能性のあるデータ損失の問題を修正するためにストレージパスを変更します。 - スーパーバッチが有効な場合の TiDB の潜在的なpanicを修正 - オンライン更新シナリオの読み取りモードを変更して読み取りパフォーマンスを向上させる @@ -96,7 +96,7 @@ TiDB バージョン: 4.0.0-rc.1 - バックアップと復元 (BR) - - storageURL [＃246](https://github.com/pingcap/br/pull/246)での S3/GCS の設定をサポート + - ストレージURL [＃246](https://github.com/pingcap/br/pull/246)での S3/GCS の設定をサポート ## バグ修正 {#bug-fixes} @@ -130,7 +130,7 @@ TiDB バージョン: 4.0.0-rc.1 - 楽観的トランザクション[＃7604](https://github.com/tikv/tikv/pull/7604)で多くの書き込み競合が発生する場合、パフォーマンスを向上させるために`BatchRollback`で書き込まれたロールバックレコードを保護しないようにする - ロック競合の負荷が高いワークロードで、トランザクションの不要なウェイクアップによって無駄な再試行が発生し、パフォーマンスが低下する問題を修正しました[＃7551](https://github.com/tikv/tikv/pull/7551) - リージョンが複数回のマージでスタックする可能性がある問題を修正[＃7518](https://github.com/tikv/tikv/pull/7518) - - 学習者[＃7518](https://github.com/tikv/tikv/pull/7518)削除しても学習者が削除されない問題を修正 + - ラーナー[＃7518](https://github.com/tikv/tikv/pull/7518)削除してもラーナーが削除されない問題を修正 - raft-rs [＃7408](https://github.com/tikv/tikv/pull/7408)でフォロワーの読み取りによってpanicが発生する可能性がある問題を修正しました - `group by constant`エラー[＃7383](https://github.com/tikv/tikv/pull/7383)によりSQL操作が失敗する可能性があるバグを修正しました - 対応するプライマリロックが悲観的ロックの場合に楽観的ロックが読み取りをブロックする可能性がある問題を修正[＃7328](https://github.com/tikv/tikv/pull/7328) @@ -144,7 +144,7 @@ TiDB バージョン: 4.0.0-rc.1 - TiFlash - - storageエンジンの粗粒度インデックス最適化を無効にする + - ストレージエンジンの粗粒度インデックス最適化を無効にする - リージョンのロックを解決するときに例外がスローされ、一部のロックをスキップする必要があるというバグを修正しました。 - コプロセッサー統計の収集時に発生するヌルポインタ例外 (NPE) を修正しました - リージョン分割/リージョン結合のプロセスが正しいことを確認するために、リージョンメタのチェックを修正しました。 diff --git a/releases/release-4.0.0-rc.2.md b/releases/release-4.0.0-rc.2.md index ac803bb3b18c8..ca09a73a83745 100644 --- a/releases/release-4.0.0-rc.2.md +++ b/releases/release-4.0.0-rc.2.md @@ -71,7 +71,7 @@ TiDB バージョン: 4.0.0-rc.2 - TiKV - - tikv-ctl の暗号化デバッグをサポートし、暗号化storageが有効な場合に tikv-ctl を使用してクラスターを操作および管理できるようになりました[＃7698](https://github.com/tikv/tikv/pull/7698) + - tikv-ctl の暗号化デバッグをサポートし、暗号化ストレージが有効な場合に tikv-ctl を使用してクラスターを操作および管理できるようになりました[＃7698](https://github.com/tikv/tikv/pull/7698) - スナップショット[＃7712](https://github.com/tikv/tikv/pull/7712)のロックカラムファミリーの暗号化をサポート - Grafanaダッシュボードのヒートマップを使用して、 Raftstoreのレイテンシーサマリーを表示し、ジッターの問題をより適切に診断します[＃7717](https://github.com/tikv/tikv/pull/7717) - gRPC メッセージのサイズの上限設定をサポート[＃7824](https://github.com/tikv/tikv/pull/7824) @@ -89,13 +89,13 @@ TiDB バージョン: 4.0.0-rc.2 - Grafanaの**Read Index**のCountグラフの名前を**Ops**に変更します - システム負荷が低いときにファイル記述子を開くためのデータを最適化して、システムリソースの消費を削減します。 - - データstorage容量を制限するために容量関連の設定パラメータを追加します + - データストレージ容量を制限するために容量関連の設定パラメータを追加します - ツール - TiDB Lightning - - tidb-lightning-ctlに`fetch-mode`サブコマンドを追加して、TiKVクラスタモード[＃287](https://github.com/pingcap/tidb-lightning/pull/287)印刷します。 + - tidb-lightning-ctlに`fetch-mode`サブコマンドを追加して、TiKVクラスターモード[＃287](https://github.com/pingcap/tidb-lightning/pull/287)印刷します。 - TiCDC @@ -122,7 +122,7 @@ TiDB バージョン: 4.0.0-rc.2 - `IndexMerge` [＃16947](https://github.com/pingcap/tidb/pull/16947)の候補パスを計算するときにインデックスの`TableFilter`失われる問題を修正しました - `MergeJoin`ヒントを使用し、 `TableDual`演算子が存在する場合に物理クエリプランを生成できない問題を修正しました[＃17016](https://github.com/pingcap/tidb/pull/17016) - ステートメントサマリーテーブル[＃17018](https://github.com/pingcap/tidb/pull/17018)の`Stmt_Type`列目の値の大文字と小文字の誤りを修正しました。 - - 異なるユーザーが同じ`tmp-storage-path` [＃16996](https://github.com/pingcap/tidb/pull/16996)を使用するとサービスを開始できないため、 `Permission Denied`エラーが報告される問題を修正しました。 + - 異なるユーザーが同じ`tmp-ストレージ-path` [＃16996](https://github.com/pingcap/tidb/pull/16996)を使用するとサービスを開始できないため、 `Permission Denied`エラーが報告される問題を修正しました。 - 結果の型が`CASE WHEN` [＃16995](https://github.com/pingcap/tidb/pull/16995)などの複数の入力列によって決定される式に対して、 `NotNullFlag`結果の型が誤って設定される問題を修正しました。 - ダーティストアが存在する場合にグリーンGCが未解決のロックを残す可能性がある問題を修正[＃16949](https://github.com/pingcap/tidb/pull/16949) - 複数の異なるロックを持つ単一のキーに遭遇したときに、グリーンGCが未解決のロックを残す可能性がある問題を修正しました[＃16948](https://github.com/pingcap/tidb/pull/16948) @@ -152,7 +152,7 @@ TiDB バージョン: 4.0.0-rc.2 - 復元後に多くの空の領域が生成される問題を修正[＃7632](https://github.com/tikv/tikv/pull/7632) - 順序がずれたインデックス読み取り応答を受け取ったときにRaftstoreがpanic問題を修正[＃7370](https://github.com/tikv/tikv/pull/7370) - - 統合スレッドプールが有効な場合に、無効なstorageまたはコプロセッサ読み取りプール構成が拒否されない可能性がある問題を修正しました[＃7513](https://github.com/tikv/tikv/pull/7513) + - 統合スレッドプールが有効な場合に、無効なストレージまたはコプロセッサ読み取りプール構成が拒否されない可能性がある問題を修正しました[＃7513](https://github.com/tikv/tikv/pull/7513) - TiKVサーバーがシャットダウンされたときの`join`操作のpanic問題を修正しました[＃7713](https://github.com/tikv/tikv/pull/7713) - 診断API [＃7776](https://github.com/tikv/tikv/pull/7776)経由でTiKVスローログを検索しても結果が返されない問題を修正 - TiKVノードが長時間実行されると顕著なメモリ断片化が発生する問題を修正[＃7556](https://github.com/tikv/tikv/pull/7556) diff --git a/releases/release-4.0.1.md b/releases/release-4.0.1.md index 815bbbaae8178..bac7e83658df7 100644 --- a/releases/release-4.0.1.md +++ b/releases/release-4.0.1.md @@ -30,7 +30,7 @@ TiDB バージョン: 4.0.1 - バックアップと復元 (BR) - - BRとTiDBクラスタの互換性がない問題を回避するために、 BRの起動時にバージョンチェックを追加します[＃311](https://github.com/pingcap/br/pull/311) + - BRとTiDBクラスターの互換性がない問題を回避するために、 BRの起動時にバージョンチェックを追加します[＃311](https://github.com/pingcap/br/pull/311) ## バグ修正 {#bug-fixes} diff --git a/releases/release-4.0.10.md b/releases/release-4.0.10.md index 4b6a7eea68a4d..f0250e98d8988 100644 --- a/releases/release-4.0.10.md +++ b/releases/release-4.0.10.md @@ -96,7 +96,7 @@ TiDB バージョン: 4.0.10 - バックアップと復元 (BR) - GCS [＃688](https://github.com/pingcap/br/pull/688)でBR v4.0.8を使用してバックアップされたファイルをBR v4.0.9で復元できない問題を修正しました。 - - GCSstorageURL にプレフィックス[＃673](https://github.com/pingcap/br/pull/673)がない場合にBR がパニックになる問題を修正しました + - GCSストレージURL にプレフィックス[＃673](https://github.com/pingcap/br/pull/673)がない場合にBR がパニックになる問題を修正しました - BR OOM [＃693](https://github.com/pingcap/br/pull/693)回避するために、デフォルトでバックアップ統計を無効にする - TiDBBinlog diff --git a/releases/release-4.0.11.md b/releases/release-4.0.11.md index 40b66df0c0820..d1e365f5cc087 100644 --- a/releases/release-4.0.11.md +++ b/releases/release-4.0.11.md @@ -88,7 +88,7 @@ TiDB バージョン: 4.0.11 - 関数パラメータの数が無効な場合、生成された列の使用を禁止する[＃22174](https://github.com/pingcap/tidb/pull/22174) - 実行プランを構築する前にプロセス情報を正しく設定する[＃22148](https://github.com/pingcap/tidb/pull/22148) - `IndexLookUp` [＃22136](https://github.com/pingcap/tidb/pull/22136)の不正確な実行時統計の問題を修正 - - コンテナ[＃22116](https://github.com/pingcap/tidb/pull/22116)にクラスタをデプロイするときにメモリ使用量情報のキャッシュを追加する + - コンテナ[＃22116](https://github.com/pingcap/tidb/pull/22116)にクラスターをデプロイするときにメモリ使用量情報のキャッシュを追加する - デコードプランエラーの問題を修正[＃22022](https://github.com/pingcap/tidb/pull/22022) - 無効なウィンドウ仕様の使用によるエラーを報告[＃21976](https://github.com/pingcap/tidb/pull/21976) - `PREPARE`文が`EXECUTE` 、 `DEALLOCATE` 、または`PREPARE` [＃21972](https://github.com/pingcap/tidb/pull/21972)とネストされている場合はエラーを報告します。 @@ -140,7 +140,7 @@ TiDB バージョン: 4.0.11 - TiFlashがデータ読み取り時にクラッシュする可能性があるバグを修正 - DDL操作後に書き込まれたデータの一部がデータ圧縮後に失われる可能性がある問題を修正しました - TiFlashがコプロセッサー内の10進定数を正しく処理しない問題を修正 - - 学習者の読み取りプロセス中に発生する可能性のあるクラッシュを修正しました + - ラーナーの読み取りプロセス中に発生する可能性のあるクラッシュを修正しました - TiDBとTiFlash間の`0`または`NULL`による除算の不一致な動作を修正 - ツール diff --git a/releases/release-4.0.12.md b/releases/release-4.0.12.md index 1d591285d750c..f503cdc546acb 100644 --- a/releases/release-4.0.12.md +++ b/releases/release-4.0.12.md @@ -20,7 +20,7 @@ TiDB バージョン: 4.0.12 - TiDB - `batch cop`モード[＃23164](https://github.com/pingcap/tidb/pull/23164)の`EXPLAIN`文の出力情報を絞り込む - - `EXPLAIN`文[＃23020](https://github.com/pingcap/tidb/pull/23020)の出力に、storageレイヤーにプッシュできない式の警告情報を追加します。 + - `EXPLAIN`文[＃23020](https://github.com/pingcap/tidb/pull/23020)の出力に、ストレージレイヤーにプッシュできない式の警告情報を追加します。 - DDLパッケージコードの一部を`Execute` `ExecRestricted`安全なAPIに移行する（2） [＃22935](https://github.com/pingcap/tidb/pull/22935) - DDLパッケージコードの一部を`Execute` `ExecRestricted`安全なAPIに移行する（1） [＃22929](https://github.com/pingcap/tidb/pull/22929) - `optimization-time`と`wait-TS-time`スローログ[＃22918](https://github.com/pingcap/tidb/pull/22918)に加える @@ -61,7 +61,7 @@ TiDB バージョン: 4.0.12 - テーブル数が多い場合のバックアップパフォーマンスの向上[＃745](https://github.com/pingcap/br/pull/745) - サービスセーフポイントチェックが失敗した場合はエラーを報告する[＃826](https://github.com/pingcap/br/pull/826) - `backupmeta` [＃803](https://github.com/pingcap/br/pull/803)の`cluster_version`と`br_version`情報を加算します - - バックアップ[＃851](https://github.com/pingcap/br/pull/851)の成功率を上げるために、外部storageエラーの再試行を追加します。 + - バックアップ[＃851](https://github.com/pingcap/br/pull/851)の成功率を上げるために、外部ストレージエラーの再試行を追加します。 - バックアップ中のメモリ使用量を削減する[＃886](https://github.com/pingcap/br/pull/886) - TiDB Lightning @@ -70,7 +70,7 @@ TiDB バージョン: 4.0.12 - TiDB Lightningが`cancel`エラー[＃867](https://github.com/pingcap/br/pull/867)に遭遇したら、すぐに失敗しましょう - メモリ使用量とパフォーマンスのバランスをとるために、 `tikv-importer.engine-mem-cache-size`と`tikv-importer.local-writer-mem-cache-size`構成項目を追加します[＃866](https://github.com/pingcap/br/pull/866) - インポート速度を上げるために、TiDB Lightningのローカルバックエンドで`batch split region`並列実行します[＃868](https://github.com/pingcap/br/pull/868) - - TiDB Lightningを使用してS3storageからデータをインポートする場合、 TiDB Lightningは`s3:ListBucket`権限[＃919](https://github.com/pingcap/br/pull/919)必要としなくなりました。 + - TiDB Lightningを使用してS3ストレージからデータをインポートする場合、 TiDB Lightningは`s3:ListBucket`権限[＃919](https://github.com/pingcap/br/pull/919)必要としなくなりました。 - チェックポイントから再開する場合、 TiDB Lightningは元のエンジン[＃924](https://github.com/pingcap/br/pull/924)を使用し続けます。 ## バグ修正 {#bug-fixes} @@ -127,7 +127,7 @@ TiDB バージョン: 4.0.12 - バックアップと復元 (BR) - - ターゲットパスがバケット名[＃733](https://github.com/pingcap/br/pull/733)の場合、S3storageの`WalkDir` `nil`返すバグを修正しました + - ターゲットパスがバケット名[＃733](https://github.com/pingcap/br/pull/733)の場合、S3ストレージの`WalkDir` `nil`返すバグを修正しました - `status`ポートがTLS [＃839](https://github.com/pingcap/br/pull/839)で提供されないバグを修正 - TiDB Lightning diff --git a/releases/release-4.0.13.md b/releases/release-4.0.13.md index 33845522c3b0f..65b17ef27dd53 100644 --- a/releases/release-4.0.13.md +++ b/releases/release-4.0.13.md @@ -26,7 +26,7 @@ TiDB バージョン: 4.0.13 - `store used size`の計算プロセスをより正確にする[＃9904](https://github.com/tikv/tikv/pull/9904) - `EpochNotMatch`メッセージにさらに多くのリージョンを設定すると、リージョンのミス[＃9731](https://github.com/tikv/tikv/pull/9731)が減ります。 - - 長時間稼働するクラスタに蓄積されたメモリの解放を高速化[＃10035](https://github.com/tikv/tikv/pull/10035) + - 長時間稼働するクラスターに蓄積されたメモリの解放を高速化[＃10035](https://github.com/tikv/tikv/pull/10035) - PD @@ -42,7 +42,7 @@ TiDB バージョン: 4.0.13 - バックアップと復元 (BR) - `mysql`スキーマ[＃1077](https://github.com/pingcap/br/pull/1077)で作成されたユーザー テーブルのバックアップをサポート - - 更新`checkVersion`クラスタデータとバックアップデータ[＃1090](https://github.com/pingcap/br/pull/1090)チェックする + - 更新`checkVersion`クラスターデータとバックアップデータ[＃1090](https://github.com/pingcap/br/pull/1090)チェックする - バックアップ[＃1062](https://github.com/pingcap/br/pull/1062)中に少数のTiKVノード障害を許容する - TiCDC @@ -114,7 +114,7 @@ TiDB バージョン: 4.0.13 - `delta-merge-tasks`の数がPrometheusに報告されない問題を修正 - `Segment Split`中に発生するTiFlashpanic問題を修正 - Grafanaの`Region write Duration (write blocks)`パネルが間違った場所に表示される問題を修正しました - - storageエンジンがデータの削除に失敗する潜在的な問題を修正 + - ストレージエンジンがデータの削除に失敗する潜在的な問題を修正 - `TIME`型を`INTEGER`型にキャストしたときに結果が不正確になる問題を修正しました - `bitwise`演算子の動作がTiDBと異なるバグを修正 - `STRING`型を`INTEGER`型にキャストしたときに結果が不正確になる問題を修正しました diff --git a/releases/release-4.0.14.md b/releases/release-4.0.14.md index 2d0b659839c16..7ec06d674ae93 100644 --- a/releases/release-4.0.14.md +++ b/releases/release-4.0.14.md @@ -26,7 +26,7 @@ TiDB バージョン: 4.0.14 - TiKV - 保留中のPDハートビートの数を監視するメトリック`pending`を追加します。これは、遅いPDスレッド[＃10008](https://github.com/tikv/tikv/pull/10008)の問題の特定に役立ちます。 - - BRがS3互換storage[＃10242](https://github.com/tikv/tikv/pull/10242)サポートするために仮想ホストアドレス指定モードの使用をサポート + - BRがS3互換ストレージ[＃10242](https://github.com/tikv/tikv/pull/10242)サポートするために仮想ホストアドレス指定モードの使用をサポート - TiDBダッシュボード @@ -67,7 +67,7 @@ TiDB バージョン: 4.0.14 - Dumpling - - アップストリームが TiDB v3.x クラスタの場合は、常に`_tidb_rowid`を使用してテーブルを分割します。これにより、TiDB のメモリ使用量が削減されます[＃306](https://github.com/pingcap/dumpling/pull/306) + - アップストリームが TiDB v3.x クラスターの場合は、常に`_tidb_rowid`を使用してテーブルを分割します。これにより、TiDB のメモリ使用量が削減されます[＃306](https://github.com/pingcap/dumpling/pull/306) - TiCDC @@ -125,13 +125,13 @@ TiDB バージョン: 4.0.14 - **プロファイリング**UIがすべてのTiDBインスタンスをプロファイリングできない問題を修正[＃944](https://github.com/pingcap/tidb-dashboard/pull/944) - **明細書**UIに「プラン数」が表示されない問題を修正しました[＃939](https://github.com/pingcap/tidb-dashboard/pull/939) - - クラスタアップグレード[＃902](https://github.com/pingcap/tidb-dashboard/issues/902)後に**スロークエリ**UIに「不明なフィールド」エラーが表示される問題を修正しました + - クラスターアップグレード[＃902](https://github.com/pingcap/tidb-dashboard/issues/902)後に**スロークエリ**UIに「不明なフィールド」エラーが表示される問題を修正しました - TiFlash - DAGリクエストをコンパイルする際に発生する可能性のあるpanic問題を修正しました - 読み取り負荷が大きい場合に発生するpanic問題を修正しました - - 列storageの分割失敗によりTiFlashが再起動し続ける問題を修正しました + - 列ストレージの分割失敗によりTiFlashが再起動し続ける問題を修正しました - TiFlashがデルタデータを削除できない潜在的なバグを修正 - 共有デルタインデックスを同時に複製するときに発生する誤った結果を修正しました - データが不完全な場合にTiFlashが再起動に失敗するバグを修正 @@ -154,7 +154,7 @@ TiDB バージョン: 4.0.14 - Dumpling - - Dumplingを使用してS3storageにデータをエクスポートする場合、バケット全体に対する`s3:ListBucket`権限は不要になりました。この権限はデータソースプレフィックスに対してのみ必要です[＃898](https://github.com/pingcap/br/issues/898) + - Dumplingを使用してS3ストレージにデータをエクスポートする場合、バケット全体に対する`s3:ListBucket`権限は不要になりました。この権限はデータソースプレフィックスに対してのみ必要です[＃898](https://github.com/pingcap/br/issues/898) - TiCDC diff --git a/releases/release-4.0.15.md b/releases/release-4.0.15.md index 8c2725cf892fd..2efe0d589c3ea 100644 --- a/releases/release-4.0.15.md +++ b/releases/release-4.0.15.md @@ -56,7 +56,7 @@ TiDB バージョン: 4.0.15 - 領域を同時に分割して分散させることで、復元速度が向上します[＃1363](https://github.com/pingcap/br/pull/1363) - PD 要求エラーまたは TiKV I/O タイムアウト エラーが発生した場合は、 BRタスクを再試行します[＃27787](https://github.com/pingcap/tidb/issues/27787) - - 多数の小さなテーブルをリストアするときに空のリージョンを減らして、リストア後のクラスタ操作に影響を与えないようにします[＃1374](https://github.com/pingcap/br/issues/1374) + - 多数の小さなテーブルをリストアするときに空のリージョンを減らして、リストア後のクラスター操作に影響を与えないようにします[＃1374](https://github.com/pingcap/br/issues/1374) - テーブルの作成中に`rebase auto id`操作を実行すると、別の`rebase auto id` DDL操作が節約され、 [＃1424](https://github.com/pingcap/br/pull/1424)復元が高速化されます。 - Dumpling diff --git a/releases/release-4.0.2.md b/releases/release-4.0.2.md index 9fcc345a5b443..94aae612f1644 100644 --- a/releases/release-4.0.2.md +++ b/releases/release-4.0.2.md @@ -43,7 +43,7 @@ TiDB バージョン: 4.0.2 - SQL文[＃17493](https://github.com/pingcap/tidb/pull/17493)のプランキャッシュの使用状況を示すために、 `PERFORMANCE_SCHEMA.EVENTS_STATEMENTS_SUMMARY_BY_DIGEST`表に`PLAN_IN_CACHE`と`PLAN_CACHE_HITS`列目を追加します。 - `enable-collect-execution-info`構成項目と`tidb_enable_collect_execution_info`セッション変数を追加して、各演算子の実行情報を収集し、その情報をスロークエリログ[＃18073](https://github.com/pingcap/tidb/pull/18073) [＃18072](https://github.com/pingcap/tidb/pull/18072)に記録するかどうかを制御します。 - スロークエリログ[＃17694](https://github.com/pingcap/tidb/pull/17694)でクエリの感度を下げるかどうかを制御するグローバル変数`tidb_slow_log_masking`追加します。 - - `storage.block-cache.capacity` TiKV構成項目[＃17671](https://github.com/pingcap/tidb/pull/17671) `INFORMATION_SCHEMA.INSPECTION_RESULT`テーブルに診断ルールを追加します。 + - `ストレージ.block-cache.capacity` TiKV構成項目[＃17671](https://github.com/pingcap/tidb/pull/17671) `INFORMATION_SCHEMA.INSPECTION_RESULT`テーブルに診断ルールを追加します。 - データのバックアップと復元を行うSQL文`BACKUP`と`RESTORE`を追加する[＃15274](https://github.com/pingcap/tidb/pull/15274) - TiKV @@ -111,8 +111,8 @@ TiDB バージョン: 4.0.2 - `IndexMergeJoin`実行者が時々スタックする問題を修正[＃18091](https://github.com/pingcap/tidb/pull/18091) - メモリクォータ不足とクエリキャンセルがトリガーされたときに`IndexMergeJoin`のエグゼキュータがハングする問題を修正[＃17654](https://github.com/pingcap/tidb/pull/17654) - `Insert`と`Replace`エグゼキュータ[＃18062](https://github.com/pingcap/tidb/pull/18062)の過剰なカウントメモリ使用量を修正 - - `DROP DATABASE`と`DROP TABLE`同じデータベース[＃17901](https://github.com/pingcap/tidb/pull/17901)で同時に実行するとTiFlashstorageへのデータレプリケーションが停止する問題を修正 - - TiDBとオブジェクトstorageサービス[＃17844](https://github.com/pingcap/tidb/pull/17844)の`BACKUP` `RESTORE`障害を修正 + - `DROP DATABASE`と`DROP TABLE`同じデータベース[＃17901](https://github.com/pingcap/tidb/pull/17901)で同時に実行するとTiFlashストレージへのデータレプリケーションが停止する問題を修正 + - TiDBとオブジェクトストレージサービス[＃17844](https://github.com/pingcap/tidb/pull/17844)の`BACKUP` `RESTORE`障害を修正 - アクセスが拒否されたときに権限チェックに失敗したという誤ったエラーメッセージを修正しました[＃17724](https://github.com/pingcap/tidb/pull/17724) - `DELETE`文から`UPDATE`されたクエリフィードバックを破棄する[＃17843](https://github.com/pingcap/tidb/pull/17843) - `AUTO_RANDOM`プロパティ[＃17828](https://github.com/pingcap/tidb/pull/17828)のないテーブルでは`AUTO_RANDOM_BASE`変更を禁止します @@ -130,7 +130,7 @@ TiDB バージョン: 4.0.2 - `max_execution_time`ヒントが時々機能しない問題を修正[＃17536](https://github.com/pingcap/tidb/pull/17536) - `EXPLAIN ANALYZE` [＃17350](https://github.com/pingcap/tidb/pull/17350)の結果に同時実行情報が重複して出力される問題を修正しました - `STR_TO_DATE`関数[＃17498](https://github.com/pingcap/tidb/pull/17498)の`%h`の非互換な動作を修正 - - `tidb_replica_read` `follower`に設定され、リーダーとフォロワー/学習者[＃17443](https://github.com/pingcap/tidb/pull/17443)間にネットワーク パーティションがある場合にフォロワー/学習者が再試行を続ける問題を修正しました。 + - `tidb_replica_read` `follower`に設定され、リーダーとフォロワー/ラーナー[＃17443](https://github.com/pingcap/tidb/pull/17443)間にネットワーク パーティションがある場合にフォロワー/ラーナーが再試行を続ける問題を修正しました。 - TiDBがPDフォロワーにpingを送信しすぎる場合がある問題を修正[＃17947](https://github.com/pingcap/tidb/pull/17947) - TiDB v4.0 [＃17983](https://github.com/pingcap/tidb/pull/17983)で古いバージョンの範囲パーティションテーブルをロードできない問題を修正しました - 各リージョンに異なる`Backoffer`割り当てることで、複数のリージョン要求が同時に失敗した場合の SQL ステートメントのタイムアウト問題を修正しました[＃17585](https://github.com/pingcap/tidb/pull/17585) diff --git a/releases/release-4.0.3.md b/releases/release-4.0.3.md index f926f89f658fe..3613409288b26 100644 --- a/releases/release-4.0.3.md +++ b/releases/release-4.0.3.md @@ -146,7 +146,7 @@ TiDB バージョン: 4.0.3 - TiFlash - 主キー列の名前を変更した後にTiFlashがクラッシュする問題を修正 - - 同時実行`Learner Read`と`Remove Region`デッドロックを引き起こす可能性がある問題を修正 + - 同時実行`ラーナー Read`と`Remove Region`デッドロックを引き起こす可能性がある問題を修正 - ツール diff --git a/releases/release-4.0.5.md b/releases/release-4.0.5.md index b8b62270b60cb..bb6e438842f6f 100644 --- a/releases/release-4.0.5.md +++ b/releases/release-4.0.5.md @@ -1,6 +1,6 @@ --- title: TiDB 4.0.5 Release Notes -summary: TiDB 4.0.5は2020年8月31日にリリースされました。この新バージョンには、互換性の変更、新機能、改善、バグ修正、そしてTiKV、 TiFlash、ツール、PD、 TiDB Lightningのアップデートが含まれています。主な変更点としては、TiDBとの統合ログ形式のサポート、パフォーマンスの最適化、様々な問題に対するバグ修正、 TiFlash内のデータstorageにおける保存時暗号化のサポートなどが挙げられます。 +summary: TiDB 4.0.5は2020年8月31日にリリースされました。この新バージョンには、互換性の変更、新機能、改善、バグ修正、そしてTiKV、 TiFlash、ツール、PD、 TiDB Lightningのアップデートが含まれています。主な変更点としては、TiDBとの統合ログ形式のサポート、パフォーマンスの最適化、様々な問題に対するバグ修正、 TiFlash内のデータストレージにおける保存時暗号化のサポートなどが挙げられます。 --- # TiDB 4.0.5 リリースノート {#tidb-4-0-5-release-notes} @@ -67,18 +67,18 @@ TiDB バージョン: 4.0.5 - PDリーダーとフォロワー間のリージョンリーダーの変更の同期をサポート[＃2795](https://github.com/tikv/pd/pull/2795) - GCセーフポイントサービス[＃2797](https://github.com/tikv/pd/pull/2797)照会するためのコマンドを追加する - パフォーマンスを向上させるためにフィルターの`region.Clone`の呼び出しを置き換えます[＃2801](https://github.com/tikv/pd/pull/2801) - - 大規模クラスタのパフォーマンスを向上させるために、リージョンフローキャッシュの更新を無効にするオプションを追加します[＃2848](https://github.com/tikv/pd/pull/2848) + - 大規模クラスターのパフォーマンスを向上させるために、リージョンフローキャッシュの更新を無効にするオプションを追加します[＃2848](https://github.com/tikv/pd/pull/2848) - TiFlash - - CPU、I/O、RAMの使用状況やstorageエンジンのメトリクスを表示するためのGrafanaパネルを追加します。 + - CPU、I/O、RAMの使用状況やストレージエンジンのメトリクスを表示するためのGrafanaパネルを追加します。 - Raftログの処理ロジックを最適化することでI/O操作を削減 - ブロックされた`add partition` DDL文のリージョンスケジュールを高速化する - DeltaTree のデルタデータの圧縮を最適化して、読み取りと書き込みの増幅を削減します。 - 複数のスレッドを使用してスナップショットを前処理することにより、リージョンショットの適用パフォーマンスを最適化します。 - TiFlashの読み取り負荷が低いときに開くファイル記述子の数を最適化して、システムリソースの消費を削減します。 - TiFlashの再起動時に作成される不要な小さなファイルの数を最適化します - - データstorage時の暗号化をサポート + - データストレージ時の暗号化をサポート - データ転送にTLSをサポート - ツール diff --git a/releases/release-4.0.6.md b/releases/release-4.0.6.md index a49bac4d0cf09..29e6ece7b4444 100644 --- a/releases/release-4.0.6.md +++ b/releases/release-4.0.6.md @@ -19,7 +19,7 @@ TiDB バージョン: 4.0.6 - クエリエディタと実行UIの追加（実験的） [＃713](https://github.com/pingcap-incubator/tidb-dashboard/pull/713) - 店舗ロケーショントポロジ可視化[＃719](https://github.com/pingcap-incubator/tidb-dashboard/pull/719)サポート - - クラスタ構成UIの追加（実験的） [＃733](https://github.com/pingcap-incubator/tidb-dashboard/pull/733) + - クラスター構成UIの追加（実験的） [＃733](https://github.com/pingcap-incubator/tidb-dashboard/pull/733) - 現在のセッション[＃741](https://github.com/pingcap-incubator/tidb-dashboard/pull/741)共有をサポート - SQLステートメントリスト[＃746](https://github.com/pingcap-incubator/tidb-dashboard/pull/746)で実行プランの数を表示する機能をサポート @@ -157,7 +157,7 @@ TiDB バージョン: 4.0.6 - PD - - ブートストラップ[＃2922](https://github.com/pingcap/pd/pull/2922)中に異なるクラスタが相互に通信するのを防ぐために、 `initial-cluster-token`構成を追加します。 + - ブートストラップ[＃2922](https://github.com/pingcap/pd/pull/2922)中に異なるクラスターが相互に通信するのを防ぐために、 `initial-cluster-token`構成を追加します。 - モードが`auto` [＃2826](https://github.com/pingcap/pd/pull/2826)ときの店舗制限レートの単位を修正 - 一部のスケジューラがエラーを解決せずに構成を保持する問題を修正[＃2818](https://github.com/tikv/pd/pull/2818) - スケジューラ[＃2871](https://github.com/tikv/pd/pull/2871) [＃2874](https://github.com/tikv/pd/pull/2874)空のHTTPレスポンスを修正 diff --git a/releases/release-4.0.8.md b/releases/release-4.0.8.md index 6ed4ebf6e89cd..ff6529e31f8ee 100644 --- a/releases/release-4.0.8.md +++ b/releases/release-4.0.8.md @@ -34,7 +34,7 @@ TiDB バージョン: 4.0.8 - スローログの解析を高速化してクエリパフォーマンスを向上させる[＃20556](https://github.com/pingcap/tidb/pull/20556) - SQL オプティマイザが潜在的な新しいプランを検証しているときに、より多くのデバッグ情報を記録するために、プラン バインディング ステージ中にタイムアウト実行プランを待機します[＃20530](https://github.com/pingcap/tidb/pull/20530) - スローログに実行再試行時間を追加し、スロークエリの結果[＃20495](https://github.com/pingcap/tidb/pull/20495) [＃20494](https://github.com/pingcap/tidb/pull/20494) - - `table_storage_stats`システムテーブル[＃20431](https://github.com/pingcap/tidb/pull/20431)を追加する + - `table_ストレージ_stats`システムテーブル[＃20431](https://github.com/pingcap/tidb/pull/20431)を追加する - `INSERT` `REPLACE`のRPC実行時統計情報`UPDATE`追加する[＃20430](https://github.com/pingcap/tidb/pull/20430) - `EXPLAIN FOR CONNECTION` [＃20384](https://github.com/pingcap/tidb/pull/20384)の結果に演算子情報を追加します - クライアントの接続/切断アクティビティ[＃20321](https://github.com/pingcap/tidb/pull/20321)のTiDBエラーログを`DEBUG`レベルに調整します。 @@ -88,7 +88,7 @@ TiDB バージョン: 4.0.8 - マルチバイトCSV区切り文字とセパレーターをサポート[＃406](https://github.com/pingcap/tidb-lightning/pull/406) - 一部のPDスケジューラを無効にして復元プロセスを高速化します[＃408](https://github.com/pingcap/tidb-lightning/pull/408) - - v4.0 クラスタのチェックサム GC セーフポイントに GC-TTL API を使用して、GC エラー[＃396](https://github.com/pingcap/tidb-lightning/pull/396)を回避します。 + - v4.0 クラスターのチェックサム GC セーフポイントに GC-TTL API を使用して、GC エラー[＃396](https://github.com/pingcap/tidb-lightning/pull/396)を回避します。 ## バグ修正 {#bug-fixes} @@ -122,8 +122,8 @@ TiDB バージョン: 4.0.8 - 暗号化時のミューテックスの競合によりpd-workerのハートビート処理が遅くなるバグを修正[＃8869](https://github.com/tikv/tikv/pull/8869) - メモリプロファイルが誤って生成される問題を修正[＃8790](https://github.com/tikv/tikv/pull/8790) - - storageクラス[＃8763](https://github.com/tikv/tikv/pull/8763)が指定されている場合に GCS 上のデータベースをバックアップできない問題を修正しました - - リージョンが再起動されたり、新しく分割されたりしたときに学習者がリーダーを見つけられないバグを修正[＃8864](https://github.com/tikv/tikv/pull/8864) + - ストレージクラス[＃8763](https://github.com/tikv/tikv/pull/8763)が指定されている場合に GCS 上のデータベースをバックアップできない問題を修正しました + - リージョンが再起動されたり、新しく分割されたりしたときにラーナーがリーダーを見つけられないバグを修正[＃8864](https://github.com/tikv/tikv/pull/8864) - PD @@ -136,7 +136,7 @@ TiDB バージョン: 4.0.8 - マルチディスクTiFlash展開中に、間違った容量が原因でTiFlashレプリカの作成が失敗する問題を修正しました。 - 再起動後にTiFlashが壊れたデータファイルに関するエラーをスローする可能性があるバグを修正しました - TiFlashがクラッシュした後に壊れたファイルがディスク上に残る可能性がある問題を修正しました - - プロキシが最新のRaftリース情報に追いつけない場合、学習者の読み取り中にインデックスを待つのに長い時間がかかる可能性があるというバグを修正しました。 + - プロキシが最新のRaftリース情報に追いつけない場合、ラーナーの読み取り中にインデックスを待つのに長い時間がかかる可能性があるというバグを修正しました。 - 古いRaftログを再生中にプロキシがキー値エンジンに過剰なリージョン状態情報を書き込むバグを修正しました。 - ツール diff --git a/releases/release-4.0.9.md b/releases/release-4.0.9.md index 151693573b3be..f7a408b0c8c69 100644 --- a/releases/release-4.0.9.md +++ b/releases/release-4.0.9.md @@ -1,6 +1,6 @@ --- title: TiDB 4.0.9 Release Notes -summary: TiDB 4.0.9は2020年12月21日にリリースされました。このリリースには、互換性の変更、新機能、改善、バグ修正、そしてTiKV、TiDBダッシュボード、PD、 TiFlash 、そして各種ツールのアップデートが含まれています。注目すべき変更点としては、TiDBにおける「enable-streaming」設定項目の廃止、 TiFlashにおけるstorageエンジンの最新データを複数のディスクに保存する機能のサポート、そしてTiDBとTiKVにおける各種バグ修正などが挙げられます。 +summary: TiDB 4.0.9は2020年12月21日にリリースされました。このリリースには、互換性の変更、新機能、改善、バグ修正、そしてTiKV、TiDBダッシュボード、PD、 TiFlash 、そして各種ツールのアップデートが含まれています。注目すべき変更点としては、TiDBにおける「enable-streaming」設定項目の廃止、 TiFlashにおけるストレージエンジンの最新データを複数のディスクに保存する機能のサポート、そしてTiDBとTiKVにおける各種バグ修正などが挙げられます。 --- # TiDB 4.0.9 リリースノート {#tidb-4-0-9-release-notes} @@ -23,7 +23,7 @@ TiDB バージョン: 4.0.9 - TiFlash - - storageエンジンの最新データを複数のディスクに保存する機能をサポート (実験的) + - ストレージエンジンの最新データを複数のディスクに保存する機能をサポート (実験的) - TiDBダッシュボード @@ -96,7 +96,7 @@ TiDB バージョン: 4.0.9 - TiCDC - TiKV の Hibernate リージョン機能[＃1120](https://github.com/pingcap/tiflow/pull/1120)を有効にするためのアラートを追加する - - スキーマstorage[＃1127](https://github.com/pingcap/tiflow/pull/1127)のメモリ使用量を削減 + - スキーマストレージ[＃1127](https://github.com/pingcap/tiflow/pull/1127)のメモリ使用量を削減 - 増分スキャンのデータサイズが大きい場合にレプリケーションを高速化する統合ソーター機能を追加（実験的） [＃1122](https://github.com/pingcap/tiflow/pull/1122) - TiCDC オープンプロトコルメッセージの最大メッセージサイズと最大メッセージバッチの構成をサポート (Kafka シンクのみ) [＃1079](https://github.com/pingcap/tiflow/pull/1079) @@ -204,8 +204,8 @@ TiDB バージョン: 4.0.9 - 所有者キャンペーンキーが削除されたときに複数の所有者が存在する可能性がある問題を修正[＃1104](https://github.com/pingcap/tiflow/pull/1104) - TiKVノードがクラッシュまたはクラッシュから回復した際に、TiCDCがデータレプリケーションを続行できなくなる可能性があるバグを修正しました。このバグはv4.0.8にのみ存在します[＃1198](https://github.com/pingcap/tiflow/pull/1198) - テーブルが初期化される前にメタデータがetcdに繰り返しフラッシュされる問題を修正[＃1191](https://github.com/pingcap/tiflow/pull/1191) - - スキーマstorageがTiDB テーブル[＃1114](https://github.com/pingcap/tiflow/pull/1114)をキャッシュするときに、早期 GC または更新のレイテンシー`TableInfo`によって発生するレプリケーション中断の問題を修正しました。 - - DDL操作が頻繁に行われる場合にスキーマstorageのメモリ消費量が多すぎる問題を修正しました[＃1127](https://github.com/pingcap/tiflow/pull/1127) + - スキーマストレージがTiDB テーブル[＃1114](https://github.com/pingcap/tiflow/pull/1114)をキャッシュするときに、早期 GC または更新のレイテンシー`TableInfo`によって発生するレプリケーション中断の問題を修正しました。 + - DDL操作が頻繁に行われる場合にスキーマストレージのメモリ消費量が多すぎる問題を修正しました[＃1127](https://github.com/pingcap/tiflow/pull/1127) - チェンジフィードが一時停止または停止したときのゴルーチンリークを修正[＃1075](https://github.com/pingcap/tiflow/pull/1075) - 下流の Kafka [＃1118](https://github.com/pingcap/tiflow/pull/1118)サービスまたはネットワークジッターによるレプリケーションの中断を防ぐために、Kafka プロデューサーの最大再試行タイムアウトを 600 秒に増やします。 - Kafka のバッチサイズが有効にならないバグを修正[＃1112](https://github.com/pingcap/tiflow/pull/1112) diff --git a/releases/release-5.0.0-rc.md b/releases/release-5.0.0-rc.md index 1df4f25408f13..e32c9e89a8de5 100644 --- a/releases/release-5.0.0-rc.md +++ b/releases/release-5.0.0-rc.md @@ -18,8 +18,8 @@ v5.0 の主な新機能または改善点は次のとおりです。 - ジッターの低減。これは、オプティマイザーの安定性を向上させ、システムタスクによるI/O、ネットワーク、CPU、メモリリソースの使用を制限することで実現されます。例えば、72時間のパフォーマンステストでは、Sysbench TPSジッターの標準偏差が11.09%から3.36%に低減しました。 - リージョンメンバーシップの変更中にシステムの可用性を確保するRaftジョイント コンセンサス アルゴリズム。 - 最適化された`EXPLAIN`機能と非表示のインデックスにより、データベース管理者 (DBA) は SQL ステートメントをより効率的にデバッグできるようになります。 -- エンタープライズデータの信頼性を保証します。TiDBからAWS S3storageやGoogle Cloud GCSにデータをバックアップしたり、これらのクラウドstorageプラットフォームからデータを復元したりできます。 -- AWS S3storageまたはTiDB/MySQLとの間でのデータインポート/エクスポートのパフォーマンスが向上し、企業がクラウド上でアプリケーションを迅速に構築できるようになります。例えば、TPC-Cテストでは、1TiBデータのインポートパフォーマンスが254GiB/時間から366GiB/時間へと40%向上しました。 +- エンタープライズデータの信頼性を保証します。TiDBからAWS S3ストレージやGoogle Cloud GCSにデータをバックアップしたり、これらのクラウドストレージプラットフォームからデータを復元したりできます。 +- AWS S3ストレージまたはTiDB/MySQLとの間でのデータインポート/エクスポートのパフォーマンスが向上し、企業がクラウド上でアプリケーションを迅速に構築できるようになります。例えば、TPC-Cテストでは、1TiBデータのインポートパフォーマンスが254GiB/時間から366GiB/時間へと40%向上しました。 ## SQL {#sql} @@ -32,7 +32,7 @@ v5.0 の主な新機能または改善点は次のとおりです。 - 範囲条件を持つクエリに主キーのみが関係する場合、クラスター化インデックスにより、ネットワークからのインデックス データの複数回の読み取りが削減されます。 - 同等条件または範囲条件を持つクエリに主キー プレフィックスが含まれる場合、クラスター化インデックスによって、ネットワークからのインデックス データの複数回の読み取りが削減されます。 -クラスター化インデックスは、テーブル内のデータの物理的なstorage順序を定義します。テーブル内のデータは、クラスター化インデックスの定義に従ってのみソートされます。各テーブルには、クラスター化インデックスが1つだけ存在します。 +クラスター化インデックスは、テーブル内のデータの物理的なストレージ順序を定義します。テーブル内のデータは、クラスター化インデックスの定義に従ってのみソートされます。各テーブルには、クラスター化インデックスが1つだけ存在します。 ユーザーは、 `tidb_enable_clustered_index`変数を変更することでクラスター化インデックス機能を有効にできます。この機能を有効にすると、新規作成されたテーブルにのみ適用され、複数の列を持つ主キー、または単一の列に整数型以外の型を持つ主キーに適用されます。主キーが単一の列に整数型を持つ場合、またはテーブルに主キーがない場合、データはクラスター化インデックスの影響を受けず、以前と同じ方法で並べ替えられます。 @@ -158,15 +158,15 @@ TiDBのスケジューリングプロセスは、I/O、ネットワーク、CPU ## バックアップと復元 {#backup-and-restore} -- バックアップ＆リストアツール（BR）は、AWS S3とGoogle Cloud GCSへのデータのバックアップをサポートしています。（ [ユーザードキュメント](/br/backup-and-restore-storages.md) ） -- バックアップ＆リストアツール(BR)は、AWS S3およびGoogle Cloud GCSからTiDBへのデータの復元をサポートしています。( [ユーザードキュメント](/br/backup-and-restore-storages.md) ) +- バックアップ＆リストアツール（BR）は、AWS S3とGoogle Cloud GCSへのデータのバックアップをサポートしています。（ [ユーザードキュメント](/br/backup-and-restore-ストレージs.md) ） +- バックアップ＆リストアツール(BR)は、AWS S3およびGoogle Cloud GCSからTiDBへのデータの復元をサポートしています。( [ユーザードキュメント](/br/backup-and-restore-ストレージs.md) ) - 関連号: [＃89](https://github.com/pingcap/br/issues/89) ## データのインポートとエクスポート {#data-import-and-export} -- TiDB Lightning は、 AWS S3storageから TiDB へのAuroraスナップショットデータのインポートをサポートしています。(関連問題: [＃266](https://github.com/pingcap/tidb-lightning/issues/266) ) +- TiDB Lightning は、 AWS S3ストレージから TiDB へのAuroraスナップショットデータのインポートをサポートしています。(関連問題: [＃266](https://github.com/pingcap/tidb-lightning/issues/266) ) - 1 TiB のデータを DBaaS T1.standard にインポートする TPC-C テストでは、パフォーマンスが 254 GiB/時間から 366 GiB/時間へと 40% 向上しました。 -- Dumpling は、TiDB/MySQL から AWS S3storageへのデータのエクスポートをサポートしています (実験的) (関連する問題: [＃8](https://github.com/pingcap/dumpling/issues/8) 、 [ユーザードキュメント](/dumpling-overview.md#export-data-to-amazon-s3-cloud-storage) ) +- Dumpling は、TiDB/MySQL から AWS S3ストレージへのデータのエクスポートをサポートしています (実験的) (関連する問題: [＃8](https://github.com/pingcap/dumpling/issues/8) 、 [ユーザードキュメント](/dumpling-overview.md#export-data-to-amazon-s3-cloud-ストレージ) ) ## 診断 {#diagnostics} diff --git a/releases/release-5.0.0.md b/releases/release-5.0.0.md index f15b83ec3f06d..081dab87d97bc 100644 --- a/releases/release-5.0.0.md +++ b/releases/release-5.0.0.md @@ -1,6 +1,6 @@ --- title: What's New in TiDB 5.0 -summary: TiDB 5.0では、MPPアーキテクチャ、クラスタ化インデックス、非同期コミット、および安定性の向上が導入されています。また、互換性の変更、構成パラメータ、および新機能も強化されています。さらに、パフォーマンス、高可用性、ディザスタリカバリ、データ移行、診断、デプロイ、およびメンテナンスが最適化されています。クラスタの使用状況メトリクス用のテレメトリ機能も追加されています。 +summary: TiDB 5.0では、MPPアーキテクチャ、クラスター化インデックス、非同期コミット、および安定性の向上が導入されています。また、互換性の変更、構成パラメータ、および新機能も強化されています。さらに、パフォーマンス、高可用性、ディザスタリカバリ、データ移行、診断、デプロイ、およびメンテナンスが最適化されています。クラスターの使用状況メトリクス用のテレメトリ機能も追加されています。 --- # TiDB 5.0の新機能 {#what-s-new-in-tidb-5-0} @@ -13,15 +13,15 @@ TiDB バージョン: 5.0.0 バージョン5.0における主な新機能または改善点は以下のとおりです。 -- TiFlashノードを介して大規模並列処理（MPP）アーキテクチャを導入し、大規模な結合クエリの実行ワークロードをTiFlashノード間で共有します。MPPモードが有効になっている場合、TiDBはコストに基づいて、計算を実行するためにMPPフレームワークを使用するかどうかを決定します。MPPモードでは、結合キーは計算中に`Exchange`操作によって再分配され、計算負荷が各TiFlashノードに分散され、計算が高速化されます。ベンチマークによると、同じクラスタリソースを使用した場合、TiDB 5.0 MPPはGreenplum 6.15.0およびApache Spark 3.1.1と比較して2～3倍高速化され、一部のクエリでは8倍のパフォーマンス向上を実現しています。 -- データベースのパフォーマンスを向上させるために、クラスタ化インデックス機能を導入します。例えば、TPC-C tpmCテストでは、クラスタ化インデックスを有効にしたTiDBのパフォーマンスは39%向上しました。 +- TiFlashノードを介して大規模並列処理（MPP）アーキテクチャを導入し、大規模な結合クエリの実行ワークロードをTiFlashノード間で共有します。MPPモードが有効になっている場合、TiDBはコストに基づいて、計算を実行するためにMPPフレームワークを使用するかどうかを決定します。MPPモードでは、結合キーは計算中に`Exchange`操作によって再分配され、計算負荷が各TiFlashノードに分散され、計算が高速化されます。ベンチマークによると、同じクラスターリソースを使用した場合、TiDB 5.0 MPPはGreenplum 6.15.0およびApache Spark 3.1.1と比較して2～3倍高速化され、一部のクエリでは8倍のパフォーマンス向上を実現しています。 +- データベースのパフォーマンスを向上させるために、クラスター化インデックス機能を導入します。例えば、TPC-C tpmCテストでは、クラスター化インデックスを有効にしたTiDBのパフォーマンスは39%向上しました。 - 非同期コミット機能を有効にすると、書き込みレイテンシーを削減できます。例えば、64スレッドのSysbenchテストでは、非同期コミットを有効にした場合、インデックス更新の平均レイテンシーは12.04msから7.01msへと41.7%削減されます。 - ジッターを低減します。これは、オプティマイザの安定性を向上させ、システムタスクによるI/O、ネットワーク、CPU、メモリリソースの使用を制限することによって実現されます。例えば、8時間のパフォーマンステストでは、TPC-C tpmCの標準偏差は2%を超えません。 - スケジューリングを改善し、実行計画を可能な限り安定させることで、システムの安定性を向上させる。 - リージョンメンバーシップの変更時にもシステムの可用性を保証するRaft共同合意アルゴリズムを導入します。 - `EXPLAIN`機能と非表示インデックスを最適化することで、データベース管理者 (DBA) が SQL ステートメントをより効率的にデバッグできるようになります。 -- 企業データの信頼性を保証します。TiDBからAmazon S3storageやGoogle Cloud GCSにデータをバックアップしたり、これらのクラウドstorageプラットフォームからデータを復元したりできます。 -- Amazon S3storageまたはTiDB/MySQLへのデータインポートおよびデータエクスポートのパフォーマンスが向上し、企業がクラウド上でアプリケーションを迅速に構築できるようになります。例えば、TPC-Cテストでは、1 TiBのデータをインポートする際のパフォーマンスが40%向上し、254 GiB/hから366 GiB/hになりました。 +- 企業データの信頼性を保証します。TiDBからAmazon S3ストレージやGoogle Cloud GCSにデータをバックアップしたり、これらのクラウドストレージプラットフォームからデータを復元したりできます。 +- Amazon S3ストレージまたはTiDB/MySQLへのデータインポートおよびデータエクスポートのパフォーマンスが向上し、企業がクラウド上でアプリケーションを迅速に構築できるようになります。例えば、TPC-Cテストでは、1 TiBのデータをインポートする際のパフォーマンスが40%向上し、254 GiB/hから366 GiB/hになりました。 ## 互換性の変更 {#compatibility-changes} @@ -57,12 +57,12 @@ TiDB バージョン: 5.0.0 - `OFF` : クラスター化インデックスは無効になっています。非クラスター化インデックスの追加または削除はサポートされています。 - - `INT_ONLY` : デフォルト値。動作はv5.0以前と同じです。 `alter-primary-key = false`と併せて、INT型のクラスタ化インデックスを有効にするかどうかを制御できます。 + - `INT_ONLY` : デフォルト値。動作はv5.0以前と同じです。 `alter-primary-key = false`と併せて、INT型のクラスター化インデックスを有効にするかどうかを制御できます。 > **注記：** > > 5.0 GA の`INT_ONLY`の`tidb_enable_clustered_index`値は、5.0 RC の`OFF`値と同じ意味です。 `OFF`設定の 5.0 RC クラスターから 5.0 GA にアップグレードすると、 `INT_ONLY`と表示されます。 -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} - TiDB の[`index-limit`](/tidb-configuration-file.md#index-limit-new-in-v50)設定項目を追加します。デフォルト値は`64`で、範囲は`[64,512]`です。MySQL テーブルは最大 64 個のインデックスをサポートします。この値がデフォルト設定を超え、テーブルに 64 個を超えるインデックスが作成された場合、テーブル スキーマが MySQL に再インポートされるとエラーが報告されます。 - TiDB が MySQL の ENUM/SET の長さ (ENUM の長さ < 255) と互換性があり、一貫性を保つように、 [`enable-enum-length-limit`](/tidb-configuration-file.md#enable-enum-length-limit-new-in-v50)設定項目を追加します。デフォルト値は`true`です。 @@ -164,9 +164,9 @@ TiDBは出力ログ情報の非機密化をサポートしています。この TiDBは、 TiFlashノードを通じてMPPアーキテクチャを導入しています。このアーキテクチャにより、複数のTiFlashノードが大規模な結合クエリの実行ワークロードを共有することが可能になります。 -MPPモードが有効な場合、TiDBは計算コストに基づいて、クエリをMPPエンジンに送信して計算を行うかどうかを判断します。MPPモードでは、TiDBはデータ計算中に結合キーを再分配することで（ `Exchange`操作）、テーブル結合の計算を各実行中のTiFlashノードに分散し、計算を高速化します。さらに、 TiFlashが既にサポートしている集計計算機能により、TiDBはクエリの計算をTiFlash MPPクラスタにプッシュダウンできます。これにより、分散環境が実行プロセス全体を高速化し、分析クエリの速度を大幅に向上させることができます。 +MPPモードが有効な場合、TiDBは計算コストに基づいて、クエリをMPPエンジンに送信して計算を行うかどうかを判断します。MPPモードでは、TiDBはデータ計算中に結合キーを再分配することで（ `Exchange`操作）、テーブル結合の計算を各実行中のTiFlashノードに分散し、計算を高速化します。さらに、 TiFlashが既にサポートしている集計計算機能により、TiDBはクエリの計算をTiFlash MPPクラスターにプッシュダウンできます。これにより、分散環境が実行プロセス全体を高速化し、分析クエリの速度を大幅に向上させることができます。 -TPC-H 100ベンチマークテストにおいて、 TiFlash MPPは従来の分析データベースやHadoop上のSQLの分析エンジンに比べて大幅な処理速度向上を実現しています。このアーキテクチャにより、最新のトランザクションデータに対して大規模な分析クエリを直接実行でき、従来のオフライン分析ソリューションよりも高いパフォーマンスを発揮します。ベンチマークによると、同じクラスタリソースを使用した場合、TiDB 5.0 MPPはGreenplum 6.15.0およびApache Spark 3.1.1に比べて2～3倍の高速化を実現し、一部のクエリでは8倍のパフォーマンス向上を達成しています。 +TPC-H 100ベンチマークテストにおいて、 TiFlash MPPは従来の分析データベースやHadoop上のSQLの分析エンジンに比べて大幅な処理速度向上を実現しています。このアーキテクチャにより、最新のトランザクションデータに対して大規模な分析クエリを直接実行でき、従来のオフライン分析ソリューションよりも高いパフォーマンスを発揮します。ベンチマークによると、同じクラスターリソースを使用した場合、TiDB 5.0 MPPはGreenplum 6.15.0およびApache Spark 3.1.1に比べて2～3倍の高速化を実現し、一部のクエリでは8倍のパフォーマンス向上を達成しています。 現在、MPP モードがサポートしていない主な機能は次のとおりです (詳細については、 [TiFlashを使用する](/tiflash/use-tiflash-mpp-mode.md)を参照してください)。 @@ -183,23 +183,23 @@ TPC-H 100ベンチマークテストにおいて、 TiFlash MPPは従来の分 [ユーザー向けドキュメント](/clustered-indexes.md)、 [#4841](https://github.com/pingcap/tidb/issues/4841) -テーブル構造を設計したり、データベースの動作を分析したりする際に、主キーを持つ一部の列が頻繁にグループ化およびソートされ、これらの列に対するクエリが特定の範囲のデータまたは異なる値を持つ少量のデータを頻繁に返し、対応するデータが読み取りまたは書き込みのホットスポット問題を引き起こさないことがわかった場合は、クラスタ化インデックス機能を使用することをお勧めします。 +テーブル構造を設計したり、データベースの動作を分析したりする際に、主キーを持つ一部の列が頻繁にグループ化およびソートされ、これらの列に対するクエリが特定の範囲のデータまたは異なる値を持つ少量のデータを頻繁に返し、対応するデータが読み取りまたは書き込みのホットスポット問題を引き起こさないことがわかった場合は、クラスター化インデックス機能を使用することをお勧めします。 -クラスタ化インデックスは、テーブルのデータに関連付けられたstorage構造です。一部のデータベース管理システムでは、クラスタ化インデックステーブルを*インデックス構成テーブル*と呼びます。クラスタ化インデックスを作成する際には、テーブルの1つ以上の列をインデックスのキーとして指定できます。TiDBはこれらのキーを特定の構造に格納するため、キーに関連付けられた行を迅速かつ効率的に検索でき、クエリとデータ書き込みのパフォーマンスが向上します。 +クラスター化インデックスは、テーブルのデータに関連付けられたストレージ構造です。一部のデータベース管理システムでは、クラスター化インデックステーブルを*インデックス構成テーブル*と呼びます。クラスター化インデックスを作成する際には、テーブルの1つ以上の列をインデックスのキーとして指定できます。TiDBはこれらのキーを特定の構造に格納するため、キーに関連付けられた行を迅速かつ効率的に検索でき、クエリとデータ書き込みのパフォーマンスが向上します。 -クラスタ化インデックス機能を有効にすると、TiDB のパフォーマンスは大幅に向上します (例えば、TPC-C tpmC テストでは、クラスタ化インデックスを有効にした TiDB のパフォーマンスは、以下のケースで 39% 向上します)。 +クラスター化インデックス機能を有効にすると、TiDB のパフォーマンスは大幅に向上します (例えば、TPC-C tpmC テストでは、クラスター化インデックスを有効にした TiDB のパフォーマンスは、以下のケースで 39% 向上します)。 -- データが挿入される際、クラスタ化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 -- 同等の条件を持つクエリが主キーのみに関係する場合、クラスタ化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 -- 範囲条件を含むクエリが主キーのみに関係する場合、クラスタ化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 -- 同等条件または範囲条件を含むクエリに主キーのプレフィックスが含まれる場合、クラスタ化インデックスによってネットワークからのインデックスデータの読み取り回数が削減されます。 +- データが挿入される際、クラスター化インデックスによって、ネットワークからのインデックスデータの書き込み回数が1回削減されます。 +- 同等の条件を持つクエリが主キーのみに関係する場合、クラスター化インデックスによってネットワークからのインデックスデータの読み取り回数が1回削減されます。 +- 範囲条件を含むクエリが主キーのみに関係する場合、クラスター化インデックスはネットワークからのインデックスデータの読み取り回数を削減します。 +- 同等条件または範囲条件を含むクエリに主キーのプレフィックスが含まれる場合、クラスター化インデックスによってネットワークからのインデックスデータの読み取り回数が削減されます。 -各テーブルは、クラスタ化インデックスまたは非クラスタ化インデックスのいずれかを使用してデータをソートおよび格納できます。これら2つのstorage構造の違いは次のとおりです。 +各テーブルは、クラスター化インデックスまたは非クラスター化インデックスのいずれかを使用してデータをソートおよび格納できます。これら2つのストレージ構造の違いは次のとおりです。 - クラスター化インデックスを作成する際、テーブル内の1つまたは複数の列をインデックスのキー値として指定できます。クラスター化インデックスは、キー値に基づいてテーブルのデータをソートして格納します。各テーブルには、クラスター化インデックスを1つだけ設定できます。テーブルにクラスター化インデックスがある場合、そのテーブルはクラスター化インデックステーブルと呼ばれます。そうでない場合は、非クラスター化インデックステーブルと呼ばれます。 -- 非クラスタ化インデックスを作成すると、テーブル内のデータは順不同構造で格納されます。TiDBは各データ行に一意のROWIDを自動的に割り当てるため、非クラスタ化インデックスのキー値を明示的に指定する必要はありません。クエリ実行時には、ROWIDを使用して対応する行が特定されます。データのクエリまたは挿入時には少なくとも2回のネットワークI/O操作が発生するため、クラスタ化インデックスと比較してパフォーマンスが低下します。 +- 非クラスター化インデックスを作成すると、テーブル内のデータは順不同構造で格納されます。TiDBは各データ行に一意のROWIDを自動的に割り当てるため、非クラスター化インデックスのキー値を明示的に指定する必要はありません。クエリ実行時には、ROWIDを使用して対応する行が特定されます。データのクエリまたは挿入時には少なくとも2回のネットワークI/O操作が発生するため、クラスター化インデックスと比較してパフォーマンスが低下します。 -テーブルデータが変更されると、データベースシステムはクラスタ化インデックスと非クラスタ化インデックスを自動的に維持します。 +テーブルデータが変更されると、データベースシステムはクラスター化インデックスと非クラスター化インデックスを自動的に維持します。 デフォルトでは、すべての主キーは非クラスター化インデックスとして作成されます。主キーをクラスター化インデックスまたは非クラスター化インデックスとして作成するには、次の 2 つの方法のいずれかを使用できます。 @@ -215,29 +215,29 @@ CREATE TABLE `t` (`a` VARCHAR(255), `b` INT, PRIMARY KEY (`a`, `b`) CLUSTERED); CREATE TABLE `t` (`a` VARCHAR(255) PRIMARY KEY CLUSTERED, `b` INT); ``` -テーブルにクラスタ化インデックスがあるかどうかを照会するには`SHOW INDEX FROM tbl-name`というステートメントを実行します。 +テーブルにクラスター化インデックスがあるかどうかを照会するには`SHOW INDEX FROM tbl-name`というステートメントを実行します。 -- クラスタ化インデックス機能を制御するには、システム変数`tidb_enable_clustered_index`を設定します。サポートされている値は、 `ON` 、 `OFF` 、および`INT_ONLY` 。 - - `ON` : すべてのタイプの主キーに対してクラスタ化インデックス機能が有効になっていることを示します。非クラスタ化インデックスの追加と削除がサポートされています。 - - `OFF` : すべてのタイプの主キーに対して、クラスタ化インデックス機能が無効になっていることを示します。非クラスタ化インデックスの追加と削除はサポートされています。 - - `INT_ONLY` : デフォルト値。変数が`INT_ONLY`に設定され、 `alter-primary-key`が`false`に設定されている場合、単一の整数列で構成される主キーは、デフォルトでクラスタ化インデックスとして作成されます。この動作は、TiDB v5.0 およびそれ以前のバージョンと同様です。 +- クラスター化インデックス機能を制御するには、システム変数`tidb_enable_clustered_index`を設定します。サポートされている値は、 `ON` 、 `OFF` 、および`INT_ONLY` 。 + - `ON` : すべてのタイプの主キーに対してクラスター化インデックス機能が有効になっていることを示します。非クラスター化インデックスの追加と削除がサポートされています。 + - `OFF` : すべてのタイプの主キーに対して、クラスター化インデックス機能が無効になっていることを示します。非クラスター化インデックスの追加と削除はサポートされています。 + - `INT_ONLY` : デフォルト値。変数が`INT_ONLY`に設定され、 `alter-primary-key`が`false`に設定されている場合、単一の整数列で構成される主キーは、デフォルトでクラスター化インデックスとして作成されます。この動作は、TiDB v5.0 およびそれ以前のバージョンと同様です。 `CREATE TABLE`ステートメントにキーワード`CLUSTERED | NONCLUSTERED`が含まれている場合、そのステートメントはシステム変数と構成項目の設定を上書きします。 -ステートメントでキーワード`CLUSTERED | NONCLUSTERED`指定して、クラスタ化インデックス機能を使用することをお勧めします。この方法により、TiDB は必要に応じてシステム内のクラスタ化インデックスと非クラスタ化インデックスのすべてのデータ型を同時に使用できるようになり、より柔軟に対応できます。 +ステートメントでキーワード`CLUSTERED | NONCLUSTERED`指定して、クラスター化インデックス機能を使用することをお勧めします。この方法により、TiDB は必要に応じてシステム内のクラスター化インデックスと非クラスター化インデックスのすべてのデータ型を同時に使用できるようになり、より柔軟に対応できます。 `tidb_enable_clustered_index = INT_ONLY`の使用は推奨されません。 `INT_ONLY`は、この機能の互換性を確保するために一時的に使用されており、将来的に廃止される予定です。 -クラスタ化インデックスの制限事項は以下のとおりです。 +クラスター化インデックスの制限事項は以下のとおりです。 -- クラスタ化インデックスと非クラスタ化インデックス間の相互変換はサポートされていません。 +- クラスター化インデックスと非クラスター化インデックス間の相互変換はサポートされていません。 - クラスター化インデックスの削除はサポートされていません。 -- `ALTER TABLE`ステートメントを使用したクラスタ化インデックスの追加、削除、および変更はサポートされていません。 -- クラスタ化インデックスの再編成および再作成はサポートされていません。 -- インデックスの有効化または無効化はサポートされていないため、非表示インデックス機能はクラスタ化インデックスには適用されません。 -- `UNIQUE KEY`をクラスタ化インデックスとして作成することはサポートされていません。 -- TiDB Binlogとクラスタ化インデックス機能を併用することはサポートされていません。TiDB Binlog を有効にすると、TiDB は単一の整数プライマリキーのみをクラスタ化インデックスとして作成することをサポートします。TiDB Binlog は、クラスタ化インデックスを持つ既存のテーブルのデータ変更をダウンストリームにレプリケートしません。 -- クラスタ化インデックス機能を属性`SHARD_ROW_ID_BITS`および`PRE_SPLIT_REGIONS`と併用することはサポートされていません。 +- `ALTER TABLE`ステートメントを使用したクラスター化インデックスの追加、削除、および変更はサポートされていません。 +- クラスター化インデックスの再編成および再作成はサポートされていません。 +- インデックスの有効化または無効化はサポートされていないため、非表示インデックス機能はクラスター化インデックスには適用されません。 +- `UNIQUE KEY`をクラスター化インデックスとして作成することはサポートされていません。 +- TiDB Binlogとクラスター化インデックス機能を併用することはサポートされていません。TiDB Binlog を有効にすると、TiDB は単一の整数プライマリキーのみをクラスター化インデックスとして作成することをサポートします。TiDB Binlog は、クラスター化インデックスを持つ既存のテーブルのデータ変更をダウンストリームにレプリケートしません。 +- クラスター化インデックス機能を属性`SHARD_ROW_ID_BITS`および`PRE_SPLIT_REGIONS`と併用することはサポートされていません。 - クラスターを新しいバージョンにアップグレードした後、ロールバックした場合、ロールバック前にテーブルデータをエクスポートし、ロールバック後にデータをインポートすることで、新しく追加されたテーブルをダウングレードする必要があります。その他のテーブルは影響を受けません。 ### 非同期コミット {#async-commit} @@ -324,7 +324,7 @@ GC の CPU および I/O リソースの消費を削減するために、GC コ この機能はデフォルトでは無効になっています。 `bg_task_io_rate_limit`設定項目を変更することで、この機能を有効にできます。 -#### 大規模クラスタにおけるスケジューリング制約のチェック性能と、異常リージョンの修復性能を向上させる。 {#improve-the-performance-of-checking-scheduling-constraints-and-the-performance-of-fixing-the-unhealthy-regions-in-a-large-cluster} +#### 大規模クラスターにおけるスケジューリング制約のチェック性能と、異常リージョンの修復性能を向上させる。 {#improve-the-performance-of-checking-scheduling-constraints-and-the-performance-of-fixing-the-unhealthy-regions-in-a-large-cluster} ### パフォーマンスの変動を避けるため、実行計画はできる限り変更しないようにしてください。 {#ensure-that-the-execution-plans-are-unchanged-as-much-as-possible-to-avoid-performance-jitter} @@ -385,11 +385,11 @@ Unified Sorterは、以前のバージョンの`memory` / `file`ソートエン ### S3/ AuroraからTiDBへデータを移行する {#migrate-data-from-s3-aurora-to-tidb} -TiDBのデータ移行ツールは、データ移行の中間段階としてAmazon S3（およびその他のS3互換storageサービス）を使用し、 AuroraスナップショットデータをTiDBに直接初期化することをサポートしており、Amazon S3/ AuroraからTiDBへのデータ移行に関するより多くの選択肢を提供します。 +TiDBのデータ移行ツールは、データ移行の中間段階としてAmazon S3（およびその他のS3互換ストレージサービス）を使用し、 AuroraスナップショットデータをTiDBに直接初期化することをサポートしており、Amazon S3/ AuroraからTiDBへのデータ移行に関するより多くの選択肢を提供します。 この機能を使用するには、以下のドキュメントを参照してください。 -- [データをAmazon S3クラウドstorageにエクスポートする](/dumpling-overview.md#export-data-to-amazon-s3-cloud-storage)、 [#8](https://github.com/pingcap/dumpling/issues/8) +- [データをAmazon S3クラウドストレージにエクスポートする](/dumpling-overview.md#export-data-to-amazon-s3-cloud-ストレージ)、 [#8](https://github.com/pingcap/dumpling/issues/8) - [TiDB Lightningを使用してAmazon Aurora MySQLから移行する](/migrate-aurora-to-tidb.md)、 [#266](https://github.com/pingcap/tidb-lightning/issues/266) ### TiDB Cloudのデータインポートパフォーマンスを最適化する {#optimize-the-data-import-performance-of-tidb-cloud} @@ -421,22 +421,22 @@ TiDB v5.0では、パフォーマンスの問題をより効率的にトラブ ## 導入と保守 {#deployment-and-maintenance} -### クラスタ展開操作のロジックを最適化し、DBAが標準的なTiDB本番クラスタをより迅速に展開できるようにします。 {#optimize-the-logic-of-cluster-deployment-operations-to-help-dbas-deploy-a-set-of-standard-tidb-production-cluster-faster} +### クラスター展開操作のロジックを最適化し、DBAが標準的なTiDB本番クラスターをより迅速に展開できるようにします。 {#optimize-the-logic-of-cluster-deployment-operations-to-help-dbas-deploy-a-set-of-standard-tidb-production-cluster-faster} [ユーザー向けドキュメント](/production-deployment-using-tiup.md) -以前のTiDBバージョンでは、 TiUPを使用してTiDBクラスタをデプロイするDBAは、環境初期化が複雑で、チェックサム構成が過剰であり、クラスタトポロジーファイルの編集が困難であるという問題に直面していました。これらの問題はすべて、DBAのデプロイ効率の低下につながっていました。TiDB v5.0では、以下の項目により、 TiUPを使用したTiDBデプロイの効率がDBA向けに改善されています。 +以前のTiDBバージョンでは、 TiUPを使用してTiDBクラスターをデプロイするDBAは、環境初期化が複雑で、チェックサム構成が過剰であり、クラスタートポロジーファイルの編集が困難であるという問題に直面していました。これらの問題はすべて、DBAのデプロイ効率の低下につながっていました。TiDB v5.0では、以下の項目により、 TiUPを使用したTiDBデプロイの効率がDBA向けに改善されています。 -- TiUP クラスタは、より包括的なワンクリック環境チェックを実行し、修復に関する推奨事項を提供する`check topo.yaml`コマンドをサポートしています。 -- TiUP クラスタは、環境チェック中に検出された環境問題を自動的に修復する`check topo.yaml --apply`コマンドをサポートしています。 -- TiUP クラスタ は、DBA が編集するためのクラスタ トポロジ テンプレート ファイルを取得し、グローバル ノード パラメータの変更をサポートする`template`コマンドをサポートしています。 +- TiUP クラスターは、より包括的なワンクリック環境チェックを実行し、修復に関する推奨事項を提供する`check topo.yaml`コマンドをサポートしています。 +- TiUP クラスターは、環境チェック中に検出された環境問題を自動的に修復する`check topo.yaml --apply`コマンドをサポートしています。 +- TiUP クラスター は、DBA が編集するためのクラスター トポロジ テンプレート ファイルを取得し、グローバル ノード パラメータの変更をサポートする`template`コマンドをサポートしています。 - TiUPは`remote_config`コマンドを使用して`edit-config`パラメータを編集し、リモートPrometheusを設定することをサポートしています。 - TiUPは`external_alertmanagers`コマンドを使用して異なるAlertManagerを設定するために、 `edit-config`パラメーターの編集をサポートしています。 - tiup-clusterの`edit-config`サブコマンドを使用してトポロジ ファイルを編集する場合、構成項目の値のデータ型を変更できます。 ### アップグレードの安定性を向上させる {#improve-upgrade-stability} -TiUP v1.4.0より前は、 tiup-clusterを使用してTiDBクラスタをアップグレードする際に、クラスタのSQL応答が長時間ジッターし、PDオンラインローリングアップグレード中にクラスタのQPSが10秒から30秒の間でジッターしていました。 +TiUP v1.4.0より前は、 tiup-clusterを使用してTiDBクラスターをアップグレードする際に、クラスターのSQL応答が長時間ジッターし、PDオンラインローリングアップグレード中にクラスターのQPSが10秒から30秒の間でジッターしていました。 TiUP v1.4.0では、ロジックを調整し、以下の最適化を行いました。 @@ -445,7 +445,7 @@ TiUP v1.4.0では、ロジックを調整し、以下の最適化を行いまし ### アップグレード時間を最適化する {#optimize-the-upgrade-time} -TiUP v1.4.0より前は、DBAがtiup-clusterを使用してTiDBクラスタをアップグレードする場合、ノード数が多いクラスタでは、アップグレードにかかる合計時間が長く、一部のユーザーのアップグレード時間枠の要件を満たせないことがありました。 +TiUP v1.4.0より前は、DBAがtiup-clusterを使用してTiDBクラスターをアップグレードする場合、ノード数が多いクラスターでは、アップグレードにかかる合計時間が長く、一部のユーザーのアップグレード時間枠の要件を満たせないことがありました。 バージョン1.4.0以降、 TiUPは以下の項目を最適化します。 @@ -455,21 +455,21 @@ TiUP v1.4.0より前は、DBAがtiup-clusterを使用してTiDBクラスタを ### ブレークポイント機能をサポートする {#support-the-breakpoint-feature} -TiUP v1.4.0より前のバージョンでは、DBAがtiup-clusterを使用してTiDBクラスタをアップグレードする際に、コマンドの実行が中断された場合、すべてのアップグレード操作を最初からやり直す必要がありました。 +TiUP v1.4.0より前のバージョンでは、DBAがtiup-clusterを使用してTiDBクラスターをアップグレードする際に、コマンドの実行が中断された場合、すべてのアップグレード操作を最初からやり直す必要がありました。 TiUP v1.4.0 では、 tiup-cluster `replay`サブコマンドを使用して、ブレークポイントから失敗した操作を再試行することがサポートされており、アップグレードの中断後にすべての操作を再実行する必要がなくなります。 ### 保守および運用機能を強化する {#enhance-the-functionalities-of-maintenance-and-operations} -TiUP v1.4.0では、TiDBクラスタの運用と保守に関する機能がさらに強化されています。 +TiUP v1.4.0では、TiDBクラスターの運用と保守に関する機能がさらに強化されています。 -- TiDBおよびDMクラスタのダウンタイム中のアップグレードまたはパッチ適用操作をサポートし、より多くの利用シナリオに対応できるようにします。 -- tiup-clusterの`--version`サブコマンドに`display`パラメータを追加して、クラスタバージョンを取得します。 +- TiDBおよびDMクラスターのダウンタイム中のアップグレードまたはパッチ適用操作をサポートし、より多くの利用シナリオに対応できるようにします。 +- tiup-clusterの`--version`サブコマンドに`display`パラメータを追加して、クラスターバージョンを取得します。 - スケールアウト対象のノードにPrometheusのみが含まれている場合、Prometheusノードの不在によるスケールアウトの失敗を回避するため、監視設定の更新操作は実行されません。 - TiUPコマンドの入力結果が正しくない場合に、エラーメッセージにユーザー入力を追加することで、問題の原因をより迅速に特定できるようにします。 ## テレメトリー {#telemetry} -TiDBは、データテーブルの数、クエリの数、新機能が有効になっているかどうかなど、クラスタの使用状況に関するメトリクスをテレメトリに追加します。 +TiDBは、データテーブルの数、クエリの数、新機能が有効になっているかどうかなど、クラスターの使用状況に関するメトリクスをテレメトリに追加します。 詳細およびこの動作を無効にする方法については、[テレメトリー](/telemetry.md)を参照してください。 diff --git a/releases/release-5.0.1.md b/releases/release-5.0.1.md index 1d5e60970f4bd..52436930bd31b 100644 --- a/releases/release-5.0.1.md +++ b/releases/release-5.0.1.md @@ -42,7 +42,7 @@ TiDB バージョン: 5.0.1 - 列に`NULL`値が含まれている場合に間違ったクエリ結果が表示される問題を修正しました[＃24063](https://github.com/pingcap/tidb/pull/24063) - スキャンに仮想列[＃24058](https://github.com/pingcap/tidb/pull/24058)が含まれている場合、MPP プランの生成を禁止します。 - プランキャッシュ[＃24043](https://github.com/pingcap/tidb/pull/24043)の`PointGet`と`TableDual`の誤った再利用を修正 - - オプティマイザがクラスタ化インデックス[＃24042](https://github.com/pingcap/tidb/pull/24042) `IndexMerge`プランを構築するときに発生するエラーを修正します + - オプティマイザがクラスター化インデックス[＃24042](https://github.com/pingcap/tidb/pull/24042) `IndexMerge`プランを構築するときに発生するエラーを修正します - BIT型エラーの型推論を修正[＃24027](https://github.com/pingcap/tidb/pull/24027) - `PointGet`演算子が存在する場合に一部のオプティマイザヒントが有効にならない問題を修正[＃23685](https://github.com/pingcap/tidb/pull/23685) - エラー[＃24080](https://github.com/pingcap/tidb/pull/24080)によりロールバック時にDDL操作が失敗する可能性がある問題を修正 @@ -62,7 +62,7 @@ TiDB バージョン: 5.0.1 - TiFlash - - storageエンジンが一部の範囲のデータの削除に失敗する問題を修正しました + - ストレージエンジンが一部の範囲のデータの削除に失敗する問題を修正しました - 時間型を整数型にキャストしたときに誤った結果が返される問題を修正しました - `receiver`秒以内に対応するタスクが見つからないバグを修正 - `cancelMPPQuery`に無効なイテレータが存在する可能性がある問題を修正 diff --git a/releases/release-5.0.2.md b/releases/release-5.0.2.md index 6572c8bdbabe6..9fa7cdd378b4d 100644 --- a/releases/release-5.0.2.md +++ b/releases/release-5.0.2.md @@ -31,7 +31,7 @@ TiDB バージョン: 5.0.2 - TiKV - - BRは、仮想ホストアドレス指定モード[＃10243](https://github.com/tikv/tikv/pull/10243)を使用してS3互換storageをサポートするようになりました。 + - BRは、仮想ホストアドレス指定モード[＃10243](https://github.com/tikv/tikv/pull/10243)を使用してS3互換ストレージをサポートするようになりました。 - TiCDCのスキャン速度[＃10151](https://github.com/tikv/tikv/pull/10151)バックプレッシャーをサポート - TiCDCの初期スキャン[＃10133](https://github.com/tikv/tikv/pull/10133)のメモリ使用量を削減 - 悲観的トランザクション[＃10089](https://github.com/tikv/tikv/pull/10089)におけるTiCDCの古い値機能のキャッシュヒット率を改善 @@ -53,7 +53,7 @@ TiDB バージョン: 5.0.2 - バックアップと復元 (BR) - 曖昧なエラーメッセージを明確にする[＃1132](https://github.com/pingcap/br/pull/1132) - - バックアップ[＃1091](https://github.com/pingcap/br/pull/1091)のクラスタ バージョンの確認をサポート + - バックアップ[＃1091](https://github.com/pingcap/br/pull/1091)のクラスター バージョンの確認をサポート - `mysql`スキーマ[＃1143](https://github.com/pingcap/br/pull/1143) [＃1078](https://github.com/pingcap/br/pull/1078)のシステムテーブルのバックアップと復元をサポート - Dumpling diff --git a/releases/release-5.0.4.md b/releases/release-5.0.4.md index 9264828dd4c72..5ebf50197afcc 100644 --- a/releases/release-5.0.4.md +++ b/releases/release-5.0.4.md @@ -83,7 +83,7 @@ TiDB バージョン: 5.0.4 - TiKVコプロセッサのスローログに、リクエスト[＃10841](https://github.com/tikv/tikv/issues/10841)処理に費やされた時間のみを考慮するようにする - 未確定エラーの可能性を減らすために、できるだけべき等な事前書き込みを行う[＃10587](https://github.com/tikv/tikv/pull/10587) - 書き込みフローが低い場合に「GC が動作できません」という誤った警告を回避する[＃10662](https://github.com/tikv/tikv/pull/10662) - - 復元するデータベースが、バックアップ時の元のクラスタサイズと常に一致するようにします[＃10643](https://github.com/tikv/tikv/pull/10643) + - 復元するデータベースが、バックアップ時の元のクラスターサイズと常に一致するようにします[＃10643](https://github.com/tikv/tikv/pull/10643) - panic出力がログ[＃9955](https://github.com/tikv/tikv/pull/9955)にフラッシュされていることを確認する - PD @@ -125,7 +125,7 @@ TiDB バージョン: 5.0.4 - ビューが`DEFINER` [＃24414](https://github.com/pingcap/tidb/issues/24414)をサポートしない問題を修正 - `tidb-server --help`コード`2` [＃24046](https://github.com/pingcap/tidb/issues/24046)で終了する問題を修正 - グローバル変数`dml_batch_size`設定が有効にならない問題を修正[＃24709](https://github.com/pingcap/tidb/issues/24709) - - `read_from_storage`とパーティションテーブルを同時に使用するとエラーが発生する問題を修正[＃20372](https://github.com/pingcap/tidb/issues/20372) + - `read_from_ストレージ`とパーティションテーブルを同時に使用するとエラーが発生する問題を修正[＃20372](https://github.com/pingcap/tidb/issues/20372) - 射影演算子[＃24264](https://github.com/pingcap/tidb/issues/24264)を実行するときに TiDB がパニックを起こす問題を修正しました - 統計情報によりクエリがpanicになる可能性がある問題を修正[＃24061](https://github.com/pingcap/tidb/pull/24061) - `BIT`列で`approx_percentile`関数を使用するとpanic可能性がある問題を修正しました[＃23662](https://github.com/pingcap/tidb/issues/23662) @@ -140,7 +140,7 @@ TiDB バージョン: 5.0.4 - 破損したスナップショットファイルによって引き起こされる潜在的なディスクフル問題を修正[＃10813](https://github.com/tikv/tikv/issues/10813) - Titan が有効になっている 5.0 より前のバージョンからアップグレードするときに発生する TiKVpanic問題を修正しました[＃10843](https://github.com/tikv/tikv/pull/10843) - 新しいバージョンのTiKVをv5.0.xにロールバックできない問題を修正しました[＃10843](https://github.com/tikv/tikv/pull/10843) - - 5.0より前のバージョンから5.0以降のバージョンにアップグレードする際に発生するTiKVpanicの問題を修正しました。アップグレード前にTitanが有効になっているTiKV v3.xからクラスタをアップグレードした場合、このクラスタでこの問題が発生する可能性があります[＃10774](https://github.com/tikv/tikv/issues/10774) + - 5.0より前のバージョンから5.0以降のバージョンにアップグレードする際に発生するTiKVpanicの問題を修正しました。アップグレード前にTitanが有効になっているTiKV v3.xからクラスターをアップグレードした場合、このクラスターでこの問題が発生する可能性があります[＃10774](https://github.com/tikv/tikv/issues/10774) - 左悲観的ロックによる解析エラーを修正[＃26404](https://github.com/pingcap/tidb/issues/26404) - 特定のプラットフォームで期間を計算するときに発生するpanicを修正[＃10571](https://github.com/tikv/tikv/pull/10571) - Load Base Split の`batch_get_command`のキーがエンコードされていない問題を修正[＃10542](https://github.com/tikv/tikv/issues/10542) diff --git a/releases/release-5.1.0.md b/releases/release-5.1.0.md index 2905f7f7ed3a2..191b53b06194c 100644 --- a/releases/release-5.1.0.md +++ b/releases/release-5.1.0.md @@ -36,9 +36,9 @@ TiDB バージョン: 5.1.0 | [`tidb_enforce_mpp`](/system-variables.md#tidb_enforce_mpp-new-in-v51) | 新しく追加された | オプティマイザのコスト見積もりを無視し、クエリ実行に強制的に MPP モードを使用するかどうかを制御します。この変数のデータ型は`BOOL`で、デフォルト値は`false`です。 | | [`tidb_partition_prune_mode`](/system-variables.md#tidb_partition_prune_mode-new-in-v51) | 新しく追加された | パーティションテーブルの動的プルーニングモードを有効にするかどうかを指定します。この機能は実験的です。この変数のデフォルト値は`static`であり、これはパーティションテーブルの動的プルーニングモードがデフォルトで無効になっていることを意味します。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションアイテム | 種類を変更する | 説明 | +| 設定ファイル | 設定アイテム | 種類を変更する | 説明 | | :------------- | :------------------------------------------------------------------------------------------------------- | :------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB設定ファイル | [`security.enable-sem`](/tidb-configuration-file.md#enable-sem) | 新しく追加された | Security拡張モード（SEM）を有効にするかどうかを制御します。この設定項目のデフォルト値は`false`で、これはSEMが無効になっていることを意味します。 | | TiDB設定ファイル | `performance.committer-concurrency` | 修正済み | 単一トランザクションのコミットフェーズにおけるコミット操作に関連するリクエストの同時実行数を制御します。デフォルト値は`16`から`128`に変更されます。 | @@ -52,7 +52,7 @@ TiDB バージョン: 5.1.0 | TiKV設定ファイル | [`incremental-scan-threads`](/tikv-configuration-file.md#incremental-scan-threads) | 新しく追加された | 履歴データを増分的にスキャンするタスクのスレッド数を設定します。デフォルト値は`4`で、これはタスクに4つのスレッドが使用されることを意味します。 | | TiKV設定ファイル | [`incremental-scan-concurrency`](/tikv-configuration-file.md#incremental-scan-concurrency) | 新しく追加された | 履歴データの増分スキャンを行うタスクの同時実行の最大数を設定します。デフォルト値は`6`で、これは最大で 6 つのタスクを同時に実行できることを意味します。 | | TiKV設定ファイル | [`soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 修正済み | 保留中の圧縮バイトのソフトリミット。デフォルト値は`"64GB"`から`"192GB"`に変更されます。 | -| TiKV設定ファイル | [`storage.io-rate-limit`](/tikv-configuration-file.md#storageio-rate-limit) | 新しく追加された | TiKV書き込みのI/Oレートを制御します。 `storage.io-rate-limit.max-bytes-per-sec`のデフォルト値は`"0MB"`です。 | +| TiKV設定ファイル | [`ストレージ.io-rate-limit`](/tikv-configuration-file.md#ストレージio-rate-limit) | 新しく追加された | TiKV書き込みのI/Oレートを制御します。 `ストレージ.io-rate-limit.max-bytes-per-sec`のデフォルト値は`"0MB"`です。 | | TiKV設定ファイル | [`resolved-ts.enable`](/tikv-configuration-file.md#enable) | 新しく追加された | すべてのリージョンリーダーに対して`resolved-ts`を維持するかどうかを決定します。デフォルト値は`true`です。 | | TiKV設定ファイル | [`resolved-ts.advance-ts-interval`](/tikv-configuration-file.md#advance-ts-interval) | 新しく追加された | `resolved-ts`が転送される間隔。デフォルト値は`"1s"`です。この値は動的に変更できます。 | | TiKV設定ファイル | [`resolved-ts.scan-lock-pool-size`](/tikv-configuration-file.md#scan-lock-pool-size) | 新しく追加された | `resolved-ts`を初期化する際に TiKV が MVCC (マルチバージョン同時実行制御) ロックデータをスキャンするために使用するスレッドの数。デフォルト値は`2`です。 | @@ -61,11 +61,11 @@ TiDB バージョン: 5.1.0 - アップグレード前に、TiDB構成の[`feedback-probability`](https://docs-archive.pingcap.com/tidb/v5.1/tidb-configuration-file#feedback-probability)の値を確認してください。値が0でない場合、アップグレード後に「回復可能なゴルーチンでpanicが発生しました」というエラーが発生しますが、このエラーはアップグレード自体には影響しません。 - TiDBのパフォーマンスを向上させるため、TiDBのGoコンパイラバージョンをgo1.13.7からgo1.16.4にアップグレードしてください。TiDB開発者の方は、スムーズなコンパイルを保証するために、Goコンパイラバージョンをアップグレードすることをお勧めします。 -- TiDBローリングアップグレード中は、TiDB Binlogを使用するクラスタでクラスタ化インデックスを持つテーブルを作成しないようにしてください。 +- TiDBローリングアップグレード中は、TiDB Binlogを使用するクラスターでクラスター化インデックスを持つテーブルを作成しないようにしてください。 - TiDB のローリングアップグレード中は`alter table ... modify column`や`alter table ... change column`のようなステートメントを実行しないでください。 -- バージョン5.1以降、各テーブルのTiFlashレプリカを作成する際に、システムテーブルのレプリカを設定する機能はサポートされなくなりました。クラスタをアップグレードする前に、関連するシステムテーブルのレプリカをクリアする必要があります。クリアしないと、アップグレードは失敗します。 +- バージョン5.1以降、各テーブルのTiFlashレプリカを作成する際に、システムテーブルのレプリカを設定する機能はサポートされなくなりました。クラスターをアップグレードする前に、関連するシステムテーブルのレプリカをクリアする必要があります。クリアしないと、アップグレードは失敗します。 - TiCDC の`--sort-dir`コマンドの`cdc cli changefeed`パラメータは非推奨です。代わりに、 `--sort-dir`コマンドで`cdc server` } を設定できます。 [#1795](https://github.com/pingcap/tiflow/pull/1795) -- TiDB 5.1 にアップグレードした後、TiDB が「関数 READ ONLY には noop 実装しかありません」というエラーを返す場合、 [`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)の値を`ON`に設定することで、TiDB がこのエラーを無視するようにできます。これは、MySQL の`read_only`変数が TiDB ではまだ有効になっていないためです (TiDB では「noop」動作です)。したがって、この変数が TiDB で設定されていても、TiDB クラスタにデータを書き込むことができます。 +- TiDB 5.1 にアップグレードした後、TiDB が「関数 READ ONLY には noop 実装しかありません」というエラーを返す場合、 [`tidb_enable_noop_functions`](/system-variables.md#tidb_enable_noop_functions-new-in-v40)の値を`ON`に設定することで、TiDB がこのエラーを無視するようにできます。これは、MySQL の`read_only`変数が TiDB ではまだ有効になっていないためです (TiDB では「noop」動作です)。したがって、この変数が TiDB で設定されていても、TiDB クラスターにデータを書き込むことができます。 ## 新機能 {#new-features} @@ -135,7 +135,7 @@ TiDB バージョン: 5.1.0 ### パフォーマンス {#performance} -- データレプリカの古い読み取り（Experimental） +- データレプリカのステイル読み取り（Experimental） ローカルレプリカのデータを直接読み込むことで、読み取りレイテンシーを削減し、クエリパフォーマンスを向上させます。 @@ -161,7 +161,7 @@ TiDB バージョン: 5.1.0 - ネットワークが不安定な場合のレプリケーションの中断 - TiKV/PD/TiCDCノードの一部がダウンした場合のレプリケーションの中断 -- TiFlashstorageメモリ制御 +- TiFlashストレージメモリ制御 リージョンスナップショット生成の速度とメモリ使用量を最適化し、メモリ不足（OOM）の可能性を低減します。 @@ -169,13 +169,13 @@ TiDB バージョン: 5.1.0 読み取りおよび書き込み要求の継続時間の安定性を確保するため、TiKV 書き込みレートリミッターは、GC や圧縮などの TiKV バックグラウンドタスクの書き込みトラフィックを平滑化します。TiKV バックグラウンドタスク書き込みレートリミッターのデフォルト値は「0MB」です。この値は、クラウドディスクメーカーが指定する最大 I/O 帯域幅など、ディスクの最適な I/O 帯域幅に設定することをお勧めします。 - [ユーザー向けドキュメント](/tikv-configuration-file.md#storageio-rate-limit)、 [#9156](https://github.com/tikv/tikv/issues/9156) + [ユーザー向けドキュメント](/tikv-configuration-file.md#ストレージio-rate-limit)、 [#9156](https://github.com/tikv/tikv/issues/9156) - 複数のスケーリングタスクが同時に実行される際のスケジューリングの安定性の問題を解決する ### テレメトリー {#telemetry} -TiDBは、実行ステータスと失敗ステータスを含む、TiDBクラスタリクエストの実行ステータスをテレメトリに追加します。 +TiDBは、実行ステータスと失敗ステータスを含む、TiDBクラスターリクエストの実行ステータスをテレメトリに追加します。 この情報の詳細と、この動作を無効にする方法については、[テレメトリー](/telemetry.md)を参照してください。 @@ -194,7 +194,7 @@ TiDBは、実行ステータスと失敗ステータスを含む、TiDBクラス - 一部の高負荷書き込み状況で発生する可能性のある`Region is Unavailable`問題を修正します。 - キャッシュされた統計情報が最新の場合は、CPU使用率が高くなるのを避けるため、 `mysql.stats_histograms`テーブルを頻繁に読み込まないようにしてください [#24317](https://github.com/pingcap/tidb/pull/24317) -- ティクヴ +- TiKV - `zstd`を使用してリージョンスナップショットを圧縮し、負荷の高いスケジューリングやスケーリングの場合にノード間の大きなスペース差を防ぎます [#10005](https://github.com/tikv/tikv/pull/10005) @@ -213,8 +213,8 @@ TiDBは、実行ステータスと失敗ステータスを含む、TiDBクラス - MPPモードでの左外部結合およびセミアンチ結合を含むデカルト積をサポートします。 - ロック操作を最適化して、実行中の DDL ステートメントと読み取り操作が互いにブロックされないようにする。 - TiFlashによる期限切れデータのクリーンアップを最適化 - - TiFlashstorageレベルで`timestamp`列に対するクエリフィルタのさらなるフィルタリングをサポートします。 - - クラスタ内に多数のテーブルが存在する場合のTiFlashの起動速度と拡張性を向上させる + - TiFlashストレージレベルで`timestamp`列に対するクエリフィルタのさらなるフィルタリングをサポートします。 + - クラスター内に多数のテーブルが存在する場合のTiFlashの起動速度と拡張性を向上させる - 未知のCPU上で動作する際のTiFlashの互換性を向上させる - PD @@ -224,14 +224,14 @@ TiDBは、実行ステータスと失敗ステータスを含む、TiDBクラス - レプリカスナップショットの生成プロセスを最適化し、スケーリング時のスケジューリングの遅延問題を解決します[#3563](https://github.com/tikv/pd/issues/3563) [#10059](https://github.com/tikv/tikv/pull/10059) [#10001](https://github.com/tikv/tikv/pull/10001) - トラフィックの変化によるハートビートのプレッシャーが原因で発生するスケジューリングの遅延問題を解決します[#3693](https://github.com/tikv/pd/issues/3693) [#3739](https://github.com/tikv/pd/issues/3739) [#3728](https://github.com/tikv/pd/issues/3728) [#3751](https://github.com/tikv/pd/issues/3751) - - スケジューリングによる大規模クラスタの空間不一致を低減し、大きな圧縮率の不一致によって引き起こされるバースト問題（異種空間クラスタと同様）を防止するためにスケジューリング式を最適化する[#3592](https://github.com/tikv/pd/issues/3592) [#10005](https://github.com/tikv/tikv/pull/10005) + - スケジューリングによる大規模クラスターの空間不一致を低減し、大きな圧縮率の不一致によって引き起こされるバースト問題（異種空間クラスターと同様）を防止するためにスケジューリング式を最適化する[#3592](https://github.com/tikv/pd/issues/3592) [#10005](https://github.com/tikv/tikv/pull/10005) - ツール - バックアップと復元 (BR) - `mysql`スキーマにおけるシステムテーブルのバックアップと復元をサポートする[#1143](https://github.com/pingcap/br/pull/1143) [#1078](https://github.com/pingcap/br/pull/1078) - - 仮想ホストアドレス指定モードに基づくS3互換storageをサポートする [#10243](https://github.com/tikv/tikv/pull/10243) + - 仮想ホストアドレス指定モードに基づくS3互換ストレージをサポートする [#10243](https://github.com/tikv/tikv/pull/10243) - バックアップメタデータのフォーマットを最適化してメモリ使用量を削減する [#1171](https://github.com/pingcap/br/pull/1171) - TiCDC @@ -250,7 +250,7 @@ TiDBは、実行ステータスと失敗ステータスを含む、TiDBクラス - TiDB Lightning - データインポート速度の向上。最適化の結果、TPC-Cデータのインポート速度が30%向上し、インデックス数が多い（5インデックス）大規模テーブル（2TB以上）のインポート速度が50%以上向上しました。 [#753](https://github.com/pingcap/br/pull/753) - - インポート前に、インポート対象データとターゲットクラスタの両方に対して事前チェックを追加し、インポート要件を満たしていない場合はエラーを報告してインポートプロセスを拒否する [#999](https://github.com/pingcap/br/pull/999) + - インポート前に、インポート対象データとターゲットクラスターの両方に対して事前チェックを追加し、インポート要件を満たしていない場合はエラーを報告してインポートプロセスを拒否する [#999](https://github.com/pingcap/br/pull/999) - ローカルバックエンドでのチェックポイント更新のタイミングを最適化し、ブレークポイントからの再開パフォーマンスを向上させる [#1080](https://github.com/pingcap/br/pull/1080) ## バグ修正 {#bug-fixes} @@ -288,13 +288,13 @@ TiDBは、実行ステータスと失敗ステータスを含む、TiDBクラス - `CONCAT`関数が照合順序を正しく処理しない問題を修正しました [#24296](https://github.com/pingcap/tidb/issues/24296) - `collation_server`グローバル変数が新しいセッションで有効にならない問題を修正しました [#24156](https://github.com/pingcap/tidb/pull/24156) -- ティクヴ +- TiKV - コプロセッサが`IN`式内の符号付きまたは符号なし整数型を正しく処理できない問題を修正します [#9821](https://github.com/tikv/tikv/issues/9821) - SSTファイルをバッチ処理で取り込んだ後に、多数のリージョンが空になる問題を修正しました [#964](https://github.com/pingcap/br/issues/964) - ファイル辞書ファイルが破損した後にTiKVが起動できないバグを修正しました [#9886](https://github.com/tikv/tikv/issues/9886) - 古い値の読み取りによって発生する TiCDC の OOM 問題を修正[#9996](https://github.com/tikv/tikv/issues/9996) [#9981](https://github.com/tikv/tikv/issues/9981) - - 照合順序が`latin1_bin`の場合に、クラスタ化された主キー列のセカンダリ インデックスに空の値が含まれる問題を修正します [#24548](https://github.com/pingcap/tidb/issues/24548) + - 照合順序が`latin1_bin`の場合に、クラスター化された主キー列のセカンダリ インデックスに空の値が含まれる問題を修正します [#24548](https://github.com/pingcap/tidb/issues/24548) - TiKVがpanic発生時にコアダンプファイルを生成できるようにする`abort-on-panic`設定を追加します。ユーザーはコアダンプを有効にするために環境を正しく構成する必要があります [#10216](https://github.com/tikv/tikv/pull/10216) - TiKVがビジー状態でない場合に発生する`point get`クエリのパフォーマンス低下問題を修正 [#10046](https://github.com/tikv/tikv/issues/10046) diff --git a/releases/release-5.1.1.md b/releases/release-5.1.1.md index 8c68102de1df3..1f517ca671981 100644 --- a/releases/release-5.1.1.md +++ b/releases/release-5.1.1.md @@ -13,9 +13,9 @@ TiDB バージョン: 5.1.1 - TiDB - - TiDBクラスタをv4.0からv5.1にアップグレードする場合、デフォルト値は`tidb_multi_statement_mode`ではなく`OFF`です。代わりに、クライアントライブラリのマルチステートメント機能を使用することをお勧めします。詳細は[`tidb_multi_statement_mode`に関するドキュメント](/system-variables.md#tidb_multi_statement_mode-new-in-v4011)参照してください[＃25751](https://github.com/pingcap/tidb/pull/25751) + - TiDBクラスターをv4.0からv5.1にアップグレードする場合、デフォルト値は`tidb_multi_statement_mode`ではなく`OFF`です。代わりに、クライアントライブラリのマルチステートメント機能を使用することをお勧めします。詳細は[`tidb_multi_statement_mode`に関するドキュメント](/system-variables.md#tidb_multi_statement_mode-new-in-v4011)参照してください[＃25751](https://github.com/pingcap/tidb/pull/25751) - `tidb_stmt_summary_max_stmt_count`変数のデフォルト値を`200`から`3000`に変更します[＃25874](https://github.com/pingcap/tidb/pull/25874) - - `table_storage_stats`テーブル[＃26352](https://github.com/pingcap/tidb/pull/26352)アクセスするには`SUPER`権限が必要です + - `table_ストレージ_stats`テーブル[＃26352](https://github.com/pingcap/tidb/pull/26352)アクセスするには`SUPER`権限が必要です - 他のユーザーの権限[＃26311](https://github.com/pingcap/tidb/pull/26311)表示するには、 `information_schema.user_privileges`テーブルにアクセスするために`mysql.user`の`SELECT`権限が必要です。 - `information_schema.cluster_hardware`テーブル[＃26297](https://github.com/pingcap/tidb/pull/26297)アクセスするには`CONFIG`権限が必要です - `information_schema.cluster_info`テーブル[＃26297](https://github.com/pingcap/tidb/pull/26297)アクセスするには`PROCESS`権限が必要です @@ -74,7 +74,7 @@ TiDB バージョン: 5.1.1 - Dumpling - - アップストリームが TiDB v3.x クラスタの場合は、常に`_tidb_rowid`を使用してテーブルを分割します。これにより、TiDB のメモリ使用量が削減されます[＃295](https://github.com/pingcap/dumpling/issues/295) + - アップストリームが TiDB v3.x クラスターの場合は、常に`_tidb_rowid`を使用してテーブルを分割します。これにより、TiDB のメモリ使用量が削減されます[＃295](https://github.com/pingcap/dumpling/issues/295) - データベースメタデータへのアクセス頻度を減らして、Dumplingのパフォーマンスと安定性を向上させます[＃315](https://github.com/pingcap/dumpling/pull/315) ## バグ修正 {#bug-fixes} diff --git a/releases/release-5.1.2.md b/releases/release-5.1.2.md index 0fd01c6e8810b..5750e9152f9a7 100644 --- a/releases/release-5.1.2.md +++ b/releases/release-5.1.2.md @@ -138,7 +138,7 @@ TiDB バージョン: 5.1.2 - Dumpling - 一部のMySQLバージョン（8.0.3および8.0.23）で`show table status`誤った結果を返すときにDumplingが保留になる問題を修正しました[＃322](https://github.com/pingcap/dumpling/issues/322) - - デフォルト`sort-engine`オプション[＃2373](https://github.com/pingcap/tiflow/issues/2373)の 4.0.x クラスタでの CLI 互換性の問題を修正しました + - デフォルト`sort-engine`オプション[＃2373](https://github.com/pingcap/tiflow/issues/2373)の 4.0.x クラスターでの CLI 互換性の問題を修正しました - TiCDC diff --git a/releases/release-5.1.4.md b/releases/release-5.1.4.md index 922235aeb95cd..10fcc6bb981af 100644 --- a/releases/release-5.1.4.md +++ b/releases/release-5.1.4.md @@ -14,7 +14,7 @@ TiDB バージョン: 5.1.4 - TiDB - システム変数[`tidb_analyze_version`](/system-variables.md#tidb_analyze_version-new-in-v510)のデフォルト値を`2`から`1`に変更します[＃31748](https://github.com/pingcap/tidb/issues/31748) - - v5.1.4以降、TiKVが`storage.enable-ttl = true`に設定されている場合、TiKVのTTL機能は[RawKVモード](https://tikv.org/docs/5.1/concepts/explore-tikv-features/ttl/) [＃27303](https://github.com/pingcap/tidb/issues/27303)のみをサポートしているため、TiDBからの要求は拒否されます。 + - v5.1.4以降、TiKVが`ストレージ.enable-ttl = true`に設定されている場合、TiKVのTTL機能は[RawKVモード](https://tikv.org/docs/5.1/concepts/explore-tikv-features/ttl/) [＃27303](https://github.com/pingcap/tidb/issues/27303)のみをサポートしているため、TiDBからの要求は拒否されます。 - ツール @@ -146,7 +146,7 @@ TiDB バージョン: 5.1.4 - デッドロックによりレプリケーションタスクが停止する可能性がある問題を修正しました[＃4055](https://github.com/pingcap/tiflow/issues/4055) - DDL文の特別なコメントによりレプリケーションタスクが停止する問題を修正[＃3755](https://github.com/pingcap/tiflow/issues/3755) - EtcdWorker がオーナーとプロセッサ[＃3750](https://github.com/pingcap/tiflow/issues/3750)をハングさせる可能性があるバグを修正しました - - クラスタのアップグレード後に`stopped`変更フィードが自動的に再開される問題を修正[＃3473](https://github.com/pingcap/tiflow/issues/3473) + - クラスターのアップグレード後に`stopped`変更フィードが自動的に再開される問題を修正[＃3473](https://github.com/pingcap/tiflow/issues/3473) - デフォルト値を複製できない問題を修正[＃3793](https://github.com/pingcap/tiflow/issues/3793) - TiCDC のデフォルト値のパディング例外によって発生するデータの不整合を修正[＃3918](https://github.com/pingcap/tiflow/issues/3918) [＃3929](https://github.com/pingcap/tiflow/issues/3929) - PDリーダーがシャットダウンして新しいノード[＃3615](https://github.com/pingcap/tiflow/issues/3615)に転送するときにオーナーがスタックするバグを修正 @@ -175,4 +175,4 @@ TiDB バージョン: 5.1.4 - TiDB Lightning - - S3storageパスが存在しない場合にTiDB Lightningがエラーを報告しない問題を修正[＃28031](https://github.com/pingcap/tidb/issues/28031) [＃30709](https://github.com/pingcap/tidb/issues/30709) + - S3ストレージパスが存在しない場合にTiDB Lightningがエラーを報告しない問題を修正[＃28031](https://github.com/pingcap/tidb/issues/28031) [＃30709](https://github.com/pingcap/tidb/issues/30709) diff --git a/releases/release-5.1.5.md b/releases/release-5.1.5.md index e69355a5fd9c0..de70321ddbfcc 100644 --- a/releases/release-5.1.5.md +++ b/releases/release-5.1.5.md @@ -31,7 +31,7 @@ TiDBバージョン：5.1.5 - リージョンが空のデータを返した場合に発生する誤った`ANY_VALUE`の結果を修正する [#30923](https://github.com/pingcap/tidb/issues/30923) - innerWorkerのpanicによって発生したインデックス結合の誤った結果を修正 [#31494](https://github.com/pingcap/tidb/issues/31494) - SQL操作がJSON型の列と`CHAR`型の列を結合する際にキャンセルされる問題を修正しました [#29401](https://github.com/pingcap/tidb/issues/29401) - - TiDBのバックグラウンドHTTPサービスが正常に終了せず、クラスタが異常な状態になる問題を修正しました [#30571](https://github.com/pingcap/tidb/issues/30571) + - TiDBのバックグラウンドHTTPサービスが正常に終了せず、クラスターが異常な状態になる問題を修正しました [#30571](https://github.com/pingcap/tidb/issues/30571) - 同時実行される列型変更によってスキーマとデータの間に不整合が生じる問題を修正します [#31048](https://github.com/pingcap/tidb/issues/31048) - `KILL TIDB`がアイドル状態の接続で即座に有効にならない問題を修正します [#24031](https://github.com/pingcap/tidb/issues/24031) - セッション変数を設定すると`tidb_snapshot`が機能しなくなるバグを修正しました [#35515](https://github.com/pingcap/tidb/issues/35515) @@ -49,7 +49,7 @@ TiDBバージョン：5.1.5 - `lock tables`フラグが有効になっていない場合に、 `unlock tables`と`enable-table-lock`に対する警告を追加する [#28967](https://github.com/pingcap/tidb/issues/28967) - 範囲パーティションで複数の`MAXVALUE`パーティションが許可される問題を修正 [#36329](https://github.com/pingcap/tidb/issues/36329) -- ティクヴ +- TiKV - `DATETIME`値に小数点が含まれる場合と`Z`値が含まれる場合に発生する時間解析エラーの問題を修正します。 [#12739](https://github.com/tikv/tikv/issues/12739) - レプリカ読み取りが線形化可能性に違反する可能性があるバグを修正 [#12109](https://github.com/tikv/tikv/issues/12109) @@ -74,7 +74,7 @@ TiDBバージョン：5.1.5 - `not leader` [#4797](https://github.com/tikv/pd/issues/4797)の誤ったステータスコードを修正します。 - PDがダッシュボードプロキシ要求を正しく処理できない問題を修正 [#5321](https://github.com/tikv/pd/issues/5321) - TSOフォールバックの特定の特殊ケースにおけるバグを修正 [#4884](https://github.com/tikv/pd/issues/4884) - - 特定のシナリオでTiFlash学習者レプリカが作成されない可能性がある問題を修正しました [#5401](https://github.com/tikv/pd/issues/5401) + - 特定のシナリオでTiFlashラーナーレプリカが作成されない可能性がある問題を修正しました [#5401](https://github.com/tikv/pd/issues/5401) - ラベル分布にメトリクスに残余ラベルが含まれる問題を修正 [#4825](https://github.com/tikv/pd/issues/4825) - 大容量（例えば2T）のストアが存在する場合、完全に割り当てられた小型ストアを検出できず、結果としてバランス演算子が生成されない問題を修正します [#4805](https://github.com/tikv/pd/issues/4805) - `SchedulerMaxWaitingOperator`が`1`に設定されている場合、スケジューラが機能しない問題を修正します。 [#4946](https://github.com/tikv/pd/issues/4946) @@ -86,7 +86,7 @@ TiDBバージョン：5.1.5 - 並列集計のエラーによりTiFlashがクラッシュする可能性があるバグを修正しました [#5356](https://github.com/pingcap/tiflash/issues/5356) - `JOIN`を含むクエリでエラーが発生した場合にハングアップする可能性がある問題を修正しました [#4195](https://github.com/pingcap/tiflash/issues/4195) - 関数`OR`が誤った結果を返す問題を修正しました [#5849](https://github.com/pingcap/tiflash/issues/5849) - - 無効なstorageディレクトリ構成が予期しない動作を引き起こすバグを修正 [#4093](https://github.com/pingcap/tiflash/issues/4093) + - 無効なストレージディレクトリ構成が予期しない動作を引き起こすバグを修正 [#4093](https://github.com/pingcap/tiflash/issues/4093) - 多数のINSERTおよびDELETE操作後に発生する可能性のあるデータ不整合を修正する [#4956](https://github.com/pingcap/tiflash/issues/4956) - リージョン範囲に一致しないデータがTiFlashノード上に残ってしまうバグを修正しました [#4414](https://github.com/pingcap/tiflash/issues/4414) - 読み取り負荷の高い環境で列を追加した後に発生する可能性のあるクエリエラーを修正する [#3967](https://github.com/pingcap/tiflash/issues/3967) diff --git a/releases/release-5.2.0.md b/releases/release-5.2.0.md index a4a2f26102714..435e52e27b2d7 100644 --- a/releases/release-5.2.0.md +++ b/releases/release-5.2.0.md @@ -40,9 +40,9 @@ TiDB バージョン: 5.2.0 | [`tidb_stmt_summary_max_stmt_count`](/system-variables.md#tidb_stmt_summary_max_stmt_count-new-in-v40) | 修正済み | ステートメントサマリーテーブルがメモリに格納するステートメントの最大数を設定します。デフォルト値は`200`から`3000`に変更されます。 | | `tidb_enable_streaming` | 非推奨 | システム変数`enable-streaming`は非推奨であり、今後は使用しないことをお勧めします。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションアイテム | 種類を変更する | 説明 | +| 設定ファイル | 設定アイテム | 種類を変更する | 説明 | | :------------- | :---------------------------------------------------------------------------------------------------------------------------- | :------- | :------------------------------------------------------------------------------------------------------------------------------ | | TiDB設定ファイル | [`pessimistic-txn.deadlock-history-collect-retryable`](/tidb-configuration-file.md#deadlock-history-collect-retryable) | 新しく追加された | [`INFORMATION\_SCHEMA.DEADLOCKS`](/information-schema/information-schema-deadlocks.md)テーブルが再試行可能なデッドロックエラーメッセージを収集するかどうかを制御します。 | | TiDB設定ファイル | [`security.auto-tls`](/tidb-configuration-file.md#auto-tls) | 新しく追加された | 起動時にTLS証明書を自動的に生成するかどうかを決定します。デフォルト値は`false`です。 | @@ -52,11 +52,11 @@ TiDB バージョン: 5.2.0 | TiKV設定ファイル | [`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval) | 新しく追加された | TiKV は一定間隔でRaftstoreコンポーネントのレイテンシーを検査します。この設定項目は検査間隔を指定します。レイテンシーがこの値を超えると、この検査はタイムアウトとしてマークされます。デフォルト値は`500ms`です。 | | TiKV設定ファイル | [`raftstore.max-peer-down-duration`](/tikv-configuration-file.md#max-peer-down-duration) | 修正済み | ピアに許可される最長の非アクティブ期間を示します。タイムアウトしたピアは`down`とマークされ、PD は後でそれを削除しようとします。デフォルト値は`5m`から`10m`に変更されます。 | | TiKV設定ファイル | [`server.raft-client-queue-size`](/tikv-configuration-file.md#raft-client-queue-size) | 新しく追加された | TiKV のRaftメッセージのキュー サイズを指定します。デフォルト値は`8192`です。 | -| TiKV設定ファイル | [`storage.flow-control.enable`](/tikv-configuration-file.md#enable) | 新しく追加された | フロー制御メカニズムを有効にするかどうかを決定します。デフォルト値は`true`です。 | -| TiKV設定ファイル | [`storage.flow-control.memtables-threshold`](/tikv-configuration-file.md#memtables-threshold) | 新しく追加された | kvDB の memtable の数がこのしきい値に達すると、フロー制御メカニズムが動作を開始します。デフォルト値は`5`です。 | -| TiKV設定ファイル | [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold) | 新しく追加された | kvDB L0 ファイルの数がこのしきい値に達すると、フロー制御メカニズムが動作を開始します。デフォルト値は`9`です。 | -| TiKV設定ファイル | [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 新しく追加された | KvDB の保留中の圧縮バイト数がこのしきい値に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。デフォルト値は「192GB」です。 | -| TiKV設定ファイル | [`storage.flow-control.hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit) | 新しく追加された | KvDB の保留中の圧縮バイト数がこのしきい値に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。デフォルト値は「1024GB」です。 | +| TiKV設定ファイル | [`ストレージ.flow-control.enable`](/tikv-configuration-file.md#enable) | 新しく追加された | フロー制御メカニズムを有効にするかどうかを決定します。デフォルト値は`true`です。 | +| TiKV設定ファイル | [`ストレージ.flow-control.memtables-threshold`](/tikv-configuration-file.md#memtables-threshold) | 新しく追加された | kvDB の memtable の数がこのしきい値に達すると、フロー制御メカニズムが動作を開始します。デフォルト値は`5`です。 | +| TiKV設定ファイル | [`ストレージ.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold) | 新しく追加された | kvDB L0 ファイルの数がこのしきい値に達すると、フロー制御メカニズムが動作を開始します。デフォルト値は`9`です。 | +| TiKV設定ファイル | [`ストレージ.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 新しく追加された | KvDB の保留中の圧縮バイト数がこのしきい値に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。デフォルト値は「192GB」です。 | +| TiKV設定ファイル | [`ストレージ.flow-control.hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit) | 新しく追加された | KvDB の保留中の圧縮バイト数がこのしきい値に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。デフォルト値は「1024GB」です。 | ### その他 {#others} @@ -112,14 +112,14 @@ 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`の状態に分割されました。 ユーザー向けドキュメント： - - クラスタ内のすべての TiKV ノードで発生している悲観的ロック待機イベントをビュー: [`DATA_LOCK_WAITS`](/information-schema/information-schema-data-lock-waits.md) + - クラスター内のすべての TiKV ノードで発生している悲観的ロック待機イベントをビュー: [`DATA_LOCK_WAITS`](/information-schema/information-schema-data-lock-waits.md) - TiDBノードで最近発生したデッドロックエラーをビュー: [`DEADLOCKS`](/information-schema/information-schema-deadlocks.md) - TiDBノードで実行中のトランザクションをビュー: [`TIDB_TRX`](/information-schema/information-schema-tidb-trx.md) @@ -129,7 +129,7 @@ TiDB バージョン: 5.2.0 - **TiFlashのI/Oトラフィック制限を追加する** - この新機能は、ディスク帯域幅が小さく特定のサイズのクラウドstorageに適しています。デフォルトでは無効になっています。 + この新機能は、ディスク帯域幅が小さく特定のサイズのクラウドストレージに適しています。デフォルトでは無効になっています。 TiFlash I/Oレートリミッターは、読み取りタスクと書き込みタスク間のI/Oリソースの過剰な競合を回避するための新しいメカニズムを提供します。読み取りタスクと書き込みタスクへの応答のバランスを取り、読み取り/書き込みワークロードに応じてレートを自動的に制限します。 @@ -146,11 +146,11 @@ TiDB バージョン: 5.2.0 この新しいメカニズムは、書き込みトラフィックが多い場合にQPS（1秒あたりのクエリ数）が低下するのを軽減するために、フロー制御アルゴリズムを改善します。 - [ユーザー向けドキュメント](/tikv-configuration-file.md#storageflow-control)、 [#10137](https://github.com/tikv/tikv/issues/10137) + [ユーザー向けドキュメント](/tikv-configuration-file.md#ストレージflow-control)、 [#10137](https://github.com/tikv/tikv/issues/10137) -- **クラスタ内の単一の低速なTiKVノードによって引き起こされる影響を自動的に検出し、復旧する** +- **クラスター内の単一の低速なTiKVノードによって引き起こされる影響を自動的に検出し、復旧する** - TiKVは、スローノード検出メカニズムを導入しました。このメカニズムは、TiKV Raftstoreのレートを検査してスコアを計算し、ストアハートビートを通じてPDにスコアを報告します。同時に、PDに`evict-slow-store-scheduler`スケジューラを追加し、単一のスローTiKVノード上のリーダーを自動的に排除します。これにより、クラスタ全体への影響が軽減されます。また、スローノードに関するアラート項目がさらに追加され、問題の迅速な特定と解決に役立ちます。 + TiKVは、スローノード検出メカニズムを導入しました。このメカニズムは、TiKV Raftstoreのレートを検査してスコアを計算し、ストアハートビートを通じてPDにスコアを報告します。同時に、PDに`evict-slow-store-scheduler`スケジューラを追加し、単一のスローTiKVノード上のリーダーを自動的に排除します。これにより、クラスター全体への影響が軽減されます。また、スローノードに関するアラート項目がさらに追加され、問題の迅速な特定と解決に役立ちます。 [ユーザー向けドキュメント](/tikv-configuration-file.md#inspect-interval)、 [#10539](https://github.com/tikv/tikv/issues/10539) @@ -211,7 +211,7 @@ Apple M1チップを搭載したMacコンピュータで`tiup playground`コマ - 「削除済み」ステータスのバインディングに対してガベージコレクションを自動的に完了する機能をサポートする [#26206](https://github.com/pingcap/tidb/pull/26206) - `EXPLAIN VERBOSE`の結果で、バインディングがクエリ最適化に使用されているかどうかを表示する機能のサポート [#26930](https://github.com/pingcap/tidb/pull/26930) - 現在の TiDB インスタンスのバインディング キャッシュに対応するタイムスタンプを表示するための新しいステータス バリエーション`last_plan_binding_update_time`を追加します [#26340](https://github.com/pingcap/tidb/pull/26340) - - バインディング進化の開始時、またはベースライン進化を禁止する`admin evolve bindings`実行時にエラーを報告する機能をサポートする（現在、実験的機能であるため、TiDB セルフマネージド バージョンでは無効になっている）。これにより、他の機能に影響が出る。 [#26333](https://github.com/pingcap/tidb/pull/26333) + - バインディング進化の開始時、またはベースライン進化を禁止する`admin evolve bindings`実行時にエラーを報告する機能をサポートする（現在、実験的機能であるため、TiDB Self-Managed バージョンでは無効になっている）。これにより、他の機能に影響が出る。 [#26333](https://github.com/pingcap/tidb/pull/26333) - PD @@ -269,7 +269,7 @@ Apple M1チップを搭載したMacコンピュータで`tiup playground`コマ - `index-out-of-range`をチェックした際に発生する`only_full_group_by`エラーを修正します[#23839](https://github.com/pingcap/tidb/issues/23839) ) - 相関サブクエリにおけるインデックス結合の結果が間違っている問題を修正しました [#25799](https://github.com/pingcap/tidb/issues/25799) -- ティクヴ +- TiKV - 誤った`tikv_raftstore_hibernated_peer_state`メトリック [#10330](https://github.com/tikv/tikv/issues/10330)を修正 - コプロセッサ内の`json_unquote()`関数の引数の型が間違っている問題を修正 [#10176](https://github.com/tikv/tikv/issues/10176) diff --git a/releases/release-5.2.2.md b/releases/release-5.2.2.md index 1c61f934f6bc4..c084b94e92a12 100644 --- a/releases/release-5.2.2.md +++ b/releases/release-5.2.2.md @@ -49,13 +49,13 @@ TiDB バージョン: 5.2.2 - プランナーが`join`の無効なプランをキャッシュする可能性がある問題を修正しました[＃28087](https://github.com/pingcap/tidb/issues/28087) - ハッシュ列の型が列挙型[＃27893](https://github.com/pingcap/tidb/issues/27893)場合の間違ったインデックス ハッシュ結合を修正しました - アイドル接続をリサイクルすると、まれにリクエストの送信がブロックされる可能性があるバッチクライアントのバグを修正しました[＃27688](https://github.com/pingcap/tidb/pull/27688) - - ターゲット クラスタ[＃27686](https://github.com/pingcap/tidb/pull/27686)でチェックサムの実行に失敗した場合のTiDB Lightningpanic問題を修正しました。 + - ターゲット クラスター[＃27686](https://github.com/pingcap/tidb/pull/27686)でチェックサムの実行に失敗した場合のTiDB Lightningpanic問題を修正しました。 - いくつかのケースで`date_add`と`date_sub`関数の誤った結果を修正[＃27232](https://github.com/pingcap/tidb/issues/27232) - ベクトル化された式[＃28643](https://github.com/pingcap/tidb/issues/28643)の関数`hour`の誤った結果を修正します - MySQL 5.1またはそれ以前のクライアントバージョン[＃27855](https://github.com/pingcap/tidb/issues/27855)に接続する際の認証問題を修正 - 新しいインデックスが追加されたときに、指定された時間外にauto analyzeがトリガーされる可能性がある問題を修正しました[＃28698](https://github.com/pingcap/tidb/issues/28698) - セッション変数を設定すると`tidb_snapshot` [＃28683](https://github.com/pingcap/tidb/pull/28683)が無効になるバグを修正 - - ピアが見つからないリージョンが多数あるクラスタでBRが機能しないバグを修正[＃27534](https://github.com/pingcap/tidb/issues/27534) + - ピアが見つからないリージョンが多数あるクラスターでBRが機能しないバグを修正[＃27534](https://github.com/pingcap/tidb/issues/27534) - サポートされていない`cast` TiFlash [＃23907](https://github.com/pingcap/tidb/issues/23907)にプッシュダウンされたときに発生する`tidb_cast to Int32 is not supported`ような予期しないエラーを修正しました - `%s value is out of range in '%s'`エラーメッセージ[＃27964](https://github.com/pingcap/tidb/issues/27964)に`DECIMAL overflow`が欠落している問題を修正 - MPPノードの可用性検出が一部のコーナーケースで機能しないバグを修正[＃3118](https://github.com/pingcap/tics/issues/3118) diff --git a/releases/release-5.2.4.md b/releases/release-5.2.4.md index 9d0fb0d953932..9069aab8570cf 100644 --- a/releases/release-5.2.4.md +++ b/releases/release-5.2.4.md @@ -16,11 +16,11 @@ TiDBバージョン：5.2.4 - システム変数[`tidb_analyze_version`](/system-variables.md#tidb_analyze_version-new-in-v510)のデフォルト値を`2`から`1`に変更します。 [#31748](https://github.com/pingcap/tidb/issues/31748) -- ティクヴ +- TiKV - 不要なRaftログを圧縮する時間間隔 (デフォルトでは`"2s"` ) を制御するために[`raft-log-compact-sync-interval`](https://docs-archive.pingcap.com/tidb/v5.2/tikv-configuration-file#raft-log-compact-sync-interval-new-in-v524)を追加する [#11404](https://github.com/tikv/tikv/issues/11404) - [`raft-log-gc-tick-interval`](/tikv-configuration-file.md#raft-log-gc-tick-interval)のデフォルト値を`"10s"`から`"3s"`に変更する [#11404](https://github.com/tikv/tikv/issues/11404) - - [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`に設定されている場合、 [`storage.flow-control.hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit)の値が[`rocksdb.(defaultcf|writecf|lockcf).hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit-1)の値を上書きします [#11424](https://github.com/tikv/tikv/issues/11424) + - [`ストレージ.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`に設定されている場合、 [`ストレージ.flow-control.hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit)の値が[`rocksdb.(defaultcf|writecf|lockcf).hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit-1)の値を上書きします [#11424](https://github.com/tikv/tikv/issues/11424) - ツール @@ -30,7 +30,7 @@ TiDBバージョン：5.2.4 ## 改善点 {#improvements} -- ティクヴ +- TiKV - レイテンシージッターを低減するために、リーダーシップをCDCオブザーバーに移管する [#12111](https://github.com/tikv/tikv/issues/12111) - 解決ロック手順 [#11993](https://github.com/tikv/tikv/issues/11993)を必要とするリージョンの数を減らすことで、TiCDCのリカバリ時間を短縮します。 @@ -84,7 +84,7 @@ TiDBバージョン：5.2.4 - テーブルに仮想列がある場合、TiDBが誤ったデータを読み取る可能性がある問題を修正しました [#30965](https://github.com/pingcap/tidb/issues/30965) - ログレベルの設定がスロークエリログに反映されない問題を修正しました [#30309](https://github.com/pingcap/tidb/issues/30309) - パーティションテーブルが場合によってはインデックスを完全に利用してデータをスキャンできない問題を修正しました [#33966](https://github.com/pingcap/tidb/issues/33966) - - TiDBのバックグラウンドHTTPサービスが正常に終了せず、クラスタが異常な状態になる問題を修正しました [#30571](https://github.com/pingcap/tidb/issues/30571) + - TiDBのバックグラウンドHTTPサービスが正常に終了せず、クラスターが異常な状態になる問題を修正しました [#30571](https://github.com/pingcap/tidb/issues/30571) - TiDBが認証失敗のログを予期せず多数出力する可能性がある問題を修正しました [#29709](https://github.com/pingcap/tidb/issues/29709) - システム変数`max_allowed_packet`が有効にならない問題を修正します [#31422](https://github.com/pingcap/tidb/issues/31422) - `REPLACE`ステートメントが自動 ID が範囲外の場合に他の行を誤って変更してしまう問題を修正しました [#29483](https://github.com/pingcap/tidb/issues/29483) @@ -95,7 +95,7 @@ TiDBバージョン：5.2.4 - STR_TO_DATE関数がマイクロ秒部分の先頭のゼロを正しく処理できない問題を修正しました [#30078](https://github.com/pingcap/tidb/issues/30078) - TiFlashがまだ空の範囲のテーブル読み取りをサポートしていないにもかかわらず、TiDBが空の範囲のテーブルをスキャンする際に誤った結果を取得する問題を修正します。 [#33083](https://github.com/pingcap/tidb/issues/33083) -- ティクヴ +- TiKV - 古いメッセージが原因で TiKV がpanicを起こすバグを修正しました [#12023](https://github.com/tikv/tikv/issues/12023) - メモリメトリックのオーバーフローによって引き起こされる、断続的なパケット損失とメモリ不足（OOM）の問題を修正します [#12160](https://github.com/tikv/tikv/issues/12160) @@ -135,7 +135,7 @@ TiDBバージョン：5.2.4 - `IN`の結果が複数値式で正しくない問題を修正 [#4016](https://github.com/pingcap/tiflash/issues/4016) - 日付フォーマットが`'\n'`無効な区切り文字として認識する問題を修正 [#4036](https://github.com/pingcap/tiflash/issues/4036) - 読み取り負荷の高い環境で列を追加した後に発生する可能性のあるクエリエラーを修正する [#3967](https://github.com/pingcap/tiflash/issues/3967) - - 無効なstorageディレクトリ構成が予期しない動作を引き起こすバグを修正 [#4093](https://github.com/pingcap/tiflash/issues/4093) + - 無効なストレージディレクトリ構成が予期しない動作を引き起こすバグを修正 [#4093](https://github.com/pingcap/tiflash/issues/4093) - 一部の例外が正しく処理されないバグを修正 [#4101](https://github.com/pingcap/tiflash/issues/4101) - `STR_TO_DATE()`関数がマイクロ秒を解析する際に先頭のゼロを正しく処理しないバグを修正しました [#3557](https://github.com/pingcap/tiflash/issues/3557) - `INT`を`DECIMAL`にキャストするとオーバーフローが発生する可能性がある問題を修正しました [#3920](https://github.com/pingcap/tiflash/issues/3920) @@ -180,7 +180,7 @@ TiDBバージョン：5.2.4 - DDLステートメント内の特殊コメントがレプリケーションタスクの停止を引き起こす問題を修正 [#3755](https://github.com/pingcap/tiflow/issues/3755) - `config.Metadata.Timeout`の設定ミスが原因で発生するレプリケーション停止の問題を修正します [#3352](https://github.com/pingcap/tiflow/issues/3352) - RHELリリース [#3584](https://github.com/pingcap/tiflow/issues/3584)において、タイムゾーンの問題によりサービスを開始できない問題を修正しました。 - - `stopped`の変更フィードがクラスタのアップグレード後に自動的に再開される問題を修正します [#3473](https://github.com/pingcap/tiflow/issues/3473) + - `stopped`の変更フィードがクラスターのアップグレード後に自動的に再開される問題を修正します [#3473](https://github.com/pingcap/tiflow/issues/3473) - MySQLシンクのデッドロックによって発生する、警告が頻繁に発生する問題を修正しました [#2706](https://github.com/pingcap/tiflow/issues/2706) - Canalプロトコルで`enable-old-value`設定項目が`true`に自動的に設定されないバグを修正しました [#3676](https://github.com/pingcap/tiflow/issues/3676) - AvroシンクがJSON型カラムの解析をサポートしていない問題を修正 [#3624](https://github.com/pingcap/tiflow/issues/3624) @@ -198,5 +198,5 @@ TiDBバージョン：5.2.4 - TiDB Lightningが`mysql.tidb`テーブルにアクセスする権限を持たない場合に発生する、インポート結果の誤りに関する問題を修正しました [#31088](https://github.com/pingcap/tidb/issues/31088) - チェックサムエラー「GCの有効期間がトランザクション期間より短い」を修正 [#32733](https://github.com/pingcap/tidb/issues/32733) - TiDB Lightningが、一部のインポートタスクにソースファイルが含まれていない場合にメタデータスキーマを削除しない可能性があるバグを修正しました [#28144](https://github.com/pingcap/tidb/issues/28144) - - S3storageパスが存在しない場合にTiDB Lightningがエラーを報告しない問題を修正[#28031](https://github.com/pingcap/tidb/issues/28031) [#30709](https://github.com/pingcap/tidb/issues/30709) + - S3ストレージパスが存在しない場合にTiDB Lightningがエラーを報告しない問題を修正[#28031](https://github.com/pingcap/tidb/issues/28031) [#30709](https://github.com/pingcap/tidb/issues/30709) - GCSで1000個以上のキーを反復処理する際に発生するエラーを修正しました [#30377](https://github.com/pingcap/tidb/issues/30377) diff --git a/releases/release-5.3.0.md b/releases/release-5.3.0.md index 83c444f5e61c0..e9fa19afbdfac 100644 --- a/releases/release-5.3.0.md +++ b/releases/release-5.3.0.md @@ -17,9 +17,9 @@ v5.3 の主な新機能または改善点は次のとおりです。 - TiDBのタイムスタンプ処理フローを最適化して全体的なパフォーマンスを向上させる - TiDBデータ移行（DM）のパフォーマンスを強化し、MySQLからTiDBへのデータ移行のレイテンシーを低減します。 - 複数のTiDB Lightningインスタンスを使用した並列インポートをサポートし、完全なデータ移行の効率を向上します。 -- 単一のSQL文でクラスタのオンサイト情報を保存・復元する機能をサポートし、実行計画に関する問題のトラブルシューティング効率を向上します。 +- 単一のSQL文でクラスターのオンサイト情報を保存・復元する機能をサポートし、実行計画に関する問題のトラブルシューティング効率を向上します。 - データベースパフォーマンスの観測性を向上させるために、継続的なプロファイリングの実験的機能をサポートします。 -- システムのパフォーマンスと安定性を向上させるために、storageとコンピューティングエンジンの最適化を継続します。 +- システムのパフォーマンスと安定性を向上させるために、ストレージとコンピューティングエンジンの最適化を継続します。 - I/O 操作をRaftstoreスレッド プールから分離することで、TiKV の書き込みレイテンシーを削減します (デフォルトでは無効) ## 互換性の変更 {#compatibility-changes} @@ -38,13 +38,13 @@ v5.3 の主な新機能または改善点は次のとおりです。 | [`tidb_tso_client_batch_max_wait_time`](/system-variables.md#tidb_tso_client_batch_max_wait_time-new-in-v530) | 新しく追加された | TiDBがPDにTSOを要求した際に、バッチ保存操作の最大待機時間を設定します。デフォルト値は`0`で、追加の待機時間はありません。 | | [`tidb_tmp_table_max_size`](/system-variables.md#tidb_tmp_table_max_size-new-in-v530) | 新しく追加された | [一時テーブル](/temporary-tables.md)個の最大サイズを制限します。一時テーブルがこのサイズを超えるとエラーが発生します。 | -### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} +### 設定ファイルのパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーション項目 | タイプを変更 | 説明 | +| 設定ファイル | 設定項目 | タイプを変更 | 説明 | | :------------- | :------------------------------------------------------------------------------------------------- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`prepared-plan-cache.capacity`](/tidb-configuration-file.md#capacity) | 修正済み | キャッシュされるステートメントの数を制御します。デフォルト値は`100`から`1000`に変更されます。 | -| TiKV | [`storage.reserve-space`](/tikv-configuration-file.md#reserve-space) | 修正済み | TiKV起動時にディスク保護のために予約される領域を制御します。v5.3.0以降では、予約領域の80%がディスク容量不足時の運用・保守に必要な追加ディスク領域として使用され、残りの20%は一時ファイルの保存に使用されます。 | -| TiKV | `memory-usage-limit` | 修正済み | この構成項目は TiDB v5.3.0 で新しく追加され、その値はstorageの.block-cache.capacity に基づいて計算されます。 | +| TiKV | [`ストレージ.reserve-space`](/tikv-configuration-file.md#reserve-space) | 修正済み | TiKV起動時にディスク保護のために予約される領域を制御します。v5.3.0以降では、予約領域の80%がディスク容量不足時の運用・保守に必要な追加ディスク領域として使用され、残りの20%は一時ファイルの保存に使用されます。 | +| TiKV | `memory-usage-limit` | 修正済み | この構成項目は TiDB v5.3.0 で新しく追加され、その値はストレージの.block-cache.capacity に基づいて計算されます。 | | TiKV | [`raftstore.store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530) | 新しく追加された | Raft I/Oタスクを処理するスレッドの許容数。これはStoreWriterスレッドプールのサイズです。このスレッドプールのサイズを変更する場合は、 [TiKV スレッドプールのパフォーマンスチューニング](/tune-tikv-thread-performance.md#performance-tuning-for-tikv-thread-pools)を参照してください。 | | TiKV | [`raftstore.raft-write-size-limit`](/tikv-configuration-file.md#raft-write-size-limit-new-in-v530) | 新しく追加された | Raftデータがディスクに書き込まれるしきい値を決定します。データサイズがこの設定項目の値より大きい場合、データはディスクに書き込まれます。1の値が`raftstore.store-io-pool-size` `0`場合、この設定項目は有効になりません。 | | TiKV | `raftstore.raft-msg-flush-interval` | 新しく追加された | Raftメッセージをバッチ送信する間隔を指定します。バッチ送信されたRaftメッセージは、この設定項目で指定された間隔ごとに送信されます。1の値が`raftstore.store-io-pool-size` `0`場合、この設定項目は無効になります。 | @@ -65,8 +65,8 @@ v5.3 の主な新機能または改善点は次のとおりです。 - 次のクラスターは、v5.3.0 以降である必要があります。そうでない場合、グローバル一時テーブルを作成するときにデータ エラーが報告されます。 - TiDB移行ツールを使用してインポートするクラスター - - TiDB移行ツールを使用してクラスタを復元しました - - TiDB移行ツールを使用したレプリケーションタスクの下流クラスタ + - TiDB移行ツールを使用してクラスターを復元しました + - TiDB移行ツールを使用したレプリケーションタスクの下流クラスター - 一時テーブルの互換性情報については、 [MySQL 一時テーブルとの互換性](/temporary-tables.md#compatibility-with-mysql-temporary-tables)および[他の TiDB 機能との互換性の制限](/temporary-tables.md#compatibility-restrictions-with-other-tidb-features)を参照してください。 - v5.3.0より前のリリースでは、システム変数が無効な値に設定された場合、TiDBはエラーを報告します。v5.3.0以降のリリースでは、システム変数が無効な値に設定された場合、TiDBは「|警告 | 1292 | 切り捨てられた不正なxxx: 'xx'」などの警告とともに成功を返します。 @@ -79,7 +79,7 @@ v5.3 の主な新機能または改善点は次のとおりです。 - バージョン5.3.0より前のバージョンでは、新しいインデックスが追加されると、指定期間外でも自動分析が予期せず実行される問題を修正しました。バージョン5.3.0では、変数`tidb_auto_analyze_start_time`と`tidb_auto_analyze_end_time`で期間を設定すると、その期間のみ自動分析が実行されます。 -- プラグインのデフォルトのstorageディレクトリが`""`から`/data/deploy/plugin`に変更されます。 +- プラグインのデフォルトのストレージディレクトリが`""`から`/data/deploy/plugin`に変更されます。 - DMコードは[TiCDCコードリポジトリのフォルダ「dm」](https://github.com/pingcap/tiflow/tree/release-5.3/dm)に移行されました。DMのバージョン番号はTiDBに準じます。v2.0.xの次に新しいDMバージョンはv5.3.0となり、v2.0.xからv5.3.0へのアップグレードはリスクなしで行えます。 @@ -95,9 +95,9 @@ v5.3 の主な新機能または改善点は次のとおりです。 - 異なるアプリケーションの複数のデータベースを統合してデータベースのメンテナンスコストを削減し、ルール構成を通じてアプリケーションリソースの分離を実現します。 - 重要なデータのレプリカ数を増やして、アプリケーションの可用性とデータの信頼性を向上させます。 - - 新しいデータを SSD に保存し、古いデータを HHD に保存することで、データのアーカイブとstorageのコストを削減します。 + - 新しいデータを SSD に保存し、古いデータを HHD に保存することで、データのアーカイブとストレージのコストを削減します。 - ホットスポットデータのリーダーを高性能TiKVインスタンスにスケジュールする - - コスト効率を向上させるために、コールドデータを低コストのstorageメディアに分離する + - コスト効率を向上させるために、コールドデータを低コストのストレージメディアに分離する [ユーザードキュメント](/placement-rules-in-sql.md) [＃18030](https://github.com/pingcap/tidb/issues/18030) @@ -181,7 +181,7 @@ v5.3 の主な新機能または改善点は次のとおりです。 - **DM クラスターをより適切に管理するために DM OpenAPI を追加します (実験的機能)** - DMは、DMクラスタのクエリと操作のためのOpenAPI機能を提供します。これは[dmctlツール](/dm/dmctl-introduction.md)の機能に類似しています。 + DMは、DMクラスターのクエリと操作のためのOpenAPI機能を提供します。これは[dmctlツール](/dm/dmctl-introduction.md)の機能に類似しています。 現在、DM OpenAPI は実験的機能であり、デフォルトで無効になっています。本番環境での使用は推奨されません。 @@ -219,12 +219,12 @@ v5.3 の主な新機能または改善点は次のとおりです。 - **クラスターのオンサイト情報を保存および復元する** - TiDB クラスタの問題を特定してトラブルシューティングする際には、システム情報やクエリプランの情報が必要になることがよくあります。より便利かつ効率的に情報を取得し、クラスタの問題をトラブルシューティングできるよう、TiDB v5.3.0 では`PLAN REPLAYER`コマンドが導入されました。このコマンドを使用すると、クラスタのオンサイト情報を簡単に保存・復元できるため、トラブルシューティングの効率が向上し、管理のために問題をアーカイブしやすくなります。 + TiDB クラスターの問題を特定してトラブルシューティングする際には、システム情報やクエリプランの情報が必要になることがよくあります。より便利かつ効率的に情報を取得し、クラスターの問題をトラブルシューティングできるよう、TiDB v5.3.0 では`PLAN REPLAYER`コマンドが導入されました。このコマンドを使用すると、クラスターのオンサイト情報を簡単に保存・復元できるため、トラブルシューティングの効率が向上し、管理のために問題をアーカイブしやすくなります。 `PLAN REPLAYER`の特徴は以下のとおりです。 - - オンサイトトラブルシューティング時の TiDB クラスターの情報を ZIP 形式のファイルにエクスポートしてstorage。 - - 別のTiDBクラスタからエクスポートされたZIP形式のファイルをクラスタにインポートします。このファイルには、オンサイトトラブルシューティング時の後者のTiDBクラスタの情報が含まれています。 + - オンサイトトラブルシューティング時の TiDB クラスターの情報を ZIP 形式のファイルにエクスポートしてストレージ。 + - 別のTiDBクラスターからエクスポートされたZIP形式のファイルをクラスターにインポートします。このファイルには、オンサイトトラブルシューティング時の後者のTiDBクラスターの情報が含まれています。 [ユーザードキュメント](/sql-plan-replayer.md) [＃26325](https://github.com/pingcap/tidb/issues/26325) @@ -232,7 +232,7 @@ v5.3 の主な新機能または改善点は次のとおりです。 - **TiCDC 結果的に一貫性のあるレプリケーション** - TiCDCは、災害シナリオにおいて結果整合性のあるレプリケーション機能を提供します。プライマリTiDBクラスタで災害が発生し、短期間でサービスを再開できない場合、TiCDCはセカンダリクラスタのデータの整合性を確保する機能を提供する必要があります。同時に、TiCDCは、データベースが長時間利用できなくなり業務に支障をきたすことを回避するため、ビジネス部門がトラフィックをセカンダリクラスタに迅速に切り替えられるようにする必要があります。 + TiCDCは、災害シナリオにおいて結果整合性のあるレプリケーション機能を提供します。プライマリTiDBクラスターで災害が発生し、短期間でサービスを再開できない場合、TiCDCはセカンダリクラスターのデータの整合性を確保する機能を提供する必要があります。同時に、TiCDCは、データベースが長時間利用できなくなり業務に支障をきたすことを回避するため、ビジネス部門がトラフィックをセカンダリクラスターに迅速に切り替えられるようにする必要があります。 この機能は、TiCDC が TiDB クラスターからセカンダリリレーショナルデータベース TiDB/ Aurora/MySQL/MariaDB に増分データをレプリケーションすることをサポートします。プライマリクラスターがクラッシュした場合、災害発生前の TiCDC のレプリケーション状態が正常で、レプリケーション遅延が小さいという条件付きで、TiCDC は 5 分以内にセカンダリクラスターをプライマリクラスター内の特定のスナップショットに復旧できます。これにより、データ損失は 30 分未満、つまり RTO <= 5 分、RPO <= 30 分を実現できます。 @@ -275,7 +275,7 @@ TiCDC v5.3.0以降、TiDBクラスター間の循環レプリケーション機 - TiKV - - ディスクスペース保護を強化してstorageの安定性を向上 + - ディスクスペース保護を強化してストレージの安定性を向上 ディスク書き込みエラーが発生した場合にTiKVがpanicに陥る可能性がある問題を解決するため、TiKVは2段階のしきい値防御メカニズムを導入し、過剰なトラフィックによるディスク残容量の枯渇を防ぎます。さらに、このメカニズムは、しきい値に達した際に領域を回収する機能も提供します。残容量しきい値に達すると、一部の書き込み操作が失敗し、TiKVはディスクフルエラーとディスクフルノードのリストを返します。この場合、領域を回復してサービスを復旧するには、 `Drop/Truncate Table`実行するか、ノードをスケールアウトします。 @@ -303,7 +303,7 @@ TiCDC v5.3.0以降、TiDBクラスター間の循環レプリケーション機 - Exchangeオペレーターの実行効率を向上させる - - storageエンジンの GC 中の書き込み増幅とメモリ使用量を削減します (実験的機能) + - ストレージエンジンの GC 中の書き込み増幅とメモリ使用量を削減します (実験的機能) - TiFlash の再起動時にTiFlashの安定性と可用性が向上し、再起動後に発生する可能性のあるクエリの失敗が減少します。 @@ -344,13 +344,13 @@ TiCDC v5.3.0以降、TiDBクラスター間の循環レプリケーション機 - プランナーが場合によっては無効なプランをキャッシュする可能性がある問題を修正`join` [＃28087](https://github.com/pingcap/tidb/issues/28087) - ハッシュ列の型が`enum` [＃27893](https://github.com/pingcap/tidb/issues/27893)の場合の誤った`IndexLookUpJoin`修正 - アイドル接続をリサイクルすると、まれにリクエストの送信がブロックされる可能性があるバッチクライアントのバグを修正しました[＃27688](https://github.com/pingcap/tidb/pull/27688) - - ターゲット クラスタ[＃27686](https://github.com/pingcap/tidb/pull/27686)でチェックサムの実行に失敗した場合のTiDB Lightningpanic問題を修正しました。 + - ターゲット クラスター[＃27686](https://github.com/pingcap/tidb/pull/27686)でチェックサムの実行に失敗した場合のTiDB Lightningpanic問題を修正しました。 - いくつかのケースで`date_add`と`date_sub`関数の誤った結果を修正[＃27232](https://github.com/pingcap/tidb/issues/27232) - ベクトル化された式[＃28643](https://github.com/pingcap/tidb/issues/28643)の関数`hour`の誤った結果を修正します - MySQL 5.1 またはそれ以前のクライアントバージョン[＃27855](https://github.com/pingcap/tidb/issues/27855)に接続する際の認証の問題を修正しました - 新しいインデックスが追加されたときに、指定された時間外にauto analyzeがトリガーされる可能性がある問題を修正しました[＃28698](https://github.com/pingcap/tidb/issues/28698) - セッション変数を設定すると`tidb_snapshot` [＃28683](https://github.com/pingcap/tidb/pull/28683)が無効になるバグを修正 - - ピアが見つからないリージョンが多数あるクラスタでBRが機能しないバグを修正[＃27534](https://github.com/pingcap/tidb/issues/27534) + - ピアが見つからないリージョンが多数あるクラスターでBRが機能しないバグを修正[＃27534](https://github.com/pingcap/tidb/issues/27534) - サポートされていない`cast` TiFlash [＃23907](https://github.com/pingcap/tidb/issues/23907)にプッシュダウンされたときに発生する`tidb_cast to Int32 is not supported`のような予期しないエラーを修正しました - `%s value is out of range in '%s'`エラーメッセージ[＃27964](https://github.com/pingcap/tidb/issues/27964)に`DECIMAL overflow`が欠落している問題を修正 - MPPノードの可用性検出が一部のコーナーケースで機能しないバグを修正[＃3118](https://github.com/pingcap/tics/issues/3118) diff --git a/releases/release-5.3.1.md b/releases/release-5.3.1.md index 7735d8f5a0633..9b3f00e18114a 100644 --- a/releases/release-5.3.1.md +++ b/releases/release-5.3.1.md @@ -38,7 +38,7 @@ TiDB バージョン: 5.3.1 - TiCDC - Kafka プロデューサーの設定パラメータを公開して、TiCDC [＃4385](https://github.com/pingcap/tiflow/issues/4385)で設定できるようにします。 - - S3 をバックエンドstorageとして使用する場合、TiCDC の起動時に事前クリーンアッププロセスを追加します[＃3878](https://github.com/pingcap/tiflow/issues/3878) + - S3 をバックエンドストレージとして使用する場合、TiCDC の起動時に事前クリーンアッププロセスを追加します[＃3878](https://github.com/pingcap/tiflow/issues/3878) - TiCDCクライアントは証明書名が指定されていない場合でも動作します[＃3627](https://github.com/pingcap/tiflow/issues/3627) - チェックポイントのタイムスタンプが予期せず進むのを避けるために、テーブルごとにシンクのチェックポイントを管理する[＃3545](https://github.com/pingcap/tiflow/issues/3545) - チェンジフィードを再開するための指数バックオフメカニズムを追加します[＃3329](https://github.com/pingcap/tiflow/issues/3329) @@ -127,7 +127,7 @@ TiDB バージョン: 5.3.1 - ロードタスクを停止するとタスク[＃3771](https://github.com/pingcap/tiflow/issues/3771)が予期せず転送されるバグを修正 - ローダー[＃3252](https://github.com/pingcap/tiflow/issues/3252)のコマンド`query-status`で間違った進行状況が返される問題を修正しました - クラスター内に異なるバージョンの TiCDC ノードがある場合に HTTP API が動作しない問題を修正[＃3483](https://github.com/pingcap/tiflow/issues/3483) - - S3storageがTiCDC Redo Log [＃3523](https://github.com/pingcap/tiflow/issues/3523)で構成されている場合に TiCDC が異常終了する問題を修正しました + - S3ストレージがTiCDC Redo Log [＃3523](https://github.com/pingcap/tiflow/issues/3523)で構成されている場合に TiCDC が異常終了する問題を修正しました - デフォルト値を複製できない問題を修正[＃3793](https://github.com/pingcap/tiflow/issues/3793) - `batch-replace-enable`無効になっている場合、MySQLシンクが重複した`replace` SQL文を生成するバグを修正[＃4501](https://github.com/pingcap/tiflow/issues/4501) - ステータス[＃4281](https://github.com/pingcap/tiflow/issues/4281)照会するときにのみ同期メトリックが更新される問題を修正しました @@ -140,7 +140,7 @@ TiDB バージョン: 5.3.1 - DDL文の特別なコメントによりレプリケーションタスクが停止する問題を修正[＃3755](https://github.com/pingcap/tiflow/issues/3755) - `config.Metadata.Timeout` [＃3352](https://github.com/pingcap/tiflow/issues/3352)の誤った構成によって発生するレプリケーション停止の問題を修正しました - 一部の RHEL リリース[＃3584](https://github.com/pingcap/tiflow/issues/3584)でタイムゾーンの問題によりサービスを開始できない問題を修正しました - - クラスタのアップグレード後に`stopped`変更フィードが自動的に再開される問題を修正[＃3473](https://github.com/pingcap/tiflow/issues/3473) + - クラスターのアップグレード後に`stopped`変更フィードが自動的に再開される問題を修正[＃3473](https://github.com/pingcap/tiflow/issues/3473) - デフォルト値を複製できない問題を修正[＃3793](https://github.com/pingcap/tiflow/issues/3793) - MySQLシンクデッドロック[＃2706](https://github.com/pingcap/tiflow/issues/2706)による警告が頻繁に発生する問題を修正 - Canalプロトコル[＃3676](https://github.com/pingcap/tiflow/issues/3676)で設定項目`enable-old-value`が自動的に`true`に設定されないバグを修正 @@ -160,6 +160,6 @@ TiDB バージョン: 5.3.1 - TiDB Lightning - 一部のインポートタスクにソースファイルが含まれていない場合にTiDB Lightningがメタデータスキーマを削除しない可能性があるバグを修正しました[＃28144](https://github.com/pingcap/tidb/issues/28144) - - storageURL プレフィックスが「gcs://xxx」ではなく「gs://xxx」の場合にTiDB Lightning がエラーを返すバグを修正しました[＃32742](https://github.com/pingcap/tidb/issues/32742) + - ストレージURL プレフィックスが「gcs://xxx」ではなく「gs://xxx」の場合にTiDB Lightning がエラーを返すバグを修正しました[＃32742](https://github.com/pingcap/tidb/issues/32742) - --log-file="-" を設定しても stdout [＃29876](https://github.com/pingcap/tidb/issues/29876)にログが出力されない問題を修正しました - - S3storageパスが存在しない場合にTiDB Lightningがエラーを報告しない問題を修正[＃30709](https://github.com/pingcap/tidb/issues/30709) + - S3ストレージパスが存在しない場合にTiDB Lightningがエラーを報告しない問題を修正[＃30709](https://github.com/pingcap/tidb/issues/30709) diff --git a/releases/release-5.3.2.md b/releases/release-5.3.2.md index 37bfbfcdfd460..30acf7779a820 100644 --- a/releases/release-5.3.2.md +++ b/releases/release-5.3.2.md @@ -92,7 +92,7 @@ TiDB バージョン: 5.3.2 - TiFlash - - 無効なstorageディレクトリ設定が予期しない動作を引き起こすバグを修正[＃4093](https://github.com/pingcap/tiflash/issues/4093) + - 無効なストレージディレクトリ設定が予期しない動作を引き起こすバグを修正[＃4093](https://github.com/pingcap/tiflash/issues/4093) - `NOT NULL`列を追加したときに報告された修正`TiFlash_schema_error` [＃4596](https://github.com/pingcap/tiflash/issues/4596) - `commit state jump backward`エラー[＃2576](https://github.com/pingcap/tiflash/issues/2576)による繰り返しのクラッシュを修正 - 多数のINSERTおよびDELETE操作後に発生する可能性のあるデータの不整合を修正[＃4956](https://github.com/pingcap/tiflash/issues/4956) @@ -115,7 +115,7 @@ TiDB バージョン: 5.3.2 - GC [＃4511](https://github.com/pingcap/tiflash/issues/4511)以降に空のセグメントを結合できないバグを修正 - TLS が有効になっているときに発生するpanic問題を修正[＃4196](https://github.com/pingcap/tiflash/issues/4196) - 期限切れのデータがゆっくりとリサイクルされる問題を修正[＃4146](https://github.com/pingcap/tiflash/issues/4146) - - 無効なstorageディレクトリ設定が予期しない動作を引き起こすバグを修正[＃4093](https://github.com/pingcap/tiflash/issues/4093) + - 無効なストレージディレクトリ設定が予期しない動作を引き起こすバグを修正[＃4093](https://github.com/pingcap/tiflash/issues/4093) - 一部の例外が適切に処理されないバグを修正[＃4101](https://github.com/pingcap/tiflash/issues/4101) - 読み取り負荷が高い状態で列を追加した後に発生する可能性のあるクエリエラーを修正[＃3967](https://github.com/pingcap/tiflash/issues/3967) - `STR_TO_DATE()`関数がマイクロ秒を解析する際に先頭のゼロを誤って処理するバグを修正[＃3557](https://github.com/pingcap/tiflash/issues/3557) diff --git a/releases/release-5.3.4.md b/releases/release-5.3.4.md index eb3c1270d13c5..5d06d8b750140 100644 --- a/releases/release-5.3.4.md +++ b/releases/release-5.3.4.md @@ -41,7 +41,7 @@ TiDB バージョン: 5.3.4 - PD - PDがダッシュボードプロキシリクエストを正しく処理できない問題を修正[＃5321](https://github.com/tikv/pd/issues/5321) - - 特定のシナリオでTiFlash学習者レプリカが作成されない可能性がある問題を修正[＃5401](https://github.com/tikv/pd/issues/5401) + - 特定のシナリオでTiFlashラーナーレプリカが作成されない可能性がある問題を修正[＃5401](https://github.com/tikv/pd/issues/5401) - 不正確なストリームタイムアウトを修正し、リーダーの切り替えを高速化[＃5207](https://github.com/tikv/pd/issues/5207) - TiFlash diff --git a/releases/release-5.4.0.md b/releases/release-5.4.0.md index 32d6737401e7d..7bb7ac5153714 100644 --- a/releases/release-5.4.0.md +++ b/releases/release-5.4.0.md @@ -1,6 +1,6 @@ --- title: TiDB 5.4 Release Notes -summary: TiDB 5.4 では、GBK 文字セット、インデックス マージ、古いデータの読み取り、統計構成の永続化、および TiKV のログstorageエンジンとしてのRaft Engine の使用がサポートされます。また、バックアップの影響が改善され、Azure Blobstorageがサポートされ、 TiFlashと MPP エンジンが強化されます。互換性の変更には、新しいシステム変数と構成ファイル パラメーターが含まれます。その他の改善点には、SQL、セキュリティ、パフォーマンス、安定性、高可用性、データ移行、診断効率、およびデプロイメントが含まれます。バグ修正では、TiDB、TiKV、PD、 TiFlash、 BR、TiCDC、DM、 TiDB Lightning、および TiDB Binlogの問題に対処します。 +summary: TiDB 5.4 では、GBK 文字セット、インデックス マージ、古いデータの読み取り、統計構成の永続化、および TiKV のログストレージエンジンとしてのRaft Engine の使用がサポートされます。また、バックアップの影響が改善され、Azure Blobストレージがサポートされ、 TiFlashと MPP エンジンが強化されます。互換性の変更には、新しいシステム変数と構成ファイル パラメーターが含まれます。その他の改善点には、SQL、セキュリティ、パフォーマンス、安定性、高可用性、データ移行、診断効率、およびデプロイメントが含まれます。バグ修正では、TiDB、TiKV、PD、 TiFlash、 BR、TiCDC、DM、 TiDB Lightning、および TiDB Binlogの問題に対処します。 --- # TiDB 5.4 リリースノート {#tidb-5-4-release-notes} @@ -15,9 +15,9 @@ TiDB バージョン: 5.4.0 - インデックスマージを使用してデータにアクセスすることをサポートします。これは、複数の列のインデックスのフィルタリング結果をマージします。 - セッション変数を使用して古いデータを読み取ることをサポートする - 統計情報を収集するための設定を永続化する機能をサポートする -- TiKVのログstorageエンジンとしてRaft Engineを使用することをサポートする（実験的） -- バックアップがクラスタに与える影響を最適化する -- バックアップstorageとしてAzure Blobstorageの使用をサポートします。 +- TiKVのログストレージエンジンとしてRaft Engineを使用することをサポートする（実験的） +- バックアップがクラスターに与える影響を最適化する +- バックアップストレージとしてAzure Blobストレージの使用をサポートします。 - TiFlashおよびMPPエンジンの安定性と性能を継続的に向上させる - TiDB Lightningに、既存のテーブルへのデータインポートを許可するかどうかを決定するスイッチを追加します。 - 継続的プロファイリング機能の最適化（実験的） @@ -31,28 +31,28 @@ TiDB バージョン: 5.4.0 ### システム変数 {#system-variables} -
変数名種類を変更する説明
tidb_enable_column_tracking新しく追加されたTiDBがPREDICATE COLUMNSを収集することを許可するかどうかを制御します。デフォルト値はOFF.
tidb_enable_paging新しく追加されたIndexLookUp演算子でコプロセッサ要求を送信する際にページング方式を使用するかどうかを制御します。デフォルト値はOFFです。
IndexLookupとLimitを使用する読み取りクエリで、 LimitをIndexScanにプッシュダウンできない場合、読み取りクエリのレイテンシーが高くなり、TiKVのunified read poolのCPU使用率が高くなる可能性があります。このような場合、 Limit演算子は少量のデータしか必要としないため、 tidb_enable_paging ONに設定すると、TiDBが処理するデータ量が少なくなり、クエリのレイテンシーとリソース消費が削減されます。
tidb_enable_top_sql新しく追加されたTop SQL機能を有効にするかどうかを制御します。デフォルト値はOFFです。
tidb_persist_analyze_options新しく追加されたANALYZE構成の永続化機能を有効にするかどうかを制御します。デフォルト値はONです。
tidb_read_staleness新しく追加された現在のセッションで読み取れる履歴データの範囲を制御します。デフォルト値は0です。
tidb_regard_null_as_point新しく追加されたオプティマイザが、NULL等価性を含むクエリ条件をインデックスアクセスのプレフィックス条件として使用できるかどうかを制御します。
tidb_stats_load_sync_wait新しく追加された同期的に統計情報を読み込む機能を有効にするかどうかを制御します。デフォルト値の0は、この機能が無効になっており、統計情報が非同期的に読み込まれることを意味します。この機能が有効になっている場合、この変数は、SQL 最適化がタイムアウトする前に同期的に統計情報を読み込むのを待機できる最大時間を制御します。
tidb_stats_load_pseudo_timeout新しく追加された同期的に統計情報を読み込む際にタイムアウトが発生した場合、SQLが失敗するか（ OFF ）、擬似統計情報を使用するようにフォールバックするか（ ON ）を制御します。デフォルト値はOFFです。
tidb_backoff_lock_fast修正済みデフォルト値が100から10に変更されました。
tidb_enable_index_merge修正済みデフォルト値がOFFからONに変更されます。
  • TiDBクラスタをv4.0.0より前のバージョンからv5.4.0以降にアップグレードする場合、この変数はデフォルトでOFFなります。
  • TiDBクラスタをv4.0.0以降からv5.4.0以降にアップグレードした場合、この変数はアップグレード前と同じままです。
  • バージョン5.4.0以降で新たに作成されたTiDBクラスタでは、この変数はデフォルトでONなっています。
tidb_store_limit修正済みバージョン5.4.0より前は、この変数はインスタンスレベルとグローバルレベルの両方で設定可能でした。バージョン5.4.0以降は、この変数はグローバル設定のみをサポートします。
+
変数名種類を変更する説明
tidb_enable_column_tracking新しく追加されたTiDBがPREDICATE COLUMNSを収集することを許可するかどうかを制御します。デフォルト値はOFF.
tidb_enable_paging新しく追加されたIndexLookUp演算子でコプロセッサ要求を送信する際にページング方式を使用するかどうかを制御します。デフォルト値はOFFです。
IndexLookupとLimitを使用する読み取りクエリで、 LimitをIndexScanにプッシュダウンできない場合、読み取りクエリのレイテンシーが高くなり、TiKVのunified read poolのCPU使用率が高くなる可能性があります。このような場合、 Limit演算子は少量のデータしか必要としないため、 tidb_enable_paging ONに設定すると、TiDBが処理するデータ量が少なくなり、クエリのレイテンシーとリソース消費が削減されます。
tidb_enable_top_sql新しく追加されたTop SQL機能を有効にするかどうかを制御します。デフォルト値はOFFです。
tidb_persist_analyze_options新しく追加されたANALYZE構成の永続化機能を有効にするかどうかを制御します。デフォルト値はONです。
tidb_read_staleness新しく追加された現在のセッションで読み取れる履歴データの範囲を制御します。デフォルト値は0です。
tidb_regard_null_as_point新しく追加されたオプティマイザが、NULL等価性を含むクエリ条件をインデックスアクセスのプレフィックス条件として使用できるかどうかを制御します。
tidb_stats_load_sync_wait新しく追加された同期的に統計情報を読み込む機能を有効にするかどうかを制御します。デフォルト値の0は、この機能が無効になっており、統計情報が非同期的に読み込まれることを意味します。この機能が有効になっている場合、この変数は、SQL 最適化がタイムアウトする前に同期的に統計情報を読み込むのを待機できる最大時間を制御します。
tidb_stats_load_pseudo_timeout新しく追加された同期的に統計情報を読み込む際にタイムアウトが発生した場合、SQLが失敗するか（ OFF ）、擬似統計情報を使用するようにフォールバックするか（ ON ）を制御します。デフォルト値はOFFです。
tidb_backoff_lock_fast修正済みデフォルト値が100から10に変更されました。
tidb_enable_index_merge修正済みデフォルト値がOFFからONに変更されます。
  • TiDBクラスターをv4.0.0より前のバージョンからv5.4.0以降にアップグレードする場合、この変数はデフォルトでOFFなります。
  • TiDBクラスターをv4.0.0以降からv5.4.0以降にアップグレードした場合、この変数はアップグレード前と同じままです。
  • バージョン5.4.0以降で新たに作成されたTiDBクラスターでは、この変数はデフォルトでONなっています。
tidb_store_limit修正済みバージョン5.4.0より前は、この変数はインスタンスレベルとグローバルレベルの両方で設定可能でした。バージョン5.4.0以降は、この変数はグローバル設定のみをサポートします。
-### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーション | 種類を変更する | 説明 | +| 設定ファイル | 設定 | 種類を変更する | 説明 | | :------------- | :-------------------------------------------------------------------------------------------------------------- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`stats-load-concurrency`](/tidb-configuration-file.md#stats-load-concurrency-new-in-v540) | 新しく追加された | TiDBの同期ロード統計機能が同時に処理できる列の最大数を制御します。デフォルト値は`5`です。 | | TiDB | [`stats-load-queue-size`](/tidb-configuration-file.md#stats-load-queue-size-new-in-v540) | 新しく追加された | TiDBの同期ロード統計機能がキャッシュできる列リクエストの最大数を制御します。デフォルト値は`1000`です。 | -| ティクヴ | [`snap-generator-pool-size`](/tikv-configuration-file.md#snap-generator-pool-size-new-in-v540) | 新しく追加された | `snap-generator`スレッドプールのサイズ。デフォルト値は`2`です。 | -| ティクヴ | `log.file.max-size` 、 `log.file.max-days` 、 `log.file.max-backups` | 新しく追加された | 詳細については、 [TiKVコンフィグレーションファイル - `log.file`](/tikv-configuration-file.md#logfile-new-in-v540)を参照してください。 | -| ティクヴ | `raft-engine` | 新しく追加された | `enable` 、 `dir` 、 `batch-compression-threshold` 、 `bytes-per-sync` 、 `target-file-size` 、 `purge-threshold` 、 `recovery-mode` 、 `recovery-read-block-size` 、 `recovery-read-block-size` 、および`recovery-threads`含まれます。詳細は、 [TiKVコンフィグレーションファイル - `raft-engine`](/tikv-configuration-file.md#raft-engine)を参照してください。 | -| ティクヴ | [`backup.enable-auto-tune`](/tikv-configuration-file.md#enable-auto-tune-new-in-v540) | 新しく追加された | v5.3.0 では、デフォルト値は`false`です。v5.4.0 以降では、デフォルト値は`true`に変更されました。このパラメータは、クラスタのリソース使用率が高い場合に、バックアップ タスクで使用されるリソースを制限してクラスタへの影響を軽減するかどうかを制御します。デフォルト設定では、バックアップ タスクの速度が低下する可能性があります。 | -| ティクヴ | `log-level` 、 `log-format` 、 `log-file` 、 `log-rotation-size` | 修正済み | TiKV ログ パラメータの名前は、TiDB ログ パラメータと互換性のある名前`log.level` 、 `log.format` 、 `log.file.filename` 、および`log.enable-timestamp` 。古いパラメータのみを設定し、その値をデフォルト値以外に設定した場合、古いパラメータは新しいパラメータと互換性があります。古いパラメータと新しいパラメータの両方を設定した場合、新しいパラメータが有効になります。詳細については、[TiKVコンフィグレーションファイル - ログ](/tikv-configuration-file.md#log-new-in-v540)を参照してください。 | -| ティクヴ | `log-rotation-timespan` | 削除済み | ログファイルのローテーション間隔。この間隔が経過すると、ログファイルがローテーションされます。これは、現在のログファイルのファイル名にタイムスタンプが追加され、新しいログファイルが作成されることを意味します。 | -| ティクヴ | `allow-remove-leader` | 削除済み | メインスイッチの削除を許可するかどうかを決定します。 | -| ティクヴ | `raft-msg-flush-interval` | 削除済み | Raftメッセージがバッチで送信される間隔を決定します。Raftメッセージは、この設定項目で指定された間隔ごとにバッチで送信されます。 | +| TiKV | [`snap-generator-pool-size`](/tikv-configuration-file.md#snap-generator-pool-size-new-in-v540) | 新しく追加された | `snap-generator`スレッドプールのサイズ。デフォルト値は`2`です。 | +| TiKV | `log.file.max-size` 、 `log.file.max-days` 、 `log.file.max-backups` | 新しく追加された | 詳細については、 [TiKV設定ファイル - `log.file`](/tikv-configuration-file.md#logfile-new-in-v540)を参照してください。 | +| TiKV | `raft-engine` | 新しく追加された | `enable` 、 `dir` 、 `batch-compression-threshold` 、 `bytes-per-sync` 、 `target-file-size` 、 `purge-threshold` 、 `recovery-mode` 、 `recovery-read-block-size` 、 `recovery-read-block-size` 、および`recovery-threads`含まれます。詳細は、 [TiKV設定ファイル - `raft-engine`](/tikv-configuration-file.md#raft-engine)を参照してください。 | +| TiKV | [`backup.enable-auto-tune`](/tikv-configuration-file.md#enable-auto-tune-new-in-v540) | 新しく追加された | v5.3.0 では、デフォルト値は`false`です。v5.4.0 以降では、デフォルト値は`true`に変更されました。このパラメータは、クラスターのリソース使用率が高い場合に、バックアップ タスクで使用されるリソースを制限してクラスターへの影響を軽減するかどうかを制御します。デフォルト設定では、バックアップ タスクの速度が低下する可能性があります。 | +| TiKV | `log-level` 、 `log-format` 、 `log-file` 、 `log-rotation-size` | 修正済み | TiKV ログ パラメータの名前は、TiDB ログ パラメータと互換性のある名前`log.level` 、 `log.format` 、 `log.file.filename` 、および`log.enable-timestamp` 。古いパラメータのみを設定し、その値をデフォルト値以外に設定した場合、古いパラメータは新しいパラメータと互換性があります。古いパラメータと新しいパラメータの両方を設定した場合、新しいパラメータが有効になります。詳細については、[TiKV設定ファイル - ログ](/tikv-configuration-file.md#log-new-in-v540)を参照してください。 | +| TiKV | `log-rotation-timespan` | 削除済み | ログファイルのローテーション間隔。この間隔が経過すると、ログファイルがローテーションされます。これは、現在のログファイルのファイル名にタイムスタンプが追加され、新しいログファイルが作成されることを意味します。 | +| TiKV | `allow-remove-leader` | 削除済み | メインスイッチの削除を許可するかどうかを決定します。 | +| TiKV | `raft-msg-flush-interval` | 削除済み | Raftメッセージがバッチで送信される間隔を決定します。Raftメッセージは、この設定項目で指定された間隔ごとにバッチで送信されます。 | | PD | [`log.level`](/pd-configuration-file.md#level) | 修正済み | デフォルト値が「INFO」から「info」に変更され、大文字と小文字を区別しないことが保証されます。 | | TiFlash | [`profile.default.enable_elastic_threadpool`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 新しく追加された | エラスティック スレッド プール機能を有効にするか無効にするかを決定します。この設定項目を有効にすると、高並行処理シナリオでのTiFlash CPU 使用率が大幅に向上します。デフォルト値は`false`です。 | -| TiFlash | [`storage.format_version`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 新しく追加された | DTFile のバージョンを指定します。デフォルト値は`2`で、このバージョンではハッシュがデータファイルに埋め込まれます。値を`3`に設定することもできます。 `3`の場合、データファイルにはメタデータとトークンデータのチェックサムが含まれ、複数のハッシュアルゴリズムがサポートされます。 | +| TiFlash | [`ストレージ.format_version`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 新しく追加された | DTFile のバージョンを指定します。デフォルト値は`2`で、このバージョンではハッシュがデータファイルに埋め込まれます。値を`3`に設定することもできます。 `3`の場合、データファイルにはメタデータとトークンデータのチェックサムが含まれ、複数のハッシュアルゴリズムがサポートされます。 | | TiFlash | [`logger.count`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 修正済み | デフォルト値は`10`に変更されます。 | | TiFlash | [`status.metrics_port`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 修正済み | デフォルト値は`8234`に変更されます。 | -| TiFlash | [`raftstore.apply-pool-size`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 新しく追加された | Raftデータをstorageにフラッシュするプール内のスレッドの許容数。デフォルト値は`4`です。 | +| TiFlash | [`raftstore.apply-pool-size`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 新しく追加された | Raftデータをストレージにフラッシュするプール内のスレッドの許容数。デフォルト値は`4`です。 | | TiFlash | [`raftstore.store-pool-size`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 新しく追加された | Raftを処理するスレッドの許容数。これはRaftstoreスレッドプールのサイズです。デフォルト値は`4`です。 | | TiDBデータ移行（DM） | [`collation_compatible`](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced) | 新しく追加された | `CREATE` SQL ステートメントのデフォルトの照合照合順序を同期するモード。値のオプションは「loose」（デフォルト）と「strict」です。 | | TiCDC | `max-message-bytes` | 修正済み | Kafkaシンクの`max-message-bytes`のデフォルト値を`104857601`に変更します（10MB）。 | @@ -83,7 +83,7 @@ TiDB バージョン: 5.4.0 バージョン 5.4.0 より前の TiDB は、 `ascii` 、 `binary` 、 `latin1` 、 `utf8` 、および`utf8mb4`文字セットをサポートしています。 - 中国語ユーザーをより適切にサポートするため、TiDB はバージョン 5.4.0 以降、GBK 文字セットをサポートしています。TiDB クラスタを初めて初期化する際に、TiDB 設定ファイルで[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)オプションを有効にすると、TiDB GBK 文字セットは`gbk_bin`と`gbk_chinese_ci`の照合順序をサポートします。 + 中国語ユーザーをより適切にサポートするため、TiDB はバージョン 5.4.0 以降、GBK 文字セットをサポートしています。TiDB クラスターを初めて初期化する際に、TiDB 設定ファイルで[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)オプションを有効にすると、TiDB GBK 文字セットは`gbk_bin`と`gbk_chinese_ci`の照合順序をサポートします。 GBK 文字セットを使用する場合は、互換性の制限に注意する必要があります。詳細については、[文字セットと照合 - GBK](/character-set-gbk.md)参照してください。 @@ -91,7 +91,7 @@ TiDB バージョン: 5.4.0 - **TiSparkはユーザー認証と認可をサポートしています。** - TiSpark 2.5.0以降、TiSparkはデータベースユーザー認証と、データベースまたはテーブルレベルでの読み書き権限の両方をサポートしています。この機能を有効にすることで、データ取得のためのドローなどの不正なバッチタスクの実行を防止でき、オンラインクラスタの安定性とデータセキュリティが向上します。 + TiSpark 2.5.0以降、TiSparkはデータベースユーザー認証と、データベースまたはテーブルレベルでの読み書き権限の両方をサポートしています。この機能を有効にすることで、データ取得のためのドローなどの不正なバッチタスクの実行を防止でき、オンラインクラスターの安定性とデータセキュリティが向上します。 この機能はデフォルトでは無効になっています。有効にした場合、TiSpark を介して操作するユーザーに必要な権限がない場合、TiSpark から例外が返されます。 @@ -105,7 +105,7 @@ TiDB バージョン: 5.4.0 ### パフォーマンス {#performance} -- **カラム型storageエンジンTiFlashおよび演算エンジンMPPの安定性とパフォーマンスの向上を継続する。** +- **カラム型ストレージエンジンTiFlashおよび演算エンジンMPPの安定性とパフォーマンスの向上を継続する。** - MPPエンジンへの関数委譲をさらに強化する： @@ -114,7 +114,7 @@ TiDB バージョン: 5.4.0 - リソース利用率を向上させるための弾性スレッドプール機能を導入（実験的） - - TiKVからデータを複製する際に、行ベースのstorage形式から列ベースのstorage形式へのデータ変換の効率を向上させ、データ複製の全体的なパフォーマンスを50%向上させました。 + - TiKVからデータを複製する際に、行ベースのストレージ形式から列ベースのストレージ形式へのデータ変換の効率を向上させ、データ複製の全体的なパフォーマンスを50%向上させました。 - 一部の設定項目のデフォルト値を調整することで、 TiFlashのパフォーマンスと安定性を向上させることができます。HTAPハイブリッドロード環境では、単一テーブルに対する単純なクエリのパフォーマンスが最大20%向上します。 @@ -153,13 +153,13 @@ TiDB バージョン: 5.4.0 - インデックス マージは、選言正規形 (X 1 ⋁ X 2 ⋁ …X n ) のみをサポートします。つまり、この機能は`WHERE`句のフィルタリング条件が`OR`で接続されている場合にのみ機能します。 - - 新規にデプロイされたv5.4.0以降のTiDBクラスタでは、この機能はデフォルトで有効になっています。以前のバージョンからアップグレードされたv5.4.0以降のTiDBクラスタでは、この機能はアップグレード前の設定を継承し、必要に応じて設定を変更できます（v4.0より前のTiDBクラスタでは、この機能は存在せず、デフォルトで無効になっています）。 + - 新規にデプロイされたv5.4.0以降のTiDBクラスターでは、この機能はデフォルトで有効になっています。以前のバージョンからアップグレードされたv5.4.0以降のTiDBクラスターでは、この機能はアップグレード前の設定を継承し、必要に応じて設定を変更できます（v4.0より前のTiDBクラスターでは、この機能は存在せず、デフォルトで無効になっています）。 [ユーザー向けドキュメント](/explain-index-merge.md) - **Raft Engineのサポート（実験的）** - TiKVのログstorageエンジンとして[Raft Engine](https://github.com/tikv/raft-engine)使用をサポートします。RocksDBと比較して、 Raft EngineはTiKVのI/O書き込みトラフィックを最大40%、CPU使用率を10%削減し、特定の負荷条件下ではフォアグラウンドスループットを約5%向上させ、テールレイテンシーを20%削減します。さらに、 Raft Engineはログリサイクルの効率を向上させ、極端な条件下でのログ蓄積の問題を解決します。 + TiKVのログストレージエンジンとして[Raft Engine](https://github.com/tikv/raft-engine)使用をサポートします。RocksDBと比較して、 Raft EngineはTiKVのI/O書き込みトラフィックを最大40%、CPU使用率を10%削減し、特定の負荷条件下ではフォアグラウンドスループットを約5%向上させ、テールレイテンシーを20%削減します。さらに、 Raft Engineはログリサイクルの効率を向上させ、極端な条件下でのログ蓄積の問題を解決します。 Raft Engine はまだ実験的機能であり、デフォルトでは無効になっています。v5.4.0 のRaft Engineのデータ形式は、以前のバージョンと互換性がないことに注意してください。クラスターをアップグレードする前に、すべての TiKV ノードでRaft Engine が無効になっていることを確認する必要があります。Raft Raft Engine はv5.4.0 以降のバージョンでのみ使用することをお勧めします。 @@ -195,17 +195,17 @@ TiDB バージョン: 5.4.0 ### 高可用性とディザスタリカバリ {#high-availability-and-disaster-recovery} -- **バックアップタスクがクラスタに与える影響を軽減する** +- **バックアップタスクがクラスターに与える影響を軽減する** - バックアップと復元 (BR) では、自動調整機能 (デフォルトで有効) が導入されました。この機能は、クラスタのリソース使用状況を監視し、バックアップタスクで使用されるスレッド数を調整することで、クラスタに対するバックアップタスクの影響を軽減します。場合によっては、バックアップ用のクラスタハードウェアリソースを増やし、自動調整機能を有効にすると、クラスタに対するバックアップタスクの影響を 10% 以下に抑えることができます。 + バックアップと復元 (BR) では、自動調整機能 (デフォルトで有効) が導入されました。この機能は、クラスターのリソース使用状況を監視し、バックアップタスクで使用されるスレッド数を調整することで、クラスターに対するバックアップタスクの影響を軽減します。場合によっては、バックアップ用のクラスターハードウェアリソースを増やし、自動調整機能を有効にすると、クラスターに対するバックアップタスクの影響を 10% 以下に抑えることができます。 [ユーザー向けドキュメント](/br/br-auto-tune.md) -- **バックアップのターゲットstorageとしてAzure Blob Storageをサポートする** +- **バックアップのターゲットストレージとしてAzure Blob Storageをサポートする** - Backup & Restore (BR) は、リモートバックアップstorageとして Azure Blob Storage をサポートしています。Azure クラウドに TiDB をデプロイしている場合、クラスタデータを Azure Blob Storage サービスにバックアップできるようになりました。 + Backup & Restore (BR) は、リモートバックアップストレージとして Azure Blob Storage をサポートしています。Azure クラウドに TiDB をデプロイしている場合、クラスターデータを Azure Blob Storage サービスにバックアップできるようになりました。 - [ユーザー向けドキュメント](/br/backup-and-restore-storages.md) + [ユーザー向けドキュメント](/br/backup-and-restore-ストレージs.md) ### データ移行 {#data-migration} @@ -217,7 +217,7 @@ TiDB バージョン: 5.4.0 - **TiDB Lightningは、並列インポート用のメタ情報を格納するスキーマ名を導入しました。** - TiDB Lightning、 `meta-schema-name`という構成項目が導入されました。並列インポートモードでは、このパラメータは、ターゲットクラスタ内の各TiDB Lightningインスタンスのメタ情報を格納するスキーマ名を指定します。デフォルト値は「lightning_metadata」です。このパラメータに設定する値は、同じ並列インポートに参加する各TiDB Lightningインスタンスで同じである必要があります。そうでない場合、インポートされたデータの正確性が保証されません。 + TiDB Lightning、 `meta-schema-name`という構成項目が導入されました。並列インポートモードでは、このパラメータは、ターゲットクラスター内の各TiDB Lightningインスタンスのメタ情報を格納するスキーマ名を指定します。デフォルト値は「lightning_metadata」です。このパラメータに設定する値は、同じ並列インポートに参加する各TiDB Lightningインスタンスで同じである必要があります。そうでない場合、インポートされたデータの正確性が保証されません。 [ユーザー向けドキュメント](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) @@ -235,7 +235,7 @@ TiDB バージョン: 5.4.0 - リレーログの状態を`source`にバインドします。 `source`どの DM-worker に移行されても、有効または無効の元の状態を維持します。 - - リレーログのstorageパスをDM-workerの設定ファイルに移動します。 + - リレーログのストレージパスをDM-workerの設定ファイルに移動します。 [ユーザー向けドキュメント](/dm/relay-log.md) @@ -270,7 +270,7 @@ TiDB バージョン: 5.4.0 - **TiCDCがクラスターに与える影響を最適化する** - TiCDCを使用すると、TiDBクラスタのパフォーマンスへの影響を大幅に軽減できます。テスト環境では、TiCDCがTiDBに与えるパフォーマンスへの影響を5%未満に抑えることが可能です。 + TiCDCを使用すると、TiDBクラスターのパフォーマンスへの影響を大幅に軽減できます。テスト環境では、TiCDCがTiDBに与えるパフォーマンスへの影響を5%未満に抑えることが可能です。 ### 導入と保守 {#deployment-and-maintenance} @@ -284,7 +284,7 @@ TiDB バージョン: 5.4.0 継続的プロファイリングはデフォルトでは無効になっており、TiDBダッシュボードで有効にすることができます。 - 継続的プロファイリングは、 TiUP v1.9.0以降、またはTiDB Operator v1.3.0以降を使用してデプロイまたはアップグレードされたクラスタに適用可能です。 + 継続的プロファイリングは、 TiUP v1.9.0以降、またはTiDB Operator v1.3.0以降を使用してデプロイまたはアップグレードされたクラスターに適用可能です。 [ユーザー向けドキュメント](/dashboard/continuous-profiling.md) @@ -294,7 +294,7 @@ TiDB バージョン: 5.4.0 - キャッシュされたクエリ プランをクリアするための`ADMIN {SESSION | INSTANCE | GLOBAL} PLAN_CACHE`構文をサポート [#30370](https://github.com/pingcap/tidb/pull/30370) -- ティクヴ +- TiKV - コプロセッサーがページングAPIをサポートし、リクエストをストリームのように処理する [#11448](https://github.com/tikv/tikv/issues/11448) - 読み取り操作が二次ロックの解決を待つ必要がないように、 `read-through-lock`をサポートする [#11402](https://github.com/tikv/tikv/issues/11402) @@ -363,7 +363,7 @@ TiDB バージョン: 5.4.0 - `INSERT ... SELECT ... ON DUPLICATE KEY UPDATE`ステートメントを実行するとpanicが発生する問題を修正しました [#28078](https://github.com/pingcap/tidb/issues/28078) - INDEX HASH JOIN が`send on closed channel`エラーを返す問題を修正します [#31129](https://github.com/pingcap/tidb/issues/31129) -- ティクヴ +- TiKV - MVCC削除レコードがGCによってクリアされない問題を修正しました [#11217](https://github.com/tikv/tikv/issues/11217) - 悲観的トランザクションモードでプリライト要求を再試行すると、まれにデータ不整合のリスクが発生する可能性がある問題を修正しました [#11187](https://github.com/tikv/tikv/issues/11187) @@ -394,7 +394,7 @@ TiDB バージョン: 5.4.0 - バックアップと復元 (BR) - リストア操作完了後にリージョン分布が不均一になる可能性がある問題を修正 [#30425](https://github.com/pingcap/tidb/issues/30425) - - `'/'`バックアップstorageとして使用している場合、エンドポイントで`minio`指定できない問題を修正しました [#30104](https://github.com/pingcap/tidb/issues/30104) + - `'/'`バックアップストレージとして使用している場合、エンドポイントで`minio`指定できない問題を修正しました [#30104](https://github.com/pingcap/tidb/issues/30104) - システムテーブルの同時バックアップによってテーブル名の更新が失敗し、システムテーブルを復元できない問題を修正しました [#29710](https://github.com/pingcap/tidb/issues/29710) - TiCDC diff --git a/releases/release-5.4.1.md b/releases/release-5.4.1.md index 8857888507f78..277eacfdf6238 100644 --- a/releases/release-5.4.1.md +++ b/releases/release-5.4.1.md @@ -114,7 +114,7 @@ TiDB v5.4.1では、製品設計上の互換性に関する変更は行われて - クエリがキャンセルされたときに発生するメモリリークの問題を修正しました[＃4098](https://github.com/pingcap/tiflash/issues/4098) - `DATETIME`を`DECIMAL` [＃4151](https://github.com/pingcap/tiflash/issues/4151)にキャストするときに発生する誤った結果を修正 - `Snapshot`複数の DDL 操作[＃4072](https://github.com/pingcap/tiflash/issues/4072)と同時に適用された場合にTiFlashpanicが発生する可能性がある問題を修正しました - - 無効なstorageディレクトリ設定が予期しない動作を引き起こすバグを修正[＃4093](https://github.com/pingcap/tiflash/issues/4093) + - 無効なストレージディレクトリ設定が予期しない動作を引き起こすバグを修正[＃4093](https://github.com/pingcap/tiflash/issues/4093) - 一部の例外が適切に処理されないバグを修正[＃4101](https://github.com/pingcap/tiflash/issues/4101) - `INT`を`DECIMAL`にキャストするとオーバーフローが発生する可能性がある問題を修正しました[＃3920](https://github.com/pingcap/tiflash/issues/3920) - 複数値式[＃4016](https://github.com/pingcap/tiflash/issues/4016)で`IN`の結果が正しくない問題を修正 diff --git a/releases/release-5.4.3.md b/releases/release-5.4.3.md index 0ce9dc08cac32..6a1dc395c1faa 100644 --- a/releases/release-5.4.3.md +++ b/releases/release-5.4.3.md @@ -52,7 +52,7 @@ TiDB バージョン: 5.4.3 - TiKV - - PDリーダーの切り替え後またはPDの再起動後にクラスタ内でSQL実行エラーが継続する問題を修正[＃12934](https://github.com/tikv/tikv/issues/12934) + - PDリーダーの切り替え後またはPDの再起動後にクラスター内でSQL実行エラーが継続する問題を修正[＃12934](https://github.com/tikv/tikv/issues/12934) - 原因：この問題は、TiKVのバグが原因で発生します。このバグにより、ハートビート要求が失敗した後、TiKVはPDクライアントに再接続するまで、PDクライアントへのハートビート情報の送信を再試行しません。その結果、障害が発生したTiKVノードのリージョン情報が古くなり、TiDBは最新のリージョン情報を取得できず、SQL実行エラーが発生します。 - 影響を受けるバージョン: v5.3.2 および v5.4.2。この問題は v5.3.3 および v5.4.3 で修正されています。v5.4.2 をご利用の場合は、クラスターを v5.4.3 にアップグレードできます。 - 回避策: アップグレードに加えて、送信するリージョンハートビートがなくなるまで、リージョンハートビートを PD に送信できない TiKV ノードを再起動することもできます。 @@ -64,7 +64,7 @@ TiDB バージョン: 5.4.3 - PDがダッシュボードプロキシリクエストを正しく処理できない問題を修正[＃5321](https://github.com/tikv/pd/issues/5321) - PDリーダー移転後に削除した墓石ストアが再び表示される問題を修正[＃4941](https://github.com/tikv/pd/issues/4941) - - TiFlash学習者レプリカが作成されない可能性がある問題を修正[＃5401](https://github.com/tikv/pd/issues/5401) + - TiFlashラーナーレプリカが作成されない可能性がある問題を修正[＃5401](https://github.com/tikv/pd/issues/5401) - TiFlash @@ -96,7 +96,7 @@ TiDB バージョン: 5.4.3 - バックアップと復元 (BR) - - 外部storage[＃37469](https://github.com/pingcap/tidb/issues/37469)の認証キーに特殊文字が含まれている場合にバックアップと復元が失敗する可能性がある問題を修正しました + - 外部ストレージ[＃37469](https://github.com/pingcap/tidb/issues/37469)の認証キーに特殊文字が含まれている場合にバックアップと復元が失敗する可能性がある問題を修正しました - 復元中に同時実行が大きすぎる設定になっているために領域のバランスが取れていない問題を修正[＃37549](https://github.com/pingcap/tidb/issues/37549) - Dumpling diff --git a/releases/release-6.0.0-dmr.md b/releases/release-6.0.0-dmr.md index a5adcacf25e9d..daaea519c3d0c 100644 --- a/releases/release-6.0.0-dmr.md +++ b/releases/release-6.0.0-dmr.md @@ -112,7 +112,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - クエリプッシュダウンの改善 - TiDBは、コンピューティングとstorageを分離するネイティブアーキテクチャを採用しており、演算子のプッシュダウンによる無効なデータのフィルタリングをサポートしています。これにより、TiDBとTiKV間のデータ転送が大幅に削減され、クエリ効率が向上します。v6.0.0では、TiDBはより多くの式と`BIT`データ型をTiKVにプッシュダウンできるようになり、式とデータ型の計算におけるクエリ効率が向上しています。 + TiDBは、コンピューティングとストレージを分離するネイティブアーキテクチャを採用しており、演算子のプッシュダウンによる無効なデータのフィルタリングをサポートしています。これにより、TiDBとTiKV間のデータ転送が大幅に削減され、クエリ効率が向上します。v6.0.0では、TiDBはより多くの式と`BIT`データ型をTiKVにプッシュダウンできるようになり、式とデータ型の計算におけるクエリ効率が向上しています。 [ユーザードキュメント](/functions-and-operators/expressions-pushed-down.md) [＃30738](https://github.com/pingcap/tidb/issues/30738) @@ -148,7 +148,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - 実行計画のベースラインキャプチャを強化する - テーブル名、頻度、ユーザー名などのディメンションを含むブロックリストを追加することで、実行計画のベースラインキャプチャの使いやすさを向上させました。キャッシュバインディングのメモリ管理を最適化する新しいアルゴリズムを導入しました。ベースラインキャプチャを有効にすると、ほとんどのOLTPクエリのバインディングが自動的に作成されます。バインドされたステートメントの実行計画は固定されるため、実行計画の変更によるパフォーマンスの問題を回避できます。ベースラインキャプチャは、メジャーバージョンのアップグレードやクラスタの移行などのシナリオに適用でき、実行計画の回帰によって引き起こされるパフォーマンスの問題を軽減するのに役立ちます。 + テーブル名、頻度、ユーザー名などのディメンションを含むブロックリストを追加することで、実行計画のベースラインキャプチャの使いやすさを向上させました。キャッシュバインディングのメモリ管理を最適化する新しいアルゴリズムを導入しました。ベースラインキャプチャを有効にすると、ほとんどのOLTPクエリのバインディングが自動的に作成されます。バインドされたステートメントの実行計画は固定されるため、実行計画の変更によるパフォーマンスの問題を回避できます。ベースラインキャプチャは、メジャーバージョンのアップグレードやクラスターの移行などのシナリオに適用でき、実行計画の回帰によって引き起こされるパフォーマンスの問題を軽減するのに役立ちます。 [ユーザードキュメント](/sql-plan-management.md#baseline-capturing) [＃32466](https://github.com/pingcap/tidb/issues/32466) @@ -205,9 +205,9 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 [ユーザードキュメント](/dm/dm-manage-schema.md) -- Amazon S3への完全なデータstorageをサポート +- Amazon S3への完全なデータストレージをサポート - DMが全データ移行タスクまたは完全データ移行タスクを実行する場合、上流からの全データを保存するために十分なハードディスク容量が必要です。EBSと比較して、Amazon S3はほぼ無制限のstorageを低コストで提供します。DMはAmazon S3をダンプディレクトリとして設定できるようになりました。つまり、全データ移行タスクまたは完全データ移行タスクを実行する際に、S3に全データを保存できます。 + DMが全データ移行タスクまたは完全データ移行タスクを実行する場合、上流からの全データを保存するために十分なハードディスク容量が必要です。EBSと比較して、Amazon S3はほぼ無制限のストレージを低コストで提供します。DMはAmazon S3をダンプディレクトリとして設定できるようになりました。つまり、全データ移行タスクまたは完全データ移行タスクを実行する際に、S3に全データを保存できます。 [ユーザードキュメント](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced) @@ -235,13 +235,13 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - 100,000 個のテーブルを同時に複製することをサポート - TiCDCはデータ処理フローを最適化することで、各テーブルの増分データ処理におけるリソース消費を削減し、大規模クラスタにおけるデータレプリケーションの安定性と効率性を大幅に向上させます。社内テストの結果、TiCDCは10万テーブルの同時レプリケーションを安定的にサポートできることが示されています。 + TiCDCはデータ処理フローを最適化することで、各テーブルの増分データ処理におけるリソース消費を削減し、大規模クラスターにおけるデータレプリケーションの安定性と効率性を大幅に向上させます。社内テストの結果、TiCDCは10万テーブルの同時レプリケーションを安定的にサポートできることが示されています。 ### 展開と保守 {#deployment-and-maintenance} - 新しい照合順序ルールをデフォルトで有効にする - TiDB v4.0以降、大文字小文字を区別しない、アクセントを区別しない、およびパディングルールにおいてMySQLと同様に動作する新しい照合順序ルールがTiDBでサポートされています。新しい照合順序ルールは`new_collations_enabled_on_first_bootstrap`パラメータで制御されますが、このパラメータはデフォルトで無効になっています。v6.0以降、TiDBは新しい照合順序ルールをデフォルトで有効にします。この設定はTiDBクラスタの初期化時にのみ有効になることに注意してください。 + TiDB v4.0以降、大文字小文字を区別しない、アクセントを区別しない、およびパディングルールにおいてMySQLと同様に動作する新しい照合順序ルールがTiDBでサポートされています。新しい照合順序ルールは`new_collations_enabled_on_first_bootstrap`パラメータで制御されますが、このパラメータはデフォルトで無効になっています。v6.0以降、TiDBは新しい照合順序ルールをデフォルトで有効にします。この設定はTiDBクラスターの初期化時にのみ有効になることに注意してください。 [ユーザードキュメント](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap) @@ -259,7 +259,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - PingCAPクリニック診断サービス（テクニカルプレビュー版） - PingCAPクリニック は、 TiDB クラスタ向けの診断サービスです。このサービスは、クラスタの問題をリモートでトラブルシューティングし、ローカルでクラスタの状態を迅速に確認するのに役立ちます。PingCAP PingCAPクリニックを利用することで、TiDB クラスタのライフサイクル全体にわたる安定した運用を確保し、潜在的な問題を予測し、問題発生の可能性を低減し、クラスタの問題を迅速にトラブルシューティングできます。 + PingCAPクリニック は、 TiDB クラスター向けの診断サービスです。このサービスは、クラスターの問題をリモートでトラブルシューティングし、ローカルでクラスターの状態を迅速に確認するのに役立ちます。PingCAP PingCAPクリニックを利用することで、TiDB クラスターのライフサイクル全体にわたる安定した運用を確保し、潜在的な問題を予測し、問題発生の可能性を低減し、クラスターの問題を迅速にトラブルシューティングできます。 クラスターの問題のトラブルシューティングのために PingCAP テクニカル サポートにリモート アシスタンスを依頼する場合、 PingCAPクリニックサービスを使用して診断データを収集およびアップロードすることで、トラブルシューティングの効率を向上させることができます。 @@ -269,7 +269,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 TiDB Enterprise Manager (TiEM) は、TiDB データベースに基づくエンタープライズ レベルのデータベース管理プラットフォームであり、ユーザーがセルフホスト環境またはパブリック クラウド環境で TiDB クラスターを管理できるようにすることを目的としています。 - TiEMは、TiDBクラスタのライフサイクル全体を視覚的に管理するだけでなく、パラメータ管理、バージョンアップ、クラスタクローン、アクティブ/スタンバイクラスタ切り替え、データのインポート/エクスポート、データレプリケーション、データのバックアップ/リストアといったワンストップサービスも提供します。TiEMは、TiDBにおけるDevOpsの効率を向上させ、企業のDevOpsコストを削減します。 + TiEMは、TiDBクラスターのライフサイクル全体を視覚的に管理するだけでなく、パラメータ管理、バージョンアップ、クラスタークローン、アクティブ/スタンバイクラスター切り替え、データのインポート/エクスポート、データレプリケーション、データのバックアップ/リストアといったワンストップサービスも提供します。TiEMは、TiDBにおけるDevOpsの効率を向上させ、企業のDevOpsコストを削減します。 現在、TiEMは[TiDBエンタープライズ](https://www.pingcap.com/tidb-enterprise/)エディションのみで提供されています。TiEMを入手するには、 [TiDBエンタープライズ](https://www.pingcap.com/tidb-enterprise/)ページからお問い合わせください。 @@ -289,9 +289,9 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。
変数名タイプを変更説明
placement_checks削除済みDDL ステートメントがSQL の配置ルールで指定された配置ルールを検証するかどうかを制御します。tidb_placement_mode に置き換えられtidb_placement_modeた。
tidb_enable_alter_placement削除済みSQL で配置ルールを有効にするかどうかを制御します。
tidb_mem_quota_hashjoin
tidb_mem_quota_indexlookupjoin
tidb_mem_quota_indexlookupreader
tidb_mem_quota_mergejoin
tidb_mem_quota_sort
tidb_mem_quota_topn		削除済みv5.0以降、これらの変数はtidb_mem_quota_queryに置き換えられ、システム変数ドキュメントから削除されました。互換性を確保するため、これらの変数はソースコードに残されていました。TiDB 6.0.0以降、これらの変数はコードからも削除されています。
tidb_enable_mutation_checker新しく追加されたミューテーションチェッカーを有効にするかどうかを制御します。デフォルト値はONです。v6.0.0より前のバージョンからアップグレードする既存のクラスターの場合、ミューテーションチェッカーはデフォルトで無効になっています。
tidb_ignore_prepared_cache_close_stmt新しく追加された準備済みステートメントを閉じるコマンドを無視するかどうかを制御します。デフォルト値はOFFです。
tidb_mem_quota_binding_cache新しく追加されたキャッシュ保持バインディングのメモリ使用量のしきい値を設定します。デフォルト値は67108864 （64 MiB）です。
tidb_placement_mode新しく追加されたDDL文がSQLの配置ルールで指定された配置ルールを無視するかどうかを制御します。デフォルト値はstrictで、DDL文は配置ルールを無視しません。
tidb_rc_read_check_ts新しく追加された
  • トランザクション内の読み取りステートメントのレイテンシーを最適化します。読み取り/書き込みの競合が深刻な場合、この変数をオンにするとオーバーヘッドとレイテンシーが増加し、パフォーマンスが低下します。デフォルト値はoffです。
  • この変数はまだreplica-readと互換性がありません。読み取りリクエストでtidb_rc_read_check_tsがオンになっている場合、 replica-read を使用できない可能性があります。両方の変数を同時にオンにしないでください。
tidb_sysdate_is_now新しく追加されたSYSDATE関数をNOW関数に置き換えるかどうかを制御します。この設定項目は、MySQLオプションsysdate-is-nowと同じ効果があります。デフォルト値はOFFです。
tidb_table_cache_lease新しく追加されたテーブルキャッシュのリース時間を秒単位で制御します。デフォルト値は3です。
tidb_top_sql_max_meta_count新しく追加されたTop SQLによって1分間に収集されるSQL文タイプの最大数を制御します。デフォルト値は5000です。
tidb_top_sql_max_time_series_count新しく追加された負荷に最も寄与するSQL文（つまり、上位N文）を1分あたりにTop SQLで記録できる回数を制御します。デフォルト値は100です。
tidb_txn_assertion_level新しく追加されたアサーションレベルを制御します。アサーションは、データとインデックス間の整合性チェックであり、トランザクションのコミットプロセスにおいて、書き込まれるキーが存在するかどうかを確認します。デフォルトでは、ほとんどのチェック項目が有効になっており、パフォーマンスへの影響はほとんどありません。v6.0.0より前のバージョンからアップグレードした既存のクラスターでは、このチェックはデフォルトで無効になっています。
-### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} +### 設定ファイルのパラメータ {#configuration-file-parameters} -
コンフィグレーションファイルコンフィグレーションタイプを変更説明
TiDBstmt-summary.enable
stmt-summary.enable-internal-query
stmt-summary.history-size
stmt-summary.max-sql-length
stmt-summary.max-stmt-count
stmt-summary.refresh-interval		削除済みステートメントサマリーテーブルに関連するコンフィグレーション。これらの設定項目はすべて削除されました。ステートメントサマリーテーブルを制御するには、SQL変数を使用する必要があります。
TiDBnew_collations_enabled_on_first_bootstrap修正済み新しい照合順序のサポートを有効にするかどうかを制御します。バージョン6.0以降、デフォルト値はfalseからtrueに変更されました。この設定項目は、クラスターが初めて初期化されたときにのみ有効になります。最初のブートストラップ後は、この設定項目を使用して新しい照合順序順序フレームワークを有効化または無効化することはできません。
TiKVbackup.num-threads修正済み値の範囲は[1, CPU]に変更されます。
TiKVraftstore.apply-max-batch-size修正済み最大値は10240に変更されます。
TiKVraftstore.raft-max-size-per-msg修正済み最小値が0から0より大きい値に変更されます。
最大値は3GBに設定されています。
単位がMBからKB|MB|GBに変更されます。
TiKVraftstore.store-max-batch-size修正済み最大値は10240に設定されています。
TiKVreadpool.unified.max-thread-count修正済み調整可能な範囲は[min-thread-count, MAX(4, CPU)]に変更されます。
TiKVrocksdb.enable-pipelined-write修正済みデフォルト値がtrueからfalseに変更されました。この設定を有効にすると、従来のパイプライン書き込みが使用されます。この設定を無効にすると、新しいパイプラインコミットメカニズムが使用されます。
TiKVrocksdb.max-background-flushes修正済みCPU コア数が 10 の場合、デフォルト値は3です。
CPU コア数が 8 の場合、デフォルト値は2です。
TiKVrocksdb.max-background-jobs修正済みCPU コア数が 10 の場合、デフォルト値は9です。
CPU コア数が 8 の場合、デフォルト値は7です。
TiFlashprofiles.default.dt_enable_logical_split修正済みDeltaTreeストレージエンジンのセグメントが論理分割を使用するかどうかを決定します。デフォルト値はtrueからfalseに変更されます。
TiFlashprofiles.default.enable_elastic_threadpool修正済みエラスティックスレッドプールを有効にするかどうかを制御します。デフォルト値はfalseからtrueに変更されます。
TiFlashstorage.format_version修正済みTiFlashのデータ検証機能を制御します。デフォルト値は2から3に変更されます。
format_version 3に設定すると、ハードウェア障害による誤った読み取りを回避するために、すべてのTiFlashデータの読み取り操作に対して一貫性チェックが実行されます。
新しい形式のバージョンは、v5.4 より前のバージョンにそのままダウングレードすることはできないことに注意してください。
TiDBpessimistic-txn.pessimistic-auto-commit新しく追加された悲観的トランザクション モードがグローバルに有効になっている場合 ( tidb_txn_mode='pessimistic' )、自動コミット トランザクションが使用するトランザクション モードを決定します。
TiKVpessimistic-txn.in-memory新しく追加されたインメモリ悲観的ロックを有効にするかどうかを制御します。この機能を有効にすると、悲観的トランザクションは、悲観的ロックをディスクに書き込んだり他のレプリカに複製したりするのではなく、可能な限りTiKVメモリに悲観的ロックを保存します。これにより、悲観的トランザクションのパフォーマンスが向上しますが、悲観的ロックが失われる可能性がわずかながらあり、その結果、悲観的トランザクションがコミットに失敗する可能性があります。デフォルト値はtrueです。
TiKVquota新しく追加されたフロントエンドリクエストが占有するリソースを制限するQuota Limiter関連の設定項目を追加しました。Quota Limiterは実験的機能であり、デフォルトでは無効になっています。新しいクォータ関連の設定項目は、 foreground-cpu-time 、 foreground-write-bandwidth 、 foreground-read-bandwidth 、 max-delay-durationです。
TiFlashprofiles.default.dt_compression_method新しく追加されたTiFlashの圧縮アルゴリズムを指定します。オプションの値はLZ4 、 zstd 、 LZ4HCで、いずれも大文字と小文字は区別されません。デフォルト値はLZ4です。
TiFlashprofiles.default.dt_compression_level新しく追加されたTiFlashの圧縮レベルを指定します。デフォルト値は1です。
DM loaders.<name>.import-mode新しく追加されたフルインポートフェーズにおけるインポートモード。v6.0以降、DMはフルインポートフェーズでTiDB LightningのTiDBバックエンドモードを使用してデータをインポートします。以前のLoaderコンポーネントは使用されなくなりました。これは内部的な置き換えであり、日常業務への影響は見られません。
デフォルト値はsqlに設定されており、これはtidb-backendモードを使用することを意味します。稀に、tidb-backendは完全な互換性を持たない場合があります。このパラメータをloaderに設定することで、Loaderモードにフォールバックできます。
DM loaders.<name>.on-duplicate新しく追加されたフルインポートフェーズで競合を解決する方法を指定します。デフォルト値はreplaceで、これは新しいデータを使用して既存のデータを置き換えることを意味します。
TiCDC dial-timeout新しく追加された下流のKafkaとの接続を確立する際のタイムアウト。デフォルト値は10sです。
TiCDC read-timeout新しく追加された下流のKafkaから返されるレスポンスを取得する際のタイムアウト。デフォルト値は10sです。
TiCDC write-timeout新しく追加された下流のKafkaにリクエストを送信する際のタイムアウト。デフォルト値は10sです。
+
設定ファイル設定タイプを変更説明
TiDBstmt-summary.enable
stmt-summary.enable-internal-query
stmt-summary.history-size
stmt-summary.max-sql-length
stmt-summary.max-stmt-count
stmt-summary.refresh-interval		削除済みステートメントサマリーテーブルに関連する設定。これらの設定項目はすべて削除されました。ステートメントサマリーテーブルを制御するには、SQL変数を使用する必要があります。
TiDBnew_collations_enabled_on_first_bootstrap修正済み新しい照合順序のサポートを有効にするかどうかを制御します。バージョン6.0以降、デフォルト値はfalseからtrueに変更されました。この設定項目は、クラスターが初めて初期化されたときにのみ有効になります。最初のブートストラップ後は、この設定項目を使用して新しい照合順序順序フレームワークを有効化または無効化することはできません。
TiKVbackup.num-threads修正済み値の範囲は[1, CPU]に変更されます。
TiKVraftstore.apply-max-batch-size修正済み最大値は10240に変更されます。
TiKVraftstore.raft-max-size-per-msg修正済み最小値が0から0より大きい値に変更されます。
最大値は3GBに設定されています。
単位がMBからKB|MB|GBに変更されます。
TiKVraftstore.store-max-batch-size修正済み最大値は10240に設定されています。
TiKVreadpool.unified.max-thread-count修正済み調整可能な範囲は[min-thread-count, MAX(4, CPU)]に変更されます。
TiKVrocksdb.enable-pipelined-write修正済みデフォルト値がtrueからfalseに変更されました。この設定を有効にすると、従来のパイプライン書き込みが使用されます。この設定を無効にすると、新しいパイプラインコミットメカニズムが使用されます。
TiKVrocksdb.max-background-flushes修正済みCPU コア数が 10 の場合、デフォルト値は3です。
CPU コア数が 8 の場合、デフォルト値は2です。
TiKVrocksdb.max-background-jobs修正済みCPU コア数が 10 の場合、デフォルト値は9です。
CPU コア数が 8 の場合、デフォルト値は7です。
TiFlashprofiles.default.dt_enable_logical_split修正済みDeltaTreeストレージエンジンのセグメントが論理分割を使用するかどうかを決定します。デフォルト値はtrueからfalseに変更されます。
TiFlashprofiles.default.enable_elastic_threadpool修正済みエラスティックスレッドプールを有効にするかどうかを制御します。デフォルト値はfalseからtrueに変更されます。
TiFlashストレージ.format_version修正済みTiFlashのデータ検証機能を制御します。デフォルト値は2から3に変更されます。
format_version 3に設定すると、ハードウェア障害による誤った読み取りを回避するために、すべてのTiFlashデータの読み取り操作に対して一貫性チェックが実行されます。
新しい形式のバージョンは、v5.4 より前のバージョンにそのままダウングレードすることはできないことに注意してください。
TiDBpessimistic-txn.pessimistic-auto-commit新しく追加された悲観的トランザクション モードがグローバルに有効になっている場合 ( tidb_txn_mode='pessimistic' )、自動コミット トランザクションが使用するトランザクション モードを決定します。
TiKVpessimistic-txn.in-memory新しく追加されたインメモリ悲観的ロックを有効にするかどうかを制御します。この機能を有効にすると、悲観的トランザクションは、悲観的ロックをディスクに書き込んだり他のレプリカに複製したりするのではなく、可能な限りTiKVメモリに悲観的ロックを保存します。これにより、悲観的トランザクションのパフォーマンスが向上しますが、悲観的ロックが失われる可能性がわずかながらあり、その結果、悲観的トランザクションがコミットに失敗する可能性があります。デフォルト値はtrueです。
TiKVquota新しく追加されたフロントエンドリクエストが占有するリソースを制限するQuota Limiter関連の設定項目を追加しました。Quota Limiterは実験的機能であり、デフォルトでは無効になっています。新しいクォータ関連の設定項目は、 foreground-cpu-time 、 foreground-write-bandwidth 、 foreground-read-bandwidth 、 max-delay-durationです。
TiFlashprofiles.default.dt_compression_method新しく追加されたTiFlashの圧縮アルゴリズムを指定します。オプションの値はLZ4 、 zstd 、 LZ4HCで、いずれも大文字と小文字は区別されません。デフォルト値はLZ4です。
TiFlashprofiles.default.dt_compression_level新しく追加されたTiFlashの圧縮レベルを指定します。デフォルト値は1です。
DM loaders.<name>.import-mode新しく追加されたフルインポートフェーズにおけるインポートモード。v6.0以降、DMはフルインポートフェーズでTiDB LightningのTiDBバックエンドモードを使用してデータをインポートします。以前のLoaderコンポーネントは使用されなくなりました。これは内部的な置き換えであり、日常業務への影響は見られません。
デフォルト値はsqlに設定されており、これはtidb-backendモードを使用することを意味します。稀に、tidb-backendは完全な互換性を持たない場合があります。このパラメータをloaderに設定することで、Loaderモードにフォールバックできます。
DM loaders.<name>.on-duplicate新しく追加されたフルインポートフェーズで競合を解決する方法を指定します。デフォルト値はreplaceで、これは新しいデータを使用して既存のデータを置き換えることを意味します。
TiCDC dial-timeout新しく追加された下流のKafkaとの接続を確立する際のタイムアウト。デフォルト値は10sです。
TiCDC read-timeout新しく追加された下流のKafkaから返されるレスポンスを取得する際のタイムアウト。デフォルト値は10sです。
TiCDC write-timeout新しく追加された下流のKafkaにリクエストを送信する際のタイムアウト。デフォルト値は10sです。
### その他 {#others} @@ -369,7 +369,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - `raftstore.apply_max_batch_size`と`raftstore.store_max_batch_size` [＃11982](https://github.com/tikv/tikv/issues/11982)の動的変更をサポート - RawKV V2は`raw_get`または`raw_scan`リクエストを受信すると最新バージョンを返します[＃11965](https://github.com/tikv/tikv/issues/11965) - RCCheckTS一貫性読み取り[＃12097](https://github.com/tikv/tikv/issues/12097)サポート - - `storage.scheduler-worker-pool-size` (スケジューラプールのスレッド数) [＃12067](https://github.com/tikv/tikv/issues/12067)の動的変更をサポート + - `ストレージ.scheduler-worker-pool-size` (スケジューラプールのスレッド数) [＃12067](https://github.com/tikv/tikv/issues/12067)の動的変更をサポート - グローバルフォアグラウンドフローコントローラを使用してCPUと帯域幅の使用を制御し、TiKV [＃11855](https://github.com/tikv/tikv/issues/11855)のパフォーマンス安定性を向上させます。 - `readpool.unified.max-thread-count` (UnifyReadPool のスレッド数) [＃11781](https://github.com/tikv/tikv/issues/11781)の動的変更をサポート - TiKV内部パイプラインを使用してRocksDBパイプラインを置き換え、 `rocksdb.enable-multibatch-write`パラメータ[＃12059](https://github.com/tikv/tikv/issues/12059)廃止します。 @@ -382,8 +382,8 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - TiFlash - - TiFlashファイルの論理分割を禁止し (デフォルト値の`profiles.default.dt_enable_logical_split`を`false`に調整します。詳細については[ユーザードキュメント](/tiflash/tiflash-configuration.md#tiflash-configuration-parameters)を参照してください)、 TiFlash列storageのスペース使用効率を改善して、 TiFlashに同期されたテーブルのスペース占有が TiKV のテーブルのスペース占有と同等になるようにします。 - - 以前のクラスタ管理モジュールをTiDBに統合することで、 TiFlashのクラスタ管理とレプリカレプリケーションのメカニズムを最適化し、小さなテーブルのレプリカ作成を高速化します[＃29924](https://github.com/pingcap/tidb/issues/29924) + - TiFlashファイルの論理分割を禁止し (デフォルト値の`profiles.default.dt_enable_logical_split`を`false`に調整します。詳細については[ユーザードキュメント](/tiflash/tiflash-configuration.md#tiflash-configuration-parameters)を参照してください)、 TiFlash列ストレージのスペース使用効率を改善して、 TiFlashに同期されたテーブルのスペース占有が TiKV のテーブルのスペース占有と同等になるようにします。 + - 以前のクラスター管理モジュールをTiDBに統合することで、 TiFlashのクラスター管理とレプリカレプリケーションのメカニズムを最適化し、小さなテーブルのレプリカ作成を高速化します[＃29924](https://github.com/pingcap/tidb/issues/29924) - ツール @@ -501,7 +501,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - `INT`を`DECIMAL`にキャストするとオーバーフローが発生する可能性がある問題を修正[＃3920](https://github.com/pingcap/tiflash/issues/3920) - 複数値式[＃4016](https://github.com/pingcap/tiflash/issues/4016)で`IN`の結果が正しくない問題を修正 - 日付形式が`'\n'`無効な区切り文字として認識する問題を修正[＃4036](https://github.com/pingcap/tiflash/issues/4036) - - 同時実行性の高いシナリオで学習者の読み取りプロセスに時間がかかりすぎる問題を修正[＃3555](https://github.com/pingcap/tiflash/issues/3555) + - 同時実行性の高いシナリオでラーナーの読み取りプロセスに時間がかかりすぎる問題を修正[＃3555](https://github.com/pingcap/tiflash/issues/3555) - `DATETIME`を`DECIMAL` [＃4151](https://github.com/pingcap/tiflash/issues/4151)にキャストするときに発生する誤った結果を修正 - クエリがキャンセルされたときに発生するメモリリークの問題を修正しました[＃4098](https://github.com/pingcap/tiflash/issues/4098) - エラスティックスレッドプールを有効にするとメモリリークが発生する可能性があるバグを修正[＃4098](https://github.com/pingcap/tiflash/issues/4098) @@ -540,7 +540,7 @@ TiDB v6.0.0 は DMR であり、そのバージョンは 6.0.0-DMR です。 - TiDB Lightning - 一部のインポートタスクにソースファイルが含まれていない場合にTiDB Lightningがメタデータスキーマを削除しない可能性があるバグを修正しました[＃28144](https://github.com/pingcap/tidb/issues/28144) - - ソースファイルとターゲットクラスタ内のテーブル名が異なる場合に発生するpanicを修正[＃31771](https://github.com/pingcap/tidb/issues/31771) + - ソースファイルとターゲットクラスター内のテーブル名が異なる場合に発生するpanicを修正[＃31771](https://github.com/pingcap/tidb/issues/31771) - チェックサムエラー「GCの有効期間がトランザクション期間より短い」を修正[＃32733](https://github.com/pingcap/tidb/issues/32733) - 空のテーブル[＃31797](https://github.com/pingcap/tidb/issues/31797)のチェックに失敗した場合、 TiDB Lightning が停止する問題を修正しました。 diff --git a/releases/release-6.1.0.md b/releases/release-6.1.0.md index 7a4e45e26e1c7..f2a18869bd2ac 100644 --- a/releases/release-6.1.0.md +++ b/releases/release-6.1.0.md @@ -71,9 +71,9 @@ TiDB バージョン: 6.1.0 [ユーザードキュメント](/tune-region-performance.md#use-bucket-to-increase-concurrency) [＃11515](https://github.com/tikv/tikv/issues/11515) -- Use Raft Engine as the default log storage engine +- Use Raft Engine as the default log ストレージ engine - v6.1.0以降、TiDBはログのデフォルトstorageエンジンとしてRaft Engineを使用しています。RocksDBと比較して、 Raft EngineはTiKV I/O書き込みトラフィックを最大40%、CPU使用率を10%削減し、フォアグラウンドスループットを約5%向上させ、特定の負荷下ではテールレイテンシーを20%削減します。 + v6.1.0以降、TiDBはログのデフォルトストレージエンジンとしてRaft Engineを使用しています。RocksDBと比較して、 Raft EngineはTiKV I/O書き込みトラフィックを最大40%、CPU使用率を10%削減し、フォアグラウンドスループットを約5%向上させ、特定の負荷下ではテールレイテンシーを20%削減します。 [ユーザードキュメント](/tikv-configuration-file.md#raft-engine) [＃95](https://github.com/tikv/raft-engine/issues/95) @@ -82,7 +82,7 @@ TiDB バージョン: 6.1.0 - The `LEADING` hint reminds the optimizer to use the specified order as the prefix of join operations. A good prefix of join can quickly reduce the amount of data at the early phase of join and improve the query performance. - `STRAIGHT_JOIN`ヒントは、 `FROM`句内のテーブルの順序と一致する順序でテーブルを結合するようにオプティマイザーに通知します。 - これにより、テーブル結合の順序を固定することができます。ヒントを適切に使用することで、SQLパフォーマンスとクラスタの安定性を効果的に向上させることができます。 + これにより、テーブル結合の順序を固定することができます。ヒントを適切に使用することで、SQLパフォーマンスとクラスターの安定性を効果的に向上させることができます。 [＃29932](https://github.com/pingcap/tidb/issues/29932) [`STRAIGHT_JOIN`](/optimizer-hints.md#straight_join) : [`LEADING`](/optimizer-hints.md#leadingt1_name--tl_name-) @@ -105,25 +105,25 @@ TiDB バージョン: 6.1.0 - SST 破損からの自動回復 - RocksDBがバックグラウンドで破損したSSTファイルを検出すると、TiKVは影響を受けたピアのスケジュールを設定し、他のレプリカを使用してそのデータの復旧を試みます。パラメータ`background-error-recovery-window`を使用して、復旧の最大許容時間を設定できます。復旧操作が指定時間内に完了しない場合、TiKVはpanicになります。この機能は、復旧可能な破損storageを自動的に検出して復旧するため、クラスターの安定性が向上します。 + RocksDBがバックグラウンドで破損したSSTファイルを検出すると、TiKVは影響を受けたピアのスケジュールを設定し、他のレプリカを使用してそのデータの復旧を試みます。パラメータ`background-error-recovery-window`を使用して、復旧の最大許容時間を設定できます。復旧操作が指定時間内に完了しない場合、TiKVはpanicになります。この機能は、復旧可能な破損ストレージを自動的に検出して復旧するため、クラスターの安定性が向上します。 [ユーザードキュメント](/tikv-configuration-file.md#background-error-recovery-window-new-in-v610) [＃10578](https://github.com/tikv/tikv/issues/10578) - 非トランザクションDMLステートメントをサポートする - 大規模データ処理のシナリオでは、大規模なトランザクションを伴う単一のSQL文が、クラスタの安定性とパフォーマンスに悪影響を及ぼす可能性があります。TiDB v6.1.0以降、 `DELETE` SQL文を複数のSQL文に分割してバッチ処理する構文がサポートされています。分割文はトランザクションの原子性と独立性を損なう可能性がありますが、クラスタの安定性を大幅に向上させます。詳細な構文については、 [`BATCH`](/sql-statements/sql-statement-batch.md)参照してください。 + 大規模データ処理のシナリオでは、大規模なトランザクションを伴う単一のSQL文が、クラスターの安定性とパフォーマンスに悪影響を及ぼす可能性があります。TiDB v6.1.0以降、 `DELETE` SQL文を複数のSQL文に分割してバッチ処理する構文がサポートされています。分割文はトランザクションの原子性と独立性を損なう可能性がありますが、クラスターの安定性を大幅に向上させます。詳細な構文については、 [`BATCH`](/sql-statements/sql-statement-batch.md)参照してください。 [User document](/non-transactional-dml.md) - TiDBは最大GC待機時間の設定をサポートしています - TiDB のトランザクションは、マルチバージョン同時実行制御 (MVCC) メカニズムを採用しています。新しく書き込まれたデータが古いデータを上書きする場合、古いデータは置き換えられず、両方のバージョンのデータが格納されます。古いデータはガベージコレクション (GC) タスクによって定期的にクリーンアップされ、storageスペースの再利用を促進してクラスターのパフォーマンスと安定性を向上させます。GC は、デフォルトでは 10 分ごとにトリガーされます。長時間実行トランザクションが対応する履歴データにアクセスできるようにするため、実行中のトランザクションがある場合は GC タスクが遅延されます。GC タスクが無期限に遅延されないように、TiDB は GC タスクの最大遅延時間を制御するシステム変数[`tidb_gc_max_wait_time`](/system-variables.md#tidb_gc_max_wait_time-new-in-v610)導入しています。最大遅延時間を超えると、GC は強制的に実行されます。変数のデフォルト値は 24 時間です。この機能により、GC の待機時間と長時間実行トランザクションの関係を制御でき、クラスターの安定性が向上します。 + TiDB のトランザクションは、マルチバージョン同時実行制御 (MVCC) メカニズムを採用しています。新しく書き込まれたデータが古いデータを上書きする場合、古いデータは置き換えられず、両方のバージョンのデータが格納されます。古いデータはガベージコレクション (GC) タスクによって定期的にクリーンアップされ、ストレージスペースの再利用を促進してクラスターのパフォーマンスと安定性を向上させます。GC は、デフォルトでは 10 分ごとにトリガーされます。長時間実行トランザクションが対応する履歴データにアクセスできるようにするため、実行中のトランザクションがある場合は GC タスクが遅延されます。GC タスクが無期限に遅延されないように、TiDB は GC タスクの最大遅延時間を制御するシステム変数[`tidb_gc_max_wait_time`](/system-variables.md#tidb_gc_max_wait_time-new-in-v610)導入しています。最大遅延時間を超えると、GC は強制的に実行されます。変数のデフォルト値は 24 時間です。この機能により、GC の待機時間と長時間実行トランザクションの関係を制御でき、クラスターの安定性が向上します。 [ユーザードキュメント](/system-variables.md#tidb_gc_max_wait_time-new-in-v610) - TiDBは自動統計収集タスクの最大実行時間の設定をサポートします - データベースは統計情報を収集することでデータの分布を効果的に把握し、合理的な実行計画を生成してSQL実行の効率を向上させることができます。TiDBは、頻繁に変更されるデータオブジェクトの統計をバックグラウンドで定期的に収集します。しかし、統計の収集はクラスタリソースを消費するため、ビジネスピーク時にはビジネスの安定運用に影響を与える可能性があります。 + データベースは統計情報を収集することでデータの分布を効果的に把握し、合理的な実行計画を生成してSQL実行の効率を向上させることができます。TiDBは、頻繁に変更されるデータオブジェクトの統計をバックグラウンドで定期的に収集します。しかし、統計の収集はクラスターリソースを消費するため、ビジネスピーク時にはビジネスの安定運用に影響を与える可能性があります。 v6.1.0以降、TiDBはバックグラウンド統計収集の最大実行時間を制御するための[`tidb_max_auto_analyze_time`](/system-variables.md#tidb_max_auto_analyze_time-new-in-v610)導入しました。これはデフォルトで12時間です。アプリケーションがリソースのボトルネックに遭遇しない場合は、TiDBがタイムリーに統計を収集できるように、この変数を変更しないことを推奨します。 @@ -145,9 +145,9 @@ TiDB バージョン: 6.1.0 - TiDB、TiKV、およびTiFlash構成の動的な変更をサポート - 以前のバージョンのTiDBでは、設定項目を変更した後、変更を有効にするにはクラスタを再起動する必要がありました。これにより、オンラインサービスが中断される可能性がありました。この問題に対処するため、TiDB v6.1.0では動的設定機能が導入され、クラスタを再起動せずにパラメータ変更を検証できるようになりました。具体的な最適化は以下の通りです。 + 以前のバージョンのTiDBでは、設定項目を変更した後、変更を有効にするにはクラスターを再起動する必要がありました。これにより、オンラインサービスが中断される可能性がありました。この問題に対処するため、TiDB v6.1.0では動的設定機能が導入され、クラスターを再起動せずにパラメータ変更を検証できるようになりました。具体的な最適化は以下の通りです。 - - TiDBの一部の設定項目をシステム変数に変換し、動的に変更・保存できるようにします。変換後は元の設定項目は非推奨となることに注意してください。変換後の設定項目の詳細なリストについては、 [コンフィグレーションファイルのパラメータ](#configuration-file-parameters)参照してください。 + - TiDBの一部の設定項目をシステム変数に変換し、動的に変更・保存できるようにします。変換後は元の設定項目は非推奨となることに注意してください。変換後の設定項目の詳細なリストについては、 [設定ファイルのパラメータ](#configuration-file-parameters)参照してください。 - Support configuring some TiKV parameters online. For a detailed list of the parameters, see [その他](#others). - TiFlash構成項目`max_threads`システム変数`tidb_max_tiflash_threads`に変換し、構成を動的に変更して永続化できるようにします。変換後も元の構成項目は保持されることに注意してください。 @@ -164,22 +164,22 @@ TiDB バージョン: 6.1.0 `enable-global-kill`構成 (デフォルトで有効) を使用して、グローバル キル機能を制御できます。 - TiDB v6.1.0より前のバージョンでは、操作が大量のリソースを消費し、クラスタの安定性に問題が発生する場合、対象のTiDBインスタンスに接続してから`KILL TIDB ${id};`のコマンドを実行して対象の接続と操作を終了する必要がありました。多くのTiDBインスタンスの場合、この方法は使いにくく、誤操作が発生しやすいという問題がありました。v6.1.0以降では、 `enable-global-kill`構成が導入され、デフォルトで有効になっています。クライアントとTiDBの間にプロキシがある場合、他のクエリやセッションを誤って終了してしまう心配なく、任意のTiDBインスタンスでkillコマンドを実行して、指定した接続と操作を終了できます。現在、TiDBはCtrl+Cを使用してクエリまたはセッションを終了することをサポートしていません。 + TiDB v6.1.0より前のバージョンでは、操作が大量のリソースを消費し、クラスターの安定性に問題が発生する場合、対象のTiDBインスタンスに接続してから`KILL TIDB ${id};`のコマンドを実行して対象の接続と操作を終了する必要がありました。多くのTiDBインスタンスの場合、この方法は使いにくく、誤操作が発生しやすいという問題がありました。v6.1.0以降では、 `enable-global-kill`構成が導入され、デフォルトで有効になっています。クライアントとTiDBの間にプロキシがある場合、他のクエリやセッションを誤って終了してしまう心配なく、任意のTiDBインスタンスでkillコマンドを実行して、指定した接続と操作を終了できます。現在、TiDBはCtrl+Cを使用してクエリまたはセッションを終了することをサポートしていません。 [ユーザードキュメント](/tidb-configuration-file.md#enable-global-kill-new-in-v610) [＃8854](https://github.com/pingcap/tidb/issues/8854) - TiKV API V2 (実験的) - v6.1.0 より前では、TiKV が Raw Key Valuestorageとして使用される場合、TiKV はクライアントから渡された生データのみを保存するため、基本的な Key Value の読み取りおよび書き込み機能のみを提供します。 + v6.1.0 より前では、TiKV が Raw Key Valueストレージとして使用される場合、TiKV はクライアントから渡された生データのみを保存するため、基本的な Key Value の読み取りおよび書き込み機能のみを提供します。 - TiKV API V2 は、次のような新しい Raw Key Valuestorage形式とアクセス インターフェイスを提供します。 + TiKV API V2 は、次のような新しい Raw Key Valueストレージ形式とアクセス インターフェイスを提供します。 - データはMVCCに保存され、データの変更タイムスタンプが記録されます。この機能は、変更データキャプチャ（CDC）と増分バックアップ・リストアの実装の基盤となります。 - データはさまざまな使用法に応じてスコープ設定され、単一の TiDB クラスター、トランザクション KV、RawKV アプリケーションの共存をサポートします。 - 基盤となるstorage形式に大幅な変更が加えられたため、API V2 を有効にすると、TiKV クラスターを v6.1.0 より前のバージョンにロールバックできなくなります。TiKV をダウングレードすると、データが破損する可能性があります。 + 基盤となるストレージ形式に大幅な変更が加えられたため、API V2 を有効にすると、TiKV クラスターを v6.1.0 より前のバージョンにロールバックできなくなります。TiKV をダウングレードすると、データが破損する可能性があります。 @@ -252,9 +252,9 @@ TiDB バージョン: 6.1.0 | [`tidb_prepared_plan_cache_size`](/system-variables.md#tidb_prepared_plan_cache_size-new-in-v610) | 新しく追加された | この設定は以前は`tidb.toml`オプション ( `prepared-plan-cache.capacity` ) でしたが、TiDB v6.1.0 以降ではシステム変数に変更されました。 | | [`tidb_stats_cache_mem_quota`](/system-variables.md#tidb_stats_cache_mem_quota-new-in-v610) | 新しく追加された | この変数は、TiDB 統計キャッシュのメモリクォータを設定します。 | -### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} +### 設定ファイルのパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーション | タイプを変更 | 説明 | +| 設定ファイル | 設定 | タイプを変更 | 説明 | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | `committer-concurrency` | 削除済み | システム変数`tidb_committer_concurrency`に置き換えられました。この構成項目は無効になりました。値を変更する場合は、対応するシステム変数を変更する必要があります。 | | TiDB | `lower-case-table-names` | 削除済み | 現在、TiDBは`lower_case_table_name=2`のみをサポートしています。別の値が設定されている場合は、クラスターをv6.1.0にアップグレードした後にその値は失われます。 | @@ -276,8 +276,8 @@ TiDB バージョン: 6.1.0 | TiKV | [`causal-ts.renew-interval`](/tikv-configuration-file.md#renew-interval) | 新しく追加された | The interval at which the locally cached timestamps are refreshed. | | TiKV | [`max-snapshot-file-raw-size`](/tikv-configuration-file.md#max-snapshot-file-raw-size-new-in-v610) | 新しく追加された | スナップショット ファイルのサイズがこの値を超えると、スナップショット ファイルは複数のファイルに分割されます。 | | TiKV | [`raft-engine.memory-limit`](/tikv-configuration-file.md#memory-limit) | 新しく追加された | Raft Engineのメモリ使用量の制限を指定します。 | -| TiKV | [`storage.background-error-recovery-window`](/tikv-configuration-file.md#background-error-recovery-window-new-in-v610) | 新しく追加された | The maximum recovery time is allowed after RocksDB detects a recoverable background error. | -| TiKV | [`storage.api-version`](/tikv-configuration-file.md#api-version-new-in-v610) | 新しく追加された | TiKV が生のキー値ストアとして機能するときに TiKV によって使用されるstorage形式とインターフェース バージョン。 | +| TiKV | [`ストレージ.background-error-recovery-window`](/tikv-configuration-file.md#background-error-recovery-window-new-in-v610) | 新しく追加された | The maximum recovery time is allowed after RocksDB detects a recoverable background error. | +| TiKV | [`ストレージ.api-version`](/tikv-configuration-file.md#api-version-new-in-v610) | 新しく追加された | TiKV が生のキー値ストアとして機能するときに TiKV によって使用されるストレージ形式とインターフェース バージョン。 | | PD | [`schedule.max-store-preparing-time`](/pd-configuration-file.md#max-store-preparing-time-new-in-v610) | 新しく追加された | ストアがオンラインになるまでの最大待機時間を制御します。 | | TiCDC | [`enable-tls`](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka) | 新しく追加された | ダウンストリーム Kafka インスタンスに接続するために TLS を使用するかどうか。 | | TiCDC | `sasl-gssapi-user`
`sasl-gssapi-password`
`sasl-gssapi-auth-type`
`sasl-gssapi-service-name`
`sasl-gssapi-realm`
`sasl-gssapi-key-tab-path`
`sasl-gssapi-kerberos-config-path` | 新しく追加された | Kafka の SASL/GSSAPI 認証をサポートするために使用されます。詳細については[`kafka`でシンクURIを設定する](/ticdc/ticdc-sink-to-kafka.md#configure-sink-uri-for-kafka)参照してください。 | @@ -297,7 +297,7 @@ TiDB バージョン: 6.1.0 新しいクラスターでは、 プリペアドプランキャッシュがデフォルトで有効化され、リクエストの`Prepare` `Execute`実行プランをキャッシュします。以降の実行では、クエリプランの最適化をスキップできるため、パフォーマンスが向上します。アップグレードされたクラスターは、設定ファイルから設定を継承します。新しいクラスターは新しいデフォルト値を使用するため、 プリペアドプランキャッシュ はデフォルトで有効化され、各セッションで最大100プランをキャッシュできます ( `capacity=100` )。この機能のメモリ消費量については、 [プリペアドプランキャッシュのメモリ管理](/sql-prepared-plan-cache.md#memory-management-of-prepared-plan-cache)参照してください。 -- TiDB v6.1.0より前のバージョンでは、 `SHOW ANALYZE STATUS`インスタンスレベルのタスクを示し、タスクレコードはTiDBの再起動後に消去されます。TiDB v6.1.0以降では、 `SHOW ANALYZE STATUS`クラスタレベルのタスクを示し、タスクレコードは再起動後も保持されます。5 `tidb_analyze_version = 2`場合、 `Job_info`列に`analyze option`情報が追加されます。 +- TiDB v6.1.0より前のバージョンでは、 `SHOW ANALYZE STATUS`インスタンスレベルのタスクを示し、タスクレコードはTiDBの再起動後に消去されます。TiDB v6.1.0以降では、 `SHOW ANALYZE STATUS`クラスターレベルのタスクを示し、タスクレコードは再起動後も保持されます。5 `tidb_analyze_version = 2`場合、 `Job_info`列に`analyze option`情報が追加されます。 - TiKV内のSSTファイルが破損すると、TiKVプロセスがpanicになる可能性があります。TiDB v6.1.0より前では、SSTファイルが破損するとTiKVは直ちにpanic状態になりました。TiDB v6.1.0以降では、SSTファイルが破損してから1時間後にTiKVプロセスがpanicになります。 diff --git a/releases/release-6.1.1.md b/releases/release-6.1.1.md index adb25a6a0592d..61d79b88b8f1f 100644 --- a/releases/release-6.1.1.md +++ b/releases/release-6.1.1.md @@ -116,7 +116,7 @@ Quick access: [クイックスタート](https://docs.pingcap.com/tidb/v6.1/quic - PD - - クラスタノードのラベル構成が無効な場合にオンラインの進行状況が不正確になる問題を修正[＃5234](https://github.com/tikv/pd/issues/5234) @ [rleungx](https://github.com/rleungx) + - クラスターノードのラベル構成が無効な場合にオンラインの進行状況が不正確になる問題を修正[＃5234](https://github.com/tikv/pd/issues/5234) @ [rleungx](https://github.com/rleungx) - `enable-forwarding`有効になっているときに gRPC がエラーを不適切に処理する問題によって発生する PD パニックを修正[＃5373](https://github.com/tikv/pd/issues/5373) @ [bufferflies](https://github.com/bufferflies) - `/regions/replicated`間違ったステータス[＃5095](https://github.com/tikv/pd/issues/5095) @ [rleungx](https://github.com/rleungx)を返す可能性がある問題を修正しました @@ -124,7 +124,7 @@ Quick access: [クイックスタート](https://docs.pingcap.com/tidb/v6.1/quic - 状況によっては、クラスター化インデックスを持つテーブルの列を削除した後にTiFlash がクラッシュする問題を修正[＃5154](https://github.com/pingcap/tiflash/issues/5154) @ [hongyunyan](https://github.com/hongyunyan) - `format`関数が`Data truncated`エラー[＃4891](https://github.com/pingcap/tiflash/issues/4891) @ [xzhangxian1008](https://github.com/xzhangxian1008)を返す可能性がある問題を修正しました - - 一部の古いデータがstorageに残り、削除できない問題を修正[＃5659](https://github.com/pingcap/tiflash/issues/5659) @ [lidezhu](https://github.com/lidezhu) + - 一部の古いデータがストレージに残り、削除できない問題を修正[＃5659](https://github.com/pingcap/tiflash/issues/5659) @ [lidezhu](https://github.com/lidezhu) - 一部のエッジケースで不要な CPU 使用率を修正[＃5409](https://github.com/pingcap/tiflash/issues/5409) @ [breezewish](https://github.com/breezewish) - IPv6 [＃5247](https://github.com/pingcap/tiflash/issues/5247) @ [solotzg](https://github.com/solotzg)を使用するクラスターでTiFlash が動作できないバグを修正しました - 並列集約[#5356](https://github.com/pingcap/tiflash/issues/5356) @ [gengliqi](https://github.com/gengliqi)エラーによりTiFlashがクラッシュする可能性があるバグを修正 @@ -166,7 +166,7 @@ Quick access: [クイックスタート](https://docs.pingcap.com/tidb/v6.1/quic - バックアップと復元 (BR) - RawKVモード[＃35279](https://github.com/pingcap/tidb/issues/35279) @ [3pointer](https://github.com/3pointer)でBRが`ErrRestoreTableIDMismatch`報告するバグを修正 - - 大規模クラスタバックアップ[#30087](https://github.com/pingcap/tidb/issues/30087) @ [MoCuishle28](https://github.com/MoCuishle28)での S3 レート制限によるバックアップ失敗を修正するために、バックアップデータディレクトリ構造を調整します。 + - 大規模クラスターバックアップ[#30087](https://github.com/pingcap/tidb/issues/30087) @ [MoCuishle28](https://github.com/MoCuishle28)での S3 レート制限によるバックアップ失敗を修正するために、バックアップデータディレクトリ構造を調整します。 - サマリーログ[#35553](https://github.com/pingcap/tidb/issues/35553) @ [ixuh12](https://github.com/ixuh12)のバックアップ時間の誤りを修正 - Dumpling diff --git a/releases/release-6.1.2.md b/releases/release-6.1.2.md index 0ab6c6a198589..24a913f773a96 100644 --- a/releases/release-6.1.2.md +++ b/releases/release-6.1.2.md @@ -58,7 +58,7 @@ Quick access: [クイックスタート](https://docs.pingcap.com/tidb/v6.1/quic - PD - リージョンツリーの統計が不正確になる可能性がある問題を修正[＃5318](https://github.com/tikv/pd/issues/5318) @ [rleungx](https://github.com/rleungx) - - TiFlash学習者レプリカが作成されない可能性がある問題を修正[#5401](https://github.com/tikv/pd/issues/5401) @ [HunDunDM](https://github.com/HunDunDM) + - TiFlashラーナーレプリカが作成されない可能性がある問題を修正[#5401](https://github.com/tikv/pd/issues/5401) @ [HunDunDM](https://github.com/HunDunDM) - PD がダッシュボード プロキシ リクエスト[＃5321](https://github.com/tikv/pd/issues/5321) @ [HunDunDM](https://github.com/HunDunDM)を正しく処理できない問題を修正しました - 不健全なリージョンがPDpanic[＃5491](https://github.com/tikv/pd/issues/5491) @ [nolouch](https://github.com/nolouch)を引き起こす可能性がある問題を修正 @@ -94,4 +94,4 @@ Quick access: [クイックスタート](https://docs.pingcap.com/tidb/v6.1/quic - バックアップと復元 (BR) - 復元中に同時実行が大きすぎる設定になっているため、領域のバランスが取れていない問題を修正しました[＃37549](https://github.com/pingcap/tidb/issues/37549) @ [3pointer](https://github.com/3pointer) - - 外部storage[＃37469](https://github.com/pingcap/tidb/issues/37469) @ [MoCuishle28](https://github.com/MoCuishle28)の認証キーに特殊文字が含まれている場合にバックアップと復元が失敗する可能性がある問題を修正しました + - 外部ストレージ[＃37469](https://github.com/pingcap/tidb/issues/37469) @ [MoCuishle28](https://github.com/MoCuishle28)の認証キーに特殊文字が含まれている場合にバックアップと復元が失敗する可能性がある問題を修正しました diff --git a/releases/release-6.1.4.md b/releases/release-6.1.4.md index eb7233522e80e..3f287c7c16f66 100644 --- a/releases/release-6.1.4.md +++ b/releases/release-6.1.4.md @@ -28,7 +28,7 @@ TiDB バージョン: 6.1.4 - TiCDC - SQL文がバッチ[＃7653](https://github.com/pingcap/tiflow/issues/7653) @ [asddongmen](https://github.com/asddongmen)で生成される際のスループットを向上させるために、DMLバッチ操作モードを追加します。 - - GCS または Azure 互換のオブジェクトstorage[＃7987](https://github.com/pingcap/tiflow/issues/7987) @ [CharlesCheung96](https://github.com/CharlesCheung96)への REDO ログの保存をサポート + - GCS または Azure 互換のオブジェクトストレージ[＃7987](https://github.com/pingcap/tiflow/issues/7987) @ [CharlesCheung96](https://github.com/CharlesCheung96)への REDO ログの保存をサポート - TiDB Lightning @@ -50,7 +50,7 @@ TiDB バージョン: 6.1.4 - PD - - PD が予期せず複数の学習者をリージョン[＃5786](https://github.com/tikv/pd/issues/5786) @ [HunDunDM](https://github.com/HunDunDM)に追加する可能性がある問題を修正しました。 + - PD が予期せず複数のラーナーをリージョン[＃5786](https://github.com/tikv/pd/issues/5786) @ [HunDunDM](https://github.com/HunDunDM)に追加する可能性がある問題を修正しました。 diff --git a/releases/release-6.1.6.md b/releases/release-6.1.6.md index 78b6a5729c0b5..97196cb5c6558 100644 --- a/releases/release-6.1.6.md +++ b/releases/release-6.1.6.md @@ -87,7 +87,7 @@ TiDB バージョン: 6.1.6 - TiDB または MySQL シンクにデータを複製するときに、主キー[＃8420](https://github.com/pingcap/tiflow/issues/8420) @ [zhaoxinyu](https://github.com/zhaoxinyu)のない非 NULL ユニーク インデックスを持つ列に`CHARACTER SET`指定した場合に発生するデータの不整合を修正しました。 - `db sorter`のメモリ使用量が`cgroup memory limit` [＃8588](https://github.com/pingcap/tiflow/issues/8588) @ [amyangfei](https://github.com/amyangfei)で制御されない問題を修正 - 無効な入力[＃7903](https://github.com/pingcap/tiflow/issues/7903)に対する`cdc cli`のエラーメッセージを[チャールズ・チュン96](https://github.com/CharlesCheung96)で最適化します - - S3storage障害[＃8089](https://github.com/pingcap/tiflow/issues/8089) @ [CharlesCheung96](https://github.com/CharlesCheung96)に対して、REDO ログが許容できる期間が不十分である問題を修正しました + - S3ストレージ障害[＃8089](https://github.com/pingcap/tiflow/issues/8089) @ [CharlesCheung96](https://github.com/CharlesCheung96)に対して、REDO ログが許容できる期間が不十分である問題を修正しました - PDが異常なときにチェンジフィードを一時停止すると、誤ったステータス[＃8330](https://github.com/pingcap/tiflow/issues/8330) @ [sdojjy](https://github.com/sdojjy)になる問題を修正しました。 - TiDB Lightning diff --git a/releases/release-6.2.0.md b/releases/release-6.2.0.md index 338daabe9feb0..02ce08b22e7b5 100644 --- a/releases/release-6.2.0.md +++ b/releases/release-6.2.0.md @@ -18,7 +18,7 @@ TiDBバージョン: 6.2.0-DMR - TiDB ダッシュボードは[視覚的な実行計画](https://docs-archive.pingcap.com/tidb/v6.2/dashboard-slow-query#visual-execution-plans)をサポートしており、実行計画をより直感的に表示できます。 - パフォーマンス分析とチューニングをより効率的に行うために、TiDB ダッシュボードに[監視ページ](/dashboard/dashboard-monitoring.md)を追加します。 - TiDB の[ロックビュー](/information-schema/information-schema-data-lock-waits.md)機能は、楽観的トランザクションの待機情報の表示をサポートし、ロック競合の迅速な特定を容易にします。 -- TiFlash は[storageフォーマットの新しいバージョン](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file)をサポートし、安定性とパフォーマンスを強化します。 +- TiFlash は[ストレージフォーマットの新しいバージョン](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file)をサポートし、安定性とパフォーマンスを強化します。 - [きめ細かいシャッフル機能](/system-variables.md#tiflash_fine_grained_shuffle_batch_size-new-in-v620)ウィンドウ関数を複数のスレッドで並列実行できます。 - 新しい並行DDLフレームワーク：DDLステートメントのブロックが減り、実行効率が向上します。 - TiKV は[CPU使用率を自動的に調整する](/tikv-configuration-file.md#background-quota-limiter)をサポートしており、安定した効率的なデータベース運用を保証します。 @@ -36,9 +36,9 @@ TiDBバージョン: 6.2.0-DMR - 物理データ圧縮機能はGAです - TiFlashのバックエンドは、特定の条件に基づいて物理データを自動的に圧縮し、不要なデータの蓄積を減らし、データstorage構造を最適化します。 + TiFlashのバックエンドは、特定の条件に基づいて物理データを自動的に圧縮し、不要なデータの蓄積を減らし、データストレージ構造を最適化します。 - TiFlashテーブルには、データ圧縮が自動的にトリガーされる前に、一定量の不要なデータが含まれていることがよくあります。この機能を使用すると、適切なタイミングを選択してSQLステートメントを手動で実行し、 TiFlash内の物理データを即座に圧縮できるため、storage容量の使用量を削減し、クエリのパフォーマンスを向上させることができます。この機能はTiDB v6.1では実験的でしたが、TiDB v6.2.0で一般提供（GA）となりました。 + TiFlashテーブルには、データ圧縮が自動的にトリガーされる前に、一定量の不要なデータが含まれていることがよくあります。この機能を使用すると、適切なタイミングを選択してSQLステートメントを手動で実行し、 TiFlash内の物理データを即座に圧縮できるため、ストレージ容量の使用量を削減し、クエリのパフォーマンスを向上させることができます。この機能はTiDB v6.1では実験的でしたが、TiDB v6.2.0で一般提供（GA）となりました。 [ユーザー向けドキュメント](/sql-statements/sql-statement-alter-table-compact.md#alter-table--compact) [#4145](https://github.com/pingcap/tiflash/issues/4145) @[breezewish](https://github.com/breezewish) @@ -116,11 +116,11 @@ TiDBバージョン: 6.2.0-DMR [ユーザー向けドキュメント](/system-variables.md#tiflash_fine_grained_shuffle_batch_size-new-in-v620) [#4631](https://github.com/pingcap/tiflash/issues/4631) @[guo-shaoge](https://github.com/guo-shaoge) -- TiFlashは、より新しいバージョンのstorageフォーマットをサポートしています。 +- TiFlashは、より新しいバージョンのストレージフォーマットをサポートしています。 - 新しいstorageフォーマットは、高並列処理や高負荷なワークロード環境において、ガベージコレクション（GC）によって引き起こされるCPU使用率の上昇を緩和します。これにより、バックグラウンドタスクのI/Oトラフィックが大幅に削減され、高並列処理や高負荷なワークロード環境下での安定性が向上します。同時に、ディスク容量の増大やディスクの無駄遣いも大幅に削減できます。 + 新しいストレージフォーマットは、高並列処理や高負荷なワークロード環境において、ガベージコレクション（GC）によって引き起こされるCPU使用率の上昇を緩和します。これにより、バックグラウンドタスクのI/Oトラフィックが大幅に削減され、高並列処理や高負荷なワークロード環境下での安定性が向上します。同時に、ディスク容量の増大やディスクの無駄遣いも大幅に削減できます。 - TiDB v6.2.0では、データはデフォルトで新しいstorage形式で保存されます。TiFlashを以前のバージョンからv6.2.0にアップグレードする場合、以前のTiFlashバージョンでは新しいstorage形式を認識できないため、 TiFlash上​​でインプレースダウングレードを実行することはできませんのでご注意ください。 + TiDB v6.2.0では、データはデフォルトで新しいストレージ形式で保存されます。TiFlashを以前のバージョンからv6.2.0にアップグレードする場合、以前のTiFlashバージョンでは新しいストレージ形式を認識できないため、 TiFlash上​​でインプレースダウングレードを実行することはできませんのでご注意ください。 TiFlash のアップグレードの詳細については、 [TiFlashアップグレードガイド](/tiflash-upgrade-guide.md)を参照してください。 @@ -156,7 +156,7 @@ TiDBバージョン: 6.2.0-DMR - TiKVは、コマンドラインフラグを使用して詳細な設定情報を一覧表示することをサポートしています。 - TiKV 設定ファイルは、TiKV インスタンスの管理に使用できます。しかし、長時間実行され、複数のユーザーによって管理されているインスタンスの場合、どの設定項目が変更されたか、デフォルト値は何かを把握するのは困難です。これは、クラスタのアップグレードやデータの移行時に混乱を招く可能性があります。TiDB v6.2.0 以降、tikv-server は、すべての TiKV 設定項目のデフォルト値と現在の値を一覧表示する新しいコマンドラインフラグ[`—-config-info`](/command-line-flags-for-tikv-configuration.md#--config-info-format)をサポートしており、TiKV プロセスの起動パラメータをユーザーがすばやく確認できるようになり、使いやすさが向上します。 + TiKV 設定ファイルは、TiKV インスタンスの管理に使用できます。しかし、長時間実行され、複数のユーザーによって管理されているインスタンスの場合、どの設定項目が変更されたか、デフォルト値は何かを把握するのは困難です。これは、クラスターのアップグレードやデータの移行時に混乱を招く可能性があります。TiDB v6.2.0 以降、tikv-server は、すべての TiKV 設定項目のデフォルト値と現在の値を一覧表示する新しいコマンドラインフラグ[`—-config-info`](/command-line-flags-for-tikv-configuration.md#--config-info-format)をサポートしており、TiKV プロセスの起動パラメータをユーザーがすばやく確認できるようになり、使いやすさが向上します。 [ユーザー向けドキュメント](/command-line-flags-for-tikv-configuration.md#--config-info-format) [#12492](https://github.com/tikv/tikv/issues/12492)[グロルヴ](https://github.com/glorv) @@ -184,7 +184,7 @@ TiDBバージョン: 6.2.0-DMR - ログとスナップショットのバックアップと復元に基づくポイントインタイムリカバリ（PITR）をサポートします。 - PITRは、ログとスナップショットのバックアップおよび復元に基づいて実装されています。これにより、クラスタの履歴上の任意の時点のスナップショットを新しいクラスタに復元できます。この機能は、以下のニーズを満たします。 + PITRは、ログとスナップショットのバックアップおよび復元に基づいて実装されています。これにより、クラスターの履歴上の任意の時点のスナップショットを新しいクラスターに復元できます。この機能は、以下のニーズを満たします。 - ディザスタリカバリにおけるRPO（目標復旧時点）を20分未満に短縮する。 - アプリケーションからの書き込みエラーが発生した場合は、例えば、エラー発生前の状態にデータをロールバックするなどの方法で対処します。 @@ -210,17 +210,17 @@ TiDBバージョン: 6.2.0-DMR - TiDB Lightningのディスククォータ設定をサポート（実験的） - TiDB Lightning が物理インポートモード (backend='local') でデータをインポートする場合、`sorted-kv-dir` にはソースデータを格納するのに十分な空き容量が必要です。ディスク容量が不足すると、インポートタスクが失敗する可能性があります。TiDB Lightning が使用するディスク容量の合計を制限するために、新しい`disk_quota`設定を使用すれば、`sorted-kv-dir` に十分なstorage容量がない場合でも、インポートタスクを正常に完了できます。 + TiDB Lightning が物理インポートモード (backend='local') でデータをインポートする場合、`sorted-kv-dir` にはソースデータを格納するのに十分な空き容量が必要です。ディスク容量が不足すると、インポートタスクが失敗する可能性があります。TiDB Lightning が使用するディスク容量の合計を制限するために、新しい`disk_quota`設定を使用すれば、`sorted-kv-dir` に十分なストレージ容量がない場合でも、インポートタスクを正常に完了できます。 [ユーザー向けドキュメント](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#configure-disk-quota-new-in-v620) [#446](https://github.com/pingcap/tidb-lightning/issues/446) @[buchuitoudegou](https://github.com/buchuitoudegou) -- TiDB Lightningは、物理インポートモードでの本番クラスタへのデータインポートをサポートしています。 +- TiDB Lightningは、物理インポートモードでの本番クラスターへのデータインポートをサポートしています。 - 従来、 TiDB Lightningの物理インポートモード（backend='local'）は、対象クラスタに大きな影響を与えていました。例えば、移行中にPDのグローバルスケジューリングが一時停止されるといった問題がありました。そのため、従来の物理インポートモードは、初期データインポートにのみ適していました。 + 従来、 TiDB Lightningの物理インポートモード（backend='local'）は、対象クラスターに大きな影響を与えていました。例えば、移行中にPDのグローバルスケジューリングが一時停止されるといった問題がありました。そのため、従来の物理インポートモードは、初期データインポートにのみ適していました。 - TiDB Lightningは、既存の物理インポートモードを改良しました。テーブルのスケジュールを一時停止できるようにすることで、インポートの影響をクラスタレベルからテーブルレベルにまで軽減します。つまり、インポートされていないテーブルの読み書きが可能になります。 + TiDB Lightningは、既存の物理インポートモードを改良しました。テーブルのスケジュールを一時停止できるようにすることで、インポートの影響をクラスターレベルからテーブルレベルにまで軽減します。つまり、インポートされていないテーブルの読み書きが可能になります。 - この機能には手動設定は不要です。TiDBクラスタがv6.1.0以降、かつTiDB Lightningがv6.2.0以降の場合、新しい物理インポートモードは自動的に有効になります。 + この機能には手動設定は不要です。TiDBクラスターがv6.1.0以降、かつTiDB Lightningがv6.2.0以降の場合、新しい物理インポートモードは自動的に有効になります。 [ユーザー向けドキュメント](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#scope-of-pausing-scheduling-during-import) [#35148](https://github.com/pingcap/tidb/issues/35148) @[sleepymole](https://github.com/sleepymole) @@ -233,7 +233,7 @@ TiDBバージョン: 6.2.0-DMR - クラスター間RawKVレプリケーションのサポート（実験的） - 新しいコンポーネントTiKV-CDCを使用して、RawKVのデータ変更を購読し、そのデータ変更を下流のTiKVクラスタにリアルタイムで複製することをサポートします。これにより、クラスタ間の複製が可能になります。 + 新しいコンポーネントTiKV-CDCを使用して、RawKVのデータ変更を購読し、そのデータ変更を下流のTiKVクラスターにリアルタイムで複製することをサポートします。これにより、クラスター間の複製が可能になります。 [ユーザー向けドキュメント](/tikv-configuration-file.md#api-version-new-in-v610) [#11965](https://github.com/tikv/tikv/issues/11965) @[pingyu](https://github.com/pingyu) @@ -251,7 +251,7 @@ TiDBバージョン: 6.2.0-DMR | ----------------------------------------------------------------------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | [tidb_enable_new_cost_interface](/system-variables.md#tidb_enable_new_cost_interface-new-in-v620) | 新しく追加された | この変数は[コストモデルの実装をリファクタリングしました](/cost-model.md#cost-model-version-2)を有効にするかどうかを制御します。 | | [tidb_cost_model_version](/system-variables.md#tidb_cost_model_version-new-in-v620) | 新しく追加された | TiDBは、物理最適化の際にインデックスと演算子を選択するためにコストモデルを使用します。この変数は、コストモデルのバージョンを選択するために使用されます。TiDB v6.2.0では、内部テストで以前のバージョンよりも精度が向上したコストモデルバージョン2が導入されました。 | -| tidb_enable_concurrent_ddl | 新しく追加された | この変数は、TiDBが同時DDLステートメントを使用することを許可するかどうかを制御します。この変数は変更しないでください。この変数を無効にすると、リスクは不明であり、クラスタのメタデータが破損する可能性があります。 | +| tidb_enable_concurrent_ddl | 新しく追加された | この変数は、TiDBが同時DDLステートメントを使用することを許可するかどうかを制御します。この変数は変更しないでください。この変数を無効にすると、リスクは不明であり、クラスターのメタデータが破損する可能性があります。 | | [tiflash_fine_grained_shuffle_stream_count](/system-variables.md#tiflash_fine_grained_shuffle_stream_count-new-in-v620) | 新しく追加された | この変数は、ウィンドウ関数が実行のためにTiFlashにプッシュダウンされる際の、ウィンドウ関数実行の並行レベルを制御します。 | | [tiflash_fine_grained_shuffle_batch_size](/system-variables.md#tiflash_fine_grained_shuffle_batch_size-new-in-v620) | 新しく追加された | 細粒度シャッフルが有効になっている場合、 TiFlashにプッシュダウンされるウィンドウ関数を並列実行できます。この変数は、送信側から送信されるデータのバッチサイズを制御します。送信側は、累積行数がこの値を超えた時点でデータを送信します。 | | [tidb_default_string_match_selectivity](/system-variables.md#tidb_default_string_match_selectivity-new-in-v620) | 新しく追加された | この変数は、行数を推定する際のフィルタ条件における`like` 、 `rlike` 、および`regexp`関数のデフォルトの選択性を設定するために関数。また、この変数は、これらの関数の推定を支援するために TopN を有効にするかどうかも制御します。 | @@ -264,33 +264,33 @@ TiDBバージョン: 6.2.0-DMR | tidb_enable_change_multi_schema | 削除済み | この変数は、v6.2.0 以降では、デフォルトで 1 つの`ALTER TABLE`ステートメントで複数の列またはインデックスを変更できるため、削除されます。 | | [tidb_enable_outer_join_reorder](/system-variables.md#tidb_enable_outer_join_reorder-new-in-v610) | 修正済み | この変数は、TiDB の結合したテーブルの再配置アルゴリズムが Outer Join をサポートするかどうかを制御します。v6.1.0 では、デフォルト値は`ON`であり、これは Join Reorder の Outer Join のサポートがデフォルトで有効になっていることを意味します。v6.2.0 以降では、デフォルト値は`OFF`であり、これはサポートがデフォルトで無効になっていることを意味します。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーション | 種類を変更する | 説明 | +| 設定ファイル | 設定 | 種類を変更する | 説明 | | -------------- | ------------------------------------------------------------------------------------------------------------------------- | -------- | --------------------------------------------------------------------------------------------------- | | TiDB | フィードバック確率 | 削除済み | この設定はもはや有効ではなく、推奨されません。 | | TiDB | クエリフィードバック制限 | 削除済み | この設定はもはや有効ではなく、推奨されません。 | -| ティクヴ | [サーバー.simplify-metrics](/tikv-configuration-file.md#simplify-metrics-new-in-v620) | 新しく追加された | この設定では、返される監視メトリクスを簡略化するかどうかを指定します。 | -| ティクヴ | [quota.background-cpu-time](/tikv-configuration-file.md#background-cpu-time-new-in-v620) | 新しく追加された | この設定では、TiKVのバックグラウンド処理で読み取りおよび書き込み要求を処理するために使用されるCPUリソースのソフトリミットを指定します。 | -| ティクヴ | [quota.background-write-bandwidth](/tikv-configuration-file.md#background-write-bandwidth-new-in-v620) | 新しく追加された | この設定では、バックグラウンド トランザクションがデータを書き込む際の帯域幅のソフト リミットを指定します (現在は有効ではありません)。 | -| ティクヴ | [クォータ.バックグラウンド読み取り帯域幅](/tikv-configuration-file.md#background-read-bandwidth-new-in-v620) | 新しく追加された | この設定では、バックグラウンドトランザクションとコプロセッサーがデータを読み取る際の帯域幅のソフトリミットを指定します（現在は有効ではありません）。 | -| ティクヴ | [quota.enable-auto-tune](/tikv-configuration-file.md#enable-auto-tune-new-in-v620) | 新しく追加された | この設定では、クォータの自動調整を有効にするかどうかを指定します。この設定項目を有効にすると、TiKVはTiKVインスタンスの負荷に基づいて、バックグラウンドリクエストのクォータを動的に調整します。 | -| ティクヴ | rocksdb.enable-pipelined-commit | 削除済み | この設定はもはや有効ではありません。 | -| ティクヴ | gc-merge-rewrite | 削除済み | この設定はもはや有効ではありません。 | -| ティクヴ | [ログバックアップを有効にする](/tikv-configuration-file.md#enable-new-in-v620) | 新しく追加された | この設定は、TiKV 上でログバックアップを有効にするかどうかを制御します。 | -| ティクヴ | [ログバックアップ.ファイルサイズ制限](/tikv-configuration-file.md#file-size-limit-new-in-v620) | 新しく追加された | この設定では、ログバックアップデータのサイズ制限を指定します。この制限に達すると、データは自動的に外部storageに書き込まれます。 | -| ティクヴ | [ログバックアップ.初期スキャン保留中のメモリ割り当て](/tikv-configuration-file.md#initial-scan-pending-memory-quota-new-in-v620) | 新しく追加された | この設定では、増分スキャンデータを保存するために使用されるキャッシュのクォータを指定します。 | -| ティクヴ | [log-backup.max-flush-interval](/tikv-configuration-file.md#max-flush-interval-new-in-v620) | 新しく追加された | この設定では、ログバックアップにおいてバックアップデータを外部storageに書き込む最大間隔を指定します。 | -| ティクヴ | [ログバックアップの初期スキャンレート制限](/tikv-configuration-file.md#initial-scan-rate-limit-new-in-v620) | 新しく追加された | この設定では、ログバックアップにおける増分データスキャンのスループットのレート制限を指定します。 | -| ティクヴ | [log-backup.num-threads](/tikv-configuration-file.md#num-threads-new-in-v620) | 新しく追加された | この設定では、ログバックアップで使用されるスレッド数を指定します。 | -| ティクヴ | [log-backup.temp-path](/tikv-configuration-file.md#temp-path-new-in-v620) | 新しく追加された | この設定では、ログファイルが外部storageに書き込まれる前に一時的に保存されるパスを指定します。 | -| ティクヴ | [rocksdb.defaultcf.format-version](/tikv-configuration-file.md#format-version-new-in-v620) | 新しく追加された | SSTファイルのフォーマットバージョン。 | -| ティクヴ | [rocksdb.writecf.format-version](/tikv-configuration-file.md#format-version-new-in-v620) | 新しく追加された | SSTファイルのフォーマットバージョン。 | -| ティクヴ | [rocksdb.lockcf.format-version](/tikv-configuration-file.md#format-version-new-in-v620) | 新しく追加された | SSTファイルのフォーマットバージョン。 | +| TiKV | [サーバー.simplify-metrics](/tikv-configuration-file.md#simplify-metrics-new-in-v620) | 新しく追加された | この設定では、返される監視メトリクスを簡略化するかどうかを指定します。 | +| TiKV | [quota.background-cpu-time](/tikv-configuration-file.md#background-cpu-time-new-in-v620) | 新しく追加された | この設定では、TiKVのバックグラウンド処理で読み取りおよび書き込み要求を処理するために使用されるCPUリソースのソフトリミットを指定します。 | +| TiKV | [quota.background-write-bandwidth](/tikv-configuration-file.md#background-write-bandwidth-new-in-v620) | 新しく追加された | この設定では、バックグラウンド トランザクションがデータを書き込む際の帯域幅のソフト リミットを指定します (現在は有効ではありません)。 | +| TiKV | [クォータ.バックグラウンド読み取り帯域幅](/tikv-configuration-file.md#background-read-bandwidth-new-in-v620) | 新しく追加された | この設定では、バックグラウンドトランザクションとコプロセッサーがデータを読み取る際の帯域幅のソフトリミットを指定します（現在は有効ではありません）。 | +| TiKV | [quota.enable-auto-tune](/tikv-configuration-file.md#enable-auto-tune-new-in-v620) | 新しく追加された | この設定では、クォータの自動調整を有効にするかどうかを指定します。この設定項目を有効にすると、TiKVはTiKVインスタンスの負荷に基づいて、バックグラウンドリクエストのクォータを動的に調整します。 | +| TiKV | rocksdb.enable-pipelined-commit | 削除済み | この設定はもはや有効ではありません。 | +| TiKV | gc-merge-rewrite | 削除済み | この設定はもはや有効ではありません。 | +| TiKV | [ログバックアップを有効にする](/tikv-configuration-file.md#enable-new-in-v620) | 新しく追加された | この設定は、TiKV 上でログバックアップを有効にするかどうかを制御します。 | +| TiKV | [ログバックアップ.ファイルサイズ制限](/tikv-configuration-file.md#file-size-limit-new-in-v620) | 新しく追加された | この設定では、ログバックアップデータのサイズ制限を指定します。この制限に達すると、データは自動的に外部ストレージに書き込まれます。 | +| TiKV | [ログバックアップ.初期スキャン保留中のメモリ割り当て](/tikv-configuration-file.md#initial-scan-pending-memory-quota-new-in-v620) | 新しく追加された | この設定では、増分スキャンデータを保存するために使用されるキャッシュのクォータを指定します。 | +| TiKV | [log-backup.max-flush-interval](/tikv-configuration-file.md#max-flush-interval-new-in-v620) | 新しく追加された | この設定では、ログバックアップにおいてバックアップデータを外部ストレージに書き込む最大間隔を指定します。 | +| TiKV | [ログバックアップの初期スキャンレート制限](/tikv-configuration-file.md#initial-scan-rate-limit-new-in-v620) | 新しく追加された | この設定では、ログバックアップにおける増分データスキャンのスループットのレート制限を指定します。 | +| TiKV | [log-backup.num-threads](/tikv-configuration-file.md#num-threads-new-in-v620) | 新しく追加された | この設定では、ログバックアップで使用されるスレッド数を指定します。 | +| TiKV | [log-backup.temp-path](/tikv-configuration-file.md#temp-path-new-in-v620) | 新しく追加された | この設定では、ログファイルが外部ストレージに書き込まれる前に一時的に保存されるパスを指定します。 | +| TiKV | [rocksdb.defaultcf.format-version](/tikv-configuration-file.md#format-version-new-in-v620) | 新しく追加された | SSTファイルのフォーマットバージョン。 | +| TiKV | [rocksdb.writecf.format-version](/tikv-configuration-file.md#format-version-new-in-v620) | 新しく追加された | SSTファイルのフォーマットバージョン。 | +| TiKV | [rocksdb.lockcf.format-version](/tikv-configuration-file.md#format-version-new-in-v620) | 新しく追加された | SSTファイルのフォーマットバージョン。 | | PD | レプリケーションモード.dr-auto-sync.wait-async-timeout | 削除済み | この設定は有効にならず、削除されます。 | | PD | レプリケーションモード.dr-auto-sync.wait-sync-timeout | 削除済み | この設定は有効にならず、削除されます。 | -| TiFlash | [`storage.format_version`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 修正済み | `format_version`のデフォルト値が`4`に変更されます。これは v6.2.0 以降のバージョンのデフォルト形式であり、書き込み増幅とバックグラウンド タスクのリソース消費を削減します。 | -| TiFlash | [profiles.default.dt_enable_read_thread](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 新しく追加された | この設定は、storageエンジンからの読み取り要求を処理するためにスレッド プールを使用するかどうかを制御します。デフォルト値は`false`です。 | +| TiFlash | [`ストレージ.format_version`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 修正済み | `format_version`のデフォルト値が`4`に変更されます。これは v6.2.0 以降のバージョンのデフォルト形式であり、書き込み増幅とバックグラウンド タスクのリソース消費を削減します。 | +| TiFlash | [profiles.default.dt_enable_read_thread](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 新しく追加された | この設定は、ストレージエンジンからの読み取り要求を処理するためにスレッド プールを使用するかどうかを制御します。デフォルト値は`false`です。 | | TiFlash | [profiles.default.dt_page_gc_threshold](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 新しく追加された | この設定では、PageStorageデータファイル内の有効データの最小比率を指定します。 | | TiCDC | [--overwrite-checkpoint-ts](/ticdc/ticdc-manage-changefeed.md#resume-a-replication-task) | 新しく追加された | この設定は`cdc cli changefeed resume`サブコマンドに追加されます。 | | TiCDC | [--確認しない](/ticdc/ticdc-manage-changefeed.md#resume-a-replication-task) | 新しく追加された | この設定は`cdc cli changefeed resume`サブコマンドに追加されます。 | @@ -298,13 +298,13 @@ TiDBバージョン: 6.2.0-DMR | DM | [労働者数](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced) | 新しく追加された | この設定はバリデーターパラメータであり、バックグラウンドで実行される検証ワーカーの数を指定します。デフォルト値は`4`です。 | | DM | [行エラー遅延](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced) | 新しく追加された | この設定はバリデーターパラメータです。指定された時間内に検証が行われなかった場合、その行はエラー行としてマークされます。デフォルト値は30mで、これは30分を意味します。 | | TiDB Lightning | [tikv-importer.store-write-bwlimit](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) | 新しく追加された | この設定は、TiDB Lightning が各 TiKV ストアにデータを書き込む際の書き込み帯域幅を決定します。デフォルト値は`0`で、帯域幅に制限がないことを示します。 | -| TiDB Lightning | [tikv-importer.disk-quota](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#configure-disk-quota-new-in-v620) | 新しく追加された | この構成により、TiDB Lightningが使用するstorage容量が制限されます。 | +| TiDB Lightning | [tikv-importer.disk-quota](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#configure-disk-quota-new-in-v620) | 新しく追加された | この構成により、TiDB Lightningが使用するストレージ容量が制限されます。 | ### その他 {#others} - TiFlash `format_version` `4`から`3`にダウングレードすることはできません。詳細については、 [TiFlashアップグレードガイド](/tiflash-upgrade-guide.md)を参照してください。 - バージョン6.2.0以降では、デフォルト値の`false`を`dt_enable_logical_split`のままにして、 `true`に変更しないことを強くお勧めします。詳細は、既知の問題[#5576](https://github.com/pingcap/tiflash/issues/5576)を参照してください。 -- バックアップ クラスタにTiFlashレプリカがある場合、PITR を実行すると、リストア クラスタにはTiFlashレプリカ内のデータが含まれません。TiFlash レプリカからデータをリストアするには、 TiFlashレプリカを手動で構成する必要があります。 `exchange partition` DDL ステートメントを実行すると、PITR が失敗する可能性があります。アップTiFlashデータベースが TiDB Lightning の物理インポート モードを使用してデータをインポートする場合、ログ バックアップでデータをバックアップできません。データ インポート後にフル バックアップを実行することをお勧めします。PITR のその他の互換性の問題については、 [PITRの制限](/br/backup-and-restore-overview.md#before-you-use)参照してください。 +- バックアップ クラスターにTiFlashレプリカがある場合、PITR を実行すると、リストア クラスターにはTiFlashレプリカ内のデータが含まれません。TiFlash レプリカからデータをリストアするには、 TiFlashレプリカを手動で構成する必要があります。 `exchange partition` DDL ステートメントを実行すると、PITR が失敗する可能性があります。アップTiFlashデータベースが TiDB Lightning の物理インポート モードを使用してデータをインポートする場合、ログ バックアップでデータをバックアップできません。データ インポート後にフル バックアップを実行することをお勧めします。PITR のその他の互換性の問題については、 [PITRの制限](/br/backup-and-restore-overview.md#before-you-use)参照してください。 - TiDB v6.2.0以降では、データ復元時に`mysql`パラメータを指定することで`--with-sys-table=true`スキーマのテーブルを復元できます。 - `ALTER TABLE`ステートメントを実行して複数の列またはインデックスを追加、削除、または変更する場合、TiDB は同じ DDL ステートメントの変更内容に関わらず、ステートメント実行前後のテーブルを比較してテーブルの一貫性をチェックします。DDL の実行順序は、シナリオによっては MySQL と完全には互換性がない場合があります。 - TiDBコンポーネントがv6.2.0以降の場合、TiKVコンポーネントはv6.2.0より前のバージョンであってはなりません。 @@ -351,7 +351,7 @@ TiDB v6.2.0以降、 BRを使用したRawKVのバックアップと復元は非 - トランザクションの監視メトリクスを追加 [#34456](https://github.com/pingcap/tidb/issues/34456) @[longfangsong](https://github.com/longfangsong) -- ティクヴ +- TiKV - HTTPボディサイズを削減するために、gzipを使用してメトリクスレスポンスを圧縮するサポート [#12355](https://github.com/tikv/tikv/issues/12355) @[glorv](https://github.com/glorv) - Grafana ダッシュボードの TiKV パネルの読みやすさを改善 [#12007](https://github.com/tikv/tikv/issues/12007) @[kevin-xianliu](https://github.com/kevin-xianliu) @@ -372,7 +372,7 @@ TiDB v6.2.0以降、 BRを使用したRawKVのバックアップと復元は非 - バックアップと復元 (BR) - - 大規模クラスタバックアップにおけるS3レート制限によるバックアップ失敗を修正するため、バックアップデータディレクトリ構造を調整しました [#30087](https://github.com/pingcap/tidb/issues/30087) @[MoCuishle28](https://github.com/MoCuishle28) + - 大規模クラスターバックアップにおけるS3レート制限によるバックアップ失敗を修正するため、バックアップデータディレクトリ構造を調整しました [#30087](https://github.com/pingcap/tidb/issues/30087) @[MoCuishle28](https://github.com/MoCuishle28) - TiCDC @@ -418,11 +418,11 @@ TiDB v6.2.0以降、 BRを使用したRawKVのバックアップと復元は非 - LOAD DATA ステートメントで列リストが機能しない問題を修正 [#35198](https://github.com/pingcap/tidb/issues/35198) @[SpadeA-Tang](https://github.com/SpadeA-Tang) - 一部のシナリオで悲観的ロックが非一意のセカンダリインデックスに誤って追加される問題を修正 [#36235](https://github.com/pingcap/tidb/issues/36235) @[ekexium](https://github.com/ekexium) -- ティクヴ +- TiKV - 悲観的トランザクションで`WriteConflict`エラーを報告しないようにします [#11612](https://github.com/tikv/tikv/issues/11612) @[sticnarf](https://github.com/sticnarf) - 非同期コミットが有効になっている場合に、悲観的トランザクションで発生する可能性のある重複コミット レコードを修正 [#12615](https://github.com/tikv/tikv/issues/12615) @[sticnarf](https://github.com/sticnarf) - - `storage.api-version`を`1`から`2`に変更した際に TiKV がパニック [#12600](https://github.com/tikv/tikv/issues/12600) @[pingyu](https://github.com/pingyu) + - `ストレージ.api-version`を`1`から`2`に変更した際に TiKV がパニック [#12600](https://github.com/tikv/tikv/issues/12600) @[pingyu](https://github.com/pingyu) - TiKVとPD間のリージョンサイズ構成の不整合の問題を修正 [#12518](https://github.com/tikv/tikv/issues/12518) @[5kbpers](https://github.com/5kbpers) - TiKV が PD クライアントに再接続し続ける問題を修正[#12506](https://github.com/tikv/tikv/issues/12506) 、 [#12827](https://github.com/tikv/tikv/issues/12827) @[Connor1996](https://github.com/Connor1996) - TiKVが空文字列の型変換時にパニックを起こす問題を修正 [#12673](https://github.com/tikv/tikv/issues/12673) @[wshwsh12](https://github.com/wshwsh12) diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 94e44732ebb95..df88e51b6429c 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -121,7 +121,7 @@ TiDBバージョン: 6.3.0-DMR TiDB v6.2.0 では、オプティマイザに`MERGE`ヒントを導入し、CTE のインライン実行を可能にしました。これにより、CTE クエリ結果の利用者はTiFlashで並列実行できるようになりました。v6.3.0 では、セッション変数[`tidb_opt_force_inline_cte`](/system-variables.md#tidb_opt_force_inline_cte-new-in-v630)導入され、セッション内での CTE のインライン実行が可能になりました。これにより、使いやすさが大幅に向上します。 -### 取引 {#transactions} +### トランザクション {#transactions} - 悲観的トランザクションにおける一意制約のチェックの延期をサポート [#36579](https://github.com/pingcap/tidb/issues/36579) @[ekexium](https://github.com/ekexium) @@ -143,7 +143,7 @@ TiDBバージョン: 6.3.0-DMR - Titan の無効化が GA に[タボキー](https://github.com/tabokie) - オンライン TiKV ノードに対して[Titanを無効にする](/storage-engine/titan-configuration.md#disable-titan)ことができます。 + オンライン TiKV ノードに対して[Titanを無効にする](/ストレージ-engine/titan-configuration.md#disable-titan)ことができます。 - グローバル統計が準備できていない場合は、 `static`パーティションプルーニングを使用します [#37535](https://github.com/pingcap/tidb/issues/37535) @[Yisaer](https://github.com/Yisaer) @@ -175,7 +175,7 @@ TiDBバージョン: 6.3.0-DMR ### バックアップと復元 {#backup-and-restore} -- PITR はバックアップ ストレージとして[GCSとAzure Blob Storage](/br/backup-and-restore-storages.md)サポートしています @[joccau](https://github.com/joccau) +- PITR はバックアップ ストレージとして[GCSとAzure Blob Storage](/br/backup-and-restore-ストレージs.md)サポートしています @[joccau](https://github.com/joccau) TiDBクラスターがGoogle CloudまたはAzureにデプロイされている場合、クラスターをv6.3.0にアップグレードすると、PITR機能を使用できます。 @@ -203,7 +203,7 @@ TiDBバージョン: 6.3.0-DMR - TiCDC はグレースフル アップグレードをサポート [#4757](https://github.com/pingcap/tiflow/issues/4757) @[overvenus](https://github.com/overvenus)@[3AceShowHand](https://github.com/3AceShowHand) - TiCDCを[TiUP](/ticdc/deploy-ticdc.md#upgrade-cautions) （>=v1.11.0）または[TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/v1.3/configure-a-tidb-cluster#configure-graceful-upgrade-for-ticdc-cluster) （>=v1.3.8）を使用してデプロイする場合、TiCDCクラスタをスムーズにアップグレードできます。アップグレード中は、データレプリケーションのレイテンシーが30秒以下に抑えられます。これにより安定性が向上し、TiCDCはレイテンシに敏感なアプリケーションをより適切にサポートできるようになります。 + TiCDCを[TiUP](/ticdc/deploy-ticdc.md#upgrade-cautions) （>=v1.11.0）または[TiDB Operator](https://docs.pingcap.com/tidb-in-kubernetes/v1.3/configure-a-tidb-cluster#configure-graceful-upgrade-for-ticdc-cluster) （>=v1.3.8）を使用してデプロイする場合、TiCDCクラスターをスムーズにアップグレードできます。アップグレード中は、データレプリケーションのレイテンシーが30秒以下に抑えられます。これにより安定性が向上し、TiCDCはレイテンシに敏感なアプリケーションをより適切にサポートできるようになります。 ## 互換性の変更 {#compatibility-changes} @@ -215,7 +215,7 @@ TiDBバージョン: 6.3.0-DMR | [`sql_require_primary_key`](/system-variables.md#sql_require_primary_key-new-in-v630) | 新しく追加された | テーブルに主キーが必要であるという要件を強制するかどうかを制御します。この変数を有効にすると、主キーのないテーブルを作成または変更しようとするとエラーが発生します。 | | [`tidb_adaptive_closest_read_threshold`](/system-variables.md#tidb_adaptive_closest_read_threshold-new-in-v630) | 新しく追加された | [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40)が`closest-adaptive`に設定されている場合、TiDBサーバーが読み取り要求を TiDBサーバーと同じリージョンのレプリカに送信することを優先するしきい値を制御します。 | | [`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630) | 新しく追加された | TiDB が悲観的トランザクションで[固有の制約](/constraints.md#pessimistic-transactions)いつチェックするかを制御します。 | -| [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630) | 新しく追加された | [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)有効になっている場合にのみ有効になります。インデックス作成時のバックフィル処理中にローカルstorageを使用する際の制限を設定します。 | +| [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-new-in-v630) | 新しく追加された | [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)有効になっている場合にのみ有効になります。インデックス作成時のバックフィル処理中にローカルストレージを使用する際の制限を設定します。 | | [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) | 新しく追加された | インデックス作成時のバックフィル速度を向上させるために、 `ADD INDEX`および`CREATE INDEX` DDL 操作の高速化を有効にするかどうかを制御します。 | | [`tidb_ddl_flashback_concurrency`](/system-variables.md#tidb_ddl_flashback_concurrency-new-in-v630) | 新しく追加された | `flashback cluster`の同時実行を制御します。この変数で制御される機能は、TiDB v6.3.0 では完全には動作しません。デフォルト値を変更しないでください。 | | [`tidb_enable_exchange_partition`](/system-variables.md#tidb_enable_exchange_partition) | 非推奨 | [`exchange partitions with tables`](/partitioned-table.md#partition-management)機能を有効にするかどうかを制御します。デフォルト値は`ON`です。つまり、 `exchange partitions with tables`がデフォルトで有効になっています。 | @@ -237,19 +237,19 @@ TiDBバージョン: 6.3.0-DMR | [`tidb_rc_write_check_ts`](/system-variables.md#tidb_rc_write_check_ts-new-in-v630) | 新しく追加された | タイムスタンプの取得を最適化するために使用され、悲観的トランザクションのRC分離レベルにおいてポイントライト競合が少ないシナリオに適しています。この変数を有効にすると、ポイントライトステートメントの実行中にグローバルタイムスタンプを取得する際に発生するレイテンシーとオーバーヘッドを回避できます。 | | [`tiflash_fastscan`](/system-variables.md#tiflash_fastscan-new-in-v630) | 新しく追加された | FastScanを有効にするかどうかを制御します。FastScan[ファストスキャン](/tiflash/use-fastscan.md)有効になっている場合（ `ON`に設定）、 TiFlashはより効率的なクエリパフォーマンスを提供しますが、クエリ結果の正確性やデータの一貫性は保証されません。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーション | 種類を変更する | 説明 | +| 設定ファイル | 設定 | 種類を変更する | 説明 | | -------------- | ----------------------------------------------------------------------------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| TiDB | [`temp-dir`](/tidb-configuration-file.md#temp-dir-new-in-v630) | 新しく追加された | TiDB が一時データを格納するために使用するファイルシステム上の場所を指定します。機能が TiDB ノードでローカルstorageを必要とする場合、TiDB は対応する一時データをこの場所に格納します。デフォルト値は`/tmp/tidb`です。 | -| ティクヴ | [`auto-adjust-pool-size`](/tikv-configuration-file.md#auto-adjust-pool-size-new-in-v630) | 新しく追加された | スレッドプールのサイズを自動的に調整するかどうかを制御します。有効にすると、現在のCPU使用率に基づいてUnifyReadPoolスレッドプールのサイズを自動的に調整することで、TiKVの読み取りパフォーマンスが最適化されます。 | -| ティクヴ | [`data-encryption-method`](/tikv-configuration-file.md#data-encryption-method) | 修正済み | 新しい値オプション`sm4-ctr`が導入されました。この設定項目が`sm4-ctr`に設定されている場合、データは保存される前に SM4 を使用して暗号化されます。 | -| ティクヴ | [`enable-log-recycle`](/tikv-configuration-file.md#enable-log-recycle-new-in-v630) | 新しく追加された | Raft Engineで古いログ ファイルを再利用するかどうかを決定します。有効にすると、論理的に削除されたログ ファイルは再利用のために予約されます。これにより、書き込みワークロードのロング テールレイテンシーが削減されます。この設定項目は[フォーマットバージョン](/tikv-configuration-file.md#format-version-new-in-v630)が 2 以上の場合のみ使用できます。 | -| ティクヴ | [`format-version`](/tikv-configuration-file.md#format-version-new-in-v630) | 新しく追加された | Raft Engineのログ ファイルのバージョンを指定します。デフォルトのログ ファイル バージョンは、TiKV v6.3.0 より前のバージョンでは`1`です。ログ ファイルは、TiKV >= v6.1.0 で読み取ることができます。デフォルトのログ ファイル バージョンは、TiKV v6.3.0 以降では`2`です。TiKV v6.3.0 以降では、ログ ファイルを読み取ることができます。 | -| ティクヴ | [`log-backup.enable`](/tikv-configuration-file.md#enable-new-in-v620) | 修正済み | バージョン6.3.0以降、デフォルト値が`false`から`true`に変更されました。 | -| ティクヴ | [`log-backup.max-flush-interval`](/tikv-configuration-file.md#max-flush-interval-new-in-v620) | 修正済み | バージョン6.3.0以降、デフォルト値が`5min`から`3min`に変更されました。 | +| TiDB | [`temp-dir`](/tidb-configuration-file.md#temp-dir-new-in-v630) | 新しく追加された | TiDB が一時データを格納するために使用するファイルシステム上の場所を指定します。機能が TiDB ノードでローカルストレージを必要とする場合、TiDB は対応する一時データをこの場所に格納します。デフォルト値は`/tmp/tidb`です。 | +| TiKV | [`auto-adjust-pool-size`](/tikv-configuration-file.md#auto-adjust-pool-size-new-in-v630) | 新しく追加された | スレッドプールのサイズを自動的に調整するかどうかを制御します。有効にすると、現在のCPU使用率に基づいてUnifyReadPoolスレッドプールのサイズを自動的に調整することで、TiKVの読み取りパフォーマンスが最適化されます。 | +| TiKV | [`data-encryption-method`](/tikv-configuration-file.md#data-encryption-method) | 修正済み | 新しい値オプション`sm4-ctr`が導入されました。この設定項目が`sm4-ctr`に設定されている場合、データは保存される前に SM4 を使用して暗号化されます。 | +| TiKV | [`enable-log-recycle`](/tikv-configuration-file.md#enable-log-recycle-new-in-v630) | 新しく追加された | Raft Engineで古いログ ファイルを再利用するかどうかを決定します。有効にすると、論理的に削除されたログ ファイルは再利用のために予約されます。これにより、書き込みワークロードのロング テールレイテンシーが削減されます。この設定項目は[フォーマットバージョン](/tikv-configuration-file.md#format-version-new-in-v630)が 2 以上の場合のみ使用できます。 | +| TiKV | [`format-version`](/tikv-configuration-file.md#format-version-new-in-v630) | 新しく追加された | Raft Engineのログ ファイルのバージョンを指定します。デフォルトのログ ファイル バージョンは、TiKV v6.3.0 より前のバージョンでは`1`です。ログ ファイルは、TiKV >= v6.1.0 で読み取ることができます。デフォルトのログ ファイル バージョンは、TiKV v6.3.0 以降では`2`です。TiKV v6.3.0 以降では、ログ ファイルを読み取ることができます。 | +| TiKV | [`log-backup.enable`](/tikv-configuration-file.md#enable-new-in-v620) | 修正済み | バージョン6.3.0以降、デフォルト値が`false`から`true`に変更されました。 | +| TiKV | [`log-backup.max-flush-interval`](/tikv-configuration-file.md#max-flush-interval-new-in-v620) | 修正済み | バージョン6.3.0以降、デフォルト値が`5min`から`3min`に変更されました。 | | PD | [診断を有効にする](/pd-configuration-file.md#enable-diagnostic-new-in-v630) | 新しく追加された | 診断機能を有効にするかどうかを制御します。デフォルト値は`false`です。 | -| TiFlash | [`dt_enable_read_thread`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 非推奨 | バージョン6.3.0以降、この設定項目は非推奨となりました。デフォルトでは、スレッドプールがstorageエンジンからの読み取り要求を処理するために使用され、無効にすることはできません。 | +| TiFlash | [`dt_enable_read_thread`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 非推奨 | バージョン6.3.0以降、この設定項目は非推奨となりました。デフォルトでは、スレッドプールがストレージエンジンからの読み取り要求を処理するために使用され、無効にすることはできません。 | | DM | [`safe-mode-duration`](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced) | 新しく追加された | 自動セーフモードの継続時間を指定します。 | | TiCDC | [`enable-sync-point`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters) | 新しく追加された | Syncpoint機能を有効にするかどうかを指定します。 | | TiCDC | [`sync-point-interval`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters) | 新しく追加された | Syncpointがアップストリームとダウンストリームのスナップショットを同期させる間隔を指定します。 | @@ -258,7 +258,7 @@ TiDBバージョン: 6.3.0-DMR ### その他 {#others} -- ログバックアップは、バックアップstorageとしてGCSとAzure Blob Storageをサポートしています。 +- ログバックアップは、バックアップストレージとしてGCSとAzure Blob Storageをサポートしています。 - ログバックアップは`exchange partition` DDLと互換性を持つようになりました。 - 以前[ファストスキャン](/tiflash/use-fastscan.md)を有効にするために使用されていた SQL ステートメント`ALTER TABLE ...SET TiFLASH MODE ...`非推奨となり、システム変数[`tiflash_fastscan`](/system-variables.md#tiflash_fastscan-new-in-v630)に置き換えられました。v6.2.0 から v6.3.0 にアップグレードすると、v6.2.0 のすべての FastScan 設定が無効になりますが、データの通常の読み取りには影響しません。この場合、FastScan を有効または無効にするには、変数[`tiflash_fastscan`](/system-variables.md#tiflash_fastscan-new-in-v630)を設定する必要があります。以前のバージョンから v6.3.0 にアップグレードすると、データの一貫性を保つために、すべてのセッションで FastScan 機能はデフォルトで有効になりません。 - TiFlashをLinux AMD64アーキテクチャにデプロイするには、CPUがAVX2命令セットをサポートしている必要があります。 `grep avx2 /proc/cpuinfo`に出力があることを確認してください。TiFlashをLinux ARM64アーキテクチャにデプロイするには、CPUがARMv8命令セットアーキテクチャをサポートしている必要があります。 `grep 'crc32' /proc/cpuinfo | grep 'asimd'`に出力があることを確認してください。命令セット拡張機能を使用することで、TiFlashのベクトル化エンジンはより優れたパフォーマンスを発揮できます。 @@ -280,7 +280,7 @@ TiDBバージョン: 6.3.0-DMR - 誤った共有の問題を修正することで、結合操作のパフォーマンスを向上させます [#37641](https://github.com/pingcap/tidb/issues/37641) @[gengliqi](https://github.com/gengliqi) - [`PLAN REPLAYER`](/sql-plan-replayer.md)を使用して複数のSQLステートメントの実行プラン情報を一度にエクスポートできるようにすることで、トラブルシューティングの効率化を図ります。 [#37798](https://github.com/pingcap/tidb/issues/37798) @[Yisaer](https://github.com/Yisaer) -- ティクヴ +- TiKV - ピアが到達不能になった後にRaftstore がメッセージを過剰にブロードキャストするのを回避するために`unreachable_backoff`アイテムの設定をサポートします [#13054](https://github.com/tikv/tikv/issues/13054) @[5kbpers](https://github.com/5kbpers) - TSOサービスの耐障害性を向上させる [#12794](https://github.com/tikv/tikv/issues/12794) @[pingyu](https://github.com/pingyu) @@ -310,7 +310,7 @@ TiDBバージョン: 6.3.0-DMR - バックアップと復元 (BR) - PITRはログバックアップで生成された小さなファイルをマージできるため、バックアップファイルの数を大幅に削減できます。 [#13232](https://github.com/tikv/tikv/issues/13232) @[Leavrth](https://github.com/Leavrth) - - PITRは、復元後にアップストリームクラスタ構成に基づいてTiFlashレプリカの数を自動的に構成することをサポートします [#37208](https://github.com/pingcap/tidb/issues/37208) @[YuJuncen](https://github.com/YuJuncen) + - PITRは、復元後にアップストリームクラスター構成に基づいてTiFlashレプリカの数を自動的に構成することをサポートします [#37208](https://github.com/pingcap/tidb/issues/37208) @[YuJuncen](https://github.com/YuJuncen) - TiCDC @@ -328,7 +328,7 @@ TiDBバージョン: 6.3.0-DMR - TiDB Lightning - - S3外部storageURLのクエリパラメータを追加し、指定されたロールを引き受けることで別のアカウントのS3データにアクセスできるようにする [#36891](https://github.com/pingcap/tidb/issues/36891) @[dsdashun](https://github.com/dsdashun) + - S3外部ストレージURLのクエリパラメータを追加し、指定されたロールを引き受けることで別のアカウントのS3データにアクセスできるようにする [#36891](https://github.com/pingcap/tidb/issues/36891) @[dsdashun](https://github.com/dsdashun) ## バグ修正 {#bug-fixes} @@ -366,7 +366,7 @@ TiDBバージョン: 6.3.0-DMR - `Can't find column`ステートメントに共通テーブル式 (CTE) が含まれている場合に`UPDATE`が報告される問題を修正 [#35758](https://github.com/pingcap/tidb/issues/35758) @[AilinKid](https://github.com/AilinKid) - 間違った`PromQL` [#35856](https://github.com/pingcap/tidb/issues/35856) @[Defined2014](https://github.com/Defined2014)修正 -- ティクヴ +- TiKV - リージョンのハートビートが中断された後、PD が TiKV に再接続しない問題を修正 [#12934](https://github.com/tikv/tikv/issues/12934) @[bufferflies](https://github.com/bufferflies) - Raftstoreがビジー状態のときにリージョンが重複する可能性がある問題を修正 [#13160](https://github.com/tikv/tikv/issues/13160) @[5kbpers](https://github.com/5kbpers) @@ -384,14 +384,14 @@ TiDBバージョン: 6.3.0-DMR - `enable-forwarding`が有効になっている場合にgRPCがエラーを不適切に処理する問題によって発生するPDパニックを修正 [#5373](https://github.com/tikv/pd/issues/5373) @[bufferflies](https://github.com/bufferflies) - 不健康なリージョンがPDpanicを引き起こす可能性がある問題を修正 [#5491](https://github.com/tikv/pd/issues/5491) @[nolouch](https://github.com/nolouch) - - TiFlash学習者レプリカが作成されない可能性がある問題を修正 [#5401](https://github.com/tikv/pd/issues/5401) @[HunDunDM](https://github.com/HunDunDM) + - TiFlashラーナーレプリカが作成されない可能性がある問題を修正 [#5401](https://github.com/tikv/pd/issues/5401) @[HunDunDM](https://github.com/HunDunDM) - TiFlash - ウィンドウ関数がクエリのキャンセル時にTiFlashをクラッシュさせる可能性がある問題を修正 [#5814](https://github.com/pingcap/tiflash/issues/5814) @[SeaRise](https://github.com/SeaRise) - `CAST(value AS DATETIME)`への誤ったデータ入力が原因でTiFlashシステムの CPU 使用率が高くなる問題を修正しました [#5097](https://github.com/pingcap/tiflash/issues/5097) @[xzhangxian1008](https://github.com/xzhangxian1008) - `CAST(Real/Decimal AS time)`の結果が MySQL と一致しない問題を修正します [#3779](https://github.com/pingcap/tiflash/issues/3779) @[mengxin9014](https://github.com/mengxin9014) - - storage内の一部の古いデータが削除できない問題を修正 [#5570](https://github.com/pingcap/tiflash/issues/5570) @[JaySon-Huang](https://github.com/JaySon-Huang) + - ストレージ内の一部の古いデータが削除できない問題を修正 [#5570](https://github.com/pingcap/tiflash/issues/5570) @[JaySon-Huang](https://github.com/JaySon-Huang) - ページ GC がテーブルの作成をブロックする可能性がある問題を修正 [#5697](https://github.com/pingcap/tiflash/issues/5697) @[JaySon-Huang](https://github.com/JaySon-Huang) - `NULL`値を含む列でプライマリ インデックスを作成した後に発生するpanicを修正 [#5859](https://github.com/pingcap/tiflash/issues/5859) @[JaySon-Huang](https://github.com/JaySon-Huang) @@ -402,7 +402,7 @@ TiDBバージョン: 6.3.0-DMR - チェックポイントの情報が古くなる可能性がある問題を修正 [#36423](https://github.com/pingcap/tidb/issues/36423) @[YuJuncen](https://github.com/YuJuncen) - 復元中に同時実行数の設定が大きすぎるため、リージョンのバランスが取れていない問題を修正 [#37549](https://github.com/pingcap/tidb/issues/37549) @[3pointer](https://github.com/3pointer) - クラスター内に TiCDC が存在する場合にログバックアップチェックポイント TS が停止する可能性がある問題を修正します [#37822](https://github.com/pingcap/tidb/issues/37822) @[YuJuncen](https://github.com/YuJuncen) - - 外部storageの認証キーに特殊文字が含まれている場合にバックアップと復元が失敗する可能性がある問題を修正しました [#37469](https://github.com/pingcap/tidb/issues/37469) @[MoCuishle28](https://github.com/MoCuishle28) + - 外部ストレージの認証キーに特殊文字が含まれている場合にバックアップと復元が失敗する可能性がある問題を修正しました [#37469](https://github.com/pingcap/tidb/issues/37469) @[MoCuishle28](https://github.com/MoCuishle28) - TiCDC diff --git a/releases/release-6.4.0.md b/releases/release-6.4.0.md index aad746821913d..9000ef91a9ce8 100644 --- a/releases/release-6.4.0.md +++ b/releases/release-6.4.0.md @@ -1,6 +1,6 @@ --- title: TiDB 6.4.0 Release Notes -summary: TiDB 6.4.0-DMRでは、クラスタを特定の時点に復元する機能、線形ハッシュパーティショニング構文との互換性、高性能なAUTO_INCREMENT`モードなど、新機能と改善点が導入されています。また、障害リカバリ、メモリ使用量制御、統計情報の収集機能も強化されています。TiFlashは保存時の暗号化にSM4アルゴリズムをサポートし、TiCDCはKafkaへのデータレプリケートに対応しました。さらに、各種ツールやコンポーネントにおけるバグ修正と改善も含まれています。 +summary: TiDB 6.4.0-DMRでは、クラスターを特定の時点に復元する機能、線形ハッシュパーティショニング構文との互換性、高性能なAUTO_INCREMENT`モードなど、新機能と改善点が導入されています。また、障害リカバリ、メモリ使用量制御、統計情報の収集機能も強化されています。TiFlashは保存時の暗号化にSM4アルゴリズムをサポートし、TiCDCはKafkaへのデータレプリケートに対応しました。さらに、各種ツールやコンポーネントにおけるバグ修正と改善も含まれています。 --- # TiDB 6.4.0 リリースノート {#tidb-6-4-0-release-notes} @@ -28,7 +28,7 @@ TiDBバージョン: 6.4.0-DMR - [クラスター診断](/dashboard/dashboard-diagnostics-access.md)機能が GA になります。 - TiFlash は[保存時の暗号化](/encryption-at-rest.md#tiflash)のための SM4 アルゴリズムをサポートしています。 - SQL ステートメントを使用して[テーブル内の指定されたパーティションのコンパクトなTiFlashレプリカを即座に](/sql-statements/sql-statement-alter-table-compact.md#compact-tiflash-replicas-of-specified-partitions-in-a-table)サポートします。 -- [EBSボリュームスナップショットを使用したTiDBクラスタのバックアップ](https://docs.pingcap.com/tidb-in-kubernetes/v1.4/backup-to-aws-s3-by-snapshot)サポートします。 +- [EBSボリュームスナップショットを使用したTiDBクラスターのバックアップ](https://docs.pingcap.com/tidb-in-kubernetes/v1.4/backup-to-aws-s3-by-snapshot)サポートします。 - DM は[上流のデータソース情報を下流のマージ済みテーブルの拡張列に書き込む](/dm/dm-table-routing.md#extract-table-schema-and-source-information-and-write-into-the-merged-table)サポートしています。 ## 新機能 {#new-features} @@ -37,7 +37,7 @@ TiDBバージョン: 6.4.0-DMR - SQL ステートメントを使用して、テーブル内の指定されたパーティションのTiFlashレプリカをすぐに圧縮するサポート [#5315](https://github.com/pingcap/tiflash/issues/5315) @[hehechen](https://github.com/hehechen) - バージョン6.2.0以降、TiDBはTiFlashのフルテーブルレプリカに対して[物理データを即座に圧縮する](/sql-statements/sql-statement-alter-table-compact.md#alter-table--compact)機能をサポートしています。適切なタイミングでSQLステートメントを手動で実行してTiFlash内の物理データを即座に圧縮することで、storage容量を削減し、クエリパフォーマンスを向上させることができます。バージョン6.4.0では、圧縮するTiFlashレプリカデータの粒度をさらに細かくし、テーブル内の指定されたパーティションのTiFlashレプリカを即座に圧縮できるようにしました。 + バージョン6.2.0以降、TiDBはTiFlashのフルテーブルレプリカに対して[物理データを即座に圧縮する](/sql-statements/sql-statement-alter-table-compact.md#alter-table--compact)機能をサポートしています。適切なタイミングでSQLステートメントを手動で実行してTiFlash内の物理データを即座に圧縮することで、ストレージ容量を削減し、クエリパフォーマンスを向上させることができます。バージョン6.4.0では、圧縮するTiFlashレプリカデータの粒度をさらに細かくし、テーブル内の指定されたパーティションのTiFlashレプリカを即座に圧縮できるようにしました。 SQL ステートメント`ALTER TABLE table_name COMPACT [PARTITION PartitionNameList] [engine_type REPLICA]`を実行すると、テーブル内の指定されたパーティションのTiFlashレプリカを即座に圧縮できます。 @@ -45,7 +45,7 @@ TiDBバージョン: 6.4.0-DMR - `FLASHBACK CLUSTER TO TIMESTAMP`を使用した特定の時点へのクラスターの復元のサポート (実験的) [#37197](https://github.com/pingcap/tidb/issues/37197) [#13303](https://github.com/tikv/tikv/issues/13303) @[Defined2014](https://github.com/Defined2014) @[bb7133](https://github.com/bb7133) @[JmPotato](https://github.com/JmPotato) @[Connor1996](https://github.com/Connor1996) @[HuSharp](https://github.com/HuSharp) @[CalvinNeo](https://github.com/CalvinNeo) - `FLASHBACK CLUSTER TO TIMESTAMP`構文を使用すると、ガベージコレクション（GC）の有効期間内に、クラスタを特定の時点に迅速に復元できます。この機能は、DML操作の誤りを簡単かつ迅速に取り消すのに役立ちます。たとえば、{{B-PLACEHOLDER-2-PLACEHOLDER-E} `WHERE`句なしで誤って`DELETE`を実行した後、この構文を使用して数分で元のクラスタを復元できます。この機能はデータベースのバックアップに依存せず、異なる時点のデータをロールバックして、データが変更された正確な時刻を特定できます。 `FLASHBACK CLUSTER TO TIMESTAMP`はデータベースのバックアップの代わりにはならないことに注意してください。 + `FLASHBACK CLUSTER TO TIMESTAMP`構文を使用すると、ガベージコレクション（GC）の有効期間内に、クラスターを特定の時点に迅速に復元できます。この機能は、DML操作の誤りを簡単かつ迅速に取り消すのに役立ちます。たとえば、{{B-PLACEHOLDER-2-PLACEHOLDER-E} `WHERE`句なしで誤って`DELETE`を実行した後、この構文を使用して数分で元のクラスターを復元できます。この機能はデータベースのバックアップに依存せず、異なる時点のデータをロールバックして、データが変更された正確な時刻を特定できます。 `FLASHBACK CLUSTER TO TIMESTAMP`はデータベースのバックアップの代わりにはならないことに注意してください。 `FLASHBACK CLUSTER TO TIMESTAMP`を実行する前に、TiCDC などのツールで実行されている PITR およびレプリケーション タスクを一時停止し、 `FLASHBACK`が完了した後に再開する必要があります。そうしないと、レプリケーション タスクが失敗する可能性があります。 @@ -67,11 +67,11 @@ TiDBバージョン: 6.4.0-DMR ### 可観測性 {#observability} -- クラスタ診断が GA になります [#1438](https://github.com/pingcap/tidb-dashboard/issues/1438) @[Hawkson-jee](https://github.com/Hawkson-jee) +- クラスター診断が GA になります [#1438](https://github.com/pingcap/tidb-dashboard/issues/1438) @[Hawkson-jee](https://github.com/Hawkson-jee) - TiDB Dashboardの [クラスター診断](/dashboard/dashboard-diagnostics-access.md)は、指定された時間範囲内でクラスタに存在する可能性のある問題を診断し、診断結果とクラスタ関連の負荷監視情報を レポートにまとめます。この診断レポートはWeb [診断レポート](/dashboard/dashboard-diagnostics-report.md)形式です。ブラウザからページを保存した後、オフラインでページを閲覧したり、このページのリンクを共有したりできます。 + TiDB Dashboardの [クラスター診断](/dashboard/dashboard-diagnostics-access.md)は、指定された時間範囲内でクラスターに存在する可能性のある問題を診断し、診断結果とクラスター関連の負荷監視情報を レポートにまとめます。この診断レポートはWeb [診断レポート](/dashboard/dashboard-diagnostics-report.md)形式です。ブラウザからページを保存した後、オフラインでページを閲覧したり、このページのリンクを共有したりできます。 - 診断レポートを使用すると、負荷、コンポーネントの状態、処理時間、構成など、クラスタの基本的な状態情報をすばやく把握できます。クラスタに一般的な問題がある場合は、 [診断情報](/dashboard/dashboard-diagnostics-report.md#diagnostic-information)セクションにある組み込みの自動診断結果から原因を特定できます。 + 診断レポートを使用すると、負荷、コンポーネントの状態、処理時間、構成など、クラスターの基本的な状態情報をすばやく把握できます。クラスターに一般的な問題がある場合は、 [診断情報](/dashboard/dashboard-diagnostics-report.md#diagnostic-information)セクションにある組み込みの自動診断結果から原因を特定できます。 ### パフォーマンス {#performance} @@ -113,7 +113,7 @@ TiDBバージョン: 6.4.0-DMR - ディスク障害やI/Oスタックなどの極端な状況における障害リカバリを加速する [#13648](https://github.com/tikv/tikv/issues/13648) @[LykxSassinator](https://github.com/LykxSassinator) - エンタープライズユーザーにとって、データベースの可用性は最も重要な指標の一つです。複雑なハードウェア環境では、障害を迅速に検知して復旧する方法が、データベース可用性における課題の一つとなっています。v6.4.0では、TiDBはTiKVノードの状態検出メカニズムを完全に最適化しました。ディスク障害やI/Oスタックといった極端な状況下でも、TiDBはノードの状態を迅速に報告し、アクティブウェイクアップメカニズムを使用してLeader選出を事前に開始することで、クラスタの自己修復を加速します。この最適化により、TiDBはディスク障害発生時のクラスタリカバリ時間を約50%短縮できます。 + エンタープライズユーザーにとって、データベースの可用性は最も重要な指標の一つです。複雑なハードウェア環境では、障害を迅速に検知して復旧する方法が、データベース可用性における課題の一つとなっています。v6.4.0では、TiDBはTiKVノードの状態検出メカニズムを完全に最適化しました。ディスク障害やI/Oスタックといった極端な状況下でも、TiDBはノードの状態を迅速に報告し、アクティブウェイクアップメカニズムを使用してLeader選出を事前に開始することで、クラスターの自己修復を加速します。この最適化により、TiDBはディスク障害発生時のクラスターリカバリ時間を約50%短縮できます。 - TiDBのメモリ使用量に関するグローバル制御 [#37816](https://github.com/pingcap/tidb/issues/37816) @[wshwsh12](https://github.com/wshwsh12) @@ -145,15 +145,15 @@ TiDBバージョン: 6.4.0-DMR - TiKV API V2 が一般公開 (GA) [#11745](https://github.com/tikv/tikv/issues/11745) @[pingyu](https://github.com/pingyu) - バージョン6.1.0より前のTiKVは、クライアントから渡された生データのみを保存するため、基本的なキーバリューの読み書き機能しか提供していませんでした。さらに、異なるコーディング方式とスコープのないデータ範囲のため、TiDB、トランザクションKV、およびRawKVを同じTiKVクラスタで同時に使用することはできません。そのため、複数のクラスタが必要となり、マシンコストと導入コストが増加します。 + バージョン6.1.0より前のTiKVは、クライアントから渡された生データのみを保存するため、基本的なキーバリューの読み書き機能しか提供していませんでした。さらに、異なるコーディング方式とスコープのないデータ範囲のため、TiDB、トランザクションKV、およびRawKVを同じTiKVクラスターで同時に使用することはできません。そのため、複数のクラスターが必要となり、マシンコストと導入コストが増加します。 - TiKV API V2は、新しいRawKVstorageフォーマットとアクセスインターフェースを提供し、以下の利点をもたらします。 + TiKV API V2は、新しいRawKVストレージフォーマットとアクセスインターフェースを提供し、以下の利点をもたらします。 - MVCCにデータを保存する際に、記録されたデータの変更タイムスタンプを付加します。このタイムスタンプに基づいて変更データキャプチャ（CDC）が実装されます。この機能は実験的であり、詳細は[TiKV-CDC](https://github.com/tikv/migration/blob/main/cdc/README.md)に記載されています。 - - データはさまざまな用途に応じて範囲が定められており、API V2では、単一のクラスタ内でTiDB、トランザクションKV、およびRawKVアプリケーションが共存することをサポートしています。 + - データはさまざまな用途に応じて範囲が定められており、API V2では、単一のクラスター内でTiDB、トランザクションKV、およびRawKVアプリケーションが共存することをサポートしています。 - マルチテナントなどの機能をサポートするために、キースペースフィールドを予約してください。 - TiKV API V2を有効にするには、TiKV設定ファイルの`api-version = 2`セクションに`[storage]` }を設定します。 + TiKV API V2を有効にするには、TiKV設定ファイルの`api-version = 2`セクションに`[ストレージ]` }を設定します。 詳細については、 [ユーザー向けドキュメント](/tikv-configuration-file.md#api-version-new-in-v610)を参照してください。 @@ -227,7 +227,7 @@ TiDBバージョン: 6.4.0-DMR TiDB クラスターが EKS 上にデプロイされ、AWS EBS ボリュームを使用している場合、TiDB クラスター データのバックアップ時に以下の要件を満たす必要がある場合は、 TiDB Operatorを使用してボリューム スナップショットとメタデータによるデータを AWS S3 にバックアップできます。 - - バックアップの影響を最小限に抑える。例えば、QPSとトランザクションレイテンシーへの影響を5%未満に抑え、クラスタのCPUとメモリを消費しないようにする。 + - バックアップの影響を最小限に抑える。例えば、QPSとトランザクションレイテンシーへの影響を5%未満に抑え、クラスターのCPUとメモリを消費しないようにする。 - 短時間でデータのバックアップと復元が可能です。例えば、1時間以内にバックアップを完了し、2時間以内にデータを復元できます。 詳細については、 [ユーザー向けドキュメント](https://docs.pingcap.com/tidb-in-kubernetes/v1.4/backup-to-aws-s3-by-snapshot)を参照してください。 @@ -254,7 +254,7 @@ TiDBバージョン: 6.4.0-DMR バージョン6.4.0以降では、binlogの位置やGTIDを指定せずに、増分移行を直接実行できます。DMは、タスク開始後にアップストリームから生成されたbinlogファイルを自動的に取得し、これらの増分データをダウンストリームに移行します。これにより、ユーザーは面倒な理解や複雑な設定から解放されます。 - 詳細については、 [DM 高度タスクコンフィグレーションファイル](/dm/task-configuration-file-full.md)を参照してください。 + 詳細については、 [DM 高度タスク設定ファイル](/dm/task-configuration-file-full.md)を参照してください。 - DMが移行タスクのステータスインジケーターを追加 [#7343](https://github.com/pingcap/tiflow/issues/7343) [okJiang](https://github.com/okJiang) @@ -281,7 +281,7 @@ TiDBバージョン: 6.4.0-DMR | [`max_execution_time`](/system-variables.md#max_execution_time) | 修正済み | バージョン6.4.0より前は、この変数はすべての種類のステートメントに適用されていました。バージョン6.4.0以降は、この変数は読み取り専用ステートメントの最大実行時間のみを制御します。 | | [`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630) | 修正済み | グローバルスコープを削除し、 [`pessimistic-txn.constraint-check-in-place-pessimistic`](/tidb-configuration-file.md#constraint-check-in-place-pessimistic-new-in-v640)設定項目を使用してデフォルト値を変更できるようにします。この変数は、TiDB が悲観的トランザクション内の一意制約をチェックするタイミングを制御します。 | | [`tidb_ddl_flashback_concurrency`](/system-variables.md#tidb_ddl_flashback_concurrency-new-in-v630) | 修正済み | バージョン6.4.0以降で有効になり、 [`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-cluster.md)の同時実行を制御します。デフォルト値は`64`です。 | -| [`tidb_enable_clustered_index`](/system-variables.md#tidb_enable_clustered_index-new-in-v50) | 修正済み | デフォルト値を`INT_ONLY`から`ON`に変更します。これは、プライマリキーがデフォルトでクラスタ化インデックスとして作成されることを意味します。 | +| [`tidb_enable_clustered_index`](/system-variables.md#tidb_enable_clustered_index-new-in-v50) | 修正済み | デフォルト値を`INT_ONLY`から`ON`に変更します。これは、プライマリキーがデフォルトでクラスター化インデックスとして作成されることを意味します。 | | [`tidb_enable_paging`](/system-variables.md#tidb_enable_paging-new-in-v540) | 修正済み | デフォルト値を`OFF`から`ON`に変更します。これは、コプロセッサ要求を送信するためのページング方式がデフォルトで使用されることを意味します。 | | [`tidb_enable_prepared_plan_cache`](/system-variables.md#tidb_enable_prepared_plan_cache-new-in-v610) | 修正済み | SESSION スコープを追加します。この変数は[プリペアドプランキャッシュ](/sql-prepared-plan-cache.md)を有効にするかどうかを制御します。 | | [`tidb_memory_usage_alarm_ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio) | 修正済み | デフォルト値を`0.8`から`0.7`に変更します。この変数は、tidb-server のメモリアラームをトリガーするメモリ使用率を制御します。 | @@ -304,19 +304,19 @@ TiDBバージョン: 6.4.0-DMR | [`tidb_server_memory_limit_gc_trigger`](/system-variables.md#tidb_server_memory_limit_gc_trigger-new-in-v640) | 新しく追加された | TiDB が GC をトリガーしようとするしきい値を制御します (実験的)。デフォルト値は`70%`です。 | | [`tidb_server_memory_limit_sess_min_size`](/system-variables.md#tidb_server_memory_limit_sess_min_size-new-in-v640) | 新しく追加された | メモリ制限を有効にすると、TiDB は現在のインスタンスで最もメモリ使用量の多い SQL ステートメントを終了します。この変数は、終了する SQL ステートメントの最小メモリ使用量を指定します。デフォルト値は`134217728` (128 MiB) です。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイル | 設定パラメータ | 種類を変更する | 説明 | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | `tidb_memory_usage_alarm_ratio` | 削除済み | この設定項目は無効になりました。 | | TiDB | `memory-usage-alarm-ratio` | 削除済み | システム変数[`tidb_memory_usage_alarm_ratio`](/system-variables.md#tidb_memory_usage_alarm_ratio)に置き換えられました。この設定項目が TiDB バージョン v6.4.0 より前のバージョンで設定されていた場合、アップグレード後には有効になりません。 | | TiDB | [`pessimistic-txn.constraint-check-in-place-pessimistic`](/tidb-configuration-file.md#constraint-check-in-place-pessimistic-new-in-v640) | 新しく追加された | システム変数[`tidb_constraint_check_in_place_pessimistic`](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630)のデフォルト値を制御します。デフォルト値は`true`です。 | | TiDB | [`tidb-max-reuse-chunk`](/tidb-configuration-file.md#tidb-max-reuse-chunk-new-in-v640) | 新しく追加された | チャンク割り当てのキャッシュされたチャンクオブジェクトの最大数を制御します。デフォルト値は`64`です。 | | TiDB | [`tidb-max-reuse-column`](/tidb-configuration-file.md#tidb-max-reuse-column-new-in-v640) | 新しく追加された | チャンク割り当てのキャッシュされた列オブジェクトの最大数を制御します。デフォルト値は`256`です。 | -| ティクヴ | [`cdc.raw-min-ts-outlier-threshold`](https://docs-archive.pingcap.com/tidb/v6.2/tikv-configuration-file#raw-min-ts-outlier-threshold-new-in-v620) | 非推奨 | この設定項目は無効になりました。 | -| ティクヴ | [`causal-ts.alloc-ahead-buffer`](/tikv-configuration-file.md#alloc-ahead-buffer-new-in-v640) | 新しく追加された | 事前割り当て済みのTSOキャッシュサイズ（期間）。デフォルト値は`3s`です。 | -| ティクヴ | [`causal-ts.renew-batch-max-size`](/tikv-configuration-file.md#renew-batch-max-size-new-in-v640) | 新しく追加された | タイムスタンプ要求におけるTSOの最大数を制御します。デフォルト値は`8192`です。 | -| ティクヴ | [`raftstore.apply-yield-write-size`](/tikv-configuration-file.md#apply-yield-write-size-new-in-v640) | 新しく追加された | Applyスレッドが1回のポーリングで1つのFSM（有限状態機械）に対して書き込める最大バイト数を制御します。デフォルト値は`32KiB`です。これはソフトリミットです。 | +| TiKV | [`cdc.raw-min-ts-outlier-threshold`](https://docs-archive.pingcap.com/tidb/v6.2/tikv-configuration-file#raw-min-ts-outlier-threshold-new-in-v620) | 非推奨 | この設定項目は無効になりました。 | +| TiKV | [`causal-ts.alloc-ahead-buffer`](/tikv-configuration-file.md#alloc-ahead-buffer-new-in-v640) | 新しく追加された | 事前割り当て済みのTSOキャッシュサイズ（期間）。デフォルト値は`3s`です。 | +| TiKV | [`causal-ts.renew-batch-max-size`](/tikv-configuration-file.md#renew-batch-max-size-new-in-v640) | 新しく追加された | タイムスタンプ要求におけるTSOの最大数を制御します。デフォルト値は`8192`です。 | +| TiKV | [`raftstore.apply-yield-write-size`](/tikv-configuration-file.md#apply-yield-write-size-new-in-v640) | 新しく追加された | Applyスレッドが1回のポーリングで1つのFSM（有限状態機械）に対して書き込める最大バイト数を制御します。デフォルト値は`32KiB`です。これはソフトリミットです。 | | PD | [`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval) | 新しく追加された | バージョン6.4.0以降で有効になり、PDがTSOの物理時刻を更新する間隔を制御します。デフォルト値は`50ms`です。 | | TiFlash | [`data-encryption-method`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 修正済み | 新しい値オプション`sm4-ctr`が導入されました。この設定項目が`sm4-ctr`に設定されている場合、データは保存される前に SM4 を使用して暗号化されます。 | | DM | [`routes.route-rule-1.extract-table`](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced) | 新しく追加された | オプション。シャーディングシナリオにおいて、シャーディングされたテーブルのソース情報を抽出するために使用します。抽出された情報は、ダウンストリームのマージ済みテーブルに書き込まれ、データソースを識別するために使用されます。このパラメータを設定する場合は、事前にダウンストリームにマージ済みテーブルを手動で作成する必要があります。 | @@ -335,10 +335,10 @@ TiDBバージョン: 6.4.0-DMR - TiDB - 何もしない変数`lc_messages`の変更を許可する [#38231](https://github.com/pingcap/tidb/issues/38231) @[djshow832](https://github.com/djshow832) - - `AUTO_RANDOM`列をクラスタ化複合インデックスの最初の列としてサポートする [#38572](https://github.com/pingcap/tidb/issues/38572) @[tangenta](https://github.com/tangenta) + - `AUTO_RANDOM`列をクラスター化複合インデックスの最初の列としてサポートする [#38572](https://github.com/pingcap/tidb/issues/38572) @[tangenta](https://github.com/tangenta) - 内部トランザクションの再試行では悲観的トランザクションを使用して、再試行の失敗を回避し、時間の消費を削減します [#38136](https://github.com/pingcap/tidb/issues/38136) @[jackysp](https://github.com/jackysp) -- ティクヴ +- TiKV - Applyスレッドが1回のポーリングで1つの有限状態マシンに対して書き込める最大バイト数を制御し、Applyスレッドが大量のデータを書き込む際のRaftstoreの混雑を緩和するために、新しい設定項目`apply-yield-write-size` -0-PLACEHOLDER-E}}を追加します。 [#13313](https://github.com/tikv/tikv/issues/13313) @[glorv](https://github.com/glorv) - リージョンのリーダーを移行する前にエントリキャッシュをウォームアップして、リーダー転送プロセス中のQPSジッターを回避する [#13060](https://github.com/tikv/tikv/issues/13060) @[cosven](https://github.com/cosven) @@ -403,7 +403,7 @@ TiDBバージョン: 6.4.0-DMR - 外部結合が削除された際に`ORDER BY`内の`GROUP_CONCAT`が考慮されず、クエリ結果が誤る問題を修正しました [#18216](https://github.com/pingcap/tidb/issues/18216) @[winoros](https://github.com/winoros) - 結合したテーブルの再配置 [#38736](https://github.com/pingcap/tidb/issues/38736)により誤ってプッシュダウンされた条件が破棄された際に発生する、誤ったクエリ結果の問題を修正しました。@[winoros](https://github.com/winoros) -- ティクヴ +- TiKV - 複数の`cgroup`および`mountinfo`が存在する場合に Gitpod で TiDB が起動に失敗する問題を修正 [#13660](https://github.com/tikv/tikv/issues/13660) @[tabokie](https://github.com/tabokie) - TiKV メトリクスの間違った式を修正`tikv_gc_compaction_filtered` [#13537](https://github.com/tikv/tikv/issues/13537) @[Defined2014](https://github.com/Defined2014) diff --git a/releases/release-6.5.0.md b/releases/release-6.5.0.md index 6128eda5c8401..85bbdd22402aa 100644 --- a/releases/release-6.5.0.md +++ b/releases/release-6.5.0.md @@ -34,7 +34,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - TiDB バックアップ & リストアは、スナップショット チェックポイント バックアップをサポートし、 [PITR](/br/br-pitr-guide.md#run-pitr)のリカバリ パフォーマンスを 50% 向上させ、一般的なシナリオでの RPO を最短 5 分に短縮します。 - [Kafkaへのデータの複製](/replicate-data-to-kafka.md)の TiCDC スループットを 4000 行/秒から 35000 行/秒に向上し、レプリケーションのレイテンシーを2 秒に短縮します。 - データのライフサイクルを管理するために行レベル[存続時間（TTL）](/time-to-live.md)を提供します (実験的)。 -- TiCDC は、Amazon S3、Azure Blob Storage、NFS (実験的) など[変更ログをオブジェクトstorageに複製する](/ticdc/ticdc-sink-to-cloud-storage.md)サポートしています。 +- TiCDC は、Amazon S3、Azure Blob Storage、NFS (実験的) など[変更ログをオブジェクトストレージに複製する](/ticdc/ticdc-sink-to-cloud-ストレージ.md)サポートしています。 ## 新機能 {#new-features} @@ -58,7 +58,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - `INSERT` `UPDATE`含む非トランザクションDMLステートメント`DELETE` [＃33485](https://github.com/pingcap/tidb/issues/33485)にサポートし[エキシウム](https://github.com/ekexium) `REPLACE` - 大規模データ処理のシナリオでは、大規模なトランザクションを含む単一のSQL文が、クラスタの安定性とパフォーマンスに悪影響を及ぼす可能性があります。非トランザクションDML文とは、内部実行のために複数のSQL文に分割されたDML文です。分割された文はトランザクションの原子性と独立性を損なう一方で、クラスタの安定性を大幅に向上させます。TiDBはバージョン6.1.0以降、非トランザクション`DELETE`文をサポートしており、バージョン6.5.0以降、非トランザクション`INSERT`文`REPLACE`サポートしてい`UPDATE` 。 + 大規模データ処理のシナリオでは、大規模なトランザクションを含む単一のSQL文が、クラスターの安定性とパフォーマンスに悪影響を及ぼす可能性があります。非トランザクションDML文とは、内部実行のために複数のSQL文に分割されたDML文です。分割された文はトランザクションの原子性と独立性を損なう一方で、クラスターの安定性を大幅に向上させます。TiDBはバージョン6.1.0以降、非トランザクション`DELETE`文をサポートしており、バージョン6.5.0以降、非トランザクション`INSERT`文`REPLACE`サポートしてい`UPDATE` 。 詳細については、 [非トランザクションDMLステートメント](/non-transactional-dml.md)および[`BATCH`構文](/sql-statements/sql-statement-batch.md)を参照してください。 @@ -159,7 +159,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - `->>` - `JSON_EXTRACT()` - JSON形式は、アプリケーションのデータモデリングに柔軟な方法を提供します。そのため、ますます多くのアプリケーションがデータ交換とデータstorageにJSON形式を使用しています。JSON関数をTiFlashにプッシュダウンすることで、JSON型のデータ分析の効率を向上させ、TiDBをよりリアルタイムな分析シナリオに活用できるようになります。 + JSON形式は、アプリケーションのデータモデリングに柔軟な方法を提供します。そのため、ますます多くのアプリケーションがデータ交換とデータストレージにJSON形式を使用しています。JSON関数をTiFlashにプッシュダウンすることで、JSON型のデータ分析の効率を向上させ、TiDBをよりリアルタイムな分析シナリオに活用できるようになります。 - 以下の文字列関数をTiFlash [＃6115](https://github.com/pingcap/tiflash/issues/6115) @ [xzhangxian1008](https://github.com/xzhangxian1008)にプッシュダウンすることをサポートします @@ -179,7 +179,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - オプティマイザーはより正確なコストモデルバージョン2（GA） [＃35240](https://github.com/pingcap/tidb/issues/35240) @ [qw4990](https://github.com/qw4990)を導入しました - TiDB v6.2.0 では、 [コストモデル バージョン 2](/cost-model.md#cost-model-version-2)実験的機能として導入されました。このモデルは、より正確なコスト推定手法を用いて、オプティマイザーが最適な実行プランを選択できるように支援します。特にTiFlashを導入している場合、コストモデル バージョン 2 は適切なstorageエンジンを自動的に選択し、手動による介入を大幅に削減します。一定期間の実環境テストを経て、このモデルは v6.5.0 で一般提供となります。v6.5.0 以降、新規に作成されたクラスターはデフォルトでコストモデル バージョン 2 を使用します。v6.5.0 にアップグレードするクラスターでは、コストモデル バージョン 2 によってクエリプランが変更される可能性があるため、十分なパフォーマンステストを行った後、 [`tidb_cost_model_version = 2`](/system-variables.md#tidb_cost_model_version-new-in-v620)変数を設定して新しいコストモデルを使用するように設定できます。 + TiDB v6.2.0 では、 [コストモデル バージョン 2](/cost-model.md#cost-model-version-2)実験的機能として導入されました。このモデルは、より正確なコスト推定手法を用いて、オプティマイザーが最適な実行プランを選択できるように支援します。特にTiFlashを導入している場合、コストモデル バージョン 2 は適切なストレージエンジンを自動的に選択し、手動による介入を大幅に削減します。一定期間の実環境テストを経て、このモデルは v6.5.0 で一般提供となります。v6.5.0 以降、新規に作成されたクラスターはデフォルトでコストモデル バージョン 2 を使用します。v6.5.0 にアップグレードするクラスターでは、コストモデル バージョン 2 によってクエリプランが変更される可能性があるため、十分なパフォーマンステストを行った後、 [`tidb_cost_model_version = 2`](/system-variables.md#tidb_cost_model_version-new-in-v620)変数を設定して新しいコストモデルを使用するように設定できます。 コスト モデル バージョン 2 は、TiDB オプティマイザーの全体的な機能を大幅に向上させ、TiDB をより強力な HTAP データベースへと進化させる、一般利用可能な機能になります。 @@ -219,7 +219,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - 高性能かつグローバルに単調な`AUTO_INCREMENT`列属性 (GA) [＃38442](https://github.com/pingcap/tidb/issues/38442) @ [tiancaiamao](https://github.com/tiancaiamao)をサポート - TiDBはv6.4.0以降、実験的機能としてMySQL互換モード`AUTO_INCREMENT`導入しました。このモードでは、すべてのTiDBインスタンスでIDが単調に増加するようにする、集中型の自動インクリメントID割り当てサービスが導入されます。この機能により、自動インクリメントIDによるクエリ結果のソートが容易になります。v6.5.0では、この機能がGAになります。この機能を使用したテーブルの挿入TPSは20,000を超えると予想されており、この機能は単一のテーブルとクラスタ全体の書き込みスループットを向上させるためのエラスティックスケーリングをサポートしています。MySQL互換モードを使用するには、テーブル作成時に`AUTO_ID_CACHE` `1`設定する必要があります。以下は例です。 + TiDBはv6.4.0以降、実験的機能としてMySQL互換モード`AUTO_INCREMENT`導入しました。このモードでは、すべてのTiDBインスタンスでIDが単調に増加するようにする、集中型の自動インクリメントID割り当てサービスが導入されます。この機能により、自動インクリメントIDによるクエリ結果のソートが容易になります。v6.5.0では、この機能がGAになります。この機能を使用したテーブルの挿入TPSは20,000を超えると予想されており、この機能は単一のテーブルとクラスター全体の書き込みスループットを向上させるためのエラスティックスケーリングをサポートしています。MySQL互換モードを使用するには、テーブル作成時に`AUTO_ID_CACHE` `1`設定する必要があります。以下は例です。 ```sql CREATE TABLE t(a int AUTO_INCREMENT key) AUTO_ID_CACHE 1; @@ -233,7 +233,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では Dumpling は、gzip、snappy、zstd などの圧縮形式で圧縮された SQL ファイルおよび CSV ファイルへのデータのエクスポートをサポートしています。TiDB Lightning は、これらの形式で圧縮されたファイルのインポートもサポートしています。 - これまで、CSVファイルやSQLファイルの保存には、データのエクスポートやインポートに大量のstorage容量が必要であり、storageコストが高くなっていました。この機能のリリースにより、データファイルを圧縮することで、storageコストを大幅に削減できます。 + これまで、CSVファイルやSQLファイルの保存には、データのエクスポートやインポートに大量のストレージ容量が必要であり、ストレージコストが高くなっていました。この機能のリリースにより、データファイルを圧縮することで、ストレージコストを大幅に削減できます。 詳細については[ドキュメント](/dumpling-overview.md#improve-export-efficiency-through-concurrency)参照してください。 @@ -261,15 +261,15 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では ### TiDBデータ共有サブスクリプション {#tidb-data-share-subscription} -- TiCDC は、変更されたログをstorageシンクに複製することをサポートしています (実験的) [＃6797](https://github.com/pingcap/tiflow/issues/6797) @ [zhaoxinyu](https://github.com/zhaoxinyu) +- TiCDC は、変更されたログをストレージシンクに複製することをサポートしています (実験的) [＃6797](https://github.com/pingcap/tiflow/issues/6797) @ [zhaoxinyu](https://github.com/zhaoxinyu) - TiCDCは、Amazon S3、Azure Blob Storage、NFS、その他のS3互換storageサービスへの変更ログのレプリケーションをサポートしています。クラウドstorageは手頃な価格で使いやすいです。Kafkaを使用していない場合は、storageシンクを使用できます。TiCDCは変更ログをファイルに保存し、storageシステムに送信します。コンシューマープログラムは、storageシステムから新しく生成された変更ログファイルを定期的に読み取ります。 + TiCDCは、Amazon S3、Azure Blob Storage、NFS、その他のS3互換ストレージサービスへの変更ログのレプリケーションをサポートしています。クラウドストレージは手頃な価格で使いやすいです。Kafkaを使用していない場合は、ストレージシンクを使用できます。TiCDCは変更ログをファイルに保存し、ストレージシステムに送信します。コンシューマープログラムは、ストレージシステムから新しく生成された変更ログファイルを定期的に読み取ります。 - storageシンクは、canal-json形式とCSV形式の変更ログをサポートしています。詳細については、 [ドキュメント](/ticdc/ticdc-sink-to-cloud-storage.md)ご覧ください。 + ストレージシンクは、canal-json形式とCSV形式の変更ログをサポートしています。詳細については、 [ドキュメント](/ticdc/ticdc-sink-to-cloud-ストレージ.md)ご覧ください。 -- TiCDCは2つのクラスタ間の双方向レプリケーションをサポートします[＃38587](https://github.com/pingcap/tidb/issues/38587) @ [xiongjiwei](https://github.com/xiongjiwei) @ [asddongmen](https://github.com/asddongmen) +- TiCDCは2つのクラスター間の双方向レプリケーションをサポートします[＃38587](https://github.com/pingcap/tidb/issues/38587) @ [xiongjiwei](https://github.com/xiongjiwei) @ [asddongmen](https://github.com/asddongmen) - TiCDCは、2つのTiDBクラスタ間の双方向レプリケーションをサポートしています。アプリケーションのために地理的に分散された複数のアクティブデータセンターを構築する必要がある場合、この機能をソリューションとして利用できます。TiCDCの変更フィードに`bdr-mode = true`パラメータを設定することで、あるTiDBクラスタから別のTiDBクラスタへのデータレプリケーションを実現できます。 + TiCDCは、2つのTiDBクラスター間の双方向レプリケーションをサポートしています。アプリケーションのために地理的に分散された複数のアクティブデータセンターを構築する必要がある場合、この機能をソリューションとして利用できます。TiCDCの変更フィードに`bdr-mode = true`パラメータを設定することで、あるTiDBクラスターから別のTiDBクラスターへのデータレプリケーションを実現できます。 詳細については[ドキュメント](/ticdc/ticdc-bidirectional-replication.md)参照してください。 @@ -279,7 +279,7 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では - TiCDCのパフォーマンスが大幅に向上[＃7540](https://github.com/pingcap/tiflow/issues/7540) [＃7478](https://github.com/pingcap/tiflow/issues/7478) [＃7532](https://github.com/pingcap/tiflow/issues/7532) @ [sdojjy](https://github.com/sdojjy) @ [3AceShowHand](https://github.com/3AceShowHand) - TiDBクラスタのテストシナリオでは、TiCDCのパフォーマンスが大幅に向上しました。具体的には、シナリオ[Kafkaへのデータの複製](/replicate-data-to-kafka.md)では、単一のTiCDCが処理できる行変更の最大量は3万行/秒に達し、レプリケーションのレイテンシーは10秒に短縮されました。TiKVとTiCDCのローリングアップグレード中でも、レプリケーションのレイテンシーは30秒未満です。 + TiDBクラスターのテストシナリオでは、TiCDCのパフォーマンスが大幅に向上しました。具体的には、シナリオ[Kafkaへのデータの複製](/replicate-data-to-kafka.md)では、単一のTiCDCが処理できる行変更の最大量は3万行/秒に達し、レプリケーションのレイテンシーは10秒に短縮されました。TiKVとTiCDCのローリングアップグレード中でも、レプリケーションのレイテンシーは30秒未満です。 災害復旧 (DR) シナリオでは、TiCDC の再実行ログと同期ポイントを有効にすると、TiCDC のスループットを 4000 行/秒から 35000 行/秒に向上でき、レプリケーションのレイテンシーを2 秒に制限できます。 @@ -346,9 +346,9 @@ TiDB [6.4.0-DMR](/releases/release-6.4.0.md)と比較して、TiDB 6.5.0 では | [`validate_password.policy`](/system-variables.md#validate_passwordpolicy-new-in-v650) | 新しく追加された | この変数は、パスワードの複雑さチェックのポリシーを制御します。値は`0` 、 `1` 、または`2` （それぞれLOW、MEDIUM、STRONGに対応）です。この変数は、 [`validate_password.enable`](/system-variables.md#password_reuse_interval-new-in-v650)が有効な場合にのみ有効になります。デフォルト値は`1`です。 | | [`validate_password.special_char_count`](/system-variables.md#validate_passwordspecial_char_count-new-in-v650) | 新しく追加された | パスワード複雑度チェックにおけるチェック項目。パスワードに十分な特殊文字が含まれているかどうかをチェックします。この変数は、 [`validate_password.enable`](/system-variables.md#password_reuse_interval-new-in-v650)が有効で、 [`validate_password.policy`](/system-variables.md#validate_passwordpolicy-new-in-v650) `1` （中）以上に設定されている場合にのみ有効になります。デフォルト値は`1`です。 | -### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} +### 設定ファイルのパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | タイプを変更 | 説明 | +| 設定ファイル | 設定パラメータ | タイプを変更 | 説明 | | -------------- | ---------------------------------------------------------------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`server-memory-quota`](/tidb-configuration-file.md#server-memory-quota-new-in-v409) | 非推奨 | バージョン6.5.0以降、この設定項目は非推奨となりました。代わりに、システム変数[`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)を使用してメモリをグローバルに管理してください。 | | TiDB | [`disconnect-on-expired-password`](/tidb-configuration-file.md#disconnect-on-expired-password-new-in-v650) | 新しく追加された | パスワードの有効期限が切れたときに、TiDBがクライアント接続を切断するかどうかを決定します。デフォルト値は`true`で、パスワードの有効期限が切れるとクライアント接続が切断されます。 | @@ -387,7 +387,7 @@ v6.5.0 以降では、v4.0.7 で導入された`AMEND TRANSACTION`メカニズ - 1回のバックアップ要求で複数の範囲のデータのバックアップをサポート[＃13701](https://github.com/tikv/tikv/issues/13701) @ [Leavrth](https://github.com/Leavrth) - rusotoライブラリ[＃13751](https://github.com/tikv/tikv/issues/13751) @ [3pointer](https://github.com/3pointer)を更新してAWSのアジア太平洋地域（ap-southeast-3）へのデータバックアップをサポート - 悲観的トランザクション競合を減らす[＃13298](https://github.com/tikv/tikv/issues/13298) @ [MyonKeminta](https://github.com/MyonKeminta) - - 外部storageオブジェクト[＃13798](https://github.com/tikv/tikv/issues/13798) @ [YuJuncen](https://github.com/YuJuncen)をキャッシュすることでリカバリパフォーマンスを向上 + - 外部ストレージオブジェクト[＃13798](https://github.com/tikv/tikv/issues/13798) @ [YuJuncen](https://github.com/YuJuncen)をキャッシュすることでリカバリパフォーマンスを向上 - 専用スレッドで CheckLeader を実行して、TiCDC レプリケーションのレイテンシー[＃13774](https://github.com/tikv/tikv/issues/13774) @ [overvenus](https://github.com/overvenus)を削減します。 - チェックポイント[＃13824](https://github.com/tikv/tikv/issues/13824) @ [YuJuncen](https://github.com/YuJuncen)のプル モデルをサポート - クロスビームチャネル[＃13815](https://github.com/tikv/tikv/issues/13815) [スティクナーフ](https://github.com/sticnarf)に更新することで、送信側での回転の問題を回避します。 @@ -401,7 +401,7 @@ v6.5.0 以降では、v4.0.7 で導入された`AMEND TRANSACTION`メカニズ - PD - ロックの粒度を最適化してロックの競合を減らし、高同時実行時のハートビートの処理能力を向上させる[＃5586](https://github.com/tikv/pd/issues/5586) @ [rleungx](https://github.com/rleungx) - - 大規模クラスタのスケジューラパフォーマンスを最適化し、スケジューリングポリシー[＃5473](https://github.com/tikv/pd/issues/5473) @ [bufferflies](https://github.com/bufferflies)の本番を高速化します。 + - 大規模クラスターのスケジューラパフォーマンスを最適化し、スケジューリングポリシー[＃5473](https://github.com/tikv/pd/issues/5473) @ [bufferflies](https://github.com/bufferflies)の本番を高速化します。 - リージョン[＃5606](https://github.com/tikv/pd/issues/5606) @ [rleungx](https://github.com/rleungx)の読み込み速度を向上 - リージョンハートビート[＃5648](https://github.com/tikv/pd/issues/5648) @ [rleungx](https://github.com/rleungx)の最適化された処理により不要なオーバーヘッドを削減 - 墓石ストア[＃5348](https://github.com/tikv/pd/issues/5348) @ [nolouch](https://github.com/nolouch)の自動ガベージコレクション機能を追加 @@ -475,7 +475,7 @@ v6.5.0 以降では、v4.0.7 で導入された`AMEND TRANSACTION`メカニズ - BRがログバックアップデータを削除するときに、削除されるべきでないデータを誤って削除してしまう問題を修正[＃38939](https://github.com/pingcap/tidb/issues/38939) @ [Leavrth](https://github.com/Leavrth) - データベースまたはテーブル[＃39150](https://github.com/pingcap/tidb/issues/39150) @ [MoCuishle28](https://github.com/MoCuishle28)の照合に古いフレームワークを使用すると復元タスクが失敗する問題を修正しました - - Alibaba CloudとHuawei CloudがAmazon S3storage[＃39545](https://github.com/pingcap/tidb/issues/39545) @ [3pointer](https://github.com/3pointer)と完全に互換性がないため、バックアップが失敗する問題を修正 + - Alibaba CloudとHuawei CloudがAmazon S3ストレージ[＃39545](https://github.com/pingcap/tidb/issues/39545) @ [3pointer](https://github.com/3pointer)と完全に互換性がないため、バックアップが失敗する問題を修正 - TiCDC diff --git a/releases/release-6.5.1.md b/releases/release-6.5.1.md index 4a7edbf844675..8b4a3aa3f4e40 100644 --- a/releases/release-6.5.1.md +++ b/releases/release-6.5.1.md @@ -31,16 +31,16 @@ TiDB バージョン: 6.5.1 - TiDB - - v6.5.1以降、 TiDB Operator v1.4.3以降でデプロイされたTiDBクラスタはIPv6アドレスをサポートします。これにより、TiDBはより広いアドレス空間をサポートし、セキュリティとネットワークパフォーマンスを向上させることができます。 + - v6.5.1以降、 TiDB Operator v1.4.3以降でデプロイされたTiDBクラスターはIPv6アドレスをサポートします。これにより、TiDBはより広いアドレス空間をサポートし、セキュリティとネットワークパフォーマンスを向上させることができます。 - IPv6 アドレスの完全サポート: TiDB は、クライアント接続、ノード間の内部通信、外部システムとの通信など、すべてのネットワーク接続で IPv6 アドレスの使用をサポートします。 - - デュアルスタックのサポート：まだIPv6への完全移行の準備が整っていない場合でも、TiDBはデュアルスタックネットワークをサポートしています。つまり、同じTiDBクラスタ内でIPv4とIPv6の両方のアドレスを使用し、設定によってIPv6を優先するネットワーク展開モードを選択できます。 + - デュアルスタックのサポート：まだIPv6への完全移行の準備が整っていない場合でも、TiDBはデュアルスタックネットワークをサポートしています。つまり、同じTiDBクラスター内でIPv4とIPv6の両方のアドレスを使用し、設定によってIPv6を優先するネットワーク展開モードを選択できます。 IPv6 の導入の詳細については、 [Kubernetes 上の TiDB ドキュメント](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster#ipv6-support)参照してください。 - - TiDB クラスタの初期化時に実行される SQL スクリプトの指定をサポート[＃35624](https://github.com/pingcap/tidb/issues/35624) @ [morgo](https://github.com/morgo) + - TiDB クラスターの初期化時に実行される SQL スクリプトの指定をサポート[＃35624](https://github.com/pingcap/tidb/issues/35624) @ [morgo](https://github.com/morgo) - TiDB v6.5.1 では、新しい設定項目[`initialize-sql-file`](https://docs.pingcap.com/tidb/v6.5/tidb-configuration-file#initialize-sql-file-new-in-v651)が追加されました。TiDB クラスタを初めて起動する際に、コマンドラインパラメータ`--initialize-sql-file`を設定することで、実行する SQL スクリプトを指定できます。この機能は、システム変数の値の変更、ユーザーの作成、権限の付与などの操作を行う際に使用できます。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v6.5/tidb-configuration-file#initialize-sql-file-new-in-v651)参照してください。 + TiDB v6.5.1 では、新しい設定項目[`initialize-sql-file`](https://docs.pingcap.com/tidb/v6.5/tidb-configuration-file#initialize-sql-file-new-in-v651)が追加されました。TiDB クラスターを初めて起動する際に、コマンドラインパラメータ`--initialize-sql-file`を設定することで、実行する SQL スクリプトを指定できます。この機能は、システム変数の値の変更、ユーザーの作成、権限の付与などの操作を行う際に使用できます。詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v6.5/tidb-configuration-file#initialize-sql-file-new-in-v651)参照してください。 - メモリリークとパフォーマンスの低下を防ぐため、期限切れのリージョンキャッシュを定期的にクリアします[＃40461](https://github.com/pingcap/tidb/issues/40461) @ [sticnarf](https://github.com/sticnarf) @@ -71,7 +71,7 @@ TiDB バージョン: 6.5.1 - TiCDC - プルベースのシンクを有効にしてシステムスループットを最適化します[＃8232](https://github.com/pingcap/tiflow/issues/8232) @ [Rustin170506](https://github.com/Rustin170506) - - GCS 互換または Azure 互換のオブジェクトstorage[＃7987](https://github.com/pingcap/tiflow/issues/7987) @ [CharlesCheung96](https://github.com/CharlesCheung96)への REDO ログの保存をサポート + - GCS 互換または Azure 互換のオブジェクトストレージ[＃7987](https://github.com/pingcap/tiflow/issues/7987) @ [CharlesCheung96](https://github.com/CharlesCheung96)への REDO ログの保存をサポート - シンクのスループットを向上させるために、非同期モードでMQシンクとMySQLシンクを実装します[＃5928](https://github.com/pingcap/tiflow/issues/5928) @ [amyangfei](https://github.com/amyangfei) @ [CharlesCheung96](https://github.com/CharlesCheung96) ## バグ修正 {#bug-fixes} @@ -134,7 +134,7 @@ TiDB バージョン: 6.5.1 - PD - 特定の条件下で実行`replace-down-peer`が遅くなる問題を修正[＃5788](https://github.com/tikv/pd/issues/5788) @ [HunDunDM](https://github.com/HunDunDM) - - PD が予期せず複数の学習者をリージョン[＃5786](https://github.com/tikv/pd/issues/5786) @ [HunDunDM](https://github.com/HunDunDM)に追加する可能性がある問題を修正しました。 + - PD が予期せず複数のラーナーをリージョン[＃5786](https://github.com/tikv/pd/issues/5786) @ [HunDunDM](https://github.com/HunDunDM)に追加する可能性がある問題を修正しました。 - リージョンスキャッタタスクが予期せず冗長レプリカを生成する問題を修正[＃5909](https://github.com/tikv/pd/issues/5909) @ [HunDunDM](https://github.com/HunDunDM) - `ReportMinResolvedTS`の呼び出しが[＃5965](https://github.com/tikv/pd/issues/5965) @ [HunDunDM](https://github.com/HunDunDM)で頻繁に発生する PD OOM 問題を修正しました - リージョン散布により、リーダー[＃6017](https://github.com/tikv/pd/issues/6017) @ [HunDunDM](https://github.com/HunDunDM)の分布が不均一になる可能性がある問題を修正しました。 @@ -153,13 +153,13 @@ TiDB バージョン: 6.5.1 - PDとtidb-server間の接続障害により、PITRバックアップの進行が[＃41082](https://github.com/pingcap/tidb/issues/41082) @ [YuJuncen](https://github.com/YuJuncen)に進まない問題を修正しました。 - PDとTiKV [＃14159](https://github.com/tikv/tikv/issues/14159) @ [YuJuncen](https://github.com/YuJuncen)間の接続障害によりTiKVがPITRタスクをリッスンできない問題を修正しました - - PITRがPDクラスタ[＃14165](https://github.com/tikv/tikv/issues/14165) @ [YuJuncen](https://github.com/YuJuncen)の構成変更をサポートしない問題を修正 + - PITRがPDクラスター[＃14165](https://github.com/tikv/tikv/issues/14165) @ [YuJuncen](https://github.com/YuJuncen)の構成変更をサポートしない問題を修正 - PITR機能がCAバンドル[＃38775](https://github.com/pingcap/tidb/issues/38775) @ [3pointer](https://github.com/3pointer)をサポートしない問題を修正 - PITRバックアップタスクを削除すると、残りのバックアップデータによって新しいタスク[#40403](https://github.com/pingcap/tidb/issues/40403) @ [joccau](https://github.com/joccau)でデータの不整合が発生する問題を修正しました。 - BRが`backupmeta`ファイル[＃40878](https://github.com/pingcap/tidb/issues/40878) @ [MoCuishle28](https://github.com/MoCuishle28)を解析するときにpanicを引き起こす問題を修正しました - リージョンサイズ[＃36053](https://github.com/pingcap/tidb/issues/36053) @ [YuJuncen](https://github.com/YuJuncen)取得に失敗したために復元が中断される問題を修正しました - - TiDBクラスタ[＃40759](https://github.com/pingcap/tidb/issues/40759) @ [joccau](https://github.com/joccau)にPITRバックアップタスクがない場合に頻度`resolve lock`が高すぎる問題を修正 - - ログバックアップが実行中のクラスタにデータを復元すると、ログバックアップファイルが復元できなくなる問題を修正[＃40797](https://github.com/pingcap/tidb/issues/40797) @ [Leavrth](https://github.com/Leavrth) + - TiDBクラスター[＃40759](https://github.com/pingcap/tidb/issues/40759) @ [joccau](https://github.com/joccau)にPITRバックアップタスクがない場合に頻度`resolve lock`が高すぎる問題を修正 + - ログバックアップが実行中のクラスターにデータを復元すると、ログバックアップファイルが復元できなくなる問題を修正[＃40797](https://github.com/pingcap/tidb/issues/40797) @ [Leavrth](https://github.com/Leavrth) - 完全バックアップの失敗後にチェックポイントからバックアップを再開しようとしたときに発生するpanicの問題を修正[＃40704](https://github.com/pingcap/tidb/issues/40704) @ [Leavrth](https://github.com/Leavrth) - PITRエラーが[＃40576](https://github.com/pingcap/tidb/issues/40576) @ [Leavrth](https://github.com/Leavrth)で上書きされる問題を修正 - PITR バックアップ タスクで、先行所有者と GC 所有者が異なる場合にチェックポイントが進まない問題を修正しました[＃41806](https://github.com/pingcap/tidb/issues/41806) @ [joccau](https://github.com/joccau) @@ -167,8 +167,8 @@ TiDB バージョン: 6.5.1 - TiCDC - TiKV または TiCDC ノード[＃8174](https://github.com/pingcap/tiflow/issues/8174) @ [hicqu](https://github.com/hicqu)スケールインまたはスケールアウトなどの特別なシナリオで、changefeed がスタックする可能性がある問題を修正しました。 - - REDOログ[＃6335](https://github.com/pingcap/tiflow/issues/6335) @ [CharlesCheung96](https://github.com/CharlesCheung96)のstorageパスで事前チェックが実行されない問題を修正 - - S3storage障害[＃8089](https://github.com/pingcap/tiflow/issues/8089) @ [CharlesCheung96](https://github.com/CharlesCheung96)に対して、REDO ログが許容できる期間が不十分である問題を修正しました + - REDOログ[＃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)に対して、REDO ログが許容できる期間が不十分である問題を修正しました - `transaction-atomicity`と`protocol`構成ファイル[＃7935](https://github.com/pingcap/tiflow/issues/7935) @ [CharlesCheung96](https://github.com/CharlesCheung96)経由で更新できない問題を修正 - TiCDC が過度に多数のテーブル[＃8004](https://github.com/pingcap/tiflow/issues/8004) @ [overvenus](https://github.com/overvenus)を複製するとチェックポイントが進めなくなる問題を修正しました - レプリケーション遅延が過度に高い場合に、REDOログを適用するとOOMが発生する可能性がある問題を修正[＃8085](https://github.com/pingcap/tiflow/issues/8085) @ [CharlesCheung96](https://github.com/CharlesCheung96) diff --git a/releases/release-6.5.10.md b/releases/release-6.5.10.md index 4f708cf3e85be..0b7aa6b140136 100644 --- a/releases/release-6.5.10.md +++ b/releases/release-6.5.10.md @@ -38,7 +38,7 @@ TiDB バージョン: 6.5.10 - TiCDC - - ダウンストリームがメッセージキュー（MQ）またはクラウドstorageの場合に生のイベントを直接出力することをサポートします[＃11211](https://github.com/pingcap/tiflow/issues/11211) @ [CharlesCheung96](https://github.com/CharlesCheung96) + - ダウンストリームがメッセージキュー（MQ）またはクラウドストレージの場合に生のイベントを直接出力することをサポートします[＃11211](https://github.com/pingcap/tiflow/issues/11211) @ [CharlesCheung96](https://github.com/CharlesCheung96) - REDOログを使用してデータリカバリ中のメモリの安定性を向上させ、OOM [＃10900](https://github.com/pingcap/tiflow/issues/10900) @ [CharlesCheung96](https://github.com/CharlesCheung96)の確率を低減します。 - トランザクション競合シナリオにおけるデータレプリケーションの安定性が大幅に向上し、パフォーマンスが最大10倍向上します[＃10896](https://github.com/pingcap/tiflow/issues/10896) @ [CharlesCheung96](https://github.com/CharlesCheung96) @@ -57,7 +57,7 @@ TiDB バージョン: 6.5.10 - クエリ内の特定のフィルター条件により、プランナーモジュールが`invalid memory address or nil pointer dereference`エラー[＃53582](https://github.com/pingcap/tidb/issues/53582) [＃53580](https://github.com/pingcap/tidb/issues/53580) [＃53594](https://github.com/pingcap/tidb/issues/53594) [＃53603](https://github.com/pingcap/tidb/issues/53603) @ [YangKeao](https://github.com/YangKeao)を報告する可能性がある問題を修正しました - `?`引数を含む`CONV` `EXECUTE` `PREPARE`を複数回実行すると、誤ったクエリ結果が返される可能性がある問題を修正しました[＃53505](https://github.com/pingcap/tidb/issues/53505) @ [qw4990](https://github.com/qw4990) - オプティマイザーヒント[＃53767](https://github.com/pingcap/tidb/issues/53767) @ [hawkingrei](https://github.com/hawkingrei)使用時に誤った警告情報が表示される問題を修正しました - - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、古い読み取りのクエリレイテンシーが増加する問題を修正しました。 + - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、ステイル読み取りのクエリレイテンシーが増加する問題を修正しました。 - DDL ステートメントが etcd を誤って使用し、タスクが[＃52335](https://github.com/pingcap/tidb/issues/52335) @ [wjhuang2016](https://github.com/wjhuang2016)でキューに入れられる問題を修正しました。 - 式インデックス[＃51431](https://github.com/pingcap/tidb/issues/51431) @ [ywqzzy](https://github.com/ywqzzy)の名前を変更する`RENAME INDEX`を実行したときに内部列の名前が変更されない問題を修正しました - `CREATE OR REPLACE VIEW`同時に実行すると`table doesn't exist`エラー[＃53673](https://github.com/pingcap/tidb/issues/53673) @ [tangenta](https://github.com/tangenta)が発生する可能性がある問題を修正 @@ -108,7 +108,7 @@ TiDB バージョン: 6.5.10 - データベース間で`ALTER TABLE ... EXCHANGE PARTITION`実行した後にTiFlash がスキーマの同期に失敗する可能性がある問題を修正しました[＃7296](https://github.com/pingcap/tiflash/issues/7296) @ [JaySon-Huang](https://github.com/JaySon-Huang) - 空のキー範囲を持つクエリがTiFlashで読み取りタスクを正しく生成できず、 TiFlashクエリ[＃9108](https://github.com/pingcap/tiflash/issues/9108) @ [JinheLin](https://github.com/JinheLin)がブロックされる可能性がある問題を修正しました。 - `SUBSTRING_INDEX()`関数が一部のコーナーケースでTiFlash のクラッシュを引き起こす可能性がある問題を修正[＃9116](https://github.com/pingcap/tiflash/issues/9116) @ [wshwsh12](https://github.com/wshwsh12) - - クラスタをv6.5.0より前のバージョンからv6.5.0以降にアップグレードするときに、 TiFlashメタデータが破損してプロセスがpanicになる可能性がある問題を修正しました[＃9039](https://github.com/pingcap/tiflash/issues/9039) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - クラスターをv6.5.0より前のバージョンからv6.5.0以降にアップグレードするときに、 TiFlashメタデータが破損してプロセスがpanicになる可能性がある問題を修正しました[＃9039](https://github.com/pingcap/tiflash/issues/9039) @ [JaySon-Huang](https://github.com/JaySon-Huang) - TiFlash が高同時読み取りシナリオで一時的に誤った結果を返す可能性がある問題を修正[＃8845](https://github.com/pingcap/tiflash/issues/8845) @ [JinheLin](https://github.com/JinheLin) - ツール @@ -137,7 +137,7 @@ TiDB バージョン: 6.5.10 - PDLeaderを強制終了すると、 TiDB Lightningがデータインポート[＃50501](https://github.com/pingcap/tidb/issues/50501) @ [Leavrth](https://github.com/Leavrth)中に`invalid store ID 0`エラーを報告する問題を修正しました。 - TiDB Lightning Grafanaダッシュボード[＃43357](https://github.com/pingcap/tidb/issues/43357) @ [lichunzhu](https://github.com/lichunzhu)でデータが欠落する問題を修正 - TiDB Lightningがサーバーモード[＃36374](https://github.com/pingcap/tidb/issues/36374) @ [kennytm](https://github.com/kennytm)でログに機密情報を出力する可能性がある問題を修正しました - - TiDB Lightning [＃52654](https://github.com/pingcap/tidb/issues/52654) @ [D3Hunter](https://github.com/D3Hunter)を使用して`SHARD_ROW_ID_BITS`と`AUTO_ID_CACHE=1`両方が設定されたテーブルをインポートした後、TiDB が自動増分 ID を生成できず、エラー`Failed to read auto-increment value from storage engine`を報告する問題を修正しました。 + - TiDB Lightning [＃52654](https://github.com/pingcap/tidb/issues/52654) @ [D3Hunter](https://github.com/D3Hunter)を使用して`SHARD_ROW_ID_BITS`と`AUTO_ID_CACHE=1`両方が設定されたテーブルをインポートした後、TiDB が自動増分 ID を生成できず、エラー`Failed to read auto-increment value from ストレージ engine`を報告する問題を修正しました。 - Dumpling diff --git a/releases/release-6.5.11.md b/releases/release-6.5.11.md index 6e7e373b2d6ec..bdcaa1bc8e042 100644 --- a/releases/release-6.5.11.md +++ b/releases/release-6.5.11.md @@ -99,13 +99,13 @@ TiDBバージョン: 6.5.11 - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取り要求タイムアウトエラー[＃9243](https://github.com/pingcap/tiflash/issues/9243) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger)が発生する可能性がある問題を修正しました。 - 外部結合[＃9190](https://github.com/pingcap/tiflash/issues/9190) @ [windtalker](https://github.com/windtalker)を含むクエリの実行中にエラーが発生した場合にTiFlashがクラッシュする可能性がある問題を修正しました。 - データ型を`DECIMAL`に変換すると、一部のコーナーケースで誤ったクエリ結果が発生する可能性がある問題を修正しました[＃53892](https://github.com/pingcap/tidb/issues/53892) @ [guo-shaoge](https://github.com/guo-shaoge) - - クラスタ内で長期間にわたって頻繁に`EXCHANGE PARTITION`と`DROP TABLE`操作を行うと、 TiFlashテーブル メタデータのレプリケーションが遅くなり、クエリ パフォーマンスが低下する可能性がある問題を修正しました[＃9227](https://github.com/pingcap/tiflash/issues/9227) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - クラスター内で長期間にわたって頻繁に`EXCHANGE PARTITION`と`DROP TABLE`操作を行うと、 TiFlashテーブル メタデータのレプリケーションが遅くなり、クエリ パフォーマンスが低下する可能性がある問題を修正しました[＃9227](https://github.com/pingcap/tiflash/issues/9227) @ [JaySon-Huang](https://github.com/JaySon-Huang) - ツール - バックアップと復元 (BR) - - バックアップと復元のチェックポイントパスが一部の外部storageと互換性がない問題を修正[＃55265](https://github.com/pingcap/tidb/issues/55265) @ [Leavrth](https://github.com/Leavrth) + - バックアップと復元のチェックポイントパスが一部の外部ストレージと互換性がない問題を修正[＃55265](https://github.com/pingcap/tidb/issues/55265) @ [Leavrth](https://github.com/Leavrth) - 増分バックアップ[＃54139](https://github.com/pingcap/tidb/issues/54139) @ [3pointer](https://github.com/3pointer)中の DDL ジョブのスキャンの非効率性の問題を修正 - リージョンリーダー[＃17168](https://github.com/tikv/tikv/issues/17168) @ [Leavrth](https://github.com/Leavrth)の探索の中断により、チェックポイントバックアップ中のバックアップパフォーマンスが影響を受ける問題を修正しました。 - `ADD INDEX`や`MODIFY COLUMN`などのバックフィルを必要とする DDL が、増分リストア[＃54426](https://github.com/pingcap/tidb/issues/54426) @ [3pointer](https://github.com/3pointer)中に正しく回復されない可能性がある問題を修正しました。 diff --git a/releases/release-6.5.12.md b/releases/release-6.5.12.md index a721c74b9e95f..7f78343a9e0d6 100644 --- a/releases/release-6.5.12.md +++ b/releases/release-6.5.12.md @@ -35,7 +35,7 @@ TiDBバージョン: 6.5.12 - バックアップと復元 (BR) - - 完全復元のためにターゲットクラスタが空のクラスタであるかどうかを確認するチェックを追加します[＃35744](https://github.com/pingcap/tidb/issues/35744) @ [3pointer](https://github.com/3pointer) + - 完全復元のためにターゲットクラスターが空のクラスターであるかどうかを確認するチェックを追加します[＃35744](https://github.com/pingcap/tidb/issues/35744) @ [3pointer](https://github.com/3pointer) - 非完全復元[＃55087](https://github.com/pingcap/tidb/issues/55087) @ [RidRisR](https://github.com/RidRisR)の場合、ターゲット クラスターに同じ名前のテーブルが含まれているかどうかを確認するチェックを追加します。 - `br log restore`サブコマンドを除き、他の`br log`サブコマンドはすべて、メモリ消費量を削減するために TiDB `domain`データ構造のロードをスキップすることをサポートしています[＃52088](https://github.com/pingcap/tidb/issues/52088) @ [Leavrth](https://github.com/Leavrth) - バックアップパフォーマンスを向上させるために、フルバックアップ中のテーブルレベルのチェックサム計算をデフォルトで無効にする（ `--checksum=false` ） [＃56373](https://github.com/pingcap/tidb/issues/56373) @ [Tristan1900](https://github.com/Tristan1900) @@ -65,7 +65,7 @@ TiDBバージョン: 6.5.12 - クエリ条件`column IS NULL` [＃56116](https://github.com/pingcap/tidb/issues/56116) @ [hawkingrei](https://github.com/hawkingrei)でユニークインデックスにアクセスするときに、オプティマイザが行数を誤って 1 と推定する問題を修正しました。 - `IndexLookUp`演算子のメモリの一部が[＃56440](https://github.com/pingcap/tidb/issues/56440) @ [wshwsh12](https://github.com/wshwsh12)で追跡されない問題を修正 - TiDBの内部コルーチン[＃57798](https://github.com/pingcap/tidb/issues/57798) [＃56053](https://github.com/pingcap/tidb/issues/56053) @ [fishiu](https://github.com/fishiu) @ [tiancaiamao](https://github.com/tiancaiamao)で発生する可能性のあるデータ競合問題を修正しました - - クエリに利用可能なインデックスマージ実行プラン[＃56217](https://github.com/pingcap/tidb/issues/56217) @ [AilinKid](https://github.com/AilinKid)がある場合に`read_from_storage`ヒントが有効にならない可能性がある問題を修正しました + - クエリに利用可能なインデックスマージ実行プラン[＃56217](https://github.com/pingcap/tidb/issues/56217) @ [AilinKid](https://github.com/AilinKid)がある場合に`read_from_ストレージ`ヒントが有効にならない可能性がある問題を修正しました - エイリアス[＃56726](https://github.com/pingcap/tidb/issues/56726) @ [hawkingrei](https://github.com/hawkingrei)を持つマルチテーブル`DELETE`ステートメントに対して実行プラン バインディングを作成できない問題を修正しました。 - 異常終了時に`INDEX_HASH_JOIN`アップする可能性がある問題を修正[＃54055](https://github.com/pingcap/tidb/issues/54055) @ [wshwsh12](https://github.com/wshwsh12) - 2人のDDL所有者が同時に存在する可能性がある問題を修正[＃54689](https://github.com/pingcap/tidb/issues/54689) @ [joccau](https://github.com/joccau) @@ -111,7 +111,7 @@ TiDBバージョン: 6.5.12 - TSO [＃9004](https://github.com/tikv/pd/issues/9004) @ [rleungx](https://github.com/rleungx)を割り当てるときにメモリリークが発生する可能性がある問題を修正しました - `tidb_enable_tso_follower_proxy`システム変数が[＃8947](https://github.com/tikv/pd/issues/8947) @ [JmPotato](https://github.com/JmPotato)で有効にならない可能性がある問題を修正しました - PD がpanicを起こす可能性のある潜在的な問題を修正[＃8915](https://github.com/tikv/pd/issues/8915) @ [bufferflies](https://github.com/bufferflies) - - 長時間実行クラスタ[＃9047](https://github.com/tikv/pd/issues/9047) @ [bufferflies](https://github.com/bufferflies)でメモリリークが発生する可能性がある問題を修正 + - 長時間実行クラスター[＃9047](https://github.com/tikv/pd/issues/9047) @ [bufferflies](https://github.com/bufferflies)でメモリリークが発生する可能性がある問題を修正 - PDノードがLeader[＃9051](https://github.com/tikv/pd/issues/9051) @ [rleungx](https://github.com/rleungx)でない場合でもTSOを生成する可能性がある問題を修正しました - PDLeader[＃9017](https://github.com/tikv/pd/issues/9017)対[rleungx](https://github.com/rleungx)の切り替え時にリージョン同期が間に合わない問題を修正しました - `evict-leader-scheduler`または`grant-leader-scheduler`作成時にエラーが発生しても、エラーメッセージが pd-ctl [＃8759](https://github.com/tikv/pd/issues/8759) @ [okJiang](https://github.com/okJiang)に返されない問題を修正しました。 @@ -142,7 +142,7 @@ TiDBバージョン: 6.5.12 - TiKV [＃58845](https://github.com/pingcap/tidb/issues/58845) @ [Tristan1900](https://github.com/Tristan1900)にリクエストを送信するときに`rpcClient is idle`エラーが発生し、 BR が復元に失敗する問題を修正しました。 - `br log status --json` [＃57959](https://github.com/pingcap/tidb/issues/57959) @ [Leavrth](https://github.com/Leavrth)を使用してログバックアップタスクをクエリすると、結果に`status`フィールドが表示されない問題を修正しました。 - ログバックアップ中のPDLeaderI/Oレイテンシーによりチェックポイントレイテンシー[＃58574](https://github.com/pingcap/tidb/issues/58574) @ [YuJuncen](https://github.com/YuJuncen)が増加する可能性がある問題を修正しました。 - - `tiup br restore`コマンドがデータベースまたはテーブルの復元中にターゲット クラスタ テーブルが既に存在するかどうかのチェックを省略し、既存のテーブル[＃58168](https://github.com/pingcap/tidb/issues/58168) @ [RidRisR](https://github.com/RidRisR)を上書きする可能性がある問題を修正しました。 + - `tiup br restore`コマンドがデータベースまたはテーブルの復元中にターゲット クラスター テーブルが既に存在するかどうかのチェックを省略し、既存のテーブル[＃58168](https://github.com/pingcap/tidb/issues/58168) @ [RidRisR](https://github.com/RidRisR)を上書きする可能性がある問題を修正しました。 - アドバンサー所有者が[＃58031](https://github.com/pingcap/tidb/issues/58031) @ [3pointer](https://github.com/3pointer)に切り替わったときに、ログバックアップが予期せず一時停止状態になる可能性がある問題を修正しました。 - ログバックアップが残留ロックをすぐに解決できず、チェックポイントが[＃57134](https://github.com/pingcap/tidb/issues/57134) @ [3pointer](https://github.com/3pointer)に進まない問題を修正しました。 - BR統合テストケースが不安定になる問題を修正し、スナップショットまたはログバックアップファイルの破損をシミュレートする新しいテストケースを追加します[＃53835](https://github.com/pingcap/tidb/issues/53835) @ [Leavrth](https://github.com/Leavrth) @@ -175,7 +175,7 @@ TiDBバージョン: 6.5.12 - ログが適切に感度調整されない問題を修正[＃59086](https://github.com/pingcap/tidb/issues/59086) @ [GMHDBJD](https://github.com/GMHDBJD) - エンコードフェーズでのキャッシュ不足によりパフォーマンスが低下する問題を修正[＃56705](https://github.com/pingcap/tidb/issues/56705) @ [OliverS929](https://github.com/OliverS929) - - 高同時実行シナリオでクラウドstorageからデータをインポートするときにパフォーマンスが低下する問題を修正[＃57413](https://github.com/pingcap/tidb/issues/57413) @ [xuanyu66](https://github.com/xuanyu66) + - 高同時実行シナリオでクラウドストレージからデータをインポートするときにパフォーマンスが低下する問題を修正[＃57413](https://github.com/pingcap/tidb/issues/57413) @ [xuanyu66](https://github.com/xuanyu66) - メタデータ更新中に`Lock wait timeout`エラーが発生した場合にTiDB Lightning が自動的に再試行しない問題を修正しました[＃53042](https://github.com/pingcap/tidb/issues/53042) @ [guoshouyan](https://github.com/guoshouyan) - TiDB LightningがTiKV [＃56114](https://github.com/pingcap/tidb/issues/56114) @ [fishiu](https://github.com/fishiu)から送信されたサイズ超過のメッセージを受信できない問題を修正しました - TiDB Lightning [＃58085](https://github.com/pingcap/tidb/issues/58085) @ [lance6716](https://github.com/lance6716)を使用してデータをインポートするときにエラーレポートの出力が切り捨てられる問題を修正しました diff --git a/releases/release-6.5.2.md b/releases/release-6.5.2.md index 35838b9824eef..759730be227a5 100644 --- a/releases/release-6.5.2.md +++ b/releases/release-6.5.2.md @@ -17,7 +17,7 @@ TiDB バージョン: 6.5.2 TiCDC クラスターを v6.5.2 またはそれ以降の v6.5.x バージョンにアップグレードする際、Avro を使用してレプリケートされたテーブルに`FLOAT`データ型が含まれている場合は、アップグレード前に Confluent Schema Registry の互換性ポリシーを手動で`None`に調整し、changefeed がスキーマを正常に更新できるようにする必要があります。そうしないと、アップグレード後に changefeed がスキーマを更新できず、エラー状態になります。 -- パーティションテーブルをstorageサービスにレプリケーションする際にデータ損失が発生する可能性がある問題を修正するため、TiCDC [`sink.enable-partition-separator`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters)構成項目のデフォルト値が`false`から`true`に変更されました。これは、テーブル内のパーティションがデフォルトで別々のディレクトリに保存されることを意味します。データ損失の問題を回避するため、この値は`true`のままにしておくことをお勧めします[＃8724](https://github.com/pingcap/tiflow/issues/8724) @ [CharlesCheung96](https://github.com/CharlesCheung96) +- パーティションテーブルをストレージサービスにレプリケーションする際にデータ損失が発生する可能性がある問題を修正するため、TiCDC [`sink.enable-partition-separator`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters)構成項目のデフォルト値が`false`から`true`に変更されました。これは、テーブル内のパーティションがデフォルトで別々のディレクトリに保存されることを意味します。データ損失の問題を回避するため、この値は`true`のままにしておくことをお勧めします[＃8724](https://github.com/pingcap/tiflow/issues/8724) @ [CharlesCheung96](https://github.com/CharlesCheung96) ## 改善点 {#improvements} @@ -74,7 +74,7 @@ TiDB バージョン: 6.5.2 - PD - - PD が予期せず複数の学習者をリージョン[＃5786](https://github.com/tikv/pd/issues/5786) @ [HunDunDM](https://github.com/HunDunDM)に追加する可能性がある問題を修正しました。 + - PD が予期せず複数のラーナーをリージョン[＃5786](https://github.com/tikv/pd/issues/5786) @ [HunDunDM](https://github.com/HunDunDM)に追加する可能性がある問題を修正しました。 - 配置ルールの切り替えにより、リーダー[＃6195](https://github.com/tikv/pd/issues/6195) @ [bufferflies](https://github.com/bufferflies)の分布が不均等になる可能性がある問題を修正しました。 - TiFlash @@ -89,15 +89,15 @@ TiDB バージョン: 6.5.2 - バックアップと復元 (BR) - - TiDBクラスタ[＃40759](https://github.com/pingcap/tidb/issues/40759) @ [joccau](https://github.com/joccau)にPITRバックアップタスクがない場合に頻度`resolve lock`が高すぎる問題を修正 + - TiDBクラスター[＃40759](https://github.com/pingcap/tidb/issues/40759) @ [joccau](https://github.com/joccau)にPITRバックアップタスクがない場合に頻度`resolve lock`が高すぎる問題を修正 - PITRリカバリプロセス[＃42001](https://github.com/pingcap/tidb/issues/42001) @ [joccau](https://github.com/joccau)中に分割リージョンの再試行の待機時間が不十分になる問題を修正 - TiCDC - - TiCDCがオブジェクトstorage[＃8581](https://github.com/pingcap/tiflow/issues/8581) @ [CharlesCheung96](https://github.com/CharlesCheung96) @ [Rustin170506](https://github.com/Rustin170506)にデータを複製するときにパーティションセパレーターが機能しない問題を修正しました - - TiCDC がオブジェクトstorage[＃8256](https://github.com/pingcap/tiflow/issues/8256) @ [zhaoxinyu](https://github.com/zhaoxinyu)にデータを複製するときにテーブル スケジューリングによってデータ損失が発生する可能性がある問題を修正しました。 + - TiCDCがオブジェクトストレージ[＃8581](https://github.com/pingcap/tiflow/issues/8581) @ [CharlesCheung96](https://github.com/CharlesCheung96) @ [Rustin170506](https://github.com/Rustin170506)にデータを複製するときにパーティションセパレーターが機能しない問題を修正しました + - TiCDC がオブジェクトストレージ[＃8256](https://github.com/pingcap/tiflow/issues/8256) @ [zhaoxinyu](https://github.com/zhaoxinyu)にデータを複製するときにテーブル スケジューリングによってデータ損失が発生する可能性がある問題を修正しました。 - 非再入可能DDL文[＃8662](https://github.com/pingcap/tiflow/issues/8662) @ [hicqu](https://github.com/hicqu)によりレプリケーションが停止する問題を修正 - - TiCDC がオブジェクトstorage[＃8666](https://github.com/pingcap/tiflow/issues/8666) @ [CharlesCheung96](https://github.com/CharlesCheung96)にデータを複製するときに、TiCDC スケーリングによってデータ損失が発生する可能性がある問題を修正しました。 + - TiCDC がオブジェクトストレージ[＃8666](https://github.com/pingcap/tiflow/issues/8666) @ [CharlesCheung96](https://github.com/CharlesCheung96)にデータを複製するときに、TiCDC スケーリングによってデータ損失が発生する可能性がある問題を修正しました。 - `db sorter`のメモリ使用量が`cgroup memory limit` [＃8588](https://github.com/pingcap/tiflow/issues/8588) @ [amyangfei](https://github.com/amyangfei)で制御されない問題を修正 - Redo ログ[＃8591](https://github.com/pingcap/tiflow/issues/8591) @ [CharlesCheung96](https://github.com/CharlesCheung96)の適用中に特別なケースでデータ損失が発生する可能性がある問題を修正しました - `db sorter`のメモリ使用量が`cgroup memory limit` [＃8588](https://github.com/pingcap/tiflow/issues/8588) @ [amyangfei](https://github.com/amyangfei)で制御されない問題を修正 diff --git a/releases/release-6.5.3.md b/releases/release-6.5.3.md index f9c3e673cd611..05889caec6889 100644 --- a/releases/release-6.5.3.md +++ b/releases/release-6.5.3.md @@ -40,7 +40,7 @@ TiDB バージョン: 6.5.3 - TiCDC が DDL を処理する方法を最適化し、DDL が他の無関係な DML イベントの使用をブロックしないようにし、メモリ使用量を削減します[＃8106](https://github.com/pingcap/tiflow/issues/8106) @ [asddongmen](https://github.com/asddongmen) - デコーダーインターフェースを最適化し、新しいメソッド`AddKeyValue` [＃8861](https://github.com/pingcap/tiflow/issues/8861) @ [3AceShowHand](https://github.com/3AceShowHand)を追加します - - オブジェクトstorageにデータを複製するシナリオでDDLイベントが発生した場合にディレクトリ構造を最適化する[＃8890](https://github.com/pingcap/tiflow/issues/8890) @ [CharlesCheung96](https://github.com/CharlesCheung96) + - オブジェクトストレージにデータを複製するシナリオでDDLイベントが発生した場合にディレクトリ構造を最適化する[＃8890](https://github.com/pingcap/tiflow/issues/8890) @ [CharlesCheung96](https://github.com/CharlesCheung96) - Kafka-on-Pulsar ダウンストリームへのデータ複製をサポート[＃8892](https://github.com/pingcap/tiflow/issues/8892) @ [Rustin170506](https://github.com/Rustin170506) - Kafka [＃8865](https://github.com/pingcap/tiflow/issues/8865) @ [Rustin170506](https://github.com/Rustin170506)にデータを複製する際の検証に OAuth プロトコルの使用をサポート - AvroまたはCSVプロトコルを使用してデータレプリケーション中にTiCDCが`UPDATE`ステートメントを処理する方法を最適化し、 `UPDATE` `DELETE`と`INSERT`ステートメントに分割して、 `DELETE`ステートメント[＃9086](https://github.com/pingcap/tiflow/issues/9086) @ [3AceShowHand](https://github.com/3AceShowHand)から古い値を取得できるようにします。 @@ -94,7 +94,7 @@ TiDB バージョン: 6.5.3 - PD クラッシュにより PITR が[＃14184](https://github.com/tikv/tikv/issues/14184) @ [YuJuncen](https://github.com/YuJuncen)で続行できなくなる問題を修正しました - 暗号化キーIDの競合により古いキー[＃14585](https://github.com/tikv/tikv/issues/14585) @ [tabokie](https://github.com/tabokie)が削除される可能性がある問題を修正しました - 自動コミットとポイント取得レプリカ読み取りによって線形化可能性[＃14715](https://github.com/tikv/tikv/issues/14715) @ [cfzjywxk](https://github.com/cfzjywxk)が破壊される可能性がある問題を修正しました - - クラスタを以前のバージョンからv6.5以降のバージョン[＃14780](https://github.com/tikv/tikv/issues/14780) @ [MyonKeminta](https://github.com/MyonKeminta)にアップグレードしたときに、蓄積されたロックレコードによって引き起こされるパフォーマンス低下の問題を修正しました。 + - クラスターを以前のバージョンからv6.5以降のバージョン[＃14780](https://github.com/tikv/tikv/issues/14780) @ [MyonKeminta](https://github.com/MyonKeminta)にアップグレードしたときに、蓄積されたロックレコードによって引き起こされるパフォーマンス低下の問題を修正しました。 - TiDB Lightning がSST ファイルの漏洩を引き起こす可能性がある問題を修正[＃14745](https://github.com/tikv/tikv/issues/14745) @ [YuJuncen](https://github.com/YuJuncen) - 暗号化キーとラフトログファイルの削除の間の潜在的な競合を修正しました。これにより、TiKV が[＃14761](https://github.com/tikv/tikv/issues/14761) @ [Connor1996](https://github.com/Connor1996)で起動しなくなる可能性があります。 @@ -120,12 +120,12 @@ TiDB バージョン: 6.5.3 - TiCDC タイムゾーン設定[＃8798](https://github.com/pingcap/tiflow/issues/8798) @ [Rustin170506](https://github.com/Rustin170506)の問題を修正 - 上流の TiKV ノードの 1 つが[＃8858](https://github.com/pingcap/tiflow/issues/8858) @ [hicqu](https://github.com/hicqu)でクラッシュするとチェックポイントの遅延が増加する問題を修正しました - 下流のMySQLにデータを複製するときに、上流のTiDB [＃8040](https://github.com/pingcap/tiflow/issues/8040) @ [asddongmen](https://github.com/asddongmen)で`FLASHBACK CLUSTER TO TIMESTAMP`ステートメントが実行された後にレプリケーションエラーが発生する問題を修正しました。 - - オブジェクトstorageにデータを複製する際に、上流の`EXCHANGE PARTITION`操作が下流の[＃8914](https://github.com/pingcap/tiflow/issues/8914) @ [CharlesCheung96](https://github.com/CharlesCheung96)に正しく複製されない問題を修正しました。 + - オブジェクトストレージにデータを複製する際に、上流の`EXCHANGE PARTITION`操作が下流の[＃8914](https://github.com/pingcap/tiflow/issues/8914) @ [CharlesCheung96](https://github.com/CharlesCheung96)に正しく複製されない問題を修正しました。 - 一部の特殊なシナリオでソートコンポーネントの過剰なメモリ使用によって引き起こされる OOM 問題を修正[＃8974](https://github.com/pingcap/tiflow/issues/8974) @ [hicqu](https://github.com/hicqu) - ダウンストリームが Kafka の場合、TiCDC がダウンストリームのメタデータを頻繁にクエリし、ダウンストリームに過度のワークロードを引き起こす問題を修正しました[＃8957](https://github.com/pingcap/tiflow/issues/8957) [＃8959](https://github.com/pingcap/tiflow/issues/8959) @ [Rustin170506](https://github.com/Rustin170506) - Kafka メッセージのサイズが大きすぎるためにレプリケーションエラーが発生した場合に、メッセージ本文がログ[＃9031](https://github.com/pingcap/tiflow/issues/9031) @ [darraes](https://github.com/darraes)に記録される問題を修正しました。 - 下流の Kafka シンクがローリング再起動されたときに発生する TiCDC ノードpanicを修正しました[＃9023](https://github.com/pingcap/tiflow/issues/9023) @ [asddongmen](https://github.com/asddongmen) - - storageサービスにデータを複製するときに、下流のDDLステートメントに対応するJSONファイルにテーブルフィールド[＃9066](https://github.com/pingcap/tiflow/issues/9066) @ [CharlesCheung96](https://github.com/CharlesCheung96)のデフォルト値が記録されない問題を修正しました。 + - ストレージサービスにデータを複製するときに、下流のDDLステートメントに対応するJSONファイルにテーブルフィールド[＃9066](https://github.com/pingcap/tiflow/issues/9066) @ [CharlesCheung96](https://github.com/CharlesCheung96)のデフォルト値が記録されない問題を修正しました。 - TiDB Lightning diff --git a/releases/release-6.5.4.md b/releases/release-6.5.4.md index c5b3d3e4b5445..4bf6180c25d9c 100644 --- a/releases/release-6.5.4.md +++ b/releases/release-6.5.4.md @@ -54,7 +54,7 @@ TiDB バージョン: 6.5.4 - バックアップと復元 (BR) - HTTPクライアント[＃46011](https://github.com/pingcap/tidb/issues/46011) @ [Leavrth](https://github.com/Leavrth)で`MaxIdleConns`と`MaxIdleConnsPerHost`パラメータを設定することで接続の再利用のサポートを強化します - - PD または外部 S3storageへの接続に失敗した場合のBRのフォールトトレランスを向上[＃42909](https://github.com/pingcap/tidb/issues/42909) @ [Leavrth](https://github.com/Leavrth) + - PD または外部 S3ストレージへの接続に失敗した場合のBRのフォールトトレランスを向上[＃42909](https://github.com/pingcap/tidb/issues/42909) @ [Leavrth](https://github.com/Leavrth) - 新しい復元パラメータ`WaitTiflashReady`を追加します。このパラメータを有効にすると、 TiFlashレプリカが正常に複製された後に復元操作が完了します[＃43828](https://github.com/pingcap/tidb/issues/43828) [＃46302](https://github.com/pingcap/tidb/issues/46302) @ [3pointer](https://github.com/3pointer) - TiCDC @@ -110,10 +110,10 @@ TiDB バージョン: 6.5.4 - `DATETIME`または`TIMESTAMP`列を数値定数[＃38361](https://github.com/pingcap/tidb/issues/38361) @ [yibin87](https://github.com/yibin87)と比較するときに、MySQL と動作が一致しない問題を修正しました。 - インデックス結合のエラーによりクエリが停止する可能性がある問題を修正[＃45716](https://github.com/pingcap/tidb/issues/45716) @ [wshwsh12](https://github.com/wshwsh12) - 接続を切断すると go コルーチン リークが発生する可能性がある問題を修正[＃46034](https://github.com/pingcap/tidb/issues/46034) @ [pingyu](https://github.com/pingyu) - - `tmp-storage-quota`設定が[＃45161](https://github.com/pingcap/tidb/issues/45161) [＃26806](https://github.com/pingcap/tidb/issues/26806) @ [wshwsh12](https://github.com/wshwsh12)で有効にならない問題を修正 + - `tmp-ストレージ-quota`設定が[＃45161](https://github.com/pingcap/tidb/issues/45161) [＃26806](https://github.com/pingcap/tidb/issues/26806) @ [wshwsh12](https://github.com/wshwsh12)で有効にならない問題を修正 - クラスター[＃38484](https://github.com/pingcap/tidb/issues/38484) @ [hehechen](https://github.com/hehechen)でTiFlashノードがダウンした場合にTiFlashレプリカが利用できなくなる問題を修正しました。 - `Config.Labels`同時に読み書きする場合に、データ競合により TiDB がクラッシュする問題を修正[＃45561](https://github.com/pingcap/tidb/issues/45561) @ [gengliqi](https://github.com/gengliqi) - - クラスタが大きい場合、クライアントが定期的に更新される`min-resolved-ts` PD OOMを引き起こす可能性がある問題を修正しました[＃46664](https://github.com/pingcap/tidb/issues/46664) @ [HuSharp](https://github.com/HuSharp) + - クラスターが大きい場合、クライアントが定期的に更新される`min-resolved-ts` PD OOMを引き起こす可能性がある問題を修正しました[＃46664](https://github.com/pingcap/tidb/issues/46664) @ [HuSharp](https://github.com/HuSharp) - TiKV @@ -133,9 +133,9 @@ TiDB バージョン: 6.5.4 - etcd がすでに起動しているがクライアントがまだ接続していない場合、クライアントを呼び出すと PD がpanic[＃6860](https://github.com/tikv/pd/issues/6860) @ [HuSharp](https://github.com/HuSharp)になる可能性がある問題を修正しました。 - リーダーが長時間退出できない問題を修正[＃6918](https://github.com/tikv/pd/issues/6918) @ [bufferflies](https://github.com/bufferflies) - 配置ルールが`LOCATION_LABELS`使用する場合、SQL とルールチェッカーが[＃38605](https://github.com/pingcap/tidb/issues/38605) @ [nolouch](https://github.com/nolouch)と互換性がない問題を修正しました - - PD が予期せず複数の学習者をリージョン[＃5786](https://github.com/tikv/pd/issues/5786) @ [HunDunDM](https://github.com/HunDunDM)に追加する可能性がある問題を修正しました。 + - PD が予期せず複数のラーナーをリージョン[＃5786](https://github.com/tikv/pd/issues/5786) @ [HunDunDM](https://github.com/HunDunDM)に追加する可能性がある問題を修正しました。 - ルールチェッカーがピア[＃6559](https://github.com/tikv/pd/issues/6559) @ [nolouch](https://github.com/nolouch)を選択した場合に、不健全なピアを削除できない問題を修正しました - - `unsafe recovery`で不合格になった学習者のピアが`auto-detect`モード[＃6690](https://github.com/tikv/pd/issues/6690) @ [v01dstar](https://github.com/v01dstar)で無視される問題を修正 + - `unsafe recovery`で不合格になったラーナーのピアが`auto-detect`モード[＃6690](https://github.com/tikv/pd/issues/6690) @ [v01dstar](https://github.com/v01dstar)で無視される問題を修正 - TiFlash @@ -152,9 +152,9 @@ TiDB バージョン: 6.5.4 - BRで使用されるグローバルパラメータ`TableColumnCountLimit`と`IndexLimit`デフォルト値を最大値[＃45793](https://github.com/pingcap/tidb/issues/45793) @ [Leavrth](https://github.com/Leavrth)に増やすことで、復元が失敗する問題を修正しました。 - PITR [＃43184](https://github.com/pingcap/tidb/issues/43184) @ [Leavrth](https://github.com/Leavrth)で DDL メタ情報を処理するときに書き換えが失敗する問題を修正しました - PITR実行中に関数の戻り値をチェックしないことで発生するpanicの問題を修正[＃45853](https://github.com/pingcap/tidb/issues/45853) @ [Leavrth](https://github.com/Leavrth) - - Amazon S3 [＃41916](https://github.com/pingcap/tidb/issues/41916) [＃42033](https://github.com/pingcap/tidb/issues/42033) @ [3pointer](https://github.com/3pointer)以外の S3 互換storage使用時に無効なリージョン ID が取得される問題を修正 + - Amazon S3 [＃41916](https://github.com/pingcap/tidb/issues/41916) [＃42033](https://github.com/pingcap/tidb/issues/42033) @ [3pointer](https://github.com/3pointer)以外の S3 互換ストレージ使用時に無効なリージョン ID が取得される問題を修正 - RawKVモード[＃37085](https://github.com/pingcap/tidb/issues/37085) @ [pingyu](https://github.com/pingyu)のきめ細かなバックアップフェーズで発生する可能性のあるエラーを修正 - - TiDBクラスタ[＃40759](https://github.com/pingcap/tidb/issues/40759) @ [joccau](https://github.com/joccau)にPITRバックアップタスクがない場合に頻度`resolve lock`が高すぎる問題を修正 + - TiDBクラスター[＃40759](https://github.com/pingcap/tidb/issues/40759) @ [joccau](https://github.com/joccau)にPITRバックアップタスクがない場合に頻度`resolve lock`が高すぎる問題を修正 - リージョンリーダーシップの移行が発生すると、PITR ログバックアップの進行のレイテンシーが長くなるという問題を軽減します[＃13638](https://github.com/tikv/tikv/issues/13638) @ [YuJuncen](https://github.com/YuJuncen) - TiCDC @@ -182,13 +182,13 @@ TiDB バージョン: 6.5.4 - TiDB Lightning - エンジンがデータ[＃44867](https://github.com/pingcap/tidb/issues/44867) @ [D3Hunter](https://github.com/D3Hunter)をインポートしているときにディスク クォータ チェックがブロックされる可能性がある問題を修正しました - - ターゲットクラスタ[＃45462](https://github.com/pingcap/tidb/issues/45462) @ [D3Hunter](https://github.com/D3Hunter)で SSL が有効になっているときにチェックサムがエラー`Region is unavailable`を報告する問題を修正しました + - ターゲットクラスター[＃45462](https://github.com/pingcap/tidb/issues/45462) @ [D3Hunter](https://github.com/D3Hunter)で SSL が有効になっているときにチェックサムがエラー`Region is unavailable`を報告する問題を修正しました - エンコードエラーが正しく記録されない問題を修正[＃44321](https://github.com/pingcap/tidb/issues/44321) @ [lyzx2001](https://github.com/lyzx2001) - CSVデータ[＃43284](https://github.com/pingcap/tidb/issues/43284) @ [lyzx2001](https://github.com/lyzx2001)をインポートする際にルートがpanicになる可能性がある問題を修正 - 論理インポートモードでテーブル A をインポートすると、テーブル B が存在しないと誤って報告される可能性がある問題を修正しました[＃44614](https://github.com/pingcap/tidb/issues/44614) @ [dsdashun](https://github.com/dsdashun) - `NEXT_GLOBAL_ROW_ID` [＃45427](https://github.com/pingcap/tidb/issues/45427) @ [lyzx2001](https://github.com/lyzx2001)を保存するときにデータ型が間違っている問題を修正しました - `checksum = "optional"` [＃45382](https://github.com/pingcap/tidb/issues/45382) @ [lyzx2001](https://github.com/lyzx2001)のときにチェックサムがエラーを報告する問題を修正しました - - PDクラスタアドレスが[＃43436](https://github.com/pingcap/tidb/issues/43436) @ [lichunzhu](https://github.com/lichunzhu)に変更されるとデータのインポートが失敗する問題を修正しました + - PDクラスターアドレスが[＃43436](https://github.com/pingcap/tidb/issues/43436) @ [lichunzhu](https://github.com/lichunzhu)に変更されるとデータのインポートが失敗する問題を修正しました - 一部のPDノードが[＃43400](https://github.com/pingcap/tidb/issues/43400) @ [lichunzhu](https://github.com/lichunzhu)で失敗した場合にデータのインポートが失敗する問題を修正しました - 自動増分列を持つテーブルが`AUTO_ID_CACHE=1`設定すると、ID アロケータのベース値が正しくなくなる[＃46100](https://github.com/pingcap/tidb/issues/46100) @ [D3Hunter](https://github.com/D3Hunter)という問題を修正しました diff --git a/releases/release-6.5.5.md b/releases/release-6.5.5.md index cdc609ce4b585..a6e894453664f 100644 --- a/releases/release-6.5.5.md +++ b/releases/release-6.5.5.md @@ -48,7 +48,7 @@ TiDB バージョン: 6.5.5 - スケジューラの起動に時間がかかる問題を修正[＃6920](https://github.com/tikv/pd/issues/6920) @ [HuSharp](https://github.com/HuSharp) - スキャッターリージョンにおけるリーダーとピアの処理ロジックが[＃6962](https://github.com/tikv/pd/issues/6962) @ [bufferflies](https://github.com/bufferflies)で矛盾している問題を修正しました - - クラスタが再起動されたとき、またはPDLeaderが[＃7008](https://github.com/tikv/pd/issues/7008) @ [CabinfeverB](https://github.com/CabinfeverB)に切り替えられたときに、 `empty-region-count`監視メトリックが異常になる問題を修正しました。 + - クラスターが再起動されたとき、またはPDLeaderが[＃7008](https://github.com/tikv/pd/issues/7008) @ [CabinfeverB](https://github.com/CabinfeverB)に切り替えられたときに、 `empty-region-count`監視メトリックが異常になる問題を修正しました。 - ツール diff --git a/releases/release-6.5.6.md b/releases/release-6.5.6.md index 4dbe443787bb3..f6e880ccbfe07 100644 --- a/releases/release-6.5.6.md +++ b/releases/release-6.5.6.md @@ -21,7 +21,7 @@ TiDB バージョン: 6.5.6 - [`encoding-worker-num`](/ticdc/ticdc-changefeed-config.md)と[`flush-worker-num`](/ticdc/ticdc-changefeed-config.md) : 異なるマシンの仕様に基づいて、再実行モジュールに異なる同時実行パラメータを設定できます[＃10048](https://github.com/pingcap/tiflow/issues/10048) @ [CharlesCheung96](https://github.com/CharlesCheung96) - [`compression`](/ticdc/ticdc-changefeed-config.md) : REDOログファイルの圧縮動作を設定できます[＃10176](https://github.com/pingcap/tiflow/issues/10176) @ [sdojjy](https://github.com/sdojjy) - [`changefeed-error-stuck-duration`](/ticdc/ticdc-changefeed-config.md) : 内部エラーまたは例外が発生したときに、変更フィードが自動的に再試行される期間を設定できます[＃9875](https://github.com/pingcap/tiflow/issues/9875) @ [asddongmen](https://github.com/asddongmen) - - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトstorage[＃10109](https://github.com/pingcap/tiflow/issues/10109)にデータを複製するときに履歴データの自動クリーンアップを設定できます[チャールズ・チュン96](https://github.com/CharlesCheung96) + - [`sink.cloud-ストレージ-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージ[＃10109](https://github.com/pingcap/tiflow/issues/10109)にデータを複製するときに履歴データの自動クリーンアップを設定できます[チャールズ・チュン96](https://github.com/CharlesCheung96) ## 改善点 {#improvements} @@ -122,10 +122,10 @@ TiDB バージョン: 6.5.6 - 変更された分離レベルがデフォルトの配置ルール[＃7121](https://github.com/tikv/pd/issues/7121) @ [rleungx](https://github.com/rleungx)に同期されない問題を修正しました - `evict-leader-scheduler` [HuSharp](https://github.com/HuSharp)で構成[＃6897](https://github.com/tikv/pd/issues/6897)失う可能性がある問題を修正 - BR [＃7148](https://github.com/tikv/pd/issues/7148) @ [CabinfeverB](https://github.com/CabinfeverB)の回復プロセス中に、空のリージョンをカウントする方法によってリージョンのバランスが崩れる可能性がある問題を修正しました。 - - 配置ルールの設定が複雑な場合、データレプリケーション自動同期（DR自動同期）モードを採用しているクラスタで`canSync`と`hasMajority`誤って計算される可能性がある問題を修正しました[＃7201](https://github.com/tikv/pd/issues/7201) @ [disksing](https://github.com/disksing) - - データレプリケーション自動同期（DR自動同期）モードを採用しているクラスタで`available_stores`誤って計算される問題を修正[＃7221](https://github.com/tikv/pd/issues/7221) @ [disksing](https://github.com/disksing) + - 配置ルールの設定が複雑な場合、データレプリケーション自動同期（DR自動同期）モードを採用しているクラスターで`canSync`と`hasMajority`誤って計算される可能性がある問題を修正しました[＃7201](https://github.com/tikv/pd/issues/7201) @ [disksing](https://github.com/disksing) + - データレプリケーション自動同期（DR自動同期）モードを採用しているクラスターで`available_stores`誤って計算される問題を修正[＃7221](https://github.com/tikv/pd/issues/7221) @ [disksing](https://github.com/disksing) - データレプリケーション自動同期（DR自動同期）モード[＃7218](https://github.com/tikv/pd/issues/7218) @ [disksing](https://github.com/disksing)を採用しているクラスターで、セカンダリAZがダウンしているときにプライマリAZがTiKVノードを追加できない問題を修正しました。 - - 大規模クラスタに複数の TiKV ノードを追加すると、TiKVハートビートレポートが遅くなったり停止したりする可能性がある問題を修正しました[＃7248](https://github.com/tikv/pd/issues/7248) @ [rleungx](https://github.com/rleungx) + - 大規模クラスターに複数の TiKV ノードを追加すると、TiKVハートビートレポートが遅くなったり停止したりする可能性がある問題を修正しました[＃7248](https://github.com/tikv/pd/issues/7248) @ [rleungx](https://github.com/rleungx) - TiKVノードが利用できない場合にPDが通常のピアを削除する可能性がある問題を修正[＃7249](https://github.com/tikv/pd/issues/7249) @ [lhy1024](https://github.com/lhy1024) - DR自動同期モード[＃6988](https://github.com/tikv/pd/issues/6988) @ [HuSharp](https://github.com/HuSharp)でリーダーの切り替えに時間がかかる問題を修正 - Gin Web Framework のバージョンを v1.8.1 から v1.9.1 にアップグレードして、いくつかのセキュリティ問題を修正しました[＃7438](https://github.com/tikv/pd/issues/7438) @ [niubell](https://github.com/niubell) @@ -146,7 +146,7 @@ TiDB バージョン: 6.5.6 - 1分以内にPITRを複数回実行するとデータ損失が発生する可能性がある問題を修正[＃15483](https://github.com/tikv/tikv/issues/15483) @ [YuJuncen](https://github.com/YuJuncen) - BR SQL コマンドと CLI のデフォルト値が異なるため、OOM の問題が発生する可能性がある問題を修正しました[＃48000](https://github.com/pingcap/tidb/issues/48000) @ [YuJuncen](https://github.com/YuJuncen) - PD所有者が[＃47533](https://github.com/pingcap/tidb/issues/47533)から[ユジュンセン](https://github.com/YuJuncen)転送されたときにログバックアップがpanic可能性がある問題を修正しました - - BRが外部storageファイル[＃48452](https://github.com/pingcap/tidb/issues/48452) @ [3AceShowHand](https://github.com/3AceShowHand)に対して誤ったURIを生成する問題を修正 + - BRが外部ストレージファイル[＃48452](https://github.com/pingcap/tidb/issues/48452) @ [3AceShowHand](https://github.com/3AceShowHand)に対して誤ったURIを生成する問題を修正 - TiCDC @@ -157,8 +157,8 @@ TiDB バージョン: 6.5.6 - レプリケーションタスクのワークロードが TiCDC ノード[＃9839](https://github.com/pingcap/tiflow/issues/9839) @ [3AceShowHand](https://github.com/3AceShowHand)間で均等に分散されない問題を修正しました - REDOログが有効な場合にDDL文の複製間隔が長すぎる問題を修正[＃9960](https://github.com/pingcap/tiflow/issues/9960) @ [CharlesCheung96](https://github.com/CharlesCheung96) - ターゲットテーブルが削除され、その後アップストリーム[＃10079](https://github.com/pingcap/tiflow/issues/10079) @ [asddongmen](https://github.com/asddongmen)で再作成された場合、変更フィードが双方向レプリケーションモードで DML イベントをレプリケートできない問題を修正しました。 - - オブジェクトstorageサービスにデータを複製する際に、NFSファイルが多すぎるためにレプリケーションの遅延が長くなる問題を修正[＃10041](https://github.com/pingcap/tiflow/issues/10041) @ [CharlesCheung96](https://github.com/CharlesCheung96) - - オブジェクトstorageサービス[＃10137](https://github.com/pingcap/tiflow/issues/10137) @ [sdojjy](https://github.com/sdojjy)にデータを複製するときに TiCDCサーバーがpanic可能性がある問題を修正しました + - オブジェクトストレージサービスにデータを複製する際に、NFSファイルが多すぎるためにレプリケーションの遅延が長くなる問題を修正[＃10041](https://github.com/pingcap/tiflow/issues/10041) @ [CharlesCheung96](https://github.com/CharlesCheung96) + - オブジェクトストレージサービス[＃10137](https://github.com/pingcap/tiflow/issues/10137) @ [sdojjy](https://github.com/sdojjy)にデータを複製するときに TiCDCサーバーがpanic可能性がある問題を修正しました - PD のスケールアップおよびスケールダウン中に TiCDC が無効な古いアドレスにアクセスする問題を修正[＃9584](https://github.com/pingcap/tiflow/issues/9584) @ [fubinzh](https://github.com/fubinzh) @ [asddongmen](https://github.com/asddongmen) - 間違ったメモリ情報を取得すると、一部のオペレーティングシステムで OOM 問題が発生する可能性がある問題を修正[＃9762](https://github.com/pingcap/tiflow/issues/9762) @ [sdojjy](https://github.com/sdojjy) diff --git a/releases/release-6.5.7.md b/releases/release-6.5.7.md index 7db0d795b85a5..c860ef499730a 100644 --- a/releases/release-6.5.7.md +++ b/releases/release-6.5.7.md @@ -69,7 +69,7 @@ TiDB バージョン: 6.5.7 - TiKV - 破損したSSTファイルが他のTiKVノード[＃15986](https://github.com/tikv/tikv/issues/15986) @ [Connor1996](https://github.com/Connor1996)に広がる可能性がある問題を修正 - - 大規模なトランザクション[＃14864](https://github.com/tikv/tikv/issues/14864) @ [overvenus](https://github.com/overvenus)を追跡するときに、古い読み取りの解決済み TS が TiKV OOM 問題を引き起こす可能性がある問題を修正しました + - 大規模なトランザクション[＃14864](https://github.com/tikv/tikv/issues/14864) @ [overvenus](https://github.com/overvenus)を追跡するときに、ステイル読み取りの解決済み TS が TiKV OOM 問題を引き起こす可能性がある問題を修正しました - TiKVがraft log [＃15800](https://github.com/tikv/tikv/issues/15800) @ [tonyxuqqi](https://github.com/tonyxuqqi)を追加できないため`ServerIsBusy`エラーを報告する問題を修正しました。 - PD diff --git a/releases/release-6.5.9.md b/releases/release-6.5.9.md index fc5a1007bd991..b71538d229bc1 100644 --- a/releases/release-6.5.9.md +++ b/releases/release-6.5.9.md @@ -39,7 +39,7 @@ TiDB バージョン: 6.5.9 - リージョンリーダーシップの移行が発生すると、PITR ログバックアップの進行のレイテンシーが長くなるという問題を軽減します[＃13638](https://github.com/tikv/tikv/issues/13638) @ [YuJuncen](https://github.com/YuJuncen) - より効率的なアルゴリズム[＃50613](https://github.com/pingcap/tidb/issues/50613) @ [Leavrth](https://github.com/Leavrth)を使用して、データ復元中に SST ファイルをマージする速度を改善します - データ復元中に SST ファイルをバッチで取り込むことをサポート[＃16267](https://github.com/tikv/tikv/issues/16267) @ [3pointer](https://github.com/3pointer) - - Google Cloud Storage（GCS）を外部storageとして使用する場合の古い互換性チェックを削除します[＃50533](https://github.com/pingcap/tidb/issues/50533) @ [lance6716](https://github.com/lance6716) + - Google Cloud Storage（GCS）を外部ストレージとして使用する場合の古い互換性チェックを削除します[＃50533](https://github.com/pingcap/tidb/issues/50533) @ [lance6716](https://github.com/lance6716) - ログバックアップ[＃51046](https://github.com/pingcap/tidb/issues/51046) @ [YuJuncen](https://github.com/YuJuncen)中に、ログとメトリックのグローバルチェックポイントの進行に影響を与える最も遅いリージョンの情報を出力します。 - BR例外処理メカニズムをリファクタリングして、未知のエラーに対する許容度を高めます[＃47656](https://github.com/pingcap/tidb/issues/47656) @ [3pointer](https://github.com/3pointer) @@ -123,10 +123,10 @@ TiDB バージョン: 6.5.9 - 同期ポイントテーブルが誤って複製される可能性がある問題を修正[＃10576](https://github.com/pingcap/tiflow/issues/10576) @ [asddongmen](https://github.com/asddongmen) - テーブルレプリケーションタスク[＃10613](https://github.com/pingcap/tiflow/issues/10613) @ [CharlesCheung96](https://github.com/CharlesCheung96)をスケジュールするときに TiCDC がパニックになる問題を修正しました - KVクライアントのデータ競合によりTiCDCがpanic[＃10718](https://github.com/pingcap/tiflow/issues/10718) @ [asddongmen](https://github.com/asddongmen)になる問題を修正 - - storageシンク[＃10352](https://github.com/pingcap/tiflow/issues/10352) @ [CharlesCheung96](https://github.com/CharlesCheung96)使用時に、storageサービスによって生成されたファイルシーケンス番号が正しく増加しない可能性がある問題を修正しました。 - - storageシンクシナリオ[＃10592](https://github.com/pingcap/tiflow/issues/10592) @ [CharlesCheung96](https://github.com/CharlesCheung96)でTiCDCがAzureとGCSに正しくアクセスできない問題を修正 + - ストレージシンク[＃10352](https://github.com/pingcap/tiflow/issues/10352) @ [CharlesCheung96](https://github.com/CharlesCheung96)使用時に、ストレージサービスによって生成されたファイルシーケンス番号が正しく増加しない可能性がある問題を修正しました。 + - ストレージシンクシナリオ[＃10592](https://github.com/pingcap/tiflow/issues/10592) @ [CharlesCheung96](https://github.com/CharlesCheung96)でTiCDCがAzureとGCSに正しくアクセスできない問題を修正 - `open-protocol`の古い値部分が、実際のタイプ[＃10803](https://github.com/pingcap/tiflow/issues/10803) @ [3AceShowHand](https://github.com/3AceShowHand)ではなく、タイプ`STRING`に応じて誤ってデフォルト値を出力する問題を修正しました。 - - オブジェクトstorageシンクに一時的な障害が発生した場合に、結果整合性が有効になっている変更フィードが失敗する可能性がある問題を修正しました[＃10710](https://github.com/pingcap/tiflow/issues/10710) @ [CharlesCheung96](https://github.com/CharlesCheung96) + - オブジェクトストレージシンクに一時的な障害が発生した場合に、結果整合性が有効になっている変更フィードが失敗する可能性がある問題を修正しました[＃10710](https://github.com/pingcap/tiflow/issues/10710) @ [CharlesCheung96](https://github.com/CharlesCheung96) - TiDB データ移行 (DM) diff --git a/releases/release-6.6.0.md b/releases/release-6.6.0.md index 1ae4ca862705d..456492d8918a5 100644 --- a/releases/release-6.6.0.md +++ b/releases/release-6.6.0.md @@ -17,15 +17,15 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone バージョン6.6.0-DMRの主な新機能と改善点は以下のとおりです。 -
カテゴリ特徴説明
拡張性とパフォーマンス
TiKVはパーティション化されたRaft KVstorageエンジンをサポートしています（実験的）。 TiKVはパーティション化されたRaft KVstorageエンジンを導入しており、各リージョンは独立したRocksDBインスタンスを使用するため、クラスターのstorage容量をテラバイトからペタバイトまで容易に拡張でき、より安定した書き込みレイテンシーと強力なスケーラビリティを実現します。
TiKVはデータ要求のバッチ集計をサポートしていますこの機能強化により、TiKVのバッチ取得操作におけるRPCの総数が大幅に削減されます。データが高度に分散しており、gRPCスレッドプールのリソースが不足している状況では、コプロセッサ要求をバッチ処理することで、パフォーマンスを50%以上向上させることができます。
TiFlashは、 ステイル読み取りと圧縮交換をサポートしています。 TiFlashは、リアルタイム要件に制約がないシナリオにおいてクエリ性能を向上させることができる、古いデータの読み取り機能をサポートしています。また、 TiFlashはデータ圧縮をサポートしており、並列データ交換の効率を向上させ、TPC-H全体のパフォーマンスを10%向上させ、ネットワーク使用量を50%以上削減できます。
信頼性と可用性
リソース制御（実験的）リソースグループに基づいたリソース管理をサポートします。これにより、データベースユーザーを対応するリソースグループにマッピングし、実際のニーズに基づいて各リソースグループの割り当て量を設定します。
履歴SQLバインディングTiDBダッシュボード上で、過去の実行計画のバインドと、実行計画の迅速なバインドをサポートします。
SQLの機能
外部キー（実験的）データの一貫性を維持し、データ品質を向上させるために、MySQL互換の外部キー制約をサポートします。
多値指標（実験的） MySQL互換の複数値インデックスを導入し、JSON型を拡張することで、TiDBのMySQL 8.0との互換性を向上させます。
DB操作と可観測性
DMは物理的なインポートをサポートします（実験的） TiDBデータ移行（DM）は、TiDB Lightningの物理インポートモードを統合することで、フルデータ移行のパフォーマンスを向上させ、最大10倍高速化します。
+
カテゴリ特徴説明
拡張性とパフォーマンス
TiKVはパーティション化されたRaft KVストレージエンジンをサポートしています（実験的）。 TiKVはパーティション化されたRaft KVストレージエンジンを導入しており、各リージョンは独立したRocksDBインスタンスを使用するため、クラスターのストレージ容量をテラバイトからペタバイトまで容易に拡張でき、より安定した書き込みレイテンシーと強力なスケーラビリティを実現します。
TiKVはデータ要求のバッチ集計をサポートしていますこの機能強化により、TiKVのバッチ取得操作におけるRPCの総数が大幅に削減されます。データが高度に分散しており、gRPCスレッドプールのリソースが不足している状況では、コプロセッサ要求をバッチ処理することで、パフォーマンスを50%以上向上させることができます。
TiFlashは、 ステイル読み取りと圧縮交換をサポートしています。 TiFlashは、リアルタイム要件に制約がないシナリオにおいてクエリ性能を向上させることができる、古いデータの読み取り機能をサポートしています。また、 TiFlashはデータ圧縮をサポートしており、並列データ交換の効率を向上させ、TPC-H全体のパフォーマンスを10%向上させ、ネットワーク使用量を50%以上削減できます。
信頼性と可用性
リソース制御（実験的）リソースグループに基づいたリソース管理をサポートします。これにより、データベースユーザーを対応するリソースグループにマッピングし、実際のニーズに基づいて各リソースグループの割り当て量を設定します。
履歴SQLバインディングTiDBダッシュボード上で、過去の実行計画のバインドと、実行計画の迅速なバインドをサポートします。
SQLの機能
外部キー（実験的）データの一貫性を維持し、データ品質を向上させるために、MySQL互換の外部キー制約をサポートします。
多値指標（実験的） MySQL互換の複数値インデックスを導入し、JSON型を拡張することで、TiDBのMySQL 8.0との互換性を向上させます。
DB操作と可観測性
DMは物理的なインポートをサポートします（実験的） TiDBデータ移行（DM）は、TiDB Lightningの物理インポートモードを統合することで、フルデータ移行のパフォーマンスを向上させ、最大10倍高速化します。
## 機能の詳細 {#feature-details} ### 拡張性 {#scalability} -- サポートパーティションRaft KVstorageエンジン (実験的) [#11515](https://github.com/tikv/tikv/issues/11515) [#12842](https://github.com/tikv/tikv/issues/12842) @[busyjay](https://github.com/busyjay)@[tonyxuqqi](https://github.com/tonyxuqqi)[タボキー](https://github.com/tabokie)[バッファロー](https://github.com/bufferflies)[5kb](https://github.com/5kbpers) @[SpadeA-Tang](https://github.com/SpadeA-Tang)@[nolouch](https://github.com/nolouch) +- サポートパーティションRaft KVストレージエンジン (実験的) [#11515](https://github.com/tikv/tikv/issues/11515) [#12842](https://github.com/tikv/tikv/issues/12842) @[busyjay](https://github.com/busyjay)@[tonyxuqqi](https://github.com/tonyxuqqi)[タボキー](https://github.com/tabokie)[バッファロー](https://github.com/bufferflies)[5kb](https://github.com/5kbpers) @[SpadeA-Tang](https://github.com/SpadeA-Tang)@[nolouch](https://github.com/nolouch) - TiDB v6.6.0 より前は、TiKV の Raft ベースのstorageエンジンは、単一の RocksDB インスタンスを使用して、TiKV インスタンスのすべての「リージョン」のデータを保存していました。より大規模なクラスタをより安定してサポートするために、TiDB v6.6.0 以降では、複数の RocksDB インスタンスを使用して TiKVリージョンデータを保存する新しい TiKVstorageエンジンが導入され、各リージョンのデータは個別の RocksDB インスタンスに独立して保存されます。この新しいエンジンは、RocksDB インスタンス内のファイルの数とレベルをより適切に制御し、リージョン間のデータ操作の物理的な分離を実現し、より多くのデータを安定して管理できます。これは、TiKV がパーティショニングによって複数の RocksDB インスタンスを管理していると考えることができます。そのため、この機能は Partitioned-Raft-KV と呼ばれています。この機能の主な利点は、書き込みパフォーマンスの向上、スケーリングの高速化、および同じハードウェアでサポートできるデータ量の拡大です。また、より大規模なクラスタにも対応できます。 + TiDB v6.6.0 より前は、TiKV の Raft ベースのストレージエンジンは、単一の RocksDB インスタンスを使用して、TiKV インスタンスのすべての「リージョン」のデータを保存していました。より大規模なクラスターをより安定してサポートするために、TiDB v6.6.0 以降では、複数の RocksDB インスタンスを使用して TiKVリージョンデータを保存する新しい TiKVストレージエンジンが導入され、各リージョンのデータは個別の RocksDB インスタンスに独立して保存されます。この新しいエンジンは、RocksDB インスタンス内のファイルの数とレベルをより適切に制御し、リージョン間のデータ操作の物理的な分離を実現し、より多くのデータを安定して管理できます。これは、TiKV がパーティショニングによって複数の RocksDB インスタンスを管理していると考えることができます。そのため、この機能は Partitioned-Raft-KV と呼ばれています。この機能の主な利点は、書き込みパフォーマンスの向上、スケーリングの高速化、および同じハードウェアでサポートできるデータ量の拡大です。また、より大規模なクラスターにも対応できます。 現在、この機能は実験的であり、本番環境での使用は推奨されません。 @@ -33,7 +33,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - DDL操作のための分散並列実行フレームワークのサポート（実験的） [#37125](https://github.com/pingcap/tidb/issues/37125) @[zimulala](https://github.com/zimulala) - 以前のバージョンでは、TiDB クラスタ全体で 1 つの TiDB インスタンスのみが DDL オーナーとしてスキーマ変更タスクを処理できました。大規模テーブルの DDL 操作の DDL 並行性をさらに向上させるため、TiDB v6.6.0 では、DDL 用の分散並列実行フレームワークが導入されました。これにより、クラスタ内のすべての TiDB インスタンスが同じタスクの`StateWriteReorganization`フェーズを同時に実行して、DDL の実行を高速化できます。この機能はシステム変数[`tidb_ddl_distribute_reorg`](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660)によって制御され、現在は`Add Index`操作のみでサポートされています。 + 以前のバージョンでは、TiDB クラスター全体で 1 つの TiDB インスタンスのみが DDL オーナーとしてスキーマ変更タスクを処理できました。大規模テーブルの DDL 操作の DDL 並行性をさらに向上させるため、TiDB v6.6.0 では、DDL 用の分散並列実行フレームワークが導入されました。これにより、クラスター内のすべての TiDB インスタンスが同じタスクの`StateWriteReorganization`フェーズを同時に実行して、DDL の実行を高速化できます。この機能はシステム変数[`tidb_ddl_distribute_reorg`](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660)によって制御され、現在は`Add Index`操作のみでサポートされています。 ### パフォーマンス {#performance} @@ -77,16 +77,16 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - リソース グループに基づくリソース制御のサポート (実験的) [#38825](https://github.com/pingcap/tidb/issues/38825) @[nolouch](https://github.com/nolouch)@[BornChanger](https://github.com/BornChanger)[グロルヴ](https://github.com/glorv)@[tiancaiamao](https://github.com/tiancaiamao)@[Connor1996](https://github.com/Connor1996) @[JmPotato](https://github.com/JmPotato) @[hnes](https://github.com/hnes) @[CabinfeverB](https://github.com/CabinfeverB) @[HuSharp](https://github.com/HuSharp) - TiDBクラスタのリソースグループを作成し、異なるデータベースユーザーを対応するリソースグループにバインドし、実際のニーズに応じて各リソースグループのクォータを設定できるようになりました。クラスタのリソースが制限されている場合、同じリソースグループ内のセッションで使用されるすべてのリソースはクォータに制限されます。このようにして、リソースグループが過剰に消費された場合でも、他のリソースグループのセッションには影響しません。TiDBは、Grafanaダッシュボード上でリソースの実際の使用状況を表示する組み込みビューを提供し、リソースをより合理的に割り当てるのに役立ちます。 + TiDBクラスターのリソースグループを作成し、異なるデータベースユーザーを対応するリソースグループにバインドし、実際のニーズに応じて各リソースグループのクォータを設定できるようになりました。クラスターのリソースが制限されている場合、同じリソースグループ内のセッションで使用されるすべてのリソースはクォータに制限されます。このようにして、リソースグループが過剰に消費された場合でも、他のリソースグループのセッションには影響しません。TiDBは、Grafanaダッシュボード上でリソースの実際の使用状況を表示する組み込みビューを提供し、リソースをより合理的に割り当てるのに役立ちます。 - リソース制御機能の導入は、TiDBにとって画期的な出来事です。この機能により、分散データベースクラスタを複数の論理ユニットに分割できます。たとえ個々のユニットがリソースを過剰に使用したとしても、他のユニットが必要とするリソースを圧迫することはありません。 + リソース制御機能の導入は、TiDBにとって画期的な出来事です。この機能により、分散データベースクラスターを複数の論理ユニットに分割できます。たとえ個々のユニットがリソースを過剰に使用したとしても、他のユニットが必要とするリソースを圧迫することはありません。 この機能を使うと、次のことができます。 - - 異なるシステムに存在する複数の中小規模アプリケーションを単一のTiDBクラスタに統合します。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作には影響しません。システムワークロードが低い場合、ビジー状態のアプリケーションは、設定された読み取り/書き込みクォータを超えても必要なシステムリソースを割り当てられるため、リソースを最大限に活用できます。 - - すべてのテスト環境を単一のTiDBクラスタに統合するか、より多くのリソースを消費するバッチタスクを単一のリソースグループにまとめるかを選択できます。これにより、ハードウェア利用率を向上させ、運用コストを削減しながら、重要なアプリケーションが常に必要なリソースを確保できるようになります。 + - 異なるシステムに存在する複数の中小規模アプリケーションを単一のTiDBクラスターに統合します。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作には影響しません。システムワークロードが低い場合、ビジー状態のアプリケーションは、設定された読み取り/書き込みクォータを超えても必要なシステムリソースを割り当てられるため、リソースを最大限に活用できます。 + - すべてのテスト環境を単一のTiDBクラスターに統合するか、より多くのリソースを消費するバッチタスクを単一のリソースグループにまとめるかを選択できます。これにより、ハードウェア利用率を向上させ、運用コストを削減しながら、重要なアプリケーションが常に必要なリソースを確保できるようになります。 - さらに、リソース制御機能を合理的に活用することで、クラスタ数を削減し、運用・保守の難易度を下げ、管理コストを削減することができます。 + さらに、リソース制御機能を合理的に活用することで、クラスター数を削減し、運用・保守の難易度を下げ、管理コストを削減することができます。 v6.6 では、リソース制御を有効にするには、TiDB のグローバル変数[`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660)と TiKV 設定項目[`resource-control.enabled`](/tikv-configuration-file.md#resource-control)両方を有効にする必要があります。現在サポートされているクォータ方式は「 [リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru) 」に基づいています。RU は、CPU や IO などのシステム リソースに対する TiDB の統一抽象化ユニットです。 @@ -117,14 +117,14 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone `SURVIVAL_PREFERENCES` 、データの災害時における耐障害性を高めるためのデータ耐障害性設定を提供します。 `SURVIVAL_PREFERENCE`を指定することで、以下の項目を制御できます。 - - クラウドリージョンをまたいでデプロイされたTiDBクラスタの場合、あるクラウドリージョンで障害が発生しても、指定されたデータベースまたはテーブルは別のクラウドリージョンで存続できます。 - - 単一のクラウドリージョンにデプロイされたTiDBクラスタの場合、可用性ゾーンに障害が発生した場合でも、指定されたデータベースまたはテーブルは別の可用性ゾーンで存続できます。 + - クラウドリージョンをまたいでデプロイされたTiDBクラスターの場合、あるクラウドリージョンで障害が発生しても、指定されたデータベースまたはテーブルは別のクラウドリージョンで存続できます。 + - 単一のクラウドリージョンにデプロイされたTiDBクラスターの場合、可用性ゾーンに障害が発生した場合でも、指定されたデータベースまたはテーブルは別の可用性ゾーンで存続できます。 詳細については、 [ドキュメント](/placement-rules-in-sql.md#specify-survival-preferences)を参照してください。 - `FLASHBACK CLUSTER TO TIMESTAMP`ステートメントによる DDL 操作のロールバックのサポート [#14045](https://github.com/tikv/tikv/issues/14045) @[Defined2014](https://github.com/Defined2014) @[JmPotato](https://github.com/JmPotato) - [`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-cluster.md)ステートメントは、ガベージ コレクション (GC) の有効期間内の指定された時点にクラスタ全体を復元することをサポートします。TiDB v6.6.0 では、この機能に DDL 操作のロールバック機能が追加されました。これにより、クラスタ上で発生した DML または DDL 操作の誤りを迅速に取り消したり、クラスタを数分以内にロールバックしたり、タイムライン上でクラスタを複数回ロールバックして特定のデータ変更が発生したタイミングを特定したりすることができます。 + [`FLASHBACK CLUSTER TO TIMESTAMP`](/sql-statements/sql-statement-flashback-cluster.md)ステートメントは、ガベージ コレクション (GC) の有効期間内の指定された時点にクラスター全体を復元することをサポートします。TiDB v6.6.0 では、この機能に DDL 操作のロールバック機能が追加されました。これにより、クラスター上で発生した DML または DDL 操作の誤りを迅速に取り消したり、クラスターを数分以内にロールバックしたり、タイムライン上でクラスターを複数回ロールバックして特定のデータ変更が発生したタイミングを特定したりすることができます。 詳細については、 [ドキュメント](/sql-statements/sql-statement-flashback-cluster.md)を参照してください。 @@ -146,9 +146,9 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone ### データベース操作 {#db-operations} -- リソースを大量に消費するタスク向けに読み取り専用storageノードを構成する機能をサポート @[v01dstar](https://github.com/v01dstar) +- リソースを大量に消費するタスク向けに読み取り専用ストレージノードを構成する機能をサポート @[v01dstar](https://github.com/v01dstar) - 本番環境では、バックアップや大規模なデータ読み取りと分析など、読み取り専用操作が定期的に大量のリソースを消費し、クラスタ全体のパフォーマンスに影響を与える場合があります。TiDB v6.6.0 では、リソースを消費する読み取り専用タスク用に読み取り専用storageノードを構成して、オンライン アプリケーションへの影響を軽減できます。現在、TiDB、TiSpark、およびBR は、読み取り専用storageノードからのデータ読み取りをサポートしています。 [手順](/best-practices/readonly-nodes.md#procedures)のパフォーマンスの安定性を確保するため、システム変数`tidb_replica_read` 、TiSpark 構成項目`spark.tispark.replica_read` 、または br コマンドstorage引数`--replica-read-label` 、読み取り先を指定して、読み取り専用ストレージ ノードを次のように構成できます。 + 本番環境では、バックアップや大規模なデータ読み取りと分析など、読み取り専用操作が定期的に大量のリソースを消費し、クラスター全体のパフォーマンスに影響を与える場合があります。TiDB v6.6.0 では、リソースを消費する読み取り専用タスク用に読み取り専用ストレージノードを構成して、オンライン アプリケーションへの影響を軽減できます。現在、TiDB、TiSpark、およびBR は、読み取り専用ストレージノードからのデータ読み取りをサポートしています。 [手順](/best-practices/readonly-nodes.md#procedures)のパフォーマンスの安定性を確保するため、システム変数`tidb_replica_read` 、TiSpark 構成項目`spark.tispark.replica_read` 、または br コマンドストレージ引数`--replica-read-label` 、読み取り先を指定して、読み取り専用ストレージ ノードを次のように構成できます。 詳細については、[ドキュメント](/best-practices/readonly-nodes.md)を参照してください。 @@ -158,9 +158,9 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone 詳細については、[ドキュメント](/dynamic-config.md)を参照してください。 -- TiDBクラスタ初期化時に実行されるSQLスクリプトの指定をサポートする [#35624](https://github.com/pingcap/tidb/issues/35624) @[morgo](https://github.com/morgo) +- TiDBクラスター初期化時に実行されるSQLスクリプトの指定をサポートする [#35624](https://github.com/pingcap/tidb/issues/35624) @[morgo](https://github.com/morgo) - TiDB クラスタを初めて起動する際に、コマンドライン パラメータ`--initialize-sql-file`を設定することで、実行する SQL スクリプトを指定できます。この機能は、システム変数の値の変更、ユーザーの作成、権限の付与などの操作を実行する必要がある場合に使用できます。 + TiDB クラスターを初めて起動する際に、コマンドライン パラメータ`--initialize-sql-file`を設定することで、実行する SQL スクリプトを指定できます。この機能は、システム変数の値の変更、ユーザーの作成、権限の付与などの操作を実行する必要がある場合に使用できます。 詳細については、 [ドキュメント](/tidb-configuration-file.md#initialize-sql-file-new-in-v660)を参照してください。 @@ -188,7 +188,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - TiKV-CDC ツールは現在 GA であり、RawKV [#48](https://github.com/tikv/migration/issues/48) @[zeminzhou](https://github.com/zeminzhou)@[haojinming](https://github.com/haojinming)[ピンギュ](https://github.com/pingyu)データ変更のサブスクライブをサポートしています。 - TiKV-CDCは、TiKVクラスタ用のCDC（変更データキャプチャ）ツールです。TiKVとPDは、TiDBを使用しない場合、RawKVと呼ばれるKVデータベースを構成できます。TiKV-CDCは、RawKVのデータ変更を購読し、それを下流のTiKVクラスタにリアルタイムで複製することをサポートしており、RawKVのクラスタ間レプリケーションを可能にします。 + TiKV-CDCは、TiKVクラスター用のCDC（変更データキャプチャ）ツールです。TiKVとPDは、TiDBを使用しない場合、RawKVと呼ばれるKVデータベースを構成できます。TiKV-CDCは、RawKVのデータ変更を購読し、それを下流のTiKVクラスターにリアルタイムで複製することをサポートしており、RawKVのクラスター間レプリケーションを可能にします。 詳細については、 [ドキュメント](https://tikv.org/docs/latest/concepts/explore-tikv-features/cdc/cdc/)を参照してください。 @@ -268,7 +268,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - TiFlashはTLS証明書の自動ローテーションをサポートします [#5503](https://github.com/pingcap/tiflash/issues/5503) @[ywqzzy](https://github.com/ywqzzy) - バージョン6.6.0では、TiDBはTiFlash TLS証明書の自動ローテーションをサポートしています。コンポーネント間で暗号化されたデータ転送が有効になっているTiDBクラスタでは、 TiFlashのTLS証明書の有効期限が切れて新しい証明書に再発行する必要が生じた場合、TiDBクラスタを再起動することなく、新しいTiFlash TLS証明書を自動的にロードできます。さらに、TiDBクラスタ内のコンポーネント間でTLS証明書をローテーションしても、TiDBクラスタの使用には影響しないため、クラスタの高い可用性が確保されます。 + バージョン6.6.0では、TiDBはTiFlash TLS証明書の自動ローテーションをサポートしています。コンポーネント間で暗号化されたデータ転送が有効になっているTiDBクラスターでは、 TiFlashのTLS証明書の有効期限が切れて新しい証明書に再発行する必要が生じた場合、TiDBクラスターを再起動することなく、新しいTiFlash TLS証明書を自動的にロードできます。さらに、TiDBクラスター内のコンポーネント間でTLS証明書をローテーションしても、TiDBクラスターの使用には影響しないため、クラスターの高い可用性が確保されます。 詳細については、[ドキュメント](/enable-tls-between-components.md)を参照してください。 @@ -313,16 +313,16 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone | [`tidb_enable_plan_replayer_capture`](/system-variables.md#tidb_enable_plan_replayer_capture) | 修正済み | この変数はv6.6.0から有効になり、 [`PLAN REPLAYER CAPTURE`機能](/sql-plan-replayer.md#use-plan-replayer-capture-to-capture-target-plans)を有効にするかどうかを制御します。デフォルト値は`OFF`から`ON`に変更され、 `PLAN REPLAYER CAPTURE`機能がデフォルトで有効になります。 | | [`tidb_enable_telemetry`](/system-variables.md#tidb_enable_telemetry-new-in-v402) | 修正済み | デフォルト値が`ON`から`OFF`に変更されます。これは、TiDB でテレメトリがデフォルトで無効になっていることを意味します。 | | `tidb_general_plan_cache_size` | 修正済み | この変数は、General Plan Cache によってキャッシュできる実行プランの最大数を制御します。v6.6.0 以降、この変数は[`tidb_non_prepared_plan_cache_size`](/system-variables.md#tidb_non_prepared_plan_cache_size)に名前が変更されました。 | -| [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40) | 修正済み | この変数に新しい値オプション`learner`が追加され、TiDB が読み取り専用ノードからデータを読み取る際に使用する学習者レプリカを指定できます。 | -| [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40) | 修正済み | TiDBクラスタの読み取り可用性を向上させるため、この変数に新しい値オプション`prefer-leader`が追加されました。このオプションを設定すると、TiDBはリーダーレプリカからの読み取りを優先します。リーダーレプリカのパフォーマンスが著しく低下した場合、TiDBは自動的にフォロワーレプリカからの読み取りに切り替わります。 | +| [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40) | 修正済み | この変数に新しい値オプション`learner`が追加され、TiDB が読み取り専用ノードからデータを読み取る際に使用するラーナーレプリカを指定できます。 | +| [`tidb_replica_read`](/system-variables.md#tidb_replica_read-new-in-v40) | 修正済み | TiDBクラスターの読み取り可用性を向上させるため、この変数に新しい値オプション`prefer-leader`が追加されました。このオプションを設定すると、TiDBはリーダーレプリカからの読み取りを優先します。リーダーレプリカのパフォーマンスが著しく低下した場合、TiDBは自動的にフォロワーレプリカからの読み取りに切り替わります。 | | [`tidb_store_batch_size`](/system-variables.md#tidb_store_batch_size) | 修正済み | この変数は`IndexLookUp`オペレータのコプロセッサータスクのバッチ サイズを制御します。 `0`バッチを無効にすることを意味します。v6.6.0 以降、デフォルト値は`0`から`4`に変更され、リクエストのバッチごとに 4 つのコプロセッサータスクが 1 つのタスクにまとめられます。 | | [`mpp_exchange_compression_mode`](/system-variables.md#mpp_exchange_compression_mode-new-in-v660) | 新しく追加された | この変数は、MPP Exchange オペレータのデータ圧縮モードを指定します。この変数は、TiDB がバージョン番号`1`の MPP 実行プランを選択した場合に有効になります。デフォルト値`UNSPECIFIED`は、TiDB が自動的に`FAST`圧縮モードを選択することを意味します。 | | [`mpp_version`](/system-variables.md#mpp_version-new-in-v660) | 新しく追加された | この変数は、MPP実行プランのバージョンを指定します。バージョンを指定すると、TiDBは指定されたバージョンのMPP実行プランを選択します。デフォルト値`UNSPECIFIED` 、TiDBが最新バージョン`1`自動的に選択することを意味します。 | | [`tidb_ddl_distribute_reorg`](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_ddl_distribute_reorg-new-in-v660) | 新しく追加された | この変数は、DDL 再編成フェーズの分散実行を有効にしてこのフェーズを高速化するかどうかを制御します。デフォルト値`OFF`は、デフォルトでは DDL 再編成フェーズの分散実行を有効にしないことを意味します。現在、この変数は`ADD INDEX`に対してのみ有効です。 | | [`tidb_enable_historical_stats_for_capture`](/system-variables.md#tidb_enable_historical_stats_for_capture) | 新しく追加された | この変数は`PLAN REPLAYER CAPTURE`で取得される情報に、デフォルトで履歴統計が含まれるかどうかを制御します。デフォルト値の`OFF`は、デフォルトでは履歴統計が含まれないことを意味します。 | | [`tidb_enable_plan_cache_for_param_limit`](/system-variables.md#tidb_enable_plan_cache_for_param_limit-new-in-v660) | 新しく追加された | この変数は`COUNT` `Limit` 0-PLACEHOLDER-E}} が含まれる実行プランをプリペアドプランキャッシュがキャッシュするかどうかを制御します。デフォルト値は`ON`で、これはプリペアドプランキャッシュ がそのような実行プランのキャッシュをサポートすることを意味します。ただし、 プリペアドプランキャッシュ は、 10000 を超える数値をカウントする`COUNT`条件を含む実行プランのキャッシュをサポートしていないことに注意してください。 | -| [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660) | 新しく追加された | この変数は、リソース制御機能を有効にするかどうかを制御します。デフォルト値は`OFF`です。この変数を`ON`に設定すると、TiDB クラスタはリソース グループに基づいたアプリケーションのリソース分離をサポートします。 | -| [`tidb_historical_stats_duration`](/system-variables.md#tidb_historical_stats_duration-new-in-v660) | 新しく追加された | この変数は、過去の統計情報をstorageに保存する期間を制御します。デフォルト値は7日間です。 | +| [`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660) | 新しく追加された | この変数は、リソース制御機能を有効にするかどうかを制御します。デフォルト値は`OFF`です。この変数を`ON`に設定すると、TiDB クラスターはリソース グループに基づいたアプリケーションのリソース分離をサポートします。 | +| [`tidb_historical_stats_duration`](/system-variables.md#tidb_historical_stats_duration-new-in-v660) | 新しく追加された | この変数は、過去の統計情報をストレージに保存する期間を制御します。デフォルト値は7日間です。 | | [`tidb_index_join_double_read_penalty_cost_rate`](/system-variables.md#tidb_index_join_double_read_penalty_cost_rate-new-in-v660) | 新しく追加された | この変数は、インデックス結合の選択にペナルティコストを追加するかどうかを制御します。デフォルト値`0`は、この機能がデフォルトで無効になっていることを意味します。 | | [`tidb_pessimistic_txn_aggressive_locking`](https://docs-archive.pingcap.com/tidb/v6.6/system-variables#tidb_pessimistic_txn_aggressive_locking-new-in-v660) | 新しく追加された | この変数は、悲観的トランザクションに対して拡張悲観的ロックウェイクアップモデルを使用するかどうかを制御します。デフォルト値`OFF`は、デフォルトでは悲観的トランザクションに対してこのようなウェイクアップモデルを使用しないことを意味します。 | | [`tidb_stmt_summary_enable_persistent`](/system-variables.md#tidb_stmt_summary_enable_persistent-new-in-v660) | 新しく追加された | この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)を有効にするかどうかを制御します。この変数の値は、構成項目[`tidb_stmt_summary_enable_persistent`](/tidb-configuration-file.md#tidb_stmt_summary_enable_persistent-new-in-v660)の値と同じです。 | @@ -331,31 +331,31 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone | [`tidb_stmt_summary_file_max_days`](/system-variables.md#tidb_stmt_summary_file_max_days-new-in-v660) | 新しく追加された | この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合に、永続的なデータ ファイルを保持する最大日数を指定します。この変数の値は、構成項目[`tidb_stmt_summary_file_max_days`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_days-new-in-v660)の値と同じです。 | | [`tidb_stmt_summary_file_max_size`](/system-variables.md#tidb_stmt_summary_file_max_size-new-in-v660) | 新しく追加された | この変数は読み取り専用です。 [ステートメントの要約持続性](/statement-summary-tables.md#persist-statements-summary)が有効な場合の永続データ ファイルの最大サイズを指定します。この変数の値は、構成項目[`tidb_stmt_summary_file_max_size`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_size-new-in-v660)の値と同じです。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイル | 設定パラメータ | 種類を変更する | 説明 | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| ティクヴ | `rocksdb.enable-statistics` | 削除済み | この設定項目は、RocksDB の統計情報を有効にするかどうかを指定します。v6.6.0 以降、この項目は削除されました。RocksDB の統計情報は、診断を支援するために、デフォルトですべてのクラスタで有効になっています。詳細については、 [#13942](https://github.com/tikv/tikv/pull/13942)を参照してください。 | -| ティクヴ | `raftdb.enable-statistics` | 削除済み | この設定項目は、 Raft RocksDB の統計情報を有効にするかどうかを指定します。v6.6.0 以降、この項目は削除されました。Raft RocksDBの統計情報は、診断を支援するために、デフォルトですべてのクラスターで有効になっています。詳細については、 [#13942](https://github.com/tikv/tikv/pull/13942)を参照してください。 | -| ティクヴ | `storage.block-cache.shared` | 削除済み | バージョン6.6.0以降、この設定項目は削除され、ブロックキャッシュはデフォルトで有効になり、無効にすることはできません。詳細は[#12936](https://github.com/tikv/tikv/issues/12936)を参照してください。 | +| TiKV | `rocksdb.enable-statistics` | 削除済み | この設定項目は、RocksDB の統計情報を有効にするかどうかを指定します。v6.6.0 以降、この項目は削除されました。RocksDB の統計情報は、診断を支援するために、デフォルトですべてのクラスターで有効になっています。詳細については、 [#13942](https://github.com/tikv/tikv/pull/13942)を参照してください。 | +| TiKV | `raftdb.enable-statistics` | 削除済み | この設定項目は、 Raft RocksDB の統計情報を有効にするかどうかを指定します。v6.6.0 以降、この項目は削除されました。Raft RocksDBの統計情報は、診断を支援するために、デフォルトですべてのクラスターで有効になっています。詳細については、 [#13942](https://github.com/tikv/tikv/pull/13942)を参照してください。 | +| TiKV | `ストレージ.block-cache.shared` | 削除済み | バージョン6.6.0以降、この設定項目は削除され、ブロックキャッシュはデフォルトで有効になり、無効にすることはできません。詳細は[#12936](https://github.com/tikv/tikv/issues/12936)を参照してください。 | | DM | `on-duplicate` | 削除済み | この構成項目は、完全インポートフェーズ中に競合を解決する方法を制御します。v6.6.0 では、 `on-duplicate-logical` `on-duplicate-physical`と`on-duplicate`が導入されました。 | | TiDB | [`enable-telemetry`](/tidb-configuration-file.md#enable-telemetry-new-in-v402) | 修正済み | バージョン6.6.0以降、デフォルト値が`true`から`false`に変更され、TiDBではデフォルトでテレメトリが無効になります。 | -| ティクヴ | [`rocksdb.defaultcf.block-size`](/tikv-configuration-file.md#block-size)および[`rocksdb.writecf.block-size`](/tikv-configuration-file.md#block-size) | 修正済み | デフォルト値が`64K`から`32K`に変更されます。 | -| ティクヴ | [`rocksdb.defaultcf.block-cache-size`](/tikv-configuration-file.md#block-cache-size) 、 [`rocksdb.writecf.block-cache-size`](/tikv-configuration-file.md#block-cache-size) 、 [`rocksdb.lockcf.block-cache-size`](/tikv-configuration-file.md#block-cache-size) | 非推奨 | バージョン6.6.0以降、これらの設定項目は非推奨となりました。詳細は[#12936](https://github.com/tikv/tikv/issues/12936)を参照してください。 | +| TiKV | [`rocksdb.defaultcf.block-size`](/tikv-configuration-file.md#block-size)および[`rocksdb.writecf.block-size`](/tikv-configuration-file.md#block-size) | 修正済み | デフォルト値が`64K`から`32K`に変更されます。 | +| TiKV | [`rocksdb.defaultcf.block-cache-size`](/tikv-configuration-file.md#block-cache-size) 、 [`rocksdb.writecf.block-cache-size`](/tikv-configuration-file.md#block-cache-size) 、 [`rocksdb.lockcf.block-cache-size`](/tikv-configuration-file.md#block-cache-size) | 非推奨 | バージョン6.6.0以降、これらの設定項目は非推奨となりました。詳細は[#12936](https://github.com/tikv/tikv/issues/12936)を参照してください。 | | PD | [`enable-telemetry`](/pd-configuration-file.md#enable-telemetry) | 修正済み | バージョン6.6.0以降、デフォルト値が`true`から`false`に変更され、TiDBダッシュボードではテレメトリがデフォルトで無効になります。 | | DM | [`import-mode`](/dm/task-configuration-file-full.md) | 修正済み | この構成項目の指定可能な値は、 `"sql"`および`"loader"`から`"logical"`および`"physical"`に変更されます。デフォルト値は`"logical"`で、これは TiDB Lightning の論理インポートモードを使用してデータをインポートすることを意味します。 | | TiFlash | [`profile.default.max_memory_usage_for_all_queries`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 修正済み | すべてのクエリで生成される中間データのメモリ使用量制限を指定します。v6.6.0以降、デフォルト値は`0`から`0.8`に変更され、制限は総メモリの80%になります。 | -| TiCDC | [`consistent.storage`](/ticdc/ticdc-sink-to-mysql.md#prerequisites) | 修正済み | この構成項目は、リドゥログのバックアップが保存されるパスを指定します。 `scheme` 、GCS、およびAzure用に、さらに2つの値オプションが追加されました。 | -| TiDB | [`initialize-sql-file`](/tidb-configuration-file.md#initialize-sql-file-new-in-v660) | 新しく追加された | この設定項目は、TiDBクラスタが初めて起動されたときに実行されるSQLスクリプトを指定します。デフォルト値は空です。 | +| TiCDC | [`consistent.ストレージ`](/ticdc/ticdc-sink-to-mysql.md#prerequisites) | 修正済み | この構成項目は、リドゥログのバックアップが保存されるパスを指定します。 `scheme` 、GCS、およびAzure用に、さらに2つの値オプションが追加されました。 | +| TiDB | [`initialize-sql-file`](/tidb-configuration-file.md#initialize-sql-file-new-in-v660) | 新しく追加された | この設定項目は、TiDBクラスターが初めて起動されたときに実行されるSQLスクリプトを指定します。デフォルト値は空です。 | | TiDB | [`tidb_stmt_summary_enable_persistent`](/tidb-configuration-file.md#tidb_stmt_summary_enable_persistent-new-in-v660) | 新しく追加された | この設定項目は、明細書の要約を永続化するかどうかを制御します。デフォルト値は`false`で、これはこの機能がデフォルトでは無効になっていることを意味します。 | | TiDB | [`tidb_stmt_summary_file_max_backups`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_backups-new-in-v660) | 新しく追加された | ステートメントサマリーの永続化が有効になっている場合、この設定では永続化できるデータファイルの最大数を指定します。 `0`ファイル数に制限がないことを意味します。 | | TiDB | [`tidb_stmt_summary_file_max_days`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_days-new-in-v660) | 新しく追加された | 明細書の要約データの永続化が有効になっている場合、この設定では永続データファイルを保持する最大日数を指定します。 | | TiDB | [`tidb_stmt_summary_file_max_size`](/tidb-configuration-file.md#tidb_stmt_summary_file_max_size-new-in-v660) | 新しく追加された | ステートメントサマリーの永続化が有効になっている場合、この設定では永続データファイルの最大サイズ（MiB単位）を指定します。 | | TiDB | [`tidb_stmt_summary_filename`](/tidb-configuration-file.md#tidb_stmt_summary_filename-new-in-v660) | 新しく追加された | 明細書の要約データの永続化が有効になっている場合、この設定では永続データが書き込まれるファイルを指定します。 | -| ティクヴ | [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) | 新しく追加された | 対応するリソース グループの要求単位 (RU) に基づいて、ユーザーのフォアグラウンド読み取り/書き込み要求のスケジューリングを有効にするかどうか。デフォルト値は`false`で、これは対応するリソース グループの RU に基づくスケジューリングを無効にすることを意味します。 | -| ティクヴ | [`storage.engine`](/tikv-configuration-file.md#engine-new-in-v660) | 新しく追加された | この構成項目は、storageエンジンのタイプを指定します。値のオプションは`"raft-kv"`と`"partitioned-raft-kv"`です。この構成項目は、クラスタ作成時にのみ指定でき、一度指定すると変更できません。 | -| ティクヴ | [`rocksdb.write-buffer-flush-oldest-first`](/tikv-configuration-file.md#write-buffer-flush-oldest-first-new-in-v660) | 新しく追加された | この設定項目は、現在の RocksDB の`memtable`のメモリ使用量がしきい値に達したときに使用されるフラッシュ戦略を指定します。 | -| ティクヴ | [`rocksdb.write-buffer-limit`](/tikv-configuration-file.md#write-buffer-limit-new-in-v660) | 新しく追加された | この設定項目は、単一の TiKV 内のすべての RocksDB インスタンス`memtable`が使用する合計メモリの制限を指定します。デフォルト値は、マシン全体のメモリの 25% です。 | +| TiKV | [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) | 新しく追加された | 対応するリソース グループの要求単位 (RU) に基づいて、ユーザーのフォアグラウンド読み取り/書き込み要求のスケジューリングを有効にするかどうか。デフォルト値は`false`で、これは対応するリソース グループの RU に基づくスケジューリングを無効にすることを意味します。 | +| TiKV | [`ストレージ.engine`](/tikv-configuration-file.md#engine-new-in-v660) | 新しく追加された | この構成項目は、ストレージエンジンのタイプを指定します。値のオプションは`"raft-kv"`と`"partitioned-raft-kv"`です。この構成項目は、クラスター作成時にのみ指定でき、一度指定すると変更できません。 | +| TiKV | [`rocksdb.write-buffer-flush-oldest-first`](/tikv-configuration-file.md#write-buffer-flush-oldest-first-new-in-v660) | 新しく追加された | この設定項目は、現在の RocksDB の`memtable`のメモリ使用量がしきい値に達したときに使用されるフラッシュ戦略を指定します。 | +| TiKV | [`rocksdb.write-buffer-limit`](/tikv-configuration-file.md#write-buffer-limit-new-in-v660) | 新しく追加された | この設定項目は、単一の TiKV 内のすべての RocksDB インスタンス`memtable`が使用する合計メモリの制限を指定します。デフォルト値は、マシン全体のメモリの 25% です。 | | PD | [`pd-server.enable-gogc-tuner`](/pd-configuration-file.md#enable-gogc-tuner-new-in-v660) | 新しく追加された | この設定項目は、GOGCチューナーを有効にするかどうかを制御します。デフォルトでは無効になっています。 | | PD | [`pd-server.gc-tuner-threshold`](/pd-configuration-file.md#gc-tuner-threshold-new-in-v660) | 新しく追加された | この設定項目は、GOGC のチューニングにおける最大メモリしきい値比率を指定します。デフォルト値は`0.6`です。 | | PD | [`pd-server.server-memory-limit-gc-trigger`](/pd-configuration-file.md#server-memory-limit-gc-trigger-new-in-v660) | 新しく追加された | この設定項目は、PD が GC をトリガーしようとするしきい値比率を指定します。デフォルト値は`0.7`です。 | @@ -396,9 +396,9 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - パーティションテーブルが依存する列が削除されたときに報告されるエラーメッセージを改善する [#38739](https://github.com/pingcap/tidb/issues/38739) @[jiyfhust](https://github.com/jiyfhust) - `FLASHBACK CLUSTER`が`min-resolved-ts`のチェックに失敗した場合に再試行するメカニズムを追加します [#39836](https://github.com/pingcap/tidb/issues/39836) @[Defined2014](https://github.com/Defined2014) -- ティクヴ +- TiKV - - partitioned-raft-kv モードにおける一部のパラメータのデフォルト値を最適化します。TiKV 設定項目`storage.block-cache.capacity`のデフォルト値を 45% から 30% に調整し、 `region-split-size`のデフォルト値を`96MiB`から`10GiB`に調整します。raft-kv モードを使用し、 `enable-region-bucket`が`true`の場合、 `region-split-size`はデフォルトで 1 GiB に調整されます。 [#12842](https://github.com/tikv/tikv/issues/12842) @[tonyxuqqi](https://github.com/tonyxuqqi) + - partitioned-raft-kv モードにおける一部のパラメータのデフォルト値を最適化します。TiKV 設定項目`ストレージ.block-cache.capacity`のデフォルト値を 45% から 30% に調整し、 `region-split-size`のデフォルト値を`96MiB`から`10GiB`に調整します。raft-kv モードを使用し、 `enable-region-bucket`が`true`の場合、 `region-split-size`はデフォルトで 1 GiB に調整されます。 [#12842](https://github.com/tikv/tikv/issues/12842) @[tonyxuqqi](https://github.com/tonyxuqqi) - Raftstoreの非同期書き込みにおける優先度スケジューリングのサポート [#13730](https://github.com/tikv/tikv/issues/13730) @[Connor1996](https://github.com/Connor1996) - コア数が1未満のCPUでTiKVを起動するサポート[#13586](https://github.com/tikv/tikv/issues/13586) [#13752](https://github.com/tikv/tikv/issues/13752) [#14017](https://github.com/tikv/tikv/issues/14017) @[andreid-db](https://github.com/andreid-db) - Raftstoreのスロースコアの新しい検出メカニズムを最適化し、 `evict-slow-trend-scheduler` [#14131](https://github.com/tikv/tikv/issues/14131) @[innerr](https://github.com/innerr)を追加しました @@ -501,7 +501,7 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - IndexMerge オペレーターがメモリ制限動作をトリガーしたときの TiDBサーバーのpanicを修正 [#41036](https://github.com/pingcap/tidb/pull/41036) @[guo-shaoge](https://github.com/guo-shaoge) - パーティションテーブルに対する`SELECT * FROM table_name LIMIT 1`クエリが遅い問題を修正 [#40741](https://github.com/pingcap/tidb/pull/40741) @[solotzg](https://github.com/solotzg) -- ティクヴ +- TiKV - `const Enum`型を他の型にキャストする際に発生するエラーを修正します [#14156](https://github.com/tikv/tikv/issues/14156) @[wshwsh12](https://github.com/wshwsh12) - 解決された TS によりネットワーク トラフィックが増加する問題を修正 [#14092](https://github.com/tikv/tikv/issues/14092) @[overvenus](https://github.com/overvenus) @@ -532,14 +532,14 @@ TiDB バージョン: 6.6.0- [DMR](/releases/versioning.md#development-milestone - PITR が PD クラスターの構成変更をサポートしていない問題を修正 [#14165](https://github.com/tikv/tikv/issues/14165) @[YuJuncen](https://github.com/YuJuncen) - PDとtidb-server間の接続障害によりPITRバックアップの進行状況が進まなくなる問題を修正 [#41082](https://github.com/pingcap/tidb/issues/41082) @[YuJuncen](https://github.com/YuJuncen) - PDとTiKV間の接続障害によりTiKVがPITRタスクをリッスンできない問題を修正 [#14159](https://github.com/tikv/tikv/issues/14159) @[YuJuncen](https://github.com/YuJuncen) - - TiDBクラスタにPITRバックアップタスクがない場合、 `resolve lock`の頻度が高すぎる問題を修正 [#40759](https://github.com/pingcap/tidb/issues/40759) @[joccau](https://github.com/joccau) + - TiDBクラスターにPITRバックアップタスクがない場合、 `resolve lock`の頻度が高すぎる問題を修正 [#40759](https://github.com/pingcap/tidb/issues/40759) @[joccau](https://github.com/joccau) - PITRバックアップタスクが削除された際に、残存バックアップデータが原因で新しいタスクのデータ不整合が発生する問題を修正しました [#40403](https://github.com/pingcap/tidb/issues/40403) @[joccau](https://github.com/joccau) - TiCDC - `transaction_atomicity`と`protocol`が設定ファイル経由で更新できない問題を修正しました [#7935](https://github.com/pingcap/tiflow/issues/7935) @[CharlesCheung96](https://github.com/CharlesCheung96) - - リドゥログのstorageパスで事前チェ​​ックが実行されない問題を修正 [#6335](https://github.com/pingcap/tiflow/issues/6335) @[CharlesCheung96](https://github.com/CharlesCheung96) - - S3storage障害時にリドゥログが許容できる期間が不十分であるという問題を修正 [#8089](https://github.com/pingcap/tiflow/issues/8089) @[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) - TiKV ノード間のトラフィックが多すぎる問題を修正 [#14092](https://github.com/tikv/tikv/issues/14092) @[overvenus](https://github.com/overvenus) - プルベースのシンクが有効になっている場合の CPU 使用率、メモリ制御、スループットに関する TiCDC のパフォーマンスの問題を修正[#8142](https://github.com/pingcap/tiflow/issues/8142) [#8157](https://github.com/pingcap/tiflow/issues/8157) [#8001](https://github.com/pingcap/tiflow/issues/8001) [#5928](https://github.com/pingcap/tiflow/issues/5928) @[hicqu](https://github.com/hicqu)@[Rustin170506](https://github.com/Rustin170506) diff --git a/releases/release-7.0.0.md b/releases/release-7.0.0.md index e4de6329b1982..717c8efd3b5ae 100644 --- a/releases/release-7.0.0.md +++ b/releases/release-7.0.0.md @@ -13,17 +13,17 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone バージョン7.0.0-DMRの主な新機能と改善点は以下のとおりです。 -
カテゴリ特徴説明
拡張性とパフォーマンス
セッションレベルの未準備SQLプランキャッシュ（実験的）セッションレベルでプランキャッシュを自動的に再利用することで、コンパイルを削減し、同じSQLパターンに対して事前に手動で準備ステートメントを設定することなくクエリ時間を短縮します。
TiFlashは 、分散型storageおよびコンピューティングアーキテクチャとS3共有storage（実験的）をサポートしています。 TiFlashは、オプションとしてクラウドネイティブアーキテクチャを導入します。
  • TiFlashのコンピューティング機能とstorageを分離することで、柔軟なHTAPリソース利用における画期的な進歩を実現しました。
  • S3ベースのstorageエンジンを導入し、より低コストで共有storageを提供可能にしました。
信頼性と可用性
リソース制御機能強化（実験的）リソースグループを使用して、1 つのクラスタ内のさまざまなアプリケーションやワークロードにリソースを割り当て、分離することをサポートします。今回のリリースでは、TiDB はさまざまなリソースバインディングモード (ユーザー、セッション、ステートメントレベル) とユーザー定義の優先度をサポートします。さらに、コマンドを使用してリソースのキャリブレーション (リソース全体の量の見積もり) を実行することもできます。
TiFlashはディスクへのスピルをサポートしていますTiFlashは、集計、ソート、ハッシュ結合などのデータ集約型操作におけるメモリ不足（OOM）を軽減するために、中間結果をディスクに書き出す機能をサポートしています。
SQL行レベルTTL （GA）一定期間経過したデータを自動的に削除することで、データベースサイズの管理をサポートし、パフォーマンスを向上させます。
LIST / RANGEパーティションを再編成するREORGANIZE PARTITIONステートメントは、隣接するパーティションをマージしたり、1 つのパーティションを複数のパーティションに分割したりするために使用でき、パーティション化されたテーブルの使いやすさを向上させます。
データベースの運用と可観測性
TiDBはLOAD DATAステートメントの機能を拡張します（実験的）。 TiDBは、S3/GCSからのデータインポートをサポートするなど、 LOAD DATA SQLステートメントの機能を拡張します。
TiCDCはオブジェクトstorageシンク（GA）をサポートしていますTiCDCは、Amazon S3、GCS、Azure Blob Storage、NFSなどのオブジェクトstorageサービスへの行変更イベントの複製をサポートしています。
+
カテゴリ特徴説明
拡張性とパフォーマンス
セッションレベルの未準備SQLプランキャッシュ（実験的）セッションレベルでプランキャッシュを自動的に再利用することで、コンパイルを削減し、同じSQLパターンに対して事前に手動で準備ステートメントを設定することなくクエリ時間を短縮します。
TiFlashは 、分散型ストレージおよびコンピューティングアーキテクチャとS3共有ストレージ（実験的）をサポートしています。 TiFlashは、オプションとしてクラウドネイティブアーキテクチャを導入します。
  • TiFlashのコンピューティング機能とストレージを分離することで、柔軟なHTAPリソース利用における画期的な進歩を実現しました。
  • S3ベースのストレージエンジンを導入し、より低コストで共有ストレージを提供可能にしました。
信頼性と可用性
リソース制御機能強化（実験的）リソースグループを使用して、1 つのクラスター内のさまざまなアプリケーションやワークロードにリソースを割り当て、分離することをサポートします。今回のリリースでは、TiDB はさまざまなリソースバインディングモード (ユーザー、セッション、ステートメントレベル) とユーザー定義の優先度をサポートします。さらに、コマンドを使用してリソースのキャリブレーション (リソース全体の量の見積もり) を実行することもできます。
TiFlashはディスクへのスピルをサポートしていますTiFlashは、集計、ソート、ハッシュ結合などのデータ集約型操作におけるメモリ不足（OOM）を軽減するために、中間結果をディスクに書き出す機能をサポートしています。
SQL行レベルTTL （GA）一定期間経過したデータを自動的に削除することで、データベースサイズの管理をサポートし、パフォーマンスを向上させます。
LIST / RANGEパーティションを再編成するREORGANIZE PARTITIONステートメントは、隣接するパーティションをマージしたり、1 つのパーティションを複数のパーティションに分割したりするために使用でき、パーティション化されたテーブルの使いやすさを向上させます。
データベースの運用と可観測性
TiDBはLOAD DATAステートメントの機能を拡張します（実験的）。 TiDBは、S3/GCSからのデータインポートをサポートするなど、 LOAD DATA SQLステートメントの機能を拡張します。
TiCDCはオブジェクトストレージシンク（GA）をサポートしていますTiCDCは、Amazon S3、GCS、Azure Blob Storage、NFSなどのオブジェクトストレージサービスへの行変更イベントの複製をサポートしています。
## 機能の詳細 {#feature-details} ### 拡張性 {#scalability} -- TiFlashは、分散storageとコンピューティングアーキテクチャをサポートし、このアーキテクチャにおけるオブジェクトstorageをサポートします（実験的） [#6882](https://github.com/pingcap/tiflash/issues/6882) @[flowbehappy](https://github.com/flowbehappy) +- TiFlashは、分散ストレージとコンピューティングアーキテクチャをサポートし、このアーキテクチャにおけるオブジェクトストレージをサポートします（実験的） [#6882](https://github.com/pingcap/tiflash/issues/6882) @[flowbehappy](https://github.com/flowbehappy) - バージョン7.0.0より前のTiFlashは、storageとコンピューティングが結合されたアーキテクチャのみをサポートしていました。このアーキテクチャでは、各TiFlashノードがstorageとコンピューティングノードの両方の役割を担い、コンピューティング機能とstorage機能を個別に拡張することはできませんでした。また、 TiFlashノードはローカルstorageしか使用できませんでした。 + バージョン7.0.0より前のTiFlashは、ストレージとコンピューティングが結合されたアーキテクチャのみをサポートしていました。このアーキテクチャでは、各TiFlashノードがストレージとコンピューティングノードの両方の役割を担い、コンピューティング機能とストレージ機能を個別に拡張することはできませんでした。また、 TiFlashノードはローカルストレージしか使用できませんでした。 - バージョン7.0.0以降、 TiFlashは分離型storageおよびコンピューティングアーキテクチャもサポートしています。このアーキテクチャでは、 TiFlashノードは2種類（コンピューティングノードと書き込みノード）に分かれており、S3 APIと互換性のあるオブジェクトstorageをサポートしています。どちらのタイプのノードも、コンピューティング容量またはstorage容量に合わせて個別にスケーリングできます。**分離型storageおよびコンピューティングアーキテクチャ**と**結合型storageおよびコンピューティングアーキテクチャは、**同じクラスタ内で使用したり、相互に変換したりすることはできません。TiFlashをデプロイする際に、使用するアーキテクチャを設定できます。 + バージョン7.0.0以降、 TiFlashは分離型ストレージおよびコンピューティングアーキテクチャもサポートしています。このアーキテクチャでは、 TiFlashノードは2種類（コンピューティングノードと書き込みノード）に分かれており、S3 APIと互換性のあるオブジェクトストレージをサポートしています。どちらのタイプのノードも、コンピューティング容量またはストレージ容量に合わせて個別にスケーリングできます。**分離型ストレージおよびコンピューティングアーキテクチャ**と**結合型ストレージおよびコンピューティングアーキテクチャは、**同じクラスター内で使用したり、相互に変換したりすることはできません。TiFlashをデプロイする際に、使用するアーキテクチャを設定できます。 詳細については、[ドキュメント](/tiflash/tiflash-disaggregated-and-s3.md)を参照してください。 @@ -33,7 +33,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone TiDB v6.5.0では、 [高速オンラインDDL](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) [PITR](/br/backup-and-restore-overview.md)と完全には互換性がありません。完全なデータバックアップを確実に行うには、まずPITRのバックグラウンドバックアップタスクを停止し、高速オンラインDDLを使用してインデックスをすばやく追加してから、PITRのバックアップタスクを再開することをお勧めします。 - TiDB v7.0.0以降、Fast Online DDLとPITRは完全に互換性があります。PITRを使用してクラスタデータを復元する場合、ログバックアップ中にFast Online DDLで追加されたインデックス操作が自動的に再生され、互換性が確保されます。 + TiDB v7.0.0以降、Fast Online DDLとPITRは完全に互換性があります。PITRを使用してクラスターデータを復元する場合、ログバックアップ中にFast Online DDLで追加されたインデックス操作が自動的に再生され、互換性が確保されます。 詳細については、[ドキュメント](/best-practices/ddl-introduction.md)を参照してください。 @@ -97,11 +97,11 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - リソース制御機能の強化 (実験的) [#38825](https://github.com/pingcap/tidb/issues/38825) @[nolouch](https://github.com/nolouch)@[BornChanger](https://github.com/BornChanger)@[glorv](https://github.com/glorv)@[tiancaiamao](https://github.com/tiancaiamao)@[Connor1996](https://github.com/Connor1996) @[JmPotato](https://github.com/JmPotato) @[hnes](https://github.com/hnes) @[CabinfeverB](https://github.com/CabinfeverB) @[HuSharp](https://github.com/HuSharp) - TiDBは、リソースグループに基づくリソース制御機能を強化しました。この機能により、TiDBクラスタのリソース利用効率とパフォーマンスが大幅に向上します。リソース制御機能の導入は、TiDBにとって画期的な出来事です。分散データベースクラスタを複数の論理ユニットに分割し、異なるデータベースユーザーを対応するリソースグループにマッピングし、必要に応じて各リソースグループのクォータを設定できます。クラスタのリソースが制限されている場合、同じリソースグループ内のセッションが使用するすべてのリソースはクォータに制限されます。このようにして、リソースグループが過剰に消費された場合でも、他のリソースグループのセッションには影響しません。 + TiDBは、リソースグループに基づくリソース制御機能を強化しました。この機能により、TiDBクラスターのリソース利用効率とパフォーマンスが大幅に向上します。リソース制御機能の導入は、TiDBにとって画期的な出来事です。分散データベースクラスターを複数の論理ユニットに分割し、異なるデータベースユーザーを対応するリソースグループにマッピングし、必要に応じて各リソースグループのクォータを設定できます。クラスターのリソースが制限されている場合、同じリソースグループ内のセッションが使用するすべてのリソースはクォータに制限されます。このようにして、リソースグループが過剰に消費された場合でも、他のリソースグループのセッションには影響しません。 - この機能により、異なるシステム上の複数の中小規模アプリケーションを単一のTiDBクラスタに統合できます。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作には影響しません。システムワークロードが低い場合は、負荷の高いアプリケーションが設定されたクォータを超えても、必要なシステムリソースを割り当てられるため、リソースを最大限に活用できます。さらに、リソース制御機能を合理的に活用することで、クラスタ数を削減し、運用保守の負担を軽減し、管理コストを削減できます。 + この機能により、異なるシステム上の複数の中小規模アプリケーションを単一のTiDBクラスターに統合できます。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作には影響しません。システムワークロードが低い場合は、負荷の高いアプリケーションが設定されたクォータを超えても、必要なシステムリソースを割り当てられるため、リソースを最大限に活用できます。さらに、リソース制御機能を合理的に活用することで、クラスター数を削減し、運用保守の負担を軽減し、管理コストを削減できます。 - この機能は、Grafanaにおけるリソースの実際の使用状況を表示する組み込みのリソース制御ダッシュボードを提供し、リソースをより合理的に割り当てるのに役立ちます。また、セッションレベルとステートメントレベルの両方に基づいた動的なリソース管理機能もサポートしています（ヒント）。この機能の導入により、TiDBクラスタのリソース使用状況をより正確に制御し、実際のニーズに基づいてクォータを動的に調整できるようになります。 + この機能は、Grafanaにおけるリソースの実際の使用状況を表示する組み込みのリソース制御ダッシュボードを提供し、リソースをより合理的に割り当てるのに役立ちます。また、セッションレベルとステートメントレベルの両方に基づいた動的なリソース管理機能もサポートしています（ヒント）。この機能の導入により、TiDBクラスターのリソース使用状況をより正確に制御し、実際のニーズに基づいてクォータを動的に調整できるようになります。 TiDB v7.0.0では、リソースグループの絶対スケジューリング優先度（ `PRIORITY` ）を設定することで、重要なサービスが確実にリソースを取得できるようになります。また、リソースグループの設定方法も拡張されています。 @@ -129,7 +129,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - 統計情報の収集効率を向上させる [#41930](https://github.com/pingcap/tidb/issues/41930) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) - バージョン7.0.0では、TiDBは統計情報の収集ロジックをさらに最適化し、収集時間を約25%短縮しました。この最適化により、大規模データベースクラスタの運用効率と安定性が向上し、統計情報の収集がクラスタのパフォーマンスに与える影響が軽減されます。 + バージョン7.0.0では、TiDBは統計情報の収集ロジックをさらに最適化し、収集時間を約25%短縮しました。この最適化により、大規模データベースクラスターの運用効率と安定性が向上し、統計情報の収集がクラスターのパフォーマンスに与える影響が軽減されます。 - MPP 最適化のための新しいオプティマイザー ヒントを追加 [#39710](https://github.com/pingcap/tidb/issues/39710) @[Reminiscent](https://github.com/Reminiscent) @@ -148,7 +148,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone バージョン7.0.0では、オプティマイザヒント[`LEADING()`](/optimizer-hints.md#leadingt1_name--tl_name-)結合方法に影響を与えるヒントと併用できるようになり、両者の動作は互換性があります。複数テーブル結合の場合、最適な結合方法と結合順序を効果的に指定できるため、実行プランに対するオプティマイザヒントの制御が強化されます。 - 新しいヒント動作には、若干の変更があります。前方互換性を確保するため、TiDB はシステム変数[`tidb_opt_advanced_join_hint`](/system-variables.md#tidb_opt_advanced_join_hint-new-in-v700)を導入します。この変数が`OFF`に設定されている場合、オプティマイザのヒント動作は以前のバージョンと互換性があります。クラスタを以前のバージョンから v7.0.0 以降のバージョンにアップグレードすると、この変数は`OFF`に設定されます。より柔軟なヒント動作を実現するには、動作によってパフォーマンスが低下しないことを確認した後、この変数を`ON`に設定することを強くお勧めします。 + 新しいヒント動作には、若干の変更があります。前方互換性を確保するため、TiDB はシステム変数[`tidb_opt_advanced_join_hint`](/system-variables.md#tidb_opt_advanced_join_hint-new-in-v700)を導入します。この変数が`OFF`に設定されている場合、オプティマイザのヒント動作は以前のバージョンと互換性があります。クラスターを以前のバージョンから v7.0.0 以降のバージョンにアップグレードすると、この変数は`OFF`に設定されます。より柔軟なヒント動作を実現するには、動作によってパフォーマンスが低下しないことを確認した後、この変数を`ON`に設定することを強くお勧めします。 詳細については、[ドキュメント](/optimizer-hints.md)を参照してください。 @@ -164,7 +164,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - Time to Live (TTL) は一般に利用可能です [#39262](https://github.com/pingcap/tidb/issues/39262) @[lcwangchao](https://github.com/lcwangchao) @[YangKeao](https://github.com/YangKeao) - TTLは行レベルのライフサイクル制御ポリシーを提供します。TiDBでは、TTL属性が設定されたテーブルは、設定に基づいて期限切れの行データを自動的にチェックして削除します。TTLの目的は、クラスタのワークロードへの影響を最小限に抑えながら、ユーザーが不要なデータを定期的に適切なタイミングでクリーンアップできるようにすることです。 + TTLは行レベルのライフサイクル制御ポリシーを提供します。TiDBでは、TTL属性が設定されたテーブルは、設定に基づいて期限切れの行データを自動的にチェックして削除します。TTLの目的は、クラスターのワークロードへの影響を最小限に抑えながら、ユーザーが不要なデータを定期的に適切なタイミングでクリーンアップできるようにすることです。 詳細については、[ドキュメント](/time-to-live.md)を参照してください。 @@ -182,15 +182,15 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone ### データベース操作 {#db-operations} -- TiCDC はstorageサービスへの変更データのレプリケーションをサポート (GA) [#6797](https://github.com/pingcap/tiflow/issues/6797) @[zhaoxinyu](https://github.com/zhaoxinyu) +- TiCDC はストレージサービスへの変更データのレプリケーションをサポート (GA) [#6797](https://github.com/pingcap/tiflow/issues/6797) @[zhaoxinyu](https://github.com/zhaoxinyu) - TiCDCは、変更されたデータをAmazon S3、GCS、Azure Blob Storage、NFS、およびその他のS3互換storageサービスに複製することをサポートしています。ストレージサービスは手頃な価格で使いやすく、Kafkaを使用していない場合は、storageサービスを利用できます。TiCDCは変更ログをファイルに保存し、それをstorageサービスに送信します。storageサービスから、独自のコンシューマープログラムが新しく生成された変更ログファイルを定期的に読み取ることができます。現在、TiCDCはcanal-jsonおよびCSV形式の変更ログをstorageサービスに複製することをサポートしています。 + TiCDCは、変更されたデータをAmazon S3、GCS、Azure Blob Storage、NFS、およびその他のS3互換ストレージサービスに複製することをサポートしています。ストレージサービスは手頃な価格で使いやすく、Kafkaを使用していない場合は、ストレージサービスを利用できます。TiCDCは変更ログをファイルに保存し、それをストレージサービスに送信します。ストレージサービスから、独自のコンシューマープログラムが新しく生成された変更ログファイルを定期的に読み取ることができます。現在、TiCDCはcanal-jsonおよびCSV形式の変更ログをストレージサービスに複製することをサポートしています。 - 詳細については、[ドキュメント](/ticdc/ticdc-sink-to-cloud-storage.md)を参照してください。 + 詳細については、[ドキュメント](/ticdc/ticdc-sink-to-cloud-ストレージ.md)を参照してください。 - TiCDC OpenAPI v2 [#8019](https://github.com/pingcap/tiflow/issues/8019) @[sdojjy](https://github.com/sdojjy) - TiCDCはOpenAPI v2を提供します。OpenAPI v1と比較して、OpenAPI v2はレプリケーションタスクをより包括的にサポートします。TiCDC OpenAPIが提供する機能は、 [`cdc cli`ツール](/ticdc/ticdc-manage-changefeed.md)の機能の一部です。OpenAPI v2を介してTiCDCクラスタを照会および操作できます。例えば、TiCDCノードの状態取得、クラスタの健全性状態の確認、レプリケーションタスクの管理などが可能です。 + TiCDCはOpenAPI v2を提供します。OpenAPI v1と比較して、OpenAPI v2はレプリケーションタスクをより包括的にサポートします。TiCDC OpenAPIが提供する機能は、 [`cdc cli`ツール](/ticdc/ticdc-manage-changefeed.md)の機能の一部です。OpenAPI v2を介してTiCDCクラスターを照会および操作できます。例えば、TiCDCノードの状態取得、クラスターの健全性状態の確認、レプリケーションタスクの管理などが可能です。 詳細については、[ドキュメント](/ticdc/ticdc-open-api-v2.md)を参照してください。 @@ -207,9 +207,9 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone ### データ移行 {#data-migration} -- `LOAD DATA`ステートメントの機能を強化し、クラウドstorageからのデータインポートをサポートする (実験的) [#40499](https://github.com/pingcap/tidb/issues/40499) @[lance6716](https://github.com/lance6716) +- `LOAD DATA`ステートメントの機能を強化し、クラウドストレージからのデータインポートをサポートする (実験的) [#40499](https://github.com/pingcap/tidb/issues/40499) @[lance6716](https://github.com/lance6716) - TiDB v7.0.0 より前は、 `LOAD DATA`ステートメントではクライアント側からのデータ ファイルのインポートしかできませんでした。クラウドstorageからデータをインポートするには、 TiDB Lightningを使用する必要がありました。しかし、 TiDB Lightning を別途デプロイすると、追加のデプロイおよび管理コストが発生します。v7.0.0 では、 `LOAD DATA`ステートメントを使用してクラウドstorageから直接データをインポートできます。この機能の例を以下に示します。 + TiDB v7.0.0 より前は、 `LOAD DATA`ステートメントではクライアント側からのデータ ファイルのインポートしかできませんでした。クラウドストレージからデータをインポートするには、 TiDB Lightningを使用する必要がありました。しかし、 TiDB Lightning を別途デプロイすると、追加のデプロイおよび管理コストが発生します。v7.0.0 では、 `LOAD DATA`ステートメントを使用してクラウドストレージから直接データをインポートできます。この機能の例を以下に示します。 - Amazon S3およびGoogle Cloud StorageからTiDBへのデータインポートをサポートします。ワイルドカードを使用して、複数のソースファイルを一度にTiDBにインポートすることをサポートします。 - `DEFINED NULL BY`を使用して null を定義することをサポートします。 @@ -235,7 +235,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - TiDBは、自動インクリメント列がインデックスでなければならないという制約を削除します [#40580](https://github.com/pingcap/tidb/issues/40580) @[tiancaiamao](https://github.com/tiancaiamao) - バージョン 7.0.0 より前は、TiDB の動作は MySQL と一貫しており、自動インクリメント列はインデックスまたはインデックスプレフィックスである必要がありました。バージョン 7.0.0 以降、TiDB は自動インクリメント列がインデックスまたはインデックスプレフィックスである必要があるという制約を撤廃しました。これにより、テーブルの主キーをより柔軟に定義し、自動インクリメント列を使用してソートやページネーションをより簡単に実装できるようになりました。また、自動インクリメント列によって引き起こされる書き込みホットスポットの問題も回避され、クラスタ化インデックスを持つテーブルを使用することでクエリのパフォーマンスが向上します。新しいリリースでは、次の構文を使用してテーブルを作成できます。 + バージョン 7.0.0 より前は、TiDB の動作は MySQL と一貫しており、自動インクリメント列はインデックスまたはインデックスプレフィックスである必要がありました。バージョン 7.0.0 以降、TiDB は自動インクリメント列がインデックスまたはインデックスプレフィックスである必要があるという制約を撤廃しました。これにより、テーブルの主キーをより柔軟に定義し、自動インクリメント列を使用してソートやページネーションをより簡単に実装できるようになりました。また、自動インクリメント列によって引き起こされる書き込みホットスポットの問題も回避され、クラスター化インデックスを持つテーブルを使用することでクエリのパフォーマンスが向上します。新しいリリースでは、次の構文を使用してテーブルを作成できます。 ```sql CREATE TABLE test1 ( @@ -293,19 +293,19 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone | [`tidb_opt_derive_topn`](/system-variables.md#tidb_opt_derive_topn-new-in-v700) | 新しく追加された | この変数は[ウィンドウ関数からTopNまたはLimitを導出する](/derive-topn-from-window.md)最適化ルールを有効にするかどうかを制御します。デフォルト値は`OFF`で、最適化ルールが有効になっていないことを意味します。 | | [`tidb_opt_enable_late_materialization`](/system-variables.md#tidb_opt_enable_late_materialization-new-in-v700) | 新しく追加された | この変数は[TiFlashの遅延発生](/tiflash/tiflash-late-materialization.md)機能を有効にするかどうかを制御します。デフォルト値は`OFF`で、これは機能が有効になっていないことを意味します。 | | [`tidb_opt_ordering_index_selectivity_threshold`](/system-variables.md#tidb_opt_ordering_index_selectivity_threshold-new-in-v700) | 新しく追加された | この変数は、SQL ステートメントに`ORDER BY`および`LIMIT`句が含まれ、フィルタリング条件がある場合に、オプティマイザがインデックスを選択する方法を制御します。 | -| [`tidb_pessimistic_txn_fair_locking`](/system-variables.md#tidb_pessimistic_txn_fair_locking-new-in-v700) | 新しく追加された | 単一行競合シナリオにおけるトランザクションのテールレイテンシーを削減するために、拡張悲観的ロックウェイクモデルを有効にするかどうかを制御します。デフォルト値は`ON`です。クラスタが以前のバージョンから v7.0.0 以降にアップグレードされると、この変数の値は`OFF`に設定されます。 | +| [`tidb_pessimistic_txn_fair_locking`](/system-variables.md#tidb_pessimistic_txn_fair_locking-new-in-v700) | 新しく追加された | 単一行競合シナリオにおけるトランザクションのテールレイテンシーを削減するために、拡張悲観的ロックウェイクモデルを有効にするかどうかを制御します。デフォルト値は`ON`です。クラスターが以前のバージョンから v7.0.0 以降にアップグレードされると、この変数の値は`OFF`に設定されます。 | | [`tidb_slow_txn_log_threshold`](/system-variables.md#tidb_slow_txn_log_threshold-new-in-v700) | 新しく追加された | トランザクションのログ記録のしきい値を設定します。トランザクションの実行時間がこのしきい値を超えると、TiDB はトランザクションに関する詳細情報をログに記録します。デフォルト値`0`は、この機能が無効になっていることを意味します。 | -| [`tidb_ttl_running_tasks`](/system-variables.md#tidb_ttl_running_tasks-new-in-v700) | 新しく追加された | この変数は、クラスタ全体におけるTTLタスクの同時実行数を制限するために使用されます。デフォルト値`-1`は、TTLタスクの数がTiKVノードの数と同じであることを意味します。 | +| [`tidb_ttl_running_tasks`](/system-variables.md#tidb_ttl_running_tasks-new-in-v700) | 新しく追加された | この変数は、クラスター全体におけるTTLタスクの同時実行数を制限するために使用されます。デフォルト値`-1`は、TTLタスクの数がTiKVノードの数と同じであることを意味します。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイル | 設定パラメータ | 種類を変更する | 説明 | | -------------- | ---------------------------------------------------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| ティクヴ | `server.snap-max-write-bytes-per-sec` | 削除済み | このパラメータは[`server.snap-io-max-bytes-per-sec`](/tikv-configuration-file.md#snap-io-max-bytes-per-sec)に名前が変更されました。 | -| ティクヴ | [`raft-engine.enable-log-recycle`](/tikv-configuration-file.md#enable-log-recycle-new-in-v630) | 修正済み | デフォルト値が`false`から`true`に変更されます。 | -| ティクヴ | [`resolved-ts.advance-ts-interval`](/tikv-configuration-file.md#advance-ts-interval) | 修正済み | デフォルト値が`"1s"`から`"20s"`に変更されます。この変更により、Resolved TSの定期的な更新間隔が長くなり、TiKVノード間のトラフィック消費量が削減されます。 | -| ティクヴ | [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) | 修正済み | デフォルト値が`false`から`true`に変更されます。 | -| ティクヴ | [`raft-engine.prefill-for-recycle`](/tikv-configuration-file.md#prefill-for-recycle-new-in-v700) | 新しく追加された | Raft Engineのログリサイクル用に空のログファイルを生成するかどうかを制御します。デフォルト値は`false`です。 | +| TiKV | `server.snap-max-write-bytes-per-sec` | 削除済み | このパラメータは[`server.snap-io-max-bytes-per-sec`](/tikv-configuration-file.md#snap-io-max-bytes-per-sec)に名前が変更されました。 | +| TiKV | [`raft-engine.enable-log-recycle`](/tikv-configuration-file.md#enable-log-recycle-new-in-v630) | 修正済み | デフォルト値が`false`から`true`に変更されます。 | +| TiKV | [`resolved-ts.advance-ts-interval`](/tikv-configuration-file.md#advance-ts-interval) | 修正済み | デフォルト値が`"1s"`から`"20s"`に変更されます。この変更により、Resolved TSの定期的な更新間隔が長くなり、TiKVノード間のトラフィック消費量が削減されます。 | +| TiKV | [`resource-control.enabled`](/tikv-configuration-file.md#resource-control) | 修正済み | デフォルト値が`false`から`true`に変更されます。 | +| TiKV | [`raft-engine.prefill-for-recycle`](/tikv-configuration-file.md#prefill-for-recycle-new-in-v700) | 新しく追加された | Raft Engineのログリサイクル用に空のログファイルを生成するかどうかを制御します。デフォルト値は`false`です。 | | PD | [`degraded-mode-wait-duration`](/pd-configuration-file.md#degraded-mode-wait-duration) | 新しく追加された | [リソース制御](/tidb-resource-control-ru-groups.md)関連する設定項目です。劣化モードをトリガーするまでの待機時間を制御します。デフォルト値は`0s`です。 | | PD | [`read-base-cost`](/pd-configuration-file.md#read-base-cost) | 新しく追加された | A[リソース制御](/tidb-resource-control-ru-groups.md)関連する設定項目です。読み取り要求から RU への変換の基準係数を制御します。デフォルト値は`0.25`です。 | | PD | [`read-cost-per-byte`](/pd-configuration-file.md#read-cost-per-byte) | 新しく追加された | A[リソース制御](/tidb-resource-control-ru-groups.md)関連する設定項目です。読み取りフローからRUへの変換の基準係数を制御します。デフォルト値は`1/ (64 * 1024)`です。 | @@ -315,13 +315,13 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone | TiFlash | [`mark_cache_size`](/tiflash/tiflash-configuration.md) | 修正済み | TiFlashのデータブロックのメタデータのデフォルトのキャッシュ制限を`5368709120`から`1073741824`に変更して、不要なメモリ使用量を削減します。 | | TiFlash | [`minmax_index_cache_size`](/tiflash/tiflash-configuration.md) | 修正済み | TiFlashのデータブロックの最小-最大インデックスのデフォルトのキャッシュ制限を`5368709120`から`1073741824`に変更して、不要なメモリ使用量を削減します。 | | TiFlash | [`flash.disaggregated_mode`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | TiFlashの分散アーキテクチャでは、このTiFlashノードが書き込みノードか計算ノードかを示します。値は`tiflash_write`または`tiflash_compute`になります。 | -| TiFlash | [`storage.s3.endpoint`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | S3に接続するためのエンドポイント。 | -| TiFlash | [`storage.s3.bucket`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | TiFlashがすべてのデータを保存するバケット。 | -| TiFlash | [`storage.s3.root`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | S3バケット内のデータstorageのルートディレクトリ。 | -| TiFlash | [`storage.s3.access_key_id`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | `ACCESS_KEY_ID` S3 にアクセスするためのものです。 | -| TiFlash | [`storage.s3.secret_access_key`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | `SECRET_ACCESS_KEY` S3 にアクセスするためのものです。 | -| TiFlash | [`storage.remote.cache.dir`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | TiFlashコンピューティングノードのローカルデータキャッシュディレクトリ。 | -| TiFlash | [`storage.remote.cache.capacity`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | TiFlashコンピューティングノードのローカルデータキャッシュディレクトリのサイズ。 | +| TiFlash | [`ストレージ.s3.endpoint`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | S3に接続するためのエンドポイント。 | +| TiFlash | [`ストレージ.s3.bucket`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | TiFlashがすべてのデータを保存するバケット。 | +| TiFlash | [`ストレージ.s3.root`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | S3バケット内のデータストレージのルートディレクトリ。 | +| TiFlash | [`ストレージ.s3.access_key_id`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | `ACCESS_KEY_ID` S3 にアクセスするためのものです。 | +| TiFlash | [`ストレージ.s3.secret_access_key`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | `SECRET_ACCESS_KEY` S3 にアクセスするためのものです。 | +| TiFlash | [`ストレージ.remote.cache.dir`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | TiFlashコンピューティングノードのローカルデータキャッシュディレクトリ。 | +| TiFlash | [`ストレージ.remote.cache.capacity`](/tiflash/tiflash-disaggregated-and-s3.md) | 新しく追加された | TiFlashコンピューティングノードのローカルデータキャッシュディレクトリのサイズ。 | | TiDB Lightning | [`add-index-by-sql`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) | 新しく追加された | 物理インポートモードでインデックスを追加する際に SQL を使用するかどうかを制御します。デフォルト値は`false`で、これはTiDB Lightning が行データとインデックスデータの両方を KV ペアにエンコードし、それらをまとめて TiKV にインポートすることを意味します。SQL を使用してインデックスを追加する利点は、データのインポートとインデックスのインポートを分離できるため、データを迅速にインポートできることです。データのインポート後にインデックスの作成が失敗した場合でも、データの一貫性は影響を受けません。 | | TiCDC | [`enable-table-across-nodes`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters) | 新しく追加された | リージョン数に応じて、テーブルを複数の同期範囲に分割するかどうかを決定します。これらの範囲は、複数のTiCDCノードによって複製できます。 | | TiCDC | [`region-threshold`](/ticdc/ticdc-changefeed-config.md#changefeed-configuration-parameters) | 新しく追加された | `enable-table-across-nodes`が有効になっている場合、この機能は`region-threshold`を超えるリージョンを持つテーブルでのみ有効になります。 | @@ -355,7 +355,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone - TiCDC - - Kafkaがダウンストリームとなるシナリオにおいて、単一の大規模テーブルのデータ変更を複数のTiCDCノードに分散することをサポートし、大規模TiDBクラスタのデータ統合シナリオにおける単一テーブルのスケーラビリティ問題を解決します [#8247](https://github.com/pingcap/tiflow/issues/8247) @[overvenus](https://github.com/overvenus) + - Kafkaがダウンストリームとなるシナリオにおいて、単一の大規模テーブルのデータ変更を複数のTiCDCノードに分散することをサポートし、大規模TiDBクラスターのデータ統合シナリオにおける単一テーブルのスケーラビリティ問題を解決します [#8247](https://github.com/pingcap/tiflow/issues/8247) @[overvenus](https://github.com/overvenus) TiCDC 構成項目`enable_table_across_nodes`を`true`に設定することで、この機能を有効にできます。 `region_threshold`を使用すると、テーブルのリージョン数がこのしきい値を超えた場合に、TiCDC が対応するテーブルのデータ変更を複数の TiCDC ノードに分散するように指定できます。 @@ -379,7 +379,7 @@ TiDB バージョン: 7.0.0- [DMR](/releases/versioning.md#development-milestone `add-index-by-sql`パラメータを追加します。デフォルト値は`false`で、これはTiDB Lightning が行データとインデックスデータの両方を KV ペアにエンコードし、それらをまとめて TiKV にインポートすることを意味します。これを`true`に設定すると、 TiDB Lightningデータのインポート後に`ADD INDEX` SQL ステートメントを使用してインデックスを追加し、インポートの速度と安定性を向上させます。 - - `tikv-importer.keyspace-name`パラメータを追加します。デフォルト値は空の文字列で、 TiDB Lightning は対応するテナントのキースペース名を自動的に取得してデータをインポートします。値を指定すると、指定されたキースペース名を使用してデータがインポートされます。このパラメータにより、マルチテナント TiDB クラスタにデータをインポートする際のTiDB Lightningの設定に柔軟性が生まれます。 [#41915](https://github.com/pingcap/tidb/issues/41915) @[lichunzhu](https://github.com/lichunzhu) + - `tikv-importer.keyspace-name`パラメータを追加します。デフォルト値は空の文字列で、 TiDB Lightning は対応するテナントのキースペース名を自動的に取得してデータをインポートします。値を指定すると、指定されたキースペース名を使用してデータがインポートされます。このパラメータにより、マルチテナント TiDB クラスターにデータをインポートする際のTiDB Lightningの設定に柔軟性が生まれます。 [#41915](https://github.com/pingcap/tidb/issues/41915) @[lichunzhu](https://github.com/lichunzhu) ## バグ修正 {#bug-fixes} diff --git a/releases/release-7.1.0.md b/releases/release-7.1.0.md index 20fd65939169b..282bc0c47c892 100644 --- a/releases/release-7.1.0.md +++ b/releases/release-7.1.0.md @@ -15,19 +15,19 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 以前の LTS 6.5.0 と比較して、7.1.0 には、 [6.6.0-DMR](/releases/release-6.6.0.md) 、 [7.0.0-DMR](/releases/release-7.0.0.md)でリリースされた新機能、改善、バグ修正が含まれているだけでなく、次の主要な機能と改善も導入されています。 -
カテゴリ特徴説明
スケーラビリティとパフォーマンスTiFlash は、分散storageとコンピューティングアーキテクチャ、および S3 共有storage(実験的、v7.0.0 で導入) をサポートします。 TiFlash は、オプションとしてクラウドネイティブアーキテクチャを導入します。
  • TiFlash のコンピューティングとstorageを分離します。これは、弾力的な HTAP リソース利用のマイルストーンとなります。
  • 低コストで共有storageを提供できる S3 ベースのstorageエンジンを導入します。
TiKV はバッチ集約データ要求をサポートします (v6.6.0 で導入)この機能強化により、TiKVバッチゲット操作におけるRPCの総数が大幅に削減されます。データが広範囲に分散し、gRPCスレッドプールのリソースが不足している状況では、コプロセッサリクエストをバッチ処理することでパフォーマンスを50%以上向上させることができます。
負荷ベースのレプリカ読み取り読み取りホットスポットのシナリオでは、TiDBはホットスポットTiKVノードへの読み取り要求をそのレプリカにリダイレクトできます。この機能により、読み取りホットスポットが効率的に分散され、クラスタリソースの利用が最適化されます。負荷ベースのレプリカ読み取りをトリガーするしきい値を制御するには、システム変数tidb_load_based_replica_read_thresholdを調整します。
TiKV はパーティション化されたRaft KVstorageエンジンをサポートします (実験的) TiKVは、新世代のstorageエンジンであるパー​​ティション型Raft KVを導入します。各データリージョンに専用のRocksDBインスタンスを割り当てることで、クラスターのstorage容量をテラバイトレベルからペタバイトレベルに拡張し、より安定した書き込みレイテンシーと強力なスケーラビリティを実現します。
信頼性と可用性リソースグループによるリソース制御（GA）リソースグループに基づくリソース管理をサポートします。これにより、同一クラスター内の異なるワークロードにリソースを割り当て、分離することができます。この機能は、マルチアプリケーション・クラスターの安定性を大幅に向上させ、マルチテナンシーの基盤を構築します。v7.1.0では、この機能により、実際のワークロードまたはハードウェア構成に基づいてシステム容量を見積もる機能が導入されました。
TiFlash はディスクへの書き込みをサポートします (v7.0.0 で導入) TiFlash は、集計、ソート、ハッシュ結合などのデータ集約型操作における OOM を軽減するために、ディスクへの中間結果のスピルをサポートします。
SQL 多値インデックス（GA） MySQL互換の多値インデックスをサポートし、JSON型を拡張することでMySQL 8.0との互換性を向上させました。この機能により、多値列のメンバーシップチェックの効率が向上します。
行レベルの TTL (v7.0.0 で GA)一定の期間を経過したデータを自動的に期限切れにすることで、データベース サイズの管理をサポートし、パフォーマンスを向上します。
生成された列（GA）生成された列の値は、列定義内のSQL式によってリアルタイムで計算されます。この機能により、一部のアプリケーションロジックがデータベースレベルにプッシュされ、クエリの効率が向上します。
SecurityLDAP認証TiDB は、 MySQL 8.0と互換性のある LDAP 認証をサポートしています。
監査ログの強化（エンタープライズ エディションのみ） TiDB Enterprise Editionは、データベース監査機能を強化しました。よりきめ細かなイベントフィルタリング制御、よりユーザーフレンドリーなフィルタ設定、JSON形式の新しいファイル出力形式、監査ログのライフサイクル管理を提供することで、システム監査能力を大幅に向上させます。
+
カテゴリ特徴説明
スケーラビリティとパフォーマンスTiFlash は、分散ストレージとコンピューティングアーキテクチャ、および S3 共有ストレージ(実験的、v7.0.0 で導入) をサポートします。 TiFlash は、オプションとしてクラウドネイティブアーキテクチャを導入します。
  • TiFlash のコンピューティングとストレージを分離します。これは、弾力的な HTAP リソース利用のマイルストーンとなります。
  • 低コストで共有ストレージを提供できる S3 ベースのストレージエンジンを導入します。
TiKV はバッチ集約データ要求をサポートします (v6.6.0 で導入)この機能強化により、TiKVバッチゲット操作におけるRPCの総数が大幅に削減されます。データが広範囲に分散し、gRPCスレッドプールのリソースが不足している状況では、コプロセッサリクエストをバッチ処理することでパフォーマンスを50%以上向上させることができます。
負荷ベースのレプリカ読み取り読み取りホットスポットのシナリオでは、TiDBはホットスポットTiKVノードへの読み取り要求をそのレプリカにリダイレクトできます。この機能により、読み取りホットスポットが効率的に分散され、クラスターリソースの利用が最適化されます。負荷ベースのレプリカ読み取りをトリガーするしきい値を制御するには、システム変数tidb_load_based_replica_read_thresholdを調整します。
TiKV はパーティション化されたRaft KVストレージエンジンをサポートします (実験的) TiKVは、新世代のストレージエンジンであるパー​​ティション型Raft KVを導入します。各データリージョンに専用のRocksDBインスタンスを割り当てることで、クラスターのストレージ容量をテラバイトレベルからペタバイトレベルに拡張し、より安定した書き込みレイテンシーと強力なスケーラビリティを実現します。
信頼性と可用性リソースグループによるリソース制御（GA）リソースグループに基づくリソース管理をサポートします。これにより、同一クラスター内の異なるワークロードにリソースを割り当て、分離することができます。この機能は、マルチアプリケーション・クラスターの安定性を大幅に向上させ、マルチテナンシーの基盤を構築します。v7.1.0では、この機能により、実際のワークロードまたはハードウェア構成に基づいてシステム容量を見積もる機能が導入されました。
TiFlash はディスクへの書き込みをサポートします (v7.0.0 で導入) TiFlash は、集計、ソート、ハッシュ結合などのデータ集約型操作における OOM を軽減するために、ディスクへの中間結果のスピルをサポートします。
SQL 多値インデックス（GA） MySQL互換の多値インデックスをサポートし、JSON型を拡張することでMySQL 8.0との互換性を向上させました。この機能により、多値列のメンバーシップチェックの効率が向上します。
行レベルの TTL (v7.0.0 で GA)一定の期間を経過したデータを自動的に期限切れにすることで、データベース サイズの管理をサポートし、パフォーマンスを向上します。
生成された列（GA）生成された列の値は、列定義内のSQL式によってリアルタイムで計算されます。この機能により、一部のアプリケーションロジックがデータベースレベルにプッシュされ、クエリの効率が向上します。
SecurityLDAP認証TiDB は、 MySQL 8.0と互換性のある LDAP 認証をサポートしています。
監査ログの強化（エンタープライズ エディションのみ） TiDB Enterprise Editionは、データベース監査機能を強化しました。よりきめ細かなイベントフィルタリング制御、よりユーザーフレンドリーなフィルタ設定、JSON形式の新しいファイル出力形式、監査ログのライフサイクル管理を提供することで、システム監査能力を大幅に向上させます。
## 機能の詳細 {#feature-details} ### パフォーマンス {#performance} -- パーティション化されたRaft KVstorageエンジンの強化 (実験的) [＃11515](https://github.com/tikv/tikv/issues/11515) [＃12842](https://github.com/tikv/tikv/issues/12842) @ [busyjay](https://github.com/busyjay) @ [tonyxuqqi](https://github.com/tonyxuqqi) @ [tabokie](https://github.com/tabokie) @ [bufferflies](https://github.com/bufferflies) @ [5kbpers](https://github.com/5kbpers) @ [SpadeA-Tang](https://github.com/SpadeA-Tang) @ [nolouch](https://github.com/nolouch) +- パーティション化されたRaft KVストレージエンジンの強化 (実験的) [＃11515](https://github.com/tikv/tikv/issues/11515) [＃12842](https://github.com/tikv/tikv/issues/12842) @ [busyjay](https://github.com/busyjay) @ [tonyxuqqi](https://github.com/tonyxuqqi) @ [tabokie](https://github.com/tabokie) @ [bufferflies](https://github.com/bufferflies) @ [5kbpers](https://github.com/5kbpers) @ [SpadeA-Tang](https://github.com/SpadeA-Tang) @ [nolouch](https://github.com/nolouch) - TiDB v6.6.0では、実験的機能としてPartitioned Raft KVstorageエンジンが導入されました。このストレージエンジンは、複数のRocksDBインスタンスを使用してTiKVリージョンデータを保存し、各リージョンのデータは独立したRocksDBインスタンスに独立して保存されます。この新しいstorageエンジンは、RocksDBインスタンス内のファイルの数とレベルをより適切に制御し、リージョン間のデータ操作の物理的な分離を実現し、より多くのデータの安定した管理をサポートします。従来のTiKVstorageエンジンと比較して、Partitioned Raft KVstorageエンジンを使用すると、同じハードウェア条件で読み取りと書き込みが混在するシナリオにおいて、書き込みスループットが約2倍になり、エラスティックスケーリング時間が約4/5短縮されます。 + TiDB v6.6.0では、実験的機能としてPartitioned Raft KVストレージエンジンが導入されました。このストレージエンジンは、複数のRocksDBインスタンスを使用してTiKVリージョンデータを保存し、各リージョンのデータは独立したRocksDBインスタンスに独立して保存されます。この新しいストレージエンジンは、RocksDBインスタンス内のファイルの数とレベルをより適切に制御し、リージョン間のデータ操作の物理的な分離を実現し、より多くのデータの安定した管理をサポートします。従来のTiKVストレージエンジンと比較して、Partitioned Raft KVストレージエンジンを使用すると、同じハードウェア条件で読み取りと書き込みが混在するシナリオにおいて、書き込みスループットが約2倍になり、エラスティックスケーリング時間が約4/5短縮されます。 - TiDB v7.1.0 では、Partitioned Raft KVstorageエンジンがTiDB Lightning、 BR、TiCDC などのツールをサポートしています。 + TiDB v7.1.0 では、Partitioned Raft KVストレージエンジンがTiDB Lightning、 BR、TiCDC などのツールをサポートしています。 - 現在、この機能は実験的であり、本番環境での使用は推奨されません。このエンジンは新規に作成されたクラスターでのみ使用でき、元のTiKVstorageエンジンから直接アップグレードすることはできません。 + 現在、この機能は実験的であり、本番環境での使用は推奨されません。このエンジンは新規に作成されたクラスターでのみ使用でき、元のTiKVストレージエンジンから直接アップグレードすることはできません。 詳細については[ドキュメント](/partitioned-raft-kv.md)参照してください。 @@ -83,7 +83,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 TiDBは、リソースグループに基づくリソース制御機能を強化し、v7.1.0でGAとなりました。この機能により、TiDBクラスターのリソース利用効率とパフォーマンスが大幅に向上します。リソース制御機能の導入は、TiDBにとって画期的な出来事です。分散データベースクラスターを複数の論理ユニットに分割し、異なるデータベースユーザーを対応するリソースグループにマッピングし、必要に応じて各リソースグループのクォータを設定できます。クラスターリソースが制限されている場合、同じリソースグループ内のセッションで使用されるすべてのリソースはクォータに制限されます。これにより、あるリソースグループが過剰に消費されても、他のリソースグループのセッションには影響がありません。 - この機能により、異なるシステムの複数の中小規模アプリケーションを単一のTiDBクラスタに統合できます。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作に影響を与えることはありません。システムのワークロードが低い場合は、設定されたクォータを超えても、高負荷のアプリケーションに必要なシステムリソースを割り当てることができるため、リソースを最大限に活用できます。さらに、リソース制御機能を合理的に活用することで、クラスタ数を削減し、運用・保守の難易度を軽減し、管理コストを削減できます。 + この機能により、異なるシステムの複数の中小規模アプリケーションを単一のTiDBクラスターに統合できます。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作に影響を与えることはありません。システムのワークロードが低い場合は、設定されたクォータを超えても、高負荷のアプリケーションに必要なシステムリソースを割り当てることができるため、リソースを最大限に活用できます。さらに、リソース制御機能を合理的に活用することで、クラスター数を削減し、運用・保守の難易度を軽減し、管理コストを削減できます。 TiDB v7.1.0では、実際のワークロードやハードウェア構成に基づいてシステム容量を見積もる機能が導入されました。この見積機能は、キャパシティプランニングのためのより正確な基準を提供し、エンタープライズレベルのシナリオにおける安定性のニーズを満たすためにTiDBのリソース割り当てをより適切に管理するのに役立ちます。 @@ -176,7 +176,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 ### DB操作 {#db-operations} -- DDL 操作を手動でキャンセルせずに、スムーズなクラスタ アップグレードをサポート (実験的) [＃39751](https://github.com/pingcap/tidb/issues/39751) @ [zimulala](https://github.com/zimulala) +- DDL 操作を手動でキャンセルせずに、スムーズなクラスター アップグレードをサポート (実験的) [＃39751](https://github.com/pingcap/tidb/issues/39751) @ [zimulala](https://github.com/zimulala) TiDB v7.1.0 より前のバージョンでは、クラスターをアップグレードするには、アップグレード前に実行中またはキューに入れられた DDL タスクを手動でキャンセルし、アップグレード後に再度追加する必要があります。 @@ -278,9 +278,9 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | [`tidb_prefer_broadcast_join_by_exchange_data_size`](/system-variables.md#tidb_prefer_broadcast_join_by_exchange_data_size-new-in-v710) | 新しく追加された | ネットワーク転送のオーバーヘッドが最小となるアルゴリズムを使用するかどうかを制御します。この変数を有効にすると、TiDBはネットワークで交換されるデータのサイズをそれぞれ`Broadcast Hash Join`と`Shuffled Hash Join`で推定し、サイズが小さい方を選択します。この変数を有効にすると、 [`tidb_broadcast_join_threshold_count`](/system-variables.md#tidb_broadcast_join_threshold_count-new-in-v50)と[`tidb_broadcast_join_threshold_size`](/system-variables.md#tidb_broadcast_join_threshold_size-new-in-v50)無効になります。 | | [`tidb_session_plan_cache_size`](/system-variables.md#tidb_session_plan_cache_size-new-in-v710) | 新しく追加された | キャッシュできるプランの最大数を制御します。準備済みプランのキャッシュと準備されていないプランのキャッシュは同じキャッシュを共有します。 | -### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} +### 設定ファイルのパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | タイプを変更 | 説明 | +| 設定ファイル | 設定パラメータ | タイプを変更 | 説明 | | -------------- | ------------------------------------------------------------------------------------------------------------------------------ | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`performance.force-init-stats`](/tidb-configuration-file.md#force-init-stats-new-in-v657-and-v710) | 新しく追加された | TiDB の起動中にサービスを提供する前に、統計の初期化が完了するまで待機するかどうかを制御します。 | | TiDB | [`performance.lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-new-in-v710) | 新しく追加された | TiDB の起動時に軽量統計初期化を使用するかどうかを制御します。 | @@ -290,7 +290,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | TiKV | [`split.byte-threshold`](/tikv-configuration-file.md#byte-threshold-new-in-v50) | 修正済み | [`region-split-size`](/tikv-configuration-file.md#region-split-size)が 4 GB 以上の場合、デフォルト値を`30MiB`から`100MiB`に変更します。 | | TiKV | [`split.qps-threshold`](/tikv-configuration-file.md#qps-threshold) | 修正済み | [`region-split-size`](/tikv-configuration-file.md#region-split-size)が 4 GB 以上の場合、デフォルト値を`3000`から`7000`に変更します。 | | TiKV | [`split.region-cpu-overload-threshold-ratio`](/tikv-configuration-file.md#region-cpu-overload-threshold-ratio-new-in-v620) | 修正済み | [`region-split-size`](/tikv-configuration-file.md#region-split-size)が 4 GB 以上の場合、デフォルト値を`0.25`から`0.75`に変更します。 | -| TiKV | [`region-compact-check-step`](/tikv-configuration-file.md#region-compact-check-step) | 修正済み | Partitioned Raft KVが有効な場合（ `storage.engine="partitioned-raft-kv"` ）、デフォルト値を`100`から`5`に変更します。 | +| TiKV | [`region-compact-check-step`](/tikv-configuration-file.md#region-compact-check-step) | 修正済み | Partitioned Raft KVが有効な場合（ `ストレージ.engine="partitioned-raft-kv"` ）、デフォルト値を`100`から`5`に変更します。 | | PD | [`store-limit-version`](/pd-configuration-file.md#store-limit-version-new-in-v710) | 新しく追加された | ストア制限のモードを制御します。値のオプションは`"v1"`と`"v2"`です。 | | PD | [`schedule.enable-diagnostic`](/pd-configuration-file.md#enable-diagnostic-new-in-v630) | 修正済み | デフォルト値を`false`から`true`に変更します。これは、スケジューラの診断機能がデフォルトで有効であることを意味します。 | | TiFlash | `http_port` | 削除済み | HTTP サービス ポート (デフォルト`8123` ) を廃止します。 | @@ -302,7 +302,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 | TiCDC | [`integrity.corruption-handle-level`](/ticdc/ticdc-changefeed-config.md#cli-and-configuration-parameters-of-ticdc-changefeeds) | 新しく追加された | 単一行データのチェックサム検証に失敗した場合のChangefeedのログレベルを指定します。デフォルト値は`"warn"`です。値のオプションは`"warn"`と`"error"`です。 | | TiCDC | [`integrity.integrity-check-level`](/ticdc/ticdc-changefeed-config.md#cli-and-configuration-parameters-of-ticdc-changefeeds) | 新しく追加された | 単一行データのチェックサム検証を有効にするかどうかを制御します。デフォルト値は`"none"`で、この機能は無効です。 | | TiCDC | [`sink.only-output-updated-columns`](/ticdc/ticdc-changefeed-config.md#cli-and-configuration-parameters-of-ticdc-changefeeds) | 新しく追加された | 更新された列のみを出力するかどうかを制御します。デフォルト値は`false`です。 | -| TiCDC | [`sink.enable-partition-separator`](/ticdc/ticdc-changefeed-config.md#cli-and-configuration-parameters-of-ticdc-changefeeds) | 修正済み | さらなるテストを経て、デフォルト値を`false`から`true`に変更しました。これは、テーブル内のパーティションがデフォルトで別々のディレクトリに保存されることを意味します。パーティション化されたテーブルをstorageサービスにレプリケーションする際にデータ損失が発生する可能性を回避するため、この値は`true`のままにしておくことをお勧めします。 | +| TiCDC | [`sink.enable-partition-separator`](/ticdc/ticdc-changefeed-config.md#cli-and-configuration-parameters-of-ticdc-changefeeds) | 修正済み | さらなるテストを経て、デフォルト値を`false`から`true`に変更しました。これは、テーブル内のパーティションがデフォルトで別々のディレクトリに保存されることを意味します。パーティション化されたテーブルをストレージサービスにレプリケーションする際にデータ損失が発生する可能性を回避するため、この値は`true`のままにしておくことをお勧めします。 | ## 改善点 {#improvements} @@ -324,12 +324,12 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - PD - スナップショットの実行内容に基づいてストア制限のサイズを自動調整するコントローラを追加します。このコントローラを有効にするには、 `store-limit-version`を`v2` （実験的）に設定してください。有効にすると、スケールインまたはスケールアウトの速度を制御するために`store limit`設定を手動で調整する必要がなくなります（ [＃6147](https://github.com/tikv/pd/issues/6147) @ [bufferflies](https://github.com/bufferflies) 。 - - storageエンジンが raft-kv2 [＃6297](https://github.com/tikv/pd/issues/6297) @ [bufferflies](https://github.com/bufferflies)の場合、ホットスポット スケジューラによって不安定な負荷のリージョンが頻繁にスケジュールされるのを避けるために、履歴負荷情報を追加します。 + - ストレージエンジンが raft-kv2 [＃6297](https://github.com/tikv/pd/issues/6297) @ [bufferflies](https://github.com/bufferflies)の場合、ホットスポット スケジューラによって不安定な負荷のリージョンが頻繁にスケジュールされるのを避けるために、履歴負荷情報を追加します。 - リーダーのヘルスチェックメカニズムを追加します。etcdリーダーが配置されているPDサーバーがリーダーとして選出できない場合、PDはetcdリーダーをアクティブに切り替え、PDリーダーが[＃6403](https://github.com/tikv/pd/issues/6403) @ [nolouch](https://github.com/nolouch)で利用可能であることを確認します。 - TiFlash - - 分散storageおよびコンピューティングアーキテクチャにおけるTiFlash のパフォーマンスと安定性を向上[＃6882](https://github.com/pingcap/tiflash/issues/6882) @ [JaySon-Huang](https://github.com/JaySon-Huang) @ [breezewish](https://github.com/breezewish) @ [JinheLin](https://github.com/JinheLin) + - 分散ストレージおよびコンピューティングアーキテクチャにおけるTiFlash のパフォーマンスと安定性を向上[＃6882](https://github.com/pingcap/tiflash/issues/6882) @ [JaySon-Huang](https://github.com/JaySon-Huang) @ [breezewish](https://github.com/breezewish) @ [JinheLin](https://github.com/JinheLin) - ビルド側[＃7280](https://github.com/pingcap/tiflash/issues/7280) @ [yibin87](https://github.com/yibin87)として小さいテーブルを選択することで、セミ結合またはアンチセミ結合でのクエリパフォーマンスの最適化をサポートします。 - デフォルト設定[＃7272](https://github.com/pingcap/tiflash/issues/7272) @ [breezewish](https://github.com/breezewish)でBRおよびTiDB LightningからTiFlashへのデータインポートのパフォーマンスを向上 @@ -341,7 +341,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - TiCDC - - オブジェクトstorageにデータを複製するシナリオでDDLイベントが発生したときにディレクトリ構造を最適化する[＃8890](https://github.com/pingcap/tiflow/issues/8890) @ [CharlesCheung96](https://github.com/CharlesCheung96) + - オブジェクトストレージにデータを複製するシナリオでDDLイベントが発生したときにディレクトリ構造を最適化する[＃8890](https://github.com/pingcap/tiflow/issues/8890) @ [CharlesCheung96](https://github.com/CharlesCheung96) - TiCDC レプリケーションタスクが失敗したときにアップストリームの GC TLS を設定する方法を最適化します[＃8403](https://github.com/pingcap/tiflow/issues/8403) @ [charleszheng44](https://github.com/charleszheng44) - Kafka-on-Pulsar ダウンストリームへのデータ複製をサポート[＃8892](https://github.com/pingcap/tiflow/issues/8892) @ [Rustin170506](https://github.com/Rustin170506) - Kafka [＃8706](https://github.com/pingcap/tiflow/issues/8706) @ [sdojjy](https://github.com/sdojjy)にデータを複製する際に更新が発生した後に変更された列のみを複製するためのオープンプロトコルプロトコルの使用をサポートします。 @@ -411,7 +411,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - `tidb_pessimistic_txn_fair_locking`有効にすると、極端なケースで、失敗した RPC 再試行によって期限切れになったリクエストが、解決ロック操作[＃14551](https://github.com/tikv/tikv/issues/14551) @ [MyonKeminta](https://github.com/MyonKeminta)中にデータの正確性に影響を与える可能性がある問題を修正しました。 - `tidb_pessimistic_txn_fair_locking`有効にすると、極端なケースで、失敗した RPC 再試行によって期限切れのリクエストが発生し、トランザクションの競合が無視され、トランザクションの一貫性[＃14311](https://github.com/tikv/tikv/issues/14311) @ [MyonKeminta](https://github.com/MyonKeminta)に影響する可能性がある問題を修正しました。 - 暗号化キーIDの競合により古いキー[＃14585](https://github.com/tikv/tikv/issues/14585) @ [tabokie](https://github.com/tabokie)が削除される可能性がある問題を修正しました - - クラスタを以前のバージョンから v6.5 以降のバージョン[＃14780](https://github.com/tikv/tikv/issues/14780) @ [MyonKeminta](https://github.com/MyonKeminta)にアップグレードしたときに、累積したロック レコードによって発生するパフォーマンス低下の問題を修正しました。 + - クラスターを以前のバージョンから v6.5 以降のバージョン[＃14780](https://github.com/tikv/tikv/issues/14780) @ [MyonKeminta](https://github.com/MyonKeminta)にアップグレードしたときに、累積したロック レコードによって発生するパフォーマンス低下の問題を修正しました。 - PITRリカバリプロセス[＃14313](https://github.com/tikv/tikv/issues/14313) @ [YuJuncen](https://github.com/YuJuncen)中に`raft entry is too large`エラーが発生する問題を修正 - PITRリカバリプロセス中に`log_batch` 2GBを超える[＃13848](https://github.com/tikv/tikv/issues/13848) @ [YuJuncen](https://github.com/YuJuncen)によりTiKVがパニックになる問題を修正 @@ -440,7 +440,7 @@ TiDB 7.1.0 は長期サポートリリース (LTS) です。 - TiCDC タイムゾーン設定[＃8798](https://github.com/pingcap/tiflow/issues/8798) @ [Rustin170506](https://github.com/Rustin170506)の問題を修正 - PDアドレスまたはリーダーに障害が発生したときにTiCDCが自動的に回復できない問題を修正[＃8812](https://github.com/pingcap/tiflow/issues/8812) [＃8877](https://github.com/pingcap/tiflow/issues/8877) @ [asddongmen](https://github.com/asddongmen) - 上流の TiKV ノードの 1 つが[＃8858](https://github.com/pingcap/tiflow/issues/8858) @ [hicqu](https://github.com/hicqu)でクラッシュするとチェックポイントの遅延が増加する問題を修正しました - - オブジェクトstorageにデータを複製する際に、上流の`EXCHANGE PARTITION`操作が下流の[＃8914](https://github.com/pingcap/tiflow/issues/8914) @ [CharlesCheung96](https://github.com/CharlesCheung96)に正しく複製されない問題を修正しました。 + - オブジェクトストレージにデータを複製する際に、上流の`EXCHANGE PARTITION`操作が下流の[＃8914](https://github.com/pingcap/tiflow/issues/8914) @ [CharlesCheung96](https://github.com/CharlesCheung96)に正しく複製されない問題を修正しました。 - いくつかの特殊なシナリオでソートコンポーネントの過剰なメモリ使用によって引き起こされる OOM 問題を修正しました[＃8974](https://github.com/pingcap/tiflow/issues/8974) @ [hicqu](https://github.com/hicqu) - 下流の Kafka シンクがローリング再起動されたときに発生する TiCDC ノードpanicを修正しました[＃9023](https://github.com/pingcap/tiflow/issues/9023) @ [asddongmen](https://github.com/asddongmen) diff --git a/releases/release-7.1.1.md b/releases/release-7.1.1.md index adba0f8171bb6..afac3ff4ca908 100644 --- a/releases/release-7.1.1.md +++ b/releases/release-7.1.1.md @@ -26,7 +26,7 @@ TiDB バージョン: 7.1.1 - プランキャッシュは200以上のパラメータを持つクエリをサポートします[＃44823](https://github.com/pingcap/tidb/issues/44823) @ [qw4990](https://github.com/qw4990) - ディスク[＃45125](https://github.com/pingcap/tidb/issues/45125)からダンプされたチャンクを読み込む際のパフォーマンスを最適化します[ヤンケオ](https://github.com/YangKeao) - インデックススキャン範囲を構築するロジックを最適化し、複雑な条件をインデックススキャン範囲[＃41572](https://github.com/pingcap/tidb/issues/41572) [＃44389](https://github.com/pingcap/tidb/issues/44389) @ [xuyifangreeneyes](https://github.com/xuyifangreeneyes)に変換できるようにしました。 - - 古い読み取りの再試行リーダーがロックに遭遇すると、TiDBはロックを解決した後、リーダーで強制的に再試行し、不要なオーバーヘッドを回避します[＃43659](https://github.com/pingcap/tidb/issues/43659) @ [you06](https://github.com/you06) + - ステイル読み取りの再試行リーダーがロックに遭遇すると、TiDBはロックを解決した後、リーダーで強制的に再試行し、不要なオーバーヘッドを回避します[＃43659](https://github.com/pingcap/tidb/issues/43659) @ [you06](https://github.com/you06) - PD @@ -36,7 +36,7 @@ TiDB バージョン: 7.1.1 - TiCDC - - TiCDC がオブジェクトstorageサービス[＃9373](https://github.com/pingcap/tiflow/issues/9373) @ [CharlesCheung96](https://github.com/CharlesCheung96)にデータを複製する際のバイナリ フィールドのエンコード形式を最適化します。 + - TiCDC がオブジェクトストレージサービス[＃9373](https://github.com/pingcap/tiflow/issues/9373) @ [CharlesCheung96](https://github.com/CharlesCheung96)にデータを複製する際のバイナリ フィールドのエンコード形式を最適化します。 - Kafka [＃8865](https://github.com/pingcap/tiflow/issues/8865) @ [Rustin170506](https://github.com/Rustin170506)へのレプリケーションのシナリオでOAUTHBEARER認証をサポート - TiDB Lightning @@ -65,7 +65,7 @@ TiDB バージョン: 7.1.1 - `indexMerge`のクエリが[＃45279](https://github.com/pingcap/tidb/issues/45279) @ [xzhangxian1008](https://github.com/xzhangxian1008)で強制終了されたときに発生するハングアップの問題を修正しました - 統計情報におけるSQL実行詳細のメモリ消費量が多すぎると、極端なケースでTiDB OOMが発生する問題を修正[＃44047](https://github.com/pingcap/tidb/issues/44047) @ [wshwsh12](https://github.com/wshwsh12) - `FormatSQL()`メソッドが入力[＃44542](https://github.com/pingcap/tidb/issues/44542) @ [hawkingrei](https://github.com/hawkingrei)の非常に長い SQL 文を適切に切り捨てることができない問題を修正しました。 - - クラスタのアップグレード中に DDL 操作が停止し、アップグレードが失敗する問題を修正しました[＃44158](https://github.com/pingcap/tidb/issues/44158) @ [zimulala](https://github.com/zimulala) + - クラスターのアップグレード中に DDL 操作が停止し、アップグレードが失敗する問題を修正しました[＃44158](https://github.com/pingcap/tidb/issues/44158) @ [zimulala](https://github.com/zimulala) - 1つのTiDBノード[＃45022](https://github.com/pingcap/tidb/issues/45022) @ [lcwangchao](https://github.com/lcwangchao)で障害が発生した後、他のTiDBノードがTTLタスクを引き継がない問題を修正しました - MySQLカーソルフェッチプロトコル使用時に、結果セットのメモリ消費量が`tidb_mem_quota_query`上限を超え、TiDBのメモリオーバーフローが発生する問題を修正しました。修正後、TiDBは結果セットを自動的にディスクに書き込み、メモリを解放します[＃43233](https://github.com/pingcap/tidb/issues/43233) @ [YangKeao](https://github.com/YangKeao) - 権限[＃45320](https://github.com/pingcap/tidb/issues/45320) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger)がなくてもユーザーが`INFORMATION_SCHEMA.TIFLASH_REPLICA`テーブルの情報を表示できる問題を修正 @@ -107,7 +107,7 @@ TiDB バージョン: 7.1.1 - TiFlash - - 分散storageおよびコンピューティングアーキテクチャモードで、 TiFlashコンピューティングノードが不正確なCPUコア情報[＃7436](https://github.com/pingcap/tiflash/issues/7436) @ [guo-shaoge](https://github.com/guo-shaoge)を取得する問題を修正しました。 + - 分散ストレージおよびコンピューティングアーキテクチャモードで、 TiFlashコンピューティングノードが不正確なCPUコア情報[＃7436](https://github.com/pingcap/tiflash/issues/7436) @ [guo-shaoge](https://github.com/guo-shaoge)を取得する問題を修正しました。 - オンラインアンセーフリカバリ[＃7671](https://github.com/pingcap/tiflash/issues/7671) @ [hongyunyan](https://github.com/hongyunyan)を使用した後、 TiFlashの再起動に時間がかかりすぎる問題を修正しました - ツール @@ -115,19 +115,19 @@ TiDB バージョン: 7.1.1 - バックアップと復元 (BR) - `checksum mismatch`場合によっては誤って報告される問題を修正[＃44472](https://github.com/pingcap/tidb/issues/44472) @ [Leavrth](https://github.com/Leavrth) - - TiDBクラスタ[＃40759](https://github.com/pingcap/tidb/issues/40759) @ [joccau](https://github.com/joccau)にPITRバックアップタスクがない場合に頻度`resolve lock`が高すぎる問題を修正 + - TiDBクラスター[＃40759](https://github.com/pingcap/tidb/issues/40759) @ [joccau](https://github.com/joccau)にPITRバックアップタスクがない場合に頻度`resolve lock`が高すぎる問題を修正 - TiCDC - PD例外によりレプリケーションタスクが停止する可能性がある問題を修正[＃8808](https://github.com/pingcap/tiflow/issues/8808) [＃9054](https://github.com/pingcap/tiflow/issues/9054) @ [asddongmen](https://github.com/asddongmen) @ [fubinzh](https://github.com/fubinzh) - - オブジェクトstorageサービス[＃8894](https://github.com/pingcap/tiflow/issues/8894) @ [CharlesCheung96](https://github.com/CharlesCheung96)へのレプリケーション時に過剰なメモリ消費が発生する問題を修正 + - オブジェクトストレージサービス[＃8894](https://github.com/pingcap/tiflow/issues/8894) @ [CharlesCheung96](https://github.com/CharlesCheung96)へのレプリケーション時に過剰なメモリ消費が発生する問題を修正 - 再実行ログが有効で、下流に例外[＃9172](https://github.com/pingcap/tiflow/issues/9172) @ [CharlesCheung96](https://github.com/CharlesCheung96)がある場合にレプリケーションタスクが停止する可能性がある問題を修正しました。 - 下流で障害が発生した場合に TiCDC が再試行を続け、再試行時間が長くなりすぎる問題を修正しました[＃9272](https://github.com/pingcap/tiflow/issues/9272) @ [asddongmen](https://github.com/asddongmen) - Kafka [＃8959](https://github.com/pingcap/tiflow/issues/8959) @ [Rustin170506](https://github.com/Rustin170506)にデータを複製する際に下流のメタデータを頻繁に読み取ることによって下流に過度の負荷がかかる問題を修正しました - ダウンストリームが Kafka の場合、TiCDC がダウンストリームのメタデータを頻繁にクエリし、ダウンストリームに過度のワークロードが発生する問題を修正しました[＃8957](https://github.com/pingcap/tiflow/issues/8957) [＃8959](https://github.com/pingcap/tiflow/issues/8959) @ [Rustin170506](https://github.com/Rustin170506) - 一部の特殊なシナリオでソートコンポーネントの過剰なメモリ使用によって引き起こされる OOM 問題を修正[＃8974](https://github.com/pingcap/tiflow/issues/8974) @ [hicqu](https://github.com/hicqu) - AvroまたはCSVプロトコルが使用されている場合、 `UPDATE`操作で古い値を出力できない問題を修正しました[＃9086](https://github.com/pingcap/tiflow/issues/9086) @ [3AceShowHand](https://github.com/3AceShowHand) - - storageサービスにデータを複製するときに、下流のDDLステートメントに対応するJSONファイルにテーブルフィールド[＃9066](https://github.com/pingcap/tiflow/issues/9066) @ [CharlesCheung96](https://github.com/CharlesCheung96)のデフォルト値が記録されない問題を修正しました。 + - ストレージサービスにデータを複製するときに、下流のDDLステートメントに対応するJSONファイルにテーブルフィールド[＃9066](https://github.com/pingcap/tiflow/issues/9066) @ [CharlesCheung96](https://github.com/CharlesCheung96)のデフォルト値が記録されない問題を修正しました。 - TiDB または MySQL [＃9180](https://github.com/pingcap/tiflow/issues/9180) @ [asddongmen](https://github.com/asddongmen)にデータを複製するときに、下流の双方向レプリケーション関連の変数を頻繁に設定することによって発生する下流ログが多すぎる問題を修正しました。 - Kafka メッセージのサイズが大きすぎるためにレプリケーションエラーが発生した場合に、メッセージ本文がログ[＃9031](https://github.com/pingcap/tiflow/issues/9031) @ [darraes](https://github.com/darraes)に記録される問題を修正しました。 - ネットワーク分離やPDオーナーノードの再起動などのPD障害時にTiCDCが停止する問題を修正[＃8808](https://github.com/pingcap/tiflow/issues/8808) [＃8812](https://github.com/pingcap/tiflow/issues/8812) [＃8877](https://github.com/pingcap/tiflow/issues/8877) @ [asddongmen](https://github.com/asddongmen) diff --git a/releases/release-7.1.2.md b/releases/release-7.1.2.md index f7604523f3ef4..437ac877746ab 100644 --- a/releases/release-7.1.2.md +++ b/releases/release-7.1.2.md @@ -98,12 +98,12 @@ TiDB バージョン: 7.1.2 - アクセスパスプルーニングロジックが`READ_FROM_STORAGE(TIFLASH[...])`ヒントを無視し、 `Can't find a proper physical plan`エラー[＃40146](https://github.com/pingcap/tidb/issues/40146) @ [AilinKid](https://github.com/AilinKid)が発生する問題を修正しました。 - CAST に精度損失がないのに条件`cast(col)=range`で FullScan が発生する問題を修正[＃45199](https://github.com/pingcap/tidb/issues/45199) @ [AilinKid](https://github.com/AilinKid) - `plan replayer dump explain`エラー[＃46197](https://github.com/pingcap/tidb/issues/46197) @ [time-and-fate](https://github.com/time-and-fate)を報告する問題を修正 - - `tmp-storage-quota`設定が[＃45161](https://github.com/pingcap/tidb/issues/45161) [＃26806](https://github.com/pingcap/tidb/issues/26806) @ [wshwsh12](https://github.com/wshwsh12)で有効にならない問題を修正 + - `tmp-ストレージ-quota`設定が[＃45161](https://github.com/pingcap/tidb/issues/45161) [＃26806](https://github.com/pingcap/tidb/issues/26806) @ [wshwsh12](https://github.com/wshwsh12)で有効にならない問題を修正 - TiDBパーサーが状態のままになり、解析エラーが発生する問題を修正[＃45898](https://github.com/pingcap/tidb/issues/45898) @ [qw4990](https://github.com/qw4990) - MPP実行プランで集計がユニオンを介してプッシュダウンされると、結果が正しくなくなる問題を修正[＃45850](https://github.com/pingcap/tidb/issues/45850) @ [AilinKid](https://github.com/AilinKid) - `AUTO_ID_CACHE=1` [＃46454](https://github.com/pingcap/tidb/issues/46454) @ [tiancaiamao](https://github.com/tiancaiamao)に設定されている場合に、panic後に TiDB がゆっくりと回復する問題を修正しました。 - ソート演算子がスピルプロセス中に TiDB をクラッシュさせる可能性がある問題を修正[＃47538](https://github.com/pingcap/tidb/issues/47538) @ [windtalker](https://github.com/windtalker) - - BRを使用して`AUTO_ID_CACHE=1` [＃46093](https://github.com/pingcap/tidb/issues/46093) @ [tiancaiamao](https://github.com/tiancaiamao)の非クラスタ化インデックステーブルを復元するときに重複する主キーの問題を修正しました。 + - BRを使用して`AUTO_ID_CACHE=1` [＃46093](https://github.com/pingcap/tidb/issues/46093) @ [tiancaiamao](https://github.com/tiancaiamao)の非クラスター化インデックステーブルを復元するときに重複する主キーの問題を修正しました。 - 静的プルーニングモードでパーティションテーブルをクエリし、実行プランに`IndexLookUp` [＃45757](https://github.com/pingcap/tidb/issues/45757) @ [Defined2014](https://github.com/Defined2014)が含まれている場合にクエリがエラーを報告する可能性がある問題を修正しました。 - パーティションテーブルと配置ポリシー[＃45791](https://github.com/pingcap/tidb/issues/45791) @ [mjonss](https://github.com/mjonss)テーブル間でパーティションを交換した後に、パーティションテーブルへのデータの挿入が失敗する可能性がある問題を修正しました。 - タイムゾーン情報が正しくない時間フィールドをエンコードする問題を修正[＃46033](https://github.com/pingcap/tidb/issues/46033) @ [tangenta](https://github.com/tangenta) @@ -138,7 +138,7 @@ TiDB バージョン: 7.1.2 - PD - v2 スケジューラ アルゴリズム[＃6645](https://github.com/tikv/pd/issues/6645) @ [lhy1024](https://github.com/lhy1024)でホット リージョンがスケジュールされない可能性がある問題を修正しました - - TLSハンドシェイクにより空のクラスタ[＃6913](https://github.com/tikv/pd/issues/6913) @ [nolouch](https://github.com/nolouch)でCPU使用率が上昇する可能性がある問題を修正 + - TLSハンドシェイクにより空のクラスター[＃6913](https://github.com/tikv/pd/issues/6913) @ [nolouch](https://github.com/nolouch)でCPU使用率が上昇する可能性がある問題を修正 - PDノード間の注入エラーによりPDpanic[＃6858](https://github.com/tikv/pd/issues/6858) @ [HuSharp](https://github.com/HuSharp)が発生する可能性がある問題を修正しました - ストア情報の同期によりPDリーダーが終了し、 [＃6918](https://github.com/tikv/pd/issues/6918) @ [rleungx](https://github.com/rleungx)で停止する可能性がある問題を修正しました。 - フラッシュバック[＃6912](https://github.com/tikv/pd/issues/6912) @ [overvenus](https://github.com/overvenus)後にリージョン情報が更新されない問題を修正 @@ -152,7 +152,7 @@ TiDB バージョン: 7.1.2 - ルールチェッカーがピア[＃6559](https://github.com/tikv/pd/issues/6559) @ [nolouch](https://github.com/nolouch)を選択した場合に、不健全なピアを削除できない問題を修正しました - etcd がすでに起動しているがクライアントがまだ接続していない場合、クライアントを呼び出すと PD がpanic[＃6860](https://github.com/tikv/pd/issues/6860) @ [HuSharp](https://github.com/HuSharp)になる可能性がある問題を修正しました。 - RU消費量が0未満の場合にPDが[＃6973](https://github.com/tikv/pd/issues/6973) @ [CabinfeverB](https://github.com/CabinfeverB)でクラッシュする問題を修正 - - クラスタが大きい場合、クライアントが定期的に更新される`min-resolved-ts` PD OOMを引き起こす可能性がある問題を修正しました[＃46664](https://github.com/pingcap/tidb/issues/46664) @ [HuSharp](https://github.com/HuSharp) + - クラスターが大きい場合、クライアントが定期的に更新される`min-resolved-ts` PD OOMを引き起こす可能性がある問題を修正しました[＃46664](https://github.com/pingcap/tidb/issues/46664) @ [HuSharp](https://github.com/HuSharp) - TiFlash @@ -178,7 +178,7 @@ TiDB バージョン: 7.1.2 - TiCDC - 異常な状態のレプリケーションタスクが上流のGC [＃9543](https://github.com/pingcap/tiflow/issues/9543) @ [CharlesCheung96](https://github.com/CharlesCheung96)をブロックする問題を修正しました - - オブジェクトstorageにデータを複製するとデータの不整合が発生する可能性がある問題を修正[＃9592](https://github.com/pingcap/tiflow/issues/9592) @ [CharlesCheung96](https://github.com/CharlesCheung96) + - オブジェクトストレージにデータを複製するとデータの不整合が発生する可能性がある問題を修正[＃9592](https://github.com/pingcap/tiflow/issues/9592) @ [CharlesCheung96](https://github.com/CharlesCheung96) - `redo-resolved-ts`有効にすると、changefeed が失敗する可能性がある問題を修正[＃9769](https://github.com/pingcap/tiflow/issues/9769) @ [CharlesCheung96](https://github.com/CharlesCheung96) - 間違ったメモリ情報を取得すると、一部のオペレーティングシステムで OOM 問題が発生する可能性がある問題を修正[＃9762](https://github.com/pingcap/tiflow/issues/9762) @ [sdojjy](https://github.com/sdojjy) - `scale-out`が有効になっている場合のノード間の書き込みキーの不均等な配布の問題を修正[＃9665](https://github.com/pingcap/tiflow/issues/9665) @ [sdojjy](https://github.com/sdojjy) @@ -211,7 +211,7 @@ TiDB バージョン: 7.1.2 - `AUTO_ID_CACHE=1`を含むテーブルをインポートするときに、間違った`row_id`が[＃46100](https://github.com/pingcap/tidb/issues/46100) @ [D3Hunter](https://github.com/D3Hunter)に割り当てられる問題を修正しました - `NEXT_GLOBAL_ROW_ID` [＃45427](https://github.com/pingcap/tidb/issues/45427) @ [lyzx2001](https://github.com/lyzx2001)を保存するときにデータ型が間違っている問題を修正しました - `checksum = "optional"` [＃45382](https://github.com/pingcap/tidb/issues/45382) @ [lyzx2001](https://github.com/lyzx2001)のときにチェックサムがエラーを報告する問題を修正しました - - PDクラスタアドレスが[＃43436](https://github.com/pingcap/tidb/issues/43436) @ [lichunzhu](https://github.com/lichunzhu)に変更されるとデータのインポートが失敗する問題を修正しました + - PDクラスターアドレスが[＃43436](https://github.com/pingcap/tidb/issues/43436) @ [lichunzhu](https://github.com/lichunzhu)に変更されるとデータのインポートが失敗する問題を修正しました - PDトポロジが変更されるとTiDB Lightningが起動に失敗する問題を修正[＃46688](https://github.com/pingcap/tidb/issues/46688) @ [lance6716](https://github.com/lance6716) - CSVデータ[＃43284](https://github.com/pingcap/tidb/issues/43284) @ [lyzx2001](https://github.com/lyzx2001)をインポートする際にルートがpanicになる可能性がある問題を修正 diff --git a/releases/release-7.1.3.md b/releases/release-7.1.3.md index 435fe85fab92b..e8d4c81a679f3 100644 --- a/releases/release-7.1.3.md +++ b/releases/release-7.1.3.md @@ -18,7 +18,7 @@ TiDB バージョン: 7.1.3 - [`sql-mode`](/ticdc/ticdc-changefeed-config.md) : TiCDC がデータを複製するときに DDL ステートメントを解析するために使用する[SQLモード](https://docs.pingcap.com/tidb/v7.1/ticdc-ddl#sql-mode)設定できます[＃9876](https://github.com/pingcap/tiflow/issues/9876) @ [asddongmen](https://github.com/asddongmen) - [`encoding-worker-num`](/ticdc/ticdc-changefeed-config.md)と[`flush-worker-num`](/ticdc/ticdc-changefeed-config.md) : 異なるマシンの仕様に基づいて、再実行モジュールに異なる同時実行パラメータを設定できます[＃10048](https://github.com/pingcap/tiflow/issues/10048) @ [CharlesCheung96](https://github.com/CharlesCheung96) - [`compression`](/ticdc/ticdc-changefeed-config.md) : REDOログファイルの圧縮動作を設定できます[＃10176](https://github.com/pingcap/tiflow/issues/10176) @ [sdojjy](https://github.com/sdojjy) - - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトstorage[＃10109](https://github.com/pingcap/tiflow/issues/10109)にデータを複製するときに履歴データの自動クリーンアップを設定できます[チャールズ・チュン96](https://github.com/CharlesCheung96) + - [`sink.cloud-ストレージ-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージ[＃10109](https://github.com/pingcap/tiflow/issues/10109)にデータを複製するときに履歴データの自動クリーンアップを設定できます[チャールズ・チュン96](https://github.com/CharlesCheung96) ## 改善点 {#improvements} @@ -43,7 +43,7 @@ TiDB バージョン: 7.1.3 - TiCDCノードがTiDB [＃9935](https://github.com/pingcap/tiflow/issues/9935) @ [3AceShowHand](https://github.com/3AceShowHand)にデータを複製する際のメモリ消費を最適化します - いくつかのアラームルールを最適化[＃9266](https://github.com/pingcap/tiflow/issues/9266) @ [asddongmen](https://github.com/asddongmen) - S3へのデータの並列書き込みやlz4圧縮アルゴリズムの採用など、REDOログのパフォーマンスを最適化します[＃10176](https://github.com/pingcap/tiflow/issues/10176) [＃10226](https://github.com/pingcap/tiflow/issues/10226) @ [sdojjy](https://github.com/sdojjy) - - 並列度[＃10098](https://github.com/pingcap/tiflow/issues/10098) @ [CharlesCheung96](https://github.com/CharlesCheung96)を増やすことで、TiCDC がオブジェクトstorageにデータを複製する際のパフォーマンスが向上します。 + - 並列度[＃10098](https://github.com/pingcap/tiflow/issues/10098) @ [CharlesCheung96](https://github.com/CharlesCheung96)を増やすことで、TiCDC がオブジェクトストレージにデータを複製する際のパフォーマンスが向上します。 - TiCDC 増分スキャンによる上流 TiKV [＃11390](https://github.com/tikv/tikv/issues/11390) @ [hicqu](https://github.com/hicqu)への影響を軽減 - `sink-uri`構成[＃10106](https://github.com/pingcap/tiflow/issues/10106) @ [3AceShowHand](https://github.com/3AceShowHand)で`content-compatible=true`設定することにより、 TiCDC Canal-JSON コンテンツ フォーマット[公式Canal出力のコンテンツ形式と互換性がある](https://docs.pingcap.com/tidb/v6.5/ticdc-canal-json#compatibility-with-the-official-canal)作成をサポートします。 @@ -95,7 +95,7 @@ TiDB バージョン: 7.1.3 - 解決済みのTSが2時間ブロックされる可能性がある問題を修正[＃15520](https://github.com/tikv/tikv/issues/15520) [＃39130](https://github.com/pingcap/tidb/issues/39130) @ [overvenus](https://github.com/overvenus) - TiKVがraft log [＃15800](https://github.com/tikv/tikv/issues/15800) @ [tonyxuqqi](https://github.com/tonyxuqqi)を追加できないため`ServerIsBusy`エラーを報告する問題を修正しました。 - BRが[＃15684](https://github.com/tikv/tikv/issues/15684) @ [YuJuncen](https://github.com/YuJuncen)でクラッシュしたときにスナップショットの復元が停止する可能性がある問題を修正しました - - 大規模なトランザクション[＃14864](https://github.com/tikv/tikv/issues/14864) @ [overvenus](https://github.com/overvenus)を追跡するときに、古い読み取りの解決済み TS が TiKV OOM 問題を引き起こす可能性がある問題を修正しました + - 大規模なトランザクション[＃14864](https://github.com/tikv/tikv/issues/14864) @ [overvenus](https://github.com/overvenus)を追跡するときに、ステイル読み取りの解決済み TS が TiKV OOM 問題を引き起こす可能性がある問題を修正しました - 破損したSSTファイルが他のTiKVノード[＃15986](https://github.com/tikv/tikv/issues/15986) @ [Connor1996](https://github.com/Connor1996)に広がる可能性がある問題を修正 - [＃15817](https://github.com/tikv/tikv/issues/15817) @ [Connor1996](https://github.com/Connor1996)にスケールアウトするときに DR 自動同期のジョイント状態がタイムアウトする可能性がある問題を修正しました - クラウド環境のGrafanaでスケジューラコマンド変数が正しくない問題を修正[＃15832](https://github.com/tikv/tikv/issues/15832) @ [Connor1996](https://github.com/Connor1996) @@ -113,10 +113,10 @@ TiDB バージョン: 7.1.3 - ワークロードによる調整ページでエラー[＃48162](https://github.com/pingcap/tidb/issues/48162) @ [CabinfeverB](https://github.com/CabinfeverB)が報告される問題を修正しました - リソース グループを削除すると DDL の原子性[＃45050](https://github.com/pingcap/tidb/issues/45050) @ [glorv](https://github.com/glorv)が損なわれる可能性がある問題を修正しました - PDリーダーが転送され、新しいリーダーとPDクライアントの間にネットワークパーティションがある場合、PDクライアントがリーダー[＃7416](https://github.com/tikv/pd/issues/7416) @ [CabinfeverB](https://github.com/CabinfeverB)の情報を更新できない問題を修正しました。 - - 大規模クラスタに複数の TiKV ノードを追加すると、TiKVハートビートレポートが遅くなったり停止したりする可能性がある問題を修正しました[＃7248](https://github.com/tikv/pd/issues/7248) @ [rleungx](https://github.com/rleungx) + - 大規模クラスターに複数の TiKV ノードを追加すると、TiKVハートビートレポートが遅くなったり停止したりする可能性がある問題を修正しました[＃7248](https://github.com/tikv/pd/issues/7248) @ [rleungx](https://github.com/rleungx) - TiDBダッシュボードがPD `trace`データを正しく読み取れない問題を修正[＃7253](https://github.com/tikv/pd/issues/7253) @ [nolouch](https://github.com/nolouch) - Gin Web Framework のバージョンを v1.8.1 から v1.9.1 にアップグレードして、いくつかのセキュリティ問題を修正しました[＃7438](https://github.com/tikv/pd/issues/7438) @ [niubell](https://github.com/niubell) - - ルールチェッカーが配置ルール[＃7185](https://github.com/tikv/pd/issues/7185) @ [nolouch](https://github.com/nolouch)設定に従って学習者を追加しない問題を修正しました + - ルールチェッカーが配置ルール[＃7185](https://github.com/tikv/pd/issues/7185) @ [nolouch](https://github.com/nolouch)設定に従ってラーナーを追加しない問題を修正しました - TiKVノードが利用できない場合にPDが通常のピアを削除する可能性がある問題を修正[＃7249](https://github.com/tikv/pd/issues/7249) @ [lhy1024](https://github.com/lhy1024) - DR自動同期モード[＃6988](https://github.com/tikv/pd/issues/6988) @ [HuSharp](https://github.com/HuSharp)でリーダーの切り替えに時間がかかる問題を修正 @@ -134,19 +134,19 @@ TiDB バージョン: 7.1.3 - BR SQL コマンドと CLI のデフォルト値が異なるため、OOM の問題が発生する可能性がある問題を修正しました[＃48000](https://github.com/pingcap/tidb/issues/48000) @ [YuJuncen](https://github.com/YuJuncen) - 大規模なワイドテーブル[＃15714](https://github.com/tikv/tikv/issues/15714) @ [YuJuncen](https://github.com/YuJuncen)をバックアップするときに、一部のシナリオでログバックアップが停止する可能性がある問題を修正しました。 - - BRが外部storageファイル[＃48452](https://github.com/pingcap/tidb/issues/48452) @ [3AceShowHand](https://github.com/3AceShowHand)に対して誤ったURIを生成する問題を修正 + - BRが外部ストレージファイル[＃48452](https://github.com/pingcap/tidb/issues/48452) @ [3AceShowHand](https://github.com/3AceShowHand)に対して誤ったURIを生成する問題を修正 - EC2 メタデータ接続のリセット後の再試行により、バックアップとリストアのパフォーマンスが低下する問題を修正[＃47650](https://github.com/pingcap/tidb/issues/47650) @ [Leavrth](https://github.com/Leavrth) - タスク初期化中にPDへの接続に失敗すると、ログバックアップタスクは開始できるが正常に動作しない問題を修正[＃16056](https://github.com/tikv/tikv/issues/16056) @ [YuJuncen](https://github.com/YuJuncen) - TiCDC - 特定のシナリオで`DELETE`ステートメントを複製するときに、 `WHERE`句が主キーを条件として使用しない問題を修正しました[＃9812](https://github.com/pingcap/tiflow/issues/9812) @ [asddongmen](https://github.com/asddongmen) - - オブジェクトstorageにデータを複製する際に、特定の特殊なシナリオでレプリケーションタスクが停止する問題を修正[＃10041](https://github.com/pingcap/tiflow/issues/10041) [＃10044](https://github.com/pingcap/tiflow/issues/10044) @ [CharlesCheung96](https://github.com/CharlesCheung96) + - オブジェクトストレージにデータを複製する際に、特定の特殊なシナリオでレプリケーションタスクが停止する問題を修正[＃10041](https://github.com/pingcap/tiflow/issues/10041) [＃10044](https://github.com/pingcap/tiflow/issues/10044) @ [CharlesCheung96](https://github.com/CharlesCheung96) - 同期ポイントとREDOログ[＃10091](https://github.com/pingcap/tiflow/issues/10091) @ [CharlesCheung96](https://github.com/CharlesCheung96)を有効にした後、特定のシナリオでレプリケーションタスクが停止する問題を修正しました。 - 特定の特殊なシナリオで TiCDC が TiKV との接続を誤って閉じる問題を修正[＃10239](https://github.com/pingcap/tiflow/issues/10239) @ [hicqu](https://github.com/hicqu) - ターゲットテーブルが削除され、その後アップストリーム[＃10079](https://github.com/pingcap/tiflow/issues/10079) @ [asddongmen](https://github.com/asddongmen)で再作成された場合、変更フィードが双方向レプリケーションモードで DML イベントをレプリケートできない問題を修正しました。 - オブジェクトストアシンク[＃10041](https://github.com/pingcap/tiflow/issues/10041) @ [CharlesCheung96](https://github.com/CharlesCheung96)にデータを複製するときに NFS ディレクトリにアクセスすることによって発生するパフォーマンスの問題を修正しました - - オブジェクトstorageサービス[＃10137](https://github.com/pingcap/tiflow/issues/10137) @ [sdojjy](https://github.com/sdojjy)にデータを複製するときに TiCDCサーバーがpanic可能性がある問題を修正しました + - オブジェクトストレージサービス[＃10137](https://github.com/pingcap/tiflow/issues/10137) @ [sdojjy](https://github.com/sdojjy)にデータを複製するときに TiCDCサーバーがpanic可能性がある問題を修正しました - REDOログが有効な場合にDDL文の複製間隔が長すぎる問題を修正[＃9960](https://github.com/pingcap/tiflow/issues/9960) @ [CharlesCheung96](https://github.com/CharlesCheung96) - REDOログが有効な場合にNFS障害によりオーナーノードが停止する問題を修正[＃9886](https://github.com/pingcap/tiflow/issues/9886) @ [3AceShowHand](https://github.com/3AceShowHand) diff --git a/releases/release-7.1.4.md b/releases/release-7.1.4.md index 77e38cd0e6b8e..6de63cdea0e78 100644 --- a/releases/release-7.1.4.md +++ b/releases/release-7.1.4.md @@ -29,7 +29,7 @@ TiDBバージョン: 7.1.4 - PD - - バックアップ クラスタが切断されたときに PD がクラスタ ステータスを自動更新する速度を向上[＃6883](https://github.com/tikv/pd/issues/6883) @ [disksing](https://github.com/disksing) + - バックアップ クラスターが切断されたときに PD がクラスター ステータスを自動更新する速度を向上[＃6883](https://github.com/tikv/pd/issues/6883) @ [disksing](https://github.com/disksing) - TiFlash @@ -45,7 +45,7 @@ TiDBバージョン: 7.1.4 - より効率的なアルゴリズム[＃50613](https://github.com/pingcap/tidb/issues/50613) @ [Leavrth](https://github.com/Leavrth)を使用して、データ復元中に SST ファイルをマージする速度を改善します - データ復元中に SST ファイルをバッチで取り込むことをサポート[＃16267](https://github.com/tikv/tikv/issues/16267) @ [3pointer](https://github.com/3pointer) - ログバックアップ[＃51046](https://github.com/pingcap/tidb/issues/51046) @ [YuJuncen](https://github.com/YuJuncen)中に、ログとメトリックのグローバルチェックポイントの進行に影響を与える最も遅いリージョンの情報を出力します。 - - Google Cloud Storage（GCS）を外部storageとして使用する場合の古い互換性チェックを削除します[＃50533](https://github.com/pingcap/tidb/issues/50533) @ [lance6716](https://github.com/lance6716) + - Google Cloud Storage（GCS）を外部ストレージとして使用する場合の古い互換性チェックを削除します[＃50533](https://github.com/pingcap/tidb/issues/50533) @ [lance6716](https://github.com/lance6716) - 複数のログバックアップ切り捨てタスク（ `br log truncate` ）が同時に実行されるのを防ぐためのロックメカニズムを実装する[＃49414](https://github.com/pingcap/tidb/issues/49414) @ [YuJuncen](https://github.com/YuJuncen) - TiCDC @@ -132,8 +132,8 @@ TiDBバージョン: 7.1.4 - `MergeLabels`関数が[＃7535](https://github.com/tikv/pd/issues/7535) @ [lhy1024](https://github.com/lhy1024)で呼び出されたときにデータ競合が発生する問題を修正しました - TLS が有効な場合に TiDB ダッシュボードが TiKV プロファイルを取得できない問題を修正[＃7561](https://github.com/tikv/pd/issues/7561) @ [Connor1996](https://github.com/Connor1996) - レプリカ数が要件[＃7584](https://github.com/tikv/pd/issues/7584) @ [bufferflies](https://github.com/bufferflies)を満たしていない場合に孤立ピアが削除される問題を修正しました - - データレプリケーション自動同期（DR自動同期）モードを採用しているクラスタで`available_stores`誤って計算される問題を修正[＃7221](https://github.com/tikv/pd/issues/7221) @ [disksing](https://github.com/disksing) - - 配置ルールの設定が複雑な場合、データレプリケーション自動同期（DR自動同期）モードを採用しているクラスタで`canSync`と`hasMajority`誤って計算される可能性がある問題を修正しました[＃7201](https://github.com/tikv/pd/issues/7201) @ [disksing](https://github.com/disksing) + - データレプリケーション自動同期（DR自動同期）モードを採用しているクラスターで`available_stores`誤って計算される問題を修正[＃7221](https://github.com/tikv/pd/issues/7221) @ [disksing](https://github.com/disksing) + - 配置ルールの設定が複雑な場合、データレプリケーション自動同期（DR自動同期）モードを採用しているクラスターで`canSync`と`hasMajority`誤って計算される可能性がある問題を修正しました[＃7201](https://github.com/tikv/pd/issues/7201) @ [disksing](https://github.com/disksing) - データレプリケーション自動同期（DR自動同期）モード[＃7218](https://github.com/tikv/pd/issues/7218) @ [disksing](https://github.com/disksing)を採用しているクラスターで、セカンダリAZがダウンしているときにプライマリAZがTiKVノードを追加できない問題を修正しました。 - リソース グループをバッチでクエリすると PD がpanic[＃7206](https://github.com/tikv/pd/issues/7206) @ [nolouch](https://github.com/nolouch)になる可能性がある問題を修正しました - `pd-ctl`を使用してリーダーのないリージョンを照会すると、PD が[＃7630](https://github.com/tikv/pd/issues/7630) @ [rleungx](https://github.com/rleungx)でpanicになる可能性がある問題を修正しました。 @@ -169,7 +169,7 @@ TiDBバージョン: 7.1.4 - 極端なケースでチェンジフィード`resolved ts`が進まない問題を修正[＃10157](https://github.com/pingcap/tiflow/issues/10157) @ [sdojjy](https://github.com/sdojjy) - 同期ポイントテーブルが誤って複製される可能性がある問題を修正[＃10576](https://github.com/pingcap/tiflow/issues/10576) @ [asddongmen](https://github.com/asddongmen) - `ignore-event`で`add table partition`イベントをフィルタリングするように設定した後、TiCDC が関連パーティションの他のタイプの DML 変更をダウンストリーム[＃10524](https://github.com/pingcap/tiflow/issues/10524) @ [CharlesCheung96](https://github.com/CharlesCheung96)に複製しない問題を修正しました。 - - storageシンク[＃10352](https://github.com/pingcap/tiflow/issues/10352) @ [CharlesCheung96](https://github.com/CharlesCheung96)の使用時に、storageサービスによって生成されたファイルシーケンス番号が正しく増加しない可能性がある問題を修正しました。 + - ストレージシンク[＃10352](https://github.com/pingcap/tiflow/issues/10352) @ [CharlesCheung96](https://github.com/CharlesCheung96)の使用時に、ストレージサービスによって生成されたファイルシーケンス番号が正しく増加しない可能性がある問題を修正しました。 - 複数のチェンジフィード[＃10430](https://github.com/pingcap/tiflow/issues/10430) @ [CharlesCheung96](https://github.com/CharlesCheung96)を同時に作成すると TiCDC が`ErrChangeFeedAlreadyExists`エラーを返す問題を修正しました - 変更フィードを再開するときに`snapshot lost caused by GC`時間内に報告されず、変更フィードの`checkpoint-ts`が TiDB [＃10463](https://github.com/pingcap/tiflow/issues/10463) @ [sdojjy](https://github.com/sdojjy)の GC セーフポイントよりも小さい問題を修正しました。 - 単一行データのデータ整合性検証が有効になった後、タイムゾーンの不一致により TiCDC が`TIMESTAMP`種類のチェックサムの検証に失敗する問題を修正[＃10573](https://github.com/pingcap/tiflow/issues/10573) @ [3AceShowHand](https://github.com/3AceShowHand) diff --git a/releases/release-7.1.5.md b/releases/release-7.1.5.md index 606df91ccd35c..bc0594cadda46 100644 --- a/releases/release-7.1.5.md +++ b/releases/release-7.1.5.md @@ -97,7 +97,7 @@ TiDB バージョン: 7.1.5 - ログバックアップタスクを一時停止後に削除しても、GCセーフポイント[＃52082](https://github.com/pingcap/tidb/issues/52082) @ [3pointer](https://github.com/3pointer)がすぐに復元されない問題を修正しました。 - フルバックアップが失敗したときにログが多すぎる問題を修正[＃51572](https://github.com/pingcap/tidb/issues/51572) @ [Leavrth](https://github.com/Leavrth) - - `AUTO_RANDOM`列が複合クラスタリングインデックス[＃52255](https://github.com/pingcap/tidb/issues/52255) @ [Leavrth](https://github.com/Leavrth)にある場合、 BRが`AUTO_RANDOM` ID割り当ての進行状況をバックアップできなかった問題を修正します + - `AUTO_RANDOM`列が複合クラスターリングインデックス[＃52255](https://github.com/pingcap/tidb/issues/52255) @ [Leavrth](https://github.com/Leavrth)にある場合、 BRが`AUTO_RANDOM` ID割り当ての進行状況をバックアップできなかった問題を修正します - フルバックアップでピアが見つからない場合に TiKV がパニックを起こす問題を修正[＃16394](https://github.com/tikv/tikv/issues/16394) @ [Leavrth](https://github.com/Leavrth) - PD接続障害により、ログバックアップアドバンサ所有者が配置されているTiDBインスタンスがpanic[＃52597](https://github.com/pingcap/tidb/issues/52597) @ [YuJuncen](https://github.com/YuJuncen)になる可能性がある問題を修正しました。 - 不安定なテストケース[＃52547](https://github.com/pingcap/tidb/issues/52547) [リーヴルス](https://github.com/Leavrth)で修正する @@ -110,7 +110,7 @@ TiDB バージョン: 7.1.5 - 変更フィードを再開するときに`snapshot lost caused by GC`時間内に報告されず、変更フィードの`checkpoint-ts` TiDB [＃10463](https://github.com/pingcap/tiflow/issues/10463) @ [sdojjy](https://github.com/sdojjy)の GC セーフポイントよりも小さい問題を修正しました。 - テーブルレプリケーションタスク[＃10613](https://github.com/pingcap/tiflow/issues/10613) @ [CharlesCheung96](https://github.com/CharlesCheung96)をスケジュールするときに TiCDC がパニックになる問題を修正しました - DDL文が頻繁に実行されるシナリオで、間違ったBarrierTSが原因でデータが間違ったCSVファイルに書き込まれる問題を修正[＃10668](https://github.com/pingcap/tiflow/issues/10668) @ [lidezhu](https://github.com/lidezhu) - - オブジェクトstorageシンクに一時的な障害が発生した場合に、結果整合性が有効になっている変更フィードが失敗する可能性がある問題を修正しました[＃10710](https://github.com/pingcap/tiflow/issues/10710) @ [CharlesCheung96](https://github.com/CharlesCheung96) + - オブジェクトストレージシンクに一時的な障害が発生した場合に、結果整合性が有効になっている変更フィードが失敗する可能性がある問題を修正しました[＃10710](https://github.com/pingcap/tiflow/issues/10710) @ [CharlesCheung96](https://github.com/CharlesCheung96) - `open-protocol`の古い値部分が、実際のタイプ[＃10803](https://github.com/pingcap/tiflow/issues/10803) @ [3AceShowHand](https://github.com/3AceShowHand)ではなく、タイプ`STRING`に応じて誤ってデフォルト値を出力する問題を修正しました。 - TiDB Lightning diff --git a/releases/release-7.1.6.md b/releases/release-7.1.6.md index 016178b4b3933..00f93da9b8c4c 100644 --- a/releases/release-7.1.6.md +++ b/releases/release-7.1.6.md @@ -61,7 +61,7 @@ TiDB バージョン: 7.1.6 - TiCDC - - ダウンストリームがメッセージキュー（MQ）またはクラウドstorageの場合、生のイベントを直接出力することをサポート[＃11211](https://github.com/pingcap/tiflow/issues/11211) @ [CharlesCheung96](https://github.com/CharlesCheung96) + - ダウンストリームがメッセージキュー（MQ）またはクラウドストレージの場合、生のイベントを直接出力することをサポート[＃11211](https://github.com/pingcap/tiflow/issues/11211) @ [CharlesCheung96](https://github.com/CharlesCheung96) - REDOログを使用してデータリカバリ中のメモリの安定性を向上させ、OOM [＃10900](https://github.com/pingcap/tiflow/issues/10900) @ [CharlesCheung96](https://github.com/CharlesCheung96)の確率を低減します。 - 下流が`SUPER`権限が付与されたTiDBの場合、TiCDCは下流データベースから`ADD INDEX DDL`の実行ステータスを照会することをサポートします。これにより、DDL文の実行を再試行する際のタイムアウトによるデータ複製の失敗を回避できます[＃10682](https://github.com/pingcap/tiflow/issues/10682) @ [CharlesCheung96](https://github.com/CharlesCheung96)の場合）。 @@ -139,10 +139,10 @@ TiDB バージョン: 7.1.6 - 最初の引数が`month`で、2番目の引数が負の[＃54908](https://github.com/pingcap/tidb/issues/54908) @ [xzhangxian1008](https://github.com/xzhangxian1008)場合に`TIMESTAMPADD()`関数が無限ループに入る問題を修正しました。 - `tidb_mem_quota_analyze`が有効になっていて、統計の更新に使用されるメモリが[＃52601](https://github.com/pingcap/tidb/issues/52601) @ [hawkingrei](https://github.com/hawkingrei)の制限を超えると、TiDB がクラッシュする可能性がある問題を修正しました。 - ユニークインデックス[＃56161](https://github.com/pingcap/tidb/issues/56161) @ [tangenta](https://github.com/tangenta)を追加するときに`duplicate entry`発生する可能性がある問題を修正 - - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、古い読み取りのクエリレイテンシーが増加する問題を修正しました。 + - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、ステイル読み取りのクエリレイテンシーが増加する問題を修正しました。 - GlobalStatsの`Distinct_count`情報が正しくない可能性がある問題を修正しました[＃53752](https://github.com/pingcap/tidb/issues/53752) @ [hawkingrei](https://github.com/hawkingrei) - `SELECT DISTINCT CAST(col AS DECIMAL), CAST(col AS SIGNED) FROM ...`クエリを実行すると誤った結果が返される可能性がある問題を修正[＃53726](https://github.com/pingcap/tidb/issues/53726) @ [hawkingrei](https://github.com/hawkingrei) - - クエリに利用可能なインデックスマージ実行プラン[＃56217](https://github.com/pingcap/tidb/issues/56217) @ [AilinKid](https://github.com/AilinKid)がある場合に`read_from_storage`ヒントが有効にならない可能性がある問題を修正しました + - クエリに利用可能なインデックスマージ実行プラン[＃56217](https://github.com/pingcap/tidb/issues/56217) @ [AilinKid](https://github.com/AilinKid)がある場合に`read_from_ストレージ`ヒントが有効にならない可能性がある問題を修正しました - `TIMESTAMPADD()`関数が誤った結果を返す問題を修正[＃41052](https://github.com/pingcap/tidb/issues/41052) @ [xzhangxian1008](https://github.com/xzhangxian1008) - `?`の引数を含む`CONV`の式を持つ`PREPARE` `EXECUTE`ステートメントを複数回実行すると、誤ったクエリ結果が返される可能性がある問題を修正しました[＃53505](https://github.com/pingcap/tidb/issues/53505) @ [qw4990](https://github.com/qw4990) - トランザクションで使用されるメモリが複数回追跡される可能性がある問題を修正[＃53984](https://github.com/pingcap/tidb/issues/53984) @ [ekexium](https://github.com/ekexium) @@ -169,7 +169,7 @@ TiDB バージョン: 7.1.6 - 浮動小数点数または整数オーバーフローがプランキャッシュ[＃46538](https://github.com/pingcap/tidb/issues/46538) @ [hawkingrei](https://github.com/hawkingrei)に影響を与える問題を修正しました - `IndexLookUp`演算子のメモリの一部が[＃56440](https://github.com/pingcap/tidb/issues/56440) @ [wshwsh12](https://github.com/wshwsh12)で追跡されない問題を修正 - stale read が読み取り操作のタイムスタンプを厳密に検証しない問題を修正しました。その結果、TSO と実際の物理時間[＃56809](https://github.com/pingcap/tidb/issues/56809) @ [MyonKeminta](https://github.com/MyonKeminta)の間にオフセットが存在する場合に、トランザクションの一貫性にわずかながら影響する可能性が生じます。 - - storageエンジン[＃56402](https://github.com/pingcap/tidb/issues/56402) @ [YangKeao](https://github.com/YangKeao)としてTiKVが選択されていない場合にTTLが失敗する可能性がある問題を修正 + - ストレージエンジン[＃56402](https://github.com/pingcap/tidb/issues/56402) @ [YangKeao](https://github.com/YangKeao)としてTiKVが選択されていない場合にTTLが失敗する可能性がある問題を修正 - 書き込み競合が発生したときにTTLタスクをキャンセルできない問題を修正[＃56422](https://github.com/pingcap/tidb/issues/56422) @ [YangKeao](https://github.com/YangKeao) - 科学表記法で大きすぎる数値を挿入するとエラーが発生する問題を修正`ERROR 1264 (22003)` 。動作を MySQL [＃47787](https://github.com/pingcap/tidb/issues/47787) @ [lcwangchao](https://github.com/lcwangchao)と一致させる。 - TTLタスクをキャンセルした際に、対応するSQLが強制終了されない問題を修正[＃56511](https://github.com/pingcap/tidb/issues/56511) @ [lcwangchao](https://github.com/lcwangchao) @@ -228,7 +228,7 @@ TiDB バージョン: 7.1.6 - TiFlash - - クラスタをv6.5.0より前のバージョンからv6.5.0以降にアップグレードするときに、 TiFlashメタデータが破損してプロセスがpanicになる可能性がある問題を修正しました[＃9039](https://github.com/pingcap/tiflash/issues/9039) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - クラスターをv6.5.0より前のバージョンからv6.5.0以降にアップグレードするときに、 TiFlashメタデータが破損してプロセスがpanicになる可能性がある問題を修正しました[＃9039](https://github.com/pingcap/tiflash/issues/9039) @ [JaySon-Huang](https://github.com/JaySon-Huang) - 遅延マテリアライゼーションが有効になった後に、一部のクエリで列タイプの不一致エラーが報告される可能性がある問題を修正[＃9175](https://github.com/pingcap/tiflash/issues/9175) @ [JinheLin](https://github.com/JinheLin) - 遅延マテリアライゼーションが有効になっている場合に一部のクエリでエラーが報告される可能性がある問題を修正[＃9472](https://github.com/pingcap/tiflash/issues/9472) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - TiFlashでサポートされていない一部の JSON関数がTiFlash [＃9444](https://github.com/pingcap/tiflash/issues/9444) @ [windtalker](https://github.com/windtalker)にプッシュダウンされる問題を修正しました @@ -242,7 +242,7 @@ TiDB バージョン: 7.1.6 - `CAST()`関数を使用して文字列をタイムゾーンまたは無効な文字を含む日付時刻に変換すると、結果が正しくなくなる問題を修正しました[＃8754](https://github.com/pingcap/tiflash/issues/8754) @ [solotzg](https://github.com/solotzg) - TiFlash が高同時読み取りシナリオで一時的に誤った結果を返す可能性がある問題を修正[＃8845](https://github.com/pingcap/tiflash/issues/8845) @ [JinheLin](https://github.com/JinheLin) - `SUBSTRING_INDEX()`関数が一部のコーナーケースでTiFlash のクラッシュを引き起こす可能性がある問題を修正[＃9116](https://github.com/pingcap/tiflash/issues/9116) @ [wshwsh12](https://github.com/wshwsh12) - - クラスタ内で長期間にわたって頻繁に`EXCHANGE PARTITION`と`DROP TABLE`操作を行うと、 TiFlashテーブル メタデータのレプリケーションが遅くなり、クエリ パフォーマンスが低下する可能性がある問題を修正しました[＃9227](https://github.com/pingcap/tiflash/issues/9227) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - クラスター内で長期間にわたって頻繁に`EXCHANGE PARTITION`と`DROP TABLE`操作を行うと、 TiFlashテーブル メタデータのレプリケーションが遅くなり、クエリ パフォーマンスが低下する可能性がある問題を修正しました[＃9227](https://github.com/pingcap/tiflash/issues/9227) @ [JaySon-Huang](https://github.com/JaySon-Huang) - 空のキー範囲を持つクエリがTiFlash上で読み取りタスクを正しく生成できず、 TiFlashクエリ[＃9108](https://github.com/pingcap/tiflash/issues/9108) @ [JinheLin](https://github.com/JinheLin)がブロックされる可能性がある問題を修正しました。 - 特定のケースで関数`CAST AS DECIMAL`の結果の符号が正しくない問題を修正[＃9301](https://github.com/pingcap/tiflash/issues/9301) @ [guo-shaoge](https://github.com/guo-shaoge) - `SUBSTRING()`関数が特定の整数型に対して`pos`と`len`引数をサポートせず、クエリエラー[＃9473](https://github.com/pingcap/tiflash/issues/9473) @ [gengliqi](https://github.com/gengliqi)が発生する問題を修正しました @@ -262,7 +262,7 @@ TiDB バージョン: 7.1.6 - 復元プロセス中に複数のネストされた再試行によりBR がエラーを正しく識別できない問題を修正[＃54053](https://github.com/pingcap/tidb/issues/54053) @ [RidRisR](https://github.com/RidRisR) - PD [＃17020](https://github.com/tikv/tikv/issues/17020) @ [YuJuncen](https://github.com/YuJuncen)へのネットワーク接続が不安定な状態で一時停止中のログバックアップタスクを再開すると TiKV がpanic可能性がある問題を修正しました - バックアッププロセス中に TiKV が応答しなくなった場合にバックアップタスクが停止する可能性がある問題を修正[＃53480](https://github.com/pingcap/tidb/issues/53480) @ [Leavrth](https://github.com/Leavrth) - - バックアップと復元のチェックポイントパスが一部の外部storageと互換性がない問題を修正[＃55265](https://github.com/pingcap/tidb/issues/55265) @ [Leavrth](https://github.com/Leavrth) + - バックアップと復元のチェックポイントパスが一部の外部ストレージと互換性がない問題を修正[＃55265](https://github.com/pingcap/tidb/issues/55265) @ [Leavrth](https://github.com/Leavrth) - BRを使用してデータを復元する場合、または物理インポート モードでTiDB Lightningを使用してデータをインポートする場合に、PD から取得されたリージョンにLeaderがない問題を修正しました[＃51124](https://github.com/pingcap/tidb/issues/51124) [＃50501](https://github.com/pingcap/tidb/issues/50501) @ [Leavrth](https://github.com/Leavrth) - PDリーダーの転送により、データ[＃53724](https://github.com/pingcap/tidb/issues/53724) @ [Leavrth](https://github.com/Leavrth)の復元時にBRがpanicになる可能性がある問題を修正しました。 - ログバックアップタスクを一時停止、停止、再構築した後、タスクの状態は正常であるが、チェックポイントが[＃53047](https://github.com/pingcap/tidb/issues/53047) @ [RidRisR](https://github.com/RidRisR)に進まない問題を修正しました。 diff --git a/releases/release-7.2.0.md b/releases/release-7.2.0.md index f0da1c8622b51..51496abaf7fbc 100644 --- a/releases/release-7.2.0.md +++ b/releases/release-7.2.0.md @@ -89,7 +89,7 @@ TiDB バージョン: 7.2.0 バージョン7.2.0以降、軽量統計初期化機能が一般提供（GA）となりました。軽量統計初期化機能により、起動時にロードする必要のある統計情報の数を大幅に削減できるため、統計情報のロード速度が向上します。この機能は、複雑な実行環境におけるTiDBの安定性を高め、TiDBノードの再起動時にサービス全体への影響を軽減します。 - v7.2.0以降のバージョンで新規作成されたクラスタの場合、TiDBはデフォルトでTiDB起動時に軽量統計情報をロードし、ロードが完了するまでサービスの提供を待ちます。以前のバージョンからアップグレードしたクラスタの場合は、TiDB構成項目[`lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-new-in-v710)と[`force-init-stats`](/tidb-configuration-file.md#force-init-stats-new-in-v657-and-v710)を`true`に設定することで、この機能を有効にできます。 + v7.2.0以降のバージョンで新規作成されたクラスターの場合、TiDBはデフォルトでTiDB起動時に軽量統計情報をロードし、ロードが完了するまでサービスの提供を待ちます。以前のバージョンからアップグレードしたクラスターの場合は、TiDB構成項目[`lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-new-in-v710)と[`force-init-stats`](/tidb-configuration-file.md#force-init-stats-new-in-v657-and-v710)を`true`に設定することで、この機能を有効にできます。 詳細については、[ドキュメント](/statistics.md#load-statistics)を参照してください。 @@ -158,17 +158,17 @@ TiDB バージョン: 7.2.0 | [`tidb_enable_tiflash_pipeline_model`](https://docs-archive.pingcap.com/tidb/v7.2/system-variables#tidb_enable_tiflash_pipeline_model-new-in-v720) | 新しく追加された | TiFlashの新しい実行モデルで[パイプラインモデル](/tiflash/tiflash-pipeline-model.md)モデルを有効にするかどうかを制御します。デフォルト値は`OFF`で、パイプライン モデルが無効であることを意味します。 | | [`tidb_expensive_txn_time_threshold`](/system-variables.md#tidb_expensive_txn_time_threshold-new-in-v720) | 新しく追加された | 高額トランザクションをログに記録するしきい値を制御します。デフォルト値は600秒です。トランザクションの所要時間がこのしきい値を超え、かつコミットもロールバックもされない場合、そのトランザクションは高額トランザクションとみなされ、ログに記録されます。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイル | 設定パラメータ | 種類を変更する | 説明 | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-new-in-v710) | 修正済み | さらなるテストの結果、デフォルト値が`false`から`true`に変更されました。これは、TiDB の起動時にデフォルトで軽量統計初期化を使用して初期化効率を向上させることを意味します。 | | TiDB | [`force-init-stats`](/tidb-configuration-file.md#force-init-stats-new-in-v657-and-v710) | 修正済み | [`lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-new-in-v710)に合わせて、デフォルト値を`false`から`true`に変更します。これにより、TiDB の起動時に、TiDB は統計情報の初期化が完了するまでサービスの提供を待ちます。 | -| ティクヴ | [`rocksdb.[defaultcf|writecf|lockcf].compaction-guard-min-output-file-size`](/tikv-configuration-file.md#compaction-guard-min-output-file-size) | 修正済み | RocksDB の圧縮タスクのデータ量を削減するために、デフォルト値を`"8MB"`から`"1MB"`に変更します。 | -| ティクヴ | [`rocksdb.[defaultcf|writecf|lockcf].optimize-filters-for-memory`](/tikv-configuration-file.md#optimize-filters-for-memory-new-in-v720) | 新しく追加された | メモリ内部の断片化を最小限に抑えるブルーム/リボンフィルタを生成するかどうかを制御します。 | -| ティクヴ | [`rocksdb.[defaultcf|writecf|lockcf].periodic-compaction-seconds`](/tikv-configuration-file.md#periodic-compaction-seconds-new-in-v720) | 新しく追加された | 定期的な圧縮の間隔を制御します。この値よりも古い更新履歴を持つSSTファイルが圧縮対象として選択され、元のSSTファイルと同じ階層に書き換えられます。 | -| ティクヴ | [`rocksdb.[defaultcf|writecf|lockcf].ribbon-filter-above-level`](/tikv-configuration-file.md#ribbon-filter-above-level-new-in-v720) | 新しく追加された | この値以上のレベルではリボンフィルターを使用し、この値未満のレベルではブロックベースではないブルームフィルターを使用するかどうかを制御します。 | -| ティクヴ | [`rocksdb.[defaultcf|writecf|lockcf].ttl`](/tikv-configuration-file.md#ttl-new-in-v720) | 新しく追加された | TTLよりも古い更新情報を持つSSTファイルは、自動的に圧縮対象として選択されます。 | +| TiKV | [`rocksdb.[defaultcf|writecf|lockcf].compaction-guard-min-output-file-size`](/tikv-configuration-file.md#compaction-guard-min-output-file-size) | 修正済み | RocksDB の圧縮タスクのデータ量を削減するために、デフォルト値を`"8MB"`から`"1MB"`に変更します。 | +| TiKV | [`rocksdb.[defaultcf|writecf|lockcf].optimize-filters-for-memory`](/tikv-configuration-file.md#optimize-filters-for-memory-new-in-v720) | 新しく追加された | メモリ内部の断片化を最小限に抑えるブルーム/リボンフィルタを生成するかどうかを制御します。 | +| TiKV | [`rocksdb.[defaultcf|writecf|lockcf].periodic-compaction-seconds`](/tikv-configuration-file.md#periodic-compaction-seconds-new-in-v720) | 新しく追加された | 定期的な圧縮の間隔を制御します。この値よりも古い更新履歴を持つSSTファイルが圧縮対象として選択され、元のSSTファイルと同じ階層に書き換えられます。 | +| TiKV | [`rocksdb.[defaultcf|writecf|lockcf].ribbon-filter-above-level`](/tikv-configuration-file.md#ribbon-filter-above-level-new-in-v720) | 新しく追加された | この値以上のレベルではリボンフィルターを使用し、この値未満のレベルではブロックベースではないブルームフィルターを使用するかどうかを制御します。 | +| TiKV | [`rocksdb.[defaultcf|writecf|lockcf].ttl`](/tikv-configuration-file.md#ttl-new-in-v720) | 新しく追加された | TTLよりも古い更新情報を持つSSTファイルは、自動的に圧縮対象として選択されます。 | | TiDB Lightning | `send-kv-pairs` | 非推奨 | バージョン7.2.0以降、パラメータ`send-kv-pairs`は非推奨となりました。物理インポートモードでTiKVにデータを送信する際の1リクエストの最大サイズを制御するには、 [`send-kv-size`](/tidb-lightning/tidb-lightning-configuration.md)使用してください。 | | TiDB Lightning | [`character-set`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) | 修正済み | データインポートでサポートされる文字セットに、新しい値オプション`latin1`が追加されました。このオプションを使用すると、Latin-1 文字セットのソースファイルをインポートできます。 | | TiDB Lightning | [`send-kv-size`](/tidb-lightning/tidb-lightning-configuration.md) | 新しく追加された | 物理インポートモードでTiKVにデータを送信する際の、1リクエストあたりの最大サイズを指定します。キーと値のペアのサイズが指定されたしきい値に達すると、 TiDB Lightningは直ちにそれらをTiKVに送信します。これにより、大規模なワイドテーブルをインポートする際に、 TiDB Lightningノードがメモリ内に大量のキーと値のペアを蓄積することによって発生するメモリ不足（OOM）の問題を回避できます。このパラメータを調整することで、メモリ使用量とインポート速度のバランスを取り、インポートプロセスの安定性と効率性を向上させることができます。 | @@ -182,14 +182,14 @@ TiDB バージョン: 7.2.0 - インデックススキャン範囲の構築ロジックを最適化し、複雑な条件をインデックススキャン範囲に変換することをサポートする[#41572](https://github.com/pingcap/tidb/issues/41572) [#44389](https://github.com/pingcap/tidb/issues/44389) @[xuyifangreeneyes](https://github.com/xuyifangreeneyes) - 新しい監視メトリクス`Stale Read OPS`と`Stale Read Traffic`を追加 [#43325](https://github.com/pingcap/tidb/issues/43325) @[you06](https://github.com/you06) - - 古い読み取りの再試行リーダーがロックに遭遇した場合、TiDB はロックを解決した後、リーダーで強制的に再試行します。これにより、不要なオーバーヘッドが回避されます。 [#43659](https://github.com/pingcap/tidb/issues/43659) @[you06](https://github.com/you06) - - 推定時間を使用して古い読み取りtsを計算し、古い読み取りのオーバーヘッドを削減します [#44215](https://github.com/pingcap/tidb/issues/44215) @[you06](https://github.com/you06) + - ステイル読み取りの再試行リーダーがロックに遭遇した場合、TiDB はロックを解決した後、リーダーで強制的に再試行します。これにより、不要なオーバーヘッドが回避されます。 [#43659](https://github.com/pingcap/tidb/issues/43659) @[you06](https://github.com/you06) + - 推定時間を使用してステイル読み取りtsを計算し、ステイル読み取りのオーバーヘッドを削減します [#44215](https://github.com/pingcap/tidb/issues/44215) @[you06](https://github.com/you06) - 長時間実行されるトランザクションのログとシステム変数を追加する [#41471](https://github.com/pingcap/tidb/issues/41471) @[crazycs520](https://github.com/crazycs520) - 圧縮されたMySQLプロトコルを介したTiDBへの接続をサポートします。これにより、低帯域幅ネットワーク下でのデータ集約型クエリのパフォーマンスが向上し、帯域幅コストが削減されます。これは`zlib`と`zstd`ベースの圧縮の両方をサポートします。 [#22605](https://github.com/pingcap/tidb/issues/22605) @[dveeden](https://github.com/dveeden) - `utf8`と`utf8bm3`の両方を従来の 3 バイト UTF-8 文字セットエンコーディングとして認識することで、従来の UTF-8 エンコーディングを持つテーブルを MySQL 8.0 から TiDB に移行しやすくなります。 [#26226](https://github.com/pingcap/tidb/issues/26226) @[dveeden](https://github.com/dveeden) - `:=`ステートメントでの代入に`UPDATE`を使用するサポート [#44751](https://github.com/pingcap/tidb/issues/44751) @[CbcWestwolf](https://github.com/CbcWestwolf) -- ティクヴ +- TiKV - `pd.retry-interval`を使用した接続要求失敗などのシナリオで PD 接続の再試行間隔を設定することをサポートします [#14964](https://github.com/tikv/tikv/issues/14964) @[rleungx](https://github.com/rleungx) - グローバルなリソース使用状況を組み込むことで、リソース制御スケジューリングアルゴリズムを最適化する [#14604](https://github.com/tikv/tikv/issues/14604) @[Connor1996](https://github.com/Connor1996) @@ -210,7 +210,7 @@ TiDB バージョン: 7.2.0 - TiCDC - - オブジェクトstorageサービスへのレプリケーションシナリオでDDL操作が発生した場合に、データファイルが格納されるディレクトリの構造を最適化する [#8891](https://github.com/pingcap/tiflow/issues/8891) @[CharlesCheung96](https://github.com/CharlesCheung96) + - オブジェクトストレージサービスへのレプリケーションシナリオでDDL操作が発生した場合に、データファイルが格納されるディレクトリの構造を最適化する [#8891](https://github.com/pingcap/tiflow/issues/8891) @[CharlesCheung96](https://github.com/CharlesCheung96) - KafkaへのレプリケーションシナリオにおけるOAUTHBEARER認証のサポート [#8865](https://github.com/pingcap/tiflow/issues/8865) @[Rustin170506](https://github.com/Rustin170506) - Kafka [#9143](https://github.com/pingcap/tiflow/issues/9143) @[3AceShowHand](https://github.com/3AceShowHand)ショーハンドにレプリケーションシナリオの`DELETE`オペレーションのハンドルキーのみを出力するオプションを追加 @@ -249,7 +249,7 @@ TiDB バージョン: 7.2.0 - 結合したテーブルの再配置によって不正な外部結合結果が生じる可能性がある問題を修正 [#44314](https://github.com/pingcap/tidb/issues/44314) @[AilinKid](https://github.com/AilinKid) - `PREPARE stmt FROM "ANALYZE TABLE xxx"`が`tidb_mem_quota_query`によって強制終了される可能性がある問題を修正 [#44320](https://github.com/pingcap/tidb/issues/44320) @[chrysan](https://github.com/chrysan) -- ティクヴ +- TiKV - TiKVが古い悲観的ロックの競合を処理する際にトランザクションが誤った値を返す問題を修正 [#13298](https://github.com/tikv/tikv/issues/13298) @[cfzjywxk](https://github.com/cfzjywxk) - インメモリ悲観的ロックがフラッシュバックの失敗やデータの不整合を引き起こす可能性がある問題を修正 [#13303](https://github.com/tikv/tikv/issues/13303) @[JmPotato](https://github.com/JmPotato) diff --git a/releases/release-7.3.0.md b/releases/release-7.3.0.md index fd4cf8a6a7f13..a360e4e853893 100644 --- a/releases/release-7.3.0.md +++ b/releases/release-7.3.0.md @@ -125,7 +125,7 @@ TiDB バージョン: 7.3.0 - バックアップと復元 (BR) - - BR は、完全なデータ復元を実行する前に、空のクラスタのチェックを追加します。デフォルトでは、空でないクラスタへのデータ復元は許可されていません。復元を強制する場合は、 `--filter`オプションを使用して、データを復元する対応するテーブル名を指定できます。 + - BR は、完全なデータ復元を実行する前に、空のクラスターのチェックを追加します。デフォルトでは、空でないクラスターへのデータ復元は許可されていません。復元を強制する場合は、 `--filter`オプションを使用して、データを復元する対応するテーブル名を指定できます。 - TiDB Lightning @@ -149,24 +149,24 @@ TiDB バージョン: 7.3.0 | [`tidb_skip_missing_partition_stats`](/system-variables.md#tidb_skip_missing_partition_stats-new-in-v730) | 新しく追加された | この変数は、パーティション統計情報が欠落している場合にグローバル統計情報を生成するかどうかを制御します。 | | [`tiflash_replica_read`](/system-variables.md#tiflash_replica_read-new-in-v730) | 新しく追加された | クエリがTiFlashエンジンを必要とする場合に、 TiFlashレプリカを選択する戦略を制御します。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイル | 設定パラメータ | 種類を変更する | 説明 | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`enable-32bits-connection-id`](/tidb-configuration-file.md#enable-32bits-connection-id-new-in-v730) | 新しく追加された | 32ビット接続ID機能を有効にするかどうかを制御します。 | | TiDB | [`in-mem-slow-query-recent-num`](/tidb-configuration-file.md#in-mem-slow-query-recent-num-new-in-v730) | 新しく追加された | メモリにキャッシュされる、最近使用された低速クエリの数を制御します。 | | TiDB | [`in-mem-slow-query-topn-num`](/tidb-configuration-file.md#in-mem-slow-query-topn-num-new-in-v730) | 新しく追加された | メモリにキャッシュされる最も遅いクエリの数を制御します。 | -| ティクヴ | [`coprocessor.region-bucket-size`](/tikv-configuration-file.md#region-bucket-size-new-in-v610) | 修正済み | デフォルト値を`96MiB`から`50MiB`に変更します。 | -| ティクヴ | [`raft-engine.format-version`](/tikv-configuration-file.md#format-version-new-in-v630) | 修正済み | パーティション化されたRaft KV ( `storage.engine="partitioned-raft-kv"` ) を使用する場合、リボンフィルタが使用されます。そのため、TiKV はデフォルト値を`2`から`5`に変更します。 | -| ティクヴ | [`raftdb.max-total-wal-size`](/tikv-configuration-file.md#max-total-wal-size-1) | 修正済み | パーティション化されたRaft KV ( `storage.engine="partitioned-raft-kv"` ) を使用する場合、TiKV は WAL の書き込みをスキップします。そのため、TiKV はデフォルト値を`"4GB"`から`1`に変更し、WAL が無効になるようにします。 | -| ティクヴ | [`rocksdb.[defaultcf|writecf|lockcf].compaction-guard-min-output-file-size`](/tikv-configuration-file.md#compaction-guard-min-output-file-size) | 修正済み | デフォルト値を`"1MB"`から`"8MB"`に変更し、大容量データ書き込み時に圧縮速度が書き込み速度に追いつかない問題を解決します。 | -| ティクヴ | [`rocksdb.[defaultcf|writecf|lockcf].format-version`](/tikv-configuration-file.md#format-version-new-in-v620) | 修正済み | パーティション化されたRaft KV ( `storage.engine="partitioned-raft-kv"` ) を使用する場合、リボンフィルタが使用されます。そのため、TiKV はデフォルト値を`2`から`5`に変更します。 | -| ティクヴ | [`rocksdb.lockcf.write-buffer-size`](/tikv-configuration-file.md#write-buffer-size) | 修正済み | パーティション化されたRaft KV ( `storage.engine="partitioned-raft-kv"` ) を使用する場合、lockcf の圧縮を高速化するために、TiKV はデフォルト値を`"32MB"`から`"4MB"`に変更します。 | -| ティクヴ | [`rocksdb.max-total-wal-size`](/tikv-configuration-file.md#max-total-wal-size) | 修正済み | パーティション化されたRaft KV ( `storage.engine="partitioned-raft-kv"` ) を使用する場合、TiKV は WAL の書き込みをスキップします。そのため、TiKV はデフォルト値を`"4GB"`から`1`に変更し、WAL が無効になるようにします。 | -| ティクヴ | [`rocksdb.stats-dump-period`](/tikv-configuration-file.md#stats-dump-period) | 修正済み | パーティション化されたRaft KV ( `storage.engine="partitioned-raft-kv"` ) を使用する場合、冗長なログ印刷を無効にするには、デフォルト値を`"10m"`から`"0"`に変更します。 | -| ティクヴ | [`rocksdb.write-buffer-limit`](/tikv-configuration-file.md#write-buffer-limit-new-in-v660) | 修正済み | memtable のメモリオーバーヘッドを削減するため、 `storage.engine="raft-kv"`の場合、TiKV はデフォルト値をマシンのメモリの 25% から`0`に変更します。これは制限がないことを意味します。パーティション化されたRaft KV ( `storage.engine="partitioned-raft-kv"` ) を使用する場合、TiKV はデフォルト値をマシンのメモリの 25% から 20% に変更します。 | -| ティクヴ | [`storage.block-cache.capacity`](/tikv-configuration-file.md#capacity) | 修正済み | パーティション化されたRaft KV ( `storage.engine="partitioned-raft-kv"` ) を使用する場合、memtable のメモリオーバーヘッドを補償するために、TiKV はデフォルト値をシステムメモリ全体のサイズの 45% から 30% に変更します。 | -| TiFlash | [`storage.format_version`](/tiflash/tiflash-configuration.md) | 修正済み | より小さなファイルをマージすることで物理ファイルの数を削減する新しいDTFileフォーマット`format_version = 5`を導入します。このフォーマットは実験的であり、デフォルトでは有効になっていません。 | +| TiKV | [`coprocessor.region-bucket-size`](/tikv-configuration-file.md#region-bucket-size-new-in-v610) | 修正済み | デフォルト値を`96MiB`から`50MiB`に変更します。 | +| TiKV | [`raft-engine.format-version`](/tikv-configuration-file.md#format-version-new-in-v630) | 修正済み | パーティション化されたRaft KV ( `ストレージ.engine="partitioned-raft-kv"` ) を使用する場合、リボンフィルタが使用されます。そのため、TiKV はデフォルト値を`2`から`5`に変更します。 | +| TiKV | [`raftdb.max-total-wal-size`](/tikv-configuration-file.md#max-total-wal-size-1) | 修正済み | パーティション化されたRaft KV ( `ストレージ.engine="partitioned-raft-kv"` ) を使用する場合、TiKV は WAL の書き込みをスキップします。そのため、TiKV はデフォルト値を`"4GB"`から`1`に変更し、WAL が無効になるようにします。 | +| TiKV | [`rocksdb.[defaultcf|writecf|lockcf].compaction-guard-min-output-file-size`](/tikv-configuration-file.md#compaction-guard-min-output-file-size) | 修正済み | デフォルト値を`"1MB"`から`"8MB"`に変更し、大容量データ書き込み時に圧縮速度が書き込み速度に追いつかない問題を解決します。 | +| TiKV | [`rocksdb.[defaultcf|writecf|lockcf].format-version`](/tikv-configuration-file.md#format-version-new-in-v620) | 修正済み | パーティション化されたRaft KV ( `ストレージ.engine="partitioned-raft-kv"` ) を使用する場合、リボンフィルタが使用されます。そのため、TiKV はデフォルト値を`2`から`5`に変更します。 | +| TiKV | [`rocksdb.lockcf.write-buffer-size`](/tikv-configuration-file.md#write-buffer-size) | 修正済み | パーティション化されたRaft KV ( `ストレージ.engine="partitioned-raft-kv"` ) を使用する場合、lockcf の圧縮を高速化するために、TiKV はデフォルト値を`"32MB"`から`"4MB"`に変更します。 | +| TiKV | [`rocksdb.max-total-wal-size`](/tikv-configuration-file.md#max-total-wal-size) | 修正済み | パーティション化されたRaft KV ( `ストレージ.engine="partitioned-raft-kv"` ) を使用する場合、TiKV は WAL の書き込みをスキップします。そのため、TiKV はデフォルト値を`"4GB"`から`1`に変更し、WAL が無効になるようにします。 | +| TiKV | [`rocksdb.stats-dump-period`](/tikv-configuration-file.md#stats-dump-period) | 修正済み | パーティション化されたRaft KV ( `ストレージ.engine="partitioned-raft-kv"` ) を使用する場合、冗長なログ印刷を無効にするには、デフォルト値を`"10m"`から`"0"`に変更します。 | +| TiKV | [`rocksdb.write-buffer-limit`](/tikv-configuration-file.md#write-buffer-limit-new-in-v660) | 修正済み | memtable のメモリオーバーヘッドを削減するため、 `ストレージ.engine="raft-kv"`の場合、TiKV はデフォルト値をマシンのメモリの 25% から`0`に変更します。これは制限がないことを意味します。パーティション化されたRaft KV ( `ストレージ.engine="partitioned-raft-kv"` ) を使用する場合、TiKV はデフォルト値をマシンのメモリの 25% から 20% に変更します。 | +| TiKV | [`ストレージ.block-cache.capacity`](/tikv-configuration-file.md#capacity) | 修正済み | パーティション化されたRaft KV ( `ストレージ.engine="partitioned-raft-kv"` ) を使用する場合、memtable のメモリオーバーヘッドを補償するために、TiKV はデフォルト値をシステムメモリ全体のサイズの 45% から 30% に変更します。 | +| TiFlash | [`ストレージ.format_version`](/tiflash/tiflash-configuration.md) | 修正済み | より小さなファイルをマージすることで物理ファイルの数を削減する新しいDTFileフォーマット`format_version = 5`を導入します。このフォーマットは実験的であり、デフォルトでは有効になっていません。 | | TiDB Lightning | `tikv-importer.incremental-import` | 削除済み | TiDB Lightning の並列インポート パラメータ。増分インポート パラメータと混同されやすいため、このパラメータは`tikv-importer.parallel-import`に名称変更されました。ユーザーが古いパラメータ名を渡した場合、自動的に新しいパラメータ名に変換されます。 | | TiDB Lightning | `tikv-importer.on-duplicate` | 非推奨 | 論理インポートモードで競合するレコードを挿入しようとしたときに実行するアクションを制御します。v7.3.0 以降、このパラメーターは[`conflict.strategy`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)に置き換えられました。 | | TiDB Lightning | [`conflict.max-record-rows`](/tidb-lightning/tidb-lightning-configuration.md) | 新しく追加された | 競合するデータを処理するための新しい戦略です。 `conflict_records`テーブルの最大行数を制御します。デフォルト値は 100 です。 | @@ -200,7 +200,7 @@ TiDB バージョン: 7.3.0 - ディスクからダンプされたチャンクを読み取るパフォーマンスを最適化 [#45125](https://github.com/pingcap/tidb/issues/45125) @[YangKeao](https://github.com/YangKeao) - Optimizer Fix Controls を使用してインデックス結合の内部テーブルの過大評価問題を最適化する [#44855](https://github.com/pingcap/tidb/issues/44855) @[time-and-fate](https://github.com/time-and-fate) -- ティクヴ +- TiKV - `Max gap of safe-ts`および`Min safe ts region`メトリックを追加し、 `tikv-ctl get-region-read-progress`コマンドを導入して、 resolved-tsおよび safe-ts の状態をより適切に監視および診断します [#15082](https://github.com/tikv/tikv/issues/15082) @[ekexium](https://github.com/ekexium) @@ -212,7 +212,7 @@ TiDB バージョン: 7.3.0 - TiFlash - - 新しい DTFile フォーマット バージョン[`storage.format_version = 5`](/tiflash/tiflash-configuration.md)をサポートして物理ファイルの数を削減します (実験的) [#7595](https://github.com/pingcap/tiflash/issues/7595) @[hongyunyan](https://github.com/hongyunyan) + - 新しい DTFile フォーマット バージョン[`ストレージ.format_version = 5`](/tiflash/tiflash-configuration.md)をサポートして物理ファイルの数を削減します (実験的) [#7595](https://github.com/pingcap/tiflash/issues/7595) @[hongyunyan](https://github.com/hongyunyan) - ツール @@ -254,7 +254,7 @@ TiDB バージョン: 7.3.0 - `tidb_opt_agg_push_down`が有効になっている場合にクエリが間違った結果を返す可能性がある問題を修正 [#44795](https://github.com/pingcap/tidb/issues/44795) @[AilinKid](https://github.com/AilinKid) - `current_date()`を含むクエリがプランキャッシュを使用した場合に発生する誤った結果の問題を修正します [#45086](https://github.com/pingcap/tidb/issues/45086) @[qw4990](https://github.com/qw4990) -- ティクヴ +- TiKV - GC中にデータを読み取ると、まれにTiKVpanicが発生する可能性がある問題を修正しました [#15109](https://github.com/tikv/tikv/issues/15109) @[MyonKeminta](https://github.com/MyonKeminta) @@ -263,8 +263,8 @@ TiDB バージョン: 7.3.0 - PD の再起動によって`default`リソース グループが再初期化される可能性がある問題を修正 [#6787](https://github.com/tikv/pd/issues/6787) @[glorv](https://github.com/glorv) - etcdが既に起動しているがクライアントがまだ接続していない場合に、クライアントを呼び出すとPDがpanicを起こす可能性がある問題を修正しました [#6860](https://github.com/tikv/pd/issues/6860) @[HuSharp](https://github.com/HuSharp) - リージョンの出力`health-check`が、リージョンID [#6560](https://github.com/tikv/pd/issues/6560)を照会して返されるリージョン情報と一致しない問題を修正します。@[JmPotato](https://github.com/JmPotato) - - `unsafe recovery`で失敗した学習者ピアが`auto-detect`モードでは無視される問題を修正 [#6690](https://github.com/tikv/pd/issues/6690) @[v01dstar](https://github.com/v01dstar) - - 配置ルールがルールを満たしていないTiFlash学習者を選択してしまう問題を修正します [#6662](https://github.com/tikv/pd/issues/6662) @[rleungx](https://github.com/rleungx) + - `unsafe recovery`で失敗したラーナーピアが`auto-detect`モードでは無視される問題を修正 [#6690](https://github.com/tikv/pd/issues/6690) @[v01dstar](https://github.com/v01dstar) + - 配置ルールがルールを満たしていないTiFlashラーナーを選択してしまう問題を修正します [#6662](https://github.com/tikv/pd/issues/6662) @[rleungx](https://github.com/rleungx) - ルールチェッカーがピアを選択する際に、不健全なピアを削除できない問題を修正 [#6559](https://github.com/tikv/pd/issues/6559) @[nolouch](https://github.com/nolouch) - TiFlash diff --git a/releases/release-7.4.0.md b/releases/release-7.4.0.md index 31f04157f0766..2938f5398b73c 100644 --- a/releases/release-7.4.0.md +++ b/releases/release-7.4.0.md @@ -13,7 +13,7 @@ TiDB バージョン: 7.4.0 7.4.0 では、次の主な機能と改善が導入されています。 -
カテゴリ特徴説明
信頼性と可用性グローバルソートによるIMPORT INTOおよびADD INDEX操作のパフォーマンスと安定性を向上 (実験的) v7.4.0より前のバージョンでは、 TiDB Distributed eXecution Framework (DXF)を使用したADD INDEXやIMPORT INTOなどのタスクは、局所的かつ部分的なソートを意味しており、最終的にはTiKVが部分的なソートを補うために多くの追加作業を実行することになりました。また、これらのジョブを実行するには、TiDBノードがソート用のローカルディスク領域をTiKVにロードする前に割り当てる必要がありました。
v7.4.0で導入されたグローバルソート機能により、データはTiKVにロードされる前に、グローバルソートのために外部共有storage（このバージョンではS3）に一時的に保存されます。これにより、TiKVが余分なリソースを消費する必要がなくなり、 ADD INDEXやIMPORT INTOなどの操作のパフォーマンスと安定性が大幅に向上します。
バックグラウンドタスクのリソース制御（実験的） v7.1.0では、ワークロード間のリソースおよびstorageアクセスの干渉を軽減するためのリソース制御機能が導入されました。TiDB v7.4.0では、この制御がバックグラウンドタスクにも適用されます。v7.4.0では、自動分析、バックアップとリストア、 TiDB Lightningによるバルクロード、オンラインDDLなどのバックグラウンドタスクによって生成されるリソースをリソース制御が識別し、管理するようになりました。これは最終的にすべてのバックグラウンドタスクに適用されます。
TiFlashは ストレージとコンピューティングの分離とS3 （GA）をサポートしますTiFlash分散storageおよびコンピューティングアーキテクチャと S3 共有storageが一般提供開始:
  • TiFlash のコンピューティングとstorageを分離します。これは、弾力性のある HTAP リソース利用のマイルストーンとなります。
  • 低コストで共有storageを提供できる S3 ベースのstorageエンジンの使用をサポートします。
SQL TiDBはパーティションタイプの管理をサポートv7.4.0 より前では、範囲/リスト パーティション テーブルは、 TRUNCATE 、 EXCHANGE 、 ADD 、 DROP 、 REORGANIZEなどのパーティション管理操作をサポートし、ハッシュ/キー パーティション テーブルは、 ADDやCOALESCEなどのパーティション管理操作をサポートします。

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

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

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

  • パーティションテーブルを非パーティションテーブルに変換する
  • 既存のパーティション化されていないテーブルをパーティション化する
  • 既存のテーブルのパーティションタイプを変更する
MySQL 8.0 互換性: 照合順序utf8mb4_0900_ai_ciサポートMySQL 8.0 の注目すべき変更点の 1 つは、デフォルトの文字セットが utf8mb4 になり、utf8mb4 のデフォルトの照合順序がutf8mb4_0900_ai_ciなったことです。TiDB v7.4.0 でこのサポートが追加されたことで、MySQL 8.0 との互換性が向上し、デフォルトの照合順序を持つ MySQL 8.0 データベースからの移行とレプリケーションがよりスムーズになりました。
DB操作と可観測性IMPORT INTOおよびADD INDEX SQL ステートメントを実行するためのそれぞれの TiDB ノードを指定します (実験的) IMPORT INTOまたはADD INDEX SQL 文を、既存の TiDB ノードの一部、または新規に追加された TiDB ノードに対して実行するかどうかを柔軟に指定できます。このアプローチにより、他の TiDB ノードからのリソース分離が可能になり、業務への影響を防ぎながら、先行する SQL 文の実行に最適なパフォーマンスを確保できます。
## 機能の詳細 {#feature-details} @@ -25,21 +25,21 @@ TiDB バージョン: 7.4.0 詳細については[ドキュメント](/system-variables.md#tidb_service_scope-new-in-v740)参照してください。 -- パーティション化されたRaft KVstorageエンジンの強化 (実験的) [＃11515](https://github.com/tikv/tikv/issues/11515) [＃12842](https://github.com/tikv/tikv/issues/12842) @ [busyjay](https://github.com/busyjay) @ [tonyxuqqi](https://github.com/tonyxuqqi) @ [tabokie](https://github.com/tabokie) @ [bufferflies](https://github.com/bufferflies) @ [5kbpers](https://github.com/5kbpers) @ [SpadeA-Tang](https://github.com/SpadeA-Tang) @ [nolouch](https://github.com/nolouch) +- パーティション化されたRaft KVストレージエンジンの強化 (実験的) [＃11515](https://github.com/tikv/tikv/issues/11515) [＃12842](https://github.com/tikv/tikv/issues/12842) @ [busyjay](https://github.com/busyjay) @ [tonyxuqqi](https://github.com/tonyxuqqi) @ [tabokie](https://github.com/tabokie) @ [bufferflies](https://github.com/bufferflies) @ [5kbpers](https://github.com/5kbpers) @ [SpadeA-Tang](https://github.com/SpadeA-Tang) @ [nolouch](https://github.com/nolouch) - TiDB v6.6.0 では、実験的機能として Partitioned Raft KVstorageエンジンが導入されました。このエンジンは、複数の RocksDB インスタンスを使用して TiKVリージョンデータを格納し、各リージョンのデータは個別の RocksDB インスタンスに独立して格納されます。 + TiDB v6.6.0 では、実験的機能として Partitioned Raft KVストレージエンジンが導入されました。このエンジンは、複数の RocksDB インスタンスを使用して TiKVリージョンデータを格納し、各リージョンのデータは個別の RocksDB インスタンスに独立して格納されます。 - TiDB v7.4.0では、Partitioned Raft KVstorageエンジンの互換性と安定性がさらに向上しました。大規模データテストを通じて、DM、 Dumpling、 TiDB Lightning、TiCDC、 BR、PITRといったTiDBエコシステムツールおよび機能との互換性が確保されています。さらに、Partitioned Raft KVstorageエンジンは、読み取りと書き込みが混在するワークロードにおいてもより安定したパフォーマンスを提供し、特に書き込み負荷の高いシナリオに適しています。さらに、各TiKVノードは8コアCPUをサポートし、8TBのデータstorageと64GBのメモリを搭載できるようになりました。 + TiDB v7.4.0では、Partitioned Raft KVストレージエンジンの互換性と安定性がさらに向上しました。大規模データテストを通じて、DM、 Dumpling、 TiDB Lightning、TiCDC、 BR、PITRといったTiDBエコシステムツールおよび機能との互換性が確保されています。さらに、Partitioned Raft KVストレージエンジンは、読み取りと書き込みが混在するワークロードにおいてもより安定したパフォーマンスを提供し、特に書き込み負荷の高いシナリオに適しています。さらに、各TiKVノードは8コアCPUをサポートし、8TBのデータストレージと64GBのメモリを搭載できるようになりました。 詳細については[ドキュメント](/partitioned-raft-kv.md)参照してください。 -- TiFlashは、分散storageおよびコンピューティングアーキテクチャ（GA）をサポートします[＃6882](https://github.com/pingcap/tiflash/issues/6882) @ [JaySon-Huang](https://github.com/JaySon-Huang) @ [JinheLin](https://github.com/JinheLin) @ [breezewish](https://github.com/breezewish) @ [lidezhu](https://github.com/lidezhu) @ [CalvinNeo](https://github.com/CalvinNeo) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) +- TiFlashは、分散ストレージおよびコンピューティングアーキテクチャ（GA）をサポートします[＃6882](https://github.com/pingcap/tiflash/issues/6882) @ [JaySon-Huang](https://github.com/JaySon-Huang) @ [JinheLin](https://github.com/JinheLin) @ [breezewish](https://github.com/breezewish) @ [lidezhu](https://github.com/lidezhu) @ [CalvinNeo](https://github.com/CalvinNeo) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - v7.0.0では、 TiFlashは実験的機能として、分散storageおよびコンピューティングアーキテクチャを導入しました。一連の改良を経て、v7.4.0以降、 TiFlashの分散storageおよびコンピューティングアーキテクチャがGAとなります。 + v7.0.0では、 TiFlashは実験的機能として、分散ストレージおよびコンピューティングアーキテクチャを導入しました。一連の改良を経て、v7.4.0以降、 TiFlashの分散ストレージおよびコンピューティングアーキテクチャがGAとなります。 - このアーキテクチャでは、 TiFlashノードは2種類（コンピューティングノードと書き込みノード）に分かれており、S3 APIと互換性のあるオブジェクトstorageをサポートします。どちらのノードも、コンピューティング容量またはstorage容量を個別に拡張できます。分散storageおよびコンピューティングアーキテクチャでは、 TiFlashレプリカの作成、データのクエリ、オプティマイザーヒントの指定など、結合storageおよびコンピューティングアーキテクチャと同様にTiFlashを使用できます。 + このアーキテクチャでは、 TiFlashノードは2種類（コンピューティングノードと書き込みノード）に分かれており、S3 APIと互換性のあるオブジェクトストレージをサポートします。どちらのノードも、コンピューティング容量またはストレージ容量を個別に拡張できます。分散ストレージおよびコンピューティングアーキテクチャでは、 TiFlashレプリカの作成、データのクエリ、オプティマイザーヒントの指定など、結合ストレージおよびコンピューティングアーキテクチャと同様にTiFlashを使用できます。 - TiFlash**の分散storageおよびコンピューティングアーキテクチャ**と**結合storageおよびコンピューティングアーキテクチャ**は、同じクラスター内で使用したり、相互に変換したりすることはできません。TiFlashをデプロイする際に、使用するアーキテクチャを設定できます。 + TiFlash**の分散ストレージおよびコンピューティングアーキテクチャ**と**結合ストレージおよびコンピューティングアーキテクチャ**は、同じクラスター内で使用したり、相互に変換したりすることはできません。TiFlashをデプロイする際に、使用するアーキテクチャを設定できます。 詳細については[ドキュメント](/tiflash/tiflash-disaggregated-and-s3.md)参照してください。 @@ -57,9 +57,9 @@ TiDB バージョン: 7.4.0 - クラウドストレージベースのグローバルソート機能を導入して、並列実行における`ADD INDEX`および`IMPORT INTO`タスクのパフォーマンスと安定性を向上します (実験的) [＃45719](https://github.com/pingcap/tidb/issues/45719) @ [wjhuang2016](https://github.com/wjhuang2016) - v7.4.0より前のバージョンでは、Distributed eXecution Framework（DXF）で`ADD INDEX`や`IMPORT INTO`ようなタスクを実行する場合、各TiDBノードは、エンコードされたインデックスKVペアとテーブルデータKVペアのソートのために、かなりの量のローカルディスク領域を割り当てる必要がありました。しかし、グローバルソート機能がないため、処理中に異なるTiDBノード間および各ノード内でデータが重複する可能性があります。その結果、TiKVはこれらのKVペアをstorageエンジンにインポートする際に、常にコンパクション操作を実行する必要があり、 `ADD INDEX`と`IMPORT INTO`のパフォーマンスと安定性に影響を与えます。 + v7.4.0より前のバージョンでは、Distributed eXecution Framework（DXF）で`ADD INDEX`や`IMPORT INTO`ようなタスクを実行する場合、各TiDBノードは、エンコードされたインデックスKVペアとテーブルデータKVペアのソートのために、かなりの量のローカルディスク領域を割り当てる必要がありました。しかし、グローバルソート機能がないため、処理中に異なるTiDBノード間および各ノード内でデータが重複する可能性があります。その結果、TiKVはこれらのKVペアをストレージエンジンにインポートする際に、常にコンパクション操作を実行する必要があり、 `ADD INDEX`と`IMPORT INTO`のパフォーマンスと安定性に影響を与えます。 - v7.4.0では、TiDBに[グローバルソート](/tidb-global-sort.md)の機能が導入されました。エンコードされたデータをローカルに書き込んでソートする代わりに、クラウドstorageに書き込んでグローバルソートを行うようになりました。ソート後、インデックスデータとテーブルデータの両方がTiKVに並列でインポートされるため、パフォーマンスと安定性が向上します。 + v7.4.0では、TiDBに[グローバルソート](/tidb-global-sort.md)の機能が導入されました。エンコードされたデータをローカルに書き込んでソートする代わりに、クラウドストレージに書き込んでグローバルソートを行うようになりました。ソート後、インデックスデータとテーブルデータの両方がTiKVに並列でインポートされるため、パフォーマンスと安定性が向上します。 詳細については[ドキュメント](/tidb-global-sort.md)参照してください。 @@ -87,7 +87,7 @@ TiDB バージョン: 7.4.0 通常、TiKVはリクエストを数ミリ秒という非常に高速に処理します。しかし、TiKVノードがディスクI/Oジッターやネットワークレイテンシーに遭遇すると、リクエスト処理時間が大幅に増加する可能性があります。v7.4.0より前のバージョンでは、TiKVリクエストのタイムアウト制限は固定されており、調整できません。そのため、TiKVノードで問題が発生すると、TiDBは一定時間のタイムアウト応答を待機する必要があり、ジッター発生時のアプリケーションクエリパフォーマンスに顕著な影響が生じます。 - TiDB v7.4.0 では、新しいシステム変数[`tikv_client_read_timeout`](/system-variables.md#tikv_client_read_timeout-new-in-v740)が導入され、クエリで TiDB が TiKV に送信する RPC 読み取り要求のタイムアウトをカスタマイズできるようになりました。つまり、ディスクまたはネットワークの問題により TiKV ノードに送信された要求が遅延した場合、TiDB はより早くタイムアウトし、他の TiKV ノードに要求を再送信できるため、クエリのレイテンシーが短縮されます。すべての TiKV ノードでタイムアウトが発生した場合、TiDB はデフォルトのタイムアウトを使用して再試行します。さらに、クエリでオプティマイザヒント`/*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=N) */`使用して、TiDB が TiKV RPC 読み取り要求を送信するタイムアウトを設定することもできます。この機能強化により、不安定なネットワークやstorage環境に TiDB が柔軟に適応できるようになり、クエリのパフォーマンスが向上し、ユーザーエクスペリエンスが強化されます。 + TiDB v7.4.0 では、新しいシステム変数[`tikv_client_read_timeout`](/system-variables.md#tikv_client_read_timeout-new-in-v740)が導入され、クエリで TiDB が TiKV に送信する RPC 読み取り要求のタイムアウトをカスタマイズできるようになりました。つまり、ディスクまたはネットワークの問題により TiKV ノードに送信された要求が遅延した場合、TiDB はより早くタイムアウトし、他の TiKV ノードに要求を再送信できるため、クエリのレイテンシーが短縮されます。すべての TiKV ノードでタイムアウトが発生した場合、TiDB はデフォルトのタイムアウトを使用して再試行します。さらに、クエリでオプティマイザヒント`/*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=N) */`使用して、TiDB が TiKV RPC 読み取り要求を送信するタイムアウトを設定することもできます。この機能強化により、不安定なネットワークやストレージ環境に TiDB が柔軟に適応できるようになり、クエリのパフォーマンスが向上し、ユーザーエクスペリエンスが強化されます。 詳細については[ドキュメント](/system-variables.md#tikv_client_read_timeout-new-in-v740)参照してください。 @@ -200,7 +200,7 @@ TiDB バージョン: 7.4.0 - `IMPORT INTO`機能を[＃46704](https://github.com/pingcap/tidb/issues/46704)つで[D3ハンター](https://github.com/D3Hunter)強化する - バージョン7.4.0以降では、 `IMPORT INTO`ステートメントに`CLOUD_STORAGE_URI`のオプションを追加することで、インポートのパフォーマンスと安定性を向上させる[グローバルソート](/tidb-global-sort.md)機能（実験的）を有効にすることができます`CLOUD_STORAGE_URI`のオプションでは、エンコードされたデータの保存先となるクラウドstorageのアドレスを指定できます。 + バージョン7.4.0以降では、 `IMPORT INTO`ステートメントに`CLOUD_STORAGE_URI`のオプションを追加することで、インポートのパフォーマンスと安定性を向上させる[グローバルソート](/tidb-global-sort.md)機能（実験的）を有効にすることができます`CLOUD_STORAGE_URI`のオプションでは、エンコードされたデータの保存先となるクラウドストレージのアドレスを指定できます。 さらに、v7.4.0 では、 `IMPORT INTO`機能に次の機能が導入されています。 @@ -227,9 +227,9 @@ TiDB バージョン: 7.4.0 - TiCDC はクレームチェックパターン[＃9153](https://github.com/pingcap/tiflow/issues/9153) @ [3AceShowHand](https://github.com/3AceShowHand)で大きなメッセージの処理を改善します - バージョン7.4.0より前のTiCDCでは、Kafkaの最大メッセージサイズ（ `max.message.bytes` ）を超える大きなメッセージを下流に送信できませんでした。バージョン7.4.0以降では、Kafkaを下流として変更フィードを設定する際に、大きなメッセージを保存する外部storageの場所を指定し、外部storage内の大きなメッセージのアドレスを含む参照メッセージをKafkaに送信できるようになりました。コンシューマーはこの参照メッセージを受信すると、外部storageのアドレスからメッセージの内容を取得できます。 + バージョン7.4.0より前のTiCDCでは、Kafkaの最大メッセージサイズ（ `max.message.bytes` ）を超える大きなメッセージを下流に送信できませんでした。バージョン7.4.0以降では、Kafkaを下流として変更フィードを設定する際に、大きなメッセージを保存する外部ストレージの場所を指定し、外部ストレージ内の大きなメッセージのアドレスを含む参照メッセージをKafkaに送信できるようになりました。コンシューマーはこの参照メッセージを受信すると、外部ストレージのアドレスからメッセージの内容を取得できます。 - 詳細については[ドキュメント](/ticdc/ticdc-sink-to-kafka.md#send-large-messages-to-external-storage)参照してください。 + 詳細については[ドキュメント](/ticdc/ticdc-sink-to-kafka.md#send-large-messages-to-external-ストレージ)参照してください。 ## 互換性の変更 {#compatibility-changes} @@ -241,7 +241,7 @@ TiDB バージョン: 7.4.0 - v7.4.0 以降、TiDB は MySQL 8.0 の必須機能と互換性があり、 `version()` `8.0.11`で始まるバージョンを返します。 -- TiFlash を以前のバージョンから v7.4.0 にアップグレードした後、元のバージョンへのインプレースダウングレードはサポートされません。これは、v7.4 以降、 TiFlash がPageStorage V3 のデータ圧縮ロジックを最適化し、データ圧縮中に発生する読み取りおよび書き込みの増幅を削減しているためです。これにより、基盤となるstorageファイル名の一部が変更されます。 +- TiFlash を以前のバージョンから v7.4.0 にアップグレードした後、元のバージョンへのインプレースダウングレードはサポートされません。これは、v7.4 以降、 TiFlash がPageStorage V3 のデータ圧縮ロジックを最適化し、データ圧縮中に発生する読み取りおよび書き込みの増幅を削減しているためです。これにより、基盤となるストレージファイル名の一部が変更されます。 - TSO タイムスタンプの論理部分を抽出できるように[`TIDB_PARSE_TSO_LOGICAL()`](/functions-and-operators/tidb-functions.md#tidb-specific-functions)関数が追加されました。 @@ -256,7 +256,7 @@ TiDB バージョン: 7.4.0 | `tidb_enable_tiflash_pipeline_model` | 削除済み | この変数は、 TiFlashパイプライン実行モデルを有効にするかどうかを制御するために使用されます。v7.4.0以降では、 TiFlashリソース制御機能を有効にすると、 TiFlashパイプライン実行モデルも自動的に有効になります。 | | [`tidb_enable_non_prepared_plan_cache`](/system-variables.md#tidb_enable_non_prepared_plan_cache) | 修正済み | さらにテストを行った後、デフォルト値を`ON`から`OFF`に変更します。これは、準備されていない実行プラン キャッシュが無効であることを意味します。 | | [`default_collation_for_utf8mb4`](/system-variables.md#default_collation_for_utf8mb4-new-in-v740) | 新しく追加された | `utf8mb4`文字セットのデフォルトの照合順序を制御します。デフォルト値は`utf8mb4_bin`です。 | -| [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) | 新しく追加された | 有効にするクラウドstorageURI を指定します[グローバルソート](/tidb-global-sort.md) 。 | +| [`tidb_cloud_ストレージ_uri`](/system-variables.md#tidb_cloud_ストレージ_uri-new-in-v740) | 新しく追加された | 有効にするクラウドストレージURI を指定します[グローバルソート](/tidb-global-sort.md) 。 | | [`tidb_opt_enable_hash_join`](/system-variables.md#tidb_opt_enable_hash_join-new-in-v656-v712-and-v740) | 新しく追加された | オプティマイザがテーブルに対してハッシュ結合を選択するかどうかを制御します。デフォルトの値は`ON`です。3 に`OFF`すると、他に利用可能な実行プランがない限り、オプティマイザはテーブルのハッシュ結合を選択しません。 | | [`tidb_opt_objective`](/system-variables.md#tidb_opt_objective-new-in-v740) | 新しく追加された | この変数はオプティマイザの目的を制御します。1 `moderate` TiDB v7.4.0 より前のバージョンのデフォルトの動作を維持し、オプティマイザはより多くの情報を使用してより優れた実行プランを生成しようとします。3 `determinate`はより保守的になる傾向があり、実行プランをより安定させます。 | | [`tidb_request_source_type`](/system-variables.md#tidb_request_source_type-new-in-v740) | 新しく追加された | 現在のセッションのタスクタイプを明示的に指定します。タスクタイプは[リソース管理](/tidb-resource-control-ru-groups.md)によって識別および制御されます。例: `SET @@tidb_request_source_type = "background"` 。 | @@ -267,21 +267,21 @@ TiDB バージョン: 7.4.0 | [`tiflash_query_spill_ratio`](/system-variables.md#tiflash_query_spill_ratio-new-in-v740) | 新しく追加された | TiFlash [クエリレベルのスピル](/tiflash/tiflash-spill-disk.md#query-level-spilling)のしきい値を制御します。デフォルト値は`0.7`です。 | | [`tikv_client_read_timeout`](/system-variables.md#tikv_client_read_timeout-new-in-v740) | 新しく追加された | TiDBがクエリ内でTiKV RPC読み取りリクエストを送信する際のタイムアウトを制御します。デフォルト値`0` 、デフォルトのタイムアウト（通常は40秒）が使用されることを示します。 | -### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} +### 設定ファイルのパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | タイプを変更 | 説明 | +| 設定ファイル | 設定パラメータ | タイプを変更 | 説明 | | -------------- | --------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`enable-stats-cache-mem-quota`](/tidb-configuration-file.md#enable-stats-cache-mem-quota-new-in-v610) | 修正済み | デフォルト値は`false`から`true`に変更され、TiDB 統計のキャッシュのメモリ制限がデフォルトで有効になることを意味します。 | | TiKV | [`rocksdb.[defaultcf|writecf|lockcf].periodic-compaction-seconds`](/tikv-configuration-file.md#periodic-compaction-seconds-new-in-v720) | 修正済み | RocksDBの定期的なコンパクションをデフォルトで無効化するため、デフォルト値を`"30d"`から`"0s"`に変更しました。この変更により、TiDBのアップグレード後に大量のコンパクションがトリガーされ、フロントエンドの読み取りおよび書き込みパフォーマンスに影響が出るのを回避できます。 | | TiKV | [`rocksdb.[defaultcf|writecf|lockcf].ttl`](/tikv-configuration-file.md#ttl-new-in-v720) | 修正済み | デフォルト値が`"30d"`から`"0s"`に変更され、SST ファイルは TTL によりデフォルトで圧縮をトリガーしなくなり、フロントエンドの読み取りおよび書き込みパフォーマンスに影響を与えなくなります。 | | TiFlash | [`flash.compact_log_min_gap`](/tiflash/tiflash-configuration.md) | 新しく追加された | 現在のRaftステート マシンによって進められた`applied_index`と最後のディスク スピル時の`applied_index`の差が`compact_log_min_gap`超えると、 TiFlash はTiKV から`CompactLog`コマンドを実行し、データをディスクにスピルします。 | | TiFlash | [`profiles.default.enable_resource_control`](/tiflash/tiflash-configuration.md) | 新しく追加された | TiFlashリソース制御機能を有効にするかどうかを制御します。 | -| TiFlash | [`storage.format_version`](/tiflash/tiflash-configuration.md) | 修正済み | デフォルト値を`4`から`5`に変更します。新しい形式では、小さなファイルを結合することで物理ファイルの数を削減できます。 | +| TiFlash | [`ストレージ.format_version`](/tiflash/tiflash-configuration.md) | 修正済み | デフォルト値を`4`から`5`に変更します。新しい形式では、小さなファイルを結合することで物理ファイルの数を削減できます。 | | TiFlash | [`task_scheduler_active_set_soft_limit`](/tiflash/tiflash-configuration.md#task_scheduler_active_set_soft_limit-new-in-v640) | 修正済み | デフォルト値を`vcpu * 0.25`から`vcpu * 2`に変更します。 | | Dumpling | [`--csv-line-terminator`](/dumpling-overview.md#option-list-of-dumpling) | 新しく追加された | CSVファイルの終端文字を指定します。このオプションは`"\r\n"`と`"\n"`サポートします。デフォルト値は`"\r\n"`で、以前のバージョンと同じです。 | -| TiCDC | [`claim-check-storage-uri`](/ticdc/ticdc-sink-to-kafka.md#send-large-messages-to-external-storage) | 新しく追加された | `large-message-handle-option` `claim-check`に設定する場合、 `claim-check-storage-uri`有効な外部storageアドレスに設定する必要があります。そうでない場合、チェンジフィードの作成時にエラーが発生します。 | +| TiCDC | [`claim-check-ストレージ-uri`](/ticdc/ticdc-sink-to-kafka.md#send-large-messages-to-external-ストレージ) | 新しく追加された | `large-message-handle-option` `claim-check`に設定する場合、 `claim-check-ストレージ-uri`有効な外部ストレージアドレスに設定する必要があります。そうでない場合、チェンジフィードの作成時にエラーが発生します。 | | TiCDC | [`large-message-handle-compression`](/ticdc/ticdc-sink-to-kafka.md#ticdc-data-compression) | 新しく追加された | エンコード中に圧縮を有効にするかどうかを制御します。デフォルト値は空で、無効を意味します。 | -| TiCDC | [`large-message-handle-option`](/ticdc/ticdc-sink-to-kafka.md#send-large-messages-to-external-storage) | 修正済み | この設定項目は新しい値`claim-check`を追加します。これを`claim-check`に設定すると、TiCDC Kafka シンクは、メッセージサイズが制限を超えた場合にメッセージを外部storageに送信することをサポートし、外部storage内のこの大きなメッセージのアドレスを含むメッセージを Kafka に送信します。 | +| TiCDC | [`large-message-handle-option`](/ticdc/ticdc-sink-to-kafka.md#send-large-messages-to-external-ストレージ) | 修正済み | この設定項目は新しい値`claim-check`を追加します。これを`claim-check`に設定すると、TiCDC Kafka シンクは、メッセージサイズが制限を超えた場合にメッセージを外部ストレージに送信することをサポートし、外部ストレージ内のこの大きなメッセージのアドレスを含むメッセージを Kafka に送信します。 | ## 廃止および削除された機能 {#deprecated-and-removed-features} @@ -314,7 +314,7 @@ TiDB バージョン: 7.4.0 - TSO トレース情報を最適化して、TSO 関連の問題の調査を容易にします[＃6856](https://github.com/tikv/pd/pull/6856) @ [tiancaiamao](https://github.com/tiancaiamao) - メモリ使用量を削減するために HTTP クライアント接続の再利用をサポート[＃6913](https://github.com/tikv/pd/issues/6913) @ [nolouch](https://github.com/nolouch) - - バックアップクラスタが切断されたときにPDがクラスタステータスを自動更新する速度を向上[＃6883](https://github.com/tikv/pd/issues/6883) @ [disksing](https://github.com/disksing) + - バックアップクラスターが切断されたときにPDがクラスターステータスを自動更新する速度を向上[＃6883](https://github.com/tikv/pd/issues/6883) @ [disksing](https://github.com/disksing) - リソース制御クライアントの構成取得方法を強化し、最新の構成を動的に取得する[＃7043](https://github.com/tikv/pd/issues/7043) @ [nolouch](https://github.com/nolouch) - TiFlash @@ -329,7 +329,7 @@ TiDB バージョン: 7.4.0 - リージョンリーダーシップの移行が発生すると、PITR ログバックアップの進行のレイテンシーが長くなるという問題を軽減します[＃13638](https://github.com/tikv/tikv/issues/13638) @ [YuJuncen](https://github.com/YuJuncen) - HTTPクライアント[＃46011](https://github.com/pingcap/tidb/issues/46011) @ [Leavrth](https://github.com/Leavrth)で`MaxIdleConns`と`MaxIdleConnsPerHost`パラメータを設定することにより、ログバックアップとPITRリストアタスクの接続再利用のサポートを強化します。 - - PD または外部 S3storageへの接続に失敗した場合のBRのフォールトトレランスを向上[＃42909](https://github.com/pingcap/tidb/issues/42909) @ [Leavrth](https://github.com/Leavrth) + - PD または外部 S3ストレージへの接続に失敗した場合のBRのフォールトトレランスを向上[＃42909](https://github.com/pingcap/tidb/issues/42909) @ [Leavrth](https://github.com/Leavrth) - 新しい復元パラメータ`WaitTiflashReady`を追加します。このパラメータを有効にすると、 TiFlashレプリカが正常に複製された後に復元操作が完了します[＃43828](https://github.com/pingcap/tidb/issues/43828) [＃46302](https://github.com/pingcap/tidb/issues/46302) @ [3pointer](https://github.com/3pointer) - ログバックアップのCPUオーバーヘッドを削減`resolve lock` [＃40759](https://github.com/pingcap/tidb/issues/40759) @ [3pointer](https://github.com/3pointer) @@ -360,7 +360,7 @@ TiDB バージョン: 7.4.0 - `EXCHANGE PARTITION`失敗またはキャンセルされた場合に、パーティションテーブルの制限が元のテーブルに残る問題を修正[＃45920](https://github.com/pingcap/tidb/issues/45920) [＃45791](https://github.com/pingcap/tidb/issues/45791) @ [mjonss](https://github.com/mjonss) - リストパーティションの定義で、 `NULL`と空の文字列[＃45694](https://github.com/pingcap/tidb/issues/45694) @ [mjonss](https://github.com/mjonss)の両方の使用がサポートされていない問題を修正しました。 - パーティション交換[＃46492](https://github.com/pingcap/tidb/issues/46492) @ [mjonss](https://github.com/mjonss)中にパーティション定義に準拠していないデータを検出できない問題を修正 - - `tmp-storage-quota`設定が[＃45161](https://github.com/pingcap/tidb/issues/45161) [＃26806](https://github.com/pingcap/tidb/issues/26806) @ [wshwsh12](https://github.com/wshwsh12)で有効にならない問題を修正 + - `tmp-ストレージ-quota`設定が[＃45161](https://github.com/pingcap/tidb/issues/45161) [＃26806](https://github.com/pingcap/tidb/issues/26806) @ [wshwsh12](https://github.com/wshwsh12)で有効にならない問題を修正 - `WEIGHT_STRING()`関数が照合順序[＃45725](https://github.com/pingcap/tidb/issues/45725) @ [dveeden](https://github.com/dveeden)と一致しない問題を修正 - インデックス結合のエラーによりクエリが停止する可能性がある問題を修正[＃45716](https://github.com/pingcap/tidb/issues/45716) @ [wshwsh12](https://github.com/wshwsh12) - `DATETIME`または`TIMESTAMP`列を数値定数[＃38361](https://github.com/pingcap/tidb/issues/38361) @ [yibin87](https://github.com/yibin87)と比較するときに、MySQL と動作が一致しない問題を修正しました。 @@ -387,8 +387,8 @@ TiDB バージョン: 7.4.0 - `sync_recovery`から`sync` [＃15366](https://github.com/tikv/tikv/issues/15366) @ [nolouch](https://github.com/nolouch)に切り替えた後に QPS が 0 に低下する問題を修正しました - オンラインアンセーフリカバリがタイムアウト[＃15346](https://github.com/tikv/tikv/issues/15346) @ [Connor1996](https://github.com/Connor1996)で中止されない問題を修正 - CpuRecord [＃15304](https://github.com/tikv/tikv/issues/15304) @ [overvenus](https://github.com/overvenus)によって発生する潜在的なメモリリークの問題を修正しました - - バックアップクラスタがダウンし、プライマリクラスタが[＃12914](https://github.com/tikv/tikv/issues/12914) @ [Connor1996](https://github.com/Connor1996)でクエリされたときに`"Error 9002: TiKV server timeout"`発生する問題を修正しました - - プライマリクラスタが[＃12320](https://github.com/tikv/tikv/issues/12320) @ [disksing](https://github.com/disksing)に回復した後に TiKV が再起動するとバックアップ TiKV が停止する問題を修正しました + - バックアップクラスターがダウンし、プライマリクラスターが[＃12914](https://github.com/tikv/tikv/issues/12914) @ [Connor1996](https://github.com/Connor1996)でクエリされたときに`"Error 9002: TiKV server timeout"`発生する問題を修正しました + - プライマリクラスターが[＃12320](https://github.com/tikv/tikv/issues/12320) @ [disksing](https://github.com/disksing)に回復した後に TiKV が再起動するとバックアップ TiKV が停止する問題を修正しました - PD @@ -397,7 +397,7 @@ TiDB バージョン: 7.4.0 - Scatter Peers [＃6962](https://github.com/tikv/pd/issues/6962) @ [bufferflies](https://github.com/bufferflies)でグループが考慮されない問題を修正しました - RU消費量が0未満の場合にPDが[＃6973](https://github.com/tikv/pd/issues/6973) @ [CabinfeverB](https://github.com/CabinfeverB)でクラッシュする問題を修正 - 変更された分離レベルがデフォルトの配置ルール[＃7121](https://github.com/tikv/pd/issues/7121) @ [rleungx](https://github.com/rleungx)に同期されない問題を修正しました - - クラスタが大きい場合、クライアントが定期的に更新される`min-resolved-ts` PD OOMを引き起こす可能性がある問題を修正しました[＃46664](https://github.com/pingcap/tidb/issues/46664) @ [HuSharp](https://github.com/HuSharp) + - クラスターが大きい場合、クライアントが定期的に更新される`min-resolved-ts` PD OOMを引き起こす可能性がある問題を修正しました[＃46664](https://github.com/pingcap/tidb/issues/46664) @ [HuSharp](https://github.com/HuSharp) - TiFlash @@ -438,7 +438,7 @@ TiDB バージョン: 7.4.0 - TiDB Lightningがテーブル`NONCLUSTERED auto_increment`と`AUTO_ID_CACHE=1`インポートした後、データを挿入するとエラーが返される問題を修正しました[＃46100](https://github.com/pingcap/tidb/issues/46100) @ [tiancaiamao](https://github.com/tiancaiamao) - `checksum = "optional"` [＃45382](https://github.com/pingcap/tidb/issues/45382) @ [lyzx2001](https://github.com/lyzx2001)のときにチェックサムがエラーを報告する問題を修正しました - - PDクラスタアドレスが[＃43436](https://github.com/pingcap/tidb/issues/43436) @ [lichunzhu](https://github.com/lichunzhu)に変更されるとデータのインポートが失敗する問題を修正しました + - PDクラスターアドレスが[＃43436](https://github.com/pingcap/tidb/issues/43436) @ [lichunzhu](https://github.com/lichunzhu)に変更されるとデータのインポートが失敗する問題を修正しました ## 寄稿者 {#contributors} diff --git a/releases/release-7.5.0.md b/releases/release-7.5.0.md index 96bbbb2a39135..1eb814dfcc93d 100644 --- a/releases/release-7.5.0.md +++ b/releases/release-7.5.0.md @@ -15,7 +15,7 @@ TiDB 7.5.0は長期サポートリリース（LTS）です。 以前の LTS 7.1.0 と比較して、7.5.0 には[7.2.0-DMR](/releases/release-7.2.0.md) 、 [7.3.0-DMR](/releases/release-7.3.0.md) 、および[7.4.0-DMR](/releases/release-7.4.0.md)でリリースされた新機能、改善点、およびバグ修正が含まれています。7.1.x から 7.5.0 にアップグレードすると、 [TiDB リリースノート PDF](https://docs-download.pingcap.com/pdf/tidb-v7.2-to-v7.5-en-release-notes.pdf)をダウンロードして、2 つの LTS バージョン間のすべてのリリースノートを確認できます。次の表は、7.2.0 から 7.5.0 までのハイライトの一部を示しています。 -
カテゴリ特徴説明
拡張性とパフォーマンス複数のADD INDEXステートメントを並列実行することをサポートするこの機能により、単一のテーブルに対して複数のインデックスを同時に追加するジョブを実行できます。従来は、2つのADD INDEXステートメント（XとY ）を同時に実行するには、Xの実行時間とYの実行時間を合わせた時間が必要でした。この機能により、1つのSQLで2つのインデックスXとYを同時に追加できるため、DDLの実行時間が大幅に短縮されます。特に、テーブルサイズが大きいシナリオでは、社内テストデータによると、パフォーマンスが最大94%向上することが示されています。
信頼性と可用性グローバルソートの最適化（実験的、v7.4.0で導入） TiDB v7.1.0 では 、分散実行フレームワーク (DXF)が導入されました。v7.4 では、このフレームワークを活用するタスク向けにグローバルソートが導入され、データ再編成タスク中に一時的にデータが順不同になることで発生する不要な I/O、CPU、およびメモリの急増を解消します。グローバルソートは、外部共有オブジェクトstorage(この最初のバージョンでは Amazon S3) を利用してジョブ実行中に中間ファイルを保存することで、柔軟性とコスト削減を実現します。ADD ADD INDEXやIMPORT INTOなどの操作は、より高速で、より堅牢で、より安定し、より柔軟になり、実行コストも削減されます。
バックグラウンドタスクのリソース制御（実験的、v7.4.0で導入）バージョン7.1.0では、ワークロード間のリソースおよびstorageアクセス干渉を軽減するために、リソース制御機能が導入されました。TiDB v7.4.0では、この制御がバックグラウンドタスクの優先度にも適用されるようになりました。v7.4.0では、リソース制御により、自動分析、バックアップと復元、 TiDB Lightningによる一括ロード、オンラインDDLなどのバックグラウンドタスクの実行優先度が識別され、管理されるようになりました。今後のリリースでは、この制御は最終的にすべてのバックグラウンドタスクに適用される予定です。
暴走クエリを管理するためのリソース制御（実験的、v7.2.0で導入）リソース制御は、リソース グループごとにワークロードをリソース分離するためのフレームワークですが、各グループ内の個々のクエリが作業にどのように影響するかについては何も規定していません。TiDB v7.2.0 では、「暴走クエリ制御」が導入され、リソース グループごとに TiDB がこれらのクエリをどのように識別して処理するかを制御できるようになりました。必要に応じて、実行時間の長いクエリを終了または制限することができ、クエリは、より汎用性を高めるために、正確な SQL テキスト、SQL ダイジェスト、または実行プラン ダイジェストで識別できます。v7.3.0 では、データベース レベルの SQL ブロック リストと同様に、既知の不正なクエリを事前に監視できるようになりました。
SQL MySQL 8.0との互換性（バージョン7.4.0で導入） MySQL 8.0 では、デフォルトの文字セットは utf8mb4 であり、utf8mb4 のデフォルトの照合照合順序はutf8mb4_0900_ai_ciです。TiDB v7.4.0 でこのサポートが追加されたことで、MySQL 8.0 との互換性が向上し、デフォルトの照合順序を持つ MySQL 8.0 データベースからの移行やレプリケーションがはるかにスムーズになりました。
データベースの運用と可観測性TiDB Lightningの物理インポートモードがIMPORT INTO (GA)でTiDBに統合されましたバージョン7.2.0より前は、ファイルシステムに基づいてデータをインポートするには、 TiDB Lightningをインストールし、その物理インポートモードを使用する必要がありました。現在では、同じ機能がIMPORT INTOステートメントに統合されているため、追加のツールをインストールすることなく、このステートメントを使用してデータを迅速にインポートできます。このステートメントは、並列インポート用の 分散実行フレームワーク（DXF）もサポートしており、大規模なインポート時のインポート効率が向上します。
ADD INDEXおよびIMPORT INTO SQLステートメントを実行するTiDBノードを指定します（GA）。既存のTiDBノードの一部、または新しく追加されたTiDBノードでADD INDEXまたはIMPORT INTO SQLステートメントを実行するかどうかを柔軟に指定できます。このアプローチにより、他のTiDBノードからリソースを分離できるため、業務への影響を防ぎながら、前述のSQLステートメントの実行において最適なパフォーマンスを確保できます。この機能は、バージョン7.5.0で一般提供（GA）されます。
DDLは一時停止および再開操作をサポートします（一般提供）。インデックスの追加は大量のリソースを消費し、オンラインのトラフィックに影響を与える可能性があります。リソースグループでスロットリングしたり、ラベル付きノードに隔離したりした場合でも、緊急時にはこれらのジョブを一時停止する必要が生じる場合があります。TiDBはバージョン7.2.0以降、これらのバックグラウンドジョブを一度にいくつでも一時停止できる機能をネイティブにサポートしており、ジョブのキャンセルと再起動を回避しながら必要なリソースを解放できます。
TiDB DashboardはTiKVのヒーププロファイリングをサポートしています従来、TiKVのメモリ不足（OOM）やメモリ使用量過多の問題に対処するには、インスタンス環境でjeprofを手動で実行してヒーププロファイルを生成する必要がありました。v7.5.0以降、TiKVはヒーププロファイルのリモート処理に対応しました。これにより、ヒーププロファイルのフレームグラフとコールグラフに直接アクセスできるようになりました。この機能は、Goのヒーププロファイリングと同様に、シンプルで使いやすい操作性を提供します。
+
カテゴリ特徴説明
拡張性とパフォーマンス複数のADD INDEXステートメントを並列実行することをサポートするこの機能により、単一のテーブルに対して複数のインデックスを同時に追加するジョブを実行できます。従来は、2つのADD INDEXステートメント（XとY ）を同時に実行するには、Xの実行時間とYの実行時間を合わせた時間が必要でした。この機能により、1つのSQLで2つのインデックスXとYを同時に追加できるため、DDLの実行時間が大幅に短縮されます。特に、テーブルサイズが大きいシナリオでは、社内テストデータによると、パフォーマンスが最大94%向上することが示されています。
信頼性と可用性グローバルソートの最適化（実験的、v7.4.0で導入） TiDB v7.1.0 では 、分散実行フレームワーク (DXF)が導入されました。v7.4 では、このフレームワークを活用するタスク向けにグローバルソートが導入され、データ再編成タスク中に一時的にデータが順不同になることで発生する不要な I/O、CPU、およびメモリの急増を解消します。グローバルソートは、外部共有オブジェクトストレージ(この最初のバージョンでは Amazon S3) を利用してジョブ実行中に中間ファイルを保存することで、柔軟性とコスト削減を実現します。ADD ADD INDEXやIMPORT INTOなどの操作は、より高速で、より堅牢で、より安定し、より柔軟になり、実行コストも削減されます。
バックグラウンドタスクのリソース制御（実験的、v7.4.0で導入）バージョン7.1.0では、ワークロード間のリソースおよびストレージアクセス干渉を軽減するために、リソース制御機能が導入されました。TiDB v7.4.0では、この制御がバックグラウンドタスクの優先度にも適用されるようになりました。v7.4.0では、リソース制御により、自動分析、バックアップと復元、 TiDB Lightningによる一括ロード、オンラインDDLなどのバックグラウンドタスクの実行優先度が識別され、管理されるようになりました。今後のリリースでは、この制御は最終的にすべてのバックグラウンドタスクに適用される予定です。
暴走クエリを管理するためのリソース制御（実験的、v7.2.0で導入）リソース制御は、リソース グループごとにワークロードをリソース分離するためのフレームワークですが、各グループ内の個々のクエリが作業にどのように影響するかについては何も規定していません。TiDB v7.2.0 では、「暴走クエリ制御」が導入され、リソース グループごとに TiDB がこれらのクエリをどのように識別して処理するかを制御できるようになりました。必要に応じて、実行時間の長いクエリを終了または制限することができ、クエリは、より汎用性を高めるために、正確な SQL テキスト、SQL ダイジェスト、または実行プラン ダイジェストで識別できます。v7.3.0 では、データベース レベルの SQL ブロック リストと同様に、既知の不正なクエリを事前に監視できるようになりました。
SQL MySQL 8.0との互換性（バージョン7.4.0で導入） MySQL 8.0 では、デフォルトの文字セットは utf8mb4 であり、utf8mb4 のデフォルトの照合照合順序はutf8mb4_0900_ai_ciです。TiDB v7.4.0 でこのサポートが追加されたことで、MySQL 8.0 との互換性が向上し、デフォルトの照合順序を持つ MySQL 8.0 データベースからの移行やレプリケーションがはるかにスムーズになりました。
データベースの運用と可観測性TiDB Lightningの物理インポートモードがIMPORT INTO (GA)でTiDBに統合されましたバージョン7.2.0より前は、ファイルシステムに基づいてデータをインポートするには、 TiDB Lightningをインストールし、その物理インポートモードを使用する必要がありました。現在では、同じ機能がIMPORT INTOステートメントに統合されているため、追加のツールをインストールすることなく、このステートメントを使用してデータを迅速にインポートできます。このステートメントは、並列インポート用の 分散実行フレームワーク（DXF）もサポートしており、大規模なインポート時のインポート効率が向上します。
ADD INDEXおよびIMPORT INTO SQLステートメントを実行するTiDBノードを指定します（GA）。既存のTiDBノードの一部、または新しく追加されたTiDBノードでADD INDEXまたはIMPORT INTO SQLステートメントを実行するかどうかを柔軟に指定できます。このアプローチにより、他のTiDBノードからリソースを分離できるため、業務への影響を防ぎながら、前述のSQLステートメントの実行において最適なパフォーマンスを確保できます。この機能は、バージョン7.5.0で一般提供（GA）されます。
DDLは一時停止および再開操作をサポートします（一般提供）。インデックスの追加は大量のリソースを消費し、オンラインのトラフィックに影響を与える可能性があります。リソースグループでスロットリングしたり、ラベル付きノードに隔離したりした場合でも、緊急時にはこれらのジョブを一時停止する必要が生じる場合があります。TiDBはバージョン7.2.0以降、これらのバックグラウンドジョブを一度にいくつでも一時停止できる機能をネイティブにサポートしており、ジョブのキャンセルと再起動を回避しながら必要なリソースを解放できます。
TiDB DashboardはTiKVのヒーププロファイリングをサポートしています従来、TiKVのメモリ不足（OOM）やメモリ使用量過多の問題に対処するには、インスタンス環境でjeprofを手動で実行してヒーププロファイルを生成する必要がありました。v7.5.0以降、TiKVはヒーププロファイルのリモート処理に対応しました。これにより、ヒーププロファイルのフレームグラフとコールグラフに直接アクセスできるようになりました。この機能は、Goのヒーププロファイリングと同様に、シンプルで使いやすい操作性を提供します。
## 機能の詳細 {#feature-details} @@ -23,7 +23,7 @@ TiDB 7.5.0は長期サポートリリース（LTS）です。 - 分散実行フレームワーク (DXF) が有効になっている場合に`ADD INDEX`または`IMPORT INTO`タスクを分散実行するために TiDB ノードを指定および分離する機能をサポートする [#46258](https://github.com/pingcap/tidb/issues/46258) @[ywqzzy](https://github.com/ywqzzy) - リソース集約型のクラスタで`ADD INDEX`または`IMPORT INTO`タスクを並列実行すると、大量の TiDB ノード リソースが消費され、クラスタのパフォーマンスが低下する可能性があります。既存のサービスのパフォーマンスへの影響を回避するため、v7.4.0 では、 [TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)の下で各 TiDB ノードのサービス スコープを制御する実験的機能としてシステム変数[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)を導入しました。既存の TiDB ノードを複数選択するか、新しい TiDB ノードの TiDB サービス スコープを設定すると、分散実行される`ADD INDEX`および`IMPORT INTO`タスクは、これらのノードでのみ実行されます。この機能は、v7.5.0 で一般提供 (GA) されます。 + リソース集約型のクラスターで`ADD INDEX`または`IMPORT INTO`タスクを並列実行すると、大量の TiDB ノード リソースが消費され、クラスターのパフォーマンスが低下する可能性があります。既存のサービスのパフォーマンスへの影響を回避するため、v7.4.0 では、 [TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)の下で各 TiDB ノードのサービス スコープを制御する実験的機能としてシステム変数[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)を導入しました。既存の TiDB ノードを複数選択するか、新しい TiDB ノードの TiDB サービス スコープを設定すると、分散実行される`ADD INDEX`および`IMPORT INTO`タスクは、これらのノードでのみ実行されます。この機能は、v7.5.0 で一般提供 (GA) されます。 詳細については、 [ドキュメント](/system-variables.md#tidb_service_scope-new-in-v740)を参照してください。 @@ -31,7 +31,7 @@ TiDB 7.5.0は長期サポートリリース（LTS）です。 - TiDB 分散実行フレームワーク (DXF) が一般提供 (GA) となり、 `ADD INDEX`および`IMPORT INTO`タスクの並列実行におけるパフォーマンスと安定性が向上しました [#45719](https://github.com/pingcap/tidb/issues/45719) @[wjhuang2016](https://github.com/wjhuang2016) - v7.1.0 で導入された DXF が GA になりました。TiDB v7.1.0 より前のバージョンでは、同時に実行できる TiDB ノードは 1 つだけでした。v7.1.0 以降では、DXF の下で複数の TiDB ノードが同じ DDL タスクを並列実行できます。v7.2.0 以降では、DXF は複数の TiDB ノードが同じ`IMPORT INTO`タスクを並列実行することをサポートし、TiDB クラスタのリソースをより有効に活用し、DDL および`IMPORT INTO`タスクのパフォーマンスを大幅に向上させます。さらに、TiDB ノードを増やすことで、これらのタスクのパフォーマンスを線形的に向上させることもできます。 + v7.1.0 で導入された DXF が GA になりました。TiDB v7.1.0 より前のバージョンでは、同時に実行できる TiDB ノードは 1 つだけでした。v7.1.0 以降では、DXF の下で複数の TiDB ノードが同じ DDL タスクを並列実行できます。v7.2.0 以降では、DXF は複数の TiDB ノードが同じ`IMPORT INTO`タスクを並列実行することをサポートし、TiDB クラスターのリソースをより有効に活用し、DDL および`IMPORT INTO`タスクのパフォーマンスを大幅に向上させます。さらに、TiDB ノードを増やすことで、これらのタスクのパフォーマンスを線形的に向上させることもできます。 DXFを使用するには、 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)値を`ON`に設定します。 @@ -117,17 +117,17 @@ TiDB 7.5.0は長期サポートリリース（LTS）です。 | [`tidb_gogc_tuner_max_value`](/system-variables.md#tidb_gogc_tuner_max_value-new-in-v750) | 新しく追加された | GOGCチューナーが調整できるGOGCの最大値を制御します。 | | [`tidb_gogc_tuner_min_value`](/system-variables.md#tidb_gogc_tuner_min_value-new-in-v750) | 新しく追加された | GOGCチューナーが調整できるGOGCの最小値を制御します。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイル | 設定パラメータ | 種類を変更する | 説明 | | -------------- | ---------------------------------------------------------------------------------------------------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`tikv-client.copr-req-timeout`](/tidb-configuration-file.md#copr-req-timeout-new-in-v750) | 新しく追加された | 単一のコプロセッサー要求のタイムアウトを設定します。 | -| ティクヴ | [`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval) | 修正済み | 低速ノード検出の感度を向上させるためにアルゴリズムを最適化した後、デフォルト値を`500ms`から`100ms`に変更します。 | -| ティクヴ | [`raftstore.region-compact-min-redundant-rows`](/tikv-configuration-file.md#region-compact-min-redundant-rows-new-in-v710) | 修正済み | RocksDB の圧縮をトリガーするために必要な冗長 MVCC 行の数を設定します。v7.5.0 以降、この設定項目は`"raft-kv"`storageエンジンに対して有効になります。 | -| ティクヴ | [`raftstore.region-compact-redundant-rows-percent`](/tikv-configuration-file.md#region-compact-redundant-rows-percent-new-in-v710) | 修正済み | RocksDB の圧縮をトリガーするために必要な冗長 MVCC 行の割合を設定します。v7.5.0 以降、この設定項目は`"raft-kv"`storageエンジンに対して有効になります。 | -| ティクヴ | [`raftstore.evict-cache-on-memory-ratio`](/tikv-configuration-file.md#evict-cache-on-memory-ratio-new-in-v750) | 新しく追加された | TiKV のメモリ使用量がシステムで使用可能なメモリの 90% を超え、Raftエントリ キャッシュによって占有されているメモリが使用済みメモリの`evict-cache-on-memory-ratio`を超えると、TiKV はRaftエントリ キャッシュを削除します。 | -| ティクヴ | [`memory.enable-heap-profiling`](/tikv-configuration-file.md#enable-heap-profiling-new-in-v750) | 新しく追加された | TiKVのメモリ使用量を追跡するためにヒーププロファイリングを有効にするかどうかを制御します。 | -| ティクヴ | [`memory.profiling-sample-per-bytes`](/tikv-configuration-file.md#profiling-sample-per-bytes-new-in-v750) | 新しく追加された | ヒーププロファイリングによって毎回サンプリングされるデータ量を指定します。値は2のべき乗に切り上げられます。 | +| TiKV | [`raftstore.inspect-interval`](/tikv-configuration-file.md#inspect-interval) | 修正済み | 低速ノード検出の感度を向上させるためにアルゴリズムを最適化した後、デフォルト値を`500ms`から`100ms`に変更します。 | +| TiKV | [`raftstore.region-compact-min-redundant-rows`](/tikv-configuration-file.md#region-compact-min-redundant-rows-new-in-v710) | 修正済み | RocksDB の圧縮をトリガーするために必要な冗長 MVCC 行の数を設定します。v7.5.0 以降、この設定項目は`"raft-kv"`ストレージエンジンに対して有効になります。 | +| TiKV | [`raftstore.region-compact-redundant-rows-percent`](/tikv-configuration-file.md#region-compact-redundant-rows-percent-new-in-v710) | 修正済み | RocksDB の圧縮をトリガーするために必要な冗長 MVCC 行の割合を設定します。v7.5.0 以降、この設定項目は`"raft-kv"`ストレージエンジンに対して有効になります。 | +| TiKV | [`raftstore.evict-cache-on-memory-ratio`](/tikv-configuration-file.md#evict-cache-on-memory-ratio-new-in-v750) | 新しく追加された | TiKV のメモリ使用量がシステムで使用可能なメモリの 90% を超え、Raftエントリ キャッシュによって占有されているメモリが使用済みメモリの`evict-cache-on-memory-ratio`を超えると、TiKV はRaftエントリ キャッシュを削除します。 | +| TiKV | [`memory.enable-heap-profiling`](/tikv-configuration-file.md#enable-heap-profiling-new-in-v750) | 新しく追加された | TiKVのメモリ使用量を追跡するためにヒーププロファイリングを有効にするかどうかを制御します。 | +| TiKV | [`memory.profiling-sample-per-bytes`](/tikv-configuration-file.md#profiling-sample-per-bytes-new-in-v750) | 新しく追加された | ヒーププロファイリングによって毎回サンプリングされるデータ量を指定します。値は2のべき乗に切り上げられます。 | | BR | [`--ignore-stats`](/br/br-snapshot-manual.md#back-up-statistics) | 新しく追加された | データベース統計情報のバックアップと復元を行うかどうかを制御します。このパラメーター`false`に設定すると、br コマンドラインツールは列、インデックス、およびテーブルの統計情報のバックアップと復元をサポートします。 | | TiCDC | [`case-sensitive`](/ticdc/ticdc-changefeed-config.md) | 修正済み | さらなるテストの結果、デフォルト値が`true`から`false`に変更されました。これは、TiCDC 構成ファイル内のテーブル名とデータベース名がデフォルトで大文字と小文字を区別しないことを意味します。 | | TiCDC | [`sink.dispatchers.partition`](/ticdc/ticdc-changefeed-config.md) | 修正済み | TiCDC が増分データを Kafka パーティションにディスパッチする方法を制御します。v7.5.0 では、明示的に指定された列の値を使用してパーティション番号を計算する新しい値オプション`columns`が導入されました。 | @@ -168,7 +168,7 @@ v7.5.0 以降、次のコンテンツが`TiDB-community-toolkit`[バイナリパ - 配置ポリシーの使用を最適化：ポリシーの範囲をグローバルに設定する機能をサポートし、一般的なシナリオにおける構文サポートを改善します。 [#45384](https://github.com/pingcap/tidb/issues/45384) @[nolouch](https://github.com/nolouch) - `tidb_ddl_enable_fast_reorg`が有効になっている場合のインデックス追加のパフォーマンスを向上させます。内部テストでは、v7.5.0 は v6.5.0 と比較して最大 62.5% パフォーマンスが向上しています。 [#47757](https://github.com/pingcap/tidb/issues/47757) @[tangenta](https://github.com/tangenta) -- ティクヴ +- TiKV - Titanマニフェストファイルを書き込む際にミューテックスを保持しないようにして、他のスレッドへの影響を防ぐ [#15351](https://github.com/tikv/tikv/issues/15351) @[Connor1996](https://github.com/Connor1996) @@ -204,7 +204,7 @@ v7.5.0 以降、次のコンテンツが`TiDB-community-toolkit`[バイナリパ - MySQLの圧縮プロトコルが大量のデータ（>=16M）を処理できない問題を修正[#47152](https://github.com/pingcap/tidb/issues/47152) [#47157](https://github.com/pingcap/tidb/issues/47157) [#47161](https://github.com/pingcap/tidb/issues/47161) @[dveeden](https://github.com/dveeden) - TiDBが`cgroup`で起動されたときに`systemd`のリソース制限を読み取らない問題を修正 [#47442](https://github.com/pingcap/tidb/issues/47442) @[hawkingrei](https://github.com/hawkingrei) -- ティクヴ +- TiKV - 悲観的トランザクションモードでのプリライト要求の再試行が、まれにデータ不整合のリスクを引き起こす可能性がある問題を修正しました [#11187](https://github.com/tikv/tikv/issues/11187) @[MyonKeminta](https://github.com/MyonKeminta) @@ -213,7 +213,7 @@ v7.5.0 以降、次のコンテンツが`TiDB-community-toolkit`[バイナリパ - `evict-leader-scheduler`の設定が失われる可能性がある問題を修正 [#6897](https://github.com/tikv/pd/issues/6897) @[HuSharp](https://github.com/HuSharp) - ストアがオフラインになった後、その統計情報の監視メトリックが削除されない問題を修正します [#7180](https://github.com/tikv/pd/issues/7180) @[rleungx](https://github.com/rleungx) - データレプリケーション自動同期（DR Auto-Sync）モードを採用しているクラスターにおいて、配置ルールの設定が複雑な場合に`canSync` `hasMajority`が正しく計算されない可能性がある問題を修正します [#7201](https://github.com/tikv/pd/issues/7201) @[disksing](https://github.com/disksing) - - ルールチェッカーが配置ルールの設定に従って学習者を追加しない問題を修正 [#7185](https://github.com/tikv/pd/issues/7185) @[nolouch](https://github.com/nolouch) + - ルールチェッカーが配置ルールの設定に従ってラーナーを追加しない問題を修正 [#7185](https://github.com/tikv/pd/issues/7185) @[nolouch](https://github.com/nolouch) - TiDB DashboardがPD `trace`データを正しく読み取れない問題を修正 [#7253](https://github.com/tikv/pd/issues/7253) @[nolouch](https://github.com/nolouch) - 内部的に取得したリージョンが空であるためにPDがpanic可能性がある問題を修正 [#7261](https://github.com/tikv/pd/issues/7261) @[lhy1024](https://github.com/lhy1024) - データレプリケーション自動同期（DR Auto-Sync）モードを採用しているクラスターで`available_stores`が正しく計算されない問題を修正します [#7221](https://github.com/tikv/pd/issues/7221) @[disksing](https://github.com/disksing) @@ -236,7 +236,7 @@ v7.5.0 以降、次のコンテンツが`TiDB-community-toolkit`[バイナリパ - TiCDC - オブジェクトストアシンクへのデータ複製時にNFSディレクトリにアクセスすることで発生するパフォーマンス問題を修正 [#10041](https://github.com/pingcap/tiflow/issues/10041) @[CharlesCheung96](https://github.com/CharlesCheung96) - - `claim-check`が有効な場合にstorageパスのスペルが間違っている問題を修正 [#10036](https://github.com/pingcap/tiflow/issues/10036) @[3AceShowHand](https://github.com/3AceShowHand) + - `claim-check`が有効な場合にストレージパスのスペルが間違っている問題を修正 [#10036](https://github.com/pingcap/tiflow/issues/10036) @[3AceShowHand](https://github.com/3AceShowHand) - TiCDCのスケジューリングのバランスが崩れる場合がある問題を修正 [#9845](https://github.com/pingcap/tiflow/issues/9845) @[3AceShowHand](https://github.com/3AceShowHand) - TiCDCがKafkaへのデータ複製時に停止する可能性がある問題を修正 [#9855](https://github.com/pingcap/tiflow/issues/9855) @[hicqu](https://github.com/hicqu) - 場合によっては TiCDC プロセッサがpanicになる問題を修正[#9849](https://github.com/pingcap/tiflow/issues/9849) [#9915](https://github.com/pingcap/tiflow/issues/9915) @[hicqu](https://github.com/hicqu)@[3AceShowHand](https://github.com/3AceShowHand) diff --git a/releases/release-7.5.1.md b/releases/release-7.5.1.md index a1cbb0d8284af..15b36015674ab 100644 --- a/releases/release-7.5.1.md +++ b/releases/release-7.5.1.md @@ -18,14 +18,14 @@ TiDB バージョン: 7.5.1 - TiKV構成項目[`gc.num-threads`](https://docs.pingcap.com/tidb/v7.5/tikv-configuration-file#num-threads-new-in-v658-and-v751)を導入して、 `enable-compaction-filter`が`false` [＃16101](https://github.com/tikv/tikv/issues/16101) @ [tonyxuqqi](https://github.com/tonyxuqqi)の場合のGCスレッド数を設定します。 - TiCDC Changefeed、次の新しい構成項目が導入されています。 - [`compression`](/ticdc/ticdc-changefeed-config.md) : REDOログファイルの圧縮動作を設定できます[＃10176](https://github.com/pingcap/tiflow/issues/10176) @ [sdojjy](https://github.com/sdojjy) - - [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトstorage[＃10109](https://github.com/pingcap/tiflow/issues/10109) @ [CharlesCheung96](https://github.com/CharlesCheung96)にデータを複製するときに履歴データの自動クリーンアップを設定できます。 + - [`sink.cloud-ストレージ-config`](/ticdc/ticdc-changefeed-config.md) : オブジェクトストレージ[＃10109](https://github.com/pingcap/tiflow/issues/10109) @ [CharlesCheung96](https://github.com/CharlesCheung96)にデータを複製するときに履歴データの自動クリーンアップを設定できます。 - [`consistent.flush-concurrency`](/ticdc/ticdc-changefeed-config.md) : 単一のREDOファイルのアップロードの同時実行を[＃10226](https://github.com/pingcap/tiflow/issues/10226) @ [sdojjy](https://github.com/sdojjy)に設定できます ## 改善点 {#improvements} - TiDB - - DDLスキーマの再ロードプロセス中に`tikv_client_read_timeout`使用して、クラスタ[＃48124](https://github.com/pingcap/tidb/issues/48124) @ [cfzjywxk](https://github.com/cfzjywxk)でのメタリージョンLeaderの読み取り不可の影響を軽減します。 + - DDLスキーマの再ロードプロセス中に`tikv_client_read_timeout`使用して、クラスター[＃48124](https://github.com/pingcap/tidb/issues/48124) @ [cfzjywxk](https://github.com/cfzjywxk)でのメタリージョンLeaderの読み取り不可の影響を軽減します。 - リソース制御に関する可観測性を強化する[＃49318](https://github.com/pingcap/tidb/issues/49318) @ [glorv](https://github.com/glorv) @ [bufferflies](https://github.com/bufferflies) @ [nolouch](https://github.com/nolouch) @@ -76,7 +76,7 @@ TiDB バージョン: 7.5.1 - TiDBダッシュボード[＃10263](https://github.com/pingcap/tiflow/issues/10263) @ [CharlesCheung96](https://github.com/CharlesCheung96)でのTiCDCログの検索をサポート - サポート[チェンジフィードの下流同期ステータスの照会](https://docs.pingcap.com/tidb/v7.5/ticdc-open-api-v2#query-whether-a-specific-replication-task-is-completed)は、TiCDC が受信した上流データの変更が下流システムに完全に同期されているかどうかを判断するのに役立ちます[＃10289](https://github.com/pingcap/tiflow/issues/10289) @ [hongyunyan](https://github.com/hongyunyan) - - 並列処理を[＃10098](https://github.com/pingcap/tiflow/issues/10098) @ [CharlesCheung96](https://github.com/CharlesCheung96)に増やすことで、TiCDC がオブジェクトstorageにデータを複製する際のパフォーマンスが向上します。 + - 並列処理を[＃10098](https://github.com/pingcap/tiflow/issues/10098) @ [CharlesCheung96](https://github.com/CharlesCheung96)に増やすことで、TiCDC がオブジェクトストレージにデータを複製する際のパフォーマンスが向上します。 - TiDB Lightning @@ -201,7 +201,7 @@ TiDB バージョン: 7.5.1 - `ALTER TABLE ... MODIFY COLUMN ... NOT NULL`実行した後にTiFlash がパニックを起こし、null 許容列が[＃8419](https://github.com/pingcap/tiflash/issues/8419) @ [JaySon-Huang](https://github.com/JaySon-Huang)に非 null 許容に変更される問題を修正しました。 - `ColumnRef in (Literal, Func...)` [＃8631](https://github.com/pingcap/tiflash/issues/8631) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger)のようなフィルタリング条件でクエリを実行したときにクエリ結果が正しくない問題を修正しました - `FLASHBACK DATABASE` [＃8450](https://github.com/pingcap/tiflash/issues/8450) @ [JaySon-Huang](https://github.com/JaySon-Huang)を実行した後もTiFlashレプリカのデータがガベージコレクションされる問題を修正しました - - 分散storageおよびコンピューティングアーキテクチャ[＃8519](https://github.com/pingcap/tiflash/issues/8519) @ [JaySon-Huang](https://github.com/JaySon-Huang)で、 TiFlash がオブジェクトstorageデータの GC 所有者を選択できない可能性がある問題を修正しました。 + - 分散ストレージおよびコンピューティングアーキテクチャ[＃8519](https://github.com/pingcap/tiflash/issues/8519) @ [JaySon-Huang](https://github.com/JaySon-Huang)で、 TiFlash がオブジェクトストレージデータの GC 所有者を選択できない可能性がある問題を修正しました。 - 定数文字列パラメータ[＃8604](https://github.com/pingcap/tiflash/issues/8604) @ [windtalker](https://github.com/windtalker)を含む`GREATEST`または`LEAST`関数で発生する可能性のある、ランダムに無効なメモリアクセスの問題を修正しました。 - ポイントインタイムリカバリ（PITR）を実行した後、または`FLASHBACK CLUSTER TO`実行した後にTiFlashレプリカデータが誤って削除され、データ異常[＃8777](https://github.com/pingcap/tiflash/issues/8777) @ [JaySon-Huang](https://github.com/JaySon-Huang)が発生する可能性がある問題を修正しました。 - 結合に非等価条件[＃8791](https://github.com/pingcap/tiflash/issues/8791) @ [windtalker](https://github.com/windtalker)が含まれている場合に、 TiFlash Anti Semi Join が誤った結果を返す可能性がある問題を修正しました。 @@ -216,20 +216,20 @@ TiDB バージョン: 7.5.1 - ログバックアップタスクを停止すると TiDB がクラッシュする問題を修正[＃50839](https://github.com/pingcap/tidb/issues/50839) @ [YuJuncen](https://github.com/YuJuncen) - 古いバージョン[＃49466](https://github.com/pingcap/tidb/issues/49466) @ [3pointer](https://github.com/3pointer)のバックアップからデータを復元するときに`Unsupported collation`エラーが報告される問題を修正しました - タスク初期化中にPDへの接続に失敗すると、ログバックアップタスクは開始できるが正常に動作しない問題を修正[＃16056](https://github.com/tikv/tikv/issues/16056) @ [YuJuncen](https://github.com/YuJuncen) - - BRが外部storageファイル[＃48452](https://github.com/pingcap/tidb/issues/48452) @ [3AceShowHand](https://github.com/3AceShowHand)に対して誤ったURIを生成する問題を修正 + - BRが外部ストレージファイル[＃48452](https://github.com/pingcap/tidb/issues/48452) @ [3AceShowHand](https://github.com/3AceShowHand)に対して誤ったURIを生成する問題を修正 - 同じノード[＃50445](https://github.com/pingcap/tidb/issues/50445) @ [3pointer](https://github.com/3pointer)で TiKV IP アドレスを変更した後にログ バックアップが停止する問題を修正しました - S3 [＃49942](https://github.com/pingcap/tidb/issues/49942) @ [Leavrth](https://github.com/Leavrth)からファイル コンテンツを読み取っているときにエラーが発生した場合にBR が再試行できない問題を修正しました - TiCDC - Syncpoint が有効な場合にエラーが発生し、シンクモジュールが正常に再起動しない問題を修正 ( `enable-sync-point = true` ) [＃10091](https://github.com/pingcap/tiflow/issues/10091) @ [hicqu](https://github.com/hicqu) - - storageシンク[＃10352](https://github.com/pingcap/tiflow/issues/10352) @ [CharlesCheung96](https://github.com/CharlesCheung96)の使用時に、storageサービスによって生成されたファイルシーケンス番号が正しく増加しない可能性がある問題を修正しました。 + - ストレージシンク[＃10352](https://github.com/pingcap/tiflow/issues/10352) @ [CharlesCheung96](https://github.com/CharlesCheung96)の使用時に、ストレージサービスによって生成されたファイルシーケンス番号が正しく増加しない可能性がある問題を修正しました。 - 同期ポイントテーブルが誤って複製される可能性がある問題を修正[＃10576](https://github.com/pingcap/tiflow/issues/10576) @ [asddongmen](https://github.com/asddongmen) - Apache Pulsarをダウンストリーム[＃10602](https://github.com/pingcap/tiflow/issues/10602) @ [asddongmen](https://github.com/asddongmen)として使用すると、OAuth2.0、TLS、mTLSが正しく有効化できない問題を修正 - 複数のチェンジフィード[＃10430](https://github.com/pingcap/tiflow/issues/10430) @ [CharlesCheung96](https://github.com/CharlesCheung96)を同時に作成すると TiCDC が`ErrChangeFeedAlreadyExists`エラーを返す問題を修正しました - 極端なケースでチェンジフィード`resolved ts`が進まない問題を修正[＃10157](https://github.com/pingcap/tiflow/issues/10157) @ [sdojjy](https://github.com/sdojjy) - 特定の特殊なシナリオで TiCDC が TiKV との接続を誤って閉じる問題を修正[＃10239](https://github.com/pingcap/tiflow/issues/10239) @ [hicqu](https://github.com/hicqu) - - オブジェクトstorageサービス[＃10137](https://github.com/pingcap/tiflow/issues/10137) @ [sdojjy](https://github.com/sdojjy)にデータを複製するときに TiCDCサーバーがpanic可能性がある問題を修正しました + - オブジェクトストレージサービス[＃10137](https://github.com/pingcap/tiflow/issues/10137) @ [sdojjy](https://github.com/sdojjy)にデータを複製するときに TiCDCサーバーがpanic可能性がある問題を修正しました - アップストリームテーブル[＃10522](https://github.com/pingcap/tiflow/issues/10522) @ [sdojjy](https://github.com/sdojjy)で`TRUNCATE PARTITION`を実行した後に、changefeed がエラーを報告する問題を修正しました。 - `ignore-event`で`add table partition`イベントをフィルタリングするように設定した後、TiCDC が関連パーティションの他のタイプの DML 変更をダウンストリーム[＃10524](https://github.com/pingcap/tiflow/issues/10524) @ [CharlesCheung96](https://github.com/CharlesCheung96)に複製しない問題を修正しました。 - `kv-client`初期化[＃10095](https://github.com/pingcap/tiflow/issues/10095) @ [3AceShowHand](https://github.com/3AceShowHand)中に発生する可能性のあるデータ競合問題を修正 diff --git a/releases/release-7.5.2.md b/releases/release-7.5.2.md index 4f3e8c36785fb..51e3067a8993a 100644 --- a/releases/release-7.5.2.md +++ b/releases/release-7.5.2.md @@ -34,7 +34,7 @@ TiDB バージョン: 7.5.2 - TiKV - - コプロセッサエラーのログレベルを`warn`から`debug`に調整して、クラスタ[＃15881](https://github.com/tikv/tikv/issues/15881) @ [cfzjywxk](https://github.com/cfzjywxk)の不要なログを削減します。 + - コプロセッサエラーのログレベルを`warn`から`debug`に調整して、クラスター[＃15881](https://github.com/tikv/tikv/issues/15881) @ [cfzjywxk](https://github.com/cfzjywxk)の不要なログを削減します。 - CDC イベント処理のキュー時間の監視メトリックを追加して、下流の CDC イベントレイテンシー問題のトラブルシューティングを容易にします[＃16282](https://github.com/tikv/tikv/issues/16282) @ [hicqu](https://github.com/hicqu) - TiKV の安定性を向上させるために、raftstore スレッドでスナップショット ファイルに対する IO 操作を実行しないようにします[＃16564](https://github.com/tikv/tikv/issues/16564) @ [Connor1996](https://github.com/Connor1996) - ピアのスローログを追加し、メッセージ[＃16600](https://github.com/tikv/tikv/issues/16600) @ [Connor1996](https://github.com/Connor1996)を保存します @@ -61,7 +61,7 @@ TiDB バージョン: 7.5.2 - 大規模なデータセット[＃48301](https://github.com/pingcap/tidb/issues/48301) @ [Leavrth](https://github.com/Leavrth)シナリオで`RESTORE`ステートメントのテーブル作成パフォーマンスを向上 - リストアプロセス中にテーブルIDを事前割り当てすることで、テーブルIDの再利用を最大化し、リストアパフォーマンスを向上します[＃51736](https://github.com/pingcap/tidb/issues/51736) @ [Leavrth](https://github.com/Leavrth) - ログバックアップの開始時にアクティブなDDLジョブの無効な検証を削除します[＃52733](https://github.com/pingcap/tidb/issues/52733) @ [Leavrth](https://github.com/Leavrth) - - Google Cloud Storage（GCS）を外部storageとして使用する場合の古い互換性チェックを削除します[＃50533](https://github.com/pingcap/tidb/issues/50533) @ [lance6716](https://github.com/lance6716) + - Google Cloud Storage（GCS）を外部ストレージとして使用する場合の古い互換性チェックを削除します[＃50533](https://github.com/pingcap/tidb/issues/50533) @ [lance6716](https://github.com/lance6716) - DNSエラーによる失敗の再試行回数を[＃53029](https://github.com/pingcap/tidb/issues/53029)から[ユジュンセン](https://github.com/YuJuncen)増やす - TiCDC @@ -192,17 +192,17 @@ TiDB バージョン: 7.5.2 - TiFlash - - 分散storageおよびコンピューティングアーキテクチャで、DDL操作[＃9084](https://github.com/pingcap/tiflash/issues/9084) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger)で非NULL列を追加した後にクエリでNULL値が誤って返される可能性がある問題を修正しました。 + - 分散ストレージおよびコンピューティングアーキテクチャで、DDL操作[＃9084](https://github.com/pingcap/tiflash/issues/9084) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger)で非NULL列を追加した後にクエリでNULL値が誤って返される可能性がある問題を修正しました。 - 空のパーティション[＃9024](https://github.com/pingcap/tiflash/issues/9024) @ [JinheLin](https://github.com/JinheLin)を含むパーティション テーブルでクエリを実行するときに発生するクエリ タイムアウトの問題を修正しました。 - - 分散storageとコンピューティングアーキテクチャで、コンピューティングノードのプロセスが停止するとTiFlash がpanic可能性がある問題を修正しました[＃8860](https://github.com/pingcap/tiflash/issues/8860) @ [guo-shaoge](https://github.com/guo-shaoge) + - 分散ストレージとコンピューティングアーキテクチャで、コンピューティングノードのプロセスが停止するとTiFlash がpanic可能性がある問題を修正しました[＃8860](https://github.com/pingcap/tiflash/issues/8860) @ [guo-shaoge](https://github.com/guo-shaoge) - 生成された列をクエリするとエラー[＃8787](https://github.com/pingcap/tiflash/issues/8787) @ [guo-shaoge](https://github.com/guo-shaoge)が返される問題を修正しました - - クラスタをv6.5.0より前のバージョンからv6.5.0以降にアップグレードするときに、 TiFlashメタデータが破損してプロセスがpanicになる可能性がある問題を修正しました[＃9039](https://github.com/pingcap/tiflash/issues/9039) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - クラスターをv6.5.0より前のバージョンからv6.5.0以降にアップグレードするときに、 TiFlashメタデータが破損してプロセスがpanicになる可能性がある問題を修正しました[＃9039](https://github.com/pingcap/tiflash/issues/9039) @ [JaySon-Huang](https://github.com/JaySon-Huang) - チャンクエンコード[＃8674](https://github.com/pingcap/tiflash/issues/8674) @ [yibin87](https://github.com/yibin87)中に`ENUM`列目がTiFlashを引き起こす可能性がある問題を修正しました - ログ[＃8895](https://github.com/pingcap/tiflash/issues/8895) @ [JaySon-Huang](https://github.com/JaySon-Huang)の誤った`local_region_num`値を修正 - - 分散storageとコンピューティングアーキテクチャで、シャットダウン[＃8837](https://github.com/pingcap/tiflash/issues/8837) @ [JaySon-Huang](https://github.com/JaySon-Huang)中にTiFlash がpanicになる可能性がある問題を修正しました。 + - 分散ストレージとコンピューティングアーキテクチャで、シャットダウン[＃8837](https://github.com/pingcap/tiflash/issues/8837) @ [JaySon-Huang](https://github.com/JaySon-Huang)中にTiFlash がpanicになる可能性がある問題を修正しました。 - TiFlash が高同時読み取りシナリオで一時的に誤った結果を返す可能性がある問題を修正[＃8845](https://github.com/pingcap/tiflash/issues/8845) @ [JinheLin](https://github.com/JinheLin) - - 分散storageおよびコンピューティングアーキテクチャで、 TiFlashコンピューティングノード[＃8920](https://github.com/pingcap/tiflash/issues/8920) @ [JinheLin](https://github.com/JinheLin)の`storage.remote.cache.capacity`構成項目の値を変更した後、Grafanaに表示されるディスク`used_size`メトリックが正しくないという問題を修正しました。 - - 分散storageおよびコンピューティングアーキテクチャで、ネットワーク分離[＃8806](https://github.com/pingcap/tiflash/issues/8806) @ [JinheLin](https://github.com/JinheLin)後にクエリが永続的にブロックされる可能性がある問題を修正しました + - 分散ストレージおよびコンピューティングアーキテクチャで、 TiFlashコンピューティングノード[＃8920](https://github.com/pingcap/tiflash/issues/8920) @ [JinheLin](https://github.com/JinheLin)の`ストレージ.remote.cache.capacity`構成項目の値を変更した後、Grafanaに表示されるディスク`used_size`メトリックが正しくないという問題を修正しました。 + - 分散ストレージおよびコンピューティングアーキテクチャで、ネットワーク分離[＃8806](https://github.com/pingcap/tiflash/issues/8806) @ [JinheLin](https://github.com/JinheLin)後にクエリが永続的にブロックされる可能性がある問題を修正しました - 非厳密な`sql_mode` [＃8803](https://github.com/pingcap/tiflash/issues/8803) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger)で無効なデフォルト値を持つ列にデータを挿入するとTiFlash がpanic可能性がある問題を修正しました - ツール @@ -229,7 +229,7 @@ TiDB バージョン: 7.5.2 - TiCDC所有者ノードを退去させるAPI（ `/api/v2/owner/resign` ）を呼び出すと、TiCDCタスクが予期せず再起動する問題を修正しました[＃10781](https://github.com/pingcap/tiflow/issues/10781) @ [sdojjy](https://github.com/sdojjy) - DDL文が頻繁に実行されるシナリオで、間違ったBarrierTSが原因でデータが間違ったCSVファイルに書き込まれる問題を修正[＃10668](https://github.com/pingcap/tiflow/issues/10668) @ [lidezhu](https://github.com/lidezhu) - 単一行データのデータ整合性検証が有効にされた後、タイムゾーンの不一致により TiCDC が`TIMESTAMP`種類のチェックサムの検証に失敗する問題を修正[＃10573](https://github.com/pingcap/tiflow/issues/10573) @ [3AceShowHand](https://github.com/3AceShowHand) - - オブジェクトstorageシンクに一時的な障害が発生した場合に、結果整合性が有効になっている変更フィードが失敗する可能性がある問題を修正しました[＃10710](https://github.com/pingcap/tiflow/issues/10710) @ [CharlesCheung96](https://github.com/CharlesCheung96) + - オブジェクトストレージシンクに一時的な障害が発生した場合に、結果整合性が有効になっている変更フィードが失敗する可能性がある問題を修正しました[＃10710](https://github.com/pingcap/tiflow/issues/10710) @ [CharlesCheung96](https://github.com/CharlesCheung96) - `DROP PRIMARY KEY`と`DROP UNIQUE KEY`ステートメントが正しく複製されない問題を修正[＃10890](https://github.com/pingcap/tiflow/issues/10890) @ [asddongmen](https://github.com/asddongmen) - テーブルレプリケーションタスク[＃10613](https://github.com/pingcap/tiflow/issues/10613) @ [CharlesCheung96](https://github.com/CharlesCheung96)をスケジュールするときに TiCDC がパニックになる問題を修正しました - 下流の Pulsar が停止しているときに、changefeed を削除すると通常の TiCDC プロセスが停止し、他の changefeed プロセスも停止するという問題を修正しました[＃10629](https://github.com/pingcap/tiflow/issues/10629) @ [asddongmen](https://github.com/asddongmen) diff --git a/releases/release-7.5.3.md b/releases/release-7.5.3.md index 0323b6908a852..8b62a42541a28 100644 --- a/releases/release-7.5.3.md +++ b/releases/release-7.5.3.md @@ -43,7 +43,7 @@ TiDB バージョン: 7.5.3 - TiCDC - - ダウンストリームがメッセージキュー（MQ）またはクラウドstorageの場合、生のイベントを直接出力することをサポート[＃11211](https://github.com/pingcap/tiflow/issues/11211) @ [CharlesCheung96](https://github.com/CharlesCheung96) + - ダウンストリームがメッセージキュー（MQ）またはクラウドストレージの場合、生のイベントを直接出力することをサポート[＃11211](https://github.com/pingcap/tiflow/issues/11211) @ [CharlesCheung96](https://github.com/CharlesCheung96) ## バグ修正 {#bug-fixes} @@ -78,7 +78,7 @@ TiDB バージョン: 7.5.3 - `ALTER TABLE ... REMOVE PARTITIONING`実行すると[＃53385](https://github.com/pingcap/tidb/issues/53385) @ [mjonss](https://github.com/mjonss)でデータが失われる可能性がある問題を修正 - `?`の引数を含む`CONV`の式を持つ`PREPARE` `EXECUTE`ステートメントを複数回実行すると、誤ったクエリ結果が返される可能性がある問題を修正しました[＃53505](https://github.com/pingcap/tidb/issues/53505) @ [qw4990](https://github.com/qw4990) - `auth_socket`認証プラグイン[＃54031](https://github.com/pingcap/tidb/issues/54031) @ [lcwangchao](https://github.com/lcwangchao)を使用しているときに、TiDB が認証されていないユーザーの接続を拒否できないことがある問題を修正しました。 - - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、古い読み取りのクエリレイテンシーが増加する問題を修正しました。 + - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、ステイル読み取りのクエリレイテンシーが増加する問題を修正しました。 - `STATE`フィールドのうち`size`が定義されていないため、 `INFORMATION_SCHEMA.TIDB_TRX`テーブルの`STATE`フィールドが空になる問題を修正しました[＃53026](https://github.com/pingcap/tidb/issues/53026) @ [cfzjywxk](https://github.com/cfzjywxk) - 自動統計収集中にシステム変数`tidb_enable_async_merge_global_stats`と`tidb_analyze_partition_concurrency`有効にならない問題を修正[＃53972](https://github.com/pingcap/tidb/issues/53972) @ [Rustin170506](https://github.com/Rustin170506) - 列のデフォルト値として`CURRENT_DATE()`使用すると、クエリ結果[＃53746](https://github.com/pingcap/tidb/issues/53746) @ [tangenta](https://github.com/tangenta)が正しくなくなる問題を修正しました diff --git a/releases/release-7.5.4.md b/releases/release-7.5.4.md index 6c0f967d1cbe7..8247179f47751 100644 --- a/releases/release-7.5.4.md +++ b/releases/release-7.5.4.md @@ -54,7 +54,7 @@ TiDB バージョン: 7.5.4 - `UNION`を含むクエリステートメントが誤った結果[＃52985](https://github.com/pingcap/tidb/issues/52985) @ [XuHuaiyu](https://github.com/XuHuaiyu)を返す可能性がある問題を修正しました - SQLが異常中断されたときに`INDEX_HASH_JOIN`正常に終了できない問題を修正[＃54688](https://github.com/pingcap/tidb/issues/54688) @ [wshwsh12](https://github.com/wshwsh12) - `PipelinedWindow`の`Open`メソッドのパラメータをリセットして、 `PipelinedWindow`が`Apply`の子ノードとして使用されたときに、繰り返しの開閉操作[＃53600](https://github.com/pingcap/tidb/issues/53600) @ [XuHuaiyu](https://github.com/XuHuaiyu)によって発生した以前のパラメータ値の再利用により発生する予期しないエラーを修正します。 - - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、古い読み取りのクエリレイテンシーが増加する問題を修正しました。 + - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、ステイル読み取りのクエリレイテンシーが増加する問題を修正しました。 - `Sort`演算子がスピルした後にディスクファイルが削除されず、クエリエラーが発生する可能性がある問題を修正[＃55061](https://github.com/pingcap/tidb/issues/55061) @ [wshwsh12](https://github.com/wshwsh12) - クエリが強制終了された後にエラーではなく誤った結果を返す可能性がある問題を修正[＃50089](https://github.com/pingcap/tidb/issues/50089) @ [D3Hunter](https://github.com/D3Hunter) - DMから複製されたテーブルのインデックスの長さが`max-index-length` [＃55138](https://github.com/pingcap/tidb/issues/55138) @ [lance6716](https://github.com/lance6716)で指定された最大長を超えるとテーブル複製が失敗する問題を修正しました @@ -92,10 +92,10 @@ TiDB バージョン: 7.5.4 - TiFlash - - 分散storageおよびコンピューティングアーキテクチャ[＃9282](https://github.com/pingcap/tiflash/issues/9282) @ [JaySon-Huang](https://github.com/JaySon-Huang)でTiFlash書き込みノードが再起動に失敗する可能性がある問題を修正しました + - 分散ストレージおよびコンピューティングアーキテクチャ[＃9282](https://github.com/pingcap/tiflash/issues/9282) @ [JaySon-Huang](https://github.com/JaySon-Huang)でTiFlash書き込みノードが再起動に失敗する可能性がある問題を修正しました - TiFlashとPD間のネットワークパーティション（ネットワーク切断）により、読み取り要求タイムアウトエラー[＃9243](https://github.com/pingcap/tiflash/issues/9243) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger)が発生する可能性がある問題を修正しました。 - `CAST()`関数を使用して文字列をタイムゾーンまたは無効な文字を含む日付時刻に変換すると、結果が正しくなくなる問題を修正しました[＃8754](https://github.com/pingcap/tiflash/issues/8754) @ [solotzg](https://github.com/solotzg) - - 分散storageおよびコンピューティングアーキテクチャ[＃9298](https://github.com/pingcap/tiflash/issues/9298) @ [JinheLin](https://github.com/JinheLin)で、 TiFlash書き込みノードの読み取りスナップショットがタイムリーにリリースされない問題を修正しました。 + - 分散ストレージおよびコンピューティングアーキテクチャ[＃9298](https://github.com/pingcap/tiflash/issues/9298) @ [JinheLin](https://github.com/JinheLin)で、 TiFlash書き込みノードの読み取りスナップショットがタイムリーにリリースされない問題を修正しました。 - テーブルに無効な文字[＃9461](https://github.com/pingcap/tiflash/issues/9461) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger)を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブル スキーマを解析できない問題を修正しました。 - 遅延マテリアライゼーションが有効になっている場合に一部のクエリでエラーが報告される可能性がある問題を修正[＃9472](https://github.com/pingcap/tiflash/issues/9472) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - データ型を`DECIMAL`型に変換すると、極端なケースで間違ったクエリ結果が返される可能性がある問題を修正しました[＃53892](https://github.com/pingcap/tidb/issues/53892) @ [guo-shaoge](https://github.com/guo-shaoge) @@ -105,7 +105,7 @@ TiDB バージョン: 7.5.4 - バックアップと復元 (BR) - バックアッププロセス中に TiKV が応答しなくなった場合にバックアップタスクが停止する可能性がある問題を修正[＃53480](https://github.com/pingcap/tidb/issues/53480) @ [Leavrth](https://github.com/Leavrth) - - バックアップと復元のチェックポイントパスが一部の外部storageと互換性がない問題を修正[＃55265](https://github.com/pingcap/tidb/issues/55265) @ [Leavrth](https://github.com/Leavrth) + - バックアップと復元のチェックポイントパスが一部の外部ストレージと互換性がない問題を修正[＃55265](https://github.com/pingcap/tidb/issues/55265) @ [Leavrth](https://github.com/Leavrth) - ログバックアップ PITR タスクが失敗して停止した後、そのタスクに関連するセーフポイントが PD [＃17316](https://github.com/tikv/tikv/issues/17316) @ [Leavrth](https://github.com/Leavrth)で適切にクリアされない問題を修正しました。 - ログバックアップが有効になっているときにBRログに機密の資格情報が出力される可能性がある問題を修正[＃55273](https://github.com/pingcap/tidb/issues/55273) @ [RidRisR](https://github.com/RidRisR) - BR統合テストケースが不安定になる問題を修正し、スナップショットまたはログバックアップファイルの破損をシミュレートする新しいテストケースを追加します[＃53835](https://github.com/pingcap/tidb/issues/53835) @ [Leavrth](https://github.com/Leavrth) diff --git a/releases/release-7.5.5.md b/releases/release-7.5.5.md index e80f74ee366f4..c3eb9d83285b2 100644 --- a/releases/release-7.5.5.md +++ b/releases/release-7.5.5.md @@ -32,7 +32,7 @@ TiDB バージョン: 7.5.5 - TLS を有効にした後に証明書を更新することでTiFlash がpanic可能性がある問題を軽減します[＃8535](https://github.com/pingcap/tiflash/issues/8535) @ [windtalker](https://github.com/windtalker) - クラスター化インデックス[＃9529](https://github.com/pingcap/tiflash/issues/9529) @ [JaySon-Huang](https://github.com/JaySon-Huang)を持つテーブルで、バックグラウンドでの古いデータのガベージコレクションの速度が向上しました。 - - 分散storageおよびコンピューティングアーキテクチャ内のTiFlashコンピューティングノードの再試行戦略を最適化して、Amazon S3 [＃9695](https://github.com/pingcap/tiflash/issues/9695) @ [JinheLin](https://github.com/JinheLin)からファイルをダウンロードする際の例外を処理します。 + - 分散ストレージおよびコンピューティングアーキテクチャ内のTiFlashコンピューティングノードの再試行戦略を最適化して、Amazon S3 [＃9695](https://github.com/pingcap/tiflash/issues/9695) @ [JinheLin](https://github.com/JinheLin)からファイルをダウンロードする際の例外を処理します。 - ツール @@ -54,11 +54,11 @@ TiDB バージョン: 7.5.5 - 共通テーブル式 (CTE) に複数のデータ コンシューマーがあり、1 つのコンシューマーがデータを読み取らずに終了した場合に発生する可能性のある無効なメモリアクセスの問題を修正しました[＃55881](https://github.com/pingcap/tidb/issues/55881) @ [windtalker](https://github.com/windtalker) - v6.5からv7.5以降にアップグレードされたクラスターで、既存のTTLタスクが予期せず頻繁に実行される問題を修正[＃56539](https://github.com/pingcap/tidb/issues/56539) @ [lcwangchao](https://github.com/lcwangchao) - `tidb_ttl_job_enable`変数が無効になった後、TTL タスクがキャンセルされない問題を修正[＃57404](https://github.com/pingcap/tidb/issues/57404) @ [YangKeao](https://github.com/YangKeao) - - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、古い読み取りのクエリレイテンシーが増加する問題を修正しました。 + - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、ステイル読み取りのクエリレイテンシーが増加する問題を修正しました。 - stale read が読み取り操作のタイムスタンプを厳密に検証しない問題を修正しました。その結果、TSO と実際の物理時間[＃56809](https://github.com/pingcap/tidb/issues/56809) @ [MyonKeminta](https://github.com/MyonKeminta)の間にオフセットが存在する場合に、トランザクションの一貫性にわずかながら影響する可能性が生じます。 - `IMPORT INTO`ステートメント[＃56476](https://github.com/pingcap/tidb/issues/56476) @ [D3Hunter](https://github.com/D3Hunter)を使用してデータをインポートした後、 `AUTO_INCREMENT`フィールドが正しく設定されない問題を修正しました。 - 2人のDDL所有者が同時に存在する可能性がある問題を修正[＃54689](https://github.com/pingcap/tidb/issues/54689) @ [joccau](https://github.com/joccau) - - storageエンジン[＃56402](https://github.com/pingcap/tidb/issues/56402) @ [YangKeao](https://github.com/YangKeao)としてTiKVが選択されていない場合にTTLが失敗する可能性がある問題を修正 + - ストレージエンジン[＃56402](https://github.com/pingcap/tidb/issues/56402) @ [YangKeao](https://github.com/YangKeao)としてTiKVが選択されていない場合にTTLが失敗する可能性がある問題を修正 - `ADD INDEX` [＃56930](https://github.com/pingcap/tidb/issues/56930) @ [fzzf678](https://github.com/fzzf678)を実行するときに TiDB がインデックスの長さ制限をチェックしない問題を修正しました - TTLタスクをキャンセルした際に、対応するSQLが強制終了されない問題を修正[＃56511](https://github.com/pingcap/tidb/issues/56511) @ [lcwangchao](https://github.com/lcwangchao) - エイリアス[＃56726](https://github.com/pingcap/tidb/issues/56726) @ [hawkingrei](https://github.com/hawkingrei)を持つマルチテーブル`DELETE`ステートメントに対して実行プラン バインディングを作成できない問題を修正しました。 @@ -75,7 +75,7 @@ TiDB バージョン: 7.5.5 - CTE に`ORDER BY` 、 `LIMIT` 、または`SELECT DISTINCT`節が含まれており、別の CTE の再帰部分によって参照されている場合、誤ってインライン化され、実行エラー[＃56603](https://github.com/pingcap/tidb/issues/56603) @ [elsa0520](https://github.com/elsa0520)が発生する可能性がある問題を修正しました。 - `UPDATE`文が`ENUM`型[＃56832](https://github.com/pingcap/tidb/issues/56832) @ [xhebox](https://github.com/xhebox)の値を誤って更新する問題を修正しました - `RECOVER TABLE BY JOB JOB_ID;`実行すると TiDB がpanicを起こす可能性がある問題を修正[＃55113](https://github.com/pingcap/tidb/issues/55113) @ [crazycs520](https://github.com/crazycs520) - - クエリに利用可能なインデックスマージ実行プラン[＃56217](https://github.com/pingcap/tidb/issues/56217) @ [AilinKid](https://github.com/AilinKid)がある場合に`read_from_storage`ヒントが有効にならない可能性がある問題を修正しました + - クエリに利用可能なインデックスマージ実行プラン[＃56217](https://github.com/pingcap/tidb/issues/56217) @ [AilinKid](https://github.com/AilinKid)がある場合に`read_from_ストレージ`ヒントが有効にならない可能性がある問題を修正しました - 異常終了時に`INDEX_HASH_JOIN`アップする可能性がある問題を修正[＃54055](https://github.com/pingcap/tidb/issues/54055) @ [wshwsh12](https://github.com/wshwsh12) - 分散実行フレームワーク (DXF) に関連するシステム テーブルをクエリすると、アップグレードが失敗する可能性がある問題を修正しました[＃49263](https://github.com/pingcap/tidb/issues/49263) @ [D3Hunter](https://github.com/D3Hunter) - DDL内部トランザクションエラー`GC life time is shorter than transaction duration`によりインデックス追加が失敗する問題を修正[＃57043](https://github.com/pingcap/tidb/issues/57043) @ [tangenta](https://github.com/tangenta) @@ -91,7 +91,7 @@ TiDB バージョン: 7.5.5 - `tidb_gogc_tuner_max_value`と`tidb_gogc_tuner_min_value`を設定するときに最大値がnullの場合、誤った警告メッセージが表示される問題を修正しました[＃57889](https://github.com/pingcap/tidb/issues/57889) @ [hawkingrei](https://github.com/hawkingrei) - TiDBの内部コルーチン[＃57798](https://github.com/pingcap/tidb/issues/57798) [＃56053](https://github.com/pingcap/tidb/issues/56053) @ [fishiu](https://github.com/fishiu) @ [tiancaiamao](https://github.com/tiancaiamao)で発生する可能性のあるデータ競合問題を修正しました - 潜在的なセキュリティリスクを防ぐためのアップデート`golang-jwt`と`jwt` [＃57135](https://github.com/pingcap/tidb/issues/57135) @ [hawkingrei](https://github.com/hawkingrei) - - `ALTER TABLE`文[＃57510](https://github.com/pingcap/tidb/issues/57510) @ [mjonss](https://github.com/mjonss)を使用して、クラスタ化インデックスを持つテーブルをパーティションテーブルに変換するときに、同時書き込みによってデータが重複する可能性がある問題を修正しました。 + - `ALTER TABLE`文[＃57510](https://github.com/pingcap/tidb/issues/57510) @ [mjonss](https://github.com/mjonss)を使用して、クラスター化インデックスを持つテーブルをパーティションテーブルに変換するときに、同時書き込みによってデータが重複する可能性がある問題を修正しました。 - TiKV @@ -126,7 +126,7 @@ TiDB バージョン: 7.5.5 - `LPAD()`と`RPAD()`関数が、場合によっては誤った結果を返す問題を修正しました[＃9465](https://github.com/pingcap/tiflash/issues/9465) @ [guo-shaoge](https://github.com/guo-shaoge) - 2番目のパラメータが負の[＃9604](https://github.com/pingcap/tiflash/issues/9604) @ [guo-shaoge](https://github.com/guo-shaoge)の場合に`SUBSTRING()`関数が誤った結果を返す問題を修正しました - テーブルに無効な文字[＃9461](https://github.com/pingcap/tiflash/issues/9461) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger)を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブル スキーマを解析できない問題を修正しました。 - - 分散storageおよびコンピューティングアーキテクチャ[＃9665](https://github.com/pingcap/tiflash/issues/9665) @ [zimulala](https://github.com/zimulala)で新しい列をクエリすると誤った結果が返される可能性がある問題を修正しました + - 分散ストレージおよびコンピューティングアーキテクチャ[＃9665](https://github.com/pingcap/tiflash/issues/9665) @ [zimulala](https://github.com/zimulala)で新しい列をクエリすると誤った結果が返される可能性がある問題を修正しました - ツール @@ -158,7 +158,7 @@ TiDB バージョン: 7.5.5 - TiDB LightningがTiKV [＃56114](https://github.com/pingcap/tidb/issues/56114) @ [fishiu](https://github.com/fishiu)から送信されたサイズ超過のメッセージを受信できない問題を修正しました - 物理インポートモード[＃56814](https://github.com/pingcap/tidb/issues/56814) @ [D3Hunter](https://github.com/D3Hunter)を使用してデータをインポートした後に`AUTO_INCREMENT`値が高すぎる値に設定される問題を修正しました - メタデータ更新中に`Lock wait timeout`エラーが発生した場合にTiDB Lightning が自動的に再試行しない問題を修正しました[＃53042](https://github.com/pingcap/tidb/issues/53042) @ [guoshouyan](https://github.com/guoshouyan) - - 高同時実行シナリオでクラウドstorageからデータをインポートするときにパフォーマンスが低下する問題を修正[＃57413](https://github.com/pingcap/tidb/issues/57413) @ [xuanyu66](https://github.com/xuanyu66) + - 高同時実行シナリオでクラウドストレージからデータをインポートするときにパフォーマンスが低下する問題を修正[＃57413](https://github.com/pingcap/tidb/issues/57413) @ [xuanyu66](https://github.com/xuanyu66) - 多数の Parquet ファイル[＃56104](https://github.com/pingcap/tidb/issues/56104) @ [zeminzhou](https://github.com/zeminzhou)をインポートする際の準備フェーズでTiDB Lightning が長時間停止する可能性がある問題を修正しました - TiDB Lightning [＃58085](https://github.com/pingcap/tidb/issues/58085) @ [lance6716](https://github.com/lance6716)を使用してデータをインポートするときにエラーレポートの出力が切り捨てられる問題を修正しました diff --git a/releases/release-7.5.6.md b/releases/release-7.5.6.md index cc14626da8f3c..b66a47476e05d 100644 --- a/releases/release-7.5.6.md +++ b/releases/release-7.5.6.md @@ -38,7 +38,7 @@ TiDB バージョン: 7.5.6 - バックアップと復元 (BR) - バックアップパフォーマンスを向上させるために、フルバックアップ中のテーブルレベルのチェックサム計算をデフォルトで無効にする（ `--checksum=false` ） [＃56373](https://github.com/pingcap/tidb/issues/56373) @ [Tristan1900](https://github.com/Tristan1900) - - 非完全リストア[＃55087](https://github.com/pingcap/tidb/issues/55087) @ [RidRisR](https://github.com/RidRisR)の場合、ターゲット クラスタに同じ名前のテーブルが含まれているかどうかを確認するチェックを追加します。 + - 非完全リストア[＃55087](https://github.com/pingcap/tidb/issues/55087) @ [RidRisR](https://github.com/RidRisR)の場合、ターゲット クラスターに同じ名前のテーブルが含まれているかどうかを確認するチェックを追加します。 - TiDB Lightning @@ -67,7 +67,7 @@ TiDB バージョン: 7.5.6 - 仮想生成列の依存関係に属性`ON UPDATE`持つ列が含まれている場合、更新された行のデータとそのインデックスデータが不整合になる可能性がある問題を修正しました[＃56829](https://github.com/pingcap/tidb/issues/56829) @ [joechenrh](https://github.com/joechenrh) - TiDBハートビートが失われた場合に TTL ジョブをキャンセルできない問題を修正[＃57784](https://github.com/pingcap/tidb/issues/57784) @ [YangKeao](https://github.com/YangKeao) - パラメータが`Enum` 、または`Set`型の場合、 `Conv()`関数はTiKV [＃51877](https://github.com/pingcap/tidb/issues/51877) @ [yibin87](https://github.com/yibin87)にプッシュダウンされなくなりました`Bit` - - 分散storageおよびコンピューティングアーキテクチャのTiFlashノードを含むクラスターで`ALTER TABLE ... PLACEMENT POLICY ...`実行した後、リージョンピアが誤ってTiFlashコンピューティングノード[＃58633](https://github.com/pingcap/tidb/issues/58633) @ [JaySon-Huang](https://github.com/JaySon-Huang)に追加される可能性がある問題を修正しました。 + - 分散ストレージおよびコンピューティングアーキテクチャのTiFlashノードを含むクラスターで`ALTER TABLE ... PLACEMENT POLICY ...`実行した後、リージョンピアが誤ってTiFlashコンピューティングノード[＃58633](https://github.com/pingcap/tidb/issues/58633) @ [JaySon-Huang](https://github.com/JaySon-Huang)に追加される可能性がある問題を修正しました。 - DDL所有者が[＃52747](https://github.com/pingcap/tidb/issues/52747) @ [D3Hunter](https://github.com/D3Hunter)に変更されるとジョブステータスが上書きされる問題を修正 - ハッシュパーティションテーブルで条件`is null`クエリを実行するとpanic[＃58374](https://github.com/pingcap/tidb/issues/58374) @ [Defined2014](https://github.com/Defined2014)が発生する問題を修正 - 生成された列[＃58475](https://github.com/pingcap/tidb/issues/58475) @ [joechenrh](https://github.com/joechenrh)を含むパーティション テーブルをクエリするときにエラーが発生する問題を修正しました。 @@ -87,7 +87,7 @@ TiDB バージョン: 7.5.6 - GBK/GB18030エンコードデータ[＃17618](https://github.com/tikv/tikv/issues/17618) @ [CbcWestwolf](https://github.com/CbcWestwolf)処理時にエンコードが失敗する可能性がある問題を修正 - 例外[＃18245](https://github.com/tikv/tikv/issues/18245) @ [wlwilliamx](https://github.com/wlwilliamx)が発生したときに CDC 接続でリソース漏洩が発生する可能性がある問題を修正しました - リージョンマージでRaftインデックスの不一致[＃18129](https://github.com/tikv/tikv/issues/18129) @ [glorv](https://github.com/glorv)により TiKV 異常終了が発生する可能性がある問題を修正しました - - 解決済み-TSの監視とログが異常になる可能性がある問題を修正[＃17989](https://github.com/tikv/tikv/issues/17989) @ [ekexium](https://github.com/ekexium) + - resolved-tsの監視とログが異常になる可能性がある問題を修正[＃17989](https://github.com/tikv/tikv/issues/17989) @ [ekexium](https://github.com/ekexium) - Titanコンポーネントとの非互換性によりアップグレードが失敗する問題を修正[＃18263](https://github.com/tikv/tikv/issues/18263) @ [v01dstar](https://github.com/v01dstar) @ [LykxSassinator](https://github.com/LykxSassinator) - PD @@ -109,7 +109,7 @@ TiDB バージョン: 7.5.6 - 特定の状況でTiFlash が予期せず終了したときにエラー スタック トレースを印刷できないことがある問題を修正[＃9902](https://github.com/pingcap/tiflash/issues/9902) @ [JaySon-Huang](https://github.com/JaySon-Huang) - `profiles.default.init_thread_count_scale` `0` [＃9906](https://github.com/pingcap/tiflash/issues/9906) @ [JaySon-Huang](https://github.com/JaySon-Huang)に設定するとTiFlash の起動がブロックされる可能性がある問題を修正しました - クエリに仮想列が含まれており、リモート読み取り[＃9561](https://github.com/pingcap/tiflash/issues/9561) @ [guo-shaoge](https://github.com/guo-shaoge)をトリガーするときに`Not found column`エラーが発生する可能性がある問題を修正しました。 - - 分散storageおよびコンピューティングアーキテクチャで、 TiFlashコンピューティング ノードがリージョンピア[＃9750](https://github.com/pingcap/tiflash/issues/9750) @ [JaySon-Huang](https://github.com/JaySon-Huang)を追加するためのターゲット ノードとして誤って選択される可能性がある問題を修正しました。 + - 分散ストレージおよびコンピューティングアーキテクチャで、 TiFlashコンピューティング ノードがリージョンピア[＃9750](https://github.com/pingcap/tiflash/issues/9750) @ [JaySon-Huang](https://github.com/JaySon-Huang)を追加するためのターゲット ノードとして誤って選択される可能性がある問題を修正しました。 - ツール diff --git a/releases/release-7.5.7.md b/releases/release-7.5.7.md index bdaec067822b0..4924a2682a10a 100644 --- a/releases/release-7.5.7.md +++ b/releases/release-7.5.7.md @@ -28,7 +28,7 @@ TiDB バージョン: 7.5.7 - インデックス追加[＃60925](https://github.com/pingcap/tidb/issues/60925) @ [CbcWestwolf](https://github.com/CbcWestwolf)中の TiKV への書き込み速度を観察するための監視メトリックを追加します。 - DDL実行中のDMLのロックロジックを最適化し、DMLとDDL間のロック競合を軽減することで、一部のシナリオでDDLのパフォーマンスが向上します。ただし、セカンダリインデックスのロック操作が追加されるため、DMLのパフォーマンスがわずかに低下する可能性があります[＃62337](https://github.com/pingcap/tidb/issues/62337) @ [lcwangchao](https://github.com/lcwangchao) - システム変数[`tidb_opt_ordering_index_selectivity_threshold`](/system-variables.md#tidb_opt_ordering_index_selectivity_threshold-new-in-v700) `1`に設定されている場合の動作を改善し、この変数[＃60242](https://github.com/pingcap/tidb/issues/60242) @ [time-and-fate](https://github.com/time-and-fate)の制御機能を強化します。 - - `ANALYZE`文実行後にクラスタ全体の統計を更新することを回避し、実行時間を`ANALYZE` [＃57631](https://github.com/pingcap/tidb/issues/57631) @ [0xPoe](https://github.com/0xPoe)に短縮します。 + - `ANALYZE`文実行後にクラスター全体の統計を更新することを回避し、実行時間を`ANALYZE` [＃57631](https://github.com/pingcap/tidb/issues/57631) @ [0xPoe](https://github.com/0xPoe)に短縮します。 - `NOT NULL`制約を持つ列の定数畳み込みをサポートし、 `IS NULL`評価を`FALSE` [＃62050](https://github.com/pingcap/tidb/issues/62050) @ [hawkingrei](https://github.com/hawkingrei)に畳み込みます。 - オプティマイザは、より多くの種類の`JOIN`操作[＃51700](https://github.com/pingcap/tidb/issues/51700) @ [hawkingrei](https://github.com/hawkingrei)で定数伝播をサポートします。 - DML 操作と DDL 操作の間に大規模なロック競合が存在する場合の一時インデックスのマージのパフォーマンスを向上[＃61433](https://github.com/pingcap/tidb/issues/61433) @ [tangenta](https://github.com/tangenta) @@ -57,7 +57,7 @@ TiDB バージョン: 7.5.7 - TiFlash - ワイドテーブルシナリオにおけるTiFlash OOM リスクの観測可能性を強化[＃10272](https://github.com/pingcap/tiflash/issues/10272) @ [JaySon-Huang](https://github.com/JaySon-Huang) - - storageスナップショットを取得する際の最大再試行回数を増やし、大規模なテーブルのクエリの安定性を向上させます[＃10300](https://github.com/pingcap/tiflash/issues/10300) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - ストレージスナップショットを取得する際の最大再試行回数を増やし、大規模なテーブルのクエリの安定性を向上させます[＃10300](https://github.com/pingcap/tiflash/issues/10300) @ [JaySon-Huang](https://github.com/JaySon-Huang) - ツール @@ -150,7 +150,7 @@ TiDB バージョン: 7.5.7 - TiCDC - - 外部storageをダウンストリーム[＃9162](https://github.com/pingcap/tiflow/issues/9162) @ [asddongmen](https://github.com/asddongmen)として使用すると、チェンジフィードが停止する可能性がある問題を修正しました。 + - 外部ストレージをダウンストリーム[＃9162](https://github.com/pingcap/tiflow/issues/9162) @ [asddongmen](https://github.com/asddongmen)として使用すると、チェンジフィードが停止する可能性がある問題を修正しました。 - レプリケーショントラフィックが下流の Kafka [＃12110](https://github.com/pingcap/tiflow/issues/12110) @ [3AceShowHand](https://github.com/3AceShowHand)のトラフィックしきい値を超えた後に、変更フィードがスタックする可能性がある問題を修正しました。 - `changefeed pause`コマンドで`--overwrite-checkpoint-ts`パラメータを使用すると、変更フィードが[＃12055](https://github.com/pingcap/tiflow/issues/12055) @ [hongyunyan](https://github.com/hongyunyan)で停止する可能性がある問題を修正しました。 - 仮想列を含むテーブルでイベントフィルタ式を評価するとpanicが発生する可能性がある問題を修正[＃12206](https://github.com/pingcap/tiflow/issues/12206) @ [lidezhu](https://github.com/lidezhu) @@ -159,7 +159,7 @@ TiDB バージョン: 7.5.7 - TiDB Lightning - - クラウドstorageから TiDB [＃60224](https://github.com/pingcap/tidb/issues/60224) @ [joechenrh](https://github.com/joechenrh)に Parquet ファイルをインポートするときに、 TiDB Lightning が数時間停止する可能性がある問題を修正しました。 + - クラウドストレージから TiDB [＃60224](https://github.com/pingcap/tidb/issues/60224) @ [joechenrh](https://github.com/joechenrh)に Parquet ファイルをインポートするときに、 TiDB Lightning が数時間停止する可能性がある問題を修正しました。 - TiKVへのRPCリクエストが[＃61326](https://github.com/pingcap/tidb/issues/61326) @ [OliverS929](https://github.com/OliverS929)でタイムアウトするとTiDB Lightningが`context deadline exceeded`エラーを返す問題を修正しました - NGモニタリング diff --git a/releases/release-7.6.0.md b/releases/release-7.6.0.md index 812d244936dd2..50871626f5116 100644 --- a/releases/release-7.6.0.md +++ b/releases/release-7.6.0.md @@ -21,7 +21,7 @@ TiDB バージョン: 7.6.0 - Active PD Follower機能を使用して PD のリージョン情報クエリ サービスのスケーラビリティを強化する (実験的) [#7431](https://github.com/tikv/pd/issues/7431) @[CabinfeverB](https://github.com/CabinfeverB) - リージョン数の多いTiDBクラスタでは、ハートビート処理やタスクスケジューリングに伴うオーバーヘッドが増加するため、PDリーダーのCPU負荷が高くなる可能性があります。クラスタにTiDBインスタンスが多数存在し、リージョン情報へのリクエストが同時に多数発生すると、PDリーダーのCPU負荷はさらに高まり、PDサービスが利用できなくなる恐れがあります。 + リージョン数の多いTiDBクラスターでは、ハートビート処理やタスクスケジューリングに伴うオーバーヘッドが増加するため、PDリーダーのCPU負荷が高くなる可能性があります。クラスターにTiDBインスタンスが多数存在し、リージョン情報へのリクエストが同時に多数発生すると、PDリーダーのCPU負荷はさらに高まり、PDサービスが利用できなくなる恐れがあります。 高可用性を確保するため、TiDB v7.6.0 では、PD のリージョン情報クエリ サービスの拡張性を向上させる Active PD Follower機能をサポートしています。Active PD Follower機能は、システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) `ON`に設定することで有効にできます。この機能を有効にすると、TiDB はリージョン情報要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるようになるため、PD リーダーの CPU 負荷が軽減されます。 @@ -31,14 +31,14 @@ TiDB バージョン: 7.6.0 - BRはスナップショットの復元速度を最大 10 倍向上させます (実験的) [#33937](https://github.com/pingcap/tidb/issues/33937) [#49886](https://github.com/pingcap/tidb/issues/49886) @[3pointer](https://github.com/3pointer) - TiDBクラスタの規模が拡大するにつれて、業務停止時間を最小限に抑えるために、障害発生時にクラスタを迅速に復旧することがますます重要になります。v7.6.0より前は、リージョン分散アルゴリズムがパフォーマンス復旧における主要なボトルネックとなっていました。v7.6.0では、 BRがリージョン分散アルゴリズムを最適化し、復旧タスクを多数の小さなタスクに迅速に分割し、バッチ処理で全てのTiKVノードに分散させます。新しい並列リカバリアルゴリズムは、各TiKVノードのリソースを最大限に活用し、高速な並列リカバリを実現します。実際の運用事例では、大規模なリージョン環境において、クラスタのスナップショット復旧速度が約10倍向上しています。 + TiDBクラスターの規模が拡大するにつれて、業務停止時間を最小限に抑えるために、障害発生時にクラスターを迅速に復旧することがますます重要になります。v7.6.0より前は、リージョン分散アルゴリズムがパフォーマンス復旧における主要なボトルネックとなっていました。v7.6.0では、 BRがリージョン分散アルゴリズムを最適化し、復旧タスクを多数の小さなタスクに迅速に分割し、バッチ処理で全てのTiKVノードに分散させます。新しい並列リカバリアルゴリズムは、各TiKVノードのリソースを最大限に活用し、高速な並列リカバリを実現します。実際の運用事例では、大規模なリージョン環境において、クラスターのスナップショット復旧速度が約10倍向上しています。 新しい粗粒度リージョン散布アルゴリズムは実験的です。これを使用するには、 `--granularity="coarse-grained"`コマンドの`br`パラメータを設定します。例: ```bash br restore full \ --pd "${PDIP}:2379" \ - --storage "s3://${Bucket}/${Folder}" \ + --ストレージ "s3://${Bucket}/${Folder}" \ --s3.region "${region}" \ --granularity "coarse-grained" \ --send-credentials-to-tikv=true \ @@ -51,9 +51,9 @@ TiDB バージョン: 7.6.0 TiDB v7.6.0以降では、特にJSONをサポートするTiDBワイドテーブル書き込みシナリオをより適切にサポートするために、Titanエンジンがデフォルトで有効になっています。Titanエンジンは、RocksDBのLSMツリーから32KBを超える大きな値を自動的に分離し、Titanに個別に保存することで、大きな値の処理を最適化します。Titanエンジンは、TiKVで使用されているRocksDBの機能と完全に互換性があります。この戦略的な変更により、書き込み増幅効果が軽減されるだけでなく、大きな値を含む書き込み、更新、およびポイントクエリのシナリオにおけるパフォーマンスも向上します。さらに、レンジスキャンシナリオでは、Titanエンジンの最適化により、デフォルト構成のRocksDBと同等のパフォーマンスを実現しています。 - この構成変更は、以前のバージョンとの互換性を維持しています。既存のTiDBクラスタの場合、TiDB v7.6.0以降のバージョンにアップグレードすると、Titanエンジンはデフォルトで無効になります。お客様の特定の要件に基づいて、Titanエンジンを手動で有効または無効にすることができます。 + この構成変更は、以前のバージョンとの互換性を維持しています。既存のTiDBクラスターの場合、TiDB v7.6.0以降のバージョンにアップグレードすると、Titanエンジンはデフォルトで無効になります。お客様の特定の要件に基づいて、Titanエンジンを手動で有効または無効にすることができます。 - 詳細については、[ドキュメント](/storage-engine/titan-overview.md)を参照してください。 + 詳細については、[ドキュメント](/ストレージ-engine/titan-overview.md)を参照してください。 - 以下の文字列関数をTiKVにプッシュダウンするサポート [#48170](https://github.com/pingcap/tidb/issues/48170) @[gengliqi](https://github.com/gengliqi) @@ -113,10 +113,10 @@ TiDB バージョン: 7.6.0 - プロキシコンポーネントTiProxyのサポート（実験的） [#413](https://github.com/pingcap/tiproxy/issues/413) @[djshow832](https://github.com/djshow832) [xhebox](https://github.com/xhebox) - TiProxyはTiDBの公式プロキシコンポーネントであり、クライアントとTiDBサーバーの間に配置されます。TiProxyはTiDBの負荷分散と接続維持関数を提供し、TiDBクラスタのワークロードをよりバランス良く分散させ、メンテナンス作業中もデータベースへのユーザーアクセスに影響を与えないようにします。 + TiProxyはTiDBの公式プロキシコンポーネントであり、クライアントとTiDBサーバーの間に配置されます。TiProxyはTiDBの負荷分散と接続維持関数を提供し、TiDBクラスターのワークロードをよりバランス良く分散させ、メンテナンス作業中もデータベースへのユーザーアクセスに影響を与えないようにします。 - - TiDBクラスタにおけるローリング再起動、ローリングアップグレード、スケールインなどのメンテナンス作業中、TiDBサーバーに変更が発生すると、クライアントとTiDBサーバー間の接続が中断されます。TiProxyを使用することで、これらのメンテナンス作業中に接続を他のTiDBサーバーにスムーズに移行できるため、クライアントへの影響を最小限に抑えることができます。 - - TiDBサーバーへのクライアント接続を、他のTiDBサーバーに動的に移行することはできません。複数のTiDBサーバーのワークロードが不均衡になると、クラスタ全体のリソースは十分であっても、特定のTiDBサーバーでリソース枯渇が発生し、レイテンシーが大幅に増加する可能性があります。この問題を解決するために、TiProxyは接続の動的移行機能を提供します。これにより、クライアントに影響を与えることなく、接続をあるTiDBサーバーから別のTiDBサーバーに移行できるため、TiDBクラスタの負荷分散が実現されます。 + - TiDBクラスターにおけるローリング再起動、ローリングアップグレード、スケールインなどのメンテナンス作業中、TiDBサーバーに変更が発生すると、クライアントとTiDBサーバー間の接続が中断されます。TiProxyを使用することで、これらのメンテナンス作業中に接続を他のTiDBサーバーにスムーズに移行できるため、クライアントへの影響を最小限に抑えることができます。 + - TiDBサーバーへのクライアント接続を、他のTiDBサーバーに動的に移行することはできません。複数のTiDBサーバーのワークロードが不均衡になると、クラスター全体のリソースは十分であっても、特定のTiDBサーバーでリソース枯渇が発生し、レイテンシーが大幅に増加する可能性があります。この問題を解決するために、TiProxyは接続の動的移行機能を提供します。これにより、クライアントに影響を与えることなく、接続をあるTiDBサーバーから別のTiDBサーバーに移行できるため、TiDBクラスターの負荷分散が実現されます。 TiProxyはTiUP、 TiDB Operator、およびTiDB Dashboardに統合されているため、設定、デプロイ、およびメンテナンスが容易です。 @@ -136,7 +136,7 @@ TiDB バージョン: 7.6.0 - `FLASHBACK CLUSTER`は、正確な TSO [#48372](https://github.com/pingcap/tidb/issues/48372) @ [ボーンチェンジャー](https://github.com/BornChanger/BornChanger)の指定をサポートしています - TiDB v7.6.0 では、フラッシュバック機能がより強力かつ正確になりました。クラスタを指定した履歴タイムスタンプにロールバックできるだけでなく、 `FLASHBACK CLUSTER TO TSO`を使用して正確なリカバリ[TSO](/tso.md)指定できるため、データリカバリの柔軟性が向上します。たとえば、この機能を TiCDC と組み合わせて使用​​できます。ダウンストリームの TiDB クラスタでデータレプリケーションを一時停止し、オンライン前の読み書きテストを実行した後、この機能を使用すると、クラスタは一時停止した TSO にスムーズかつ迅速にロールバックし、TiCDC を使用してデータのレプリケーションを再開できます。これにより、オンライン前の検証プロセスが効率化され、データ管理が簡素化されます。 + TiDB v7.6.0 では、フラッシュバック機能がより強力かつ正確になりました。クラスターを指定した履歴タイムスタンプにロールバックできるだけでなく、 `FLASHBACK CLUSTER TO TSO`を使用して正確なリカバリ[TSO](/tso.md)指定できるため、データリカバリの柔軟性が向上します。たとえば、この機能を TiCDC と組み合わせて使用​​できます。ダウンストリームの TiDB クラスターでデータレプリケーションを一時停止し、オンライン前の読み書きテストを実行した後、この機能を使用すると、クラスターは一時停止した TSO にスムーズかつ迅速にロールバックし、TiCDC を使用してデータのレプリケーションを再開できます。これにより、オンライン前の検証プロセスが効率化され、データ管理が簡素化されます。 ```sql FLASHBACK CLUSTER TO TSO 445494839813079041; @@ -200,7 +200,7 @@ TiDB バージョン: 7.6.0 - TiCDCは双方向レプリケーション（BDR）モードでのDDLステートメントのレプリケーションをサポートします（実験的） [#10301](https://github.com/pingcap/tiflow/issues/10301) [#48519](https://github.com/pingcap/tidb/issues/48519) [okJiang](https://github.com/okJiang) [asddongmen](https://github.com/asddongmen) - バージョン7.6.0以降、TiCDCは双方向レプリケーションが構成されたDDLステートメントのレプリケーションをサポートします。以前は、TiCDCはDDLステートメントのレプリケーションをサポートしていなかったため、TiCDCの双方向レプリケーションを使用するユーザーは、DDLステートメントを両方のTiDBクラスタに個別に適用する必要がありました。この機能により、TiCDCはクラスタに`PRIMARY` BDRロールを割り当てることができ、そのクラスタからダウンストリームクラスタへのDDLステートメントのレプリケーションが可能になります。 + バージョン7.6.0以降、TiCDCは双方向レプリケーションが構成されたDDLステートメントのレプリケーションをサポートします。以前は、TiCDCはDDLステートメントのレプリケーションをサポートしていなかったため、TiCDCの双方向レプリケーションを使用するユーザーは、DDLステートメントを両方のTiDBクラスターに個別に適用する必要がありました。この機能により、TiCDCはクラスターに`PRIMARY` BDRロールを割り当てることができ、そのクラスターからダウンストリームクラスターへのDDLステートメントのレプリケーションが可能になります。 詳細については、 [ドキュメント](/ticdc/ticdc-bidirectional-replication.md)を参照してください。 @@ -231,7 +231,7 @@ TiDB バージョン: 7.6.0 | 変数名 | 種類を変更する | 説明 | | ------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`tidb_auto_analyze_partition_batch_size`](/system-variables.md#tidb_auto_analyze_partition_batch_size-new-in-v640) | 修正済み | さらなるテストの結果、デフォルト値を`1`から`128`に変更します。 | -| [`tidb_sysproc_scan_concurrency`](/system-variables.md#tidb_sysproc_scan_concurrency-new-in-v650) | 修正済み | 大規模クラスタでは、 `scan`操作の同時実行数を`ANALYZE`のニーズに合わせて高く調整できます。したがって、最大値を`256`から`4294967295`に変更します。 | +| [`tidb_sysproc_scan_concurrency`](/system-variables.md#tidb_sysproc_scan_concurrency-new-in-v650) | 修正済み | 大規模クラスターでは、 `scan`操作の同時実行数を`ANALYZE`のニーズに合わせて高く調整できます。したがって、最大値を`256`から`4294967295`に変更します。 | | [`tidb_analyze_distsql_scan_concurrency`](/system-variables.md#tidb_analyze_distsql_scan_concurrency-new-in-v760) | 新しく追加された | `scan`操作を実行する際の`ANALYZE`操作の同時実行数を設定します。デフォルト値は`4`です。 | | [`tidb_ddl_version`](https://docs-archive.pingcap.com/tidb/v7.6/system-variables/#tidb_ddl_version-new-in-v760) | 新しく追加された | [TiDB DDL V2](https://docs-archive.pingcap.com/tidb/v7.6/ddl-v2/)を有効にするかどうかを制御します。有効にするには`2`に、無効にするには`1`に値を設定します。デフォルト値は`1`です。TiDB DDL V2 が有効になっている場合、DDL ステートメントは TiDB DDL V2 を使用して実行されます。テーブルを作成する DDL ステートメントの実行速度は、TiDB DDL V1 と比較して 10 倍向上します。 | | [`tidb_enable_global_index`](/system-variables.md#tidb_enable_global_index-new-in-v760) | 新しく追加された | パーティションテーブルに対して`Global indexes`を作成するかどうかを制御します。デフォルト値は`OFF`です。 `Global index`は現在開発段階です。**このシステム変数の値を変更することは推奨されません**。 | @@ -241,27 +241,27 @@ TiDB バージョン: 7.6.0 | [`tidb_txn_entry_size_limit`](/system-variables.md#tidb_txn_entry_size_limit-new-in-v760) | 新しく追加された | TiDB 構成項目[`performance.txn-entry-size-limit`](/tidb-configuration-file.md#txn-entry-size-limit-new-in-v4010-and-v500)を動的に変更します。これは、TiDB 内の単一行のデータのサイズを制限します。この変数のデフォルト値は`0`です。これは、TiDB がデフォルトで構成項目`txn-entry-size-limit`の値を使用することを意味します。この変数がゼロ以外の値に設定されている場合、 `txn-entry-size-limit`も同じ値に設定されます。 | | [`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) | 新しく追加された | 有効にするかどうかを制御します[アクティブなPDFollower](/tune-region-performance.md#use-the-active-pd-follower-feature-to-enhance-the-scalability-of-pds-region-information-query-service)機能 (実験的)。値が`OFF`の場合、TiDB は PD リーダーからのみリージョン情報を取得します。値が`ON`の場合、TiDB はリージョン情報の要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるため、PD リーダーの CPU 負荷が軽減されます。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイル | 設定パラメータ | 種類を変更する | 説明 | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`tls-version`](/tidb-configuration-file.md#tls-version) | 修正済み | デフォルト値は "" です。TiDB のデフォルトのサポート TLS バージョンが`TLS1.1`以上から`TLS1.2`以上に変更されました。 | -| ティクヴ | [`raftstore.report-min-resolved-ts-interval`](https://docs.pingcap.com/tidb/v7.5/tikv-configuration-file/#report-min-resolved-ts-interval-new-in-v600) | 名称変更 | 名前をより正確にするため、この構成項目は[`raftstore.pd-report-min-resolved-ts-interval`](/tikv-configuration-file.md#pd-report-min-resolved-ts-interval-new-in-v760)に名前が変更されました。 `raftstore.report-min-resolved-ts-interval`は無効になりました。 | -| ティクヴ | [`blob-file-compression`](/tikv-configuration-file.md#blob-file-compression) | 修正済み | Titan で値を圧縮するために使用されるアルゴリズムで、値を単位とします。TiDB v7.6.0 以降、デフォルトの圧縮アルゴリズムは`zstd`です。 | -| ティクヴ | [`rocksdb.defaultcf.titan.min-blob-size`](/tikv-configuration-file.md#min-blob-size) | 修正済み | TiDB v7.6.0以降、新規クラスタのデフォルト値は`32KB`となります。v7.6.0にアップグレードする既存クラスタの場合、デフォルト値`1KB`は変更されません。 | -| ティクヴ | [`rocksdb.titan.enabled`](/tikv-configuration-file.md#enabled) | 修正済み | Titan を有効または無効にします。v7.5.0 以前のバージョンでは、デフォルト値は`false`です。v7.6.0 以降では、新規クラスターの場合のみデフォルト値は`true`になります。v7.6.0 以降のバージョンにアップグレードされた既存のクラスターは、元の構成を維持します。 | -| ティクヴ | [`cdc.incremental-scan-concurrency-limit`](/tikv-configuration-file.md#incremental-scan-concurrency-limit-new-in-v760) | 新しく追加された | 履歴データを増分スキャンするタスクの実行待ちキューの最大長を設定します。デフォルト値は`10000`で、これは最大 10000 個のタスクを実行待ちキューに入れることができることを意味します。 | -| ティクヴ | [`gc.num-threads`](/tikv-configuration-file.md#num-threads-new-in-v658-v714-v751-and-v760) | 新しく追加された | `enable-compaction-filter` `false`に設定すると、このパラメータは GC スレッドの数を制御します。デフォルト値は`1`です。 | -| ティクヴ | [`raftstore.periodic-full-compact-start-times`](/tikv-configuration-file.md#periodic-full-compact-start-times-new-in-v760) | 新しく追加された | TiKVが定期的な完全圧縮を開始する具体的な時間を設定します。デフォルト値`[]`は、定期的な完全圧縮が無効になっていることを意味します。 | -| ティクヴ | [`raftstore.periodic-full-compact-start-max-cpu`](/tikv-configuration-file.md#periodic-full-compact-start-max-cpu-new-in-v760) | 新しく追加された | TiKVの定期的な完全圧縮における最大CPU使用率を制限します。デフォルト値は`0.1`です。 | -| ティクヴ | [`raftstore.pd-report-min-resolved-ts-interval`](/tikv-configuration-file.md#pd-report-min-resolved-ts-interval-new-in-v760) | 新しく追加された | [`raftstore.report-min-resolved-ts-interval`](https://docs.pingcap.com/tidb/v7.5/tikv-configuration-file#report-min-resolved-ts-interval-new-in-v600)から名前が変更されました。TiKV が解決済み TS を PD リーダーに報告する最小間隔を指定します。デフォルト値は`"1s"`です。 | -| ティクヴ | [`zstd-dict-size`](/tikv-configuration-file.md#zstd-dict-size) | 新しく追加された | `zstd`辞書の圧縮サイズを指定します。デフォルト値は`"0KB"`で、これは`zstd`辞書の圧縮を無効にすることを意味します。 | +| TiKV | [`raftstore.report-min-resolved-ts-interval`](https://docs.pingcap.com/tidb/v7.5/tikv-configuration-file/#report-min-resolved-ts-interval-new-in-v600) | 名称変更 | 名前をより正確にするため、この構成項目は[`raftstore.pd-report-min-resolved-ts-interval`](/tikv-configuration-file.md#pd-report-min-resolved-ts-interval-new-in-v760)に名前が変更されました。 `raftstore.report-min-resolved-ts-interval`は無効になりました。 | +| TiKV | [`blob-file-compression`](/tikv-configuration-file.md#blob-file-compression) | 修正済み | Titan で値を圧縮するために使用されるアルゴリズムで、値を単位とします。TiDB v7.6.0 以降、デフォルトの圧縮アルゴリズムは`zstd`です。 | +| TiKV | [`rocksdb.defaultcf.titan.min-blob-size`](/tikv-configuration-file.md#min-blob-size) | 修正済み | TiDB v7.6.0以降、新規クラスターのデフォルト値は`32KB`となります。v7.6.0にアップグレードする既存クラスターの場合、デフォルト値`1KB`は変更されません。 | +| TiKV | [`rocksdb.titan.enabled`](/tikv-configuration-file.md#enabled) | 修正済み | Titan を有効または無効にします。v7.5.0 以前のバージョンでは、デフォルト値は`false`です。v7.6.0 以降では、新規クラスターの場合のみデフォルト値は`true`になります。v7.6.0 以降のバージョンにアップグレードされた既存のクラスターは、元の構成を維持します。 | +| TiKV | [`cdc.incremental-scan-concurrency-limit`](/tikv-configuration-file.md#incremental-scan-concurrency-limit-new-in-v760) | 新しく追加された | 履歴データを増分スキャンするタスクの実行待ちキューの最大長を設定します。デフォルト値は`10000`で、これは最大 10000 個のタスクを実行待ちキューに入れることができることを意味します。 | +| TiKV | [`gc.num-threads`](/tikv-configuration-file.md#num-threads-new-in-v658-v714-v751-and-v760) | 新しく追加された | `enable-compaction-filter` `false`に設定すると、このパラメータは GC スレッドの数を制御します。デフォルト値は`1`です。 | +| TiKV | [`raftstore.periodic-full-compact-start-times`](/tikv-configuration-file.md#periodic-full-compact-start-times-new-in-v760) | 新しく追加された | TiKVが定期的な完全圧縮を開始する具体的な時間を設定します。デフォルト値`[]`は、定期的な完全圧縮が無効になっていることを意味します。 | +| TiKV | [`raftstore.periodic-full-compact-start-max-cpu`](/tikv-configuration-file.md#periodic-full-compact-start-max-cpu-new-in-v760) | 新しく追加された | TiKVの定期的な完全圧縮における最大CPU使用率を制限します。デフォルト値は`0.1`です。 | +| TiKV | [`raftstore.pd-report-min-resolved-ts-interval`](/tikv-configuration-file.md#pd-report-min-resolved-ts-interval-new-in-v760) | 新しく追加された | [`raftstore.report-min-resolved-ts-interval`](https://docs.pingcap.com/tidb/v7.5/tikv-configuration-file#report-min-resolved-ts-interval-new-in-v600)から名前が変更されました。TiKV が解決済み TS を PD リーダーに報告する最小間隔を指定します。デフォルト値は`"1s"`です。 | +| TiKV | [`zstd-dict-size`](/tikv-configuration-file.md#zstd-dict-size) | 新しく追加された | `zstd`辞書の圧縮サイズを指定します。デフォルト値は`"0KB"`で、これは`zstd`辞書の圧縮を無効にすることを意味します。 | | TiFlash | [`logger.level`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 修正済み | ログ記録のコストを削減するために、デフォルト値を`"debug"`から`"INFO"`に変更します。 | | TiDB Lightning | [`tidb.pd-addr`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) | 修正済み | PDサーバーのアドレスを設定します。バージョン7.6.0以降、TiDBは複数のPDアドレスの設定をサポートしています。 | | TiDB Lightning | [`block-size`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task) | 新しく追加された | 物理インポートモード（ `backend='local'` ）でローカルファイルをソートするためのI/Oブロックサイズを制御します。デフォルト値は`16KiB`です。ディスクIOPSがボトルネックになっている場合は、この値を増やすことでパフォーマンスを向上させることができます。 | | BR | [`--granularity`](/br/br-snapshot-guide.md#performance-and-impact-of-snapshot-restore) | 新しく追加された | `--granularity="coarse-grained"`を指定することで、粗粒度リージョン散布アルゴリズム（実験的）を使用します。これにより、大規模なリージョンシナリオにおける復元速度が向上します。 | | TiCDC | [`compression`](/ticdc/ticdc-changefeed-config.md) | 新しく追加された | リドゥログファイルの圧縮動作を制御します。 | -| TiCDC | [`sink.cloud-storage-config`](/ticdc/ticdc-changefeed-config.md) | 新しく追加された | オブジェクトstorageにデータを複製する際に、履歴データの自動クリーンアップを設定します。 | +| TiCDC | [`sink.cloud-ストレージ-config`](/ticdc/ticdc-changefeed-config.md) | 新しく追加された | オブジェクトストレージにデータを複製する際に、履歴データの自動クリーンアップを設定します。 | ### システムテーブル {#system-tables} @@ -299,7 +299,7 @@ v7.6.0 以降、 `TiDB-community-server`[バイナリパッケージ](/binary-pa - 一部の型変換を処理する際の TiDB 実装を最適化し、関連する問題を修正します[#47945](https://github.com/pingcap/tidb/issues/47945) [#47864](https://github.com/pingcap/tidb/issues/47864) [#47829](https://github.com/pingcap/tidb/issues/47829) [#47816](https://github.com/pingcap/tidb/issues/47816) @[YangKeao](https://github.com/YangKeao)@[lcwangchao](https://github.com/lcwangchao) - スキーマバージョンを取得する際、TiDBはデフォルトでKVタイムアウト機能を使用して読み取りを行うため、遅いメタリージョンリーダーの読み取りがスキーマバージョン更新に与える影響が軽減されます。 [#48125](https://github.com/pingcap/tidb/pull/48125) [cfzjywxk](https://github.com/cfzjywxk) -- ティクヴ +- TiKV - 非同期タスクを照会するためのAPIエンドポイント`/async_tasks`を追加 [#15759](https://github.com/tikv/tikv/issues/15759) @[YuJuncen](https://github.com/YuJuncen) - gRPC モニタリングに優先度ラベルを追加して、異なる優先度のリソース グループ データを表示します [#49318](https://github.com/pingcap/tidb/issues/49318) @[bufferflies](https://github.com/bufferflies) @@ -328,7 +328,7 @@ v7.6.0 以降、 `TiDB-community-server`[バイナリパッケージ](/binary-pa - TiCDC - - TiCDCによるオブジェクトstorageへのデータ複製パフォーマンスを並列処理の増加によって改善する [#10098](https://github.com/pingcap/tiflow/issues/10098) @[CharlesCheung96](https://github.com/CharlesCheung96) + - TiCDCによるオブジェクトストレージへのデータ複製パフォーマンスを並列処理の増加によって改善する [#10098](https://github.com/pingcap/tiflow/issues/10098) @[CharlesCheung96](https://github.com/CharlesCheung96) - `content-compatible=true` [公式Canal出力のコンテンツ形式と互換性がある](/ticdc/ticdc-canal-json.md#compatibility-with-the-official-canal)`sink-uri`の[3エースショーハンド](https://github.com/3AceShowHand) [#10106](https://github.com/pingcap/tiflow/issues/10106) - TiDBデータ移行（DM） @@ -417,7 +417,7 @@ v7.6.0 以降、 `TiDB-community-server`[バイナリパッケージ](/binary-pa - ハッシュ パーティション テーブルのクエリ時に TiDB が間違ったパーティションを選択する可能性がある問題を修正 [#50044](https://github.com/pingcap/tidb/issues/50044) @[Defined2014](https://github.com/Defined2014) - 圧縮を有効にして MariaDB Connector/J を使用するときに発生する接続エラーを修正 [#49845](https://github.com/pingcap/tidb/issues/49845) @[onlyacat](https://github.com/onlyacat) -- ティクヴ +- TiKV - 破損したSSTファイルが他のTiKVノードに拡散し、TiKVがpanic可能性がある問題を修正しました [#15986](https://github.com/tikv/tikv/issues/15986) @[Connor1996](https://github.com/Connor1996) - オンラインの安全でない回復がマージ中止を処理できない問題を修正 [#15580](https://github.com/tikv/tikv/issues/15580) @[v01dstar](https://github.com/v01dstar) @@ -449,7 +449,7 @@ v7.6.0 以降、 `TiDB-community-server`[バイナリパッケージ](/binary-pa - `RECOVER TABLE`および`FLASHBACK TABLE`TiFlash`CREATE TABLE` `DROP TABLE`を介して一部の TiFlash レプリカデータを復元できない問題 [#1664](https://github.com/pingcap/tiflash/issues/1664) @[JaySon-Huang](https://github.com/JaySon-Huang) - `ColumnRef in (Literal, Func...)`のようなフィルタリング条件を指定してクエリを実行すると、クエリ結果が正しくなくなる問題を修正 [#8631](https://github.com/pingcap/tiflash/issues/8631) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - DDL の同時実行中にTiFlash で競合が発生した場合のTiFlashpanic問題を修正 [#8578](https://github.com/pingcap/tiflash/issues/8578) @[JaySon-Huang](https://github.com/JaySon-Huang) - - TiFlash が非集約storageおよびコンピューティングアーキテクチャの下でオブジェクトstorageデータの GC 所有者を選択できない場合がある問題を修正 [#8519](https://github.com/pingcap/tiflash/issues/8519) @[JaySon-Huang](https://github.com/JaySon-Huang) + - TiFlash が非集約ストレージおよびコンピューティングアーキテクチャの下でオブジェクトストレージデータの GC 所有者を選択できない場合がある問題を修正 [#8519](https://github.com/pingcap/tiflash/issues/8519) @[JaySon-Huang](https://github.com/JaySon-Huang) - `lowerUTF8`および`upperUTF8`関数で、大文字と小文字が異なるバイトを占有することを許可しない問題を修正 [#8484](https://github.com/pingcap/tiflash/issues/8484) @[gengliqi](https://github.com/gengliqi) - TiFlashが`ENUM`の値が0の場合に`ENUM`を正しく処理しない問題を修正 [#8311](https://github.com/pingcap/tiflash/issues/8311) @[solotzg](https://github.com/solotzg) - `INET_NTOA()`式の互換性の問題を修正 [#8211](https://github.com/pingcap/tiflash/issues/8211) @[solotzg](https://github.com/solotzg) @@ -462,7 +462,7 @@ v7.6.0 以降、 `TiDB-community-server`[バイナリパッケージ](/binary-pa - バックアップと復元 (BR) - - BRが外部storageファイルに対して不正なURIを生成する問題を修正 [#48452](https://github.com/pingcap/tidb/issues/48452) @[3AceShowHand](https://github.com/3AceShowHand) + - BRが外部ストレージファイルに対して不正なURIを生成する問題を修正 [#48452](https://github.com/pingcap/tidb/issues/48452) @[3AceShowHand](https://github.com/3AceShowHand) - ログバックアップタスクは開始できるものの、タスク初期化中にPDへの接続に失敗すると正しく動作しない問題を修正 [#16056](https://github.com/tikv/tikv/issues/16056) @[YuJuncen](https://github.com/YuJuncen) - ログバックアップタスクが起動後にメモリリークを起こして正常に実行されない可能性がある問題を修正 [#16070](https://github.com/tikv/tikv/issues/16070) @[YuJuncen](https://github.com/YuJuncen) - PITR処理中にシステムテーブル`mysql.gc_delete_range`にデータを挿入するとエラー [#49346](https://github.com/pingcap/tidb/issues/49346)が返される問題を修正しました。@[Leavrth](https://github.com/Leavrth) @@ -472,7 +472,7 @@ v7.6.0 以降、 `TiDB-community-server`[バイナリパッケージ](/binary-pa - TiCDC - `WHERE`句が、特定のシナリオで`DELETE`ステートメントを複製する際に主キーを条件として使用しない問題を修正しました [#9812](https://github.com/pingcap/tiflow/issues/9812) @[asddongmen](https://github.com/asddongmen) - - TiCDCサーバーがオブジェクトstorageサービスへのデータ複製時にpanic可能性がある問題を修正しました [#10137](https://github.com/pingcap/tiflow/issues/10137) @[sdojjy](https://github.com/sdojjy) + - TiCDCサーバーがオブジェクトストレージサービスへのデータ複製時にpanic可能性がある問題を修正しました [#10137](https://github.com/pingcap/tiflow/issues/10137) @[sdojjy](https://github.com/sdojjy) - `kv-client`の初期化中の潜在的なデータ競合の問題を修正 [#10095](https://github.com/pingcap/tiflow/issues/10095) @[3AceShowHand](https://github.com/3AceShowHand)ショーハンド - TiCDCが特定の特殊なシナリオで誤ってTiKVとの接続を閉じる問題を修正 [#10239](https://github.com/pingcap/tiflow/issues/10239) @[hicqu](https://github.com/hicqu) - TiCDCサーバーが損失のあるDDLステートメントを実行する際にpanic可能性がある問題を修正しました（アップストリーム [#9739](https://github.com/pingcap/tiflow/issues/9739) @[hicqu](https://github.com/hicqu) diff --git a/releases/release-8.0.0.md b/releases/release-8.0.0.md index 2d6fb992fe030..ecc76438c856d 100644 --- a/releases/release-8.0.0.md +++ b/releases/release-8.0.0.md @@ -13,7 +13,7 @@ TiDB バージョン: 8.0.0 バージョン8.0.0では、以下の主要な機能と改善点が導入されています。 -
カテゴリ機能／改善点説明
拡張性とパフォーマンススケーラビリティ向上のためのPDの分解（実験的）配置Driver（PD）には、TiDBクラスタの正常な動作を保証するための複数の重要なモジュールが含まれています。クラスタのワークロードが増加すると、PD内の各モジュールのリソース消費量も増加し、これらのモジュール間で相互干渉が発生し、最終的にクラスタ全体のサービス品質に影響を与えます。v8.0.0以降、TiDBはこの問題に対処するため、PD内のTSOモジュールとスケジューリングモジュールを独立してデプロイ可能なマイクロサービスに分割しました。これにより、クラスタの規模が拡大するにつれて、モジュール間の相互干渉を大幅に削減できます。このアーキテクチャにより、より大規模なワークロードを持つ、より大規模なクラスタの構築が可能になりました。
より大規模なトランザクション向けの一括DML（実験的）大規模なバッチ DML ジョブ（大規模なクリーンアップ ジョブ、結合、集計など）は、大量のメモリを消費する可能性があり、これまで非常に大規模な処理には制限がありました。バルク DML ( tidb_dml_type = "bulk" ) は、トランザクション保証を提供し、メモリ不足の問題を軽減しながら、大規模なバッチ DML タスクをより効率的に処理するための新しい DML タイプです。この機能は、データ ロードに使用する場合、インポート、ロード、およびリストア操作とは異なります。
クラスタスナップショット復元速度の向上（GA）この機能により、 BRはクラスタの規模の利点を最大限に活用し、クラスタ内のすべてのTiKVノードがデータ復元の準備段階に参加できるようになります。この機能は、大規模クラスタにおける大規模データセットの復元速度を大幅に向上させます。実際のテストでは、この機能によりダウンロード帯域幅が飽和状態になり、ダウンロード速度が8～10倍、エンドツーエンドの復元速度が約1.5～3倍向上することが示されています。
テーブル数が膨大な場合のスキーマ情報のキャッシュの安定性を向上させる（実験的） TiDBをマルチテナントアプリケーションの記録システムとして利用するSaaS企業は、多くの場合、膨大な数のテーブルを保存する必要があります。以前のバージョンでは、100万個以上のテーブルを処理することは可能でしたが、ユーザーエクスペリエンス全体が低下する可能性がありました。TiDB v8.0.0では、 auto analyze用の優先度キューを実装することで状況が改善され、処理がより柔軟になり、より幅広いテーブルで安定性が向上します。
データベースの運用と可観測性インデックス使用統計の監視をサポートします適切なインデックス設計は、データベースのパフォーマンスを維持するための重要な前提条件です。TiDB v8.0.0 では、インデックスの使用状況統計情報を提供するINFORMATION_SCHEMA.TIDB_INDEX_USAGEテーブルとsys.schema_unused_indexesビューが導入されました。この機能は、データベース内のインデックスの効率性を評価し、インデックス設計を最適化するのに役立ちます。
データ移行TiCDCがSimpleプロトコルのサポートを追加TiCDCは、新しいプロトコルであるSimpleプロトコルを導入しました。このプロトコルは、DDLおよびBOOTSTRAPイベントにテーブルスキーマ情報を埋め込むことで、インバンドスキーマ追跡機能を提供します。
TiCDCはDebeziumフォーマットプロトコルのサポートを追加しました。 TiCDCは、新しいプロトコルであるDebeziumプロトコルを導入しました。TiCDCは、Debezium形式のメッセージを生成するプロトコルを使用して、データ変更イベントをKafkaシンクに発行できるようになりました。
+
カテゴリ機能／改善点説明
拡張性とパフォーマンススケーラビリティ向上のためのPDの分解（実験的）配置Driver（PD）には、TiDBクラスターの正常な動作を保証するための複数の重要なモジュールが含まれています。クラスターのワークロードが増加すると、PD内の各モジュールのリソース消費量も増加し、これらのモジュール間で相互干渉が発生し、最終的にクラスター全体のサービス品質に影響を与えます。v8.0.0以降、TiDBはこの問題に対処するため、PD内のTSOモジュールとスケジューリングモジュールを独立してデプロイ可能なマイクロサービスに分割しました。これにより、クラスターの規模が拡大するにつれて、モジュール間の相互干渉を大幅に削減できます。このアーキテクチャにより、より大規模なワークロードを持つ、より大規模なクラスターの構築が可能になりました。
より大規模なトランザクション向けの一括DML（実験的）大規模なバッチ DML ジョブ（大規模なクリーンアップ ジョブ、結合、集計など）は、大量のメモリを消費する可能性があり、これまで非常に大規模な処理には制限がありました。バルク DML ( tidb_dml_type = "bulk" ) は、トランザクション保証を提供し、メモリ不足の問題を軽減しながら、大規模なバッチ DML タスクをより効率的に処理するための新しい DML タイプです。この機能は、データ ロードに使用する場合、インポート、ロード、およびリストア操作とは異なります。
クラスタースナップショット復元速度の向上（GA）この機能により、 BRはクラスターの規模の利点を最大限に活用し、クラスター内のすべてのTiKVノードがデータ復元の準備段階に参加できるようになります。この機能は、大規模クラスターにおける大規模データセットの復元速度を大幅に向上させます。実際のテストでは、この機能によりダウンロード帯域幅が飽和状態になり、ダウンロード速度が8～10倍、エンドツーエンドの復元速度が約1.5～3倍向上することが示されています。
テーブル数が膨大な場合のスキーマ情報のキャッシュの安定性を向上させる（実験的） TiDBをマルチテナントアプリケーションの記録システムとして利用するSaaS企業は、多くの場合、膨大な数のテーブルを保存する必要があります。以前のバージョンでは、100万個以上のテーブルを処理することは可能でしたが、ユーザーエクスペリエンス全体が低下する可能性がありました。TiDB v8.0.0では、 auto analyze用の優先度キューを実装することで状況が改善され、処理がより柔軟になり、より幅広いテーブルで安定性が向上します。
データベースの運用と可観測性インデックス使用統計の監視をサポートします適切なインデックス設計は、データベースのパフォーマンスを維持するための重要な前提条件です。TiDB v8.0.0 では、インデックスの使用状況統計情報を提供するINFORMATION_SCHEMA.TIDB_INDEX_USAGEテーブルとsys.schema_unused_indexesビューが導入されました。この機能は、データベース内のインデックスの効率性を評価し、インデックス設計を最適化するのに役立ちます。
データ移行TiCDCがSimpleプロトコルのサポートを追加TiCDCは、新しいプロトコルであるSimpleプロトコルを導入しました。このプロトコルは、DDLおよびBOOTSTRAPイベントにテーブルスキーマ情報を埋め込むことで、インバンドスキーマ追跡機能を提供します。
TiCDCはDebeziumフォーマットプロトコルのサポートを追加しました。 TiCDCは、新しいプロトコルであるDebeziumプロトコルを導入しました。TiCDCは、Debezium形式のメッセージを生成するプロトコルを使用して、データ変更イベントをKafkaシンクに発行できるようになりました。
## 機能の詳細 {#feature-details} @@ -21,10 +21,10 @@ TiDB バージョン: 8.0.0 - PDはマイクロサービスモードをサポートしています（実験的） [#5766](https://github.com/tikv/pd/issues/5766) @[binshi-bing](https://github.com/binshi-bing) - バージョン8.0.0以降、PDはマイクロサービスモードをサポートしています。このモードでは、PDのタイムスタンプ割り当て機能とクラスタスケジューリング関数を個別のマイクロサービスに分割し、それぞれを独立してデプロイできるため、PDのパフォーマンス拡張性が向上し、大規模クラスタにおけるPDのパフォーマンスボトルネックが解消されます。 + バージョン8.0.0以降、PDはマイクロサービスモードをサポートしています。このモードでは、PDのタイムスタンプ割り当て機能とクラスタースケジューリング関数を個別のマイクロサービスに分割し、それぞれを独立してデプロイできるため、PDのパフォーマンス拡張性が向上し、大規模クラスターにおけるPDのパフォーマンスボトルネックが解消されます。 - `tso`マイクロサービス: クラスター全体に単調増加するタイムスタンプ割り当てを提供します。 - - `scheduling`マイクロサービス: 負荷分散、ホットスポット処理、レプリカ修復、レプリカ配置などを含むがこれらに限定されない、クラスタ全体のスケジューリング関数を提供します。 + - `scheduling`マイクロサービス: 負荷分散、ホットスポット処理、レプリカ修復、レプリカ配置などを含むがこれらに限定されない、クラスター全体のスケジューリング関数を提供します。 各マイクロサービスは独立したプロセスとしてデプロイされます。マイクロサービスに複数のレプリカを設定すると、マイクロサービスは自動的にプライマリ/セカンダリのフォールトトレラントモードを実装し、サービスの高い可用性と信頼性を確保します。 @@ -39,7 +39,7 @@ TiDB バージョン: 8.0.0 - Titan blob ファイルと RocksDB ブロックファイルの共有キャッシュをデフォルトで有効にします ( [`shared-blob-cache`](/tikv-configuration-file.md#shared-blob-cache-new-in-v800)デフォルト値は`true`です)。これにより、[`blob-cache-size`](/tikv-configuration-file.md#blob-cache-size)個別に設定する必要がなくなります。 - Titanエンジンを使用する際のパフォーマンスと柔軟性を向上させるため、 [`min-blob-size`](/tikv-configuration-file.md#min-blob-size) 、 [`blob-file-compression`](/tikv-configuration-file.md#blob-file-compression) 、 [`discardable-ratio`](/tikv-configuration-file.md#min-blob-size)を動的に変更することをサポートします。 - 詳細については、[ドキュメント](/storage-engine/titan-configuration.md)を参照してください。 + 詳細については、[ドキュメント](/ストレージ-engine/titan-configuration.md)を参照してください。 ### パフォーマンス {#performance} @@ -47,7 +47,7 @@ TiDB バージョン: 8.0.0 TiDB v8.0.0以降、スナップショット復元速度の高速化が一般提供（GA）となり、デフォルトで有効になっています。BRは、粗粒度リージョン分散アルゴリズムの採用、データベースとテーブルのバッチ作成、SSTファイルダウンロードと取り込み操作間の相互影響の低減、テーブル統計情報の復元の高速化など、さまざまな最適化を実装することで、スナップショット復元速度を大幅に向上させています。実際のケースでのテスト結果によると、単一のTiKVノードのデータ復元速度は1.2 GiB/sで安定し、100 TiBのデータを1時間以内に復元できます。 - これは、高負荷環境でもBRが各 TiKVノードのリソースを最大限に活用し、データベースの復元時間を大幅に短縮し、データベースの可用性と信頼性を向上させ、データ損失やシステム障害によるダウンタイムやビジネス損失を削減できることを意味します。復元速度の向上は、多数のゴルーチンの並列実行によるものであり、特にテーブルやリージョンが多い場合は、メモリ消費量が大幅に増加する可能性があることに注意してください。BRを実行するには、メモリ容量の大きいマシンを使用することをお勧めします。マシンのメモリ容量が限られている場合は、よりきめ細かいリージョン分散アルゴリズムを使用することをお勧めします。また、粗い粒度のリージョン分散アルゴリズムは外部storageの帯域幅を大量に消費する可能性があるため、外部帯域幅不足による他のアプリケーションへの影響を避ける必要があります。 + これは、高負荷環境でもBRが各 TiKVノードのリソースを最大限に活用し、データベースの復元時間を大幅に短縮し、データベースの可用性と信頼性を向上させ、データ損失やシステム障害によるダウンタイムやビジネス損失を削減できることを意味します。復元速度の向上は、多数のゴルーチンの並列実行によるものであり、特にテーブルやリージョンが多い場合は、メモリ消費量が大幅に増加する可能性があることに注意してください。BRを実行するには、メモリ容量の大きいマシンを使用することをお勧めします。マシンのメモリ容量が限られている場合は、よりきめ細かいリージョン分散アルゴリズムを使用することをお勧めします。また、粗い粒度のリージョン分散アルゴリズムは外部ストレージの帯域幅を大量に消費する可能性があるため、外部帯域幅不足による他のアプリケーションへの影響を避ける必要があります。 詳細については、 [ドキュメント](/br/br-snapshot-guide.md#restore-cluster-snapshots)を参照してください。 @@ -106,14 +106,14 @@ TiDB バージョン: 8.0.0 - プロキシコンポーネントTiProxyが一般提供開始（GA）になりました [#413](https://github.com/pingcap/tiproxy/issues/413) @[djshow832](https://github.com/djshow832) @[xhebox](https://github.com/xhebox) - TiDB v7.6.0では、実験的機能としてプロキシコンポーネントTiProxyが導入されました。TiProxyはTiDBの公式プロキシコンポーネントであり、クライアントとTiDBサーバーの間に配置されます。TiProxyはTiDBの負荷分散と接続維持関数を提供し、TiDBクラスタのワークロードをよりバランス良く分散させ、メンテナンス作業中のデータベースへのユーザーアクセスに影響を与えないようにします。 + TiDB v7.6.0では、実験的機能としてプロキシコンポーネントTiProxyが導入されました。TiProxyはTiDBの公式プロキシコンポーネントであり、クライアントとTiDBサーバーの間に配置されます。TiProxyはTiDBの負荷分散と接続維持関数を提供し、TiDBクラスターのワークロードをよりバランス良く分散させ、メンテナンス作業中のデータベースへのユーザーアクセスに影響を与えないようにします。 バージョン8.0.0では、TiProxyが一般提供開始となり、署名証明書の自動生成機能と監視関数が強化されました。 TiProxyの利用シナリオは以下のとおりです。 - - TiDBクラスタにおけるローリング再起動、ローリングアップグレード、スケールインなどのメンテナンス作業中、TiDBサーバーに変更が発生すると、クライアントとTiDBサーバー間の接続が中断されます。TiProxyを使用することで、これらのメンテナンス作業中に接続を他のTiDBサーバーにスムーズに移行できるため、クライアントへの影響を最小限に抑えることができます。 - - TiDBサーバーへのクライアント接続を、他のTiDBサーバーに動的に移行することはできません。複数のTiDBサーバーのワークロードが不均衡になると、クラスタ全体のリソースは十分であっても、特定のTiDBサーバーでリソース枯渇が発生し、レイテンシーが大幅に増加する可能性があります。この問題を解決するために、TiProxyは接続の動的移行機能を提供します。これにより、クライアントに影響を与えることなく、接続をあるTiDBサーバーから別のTiDBサーバーに移行できるため、TiDBクラスタの負荷分散が実現されます。 + - TiDBクラスターにおけるローリング再起動、ローリングアップグレード、スケールインなどのメンテナンス作業中、TiDBサーバーに変更が発生すると、クライアントとTiDBサーバー間の接続が中断されます。TiProxyを使用することで、これらのメンテナンス作業中に接続を他のTiDBサーバーにスムーズに移行できるため、クライアントへの影響を最小限に抑えることができます。 + - TiDBサーバーへのクライアント接続を、他のTiDBサーバーに動的に移行することはできません。複数のTiDBサーバーのワークロードが不均衡になると、クラスター全体のリソースは十分であっても、特定のTiDBサーバーでリソース枯渇が発生し、レイテンシーが大幅に増加する可能性があります。この問題を解決するために、TiProxyは接続の動的移行機能を提供します。これにより、クライアントに影響を与えることなく、接続をあるTiDBサーバーから別のTiDBサーバーに移行できるため、TiDBクラスターの負荷分散が実現されます。 TiProxyはTiUP、 TiDB Operator、およびTiDB Dashboardに統合されているため、設定、デプロイ、およびメンテナンスが容易です。 @@ -125,7 +125,7 @@ TiDB バージョン: 8.0.0 バージョン8.0.0より前のTiDBでは、トランザクションデータをコミットする前にすべてメモリに格納していました。大量のデータを処理する場合、トランザクションに必要なメモリがボトルネックとなり、TiDBが処理できるトランザクションサイズが制限されていました。TiDBは、SQL文を分割することでトランザクションサイズの制限を解消しようと、非トランザクションDMLを導入しましたが、この機能には様々な制限があり、実際のシナリオでは理想的なエクスペリエンスを提供できませんでした。 - バージョン 8.0.0 以降、TiDB は大量のデータを処理するための DML タイプをサポートしています。この DML タイプは、実行中にデータを TiKV にタイムリーに書き込み、すべてのトランザクション データをメモリに継続的にstorageことを回避し、メモリ制限を超える大量のデータの処理をサポートします。この DML タイプはトランザクションの整合性を保証し、標準 DML と同じ構文を使用します。 `INSERT` 、 `UPDATE` 、 `REPLACE` 、および`DELETE`ステートメントは、この新しい DML タイプを使用して大規模な DML 操作を実行できます。 + バージョン 8.0.0 以降、TiDB は大量のデータを処理するための DML タイプをサポートしています。この DML タイプは、実行中にデータを TiKV にタイムリーに書き込み、すべてのトランザクション データをメモリに継続的にストレージことを回避し、メモリ制限を超える大量のデータの処理をサポートします。この DML タイプはトランザクションの整合性を保証し、標準 DML と同じ構文を使用します。 `INSERT` 、 `UPDATE` 、 `REPLACE` 、および`DELETE`ステートメントは、この新しい DML タイプを使用して大規模な DML 操作を実行できます。 この DML タイプは[パイプラインDML](https://github.com/pingcap/tidb/blob/release-8.0/docs/design/2024-01-09-pipelined-DML.md)機能によって実装され、自動コミットが有効になっているステートメントでのみ有効になります。この DML タイプを有効にするかどうかは、システム変数[`tidb_dml_type`](/system-variables.md#tidb_dml_type-new-in-v800)設定することで制御できます。 @@ -149,7 +149,7 @@ TiDB バージョン: 8.0.0 Amazon S3 オブジェクトロックを使用すると、指定された保持期間中にバックアップデータが誤ってまたは意図的に削除されるのを防ぎ、データのセキュリティと整合性を強化できます。バージョン 6.3.0 以降、 BR はスナップショットバックアップで Amazon S3 オブジェクトロックをサポートし、フルバックアップにセキュリティレイヤーを追加します。バージョン 8.0.0 以降、PITR も Amazon S3 オブジェクトロックをサポートします。フルバックアップでもログデータバックアップでも、オブジェクトロック機能はより信頼性の高いデータ保護を保証し、データバックアップとリカバリのセキュリティをさらに強化し、規制要件を満たします。 - 詳細については、 [ドキュメント](/br/backup-and-restore-storages.md#other-features-supported-by-the-storage-service)を参照してください。 + 詳細については、 [ドキュメント](/br/backup-and-restore-ストレージs.md#other-features-supported-by-the-ストレージ-service)を参照してください。 - セッションレベルで非表示のインデックスを可視化する機能のサポート [#50653](https://github.com/pingcap/tidb/issues/50653) @[hawkingrei](https://github.com/hawkingrei) @@ -182,7 +182,7 @@ TiDB バージョン: 8.0.0 この情報を用いることで、オプティマイザで使用されていないインデックスや選択性の低いインデックスを特定し、インデックス設計を最適化することでデータベースのパフォーマンスを向上させることができます。 - さらに、TiDB v8.0.0 では MySQL と互換性のあるビュー[`sys.schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md)が導入されました。このビューには、TiDB インスタンスの最後の起動以降に使用されていないインデックスが表示されます。v8.0.0 より前のバージョンからアップグレードされたクラスタの場合、 `sys`スキーマとビューは自動的に作成されません[`sys.schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md#manually-create-the-schema_unused_indexes-view)を参照して手動で作成できます。 + さらに、TiDB v8.0.0 では MySQL と互換性のあるビュー[`sys.schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md)が導入されました。このビューには、TiDB インスタンスの最後の起動以降に使用されていないインデックスが表示されます。v8.0.0 より前のバージョンからアップグレードされたクラスターの場合、 `sys`スキーマとビューは自動的に作成されません[`sys.schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md#manually-create-the-schema_unused_indexes-view)を参照して手動で作成できます。 詳細については、 [ドキュメント](/information-schema/information-schema-tidb-index-usage.md)を参照してください。 @@ -240,9 +240,9 @@ TiDB バージョン: 8.0.0 - グローバルソートが一般提供開始（GA）となり、 `IMPORT INTO`のパフォーマンスと安定性が大幅に向上しました [#45719](https://github.com/pingcap/tidb/issues/45719) @[lance6716](https://github.com/lance6716) - バージョン7.4.0より前では、[分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)を使用して`IMPORT INTO`タスクを実行すると、ローカルstorage容量が限られているため、TiDBはデータの一部をローカルでソートしてからTiKVにインポートしていました。このため、TiKVにインポートされたデータにかなりの重複が生じ、インポート中にTiKVが追加の圧縮操作を実行する必要が生じ、TiKVのパフォーマンスと安定性に影響が出ていました。 + バージョン7.4.0より前では、[分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)を使用して`IMPORT INTO`タスクを実行すると、ローカルストレージ容量が限られているため、TiDBはデータの一部をローカルでソートしてからTiKVにインポートしていました。このため、TiKVにインポートされたデータにかなりの重複が生じ、インポート中にTiKVが追加の圧縮操作を実行する必要が生じ、TiKVのパフォーマンスと安定性に影響が出ていました。 - v7.4.0 で導入された実験的機能であるグローバル ソートを使用すると、TiDB はインポートするデータを TiKV にインポートする前に、グローバル ソートのために一時的に外部storage(Amazon S3 など) に保存できます。これにより、インポート中の TiKV 圧縮操作が不要になります。v8.0.0 では、グローバル ソートが GA になります。この機能により、TiKV のリソース消費が削減され、 `IMPORT INTO`のパフォーマンスと安定性が大幅に向上します。グローバル ソートを有効にすると、各`IMPORT INTO`タスクは 40 TiB 以内のデータのインポートをサポートします。 + v7.4.0 で導入された実験的機能であるグローバル ソートを使用すると、TiDB はインポートするデータを TiKV にインポートする前に、グローバル ソートのために一時的に外部ストレージ(Amazon S3 など) に保存できます。これにより、インポート中の TiKV 圧縮操作が不要になります。v8.0.0 では、グローバル ソートが GA になります。この機能により、TiKV のリソース消費が削減され、 `IMPORT INTO`のパフォーマンスと安定性が大幅に向上します。グローバル ソートを有効にすると、各`IMPORT INTO`タスクは 40 TiB 以内のデータのインポートをサポートします。 詳細については、[ドキュメント](/tidb-global-sort.md)を参照してください。 @@ -270,7 +270,7 @@ TiDB バージョン: 8.0.0 | 変数名 | 種類を変更する | 説明 | | ------------------------------------------------------------------------------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry) | 非推奨 | バージョン8.0.0以降、このシステム変数は非推奨となり、TiDBは楽観的トランザクションの自動再試行をサポートしなくなりました。[悲観的な取引モード](/pessimistic-transaction.md)使用をお勧めします。楽観的トランザクションの競合が発生した場合は、エラーを捕捉してアプリケーションでトランザクションを再試行できます。 | +| [`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry) | 非推奨 | バージョン8.0.0以降、このシステム変数は非推奨となり、TiDBは楽観的トランザクションの自動再試行をサポートしなくなりました。[悲観的なトランザクションモード](/pessimistic-transaction.md)使用をお勧めします。楽観的トランザクションの競合が発生した場合は、エラーを捕捉してアプリケーションでトランザクションを再試行できます。 | | `tidb_ddl_version` | 名称変更 | TiDB DDL V2 を有効にするかどうかを制御します。バージョン 8.0.0 以降、この変数は目的をより明確にするために[`tidb_enable_fast_create_table`](/system-variables.md#tidb_enable_fast_create_table-new-in-v800)に名称変更されました。 | | [`tidb_enable_collect_execution_info`](/system-variables.md#tidb_enable_collect_execution_info) | 修正済み | [インデックスの使用統計](/information-schema/information-schema-tidb-index-usage.md)を記録するかどうかのコントロールを追加します。デフォルト値は`ON`です。 | | [`tidb_redact_log`](/system-variables.md#tidb_redact_log) | 修正済み | TiDB ログおよびスロー ログを記録する際に、SAL テキスト内のユーザー情報をどのように処理するかを制御します。値のオプションは`OFF` (ログ内のユーザー情報を処理しないことを示す) と`ON` (ログ内のユーザー情報を非表示にすることを示す) です。ログ内のユーザー情報をより詳細に処理できるように、v8.0.0 ではログ情報をマークするための`MARKER`オプションが追加されました。 | @@ -285,23 +285,23 @@ TiDB バージョン: 8.0.0 | [`tidb_opt_use_invisible_indexes`](/system-variables.md#tidb_opt_use_invisible_indexes-new-in-v800) | 新しく追加された | オプティマイザーが現在のセッションでクエリ最適化のために[目に見えないインデックス](/sql-statements/sql-statement-create-index.md#invisible-index)を選択できるかどうかを制御します。変数が`ON`に設定されている場合、オプティマイザーはセッション内のクエリ最適化のために非表示のインデックスを選択できます。 | | [`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800) | 新しく追加された | スキーマ情報のキャッシュに使用できるメモリの上限を制御し、メモリの過剰使用を防ぎます。この機能を有効にすると、LRUアルゴリズムを使用して必要なテーブルをキャッシュし、スキーマ情報によって占有されるメモリを効果的に削減します。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイル | 設定パラメータ | 種類を変更する | 説明 | | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`instance.tidb_enable_collect_execution_info`](/tidb-configuration-file.md#tidb_enable_collect_execution_info) | 修正済み | [インデックスの使用統計](/information-schema/information-schema-tidb-index-usage.md)を記録するかどうかのコントロールを追加します。デフォルト値は`true`です。 | | TiDB | [`tls-version`](/tidb-configuration-file.md#tls-version) | 修正済み | このパラメータは`"TLSv1.0"`と`"TLSv1.1"`をサポートしなくなりました。現在は`"TLSv1.2"`と`"TLSv1.3"`のみをサポートしています。 | | TiDB | [`log.file.compression`](/tidb-configuration-file.md#compression-new-in-v800) | 新しく追加された | ポーリングログの圧縮形式を指定します。デフォルト値はnullで、これはポーリングログが圧縮されないことを意味します。 | | TiDB | [`log.general-log-file`](/tidb-configuration-file.md#general-log-file-new-in-v800) | 新しく追加された | 一般ログを保存するファイルを指定します。デフォルト値はnullで、これは一般ログがインスタンスファイルに書き込まれることを意味します。 | | TiDB | [`tikv-client.enable-replica-selector-v2`](/tidb-configuration-file.md#enable-replica-selector-v2-new-in-v800) | 新しく追加された | TiKV に RPC リクエストを送信する際に、リージョンレプリカセレクターの新しいバージョンを使用するかどうかを制御します。デフォルト値は`true`です。 | -| ティクヴ | [`log-backup.initial-scan-rate-limit`](/tikv-configuration-file.md#initial-scan-rate-limit-new-in-v620) | 修正済み | 最小値として`1MiB`の制限を追加します。 | -| ティクヴ | [`raftstore.store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530) | 修正済み | TiKV のパフォーマンスを向上させるため、デフォルト値を`0`から`1`に変更します。つまり、StoreWriter スレッド プールのサイズはデフォルトで`1`になります。 | -| ティクヴ | [`rocksdb.defaultcf.titan.blob-cache-size`](/tikv-configuration-file.md#blob-cache-size) | 修正済み | バージョン8.0.0以降、TiKVは`shared-blob-cache`設定項目を導入し、デフォルトで有効にしているため、 `blob-cache-size`を別途設定する必要はありません。 `blob-cache-size`の設定は、 `shared-blob-cache`が`false`に設定されている場合にのみ有効になります。 | -| ティクヴ | [`rocksdb.titan.max-background-gc`](/tikv-configuration-file.md#max-background-gc) | 修正済み | Titan GC プロセスによるスレッド リソースの占有を減らすため、デフォルト値を`4`から`1`に変更します。 | -| ティクヴ | [`security.encryption.master-key.vendor`](/encryption-at-rest.md#specify-a-master-key-via-kms) | 修正済み | サービスプロバイダで使用可能なタイプとして`gcp`を追加します。 | -| ティクヴ | [`storage.block-cache.low-pri-pool-ratio`](/tikv-configuration-file.md#low-pri-pool-ratio-new-in-v800) | 新しく追加された | Titanコンポーネントが使用できるブロックキャッシュ全体の割合を指定します。デフォルト値は`0.2`です。 | -| ティクヴ | [`rocksdb.defaultcf.titan.shared-blob-cache`](/tikv-configuration-file.md#shared-blob-cache-new-in-v800) | 新しく追加された | Titan blob ファイルと RocksDB ブロックファイルの共有キャッシュを有効にするかどうかを制御します。デフォルト値は`true`です。 | -| ティクヴ | [`security.encryption.master-key.gcp.credential-file-path`](/encryption-at-rest.md#specify-a-master-key-via-kms) | 新しく追加された | `security.encryption.master-key.vendor`が`gcp`の場合に、Google Cloud 認証情報ファイルへのパスを指定します。 | +| TiKV | [`log-backup.initial-scan-rate-limit`](/tikv-configuration-file.md#initial-scan-rate-limit-new-in-v620) | 修正済み | 最小値として`1MiB`の制限を追加します。 | +| TiKV | [`raftstore.store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530) | 修正済み | TiKV のパフォーマンスを向上させるため、デフォルト値を`0`から`1`に変更します。つまり、StoreWriter スレッド プールのサイズはデフォルトで`1`になります。 | +| TiKV | [`rocksdb.defaultcf.titan.blob-cache-size`](/tikv-configuration-file.md#blob-cache-size) | 修正済み | バージョン8.0.0以降、TiKVは`shared-blob-cache`設定項目を導入し、デフォルトで有効にしているため、 `blob-cache-size`を別途設定する必要はありません。 `blob-cache-size`の設定は、 `shared-blob-cache`が`false`に設定されている場合にのみ有効になります。 | +| TiKV | [`rocksdb.titan.max-background-gc`](/tikv-configuration-file.md#max-background-gc) | 修正済み | Titan GC プロセスによるスレッド リソースの占有を減らすため、デフォルト値を`4`から`1`に変更します。 | +| TiKV | [`security.encryption.master-key.vendor`](/encryption-at-rest.md#specify-a-master-key-via-kms) | 修正済み | サービスプロバイダで使用可能なタイプとして`gcp`を追加します。 | +| TiKV | [`ストレージ.block-cache.low-pri-pool-ratio`](/tikv-configuration-file.md#low-pri-pool-ratio-new-in-v800) | 新しく追加された | Titanコンポーネントが使用できるブロックキャッシュ全体の割合を指定します。デフォルト値は`0.2`です。 | +| TiKV | [`rocksdb.defaultcf.titan.shared-blob-cache`](/tikv-configuration-file.md#shared-blob-cache-new-in-v800) | 新しく追加された | Titan blob ファイルと RocksDB ブロックファイルの共有キャッシュを有効にするかどうかを制御します。デフォルト値は`true`です。 | +| TiKV | [`security.encryption.master-key.gcp.credential-file-path`](/encryption-at-rest.md#specify-a-master-key-via-kms) | 新しく追加された | `security.encryption.master-key.vendor`が`gcp`の場合に、Google Cloud 認証情報ファイルへのパスを指定します。 | | PD | [`schedule.enable-heartbeat-breakdown-metrics`](/pd-configuration-file.md#enable-heartbeat-breakdown-metrics-new-in-v800) | 新しく追加された | リージョンハートビートの内訳メトリクスを有効にするかどうかを制御します。これらのメトリクスは、リージョンハートビート処理の各段階で消費された時間を測定し、監視による分析を容易にします。デフォルト値は`true`です。 | | PD | [`schedule.enable-heartbeat-concurrent-runner`](/pd-configuration-file.md#enable-heartbeat-concurrent-runner-new-in-v800) | 新しく追加された | リージョンハートビートの非同期同時処理を有効にするかどうかを制御します。有効にすると、独立したエグゼキュータがリージョンハートビート要求を非同期かつ同時に処理し、ハートビート処理のスループットを向上させ、レイテンシーを削減できます。デフォルト値は`true`です。 | | TiDB Lightning | [`tikv-importer.duplicate-resolution`](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#the-old-version-of-conflict-detection-deprecated-in-v800) | 非推奨 | 物理インポートモードで一意キーの競合を検出して解決するかどうかを制御します。v8.0.0以降は[`conflict.strategy`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)に置き換えられています。 | @@ -320,7 +320,7 @@ TiDB バージョン: 8.0.0 ## 非推奨機能 {#deprecated-features} -- バージョン8.0.0以降、 [`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry)システム変数は非推奨となり、TiDBは楽観的トランザクションの自動再試行をサポートしなくなりました。代替策として、楽観的トランザクションの競合が発生した場合は、エラーを捕捉してアプリケーションでトランザクションを再試行するか、[悲観的な取引モード](/pessimistic-transaction.md)を使用してください。 +- バージョン8.0.0以降、 [`tidb_disable_txn_auto_retry`](/system-variables.md#tidb_disable_txn_auto_retry)システム変数は非推奨となり、TiDBは楽観的トランザクションの自動再試行をサポートしなくなりました。代替策として、楽観的トランザクションの競合が発生した場合は、エラーを捕捉してアプリケーションでトランザクションを再試行するか、[悲観的なトランザクションモード](/pessimistic-transaction.md)を使用してください。 - バージョン8.0.0以降、TiDBはTLSv1.0およびTLSv1.1プロトコルをサポートしなくなりました。TLSをTLSv1.2またはTLSv1.3にアップグレードする必要があります。 - バージョン8.0.0以降、 TiDB Lightningは[旧バージョンの競合検出](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#the-old-version-of-conflict-detection-deprecated-in-v800)戦略を非推奨とし、 [`conflict.strategy`](/tidb-lightning/tidb-lightning-configuration.md)パラメータを使用して論理インポートモードと物理インポートモードの両方の競合検出戦略を制御できるようにします。旧バージョンの競合検出の[`duplicate-resolution`](/tidb-lightning/tidb-lightning-configuration.md)パラメータは、今後のリリースで削除されます。 - 今後のリリースでは [実行プランバインディングの自動進化](/sql-plan-management.md#baseline-evolution)が再設計される予定であり、関連する変数や動作が変更される予定です。 @@ -347,12 +347,12 @@ TiDB バージョン: 8.0.0 - 大規模テーブルをクエリする際に、PD からリージョンをバッチでロードして KV 範囲からリージョンへの変換プロセスを高速化するサポート [#51326](https://github.com/pingcap/tidb/issues/51326) @[SeaRise](https://github.com/SeaRise) - システムテーブル`INFORMATION_SCHEMA.TABLES` 、 `INFORMATION_SCHEMA.STATISTICS` 、 `INFORMATION_SCHEMA.KEY_COLUMN_USAGE` 、および`INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS`パフォーマンスを最適化しました。以前のバージョンと比較して、パフォーマンスが最大 100 倍向上しています。 [#50305](https://github.com/pingcap/tidb/issues/50305) @[ywqzzy](https://github.com/ywqzzy) -- ティクヴ +- TiKV - - 構成や操作が不適切な場合のクラスタTSOの堅牢性を向上させるため、TSOの検証と検出機能を強化する [#16545](https://github.com/tikv/tikv/issues/16545) @[cfzjywxk](https://github.com/cfzjywxk) + - 構成や操作が不適切な場合のクラスターTSOの堅牢性を向上させるため、TSOの検証と検出機能を強化する [#16545](https://github.com/tikv/tikv/issues/16545) @[cfzjywxk](https://github.com/cfzjywxk) - 未コミットトランザクションの処理パフォーマンスを向上させるため、悲観的ロックのクリーンアップロジックを最適化する [#16158](https://github.com/tikv/tikv/issues/16158) @[cfzjywxk](https://github.com/cfzjywxk) - - TiKV の統一ヘルス制御を導入し、異常な単一の TiKV ノードがクラスタ アクセス パフォーマンスに与える影響を軽減します。この最適化は、 [`tikv-client.enable-replica-selector-v2`](/tidb-configuration-file.md#enable-replica-selector-v2-new-in-v800)を`false`に設定することで無効にできます。 [#16297](https://github.com/tikv/tikv/issues/16297) [#1104](https://github.com/tikv/client-go/issues/1104) [#1167](https://github.com/tikv/client-go/issues/1167) @[MyonKeminta](https://github.com/MyonKeminta)@[zyguan](https://github.com/zyguan)@[crazycs520](https://github.com/crazycs520) - - PDクライアントはメタデータstorageインターフェースを使用して、以前のグローバル構成インターフェースを置き換えます [#14484](https://github.com/tikv/tikv/issues/14484) @[HuSharp](https://github.com/HuSharp) + - TiKV の統一ヘルス制御を導入し、異常な単一の TiKV ノードがクラスター アクセス パフォーマンスに与える影響を軽減します。この最適化は、 [`tikv-client.enable-replica-selector-v2`](/tidb-configuration-file.md#enable-replica-selector-v2-new-in-v800)を`false`に設定することで無効にできます。 [#16297](https://github.com/tikv/tikv/issues/16297) [#1104](https://github.com/tikv/client-go/issues/1104) [#1167](https://github.com/tikv/client-go/issues/1167) @[MyonKeminta](https://github.com/MyonKeminta)@[zyguan](https://github.com/zyguan)@[crazycs520](https://github.com/crazycs520) + - PDクライアントはメタデータストレージインターフェースを使用して、以前のグローバル構成インターフェースを置き換えます [#14484](https://github.com/tikv/tikv/issues/14484) @[HuSharp](https://github.com/HuSharp) - cf stats の書き込みによるデータ読み込み動作の判定により、スキャン性能を向上させる [#16245](https://github.com/tikv/tikv/issues/16245) @[Connor1996](https://github.com/Connor1996) - Raft設定変更プロセス中にノードが削除され、投票者が降格された最新のハートビートをチェックして、この動作によってリージョンにアクセスできなくなることがないようにしてください [#15799](https://github.com/tikv/tikv/issues/15799) @[tonyxuqqi](https://github.com/tonyxuqqi) - パイプラインDML用のFlushおよびBufferBatchGetインターフェースを追加 [#16291](https://github.com/tikv/tikv/issues/16291) @[ekexium](https://github.com/ekexium) @@ -474,7 +474,7 @@ TiDB バージョン: 8.0.0 - `SURVIVAL_PREFERENCES`ステートメントの出力に`SHOW CREATE PLACEMENT POLICY`属性が特定の条件下で表示されない問題を修正しました [#51699](https://github.com/pingcap/tidb/issues/51699) @[lcwangchao](https://github.com/lcwangchao) - 設定ファイルに無効な設定項目が含まれている場合に、設定ファイルが有効にならない問題を修正します [#51399](https://github.com/pingcap/tidb/issues/51399) @[Defined2014](https://github.com/Defined2014) -- ティクヴ +- TiKV - `tidb_enable_row_level_checksum`を有効にするとTiKVがpanicを起こす可能性がある問題を修正しました [#16371](https://github.com/tikv/tikv/issues/16371) @[cfzjywxk](https://github.com/cfzjywxk) - 例外的な状況で休止状態のリージョンがすぐに起動されない問題を修正 [#16368](https://github.com/tikv/tikv/issues/16368) @[LykxSassinator](https://github.com/LykxSassinator) @@ -503,8 +503,8 @@ TiDB バージョン: 8.0.0 - TiFlashレプリカを削除して再追加するとTiFlashでデータ破損が発生する可能性がある問題を修正 [#8695](https://github.com/pingcap/tiflash/issues/8695) @[JaySon-Huang](https://github.com/JaySon-Huang) - ポイントインタイムリカバリ(PITR) の実行後、または`FLASHBACK CLUSTER TO`の実行後にTiFlashレプリカ データが誤って削除され、データ異常が発生する可能性がある問題を修正 [#8777](https://github.com/pingcap/tiflash/issues/8777) @[JaySon-Huang](https://github.com/JaySon-Huang) - Null 許容カラムを null 許容カラム以外に変更する`ALTER TABLE ... MODIFY COLUMN ... NOT NULL`の実行後にTiFlash がパニックになる問題を修正 [#8419](https://github.com/pingcap/tiflash/issues/8419) @[JaySon-Huang](https://github.com/JaySon-Huang) - - 分散storageとコンピューティングアーキテクチャにおいて、ネットワーク分離後にクエリが永久にブロックされる可能性がある問題を修正 [#8806](https://github.com/pingcap/tiflash/issues/8806) @[JinheLin](https://github.com/JinheLin) - - 分散storageとコンピューティングアーキテクチャにおいて、 TiFlash がシャットダウン中にpanic可能性がある問題を修正 [#8837](https://github.com/pingcap/tiflash/issues/8837) @[JaySon-Huang](https://github.com/JaySon-Huang) + - 分散ストレージとコンピューティングアーキテクチャにおいて、ネットワーク分離後にクエリが永久にブロックされる可能性がある問題を修正 [#8806](https://github.com/pingcap/tiflash/issues/8806) @[JinheLin](https://github.com/JinheLin) + - 分散ストレージとコンピューティングアーキテクチャにおいて、 TiFlash がシャットダウン中にpanic可能性がある問題を修正 [#8837](https://github.com/pingcap/tiflash/issues/8837) @[JaySon-Huang](https://github.com/JaySon-Huang) - リモート読み取り時にデータ競合によりTiFlashがクラッシュする可能性がある問題を修正 [#8685](https://github.com/pingcap/tiflash/issues/8685) @[solotzg](https://github.com/solotzg) - `CAST(AS JSON)`関数が JSON オブジェクト キーの重複を削除しない問題を修正 [#8712](https://github.com/pingcap/tiflash/issues/8712) @[SeaRise](https://github.com/SeaRise) - `ENUM`列がチャンクエンコード中にTiFlashを引き起こす可能性がある問題を修正しました [#8674](https://github.com/pingcap/tiflash/issues/8674) @[yibin87](https://github.com/yibin87) @@ -524,7 +524,7 @@ TiDB バージョン: 8.0.0 - TiCDC - - storageシンク使用時にstorageサービスによって生成されるファイルシーケンス番号が正しくインクリメントされない可能性がある問題を修正しました [#10352](https://github.com/pingcap/tiflow/issues/10352) @[CharlesCheung96](https://github.com/CharlesCheung96) + - ストレージシンク使用時にストレージサービスによって生成されるファイルシーケンス番号が正しくインクリメントされない可能性がある問題を修正しました [#10352](https://github.com/pingcap/tiflow/issues/10352) @[CharlesCheung96](https://github.com/CharlesCheung96) - TiCDCが複数のチェンジフィードを同時に作成する際に`ErrChangeFeedAlreadyExists`エラーを返す問題を修正 [#10430](https://github.com/pingcap/tiflow/issues/10430) @[CharlesCheung96](https://github.com/CharlesCheung96) - `add table partition`で`ignore-event`イベントをフィルタリングした後、TiCDC が関連パーティションの他のタイプの DML 変更を下流にレプリケートしない問題を修正します。 [#10524](https://github.com/pingcap/tiflow/issues/10524) @[CharlesCheung96](https://github.com/CharlesCheung96) - アップストリームテーブルで`TRUNCATE PARTITION`が実行された後、changefeed がエラーを報告する問題を修正します [#10522](https://github.com/pingcap/tiflow/issues/10522) @[sdojjy](https://github.com/sdojjy) diff --git a/releases/release-8.1.0.md b/releases/release-8.1.0.md index 5d19cc4d354bf..1c42027042825 100644 --- a/releases/release-8.1.0.md +++ b/releases/release-8.1.0.md @@ -17,7 +17,7 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 以前のLTSバージョン7.5.0と比較して、8.1.0にはバージョン[7.6.0-DMR](/releases/release-7.6.0.md)と[8.0.0-DMR](/releases/release-8.0.0.md)でリリースされた新機能、改善、バグ修正が含まれています。7.5.xから8.1.0にアップグレードする場合は、バージョン[TiDB リリースノート PDF](https://docs-download.pingcap.com/pdf/tidb-v7.6-to-v8.1-en-release-notes.pdf)をダウンロードして、2つのLTSバージョン間のすべてのリリースノートをご覧いただけます。以下の表は、7.6.0から8.1.0への主な変更点です。 -
カテゴリ機能/拡張機能説明
スケーラビリティとパフォーマンスクラスター スナップショットの復元速度の高速化(v8.0.0 で GA)この機能により、 BRはクラスタのスケールメリットを最大限に活用し、クラスタ内のすべてのTiKVノードがデータ復元の準備ステップに参加できるようになります。この機能により、大規模クラスタにおける大規模データセットの復元速度が大幅に向上します。実環境テストでは、この機能によりダウンロード帯域幅が飽和状態になり、ダウンロード速度が8～10倍、エンドツーエンドの復元速度が約1.5～3倍向上することが示されています。
バッチでテーブルを作成する場合、最大 10 倍の高速化を実現します(実験的、v7.6.0 で導入) v7.6.0での新しいDDLアーキテクチャの実装により、バッチテーブル作成のパフォーマンスが大幅に向上し、最大10倍高速化しました。この大幅な機能強化により、多数のテーブル作成に必要な時間が大幅に短縮されます。この高速化は、数万から数十万に及ぶ大量のテーブルが頻繁に使用されるSaaSシナリオにおいて特に顕著です。
アクティブ PD フォロワーを使用して、PD のリージョン情報クエリ サービスを強化します(実験的、v7.6.0 で導入) TiDB v7.6.0では、PDフォロワーがリージョン情報クエリサービスを提供できる実験的機能「Active PD Follower 」が導入されました。この機能により、多数のTiDBノードとリージョンを持つクラスターにおいて、PDクラスターのGetRegionおよびScanRegionsリクエスト処理能力が向上し、PDリーダーのCPU負荷が軽減されます。
大規模なトランザクションのためのバルク DML (実験的、v8.0.0 で導入)大規模なクリーンアップジョブ、結合、集計といった大規模なバッチDMLジョブは、大量のメモリを消費する可能性があり、これまでは非常に大規模なスケールでは制限されていました。バルクDML（ tidb_dml_type = "bulk" ）は、トランザクション保証を提供し、OOM（メモリ不足）の問題を軽減しながら、大規模なバッチDMLタスクをより効率的に処理するための新しいDMLタイプです。この機能は、データのロードに使用する場合、インポート、ロード、リストアの各操作とは異なります。
膨大な数のテーブルがある場合のスキーマ情報のキャッシュの安定性を向上 (実験的、v8.0.0 で導入)マルチテナントアプリケーションの記録システムとしてTiDBを使用しているSaaS企業は、多くの場合、膨大な数のテーブルを保存する必要があります。以前のバージョンでは、100万個以上のテーブル数を処理することは可能でしたが、全体的なユーザーエクスペリエンスが低下する可能性がありました。TiDB v8.0.0では、 auto analyzeに優先キューを実装することで状況が改善され、プロセスの柔軟性が向上し、より広範なテーブルにわたる安定性が向上しました。
信頼性と可用性グローバルソート（v8.0.0 で GA）グローバルソート機能は、 IMPORT INTOおよびCREATE INDEXの安定性と効率性を向上させることを目的としています。処理対象のデータをグローバルにソートすることで、TiKVへのデータ書き込みの安定性、制御性、スケーラビリティが向上し、結果としてデータのインポートとインデックス作成におけるユーザーエクスペリエンスとサービス品質が向上します。グローバルソートを有効にすると、各IMPORT INTOまたはCREATE INDEXステートメントで、最大40TiBのデータのインポートまたはインデックスの追加がサポートされるようになりました。
データベース間 SQL バインディング(v7.6.0 で導入)同じスキーマを持つ数百のデータベースを管理する場合、これらのデータベース全体にSQLバインディングを適用する必要があることがよくあります。例えば、SaaSまたはPaaSデータプラットフォームでは、各ユーザーは通常、同じスキーマを持つ別々のデータベースを操作し、それらに対して類似のSQLクエリを実行します。このような場合、各データベースにSQLを個別にバインドするのは現実的ではありません。TiDB v7.6.0では、スキーマが同等なすべてのデータベース間で一致するバインディングを可能にする、データベース間SQLバインディングが導入されています。
TiProxy をサポート(v8.0.0 で GA)デプロイメント ツールを使用して簡単にデプロイできる TiProxy サービスを完全にサポートし、ローリング リスタート、アップグレード、またはスケーリング イベントを通じて TiDB への接続を管理および維持できるようにします。
データ移行（DM）はMySQL 8.0（バージョン7.6.0でGA）を正式にサポートしますこれまで、DMを使用したMySQL 8.0からのデータ移行は実験的機能であり、本番環境ではご利用いただけませんでした。TiDB v7.6.0では、この機能の安定性と互換性が向上し、本番環境においてMySQL 8.0からTiDBへのデータ移行をスムーズかつ迅速に実行できるようになります。v7.6.0では、この機能が一般提供（GA）されます。
TiDB リソース制御は、予想よりも多くのリソースを消費するクエリの管理をサポートします (v8.1.0 で GA) TiDBは、リソースグループのルールを通じて、予想以上にリソースを消費するクエリを自動的に識別し、それらのクエリを制限またはキャンセルすることができます。ルールで識別されないクエリでも、手動でクエリ特性を追加し、適切な対策を講じることで、突発的なクエリパフォーマンスの問題がデータベース全体に与える影響を軽減できます。
DB操作と可観測性インデックス使用状況統計の監視をサポート（v8.0.0 で導入）適切なインデックス設計は、データベースのパフォーマンス維持に不可欠な前提条件です。TiDB v8.0.0では、インデックスの使用状況統計を提供するINFORMATION_SCHEMA.TIDB_INDEX_USAGEテーブルとsys.schema_unused_indexesビューが導入されました。この機能は、データベース内のインデックスの効率性を評価し、インデックス設計を最適化するのに役立ちます。
データ移行TiCDC はシンプルプロトコルをサポートしています (v8.0.0 で導入) TiCDCは、新しいプロトコル「Simpleプロトコル」を導入しました。このプロトコルは、DDLおよびBOOTSTRAPイベントにテーブルスキーマ情報を埋め込むことで、インバンドスキーマ追跡機能を提供します。
TiCDC はDebezium 形式プロトコル(v8.0.0 で導入) をサポートしています。 TiCDC は新しいプロトコル、Debezium プロトコルを導入しました。TiCDC は、Debezium スタイルのメッセージを生成するプロトコルを使用して、データ変更イベントを Kafka シンクにパブリッシュできるようになりました。
TiCDC はクライアント認証をサポートしています (v8.1.0 で導入) TiCDCは、相互トランスポート層Security（mTLS）またはTiDBユーザー名とパスワードを使用したクライアント認証をサポートしています。この機能により、CLIまたはOpenAPIクライアントはTiCDCへの接続を認証できます。
+
カテゴリ機能/拡張機能説明
スケーラビリティとパフォーマンスクラスター スナップショットの復元速度の高速化(v8.0.0 で GA)この機能により、 BRはクラスターのスケールメリットを最大限に活用し、クラスター内のすべてのTiKVノードがデータ復元の準備ステップに参加できるようになります。この機能により、大規模クラスターにおける大規模データセットの復元速度が大幅に向上します。実環境テストでは、この機能によりダウンロード帯域幅が飽和状態になり、ダウンロード速度が8～10倍、エンドツーエンドの復元速度が約1.5～3倍向上することが示されています。
バッチでテーブルを作成する場合、最大 10 倍の高速化を実現します(実験的、v7.6.0 で導入) v7.6.0での新しいDDLアーキテクチャの実装により、バッチテーブル作成のパフォーマンスが大幅に向上し、最大10倍高速化しました。この大幅な機能強化により、多数のテーブル作成に必要な時間が大幅に短縮されます。この高速化は、数万から数十万に及ぶ大量のテーブルが頻繁に使用されるSaaSシナリオにおいて特に顕著です。
アクティブ PD フォロワーを使用して、PD のリージョン情報クエリ サービスを強化します(実験的、v7.6.0 で導入) TiDB v7.6.0では、PDフォロワーがリージョン情報クエリサービスを提供できる実験的機能「Active PD Follower 」が導入されました。この機能により、多数のTiDBノードとリージョンを持つクラスターにおいて、PDクラスターのGetRegionおよびScanRegionsリクエスト処理能力が向上し、PDリーダーのCPU負荷が軽減されます。
大規模なトランザクションのためのバルク DML (実験的、v8.0.0 で導入)大規模なクリーンアップジョブ、結合、集計といった大規模なバッチDMLジョブは、大量のメモリを消費する可能性があり、これまでは非常に大規模なスケールでは制限されていました。バルクDML（ tidb_dml_type = "bulk" ）は、トランザクション保証を提供し、OOM（メモリ不足）の問題を軽減しながら、大規模なバッチDMLタスクをより効率的に処理するための新しいDMLタイプです。この機能は、データのロードに使用する場合、インポート、ロード、リストアの各操作とは異なります。
膨大な数のテーブルがある場合のスキーマ情報のキャッシュの安定性を向上 (実験的、v8.0.0 で導入)マルチテナントアプリケーションの記録システムとしてTiDBを使用しているSaaS企業は、多くの場合、膨大な数のテーブルを保存する必要があります。以前のバージョンでは、100万個以上のテーブル数を処理することは可能でしたが、全体的なユーザーエクスペリエンスが低下する可能性がありました。TiDB v8.0.0では、 auto analyzeに優先キューを実装することで状況が改善され、プロセスの柔軟性が向上し、より広範なテーブルにわたる安定性が向上しました。
信頼性と可用性グローバルソート（v8.0.0 で GA）グローバルソート機能は、 IMPORT INTOおよびCREATE INDEXの安定性と効率性を向上させることを目的としています。処理対象のデータをグローバルにソートすることで、TiKVへのデータ書き込みの安定性、制御性、スケーラビリティが向上し、結果としてデータのインポートとインデックス作成におけるユーザーエクスペリエンスとサービス品質が向上します。グローバルソートを有効にすると、各IMPORT INTOまたはCREATE INDEXステートメントで、最大40TiBのデータのインポートまたはインデックスの追加がサポートされるようになりました。
データベース間 SQL バインディング(v7.6.0 で導入)同じスキーマを持つ数百のデータベースを管理する場合、これらのデータベース全体にSQLバインディングを適用する必要があることがよくあります。例えば、SaaSまたはPaaSデータプラットフォームでは、各ユーザーは通常、同じスキーマを持つ別々のデータベースを操作し、それらに対して類似のSQLクエリを実行します。このような場合、各データベースにSQLを個別にバインドするのは現実的ではありません。TiDB v7.6.0では、スキーマが同等なすべてのデータベース間で一致するバインディングを可能にする、データベース間SQLバインディングが導入されています。
TiProxy をサポート(v8.0.0 で GA)デプロイメント ツールを使用して簡単にデプロイできる TiProxy サービスを完全にサポートし、ローリング リスタート、アップグレード、またはスケーリング イベントを通じて TiDB への接続を管理および維持できるようにします。
データ移行（DM）はMySQL 8.0（バージョン7.6.0でGA）を正式にサポートしますこれまで、DMを使用したMySQL 8.0からのデータ移行は実験的機能であり、本番環境ではご利用いただけませんでした。TiDB v7.6.0では、この機能の安定性と互換性が向上し、本番環境においてMySQL 8.0からTiDBへのデータ移行をスムーズかつ迅速に実行できるようになります。v7.6.0では、この機能が一般提供（GA）されます。
TiDB リソース制御は、予想よりも多くのリソースを消費するクエリの管理をサポートします (v8.1.0 で GA) TiDBは、リソースグループのルールを通じて、予想以上にリソースを消費するクエリを自動的に識別し、それらのクエリを制限またはキャンセルすることができます。ルールで識別されないクエリでも、手動でクエリ特性を追加し、適切な対策を講じることで、突発的なクエリパフォーマンスの問題がデータベース全体に与える影響を軽減できます。
DB操作と可観測性インデックス使用状況統計の監視をサポート（v8.0.0 で導入）適切なインデックス設計は、データベースのパフォーマンス維持に不可欠な前提条件です。TiDB v8.0.0では、インデックスの使用状況統計を提供するINFORMATION_SCHEMA.TIDB_INDEX_USAGEテーブルとsys.schema_unused_indexesビューが導入されました。この機能は、データベース内のインデックスの効率性を評価し、インデックス設計を最適化するのに役立ちます。
データ移行TiCDC はシンプルプロトコルをサポートしています (v8.0.0 で導入) TiCDCは、新しいプロトコル「Simpleプロトコル」を導入しました。このプロトコルは、DDLおよびBOOTSTRAPイベントにテーブルスキーマ情報を埋め込むことで、インバンドスキーマ追跡機能を提供します。
TiCDC はDebezium 形式プロトコル(v8.0.0 で導入) をサポートしています。 TiCDC は新しいプロトコル、Debezium プロトコルを導入しました。TiCDC は、Debezium スタイルのメッセージを生成するプロトコルを使用して、データ変更イベントを Kafka シンクにパブリッシュできるようになりました。
TiCDC はクライアント認証をサポートしています (v8.1.0 で導入) TiCDCは、相互トランスポート層Security（mTLS）またはTiDBユーザー名とパスワードを使用したクライアント認証をサポートしています。この機能により、CLIまたはOpenAPIクライアントはTiCDCへの接続を認証できます。
## 機能の詳細 {#feature-details} @@ -108,9 +108,9 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 | [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710) | 修正済み | デフォルト値を`OFF`から`ON`に変更します。これは、Distributed eXecution Framework（DXF）がデフォルトで有効になることを意味します。これにより、TiDBクラスターのリソースが最大限に活用され、 `ADD INDEX`および`IMPORT INTO`タスクのパフォーマンスが大幅に向上します。DXFが有効になっているクラスターをv8.1.0以降にアップグレードする場合は、アップグレード前にDXFを無効にしてください（ `tidb_enable_dist_task`を`OFF`に設定）。これにより、アップグレード中に`ADD INDEX`操作が発生し、データインデックスの不整合が発生するのを回避できます。アップグレード後、DXFを手動で有効にすることができます。 | | [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740) | 修正済み | オプションの値を`""`または`background`から最大 64 文字の文字列に変更します。これにより、各 TiDB ノードのサービス範囲をより柔軟に制御できます。有効な文字は、数字`0-9` 、文字`a-zA-Z` 、アンダースコア`_` 、ハイフン`-`です。Distributed eXecution Framework (DXF) は、この変数の値に基づいて、どの TiDB ノードに分散タスクの実行をスケジュールするかを決定します。具体的なルールについては、 [タスクのスケジュール](/tidb-distributed-execution-framework.md#task-scheduling)参照してください。 | -### コンフィグレーションファイルのパラメータ {#configuration-file-parameters} +### 設定ファイルのパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | タイプを変更 | 説明 | +| 設定ファイル | 設定パラメータ | タイプを変更 | 説明 | | -------------- | --------------------------------------------------------------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`enable-telemetry`](/tidb-configuration-file.md#enable-telemetry-new-in-v402) | 非推奨 | v8.1.0以降、TiDBのテレメトリ機能は削除され、この設定項目は機能しなくなりました。これは以前のバージョンとの互換性のためだけに保持されています。 | | TiDB | [`concurrently-init-stats`](/tidb-configuration-file.md#concurrently-init-stats-new-in-v810-and-v752) | 新しく追加された | TiDBの起動時に統計を同時に初期化するかどうかを制御します。デフォルト値は`false`です。 | @@ -243,9 +243,9 @@ TiDB 8.1.0 は長期サポートリリース (LTS) です。 - 非厳密な`sql_mode` [＃8803](https://github.com/pingcap/tiflash/issues/8803) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger)で無効なデフォルト値を持つ列にデータを挿入するとTiFlash がpanic可能性がある問題を修正しました - TiFlash が高同時読み取りシナリオで一時的に誤った結果を返す可能性がある問題を修正[＃8845](https://github.com/pingcap/tiflash/issues/8845) @ [JinheLin](https://github.com/JinheLin) - - 分散storageおよびコンピューティングアーキテクチャで、 TiFlashコンピューティングノード[＃8920](https://github.com/pingcap/tiflash/issues/8920) @ [JinheLin](https://github.com/JinheLin)の`storage.remote.cache.capacity`構成項目の値を変更した後、Grafanaに表示されるディスク`used_size`メトリックが正しくないという問題を修正しました。 - - クラスタをv6.5.0より前のバージョンからv6.5.0以降にアップグレードするときに、 TiFlashメタデータが破損してプロセスがpanicになる可能性がある問題を修正しました[＃9039](https://github.com/pingcap/tiflash/issues/9039) @ [JaySon-Huang](https://github.com/JaySon-Huang) - - 分散storageとコンピューティングアーキテクチャで、コンピューティングノードのプロセスが停止するとTiFlash がpanic可能性がある問題を修正しました[＃8860](https://github.com/pingcap/tiflash/issues/8860) @ [guo-shaoge](https://github.com/guo-shaoge) + - 分散ストレージおよびコンピューティングアーキテクチャで、 TiFlashコンピューティングノード[＃8920](https://github.com/pingcap/tiflash/issues/8920) @ [JinheLin](https://github.com/JinheLin)の`ストレージ.remote.cache.capacity`構成項目の値を変更した後、Grafanaに表示されるディスク`used_size`メトリックが正しくないという問題を修正しました。 + - クラスターをv6.5.0より前のバージョンからv6.5.0以降にアップグレードするときに、 TiFlashメタデータが破損してプロセスがpanicになる可能性がある問題を修正しました[＃9039](https://github.com/pingcap/tiflash/issues/9039) @ [JaySon-Huang](https://github.com/JaySon-Huang) + - 分散ストレージとコンピューティングアーキテクチャで、コンピューティングノードのプロセスが停止するとTiFlash がpanic可能性がある問題を修正しました[＃8860](https://github.com/pingcap/tiflash/issues/8860) @ [guo-shaoge](https://github.com/guo-shaoge) - 仮想生成列[＃8787](https://github.com/pingcap/tiflash/issues/8787) @ [guo-shaoge](https://github.com/guo-shaoge)を含むクエリを実行するとTiFlash がエラーを返す可能性がある問題を修正しました - ツール diff --git a/releases/release-8.1.1.md b/releases/release-8.1.1.md index 687c5a077a7a8..ca51d3658ac46 100644 --- a/releases/release-8.1.1.md +++ b/releases/release-8.1.1.md @@ -56,7 +56,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - TiCDC - シンプルプロトコルを使用したチェンジフィードが[＃11315](https://github.com/pingcap/tiflow/issues/11315) @ [asddongmen](https://github.com/asddongmen)で開始されたときに、すべてのテーブルの BOOTSTRAP メッセージをダウンストリームに一度に送信することをサポートします。 - - ダウンストリームがメッセージキュー（MQ）またはクラウドstorageの場合、生のイベントを直接出力することをサポート[＃11211](https://github.com/pingcap/tiflow/issues/11211) @ [CharlesCheung96](https://github.com/CharlesCheung96) + - ダウンストリームがメッセージキュー（MQ）またはクラウドストレージの場合、生のイベントを直接出力することをサポート[＃11211](https://github.com/pingcap/tiflow/issues/11211) @ [CharlesCheung96](https://github.com/CharlesCheung96) ## バグ修正 {#bug-fixes} @@ -96,7 +96,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - `memory_quota`ヒントがサブクエリ[＃53834](https://github.com/pingcap/tidb/issues/53834) @ [qw4990](https://github.com/qw4990)で機能しない可能性がある問題を修正しました - 起動時に統計情報をロードするときに、TiDB が GC によるエラーを報告する可能性がある問題を修正[＃53592](https://github.com/pingcap/tidb/issues/53592) @ [you06](https://github.com/you06) - `CREATE OR REPLACE VIEW`同時に実行すると`table doesn't exist`エラー[＃53673](https://github.com/pingcap/tidb/issues/53673) @ [tangenta](https://github.com/tangenta)が発生する可能性がある問題を修正 - - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、古い読み取りのクエリレイテンシーが増加する問題を修正しました。 + - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、ステイル読み取りのクエリレイテンシーが増加する問題を修正しました。 - クラスター化インデックスを述語として使用すると`SELECT INTO OUTFILE`機能しない問題を修正[＃42093](https://github.com/pingcap/tidb/issues/42093) @ [qw4990](https://github.com/qw4990) - `YEAR`型の列を範囲外の符号なし整数と比較すると誤った結果が発生する問題を修正[＃50235](https://github.com/pingcap/tidb/issues/50235) @ [qw4990](https://github.com/qw4990) - データ変更操作[＃53951](https://github.com/pingcap/tidb/issues/53951) @ [qw4990](https://github.com/qw4990)を含むトランザクションで仮想列を持つテーブルをクエリすると、TiDB が誤ったクエリ結果を返す可能性がある問題を修正しました @@ -117,7 +117,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - TiDB Lightning物理インポートモードの初期化中にエラーが発生し、リソースリークが発生する可能性がある問題を修正[＃53659](https://github.com/pingcap/tidb/issues/53659) @ [D3Hunter](https://github.com/D3Hunter) - ビュー定義[＃54343](https://github.com/pingcap/tidb/issues/54343) @ [lance6716](https://github.com/lance6716)でサブクエリが列定義として使用されている場合、 `information_schema.columns`を使用して列情報を取得すると警告1356が返される問題を修正しました。 - インデックスアクセラレーションを使用して一意のインデックスを追加すると、所有者が[＃49233](https://github.com/pingcap/tidb/issues/49233) @ [lance6716](https://github.com/lance6716)に切り替えられたときに`Duplicate entry`エラーが発生する可能性がある問題を修正しました。 - - `global.tidb_cloud_storage_uri` [＃54096](https://github.com/pingcap/tidb/issues/54096) @ [lance6716](https://github.com/lance6716)を設定するときに不明瞭なエラーメッセージが表示される問題を修正しました + - `global.tidb_cloud_ストレージ_uri` [＃54096](https://github.com/pingcap/tidb/issues/54096) @ [lance6716](https://github.com/lance6716)を設定するときに不明瞭なエラーメッセージが表示される問題を修正しました - 同期負荷QPSモニタリングメトリックが正しくない問題を修正[＃53558](https://github.com/pingcap/tidb/issues/53558) @ [hawkingrei](https://github.com/hawkingrei) - 初期統計を同時に[＃53607](https://github.com/pingcap/tidb/issues/53607) @ [hawkingrei](https://github.com/hawkingrei)でロードするときに一部の統計情報が失われる可能性がある問題を修正しました - `SELECT ... FOR UPDATE` [＃54652](https://github.com/pingcap/tidb/issues/54652) @ [qw4990](https://github.com/qw4990)の間違ったポイント取得プランを再利用する問題を修正しました @@ -164,7 +164,7 @@ v8.1.1 では、 `TiDB-community-toolkit` [バイナリパッケージ](/binary- - BRまたはTiDB Lightning [＃9118](https://github.com/pingcap/tiflash/issues/9118) @ [JinheLin](https://github.com/JinheLin)経由でデータをインポートした後、FastScanモードで多数の重複行が読み取られる可能性がある問題を修正しました。 - データベースが作成直後に削除されるとTiFlash がpanic可能性がある問題を修正[＃9266](https://github.com/pingcap/tiflash/issues/9266) @ [JaySon-Huang](https://github.com/JaySon-Huang) - TiFlashで SSL 証明書の構成を空の文字列に設定すると、誤って TLS が有効になり、 TiFlash が起動しなくなる問題を修正しました[＃9235](https://github.com/pingcap/tiflash/issues/9235) @ [JaySon-Huang](https://github.com/JaySon-Huang) - - 分散storageおよびコンピューティングアーキテクチャで、DDL操作[＃9084](https://github.com/pingcap/tiflash/issues/9084) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger)で非NULL列を追加した後にクエリでNULL値が誤って返される可能性がある問題を修正しました。 + - 分散ストレージおよびコンピューティングアーキテクチャで、DDL操作[＃9084](https://github.com/pingcap/tiflash/issues/9084) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger)で非NULL列を追加した後にクエリでNULL値が誤って返される可能性がある問題を修正しました。 - データベース[＃9132](https://github.com/pingcap/tiflash/issues/9132) @ [JaySon-Huang](https://github.com/JaySon-Huang)にまたがる空のパーティションを持つパーティションテーブルで`RENAME TABLE ... TO ...`実行した後にTiFlash がpanic可能性がある問題を修正しました。 - 空のパーティション[＃9024](https://github.com/pingcap/tiflash/issues/9024) @ [JinheLin](https://github.com/JinheLin)を含むパーティション テーブルでクエリを実行するときに発生するクエリ タイムアウトの問題を修正しました。 - 遅延マテリアライゼーションが有効になった後に、一部のクエリで列タイプの不一致エラーが報告される可能性がある問題を修正[＃9175](https://github.com/pingcap/tiflash/issues/9175) @ [JinheLin](https://github.com/JinheLin) diff --git a/releases/release-8.1.2.md b/releases/release-8.1.2.md index d6fec6b2d54fd..c9a65ec5fcb58 100644 --- a/releases/release-8.1.2.md +++ b/releases/release-8.1.2.md @@ -30,16 +30,16 @@ TiDB バージョン: 8.1.2 - TiKVの`DiskFull`検出を最適化してRaftEngineの`spill-dir`構成と互換性を持たせ、この機能が[＃17356](https://github.com/tikv/tikv/issues/17356) @ [LykxSassinator](https://github.com/LykxSassinator)で一貫して動作することを保証します。 - RocksDB 圧縮のトリガー メカニズムを最適化し、多数の DELETE バージョン[＃17269](https://github.com/tikv/tikv/issues/17269) @ [AndreMouche](https://github.com/AndreMouche)を処理するときにディスク領域の再利用を高速化します。 - `import.num-threads`構成項目を動的に変更するサポート[＃17807](https://github.com/tikv/tikv/issues/17807) @ [RidRisR](https://github.com/RidRisR) - - Rusoto ライブラリを AWS Rust SDK に置き換えて、バックアップと復元のために外部storage(Amazon S3 など) にアクセスします。これにより、IMDSv2 や EKS Pod Identity [＃12371](https://github.com/tikv/tikv/issues/12371) @ [akoshchiy](https://github.com/akoshchiy)などの AWS 機能との互換性が向上します。 + - Rusoto ライブラリを AWS Rust SDK に置き換えて、バックアップと復元のために外部ストレージ(Amazon S3 など) にアクセスします。これにより、IMDSv2 や EKS Pod Identity [＃12371](https://github.com/tikv/tikv/issues/12371) @ [akoshchiy](https://github.com/akoshchiy)などの AWS 機能との互換性が向上します。 - TiFlash - クラスター化インデックス[＃9529](https://github.com/pingcap/tiflash/issues/9529) @ [JaySon-Huang](https://github.com/JaySon-Huang)を持つテーブルで、バックグラウンドでの古いデータのガベージコレクションの速度が向上しました。 - TLS を有効にした後に証明書を更新することでTiFlash がpanic可能性がある問題を軽減します[＃8535](https://github.com/pingcap/tiflash/issues/8535) @ [windtalker](https://github.com/windtalker) - - 分散storageとコンピューティング要求を処理するときにTiFlash が作成する必要があるスレッドの数を減らし、大量のそのような要求を処理するときにTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます[＃9334](https://github.com/pingcap/tiflash/issues/9334) @ [JinheLin](https://github.com/JinheLin) + - 分散ストレージとコンピューティング要求を処理するときにTiFlash が作成する必要があるスレッドの数を減らし、大量のそのような要求を処理するときにTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます[＃9334](https://github.com/pingcap/tiflash/issues/9334) @ [JinheLin](https://github.com/JinheLin) - JOIN演算子のキャンセルメカニズムを改善し、JOIN演算子がキャンセル要求にタイムリーに応答できるようにします[＃9430](https://github.com/pingcap/tiflash/issues/9430) @ [windtalker](https://github.com/windtalker) - `LENGTH()`と`ASCII()`関数[＃9344](https://github.com/pingcap/tiflash/issues/9344) @ [xzhangxian1008](https://github.com/xzhangxian1008)の実行効率を最適化 - - 分散storageおよびコンピューティングアーキテクチャ内のTiFlashコンピューティングノードの再試行戦略を最適化して、Amazon S3 [＃9695](https://github.com/pingcap/tiflash/issues/9695) @ [JinheLin](https://github.com/JinheLin)からファイルをダウンロードする際の例外を処理します。 + - 分散ストレージおよびコンピューティングアーキテクチャ内のTiFlashコンピューティングノードの再試行戦略を最適化して、Amazon S3 [＃9695](https://github.com/pingcap/tiflash/issues/9695) @ [JinheLin](https://github.com/JinheLin)からファイルをダウンロードする際の例外を処理します。 - ツール @@ -81,7 +81,7 @@ TiDB バージョン: 8.1.2 - TTLタスクをキャンセルした際に、対応するSQLが強制終了されない問題を修正[＃56511](https://github.com/pingcap/tidb/issues/56511) @ [lcwangchao](https://github.com/lcwangchao) - `IMPORT INTO`文[＃55970](https://github.com/pingcap/tidb/issues/55970) @ [D3Hunter](https://github.com/D3Hunter)を使用して一時テーブルをインポートするときに TiDB がパニックになる問題を修正しました - クエリ条件`column IS NULL` [＃56116](https://github.com/pingcap/tidb/issues/56116) @ [hawkingrei](https://github.com/hawkingrei)でユニークインデックスにアクセスするときに、オプティマイザが行数を誤って 1 と推定する問題を修正しました。 - - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、古い読み取りのクエリレイテンシーが増加する問題を修正しました。 + - 情報スキーマキャッシュミス[＃53428](https://github.com/pingcap/tidb/issues/53428) @ [crazycs520](https://github.com/crazycs520)により、ステイル読み取りのクエリレイテンシーが増加する問題を修正しました。 - `UPDATE`文が`ENUM`型[＃56832](https://github.com/pingcap/tidb/issues/56832) @ [xhebox](https://github.com/xhebox)の値を誤って更新する問題を修正しました - 外部キー[＃56456](https://github.com/pingcap/tidb/issues/56456) @ [hawkingrei](https://github.com/hawkingrei)を含むテーブル構造をインポートするときに Plan Replayer がエラーを報告する可能性がある問題を修正しました。 - `tidb_ttl_job_enable`変数が無効になった後、TTL タスクがキャンセルされない問題を修正[＃57404](https://github.com/pingcap/tidb/issues/57404) @ [YangKeao](https://github.com/YangKeao) @@ -130,11 +130,11 @@ TiDB バージョン: 8.1.2 - テーブルに無効な文字[＃9461](https://github.com/pingcap/tiflash/issues/9461) @ [Lloyd-Pottiger](https://github.com/Lloyd-Pottiger)を含むデフォルト値を持つビット型の列が含まれている場合、 TiFlash がテーブル スキーマを解析できない問題を修正しました。 - TiFlashでサポートされていない一部の JSON関数がTiFlash [＃9444](https://github.com/pingcap/tiflash/issues/9444) @ [windtalker](https://github.com/windtalker)にプッシュダウンされる問題を修正しました - 特定のケースで関数`CAST AS DECIMAL`の結果の符号が正しくない問題を修正[＃9301](https://github.com/pingcap/tiflash/issues/9301) @ [guo-shaoge](https://github.com/guo-shaoge) - - 分散storageおよびコンピューティングアーキテクチャ[＃9298](https://github.com/pingcap/tiflash/issues/9298) @ [JinheLin](https://github.com/JinheLin)で、 TiFlash書き込みノードの読み取りスナップショットがタイムリーにリリースされない問題を修正しました。 + - 分散ストレージおよびコンピューティングアーキテクチャ[＃9298](https://github.com/pingcap/tiflash/issues/9298) @ [JinheLin](https://github.com/JinheLin)で、 TiFlash書き込みノードの読み取りスナップショットがタイムリーにリリースされない問題を修正しました。 - `SUBSTRING()`関数が特定の整数型に対して`pos`と`len`引数をサポートせず、クエリエラー[＃9473](https://github.com/pingcap/tiflash/issues/9473) @ [gengliqi](https://github.com/gengliqi)が発生する問題を修正しました - `CAST()`関数を使用して文字列をタイムゾーンまたは無効な文字を含む日付時刻に変換すると、結果が正しくなくなる問題を修正しました[＃8754](https://github.com/pingcap/tiflash/issues/8754) @ [solotzg](https://github.com/solotzg) - `LPAD()`と`RPAD()`関数が、場合によっては誤った結果を返す問題を修正しました[＃9465](https://github.com/pingcap/tiflash/issues/9465) @ [guo-shaoge](https://github.com/guo-shaoge) - - 分散storageおよびコンピューティングアーキテクチャ[＃9665](https://github.com/pingcap/tiflash/issues/9665) @ [zimulala](https://github.com/zimulala)で新しい列をクエリすると誤った結果が返される可能性がある問題を修正しました + - 分散ストレージおよびコンピューティングアーキテクチャ[＃9665](https://github.com/pingcap/tiflash/issues/9665) @ [zimulala](https://github.com/zimulala)で新しい列をクエリすると誤った結果が返される可能性がある問題を修正しました - ツール @@ -142,7 +142,7 @@ TiDB バージョン: 8.1.2 - ログに暗号化された情報[＃57585](https://github.com/pingcap/tidb/issues/57585) @ [kennytm](https://github.com/kennytm)が出力される問題を修正 - AWS EBS に基づくスナップショットバックアップが準備フェーズで失敗し、バックアップが[＃52049](https://github.com/pingcap/tidb/issues/52049) @ [YuJuncen](https://github.com/YuJuncen)で停止する可能性がある問題を修正しました。 - - バックアップと復元のチェックポイントパスが一部の外部storageと互換性がない問題を修正[＃55265](https://github.com/pingcap/tidb/issues/55265) @ [Leavrth](https://github.com/Leavrth) + - バックアップと復元のチェックポイントパスが一部の外部ストレージと互換性がない問題を修正[＃55265](https://github.com/pingcap/tidb/issues/55265) @ [Leavrth](https://github.com/Leavrth) - `k8s.io/api`ライブラリバージョン[＃57790](https://github.com/pingcap/tidb/issues/57790) @ [BornChanger](https://github.com/BornChanger)にアップグレードして潜在的なセキュリティ脆弱性を修正します - クラスター内に多数のテーブルがあるが、実際のデータサイズが小さい場合に PITR タスクが`Information schema is out of date`エラーを返す可能性がある問題を修正しました[＃57743](https://github.com/pingcap/tidb/issues/57743) @ [Tristan1900](https://github.com/Tristan1900) diff --git a/releases/release-8.2.0.md b/releases/release-8.2.0.md index 3e066a4fca56e..9e1a7bc9e5d9b 100644 --- a/releases/release-8.2.0.md +++ b/releases/release-8.2.0.md @@ -13,7 +13,7 @@ TiDB バージョン: 8.2.0 バージョン8.2.0では、以下の主要な機能と改善点が導入されています。 -
カテゴリ機能／改善点説明
信頼性と可用性TiProxyは複数のロードバランシングポリシーをサポートしています。 TiDB v8.2.0では、TiProxyはステータス、接続数、健全性、メモリ、CPU、ロケーションなど、さまざまな要素に基づいてTiDBノードを評価し、ランク付けします。 policy構成項目で指定された負荷分散ポリシーに従って、TiProxyはデータベース操作を実行する最適なTiDBノードを動的に選択します。これにより、リソース使用率全体が最適化され、クラスタのパフォーマンスが向上し、スループットが増加します。
TiDB の並列 HashAgg アルゴリズムはディスク スピル (GA) をサポートしますHashAgg は、同じフィールド値を持つ行を効率的に集計するために TiDB で広く使用されている集計演算子です。TiDB v8.0.0 では、処理速度をさらに向上させる実験的機能として parallel HashAgg が導入されました。メモリリソースが不足している場合、parallel HashAgg は一時的にソートされたデータをディスクに書き出すことで、過剰なメモリ使用による潜在的な OOM リスクを回避します。これにより、ノードの安定性を維持しながらクエリ パフォーマンスが向上します。v8.2.0 では、この機能が一般提供 (GA) となり、デフォルトで有効になっているため、 tidb_executor_concurrencyを使用して parallel HashAgg の同時実行性を安全に構成できます。
統計情報の読み込み効率を最大10倍向上SaaSやPaaSサービスなど、テーブルとパーティションの数が多いクラスタでは、統計情報のロード効率を改善することで、TiDBインスタンスの起動速度低下の問題を解決し、統計情報の動的ロードの成功率を高めることができます。この改善により、統計情報のロード失敗によるパフォーマンス低下が軽減され、クラスタの安定性が向上します。
データベースの運用と可観測性リソースグループの切り替えに対する特権制御を導入するリソース制御は広く利用されているため、リソースグループの切り替えに関する権限制御は、データベースユーザーによるリソースの不正使用を防ぎ、管理者によるリソース使用全体の保護を強化し、クラスタの安定性を向上させることができる。
+
カテゴリ機能／改善点説明
信頼性と可用性TiProxyは複数のロードバランシングポリシーをサポートしています。 TiDB v8.2.0では、TiProxyはステータス、接続数、健全性、メモリ、CPU、ロケーションなど、さまざまな要素に基づいてTiDBノードを評価し、ランク付けします。 policy構成項目で指定された負荷分散ポリシーに従って、TiProxyはデータベース操作を実行する最適なTiDBノードを動的に選択します。これにより、リソース使用率全体が最適化され、クラスターのパフォーマンスが向上し、スループットが増加します。
TiDB の並列 HashAgg アルゴリズムはディスク スピル (GA) をサポートしますHashAgg は、同じフィールド値を持つ行を効率的に集計するために TiDB で広く使用されている集計演算子です。TiDB v8.0.0 では、処理速度をさらに向上させる実験的機能として parallel HashAgg が導入されました。メモリリソースが不足している場合、parallel HashAgg は一時的にソートされたデータをディスクに書き出すことで、過剰なメモリ使用による潜在的な OOM リスクを回避します。これにより、ノードの安定性を維持しながらクエリ パフォーマンスが向上します。v8.2.0 では、この機能が一般提供 (GA) となり、デフォルトで有効になっているため、 tidb_executor_concurrencyを使用して parallel HashAgg の同時実行性を安全に構成できます。
統計情報の読み込み効率を最大10倍向上SaaSやPaaSサービスなど、テーブルとパーティションの数が多いクラスターでは、統計情報のロード効率を改善することで、TiDBインスタンスの起動速度低下の問題を解決し、統計情報の動的ロードの成功率を高めることができます。この改善により、統計情報のロード失敗によるパフォーマンス低下が軽減され、クラスターの安定性が向上します。
データベースの運用と可観測性リソースグループの切り替えに対する特権制御を導入するリソース制御は広く利用されているため、リソースグループの切り替えに関する権限制御は、データベースユーザーによるリソースの不正使用を防ぎ、管理者によるリソース使用全体の保護を強化し、クラスターの安定性を向上させることができる。
## 機能の詳細 {#feature-details} @@ -57,7 +57,7 @@ TiDB バージョン: 8.2.0 TiProxyはTiDBの公式プロキシコンポーネントであり、クライアントとTiDBサーバーの間に配置されます。TiProxyはTiDBの負荷分散機能と接続維持関数を提供します。v8.2.0より前のバージョンでは、TiProxyはデフォルトでv1.0.0を使用しており、TiDBサーバーに対してステータスベースおよび接続数ベースの負荷分散ポリシーのみをサポートしています。 - バージョン8.2.0以降、TiProxyはデフォルトでバージョン1.1.0となり、複数の負荷分散ポリシーが導入されました。ステータスベースおよび接続数ベースのポリシーに加え、TiProxyは健全性、メモリ、CPU、およびロケーションに基づいた動的な負荷分散をサポートし、TiDBクラスタの安定性を向上させます。 + バージョン8.2.0以降、TiProxyはデフォルトでバージョン1.1.0となり、複数の負荷分散ポリシーが導入されました。ステータスベースおよび接続数ベースのポリシーに加え、TiProxyは健全性、メモリ、CPU、およびロケーションに基づいた動的な負荷分散をサポートし、TiDBクラスターの安定性を向上させます。 [`policy`](/tiproxy/tiproxy-configuration.md#policy)設定項目を通じて、負荷分散ポリシーの組み合わせと優先順位を設定できます。 @@ -79,7 +79,7 @@ TiDB バージョン: 8.2.0 - TiUPはPDマイクロサービスのデプロイをサポートします [#5766](https://github.com/tikv/pd/issues/5766) @[rleungx](https://github.com/rleungx) - バージョン8.0.0以降、PDはマイクロサービスモードをサポートしています。このモードでは、PDのタイムスタンプ割り当て機能とクラスタスケジューリング関数が、それぞれ独立してデプロイ可能な個別のマイクロサービスに分割されます。これにより、リソース制御と分離性が向上し、異なるサービス間の影響が軽減されます。バージョン8.2.0より前は、PDマイクロサービスはTiDB Operatorを使用してのみデプロイできます。 + バージョン8.0.0以降、PDはマイクロサービスモードをサポートしています。このモードでは、PDのタイムスタンプ割り当て機能とクラスタースケジューリング関数が、それぞれ独立してデプロイ可能な個別のマイクロサービスに分割されます。これにより、リソース制御と分離性が向上し、異なるサービス間の影響が軽減されます。バージョン8.2.0より前は、PDマイクロサービスはTiDB Operatorを使用してのみデプロイできます。 バージョン8.2.0以降、PDマイクロサービスはTiUPを使用してデプロイすることもできます。クラスター内で`tso`マイクロサービスと`scheduling`マイクロサービスを個別にデプロイすることで、PDのパフォーマンス拡張性を向上させ、大規模クラスターにおけるPDのパフォーマンスボトルネックを解消できます。このモードは、スケールアップでは解決できないほどPDが深刻なパフォーマンスボトルネックになった場合に推奨されます。 @@ -115,7 +115,7 @@ TiDB バージョン: 8.2.0 - 複数の変更フィード間で TiCDC 同期ポイントを調整する [#11212](https://github.com/pingcap/tiflow/issues/11212) @[hongyunyan](https://github.com/hongyunyan) - バージョン 8.2.0 より前は、複数のチェンジフィード間で TiCDC 同期ポイントを整合させるのは困難でした。チェンジフィードの作成時に、他のチェンジフィードの同期ポイントと整合するように、チェンジフィードの`startTs` `sync-point-interval`構成の倍数として作成されます。この変更により、同じ`sync-point-interval`構成を持つ複数のチェンジフィード間で同期ポイントを整合させることが可能になり、複数のダウンストリーム クラスタの整合が簡素化され、機能が向上します。 + バージョン 8.2.0 より前は、複数のチェンジフィード間で TiCDC 同期ポイントを整合させるのは困難でした。チェンジフィードの作成時に、他のチェンジフィードの同期ポイントと整合するように、チェンジフィードの`startTs` `sync-point-interval`構成の倍数として作成されます。この変更により、同じ`sync-point-interval`構成を持つ複数のチェンジフィード間で同期ポイントを整合させることが可能になり、複数のダウンストリーム クラスターの整合が簡素化され、機能が向上します。 詳細については、 [ドキュメント](/ticdc/ticdc-upstream-downstream-check.md#notes)を参照してください。 @@ -137,7 +137,7 @@ TiDB バージョン: 8.2.0 - [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用して CSV ファイルをインポートする場合、大きな CSV ファイルを複数の小さな CSV ファイルに分割して同時実行性とインポート パフォーマンスを向上させるために`SPLIT_FILE`パラメーターを指定すると、行末文字`LINES_TERMINATED_BY`を明示的に指定する必要があります。指定できる値は`\r` 、 `\n` 、または`\r\n`です。行末文字を指定しないと、CSV ファイル データの解析時に例外が発生する可能性があります。 [#37338](https://github.com/pingcap/tidb/issues/37338) @[lance6716](https://github.com/lance6716) -- BR v8.2.0 より前は、TiCDC レプリケーション タスクを持つクラスタで[BRデータ復元](/br/backup-and-restore-overview.md)実行することはサポートされていませんでした。v8.2.0 以降、 BR はTiCDC のデータ復元に関する制限を緩和しました。復元対象データの BackupTS (バックアップ時刻) が changefeed [`CheckpointTS`](/ticdc/ticdc-classic-architecture.md#checkpointts) (現在のレプリケーションの進行状況を示すタイムスタンプ) より前であれば、 BR は正常にデータ復元を進めることができます。 `BackupTS`は通常かなり前であることを考慮すると、ほとんどのシナリオで、 BR はTiCDC レプリケーション タスクを持つクラスタのデータ復元をサポートしていると考えられます。 [#53131](https://github.com/pingcap/tidb/issues/53131) @[YuJuncen](https://github.com/YuJuncen) +- BR v8.2.0 より前は、TiCDC レプリケーション タスクを持つクラスターで[BRデータ復元](/br/backup-and-restore-overview.md)実行することはサポートされていませんでした。v8.2.0 以降、 BR はTiCDC のデータ復元に関する制限を緩和しました。復元対象データの BackupTS (バックアップ時刻) が changefeed [`CheckpointTS`](/ticdc/ticdc-classic-architecture.md#checkpointts) (現在のレプリケーションの進行状況を示すタイムスタンプ) より前であれば、 BR は正常にデータ復元を進めることができます。 `BackupTS`は通常かなり前であることを考慮すると、ほとんどのシナリオで、 BR はTiCDC レプリケーション タスクを持つクラスターのデータ復元をサポートしていると考えられます。 [#53131](https://github.com/pingcap/tidb/issues/53131) @[YuJuncen](https://github.com/YuJuncen) ### MySQLとの互換性 {#mysql-compatibility} @@ -147,23 +147,23 @@ TiDB バージョン: 8.2.0 | 変数名 | 種類を変更する | 説明 | | ------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [`tidb_analyze_distsql_scan_concurrency`](/system-variables.md#tidb_analyze_distsql_scan_concurrency-new-in-v760) | 修正済み | 最小値を`1`から`0`に変更します。これを`0`に設定すると、TiDB はクラスタサイズに基づいて`scan`操作を実行する際に`ANALYZE`操作の同時実行性を適応的に調整します。 | +| [`tidb_analyze_distsql_scan_concurrency`](/system-variables.md#tidb_analyze_distsql_scan_concurrency-new-in-v760) | 修正済み | 最小値を`1`から`0`に変更します。これを`0`に設定すると、TiDB はクラスターサイズに基づいて`scan`操作を実行する際に`ANALYZE`操作の同時実行性を適応的に調整します。 | | [`tidb_analyze_skip_column_types`](/system-variables.md#tidb_analyze_skip_column_types-new-in-v720) | 修正済み | バージョン8.2.0以降、TiDBは潜在的なメモリ不足リスクを回避するため、デフォルトでは`MEDIUMTEXT`および`LONGTEXT`型の列を収集しません。 | -| [`tidb_auto_analyze_partition_batch_size`](/system-variables.md#tidb_auto_analyze_partition_batch_size-new-in-v640) | 修正済み | TiDB クラスタのパフォーマンスに対する自動統計収集の影響を軽減するため、デフォルト値を`128`から`8192`に変更します。値の範囲を`[1, 1024]`から`[1, 8192]`に変更します。 | +| [`tidb_auto_analyze_partition_batch_size`](/system-variables.md#tidb_auto_analyze_partition_batch_size-new-in-v640) | 修正済み | TiDB クラスターのパフォーマンスに対する自動統計収集の影響を軽減するため、デフォルト値を`128`から`8192`に変更します。値の範囲を`[1, 1024]`から`[1, 8192]`に変更します。 | | [`tidb_enable_historical_stats`](/system-variables.md#tidb_enable_historical_stats) | 修正済み | デフォルト値を`ON`から`OFF`に変更します。これにより、履歴統計が無効になり、潜在的な安定性の問題を回避できます。 | | [`tidb_executor_concurrency`](/system-variables.md#tidb_executor_concurrency-new-in-v50) | 修正済み | `sort`演算子の同時実行設定のサポートを追加します。 | -| [`tidb_sysproc_scan_concurrency`](/system-variables.md#tidb_sysproc_scan_concurrency-new-in-v650) | 修正済み | 最小値を`1`から`0`に変更します。これを`0`に設定すると、TiDB はクラスタサイズに基づいて、内部 SQL ステートメントの実行時に実行される`scan`操作の同時実行性を適応的に調整します。 | +| [`tidb_sysproc_scan_concurrency`](/system-variables.md#tidb_sysproc_scan_concurrency-new-in-v650) | 修正済み | 最小値を`1`から`0`に変更します。これを`0`に設定すると、TiDB はクラスターサイズに基づいて、内部 SQL ステートメントの実行時に実行される`scan`操作の同時実行性を適応的に調整します。 | | [`tidb_resource_control_strict_mode`](/system-variables.md#tidb_resource_control_strict_mode-new-in-v820) | 新しく追加された | [`SET RESOURCE GROUP`](/sql-statements/sql-statement-set-resource-group.md)ステートメントおよび[`RESOURCE_GROUP()`](/optimizer-hints.md#resource_groupresource_group_name)オプティマイザヒントに特権制御を適用するかどうかを制御します。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイル | 設定パラメータ | 種類を変更する | 説明 | | -------------- | ------------------------------------------------------------------------------------------------------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`concurrently-init-stats`](/tidb-configuration-file.md#concurrently-init-stats-new-in-v810-and-v752) | 修正済み | 統計情報の初期化にかかる時間を短縮するため、デフォルト値を`false`から`true`に変更します。この設定項目は、 [`lite-init-stats`](/tidb-configuration-file.md#lite-init-stats-new-in-v710) `false`に設定されている場合にのみ有効になります。 | | TiDB | [`stats-load-concurrency`](/tidb-configuration-file.md#stats-load-concurrency-new-in-v540) | 修正済み | デフォルト値を`5`から`0`に変更し、最小値を`1`から`0`に変更します。値`0`は自動モードを意味し、サーバーの設定に基づいて同時実行数を自動的に調整します。 | | TiDB | [`token-limit`](/tidb-configuration-file.md#token-limit) | 修正済み | TiDB Server のメモリ不足エラー (OOM) が発生するのを避けるため、最大値を`18446744073709551615` (64 ビット プラットフォーム) および`4294967295` `1048576`に変更します。これにより、同時にリクエストを実行できるセッション数は最大`1048576`まで設定できます。 | -| ティクヴ | [`max-apply-unpersisted-log-limit`](/tikv-configuration-file.md#max-apply-unpersisted-log-limit-new-in-v810) | 修正済み | TiKVノードのI/Oジッターによって発生するロングテールレイテンシーを削減するため、デフォルト値を`0`から`1024`に変更します。これは、コミット済みだが永続化されていないRaftログの最大適用数が、デフォルトでは`1024`であることを意味します。 | -| ティクヴ | [`server.grpc-compression-type`](/tikv-configuration-file.md#grpc-compression-type) | 修正済み | この設定項目では、TiKVからTiDBに送信される応答メッセージの圧縮アルゴリズムも制御できるようになりました。圧縮を有効にすると、CPUリソースの消費量が増加する可能性があります。 | +| TiKV | [`max-apply-unpersisted-log-limit`](/tikv-configuration-file.md#max-apply-unpersisted-log-limit-new-in-v810) | 修正済み | TiKVノードのI/Oジッターによって発生するロングテールレイテンシーを削減するため、デフォルト値を`0`から`1024`に変更します。これは、コミット済みだが永続化されていないRaftログの最大適用数が、デフォルトでは`1024`であることを意味します。 | +| TiKV | [`server.grpc-compression-type`](/tikv-configuration-file.md#grpc-compression-type) | 修正済み | この設定項目では、TiKVからTiDBに送信される応答メッセージの圧縮アルゴリズムも制御できるようになりました。圧縮を有効にすると、CPUリソースの消費量が増加する可能性があります。 | | TiFlash | [`security.redact_info_log`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) | 修正済み | 新しい値オプション`marker`が導入されました。値を`marker`に設定すると、ログ内のすべてのユーザーデータが`‹ ›`で囲まれます。 | ### システムテーブル {#system-tables} @@ -209,7 +209,7 @@ TiDB バージョン: 8.2.0 - 大量のデータ（>1024行）を含むテーブルを検索する際の`IndexLookUp`演算子のパフォーマンスオーバーヘッドを最適化する [#53871](https://github.com/pingcap/tidb/issues/53871) @[crazycs520](https://github.com/crazycs520) - MPPロードバランシング中にリージョンを持たないストアを削除する [#52313](https://github.com/pingcap/tidb/issues/52313) @[xzhangxian1008](https://github.com/xzhangxian1008) -- ティクヴ +- TiKV - 単一の圧縮ジョブに関係する SST ファイルの数を表示する**圧縮ジョブサイズ (ファイル)**メトリックを追加します [#16837](https://github.com/tikv/tikv/issues/16837) @[zhangjinpeng87](https://github.com/zhangjinpeng87) - [早期応募](/tikv-configuration-file.md#max-apply-unpersisted-log-limit-new-in-v810)をデフォルトで有効にします。この機能を有効にすると、 Raftリーダーは、クォーラム ピアがログを永続化した後、リーダー自身がログを永続化するのを待たずにログを適用できるため、少数の TiKV ノードでのジッターが書き込みリクエストのレイテンシーに与える影響が軽減されます。 [#16717](https://github.com/tikv/tikv/issues/16717) @[glorv](https://github.com/glorv) @@ -244,7 +244,7 @@ TiDB バージョン: 8.2.0 - TiCDC - - ダウンストリームがメッセージキュー（MQ）またはクラウドstorageの場合に、生イベントを直接出力する機能をサポートする [#11211](https://github.com/pingcap/tiflow/issues/11211) @[CharlesCheung96](https://github.com/CharlesCheung96) + - ダウンストリームがメッセージキュー（MQ）またはクラウドストレージの場合に、生イベントを直接出力する機能をサポートする [#11211](https://github.com/pingcap/tiflow/issues/11211) @[CharlesCheung96](https://github.com/CharlesCheung96) ## バグ修正 {#bug-fixes} @@ -262,8 +262,8 @@ TiDB バージョン: 8.2.0 - 述語における`Longlong`型のオーバーフロー問題を修正 [#45783](https://github.com/pingcap/tidb/issues/45783) @[hawkingrei](https://github.com/hawkingrei) - Window関数内に関連サブクエリがある場合にpanicする可能性がある問題を修正しました [#42734](https://github.com/pingcap/tidb/issues/42734) @[Rustin170506](https://github.com/Rustin170506) - TopN演算子が正しくプッシュダウンされない可能性がある問題を修正しました [#37986](https://github.com/pingcap/tidb/issues/37986) @[qw4990](https://github.com/qw4990) - - クラスタ化インデックスを述語として使用する場合に`SELECT INTO OUTFILE`が機能しない問題を修正 [#42093](https://github.com/pingcap/tidb/issues/42093) @[qw4990](https://github.com/qw4990) - - 情報スキーマキャッシュのミスによって古い読み取りのクエリレイテンシーが増加する問題を修正します [#53428](https://github.com/pingcap/tidb/issues/53428) @[crazycs520](https://github.com/crazycs520) + - クラスター化インデックスを述語として使用する場合に`SELECT INTO OUTFILE`が機能しない問題を修正 [#42093](https://github.com/pingcap/tidb/issues/42093) @[qw4990](https://github.com/qw4990) + - 情報スキーマキャッシュのミスによってステイル読み取りのクエリレイテンシーが増加する問題を修正します [#53428](https://github.com/pingcap/tidb/issues/53428) @[crazycs520](https://github.com/crazycs520) - `YEAR`型の列を範囲外の符号なし整数と比較すると誤った結果が生じる問題を修正しました [#50235](https://github.com/pingcap/tidb/issues/50235) @[qw4990](https://github.com/qw4990) - TiDBを再起動した後に、主キー列統計のヒストグラムとTopNが読み込まれない問題を修正しました [#37548](https://github.com/pingcap/tidb/issues/37548) @[hawkingrei](https://github.com/hawkingrei) - `final` AggMode と`non-final` AggMode が大規模並列処理 (MPP) で共存できない問題を修正します [#51362](https://github.com/pingcap/tidb/issues/51362) @[AilinKid](https://github.com/AilinKid) @@ -300,7 +300,7 @@ TiDB バージョン: 8.2.0 - メタデータロックの不適切な使用により、特定の状況下でプランキャッシュを使用する際に異常なデータが書き込まれる可能性がある問題を修正しました [#53634](https://github.com/pingcap/tidb/issues/53634) @[zimulala](https://github.com/zimulala) - トランザクション内のステートメントがメモリ不足で強制終了された後、TiDB が同じトランザクション内の次のステートメントの実行を継続すると、 `Trying to start aggressive locking while it's already started`エラーが発生し、panicが発生する可能性がある問題を修正しました。 [#53540](https://github.com/pingcap/tidb/issues/53540) @[MyonKeminta](https://github.com/MyonKeminta) -- ティクヴ +- TiKV - `JSON_ARRAY_APPEND()`関数を TiKV にプッシュダウンすると TiKV がpanicを起こす問題を修正しました [#16930](https://github.com/tikv/tikv/issues/16930) @[dbsid](https://github.com/dbsid) - リーダーが失敗したスナップショットファイルを時間内にクリーンアップしない問題を修正 [#16976](https://github.com/tikv/tikv/issues/16976) @[hbisheng](https://github.com/hbisheng) @@ -323,7 +323,7 @@ TiDB バージョン: 8.2.0 - TiFlash - 空のパーティションを含むパーティションテーブルに対してクエリを実行する際に発生するクエリタイムアウトの問題を修正 [#9024](https://github.com/pingcap/tiflash/issues/9024) @[JinheLin](https://github.com/JinheLin) - - 分散storageおよびコンピューティングアーキテクチャにおいて、DDL操作で非null列を追加した後、クエリでnull値が誤って返される可能性がある問題を修正します [#9084](https://github.com/pingcap/tiflash/issues/9084) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - 分散ストレージおよびコンピューティングアーキテクチャにおいて、DDL操作で非null列を追加した後、クエリでnull値が誤って返される可能性がある問題を修正します [#9084](https://github.com/pingcap/tiflash/issues/9084) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - `SUBSTRING_INDEX()`関数が一部の特殊なケースでTiFlashをクラッシュさせる可能性がある問題を修正しました [#9116](https://github.com/pingcap/tiflash/issues/9116) @[wshwsh12](https://github.com/wshwsh12) - BRまたはTiDB Lightning経由でデータをインポートした後、FastScanモードで多数の重複行が読み込まれる可能性がある問題を修正しました [#9118](https://github.com/pingcap/tiflash/issues/9118) @[JinheLin](https://github.com/JinheLin) diff --git a/releases/release-8.3.0.md b/releases/release-8.3.0.md index 6d5edd7b1b1a2..2f02729da0c89 100644 --- a/releases/release-8.3.0.md +++ b/releases/release-8.3.0.md @@ -13,15 +13,15 @@ TiDBバージョン：8.3.0 バージョン8.3.0では、以下の主要な機能と改善点が導入されています。 -
カテゴリ機能／改善点説明
拡張性とパフォーマンスパーティションテーブルのグローバルインデックス（実験的）グローバルインデックスを使用すると、パーティション化されていない列の取得効率を効果的に向上させることができ、一意キーにパーティションキーを含める必要があるという制約を取り除くことができます。この機能により、TiDBパーティションテーブルの使用シナリオが拡張され、データ移行時に必要となる可能性のあるアプリケーションの変更作業の一部を回避できます。
Projection演算子をstorageエンジンにデフォルトでプッシュダウンするProjection演算子をstorageエンジンにプッシュダウンすることで、storageノード全体に負荷を分散させ、ノード間のデータ転送量を削減できます。この最適化により、特定のSQLクエリの実行時間が短縮され、データベース全体のパフォーマンスが向上します。
統計情報を収集する際に不要な列を無視するオプティマイザが必要な情報を確実に取得できるという前提のもと、TiDBは統計情報の収集を高速化し、統計情報の適時性を向上させることで、最適な実行プランの選択を保証し、クラスタのパフォーマンスを向上させます。同時に、TiDBはシステムオーバーヘッドを削減し、リソース利用率も向上させます。
信頼性と可用性TiProxyに組み込まれた仮想IP管理機能TiProxyは、仮想IP管理機能を内蔵しています。設定することで、外部プラットフォームやツールに依存することなく、仮想IPの自動切り替えをサポートします。この機能により、TiProxyの導入が簡素化され、データベースアクセスレイヤーの複雑さが軽減されます。
+
カテゴリ機能／改善点説明
拡張性とパフォーマンスパーティションテーブルのグローバルインデックス（実験的）グローバルインデックスを使用すると、パーティション化されていない列の取得効率を効果的に向上させることができ、一意キーにパーティションキーを含める必要があるという制約を取り除くことができます。この機能により、TiDBパーティションテーブルの使用シナリオが拡張され、データ移行時に必要となる可能性のあるアプリケーションの変更作業の一部を回避できます。
Projection演算子をストレージエンジンにデフォルトでプッシュダウンするProjection演算子をストレージエンジンにプッシュダウンすることで、ストレージノード全体に負荷を分散させ、ノード間のデータ転送量を削減できます。この最適化により、特定のSQLクエリの実行時間が短縮され、データベース全体のパフォーマンスが向上します。
統計情報を収集する際に不要な列を無視するオプティマイザが必要な情報を確実に取得できるという前提のもと、TiDBは統計情報の収集を高速化し、統計情報の適時性を向上させることで、最適な実行プランの選択を保証し、クラスターのパフォーマンスを向上させます。同時に、TiDBはシステムオーバーヘッドを削減し、リソース利用率も向上させます。
信頼性と可用性TiProxyに組み込まれた仮想IP管理機能TiProxyは、仮想IP管理機能を内蔵しています。設定することで、外部プラットフォームやツールに依存することなく、仮想IPの自動切り替えをサポートします。この機能により、TiProxyの導入が簡素化され、データベースアクセスレイヤーの複雑さが軽減されます。
## 機能の詳細 {#feature-details} ### パフォーマンス {#performance} -- オプティマイザは`Projection`演算子をデフォルトでstorageエンジンにプッシュダウンすることを可能にします [#51876](https://github.com/pingcap/tidb/issues/51876) @[yibin87](https://github.com/yibin87) +- オプティマイザは`Projection`演算子をデフォルトでストレージエンジンにプッシュダウンすることを可能にします [#51876](https://github.com/pingcap/tidb/issues/51876) @[yibin87](https://github.com/yibin87) - `Projection`演算子をstorageエンジンにプッシュダウンすると、計算エンジンとstorageエンジン間のデータ転送が削減され、SQL 実行パフォーマンスが向上します。これは[JSONクエリ関数](/functions-and-operators/json-functions/json-functions-search.md)含むクエリに特に効果的です。 または[JSON値属性関数](/functions-and-operators/json-functions/json-functions-return.md)。v8.3.0 以降、TiDB は、この機能を制御するシステム変数[`tidb_opt_projection_push_down`](/system-variables.md#tidb_opt_projection_push_down-new-in-v610)のデフォルト値を`Projection`から`OFF` `ON`ダウン機能をデフォルトで有効にします。この機能が有効になると、オプティマイザは、対象となる JSON クエリ関数と JSON 値属性関数を自動的にstorageエンジンにプッシュダウンします。 + `Projection`演算子をストレージエンジンにプッシュダウンすると、計算エンジンとストレージエンジン間のデータ転送が削減され、SQL 実行パフォーマンスが向上します。これは[JSONクエリ関数](/functions-and-operators/json-functions/json-functions-search.md)含むクエリに特に効果的です。 または[JSON値属性関数](/functions-and-operators/json-functions/json-functions-return.md)。v8.3.0 以降、TiDB は、この機能を制御するシステム変数[`tidb_opt_projection_push_down`](/system-variables.md#tidb_opt_projection_push_down-new-in-v610)のデフォルト値を`Projection`から`OFF` `ON`ダウン機能をデフォルトで有効にします。この機能が有効になると、オプティマイザは、対象となる JSON クエリ関数と JSON 値属性関数を自動的にストレージエンジンにプッシュダウンします。 詳細については、 [ドキュメント](/system-variables.md#tidb_opt_projection_push_down-new-in-v610)を参照してください。 @@ -49,7 +49,7 @@ TiDBバージョン：8.3.0 - 一部のシステムテーブルのクエリパフォーマンスを改善 [#50305](https://github.com/pingcap/tidb/issues/50305) @[tangenta](https://github.com/tangenta) - 以前のバージョンでは、クラスタサイズが大きくなり、テーブル数が多くなると、システムテーブルへのクエリのパフォーマンスが低下していました。 + 以前のバージョンでは、クラスターサイズが大きくなり、テーブル数が多くなると、システムテーブルへのクエリのパフォーマンスが低下していました。 バージョン8.0.0では、以下の4つのシステムテーブルについてクエリパフォーマンスが最適化されています。 @@ -99,7 +99,7 @@ TiDBバージョン：8.3.0 アプリケーションコードが[カーソルフェッチ](/develop/dev-guide-connection-parameters.md#use-streamingresult-to-get-the-execution-result)を使用して結果セットを取得する場合、TiDBは通常、まず結果セット全体をメモリに格納し、その後データをバッチ処理でクライアントに返します。結果セットが大きすぎる場合は、TiDBは一時的に結果をハードディスクに書き込むことがあります。 - バージョン8.3.0以降では、システム変数[`tidb_enable_lazy_cursor_fetch`](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830) `ON`に設定すると、TiDBはすべてのデータをTiDBノードに読み込むのではなく、クライアントが読み込むにつれて徐々にデータをTiDBノードに読み込むようになります。TiDBが大規模な結果セットを処理する場合、この機能によりTiDBノードのメモリ使用量が削減され、クラスタの安定性が向上します。 + バージョン8.3.0以降では、システム変数[`tidb_enable_lazy_cursor_fetch`](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830) `ON`に設定すると、TiDBはすべてのデータをTiDBノードに読み込むのではなく、クライアントが読み込むにつれて徐々にデータをTiDBノードに読み込むようになります。TiDBが大規模な結果セットを処理する場合、この機能によりTiDBノードのメモリ使用量が削減され、クラスターの安定性が向上します。 詳細については、 [ドキュメント](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830)を参照してください。 @@ -162,7 +162,7 @@ TiDBバージョン：8.3.0 - TiCDCは双方向レプリケーション（BDR）モードでのDDLステートメントのレプリケーションをサポートします（GA） [#10301](https://github.com/pingcap/tiflow/issues/10301) [#48519](https://github.com/pingcap/tidb/issues/48519) [okJiang](https://github.com/okJiang) [asddongmen](https://github.com/asddongmen) - TiCDC v7.6.0 では、双方向レプリケーションが構成された DDL ステートメントのレプリケーションが導入されました。以前は、TiCDC は DDL ステートメントの双方向レプリケーションをサポートしていなかったため、TiCDC の双方向レプリケーションを使用するユーザーは、両方の TiDB クラスタで DDL ステートメントを個別に実行する必要がありました。この機能により、クラスタに`PRIMARY` BDR ロールを割り当てると、TiCDC はそのクラスタから`SECONDARY`クラスタに DDL ステートメントをレプリケートできます。 + TiCDC v7.6.0 では、双方向レプリケーションが構成された DDL ステートメントのレプリケーションが導入されました。以前は、TiCDC は DDL ステートメントの双方向レプリケーションをサポートしていなかったため、TiCDC の双方向レプリケーションを使用するユーザーは、両方の TiDB クラスターで DDL ステートメントを個別に実行する必要がありました。この機能により、クラスターに`PRIMARY` BDR ロールを割り当てると、TiCDC はそのクラスターから`SECONDARY`クラスターに DDL ステートメントをレプリケートできます。 バージョン8.3.0では、この機能が一般提供（GA）されます。 @@ -185,23 +185,23 @@ TiDBバージョン：8.3.0 | [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) | 修正済み | SESSIONスコープを追加します。 | | [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) | 修正済み | SESSIONスコープを追加します。 | | [`tidb_enable_column_tracking`](/system-variables.md#tidb_enable_column_tracking-new-in-v540) | 修正済み | さらなるテストの結果、デフォルト値が`OFF`から`ON`に変更されます。これは、TiDB がデフォルトで`PREDICATE COLUMNS`を収集することを意味します。 | -| [`tidb_gc_concurrency`](/system-variables.md#tidb_gc_concurrency-new-in-v50) | 修正済み | v8.3.0 以降、この変数は[ごみ収集（GC）](/garbage-collection-overview.md)プロセスの[ロックを解除する](/garbage-collection-overview.md#resolve-locks)ステップと[範囲を削除](/garbage-collection-overview.md#delete-ranges)ステップ中の同時スレッドの数を制御します。 v8.3.0 より前では、この変数は[ロックを解除する](/garbage-collection-overview.md#resolve-locks)ステップ中のスレッド数のみを制御します。 | +| [`tidb_gc_concurrency`](/system-variables.md#tidb_gc_concurrency-new-in-v50) | 修正済み | v8.3.0 以降、この変数は[ガベージコレクション（GC）](/garbage-collection-overview.md)プロセスの[ロックを解除する](/garbage-collection-overview.md#resolve-locks)ステップと[範囲を削除](/garbage-collection-overview.md#delete-ranges)ステップ中の同時スレッドの数を制御します。 v8.3.0 より前では、この変数は[ロックを解除する](/garbage-collection-overview.md#resolve-locks)ステップ中のスレッド数のみを制御します。 | | [`tidb_low_resolution_tso`](/system-variables.md#tidb_low_resolution_tso) | 修正済み | グローバルスコープを追加します。 | -| [`tidb_opt_projection_push_down`](/system-variables.md#tidb_opt_projection_push_down-new-in-v610) | 修正済み | GLOBAL スコープを追加し、変数の値をクラスタに永続化します。さらにテストを行った結果、デフォルト値を`OFF`から`ON`に変更します。これは、オプティマイザが`Projection` TiKV コプロセッサにプッシュできることを意味します。 | +| [`tidb_opt_projection_push_down`](/system-variables.md#tidb_opt_projection_push_down-new-in-v610) | 修正済み | GLOBAL スコープを追加し、変数の値をクラスターに永続化します。さらにテストを行った結果、デフォルト値を`OFF`から`ON`に変更します。これは、オプティマイザが`Projection` TiKV コプロセッサにプッシュできることを意味します。 | | [`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800) | 修正済み | 値の範囲は`0`または`[536870912, 9223372036854775807]`に変更されました。キャッシュサイズが小さすぎてパフォーマンスが低下するのを避けるため、最小値は`536870912`バイト (つまり 512 MiB) です。 | | [`tidb_analyze_column_options`](/system-variables.md#tidb_analyze_column_options-new-in-v830) | 新しく追加された | `ANALYZE TABLE`ステートメントの動作を制御します。デフォルト値の`PREDICATE`に設定すると、 [述語列](/statistics.md#collect-statistics-on-some-columns)の統計情報のみが収集されます。 `ALL`に設定すると、すべての列の統計情報が収集されます。 | | [`tidb_enable_lazy_cursor_fetch`](/system-variables.md#tidb_enable_lazy_cursor_fetch-new-in-v830) | 新しく追加された | [カーソルフェッチ](/develop/dev-guide-connection-parameters.md#use-streamingresult-to-get-the-execution-result)機能の動作を制御します。 | | [`tidb_enable_shared_lock_promotion`](/system-variables.md#tidb_enable_shared_lock_promotion-new-in-v830) | 新しく追加された | 共有ロックを排他ロックにアップグレードする機能を有効にするかどうかを制御します。この変数のデフォルト値は`OFF`であり、これは共有ロックを排他ロックにアップグレードする機能が無効になっていることを意味します。 | | [`tiflash_hashagg_preaggregation_mode`](/system-variables.md#tiflash_hashagg_preaggregation_mode-new-in-v830) | 新しく追加された | TiFlashにプッシュダウンされる2段階または3段階のHashAgg操作の最初の段階で使用される事前集計戦略を制御します。 | -### コンフィグレーションファイルパラメータ {#configuration-file-parameters} +### 設定ファイルパラメータ {#configuration-file-parameters} -| コンフィグレーションファイル | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイル | 設定パラメータ | 種類を変更する | 説明 | | -------------- | ------------------------------------------------------------------------------------------------------ | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`tikv-client.batch-policy`](/tidb-configuration-file.md#batch-policy-new-in-v830) | 新しく追加された | TiDBからTiKVへのリクエストのバッチ処理戦略を制御します。 | | PD | [`security.redact-info-log`](/pd-configuration-file.md#redact-info-log-new-in-v50) | 修正済み | PD構成項目`security.redact-info-log`の値を`"marker"`に設定することで、ログ内の機密情報を直接シールドする代わりに`‹ ›`でマークできます。 `"marker"`オプションを使用すると、マスキングルールをカスタマイズできます。 | -| ティクヴ | [`security.redact-info-log`](/tikv-configuration-file.md#redact-info-log-new-in-v408) | 修正済み | TiKV 設定項目`security.redact-info-log`の値を`"marker"`に設定することで、ログ内の機密情報を直接シールドする代わりに`‹ ›`でマークできます。 `"marker"`オプションを使用すると、マスキングルールをカスタマイズできます。 | -| TiFlash | [`security.redact-info-log`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 修正済み | TiFlash Learnerの設定項目`security.redact-info-log`の値を`"marker"`に設定することで、ログ内の機密情報を直接シールドする代わりに`‹ ›`でマークすることができます。 `"marker"`オプションを使用すると、マスキングルールをカスタマイズできます。 | +| TiKV | [`security.redact-info-log`](/tikv-configuration-file.md#redact-info-log-new-in-v408) | 修正済み | TiKV 設定項目`security.redact-info-log`の値を`"marker"`に設定することで、ログ内の機密情報を直接シールドする代わりに`‹ ›`でマークできます。 `"marker"`オプションを使用すると、マスキングルールをカスタマイズできます。 | +| TiFlash | [`security.redact-info-log`](/tiflash/tiflash-configuration.md#configure-the-tiflash-learnertoml-file) | 修正済み | TiFlash ラーナーの設定項目`security.redact-info-log`の値を`"marker"`に設定することで、ログ内の機密情報を直接シールドする代わりに`‹ ›`でマークすることができます。 `"marker"`オプションを使用すると、マスキングルールをカスタマイズできます。 | | BR | [`--allow-pitr-from-incremental`](/br/br-incremental-guide.md#limitations) | 新しく追加された | 増分バックアップが後続のログバックアップと互換性があるかどうかを制御します。デフォルト値は`true`で、これは増分バックアップが後続のログバックアップと互換性があることを意味します。デフォルト値`true`ままにすると、増分リストアが開始される前に、再生が必要な DDL が厳密にチェックされます。 | ### システムテーブル {#system-tables} @@ -251,7 +251,7 @@ TiDBバージョン：8.3.0 - PD - `batch`を介して`evict-leader-scheduler`の`pd-ctl`構成を変更してリーダー退去プロセスを加速するサポート [#8265](https://github.com/tikv/pd/issues/8265) @[rleungx](https://github.com/rleungx) - - Grafana の**クラスタ > Label 配信**パネルに`store_id`モニタリングメトリックを追加して、異なるラベルに対応するストア ID を表示します [#8337](https://github.com/tikv/pd/issues/8337) @[HuSharp](https://github.com/HuSharp) + - Grafana の**クラスター > Label 配信**パネルに`store_id`モニタリングメトリックを追加して、異なるラベルに対応するストア ID を表示します [#8337](https://github.com/tikv/pd/issues/8337) @[HuSharp](https://github.com/HuSharp) - 指定されたリソースグループが存在しない場合、デフォルトのリソースグループへのフォールバックをサポートする [#8388](https://github.com/tikv/pd/issues/8388) @[JmPotato](https://github.com/JmPotato) - `approximate_kv_size`の`region`コマンドが出力するリージョン情報に`pd-ctl`フィールドを追加します。 [#8412](https://github.com/tikv/pd/issues/8412) @[zeminzhou](https://github.com/zeminzhou) - PD APIを呼び出してTTL設定を削除したときに返されるメッセージを最適化します [#8450](https://github.com/tikv/pd/issues/8450) @[lhy1024](https://github.com/lhy1024) @@ -260,7 +260,7 @@ TiDBバージョン：8.3.0 - PDマイクロサービスに`--name`起動パラメータを追加して、デプロイ中にサービス名をより正確に表示します [#7995](https://github.com/tikv/pd/issues/7995) @[HuSharp](https://github.com/HuSharp) - 領域数に基づいて`PatrolRegionScanLimit`を動的に調整してリージョンスキャン時間を短縮する機能をサポート [#7963](https://github.com/tikv/pd/issues/7963) @[lhy1024](https://github.com/lhy1024) -- ティクヴ +- TiKV - `async-io`が有効になっている場合、 Raftログの書き込みバッチ処理ポリシーを最適化して、ディスク I/O 帯域幅リソースの消費を削減します [#16907](https://github.com/tikv/tikv/issues/16907) @[LykxSassinator](https://github.com/LykxSassinator) - リージョン部分購読をより適切にサポートするために、TiCDCデリゲートとダウンストリームモジュールを再設計します [#16362](https://github.com/tikv/tikv/issues/16362) @[hicqu](https://github.com/hicqu) @@ -356,10 +356,10 @@ TiDBバージョン：8.3.0 - TiFlashでSSL証明書の設定を空文字列に設定するとTLSが誤って有効になり、 TiFlashが起動に失敗する問題を修正しました [#9235](https://github.com/pingcap/tiflash/issues/9235) @[JaySon-Huang](https://github.com/JaySon-Huang) - データベース作成直後にデータベースが削除されるとTiFlash がpanicことがある問題を修正 [#9266](https://github.com/pingcap/tiflash/issues/9266) @[JaySon-Huang](https://github.com/JaySon-Huang) - TiFlashと任意の PD 間のネットワーク パーティション (ネットワークの切断) により、読み取りリクエストのタイムアウト エラーが発生する可能性がある問題を修正 [#9243](https://github.com/pingcap/tiflash/issues/9243) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - - 分散storageおよびコンピューティングアーキテクチャでTiFlash書き込みノードの再起動に失敗することがある問題を修正 [#9282](https://github.com/pingcap/tiflash/issues/9282) @[JaySon-Huang](https://github.com/JaySon-Huang) - - 分散storageおよびコンピューティングアーキテクチャにおいて、 TiFlash書き込みノードの読み取りスナップショットがタイムリーに解放されない問題を修正します [#9298](https://github.com/pingcap/tiflash/issues/9298) @[JinheLin](https://github.com/JinheLin) + - 分散ストレージおよびコンピューティングアーキテクチャでTiFlash書き込みノードの再起動に失敗することがある問題を修正 [#9282](https://github.com/pingcap/tiflash/issues/9282) @[JaySon-Huang](https://github.com/JaySon-Huang) + - 分散ストレージおよびコンピューティングアーキテクチャにおいて、 TiFlash書き込みノードの読み取りスナップショットがタイムリーに解放されない問題を修正します [#9298](https://github.com/pingcap/tiflash/issues/9298) @[JinheLin](https://github.com/JinheLin) -- ティクヴ +- TiKV - 古いリージョンをクリーンアップすると、誤って有効なデータが削除される可能性がある問題を修正 [#17258](https://github.com/tikv/tikv/issues/17258) @[hbisheng](https://github.com/hbisheng) - Grafana の TiKV ダッシュボードで`Ingestion picked level`と`Compaction Job Size(files)`が正しく表示されない問題を修正します [#15990](https://github.com/tikv/tikv/issues/15990) @[Connor1996](https://github.com/Connor1996) @@ -374,7 +374,7 @@ TiDBバージョン：8.3.0 - `ADD INDEX`や`MODIFY COLUMN`など、バックフィルが必要な DDL が増分リストア中に正しく復元されない可能性がある問題を修正します [#54426](https://github.com/pingcap/tidb/issues/54426) @[3pointer](https://github.com/3pointer)シュート - バックアップと復元中に進行状況が停止する問題を修正 [#54140](https://github.com/pingcap/tidb/issues/54140) @[Leavrth](https://github.com/Leavrth) - - バックアップとリストアのチェックポイントパスが一部の外部storageと互換性がない問題を修正 [#55265](https://github.com/pingcap/tidb/issues/55265) @[Leavrth](https://github.com/Leavrth) + - バックアップとリストアのチェックポイントパスが一部の外部ストレージと互換性がない問題を修正 [#55265](https://github.com/pingcap/tidb/issues/55265) @[Leavrth](https://github.com/Leavrth) - TiCDC diff --git a/releases/release-8.4.0.md b/releases/release-8.4.0.md index 638260b6b2fa3..afeff2242f8ea 100644 --- a/releases/release-8.4.0.md +++ b/releases/release-8.4.0.md @@ -13,7 +13,7 @@ TiDB バージョン: 8.4.0 バージョン8.4.0では、以下の主要な機能と改善点が導入されています。 -
カテゴリ機能／改善点説明
拡張性とパフォーマンスインスタンスレベルの実行プランキャッシュ（実験的）インスタンスレベルのプランキャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションでプランキャッシュを共有できます。セッションレベルのプランキャッシュと比較して、この機能はメモリに多くの実行プランをキャッシュすることで SQL コンパイル時間を短縮し、SQL 全体の実行時間を短縮します。これにより、OLTP のパフォーマンスとスループットが向上するとともに、メモリ使用量をより適切に制御し、データベースの安定性を高めることができます。
パーティションテーブルのグローバルインデックス（GA）グローバルインデックスを使用すると、パーティション化されていない列の取得効率を効果的に向上させることができ、一意キーにパーティションキーを含める必要があるという制約を取り除くことができます。この機能により、TiDBパーティションテーブルの使用シナリオが拡張され、データ移行に必要なアプリケーションの変更作業の一部が不要になります。
TSOリクエストの並列モード高並行処理環境では、この機能を使用することでTSOの取得待ち時間を短縮し、クラスタのスループットを向上させることができます。
キャッシュされたテーブルのクエリパフォーマンスを向上させるキャッシュされたテーブルに対するインデックススキャンのクエリパフォーマンスが向上し、場合によっては最大5.4倍の改善が見られます。小規模なテーブルに対する高速クエリの場合、キャッシュされたテーブルを使用することで、全体的なパフォーマンスを大幅に向上させることができます。
信頼性と可用性 暴走クエリに対するトリガーの追加と、リソースグループの切り替えのサポート暴走クエリは、予期しないSQLパフォーマンスの問題がシステムに与える影響を軽減する効果的な手段です。TiDB v8.4.0では、識別条件としてコプロセッサーによって処理されたキーの数（ PROCESSED_KEYS ）とリクエストユニット（ RU ）が導入され、識別されたクエリを指定されたリソースグループに配置することで、暴走クエリのより正確な識別と制御が可能になりました。
リソース制御のバックグラウンドタスクにおけるリソース使用量の上限設定をサポートするリソース制御のバックグラウンドタスクに最大パーセンテージ制限を設定することで、さまざまなアプリケーションシステムのニーズに基づいてリソース消費を制御できます。これにより、バックグラウンドタスクの消費量を低く抑え、オンラインサービスの品質を確保できます。
TiProxyはトラフィックのキャプチャと再生をサポートします（実験的）。 TiProxyを使用して、クラスターのアップグレード、移行、デプロイメントの変更などの主要な操作を行う前に、TiDB本番クラスターから実際のワークロードをキャプチャします。これらのワークロードをターゲットのテストクラスターで再生することで、パフォーマンスを検証し、変更が確実に成功することを確認します。
同時自動統計収集TiDBクラスタ内での同時実行自動分析操作の数を制御するために、システム変数tidb_auto_analyze_concurrencyを導入します。TiDBは、ノードの規模とハードウェア仕様に基づいて、スキャンタスクの同時実行数を自動的に決定します。これにより、システムリソースを最大限に活用して統計情報の収集効率が向上し、手動による調整が削減され、クラスタの安定したパフォーマンスが確保されます。
SQLベクトル検索（実験的）ベクトル検索は、データの意味論に基づいた検索手法であり、より関連性の高い検索結果を提供します。AIや大規模言語モデル（LLM）の中核関数の一つとして、ベクトル検索は、検索拡張生成（RAG）、意味検索、推薦システムなど、さまざまなシナリオで活用できます。
データベースの運用と可観測性TiKVとTiDBのCPU時間をメモリテーブルに表示するCPU時間はシステムテーブルに統合され、セッションやSQLなどの他のメトリックと並べて表示されるようになりました。これにより、CPU使用率の高い操作を複数の視点から把握し、診断効率を向上させることができます。これは、インスタンスにおけるCPUスパイクやクラスタにおける読み書きホットスポットなどのシナリオを診断する際に特に役立ちます。
テーブルまたはデータベースごとに集計されたTiKV CPU時間を表示する機能をサポートします。ホットスポットの問題が個々のSQL文によって引き起こされていない場合、 Top SQLでテーブルまたはデータベースレベルごとに集計されたCPU時間を使用することで、ホットスポットの原因となっているテーブルやアプリケーションを迅速に特定でき、ホットスポットやCPU消費の問題の診断効率を大幅に向上させることができます。
IMDSv2サービスが有効になっているTiKVインスタンスのバックアップをサポートします。 AWS EC2 では、デフォルトのメタデータ サービスとして IMDSv2 が使用されるようになりました。TiDB は、IMDSv2 が有効になっている TiKV インスタンスからのデータバックアップをサポートしており、パブリック クラウド サービスで TiDB クラスターをより効率的に実行するのに役立ちます。
Securityログバックアップデータのクライアント側暗号化（実験的）ログバックアップデータをバックアップstorageにアップロードする前に、バックアップデータを暗号化することで、storage中および転送中のセキュリティを確保できます。
+
カテゴリ機能／改善点説明
拡張性とパフォーマンスインスタンスレベルの実行プランキャッシュ（実験的）インスタンスレベルのプランキャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションでプランキャッシュを共有できます。セッションレベルのプランキャッシュと比較して、この機能はメモリに多くの実行プランをキャッシュすることで SQL コンパイル時間を短縮し、SQL 全体の実行時間を短縮します。これにより、OLTP のパフォーマンスとスループットが向上するとともに、メモリ使用量をより適切に制御し、データベースの安定性を高めることができます。
パーティションテーブルのグローバルインデックス（GA）グローバルインデックスを使用すると、パーティション化されていない列の取得効率を効果的に向上させることができ、一意キーにパーティションキーを含める必要があるという制約を取り除くことができます。この機能により、TiDBパーティションテーブルの使用シナリオが拡張され、データ移行に必要なアプリケーションの変更作業の一部が不要になります。
TSOリクエストの並列モード高並行処理環境では、この機能を使用することでTSOの取得待ち時間を短縮し、クラスターのスループットを向上させることができます。
キャッシュされたテーブルのクエリパフォーマンスを向上させるキャッシュされたテーブルに対するインデックススキャンのクエリパフォーマンスが向上し、場合によっては最大5.4倍の改善が見られます。小規模なテーブルに対する高速クエリの場合、キャッシュされたテーブルを使用することで、全体的なパフォーマンスを大幅に向上させることができます。
信頼性と可用性 暴走クエリに対するトリガーの追加と、リソースグループの切り替えのサポート暴走クエリは、予期しないSQLパフォーマンスの問題がシステムに与える影響を軽減する効果的な手段です。TiDB v8.4.0では、識別条件としてコプロセッサーによって処理されたキーの数（ PROCESSED_KEYS ）とリクエストユニット（ RU ）が導入され、識別されたクエリを指定されたリソースグループに配置することで、暴走クエリのより正確な識別と制御が可能になりました。
リソース制御のバックグラウンドタスクにおけるリソース使用量の上限設定をサポートするリソース制御のバックグラウンドタスクに最大パーセンテージ制限を設定することで、さまざまなアプリケーションシステムのニーズに基づいてリソース消費を制御できます。これにより、バックグラウンドタスクの消費量を低く抑え、オンラインサービスの品質を確保できます。
TiProxyはトラフィックのキャプチャと再生をサポートします（実験的）。 TiProxyを使用して、クラスターのアップグレード、移行、デプロイメントの変更などの主要な操作を行う前に、TiDB本番クラスターから実際のワークロードをキャプチャします。これらのワークロードをターゲットのテストクラスターで再生することで、パフォーマンスを検証し、変更が確実に成功することを確認します。
同時自動統計収集TiDBクラスター内での同時実行自動分析操作の数を制御するために、システム変数tidb_auto_analyze_concurrencyを導入します。TiDBは、ノードの規模とハードウェア仕様に基づいて、スキャンタスクの同時実行数を自動的に決定します。これにより、システムリソースを最大限に活用して統計情報の収集効率が向上し、手動による調整が削減され、クラスターの安定したパフォーマンスが確保されます。
SQLベクトル検索（実験的）ベクトル検索は、データの意味論に基づいた検索手法であり、より関連性の高い検索結果を提供します。AIや大規模言語モデル（LLM）の中核関数の一つとして、ベクトル検索は、検索拡張生成（RAG）、意味検索、推薦システムなど、さまざまなシナリオで活用できます。
データベースの運用と可観測性TiKVとTiDBのCPU時間をメモリテーブルに表示するCPU時間はシステムテーブルに統合され、セッションやSQLなどの他のメトリックと並べて表示されるようになりました。これにより、CPU使用率の高い操作を複数の視点から把握し、診断効率を向上させることができます。これは、インスタンスにおけるCPUスパイクやクラスターにおける読み書きホットスポットなどのシナリオを診断する際に特に役立ちます。
テーブルまたはデータベースごとに集計されたTiKV CPU時間を表示する機能をサポートします。ホットスポットの問題が個々のSQL文によって引き起こされていない場合、 Top SQLでテーブルまたはデータベースレベルごとに集計されたCPU時間を使用することで、ホットスポットの原因となっているテーブルやアプリケーションを迅速に特定でき、ホットスポットやCPU消費の問題の診断効率を大幅に向上させることができます。
IMDSv2サービスが有効になっているTiKVインスタンスのバックアップをサポートします。 AWS EC2 では、デフォルトのメタデータ サービスとして IMDSv2 が使用されるようになりました。TiDB は、IMDSv2 が有効になっている TiKV インスタンスからのデータバックアップをサポートしており、パブリック クラウド サービスで TiDB クラスターをより効率的に実行するのに役立ちます。
Securityログバックアップデータのクライアント側暗号化（実験的）ログバックアップデータをバックアップストレージにアップロードする前に、バックアップデータを暗号化することで、ストレージ中および転送中のセキュリティを確保できます。
## 機能の詳細 {#feature-details} @@ -44,7 +44,7 @@ TiDB バージョン: 8.4.0 - インスタンスレベルの実行プランキャッシュのサポート（実験的） [#54057](https://github.com/pingcap/tidb/issues/54057) @[qw4990](https://github.com/qw4990) - インスタンスレベルの実行プランキャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションで実行プランキャッシュを共有できます。この機能により、TiDB クエリの応答時間が大幅に短縮され、クラスタのスループットが向上し、実行プランの変更の可能性が低減され、クラスタのパフォーマンスが安定します。セッションレベルの実行プランキャッシュと比較して、インスタンスレベルの実行プランキャッシュには次の利点があります。 + インスタンスレベルの実行プランキャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションで実行プランキャッシュを共有できます。この機能により、TiDB クエリの応答時間が大幅に短縮され、クラスターのスループットが向上し、実行プランの変更の可能性が低減され、クラスターのパフォーマンスが安定します。セッションレベルの実行プランキャッシュと比較して、インスタンスレベルの実行プランキャッシュには次の利点があります。 - 冗長性を排除し、同じメモリ消費量でより多くの実行プランをキャッシュします。 - インスタンスに固定サイズのメモリを割り当て、メモリ使用量をより効果的に制限します。 @@ -95,13 +95,13 @@ TiDB バージョン: 8.4.0 バージョン8.4.0より前では、 `tidb_scatter_region`システム変数は有効化または無効化のみが可能でした。有効化すると、TiDBはバッチテーブル作成時にテーブルレベルの分散戦略を適用します。しかし、バッチで数十万ものテーブルを作成する場合、この戦略によってリージョンが少数のTiKVノードに集中し、それらのノードでOOM（メモリ不足）の問題が発生します。 - バージョン8.4.0以降、 `tidb_scatter_region`は文字列型に変更されました。これにより、クラスタレベルの分散戦略がサポートされ、前述のシナリオにおけるTiKVのメモリ不足問題​​を回避するのに役立ちます。 + バージョン8.4.0以降、 `tidb_scatter_region`は文字列型に変更されました。これにより、クラスターレベルの分散戦略がサポートされ、前述のシナリオにおけるTiKVのメモリ不足問題​​を回避するのに役立ちます。 詳細については、[ドキュメント](/system-variables.md#tidb_scatter_region)を参照してください。 - リソース制御のバックグラウンドタスクにおけるリソース使用量の上限設定をサポートする [#56019](https://github.com/pingcap/tidb/issues/56019) @[glorv](https://github.com/glorv) - TiDBのリソース制御機能を使用すると、バックグラウンドタスクを識別して優先度を下げることができます。特定のシナリオでは、リソースが利用可能な場合でも、バックグラウンドタスクのリソース消費を制限したい場合があります。v8.4.0以降では、 `UTILIZATION_LIMIT`パラメータを使用して、バックグラウンドタスクが消費できるリソースの最大割合を設定できます。各ノードは、すべてのバックグラウンドタスクのリソース使用量をこの割合以下に抑えます。この機能により、バックグラウンドタスクのリソース消費を正確に制御できるため、クラスタの安定性がさらに向上します。 + TiDBのリソース制御機能を使用すると、バックグラウンドタスクを識別して優先度を下げることができます。特定のシナリオでは、リソースが利用可能な場合でも、バックグラウンドタスクのリソース消費を制限したい場合があります。v8.4.0以降では、 `UTILIZATION_LIMIT`パラメータを使用して、バックグラウンドタスクが消費できるリソースの最大割合を設定できます。各ノードは、すべてのバックグラウンドタスクのリソース使用量をこの割合以下に抑えます。この機能により、バックグラウンドタスクのリソース消費を正確に制御できるため、クラスターの安定性がさらに向上します。 詳細については、 [ドキュメント](/tidb-resource-control-background-tasks.md)を参照してください。 @@ -116,7 +116,7 @@ TiDB バージョン: 8.4.0 - TiProxyがトラフィック再生をサポート（実験的） [#642](https://github.com/pingcap/tiproxy/issues/642) @[djshow832](https://github.com/djshow832) - TiProxy v1.3.0以降では、 `tiproxyctl`を使用してTiProxyインスタンスに接続し、TiDB本番クラスタのアクセストラフィックをキャプチャして、指定したレートでテストクラスタに再生できます。この機能により、本番クラスタの実際のワークロードをテスト環境で再現し、SQLステートメントの実行結果とパフォーマンスを検証できます。 + TiProxy v1.3.0以降では、 `tiproxyctl`を使用してTiProxyインスタンスに接続し、TiDB本番クラスターのアクセストラフィックをキャプチャして、指定したレートでテストクラスターに再生できます。この機能により、本番クラスターの実際のワークロードをテスト環境で再現し、SQLステートメントの実行結果とパフォーマンスを検証できます。 交通状況のリプレイは、次のような状況で役立ちます。 @@ -145,7 +145,7 @@ TiDB バージョン: 8.4.0 - BRはログ バックアップ データのクライアント側暗号化をサポートします (実験的) [#55834](https://github.com/pingcap/tidb/issues/55834) @[Tristan1900](https://github.com/Tristan1900) - 以前のTiDBバージョンでは、スナップショットバックアップデータのみがクライアント側で暗号化されていました。v8.4.0以降では、ログバックアップデータもクライアント側で暗号化できるようになりました。ログバックアップデータをバックアップstorageにアップロードする前に、以下のいずれかの方法でバックアップデータを暗号化してセキュリティを確保できます。 + 以前のTiDBバージョンでは、スナップショットバックアップデータのみがクライアント側で暗号化されていました。v8.4.0以降では、ログバックアップデータもクライアント側で暗号化できるようになりました。ログバックアップデータをバックアップストレージにアップロードする前に、以下のいずれかの方法でバックアップデータを暗号化してセキュリティを確保できます。 - カスタム固定キーを使用して暗号化する - ローカルディスクに保存されているマスターキーを使用して暗号化します。 @@ -153,17 +153,17 @@ TiDB バージョン: 8.4.0 詳細については、 [ドキュメント](/br/br-pitr-manual.md#encrypt-the-log-backup-data)を参照してください。 -- BRはクラウドstorageシステムでバックアップデータを復元する際に、より少ない権限しか必要としない [#55870](https://github.com/pingcap/tidb/issues/55870) @[Leavrth](https://github.com/Leavrth) +- BRはクラウドストレージシステムでバックアップデータを復元する際に、より少ない権限しか必要としない [#55870](https://github.com/pingcap/tidb/issues/55870) @[Leavrth](https://github.com/Leavrth) - バージョン8.4.0より前は、 BRはリストア中にリストアの進行状況に関するチェックポイント情報をバックアップstorageシステムに書き込みます。これらのチェックポイントにより、中断されたリストアを迅速に再開できます。バージョン8.4.0以降では、 BRはリストアチェックポイント情報をターゲットのTiDBクラスタに書き込みます。つまり、 BRはリストア中にバックアップディレクトリへの読み取りアクセスのみを必要とします。 + バージョン8.4.0より前は、 BRはリストア中にリストアの進行状況に関するチェックポイント情報をバックアップストレージシステムに書き込みます。これらのチェックポイントにより、中断されたリストアを迅速に再開できます。バージョン8.4.0以降では、 BRはリストアチェックポイント情報をターゲットのTiDBクラスターに書き込みます。つまり、 BRはリストア中にバックアップディレクトリへの読み取りアクセスのみを必要とします。 - 詳細については、 [ドキュメント](/br/backup-and-restore-storages.md#authentication)を参照してください。 + 詳細については、 [ドキュメント](/br/backup-and-restore-ストレージs.md#authentication)を参照してください。 ### 可観測性 {#observability} - TiDBとTiKVが消費したCPU時間をシステムテーブルに表示する [#55542](https://github.com/pingcap/tidb/issues/55542) @[yibin87](https://github.com/yibin87) - [TiDBダッシュボード](/dashboard/dashboard-intro.md)の[Top SQLページ](/dashboard/top-sql.md)CPU 使用率の高い SQL ステートメントを表示します。バージョン 8.4.0 以降、TiDB はシステム テーブルに CPU 使用時間情報を追加し、セッションや SQL の他のメトリックと並べて表示することで、CPU 使用率の高い操作をさまざまな視点から簡単に把握できるようにしました。この情報は、インスタンスの CPU スパイクやクラスタ内の読み書きホットスポットなどのシナリオで、問題の原因を迅速に特定するのに役立ちます。 + [TiDBダッシュボード](/dashboard/dashboard-intro.md)の[Top SQLページ](/dashboard/top-sql.md)CPU 使用率の高い SQL ステートメントを表示します。バージョン 8.4.0 以降、TiDB はシステム テーブルに CPU 使用時間情報を追加し、セッションや SQL の他のメトリックと並べて表示することで、CPU 使用率の高い操作をさまざまな視点から簡単に把握できるようにしました。この情報は、インスタンスの CPU スパイクやクラスター内の読み書きホットスポットなどのシナリオで、問題の原因を迅速に特定するのに役立ちます。 - [明細書概要表](/statement-summary-tables.md)には`AVG_TIDB_CPU_TIME`と`AVG_TIKV_CPU_TIME`が追加され、過去の個々の SQL ステートメントによって消費された平均 CPU 時間が表示されます。 - [情報スキーマ.プロセスリスト](/information-schema/information-schema-processlist.md)テーブルには、 `TIDB_CPU`と`TIKV_CPU`が追加され、現在セッションで実行されている SQL ステートメントの累積 CPU 消費量が表示されます。 @@ -185,21 +185,21 @@ TiDB バージョン: 8.4.0 TiDBをAmazon EC2にデプロイする場合、 BRはAWSインスタンスメタデータサービスバージョン2（IMDSv2）をサポートします。EC2インスタンスを設定することで、 BRがインスタンスに関連付けられたIAMロールを使用してAmazon S3にアクセスするための適切な権限を取得できます。 - 詳細については、 [ドキュメント](/br/backup-and-restore-storages.md#authentication)を参照してください。 + 詳細については、 [ドキュメント](/br/backup-and-restore-ストレージs.md#authentication)を参照してください。 ### データ移行 {#data-migration} -- TiCDC Claim-Check は、Kafka メッセージの`value`フィールドの外部storageへの送信のみをサポートします [#11396](https://github.com/pingcap/tiflow/issues/11396) @[3AceShowHand](https://github.com/3AceShowHand) +- TiCDC Claim-Check は、Kafka メッセージの`value`フィールドの外部ストレージへの送信のみをサポートします [#11396](https://github.com/pingcap/tiflow/issues/11396) @[3AceShowHand](https://github.com/3AceShowHand) - バージョン 8.4.0 より前では、クレームチェック機能が有効になっている場合 ( `large-message-handle-option`を`claim-check`に設定した場合)、TiCDC は大きなメッセージを処理する際に、 `key`と`value`フィールドの両方をエンコードして外部storageシステムに保存します。 + バージョン 8.4.0 より前では、クレームチェック機能が有効になっている場合 ( `large-message-handle-option`を`claim-check`に設定した場合)、TiCDC は大きなメッセージを処理する際に、 `key`と`value`フィールドの両方をエンコードして外部ストレージシステムに保存します。 - バージョン8.4.0以降、TiCDCはKafkaメッセージの`value`フィールドのみを外部storageに送信する機能をサポートしています。この機能は、Open Protocol以外のプロトコルにのみ適用されます。 `claim-check-raw-value`パラメータを設定することで、この機能を制御できます。 + バージョン8.4.0以降、TiCDCはKafkaメッセージの`value`フィールドのみを外部ストレージに送信する機能をサポートしています。この機能は、Open Protocol以外のプロトコルにのみ適用されます。 `claim-check-raw-value`パラメータを設定することで、この機能を制御できます。 - 詳細については、 [ドキュメント](/ticdc/ticdc-sink-to-kafka.md#send-the-value-field-to-external-storage-only)を参照してください。 + 詳細については、 [ドキュメント](/ticdc/ticdc-sink-to-kafka.md#send-the-value-field-to-external-ストレージ-only)を参照してください。 - TiCDC は、更新または削除イベントで古い値を検証するための Checksum V2 を導入 [#10969](https://github.com/pingcap/tiflow/issues/10969) @[3AceShowHand](https://github.com/3AceShowHand) - バージョン 8.4.0 以降、TiDB と TiCDC は`ADD COLUMN`または`DROP COLUMN`操作後の Update イベントまたは Delete イベントで古い値を検証する際の Checksum V1 の問題に対処するため、Checksum V2 アルゴリズムを導入しました。バージョン 8.4.0 以降で作成されたクラスタ、またはバージョン 8.4.0 にアップグレードされたクラスタでは、単一行データのチェックサム検証が有効になっている場合、TiDB はデフォルトで Checksum V2 を使用します。TiCDC は Checksum V1 と V2 の両方の処理をサポートしています。この変更は TiDB と TiCDC の内部実装にのみ影響し、下流の Kafka コンシューマーのチェックサム計算方法には影響しません。 + バージョン 8.4.0 以降、TiDB と TiCDC は`ADD COLUMN`または`DROP COLUMN`操作後の Update イベントまたは Delete イベントで古い値を検証する際の Checksum V1 の問題に対処するため、Checksum V2 アルゴリズムを導入しました。バージョン 8.4.0 以降で作成されたクラスター、またはバージョン 8.4.0 にアップグレードされたクラスターでは、単一行データのチェックサム検証が有効になっている場合、TiDB はデフォルトで Checksum V2 を使用します。TiCDC は Checksum V1 と V2 の両方の処理をサポートしています。この変更は TiDB と TiCDC の内部実装にのみ影響し、下流の Kafka コンシューマーのチェックサム計算方法には影響しません。 詳細については、[ドキュメント](/ticdc/ticdc-integrity-check.md)を参照してください。 @@ -221,9 +221,9 @@ TiDB バージョン: 8.4.0 | [`tidb_analyze_partition_concurrency`](/system-variables.md#tidb_analyze_partition_concurrency) | 修正済み | 値の範囲を`[1, 18446744073709551615]`から`[1, 128]`に変更します。 | | [`tidb_enable_inl_join_inner_multi_pattern`](/system-variables.md#tidb_enable_inl_join_inner_multi_pattern-new-in-v700) | 修正済み | デフォルト値を`OFF`から`ON`に変更します。v8.4.0 以降、内部テーブルに`Selection` 、{{B-PLACEHOLDER-3-PLACEHOLDER- `Aggregation` `Projection`デフォルトでサポートされます。 | | [`tidb_opt_prefer_range_scan`](/system-variables.md#tidb_opt_prefer_range_scan-new-in-v50) | 修正済み | デフォルト値を`OFF`から`ON`に変更します。統計情報がないテーブル (擬似統計情報) または空のテーブル (統計情報がゼロ) の場合、オプティマイザはフルテーブルスキャンよりもインターバルスキャンを優先します。 | -| [`tidb_scatter_region`](/system-variables.md#tidb_scatter_region) | 修正済み | v8.4.0 より前は、型はブール型で、 `ON`と`OFF`のみをサポートし、新しく作成されたテーブルのリージョンは、有効化後にのみテーブルレベルの分散をサポートします。v8.4.0 以降では、 `SESSION`スコープが追加され、型がブール型から列挙型に変更され、デフォルト値が`OFF`から null に変更され、オプション値`TABLE`と`GLOBAL`が追加されました。さらに、バッチでの高速テーブル作成中にリージョンの不均一な分散によって発生する TiKV OOM の問題を回避するために、クラスタレベルの分散ポリシーがサポートされるようになりました。 | +| [`tidb_scatter_region`](/system-variables.md#tidb_scatter_region) | 修正済み | v8.4.0 より前は、型はブール型で、 `ON`と`OFF`のみをサポートし、新しく作成されたテーブルのリージョンは、有効化後にのみテーブルレベルの分散をサポートします。v8.4.0 以降では、 `SESSION`スコープが追加され、型がブール型から列挙型に変更され、デフォルト値が`OFF`から null に変更され、オプション値`TABLE`と`GLOBAL`が追加されました。さらに、バッチでの高速テーブル作成中にリージョンの不均一な分散によって発生する TiKV OOM の問題を回避するために、クラスターレベルの分散ポリシーがサポートされるようになりました。 | | [`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800) | 修正済み | デフォルト値を`0`から`536870912` (512 MiB) に変更し、この機能がデフォルトで有効になっていることを示します。許可される最小値は`67108864` (64 MiB) に設定されています。 | -| [`tidb_auto_analyze_concurrency`](/system-variables.md#tidb_auto_analyze_concurrency-new-in-v840) | 新しく追加された | TiDB クラスタ内での自動分析操作の同時実行数を設定します。v8.4.0 より前のバージョンでは、この同時実行数は`1`に固定されていました。統計情報の収集タスクを高速化するには、クラスタで使用可能なリソースに基づいてこの同時実行数を増やすことができます。 | +| [`tidb_auto_analyze_concurrency`](/system-variables.md#tidb_auto_analyze_concurrency-new-in-v840) | 新しく追加された | TiDB クラスター内での自動分析操作の同時実行数を設定します。v8.4.0 より前のバージョンでは、この同時実行数は`1`に固定されていました。統計情報の収集タスクを高速化するには、クラスターで使用可能なリソースに基づいてこの同時実行数を増やすことができます。 | | [`tidb_enable_instance_plan_cache`](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840) | 新しく追加された | インスタンスプランキャッシュ機能を有効にするかどうかを制御します。 | | [`tidb_enable_stats_owner`](/system-variables.md#tidb_enable_stats_owner-new-in-v840) | 新しく追加された | 対応するTiDBインスタンスが自動統計更新タスクを実行できるかどうかを制御します。 | | [`tidb_hash_join_version`](/system-variables.md#tidb_hash_join_version-new-in-v840) | 新しく追加された | TiDB がハッシュ結合演算子の最適化バージョンを使用するかどうかを制御します。デフォルト値の`legacy`は、最適化バージョンが使用されないことを意味します。これを`optimized`に設定すると、TiDB はハッシュ結合演算子の実行時に最適化バージョンを使用して、ハッシュ結合のパフォーマンスを向上させます。 | @@ -233,26 +233,26 @@ TiDB バージョン: 8.4.0 | [`tidb_shard_row_id_bits`](/system-variables.md#tidb_shard_row_id_bits-new-in-v840) | 新しく追加された | バージョン 8.4.0 より前では、新しく作成されたテーブルの行 ID のスライス数のデフォルト設定を行うには、 `SHARD_ROW_ID_BITS`または`CREATE TABLE` SQL ステートメントごとに`ALTER TABLE`宣言する必要がありましたが、多数のテーブルを同様に構成する必要がある場合は複雑でした。この変数は、このような問題を解決するために導入されました。使いやすさを向上させるために、このシステム変数を`GLOBAL`または`SESSION`レベルで設定できます。 | | [`tidb_tso_client_rpc_mode`](/system-variables.md#tidb_tso_client_rpc_mode-new-in-v840) | 新しく追加された | TiDBがPDにTSO RPCリクエストを送信するモードを切り替えます。このモードによって、TSO RPCリクエストを並列処理できるかどうかが決まり、各TS取得操作のバッチ待機時間に影響するため、特定のシナリオにおけるクエリ実行中のTS取得の待機時間を短縮できます。 | -### コンフィグレーションパラメータ {#configuration-parameters} +### 設定パラメータ {#configuration-parameters} -| コンフィグレーションファイルまたはコンポーネント | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイルまたはコンポーネント | 設定パラメータ | 種類を変更する | 説明 | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------ | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`grpc-keepalive-time`](/tidb-configuration-file.md#grpc-keepalive-time) | 修正済み | `1`の最小値を追加します。 | | TiDB | [`grpc-keepalive-timeout`](/tidb-configuration-file.md#grpc-keepalive-timeout) | 修正済み | バージョン 8.4.0 より前は、このパラメータのデータ型は INT で、最小値は`1`でした。バージョン 8.4.0 以降では、データ型が FLOAT64 に変更され、最小値は`0.05`になります。ネットワークのジッターが頻繁に発生するシナリオでは、値を小さく設定して再試行間隔を短くすることで、ネットワークのジッターがパフォーマンスに与える影響を軽減できます。 | | TiDB | [`tidb_enable_stats_owner`](/tidb-configuration-file.md#tidb_enable_stats_owner-new-in-v840) | 新しく追加された | 対応するTiDBインスタンスが自動統計更新タスクを実行できるかどうかを制御します。 | -| ティクヴ | [`region-split-keys`](/tikv-configuration-file.md#region-split-keys) | 修正済み | デフォルト値を`"960000"`から`"2560000"`に変更します。 | -| ティクヴ | [`region-split-size`](/tikv-configuration-file.md#region-split-size) | 修正済み | デフォルト値を`"96MiB"`から`"256MiB"`に変更します。 | -| ティクヴ | [`sst-max-size`](/tikv-configuration-file.md#sst-max-size) | 修正済み | デフォルト値を`"144MiB"`から`"384MiB"`に変更します。 | -| ティクヴ | [`pessimistic-txn.in-memory-instance-size-limit`](/tikv-configuration-file.md#in-memory-instance-size-limit-new-in-v840) | 新しく追加された | TiKVインスタンスにおけるメモリ内悲観的ロックのメモリ使用量制限を制御します。この制限を超えると、TiKVは悲観的ロックを永続的に書き込みます。 | -| ティクヴ | [`pessimistic-txn.in-memory-peer-size-limit`](/tikv-configuration-file.md#in-memory-peer-size-limit-new-in-v840) | 新しく追加された | リージョン内のメモリ内悲観的ロックのメモリ使用量制限を制御します。この制限を超えると、TiKV は悲観的ロックを永続的に書き込みます。 | -| ティクヴ | [`raft-engine.spill-dir`](/tikv-configuration-file.md#spill-dir-new-in-v840) | 新しく追加された | TiKVインスタンスがRaftログファイルを保存するセカンダリディレクトリを制御し、 Raftログファイルのマルチディスクstorageをサポートします。 | -| ティクヴ | [`resource-control.priority-ctl-strategy`](/tikv-configuration-file.md#priority-ctl-strategy-new-in-v840) | 新しく追加された | 優先度の低いタスクの管理ポリシーを制御します。TiKVは、優先度の低いタスクにフロー制御を追加することで、優先度の高いタスクが優先的に実行されるようにします。 | +| TiKV | [`region-split-keys`](/tikv-configuration-file.md#region-split-keys) | 修正済み | デフォルト値を`"960000"`から`"2560000"`に変更します。 | +| TiKV | [`region-split-size`](/tikv-configuration-file.md#region-split-size) | 修正済み | デフォルト値を`"96MiB"`から`"256MiB"`に変更します。 | +| TiKV | [`sst-max-size`](/tikv-configuration-file.md#sst-max-size) | 修正済み | デフォルト値を`"144MiB"`から`"384MiB"`に変更します。 | +| TiKV | [`pessimistic-txn.in-memory-instance-size-limit`](/tikv-configuration-file.md#in-memory-instance-size-limit-new-in-v840) | 新しく追加された | TiKVインスタンスにおけるメモリ内悲観的ロックのメモリ使用量制限を制御します。この制限を超えると、TiKVは悲観的ロックを永続的に書き込みます。 | +| TiKV | [`pessimistic-txn.in-memory-peer-size-limit`](/tikv-configuration-file.md#in-memory-peer-size-limit-new-in-v840) | 新しく追加された | リージョン内のメモリ内悲観的ロックのメモリ使用量制限を制御します。この制限を超えると、TiKV は悲観的ロックを永続的に書き込みます。 | +| TiKV | [`raft-engine.spill-dir`](/tikv-configuration-file.md#spill-dir-new-in-v840) | 新しく追加された | TiKVインスタンスがRaftログファイルを保存するセカンダリディレクトリを制御し、 Raftログファイルのマルチディスクストレージをサポートします。 | +| TiKV | [`resource-control.priority-ctl-strategy`](/tikv-configuration-file.md#priority-ctl-strategy-new-in-v840) | 新しく追加された | 優先度の低いタスクの管理ポリシーを制御します。TiKVは、優先度の低いタスクにフロー制御を追加することで、優先度の高いタスクが優先的に実行されるようにします。 | | PD | [`cert-allowed-cn`](/enable-tls-between-components.md#verify-component-callers-identity) | 修正済み | バージョン8.4.0以降では、複数の`Common Names`の設定がサポートされています。バージョン8.4.0より前は、 `Common Name` 1つしか設定できませんでした。 | | PD | [`max-merge-region-keys`](/pd-configuration-file.md#max-merge-region-keys) | 修正済み | デフォルト値を`200000`から`540000`に変更します。 | | PD | [`max-merge-region-size`](/pd-configuration-file.md#max-merge-region-size) | 修正済み | デフォルト値を`20`から`54`に変更します。 | -| TiFlash | [`storage.format_version`](/tiflash/tiflash-configuration.md) | 修正済み | ベクターインデックスの作成とstorageをサポートするため、デフォルトのTiFlashstorageフォーマットバージョンを`5`から`7`に変更します。このフォーマット変更により、v8.4.0以降のバージョンにアップグレードされたTiFlashクラスタでは、以前のバージョンへのインプレースダウングレードはサポートされません。 | +| TiFlash | [`ストレージ.format_version`](/tiflash/tiflash-configuration.md) | 修正済み | ベクターインデックスの作成とストレージをサポートするため、デフォルトのTiFlashストレージフォーマットバージョンを`5`から`7`に変更します。このフォーマット変更により、v8.4.0以降のバージョンにアップグレードされたTiFlashクラスターでは、以前のバージョンへのインプレースダウングレードはサポートされません。 | | TiDBBinlog | `--enable-binlog` | 削除済み | バージョン8.4.0では、 [TiDBBinlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)が削除されました。このパラメータは、TiDBbinlogの生成を有効にするかどうかを制御するもので、バージョン8.4.0以降は削除されます。 | -| TiCDC | [`claim-check-raw-value`](/ticdc/ticdc-sink-to-kafka.md#send-the-value-field-to-external-storage-only) | 新しく追加された | TiCDCがKafkaメッセージの`value`フィールドのみを外部storageに送信するかどうかを制御します。この機能は、オープンプロトコルを使用しないシナリオでのみ適用されます。 | +| TiCDC | [`claim-check-raw-value`](/ticdc/ticdc-sink-to-kafka.md#send-the-value-field-to-external-ストレージ-only) | 新しく追加された | TiCDCがKafkaメッセージの`value`フィールドのみを外部ストレージに送信するかどうかを制御します。この機能は、オープンプロトコルを使用しないシナリオでのみ適用されます。 | | TiDB Lightning | [`logical-import-prep-stmt`](/tidb-lightning/tidb-lightning-configuration.md) | 新しく追加された | 論理インポートモードでは、このパラメーターは、パフォーマンスを向上させるためにプリペアドステートメントとステートメントキャッシュを使用するかどうかを制御します。デフォルト値は`false`です。 | | BR | [`--log.crypter.key`](/br/br-pitr-manual.md#encrypt-the-log-backup-data) | 新しく追加された | ログバックアップデータの暗号化キーを16進数文字列形式で指定します。アルゴリズム`aes128-ctr`の場合は128ビット（16バイト）のキー、アルゴリズム`aes192-ctr` `aes256-ctr`の場合は32バイトのキーです。 | | BR | [`--log.crypter.key-file`](/br/br-pitr-manual.md#encrypt-the-log-backup-data) | 新しく追加された | ログバックアップデータのキーファイルを指定します。 `crypter.key`を渡さずに、キーが格納されているファイルパスをパラメータとして直接渡すことができます。 | @@ -273,14 +273,14 @@ v8.4.0 以降、次のコンテンツが`TiDB-community-toolkit`[バイナリパ TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 -- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 にアップグレードすると、クラスタが利用できなくなります。 -- [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB は、8.4 DMR バージョン以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタを v8.4.0 以降にアップグレードすると、クラスタが使用できなくなります。 +- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスターを v8.4.0 にアップグレードすると、クラスターが利用できなくなります。 +- [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB は、8.4 DMR バージョン以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスターを v8.4.0 以降にアップグレードすると、クラスターが使用できなくなります。 ## 削除された機能 {#removed-features} - バージョン8.4.0以降、以下の機能が削除されます。 - - バージョン 8.4.0 では、 [TiDBBinlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)は削除されました。バージョン 8.3.0 以降、TiDB Binlog は完全に非推奨となっています。増分データレプリケーションには、代わりに[TiCDC](/ticdc/ticdc-overview.md)を使用してください。ポイントインタイムリカバリ(PITR) には、 [PITR](/br/br-pitr-guide.md)を使用してください。TiDB クラスタをバージョン 8.4.0 以降にアップグレードする前に、必ず TiCDC と PITR に切り替えてください。 + - バージョン 8.4.0 では、 [TiDBBinlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)は削除されました。バージョン 8.3.0 以降、TiDB Binlog は完全に非推奨となっています。増分データレプリケーションには、代わりに[TiCDC](/ticdc/ticdc-overview.md)を使用してください。ポイントインタイムリカバリ(PITR) には、 [PITR](/br/br-pitr-guide.md)を使用してください。TiDB クラスターをバージョン 8.4.0 以降にアップグレードする前に、必ず TiCDC と PITR に切り替えてください。 - 今後のバージョンでは、以下の機能が削除される予定です。 @@ -308,7 +308,7 @@ TiDB をアップグレードする前に、オペレーティング システ - [`mysql.tidb_runaway_queries`](/mysql-schema/mysql-schema.md#system-tables-related-to-runaway-queries)ログ テーブルに書き込み制御を追加し、多数の同時書き込みによって発生するオーバーヘッドを削減します [#54434](https://github.com/pingcap/tidb/issues/54434) @[HuSharp](https://github.com/HuSharp) - 内部テーブルに`Selection` 、 `Projection` 、または`Aggregation`演算子がある場合、デフォルトでインデックス結合をサポートします [#47233](https://github.com/pingcap/tidb/issues/47233) @[winoros](https://github.com/winoros) - 特定のシナリオにおける`DELETE`操作のために TiKV から取得する列の詳細の数を減らし、これらの操作のリソースオーバーヘッドを削減します [#38911](https://github.com/pingcap/tidb/issues/38911) @[winoros](https://github.com/winoros) - - TiDBクラスタ内での自動分析操作の同時実行設定をシステム変数`tidb_auto_analyze_concurrency`を使用してサポートする [#53460](https://github.com/pingcap/tidb/issues/53460) @[hawkingrei](https://github.com/hawkingrei) + - TiDBクラスター内での自動分析操作の同時実行設定をシステム変数`tidb_auto_analyze_concurrency`を使用してサポートする [#53460](https://github.com/pingcap/tidb/issues/53460) @[hawkingrei](https://github.com/hawkingrei) - 多数の列を持つテーブルをクエリする際のパフォーマンスを向上させるため、内部関数のロジックを最適化します [#52112](https://github.com/pingcap/tidb/issues/52112) @[Rustin170506](https://github.com/Rustin170506) - `a = 1 AND (a > 1 OR (a = 1 AND b = 2))`から`a = 1 AND b = 2`のようなフィルター条件を簡素化 [#56005](https://github.com/pingcap/tidb/issues/56005) @[ghazalfamilyusa](https://github.com/ghazalfamilyusa) - 最適ではない実行プランのリスクが高いシナリオでは、コストモデルでテーブルスキャンのコストを増やし、オプティマイザがインデックスを優先するようにします [#56012](https://github.com/pingcap/tidb/issues/56012) @[terry1purcell](https://github.com/terry1purcell) @@ -320,11 +320,11 @@ TiDB をアップグレードする前に、オペレーティング システ - TiDB のアップグレード中に、新しい TiDB ノードが DDL の所有権を引き継ぐように強制することで、古い TiDB ノードが所有権を引き継ぐことによる互換性の問題を回避する [#51285](https://github.com/pingcap/tidb/pull/51285) @[wjhuang2016](https://github.com/wjhuang2016) - クラスターレベルの散乱リージョン [#8424](https://github.com/tikv/pd/issues/8424) @[River2000i](https://github.com/River2000i)をサポート -- ティクヴ +- TiKV - リージョンのデフォルト値を 96 MiB から 256 MiB に増やして、Region が多すぎることによる余分なオーバーヘッドを回避します [#17309](https://github.com/tikv/tikv/issues/17309) @[LykxSassinator](https://github.com/LykxSassinator) - リージョンまたはTiKVインスタンスにおけるインメモリ悲観的ロックのメモリ使用量制限の設定をサポートします。ホットライトシナリオで多数の悲観的ロックが発生する場合、構成によってメモリ制限を増やすことができます。これにより、悲観的ロックがディスクに書き込まれることによって発生するCPUおよびI/Oオーバーヘッドを回避できます。 [#17542](https://github.com/tikv/tikv/issues/17542) @[cfzjywxk](https://github.com/cfzjywxk) - - Raft Engineに新しい設定項目`spill-dir`を導入し、 Raftログのマルチディスクstorageをサポートします。ホームディレクトリ ( `dir`が配置されているディスクの空き容量がなくなると、 Raft Engine は新しいログを自動的に`spill-dir`に書き込み、システムの継続的な動作を保証します [#17356](https://github.com/tikv/tikv/issues/17356) @[LykxSassinator](https://github.com/LykxSassinator) + - Raft Engineに新しい設定項目`spill-dir`を導入し、 Raftログのマルチディスクストレージをサポートします。ホームディレクトリ ( `dir`が配置されているディスクの空き容量がなくなると、 Raft Engine は新しいログを自動的に`spill-dir`に書き込み、システムの継続的な動作を保証します [#17356](https://github.com/tikv/tikv/issues/17356) @[LykxSassinator](https://github.com/LykxSassinator) - RocksDB の圧縮トリガー メカニズムを最適化し、多数の DELETE バージョンを処理する際のディスク領域の再利用を加速します [#17269](https://github.com/tikv/tikv/issues/17269) @[AndreMouche](https://github.com/AndreMouche) - 書き込み操作のフロー制御構成を動的に変更するサポート [#17395](https://github.com/tikv/tikv/issues/17395) @[glorv](https://github.com/glorv) - 空のテーブルと小さなリージョンを含むシナリオでのリージョンマージの速度を改善 [#17376](https://github.com/tikv/tikv/issues/17376) @[LykxSassinator](https://github.com/LykxSassinator) @@ -339,7 +339,7 @@ TiDB をアップグレードする前に、オペレーティング システ - TiFlash - `LENGTH()`および`ASCII()`関数の実行効率を最適化する [#9344](https://github.com/pingcap/tiflash/issues/9344) @[xzhangxian1008](https://github.com/xzhangxian1008) - - TiFlashが分散storageとコンピューティング要求を処理する際に作成する必要のあるスレッド数を減らし、そのような要求を多数処理する際のTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます [#9334](https://github.com/pingcap/tiflash/issues/9334) @[JinheLin](https://github.com/JinheLin) + - TiFlashが分散ストレージとコンピューティング要求を処理する際に作成する必要のあるスレッド数を減らし、そのような要求を多数処理する際のTiFlashコンピューティングノードのクラッシュを回避するのに役立ちます [#9334](https://github.com/pingcap/tiflash/issues/9334) @[JinheLin](https://github.com/JinheLin) - パイプライン実行モデルにおけるタスク待機メカニズムの強化 [#8869](https://github.com/pingcap/tiflash/issues/8869) @[SeaRise](https://github.com/SeaRise) - JOIN オペレーターがキャンセル要求にタイムリーに応答できるように、JOIN オペレーターのキャンセル メカニズムを改善 [#9430](https://github.com/pingcap/tiflash/issues/9430) @[windtalker](https://github.com/windtalker) @@ -366,7 +366,7 @@ TiDB をアップグレードする前に、オペレーティング システ - 非バイナリ照合順序を持つ文字列列の統計情報が、統計情報の初期化時にロードに失敗する可能性がある問題を修正 [#55684](https://github.com/pingcap/tidb/issues/55684) @[winoros](https://github.com/winoros) - クエリ条件`column IS NULL`を使用して一意インデックスにアクセスする際に、オプティマイザが行数を誤って 1 と推定する問題を修正しました。 [#56116](https://github.com/pingcap/tidb/issues/56116) @[hawkingrei](https://github.com/hawkingrei) - クエリに`(... AND ...) OR (... AND ...) ...`のようなフィルタ条件が含まれている場合、オプティマイザが行数推定に最適な複数列統計情報を使用しない問題を修正します [#54323](https://github.com/pingcap/tidb/issues/54323) @[time-and-fate](https://github.com/time-and-fate) - - クエリに利用可能なインデックス マージ実行プランがある場合、 `read_from_storage`ヒントが有効にならない可能性がある問題を修正 [#56217](https://github.com/pingcap/tidb/issues/56217) @[AilinKid](https://github.com/AilinKid) + - クエリに利用可能なインデックス マージ実行プランがある場合、 `read_from_ストレージ`ヒントが有効にならない可能性がある問題を修正 [#56217](https://github.com/pingcap/tidb/issues/56217) @[AilinKid](https://github.com/AilinKid) - `IndexNestedLoopHashJoin` [#49692](https://github.com/pingcap/tidb/issues/49692)のデータ競合問題を修正 @[solotzg](https://github.com/solotzg) - `SUB_PART`テーブル内の`INFORMATION_SCHEMA.STATISTICS`の値が`NULL`になっている問題を修正します [#55812](https://github.com/pingcap/tidb/issues/55812) @[Defined2014](https://github.com/Defined2014) - DMLステートメントにネストされた生成列が含まれている場合にエラーが発生する問題を修正しました [#53967](https://github.com/pingcap/tidb/issues/53967) @[wjhuang2016](https://github.com/wjhuang2016) @@ -384,7 +384,7 @@ TiDB をアップグレードする前に、オペレーティング システ - パーティションテーブルを作成する際に、 `CREATE TABLE`と`ALTER TABLE`の間で列タイプの制限が矛盾する問題を修正 [#56094](https://github.com/pingcap/tidb/issues/56094) @[mjonss](https://github.com/mjonss) - `INFORMATION_SCHEMA.RUNAWAY_WATCHES`テーブル内の誤った時間タイプを修正 [#54770](https://github.com/pingcap/tidb/issues/54770) @[HuSharp](https://github.com/HuSharp) -- ティクヴ +- TiKV - マスターキーがキー管理サービス（KMS）に保存されている場合にマスターキーのローテーションが妨げられる問題を修正しました [#17410](https://github.com/tikv/tikv/issues/17410) @[hhwyt](https://github.com/hhwyt) - 大きなテーブルやパーティションを削除した後に発生する可能性のあるトラフィック制御の問題を修正 [#17304](https://github.com/tikv/tikv/issues/17304) @[Connor1996](https://github.com/Connor1996) diff --git a/releases/release-8.5.0.md b/releases/release-8.5.0.md index a17dd59e6b893..887f3ac37d33c 100644 --- a/releases/release-8.5.0.md +++ b/releases/release-8.5.0.md @@ -17,7 +17,7 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 以前の LTS 8.1.0 と比較して、8.5.0 には[8.2.0-DMR](/releases/release-8.2.0.md) 、 [8.3.0-DMR](/releases/release-8.3.0.md) 、および[8.4.0-DMR](/releases/release-8.4.0.md)でリリースされた新機能、改善点、およびバグ修正が含まれています。8.1.x から 8.5.0 にアップグレードすると、 [TiDB リリースノート PDF](https://docs-download.pingcap.com/pdf/tidb-v8.2-to-v8.5-en-release-notes.pdf)をダウンロードして、2 つの LTS バージョン間のすべてのリリースノートを確認できます。次の表は、8.1.0 から 8.5.0 までのハイライトの一部を示しています。 -
カテゴリ機能／改善点説明
拡張性とパフォーマンス複数の次元でデータ処理のレイテンシーを削減するTiDBは、パフォーマンス向上のためにデータ処理を継続的に改良し、金融分野における低遅延SQL処理の要件を効果的に満たしています。主なアップデート内容は以下のとおりです。
TiKV MVCC インメモリエンジン (IME) (バージョン8.5.0で導入) TiKV MVCCのインメモリエンジンは、最新のMVCCバージョンのデータをメモリにキャッシュすることで、古いバージョンをスキップして最新のデータを迅速に取得できるようにします。この機能は、データレコードが頻繁に更新される場合や、履歴バージョンが長期間保持される場合に、データスキャン性能を大幅に向上させることができます。
アクティブなPDフォロワーを使用して、PDのリージョン情報クエリサービスを強化します（v8.5.0で一般提供開始）。 TiDB v7.6.0 では、実験的機能「アクティブ PDFollower」が導入されました。これにより、PD フォロワーがリージョン情報クエリサービスを提供できるようになります。この機能は、多数の TiDB ノードとリージョンを持つクラスターにおいて、PD クラスターがGetRegionおよびScanRegionsリクエストを処理する能力を向上させ、PD リーダーの CPU 負荷を軽減します。この機能は、v8.5.0 で一般提供 (GA) されます。
インスタンスレベルの実行プランキャッシュ（実験的、v8.4.0で導入）インスタンスレベルのプランキャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションでプランキャッシュを共有できます。セッションレベルのプランキャッシュと比較して、この機能はメモリに多くの実行プランをキャッシュすることで SQL コンパイル時間を短縮し、SQL 全体の実行時間を短縮します。これにより、OLTP のパフォーマンスとスループットが向上するとともに、メモリ使用量をより適切に制御し、データベースの安定性を高めることができます。
パーティションテーブルのグローバルインデックス（バージョン8.4.0で一般提供開始）グローバルインデックスは、パーティション化されていない列の取得効率を効果的に向上させ、一意キーにパーティションキーを含める必要があるという制約を取り除きます。この機能により、TiDBパーティションテーブルの利用シナリオが拡張され、パーティションテーブルのパフォーマンスが向上し、特定のクエリシナリオにおけるリソース消費量が削減されます。
Projection演算子をstorageエンジンにデフォルトでプッシュダウンする機能（v8.3.0で導入） Projection演算子をstorageエンジンにプッシュダウンすることで、storageノード全体に負荷を分散させ、ノード間のデータ転送量を削減できます。この最適化により、特定のSQLクエリの実行時間が短縮され、データベース全体のパフォーマンスが向上します。
統計情報を収集する際に不要な列を無視する機能（バージョン8.3.0で導入）オプティマイザが必要な情報を確実に取得できるという前提のもと、TiDBは統計情報の収集を高速化し、統計情報の適時性を向上させることで、最適な実行プランの選択を保証し、クラスタのパフォーマンスを向上させます。同時に、TiDBはシステムオーバーヘッドを削減し、リソース利用率も向上させます。
信頼性と可用性大規模クラスターの安定性を向上させるTiDBを使用してマルチテナントアプリケーションやSaaSアプリケーションを運用する企業は、多くの場合、大量のテーブルを保存する必要があります。バージョン8.5.0では、TiDBは大規模クラスタの安定性を大幅に向上させました。
暴走クエリに対するトリガーの追加サポート、およびリソースグループの切り替えサポート（v8.4.0で導入）暴走クエリは、予期しないSQLパフォーマンスの問題がシステムに与える影響を軽減する効果的な手段です。TiDB v8.4.0では、識別条件としてコプロセッサーによって処理されたキーの数（ PROCESSED_KEYS ）とリクエストユニット（ RU ）が導入され、識別されたクエリを指定されたリソースグループに配置することで、暴走クエリのより正確な識別と制御が可能になりました。
リソース制御のバックグラウンドタスクにおけるリソース使用量の上限設定をサポート（実験的、v8.4.0で導入）リソース制御のバックグラウンドタスクに最大パーセンテージ制限を設定することで、さまざまなアプリケーションシステムのニーズに基づいてリソース消費を制御できます。これにより、バックグラウンドタスクの消費量を低く抑え、オンラインサービスの品質を確保できます。
TiProxyのユースケースを強化および拡張するTiDBの高可用性を実現する上で重要なコンポーネントであるTiProxyは、SQLトラフィックのアクセスと転送にとどまらず、クラスタ変更の評価をサポートする機能も備えています。主な機能は以下のとおりです。
TiDBの並列HashAggアルゴリズムはディスクスピルをサポートしています（v8.2.0でGA対応）。 HashAgg は、同じフィールド値を持つ行を効率的に集計するために TiDB で広く使用されている集計演算子です。TiDB v8.0.0 では、処理速度をさらに向上させる実験的機能として parallel HashAgg が導入されました。メモリリソースが不足している場合、parallel HashAgg は一時的にソートされたデータをディスクに書き出すことで、過剰なメモリ使用による潜在的な OOM リスクを回避します。これにより、ノードの安定性を維持しながらクエリ パフォーマンスが向上します。v8.2.0 では、この機能が一般提供 (GA) となり、デフォルトで有効になっているため、 tidb_executor_concurrencyを使用して parallel HashAgg の同時実行性を安全に構成できます。
SQL外部キー（バージョン8.5.0でGA対応）外部キーは、データベースにおける制約であり、テーブル間の関係を確立し、データの一貫性と整合性を確保します。外部キーは、子テーブルで参照されるデータが親テーブルに存在することを保証し、無効なデータの挿入を防ぎます。また、外部キーはカスケード操作（削除や更新時の自動同期など）をサポートし、ビジネスロジックの実装を簡素化し、データ関係を手動で維持する複雑さを軽減します。
ベクトル検索（実験的、v8.4.0で導入）ベクトル検索は、データの意味論に基づいた検索手法であり、より関連性の高い検索結果を提供します。AIや大規模言語モデル（LLM）の中核関数の一つとして、ベクトル検索は、検索拡張生成（RAG）、意味検索、推薦システムなど、さまざまなシナリオで活用できます。
データベースの運用と可観測性TiKVおよびTiDBのCPU時間をメモリテーブルに表示する（バージョン8.4.0で導入） CPU時間はシステムテーブルに統合され、セッションやSQLなどの他のメトリックと並べて表示されるようになりました。これにより、CPU使用率の高い操作を複数の視点から把握し、診断効率を向上させることができます。これは、インスタンスにおけるCPUスパイクやクラスタにおける読み書きホットスポットなどのシナリオを診断する際に特に役立ちます。
TiKVのCPU時間をテーブル別またはデータベース別に集計して表示する機能をサポート（v8.4.0で導入）ホットスポットの問題が個々のSQL文によって引き起こされていない場合、 Top SQLでテーブルまたはデータベースレベルごとに集計されたCPU時間を使用することで、ホットスポットの原因となっているテーブルやアプリケーションを迅速に特定でき、ホットスポットやCPU消費の問題の診断効率を大幅に向上させることができます。
Backup & Restore (BR)は、 AWS SDK for Rustを使用して外部storageにアクセスします (v8.5.0 で導入)。 BRは、TiKVからAmazon S3などの外部storageにアクセスするために、元のRusotoライブラリをAWS SDK for Rustに置き換えます。この変更により、 IMDSv2やEKS Pod IdentityなどのAWS機能との互換性が向上します。
Securityスナップショットバックアップデータおよびログバックアップデータのクライアント側暗号化（v8.5.0で一般提供開始）バックアップデータをバックアップstorageにアップロードする前に、バックアップデータを暗号化することで、storage中および転送中のセキュリティを確保できます。
+
カテゴリ機能／改善点説明
拡張性とパフォーマンス複数の次元でデータ処理のレイテンシーを削減するTiDBは、パフォーマンス向上のためにデータ処理を継続的に改良し、金融分野における低遅延SQL処理の要件を効果的に満たしています。主なアップデート内容は以下のとおりです。
TiKV MVCC インメモリエンジン (IME) (バージョン8.5.0で導入) TiKV MVCCのインメモリエンジンは、最新のMVCCバージョンのデータをメモリにキャッシュすることで、古いバージョンをスキップして最新のデータを迅速に取得できるようにします。この機能は、データレコードが頻繁に更新される場合や、履歴バージョンが長期間保持される場合に、データスキャン性能を大幅に向上させることができます。
アクティブなPDフォロワーを使用して、PDのリージョン情報クエリサービスを強化します（v8.5.0で一般提供開始）。 TiDB v7.6.0 では、実験的機能「アクティブ PDFollower」が導入されました。これにより、PD フォロワーがリージョン情報クエリサービスを提供できるようになります。この機能は、多数の TiDB ノードとリージョンを持つクラスターにおいて、PD クラスターがGetRegionおよびScanRegionsリクエストを処理する能力を向上させ、PD リーダーの CPU 負荷を軽減します。この機能は、v8.5.0 で一般提供 (GA) されます。
インスタンスレベルの実行プランキャッシュ（実験的、v8.4.0で導入）インスタンスレベルのプランキャッシュを使用すると、同じ TiDB インスタンス内のすべてのセッションでプランキャッシュを共有できます。セッションレベルのプランキャッシュと比較して、この機能はメモリに多くの実行プランをキャッシュすることで SQL コンパイル時間を短縮し、SQL 全体の実行時間を短縮します。これにより、OLTP のパフォーマンスとスループットが向上するとともに、メモリ使用量をより適切に制御し、データベースの安定性を高めることができます。
パーティションテーブルのグローバルインデックス（バージョン8.4.0で一般提供開始）グローバルインデックスは、パーティション化されていない列の取得効率を効果的に向上させ、一意キーにパーティションキーを含める必要があるという制約を取り除きます。この機能により、TiDBパーティションテーブルの利用シナリオが拡張され、パーティションテーブルのパフォーマンスが向上し、特定のクエリシナリオにおけるリソース消費量が削減されます。
Projection演算子をストレージエンジンにデフォルトでプッシュダウンする機能（v8.3.0で導入） Projection演算子をストレージエンジンにプッシュダウンすることで、ストレージノード全体に負荷を分散させ、ノード間のデータ転送量を削減できます。この最適化により、特定のSQLクエリの実行時間が短縮され、データベース全体のパフォーマンスが向上します。
統計情報を収集する際に不要な列を無視する機能（バージョン8.3.0で導入）オプティマイザが必要な情報を確実に取得できるという前提のもと、TiDBは統計情報の収集を高速化し、統計情報の適時性を向上させることで、最適な実行プランの選択を保証し、クラスターのパフォーマンスを向上させます。同時に、TiDBはシステムオーバーヘッドを削減し、リソース利用率も向上させます。
信頼性と可用性大規模クラスターの安定性を向上させるTiDBを使用してマルチテナントアプリケーションやSaaSアプリケーションを運用する企業は、多くの場合、大量のテーブルを保存する必要があります。バージョン8.5.0では、TiDBは大規模クラスターの安定性を大幅に向上させました。
暴走クエリに対するトリガーの追加サポート、およびリソースグループの切り替えサポート（v8.4.0で導入）暴走クエリは、予期しないSQLパフォーマンスの問題がシステムに与える影響を軽減する効果的な手段です。TiDB v8.4.0では、識別条件としてコプロセッサーによって処理されたキーの数（ PROCESSED_KEYS ）とリクエストユニット（ RU ）が導入され、識別されたクエリを指定されたリソースグループに配置することで、暴走クエリのより正確な識別と制御が可能になりました。
リソース制御のバックグラウンドタスクにおけるリソース使用量の上限設定をサポート（実験的、v8.4.0で導入）リソース制御のバックグラウンドタスクに最大パーセンテージ制限を設定することで、さまざまなアプリケーションシステムのニーズに基づいてリソース消費を制御できます。これにより、バックグラウンドタスクの消費量を低く抑え、オンラインサービスの品質を確保できます。
TiProxyのユースケースを強化および拡張するTiDBの高可用性を実現する上で重要なコンポーネントであるTiProxyは、SQLトラフィックのアクセスと転送にとどまらず、クラスター変更の評価をサポートする機能も備えています。主な機能は以下のとおりです。
TiDBの並列HashAggアルゴリズムはディスクスピルをサポートしています（v8.2.0でGA対応）。 HashAgg は、同じフィールド値を持つ行を効率的に集計するために TiDB で広く使用されている集計演算子です。TiDB v8.0.0 では、処理速度をさらに向上させる実験的機能として parallel HashAgg が導入されました。メモリリソースが不足している場合、parallel HashAgg は一時的にソートされたデータをディスクに書き出すことで、過剰なメモリ使用による潜在的な OOM リスクを回避します。これにより、ノードの安定性を維持しながらクエリ パフォーマンスが向上します。v8.2.0 では、この機能が一般提供 (GA) となり、デフォルトで有効になっているため、 tidb_executor_concurrencyを使用して parallel HashAgg の同時実行性を安全に構成できます。
SQL外部キー（バージョン8.5.0でGA対応）外部キーは、データベースにおける制約であり、テーブル間の関係を確立し、データの一貫性と整合性を確保します。外部キーは、子テーブルで参照されるデータが親テーブルに存在することを保証し、無効なデータの挿入を防ぎます。また、外部キーはカスケード操作（削除や更新時の自動同期など）をサポートし、ビジネスロジックの実装を簡素化し、データ関係を手動で維持する複雑さを軽減します。
ベクトル検索（実験的、v8.4.0で導入）ベクトル検索は、データの意味論に基づいた検索手法であり、より関連性の高い検索結果を提供します。AIや大規模言語モデル（LLM）の中核関数の一つとして、ベクトル検索は、検索拡張生成（RAG）、意味検索、推薦システムなど、さまざまなシナリオで活用できます。
データベースの運用と可観測性TiKVおよびTiDBのCPU時間をメモリテーブルに表示する（バージョン8.4.0で導入） CPU時間はシステムテーブルに統合され、セッションやSQLなどの他のメトリックと並べて表示されるようになりました。これにより、CPU使用率の高い操作を複数の視点から把握し、診断効率を向上させることができます。これは、インスタンスにおけるCPUスパイクやクラスターにおける読み書きホットスポットなどのシナリオを診断する際に特に役立ちます。
TiKVのCPU時間をテーブル別またはデータベース別に集計して表示する機能をサポート（v8.4.0で導入）ホットスポットの問題が個々のSQL文によって引き起こされていない場合、 Top SQLでテーブルまたはデータベースレベルごとに集計されたCPU時間を使用することで、ホットスポットの原因となっているテーブルやアプリケーションを迅速に特定でき、ホットスポットやCPU消費の問題の診断効率を大幅に向上させることができます。
Backup & Restore (BR)は、 AWS SDK for Rustを使用して外部ストレージにアクセスします (v8.5.0 で導入)。 BRは、TiKVからAmazon S3などの外部ストレージにアクセスするために、元のRusotoライブラリをAWS SDK for Rustに置き換えます。この変更により、 IMDSv2やEKS Pod IdentityなどのAWS機能との互換性が向上します。
Securityスナップショットバックアップデータおよびログバックアップデータのクライアント側暗号化（v8.5.0で一般提供開始）バックアップデータをバックアップストレージにアップロードする前に、バックアップデータを暗号化することで、ストレージ中および転送中のセキュリティを確保できます。
## 機能の詳細 {#feature-details} @@ -33,7 +33,7 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 - PDのリージョン情報クエリサービスの拡張性を向上させるため、アクティブPDFollower機能を提供する（GA） [#7431](https://github.com/tikv/pd/issues/7431) [okJiang](https://github.com/okJiang) - リージョン数の多いTiDBクラスタでは、ハートビート処理やタスクスケジューリングに伴うオーバーヘッドが増加するため、PDリーダーのCPU負荷が高くなる可能性があります。クラスタにTiDBインスタンスが多数存在し、リージョン情報へのリクエストが同時に多数発生すると、PDリーダーのCPU負荷はさらに高まり、PDサービスが利用できなくなる恐れがあります。 + リージョン数の多いTiDBクラスターでは、ハートビート処理やタスクスケジューリングに伴うオーバーヘッドが増加するため、PDリーダーのCPU負荷が高くなる可能性があります。クラスターにTiDBインスタンスが多数存在し、リージョン情報へのリクエストが同時に多数発生すると、PDリーダーのCPU負荷はさらに高まり、PDサービスが利用できなくなる恐れがあります。 高可用性を確保するため、TiDB v7.6.0 では、PD のリージョン情報クエリ サービスの拡張性を向上させる実験的機能として Active PD Followerが導入されました。v8.5.0 では、この機能が一般提供 (GA) になります。Active PD Follower機能を有効にするには、システム変数[`pd_enable_follower_handle_region`](/system-variables.md#pd_enable_follower_handle_region-new-in-v760) `ON`に設定します。この機能が有効になると、TiDB はリージョン情報要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるようになるため、PD リーダーの CPU 負荷が軽減されます。 @@ -41,11 +41,11 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 ### パフォーマンス {#performance} -- TiDBの高速テーブル作成機能が一般提供開始（GA）となり、データ移行とクラスタ初期化時間を大幅に短縮 [#50052](https://github.com/pingcap/tidb/issues/50052) @[D3Hunter](https://github.com/D3Hunter)@[gmhdbjd](https://github.com/gmhdbjd) +- TiDBの高速テーブル作成機能が一般提供開始（GA）となり、データ移行とクラスター初期化時間を大幅に短縮 [#50052](https://github.com/pingcap/tidb/issues/50052) @[D3Hunter](https://github.com/D3Hunter)@[gmhdbjd](https://github.com/gmhdbjd) TiDB v7.6.0 では、システム変数[`tidb_ddl_version`](https://docs-archive.pingcap.com/tidb/v7.6/system-variables/#tidb_ddl_version-new-in-v760)によって制御される、高速テーブル作成機能が実験的機能として導入されました。v8.0.0 以降、このシステム変数は[`tidb_enable_fast_create_table`](/system-variables.md#tidb_enable_fast_create_table-new-in-v800)に名称変更されました。 - バージョン8.5.0では、TiDBの高速テーブル作成機能が一般提供（GA）となり、デフォルトで有効になっています。データ移行やクラスタ初期化の際に、この機能は数百万ものテーブルを迅速に作成できるため、操作時間を大幅に短縮できます。 + バージョン8.5.0では、TiDBの高速テーブル作成機能が一般提供（GA）となり、デフォルトで有効になっています。データ移行やクラスター初期化の際に、この機能は数百万ものテーブルを迅速に作成できるため、操作時間を大幅に短縮できます。 詳細については、[ドキュメント](/accelerated-table-creation.md)を参照してください。 @@ -53,7 +53,7 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 レコードが頻繁に更新される場合、または TiDB が履歴バージョンを長期間 (例えば 24 時間) 保持する必要がある場合、MVCC バージョンの蓄積によりスキャン パフォーマンスが低下する可能性があります。TiKV の MVCC インメモリ エンジンは、最新の MVCC バージョンをメモリにキャッシュし、高速な GC メカニズムを使用して履歴バージョンをメモリから削除することで、スキャン パフォーマンスを向上させます。 - バージョン8.5.0以降、TiKVはMVCCインメモリエンジンを導入しました。TiKVクラスタ内でMVCCバージョンが蓄積され、スキャンパフォーマンスが低下する場合は、TiKV構成パラメータ[`in-memory-engine.enable`](/tikv-in-memory-engine.md#usage)を設定することで、TiKV MVCCインメモリエンジンを有効にしてスキャンパフォーマンスを向上させることができます。 + バージョン8.5.0以降、TiKVはMVCCインメモリエンジンを導入しました。TiKVクラスター内でMVCCバージョンが蓄積され、スキャンパフォーマンスが低下する場合は、TiKV構成パラメータ[`in-memory-engine.enable`](/tikv-in-memory-engine.md#usage)を設定することで、TiKV MVCCインメモリエンジンを有効にしてスキャンパフォーマンスを向上させることができます。 詳細については、[ドキュメント](/tikv-in-memory-engine.md)を参照してください。 @@ -127,16 +127,16 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 | [`tidb_enable_fast_create_table`](/system-variables.md#tidb_enable_fast_create_table-new-in-v800) | 修正済み | さらにテストを行った後、デフォルト値を`OFF`から`ON`に変更します。これは、[テーブル作成の高速化](/accelerated-table-creation.md)機能がデフォルトで有効になることを意味します。 | | [`tidb_ddl_reorg_max_write_speed`](/system-variables.md#tidb_ddl_reorg_max_write_speed-new-in-v6512-v755-and-v850) | 新しく追加された | 各 TiKV ノードの書き込み帯域幅を制限し、インデックス作成の高速化が有効になっている場合（ [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)変数で制御）にのみ有効になります。たとえば、この変数を`200MiB`に設定すると、最大書き込み速度が 200 MiB/s に制限されます。 | -### コンフィグレーションパラメータ {#configuration-parameters} +### 設定パラメータ {#configuration-parameters} -| コンフィグレーションファイルまたはコンポーネント | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイルまたはコンポーネント | 設定パラメータ | 種類を変更する | 説明 | | ------------------------ | ----------------------------------------------------------------------------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`deprecate-integer-display-length`](/tidb-configuration-file.md#deprecate-integer-display-length) | 修正済み | バージョン8.5.0以降、整数表示幅機能は非推奨となりました。この設定項目のデフォルト値は`false`から`true`に変更されました。 | -| ティクヴ | [`raft-client-queue-size`](/tikv-configuration-file.md#raft-client-queue-size) | 修正済み | デフォルト値を`8192`から`16384`に変更します。 | -| ティクヴ | [`in-memory-engine.capacity`](/tikv-configuration-file.md#capacity-new-in-v850) | 新しく追加された | TiKV MVCC インメモリ エンジンが使用できる最大メモリサイズを制御します。デフォルト値は`min(the system memory * 10%, 5 GiB)`です。 | -| ティクヴ | [`in-memory-engine.enable`](/tikv-configuration-file.md#enable-new-in-v850) | 新しく追加された | TiKV MVCCのインメモリエンジンを有効にして、マルチバージョンクエリを高速化するかどうかを制御します。デフォルト値は`false`で、これはインメモリエンジンが無効になっていることを意味します。 | -| ティクヴ | [`in-memory-engine.gc-run-interval`](/tikv-configuration-file.md#gc-run-interval-new-in-v850) | 新しく追加された | インメモリ エンジンがキャッシュされた MVCC バージョンに対してガベージコレクション(GC) を実行する時間間隔を制御します。デフォルト値は`"3m"`です。 | -| ティクヴ | [`in-memory-engine.mvcc-amplification-threshold`](/tikv-configuration-file.md#mvcc-amplification-threshold-new-in-v850) | 新しく追加された | インメモリエンジンがリージョンを選択してロードする際の、MVCC読み取り増幅のしきい値を制御します。デフォルト値は`10`で、リージョン内の1行を読み取るのに10を超えるMVCCバージョンを処理する必要がある場合は、そのリージョンがインメモリエンジンにロードされる可能性があることを示します。 | +| TiKV | [`raft-client-queue-size`](/tikv-configuration-file.md#raft-client-queue-size) | 修正済み | デフォルト値を`8192`から`16384`に変更します。 | +| TiKV | [`in-memory-engine.capacity`](/tikv-configuration-file.md#capacity-new-in-v850) | 新しく追加された | TiKV MVCC インメモリ エンジンが使用できる最大メモリサイズを制御します。デフォルト値は`min(the system memory * 10%, 5 GiB)`です。 | +| TiKV | [`in-memory-engine.enable`](/tikv-configuration-file.md#enable-new-in-v850) | 新しく追加された | TiKV MVCCのインメモリエンジンを有効にして、マルチバージョンクエリを高速化するかどうかを制御します。デフォルト値は`false`で、これはインメモリエンジンが無効になっていることを意味します。 | +| TiKV | [`in-memory-engine.gc-run-interval`](/tikv-configuration-file.md#gc-run-interval-new-in-v850) | 新しく追加された | インメモリ エンジンがキャッシュされた MVCC バージョンに対してガベージコレクション(GC) を実行する時間間隔を制御します。デフォルト値は`"3m"`です。 | +| TiKV | [`in-memory-engine.mvcc-amplification-threshold`](/tikv-configuration-file.md#mvcc-amplification-threshold-new-in-v850) | 新しく追加された | インメモリエンジンがリージョンを選択してロードする際の、MVCC読み取り増幅のしきい値を制御します。デフォルト値は`10`で、リージョン内の1行を読み取るのに10を超えるMVCCバージョンを処理する必要がある場合は、そのリージョンがインメモリエンジンにロードされる可能性があることを示します。 | | PD | [`patrol-region-worker-count`](/pd-configuration-file.md#patrol-region-worker-count-new-in-v850) | 新しく追加された | リージョンの健全性状態を検査する際にチェッカーによって作成される同時[オペレーター](/glossary.md#operator)の数を制御します。 | | BR | [`--checksum`](/br/br-snapshot-manual.md) | 修正済み | デフォルト値を`true`から`false`に変更します。これは、デフォルトではBR がフルバックアップ中にテーブルレベルのチェックサムを計算しないことを意味し、バックアップのパフォーマンスを向上させます。 | @@ -144,14 +144,14 @@ TiDB 8.5.0は長期サポートリリース（LTS）です。 TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 -- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 および v8.5.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスタを v8.4.0 または v8.5.0 にアップグレードすると、クラスタが利用できなくなるリスクがあります。CentOS Linux 7 を引き続き使用しているユーザーを支援するため、TiDB v8.5.1 では CentOS Linux 7 のテストを再開し、互換性を持たせています。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 -- [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB はバージョン 8.4.0 以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスタをバージョン 8.4.0 以降にアップグレードすると、クラスタが利用できなくなります。 +- [CentOS Linux サポート終了](https://www.centos.org/centos-linux-eol/)CentOS Linux 7 のアップストリームサポートは 2024 年 6 月 30 日に終了しました。そのため、TiDB は v8.4.0 および v8.5.0 で CentOS 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。CentOS 7 上の TiDB クラスターを v8.4.0 または v8.5.0 にアップグレードすると、クラスターが利用できなくなるリスクがあります。CentOS Linux 7 を引き続き使用しているユーザーを支援するため、TiDB v8.5.1 では CentOS Linux 7 のテストを再開し、互換性を持たせています。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 +- [Red Hat Enterprise Linux ライフサイクル](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates)によると、Red Hat Enterprise Linux 7 のメンテナンスサポートは 2024 年 6 月 30 日に終了しました。TiDB はバージョン 8.4.0 以降、Red Hat Enterprise Linux 7 のサポートを終了します。Rocky Linux 9.1 以降のバージョンを使用することをお勧めします。Red Hat Enterprise Linux 7 上の TiDB クラスターをバージョン 8.4.0 以降にアップグレードすると、クラスターが利用できなくなります。 ## 削除された機能 {#removed-features} - 以下の機能が削除されました。 - - バージョン 8.4.0 では、 [TiDBBinlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)は削除されました。バージョン 8.3.0 以降、TiDB Binlog は完全に非推奨となっています。増分データレプリケーションには、代わりに[TiCDC](/ticdc/ticdc-overview.md)を使用してください。ポイントインタイムリカバリ(PITR) には、 [PITR](/br/br-pitr-guide.md)を使用してください。TiDB クラスタをバージョン 8.4.0 以降にアップグレードする前に、必ず TiCDC と PITR に切り替えてください。 + - バージョン 8.4.0 では、 [TiDBBinlog](https://docs-archive.pingcap.com/tidb/v8.3/tidb-binlog-overview/)は削除されました。バージョン 8.3.0 以降、TiDB Binlog は完全に非推奨となっています。増分データレプリケーションには、代わりに[TiCDC](/ticdc/ticdc-overview.md)を使用してください。ポイントインタイムリカバリ(PITR) には、 [PITR](/br/br-pitr-guide.md)を使用してください。TiDB クラスターをバージョン 8.4.0 以降にアップグレードする前に、必ず TiCDC と PITR に切り替えてください。 - 今後のバージョンでは、以下の機能が削除される予定です。 @@ -186,7 +186,7 @@ TiDB をアップグレードする前に、オペレーティング システ - 統計情報の同期読み込みに必要なデータ量を最適化して読み込みパフォーマンスを向上させる [#56812](https://github.com/pingcap/tidb/issues/56812) @[winoros](https://github.com/winoros) - `OUTER JOIN`に一意インデックスと`ORDER BY ... LIMIT`句が含まれる特定のケースで実行プランを最適化し、実行効率を向上させます [#56321](https://github.com/pingcap/tidb/issues/56321) @[winoros](https://github.com/winoros) -- ティクヴ +- TiKV - レプリカのクリーンアップには別のスレッドを使用し、 Raft の読み取りと書き込みの重要なパスのレイテンシーを安定させる [#16001](https://github.com/tikv/tikv/issues/16001) @[hbisheng](https://github.com/hbisheng) - SIMD [#17290](https://github.com/tikv/tikv/issues/17290) @[EricZequan](https://github.com/EricZequan)をサポートすることで、ベクトル距離関数のパフォーマンスを向上させます。 @@ -213,11 +213,11 @@ TiDB をアップグレードする前に、オペレーティング システ - 暗号化キー`--crypter.key`のエラー メッセージを最適化 [#56388](https://github.com/pingcap/tidb/issues/56388) @[Tristan1900](https://github.com/Tristan1900) - データベース作成時のBRにおける同時実行数を増やし、データ復元パフォーマンスを向上させる [#56866](https://github.com/pingcap/tidb/issues/56866) @[Leavrth](https://github.com/Leavrth) - フルバックアップ中にテーブルレベルのチェックサム計算をデフォルトで無効にする（ `--checksum=false` ）バックアップパフォーマンスを向上させる [#56373](https://github.com/pingcap/tidb/issues/56373) @[Tristan1900](https://github.com/Tristan1900) - - 各storageノードの接続タイムアウトを個別に追跡およびリセットするメカニズムを追加して、低速ノードの処理を強化し、バックアップ操作のハングを防止します [#57666](https://github.com/pingcap/tidb/issues/57666) @[3pointer](https://github.com/3pointer)シュート + - 各ストレージノードの接続タイムアウトを個別に追跡およびリセットするメカニズムを追加して、低速ノードの処理を強化し、バックアップ操作のハングを防止します [#57666](https://github.com/pingcap/tidb/issues/57666) @[3pointer](https://github.com/3pointer)シュート - TiDBデータ移行（DM） - - DMクラスタ起動時にDMワーカーがDMマスターに接続するための再試行を追加 [#4287](https://github.com/pingcap/tiflow/issues/4287) @[GMHDBJD](https://github.com/GMHDBJD) + - DMクラスター起動時にDMワーカーがDMマスターに接続するための再試行を追加 [#4287](https://github.com/pingcap/tiflow/issues/4287) @[GMHDBJD](https://github.com/GMHDBJD) ## バグ修正 {#bug-fixes} @@ -228,11 +228,11 @@ TiDB をアップグレードする前に、オペレーティング システ - TTLタスクをキャンセルした際に、対応するSQLが強制終了されない問題を修正しました [#56511](https://github.com/pingcap/tidb/issues/56511) @[lcwangchao](https://github.com/lcwangchao) - v6.5からv7.5以降にアップグレードしたクラスターで、既存のTTLタスクが予期せず頻繁に実行される問題を修正します [#56539](https://github.com/pingcap/tidb/issues/56539) @[lcwangchao](https://github.com/lcwangchao) - `INSERT ... ON DUPLICATE KEY`ステートメントが`mysql_insert_id`と互換性がない問題を修正 [#55965](https://github.com/pingcap/tidb/issues/55965) @[tiancaiamao](https://github.com/tiancaiamao) - - TiKVをstorageエンジンとして選択しない場合、TTLが失敗する可能性がある問題を修正 [#56402](https://github.com/pingcap/tidb/issues/56402) @[YangKeao](https://github.com/YangKeao) + - TiKVをストレージエンジンとして選択しない場合、TTLが失敗する可能性がある問題を修正 [#56402](https://github.com/pingcap/tidb/issues/56402) @[YangKeao](https://github.com/YangKeao) - `AUTO_INCREMENT`ステートメントを使用してデータをインポートした後、 `IMPORT INTO`フィールドが正しく設定されない問題を修正します [#56476](https://github.com/pingcap/tidb/issues/56476) @[D3Hunter](https://github.com/D3Hunter) - TiDBが`ADD INDEX`を実行する際にインデックス長の制限をチェックしない問題を修正しました。 [#56930](https://github.com/pingcap/tidb/issues/56930) @[fzzf678](https://github.com/fzzf678) - `RECOVER TABLE BY JOB JOB_ID;`を実行すると TiDB がpanicを起こす可能性がある問題を修正しました [#55113](https://github.com/pingcap/tidb/issues/55113) @[crazycs520](https://github.com/crazycs520) - - 古い読み取りが読み取り操作のタイムスタンプを厳密に検証しないため、TSOと実際の物理時間の間にオフセットが存在する場合にトランザクションの一貫性に影響を与える可能性がわずかにある問題を修正しました [#56809](https://github.com/pingcap/tidb/issues/56809) @[MyonKeminta](https://github.com/MyonKeminta) + - ステイル読み取りが読み取り操作のタイムスタンプを厳密に検証しないため、TSOと実際の物理時間の間にオフセットが存在する場合にトランザクションの一貫性に影響を与える可能性がわずかにある問題を修正しました [#56809](https://github.com/pingcap/tidb/issues/56809) @[MyonKeminta](https://github.com/MyonKeminta) - DDLオーナーノードが切り替わった後、TiDBが以前の進行状況からReorg DDLタスクを再開できない問題を修正 [#56506](https://github.com/pingcap/tidb/issues/56506) @[tangenta](https://github.com/tangenta) - 分散実行フレームワーク (DXF) の監視パネルの一部のメトリックが不正確である問題を修正します[#57172](https://github.com/pingcap/tidb/issues/57172) @[fzzf678](https://github.com/fzzf678) [#56942](https://github.com/pingcap/tidb/issues/56942) @[fzzf678](https://github.com/fzzf678) - `REORGANIZE PARTITION`が特定の場合にエラー理由を返さない問題を修正 [#56634](https://github.com/pingcap/tidb/issues/56634) @[mjonss](https://github.com/mjonss) @@ -272,9 +272,9 @@ TiDB をアップグレードする前に、オペレーティング システ - 複数テーブルの`DELETE`ステートメントに対して、エイリアスを使用した実行プランバインディングを作成できない問題を修正 [#56726](https://github.com/pingcap/tidb/issues/56726) @[hawkingrei](https://github.com/hawkingrei) - オプティマイザが複雑な述語を簡略化する際に文字セットと照合順序を考慮しないため、実行エラーが発生する可能性がある問題を修正しました [#56479](https://github.com/pingcap/tidb/issues/56479) @[dash12653](https://github.com/dash12653) - Grafana の**Stats Healthy Distribution**パネルのデータが正しくない可能性がある問題を修正 [#57176](https://github.com/pingcap/tidb/issues/57176) @[hawkingrei](https://github.com/hawkingrei) - - クラスタ化インデックスを持つテーブルをクエリする際に、ベクトル検索が誤った結果を返す可能性がある問題を修正 [#57627](https://github.com/pingcap/tidb/issues/57627) @[winoros](https://github.com/winoros) + - クラスター化インデックスを持つテーブルをクエリする際に、ベクトル検索が誤った結果を返す可能性がある問題を修正 [#57627](https://github.com/pingcap/tidb/issues/57627) @[winoros](https://github.com/winoros) -- ティクヴ +- TiKV - Raft EngineのMemTable内の古いインデックスに読み取りスレッドがアクセスした際に発生するpanic問題を修正しました [#17383](https://github.com/tikv/tikv/issues/17383) @[LykxSassinator](https://github.com/LykxSassinator) - 多数のトランザクションが同じキーのロック解除をキューイングしており、キーが頻繁に更新される場合、デッドロック検出に過度の負荷がかかり、TiKV OOM の問題が発生する可能性がある問題を修正しました [#17394](https://github.com/tikv/tikv/issues/17394) @[MyonKeminta](https://github.com/MyonKeminta) @@ -297,7 +297,7 @@ TiDB をアップグレードする前に、オペレーティング システ - TiFlash - `SUBSTRING()`関数が特定の整数型に対して`pos`および`len`引数をサポートしていないためクエリエラーが発生する問題を修正しました [#9473](https://github.com/pingcap/tiflash/issues/9473) @[gengliqi](https://github.com/gengliqi) - - 分散storageおよびコンピューティングアーキテクチャにおいて、 TiFlash書き込みノードをスケールアウトした後にベクトル検索のパフォーマンスが低下する可能性がある問題を修正します [#9637](https://github.com/pingcap/tiflash/issues/9637) @[kolafish](https://github.com/kolafish) + - 分散ストレージおよびコンピューティングアーキテクチャにおいて、 TiFlash書き込みノードをスケールアウトした後にベクトル検索のパフォーマンスが低下する可能性がある問題を修正します [#9637](https://github.com/pingcap/tiflash/issues/9637) @[kolafish](https://github.com/kolafish) - `SUBSTRING()`関数が、2 番目のパラメータが負の場合に誤った結果を返す問題を修正しました [#9604](https://github.com/pingcap/tiflash/issues/9604) @[guo-shaoge](https://github.com/guo-shaoge) - `REPLACE()`関数が最初のパラメータが定数の場合にエラーを返す問題を修正 [#9522](https://github.com/pingcap/tiflash/issues/9522) @[guo-shaoge](https://github.com/guo-shaoge) - `LPAD()`および`RPAD()`関数が場合によっては誤った結果を返す問題を修正 [#9465](https://github.com/pingcap/tiflash/issues/9465) @[guo-shaoge](https://github.com/guo-shaoge) @@ -314,7 +314,7 @@ TiDB をアップグレードする前に、オペレーティング システ - `k8s.io/api`ライブラリ バージョン [#57790](https://github.com/pingcap/tidb/issues/57790) @[BornChanger](https://github.com/BornChanger)をアップグレードして、潜在的なセキュリティ脆弱性を修正します - クラスター内に多数のテーブルが存在するが実際のデータサイズが小さい場合に、PITRタスクが`Information schema is out of date`エラーを返す可能性がある問題を修正します。 [#57743](https://github.com/pingcap/tidb/issues/57743) @[Tristan1900](https://github.com/Tristan1900) - アドバンスダー所有者が切り替わるとログバックアップが予期せず一時停止状態になることがある問題を修正 [#58031](https://github.com/pingcap/tidb/issues/58031) @[3pointer](https://github.com/3pointer) - - `tiup br restore`コマンドがデータベースまたはテーブルの復元時にターゲットクラスタテーブルが既に存在するかどうかのチェックを省略し、既存のテーブルを上書きする可能性がある問題を修正しました [#58168](https://github.com/pingcap/tidb/issues/58168) @[RidRisR](https://github.com/RidRisR) + - `tiup br restore`コマンドがデータベースまたはテーブルの復元時にターゲットクラスターテーブルが既に存在するかどうかのチェックを省略し、既存のテーブルを上書きする可能性がある問題を修正しました [#58168](https://github.com/pingcap/tidb/issues/58168) @[RidRisR](https://github.com/RidRisR) - TiCDC diff --git a/releases/release-8.5.1.md b/releases/release-8.5.1.md index d5a0fcae27527..b33d61b0da494 100644 --- a/releases/release-8.5.1.md +++ b/releases/release-8.5.1.md @@ -13,7 +13,7 @@ TiDBバージョン：8.5.1 ## オペレーティングシステムとプラットフォームの要件変更 {#operating-system-and-platform-requirement-changes} -バージョン8.5.1以降、TiDBはCentOS Linux 7のテストを再開し、互換性を確保しています。TiDB v8.5をデプロイする場合、またはクラスタをv8.5にアップグレードする場合は、TiDB v8.5.1以降のバージョンを使用してください。 +バージョン8.5.1以降、TiDBはCentOS Linux 7のテストを再開し、互換性を確保しています。TiDB v8.5をデプロイする場合、またはクラスターをv8.5にアップグレードする場合は、TiDB v8.5.1以降のバージョンを使用してください。 - TiDB v8.4.0 DMR および v8.5.0 リリースは[2024年6月30日をもってサポート終了となります。](https://www.redhat.com/en/topics/linux/centos-linux-eol) CentOS 7 上の TiDB クラスターを v8.4.0 または v8.5.0 にアップグレードすると、クラスターが使用できなくなるリスクが発生します。 @@ -37,13 +37,13 @@ CentOS Linux 7はサポート終了（EOL）を迎えたため、今後のTiDB - 統計メモリキャッシュのデフォルトしきい値を総メモリの20%に調整 [#58014](https://github.com/pingcap/tidb/issues/58014) @[hawkingrei](https://github.com/hawkingrei) - タイムスタンプの有効性チェックを強化 [#57786](https://github.com/pingcap/tidb/issues/57786) @[MyonKeminta](https://github.com/MyonKeminta) -- ティクヴ +- TiKV - 無効な`max_ts`更新の検出メカニズムを追加 [#17916](https://github.com/tikv/tikv/issues/17916) @[ekexium](https://github.com/ekexium) - TiFlash - - 分散型storageおよびコンピューティングアーキテクチャにおけるTiFlashコンピューティングノードの再試行戦略を最適化し、Amazon S3からのファイルダウンロード時に発生する例外を処理する [#9695](https://github.com/pingcap/tiflash/issues/9695) @[JinheLin](https://github.com/JinheLin) + - 分散型ストレージおよびコンピューティングアーキテクチャにおけるTiFlashコンピューティングノードの再試行戦略を最適化し、Amazon S3からのファイルダウンロード時に発生する例外を処理する [#9695](https://github.com/pingcap/tiflash/issues/9695) @[JinheLin](https://github.com/JinheLin) - ツール @@ -79,7 +79,7 @@ CentOS Linux 7はサポート終了（EOL）を迎えたため、今後のTiDB - `REORGANIZE PARTITION`のデータバックフィル中に同時更新がロールバックされる可能性がある問題を修正 [#58226](https://github.com/pingcap/tidb/issues/58226) @[mjonss](https://github.com/mjonss) - `ORDER BY`をクエリする際に`cluster_slow_query table`を使用すると、結果が順不同になる可能性がある問題を修正しました [#51723](https://github.com/pingcap/tidb/issues/51723) @[Defined2014](https://github.com/Defined2014) -- ティクヴ +- TiKV - GBK/GB18030でエンコードされたデータを処理する際にエンコードが失敗する可能性がある問題を修正しました [#17618](https://github.com/tikv/tikv/issues/17618) @[CbcWestwolf](https://github.com/CbcWestwolf) - TiKV MVCC In-Memory Engine (IME) がレプリカをプリロードするときに初期化されていないレプリカが原因で TiKV パニックが発生する問題を修正 [#18046](https://github.com/tikv/tikv/issues/18046) @[overvenus](https://github.com/overvenus) @@ -93,7 +93,7 @@ CentOS Linux 7はサポート終了（EOL）を迎えたため、今後のTiDB - TiFlash - - 分散storageおよびコンピューティングアーキテクチャにおいて、新しい列をクエリすると誤った結果が返される可能性がある問題を修正しました [#9665](https://github.com/pingcap/tiflash/issues/9665) @[zimulala](https://github.com/zimulala) + - 分散ストレージおよびコンピューティングアーキテクチャにおいて、新しい列をクエリすると誤った結果が返される可能性がある問題を修正しました [#9665](https://github.com/pingcap/tiflash/issues/9665) @[zimulala](https://github.com/zimulala) - メモリ使用量が低い場合、 TiFlash がRaftメッセージの処理を予期せず拒否する可能性がある問題を修正 [#9745](https://github.com/pingcap/tiflash/issues/9745) @[CalvinNeo](https://github.com/CalvinNeo) - TiFlashの`POSITION()`関数が文字セット照合をサポートしていない問題を修正 [#9377](https://github.com/pingcap/tiflash/issues/9377) @[xzhangxian1008](https://github.com/xzhangxian1008) diff --git a/releases/release-8.5.2.md b/releases/release-8.5.2.md index bc4444a62b78f..c9641373bcb41 100644 --- a/releases/release-8.5.2.md +++ b/releases/release-8.5.2.md @@ -17,7 +17,7 @@ TiDBバージョン：8.5.2 - TTLテーブルおよび関連する統計収集タスクのGC実行をオーナーノードに限定することで、オーバーヘッドを削減します [#59357](https://github.com/pingcap/tidb/issues/59357) @[lcwangchao](https://github.com/lcwangchao) -- ティクヴ +- TiKV - `import.num-threads`設定項目を動的に変更するサポート [#17807](https://github.com/tikv/tikv/issues/17807) @[RidRisR](https://github.com/RidRisR) @@ -43,7 +43,7 @@ TiDBバージョン：8.5.2 - 同じ名前のビューを2つ作成してもエラーが報告されない問題を修正 [#58769](https://github.com/pingcap/tidb/issues/58769) @[tiancaiamao](https://github.com/tiancaiamao) - TiFlashの Join における等価条件の両側のデータ型が異なると、誤った結果が生じる可能性がある問題を修正しました [#59877](https://github.com/pingcap/tidb/issues/59877) @[yibin87](https://github.com/yibin87) - ハッシュパーティションテーブルで`is null`条件を含むクエリがpanicを引き起こす問題を修正 [#58374](https://github.com/pingcap/tidb/issues/58374) @[Defined2014](https://github.com/Defined2014) - - 分散storageおよびコンピューティングアーキテクチャのTiFlashノードを含むクラスタで`ALTER TABLE ... PLACEMENT POLICY ...`を実行した後、リージョンピアが誤ってTiFlash Compute ノードに追加される可能性がある問題を修正しました [#58633](https://github.com/pingcap/tidb/issues/58633) @[JaySon-Huang](https://github.com/JaySon-Huang) + - 分散ストレージおよびコンピューティングアーキテクチャのTiFlashノードを含むクラスターで`ALTER TABLE ... PLACEMENT POLICY ...`を実行した後、リージョンピアが誤ってTiFlash Compute ノードに追加される可能性がある問題を修正しました [#58633](https://github.com/pingcap/tidb/issues/58633) @[JaySon-Huang](https://github.com/JaySon-Huang) - 統計ファイルにnull値が含まれている場合、統計の手動読み込みに失敗することがある問題を修正 [#53966](https://github.com/pingcap/tidb/issues/53966) @[King-Dylan](https://github.com/King-Dylan) - TTLジョブが無視されたり、複数回処理されたりする問題を修正 [#59347](https://github.com/pingcap/tidb/issues/59347) @[YangKeao](https://github.com/YangKeao) - 交換パーティションでの誤った判断により実行が失敗する問題を修正 [#59534](https://github.com/pingcap/tidb/issues/59534) @[mjonss](https://github.com/mjonss) @@ -63,13 +63,13 @@ TiDBバージョン：8.5.2 - インデックス作成中にPDLeaderの強制終了エラーを注入するとデータ不整合が発生する可能性がある問題を修正 [#59701](https://github.com/pingcap/tidb/issues/59701) @[tangenta](https://github.com/tangenta) - TiDBが約650万個のテーブルを作成した後にメモリ不足（OOM）になる問題を修正 [#58368](https://github.com/pingcap/tidb/issues/58368) @[lance6716](https://github.com/lance6716) - グローバルソート機能を有効にして大量のデータをインポートする際に、一意キーの追加が失敗する可能性がある問題を修正しました [#59725](https://github.com/pingcap/tidb/issues/59725) @[CbcWestwolf](https://github.com/CbcWestwolf) - - TiDBがS3外部storageへのアクセスに失敗した後に判読不能なエラーメッセージを返す問題を修正 [#59326](https://github.com/pingcap/tidb/issues/59326) @[lance6716](https://github.com/lance6716) + - TiDBがS3外部ストレージへのアクセスに失敗した後に判読不能なエラーメッセージを返す問題を修正 [#59326](https://github.com/pingcap/tidb/issues/59326) @[lance6716](https://github.com/lance6716) - `information_schema.tables`をクエリすると、 `table_schema`と`table_name`の値が一致しない問題を修正 [#60593](https://github.com/pingcap/tidb/issues/60593) @[tangenta](https://github.com/tangenta) - 内部SQLコミットが失敗した場合にDDL通知機能が誤った通知を送信する可能性がある問題を修正しました [#59055](https://github.com/pingcap/tidb/issues/59055) @[lance6716](https://github.com/lance6716) - `ADD INDEX` DDL 操作で、リージョンサイズが 256 MiB であるにもかかわらず、グローバルソート機能が有効になっている場合に SST ファイルが 96 MiB ずつ分割される問題を修正します。 [#59962](https://github.com/pingcap/tidb/issues/59962) @[D3Hunter](https://github.com/D3Hunter) - グローバルソート機能を有効にした状態でデータインポート中にメモリ使用率が80%を超えるとTiDBサーバーがメモリ不足（OOM）になる問題を修正 [#59508](https://github.com/pingcap/tidb/issues/59508) @[D3Hunter](https://github.com/D3Hunter) -- ティクヴ +- TiKV - `txn_status_cache` [#18384](https://github.com/tikv/tikv/issues/18384)でデッドロックが発生する可能性がある問題を修正しました @[ekexium](https://github.com/ekexium) - Resolved-TS の監視とログが異常になる可能性がある問題を修正 [#17989](https://github.com/tikv/tikv/issues/17989) @[ekexium](https://github.com/ekexium) @@ -102,7 +102,7 @@ TiDBバージョン：8.5.2 - ソート中にデータが流出してTiFlashがクラッシュする可能性がある問題を修正 [#9999](https://github.com/pingcap/tiflash/issues/9999) @[windtalker](https://github.com/windtalker) - TiFlashが`Exception: Block schema mismatch`を含むSQL文を実行する際に`GROUP BY ... WITH ROLLUP`エラーを返す可能性がある問題を修正しました。 [#10110](https://github.com/pingcap/tiflash/issues/10110) @[gengliqi](https://github.com/gengliqi) - - 分散storageとコンピューティングアーキテクチャで、 TiFlashコンピューティング ノードがリージョンピアを追加するターゲット ノードとして誤って選択される可能性がある問題を修正 [#9750](https://github.com/pingcap/tiflash/issues/9750) @[JaySon-Huang](https://github.com/JaySon-Huang) + - 分散ストレージとコンピューティングアーキテクチャで、 TiFlashコンピューティング ノードがリージョンピアを追加するターゲット ノードとして誤って選択される可能性がある問題を修正 [#9750](https://github.com/pingcap/tiflash/issues/9750) @[JaySon-Huang](https://github.com/JaySon-Huang) - 特定の状況でTiFlash が予期せず終了した場合に、エラー スタック トレースの出力に失敗することがある問題を修正 [#9902](https://github.com/pingcap/tiflash/issues/9902) @[JaySon-Huang](https://github.com/JaySon-Huang) - 大量のデータをインポートした後にTiFlash が高いメモリ使用量を維持する可能性がある問題を修正 [#9812](https://github.com/pingcap/tiflash/issues/9812) @[CalvinNeo](https://github.com/CalvinNeo) - `profiles.default.init_thread_count_scale`が`0`に設定されている場合、 TiFlash の起動がブロックされる場合がある問題を修正 [#9906](https://github.com/pingcap/tiflash/issues/9906) @[JaySon-Huang](https://github.com/JaySon-Huang) @@ -112,9 +112,9 @@ TiDBバージョン：8.5.2 - 16 MiB を超えるデータを 1 行挿入するとTiFlash が再起動に失敗することがある問題を修正 [#10052](https://github.com/pingcap/tiflash/issues/10052) @[JaySon-Huang](https://github.com/JaySon-Huang) - ベクター インデックスを持つテーブルに新しいデータが挿入された後、 TiFlash が一部のディスク データを正しくクリーンアップできず、ディスク容量が異常に消費される問題を修正 [#9946](https://github.com/pingcap/tiflash/issues/9946) @[JaySon-Huang](https://github.com/JaySon-Huang) - TiFlashが同じテーブルに複数のベクターインデックスを作成した後、以前に作成されたベクターインデックスを予期せず削除し、パフォーマンスの低下を引き起こす可能性がある問題を修正しました [#9971](https://github.com/pingcap/tiflash/issues/9971) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - - TiFlashが分散storageおよびコンピューティングアーキテクチャでベクトルインデックスを使用してベクトル検索クエリを高速化できない可能性がある問題を修正 [#9847](https://github.com/pingcap/tiflash/issues/9847) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - - TiFlash が分散storageおよびコンピューティングアーキテクチャで大量の`tag=EnumParseOverflowContainer`ログを出力する可能性がある問題を修正 [#9955](https://github.com/pingcap/tiflash/issues/9955) @[JaySon-Huang](https://github.com/JaySon-Huang) - - `SELECT ... AS OF TIMESTAMP`クエリの実行時にTiFlash が期待どおりにLearnerの読み取りをスキップしない問題を修正 [#10046](https://github.com/pingcap/tiflash/issues/10046) @[CalvinNeo](https://github.com/CalvinNeo) + - TiFlashが分散ストレージおよびコンピューティングアーキテクチャでベクトルインデックスを使用してベクトル検索クエリを高速化できない可能性がある問題を修正 [#9847](https://github.com/pingcap/tiflash/issues/9847) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) + - TiFlash が分散ストレージおよびコンピューティングアーキテクチャで大量の`tag=EnumParseOverflowContainer`ログを出力する可能性がある問題を修正 [#9955](https://github.com/pingcap/tiflash/issues/9955) @[JaySon-Huang](https://github.com/JaySon-Huang) + - `SELECT ... AS OF TIMESTAMP`クエリの実行時にTiFlash が期待どおりにラーナーの読み取りをスキップしない問題を修正 [#10046](https://github.com/pingcap/tiflash/issues/10046) @[CalvinNeo](https://github.com/CalvinNeo) - リージョンのキー範囲が不規則なスナップショットを処理するとTiFlash がpanicになる問題を修正 [#10147](https://github.com/pingcap/tiflash/issues/10147) @[JaySon-Huang](https://github.com/JaySon-Huang) - ツール @@ -143,11 +143,11 @@ TiDBバージョン：8.5.2 - TiDB Lightning - - 高同時実行シナリオでクラウドstorageからデータをインポートする際にパフォーマンスが低下する問題を修正 [#57413](https://github.com/pingcap/tidb/issues/57413) @[xuanyu66](https://github.com/xuanyu66) + - 高同時実行シナリオでクラウドストレージからデータをインポートする際にパフォーマンスが低下する問題を修正 [#57413](https://github.com/pingcap/tidb/issues/57413) @[xuanyu66](https://github.com/xuanyu66) - TiDB Lightningを使用してデータをインポートする際に、エラーレポートの出力が切り詰められる問題を修正しました [#58085](https://github.com/pingcap/tidb/issues/58085) @[lance6716](https://github.com/lance6716) - ログが適切に匿名化されていない問題を修正 [#59086](https://github.com/pingcap/tidb/issues/59086) @[GMHDBJD](https://github.com/GMHDBJD) - - 外部アカウントを使用してGCSstorage操作を実行する際に、認証が`context canceled`エラーで失敗する問題を修正しました [#60155](https://github.com/pingcap/tidb/issues/60155) @[lance6716](https://github.com/lance6716) - - TiDB LightningがクラウドstorageからParquetファイルをTiDBにインポートする際に数時間停止する問題を修正します [#60224](https://github.com/pingcap/tidb/issues/60224) @[joechenrh](https://github.com/joechenrh) + - 外部アカウントを使用してGCSストレージ操作を実行する際に、認証が`context canceled`エラーで失敗する問題を修正しました [#60155](https://github.com/pingcap/tidb/issues/60155) @[lance6716](https://github.com/lance6716) + - TiDB LightningがクラウドストレージからParquetファイルをTiDBにインポートする際に数時間停止する問題を修正します [#60224](https://github.com/pingcap/tidb/issues/60224) @[joechenrh](https://github.com/joechenrh) - TiDB Lightningが大量のデータをインポートする際に、SSTファイルをTiKVクラスターに書き込んだり取り込んだりする際にメモリ不足（OOM）になる可能性がある問題を修正しました。 [#59947](https://github.com/pingcap/tidb/issues/59947) @[OliverS929](https://github.com/OliverS929) - テーブル作成時の最大QPSが低いことと`information_schema.tables`へのアクセスが遅いことが原因で、数百万のテーブルが存在するシナリオでTiDB Lightningがスキーマジョブのディスパッチが遅くなる問題を修正しました [#58141](https://github.com/pingcap/tidb/issues/58141) @[D3Hunter](https://github.com/D3Hunter) diff --git a/releases/release-8.5.3.md b/releases/release-8.5.3.md index 5565ed856c1c2..1d02b82156e56 100644 --- a/releases/release-8.5.3.md +++ b/releases/release-8.5.3.md @@ -33,9 +33,9 @@ TiDBバージョン：8.5.3 - インデックスを使用したグローバルソート時にマージソート段階の監視メトリクスを追加する [#61025](https://github.com/pingcap/tidb/issues/61025) @[fzzf678](https://github.com/fzzf678) - `IndexLookup`オペレーターが`context canceled`エラーに遭遇したときに、冗長なログエントリを削除します [#61072](https://github.com/pingcap/tidb/issues/61072) @[yibin87](https://github.com/yibin87) - `tidb_replica_read`を`closest-adaptive`に設定した場合のパフォーマンスを改善します [#61745](https://github.com/pingcap/tidb/issues/61745) @[you06](https://github.com/you06) - - 大規模クラスタにおける監視メトリクスデータの量を減らすことで運用コストを削減する [#59990](https://github.com/pingcap/tidb/issues/59990) @[zimulala](https://github.com/zimulala) + - 大規模クラスターにおける監視メトリクスデータの量を減らすことで運用コストを削減する [#59990](https://github.com/pingcap/tidb/issues/59990) @[zimulala](https://github.com/zimulala) -- ティクヴ +- TiKV - フォアグラウンド書き込みをブロックせずにSSTファイルを取り込むことをサポートし、レイテンシーの影響を軽減します [#18081](https://github.com/tikv/tikv/issues/18081) @[hhwyt](https://github.com/hhwyt) - フローコントローラによって引き起こされるパフォーマンスのジッターを軽減します [#18625](https://github.com/tikv/tikv/issues/18625) @[hhwyt](https://github.com/hhwyt) @@ -53,7 +53,7 @@ TiDBバージョン：8.5.3 - TiFlash - - storageスナップショット取得時の最大リトライ回数を増やし、大規模テーブルのクエリの安定性を向上 [#10300](https://github.com/pingcap/tiflash/issues/10300) @[JaySon-Huang](https://github.com/JaySon-Huang) + - ストレージスナップショット取得時の最大リトライ回数を増やし、大規模テーブルのクエリの安定性を向上 [#10300](https://github.com/pingcap/tiflash/issues/10300) @[JaySon-Huang](https://github.com/JaySon-Huang) - ワイドテーブルシナリオにおけるTiFlash OOM リスクの可観測性を強化 [#10272](https://github.com/pingcap/tiflash/issues/10272) @[JaySon-Huang](https://github.com/JaySon-Huang) - ツール @@ -100,7 +100,7 @@ TiDBバージョン：8.5.3 - クエリが終了したときに悲観的ロックが残る可能性がある問題を修正 [#61454](https://github.com/pingcap/tidb/issues/61454) @[zyguan](https://github.com/zyguan) - TiDBがPDから単一のリクエストでリージョンを多数ロードしたために大規模なクエリを実行する際にエラーが発生する問題を修正しました [#1704](https://github.com/tikv/client-go/issues/1704) @[you06](https://github.com/you06) -- ティクヴ +- TiKV - TiKV が正常シャットダウン中に進行中の手動圧縮タスクを終了できない問題を修正 [#18396](https://github.com/tikv/tikv/issues/18396) @[LykxSassinator](https://github.com/LykxSassinator) - クラスターのアップグレード後にデフォルトのリージョンサイズが予期せず変更される問題を修正 [#18503](https://github.com/tikv/tikv/issues/18503) @[LykxSassinator](https://github.com/LykxSassinator) @@ -113,7 +113,7 @@ TiDBバージョン：8.5.3 - PD - `recovery-duration`が低速ノード検出メカニズムで有効にならない問題を修正 [#9384](https://github.com/tikv/pd/issues/9384) @[rleungx](https://github.com/rleungx) - - クラスタのアップグレード後に Evict Leaderスケジューラが誤って一時停止される可能性がある問題を修正しました [#9416](https://github.com/tikv/pd/issues/9416) @[rleungx](https://github.com/rleungx) + - クラスターのアップグレード後に Evict Leaderスケジューラが誤って一時停止される可能性がある問題を修正しました [#9416](https://github.com/tikv/pd/issues/9416) @[rleungx](https://github.com/rleungx) - TiDB DashboardのTCP接続を不適切に閉じるとPDゴルーチンリークが発生する問題を修正しました [#9402](https://github.com/tikv/pd/issues/9402) @[baurine](https://github.com/baurine) - 新しく追加された TiKV ノードがスケジュールに失敗する可能性がある問題を修正 [#9145](https://github.com/tikv/pd/issues/9145) @[bufferflies](https://github.com/bufferflies) @@ -127,11 +127,11 @@ TiDBバージョン：8.5.3 - バックアップと復元 (BR) - - ブレークポイントリカバリ中にstorageノードの空き容量が不必要に再チェックされる問題を修正 [#54316](https://github.com/pingcap/tidb/issues/54316) @[Leavrth](https://github.com/Leavrth) - - HTTP/2 GOAWAY エラーが発生した際に、外部storageからのデータインポートが自動的に再試行されない問題を修正 [#60143](https://github.com/pingcap/tidb/issues/60143) @[joechenrh](https://github.com/joechenrh) + - ブレークポイントリカバリ中にストレージノードの空き容量が不必要に再チェックされる問題を修正 [#54316](https://github.com/pingcap/tidb/issues/54316) @[Leavrth](https://github.com/Leavrth) + - HTTP/2 GOAWAY エラーが発生した際に、外部ストレージからのデータインポートが自動的に再試行されない問題を修正 [#60143](https://github.com/pingcap/tidb/issues/60143) @[joechenrh](https://github.com/joechenrh) - インポートモードの切り替えにより復元中に発生する`keepalive watchdog timedout`エラーを修正 [#18541](https://github.com/tikv/tikv/issues/18541) @[Leavrth](https://github.com/Leavrth) - 大量のデータを転送する際に、ログバックアップのAzure Blob Storageへのアップロードが遅くなる問題を修正しました [#18410](https://github.com/tikv/tikv/issues/18410) @[YuJuncen](https://github.com/YuJuncen) - - `-f`でテーブルをフィルタリングする際に、 BRが対応するテーブルがクラスタ内に存在するかどうかをチェックしない問題を修正 [#61592](https://github.com/pingcap/tidb/issues/61592) @[RidRisR](https://github.com/RidRisR) + - `-f`でテーブルをフィルタリングする際に、 BRが対応するテーブルがクラスター内に存在するかどうかをチェックしない問題を修正 [#61592](https://github.com/pingcap/tidb/issues/61592) @[RidRisR](https://github.com/RidRisR) - PITR が 3072 バイトを超えるインデックスの復元に失敗する問題を修正 [#58430](https://github.com/pingcap/tidb/issues/58430) @[YuJuncen](https://github.com/YuJuncen) - RangeTree の結果が完全バックアップ中にメモリを非効率的に消費する問題を修正 [#58587](https://github.com/pingcap/tidb/issues/58587) @[3pointer](https://github.com/3pointer) diff --git a/releases/release-8.5.4.md b/releases/release-8.5.4.md index 88592ad5dddd2..ddfde12a8e4b6 100644 --- a/releases/release-8.5.4.md +++ b/releases/release-8.5.4.md @@ -15,7 +15,7 @@ TiDBバージョン：8.5.4 - 特定のテーブルのデータの再配布をサポート (実験的) [#63260](https://github.com/pingcap/tidb/issues/63260) @[bufferflies](https://github.com/bufferflies) - PDは、クラスタ内のすべてのTiKVノードにデータが可能な限り均等に分散されるように自動的にスケジュールします。ただし、この自動スケジュールはクラスタ全体を対象としています。場合によっては、クラスタ全体のデータ分散がバランスが取れていても、特定のテーブルのデータがTiKVノード間で不均等に分散される可能性があります。 + PDは、クラスター内のすべてのTiKVノードにデータが可能な限り均等に分散されるように自動的にスケジュールします。ただし、この自動スケジュールはクラスター全体を対象としています。場合によっては、クラスター全体のデータ分散がバランスが取れていても、特定のテーブルのデータがTiKVノード間で不均等に分散される可能性があります。 バージョン8.5.4以降では、 [`SHOW TABLE DISTRIBUTION`](https://docs.pingcap.com/tidb/v8.5/sql-statement-show-table-distribution/)ステートメントを使用して、特定のテーブルのデータがすべてのTiKVノードにどのように分散されているかを確認できます。データの分散が不均衡な場合は、 [`DISTRIBUTE TABLE`](https://docs.pingcap.com/tidb/v8.5/sql-statement-distribute-table)ステートメントを使用してテーブルのデータを再分散（実験的）し、負荷分散を改善できます。 @@ -53,7 +53,7 @@ TiDBバージョン：8.5.4 この新しいアーキテクチャは[従来のTiCDCアーキテクチャ](/ticdc/ticdc-classic-architecture.md)アーキテクチャの構成、使用法、API との互換性を維持しながら、TiCDC コア コンポーネントを再設計し、そのデータ処理ワークフローを最適化します。 - この新しいアーキテクチャを使用するように構成すると、TiCDC はほぼ線形のスケーラビリティを実現し、より低いリソース消費で数百万のテーブルを複製できます。また、変更フィードのレイテンシーを削減し、書き込みワークロードが高いシナリオ、頻繁な DDL 操作、クラスタのスケーリングにおいて、より安定したパフォーマンスを提供します。なお、この新しいアーキテクチャには現在、いくつか[初期の制約](https://docs.pingcap.com/tidb/v8.5/ticdc-architecture#limitations)があります。 + この新しいアーキテクチャを使用するように構成すると、TiCDC はほぼ線形のスケーラビリティを実現し、より低いリソース消費で数百万のテーブルを複製できます。また、変更フィードのレイテンシーを削減し、書き込みワークロードが高いシナリオ、頻繁な DDL 操作、クラスターのスケーリングにおいて、より安定したパフォーマンスを提供します。なお、この新しいアーキテクチャには現在、いくつか[初期の制約](https://docs.pingcap.com/tidb/v8.5/ticdc-architecture#limitations)があります。 新しいアーキテクチャを使用するには、TiCDC 構成項目[`newarch`](https://docs.pingcap.com/tidb/v8.5/ticdc-server-config#newarch-new-in-v854-release1) `true`に設定します。 @@ -61,7 +61,7 @@ TiDBバージョン：8.5.4 ## 互換性の変更 {#compatibility-changes} -新規作成されたv8.5.3クラスタは、v8.5.4へスムーズにアップグレードできます。ただし、v8.5.4では、システム変数と構成パラメータの**デフォルト値の変更や動作調整が**いくつか導入されています。アップグレード前に、以下の点にご注意ください。 +新規作成されたv8.5.3クラスターは、v8.5.4へスムーズにアップグレードできます。ただし、v8.5.4では、システム変数と構成パラメータの**デフォルト値の変更や動作調整が**いくつか導入されています。アップグレード前に、以下の点にご注意ください。 - ほとんどの変更は、通常のアップグレードであれば安全です。ただし、クラスターにTiFlashやTiKVの圧縮構成のカスタマイズなど、パフォーマンスチューニングが施されている場合は、このセクションをよくお読みください。 - バージョン8.5.4では、一部の従来のTiKV設定項目が非推奨となり、使用が推奨されなくなりました。代替として、このセクションで説明する新しいTiKV設定グループを使用することをお勧めします。 @@ -76,15 +76,15 @@ TiDBバージョン：8.5.4 | [`tidb_opt_enable_semi_join_rewrite`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_opt_enable_semi_join_rewrite-new-in-v854) | 新しく追加された | `EXISTS`サブクエリを書き換えるかどうかを制御します。デフォルト値は`OFF`です。 [#44850](https://github.com/pingcap/tidb/issues/44850) [@terry1purcell](https://github.com/terry1purcell) | | [`tidb_stats_update_during_ddl`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_stats_update_during_ddl-new-in-v854) | 新しく追加された | [DDLステートメントに埋め込まれた`ANALYZE`](https://docs.pingcap.com/tidb/v8.5/ddl_embedded_analyze) 。デフォルト値は`OFF`です。有効にすると、 `ADD INDEX` DDL ステートメントは実行中に新しいインデックスの統計情報を収集し、オプティマイザがインデックスの追加直後にインデックスを使用できるようにします。この変数を有効にすると、大きなテーブルにインデックスを追加する際の DDL 実行時間が長くなる可能性があることに注意してください。 [#57948](https://github.com/pingcap/tidb/issues/57948) [@terry1purcell](https://github.com/terry1purcell) [@AilinKid](https://github.com/AilinKid) | -### コンフィグレーションパラメータ {#configuration-parameters} +### 設定パラメータ {#configuration-parameters} -| コンフィグレーションファイルまたはコンポーネント | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイルまたはコンポーネント | 設定パラメータ | 種類を変更する | 説明 | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| ティクヴ | [`rocksdb.max-manifest-file-size`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#max-manifest-file-size) | 修正済み | 単一の TiKV ノードに多数の SST ファイルが含まれている場合に、全体的なパフォーマンスに影響を与える可能性のある頻繁なマニフェスト ファイル圧縮を回避するため、デフォルト値を`128MiB` `256MiB`に変更します。 [#18889](https://github.com/tikv/tikv/issues/18889) [@glorv](https://github.com/glorv) | -| ティクヴ | [`server.grpc-raft-conn-num`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#grpc-raft-conn-num) | 修正済み | デフォルト値を`1`から`MAX(1, MIN(4, CPU cores / 8))`に変更します。これにより、gRPC 関連のスレッド設定が CPU コア数に応じて調整されるようになります。CPU コア数が 32 以上の場合、デフォルトの最大接続数は 4 になります。 [#18806](https://github.com/tikv/tikv/issues/18806) [@LykxSassinator](https://github.com/LykxSassinator) | -| ティクヴ | [`server.grpc-concurrency`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#grpc-concurrency) | 修正済み | デフォルト値を`5`から`grpc-raft-conn-num * 3 + 2`に変更します。これにより、gRPC 関連のスレッド設定が CPU コア数に合わせて調整されるようになります。 [#18806](https://github.com/tikv/tikv/issues/18806) [@LykxSassinator](https://github.com/LykxSassinator) | -| ティクヴ |
  • [`region-compact-check-interval`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#region-compact-check-interval)
  • [`region-compact-check-step`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#region-compact-check-step)
  • [`region-compact-min-tombstones`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#region-compact-min-tombstones)
  • [`region-compact-tombstones-percent`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#region-compact-tombstones-percent)
  • [`region-compact-min-redundant-rows`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#region-compact-min-redundant-rows-new-in-v710)
  • [`region-compact-redundant-rows-percent`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#region-compact-redundant-rows-percent-new-in-v710)
    • | 非推奨 | これらの設定項目は、自動圧縮動作を制御する[`gc.auto-compaction`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#gcauto-compaction)設定グループに置き換えられます。 [#18727](https://github.com/tikv/tikv/issues/18727) [@v01dstar](https://github.com/v01dstar) | -| ティクヴ | [`gc.auto-compaction`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#gcauto-compaction)設定グループ:
    • [`gc.auto-compaction.check-interval`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#check-interval-new-in-v757-and-v854)
    • [`gc.auto-compaction.tombstone-num-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#tombstone-num-threshold-new-in-v757-and-v854)
    • [`gc.auto-compaction.tombstone-percent-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#tombstone-percent-threshold-new-in-v757-and-v854)
    • [`gc.auto-compaction.redundant-rows-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#redundant-rows-threshold-new-in-v757-and-v854)
    • [`gc.auto-compaction.redundant-rows-percent-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#redundant-rows-percent-threshold-new-in-v757-and-v854)
    • [`gc.auto-compaction.bottommost-level-force`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#bottommost-level-force-new-in-v757-and-v854)
    | 新しく追加された | この構成グループは、自動圧縮動作を制御します。 [#18727](https://github.com/tikv/tikv/issues/18727) [@v01dstar](https://github.com/v01dstar) | +| TiKV | [`rocksdb.max-manifest-file-size`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#max-manifest-file-size) | 修正済み | 単一の TiKV ノードに多数の SST ファイルが含まれている場合に、全体的なパフォーマンスに影響を与える可能性のある頻繁なマニフェスト ファイル圧縮を回避するため、デフォルト値を`128MiB` `256MiB`に変更します。 [#18889](https://github.com/tikv/tikv/issues/18889) [@glorv](https://github.com/glorv) | +| TiKV | [`server.grpc-raft-conn-num`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#grpc-raft-conn-num) | 修正済み | デフォルト値を`1`から`MAX(1, MIN(4, CPU cores / 8))`に変更します。これにより、gRPC 関連のスレッド設定が CPU コア数に応じて調整されるようになります。CPU コア数が 32 以上の場合、デフォルトの最大接続数は 4 になります。 [#18806](https://github.com/tikv/tikv/issues/18806) [@LykxSassinator](https://github.com/LykxSassinator) | +| TiKV | [`server.grpc-concurrency`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#grpc-concurrency) | 修正済み | デフォルト値を`5`から`grpc-raft-conn-num * 3 + 2`に変更します。これにより、gRPC 関連のスレッド設定が CPU コア数に合わせて調整されるようになります。 [#18806](https://github.com/tikv/tikv/issues/18806) [@LykxSassinator](https://github.com/LykxSassinator) | +| TiKV |
  • [`region-compact-check-interval`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#region-compact-check-interval)
  • [`region-compact-check-step`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#region-compact-check-step)
  • [`region-compact-min-tombstones`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#region-compact-min-tombstones)
  • [`region-compact-tombstones-percent`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#region-compact-tombstones-percent)
  • [`region-compact-min-redundant-rows`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#region-compact-min-redundant-rows-new-in-v710)
  • [`region-compact-redundant-rows-percent`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#region-compact-redundant-rows-percent-new-in-v710)
    • | 非推奨 | これらの設定項目は、自動圧縮動作を制御する[`gc.auto-compaction`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#gcauto-compaction)設定グループに置き換えられます。 [#18727](https://github.com/tikv/tikv/issues/18727) [@v01dstar](https://github.com/v01dstar) | +| TiKV | [`gc.auto-compaction`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#gcauto-compaction)設定グループ:
    • [`gc.auto-compaction.check-interval`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#check-interval-new-in-v757-and-v854)
    • [`gc.auto-compaction.tombstone-num-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#tombstone-num-threshold-new-in-v757-and-v854)
    • [`gc.auto-compaction.tombstone-percent-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#tombstone-percent-threshold-new-in-v757-and-v854)
    • [`gc.auto-compaction.redundant-rows-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#redundant-rows-threshold-new-in-v757-and-v854)
    • [`gc.auto-compaction.redundant-rows-percent-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#redundant-rows-percent-threshold-new-in-v757-and-v854)
    • [`gc.auto-compaction.bottommost-level-force`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#bottommost-level-force-new-in-v757-and-v854)
    | 新しく追加された | この構成グループは、自動圧縮動作を制御します。 [#18727](https://github.com/tikv/tikv/issues/18727) [@v01dstar](https://github.com/v01dstar) | | TiFlash | [`flash.graceful_wait_shutdown_timeout`](https://docs.pingcap.com/tidb/v8.5/tiflash-configuration#graceful_wait_shutdown_timeout-new-in-v854) | 新しく追加された | TiFlashの正常なシャットダウンの最大待機時間（秒単位）を制御します。デフォルト値は`600`です。TiFlashをシャットダウンする際、未完了のMPPタスクの実行は継続されますが、新しいMPPタスクは受け付けなくなります。すべてのMPPタスクがタイムアウト前に完了した場合、 TiFlashは直ちにシャットダウンします。そうでない場合は、タイムアウト後に強制的にシャットダウンされます。 [#10266](https://github.com/pingcap/tiflash/issues/10266) [@genliqi](https://github.com/gengliqi) | | TiCDC | [`scheduler.region-count-per-span`](https://docs.pingcap.com/tidb/v8.5/ticdc-changefeed-config#region-count-per-span-new-in-v854) | 新しく追加された | [TiCDCの新アーキテクチャ](https://docs.pingcap.com/tidb/v8.5/ticdc-architecture)で導入 チェンジフィードの初期化時に、TiCDCはこのパラメータに従って分割条件を満たすテーブルを分割します。各分割サブテーブルには、最大で`region-count-per-span`個のリージョンが含まれます。デフォルト値は`100`です。 | @@ -105,7 +105,7 @@ TiDBバージョン：8.5.4 - Grafana の**パフォーマンス概要**> **SQL 実行時間概要**パネルに`backoff`メトリックを追加してデバッグを容易にします [#61441](https://github.com/pingcap/tidb/issues/61441) @[dbsid](https://github.com/dbsid) - 監査ログ プラグインにステートメント ID 情報を追加 [#63525](https://github.com/pingcap/tidb/issues/63525) @[YangKeao](https://github.com/YangKeao) -- ティクヴ +- TiKV - BRモジュール内の特定の自動回復可能なエラーのログレベルを`ERROR`から`WARN`に変更して、不要なアラートを削減します [#18493](https://github.com/tikv/tikv/issues/18493) @[YuJuncen](https://github.com/YuJuncen) - 不要なアラートを減らすため、特定の TiKV エラーのログレベルを`ERROR`から`WARN`に変更します [#18745](https://github.com/tikv/tikv/issues/18745) @[exit-code-1](https://github.com/exit-code-1) @@ -184,8 +184,8 @@ TiDBバージョン：8.5.4 - クエリ対象の列に多数の`NULL`値が含まれている場合にクエリが失敗する可能性がある問題を修正 [#10340](https://github.com/pingcap/tiflash/issues/10340) @[Lloyd-Pottiger](https://github.com/Lloyd-Pottiger) - TiFlashがRU消費量の統計情報を水増しして生成する問題を修正 [#10380](https://github.com/pingcap/tiflash/issues/10380) @[JinheLin](https://github.com/JinheLin) - - 分離されたstorageとコンピューティングアーキテクチャの下で低速クエリが存在する場合にTiFlash でOOM が発生する可能性がある問題を修正 [#10278](https://github.com/pingcap/tiflash/issues/10278) @[JaySon-Huang](https://github.com/JaySon-Huang) - - 分散storageおよびコンピューティングアーキテクチャ下でTiFlashと S3 の間でネットワーク分割が発生した場合、 TiFlash が無期限に再試行する可能性がある問題を修正 [#10424](https://github.com/pingcap/tiflash/issues/10424) @[JaySon-Huang](https://github.com/JaySon-Huang) + - 分離されたストレージとコンピューティングアーキテクチャの下で低速クエリが存在する場合にTiFlash でOOM が発生する可能性がある問題を修正 [#10278](https://github.com/pingcap/tiflash/issues/10278) @[JaySon-Huang](https://github.com/JaySon-Huang) + - 分散ストレージおよびコンピューティングアーキテクチャ下でTiFlashと S3 の間でネットワーク分割が発生した場合、 TiFlash が無期限に再試行する可能性がある問題を修正 [#10424](https://github.com/pingcap/tiflash/issues/10424) @[JaySon-Huang](https://github.com/JaySon-Huang) - `FLOOR()`関数と`CEIL()`関数のパラメータ`DECIMAL`型の場合、誤った結果を返すことがある問題を修正 [#10365](https://github.com/pingcap/tiflash/issues/10365) @[ChangRui-Ryan](https://github.com/ChangRui-Ryan) - ツール @@ -196,7 +196,7 @@ TiDBバージョン：8.5.4 - Azure Blob Storageへのデータバックアップ時にフラッシュ操作が時々遅くなる問題を修正 [#18410](https://github.com/tikv/tikv/issues/18410) @[YuJuncen](https://github.com/YuJuncen) - ファイル削除が失敗した場合に`log truncate`が発生する可能性がある問題を修正 [#63358](https://github.com/pingcap/tidb/issues/63358) @[YuJuncen](https://github.com/YuJuncen) - バックアップ中に`--checksum`を`false`に設定すると、リストア後に`count`テーブルの`mysql.stats_meta`列が`0`になる可能性がある問題を修正 [#60978](https://github.com/pingcap/tidb/issues/60978) @[Leavrth](https://github.com/Leavrth) - - S3互換storageサービスの帯域幅制限が有効になっている場合に、 BRがこれらのサービスからデータを復元できない可能性を低減する [#18846](https://github.com/tikv/tikv/issues/18846) @[kennytm](https://github.com/kennytm) + - S3互換ストレージサービスの帯域幅制限が有効になっている場合に、 BRがこれらのサービスからデータを復元できない可能性を低減する [#18846](https://github.com/tikv/tikv/issues/18846) @[kennytm](https://github.com/kennytm) - `log backup observer`リージョン上の観測を失う可能性があり、ログバックアップの進行が進まなくなる問題を修正しました [#18243](https://github.com/tikv/tikv/issues/18243) @[Leavrth](https://github.com/Leavrth) - バックアップされたテーブルに特定の特殊スキーマが含まれている場合に`restore point`作成が失敗する問題を修正します [#63663](https://github.com/pingcap/tidb/issues/63663) @[RidRisR](https://github.com/RidRisR) diff --git a/releases/release-8.5.5.md b/releases/release-8.5.5.md index 0ee161a3dd347..6294943cbfdce 100644 --- a/releases/release-8.5.5.md +++ b/releases/release-8.5.5.md @@ -23,7 +23,7 @@ TiDBバージョン：8.5.5 - データ切り捨てのリスクが検出されない場合、TiDBはメタデータのみを更新し、可能な限りインデックスの再構築を回避します。 - インデックスの再構築が必要な場合、TiDBはより効率的な取り込みプロセスを使用することで、インデックス再構築のパフォーマンスを大幅に向上させます。 - 以下の表は、114 GiB のデータと 6 億行のデータを含むテーブルに対するベンチマーク テストに基づいたパフォーマンス改善の例を示しています。テスト クラスタは、3 つの TiDB ノード、6 つの TiKV ノード、および 1 つの PD ノードで構成されています。すべてのノードは、16 個の CPU コアと 32 GiB のメモリで構成されています。 + 以下の表は、114 GiB のデータと 6 億行のデータを含むテーブルに対するベンチマーク テストに基づいたパフォーマンス改善の例を示しています。テスト クラスターは、3 つの TiDB ノード、6 つの TiKV ノード、および 1 つの PD ノードで構成されています。すべてのノードは、16 個の CPU コアと 32 GiB のメモリで構成されています。 | シナリオ | 操作タイプ | 最適化前 | 最適化後 | パフォーマンスの向上 | | --------- | ------------------------- | ------ | ------ | ---------- | @@ -37,9 +37,9 @@ TiDBバージョン：8.5.5 - 外部キーが多数存在するシナリオにおける DDL パフォーマンスを改善し、論理 DDL パフォーマンスを最大 25 倍向上させます [#61126](https://github.com/pingcap/tidb/issues/61126) @[GMHDBJD](https://github.com/GMHDBJD) - バージョン8.5.5より前のバージョンでは、超大規模テーブル（例えば、外部キーを持つ数十万のテーブルを含む、合計1,000万のテーブルを持つクラスタなど）を扱うシナリオにおいて、論理DDL操作（テーブルの作成や列の追加など）のパフォーマンスが約4QPSまで低下することがありました。これは、マルチテナントSaaS環境における運用効率の低下につながっていました。 + バージョン8.5.5より前のバージョンでは、超大規模テーブル（例えば、外部キーを持つ数十万のテーブルを含む、合計1,000万のテーブルを持つクラスターなど）を扱うシナリオにおいて、論理DDL操作（テーブルの作成や列の追加など）のパフォーマンスが約4QPSまで低下することがありました。これは、マルチテナントSaaS環境における運用効率の低下につながっていました。 - TiDB v8.5.5 はこれらのシナリオを最適化します。テスト結果によると、1,000 万テーブル（外部キーを持つテーブル 20 万テーブルを含む）という極限環境においても、論理 DDL 処理性能は一貫して 100 QPS を維持します。これは以前のバージョンと比較して 25 倍向上しており、超大規模クラスタの運用応答性を大幅に向上させます。 + TiDB v8.5.5 はこれらのシナリオを最適化します。テスト結果によると、1,000 万テーブル（外部キーを持つテーブル 20 万テーブルを含む）という極限環境においても、論理 DDL 処理性能は一貫して 100 QPS を維持します。これは以前のバージョンと比較して 25 倍向上しており、超大規模クラスターの運用応答性を大幅に向上させます。 - クエリパフォーマンスを向上させるため、インデックス検索をTiKVにプッシュダウンするサポート [#62575](https://github.com/pingcap/tidb/issues/62575) [lcwangchao](https://github.com/lcwangchao) @@ -64,7 +64,7 @@ TiDBバージョン：8.5.5 バージョン8.5.5以降、ログバックアップ圧縮機能にオフライン圧縮機能が追加され、非構造化ログバックアップデータを構造化SSTファイルに変換できるようになりました。これにより、以下の改善が実現します。 - **リカバリ性能の向上**：SSTファイルをより迅速にクラスターにインポートできるようになりました。 - - **storage容量の削減**：圧縮処理中に冗長データが削除されます。 + - **ストレージ容量の削減**：圧縮処理中に冗長データが削除されます。 - **アプリケーションへの影響を軽減**：スナップショットベースのフルバックアップの頻度を減らすことで、RPO（リカバリポイント目標）を維持できます。 詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v8.5/br-compact-log-backup)を参照してください。 @@ -79,7 +79,7 @@ TiDBバージョン：8.5.5 - ネットワークジッター時のTiKVにおけるスケジューリングの安定性を向上させる [#9359](https://github.com/tikv/pd/issues/9359) [okJiang](https://github.com/okJiang) - バージョン8.5.5以降、TiKVはネットワークの遅延ノードを検出してフィードバックするメカニズムを導入しました。このメカニズムが有効になっている場合、TiKVはノード間のネットワークレイテンシーをプローブし、ネットワーク遅延スコアを計算して、そのスコアをPDに報告します。PDはこのスコアに基づいてTiKVノードのネットワーク状態を評価し、それに応じてスケジューリングを調整します。TiKVノードでネットワークジッターが発生していることが検出されると、PDはそのノードへの新しいリーダーのスケジューリングを制限します。ネットワークジッターが続く場合、PDは影響を受けているノードから既存のリーダーを他のTiKVノードに積極的に移動させ、ネットワークの問題がクラスタに与える影響を軽減します。 + バージョン8.5.5以降、TiKVはネットワークの遅延ノードを検出してフィードバックするメカニズムを導入しました。このメカニズムが有効になっている場合、TiKVはノード間のネットワークレイテンシーをプローブし、ネットワーク遅延スコアを計算して、そのスコアをPDに報告します。PDはこのスコアに基づいてTiKVノードのネットワーク状態を評価し、それに応じてスケジューリングを調整します。TiKVノードでネットワークジッターが発生していることが検出されると、PDはそのノードへの新しいリーダーのスケジューリングを制限します。ネットワークジッターが続く場合、PDは影響を受けているノードから既存のリーダーを他のTiKVノードに積極的に移動させ、ネットワークの問題がクラスターに与える影響を軽減します。 詳細については、 [ドキュメント](/pd-control.md#scheduler-config-evict-slow-store-scheduler)を参照してください。 @@ -105,7 +105,7 @@ TiDBバージョン：8.5.5 - TiKV の正常なシャットダウンをサポート [#17221](https://github.com/tikv/tikv/issues/17221) @[hujiatao0](https://github.com/hujiatao0) - TiKVサーバーをシャットダウンする際、TiKVはシャットダウン前に、設定可能なタイムアウト時間内にノード上のLeaderレプリカを他のTiKVノードに転送しようとします。デフォルトのタイムアウト時間は20秒で、 [`server.graceful-shutdown-timeout`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#graceful-shutdown-timeout-new-in-v855)設定項目を使用して調整できます。タイムアウトに達しても一部のリーダーが正常に転送されなかった場合、TiKVは残りのLeader転送をスキップしてシャットダウンを続行します。 + TiKVサーバーをシャットダウンする際、TiKVはシャットダウン前に、設定可能なタイムアウト時間内にノード上のリーダーレプリカを他のTiKVノードに転送しようとします。デフォルトのタイムアウト時間は20秒で、 [`server.graceful-shutdown-timeout`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#graceful-shutdown-timeout-new-in-v855)設定項目を使用して調整できます。タイムアウトに達しても一部のリーダーが正常に転送されなかった場合、TiKVは残りのLeader転送をスキップしてシャットダウンを続行します。 詳細については、 [ドキュメント](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#graceful-shutdown-timeout-new-in-v855)を参照してください。 @@ -117,15 +117,15 @@ TiDBバージョン：8.5.5 - ログ バックアップからのテーブル レベルの復元をサポート [#57613](https://github.com/pingcap/tidb/issues/57613) @[Tristan1900](https://github.com/Tristan1900) - バージョン8.5.5以降では、フィルタを使用してログバックアップから個々のテーブルのポイントインタイムリカバリ（PITR）を実行できます。クラスタ全体ではなく特定のテーブルを特定の時点に復元することで、より柔軟で影響の少ないリカバリオプションが提供されます。 + バージョン8.5.5以降では、フィルタを使用してログバックアップから個々のテーブルのポイントインタイムリカバリ（PITR）を実行できます。クラスター全体ではなく特定のテーブルを特定の時点に復元することで、より柔軟で影響の少ないリカバリオプションが提供されます。 詳細については、 [ドキュメント](/br/br-pitr-manual.md#restore-data-using-filters)を参照してください。 ### 可観測性 {#observability} -- ステートメントサマリーテーブルとスロークエリログにstorageエンジン識別子を追加する [#61736](https://github.com/pingcap/tidb/issues/61736) [henrybw](https://github.com/henrybw) +- ステートメントサマリーテーブルとスロークエリログにストレージエンジン識別子を追加する [#61736](https://github.com/pingcap/tidb/issues/61736) [henrybw](https://github.com/henrybw) - TiKVとTiFlashの両方がクラスタにデプロイされている場合、データベースの診断やパフォーマンス最適化の際に、storageエンジンごとにSQLステートメントをフィルタリングする必要が生じることがよくあります。たとえば、 TiFlashに高負荷がかかっている場合、潜在的な原因を特定するために、 TiFlash上​​で実行されているSQLステートメントを識別する必要があるかもしれません。このニーズに応えるため、TiDBはv8.5.5以降、ステートメントサマリーテーブルとスロークエリログにstorageエンジン識別子フィールドを追加しました。 + TiKVとTiFlashの両方がクラスターにデプロイされている場合、データベースの診断やパフォーマンス最適化の際に、ストレージエンジンごとにSQLステートメントをフィルタリングする必要が生じることがよくあります。たとえば、 TiFlashに高負荷がかかっている場合、潜在的な原因を特定するために、 TiFlash上​​で実行されているSQLステートメントを識別する必要があるかもしれません。このニーズに応えるため、TiDBはv8.5.5以降、ステートメントサマリーテーブルとスロークエリログにストレージエンジン識別子フィールドを追加しました。 [明細書概要表](/statement-summary-tables.md)表の新しいフィールド: @@ -147,15 +147,15 @@ TiDBバージョン：8.5.5 バージョン8.5.5以降、 BRはAzure Blob Storageへの認証にAzure Managed Identity（MI）をサポートし、静的SASトークンが不要になりました。これにより、Azureのセキュリティベストプラクティスに準拠した、安全でキーレスな一時的な認証が可能になります。 - この機能により、 BRとTiKVに組み込まれたBRワーカーは、Azureインスタンスメタデータサービス（IMDS）から直接アクセストークンを取得できるため、認証情報の漏洩リスクが軽減され、Azure上のセルフマネージドおよびクラウドデプロイメントの両方で認証情報のローテーション管理が簡素化されます。 + この機能により、 BRとTiKVに組み込まれたBRワーカーは、Azureインスタンスメタデータサービス（IMDS）から直接アクセストークンを取得できるため、認証情報の漏洩リスクが軽減され、Azure上のSelf-Managedおよびクラウドデプロイメントの両方で認証情報のローテーション管理が簡素化されます。 この機能は、Azure Kubernetes Service (AKS) またはその他の Azure 環境で実行されている TiDB クラスターに適用されます。特に、バックアップおよび復元操作に対して厳格なセキュリティ制御が求められるエンタープライズ環境において有効です。 - 詳細については、 [ドキュメント](/br/backup-and-restore-storages.md#authentication)を参照してください。 + 詳細については、 [ドキュメント](/br/backup-and-restore-ストレージs.md#authentication)を参照してください。 ## 互換性の変更 {#compatibility-changes} -TiDBクラスタがv8.5.4で新規にデプロイされている場合（つまり、v8.5.3より前のバージョンからアップグレードされていない場合）、v8.5.5へスムーズにアップグレードできます。v8.5.5の変更点のほとんどは通常のアップグレードでは問題ありませんが、このリリースには動作の変更、MySQLとの互換性調整、​​システム変数の更新、構成パラメータの更新、システムテーブルの変更も含まれています。アップグレードする前に、このセクションをよくお読みください。 +TiDBクラスターがv8.5.4で新規にデプロイされている場合（つまり、v8.5.3より前のバージョンからアップグレードされていない場合）、v8.5.5へスムーズにアップグレードできます。v8.5.5の変更点のほとんどは通常のアップグレードでは問題ありませんが、このリリースには動作の変更、MySQLとの互換性調整、​​システム変数の更新、構成パラメータの更新、システムテーブルの変更も含まれています。アップグレードする前に、このセクションをよくお読みください。 ### 行動の変化 {#behavior-changes} @@ -176,20 +176,20 @@ TiDBクラスタがv8.5.4で新規にデプロイされている場合（つま | [`tidb_cb_pd_metadata_error_rate_threshold_ratio`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_cb_pd_metadata_error_rate_threshold_ratio-new-in-v855) | 新しく追加された | TiDB がサーキットブレーカーをトリガーするタイミングを制御します。デフォルト値は`0`で、これはサーキットブレーカーが無効になっていることを意味します。 `0.01`から`1`の間の値を設定すると、サーキットブレーカーが有効になり、PD に送信される特定のリクエストのエラー率がしきい値に達するか超えたときにサーキットブレーカーがトリガーされます。 | | [`tidb_index_lookup_pushdown_policy`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_index_lookup_pushdown_policy-new-in-v855) | 新しく追加された | TiDB が`IndexLookUp`演算子を TiKV にプッシュするかどうか、またプッシュするタイミングを制御します。デフォルト値は`hint-only`です。これは、SQL ステートメントで[`INDEX_LOOKUP_PUSHDOWN`](https://docs.pingcap.com/tidb/v8.5/optimizer-hints#index_lookup_pushdownt1_name-idx1_name--idx2_name--new-in-v855)ヒントが明示的に指定されている場合にのみ、TiDB が`IndexLookUp`演算子を TiKV にプッシュすることを意味します。 | -### コンフィグレーションパラメータ {#configuration-parameters} +### 設定パラメータ {#configuration-parameters} -| コンフィグレーションファイルまたはコンポーネント | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイルまたはコンポーネント | 設定パラメータ | 種類を変更する | 説明 | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | TiDB | [`performance.enable-async-batch-get`](https://docs.pingcap.com/tidb/v8.5/tidb-configuration-file#enable-async-batch-get-new-in-v855) | 新しく追加された | TiDB がバッチ Get オペレーターを実行する際に非同期モードを使用するかどうかを制御します。デフォルト値は`false`です。 | -| ティクヴ | [`rocksdb.(defaultcf|writecf|lockcf|raftcf).level0-slowdown-writes-trigger`](/tikv-configuration-file.md#level0-slowdown-writes-trigger) | 修正済み | v8.5.5 以降では、フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`に設定されている場合)、この構成項目は、その値が`storage.flow-control.l0-files-threshold`より大きい場合にのみ[`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合、この構成項目は`storage.flow-control.l0-files-threshold`によって直接上書きされます。 | -| ティクヴ | [`rocksdb.(defaultcf|writecf|lockcf|raftcf).soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1) | 修正済み | v8.5.5 以降では、フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`に設定されている場合)、この構成項目は、その値が`storage.flow-control.soft-pending-compaction-bytes-limit`より大きい場合にのみ[`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)によって上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合、この構成項目は`storage.flow-control.soft-pending-compaction-bytes-limit`によって直接上書きされます。 | -| ティクヴ | [`readpool.cpu-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#cpu-threshold-new-in-v855) | 新しく追加された | 統合リードプールのCPU使用率のしきい値を指定します。デフォルト値は`0.0`で、これは統合リードプールのCPU使用率に制限がないことを意味します。スレッドプールのサイズは、ビジースレッドスケーリングアルゴリズムによってのみ決定され、現在のタスクを処理するスレッド数に基づいてサイズが動的に調整されます。 | -| ティクヴ | [`server.graceful-shutdown-timeout`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#graceful-shutdown-timeout-new-in-v855) | 新しく追加された | TiKV の正常なシャットダウンのタイムアウト時間を制御します。デフォルト値は`20s`です。 | -| ティクヴ | [`server.inspect-network-interval`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#inspect-network-interval-new-in-v855) | 新しく追加された | TiKV HealthChecker が PD や他の TiKV ノードに対してネットワーク検出をアクティブに実行する間隔を制御します。デフォルト値は`100ms`です。 | +| TiKV | [`rocksdb.(defaultcf|writecf|lockcf|raftcf).level0-slowdown-writes-trigger`](/tikv-configuration-file.md#level0-slowdown-writes-trigger) | 修正済み | v8.5.5 以降では、フロー制御メカニズムが有効になっている場合 ( [`ストレージ.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`に設定されている場合)、この構成項目は、その値が`ストレージ.flow-control.l0-files-threshold`より大きい場合にのみ[`ストレージ.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合、この構成項目は`ストレージ.flow-control.l0-files-threshold`によって直接上書きされます。 | +| TiKV | [`rocksdb.(defaultcf|writecf|lockcf|raftcf).soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1) | 修正済み | v8.5.5 以降では、フロー制御メカニズムが有効になっている場合 ( [`ストレージ.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`に設定されている場合)、この構成項目は、その値が`ストレージ.flow-control.soft-pending-compaction-bytes-limit`より大きい場合にのみ[`ストレージ.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)によって上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合、この構成項目は`ストレージ.flow-control.soft-pending-compaction-bytes-limit`によって直接上書きされます。 | +| TiKV | [`readpool.cpu-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#cpu-threshold-new-in-v855) | 新しく追加された | 統合リードプールのCPU使用率のしきい値を指定します。デフォルト値は`0.0`で、これは統合リードプールのCPU使用率に制限がないことを意味します。スレッドプールのサイズは、ビジースレッドスケーリングアルゴリズムによってのみ決定され、現在のタスクを処理するスレッド数に基づいてサイズが動的に調整されます。 | +| TiKV | [`server.graceful-shutdown-timeout`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#graceful-shutdown-timeout-new-in-v855) | 新しく追加された | TiKV の正常なシャットダウンのタイムアウト時間を制御します。デフォルト値は`20s`です。 | +| TiKV | [`server.inspect-network-interval`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#inspect-network-interval-new-in-v855) | 新しく追加された | TiKV HealthChecker が PD や他の TiKV ノードに対してネットワーク検出をアクティブに実行する間隔を制御します。デフォルト値は`100ms`です。 | | PD | [`schedule.max-affinity-merge-region-size`](https://docs.pingcap.com/tidb/v8.5/pd-configuration-file#max-affinity-merge-region-size-new-in-v855) | 新しく追加された | 同じ[親和性グループ](https://docs.pingcap.com/tidb/v8.5/table-affinity)内の隣接する小さな領域を自動的にマージするためのしきい値を制御します。デフォルト値は`256` （MiB単位）です。 | | PD | [`schedule.affinity-schedule-limit`](https://docs.pingcap.com/tidb/v8.5/pd-configuration-file#affinity-schedule-limit-new-in-v855) | 新しく追加された | 同時に実行できる[親和性](https://docs.pingcap.com/tidb/v8.5/table-affinity)スケジューリング タスクの数を制御します。デフォルト値は`0`で、これはデフォルトで親和性スケジューリングが無効になっていることを意味します。 | -| BR | [`--checkpoint-storage`](/br/br-checkpoint-restore.md#implementation-details-store-checkpoint-data-in-the-downstream-cluster) | 新しく追加された | チェックポイントデータの外部storageを指定します。 | -| BR | [`--fast-load-sys-tables`](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema) | 新しく追加された | 新しいクラスタ上でのシステムテーブルの物理的な復元をサポートします。このパラメータはデフォルトで有効になっています。 | +| BR | [`--checkpoint-ストレージ`](/br/br-checkpoint-restore.md#implementation-details-store-checkpoint-data-in-the-downstream-cluster) | 新しく追加された | チェックポイントデータの外部ストレージを指定します。 | +| BR | [`--fast-load-sys-tables`](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema) | 新しく追加された | 新しいクラスター上でのシステムテーブルの物理的な復元をサポートします。このパラメータはデフォルトで有効になっています。 | | BR | [`--filter`](/br/br-pitr-manual.md#restore-data-using-filters) | 新しく追加された | 復元対象に含める、または除外する特定のデータベースまたはテーブルを指定するパターンを指定します。 | ### システムテーブル {#system-tables} @@ -204,7 +204,7 @@ TiDBクラスタがv8.5.4で新規にデプロイされている場合（つま この問題により、データの完全バックアップと復元は影響を受けません。 - ターゲットとなるTiDBクラスタのバージョンと一致するBRバージョンを使用することをお勧めします。たとえば、TiDB v8.5.4クラスタでPITRを実行する場合は、 BR v8.5.4を使用してください。 + ターゲットとなるTiDBクラスターのバージョンと一致するBRバージョンを使用することをお勧めします。たとえば、TiDB v8.5.4クラスターでPITRを実行する場合は、 BR v8.5.4を使用してください。 ## 改善点 {#improvements} @@ -217,7 +217,7 @@ TiDBクラスタがv8.5.4で新規にデプロイされている場合（つま - 分散実行フレームワーク（DXF）における内部SQLステートメントのCPU使用率を最適化する [#59344](https://github.com/pingcap/tidb/issues/59344) @[D3Hunter](https://github.com/D3Hunter) - `expression.Contains`関数のパフォーマンスを改善 [#61373](https://github.com/pingcap/tidb/issues/61373) @[hawkingrei](https://github.com/hawkingrei) -- ティクヴ +- TiKV - ホットリードワークロード時のCPU飢餓を回避するために、統合リードプールにCPU認識スケーリングを導入する [#18464](https://github.com/tikv/tikv/issues/18464) @[mittalrishabh](https://github.com/mittalrishabh) - ネットワークレイテンシーを考慮したスコアを追加し、不安定なネットワーク状態のTiKVノードにリーダーをスケジュールしないようにする [#18797](https://github.com/tikv/tikv/issues/18797) @[okJiang](https://github.com/okJiang) @@ -228,7 +228,7 @@ TiDBクラスタがv8.5.4で新規にデプロイされている場合（つま - PDメモリ使用量を削減し、監視システムへの負荷を軽減するために、カーディナリティの高いメトリクスを最適化します [#9357](https://github.com/tikv/pd/issues/9357) @[rleungx](https://github.com/rleungx) - タイムスタンプの前進とリーダー選出のロジックを最適化 [#9981](https://github.com/tikv/pd/issues/9981) @[bufferflies](https://github.com/bufferflies) - - storageエンジン (TiKV またはTiFlash) による TiKV ストア制限のバッチ構成をサポート [#9970](https://github.com/tikv/pd/issues/9970) @[bufferflies](https://github.com/bufferflies) + - ストレージエンジン (TiKV またはTiFlash) による TiKV ストア制限のバッチ構成をサポート [#9970](https://github.com/tikv/pd/issues/9970) @[bufferflies](https://github.com/bufferflies) - `store`メトリックに`pd_cluster_status`ラベルを追加します [#9855](https://github.com/tikv/pd/issues/9855) @[SerjKol80](https://github.com/SerjKol80) - ツール @@ -275,11 +275,11 @@ TiDBクラスタがv8.5.4で新規にデプロイされている場合（つま - `information_schema.tables`をクエリする際に発生する可能性のある OOM 問題を修正するため、システム テーブルをクエリする際のメモリ使用量の監視を改善しました [#58985](https://github.com/pingcap/tidb/issues/58985) @[tangenta](https://github.com/tangenta) - `client-go`の潜在的なメモリリークを修正 [#65522](https://github.com/pingcap/tidb/issues/65522) @[bufferflies](https://github.com/bufferflies) -- ティクヴ +- TiKV - 分析リクエストの`KV Cursor Operations`メトリックが常に`0`になる問題を修正 [#19206](https://github.com/tikv/tikv/issues/19206) @[glorv](https://github.com/glorv) - リーダー変更後にリージョンハートビートがリージョンサイズやキー統計情報をPDに誤って報告する可能性がある問題を修正 [#19180](https://github.com/tikv/tikv/issues/19180) @[glorv](https://github.com/glorv) - - 安全でないリカバリが停止する問題を修正するため、安全でないリカバリ降格リストからTombstone TiFlash学習者を削除します [#18458](https://github.com/tikv/tikv/issues/18458) @[v01dstar](https://github.com/v01dstar) + - 安全でないリカバリが停止する問題を修正するため、安全でないリカバリ降格リストからTombstone TiFlashラーナーを削除します [#18458](https://github.com/tikv/tikv/issues/18458) @[v01dstar](https://github.com/v01dstar) - 連続書き込み中にスナップショットが繰り返しキャンセルされ、レプリカのリカバリがブロックされる問題を修正 [#18872](https://github.com/tikv/tikv/issues/18872) @[exit-code-1](https://github.com/exit-code-1) - 流量制御しきい値の増加により圧縮速度が低下する問題を修正 [#18708](https://github.com/tikv/tikv/issues/18708) @[hhwyt](https://github.com/hhwyt) - 特殊なケースでRaftピアが予定より早く休止状態に入り、TiKV の再起動後にビジー状態が続き、リーダー転送がブロックされる問題を修正しました [#19203](https://github.com/tikv/tikv/issues/19203) @[LykxSassinator](https://github.com/LykxSassinator) @@ -307,13 +307,13 @@ TiDBクラスタがv8.5.4で新規にデプロイされている場合（つま - クラスターに多数のリージョンが含まれている場合にログバックアップを有効にするとメモリ使用量が過剰になる問題を修正 [#18719](https://github.com/tikv/tikv/issues/18719) @[YuJuncen](https://github.com/YuJuncen) - Azure SDK が環境から適切なキーを見つけられない問題を修正 [#18206](https://github.com/tikv/tikv/issues/18206) @[YuJuncen](https://github.com/YuJuncen) - `restore point` [#61642](https://github.com/pingcap/tidb/issues/61642) @[Leavrth](https://github.com/Leavrth)の期間中に外部キーが正しく復元されない問題を修正します。 - - バックアップとターゲットクラスタ間でシステムテーブルの照合順序に互換性がない場合にリストアが失敗する問題を修正するため、v6.5 から v7.5 への特権テーブルのリストアをサポートする`--sys-check-collation`パラメータを追加しました。 [#64667](https://github.com/pingcap/tidb/issues/64667) @[Leavrth](https://github.com/Leavrth) + - バックアップとターゲットクラスター間でシステムテーブルの照合順序に互換性がない場合にリストアが失敗する問題を修正するため、v6.5 から v7.5 への特権テーブルのリストアをサポートする`--sys-check-collation`パラメータを追加しました。 [#64667](https://github.com/pingcap/tidb/issues/64667) @[Leavrth](https://github.com/Leavrth) - `restore log`が失敗した後に`restore point`を実行できない問題を修正します（操作が安全な場合でも）。 [#64908](https://github.com/pingcap/tidb/issues/64908) @[RidRisR](https://github.com/RidRisR) - チェックポイントの`restore point`が、ログバックアップデータがフルバックアップと混在している場合にpanic可能性がある問題を修正 [#58685](https://github.com/pingcap/tidb/issues/58685) @[YuJuncen](https://github.com/YuJuncen) - TiCDC - - ライターのクローズエラーが正しくキャプチャされないため、オブジェクトstorageへのレプリケーション中にデータが失われる可能性がある問題を修正します [#12436](https://github.com/pingcap/tiflow/issues/12436) @[wk989898](https://github.com/wk989898) + - ライターのクローズエラーが正しくキャプチャされないため、オブジェクトストレージへのレプリケーション中にデータが失われる可能性がある問題を修正します [#12436](https://github.com/pingcap/tiflow/issues/12436) @[wk989898](https://github.com/wk989898) - パーティションテーブルで`TRUNCATE`操作を複製すると、変更フィードが失敗する可能性がある問題を修正します [#12430](https://github.com/pingcap/tiflow/issues/12430) @[wk989898](https://github.com/wk989898) - 複数テーブルの`RENAME` DDL ステートメントを複製する際に、下流の実行順序が正しくない可能性がある問題を修正します [#12449](https://github.com/pingcap/tiflow/issues/12449) @[wlwilliamx](https://github.com/wlwilliamx) - `aws-sdk-go-v2`依存関係のバージョンをアップグレードすることで、Glue Schema Registryの使用時に発生する可能性のある接続エラーを修正します [#12424](https://github.com/pingcap/tiflow/issues/12424) @[wk989898](https://github.com/wk989898) diff --git a/releases/release-8.5.6.md b/releases/release-8.5.6.md index 3be42e2084b12..9fc5d5645acc2 100644 --- a/releases/release-8.5.6.md +++ b/releases/release-8.5.6.md @@ -27,7 +27,7 @@ TiDBバージョン：8.5.6 - リソース制御のバックグラウンドタスクにおけるリソース使用量の上限を設定する機能が一般提供開始（GA）になりました [#56019](https://github.com/pingcap/tidb/issues/56019) @[glorv](https://github.com/glorv) - TiDBのリソース制御機能を使用すると、バックグラウンドタスクを識別して優先度を下げることができます。特定のシナリオでは、リソースが利用可能な場合でも、バックグラウンドタスクのリソース消費を制限したい場合があります。v8.4.0以降では、 `UTILIZATION_LIMIT`パラメータを使用して、バックグラウンドタスクが消費できるリソースの最大割合を設定できます。各ノードは、すべてのバックグラウンドタスクのリソース使用量をこの割合以下に抑えます。この機能により、バックグラウンドタスクのリソース消費を正確に制御できるため、クラスタの安定性がさらに向上します。 + TiDBのリソース制御機能を使用すると、バックグラウンドタスクを識別して優先度を下げることができます。特定のシナリオでは、リソースが利用可能な場合でも、バックグラウンドタスクのリソース消費を制限したい場合があります。v8.4.0以降では、 `UTILIZATION_LIMIT`パラメータを使用して、バックグラウンドタスクが消費できるリソースの最大割合を設定できます。各ノードは、すべてのバックグラウンドタスクのリソース使用量をこの割合以下に抑えます。この機能により、バックグラウンドタスクのリソース消費を正確に制御できるため、クラスターの安定性がさらに向上します。 バージョン8.5.6では、この機能は一般提供（GA）されています。 @@ -77,7 +77,7 @@ TiDBバージョン：8.5.6 ## 互換性の変更 {#compatibility-changes} -TiDBクラスタをv8.5.5で新規にデプロイした場合（つまり、v8.5.4より前のバージョンからアップグレードしていない場合）、v8.5.6へスムーズにアップグレードできます。v8.5.6の変更点のほとんどは通常のアップグレードでは問題ありませんが、このリリースにはMySQLとの互換性に関する変更、システム変数の更新、構成パラメータの更新、および非推奨機能も含まれています。アップグレードする前に、このセクションをよくお読みください。 +TiDBクラスターをv8.5.5で新規にデプロイした場合（つまり、v8.5.4より前のバージョンからアップグレードしていない場合）、v8.5.6へスムーズにアップグレードできます。v8.5.6の変更点のほとんどは通常のアップグレードでは問題ありませんが、このリリースにはMySQLとの互換性に関する変更、システム変数の更新、構成パラメータの更新、および非推奨機能も含まれています。アップグレードする前に、このセクションをよくお読みください。 ### MySQLとの互換性 {#mysql-compatibility} @@ -92,30 +92,30 @@ TiDBクラスタをv8.5.5で新規にデプロイした場合（つまり、v8.5 | ---------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`tidb_analyze_version`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_analyze_version-new-in-v510) | 修正済み | バージョン8.5.6以降、統計情報バージョン1（ `tidb_analyze_version = 1` ）は非推奨となり、今後のリリースで削除されます。統計情報バージョン2（ `tidb_analyze_version = 2` ）の使用をお勧めします。 | | [`tidb_ignore_inlist_plan_digest`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_ignore_inlist_plan_digest-new-in-v760) | 修正済み | デフォルト値を`OFF`から`ON`に変更します。デフォルト値`ON`は、TiDB が`IN` } リスト内の要素の差異 (要素数の差異を含む) を無視し、プランダイジェストを生成する際に`...`を使用して`IN`リスト内の要素を置き換えることを意味します。 | -| [`tidb_service_scope`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_service_scope-new-in-v740) | 修正済み | バージョン8.5.6以降、この変数の値は大文字と小文字を区別しません。TiDBは、storageおよび比較のために、入力値を小文字に変換します。 | +| [`tidb_service_scope`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_service_scope-new-in-v740) | 修正済み | バージョン8.5.6以降、この変数の値は大文字と小文字を区別しません。TiDBは、ストレージおよび比較のために、入力値を小文字に変換します。 | | [`InPacketBytes`](https://docs.pingcap.com/tidb/v8.5/system-variables#inpacketbytes-new-in-v856) | 新しく追加された | この変数は内部統計のみに使用され、ユーザーには表示されません。 | | [`OutPacketBytes`](https://docs.pingcap.com/tidb/v8.5/system-variables#outpacketbytes-new-in-v856) | 新しく追加された | この変数は内部統計のみに使用され、ユーザーには表示されません。 | | [`tidb_foreign_key_check_in_shared_lock`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_foreign_key_check_in_shared_lock-new-in-v856) | 新しく追加された | 悲観的トランザクションにおける外部キーチェックで、親テーブルの行に対して排他ロックではなく共有ロックを使用するかどうかを制御します。デフォルト値は`OFF`で、これは TiDB がデフォルトで排他ロックを使用することを意味します。 | -| [`tidb_max_dist_task_nodes`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_max_dist_task_nodes-new-in-v856) | 新しく追加された | 分散実行フレームワーク (DXF) タスクが使用できる TiDB ノードの最大数を定義します。デフォルト値は`-1`で、これは自動モードが有効になっていることを示します。自動モードでは、TiDB は`min(3, tikv_nodes / 3)`という値を動的に計算します。ここで、 `tikv_nodes`クラスタ内の TiKV ノードの数を表します。 | +| [`tidb_max_dist_task_nodes`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_max_dist_task_nodes-new-in-v856) | 新しく追加された | 分散実行フレームワーク (DXF) タスクが使用できる TiDB ノードの最大数を定義します。デフォルト値は`-1`で、これは自動モードが有効になっていることを示します。自動モードでは、TiDB は`min(3, tikv_nodes / 3)`という値を動的に計算します。ここで、 `tikv_nodes`クラスター内の TiKV ノードの数を表します。 | | [`tidb_opt_join_reorder_through_sel`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_opt_join_reorder_through_sel-new-in-v856) | 新しく追加された | 特定の複数テーブル結合クエリの結合順序最適化を改善します。これを`ON`に設定し、安全条件が満たされている場合、オプティマイザは、連続する結合演算子間の`Selection`条件と結合順序候補を評価します。結合ツリーの再構築中、オプティマイザは可能な限りこれらの条件をより適切な位置に押し下げ、より多くのテーブルが結合順序最適化に参加できるようにします。 | | [`tidb_opt_partial_ordered_index_for_topn`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_opt_partial_ordered_index_for_topn-new-in-v856) | 新しく追加された | クエリに`ORDER BY ... LIMIT`が含まれている場合に、オプティマイザがインデックスの部分順序を利用して TopN 計算を最適化できるかどうかを制御します。デフォルト値は`DISABLE`で、これは最適化が無効になっていることを意味します。 | | [`tidb_slow_log_max_per_sec`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_max_per_sec-new-in-v856) | 新しく追加された | TiDBノードごとに1秒あたりに書き込める、低速クエリログエントリの最大数を制御します。
    • `0` （デフォルト値）という値は、1秒あたりに書き込まれるスロークエリログエントリの数に制限がないことを意味します。
    • `0`より大きい値を指定すると、TiDBは1秒あたりに指定された数のスロークエリログエントリを書き込みます。超過分のログエントリは破棄され、スロークエリログファイルには書き込まれません。
    | | [`tidb_slow_log_rules`](https://docs.pingcap.com/tidb/v8.5/system-variables#tidb_slow_log_rules-new-in-v856) | 新しく追加された | スロークエリログのトリガールールを定義します。多次元メトリクスを組み合わせることで、より柔軟で詳細なログ記録を実現します。 | -### コンフィグレーションパラメータ {#configuration-parameters} +### 設定パラメータ {#configuration-parameters} -| コンフィグレーションファイルまたはコンポーネント | コンフィグレーションパラメータ | 種類を変更する | 説明 | +| 設定ファイルまたはコンポーネント | 設定パラメータ | 種類を変更する | 説明 | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------- | -------- | -------------------------------------------------------------------------------- | -| ティクヴ | [`gc.auto-compaction.mvcc-read-aware-enabled`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#mvcc-read-aware-enabled-new-in-v856) | 新しく追加された | MVCC読み取り対応の圧縮を有効にするかどうかを制御します。デフォルト値は`false`です。 | -| ティクヴ | [`gc.auto-compaction.mvcc-read-weight`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#mvcc-read-weight-new-in-v856) | 新しく追加された | リージョンの圧縮優先度スコアを計算する際に、MVCC 読み取りアクティビティに適用される重み乗数。デフォルト値は`3.0`です。 | -| ティクヴ | [`gc.auto-compaction.mvcc-scan-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#mvcc-scan-threshold-new-in-v856) | 新しく追加された | リージョンを圧縮候補としてマークするために、読み取り要求ごとにスキャンされる MVCC バージョンの最小数。デフォルト値は`1000`です。 | +| TiKV | [`gc.auto-compaction.mvcc-read-aware-enabled`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#mvcc-read-aware-enabled-new-in-v856) | 新しく追加された | MVCC読み取り対応の圧縮を有効にするかどうかを制御します。デフォルト値は`false`です。 | +| TiKV | [`gc.auto-compaction.mvcc-read-weight`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#mvcc-read-weight-new-in-v856) | 新しく追加された | リージョンの圧縮優先度スコアを計算する際に、MVCC 読み取りアクティビティに適用される重み乗数。デフォルト値は`3.0`です。 | +| TiKV | [`gc.auto-compaction.mvcc-scan-threshold`](https://docs.pingcap.com/tidb/v8.5/tikv-configuration-file#mvcc-scan-threshold-new-in-v856) | 新しく追加された | リージョンを圧縮候補としてマークするために、読み取り要求ごとにスキャンされる MVCC バージョンの最小数。デフォルト値は`1000`です。 | | TiCDC | [`sink.csv.output-field-header`](https://docs.pingcap.com/tidb/v8.5/ticdc-csv#use-csv) | 新しく追加された | CSVファイルにヘッダー行を出力するかどうかを制御します。デフォルト値は`false`です。このパラメータはTiCDCの新しいアーキテクチャにのみ適用されます。 | ### システムテーブルの変更 {#system-table-changes} | システムテーブル | 種類を変更する | 説明 | | -------------------------------------------------------------------------------------------- | ------- | ----------------------------------------------------------------------------------- | -| [`mysql.tidb`](https://docs.pingcap.com/tidb/v8.5/mysql-schema#cluster-status-system-tables) | 修正済み | TiDBクラスタの一意の識別子を表す`cluster_id`フィールドを追加します。 `cluster_id`は読み取り専用であり、変更できませんのでご注意ください。 | +| [`mysql.tidb`](https://docs.pingcap.com/tidb/v8.5/mysql-schema#cluster-status-system-tables) | 修正済み | TiDBクラスターの一意の識別子を表す`cluster_id`フィールドを追加します。 `cluster_id`は読み取り専用であり、変更できませんのでご注意ください。 | ## 非推奨機能 {#deprecated-features} @@ -130,10 +130,10 @@ TiDBクラスタをv8.5.5で新規にデプロイした場合（つまり、v8.5 - 印刷不可能なプリペアドステートメント引数を16進数として出力することで、スロークエリログの可読性を向上させる [#65383](https://github.com/pingcap/tidb/issues/65383) @[dveeden](https://github.com/dveeden) - `cluster_id`を`mysql.tidb`に追加し、外部ツールが 2 つの TiDB インスタンスが同じクラスターに属しているかどうかを判断できるようにします [#59476](https://github.com/pingcap/tidb/issues/59476) @[YangKeao](https://github.com/YangKeao) -- ティクヴ +- TiKV - MVCCの読み取りオーバーヘッドを検出し、読み取りコストの高いリージョンの圧縮を優先することでクエリパフォーマンスを向上させる、負荷ベースの圧縮メカニズムを導入します [#19133](https://github.com/tikv/tikv/issues/19133) @[mittalrishabh](https://github.com/mittalrishabh) - - クラスタのスケールアウトおよびスケールイン操作中に、古いキーをSSTファイル取り込みでクリーンアップするのではなく直接削除することで、古いキーの範囲のクリーンアップロジックを最適化し、オンラインリクエストのレイテンシーへの影響を軽減します。 [#18042](https://github.com/tikv/tikv/issues/18042) @[LykxSassinator](https://github.com/LykxSassinator) + - クラスターのスケールアウトおよびスケールイン操作中に、古いキーをSSTファイル取り込みでクリーンアップするのではなく直接削除することで、古いキーの範囲のクリーンアップロジックを最適化し、オンラインリクエストのレイテンシーへの影響を軽減します。 [#18042](https://github.com/tikv/tikv/issues/18042) @[LykxSassinator](https://github.com/LykxSassinator) - PD @@ -159,7 +159,7 @@ TiDBクラスタをv8.5.5で新規にデプロイした場合（つまり、v8.5 - `modify_count`の異常な更新により統計情報が更新されない可能性がある問題を修正しました [#65426](https://github.com/pingcap/tidb/issues/65426) @[0xPoe](https://github.com/0xPoe) - フェアロックモードで最初のステートメントがロックを取得する際に、キープアライブメカニズムの失敗により悲観的トランザクションが予期せずロールバックされる可能性がある問題を修正 [#66571](https://github.com/pingcap/tidb/issues/66571) @[MyonKeminta](https://github.com/MyonKeminta) -- ティクヴ +- TiKV - クロスビームスキップリストのメモリリーク問題を修正 [#19285](https://github.com/tikv/tikv/issues/19285) @[ekexium](https://github.com/ekexium) - パーティションテーブルの一意でない列のグローバルインデックスが、場合によっては不整合になり、誤った結果を返す可能性がある問題を修正しました [#19262](https://github.com/tikv/tikv/issues/19262) @[mjonss](https://github.com/mjonss) @@ -194,7 +194,7 @@ TiDBクラスタをv8.5.5で新規にデプロイした場合（つまり、v8.5 - changefeedsがサーバー再起動後に無効なディスパッチャーを繰り返し作成する可能性がある問題を修正 [#4452](https://github.com/pingcap/ticdc/issues/4452) @[wlwilliamx](https://github.com/wlwilliamx) - TiCDCが、上流のTiDBバージョンがv8.1.x以前の場合にテーブル名変更操作を正しく複製できない問題を修正 [#4392](https://github.com/pingcap/ticdc/issues/4392) @[lidezhu](https://github.com/lidezhu) - TiCDCが有効になっている場合に、データスキャン中にTiKVがクラッシュする可能性がある問題を修正しました [#19404](https://github.com/tikv/tikv/issues/19404) @[wk989898](https://github.com/wk989898) - - Azure Blob Storage の Azure Managed Identity 認証をサポートし、クラウドstorageへのアップロードが停止する可能性がある問題を修正します [#3093](https://github.com/pingcap/ticdc/issues/3093) @[wlwilliamx](https://github.com/wlwilliamx) + - Azure Blob Storage の Azure Managed Identity 認証をサポートし、クラウドストレージへのアップロードが停止する可能性がある問題を修正します [#3093](https://github.com/pingcap/ticdc/issues/3093) @[wlwilliamx](https://github.com/wlwilliamx) - TiDBデータ移行（DM） diff --git a/releases/release-pre-ga.md b/releases/release-pre-ga.md index 65f05d536997d..03ccf3dbc97e6 100644 --- a/releases/release-pre-ga.md +++ b/releases/release-pre-ga.md @@ -1,6 +1,6 @@ --- title: Pre-GA release notes -summary: 2017年8月30日にリリースされたTiDBのプレGAリリースは、MySQLとの互換性、SQLの最適化、安定性、そしてパフォーマンスに重点を置いています。TiDBでは、SQLクエリオプティマイザーの強化、MySQLとの互換性、JSON型のサポート、そしてメモリ消費量の削減が導入されています。配置Driver（PD）は手動でのリーダー変更をサポートするようになり、TiKVはRaftログstorageに専用のRocksdbを使用することでパフォーマンスを向上させています。Sparkベータリリース向けのTiDBコネクタは、述語プッシュダウン、集計プッシュダウン、そして範囲プルーニングを実装し、TPC+Hクエリの実行を可能にします。 +summary: 2017年8月30日にリリースされたTiDBのプレGAリリースは、MySQLとの互換性、SQLの最適化、安定性、そしてパフォーマンスに重点を置いています。TiDBでは、SQLクエリオプティマイザーの強化、MySQLとの互換性、JSON型のサポート、そしてメモリ消費量の削減が導入されています。配置Driver（PD）は手動でのリーダー変更をサポートするようになり、TiKVはRaftログストレージに専用のRocksdbを使用することでパフォーマンスを向上させています。Sparkベータリリース向けのTiDBコネクタは、述語プッシュダウン、集計プッシュダウン、そして範囲プルーニングを実装し、TPC+Hクエリの実行を可能にします。 --- # プレGAリリースノート {#pre-ga-release-notes} @@ -22,7 +22,7 @@ summary: 2017年8月30日にリリースされたTiDBのプレGAリリースは ## 配置Driver（PD） {#placement-driver-pd} -- PDクラスタのリーダーを手動で変更する機能をサポート +- PDクラスターのリーダーを手動で変更する機能をサポート ## TiKV {#tikv} diff --git a/releases/release-rc.2.md b/releases/release-rc.2.md index 1aca06ec532d3..852179777dd79 100644 --- a/releases/release-rc.2.md +++ b/releases/release-rc.2.md @@ -23,7 +23,7 @@ summary: 2017年3月1日にリリースされたTiDB RC2は、MySQLとの互換 - Create Table Like ステートメントをサポートする - 警告の表示ステートメントをサポートする - Rename Tableステートメントをサポートする -- 大規模なトランザクションのクラスタブロックを回避するために、単一のトランザクションのサイズを制限します。 +- 大規模なトランザクションのクラスターブロックを回避するために、単一のトランザクションのサイズを制限します。 - データのロードプロセスでデータを自動的に分割する - AddIndex および Delete ステートメントのパフォーマンスを最適化します - 「ANSI_QUOTES」sql_modeをサポート @@ -39,7 +39,7 @@ summary: 2017年3月1日にリリースされたTiDB RC2は、MySQLとの互換 - PDを追加または削除する - キーでリージョン情報を取得する - スケジューラとオペレータの追加または削除 - - クラスタラベル情報を取得する + - クラスターラベル情報を取得する ## TiKV {#tikv} diff --git a/releases/release-rc.3.md b/releases/release-rc.3.md index 4e7398b8096dd..cd05b37250e51 100644 --- a/releases/release-rc.3.md +++ b/releases/release-rc.3.md @@ -1,6 +1,6 @@ --- title: TiDB RC3 Release Notes -summary: 2017年6月16日にリリースされたTiDB RC3は、MySQLとの互換性、SQLの最適化、安定性、パフォーマンスに重点を置いています。主な特徴としては、権限管理の改良、DDLの高速化、負荷分散の最適化、そしてクラスタ管理を容易にするオープンソース化されたTiDB Ansibleなどが挙げられます。TiDB、Placement Driver （PD）、TiKVの詳細なアップデートには、SQLクエリの最適化の改善、権限管理の強化、HTTP APIのサポート、クエリ同時実行制御のためのシステム変数、そしてデータバランスの効率化などが含まれます。PDはgRPC、ディザスタリカバリツールキット、そしてホットリージョンスケジューリングをサポートしています。TiKVはgRPC、SST形式のスナップショット、メモリリーク検出、そしてデータインポート速度の向上をサポートしています。全体として、このリリースはパフォーマンス、安定性、そして管理機能を強化しています。 +summary: 2017年6月16日にリリースされたTiDB RC3は、MySQLとの互換性、SQLの最適化、安定性、パフォーマンスに重点を置いています。主な特徴としては、権限管理の改良、DDLの高速化、負荷分散の最適化、そしてクラスター管理を容易にするオープンソース化されたTiDB Ansibleなどが挙げられます。TiDB、Placement Driver （PD）、TiKVの詳細なアップデートには、SQLクエリの最適化の改善、権限管理の強化、HTTP APIのサポート、クエリ同時実行制御のためのシステム変数、そしてデータバランスの効率化などが含まれます。PDはgRPC、ディザスタリカバリツールキット、そしてホットリージョンスケジューリングをサポートしています。TiKVはgRPC、SST形式のスナップショット、メモリリーク検出、そしてデータインポート速度の向上をサポートしています。全体として、このリリースはパフォーマンス、安定性、そして管理機能を強化しています。 --- # TiDB RC3 リリースノート {#tidb-rc3-release-notes} diff --git a/replicate-between-primary-and-secondary-clusters.md b/replicate-between-primary-and-secondary-clusters.md index b2cb9aae27c12..9564e6263dab4 100644 --- a/replicate-between-primary-and-secondary-clusters.md +++ b/replicate-between-primary-and-secondary-clusters.md @@ -1,29 +1,29 @@ --- title: Replicate data between primary and secondary clusters -summary: プライマリクラスタからセカンダリクラスタへデータを複製する方法を学びましょう。 +summary: プライマリクラスターからセカンダリクラスターへデータを複製する方法を学びましょう。 --- -# プライマリクラスタとセカンダリクラスタ間でデータを複製する {#replicate-data-between-primary-and-secondary-clusters} +# プライマリクラスターとセカンダリクラスター間でデータを複製する {#replicate-data-between-primary-and-secondary-clusters} -このドキュメントでは、TiDBプライマリ（アップストリーム）クラスタとTiDBまたはMySQLセカンダリ（ダウンストリーム）クラスタを構成し、プライマリクラスタからセカンダリクラスタへ増分データをレプリケートする方法について説明します。プロセスには以下の手順が含まれます。 +このドキュメントでは、TiDBプライマリ（アップストリーム）クラスターとTiDBまたはMySQLセカンダリ（ダウンストリーム）クラスターを構成し、プライマリクラスターからセカンダリクラスターへ増分データをレプリケートする方法について説明します。プロセスには以下の手順が含まれます。 -1. TiDBプライマリクラスタと、TiDBまたはMySQLセカンダリクラスタを設定します。 -2. プライマリクラスタからセカンダリクラスタへ、増分データを複製する。 -3. プライマリクラスタがダウンした場合でも、リドゥログを使用してデータの確実な復旧を実現します。 +1. TiDBプライマリクラスターと、TiDBまたはMySQLセカンダリクラスターを設定します。 +2. プライマリクラスターからセカンダリクラスターへ、増分データを複製する。 +3. プライマリクラスターがダウンした場合でも、リドゥログを使用してデータの確実な復旧を実現します。 -実行中の TiDB クラスタからセカンダリ クラスタに増分データを複製するには、Backup & Restore [BR](/br/backup-and-restore-overview.md)と[TiCDC](/ticdc/ticdc-overview.md)を使用できます。 +実行中の TiDB クラスターからセカンダリ クラスターに増分データを複製するには、Backup & Restore [BR](/br/backup-and-restore-overview.md)と[TiCDC](/ticdc/ticdc-overview.md)を使用できます。 ## ステップ1. 環境をセットアップする {#step-1-set-up-the-environment} -1. TiDBクラスタをデプロイ。 +1. TiDBクラスターをデプロイ。 - TiUP Playground を使用して、2 つの TiDB クラスター (1 つはアップストリーム、もう 1 つはダウンストリーム)をデプロイ。本番環境の場合は、 [TiUPを使用してオンラインTiDBクラスタをデプロイおよび管理](/tiup/tiup-cluster.md)を参照してクラスターをデプロイします。 + TiUP Playground を使用して、2 つの TiDB クラスター (1 つはアップストリーム、もう 1 つはダウンストリーム)をデプロイ。本番環境の場合は、 [TiUPを使用してオンラインTiDBクラスターをデプロイおよび管理](/tiup/tiup-cluster.md)を参照してクラスターをデプロイします。 このドキュメントでは、2台のマシンに2つのクラスターをデプロイします。 - - ノードA：172.16.6.123、上流のTiDBクラスタをデプロイするため + - ノードA：172.16.6.123、上流のTiDBクラスターをデプロイするため - - ノードB：172.16.6.124、下流のTiDBクラスタをデプロイするため + - ノードB：172.16.6.124、下流のTiDBクラスターをデプロイするため ```shell # Create an upstream cluster on Node A @@ -36,7 +36,7 @@ summary: プライマリクラスタからセカンダリクラスタへデー 2. データを初期化します。 - デフォルトでは、新しくデプロイされたクラスタにテストデータベースが作成されます。そのため、 [sysbench](https://github.com/akopytov/sysbench#linux)を使用してテストデータを生成し、実際のシナリオでデータをシミュレートできます。 + デフォルトでは、新しくデプロイされたクラスターにテストデータベースが作成されます。そのため、 [sysbench](https://github.com/akopytov/sysbench#linux)を使用してテストデータを生成し、実際のシナリオでデータをシミュレートできます。 ```shell sysbench oltp_write_only --config-file=./tidb-config --tables=10 --table-size=10000 prepare @@ -59,15 +59,15 @@ summary: プライマリクラスタからセカンダリクラスタへデー 3. サービス負荷をシミュレーションします。 - 実際のシナリオでは、サービスデータはアップストリームクラスタに継続的に書き込まれます。このドキュメントでは、sysbenchを使用してこのワークロードをシミュレートします。具体的には、以下のコマンドを実行して、10個のワーカーがsbtest1、sbtest2、sbtest3の3つのテーブルにデータを継続的に書き込むようにし、合計TPSが100を超えないようにします。 + 実際のシナリオでは、サービスデータはアップストリームクラスターに継続的に書き込まれます。このドキュメントでは、sysbenchを使用してこのワークロードをシミュレートします。具体的には、以下のコマンドを実行して、10個のワーカーがsbtest1、sbtest2、sbtest3の3つのテーブルにデータを継続的に書き込むようにし、合計TPSが100を超えないようにします。 ```shell sysbench oltp_write_only --config-file=./tidb-config --tables=3 run ``` -4. 外部storageを準備してください。 +4. 外部ストレージを準備してください。 - フルデータバックアップでは、アップストリームクラスタとダウンストリームクラスタの両方がバックアップファイルにアクセスする必要があります。バックアップファイルの保存には[外部storage](/br/backup-and-restore-storages.md)を使用することをお勧めします。この例では、Minioを使用してS3互換のstorageサービスをシミュレートしています。 + フルデータバックアップでは、アップストリームクラスターとダウンストリームクラスターの両方がバックアップファイルにアクセスする必要があります。バックアップファイルの保存には[外部ストレージ](/br/backup-and-restore-ストレージs.md)を使用することをお勧めします。この例では、Minioを使用してS3互換のストレージサービスをシミュレートしています。 ```shell wget https://dl.min.io/server/minio/release/linux-amd64/minio @@ -75,7 +75,7 @@ summary: プライマリクラスタからセカンダリクラスタへデー # Configure access-key access-screct-id to access minio export HOST_IP='172.16.6.123' # Replace it with the IP address of your upstream cluster export MINIO_ROOT_USER='minio' - export MINIO_ROOT_PASSWORD='miniostorage' + export MINIO_ROOT_PASSWORD='minioストレージ' # Create the redo and backup directories. `backup` and `redo` are bucket names. mkdir -p data/redo mkdir -p data/backup @@ -87,13 +87,13 @@ summary: プライマリクラスタからセカンダリクラスタへデー - エンドポイント: `http://${HOST_IP}:6060/` - アクセスキー: `minio` - - 秘密アクセスキー: `miniostorage` + - 秘密アクセスキー: `minioストレージ` - バケット: `redo` リンクは以下のとおりです。 ```shell - s3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://${HOST_IP}:6060&force-path-style=true + s3://backup?access-key=minio&secret-access-key=minioストレージ&endpoint=http://${HOST_IP}:6060&force-path-style=true ``` ## ステップ2. 全データを移行する {#step-2-migrate-full-data} @@ -103,12 +103,12 @@ summary: プライマリクラスタからセカンダリクラスタへデー > **注記：** > > - `BACKUP`および`RESTORE` SQL ステートメントは実験的です。本番環境での使用は推奨されません。予告なく変更または削除される場合があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tidb/issues)を報告してください。 -> - 本番のクラスタでは、GCを無効にした状態でバックアップを実行すると、クラスタのパフォーマンスに影響を与える可能性があります。パフォーマンスの低下を避けるため、データのバックアップはピーク時以外の時間帯に行い、RATE_LIMITを適切な値に設定することをお勧めします。 -> - アップストリームとダウンストリームのクラスタのバージョンが異なる場合は、 [BR互換性](/br/backup-and-restore-overview.md#some-tips)確認してください。このドキュメントでは、アップストリームとダウンストリームのクラスタのバージョンが同じであることを前提としています。 +> - 本番のクラスターでは、GCを無効にした状態でバックアップを実行すると、クラスターのパフォーマンスに影響を与える可能性があります。パフォーマンスの低下を避けるため、データのバックアップはピーク時以外の時間帯に行い、RATE_LIMITを適切な値に設定することをお勧めします。 +> - アップストリームとダウンストリームのクラスターのバージョンが異なる場合は、 [BR互換性](/br/backup-and-restore-overview.md#some-tips)確認してください。このドキュメントでは、アップストリームとダウンストリームのクラスターのバージョンが同じであることを前提としています。 1. GCを無効にする。 - 増分移行中に新しく書き込まれたデータが削除されないようにするには、バックアップ前にアップストリームクラスタのガベージコレクション（GC）を無効にする必要があります。こうすることで、履歴データが削除されるのを防ぐことができます。 + 増分移行中に新しく書き込まれたデータが削除されないようにするには、バックアップ前にアップストリームクラスターのガベージコレクション（GC）を無効にする必要があります。こうすることで、履歴データが削除されるのを防ぐことができます。 GCを無効にするには、以下のコマンドを実行してください。 @@ -136,7 +136,7 @@ summary: プライマリクラスタからセカンダリクラスタへデー 上流クラスターで`BACKUP`ステートメントを実行してデータをバックアップします。 ```sql - MySQL [(none)]> BACKUP DATABASE * TO 's3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://${HOST_IP}:6060&force-path-style=true' RATE_LIMIT = 120 MB/SECOND; + MySQL [(none)]> BACKUP DATABASE * TO 's3://backup?access-key=minio&secret-access-key=minioストレージ&endpoint=http://${HOST_IP}:6060&force-path-style=true' RATE_LIMIT = 120 MB/SECOND; ``` +----------------------+----------+--------------------+---------------------+---------------------+ @@ -150,10 +150,10 @@ summary: プライマリクラスタからセカンダリクラスタへデー 3. データを復元します。 - ダウンストリームクラスタで`RESTORE`コマンドを実行してデータを復元します。 + ダウンストリームクラスターで`RESTORE`コマンドを実行してデータを復元します。 ```sql - mysql> RESTORE DATABASE * FROM 's3://backup?access-key=minio&secret-access-key=miniostorage&endpoint=http://${HOST_IP}:6060&force-path-style=true'; + mysql> RESTORE DATABASE * FROM 's3://backup?access-key=minio&secret-access-key=minioストレージ&endpoint=http://${HOST_IP}:6060&force-path-style=true'; ``` +----------------------+----------+--------------------+---------------------+---------------------+ @@ -165,13 +165,13 @@ summary: プライマリクラスタからセカンダリクラスタへデー 4. （オプション）データの検証。 - [同期差分検査ツール](/sync-diff-inspector/sync-diff-inspector-overview.md)を使用して、特定の時刻におけるアップストリームとダウンストリーム間のデータの一貫性を確認します。前述の`BACKUP`出力は、アップストリーム クラスタが 431434047157698561 にバックアップを完了したことを示しています。前述の`RESTORE`出力は、ダウンストリームが 431434141450371074 にリストアを完了したことを示しています。 + [同期差分検査ツール](/sync-diff-inspector/sync-diff-inspector-overview.md)を使用して、特定の時刻におけるアップストリームとダウンストリーム間のデータの一貫性を確認します。前述の`BACKUP`出力は、アップストリーム クラスターが 431434047157698561 にバックアップを完了したことを示しています。前述の`RESTORE`出力は、ダウンストリームが 431434141450371074 にリストアを完了したことを示しています。 ```shell sync_diff_inspector -C ./config.yaml ``` - sync-diff-inspector の設定方法の詳細については、 [コンフィグレーションファイルの説明](/sync-diff-inspector/sync-diff-inspector-overview.md#configuration-file-description)参照してください。このドキュメントでは、構成は次のようになります。 + sync-diff-inspector の設定方法の詳細については、 [設定ファイルの説明](/sync-diff-inspector/sync-diff-inspector-overview.md#configuration-file-description)参照してください。このドキュメントでは、構成は次のようになります。 ```shell # Diff Configuration. @@ -218,7 +218,7 @@ summary: プライマリクラスタからセカンダリクラスタへデー # Consistency level, eventual means enabling consistent replication level = "eventual" # Use S3 to store redo logs. Other options are local and nfs. - storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=http://172.16.6.125:6060&force-path-style=true" + ストレージ = "s3://redo?access-key=minio&secret-access-key=minioストレージ&endpoint=http://172.16.6.125:6060&force-path-style=true" ``` アップストリームクラスターで、次のコマンドを実行して、アップストリームクラスターからダウンストリームクラスターへの変更フィードを作成します。 @@ -229,8 +229,8 @@ summary: プライマリクラスタからセカンダリクラスタへデー このコマンドにおけるパラメータは以下のとおりです。 - - `--server` : TiCDCクラスタ内の任意のノードのIPアドレス - - `--sink-uri` : ダウンストリームクラスタのURI + - `--server` : TiCDCクラスター内の任意のノードのIPアドレス + - `--sink-uri` : ダウンストリームクラスターのURI - `--start-ts` : 変更フィードの開始タイムスタンプ。バックアップ時間 (または[ステップ2. 全データを移行する](#step-2-migrate-full-data)) チェンジフィード構成の詳細については、 [TiCDC Changefeedフィード構成](/ticdc/ticdc-changefeed-config.md)参照してください。 @@ -262,40 +262,40 @@ summary: プライマリクラスタからセカンダリクラスタへデー ## ステップ4．上流クラスターで災害をシミュレーションする {#step-4-simulate-a-disaster-in-the-upstream-cluster} -上流クラスタが実行中に、致命的な障害を発生させます。たとえば、Ctrl+C を押して tiup プレイグラウンド プロセスを終了させることができます。 +上流クラスターが実行中に、致命的な障害を発生させます。たとえば、Ctrl+C を押して tiup プレイグラウンド プロセスを終了させることができます。 ## ステップ5．リドゥログを使用してデータの一貫性を確保する {#step-5-use-redo-log-to-ensure-data-consistency} 通常、TiCDCはスループットを向上させるために、トランザクションをダウンストリームに同時に書き込みます。変更フィードが予期せず中断された場合、ダウンストリームにはアップストリームと同じ最新データが存在しない可能性があります。この不整合に対処するには、次のコマンドを実行して、ダウンストリームのデータがアップストリームのデータと整合していることを確認してください。 ```shell -tiup cdc redo apply --storage "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=http://172.16.6.123:6060&force-path-style=true" --tmp-dir /tmp/redo --sink-uri "mysql://root:@172.16.6.124:4000" +tiup cdc redo apply --ストレージ "s3://redo?access-key=minio&secret-access-key=minioストレージ&endpoint=http://172.16.6.123:6060&force-path-style=true" --tmp-dir /tmp/redo --sink-uri "mysql://root:@172.16.6.124:4000" ``` -- `--storage` : S3 内のリドゥログの場所と認証情報 +- `--ストレージ` : S3 内のリドゥログの場所と認証情報 - `--tmp-dir` : S3からダウンロードしたリドゥログのキャッシュディレクトリ -- `--sink-uri` : ダウンストリームクラスタのURI +- `--sink-uri` : ダウンストリームクラスターのURI -## ステップ6．プライマリクラスタとそのサービスを復旧する {#step-6-recover-the-primary-cluster-and-its-services} +## ステップ6．プライマリクラスターとそのサービスを復旧する {#step-6-recover-the-primary-cluster-and-its-services} 前の手順の後、下流（セカンダリ）クラスターには、特定の時点において上流（プライマリ）クラスターと整合性のあるデータが格納されます。データの信頼性を確保するためには、新しいプライマリクラスターとセカンダリクラスターを設定する必要があります。 -1. 新しいプライマリクラスタとして、ノードA上に新しいTiDBクラスタをデプロイ。 +1. 新しいプライマリクラスターとして、ノードA上に新しいTiDBクラスターをデプロイ。 ```shell tiup --tag upstream playground v5.4.0 --host 0.0.0.0 --db 1 --pd 1 --kv 1 --tiflash 0 --ticdc 1 ``` -2. BRを使用して、セカンダリクラスタからプライマリクラスタへデータを完全にバックアップおよび復元します。 +2. BRを使用して、セカンダリクラスターからプライマリクラスターへデータを完全にバックアップおよび復元します。 ```shell # Back up full data of the secondary cluster - tiup br --pd http://172.16.6.124:2379 backup full --storage ./backup + tiup br --pd http://172.16.6.124:2379 backup full --ストレージ ./backup # Restore full data of the secondary cluster - tiup br --pd http://172.16.6.123:2379 restore full --storage ./backup + tiup br --pd http://172.16.6.123:2379 restore full --ストレージ ./backup ``` -3. プライマリクラスタからセカンダリクラスタへデータをバックアップするための新しい変更フィードを作成します。 +3. プライマリクラスターからセカンダリクラスターへデータをバックアップするための新しい変更フィードを作成します。 ```shell # Create a changefeed diff --git a/resources/doc-templates/template-concept.md b/resources/doc-templates/template-concept.md index 78a197443bbf9..abc72cf56531c 100644 --- a/resources/doc-templates/template-concept.md +++ b/resources/doc-templates/template-concept.md @@ -67,6 +67,6 @@ xxx 次のような、ユーザーが興味を持ちそうなドキュメントを直接提供することもできます。 -- [HTAPを探索する](/explore-htap.md) +- [HTAP入門](/explore-htap.md) - [TiCDC よくある質問](/ticdc/ticdc-faq.md) - [TiCDC用語集](/ticdc/ticdc-glossary.md) diff --git a/resources/doc-templates/template-new-feature.md b/resources/doc-templates/template-new-feature.md index bd28ea204da6e..5cf0df8436b1c 100644 --- a/resources/doc-templates/template-new-feature.md +++ b/resources/doc-templates/template-new-feature.md @@ -109,11 +109,11 @@ FAQ が多数ある場合は、この機能用に個別のFAQドキュメント このセクションでは、ユーザーが読みたいと思う可能性のある次のような関連ドキュメントを提供します。 -- TiFlash のバージョン、重要なログ、システム テーブルを表示するには、 [TiFlashクラスタを管理](/tiflash/maintain-tiflash.md)参照してください。 +- TiFlash のバージョン、重要なログ、システム テーブルを表示するには、 [TiFlashクラスターを管理](/tiflash/maintain-tiflash.md)参照してください。 - TiFlashノードを削除する必要がある場合は、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)参照してください。 次のような、ユーザーが興味を持ちそうなドキュメントを直接提供することもできます。 -- [HTAPを探索する](/explore-htap.md) +- [HTAP入門](/explore-htap.md) - [TiFlashアーキテクチャ](/tiflash/tiflash-overview.md#architecture) - [TiFlashクラスターを管理](/tiflash/maintain-tiflash.md) diff --git a/resources/doc-templates/template-reference.md b/resources/doc-templates/template-reference.md index ba7f299462dec..3b658de660617 100644 --- a/resources/doc-templates/template-reference.md +++ b/resources/doc-templates/template-reference.md @@ -7,7 +7,7 @@ summary: このドキュメントを115～145文字で要約してください > このテンプレートについて: > -> - このドキュメントは、コマンド、パラメータ、設定オプションなどを含むリファレンストピックのテンプレートです。このテンプレートをそのままコピーして使用し、不要な注釈を削除してください。このタイプのドキュメントの例： [TiDBクラスタアラートルール](/alert-rules.md) +> - このドキュメントは、コマンド、パラメータ、設定オプションなどを含むリファレンストピックのテンプレートです。このテンプレートをそのままコピーして使用し、不要な注釈を削除してください。このタイプのドキュメントの例： [TiDBクラスターアラートルール](/alert-rules.md) > - 新しいドキュメントの場合は、 `TOC.md`ファイル内の適切な場所へのリンクを追加してください (ユーザーが目次内でこのドキュメントを探す可能性が最も高い場所を考慮してください)。 > - ドキュメント内の見出しはレベルをスキップできないため、レベル 5 の見出しの使用は避けてください。 diff --git a/resources/doc-templates/template-task.md b/resources/doc-templates/template-task.md index eaacdee6f93fd..486fd71e040ef 100644 --- a/resources/doc-templates/template-task.md +++ b/resources/doc-templates/template-task.md @@ -7,7 +7,7 @@ summary: このドキュメントを115～145文字で要約してください > このテンプレートについて: > -> - このドキュメントは、タスクトピック用のテンプレートであり、特定のタスクを段階的に実行する方法を説明します。このテンプレートをそのままコピーして使用し、不要な注釈を削除してください。このタイプのドキュメントの例： [TiDBセルフマネージドのクイックスタート](/quick-start-with-tidb.md) +> - このドキュメントは、タスクトピック用のテンプレートであり、特定のタスクを段階的に実行する方法を説明します。このテンプレートをそのままコピーして使用し、不要な注釈を削除してください。このタイプのドキュメントの例： [TiDB Self-Managedのクイックスタート](/quick-start-with-tidb.md) > - 新しいドキュメントの場合は、 `TOC.md`ファイル内の適切な場所へのリンクを追加してください (ユーザーが目次内でこのドキュメントを探す可能性が最も高い場所を考慮してください)。 > - ドキュメント内の見出しはレベルをスキップできないため、レベル 5 の見出しの使用は避けてください。 @@ -117,11 +117,11 @@ summary: このドキュメントを115～145文字で要約してください このセクションでは、ユーザーが読みたいと思う可能性のある次のような関連ドキュメントを提供します。 -- TiFlash のバージョン、重要なログ、システム テーブルを表示するには、 [TiFlashクラスタを管理](/tiflash/maintain-tiflash.md)参照してください。 +- TiFlash のバージョン、重要なログ、システム テーブルを表示するには、 [TiFlashクラスターを管理](/tiflash/maintain-tiflash.md)参照してください。 - TiFlashノードを削除する必要がある場合は、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)参照してください。 次のような、ユーザーが興味を持ちそうなドキュメントを直接提供することもできます。 -- [HTAPを探索する](/explore-htap.md) +- [HTAP入門](/explore-htap.md) - [TiFlashアーキテクチャ](/tiflash/tiflash-overview.md#architecture) - [TiFlashクラスターを管理](/tiflash/maintain-tiflash.md) diff --git a/scale-microservices-using-tiup.md b/scale-microservices-using-tiup.md index 066cdca0c39bf..836d39b8089c4 100644 --- a/scale-microservices-using-tiup.md +++ b/scale-microservices-using-tiup.md @@ -84,7 +84,7 @@ scheduling_servers: 上記のコマンドでは、 - `scale-out.yml`はスケールアウト構成ファイルです。 -- `--user root` 、クラスタのスケールアウトを完了するために、ターゲットマシンに`root`ユーザーとしてログインすることを示します。4 `root`ユーザーは、ターゲットマシンに対して`ssh`と`sudo`権限を持つことが想定されています。または、 `ssh`と`sudo`権限を持つ他のユーザーを使用してデプロイを完了することもできます。 +- `--user root` 、クラスターのスケールアウトを完了するために、ターゲットマシンに`root`ユーザーとしてログインすることを示します。4 `root`ユーザーは、ターゲットマシンに対して`ssh`と`sudo`権限を持つことが想定されています。または、 `ssh`と`sudo`権限を持つ他のユーザーを使用してデプロイを完了することもできます。 - `[-i]`と`[-p]`オプションです。ターゲットマシンへのログインにパスワードを使用しない設定をしている場合は、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。4 `[-i]` 、ターゲットマシンにアクセスできるルートユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。8 `[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 `Scaled cluster out successfully`表示された場合、スケールアウト操作は成功しています。 diff --git a/scale-tidb-using-tiup.md b/scale-tidb-using-tiup.md index 48d1e91de5f7f..2e5439983b81c 100644 --- a/scale-tidb-using-tiup.md +++ b/scale-tidb-using-tiup.md @@ -3,7 +3,7 @@ title: Scale a TiDB Cluster Using TiUP summary: TiUPを使用して TiDB クラスターをスケーリングする方法を学びます。 --- -# TiUPを使用して TiDBクラスタをスケールする {#scale-a-tidb-cluster-using-tiup} +# TiUPを使用して TiDBクラスターをスケールする {#scale-a-tidb-cluster-using-tiup} TiDB クラスターの容量は、オンライン サービスを中断することなく増減できます。 @@ -107,7 +107,7 @@ TiDB クラスターの容量は、オンライン サービスを中断する 上記のコマンドでは、 - `scale-out.yml`はスケールアウト構成ファイルです。 - - `--user root` 、クラスタのスケールアウトを完了するために、ターゲットマシンに`root`ユーザーとしてログインすることを示します。4 `root`ユーザーは、ターゲットマシンに対して`ssh`と`sudo`権限を持つことが想定されています。または、 `ssh`と`sudo`権限を持つ他のユーザーを使用してデプロイを完了することもできます。 + - `--user root` 、クラスターのスケールアウトを完了するために、ターゲットマシンに`root`ユーザーとしてログインすることを示します。4 `root`ユーザーは、ターゲットマシンに対して`ssh`と`sudo`権限を持つことが想定されています。または、 `ssh`と`sudo`権限を持つ他のユーザーを使用してデプロイを完了することもできます。 - `[-i]`と`[-p]`オプションです。ターゲットマシンへのログインをパスワードなしで設定している場合、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。4 `[-i]` 、ターゲットマシンにアクセスできるルートユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。8 `[-p]` 、ユーザーパスワードを対話的に入力するために使用されます。 `Scaled cluster out successfully`表示された場合、スケールアウト操作は成功しています。 diff --git a/schedule-replicas-by-topology-labels.md b/schedule-replicas-by-topology-labels.md index 4ef273417acda..a79f68be432e0 100644 --- a/schedule-replicas-by-topology-labels.md +++ b/schedule-replicas-by-topology-labels.md @@ -156,7 +156,7 @@ TiUPを使用してクラスターをデプロイする場合、 [初期化設 > **注記：** > -> 設定ファイルで`replication.location-labels`設定されていない場合、このトポロジファイルを使用してクラスタをデプロイするとエラーが発生する可能性があります。クラスタをデプロイする前に、設定ファイルで`replication.location-labels`が設定されていることを確認することをお勧めします。 +> 設定ファイルで`replication.location-labels`設定されていない場合、このトポロジファイルを使用してクラスターをデプロイするとエラーが発生する可能性があります。クラスターをデプロイする前に、設定ファイルで`replication.location-labels`が設定されていることを確認することをお勧めします。 ### コマンドラインまたは構成ファイルを使用してクラスターを構成する {#configure-a-cluster-using-command-lines-or-configuration-files} @@ -244,7 +244,7 @@ host = "" `location-labels`が設定されている場合は、PD 設定ファイルで`isolation-level`設定することで、TiKV クラスターのトポロジ分離要件をさらに強化できます。 -上記の手順に従って`location-labels`ゾーン -> ラック -> ホストと設定して 3 層クラスタ トポロジを作成したと仮定すると、 `isolation-level` ～ `zone`次のように設定できます。 +上記の手順に従って`location-labels`ゾーン -> ラック -> ホストと設定して 3 層クラスター トポロジを作成したと仮定すると、 `isolation-level` ～ `zone`次のように設定できます。 ```toml [replication] @@ -257,7 +257,7 @@ PD クラスターがすでに初期化されている場合は、pd-ctl ツー pd-ctl config set isolation-level zone ``` -`location-level`設定は文字列の配列であり、キー`location-labels`に対応している必要があります。このパラメータは、TiKVトポロジクラスタにおける最小および必須の分離レベル要件を制限します。 +`location-level`設定は文字列の配列であり、キー`location-labels`に対応している必要があります。このパラメータは、TiKVトポロジクラスターにおける最小および必須の分離レベル要件を制限します。 > **注記：** > @@ -269,9 +269,9 @@ PD はラベルレイヤーに従ってレプリカをスケジュールし、 前のセクションのトポロジを例に挙げます。 -クラスタのレプリカ数が3（ `max-replicas=3` ）であると仮定します。合計3つのゾーンがあるため、PDは各リージョンの3つのレプリカがそれぞれz1、z2、z3に配置されるように保証します。これにより、1つのゾーンに障害が発生してもTiDBクラスタは引き続き利用可能です。 +クラスターのレプリカ数が3（ `max-replicas=3` ）であると仮定します。合計3つのゾーンがあるため、PDは各リージョンの3つのレプリカがそれぞれz1、z2、z3に配置されるように保証します。これにより、1つのゾーンに障害が発生してもTiDBクラスターは引き続き利用可能です。 -次に、クラスタレプリカの数が5（ `max-replicas=5` ）であると仮定します。ゾーンは合計3つしかないため、PDはゾーンレベルで各レプリカの分離を保証することができません。この場合、PDスケジューラはホストレベルでレプリカの分離を保証します。つまり、リージョンの複数のレプリカが同じゾーンに分散されていても、同じホスト上には分散されていない可能性があります。 +次に、クラスターレプリカの数が5（ `max-replicas=5` ）であると仮定します。ゾーンは合計3つしかないため、PDはゾーンレベルで各レプリカの分離を保証することができません。この場合、PDスケジューラはホストレベルでレプリカの分離を保証します。つまり、リージョンの複数のレプリカが同じゾーンに分散されていても、同じホスト上には分散されていない可能性があります。 5 つのレプリカ構成の場合、z3 に障害が発生するか、z3 全体が分離され、一定期間 ( `max-store-down-time`で制御) 後に回復できない場合、PD はスケジュールによって 5 つのレプリカを構成します。この時点では、使用できるホストは 4 つだけです。つまり、ホストレベルの分離は保証されず、複数のレプリカが同じホストにスケジュールされる可能性があります。ただし、 `isolation-level`値が空のままではなく`zone`に設定されている場合、これはリージョンレプリカの最小の物理的な分離要件を指定します。つまり、PD は同じリージョンのレプリカが異なるゾーンに分散されていることを保証します。この分離制限に従っても、複数のレプリカの`max-replicas`の要件が満たされない場合でも、PD は対応するスケジュールを実行しません。 diff --git a/scheduling-configuration-file.md b/scheduling-configuration-file.md index a78cb52628a93..7fee156d2bfaa 100644 --- a/scheduling-configuration-file.md +++ b/scheduling-configuration-file.md @@ -3,7 +3,7 @@ title: Scheduling Configuration File summary: スケジューリング構成ファイルには、ノード名、データ パス、ノード URL などの複数の構成項目が含まれています。 --- -# スケジュールコンフィグレーションファイル {#scheduling-configuration-file} +# スケジュール設定ファイル {#scheduling-configuration-file} @@ -50,7 +50,7 @@ summary: スケジューリング構成ファイルには、ノード名、デ ## 安全 {#security} -セキュリティ関連のコンフィグレーション項目 +セキュリティ関連の設定項目 ### cacert-path {#code-cacert-path-code} @@ -75,7 +75,7 @@ summary: スケジューリング構成ファイルには、ノード名、デ ## ログ {#log} -ログに関するコンフィグレーション項目。 +ログに関する設定項目。 ### level {#code-level-code} @@ -96,7 +96,7 @@ summary: スケジューリング構成ファイルには、ノード名、デ ## ログファイル {#log-file} -ログファイルに関連するコンフィグレーション項目 +ログファイルに関連する設定項目 ### max-size {#code-max-size-code} @@ -119,7 +119,7 @@ summary: スケジューリング構成ファイルには、ノード名、デ ## メトリック {#metric} -監視に関連するコンフィグレーション項目 +監視に関連する設定項目 ### interval {#code-interval-code} diff --git a/schema-cache.md b/schema-cache.md index 2427adbd46747..ad3468be14fa5 100644 --- a/schema-cache.md +++ b/schema-cache.md @@ -41,9 +41,9 @@ summary: TiDBは、スキーマ情報に対してLRU（Least Recently Used：最 - 単一クラスター内のテーブル数は300万を超えることはできません。 -- 単一クラスタ内のテーブル数が 300,000 を超える場合は、 [`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800)の値を`0`に設定しないでください。TiDB のメモリ不足 (OOM) を引き起こす可能性があります。 +- 単一クラスター内のテーブル数が 300,000 を超える場合は、 [`tidb_schema_cache_size`](/system-variables.md#tidb_schema_cache_size-new-in-v800)の値を`0`に設定しないでください。TiDB のメモリ不足 (OOM) を引き起こす可能性があります。 -- 外部キーを使用すると、クラスタ環境におけるDDL操作の実行時間が長くなる可能性があります。 +- 外部キーを使用すると、クラスター環境におけるDDL操作の実行時間が長くなる可能性があります。 - テーブルへのアクセスが不規則な場合（例えば、あるテーブル群が時刻1にアクセスされ、別のテーブル群が時刻2にアクセスされる場合など）、 `tidb_schema_cache_size`の値が小さいと、スキーマ情報が頻繁に削除およびキャッシュされ、パフォーマンスの変動につながる可能性があります。この機能は、頻繁にアクセスされるデータベースやテーブルが比較的固定されているシナリオに適しています。 diff --git a/shard-row-id-bits.md b/shard-row-id-bits.md index 7d8de85c057c1..fad01e3d121ab 100644 --- a/shard-row-id-bits.md +++ b/shard-row-id-bits.md @@ -9,7 +9,7 @@ summary: SHARD_ROW_ID_BITS属性について学びましょう。 ## コンセプト {#concept} -クラスタ化されていないプライマリキーまたはプライマリキーのないテーブルの場合、TiDB は自動的に生成された[`_tidb_rowid`](/tidb-rowid.md)暗黙の自動インクリメント行 ID として使用します。多数の`INSERT`操作が実行されると、データは単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 +クラスター化されていないプライマリキーまたはプライマリキーのないテーブルの場合、TiDB は自動的に生成された[`_tidb_rowid`](/tidb-rowid.md)暗黙の自動インクリメント行 ID として使用します。多数の`INSERT`操作が実行されると、データは単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 ホットスポットの問題を軽減するには、 `SHARD_ROW_ID_BITS`設定できます。行 ID は分散しており、データは複数の異なるリージョンに書き込まれます。 @@ -23,19 +23,19 @@ summary: SHARD_ROW_ID_BITS属性について学びましょう。 | ------ | ------ | ------------ | | 1ビット | `S`ビット | `63-S`ビット | -- 自動インクリメントビットの値はTiKVに格納され、順次割り当てられます。値が割り当てられるたびに、次の値は1ずつ増加します。自動インクリメントビットの値が使い果たされると（つまり、最大値に達すると）、以降の自動割り当てはエラー`Failed to read auto-increment value from storage engine`で失敗します。 +- 自動インクリメントビットの値はTiKVに格納され、順次割り当てられます。値が割り当てられるたびに、次の値は1ずつ増加します。自動インクリメントビットの値が使い果たされると（つまり、最大値に達すると）、以降の自動割り当てはエラー`Failed to read auto-increment value from ストレージ engine`で失敗します。 - 値の範囲は`_tidb_rowid`です。最終的に生成される値の最大ビット数は、シャードビット + 自動インクリメントビットなので、最大値は`(2^63)-1`です。 > **警告：** > -> `_tidb_rowid`は TiDB によって暗黙的に割り当てられる内部行 ID です。すべての場合においてグローバルに一意であると想定しないでください。クラスタ化インデックスを使用しないパーティション テーブルの場合、 `ALTER TABLE ... EXCHANGE PARTITION`異なるパーティションに同じ`_tidb_rowid`値を残す可能性があります。詳細については、 [`_tidb_rowid`](/tidb-rowid.md)参照してください。 +> `_tidb_rowid`は TiDB によって暗黙的に割り当てられる内部行 ID です。すべての場合においてグローバルに一意であると想定しないでください。クラスター化インデックスを使用しないパーティション テーブルの場合、 `ALTER TABLE ... EXCHANGE PARTITION`異なるパーティションに同じ`_tidb_rowid`値を残す可能性があります。詳細については、 [`_tidb_rowid`](/tidb-rowid.md)参照してください。 > **注記：** > > シャードビットの選択（ `S` ）： > > - `_tidb_rowid`の合計ビット数は64であるため、シャードビットの数は自動インクリメントビットの数に影響します。シャードビットの数が増えると自動インクリメントビットの数は減り、その逆もまた然りです。したがって、自動インクリメント値のランダム性と利用可能な自動インクリメント領域のバランスを取る必要があります。 -> - ベストプラクティスは、シャードビットを`log(2, x)`に設定することです。ここで、 `x`クラスタ内のTiKVノードの数です。たとえば、TiDBクラスタに16個のTiKVノードがある場合、シャードビットを`log(2, 16)` （ `4`に相当）に設定することをお勧めします。すべてのリージョンが各TiKVノードに均等にスケジュールされた後、バルク書き込みの負荷をさまざまなTiKVノードに均等に分散して、リソース利用率を最大化できます。 +> - ベストプラクティスは、シャードビットを`log(2, x)`に設定することです。ここで、 `x`クラスター内のTiKVノードの数です。たとえば、TiDBクラスターに16個のTiKVノードがある場合、シャードビットを`log(2, 16)` （ `4`に相当）に設定することをお勧めします。すべてのリージョンが各TiKVノードに均等にスケジュールされた後、バルク書き込みの負荷をさまざまなTiKVノードに均等に分散して、リソース利用率を最大化できます。 diff --git a/smooth-upgrade-tidb.md b/smooth-upgrade-tidb.md index 6f135ae66cb90..f9424fe25c32d 100644 --- a/smooth-upgrade-tidb.md +++ b/smooth-upgrade-tidb.md @@ -49,7 +49,7 @@ These limitations can be summarized as that you need to ensure that there are no #### TiUPを使用してアップグレードする {#use-tiup-to-upgrade} -v1.14.0以降、 TiUPはこの機能を自動的にサポートします。つまり、 `tiup cluster upgrade`コマンドを使用してTiDBクラスタを直接アップグレードできます。3 `tiup cluster patch`は現在サポートされていないことに注意してください。 +v1.14.0以降、 TiUPはこの機能を自動的にサポートします。つまり、 `tiup cluster upgrade`コマンドを使用してTiDBクラスターを直接アップグレードできます。3 `tiup cluster patch`は現在サポートされていないことに注意してください。 #### TiDB Operatorを使用してアップグレードする {#use-tidb-operator-to-upgrade} @@ -81,7 +81,7 @@ You can take the following steps to upgrade TiDB manually or by using a script: - アップグレードする前に、次の制限を考慮してください。 - - クラスタ内にキャンセル中のDDLジョブがある場合、つまり実行中のDDLジョブがユーザーによってキャンセルされている場合、キャンセル中のジョブは一時停止できないため、TiDBはジョブのキャンセルを再試行します。再試行が失敗した場合はエラーが報告され、アップグレードは終了します。 + - クラスター内にキャンセル中のDDLジョブがある場合、つまり実行中のDDLジョブがユーザーによってキャンセルされている場合、キャンセル中のジョブは一時停止できないため、TiDBはジョブのキャンセルを再試行します。再試行が失敗した場合はエラーが報告され、アップグレードは終了します。 - 現在ご使用の TiDB バージョンが v8.1.0 より前で、TiDB Distributed eXecution Framework (DXF) が有効になっている場合は、 [`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)を`OFF`に設定して無効にしてください。実行中の分散タスク`ADD INDEX`と`IMPORT INTO`すべて完了していることを確認してください。または、これらのタスクをキャンセルし、アップグレードが完了するまで待ってから再開することもできます。そうしないと、アップグレード中の`ADD INDEX`操作によってデータインデックスの不整合が発生する可能性があります。現在ご使用の TiDB バージョンが v8.1.0 以降の場合は、DXF を無効にする必要はなく、この制限は無視してかまいません。 - TiUPを使用して TiDB をアップグレードするシナリオでは、 TiUPアップグレードにはタイムアウト期間があるため、アップグレード前にクラスターのキューで待機している DDL ジョブが多数 (300 を超える) ある場合、アップグレードが失敗する可能性があります。 diff --git a/sql-mode.md b/sql-mode.md index 6ac7bb0f1c631..2e933f20f67c7 100644 --- a/sql-mode.md +++ b/sql-mode.md @@ -36,7 +36,7 @@ TiDB の起動後、 `SET [ SESSION | GLOBAL ] sql_mode='modes'`ステートメ | `NO_TABLE_OPTIONS` | `SHOW CREATE TABLE`ステートメントを使用する場合、 `ENGINE`などの MySQL 固有の構文はエクスポートされません。mysqldump を使用してデータベースの種類を移行する場合は、このオプションを検討してください。（構文のみサポート） | | `NO_AUTO_VALUE_ON_ZERO` | このモードが有効になっている場合、 [`AUTO_INCREMENT`](/auto-increment.md)列に渡された値が`0`または特定の値である場合、システムはこの値を直接この列に書き込みます。 `NULL`が渡された場合、システムは自動的に次のシリアル番号を生成します。（完全サポート） | | `NO_BACKSLASH_ESCAPES` | このモードが有効になっている場合、 `\`バックスラッシュ記号はそれ自体のみを表します。（完全サポート） | -| `STRICT_TRANS_TABLES` | トランザクションstorageエンジンの厳格モードを有効にし、無効な値が挿入された後にステートメント全体をロールバックします。（完全サポート） | +| `STRICT_TRANS_TABLES` | トランザクションストレージエンジンの厳格モードを有効にし、無効な値が挿入された後にステートメント全体をロールバックします。（完全サポート） | | `STRICT_ALL_TABLES` | トランザクションテーブルの場合、無効な値が挿入された後にトランザクションステートメント全体をロールバックします。（完全サポート） | | `NO_ZERO_IN_DATE` | 厳格モードでは、月または日の一部が`0`である日付は受け入れられません。 `IGNORE`オプションを使用すると、TiDB は同様の日付に対して '0000-00-00' を挿入します。非厳格モードでは、この日付は受け入れられますが、警告が表示されます。（完全サポート） | | `NO_ZERO_DATE` | 厳格モードでは、「0000-00-00」を有効な日付として使用しません。ただし`IGNORE`オプションを使用すれば、ゼロの日付を挿入することは可能です。非厳格モードでは、この日付は受け入れられますが、警告が表示されます。（完全サポート） | @@ -44,7 +44,7 @@ TiDB の起動後、 `SET [ SESSION | GLOBAL ] sql_mode='modes'`ステートメ | `ERROR_FOR_DIVISION_BY_ZERO` | このモードが有効になっている場合、システムはデータ変更操作（ `0`または`INSERT`で`UPDATE`による除算を処理する際にエラーを返します。
    このモードが有効になっていない場合、システムは警告を返し、代わりに`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`として解析されます。（完全サポート） | -| `NO_ENGINE_SUBSTITUTION` | 必要なstorageエンジンが無効化されているかコンパイルされていない場合、storageエンジンの自動置換を防止します。（構文サポートのみ） | +| `NO_ENGINE_SUBSTITUTION` | 必要なストレージエンジンが無効化されているかコンパイルされていない場合、ストレージエンジンの自動置換を防止します。（構文サポートのみ） | | `PAD_CHAR_TO_FULL_LENGTH` | このモードが有効な場合、システムは`CHAR`タイプの末尾のスペースをトリミングしません。 (構文サポートのみ。このモードは[MySQL 8.0で非推奨になりました](https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html#sqlmode_pad_char_to_full_length)。) | | `REAL_AS_FLOAT` | `REAL` `FLOAT`の同義語として扱い、 `DOUBLE`の同義語としては扱いません（完全サポート）。 | | `POSTGRESQL` | `PIPES_AS_CONCAT` 、 `ANSI_QUOTES` 、 `IGNORE_SPACE` 、 `NO_KEY_OPTIONS` 、 `NO_TABLE_OPTIONS` 、 `NO_FIELD_OPTIONS` （構文のみサポート）。 | diff --git a/sql-plan-management.md b/sql-plan-management.md index 5fc6e0d3855a1..fbbe916b961ac 100644 --- a/sql-plan-management.md +++ b/sql-plan-management.md @@ -657,7 +657,7 @@ SHOW GLOBAL BINDINGS; #### 使用法 {#usage} -システムテーブル`mysql.capture_plan_baselines_blacklist`にフィルタリング条件を挿入します。すると、フィルタリング条件はクラスタ全体に即座に反映されます。 +システムテーブル`mysql.capture_plan_baselines_blacklist`にフィルタリング条件を挿入します。すると、フィルタリング条件はクラスター全体に即座に反映されます。 ```sql -- Filter by table name @@ -804,11 +804,11 @@ CREATE GLOBAL BINDING for SELECT * FROM t WHERE a < 100 AND b < 100 USING SELECT | `read_consistent_replica` | テーブルの読み取り時にFollower Read を強制的に有効にするかどうか。 | | `max_execution_time` | クエリの最長時間。 | -- `read_from_storage`は、テーブル読み取り時に TiKV からデータを読み取るかTiFlashからデータを読み取るかを指定する特別なヒントです。TiDB は分離読み取りを提供するため、分離条件が変化すると、このヒントは進化型実行プランに大きな影響を与えます。したがって、最初に作成されたバインディングにこのヒントが存在する場合、TiDB はすべての進化型バインディングを無視します。 +- `read_from_ストレージ`は、テーブル読み取り時に TiKV からデータを読み取るかTiFlashからデータを読み取るかを指定する特別なヒントです。TiDB は分離読み取りを提供するため、分離条件が変化すると、このヒントは進化型実行プランに大きな影響を与えます。したがって、最初に作成されたバインディングにこのヒントが存在する場合、TiDB はすべての進化型バインディングを無視します。 ## アップグレードチェックリスト {#upgrade-checklist} -クラスタのアップグレード中に、SQL Plan Management (SPM) によって互換性の問題が発生し、アップグレードが失敗する可能性があります。アップグレードを成功させるには、アップグレードの事前チェックに以下の項目を含める必要があります。 +クラスターのアップグレード中に、SQL Plan Management (SPM) によって互換性の問題が発生し、アップグレードが失敗する可能性があります。アップグレードを成功させるには、アップグレードの事前チェックに以下の項目を含める必要があります。 - v5.2.0より前のバージョン（v4.0、v5.0、v5.1）から現在のバージョンにアップグレードする場合は、アップグレード前に`tidb_evolve_plan_baselines`無効になっていることを確認してください。この変数を無効にするには、以下の手順を実行してください。 diff --git a/sql-plan-replayer.md b/sql-plan-replayer.md index bd448ecbaec20..d7c21b6e9c6b5 100644 --- a/sql-plan-replayer.md +++ b/sql-plan-replayer.md @@ -3,18 +3,18 @@ title: Use PLAN REPLAYER to Save and Restore the On-Site Information of a Cluste summary: PLAN REPLAYER を使用してクラスターのオンサイト情報を保存および復元する方法を学びます。 --- -# PLAN REPLAYERを使用してクラスタのオンサイト情報を保存および復元する {#use-plan-replayer-to-save-and-restore-the-on-site-information-of-a-cluster} +# PLAN REPLAYERを使用してクラスターのオンサイト情報を保存および復元する {#use-plan-replayer-to-save-and-restore-the-on-site-information-of-a-cluster} -TiDB クラスタの問題を特定してトラブルシューティングする際には、システム情報と実行計画を提供する必要があることがよくあります。より便利かつ効率的に情報を取得し、クラスタの問題をトラブルシューティングできるよう、TiDB v5.3.0 では`PLAN REPLAYER`コマンドが導入されました。このコマンドを使用すると、クラスタのオンサイト情報を簡単に保存・復元できるため、トラブルシューティングの効率が向上し、問題を管理用にアーカイブ化することも容易になります。 +TiDB クラスターの問題を特定してトラブルシューティングする際には、システム情報と実行計画を提供する必要があることがよくあります。より便利かつ効率的に情報を取得し、クラスターの問題をトラブルシューティングできるよう、TiDB v5.3.0 では`PLAN REPLAYER`コマンドが導入されました。このコマンドを使用すると、クラスターのオンサイト情報を簡単に保存・復元できるため、トラブルシューティングの効率が向上し、問題を管理用にアーカイブ化することも容易になります。 `PLAN REPLAYER`の特徴は以下のとおりです。 -- オンサイトトラブルシューティング時の TiDB クラスターの情報を ZIP 形式のファイルにエクスポートしてstorage。 -- 別のTiDBクラスタからエクスポートされたZIP形式のファイルをクラスタにインポートします。このファイルには、オンサイトトラブルシューティング時の後者のTiDBクラスタの情報が含まれています。 +- オンサイトトラブルシューティング時の TiDB クラスターの情報を ZIP 形式のファイルにエクスポートしてストレージ。 +- 別のTiDBクラスターからエクスポートされたZIP形式のファイルをクラスターにインポートします。このファイルには、オンサイトトラブルシューティング時の後者のTiDBクラスターの情報が含まれています。 ## PLAN REPLAYERを使用してクラスター情報をエクスポートします {#use-code-plan-replayer-code-to-export-cluster-information} -`PLAN REPLAYER`使用すると、TiDBクラスタのオンサイト情報を保存できます。エクスポートインターフェースは次のとおりです。 +`PLAN REPLAYER`使用すると、TiDBクラスターのオンサイト情報を保存できます。エクスポートインターフェースは次のとおりです。 ```sql PLAN REPLAYER DUMP [WITH STATS AS OF TIMESTAMP expression] EXPLAIN [ANALYZE] sql-statement; @@ -56,7 +56,7 @@ plan replayer dump with stats as of timestamp '442012134592479233' explain selec > **注記：** > -> `ZIP`ファイルはTiDBクラスタに最大1時間保存されます。1時間経過すると、TiDBによって削除されます。 +> `ZIP`ファイルはTiDBクラスターに最大1時間保存されます。1時間経過すると、TiDBによって削除されます。 ```sql MySQL [test]> plan replayer dump explain select * from t; @@ -115,7 +115,7 @@ SELECT @@tidb_last_plan_replayer_token; http://${tidb-server-ip}:${tidb-server-status-port}/plan_replayer/dump/${file_token} ``` -`${tidb-server-ip}:${tidb-server-status-port}`はクラスタ内の任意のTiDBサーバーのアドレスです。例： +`${tidb-server-ip}:${tidb-server-status-port}`はクラスター内の任意のTiDBサーバーのアドレスです。例： ```shell curl http://127.0.0.1:10080/plan_replayer/dump/replayer_JOGvpu4t7dssySqJfTtS4A==_1635750890568691080.zip > plan_replayer.zip @@ -127,7 +127,7 @@ curl http://127.0.0.1:10080/plan_replayer/dump/replayer_JOGvpu4t7dssySqJfTtS4A== > > TiDB クラスターのオンサイト情報を別のクラスターにインポートすると、後者のクラスターの TiDB セッション変数、SQL バインディング、テーブル スキーマ、および統計が変更されます。 -`PLAN REPLAYER`を使用してエクスポートされた既存の`ZIP`ファイルがあれば、 `PLAN REPLAYER`インポートインターフェースを使用して、クラスタのオンサイト情報を他の TiDB クラスタに復元できます。構文は次のとおりです。 +`PLAN REPLAYER`を使用してエクスポートされた既存の`ZIP`ファイルがあれば、 `PLAN REPLAYER`インポートインターフェースを使用して、クラスターのオンサイト情報を他の TiDB クラスターに復元できます。構文は次のとおりです。 ```sql PLAN REPLAYER LOAD 'file_name'; @@ -151,7 +151,7 @@ PLAN REPLAYER LOAD 'plan_replayer.zip'; set @@global.tidb_enable_auto_analyze = OFF; ``` -クラスタ情報がインポートされると、TiDBクラスタには、必要なテーブルスキーマ、統計情報、および実行プランの構築に影響するその他の情報がロードされます。実行プランを表示し、統計情報を確認するには、以下の手順に従います。 +クラスター情報がインポートされると、TiDBクラスターには、必要なテーブルスキーマ、統計情報、および実行プランの構築に影響するその他の情報がロードされます。実行プランを表示し、統計情報を確認するには、以下の手順に従います。 ```sql mysql> desc t; @@ -194,7 +194,7 @@ TiDBの実行プランを特定する場合、対象となるSQL文と実行プ `PLAN REPLAYER CAPTURE`は主に次の機能があります。 -- 対象となるSQL文と対象実行プランのダイジェストを事前にTiDBクラスタに登録し、対象クエリとのマッチングを開始します。 +- 対象となるSQL文と対象実行プランのダイジェストを事前にTiDBクラスターに登録し、対象クエリとのマッチングを開始します。 - ターゲット クエリが正常に一致すると、そのオプティマイザー関連の情報を直接キャプチャし、ZIP ファイルとしてエクスポートします。 - 一致した SQL と実行プランごとに、情報は 1 回だけキャプチャされます。 - システム テーブルを通じて、進行中の一致するタスクと生成されたファイルを表示します。 diff --git a/sql-prepared-plan-cache.md b/sql-prepared-plan-cache.md index 486a09011d31c..4c2a69f8e5b6f 100644 --- a/sql-prepared-plan-cache.md +++ b/sql-prepared-plan-cache.md @@ -280,7 +280,7 @@ MySQL [test]> select @@last_plan_from_cache; -- The cached plan cannot be select 1 row in set (0.00 sec) ``` -現在、TiDBは`GLOBAL`実行計画キャッシュのクリアをサポートしていません。つまり、TiDBクラスタ全体のキャッシュされた計画をクリアすることはできません。3 `GLOBAL`実行計画キャッシュをクリアしようとすると、以下のエラーが報告されます。 +現在、TiDBは`GLOBAL`実行計画キャッシュのクリアをサポートしていません。つまり、TiDBクラスター全体のキャッシュされた計画をクリアすることはできません。3 `GLOBAL`実行計画キャッシュをクリアしようとすると、以下のエラーが報告されます。 ```sql MySQL [test]> admin flush global plan_cache; diff --git a/sql-statements/sql-statement-add-index.md b/sql-statements/sql-statement-add-index.md index 11b1006915900..6fef8c4fc9f84 100644 --- a/sql-statements/sql-statement-add-index.md +++ b/sql-statements/sql-statement-add-index.md @@ -15,7 +15,7 @@ summary: TiDBデータベースにおけるADD INDEXの使用方法の概要。 > **注記：** > -> 4 vCPUを搭載した[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタの場合、インデックス作成中にリソース制限がクラスタの安定性に影響を与えないように、 [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)手動で無効にすることをお勧めします。この設定を無効にすることで、トランザクションを使用してインデックスを作成できるようになり、クラスタ全体への影響を軽減できます。 +> 4 vCPUを搭載した[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの場合、インデックス作成中にリソース制限がクラスターの安定性に影響を与えないように、 [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)手動で無効にすることをお勧めします。この設定を無効にすることで、トランザクションを使用してインデックスを作成できるようになり、クラスター全体への影響を軽減できます。     @@ -24,8 +24,8 @@ summary: TiDBデータベースにおけるADD INDEXの使用方法の概要。 > **警告：** > > - TiDB クラスターで DDL ステートメントが実行されている間は、TiDB クラスターをアップグレード**しないでください**(通常、 `ADD INDEX`や列型の変更など、時間のかかる DDL ステートメントの場合)。 -> - アップグレードを行う前に、 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)コマンドを使用して、TiDB クラスタで実行中の DDL ジョブがあるかどうかを確認することをお勧めします。クラスタで DDL ジョブが実行されている場合は、クラスタをアップグレードする前に、DDL ジョブの実行が完了するまで待つか、 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md)コマンドを使用して DDL ジョブをキャンセルしてください。 -> - さらに、クラスタのアップグレード中は、DDLステートメントを一切実行**しないでください**。実行すると、未定義の動作が発生する可能性があります。 +> - アップグレードを行う前に、 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)コマンドを使用して、TiDB クラスターで実行中の DDL ジョブがあるかどうかを確認することをお勧めします。クラスターで DDL ジョブが実行されている場合は、クラスターをアップグレードする前に、DDL ジョブの実行が完了するまで待つか、 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md)コマンドを使用して DDL ジョブをキャンセルしてください。 +> - さらに、クラスターのアップグレード中は、DDLステートメントを一切実行**しないでください**。実行すると、未定義の動作が発生する可能性があります。 > > TiDB を v7.1.0 から以降のバージョンにアップグレードする場合は、前述の制限を無視できます。詳細については、 [TiDBのスムーズアップグレードの制限事項](/smooth-upgrade-tidb.md)を参照してください。 diff --git a/sql-statements/sql-statement-admin-cancel-ddl.md b/sql-statements/sql-statement-admin-cancel-ddl.md index e84205adaf673..77a10687ac700 100644 --- a/sql-statements/sql-statement-admin-cancel-ddl.md +++ b/sql-statements/sql-statement-admin-cancel-ddl.md @@ -32,7 +32,7 @@ ADMIN CANCEL DDL JOBS job_id [, job_id] ...; > **注記：** > -> - バージョン6.2.0より前では、この操作のみがDDLジョブをキャンセルでき、他のすべての操作や環境変更（マシンの再起動やクラスタの再起動など）ではこれらのジョブをキャンセルできませんでした。バージョン6.2.0以降では、 [`KILL`](/sql-statements/sql-statement-kill.md)ステートメントを使用して実行中のDDLジョブを強制終了することでキャンセルできるようになりました。 +> - バージョン6.2.0より前では、この操作のみがDDLジョブをキャンセルでき、他のすべての操作や環境変更（マシンの再起動やクラスターの再起動など）ではこれらのジョブをキャンセルできませんでした。バージョン6.2.0以降では、 [`KILL`](/sql-statements/sql-statement-kill.md)ステートメントを使用して実行中のDDLジョブを強制終了することでキャンセルできるようになりました。 > - この操作では、複数のDDLジョブを同時にキャンセルできます。1 ステートメントを使用して、 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ジョブのIDを取得できます。 > - キャンセルするジョブが完了している場合、キャンセル操作は失敗します。 diff --git a/sql-statements/sql-statement-admin-pause-ddl.md b/sql-statements/sql-statement-admin-pause-ddl.md index a2a35f96ecdee..a74df62d6a2e3 100644 --- a/sql-statements/sql-statement-admin-pause-ddl.md +++ b/sql-statements/sql-statement-admin-pause-ddl.md @@ -34,7 +34,7 @@ ADMIN PAUSE DDL JOBS job_id [, job_id] ...; > **注記：** > > - このステートメントは DDL ジョブを一時停止できますが、他の操作や環境の変更 (マシンの再起動やクラスターの再起動など) では、クラスターのアップグレードを除き、DDL ジョブは一時停止されません。 -> - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](/smooth-upgrade-tidb.md)ご覧ください。 +> - クラスターのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](/smooth-upgrade-tidb.md)ご覧ください。 > - このステートメントは複数のDDLジョブを一時停止できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。     @@ -43,7 +43,7 @@ ADMIN PAUSE DDL JOBS job_id [, job_id] ...; > **注記：** > > - このステートメントは DDL ジョブを一時停止できますが、他の操作や環境の変更 (マシンの再起動やクラスターの再起動など) では、クラスターのアップグレードを除き、DDL ジョブは一時停止されません。 -> - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](https://docs.pingcap.com/tidb/stable/smooth-upgrade-tidb)ご覧ください。 +> - クラスターのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](https://docs.pingcap.com/tidb/stable/smooth-upgrade-tidb)ご覧ください。 > - このステートメントは複数のDDLジョブを一時停止できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。     diff --git a/sql-statements/sql-statement-admin-resume-ddl.md b/sql-statements/sql-statement-admin-resume-ddl.md index 0f882fe4060c7..489233f64286a 100644 --- a/sql-statements/sql-statement-admin-resume-ddl.md +++ b/sql-statements/sql-statement-admin-resume-ddl.md @@ -33,7 +33,7 @@ ADMIN RESUME DDL JOBS job_id [, job_id] ...; > **注記：** > -> - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](/smooth-upgrade-tidb.md)ご覧ください。 +> - クラスターのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](/smooth-upgrade-tidb.md)ご覧ください。 > - このステートメントは複数のDDLジョブを再開できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。 > - その他のステータス ( `paused`以外) の DDL ジョブは再開できず、再開操作は失敗します。 > - ジョブを複数回再開しようとすると、TiDB はエラー`Error Number: 8261`報告します。 @@ -43,7 +43,7 @@ ADMIN RESUME DDL JOBS job_id [, job_id] ...; > **注記：** > -> - クラスタのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](https://docs.pingcap.com/tidb/stable/smooth-upgrade-tidb)ご覧ください。 +> - クラスターのアップグレード中は、実行中のDDLジョブが一時停止され、アップグレード中に開始されたDDLジョブも一時停止されます。アップグレード後、一時停止されていたすべてのDDLジョブは再開されます。アップグレード中の一時停止と再開の操作は自動的に実行されます。詳細は[TiDB スムーズアップグレード](https://docs.pingcap.com/tidb/stable/smooth-upgrade-tidb)ご覧ください。 > - このステートメントは複数のDDLジョブを再開できます。1 [`ADMIN SHOW DDL JOBS`](/sql-statements/sql-statement-admin-show-ddl.md)ステートメントを使用して、DDLジョブの`job_id`のステートメントを取得できます。 > - その他のステータス ( `paused`以外) の DDL ジョブは再開できず、再開操作は失敗します。 > - ジョブを複数回再開しようとすると、TiDB はエラー`Error Number: 8261`報告します。 diff --git a/sql-statements/sql-statement-alter-range.md b/sql-statements/sql-statement-alter-range.md index 7006231b2d39f..972b74fbe4ee5 100644 --- a/sql-statements/sql-statement-alter-range.md +++ b/sql-statements/sql-statement-alter-range.md @@ -33,4 +33,4 @@ ALTER RANGE global PLACEMENT POLICY = "deploy111"; ALTER RANGE meta PLACEMENT POLICY = "five_replicas"; ``` -上記の例では、2 つの配置ポリシー ( `deploy111`と`five_replicas` ) を作成し、異なる領域の制約を指定した後、 `deploy111`配置ポリシーをクラスタ範囲内のすべてのデータに適用し、 `five_replicas`配置ポリシーをメタデータ範囲に適用しています。 +上記の例では、2 つの配置ポリシー ( `deploy111`と`five_replicas` ) を作成し、異なる領域の制約を指定した後、 `deploy111`配置ポリシーをクラスター範囲内のすべてのデータに適用し、 `five_replicas`配置ポリシーをメタデータ範囲に適用しています。 diff --git a/sql-statements/sql-statement-alter-table-compact.md b/sql-statements/sql-statement-alter-table-compact.md index 6d7494940c35e..5a31a21290086 100644 --- a/sql-statements/sql-statement-alter-table-compact.md +++ b/sql-statements/sql-statement-alter-table-compact.md @@ -5,7 +5,7 @@ summary: TiDB データベースの ALTER TABLE ... COMPACT の使用法の概 # ALTER TABLE ... COMPACT {#alter-table-compact} -読み取りパフォーマンスを向上させ、ディスク使用量を削減するために、TiDB はstorageノード上でバックグラウンドでデータ圧縮を自動的にスケジュールします。圧縮中、storageノードは物理データを書き換えます。これには、削除された行のクリーンアップや、更新によって発生した複数のデータバージョンのマージなどが含まれます。1 ステートメントを使用すると、 `ALTER TABLE ... COMPACT`グラウンドで圧縮がトリガーされるまで待たずに、特定のテーブルの圧縮を即座に開始できます。 +読み取りパフォーマンスを向上させ、ディスク使用量を削減するために、TiDB はストレージノード上でバックグラウンドでデータ圧縮を自動的にスケジュールします。圧縮中、ストレージノードは物理データを書き換えます。これには、削除された行のクリーンアップや、更新によって発生した複数のデータバージョンのマージなどが含まれます。1 ステートメントを使用すると、 `ALTER TABLE ... COMPACT`グラウンドで圧縮がトリガーされるまで待たずに、特定のテーブルの圧縮を即座に開始できます。 この文を実行しても、既存のSQL文はブロックされず、トランザクション、DDL、GCといったTiDBの機能にも影響はありません。SQL文で選択可能なデータも変更されません。この文の実行は、IOリソースとCPUリソースを消費します。業務への悪影響を避けるため、リソースに余裕があるタイミングなど、適切なタイミングで実行するようご注意ください。 diff --git a/sql-statements/sql-statement-backup.md b/sql-statements/sql-statement-backup.md index 2eaa1d0d55437..63a9b0380a4de 100644 --- a/sql-statements/sql-statement-backup.md +++ b/sql-statements/sql-statement-backup.md @@ -5,7 +5,7 @@ summary: TiDBデータベースにおけるBACKUPの使用方法の概要。 # バックアップ {#backup} -このステートメントは、TiDBクラスタの分散バックアップを実行するために使用されます。 +このステートメントは、TiDBクラスターの分散バックアップを実行するために使用されます。 > **警告：** > @@ -14,13 +14,13 @@ summary: TiDBデータベースにおけるBACKUPの使用方法の概要。 `BACKUP`ステートメントは、 [BRツール](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview)と同じエンジンを使用しますが、バックアップ処理は別のBRツールではなくBR自体によって実行されます。BR のすべての利点と警告は、このステートメントにも適用されます。 -`BACKUP`を実行するには`BACKUP_ADMIN`または`SUPER`権限が必要です。さらに、バックアップを実行する TiDB ノードとクラスタ内のすべての TiKV ノードの両方が、宛先への読み取りまたは書き込み権限を持っている必要があります。 [Security強化モード](/system-variables.md#tidb_enable_enhanced_security)が有効になっている場合、ローカルstorage( `local://`で始まるstorageパス) は許可されません。 +`BACKUP`を実行するには`BACKUP_ADMIN`または`SUPER`権限が必要です。さらに、バックアップを実行する TiDB ノードとクラスター内のすべての TiKV ノードの両方が、宛先への読み取りまたは書き込み権限を持っている必要があります。 [Security強化モード](/system-variables.md#tidb_enable_enhanced_security)が有効になっている場合、ローカルストレージ( `local://`で始まるストレージパス) は許可されません。 `BACKUP`ステートメントは、バックアップ タスク全体が完了、失敗、またはキャンセルされるまでブロックされます。 `BACKUP`を実行するには、長時間接続を準備する必要があります。タスクは、[`KILL TIDB QUERY`](/sql-statements/sql-statement-kill.md)ステートメントを使用してキャンセルできます。 `BACKUP`および[`RESTORE`](/sql-statements/sql-statement-restore.md)タスクは、一度に 1 つしか実行できません。 `BACKUP`または`RESTORE`ステートメントが同じ TiDBサーバーで既に実行されている場合、新しい`BACKUP`の実行は、以前のすべてのタスクが完了するまで待機します。 -`BACKUP` 「tikv」storageエンジンでのみ使用できます。「unistore」エンジンで`BACKUP`を使用すると失敗します。 +`BACKUP` 「tikv」ストレージエンジンでのみ使用できます。「unistore」エンジンで`BACKUP`を使用すると失敗します。 ## あらすじ {#synopsis} @@ -98,7 +98,7 @@ BACKUP DATABASE * TO 'local:///mnt/backup/full/'; システムテーブル（ `mysql.*` 、 `INFORMATION_SCHEMA.*` 、 `PERFORMANCE_SCHEMA.*` 、…）はバックアップに含まれないことに注意してください。 -### 外部ストレージ {#external-storages} +### 外部ストレージ {#external-ストレージs} BRは、S3またはGCSへのデータバックアップをサポートしています。 @@ -106,7 +106,7 @@ BRは、S3またはGCSへのデータバックアップをサポートしてい BACKUP DATABASE `test` TO 's3://example-bucket-2020/backup-05/?access-key={YOUR_ACCESS_KEY}&secret-access-key={YOUR_SECRET_KEY}'; ``` -URL 構文については[外部ストレージサービスのURI形式](/external-storage-uri.md)で詳しく説明します。 +URL 構文については[外部ストレージサービスのURI形式](/external-ストレージ-uri.md)で詳しく説明します。 認証情報を配布すべきでないクラウド環境で実行する場合は、 `SEND_CREDENTIALS_TO_TIKV`オプションを`FALSE`に設定してください。 @@ -119,7 +119,7 @@ BACKUP DATABASE `test` TO 's3://example-bucket-2020/backup-05/' `RATE_LIMIT`を使用して、TiKVノードあたりの平均アップロード速度を制限し、ネットワーク帯域幅を削減します。 -バックアップが完了する前に、 `BACKUP`デフォルトでクラスタ上のデータに対してチェックサムを実行し、データの正当性を検証します。単一テーブルでのチェックサムタスクのデフォルトの同時実行数は 4 ですが、 `CHECKSUM_CONCURRENCY`パラメータを使用して調整できます。データの検証が不要であると確信している場合は、 `CHECKSUM`パラメータを`FALSE`に設定してチェックを無効にできます。 +バックアップが完了する前に、 `BACKUP`デフォルトでクラスター上のデータに対してチェックサムを実行し、データの正当性を検証します。単一テーブルでのチェックサムタスクのデフォルトの同時実行数は 4 ですが、 `CHECKSUM_CONCURRENCY`パラメータを使用して調整できます。データの検証が不要であると確信している場合は、 `CHECKSUM`パラメータを`FALSE`に設定してチェックを無効にできます。 テーブルとインデックスのバックアップにおいて、 BRが同時に実行できるタスクの数を指定するには、 `CONCURRENCY`パラメーターを使用します。このパラメーターは、 BR内のスレッドプールサイズを制御し、バックアップ操作のパフォーマンスと効率を最適化します。 diff --git a/sql-statements/sql-statement-begin.md b/sql-statements/sql-statement-begin.md index 9f87f2bbaa34a..1ca736dca071f 100644 --- a/sql-statements/sql-statement-begin.md +++ b/sql-statements/sql-statement-begin.md @@ -41,6 +41,6 @@ TiDBは`BEGIN PESSIMISTIC`または`BEGIN OPTIMISTIC`の構文拡張をサポー - [専念](/sql-statements/sql-statement-commit.md) - [ロールバック](/sql-statements/sql-statement-rollback.md) -- [取引を開始](/sql-statements/sql-statement-start-transaction.md) +- [トランザクションを開始](/sql-statements/sql-statement-start-transaction.md) - [TiDB楽観的トランザクションモデル](/optimistic-transaction.md) - [TiDB悲観的トランザクションモード](/pessimistic-transaction.md) diff --git a/sql-statements/sql-statement-calibrate-resource.md b/sql-statements/sql-statement-calibrate-resource.md index f9447237236c1..58a6bd97b1951 100644 --- a/sql-statements/sql-statement-calibrate-resource.md +++ b/sql-statements/sql-statement-calibrate-resource.md @@ -49,7 +49,7 @@ TiDB は推定に 2 つの方法を提供します。 ### ハードウェアの展開に基づいて容量を見積もる {#estimate-capacity-based-on-hardware-deployment} -この方法は、主に現在のクラスタ構成と、様々なワークロードで観測された経験値に基づいて容量を推定します。ワークロードの種類によって必要なハードウェア比率が異なるため、同じハードウェア構成でも出力容量が異なる場合があります。ここでの`WORKLOAD`パラメータは、以下の異なるワークロードタイプを受け入れます。デフォルト値は`TPCC`です。 +この方法は、主に現在のクラスター構成と、様々なワークロードで観測された経験値に基づいて容量を推定します。ワークロードの種類によって必要なハードウェア比率が異なるため、同じハードウェア構成でも出力容量が異なる場合があります。ここでの`WORKLOAD`パラメータは、以下の異なるワークロードタイプを受け入れます。デフォルト値は`TPCC`です。 - `TPCC` : 大量のデータ書き込みを伴うワークロードに適用されます。これは`TPC-C`と同様のワークロードモデルに基づいて推定されます。 - `OLTP_WRITE_ONLY` : 大量のデータ書き込みを伴うワークロードに適用されます。これは`sysbench oltp_write_only`と同様のワークロードモデルに基づいて推定されます。 @@ -59,7 +59,7 @@ TiDB は推定に 2 つの方法を提供します。 > **注記：** > -> クラスタのRU容量は、クラスタのトポロジと各コンポーネントのハードウェアおよびソフトウェア構成によって異なります。各クラスタが提供できる実際のRUは、実際のワークロードにも依存します。ハードウェア構成に基づく推定値は参考値であり、実際の最大値と異なる場合があります[実際の作業量に基づいて容量を見積もる](#estimate-capacity-based-on-actual-workload)を推奨します。 +> クラスターのRU容量は、クラスターのトポロジと各コンポーネントのハードウェアおよびソフトウェア構成によって異なります。各クラスターが提供できる実際のRUは、実際のワークロードにも依存します。ハードウェア構成に基づく推定値は参考値であり、実際の最大値と異なる場合があります[実際の作業量に基づいて容量を見積もる](#estimate-capacity-based-on-actual-workload)を推奨します。 ## 例 {#examples} diff --git a/sql-statements/sql-statement-commit.md b/sql-statements/sql-statement-commit.md index 7d7e2591cf433..715148bb39dff 100644 --- a/sql-statements/sql-statement-commit.md +++ b/sql-statements/sql-statement-commit.md @@ -46,7 +46,7 @@ Query OK, 0 rows affected (0.01 sec) ## 参照 {#see-also} -- [取引を開始](/sql-statements/sql-statement-start-transaction.md) +- [トランザクションを開始](/sql-statements/sql-statement-start-transaction.md) - [ロールバック](/sql-statements/sql-statement-rollback.md) - [始める](/sql-statements/sql-statement-begin.md) - [制約の遅延チェック](/transaction-overview.md#lazy-check-of-constraints) diff --git a/sql-statements/sql-statement-create-index.md b/sql-statements/sql-statement-create-index.md index 845942c98cba8..80b80f103ad3b 100644 --- a/sql-statements/sql-statement-create-index.md +++ b/sql-statements/sql-statement-create-index.md @@ -11,7 +11,7 @@ summary: TiDBデータベースにおけるCREATE INDEXの使用方法の概要 > **注記：** > -> 4 vCPUを搭載した[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタの場合、インデックス作成中にリソース制限がクラスタの安定性に影響を与えないように、 [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)手動で無効にすることをお勧めします。この設定を無効にすることで、トランザクションを使用してインデックスを作成できるようになり、クラスタ全体への影響を軽減できます。 +> 4 vCPUを搭載した[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの場合、インデックス作成中にリソース制限がクラスターの安定性に影響を与えないように、 [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)手動で無効にすることをお勧めします。この設定を無効にすることで、トランザクションを使用してインデックスを作成できるようになり、クラスター全体への影響を軽減できます。 @@ -359,10 +359,10 @@ Query OK, 1 row affected (0.00 sec) - 複数値インデックスをソートに使用することはできません。 - JSON配列に対してのみ、複数値のインデックスを作成できます。 - 複数値インデックスは、主キーまたは外部キーとして使用することはできません。 -- 複数値インデックスが使用する追加のstorage領域は、1行あたりの配列要素の平均数×通常のセカンダリインデックスが使用する領域に等しくなります。 +- 複数値インデックスが使用する追加のストレージ領域は、1行あたりの配列要素の平均数×通常のセカンダリインデックスが使用する領域に等しくなります。 - 通常のインデックスと比較して、多値インデックスではDML操作によって変更されるインデックスレコードの数が多くなるため、多値インデックスは通常のインデックスよりもパフォーマンスに大きな影響を与えます。 - 多値インデックスは式インデックスの特殊なタイプであるため、式インデックスと同様の制限があります。 -- テーブルが複数値インデックスを使用している場合、 BR、TiCDC、またはTiDB Lightningを使用して、v6.6.0より前のTiDBクラスタにテーブルをバックアップ、レプリケート、またはインポートすることはできません。 +- テーブルが複数値インデックスを使用している場合、 BR、TiCDC、またはTiDB Lightningを使用して、v6.6.0より前のTiDBクラスターにテーブルをバックアップ、レプリケート、またはインポートすることはできません。 - 複雑な条件を含むクエリの場合、TiDB は複数値のインデックスを選択できない場合があります。多値インデックスでサポートされる条件パターンについては、 [複数値インデックスを使用する](/choose-index.md#use-multi-valued-indexes)を参照してください。 ## 非表示インデックス {#invisible-index} diff --git a/sql-statements/sql-statement-create-resource-group.md b/sql-statements/sql-statement-create-resource-group.md index 2792cb037a997..9766c44b63458 100644 --- a/sql-statements/sql-statement-create-resource-group.md +++ b/sql-statements/sql-statement-create-resource-group.md @@ -86,7 +86,7 @@ TiDB は、次の`DirectResourceGroupOption`をサポートします。ここで > **注記：** > -> - `CREATE RESOURCE GROUP`ステートメントは、グローバル変数[`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660)が`ON`に設定されている場合にのみ実行できます。 TiDB は、クラスタ初期化時に`default`リソース グループを自動的に作成します。 このリソース グループの`RU_PER_SEC`のデフォルト値は`UNLIMITED` ( `INT`型の最大値、つまり`2147483647`に相当) であり、 `BURSTABLE`モードです。いずれのリソースグループにも紐付けられていないすべてのリクエストは、自動的にこの`default`リソースグループに紐付けられます。別のリソースグループの新しい構成を作成する場合は、必要に応じて`default`リソースグループの構成を変更することをお勧めします。 +> - `CREATE RESOURCE GROUP`ステートメントは、グローバル変数[`tidb_enable_resource_control`](/system-variables.md#tidb_enable_resource_control-new-in-v660)が`ON`に設定されている場合にのみ実行できます。 TiDB は、クラスター初期化時に`default`リソース グループを自動的に作成します。 このリソース グループの`RU_PER_SEC`のデフォルト値は`UNLIMITED` ( `INT`型の最大値、つまり`2147483647`に相当) であり、 `BURSTABLE`モードです。いずれのリソースグループにも紐付けられていないすべてのリクエストは、自動的にこの`default`リソースグループに紐付けられます。別のリソースグループの新しい構成を作成する場合は、必要に応じて`default`リソースグループの構成を変更することをお勧めします。 > - 現在、 `default`リソース グループのみが`BACKGROUND`構成の変更をサポートしています。 ## 例 {#examples} diff --git a/sql-statements/sql-statement-distribute-table.md b/sql-statements/sql-statement-distribute-table.md index 670e779194003..daaa297d9cfcf 100644 --- a/sql-statements/sql-statement-distribute-table.md +++ b/sql-statements/sql-statement-distribute-table.md @@ -34,10 +34,10 @@ PartitionNameList ::= ## パラメータの説明 {#parameter-description} -`DISTRIBUTE TABLE`ステートメントを使用してテーブル内のリージョンを再分配する場合、バランスの取れた分配のために、storageエンジン ( TiFlashや TiKV など) とさまざまなRaftロール (Leader、Learner、投票者など) を指定できます。 +`DISTRIBUTE TABLE`ステートメントを使用してテーブル内のリージョンを再分配する場合、バランスの取れた分配のために、ストレージエンジン ( TiFlashや TiKV など) とさまざまなRaftロール (Leader、ラーナー、投票者など) を指定できます。 - `RULE` : バランス調整とスケジュールを行うRaftロールのリージョンを指定します。オプションの値は`"leader-scatter"` 、 `"peer-scatter"` 、および`"learner-scatter"` 。 -- `ENGINE` :storageエンジンを指定します。オプションの値は`"tikv"`と`"tiflash"` 。 +- `ENGINE` :ストレージエンジンを指定します。オプションの値は`"tikv"`と`"tiflash"` 。 - `TIMEOUT` : 散布操作のタイムアウト制限を指定します。PD がこの時間内に散布を完了しない場合、散布タスクは自動的に終了します。このパラメーターが指定されていない場合、デフォルト値は`"30m"`です。 ## 例 {#examples} @@ -56,7 +56,7 @@ DISTRIBUTE TABLE t1 RULE = "leader-scatter" ENGINE = "tikv" TIMEOUT = "1h"; | 100 | +--------+ -TiFlash上の表`t2`内の学習者の領域を再分配します。 +TiFlash上の表`t2`内のラーナーの領域を再分配します。 ```sql CREATE TABLE t2 (a INT); @@ -87,7 +87,7 @@ DISTRIBUTE TABLE t3 PARTITION (p1, p2) RULE = "peer-scatter" ENGINE = "tikv"; | 102 | +--------+ -TiFlash 上のテーブル`t4`の`p1`および`p2`TiFlashでLearnerの領域を再分配します。 +TiFlash 上のテーブル`t4`の`p1`および`p2`TiFlashでラーナーの領域を再分配します。 ```sql CREATE TABLE t4 ( a INT, b INT, INDEX idx(b)) PARTITION BY RANGE( a ) ( diff --git a/sql-statements/sql-statement-flashback-cluster.md b/sql-statements/sql-statement-flashback-cluster.md index b4af05c301747..05f43c0d164de 100644 --- a/sql-statements/sql-statement-flashback-cluster.md +++ b/sql-statements/sql-statement-flashback-cluster.md @@ -5,7 +5,7 @@ summary: TiDBデータベースにおけるFLASHBACK CLUSTERの使い方を学 # フラッシュバック・クラスター {#flashback-cluster} -TiDB v6.4.0 では`FLASHBACK CLUSTER TO TIMESTAMP`構文が導入されました。これを使用すると、クラスタを特定の時点に復元できます。タイムスタンプを指定する際には、datetime 値を設定するか、time 関数を使用できます。datetime の形式は「2016-10-08 16:45:26.999」のようで、最小時間単位はミリ秒です。ただし、ほとんどの場合、時間単位を秒としてタイムスタンプを指定するだけで十分です。たとえば、「2016-10-08 16:45:26」のように指定します。 +TiDB v6.4.0 では`FLASHBACK CLUSTER TO TIMESTAMP`構文が導入されました。これを使用すると、クラスターを特定の時点に復元できます。タイムスタンプを指定する際には、datetime 値を設定するか、time 関数を使用できます。datetime の形式は「2016-10-08 16:45:26.999」のようで、最小時間単位はミリ秒です。ただし、ほとんどの場合、時間単位を秒としてタイムスタンプを指定するだけで十分です。たとえば、「2016-10-08 16:45:26」のように指定します。 TiDBは、v6.5.6、v7.1.3、v7.5.1、v7.6.0以降で`FLASHBACK CLUSTER TO TSO`構文を導入しました。この構文を使用すると、 [TSO](/tso.md)使用してより正確なリカバリ時点を指定できるため、データリカバリの柔軟性が向上します。 @@ -30,7 +30,7 @@ TiDBは、v6.5.6、v7.1.3、v7.5.1、v7.6.0以降で`FLASHBACK CLUSTER TO TSO` > **注記：** > -> `FLASHBACK CLUSTER TO [TIMESTAMP|TSO]`の動作原理は、特定の時点の古いデータを最新のタイムスタンプで書き込むことであり、現在のデータは削除しません。そのため、この機能を使用する前に、古いデータと現在のデータのための十分なstorage容量があることを確認する必要があります。 +> `FLASHBACK CLUSTER TO [TIMESTAMP|TSO]`の動作原理は、特定の時点の古いデータを最新のタイムスタンプで書き込むことであり、現在のデータは削除しません。そのため、この機能を使用する前に、古いデータと現在のデータのための十分なストレージ容量があることを確認する必要があります。 ## 構文 {#syntax} @@ -114,7 +114,7 @@ mysql> SELECT * FROM t; Empty set (0.00 sec) ``` -次の例は、誤って削除されたデータを正確に復元するために、クラスタを特定のTSOにフラッシュバックする方法を示しています。 +次の例は、誤って削除されたデータを正確に復元するために、クラスターを特定のTSOにフラッシュバックする方法を示しています。 ```sql mysql> INSERT INTO t VALUES (1); diff --git a/sql-statements/sql-statement-import-into.md b/sql-statements/sql-statement-import-into.md index 07f035da8e2f0..ee4a3c76b4e0f 100644 --- a/sql-statements/sql-statement-import-into.md +++ b/sql-statements/sql-statement-import-into.md @@ -26,12 +26,12 @@ summary: TiDBにおけるIMPORT INTOの使用方法の概要。 - `IMPORT INTO`トランザクションまたはロールバックをサポートしていません。明示的なトランザクション ( `IMPORT INTO` / { `BEGIN`内) で`END`を実行するとエラーが返されます。 - `IMPORT INTO` [バックアップと復元](https://docs.pingcap.com/tidb/stable/backup-and-restore-overview)、 [`FLASHBACK CLUSTER`](/sql-statements/sql-statement-flashback-cluster.md) 、 [インデックス追加処理の高速化](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)、 TiDB Lightning を使用したデータ インポート、TiCDC を使用したデータ レプリケーション、または[特定時点復旧（PITR）](https://docs.pingcap.com/tidb/stable/br-log-architecture)などの機能との同時作業をサポートしていません。互換性の詳細については、 [TiDB Lightningと`IMPORT INTO`のTiCDCおよびログバックアップとの互換性](https://docs.pingcap.com/tidb/stable/tidb-lightning-compatibility-and-scenarios)参照してください。 - データインポート処理中は、対象テーブルに対してDDLまたはDML操作を実行したり、対象データベースに対して[`FLASHBACK DATABASE`](/sql-statements/sql-statement-flashback-database.md)を実行したりしないでください。これらの操作は、インポートの失敗やデータの不整合を引き起こす可能性があります。また、インポート処理中に読み取り操作を実行することも推奨さ**れません**。読み取られるデータに不整合が生じる可能性があるためです。読み取りおよび書き込み操作は、インポートが完了した後にのみ実行してください。 -- インポート プロセスはシステム リソースを大幅に消費します。 TiDB セルフマネージドの場合、パフォーマンスを向上させるために、少なくとも 32 コアと 64 GiB のメモリを備えた TiDB ノードを使用することをお勧めします。 TiDB はインポート中にソートされたデータを TiDB [一時ディレクトリ](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630)に書き込むため、フラッシュメモリなどの TiDB 自己管理用の高性能storageメディアを構成することをお勧めします。詳細については、 [物理輸入モードの制限](https://docs.pingcap.com/tidb/stable/tidb-lightning-physical-import-mode#requirements-and-restrictions)を参照してください。 -- TiDB Self-Managedの場合、TiDB [一時ディレクトリ](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630)は少なくとも90 GiBの空き容量が必要です。インポートするデータ量と同等以上のstorage容量を割り当てることをお勧めします。 +- インポート プロセスはシステム リソースを大幅に消費します。 TiDB Self-Managedの場合、パフォーマンスを向上させるために、少なくとも 32 コアと 64 GiB のメモリを備えた TiDB ノードを使用することをお勧めします。 TiDB はインポート中にソートされたデータを TiDB [一時ディレクトリ](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630)に書き込むため、フラッシュメモリなどの TiDB 自己管理用の高性能ストレージメディアを構成することをお勧めします。詳細については、 [物理輸入モードの制限](https://docs.pingcap.com/tidb/stable/tidb-lightning-physical-import-mode#requirements-and-restrictions)を参照してください。 +- TiDB Self-Managedの場合、TiDB [一時ディレクトリ](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630)は少なくとも90 GiBの空き容量が必要です。インポートするデータ量と同等以上のストレージ容量を割り当てることをお勧めします。 - 1つのインポートジョブは、1つのターゲットテーブルへのデータインポートのみをサポートします。 -- `IMPORT INTO` TiDB クラスタのアップグレード時にはサポートされません。 +- `IMPORT INTO` TiDB クラスターのアップグレード時にはサポートされません。 - インポートするデータに、主キーまたはNULL以外の一意インデックスの競合が発生するレコードが含まれていないことを確認してください。競合が発生すると、インポート処理が失敗する可能性があります。 -- 既知の問題: TiDBノード構成ファイル内のPDアドレスがクラスタの現在のPDトポロジと一致しない場合`IMPORT INTO`タスクが失敗する可能性があります。この不一致は、PDが以前にスケールインされたものの、TiDB構成ファイルがそれに応じて更新されなかった場合や、構成ファイルの更新後にTiDBノードが再起動されなかった場合などに発生する可能性があります。 +- 既知の問題: TiDBノード構成ファイル内のPDアドレスがクラスターの現在のPDトポロジと一致しない場合`IMPORT INTO`タスクが失敗する可能性があります。この不一致は、PDが以前にスケールインされたものの、TiDB構成ファイルがそれに応じて更新されなかった場合や、構成ファイルの更新後にTiDBノードが再起動されなかった場合などに発生する可能性があります。 ### IMPORT INTO ... FROM FILE制限 {#code-import-into-from-file-code-restrictions} @@ -58,11 +58,11 @@ summary: TiDBにおけるIMPORT INTOの使用方法の概要。 - インポート対象のテーブルは既にTiDB内に作成されており、空の状態です。 - 対象クラスターには、インポートするデータを保存するのに十分な空き容量があります。 -- TiDB Self-Managed の場合、 現在のセッションに接続されている TiDB ノードの空き容量[一時ディレクトリ](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630)90 GiB 以上必要です[`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)が有効になっており、インポートするデータが S3 または GCS から取得される場合は、クラスタ内の各 TiDB ノードの一時ディレクトリに十分なディスク容量があることを確認してください。 +- TiDB Self-Managed の場合、 現在のセッションに接続されている TiDB ノードの空き容量[一時ディレクトリ](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630)90 GiB 以上必要です[`tidb_enable_dist_task`](/system-variables.md#tidb_enable_dist_task-new-in-v710)が有効になっており、インポートするデータが S3 または GCS から取得される場合は、クラスター内の各 TiDB ノードの一時ディレクトリに十分なディスク容量があることを確認してください。 ## 必要な権限 {#required-privileges} -`IMPORT INTO`を実行するには、対象テーブルに対する`SELECT` 、 `UPDATE` 、 `INSERT` 、 `DELETE` 、および`ALTER`の権限。TiDB ローカルstorageにファイルをインポートするには、 `FILE`権限も必要です。 +`IMPORT INTO`を実行するには、対象テーブルに対する`SELECT` 、 `UPDATE` 、 `INSERT` 、 `DELETE` 、および`ALTER`の権限。TiDB ローカルストレージにファイルをインポートするには、 `FILE`権限も必要です。 ## あらすじ {#synopsis} @@ -111,9 +111,9 @@ OptionItem ::= ### ファイルの場所 {#filelocation} -これはデータファイルのstorage場所を指定するもので、Amazon S3またはGCSのURIパス、あるいはTiDBのローカルファイルパスを指定できます。 +これはデータファイルのストレージ場所を指定するもので、Amazon S3またはGCSのURIパス、あるいはTiDBのローカルファイルパスを指定できます。 -- Amazon S3 または GCS URI パス: URI 設定の詳細については、[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 +- Amazon S3 または GCS URI パス: URI 設定の詳細については、[外部ストレージサービスのURI形式](/external-ストレージ-uri.md)を参照してください。 - TiDB ローカルファイルパス: 絶対パスである必要があり、ファイル拡張子は`.csv` 、 `.sql` 、または`.parquet`である必要があります。このパスに対応するファイルが、現在のユーザーが接続している TiDB ノードに保存されていること、およびユーザーが`FILE`権限を持っていることを確認してください。 @@ -151,12 +151,12 @@ OptionItem ::= | `SKIP_ROWS=` | CSV | スキップする行数を指定します。デフォルト値は`0`です。このオプションを使用すると、CSV ファイルのヘッダーをスキップできます。インポートするソース ファイルを指定するためにワイルド カードを使用する場合、このオプションは`fileLocation`のワイルド カードに一致するすべてのソース ファイルに適用されます。 | | `SPLIT_FILE` | CSV | インポート効率を向上させるため、単一のCSVファイルを約256MiBの複数の小さなチャンクに分割し、並列処理を行います。このパラメータは**非圧縮**CSVファイルでのみ有効で、 TiDB Lightning [`strict-format`](https://docs.pingcap.com/tidb/stable/tidb-lightning-data-source#strict-format)と同様の使用制限があります。このオプションを使用するには`LINES_TERMINATED_BY`明示的に指定する必要があることに注意してください。 | | `DISK_QUOTA=''` | すべてのファイル形式 | データソート中に使用できるディスク容量のしきい値を指定します。デフォルト値は、TiDB のディスク容量の 80% です。 ディスクの合計サイズを取得できない場合は、デフォルト値は 50 GiB です。 `DISK_QUOTA`を明示的に指定する場合は、その値が TiDB [一時ディレクトリ](https://docs.pingcap.com/tidb/stable/tidb-configuration-file#temp-dir-new-in-v630)ディレクトリのディスク容量の 80% を超えないようにしてください。 | -| `DISABLE_TIKV_IMPORT_MODE` | すべてのファイル形式 | インポート処理中に TiKV をインポートモードに切り替える機能を無効にするかどうかを指定します。デフォルトでは、TiKV をインポートモードに切り替える機能は無効になっていません。クラスタ内で読み書き操作が進行中の場合は、このオプションを有効にすることで、インポート処理による影響を回避できます。 | -| `THREAD=` | `SELECT`のすべてのファイル形式とクエリ結果 | インポートの同時実行数を指定します。 `IMPORT INTO ... FROM FILE`の場合、 `THREAD`のデフォルト値は TiDB ノードの CPU コア数の 50%、最小値は`1` 、最大値は CPU コア数です。 `IMPORT INTO ... FROM SELECT`の場合、 `THREAD`のデフォルト値は`2` 、最小値は`1` 、最大値は TiDB ノードの CPU コア数の 2 倍です。データのない新しいクラスタにデータをインポートする場合は、インポートのパフォーマンスを向上させるために、この同時実行数を適切に増やすことをお勧めします。対象クラスターが既に本番環境で使用されている場合は、アプリケーションの要件に応じてこの同時実行数を調整することをお勧めします。 | +| `DISABLE_TIKV_IMPORT_MODE` | すべてのファイル形式 | インポート処理中に TiKV をインポートモードに切り替える機能を無効にするかどうかを指定します。デフォルトでは、TiKV をインポートモードに切り替える機能は無効になっていません。クラスター内で読み書き操作が進行中の場合は、このオプションを有効にすることで、インポート処理による影響を回避できます。 | +| `THREAD=` | `SELECT`のすべてのファイル形式とクエリ結果 | インポートの同時実行数を指定します。 `IMPORT INTO ... FROM FILE`の場合、 `THREAD`のデフォルト値は TiDB ノードの CPU コア数の 50%、最小値は`1` 、最大値は CPU コア数です。 `IMPORT INTO ... FROM SELECT`の場合、 `THREAD`のデフォルト値は`2` 、最小値は`1` 、最大値は TiDB ノードの CPU コア数の 2 倍です。データのない新しいクラスターにデータをインポートする場合は、インポートのパフォーマンスを向上させるために、この同時実行数を適切に増やすことをお勧めします。対象クラスターが既に本番環境で使用されている場合は、アプリケーションの要件に応じてこの同時実行数を調整することをお勧めします。 | | `MAX_WRITE_SPEED=''` | すべてのファイル形式 | TiKVノードへの書き込み速度を制御します。デフォルトでは速度制限はありません。たとえば、このオプションを`1MiB`と指定すると、書き込み速度を1 MiB/sに制限できます。 | | `CHECKSUM_TABLE=''` | すべてのファイル形式 | インポート後にターゲット テーブルに対してチェックサム チェックを実行してインポートの整合性を検証するかどうかを設定します。サポートされている値は、 `"required"` (デフォルト)、 `"optional"` 、および`"off"`です。 `"required"`インポート後にチェックサム チェックを実行することを意味します。チェックサム チェックが失敗した場合、TiDB はエラーを返し、インポートは終了します。 `"optional"`インポート後にチェックサム チェックを実行することを意味します。エラーが発生した場合、TiDB は警告を返し、エラーを無視します。 `"off"`インポート後にチェックサム チェックを実行しないことを意味します。 | | `DETACHED` | すべてのファイル形式 | `IMPORT INTO`非同期で実行するかどうかを制御します。このオプションを有効にすると、 `IMPORT INTO`の実行によりインポートジョブの情報 ( `Job_ID`など) がすぐに返され、ジョブはバックエンドで非同期に実行されます。 | -| `CLOUD_STORAGE_URI` | すべてのファイル形式 | [グローバルソート](/tidb-global-sort.md)用のエンコードされた KV データが保存されるターゲット アドレスを指定します。 `CLOUD_STORAGE_URI`が指定されていない場合、 `IMPORT INTO`システム変数[`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)の値に基づいてグローバル ソートを使用するかどうかを決定します。このシステム変数でターゲットstorageアドレスが指定されている場合、 `IMPORT INTO`このアドレスをグローバル ソートに使用します。 `CLOUD_STORAGE_URI`に空でない値が指定されている場合、 `IMPORT INTO`その値をターゲットstorageアドレスとして使用します。 `CLOUD_STORAGE_URI`に空の値が指定されている場合、ローカル ソートが適用されます。現在、ターゲットstorageアドレスは S3 のみをサポートしています。URI 構成の詳細については、 [Amazon S3 URI形式](/external-storage-uri.md#amazon-s3-uri-format)参照してください。この機能を使用する場合、すべての TiDB ノードは、対象の S3 バケットに対する読み取りおよび書き込みアクセス権を持っている必要があり、少なくとも次の権限が必要です: `s3:ListBucket` 、 `s3:GetObject` 、 {{B- `s3:DeleteObject` 、 `s3:PutObject` 、 `s3: AbortMultipartUpload` 。 | +| `CLOUD_STORAGE_URI` | すべてのファイル形式 | [グローバルソート](/tidb-global-sort.md)用のエンコードされた KV データが保存されるターゲット アドレスを指定します。 `CLOUD_STORAGE_URI`が指定されていない場合、 `IMPORT INTO`システム変数[`tidb_cloud_ストレージ_uri`](/system-variables.md#tidb_cloud_ストレージ_uri-new-in-v740)の値に基づいてグローバル ソートを使用するかどうかを決定します。このシステム変数でターゲットストレージアドレスが指定されている場合、 `IMPORT INTO`このアドレスをグローバル ソートに使用します。 `CLOUD_STORAGE_URI`に空でない値が指定されている場合、 `IMPORT INTO`その値をターゲットストレージアドレスとして使用します。 `CLOUD_STORAGE_URI`に空の値が指定されている場合、ローカル ソートが適用されます。現在、ターゲットストレージアドレスは S3 のみをサポートしています。URI 構成の詳細については、 [Amazon S3 URI形式](/external-ストレージ-uri.md#amazon-s3-uri-format)参照してください。この機能を使用する場合、すべての TiDB ノードは、対象の S3 バケットに対する読み取りおよび書き込みアクセス権を持っている必要があり、少なくとも次の権限が必要です: `s3:ListBucket` 、 `s3:GetObject` 、 {{B- `s3:DeleteObject` 、 `s3:PutObject` 、 `s3: AbortMultipartUpload` 。 | | `DISABLE_PRECHECK` | `SELECT`のすべてのファイル形式とクエリ結果 | このオプションを設定すると、CDCやPITRタスクの有無など、重要度の低い項目の事前チェックが無効になります。 | @@ -169,7 +169,7 @@ OptionItem ::= ## IMPORT INTO ... FROM FILE方法 {#code-import-into-from-file-code-usage} -TiDB Self-Managed の場合、 `IMPORT INTO ... FROM FILE`は Amazon S3、GCS、および TiDB ローカルstorageに保存されているファイルからのデータインポートをサポートしています。 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)の場合、 `IMPORT INTO ... FROM FILE`は Amazon S3 および GCS に保存されているファイルからのデータインポートをサポートしています。 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、 `IMPORT INTO ... FROM FILE`は Amazon S3 および Alibaba Cloud OSS に保存されているファイルからのデータインポートをサポートしています。 +TiDB Self-Managed の場合、 `IMPORT INTO ... FROM FILE`は Amazon S3、GCS、および TiDB ローカルストレージに保存されているファイルからのデータインポートをサポートしています。 [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)の場合、 `IMPORT INTO ... FROM FILE`は Amazon S3 および GCS に保存されているファイルからのデータインポートをサポートしています。 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)の場合、 `IMPORT INTO ... FROM FILE`は Amazon S3 および Alibaba Cloud OSS に保存されているファイルからのデータインポートをサポートしています。 - Amazon S3 または GCS に保存されているデータ ファイルの場合、 `IMPORT INTO ... FROM FILE` [TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)での実行をサポートしています。 @@ -207,7 +207,7 @@ TiDB Self-Managed の場合、 `IMPORT INTO ... FROM FILE`は Amazon S3、GCS、 - `IMPORT INTO` 、データファイルの走査順序に基づいてサブジョブを分割します。通常は、ファイル名で辞書順にソートされます。 - 対象テーブルに多数のインデックスが存在する場合、またはインデックス列の値がデータファイル内に分散している場合、各サブジョブのエンコードによって生成されるインデックスKVも重複します。 -[TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)が有効になっている場合、 `CLOUD_STORAGE_URI` `IMPORT INTO`を指定するか、システム変数[`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)を使用してエンコードされた KV データのターゲットstorageアドレスを指定することで、[グローバルソート](/tidb-global-sort.md)を有効にできます。現在、グローバル ソートはstorageアドレスとして Amazon S3 の使用をサポートしています。グローバル ソートが有効になっている場合、 `IMPORT INTO`はエンコードされた KV データをクラウドstorageに書き込み、クラウドstorageでグローバル ソートを実行し、グローバルにソートされたインデックスとテーブル データを TiKV に並列にインポートします。これにより、KV の重複によって発生する問題が防止され、インポートの安定性とパフォーマンスが向上します。 +[TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)が有効になっている場合、 `CLOUD_STORAGE_URI` `IMPORT INTO`を指定するか、システム変数[`tidb_cloud_ストレージ_uri`](/system-variables.md#tidb_cloud_ストレージ_uri-new-in-v740)を使用してエンコードされた KV データのターゲットストレージアドレスを指定することで、[グローバルソート](/tidb-global-sort.md)を有効にできます。現在、グローバル ソートはストレージアドレスとして Amazon S3 の使用をサポートしています。グローバル ソートが有効になっている場合、 `IMPORT INTO`はエンコードされた KV データをクラウドストレージに書き込み、クラウドストレージでグローバル ソートを実行し、グローバルにソートされたインデックスとテーブル データを TiKV に並列にインポートします。これにより、KV の重複によって発生する問題が防止され、インポートの安定性とパフォーマンスが向上します。 グローバルソートは大量のメモリリソースを消費します。データインポートの前に、 [`tidb_server_memory_limit_gc_trigger`](/system-variables.md#tidb_server_memory_limit_gc_trigger-new-in-v640)および[`tidb_server_memory_limit`](/system-variables.md#tidb_server_memory_limit-new-in-v640)変数を設定することをお勧めします。これにより、Go言語のガベージコレクションが頻繁にトリガーされることを防ぎ、インポート効率への影響を軽減できます。 @@ -219,7 +219,7 @@ SET GLOBAL tidb_server_memory_limit='75%'; > **注記：** > > - ソースデータファイル内のキーバリュー範囲の重複が少ない場合、グローバルソートを有効にするとインポートのパフォーマンスが低下する可能性があります。これは、グローバルソートを有効にすると、TiDB はグローバルソート操作とそれに続くインポートに進む前に、すべてのサブジョブにおけるローカルソートの完了を待つ必要があるためです。 -> - Global Sortを使用したインポート処理が完了すると、Global Sort用にクラウドstorageに保存されたファイルは、バックグラウンドスレッドで非同期的にクリーンアップされます。 +> - Global Sortを使用したインポート処理が完了すると、Global Sort用にクラウドストレージに保存されたファイルは、バックグラウンドスレッドで非同期的にクリーンアップされます。 ### 出力 {#output} @@ -309,7 +309,7 @@ IMPORT INTO t FROM '/path/to/file-0[13].csv'; IMPORT INTO t FROM 'gs://import/test.csv?credentials-file=${credentials-file-path}'; ``` -Amazon S3 または GCS の URI パス設定の詳細については、[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 +Amazon S3 または GCS の URI パス設定の詳細については、[外部ストレージサービスのURI形式](/external-ストレージ-uri.md)を参照してください。 #### SetClauseを使用して列の値を計算する {#calculate-column-values-using-setclause} diff --git a/sql-statements/sql-statement-kill.md b/sql-statements/sql-statement-kill.md index 3ebd7c1b3af88..4433d2e1470be 100644 --- a/sql-statements/sql-statement-kill.md +++ b/sql-statements/sql-statement-kill.md @@ -5,7 +5,7 @@ summary: TiDB データベースに対する KILL の使用法の概要。 # 殺す {#kill} -`KILL`文は、現在の TiDB クラスタ内の任意の TiDB インスタンスへの接続を終了するために使用されます。TiDB v6.2.0 以降では、 `KILL`文を使用して実行中の DDL ジョブを終了することもできます。 +`KILL`文は、現在の TiDB クラスター内の任意の TiDB インスタンスへの接続を終了するために使用されます。TiDB v6.2.0 以降では、 `KILL`文を使用して実行中の DDL ジョブを終了することもできます。 ## 概要 {#synopsis} @@ -48,7 +48,7 @@ v7.3.0以降、TiDBは32ビット接続IDの生成をサポートしています > **警告：** > -> クラスタ内のTiDBインスタンス数が2048を超えるか、単一のTiDBインスタンスの同時接続数が1048576を超えると、32ビット接続IDの容量が不足するため、自動的に64ビット接続IDにアップグレードされます。アップグレードプロセス中、既存のビジネス接続および確立済みの接続は影響を受けません。ただし、それ以降の新規接続は、MySQLコマンドラインでControl+Cを使用して終了することはできません。 +> クラスター内のTiDBインスタンス数が2048を超えるか、単一のTiDBインスタンスの同時接続数が1048576を超えると、32ビット接続IDの容量が不足するため、自動的に64ビット接続IDにアップグレードされます。アップグレードプロセス中、既存のビジネス接続および確立済みの接続は影響を受けません。ただし、それ以降の新規接続は、MySQLコマンドラインでControl+Cを使用して終了することはできません。 v6.1.0 以降、TiDB は Global Kill 機能をサポートしています。この機能はデフォルトで有効になっており、 [`enable-global-kill`](/tidb-configuration-file.md#enable-global-kill-new-in-v610)構成によって制御されます。 @@ -62,7 +62,7 @@ v6.1.0 以降、TiDB は Global Kill 機能をサポートしており、これ -Global Kill機能を有効にすると、 `KILL`と`KILL TIDB`両方のステートメントでインスタンス間のクエリまたは接続を終了できるため、クエリや接続が誤って終了してしまう心配はありません。クライアントを使用して任意のTiDBインスタンスに接続し、 `KILL`または`KILL TIDB`ステートメントを実行すると、ステートメントは対象のTiDBインスタンスに転送されます。クライアントとTiDBクラスタの間にプロキシが存在する場合、 `KILL`と`KILL TIDB`ステートメントも対象のTiDBインスタンスに転送され、実行されます。 +Global Kill機能を有効にすると、 `KILL`と`KILL TIDB`両方のステートメントでインスタンス間のクエリまたは接続を終了できるため、クエリや接続が誤って終了してしまう心配はありません。クライアントを使用して任意のTiDBインスタンスに接続し、 `KILL`または`KILL TIDB`ステートメントを実行すると、ステートメントは対象のTiDBインスタンスに転送されます。クライアントとTiDBクラスターの間にプロキシが存在する場合、 `KILL`と`KILL TIDB`ステートメントも対象のTiDBインスタンスに転送され、実行されます。 Global Kill 機能が有効になっていない場合、または v6.1.0 より前のバージョンの TiDB を使用している場合は、次の点に注意してください。 @@ -70,7 +70,7 @@ Global Kill 機能が有効になっていない場合、または v6.1.0 より -- クライアントが常に同じTiDBインスタンスに接続されることが確実でない限り、設定ファイルで[`compatible-kill-query = true`](/tidb-configuration-file.md#compatible-kill-query)設定することは**強く推奨されません**。これは、デフォルトのMySQLクライアントでControl+Cを押すと、新しい接続が開かれ、その中で`KILL`実行されるためです。クライアントとTiDBクラスタの間にプロキシが存在する場合、新しい接続が別のTiDBインスタンスにルーティングされ、誤って別のセッションが強制終了される可能性があります。 +- クライアントが常に同じTiDBインスタンスに接続されることが確実でない限り、設定ファイルで[`compatible-kill-query = true`](/tidb-configuration-file.md#compatible-kill-query)設定することは**強く推奨されません**。これは、デフォルトのMySQLクライアントでControl+Cを押すと、新しい接続が開かれ、その中で`KILL`実行されるためです。クライアントとTiDBクラスターの間にプロキシが存在する場合、新しい接続が別のTiDBインスタンスにルーティングされ、誤って別のセッションが強制終了される可能性があります。 diff --git a/sql-statements/sql-statement-load-data.md b/sql-statements/sql-statement-load-data.md index 8ba5a26dace56..9222683ba5520 100644 --- a/sql-statements/sql-statement-load-data.md +++ b/sql-statements/sql-statement-load-data.md @@ -67,17 +67,17 @@ TiDB Cloudを使用している場合、 `LOAD DATA`ステートメントを使 デフォルトでは、重複したデータはエラーの原因となります。 -### S3とGCSstorage {#s3-and-gcs-storage} +### S3とGCSストレージ {#s3-and-gcs-ストレージ} -`LOCAL`指定しない場合は、 [外部storage](/br/backup-and-restore-storages.md)で詳述されているように、ファイル パラメータは有効な S3 または GCS パスである必要があります。 +`LOCAL`指定しない場合は、 [外部ストレージ](/br/backup-and-restore-ストレージs.md)で詳述されているように、ファイル パラメータは有効な S3 または GCS パスである必要があります。 -`LOCAL`指定しない場合は、 [外部storage](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)で詳述されているように、ファイル パラメータは有効な S3 または GCS パスである必要があります。 +`LOCAL`指定しない場合は、 [外部ストレージ](https://docs.pingcap.com/tidb/stable/backup-and-restore-ストレージs)で詳述されているように、ファイル パラメータは有効な S3 または GCS パスである必要があります。 diff --git a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md index 812de84aaf9a2..55c673fc29926 100644 --- a/sql-statements/sql-statement-lock-tables-and-unlock-tables.md +++ b/sql-statements/sql-statement-lock-tables-and-unlock-tables.md @@ -104,7 +104,7 @@ ERROR 1066 (42000): Not unique table/alias: 't' - TiDBでは、セッションAが既にテーブルロックを保持している場合、セッションBがそのテーブルに書き込みを試みるとエラーが返されます。MySQLでは、セッションBの書き込み要求はセッションAがテーブルロックを解放するまでブロックされ、他のセッションからのテーブルロック要求は現在のセッションが`WRITE`ロックを解放するまでブロックされます。 - TiDBでは、 `LOCK TABLES`文に必要なロックが別のセッションによって保持されている場合、 `LOCK TABLES`の文は待機する必要があり、この文の実行時にエラーが返されます。MySQLでは、この文はロックが取得されるまでブロックされます。 -- TiDBでは、 `LOCK TABLES`文はクラスタ全体で有効です。MySQLでは、この文は現在のMySQLサーバーでのみ有効であり、NDBクラスタとは互換性がありません。 +- TiDBでは、 `LOCK TABLES`文はクラスター全体で有効です。MySQLでは、この文は現在のMySQLサーバーでのみ有効であり、NDBクラスターとは互換性がありません。 ### テーブルロックの解除 {#table-lock-release} diff --git a/sql-statements/sql-statement-overview.md b/sql-statements/sql-statement-overview.md index 66ef5f5a99edb..270d93e8acb8b 100644 --- a/sql-statements/sql-statement-overview.md +++ b/sql-statements/sql-statement-overview.md @@ -65,12 +65,12 @@ TiDBは、ISO/IEC SQL標準に準拠することを目的としたSQL文を使 | SQLステートメント | 説明 | | ------------------------------------------------------------------------- | ----------------------------------------- | -| [`BEGIN`](/sql-statements/sql-statement-begin.md) | 新しい取引を開始します。 | +| [`BEGIN`](/sql-statements/sql-statement-begin.md) | 新しいトランザクションを開始します。 | | [`COMMIT`](/sql-statements/sql-statement-commit.md) | 現在のトランザクションをコミットします。 | | [`ROLLBACK`](/sql-statements/sql-statement-rollback.md) | 現在のトランザクションをロールバックします。 | | [`SAVEPOINT`](/sql-statements/sql-statement-savepoint.md) | トランザクション内にセーブポイントを設定します。 | | [`SET TRANSACTION`](/sql-statements/sql-statement-set-transaction.md) | `GLOBAL`または`SESSION`に基づいて、現在の隔離レベルを変更します。 | -| [`START TRANSACTION`](/sql-statements/sql-statement-start-transaction.md) | 新しい取引を開始します。 | +| [`START TRANSACTION`](/sql-statements/sql-statement-start-transaction.md) | 新しいトランザクションを開始します。 | ## 準備された声明 {#prepared-statements} @@ -136,7 +136,7 @@ TiDBは、ISO/IEC SQL標準に準拠することを目的としたSQL文を使 | SQLステートメント | 説明 | | --------------------------------------------------------------------------- | --------------------------------------------- | -| [`BACKUP`](/sql-statements/sql-statement-backup.md) | TiDBクラスタの分散バックアップを実行します。 | +| [`BACKUP`](/sql-statements/sql-statement-backup.md) | TiDBクラスターの分散バックアップを実行します。 | | [`FLASHBACK CLUSTER`](/sql-statements/sql-statement-flashback-cluster.md) | クラスターを特定の時点のスナップショットに復元します。 | | [`FLASHBACK DATABASE`](/sql-statements/sql-statement-flashback-database.md) | `DROP`ステートメントによって削除されたデータベースとそのデータを復元します。 | | [`FLASHBACK TABLE`](/sql-statements/sql-statement-flashback-table.md) | `DROP`または`TRUNCATE`操作によって削除されたテーブルとデータを復元します。 | @@ -236,13 +236,13 @@ TiDBは、ISO/IEC SQL標準に準拠することを目的としたSQL文を使 | ----------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`ALTER INSTANCE`](/sql-statements/sql-statement-alter-instance.md) | インスタンスを変更します。 | | [`FLUSH STATUS`](/sql-statements/sql-statement-flush-status.md) | [MySQLとの互換性](/mysql-compatibility.md)のために含まれています。 TiDB は、ほとんどのメトリックに対して`SHOW STATUS`の代わりにプロメテウス[プロメテウスとグラファナ](/tidb-monitoring-framework.md)グラファナを使用して一元的なメトリック収集を行います。 | -| [`KILL`](/sql-statements/sql-statement-kill.md) | 現在の TiDB クラスタ内の任意の TiDB インスタンスの接続を切断します。 | +| [`KILL`](/sql-statements/sql-statement-kill.md) | 現在の TiDB クラスター内の任意の TiDB インスタンスの接続を切断します。 | | [`SHOW CONFIG`](/sql-statements/sql-statement-show-config.md) | TiDBの各種コンポーネントの設定を表示します。 | -| [`SHOW ENGINES`](/sql-statements/sql-statement-show-engines.md) | 利用可能なstorageエンジンを表示します。 | +| [`SHOW ENGINES`](/sql-statements/sql-statement-show-engines.md) | 利用可能なストレージエンジンを表示します。 | | [`SHOW PLUGINS`](/sql-statements/sql-statement-show-plugins.md) | インストールされているプラ​​グインを表示します。 | | [`SHOW PROCESSLIST`](/sql-statements/sql-statement-show-processlist.md) | 同じ TiDBサーバーに接続されている現在のセッションを表示します。 | | [`SHOW PROFILES`](/sql-statements/sql-statement-show-profiles.md) | [MySQLとの互換性](/mysql-compatibility.md)のために含まれています。現時点では、空の結果のみが返されます。 | -| [`SHUTDOWN`](/sql-statements/sql-statement-shutdown.md) | クライアントに接続されているTiDBインスタンスを停止します。TiDBクラスタ全体を停止するわけではありません。 | +| [`SHUTDOWN`](/sql-statements/sql-statement-shutdown.md) | クライアントに接続されているTiDBインスタンスを停止します。TiDBクラスター全体を停止するわけではありません。 | @@ -252,8 +252,8 @@ TiDBは、ISO/IEC SQL標準に準拠することを目的としたSQL文を使 | ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`ALTER INSTANCE`](/sql-statements/sql-statement-alter-instance.md) | インスタンスを変更します。 | | [`FLUSH STATUS`](/sql-statements/sql-statement-flush-status.md) | [MySQLとの互換性](/mysql-compatibility.md)のために含まれています。 TiDB Cloudは、ほとんどのメトリクスに対して`SHOW STATUS`の代わりに、一元化されたメトリクス収集のための[監視](/tidb-cloud/monitor-tidb-cluster.md)を提供します。 | -| [`KILL`](/sql-statements/sql-statement-kill.md) | 現在の TiDB クラスタ内の任意の TiDB インスタンスの接続を切断します。 | -| [`SHOW ENGINES`](/sql-statements/sql-statement-show-engines.md) | 利用可能なstorageエンジンを表示します。 | +| [`KILL`](/sql-statements/sql-statement-kill.md) | 現在の TiDB クラスター内の任意の TiDB インスタンスの接続を切断します。 | +| [`SHOW ENGINES`](/sql-statements/sql-statement-show-engines.md) | 利用可能なストレージエンジンを表示します。 | | [`SHOW PLUGINS`](/sql-statements/sql-statement-show-plugins.md) | インストールされているプラ​​グインを表示します。 | | [`SHOW PROCESSLIST`](/sql-statements/sql-statement-show-processlist.md) | 同じ TiDBサーバーに接続されている現在のセッションを表示します。 | | [`SHOW PROFILES`](/sql-statements/sql-statement-show-profiles.md) | クエリプロファイルを表示します。 [MySQLとの互換性](/mysql-compatibility.md)のために含まれています。現在は空の結果のみを返します。 | @@ -306,7 +306,7 @@ TiDBは、ISO/IEC SQL標準に準拠することを目的としたSQL文を使 > **注記：** > -> [TiCDC](https://docs.pingcap.com/tidb/stable/ticdc-overview)は、TiDBセルフマネージドの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-restore.md b/sql-statements/sql-statement-restore.md index 797fe7dae33b0..33b5e71713e0a 100644 --- a/sql-statements/sql-statement-restore.md +++ b/sql-statements/sql-statement-restore.md @@ -18,13 +18,13 @@ summary: TiDBデータベースにおけるRESTOREの使用方法の概要。 - 完全復元を実行する場合、復元対象のテーブルは既に存在してはなりません。既存のデータが上書きされ、データとインデックス間の不整合が発生する可能性があるためです。 - 増分復元を実行する場合、テーブルはバックアップが作成された時点の`LAST_BACKUP`タイムスタンプとまったく同じ状態である必要があります。 -`RESTORE`を実行するには`RESTORE_ADMIN`または`SUPER`権限が必要です。さらに、リストアを実行する TiDB ノードとクラスタ内のすべての TiKV ノードは、宛先からの読み取り権限を持っている必要があります。 +`RESTORE`を実行するには`RESTORE_ADMIN`または`SUPER`権限が必要です。さらに、リストアを実行する TiDB ノードとクラスター内のすべての TiKV ノードは、宛先からの読み取り権限を持っている必要があります。 `RESTORE`ステートメントはブロッキング処理であり、リストアタスク全体が完了、失敗、またはキャンセルされるまで終了しません。 `RESTORE`を実行するには、長時間接続を準備する必要があります。タスクは[`KILL TIDB QUERY`](/sql-statements/sql-statement-kill.md)ステートメントを使用してキャンセルできます。 `BACKUP`と`RESTORE`のタスクは、一度に 1 つしか実行できません。 `BACKUP`または`RESTORE`タスクが同じ TiDBサーバーで既に実行されている場合、新しい`RESTORE`実行は、以前のすべてのタスクが完了するまで待機します。 -`RESTORE` 「tikv」storageエンジンでのみ使用できます。「unistore」エンジンで`RESTORE`を使用すると失敗します。 +`RESTORE` 「tikv」ストレージエンジンでのみ使用できます。「unistore」エンジンで`RESTORE`を使用すると失敗します。 ## あらすじ {#synopsis} @@ -91,7 +91,7 @@ RESTORE DATABASE `test` FROM 'local:///mnt/backup/2020/04/'; RESTORE TABLE `test`.`sbtest01`, `test`.`sbtest02` FROM 'local:///mnt/backup/2020/04/'; ``` -### 外部ストレージ {#external-storages} +### 外部ストレージ {#external-ストレージs} BRはS3またはGCSからのデータ復元をサポートしています。 @@ -99,7 +99,7 @@ BRはS3またはGCSからのデータ復元をサポートしています。 RESTORE DATABASE * FROM 's3://example-bucket-2020/backup-05/'; ``` -URL 構文については[外部ストレージサービスのURI形式](/external-storage-uri.md)で詳しく説明します。 +URL 構文については[外部ストレージサービスのURI形式](/external-ストレージ-uri.md)で詳しく説明します。 認証情報を配布すべきでないクラウド環境で実行する場合は、 `SEND_CREDENTIALS_TO_TIKV`オプションを`FALSE`に設定してください。 diff --git a/sql-statements/sql-statement-rollback.md b/sql-statements/sql-statement-rollback.md index 331278d0bcfa2..0565726af5f06 100644 --- a/sql-statements/sql-statement-rollback.md +++ b/sql-statements/sql-statement-rollback.md @@ -47,4 +47,4 @@ Empty set (0.01 sec) - [セーブポイント](/sql-statements/sql-statement-savepoint.md) - [専念](/sql-statements/sql-statement-commit.md) - [始める](/sql-statements/sql-statement-begin.md) -- [取引を開始](/sql-statements/sql-statement-start-transaction.md) +- [トランザクションを開始](/sql-statements/sql-statement-start-transaction.md) diff --git a/sql-statements/sql-statement-savepoint.md b/sql-statements/sql-statement-savepoint.md index 4a5a8c0c651ba..8b6b618c65f56 100644 --- a/sql-statements/sql-statement-savepoint.md +++ b/sql-statements/sql-statement-savepoint.md @@ -155,6 +155,6 @@ TiDB は MySQL 構文`ROLLBACK WORK TO SAVEPOINT ...`サポートしていませ - [専念](/sql-statements/sql-statement-commit.md) - [ロールバック](/sql-statements/sql-statement-rollback.md) -- [取引を開始](/sql-statements/sql-statement-start-transaction.md) +- [トランザクションを開始](/sql-statements/sql-statement-start-transaction.md) - [TiDB 楽観的トランザクションモード](/optimistic-transaction.md) - [TiDB 悲観的トランザクションモード](/pessimistic-transaction.md) diff --git a/sql-statements/sql-statement-select.md b/sql-statements/sql-statement-select.md index f0bdf6b0709d2..d058fb51a4dd0 100644 --- a/sql-statements/sql-statement-select.md +++ b/sql-statements/sql-statement-select.md @@ -161,7 +161,7 @@ mysql> SELECT AVG(s_quantity), COUNT(s_quantity) FROM stock; > **注記：** > > - この記述はTiDB Self-Managedにのみ適用され、 [TiDB Cloud](https://docs.pingcap.com/tidbcloud/)では利用できません。 -> - このステートメントは、Amazon S3 や GCS などの[外部ストレージ](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)へのクエリ結果の書き込みをサポートしていません。 +> - このステートメントは、Amazon S3 や GCS などの[外部ストレージ](https://docs.pingcap.com/tidb/stable/backup-and-restore-ストレージs)へのクエリ結果の書き込みをサポートしていません。 ステートメントでは、以下の句を使用して出力ファイルの形式を指定できます。 diff --git a/sql-statements/sql-statement-show-builtins.md b/sql-statements/sql-statement-show-builtins.md index a0d7967cd4727..658c54637814e 100644 --- a/sql-statements/sql-statement-show-builtins.md +++ b/sql-statements/sql-statement-show-builtins.md @@ -160,8 +160,8 @@ SHOW BUILTINS; | json_schema_valid | | json_search | | json_set | - | json_storage_free | - | json_storage_size | + | json_ストレージ_free | + | json_ストレージ_size | | json_type | | json_unquote | | json_valid | diff --git a/sql-statements/sql-statement-show-create-placement-policy.md b/sql-statements/sql-statement-show-create-placement-policy.md index 9db86876d434d..777949dd4f2ce 100644 --- a/sql-statements/sql-statement-show-create-placement-policy.md +++ b/sql-statements/sql-statement-show-create-placement-policy.md @@ -5,7 +5,7 @@ summary: TiDBにおけるSHOW CREATE PLACEMENT POLICYの使用方法。 # 表示・作成・配置ポリシー {#show-create-placement-policy} -`SHOW CREATE PLACEMENT POLICY`配置ポリシーの定義を表示するために使用されます。これを使用すると、現在の配置ポリシーの定義を確認し、別の TiDB クラスタでそれを再現できます。 +`SHOW CREATE PLACEMENT POLICY`配置ポリシーの定義を表示するために使用されます。これを使用すると、現在の配置ポリシーの定義を確認し、別の TiDB クラスターでそれを再現できます。 > **注記：** > diff --git a/sql-statements/sql-statement-show-engines.md b/sql-statements/sql-statement-show-engines.md index 425e0f3448fa6..c9395ee0564f0 100644 --- a/sql-statements/sql-statement-show-engines.md +++ b/sql-statements/sql-statement-show-engines.md @@ -5,7 +5,7 @@ summary: TiDB データベースの SHOW ENGINES の使用法の概要。 # エンジンを表示 {#show-engines} -このステートメントは、サポートされているすべてのstorageエンジンを一覧表示するために使用されます。この構文は、MySQLとの互換性のためにのみ含まれています。 +このステートメントは、サポートされているすべてのストレージエンジンを一覧表示するために使用されます。この構文は、MySQLとの互換性のためにのみ含まれています。 ## 概要 {#synopsis} @@ -32,4 +32,4 @@ mysql> SHOW ENGINES; ## MySQLの互換性 {#mysql-compatibility} -- このステートメントは、サポートされているエンジンとして常にInnoDBのみを返します。TiDBは内部的に、storageエンジンとして通常[TiKV](/tikv-overview.md)使用します。 +- このステートメントは、サポートされているエンジンとして常にInnoDBのみを返します。TiDBは内部的に、ストレージエンジンとして通常[TiKV](/tikv-overview.md)使用します。 diff --git a/sql-statements/sql-statement-show-placement-for.md b/sql-statements/sql-statement-show-placement-for.md index e3da3e6268d5e..5b5f614ce9372 100644 --- a/sql-statements/sql-statement-show-placement-for.md +++ b/sql-statements/sql-statement-show-placement-for.md @@ -13,7 +13,7 @@ summary: TiDB における SHOW PLACEMENT FOR の使用方法。 このステートメントは`Scheduling_State`フィールドが配置Driver(PD) が配置スケジュールに関して現在行っている進捗状況を示す結果セットを返します。 -- `PENDING` : PD はまだ配置のスケジュールを開始していません。これは、配置ルールが意味的には正しいものの、現在のところクラスタで満たすことができないことを示している可能性があります。たとえば、 `FOLLOWERS=4`ですが、フォロワー候補となる TiKV ストアが 3 つしかない場合などです。 +- `PENDING` : PD はまだ配置のスケジュールを開始していません。これは、配置ルールが意味的には正しいものの、現在のところクラスターで満たすことができないことを示している可能性があります。たとえば、 `FOLLOWERS=4`ですが、フォロワー候補となる TiKV ストアが 3 つしかない場合などです。 - `INPROGRESS` : PD は現在配置のスケジュールを調整中です。 - `SCHEDULED` : PD は配置を正常にスケジュールしました。 diff --git a/sql-statements/sql-statement-show-placement.md b/sql-statements/sql-statement-show-placement.md index 0db35d128e9f6..17004b299d94f 100644 --- a/sql-statements/sql-statement-show-placement.md +++ b/sql-statements/sql-statement-show-placement.md @@ -13,7 +13,7 @@ summary: TiDBにおけるSHOW PLACEMENTの使用方法。 このステートメントは`Scheduling_State`フィールドが配置Driver(PD) が配置スケジュールに関して現在行っている進捗状況を示す結果セットを返します。 -- `PENDING` : PD はまだ配置のスケジュールを開始していません。これは、配置ルールが意味的には正しいものの、現在のところクラスタで満たすことができないことを示している可能性があります。たとえば、 `FOLLOWERS=4`ですが、フォロワー候補となる TiKV ストアが 3 つしかない場合などです。 +- `PENDING` : PD はまだ配置のスケジュールを開始していません。これは、配置ルールが意味的には正しいものの、現在のところクラスターで満たすことができないことを示している可能性があります。たとえば、 `FOLLOWERS=4`ですが、フォロワー候補となる TiKV ストアが 3 つしかない場合などです。 - `INPROGRESS` : PD は現在配置のスケジュールを調整中です。 - `SCHEDULED` : PD は配置を正常にスケジュールしました。 diff --git a/sql-statements/sql-statement-show-table-next-rowid.md b/sql-statements/sql-statement-show-table-next-rowid.md index 16c9b06947b64..599bc925f64d1 100644 --- a/sql-statements/sql-statement-show-table-next-rowid.md +++ b/sql-statements/sql-statement-show-table-next-rowid.md @@ -63,6 +63,6 @@ SHOW TABLE t NEXT_ROW_ID; ## 関連項目 {#see-also} - [テーブルを作成する](/sql-statements/sql-statement-create-table.md) -- [自動乱数](/auto-random.md) +- [AUTO_RANDOM](/auto-random.md) - [CREATE_SEQUENCE](/sql-statements/sql-statement-create-sequence.md) - [_tidb_rowid](/tidb-rowid.md) diff --git a/sql-statements/sql-statement-show-table-regions.md b/sql-statements/sql-statement-show-table-regions.md index 80c91a0e83275..ca3d57f2c5e73 100644 --- a/sql-statements/sql-statement-show-table-regions.md +++ b/sql-statements/sql-statement-show-table-regions.md @@ -154,7 +154,7 @@ mysql> SHOW TABLE t REGIONS; - テーブル t は 6 つの領域に対応しています。これらの領域では、 `102` 、 `106` 、 `110` 、 `114` 、および`3`に行データが格納され、 `98`にインデックスデータが格納されます。 - リージョン`START_KEY`の`END_KEY`および`102`について、 `t_43`はテーブルのプレフィックスと ID を示します。 `_r`テーブル t のレコード データのプレフィックスです。 `_i`はインデックス データのプレフィックスです。 -- リージョン`102` 、 `START_KEY` 、および`END_KEY`では、 `[-inf, 20000)`の範囲内のstorageデータが格納されます。同様に、領域 ( `106` 、 `110` 、 `114` 、 `3` ) におけるデータ格納範囲も計算できます。 +- リージョン`102` 、 `START_KEY` 、および`END_KEY`では、 `[-inf, 20000)`の範囲内のストレージデータが格納されます。同様に、領域 ( `106` 、 `110` 、 `114` 、 `3` ) におけるデータ格納範囲も計算できます。 - リージョン`98`にはインデックスデータが格納されます。テーブル t のインデックスデータの開始キーは`t_43_i`であり、これはリージョン`98`の範囲内にあります。 ストア1のテーブルtに対応するリージョンを確認するには、 `WHERE`句を使用します。 diff --git a/sql-statements/sql-statement-split-region.md b/sql-statements/sql-statement-split-region.md index a879b7d089e20..2065ea96e1bfd 100644 --- a/sql-statements/sql-statement-split-region.md +++ b/sql-statements/sql-statement-split-region.md @@ -5,7 +5,7 @@ summary: TiDBデータベースにおけるスプリットリージョンの使 # 分割リージョン {#split-region} -TiDBで新しいテーブルを作成するたびに、デフォルトで1つの[リージョン](/tidb-storage.md#region)が分割され、そのテーブルのデータが格納されます。このデフォルトの動作は、TiDB構成ファイルの`split-table`によって制御されます。このリージョン内のデータがデフォルトのリージョンサイズ制限を超えると、リージョンは2つに分割され始めます。 +TiDBで新しいテーブルを作成するたびに、デフォルトで1つの[リージョン](/tidb-ストレージ.md#region)が分割され、そのテーブルのデータが格納されます。このデフォルトの動作は、TiDB構成ファイルの`split-table`によって制御されます。このリージョン内のデータがデフォルトのリージョンサイズ制限を超えると、リージョンは2つに分割され始めます。 上記の場合、初期状態ではリージョンが1つしかないため、すべての書き込み要求はリージョンが配置されているTiKV上で発生します。新しく作成されたテーブルへの書き込みが大量に発生すると、ホットスポットが発生します。 @@ -358,7 +358,7 @@ SPLIT TABLE t1 INDEX idx4 BY ("a", "2000-01-01 00:00:01"), ("b", "2019-04-17 14: > > `PRE_SPLIT_REGIONS`の値は、 `SHARD_ROW_ID_BITS`または`AUTO_RANDOM`の値以下でなければなりません。 -[`tidb_scatter_region`](/system-variables.md#tidb_scatter_region)グローバル変数は`PRE_SPLIT_REGIONS`の動作に影響します。この変数は、テーブル作成後に結果を返す前に、リージョンが事前に分割され分散されるまで待機するかどうかを制御します。テーブル作成後に書き込みが集中する場合は、この変数の値を`global`に設定する必要があります。そうすると、TiDB はクラスタ全体のデータ分布に従って、新しく作成されたテーブルのリージョンを分散します。そうでない場合、TiDB は分散が完了する前にデータを書き込み、書き込みパフォーマンスに大きな影響を与えます。 +[`tidb_scatter_region`](/system-variables.md#tidb_scatter_region)グローバル変数は`PRE_SPLIT_REGIONS`の動作に影響します。この変数は、テーブル作成後に結果を返す前に、リージョンが事前に分割され分散されるまで待機するかどうかを制御します。テーブル作成後に書き込みが集中する場合は、この変数の値を`global`に設定する必要があります。そうすると、TiDB はクラスター全体のデータ分布に従って、新しく作成されたテーブルのリージョンを分散します。そうでない場合、TiDB は分散が完了する前にデータを書き込み、書き込みパフォーマンスに大きな影響を与えます。 ### pre_split_regionsの例 {#examples-of-pre-split-regions} diff --git a/sql-statements/sql-statement-start-transaction.md b/sql-statements/sql-statement-start-transaction.md index 3002efbe9f567..b77bf2753fa2c 100644 --- a/sql-statements/sql-statement-start-transaction.md +++ b/sql-statements/sql-statement-start-transaction.md @@ -3,7 +3,7 @@ title: START TRANSACTION | TiDB SQL Statement Reference summary: TiDB データベースの START TRANSACTION の使用法の概要。 --- -# 取引を開始 {#start-transaction} +# トランザクションを開始 {#start-transaction} この文はTiDB内で新しいトランザクションを開始します。これは文`BEGIN`と似ています。 @@ -49,4 +49,4 @@ Query OK, 0 rows affected (0.01 sec) - [専念](/sql-statements/sql-statement-commit.md) - [ロールバック](/sql-statements/sql-statement-rollback.md) - [始める](/sql-statements/sql-statement-begin.md) -- [因果関係の一貫性のみで取引を開始する](/transaction-overview.md#causal-consistency) +- [因果関係の一貫性のみでトランザクションを開始する](/transaction-overview.md#causal-consistency) diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index bdfe189f8e691..5aaa408e8abbc 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -117,7 +117,7 @@ TiDBダッシュボードに加えて、他のツールを使用してリソー ### 識別されたSQL文に関するデータを収集する {#gather-data-on-identified-sql-statements} -特定された上位のSQL文については、 [`PLAN REPLAYER`](/sql-plan-replayer.md)使用してTiDBクラスタからSQL実行情報を取得・保存できます。このツールは、さらなる分析のために実行環境を再現するのに役立ちます。SQL実行情報をエクスポートするには、次の構文を使用します。 +特定された上位のSQL文については、 [`PLAN REPLAYER`](/sql-plan-replayer.md)使用してTiDBクラスターからSQL実行情報を取得・保存できます。このツールは、さらなる分析のために実行環境を再現するのに役立ちます。SQL実行情報をエクスポートするには、次の構文を使用します。 ```sql PLAN REPLAYER DUMP EXPLAIN [ANALYZE] [WITH STATS AS OF TIMESTAMP expression] sql-statement; @@ -297,11 +297,11 @@ EXPLAIN SELECT id, name FROM emp WHERE id = 901; TiDBオプティマイザは、統計情報を用いてSQL文の各ステップで処理される行数を推定し、各ステップにコストを割り当てます。コストベースの最適化では、オプティマイザはインデックスアクセスや結合方法など、考えられるすべてのプランを評価し、各プランの合計コストを計算します。そして、合計コストが最小となる実行プランを選択します。 -次の図は、コストベース最適化において考慮される様々なデータアクセスパスと行セット操作を示しています。データ取得パスについては、オプティマイザーはインデックススキャンとフルテーブルスキャンのどちらが最も効率的な方法であるかを判断し、行ベースのTiKVstorageと列指向のTiFlashstorageのどちらからデータを取得するかを決定します。 +次の図は、コストベース最適化において考慮される様々なデータアクセスパスと行セット操作を示しています。データ取得パスについては、オプティマイザーはインデックススキャンとフルテーブルスキャンのどちらが最も効率的な方法であるかを判断し、行ベースのTiKVストレージと列指向のTiFlashストレージのどちらからデータを取得するかを決定します。 オプティマイザは、集計、結合、ソートなど、行セットを操作する操作も評価します。例えば、集計演算子では`HashAgg`または`StreamAgg`いずれかが使用される可能性がありますが、結合方法では`HashJoin` 、 `MergeJoin` 、または`IndexJoin`いずれかが選択されます。 -さらに、物理最適化フェーズでは、式と演算子を物理storageエンジンにプッシュダウンします。物理プランは、基盤となるstorageエンジンに基づいて、以下のように異なるコンポーネントに分配されます。 +さらに、物理最適化フェーズでは、式と演算子を物理ストレージエンジンにプッシュダウンします。物理プランは、基盤となるストレージエンジンに基づいて、以下のように異なるコンポーネントに分配されます。 - ルート タスクは TiDBサーバー上で実行されます。 - Cop (コプロセッサー) タスクは TiKV 上で実行されます。 @@ -542,7 +542,7 @@ LIMIT 3; ### TiDBのインデックス戦略 {#index-strategy-in-tidb} -TiDBは、SQLレイヤー（TiDBサーバー）とstorageレイヤー（TiKV）を分離した分散SQLデータベースです。従来のデータベースとは異なり、TiDBは計算ノードにデータをキャッシュするためにバッファプールを使用しません。そのため、SQLクエリのパフォーマンスとクラスタ全体のパフォーマンスは、処理が必要なキーバリュー（KV）RPCリクエストの数に依存します。一般的なKV RPCリクエストには、 `Point_Get` 、およびコプロセッサー`Batch_Point_Get`あります。 +TiDBは、SQLレイヤー（TiDBサーバー）とストレージレイヤー（TiKV）を分離した分散SQLデータベースです。従来のデータベースとは異なり、TiDBは計算ノードにデータをキャッシュするためにバッファプールを使用しません。そのため、SQLクエリのパフォーマンスとクラスター全体のパフォーマンスは、処理が必要なキーバリュー（KV）RPCリクエストの数に依存します。一般的なKV RPCリクエストには、 `Point_Get` 、およびコプロセッサー`Batch_Point_Get`あります。 TiDBのパフォーマンスを最適化するには、インデックスを効果的に使用することが不可欠です。インデックスはKV RPCリクエストの数を大幅に削減できるためです。KV RPCリクエストが減ることで、クエリのパフォーマンスとシステム効率が向上します。以下に、インデックスの最適化に役立つ主要な戦略をいくつか示します。 @@ -800,25 +800,25 @@ ANALYZE TABLE orders index idx_composite; ### TiFlashを使用する場合 {#when-to-use-tiflash} -このセクションでは、TiDBでTiFlashを使用するタイミングについて説明します。TiFlashは、複雑な計算、集計、大規模データセットのスキャンを伴う分析クエリに最適化されています。列指向storage形式とMPPモードにより、これらのシナリオにおけるパフォーマンスが大幅に向上します。 +このセクションでは、TiDBでTiFlashを使用するタイミングについて説明します。TiFlashは、複雑な計算、集計、大規模データセットのスキャンを伴う分析クエリに最適化されています。列指向ストレージ形式とMPPモードにより、これらのシナリオにおけるパフォーマンスが大幅に向上します。 TiFlash は次のシナリオで使用します。 -- 大規模データ分析： TiFlashは、大規模なデータスキャンを必要とするOLAPワークロードにおいて、より高速なパフォーマンスを提供します。列指向storageとMPP実行モードにより、TiKVと比較してクエリ効率が最適化されます。 +- 大規模データ分析： TiFlashは、大規模なデータスキャンを必要とするOLAPワークロードにおいて、より高速なパフォーマンスを提供します。列指向ストレージとMPP実行モードにより、TiKVと比較してクエリ効率が最適化されます。 - 複雑なスキャン、集計、結合: TiFlash は、必要な列のみを読み取ることで、集計や結合の負荷が高いクエリをより効率的に処理します。 - 混合ワークロード: トランザクション (OLTP) ワークロードと分析 (OLAP) ワークロードの両方が同時に実行されるハイブリッド環境では、 TiFlash はトランザクション クエリに対する TiKV のパフォーマンスに影響を与えずに分析クエリを処理します。 -- 任意のフィルタリング要件を持つSaaSアプリケーション：クエリでは、多くの場合、多数の列にまたがるフィルタリングが必要になります。すべての列にインデックスを付けるのは現実的ではなく、特にテナントIDがクエリの主キーの一部に含まれている場合はなおさらです。TiFlashは主キーに基づいてデータをソートおよびクラスタ化するため、このようなワークロードに最適です。TiFlashの[遅い実現](/tiflash/tiflash-late-materialization.md)機能により、効率的なテーブル範囲スキャンが可能になり、複数のインデックスを維持するオーバーヘッドなしでクエリパフォーマンスが向上します。 +- 任意のフィルタリング要件を持つSaaSアプリケーション：クエリでは、多くの場合、多数の列にまたがるフィルタリングが必要になります。すべての列にインデックスを付けるのは現実的ではなく、特にテナントIDがクエリの主キーの一部に含まれている場合はなおさらです。TiFlashは主キーに基づいてデータをソートおよびクラスター化するため、このようなワークロードに最適です。TiFlashの[遅い実現](/tiflash/tiflash-late-materialization.md)機能により、効率的なテーブル範囲スキャンが可能になり、複数のインデックスを維持するオーバーヘッドなしでクエリパフォーマンスが向上します。 TiFlash を戦略的に使用することで、クエリパフォーマンスが向上し、データ集約型の分析クエリにおける TiDB のリソース使用が最適化されます。以下のセクションでは、 TiFlashのユースケース例を紹介します。 #### 分析クエリ {#analytical-query} -このセクションでは、TiKV およびTiFlashstorageエンジンでの TPC-H クエリ 14 の実行パフォーマンスを比較します。 +このセクションでは、TiKV およびTiFlashストレージエンジンでの TPC-H クエリ 14 の実行パフォーマンスを比較します。 TPC-Hクエリ14は、テーブル`order_line`とテーブル`item`結合を伴います。このクエリはTiKVでは**21.1秒**かかりますが、 TiFlash MPPモードではわずか**1.41秒**で実行され、15倍の速度向上が見込まれます。 - TiKVプラン：TiDBはテーブル`lineitem`から3,864,397行、テーブル`part`から1000万行を取得します。ハッシュ結合演算（ `HashJoin_21` ）と、それに続く射影演算（ `Projection_38` ）および集計演算（ `HashAgg_9` ）はTiDB内で実行されます。 -- TiFlashプラン：オプティマイザーは、テーブル数`order_line`と`item`両方でTiFlashレプリカを検出します。TiDBはコスト見積もりに基づいて自動的にMPPモードを選択し、クエリ全体をTiFlash列指向storageエンジン内で実行します。これにはテーブルスキャン、ハッシュ結合、列プロジェクション、集計が含まれ、TiKVプランと比較してパフォーマンスが大幅に向上します。 +- TiFlashプラン：オプティマイザーは、テーブル数`order_line`と`item`両方でTiFlashレプリカを検出します。TiDBはコスト見積もりに基づいて自動的にMPPモードを選択し、クエリ全体をTiFlash列指向ストレージエンジン内で実行します。これにはテーブルスキャン、ハッシュ結合、列プロジェクション、集計が含まれ、TiKVプランと比較してパフォーマンスが大幅に向上します。 クエリは次のとおりです。 @@ -878,7 +878,7 @@ SaaSアプリケーションでは、テーブルでテナント識別情報を ##### パフォーマンス比較 {#performance-comparison} -異なるstorageエンジンで同じクエリを実行すると、パフォーマンスに大きな違いが見られます。 +異なるストレージエンジンで同じクエリを実行すると、パフォーマンスに大きな違いが見られます。 - TiKV プラン: TiKV ではクエリに 2 分 38.6 秒かかります。データが 5,121 のリージョンに分散されているため、 `TableRangeScan` 5,121 の cop タスクが送信されます。 - TiFlashプラン：同じクエリをTiFlash MPPエンジンで実行すると、わずか3.44秒で実行できます。これは約46倍の高速化です。TiFlashはデータを主キーでソートして保存するため、主キーのプレフィックスでフィルタリングされたクエリでは、テーブル全体をスキャンする代わりに`TableRangeScan`のタスクで済みます。TiFlashに必要なMPPタスクは、TiKVの5,121タスクと比較してわずか2タスクです。 @@ -950,4 +950,4 @@ TiFlash上の実行プランは次のとおりです。 - 大規模テナント: 大規模なデータセット (この場合は 1,000 万行など) を持つテナントの場合、 TiFlash は次の利点により効率的です。 - TiFlash は、特定のインデックスを必要とせずに動的なフィルタリング条件を処理します。 - TiDB は、 `COUNT` 、 `SORT` 、 `LIMIT`操作をTiFlashにプッシュダウンできます。 - - TiFlash は、列指向storageを使用して必要な列のみをスキャンします。 + - TiFlash は、列指向ストレージを使用して必要な列のみをスキャンします。 diff --git a/stale-read.md b/stale-read.md index 68d988eec2d05..5f2e893ff5740 100644 --- a/stale-read.md +++ b/stale-read.md @@ -5,7 +5,7 @@ summary: ステイル読み取りとその使用シナリオについて学習 # ステイル読み取りの使用シナリオ {#usage-scenarios-of-stale-read} -このドキュメントでは、 ステイル読み取りの使用シナリオについて説明します。Stale ステイル読み取り は、TiDB が TiDB に保存されているデータの履歴バージョンを読み取るために適用するメカニズムです。このメカニズムを使用することで、特定の時点または指定された時間範囲内の対応する履歴データを読み取ることができ、storageノード間のデータレプリケーションによって生じるレイテンシーを削減できます。 +このドキュメントでは、 ステイル読み取りの使用シナリオについて説明します。Stale ステイル読み取り は、TiDB が TiDB に保存されているデータの履歴バージョンを読み取るために適用するメカニズムです。このメカニズムを使用することで、特定の時点または指定された時間範囲内の対応する履歴データを読み取ることができ、ストレージノード間のデータレプリケーションによって生じるレイテンシーを削減できます。 ステイル読み取り を使用する場合、TiDBはデータ読み取りのためにレプリカをランダムに選択します。つまり、すべてのレプリカがデータ読み取りに利用可能になります。アプリケーションが非リアルタイムデータの読み取りを許容できない場合は、 ステイル読み取り を使用しないでください。そうしないと、レプリカから読み取られたデータがTiDBに書き込まれた最新のデータではない可能性があります。 @@ -13,7 +13,7 @@ summary: ステイル読み取りとその使用シナリオについて学習 -- シナリオ 1: トランザクションが読み取り操作のみを伴い、ある程度のデータの古さが許容される場合は、 ステイル読み取りを使用して履歴データを取得できます。 ステイル読み取りを使用すると、TiDB はリアルタイム パフォーマンスをある程度犠牲にしてクエリ要求を任意のレプリカに送信するため、クエリ実行のスループットが向上します。特に、小さなテーブルをクエリするシナリオでは、強力な一貫性のある読み取りを使用すると、リーダーが特定のstorageノードに集中し、クエリの負荷もそのノードに集中する可能性があります。そのため、そのノードがクエリ全体のボトルネックになる可能性があります。しかし、 ステイル読み取り を使用すると、クエリ全体のスループットが向上し、クエリのパフォーマンスが大幅に向上します。 +- シナリオ 1: トランザクションが読み取り操作のみを伴い、ある程度のデータの古さが許容される場合は、 ステイル読み取りを使用して履歴データを取得できます。 ステイル読み取りを使用すると、TiDB はリアルタイム パフォーマンスをある程度犠牲にしてクエリ要求を任意のレプリカに送信するため、クエリ実行のスループットが向上します。特に、小さなテーブルをクエリするシナリオでは、強力な一貫性のある読み取りを使用すると、リーダーが特定のストレージノードに集中し、クエリの負荷もそのノードに集中する可能性があります。そのため、そのノードがクエリ全体のボトルネックになる可能性があります。しかし、 ステイル読み取り を使用すると、クエリ全体のスループットが向上し、クエリのパフォーマンスが大幅に向上します。 - シナリオ 2: 地理的に分散したデプロイメントの一部のシナリオでは、フォロワーから読み取ったデータがLeaderに保存されているデータと整合していることを確認するために、強力な整合性を持つフォロワー読み取りを使用する場合、TiDB は検証のために異なるデータセンターに`Readindex`要求します。これにより、クエリプロセス全体のアクセスレイテンシーが増加します。Stale ステイル読み取りを使用すると、TiDB は現在のデータセンターのレプリカにアクセスして対応するデータを読み取りますが、リアルタイムパフォーマンスが多少犠牲になります。これにより、センター間接続によるネットワークレイテンシーが回避され、クエリ全体のアクセスレイテンシーが短縮されます。詳細については、 [3つのデータセンター展開におけるローカル読み取りのベストプラクティス](/best-practices/three-dc-local-read.md)参照してください。 @@ -21,7 +21,7 @@ summary: ステイル読み取りとその使用シナリオについて学習 -トランザクションが読み取り操作のみで、ある程度のデータの古さを許容する場合は、 ステイル読み取りを使用して履歴データを取得できます。 ステイル読み取りを使用すると、TiDB はリアルタイム パフォーマンスをある程度犠牲にしてクエリ要求を任意のレプリカに送信するため、クエリ実行のスループットが向上します。特に、小さなテーブルをクエリするシナリオでは、強力な一貫性のある読み取りを使用すると、リーダーが特定のstorageノードに集中し、クエリの負荷もそのノードに集中する可能性があります。そのため、そのノードがクエリ全体のボトルネックになる可能性があります。しかし、 ステイル読み取り を使用すると、全体的なクエリ スループットが向上し、クエリのパフォーマンスが大幅に向上します。 +トランザクションが読み取り操作のみで、ある程度のデータの古さを許容する場合は、 ステイル読み取りを使用して履歴データを取得できます。 ステイル読み取りを使用すると、TiDB はリアルタイム パフォーマンスをある程度犠牲にしてクエリ要求を任意のレプリカに送信するため、クエリ実行のスループットが向上します。特に、小さなテーブルをクエリするシナリオでは、強力な一貫性のある読み取りを使用すると、リーダーが特定のストレージノードに集中し、クエリの負荷もそのノードに集中する可能性があります。そのため、そのノードがクエリ全体のボトルネックになる可能性があります。しかし、 ステイル読み取り を使用すると、全体的なクエリ スループットが向上し、クエリのパフォーマンスが大幅に向上します。 @@ -39,7 +39,7 @@ TiDB は、次のようにステートメント レベル、セッション レ ### ステイル読み取りのレイテンシーを削減 {#reduce-stale-read-latency} -ステイル読み取り機能は、TiDBクラスタのResolved TSタイムスタンプを定期的に進め、TiDBがトランザクションの一貫性を満たすデータを読み取ることを保証します。Stale ステイル読み取りで使用されるタイムスタンプ（例： `AS OF TIMESTAMP '2016-10-08 16:45:26'` ）がResolved TSよりも大きい場合、 ステイル読み取りはTiDBにまずResolved TSを進めさせ、その完了を待ってからデータを読み取るようにトリガーします。これにより、レイテンシーが増加します。 +ステイル読み取り機能は、TiDBクラスターのResolved TSタイムスタンプを定期的に進め、TiDBがトランザクションの一貫性を満たすデータを読み取ることを保証します。Stale ステイル読み取りで使用されるタイムスタンプ（例： `AS OF TIMESTAMP '2016-10-08 16:45:26'` ）がResolved TSよりも大きい場合、 ステイル読み取りはTiDBにまずResolved TSを進めさせ、その完了を待ってからデータを読み取るようにトリガーします。これにより、レイテンシーが増加します。 ステイル読み取りのレイテンシーを短縮するには、次の TiKV 構成項目を変更して、TiDB が解決された TS タイムスタンプをより頻繁に進めるようにします。 diff --git a/statement-summary-tables.md b/statement-summary-tables.md index 6005d0521e5b8..29bb776e15ede 100644 --- a/statement-summary-tables.md +++ b/statement-summary-tables.md @@ -116,7 +116,7 @@ select * from employee where id in (...) and salary between ? and ?; ## ステートメントサマリーのclusterテーブル {#the-code-cluster-code-tables-for-statement-summary} -`statements_summary` 、 `statements_summary_history` 、および`statements_summary_evicted`テーブルには、単一の TiDBサーバーのステートメントの概要のみが表示されます。クラスタ全体のデータを照会するには、 `cluster_statements_summary` 、 `cluster_statements_summary_history` 、または`cluster_statements_summary_evicted`テーブルを照会する必要があります。 +`statements_summary` 、 `statements_summary_history` 、および`statements_summary_evicted`テーブルには、単一の TiDBサーバーのステートメントの概要のみが表示されます。クラスター全体のデータを照会するには、 `cluster_statements_summary` 、 `cluster_statements_summary_history` 、または`cluster_statements_summary_evicted`テーブルを照会する必要があります。 `cluster_statements_summary`には、各 TiDBサーバーの`statements_summary`データが表示されます。 `cluster_statements_summary_history`には、各 TiDBサーバーの`statements_summary_history`データが表示されます。 `cluster_statements_summary_evicted`には、各 TiDBサーバーの`statements_summary_evicted`データが表示されます。これらのテーブルでは`INSTANCE`フィールドを使用して TiDBサーバーのアドレスを表します。その他のフィールドは`statements_summary` 、 `statements_summary_history` 、および`statements_summary_evicted`と同じです。 @@ -406,7 +406,7 @@ TiKVコプロセッサータスクに関連するフィールド： - `MAX_PROCESSED_KEYS` :コプロセッサーが処理したキーの最大数。 - `AVG_TIKV_CPU_TIME` : このカテゴリの SQL ステートメントが消費する TiKVサーバーのCPU 時間の平均値。 -取引関連フィールド： +トランザクション関連フィールド： - `AVG_PREWRITE_TIME` : プリライトフェーズの平均時間。 - `MAX_PREWRITE_TIME` : プリライトフェーズの最長時間。 @@ -418,8 +418,8 @@ TiKVコプロセッサータスクに関連するフィールド： - `MAX_COMMIT_BACKOFF_TIME` : コミットフェーズ中に再試行が必要なエラーがSQLステートメントで発生した場合、再試行までの最大待機時間。 - `AVG_RESOLVE_LOCK_TIME` : トランザクション間で発生したロック競合の解決にかかる平均時間。 - `MAX_RESOLVE_LOCK_TIME` : ロック競合の解決に最も時間がかかったのはトランザクション間です。 -- `AVG_LOCAL_LATCH_WAIT_TIME` : ローカル取引の平均待ち時間。 -- `MAX_LOCAL_LATCH_WAIT_TIME` : ローカル取引の最大待ち時間。 +- `AVG_LOCAL_LATCH_WAIT_TIME` : ローカルトランザクションの平均待ち時間。 +- `MAX_LOCAL_LATCH_WAIT_TIME` : ローカルトランザクションの最大待ち時間。 - `AVG_WRITE_KEYS` : 入力されたキーの平均数。 - `MAX_WRITE_KEYS` : 書き込まれたキーの最大数。 - `AVG_WRITE_SIZE` : 書き込まれたデータの平均量（バイト単位）。 @@ -443,7 +443,7 @@ TiKVコプロセッサータスクに関連するフィールド： - `MAX_QUEUED_RC_TIME` : SQL ステートメントを実行する際に、使用可能な RU の最大待機時間。 - `RESOURCE_GROUP` : SQL ステートメントにバインドされたリソース グループ。 -storageエンジンに関連する分野： +ストレージエンジンに関連する分野： - `STORAGE_KV` : v8.5.5 で導入され、このカテゴリの SQL ステートメントの以前の実行が TiKV からデータを読み取ったかどうかを示します。 - `STORAGE_MPP` : v8.5.5 で導入され、このカテゴリの SQL ステートメントの以前の実行がTiFlashからデータを読み取ったかどうかを示します。 diff --git a/statistics.md b/statistics.md index ef62b41f007a3..f04a819a2533a 100644 --- a/statistics.md +++ b/statistics.md @@ -31,7 +31,7 @@ TiDBは、テーブルへの変更回数に基づいて、自動的に[`ANALYZE` | システム変数 | デフォルト値 | 説明 | | --------------------------------------------------------------------------------------------------------------------- | -------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| [`tidb_auto_analyze_concurrency`](/system-variables.md#tidb_auto_analyze_concurrency-new-in-v840) | `1` | TiDBクラスタ内における自動分析操作の並行処理。 | +| [`tidb_auto_analyze_concurrency`](/system-variables.md#tidb_auto_analyze_concurrency-new-in-v840) | `1` | TiDBクラスター内における自動分析操作の並行処理。 | | [`tidb_auto_analyze_end_time`](/system-variables.md#tidb_auto_analyze_end_time) | `23:59 +0000` | TiDBが自動更新を実行できる1日の終了時刻。 | | [`tidb_auto_analyze_partition_batch_size`](/system-variables.md#tidb_auto_analyze_partition_batch_size-new-in-v640) | `8192` | TiDBがパーティションテーブルを分析する際（つまり、パーティションテーブルの統計情報を自動的に更新する際）に自動的に分析するパーティションの数。 | | [`tidb_auto_analyze_ratio`](/system-variables.md#tidb_auto_analyze_ratio) | `0.5` | 自動更新のしきい値。 | @@ -254,7 +254,7 @@ TiDBは、統計情報の収集パフォーマンスを向上させるための2 TiDB v6.1.0以降では、システム変数[`tidb_mem_quota_analyze`](/system-variables.md#tidb_mem_quota_analyze-new-in-v610)を使用して、TiDBで統計情報を収集するためのメモリ割り当てを制御できます。 -`tidb_mem_quota_analyze`の適切な値を設定するには、クラスタのデータサイズを考慮してください。デフォルトのサンプリングレートを使用する場合、主な考慮事項は、列数、列値のサイズ、および TiDB のメモリ構成です。最大値と最小値を設定する際には、次の提案を参考にしてください。 +`tidb_mem_quota_analyze`の適切な値を設定するには、クラスターのデータサイズを考慮してください。デフォルトのサンプリングレートを使用する場合、主な考慮事項は、列数、列値のサイズ、および TiDB のメモリ構成です。最大値と最小値を設定する際には、次の提案を参考にしてください。 > **注記：** > @@ -385,7 +385,7 @@ WHERE db_name = 'test' AND table_name = 't' AND last_analyzed_at IS NOT NULL; ### 統計バージョンの切り替え {#switch-between-statistics-versions} -すべてのテーブル、インデックス、パーティションで同じ統計バージョンを使用することをお勧めします。クラスタでまだ統計バージョン1を使用している場合は、できるだけ早く統計バージョン2に移行してください。テーブル、インデックス、パーティションなどのオブジェクトに対してバージョン2の統計が収集されるまで、TiDBはそのオブジェクトに対して既存のバージョン1の統計を引き続き使用します。 +すべてのテーブル、インデックス、パーティションで同じ統計バージョンを使用することをお勧めします。クラスターでまだ統計バージョン1を使用している場合は、できるだけ早く統計バージョン2に移行してください。テーブル、インデックス、パーティションなどのオブジェクトに対してバージョン2の統計が収集されるまで、TiDBはそのオブジェクトに対して既存のバージョン1の統計を引き続き使用します。 移行の主な理由の1つは、Count-Min Sketchでハッシュ衝突が発生する可能性があるため、バージョン1ではequal/IN述語の推定値が不正確になる可能性があることです。詳細については、[カウントミニスケッチ](#count-min-sketch)参照してください。この問題を回避するには、 `tidb_analyze_version = 2`を設定し、すべてのオブジェクトで`ANALYZE`を再実行してください。 @@ -417,7 +417,7 @@ WHERE db_name = 'test' AND table_name = 't' AND last_analyzed_at IS NOT NULL; `ANALYZE`ステートメントを実行すると、 [`SHOW ANALYZE STATUS`](/sql-statements/sql-statement-show-analyze-status.md)を使用して`ANALYZE`の現在の状態を表示できます。 -TiDB v6.1.0 以降では、 `SHOW ANALYZE STATUS`ステートメントでクラスタレベルのタスクを表示できるようになりました。TiDB を再起動した後でも、このステートメントを使用すれば再起動前のタスクレコードを表示できます。TiDB v6.1.0 より前では、 `SHOW ANALYZE STATUS`ステートメントではインスタンスレベルのタスクしか表示できず、TiDB の再起動後にタスクレコードはクリアされていました。 +TiDB v6.1.0 以降では、 `SHOW ANALYZE STATUS`ステートメントでクラスターレベルのタスクを表示できるようになりました。TiDB を再起動した後でも、このステートメントを使用すれば再起動前のタスクレコードを表示できます。TiDB v6.1.0 より前では、 `SHOW ANALYZE STATUS`ステートメントではインスタンスレベルのタスクしか表示できず、TiDB の再起動後にタスクレコードはクリアされていました。 `SHOW ANALYZE STATUS`には、最新のタスク記録のみが表示されます。TiDB v6.1.0 以降では、システムテーブル`mysql.analyze_jobs`を通じて、過去 7 日間の履歴タスクを表示できます。 @@ -725,7 +725,7 @@ TiDB v6.0以降、TiDBは`KILL`ステートメントを使用して、バック - [`enable-global-kill`](/tidb-configuration-file.md#enable-global-kill-new-in-v610)が`true` (デフォルトでは`true` ) の場合、 `KILL TIDB ${id};`ステートメントを直接実行できます。ここで、 `${id}`は、前の手順で取得したバックグラウンド`ID`タスクの`ANALYZE`です。 - - `enable-global-kill`が`false`の場合、クライアントを使用してバックエンドの`ANALYZE`タスクを実行している TiDB インスタンスに接続し、 `KILL TIDB ${id};`ステートメントを実行する必要があります。クライアントを使用して別の TiDB インスタンスに接続する場合、またはクライアントと TiDB クラスタの間にプロキシがある場合、 `KILL`ステートメントではバックグラウンド`ANALYZE`タスクを終了できません。 + - `enable-global-kill`が`false`の場合、クライアントを使用してバックエンドの`ANALYZE`タスクを実行している TiDB インスタンスに接続し、 `KILL TIDB ${id};`ステートメントを実行する必要があります。クライアントを使用して別の TiDB インスタンスに接続する場合、またはクライアントと TiDB クラスターの間にプロキシがある場合、 `KILL`ステートメントではバックグラウンド`ANALYZE`タスクを終了できません。 diff --git a/storage-engine/rocksdb-overview.md b/storage-engine/rocksdb-overview.md index 601ea943217d4..2fa53a8d96700 100644 --- a/storage-engine/rocksdb-overview.md +++ b/storage-engine/rocksdb-overview.md @@ -6,7 +6,7 @@ category: reference # RocksDBの概要 {#rocksdb-overview} -[ロックスDB](https://github.com/facebook/rocksdb)は、キーと値の保存と読み書き関数を提供するLSMツリーstorageエンジンです。Facebookによって開発され、LevelDBをベースにしています。ユーザーが書き込んだキーと値のペアは、まずWrite Ahead Log（WAL）に挿入され、次にメモリ内のSkipList（ MemTableと呼ばれるデータ構造）に書き込まれます。LSMツリーエンジンは、ランダムな変更（挿入）をWALファイルへのシーケンシャルな書き込みに変換するため、Bツリーエンジンよりも優れた書き込みスループットを提供します。 +[ロックスDB](https://github.com/facebook/rocksdb)は、キーと値の保存と読み書き関数を提供するLSMツリーストレージエンジンです。Facebookによって開発され、LevelDBをベースにしています。ユーザーが書き込んだキーと値のペアは、まずWrite Ahead Log（WAL）に挿入され、次にメモリ内のSkipList（ MemTableと呼ばれるデータ構造）に書き込まれます。LSMツリーエンジンは、ランダムな変更（挿入）をWALファイルへのシーケンシャルな書き込みに変換するため、Bツリーエンジンよりも優れた書き込みスループットを提供します。 メモリ内のデータが一定サイズに達すると、RocksDBはその内容をディスク上のソート文字列テーブル（SST）ファイルにフラッシュします。SSTファイルは複数のレベル（デフォルトでは最大6レベル）で構成されています。あるレベルの合計サイズがしきい値に達すると、RocksDBはSSTファイルの一部を選択し、次のレベルにマージします。後続の各レベルは前のレベルの10倍の大きさになるため、データの90%が最終レイヤーに保存されます。 @@ -18,7 +18,7 @@ TiKV のアーキテクチャは次のようになります。 ![TiKV RocksDB](/media/tikv-rocksdb.png) -TiKVのstorageエンジンであるRocksDBは、 Raftログとユーザーデータの保存に使用されます。TiKVノード内のすべてのデータは、2つのRocksDBインスタンスを共有します。1つはRaftログ用（多くの場合raftdbと呼ばれます）、もう1つはユーザーデータとMVCCメタデータ用（多くの場合kvdbと呼ばれます）です。kvdbには、raft、lock、default、writeの4つのCFがあります。 +TiKVのストレージエンジンであるRocksDBは、 Raftログとユーザーデータの保存に使用されます。TiKVノード内のすべてのデータは、2つのRocksDBインスタンスを共有します。1つはRaftログ用（多くの場合raftdbと呼ばれます）、もう1つはユーザーデータとMVCCメタデータ用（多くの場合kvdbと呼ばれます）です。kvdbには、raft、lock、default、writeの4つのCFがあります。 - raft CF: 各リージョンのメタデータを保存します。非常に小さなスペースしか占有しないため、ユーザーは気にする必要はありません。 - ロックCF：悲観的トランザクションの悲観的ロックと、分散トランザクションの事前書き込みロックを保存します。トランザクションがコミットされると、ロックCF内の対応するデータは速やかに削除されます。そのため、ロックCFのデータサイズは通常非常に小さく（1GB未満）、増加した場合、大量のトランザクションがコミット待ち状態にあることを意味し、システムにバグや障害が発生している可能性があります。 @@ -29,13 +29,13 @@ TiKVのstorageエンジンであるRocksDBは、 Raftログとユーザーデー 読み取りパフォーマンスを向上させ、ディスクへの読み取り操作を削減するために、RocksDBはディスクに保存されているファイルを一定のサイズ（デフォルトは64KB）に基づいてブロックに分割します。ブロックを読み取る際、まずメモリ内のBlockCacheにデータが既に存在するかどうかを確認します。存在する場合、ディスクにアクセスすることなく、メモリから直接データを読み取ることができます。 -BlockCacheは、LRUアルゴリズムに従って最も最近使用されていないデータを破棄します。デフォルトでは、TiKVはシステムメモリの45%をBlockCacheに割り当てます。ユーザーは`storage.block-cache.capacity`設定を適切な値に変更することもできます。ただし、システムメモリ全体の60%を超えることは推奨されません。 +BlockCacheは、LRUアルゴリズムに従って最も最近使用されていないデータを破棄します。デフォルトでは、TiKVはシステムメモリの45%をBlockCacheに割り当てます。ユーザーは`ストレージ.block-cache.capacity`設定を適切な値に変更することもできます。ただし、システムメモリ全体の60%を超えることは推奨されません。 RocksDBに書き込まれるデータは、まずMemTableに書き込まれます。MemTableのサイズが128MBを超えると、新しいMemTableに切り替わります。TiKVには2つのRocksDBインスタンスがあり、合計4つのCFがあります。各CFのMemTableのサイズ制限は128MBです。同時に存在できるMemTableは最大5つです。それ以上の場合、フォアグラウンド書き込みはブロックされます。この部分が占有するメモリは最大2.5GB（4 x 5 x 128MB）です。メモリ消費量が少なくなるため、この制限を変更することは推奨されません。 ## RocksDB のスペース使用量 {#rocksdb-space-usage} -- マルチバージョン：RocksDBはLSMツリー構造のキーバリューstorageエンジンであるため、 MemTableのデータはまずL0にフラッシュされます。ファイルは生成順に並べられるため、L0ではSSTの範囲が重複する可能性があります。その結果、同じキーがL0で複数のバージョンを持つ場合があります。ファイルがL0からL1にマージされると、一定サイズ（デフォルトは8MB）の複数のファイルに分割されます。同じレベルの各ファイルのキー範囲は互いに重複しないため、L1以降のレベルでは各キーに対して1つのバージョンのみとなります。 +- マルチバージョン：RocksDBはLSMツリー構造のキーバリューストレージエンジンであるため、 MemTableのデータはまずL0にフラッシュされます。ファイルは生成順に並べられるため、L0ではSSTの範囲が重複する可能性があります。その結果、同じキーがL0で複数のバージョンを持つ場合があります。ファイルがL0からL1にマージされると、一定サイズ（デフォルトは8MB）の複数のファイルに分割されます。同じレベルの各ファイルのキー範囲は互いに重複しないため、L1以降のレベルでは各キーに対して1つのバージョンのみとなります。 - スペース増幅：各レベルのファイルの合計サイズは前のレベルのx倍（デフォルトは10）であるため、データの90%が最終レベルに保存されます。これは、RocksDBのスペース増幅が1.11を超えないことを意味します（L0はデータ量が少ないため無視できます）。 - TiKVの領域拡張：TiKVは独自のMVCC戦略を採用しています。ユーザーがキーを書き込むと、RocksDBに書き込まれる実際のデータはキー + commit_tsです。つまり、更新と削除によって新しいキーもRocksDBに書き込まれます。TiKVは一定間隔で古いバージョンのデータを削除します（RocksDBのDeleteインターフェース経由）。そのため、ユーザーがTiKVに保存するデータの実際の領域は、1.11に過去10分間に書き込まれたデータを加えたものと考えられます（TiKVが古いデータを速やかに削除すると仮定）。 diff --git a/storage-engine/titan-configuration.md b/storage-engine/titan-configuration.md index cc648e6baa9eb..8d775325a46c3 100644 --- a/storage-engine/titan-configuration.md +++ b/storage-engine/titan-configuration.md @@ -3,17 +3,17 @@ title: Titan Configuration summary: Titan の設定方法を学びます。 --- -# タイタンのコンフィグレーション {#titan-configuration} +# Titanの設定 {#titan-configuration} -このドキュメントでは、対応する構成項目、データ変換メカニズム、関連パラメータ、およびレベルマージ機能を使用して[タイタン](/storage-engine/titan-overview.md)有効または無効にする方法を紹介します。 +このドキュメントでは、対応する構成項目、データ変換メカニズム、関連パラメータ、およびレベルマージ機能を使用して[Titan](/ストレージ-engine/titan-overview.md)有効または無効にする方法を紹介します。 -## タイタンを有効にする {#enable-titan} +## Titanを有効にする {#enable-titan} > **注記：** > -> - TiDB v7.6.0以降、新規クラスタではTitanがデフォルトで有効化され、ワイドテーブルとJSONデータの書き込みパフォーマンスが向上します。1 [`min-blob-size`](/tikv-configuration-file.md#min-blob-size)のデフォルト値は`1KB`から`32KB`に変更されました。 +> - TiDB v7.6.0以降、新規クラスターではTitanがデフォルトで有効化され、ワイドテーブルとJSONデータの書き込みパフォーマンスが向上します。1 [`min-blob-size`](/tikv-configuration-file.md#min-blob-size)のデフォルト値は`1KB`から`32KB`に変更されました。 > - v7.6.0 以降のバージョンにアップグレードされた既存のクラスターは元の構成を保持します。つまり、Titan が明示的に有効になっていない場合は、引き続き RocksDB が使用されます。 -> - クラスタをTiDB v7.6.0以降のバージョンにアップグレードする前にTitanを有効にしていた場合、アップグレード後もTitanが有効になり、アップグレード前の設定値[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)も保持されます。アップグレード前に明示的に値を設定しない場合は、アップグレード後のクラスタ構成の安定性を確保するために、旧バージョンのデフォルト値`1KB`が保持されます。 +> - クラスターをTiDB v7.6.0以降のバージョンにアップグレードする前にTitanを有効にしていた場合、アップグレード後もTitanが有効になり、アップグレード前の設定値[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)も保持されます。アップグレード前に明示的に値を設定しない場合は、アップグレード後のクラスター構成の安定性を確保するために、旧バージョンのデフォルト値`1KB`が保持されます。 TitanはRocksDBと互換性があるため、RocksDBを使用する既存のTiKVインスタンスでTitanを直接有効化できます。Titanを有効化するには、以下のいずれかの方法があります。 @@ -61,13 +61,13 @@ TitanはRocksDBと互換性があるため、RocksDBを使用する既存のTiKV kubectl apply -f ${cluster_name} -n ${namespace} ``` - 詳細については[Kubernetes での TiDBクラスタの構成](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster)を参照してください。 + 詳細については[Kubernetes での TiDBクラスターの構成](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster)を参照してください。 ## データ変換 {#data-conversion} > **警告：** > -> Titanが無効になっている場合、RocksDBはTitanに移動されたデータを読み取ることができません。Titanが既に有効になっているTiKVインスタンスでTitanを誤って無効にした場合（誤って`rocksdb.titan.enabled`を`false`に設定した場合）、TiKVは起動に失敗し、TiKVログに`You have disabled titan when its data directory is not empty`エラーが表示されます。Titanを正しく無効にするには、 [タイタンを無効にする](#disable-titan)参照してください。 +> Titanが無効になっている場合、RocksDBはTitanに移動されたデータを読み取ることができません。Titanが既に有効になっているTiKVインスタンスでTitanを誤って無効にした場合（誤って`rocksdb.titan.enabled`を`false`に設定した場合）、TiKVは起動に失敗し、TiKVログに`You have disabled titan when its data directory is not empty`エラーが表示されます。Titanを正しく無効にするには、 [Titanを無効にする](#disable-titan)参照してください。 Titan を有効にした後、RocksDB に保存されている既存のデータは、すぐに Titan エンジンに移動されるわけではありません。新しいデータが TiKV に書き込まれ、RocksDB が圧縮を実行すると、**値は徐々にキーから分離され、 Titan に書き込まれます**。同様に、 BRスナップショット/ログを通じて復元されたデータ、スケーリング中に変換されたデータ、またはTiDB Lightning物理インポート モードによってインポートされたデータは、Titan に直接書き込まれません。圧縮が進むにつれて、処理された SST ファイル内のデフォルト値 ( `32KB` ) の[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)を超える大きな値が Titan に分離されます。TiKV**の詳細 > Titan kv > blob ファイル サイズ**パネルを観察してデータ サイズを見積もることで、Titan に保存されているファイルのサイズを監視できます。 @@ -81,7 +81,7 @@ Titanパラメータを適切に設定することで、データベースのパ ### min-blob-size {#code-min-blob-size-code} -[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)使用すると、RocksDB に保存するデータと Titan の BLOB ファイルに保存するデータを決定するための値のサイズのしきい値を設定できます。テストによると、適切なしきい値は`32KB`です。これにより、RocksDB と比較して Titan のパフォーマンスが低下しないことが保証されます。ただし、多くのシナリオでは、この値は最適ではありません。適切な値を選択するには、 [`min-blob-size`がパフォーマンスに与える影響](/storage-engine/titan-overview.md#impact-of-min-blob-size-on-performance)を参照することをお勧めします。書き込みパフォーマンスをさらに向上させ、スキャンパフォーマンスの低下を許容できる場合は、最小値の`1KB`に設定できます。 +[`min-blob-size`](/tikv-configuration-file.md#min-blob-size)使用すると、RocksDB に保存するデータと Titan の BLOB ファイルに保存するデータを決定するための値のサイズのしきい値を設定できます。テストによると、適切なしきい値は`32KB`です。これにより、RocksDB と比較して Titan のパフォーマンスが低下しないことが保証されます。ただし、多くのシナリオでは、この値は最適ではありません。適切な値を選択するには、 [`min-blob-size`がパフォーマンスに与える影響](/ストレージ-engine/titan-overview.md#impact-of-min-blob-size-on-performance)を参照することをお勧めします。書き込みパフォーマンスをさらに向上させ、スキャンパフォーマンスの低下を許容できる場合は、最小値の`1KB`に設定できます。 ### blob-file-compressionとzstd-dict-size {#code-blob-file-compression-code-and-code-zstd-dict-size-code} @@ -91,7 +91,7 @@ Titanパラメータを適切に設定することで、データベースのパ Titanの値のキャッシュサイズを制御するには、 [`blob-cache-size`](/tikv-configuration-file.md#blob-cache-size)使用します。キャッシュサイズが大きいほど、Titanの読み取りパフォーマンスが向上します。ただし、キャッシュサイズが大きすぎると、メモリ不足（OOM）の問題が発生します。 -ストアサイズからBLOBファイルサイズを引いた値を`storage.block-cache.capacity`に設定し、データベースが安定して動作している場合は、監視指標に応じて`blob-cache-size` ～ `memory size * 50% - block cache size`設定することをお勧めします。これにより、ブロックキャッシュがRocksDBエンジン全体に十分な大きさである場合に、BLOBキャッシュサイズが最大化されます。 +ストアサイズからBLOBファイルサイズを引いた値を`ストレージ.block-cache.capacity`に設定し、データベースが安定して動作している場合は、監視指標に応じて`blob-cache-size` ～ `memory size * 50% - block cache size`設定することをお勧めします。これにより、ブロックキャッシュがRocksDBエンジン全体に十分な大きさである場合に、BLOBキャッシュサイズが最大化されます。 ### discardable-ratioとmax-background-gc {#code-discardable-ratio-code-and-code-max-background-gc-code} @@ -130,7 +130,7 @@ blob-run-mode = "normal" level-merge = false ``` -## タイタンを無効にする {#disable-titan} +## Titanを無効にする {#disable-titan} Titanを無効にするには、オプション`rocksdb.defaultcf.titan.blob-run-mode`設定します。オプション`blob-run-mode`のオプション値は次のとおりです。 @@ -181,7 +181,7 @@ Titanを無効にするには、オプション`rocksdb.defaultcf.titan.blob-run ## レベルマージ（実験的） {#level-merge-experimental} -TiKV 4.0では、範囲クエリのパフォーマンスを向上させ、Titan GCによるフォアグラウンド書き込み操作への影響を軽減するための新しいアルゴリズム[レベルマージ](/storage-engine/titan-overview.md#level-merge)導入されました。レベルマージは、以下のオプションで有効にできます。 +TiKV 4.0では、範囲クエリのパフォーマンスを向上させ、Titan GCによるフォアグラウンド書き込み操作への影響を軽減するための新しいアルゴリズム[レベルマージ](/ストレージ-engine/titan-overview.md#level-merge)導入されました。レベルマージは、以下のオプションで有効にできます。 ```toml [rocksdb.defaultcf.titan] diff --git a/storage-engine/titan-overview.md b/storage-engine/titan-overview.md index 48bdcd427a8ad..791118592740d 100644 --- a/storage-engine/titan-overview.md +++ b/storage-engine/titan-overview.md @@ -1,13 +1,13 @@ --- title: Titan Overview -summary: Titanstorageエンジンの概要を学習します。 +summary: Titanストレージエンジンの概要を学習します。 --- -# タイタンの概要 {#titan-overview} +# Titanの概要 {#titan-overview} -[タイタン](https://github.com/pingcap/rocksdb/tree/titan-5.15)は、キーと値の分離を実現する高性能な[ロックスDB](https://github.com/facebook/rocksdb)プラグインです。Titanは、大きな値が使用される際のRocksDBでの書き込み増幅を軽減できます。 +[Titan](https://github.com/pingcap/rocksdb/tree/titan-5.15)は、キーと値の分離を実現する高性能な[ロックスDB](https://github.com/facebook/rocksdb)プラグインです。Titanは、大きな値が使用される際のRocksDBでの書き込み増幅を軽減できます。 -キーと値のペアの値のサイズが大きい場合（1KBまたは512Bを超える場合）、Titanは書き込み、更新、ポイント読み取りのシナリオにおいてRocksDBよりも優れたパフォーマンスを発揮します。ただし、Titanはstorage容量と範囲クエリのパフォーマンスを犠牲にすることで、より高い書き込みパフォーマンスを実現しています。SSDの価格が下がり続けるにつれて、このトレードオフはますます重要になるでしょう。 +キーと値のペアの値のサイズが大きい場合（1KBまたは512Bを超える場合）、Titanは書き込み、更新、ポイント読み取りのシナリオにおいてRocksDBよりも優れたパフォーマンスを発揮します。ただし、Titanはストレージ容量と範囲クエリのパフォーマンスを犠牲にすることで、より高い書き込みパフォーマンスを実現しています。SSDの価格が下がり続けるにつれて、このトレードオフはますます重要になるでしょう。 ## 主な特徴 {#key-features} @@ -29,11 +29,11 @@ Titan を有効にするための前提条件は次のとおりです。 - 値の平均サイズが大きい、またはすべての大きな値のサイズが値の合計サイズの大部分を占めています。現在、1KBを超える値のサイズは大きな値とみなされます。状況によっては、この数値（1KB）が512Bになる場合があります。TiKV Raftレイヤーの制限により、TiKVに書き込まれる単一の値は8MBを超えることはできません。1 [`raft-entry-max-size`](/tikv-configuration-file.md#raft-entry-max-size)設定値を調整することで、この制限を緩和できます。 - 範囲クエリは実行されないか、高い範囲クエリのパフォーマンスを必要としません。Titan に格納されるデータは整列されていないため、範囲クエリのパフォーマンスは RocksDB よりも低く、特に広い範囲のクエリではその傾向が顕著です。PingCAP の内部テストによると、Titan の範囲クエリのパフォーマンスは RocksDB よりも 40% から数倍低いことが示されています。 -- 十分なディスク容量（同じデータ量でRocksDBのディスク消費量の2倍の容量を確保することを検討してください）。これは、Titanがディスク容量を犠牲にして書き込み増幅を削減するためです。また、Titanは値を1つずつ圧縮するため、圧縮率はRocksDBよりも低くなります。RocksDBはブロックを1つずつ圧縮するため、TitanはRocksDBよりも多くのstorage容量を消費しますが、これは想定内の正常な動作です。状況によっては、Titanのstorage消費量がRocksDBの2倍になる場合があります。 +- 十分なディスク容量（同じデータ量でRocksDBのディスク消費量の2倍の容量を確保することを検討してください）。これは、Titanがディスク容量を犠牲にして書き込み増幅を削減するためです。また、Titanは値を1つずつ圧縮するため、圧縮率はRocksDBよりも低くなります。RocksDBはブロックを1つずつ圧縮するため、TitanはRocksDBよりも多くのストレージ容量を消費しますが、これは想定内の正常な動作です。状況によっては、Titanのストレージ消費量がRocksDBの2倍になる場合があります。 バージョン7.6.0以降、新規作成されたクラスターではTitanがデフォルトで有効になっています。小さなTiKV値はRocksDBに保存されたままなので、このシナリオでもTitanを有効にすることができます。 -Titan のパフォーマンスを向上させたい場合は、ブログ投稿[Titan: 書き込み増幅を減らす RocksDB プラグイン](https://pingcap.com/blog/titan-storage-engine-design-and-implementation/)参照してください。 +Titan のパフォーマンスを向上させたい場合は、ブログ投稿[Titan: 書き込み増幅を減らす RocksDB プラグイン](https://pingcap.com/blog/titan-ストレージ-engine-design-and-implementation/)参照してください。 ## アーキテクチャと実装 {#architecture-and-implementation} @@ -137,7 +137,7 @@ Titan は、選択された BLOB ファイルについて、各値に対応す 以下の表は、YCSBワークロードのQPSを異なる`min-blob-size`値に基づいて比較したものです。各テストラウンドでは、テストデータの行幅は`min-blob-size`に設定されており、Titanが有効な場合はデータがTitanに保存されます。 -| 行幅（バイト） | `Point_Get` | `Point_Get` （タイタン） | スキャン100 | scan100（タイタン） | スキャン10000 | scan10000（タイタン） | `UPDATE` | `UPDATE` （タイタン） | +| 行幅（バイト） | `Point_Get` | `Point_Get` （Titan） | スキャン100 | scan100（Titan） | スキャン10000 | scan10000（Titan） | `UPDATE` | `UPDATE` （Titan） | | ------- | ----------- | ------------------ | ------- | ------------- | --------- | --------------- | -------- | --------------- | | 1KB | 139255 | 140486 | 25171 | 21854 | 533 | 175 | 17913 | 30767 | | 2KB | 114201 | 124075 | 12466 | 11552 | 249 | 131 | 10369 | 27188 | diff --git a/sync-diff-inspector/sync-diff-inspector-overview.md b/sync-diff-inspector/sync-diff-inspector-overview.md index 854581f761e4c..26563767d90de 100644 --- a/sync-diff-inspector/sync-diff-inspector-overview.md +++ b/sync-diff-inspector/sync-diff-inspector-overview.md @@ -15,7 +15,7 @@ summary: sync-diff-inspectorを使用してデータを比較し、不整合な - データ不整合が存在する場合に、データ修復に使用するSQLステートメントを生成します。 - サポート[スキーマ名またはテーブル名が異なるテーブルのデータチェック](/sync-diff-inspector/route-diff.md) - Support[シャーディングシナリオにおけるデータチェック](/sync-diff-inspector/shard-diff.md) -- [TiDBアップストリーム/ダウンストリームクラスタのデータチェック](/ticdc/ticdc-upstream-downstream-check.md)サポート +- [TiDBアップストリーム/ダウンストリームクラスターのデータチェック](/ticdc/ticdc-upstream-downstream-check.md)サポート - Support [DMレプリケーションシナリオにおけるデータチェック](/sync-diff-inspector/dm-diff.md) ## sync-diff-inspectorをインストールしてください。 {#install-sync-diff-inspector} @@ -62,14 +62,14 @@ TiDB v8.5.6以降の場合： - `SELECT` : データを比較するために必要です。 - `RELOAD` : テーブルスキーマを表示するために必要です。 -- `PROCESS` : アップストリームとダウンストリームの両方が TiDB クラスタである場合に必須です。 `INFORMATION_SCHEMA.CLUSTER_INFO`テーブルをクエリするために使用されます。 +- `PROCESS` : アップストリームとダウンストリームの両方が TiDB クラスターである場合に必須です。 `INFORMATION_SCHEMA.CLUSTER_INFO`テーブルをクエリするために使用されます。 > **注記**： > > - すべてのデータベースに対して[`SHOW DATABASES`](/sql-statements/sql-statement-show-databases.md)権限を付与**しないでください**( `*.*` )。そうしないと、sync-diff-inspector がアクセスできないデータベースにアクセスしようとしてエラーが発生します。 > - MySQLデータソースの場合、 [`skip_show_database`](https://dev.mysql.com/doc/refman/8.4/en/server-system-variables.html#sysvar_skip_show_database)システム変数が`OFF`に設定されていることを確認してください。この変数が`ON`に設定されている場合、チェックが失敗する可能性があります。 -## コンフィグレーションファイルの説明 {#configuration-file-description} +## 設定ファイルの説明 {#configuration-file-description} sync-diff-inspectorの設定は、以下の部分から構成されます。 diff --git a/system-variable-reference.md b/system-variable-reference.md index 5eb64c29ab00f..4d6d620c8fbf9 100644 --- a/system-variable-reference.md +++ b/system-variable-reference.md @@ -201,7 +201,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [最適なパフォーマンスを得るための TiDB の設定](/tidb-performance-tuning-config.md) - [非トランザクションDMLステートメント](/non-transactional-dml.md) - [システム変数](/system-variables.md#autocommit) -- [取引](/transaction-overview.md) +- [トランザクション](/transaction-overview.md) ### ブロック暗号化モード {#block-encryption-mode} @@ -432,7 +432,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [システム変数](/system-variables.md#innodb_lock_wait_timeout) - [TiDB 悲観的トランザクションモード](/pessimistic-transaction.md) -- [TiKVコンフィグレーションファイル](/tikv-configuration-file.md) +- [TiKV設定ファイル](/tikv-configuration-file.md) - [ロック競合のトラブルシューティング](/troubleshoot-lock-conflicts.md) - [TiDB 3.0.6 リリースノート](/releases/release-3.0.6.md) @@ -443,7 +443,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [TiDB を使用したJavaアプリケーション開発のベスト プラクティス](/develop/java-app-best-practices.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [システム変数](/system-variables.md#interactive_timeout) -- [TiDBクラスタ管理に関する FAQ](/faq/manage-cluster-faq.md) +- [TiDBクラスター管理に関する FAQ](/faq/manage-cluster-faq.md) - [TiDBのタイムアウト](/develop/dev-guide-timeouts-in-tidb.md) - [TiDB 3.0 ベータ版リリースノート](/releases/release-3.0-beta.md) - [TiDB 3.0 GA リリースノート](/releases/release-3.0-ga.md) @@ -498,13 +498,13 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md) +- [DM 高度なタスク設定ファイル](/dm/task-configuration-file-full.md) - [TiDBデータ移行におけるエラーの処理](/dm/dm-error-handling.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [システム変数](/system-variables.md#max_allowed_packet-new-in-v610) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDBデータ移行に関するよくある質問](/dm/dm-faq.md) -- [TiDB Lightningコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md) +- [TiDB Lightning設定](/tidb-lightning/tidb-lightning-configuration.md) - [TiDB 6.1.0 リリースノート](/releases/release-6.1.0.md) - [TiDB 5.2.4 リリースノート](/releases/release-5.2.4.md) - [TiDB 3.0.2 リリースノート](/releases/release-3.0.2.md) @@ -517,11 +517,11 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [TiDBとProxySQLを統合する](/develop/dev-guide-proxysql-integration.md) -- [コンフィグレーションを動的に変更する](/dynamic-config.md) +- [設定を動的に変更する](/dynamic-config.md) - [データ移行の事前チェックエラー、移行エラー、アラート](https://docs.pingcap.com/tidbcloud/tidb-cloud-dm-precheck-and-troubleshooting) - [システム変数](/system-variables.md#max_connections) -- [TiDBクラスタ管理に関する FAQ](/faq/manage-cluster-faq.md) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDBクラスター管理に関する FAQ](/faq/manage-cluster-faq.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) ### 最大実行時間 {#max-execution-time} @@ -661,7 +661,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [集計（GROUP BY）関数](/functions-and-operators/aggregate-group-by-functions.md) -- [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md) +- [DM 高度なタスク設定ファイル](/dm/task-configuration-file-full.md) - [日付と時刻の型](/data-type-date-and-time.md) - [その他の機能](/functions-and-operators/miscellaneous-functions.md) - [パーティショニング](/partitioned-table.md) @@ -702,7 +702,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md) +- [DM 高度なタスク設定ファイル](/dm/task-configuration-file-full.md) - [システム変数](/system-variables.md#sql_require_primary_key-new-in-v630) - [TiDB 6.3.0 リリースノート](/releases/release-6.3.0.md) @@ -783,7 +783,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [インデックスの作成](/sql-statements/sql-statement-create-index.md) - [システム変数](/system-variables.md#tidb_allow_function_for_expression_index-new-in-v520) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDBの機能](/basic-features.md) ### tidb_allow_mpp {#tidb-allow-mpp} @@ -791,7 +791,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [MPPモードでステートメントを説明する](/explain-mpp.md) -- [HTAPを探索する](/explore-htap.md) +- [HTAP入門](/explore-htap.md) - [システム変数](/system-variables.md#tidb_allow_mpp-new-in-v50) - [TiFlashクエリ結果のマテリアライゼーション](/tiflash/tiflash-results-materialization.md) - [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md) @@ -1060,7 +1060,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [システム変数](/system-variables.md#tidb_check_mb4_value_in_utf8) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [アップグレードとアップグレード後のFAQ](/faq/upgrade-faq.md) ### tidb_checksum_table_concurrency {#tidb-checksum-table-concurrency} @@ -1069,14 +1069,14 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [システム変数](/system-variables.md#tidb_checksum_table_concurrency) -- [TiDB Lightningコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md) +- [TiDB Lightning設定](/tidb-lightning/tidb-lightning-configuration.md) -### tidb_クラウドストレージuri {#tidb-cloud-storage-uri} +### tidb_クラウドストレージuri {#tidb-cloud-ストレージ-uri} 参照先: - [インポート先](/sql-statements/sql-statement-import-into.md) -- [システム変数](/system-variables.md#tidb_cloud_storage_uri-new-in-v740) +- [システム変数](/system-variables.md#tidb_cloud_ストレージ_uri-new-in-v740) - [TiDBグローバルソート](/tidb-global-sort.md) - [TiDB 8.1.1 リリースノート](/releases/release-8.1.1.md) - [TiDB 7.4.0 リリースノート](/releases/release-7.4.0.md) @@ -1106,10 +1106,10 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [専念](/sql-statements/sql-statement-commit.md) - [制約](/constraints.md) -- [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md) +- [DM 高度なタスク設定ファイル](/dm/task-configuration-file-full.md) - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [システム変数](/system-variables.md#tidb_constraint_check_in_place) -- [取引](/transaction-overview.md) +- [トランザクション](/transaction-overview.md) - [TiDB 2.1.5 リリースノート](/releases/release-2.1.5.md) ### tidb_constraint_check_in_place_pessimistic {#tidb-constraint-check-in-place-pessimistic} @@ -1118,10 +1118,10 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [制約](/constraints.md) - [エラーコードとトラブルシューティング](/error-codes.md) -- [コンフィグレーションを動的に変更する](/dynamic-config.md) +- [設定を動的に変更する](/dynamic-config.md) - [セーブポイント](/sql-statements/sql-statement-savepoint.md) - [システム変数](/system-variables.md#tidb_constraint_check_in_place_pessimistic-new-in-v630) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB 悲観的トランザクションモード](/pessimistic-transaction.md) - [TiDB 6.5.0 リリースノート](/releases/release-6.5.0.md) - [TiDB 6.4.0 リリースノート](/releases/release-6.4.0.md) @@ -1141,15 +1141,15 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [プライマリクラスタとセカンダリクラスタに基づくDRソリューション](/dr-secondary-cluster.md) +- [プライマリクラスターとセカンダリクラスターに基づくDRソリューション](/dr-secondary-cluster.md) - [フラッシュバッククラスター](/sql-statements/sql-statement-flashback-cluster.md) -- [TiDBクラスタの移行とアップグレード](/tidb-upgrade-migration-guide.md) +- [TiDBクラスターの移行とアップグレード](/tidb-upgrade-migration-guide.md) - [`tidb_external_ts`変数を使用して履歴データを読み取る](/tidb-external-ts.md) - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [システム変数](/system-variables.md#tidb_current_ts) - [TiDB固有の機能](/functions-and-operators/tidb-functions.md) - [TiDB のタイムスタンプ Oracle (TSO)](/tso.md) -- [上流および下流のクラスタのデータ検証とスナップショットの読み取り](/ticdc/ticdc-upstream-downstream-check.md) +- [上流および下流のクラスターのデータ検証とスナップショットの読み取り](/ticdc/ticdc-upstream-downstream-check.md) ### tidb_ddl_ディスククォータ {#tidb-ddl-disk-quota} @@ -1170,9 +1170,9 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [インポート先](/sql-statements/sql-statement-import-into.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [システム変数](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB 分散実行フレームワーク (DXF)](/tidb-distributed-execution-framework.md) -- [TiDB環境とシステムコンフィグレーションのチェック](/check-before-deployment.md) +- [TiDB環境とシステム設定のチェック](/check-before-deployment.md) - [TiDBの機能](/basic-features.md) - [TiDB のソフトウェアおよびハードウェア要件](/hardware-and-software-requirements.md) - [TiDB 8.5.0 リリースノート](/releases/release-8.5.0.md) @@ -1288,7 +1288,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [システム変数](/system-variables.md#tidb_disable_txn_auto_retry) - [TiDB 楽観的トランザクションモデル](/optimistic-transaction.md) -- [取引](/transaction-overview.md) +- [トランザクション](/transaction-overview.md) - [TiDB 8.0.0 リリースノート](/releases/release-8.0.0.md) - [TiDB 7.6.0 リリースノート](/releases/release-7.6.0.md) - [TiDB 3.0.0-rc.2 リリースノート](/releases/release-3.0.0-rc.2.md) @@ -1339,7 +1339,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [コストの高いクエリを特定する](/identify-expensive-queries.md) - [パイプラインDML](/pipelined-dml.md) - [システム変数](/system-variables.md#tidb_dml_type-new-in-v800) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDBの機能](/basic-features.md) - [TiDB メモリ制御](/configure-memory-usage.md) - [TiDB 8.4.0 リリースノート](/releases/release-8.4.0.md) @@ -1353,9 +1353,9 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [システム変数](/system-variables.md#tidb_enable_1pc-new-in-v50) -- [TiDBクラスタ管理に関する FAQ](/faq/manage-cluster-faq.md) +- [TiDBクラスター管理に関する FAQ](/faq/manage-cluster-faq.md) - [TiDBの機能](/basic-features.md) -- [取引](/transaction-overview.md) +- [トランザクション](/transaction-overview.md) - [TiDB 5.0 リリースノート](/releases/release-5.0.0.md) ### tidb_enable_analyze_snapshot {#tidb-enable-analyze-snapshot} @@ -1371,9 +1371,9 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [システム変数](/system-variables.md#tidb_enable_async_commit-new-in-v50) -- [TiDBクラスタ管理に関する FAQ](/faq/manage-cluster-faq.md) +- [TiDBクラスター管理に関する FAQ](/faq/manage-cluster-faq.md) - [TiDBの機能](/basic-features.md) -- [取引](/transaction-overview.md) +- [トランザクション](/transaction-overview.md) - [TiDB 5.0 リリースノート](/releases/release-5.0.0.md) - [TiDB 5.0 RC リリースノート](/releases/release-5.0.0-rc.md) @@ -1399,7 +1399,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [SQLに関するよくある質問](/faq/sql-faq.md) - [システム変数](/system-variables.md#tidb_enable_auto_analyze-new-in-v610) -- [PLAN REPLAYERを使用してクラスタのオンサイト情報を保存および復元する](/sql-plan-replayer.md) +- [PLAN REPLAYERを使用してクラスターのオンサイト情報を保存および復元する](/sql-plan-replayer.md) - [TiDB 6.1.0 リリースノート](/releases/release-6.1.0.md) ### tidb_enable_auto_analyze_priority_queue {#tidb-enable-auto-analyze-priority-queue} @@ -1464,9 +1464,9 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [テーブルを作成する](/develop/dev-guide-create-table.md) - [システム変数](/system-variables.md#tidb_enable_clustered_index-new-in-v50) - [TiDB バックアップと復元の概要](/br/backup-and-restore-overview.md) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB データベース スキーマ設計の概要](/develop/dev-guide-schema-design-overview.md) -- [TiDB Lightningコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md) +- [TiDB Lightning設定](/tidb-lightning/tidb-lightning-configuration.md) - [TiDB 6.4.0 リリースノート](/releases/release-6.4.0.md) - [TiDB 5.0 リリースノート](/releases/release-5.0.0.md) - [TiDB 5.0 RC リリースノート](/releases/release-5.0.0-rc.md) @@ -1477,11 +1477,11 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [遅いクエリを特定する](/identify-slow-queries.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) -- [コンフィグレーションを動的に変更する](/dynamic-config.md) +- [設定を動的に変更する](/dynamic-config.md) - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [システム変数](/system-variables.md#tidb_enable_collect_execution_info) - [TIDB_インデックス_使用法](/information-schema/information-schema-tidb-index-usage.md) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB 8.0.0 リリースノート](/releases/release-8.0.0.md) - [TiDB 7.6.0 リリースノート](/releases/release-7.6.0.md) - [TiDB 7.5.1 リリースノート](/releases/release-7.5.1.md) @@ -1501,10 +1501,10 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) -- [コンフィグレーションを動的に変更する](/dynamic-config.md) +- [設定を動的に変更する](/dynamic-config.md) - [システム変数](/system-variables.md#tidb_enable_ddl-new-in-v630) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) -- [TiUPを使用した TiDB デプロイメントのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) +- [TiUPを使用した TiDB デプロイメントのトポロジ設定ファイル](/tiup/tiup-cluster-topology-reference.md) ### tidb_enable_dist_task {#tidb-enable-dist-task} @@ -1532,7 +1532,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [インポート先](/sql-statements/sql-statement-import-into.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [システム変数](/system-variables.md#tidb_enable_enhanced_security) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDBダッシュボードのユーザー管理](/dashboard/dashboard-user.md) - [TiDBの機能](/basic-features.md) - [TiDB 5.1 リリースノート](/releases/release-5.1.0.md) @@ -1556,10 +1556,10 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [プライマリクラスタとセカンダリクラスタに基づくDRソリューション](/dr-secondary-cluster.md) +- [プライマリクラスターとセカンダリクラスターに基づくDRソリューション](/dr-secondary-cluster.md) - [`tidb_external_ts`変数を使用して履歴データを読み取る](/tidb-external-ts.md) - [システム変数](/system-variables.md#tidb_enable_external_ts_read-new-in-v640) -- [上流および下流のクラスタのデータ検証とスナップショットの読み取り](/ticdc/ticdc-upstream-downstream-check.md) +- [上流および下流のクラスターのデータ検証とスナップショットの読み取り](/ticdc/ticdc-upstream-downstream-check.md) - [ステイル読み取りの使用シナリオ](/stale-read.md) - [TiDB 6.4.0 リリースノート](/releases/release-6.4.0.md) @@ -1629,7 +1629,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [システム変数](/system-variables.md#tidb_enable_historical_stats) -- [PLAN REPLAYERを使用してクラスタのオンサイト情報を保存および復元する](/sql-plan-replayer.md) +- [PLAN REPLAYERを使用してクラスターのオンサイト情報を保存および復元する](/sql-plan-replayer.md) - [TiDB 8.2.0 リリースノート](/releases/release-8.2.0.md) - [TiDB 7.5.7 リリースノート](/releases/release-7.5.7.md) - [TiDB 6.6.0 リリースノート](/releases/release-6.6.0.md) @@ -1869,7 +1869,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [システム変数](/system-variables.md#tidb_enable_plan_replayer_capture) -- [PLAN REPLAYERを使用してクラスタのオンサイト情報を保存および復元する](/sql-plan-replayer.md) +- [PLAN REPLAYERを使用してクラスターのオンサイト情報を保存および復元する](/sql-plan-replayer.md) - [TiDB 6.6.0 リリースノート](/releases/release-6.6.0.md) - [TiDB 6.5.0 リリースノート](/releases/release-6.5.0.md) @@ -1878,7 +1878,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [システム変数](/system-variables.md#tidb_enable_plan_replayer_continuous_capture-new-in-v700) -- [PLAN REPLAYERを使用してクラスタのオンサイト情報を保存および復元する](/sql-plan-replayer.md) +- [PLAN REPLAYERを使用してクラスターのオンサイト情報を保存および復元する](/sql-plan-replayer.md) - [TiDB 7.0.0 リリースノート](/releases/release-7.0.0.md) ### tidb_enable_point_get_cache {#tidb-enable-point-get-cache} @@ -1937,7 +1937,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [リソースグループの設定](/sql-statements/sql-statement-set-resource-group.md) - [システム変数](/system-variables.md#tidb_enable_resource_control-new-in-v660) -- [TiKVコンフィグレーションファイル](/tikv-configuration-file.md) +- [TiKV設定ファイル](/tikv-configuration-file.md) - [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md) - [`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md) - [TiDB 7.4.0 リリースノート](/releases/release-7.4.0.md) @@ -1977,11 +1977,11 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [遅いクエリを特定する](/identify-slow-queries.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) -- [コンフィグレーションを動的に変更する](/dynamic-config.md) +- [設定を動的に変更する](/dynamic-config.md) - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [TiDBダッシュボードのスロークエリページ](/dashboard/dashboard-slow-query.md) - [システム変数](/system-variables.md#tidb_enable_slow_log) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) ### tidb_enable_stats_owner {#tidb-enable-stats-owner} @@ -1989,7 +1989,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [統計入門](/statistics.md) - [システム変数](/system-variables.md#tidb_enable_stats_owner-new-in-v840) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB 8.4.0 リリースノート](/releases/release-8.4.0.md) ### tidb_enable_stmt_summary {#tidb-enable-stmt-summary} @@ -2041,7 +2041,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [TiDB 6.5.0 リリースノート](/releases/release-6.5.0.md) - [TiDB 6.3.0 リリースノート](/releases/release-6.3.0.md) -### tidb_enable_tmp_storage_on_oom {#tidb-enable-tmp-storage-on-oom} +### tidb_enable_tmp_ストレージ_on_oom {#tidb-enable-tmp-ストレージ-on-oom} 参照先: @@ -2049,8 +2049,8 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [接続プールと接続パラメータ](/develop/dev-guide-connection-parameters.md) - [ディスク流出時の暗号化機能を有効にする](/enable-disk-spill-encrypt.md) - [テーブル結合を使用するステートメントを説明する](/explain-joins.md) -- [システム変数](/system-variables.md#tidb_enable_tmp_storage_on_oom) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [システム変数](/system-variables.md#tidb_enable_tmp_ストレージ_on_oom) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB メモリ制御](/configure-memory-usage.md) ### tidb_enable_top_sql {#tidb-enable-top-sql} @@ -2112,11 +2112,11 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [HTAPを探索する](/explore-htap.md) +- [HTAP入門](/explore-htap.md) - [システム変数](/system-variables.md#tidb_enforce_mpp-new-in-v51) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiFlashクエリ結果のマテリアライゼーション](/tiflash/tiflash-results-materialization.md) -- [TiFlashクラスタのトラブルシューティング](/tiflash/troubleshoot-tiflash.md) +- [TiFlashクラスターのトラブルシューティング](/tiflash/troubleshoot-tiflash.md) - [TiFlash のパフォーマンスを調整する](/tiflash/tune-tiflash-performance.md) - [ステイル読み取りの使用シナリオ](/stale-read.md) - [TiFlash MPPモードを使用する](/tiflash/use-tiflash-mpp-mode.md) @@ -2175,10 +2175,10 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [コストの高いクエリを特定する](/identify-expensive-queries.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) -- [コンフィグレーションを動的に変更する](/dynamic-config.md) +- [設定を動的に変更する](/dynamic-config.md) - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [システム変数](/system-variables.md#tidb_expensive_query_time_threshold) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) ### tidb_expensive_txn_time_threshold {#tidb-expensive-txn-time-threshold} @@ -2191,10 +2191,10 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [プライマリクラスタとセカンダリクラスタに基づくDRソリューション](/dr-secondary-cluster.md) +- [プライマリクラスターとセカンダリクラスターに基づくDRソリューション](/dr-secondary-cluster.md) - [`tidb_external_ts`変数を使用して履歴データを読み取る](/tidb-external-ts.md) - [システム変数](/system-variables.md#tidb_external_ts-new-in-v640) -- [上流および下流のクラスタのデータ検証とスナップショットの読み取り](/ticdc/ticdc-upstream-downstream-check.md) +- [上流および下流のクラスターのデータ検証とスナップショットの読み取り](/ticdc/ticdc-upstream-downstream-check.md) - [ステイル読み取りの使用シナリオ](/stale-read.md) - [TiDB 6.4.0 リリースノート](/releases/release-6.4.0.md) @@ -2203,11 +2203,11 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) -- [コンフィグレーションを動的に変更する](/dynamic-config.md) +- [設定を動的に変更する](/dynamic-config.md) - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [SQLに関するよくある質問](/faq/sql-faq.md) - [システム変数](/system-variables.md#tidb_force_priority) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB 2.1.5 リリースノート](/releases/release-2.1.5.md) - [TiDB 2.1 RC3 リリースノート](/releases/release-2.1-rc.3.md) @@ -2215,7 +2215,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [ガベージコレクションのコンフィグレーション](/garbage-collection-configuration.md) +- [ガベージコレクションの設定](/garbage-collection-configuration.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [システム変数](/system-variables.md#tidb_gc_concurrency-new-in-v50) - [TiDB 8.3.0 リリースノート](/releases/release-8.3.0.md) @@ -2225,13 +2225,13 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [プライマリクラスタとセカンダリクラスタに基づくDRソリューション](/dr-secondary-cluster.md) -- [ガベージコレクションのコンフィグレーション](/garbage-collection-configuration.md) +- [プライマリクラスターとセカンダリクラスターに基づくDRソリューション](/dr-secondary-cluster.md) +- [ガベージコレクションの設定](/garbage-collection-configuration.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [TiDB から MySQL 互換データベースへのデータ移行](/migrate-from-tidb-to-mysql.md) -- [ある TiDBクラスタから別の TiDBクラスタに移行する](/migrate-from-tidb-to-tidb.md) -- [TiDBセルフマネージドからTiDB Cloudへの移行](https://docs.pingcap.com/tidbcloud/migrate-from-op-tidb) -- [プライマリクラスタとセカンダリクラスタ間でデータを複製する](/replicate-between-primary-and-secondary-clusters.md) +- [ある TiDBクラスターから別の TiDBクラスターに移行する](/migrate-from-tidb-to-tidb.md) +- [TiDB Self-ManagedからTiDB Cloudへの移行](https://docs.pingcap.com/tidbcloud/migrate-from-op-tidb) +- [プライマリクラスターとセカンダリクラスター間でデータを複製する](/replicate-between-primary-and-secondary-clusters.md) - [システム変数](/system-variables.md#tidb_gc_enable-new-in-v50) - [TiDB トラブルシューティング マップ](/tidb-troubleshooting-map.md) - [TiDB 5.0 リリースノート](/releases/release-5.0.0.md) @@ -2244,8 +2244,8 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [フラッシュバッククラスター](/sql-statements/sql-statement-flashback-cluster.md) - [フラッシュバックデータベース](/sql-statements/sql-statement-flashback-database.md) - [フラッシュバックテーブル](/sql-statements/sql-statement-flashback-table.md) -- [ガベージコレクションのコンフィグレーション](/garbage-collection-configuration.md) -- [TiDBクラスタの移行とアップグレード](/tidb-upgrade-migration-guide.md) +- [ガベージコレクションの設定](/garbage-collection-configuration.md) +- [TiDBクラスターの移行とアップグレード](/tidb-upgrade-migration-guide.md) - [システム変数`tidb_snapshot`を使用して履歴データを読み取る](/read-historical-data.md) - [Kafka にデータを複製する](/ticdc/ticdc-sink-to-kafka.md) - [SQLに関するよくある質問](/faq/sql-faq.md) @@ -2266,7 +2266,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [ガベージコレクションのコンフィグレーション](/garbage-collection-configuration.md) +- [ガベージコレクションの設定](/garbage-collection-configuration.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [パイプラインDML](/pipelined-dml.md) - [システム変数](/system-variables.md#tidb_gc_max_wait_time-new-in-v610) @@ -2276,7 +2276,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [ガベージコレクションのコンフィグレーション](/garbage-collection-configuration.md) +- [ガベージコレクションの設定](/garbage-collection-configuration.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [システム変数](/system-variables.md#tidb_gc_run_interval-new-in-v50) - [TiDB 5.0 リリースノート](/releases/release-5.0.0.md) @@ -2286,7 +2286,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [GCの概要](/garbage-collection-overview.md) -- [ガベージコレクションのコンフィグレーション](/garbage-collection-configuration.md) +- [ガベージコレクションの設定](/garbage-collection-configuration.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [システム変数](/system-variables.md#tidb_gc_scan_lock_mode-new-in-v50) - [TiDBの機能](/basic-features.md) @@ -2297,11 +2297,11 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [コンフィグレーションオプション](/command-line-flags-for-tidb-configuration.md) +- [設定オプション](/command-line-flags-for-tidb-configuration.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [システム変数](/system-variables.md#tidb_general_log) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDBデータ移行に関するよくある質問](/dm/dm-faq.md) - [TiDB 8.0.0 リリースノート](/releases/release-8.0.0.md) @@ -2401,7 +2401,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [接続プールと接続パラメータ](/develop/dev-guide-connection-parameters.md) - [システム変数](/system-variables.md#tidb_idle_transaction_timeout-new-in-v760) -- [TiDBクラスタ管理に関する FAQ](/faq/manage-cluster-faq.md) +- [TiDBクラスター管理に関する FAQ](/faq/manage-cluster-faq.md) - [TiDBの機能](/basic-features.md) - [TiDBのタイムアウト](/develop/dev-guide-timeouts-in-tidb.md) - [TiDB 7.6.0 リリースノート](/releases/release-7.6.0.md) @@ -2535,7 +2535,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [システム変数](/system-variables.md#tidb_last_plan_replayer_token-new-in-v630) -- [PLAN REPLAYERを使用してクラスタのオンサイト情報を保存および復元する](/sql-plan-replayer.md) +- [PLAN REPLAYERを使用してクラスターのオンサイト情報を保存および復元する](/sql-plan-replayer.md) - [TiDB 6.3.0 リリースノート](/releases/release-6.3.0.md) ### tidb_last_query_info {#tidb-last-query-info} @@ -2674,7 +2674,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [TiFlashの設定](/tiflash/tiflash-configuration.md) -- [コンフィグレーションを動的に変更する](/dynamic-config.md) +- [設定を動的に変更する](/dynamic-config.md) - [システム変数](/system-variables.md#tidb_max_tiflash_threads-new-in-v610) - [2022年のTiDB Cloudリリースノート](https://docs.pingcap.com/tidbcloud/release-notes-2022) - [TiFlash のパフォーマンスを調整する](/tiflash/tune-tiflash-performance.md) @@ -2732,7 +2732,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [システム変数](/system-variables.md#tidb_mem_quota_query) - [2022年のTiDB Cloudリリースノート](https://docs.pingcap.com/tidbcloud/release-notes-2022) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB メモリ制御](/configure-memory-usage.md) - [TiDB トラブルシューティング マップ](/tidb-troubleshooting-map.md) - [TiFlashクエリ結果のマテリアライゼーション](/tiflash/tiflash-results-materialization.md) @@ -2964,7 +2964,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [クエリの最適化](/agg-distinct-optimization.md) - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [システム変数](/system-variables.md#tidb_opt_distinct_agg_push_down) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiFlash のパフォーマンスを調整する](/tiflash/tune-tiflash-performance.md) ### tidb_opt_enable_correlation_adjustment {#tidb-opt-enable-correlation-adjustment} @@ -3494,17 +3494,17 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) -- [コンフィグレーションを動的に変更する](/dynamic-config.md) +- [設定を動的に変更する](/dynamic-config.md) - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [システム変数](/system-variables.md#tidb_record_plan_in_slow_log) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB 3.0.5 リリースノート](/releases/release-3.0.5.md) ### tidb_redact_log {#tidb-redact-log} 参照先: -- [コンフィグレーションオプション](/command-line-flags-for-tidb-configuration.md) +- [設定オプション](/command-line-flags-for-tidb-configuration.md) - [遅いクエリを特定する](/identify-slow-queries.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [ログ編集](/log-redaction.md) @@ -3593,7 +3593,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [システム変数](/system-variables.md#tidb_retry_limit) - [TiDB 楽観的トランザクションモデル](/optimistic-transaction.md) - [TiDB 悲観的トランザクションモード](/pessimistic-transaction.md) -- [取引](/transaction-overview.md) +- [トランザクション](/transaction-overview.md) - [ロック競合のトラブルシューティング](/troubleshoot-lock-conflicts.md) - [TiDB 2.1 ベータ版リリースノート](/releases/release-2.1-beta.md) - [TiDB 2.1 GA リリースノート](/releases/release-2.1-ga.md) @@ -3666,7 +3666,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [メモリ使用量](/information-schema/information-schema-memory-usage.md) - [メモリ使用量オペレーション履歴](/information-schema/information-schema-memory-usage-ops-history.md) - [システム変数](/system-variables.md#tidb_server_memory_limit-new-in-v640) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB メモリ制御](/configure-memory-usage.md) - [TiDB OOM の問題のトラブルシューティング](/troubleshoot-tidb-oom.md) - [TiDB 8.0.0 リリースノート](/releases/release-8.0.0.md) @@ -3703,7 +3703,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [管理者 SHOW DDL [ジョブ|ジョブクエリ]](/sql-statements/sql-statement-admin-show-ddl.md) -- [コンフィグレーションオプション](/command-line-flags-for-tidb-configuration.md) +- [設定オプション](/command-line-flags-for-tidb-configuration.md) - [IMPORT INTO とTiDB Lightning](/tidb-lightning/import-into-vs-tidb-lightning.md) - [システム変数](/system-variables.md#tidb_service_scope-new-in-v740) - [TiDB 分散実行フレームワーク (DXF)](/tidb-distributed-execution-framework.md) @@ -3786,7 +3786,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [文字セットと照合順序](/character-set-and-collation.md) -- [DM 高度なタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md) +- [DM 高度なタスク設定ファイル](/dm/task-configuration-file-full.md) - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [システム変数](/system-variables.md#tidb_skip_utf8_check) - [TiDB トラブルシューティング マップ](/tidb-troubleshooting-map.md) @@ -3799,13 +3799,13 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [SQLチューニングの実践ガイド](/sql-tuning-best-practice.md) - [遅いクエリを特定する](/identify-slow-queries.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) -- [コンフィグレーションを動的に変更する](/dynamic-config.md) +- [設定を動的に変更する](/dynamic-config.md) - [概要ページ](/dashboard/dashboard-overview.md) -- [TiDBセルフマネージドのクイックスタート](/quick-start-with-tidb.md) +- [TiDB Self-Managedのクイックスタート](/quick-start-with-tidb.md) - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [TiDBダッシュボードのスロークエリページ](/dashboard/dashboard-slow-query.md) - [システム変数](/system-variables.md#tidb_slow_log_threshold) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB デプロイメントに関する FAQ](/faq/deploy-and-maintain-faq.md) - [TiDB 2.1 GA リリースノート](/releases/release-2.1-ga.md) - [TiDB 2.1 RC5 リリースノート](/releases/release-2.1-rc.5.md) @@ -3891,7 +3891,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [統計入門](/statistics.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [システム変数](/system-variables.md#tidb_stats_load_sync_wait-new-in-v540) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB 8.0.0 リリースノート](/releases/release-8.0.0.md) - [TiDB 6.4.0 リリースノート](/releases/release-6.4.0.md) - [TiDB 5.4 リリースノート](/releases/release-5.4.0.md) @@ -3910,7 +3910,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [明細書要約表](/statement-summary-tables.md) - [システム変数](/system-variables.md#tidb_stmt_summary_enable_persistent-new-in-v660) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB 6.6.0 リリースノート](/releases/release-6.6.0.md) ### tidb_stmt_summary_file_max_backups {#tidb-stmt-summary-file-max-backups} @@ -3919,7 +3919,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [明細書要約表](/statement-summary-tables.md) - [システム変数](/system-variables.md#tidb_stmt_summary_file_max_backups-new-in-v660) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB 6.6.0 リリースノート](/releases/release-6.6.0.md) ### tidb_stmt_summary_file_max_days {#tidb-stmt-summary-file-max-days} @@ -3928,7 +3928,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [明細書要約表](/statement-summary-tables.md) - [システム変数](/system-variables.md#tidb_stmt_summary_file_max_days-new-in-v660) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB 6.6.0 リリースノート](/releases/release-6.6.0.md) ### tidb_stmt_summary_file_max_size {#tidb-stmt-summary-file-max-size} @@ -3937,7 +3937,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [明細書要約表](/statement-summary-tables.md) - [システム変数](/system-variables.md#tidb_stmt_summary_file_max_size-new-in-v660) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB 6.6.0 リリースノート](/releases/release-6.6.0.md) ### tidb_stmt_summary_filename {#tidb-stmt-summary-filename} @@ -3946,7 +3946,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [明細書要約表](/statement-summary-tables.md) - [システム変数](/system-variables.md#tidb_stmt_summary_filename-new-in-v660) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB 6.6.0 リリースノート](/releases/release-6.6.0.md) ### tidb_stmt_summary_history_size {#tidb-stmt-summary-history-size} @@ -4030,7 +4030,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: -- [TiDBクラスタの移行とアップグレード](/tidb-upgrade-migration-guide.md) +- [TiDBクラスターの移行とアップグレード](/tidb-upgrade-migration-guide.md) - [システム変数](/system-variables.md#tidb_super_read_only-new-in-v531) - [TiDB 5.4.1 リリースノート](/releases/release-5.4.1.md) - [TiDB 5.3.1 リリースノート](/releases/release-5.3.1.md) @@ -4213,7 +4213,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [システム変数](/system-variables.md#tidb_txn_entry_size_limit-new-in-v760) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [トランザクション制限](/develop/dev-guide-transaction-restraints.md) - [TiDB Lightningのトラブルシューティング](/tidb-lightning/troubleshoot-tidb-lightning.md) - [TiDB 8.5.2 リリースノート](/releases/release-8.5.2.md) @@ -4229,9 +4229,9 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [MySQL互換データベースにデータを複製する](/ticdc/ticdc-sink-to-mysql.md) - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [システム変数](/system-variables.md#tidb_txn_mode) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [TiDB 悲観的トランザクションモード](/pessimistic-transaction.md) -- [取引](/transaction-overview.md) +- [トランザクション](/transaction-overview.md) - [TiDB 6.0.0 リリースノート](/releases/release-6.0.0-dmr.md) - [TiDB 5.0 リリースノート](/releases/release-5.0.0.md) - [TiDB 3.0.8 リリースノート](/releases/release-3.0.8.md) @@ -4341,7 +4341,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 参照先: - [日付と時刻の型](/data-type-date-and-time.md) -- [TiDBセルフマネージドからTiDB Cloudへの移行](https://docs.pingcap.com/tidbcloud/migrate-from-op-tidb) +- [TiDB Self-ManagedからTiDB Cloudへの移行](https://docs.pingcap.com/tidbcloud/migrate-from-op-tidb) - [[グローバル|セッション]変数を表示](/sql-statements/sql-statement-show-variables.md) - [SQL 準備済み実行プランキャッシュ](/sql-prepared-plan-cache.md) - [システム変数](/system-variables.md#time_zone) @@ -4390,7 +4390,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [システム変数](/system-variables.md#txn_scope) -- [TiDBコンフィグレーションファイル](/tidb-configuration-file.md) +- [TiDB設定ファイル](/tidb-configuration-file.md) - [リソース制御を使用してリソースグループの制限とフロー制御を実現する](/tidb-resource-control-ru-groups.md) ### パスワードの検証、ユーザー名の確認 {#validate-password-check-user-name} @@ -4505,7 +4505,7 @@ summary: すべての TiDB システム変数とドキュメント内の参照 - [接続プールと接続パラメータ](/develop/dev-guide-connection-parameters.md) - [TiDB Cloudの SQL 機能が制限されている](https://docs.pingcap.com/tidbcloud/limited-sql-features) - [システム変数](/system-variables.md#wait_timeout) -- [TiDBクラスタ管理に関する FAQ](/faq/manage-cluster-faq.md) +- [TiDBクラスター管理に関する FAQ](/faq/manage-cluster-faq.md) - [TiProxy の概要](/tiproxy/tiproxy-overview.md) - [TiDBのタイムアウト](/develop/dev-guide-timeouts-in-tidb.md) - [TiDB OOM の問題のトラブルシューティング](/troubleshoot-tidb-oom.md) diff --git a/system-variables.md b/system-variables.md index f321a4bd81ab2..48758b82fb9ab 100644 --- a/system-variables.md +++ b/system-variables.md @@ -23,7 +23,7 @@ SET GLOBAL tidb_distsql_scan_concurrency = 10; > **注記：** > -> いくつかの`GLOBAL`変数は TiDB クラスタに保持されます。このドキュメントの一部の変数には`Persists to cluster`設定があり、これは`Yes`または`No`に設定できます。 +> いくつかの`GLOBAL`変数は TiDB クラスターに保持されます。このドキュメントの一部の変数には`Persists to cluster`設定があり、これは`Yes`または`No`に設定できます。 > > - `Persists to cluster: Yes`設定の変数については、グローバル変数が変更されると、すべての TiDB サーバーに通知が送信され、システム変数キャッシュが更新されます。TiDB サーバーを追加したり、既存の TiDB サーバーを再起動したりすると、保存されている構成値が自動的に使用されます。 > - `Persists to cluster: No`設定の変数については、変更は接続先のローカル TiDB インスタンスにのみ適用されます。設定した値を保持するには、 `tidb.toml`設定ファイルで変数を指定する必要があります。 @@ -399,7 +399,7 @@ mysql> SELECT * FROM t1; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値：コンポーネントとデプロイ方法によって異なります。 - `/tmp/tidb` : [`--store`](/command-line-flags-for-tidb-configuration.md#--store)に`"unistore"`を設定した場合、または`--store`を設定しなかった場合。 - - `${pd-ip}:${pd-port}` : TiKV を使用する場合。TiKV は、Kubernetes デプロイメント用のTiUPおよびTiDB Operatorのデフォルトのstorageエンジンです。 + - `${pd-ip}:${pd-port}` : TiKV を使用する場合。TiKV は、Kubernetes デプロイメント用のTiUPおよびTiDB Operatorのデフォルトのストレージエンジンです。 - この変数は、データが保存されている場所を示します。この場所は、ローカルパス`/tmp/tidb`にすることも、データが TiKV に保存されている場合は PDサーバーを指すこともできます。 `${pd-ip}:${pd-port}`の形式の値は、TiDB が起動時に接続する PDサーバーを示します。 @@ -410,7 +410,7 @@ mysql> SELECT * FROM t1; - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値：コンポーネントとデプロイ方法によって異なります。 - `/tmp/tidb` : [`--store`](https://docs.pingcap.com/tidb/stable/command-line-flags-for-tidb-configuration#--store)に`"unistore"`を設定した場合、または`--store`を設定しなかった場合。 - - `${pd-ip}:${pd-port}` : TiKV を使用する場合。TiKV は、Kubernetes デプロイメント用のTiUPおよびTiDB Operatorのデフォルトのstorageエンジンです。 + - `${pd-ip}:${pd-port}` : TiKV を使用する場合。TiKV は、Kubernetes デプロイメント用のTiUPおよびTiDB Operatorのデフォルトのストレージエンジンです。 - この変数は、データが保存されている場所を示します。この場所は、ローカルパス`/tmp/tidb`にすることも、データが TiKV に保存されている場合は PDサーバーを指すこともできます。 `${pd-ip}:${pd-port}`の形式の値は、TiDB が起動時に接続する PDサーバーを示します。 @@ -426,7 +426,7 @@ mysql> SELECT * FROM t1; - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `300` @@ -697,7 +697,7 @@ mysql> SELECT * FROM t1; - 値のオプション: `UNSPECIFIED` 、 `0` 、 `1` 、 `2` - この変数は、MPP実行プランの異なるバージョンを指定するために使用されます。バージョンが指定されると、TiDBは指定されたバージョンのMPP実行プランを選択します。変数の値の意味は次のとおりです。 - `UNSPECIFIED` : 未指定を意味します。TiDB は最新バージョン`2`を自動的に選択します。 - - `0` : すべての TiDB クラスタ バージョンと互換性があります。 `0`より大きい MPP バージョンを持つ機能は、このモードでは有効になりません。 + - `0` : すべての TiDB クラスター バージョンと互換性があります。 `0`より大きい MPP バージョンを持つ機能は、このモードでは有効になりません。 - `1` : v6.6.0 の新機能。 TiFlashで圧縮を伴うデータ交換を有効にするために使用されます。詳細については、 [MPPバージョンとデータ圧縮の交換](/explain-mpp.md#mpp-version-and-exchange-data-compression)を参照してください。 - `2` : v7.3.0 で新しく追加され、 TiFlashで MPP タスクがエラーに遭遇したときに、より正確なエラー メッセージを提供するために使用されます。 @@ -714,7 +714,7 @@ mysql> SELECT * FROM t1; ### 最大接続数 {#max-connections} - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `0` @@ -792,7 +792,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - この変数は、アクティブ PDFollower機能を有効にするかどうかを制御します (現在はリージョン情報の要求にのみ適用されます)。値が`OFF`の場合、TiDB は PD リーダーからのみリージョン情報を取得します。値が`ON`の場合、TiDB はリージョン情報の要求をすべての PD サーバーに均等に分散し、PD フォロワーもリージョン要求を処理できるため、PD リーダーの CPU 負荷が軽減されます。 - アクティブPDFollowerを有効にするシナリオ： - リージョン数が多いクラスターでは、ハートビートの処理やタスクのスケジューリングに伴うオーバーヘッドが増加するため、PDリーダーのCPU負荷が高くなります。 - - TiDBインスタンスが多数存在するTiDBクラスタでは、リージョン情報に対する要求の同時発生率が高いため、PDリーダーに高いCPU負荷がかかります。 + - TiDBインスタンスが多数存在するTiDBクラスターでは、リージョン情報に対する要求の同時発生率が高いため、PDリーダーに高いCPU負荷がかかります。 ### プラグインディレクトリ {#plugin-dir} @@ -801,7 +801,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; > この変数は、 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)ではサポートされていません。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: "" - コマンドラインフラグで指定されたプラグインをロードするディレクトリを示します。 @@ -813,7 +813,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; > この変数は、 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)ではサポートされていません。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: "" - TiDB起動時にロードするプラグインを指定します。これらのプラグインはコマンドラインフラグで指定し、カンマで区切ります。 @@ -927,7 +927,7 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; -- この変数を有効にし、TiDB Data Migration (DM) を使用してデータを移行している場合は、 [DMタスクコンフィグレーションファイル](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced)ファイルの`sql_require_ primary_key`部分に`session`を追加し、それを`OFF`に設定することをお勧めします。そうしないと、DM がタスクを作成できなくなります。 +- この変数を有効にし、TiDB Data Migration (DM) を使用してデータを移行している場合は、 [DMタスク設定ファイル](/dm/task-configuration-file-full.md#task-configuration-file-template-advanced)ファイルの`sql_require_ primary_key`部分に`session`を追加し、それを`OFF`に設定することをお勧めします。そうしないと、DM がタスクを作成できなくなります。 @@ -1061,13 +1061,13 @@ mysql> SHOW GLOBAL VARIABLES LIKE 'max_prepared_stmt_count'; - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - デフォルト値: "" -- この変数は、TiKV にフォールバックする可能性のあるstorageエンジンのリストを指定するために使用されます。リストで指定されたstorageエンジンの障害により SQL ステートメントの実行が失敗した場合、TiDB は TiKV を使用してこの SQL ステートメントの実行を再試行します。この変数は "" または "tiflash" に設定できます。この変数が "tiflash" に設定されている場合、 TiFlash がタイムアウト エラー (エラー コード: ErrTiFlashServerTimeout) を返すと、TiDB は TiKV を使用してこの SQL ステートメントの実行を再試行します。 +- この変数は、TiKV にフォールバックする可能性のあるストレージエンジンのリストを指定するために使用されます。リストで指定されたストレージエンジンの障害により SQL ステートメントの実行が失敗した場合、TiDB は TiKV を使用してこの SQL ステートメントの実行を再試行します。この変数は "" または "tiflash" に設定できます。この変数が "tiflash" に設定されている場合、 TiFlash がタイムアウト エラー (エラー コード: ErrTiFlashServerTimeout) を返すと、TiDB は TiKV を使用してこの SQL ステートメントの実行を再試行します。 ### tidb_allow_function_for_expression_index v5.2.0で追加 {#tidb-allow-function-for-expression-index-span-class-version-mark-new-in-v5-2-0-span} - 適用範囲：なし - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ -- デフォルト値: `json_array, json_array_append, json_array_insert, json_contains, json_contains_path, json_depth, json_extract, json_insert, json_keys, json_length, json_merge_patch, json_merge_preserve, json_object, json_pretty, json_quote, json_remove, json_replace, json_schema_valid, json_search, json_set, json_storage_size, json_type, json_unquote, json_valid, lower, md5, reverse, tidb_shard, upper, vitess_hash` +- デフォルト値: `json_array, json_array_append, json_array_insert, json_contains, json_contains_path, json_depth, json_extract, json_insert, json_keys, json_length, json_merge_patch, json_merge_preserve, json_object, json_pretty, json_quote, json_remove, json_replace, json_schema_valid, json_search, json_set, json_ストレージ_size, json_type, json_unquote, json_valid, lower, md5, reverse, tidb_shard, upper, vitess_hash` - この読み取り専用変数は、 [発現指数](/sql-statements/sql-statement-create-index.md#expression-index)を作成するために使用できる関数を表示するために使用されます。 ### tidb_allow_mpp v5.0で追加 {#tidb-allow-mpp-span-class-version-mark-new-in-v5-0-span} @@ -1105,8 +1105,8 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > > - この変数は、 [`tidb_analyze_version`](#tidb_analyze_version-new-in-v510)が`2`に設定されている場合にのみ機能します。 > - TiDB クラスターを v8.3.0 より前のバージョンから v8.3.0 以降にアップグレードすると、元の動作を維持するために、この変数はデフォルトで`ALL`に設定されます。 -> - v8.3.0 から v8.5.4 までの新規デプロイされた TiDB クラスタの場合、この変数はデフォルトで`PREDICATE`に設定されます。 -> - バージョン8.5.5以降に新しくデプロイされたTiDBクラスタの場合、この変数はデフォルトで`ALL`に設定されます。 +> - v8.3.0 から v8.5.4 までの新規デプロイされた TiDB クラスターの場合、この変数はデフォルトで`PREDICATE`に設定されます。 +> - バージョン8.5.5以降に新しくデプロイされたTiDBクラスターの場合、この変数はデフォルトで`ALL`に設定されます。 - 対象範囲：グローバル - クラスターに保持される: はい @@ -1123,7 +1123,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `4` -- 範囲: `[0, 4294967295]` 。v8.2.0 より前のバージョンでは、最小値は`1`です。これを`0`に設定すると、クラスタサイズに基づいて同時実行数が適応的に調整されます。 +- 範囲: `[0, 4294967295]` 。v8.2.0 より前のバージョンでは、最小値は`1`です。これを`0`に設定すると、クラスターサイズに基づいて同時実行数が適応的に調整されます。 - この変数は`scan`操作を実行する際に、 `ANALYZE`操作の同時実行性を設定するために使用されます。 ### tidb_analyze_partition_concurrency {#tidb-analyze-partition-concurrency} @@ -1216,7 +1216,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: 整数 - デフォルト値: `1` - 範囲: `[1, 2147483647]` -- この変数は、TiDBクラスタで同時に実行できる自動分析操作の数を制御します。v8.4.0より前のバージョンでは、この同時実行数は1に固定されていました。統計情報の収集タスクを高速化するには、クラスタで使用可能なリソースに基づいてこの同時実行数を増やすことができます。 +- この変数は、TiDBクラスターで同時に実行できる自動分析操作の数を制御します。v8.4.0より前のバージョンでは、この同時実行数は1に固定されていました。統計情報の収集タスクを高速化するには、クラスターで使用可能なリソースに基づいてこの同時実行数を増やすことができます。 ### tidb_auto_analyze_end_time {#tidb-auto-analyze-end-time} @@ -1448,7 +1448,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > この TiDB 変数はTiDB Cloudには適用されません。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - タイプ: ブール値 - デフォルト値: `ON` @@ -1485,7 +1485,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > この TiDB 変数はTiDB Cloudには適用されません。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: "" - この変数は読み取り専用です。現在のTiDBサーバーの構成情報を取得するために使用されます。 @@ -1577,7 +1577,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **注記：** > -> - TiDB v6.5.0以降では、新しく作成されたクラスタはデフォルトでコストモデルバージョン2を使用します。TiDBバージョンをv6.5.0より前のバージョンからv6.5.0以降にアップグレードした場合、 `tidb_cost_model_version`値は変更されません。 +> - TiDB v6.5.0以降では、新しく作成されたクラスターはデフォルトでコストモデルバージョン2を使用します。TiDBバージョンをv6.5.0より前のバージョンからv6.5.0以降にアップグレードした場合、 `tidb_cost_model_version`値は変更されません。 > - コストモデルのバージョンを変更すると、クエリプランに変更が生じる可能性があります。 - 範囲: セッション | グローバル @@ -1624,14 +1624,14 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `107374182400` (100 GiB) - 範囲: `[107374182400, 1125899906842624]` ([100 GiB、1 PiB]) - 単位：バイト -- この変数は、 [`tidb_ddl_enable_fast_reorg`](#tidb_ddl_enable_fast_reorg-new-in-v630)が有効になっている場合にのみ有効になります。インデックス作成時のバックフィル処理におけるローカルstorageの使用制限を設定します。 +- この変数は、 [`tidb_ddl_enable_fast_reorg`](#tidb_ddl_enable_fast_reorg-new-in-v630)が有効になっている場合にのみ有効になります。インデックス作成時のバックフィル処理におけるローカルストレージの使用制限を設定します。 ### tidb_ddl_enable_fast_reorg はv6.3.0 で追加されました。 {#tidb-ddl-enable-fast-reorg-span-class-version-mark-new-in-v6-3-0-span} > **注記：** > > - [TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)クラスターを使用している場合、この変数を使用してインデックス作成の速度を向上させるには、TiDB クラスターが AWS 上でホストされていること、および TiDB ノードのサイズが少なくとも 8 vCPU であることを確認してください。 -> - 4 vCPUを搭載した[TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)クラスタの場合、インデックス作成中にリソース制限がクラスタの安定性に影響を与えないように、 [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)手動で無効にすることをお勧めします。この設定を無効にすることで、トランザクションを使用してインデックスを作成できるようになり、クラスタ全体への影響を軽減できます。 +> - 4 vCPUを搭載した[TiDB Cloud Dedicated](https://docs.pingcap.com/tidbcloud/select-cluster-tier#tidb-cloud-dedicated)クラスターの場合、インデックス作成中にリソース制限がクラスターの安定性に影響を与えないように、 [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)手動で無効にすることをお勧めします。この設定を無効にすることで、トランザクションを使用してインデックスを作成できるようになり、クラスター全体への影響を軽減できます。 > - [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)インスタンスの場合、この変数は読み取り専用です。 - 対象範囲：グローバル @@ -1683,10 +1683,10 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `ON` -- この変数は[TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)有効にするかどうかを制御するために使用されます。フレームワークが有効になると、DDLやインポートなどのDXFタスクは、クラスタ内の複数のTiDBノードによって分散的に実行および完了されます。 +- この変数は[TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)有効にするかどうかを制御するために使用されます。フレームワークが有効になると、DDLやインポートなどのDXFタスクは、クラスター内の複数のTiDBノードによって分散的に実行および完了されます。 - TiDB v7.1.0以降、DXFはパーティションテーブルに対する[`ADD INDEX`](/sql-statements/sql-statement-add-index.md)ステートメントの分散実行をサポートしています。 - TiDB v7.2.0以降、DXFはインポートジョブにおける[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)ステートメントの分散実行をサポートしています。 -- TiDB v8.1.0 以降では、この変数はデフォルトで有効になっています。DXF が有効になっているクラスタを v8.1.0 以降にアップグレードする場合は、アップグレード前に DXF を無効にしてください ( `tidb_enable_dist_task`を`OFF`に設定)。これにより、アップグレード中に`ADD INDEX`操作が発生してデータ インデックスの不整合が発生するのを回避できます。アップグレード後、DXF を手動で有効にすることができます。 +- TiDB v8.1.0 以降では、この変数はデフォルトで有効になっています。DXF が有効になっているクラスターを v8.1.0 以降にアップグレードする場合は、アップグレード前に DXF を無効にしてください ( `tidb_enable_dist_task`を`OFF`に設定)。これにより、アップグレード中に`ADD INDEX`操作が発生してデータ インデックスの不整合が発生するのを回避できます。アップグレード後、DXF を手動で有効にすることができます。 - この変数は`tidb_ddl_distribute_reorg`から名前が変更されました。 @@ -1697,17 +1697,17 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー -### tidb_cloud_storage_uri v7.4.0で追加 {#tidb-cloud-storage-uri-span-class-version-mark-new-in-v7-4-0-span} +### tidb_cloud_ストレージ_uri v7.4.0で追加 {#tidb-cloud-ストレージ-uri-span-class-version-mark-new-in-v7-4-0-span} > **注記：** > -> 現在、[グローバルソート](/tidb-global-sort.md)プロセスは TiDB ノードのコンピューティング リソースとメモリリソースを大量に消費します。ユーザー業務アプリケーションの実行中にオンラインでインデックスを追加するなどのシナリオでは、クラスタに新しい TiDB ノードを追加し、これらのノードの[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)変数を構成して、これらのノードに接続してタスクを作成することをお勧めします。このようにして、分散フレームワークはタスクをこれらのノードにスケジュールし、ワークロードを他の TiDB ノードから分離することで、 `ADD INDEX`や`IMPORT INTO`などのバックエンド タスクの実行がユーザー業務アプリケーションに与える影響を軽減します。 +> 現在、[グローバルソート](/tidb-global-sort.md)プロセスは TiDB ノードのコンピューティング リソースとメモリリソースを大量に消費します。ユーザー業務アプリケーションの実行中にオンラインでインデックスを追加するなどのシナリオでは、クラスターに新しい TiDB ノードを追加し、これらのノードの[`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)変数を構成して、これらのノードに接続してタスクを作成することをお勧めします。このようにして、分散フレームワークはタスクをこれらのノードにスケジュールし、ワークロードを他の TiDB ノードから分離することで、 `ADD INDEX`や`IMPORT INTO`などのバックエンド タスクの実行がユーザー業務アプリケーションに与える影響を軽減します。 - 対象範囲：グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `""` -- この変数は、[グローバルソート](/tidb-global-sort.md)を有効にするための Amazon S3 クラウドstorageURI を指定するために使用されます。 [TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)を有効にすると、URI を構成し、storageへのアクセスに必要な権限を持つ適切なクラウドstorageパスを指すようにすることで、グローバル ソート機能を使用できるようになります。詳細については、 [Amazon S3 URI形式](/external-storage-uri.md#amazon-s3-uri-format)を参照してください。 +- この変数は、[グローバルソート](/tidb-global-sort.md)を有効にするための Amazon S3 クラウドストレージURI を指定するために使用されます。 [TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)を有効にすると、URI を構成し、ストレージへのアクセスに必要な権限を持つ適切なクラウドストレージパスを指すようにすることで、グローバル ソート機能を使用できるようになります。詳細については、 [Amazon S3 URI形式](/external-ストレージ-uri.md#amazon-s3-uri-format)を参照してください。 - 以下のステートメントでは、グローバルソート機能を使用できます。 - [`ADD INDEX`](/sql-statements/sql-statement-add-index.md)文。 - インポートジョブ用の[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)ステートメント。 @@ -1781,7 +1781,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: 文字列 - デフォルト値: `0` - 範囲: `[0, 1PiB]` -- この変数は、インデックスのバックフィル中に、**単一の TiDB ノードから単一の TiKV ノードへの**書き込み帯域幅を制限します。これは、インデックス作成の高速化が有効になっている場合 ( [`tidb_ddl_enable_fast_reorg`](#tidb_ddl_enable_fast_reorg-new-in-v630)変数で制御) にのみ有効になります。[グローバルソート](/tidb-global-sort.md)が有効になっている場合、複数の TiDB ノードが TiKV に同時に書き込むことができます。クラスタ内のデータサイズが非常に大きい場合 (数十億行など)、インデックス作成の書き込み帯域幅を制限することで、アプリケーションのワークロードへの影響を効果的に軽減できます。 +- この変数は、インデックスのバックフィル中に、**単一の TiDB ノードから単一の TiKV ノードへの**書き込み帯域幅を制限します。これは、インデックス作成の高速化が有効になっている場合 ( [`tidb_ddl_enable_fast_reorg`](#tidb_ddl_enable_fast_reorg-new-in-v630)変数で制御) にのみ有効になります。[グローバルソート](/tidb-global-sort.md)が有効になっている場合、複数の TiDB ノードが TiKV に同時に書き込むことができます。クラスター内のデータサイズが非常に大きい場合 (数十億行など)、インデックス作成の書き込み帯域幅を制限することで、アプリケーションのワークロードへの影響を効果的に軽減できます。 - デフォルト値`0`は、書き込み帯域幅制限がないことを意味します。 - この変数の値は、単位を指定しても指定しなくても構いません。 - 単位を指定せずに値を指定すると、デフォルトの単位はバイト/秒になります。たとえば、 `67108864`は、1秒あたり`64MiB`を表します。 @@ -1789,7 +1789,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー 例： -4 つの TiDB ノードと複数の TiKV ノードを持つクラスタがあるとします。このクラスタでは、各 TiDB ノードがインデックスのバックフィルを実行でき、リージョンはすべての TiKV ノードに均等に分散されています。 `tidb_ddl_reorg_max_write_speed`を`100MiB`に設定すると、次のようになります。 +4 つの TiDB ノードと複数の TiKV ノードを持つクラスターがあるとします。このクラスターでは、各 TiDB ノードがインデックスのバックフィルを実行でき、リージョンはすべての TiKV ノードに均等に分散されています。 `tidb_ddl_reorg_max_write_speed`を`100MiB`に設定すると、次のようになります。 - グローバルソートが無効になっている場合、一度に TiDB ノードが TiKV に書き込むのは 1 つだけです。この場合、TiKV ノードあたりの最大書き込み帯域幅は`100MiB`です。 - グローバルソートが有効になっている場合、4 つの TiDB ノードすべてが同時に TiKV に書き込むことができます。この場合、TiKV ノードあたりの最大書き込み帯域幅は`4 * 100MiB = 400MiB`です。 @@ -1845,7 +1845,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - この変数は[TiDB高速テーブル作成](/accelerated-table-creation.md)を有効にするかどうかを制御するために使用されます。 - バージョン8.0.0以降、TiDBは`tidb_enable_fast_create_table`を使用して[`CREATE TABLE`](/sql-statements/sql-statement-create-table.md)ステートメントによるテーブル作成の高速化をサポートしています。 - この変数は、v7.6.0 で導入された変数[`tidb_ddl_version`](https://docs-archive.pingcap.com/tidb/v7.6/system-variables#tidb_ddl_version-new-in-v760)から名前が変更されました。v8.0.0 以降、 `tidb_ddl_version`無効になります。 -- TiDB v8.5.0以降、新しく作成されたクラスタでは、高速テーブル作成機能がデフォルトで有効になり、 `tidb_enable_fast_create_table`が`ON`に設定されます。v8.4.0以前のバージョンからアップグレードされたクラスタの場合、 `tidb_enable_fast_create_table`のデフォルト値は変更されません。 +- TiDB v8.5.0以降、新しく作成されたクラスターでは、高速テーブル作成機能がデフォルトで有効になり、 `tidb_enable_fast_create_table`が`ON`に設定されます。v8.4.0以前のバージョンからアップグレードされたクラスターの場合、 `tidb_enable_fast_create_table`のデフォルト値は変更されません。 ### tidb_default_string_match_selectivity v6.2.0で追加 {#tidb-default-string-match-selectivity-span-class-version-mark-new-in-v6-2-0-span} @@ -1865,7 +1865,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **警告：** > -> バージョン8.0.0以降、この変数は非推奨となり、TiDBは楽観的トランザクションの自動再試行をサポートしなくなりました。代替策として、楽観的トランザクションの競合が発生した場合は、エラーを捕捉してアプリケーションでトランザクションを再試行するか、[悲観的な取引モード](/pessimistic-transaction.md)を使用してください。 +> バージョン8.0.0以降、この変数は非推奨となり、TiDBは楽観的トランザクションの自動再試行をサポートしなくなりました。代替策として、楽観的トランザクションの競合が発生した場合は、エラーを捕捉してアプリケーションでトランザクションを再試行するか、[悲観的なトランザクションモード](/pessimistic-transaction.md)を使用してください。 - 範囲: セッション | グローバル - クラスターに保持される: はい @@ -2084,8 +2084,8 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 指定可能な値: `OFF` 、 `ON` 、 `INT_ONLY` - この変数は、プライマリキー[クラスター化インデックス](/clustered-indexes.md)化 として作成するかどうかを制御するために使用されます。ここで「デフォルト」とは、ステートメントがキーワード`CLUSTERED` / `NONCLUSTERED`を明示的に指定しないことを意味します。サポートされている値は`OFF` 、 `ON` 、および`INT_ONLY`です。 - `OFF`は、プライマリキーがデフォルトで非クラスター化インデックスとして作成されることを示します。 - - `ON`は、プライマリキーがデフォルトでクラスタ化インデックスとして作成されることを示します。 - - `INT_ONLY`は、動作が構成項目`alter-primary-key`によって制御されることを示します。 `alter-primary-key`が`true`に設定されている場合、すべての主キーはデフォルトで非クラスタ化インデックスとして作成されます。 `false`に設定されている場合、整数列で構成される主キーのみがクラスタ化インデックスとして作成されます。 + - `ON`は、プライマリキーがデフォルトでクラスター化インデックスとして作成されることを示します。 + - `INT_ONLY`は、動作が構成項目`alter-primary-key`によって制御されることを示します。 `alter-primary-key`が`true`に設定されている場合、すべての主キーはデフォルトで非クラスター化インデックスとして作成されます。 `false`に設定されている場合、整数列で構成される主キーのみがクラスター化インデックスとして作成されます。 ### tidb_enable_ddl はv6.3.0 で追加されました。 {#tidb-enable-ddl-span-class-version-mark-new-in-v6-3-0-span} @@ -2094,11 +2094,11 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > この変数は、 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)では読み取り専用です。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `ON` - 指定可能な値: `OFF` 、 `ON` -- この変数は、対応する TiDB インスタンスが DDL の所有者になれるかどうかを制御します。現在の TiDB クラスタに TiDB インスタンスが 1 つしかない場合、それが DDL の所有者になることを防ぐことはできません。つまり、 `OFF`に設定することはできません。 +- この変数は、対応する TiDB インスタンスが DDL の所有者になれるかどうかを制御します。現在の TiDB クラスターに TiDB インスタンスが 1 つしかない場合、それが DDL の所有者になることを防ぐことはできません。つまり、 `OFF`に設定することはできません。 ### tidb_enable_collect_execution_info {#tidb-enable-collect-execution-info} @@ -2107,7 +2107,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > この TiDB 変数はTiDB Cloudには適用されません。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - タイプ: ブール値 - デフォルト値: `ON` @@ -2359,11 +2359,11 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **注記：** > -> - TiDBクラスタをv4.0.0より前のバージョンからv5.4.0以降にアップグレードした後、実行プランの変更によるパフォーマンス低下を防ぐため、この変数はデフォルトで無効になります。 +> - TiDBクラスターをv4.0.0より前のバージョンからv5.4.0以降にアップグレードした後、実行プランの変更によるパフォーマンス低下を防ぐため、この変数はデフォルトで無効になります。 > -> - TiDBクラスタをv4.0.0以降からv5.4.0以降にアップグレードした後も、この変数はアップグレード前の設定のままです。 +> - TiDBクラスターをv4.0.0以降からv5.4.0以降にアップグレードした後も、この変数はアップグレード前の設定のままです。 > -> - バージョン5.4.0以降、新規にデプロイされたTiDBクラスタでは、この変数はデフォルトで有効になっています。 +> - バージョン5.4.0以降、新規にデプロイされたTiDBクラスターでは、この変数はデフォルトで有効になっています。 - 範囲: セッション | グローバル - クラスターに保持される: はい @@ -2567,7 +2567,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **注記：** > -> TiFlashの代わりにTiKVをstorageエンジンとして使用するOLAPシナリオでは、ページングを有効にすると、場合によってはパフォーマンスが低下する可能性があります。パフォーマンスが低下した場合は、この変数を使用してページングを無効にするか、 [`tidb_min_paging_size`](/system-variables.md#tidb_min_paging_size-new-in-v620)および[`tidb_max_paging_size`](/system-variables.md#tidb_max_paging_size-new-in-v630)変数を使用してページングサイズの行範囲を調整することを検討してください。 +> TiFlashの代わりにTiKVをストレージエンジンとして使用するOLAPシナリオでは、ページングを有効にすると、場合によってはパフォーマンスが低下する可能性があります。パフォーマンスが低下した場合は、この変数を使用してページングを無効にするか、 [`tidb_min_paging_size`](/system-variables.md#tidb_min_paging_size-new-in-v620)および[`tidb_max_paging_size`](/system-variables.md#tidb_max_paging_size-new-in-v630)変数を使用してページングサイズの行範囲を調整することを検討してください。 ### tidb_enable_parallel_apply v5.0で追加 {#tidb-enable-parallel-apply-span-class-version-mark-new-in-v5-0-span} @@ -2723,7 +2723,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー -- データを読み取るオペレーターにスレッドが 1 つだけ残っており、単一の SQL ステートメントのメモリ使用量が常に[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)超える場合、この SQL ステートメントは[データをディスクに書き出す](/system-variables.md#tidb_enable_tmp_storage_on_oom)などの他のメモリ制御動作をトリガーします。 +- データを読み取るオペレーターにスレッドが 1 つだけ残っており、単一の SQL ステートメントのメモリ使用量が常に[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)超える場合、この SQL ステートメントは[データをディスクに書き出す](/system-variables.md#tidb_enable_tmp_ストレージ_on_oom)などの他のメモリ制御動作をトリガーします。 - この変数は、SQL ステートメントがデータの読み取りのみを行う場合にメモリ使用量を効果的に制御します。結合や集計などの計算操作が必要な場合、メモリ使用量は`tidb_mem_quota_query`の制御下にない可能性があり、メモリ不足エラーのリスクが高まります。 @@ -2773,30 +2773,30 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > この TiDB 変数はTiDB Cloudには適用されません。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - タイプ: ブール値 - デフォルト値: `ON` - この変数は、スローログ機能を有効にするかどうかを制御するために使用されます。 -### tidb_enable_tmp_storage_on_oom {#tidb-enable-tmp-storage-on-oom} +### tidb_enable_tmp_ストレージ_on_oom {#tidb-enable-tmp-ストレージ-on-oom} - 対象範囲：グローバル - クラスターに保持される: はい - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `ON` - 値のオプション: `OFF` 、 `ON` -- 単一の SQL ステートメントがシステム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)で指定されたメモリクォータを超えた場合に、一部のオペレーターに対して一時storageを有効にするかどうかを制御します。 -- バージョン 6.3.0 より前では、TiDB 構成項目`oom-use-tmp-storage`を使用してこの機能を有効または無効にできます。クラスターをバージョン 6.3.0 以降にアップグレードすると、TiDB クラスターは`oom-use-tmp-storage`の値を使用してこの変数を自動的に初期化します。その後、 `oom-use-tmp-storage`の値を変更しても効果は**ありません**。 +- 単一の SQL ステートメントがシステム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)で指定されたメモリクォータを超えた場合に、一部のオペレーターに対して一時ストレージを有効にするかどうかを制御します。 +- バージョン 6.3.0 より前では、TiDB 構成項目`oom-use-tmp-ストレージ`を使用してこの機能を有効または無効にできます。クラスターをバージョン 6.3.0 以降にアップグレードすると、TiDB クラスターは`oom-use-tmp-ストレージ`の値を使用してこの変数を自動的に初期化します。その後、 `oom-use-tmp-ストレージ`の値を変更しても効果は**ありません**。 ### tidb_enable_stats_owner はv8.4.0 で追加されました。 {#tidb-enable-stats-owner-span-class-version-mark-new-in-v8-4-0-span} - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - デフォルト値: `ON` - 指定可能な値: `OFF` 、 `ON` -- この変数は、対応する TiDB インスタンスが[統計情報の自動更新](/statistics.md#automatic-update)タスクを実行できるかどうかを制御します。現在の TiDB クラスタに TiDB インスタンスが 1 つしかない場合、このインスタンスで統計の自動更新を無効にすることはできません。つまり、この変数を`OFF`に設定することはできません。 +- この変数は、対応する TiDB インスタンスが[統計情報の自動更新](/statistics.md#automatic-update)タスクを実行できるかどうかを制御します。現在の TiDB クラスターに TiDB インスタンスが 1 つしかない場合、このインスタンスで統計の自動更新を無効にすることはできません。つまり、この変数を`OFF`に設定することはできません。 ### tidb_enable_stmt_summary v3.0.4で追加 {#tidb-enable-stmt-summary-span-class-version-mark-new-in-v3-0-4-span} @@ -2924,11 +2924,11 @@ Query OK, 0 rows affected (0.09 sec) - この変数は、TSOFollowerプロキシ機能を有効にするかどうかを制御します。値が`OFF`の場合、TiDBはPDリーダーからのみTSOを取得します。値が`ON`の場合、TiDBはTSO要求をすべてのPDサーバーに均等に分散し、PDフォロワーもTSO要求を処理できるため、PDリーダーのCPU負荷が軽減されます。 - TSOFollowerプロキシを有効にするシナリオ： - TSOリクエストの負荷が高いため、PDリーダーのCPUがボトルネックとなり、TSO RPCリクエストのレイテンシーが増大する。 - - TiDBクラスタには多数のTiDBインスタンスが存在するため、 [`tidb_tso_client_batch_max_wait_time`](#tidb_tso_client_batch_max_wait_time-new-in-v530)の値を増やしても、TSO RPCリクエストの高レイテンシーの問題は解消されません。 + - TiDBクラスターには多数のTiDBインスタンスが存在するため、 [`tidb_tso_client_batch_max_wait_time`](#tidb_tso_client_batch_max_wait_time-new-in-v530)の値を増やしても、TSO RPCリクエストの高レイテンシーの問題は解消されません。 > **注記：** > -> - PDリーダーのCPU使用率のボトルネック以外の理由（ネットワークの問題など）でTSO RPCのレイテンシーが増加したとします。この場合、TSOFollowerプロキシを有効にすると、TiDBの実行レイテンシーが増加し、クラスタのQPSパフォーマンスに影響を与える可能性があります。 +> - PDリーダーのCPU使用率のボトルネック以外の理由（ネットワークの問題など）でTSO RPCのレイテンシーが増加したとします。この場合、TSOFollowerプロキシを有効にすると、TiDBの実行レイテンシーが増加し、クラスターのQPSパフォーマンスに影響を与える可能性があります。 > - この機能は[`tidb_tso_client_rpc_mode`](#tidb_tso_client_rpc_mode-new-in-v840)と互換性がありません。この機能を有効にすると、[`tidb_tso_client_rpc_mode`](#tidb_tso_client_rpc_mode-new-in-v840)は有効になりません。 ### tidb_enable_unsafe_substitute v6.3.0で追加 {#tidb-enable-unsafe-substitute-span-class-version-mark-new-in-v6-3-0-span} @@ -3085,7 +3085,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > この TiDB 変数はTiDB Cloudには適用されません。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `60` @@ -3106,7 +3106,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `600` @@ -3121,7 +3121,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > この TiDB 変数はTiDB Cloudには適用されません。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - タイプ: 列挙型 - デフォルト値: `NO_PRIORITY` @@ -3155,7 +3155,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `-1` - 範囲: `-1`または`[1, 256]` - 単位：糸 -- この変数は[ごみ収集（GC）](/garbage-collection-overview.md)プロセスの[ロックを解除する](/garbage-collection-overview.md#resolve-locks)ステップ中の同時スレッドの数を制御します。 +- この変数は[ガベージコレクション（GC）](/garbage-collection-overview.md)プロセスの[ロックを解除する](/garbage-collection-overview.md#resolve-locks)ステップ中の同時スレッドの数を制御します。 - v8.3.0 以降、この変数は、GC プロセスの[範囲の削除](/garbage-collection-overview.md#delete-ranges)ステップ中の同時スレッドの数も制御します。 - デフォルトでは、この変数は`-1`であり、TiDB がワークロードに基づいて適切なスレッド数を自動的に決定できるようにします。 - この変数が`[1, 256]`の範囲内の数値に設定されている場合： @@ -3188,7 +3188,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **注記：** > > - 頻繁に更新されるシナリオでは、 `tidb_gc_life_time`の値が大きい場合（日数または月数）、次のような潜在的な問題が発生する可能性があります。 -> - storage使用量の増加 +> - ストレージ使用量の増加 > - 大量の履歴データは、特に`select count(*) from t`のような範囲クエリの場合、パフォーマンスに一定の影響を与える可能性があります。 > - `tidb_gc_life_time`より長く実行されているトランザクションがある場合、GC の実行を継続するために、 `start_ts`以降のデータが保持されます。たとえば、 `tidb_gc_life_time`が 10 分に設定されている場合、実行中のすべてのトランザクションの中で、最も早く開始されたトランザクションが 15 分間実行されている場合、GC は直近 15 分間のデータを保持します。 @@ -3259,7 +3259,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > この TiDB 変数はTiDB Cloudには適用されません。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - タイプ: ブール値 - デフォルト値: `OFF` @@ -3390,7 +3390,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - タイプ: ブール値 - デフォルト値: `ON` -- この変数は、新しい照合順序が有効になっているクラスタで MPP ハッシュパーティション交換演算子を生成するかどうかを制御します。 `true`演算子を生成することを意味し、 `false`生成しないことを意味します。 +- この変数は、新しい照合順序が有効になっているクラスターで MPP ハッシュパーティション交換演算子を生成するかどうかを制御します。 `true`演算子を生成することを意味し、 `false`生成しないことを意味します。 - この変数はTiDBの内部動作に使用されます。この変数を設定することは**推奨されません**。 ### tidb_hash_join_concurrency {#tidb-hash-join-concurrency} @@ -3468,7 +3468,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - タイプ：期間 - デフォルト値： `168h` 、つまり7日間 -- この変数は、履歴統計がstorageに保持される期間を制御します。 +- この変数は、履歴統計がストレージに保持される期間を制御します。 ### tidb_idle_transaction_timeout はv7.6.0 で追加されました。 {#tidb-idle-transaction-timeout-span-class-version-mark-new-in-v7-6-0-span} @@ -3656,7 +3656,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 範囲: セッション - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：はい - デフォルト値: `tikv,tiflash,tidb` -- この変数は、TiDBがデータを読み取る際に使用できるstorageエンジンのリストを設定するために使用されます。 +- この変数は、TiDBがデータを読み取る際に使用できるストレージエンジンのリストを設定するために使用されます。 ### tidb_last_ddl_info v6.0.0で追加 {#tidb-last-ddl-info-span-class-version-mark-new-in-v6-0-0-span} @@ -3755,7 +3755,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > この変数は、 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)インスタンスでは読み取り専用です。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `0` @@ -3820,7 +3820,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **注記：** > -> - TiDBクラスタに複数のTiFlashノードがある場合、集計処理は通常、複数のTiFlashノードに分散して実行されます。この変数は、単一のTiFlashノードにおける集計演算子の最大メモリ使用量を制御します。 +> - TiDBクラスターに複数のTiFlashノードがある場合、集計処理は通常、複数のTiFlashノードに分散して実行されます。この変数は、単一のTiFlashノードにおける集計演算子の最大メモリ使用量を制御します。 > - この変数が`-1`に設定されている場合、 TiFlash は、自身の構成項目[`max_bytes_before_external_group_by`](/tiflash/tiflash-configuration.md#tiflash-configuration-parameters)の値に基づいて、集約演算子の最大メモリ使用量を決定します。 @@ -3829,7 +3829,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **注記：** > -> - TiDBクラスタに複数のTiFlashノードがある場合、集計処理は通常、複数のTiFlashノードに分散して実行されます。この変数は、単一のTiFlashノードにおける集計演算子の最大メモリ使用量を制御します。 +> - TiDBクラスターに複数のTiFlashノードがある場合、集計処理は通常、複数のTiFlashノードに分散して実行されます。この変数は、単一のTiFlashノードにおける集計演算子の最大メモリ使用量を制御します。 > - この変数が`-1`に設定されている場合、 TiFlash は自身の構成項目`max_bytes_before_external_group_by`の値に基づいて集約演算子の最大メモリ使用量を決定します。 @@ -3848,7 +3848,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **注記：** > -> - TiDBクラスタに複数のTiFlashノードがある場合、結合処理は通常、複数のTiFlashノード上で分散して実行されます。この変数は、単一のTiFlashノード上での結合演算子の最大メモリ使用量を制御します。 +> - TiDBクラスターに複数のTiFlashノードがある場合、結合処理は通常、複数のTiFlashノード上で分散して実行されます。この変数は、単一のTiFlashノード上での結合演算子の最大メモリ使用量を制御します。 > - この変数が`-1`に設定されている場合、 TiFlash は、自身の構成項目[`max_bytes_before_external_join`](/tiflash/tiflash-configuration.md#tiflash-configuration-parameters)の値に基づいて、結合演算子の最大メモリ使用量を決定します。 @@ -3857,7 +3857,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **注記：** > -> - TiDBクラスタに複数のTiFlashノードがある場合、結合処理は通常、複数のTiFlashノード上で分散して実行されます。この変数は、単一のTiFlashノード上での結合演算子の最大メモリ使用量を制御します。 +> - TiDBクラスターに複数のTiFlashノードがある場合、結合処理は通常、複数のTiFlashノード上で分散して実行されます。この変数は、単一のTiFlashノード上での結合演算子の最大メモリ使用量を制御します。 > - この変数が`-1`に設定されている場合、 TiFlash は自身の構成項目`max_bytes_before_external_join`の値に基づいて結合演算子の最大メモリ使用量を決定します。 @@ -3876,7 +3876,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **注記：** > -> - TiDBクラスタに複数のTiFlashノードがある場合、TopNとSortは通常、複数のTiFlashノードで分散実行されます。この変数は、単一のTiFlashノードにおけるTopNおよびSort演算子の最大メモリ使用量を制御します。 +> - TiDBクラスターに複数のTiFlashノードがある場合、TopNとSortは通常、複数のTiFlashノードで分散実行されます。この変数は、単一のTiFlashノードにおけるTopNおよびSort演算子の最大メモリ使用量を制御します。 > - この変数が`-1`に設定されている場合、 TiFlash は、独自の構成項目[`max_bytes_before_external_sort`](/tiflash/tiflash-configuration.md#tiflash-configuration-parameters)の値に基づいて、TopN および Sort オペレーターの最大メモリ使用量を決定します。 @@ -3885,7 +3885,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **注記：** > -> - TiDBクラスタに複数のTiFlashノードがある場合、TopNとSortは通常、複数のTiFlashノードで分散実行されます。この変数は、単一のTiFlashノードにおけるTopNおよびSort演算子の最大メモリ使用量を制御します。 +> - TiDBクラスターに複数のTiFlashノードがある場合、TopNとSortは通常、複数のTiFlashノードで分散実行されます。この変数は、単一のTiFlashノードにおけるTopNおよびSort演算子の最大メモリ使用量を制御します。 > - この変数が`-1`に設定されている場合、 TiFlash は、自身の構成項目`max_bytes_before_external_sort`の値に基づいて、TopN および Sort オペレーターの最大メモリ使用量を決定します。 @@ -3919,7 +3919,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - 型: 整数 - デフォルト値: `-1` - 範囲: `-1`または`[1, 128]` -- この変数は、分散実行フレームワーク（DXF）タスクが使用できる TiDB ノードの最大数を定義します。デフォルト値`-1`は、自動モードが有効になっていることを示します。このモードでは、TiDB は`min(3, tikv_nodes / 3)`という値を動的に計算します。ここで、 `tikv_nodes`はクラスタ内の TiKV ノードの数です。 +- この変数は、分散実行フレームワーク（DXF）タスクが使用できる TiDB ノードの最大数を定義します。デフォルト値`-1`は、自動モードが有効になっていることを示します。このモードでは、TiDB は`min(3, tikv_nodes / 3)`という値を動的に計算します。ここで、 `tikv_nodes`はクラスター内の TiKV ノードの数です。 > **注記：** > @@ -3936,7 +3936,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `50000` - 範囲: `[1, 9223372036854775807]` - 単位：行 -- この変数は、コプロセッサのページング要求処理中に処理する最大行数を設定するために使用されます。値を小さく設定しすぎると、TiDBとTiKV間のRPC回数が増加します。一方、値を大きく設定しすぎると、データのロードやフルテーブルスキャンなど、場合によってはメモリ使用量が過剰になります。この変数のデフォルト値は、OLAPシナリオよりもOLTPシナリオで優れたパフォーマンスを発揮します。アプリケーションがstorageエンジンとしてTiKVのみを使用している場合は、OLAPワークロードクエリを実行する際にこの変数の値を増やすことを検討してください。これにより、パフォーマンスが向上する可能性があります。 +- この変数は、コプロセッサのページング要求処理中に処理する最大行数を設定するために使用されます。値を小さく設定しすぎると、TiDBとTiKV間のRPC回数が増加します。一方、値を大きく設定しすぎると、データのロードやフルテーブルスキャンなど、場合によってはメモリ使用量が過剰になります。この変数のデフォルト値は、OLAPシナリオよりもOLTPシナリオで優れたパフォーマンスを発揮します。アプリケーションがストレージエンジンとしてTiKVのみを使用している場合は、OLAPワークロードクエリを実行する際にこの変数の値を増やすことを検討してください。これにより、パフォーマンスが向上する可能性があります。 ### tidb_max_tiflash_threads はv6.1.0 で追加されました。 {#tidb-max-tiflash-threads-span-class-version-mark-new-in-v6-1-0-span} @@ -3990,7 +3990,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー > **注記：** > -> `auto_analyze` 、TiDB 起動構成ファイルで`run-auto-analyze`有効になっている場合にのみ、TiDB クラスタでトリガーされます。 +> `auto_analyze` 、TiDB 起動構成ファイルで`run-auto-analyze`有効になっている場合にのみ、TiDB クラスターでトリガーされます。 ### tidb_mem_quota_apply_cache v5.0で追加 {#tidb-mem-quota-apply-cache-span-class-version-mark-new-in-v5-0-span} @@ -4176,7 +4176,7 @@ MPP は、 TiFlashエンジンによって提供される分散コンピュー - デフォルト値: `128` - 範囲: `[1, 9223372036854775807]` - 単位：行 -- この変数は、コプロセッサのページング要求処理中に最小行数を設定するために使用されます。値を小さく設定しすぎると、TiDBとTiKV間のRPC要求数が増加します。一方、値を大きく設定しすぎると、Limitを使用したIndexLookupクエリの実行時にパフォーマンスが低下する可能性があります。この変数のデフォルト値は、OLAPシナリオよりもOLTPシナリオで優れたパフォーマンスを発揮します。アプリケーションがstorageエンジンとしてTiKVのみを使用している場合は、OLAPワークロードクエリを実行する際にこの変数の値を増やすことを検討してください。これにより、パフォーマンスが向上する可能性があります。 +- この変数は、コプロセッサのページング要求処理中に最小行数を設定するために使用されます。値を小さく設定しすぎると、TiDBとTiKV間のRPC要求数が増加します。一方、値を大きく設定しすぎると、Limitを使用したIndexLookupクエリの実行時にパフォーマンスが低下する可能性があります。この変数のデフォルト値は、OLAPシナリオよりもOLTPシナリオで優れたパフォーマンスを発揮します。アプリケーションがストレージエンジンとしてTiKVのみを使用している場合は、OLAPワークロードクエリを実行する際にこの変数の値を増やすことを検討してください。これにより、パフォーマンスが向上する可能性があります。 ![Paging size impact on TPCH](/media/paging-size-impact-on-tpch.png) @@ -4498,7 +4498,7 @@ mysql> desc select count(distinct a) from test.t; > **注記：** > -> v7.0.0 より前のバージョンの動作は、この変数を`OFF`に設定した場合の動作と一致します。前方互換性を確保するため、以前のバージョンから v7.0.0 以降のクラスタにアップグレードすると、この変数は`OFF`に設定されます。より柔軟なヒント動作を実現するには、パフォーマンスの低下がないことを条件に、この変数を`ON`に切り替えることを強くお勧めします。 +> v7.0.0 より前のバージョンの動作は、この変数を`OFF`に設定した場合の動作と一致します。前方互換性を確保するため、以前のバージョンから v7.0.0 以降のクラスターにアップグレードすると、この変数は`OFF`に設定されます。より柔軟なヒント動作を実現するには、パフォーマンスの低下がないことを条件に、この変数を`ON`に切り替えることを強くお勧めします。 ### tidb_opt_insubq_to_join_and_agg {#tidb-opt-insubq-to-join-and-agg} @@ -5386,7 +5386,7 @@ SHOW WARNINGS; - タイプ: ブール値 - デフォルト値: `ON` - 悲観的トランザクションに対して拡張悲観的ロックウェイクアップモデルを使用するかどうかを決定します。このモデルは、悲観的ロックの単一点競合シナリオにおける悲観的トランザクションのウェイクアップ順序を厳密に制御し、不要なウェイクアップを回避します。既存のウェイクアップメカニズムのランダム性によって生じる不確実性を大幅に低減します。ビジネスシナリオで頻繁に単一点悲観的ロックの競合が発生し（同じデータ行への頻繁な更新など）、その結果、ステートメントの再試行が頻繁に発生したり、テールレイテンシーが高くなったり、場合によっては`pessimistic lock retry limit reached`エラーが発生したりする場合には、この変数を有効にして問題を解決してみてください。 -- この変数は、TiDBクラスタをv7.0.0より前のバージョンからv7.0.0以降のバージョンにアップグレードする場合、デフォルトで無効になっています。 +- この変数は、TiDBクラスターをv7.0.0より前のバージョンからv7.0.0以降のバージョンにアップグレードする場合、デフォルトで無効になっています。 > **注記：** > @@ -5420,7 +5420,7 @@ SHOW WARNINGS; - この変数を有効にすると、プランキャッシュは統計情報をより効果的に活用して実行プランを生成できるようになります。例えば、次のようになります。 - 統計情報が利用可能になる前に実行計画が生成された場合、統計情報が利用可能になった時点で、計画キャッシュは実行計画を再生成します。 - テーブルのデータ分布が変化し、以前は最適だった実行プランが最適ではなくなった場合、統計情報が再収集された後、プランキャッシュは実行プランを再生成します。 -- この変数は、バージョン7.1.0より前のバージョンからバージョン7.1.0以降にアップグレードされたTiDBクラスタでは、デフォルトで無効になっています。 +- この変数は、バージョン7.1.0より前のバージョンからバージョン7.1.0以降にアップグレードされたTiDBクラスターでは、デフォルトで無効になっています。 ### tidb_plan_cache_max_plan_size v7.1.0 で追加されました。 {#code-tidb-plan-cache-max-plan-size-code-span-class-version-mark-new-in-v7-1-0-span} @@ -5438,7 +5438,7 @@ SHOW WARNINGS; > この TiDB 変数はTiDB Cloudには適用されません。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `0` @@ -5517,7 +5517,7 @@ SHOW WARNINGS; > - バージョン7.0.0以降、この変数は、プリペアドステートメントプロトコルを使用するカーソルフェッチ読み取りモードでは無効になります。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - タイプ: ブール値 - デフォルト値: `OFF` @@ -5564,7 +5564,7 @@ SHOW WARNINGS; > この TiDB 変数はTiDB Cloudには適用されません。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、これは現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - タイプ: ブール値 - デフォルト値: `ON` @@ -5652,9 +5652,9 @@ SHOW WARNINGS; - `tidb_restricted_read_only`を`ON`に設定すると、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531) `ON`に更新されます。 - `tidb_restricted_read_only`を`OFF`に設定しても、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)は変更されません。 - `tidb_restricted_read_only`が`ON`の場合、 [`tidb_super_read_only`](#tidb_super_read_only-new-in-v531) `OFF`に設定することはできません。 -- TiDB の DBaaS プロバイダーの場合、TiDB クラスタが別のデータベースのダウンストリーム データベースである場合、TiDB クラスタを読み取り専用にするには、 [Security強化モード](#tidb_enable_enhanced_security)を有効にした`tidb_restricted_read_only`使用する必要がある場合があります。これにより、顧客が[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)使用してクラスタを書き込み可能にすることができなくなります。これを実現するには、 [Security強化モード](#tidb_enable_enhanced_security)を有効にし、 `SYSTEM_VARIABLES_ADMIN`および`RESTRICTED_VARIABLES_ADMIN`権限を持つ管理者ユーザーを使用して`tidb_restricted_read_only`制御し、データベース ユーザーには、 `SUPER`権限を持つルート ユーザーを使用して[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)のみを制御させる必要があります。 -- この変数は、クラスタ全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスタ全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` }、{{B- `SHOW` -E}} など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。 -- この変数を使用して読み取り専用モードを有効にしても、最終的にクラスタ全体が読み取り専用状態になることが保証されるだけです。TiDBクラスタでこの変数の値を変更しても、その変更が他のTiDBサーバーにまだ反映されていない場合、更新されていないTiDBサーバーは読み取り専用モードになり**ません**。 +- TiDB の DBaaS プロバイダーの場合、TiDB クラスターが別のデータベースのダウンストリーム データベースである場合、TiDB クラスターを読み取り専用にするには、 [Security強化モード](#tidb_enable_enhanced_security)を有効にした`tidb_restricted_read_only`使用する必要がある場合があります。これにより、顧客が[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)使用してクラスターを書き込み可能にすることができなくなります。これを実現するには、 [Security強化モード](#tidb_enable_enhanced_security)を有効にし、 `SYSTEM_VARIABLES_ADMIN`および`RESTRICTED_VARIABLES_ADMIN`権限を持つ管理者ユーザーを使用して`tidb_restricted_read_only`制御し、データベース ユーザーには、 `SUPER`権限を持つルート ユーザーを使用して[`tidb_super_read_only`](#tidb_super_read_only-new-in-v531)のみを制御させる必要があります。 +- この変数は、クラスター全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスター全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` }、{{B- `SHOW` -E}} など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。 +- この変数を使用して読み取り専用モードを有効にしても、最終的にクラスター全体が読み取り専用状態になることが保証されるだけです。TiDBクラスターでこの変数の値を変更しても、その変更が他のTiDBサーバーにまだ反映されていない場合、更新されていないTiDBサーバーは読み取り専用モードになり**ません**。 - TiDB は、SQL ステートメントの実行前に読み取り専用フラグを確認します。v6.2.0 以降では、SQL ステートメントのコミット前にもフラグがチェックされます。これにより、サーバーが読み取り専用モードになった後に、長時間実行される[自動コミット](/transaction-overview.md#autocommit)ステートメントがデータを変更するケースを防ぐことができます。 - この変数が有効になっている場合、TiDB はコミットされていないトランザクションを次のように処理します。 - コミットされていない読み取り専用トランザクションについては、通常どおりトランザクションをコミットできます。 @@ -5703,8 +5703,8 @@ SHOW WARNINGS; - 型: 整数 - デフォルト値: `2` - 範囲: `[1, 2]` -- テーブルに新しく保存されたデータの形式バージョンを制御します。 TiDB v4.0 では、 [新しいstorage行フォーマット](https://github.com/pingcap/tidb/blob/release-8.5/docs/design/2018-07-19-row-format.md)バージョン`2`がデフォルトで新しいデータの保存に使用されます。 -- TiDB のバージョンを v4.0.0 より前のバージョンから v4.0.0 以降のバージョンにアップグレードした場合、フォーマット バージョンは変更されず、TiDB は引き続き古いフォーマット`1`を使用してテーブルにデータを書き込みます。つまり、**新しく作成されたクラスタのみがデフォルトで新しいデータ フォーマットを使用します**。 +- テーブルに新しく保存されたデータの形式バージョンを制御します。 TiDB v4.0 では、 [新しいストレージ行フォーマット](https://github.com/pingcap/tidb/blob/release-8.5/docs/design/2018-07-19-row-format.md)バージョン`2`がデフォルトで新しいデータの保存に使用されます。 +- TiDB のバージョンを v4.0.0 より前のバージョンから v4.0.0 以降のバージョンにアップグレードした場合、フォーマット バージョンは変更されず、TiDB は引き続き古いフォーマット`1`を使用してテーブルにデータを書き込みます。つまり、**新しく作成されたクラスターのみがデフォルトで新しいデータ フォーマットを使用します**。 - この変数を変更しても、既に保存されている古いデータには影響しませんが、この変数を変更した後に新たに書き込まれるデータにのみ、対応するバージョン形式が適用されます。 ### tidb_runtime_filter_mode v7.2.0で追加 {#tidb-runtime-filter-mode-span-class-version-mark-new-in-v7-2-0-span} @@ -5742,7 +5742,7 @@ SHOW WARNINGS; - テーブル作成時に`SHARD_ROW_ID_BITS`および`PRE_SPLIT_REGIONS`パラメータが設定されている場合、システムはテーブルの作成が成功すると、自動的に指定された数のリージョンに分割します。この変数は、分割されたリージョンの分散戦略を制御します。TiDB は、選択された分散戦略に基づいてリージョンを処理します。テーブル作成操作は、成功ステータスを返す前に分散処理が完了するまで待機するため、この変数を有効にすると`CREATE TABLE`ステートメントの実行時間が大幅に増加する可能性があることに注意してください。この変数が無効になっている場合と比較すると、実行時間は数倍長くなる可能性があります。可能な値の説明は次のとおりです。 - `""` : デフォルト値。テーブル作成後にテーブルの領域が分散されないことを示します。 - `table` : テーブルを作成する際に`PRE_SPLIT_REGIONS`または`SHARD_ROW_ID_BITS`属性を設定した場合、複数のリージョンを事前に分割するシナリオでは、これらのテーブルのリージョンはテーブルの粒度に応じて分散されます。ただし、テーブルを作成する際に上記の属性を設定しない場合、多数のテーブルを迅速に作成するシナリオでは、これらのテーブルのリージョンが少数の TiKV ノードに集中し、リージョンの分布が不均一になります。 - - `global` : TiDB は、新しく作成されたテーブルのリージョンをクラスタ全体のデータ分布に従って分散します。特に、多数のテーブルを迅速に作成する場合、 `global`オプションを使用すると、リージョンが少数の TiKV ノードに過度に集中するのを防ぎ、クラスタ全体にリージョンがよりバランスよく分散されるようにすることができます。 + - `global` : TiDB は、新しく作成されたテーブルのリージョンをクラスター全体のデータ分布に従って分散します。特に、多数のテーブルを迅速に作成する場合、 `global`オプションを使用すると、リージョンが少数の TiKV ノードに過度に集中するのを防ぎ、クラスター全体にリージョンがよりバランスよく分散されるようにすることができます。 ### tidb_schema_cache_size v8.0.0で追加 {#tidb-schema-cache-size-span-class-version-mark-new-in-v8-0-0-span} @@ -5819,11 +5819,11 @@ SHOW WARNINGS; > この TiDB 変数はTiDB Cloudには適用されません。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 文字列 - デフォルト値: "" -- オプション値: 最大 64 文字の文字列。有効な文字は、数字`0-9` 、文字`a-zA-Z` 、アンダースコア`_` 、ハイフン`-` 。v8.5.6 以降、この変数の値は大文字と小文字を区別しません。TiDB は、storageおよび比較のために入力値を小文字に変換します。 +- オプション値: 最大 64 文字の文字列。有効な文字は、数字`0-9` 、文字`a-zA-Z` 、アンダースコア`_` 、ハイフン`-` 。v8.5.6 以降、この変数の値は大文字と小文字を区別しません。TiDB は、ストレージおよび比較のために入力値を小文字に変換します。 - この変数はインスタンスレベルのシステム変数です。これを使用して[TiDB分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)の下で各 TiDB ノードのサービス スコープを制御できます。 DXF は、この変数の値に基づいて、どの TiDB ノードが分散タスクを実行するようにスケジュールできるかを決定します。特定のルールについては、 [タスクスケジューリング](/tidb-distributed-execution-framework.md#task-scheduling)を参照してください。 ### tidb_session_alias v7.4.0で追加 {#tidb-session-alias-span-class-version-mark-new-in-v7-4-0-span} @@ -5968,7 +5968,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) > この TiDB 変数はTiDB Cloudには適用されません。 - 対象範囲：グローバル -- クラスタに永続化しますか？：いいえ、現在接続している TiDB インスタンスにのみ適用されます。 +- クラスターに永続化しますか？：いいえ、現在接続している TiDB インスタンスにのみ適用されます。 - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `300` @@ -6327,8 +6327,8 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - デフォルト値: `OFF` - `tidb_super_read_only` MySQL 変数`super_read_only`の代替として実装されることを目的としています。ただし、TiDB は分散データベースであるため、 `tidb_super_read_only`実行直後にデータベースを読み取り専用にするのではなく、最終的に読み取り専用にします。 - `SUPER`または`SYSTEM_VARIABLES_ADMIN`の権限を持つユーザーは、この変数を変更できます。 -- この変数は、クラスタ全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスタ全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` }、{{B- `SHOW` }} など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。 -- この変数を使用して読み取り専用モードを有効にしても、最終的にクラスタ全体が読み取り専用状態になることが保証されるだけです。TiDBクラスタでこの変数の値を変更しても、その変更が他のTiDBサーバーにまだ反映されていない場合、更新されていないTiDBサーバーは読み取り専用モードになり**ません**。 +- この変数は、クラスター全体の読み取り専用状態を制御します。変数が`ON`の場合、クラスター全体のすべての TiDB サーバーが読み取り専用モードになります。この場合、TiDB は`SELECT` 、 `USE` }、{{B- `SHOW` }} など、データを変更しないステートメントのみを実行します。 `INSERT`や`UPDATE`などの他のステートメントについては、TiDB は読み取り専用モードでの実行を拒否します。 +- この変数を使用して読み取り専用モードを有効にしても、最終的にクラスター全体が読み取り専用状態になることが保証されるだけです。TiDBクラスターでこの変数の値を変更しても、その変更が他のTiDBサーバーにまだ反映されていない場合、更新されていないTiDBサーバーは読み取り専用モードになり**ません**。 - TiDB は、SQL ステートメントの実行前に読み取り専用フラグを確認します。v6.2.0 以降では、SQL ステートメントのコミット前にもフラグがチェックされます。これにより、サーバーが読み取り専用モードになった後に、長時間実行される[自動コミット](/transaction-overview.md#autocommit)ステートメントがデータを変更するケースを防ぐことができます。 - この変数が有効になっている場合、TiDB はコミットされていないトランザクションを次のように処理します。 - コミットされていない読み取り専用トランザクションについては、通常どおりトランザクションをコミットできます。 @@ -6357,7 +6357,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - ヒント[SET_VAR](/optimizer-hints.md#set_varvar_namevar_value)に適用：いいえ - 型: 整数 - デフォルト値: `1` -- 範囲: `[0, 4294967295]` 。v7.5.0 以前のバージョンの最大値は`256`です。v8.2.0 より前のバージョンでは、最小値は`1`です。 `0`に設定すると、クラスタサイズに基づいて同時実行数が適応的に調整されます。 +- 範囲: `[0, 4294967295]` 。v7.5.0 以前のバージョンの最大値は`256`です。v8.2.0 より前のバージョンでは、最小値は`1`です。 `0`に設定すると、クラスターサイズに基づいて同時実行数が適応的に調整されます。 - この変数は、TiDBが内部SQLステートメント（統計情報の自動更新など）を実行する際に実行されるスキャン操作の同時実行数を設定するために使用されます。 ### tidb_table_cache_lease v6.0.0で追加 {#tidb-table-cache-lease-span-class-version-mark-new-in-v6-0-0-span} @@ -6472,7 +6472,7 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) > **注記：** > -> - TSO RPC のレイテンシーがPD リーダーの CPU 使用率のボトルネック以外の理由 (ネットワークの問題など) で増加するとします。この場合、 `tidb_tso_client_batch_max_wait_time`の値を増やすと、TiDB の実行レイテンシーが増加し、クラスタの QPS パフォーマンスに影響を与える可能性があります。 +> - TSO RPC のレイテンシーがPD リーダーの CPU 使用率のボトルネック以外の理由 (ネットワークの問題など) で増加するとします。この場合、 `tidb_tso_client_batch_max_wait_time`の値を増やすと、TiDB の実行レイテンシーが増加し、クラスターの QPS パフォーマンスに影響を与える可能性があります。 > - この機能は[`tidb_tso_client_rpc_mode`](#tidb_tso_client_rpc_mode-new-in-v840)と互換性がありません。この変数にゼロ以外の値を設定すると、[`tidb_tso_client_rpc_mode`](#tidb_tso_client_rpc_mode-new-in-v840)有効になりません。 ### tidb_tso_client_rpc_mode v8.4.0で追加 {#tidb-tso-client-rpc-mode-span-class-version-mark-new-in-v8-4-0-span} @@ -6719,9 +6719,9 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - タイプ: 列挙型 - デフォルト値: `pessimistic` - 指定可能な値: `pessimistic` 、 `optimistic` -- この変数はトランザクション モードを設定するために使用されます。 TiDB 3.0 は悲観的トランザクションをサポートします。 TiDB 3.0.8 以降、[悲観的取引モード](/pessimistic-transaction.md)はデフォルトで有効になっています。 -- TiDBをv3.0.7以前のバージョンからv3.0.8以降のバージョンにアップグレードしても、デフォルトのトランザクションモードは変更されません。**新しく作成されたクラスタのみが、デフォルトで悲観的トランザクションモードを使用します**。 -- この変数が「楽観的」または「」に設定されている場合、TiDB は[楽観的取引モード](/optimistic-transaction.md)を使用します。 +- この変数はトランザクション モードを設定するために使用されます。 TiDB 3.0 は悲観的トランザクションをサポートします。 TiDB 3.0.8 以降、[悲観的トランザクションモード](/pessimistic-transaction.md)はデフォルトで有効になっています。 +- TiDBをv3.0.7以前のバージョンからv3.0.8以降のバージョンにアップグレードしても、デフォルトのトランザクションモードは変更されません。**新しく作成されたクラスターのみが、デフォルトで悲観的トランザクションモードを使用します**。 +- この変数が「楽観的」または「」に設定されている場合、TiDB は[楽観的トランザクションモード](/optimistic-transaction.md)を使用します。 ### tidb_use_plan_baselines v4.0で追加 {#tidb-use-plan-baselines-span-class-version-mark-new-in-v4-0-span} @@ -6882,14 +6882,14 @@ Query OK, 0 rows affected, 1 warning (0.00 sec) - デフォルト値: `0` - 範囲: `[0, 2147483647]` - 単位：ミリ秒 -- `tikv_client_read_timeout`を使用すると、クエリで TiDB が TiKV RPC 読み取りリクエストを送信するタイムアウトを設定できます。TiDB クラスタが不安定なネットワーク環境または深刻な TiKV I/Oレイテンシーのジッターがある環境にあり、アプリケーションが SQL クエリのレイテンシーに敏感な場合は、 `tikv_client_read_timeout`を設定して、TiKV RPC 読み取りリクエストのタイムアウトを短縮できます。この場合、TiKV ノードで I/Oレイテンシーのジッターが発生すると、TiDB はすぐにタイムアウトして、次の TiKVリージョンピアがある TiKV ノードに RPC リクエストを再送信できます。すべての TiKVリージョンピアのリクエストがタイムアウトした場合、TiDB はデフォルトのタイムアウト (通常 40 秒) で再試行します。 +- `tikv_client_read_timeout`を使用すると、クエリで TiDB が TiKV RPC 読み取りリクエストを送信するタイムアウトを設定できます。TiDB クラスターが不安定なネットワーク環境または深刻な TiKV I/Oレイテンシーのジッターがある環境にあり、アプリケーションが SQL クエリのレイテンシーに敏感な場合は、 `tikv_client_read_timeout`を設定して、TiKV RPC 読み取りリクエストのタイムアウトを短縮できます。この場合、TiKV ノードで I/Oレイテンシーのジッターが発生すると、TiDB はすぐにタイムアウトして、次の TiKVリージョンピアがある TiKV ノードに RPC リクエストを再送信できます。すべての TiKVリージョンピアのリクエストがタイムアウトした場合、TiDB はデフォルトのタイムアウト (通常 40 秒) で再試行します。 - クエリ内でオプティマイザヒント`/*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=N) */`を使用すると、TiDB が TiKV RPC 読み取りリクエストを送信するタイムアウトを設定できます。オプティマイザヒントとこのシステム変数の両方が設定されている場合は、オプティマイザヒントが優先されます。 - デフォルト値`0`は、デフォルトのタイムアウト（通常は 40 秒）が使用されることを示します。 > **注記：** > > - 通常、通常のクエリは数ミリ秒で完了しますが、TiKVノードのネットワークが不安定な場合やI/Oジッターが発生すると、クエリに1秒以上、場合によっては10秒以上かかることがあります。このような場合は、オプティマイザヒント`/*+ SET_VAR(TIKV_CLIENT_READ_TIMEOUT=100) */`を使用して、特定のクエリのTiKV RPC読み取りリクエストのタイムアウトを100ミリ秒に設定できます。こうすることで、TiKVノードの応答が遅い場合でも、TiDBはすぐにタイムアウトして、次のTiKVリージョンピアが存在するTiKVノードにRPCリクエストを再送信できます。2つのTiKVノードが同時にI/Oジッターが発生する確率は低いため、クエリは通常、数ミリ秒から110ミリ秒以内に完了します。 -> - `tikv_client_read_timeout`に小さすぎる値（例えば 1 ミリ秒）を設定しないでください。そうしないと、TiDB クラスタのワークロードが高い場合にリクエストがタイムアウトしやすくなり、その後の再試行によって TiDB クラスタへの負荷がさらに増加する可能性があります。 +> - `tikv_client_read_timeout`に小さすぎる値（例えば 1 ミリ秒）を設定しないでください。そうしないと、TiDB クラスターのワークロードが高い場合にリクエストがタイムアウトしやすくなり、その後の再試行によって TiDB クラスターへの負荷がさらに増加する可能性があります。 > - クエリの種類ごとに異なるタイムアウト値を設定する必要がある場合は、オプティマイザヒントを使用することをお勧めします。 ### タイムゾーン {#time-zone} diff --git a/table-affinity.md b/table-affinity.md index 87ef8b441288b..66094700c4adc 100644 --- a/table-affinity.md +++ b/table-affinity.md @@ -21,7 +21,7 @@ PDアフィニティスケジューリングを有効にし、テーブルの`AF - この機能は[一時テーブル](/temporary-tables.md)および[ビュー](/views.md)では動作しません。 - [パーティションテーブル](/partitioned-table.md)データアフィニティが設定されると、**パーティションの追加、削除、再編成、スワップなど、テーブルのパーティション構成の変更はサポートされなくなります**。パーティション構成を変更するには、まずそのテーブルのアフィニティ設定を削除する必要があります。 - **大容量データを扱う場合、ディスク容量を事前に評価してください**。アフィニティを有効にすると、PDはテーブルまたはパーティションのリージョンを、少数のTiKVノードの同じサブセットに優先的にスケジュールします。データ量の多いテーブルやパーティションの場合、これによりこれらのノードのディスク使用量が大幅に増加する可能性があります。事前にディスク容量を評価し、監視することをお勧めします。 -- データアフィニティは、Leaderとボーターレプリカの分散にのみ影響します。テーブルにLearnerレプリカ（ TiFlashなど）がある場合、それらの分散はアフィニティ設定の影響を受けません。 +- データアフィニティは、Leaderとボーターレプリカの分散にのみ影響します。テーブルにラーナーレプリカ（ TiFlashなど）がある場合、それらの分散はアフィニティ設定の影響を受けません。 ## 前提条件 {#prerequisites} diff --git a/telemetry.md b/telemetry.md index 692e4359826ab..9dbc786624a51 100644 --- a/telemetry.md +++ b/telemetry.md @@ -19,7 +19,7 @@ summary: テレメトリ機能と、その機能を無効化してそのステ > **注記：** > -> **いずれの**場合も、TiDBクラスタに保存されたユーザーデータは共有され**ません**[PingCAPプライバシーポリシー](https://pingcap.com/privacy-policy)も参照してください。 +> **いずれの**場合も、TiDBクラスターに保存されたユーザーデータは共有され**ません**[PingCAPプライバシーポリシー](https://pingcap.com/privacy-policy)も参照してください。 TiUPでテレメトリ収集機能が有効になっている場合、次のような (ただしこれらに限定されない) TiUPの使用状況の詳細が共有されます。 diff --git a/temporary-tables.md b/temporary-tables.md index 2d3e2f16fd3b5..bbb5350d07d6e 100644 --- a/temporary-tables.md +++ b/temporary-tables.md @@ -23,7 +23,7 @@ TiDB 一時テーブルは、次のシナリオで使用できます。 TiDB の一時テーブルは、ローカル一時テーブルとグローバル一時テーブルの 2 種類に分かれています。 - ローカル一時テーブルの場合、テーブル定義とテーブル内のデータは現在のセッションでのみ参照可能です。このタイプは、セッション中の中間データを一時的に保存するのに適しています。 -- グローバル一時テーブルの場合、テーブル定義はTiDBクラスタ全体から参照可能で、テーブル内のデータは現在のトランザクションからのみ参照可能です。このタイプは、トランザクション中の中間データを一時的に保存するのに適しています。 +- グローバル一時テーブルの場合、テーブル定義はTiDBクラスター全体から参照可能で、テーブル内のデータは現在のトランザクションからのみ参照可能です。このタイプは、トランザクション中の中間データを一時的に保存するのに適しています。 ## ローカル一時テーブル {#local-temporary-tables} @@ -135,8 +135,8 @@ TiDB のローカル一時テーブルは、次の点で MySQL の一時テー - TiDB ローカル一時テーブルは`ALTER TABLE`サポートしていません。 - TiDB ローカル一時テーブルは`ENGINE`テーブル オプションを無視し、常に[メモリ制限](#limit-the-memory-usage-of-temporary-tables)を使用して一時テーブル データを TiDBメモリに格納します。 -- storageエンジンとして`MEMORY`宣言されている場合、TiDB ローカル一時テーブルは`MEMORY`storageエンジンによって制限されません。 -- storageエンジンとして`INNODB`または`MYISAM`宣言されている場合、TiDB ローカル一時テーブルは InnoDB 一時テーブルに固有のシステム変数を無視します。 +- ストレージエンジンとして`MEMORY`宣言されている場合、TiDB ローカル一時テーブルは`MEMORY`ストレージエンジンによって制限されません。 +- ストレージエンジンとして`INNODB`または`MYISAM`宣言されている場合、TiDB ローカル一時テーブルは InnoDB 一時テーブルに固有のシステム変数を無視します。 - MySQLでは、同じSQL文内で同じ一時テーブルを複数回参照することはできません。TiDBのローカル一時テーブルにはこの制限はありません。 - MySQLの一時テーブルを表示するシステムテーブル`information_schema.INNODB_TEMP_TABLE_INFO`は、TiDBには存在しません。現在、TiDBにはローカル一時テーブルを表示するシステムテーブルはありません。 - TiDBには内部一時テーブルがありません。内部一時テーブル用のMySQLシステム変数はTiDBには適用されません。 @@ -156,7 +156,7 @@ TiDB のローカル一時テーブルは、次の点で MySQL の一時テー > **注記：** > > - TiDB で一時テーブルを使用する前に、 [他の TiDB 機能との互換性の制限](#compatibility-restrictions-with-other-tidb-features)に注意してください。 -> - TiDB クラスタ v5.3.0 以降でグローバル一時テーブルを作成した場合、クラスタを v5.3.0 より前のバージョンにダウングレードすると、これらのテーブルは通常のテーブルとして扱われ、データエラーが発生します。 +> - TiDB クラスター v5.3.0 以降でグローバル一時テーブルを作成した場合、クラスターを v5.3.0 より前のバージョンにダウングレードすると、これらのテーブルは通常のテーブルとして扱われ、データエラーが発生します。 セッション A にグローバル一時テーブル`users`を作成します。 @@ -224,7 +224,7 @@ SELECT * FROM users; ## 一時テーブルのメモリ使用量を制限する {#limit-the-memory-usage-of-temporary-tables} -テーブル定義時にどのstorageエンジンを`ENGINE`として宣言したとしても、ローカル一時テーブルとグローバル一時テーブルのデータはTiDBインスタンスのメモリ内にのみ保存されます。これらのデータは永続化されません。 +テーブル定義時にどのストレージエンジンを`ENGINE`として宣言したとしても、ローカル一時テーブルとグローバル一時テーブルのデータはTiDBインスタンスのメモリ内にのみ保存されます。これらのデータは永続化されません。 メモリオーバーフローを回避するために、システム変数[`tidb_tmp_table_max_size`](/system-variables.md#tidb_tmp_table_max_size-new-in-v530)使用して各一時テーブルのサイズを制限できます。一時テーブルのサイズがしきい値`tidb_tmp_table_max_size`を超えると、TiDB はエラーを報告します。デフォルト値は`tidb_tmp_table_max_size`ですが、現在は`64MB`です。 diff --git a/three-data-centers-in-two-cities-deployment.md b/three-data-centers-in-two-cities-deployment.md index 8d7387a2d83d5..14a259c876ecc 100644 --- a/three-data-centers-in-two-cities-deployment.md +++ b/three-data-centers-in-two-cities-deployment.md @@ -7,7 +7,7 @@ summary: 2 つのリージョンにある 3 つのアベイラビリティーゾ このドキュメントでは、2 つのリージョン展開における 3 つの可用性ゾーン (AZ) のアーキテクチャと構成について説明します。 -このドキュメントにおける「リージョン」という用語は地理的な領域を指し、「リージョン」はTiKVにおけるデータstorageの基本単位を指します。「AZ」はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 +このドキュメントにおける「リージョン」という用語は地理的な領域を指し、「リージョン」はTiKVにおけるデータストレージの基本単位を指します。「AZ」はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 ## 概要 {#overview} @@ -41,7 +41,7 @@ summary: 2 つのリージョンにある 3 つのアベイラビリティーゾ - データの一貫性はRaftアルゴリズムによって実現されるため、同一リージョン内の2つのAZが同時に障害に見舞われた場合、別のリージョン（サンフランシスコ）の災害復旧AZに1つのレプリカのみが残ります。これは、ほとんどのレプリカが残るというRaftアルゴリズムの要件を満たしていません。その結果、クラスターが一時的に利用できなくなる可能性があります。保守担当者は、残った1つのレプリカからクラスターを復旧する必要があり、複製されていない少量のホットデータが失われることになります。ただし、このようなケースはまれです。 - ISP 専用ネットワークが使用されるため、このアーキテクチャのネットワーク インフラストラクチャには高いコストがかかります。 - - 2 つのリージョンの 3 つの AZ に 5 つのレプリカが構成され、データの冗長性が高まり、storageコストが高くなります。 + - 2 つのリージョンの 3 つの AZ に 5 つのレプリカが構成され、データの冗長性が高まり、ストレージコストが高くなります。 ### 展開の詳細 {#deployment-details} @@ -55,7 +55,7 @@ AZ1のrac1では、1台のサーバーにTiDBとPDサービスがデプロイさ TiDBサーバー、制御マシン、監視サーバーはrac3上に配置されています。TiDBサーバーは定期メンテナンスとバックアップ用に導入されています。Prometheus、Grafana、およびリストアツールは制御マシンと監視マシンに導入されています。 -## コンフィグレーション {#configuration} +## 設定 {#configuration} ### 例 {#example} diff --git a/ticdc-deployment-topology.md b/ticdc-deployment-topology.md index a5a702eb61dda..42b0939e62e62 100644 --- a/ticdc-deployment-topology.md +++ b/ticdc-deployment-topology.md @@ -9,13 +9,13 @@ summary: 最小限の TiDB トポロジに基づく TiCDC のデプロイメン > > TiCDCはv4.0.6以降、一般提供（GA）された機能です。本番環境でご利用いただけます。 -このドキュメントでは、最小限のクラスタ トポロジに基づく[TiCDC](/ticdc/ticdc-overview.md)のデプロイメント トポロジについて説明します。 +このドキュメントでは、最小限のクラスター トポロジに基づく[TiCDC](/ticdc/ticdc-overview.md)のデプロイメント トポロジについて説明します。 -TiCDCは、TiDB 4.0で導入されたTiDBの増分データを複製するためのツールです。TiDB、MySQL、Kafka、MQ、storageサービスなど、複数のダウンストリームプラットフォームをサポートします。TiCDCは低レイテンシーとネイティブな高可用性を備えています。 +TiCDCは、TiDB 4.0で導入されたTiDBの増分データを複製するためのツールです。TiDB、MySQL、Kafka、MQ、ストレージサービスなど、複数のダウンストリームプラットフォームをサポートします。TiCDCは低レイテンシーとネイティブな高可用性を備えています。 ## トポロジ情報 {#topology-information} -| 実例 | カウント | 物理マシン構成 | IP | コンフィグレーション | +| 実例 | カウント | 物理マシン構成 | IP | 設定 | | :------------- | :--- | :----------------------------- | :-------------------------------------- | :------------------------- | | TiDB | 3 | 16 VCore 32GB * 1 | 10.0.1.1
    10.0.1.2
    10.0.1.3 | デフォルトポート
    グローバルディレクトリ構成 | | PD | 3 | 4 VCore 8GB * 1 | 10.0.1.4
    10.0.1.5
    10.0.1.6 | デフォルトポート
    グローバルディレクトリ構成 | @@ -32,7 +32,7 @@ TiCDCは、TiDB 4.0で導入されたTiDBの増分データを複製するため - [TiCDCトポロジのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-cdc.yaml) - [TiCDCトポロジの複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-cdc.yaml) -上記の TiDB クラスター トポロジ ファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)参照してください。 +上記の TiDB クラスター トポロジ ファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジ設定ファイル](/tiup/tiup-cluster-topology-reference.md)参照してください。 > **注記：** > diff --git a/ticdc-performance-tuning-methods.md b/ticdc-performance-tuning-methods.md index dbcaab6959181..f5a5d127f4c83 100644 --- a/ticdc-performance-tuning-methods.md +++ b/ticdc-performance-tuning-methods.md @@ -31,7 +31,7 @@ summary: パフォーマンス概要ダッシュボードに TiCDC メトリッ - ネットワークの問題: TiCDC でネットワークの中断、遅延、または帯域幅不足が発生すると、データ転送速度に影響し、TiCDC 変更フィードのチェックポイントが長くなる可能性があります。 - アップストリームのQPSが高い場合：TiCDCで処理するデータが過度に大きい場合、データ処理のタイムアウトが発生し、TiCDCチェンジフィードのチェックポイントが増加する可能性があります。通常、単一のTiCDCノードは最大約60KのQPSを処理できます。 - データベースの問題: - - アップストリームTiKVクラスタの`min resolved ts`と最新のPD TSOのギャップが大きくなっています。この問題は通常、アップストリームの書き込みワークロードが過度に重い場合に、TiKVが解決済みのTSを時間内に進めることができないために発生します。 + - アップストリームTiKVクラスターの`min resolved ts`と最新のPD TSOのギャップが大きくなっています。この問題は通常、アップストリームの書き込みワークロードが過度に重い場合に、TiKVが解決済みのTSを時間内に進めることができないために発生します。 - ダウンストリーム データベースのレイテンシーが大きいため、TiCDC がダウンストリームにデータをタイムリーに複製できなくなります。 - Changefeed 解決 ts ラグ: TiCDC ノードの内部レプリケーション状態と上流との間の進捗ラグ（秒単位）。このメトリックが高い場合、TiCDC Puller または Sorter モジュールのデータ処理能力が不足しているか、ネットワークレイテンシーやディスクの読み取り/書き込み速度の低下などの問題が発生している可能性があります。このような場合、TiCDC の効率的かつ安定した運用を確保するには、TiCDC ノードの数を増やす、ネットワーク構成を最適化するなどの適切な対策を講じる必要があります。 diff --git a/ticdc/deploy-ticdc.md b/ticdc/deploy-ticdc.md index e218708e7abc4..2cdfef04b1ee5 100644 --- a/ticdc/deploy-ticdc.md +++ b/ticdc/deploy-ticdc.md @@ -5,21 +5,21 @@ summary: TiCDCの導入と実行に関するハードウェアおよびソフト # TiCDCのデプロイと管理 {#deploy-and-maintain-ticdc} -このドキュメントでは、ハードウェアとソフトウェアに関する推奨事項を含め、TiCDCクラスタのデプロイと保守方法について説明します。TiCDCは、新しいTiDBクラスタと同時にデプロイすることも、既存のTiDBクラスタにTiCDCコンポーネントを追加することもできます。 +このドキュメントでは、ハードウェアとソフトウェアに関する推奨事項を含め、TiCDCクラスターのデプロイと保守方法について説明します。TiCDCは、新しいTiDBクラスターと同時にデプロイすることも、既存のTiDBクラスターにTiCDCコンポーネントを追加することもできます。 ## ソフトウェアとハ​​ードウェアの推奨事項 {#software-and-hardware-recommendations} 本番環境におけるTiCDCの推奨ハードウェア構成は以下のとおりです。 -| CPU | メモリ | ディスク | ネットワーク | TiCDCクラスタインスタンスの数（本番環境における最小要件） | +| CPU | メモリ | ディスク | ネットワーク | TiCDCクラスターインスタンスの数（本番環境における最小要件） | | :----- | :----- | :---------- | :--------------------- | :------------------------------ | | 16コア以上 | 64GB以上 | 500GB以上のSSD | 10ギガビットネットワークカード（2枚推奨） | 2 | 詳細については、[ソフトウェアおよびハードウェアに関する推奨事項](/hardware-and-software-requirements.md)を参照してください。 -## TiUPを使用してTiCDCを含む新しいTiDBクラスタをデプロイ {#deploy-a-new-tidb-cluster-that-includes-ticdc-using-tiup} +## TiUPを使用してTiCDCを含む新しいTiDBクラスターをデプロイ {#deploy-a-new-tidb-cluster-that-includes-ticdc-using-tiup} -TiUPを使用して新しい TiDB クラスタをデプロイする場合、同時に TiCDC もデプロイできます。TiUPが TiUPクラスタの起動に使用する構成ファイルに`cdc_servers`セクションを追加するだけで済みます。以下に例を示します。 +TiUPを使用して新しい TiDB クラスターをデプロイする場合、同時に TiCDC もデプロイできます。TiUPが TiUPクラスターの起動に使用する構成ファイルに`cdc_servers`セクションを追加するだけで済みます。以下に例を示します。 ```shell cdc_servers: @@ -35,15 +35,15 @@ cdc_servers: - 詳しい操作については、 [初期化設定ファイルを編集します](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)ご覧ください。 - 設定可能なフィールドの詳細については、 [TiUPを使用して`cdc_servers`を設定する](/tiup/tiup-cluster-topology-reference.md#cdc_servers)を参照してください。 -- TiDB クラスターを展開する詳細な手順については、 [TiUPを使用してTiDBクラスタをデプロイ](/production-deployment-using-tiup.md)参照してください。 +- TiDB クラスターを展開する詳細な手順については、 [TiUPを使用してTiDBクラスターをデプロイ](/production-deployment-using-tiup.md)参照してください。 > **注記：** > > TiCDC をインストールする前に、 TiUPコントロール マシンと TiCDC ホストの間に[SSH相互信頼とパスワードなしのsudoを手動で設定](/check-before-deployment.md#manually-configure-the-ssh-mutual-trust-and-sudo-without-password)いることを確認してください。 -## TiUPを使用して、既存のTiDBクラスタにTiCDCを追加またはスケールアウトします。 {#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup} +## TiUPを使用して、既存のTiDBクラスターにTiCDCを追加またはスケールアウトします。 {#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup} -TiCDCクラスタのスケールアウト方法は、新規デプロイ方法と同様です。スケールアウトにはTiUPを使用することをお勧めします。 +TiCDCクラスターのスケールアウト方法は、新規デプロイ方法と同様です。スケールアウトにはTiUPを使用することをお勧めします。 1. TiCDCノード情報を追加する`scale-out.yml`ファイルを作成します。以下に例を示します。 @@ -68,7 +68,7 @@ TiCDCクラスタのスケールアウト方法は、新規デプロイ方法と その他の使用例については、 [TiCDCクラスターをスケールアウトする](/scale-tidb-using-tiup.md#scale-out-a-ticdc-cluster)参照してください。 -## TiUPを使用して既存のTiDBクラスタからTiCDCを削除またはスケーリングする {#delete-or-scale-in-ticdc-from-an-existing-tidb-cluster-using-tiup} +## TiUPを使用して既存のTiDBクラスターからTiCDCを削除またはスケーリングする {#delete-or-scale-in-ticdc-from-an-existing-tidb-cluster-using-tiup} TiCDCノードの拡張にはTiUPを使用することをお勧めします。拡張コマンドは以下のとおりです。 @@ -80,7 +80,7 @@ tiup cluster scale-in --node 10.0.1.4:8300 ## TiUPを使用してTiCDCをアップグレードする {#upgrade-ticdc-using-tiup} -TiUPを使用すると TiDB クラスタをアップグレードできます。この際、TiCDC も同時にアップグレードされます。アップグレード コマンドを実行すると、 TiUP は自動的に TiCDCコンポーネントをアップグレードします。以下に例を示します。 +TiUPを使用すると TiDB クラスターをアップグレードできます。この際、TiCDC も同時にアップグレードされます。アップグレード コマンドを実行すると、 TiUP は自動的に TiCDCコンポーネントをアップグレードします。以下に例を示します。 ```shell tiup update --self && \ @@ -90,13 +90,13 @@ tiup cluster upgrade --transfer-timeout 600 > **注記：** > -> 上記のコマンドでは、 ``と``実際のクラスタ名とクラスタバージョンに置き換える必要があります。たとえば、バージョンは v8.5.4 です。 +> 上記のコマンドでは、 ``と``実際のクラスター名とクラスターバージョンに置き換える必要があります。たとえば、バージョンは v8.5.4 です。 ### アップグレードに関する注意事項 {#upgrade-cautions} -TiCDCクラスタをアップグレードする際には、以下の点に注意してください。 +TiCDCクラスターをアップグレードする際には、以下の点に注意してください。 -- TiCDC v4.0.2 は`changefeed`を再構成しました。詳細については、 [コンフィグレーションファイルの互換性に関する注意事項](/ticdc/ticdc-compatibility.md#cli-and-configuration-file-compatibility)を参照してください。 +- TiCDC v4.0.2 は`changefeed`を再構成しました。詳細については、 [設定ファイルの互換性に関する注意事項](/ticdc/ticdc-compatibility.md#cli-and-configuration-file-compatibility)を参照してください。 - アップグレード中に問題が発生した場合は、解決策について[アップグレードに関するよくある質問](/upgrade-tidb-using-tiup.md#faq)を参照してください。 - v6.3.0 以降、TiCDC はローリング アップグレードをサポートしています。マイナー バージョン間のローリング アップグレードを直接実行できます (たとえば、v8.5.0 -> v8.5.3 はマイナー バージョン アップグレードであり、v8.1.x -> v8.5.x はメジャー バージョン アップグレードです)。 TiCDC クラシックアーキテクチャの場合、メジャー バージョン間のアップグレード中に変更フィードを実行しないでください。クラシックアーキテクチャをアップグレードする前に、変更フィードを一時停止してください。新しい TiCDCアーキテクチャは、ローリング アップグレード プロセス中の変更フィードの実行をサポートします。詳細については、 [以前のTiCDCバージョンからのローリングアップグレードに関する互換性に関する注意事項](/ticdc/ticdc-compatibility.md#compatibility-notes-for-upgrading-from-earlier-versions)参照してください。次の条件が満たされる場合、ローリング アップグレードは自動的に有効になります。 @@ -104,7 +104,7 @@ TiCDCクラスタをアップグレードする際には、以下の点に注意 - TiUPはバージョン1.11.3以降です。 - クラスター内では、少なくとも2つのTiCDCインスタンスが稼働している。 -## TiUPを使用してTiCDCクラスタ構成を変更します。 {#modify-ticdc-cluster-configurations-using-tiup} +## TiUPを使用してTiCDCクラスター構成を変更します。 {#modify-ticdc-cluster-configurations-using-tiup} このセクションでは[`tiup cluster edit-config`](/tiup/tiup-component-cluster-edit-config.md)コマンドを使用して TiCDC の設定を変更する方法について説明します。次の例では、 `gc-ttl`のデフォルト値を`86400`から`172800` (48 時間) に変更する必要があると想定しています。 @@ -145,7 +145,7 @@ TiUPを使用すると、TiCDCノードを簡単に停止および起動でき ## コマンドラインツールを使用してTiCDCのステータスをビュー {#view-ticdc-status-using-the-command-line-tool} -TiCDCクラスタの状態を確認するには、次のコマンドを実行します。 `v`を、 `v8.5.4`などのTiCDCクラスタのバージョンに置き換える必要があることに注意してください。 +TiCDCクラスターの状態を確認するには、次のコマンドを実行します。 `v`を、 `v8.5.4`などのTiCDCクラスターのバージョンに置き換える必要があることに注意してください。 ```shell tiup cdc:v cli capture list --server=http://10.0.10.25:8300 diff --git a/ticdc/integrate-confluent-using-ticdc.md b/ticdc/integrate-confluent-using-ticdc.md index 5c0f5ed0d8018..be758536a5640 100644 --- a/ticdc/integrate-confluent-using-ticdc.md +++ b/ticdc/integrate-confluent-using-ticdc.md @@ -34,7 +34,7 @@ TiDB v6.1.0以降、TiCDCはAvro形式でConfluentへの増分データのレプ 2. Confluent Cloud を登録し、Confluent クラスターを作成します。 - ベーシッククラスタを作成し、インターネット経由でアクセスできるようにします。詳細は[Confluent Cloud のクイックスタート](https://docs.confluent.io/cloud/current/get-started/index.html)参照してください。 + ベーシッククラスターを作成し、インターネット経由でアクセスできるようにします。詳細は[Confluent Cloud のクイックスタート](https://docs.confluent.io/cloud/current/get-started/index.html)参照してください。 ### ステップ2. アクセスキーペアを作成する {#step-2-create-an-access-key-pair} @@ -73,7 +73,7 @@ TiDB v6.1.0以降、TiCDCはAvro形式でConfluentへの増分データのレプ API secret: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx - この手順はConfluent CLIを使用して実行することもできます。詳細については[Confluent CLI を Confluent Cloudクラスタに接続する](https://docs.confluent.io/confluent-cli/current/connect.html)参照してください。 + この手順はConfluent CLIを使用して実行することもできます。詳細については[Confluent CLI を Confluent Cloudクラスターに接続する](https://docs.confluent.io/confluent-cli/current/connect.html)参照してください。 ### ステップ3. Kafkaの変更フィードを作成する {#step-3-create-a-kafka-changefeed} @@ -157,7 +157,7 @@ Snowflakeはクラウドネイティブなデータウェアハウスです。Co ### 前提条件 {#prerequisites} - Snowflakeクラスターの登録と作成が完了しました[Snowflakeを使い始める](https://docs.snowflake.com/en/user-guide-getting-started.html)参照してください。 -- Snowflakeクラスタに接続する前に、クラスタ用の秘密鍵を生成しておきます。1 [キーペア認証とキーペアローテーション](https://docs.snowflake.com/en/user-guide/key-pair-auth.html)参照してください。 +- Snowflakeクラスターに接続する前に、クラスター用の秘密鍵を生成しておきます。1 [キーペア認証とキーペアローテーション](https://docs.snowflake.com/en/user-guide/key-pair-auth.html)参照してください。 ### 統合手順 {#integration-procedure} @@ -177,7 +177,7 @@ Snowflakeはクラウドネイティブなデータウェアハウスです。Co ![Configuration](/media/integrate/configuration.png) -5. **コンフィグレーション**ページで、**入力Kafkaレコード値の形式**と**入力Kafkaレコードキーの形式**の両方に`AVRO`選択します。次に、 **「続行」**をクリックします。コネクタが作成され、ステータスが**「実行中」**になるまでお待ちください。これには数分かかる場合があります。 +5. **設定**ページで、**入力Kafkaレコード値の形式**と**入力Kafkaレコードキーの形式**の両方に`AVRO`選択します。次に、 **「続行」**をクリックします。コネクタが作成され、ステータスが**「実行中」**になるまでお待ちください。これには数分かかる場合があります。 ![Data preview](/media/integrate/data-preview.png) @@ -350,7 +350,7 @@ Microsoft SQL Server は、Microsoft が開発したリレーショナルデー 4. 接続情報と認証情報を入力してください。次のページに進んでください。 -5. **「コンフィグレーション」**ページで次のフィールドを構成し、 **「続行」**をクリックします。 +5. **「設定」**ページで次のフィールドを構成し、 **「続行」**をクリックします。 | 分野 | 価値 | | :-------------- | :----- | diff --git a/ticdc/monitor-ticdc.md b/ticdc/monitor-ticdc.md index d1efd740e640e..af14b2438aceb 100644 --- a/ticdc/monitor-ticdc.md +++ b/ticdc/monitor-ticdc.md @@ -32,7 +32,7 @@ cdc cli changefeed create --server=http://10.0.10.25:8300 --sink-uri="mysql://ro TiCDC の新しいアーキテクチャの監視ダッシュボードには、主に次のセクションが含まれます。 - [**まとめ**](#summary) : TiCDCクラスターの概要情報 -- [**サーバ**](#server) : TiDBクラスタ内のTiKVノードとTiCDCノードの概要情報 +- [**サーバ**](#server) : TiDBクラスター内のTiKVノードとTiCDCノードの概要情報 - [**丸太引き**](#log-puller) : TiCDC Log Pullerモジュールの詳細情報 - [**イベントストア**](#event-store) : TiCDCイベントストアモジュールの詳細情報 - [**シンク**](#sink) : TiCDCシンクモジュールの詳細情報 @@ -69,7 +69,7 @@ TiCDC の新しいアーキテクチャの監視ダッシュボードには、 - CPU使用率: TiCDCノードのCPU使用率 - メモリ使用量: TiCDCノードのメモリ使用量 - 所有権履歴: TiCDC クラスター内の所有者ノードの履歴記録 -- PDLeader履歴:上流TiDBクラスタ内のPDLeaderノードの履歴記録 +- PDLeader履歴:上流TiDBクラスター内のPDLeaderノードの履歴記録 ### 丸太引き {#log-puller} @@ -131,9 +131,9 @@ TiUPを使用して TiDB クラスターをデプロイすると、TiDB と同 各パネルの説明は次のとおりです。 -- [**サーバ**](#server) : TiDBクラスタ内のTiKVノードとTiCDCノードの概要情報 +- [**サーバ**](#server) : TiDBクラスター内のTiKVノードとTiCDCノードの概要情報 - [**チェンジフィード**](#changefeed) : TiCDCレプリケーションタスクの詳細情報 -- [**イベント**](#events) : TiCDCクラスタ内のデータフローに関する詳細情報 +- [**イベント**](#events) : TiCDCクラスター内のデータフローに関する詳細情報 - [**TiKV**](#tikv) : TiCDCに関連するTiKV情報 ### サーバ {#server} @@ -159,7 +159,7 @@ TiUPを使用して TiDB クラスターをデプロイすると、TiDB と同 ![TiCDC Dashboard - Changefeed metrics 1](/media/ticdc/ticdc-dashboard-changefeed-1.png) - チェンジフィードテーブル数: 各 TiCDC ノードがレプリケーションタスクで複製する必要があるテーブルの数 -- プロセッサ解決ts: TiCDCクラスタで解決されたタイムスタンプ +- プロセッサ解決ts: TiCDCクラスターで解決されたタイムスタンプ - テーブル解決ts: レプリケーションタスク内の各テーブルのレプリケーションの進行状況 - チェンジフィードチェックポイント：下流へのデータ複製の進行状況。通常、緑色のバーは黄色の線とつながっています。 - PD etcdリクエスト数/秒: TiCDCノードがPDに送信するリクエスト数（1秒あたり） @@ -182,7 +182,7 @@ TiUPを使用して TiDB クラスターをデプロイすると、TiDB と同 ![TiCDC Dashboard - Changefeed metrics 4](/media/ticdc/ticdc-dashboard-changefeed-4.png) -- Changefeed キャッチアップ ETA: レプリケーションタスクが上流のクラスタデータに追いつくのに必要な推定時間です。上流の書き込み速度が TiCDC のレプリケーション速度よりも速い場合、この指標は非常に大きくなる可能性があります。TiCDC のレプリケーション速度は多くの要因に左右されるため、この指標は参考値であり、実際のレプリケーション時間とは異なる可能性があります。 +- Changefeed キャッチアップ ETA: レプリケーションタスクが上流のクラスターデータに追いつくのに必要な推定時間です。上流の書き込み速度が TiCDC のレプリケーション速度よりも速い場合、この指標は非常に大きくなる可能性があります。TiCDC のレプリケーション速度は多くの要因に左右されるため、この指標は参考値であり、実際のレプリケーション時間とは異なる可能性があります。 ### イベント {#events} diff --git a/ticdc/ticdc-architecture.md b/ticdc/ticdc-architecture.md index f2254a2065bd1..44700e7c7c183 100644 --- a/ticdc/ticdc-architecture.md +++ b/ticdc/ticdc-architecture.md @@ -10,22 +10,22 @@ summary: TiCDCの新しいアーキテクチャの機能、アーキテクチャ この新しいアーキテクチャは[従来のTiCDCアーキテクチャ](/ticdc/ticdc-classic-architecture.md)アーキテクチャの構成、使用法、API との互換性を維持しながら、TiCDC コア コンポーネントを再設計し、そのデータ処理ワークフローを最適化します。これには次のような利点があります。 - **シングルノードのパフォーマンス向上**：シングルノードで最大50万個のテーブルを複製でき、テーブル数の多いシナリオではシングルノードで最大190 MiB/sの複製スループットを実現します。 -- **拡張性の向上**：クラスタレプリケーション機能はほぼ線形に拡張可能です。単一のクラスタは100ノード以上に拡張でき、10,000を超えるチェンジフィードをサポートし、単一のチェンジフィード内で数百万のテーブルをレプリケートできます。 -- **安定性の向上**：トラフィック量が多く、DDL操作が頻繁に発生し、クラスタのスケーリングイベントが発生するシナリオにおいて、変更フィードのレイテンシーが短縮され、パフォーマンスがより安定します。リソースの分離と優先度スケジューリングにより、複数の変更フィードタスク間の干渉が軽減されます。 +- **拡張性の向上**：クラスターレプリケーション機能はほぼ線形に拡張可能です。単一のクラスターは100ノード以上に拡張でき、10,000を超えるチェンジフィードをサポートし、単一のチェンジフィード内で数百万のテーブルをレプリケートできます。 +- **安定性の向上**：トラフィック量が多く、DDL操作が頻繁に発生し、クラスターのスケーリングイベントが発生するシナリオにおいて、変更フィードのレイテンシーが短縮され、パフォーマンスがより安定します。リソースの分離と優先度スケジューリングにより、複数の変更フィードタスク間の干渉が軽減されます。 - **リソースコストの削減**：リソース利用率の向上と冗長性の削減により、一般的なシナリオではCPUとメモリのリソース使用量を最大50%削減できます。 -## 建築設計 {#architectural-design} +## アーキテクチャ設計 {#architectural-design} ![TiCDC New Architecture](/media/ticdc/ticdc-new-arch-1.png) TiCDCの新しいアーキテクチャは、ログサービスとダウンストリームアダプタという2つの主要コンポーネントで構成されています。 -- ログサービス：コアデータサービスレイヤーとして、ログサービスはアップストリームのTiDBクラスタから行の変更やDDLイベントなどの情報を取得し、変更データをローカルディスクに一時的に保存します。また、ダウンストリームアダプタからのデータ要求にも応答し、DMLデータとDDLデータを定期的にマージおよびソートして、ソート済みのデータをダウンストリームアダプタに送信します。 +- ログサービス：コアデータサービスレイヤーとして、ログサービスはアップストリームのTiDBクラスターから行の変更やDDLイベントなどの情報を取得し、変更データをローカルディスクに一時的に保存します。また、ダウンストリームアダプタからのデータ要求にも応答し、DMLデータとDDLデータを定期的にマージおよびソートして、ソート済みのデータをダウンストリームアダプタに送信します。 - ダウンストリームアダプタ：ダウンストリームデータレプリケーション適応レイヤーとして、ダウンストリームアダプタはユーザーが開始する変更フィード操作を処理します。関連するレプリケーションタスクをスケジュールおよび生成し、ログサービスからデータを取得し、取得したデータをダウンストリームシステムにレプリケートします。 -TiCDCの新しいアーキテクチャは、アーキテクチャをステートフルコンポーネントとステートレスコンポーネントに分離することで、システムの拡張性、信頼性、柔軟性を大幅に向上させています。ステートフルコンポーネントであるログサービスは、データの取得、ソート、およびstorageに重点を置いています。これを変更フィード処理ロジックから分離することで、複数の変更フィード間でデータを共有できるようになり、リソース利用率を効果的に向上させ、システムオーバーヘッドを削減できます。ステートレスコンポーネントであるダウンストリームアダプタは、インスタンス間でレプリケーションタスクを迅速に移行できる軽量スケジューリングメカニズムを使用しています。ワークロードの変化に基づいてレプリケーションタスクの分割とマージを動的に調整できるため、さまざまなシナリオで低遅延のレプリケーションが保証されます。 +TiCDCの新しいアーキテクチャは、アーキテクチャをステートフルコンポーネントとステートレスコンポーネントに分離することで、システムの拡張性、信頼性、柔軟性を大幅に向上させています。ステートフルコンポーネントであるログサービスは、データの取得、ソート、およびストレージに重点を置いています。これを変更フィード処理ロジックから分離することで、複数の変更フィード間でデータを共有できるようになり、リソース利用率を効果的に向上させ、システムオーバーヘッドを削減できます。ステートレスコンポーネントであるダウンストリームアダプタは、インスタンス間でレプリケーションタスクを迅速に移行できる軽量スケジューリングメカニズムを使用しています。ワークロードの変化に基づいてレプリケーションタスクの分割とマージを動的に調整できるため、さまざまなシナリオで低遅延のレプリケーションが保証されます。 -## 古典的建築と新建築の比較 {#comparison-between-the-classic-and-new-architectures} +## 古典的アーキテクチャと新アーキテクチャの比較 {#comparison-between-the-classic-and-new-architectures} 新しいアーキテクチャは、継続的なシステム拡張時に発生するパフォーマンスのボトルネック、安定性の不足、拡張性の制限といった一般的な問題に対処するように設計されています。[古典アーキテクチャ](/ticdc/ticdc-classic-architecture.md)と比較して、新しいアーキテクチャは以下の主要な側面で大幅な最適化を実現しています。 @@ -43,7 +43,7 @@ TiCDCの新しいアーキテクチャは、アーキテクチャをステート ![Comparison between the TiCDC classic and new architectures](/media/ticdc/ticdc-new-arch-2.png) -## クラシックな建築様式と新しい建築様式からお選びください。 {#choose-between-the-classic-and-new-architectures} +## クラシックなアーキテクチャ様式と新しいアーキテクチャ様式からお選びください。 {#choose-between-the-classic-and-new-architectures} ワークロードが次のいずれかの条件を満たす場合は、パフォーマンスと安定性を向上させるために、[従来のTiCDCアーキテクチャ](/ticdc/ticdc-classic-architecture.md)から新しいアーキテクチャに切り替えることをお勧めします。 @@ -114,22 +114,22 @@ TiCDC の従来のアーキテクチャでは、DDL レプリケーション操 - [シンクポイント](/ticdc/ticdc-upstream-downstream-check.md) - [リドゥログ](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios) - [パルサーシンク](/ticdc/ticdc-sink-to-pulsar.md) -- [収納シンク](/ticdc/ticdc-sink-to-cloud-storage.md) +- [収納シンク](/ticdc/ticdc-sink-to-cloud-ストレージ.md) さらに、新しいTiCDCアーキテクチャでは、ダウンストリームレプリケーションのために大規模なトランザクションを複数のバッチに分割する機能が現状ではサポートされていません。そのため、非常に大きなトランザクションを処理する際にメモリ不足（OOM）が発生するリスクが依然として存在します。新しいアーキテクチャを使用する前に、このリスクを適切に評価し、軽減策を講じてください。 ## アップグレードガイド {#upgrade-guide} -新しいアーキテクチャのTiCDCは、TiDBクラスタのバージョン7.5.0以降にのみデプロイできます。デプロイ前に、TiDBクラスタがこの要件を満たしていることを確認してください。 +新しいアーキテクチャのTiCDCは、TiDBクラスターのバージョン7.5.0以降にのみデプロイできます。デプロイ前に、TiDBクラスターがこの要件を満たしていることを確認してください。 TiUPまたはTiDB Operatorを使用して、新しいアーキテクチャにTiCDCノードをデプロイできます。 -### 新しいアーキテクチャでTiCDCノードを備えた新しいTiDBクラスタをデプロイ {#deploy-a-new-tidb-cluster-with-ticdc-nodes-in-the-new-architecture} +### 新しいアーキテクチャでTiCDCノードを備えた新しいTiDBクラスターをデプロイ {#deploy-a-new-tidb-cluster-with-ticdc-nodes-in-the-new-architecture}
    -TiUPを使用して v8.5.4 以降の新しい TiDB クラスタをデプロイする場合、新しいアーキテクチャで TiCDC ノードも同時にデプロイできます。そのためには、 TiUP がTiDB クラスタの起動に使用する構成ファイルに TiCDC 関連のセクションを追加し、 `newarch: true`を設定するだけです。以下に例を示します。 +TiUPを使用して v8.5.4 以降の新しい TiDB クラスターをデプロイする場合、新しいアーキテクチャで TiCDC ノードも同時にデプロイできます。そのためには、 TiUP がTiDB クラスターの起動に使用する構成ファイルに TiCDC 関連のセクションを追加し、 `newarch: true`を設定するだけです。以下に例を示します。 ```yaml cdc_servers: @@ -141,12 +141,12 @@ cdc_servers: newarch: true ``` -TiCDC デプロイメントの詳細については、 [TiUPを使用してTiCDCを含む新しいTiDBクラスタをデプロイ](/ticdc/deploy-ticdc.md#deploy-a-new-tidb-cluster-that-includes-ticdc-using-tiup)参照してください。 +TiCDC デプロイメントの詳細については、 [TiUPを使用してTiCDCを含む新しいTiDBクラスターをデプロイ](/ticdc/deploy-ticdc.md#deploy-a-new-tidb-cluster-that-includes-ticdc-using-tiup)参照してください。
    -TiDB Operator を使用して v8.5.4 以降の新しい TiDB クラスタをデプロイする場合、新しいアーキテクチャで TiCDC ノードを同時にデプロイすることもできます。そのためには、クラスタ構成ファイルに TiCDC 関連のセクションを追加し、 `newarch = true`を設定するだけです。以下に例を示します。 +TiDB Operator を使用して v8.5.4 以降の新しい TiDB クラスターをデプロイする場合、新しいアーキテクチャで TiCDC ノードを同時にデプロイすることもできます。そのためには、クラスター構成ファイルに TiCDC 関連のセクションを追加し、 `newarch = true`を設定するだけです。以下に例を示します。 ```yaml spec: @@ -163,7 +163,7 @@ TiCDC 導入の詳細については、 [TiCDCの新規導入](https://docs.ping
    -### 既存のTiDBクラスタに新しいアーキテクチャでTiCDCノードをデプロイ {#deploy-ticdc-nodes-in-the-new-architecture-in-an-existing-tidb-cluster} +### 既存のTiDBクラスターに新しいアーキテクチャでTiCDCノードをデプロイ {#deploy-ticdc-nodes-in-the-new-architecture-in-an-existing-tidb-cluster}
    @@ -172,7 +172,7 @@ TiUPを使用して新しいアーキテクチャにTiCDCノードをデプロ 1. TiDB クラスターにまだ TiCDC ノードがない場合は、 [TiCDCクラスターをスケールアウトする](/scale-tidb-using-tiup.md#scale-out-a-ticdc-cluster)を参照してクラスターに新しい TiCDC ノードを追加します。それ以外の場合は、この手順をスキップしてください。 -2. TiDBクラスタのバージョンがv8.5.4より前の場合は、新しいアーキテクチャのTiCDCバイナリパッケージを手動でダウンロードし、ダウンロードしたファイルをTiDBクラスタにパッチ適用する必要があります。それ以外の場合は、この手順をスキップしてください。 +2. TiDBクラスターのバージョンがv8.5.4より前の場合は、新しいアーキテクチャのTiCDCバイナリパッケージを手動でダウンロードし、ダウンロードしたファイルをTiDBクラスターにパッチ適用する必要があります。それ以外の場合は、この手順をスキップしてください。 ダウンロード リンクは次の形式に従います: `https://tiup-mirrors.pingcap.com/cdc-${version}-${os}-${arch}.tar.gz` 。ここで、 `${version}`は TiCDC バージョン (利用可能なバージョン[TiCDCが新アーキテクチャ向けにリリース](https://github.com/pingcap/ticdc/releases)方向へのリリースを参照)、 `${os}`はオペレーティング システムです。 `${arch}`は、コンポーネントが実行されるプラットフォーム ( `amd64`または`arm64` ) です。 @@ -189,7 +189,7 @@ TiUPを使用して新しいアーキテクチャにTiCDCノードをデプロ cdc cli changefeed pause --server=http://:8300 --changefeed-id ``` -4. [`tiup cluster patch`](/tiup/tiup-component-cluster-patch.md)コマンドを使用して、ダウンロードした TiCDC バイナリファイルを TiDB クラスタにパッチ適用します。 +4. [`tiup cluster patch`](/tiup/tiup-component-cluster-patch.md)コマンドを使用して、ダウンロードした TiCDC バイナリファイルを TiDB クラスターにパッチ適用します。 ```shell tiup cluster patch ./cdc-v8.5.4-release.1-linux-amd64.tar.gz -R cdc --overwrite @@ -217,9 +217,9 @@ TiUPを使用して新しいアーキテクチャにTiCDCノードをデプロ
    -TiDB Operatorを使用して既存のTiDBクラスタに新しいアーキテクチャでTiCDCノードをデプロイするには、次の手順を実行します。 +TiDB Operatorを使用して既存のTiDBクラスターに新しいアーキテクチャでTiCDCノードをデプロイするには、次の手順を実行します。 -- TiDB クラスターに TiCDCコンポーネントが含まれていない場合は、 [既存のTiDBクラスタにTiCDCを追加する](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-ticdc/#add-ticdc-to-an-existing-tidb-cluster)を参照して、新しい TiCDC ノードを追加します。その際、クラスター構成ファイルで TiCDC イメージのバージョンを新しいアーキテクチャのバージョンとして指定します。利用可能なバージョンについては、 [TiCDCが新アーキテクチャ向けにリリース](https://github.com/pingcap/ticdc/releases)参照してください。 +- TiDB クラスターに TiCDCコンポーネントが含まれていない場合は、 [既存のTiDBクラスターにTiCDCを追加する](https://docs.pingcap.com/tidb-in-kubernetes/stable/deploy-ticdc/#add-ticdc-to-an-existing-tidb-cluster)を参照して、新しい TiCDC ノードを追加します。その際、クラスター構成ファイルで TiCDC イメージのバージョンを新しいアーキテクチャのバージョンとして指定します。利用可能なバージョンについては、 [TiCDCが新アーキテクチャ向けにリリース](https://github.com/pingcap/ticdc/releases)参照してください。 例えば： @@ -233,9 +233,9 @@ TiDB Operatorを使用して既存のTiDBクラスタに新しいアーキテク newarch = true ``` -- TiDBクラスタに既にTiCDCコンポーネントが含まれている場合は、以下の手順を実行してください。 +- TiDBクラスターに既にTiCDCコンポーネントが含まれている場合は、以下の手順を実行してください。 - 1. TiDBクラスタで実行中のチェンジフィードがある場合は、チェンジフィードのすべてのレプリケーションタスクを一時停止してください。 + 1. TiDBクラスターで実行中のチェンジフィードがある場合は、チェンジフィードのすべてのレプリケーションタスクを一時停止してください。 ```shell kubectl exec -it ${pod_name} -n ${namespace} -- sh @@ -246,7 +246,7 @@ TiDB Operatorを使用して既存のTiDBクラスタに新しいアーキテク /cdc cli changefeed pause --server=http://127.0.0.1:8301 --changefeed-id ``` - 2. クラスタ構成ファイル内のTiCDCイメージバージョンを新しいアーキテクチャバージョンに更新してください。 + 2. クラスター構成ファイル内のTiCDCイメージバージョンを新しいアーキテクチャバージョンに更新してください。 ```shell kubectl edit tc ${cluster_name} -n ${namespace} @@ -298,6 +298,6 @@ cdc cli changefeed query -s --server=http://127.0.0.1:8300 --changefeed-id=simpl ## 監視 {#monitoring} -新しいアーキテクチャにおける TiCDC の監視ダッシュボードは**、TiCDC-New-Arch**です。TiDB クラスタのバージョンが v8.5.4 以降の場合、この監視ダッシュボードはクラスタのデプロイまたはアップグレード時に Grafana に統合されるため、手動操作は不要です。クラスタのバージョンが v8.5.4 より前の場合は、監視を有効にするために[TiCDC監視メトリクスファイル](https://github.com/pingcap/ticdc/blob/master/metrics/grafana/ticdc_new_arch.json)を手動でインポートする必要があります。 +新しいアーキテクチャにおける TiCDC の監視ダッシュボードは**、TiCDC-New-Arch**です。TiDB クラスターのバージョンが v8.5.4 以降の場合、この監視ダッシュボードはクラスターのデプロイまたはアップグレード時に Grafana に統合されるため、手動操作は不要です。クラスターのバージョンが v8.5.4 より前の場合は、監視を有効にするために[TiCDC監視メトリクスファイル](https://github.com/pingcap/ticdc/blob/master/metrics/grafana/ticdc_new_arch.json)を手動でインポートする必要があります。 インポート手順と各監視メトリクスの詳細な説明については、 [新アーキテクチャにおけるTiCDCのメトリクス](/ticdc/monitor-ticdc.md#metrics-for-ticdc-in-the-new-architecture)参照してください。 diff --git a/ticdc/ticdc-bidirectional-replication.md b/ticdc/ticdc-bidirectional-replication.md index e8239d0e109f0..59aa1ce6a3919 100644 --- a/ticdc/ticdc-bidirectional-replication.md +++ b/ticdc/ticdc-bidirectional-replication.md @@ -5,7 +5,7 @@ summary: TiCDC の双方向レプリケーションの使用方法を学習し # 双方向レプリケーション {#bidirectional-replication} -TiCDCは、2つのTiDBクラスタ間の双方向レプリケーション（BDR）をサポートしています。この機能を利用することで、TiCDCを使用したマルチアクティブTiDBソリューションを構築できます。 +TiCDCは、2つのTiDBクラスター間の双方向レプリケーション（BDR）をサポートしています。この機能を利用することで、TiCDCを使用したマルチアクティブTiDBソリューションを構築できます。 このセクションでは、2 つの TiDB クラスターを例にして双方向レプリケーションを使用する方法について説明します。 @@ -21,7 +21,7 @@ TiCDCは、指定されたタイムスタンプ以降に発生した増分デー 3. アップストリーム クラスターとダウンストリーム クラスターのデータ複製の開始時点を指定します。 - 1. 上流クラスタと下流クラスタの時点を確認します。2つのTiDBクラスタがある場合は、特定の時点において2つのクラスタのデータが整合していることを確認します。例えば、TiDB 1の`ts=1`時点のデータとTiDB 2の`ts=2`のデータは整合しています。 + 1. 上流クラスターと下流クラスターの時点を確認します。2つのTiDBクラスターがある場合は、特定の時点において2つのクラスターのデータが整合していることを確認します。例えば、TiDB 1の`ts=1`時点のデータとTiDB 2の`ts=2`のデータは整合しています。 2. changefeed を作成する際、上流クラスターの changefeed の`--start-ts`対応する`tso`に設定します。つまり、上流クラスターが TiDB 1 の場合は`--start-ts=1` 、下流クラスターが TiDB 2 の場合は`--start-ts=2`設定します。 @@ -66,7 +66,7 @@ v7.6.0 以降、双方向レプリケーションで DDL レプリケーショ ### 複製不可能なDDL {#non-replicable-ddls} -複製不可能なDDLは、ビジネスへの影響が大きく、クラスタ間のデータ不整合を引き起こす可能性のあるDDLです。複製不可能なDDLは、TiCDCを介した双方向レプリケーションにおいて、他のTiDBクラスタに直接複製することはできません。複製不可能なDDLは、特定の操作を通じて実行する必要があります。 +複製不可能なDDLは、ビジネスへの影響が大きく、クラスター間のデータ不整合を引き起こす可能性のあるDDLです。複製不可能なDDLは、TiCDCを介した双方向レプリケーションにおいて、他のTiDBクラスターに直接複製することはできません。複製不可能なDDLは、特定の操作を通じて実行する必要があります。 レプリケートできない DDL には次のものが含まれます。 @@ -153,20 +153,20 @@ BDRロールが設定されていない場合、任意のDDLを実行できま - 1 `PRIMARY`クラスターと n `SECONDARY`クラスター（複製可能な DDL のレプリケーション シナリオ） - - BDR ロールを持たない n 個のクラスタ（各クラスタで複製不可能な DDL を手動で実行できるレプリケーション シナリオ） + - BDR ロールを持たない n 個のクラスター（各クラスターで複製不可能な DDL を手動で実行できるレプリケーション シナリオ） > **注記：** > > 他のシナリオではBDRロールを設定しないでください。例えば、BDRロールを`PRIMARY` 、 `SECONDARY` 、そして0つを同時に設定しないでください。BDRロールを誤って設定すると、TiDBはデータレプリケーション中にデータの正確性と一貫性を保証できません。 -- 通常、レプリケートされたテーブルでのデータ競合を避けるため、 [`AUTO_INCREMENT`](/auto-increment.md)または[`AUTO_RANDOM`](/auto-random.md)使用しないでください。5 または`AUTO_INCREMENT` `AUTO_RANDOM`使用する必要がある場合は、異なるクラスタに異なる主キーを割り当てることができるように、異なるクラスタに異なる`auto_increment_increment`と`auto_increment_offset`設定できます。例えば、双方向レプリケーションに3つのTiDBクラスタ（A、B、C）がある場合、次のように設定します。 +- 通常、レプリケートされたテーブルでのデータ競合を避けるため、 [`AUTO_INCREMENT`](/auto-increment.md)または[`AUTO_RANDOM`](/auto-random.md)使用しないでください。5 または`AUTO_INCREMENT` `AUTO_RANDOM`使用する必要がある場合は、異なるクラスターに異なる主キーを割り当てることができるように、異なるクラスターに異なる`auto_increment_increment`と`auto_increment_offset`設定できます。例えば、双方向レプリケーションに3つのTiDBクラスター（A、B、C）がある場合、次のように設定します。 - - クラスタAでは、 `auto_increment_increment=3`と`auto_increment_offset=2000`設定します - - クラスタBでは、 `auto_increment_increment=3`と`auto_increment_offset=2001`設定します - - クラスタCでは、 `auto_increment_increment=3`と`auto_increment_offset=2002`設定します + - クラスターAでは、 `auto_increment_increment=3`と`auto_increment_offset=2000`設定します + - クラスターBでは、 `auto_increment_increment=3`と`auto_increment_offset=2001`設定します + - クラスターCでは、 `auto_increment_increment=3`と`auto_increment_offset=2002`設定します これにより、A、B、Cは暗黙的に割り当てられた`AUTO_INCREMENT`と`AUTO_RANDOM`で互いに競合することがなくなります。BDRモードでクラスターを追加する必要がある場合は、関連アプリケーションのデータ書き込みを一時的に停止し、すべてのクラスターの`auto_increment_increment`と`auto_increment_offset`に適切な値を設定してから、関連アプリケーションのデータ書き込みを再開する必要があります。 -- 双方向レプリケーションクラスタは書き込み競合を検出できないため、未定義の動作が発生する可能性があります。そのため、アプリケーション側で書き込み競合がないことを確認する必要があります。 +- 双方向レプリケーションクラスターは書き込み競合を検出できないため、未定義の動作が発生する可能性があります。そのため、アプリケーション側で書き込み競合がないことを確認する必要があります。 -- 双方向レプリケーションは2つ以上のクラスタをサポートしますが、カスケードモード、つまりTiDB A -> TiDB B -> TiDB C -> TiDB Aのような循環レプリケーションはサポートしません。このようなトポロジでは、1つのクラスタに障害が発生すると、データレプリケーション全体に影響が出ます。したがって、複数のクラスタ間で双方向レプリケーションを有効にするには、各クラスタを他のすべてのクラスタ（例： `TiDB A <-> TiDB B` `TiDB C <-> TiDB A`に接続する`TiDB B <-> TiDB C`があります。 +- 双方向レプリケーションは2つ以上のクラスターをサポートしますが、カスケードモード、つまりTiDB A -> TiDB B -> TiDB C -> TiDB Aのような循環レプリケーションはサポートしません。このようなトポロジでは、1つのクラスターに障害が発生すると、データレプリケーション全体に影響が出ます。したがって、複数のクラスター間で双方向レプリケーションを有効にするには、各クラスターを他のすべてのクラスター（例： `TiDB A <-> TiDB B` `TiDB C <-> TiDB A`に接続する`TiDB B <-> TiDB C`があります。 diff --git a/ticdc/ticdc-changefeed-config.md b/ticdc/ticdc-changefeed-config.md index c8bbc50cbbb28..75498b332e0d4 100644 --- a/ticdc/ticdc-changefeed-config.md +++ b/ticdc/ticdc-changefeed-config.md @@ -3,7 +3,7 @@ title: CLI and Configuration Parameters of TiCDC Changefeeds summary: TiCDCチェンジフィードのCLIの定義と設定パラメータについて学びましょう。 --- -# TiCDC ChangefeedsのCLIとコンフィグレーションパラメータ {#cli-and-configuration-parameters-of-ticdc-changefeeds} +# TiCDC ChangefeedsのCLIと設定パラメータ {#cli-and-configuration-parameters-of-ticdc-changefeeds} ## 変更フィードCLIパラメータ {#changefeed-cli-parameters} @@ -16,7 +16,7 @@ cdc cli changefeed create --server=http://10.0.10.25:8300 --sink-uri="mysql://ro ```shell Create changefeed successfully! ID: simple-replication-task -Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-replication-task","sink_uri":"mysql://root:xxxxx@127.0.0.1:4000/?time-zone=","create_time":"2025-11-27T15:05:46.679218+08:00","start_ts":438156275634929669,"engine":"unified","config":{"case_sensitive":false,"force_replicate":false,"ignore_ineligible_table":false,"check_gc_safe_point":true,"enable_sync_point":true,"bdr_mode":false,"sync_point_interval":30000000000,"sync_point_retention":3600000000000,"filter":{"rules":["test.*"],"event_filters":null},"mounter":{"worker_num":16},"sink":{"protocol":"","schema_registry":"","csv":{"delimiter":",","quote":"\"","null":"\\N","include_commit_ts":false},"column_selectors":null,"transaction_atomicity":"none","encoder_concurrency":16,"terminator":"\r\n","date_separator":"none","enable_partition_separator":false},"consistent":{"level":"none","max_log_size":64,"flush_interval":2000,"storage":""}},"state":"normal","creator_version":"v8.5.4"} +Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-replication-task","sink_uri":"mysql://root:xxxxx@127.0.0.1:4000/?time-zone=","create_time":"2025-11-27T15:05:46.679218+08:00","start_ts":438156275634929669,"engine":"unified","config":{"case_sensitive":false,"force_replicate":false,"ignore_ineligible_table":false,"check_gc_safe_point":true,"enable_sync_point":true,"bdr_mode":false,"sync_point_interval":30000000000,"sync_point_retention":3600000000000,"filter":{"rules":["test.*"],"event_filters":null},"mounter":{"worker_num":16},"sink":{"protocol":"","schema_registry":"","csv":{"delimiter":",","quote":"\"","null":"\\N","include_commit_ts":false},"column_selectors":null,"transaction_atomicity":"none","encoder_concurrency":16,"terminator":"\r\n","date_separator":"none","enable_partition_separator":false},"consistent":{"level":"none","max_log_size":64,"flush_interval":2000,"ストレージ":""}},"state":"normal","creator_version":"v8.5.4"} ``` - `--changefeed-id` : レプリケーションタスクのID。形式は`^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$`正規表現に一致する必要があります。このIDが指定されていない場合、TiCDCは自動的にUUID（バージョン4形式）をIDとして生成します。 @@ -27,9 +27,9 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl シンク URI パラメータに`! * ' ( ) ; : @ & = + $ , / ? % # [ ]`などの特殊文字が含まれている場合は、 [URIエンコーダー](https://www.urlencoder.org/)のように特殊文字をエスケープする必要があります。 -- `--start-ts` : 変更フィードの開始TSOを指定します。TiCDCクラスタはこのTSOからデータの取得を開始します。デフォルト値は現在時刻です。 +- `--start-ts` : 変更フィードの開始TSOを指定します。TiCDCクラスターはこのTSOからデータの取得を開始します。デフォルト値は現在時刻です。 -- `--target-ts` : 変更フィードの終了TSOを指定します。このTSOに達すると、TiCDCクラスタはデータのプルを停止します。デフォルト値は空で、これはTiCDCが自動的にデータのプルを停止しないことを意味します。 +- `--target-ts` : 変更フィードの終了TSOを指定します。このTSOに達すると、TiCDCクラスターはデータのプルを停止します。デフォルト値は空で、これはTiCDCが自動的にデータのプルを停止しないことを意味します。 - `--config` : 変更フィードの設定ファイルを指定します。 @@ -125,7 +125,7 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl ##### ignore-event {#code-ignore-event-code} - `ignore-event = ["insert"]`は`INSERT`イベントを無視します。 -- `ignore-event = ["drop table", "delete"]`は`DROP TABLE` DDL イベントと`DELETE` DML イベントを無視します。 TiDB でクラスタ化インデックス列の値が更新されると、TiCDC は`UPDATE`イベントを`DELETE`イベントと`INSERT`イベントに分割することに注意してください。 TiCDC はこれらのイベントを`UPDATE`イベントとして識別できないため、これらのイベントを正しくフィルタリングできません。 +- `ignore-event = ["drop table", "delete"]`は`DROP TABLE` DDL イベントと`DELETE` DML イベントを無視します。 TiDB でクラスター化インデックス列の値が更新されると、TiCDC は`UPDATE`イベントを`DELETE`イベントと`INSERT`イベントに分割することに注意してください。 TiCDC はこれらのイベントを`UPDATE`イベントとして識別できないため、これらのイベントを正しくフィルタリングできません。 ##### ignore-sql {#code-ignore-sql-code} @@ -200,10 +200,10 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl #### protocol {#code-protocol-code} - メッセージのエンコードに使用されるプロトコル形式を指定します。 -- この設定項目は、ダウンストリームがKafka、Pulsar、またはstorageサービスの場合にのみ有効になります。 +- この設定項目は、ダウンストリームがKafka、Pulsar、またはストレージサービスの場合にのみ有効になります。 - ダウンストリームがKafkaの場合、プロトコルはcanal-json、avro、debezium、open-protocol、またはsimpleのいずれかになります。 - ダウンストリームがPulsarの場合、プロトコルはcanal-jsonのみとなります。 -- ダウンストリームがstorageサービスの場合、プロトコルはcanal-jsonまたはcsvのみとなります。 +- ダウンストリームがストレージサービスの場合、プロトコルはcanal-jsonまたはcsvのみとなります。 @@ -249,23 +249,23 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl #### terminator {#code-terminator-code} -- この構成項目は、データをstorageシンクにレプリケートする場合にのみ使用され、MQまたはMySQLシンクにデータをレプリケートする場合は無視できます。 +- この構成項目は、データをストレージシンクにレプリケートする場合にのみ使用され、MQまたはMySQLシンクにデータをレプリケートする場合は無視できます。 - 2つのデータ変更イベントを区切るために使用される行終端文字を指定します。 - デフォルト値: `""` 、つまり`\r\n`が使用されます。 #### date-separator {#code-date-separator-code} -- ファイル ディレクトリで使用される日付区切り文字のタイプを指定します。詳細については、 [データ変更記録](/ticdc/ticdc-sink-to-cloud-storage.md#data-change-records)参照してください。 -- この設定項目は、ダウンストリームがstorageサービスである場合にのみ有効になります。 +- ファイル ディレクトリで使用される日付区切り文字のタイプを指定します。詳細については、 [データ変更記録](/ticdc/ticdc-sink-to-cloud-ストレージ.md#data-change-records)参照してください。 +- この設定項目は、ダウンストリームがストレージサービスである場合にのみ有効になります。 - デフォルト値: `day` 、ファイルを日付ごとに分割することを意味します。 - 値のオプション: `none` 、 `year` 、 `month` 、 `day` #### enable-partition-separator {#code-enable-partition-separator-code} - パーティションを区切り文字として使用するかどうかを制御します。 -- この設定項目は、ダウンストリームがstorageサービスである場合にのみ有効になります。 +- この設定項目は、ダウンストリームがストレージサービスである場合にのみ有効になります。 - デフォルト値： `true` 。これは、テーブル内のパーティションが別々のディレクトリに保存されることを意味します。 -- この設定は将来のバージョンで非推奨となり、 `true`に強制的に設定されますのでご注意ください。下流のパーティションテーブルでのデータ損失を防ぐため、この設定はデフォルト値のままにしておくことをお勧めします。詳細については、 [第11979号](https://github.com/pingcap/tiflow/issues/11979)を参照してください。使用例については、データ[データ変更記録](/ticdc/ticdc-sink-to-cloud-storage.md#data-change-records)参照してください。 +- この設定は将来のバージョンで非推奨となり、 `true`に強制的に設定されますのでご注意ください。下流のパーティションテーブルでのデータ損失を防ぐため、この設定はデフォルト値のままにしておくことをお勧めします。詳細については、 [第11979号](https://github.com/pingcap/tiflow/issues/11979)を参照してください。使用例については、データ[データ変更記録](/ticdc/ticdc-sink-to-cloud-ストレージ.md#data-change-records)参照してください。 #### debezium-disable-schema {#code-debezium-disable-schema-code} @@ -275,7 +275,7 @@ Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-repl #### sink.csv はv6.5.0 で追加されました。 {#sink-csv-span-class-version-mark-new-in-v6-5-0-span} -バージョン6.5.0以降、TiCDCはデータ変更をCSV形式でstorageサービスに保存することをサポートしています。データをMQまたはMySQLシンクにレプリケートする場合は、以下の設定は無視してください。 +バージョン6.5.0以降、TiCDCはデータ変更をCSV形式でストレージサービスに保存することをサポートしています。データをMQまたはMySQLシンクにレプリケートする場合は、以下の設定は無視してください。 ##### delimiter {#code-delimiter-code} @@ -383,9 +383,9 @@ REDO ログを使用する場合の変更フィードのレプリケーション - デフォルト値: `2000` - 単位：ミリ秒 -#### storage {#code-storage-code} +#### ストレージ {#code-ストレージ-code} -- リドゥログのstorageURI。 +- リドゥログのストレージURI。 - デフォルト値: `""` #### use-file-backend {#code-use-file-backend-code} @@ -588,21 +588,21 @@ token="xxxx" - 元のデータ変更イベントを出力するかどうかを制御します。詳細については、 [プライマリキーまたはユニークキーの`UPDATE`イベントを分割するかどうかを制御します](/ticdc/ticdc-split-update-behavior.md#control-whether-to-split-primary-or-unique-key-update-events)参照してください。 - デフォルト値: `false` -### sink.cloud-storage-config {#sink-cloud-storage-config} +### sink.cloud-ストレージ-config {#sink-cloud-ストレージ-config} #### worker-count {#code-worker-count-code} -- ダウンストリームのクラウドstorageの同時実行性が変更されます。 +- ダウンストリームのクラウドストレージの同時実行性が変更されます。 - デフォルト値: `16` #### flush-interval {#code-flush-interval-code} -- 下流のクラウドstorageにデータを保存する間隔が変更されます。 +- 下流のクラウドストレージにデータを保存する間隔が変更されます。 - デフォルト値: `"2s"` #### file-size {#code-file-size-code} -- このファイルのバイト数`file-size`を超えると、データ変更ファイルがクラウドstorageに保存されます。 +- このファイルのバイト数`file-size`を超えると、データ変更ファイルがクラウドストレージに保存されます。 - デフォルト値： `67108864` 、つまり64MiB #### file-expiration-days {#code-file-expiration-days-code} diff --git a/ticdc/ticdc-classic-architecture.md b/ticdc/ticdc-classic-architecture.md index 74d66a9917c4e..865790a4203d7 100644 --- a/ticdc/ticdc-classic-architecture.md +++ b/ticdc/ticdc-classic-architecture.md @@ -57,7 +57,7 @@ TiCDCにおけるChangefeedとTaskは、2つの論理的な概念です。具体 {matcher = ['test3.tab3', 'test4.tab4'], topic = "{schema}_{table}"}, ] -前述の`cdc cli changefeed create`コマンドのパラメータの詳細については、 [TiCDC Changefeedコンフィグレーションパラメータ](/ticdc/ticdc-changefeed-config.md)参照してください。 +前述の`cdc cli changefeed create`コマンドのパラメータの詳細については、 [TiCDC Changefeed設定パラメータ](/ticdc/ticdc-changefeed-config.md)参照してください。 上記のコマンド`cdc cli changefeed create`は、 `test1.tab1` 、 `test1.tab2` 、 `test3.tab3` 、 `test4.tab4` Kafkaクラスターに複製する changefeed タスクを作成します。TiCDCがこのコマンドを受信した後の処理フローは以下のとおりです。 @@ -88,12 +88,12 @@ TiCDCの上流は、トランザクションをサポートする分散リレー 下流のリレーショナルデータベースでは、TiCDC は単一テーブル内のトランザクションの一貫性と、複数テーブルにおける最終的なトランザクションの一貫性を保証します。さらに、TiCDC は上流の TiDB クラスターで発生したデータ変更が下流に少なくとも 1 回は複製されることを保証します。 -### 建築関連の概念 {#architecture-related-concepts} +### アーキテクチャ関連の概念 {#architecture-related-concepts} - キャプチャ：TiCDCノードを実行するプロセス。複数のキャプチャプロセスがTiCDCクラスターを構成します。各キャプチャプロセスは、TiKVへのデータ変更のレプリケーション（データ変更の受信とアクティブプル、ダウンストリームへのデータレプリケーションなど）を担当します。 -- キャプチャオーナー：複数のキャプチャプロセスにおけるキャプチャのオーナー。TiCDCクラスタには、一度に1つのオーナーロールのみが存在します。キャプチャオーナーは、クラスタ内のデータのスケジュール設定を担当します。 +- キャプチャオーナー：複数のキャプチャプロセスにおけるキャプチャのオーナー。TiCDCクラスターには、一度に1つのオーナーロールのみが存在します。キャプチャオーナーは、クラスター内のデータのスケジュール設定を担当します。 - プロセッサ: Captureノード内の論理スレッド。各プロセッサは、同じレプリケーションストリーム内の1つ以上のテーブルのデータを処理する役割を担います。Captureノードは複数のプロセッサを実行できます。 -- チェンジフィード: 上流のTiDBクラスタから下流のシステムにデータを複製するタスク。チェンジフィードには複数のタスクが含まれ、各タスクはキャプチャノードによって処理されます。 +- チェンジフィード: 上流のTiDBクラスターから下流のシステムにデータを複製するタスク。チェンジフィードには複数のタスクが含まれ、各タスクはキャプチャノードによって処理されます。 ### タイムスタンプ関連の概念 {#timestamp-related-concepts} diff --git a/ticdc/ticdc-compatibility.md b/ticdc/ticdc-compatibility.md index 0e42781e165b9..37686762fe756 100644 --- a/ticdc/ticdc-compatibility.md +++ b/ticdc/ticdc-compatibility.md @@ -7,9 +7,9 @@ summary: TiCDCの互換性に関する問題とその対処方法について学 このセクションでは、TiCDCに関連する互換性の問題と、それらの対処方法について説明します。 -## TiCDCの新アーキテクチャとTiDBクラスタ間の互換性 {#compatibility-between-ticdc-new-architecture-and-tidb-clusters} +## TiCDCの新アーキテクチャとTiDBクラスター間の互換性 {#compatibility-between-ticdc-new-architecture-and-tidb-clusters} -TiCDCの新しいアーキテクチャは、TiDBクラスタv7.5.0以降をサポートしています。 [互換性](/ticdc/ticdc-architecture.md#compatibility)に関する特別な注意事項については、を参照してください。 。 +TiCDCの新しいアーキテクチャは、TiDBクラスターv7.5.0以降をサポートしています。 [互換性](/ticdc/ticdc-architecture.md#compatibility)に関する特別な注意事項については、を参照してください。 。 ## TiDB Lightningとの互換性 {#compatibility-with-tidb-lightning} @@ -22,35 +22,35 @@ TiCDCの新しいアーキテクチャは、TiDBクラスタv7.5.0以降をサ 物理インポートモードでは、 TiDB Lightning はSST ファイルを TiKV に挿入することでデータをインポートします。TiCDC はこのモードと互換性がなく、物理インポートモードでインポートされたデータの複製をサポートしていません。TiDB Lightning の物理インポートモードと TiCDC の両方を使用する必要がある場合は、ダウンストリームシステムに基づいて、以下のいずれかのソリューションを選択してください。 -- ダウンストリームがTiDBクラスタである場合は、以下の手順を実行してください。 +- ダウンストリームがTiDBクラスターである場合は、以下の手順を実行してください。 - 1. データの一貫性を確保するため、 TiDB Lightningを使用してデータをアップストリームとダウンストリームの両方のTiDBクラスタにインポートしてください。 + 1. データの一貫性を確保するため、 TiDB Lightningを使用してデータをアップストリームとダウンストリームの両方のTiDBクラスターにインポートしてください。 2. 変更フィードを作成して、SQL を通じて書き込まれた後続の増分データをレプリケートします。詳細については、 [レプリケーションタスクを作成する](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task)参照してください。 -- ダウンストリームがTiDBクラスタでない場合は、以下の手順を実行してください。 +- ダウンストリームがTiDBクラスターでない場合は、以下の手順を実行してください。 1. TiDB Lightningの入力ファイルをインポートするには、ダウンストリームシステムが提供するオフラインインポートツールを使用してください。 2. 変更フィードを作成して、SQL を通じて書き込まれた後続の増分データをレプリケートします。詳細については、 [レプリケーションタスクを作成する](/ticdc/ticdc-manage-changefeed.md#create-a-replication-task)参照してください。 ## TiFlashとの互換性 {#compatibility-with-tiflash} -現在、TiCDC を使用してテーブルを下流の TiDB クラスタにレプリケートする場合、テーブルのTiFlashレプリカを作成することはサポートされていません。つまり、TiCDC は、次のようなTiFlash関連の DDL ステートメントのレプリケートをサポートしていません。 +現在、TiCDC を使用してテーブルを下流の TiDB クラスターにレプリケートする場合、テーブルのTiFlashレプリカを作成することはサポートされていません。つまり、TiCDC は、次のようなTiFlash関連の DDL ステートメントのレプリケートをサポートしていません。 - `ALTER TABLE table_name SET TIFLASH REPLICA count;` - `ALTER DATABASE db_name SET TIFLASH REPLICA count;` ## 以前のバージョンからのアップグレードに関する互換性に関する注意事項 {#compatibility-notes-for-upgrading-from-earlier-versions} -TiCDCは、上流の変更データおよび関連インターフェースを提供するために、TiDB、TiKV、およびPDに依存しています。TiDBおよび関連コンポーネントは進化を続けており、これらのデータ形式やインターフェースも変更される可能性があります。例えば、TiDBの並列DDLや高速テーブル作成などの機能は、関連するロジックやデータ処理ワークフローを変更する可能性があり、TiCDCはそれに応じた対応が必要となります。そのため、従来**のTiCDCアーキテクチャでは、バージョンをまたいだTiDB/TiKV/PD混在環境における公式な前方互換性または後方互換性は保証されません**。TiCDCの新しいアーキテクチャでは、v7.5.0以降のTiDBクラスタとの**後方互換性**が提供されます。 +TiCDCは、上流の変更データおよび関連インターフェースを提供するために、TiDB、TiKV、およびPDに依存しています。TiDBおよび関連コンポーネントは進化を続けており、これらのデータ形式やインターフェースも変更される可能性があります。例えば、TiDBの並列DDLや高速テーブル作成などの機能は、関連するロジックやデータ処理ワークフローを変更する可能性があり、TiCDCはそれに応じた対応が必要となります。そのため、従来**のTiCDCアーキテクチャでは、バージョンをまたいだTiDB/TiKV/PD混在環境における公式な前方互換性または後方互換性は保証されません**。TiCDCの新しいアーキテクチャでは、v7.5.0以降のTiDBクラスターとの**後方互換性**が提供されます。 ### TiCDCクラシックアーキテクチャのアップグレードに関する推奨事項 {#upgrade-recommendations-for-the-ticdc-classic-architecture} TiCDC をクラシックアーキテクチャから新しいアーキテクチャにアップグレードする前に、すべての変更フィードを一時停止します。詳細については、 [TiCDC新アーキテクチャアップグレードガイド](/ticdc/ticdc-architecture.md#upgrade-guide)を参照してください。 -アップグレードが、両方ともクラシックアーキテクチャを使用する TiCDC デプロイメント間で行われる場合、マイナーバージョン間のローリングアップグレードがサポートされます。ただし、メジャーバージョン間のアップグレード (たとえば、v8.5.0 -> v8.5.3 はマイナーバージョンアップグレード、v8.1.x -> v8.5.x はメジャーバージョンアップグレード) の場合、 **TiDB クラスタのローリングアップグレード中にチェンジフィードを実行し続けることは推奨されません**。メジャーバージョンアップグレードの場合は、次の手順を順番に実行してください。 +アップグレードが、両方ともクラシックアーキテクチャを使用する TiCDC デプロイメント間で行われる場合、マイナーバージョン間のローリングアップグレードがサポートされます。ただし、メジャーバージョン間のアップグレード (たとえば、v8.5.0 -> v8.5.3 はマイナーバージョンアップグレード、v8.1.x -> v8.5.x はメジャーバージョンアップグレード) の場合、 **TiDB クラスターのローリングアップグレード中にチェンジフィードを実行し続けることは推奨されません**。メジャーバージョンアップグレードの場合は、次の手順を順番に実行してください。 1. すべての変更フィードを一時停止します。 -2. TiDBクラスタに対してローリングアップグレードを実行します。 +2. TiDBクラスターに対してローリングアップグレードを実行します。 3. アップグレード完了後、すべての変更フィードを再開してください。 例えば、クラスターをv8.5.4からv8.5.5にアップグレードする場合、 TiUPを使用してクラスターを管理している場合は、以下のコマンドを参照してください。以下の例では`linux-amd64`を使用しています。他のプラットフォームの場合は、環境に合わせてパッケージ名のプラットフォーム情報を置き換えてください。 @@ -88,7 +88,7 @@ TiCDC クラシック アーキテクチャと新しいアーキテクチャの このセクションでは、TiCDCに関連する互換性の問題と、それらの対処方法について説明します。 -### TiCDC v5.0.0-rc cdc cliツールを使用してv4.0.xクラスタを操作すると、互換性の問題が発生します。 {#incompatibility-issue-caused-by-using-the-ticdc-v5-0-0-rc-code-cdc-cli-code-tool-to-operate-a-v4-0-x-cluster} +### TiCDC v5.0.0-rc cdc cliツールを使用してv4.0.xクラスターを操作すると、互換性の問題が発生します。 {#incompatibility-issue-caused-by-using-the-ticdc-v5-0-0-rc-code-cdc-cli-code-tool-to-operate-a-v4-0-x-cluster} TiCDC v5.0.0-rc の`cdc cli`ツールを使用して v4.0.x TiCDC クラスターを操作する場合、次のような異常な状況が発生する可能性があります。 @@ -98,10 +98,10 @@ TiCDC v5.0.0-rc の`cdc cli`ツールを使用して v4.0.x TiCDC クラスタ 解決策： -TiCDCクラスタのバージョンに対応する`cdc`実行可能ファイルを使用して、以下の操作を実行します。 +TiCDCクラスターのバージョンに対応する`cdc`実行可能ファイルを使用して、以下の操作を実行します。 1. v5.0.0-rc `cdc cli`ツールを使用して作成された変更フィードを削除します。たとえば、 `tiup cdc:v4.0.9 cli changefeed remove -c xxxx --pd=xxxxx --force`コマンドを実行します。 -2. レプリケーションタスクが停止している場合は、TiCDCクラスタを再起動してください。たとえば、 `tiup cluster restart -R cdc`コマンドを実行します。 +2. レプリケーションタスクが停止している場合は、TiCDCクラスターを再起動してください。たとえば、 `tiup cluster restart -R cdc`コマンドを実行します。 3. 変更フィードを再作成します。たとえば、 `tiup cdc:v4.0.9 cli changefeed create --sink-uri=xxxx --pd=xxx`コマンドを実行します。 > **注記：** @@ -116,19 +116,19 @@ TiCDCクラスタのバージョンに対応する`cdc`実行可能ファイル | :---------------------------------------------------- | :--------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :-------------------------------------------------------------- | | v4.0.11 またはそれ以前の v4.0 バージョン、v5.0.0-rc | これはチェンジフィード構成項目であり、 `file`ソーターと`unified`ソーターの一時ファイルディレクトリを指定します。 | これらのバージョンでは、 `file`ソーターと`unified`ソーターは**実験的機能**であり、本番環境での使用は推奨され**ません**。

    複数のチェンジフィードが`unified`ソーターを`sort-engine`として使用する場合、実際の一時ファイルディレクトリは、いずれかのチェンジフィードの`sort-dir`構成になる可能性があり、各TiCDCノードで使用されるディレクトリは異なる可能性があります。 | `unified`ソーターを本番環境で使用することは推奨されません。 | | v4.0.12、v4.0.13、v5.0.0、および v5.0.1 | これは、changefeed または`cdc server`の構成項目です。 | デフォルトでは、変更フィードの`sort-dir`設定は有効にならず、 `sort-dir`の`cdc server`設定は`/tmp/cdc_sort`にデフォルト設定されます。本番環境では`cdc server`のみを設定することをお勧めします。

    TiUPを使用してTiCDCをデプロイする場合は、最新のTiUPバージョンを使用し、TiCDCサーバー構成で`sorter.sort-dir`を設定することをお勧めします。

    `unified`ソーターは、v4.0.13、v5.0.0、v5.0.1 でデフォルトで有効になっています。クラスターをこれらのバージョンにアップグレードする場合は、TiCDCサーバー構成で`sorter.sort-dir`正しく構成されていることを確認してください。 | `sort-dir` `cdc server`コマンドラインパラメータ (またはTiUP) を使用して設定する必要があります。 | -| v4.0.14以降、v4.0バージョン、v5.0.3以降、v5.0バージョン、それ以降のTiDBバージョン | `sort-dir`は非推奨です。 `data-dir`を設定することをお勧めします。 | 最新バージョンのTiUPを使用して`data-dir`を構成できます。これらの TiDB バージョンでは、 `unified`ソーターがデフォルトで有効になっています。クラスターをアップグレードする際は、 `data-dir`正しく構成されていることを確認してください。そうでない場合、 `/tmp/cdc_data`デフォルトで一時ファイル ディレクトリとして使用されます。

    ディレクトリが配置されているデバイスのstorage容量が不足している場合、ハードディスクの空き容量不足の問題が発生する可能性があります。この場合、changefeed の以前の`sort-dir`設定は無効になります。 | `data-dir` `cdc server`コマンドラインパラメータ (またはTiUP) を使用して設定する必要があります。 | +| v4.0.14以降、v4.0バージョン、v5.0.3以降、v5.0バージョン、それ以降のTiDBバージョン | `sort-dir`は非推奨です。 `data-dir`を設定することをお勧めします。 | 最新バージョンのTiUPを使用して`data-dir`を構成できます。これらの TiDB バージョンでは、 `unified`ソーターがデフォルトで有効になっています。クラスターをアップグレードする際は、 `data-dir`正しく構成されていることを確認してください。そうでない場合、 `/tmp/cdc_data`デフォルトで一時ファイル ディレクトリとして使用されます。

    ディレクトリが配置されているデバイスのストレージ容量が不足している場合、ハードディスクの空き容量不足の問題が発生する可能性があります。この場合、changefeed の以前の`sort-dir`設定は無効になります。 | `data-dir` `cdc server`コマンドラインパラメータ (またはTiUP) を使用して設定する必要があります。 | | v6.0.0以降のバージョン | `data-dir` TiCDC によって生成された一時ファイルを保存するために使用されます。 | バージョン6.0.0以降、TiCDCはデフォルトで`db sorter`ソートエンジンとして使用します。 `data-dir`はこのエンジンのディスクディレクトリです。 | `data-dir` `cdc server`コマンドラインパラメータ (またはTiUP) を使用して設定する必要があります。 | ### 一時テーブルとの互換性 {#compatibility-with-temporary-tables} TiCDC は v5.3.0 以降、 [グローバル一時テーブル](/temporary-tables.md#global-temporary-tables)をサポートしています。 v5.3.0 より前のバージョンの TiCDC を使用してグローバル一時テーブルをダウンストリームにレプリケートすると、テーブル定義エラーが発生します。 -アップストリームクラスタにグローバル一時テーブルが含まれている場合、ダウンストリームのTiDBクラスタはv5.3.0以降のバージョンである必要があります。そうでない場合、レプリケーション処理中にエラーが発生します。 +アップストリームクラスターにグローバル一時テーブルが含まれている場合、ダウンストリームのTiDBクラスターはv5.3.0以降のバージョンである必要があります。そうでない場合、レプリケーション処理中にエラーが発生します。 ### ベクトルデータ型との互換性 {#compatibility-with-vector-data-types} v8.4.0 以降、TiCDC は、自動 [ベクトルデータ型](/ai/reference/vector-search-data-types.md)ストリームへのテーブルの複製をサポートします (実験的)。 -ダウンストリームがKafkaまたはstorageサービス（Amazon S3、GCS、Azure Blob Storage、NFSなど）の場合、TiCDCはダウンストリームに書き込む前にベクトルデータ型を文字列型に変換します。 +ダウンストリームがKafkaまたはストレージサービス（Amazon S3、GCS、Azure Blob Storage、NFSなど）の場合、TiCDCはダウンストリームに書き込む前にベクトルデータ型を文字列型に変換します。 ダウンストリームがベクトルデータ型をサポートしないMySQL互換データベースである場合、TiCDCはベクトル型を含むDDLイベントをダウンストリームに書き込むことができません。この場合、 `has-vector-type=true`に`sink-url`パラメータを追加してください。これにより、TiCDCは書き込み前にベクトルデータ型を`LONGTEXT`型に変換できます。 diff --git a/ticdc/ticdc-csv.md b/ticdc/ticdc-csv.md index 15441d658f61c..717982fffea12 100644 --- a/ticdc/ticdc-csv.md +++ b/ticdc/ticdc-csv.md @@ -5,7 +5,7 @@ summary: TiCDC CSVプロトコルの概念と使用方法を学びましょう # TiCDC CSVプロトコル {#ticdc-csv-protocol} -クラウドstorageサービスをダウンストリームのシンクとして使用する場合、DMLイベントをCSV形式でクラウドstorageサービスに送信できます。 +クラウドストレージサービスをダウンストリームのシンクとして使用する場合、DMLイベントをCSV形式でクラウドストレージサービスに送信できます。 ## CSVを使用する {#use-csv} @@ -31,15 +31,15 @@ output-old-value = false output-field-header = false # New in v8.5.6 (only available in the TiCDC new architecture) ``` -## 取引上の制約 {#transactional-constraints} +## トランザクション上の制約 {#transactional-constraints} - 単一のCSVファイルでは、ある行の`commit-ts`は、次の行の{{B-PLACEHOLDER-E}}と同じかそれ以下です。 - 同一テーブルの同じトランザクションは、同じCSVファイルに保存されます。 - 同じトランザクションの複数のテーブルを、異なるCSVファイルに保存することができます。 -## データstorageパス構造 {#data-storage-path-structure} +## データストレージパス構造 {#data-ストレージ-path-structure} -データのstorageパス構造の詳細については、 [ストレージパス構造](/ticdc/ticdc-sink-to-cloud-storage.md#storage-path-structure)参照してください。 +データのストレージパス構造の詳細については、 [ストレージパス構造](/ticdc/ticdc-sink-to-cloud-ストレージ.md#ストレージ-path-structure)参照してください。 ## データ形式の定義 {#definition-of-the-data-format} diff --git a/ticdc/ticdc-data-replication-capabilities.md b/ticdc/ticdc-data-replication-capabilities.md index 99cd4ef4d5f94..9b838cf13709e 100644 --- a/ticdc/ticdc-data-replication-capabilities.md +++ b/ticdc/ticdc-data-replication-capabilities.md @@ -22,7 +22,7 @@ TiCDC は、次のようなさまざまな下流システムへのデータの - [TiDBデータベースまたはその他のMySQL互換データベース](/ticdc/ticdc-sink-to-mysql.md) - [アパッチカフカ](/ticdc/ticdc-sink-to-kafka.md) - [メッセージキュー（MQ）タイプのシンク](/ticdc/ticdc-changefeed-config.md#sink) 、例えば[パルサー](/ticdc/ticdc-sink-to-pulsar.md) -- [ストレージ サービス (Amazon S3、GCS、Azure Blob Storage、NFS)](/ticdc/ticdc-sink-to-cloud-storage.md) +- [ストレージ サービス (Amazon S3、GCS、Azure Blob Storage、NFS)](/ticdc/ticdc-sink-to-cloud-ストレージ.md) - [Confluent Cloud 統合による Snowflake、ksqlDB、SQL Server](/ticdc/integrate-confluent-using-ticdc.md) - [Kafka で複製されたデータを消費するための Apache Flink](/replicate-data-to-kafka.md) diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 601f2d887518d..866b643df6a8d 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -13,7 +13,7 @@ summary: TiCDC を使用する際に遭遇する可能性のある FAQ につい ## TiCDC でタスクを作成するときにstart-ts選択するにはどうすればよいですか? {#how-do-i-choose-code-start-ts-code-when-creating-a-task-in-ticdc} -レプリケーションタスクの`start-ts`は、上流TiDBクラスタ内のタイムスタンプOracle（TSO）に対応します。TiCDCは、レプリケーションタスクでこのTSOにデータを要求します。したがって、レプリケーションタスクの`start-ts` 、以下の要件を満たす必要があります。 +レプリケーションタスクの`start-ts`は、上流TiDBクラスター内のタイムスタンプOracle（TSO）に対応します。TiCDCは、レプリケーションタスクでこのTSOにデータを要求します。したがって、レプリケーションタスクの`start-ts` 、以下の要件を満たす必要があります。 - `start-ts`という値は、現在の TiDB クラスターの`tikv_gc_safe_point`という値よりも大きいです。それ以外の場合、タスクの作成時にエラーが発生します。 - タスクを開始する前に、ダウンストリームにすべてのデータが`start-ts`あることを確認してください。メッセージキューにデータを複製するなどのシナリオでは、アップストリームとダウンストリーム間のデータの整合性が要求されない場合は、アプリケーションのニーズに応じてこの要件を緩和できます。 @@ -55,7 +55,7 @@ cdc cli changefeed list --server=http://127.0.0.1:8300 ## アップストリームが更新を停止した後、TiCDC がすべての更新を複製したかどうかを確認するにはどうすればよいですか? {#how-to-verify-if-ticdc-has-replicated-all-updates-after-upstream-stops-updating} -上流TiDBクラスタの更新が停止した後、上流TiDBクラスタの最新の[TSO](/glossary.md#timestamp-oracle-tso)タイムスタンプとTiCDCのレプリケーション進行状況を比較することで、レプリケーションが完了したかどうかを確認できます。TiCDCのレプリケーション進行状況のタイムスタンプが上流TiDBクラスタのTSO以上であれば、すべての更新がレプリケートされています。レプリケーションの完了を確認するには、以下の手順を実行してください。 +上流TiDBクラスターの更新が停止した後、上流TiDBクラスターの最新の[TSO](/glossary.md#timestamp-oracle-tso)タイムスタンプとTiCDCのレプリケーション進行状況を比較することで、レプリケーションが完了したかどうかを確認できます。TiCDCのレプリケーション進行状況のタイムスタンプが上流TiDBクラスターのTSO以上であれば、すべての更新がレプリケートされています。レプリケーションの完了を確認するには、以下の手順を実行してください。 1. アップストリーム TiDB クラスターから最新の TSO タイムスタンプを取得します。 @@ -169,7 +169,7 @@ TiCDCサーバーの起動時に、GCセーフポイントのTime To Live（TTL - TiCDC サービスが停止した後、GC セーフポイントが PD に保持される最大時間。 - TiKVのGCがTiCDCのGCセーフポイントによってブロックされている場合、 `gc-ttl` TiCDCレプリケーションタスクの最大レプリケ​​ーション遅延を示します。レプリケーションタスクの遅延が`gc-ttl`で設定された値を超えると、レプリケーションタスクは`failed`状態になり、 `ErrGCTTLExceeded`エラーを報告します。この状態は回復できず、GCセーフポイントの進行をブロックしなくなります。 -上記の2番目の動作は、TiCDC v4.0.13以降のバージョンで導入されました。これは、TiCDCのレプリケーションタスクが長時間停止し、上流TiKVクラスタのGCセーフポイントが長時間継続せず、古いデータバージョンが過度に保持され、上流クラスタのパフォーマンスに影響を及ぼすのを防ぐことを目的としています。 +上記の2番目の動作は、TiCDC v4.0.13以降のバージョンで導入されました。これは、TiCDCのレプリケーションタスクが長時間停止し、上流TiKVクラスターのGCセーフポイントが長時間継続せず、古いデータバージョンが過度に保持され、上流クラスターのパフォーマンスに影響を及ぼすのを防ぐことを目的としています。 > **注記：** > @@ -193,7 +193,7 @@ TiCDC がサービス GC セーフポイントに設定するデフォルトの | | 上流タイムゾーン | TiCDCタイムゾーン | 下流タイムゾーン | | :----------: | :-------------------------------------------------------------------------: | :----------------------------------------------------------------------------------: | :------------------------------------------------------------------------------: | -| コンフィグレーション方法 | [タイムゾーンのサポート](/configure-time-zone.md)参照 | TiCDCサーバーを起動するときに`--tz`パラメータを使用して設定されます | `sink-uri`の`time-zone`パラメータを使用して設定します。このパラメータは、シンクが`mysql`または`tidb`の場合のみ有効です。 | +| 設定方法 | [タイムゾーンのサポート](/configure-time-zone.md)参照 | TiCDCサーバーを起動するときに`--tz`パラメータを使用して設定されます | `sink-uri`の`time-zone`パラメータを使用して設定します。このパラメータは、シンクが`mysql`または`tidb`の場合のみ有効です。 | | 説明 | アップストリーム TiDB のタイムゾーン。タイムスタンプ タイプの DML 操作と、タイムスタンプ タイプの列に関連する DDL 操作に影響します。 | TiCDC は、アップストリーム TiDB のタイム ゾーンが TiCDC のタイム ゾーン構成と同じであると想定し、タイムスタンプ列に対して関連する操作を実行します。 | ダウンストリーム`mysql`および`tidb`シンクは、接続セッションのタイム ゾーン設定に従って、DML および DDL 操作のタイムスタンプを処理します。 | > **注記：** @@ -290,17 +290,17 @@ TiCDC オープン プロトコルでは、タイプ コード`6`は`null`表し 詳細については[オープンプロトコル行変更イベント形式](/ticdc/ticdc-open-protocol.md#row-changed-event)を参照してください。 -## TiCDC はどのくらいの PDstorageを使用しますか? {#how-much-pd-storage-does-ticdc-use} +## TiCDC はどのくらいの PDストレージを使用しますか? {#how-much-pd-ストレージ-does-ticdc-use} TiCDC を使用するときに、 `etcdserver: mvcc: database space exceeded`エラーが発生する可能性があります。これは主に、TiCDC が PD で etcd を使用してメタデータを保存するメカニズムに関連しています。 etcdはデータの保存にマルチバージョン同時実行制御（MVCC）を使用し、PDにおけるデフォルトのコンパクション間隔は1時間です。つまり、etcdはコンパクションを行う前の1時間、すべてのデータの複数のバージョンを保持します。 -v6.0.0より前のバージョンでは、TiCDCはPD内のetcdを使用して、変更フィード内のすべてのテーブルのメタデータを保存および更新していました。そのため、TiCDCが使用するPDstorage容量は、変更フィードによって複製されるテーブルの数に比例します。TiCDCが多数のテーブルを複製する場合、etcdstorage容量がすぐにいっぱいになり、 `etcdserver: mvcc: database space exceeded`エラーが発生する可能性が高くなります。 +v6.0.0より前のバージョンでは、TiCDCはPD内のetcdを使用して、変更フィード内のすべてのテーブルのメタデータを保存および更新していました。そのため、TiCDCが使用するPDストレージ容量は、変更フィードによって複製されるテーブルの数に比例します。TiCDCが多数のテーブルを複製する場合、etcdストレージ容量がすぐにいっぱいになり、 `etcdserver: mvcc: database space exceeded`エラーが発生する可能性が高くなります。 -このエラーが発生した場合は、 [etcd メンテナンス スペース クォータ](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota)を参照して etcdstorageスペースをクリーンアップしてください。 +このエラーが発生した場合は、 [etcd メンテナンス スペース クォータ](https://etcd.io/docs/v3.4.0/op-guide/maintenance/#space-quota)を参照して etcdストレージスペースをクリーンアップしてください。 -v6.0.0以降、TiCDCはメタデータstorageメカニズムを最適化し、前述の理由によるetcdstorage容量の問題を効果的に回避します。TiCDCのバージョンがv6.0.0より前の場合は、v6.0.0以降へのアップグレードをお勧めします。 +v6.0.0以降、TiCDCはメタデータストレージメカニズムを最適化し、前述の理由によるetcdストレージ容量の問題を効果的に回避します。TiCDCのバージョンがv6.0.0より前の場合は、v6.0.0以降へのアップグレードをお勧めします。 ## TiCDC は大規模なトランザクションのレプリケーションをサポートしていますか? リスクはありますか? {#does-ticdc-support-replicating-large-transactions-is-there-any-risk} @@ -329,7 +329,7 @@ TiCDC v6.2以降、単一テーブルトランザクションを複数のトラ - 列の精度を変更する（例：DECIMAL(10, 3) -> DECIMAL(10, 2)） - 列の UNSIGNED または SIGNED 属性の変更 (例: INT UNSIGNED -> INT SIGNED) -TiDB v7.1.0より前のバージョンでは、TiCDCは新旧のデータが同一のDMLイベントを下流に複製します。下流がMySQLの場合、これらのDMLイベントは、下流がDDL文を受信して​​実行するまでデータの変更を引き起こしません。しかし、下流がKafkaまたはクラウドstorageサービスの場合、TiCDCは冗長データの行を下流に書き込みます。 +TiDB v7.1.0より前のバージョンでは、TiCDCは新旧のデータが同一のDMLイベントを下流に複製します。下流がMySQLの場合、これらのDMLイベントは、下流がDDL文を受信して​​実行するまでデータの変更を引き起こしません。しかし、下流がKafkaまたはクラウドストレージサービスの場合、TiCDCは冗長データの行を下流に書き込みます。 TiDB v7.1.0 以降、TiCDC はこれらの冗長な DML イベントを削除し、ダウンストリームに複製しなくなりました。 @@ -403,7 +403,7 @@ BR はバージョンに応じて互換性を異なる方法で処理します ## 異なるリージョンにある 2 つの TiDB クラスター間でデータをレプリケートするには、TiCDC をどのようにデプロイすればよいですか? {#how-should-i-deploy-ticdc-to-replicate-data-between-two-tidb-cluster-located-in-different-regions} -TiCDC v6.5.2より前のバージョンでは、TiCDCをダウンストリームTiDBクラスタにデプロイすることをお勧めします。アップストリームとダウンストリーム間のネットワークレイテンシーが大きい場合（例えば100ミリ秒を超える場合）、MySQL転送プロトコルの問題により、TiCDCがダウンストリームにSQL文を実行する際のレイテンシーが大幅に増加する可能性があります。その結果、システムスループットが低下します。しかし、ダウンストリームにTiCDCをデプロイすることで、この問題を大幅に軽減できます。最適化後、TiCDC v6.5.2以降では、TiCDCをアップストリームTiDBクラスタにデプロイすることをお勧めします。 +TiCDC v6.5.2より前のバージョンでは、TiCDCをダウンストリームTiDBクラスターにデプロイすることをお勧めします。アップストリームとダウンストリーム間のネットワークレイテンシーが大きい場合（例えば100ミリ秒を超える場合）、MySQL転送プロトコルの問題により、TiCDCがダウンストリームにSQL文を実行する際のレイテンシーが大幅に増加する可能性があります。その結果、システムスループットが低下します。しかし、ダウンストリームにTiCDCをデプロイすることで、この問題を大幅に軽減できます。最適化後、TiCDC v6.5.2以降では、TiCDCをアップストリームTiDBクラスターにデプロイすることをお勧めします。 ## DML および DDL ステートメントの実行順序は何ですか? {#what-is-the-order-of-executing-dml-and-ddl-statements} @@ -432,7 +432,7 @@ TiDBにはトランザクションタイムアウト機構があります。ト ## TiDB Operatorによってデプロイされた TiCDC クラスターをcdc cliコマンドを使用して操作できないのはなぜですか? {#why-can-t-i-use-the-code-cdc-cli-code-command-to-operate-a-ticdc-cluster-deployed-by-tidb-operator} -これは、 TiDB OperatorによってデプロイされたTiCDCクラスタのデフォルトポート番号が`8301`あるのに対し、TiCDCサーバーに接続するための`cdc cli`コマンドのデフォルトポート番号が`8300`であるためです。TiDB OperatorによってデプロイされたTiCDCクラスタを`cdc cli`コマンドで操作する場合は、以下のように`--server`パラメータを明示的に指定する必要があります。 +これは、 TiDB OperatorによってデプロイされたTiCDCクラスターのデフォルトポート番号が`8301`あるのに対し、TiCDCサーバーに接続するための`cdc cli`コマンドのデフォルトポート番号が`8300`であるためです。TiDB OperatorによってデプロイされたTiCDCクラスターを`cdc cli`コマンドで操作する場合は、以下のように`--server`パラメータを明示的に指定する必要があります。 ```shell ./cdc cli changefeed list --server "127.0.0.1:8301" @@ -462,11 +462,11 @@ TiDBにはトランザクションタイムアウト機構があります。ト ## TiCDC は DML 操作で生成された列を複製しますか? {#does-ticdc-replicate-generated-columns-of-dml-operations} -生成列には、仮想生成列と保存生成列が含まれます。TiCDCは仮想生成列を無視し、保存生成列のみを下流に複製します。ただし、下流がMySQLまたは他のMySQL互換データベース（Kafkaなどのstorageサービスではない）である場合、保存生成列も無視されます。 +生成列には、仮想生成列と保存生成列が含まれます。TiCDCは仮想生成列を無視し、保存生成列のみを下流に複製します。ただし、下流がMySQLまたは他のMySQL互換データベース（Kafkaなどのストレージサービスではない）である場合、保存生成列も無視されます。 > **注記：** > -> 保存された生成列をKafkaまたはstorageサービスにレプリケーションし、その後MySQLに書き戻すと、 `Error 3105 (HY000): The value specified for generated column 'xx' in table 'xxx' is not allowed`発生する可能性があります。このエラーを回避するには、レプリケーションに[オープンプロトコル](/ticdc/ticdc-open-protocol.md#ticdc-open-protocol)使用します。このプロトコルの出力には[列のビットフラグ](/ticdc/ticdc-open-protocol.md#bit-flags-of-columns)含まれており、列が生成列かどうかを区別できます。 +> 保存された生成列をKafkaまたはストレージサービスにレプリケーションし、その後MySQLに書き戻すと、 `Error 3105 (HY000): The value specified for generated column 'xx' in table 'xxx' is not allowed`発生する可能性があります。このエラーを回避するには、レプリケーションに[オープンプロトコル](/ticdc/ticdc-open-protocol.md#ticdc-open-protocol)使用します。このプロトコルの出力には[列のビットフラグ](/ticdc/ticdc-open-protocol.md#bit-flags-of-columns)含まれており、列が生成列かどうかを区別できます。 ## 頻繁に発生するCDC:ErrMySQLDuplicateEntryCDCエラーを解決するにはどうすればよいですか? {#how-do-i-resolve-frequent-code-cdc-errmysqlduplicateentrycdc-code-errors} diff --git a/ticdc/ticdc-manage-changefeed.md b/ticdc/ticdc-manage-changefeed.md index b77b476813f82..adba05c275408 100644 --- a/ticdc/ticdc-manage-changefeed.md +++ b/ticdc/ticdc-manage-changefeed.md @@ -18,7 +18,7 @@ cdc cli changefeed create --server=http://10.0.10.25:8300 --sink-uri="mysql://ro ```shell Create changefeed successfully! ID: simple-replication-task -Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-replication-task","sink_uri":"mysql://root:xxxxx@127.0.0.1:4000/?time-zone=","create_time":"2025-08-14T15:05:46.679218+08:00","start_ts":438156275634929669,"engine":"unified","config":{"case_sensitive":false,"force_replicate":false,"ignore_ineligible_table":false,"check_gc_safe_point":true,"enable_sync_point":true,"bdr_mode":false,"sync_point_interval":30000000000,"sync_point_retention":3600000000000,"filter":{"rules":["test.*"],"event_filters":null},"mounter":{"worker_num":16},"sink":{"protocol":"","schema_registry":"","csv":{"delimiter":",","quote":"\"","null":"\\N","include_commit_ts":false},"column_selectors":null,"transaction_atomicity":"none","encoder_concurrency":16,"terminator":"\r\n","date_separator":"none","enable_partition_separator":false},"consistent":{"level":"none","max_log_size":64,"flush_interval":2000,"storage":""}},"state":"normal","creator_version":"v8.5.3"} +Info: {"upstream_id":7178706266519722477,"namespace":"default","id":"simple-replication-task","sink_uri":"mysql://root:xxxxx@127.0.0.1:4000/?time-zone=","create_time":"2025-08-14T15:05:46.679218+08:00","start_ts":438156275634929669,"engine":"unified","config":{"case_sensitive":false,"force_replicate":false,"ignore_ineligible_table":false,"check_gc_safe_point":true,"enable_sync_point":true,"bdr_mode":false,"sync_point_interval":30000000000,"sync_point_retention":3600000000000,"filter":{"rules":["test.*"],"event_filters":null},"mounter":{"worker_num":16},"sink":{"protocol":"","schema_registry":"","csv":{"delimiter":",","quote":"\"","null":"\\N","include_commit_ts":false},"column_selectors":null,"transaction_atomicity":"none","encoder_concurrency":16,"terminator":"\r\n","date_separator":"none","enable_partition_separator":false},"consistent":{"level":"none","max_log_size":64,"flush_interval":2000,"ストレージ":""}},"state":"normal","creator_version":"v8.5.3"} ``` ## レプリケーションタスクリストをクエリする {#query-the-replication-task-list} @@ -293,5 +293,5 @@ cdc cli --server="http://10.0.10.25:8300" changefeed query --changefeed-id=simpl > **注記：** > -> - サーバーで、レイテンシーが長く、帯域幅が制限されている機械式ハード ドライブやその他のstorageデバイスが使用されている場合、Unified Sorter のパフォーマンスは大幅に低下します。 +> - サーバーで、レイテンシーが長く、帯域幅が制限されている機械式ハード ドライブやその他のストレージデバイスが使用されている場合、Unified Sorter のパフォーマンスは大幅に低下します。 > - デフォルトでは、Unified Sorter は一時ファイルの保存に`data_dir`使用します。空きディスク容量が 500 GiB 以上であることを確認することをお勧めします。本番環境では、各ノードの空きディスク容量が（業務で許容される最大遅延時間`checkpoint-ts` ）×（業務ピーク時のアップストリーム書き込みトラフィック）よりも大きいことを確認することをお勧めします。また、 `changefeed`作成した後に大量の履歴データを複製する予定がある場合は、各ノードの空き容量が複製データの量よりも大きいことを確認してください。 diff --git a/ticdc/ticdc-open-api-v2.md b/ticdc/ticdc-open-api-v2.md index 8544c16ca0e56..fa0e405d3aacf 100644 --- a/ticdc/ticdc-open-api-v2.md +++ b/ticdc/ticdc-open-api-v2.md @@ -153,7 +153,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health "flush_interval": 0, "level": "string", "max_log_size": 0, - "storage": "string" + "ストレージ": "string" }, "enable_sync_point": true, "filter": { @@ -235,7 +235,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | パラメータ名 | 説明 | | :--------------- | :----------------------------------------------------------------------------------------------------- | | `changefeed_id` | `STRING`型。レプリケーションタスクのID。（オプション） | -| `replica_config` | レプリケーションタスクのコンフィグレーションパラメータ。(オプション) | +| `replica_config` | レプリケーションタスクの設定パラメータ。(オプション) | | **`sink_uri`** | `STRING`型。レプリケーションタスクのダウンストリームアドレス。（**必須**） | | `start_ts` | `UINT64`型。変更フィードの開始TSOを指定します。TiCDCクラスターは、このTSOからデータのプルを開始します。デフォルト値は現在時刻です。（オプション） | | `target_ts` | `UINT64`型。変更フィードのターゲットTSOを指定します。TiCDCクラスターは、このTSOに到達するとデータのプルを停止します。デフォルト値は空で、TiCDCは自動的に停止しません。(オプション) | @@ -267,7 +267,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | `flush_interval` | `UINT64`型。REDOログファイルをフラッシュする間隔。（オプション） | | `level` | `STRING`型。複製されたデータの一貫性レベル。（オプション） | | `max_log_size` | `UINT64`型。REDOログの最大値。（オプション） | -| `storage` | `STRING`型。storageの宛先アドレス。（オプション） | +| `ストレージ` | `STRING`型。ストレージの宛先アドレス。（オプション） | | `use_file_backend` | `BOOL`タイプ。REDOログをローカルファイルに保存するかどうかを指定します。（オプション） | | `encoding_worker_num` | `INT`型。REDOモジュール内のエンコードおよびデコードワーカーの数。（オプション） | | `flush_worker_num` | `INT`型。REDOモジュール内のフラッシュワーカーの数。（オプション） | @@ -314,7 +314,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | `terminator` | `STRING`型。ターミネータは、2つのデータ変更イベントを区切るために使用されます。デフォルト値はnullで、 `"\r\n"`ターミネータとして使用されます。（オプション） | | `transaction_atomicity` | `STRING`型。トランザクションのアトミック性レベル。（オプション） | | `only_output_updated_columns` | `BOOLEAN`型。2 または`canal-json`プロトコル`open-protocol`使用するMQシンクの場合、変更された列のみを出力するかどうかを指定できます。デフォルト値は`false`です。（オプション） | -| `cloud_storage_config` | storageシンクの構成。(オプション) | +| `cloud_ストレージ_config` | ストレージシンクの構成。(オプション) | | `open` | オープンプロトコルの構成。(オプション) | | `debezium` | Debezium プロトコルの設定。(オプション) | @@ -350,13 +350,13 @@ curl -X GET http://127.0.0.1:8300/api/v2/health | `partition` | `STRING`タイプ。イベントをディスパッチするターゲット パーティション。 | | `topic` | `STRING`型。イベントをディスパッチするターゲットトピック。 | -`sink.cloud_storage_config`パラメータは次のように記述されます。 +`sink.cloud_ストレージ_config`パラメータは次のように記述されます。 | パラメータ名 | 説明 | | :------------------------ | :---------------------------------------------------------------------------------------------------------------------------------------------- | -| `worker_count` | `INT`型。下流のクラウドストレージへのデータstorageの同時実行性が変更されます。 | -| `flush_interval` | `STRING`型。下流のクラウドstorageへのデータ保存間隔が変更されます。 | -| `file_size` | `INT`型。このファイル内のバイト数がこのパラメータの値を超えると、データ変更ファイルがクラウドstorageに保存されます。 | +| `worker_count` | `INT`型。下流のクラウドストレージへのデータストレージの同時実行性が変更されます。 | +| `flush_interval` | `STRING`型。下流のクラウドストレージへのデータ保存間隔が変更されます。 | +| `file_size` | `INT`型。このファイル内のバイト数がこのパラメータの値を超えると、データ変更ファイルがクラウドストレージに保存されます。 | | `file_expiration_days` | `INT`タイプ。ファイルを保持する期間。2 `date-separator` `day`に設定されている場合にのみ有効になります。 | | `file_cleanup_cron_spec` | `STRING`型。crontab 設定と互換性のある、スケジュールされたクリーンアップタスクの実行サイクル。形式は` `です。 | | `flush_concurrency` | `INT`型。単一ファイルのアップロードの同時実行性。 | @@ -399,7 +399,7 @@ curl -X POST -H "Content-type: application/json" http://127.0.0.1:8300/api/v2/ch "flush_interval": 0, "level": "string", "max_log_size": 0, - "storage": "string" + "ストレージ": "string" }, "enable_sync_point": true, "filter": { @@ -584,7 +584,7 @@ changefeed 設定を変更するには、 `pause the replication task -> modify "flush_interval": 0, "level": "string", "max_log_size": 0, - "storage": "string" + "ストレージ": "string" }, "enable_sync_point": true, "filter": { @@ -838,7 +838,7 @@ curl -X GET http://127.0.0.1:8300/api/v2/changefeeds/test1/synced } ``` -このAPIを使用すると、上流クラスタで災害が発生した場合でも同期ステータスを照会できます。状況によっては、TiCDCの現在のデータレプリケーションタスクが完了しているかどうかを直接確認できない場合があります。そのような場合は、このAPIをリクエストし、レスポンスの`info`フィールドと上流クラスタの現在のステータスの両方を確認することで、具体的なステータスを確認できます。 +このAPIを使用すると、上流クラスターで災害が発生した場合でも同期ステータスを照会できます。状況によっては、TiCDCの現在のデータレプリケーションタスクが完了しているかどうかを直接確認できない場合があります。そのような場合は、このAPIをリクエストし、レスポンスの`info`フィールドと上流クラスターの現在のステータスの両方を確認することで、具体的なステータスを確認できます。 この例では、 `sink_checkpoint_ts` `now_ts`より遅れていますが、これは TiCDC がまだデータレプリケーションに追いついていないか、PD または TiKV に障害が発生しているためです。TiCDC がまだデータレプリケーションに追いついていない場合は、レプリケーションタスクがまだ完了していないことを意味します。PD または TiKV に障害が発生した場合は、レプリケーションタスクが完了していることを意味します。したがって、クラスターのステータスを確認するには、 `info`フィールドを確認する必要があります。 diff --git a/ticdc/ticdc-overview.md b/ticdc/ticdc-overview.md index 69308cf6a3bf5..dbe41ea605816 100644 --- a/ticdc/ticdc-overview.md +++ b/ticdc/ticdc-overview.md @@ -11,7 +11,7 @@ summary: TiCDCとは何か、TiCDCが提供する機能、そしてTiCDCのイ TiCDCには、以下のような複数の使用シナリオがあります。 -- 複数のTiDBクラスタ向けに、高可用性とディザスタリカバリソリューションを提供します。TiCDCは、災害発生時にプライマリクラスタとセカンダリクラスタ間のデータ整合性を確保します。 +- 複数のTiDBクラスター向けに、高可用性とディザスタリカバリソリューションを提供します。TiCDCは、災害発生時にプライマリクラスターとセカンダリクラスター間のデータ整合性を確保します。 - リアルタイムのデータ変更を同種システムに複製します。これにより、監視、キャッシング、グローバルインデックス作成、データ分析、異種データベース間のプライマリ/セカンダリ複製など、さまざまなシナリオに対応するデータソースが提供されます。 ## 主な特徴 {#major-features} @@ -20,19 +20,19 @@ TiCDCには、以下のような複数の使用シナリオがあります。 TiCDCには、以下の主要な機能があります。 -- 秒単位のRPOと分単位のRTOで、TiDBクラスタ間で増分データを複製します。 -- TiDBクラスタ間の双方向レプリケーションにより、TiCDCを使用してマルチアクティブTiDBソリューションを構築できます。 -- TiDBクラスタからMySQLデータベースまたはその他のMySQL互換データベースへ、低レイテンシーで増分データを複製します。 +- 秒単位のRPOと分単位のRTOで、TiDBクラスター間で増分データを複製します。 +- TiDBクラスター間の双方向レプリケーションにより、TiCDCを使用してマルチアクティブTiDBソリューションを構築できます。 +- TiDBクラスターからMySQLデータベースまたはその他のMySQL互換データベースへ、低レイテンシーで増分データを複製します。 - TiDB クラスターから Kafka クラスターへの増分データのレプリケーション。推奨されるデータ形式には、 [Canal-JSON](/ticdc/ticdc-canal-json.md) 、[アヴロ](/ticdc/ticdc-avro-protocol.md)、[デベジウム](/ticdc/ticdc-debezium.md)が含まれます。 -- TiDBクラスタからAmazon S3、GCS、Azure Blob Storage、NFSなどのstorageサービスへ増分データを複製する。 +- TiDBクラスターからAmazon S3、GCS、Azure Blob Storage、NFSなどのストレージサービスへ増分データを複製する。 - データベース、テーブル、DML、DDLをフィルタリングする機能を備えたテーブルの複製。 - 単一障害点のない高可用性を実現し、TiCDCノードの動的な追加と削除をサポートします。 -- [オープンAPI](/ticdc/ticdc-open-api-v2.md)を介したクラスタ管理。タスクの状態照会、タスク構成の動的な変更、タスクの作成または削除などが含まれます。 +- [オープンAPI](/ticdc/ticdc-open-api-v2.md)を介したクラスター管理。タスクの状態照会、タスク構成の動的な変更、タスクの作成または削除などが含まれます。 ### 複製順序 {#replication-order} - TiCDCは、すべてのDDLまたはDMLステートメントを**少なくとも1回**出力します。 -- TiKVまたはTiCDCクラスタで障害が発生した場合、TiCDCは同じDDL/DMLステートメントを繰り返し送信する可能性があります。重複したDDL/DMLステートメントについては、以下を参照してください。 +- TiKVまたはTiCDCクラスターで障害が発生した場合、TiCDCは同じDDL/DMLステートメントを繰り返し送信する可能性があります。重複したDDL/DMLステートメントについては、以下を参照してください。 - MySQLシンクはDDLステートメントを繰り返し実行できます。 `TRUNCATE TABLE`のようにダウンストリームで繰り返し実行できるDDLステートメントは正常に実行されます。 `CREATE TABLE`のように繰り返し実行できないステートメントは実行に失敗し、TiCDCはエラーを無視してレプリケーション処理を続行します。 - Kafkaシンクは、データ配信のためのさまざまな戦略を提供します。 @@ -68,13 +68,13 @@ TiCDCのアーキテクチャを次の図に示す。 アーキテクチャ図における各構成要素は、以下のように説明されます。 -- TiKVサーバー：TiDBクラスタ内のTiKVノード。データに変更が発生すると、TiKVノードは変更ログ（KV変更ログ）として変更内容をTiCDCノードに送信します。TiCDCノードは、変更ログが連続していないことを検出した場合、TiKVノードに変更ログの提供を積極的に要求します。 +- TiKVサーバー：TiDBクラスター内のTiKVノード。データに変更が発生すると、TiKVノードは変更ログ（KV変更ログ）として変更内容をTiCDCノードに送信します。TiCDCノードは、変更ログが連続していないことを検出した場合、TiKVノードに変更ログの提供を積極的に要求します。 - TiCDC: TiCDCプロセスが実行されるTiCDCノード。各ノードではTiCDCプロセスが実行されます。各プロセスは、TiKVノード内の1つ以上のテーブルからデータ変更を取得し、シンクコンポーネントを介して下流システムにその変更を複製します。 -- PD：TiDBクラスタのスケジューリングモジュール。このモジュールはクラスタデータのスケジューリングを担当し、通常は3つのPDノードで構成されます。PDはetcdクラスタを介して高可用性を提供します。etcdクラスタでは、TiCDCはノードの状態情報や変更フィードの設定などのメタデータを保存します。 +- PD：TiDBクラスターのスケジューリングモジュール。このモジュールはクラスターデータのスケジューリングを担当し、通常は3つのPDノードで構成されます。PDはetcdクラスターを介して高可用性を提供します。etcdクラスターでは、TiCDCはノードの状態情報や変更フィードの設定などのメタデータを保存します。 実装では、TiCDC の[新しいアーキテクチャ](/ticdc/ticdc-architecture.md)と[古典アーキテクチャ](/ticdc/ticdc-classic-architecture.md)両方が、同じ増分データ レプリケーション モデルに基づいて構築されます。クラシックアーキテクチャと比較して、新しいアーキテクチャはタスク スケジューリングとレプリケーション メカニズムをリファクタリングして最適化し、リソース コストを削減しながら、リアルタイム データ レプリケーションのパフォーマンス、スケーラビリティ、安定性を大幅に向上させます。 -アーキテクチャ図に示すように、TiCDCはTiDB、MySQL、Kafka、およびstorageサービスへのデータ複製をサポートしています。 +アーキテクチャ図に示すように、TiCDCはTiDB、MySQL、Kafka、およびストレージサービスへのデータ複製をサポートしています。 ## 有効なインデックス {#valid-index} @@ -89,14 +89,14 @@ TiCDCのアーキテクチャを次の図に示す。 ## ベストプラクティス {#best-practices} -- TiCDCを使用して2つのTiDBクラスタ間でデータを複製する場合、2つのクラスタ間のネットワークレイテンシーが100msを超えると、次のようになります。 +- TiCDCを使用して2つのTiDBクラスター間でデータを複製する場合、2つのクラスター間のネットワークレイテンシーが100msを超えると、次のようになります。 - - TiCDCのバージョンがv6.5.2より前の場合は、下流のTiDBクラスタが配置されているリージョン（IDC）にTiCDCをデプロイすることをお勧めします。 - - TiCDC v6.5.2以降に導入された一連の改善により、TiCDCは上流のTiDBクラスタが配置されているリージョン（IDC）にデプロイすることが推奨されます。 + - TiCDCのバージョンがv6.5.2より前の場合は、下流のTiDBクラスターが配置されているリージョン（IDC）にTiCDCをデプロイすることをお勧めします。 + - TiCDC v6.5.2以降に導入された一連の改善により、TiCDCは上流のTiDBクラスターが配置されているリージョン（IDC）にデプロイすることが推奨されます。 - TiCDC によって複製される各テーブルには、少なくとも 1 つの[有効なインデックス](#valid-index)があります。 -- TiCDC をディザスタリカバリに使用する際に最終的な整合性を確保するには、 [リドゥログ](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios)を設定し、上流で災害が発生した場合でも、リドゥログが書き込まれるstorageシステムが正常に読み取れるようにする必要があります。 +- TiCDC をディザスタリカバリに使用する際に最終的な整合性を確保するには、 [リドゥログ](/ticdc/ticdc-sink-to-mysql.md#eventually-consistent-replication-in-disaster-scenarios)を設定し、上流で災害が発生した場合でも、リドゥログが書き込まれるストレージシステムが正常に読み取れるようにする必要があります。 ## データ処理変更の実装 {#implementation-of-processing-data-changes} @@ -161,7 +161,7 @@ WHERE `A` = 1 OR `A` = 2; - TiDB の[`CREATE SEQUENCE` DDL操作](/sql-statements/sql-statement-create-sequence.md)と[`SEQUENCE`関数](/sql-statements/sql-statement-create-sequence.md#sequence-function)上流の TiDB が`SEQUENCE`を使用している場合、TiCDC は上流で実行された`SEQUENCE` DDL 操作/関数を無視します。ただし、 `SEQUENCE`関数を使用した DML 操作は正しく複製できます。 - 現在、TiCDC によってレプリケートされているテーブルおよびデータベースへの[TiDB Lightning物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)を使用したデータのインポートはサポートされていません。詳細については、 [TiDB Lightningの物理インポートモードとTiCDCの互換性に関する制限事項は何ですか？](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-tidb-lightning-physical-import-mode-and-ticdc)参照してください。 - v8.2.0 より前では、 BR はTiCDC レプリケーション タスクを使用するクラスター[データの復元](/br/backup-and-restore-overview.md)サポートしていません。詳細については、 [BR （バックアップ＆リストア）とTiCDCの互換性に関する制限事項は何ですか？](/ticdc/ticdc-faq.md#what-are-the-compatibility-limitations-between-br-and-ticdc)参照してください。 -- バージョン8.2.0以降、 BRはTiCDCのデータ復元に関する制限を緩和しました。復元対象データの`BackupTS` （バックアップ時刻）がchangefeed [`CheckpointTS`](/ticdc/ticdc-classic-architecture.md#checkpointts) （現在のレプリケーションの進行状況を示すタイムスタンプ）よりも前であれば、 BRは正常にデータ復元を進めることができます。 `BackupTS`は通常かなり前であることを考慮すると、ほとんどのシナリオにおいて、 BRはTiCDCレプリケーションタスクを持つクラスタのデータ復元をサポートしていると考えられます。 +- バージョン8.2.0以降、 BRはTiCDCのデータ復元に関する制限を緩和しました。復元対象データの`BackupTS` （バックアップ時刻）がchangefeed [`CheckpointTS`](/ticdc/ticdc-classic-architecture.md#checkpointts) （現在のレプリケーションの進行状況を示すタイムスタンプ）よりも前であれば、 BRは正常にデータ復元を進めることができます。 `BackupTS`は通常かなり前であることを考慮すると、ほとんどのシナリオにおいて、 BRはTiCDCレプリケーションタスクを持つクラスターのデータ復元をサポートしていると考えられます。 TiCDCは、アップストリームにおける大規模トランザクションを含むシナリオを部分的にのみサポートしています。詳細については、 [TiCDCに関するFAQ](/ticdc/ticdc-faq.md#does-ticdc-support-replicating-large-transactions-is-there-any-risk)を参照してください。FAQでは、TiCDCが大規模トランザクションのレプリケーションをサポートしているかどうか、および関連するリスクについて詳しく説明されています。 diff --git a/ticdc/ticdc-server-config.md b/ticdc/ticdc-server-config.md index e645fd944e489..6d0543f11d923 100644 --- a/ticdc/ticdc-server-config.md +++ b/ticdc/ticdc-server-config.md @@ -115,13 +115,13 @@ summary: TiCDC で使用される CLI と構成パラメータについて学習 ### owner-flush-interval {#code-owner-flush-interval-code} -- TiCDCクラスタ内のオーナーモジュールがレプリケーションの進行状況をプッシュしようとする間隔を指定します。このパラメータはオプションで、デフォルト値は`50000000`ナノ秒（つまり50ミリ秒）です。 +- TiCDCクラスター内のオーナーモジュールがレプリケーションの進行状況をプッシュしようとする間隔を指定します。このパラメータはオプションで、デフォルト値は`50000000`ナノ秒（つまり50ミリ秒）です。 - このパラメータは、数値のみを指定する（たとえば、 `40000000`に設定すると 40000000 ナノ秒、つまり 40 ミリ秒を表します）、または数値と単位の両方を指定する（たとえば、直接`40ms`に設定する）という 2 つの方法で設定できます。 - デフォルト値: `50000000` 、つまり50ミリ秒 ### processor-flush-interval {#code-processor-flush-interval-code} -- TiCDCクラスタ内のプロセッサモジュールがレプリケーションの進行状況をプッシュしようとする間隔を指定します。このパラメータはオプションで、デフォルト値は`50000000`ナノ秒（つまり50ミリ秒）です。 +- TiCDCクラスター内のプロセッサモジュールがレプリケーションの進行状況をプッシュしようとする間隔を指定します。このパラメータはオプションで、デフォルト値は`50000000`ナノ秒（つまり50ミリ秒）です。 - このパラメータの設定方法は`owner-flush-interval`と同様です。 - デフォルト値: `50000000` 、つまり50ミリ秒 diff --git a/ticdc/ticdc-sink-to-cloud-storage.md b/ticdc/ticdc-sink-to-cloud-storage.md index 5d07a1cf0fb5c..923ce74bbe08c 100644 --- a/ticdc/ticdc-sink-to-cloud-storage.md +++ b/ticdc/ticdc-sink-to-cloud-storage.md @@ -1,30 +1,30 @@ --- title: Replicate Data to Storage Services -summary: TiCDC を使用してデータをstorageサービスに複製する方法と、複製されたデータのstorageパスについて学習します。 +summary: TiCDC を使用してデータをストレージサービスに複製する方法と、複製されたデータのストレージパスについて学習します。 --- -# ストレージサービスへのデータの複製 {#replicate-data-to-storage-services} +# ストレージサービスへのデータの複製 {#replicate-data-to-ストレージ-services} -TiDB v6.5.0以降、TiCDCはAmazon S3、GCS、Azure Blob Storage、NFSなどのstorageサービスへの行変更イベントの保存をサポートします。本ドキュメントでは、TiCDCを使用してこれらのstorageサービスに増分データをレプリケートするチェンジフィードの作成方法と、データの保存方法について説明します。本ドキュメントの構成は以下のとおりです。 +TiDB v6.5.0以降、TiCDCはAmazon S3、GCS、Azure Blob Storage、NFSなどのストレージサービスへの行変更イベントの保存をサポートします。本ドキュメントでは、TiCDCを使用してこれらのストレージサービスに増分データをレプリケートするチェンジフィードの作成方法と、データの保存方法について説明します。本ドキュメントの構成は以下のとおりです。 -- [storageサービスにデータを複製する方法](#replicate-change-data-to-storage-services) 。 -- [storageサービスにデータを保存する方法](#storage-path-structure) 。 +- [ストレージサービスにデータを複製する方法](#replicate-change-data-to-ストレージ-services) 。 +- [ストレージサービスにデータを保存する方法](#ストレージ-path-structure) 。 -## 変更データをstorageサービスに複製する {#replicate-change-data-to-storage-services} +## 変更データをストレージサービスに複製する {#replicate-change-data-to-ストレージ-services} 次のコマンドを実行して、changefeed タスクを作成します。 ```shell cdc cli changefeed create \ --server=http://10.0.10.25:8300 \ - --sink-uri="s3://logbucket/storage_test?protocol=canal-json" \ + --sink-uri="s3://logbucket/ストレージ_test?protocol=canal-json" \ --changefeed-id="simple-replication-task" ``` 出力は次のようになります。 ```shell -Info: {"upstream_id":7171388873935111376,"namespace":"default","id":"simple-replication-task","sink_uri":"s3://logbucket/storage_test?protocol=canal-json","create_time":"2025-08-14T18:52:05.566016967+08:00","start_ts":437706850431664129,"engine":"unified","config":{"case_sensitive":false,"force_replicate":false,"ignore_ineligible_table":false,"check_gc_safe_point":true,"enable_sync_point":false,"sync_point_interval":600000000000,"sync_point_retention":86400000000000,"filter":{"rules":["*.*"],"event_filters":null},"mounter":{"worker_num":16},"sink":{"protocol":"canal-json","schema_registry":"","csv":{"delimiter":",","quote":"\"","null":"\\N","include_commit_ts":false},"column_selectors":null,"transaction_atomicity":"none","encoder_concurrency":16,"terminator":"\r\n","date_separator":"none","enable_partition_separator":false},"consistent":{"level":"none","max_log_size":64,"flush_interval":2000,"storage":""}},"state":"normal","creator_version":"v8.5.3"} +Info: {"upstream_id":7171388873935111376,"namespace":"default","id":"simple-replication-task","sink_uri":"s3://logbucket/ストレージ_test?protocol=canal-json","create_time":"2025-08-14T18:52:05.566016967+08:00","start_ts":437706850431664129,"engine":"unified","config":{"case_sensitive":false,"force_replicate":false,"ignore_ineligible_table":false,"check_gc_safe_point":true,"enable_sync_point":false,"sync_point_interval":600000000000,"sync_point_retention":86400000000000,"filter":{"rules":["*.*"],"event_filters":null},"mounter":{"worker_num":16},"sink":{"protocol":"canal-json","schema_registry":"","csv":{"delimiter":",","quote":"\"","null":"\\N","include_commit_ts":false},"column_selectors":null,"transaction_atomicity":"none","encoder_concurrency":16,"terminator":"\r\n","date_separator":"none","enable_partition_separator":false},"consistent":{"level":"none","max_log_size":64,"flush_interval":2000,"ストレージ":""}},"state":"normal","creator_version":"v8.5.3"} ``` - `--server` : TiCDC クラスター内の任意の TiCDCサーバーのアドレス。 @@ -36,7 +36,7 @@ Info: {"upstream_id":7171388873935111376,"namespace":"default","id":"simple-repl ## シンクURIを構成する {#configure-sink-uri} -このセクションでは、Amazon S3、GCS、Azure Blob Storage、NFSなどのstorageサービスのシンクURIを設定する方法について説明します。シンクURIは、TiCDCターゲットシステムの接続情報を指定するために使用されます。形式は次のとおりです。 +このセクションでは、Amazon S3、GCS、Azure Blob Storage、NFSなどのストレージサービスのシンクURIを設定する方法について説明します。シンクURIは、TiCDCターゲットシステムの接続情報を指定するために使用されます。形式は次のとおりです。 ```shell [scheme]://[host]/[path]?[query_parameters] @@ -46,9 +46,9 @@ URI の`[query_parameters]`には、次のパラメータを設定できます | パラメータ | 説明 | デフォルト値 | 値の範囲 | | :---------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------- | :--------------------- | -| `worker-count` | ダウンストリームのクラウドstorageにデータの変更を保存するための同時実行性。 | `16` | `[1, 512]` | -| `flush-interval` | ダウンストリームのクラウドstorageにデータの変更を保存する間隔。 | `5s` | `[2s, 10m]` | -| `file-size` | バイト数がこのパラメータの値を超えると、データ変更ファイルはクラウドstorageに保存されます。 | `67108864` | `[1048576, 536870912]` | +| `worker-count` | ダウンストリームのクラウドストレージにデータの変更を保存するための同時実行性。 | `16` | `[1, 512]` | +| `flush-interval` | ダウンストリームのクラウドストレージにデータの変更を保存する間隔。 | `5s` | `[2s, 10m]` | +| `file-size` | バイト数がこのパラメータの値を超えると、データ変更ファイルはクラウドストレージに保存されます。 | `67108864` | `[1048576, 536870912]` | | `protocol` | ダウンストリームに送信されるメッセージのプロトコル形式。 | 該当なし | `canal-json`と`csv` | | `enable-tidb-extension` | `protocol` `canal-json`に設定され、 `enable-tidb-extension` `true`に設定されている場合、 TiCDC は[ウォーターマークイベント](/ticdc/ticdc-canal-json.md#watermark-event)送信し、 [TiDB拡張フィールド](/ticdc/ticdc-canal-json.md#tidb-extension-field) Canal-JSON メッセージに追加します。 | `false` | `false`と`true` | @@ -56,11 +56,11 @@ URI の`[query_parameters]`には、次のパラメータを設定できます > > データ変更ファイルは、 `flush-interval`または`file-size`いずれかが要件を満たしている場合に下流に保存されます。5 `protocol`パラメータは必須です。TiCDCが変更フィードの作成時にこのパラメータを受け取らない場合は、 `CDC:ErrSinkUnknownProtocol`エラーが返されます。 -### 外部storageのシンクURIを構成する {#configure-sink-uri-for-external-storage} +### 外部ストレージのシンクURIを構成する {#configure-sink-uri-for-external-ストレージ} -クラウドstorageシステムにデータを保存する場合、クラウドサービスプロバイダーに応じて異なる認証パラメータを設定する必要があります。このセクションでは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage を使用する場合の認証方法と、それぞれのストレージstorageにアクセスするためのアカウントの設定方法について説明します。 +クラウドストレージシステムにデータを保存する場合、クラウドサービスプロバイダーに応じて異なる認証パラメータを設定する必要があります。このセクションでは、Amazon S3、Google Cloud Storage（GCS）、Azure Blob Storage を使用する場合の認証方法と、それぞれのストレージストレージにアクセスするためのアカウントの設定方法について説明します。 - +
    以下は Amazon S3 の設定例です。 @@ -72,12 +72,12 @@ URI の`[query_parameters]`には、次のパラメータを設定できます データを複製する前に、Amazon S3 のディレクトリに適切なアクセス権限を設定する必要があります。 - TiCDC に必要な最小限`s3:PutObject`権限: `s3:ListBucket` 、および`s3:GetObject` 。 -- changefeed 構成項目`sink.cloud-storage-config.flush-concurrency` 1 より大きい場合、つまり単一ファイルの並列アップロードが有効になっている場合は、 [リストパーツ](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListParts.html)に関連する権限を追加する必要があります。 +- changefeed 構成項目`sink.cloud-ストレージ-config.flush-concurrency` 1 より大きい場合、つまり単一ファイルの並列アップロードが有効になっている場合は、 [リストパーツ](https://docs.aws.amazon.com/AmazonS3/latest/API/API_ListParts.html)に関連する権限を追加する必要があります。 - `s3:AbortMultipartUpload` - `s3:ListMultipartUploadParts` - `s3:ListBucketMultipartUploads` -レプリケーションデータstorageディレクトリを作成していない場合は、 [バケットを作成する](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)を参照して指定リージョンに S3 バケットを作成してください。必要に応じて、 [フォルダを使用して Amazon S3 コンソールでオブジェクトを整理する](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-folder.html)を参照してバケット内にフォルダを作成することもできます。 +レプリケーションデータストレージディレクトリを作成していない場合は、 [バケットを作成する](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)を参照して指定リージョンに S3 バケットを作成してください。必要に応じて、 [フォルダを使用して Amazon S3 コンソールでオブジェクトを整理する](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-folder.html)を参照してバケット内にフォルダを作成することもできます。 次の方法で Amazon S3 にアクセスできるようにアカウントを設定できます。 @@ -122,11 +122,11 @@ GCSへのアクセスに使用するアカウントは、アクセスキーを - 方法1: 共有アクセス署名を指定する - URIに`account-name`と`sas-token`設定した場合、このパラメーターで指定されたstorageアカウント名と共有アクセス署名トークンが使用されます。共有アクセス署名トークンには`&`文字が含まれているため、URIに追加する前に`%26`としてエンコードする必要があります。パーセントエンコードを使用して、 `sas-token`全体を直接エンコードすることもできます。 + URIに`account-name`と`sas-token`設定した場合、このパラメーターで指定されたストレージアカウント名と共有アクセス署名トークンが使用されます。共有アクセス署名トークンには`&`文字が含まれているため、URIに追加する前に`%26`としてエンコードする必要があります。パーセントエンコードを使用して、 `sas-token`全体を直接エンコードすることもできます。 - 方法2: アクセスキーを指定する - URIで`account-name`と`account-key`設定した場合、このパラメータで指定されたstorageアカウント名とキーが使用されます。URIでキーファイルを指定するだけでなく、TiCDCは環境変数`$AZURE_STORAGE_KEY`からキーを読み取ることもできます。 + URIで`account-name`と`account-key`設定した場合、このパラメータで指定されたストレージアカウント名とキーが使用されます。URIでキーファイルを指定するだけでなく、TiCDCは環境変数`$AZURE_STORAGE_KEY`からキーを読み取ることもできます。 - 方法3: Azure ADを使用してバックアップを復元する @@ -137,7 +137,7 @@ GCSへのアクセスに使用するアカウントは、アクセスキーを > **ヒント：** > -> TiCDC における Amazon S3、GCS、Azure Blob Storage の URI パラメータの詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +> TiCDC における Amazon S3、GCS、Azure Blob Storage の URI パラメータの詳細については、 [外部ストレージサービスのURI形式](/external-ストレージ-uri.md)参照してください。 ### NFSのシンクURIを構成する {#configure-sink-uri-for-nfs} @@ -147,9 +147,9 @@ GCSへのアクセスに使用するアカウントは、アクセスキーを --sink-uri="file:///my-directory/prefix?protocol=canal-json" ``` -## ストレージパス構造 {#storage-path-structure} +## ストレージパス構造 {#ストレージ-path-structure} -このセクションでは、データ変更レコード、メタデータ、および DDL イベントのstorageパス構造について説明します。 +このセクションでは、データ変更レコード、メタデータ、および DDL イベントのストレージパス構造について説明します。 ### データ変更記録 {#data-change-records} @@ -159,7 +159,7 @@ GCSへのアクセスに使用するアカウントは、アクセスキーを {scheme}://{prefix}/{schema}/{table}/{table-version-separator}/{partition-separator}/{date-separator}/CDC{num}.{extension} ``` -- `scheme` :storageタイプを指定します (例: `s3` 、 `gcs` 、 `azure` 、 `file` 。 +- `scheme` :ストレージタイプを指定します (例: `s3` 、 `gcs` 、 `azure` 、 `file` 。 - `prefix` : ユーザー定義の親ディレクトリを指定します (例: `s3:// **bucket/bbb/ccc**` 。 - `schema` : スキーマ名を指定します (例: `s3://bucket/bbb/ccc/ **test**` 。 - `table` : テーブル名を指定します (例: `s3://bucket/bbb/ccc/test/ **table1**` 。 @@ -213,7 +213,7 @@ GCSへのアクセスに使用するアカウントは、アクセスキーを } ``` -- `checkpoint-ts` : `commit-ts`が`checkpoint-ts`より小さいトランザクションは、ダウンストリームのターゲットstorageに書き込まれます。 +- `checkpoint-ts` : `commit-ts`が`checkpoint-ts`より小さいトランザクションは、ダウンストリームのターゲットストレージに書き込まれます。 ### DDLイベント {#ddl-events} @@ -271,7 +271,7 @@ GCSへのアクセスに使用するアカウントは、アクセスキーを - `Table` : テーブル名。 - `Schema` : スキーマ名。 -- `Version` :storageシンクのプロトコル バージョン。 +- `Version` :ストレージシンクのプロトコル バージョン。 - `TableVersion` : テーブルバージョン。 - `Query` : DDL ステートメント。 - `Type` : DDL タイプ。 diff --git a/ticdc/ticdc-sink-to-kafka.md b/ticdc/ticdc-sink-to-kafka.md index a2df6640f56b4..180ee8bf7a36b 100644 --- a/ticdc/ticdc-sink-to-kafka.md +++ b/ticdc/ticdc-sink-to-kafka.md @@ -29,7 +29,7 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na - `--sink-uri` : レプリケーションタスクのダウンストリームアドレス。詳細は[`kafka`でシンクURIを設定する](#configure-sink-uri-for-kafka)参照してください。 - `--start-ts` : チェンジフィードの開始TSOを指定します。このTSOから、TiCDCクラスターはデータのプルを開始します。デフォルト値は現在時刻です。 - `--target-ts` : チェンジフィードの終了TSOを指定します。このTSOまで、TiCDCクラスターはデータのプルを停止します。デフォルト値は空で、TiCDCはデータのプルを自動的に停止しません。 -- `--config` : changefeed設定ファイルを指定します。詳細は[TiCDC Changefeedコンフィグレーションパラメータ](/ticdc/ticdc-changefeed-config.md)参照してください。 +- `--config` : changefeed設定ファイルを指定します。詳細は[TiCDC Changefeed設定パラメータ](/ticdc/ticdc-changefeed-config.md)参照してください。 ## サポートされているKafkaのバージョン {#supported-kafka-versions} @@ -158,13 +158,13 @@ Info: {"sink-uri":"kafka://127.0.0.1:9092,127.0.0.1:9093,127.0.0.1:9094/topic-na TiCDC が適切に機能するために必要な最小限の権限セットは次のとおりです。 - トピック[リソースタイプ](https://docs.confluent.io/platform/current/kafka/authorization.html#resources)の`Create` 、 `Write` 、および`Describe`権限。 - - クラスタリソース タイプに対する`DescribeConfig`の権限。 + - クラスターリソース タイプに対する`DescribeConfig`の権限。 各権限の使用シナリオは次のとおりです。 | リソースタイプ | 操作の種類 | シナリオ | | :------ | :--------------- | :--------------------------- | - | クラスタ | `DescribeConfig` | 変更フィードの実行中にクラスターのメタデータを取得します | + | クラスター | `DescribeConfig` | 変更フィードの実行中にクラスターのメタデータを取得します | | トピック | `Describe` | チェンジフィードの開始時にトピックを作成しようとします | | トピック | `Create` | チェンジフィードの開始時にトピックを作成しようとします | | トピック | `Write` | トピックにデータを送信する | @@ -469,11 +469,11 @@ Kafkaコンシューマーはメッセージを受信すると、まず`onlyHand > **警告：** > -> Kafkaコンシューマーがデータを処理してTiDBにクエリを実行すると、GCによってデータが削除される可能性があります。この状況を回避するには、 [TiDBクラスタのGCライフタイムを変更する](/system-variables.md#tidb_gc_life_time-new-in-v50)より大きい値に設定する必要があります。 +> Kafkaコンシューマーがデータを処理してTiDBにクエリを実行すると、GCによってデータが削除される可能性があります。この状況を回避するには、 [TiDBクラスターのGCライフタイムを変更する](/system-variables.md#tidb_gc_life_time-new-in-v50)より大きい値に設定する必要があります。 -### 大きなメッセージを外部storageに送信する {#send-large-messages-to-external-storage} +### 大きなメッセージを外部ストレージに送信する {#send-large-messages-to-external-ストレージ} -バージョン7.4.0以降、TiCDC Kafkaシンクは、メッセージサイズが制限を超えた場合に、大きなメッセージを外部storageに送信することをサポートします。同時に、TiCDCは外部storage内の大きなメッセージのアドレスを含むメッセージをKafkaに送信します。これにより、メッセージサイズがKafkaトピックの制限を超えたことによる変更フィードの失敗を回避できます。 +バージョン7.4.0以降、TiCDC Kafkaシンクは、メッセージサイズが制限を超えた場合に、大きなメッセージを外部ストレージに送信することをサポートします。同時に、TiCDCは外部ストレージ内の大きなメッセージのアドレスを含むメッセージをKafkaに送信します。これにより、メッセージサイズがKafkaトピックの制限を超えたことによる変更フィードの失敗を回避できます。 構成例は次のとおりです。 @@ -482,22 +482,22 @@ Kafkaコンシューマーはメッセージを受信すると、まず`onlyHand # large-message-handle-option is introduced in v7.3.0. # Defaults to "none". When the message size exceeds the limit, the changefeed fails. # When set to "handle-key-only", if the message size exceeds the limit, only the handle key is sent in the data field. If the message size still exceeds the limit, the changefeed fails. -# When set to "claim-check", if the message size exceeds the limit, the message is sent to external storage. +# When set to "claim-check", if the message size exceeds the limit, the message is sent to external ストレージ. large-message-handle-option = "claim-check" -claim-check-storage-uri = "s3://claim-check-bucket" +claim-check-ストレージ-uri = "s3://claim-check-bucket" ``` -`large-message-handle-option` `"claim-check"`に設定する場合、 `claim-check-storage-uri`有効な外部storageアドレスに設定する必要があります。そうでない場合、チェンジフィードの作成は失敗します。 +`large-message-handle-option` `"claim-check"`に設定する場合、 `claim-check-ストレージ-uri`有効な外部ストレージアドレスに設定する必要があります。そうでない場合、チェンジフィードの作成は失敗します。 > **ヒント** > -> TiCDC における Amazon S3、GCS、Azure Blob Storage の URI パラメータの詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +> TiCDC における Amazon S3、GCS、Azure Blob Storage の URI パラメータの詳細については、 [外部ストレージサービスのURI形式](/external-ストレージ-uri.md)参照してください。 -TiCDCは外部storageサービス上のメッセージをクリーンアップしません。データ利用者は外部storageサービスを独自に管理する必要があります。 +TiCDCは外部ストレージサービス上のメッセージをクリーンアップしません。データ利用者は外部ストレージサービスを独自に管理する必要があります。 -### 外部storageから大きなメッセージを消費する {#consume-large-messages-from-external-storage} +### 外部ストレージから大きなメッセージを消費する {#consume-large-messages-from-external-ストレージ} -Kafkaコンシューマーは、外部storage内の大きなメッセージのアドレスを含むメッセージを受信します。メッセージの形式は次のとおりです。 +Kafkaコンシューマーは、外部ストレージ内の大きなメッセージのアドレスを含むメッセージを受信します。メッセージの形式は次のとおりです。 ```json { @@ -542,15 +542,15 @@ Kafkaコンシューマーは、外部storage内の大きなメッセージの `key`と`value`フィールドは、Kafka メッセージ内の同名のフィールドに対応しています。コンシューマーは、これらの 2 つのフィールドのデータを解析することで、元の大きなメッセージを取得できます。オープンプロトコルでエンコードされた Kafka メッセージのみが、 `key`フィールドに有効なコンテンツを含みます。TiCDC は、 `key`と`value`両方を単一の JSON オブジェクトにエンコードして、完全なメッセージを一度に配信します。他のプロトコルでは、 `key`フィールドは常に空です。 -#### valueフィールドを外部storageにのみ送信する {#send-the-code-value-code-field-to-external-storage-only} +#### valueフィールドを外部ストレージにのみ送信する {#send-the-code-value-code-field-to-external-ストレージ-only} -バージョン8.4.0以降、TiCDCはKafkaメッセージの`value`フィールドのみを外部storageに送信できるようになりました。この機能は、Open Protocol以外のシナリオにのみ適用されます。この機能は、 `claim-check-raw-value`パラメータ（デフォルトは`false`を設定することで制御できます。 +バージョン8.4.0以降、TiCDCはKafkaメッセージの`value`フィールドのみを外部ストレージに送信できるようになりました。この機能は、Open Protocol以外のシナリオにのみ適用されます。この機能は、 `claim-check-raw-value`パラメータ（デフォルトは`false`を設定することで制御できます。 > **注記：** > > オープンプロトコルを使用する場合、 `claim-check-raw-value` ～ `true`に設定するとエラーが発生します。 -`claim-check-raw-value` `true`に設定すると、チェンジフィードは Kafka メッセージの`value`フィールドを、 `key`と`value`の追加の JSON シリアル化なしで外部storageに直接送信します。これにより CPU オーバーヘッドが削減されます。さらに、コンシューマーは外部storageから直接消費可能なデータを読み取ることができるため、デシリアライゼーションのオーバーヘッドが削減されます。 +`claim-check-raw-value` `true`に設定すると、チェンジフィードは Kafka メッセージの`value`フィールドを、 `key`と`value`の追加の JSON シリアル化なしで外部ストレージに直接送信します。これにより CPU オーバーヘッドが削減されます。さらに、コンシューマーは外部ストレージから直接消費可能なデータを読み取ることができるため、デシリアライゼーションのオーバーヘッドが削減されます。 構成例は次のとおりです。 @@ -559,6 +559,6 @@ protocol = "simple" [sink.kafka-config.large-message-handle] large-message-handle-option = "claim-check" -claim-check-storage-uri = "s3://claim-check-bucket" +claim-check-ストレージ-uri = "s3://claim-check-bucket" claim-check-raw-value = true ``` diff --git a/ticdc/ticdc-sink-to-mysql.md b/ticdc/ticdc-sink-to-mysql.md index 9f033997e63d8..e86586ac86fd8 100644 --- a/ticdc/ticdc-sink-to-mysql.md +++ b/ticdc/ticdc-sink-to-mysql.md @@ -24,12 +24,12 @@ ID: simple-replication-task Info: {"sink-uri":"mysql://root:123456@127.0.0.1:3306/","opts":{},"create-time":"2023-11-28T22:04:08.103600025+08:00","start-ts":415241823337054209,"target-ts":0,"admin-job-type":0,"sort-engine":"unified","sort-dir":".","config":{"case-sensitive":false,"filter":{"rules":["*.*"],"ignore-txn-start-ts":null,"ddl-allow-list":null},"mounter":{"worker-num":16},"sink":{"dispatchers":null},"scheduler":{"type":"table-number","polling-time":-1}},"state":"normal","history":null,"error":null} ``` -- `--server` : TiCDCクラスタ内の任意のTiCDCサーバーのアドレス。 +- `--server` : TiCDCクラスター内の任意のTiCDCサーバーのアドレス。 - `--changefeed-id` : レプリケーションタスクのID。形式は`^[a-zA-Z0-9]+(\-[a-zA-Z0-9]+)*$`正規表現に一致する必要があります。このIDが指定されていない場合、TiCDCは自動的にUUID（バージョン4形式）をIDとして生成します。 - `--sink-uri` : レプリケーション タスクのダウンストリーム アドレス。詳細については、[シンクURIを`mysql` / `tidb`で設定します](#configure-sink-uri-for-mysql-or-tidb)参照してください。 -- `--start-ts` : 変更フィードの開始TSOを指定します。TiCDCクラスタはこのTSOからデータの取得を開始します。デフォルト値は現在時刻です。 -- `--target-ts` : 変更フィードの終了TSOを指定します。このTSOに達すると、TiCDCクラスタはデータのプルを停止します。デフォルト値は空で、これはTiCDCが自動的にデータのプルを停止しないことを意味します。 -- `--config` : チェンジフィード構成ファイルを指定します。詳細については、 [TiCDC Changefeedコンフィグレーションパラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。 +- `--start-ts` : 変更フィードの開始TSOを指定します。TiCDCクラスターはこのTSOからデータの取得を開始します。デフォルト値は現在時刻です。 +- `--target-ts` : 変更フィードの終了TSOを指定します。このTSOに達すると、TiCDCクラスターはデータのプルを停止します。デフォルト値は空で、これはTiCDCが自動的にデータのプルを停止しないことを意味します。 +- `--config` : チェンジフィード構成ファイルを指定します。詳細については、 [TiCDC Changefeed設定パラメータ](/ticdc/ticdc-changefeed-config.md)を参照してください。 > **注記：** > @@ -127,25 +127,25 @@ TiDBまたはその他のMySQL互換データベースにデータを複製す ## 最終的には災害シナリオにおける一貫した再現 {#eventually-consistent-replication-in-disaster-scenarios} -TiCDC の最終整合性レプリケーション機能は、リドゥ ログを使用して、アップストリームで障害が発生した場合でもデータの一貫性を確保します。この機能は、バージョン 6.1.1 から一般提供 (GA) となります。バージョン 5.3.0 から、TiCDC は、アップストリーム TiDB クラスタからダウンストリーム クラスタのオブジェクトstorageまたは NFS への増分データのバックアップをサポートします。アップストリーム クラスタで障害が発生して利用できなくなった場合、TiCDC はダウンストリーム データを最新の最終整合性状態に復元できます。この機能により、アプリケーションをダウンストリーム クラスタに迅速に切り替えることができ、長時間のダウンタイムを回避し、サービスの継続性を向上させることができます。 +TiCDC の最終整合性レプリケーション機能は、リドゥ ログを使用して、アップストリームで障害が発生した場合でもデータの一貫性を確保します。この機能は、バージョン 6.1.1 から一般提供 (GA) となります。バージョン 5.3.0 から、TiCDC は、アップストリーム TiDB クラスターからダウンストリーム クラスターのオブジェクトストレージまたは NFS への増分データのバックアップをサポートします。アップストリーム クラスターで障害が発生して利用できなくなった場合、TiCDC はダウンストリーム データを最新の最終整合性状態に復元できます。この機能により、アプリケーションをダウンストリーム クラスターに迅速に切り替えることができ、長時間のダウンタイムを回避し、サービスの継続性を向上させることができます。 -現在、TiCDCは、TiDBクラスタから別のTiDBクラスタまたはMySQL互換データベースシステム（ Aurora、MySQL、MariaDBを含む）へ増分データを複製できます。上流クラスタがクラッシュした場合、TiCDCがクラッシュ前に正常にデータを複製し、複製遅延が小さいという条件を満たせば、TiCDCは下流クラスタで5分以内にデータを復元できます。データ損失は最大10秒まで許容され、RTOは5分以下、P95 RPOは10秒以下となります。 +現在、TiCDCは、TiDBクラスターから別のTiDBクラスターまたはMySQL互換データベースシステム（ Aurora、MySQL、MariaDBを含む）へ増分データを複製できます。上流クラスターがクラッシュした場合、TiCDCがクラッシュ前に正常にデータを複製し、複製遅延が小さいという条件を満たせば、TiCDCは下流クラスターで5分以内にデータを復元できます。データ損失は最大10秒まで許容され、RTOは5分以下、P95 RPOは10秒以下となります。 TiCDCのレプリケーション遅延は、以下のシナリオで増加します。 - TPSは短時間で大幅に増加する。 -- 上流工程では、大規模または長時間の取引が発生する。 -- アップストリームのTiKVまたはTiCDCクラスタが再ロードまたはアップグレードされます。 +- 上流工程では、大規模または長時間のトランザクションが発生する。 +- アップストリームのTiKVまたはTiCDCクラスターが再ロードまたはアップグレードされます。 - `add index`のような時間のかかる DDL ステートメントは、上流で実行されます。 - PDは積極的なスケジューリング戦略で構成されており、その結果、リージョンリーダーの頻繁な異動、あるいはリージョンの統合や分割が頻繁に発生します。 > **注記：** > -> バージョン6.1.1以降、TiCDCの最終整合性レプリケーション機能はAmazon S3互換のオブジェクトstorageをサポートしています。バージョン6.1.4以降、この機能はGCSおよびAzure互換のオブジェクトstorageもサポートしています。 +> バージョン6.1.1以降、TiCDCの最終整合性レプリケーション機能はAmazon S3互換のオブジェクトストレージをサポートしています。バージョン6.1.4以降、この機能はGCSおよびAzure互換のオブジェクトストレージもサポートしています。 ### 前提条件 {#prerequisites} -- TiCDCのリアルタイム増分データバックアップファイルを保存するために、高可用性のオブジェクトstorageまたはNFSを準備してください。これらのファイルは、上流側で災害が発生した場合にアクセスできます。 +- TiCDCのリアルタイム増分データバックアップファイルを保存するために、高可用性のオブジェクトストレージまたはNFSを準備してください。これらのファイルは、上流側で災害が発生した場合にアクセスできます。 - 災害発生時に最終的な整合性が必要な変更フィードに対して、この機能を有効にしてください。有効にするには、変更フィードの設定ファイルに以下の設定を追加します。 ```toml @@ -161,25 +161,25 @@ max-log-size = 64 # The interval for flushing or uploading redo logs to Amazon S3, in milliseconds. It is recommended that this configuration be equal to or greater than 2000. flush-interval = 2000 -# The path under which redo log backup is stored. The scheme can be nfs (NFS directory), or Amazon S3, GCS, and Azure (uploaded to object storage). -storage = "$SCHEME://logbucket/test-changefeed?endpoint=http://$ENDPOINT/" +# The path under which redo log backup is stored. The scheme can be nfs (NFS directory), or Amazon S3, GCS, and Azure (uploaded to object ストレージ). +ストレージ = "$SCHEME://logbucket/test-changefeed?endpoint=http://$ENDPOINT/" ``` ### 災害リカバリ {#disaster-recovery} -プライマリクラスタで障害が発生した場合は、 `cdc redo`コマンドを実行してセカンダリクラスタで手動で復旧する必要があります。リカバリ手順は以下のとおりです。 +プライマリクラスターで障害が発生した場合は、 `cdc redo`コマンドを実行してセカンダリクラスターで手動で復旧する必要があります。リカバリ手順は以下のとおりです。 -1. TiCDCのすべてのプロセスが終了していることを確認してください。これは、データリカバリ中にプライマリクラスタがサービスを再開したり、TiCDCがデータ同期を再開したりするのを防ぐためです。 +1. TiCDCのすべてのプロセスが終了していることを確認してください。これは、データリカバリ中にプライマリクラスターがサービスを再開したり、TiCDCがデータ同期を再開したりするのを防ぐためです。 2. データリカバリにはcdcバイナリを使用してください。以下のコマンドを実行してください。 ```shell cdc redo apply --tmp-dir="/tmp/cdc/redo/apply" \ - --storage="s3://logbucket/test-changefeed?endpoint=http://10.0.10.25:24927/" \ + --ストレージ="s3://logbucket/test-changefeed?endpoint=http://10.0.10.25:24927/" \ --sink-uri="mysql://normal:123456@10.0.10.55:3306/" ``` このコマンドでは： - `tmp-dir` : TiCDC増分データバックアップファイルをダウンロードするための一時ディレクトリを指定します。 -- `storage` : TiCDC増分データバックアップファイルを保存するアドレスを指定します。オブジェクトstorageのURIまたはNFSディレクトリのいずれかを指定します。 -- `sink-uri` : データを復元するセカンダリクラスタアドレスを指定します。スキームは`mysql`のみ可能です。 +- `ストレージ` : TiCDC増分データバックアップファイルを保存するアドレスを指定します。オブジェクトストレージのURIまたはNFSディレクトリのいずれかを指定します。 +- `sink-uri` : データを復元するセカンダリクラスターアドレスを指定します。スキームは`mysql`のみ可能です。 diff --git a/ticdc/ticdc-sink-to-pulsar.md b/ticdc/ticdc-sink-to-pulsar.md index d38e626f5dde1..d4181a86d972e 100644 --- a/ticdc/ticdc-sink-to-pulsar.md +++ b/ticdc/ticdc-sink-to-pulsar.md @@ -47,13 +47,13 @@ Sink URI を使用して TiCDC ターゲット システムの接続情報を指 [scheme]://[userinfo@][host]:[port][/path]?[query_parameters] ``` -コンフィグレーション例1: +設定例1: ```shell --sink-uri="pulsar://127.0.0.1:6650/persistent://abc/def/yktest?protocol=canal-json" ``` -コンフィグレーション例2: +設定例2: ```shell --sink-uri="pulsar://127.0.0.1:6650/yktest?protocol=canal-json" @@ -151,7 +151,7 @@ TiCDCはv7.5.1およびv8.0.0以降、PulsarのTLS暗号化通信をサポート --sink-uri="pulsar+ssl://127.0.0.1:6651/persistent://public/default/yktest?protocol=canal-json" ``` -コンフィグレーション： +設定： ```toml [sink.pulsar-config] diff --git a/ticdc/ticdc-storage-consumer-dev-guide.md b/ticdc/ticdc-storage-consumer-dev-guide.md index c5f5dc0616f85..b0b39ddbafc19 100644 --- a/ticdc/ticdc-storage-consumer-dev-guide.md +++ b/ticdc/ticdc-storage-consumer-dev-guide.md @@ -1,36 +1,36 @@ --- title: Guide for Developing a Storage Sink Consumer -summary: storageシンク内のデータの変更を消費するコンシューマーを設計および実装する方法を学習します。 +summary: ストレージシンク内のデータの変更を消費するコンシューマーを設計および実装する方法を学習します。 --- -# ストレージシンクコンシューマーの開発ガイド {#guide-for-developing-a-storage-sink-consumer} +# ストレージシンクコンシューマーの開発ガイド {#guide-for-developing-a-ストレージ-sink-consumer} このドキュメントでは、TiDB データ変更コンシューマーを設計および実装する方法について説明します。 > **注記：** > -> storageシンクは`DROP DATABASE` DDLを処理できません。そのため、このDDLの実行は避けてください。このDDLを実行する必要がある場合は、下流のMySQLで手動で実行してください。 +> ストレージシンクは`DROP DATABASE` DDLを処理できません。そのため、このDDLの実行は避けてください。このDDLを実行する必要がある場合は、下流のMySQLで手動で実行してください。 -TiCDC は、コンシューマーを実装するための標準的な方法を提供していません。このドキュメントでは、 Golangで記述されたコンシューマーのサンプルプログラムを提供します。このプログラムは、storageサービスからデータを読み取り、MySQL 互換データベースに書き込むことができます。このサンプルで提供されているデータ形式と手順を参考に、独自にコンシューマーを実装できます。 +TiCDC は、コンシューマーを実装するための標準的な方法を提供していません。このドキュメントでは、 Golangで記述されたコンシューマーのサンプルプログラムを提供します。このプログラムは、ストレージサービスからデータを読み取り、MySQL 互換データベースに書き込むことができます。このサンプルで提供されているデータ形式と手順を参考に、独自にコンシューマーを実装できます。 -[Golangで書かれたコンシューマープログラム](https://github.com/pingcap/tiflow/tree/release-8.5/cmd/storage-consumer) +[Golangで書かれたコンシューマープログラム](https://github.com/pingcap/tiflow/tree/release-8.5/cmd/ストレージ-consumer) ## 消費者をデザインする {#design-a-consumer} 次の図は、消費者の全体的な消費プロセスを示しています。 -![TiCDC storage consumer overview](/media/ticdc/ticdc-storage-consumer-overview.png) +![TiCDC ストレージ consumer overview](/media/ticdc/ticdc-ストレージ-consumer-overview.png) コンシューマーのコンポーネントとその機能は次のように説明されます。 ```go type StorageReader struct { } -// Read the files from storage. -// Add new files and delete files that do not exist in storage. +// Read the files from ストレージ. +// Add new files and delete files that do not exist in ストレージ. func (c *StorageReader) ReadFiles() {} -// Query newly added files and the latest checkpoint from storage. One file can only be returned once. +// Query newly added files and the latest checkpoint from ストレージ. One file can only be returned once. func (c *StorageReader) ExposeNewFiles() (int64, []string) {} // ConsumerManager is responsible for assigning tasks to TableConsumer. @@ -38,7 +38,7 @@ func (c *StorageReader) ExposeNewFiles() (int64, []string) {} // but data of one table must be processed by the same TableConsumer. type ConsumerManager struct { // StorageCheckpoint is recorded in the metadata file, and it can be fetched by calling `StorageReader.ExposeNewFiles()`. - // This checkpoint indicates that the data whose transaction commit time is less than this checkpoint has been stored in storage. + // This checkpoint indicates that the data whose transaction commit time is less than this checkpoint has been stored in ストレージ. StorageCheckpoint int64 // This checkpoint indicates where the consumer has consumed. // ConsumerManager periodically collects TableConsumer.Checkpoint, diff --git a/ticdc/ticdc-summary-monitor.md b/ticdc/ticdc-summary-monitor.md index 79460889bd8a3..8f4f17108706b 100644 --- a/ticdc/ticdc-summary-monitor.md +++ b/ticdc/ticdc-summary-monitor.md @@ -18,7 +18,7 @@ v7.0.0以降、 TiUPを使用してGrafanaをデプロイすると、TiCDCサマ - データフロー: TiCDC 内部モジュールによって処理されるデータ変更の統計。 - トランザクションシンク: ダウンストリーム MySQL または TiDB の書き込みレイテンシー。 - MQ シンク: ダウンストリーム MQ システムの書き込みレイテンシー。 -- クラウド ストレージ シンク: ダウンストリーム クラウドstorageの書き込み速度。 +- クラウド ストレージ シンク: ダウンストリーム クラウドストレージの書き込み速度。 - やり直し: やり直し機能が有効な場合の書き込みレイテンシー。 ## サーバーパネル {#server-panel} @@ -84,11 +84,11 @@ v7.0.0以降、 TiUPを使用してGrafanaをデプロイすると、TiCDCサマ - **ワーカー送信メッセージ期間パーセンタイル**: TiCDC MQ シンク ワーカーがダウンストリームにデータを送信する際のレイテンシー。 - **Kafka Ongoing Bytes** : TiCDC MQ Sink がダウンストリームにデータを送信する速度。 -## クラウドストレージシンクパネル {#cloud-storage-sink-panel} +## クラウドストレージシンクパネル {#cloud-ストレージ-sink-panel} **Cloud Storage シンク**パネルには、ダウンストリームが Cloud Storage の場合にのみデータが表示されます。 -![TiCDC Summary Dashboard - Transaction Sink metrics](/media/ticdc/ticdc-summary-monitor-cloud-storage.png) +![TiCDC Summary Dashboard - Transaction Sink metrics](/media/ticdc/ticdc-summary-monitor-cloud-ストレージ.png) - **書き込みバイト数/秒**: Cloud Storage Sink モジュールがダウンストリームにデータを書き込む速度。 - **ファイル数**: Cloud Storage Sink モジュールによって書き込まれたファイルの合計数。 diff --git a/ticdc/ticdc-upstream-downstream-check.md b/ticdc/ticdc-upstream-downstream-check.md index 66e9f2dccdfe6..a950151dc34c8 100644 --- a/ticdc/ticdc-upstream-downstream-check.md +++ b/ticdc/ticdc-upstream-downstream-check.md @@ -3,7 +3,7 @@ title: Upstream and Downstream Clusters Data Validation and Snapshot Read summary: TiDB アップストリーム クラスターとダウンストリーム クラスターのデータを確認する方法を学習します。 --- -# 上流および下流のクラスタのデータ検証とスナップショットの読み取り {#upstream-and-downstream-clusters-data-validation-and-snapshot-read} +# 上流および下流のクラスターのデータ検証とスナップショットの読み取り {#upstream-and-downstream-clusters-data-validation-and-snapshot-read} TiCDCを使用してTiDBの上流および下流クラスターを構築する場合、レプリケーションを停止することなく、上流および下流のスナップショットの一貫性読み取りやデータ整合性検証を実行する必要がある場合があります。通常のレプリケーションモードでは、TiCDCはデータの結果整合性のみを保証しますが、レプリケーションプロセス中のデータの一貫性は保証できません。そのため、動的に変化するデータの一貫性読み取りを実行することは困難です。このようなニーズを満たすために、TiCDCはSyncpoint機能を提供します。 @@ -51,7 +51,7 @@ sync-point-retention = "1h" ### ステップ1: ts-mapを取得する {#step-1-obtain-code-ts-map-code} -下流TiDBクラスタで次のSQL文を実行すると、上流TSO（ `primary_ts` ）と下流TSO（ `secondary_ts` ）を取得できます。 +下流TiDBクラスターで次のSQL文を実行すると、上流TSO（ `primary_ts` ）と下流TSO（ `secondary_ts` ）を取得できます。 ```sql select * from tidb_cdc.syncpoint_v1; @@ -103,4 +103,4 @@ select * from tidb_cdc.syncpoint_v1; - TiCDC が新しい`primary_ts`生成するときは、その値は`sync-point-interval`の整数倍である必要があります。 - TiCDCは、新しいチェンジフィードごとに初期値`primary_ts`計算します。この初期値は、チェンジフィードの開始時刻（ `startTs` ）以上であり、 `sync-point-interval`の最小の整数倍です。 - この設定は、データレプリケーション中に異なる変更フィードの同期ポイントを揃えるために使用されます。例えば、複数の下流クラスタは、 [`FLASHBACK TABLE`](/sql-statements/sql-statement-flashback-table.md)番目のステートメントを実行することで、同じ`primary_ts`番目の同期ポイントの`secondary_ts`番目の状態に復元することができ、下流クラスタ間でデータの一貫性を確保できます。 + この設定は、データレプリケーション中に異なる変更フィードの同期ポイントを揃えるために使用されます。例えば、複数の下流クラスターは、 [`FLASHBACK TABLE`](/sql-statements/sql-statement-flashback-table.md)番目のステートメントを実行することで、同じ`primary_ts`番目の同期ポイントの`secondary_ts`番目の状態に復元することができ、下流クラスター間でデータの一貫性を確保できます。 diff --git a/ticdc/troubleshoot-ticdc.md b/ticdc/troubleshoot-ticdc.md index 257c4b553c151..23aed5d8716fa 100644 --- a/ticdc/troubleshoot-ticdc.md +++ b/ticdc/troubleshoot-ticdc.md @@ -52,7 +52,7 @@ cdc cli changefeed query --server=http://127.0.0.1:8300 --changefeed-id 28c43ffc ### タスク中断後に TiCDC を再起動した後で発生する OOM を処理するにはどうすればよいですか? {#what-should-i-do-to-handle-the-oom-that-occurs-after-ticdc-is-restarted-after-a-task-interruption} -- TiDBクラスタとTiCDCクラスタを最新バージョンに更新してください。OOM問題は**、v4.0.14以降のv4.0バージョン、v5.0.2以降のv5.0バージョン、および最新バージョン**で既に解決されています。 +- TiDBクラスターとTiCDCクラスターを最新バージョンに更新してください。OOM問題は**、v4.0.14以降のv4.0バージョン、v5.0.2以降のv5.0バージョン、および最新バージョン**で既に解決されています。 ## レプリケーション タスクを作成するとき、または MySQL にデータをレプリケートするときに、「 Error 1298: Unknown or incorrect time zone: 'UTC'エラーを処理するにはどうすればよいですか? {#how-do-i-handle-the-code-error-1298-unknown-or-incorrect-time-zone-utc-code-error-when-creating-the-replication-task-or-replicating-data-to-mysql} diff --git a/tidb-architecture.md b/tidb-architecture.md index ff64e0e8e3f8d..6b78f3279c36b 100644 --- a/tidb-architecture.md +++ b/tidb-architecture.md @@ -34,13 +34,13 @@ TiDB には、クラシック TiDBアーキテクチャと[TiDB Xアーキテク ## 配置Driver（PD）サーバー {#placement-driver-pd-server} -[PDサーバー](/tidb-scheduling.md)はクラスタ全体のメタデータ管理コンポーネントです。各TiKVノードのリアルタイムデータ分布とTiDBクラスタ全体のトポロジ構造に関するメタデータを保存し、TiDBダッシュボード管理UIを提供し、分散トランザクションにトランザクションIDを割り当てます。PDサーバーは、クラスタのメタデータを保存するだけでなく、TiKVノードからリアルタイムに報告されるデータ分布状態に基づいて、特定のTiKVノードにデータスケジューリングコマンドを送信するため、TiDBクラスタ全体の「頭脳」と言えます。また、PDサーバーは少なくとも3ノードで構成され、高い可用性を備えています。奇数個のPDノードを配置することをお勧めします。 +[PDサーバー](/tidb-scheduling.md)はクラスター全体のメタデータ管理コンポーネントです。各TiKVノードのリアルタイムデータ分布とTiDBクラスター全体のトポロジ構造に関するメタデータを保存し、TiDBダッシュボード管理UIを提供し、分散トランザクションにトランザクションIDを割り当てます。PDサーバーは、クラスターのメタデータを保存するだけでなく、TiKVノードからリアルタイムに報告されるデータ分布状態に基づいて、特定のTiKVノードにデータスケジューリングコマンドを送信するため、TiDBクラスター全体の「頭脳」と言えます。また、PDサーバーは少なくとも3ノードで構成され、高い可用性を備えています。奇数個のPDノードを配置することをお勧めします。 -## ストレージサーバー {#storage-servers} +## ストレージサーバー {#ストレージ-servers} ### TiKVサーバー {#tikv-server} -[TiKVサーバー](/tidb-storage.md)はデータの保存を担当します。TiKVは分散トランザクションキーバリューstorageエンジンです。 +[TiKVサーバー](/tidb-ストレージ.md)はデータの保存を担当します。TiKVは分散トランザクションキーバリューストレージエンジンです。 @@ -58,4 +58,4 @@ TiDB には、クラシック TiDBアーキテクチャと[TiDB Xアーキテク ### TiFlashサーバー {#tiflash-server} -[TiFlashサーバー](/tiflash/tiflash-overview.md)は特殊なタイプのstorageサーバーです。通常のTiKVノードとは異なり、 TiFlashはデータを列単位で保存し、主に分析処理の高速化を目的として設計されています。 +[TiFlashサーバー](/tiflash/tiflash-overview.md)は特殊なタイプのストレージサーバーです。通常のTiKVノードとは異なり、 TiFlashはデータを列単位で保存し、主に分析処理の高速化を目的として設計されています。 diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index 0657010e056c1..2058d24fcd370 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -43,7 +43,7 @@ TiDB Cloud Starterは、フルマネージド型のマルチテナントTiDBサ Starterプランは、 TiDB Cloudを初めて利用する方に最適です。開発者や小規模チーム向けに、以下の機能を提供します。 - **無料**：このプランは完全に無料で、利用開始にクレジットカードは必要ありません。 -- **ストレージ**：初期容量として、行ベースのstorageが5 GiB、列ベースのstorageが5 GiB提供されます。 +- **ストレージ**：初期容量として、行ベースのストレージが5 GiB、列ベースのストレージが5 GiB提供されます。 - **要求単位**: データベース操作の 5,000 万[要求単位（RU）](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru)が含まれます。 ## TiDB Cloud Essential {#tidb-cloud-essential} @@ -51,9 +51,9 @@ Starterプランは、 TiDB Cloudを初めて利用する方に最適です。 ワークロードが増加し、リアルタイムでの拡張性を必要とするアプリケーション向けに、 Essentialプランは以下の機能を備え、ビジネスの成長に合わせて柔軟かつ高性能なソリューションを提供します。 - **機能強化**：Starterプランのすべての機能に加え、より大規模で複雑なワークロードを処理できる能力、および高度なセキュリティ機能が含まれています。 -- **自動スケーリング**：変化するワークロードの需要に効率的に対応するために、storageとコンピューティングリソースを自動的に調整します。 +- **自動スケーリング**：変化するワークロードの需要に効率的に対応するために、ストレージとコンピューティングリソースを自動的に調整します。 - **高可用性**：組み込みの耐障害性と冗長性により、インフラストラクチャの障害発生時でも、アプリケーションの可用性と回復力が維持されます。 -- **予測可能な料金体系**：コンピューティングリソースのstorageとリクエストキャパシティユニット（RCU）に基づいて課金されるため、ニーズに合わせて拡張可能な透明性の高い使用量ベースの料金体系が提供され、予期せぬ追加料金なしで使用した分だけを支払うことができます。 +- **予測可能な料金体系**：コンピューティングリソースのストレージとリクエストキャパシティユニット（RCU）に基づいて課金されるため、ニーズに合わせて拡張可能な透明性の高い使用量ベースの料金体系が提供され、予期せぬ追加料金なしで使用した分だけを支払うことができます。 TiDB Cloud Essentialは、さまざまな運用要件に対応するため、2種類の高可用性機能を提供します。 @@ -68,7 +68,7 @@ TiDB Cloud Essentialは、さまざまな運用要件に対応するため、2 - **無制限の成長と自動スケーリング**：変化するワークロードに対応するためのシームレスなスケーリングを提供し、ビジネスに不可欠な業務の継続的な信頼性を確保します。 - **パフォーマンス最適化**：高スループットかつ低遅延のワークロード向けに調整されており、より大きなリソース上限と、よりきめ細かなスケーリング制御を提供します。 -- **従量課金制**：実際の[要求容量単位（RCU）](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu)消費量とstorage使用量に基づいて課金されます。この柔軟なモデルにより、バックエンドでの手動による過剰プロビジョニングが不要になります。 +- **従量課金制**：実際の[要求容量単位（RCU）](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu)消費量とストレージ使用量に基づいて課金されます。この柔軟なモデルにより、バックエンドでの手動による過剰プロビジョニングが不要になります。 - **高度なセキュリティ**：大規模企業や規制対象業界が必要とする、より高度なセキュリティ設定とコンプライアンス機能を提供します。 ミッション クリティカルなワークロードの稼働時間と回復力を最大化するために、 TiDB Cloud Premium は[地域的な高可用性](/tidb-cloud/serverless-high-availability.md#regional-high-availability-architecture)を提供し、複数のアベイラビリティ ゾーンにノードを分散して、ゾーン展開よりも高い冗長性を実現します。 @@ -77,7 +77,7 @@ TiDB Cloud Essentialは、さまざまな運用要件に対応するため、2 TiDB Cloud Dedicatedは、ミッションクリティカルなビジネス向けに設計されており、複数のアベイラビリティゾーンにわたる高可用性、水平スケーリング、および完全なHTAP機能を提供します。 -VPC、VM、マネージドKubernetesサービス、クラウドstorageなどの独立したクラウドリソース上に構築されたTiDB Cloud Dedicatedクラスターは、TiDBの全機能セットをサポートし、迅速なスケーリング、信頼性の高いバックアップ、特定のVPC内でのデプロイ、および地理的レベルのディザスタリカバリ。 +VPC、VM、マネージドKubernetesサービス、クラウドストレージなどの独立したクラウドリソース上に構築されたTiDB Cloud Dedicatedクラスターは、TiDBの全機能セットをサポートし、迅速なスケーリング、信頼性の高いバックアップ、特定のVPC内でのデプロイ、および地理的レベルのディザスタリカバリ。 ![TiDB Cloud Dedicated Architecture](/media/tidb-cloud/tidb-cloud-dedicated-architecture.png) @@ -97,7 +97,7 @@ TiDB Cloud CLI `ticloud`と、簡単なコマンドでターミナルから直 ## TiDB CloudAPI（ベータ版） {#tidb-cloud-api-beta} -TiDB Cloud APIは、RESTベースのインターフェースであり、 TiDB Cloud Starter、 TiDB Cloud Essential、 TiDB Cloud Premium、およびTiDB Cloud Dedicatedの各プランにわたるリソースをプログラムから管理するためのアクセスを提供します。これにより、 [TiDB Cloudデータサービス](/tidb-cloud/data-service-overview.md)におけるプロジェクト、クラスタ、バックアップ、リストア、データインポート、課金、その他のリソースの管理といったタスクを自動化し、効率的に処理することが可能になります。 +TiDB Cloud APIは、RESTベースのインターフェースであり、 TiDB Cloud Starter、 TiDB Cloud Essential、 TiDB Cloud Premium、およびTiDB Cloud Dedicatedの各プランにわたるリソースをプログラムから管理するためのアクセスを提供します。これにより、 [TiDB Cloudデータサービス](/tidb-cloud/data-service-overview.md)におけるプロジェクト、クラスター、バックアップ、リストア、データインポート、課金、その他のリソースの管理といったタスクを自動化し、効率的に処理することが可能になります。 詳細については、 [TiDB Cloud APIの概要](https://docs.pingcap.com/api/tidb-cloud-api-overview)参照してください。 @@ -112,15 +112,15 @@ TiDB Cloud APIは、RESTベースのインターフェースであり、 TiDB Cl [TiDBノード](/tidb-computing.md)MySQL互換エンドポイントを使用してアプリケーションに接続するステートレスなSQLレイヤーです。SQLクエリの解析、最適化、分散実行プランの作成などのタスクを処理します。 -TiDBノードを複数デプロイすることで、水平方向に拡張し、より高いワークロードに対応できます。これらのノードは、TiProxyやHAProxyなどのロードバランサーと連携して、シームレスなインターフェースを提供します。TiDBノード自体はデータを保存せず、データ要求を行ベースstorageの場合はTiKVノードに、列ベースstorageの場合はTiFlashノードに転送します。 +TiDBノードを複数デプロイすることで、水平方向に拡張し、より高いワークロードに対応できます。これらのノードは、TiProxyやHAProxyなどのロードバランサーと連携して、シームレスなインターフェースを提供します。TiDBノード自体はデータを保存せず、データ要求を行ベースストレージの場合はTiKVノードに、列ベースストレージの場合はTiFlashノードに転送します。 ### TiKVノード {#tikv-node} -[TiKVノード](/tikv-overview.md)、TiDBアーキテクチャにおけるデータstorageの基盤であり、信頼性、拡張性、高可用性を提供する分散型トランザクションキーバリューstorageエンジンとして機能します。 +[TiKVノード](/tikv-overview.md)、TiDBアーキテクチャにおけるデータストレージの基盤であり、信頼性、拡張性、高可用性を提供する分散型トランザクションキーバリューストレージエンジンとして機能します。 **主な特徴：** -- **地域ベースのデータstorage** +- **地域ベースのデータストレージ** - データは[地域](https://docs.pingcap.com/tidb/dev/glossary#regionpeerraft-group)ごとに分割され、それぞれが特定のキー範囲（左端が閉じ、右端が開いた区間： `StartKey`から`EndKey` ）をカバーします。 - 効率的なデータ配信を確保するため、各TiKVノード内には複数のリージョンが共存している。 @@ -141,11 +141,11 @@ TiDBノードを複数デプロイすることで、水平方向に拡張し、 ### TiFlashノード {#tiflash-node} -[TiFlashノード](/tiflash/tiflash-overview.md)TiDBアーキテクチャ内の特殊なstorageノードです。通常のTiKVノードとは異なり、 TiFlashはカラム型storageモデルによる分析高速化のために設計されています。 +[TiFlashノード](/tiflash/tiflash-overview.md)TiDBアーキテクチャ内の特殊なストレージノードです。通常のTiKVノードとは異なり、 TiFlashはカラム型ストレージモデルによる分析高速化のために設計されています。 **主な特徴：** -- **柱状storage** +- **柱状ストレージ** TiFlashノードはデータを列形式で保存するため、分析クエリに最適化されており、読み取り負荷の高いワークロードのパフォーマンスを大幅に向上させます。 @@ -171,7 +171,7 @@ TiDB Cloud Premium インスタンスを構成する際に、ワークロード ### RCUの請求 {#rcu-billing} -TiDB Cloud Premiumは、実際の要求容量ユニット（RCU）の消費量とstorage使用量に基づいて課金される、使用量ベースの課金モデルを採用しています。 +TiDB Cloud Premiumは、実際の要求容量ユニット（RCU）の消費量とストレージ使用量に基づいて課金される、使用量ベースの課金モデルを採用しています。 #### 1分あたりの計算 {#per-minute-calculation} diff --git a/tidb-cloud/backup-and-restore-concepts.md b/tidb-cloud/backup-and-restore-concepts.md index 1f08297361149..b482aa2a16bc5 100644 --- a/tidb-cloud/backup-and-restore-concepts.md +++ b/tidb-cloud/backup-and-restore-concepts.md @@ -25,7 +25,7 @@ TiDB Cloud Dedicatedの手動バックアップ機能は、必要に応じてデ ## デュアルリージョンバックアップ {#dual-region-backup} -TiDB Cloud Dedicatedのデュアルリージョンバックアップ機能は、クラスタリージョンから別のリージョンへバックアップを複製できる機能です。この機能を有効にすると、すべてのバックアップが指定されたリージョンに自動的に複製されます。これにより、リージョンをまたいだデータ保護とディザスタリカバリ機能が実現します。データの約99%は1時間以内にセカンダリリージョンに複製できると推定されています。 +TiDB Cloud Dedicatedのデュアルリージョンバックアップ機能は、クラスターリージョンから別のリージョンへバックアップを複製できる機能です。この機能を有効にすると、すべてのバックアップが指定されたリージョンに自動的に複製されます。これにより、リージョンをまたいだデータ保護とディザスタリカバリ機能が実現します。データの約99%は1時間以内にセカンダリリージョンに複製できると推定されています。 詳細については、 [デュアルリージョンバックアップを有効にする](/tidb-cloud/backup-and-restore.md#turn-on-dual-region-backup)参照してください。 diff --git a/tidb-cloud/backup-and-restore.md b/tidb-cloud/backup-and-restore.md index bb5088c340d93..611b713a87ddb 100644 --- a/tidb-cloud/backup-and-restore.md +++ b/tidb-cloud/backup-and-restore.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidbcloud/restore-deleted-tidb-cluster'] # TiDB Cloud Dedicatedデータのバックアップと復元 {#back-up-and-restore-tidb-cloud-dedicated-data} -このドキュメントでは、 TiDB Cloud上でTiDB Cloud Dedicatedクラスタのデータをバックアップおよび復元する方法について説明します。TiDB Cloud Dedicated は、自動バックアップと手動バックアップをサポートしています。また、バックアップデータを新しいクラスタに復元したり、ごみ箱から削除されたクラスタを復元したりすることもできます。 +このドキュメントでは、 TiDB Cloud上でTiDB Cloud Dedicatedクラスターのデータをバックアップおよび復元する方法について説明します。TiDB Cloud Dedicated は、自動バックアップと手動バックアップをサポートしています。また、バックアップデータを新しいクラスターに復元したり、ごみ箱から削除されたクラスターを復元したりすることもできます。 > **ヒント** > @@ -14,7 +14,7 @@ aliases: ['/ja/tidbcloud/restore-deleted-tidb-cluster'] ## 制限事項 {#limitations} -- TiDB Cloud Dedicatedは、v6.2.0以降のバージョンのクラスタでは、デフォルトでバックアップからのユーザーアカウントとSQLバインディングの復元をサポートしています。 +- TiDB Cloud Dedicatedは、v6.2.0以降のバージョンのクラスターでは、デフォルトでバックアップからのユーザーアカウントとSQLバインディングの復元をサポートしています。 - TiDB Cloud Dedicated は、 `mysql`スキーマに保存されているシステム変数の復元をサポートしていません。 - 最初にデータをインポートし、次に**手動**スナップショット バックアップを実行し、最後にポイントインタイム リストアを有効にすることをお勧めします。 TiDB Cloudコンソールを通じてインポートされたデータは変更ログを生成**しない**ため、自動的に検出してバックアップすることはできません。詳細については、[クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)参照してください。 - ポイントインタイム復元を複数回オン/オフした場合、復元可能な期間内で選択できるのは、直近のポイントインタイム復元が有効になった時点以降の時点のみです。それ以前の復元可能な期間にはアクセスできません。 @@ -24,7 +24,7 @@ aliases: ['/ja/tidbcloud/restore-deleted-tidb-cluster'] ### バックアップページをビュー {#view-the-backup-page} -1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Dedicatedクラスタの名前をクリックすると、その概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Dedicatedクラスターの名前をクリックすると、その概要ページに移動します。 > **ヒント：** > @@ -40,7 +40,7 @@ TiDB Cloud Dedicated は、 [スナップショットバックアップ](https:/ > **注記** > -> ポイントインタイム復元機能は、バージョン6.4.0以降のTiDB Cloud Dedicatedクラスタでサポートされています。 +> ポイントインタイム復元機能は、バージョン6.4.0以降のTiDB Cloud Dedicatedクラスターでサポートされています。 この機能は、任意の時点のデータを新しいクラスターに復元することをサポートします。この機能は、以下の目的で使用できます。 @@ -48,7 +48,7 @@ TiDB Cloud Dedicated は、 [スナップショットバックアップ](https:/ - データ書き込みエラーが発生した場合は、エラー発生前の時点にデータを復元することで解決します。 - 企業の過去のデータを監査する。 -この機能をオンにすることを強くお勧めします。コストはスナップショットバックアップと同じです。詳細については、 [データバックアップ費用](https://www.pingcap.com/tidb-dedicated-pricing-details#backup-storage-cost)を参照してください。 +この機能をオンにすることを強くお勧めします。コストはスナップショットバックアップと同じです。詳細については、 [データバックアップ費用](https://www.pingcap.com/tidb-dedicated-pricing-details#backup-ストレージ-cost)を参照してください。 TiDB Cloud Dedicatedクラスターでこの機能を有効にするには、以下の手順を実行してください。 @@ -87,19 +87,19 @@ TiDB Cloud Dedicatedクラスターのバックアップ スケジュールを > - 週次バックアップが有効になっている場合、ポイントインタイム復元機能はデフォルトで有効になりますが、手動で無効にすることもできます。 > - バックアップサイクルを週単位から日単位に変更した場合でも、ポイントインタイム復元機能は元の設定のままです。必要に応じて手動で無効にすることもできます。 - - **「バックアップ時間」**で、日次または週次のクラスタバックアップの開始時間をスケジュールします。 + - **「バックアップ時間」**で、日次または週次のクラスターバックアップの開始時間をスケジュールします。 バックアップの希望時刻を指定しない場合、 TiDB Cloudはデフォルトのバックアップ時刻を割り当てます。これは、クラスターが配置されているリージョンのタイムゾーンにおける午前2時です。 > **注記** > - > - データインポートジョブが実行中の場合、バックアップジョブは自動的に遅延されます。データインポート中またはクラスタのスケーリング中は、手動バックアップを実行**しないでください**。 + > - データインポートジョブが実行中の場合、バックアップジョブは自動的に遅延されます。データインポート中またはクラスターのスケーリング中は、手動バックアップを実行**しないでください**。 - **バックアップ保持期間**では、バックアップデータの最小保持期間を設定します。デフォルトの期間は7日間です。業務への影響を最小限に抑えるため、ワークロードが少ない時間帯に自動バックアップを実行することをお勧めします。 > **注記** > - > - 最新の自動バックアップを除くすべての自動バックアップは、保存期間を超過すると削除されます。最新の自動バックアップは、手動で削除しない限り削除されません。これにより、誤って削除してしまった場合でもクラスタデータを復元できます。 + > - 最新の自動バックアップを除くすべての自動バックアップは、保存期間を超過すると削除されます。最新の自動バックアップは、手動で削除しない限り削除されません。これにより、誤って削除してしまった場合でもクラスターデータを復元できます。 > - クラスターを削除すると、保持期間内に有効期限が設定されている自動バックアップはごみ箱に移動されます。 ### デュアルリージョンバックアップを有効にする {#turn-on-dual-region-backup} @@ -107,11 +107,11 @@ TiDB Cloud Dedicatedクラスターのバックアップ スケジュールを > **注記：** > > - 現在、デュアルリージョンバックアップ機能は、AWSおよびGoogle Cloud上でホストされているTiDB Cloud Dedicatedクラスターでのみ利用可能です。 -> - Google Cloud 上でホストされているTiDB Cloud Dedicatedクラスターは、Google Cloud Storage とシームレスに連携します。Google Cloud Storage と同様に、 **TiDB Cloud Dedicated は、Google デュアルリージョンstorageと同じマルチリージョンコード内でのみデュアルリージョンペアリングをサポートします**。たとえば、アジアでは現在、デュアルリージョンstorageのために東京と大阪をペアリングする必要があります。詳細については、 [二重領域](https://cloud.google.com/storage/docs/locations#location-dr)を参照してください。 +> - Google Cloud 上でホストされているTiDB Cloud Dedicatedクラスターは、Google Cloud Storage とシームレスに連携します。Google Cloud Storage と同様に、 **TiDB Cloud Dedicated は、Google デュアルリージョンストレージと同じマルチリージョンコード内でのみデュアルリージョンペアリングをサポートします**。たとえば、アジアでは現在、デュアルリージョンストレージのために東京と大阪をペアリングする必要があります。詳細については、 [二重領域](https://cloud.google.com/ストレージ/docs/locations#location-dr)を参照してください。 -TiDB Cloud Dedicatedは、クラスタリージョンから別のリージョンにバックアップを複製することで、デュアルリージョンバックアップをサポートします。この機能を有効にすると、すべてのバックアップが指定されたリージョンに自動的に複製されます。これにより、リージョンをまたいだデータ保護とディザスタリカバリ機能が実現します。データの約99%は1時間以内にセカンダリリージョンに複製されると推定されます。 +TiDB Cloud Dedicatedは、クラスターリージョンから別のリージョンにバックアップを複製することで、デュアルリージョンバックアップをサポートします。この機能を有効にすると、すべてのバックアップが指定されたリージョンに自動的に複製されます。これにより、リージョンをまたいだデータ保護とディザスタリカバリ機能が実現します。データの約99%は1時間以内にセカンダリリージョンに複製されると推定されます。 -デュアル リージョンのバックアップ コストには、バックアップstorageの使用量とリージョン間のデータ転送料金の両方が含まれます。詳細については、 [データバックアップ費用](https://www.pingcap.com/tidb-dedicated-pricing-details#backup-storage-cost)を参照してください。 +デュアル リージョンのバックアップ コストには、バックアップストレージの使用量とリージョン間のデータ転送料金の両方が含まれます。詳細については、 [データバックアップ費用](https://www.pingcap.com/tidb-dedicated-pricing-details#backup-ストレージ-cost)を参照してください。 TiDB Cloud Dedicatedクラスターでデュアルリージョンバックアップを有効にするには、次の手順を実行します。 @@ -178,7 +178,7 @@ TiDB Cloud Dedicatedクラスターに手動バックアップを適用するに ### バックアップのエクスポート {#export-backups} -特定のバックアップをAmazon S3やGoogle Cloud Storageなどのクラウドstorageにエクスポートするには、対象のstorageプロバイダーの手順に従ってください。 +特定のバックアップをAmazon S3やGoogle Cloud Storageなどのクラウドストレージにエクスポートするには、対象のストレージプロバイダーの手順に従ってください。 > **注記：** > @@ -226,16 +226,16 @@ TiDB Cloud Dedicatedクラスターに手動バックアップを適用するに 4. [Google Cloud Console](https://console.cloud.google.com/)で、以下の権限を持つカスタムIAMロールを作成します。既存のロールを使用する場合は、そのロールにこれらの権限が付与されていることを確認してください。 - - `storage.buckets.get` - - `storage.objects.list` - - `storage.objects.create` - - `storage.objects.delete` + - `ストレージ.buckets.get` + - `ストレージ.objects.list` + - `ストレージ.objects.create` + - `ストレージ.objects.delete` 5. **クラウドストレージ**>**バケット**に移動し、対象のバケットを選択してから、**アクセス許可**>**アクセスを**許可 をクリックします。 6. **「新しいプリンシパル」**で、手順3の**サービスアカウントID**を入力し、手順4の役割を割り当ててから、 **「保存」**をクリックします。 -7. **「コンフィグレーション」**タブを開き、 **gsutil URIを**コピーして、 **「Google Cloud Storageへのバックアップのエクスポート」**ダイアログの**「エクスポートパス」**フィールドに貼り付けます。サブディレクトリにエクスポートする場合は、URIにパスサフィックスを追加します。 +7. **「設定」**タブを開き、 **gsutil URIを**コピーして、 **「Google Cloud Storageへのバックアップのエクスポート」**ダイアログの**「エクスポートパス」**フィールドに貼り付けます。サブディレクトリにエクスポートする場合は、URIにパスサフィックスを追加します。 8. エクスポートを開始するには、 **「エクスポート」**をクリックしてください。 @@ -267,9 +267,9 @@ TiDB Cloud Dedicatedクラスターの実行中のバックアップ ジョブ > **注記** > -> TiDBクラスタをバックアップから復元する場合、復元プロセスは元のタイムゾーン設定を上書きすることなく保持します。 +> TiDBクラスターをバックアップから復元する場合、復元プロセスは元のタイムゾーン設定を上書きすることなく保持します。 -TiDB Cloud Dedicatedクラスタのデータをバックアップから新しいクラスタに復元するには、以下の手順を実行してください。 +TiDB Cloud Dedicatedクラスターのデータをバックアップから新しいクラスターに復元するには、以下の手順を実行してください。 1. TiDB Cloud Dedicatedクラスターの[**バックアップ**](#view-the-backup-page)ページに移動します。 @@ -279,14 +279,14 @@ TiDB Cloud Dedicatedクラスタのデータをバックアップから新しい > **注記** > - > - **「復元元リージョン」**のデフォルト値は、バックアップクラスタの値と同じです。 + > - **「復元元リージョン」**のデフォルト値は、バックアップクラスターの値と同じです。 4. **復元モード**では、任意の時点のデータ、または選択したバックアップを新しいクラスターに復元するかどうかを選択できます。
    - バックアップ保持期間内の任意の時点のデータを新しいクラスタに復元するには、**バックアップ設定**の**「時点復元」**がオンになっていることを確認し、以下の手順を実行してください。 + バックアップ保持期間内の任意の時点のデータを新しいクラスターに復元するには、**バックアップ設定**の**「時点復元」**がオンになっていることを確認し、以下の手順を実行してください。 - **「時間ポイントを選択」**をクリックしてください。 - 復元したい**日時****を**選択してください。 @@ -309,13 +309,13 @@ TiDB Cloud Dedicatedクラスタのデータをバックアップから新しい - クラスター名を設定します。 - クラスターのポート番号を更新してください。 - - クラスターのノード数、vCPU、RAM、およびstorageを増やす。 + - クラスターのノード数、vCPU、RAM、およびストレージを増やす。 7. **「復元」**をクリックしてください。 クラスター復元プロセスが開始され、**パスワード設定**ダイアログボックスが表示されます。 -8. **パスワード設定**ダイアログボックスで、 TiDB Cloud Dedicatedクラスタに接続するためのrootパスワードを設定し、 **[保存]**をクリックします。 +8. **パスワード設定**ダイアログボックスで、 TiDB Cloud Dedicatedクラスターに接続するためのrootパスワードを設定し、 **[保存]**をクリックします。 ### 削除されたクラスターを復元する {#restore-a-deleted-cluster} @@ -340,10 +340,10 @@ TiDB Cloud Dedicatedクラスタのデータをバックアップから新しい 5. **復元**ページで、新しいクラスターの名前を指定し、必要に応じて以下の変更を行います。 - クラスターのポート番号を更新してください。 - - クラスターのノード数、vCPU、RAM、およびstorageを増やしてください。 + - クラスターのノード数、vCPU、RAM、およびストレージを増やしてください。 6. **概要**セクションで復元情報を確認し、 **「復元」**をクリックします。 クラスター復元プロセスが開始され、**パスワード設定**ダイアログボックスが表示されます。 -7. **パスワード設定**ダイアログボックスで、 TiDB Cloud Dedicatedクラスタに接続するためのrootパスワードを設定し、 **[保存]**をクリックします。 +7. **パスワード設定**ダイアログボックスで、 TiDB Cloud Dedicatedクラスターに接続するためのrootパスワードを設定し、 **[保存]**をクリックします。 diff --git a/tidb-cloud/branch-overview.md b/tidb-cloud/branch-overview.md index 2cd834688effd..f468157af8df6 100644 --- a/tidb-cloud/branch-overview.md +++ b/tidb-cloud/branch-overview.md @@ -41,7 +41,7 @@ TiDB Cloudは、高速かつシームレスなブランチ作成を実現する - TiDB Cloudの各組織では、デフォルトではTiDB Cloud StarterおよびEssentialインスタンス全体で最大 5 つのブランチを作成できます。TiDB TiDB Cloud StarterまたはEssentialインスタンスのブランチは、インスタンスと同じリージョンに作成されます。また、スロットリングが適用されている、または 100 GiB を超えるサイズのTiDB Cloud StarterまたはEssentialインスタンスにはブランチを作成できません。 -- 無料のTiDB Cloud Starterインスタンスの各ブランチには、10 GiB のstorageが許可されます。利用制限が 0 より大きいTiDB Cloud Starterインスタンスの各ブランチには、100 GiB のstorageが許可されます。storage容量が上限に達すると、storageを減らすまで、このブランチでの読み取りおよび書き込み操作が制限されます。 +- 無料のTiDB Cloud Starterインスタンスの各ブランチには、10 GiB のストレージが許可されます。利用制限が 0 より大きいTiDB Cloud Starterインスタンスの各ブランチには、100 GiB のストレージが許可されます。ストレージ容量が上限に達すると、ストレージを減らすまで、このブランチでの読み取りおよび書き込み操作が制限されます。 - ブランチは、短期的な機能開発と機能テストを目的としています。ブランチには自動スケーリング機能がないため、パフォーマンス テストには適していません。 diff --git a/tidb-cloud/built-in-monitoring.md b/tidb-cloud/built-in-monitoring.md index 05ed78b22fbb0..a78480d4654f7 100644 --- a/tidb-cloud/built-in-monitoring.md +++ b/tidb-cloud/built-in-monitoring.md @@ -38,7 +38,7 @@ TiDB Cloudでは、メトリクスデータは7日間保持されます。 | 1秒あたりのコマンド数 | クエリ、ステートメント実行、およびステートメント準備 | コマンドの種類に基づいて、すべての TiDB ノードが 1 秒あたりに処理するコマンドの数。 | | プランキャッシュOPSを使用したクエリ | ヒット、ミス | hit: すべてのTiDBノードにおいて、1秒あたりにプランキャッシュを使用するクエリの数。
    miss: すべての TiDB ノードにおいて、1 秒あたりにプラン キャッシュに見つからないクエリの数。 | | トランザクション/秒 | {タイプ}-{トランザクションモデル} | 1秒あたりに実行されるトランザクション数。 | -| トランザクション期間 | 平均-{トランザクションモデル}、99-{トランザクションモデル} | 取引の平均期間、または99パーセンタイル値。 | +| トランザクション期間 | 平均-{トランザクションモデル}、99-{トランザクションモデル} | トランザクションの平均期間、または99パーセンタイル値。 | | 接続数 | すべて、アクティブな接続 | All: すべてのTiDBノードへの接続数。
    アクティブな接続数：すべてのTiDBノードへのアクティブな接続数。 | | 切断回数 | {インスタンス}-{結果} | 各TiDBノードから切断されたクライアントの数。 | @@ -46,7 +46,7 @@ TiDB Cloudでは、メトリクスデータは7日間保持されます。 | メトリック名 | ラベル | 説明 | | :---------------------------- | :----------------- | :--------------------------------------------------------------------------------------------------------------------------------- | -| 平均アイドル接続時間 | 取引内平均、取引外平均 | 接続アイドル時間とは、接続がアイドル状態であった時間を示します。
    avg-in-txn: 接続がトランザクション内にある場合の平均接続アイドル時間。
    avg-not-in-txn: 接続がトランザクション内にない場合の平均接続アイドル時間。 | +| 平均アイドル接続時間 | トランザクション内平均、トランザクション外平均 | 接続アイドル時間とは、接続がアイドル状態であった時間を示します。
    avg-in-txn: 接続がトランザクション内にある場合の平均接続アイドル時間。
    avg-not-in-txn: 接続がトランザクション内にない場合の平均接続アイドル時間。 | | トークンの有効期間を取得する | 平均、99 | SQL文のトークンを取得するのに要する平均時間、または99パーセンタイル値。 | | 解析時間 | 平均、99 | SQL文の解析に要する平均時間、または99パーセンタイル値。 | | コンパイル時間 | 平均、99 | 解析されたSQL抽象構文木（AST）を実行計画にコンパイルする際に要する平均時間、または99パーセンタイル値。 | @@ -54,7 +54,7 @@ TiDB Cloudでは、メトリクスデータは7日間保持されます。 | TiDB KVリクエストの平均所要時間 | {リクエストタイプ} | `Get` 、 `Prewrite`などのリクエストタイプに基づいて、すべて`Commit`でKVリクエストを実行するのに要する平均時間。 | | TiKV gRPCの平均持続時間 | {リクエストタイプ} | `kv_get` 、 `kv_prewrite` `kv_commit`でgRPCリクエストを実行するのに要した平均時間。 | | 平均 / P99 PD TSO 待ち時間/RPC 所要時間 | 待機時間平均/99、RPC平均/99 | 待機時間：すべてのTiDBノードにおいてPDがTSOを返すまでの待機時間の平均値、または99パーセンタイル値。
    RPC: PDにTSOリクエストを送信してから、すべてのTiDBノードでTSOを受信するまでの平均時間、または99パーセンタイル値。 | -| 平均 / P99 ストレージ非同期書き込み時間 | 平均、99 | 非同期書き込みで消費される平均時間、または99パーセンタイル値。平均storage非同期書き込み時間 = 平均ストレージ時間 + 平均適用時間。 | +| 平均 / P99 ストレージ非同期書き込み時間 | 平均、99 | 非同期書き込みで消費される平均時間、または99パーセンタイル値。平均ストレージ非同期書き込み時間 = 平均ストレージ時間 + 平均適用時間。 | | 平均 / P99 店舗での保管期間 | 平均、99 | 非同期書き込み時のストレージループで消費される平均時間、または99パーセンタイル値。 | | 平均 / P99 適用期間 | 平均、99 | 非同期書き込み中にループを適用する際に要する平均時間、または99パーセンタイル値。 | | 平均 / P99 追記ログの所要時間 | 平均、99 | Raftがログを追加する際に要する平均時間、または99パーセンタイル値。 | @@ -75,12 +75,12 @@ TiDB Cloudでは、メトリクスデータは7日間保持されます。 | TiKVのCPU使用率 | ノード、制限 | 各TiKVノードのCPU使用率統計または上限値。 | | TiKVのメモリ使用量 | ノード、制限 | 各TiKVノードのメモリ使用量統計または上限値。 | | TiKV IO bps | ノード書き込み、ノード読み取り | 各TiKVノードにおける、1秒あたりの読み取りおよび書き込みの総入出力バイト数。 | -| TiKVストレージの使用状況 | ノード、制限 | 各TiKVノードのstorage使用量統計または上限値。storage使用量には、storageエンジン内の論理データサイズ、WALファイル、および一時ファイルが含まれます。 | +| TiKVストレージの使用状況 | ノード、制限 | 各TiKVノードのストレージ使用量統計または上限値。ストレージ使用量には、ストレージエンジン内の論理データサイズ、WALファイル、および一時ファイルが含まれます。 | | TiFlashの稼働時間 | ノード | 各TiFlashノードの前回再起動以降の実行時間。 | | TiFlashのCPU使用率 | ノード、制限 | 各TiFlashノードのCPU使用率統計または上限値。 | | TiFlashメモリの使用状況 | ノード、制限 | 各TiFlashノードのメモリ使用量統計または上限値。 | | TiFlash IO MBps | ノード書き込み、ノード読み取り | 各TiFlashノードにおける読み書きの合計バイト数。 | -| TiFlashストレージの使用状況 | ノード、制限 | 各TiFlashノードのstorage使用量統計または上限値。storage使用量には、storageエンジン内の論理データサイズ、WALファイル、および一時ファイルが含まれます。 | +| TiFlashストレージの使用状況 | ノード、制限 | 各TiFlashノードのストレージ使用量統計または上限値。ストレージ使用量には、ストレージエンジン内の論理データサイズ、WALファイル、および一時ファイルが含まれます。 | | TiProxyのCPU使用率 | ノード | 各TiProxyノードのCPU使用率統計情報。上限は100%です。 | | TiProxy接続 | ノード | 各TiProxyノード上の接続数。 | | TiProxyのスループット | ノード | 各TiProxyノードで1秒あたりに転送されるバイト数。 | @@ -90,18 +90,18 @@ TiDB Cloudでは、メトリクスデータは7日間保持されます。 **メトリクス**ページには、TiDB Cloud StarterとTiDB Cloud Essentialインスタンスのメトリクスを表示する2つのタブがあります。 -- **クラスタステータス**：クラスタレベルの主要なメトリックを表示します。 +- **クラスターステータス**：クラスターレベルの主要なメトリックを表示します。 - **データベースステータス**：データベースレベルの主要なメトリックを表示します。 -### クラスタの状態 {#cluster-status} +### クラスターの状態 {#cluster-status} -以下の表は**、 [クラスタステータス]**タブに表示されるクラスタレベルの主要メトリックを示しています。 +以下の表は**、 [クラスターステータス]**タブに表示されるクラスターレベルの主要メトリックを示しています。 | メトリック名 | ラベル | 説明 | | :----------- | :----------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ユニットをリクエストする | RU/秒 | リクエストユニット（RU）は、 TiDB Cloud Starterインスタンスにおけるクエリまたはトランザクションのリソース消費量を追跡するために使用される測定単位です。ユーザークエリに加えて、バックグラウンドアクティビティもRUを消費するため、QPSが0の場合でも、1秒あたりのRU使用量はゼロにならない場合があります。 | | 容量対使用量（RU/秒） | プロビジョニング済み容量（RCU）、消費RU/秒 | TiDB Cloud Essentialインスタンスにおける、1秒あたりのリクエスト容量ユニット（RCU）と消費リクエストユニット（RU）。 | -| 使用済みストレージサイズ | 行ベースstorage、列ベースstorage | 行ベースstorageと列ベースstorageのサイズ。このメトリックは、各storageタイプが50 MiB以上の場合にのみ表示されます。 | +| 使用済みストレージサイズ | 行ベースストレージ、列ベースストレージ | 行ベースストレージと列ベースストレージのサイズ。このメトリックは、各ストレージタイプが50 MiB以上の場合にのみ表示されます。 | | 1秒あたりのクエリ数 | すべて、{SQLタイプ} | 1 秒あたりに実行される SQL ステートメントの数。これは、 `SELECT` 、 `INSERT` 、 `UPDATE`などの SQL タイプごとに収集されます。 | | クエリ実行時間 | 平均値、P99、P99-{SQLタイプ} | クライアントからTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにリクエストが送信されてから、インスタンスがリクエストを実行して結果をクライアントに返すまでの時間。 | | クエリが失敗しました | 全て | 1秒あたりのSQL文実行エラー数。 | @@ -109,7 +109,7 @@ TiDB Cloudでは、メトリクスデータは7日間保持されます。 | トランザクション期間 | 平均、P99 | トランザクションの実行時間。 | | ロック待機 | P95、P99 | トランザクションが悲観的ロックの取得を待機する時間。値が高いほど、同じ行またはキーに対する競合が発生していることを示します。 | | トータルコネクション | 全て | TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスへの接続数。 | -| アイドル接続時間 | P99、P99（取引内）、P99（取引外） | トランザクションが開いている間、接続がアイドル状態になっている時間。この時間が長い場合は、通常、アプリケーションロジックの処理速度が遅いか、トランザクションの実行時間が長いことを示しています。 | +| アイドル接続時間 | P99、P99（トランザクション内）、P99（トランザクション外） | トランザクションが開いている間、接続がアイドル状態になっている時間。この時間が長い場合は、通常、アプリケーションロジックの処理速度が遅いか、トランザクションの実行時間が長いことを示しています。 | ### データベースの状態 {#database-status} diff --git a/tidb-cloud/changefeed-overview.md b/tidb-cloud/changefeed-overview.md index 61d8b0baf7718..796ca1d67b1e2 100644 --- a/tidb-cloud/changefeed-overview.md +++ b/tidb-cloud/changefeed-overview.md @@ -7,7 +7,7 @@ summary: TiDB Cloud changefeed を使用すると、TiDB Cloudから他のデー -TiDB Cloud changefeed を使用すると、 TiDB Cloudから他のデータサービスにデータをストリーミングできます。現在、 TiDB Cloud Dedicated は、 Apache Kafka、MySQL、 TiDB Cloud、およびクラウドstorageへのデータストリーミングをサポートしています。 +TiDB Cloud changefeed を使用すると、 TiDB Cloudから他のデータサービスにデータをストリーミングできます。現在、 TiDB Cloud Dedicated は、 Apache Kafka、MySQL、 TiDB Cloud、およびクラウドストレージへのデータストリーミングをサポートしています。 @@ -52,7 +52,7 @@ TiDB Cloud changefeed を使用すると、 TiDB Cloudから他のデータサ - [Apache Kafkaへのシンク](/tidb-cloud/changefeed-sink-to-apache-kafka.md) - [MySQLにシンクする](/tidb-cloud/changefeed-sink-to-mysql.md) - [TiDB Cloudにシンクする](/tidb-cloud/changefeed-sink-to-tidb-cloud.md) -- [クラウドstorageにシンクする](/tidb-cloud/changefeed-sink-to-cloud-storage.md) +- [クラウドストレージにシンクする](/tidb-cloud/changefeed-sink-to-cloud-ストレージ.md) @@ -132,7 +132,7 @@ TiDB Cloud Premiumでは、チェンジフィードのTiCDC Changefeed容量ユ - Apache Kafkaシンク：すべての設定。 - MySQLシンク： **MySQL接続**、**テーブルフィルタ**、および**イベントフィルタ**。 - TiDB Cloudシンク: **TiDB Cloud接続**、**テーブルフィルタ**、および**イベントフィルタ**。 - - クラウドstorageシンク：**ストレージエンドポイント**、**テーブルフィルタ**、および**イベントフィルタ**。 + - クラウドストレージシンク：**ストレージエンドポイント**、**テーブルフィルタ**、および**イベントフィルタ**。 diff --git a/tidb-cloud/changefeed-sink-to-apache-kafka.md b/tidb-cloud/changefeed-sink-to-apache-kafka.md index ebb5a34c3fbd1..f7d56f1bf1d2c 100644 --- a/tidb-cloud/changefeed-sink-to-apache-kafka.md +++ b/tidb-cloud/changefeed-sink-to-apache-kafka.md @@ -11,7 +11,7 @@ summary: このドキュメントでは、TiDB Cloudから Apache Kafka へデ > **注記：** > -> 変更フィード機能を使用するには、 TiDB Cloud Dedicatedクラスタのバージョンがv6.1.3以降であることを確認してください。 +> 変更フィード機能を使用するには、 TiDB Cloud Dedicatedクラスターのバージョンがv6.1.3以降であることを確認してください。 @@ -24,7 +24,7 @@ summary: このドキュメントでは、TiDB Cloudから Apache Kafka へデ -- ネットワーク接続方法としてプライベートリンクまたはプライベートサービスコネクトを選択する場合は、 TiDB Cloud Dedicatedクラスタのバージョンが以下の要件を満たしていることを確認してください。 +- ネットワーク接続方法としてプライベートリンクまたはプライベートサービスコネクトを選択する場合は、 TiDB Cloud Dedicatedクラスターのバージョンが以下の要件を満たしていることを確認してください。 - v6.5.xの場合：バージョンv6.5.9以降 - v7.1.xの場合：バージョンv7.1.4以降 @@ -34,7 +34,7 @@ summary: このドキュメントでは、TiDB Cloudから Apache Kafka へデ - Kafkaメッセージのパーティション分散については、以下の点に注意してください。 - 変更ログをプライマリキーまたはインデックス値に基づいて、指定したインデックス名を持つ Kafka パーティションに分散する場合は、 TiDB Cloud Dedicatedクラスターのバージョンが v7.5.0 以降であることを確認してください。 - - 変更ログを列値ごとにKafkaパーティションに分散する場合は、 TiDB Cloud Dedicatedクラスタのバージョンがv7.5.0以降であることを確認してください。 + - 変更ログを列値ごとにKafkaパーティションに分散する場合は、 TiDB Cloud Dedicatedクラスターのバージョンがv7.5.0以降であることを確認してください。 @@ -135,7 +135,7 @@ Apache KafkaサービスにパブリックIPアクセスを提供する場合は TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミングし、Kafkaトピックを自動的に作成できるようにするには、Kafkaに以下の権限が追加されていることを確認してください。 - Kafka のトピック リソース タイプに`Create`および`Write`権限が追加されます。 -- Kafka のクラスタ リソース タイプに`DescribeConfigs`権限が追加されます。 +- Kafka のクラスター リソース タイプに`DescribeConfigs`権限が追加されます。 たとえば、Kafka クラスターが Confluent Cloud にある場合、詳細については Confluent ドキュメントの[リソース](https://docs.confluent.io/platform/current/kafka/authorization.html#resources)と[ACLの追加](https://docs.confluent.io/platform/current/kafka/authorization.html#adding-acls)参照してください。 @@ -328,7 +328,7 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン テーブルのKafkaメッセージを複数のパーティションに送信するように変更フィードを設定したい場合は、この配信方法を選択してください。行の変更ログで指定された列の値によって、変更ログの送信先パーティションが決まります。この配信方法では、各パーティション内の順序が確保され、同じ列の値を持つ変更ログが同じパーティションに送信されることが保証されます。 -9. **トピックコンフィグレーション**領域で、以下の数値を設定してください。changefeedは、これらの数値に基づいてKafkaトピックを自動的に作成します。 +9. **トピック設定**領域で、以下の数値を設定してください。changefeedは、これらの数値に基づいてKafkaトピックを自動的に作成します。 - **レプリケーション係数**：各KafkaメッセージがレプリケートされるKafkaサーバーの数を制御します。有効な値の範囲は、 [`min.insync.replicas`](https://kafka.apache.org/33/documentation.html#brokerconfigs_min.insync.replicas)からKafkaブローカーの数までです。 - **パーティション番号**：トピックに存在するパーティションの数を制御します。有効な値の範囲は`[1, 10 * the number of Kafka brokers]`です。 diff --git a/tidb-cloud/changefeed-sink-to-apache-pulsar.md b/tidb-cloud/changefeed-sink-to-apache-pulsar.md index 826221f98d879..5c614fb9133df 100644 --- a/tidb-cloud/changefeed-sink-to-apache-pulsar.md +++ b/tidb-cloud/changefeed-sink-to-apache-pulsar.md @@ -9,7 +9,7 @@ summary: このドキュメントでは、TiDB Cloudから Apache Pulsar へデ > **注記：** > -> - 変更フィード機能を使用してデータをApache Pulsarに複製するには、 TiDB Cloud Dedicatedクラスタのバージョンがv7.5.1以降であることを確認してください。 +> - 変更フィード機能を使用してデータをApache Pulsarに複製するには、 TiDB Cloud Dedicatedクラスターのバージョンがv7.5.1以降であることを確認してください。 > - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)インスタンスでは、変更フィード機能は利用できません。 > - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンスの場合、変更フィード機能はベータ版です。詳細については、 [変更フィード（ベータ版）](/tidb-cloud/essential-changefeed-overview.md)を参照してください。 @@ -31,7 +31,7 @@ Apache Pulsarにデータをストリーミングするためのチェンジフ ### ネットワーク {#network} -TiDBクラスタがApache Pulsarサービスに接続できることを確認してください。接続方法は以下のいずれかを選択できます。 +TiDBクラスターがApache Pulsarサービスに接続できることを確認してください。接続方法は以下のいずれかを選択できます。 - VPCピアリング：潜在的なVPC CIDRの競合を回避するためのネットワーク計画と、セキュリティ上の懸念事項の考慮が必要です。 - パブリックIP：PulsarがパブリックIPをアドバタイズする場合に適しています。この方法は本番環境では推奨されず、セキュリティ上の懸念事項を慎重に検討する必要があります。 @@ -45,7 +45,7 @@ Apache PulsarサービスがインターネットにアクセスできないAWS 2. Apache Pulsarサービスが関連付けられているセキュリティグループの受信ルールを変更します。 - TiDB Cloudクラスタが配置されているリージョンのCIDRを受信ルールに追加する必要があります。CIDRは**VPCピアリング**ページで確認できます。これにより、TiDBクラスタからPulsarブローカーへのトラフィックが流れるようになります。 + TiDB Cloudクラスターが配置されているリージョンのCIDRを受信ルールに追加する必要があります。CIDRは**VPCピアリング**ページで確認できます。これにより、TiDBクラスターからPulsarブローカーへのトラフィックが流れるようになります。 3. Apache PulsarのURLにホスト名が含まれている場合、 TiDB CloudがApache PulsarブローカーのDNSホスト名を解決できるようにする必要があります。 @@ -57,7 +57,7 @@ Apache Pulsar サービスがインターネットにアクセスできない Go 1. Apache Pulsar サービスの VPC と TiDB クラスターの間で[VPCピアリング接続を設定する](/tidb-cloud/set-up-vpc-peering-connections.md)。 2. Apache Pulsarが配置されているVPCのイングレスファイアウォールルールを変更します。 - TiDB Cloudクラスタが配置されているリージョンのCIDRを、イングレスファイアウォールルールに追加する必要があります。CIDRは**VPCピアリング**ページで確認できます。これにより、TiDBクラスタからPulsarブローカーへのトラフィックが流れるようになります。 + TiDB Cloudクラスターが配置されているリージョンのCIDRを、イングレスファイアウォールルールに追加する必要があります。CIDRは**VPCピアリング**ページで確認できます。これにより、TiDBクラスターからPulsarブローカーへのトラフィックが流れるようになります。
    @@ -84,7 +84,7 @@ Apache PulsarサービスにパブリックIPアクセスを提供する場合 ## ステップ1. Apache PulsarのChangefeedページを開きます。 {#step-1-open-the-changefeed-page-for-apache-pulsar} 1. [TiDB Cloudコンソール](https://tidbcloud.com)にログインします。 -2. 変更フィードイベントの発生源となるTiDBクラスタのクラスタ概要ページに移動し、左側のナビゲーションペインで**「データ」** > **「変更フィード」**をクリックします。 +2. 変更フィードイベントの発生源となるTiDBクラスターのクラスター概要ページに移動し、左側のナビゲーションペインで**「データ」** > **「変更フィード」**をクリックします。 3. **変更フィードを作成を**クリックします。 ## ステップ2. changefeedの送信先を設定します {#step-2-configure-the-changefeed-destination} diff --git a/tidb-cloud/changefeed-sink-to-cloud-storage.md b/tidb-cloud/changefeed-sink-to-cloud-storage.md index 56235f33e3d3c..2c5521f3d941f 100644 --- a/tidb-cloud/changefeed-sink-to-cloud-storage.md +++ b/tidb-cloud/changefeed-sink-to-cloud-storage.md @@ -3,13 +3,13 @@ title: Sink to Cloud Storage summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cloud Storage (GCS)、または Azure Blob Storage へデータをストリーミングするための変更フィードの作成方法について説明します。制限事項、宛先、レプリケーション、仕様に関する構成手順、およびレプリケーションプロセスの開始方法についても説明します。 --- -# クラウドストレージへのシンク {#sink-to-cloud-storage} +# クラウドストレージへのシンク {#sink-to-cloud-ストレージ} -このドキュメントでは、TiDB Cloudからクラウドstorageへデータをストリーミングするためのチェンジフィードの作成方法について説明します。現在、Amazon S3、Google Cloud Storage（GCS）、およびAzure Blob Storageがサポートされています。 +このドキュメントでは、TiDB Cloudからクラウドストレージへデータをストリーミングするためのチェンジフィードの作成方法について説明します。現在、Amazon S3、Google Cloud Storage（GCS）、およびAzure Blob Storageがサポートされています。 > **注記：** > -> - データをクラウドstorageにストリーミングするには、TiDB クラスターのバージョンが v7.1.1 以降であることを確認してください。 TiDB Cloud Dedicatedクラスターを v7.1.1 以降にアップグレードするには、 [TiDB Cloudサポートにお問い合わせください](/tidb-cloud/tidb-cloud-support.md)。 +> - データをクラウドストレージにストリーミングするには、TiDB クラスターのバージョンが v7.1.1 以降であることを確認してください。 TiDB Cloud Dedicatedクラスターを v7.1.1 以降にアップグレードするには、 [TiDB Cloudサポートにお問い合わせください](/tidb-cloud/tidb-cloud-support.md)。 > - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)インスタンスでは、変更フィード機能は利用できません。 > - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンスの場合、変更フィード機能はベータ版です。詳細については、 [変更フィード（ベータ版）](/tidb-cloud/essential-changefeed-overview.md)を参照してください。 @@ -71,7 +71,7 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl 1. TiDB Cloudコンソールで、**サービスアカウントID**を記録してください。このIDは、 TiDB CloudにGCSバケットへのアクセス権を付与するために使用されます。 - ![gcs\_endpoint](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-endpoint.png) + ![gcs\_endpoint](/media/tidb-cloud/changefeed/sink-to-cloud-ストレージ-gcs-endpoint.png) 2. Google Cloud コンソールで、GCS バケット用のIAMロールを作成します。 @@ -79,30 +79,30 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl 2. に移動して、 [役割](https://console.cloud.google.com/iam-admin/roles)**の作成]**をクリックします。 - ![Create a role](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-create-role.png) + ![Create a role](/media/tidb-cloud/changefeed/sink-to-cloud-ストレージ-gcs-create-role.png) 3. 役割の名前、説明、ID、および役割の起動ステージを入力してください。役割名は、作成後に変更することはできません。 4. **「権限の追加」**をクリックします。役割に以下の権限を追加し、 **「追加」**をクリックします。 - - storage.buckets.get - - storage.オブジェクト.作成 - - storage.オブジェクト.削除 - - storage.get - - storage.オブジェクトリスト - - storage.オブジェクト.更新 + - ストレージ.buckets.get + - ストレージ.オブジェクト.作成 + - ストレージ.オブジェクト.削除 + - ストレージ.get + - ストレージ.オブジェクトリスト + - ストレージ.オブジェクト.更新 - ![Add permissions](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-assign-permission.png) + ![Add permissions](/media/tidb-cloud/changefeed/sink-to-cloud-ストレージ-gcs-assign-permission.png) -3. [バケツ](https://console.cloud.google.com/storage/browser)ページに移動し、 TiDB CloudがアクセスするGCSバケットを選択してください。GCSバケットは、TiDBクラスタと同じリージョンにある必要があります。 +3. [バケツ](https://console.cloud.google.com/ストレージ/browser)ページに移動し、 TiDB CloudがアクセスするGCSバケットを選択してください。GCSバケットは、TiDBクラスターと同じリージョンにある必要があります。 4. **バケットの詳細**ページで、 **[権限]**タブをクリックし、 **[アクセスを許可]**をクリックします。 - ![Grant Access to the bucket ](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-grant-access-1.png) + ![Grant Access to the bucket ](/media/tidb-cloud/changefeed/sink-to-cloud-ストレージ-gcs-grant-access-1.png) 5. バケットへのアクセスを許可するには、以下の情報を入力し、 **「保存」**をクリックしてください。 - - **「新しいプリンシパル」**フィールドに、以前に記録した対象のTiDBクラスタの**サービスアカウントID**を貼り付けます。 + - **「新しいプリンシパル」**フィールドに、以前に記録した対象のTiDBクラスターの**サービスアカウントID**を貼り付けます。 - **「役割を選択」ドロップ**ダウンリストに、先ほど作成したIAMロールの名前を入力し、フィルター結果からその名前を選択します。 @@ -114,11 +114,11 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl - バケットの gsutil URI を取得するには、[コピー] ボタンをクリックし、プレフィックスとして`gs://`を追加します。たとえば、バケット名が`test-sink-gcs`の場合、URI は`gs://test-sink-gcs/`になります。 - ![Get bucket URI](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-uri01.png) + ![Get bucket URI](/media/tidb-cloud/changefeed/sink-to-cloud-ストレージ-gcs-uri01.png) - フォルダの gsutil URI を取得するには、フォルダを開き、[コピー] ボタンをクリックし、プレフィックスとして`gs://`を追加します。たとえば、バケット名が`test-sink-gcs`で、フォルダ名が`changefeed-xxx`の場合、URI は`gs://test-sink-gcs/changefeed-xxx/`になります。 - ![Get bucket URI](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-uri02.png) + ![Get bucket URI](/media/tidb-cloud/changefeed/sink-to-cloud-ストレージ-gcs-uri02.png) 7. TiDB Cloudコンソールで、Changefeedの**宛先**ページに移動し、**バケットgsutil URI**フィールドに入力します。 @@ -129,19 +129,19 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl 1. [Azureポータル](https://portal.azure.com/)で、変更フィード データを保存するコンテナーを作成します。 - 1. 左側のナビゲーションペインで**「ストレージアカウント」**をクリックし、storageアカウントを選択します。 - 2. storageアカウントのナビゲーションメニューで、 **[データstorage]** > **[コンテナー]**を選択し、 **[+コンテナー]**をクリックします。 + 1. 左側のナビゲーションペインで**「ストレージアカウント」**をクリックし、ストレージアカウントを選択します。 + 2. ストレージアカウントのナビゲーションメニューで、 **[データストレージ]** > **[コンテナー]**を選択し、 **[+コンテナー]**をクリックします。 3. 新しいコンテナの名前を入力し、匿名アクセスレベルを設定します（推奨レベルは**プライベート**です）。次に、 **[作成]**をクリックします。 2. 対象コンテナのURLを取得します。 1. コンテナ一覧から、対象のコンテナを選択してください。 2. コンテナの**「…」**をクリックし、次に**「コンテナのプロパティ」**を選択します。 - 3. **URL**値を後で使用するために保存します。たとえば`https://.blob.core.windows.net/`のように保存します。 + 3. **URL**値を後で使用するために保存します。たとえば`https://<ストレージ_account>.blob.core.windows.net/`のように保存します。 3. SASトークンを生成します。 - 1. storageアカウントのナビゲーション メニューで、 **[Security+ ネットワーク]** > **[共有アクセス 署名]**を選択します。 + 1. ストレージアカウントのナビゲーション メニューで、 **[Security+ ネットワーク]** > **[共有アクセス 署名]**を選択します。 2. **「許可されたサービス」**セクションで、 **「Blob」**を選択します。 @@ -159,7 +159,7 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl 6. **「SASと接続文字列を生成」**をクリックし、 **SASトークン**を保存します。 - ![Generate a SAS token](/media/tidb-cloud/changefeed/sink-to-cloud-storage-azure-signature.png) + ![Generate a SAS token](/media/tidb-cloud/changefeed/sink-to-cloud-ストレージ-azure-signature.png) 4. [TiDB Cloudコンソール](https://tidbcloud.com/)で、Changefeed の**宛先**ページに移動し、次のフィールドに入力します。 @@ -214,7 +214,7 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl - **区切り文字**：CSVファイル内の値を区切る文字を指定します。最も一般的に使用される区切り文字はカンマ（ `,` ）です。 - **引用符**：区切り文字または特殊文字を含む値を囲むために使用する文字を指定します。通常、引用符には二重引用符（ `"` ）が使用されます。 - **null/空値**：CSVファイル内でnull値または空値がどのように表現されるかを指定します。これは、データの適切な処理と解釈のために重要です。 - - **コミットTを含める**：CSV行に[`commit-ts`](https://docs.pingcap.com/tidb/stable/ticdc-sink-to-cloud-storage#replicate-change-data-to-storage-services)を含めるかどうかを制御します。 + - **コミットTを含める**：CSV行に[`commit-ts`](https://docs.pingcap.com/tidb/stable/ticdc-sink-to-cloud-ストレージ#replicate-change-data-to-ストレージ-services)を含めるかどうかを制御します。
    @@ -232,11 +232,11 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl - **洗浄間隔**：デフォルトでは60秒に設定されていますが、2秒から10分の範囲で調整可能です。 - **ファイルサイズ**：デフォルトでは64MBに設定されていますが、1MBから512MBの範囲で調整可能です。 - ![Flush Parameters](/media/tidb-cloud/changefeed/sink-to-cloud-storage-flush-parameters.jpg) + ![Flush Parameters](/media/tidb-cloud/changefeed/sink-to-cloud-ストレージ-flush-parameters.jpg) > **注記：** > - > これら2つのパラメータは、各データベーステーブルごとにクラウドstorageに生成されるオブジェクトの数に影響します。テーブル数が多い場合、同じ設定を使用すると生成されるオブジェクトの数が増加し、結果としてクラウドstorageAPIの呼び出しコストが上昇します。そのため、リカバリポイント目標（RPO）とコスト要件に基づいて、これらのパラメータを適切に設定することをお勧めします。 + > これら2つのパラメータは、各データベーステーブルごとにクラウドストレージに生成されるオブジェクトの数に影響します。テーブル数が多い場合、同じ設定を使用すると生成されるオブジェクトの数が増加し、結果としてクラウドストレージAPIの呼び出しコストが上昇します。そのため、リカバリポイント目標（RPO）とコスト要件に基づいて、これらのパラメータを適切に設定することをお勧めします。 6. **[イベントの分割]**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)参照してください。 diff --git a/tidb-cloud/changefeed-sink-to-mysql.md b/tidb-cloud/changefeed-sink-to-mysql.md index e481d4af4fd47..7d87f506b7ce3 100644 --- a/tidb-cloud/changefeed-sink-to-mysql.md +++ b/tidb-cloud/changefeed-sink-to-mysql.md @@ -11,7 +11,7 @@ summary: このドキュメントでは、Sink to MySQL changefeed を使用し > **注記：** > -> 変更フィード機能を使用するには、 TiDB Cloud Dedicatedクラスタのバージョンがv6.1.3以降であることを確認してください。 +> 変更フィード機能を使用するには、 TiDB Cloud Dedicatedクラスターのバージョンがv6.1.3以降であることを確認してください。 @@ -87,7 +87,7 @@ TiDB Cloud PremiumインスタンスがMySQLサービスに接続できること -**Sink to MySQL**コネクタは、特定のタイムスタンプ以降の増分データのみをTiDB Cloud DedicatedクラスタからMySQLにシンクできます。TiDB Cloud Dedicatedクラスタに既にデータが存在する場合は、 **Sink to MySQL**を有効にする前に、 TiDB Cloud Dedicatedクラスタの既存データをエクスポートしてMySQLにロードすることができます。 +**Sink to MySQL**コネクタは、特定のタイムスタンプ以降の増分データのみをTiDB Cloud DedicatedクラスターからMySQLにシンクできます。TiDB Cloud Dedicatedクラスターに既にデータが存在する場合は、 **Sink to MySQL**を有効にする前に、 TiDB Cloud Dedicatedクラスターの既存データをエクスポートしてMySQLにロードすることができます。 diff --git a/tidb-cloud/changefeed-sink-to-tidb-cloud.md b/tidb-cloud/changefeed-sink-to-tidb-cloud.md index 75ed3afdbbfe9..4bb5790dd09d6 100644 --- a/tidb-cloud/changefeed-sink-to-tidb-cloud.md +++ b/tidb-cloud/changefeed-sink-to-tidb-cloud.md @@ -1,6 +1,6 @@ --- title: Sink to TiDB Cloud -summary: このドキュメントでは、TiDB Cloud DedicatedクラスタからTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにデータをストリーミングする方法について説明します。この機能で使用できる変更フィードとリージョンの数には制限があります。前提条件として、tidb_gc_life_time の拡張、データのバックアップ、およびTiDB Cloudシンクの開始位置の取得が必要です。TiDB Cloudシンクを作成するには、クラスタの概要ページに移動し、接続を確立し、テーブルとイベントのフィルタをカスタマイズし、レプリケーションの開始位置を入力し、変更フィードの仕様を指定し、構成を確認して、シンクを作成します。最後に、tidb_gc_life_time を元の値に戻します。 +summary: このドキュメントでは、TiDB Cloud DedicatedクラスターからTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにデータをストリーミングする方法について説明します。この機能で使用できる変更フィードとリージョンの数には制限があります。前提条件として、tidb_gc_life_time の拡張、データのバックアップ、およびTiDB Cloudシンクの開始位置の取得が必要です。TiDB Cloudシンクを作成するには、クラスターの概要ページに移動し、接続を確立し、テーブルとイベントのフィルタをカスタマイズし、レプリケーションの開始位置を入力し、変更フィードの仕様を指定し、構成を確認して、シンクを作成します。最後に、tidb_gc_life_time を元の値に戻します。 --- # TiDB Cloudにシンクする {#sink-to-tidb-cloud} @@ -9,7 +9,7 @@ summary: このドキュメントでは、TiDB Cloud Dedicatedクラスタから > **注記：** > -> Changefeed機能を使用するには、 TiDB Cloud Dedicatedクラスタのバージョンがv6.1.3以降であることを確認してください。 +> Changefeed機能を使用するには、 TiDB Cloud Dedicatedクラスターのバージョンがv6.1.3以降であることを確認してください。 ## 制限 {#restrictions} @@ -28,11 +28,11 @@ summary: このドキュメントでは、TiDB Cloud Dedicatedクラスタから - ソースとなるTiDB Cloud Dedicatedクラスターと、宛先となるTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスは、同じプロジェクトおよび同じリージョンに属している必要があります。 -- **TiDB Cloudへのシンク**機能は、プライベートエンドポイント経由のネットワーク接続のみをサポートしています。TiDB Cloud DedicatedクラスタからTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにデータをストリーミングするためのチェンジフィードを作成すると、 TiDB Cloudは2つのクラスタ間のプライベートエンドポイント接続を自動的に設定します。 +- **TiDB Cloudへのシンク**機能は、プライベートエンドポイント経由のネットワーク接続のみをサポートしています。TiDB Cloud DedicatedクラスターからTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにデータをストリーミングするためのチェンジフィードを作成すると、 TiDB Cloudは2つのクラスター間のプライベートエンドポイント接続を自動的に設定します。 ## 前提条件 {#prerequisites} -**TiDB Cloudへのシンク**コネクタは、特定の[TSO](https://docs.pingcap.com/tidb/stable/glossary#tso)の後、 TiDB Cloud DedicatedクラスタからTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに増分データをシンクすることのみが可能です。 +**TiDB Cloudへのシンク**コネクタは、特定の[TSO](https://docs.pingcap.com/tidb/stable/glossary#tso)の後、 TiDB Cloud DedicatedクラスターからTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに増分データをシンクすることのみが可能です。 変更フィードを作成する前に、ソースのTiDB Cloud Dedicatedクラスターから既存のデータをエクスポートし、そのデータを宛先のTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにロードする必要があります。 @@ -63,7 +63,7 @@ summary: このドキュメントでは、TiDB Cloud Dedicatedクラスタから 前提条件を満たしたら、データを宛先のTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにシンクできます。 -1. 対象のTiDBクラスタのクラスタ概要ページに移動し、左側のナビゲーションペインで**「データ」** > **「変更フィード」**をクリックします。 +1. 対象のTiDBクラスターのクラスター概要ページに移動し、左側のナビゲーションペインで**「データ」** > **「変更フィード」**をクリックします。 2. **「変更フィードを作成」**をクリックし、宛先として**「TiDB Cloud」**を選択します。 diff --git a/tidb-cloud/cli-reference.md b/tidb-cloud/cli-reference.md index 05681794bc2f4..a09382a8f7a19 100644 --- a/tidb-cloud/cli-reference.md +++ b/tidb-cloud/cli-reference.md @@ -7,7 +7,7 @@ summary: TiDB Cloud CLIの概要を説明します。 > **注記：** > -> 現在、 TiDB Cloud CLIはベータ版であり、 TiDB Cloud Dedicatedクラスタには適用できません。 +> 現在、 TiDB Cloud CLIはベータ版であり、 TiDB Cloud Dedicatedクラスターには適用できません。 TiDB Cloud CLIはコマンドラインインターフェースであり、ターミナルから数行のコマンドを入力するだけでTiDB Cloudを操作できます。TiDB Cloud CLIを使用すると、 TiDB Cloud StarterおよびEssentialインスタンスを簡単に管理したり、インスタンスにデータをインポートしたり、その他の操作を実行したりできます。 diff --git a/tidb-cloud/configure-external-storage-access.md b/tidb-cloud/configure-external-storage-access.md index 4edc6b28bc7f7..b3b0c75716c9a 100644 --- a/tidb-cloud/configure-external-storage-access.md +++ b/tidb-cloud/configure-external-storage-access.md @@ -1,14 +1,14 @@ --- title: Configure External Storage Access -summary: Amazon Simple Storage Service (Amazon S3) などの外部storageへのクロスアカウントアクセスを設定する方法を学びましょう。 -aliases: ['/ja/tidbcloud/serverless-external-storage'] +summary: Amazon Simple Storage Service (Amazon S3) などの外部ストレージへのクロスアカウントアクセスを設定する方法を学びましょう。 +aliases: ['/ja/tidbcloud/serverless-external-ストレージ'] --- -# 外部ストレージへのアクセスを構成する {#configure-external-storage-access} +# 外部ストレージへのアクセスを構成する {#configure-external-ストレージ-access} -TiDB Cloud Starter、 Essential 、またはPremiumインスタンスで外部storageからデータをインポートしたり、外部ストレージにデータをエクスポートしたりするには、アカウント間アクセスを設定する必要があります。このドキュメントでは、TiDB Cloud Starter、 TiDB Cloud Essential、およびTiDB Cloud Premiumインスタンスで外部storageへのアクセスを設定する方法について説明します。 +TiDB Cloud Starter、 Essential 、またはPremiumインスタンスで外部ストレージからデータをインポートしたり、外部ストレージにデータをエクスポートしたりするには、アカウント間アクセスを設定する必要があります。このドキュメントでは、TiDB Cloud Starter、 TiDB Cloud Essential、およびTiDB Cloud Premiumインスタンスで外部ストレージへのアクセスを設定する方法について説明します。 -TiDB Cloud Dedicatedクラスター用にこれらの外部ストレージを構成する必要がある場合は、 [TiDB Cloud Dedicatedの外部ストレージアクセスを構成する](/tidb-cloud/dedicated-external-storage.md)参照してください。 +TiDB Cloud Dedicatedクラスター用にこれらの外部ストレージを構成する必要がある場合は、 [TiDB Cloud Dedicatedの外部ストレージアクセスを構成する](/tidb-cloud/dedicated-external-ストレージ.md)参照してください。 ## Amazon S3へのアクセスを設定する {#configure-amazon-s3-access} @@ -71,7 +71,7 @@ TiDB Cloud Starter、 Essential、またはPremiumインスタンスがAmazon S3 5. CloudFormationスタックの実行後、 **[出力]**タブをクリックすると、 **[値]**列にロールARNの値が表示されます。 - ![Role ARN](/media/tidb-cloud/serverless-external-storage/serverless-role-arn.png) + ![Role ARN](/media/tidb-cloud/serverless-external-ストレージ/serverless-role-arn.png) AWS CloudFormationでロールARNを作成する際に問題が発生した場合は、以下の手順で手動で作成できます。 @@ -208,8 +208,8 @@ TiDB Cloud StarterまたはEssentialインスタンスがGCSバケットにア 4. `Grant this service account access to project`で、必要な権限を持つ[IAMロール](https://cloud.google.com/iam/docs/understanding-roles)を選択します。 - - TiDB Cloud StarterまたはEssentialインスタンスからデータをエクスポートするには`storage.objects.create`権限を持つロールが必要です。 - - TiDB Cloud StarterまたはEssentialインスタンスにデータをインポートするには`storage.buckets.get` 、 `storage.objects.get` 、および`storage.objects.list`権限を持つロールが必要です。 + - TiDB Cloud StarterまたはEssentialインスタンスからデータをエクスポートするには`ストレージ.objects.create`権限を持つロールが必要です。 + - TiDB Cloud StarterまたはEssentialインスタンスにデータをインポートするには`ストレージ.buckets.get` 、 `ストレージ.objects.get` 、および`ストレージ.objects.list`権限を持つロールが必要です。 5. 次のステップに進むには、 **「続行」**をクリックしてください。 @@ -217,11 +217,11 @@ TiDB Cloud StarterまたはEssentialインスタンスがGCSバケットにア 7. **「完了」**をクリックして、サービスアカウントの作成を完了してください。 - ![service-account](/media/tidb-cloud/serverless-external-storage/gcs-service-account.png) + ![service-account](/media/tidb-cloud/serverless-external-ストレージ/gcs-service-account.png) 2. サービスアカウントをクリックし、 `KEYS`ページで**[キーの追加]**をクリックして、サービスアカウントキーを作成します。 - ![service-account-key](/media/tidb-cloud/serverless-external-storage/gcs-service-account-key.png) + ![service-account-key](/media/tidb-cloud/serverless-external-ストレージ/gcs-service-account-key.png) 3. デフォルトのキータイプ`JSON`を選択し、 **[作成]**をクリックして Google Cloud 認証情報ファイルをダウンロードします。このファイルには、TiDB Cloud StarterまたはEssentialインスタンスの GCS アクセスを設定する際に使用する必要のあるサービス アカウント キーが含まれています。 @@ -229,7 +229,7 @@ TiDB Cloud StarterまたはEssentialインスタンスがGCSバケットにア -## Azure Blob Storageへのアクセスを構成する {#configure-azure-blob-storage-access} +## Azure Blob Storageへのアクセスを構成する {#configure-azure-blob-ストレージ-access} TiDB CloudがAzure Blobコンテナにアクセスできるようにするには、コンテナ用のサービスSASトークンを作成する必要があります。 @@ -276,9 +276,9 @@ Azure ARMテンプレートを使用してSASトークンを作成するには 2. Azureにログインすると、Azure**カスタムデプロイ**ページにリダイレクトされます。 - 3. **カスタムデプロイメント**ページで、**リソースグループ**と**ストレージアカウント名**を入力してください。コンテナが配置されているstorageアカウントの概要ページから、すべての情報を取得できます。 + 3. **カスタムデプロイメント**ページで、**リソースグループ**と**ストレージアカウント名**を入力してください。コンテナが配置されているストレージアカウントの概要ページから、すべての情報を取得できます。 - ![azure-storage-account-overview](/media/tidb-cloud/serverless-external-storage/azure-storage-account-overview.png) + ![azure-ストレージ-account-overview](/media/tidb-cloud/serverless-external-ストレージ/azure-ストレージ-account-overview.png) 4. デプロイメントを確認するには、 **「レビュー + 作成」**または**「次へ」**をクリックします。デプロイメントを開始するには、 **「作成」**をクリックします。 @@ -288,13 +288,13 @@ Azure ARMテンプレートを使用してSASトークンを作成する際に
    詳細はこちらをクリックしてください -1. [Azureストレージアカウント](https://portal.azure.com/#browse/Microsoft.Storage%2FStorageAccounts)ページで、コンテナーが属するstorageアカウントをクリックします。 +1. [Azureストレージアカウント](https://portal.azure.com/#browse/Microsoft.Storage%2FStorageAccounts)ページで、コンテナーが属するストレージアカウントをクリックします。 2. **ストレージアカウントの**ページで、[**Security]+ [ネットワーク]**をクリックし、 **[共有アクセス署名]**をクリックします。 - ![sas-position](/media/tidb-cloud/serverless-external-storage/azure-sas-position.png) + ![sas-position](/media/tidb-cloud/serverless-external-ストレージ/azure-sas-position.png) -3. **[共有アクセス署名]**ページで、次のように必要なアクセス許可を持つサービス SAS トークンを作成します。詳細については、 [サービスSASトークンを作成します](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview)参照してください。 +3. **[共有アクセス署名]**ページで、次のように必要なアクセス許可を持つサービス SAS トークンを作成します。詳細については、 [サービスSASトークンを作成します](https://docs.microsoft.com/en-us/azure/ストレージ/common/ストレージ-sas-overview)参照してください。 1. **「許可されたサービス」**セクションで、 **「Blob」**サービスを選択します。 @@ -309,7 +309,7 @@ Azure ARMテンプレートを使用してSASトークンを作成する際に 5. その他の設定については、デフォルト値をそのまま使用できます。 - ![sas-create](/media/tidb-cloud/serverless-external-storage/azure-sas-create.png) + ![sas-create](/media/tidb-cloud/serverless-external-ストレージ/azure-sas-create.png) 4. SASトークンを生成するには、 **「SASと接続文字列の生成」を**クリックしてください。 @@ -317,7 +317,7 @@ Azure ARMテンプレートを使用してSASトークンを作成する際に -## Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する {#configure-alibaba-cloud-object-storage-service-oss-access} +## Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する {#configure-alibaba-cloud-object-ストレージ-service-oss-access} TiDB CloudがAlibaba Cloud OSSバケットにアクセスできるようにするには、そのバケットのアクセスキーペアを作成する必要があります。 diff --git a/tidb-cloud/configure-ip-access-list.md b/tidb-cloud/configure-ip-access-list.md index 4afd22a8eecc9..79a20b48a7774 100644 --- a/tidb-cloud/configure-ip-access-list.md +++ b/tidb-cloud/configure-ip-access-list.md @@ -13,7 +13,7 @@ TiDB Cloudの各TiDB Cloud Dedicatedクラスターに対して、IP アクセ TiDB Cloud Dedicatedクラスターの IP アクセス リストを設定するには、次の手順を実行します。 -1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 > **ヒント：** > @@ -25,9 +25,9 @@ TiDB Cloud Dedicatedクラスターの IP アクセス リストを設定する 4. 表示されたダイアログで、以下のいずれかのオプションを選択してください。 - - **どこからでもアクセスを許可する**：すべてのIPアドレスからTiDB Cloudへのアクセスを許可します。このオプションを選択すると、TiDB Cloud Dedicatedクラスタが完全にインターネットに公開されるため、非常に危険です。 + - **どこからでもアクセスを許可する**：すべてのIPアドレスからTiDB Cloudへのアクセスを許可します。このオプションを選択すると、TiDB Cloud Dedicatedクラスターが完全にインターネットに公開されるため、非常に危険です。 - **IPアドレスを使用する**（推奨）：SQLクライアント経由でTiDB Cloudへのアクセスを許可するIPアドレスとCIDRアドレスのリストを追加できます。 -5. **「IPアドレスを使用する」**を選択した場合は、IPアドレスまたはCIDR範囲を追加し、必要に応じて説明を入力してください。TiDB Cloud Dedicatedクラスタごとに、最大100個のIPアドレスを追加できます。 +5. **「IPアドレスを使用する」**を選択した場合は、IPアドレスまたはCIDR範囲を追加し、必要に応じて説明を入力してください。TiDB Cloud Dedicatedクラスターごとに、最大100個のIPアドレスを追加できます。 6. 変更を保存するには、 **「確認」**をクリックしてください。 diff --git a/tidb-cloud/configure-maintenance-window.md b/tidb-cloud/configure-maintenance-window.md index 23a8ab45801e7..611e55355dada 100644 --- a/tidb-cloud/configure-maintenance-window.md +++ b/tidb-cloud/configure-maintenance-window.md @@ -26,7 +26,7 @@ summary: TiDB Cloud Dedicatedクラスターのメンテナンス ウィンド - クラスターを削除します - バックアップタスクを作成する - クラスターを復元する - - クラスタページにアクセスします + - クラスターページにアクセスします - 許可されていない操作: @@ -92,7 +92,7 @@ TiDB Cloudは、メンテナンス期間ごとに、以下のタイミングで - メンテナンス期間はどのくらいですか？ - 状況によります。各プロジェクトにおいて、対象となるTiDBクラスタに対して、メンテナンスは1つずつ実行されます。メンテナンスの所要時間は、クラスタの数、クラスタのデータサイズ、および実行されるメンテナンス作業によって異なります。 + 状況によります。各プロジェクトにおいて、対象となるTiDBクラスターに対して、メンテナンスは1つずつ実行されます。メンテナンスの所要時間は、クラスターの数、クラスターのデータサイズ、および実行されるメンテナンス作業によって異なります。 - どのような状態のクラスターに対しても、メンテナンス作業は実施されますか？ diff --git a/tidb-cloud/configure-security-settings.md b/tidb-cloud/configure-security-settings.md index c66184ff02819..71a9c9e3dd30b 100644 --- a/tidb-cloud/configure-security-settings.md +++ b/tidb-cloud/configure-security-settings.md @@ -3,9 +3,9 @@ title: Configure Cluster Password Settings summary: TiDB Cloud Dedicatedクラスターに接続するためのルートパスワードの設定方法を学びましょう。 --- -# クラスタパスワード設定の構成 {#configure-cluster-password-settings} +# クラスターパスワード設定の構成 {#configure-cluster-password-settings} -TiDB Cloud Dedicatedクラスタの場合、ルートパスワードと接続を許可するIPアドレスを設定できます。 +TiDB Cloud Dedicatedクラスターの場合、ルートパスワードと接続を許可するIPアドレスを設定できます。 > **注記：** > diff --git a/tidb-cloud/connect-to-tidb-cluster-serverless.md b/tidb-cloud/connect-to-tidb-cluster-serverless.md index 8f4c71f09666e..9a41e1df0ea63 100644 --- a/tidb-cloud/connect-to-tidb-cluster-serverless.md +++ b/tidb-cloud/connect-to-tidb-cluster-serverless.md @@ -9,7 +9,7 @@ summary: TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスにさ > **ヒント：** > -> - TiDB Cloud Dedicatedクラスターに接続する方法については、 [TiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/connect-to-tidb-cluster.md)を参照してください。 +> - TiDB Cloud Dedicatedクラスターに接続する方法については、 [TiDB Cloud Dedicatedクラスターに接続します](/tidb-cloud/connect-to-tidb-cluster.md)を参照してください。 > - このドキュメントでは、TiDB Cloud StarterおよびTiDB Cloud Essentialのネットワーク接続方法について説明します。特定のツール、ドライバ、または ORM を介して TiDB に接続する方法については、 [TiDBに接続する](/develop/dev-guide-connect-to-tidb.md)参照してください。 ## ネットワーク接続方法 {#network-connection-methods} @@ -60,4 +60,4 @@ TiDB Cloud StarterとTiDB Cloud Essentialには、2種類のネットワーク ## 次は？ {#what-s-next} -TiDB Cloud StarterまたはEssentialインスタンスに正常に接続したら、 [TiDBを使用してSQLステートメントを探索する](/basic-sql-operations.md)ことができます。 +TiDB Cloud StarterまたはEssentialインスタンスに正常に接続したら、 [TiDBでのSQL基本操作](/basic-sql-operations.md)ことができます。 diff --git a/tidb-cloud/connect-to-tidb-cluster.md b/tidb-cloud/connect-to-tidb-cluster.md index c544b6bc7650f..1085f8717bb19 100644 --- a/tidb-cloud/connect-to-tidb-cluster.md +++ b/tidb-cloud/connect-to-tidb-cluster.md @@ -3,16 +3,16 @@ title: Connect to Your TiDB Cloud Dedicated Cluster summary: さまざまな方法でTiDB Cloud Dedicatedクラスターに接続する方法を学びましょう。 --- -# TiDB Cloud Dedicatedクラスタに接続します {#connect-to-your-tidb-cloud-dedicated-cluster} +# TiDB Cloud Dedicatedクラスターに接続します {#connect-to-your-tidb-cloud-dedicated-cluster} -このドキュメントでは、TiDB Cloud Dedicatedクラスタへの接続方法について説明します。 +このドキュメントでは、TiDB Cloud Dedicatedクラスターへの接続方法について説明します。 > **ヒント：** > > - TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、 [TiDB Cloud StarterまたはEssentialインスタンスに接続します](/tidb-cloud/connect-to-tidb-cluster-serverless.md)参照してください。 > - このドキュメントでは、 TiDB Cloud Dedicatedのネットワーク接続方法について説明します。特定のツール、ドライバ、または ORM を介して TiDB に接続する方法については、 [TiDBに接続する](/develop/dev-guide-connect-to-tidb.md)参照してください。 -TiDB Cloud Dedicatedクラスタが作成されたら、以下のいずれかのネットワーク接続方法で接続できます。 +TiDB Cloud Dedicatedクラスターが作成されたら、以下のいずれかのネットワーク接続方法で接続できます。 - 直接接続 @@ -28,9 +28,9 @@ TiDB Cloud Dedicatedクラスタが作成されたら、以下のいずれかの プライベートエンドポイント接続は、VPC内のSQLクライアントがTiDB Cloud Dedicatedクラスターに安全にアクセスできるようにするためのプライベートエンドポイントを提供します。これは、さまざまなクラウドプロバイダーが提供するプライベートリンクサービスを利用しており、ネットワーク管理を簡素化しながら、データベースサービスへの高度に安全な一方向アクセスを実現します。 - - AWS でホストされているTiDB Cloud Dedicatedクラスターの場合、プライベート エンドポイント接続は AWS PrivateLink を使用します。詳細については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します。](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 - - Azure 上でホストされているTiDB Cloud Dedicatedクラスターの場合、プライベート エンドポイント接続は Azure Private Link を使用します。詳細については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)参照してください。 - - Google Cloud でホストされているTiDB Cloud Dedicatedクラスターの場合、プライベート エンドポイント接続は Google Cloud Private Service Connect を使用します。詳細については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します。](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)参照してください。 + - AWS でホストされているTiDB Cloud Dedicatedクラスターの場合、プライベート エンドポイント接続は AWS PrivateLink を使用します。詳細については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスターに接続します。](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 + - Azure 上でホストされているTiDB Cloud Dedicatedクラスターの場合、プライベート エンドポイント接続は Azure Private Link を使用します。詳細については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスターに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)参照してください。 + - Google Cloud でホストされているTiDB Cloud Dedicatedクラスターの場合、プライベート エンドポイント接続は Google Cloud Private Service Connect を使用します。詳細については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスターに接続します。](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)参照してください。 - [VPCピアリング](/tidb-cloud/set-up-vpc-peering-connections.md) @@ -40,7 +40,7 @@ TiDB Cloud Dedicatedクラスタが作成されたら、以下のいずれかの > **注記：** > - > [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタでSQLエディタを使用するには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 + > [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでSQLエディタを使用するには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 クラスターがAWS上でホストされており、クラスターのTiDBバージョンがv6.5.0以降である場合、 [TiDB Cloudコンソール](https://tidbcloud.com/)のAI支援SQLエディタを使用して、データの価値を最大化できます。 @@ -48,4 +48,4 @@ TiDB Cloud Dedicatedクラスタが作成されたら、以下のいずれかの ## 次は？ {#what-s-next} -TiDB クラスターに正常に接続したら、 [TiDBを使用してSQLステートメントを探索する](/basic-sql-operations.md)ことができます。 +TiDB クラスターに正常に接続したら、 [TiDBでのSQL基本操作](/basic-sql-operations.md)ことができます。 diff --git a/tidb-cloud/connect-via-sql-shell.md b/tidb-cloud/connect-via-sql-shell.md index d5616fc38c6de..b8178a0d94e5f 100644 --- a/tidb-cloud/connect-via-sql-shell.md +++ b/tidb-cloud/connect-via-sql-shell.md @@ -1,6 +1,6 @@ --- title: Connect via SQL Shell -summary: SQLシェルを使用してTiDBクラスタに接続する方法を学びましょう。 +summary: SQLシェルを使用してTiDBクラスターに接続する方法を学びましょう。 --- # SQL Shell経由で接続する {#connect-via-sql-shell} @@ -23,4 +23,4 @@ SQLシェルを使用してTiDBに接続するには、以下の手順を実行 3. **ネットワーク**ページで、右上隅にある**「Web SQL Shell」**をクリックします。 -4. **「パスワードを入力してください**」というプロンプトが表示されたら、現在のクラスタのrootパスワードを入力してください。これで、アプリケーションがTiDBクラスタに接続されます。 +4. **「パスワードを入力してください**」というプロンプトが表示されたら、現在のクラスターのrootパスワードを入力してください。これで、アプリケーションがTiDBクラスターに接続されます。 diff --git a/tidb-cloud/connect-via-standard-connection-serverless.md b/tidb-cloud/connect-via-standard-connection-serverless.md index 8a03106964d0b..3f9ebadc8661c 100644 --- a/tidb-cloud/connect-via-standard-connection-serverless.md +++ b/tidb-cloud/connect-via-standard-connection-serverless.md @@ -80,4 +80,4 @@ TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスのパブリッ ## 次は？ {#what-s-next} -TiDB Cloud StarterまたはEssentialインスタンスに正常に接続したら、 [TiDBを使用してSQLステートメントを探索する](/basic-sql-operations.md)ことができます。 +TiDB Cloud StarterまたはEssentialインスタンスに正常に接続したら、 [TiDBでのSQL基本操作](/basic-sql-operations.md)ことができます。 diff --git a/tidb-cloud/connect-via-standard-connection.md b/tidb-cloud/connect-via-standard-connection.md index f8b32f414bebe..7cb4b87765bdd 100644 --- a/tidb-cloud/connect-via-standard-connection.md +++ b/tidb-cloud/connect-via-standard-connection.md @@ -19,7 +19,7 @@ summary: パブリック接続を使用してTiDB Cloudクラスターに接続 パブリック接続を介してTiDB Cloud Dedicatedクラスターに接続するには、以下の手順を実行してください。 -1. 対象のTiDB Cloud Dedicatedクラスタの概要ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスターの概要ページを開きます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動します。 @@ -41,4 +41,4 @@ summary: パブリック接続を使用してTiDB Cloudクラスターに接続 ## 次は？ {#what-s-next} -TiDB クラスターに正常に接続したら、 [TiDBを使用してSQLステートメントを探索する](/basic-sql-operations.md)ことができます。 +TiDB クラスターに正常に接続したら、 [TiDBでのSQL基本操作](/basic-sql-operations.md)ことができます。 diff --git a/tidb-cloud/create-tidb-cluster-serverless.md b/tidb-cloud/create-tidb-cluster-serverless.md index 2851981316831..5548a8d135551 100644 --- a/tidb-cloud/create-tidb-cluster-serverless.md +++ b/tidb-cloud/create-tidb-cluster-serverless.md @@ -9,7 +9,7 @@ summary: TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスの作 > **ヒント：** > -> TiDB Cloud Dedicatedクラスターを作成する方法については、 [TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 +> TiDB Cloud Dedicatedクラスターを作成する方法については、 [TiDB Cloud Dedicatedクラスターを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 ## 始める前に {#before-you-begin} diff --git a/tidb-cloud/create-tidb-cluster.md b/tidb-cloud/create-tidb-cluster.md index fd3fe68123894..10c9a844bc0b6 100644 --- a/tidb-cloud/create-tidb-cluster.md +++ b/tidb-cloud/create-tidb-cluster.md @@ -3,7 +3,7 @@ title: Create a TiDB Cloud Dedicated Cluster summary: TiDB Cloud Dedicatedクラスターの作成方法を学びましょう。 --- -# TiDB Cloud Dedicatedクラスタを作成する {#create-a-tidb-cloud-dedicated-cluster} +# TiDB Cloud Dedicatedクラスターを作成する {#create-a-tidb-cloud-dedicated-cluster} このチュートリアルでは、TiDB Cloud Dedicatedクラスターへのサインアップと作成の手順を説明します。 @@ -20,7 +20,7 @@ TiDB Cloudアカウントをお持ちでない場合は、[ここ](https://tidbc - Azure Marketplace をご利用の方は、Azure Marketplace からサインアップすることもできます。サインアップするには、 [Azure Marketplace](https://azuremarketplace.microsoft.com)で`TiDB Cloud`を検索し、 TiDB Cloudを購読してから、画面の指示に従ってTiDB Cloudアカウントを設定してください。 - Google Cloud Marketplace をご利用の方は、Google Cloud Marketplace からサインアップすることもできます。サインアップするには、 [Google Cloud Marketplace](https://console.cloud.google.com/marketplace)で`TiDB Cloud`を検索し、 TiDB Cloudを購読してから、画面の指示に従ってTiDB Cloudアカウントを設定してください。 -## ステップ1. TiDB Cloud Dedicatedクラスタを作成する {#step-1-create-a-tidb-cloud-dedicated-cluster} +## ステップ1. TiDB Cloud Dedicatedクラスターを作成する {#step-1-create-a-tidb-cloud-dedicated-cluster} `Organization Owner`または`Project Owner`の役割を担っている場合は、次のようにしてTiDB Cloud Dedicatedクラスターを作成できます。 @@ -32,7 +32,7 @@ TiDB Cloudアカウントをお持ちでない場合は、[ここ](https://tidbc 2. **「リソースの作成」を**クリックします。 -3. **「リソースの作成」**ページで**「Dedicated」**を選択し、クラスタ情報を次のように構成します。 +3. **「リソースの作成」**ページで**「Dedicated」**を選択し、クラスター情報を次のように構成します。 1. TiDB Cloud Dedicatedクラスターのプロジェクトを選択してください。組織内にプロジェクトがない場合は、 **「プロジェクトの作成」を**クリックして作成できます。 @@ -67,7 +67,7 @@ TiDB Cloudアカウントをお持ちでない場合は、[ここ](https://tidbc 6. **「作成」**をクリックします。 - TiDB Cloudクラスタの作成には約20～30分かかります。作成が完了すると、 TiDB Cloudコンソールから通知が届きます。 + TiDB Cloudクラスターの作成には約20～30分かかります。作成が完了すると、 TiDB Cloudコンソールから通知が届きます。 > **注記：** > @@ -85,4 +85,4 @@ TiDB Cloud Dedicatedクラスターの作成が完了したら、以下の手順 ## 次は？ {#what-s-next} -TiDB Cloud DedicatedクラスターがTiDB Cloud上に作成されたら、 [TiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/connect-to-tidb-cluster.md)に接続します」で提供されている方法を介してそれに接続できます。 +TiDB Cloud DedicatedクラスターがTiDB Cloud上に作成されたら、 [TiDB Cloud Dedicatedクラスターに接続します](/tidb-cloud/connect-to-tidb-cluster.md)に接続します」で提供されている方法を介してそれに接続できます。 diff --git a/tidb-cloud/csv-config-for-import-data.md b/tidb-cloud/csv-config-for-import-data.md index 8e6db7aca8e50..3d79801e3a003 100644 --- a/tidb-cloud/csv-config-for-import-data.md +++ b/tidb-cloud/csv-config-for-import-data.md @@ -7,7 +7,7 @@ summary: TiDB Cloudのインポート データ サービスで CSV 構成を使 このドキュメントでは、 TiDB Cloudの Import Data サービスの CSV 構成について説明します。 -以下は、 TiDB Cloudのデータインポートサービスを使用してCSVファイルをインポートする際のCSVコンフィグレーションウィンドウです。詳細については、 [クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)参照してください。 +以下は、 TiDB Cloudのデータインポートサービスを使用してCSVファイルをインポートする際のCSV設定ウィンドウです。詳細については、 [クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)参照してください。 diff --git a/tidb-cloud/data-service-api-key.md b/tidb-cloud/data-service-api-key.md index 52f7c1bdc7a1a..db7697fad7058 100644 --- a/tidb-cloud/data-service-api-key.md +++ b/tidb-cloud/data-service-api-key.md @@ -12,7 +12,7 @@ TiDB Cloud Data API は[基本認証](https://en.wikipedia.org/wiki/Basic_access > **注記：** > -> データサービスで使用されるデータAPIキーは、 [TiDB CloudAPI](https://docs.pingcap.com/tidbcloud/api/v1beta#section/Authentication)で使用されるキーとは異なります。データAPIキーはTiDB内のデータにアクセスするために使用されますが、 TiDB Cloud APIキーはプロジェクト、クラスタ、バックアップ、リストア、インポートなどのリソースを管理するために使用されます。 +> データサービスで使用されるデータAPIキーは、 [TiDB CloudAPI](https://docs.pingcap.com/tidbcloud/api/v1beta#section/Authentication)で使用されるキーとは異なります。データAPIキーはTiDB内のデータにアクセスするために使用されますが、 TiDB Cloud APIキーはプロジェクト、クラスター、バックアップ、リストア、インポートなどのリソースを管理するために使用されます。 ## APIキーの概要 {#api-key-overview} diff --git a/tidb-cloud/data-service-app-config-files.md b/tidb-cloud/data-service-app-config-files.md index 100aca7e8f084..25ecc4f58bba8 100644 --- a/tidb-cloud/data-service-app-config-files.md +++ b/tidb-cloud/data-service-app-config-files.md @@ -3,7 +3,7 @@ title: Data App Configuration Files summary: このドキュメントでは、TiDB Cloudのデータ アプリの構成ファイルについて説明します。 --- -# データアプリコンフィグレーションファイル {#data-app-configuration-files} +# データアプリ設定ファイル {#data-app-configuration-files} このドキュメントでは、TiDB Cloudの[データアプリ](/tidb-cloud/tidb-cloud-glossary.md#data-app)の構成ファイルについて説明します。 diff --git a/tidb-cloud/data-service-concepts.md b/tidb-cloud/data-service-concepts.md index 8c6280a19a3ab..b71efb08a7f06 100644 --- a/tidb-cloud/data-service-concepts.md +++ b/tidb-cloud/data-service-concepts.md @@ -37,9 +37,9 @@ TiDB Cloudの Chat2Query API は、AI が指示を与えることで SQL 文を 詳細については[データアプリをサードパーティツールと統合する](/tidb-cloud/data-service-integrations.md)参照してください。 -## コードとしてのコンフィグレーション {#configuration-as-code} +## コードとしての設定 {#configuration-as-code} -TiDB Cloud は、 JSON 構文を使用してデータ アプリの構成全体をコードとして表現する、 コンフィグレーション as Code (CaC) アプローチを提供します。 +TiDB Cloud は、 JSON 構文を使用してデータ アプリの構成全体をコードとして表現する、 設定 as Code (CaC) アプローチを提供します。 データ アプリを GitHub に接続することで、 TiDB Cloud はCaC アプローチを使用して、データ アプリの構成を[設定ファイル](/tidb-cloud/data-service-app-config-files.md)として優先 GitHub リポジトリおよびブランチにプッシュできます。 diff --git a/tidb-cloud/data-service-integrations.md b/tidb-cloud/data-service-integrations.md index 67c09f8c8ad23..fcdbc165825e6 100644 --- a/tidb-cloud/data-service-integrations.md +++ b/tidb-cloud/data-service-integrations.md @@ -19,7 +19,7 @@ summary: TiDB Cloudコンソールで、 TiDB CloudデータアプリをGPTやDi 2. 左側のペインで、対象のデータアプリを見つけ、対象のデータアプリの名前をクリックし、次に**「統合」**タブをクリックします。 -3. **「GPTとの統合」**領域で、 **「コンフィグレーションを取得」**をクリックします。 +3. **「GPTとの統合」**領域で、 **「設定を取得」**をクリックします。 ![Get Configuration](/media/tidb-cloud/data-service/GPTs1.png) @@ -39,4 +39,4 @@ summary: TiDB Cloudコンソールで、 TiDB CloudデータアプリをGPTやDi データアプリを[ダイファイ](https://dify.ai/)と統合することで、ベクトル距離計算、高度な類似性検索、ベクトル解析などのインテリジェントな機能を追加し、アプリケーションを強化できます。 -データアプリをDifyと連携させるには、 [GPT統合](#integrate-your-data-app-with-gpts)の場合と同じ手順に従ってください。唯一の違いは、 **[連携]**タブの**[Difyとの連携]**エリアで**[コンフィグレーションを取得]を**クリックする必要がある点です。 +データアプリをDifyと連携させるには、 [GPT統合](#integrate-your-data-app-with-gpts)の場合と同じ手順に従ってください。唯一の違いは、 **[連携]**タブの**[Difyとの連携]**エリアで**[設定を取得]を**クリックする必要がある点です。 diff --git a/tidb-cloud/data-service-manage-data-app.md b/tidb-cloud/data-service-manage-data-app.md index 6a4f5d234fae4..16b0b1df989b2 100644 --- a/tidb-cloud/data-service-manage-data-app.md +++ b/tidb-cloud/data-service-manage-data-app.md @@ -69,7 +69,7 @@ Data Service（ベータ版）のデータアプリは、特定のアプリケ 1. プロジェクトの[**データサービス**](https://tidbcloud.com/project/data-service)ページに移動します。 2. 左側のペインで、対象のデータ アプリを見つけ、対象のデータ アプリの名前をクリックして詳細を表示します。 -3. **[リンクされたデータ ソース]**領域で、 **[クラスタの追加] を**クリックします。 +3. **[リンクされたデータ ソース]**領域で、 **[クラスターの追加] を**クリックします。 4. 表示されたダイアログボックスで、リストからクラスターを選択し、 **「追加」**をクリックします。 データ アプリからリンクされたクラスターを削除するには、次の手順を実行します。 @@ -101,7 +101,7 @@ Data Service（ベータ版）のデータアプリは、特定のアプリケ 2. 左側のペインで、対象のデータ アプリを見つけ、対象のデータ アプリの名前をクリックして詳細を表示します。 -3. **「デプロイメントコンフィグレーション」**領域で、 **「構成」**をクリックします。デプロイメント構成のダイアログが表示されます。 +3. **「デプロイメント設定」**領域で、 **「構成」**をクリックします。デプロイメント構成のダイアログが表示されます。 4. ダイアログで、**自動同期とデプロイメント**と**ドラフトの確認**の希望の設定を選択します。 diff --git a/tidb-cloud/data-service-manage-github-connection.md b/tidb-cloud/data-service-manage-github-connection.md index 3a40e63a83d4d..446478337891e 100644 --- a/tidb-cloud/data-service-manage-github-connection.md +++ b/tidb-cloud/data-service-manage-github-connection.md @@ -5,7 +5,7 @@ summary: GitHubを使ってデータアプリを自動的にデプロイする # GitHub を使用してデータアプリを自動的にデプロイ {#deploy-data-app-automatically-with-github} -TiDB Cloudは、 JSON構文を使用してデータアプリの構成全体をコードとして表現する、コンフィグレーションコード（CaC）アプローチを提供します。 +TiDB Cloudは、 JSON構文を使用してデータアプリの構成全体をコードとして表現する、設定コード（CaC）アプローチを提供します。 データアプリをGitHubに接続することで、 TiDB CloudはCaC方式を使用し、データアプリの設定を[設定ファイル](/tidb-cloud/data-service-app-config-files.md)として、指定したGitHubリポジトリとブランチにプッシュできます。 diff --git a/tidb-cloud/data-service-overview.md b/tidb-cloud/data-service-overview.md index 21a173eec2f83..e42e717ea9bbf 100644 --- a/tidb-cloud/data-service-overview.md +++ b/tidb-cloud/data-service-overview.md @@ -19,7 +19,7 @@ Data Service のエンドポイントは、SQL 文を実行するためにカス > **ヒント：** > -> TiDB Cloudは、TiDBクラスタ用のChat2Query APIを提供します。有効にすると、 TiDB Cloudは自動的に**Chat2Query**と呼ばれるシステムデータアプリと、データサービスにChat2Dataエンドポイントを作成します。このエンドポイントを呼び出すことで、AIが指示を与えるだけでSQL文を生成・実行できるようになります。 +> TiDB Cloudは、TiDBクラスター用のChat2Query APIを提供します。有効にすると、 TiDB Cloudは自動的に**Chat2Query**と呼ばれるシステムデータアプリと、データサービスにChat2Dataエンドポイントを作成します。このエンドポイントを呼び出すことで、AIが指示を与えるだけでSQL文を生成・実行できるようになります。 > > 詳細については[Chat2Query APIを使い始める](/tidb-cloud/use-chat2query-api.md)参照してください。 diff --git a/tidb-cloud/data-streaming-concepts.md b/tidb-cloud/data-streaming-concepts.md index 3940efda70261..05f8328f554ad 100644 --- a/tidb-cloud/data-streaming-concepts.md +++ b/tidb-cloud/data-streaming-concepts.md @@ -5,9 +5,9 @@ summary: TiDB Cloudのデータ ストリーミングの概念について学習 # データストリーミング {#data-streaming} -TiDB Cloud を使用すると、TiDB クラスタからのデータ変更を Kafka、MySQL、オブジェクトstorageなどの他のシステムにストリーミングできます。 +TiDB Cloud を使用すると、TiDB クラスターからのデータ変更を Kafka、MySQL、オブジェクトストレージなどの他のシステムにストリーミングできます。 -現在、 TiDB Cloud は、Apache Kafka、MySQL、 TiDB Cloud、クラウドstorageへのストリーミング データをサポートしています。 +現在、 TiDB Cloud は、Apache Kafka、MySQL、 TiDB Cloud、クラウドストレージへのストリーミング データをサポートしています。 ## チェンジフィード {#changefeed} diff --git a/tidb-cloud/database-schema-concepts.md b/tidb-cloud/database-schema-concepts.md index 43c9454c33c64..cdd398d669a89 100644 --- a/tidb-cloud/database-schema-concepts.md +++ b/tidb-cloud/database-schema-concepts.md @@ -67,7 +67,7 @@ TiDB を使用すると、JSON データ型から[生成された列](/generated 一般的な列とは異なり、生成された列の値は列定義内の式によって計算されます。生成された列を挿入または更新する場合、値を割り当てることはできず、 `DEFAULT`のみを使用できます。 -生成列には、仮想生成列と格納生成列の2種類があります。仮想生成列はstorageを占有せず、読み取り時に計算されます。格納生成列は書き込み時（挿入または更新時）に計算され、storageを占有します。仮想生成列と比較すると、格納生成列は読み取りパフォーマンスが優れていますが、より多くのディスク容量を消費します。 +生成列には、仮想生成列と格納生成列の2種類があります。仮想生成列はストレージを占有せず、読み取り時に計算されます。格納生成列は書き込み時（挿入または更新時）に計算され、ストレージを占有します。仮想生成列と比較すると、格納生成列は読み取りパフォーマンスが優れていますが、より多くのディスク容量を消費します。 ## データ型 {#data-types} @@ -103,7 +103,7 @@ TiDB v8.0.0以降では、 [`tidb_opt_use_invisible_indexes`](/system-variables. ### クラスター化インデックス {#clustered-indexes} -クラスタ化インデックスにおいて、「クラスタ化」という用語は、データの格納方法の構成を指し、連携して動作するデータベースサーバーのグループを指すものではありません。一部のデータベース管理システムでは、クラスタ化インデックスをインデックス構成テーブル（IOT）と呼んでいます。 +クラスター化インデックスにおいて、「クラスター化」という用語は、データの格納方法の構成を指し、連携して動作するデータベースサーバーのグループを指すものではありません。一部のデータベース管理システムでは、クラスター化インデックスをインデックス構成テーブル（IOT）と呼んでいます。 この機能は、主キーを含むテーブルへのデータの格納方法を制御します。これにより、TiDBは特定のクエリのパフォーマンスを向上させるような方法でテーブルを整理できるようになります。 @@ -125,7 +125,7 @@ TiDB では、 [既存のテーブルにセカンダリインデックスを追 TiDBでは、ベクトルインデックスは、ベクトルデータを含む列に対して効率的な近似最近傍（ANN）検索を行うために設計された特殊なインデックスです。ベクトルインデックス、特にHNSW（階層型ナビゲート可能スモールワールド）アルゴリズムは、K近傍（KNN）検索によってベクトル空間内の最も近いデータポイントを迅速に特定することを可能にします。これによりクエリのパフォーマンスが大幅に向上し、総当たり検索に比べてミリ秒単位で結果が得られます。 -ベクター インデックスは、データstorageと検索機能をTiFlashレプリカに依存します。 TiDB Cloud Dedicatedクラスターを使用している場合は、ベクター インデックスを作成または使用する前に、クラスター内でTiFlashノードが利用可能であることを確認してください。詳細については、[ベクトル検索インデックス](/ai/reference/vector-search-index.md)参照してください。 +ベクター インデックスは、データストレージと検索機能をTiFlashレプリカに依存します。 TiDB Cloud Dedicatedクラスターを使用している場合は、ベクター インデックスを作成または使用する前に、クラスター内でTiFlashノードが利用可能であることを確認してください。詳細については、[ベクトル検索インデックス](/ai/reference/vector-search-index.md)参照してください。 ## 制約 {#constraints} @@ -157,7 +157,7 @@ TiDBはバージョン6.6.0以降、実験的機能として外部キー制約 詳細については、[外部キー制約](/foreign-key.md)を参照してください。 -## 閲覧数 {#views} +## ビュー {#views} ビューは仮想テーブルとして機能し、そのスキーマはビューを作成する`SELECT`ステートメントによって定義されます。ビューを使用することには、次のような利点があります。 @@ -165,7 +165,7 @@ TiDBはバージョン6.6.0以降、実験的機能として外部キー制約 - 複雑なクエリをより簡単かつ便利にするために、ビューとして頻繁に出現する複雑なクエリを定義する。 -詳細については、[閲覧数](/views.md)を参照してください。 +詳細については、[ビュー](/views.md)を参照してください。 ## シーケンス {#sequence} diff --git a/tidb-cloud/dedicated-external-storage.md b/tidb-cloud/dedicated-external-storage.md index 48f4de48c3af7..ee1b013035134 100644 --- a/tidb-cloud/dedicated-external-storage.md +++ b/tidb-cloud/dedicated-external-storage.md @@ -4,11 +4,11 @@ summary: Amazon Simple Storage Service (Amazon S3)、Google Cloud Storage (GCS) aliases: ['/ja/tidb-cloud/config-s3-and-gcs-access'] --- -# TiDB Cloud Dedicatedの外部ストレージアクセスを構成する {#configure-external-storage-access-for-tidb-cloud-dedicated} +# TiDB Cloud Dedicatedの外部ストレージアクセスを構成する {#configure-external-ストレージ-access-for-tidb-cloud-dedicated} ソースデータがAmazon S3バケット、Azure Blob Storageコンテナ、またはGoogle Cloud Storage（GCS）バケットに保存されている場合、データをTiDB Cloudにインポートまたは移行する前に、バケットへのクロスアカウントアクセスを設定する必要があります。このドキュメントでは、TiDB Cloud Dedicatedクラスターでこの設定を行う方法について説明します。 -TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンス用にこれらの外部ストレージを構成する必要がある場合は、 [TiDB Cloud StarterまたはEssentialの外部ストレージアクセスを設定する](/tidb-cloud/configure-external-storage-access.md)を参照してください。 +TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンス用にこれらの外部ストレージを構成する必要がある場合は、 [TiDB Cloud StarterまたはEssentialの外部ストレージアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md)を参照してください。 ## Amazon S3へのアクセスを設定する {#configure-amazon-s3-access} @@ -119,7 +119,7 @@ TiDB Cloudのバケットアクセスを設定し、以下の手順でロールA - **「信頼できるエンティティの種類」**で**「AWS アカウント」**を選択します。 - **「AWSアカウント」**の下にある**「別のAWSアカウント」**を選択し、 TiDB CloudアカウントIDを**「アカウントID」**フィールドに貼り付けます。 - - **「オプション」**で**「外部IDを必須にする」**をクリックして[混乱した副官の問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)回避し、 TiDB Cloud外部IDを「**外部ID」**フィールドに貼り付けます。「外部IDを必須にする」を選択せず​​にロールを作成すると、S3バケットURIとIAMロールARNを持つユーザーであれば誰でもAmazon S3バケットにアクセスできる可能性があります。アカウントIDと外部IDの両方を使用してロールを作成すると、同じプロジェクトおよび同じリージョンで実行されているTiDBクラスタのみがバケットにアクセスできます。 + - **「オプション」**で**「外部IDを必須にする」**をクリックして[混乱した副官の問題](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)回避し、 TiDB Cloud外部IDを「**外部ID」**フィールドに貼り付けます。「外部IDを必須にする」を選択せず​​にロールを作成すると、S3バケットURIとIAMロールARNを持つユーザーであれば誰でもAmazon S3バケットにアクセスできる可能性があります。アカウントIDと外部IDの両方を使用してロールを作成すると、同じプロジェクトおよび同じリージョンで実行されているTiDBクラスターのみがバケットにアクセスできます。 3. **「次へ」**をクリックしてポリシー一覧を開き、先ほど作成したポリシーを選択してから**「次へ」**をクリックします。 @@ -156,7 +156,7 @@ TiDB Cloudのバケットアクセスを設定し、以下の手順でロールA ## GCSへのアクセスを設定する {#configure-gcs-access} -TiDB CloudがGCSバケット内のソースデータにアクセスできるようにするには、バケットのGCSアクセスを設定する必要があります。プロジェクト内の1つのTiDBクラスタの設定が完了すると、そのプロジェクト内のすべてのTiDBクラスタがGCSバケットにアクセスできるようになります。 +TiDB CloudがGCSバケット内のソースデータにアクセスできるようにするには、バケットのGCSアクセスを設定する必要があります。プロジェクト内の1つのTiDBクラスターの設定が完了すると、そのプロジェクト内のすべてのTiDBクラスターがGCSバケットにアクセスできるようになります。 1. TiDB Cloudコンソールで、対象のTiDBクラスターのGoogle CloudサービスアカウントIDを取得します。 @@ -166,7 +166,7 @@ TiDB CloudがGCSバケット内のソースデータにアクセスできるよ > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 - 2. 対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**「データ」** > **「インポート」**をクリックします。 + 2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**「データ」** > **「インポート」**をクリックします。 3. **「クラウドストレージからデータをインポート」**をクリックします。 @@ -186,15 +186,15 @@ TiDB CloudがGCSバケット内のソースデータにアクセスできるよ 5. ロールに以下の読み取り専用権限を追加し、 **[追加]**をクリックします。 - - storage.buckets.get - - storage.get - - storage.オブジェクトリスト + - ストレージ.buckets.get + - ストレージ.get + - ストレージ.オブジェクトリスト 権限名をフィルタークエリとして**「プロパティ名または値を入力」**フィールドにコピーし、フィルター結果からその名前を選択できます。3つの権限を追加するには、権限名の間に**OR演算子**を使用します。 ![Add permissions](/media/tidb-cloud/gcp-add-permissions.png) -3. [バケツ](https://console.cloud.google.com/storage/browser)ページに移動し、 TiDB CloudがアクセスするGCSバケットの名前をクリックします。 +3. [バケツ](https://console.cloud.google.com/ストレージ/browser)ページに移動し、 TiDB CloudがアクセスするGCSバケットの名前をクリックします。 4. **バケットの詳細**ページで、 **[権限]**タブをクリックし、 **[アクセス権の付与]**をクリックします。 @@ -224,17 +224,17 @@ TiDB CloudがGCSバケット内のソースデータにアクセスできるよ 7. TiDB Cloudコンソールで、Google Cloud Service アカウント ID を取得する**データインポート**ページに移動し、GCS バケットの gsutil URI を**バケット gsutil URI**フィールドに貼り付けます。たとえば、 `gs://tidb-cloud-source-data/`を貼り付けます。 -## Azure Blob Storageへのアクセスを構成する {#configure-azure-blob-storage-access} +## Azure Blob Storageへのアクセスを構成する {#configure-azure-blob-ストレージ-access} TiDB Cloud DedicatedがAzure Blobコンテナにアクセスできるようにするには、コンテナのAzure Blobアクセスを設定する必要があります。アカウントSASトークンを使用してコンテナアクセスを設定できます。 -1. [Azureストレージアカウント](https://portal.azure.com/#browse/Microsoft.Storage%2FStorageAccounts)ページで、コンテナーが属するstorageアカウントをクリックします。 +1. [Azureストレージアカウント](https://portal.azure.com/#browse/Microsoft.Storage%2FStorageAccounts)ページで、コンテナーが属するストレージアカウントをクリックします。 -2. storageアカウントのナビゲーション ペインで、 **[Security+ ネットワーク]** > **[共有アクセス 署名]**をクリックします。 +2. ストレージアカウントのナビゲーション ペインで、 **[Security+ ネットワーク]** > **[共有アクセス 署名]**をクリックします。 - ![sas-position](/media/tidb-cloud/dedicated-external-storage/azure-sas-position.png) + ![sas-position](/media/tidb-cloud/dedicated-external-ストレージ/azure-sas-position.png) -3. **[共有アクセス署名]**ページで、次のように必要な権限を持つ[アカウントSASトークン](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview)を作成します。 +3. **[共有アクセス署名]**ページで、次のように必要な権限を持つ[アカウントSASトークン](https://docs.microsoft.com/en-us/azure/ストレージ/common/ストレージ-sas-overview)を作成します。 1. **「許可されたサービス」**で**「Blob」**を選択します。 2. **「許可されるリソースの種類」**で、 **「コンテナ」**と**「オブジェクト」**を選択します。 @@ -242,7 +242,7 @@ TiDB Cloud DedicatedがAzure Blobコンテナにアクセスできるように 4. 必要に応じて**開始日時と有効期限日時**を調整してください。セキュリティ上の理由から、有効期限はデータインポートのスケジュールに合わせて設定することをお勧めします。 5. その他の設定については、デフォルト値を維持してください。 - ![sas-create](/media/tidb-cloud/dedicated-external-storage/azure-sas-create.png) + ![sas-create](/media/tidb-cloud/dedicated-external-ストレージ/azure-sas-create.png) 4. SASトークンを生成するには、 **「SASと接続文字列の生成」を**クリックしてください。 diff --git a/tidb-cloud/dedicated/_index.md b/tidb-cloud/dedicated/_index.md index 088c37cc6af20..636d1c9ed49f8 100644 --- a/tidb-cloud/dedicated/_index.md +++ b/tidb-cloud/dedicated/_index.md @@ -42,17 +42,17 @@ summary: TiDB Cloudは、TiDBの優れた機能すべてをクラウドに提供 -[クラスタを作成する](https://docs.pingcap.com/tidbcloud/create-tidb-cluster) +[クラスターを作成する](https://docs.pingcap.com/tidbcloud/create-tidb-cluster) -[クラスタに接続する](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster) +[クラスターに接続する](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster) -[HTAPクラスタを使用する](https://docs.pingcap.com/tidbcloud/tiflash-overview) +[HTAPクラスターを使用する](https://docs.pingcap.com/tidbcloud/tiflash-overview) [データのバックアップと復元](https://docs.pingcap.com/tidbcloud/backup-and-restore) -[クラスタのスケール](https://docs.pingcap.com/tidbcloud/scale-tidb-cluster) +[クラスターのスケール](https://docs.pingcap.com/tidbcloud/scale-tidb-cluster) -[TiDBクラスタを一時停止または再開する](https://docs.pingcap.com/tidbcloud/pause-or-resume-tidb-cluster) +[TiDBクラスターを一時停止または再開する](https://docs.pingcap.com/tidbcloud/pause-or-resume-tidb-cluster) [ストリームデータ](http://docs.pingcap.com/tidbcloud/changefeed-overview) @@ -68,7 +68,7 @@ summary: TiDB Cloudは、TiDBの優れた機能すべてをクラウドに提供 [Amazon RDS for Oracleから](https://docs.pingcap.com/tidbcloud/migrate-from-oracle-using-aws-dms) -[TiDBセルフマネージドから](https://docs.pingcap.com/tidbcloud/migrate-from-op-tidb) +[TiDB Self-Managedから](https://docs.pingcap.com/tidbcloud/migrate-from-op-tidb) [CSVファイルから](https://docs.pingcap.com/tidbcloud/import-csv-files) diff --git a/tidb-cloud/essential-changefeed-sink-to-kafka.md b/tidb-cloud/essential-changefeed-sink-to-kafka.md index eff40ab518e5b..a28583038019f 100644 --- a/tidb-cloud/essential-changefeed-sink-to-kafka.md +++ b/tidb-cloud/essential-changefeed-sink-to-kafka.md @@ -58,7 +58,7 @@ Apache Kafkaサービスへのパブリックアクセスを提供する場合 TiDB Cloud Essential の変更フィードが Apache Kafka にデータをストリーミングし、Kafka トピックを自動的に作成できるようにするには、Kafka に次の権限が追加されていることを確認してください。 - Kafka のトピック リソース タイプに`Create`および`Write`権限が追加されます。 -- Kafka のクラスタ リソース タイプに`DescribeConfigs`権限が追加されます。 +- Kafka のクラスター リソース タイプに`DescribeConfigs`権限が追加されます。 たとえば、Kafka クラスターが Confluent Cloud にある場合、詳細については、Confluent ドキュメントの[リソース](https://docs.confluent.io/platform/current/kafka/authorization.html#resources)と[ACLの追加](https://docs.confluent.io/platform/current/security/authorization/acls/manage-acls.html#add-acls)を参照してください。 @@ -195,7 +195,7 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト テーブルのKafkaメッセージを異なるパーティションに送信するように変更フィードを設定したい場合は、この配信方法を選択してください。行の変更ログで指定された列の値によって、変更ログの送信先パーティションが決まります。この配信方法は、各パーティション内の順序性を保証し、同じ列値を持つ変更ログが同じパーティションに送信されることを保証します。 -9. **トピックコンフィグレーション**領域で、以下の数値を設定してください。changefeedは、これらの数値に基づいてKafkaトピックを自動的に作成します。 +9. **トピック設定**領域で、以下の数値を設定してください。changefeedは、これらの数値に基づいてKafkaトピックを自動的に作成します。 - **レプリケーション係数**：各KafkaメッセージがレプリケートされるKafkaサーバーの数を制御します。有効な値の範囲は、 [`min.insync.replicas`](https://kafka.apache.org/33/documentation.html#brokerconfigs_min.insync.replicas)からKafkaブローカーの数までです。 - **パーティション番号**：トピックに存在するパーティションの数を制御します。有効な値の範囲は`[1, 10 * the number of Kafka brokers]`です。 diff --git a/tidb-cloud/essential-database-audit-logging.md b/tidb-cloud/essential-database-audit-logging.md index caf25faefa2ac..4448c3c786aed 100644 --- a/tidb-cloud/essential-database-audit-logging.md +++ b/tidb-cloud/essential-database-audit-logging.md @@ -45,8 +45,8 @@ TiDB Cloud Essentialは、以下のいずれかの条件が満たされた場合 - TiDB Cloud - [Amazon S3](https://aws.amazon.com/s3/) -- [Google Cloud Storage](https://cloud.google.com/storage) -- [Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/) +- [Google Cloud Storage](https://cloud.google.com/ストレージ) +- [Azure Blob Storage](https://azure.microsoft.com/en-us/services/ストレージ/blobs/) - [Alibaba Cloudオブジェクトストレージサービス（OSS）](https://www.alibabacloud.com/product/oss) ### TiDB Cloud {#tidb-cloud} @@ -62,25 +62,25 @@ TiDB Cloudに監査ログを保存し、ローカルマシンにダウンロー - `s3:PutObject`権限を持つ[アクセスキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html)。 - `s3:PutObject`権限を持つ[ロールARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) 。ロールARNの使用は、AWSでホストされているクラスターのみでサポートされています。 -詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)参照してください。 +詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-amazon-s3-access)参照してください。 -### Google Cloud Storage {#google-cloud-storage} +### Google Cloud Storage {#google-cloud-ストレージ} 監査ログをGoogle Cloud Storageに保存するには、以下の情報を提供する必要があります。 - URI: `gs:////` -- アクセス資格情報: `storage.objects.create`および`storage.objects.delete`権限を持つサービス[サービスアカウントキー](https://cloud.google.com/iam/docs/creating-managing-service-account-keys)。 +- アクセス資格情報: `ストレージ.objects.create`および`ストレージ.objects.delete`権限を持つサービス[サービスアカウントキー](https://cloud.google.com/iam/docs/creating-managing-service-account-keys)。 -詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)参照してください。 +詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-gcs-access)参照してください。 -### Azure Blob Storage {#azure-blob-storage} +### Azure Blob Storage {#azure-blob-ストレージ} Azure Blob Storage に監査ログを保存するには、以下の情報を提供する必要があります。 - URI: `azure://.blob.core.windows.net///`または`https://.blob.core.windows.net///` -- [共有アクセス署名（SAS）トークン](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview)資格情報: `Read`および`Write`および { `Container` `Object`権限を持つ共有アクセス宣言（SAS） ブラウザ。 +- [共有アクセス署名（SAS）トークン](https://docs.microsoft.com/en-us/azure/ストレージ/common/ストレージ-sas-overview)資格情報: `Read`および`Write`および { `Container` `Object`権限を持つ共有アクセス宣言（SAS） ブラウザ。 -詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)参照してください。 +詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-azure-blob-ストレージ-access)参照してください。 ### アリババクラウドOSS {#alibaba-cloud-oss} @@ -89,7 +89,7 @@ Alibaba Cloud OSSに監査ログを保存するには、以下の情報を提供 - URI: `oss:////` - アクセス資格情報: OSS バケットへのデータのエクスポートを許可する`oss:PutObject`および`oss:GetBucketInfo`権限を持つ[アクセスキーペア](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair)キーペア。 -詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)参照してください。 +詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-alibaba-cloud-object-ストレージ-service-oss-access)参照してください。 ## 監査ログフィルタルール {#audit-logging-filter-rules} @@ -156,7 +156,7 @@ TiDB CloudコンソールまたはTiDB Cloud CLIを使用して、 TiDB Cloud Es 3. **DB監査ログの**ページで、 **[有効にする]**をクリックします。 -4. 監査ログのstorage場所を選択し、必要な情報を入力します。次に、 **「接続をテスト」をクリックし、「次へ」**または**「次へ」を**クリックします。利用可能なstorage場所の詳細については、[監査ログの場所](#audit-logging-locations)を参照してください。 +4. 監査ログのストレージ場所を選択し、必要な情報を入力します。次に、 **「接続をテスト」をクリックし、「次へ」**または**「次へ」を**クリックします。利用可能なストレージ場所の詳細については、[監査ログの場所](#audit-logging-locations)を参照してください。 5. **データベース監査ログ設定**ダイアログで、ログファイルのローテーションとログのマスキング設定を入力し、 **[保存]**をクリックします。 @@ -164,10 +164,10 @@ TiDB CloudコンソールまたはTiDB Cloud CLIを使用して、 TiDB Cloud Es
    -Amazon S3storageを例にとってみましょう。監査ログを有効にして監査ログをAmazon S3に保存するには、次のコマンドを実行します。 +Amazon S3ストレージを例にとってみましょう。監査ログを有効にして監査ログをAmazon S3に保存するには、次のコマンドを実行します。 ```shell -ticloud serverless audit-log config update -c --enabled --cloud-storage S3 --s3.uri --s3.access-key-id --s3.secret-access-key --rotation-size-mib --rotation-interval-minutes --unredacted= +ticloud serverless audit-log config update -c --enabled --cloud-ストレージ S3 --s3.uri --s3.access-key-id --s3.secret-access-key --rotation-size-mib --rotation-interval-minutes --unredacted= ``` `--rotation-size-mib` 、 `--rotation-interval-minutes` 、および`--unredacted`パラメータはオプションです。これらを指定しない場合、デフォルト値が使用されます。 @@ -361,7 +361,7 @@ ticloud serverless audit-log filter delete --cluster-id --filter-ru
    -## TiDB Cloud Storage を使用した監査ログへのアクセス {#access-audit-logging-with-tidb-cloud-storage} +## TiDB Cloud Storage を使用した監査ログへのアクセス {#access-audit-logging-with-tidb-cloud-ストレージ} TiDB Cloudに監査ログを保存すると、 TiDB Cloud Essentialはそれらを`YYYY-MM-DD-.log`という名前の読み取り可能なテキストファイルとして保存します。これらのファイルは、 TiDB CloudコンソールまたはTiDB Cloud CLIを使用して表示およびダウンロードできます。 diff --git a/tidb-cloud/essential/_index.md b/tidb-cloud/essential/_index.md index 00c3d21ecf153..ab9b461e1ab75 100644 --- a/tidb-cloud/essential/_index.md +++ b/tidb-cloud/essential/_index.md @@ -41,11 +41,11 @@ summary: TiDB Cloudは、 TiDBの優れた機能すべてをクラウドに提 -[クラスタを作成する](https://docs.pingcap.com/tidbcloud/create-tidb-cluster-serverless/?plan=essential) +[クラスターを作成する](https://docs.pingcap.com/tidbcloud/create-tidb-cluster-serverless/?plan=essential) -[クラスタに接続する](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster-serverless/?plan=essential) +[クラスターに接続する](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster-serverless/?plan=essential) -[HTAPクラスタを使用する](https://docs.pingcap.com/tidbcloud/tiflash-overview/?plan=essential) +[HTAPクラスターを使用する](https://docs.pingcap.com/tidbcloud/tiflash-overview/?plan=essential) [データのバックアップと復元](https://docs.pingcap.com/tidbcloud/backup-and-restore-serverless/?plan=essential) diff --git a/tidb-cloud/explore-data-with-chat2query.md b/tidb-cloud/explore-data-with-chat2query.md index 3bea90c498d97..2b8752acff6ed 100644 --- a/tidb-cloud/explore-data-with-chat2query.md +++ b/tidb-cloud/explore-data-with-chat2query.md @@ -30,7 +30,7 @@ SQLエディタの推奨される使用例は以下のとおりです。 > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. TiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスタの名前をクリックし、左側のナビゲーションペインで**「SQLエディタ」を**クリックします。 +2. TiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスターの名前をクリックし、左側のナビゲーションペインで**「SQLエディタ」を**クリックします。 > **注記：** > diff --git a/tidb-cloud/features.md b/tidb-cloud/features.md index 557e66db6dd25..9617c0b1ba87e 100644 --- a/tidb-cloud/features.md +++ b/tidb-cloud/features.md @@ -16,7 +16,7 @@ summary: TiDB Cloudの各プランにおける機能サポート状況につい - 🚧:**開発中です**。 - ❌:**現在ご利用いただけません**。 -
    カテゴリ特徴StarterEssentialプレミアムDedicated
    基本スケーラブルなトランザクション処理✅ ✅ ✅ ✅
    分析処理✅ ✅ ✅ ✅
    ベクターstorageとベクター検索✅
    （一般公開プレビュー）    		 ✅
    （一般公開プレビュー）    		 🚧 ✅
    （一般公開プレビュー）
    API ✅
    （一般公開プレビュー）    		 ✅
    （一般公開プレビュー）    		 ✅
    （一般公開プレビュー）    		 ✅
    （一般公開プレビュー）
    開発者エクスペリエンスデータブランチ✅ ✅ 🚧 ❌
    SQLエディタ✅ 🚧 🚧 ❌
    リソース管理使った分だけ支払う✅ ✅ ✅ ❌
    ワークロードに基づいた自動スケーリング✅ ✅ ✅ ❌
    クラスターの手動変更❌ ❌ ❌ ✅
    パスワード設定✅ ✅ ✅ ✅
    一時停止と再開❌ ❌ ❌ ✅
    システムメンテナンス期間❌ ❌ 🚧 ✅
    バックアップファイルのごみ箱❌ ❌ ✅ ✅
    データ処理CSV、Parquet、SQLファイルからTiDB Cloudへのデータインポート✅ ✅ ✅ ✅
    MySQL互換データベースからTiDB Cloudへのデータ移行❌ ✅
    （一般公開プレビュー）    		 ✅
    （一般公開プレビュー）    		 ✅
    CSV、Parquet、SQLファイルによるローカルストレージまたはオブジェクトストレージへのデータエクスポート✅
    （一般公開プレビュー）    		 ✅
    （一般公開プレビュー）    		 🔒 ❌
    変更フィードを使用して、Kafkaまたはその他のMySQL互換データベースへのデータレプリケーションを変更します。 ❌ ✅
    （一般公開プレビュー）    		 ✅ ✅
    バックアップと復元自動バックアップ✅ ✅ ✅ ✅
    手動バックアップ❌ ❌ ✅ ✅
    デュアルリージョンバックアップ❌ ❌ ❌ ✅
    特定時点リカバリ（PITR） ❌ ✅ ✅ ✅
    復元する✅ ✅ ✅ ✅
    可観測性組み込みの指標✅ ✅ ✅ ✅
    アラート❌ ✅ ✅ ✅
    SQL文の分析✅ ✅ ✅ ✅
    スロークエリログ✅ ✅ ✅ ✅
    Top SQL ❌ ✅
    （公開プレビューでトップRUを獲得）    		 ✅
    （公開プレビューでトップRUを獲得）    		 ✅
    イベント✅ ✅ 🚧 ✅
    Datadog、Prometheus、New Relicなどのサードパーティ統合❌ ✅
    （一般公開プレビュー）    		 ✅ ✅
    高可用性クロスAZフェイルオーバー❌ ✅ ✅ ✅
    リソース割り当てノードグループ❌ ❌ ❌ ✅
    リソース制御❌ ❌ 🚧 ✅
    ネットワーク接続プライベートエンドポイント✅ ✅ ✅ ✅
    公開エンドポイント✅ ✅ ✅ ✅
    VPCピアリング❌ ❌ 🔒 ✅
    Security国立データベース監査ログ❌ 🔒 ✅ ✅
    コンソール監査ログ✅ ✅ ✅ ✅
    ログの編集✅ ✅ ✅ ✅
    CMEK ❌ ❌ 🔒 ✅
    二重層暗号化✅ ✅ 🔒 ✅
    IAM （メールアドレスとパスワードによるログイン、標準SSO、組織SSOを含む） ✅ ✅ ✅ ✅
    クラウドとリージョンAWS ✅ ✅ ✅ ✅
    アリババクラウド✅ ✅ ✅ ❌
    Azure ❌ ❌ 🚧 ✅
    Google Cloud ❌ ❌ ❌ ✅
    クラウドとリージョンAWS ✅ ✅ ✅ ✅
    Azure ❌ ❌ 🚧 ✅
    Google Cloud ❌ ❌ ❌ ✅
    +
    カテゴリ特徴StarterEssentialプレミアムDedicated
    基本スケーラブルなトランザクション処理✅ ✅ ✅ ✅
    分析処理✅ ✅ ✅ ✅
    ベクターストレージとベクター検索✅
    （一般公開プレビュー）    		 ✅
    （一般公開プレビュー）    		 🚧 ✅
    （一般公開プレビュー）
    API ✅
    （一般公開プレビュー）    		 ✅
    （一般公開プレビュー）    		 ✅
    （一般公開プレビュー）    		 ✅
    （一般公開プレビュー）
    開発者エクスペリエンスデータブランチ✅ ✅ 🚧 ❌
    SQLエディタ✅ 🚧 🚧 ❌
    リソース管理使った分だけ支払う✅ ✅ ✅ ❌
    ワークロードに基づいた自動スケーリング✅ ✅ ✅ ❌
    クラスターの手動変更❌ ❌ ❌ ✅
    パスワード設定✅ ✅ ✅ ✅
    一時停止と再開❌ ❌ ❌ ✅
    システムメンテナンス期間❌ ❌ 🚧 ✅
    バックアップファイルのごみ箱❌ ❌ ✅ ✅
    データ処理CSV、Parquet、SQLファイルからTiDB Cloudへのデータインポート✅ ✅ ✅ ✅
    MySQL互換データベースからTiDB Cloudへのデータ移行❌ ✅
    （一般公開プレビュー）    		 ✅
    （一般公開プレビュー）    		 ✅
    CSV、Parquet、SQLファイルによるローカルストレージまたはオブジェクトストレージへのデータエクスポート✅
    （一般公開プレビュー）    		 ✅
    （一般公開プレビュー）    		 🔒 ❌
    変更フィードを使用して、Kafkaまたはその他のMySQL互換データベースへのデータレプリケーションを変更します。 ❌ ✅
    （一般公開プレビュー）    		 ✅ ✅
    バックアップと復元自動バックアップ✅ ✅ ✅ ✅
    手動バックアップ❌ ❌ ✅ ✅
    デュアルリージョンバックアップ❌ ❌ ❌ ✅
    特定時点リカバリ（PITR） ❌ ✅ ✅ ✅
    復元する✅ ✅ ✅ ✅
    可観測性組み込みの指標✅ ✅ ✅ ✅
    アラート❌ ✅ ✅ ✅
    SQL文の分析✅ ✅ ✅ ✅
    スロークエリログ✅ ✅ ✅ ✅
    Top SQL ❌ ✅
    （公開プレビューでトップRUを獲得）    		 ✅
    （公開プレビューでトップRUを獲得）    		 ✅
    イベント✅ ✅ 🚧 ✅
    Datadog、Prometheus、New Relicなどのサードパーティ統合❌ ✅
    （一般公開プレビュー）    		 ✅ ✅
    高可用性クロスAZフェイルオーバー❌ ✅ ✅ ✅
    リソース割り当てノードグループ❌ ❌ ❌ ✅
    リソース制御❌ ❌ 🚧 ✅
    ネットワーク接続プライベートエンドポイント✅ ✅ ✅ ✅
    公開エンドポイント✅ ✅ ✅ ✅
    VPCピアリング❌ ❌ 🔒 ✅
    Security国立データベース監査ログ❌ 🔒 ✅ ✅
    コンソール監査ログ✅ ✅ ✅ ✅
    ログの編集✅ ✅ ✅ ✅
    CMEK ❌ ❌ 🔒 ✅
    二重層暗号化✅ ✅ 🔒 ✅
    IAM （メールアドレスとパスワードによるログイン、標準SSO、組織SSOを含む） ✅ ✅ ✅ ✅
    クラウドとリージョンAWS ✅ ✅ ✅ ✅
    アリババクラウド✅ ✅ ✅ ❌
    Azure ❌ ❌ 🚧 ✅
    Google Cloud ❌ ❌ ❌ ✅
    クラウドとリージョンAWS ✅ ✅ ✅ ✅
    Azure ❌ ❌ 🚧 ✅
    Google Cloud ❌ ❌ ❌ ✅
    > **ヒント：** > diff --git a/tidb-cloud/high-availability-with-multi-az.md b/tidb-cloud/high-availability-with-multi-az.md index 055e834d20362..587316fde4e60 100644 --- a/tidb-cloud/high-availability-with-multi-az.md +++ b/tidb-cloud/high-availability-with-multi-az.md @@ -5,18 +5,18 @@ summary: TiDB Cloud Dedicated は、マルチ AZ デプロイメントによる # TiDB Cloud専用における高可用性 {#high-availability-in-tidb-cloud-dedicated} -TiDBはRaftコンセンサスアルゴリズムを使用し、 Raftグループ内のstorage全体にデータの高可用性と安全なレプリケーションを実現します。データはstorageノード間で冗長コピーされ、異なるアベイラビリティゾーンに配置されるため、マシンやデータセンターの障害から保護されます。自動フェイルオーバー機能により、TiDBはサービスの常時稼働を保証します。 +TiDBはRaftコンセンサスアルゴリズムを使用し、 Raftグループ内のストレージ全体にデータの高可用性と安全なレプリケーションを実現します。データはストレージノード間で冗長コピーされ、異なるアベイラビリティゾーンに配置されるため、マシンやデータセンターの障害から保護されます。自動フェイルオーバー機能により、TiDBはサービスの常時稼働を保証します。 -TiDB Cloud Dedicated クラスタは、TiDB ノード、TiKV ノード、 TiFlashノードという 3 つの主要コンポーネントで構成されています。TiDB Cloud Dedicated の各コンポーネントの高可用性実装は次のとおりです。 +TiDB Cloud Dedicated クラスターは、TiDB ノード、TiKV ノード、 TiFlashノードという 3 つの主要コンポーネントで構成されています。TiDB Cloud Dedicated の各コンポーネントの高可用性実装は次のとおりです。 - **TiDBノード** - TiDBはコンピューティングのみを目的としており、データの保存は行いません。水平方向に拡張可能です。TiDB Cloud Dedicatedは、リージョン内の異なるアベイラビリティゾーンにTiDBノードを均等に配置します。ユーザーがSQLリクエストを実行すると、リクエストはまず複数のアベイラビリティゾーンに展開されたロードバランサーを通過し、その後、ロードバランサーによって複数のTiDBノードに分散されて実行されます。高可用性を確保するため、各TiDB Cloud Dedicatedクラスタには少なくとも2つのTiDBノードを配置することをお勧めします。 + TiDBはコンピューティングのみを目的としており、データの保存は行いません。水平方向に拡張可能です。TiDB Cloud Dedicatedは、リージョン内の異なるアベイラビリティゾーンにTiDBノードを均等に配置します。ユーザーがSQLリクエストを実行すると、リクエストはまず複数のアベイラビリティゾーンに展開されたロードバランサーを通過し、その後、ロードバランサーによって複数のTiDBノードに分散されて実行されます。高可用性を確保するため、各TiDB Cloud Dedicatedクラスターには少なくとも2つのTiDBノードを配置することをお勧めします。 - **TiKVノード** - [TiKV](https://docs.pingcap.com/tidb/stable/tikv-overview) 、水平スケーラビリティを備えたTiDB Cloud Dedicatedクラスタの行ベースのstorageレイヤーです。TiDB Cloud DedicatedクラスタのTiKVノードの最小数は3です。TiDB Cloud Dedicatedは、選択したリージョン内のすべてのアベイラビリティゾーン（少なくとも3つ）にTiKVノードを均等にデプロイすることで、耐久性と高可用性を実現します。典型的な3レプリカ構成では、データはすべてのアベイラビリティゾーンのTiKVノードに均等に分散され、各TiKVノードのディスクに永続化されます。 + [TiKV](https://docs.pingcap.com/tidb/stable/tikv-overview) 、水平スケーラビリティを備えたTiDB Cloud Dedicatedクラスターの行ベースのストレージレイヤーです。TiDB Cloud DedicatedクラスターのTiKVノードの最小数は3です。TiDB Cloud Dedicatedは、選択したリージョン内のすべてのアベイラビリティゾーン（少なくとも3つ）にTiKVノードを均等にデプロイすることで、耐久性と高可用性を実現します。典型的な3レプリカ構成では、データはすべてのアベイラビリティゾーンのTiKVノードに均等に分散され、各TiKVノードのディスクに永続化されます。 - **TiFlashノード** - [TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview) 、TiKV の列指向storage拡張機能であり、TiDB を本質的にハイブリッドトランザクション/分析処理 (HTAP) データベースにする重要なコンポーネントです。TiFlash、列指向レプリカはRaft Learnerコンセンサスアルゴリズムに従って非同期的に複製されます。TiDB Cloud Dedicated は、 TiFlashノードをリージョン内の異なるアベイラビリティゾーンに均等にデプロイします。本番環境での高可用性を確保するため、各TiDB Cloud Dedicated クラスターに少なくとも 2 つのTiFlashノードを設定し、少なくとも 2 つのデータレプリカを作成本番ことをお勧めします。 + [TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview) 、TiKV の列指向ストレージ拡張機能であり、TiDB を本質的にハイブリッドトランザクション/分析処理 (HTAP) データベースにする重要なコンポーネントです。TiFlash、列指向レプリカはRaftラーナーコンセンサスアルゴリズムに従って非同期的に複製されます。TiDB Cloud Dedicated は、 TiFlashノードをリージョン内の異なるアベイラビリティゾーンに均等にデプロイします。本番環境での高可用性を確保するため、各TiDB Cloud Dedicated クラスターに少なくとも 2 つのTiFlashノードを設定し、少なくとも 2 つのデータレプリカを作成本番ことをお勧めします。 diff --git a/tidb-cloud/import-csv-files-serverless.md b/tidb-cloud/import-csv-files-serverless.md index 4d9ea7448bd6f..af9798c9de608 100644 --- a/tidb-cloud/import-csv-files-serverless.md +++ b/tidb-cloud/import-csv-files-serverless.md @@ -3,7 +3,7 @@ title: Import CSV Files from Cloud Storage into TiDB Cloud Starter or Essential summary: Amazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object Storage Service (OSS) からCSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポートする方法を学びましょう。 --- -# TiDB Cloud StarterまたはEssentialにクラウドストレージからCSVファイルをインポートする {#import-csv-files-from-cloud-storage-into-tidb-cloud-starter-or-essential} +# TiDB Cloud StarterまたはEssentialにクラウドストレージからCSVファイルをインポートする {#import-csv-files-from-cloud-ストレージ-into-tidb-cloud-starter-or-essential} このドキュメントでは、Amazon Simple Storage Service (Amazon S3)、Google Cloud Storage (GCS)、Azure Blob Storage、または Alibaba Cloud Object Storage Service (OSS) から CSV ファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポートする方法について説明します。 @@ -78,15 +78,15 @@ CSVファイルにはスキーマ情報が含まれていないため、CSVフ TiDB CloudがAmazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object Storage Serviceバケット内のCSVファイルにアクセスできるようにするには、次のいずれかの操作を行います。 -- CSV ファイルが Amazon S3 にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 +- CSV ファイルが Amazon S3 にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-amazon-s3-access)。 バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-csv-files)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 -- CSV ファイルが GCS にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 +- CSV ファイルが GCS にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[GCSへのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-gcs-access)。 -- CSV ファイルが Azure Blob Storage にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)。 +- CSV ファイルが Azure Blob Storage にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-azure-blob-ストレージ-access)。 -- CSV ファイルが Alibaba Cloud Object Storage Service (OSS) にある場合は、 TiDB Cloud StarterまたはEssentialインスタンス[Alibaba Cloud Object Storage Service (OSS) へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 +- CSV ファイルが Alibaba Cloud Object Storage Service (OSS) にある場合は、 TiDB Cloud StarterまたはEssentialインスタンス[Alibaba Cloud Object Storage Service (OSS) へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-alibaba-cloud-object-ストレージ-service-oss-access)。 ## ステップ4．CSVファイルをインポートする {#step-4-import-csv-files} @@ -113,7 +113,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `s3://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://sampledata/ingest/` 。 - - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)参照してください。 + - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-amazon-s3-access)参照してください。 - **AWSロールARN** ：AWSロールARNの値を入力してください。 - **AWSアクセスキー**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 @@ -166,7 +166,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[gcs|gs]://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `[gcs|gs]://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[gcs|gs]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[gcs|gs]://sampledata/ingest/` 。 - - **認証情報**: GCS IAM役割サービス アカウント キーを使用してバケットにアクセスできます。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)参照してください。 + - **認証情報**: GCS IAM役割サービス アカウント キーを使用してバケットにアクセスできます。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-gcs-access)参照してください。 4. **「次へ」**をクリックしてください。 @@ -217,7 +217,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[azure|https]://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `[azure|https]://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[azure|https]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[azure|https]://sampledata/ingest/` 。 - - **資格情報**: Shared Access Signature (SAS) トークンを使用してバケットにアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)参照してください。 + - **資格情報**: Shared Access Signature (SAS) トークンを使用してバケットにアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-azure-blob-ストレージ-access)参照してください。 4. **「次へ」**をクリックしてください。 @@ -268,7 +268,7 @@ CSVファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポー - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `oss://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`oss://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `oss://sampledata/ingest/` 。 - - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)参照してください。 + - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-alibaba-cloud-object-ストレージ-service-oss-access)参照してください。 4. **「次へ」**をクリックしてください。 diff --git a/tidb-cloud/import-csv-files.md b/tidb-cloud/import-csv-files.md index 04373c99d8267..6e00cb30c9744 100644 --- a/tidb-cloud/import-csv-files.md +++ b/tidb-cloud/import-csv-files.md @@ -4,7 +4,7 @@ summary: Amazon S3、GCS、またはAzure Blob StorageからCSVファイルをTi aliases: ['/ja/tidbcloud/migrate-from-amazon-s3-or-gcs','/ja/tidbcloud/migrate-from-aurora-bulk-import'] --- -# クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする {#import-csv-files-from-cloud-storage-into-tidb-cloud-dedicated} +# クラウドストレージからTiDB Cloud DedicatedにCSVファイルをインポートする {#import-csv-files-from-cloud-ストレージ-into-tidb-cloud-dedicated} このドキュメントでは、Amazon Simple Storage Service (Amazon S3)、Google Cloud Storage (GCS)、または Azure Blob Storage から CSV ファイルをTiDB Cloud Dedicatedにインポートする方法について説明します。 @@ -82,13 +82,13 @@ CSVファイルにはスキーマ情報が含まれていないため、CSVフ TiDB CloudがAmazon S3バケット、GCSバケット、またはAzure Blob Storageコンテナ内のCSVファイルにアクセスできるようにするには、次のいずれかの操作を行います。 -- CSV ファイルが Amazon S3 にある場合は、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 +- CSV ファイルが Amazon S3 にある場合は、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-ストレージ.md#configure-amazon-s3-access)。 バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-csv-files-to-tidb-cloud)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 -- CSV ファイルが GCS にある場合は、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 +- CSV ファイルが GCS にある場合は、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-ストレージ.md#configure-gcs-access)。 -- CSV ファイルが Azure Blob Storage にある場合は、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)。 +- CSV ファイルが Azure Blob Storage にある場合は、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-ストレージ.md#configure-azure-blob-ストレージ-access)。 ## ステップ4. CSVファイルをTiDB Cloudにインポートする {#step-4-import-csv-files-to-tidb-cloud} @@ -97,7 +97,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に
    -1. 対象のTiDB Cloud Dedicatedクラスタの**インポート**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスターの**インポート**ページを開きます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動します。 @@ -115,7 +115,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に - **ソースURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `s3://mybucket/myfolder/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://mybucket/myfolder/` 。 - - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)参照してください。 + - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-ストレージ.md#configure-amazon-s3-access)参照してください。 - **AWS ロール ARN** (推奨): AWS ロール ARN の値を入力します。まだロール ARN がない場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロール ARN を作成する] を**クリックし、画面の指示に従うか、 **[問題が発生しましたか?] ダイアログでロール ARN を手動で作成して、**クラスター**のTiDB Cloudアカウント ID**と**TiDB Cloud外部 ID**を取得し、 IAMロールを手動で作成します。 - **AWSアクセスキー**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 @@ -140,7 +140,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に - **対象データベース**と**対象テーブル**：データをインポートする対象データベースとテーブルを入力してください。 - 必要に応じて、 **「CSVコンフィグレーションの編集」**をクリックして、CSVファイルに合わせてオプションを設定してください。区切り文字や区切り記号の設定、エスケープ文字にバックスラッシュを使用するかどうかの指定、ファイルにヘッダー行が含まれているかどうかの指定が可能です。 + 必要に応じて、 **「CSV設定の編集」**をクリックして、CSVファイルに合わせてオプションを設定してください。区切り文字や区切り記号の設定、エスケープ文字にバックスラッシュを使用するかどうかの指定、ファイルにヘッダー行が含まれているかどうかの指定が可能です。 6. **「次へ」**をクリックします。TiDB Cloudがソースファイルをスキャンします。 @@ -152,7 +152,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に
    -1. 対象のTiDB Cloud Dedicatedクラスタの**インポート**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスターの**インポート**ページを開きます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動します。 @@ -170,7 +170,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に - **ソースURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`gs://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `gs://mybucket/myfolder/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`gs://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `gs://mybucket/myfolder/` 。 - - **Google Cloud サービス アカウント ID** : TiDB Cloud は、このページで一意の Google Cloud サービス アカウント ID ( `example-service-account@your-project.iam.gserviceaccount.com`など) を提供します。このサービス アカウント ID に、Google Cloud プロジェクト内の GCS バケットに対して必要なIAM権限（ `Storage Object Viewer`など）を付与します。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)参照してください。 + - **Google Cloud サービス アカウント ID** : TiDB Cloud は、このページで一意の Google Cloud サービス アカウント ID ( `example-service-account@your-project.iam.gserviceaccount.com`など) を提供します。このサービス アカウント ID に、Google Cloud プロジェクト内の GCS バケットに対して必要なIAM権限（ `Storage Object Viewer`など）を付与します。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-ストレージ.md#configure-gcs-access)参照してください。 4. **「次へ」**をクリックしてください。 @@ -193,7 +193,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に - **対象データベース**と**対象テーブル**：データをインポートする対象データベースとテーブルを入力してください。 - 必要に応じて、 **「CSVコンフィグレーションの編集」**をクリックして、CSVファイルに合わせてオプションを設定してください。区切り文字や区切り記号の設定、エスケープ文字にバックスラッシュを使用するかどうかの指定、ファイルにヘッダー行が含まれているかどうかの指定が可能です。 + 必要に応じて、 **「CSV設定の編集」**をクリックして、CSVファイルに合わせてオプションを設定してください。区切り文字や区切り記号の設定、エスケープ文字にバックスラッシュを使用するかどうかの指定、ファイルにヘッダー行が含まれているかどうかの指定が可能です。 6. **「次へ」**をクリックします。TiDB Cloudがソースファイルをスキャンします。 @@ -205,7 +205,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に
    -1. 対象のTiDB Cloud Dedicatedクラスタの**インポート**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスターの**インポート**ページを開きます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動します。 @@ -227,20 +227,20 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に - **接続方法**： TiDB CloudがAzure Blob Storageに接続する方法を選択してください。 - - **パブリック**（デフォルト）：パブリックインターネット経由で接続します。storageアカウントがパブリックネットワークへのアクセスを許可している場合にこのオプションを使用してください。 - - **プライベートリンク**：Azure プライベートエンドポイント経由で接続し、ネットワークから隔離されたアクセスを実現します。storageアカウントがパブリックアクセスをブロックしている場合、またはセキュリティポリシーでプライベート接続が必要な場合にこのオプションを使用します。**プライベートリンク**を選択した場合は、追加フィールド**「Azure Blob Storage リソース ID」**も入力する必要があります。リソース ID を確認するには： + - **パブリック**（デフォルト）：パブリックインターネット経由で接続します。ストレージアカウントがパブリックネットワークへのアクセスを許可している場合にこのオプションを使用してください。 + - **プライベートリンク**：Azure プライベートエンドポイント経由で接続し、ネットワークから隔離されたアクセスを実現します。ストレージアカウントがパブリックアクセスをブロックしている場合、またはセキュリティポリシーでプライベート接続が必要な場合にこのオプションを使用します。**プライベートリンク**を選択した場合は、追加フィールド**「Azure Blob Storage リソース ID」**も入力する必要があります。リソース ID を確認するには： 1. [Azureポータル](https://portal.azure.com/)にアクセスします。 - 2. storageアカウントに移動し、 **[概要]** > **[JSONビュー]**をクリックします。 - 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/`の形式です。 + 2. ストレージアカウントに移動し、 **[概要]** > **[JSONビュー]**をクリックします。 + 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/ストレージAccounts/`の形式です。 - - **SAS トークン**: TiDB Cloud がAzure Blob Storage コンテナー内のソース ファイルにアクセスできるようにするアカウント SAS トークンを入力します。まだお持ちでない場合は、 **「ここをクリックして Azure ARM テンプレートを使用して新しいものを作成します」を**クリックし、画面の指示に従うか、アカウント SAS トークンを手動で作成します。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)参照してください。 + - **SAS トークン**: TiDB Cloud がAzure Blob Storage コンテナー内のソース ファイルにアクセスできるようにするアカウント SAS トークンを入力します。まだお持ちでない場合は、 **「ここをクリックして Azure ARM テンプレートを使用して新しいものを作成します」を**クリックし、画面の指示に従うか、アカウント SAS トークンを手動で作成します。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-ストレージ.md#configure-azure-blob-ストレージ-access)参照してください。 4. **「次へ」**をクリックしてください。 - 接続方法として**プライベートリンク**を選択した場合、 TiDB Cloudはstorageアカウント用のプライベートエンドポイントを作成します。ウィザードを続行するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 + 接続方法として**プライベートリンク**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。ウィザードを続行するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 - 1. [Azureポータル](https://portal.azure.com/)に移動し、storageアカウントに移動します。 + 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 2. **「ネットワーク」** > **「プライベートエンドポイント接続」**をクリックします。 @@ -271,7 +271,7 @@ CSVファイルをTiDB Cloudにインポートするには、以下の手順に - **対象データベース**と**対象テーブル**：データをインポートする対象データベースとテーブルを入力してください。 - 必要に応じて、 **「CSVコンフィグレーションの編集」**をクリックして、CSVファイルに合わせてオプションを設定してください。区切り文字や区切り記号の設定、エスケープ文字にバックスラッシュを使用するかどうかの指定、ファイルにヘッダー行が含まれているかどうかの指定が可能です。 + 必要に応じて、 **「CSV設定の編集」**をクリックして、CSVファイルに合わせてオプションを設定してください。区切り文字や区切り記号の設定、エスケープ文字にバックスラッシュを使用するかどうかの指定、ファイルにヘッダー行が含まれているかどうかの指定が可能です。 6. **「次へ」**をクリックします。TiDB Cloudがソースファイルをスキャンします。 diff --git a/tidb-cloud/import-parquet-files-serverless.md b/tidb-cloud/import-parquet-files-serverless.md index e90358fbd71d9..9cd29ecb59cba 100644 --- a/tidb-cloud/import-parquet-files-serverless.md +++ b/tidb-cloud/import-parquet-files-serverless.md @@ -3,7 +3,7 @@ title: Import Apache Parquet Files from Cloud Storage into TiDB Cloud Starter or summary: Amazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object Storage Service (OSS) から Apache Parquet ファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialにインポートする方法を学びましょう。 --- -# クラウドストレージからTiDB Cloud StarterまたはEssentialにApache Parquetファイルをインポートする {#import-apache-parquet-files-from-cloud-storage-into-tidb-cloud-starter-or-essential} +# クラウドストレージからTiDB Cloud StarterまたはEssentialにApache Parquetファイルをインポートする {#import-apache-parquet-files-from-cloud-ストレージ-into-tidb-cloud-starter-or-essential} TiDB Cloud StarterまたはTiDB Cloud Essential[アパッチ・パーケット](https://parquet.apache.org/)TiDB Cloud Starterファイルをインポートする方法についてTiDB Cloud Essential。 @@ -82,15 +82,15 @@ Parquetファイルにはスキーマ情報が含まれていないため、Parq TiDB CloudがAmazon S3、GCS、Azure Blob Storage、またはAlibaba Cloud Object Storage Serviceバケット内のParquetファイルにアクセスできるようにするには、次のいずれかの操作を行います。 -- Parquet ファイルが Amazon S3 にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 +- Parquet ファイルが Amazon S3 にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-amazon-s3-access)。 バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-parquet-files)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 -- Parquet ファイルが GCS にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)。 +- Parquet ファイルが GCS にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスに対して[GCSへのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-gcs-access)。 -- Parquet ファイルが Azure Blob Storage に配置されている場合は、 TiDB Cloud StarterまたはEssentialインスタンスの[Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)。 +- Parquet ファイルが Azure Blob Storage に配置されている場合は、 TiDB Cloud StarterまたはEssentialインスタンスの[Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-azure-blob-ストレージ-access)。 -- Parquet ファイルが Alibaba Cloud Object Storage Service (OSS) にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスの[Alibaba Cloud Object Storage Service (OSS) へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 +- Parquet ファイルが Alibaba Cloud Object Storage Service (OSS) にある場合は、 TiDB Cloud StarterまたはEssentialインスタンスの[Alibaba Cloud Object Storage Service (OSS) へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-alibaba-cloud-object-ストレージ-service-oss-access)。 ## ステップ4．Parquetファイルをインポートする {#step-4-import-parquet-files} @@ -117,7 +117,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `s3://sampledata/ingest/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://sampledata/ingest/` 。 - - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)参照してください。 + - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-amazon-s3-access)参照してください。 - **AWSロールARN** ：AWSロールARNの値を入力してください。 - **AWSアクセスキー**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 @@ -170,7 +170,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[gcs|gs]://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `[gcs|gs]://sampledata/ingest/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[gcs|gs]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[gcs|gs]://sampledata/ingest/` 。 - - **認証情報**: GCS IAM役割サービス アカウント キーを使用してバケットにアクセスできます。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)参照してください。 + - **認証情報**: GCS IAM役割サービス アカウント キーを使用してバケットにアクセスできます。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-gcs-access)参照してください。 4. **「次へ」**をクリックしてください。 @@ -221,7 +221,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`[azure|https]://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `[azure|https]://sampledata/ingest/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`[azure|https]://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `[azure|https]://sampledata/ingest/` 。 - - **資格情報**: Shared Access Signature (SAS) トークンを使用してバケットにアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)参照してください。 + - **資格情報**: Shared Access Signature (SAS) トークンを使用してバケットにアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-azure-blob-ストレージ-access)参照してください。 4. **「次へ」**をクリックしてください。 @@ -272,7 +272,7 @@ TiDB Cloud StarterまたはTiDB Cloud EssentialにParquetファイルをイン - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `oss://sampledata/ingest/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`oss://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `oss://sampledata/ingest/` 。 - - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)参照してください。 + - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-alibaba-cloud-object-ストレージ-service-oss-access)参照してください。 4. **「次へ」**をクリックしてください。 diff --git a/tidb-cloud/import-parquet-files.md b/tidb-cloud/import-parquet-files.md index f9f1e43eb9f67..b62377905955b 100644 --- a/tidb-cloud/import-parquet-files.md +++ b/tidb-cloud/import-parquet-files.md @@ -3,7 +3,7 @@ title: Import Apache Parquet Files from Cloud Storage into TiDB Cloud Dedicated summary: Amazon S3、GCS、またはAzure Blob StorageからTiDB Cloud DedicatedにApache Parquetファイルをインポートする方法を学びましょう。 --- -# クラウドストレージからTiDB Cloud DedicatedにApache Parquetファイルをインポートする {#import-apache-parquet-files-from-cloud-storage-into-tidb-cloud-dedicated} +# クラウドストレージからTiDB Cloud DedicatedにApache Parquetファイルをインポートする {#import-apache-parquet-files-from-cloud-ストレージ-into-tidb-cloud-dedicated} このドキュメントでは、Amazon Simple Storage Service (Amazon S3)、Google Cloud Storage (GCS)、または Azure Blob Storage からTiDB Cloud Dedicatedに Apache Parquet ファイルをインポートする方法について説明します。インポートできる Parquet ファイルは、非圧縮ファイルでも[Google Snappy](https://github.com/google/snappy)で圧縮されたファイルでも構いません。その他の Parquet 圧縮コーデックはサポートされていません。 @@ -87,13 +87,13 @@ Parquetファイルにはスキーマ情報が含まれていないため、Parq TiDB CloudがAmazon S3バケット、GCSバケット、またはAzure Blob Storageコンテナ内のParquetファイルにアクセスできるようにするには、次のいずれかの操作を行います。 -- Parquet ファイルが Amazon S3 にある場合は、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)。 +- Parquet ファイルが Amazon S3 にある場合は、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-ストレージ.md#configure-amazon-s3-access)。 バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、 [ステップ4](#step-4-import-parquet-files-to-tidb-cloud)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 -- Parquet ファイルが GCS にある場合は、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)。 +- Parquet ファイルが GCS にある場合は、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-ストレージ.md#configure-gcs-access)。 -- Parquet ファイルが Azure Blob Storage に配置されている場合は、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)。 +- Parquet ファイルが Azure Blob Storage に配置されている場合は、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-ストレージ.md#configure-azure-blob-ストレージ-access)。 ## ステップ4. ParquetファイルをTiDB Cloudにインポートする {#step-4-import-parquet-files-to-tidb-cloud} @@ -102,7 +102,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順
    -1. 対象のTiDB Cloud Dedicatedクラスタの**インポート**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスターの**インポート**ページを開きます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動します。 @@ -120,7 +120,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 - **ソースURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `s3://mybucket/myfolder/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://mybucket/myfolder/` 。 - - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)参照してください。 + - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-ストレージ.md#configure-amazon-s3-access)参照してください。 - **AWS ロール ARN** (推奨): AWS ロール ARN の値を入力します。まだロール ARN がない場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロール ARN を作成する] を**クリックし、画面の指示に従うか、 **[問題が発生しましたか?] ダイアログでロール ARN を手動で作成して、**クラスター**のTiDB Cloudアカウント ID**と**TiDB Cloud外部 ID**を取得し、 IAMロールを手動で作成します。 - **AWSアクセスキー**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 @@ -155,7 +155,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順
    -1. 対象のTiDB Cloud Dedicatedクラスタの**インポート**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスターの**インポート**ページを開きます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動します。 @@ -173,7 +173,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 - **ソースURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`gs://[bucket_name]/[data_source_folder]/[file_name].parquet`の形式で入力してください。例: `gs://mybucket/myfolder/TableName.01.parquet` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`gs://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `gs://mybucket/myfolder/` 。 - - **認証情報**: TiDB Cloud は、このページで一意の Google Cloud サービス アカウント ID ( `example-service-account@your-project.iam.gserviceaccount.com`など) を提供します。このサービス アカウント ID に、Google Cloud プロジェクト内の GCS バケットに対して必要なIAM権限（ `Storage Object Viewer`など）を付与します。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-gcs-access)参照してください。 + - **認証情報**: TiDB Cloud は、このページで一意の Google Cloud サービス アカウント ID ( `example-service-account@your-project.iam.gserviceaccount.com`など) を提供します。このサービス アカウント ID に、Google Cloud プロジェクト内の GCS バケットに対して必要なIAM権限（ `Storage Object Viewer`など）を付与します。詳細については、 [GCSへのアクセスを設定する](/tidb-cloud/dedicated-external-ストレージ.md#configure-gcs-access)参照してください。 4. **「次へ」**をクリックしてください。 @@ -206,7 +206,7 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順
    -1. 対象のTiDB Cloud Dedicatedクラスタの**インポート**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスターの**インポート**ページを開きます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動します。 @@ -228,20 +228,20 @@ TiDB CloudにParquetファイルをインポートするには、以下の手順 - **接続方法**： TiDB CloudがAzure Blob Storageに接続する方法を選択してください。 - - **パブリック**（デフォルト）：パブリックインターネット経由で接続します。storageアカウントがパブリックネットワークへのアクセスを許可している場合にこのオプションを使用してください。 - - **プライベートリンク**：Azure プライベートエンドポイント経由で接続し、ネットワークから隔離されたアクセスを実現します。storageアカウントがパブリックアクセスをブロックしている場合、またはセキュリティポリシーでプライベート接続が必要な場合にこのオプションを使用します。**プライベートリンク**を選択した場合は、追加フィールド**「Azure Blob Storage リソース ID」**も入力する必要があります。リソース ID を確認するには： + - **パブリック**（デフォルト）：パブリックインターネット経由で接続します。ストレージアカウントがパブリックネットワークへのアクセスを許可している場合にこのオプションを使用してください。 + - **プライベートリンク**：Azure プライベートエンドポイント経由で接続し、ネットワークから隔離されたアクセスを実現します。ストレージアカウントがパブリックアクセスをブロックしている場合、またはセキュリティポリシーでプライベート接続が必要な場合にこのオプションを使用します。**プライベートリンク**を選択した場合は、追加フィールド**「Azure Blob Storage リソース ID」**も入力する必要があります。リソース ID を確認するには： 1. [Azureポータル](https://portal.azure.com/)にアクセスします。 - 2. storageアカウントに移動し、 **[概要]** > **[JSONビュー]**をクリックします。 - 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/`の形式です。 + 2. ストレージアカウントに移動し、 **[概要]** > **[JSONビュー]**をクリックします。 + 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/ストレージAccounts/`の形式です。 - - **資格情報**: TiDB Cloud がAzure Blob Storage コンテナー内のソース ファイルにアクセスできるようにするためのアカウント SAS トークンを入力します。まだお持ちでない場合は、 **「ここをクリックして Azure ARM テンプレートを使用して新しいものを作成します」を**クリックし、画面の指示に従うか、アカウント SAS トークンを手動で作成します。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)参照してください。 + - **資格情報**: TiDB Cloud がAzure Blob Storage コンテナー内のソース ファイルにアクセスできるようにするためのアカウント SAS トークンを入力します。まだお持ちでない場合は、 **「ここをクリックして Azure ARM テンプレートを使用して新しいものを作成します」を**クリックし、画面の指示に従うか、アカウント SAS トークンを手動で作成します。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-ストレージ.md#configure-azure-blob-ストレージ-access)参照してください。 4. **「次へ」**をクリックしてください。 - 接続方法として**プライベートリンク**を選択した場合、 TiDB Cloudはstorageアカウント用のプライベートエンドポイントを作成します。ウィザードを続行するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 + 接続方法として**プライベートリンク**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。ウィザードを続行するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 - 1. [Azureポータル](https://portal.azure.com/)に移動し、storageアカウントに移動します。 + 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 2. **「ネットワーク」** > **「プライベートエンドポイント接続」**をクリックします。 diff --git a/tidb-cloud/import-sample-data-serverless.md b/tidb-cloud/import-sample-data-serverless.md index e7266e6be129b..9fc15adde9b5f 100644 --- a/tidb-cloud/import-sample-data-serverless.md +++ b/tidb-cloud/import-sample-data-serverless.md @@ -3,7 +3,7 @@ title: Import Sample Data (SQL Files) into TiDB Cloud Starter or Essential from summary: TiDB Cloud StarterまたはTiDB Cloud EssentialにUI経由でサンプルデータをインポートする方法を学びましょう。 --- -# クラウドストレージからサンプルデータ（SQLファイル）をTiDB Cloud StarterまたはEssentialにインポートする {#import-sample-data-sql-files-into-tidb-cloud-starter-or-essential-from-cloud-storage} +# クラウドストレージからサンプルデータ（SQLファイル）をTiDB Cloud StarterまたはEssentialにインポートする {#import-sample-data-sql-files-into-tidb-cloud-starter-or-essential-from-cloud-ストレージ} このドキュメントでは、UI を介してサンプルデータ (SQL ファイル) をTiDB Cloud StarterまたはTiDB Cloud Essentialにインポートする方法について説明します。使用するサンプルデータは、Capital Bikeshare のデータライセンス契約に基づいて公開されている Capital Bikeshare のシステムデータです。サンプルデータをインポートする前に、 TiDB Cloud StarterまたはEssential のインスタンスが 1 つ必要です。 diff --git a/tidb-cloud/import-sample-data.md b/tidb-cloud/import-sample-data.md index 80ff45a3a9d86..ea5b317a176e8 100644 --- a/tidb-cloud/import-sample-data.md +++ b/tidb-cloud/import-sample-data.md @@ -3,14 +3,14 @@ title: Import Sample Data (SQL Files) from Cloud Storage into TiDB Cloud Dedicat summary: TiDB Cloud DedicatedにUI経由でサンプルデータをインポートする方法を学びましょう。 --- -# クラウドストレージからサンプルデータ（SQLファイル）をTiDB Cloud Dedicatedにインポートする {#import-sample-data-sql-files-from-cloud-storage-into-tidb-cloud-dedicated} +# クラウドストレージからサンプルデータ（SQLファイル）をTiDB Cloud Dedicatedにインポートする {#import-sample-data-sql-files-from-cloud-ストレージ-into-tidb-cloud-dedicated} -このドキュメントでは、UI を介してサンプルデータ (SQL ファイル) をTiDB Cloud Dedicatedにインポートする方法について説明します。使用するサンプルデータは、Capital Bikeshare のデータライセンス契約に基づいて公開されている Capital Bikeshare のシステムデータです。サンプルデータをインポートする前に、TiDB クラスタが 1 つ必要です。 +このドキュメントでは、UI を介してサンプルデータ (SQL ファイル) をTiDB Cloud Dedicatedにインポートする方法について説明します。使用するサンプルデータは、Capital Bikeshare のデータライセンス契約に基づいて公開されている Capital Bikeshare のシステムデータです。サンプルデータをインポートする前に、TiDB クラスターが 1 つ必要です。
    -1. 対象のTiDB Cloud Dedicatedクラスタの**インポート**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスターの**インポート**ページを開きます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動します。 @@ -42,7 +42,7 @@ summary: TiDB Cloud DedicatedにUI経由でサンプルデータをインポー
    -1. 対象のTiDB Cloud Dedicatedクラスタの**インポート**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスターの**インポート**ページを開きます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動します。 @@ -74,7 +74,7 @@ summary: TiDB Cloud DedicatedにUI経由でサンプルデータをインポー
    -1. 対象のTiDB Cloud Dedicatedクラスタの**インポート**ページを開きます。 +1. 対象のTiDB Cloud Dedicatedクラスターの**インポート**ページを開きます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動します。 @@ -94,23 +94,23 @@ summary: TiDB Cloud DedicatedにUI経由でサンプルデータをインポー - **接続方法**： TiDB CloudがAzure Blob Storageに接続する方法を選択します。サンプルデータをインポートするには、デフォルトの接続方法を使用できます。 - - **パブリック**（デフォルト）：パブリックインターネット経由で接続します。storageアカウントがパブリックネットワークへのアクセスを許可している場合にこのオプションを使用してください。 - - **プライベートリンク**：Azure プライベートエンドポイント経由で接続し、ネットワークから隔離されたアクセスを実現します。storageアカウントがパブリックアクセスをブロックしている場合、またはセキュリティポリシーでプライベート接続が必要な場合にこのオプションを使用します。**プライベートリンク**を選択した場合は、追加フィールド**「Azure Blob Storage リソース ID」**も入力する必要があります。リソース ID を確認するには： + - **パブリック**（デフォルト）：パブリックインターネット経由で接続します。ストレージアカウントがパブリックネットワークへのアクセスを許可している場合にこのオプションを使用してください。 + - **プライベートリンク**：Azure プライベートエンドポイント経由で接続し、ネットワークから隔離されたアクセスを実現します。ストレージアカウントがパブリックアクセスをブロックしている場合、またはセキュリティポリシーでプライベート接続が必要な場合にこのオプションを使用します。**プライベートリンク**を選択した場合は、追加フィールド**「Azure Blob Storage リソース ID」**も入力する必要があります。リソース ID を確認するには： 1. [Azureポータル](https://portal.azure.com/)にアクセスします。 - 2. storageアカウントに移動し、 **[概要]** > **[JSONビュー]**をクリックします。 - 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/storageAccounts/`の形式です。 + 2. ストレージアカウントに移動し、 **[概要]** > **[JSONビュー]**をクリックします。 + 3. `id`プロパティの値をコピーします。リソース ID は`/subscriptions//resourceGroups//providers/Microsoft.Storage/ストレージAccounts/`の形式です。 - **SASトークン**： - サンプルデータには、次の**SASトークン**を使用してください： `sv=2015-04-05&ss=b&srt=co&sp=rl&se=2099-03-01T00%3A00%3A01.0000000Z&sig=cQHvaofmVsUJEbgyf4JFkAwTJGsFOmbQHx03GvVMrNc%3D` 。 - - 自分のデータについては、SAS トークンを使用して Azure Blob Storage にアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-azure-blob-storage-access)参照してください。 + - 自分のデータについては、SAS トークンを使用して Azure Blob Storage にアクセスできます。詳細については、 [Azure Blob Storageへのアクセスを構成する](/tidb-cloud/dedicated-external-ストレージ.md#configure-azure-blob-ストレージ-access)参照してください。 4. **「次へ」**をクリックしてください。 - 接続方法として**プライベートリンク**を選択した場合、 TiDB Cloudはstorageアカウント用のプライベートエンドポイントを作成します。接続を開始するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 + 接続方法として**プライベートリンク**を選択した場合、 TiDB Cloudはストレージアカウント用のプライベートエンドポイントを作成します。接続を開始するには、Azureポータルでこのエンドポイント要求を承認する必要があります。 - 1. [Azureポータル](https://portal.azure.com/)に移動し、storageアカウントに移動します。 + 1. [Azureポータル](https://portal.azure.com/)に移動し、ストレージアカウントに移動します。 2. **「ネットワーク」** > **「プライベートエンドポイント接続」**をクリックします。 diff --git a/tidb-cloud/import-with-mysql-cli.md b/tidb-cloud/import-with-mysql-cli.md index 015431826808e..fa08480533045 100644 --- a/tidb-cloud/import-with-mysql-cli.md +++ b/tidb-cloud/import-with-mysql-cli.md @@ -18,7 +18,7 @@ MySQL CLI を介してTiDB Cloud Dedicatedにデータをインポートする TiDB Cloud Dedicatedクラスターに接続してください。 -1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動します。 2. 左側のナビゲーションペインで、 **[設定]** > **[ネットワーク]**をクリックします。 diff --git a/tidb-cloud/integrate-tidbcloud-with-airbyte.md b/tidb-cloud/integrate-tidbcloud-with-airbyte.md index de95055dc0f68..efaadeb302e8d 100644 --- a/tidb-cloud/integrate-tidbcloud-with-airbyte.md +++ b/tidb-cloud/integrate-tidbcloud-with-airbyte.md @@ -109,7 +109,7 @@ TiDB コネクタの詳細については、 [TiDBソース](https://docs.airbyt - TiDBコネクタは、TiCDCが提供する変更データキャプチャ（CDC）機能を使用できません。増分同期はカーソル機構に基づいて実行されます。 - TiDB の宛先では、デフォルトの正規化モードで`timestamp`型が`varchar`型に変換されます。これは、Airbyte が送信中にタイムスタンプ型を文字列に変換し、TiDB が`cast ('2020-07-28 14:50:15+1:00' as timestamp)`をサポートしていないためです。 -- 一部の大規模な ELT ミッションでは、TiDB の[取引制限](/develop/dev-guide-transaction-restraints.md#large-transaction-restrictions)のパラメーターを増やす必要があります。 +- 一部の大規模な ELT ミッションでは、TiDB の[トランザクション制限](/develop/dev-guide-transaction-restraints.md#large-transaction-restrictions)のパラメーターを増やす必要があります。 ## 関連リソース {#related-resources} diff --git a/tidb-cloud/integrate-tidbcloud-with-n8n.md b/tidb-cloud/integrate-tidbcloud-with-n8n.md index e942dca168723..3a483cbebfeca 100644 --- a/tidb-cloud/integrate-tidbcloud-with-n8n.md +++ b/tidb-cloud/integrate-tidbcloud-with-n8n.md @@ -90,7 +90,7 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ 4. TiDB Cloudノードの認証情報（TiDB Cloud APIキー）を入力してください。 5. **プロジェクト**一覧から、プロジェクトを選択してください。 6. **操作**リストで、 `Create Serverless Cluster`を選択します。 -7. **「クラスタ名」**ボックスに、 TiDB Cloud Starterインスタンスの名前を入力します。 +7. **「クラスター名」**ボックスに、 TiDB Cloud Starterインスタンスの名前を入力します。 8. **リージョン**リストから地域を選択してください。 9. **パスワード**欄に、 TiDB Cloud Starterインスタンスへのログインに使用するパスワードを入力してください。 10. ノードを実行するには、 **「ノードを実行」**をクリックしてください。 @@ -156,7 +156,7 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ 3. 以前のTiDB Cloudノードで入力した認証情報を選択してください。 4. **プロジェクト**一覧から、プロジェクトを選択してください。 5. **操作**リストで、 `Insert`を選択します。 -6. **「クラスタ」** 、 **「ユーザー」** 、 **「データベース」** 、 **「パスワード」**の各ボックスに、それぞれ対応する値を入力してください。 +6. **「クラスター」** 、 **「ユーザー」** 、 **「データベース」** 、 **「パスワード」**の各ボックスに、それぞれ対応する値を入力してください。 7. **表**ボックスに、 `hacker_news_briefing`表を入力します。 8. **「列」**ボックスに`creator, title, link, pubdate, comments, content, guid, isodate`と入力します。 @@ -226,7 +226,7 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ TiDB Cloudノードは[通常のノード](https://docs.n8n.io/workflows/nodes/#regular-nodes)として機能し、次の 5 つの操作のみをサポートします。 -- **サーバーレスクラスタの作成**: TiDB Cloud Starterインスタンスを作成します。 +- **サーバーレスクラスターの作成**: TiDB Cloud Starterインスタンスを作成します。 - **SQLの実行**：TiDBでSQL文を実行します。 - **削除**：TiDB内の行を削除します。 - **Insert** ：TiDBに行を挿入します。 @@ -242,7 +242,7 @@ TiDB Cloudノードは[通常のノード](https://docs.n8n.io/workflows/nodes/# - **TiDB CloudAPI の認証情報**: TiDB CloudAPI キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 - **プロジェクト**： TiDB Cloudプロジェクト名。 - **操作**: このノードの操作。サポートされているすべての操作については、[サポート対象のオペレーション](#supported-operations)を参照してください。 -- **クラスタ**： TiDB Cloud Starterインスタンスの名前を入力してください。 +- **クラスター**： TiDB Cloud Starterインスタンスの名前を入力してください。 - **リージョン**：リージョン名。TiDB Cloud Starterインスタンスをデプロイするリージョンを選択してください。通常は、アプリケーションのデプロイ先に最も近いリージョンを選択してください。 - **パスワード**：rootパスワード。新しいTiDB Cloud Starterインスタンスのパスワードを設定してください。 @@ -252,7 +252,7 @@ TiDB Cloudノードは[通常のノード](https://docs.n8n.io/workflows/nodes/# - **TiDB CloudAPI の認証情報**: TiDB CloudAPI キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 - **プロジェクト**： TiDB Cloudプロジェクト名。 - **操作**: このノードの操作。サポートされているすべての操作については、[サポート対象のオペレーション](#supported-operations)を参照してください。 -- **クラスタ**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 +- **クラスター**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 - **パスワード**： TiDB Cloud Starterインスタンスのパスワード。 - **ユーザー**： TiDB Cloud Starterインスタンスのユーザー名。 - **データベース**：データベース名。 @@ -264,7 +264,7 @@ TiDB Cloudノードは[通常のノード](https://docs.n8n.io/workflows/nodes/# - **TiDB CloudAPI の認証情報**: TiDB CloudAPI キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 - **プロジェクト**： TiDB Cloudプロジェクト名。 - **操作**: このノードの操作。サポートされているすべての操作については、[支援活動](#supported-operations)を参照してください。 -- **クラスタ**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 +- **クラスター**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 - **パスワード**： TiDB Cloud Starterインスタンスのパスワード。 - **ユーザー**： TiDB Cloud Starterインスタンスのユーザー名。 - **データベース**：データベース名。 @@ -277,7 +277,7 @@ TiDB Cloudノードは[通常のノード](https://docs.n8n.io/workflows/nodes/# - **TiDB CloudAPI の認証情報**: TiDB CloudAPI キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 - **プロジェクト**： TiDB Cloudプロジェクト名。 - **操作**: このノードの操作。サポートされているすべての操作については、[支援活動](#supported-operations)を参照してください。 -- **クラスタ**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 +- **クラスター**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 - **パスワード**： TiDB Cloud Starterインスタンスのパスワード。 - **ユーザー**： TiDB Cloud Starterインスタンスのユーザー名。 - **データベース**：データベース名。 @@ -290,7 +290,7 @@ TiDB Cloudノードは[通常のノード](https://docs.n8n.io/workflows/nodes/# - **TiDB CloudAPI の認証情報**: TiDB CloudAPI キーのみをサポートします。 APIキーの作成方法については、 [TiDB Cloud APIキーを取得する](#prerequisites-get-tidb-cloud-api-key)を参照してください。 - **プロジェクト**： TiDB Cloudプロジェクト名。 - **操作**: このノードの操作。サポートされているすべての操作については、[支援活動](#supported-operations)を参照してください。 -- **クラスタ**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 +- **クラスター**： TiDB Cloud Starterインスタンスの名前。既存のインスタンスを1つ選択してください。 - **パスワード**： TiDB Cloud Starterインスタンスのパスワード。 - **ユーザー**： TiDB Cloud Starterインスタンスのユーザー名。 - **データベース**：データベース名。 diff --git a/tidb-cloud/integrate-tidbcloud-with-netlify.md b/tidb-cloud/integrate-tidbcloud-with-netlify.md index 3cc5b6301d980..ada682ed3cb20 100644 --- a/tidb-cloud/integrate-tidbcloud-with-netlify.md +++ b/tidb-cloud/integrate-tidbcloud-with-netlify.md @@ -54,7 +54,7 @@ TiDB Cloudは、すぐに開発を始められるように、TypeScriptとNext.j TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスの場合、接続文字列は[TiDB Cloud CLI](/tidb-cloud/cli-reference.md)または[TiDB Cloudコンソール](https://tidbcloud.com/)から取得できます。 。 -TiDB Cloud Dedicatedクラスタの場合、接続文字列はTiDB Cloudコンソールからのみ取得できます。 +TiDB Cloud Dedicatedクラスターの場合、接続文字列はTiDB Cloudコンソールからのみ取得できます。
    diff --git a/tidb-cloud/integrate-tidbcloud-with-vercel.md b/tidb-cloud/integrate-tidbcloud-with-vercel.md index 947b5dcdbba46..2f23bb2a2dc8b 100644 --- a/tidb-cloud/integrate-tidbcloud-with-vercel.md +++ b/tidb-cloud/integrate-tidbcloud-with-vercel.md @@ -18,7 +18,7 @@ TiDB CloudとVercelを組み合わせることで、MySQL互換のリレーシ 上記2つの方法のいずれにおいても、 TiDB Cloudはデータベースにプログラムで接続するための以下のオプションを提供します。 -- クラスタ: 直接接続または[サーバーレスドライバー](/develop/serverless-driver.md)レス ドライバーを使用して、 TiDB Cloudクラスターを Vercel プロジェクトに接続します。 +- クラスター: 直接接続または[サーバーレスドライバー](/develop/serverless-driver.md)レス ドライバーを使用して、 TiDB Cloudクラスターを Vercel プロジェクトに接続します。 - [データアプリ](/tidb-cloud/data-service-manage-data-app.md): HTTP エンドポイントのコレクションを通じてTiDB Cloudクラスターのデータにアクセスします。 ## 前提条件 {#prerequisites} @@ -34,7 +34,7 @@ Vercelにアカウントとプロジェクトをお持ちであることが前 Vercelプロジェクトは、1つのTiDB Cloudクラスターにしか接続できません。統合を変更するには、まず現在のクラスターとの接続を解除してから、新しいクラスターに接続する必要があります。 -### TiDB CloudアカウントとTiDBクラスタ {#a-tidb-cloud-account-and-a-tidb-cluster} +### TiDB CloudアカウントとTiDBクラスター {#a-tidb-cloud-account-and-a-tidb-cluster} TiDB Cloudにアカウントとクラスターが既に作成されている必要があります。アカウントとクラスターをお持ちでない場合は、以下の手順に従って作成してください。 @@ -88,8 +88,8 @@ TiDB Cloud Vercel 統合経由で接続するには、 [Vercelの統合マーケ 1. 対象となるVercelプロジェクトを選択し、 **「次へ」**をクリックしてください。 2. 対象となるTiDB Cloud組織とプロジェクトを選択してください。 - 3. 接続タイプとして**「クラスタ」**を選択してください。 - 4. 対象のTiDB Cloudリソースを選択してください。**クラスタの**ドロップダウン リストが空の場合、または新しいTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスを選択する場合は、リストの**[+クラスタの作成**] をクリックして作成してください。 + 3. 接続タイプとして**「クラスター」**を選択してください。 + 4. 対象のTiDB Cloudリソースを選択してください。**クラスターの**ドロップダウン リストが空の場合、または新しいTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスを選択する場合は、リストの**[+クラスターの作成**] をクリックして作成してください。 5. 接続するデータベースを選択してください。**データベースの**ドロップダウンリストが空の場合、または新しいデータベースを選択する場合は、リスト内の**「+ データベースの作成**」をクリックして作成してください。 6. Vercelプロジェクトで使用しているフレームワークを選択してください。対象のフレームワークが一覧にない場合は、 **「一般」**を選択してください。フレームワークによって環境変数が異なります。 7. プレビュー環境用に新しいブランチを作成するために、**ブランチ機能**を有効にするかどうかを選択してください。 @@ -97,7 +97,7 @@ TiDB Cloud Vercel 統合経由で接続するには、 [Vercelの統合マーケ ![Vercel Integration Page](/media/tidb-cloud/vercel/integration-link-cluster-page.png) -6. Vercelダッシュボードに戻り、Vercelプロジェクトに移動して、 **[設定]** > **[環境変数]**をクリックし、対象のTiDBクラスタの環境変数が自動的に追加されているかどうかを確認してください。 +6. Vercelダッシュボードに戻り、Vercelプロジェクトに移動して、 **[設定]** > **[環境変数]**をクリックし、対象のTiDBクラスターの環境変数が自動的に追加されているかどうかを確認してください。 以下の変数が追加された場合、積分は完了です。 @@ -161,7 +161,7 @@ TiDB Cloud Vercel 統合経由で接続するには、 [Vercelの統合マーケ ![Vercel Integration Configuration Page](/media/tidb-cloud/vercel/integration-vercel-configuration-page.png) - 接続を削除すると、統合ワークフローによって設定された環境変数もVercelプロジェクトから削除されます。ただし、この操作はTiDB Cloudクラスタのデータには影響しません。 + 接続を削除すると、統合ワークフローによって設定された環境変数もVercelプロジェクトから削除されます。ただし、この操作はTiDB Cloudクラスターのデータには影響しません。 ### TiDB Cloudのブランチ機能に接続します {#connect-with-branching} {#connect-with-branching} @@ -173,10 +173,10 @@ Vercel の[プレビュー展開](https://vercel.com/docs/deployments/preview-de TiDB Cloud Branching を有効にするには、 [TiDB Cloud Vercel統合ワークフロー](#integration-workflow)で次のことを確認する必要があります。 -1. 接続タイプとして**「クラスタ」**を選択してください。 +1. 接続タイプとして**「クラスター」**を選択してください。 2. プレビュー環境用の新しいブランチを作成するには、**ブランチ機能**を有効にしてください。 -Gitリポジトリに変更をプッシュすると、Vercelがプレビューデプロイメントをトリガーします。TiDB Cloudとの連携により、Gitブランチ用のTiDB Cloudクラスタのブランチが自動的に作成され、環境変数が設定されます。詳細な手順は以下のとおりです。 +Gitリポジトリに変更をプッシュすると、Vercelがプレビューデプロイメントをトリガーします。TiDB Cloudとの連携により、Gitブランチ用のTiDB Cloudクラスターのブランチが自動的に作成され、環境変数が設定されます。詳細な手順は以下のとおりです。 1. Gitリポジトリに新しいブランチを作成します。 @@ -191,7 +191,7 @@ Gitリポジトリに変更をプッシュすると、Vercelがプレビュー ![Vercel Preview\_Deployment](/media/tidb-cloud/vercel/vercel-preview-deployment.png) - 1. デプロイ時に、 TiDB Cloud統合機能は、Gitブランチと同じ名前のブランチをクラスタ用に自動的に作成します。ブランチが既に存在する場合は、 TiDB Cloud統合機能はこの手順をスキップします。 + 1. デプロイ時に、 TiDB Cloud統合機能は、Gitブランチと同じ名前のブランチをクラスター用に自動的に作成します。ブランチが既に存在する場合は、 TiDB Cloud統合機能はこの手順をスキップします。 ![TiDB\_Cloud\_Branch\_Check](/media/tidb-cloud/vercel/tidbcloud-branch-check.png) @@ -216,9 +216,9 @@ Gitリポジトリに変更をプッシュすると、Vercelがプレビュー
    -1. TiDBクラスタの接続情報を取得します。 +1. TiDBクラスターの接続情報を取得します。 - 接続情報は、クラスタの接続ダイアログから取得できます。ダイアログを開くには、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象リソースの名前をクリックして概要ページを開き、右上隅の**[接続]**をクリックします。 + 接続情報は、クラスターの接続ダイアログから取得できます。ダイアログを開くには、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象リソースの名前をクリックして概要ページを開き、右上隅の**[接続]**をクリックします。 2. Vercel ダッシュボード > Vercel プロジェクト >**設定**>**環境変数**に移動し、TiDB クラスターの接続情報に従って[各環境変数の値を宣言する](https://vercel.com/docs/concepts/projects/environment-variables#declare-an-environment-variable)。 diff --git a/tidb-cloud/integrate-tidbcloud-with-zapier.md b/tidb-cloud/integrate-tidbcloud-with-zapier.md index 333d040e8d846..796a1ca38adf0 100644 --- a/tidb-cloud/integrate-tidbcloud-with-zapier.md +++ b/tidb-cloud/integrate-tidbcloud-with-zapier.md @@ -105,7 +105,7 @@ Zapier で[TiDB Cloudアプリ](https://zapier.com/apps/tidb-cloud/integrations) 3. アクションを設定する - 1. 前の手順と同様に、**プロジェクト名**、**クラスタ名**、 **TiDBパスワード**、**データベース名**を入力してください。 + 1. 前の手順と同様に、**プロジェクト名**、**クラスター名**、 **TiDBパスワード**、**データベース名**を入力してください。 2. 「**テーブル名」**で、ドロップダウンリストから「 **github_global_event」**テーブルを選択します。テーブルの列が表示されます。 @@ -149,7 +149,7 @@ Zapier で[TiDB Cloudアプリ](https://zapier.com/apps/tidb-cloud/integrations) | トリガー | 説明 | | ------------ | ----------------------------------------- | -| 新しいクラスタ | 新しいクラスターが作成されたときにトリガーされます。 | +| 新しいクラスター | 新しいクラスターが作成されたときにトリガーされます。 | | 新しいテーブル | 新しいテーブルが作成されたときにトリガーされます。 | | 新しい行 | 新しい行が作成されたときにトリガーされます。直近の10,000行のみを取得します。 | | 新規行（カスタムクエリ） | 指定したカスタムクエリから新しい行が返されたときにトリガーされます。 | @@ -160,8 +160,8 @@ Zapier で[TiDB Cloudアプリ](https://zapier.com/apps/tidb-cloud/integrations) | アクション | 説明 | リソース | | ------------- | ------------------------------------------------------------- | --------------------------------------- | -| クラスタの検索 | 既存のTiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスタを検索します。 | なし | -| クラスタを作成する | 新しいクラスターを作成します。TiDB TiDB Cloud Starterインスタンスの作成のみをサポートしています。 | なし | +| クラスターの検索 | 既存のTiDB Cloud StarterインスタンスまたはTiDB Cloud Dedicatedクラスターを検索します。 | なし | +| クラスターを作成する | 新しいクラスターを作成します。TiDB TiDB Cloud Starterインスタンスの作成のみをサポートしています。 | なし | | データベースの検索 | 既存のデータベースを検索します。 | TiDB Cloud Starterインスタンス | | データベースを作成する | 新しいデータベースを作成します。 | TiDB Cloud Starterインスタンス | | テーブルを探す | 既存のテーブルを検索します。 | TiDB Cloud Starterインスタンスとデータベース | diff --git a/tidb-cloud/key-concepts.md b/tidb-cloud/key-concepts.md index 48e7ede575bba..fc3ebc9a114bb 100644 --- a/tidb-cloud/key-concepts.md +++ b/tidb-cloud/key-concepts.md @@ -9,15 +9,15 @@ summary: TiDB Cloudの主要な概念について学びましょう。 ## アーキテクチャ {#architecture} -TiDB Cloudは、コンピューティングをstorageから分離するクラウドネイティブの分散アーキテクチャ上に構築されており、柔軟なスケーリングと高可用性を実現します。 [TiDB Cloudアーキテクチャの詳細についてはこちらをご覧ください。](/tidb-cloud/architecture-concepts.md) +TiDB Cloudは、コンピューティングをストレージから分離するクラウドネイティブの分散アーキテクチャ上に構築されており、柔軟なスケーリングと高可用性を実現します。 [TiDB Cloudアーキテクチャの詳細についてはこちらをご覧ください。](/tidb-cloud/architecture-concepts.md) ## データベーススキーマ {#database-schema} TiDB Cloudを使用すると、データベース、テーブル、列、インデックス、制約などのオブジェクトを使用してデータを整理および構造化できます。また、一時テーブル、ベクター インデックス、キャッシュされたテーブルなどの高度な機能もサポートしています。[データベーススキーマについて詳しくはこちらをご覧ください](/tidb-cloud/database-schema-concepts.md)。 -## 取引 {#transactions} +## トランザクション {#transactions} -TiDB は完全な分散トランザクションを提供し、モデルには[Googleパーコレーター](https://research.google.com/pubs/pub36726.html)に基づいていくつかの最適化が施さ[取引について詳しくはこちらをご覧ください](/tidb-cloud/transaction-concepts.md)ています。 +TiDB は完全な分散トランザクションを提供し、モデルには[Googleパーコレーター](https://research.google.com/pubs/pub36726.html)に基づいていくつかの最適化が施さ[トランザクションについて詳しくはこちらをご覧ください](/tidb-cloud/transaction-concepts.md)ています。 ## SQL {#sql} @@ -33,7 +33,7 @@ TiDB Cloudの AI 機能を使用すると、データの探索、検索、統合 ## 拡張性 {#scalability} -TiDB Cloud Dedicated を使用すると、データ量やワークロードの変化に合わせてコンピューティング リソースとstorageリソースを個別に調整できます。[拡張性について詳しくはこちらをご覧ください](/tidb-cloud/scalability-concepts.md)。 +TiDB Cloud Dedicated を使用すると、データ量やワークロードの変化に合わせてコンピューティング リソースとストレージリソースを個別に調整できます。[拡張性について詳しくはこちらをご覧ください](/tidb-cloud/scalability-concepts.md)。 ## 高可用性 {#high-availability} @@ -48,7 +48,7 @@ TiDB Cloudは、TiDB のパフォーマンスと健全性の包括的なモニ ## データストリーミング {#data-streaming} -TiDB Cloud を使用すると、データ変更を Kafka、MySQL、オブジェクトstorageなどの他のシステムにストリーミングできます。データ ストリーミング[データストリーミングについて詳しくはこちらをご覧ください](/tidb-cloud/data-streaming-concepts.md)。 +TiDB Cloud を使用すると、データ変更を Kafka、MySQL、オブジェクトストレージなどの他のシステムにストリーミングできます。データ ストリーミング[データストリーミングについて詳しくはこちらをご覧ください](/tidb-cloud/data-streaming-concepts.md)。 ## バックアップと復元 {#backup-x26-restore} diff --git a/tidb-cloud/limitations-and-quotas.md b/tidb-cloud/limitations-and-quotas.md index c561a552dfdf6..4b52b347be972 100644 --- a/tidb-cloud/limitations-and-quotas.md +++ b/tidb-cloud/limitations-and-quotas.md @@ -11,9 +11,9 @@ TiDB Cloud、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-d > > これらの制限または割り当てが組織にとって問題となる場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 -## クラスタの制限 {#cluster-limits} +## クラスターの制限 {#cluster-limits} -| 成分 | 制限 | +| コンポーネント | 制限 | | :---------------------------------------------------------- | :- | | [データ領域](/tidb-cloud/tidb-cloud-glossary.md#region)部あたりのコピー数 | 3 | | クロスゾーン展開のアベイラビリティゾーンの数 | 3 | @@ -22,14 +22,14 @@ TiDB Cloud、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-d > > TiDB の一般的な使用上の制限について詳しくは、 [TiDB の制限](https://docs.pingcap.com/tidb/stable/tidb-limitations)を参照してください。 -## クラスタクォータ {#cluster-quotas} +## クラスタークォータ {#cluster-quotas} -| 成分 | クォータ（デフォルト） | +| コンポーネント | クォータ（デフォルト） | | :---------------------------- | :---------- | -| 組織内のすべてのクラスタの合計 TiDB ノードの最大数 | 10 | -| 組織内のすべてのクラスタの合計 TiKV ノードの最大数 | 15 | -| 組織内のすべてのクラスタのTiFlashノードの最大数 | 5 | -| 組織内のすべてのクラスタの TiProxy ノードの最大数 | 10 | +| 組織内のすべてのクラスターの合計 TiDB ノードの最大数 | 10 | +| 組織内のすべてのクラスターの合計 TiKV ノードの最大数 | 15 | +| 組織内のすべてのクラスターのTiFlashノードの最大数 | 5 | +| 組織内のすべてのクラスターの TiProxy ノードの最大数 | 10 | > **注記：** > diff --git a/tidb-cloud/manage-projects-and-resources.md b/tidb-cloud/manage-projects-and-resources.md index 381b966aff2df..5bbad8f0fad65 100644 --- a/tidb-cloud/manage-projects-and-resources.md +++ b/tidb-cloud/manage-projects-and-resources.md @@ -45,7 +45,7 @@ TiDB Cloudリソースを作成するには、組織の[**私のTiDB**](https:// - [TiDB Cloud Premiumインスタンスを作成する](/tidb-cloud/premium/create-tidb-instance-premium.md) -- [TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md) +- [TiDB Cloud Dedicatedクラスターを作成する](/tidb-cloud/create-tidb-cluster.md) ### TiDB Cloudのリソースを管理する {#manage-tidb-cloud-resources} @@ -76,7 +76,7 @@ TiDB Cloudのリソースをプロジェクトごとにグループ化して表 > **注記：** > > - 無料トライアルユーザーは新規プロジェクトを作成できません。 -> - TiDB Xインスタンスの場合、プロジェクトの作成は任意です。TiDB Cloud Dedicatedクラスタの場合は、デフォルトのプロジェクトを使用するか、新しいプロジェクトを作成して管理する必要があります。 +> - TiDB Xインスタンスの場合、プロジェクトの作成は任意です。TiDB Cloud Dedicatedクラスターの場合は、デフォルトのプロジェクトを使用するか、新しいプロジェクトを作成して管理する必要があります。 `Organization Owner`の役割をお持ちの場合は、組織内でプロジェクトを作成できます。 @@ -98,7 +98,7 @@ TiDB Cloudのリソースをプロジェクトごとにグループ化して表 > > TiDB Cloud Premium インスタンスの場合、暗号化はプロジェクトごとではなくインスタンスごとに構成されます。インスタンスを作成した後、 [二重層データ暗号化](/tidb-cloud/premium/dual-layer-data-encryption-premium.md)有効にして、デフォルトのストレージ層の暗号化に加えてデータベース層の暗号化を追加できます。 - - プロジェクトがTiDB Cloud Dedicatedクラスター用に作成されている場合は、 **「Dedicatedクラスタ用に作成」**オプションを選択し、プロジェクトの [顧客管理型暗号化キー（CMEK）](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md)と[メンテナンスウィンドウ](/tidb-cloud/configure-maintenance-window.md)を構成して、 **「確認」**をクリックします。 + - プロジェクトがTiDB Cloud Dedicatedクラスター用に作成されている場合は、 **「Dedicatedクラスター用に作成」**オプションを選択し、プロジェクトの [顧客管理型暗号化キー（CMEK）](/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md)と[メンテナンスウィンドウ](/tidb-cloud/configure-maintenance-window.md)を構成して、 **「確認」**をクリックします。 ### プロジェクトを管理する {#manage-a-project} @@ -123,7 +123,7 @@ TiDB Cloudのリソースをプロジェクトごとにグループ化して表 > **注記：** > -> TiDB Xインスタンスのみが、TiDB Xプロジェクト間の移動およびTiDB Xプロジェクトからの離脱をサポートしています。TiDB Cloud Dedicatedクラスタは、プロジェクト間の移動をサポートしていません。 +> TiDB Xインスタンスのみが、TiDB Xプロジェクト間の移動およびTiDB Xプロジェクトからの離脱をサポートしています。TiDB Cloud Dedicatedクラスターは、プロジェクト間の移動をサポートしていません。 TiDB Xインスタンスを移動するには、以下の手順を実行してください。 diff --git a/tidb-cloud/manage-serverless-spend-limit.md b/tidb-cloud/manage-serverless-spend-limit.md index ab0b9cbe0f5b5..95e50ff224645 100644 --- a/tidb-cloud/manage-serverless-spend-limit.md +++ b/tidb-cloud/manage-serverless-spend-limit.md @@ -17,11 +17,11 @@ TiDB Cloudの各組織につき、最大 5 つの [無料のTiDB Cloud Starter 組織内の最初の 5 つのTiDB Cloud Starterインスタンス（無料版かスケーラブル版かを問わず）については、 TiDB Cloud はそれぞれに以下の無料使用クォ​​ータを提供します。 -- 行ベースstorage：5 GiB -- カラム型storage：5 GiB +- 行ベースストレージ：5 GiB +- カラム型ストレージ：5 GiB - [要求単位（RU）](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) : 5,000万RU/月 -TiDB Cloud Starterインスタンスが使用クォータに達すると、ユーザーが または新しい月の開始時に使用がリセットさ[割り当てを増やす](#update-spending-limit)まで、新しい接続試行は即座に拒否されます。クォータに達する前に確立された既存の接続はアクティブなままですが、スロットリングが発生します。たとえば、無料のTiDB Cloud StarterTiDB Cloud Starterの行ベースのstorageが5 GiB を超えると、 TiDB Cloud Starterインスタンスは自動的に新しい接続試行を制限します。 +TiDB Cloud Starterインスタンスが使用クォータに達すると、ユーザーが または新しい月の開始時に使用がリセットさ[割り当てを増やす](#update-spending-limit)まで、新しい接続試行は即座に拒否されます。クォータに達する前に確立された既存の接続はアクティブなままですが、スロットリングが発生します。たとえば、無料のTiDB Cloud StarterTiDB Cloud Starterの行ベースのストレージが5 GiB を超えると、 TiDB Cloud Starterインスタンスは自動的に新しい接続試行を制限します。 さまざまなリソース（読み取り、書き込み、SQL CPU、ネットワーク出力など）のRU消費量、価格の詳細、およびスロットリング情報の詳細については、 [TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)参照してください。 diff --git a/tidb-cloud/manage-user-access.md b/tidb-cloud/manage-user-access.md index 4ebce96c1f969..9669f657c1981 100644 --- a/tidb-cloud/manage-user-access.md +++ b/tidb-cloud/manage-user-access.md @@ -13,7 +13,7 @@ TiDB Cloudにアクセスする前に、 [TiDB Cloudアカウントを作成す TiDB Cloudは、組織、プロジェクト、リソースに基づいた階層構造を採用しており、ユーザーとTiDBデプロイメントの管理を支援します。 -- TiDB Cloudの[リソース](/tidb-cloud/tidb-cloud-glossary.md#tidb-cloud-resource)TiDB X インスタンスまたはTiDB Cloud Dedicatedクラスタのいずれかです。TiDB X インスタンスは、 [TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md)上に構築されたサービス指向のTiDB Cloudオファリングです。TiDB Cloud Starter、 Essential、Premium インスタンスなどがあります。 +- TiDB Cloudの[リソース](/tidb-cloud/tidb-cloud-glossary.md#tidb-cloud-resource)TiDB X インスタンスまたはTiDB Cloud Dedicatedクラスターのいずれかです。TiDB X インスタンスは、 [TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md)上に構築されたサービス指向のTiDB Cloudオファリングです。TiDB Cloud Starter、 Essential、Premium インスタンスなどがあります。 - A [プロジェクト](/tidb-cloud/tidb-cloud-glossary.md#project)は、 TiDB Cloudリソースのコンテナです。 @@ -71,7 +71,7 @@ TiDB Cloudは組織レベルで課金計算を行い、各プロジェクトお TiDB Cloudには、3種類のプロジェクトがあります。 -- **TiDB Dedicatedプロジェクト**：このプロジェクトタイプは、 TiDB Cloud Dedicatedクラスタでのみ使用されます。RBAC、ネットワーク、メンテナンス、アラート購読、暗号化アクセスなど、 TiDB Cloud Dedicatedクラスタの設定をプロジェクトごとに個別に管理できます。 +- **TiDB Dedicatedプロジェクト**：このプロジェクトタイプは、 TiDB Cloud Dedicatedクラスターでのみ使用されます。RBAC、ネットワーク、メンテナンス、アラート購読、暗号化アクセスなど、 TiDB Cloud Dedicatedクラスターの設定をプロジェクトごとに個別に管理できます。 - **TiDB X プロジェクト**: このプロジェクト タイプは、TiDB X インスタンス ( TiDB Cloud Starter、 Essential、Premium インスタンスを含む) でのみ使用されます。プロジェクトごとに TiDB X インスタンスの RBAC を管理できます。TiDB X プロジェクトは[**私のTiDB**](https://tidbcloud.com/tidbs)ページでプロジェクトを作成する際のデフォルトのプロジェクト タイプです。 - **TiDB X 仮想プロジェクト**: このプロジェクトは仮想プロジェクトであり、管理機能は提供しません。これは、どのプロジェクトにも属さない TiDB X インスタンスの仮想コンテナとして機能するため、これらのインスタンスには、プロジェクト ID を使用してTiDB CloudAPI 経由でアクセスできます。各組織には一意の仮想プロジェクト ID があります。この ID は、TiDB Cloud API の[アクセス可能なプロジェクトをすべて一覧表示します。](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Project/operation/ListProjects) 。 @@ -133,7 +133,7 @@ TiDB Cloudは、組織、プロジェクト、インスタンスの各レベル | プロジェクトへのユーザーの招待や削除、およびユーザーのプロジェクトにおける役割の編集を行います。 | ✅ | ❌ | ❌ | ❌ | | プロジェクトの[データベース監査ログ](/tidb-cloud/tidb-cloud-auditing.md)管理します。 | ✅ | ❌ | ❌ | ❌ | | プロジェクト内のすべてのTiDB Cloud Starterインスタンスの[支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)を管理します。 | ✅ | ❌ | ❌ | ❌ | -| プロジェクトの種類に応じてサポートされるインスタンスやクラスタの作成、変更、移動、削除など、プロジェクト内のリソース操作を管理します。 | ✅ | ❌ | ❌ | ❌ | +| プロジェクトの種類に応じてサポートされるインスタンスやクラスターの作成、変更、移動、削除など、プロジェクト内のリソース操作を管理します。 | ✅ | ❌ | ❌ | ❌ | | プロジェクト内のTiDB Cloud StarterおよびTiDB Cloud Essentialインスタンスのブランチを管理します。ブランチの作成、接続、削除などを行います。 | ✅ | ❌ | ❌ | ❌ | | データインポート、データバックアップと復元、データ移行などのリソースデータを管理します。 | ✅ | ✅ | ❌ | ❌ | | データを読み取るためのエンドポイントの使用または作成など、データ読み取り専用操作の[データサービス](/tidb-cloud/data-service-overview.md)を管理します。 | ✅ | ✅ | ✅ | ❌ | diff --git a/tidb-cloud/migrate-from-mysql-using-aws-dms.md b/tidb-cloud/migrate-from-mysql-using-aws-dms.md index d931b6c63c699..13f483559686a 100644 --- a/tidb-cloud/migrate-from-mysql-using-aws-dms.md +++ b/tidb-cloud/migrate-from-mysql-using-aws-dms.md @@ -11,7 +11,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ このドキュメントでは、Amazon RDSを例として、AWS DMSを使用してTiDB Cloudにデータを移行する方法を示します。この手順は、セルフホスト型のMySQLデータベースまたはAmazon AuroraからTiDB Cloudへのデータ移行にも適用できます。 -この例では、データソースはAmazon RDS、データ宛先はTiDB Cloud内のTiDB Cloud Dedicatedクラスタです。アップストリームデータベースとダウンストリームデータベースはどちらも同じリージョンにあります。 +この例では、データソースはAmazon RDS、データ宛先はTiDB Cloud内のTiDB Cloud Dedicatedクラスターです。アップストリームデータベースとダウンストリームデータベースはどちらも同じリージョンにあります。 ## 前提条件 {#prerequisites} @@ -46,7 +46,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ - **エンジンバージョン**：デフォルト設定を使用します。 - **マルチAZ** ：ビジネスニーズに応じて、**シングルAZ**または**マルチAZ**を選択してください。 -5. storageは**「割り当て済みstorage（GiB）」**フィールドで設定します。デフォルト設定を使用してください。 +5. ストレージは**「割り当て済みストレージ（GiB）」**フィールドで設定します。デフォルト設定を使用してください。 6. 接続性とセキュリティを設定します。 - **ネットワークタイプ - 新規**: **IPv4**を選択してください。 @@ -100,7 +100,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ 2. TiDB Cloudコンソールで、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、対象のリソース名をクリックしてから、右上隅の**[接続]**をクリックすると、 TiDB Cloudデータベースの接続情報が表示されます。 -3. ダイアログの**「ステップ 1: トラフィック フィルタの作成」**で、 **「編集」**をクリックし、AWS DMS コンソールからコピーしたパブリック IP アドレスとプライベート IP アドレスを入力して、 **「フィルタの更新」**をクリックします。AWS DMS レプリケーション インスタンスのパブリック IP アドレスとプライベート IP アドレスを TiDB クラスタのトラフィック フィルタに同時に追加することをお勧めします。そうしないと、状況によっては AWS DMS が TiDB クラスタに接続できない場合があります。 +3. ダイアログの**「ステップ 1: トラフィック フィルタの作成」**で、 **「編集」**をクリックし、AWS DMS コンソールからコピーしたパブリック IP アドレスとプライベート IP アドレスを入力して、 **「フィルタの更新」**をクリックします。AWS DMS レプリケーション インスタンスのパブリック IP アドレスとプライベート IP アドレスを TiDB クラスターのトラフィック フィルタに同時に追加することをお勧めします。そうしないと、状況によっては AWS DMS が TiDB クラスターに接続できない場合があります。 4. **CA証明書をダウンロードするには、[CA証明書のダウンロード]**をクリックします。ダイアログの**[ステップ3：SQLクライアントで接続する**]で、接続文字列内の`-u` 、 `-h` 、および`-P`情報を後で使用するためにメモしておきます。 @@ -108,7 +108,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ 6. 対応する情報を設定します。 [VPCピアリング接続を設定する](/tidb-cloud/set-up-vpc-peering-connections.md)参照してください。 -7. TiDBクラスタのターゲットエンドポイントを設定します。 +7. TiDBクラスターのターゲットエンドポイントを設定します。 - **エンドポイントタイプ**：**ターゲットエンドポイント**を選択してください。 - **エンドポイント識別子**：エンドポイントの名前を入力してください。 @@ -120,9 +120,9 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ 8. [AWS DMSコンソール](https://console.aws.amazon.com/dms/v2/home)で、 **[エンドポイントの作成]**をクリックしてターゲットデータベースエンドポイントを作成し、次の情報を設定します。 - **サーバー名**: 記録した`-h`情報である TiDB クラスターのホスト名を入力してください。 - - **ポート**：記録した`-P`情報と同じTiDBクラスタのポート番号を入力してください。TiDBクラスタのデフォルトポートは4000です。 + - **ポート**：記録した`-P`情報と同じTiDBクラスターのポート番号を入力してください。TiDBクラスターのデフォルトポートは4000です。 - **ユーザー名**: TiDB クラスターのユーザー名を入力してください。これは、記録した`-u`情報です。 - - **パスワード**：TiDBクラスタのパスワードを入力してください。 + - **パスワード**：TiDBクラスターのパスワードを入力してください。 - **セキュリティソケットレイヤー（SSL）モード**： **Verify-ca**を選択します。 - **「新しいCA証明書を追加」を**クリックして、前の手順でTiDB CloudコンソールからダウンロードしたCAファイルをインポートします。 diff --git a/tidb-cloud/migrate-from-mysql-using-data-migration.md b/tidb-cloud/migrate-from-mysql-using-data-migration.md index 04011589cd7e6..fb4be9983686f 100644 --- a/tidb-cloud/migrate-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-from-mysql-using-data-migration.md @@ -1,12 +1,12 @@ --- title: Migrate MySQL-Compatible Databases to TiDB Cloud Using Data Migration -summary: データ移行機能を使用して、Amazon Aurora MySQL、Amazon RDS、Azure Database for MySQL - Flexible Server、Google Cloud SQL for MySQL、またはセルフマネージドのMySQLインスタンスから、ダウンタイムを最小限に抑えながらMySQLデータベースをTiDB Cloudにシームレスに移行する方法を学びましょう。 +summary: データ移行機能を使用して、Amazon Aurora MySQL、Amazon RDS、Azure Database for MySQL - Flexible Server、Google Cloud SQL for MySQL、またはSelf-ManagedのMySQLインスタンスから、ダウンタイムを最小限に抑えながらMySQLデータベースをTiDB Cloudにシームレスに移行する方法を学びましょう。 aliases: ['/ja/tidbcloud/migrate-data-into-tidb','/ja/tidbcloud/migrate-incremental-data-from-mysql'] --- # データ移行を使用してMySQL互換データベースをTiDB Cloudに移行する {#migrate-mysql-compatible-databases-to-tidb-cloud-using-data-migration} -このドキュメントでは、TiDB Cloud のデータ移行機能を使用して、Amazon Aurora MySQL、Amazon RDS、Azure Database for MySQL - Flexible Server、Google Cloud SQL for MySQL、またはセルフマネージド MySQL インスタンスからTiDB Cloud Dedicated 、 TiDB Cloud Essential TiDB Cloudプレミアム[TiDB Cloudコンソール](https://tidbcloud.com/)Cloud Premium へ MySQL データベースを移行する手順を説明します。 +このドキュメントでは、TiDB Cloud のデータ移行機能を使用して、Amazon Aurora MySQL、Amazon RDS、Azure Database for MySQL - Flexible Server、Google Cloud SQL for MySQL、またはSelf-Managed MySQL インスタンスからTiDB Cloud Dedicated 、 TiDB Cloud Essential TiDB Cloudプレミアム[TiDB Cloudコンソール](https://tidbcloud.com/)Cloud Premium へ MySQL データベースを移行する手順を説明します。 @@ -74,7 +74,7 @@ TiDB Cloud Essentialインスタンスでは、組織ごとに最大 100 個の -- TiDB CloudでTiDB Cloud Dedicatedクラスタを削除すると、そのクラスタ内のすべての移行ジョブが自動的に削除され、復元できなくなります。 +- TiDB CloudでTiDB Cloud Dedicatedクラスターを削除すると、そのクラスター内のすべての移行ジョブが自動的に削除され、復元できなくなります。 @@ -115,7 +115,7 @@ Alibaba Cloud RDSをデータソースとして使用する場合、すべての -- 増分データ移行中に、移行対象のテーブルが既にターゲットデータベースに重複キーで存在する場合、エラーが報告され、移行は中断されます。この場合、MySQLソースデータが正確であることを確認する必要があります。データが正確であれば、移行ジョブの**「再開」**ボタンをクリックすると、移行ジョブはターゲットのTiDB Cloud Dedicatedクラスタ内の競合レコードをMySQLソースレコードに置き換えます。 +- 増分データ移行中に、移行対象のテーブルが既にターゲットデータベースに重複キーで存在する場合、エラーが報告され、移行は中断されます。この場合、MySQLソースデータが正確であることを確認する必要があります。データが正確であれば、移行ジョブの**「再開」**ボタンをクリックすると、移行ジョブはターゲットのTiDB Cloud Dedicatedクラスター内の競合レコードをMySQLソースレコードに置き換えます。 @@ -195,7 +195,7 @@ TiDB Cloud Premium の場合、データ移行機能は次の MySQL 互換ソー DM を使用して、ソースの MySQL 互換データベースからターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud EssentialインスタンスTiDB Cloud Premiumインスタンスに増分変更を継続的にレプリケートするには、ソース データベースでバイナリ ログを有効にするために次の構成が必要です。 -| コンフィグレーション | 必要値 | なぜ | +| 設定 | 必要値 | なぜ | | :------------------------------- | :------------------------------- | :---------------------------------------- | | `log_bin` | `ON` | DMがTiDBへの変更を複製するために使用するバイナリログを有効にします。 | | `binlog_format` | `ROW` | すべてのデータ変更を正確に記録します（他の形式では例外的なケースを見落とします）。 | @@ -338,7 +338,7 @@ TiDB Cloud Premiumで利用可能な接続方法は以下のとおりです。
    TLS/SSL暗号化接続用のクラウドプロバイダーの証明書をダウンロードして保存する -- Amazon Aurora MySQL または Amazon RDS MySQL: [SSL/TLSを使用してDBインスタンスまたはクラスタへの接続を暗号化する](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.SSL.html) +- Amazon Aurora MySQL または Amazon RDS MySQL: [SSL/TLSを使用してDBインスタンスまたはクラスターへの接続を暗号化する](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/UsingWithRDS.SSL.html) - Azure Database for MySQL - フレキシブル サーバー: [暗号化された接続で接続します](https://learn.microsoft.com/en-us/azure/mysql/flexible-server/how-to-connect-tls-ssl) - Google Cloud SQL for MySQL: [SSL/TLS証明書の管理](https://cloud.google.com/sql/docs/mysql/manage-ssl-instance) - Alibaba Cloud RDS MySQL: [SSL暗号化機能を設定する](https://www.alibabacloud.com/help/en/rds/apsaradb-rds-for-mysql/configure-a-cloud-certificate-to-enable-ssl-encryption) @@ -399,7 +399,7 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ > **注記：** > - > RDS プライベート IP は、フェールオーバー、メンテナンス、またはstorageの拡張時に変更される可能性があります。実稼働デプロイメントについては、本番ローテーション パターンについて、AWS データベース ブログの[AWS PrivateLinkとネットワークロードバランサーを使用して、VPCをまたいでAmazon RDSにアクセスします。](https://aws.amazon.com/blogs/database/access-amazon-rds-across-vpcs-using-aws-privatelink-and-network-load-balancer/)参照してください。 + > RDS プライベート IP は、フェールオーバー、メンテナンス、またはストレージの拡張時に変更される可能性があります。実稼働デプロイメントについては、本番ローテーション パターンについて、AWS データベース ブログの[AWS PrivateLinkとネットワークロードバランサーを使用して、VPCをまたいでAmazon RDSにアクセスします。](https://aws.amazon.com/blogs/database/access-amazon-rds-across-vpcs-using-aws-privatelink-and-network-load-balancer/)参照してください。 詳細な手順については、AWS ドキュメントの[ネットワークロードバランサーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)参照してください。 @@ -485,7 +485,7 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ > **注記：** > - > RDS プライベート IP は、フェールオーバー、メンテナンス、またはstorageの拡張時に変更される可能性があります。実稼働デプロイメントについては、本番ローテーション パターンについて、AWS データベース ブログの[AWS PrivateLinkとネットワークロードバランサーを使用して、VPCをまたいでAmazon RDSにアクセスします。](https://aws.amazon.com/blogs/database/access-amazon-rds-across-vpcs-using-aws-privatelink-and-network-load-balancer/)参照してください。 + > RDS プライベート IP は、フェールオーバー、メンテナンス、またはストレージの拡張時に変更される可能性があります。実稼働デプロイメントについては、本番ローテーション パターンについて、AWS データベース ブログの[AWS PrivateLinkとネットワークロードバランサーを使用して、VPCをまたいでAmazon RDSにアクセスします。](https://aws.amazon.com/blogs/database/access-amazon-rds-across-vpcs-using-aws-privatelink-and-network-load-balancer/)参照してください。 詳細な手順については、AWS ドキュメントの[ネットワークロードバランサーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)参照してください。 @@ -616,7 +616,7 @@ MySQLサービスがGoogle Cloud VPC内にある場合は、以下の手順を | `RELOAD` | グローバル | フルダンプ中に一貫性のあるスナップショットを保証します | | `REPLICATION SLAVE` | グローバル | 増分データ移行のためのbinlogストリーミングを有効にする | | `REPLICATION CLIENT` | グローバル | binlogの位置とサーバーの状態へのアクセスを提供します | -| `LOCK TABLES` | 表 | ソースがマネージド MySQL サービス (Amazon RDS、 Aurora、ApsaraDB RDS for MySQL、Azure Database for MySQL、Google Cloud SQL など) であり、 `FLUSH TABLES WITH READ LOCK` (FTWRL) が許可されていない場合に必要です。この場合、DM は`LOCK TABLES`にフォールバックし、完全なデータエクスポート中の一貫性を確保します。FTWRL が利用可能なセルフマネージド MySQL インスタンスには不要です。 | +| `LOCK TABLES` | 表 | ソースがマネージド MySQL サービス (Amazon RDS、 Aurora、ApsaraDB RDS for MySQL、Azure Database for MySQL、Google Cloud SQL など) であり、 `FLUSH TABLES WITH READ LOCK` (FTWRL) が許可されていない場合に必要です。この場合、DM は`LOCK TABLES`にフォールバックし、完全なデータエクスポート中の一貫性を確保します。FTWRL が利用可能なSelf-Managed MySQL インスタンスには不要です。 | 例えば、ソースのMySQLインスタンスで次の`GRANT`ステートメントを使用すると、対応する権限を付与できます。 @@ -644,7 +644,7 @@ GRANT SELECT, RELOAD, LOCK TABLES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* | `ALTER` | 表 | スキーマ変更時にテーブル定義を修正します | | `DROP` | データベース、テーブル | スキーマ同期中にオブジェクトを削除します | | `INDEX` | 表 | インデックスを作成および変更します | -| `CREATE VIEW` | 閲覧数 | マイグレーションで使用されるビューを作成します | +| `CREATE VIEW` | ビュー | マイグレーションで使用されるビューを作成します | たとえば、ターゲットのTiDB Cloud DedicatedクラスターTiDB Cloud Essential インスタンスTiDB Cloud Essentialインスタンスインスタンスで次の`GRANT`ステートメントを実行して、対応するTiDB Cloud Premiumインスタンスを付与できます。 @@ -817,7 +817,7 @@ TiDB Cloudへのデータ移行を一度で完了させるには、 **「既存 > **注記：** > -> - 物理モードを使用する場合、既存のデータ移行が完了する前に、 TiDB Cloud Dedicatedクラスタに対して2つ目の移行ジョブまたはインポートタスクを作成することはできません。 +> - 物理モードを使用する場合、既存のデータ移行が完了する前に、 TiDB Cloud Dedicatedクラスターに対して2つ目の移行ジョブまたはインポートタスクを作成することはできません。 > - 物理モードを使用し、移行ジョブが開始されたら、 TiDB Cloud Dedicatedクラスターで PITR (ポイントインタイムリカバリ) を有効にしたり、変更フィードを設定したり**しないで**ください。そうしないと、移行ジョブが停止します。PITR を有効にしたり、変更フィードを設定したりする必要がある場合は、代わりに論理モードを使用してデータを移行してください。 物理モードでは、MySQLソースデータを可能な限り高速にエクスポートするため、 [異なる仕様](/tidb-cloud/tidb-cloud-billing-dm.md#specifications-for-data-migration)データエクスポート時のMySQLソースデータベースのQPSとTPSに対するパフォーマンスへの影響が異なります。以下の表は、各仕様のパフォーマンス低下を示しています。 @@ -967,7 +967,7 @@ TiDB Cloud Dedicatedは、さまざまなシナリオにおけるパフォーマ 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動します。 -2. 対象のTiDB Cloud Dedicatedクラスタの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**「データ」** > **「データ移行」**をクリックします。 +2. 対象のTiDB Cloud Dedicatedクラスターの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**「データ」** > **「データ移行」**をクリックします。 3. **データ移行**ページで、スケールアップする移行ジョブを探します。**アクション**列で、 **[...]** > **[スケールアップ/スケールダウン]**をクリックします。 diff --git a/tidb-cloud/migrate-from-op-tidb.md b/tidb-cloud/migrate-from-op-tidb.md index 5c9d229b1f01f..e2b2d5f851cfd 100644 --- a/tidb-cloud/migrate-from-op-tidb.md +++ b/tidb-cloud/migrate-from-op-tidb.md @@ -3,9 +3,9 @@ title: Migrate from TiDB Self-Managed to TiDB Cloud summary: TiDB Self-ManagedからTiDB Cloudへのデータ移行方法を学びましょう。 --- -# TiDBセルフマネージドからTiDB Cloudへの移行 {#migrate-from-tidb-self-managed-to-tidb-cloud} +# TiDB Self-ManagedからTiDB Cloudへの移行 {#migrate-from-tidb-self-managed-to-tidb-cloud} -このドキュメントでは、 DumplingとTiCDCを使用して、TiDBセルフマネージドクラスタからTiDB Cloud（AWS上）へデータを移行する方法について説明します。 +このドキュメントでは、 DumplingとTiCDCを使用して、TiDB Self-ManagedクラスターからTiDB Cloud（AWS上）へデータを移行する方法について説明します。 全体の手順は以下のとおりです。 @@ -77,11 +77,11 @@ tiup update --self && tiup update dumpling ### TiCDCをデプロイ {#deploy-ticdc} -アップストリームの TiDB セルフマネージド クラスターからダウンストリームのTiDB Cloudリソースに増分データをレプリケートするには、 [TiCDCをデプロイする](https://docs.pingcap.com/tidb/dev/deploy-ticdc)必要があります。 +アップストリームの TiDB Self-Managed クラスターからダウンストリームのTiDB Cloudリソースに増分データをレプリケートするには、 [TiCDCをデプロイする](https://docs.pingcap.com/tidb/dev/deploy-ticdc)必要があります。 1. アップストリーム TiDB 自己管理クラスターの現在の TiDB バージョンが TiCDC をサポートしているかどうかを確認します。 TiDB v4.0.8.rc.1 以降のバージョンは TiCDC をサポートします。 TiDB のバージョンを確認するには、上流の TiDB 自己管理クラスターで`select tidb_version();`を実行します。アップグレードする必要がある場合は、 [TiUPを使用してTiDBをアップグレードする](https://docs.pingcap.com/tidb/dev/deploy-ticdc#upgrade-ticdc-using-tiup)参照してください。 -2. TiCDCコンポーネントをアップストリームの TiDB 自己管理クラスターに追加します。 [TiUPを使用して、既存のTiDBクラスタにTiCDCを追加またはスケールアウトします。](https://docs.pingcap.com/tidb/dev/deploy-ticdc#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup)参照してください。 `scale-out.yml`ファイルを編集して TiCDC を追加します。 +2. TiCDCコンポーネントをアップストリームの TiDB 自己管理クラスターに追加します。 [TiUPを使用して、既存のTiDBクラスターにTiCDCを追加またはスケールアウトします。](https://docs.pingcap.com/tidb/dev/deploy-ticdc#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup)参照してください。 `scale-out.yml`ファイルを編集して TiCDC を追加します。 ```yaml cdc_servers: @@ -102,20 +102,20 @@ tiup update --self && tiup update dumpling ## 全てのデータを移行する {#migrate-full-data} -TiDBセルフマネージドクラスタからTiDB Cloudへデータを移行するには、以下の手順で完全なデータ移行を実行します。 +TiDB Self-ManagedクラスターからTiDB Cloudへデータを移行するには、以下の手順で完全なデータ移行を実行します。 -1. TiDBセルフマネージドクラスターからAmazon S3へデータを移行します。 +1. TiDB Self-ManagedクラスターからAmazon S3へデータを移行します。 2. Amazon S3からTiDB Cloudへデータを移行します。 -### TiDBセルフマネージドクラスターからAmazon S3へデータを移行する {#migrate-data-from-the-tidb-self-managed-cluster-to-amazon-s3} +### TiDB Self-ManagedクラスターからAmazon S3へデータを移行する {#migrate-data-from-the-tidb-self-managed-cluster-to-amazon-s3} -TiDBセルフマネージドクラスターからAmazon S3へDumplingを使用してデータを移行する必要があります。 +TiDB Self-ManagedクラスターからAmazon S3へDumplingを使用してデータを移行する必要があります。 -TiDBセルフマネージドクラスターがローカルIDCにある場合、またはDumplingサーバーとAmazon S3間のネットワークが接続されていない場合は、まずファイルをローカルstorageにエクスポートしてから、後でAmazon S3にアップロードすることができます。 +TiDB Self-ManagedクラスターがローカルIDCにある場合、またはDumplingサーバーとAmazon S3間のネットワークが接続されていない場合は、まずファイルをローカルストレージにエクスポートしてから、後でAmazon S3にアップロードすることができます。 -#### ステップ1. アップストリームのTiDBセルフマネージドクラスタのGCメカニズムを一時的に無効にします。 {#step-1-disable-the-gc-mechanism-of-the-upstream-tidb-self-managed-cluster-temporarily} +#### ステップ1. アップストリームのTiDB Self-ManagedクラスターのGCメカニズムを一時的に無効にします。 {#step-1-disable-the-gc-mechanism-of-the-upstream-tidb-self-managed-cluster-temporarily} -増分移行中に新しく書き込まれたデータが失われないようにするには、移行を開始する前にアップストリームクラスタのガベージコレクション（GC）メカニズムを無効にして、システムが履歴データをクリーンアップしないようにする必要があります。 +増分移行中に新しく書き込まれたデータが失われないようにするには、移行を開始する前にアップストリームクラスターのガベージコレクション（GC）メカニズムを無効にして、システムが履歴データをクリーンアップしないようにする必要があります。 設定が成功したかどうかを確認するには、次のコマンドを実行してください。 @@ -151,7 +151,7 @@ AWS コンソールでアクセスキーを作成します。詳細について #### ステップ3. Dumplingを使用して、上流のTiDBクラスターからAmazon S3にデータをエクスポートします。 {#step-3-export-data-from-the-upstream-tidb-cluster-to-amazon-s3-using-dumpling} -Dumplingを使用して、アップストリームのTiDBクラスタからAmazon S3にデータをエクスポートするには、次の手順を実行します。 +Dumplingを使用して、アップストリームのTiDBクラスターからAmazon S3にデータをエクスポートするには、次の手順を実行します。 1. Dumplingの環境変数を設定します。 @@ -199,12 +199,12 @@ Dumplingを使用して、アップストリームのTiDBクラスタからAmazo ### Amazon S3からTiDB Cloudへデータを移行する {#migrate-data-from-amazon-s3-to-tidb-cloud} -TiDBセルフマネージドクラスターからAmazon S3にデータをエクスポートした後、データをTiDB Cloudに移行する必要があります。 +TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポートした後、データをTiDB Cloudに移行する必要があります。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)以下のドキュメントに従って、対象のTiDBリソースのアカウントIDと外部IDを取得してください。 - - TiDB Cloud Dedicatedクラスターについては、 [ロールARNを使用してAmazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access-using-a-role-arn)参照してください。 - - TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスについては、 [ロールARNを使用してAmazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access-using-a-role-arn)参照してください。 + - TiDB Cloud Dedicatedクラスターについては、 [ロールARNを使用してAmazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-ストレージ.md#configure-amazon-s3-access-using-a-role-arn)参照してください。 + - TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスについては、 [ロールARNを使用してAmazon S3へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-amazon-s3-access-using-a-role-arn)参照してください。 2. Amazon S3 のアクセス権限を設定します。通常、以下の読み取り専用権限が必要です。 @@ -307,7 +307,7 @@ TiDBセルフマネージドクラスターからAmazon S3にデータをエク --start-ts="431434047157698561" ``` - - `--pd` : アップストリームクラスタのPDアドレス。形式は`[upstream_pd_ip]:[pd_port]`です。 + - `--pd` : アップストリームクラスターのPDアドレス。形式は`[upstream_pd_ip]:[pd_port]`です。 - `--sink-uri` : レプリケーション タスクのダウンストリーム アドレス。 `--sink-uri`は、次の形式に従って構成します。現在、このスキームは`mysql` 、 `tidb` 、 `kafka` 、 `s3` 、および`local` 。 @@ -317,11 +317,11 @@ TiDBセルフマネージドクラスターからAmazon S3にデータをエク - `--changefeed-id` : レプリケーションタスクのID。形式は、^[a-zA-Z0-9]+(-[a-zA-Z0-9]+)*$ の正規表現に一致する必要があります。このIDが指定されていない場合、TiCDCは自動的にUUID（バージョン4形式）をIDとして生成します。 - - `--start-ts` : 変更フィードの開始TSOを指定します。TiCDCクラスタはこのTSOからデータの取得を開始します。デフォルト値は現在時刻です。 + - `--start-ts` : 変更フィードの開始TSOを指定します。TiCDCクラスターはこのTSOからデータの取得を開始します。デフォルト値は現在時刻です。 - 詳細については、 [TiCDC ChangefeedsのCLIとコンフィグレーションパラメータ](https://docs.pingcap.com/tidb/dev/ticdc-changefeed-config)を参照してください。 + 詳細については、 [TiCDC ChangefeedsのCLIと設定パラメータ](https://docs.pingcap.com/tidb/dev/ticdc-changefeed-config)を参照してください。 -5. アップストリームクラスタでGCメカニズムを再度有効にします。増分レプリケーションでエラーや遅延が検出されない場合は、GCメカニズムを有効にして、アップストリームクラスタのガベージコレクションを再開します。 +5. アップストリームクラスターでGCメカニズムを再度有効にします。増分レプリケーションでエラーや遅延が検出されない場合は、GCメカニズムを有効にして、アップストリームクラスターのガベージコレクションを再開します。 設定が正しく機能しているかどうかを確認するには、以下のコマンドを実行してください。 @@ -353,11 +353,11 @@ TiDBセルフマネージドクラスターからAmazon S3にデータをエク ![Update Filter](/media/tidb-cloud/normal_status_in_replication_task.png) - - レプリケーションを確認します。アップストリームクラスタに新しいレコードを書き込み、そのレコードがダウンストリームのTiDB Cloudリソースにレプリケートされているかどうかを確認します。 + - レプリケーションを確認します。アップストリームクラスターに新しいレコードを書き込み、そのレコードがダウンストリームのTiDB Cloudリソースにレプリケートされているかどうかを確認します。 7. アップストリームとダウンストリームで同じタイムゾーンを設定してください。デフォルトでは、 TiDB CloudはタイムゾーンをUTCに設定します。アップストリームとダウンストリームでタイムゾーンが異なる場合は、両方で同じタイムゾーンを設定する必要があります。 - 1. 上流の TiDB セルフマネージド クラスタで、次のコマンドを実行してタイムゾーンを確認します。 + 1. 上流の TiDB Self-Managed クラスターで、次のコマンドを実行してタイムゾーンを確認します。 ```sql SELECT @@global.time_zone; @@ -375,17 +375,17 @@ TiDBセルフマネージドクラスターからAmazon S3にデータをエク SELECT @@global.time_zone; ``` -8. をバックアップします アップストリームの TiDB セルフマネージド クラスターでバックアップし、ダウンストリームのTiDB Cloudリソースに復元します。クエリ バインディングをバックアップするには[クエリバインディング](/sql-plan-management.md)次のクエリを使用できます。 +8. をバックアップします アップストリームの TiDB Self-Managed クラスターでバックアップし、ダウンストリームのTiDB Cloudリソースに復元します。クエリ バインディングをバックアップするには[クエリバインディング](/sql-plan-management.md)次のクエリを使用できます。 ```sql SELECT DISTINCT(CONCAT('CREATE GLOBAL BINDING FOR ', original_sql,' USING ', bind_sql,';')) FROM mysql.bind_info WHERE status='enabled'; ``` - 出力が得られない場合は、クエリバインディングがアップストリームクラスタで使用されていない可能性があります。この場合は、この手順をスキップできます。 + 出力が得られない場合は、クエリバインディングがアップストリームクラスターで使用されていない可能性があります。この場合は、この手順をスキップできます。 クエリバインディングを取得したら、下流のTiDB Cloudリソースでそれらを実行して、クエリバインディングを復元します。 -9. 上流の TiDB セルフマネージド クラスタでユーザー情報と権限情報をバックアップし、下流のTiDB Cloudリソースに復元します。ユーザー情報と権限情報のバックアップには、以下のスクリプトを使用できます。プレースホルダーを実際の値に置き換える必要があることに注意してください。 +9. 上流の TiDB Self-Managed クラスターでユーザー情報と権限情報をバックアップし、下流のTiDB Cloudリソースに復元します。ユーザー情報と権限情報のバックアップには、以下のスクリプトを使用できます。プレースホルダーを実際の値に置き換える必要があることに注意してください。 ```shell #!/bin/bash diff --git a/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md b/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md index 7558e82165312..1d31d9b416a1c 100644 --- a/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-incremental-data-from-mysql-using-data-migration.md @@ -47,7 +47,7 @@ summary: データ移行を使用して、Amazon Aurora MySQL、Amazon Relationa 増分データの移行開始位置としてGTIDを指定する場合、以下の制限事項に注意してください。 - ソースデータベースでGTIDモードが有効になっていることを確認してください。 -- ソースデータベースがMySQLの場合、MySQLのバージョンは5.6以降である必要があり、storageエンジンはInnoDBである必要があります。 +- ソースデータベースがMySQLの場合、MySQLのバージョンは5.6以降である必要があり、ストレージエンジンはInnoDBである必要があります。 - 移行ジョブがアップストリームのセカンダリデータベースに接続する場合、 `REPLICATE CREATE TABLE ... SELECT`イベントは移行できません。これは、ステートメントが同じ GTID が割り当てられた 2 つのトランザクション ( `CREATE TABLE`と`INSERT` ) に分割されるためです。その結果、 `INSERT`ステートメントはセカンダリデータベースによって無視されます。 ## 前提条件 {#prerequisites} diff --git a/tidb-cloud/migrate-metrics-integrations.md b/tidb-cloud/migrate-metrics-integrations.md index 4e4e54aee8b2d..cbe43605f87bb 100644 --- a/tidb-cloud/migrate-metrics-integrations.md +++ b/tidb-cloud/migrate-metrics-integrations.md @@ -1,11 +1,11 @@ --- title: Migrate Datadog and New Relic Integrations -summary: DatadogとNew Relicにおける、従来のプロジェクトレベルのメトリクス統合から新しいクラスタレベルの統合への移行方法を学びましょう。 +summary: DatadogとNew Relicにおける、従来のプロジェクトレベルのメトリクス統合から新しいクラスターレベルの統合への移行方法を学びましょう。 --- # DatadogとNew Relicの統合を移行する {#migrate-datadog-and-new-relic-integrations} -TiDB Cloudは、DatadogおよびNew Relicとの連携をクラスタレベルで管理するようになり、よりきめ細かな制御と設定が可能になりました。従来のプロジェクトレベルのDatadogおよびNew Relic連携は、2025年10月31日に廃止されます。組織でこれらの従来の連携をまだ使用している場合は、このガイドに従って新しいクラスタレベルの連携に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 +TiDB Cloudは、DatadogおよびNew Relicとの連携をクラスターレベルで管理するようになり、よりきめ細かな制御と設定が可能になりました。従来のプロジェクトレベルのDatadogおよびNew Relic連携は、2025年10月31日に廃止されます。組織でこれらの従来の連携をまだ使用している場合は、このガイドに従って新しいクラスターレベルの連携に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 ## 前提条件 {#prerequisites} diff --git a/tidb-cloud/migrate-prometheus-metrics-integrations.md b/tidb-cloud/migrate-prometheus-metrics-integrations.md index d7f8c1ad567f6..aac0038d2ef75 100644 --- a/tidb-cloud/migrate-prometheus-metrics-integrations.md +++ b/tidb-cloud/migrate-prometheus-metrics-integrations.md @@ -1,11 +1,11 @@ --- title: Migrate Prometheus Integrations -summary: 従来のプロジェクトレベルのPrometheus統合から、新しいクラスタレベルのPrometheus統合への移行方法を学びましょう。 +summary: 従来のプロジェクトレベルのPrometheus統合から、新しいクラスターレベルのPrometheus統合への移行方法を学びましょう。 --- # Prometheus統合の移行 {#migrate-prometheus-integrations} -TiDB Cloud は、 [Prometheusとの統合](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)クラスタレベルで管理するようになり、よりきめ細かな制御と構成が可能になりました。従来のプロジェクトレベルの Prometheus 統合 (ベータ版) は、2026 年 1 月 9 日に廃止されます。組織でこれらの従来の統合をまだ使用している場合は、このガイドに従って新しいクラスタレベルの Prometheus 統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 +TiDB Cloud は、 [Prometheusとの統合](/tidb-cloud/monitor-prometheus-and-grafana-integration.md)クラスターレベルで管理するようになり、よりきめ細かな制御と構成が可能になりました。従来のプロジェクトレベルの Prometheus 統合 (ベータ版) は、2026 年 1 月 9 日に廃止されます。組織でこれらの従来の統合をまだ使用している場合は、このガイドに従って新しいクラスターレベルの Prometheus 統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 ## 前提条件 {#prerequisites} diff --git a/tidb-cloud/migrate-sql-shards.md b/tidb-cloud/migrate-sql-shards.md index 13c59abde0e35..eeac83fcfc3ab 100644 --- a/tidb-cloud/migrate-sql-shards.md +++ b/tidb-cloud/migrate-sql-shards.md @@ -11,7 +11,7 @@ summary: 大規模データセットのMySQLシャードをTiDB Cloudに移行 ## 例の環境情報 {#environment-information-in-the-example} -このセクションでは、例で使用されているアップストリームクラスタ、DM、およびダウンストリームTiDB Cloudの基本情報について説明します。 +このセクションでは、例で使用されているアップストリームクラスター、DM、およびダウンストリームTiDB Cloudの基本情報について説明します。 ### 上流クラスター {#upstream-cluster} @@ -38,9 +38,9 @@ summary: 大規模データセットのMySQLシャードをTiDB Cloudに移行 ### DM {#dm} -DM のバージョンは v5.3.0 です。 TiDB DM を手動でデプロイする必要があります。詳細な手順については、 [TiUPを使用してDMクラスタをデプロイ](https://docs.pingcap.com/tidb/stable/deploy-a-dm-cluster-using-tiup)を参照してください。 +DM のバージョンは v5.3.0 です。 TiDB DM を手動でデプロイする必要があります。詳細な手順については、 [TiUPを使用してDMクラスターをデプロイ](https://docs.pingcap.com/tidb/stable/deploy-a-dm-cluster-using-tiup)を参照してください。 -### 外部storage {#external-storage} +### 外部ストレージ {#external-ストレージ} この文書では、Amazon S3を例として使用します。 @@ -74,7 +74,7 @@ Dumplingを使用してデータをAmazon S3にエクスポートする場合、 - アップストリームクラスターのbinlogを有効にします。 - 適切なAmazon S3ディレクトリとリージョンを選択してください。 -- 上流クラスタへの影響を最小限に抑えるには、 `-t`オプションを設定して適切な同時実行数を選択するか、バックアップ データベースから直接エクスポートしてください。このパラメータの使用方法の詳細については、 [Dumplingのオプション一覧](https://docs.pingcap.com/tidb/stable/dumpling-overview#option-list-of-dumpling)参照してください。 +- 上流クラスターへの影響を最小限に抑えるには、 `-t`オプションを設定して適切な同時実行数を選択するか、バックアップ データベースから直接エクスポートしてください。このパラメータの使用方法の詳細については、 [Dumplingのオプション一覧](https://docs.pingcap.com/tidb/stable/dumpling-overview#option-list-of-dumpling)参照してください。 - `--filetype csv`と`--no-schemas`に適切な値を設定します。これらのパラメーターの使用方法の詳細については、 [Dumplingのオプション一覧](https://docs.pingcap.com/tidb/stable/dumpling-overview#option-list-of-dumpling)参照してください。 CSVファイルの名前は以下のようにしてください。 @@ -108,7 +108,7 @@ CSVファイルの名前は以下のようにしてください。 [root@localhost ~]# tiup dumpling -u {username} -p {password} -P {port} -h {mysql02-ip} -B store_01,store_02 -r 20000 --filetype csv --no-schemas -o "s3://dumpling-s3/store/sales/instance02/" --s3.region "ap-northeast-1" ``` -詳細な手順については、 [データをAmazon S3クラウドstorageにエクスポートする](https://docs.pingcap.com/tidb/stable/dumpling-overview#export-data-to-amazon-s3-cloud-storage)参照してください。 +詳細な手順については、 [データをAmazon S3クラウドストレージにエクスポートする](https://docs.pingcap.com/tidb/stable/dumpling-overview#export-data-to-amazon-s3-cloud-ストレージ)参照してください。 ### ステップ3. スキーマを作成しますTiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスター {#step-3-create-schemas-in-customcontent-plan-starter-tidb-cloud-starter-instance-customcontent-customcontent-plan-essential-tidb-cloud-essential-instance-customcontent-customcontent-plan-premium-tidb-cloud-premium-instance-customcontent-customcontent-plan-dedicated-tidb-cloud-dedicated-cluster-customcontent} @@ -138,7 +138,7 @@ Query OK, 0 rows affected (0.17 sec) ### ステップ4. Amazon S3へのアクセスを設定する {#step-4-configure-amazon-s3-access} -[Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)」の手順に従って、ソースデータにアクセスするためのロール ARN を取得します。 +[Amazon S3へのアクセスを設定する](/tidb-cloud/dedicated-external-ストレージ.md#configure-amazon-s3-access)」の手順に従って、ソースデータにアクセスするためのロール ARN を取得します。 以下の例では、主要なポリシー設定のみを示しています。Amazon S3 のパスを、ご自身の値に置き換えてください。 @@ -235,11 +235,11 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 ## MySQLからTiDB Cloudへの増分データレプリケーションを実行する {#perform-incremental-data-replication-from-mysql-to-tidb-cloud} -上流クラスタの指定された位置からbinlogに基づいてデータ変更をTiDB Cloudに複製するには、TiDBデータ移行（DM）を使用して増分レプリケーションを実行できます。 +上流クラスターの指定された位置からbinlogに基づいてデータ変更をTiDB Cloudに複製するには、TiDBデータ移行（DM）を使用して増分レプリケーションを実行できます。 ### 始める前に {#before-you-begin} -増分データを移行し、MySQL シャードをTiDB Cloudにマージする場合は、TiDB DM を手動でデプロイする必要があります。これは、 TiDB Cloud がMySQL シャードの移行とマージをまだサポートしていないためです。詳細な手順については、 [TiUPを使用してDMクラスタをデプロイ](https://docs.pingcap.com/tidb/stable/deploy-a-dm-cluster-using-tiup)を参照してください。 +増分データを移行し、MySQL シャードをTiDB Cloudにマージする場合は、TiDB DM を手動でデプロイする必要があります。これは、 TiDB Cloud がMySQL シャードの移行とマージをまだサポートしていないためです。詳細な手順については、 [TiUPを使用してDMクラスターをデプロイ](https://docs.pingcap.com/tidb/stable/deploy-a-dm-cluster-using-tiup)を参照してください。 ### ステップ1. データソースを追加する {#step-1-add-the-data-source} @@ -275,7 +275,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 port: 3308 ``` -3. ターミナルで次のコマンドを実行します。 `tiup dmctl`を使用して、最初のデータソース構成をDMクラスタにロードします。 +3. ターミナルで次のコマンドを実行します。 `tiup dmctl`を使用して、最初のデータソース構成をDMクラスターにロードします。 ```shell [root@localhost ~]# tiup dmctl --master-addr ${advertise-addr} operate-source create dm-source1.yaml @@ -285,7 +285,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 | パラメータ | 説明 | | ----------------------- | ------------------------------------------------------------------------- | - | `--master-addr` | `{advertise-addr}`が接続されるクラスタ内の任意のDMマスターノードの`dmctl` 。例：192.168.11.110:9261 | + | `--master-addr` | `{advertise-addr}`が接続されるクラスター内の任意のDMマスターノードの`dmctl` 。例：192.168.11.110:9261 | | `operate-source create` | データソースをDMクラスターにロードします。 | 以下は出力例です。 @@ -310,7 +310,7 @@ Amazon S3へのアクセスを設定した後、 TiDB Cloudコンソールで次 ``` -4. ターミナルで次のコマンドを実行します。 `tiup dmctl`を使用して、2番目のデータソース構成をDMクラスタにロードします。 +4. ターミナルで次のコマンドを実行します。 `tiup dmctl`を使用して、2番目のデータソース構成をDMクラスターにロードします。 ```shell [root@localhost ~]# tiup dmctl --master-addr 192.168.11.110:9261 operate-source create dm-source2.yaml @@ -470,7 +470,7 @@ Starting component `dmctl`: /root/.tiup/components/dmctl/${tidb_version}/dmctl/d | パラメータ | 説明 | | --------------- | ------------------------------------------------------------------------- | -| `--master-addr` | `{advertise-addr}`が接続されるクラスタ内の任意のDMマスターノードの`dmctl` 。例：192.168.11.110:9261 | +| `--master-addr` | `{advertise-addr}`が接続されるクラスター内の任意のDMマスターノードの`dmctl` 。例：192.168.11.110:9261 | | `start-task` | 移行タスクを開始します。 | 以下は出力例です。 diff --git a/tidb-cloud/monitor-alert-email.md b/tidb-cloud/monitor-alert-email.md index f0b2aba582858..ee0da46c18cff 100644 --- a/tidb-cloud/monitor-alert-email.md +++ b/tidb-cloud/monitor-alert-email.md @@ -9,7 +9,7 @@ TiDB Cloud、電子メール、[スラック](/tidb-cloud/monitor-alert-slack.md > **注記：** > -> 現在、アラート購読は、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンス、 [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)インスタンス、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタで利用可能です。 +> 現在、アラート購読は、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンス、 [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)インスタンス、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターで利用可能です。 ## 前提条件 {#prerequisites} @@ -33,7 +33,7 @@ TiDB Cloud、電子メール、[スラック](/tidb-cloud/monitor-alert-slack.md > **ヒント：** > -> TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスタがある場合でも、購読は一度だけで済みます。 +> TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスターがある場合でも、購読は一度だけで済みます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、組織の[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **[プロジェクト ビュー]**タブをクリックします。 @@ -58,7 +58,7 @@ TiDB Cloud、電子メール、[スラック](/tidb-cloud/monitor-alert-slack.md 8. 購読を完了するには、 **「保存」**をクリックしてください。 -または、 TiDB Cloud Dedicatedクラスタの[**警告**](/tidb-cloud/monitor-built-in-alerting.md#view-alerts)ページの右上隅にある**「購読」を**クリックすることもできます。**アラート購読**ページに移動します。 +または、 TiDB Cloud Dedicatedクラスターの[**警告**](/tidb-cloud/monitor-built-in-alerting.md#view-alerts)ページの右上隅にある**「購読」を**クリックすることもできます。**アラート購読**ページに移動します。 diff --git a/tidb-cloud/monitor-alert-flashduty.md b/tidb-cloud/monitor-alert-flashduty.md index 7fcf1b49c1e91..d46af2a743dd0 100644 --- a/tidb-cloud/monitor-alert-flashduty.md +++ b/tidb-cloud/monitor-alert-flashduty.md @@ -9,7 +9,7 @@ TiDB Cloud、Flashduty、[スラック](/tidb-cloud/monitor-alert-slack.md)、[ > **注記：** > -> 現在、アラート購読は、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンス、 [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)インスタンス、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタで利用可能です。 +> 現在、アラート購読は、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンス、 [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)インスタンス、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターで利用可能です。 ## 前提条件 {#prerequisites} @@ -44,7 +44,7 @@ TiDB Cloud、Flashduty、[スラック](/tidb-cloud/monitor-alert-slack.md)、[ > **ヒント：** > -> TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスタがある場合でも、購読は一度だけで済みます。 +> TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスターがある場合でも、購読は一度だけで済みます。 1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **[プロジェクト ビュー]**タブをクリックします。 @@ -69,7 +69,7 @@ TiDB Cloud、Flashduty、[スラック](/tidb-cloud/monitor-alert-slack.md)、[ 8. 購読を完了するには、 **「保存」**をクリックしてください。 -または、 TiDB Cloud Dedicatedクラスタの**アラート**ページの右上にある**「購読」を**クリックすることもできます。**アラート購読**ページに移動します。 +または、 TiDB Cloud Dedicatedクラスターの**アラート**ページの右上にある**「購読」を**クリックすることもできます。**アラート購読**ページに移動します。 または、クラスターの**アラート**ページの右上隅にある**「購読」を**クリックすることもできます。**アラート購読**ページに移動します。 diff --git a/tidb-cloud/monitor-alert-pagerduty.md b/tidb-cloud/monitor-alert-pagerduty.md index abc6ff8d747b7..0431175bf3db3 100644 --- a/tidb-cloud/monitor-alert-pagerduty.md +++ b/tidb-cloud/monitor-alert-pagerduty.md @@ -9,7 +9,7 @@ TiDB Cloud は、PagerDuty、[スラック](/tidb-cloud/monitor-alert-slack.md) > **注記：** > -> 現在、アラート購読は、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンス、 [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)インスタンス、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタで利用可能です。 +> 現在、アラート購読は、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンス、 [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)インスタンス、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターで利用可能です。 ## 前提条件 {#prerequisites} @@ -44,7 +44,7 @@ TiDB Cloud は、PagerDuty、[スラック](/tidb-cloud/monitor-alert-slack.md) > **ヒント：** > -> TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスタがある場合でも、購読は一度だけで済みます。 +> TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスターがある場合でも、購読は一度だけで済みます。 1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **[プロジェクト ビュー]**タブをクリックします。 @@ -65,7 +65,7 @@ TiDB Cloud は、PagerDuty、[スラック](/tidb-cloud/monitor-alert-slack.md) 8. 購読を完了するには、 **「保存」**をクリックしてください。 -または、 TiDB Cloud Dedicatedクラスタの**アラート**ページの右上にある**「購読」を**クリックすることもできます。**アラート購読**ページに移動します。 +または、 TiDB Cloud Dedicatedクラスターの**アラート**ページの右上にある**「購読」を**クリックすることもできます。**アラート購読**ページに移動します。 または、クラスターの**アラート**ページの右上隅にある**「購読」を**クリックすることもできます。**アラート購読**ページに移動します。 diff --git a/tidb-cloud/monitor-alert-slack.md b/tidb-cloud/monitor-alert-slack.md index ca26c48683f8a..f95439e983f57 100644 --- a/tidb-cloud/monitor-alert-slack.md +++ b/tidb-cloud/monitor-alert-slack.md @@ -1,6 +1,6 @@ --- title: Subscribe via Slack -summary: Slack経由でアラート通知を受け取ることで、TiDBクラスタを監視する方法を学びましょう。 +summary: Slack経由でアラート通知を受け取ることで、TiDBクラスターを監視する方法を学びましょう。 --- # Slack経由で購読する {#subscribe-via-slack} @@ -9,7 +9,7 @@ TiDB Cloud、Slack、[メール](/tidb-cloud/monitor-alert-email.md)、[ズー > **注記：** > -> 現在、アラート購読は、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンス、 [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)インスタンス、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタで利用可能です。 +> 現在、アラート購読は、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンス、 [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)インスタンス、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターで利用可能です。 ## 前提条件 {#prerequisites} @@ -49,7 +49,7 @@ TiDB Cloud Dedicatedクラスターのアラート通知を購読するには、 > **ヒント：** > -> TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスタがある場合でも、購読は一度だけで済みます。 +> TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスターがある場合でも、購読は一度だけで済みます。 1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **[プロジェクト ビュー]**タブをクリックします。 @@ -70,7 +70,7 @@ TiDB Cloud Dedicatedクラスターのアラート通知を購読するには、 8. 購読を完了するには、 **「保存」**をクリックしてください。 -または、対象のTiDB Cloud Dedicatedクラスタの**アラート**ページの右上にある**「購読」を**クリックすることもできます。**アラート購読**ページに移動します。 +または、対象のTiDB Cloud Dedicatedクラスターの**アラート**ページの右上にある**「購読」を**クリックすることもできます。**アラート購読**ページに移動します。 または、クラスターの**アラート**ページの右上隅にある**「購読」を**クリックすることもできます。**アラート購読**ページに移動します。 diff --git a/tidb-cloud/monitor-alert-zoom.md b/tidb-cloud/monitor-alert-zoom.md index 4ccaad4c6fba0..50629033f4bf0 100644 --- a/tidb-cloud/monitor-alert-zoom.md +++ b/tidb-cloud/monitor-alert-zoom.md @@ -1,6 +1,6 @@ --- title: Subscribe via Zoom -summary: Zoom経由でアラート通知を受け取ることで、TiDBクラスタを監視する方法を学びましょう。 +summary: Zoom経由でアラート通知を受け取ることで、TiDBクラスターを監視する方法を学びましょう。 --- # Zoom経由で登録する {#subscribe-via-zoom} @@ -9,7 +9,7 @@ TiDB Cloud は、Zoom、[スラック](/tidb-cloud/monitor-alert-slack.md)、[ > **注記：** > -> 現在、アラート購読は、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンス、 [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)インスタンス、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタで利用可能です。 +> 現在、アラート購読は、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンス、 [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)インスタンス、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターで利用可能です。 ## 前提条件 {#prerequisites} @@ -66,7 +66,7 @@ TiDB Cloud Dedicatedクラスターのアラート通知を購読するには、 > **ヒント：** > -> TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスタがある場合でも、購読は一度だけで済みます。 +> TiDB Cloud Dedicatedの場合、アラートの購読は現在のプロジェクト内のすべてのアラートに適用されます。プロジェクト内に複数のTiDB Cloud Dedicatedクラスターがある場合でも、購読は一度だけで済みます。 1. [TiDB Cloudコンソール](https://tidbcloud.com)で、組織の[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、 **[プロジェクト ビュー]**タブをクリックします。 @@ -87,7 +87,7 @@ TiDB Cloud Dedicatedクラスターのアラート通知を購読するには、 8. 購読を完了するには、 **「保存」**をクリックしてください。 -または、対象のTiDB Cloud Dedicatedクラスタの**アラート**ページの右上にある**「購読」を**クリックすることもできます。**アラート購読**ページに移動します。 +または、対象のTiDB Cloud Dedicatedクラスターの**アラート**ページの右上にある**「購読」を**クリックすることもできます。**アラート購読**ページに移動します。 または、クラスターの**アラート**ページの右上隅にある**「購読」を**クリックすることもできます。**アラート購読**ページに移動します。 diff --git a/tidb-cloud/monitor-built-in-alerting.md b/tidb-cloud/monitor-built-in-alerting.md index f653c8a436aa8..0919165b2121f 100644 --- a/tidb-cloud/monitor-built-in-alerting.md +++ b/tidb-cloud/monitor-built-in-alerting.md @@ -11,7 +11,7 @@ TiDB Cloud を使用すると、アラートの表示、アラートルールの > **注記：** > -> 現在、アラート購読は、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンス、 [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)インスタンス、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタで利用可能です。 +> 現在、アラート購読は、 [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンス、 [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)インスタンス、および[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターで利用可能です。 ## アラートをビュー {#view-alerts} @@ -25,7 +25,7 @@ TiDB Cloudでは、**アラート**ページでアクティブなアラートと > > 複数の組織に所属している場合は、左上隅のコンボボックスを使用して、まず目的の組織に切り替えてください。 -2. 対象のTiDB Cloud EssentialインスタンスまたはTiDB Cloud Dedicatedクラスタの名前をクリックすると、その概要ページに移動します。 +2. 対象のTiDB Cloud EssentialインスタンスまたはTiDB Cloud Dedicatedクラスターの名前をクリックすると、その概要ページに移動します。 3. 左側のナビゲーションペインにある**「アラート」**をクリックします。 @@ -101,8 +101,8 @@ TiDB Cloudは、そのプランで利用可能[特徴](/tidb-cloud/features.md) | TiDBノード全体のCPU使用率が10分間80%を超えました。 | 現在のワークロードにおけるCPU使用率を低減するために、TiDBのノード数またはノードサイズを増やすことを検討してください。 | | TiKVノード全体のCPU使用率が10分間80%を超えました。 | 現在のワークロードにおけるCPU使用率を低減するために、TiKVのノード数またはノードサイズを増やすことを検討してください。 | | TiFlashノード全体のCPU使用率が10分間80%を超えました。 | 現在のワークロードにおけるCPU使用率を低減するために、 TiFlashのノード数またはノードサイズを増やすことを検討してください。 | -| TiKVstorageの利用率は80%を超えました。 | storage容量を増やすには、TiKVのノード数またはノードのstorageサイズを増やすことを検討してください。TiKVのstorage使用率が80%を超えると、レイテンシーの急上昇が発生する可能性があり、使用率が高くなるとリクエストが失敗する場合があります。 | -| TiFlashstorageの利用率は80%を超えています。 | TiFlashのstorage容量を増やすには、ノード数またはノードのstorageサイズを増やすことを検討してください。すべてのTiFlashノードのstorage使用率が80%に達すると、 TiFlashレプリカを追加するDDLステートメントは永久にハングアップします。 | +| TiKVストレージの利用率は80%を超えました。 | ストレージ容量を増やすには、TiKVのノード数またはノードのストレージサイズを増やすことを検討してください。TiKVのストレージ使用率が80%を超えると、レイテンシーの急上昇が発生する可能性があり、使用率が高くなるとリクエストが失敗する場合があります。 | +| TiFlashストレージの利用率は80%を超えています。 | TiFlashのストレージ容量を増やすには、ノード数またはノードのストレージサイズを増やすことを検討してください。すべてのTiFlashノードのストレージ使用率が80%に達すると、 TiFlashレプリカを追加するDDLステートメントは永久にハングアップします。 | | TiDBノード全体の最大メモリ使用率が10分間70%を超えました。 | クラスター内に[ホットスポット](/tidb-cloud/tidb-cloud-sql-tuning-overview.md#hotspot-issues)がないか確認するか、TiDBのノード数またはノードサイズを増やして、現在のワークロードのメモリ使用率を削減することを検討してください。 | | TiKVノード全体の最大メモリ使用率が10分間70%を超えました。 | クラスター内に[ホットスポット](/tidb-cloud/tidb-cloud-sql-tuning-overview.md#hotspot-issues)がないか確認するか、TiKVのノード数またはノードサイズを増やして、現在のワークロードのメモリ使用率を削減することを検討してください。 | | TiDBノード全体のCPU使用率が10分間80%を超えました。 | クラスター内に[ホットスポット](/tidb-cloud/tidb-cloud-sql-tuning-overview.md#hotspot-issues)がないか確認するか、TiDBのノード数またはノードサイズを増やして、現在のワークロードのCPU使用率を下げることを検討してください。 | diff --git a/tidb-cloud/monitor-datadog-integration.md b/tidb-cloud/monitor-datadog-integration.md index 3c51ac60ad40d..6688cd5cc3b61 100644 --- a/tidb-cloud/monitor-datadog-integration.md +++ b/tidb-cloud/monitor-datadog-integration.md @@ -1,18 +1,18 @@ --- title: Integrate TiDB Cloud with Datadog -summary: Datadogとの連携により、TiDBクラスタを監視する方法を学びましょう。 +summary: Datadogとの連携により、TiDBクラスターを監視する方法を学びましょう。 --- # TiDB CloudとDatadogを統合する {#integrate-tidb-cloud-with-datadog} -TiDB CloudはDatadogとの連携をサポートしています。TiDB Cloudを設定することで、TiDBクラスタに関するメトリクスを[データドッグ](https://www.datadoghq.com/)に送信できます。その後、これらのメトリクスをDatadogダッシュボードで直接確認できます。 +TiDB CloudはDatadogとの連携をサポートしています。TiDB Cloudを設定することで、TiDBクラスターに関するメトリクスを[データドッグ](https://www.datadoghq.com/)に送信できます。その後、これらのメトリクスをDatadogダッシュボードで直接確認できます。 ## Datadog統合バージョン {#datadog-integration-version} TiDB Cloudは、2022年3月4日よりプロジェクトレベルのDatadog統合（ベータ版）をサポートしてきました。2025年7月31日より、TiDB CloudレベルのDatadog統合（プレビュー版）を導入します。2025年9月30日より、クラスターレベルのDatadog統合が一般提供（GA）となります。 -- **クラスタレベルのDatadog統合**：2025年7月31日までに組織内に削除されていない従来のプロジェクトレベルのDatadogまたはNew Relic統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスタレベルのDatadog統合を提供します。 -- **従来のプロジェクトレベルの Datadog 統合 (ベータ版)** : 2025 年 7 月 31 日時点で組織内に少なくとも 1 つの従来のプロジェクトレベルの Datadog または New Relic 統合が削除されずに残っている場合、 TiDB Cloudは、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。従来のプロジェクトレベルの Datadog 統合は、2025 年 10 月 31 日に廃止されることに注意してください。組織がこれらの従来の統合をまだ使用している場合は、[DatadogとNew Relicの統合を移行する](/tidb-cloud/migrate-metrics-integrations.md)手順に従って、新しいクラスタレベルの統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 +- **クラスターレベルのDatadog統合**：2025年7月31日までに組織内に削除されていない従来のプロジェクトレベルのDatadogまたはNew Relic統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスターレベルのDatadog統合を提供します。 +- **従来のプロジェクトレベルの Datadog 統合 (ベータ版)** : 2025 年 7 月 31 日時点で組織内に少なくとも 1 つの従来のプロジェクトレベルの Datadog または New Relic 統合が削除されずに残っている場合、 TiDB Cloudは、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。従来のプロジェクトレベルの Datadog 統合は、2025 年 10 月 31 日に廃止されることに注意してください。組織がこれらの従来の統合をまだ使用している場合は、[DatadogとNew Relicの統合を移行する](/tidb-cloud/migrate-metrics-integrations.md)手順に従って、新しいクラスターレベルの統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 ## 前提条件 {#prerequisites} @@ -81,26 +81,26 @@ TiDB Cloudは、2022年3月4日よりプロジェクトレベルのDatadog統合 > **注記：** > -> Datadog にTiDB Cloud統合をすでにインストールしている場合は、このセクションの次の手順をスキップできます。 [**TiDB Cloudダイナミックトラッカー**](https://app.datadoghq.com/dash/integration/32021/tidb-cloud-dynamic-tracker)または[**TiDB Cloudクラスタの概要**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview)ダッシュボードは、Datadog [**ダッシュボード一覧**](https://app.datadoghq.com/dashboard/lists)で自動的に利用可能になります。 +> Datadog にTiDB Cloud統合をすでにインストールしている場合は、このセクションの次の手順をスキップできます。 [**TiDB Cloudダイナミックトラッカー**](https://app.datadoghq.com/dash/integration/32021/tidb-cloud-dynamic-tracker)または[**TiDB Cloudクラスターの概要**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview)ダッシュボードは、Datadog [**ダッシュボード一覧**](https://app.datadoghq.com/dashboard/lists)で自動的に利用可能になります。 1. [データドッグ](https://app.datadoghq.com)にログインします。 2. Datadog の[**TiDB Cloud統合**ページ](https://app.datadoghq.com/account/settings#integrations/tidb-cloud)に移動します。 -3. **「コンフィグレーション」**タブで、 **「統合のインストール」を**クリックします。 +3. **「設定」**タブで、 **「統合のインストール」を**クリックします。 - クラスターレベルの Datadog 統合の場合、 [**TiDB Cloudダイナミックトラッカー**](https://app.datadoghq.com/dash/integration/32021/tidb-cloud-dynamic-tracker)ダッシュボードが[**ダッシュボード一覧**](https://app.datadoghq.com/dashboard/lists)に表示されます。 - - 従来のプロジェクト レベルの Datadog 統合 (ベータ版) の場合、 [**TiDB Cloudクラスタの概要**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview)ボード[**ダッシュボード一覧**](https://app.datadoghq.com/dashboard/lists)に表示されます。 + - 従来のプロジェクト レベルの Datadog 統合 (ベータ版) の場合、 [**TiDB Cloudクラスターの概要**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview)ボード[**ダッシュボード一覧**](https://app.datadoghq.com/dashboard/lists)に表示されます。 ## 事前に構築されたダッシュボードをビュー {#view-the-pre-built-dashboard} 1. [TiDB Cloudコンソール](https://tidbcloud.com)で、 **「統合」**ページに移動します。 2. **Datadog**セクションの**「ダッシュボード」**リンクをクリックしてください。 - - クラスタレベルのDatadog統合の場合、**ダッシュボード**リンクをクリックすると、拡張バージョンで導入された最新のメトリクスを含む新しいダッシュボードが開きます。 - - 従来のプロジェクトレベルのDatadog統合（ベータ版）の場合、**ダッシュボード**リンクをクリックすると従来のダッシュボードが開きますが、そこにはクラスタレベルのDatadog統合で導入された最新のメトリクスは含まれていません。 + - クラスターレベルのDatadog統合の場合、**ダッシュボード**リンクをクリックすると、拡張バージョンで導入された最新のメトリクスを含む新しいダッシュボードが開きます。 + - 従来のプロジェクトレベルのDatadog統合（ベータ版）の場合、**ダッシュボード**リンクをクリックすると従来のダッシュボードが開きますが、そこにはクラスターレベルのDatadog統合で導入された最新のメトリクスは含まれていません。 ## Datadogで利用可能な指標 {#metrics-available-to-datadog} -Datadogは、TiDBクラスタに関して以下のメトリクスを追跡します。 +Datadogは、TiDBクラスターに関して以下のメトリクスを追跡します。 | メトリック名 | メトリックタイプ | ラベル | 説明 | | :----------------------------------------- | :------- | :---------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -114,20 +114,20 @@ Datadogは、TiDBクラスタに関して以下のメトリクスを追跡しま | tidb_cloud.db_command_per_second | ゲージ | タイプ: クエリ|ステートメント準備|...
    クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | TiDBが1秒間に処理するコマンド数。コマンド実行結果の成否に応じて分類されます。 | | tidb_cloud.db_queries_using_plan_cache_ops | ゲージ | クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | [プランキャッシュ](/sql-prepared-plan-cache.md)を使用したクエリの 1 秒あたりの統計。実行プラン キャッシュは、プリペアドステートメントコマンドのみをサポートします。 | | tidb_cloud.db_transaction_per_second | ゲージ | txn_mode:悲観的|楽観的
    タイプ: 中止|コミット|...
    クラスター名: ``
    インスタンス: tidb-0|tidb-1…
    コンポーネント: `tidb` | 1秒あたりに実行されるトランザクション数。 | -| tidb_cloud.node_storage_used_bytes | ゲージ | クラスター名: ``
    インスタンス: tikv-0|tikv-1…|tiflash-0|tiflash-1…
    コンポーネント: tikv|tiflash | TiKV またはTiFlashノードのディスク使用量（バイト単位）。このメトリックは主にstorageエンジンの論理データ サイズを表し、WAL ファイルと一時ファイルは除外されます。実際のディスク使用率を計算するには、代わりに`(capacity - available) / capacity`を使用してください。TiKV のstorage使用率が 80% を超えると、レイテンシーの急増が発生する可能性があり、使用率が高くなるとリクエストが失敗する可能性があります。すべてのTiFlashノードのstorage使用率が 80% に達すると、 TiFlashレプリカを追加する DDL ステートメントは無期限にハングします。 | -| tidb_cloud.node_storage_capacity_bytes | ゲージ | クラスター名: ``
    インスタンス: tikv-0|tikv-1…|tiflash-0|tiflash-1…
    コンポーネント: tikv|tiflash | TiKV/ TiFlashノードのディスク容量（バイト単位）。 | +| tidb_cloud.node_ストレージ_used_bytes | ゲージ | クラスター名: ``
    インスタンス: tikv-0|tikv-1…|tiflash-0|tiflash-1…
    コンポーネント: tikv|tiflash | TiKV またはTiFlashノードのディスク使用量（バイト単位）。このメトリックは主にストレージエンジンの論理データ サイズを表し、WAL ファイルと一時ファイルは除外されます。実際のディスク使用率を計算するには、代わりに`(capacity - available) / capacity`を使用してください。TiKV のストレージ使用率が 80% を超えると、レイテンシーの急増が発生する可能性があり、使用率が高くなるとリクエストが失敗する可能性があります。すべてのTiFlashノードのストレージ使用率が 80% に達すると、 TiFlashレプリカを追加する DDL ステートメントは無期限にハングします。 | +| tidb_cloud.node_ストレージ_capacity_bytes | ゲージ | クラスター名: ``
    インスタンス: tikv-0|tikv-1…|tiflash-0|tiflash-1…
    コンポーネント: tikv|tiflash | TiKV/ TiFlashノードのディスク容量（バイト単位）。 | | tidb_cloud.node_cpu_seconds_total | カウント | クラスター名: ``
    インスタンス: tidb-0|tidb-1…|tikv-0…|tiflash-0…
    コンポーネント: tidb|tikv|tiflash | TiDB/TiKV/ TiFlashノードのCPU使用率。 | | tidb_cloud.node_cpu_capacity_cores | ゲージ | クラスター名: ``
    インスタンス: tidb-0|tidb-1…|tikv-0…|tiflash-0…
    コンポーネント: tidb|tikv|tiflash | TiDB/TiKV/ TiFlashノードのCPUコア数の制限。 | | tidb_cloud.node_memory_used_bytes | ゲージ | クラスター名: ``
    インスタンス: tidb-0|tidb-1…|tikv-0…|tiflash-0…
    コンポーネント: tidb|tikv|tiflash | TiDB/TiKV/ TiFlashノードで使用されているメモリ（バイト単位）。 | | tidb_cloud.node_memory_capacity_bytes | ゲージ | クラスター名: ``
    インスタンス: tidb-0|tidb-1…|tikv-0…|tiflash-0…
    コンポーネント: tidb|tikv|tiflash | TiDB/TiKV/ TiFlashノードのメモリ容量（バイト単位）。 | -クラスタレベルのDatadog統合では、以下の追加メトリクスも利用可能です。 +クラスターレベルのDatadog統合では、以下の追加メトリクスも利用可能です。 | メトリック名 | メトリックタイプ | ラベル | 説明 | | :---------------------------------------------------------------------- | :------- | :----------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------- | -| tidb_cloud.node_storage_available_bytes | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tikv\|tiflash`
    クラスター名: `` | TiKV/ TiFlashノードで使用可能なディスク容量（バイト単位）。 | -| tidb_cloud.node_disk_read_latency | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tikv\|tiflash`
    クラスター名: ``
    `device` : `nvme.*\|dm.*` | storageデバイスごとの読み取りレイテンシー（秒）。 | -| tidb_cloud.node_disk_write_latency | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tikv\|tiflash`
    クラスター名: ``
    `device` : `nvme.*\|dm.*` | storageデバイスごとの書き込みレイテンシー（秒）。 | +| tidb_cloud.node_ストレージ_available_bytes | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tikv\|tiflash`
    クラスター名: `` | TiKV/ TiFlashノードで使用可能なディスク容量（バイト単位）。 | +| tidb_cloud.node_disk_read_latency | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tikv\|tiflash`
    クラスター名: ``
    `device` : `nvme.*\|dm.*` | ストレージデバイスごとの読み取りレイテンシー（秒）。 | +| tidb_cloud.node_disk_write_latency | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tikv\|tiflash`
    クラスター名: ``
    `device` : `nvme.*\|dm.*` | ストレージデバイスごとの書き込みレイテンシー（秒）。 | | tidb_cloud.db_kv_request_duration | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tikv`
    クラスター名: ``
    `type` : `BatchGet\|Commit\|Prewrite\|...` | TiKVリクエストの種類別の所要時間（秒）。 | | tidb_cloud.db_component_uptime | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tidb\|tikv\|tiflash`
    クラスター名: `` | TiDBコンポーネントの稼働時間（秒単位）。 | | tidb_cloud.cdc_changefeed_latency (別名 cdc_changefeed_checkpoint_ts_lag) | ゲージ | changefeed_id: ``
    クラスター名: `` | 変更フィード所有者のチェックポイントタイムスタンプの遅延（秒単位）。 | diff --git a/tidb-cloud/monitor-new-relic-integration.md b/tidb-cloud/monitor-new-relic-integration.md index 41e910b657162..b3240eb813fbf 100644 --- a/tidb-cloud/monitor-new-relic-integration.md +++ b/tidb-cloud/monitor-new-relic-integration.md @@ -1,18 +1,18 @@ --- title: Integrate TiDB Cloud with New Relic -summary: New Relicとの連携により、TiDBクラスタを監視する方法を学びましょう。 +summary: New Relicとの連携により、TiDBクラスターを監視する方法を学びましょう。 --- # TiDB CloudとNew Relicを統合する {#integrate-tidb-cloud-with-new-relic} -TiDB CloudはNew Relicとの連携をサポートしています。TiDB Cloudを設定して、TiDBクラスタのメトリクスを[ニューレリック](https://newrelic.com/)に送信することができます。その後、New Relicダッシュボードでこれらのメトリクスを直接確認できます。 +TiDB CloudはNew Relicとの連携をサポートしています。TiDB Cloudを設定して、TiDBクラスターのメトリクスを[ニューレリック](https://newrelic.com/)に送信することができます。その後、New Relicダッシュボードでこれらのメトリクスを直接確認できます。 ## 新しいRelic統合バージョン {#new-relic-integration-version} TiDB Cloudは、2023年4月11日よりプロジェクトレベルのNew Relic統合（ベータ版）をサポートしてきました。2025年7月31日より、TiDB CloudレベルのNew Relic統合（プレビュー版）を導入します。2025年9月30日より、クラスターレベルのNew Relic統合が一般提供（GA）となります。 -- **クラスタレベルのNew Relic統合**：2025年7月31日までに組織内で削除されていない従来のプロジェクトレベルのDatadogまたはNew Relic統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスタレベルのNew Relic統合を提供します。 -- **従来のプロジェクトレベルの New Relic 統合 (ベータ版)** : 2025 年 7 月 31 日時点で組織内に少なくとも 1 つの従来のプロジェクトレベルの Datadog または New Relic 統合が削除されずに残っている場合、 TiDB Cloud は、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。従来のプロジェクトレベルの New Relic 統合は、2025 年 10 月 31 日に廃止されることに注意してください。組織がこれらの従来の統合をまだ使用している場合は、[DatadogとNew Relicの統合を移行する](/tidb-cloud/migrate-metrics-integrations.md)手順に従って、新しいクラスタレベルの統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 +- **クラスターレベルのNew Relic統合**：2025年7月31日までに組織内で削除されていない従来のプロジェクトレベルのDatadogまたはNew Relic統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスターレベルのNew Relic統合を提供します。 +- **従来のプロジェクトレベルの New Relic 統合 (ベータ版)** : 2025 年 7 月 31 日時点で組織内に少なくとも 1 つの従来のプロジェクトレベルの Datadog または New Relic 統合が削除されずに残っている場合、 TiDB Cloud は、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。従来のプロジェクトレベルの New Relic 統合は、2025 年 10 月 31 日に廃止されることに注意してください。組織がこれらの従来の統合をまだ使用している場合は、[DatadogとNew Relicの統合を移行する](/tidb-cloud/migrate-metrics-integrations.md)手順に従って、新しいクラスターレベルの統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 ## 前提条件 {#prerequisites} @@ -137,12 +137,12 @@ TiDB Cloudは、2023年4月11日よりプロジェクトレベルのNew Relic統 3. [新しいRelic統合バージョン](#new-relic-integration-version)に応じて、次のいずれかを実行します。 - - クラスタレベルでのNew Relic統合を行うには、 **TiDB Cloud Dynamic Tracker**をクリックして新しいダッシュボードを表示してください。 + - クラスターレベルでのNew Relic統合を行うには、 **TiDB Cloud Dynamic Tracker**をクリックして新しいダッシュボードを表示してください。 - 従来のプロジェクトレベルのNew Relic統合（ベータ版）については、 **「TiDB Cloud Monitoring」**をクリックして従来のダッシュボードを表示してください。 ## New Relicで利用可能なメトリクス {#metrics-available-to-new-relic} -New Relicは、TiDBクラスタに関して以下のメトリクスを追跡します。 +New Relicは、TiDBクラスターに関して以下のメトリクスを追跡します。 | メトリック名 | メトリックタイプ | ラベル | 説明 | | :----------------------------------------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -156,8 +156,8 @@ New Relicは、TiDBクラスタに関して以下のメトリクスを追跡し | tidb_cloud.db_command_per_second | ゲージ | タイプ: クエリ|ステートメント準備|...

    クラスター名: ``

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

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

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

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

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

    クラスター名: ``

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

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

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

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

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

    コンポーネント: tikv|tiflash | TiKV/ TiFlashノードのディスク容量（バイト単位）。 | +| tidb_cloud.node_ストレージ_used_bytes | ゲージ | クラスター名: ``

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

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

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

    コンポーネント: tikv|tiflash | TiKV/ TiFlashノードのディスク容量（バイト単位）。 | | tidb_cloud.node_cpu_seconds_total (ベータ版のみ) | カウント | クラスター名: ``

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

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

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

    コンポーネント: tidb|tikv|tiflash | TiDB/TiKV/ TiFlashノードのCPUコア数の制限。 | | tidb_cloud.node_memory_used_bytes | ゲージ | クラスター名: ``

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

    コンポーネント: tidb|tikv|tiflash | TiDB/TiKV/ TiFlashノードで使用されているメモリ（バイト単位）。 | @@ -167,9 +167,9 @@ New Relicは、TiDBクラスタに関して以下のメトリクスを追跡し | メトリック名 | メトリックタイプ | ラベル | 説明 | | :---------------------------------------------------------------------- | :------- | :-------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| tidb_cloud.node_storage_available_bytes | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`

    コンポーネント: `tikv\|tiflash`

    クラスター名: `` | TiKVまたはTiFlashノードで使用可能なディスク容量（バイト単位）。 | -| tidb_cloud.node_disk_read_latency | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`

    コンポーネント: `tikv\|tiflash`

    クラスター名: ``

    `device` : `nvme.*\|dm.*` | storageデバイスごとの読み取りレイテンシー（秒単位）。 | -| tidb_cloud.node_disk_write_latency | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`

    コンポーネント: `tikv\|tiflash`

    クラスター名: ``

    `device` : `nvme.*\|dm.*` | storageデバイスごとの書き込みレイテンシー（秒単位）。 | +| tidb_cloud.node_ストレージ_available_bytes | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`

    コンポーネント: `tikv\|tiflash`

    クラスター名: `` | TiKVまたはTiFlashノードで使用可能なディスク容量（バイト単位）。 | +| tidb_cloud.node_disk_read_latency | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`

    コンポーネント: `tikv\|tiflash`

    クラスター名: ``

    `device` : `nvme.*\|dm.*` | ストレージデバイスごとの読み取りレイテンシー（秒単位）。 | +| tidb_cloud.node_disk_write_latency | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`

    コンポーネント: `tikv\|tiflash`

    クラスター名: ``

    `device` : `nvme.*\|dm.*` | ストレージデバイスごとの書き込みレイテンシー（秒単位）。 | | tidb_cloud.db_kv_request_duration | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`

    コンポーネント: `tikv`

    クラスター名: ``

    `type` : `BatchGet\|Commit\|Prewrite\|...` | TiKVリクエストの種類別の所要時間（秒）。 | | tidb_cloud.db_component_uptime | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`

    コンポーネント: `tidb\|tikv\|tiflash`

    クラスター名: `` | TiDBコンポーネントの稼働時間（秒単位）。 | | tidb_cloud.cdc_changefeed_latency (別名 cdc_changefeed_checkpoint_ts_lag) | ゲージ | changefeed_id: ``

    クラスター名: `` | 変更フィード所有者のチェックポイントタイムスタンプの遅延（秒単位）。 | diff --git a/tidb-cloud/monitor-prometheus-and-grafana-integration.md b/tidb-cloud/monitor-prometheus-and-grafana-integration.md index 439a2ff41bbf9..bd555fe8d4f5b 100644 --- a/tidb-cloud/monitor-prometheus-and-grafana-integration.md +++ b/tidb-cloud/monitor-prometheus-and-grafana-integration.md @@ -1,6 +1,6 @@ --- title: Integrate TiDB Cloud with Prometheus and Grafana -summary: PrometheusとGrafanaを統合してTiDBクラスタを監視する方法を学びましょう。 +summary: PrometheusとGrafanaを統合してTiDBクラスターを監視する方法を学びましょう。 --- # TiDB CloudをPrometheusおよびGrafanaと統合する {#integrate-tidb-cloud-with-prometheus-and-grafana} @@ -13,13 +13,13 @@ TiDB Cloudは[プロメテウス](https://prometheus.io/)APIエンドポイン TiDB Cloudは、2022年3月15日よりプロジェクトレベルのPrometheus統合（ベータ版）をサポートしてきました。2025年10月21日より、TiDB CloudレベルのPrometheus統合（プレビュー版）を導入します。2025年12月2日より、クラスターレベルのPrometheus統合が一般提供（GA）となります。 -- **クラスタレベルのPrometheus統合**：2025年10月21日までに組織内に削除されていない従来のプロジェクトレベルのPrometheus統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスタレベルのPrometheus統合を提供します。 +- **クラスターレベルのPrometheus統合**：2025年10月21日までに組織内に削除されていない従来のプロジェクトレベルのPrometheus統合が残っていない場合、 TiDB Cloudは組織が最新の機能強化を体験できるように、クラスターレベルのPrometheus統合を提供します。 - **従来のプロジェクトレベルの Prometheus 統合 (ベータ版)** : 2025 年 10 月 21 日時点で組織内に少なくとも 1 つの従来のプロジェクトレベルの Prometheus 統合が削除されずに残っている場合、 TiDB Cloud は、現在のダッシュボードへの影響を回避するために、組織向けにプロジェクトレベルで既存および新規の統合の両方を保持します。 > **注記** > - > 従来のプロジェクトレベルのPrometheus統合は、2026年1月9日に廃止されます。組織がまだこれらの従来の統合を使用している場合は、 [Prometheus統合の移行](/tidb-cloud/migrate-prometheus-metrics-integrations.md)手順に従って、新しいクラスタレベルの統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 + > 従来のプロジェクトレベルのPrometheus統合は、2026年1月9日に廃止されます。組織がまだこれらの従来の統合を使用している場合は、 [Prometheus統合の移行](/tidb-cloud/migrate-prometheus-metrics-integrations.md)手順に従って、新しいクラスターレベルの統合に移行し、メトリクス関連サービスへの影響を最小限に抑えてください。 ## 前提条件 {#prerequisites} @@ -106,7 +106,7 @@ Grafana の使用方法の詳細については、 [Grafanaのドキュメント ## Prometheusで利用可能なメトリクス {#metrics-available-to-prometheus} -Prometheusは、TiDBクラスタに関して以下のメトリックデータを追跡します。 +Prometheusは、TiDBクラスターに関して以下のメトリックデータを追跡します。 | メトリック名 | メトリックタイプ | ラベル | 説明 | | :---------------------------------------------------------- | :------- | :----------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | @@ -117,15 +117,15 @@ Prometheusは、TiDBクラスタに関して以下のメトリックデータを | tidbcloud_changefeed_latency | ゲージ | changefeed_id | 変更フィードの上流と下流間のデータ複製レイテンシー | | tidbcloud_changefeed_checkpoint_ts | ゲージ | changefeed_id | 変更フィードのチェックポイントタイムスタンプ。ダウンストリームに正常に書き込まれた最大のTSO（タイムスタンプオラクル）を表す。 | | tidbcloud_changefeed_replica_rows | ゲージ | changefeed_id | 変更フィードがダウンストリームに1秒あたりに書き込む複製行数 | -| tidbcloud_node_storage_used_bytes | ゲージ | クラスター名: ``
    インスタンス: `tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…`
    コンポーネント: `tikv\|tiflash` | TiKV またはTiFlashノードのディスク使用量（バイト単位）。このメトリックは主にstorageエンジンの論理データ サイズを表し、WAL ファイルと一時ファイルは除外されます。実際のディスク使用率を計算するには、代わりに`(capacity - available) / capacity`を使用してください。TiKV のstorage使用率が 80% を超えると、レイテンシーの急増が発生する可能性があり、使用率が高くなるとリクエストが失敗する可能性があります。すべてのTiFlashノードのstorage使用率が 80% に達すると、 TiFlashレプリカを追加する DDL ステートメントは無期限にハングします。 | -| tidbcloud_node_storage_capacity_bytes | ゲージ | クラスター名: ``
    インスタンス: `tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…`
    コンポーネント: `tikv\|tiflash` | TiKV/ TiFlashノードのディスク容量（バイト） | +| tidbcloud_node_ストレージ_used_bytes | ゲージ | クラスター名: ``
    インスタンス: `tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…`
    コンポーネント: `tikv\|tiflash` | TiKV またはTiFlashノードのディスク使用量（バイト単位）。このメトリックは主にストレージエンジンの論理データ サイズを表し、WAL ファイルと一時ファイルは除外されます。実際のディスク使用率を計算するには、代わりに`(capacity - available) / capacity`を使用してください。TiKV のストレージ使用率が 80% を超えると、レイテンシーの急増が発生する可能性があり、使用率が高くなるとリクエストが失敗する可能性があります。すべてのTiFlashノードのストレージ使用率が 80% に達すると、 TiFlashレプリカを追加する DDL ステートメントは無期限にハングします。 | +| tidbcloud_node_ストレージ_capacity_bytes | ゲージ | クラスター名: ``
    インスタンス: `tikv-0\|tikv-1…\|tiflash-0\|tiflash-1…`
    コンポーネント: `tikv\|tiflash` | TiKV/ TiFlashノードのディスク容量（バイト） | | tidbcloud_node_cpu_seconds_total | カウント | クラスター名: ``
    インスタンス: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
    コンポーネント: `tidb\|tikv\|tiflash` | TiDB/TiKV/ TiFlashノードのCPU使用率 | | tidbcloud_node_cpu_capacity_cores | ゲージ | クラスター名: ``
    インスタンス: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
    コンポーネント: `tidb\|tikv\|tiflash` | TiDB/TiKV/ TiFlashノードのCPU制限コア数 | | tidbcloud_node_memory_used_bytes | ゲージ | クラスター名: ``
    インスタンス: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
    コンポーネント: `tidb\|tikv\|tiflash` | TiDB/TiKV/ TiFlashノードで使用されているメモリバイト数 | | tidbcloud_node_memory_capacity_bytes | ゲージ | クラスター名: ``
    インスタンス: `tidb-0\|tidb-1…\|tikv-0…\|tiflash-0…`
    コンポーネント: `tidb\|tikv\|tiflash` | TiDB/TiKV/ TiFlashノードのメモリ容量（バイト） | -| tidbcloud_node_storage_available_bytes | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tikv\|tiflash`
    クラスター名: `` | TiKV/ TiFlashノードで使用可能なディスク容量（バイト単位） | -| tidbcloud_disk_read_latency | ヒストグラム | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tikv\|tiflash`
    クラスター名: ``
    `device` : `nvme.*\|dm.*` | storageあたりの読み取りレイテンシー（秒） | -| tidbcloud_disk_write_latency | ヒストグラム | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tikv\|tiflash`
    クラスター名: ``
    `device` : `nvme.*\|dm.*` | storageあたりの書き込みレイテンシー（秒） | +| tidbcloud_node_ストレージ_available_bytes | ゲージ | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tikv\|tiflash`
    クラスター名: `` | TiKV/ TiFlashノードで使用可能なディスク容量（バイト単位） | +| tidbcloud_disk_read_latency | ヒストグラム | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tikv\|tiflash`
    クラスター名: ``
    `device` : `nvme.*\|dm.*` | ストレージあたりの読み取りレイテンシー（秒） | +| tidbcloud_disk_write_latency | ヒストグラム | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tikv\|tiflash`
    クラスター名: ``
    `device` : `nvme.*\|dm.*` | ストレージあたりの書き込みレイテンシー（秒） | | tidbcloud_kv_request_duration | ヒストグラム | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tikv`
    クラスター名: ``
    `type` : `BatchGet\|Commit\|Prewrite\|...` | TiKVリクエストの種類別の所要時間（秒） | | tidbcloud_component_uptime | ヒストグラム | インスタンス: `tidb-0\|tidb-1\|...`
    コンポーネント: `tidb\|tikv\|tiflash`
    クラスター名: `` | TiDBコンポーネントの稼働時間（秒） | | tidbcloud_ticdc_owner_resolved_ts_lag | ゲージ | changefeed_id: ``
    クラスター名: `` | 変更フィード所有者の解決済みタイムスタンプ遅延（秒単位） | diff --git a/tidb-cloud/monitor-tidb-cluster.md b/tidb-cloud/monitor-tidb-cluster.md index 330f574173cae..3e4d5172f39c5 100644 --- a/tidb-cloud/monitor-tidb-cluster.md +++ b/tidb-cloud/monitor-tidb-cluster.md @@ -9,13 +9,13 @@ summary: TiDB Cloudリソースの監視方法を学びましょう。 -## クラスタの状態とノードの状態 {#cluster-status-and-node-status} +## クラスターの状態とノードの状態 {#cluster-status-and-node-status} 各実行中のクラスターの現在のステータスは、クラスターページで確認できます。 -### クラスタの状態 {#cluster-status} +### クラスターの状態 {#cluster-status} -| クラスタの状態 | 説明 | +| クラスターの状態 | 説明 | | :------- | :------------------------------- | | **利用可能** | クラスターは正常で、利用可能です。 | | **作成** | クラスターを作成中です。作成中はクラスターにアクセスできません。 | @@ -32,7 +32,7 @@ summary: TiDB Cloudリソースの監視方法を学びましょう。 > **注記：** > -> TiDBノードの状態は、 TiDB Cloud Dedicatedクラスタでのみ利用可能です。 +> TiDBノードの状態は、 TiDB Cloud Dedicatedクラスターでのみ利用可能です。 `tidb`で始まるノード名はTiDBノードであり、 `tiproxy`で始まるノード名はTiProxyノードです。 @@ -47,7 +47,7 @@ summary: TiDB Cloudリソースの監視方法を学びましょう。 > **注記：** > -> TiKVノードの状態は、 TiDB Cloud Dedicatedクラスタでのみ利用可能です。 +> TiKVノードの状態は、 TiDB Cloud Dedicatedクラスターでのみ利用可能です。 | TiKVノードの状態 | 説明 | | :--------- | :----------------- | diff --git a/tidb-cloud/monitoring-concepts.md b/tidb-cloud/monitoring-concepts.md index e5aa8dd03f5cf..7a39f4f72e783 100644 --- a/tidb-cloud/monitoring-concepts.md +++ b/tidb-cloud/monitoring-concepts.md @@ -9,7 +9,7 @@ TiDB Cloudのモニタリング機能は、TiDBのパフォーマンスを監視 ## 組み込みの指標 {#built-in-metrics} -組み込みメトリクスとはクラスタTiDB Cloudが収集し、実例レベルの**メトリクス**ページに表示する一連の標準メトリクスを指します。これらのメトリクスを使用することで、パフォーマンスの問題を容易に特定し、現在のデータベース展開が要件を満たしているかどうかを判断できます。 +組み込みメトリクスとはクラスターTiDB Cloudが収集し、実例レベルの**メトリクス**ページに表示する一連の標準メトリクスを指します。これらのメトリクスを使用することで、パフォーマンスの問題を容易に特定し、現在のデータベース展開が要件を満たしているかどうかを判断できます。 @@ -24,7 +24,7 @@ TiDB Cloudのモニタリング機能は、TiDBのパフォーマンスを監視 ## 内蔵アラート機能 {#built-in-alerting} -組み込みアラートとは、 TiDB Cloud EssentialインスタンスおよびTiDB Cloud Dedicatedクラスタの監視を支援するためにTiDB Cloudが提供するアラートメカニズムのことです。現在、 TiDB Cloudは以下の3種類のアラートを提供しています。 +組み込みアラートとは、 TiDB Cloud EssentialインスタンスおよびTiDB Cloud Dedicatedクラスターの監視を支援するためにTiDB Cloudが提供するアラートメカニズムのことです。現在、 TiDB Cloudは以下の3種類のアラートを提供しています。 - リソース使用状況アラート @@ -32,7 +32,7 @@ TiDB Cloudのモニタリング機能は、TiDBのパフォーマンスを監視 - 変更フィードアラート -TiDB Cloudコンソールの「アラート」ページでは、 TiDB Cloud EssentialインスタンスまたはTiDB Cloud Dedicatedクラスタのアラートを表示したり、アラートルールを編集したり、アラート通知メールを購読したりできます。 +TiDB Cloudコンソールの「アラート」ページでは、 TiDB Cloud EssentialインスタンスまたはTiDB Cloud Dedicatedクラスターのアラートを表示したり、アラートルールを編集したり、アラート通知メールを購読したりできます。 詳細については、 [TiDB Cloudの組み込みアラート機能](/tidb-cloud/monitor-built-in-alerting.md)を参照してください。 @@ -41,7 +41,7 @@ TiDB Cloudコンソールの「アラート」ページでは、 TiDB Cloud Esse TiDB Cloudでは、イベントはTiDB Cloudリソースの変更を示します。 - TiDB Cloud StarterおよびEssentialインスタンスの場合、 TiDB Cloudはインスタンスレベルで履歴イベントをログに記録します。 -- TiDB Cloud Dedicatedクラスタの場合、 TiDB Cloudはクラスタレベルで履歴イベントをログに記録します。 +- TiDB Cloud Dedicatedクラスターの場合、 TiDB Cloudはクラスターレベルで履歴イベントをログに記録します。 **イベント**ページでは、イベントの種類、ステータス、メッセージ、トリガー時刻、トリガーユーザーなど、記録されたイベントを確認できます。 @@ -49,7 +49,7 @@ TiDB Cloudでは、イベントはTiDB Cloudリソースの変更を示します ## サードパーティ製メトリクスの統合 {#third-party-metrics-integrations} -TiDB Cloud、以下のサードパーティ製メトリクスサービスのいずれかを統合して、 TiDB Cloudアラートを受信したり、 TiDB Cloud Dedicatedクラスタのパフォーマンスメトリクスを表示したりできます。 +TiDB Cloud、以下のサードパーティ製メトリクスサービスのいずれかを統合して、 TiDB Cloudアラートを受信したり、 TiDB Cloud Dedicatedクラスターのパフォーマンスメトリクスを表示したりできます。 - [Datadogとの連携](/tidb-cloud/monitor-datadog-integration.md) diff --git a/tidb-cloud/notifications.md b/tidb-cloud/notifications.md index 7a62c6a6d71f6..6cf7b169c950e 100644 --- a/tidb-cloud/notifications.md +++ b/tidb-cloud/notifications.md @@ -41,8 +41,8 @@ TiDB Cloudコンソールでは、次のようなさまざまな種類の通知 | TiDB Cloud Starterインスタンスの削除 | TiDB Cloud Starterインスタンスが削除されました。 | プロジェクトメンバー全員 | | TiDB Cloud Essentialインスタンスの作成 | [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンスが作成されます。 | プロジェクトメンバー全員 | | TiDB Cloud Essentialインスタンスの削除 | [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンスが削除されました。 | プロジェクトメンバー全員 | -| TiDB Cloud Dedicatedクラスタの作成 | [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターが作成されます。 | プロジェクトメンバー全員 | -| TiDB Cloud Dedicatedクラスタの削除 | TiDB Cloud Dedicatedクラスターが削除されました。 | プロジェクトメンバー全員 | +| TiDB Cloud Dedicatedクラスターの作成 | [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターが作成されます。 | プロジェクトメンバー全員 | +| TiDB Cloud Dedicatedクラスターの削除 | TiDB Cloud Dedicatedクラスターが削除されました。 | プロジェクトメンバー全員 | | 組織予算のしきい値アラート | 組織の[予算の上限](/tidb-cloud/tidb-cloud-budget.md)達しました。 | `Organization Owner` 、 `Organization Billing Manager` 、および`Organization Billing Viewer` | | プロジェクト予算のしきい値アラート | プロジェクト[予算の上限](/tidb-cloud/tidb-cloud-budget.md)達しました。 | `Organization Owner` 、 `Organization Billing Manager` 、 `Organization Billing Viewer` 、および`Project Owner` | | Starterインスタンスの支出制限しきい値アラート | 組織内のTiDB Cloud Starterインスタンスの[支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)に達しました。 | `Organization Owner` 、 `Organization Billing Manager` 、 `Organization Billing Viewer` 、および`Project Owner` | diff --git a/tidb-cloud/optimize-resource-allocation.md b/tidb-cloud/optimize-resource-allocation.md index c41b7960ba7ef..d164ddf0a0c8c 100644 --- a/tidb-cloud/optimize-resource-allocation.md +++ b/tidb-cloud/optimize-resource-allocation.md @@ -11,7 +11,7 @@ TiDB Cloud Dedicatedは、 [リソース管理](/tidb-resource-control-ru-groups ## リソース制御を使用する {#use-resource-control} -[リソース管理](/tidb-resource-control-ru-groups.md)使用すると、 TiDB Cloud Dedicatedクラスタのstorageノード（TiKVまたはTiFlash ）を複数の論理グループに分割できます。混在ワークロードを持つシステムでは、ワークロードを個別のリソースグループに割り当てることで、リソースの分離を確保し、QoS要件を満たすことができます。 +[リソース管理](/tidb-resource-control-ru-groups.md)使用すると、 TiDB Cloud Dedicatedクラスターのストレージノード（TiKVまたはTiFlash ）を複数の論理グループに分割できます。混在ワークロードを持つシステムでは、ワークロードを個別のリソースグループに割り当てることで、リソースの分離を確保し、QoS要件を満たすことができます。 クラスターで予期しない SQL パフォーマンスの問題が発生した場合は、リソース グループと併せて[SQLバインディング](/sql-statements/sql-statement-create-binding.md)または[暴走クエリを管理する](/tidb-resource-control-runaway-queries.md)使用して、特定の SQL ステートメントのリソース消費を一時的に制限できます。 @@ -19,7 +19,7 @@ TiDB Cloud Dedicatedは、 [リソース管理](/tidb-resource-control-ru-groups ## TiDBノードグループを使用する {#use-tidb-node-group} -[TiDBノードグループ](/tidb-cloud/tidb-node-group-overview.md)機能は、 TiDB Cloud Dedicated クラスタのコンピューティングノード（TiDBレイヤー）を物理的にグループ化します。各グループは特定の数の TiDB ノードで構成され、グループ間のコンピューティングリソースの物理的な分離を保証します。 +[TiDBノードグループ](/tidb-cloud/tidb-node-group-overview.md)機能は、 TiDB Cloud Dedicated クラスターのコンピューティングノード（TiDBレイヤー）を物理的にグループ化します。各グループは特定の数の TiDB ノードで構成され、グループ間のコンピューティングリソースの物理的な分離を保証します。 ビジネス要件に基づいてコンピューティングノードを複数のTiDBノードグループに分割し、各グループに固有の接続エンドポイントを割り当てることができます。アプリケーションはそれぞれのエンドポイントを介してクラスターに接続し、リクエストは対応するノードグループにルーティングされて処理されます。これにより、あるグループでのリソースの過剰使用が他のグループに影響を与えることを防ぎます。 @@ -33,6 +33,6 @@ TiDB Cloud Dedicatedは、 [リソース管理](/tidb-resource-control-ru-groups | ------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------- | | 分離レベル | TiKVまたはTiFlash論理レイヤー | TiDBノード物理レイヤー | | フロー制御 | リソース グループに設定されたクォータに基づいて、ユーザーの読み取りおよび書き込み要求のフローを制御します。 | サポートされていません。 | -| コンフィグレーション方法 | SQL文を使用して構成 | TiDB Cloudコンソールから設定 | +| 設定方法 | SQL文を使用して構成 | TiDB Cloudコンソールから設定 | | ワークロードの区別 | 次のレベルでのバインディング リソースをサポートします。
    • ユーザーレベル。
    • セッション レベル (セッションごとにリソース グループを設定します)。
    • ステートメント レベル (ステートメントごとにリソース グループを設定します)。
    | さまざまなワークロードに異なる接続エンドポイントを提供します。 | | 料金 | 追加料金なし | TiDB ノードの追加に関連するコストは発生しますが、TiDB ノード グループの作成には追加コストは発生しません。 | diff --git a/tidb-cloud/pause-or-resume-tidb-cluster.md b/tidb-cloud/pause-or-resume-tidb-cluster.md index 4206640d836cb..0771587dfd175 100644 --- a/tidb-cloud/pause-or-resume-tidb-cluster.md +++ b/tidb-cloud/pause-or-resume-tidb-cluster.md @@ -3,13 +3,13 @@ title: Pause or Resume a TiDB Cloud Dedicated Cluster summary: TiDB Cloud Dedicatedクラスターの一時停止または再開方法について説明します。 --- -# TiDB Cloud Dedicatedクラスタの一時停止または再開 {#pause-or-resume-a-tidb-cloud-dedicated-cluster} +# TiDB Cloud Dedicatedクラスターの一時停止または再開 {#pause-or-resume-a-tidb-cloud-dedicated-cluster} TiDB Cloudでは、常時稼働していないTiDB Cloud Dedicatedクラスターを簡単に一時停止および再開できます。 一時停止しても、クラスターに保存されているデータには影響しません。一時停止するのは、監視情報の収集とコンピューティングリソースの消費のみです。一時停止後、いつでもクラスターを再開できます。 -バックアップとリストアと比較すると、クラスタの一時停止と再開は時間がかからず、クラスタ情報（クラスタバージョン、クラスタ構成、TiDBユーザーアカウントなど）を保持できます。 +バックアップとリストアと比較すると、クラスターの一時停止と再開は時間がかからず、クラスター情報（クラスターバージョン、クラスター構成、TiDBユーザーアカウントなど）を保持できます。 > **注記：** > @@ -22,7 +22,7 @@ TiDB Cloudでは、常時稼働していないTiDB Cloud Dedicatedクラスタ - バックアップ ジョブの実行中はクラスターを一時停止できません。現在のバックアップ ジョブが完了するまで待つか、 [実行中のバックアップジョブを削除します](/tidb-cloud/backup-and-restore.md#delete-a-running-backup-job)。 - クラスターに[変更フィード](/tidb-cloud/changefeed-overview.md)がある場合、クラスターを一時停止することはできません。クラスターを一時停止する前に[既存の変更フィードを削除する](/tidb-cloud/changefeed-overview.md#delete-a-changefeed)必要があります。 -## TiDBクラスタを一時停止する {#pause-a-tidb-cluster} +## TiDBクラスターを一時停止する {#pause-a-tidb-cluster} 一時停止期間と動作は、組織の作成日によって異なります。 @@ -34,7 +34,7 @@ TiDB Cloudでは、常時稼働していないTiDB Cloud Dedicatedクラスタ クラスターが一時停止された場合は、以下の点に注意してください。 -- TiDB Cloudは、クラスタの監視情報の収集を停止します。 +- TiDB Cloudは、クラスターの監視情報の収集を停止します。 - クラスターからデータを読み取ったり、クラスターにデータを書き込んだりすることはできません。 @@ -60,7 +60,7 @@ TiDB Cloudでは、常時稼働していないTiDB Cloud Dedicatedクラスタ クラスターが一時停止された場合は、以下の点に注意してください。 -- TiDB Cloudは、クラスタの監視情報の収集を停止します。 +- TiDB Cloudは、クラスターの監視情報の収集を停止します。 - クラスターからデータを読み取ったり、クラスターにデータを書き込んだりすることはできません。 @@ -96,14 +96,14 @@ TiDB Cloudでは、常時稼働していないTiDB Cloud Dedicatedクラスタ **「一時停止」**をクリックすると、クラスターはまず「**一時停止中」の**状態になります。一時停止操作が完了すると、クラスターは**「一時停止済み」の**状態に移行します。 -TiDB Cloud API を使用してクラスタを一時停止することもできます。現在、 TiDB Cloud API はベータ版です。詳細については、 [TiDB Cloud APIドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)を参照してください。 +TiDB Cloud API を使用してクラスターを一時停止することもできます。現在、 TiDB Cloud API はベータ版です。詳細については、 [TiDB Cloud APIドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)を参照してください。 -## TiDBクラスタを再開する {#resume-a-tidb-cluster} +## TiDBクラスターを再開する {#resume-a-tidb-cluster} 一時停止していたクラスターを再開した後は、以下の点に注意してください。 -- TiDB Cloudはクラスタの監視情報の収集を再開し、クラスタからのデータ読み取りやクラスタへのデータ書き込みが可能になります。 -- TiDB Cloudは、コンピューティングコストとstorageコストの両方の課金を再開します。 +- TiDB Cloudはクラスターの監視情報の収集を再開し、クラスターからのデータ読み取りやクラスターへのデータ書き込みが可能になります。 +- TiDB Cloudは、コンピューティングコストとストレージコストの両方の課金を再開します。 - TiDB Cloud はクラスターの[自動バックアップ](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)を再開します。 一時停止したクラスターを再開するには、以下の手順を実行してください。 @@ -116,8 +116,8 @@ TiDB Cloud API を使用してクラスタを一時停止することもでき > > 一時**停止**状態のクラスターは再開できません。 -3. ダイアログで**「再開」**をクリックして選択を確定します。クラスタの状態が**「再開中」**になります。 +3. ダイアログで**「再開」**をクリックして選択を確定します。クラスターの状態が**「再開中」**になります。 クラスターのサイズによっては、クラスターの再開に数分かかる場合があります。クラスターが再開されると、クラスターの状態が**「再開中」**から**「利用可能」**に変わります。 -TiDB Cloud API を使用してクラスタを再開することもできます。現在、 TiDB Cloud API はベータ版です。詳細については、 [TiDB Cloud APIドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)参照してください。 +TiDB Cloud API を使用してクラスターを再開することもできます。現在、 TiDB Cloud API はベータ版です。詳細については、 [TiDB Cloud APIドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)参照してください。 diff --git a/tidb-cloud/premium/_index.md b/tidb-cloud/premium/_index.md index c98920c5b8ae0..1f4d233b123d0 100644 --- a/tidb-cloud/premium/_index.md +++ b/tidb-cloud/premium/_index.md @@ -41,7 +41,7 @@ summary: TiDB Cloudは、TiDBの優れた機能をすべてクラウド上で提 [TiDB Cloud Premiumインスタンスに接続します](https://docs.pingcap.com/tidbcloud/connect-to-tidb-instance/?plan=premium) -[HTAPクラスタを使用する](https://docs.pingcap.com/tidbcloud/tiflash-overview/?plan=premium) +[HTAPクラスターを使用する](https://docs.pingcap.com/tidbcloud/tiflash-overview/?plan=premium) [データのバックアップと復元](https://docs.pingcap.com/tidbcloud/backup-and-restore-premium/?plan=premium) diff --git a/tidb-cloud/premium/backup-and-restore-premium.md b/tidb-cloud/premium/backup-and-restore-premium.md index 24ec3a3e42523..cfec7386da18a 100644 --- a/tidb-cloud/premium/backup-and-restore-premium.md +++ b/tidb-cloud/premium/backup-and-restore-premium.md @@ -56,7 +56,7 @@ TiDB Cloud Premiumインスタンスは、以下の表に示すように、多 > **注記：** > -> - 自動バックアップのstorageコストは、バックアップデータの量と保存期間によって異なります。 +> - 自動バックアップのストレージコストは、バックアップデータの量と保存期間によって異なります。 > - バックアップの保持期間をデフォルトの制限を超えて延長するには、 [TiDB Cloudサポート](https://docs.pingcap.com/tidbcloud/tidb-cloud-support)にお問い合わせください。 ### バックアップファイルを削除する {#delete-backup-files} @@ -75,7 +75,7 @@ TiDB Cloud Premiumは、自動バックアップに加えて、手動バック - **保持と削除**：自動バックアップとは異なり、手動バックアップは保持ポリシーに基づいて自動的に削除されません。明示的に削除するまで保持されます。インスタンスを削除すると、その手動バックアップはごみ箱に移動し、手動で削除するまでそこに残ります。 -- **保存場所**：手動バックアップは、TiDBが管理するクラウドstorageに保存されます。 +- **保存場所**：手動バックアップは、TiDBが管理するクラウドストレージに保存されます。 - **コスト**：手動バックアップは長期保存されるため、追加料金が発生する。 @@ -91,7 +91,7 @@ TiDB Cloud Premiumは、自動バックアップに加えて、手動バック 3. 操作を確認してください。バックアップはTiDB Cloudに保存され、**バックアップリスト**に表示されます。 -TiDB Cloudコンソールでは、外部storageの認証情報を入力することなく、手動バックアップを直接復元できます。 +TiDB Cloudコンソールでは、外部ストレージの認証情報を入力することなく、手動バックアップを直接復元できます。 ## 復元する {#restore} @@ -172,7 +172,7 @@ TiDB Cloudは、新しいインスタンスへのデータ復元をサポート ### 別のプランタイプからバックアップを復元する {#restore-backups-from-a-different-plan-type} -現在、AWS上でホストされているTiDB Cloud Dedicatedクラスタから新しいTiDB Cloud Premiumインスタンスへのバックアップ復元のみが可能です。 +現在、AWS上でホストされているTiDB Cloud Dedicatedクラスターから新しいTiDB Cloud Premiumインスタンスへのバックアップ復元のみが可能です。 TiDB Cloud Dedicatedクラスターによって生成されたバックアップを復元するには、次の手順に従ってください。 @@ -187,21 +187,21 @@ TiDB Cloud Dedicatedクラスターによって生成されたバックアップ 3. **[復元]**ページで、[新しいインスタンスに復元する](#restore-to-a-new-instance)と同じ手順に従って、バックアップを新しいインスタンスに復元します。 -### クラウドstorageからバックアップを復元する {#restore-backups-from-cloud-storage} +### クラウドストレージからバックアップを復元する {#restore-backups-from-cloud-ストレージ} -TiDB Cloud Premiumは、クラウドstorage（Amazon S3やAlibaba Cloud Object Storage Service（OSS）など）から新しいインスタンスへのバックアップ復元をサポートしています。この機能は、 TiDB Cloud DedicatedクラスタまたはTiDB Self-Managedクラスタから生成されたバックアップと互換性があります。 +TiDB Cloud Premiumは、クラウドストレージ（Amazon S3やAlibaba Cloud Object Storage Service（OSS）など）から新しいインスタンスへのバックアップ復元をサポートしています。この機能は、 TiDB Cloud DedicatedクラスターまたはTiDB Self-Managedクラスターから生成されたバックアップと互換性があります。 > **注記：** > > - 現在、復元対象としてサポートされているのは、 **Amazon S3**および**Alibaba Cloud OSS**に保存されているバックアップのみです。 -> - バックアップの復元は、storageバケットと同じクラウドプロバイダーがホストする新しいインスタンスにのみ可能です。 -> - インスタンスとstorageバケットが異なるリージョンに配置されている場合、リージョン間データ転送料金が別途発生する可能性があります。 +> - バックアップの復元は、ストレージバケットと同じクラウドプロバイダーがホストする新しいインスタンスにのみ可能です。 +> - インスタンスとストレージバケットが異なるリージョンに配置されている場合、リージョン間データ転送料金が別途発生する可能性があります。 #### 手順 {#steps} 開始する前に、バックアップファイルにアクセスするための十分な権限を持つアクセスキーとシークレットキーを用意してください。 -クラウドstorageからバックアップを復元するには、以下の手順を実行してください。 +クラウドストレージからバックアップを復元するには、以下の手順を実行してください。 1. [TiDB Cloudコンソール](https://tidbcloud.com)にログインし、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動します。右上隅にある**[...]**をクリックし、 **[クラウド ストレージから復元]**をクリックします。 @@ -219,7 +219,7 @@ TiDB Cloud Premiumは、クラウドstorage（Amazon S3やAlibaba Cloud Object S > **ヒント：** > - > storageバケットのアクセスキーを作成するには、 [AWSアクセスキーを使用してAmazon S3へのアクセスを設定する](#configure-amazon-s3-access-using-an-aws-access-key)および[Alibaba Cloud OSSへのアクセスを設定する](#configure-alibaba-cloud-oss-access)参照してください。 + > ストレージバケットのアクセスキーを作成するには、 [AWSアクセスキーを使用してAmazon S3へのアクセスを設定する](#configure-amazon-s3-access-using-an-aws-access-key)および[Alibaba Cloud OSSへのアクセスを設定する](#configure-alibaba-cloud-oss-access)参照してください。 3. **「バックアップの確認」をクリックし、「次へ」を**クリックします。 diff --git a/tidb-cloud/premium/built-in-monitoring-premium.md b/tidb-cloud/premium/built-in-monitoring-premium.md index 04ae33b220b5d..5642cf4a58ab9 100644 --- a/tidb-cloud/premium/built-in-monitoring-premium.md +++ b/tidb-cloud/premium/built-in-monitoring-premium.md @@ -40,7 +40,7 @@ TiDB Cloud Premiumインスタンスの場合、メトリクスデータは7日 | 1秒あたりのコマンド数 | {タイプ} | コマンドの種類に基づいた、1秒あたりに処理されるコマンドの数。 | | プランキャッシュOPSを使用したクエリ | ヒット、ミス | hit: プランキャッシュを使用するクエリが1秒あたりに実行される回数。
    miss: 1秒あたりにプランキャッシュに見つからないクエリの数。 | | トランザクション/秒 | {タイプ}-{トランザクションモデル} | 1秒あたりに実行されるトランザクション数。 | -| トランザクション期間 | 平均-{トランザクションモデル}、99-{トランザクションモデル} | 取引の平均期間、または99パーセンタイル値。 | +| トランザクション期間 | 平均-{トランザクションモデル}、99-{トランザクションモデル} | トランザクションの平均期間、または99パーセンタイル値。 | | 接続数 | すべて、アクティブな接続 | すべて：接続数。
    アクティブな接続数：アクティブな接続の数。 | | 切断回数 | {結果} | 接続が切断されたクライアントの数。 | @@ -56,7 +56,7 @@ TiDB Cloud Premiumインスタンスの場合、メトリクスデータは7日 | メトリック名 | ラベル | 説明 | | :---------------------------- | :----------------- | :--------------------------------------------------------------------------------------------------------------------------------- | -| 平均アイドル接続時間 | 取引内平均、取引外平均 | 接続アイドル時間とは、接続がアイドル状態であった時間を示します。
    avg-in-txn: 接続がトランザクション内にある場合の平均接続アイドル時間。
    avg-not-in-txn: 接続がトランザクション内にない場合の平均接続アイドル時間。 | +| 平均アイドル接続時間 | トランザクション内平均、トランザクション外平均 | 接続アイドル時間とは、接続がアイドル状態であった時間を示します。
    avg-in-txn: 接続がトランザクション内にある場合の平均接続アイドル時間。
    avg-not-in-txn: 接続がトランザクション内にない場合の平均接続アイドル時間。 | | トークンの有効期間を取得する | 平均、99 | SQL文のトークンを取得するのに要する平均時間、または99パーセンタイル値。 | | 解析時間 | 平均、99 | SQL文の解析に要する平均時間、または99パーセンタイル値。 | | コンパイル時間 | 平均、99 | 解析されたSQL抽象構文木（AST）を実行計画にコンパイルする際に要する平均時間、または99パーセンタイル値。 | diff --git a/tidb-cloud/premium/connect-to-premium-via-public-connection.md b/tidb-cloud/premium/connect-to-premium-via-public-connection.md index f6cf988ebfc1d..cad0bd736962e 100644 --- a/tidb-cloud/premium/connect-to-premium-via-public-connection.md +++ b/tidb-cloud/premium/connect-to-premium-via-public-connection.md @@ -42,4 +42,4 @@ summary: パブリック接続を介してTiDB Cloud Premiumに接続する方 ## 次は？ {#what-s-next} -TiDB Cloud Premium インスタンスに正常に接続したら、 [TiDBを使用してSQLステートメントを探索する](/basic-sql-operations.md)ことができます。 +TiDB Cloud Premium インスタンスに正常に接続したら、 [TiDBでのSQL基本操作](/basic-sql-operations.md)ことができます。 diff --git a/tidb-cloud/premium/connect-to-tidb-instance.md b/tidb-cloud/premium/connect-to-tidb-instance.md index 570562a3d46be..42e2d13750c48 100644 --- a/tidb-cloud/premium/connect-to-tidb-instance.md +++ b/tidb-cloud/premium/connect-to-tidb-instance.md @@ -9,7 +9,7 @@ summary: さまざまな方法でTiDB Cloud Premiumインスタンスに接続 > **ヒント：** > -> TiDB Cloud Dedicatedクラスターに接続する方法については、 [TiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/connect-to-tidb-cluster.md)を参照してください。 +> TiDB Cloud Dedicatedクラスターに接続する方法については、 [TiDB Cloud Dedicatedクラスターに接続します](/tidb-cloud/connect-to-tidb-cluster.md)を参照してください。 ## 接続方法 {#connection-methods} @@ -43,4 +43,4 @@ TiDB Cloud Premiumには、2種類のネットワーク接続タイプがあり ## 次は？ {#what-s-next} -TiDB Cloud Premium インスタンスに正常に接続したら、 [TiDBを使用してSQLステートメントを探索する](/basic-sql-operations.md)ことができます。 +TiDB Cloud Premium インスタンスに正常に接続したら、 [TiDBでのSQL基本操作](/basic-sql-operations.md)ことができます。 diff --git a/tidb-cloud/premium/create-tidb-instance-premium.md b/tidb-cloud/premium/create-tidb-instance-premium.md index dfb6e188bb229..23460d7492d83 100644 --- a/tidb-cloud/premium/create-tidb-instance-premium.md +++ b/tidb-cloud/premium/create-tidb-instance-premium.md @@ -9,7 +9,7 @@ summary: TiDB Cloud Premiumインスタンスの作成方法を学びましょ > **注記：** > -> TiDB Cloud Dedicatedクラスターを作成する方法については、 [TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 +> TiDB Cloud Dedicatedクラスターを作成する方法については、 [TiDB Cloud Dedicatedクラスターを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 ## 始める前に {#before-you-begin} diff --git a/tidb-cloud/premium/dual-layer-data-encryption-premium.md b/tidb-cloud/premium/dual-layer-data-encryption-premium.md index 66389b7d96be4..3ce30ae33b5a1 100644 --- a/tidb-cloud/premium/dual-layer-data-encryption-premium.md +++ b/tidb-cloud/premium/dual-layer-data-encryption-premium.md @@ -13,7 +13,7 @@ summary: AWS上でホストされているTiDB Cloud Premiumインスタンス ## 概要 {#overview} -TiDB Cloud Premiumは、デフォルトでインスタンスstorageとスナップショットボリューム上の保存データを暗号化し、基本的なデータセキュリティレベルを提供します。さらに、 TiDB Cloud Premiumは、TiDBstorageエンジンの暗号化とクラウドプロバイダーのキー管理サービス（KMS）を組み合わせることをサポートしています。この追加レイヤーは、**デュアルレイヤーデータ暗号化**と呼ばれます。 +TiDB Cloud Premiumは、デフォルトでインスタンスストレージとスナップショットボリューム上の保存データを暗号化し、基本的なデータセキュリティレベルを提供します。さらに、 TiDB Cloud Premiumは、TiDBストレージエンジンの暗号化とクラウドプロバイダーのキー管理サービス（KMS）を組み合わせることをサポートしています。この追加レイヤーは、**デュアルレイヤーデータ暗号化**と呼ばれます。 ### 暗号化メカニズム {#encryption-mechanism} @@ -21,7 +21,7 @@ TiDB Cloud Premiumは、より高いレベルのデータセキュリティを - **ストレージ層暗号化** - - 基盤となるクラウドサービスプロバイダーは、storageストラクチャ上でストレージ層暗号化を提供します。例えば、AWSでは、Amazon Elastic Block Store（EBS）ボリュームの暗号化とAmazon Simple Storage Service（S3）バケットの暗号化が含まれます。 + - 基盤となるクラウドサービスプロバイダーは、ストレージストラクチャ上でストレージ層暗号化を提供します。例えば、AWSでは、Amazon Elastic Block Store（EBS）ボリュームの暗号化とAmazon Simple Storage Service（S3）バケットの暗号化が含まれます。 - このレイヤーは、すべてのTiDB Cloud Premiumインスタンスでデフォルトで有効になっており、無効にすることはできません。これは、保存データに対する基本的なセキュリティ基準を提供します。 - **データベース層の暗号化** diff --git a/tidb-cloud/premium/import-csv-files-premium.md b/tidb-cloud/premium/import-csv-files-premium.md index 5c8e5eb5a81a7..2c9ad30a51056 100644 --- a/tidb-cloud/premium/import-csv-files-premium.md +++ b/tidb-cloud/premium/import-csv-files-premium.md @@ -3,7 +3,7 @@ title: Import CSV Files from Cloud Storage into TiDB Cloud Premium summary: Amazon S3またはAlibaba Cloud Object Storage Service（OSS）からCSVファイルをTiDB Cloud Premiumインスタンスにインポートする方法を学びましょう。 --- -# クラウドストレージからCSVファイルをTiDB Cloud Premiumにインポートする {#import-csv-files-from-cloud-storage-into-tidb-cloud-premium} +# クラウドストレージからCSVファイルをTiDB Cloud Premiumにインポートする {#import-csv-files-from-cloud-ストレージ-into-tidb-cloud-premium} このドキュメントでは、Amazon Simple Storage Service (Amazon S3) または Alibaba Cloud Object Storage Service (OSS) から CSV ファイルをTiDB Cloud Premium インスタンスにインポートする方法について説明します。 @@ -79,11 +79,11 @@ CSVファイルにはスキーマ情報が含まれていないため、CSVフ TiDB Cloud PremiumがAmazon S3またはAlibaba Cloud Object Storage Service（OSS）内のCSVファイルにアクセスできるようにするには、次のいずれかの操作を行います。 -- CSV ファイルが Amazon S3 にある場合は、 TiDB Cloud Premium インスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)。 +- CSV ファイルが Amazon S3 にある場合は、 TiDB Cloud Premium インスタンスに対して[Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-amazon-s3-access)。 バケットにアクセスするには、AWS アクセスキーまたはロール ARN のいずれかを使用できます。完了したら、[ステップ4](#step-4-import-csv-files)で必要となるため、アクセスキー (アクセスキー ID とシークレット アクセスキーを含む) またはロール ARN の値をメモしておいてください。 -- CSV ファイルが Alibaba Cloud Object Storage Service (OSS) にある場合は、 TiDB Cloud Premium インスタンスの[Alibaba Cloud Object Storage Service (OSS) へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)。 +- CSV ファイルが Alibaba Cloud Object Storage Service (OSS) にある場合は、 TiDB Cloud Premium インスタンスの[Alibaba Cloud Object Storage Service (OSS) へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-alibaba-cloud-object-ストレージ-service-oss-access)。 ## ステップ4．CSVファイルをインポートする {#step-4-import-csv-files} @@ -110,7 +110,7 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`s3://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力します。例: `s3://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`s3://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `s3://sampledata/ingest/` 。 - - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)参照してください。 + - **認証情報**: AWS ロール ARN または AWS アクセス キーを使用してバケットにアクセスできます。詳細については、 [Amazon S3へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-amazon-s3-access)参照してください。 - **AWS ロール ARN** : AWS ロール ARN の値を入力してください。新しいロールを作成する必要がある場合は、 **[ここをクリックして AWS CloudFormation を使用して新しいロールを作成] をクリックし**、ガイド付き手順に従って、提供されているテンプレートを起動し、 IAM警告を確認し、スタックを作成し、生成された ARN をTiDB Cloud Premium にコピーしてください。 - **AWSアクセスキー**：AWSアクセスキーIDとAWSシークレットアクセスキーを入力してください。 - **バケットへのアクセスをテストする**：認証情報が正しく入力された後、このボタンをクリックして、 TiDB Cloud Premiumがバケットにアクセスできることを確認してください。 @@ -165,7 +165,7 @@ CSVファイルをTiDB Cloud Premiumにインポートするには、以下の - **ソースファイルURI** ： - 1 つのファイルをインポートする場合は、ソースファイルの URI を`oss://[bucket_name]/[data_source_folder]/[file_name].csv`の形式で入力してください。例: `oss://sampledata/ingest/TableName.01.csv` 。 - 複数のファイルをインポートする場合は、ソースフォルダのURIを`oss://[bucket_name]/[data_source_folder]/`の形式で入力してください。例： `oss://sampledata/ingest/` 。 - - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)参照してください。 + - **Credential** : AccessKey ペアを使用してバケットにアクセスできます。詳細については、 [Alibaba Cloudオブジェクトストレージサービス（OSS）へのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-alibaba-cloud-object-ストレージ-service-oss-access)参照してください。 - **バケットへのアクセスをテストする**：認証情報が正しく入力された後、このボタンをクリックして、 TiDB Cloud Premiumがバケットにアクセスできることを確認してください。 - **ターゲット接続**：インポートを実行するTiDBのユーザー名とパスワードを入力してください。必要に応じて、 **「接続テスト」を**クリックして認証情報を検証してください。 diff --git a/tidb-cloud/premium/import-from-s3-premium.md b/tidb-cloud/premium/import-from-s3-premium.md index d08c50b4f36d8..864a938f2d130 100644 --- a/tidb-cloud/premium/import-from-s3-premium.md +++ b/tidb-cloud/premium/import-from-s3-premium.md @@ -15,7 +15,7 @@ summary: コンソールウィザードを使用して、Amazon S3からTiDB Clo ## 制限事項 {#limitations} - データの一貫性を確保するため、 TiDB Cloud Premium では、CSV ファイルを空のテーブルにのみインポートできます。対象テーブルに既にデータが含まれている場合は、ステージングテーブルにインポートしてから、 `INSERT ... SELECT`ステートメントを使用して行をコピーしてください。 -- パブリックプレビュー期間中は、ユーザーインターフェースはstorageプロバイダーとしてAmazon S3のみをサポートしています。その他のプロバイダーへの対応は、今後のリリースで追加される予定です。 +- パブリックプレビュー期間中は、ユーザーインターフェースはストレージプロバイダーとしてAmazon S3のみをサポートしています。その他のプロバイダーへの対応は、今後のリリースで追加される予定です。 - 各インポートジョブは、単一のソースパターンを1つの宛先テーブルにマッピングします。 ## ステップ1. CSVファイルを準備する {#step-1-prepare-the-csv-files} diff --git a/tidb-cloud/premium/import-with-mysql-cli-premium.md b/tidb-cloud/premium/import-with-mysql-cli-premium.md index a04a3b086aa35..6daf7cf425f5e 100644 --- a/tidb-cloud/premium/import-with-mysql-cli-premium.md +++ b/tidb-cloud/premium/import-with-mysql-cli-premium.md @@ -9,7 +9,7 @@ summary: MySQLコマンドラインクライアント（mysql`）を使用して > **ヒント：** > -> - 論理インポートは、比較的小さな SQL ファイルまたは CSV ファイルに最適です。クラウドstorageからのより高速な並行インポート、または[Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview)エクスポートからの複数のファイルの処理については、 [クラウドストレージからCSVファイルをTiDB Cloud Premiumにインポートする](/tidb-cloud/premium/import-csv-files-premium.md)インポートするを参照してください。 +> - 論理インポートは、比較的小さな SQL ファイルまたは CSV ファイルに最適です。クラウドストレージからのより高速な並行インポート、または[Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview)エクスポートからの複数のファイルの処理については、 [クラウドストレージからCSVファイルをTiDB Cloud Premiumにインポートする](/tidb-cloud/premium/import-csv-files-premium.md)インポートするを参照してください。 > - TiDB Cloud StarterまたはEssentialについては、 [MySQL CLI を介してTiDB Cloud StarterまたはEssentialにデータをインポートする](/tidb-cloud/import-with-mysql-cli-serverless.md)参照してください。 > - TiDB Cloud Dedicatedについては、 [MySQL CLI を介してTiDB Cloud Dedicatedにデータをインポートする](/tidb-cloud/import-with-mysql-cli.md)参照してください。 diff --git a/tidb-cloud/premium/migrate-from-op-tidb-premium.md b/tidb-cloud/premium/migrate-from-op-tidb-premium.md index ba0ea27cd5291..9e69ebfd1294a 100644 --- a/tidb-cloud/premium/migrate-from-op-tidb-premium.md +++ b/tidb-cloud/premium/migrate-from-op-tidb-premium.md @@ -5,7 +5,7 @@ summary: TiDB Self-ManagedからTiDB Cloud Premiumへのデータ移行方法を # TiDB Self-ManagedからTiDB Cloud Premiumへの移行 {#migrate-from-tidb-self-managed-to-tidb-cloud-premium} -このドキュメントでは、 DumplingとTiCDCを使用して、TiDBセルフマネージドクラスタからTiDB Cloudプレミアム（AWS上）インスタンスにデータを移行する方法について説明します。 +このドキュメントでは、 DumplingとTiCDCを使用して、TiDB Self-ManagedクラスターからTiDB Cloudプレミアム（AWS上）インスタンスにデータを移行する方法について説明します。 全体の手順は以下のとおりです。 @@ -77,11 +77,11 @@ tiup update --self && tiup update dumpling ### TiCDCをデプロイ {#deploy-ticdc} -上流の TiDB セルフマネージド クラスターからTiDB Cloud Premium に増分データを複製するには、 [TiCDCをデプロイする](https://docs.pingcap.com/tidb/dev/deploy-ticdc)必要があります。 +上流の TiDB Self-Managed クラスターからTiDB Cloud Premium に増分データを複製するには、 [TiCDCをデプロイする](https://docs.pingcap.com/tidb/dev/deploy-ticdc)必要があります。 -1. 現在の TiDB バージョンが TiCDC をサポートしているかどうかを確認します。 TiDB v4.0.8.rc.1 以降のバージョンは TiCDC をサポートします。 TiDB のバージョンを確認するには、TiDB セルフマネージド クラスターで`select tidb_version();`実行します。アップグレードする必要がある場合は、 [TiUPを使用してTiDBをアップグレードする](https://docs.pingcap.com/tidb/dev/deploy-ticdc#upgrade-ticdc-using-tiup)参照してください。 +1. 現在の TiDB バージョンが TiCDC をサポートしているかどうかを確認します。 TiDB v4.0.8.rc.1 以降のバージョンは TiCDC をサポートします。 TiDB のバージョンを確認するには、TiDB Self-Managed クラスターで`select tidb_version();`実行します。アップグレードする必要がある場合は、 [TiUPを使用してTiDBをアップグレードする](https://docs.pingcap.com/tidb/dev/deploy-ticdc#upgrade-ticdc-using-tiup)参照してください。 -2. TiCDCコンポーネントをTiDB 自己管理クラスターに追加します。 [TiUPを使用して、既存のTiDBクラスタにTiCDCを追加またはスケールアウトします。](https://docs.pingcap.com/tidb/dev/deploy-ticdc#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup)参照してください。 `scale-out.yml`ファイルを編集して TiCDC を追加します。 +2. TiCDCコンポーネントをTiDB 自己管理クラスターに追加します。 [TiUPを使用して、既存のTiDBクラスターにTiCDCを追加またはスケールアウトします。](https://docs.pingcap.com/tidb/dev/deploy-ticdc#add-or-scale-out-ticdc-to-an-existing-tidb-cluster-using-tiup)参照してください。 `scale-out.yml`ファイルを編集して TiCDC を追加します。 ```yaml cdc_servers: @@ -102,20 +102,20 @@ tiup update --self && tiup update dumpling ## 全てのデータを移行する {#migrate-full-data} -TiDBセルフマネージドクラスタからTiDB Cloudプレミアムにデータを移行するには、以下の手順で完全なデータ移行を実行します。 +TiDB Self-ManagedクラスターからTiDB Cloudプレミアムにデータを移行するには、以下の手順で完全なデータ移行を実行します。 -1. TiDBセルフマネージドクラスターからAmazon S3へデータを移行します。 +1. TiDB Self-ManagedクラスターからAmazon S3へデータを移行します。 2. Amazon S3からTiDB Cloud Premiumへデータを移行します。 -### TiDBセルフマネージドクラスターからAmazon S3へデータを移行する {#migrate-data-from-the-tidb-self-managed-cluster-to-amazon-s3} +### TiDB Self-ManagedクラスターからAmazon S3へデータを移行する {#migrate-data-from-the-tidb-self-managed-cluster-to-amazon-s3} -TiDBセルフマネージドクラスターからAmazon S3へDumplingを使用してデータを移行する必要があります。 +TiDB Self-ManagedクラスターからAmazon S3へDumplingを使用してデータを移行する必要があります。 -TiDBセルフマネージドクラスターがローカルIDCにある場合、またはDumplingサーバーとAmazon S3間のネットワークが接続されていない場合は、まずファイルをローカルstorageにエクスポートしてから、後でAmazon S3にアップロードすることができます。 +TiDB Self-ManagedクラスターがローカルIDCにある場合、またはDumplingサーバーとAmazon S3間のネットワークが接続されていない場合は、まずファイルをローカルストレージにエクスポートしてから、後でAmazon S3にアップロードすることができます。 -#### ステップ1. アップストリームのTiDBセルフマネージドクラスタのGCメカニズムを一時的に無効にします。 {#step-1-disable-the-gc-mechanism-of-the-upstream-tidb-self-managed-cluster-temporarily} +#### ステップ1. アップストリームのTiDB Self-ManagedクラスターのGCメカニズムを一時的に無効にします。 {#step-1-disable-the-gc-mechanism-of-the-upstream-tidb-self-managed-cluster-temporarily} -増分移行中に新しく書き込まれたデータが失われないようにするには、移行を開始する前にアップストリームクラスタのガベージコレクション（GC）メカニズムを無効にして、システムが履歴データをクリーンアップしないようにする必要があります。 +増分移行中に新しく書き込まれたデータが失われないようにするには、移行を開始する前にアップストリームクラスターのガベージコレクション（GC）メカニズムを無効にして、システムが履歴データをクリーンアップしないようにする必要があります。 設定が成功したかどうかを確認するには、次のコマンドを実行してください。 @@ -149,9 +149,9 @@ AWS コンソールでアクセスキーを作成します。詳細について ![Download CSV file](/media/tidb-cloud/op-to-cloud-create-access-key02.png) -#### ステップ3. Dumplingを使用して、上流のTiDBセルフマネージドクラスターからAmazon S3にデータをエクスポートします。 {#step-3-export-data-from-the-upstream-tidb-self-managed-cluster-to-amazon-s3-using-dumpling} +#### ステップ3. Dumplingを使用して、上流のTiDB Self-ManagedクラスターからAmazon S3にデータをエクスポートします。 {#step-3-export-data-from-the-upstream-tidb-self-managed-cluster-to-amazon-s3-using-dumpling} -Dumplingを使用して、アップストリームのTiDBセルフマネージドクラスターからAmazon S3にデータをエクスポートするには、次の手順を実行します。 +Dumplingを使用して、アップストリームのTiDB Self-ManagedクラスターからAmazon S3にデータをエクスポートするには、次の手順を実行します。 1. Dumplingの環境変数を設定します。 @@ -199,7 +199,7 @@ Dumplingを使用して、アップストリームのTiDBセルフマネージ ### Amazon S3からTiDB Cloud Premiumへデータを移行する {#migrate-data-from-amazon-s3-to-tidb-cloud-premium} -TiDBセルフマネージドクラスターからAmazon S3にデータをエクスポートした後、そのデータをTiDB Cloud Premiumに移行する必要があります。 +TiDB Self-ManagedクラスターからAmazon S3にデータをエクスポートした後、そのデータをTiDB Cloud Premiumに移行する必要があります。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、対象のTiDB Cloud Premium インスタンスのアカウント ID と外部 ID を取得します。 @@ -301,7 +301,7 @@ TiDBセルフマネージドクラスターからAmazon S3にデータをエク --start-ts="431434047157698561" ``` - - `--pd` : アップストリームクラスタのPDアドレス。形式は`[upstream_pd_ip]:[pd_port]`です。 + - `--pd` : アップストリームクラスターのPDアドレス。形式は`[upstream_pd_ip]:[pd_port]`です。 - `--sink-uri` : レプリケーション タスクのダウンストリーム アドレス。 `--sink-uri`は、次の形式に従って構成します。現在、このスキームは`mysql` 、 `tidb` 、 `kafka` 、 `s3` 、および`local` 。 @@ -311,11 +311,11 @@ TiDBセルフマネージドクラスターからAmazon S3にデータをエク - `--changefeed-id` : レプリケーションタスクのID。形式は、^[a-zA-Z0-9]+(-[a-zA-Z0-9]+)*$ の正規表現に一致する必要があります。このIDが指定されていない場合、TiCDCは自動的にUUID（バージョン4形式）をIDとして生成します。 - - `--start-ts` : 変更フィードの開始TSOを指定します。TiCDCクラスタはこのTSOからデータの取得を開始します。デフォルト値は現在時刻です。 + - `--start-ts` : 変更フィードの開始TSOを指定します。TiCDCクラスターはこのTSOからデータの取得を開始します。デフォルト値は現在時刻です。 - 詳細については、 [TiCDC ChangefeedsのCLIとコンフィグレーションパラメータ](https://docs.pingcap.com/tidb/dev/ticdc-changefeed-config)を参照してください。 + 詳細については、 [TiCDC ChangefeedsのCLIと設定パラメータ](https://docs.pingcap.com/tidb/dev/ticdc-changefeed-config)を参照してください。 -5. アップストリームクラスタでGCメカニズムを再度有効にします。増分レプリケーションでエラーや遅延が検出されない場合は、GCメカニズムを有効にしてクラスタのガベージコレクションを再開します。 +5. アップストリームクラスターでGCメカニズムを再度有効にします。増分レプリケーションでエラーや遅延が検出されない場合は、GCメカニズムを有効にしてクラスターのガベージコレクションを再開します。 設定が正しく機能しているかどうかを確認するには、以下のコマンドを実行してください。 @@ -347,7 +347,7 @@ TiDBセルフマネージドクラスターからAmazon S3にデータをエク ![Update Filter](/media/tidb-cloud/normal_status_in_replication_task.png) - - レプリケーションを確認します。アップストリームのクラスタに新しいレコードを書き込み、そのレコードがダウンストリームのTiDB Cloud Premiumインスタンスにレプリケートされているかどうかを確認します。 + - レプリケーションを確認します。アップストリームのクラスターに新しいレコードを書き込み、そのレコードがダウンストリームのTiDB Cloud Premiumインスタンスにレプリケートされているかどうかを確認します。 7. アップストリームクラスターとダウンストリームインスタンスで同じタイムゾーンを設定してください。デフォルトでは、 TiDB Cloud PremiumはタイムゾーンをUTCに設定します。アップストリームクラスターとダウンストリームインスタンスのタイムゾーンが異なる場合は、両方で同じタイムゾーンを設定する必要があります。 @@ -375,11 +375,11 @@ TiDBセルフマネージドクラスターからAmazon S3にデータをエク SELECT DISTINCT(CONCAT('CREATE GLOBAL BINDING FOR ', original_sql,' USING ', bind_sql,';')) FROM mysql.bind_info WHERE status='enabled'; ``` - 出力が得られない場合は、アップストリームクラスタでクエリバインディングが使用されていないことを意味します。この場合は、この手順をスキップできます。 + 出力が得られない場合は、アップストリームクラスターでクエリバインディングが使用されていないことを意味します。この場合は、この手順をスキップできます。 クエリバインディングを取得したら、ダウンストリームインスタンスでそれらを実行してクエリバインディングを復元します。 -9. アップストリームクラスタのユーザー情報と権限情報をバックアップし、ダウンストリームインスタンスに復元します。ユーザー情報と権限情報のバックアップには、以下のスクリプトを使用できます。プレースホルダーを実際の値に置き換える必要があることに注意してください。 +9. アップストリームクラスターのユーザー情報と権限情報をバックアップし、ダウンストリームインスタンスに復元します。ユーザー情報と権限情報のバックアップには、以下のスクリプトを使用できます。プレースホルダーを実際の値に置き換える必要があることに注意してください。 ```shell #!/bin/bash diff --git a/tidb-cloud/premium/premium-export.md b/tidb-cloud/premium/premium-export.md index fa9bfaa9b7420..9dcff7f9d13ee 100644 --- a/tidb-cloud/premium/premium-export.md +++ b/tidb-cloud/premium/premium-export.md @@ -5,7 +5,7 @@ summary: TiDB Cloud Premiumインスタンスからデータをエクスポー # TiDB Cloud Premium からデータをエクスポート {#export-data-from-tidb-cloud-premium} -TiDB Cloudを使用すると、 TiDB Cloud Premiumインスタンスから外部storageサービスにデータをエクスポートできます。エクスポートしたデータは、バックアップ、移行、データ分析、その他の目的に使用できます。 +TiDB Cloudを使用すると、 TiDB Cloud Premiumインスタンスから外部ストレージサービスにデータをエクスポートできます。エクスポートしたデータは、バックアップ、移行、データ分析、その他の目的に使用できます。 [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html)やTiDB [Dumpling](https://docs.pingcap.com/tidb/dev/dumpling-overview)などのツールを使用してデータをエクスポートすることもできますが、 TiDB Cloudが提供するエクスポート機能は、 TiDB Cloud Premiumインスタンスからデータをエクスポートするためのより便利で効率的な方法を提供します。この機能には、次のような利点があります。 @@ -20,10 +20,10 @@ TiDB Cloudを使用すると、 TiDB Cloud Premiumインスタンスから外部 ## 輸出先 {#export-locations} -データを以下の外部storage場所にエクスポートできます。 +データを以下の外部ストレージ場所にエクスポートできます。 - [Amazon S3](https://aws.amazon.com/s3/) -- [Azure Blob Storage](https://azure.microsoft.com/en-us/services/storage/blobs/) +- [Azure Blob Storage](https://azure.microsoft.com/en-us/services/ストレージ/blobs/) - [Alibaba Cloudオブジェクトストレージサービス（OSS）](https://www.alibabacloud.com/product/oss) ### Amazon S3 {#amazon-s3} @@ -35,16 +35,16 @@ TiDB Cloudを使用すると、 TiDB Cloud Premiumインスタンスから外部 - [アクセスキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html): アクセス キーに`s3:PutObject`権限があることを確認してください。 - [ロールARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) ：ロールARN（Amazonリソースネーム）に`s3:PutObject`権限が付与されていることを確認してください。なお、ロールARNはAWS上でホストされているTiDB Cloud Premiumインスタンスのみがサポートしています。 -詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)参照してください。 +詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-amazon-s3-access)参照してください。 -### Azure Blob Storage {#azure-blob-storage} +### Azure Blob Storage {#azure-blob-ストレージ} Azure Blob Storage にデータをエクスポートするには、以下の情報を提供する必要があります。 - URI: `azure://.blob.core.windows.net///`または`https://.blob.core.windows.net///` -- アクセス資格情報: Azure Blob Storage コンテナーの[共有アクセス署名（SAS）トークン](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview)。 SAS トークンに、 `Read`および`Write`リソースに対する`Container`および`Object`権限があることを確認してください。 +- アクセス資格情報: Azure Blob Storage コンテナーの[共有アクセス署名（SAS）トークン](https://docs.microsoft.com/en-us/azure/ストレージ/common/ストレージ-sas-overview)。 SAS トークンに、 `Read`および`Write`リソースに対する`Container`および`Object`権限があることを確認してください。 -詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)参照してください。 +詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-azure-blob-ストレージ-access)参照してください。 ### アリババクラウドOSS {#alibaba-cloud-oss} @@ -53,7 +53,7 @@ Alibaba Cloud OSSにデータをエクスポートするには、以下の情報 - URI: `oss:////` - アクセス資格情報: Alibaba Cloud アカウントの[アクセスキーペア](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair)。 AccessKey ペアに`oss:PutObject`および`oss:GetBucketInfo`権限があることを確認してください。 -詳細については、 [外部ストレージへのアクセスを設定する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)参照してください。 +詳細については、 [外部ストレージへのアクセスを設定する](/tidb-cloud/configure-external-ストレージ-access.md#configure-alibaba-cloud-object-ストレージ-service-oss-access)参照してください。 ## エクスポートオプション {#export-options} @@ -110,7 +110,7 @@ TiDB Cloudコンソールは、選択したデータベースとテーブルを - **ストレージプロバイダー**：Amazon S3を選択してください。 - **フォルダURI** ： `s3:////`形式でAmazon S3のURIを入力してください。 - **バケットへのアクセス**：以下のアクセス認証情報から1つを選択し、認証情報を入力してください。 - - **AWS ロール ARN** : バケットにアクセスする権限を持つロール ARN を入力します。 AWS CloudFormation を使用してロール ARN を作成することをお勧めします。詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)参照してください。 + - **AWS ロール ARN** : バケットにアクセスする権限を持つロール ARN を入力します。 AWS CloudFormation を使用してロール ARN を作成することをお勧めします。詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-amazon-s3-access)参照してください。 - **AWSアクセスキー**：バケットへのアクセス権限を持つアクセスキーIDとアクセスキーシークレットを入力してください。 - **エクスポートするデータ**：エクスポートするデータベースまたはテーブルを選択してください。 - **データ形式**： **SQL**または**CSV**を選択してください。 @@ -118,7 +118,7 @@ TiDB Cloudコンソールは、選択したデータベースとテーブルを 4. **「エクスポート」**をクリックします。 -### データをAzure Blob Storageにエクスポートする {#export-data-to-azure-blob-storage} +### データをAzure Blob Storageにエクスポートする {#export-data-to-azure-blob-ストレージ} 1. [TiDB Cloudコンソール](https://tidbcloud.com/)にログインし、 [**TiDBインスタンス**](https://tidbcloud.com/tidbs)ページに移動します。 @@ -135,7 +135,7 @@ TiDB Cloudコンソールは、選択したデータベースとテーブルを - **ターゲット接続**： - **ストレージプロバイダー**：Azure Blob Storageを選択してください。 - **フォルダー URI** : `azure://.blob.core.windows.net///`の形式で Azure Blob Storage の URI を入力してください。 - - **SAS トークン**: コンテナーへのアクセス権限を持つ SAS トークンを入力します。 [Azure ARM テンプレート](https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/)を使用して SAS トークンを作成することをお勧めします。詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)参照してください。 + - **SAS トークン**: コンテナーへのアクセス権限を持つ SAS トークンを入力します。 [Azure ARM テンプレート](https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/)を使用して SAS トークンを作成することをお勧めします。詳細については、 [外部ストレージへのアクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-azure-blob-ストレージ-access)参照してください。 - **エクスポートするデータ**：エクスポートするデータベースまたはテーブルを選択してください。 - **データ形式**： **SQL**または**CSV**を選択してください。 - **圧縮**： **Gzip** 、 **Snappy** 、 **Zstd** 、または**None**を選択してください。 diff --git a/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md b/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md index 0b0ae28ddde0b..e1b11e946e3e5 100644 --- a/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md +++ b/tidb-cloud/premium/set-up-sink-private-endpoint-premium.md @@ -33,7 +33,7 @@ TiDB Cloudのロールの詳細については、 [ユーザーロール](/tidb- - ダウンストリームサービスのプライベートエンドポイントサービスの名前 - ダウンストリームサービスがデプロイされている可用性ゾーン（AZ） -ダウンストリーム サービスでプライベート エンドポイント サービスを利用できない場合は、 [ステップ2. Kafkaクラスタをプライベートリンクサービスとして公開する](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service)プライベートリンクサービスとして公開することで、ロードバランサーとプライベートリンクサービスを設定します。 +ダウンストリーム サービスでプライベート エンドポイント サービスを利用できない場合は、 [ステップ2. Kafkaクラスターをプライベートリンクサービスとして公開する](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service)プライベートリンクサービスとして公開することで、ロードバランサーとプライベートリンクサービスを設定します。
    @@ -48,7 +48,7 @@ TiDB Cloudのロールの詳細については、 [ユーザーロール](/tidb- TiDB Cloud VPCへのアクセスを許可するには、エンドポイントサービスの許可リストにTiDB CloudのAlibaba CloudアカウントIDを追加する必要があります。 -ダウンストリーム サービスでプライベート エンドポイント サービスを利用できない場合は、 [ステップ2. Kafkaクラスタをプライベートリンクサービスとして公開する](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service)プライベートリンクサービスとして公開することで、ロードバランサーとプライベートリンクサービスをセットアップします。 +ダウンストリーム サービスでプライベート エンドポイント サービスを利用できない場合は、 [ステップ2. Kafkaクラスターをプライベートリンクサービスとして公開する](/tidb-cloud/setup-aws-self-hosted-kafka-private-link-service.md#step-2-expose-the-kafka-cluster-as-private-link-service)プライベートリンクサービスとして公開することで、ロードバランサーとプライベートリンクサービスをセットアップします。
    diff --git a/tidb-cloud/premium/tidb-cloud-auditing-premium.md b/tidb-cloud/premium/tidb-cloud-auditing-premium.md index 4f0446cf7e951..b4d3256824c15 100644 --- a/tidb-cloud/premium/tidb-cloud-auditing-premium.md +++ b/tidb-cloud/premium/tidb-cloud-auditing-premium.md @@ -29,7 +29,7 @@ TiDB Cloudは、実行されたSQLステートメントなど、データベー ## 監査ログを有効にする {#enable-audit-logging} -TiDB Cloudは、 TiDB Cloud Premiumインスタンスの監査ログをクラウドstorageサービスに記録することをサポートしています。データベース監査ログを有効にする前に、インスタンスが配置されているクラウドプロバイダーでクラウドstorageサービスを設定してください。 +TiDB Cloudは、 TiDB Cloud Premiumインスタンスの監査ログをクラウドストレージサービスに記録することをサポートしています。データベース監査ログを有効にする前に、インスタンスが配置されているクラウドプロバイダーでクラウドストレージサービスを設定してください。 ### AWS 上の TiDB の監査ログを有効にする {#enable-audit-logging-for-tidb-on-aws} @@ -55,11 +55,11 @@ TiDB Cloudが監査ログを書き込む宛先として、組織が所有するA 3. **DB監査ログの**ページで、右上隅にある**「有効にする」**をクリックします。 - 4. **データベース監査ログストレージコンフィグレーション**ダイアログで、 **AWS IAMポリシー設定**セクションを探し、後で使用するために**TiDB CloudアカウントID**と**TiDB Cloud外部ID**を記録してください。 + 4. **データベース監査ログストレージ設定**ダイアログで、 **AWS IAMポリシー設定**セクションを探し、後で使用するために**TiDB CloudアカウントID**と**TiDB Cloud外部ID**を記録してください。 -2. AWS マネジメント コンソールで、 **[IAM]** > **[アクセス管理]** > **[ポリシー]**に移動し、 `s3:PutObject`書き込み専用権限を持つstorageバケット ポリシーが存在するかどうかを確認します。 +2. AWS マネジメント コンソールで、 **[IAM]** > **[アクセス管理]** > **[ポリシー]**に移動し、 `s3:PutObject`書き込み専用権限を持つストレージバケット ポリシーが存在するかどうかを確認します。 - - はいの場合、後で使用するために、一致したstorageバケットポリシーを記録してください。 + - はいの場合、後で使用するために、一致したストレージバケットポリシーを記録してください。 - そうでない場合は、 **IAM** >**アクセス管理**>**ポリシー**>**ポリシーの作成**に移動し、次のポリシー テンプレートに従ってバケット ポリシーを定義します。 ```json @@ -89,7 +89,7 @@ TiDB Cloudが監査ログを書き込む宛先として、組織が所有するA #### ステップ3．監査ログを有効にする {#step-3-enable-audit-logging} -TiDB Cloudコンソールで、 TiDB CloudアカウントIDと外部IDの値を取得した**「データベース監査ログストレージコンフィグレーション」**ダイアログに戻り、以下の手順を実行します。 +TiDB Cloudコンソールで、 TiDB CloudアカウントIDと外部IDの値を取得した**「データベース監査ログストレージ設定」**ダイアログに戻り、以下の手順を実行します。 1. **「バケットURI」**フィールドに、監査ログファイルが書き込まれるS3バケットのURIを入力してください。 @@ -129,7 +129,7 @@ TiDB Cloudが監査ログを書き込む宛先として、組織が所有するA 1. TiDB Cloudコンソールで、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動します。 2. 対象インスタンスの名前をクリックして概要ページに移動し、左側のナビゲーションペインで**「設定」** > **「DB監査ログ」**をクリックします。 3. **DB監査ログの**ページで、右上隅にある**「有効にする」**をクリックします。 - 4. **データベース監査ログストレージコンフィグレーション**ダイアログで、 **Alibaba Cloud RAMポリシー設定**セクションを探し、後で使用するために**TiDB CloudアカウントID**と**TiDB Cloud外部ID**を記録してください。 + 4. **データベース監査ログストレージ設定**ダイアログで、 **Alibaba Cloud RAMポリシー設定**セクションを探し、後で使用するために**TiDB CloudアカウントID**と**TiDB Cloud外部ID**を記録してください。 2. Alibaba Cloud コンソールで、 **[RAM]** > **[権限]** > **[ポリシー]**に移動し、監査ログ OSS バケットに対して`oss:PutObject`書き込み専用権限を持つポリシーが既に存在するかどうかを確認します。 @@ -182,7 +182,7 @@ TiDB Cloudが監査ログを書き込む宛先として、組織が所有するA #### ステップ3．監査ログを有効にする {#step-3-enable-audit-logging} -TiDB Cloudコンソールで、 TiDB CloudアカウントIDを取得した**「データベース監査ログストレージコンフィグレーション」**ダイアログに戻り、以下の手順を実行します。 +TiDB Cloudコンソールで、 TiDB CloudアカウントIDを取得した**「データベース監査ログストレージ設定」**ダイアログに戻り、以下の手順を実行します。 1. **「バケットURI」**フィールドに、OSSバケットのURIを入力します。例： `oss://tidb-cloud-audit-log` 。 @@ -225,7 +225,7 @@ TiDB Cloudコンソールで、 TiDB CloudアカウントIDを取得した**「 ## 監査ログをビュー {#view-audit-logs} -TiDB Cloudはデフォルトではデータベース監査ログファイルをstorageサービスに保存するため、storageサービスから監査ログ情報を読み取る必要があります。 +TiDB Cloudはデフォルトではデータベース監査ログファイルをストレージサービスに保存するため、ストレージサービスから監査ログ情報を読み取る必要があります。 TiDB Cloudの監査ログは、インスタンスID、内部ID、およびログ作成日が完全修飾ファイル名に組み込まれた読み取り可能なテキストファイルです。 @@ -237,7 +237,7 @@ TiDB Cloudの監査ログは、インスタンスID、内部ID、およびログ > **注記：** > -> ログファイルのサイズが10MiBに達するたびに、ログファイルはクラウドstorageバケットにプッシュされます。そのため、監査ログを無効にした後は、サイズが10MiB未満のログファイルは自動的にクラウドstorageバケットにプッシュされません。この状況でログファイルを取得するには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 +> ログファイルのサイズが10MiBに達するたびに、ログファイルはクラウドストレージバケットにプッシュされます。そのため、監査ログを無効にした後は、サイズが10MiB未満のログファイルは自動的にクラウドストレージバケットにプッシュされません。この状況でログファイルを取得するには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 ## 監査ログフィールド {#audit-logging-fields} diff --git a/tidb-cloud/premium/tidb-cloud-tls-connect-to-premium.md b/tidb-cloud/premium/tidb-cloud-tls-connect-to-premium.md index 21ae044e86e3d..99a43c96be955 100644 --- a/tidb-cloud/premium/tidb-cloud-tls-connect-to-premium.md +++ b/tidb-cloud/premium/tidb-cloud-tls-connect-to-premium.md @@ -33,7 +33,7 @@ TiDB Cloudでは、TLS接続の確立は、 TiDB Cloud Premiumインスタンス > **注記：** > - > - ダウンロードしたCA証明書は、オペレーティングシステムのデフォルトのstorageパスに保存することも、別のstorageパスを指定することもできます。以降の手順では、コード例のCA証明書パスを、ご自身のCA証明書パスに置き換える必要があります。 + > - ダウンロードしたCA証明書は、オペレーティングシステムのデフォルトのストレージパスに保存することも、別のストレージパスを指定することもできます。以降の手順では、コード例のCA証明書パスを、ご自身のCA証明書パスに置き換える必要があります。 > - TiDB Cloud Premiumでは、クライアントにTLS接続の使用を強制することはなく、 [`require_secure_transport`](/system-variables.md#require_secure_transport-new-in-v610)変数のユーザー定義設定は現在TiDB Cloud Premiumではサポートされていません。 5. ご希望の接続方法を選択し、タブに表示されている接続文字列とサンプルコードを参照してインスタンスに接続してください。 diff --git a/tidb-cloud/prometheus-grafana-integration.md b/tidb-cloud/prometheus-grafana-integration.md index db958818f1924..3988cb322c9ee 100644 --- a/tidb-cloud/prometheus-grafana-integration.md +++ b/tidb-cloud/prometheus-grafana-integration.md @@ -117,8 +117,8 @@ Prometheusは、お客様のTiDB Cloud Essential | `tidbcloud_db_queries_using_plan_cache_ops` | ゲージ | `instance_id: `
    `instance_name: ` | 1秒あたりに実行プランキャッシュにヒットするクエリの統計情報 | | `tidbcloud_db_average_query_duration` | ゲージ | `sql_type: Select\|Insert\|...`
    `instance_id: `
    `instance_name: ` | TiDBにネットワークリクエストが送信されてからクライアントに返されるまでの時間 | | `tidbcloud_db_transaction_per_second` | ゲージ | `type: Commit\|Rollback\|...`
    `txn_mode: optimistic\|pessimistic`
    `instance_id: `
    `instance_name: ` | 1秒あたりに実行されるトランザクション数 | -| `tidbcloud_db_row_storage_used_bytes` | ゲージ | `instance_id: `
    `instance_name: ` | TiDB Cloud Essentialインスタンスの行ベースのstorageサイズ（バイト単位） | -| `tidbcloud_db_columnar_storage_used_bytes` | ゲージ | `instance_id: `
    `instance_name: ` | TiDB Cloud Essentialインスタンスのカラム型storageのサイズ（バイト単位）。TiFlashが有効になっていない場合は0を返します。 | +| `tidbcloud_db_row_ストレージ_used_bytes` | ゲージ | `instance_id: `
    `instance_name: ` | TiDB Cloud Essentialインスタンスの行ベースのストレージサイズ（バイト単位） | +| `tidbcloud_db_columnar_ストレージ_used_bytes` | ゲージ | `instance_id: `
    `instance_name: ` | TiDB Cloud Essentialインスタンスのカラム型ストレージのサイズ（バイト単位）。TiFlashが有効になっていない場合は0を返します。 | | `tidbcloud_resource_manager_resource_request_unit_total` | ゲージ | `instance_id: `
    `instance_name: ` | 消費されたリクエストユニット（RU）の合計。 |     @@ -137,8 +137,8 @@ Prometheusは、お客様のTiDB Cloud Essential | `tidbcloud_db_queries_using_plan_cache_ops` | ゲージ | `instance_id: `
    `instance_name: ` | 1秒あたりに実行プランキャッシュにヒットするクエリの統計情報 | | `tidbcloud_db_average_query_duration` | ゲージ | `sql_type: Select\|Insert\|...`
    `instance_id: `
    `instance_name: ` | TiDBにネットワークリクエストが送信されてからクライアントに返されるまでの時間 | | `tidbcloud_db_transaction_per_second` | ゲージ | `type: Commit\|Rollback\|...`
    `txn_mode: optimistic\|pessimistic`
    `instance_id: `
    `instance_name: ` | 1秒あたりに実行されるトランザクション数 | -| `tidbcloud_db_row_storage_used_bytes` | ゲージ | `instance_id: `
    `instance_name: ` | TiDB Cloud Premiumインスタンスの行ベースのstorageサイズ（バイト単位） | -| `tidbcloud_db_columnar_storage_used_bytes` | ゲージ | `instance_id: `
    `instance_name: ` | TiDB Cloud Premiumインスタンスのカラム型storageのサイズ（バイト単位）。 | +| `tidbcloud_db_row_ストレージ_used_bytes` | ゲージ | `instance_id: `
    `instance_name: ` | TiDB Cloud Premiumインスタンスの行ベースのストレージサイズ（バイト単位） | +| `tidbcloud_db_columnar_ストレージ_used_bytes` | ゲージ | `instance_id: `
    `instance_name: ` | TiDB Cloud Premiumインスタンスのカラム型ストレージのサイズ（バイト単位）。 | | `tidbcloud_resource_manager_resource_request_unit_total` | ゲージ | `instance_id: `
    `instance_name: ` | 消費されたリクエストユニット（RU）の合計。 | | `tidbcloud_changefeed_latency` | ゲージ | `changefeed: `
    `instance_id: `
    `instance_name: ` | 変更フィードの上流と下流間のデータ複製レイテンシー | | `tidbcloud_changefeed_status` | ゲージ | `changefeed: `
    `instance_id: `
    `instance_name: ` | 変更フィードのステータス:
    `-1` : 不明
    `0` : 通常
    `1` : 警告
    `2` : 失敗
    `3` : 停止しました
    `4` : 完了
    `6` : 警告
    `7` : その他 | diff --git a/tidb-cloud/recovery-group-failover.md b/tidb-cloud/recovery-group-failover.md index 4e8bdb63f7419..5263930bb223d 100644 --- a/tidb-cloud/recovery-group-failover.md +++ b/tidb-cloud/recovery-group-failover.md @@ -1,6 +1,6 @@ --- title: Failover and Reprotect Databases -summary: TiDB Cloudクラスタ間でデータベースのフェイルオーバーと再保護を行うために、リカバリグループを使用する方法を学びましょう。 +summary: TiDB Cloudクラスター間でデータベースのフェイルオーバーと再保護を行うために、リカバリグループを使用する方法を学びましょう。 --- # フェイルオーバーとデータベースの再保護 {#failover-and-reprotect-databases} @@ -19,7 +19,7 @@ summary: TiDB Cloudクラスタ間でデータベースのフェイルオーバ ## リカバリグループを使用したフェールオーバーデータベース {#failover-databases-using-a-recovery-group} -災害発生時には、リカバリグループを使用してデータベースをセカンダリクラスタにフェイルオーバーできます。 +災害発生時には、リカバリグループを使用してデータベースをセカンダリクラスターにフェイルオーバーできます。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)では、左上隅のコンボボックスを使用して、対象のプロジェクトに切り替えてください。 @@ -33,7 +33,7 @@ summary: TiDB Cloudクラスタ間でデータベースのフェイルオーバ > > フェイルオーバーを実行すると、既存のレプリケーション関係が切断されます。 -5. プライマリコピーに昇格させるセカンダリTiDB Cloudクラスタを選択します。選択したクラスタが正常な状態であることを確認してください。 +5. プライマリコピーに昇格させるセカンダリTiDB Cloudクラスターを選択します。選択したクラスターが正常な状態であることを確認してください。 6. 確認画面に**「Failover」**と入力し、 **「理解しました、フェイルオーバー グループ」**をクリックしてフェイルオーバーを開始し、フェイルオーバーが引き起こす可能性のある混乱について理解していることを確認してください。 @@ -41,7 +41,7 @@ summary: TiDB Cloudクラスタ間でデータベースのフェイルオーバ ## リカバリグループを使用してデータベースを再保護する {#reprotect-databases-using-a-recovery-group} -フェイルオーバーが完了すると、セカンダリクラスタ上のレプリカデータベースがプライマリコピーになります。しかし、フェイルオーバー処理によってレプリケーション関係が停止するため、これらのデータベースは将来の災害に対して保護されません。 +フェイルオーバーが完了すると、セカンダリクラスター上のレプリカデータベースがプライマリコピーになります。しかし、フェイルオーバー処理によってレプリケーション関係が停止するため、これらのデータベースは将来の災害に対して保護されません。 災害の影響を受けた元のプライマリ クラスターを再びオンラインにできる場合は、 **Reprotect**アクションを使用して、リカバリリージョンから元のリージョンへのレプリケーションを再確立できます。 @@ -55,7 +55,7 @@ summary: TiDB Cloudクラスタ間でデータベースのフェイルオーバ > **注記** > - > **リカバリグループの詳細**ページには、リカバリグループの現在の状態やレプリケーショントポロジなど、リカバリグループに関する情報が表示されます。再保護同期中は、転送されるデータ量が多いため、プライマリクラスタまたはセカンダリクラスタでのオンラインクエリのパフォーマンスに影響が出る可能性があります。データベースの再保護は、負荷の低い時間帯にスケジュールすることをお勧めします。 + > **リカバリグループの詳細**ページには、リカバリグループの現在の状態やレプリケーショントポロジなど、リカバリグループに関する情報が表示されます。再保護同期中は、転送されるデータ量が多いため、プライマリクラスターまたはセカンダリクラスターでのオンラインクエリのパフォーマンスに影響が出る可能性があります。データベースの再保護は、負荷の低い時間帯にスケジュールすることをお勧めします。 > **警告** > diff --git a/tidb-cloud/recovery-group-get-started.md b/tidb-cloud/recovery-group-get-started.md index bf02d02894dda..d0aecda3470d3 100644 --- a/tidb-cloud/recovery-group-get-started.md +++ b/tidb-cloud/recovery-group-get-started.md @@ -9,7 +9,7 @@ summary: TiDB Cloudでリカバリ グループを作成し、その詳細を表 ## 前提条件 {#prerequisites} -- リカバリグループは、データベースを別のクラスタに複製することで、地域的な災害からデータベースを保護します。リカバリグループを作成する前に、2つのTiDB Cloud Dedicatedクラスタが必要です。1つのクラスタはプライマリデータベースをホストし、もう1つのクラスタはプライマリデータベースのレプリカをホストします。まだクラスタを作成していない場合は、 [TiDB Cloud専用クラスタを作成する](/tidb-cloud/create-tidb-cluster.md)の手順に従って必要なクラスタを作成してください。 +- リカバリグループは、データベースを別のクラスターに複製することで、地域的な災害からデータベースを保護します。リカバリグループを作成する前に、2つのTiDB Cloud Dedicatedクラスターが必要です。1つのクラスターはプライマリデータベースをホストし、もう1つのクラスターはプライマリデータベースのレプリカをホストします。まだクラスターを作成していない場合は、 [TiDB Cloud専用クラスターを作成する](/tidb-cloud/create-tidb-cluster.md)の手順に従って必要なクラスターを作成してください。 - 回復グループを作成するには、組織の`Organization Owner`のロールまたは対象プロジェクトの`Project Owner`ロールに属している必要があります。 > **注記** @@ -43,13 +43,13 @@ summary: TiDB Cloudでリカバリ グループを作成し、その詳細を表 > データベースをグループに割り当てるときは、特定のデータベースを選択するか、プライマリ クラスター (現在および将来) 上のすべての (システム以外の) データベースを選択できます。 > > - **すべてのデータベース (現在および将来) を割り当てる**と、クラスターに追加される将来のデータベースは自動的にこのリカバリ グループに含まれ、セカンダリ クラスターに複製されます。 - > - **特定のデータベースを割り当てる**場合は、セカンダリクラスタにレプリケートするプライマリクラスタ上の特定のデータベースを選択します。将来、プライマリクラスタにデータベースが追加されても、これらの新しいデータベースはこのリカバリグループの一部として自動的にレプリケートされません。 + > - **特定のデータベースを割り当てる**場合は、セカンダリクラスターにレプリケートするプライマリクラスター上の特定のデータベースを選択します。将来、プライマリクラスターにデータベースが追加されても、これらの新しいデータベースはこのリカバリグループの一部として自動的にレプリケートされません。 > - > 初期レプリケーション中は、転送されるデータ量が多いため、プライマリクラスタまたはセカンダリクラスタでのオンラインクエリのパフォーマンスに影響が出る可能性があります。データベースの初期保護は、比較的混雑していない時間帯にスケジュールしてください。 + > 初期レプリケーション中は、転送されるデータ量が多いため、プライマリクラスターまたはセカンダリクラスターでのオンラインクエリのパフォーマンスに影響が出る可能性があります。データベースの初期保護は、比較的混雑していない時間帯にスケジュールしてください。 > **警告** > - > 初期レプリケーション中に、プライマリクラスタの選択されたデータベースの内容がセカンダリクラスタのデータベースの内容に置き換えられます。セカンダリクラスタの固有の内容を保持したい場合は、リカバリグループを設定する前にバックアップを完了してください。 + > 初期レプリケーション中に、プライマリクラスターの選択されたデータベースの内容がセカンダリクラスターのデータベースの内容に置き換えられます。セカンダリクラスターの固有の内容を保持したい場合は、リカバリグループを設定する前にバックアップを完了してください。 8. 概要情報を確認し、 **[作成]**をクリックして、新しい回復グループの一部としてデータベースの保護を開始します。 @@ -69,18 +69,18 @@ summary: TiDB Cloudでリカバリ グループを作成し、その詳細を表 > **警告** > - > リカバリグループのセットアップ中に、レプリケーションプロセスのために、パターン`cloud-rg-*`に従った名前のアカウントがセカンダリクラスタに作成されます。このアカウントを削除または変更すると、レプリケーションが中断されます。 + > リカバリグループのセットアップ中に、レプリケーションプロセスのために、パターン`cloud-rg-*`に従った名前のアカウントがセカンダリクラスターに作成されます。このアカウントを削除または変更すると、レプリケーションが中断されます。 ## 回復力レベルについて {#about-resiliency-levels} 回復力レベルは、リカバリグループのさまざまなシナリオにおけるデータ読み取りの一貫性特性を定義します。現在、 TiDB Cloud は以下の回復力レベルのみを提供しています。 -- 整合性は保証されません。リカバリグループのレプリケーション中、下流クラスタはトランザクションの整合性読み取りを保証しません。上流クラスタが利用できなくなった場合、下流クラスタのデータをトランザクションの整合性のある状態に復元することはできません。 +- 整合性は保証されません。リカバリグループのレプリケーション中、下流クラスターはトランザクションの整合性読み取りを保証しません。上流クラスターが利用できなくなった場合、下流クラスターのデータをトランザクションの整合性のある状態に復元することはできません。 TiDB Cloud は、近い将来、次の 2 つの追加の回復力レベルを提供する予定です。 - 最終的な整合性。リカバリグループのレプリケーション中、下流クラスターはトランザクションの整合性読み取りを保証しません。ただし、上流クラスターが利用できなくなった場合は、下流クラスターのデータをトランザクションの整合性が保たれた状態に復元できます。 -- ほぼリアルタイムの整合性。リカバリグループのレプリケーション中、下流クラスタはほぼリアルタイムのトランザクション整合性読み取りを提供します。上流クラスタが利用できなくなった場合でも、下流クラスタのデータをトランザクション整合性状態に復元できます。 +- ほぼリアルタイムの整合性。リカバリグループのレプリケーション中、下流クラスターはほぼリアルタイムのトランザクション整合性読み取りを提供します。上流クラスターが利用できなくなった場合でも、下流クラスターのデータをトランザクション整合性状態に復元できます。 ## 次は何？ {#what-s-next} diff --git a/tidb-cloud/recovery-group-overview.md b/tidb-cloud/recovery-group-overview.md index e504a8e91d307..6b8059c96adc5 100644 --- a/tidb-cloud/recovery-group-overview.md +++ b/tidb-cloud/recovery-group-overview.md @@ -5,17 +5,17 @@ summary: TiDB Cloudリカバリ グループを使用してデータベースを # リカバリグループの概要（ベータ版） {#recovery-group-overview-beta} -TiDB Cloudリカバリグループを使用すると、 TiDB Cloud Dedicated クラスタ間でデータベースを複製し、地域的な災害から保護することができます。クラスタ間でデータベースのフェイルオーバーをオーケストレーションできます。セカンダリクラスタへのフェイルオーバー後、元のプライマリクラスタが再び利用可能になった場合は、逆方向のレプリケーションを再確立してデータベースを再び保護できます。 +TiDB Cloudリカバリグループを使用すると、 TiDB Cloud Dedicated クラスター間でデータベースを複製し、地域的な災害から保護することができます。クラスター間でデータベースのフェイルオーバーをオーケストレーションできます。セカンダリクラスターへのフェイルオーバー後、元のプライマリクラスターが再び利用可能になった場合は、逆方向のレプリケーションを再確立してデータベースを再び保護できます。 ## アーキテクチャ {#architecture} -リカバリグループは、2つのTiDB Cloud Dedicatedクラスタ間でまとめてフェイルオーバーできる、複製されたデータベースのセットで構成されます。各リカバリグループにはプライマリクラスタが割り当てられ、このプライマリクラスタ上のデータベースはグループに関連付けられ、セカンダリクラスタに複製されます。 +リカバリグループは、2つのTiDB Cloud Dedicatedクラスター間でまとめてフェイルオーバーできる、複製されたデータベースのセットで構成されます。各リカバリグループにはプライマリクラスターが割り当てられ、このプライマリクラスター上のデータベースはグループに関連付けられ、セカンダリクラスターに複製されます。 ![Recovery Group](/media/tidb-cloud/recovery-group/recovery-group-overview.png) -- リカバリグループ: 2つのクラスタ間で複製されるデータベースのグループ -- プライマリクラスタ: アプリケーションによってデータベースがアクティブに書き込まれるクラスタ -- セカンダリクラスタ: データベースのレプリカが配置されているクラスタ +- リカバリグループ: 2つのクラスター間で複製されるデータベースのグループ +- プライマリクラスター: アプリケーションによってデータベースがアクティブに書き込まれるクラスター +- セカンダリクラスター: データベースのレプリカが配置されているクラスター > **注記** > diff --git a/tidb-cloud/releases/notification-2023-08-31-console-maintenance.md b/tidb-cloud/releases/notification-2023-08-31-console-maintenance.md index 8d20ff0707206..17b06fcaac610 100644 --- a/tidb-cloud/releases/notification-2023-08-31-console-maintenance.md +++ b/tidb-cloud/releases/notification-2023-08-31-console-maintenance.md @@ -28,8 +28,8 @@ TiDB Cloudコンソールのメタデータサービスをアップグレード ### TiDB Cloudコンソール UI の影響を受ける機能 {#affected-features-of-tidb-cloud-console-ui} -- クラスタレベル - - クラスタ管理 +- クラスターレベル + - クラスター管理 - クラスターを作成する - クラスターを削除する - スケールクラスター @@ -68,7 +68,7 @@ TiDB Cloudコンソールのメタデータサービスをアップグレード ### TiDB Cloud API の影響を受ける機能 {#affected-features-of-tidb-cloud-api} -- クラスタ管理 +- クラスター管理 - [クラスターの作成](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/CreateCluster) - [クラスターの削除](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/DeleteCluster) - [クラスターの更新](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster) diff --git a/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md b/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md index 3aca61794cb1c..bf4711654f908 100644 --- a/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md +++ b/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md @@ -28,8 +28,8 @@ TiDB Cloud Starterの管理インフラストラクチャをアップグレー ### TiDB Cloudコンソール UI の影響を受ける機能 {#affected-features-of-tidb-cloud-console-ui} -- クラスタレベル - - クラスタ管理 +- クラスターレベル + - クラスター管理 - クラスターを作成する - クラスターを削除する - スケールクラスター diff --git a/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md b/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md index 51edeb13393bc..c431d8e545cfd 100644 --- a/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md +++ b/tidb-cloud/releases/notification-2023-11-14-scale-feature-maintenance.md @@ -19,18 +19,18 @@ summary: 2023 年 11 月 14 日のTiDB Cloud Dedicated Scale 機能メンテナ ## インパクト {#impact} -メンテナンス期間中は、 [vCPUとRAMを変更する](https://docs.pingcap.com/tidbcloud/scale-tidb-cluster#change-vcpu-and-ram)無効化され、専用クラスタの vCPU と RAM を変更することはできません。ただし、 「クラスタの変更」ページでノード番号またはstorageを変更することは可能です。TiDB クラスタは通常通りデータの読み取りと書き込みを行うため、オンラインビジネスへの悪影響はありません。 +メンテナンス期間中は、 [vCPUとRAMを変更する](https://docs.pingcap.com/tidbcloud/scale-tidb-cluster#change-vcpu-and-ram)無効化され、専用クラスターの vCPU と RAM を変更することはできません。ただし、 「クラスターの変更」ページでノード番号またはストレージを変更することは可能です。TiDB クラスターは通常通りデータの読み取りと書き込みを行うため、オンラインビジネスへの悪影響はありません。 ### TiDB Cloudコンソール UI の影響を受ける機能 {#affected-features-of-tidb-cloud-console-ui} -- クラスタレベル - - クラスタ管理 +- クラスターレベル + - クラスター管理 - クラスターを変更する - TiDB、TiKV、またはTiFlashノードの vCPU と RAM を変更します。 ### TiDB Cloud API の影響を受ける機能 {#affected-features-of-tidb-cloud-api} -- クラスタ管理 +- クラスター管理 - [クラスターの更新](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster) ## 完了と再開 {#completion-and-resumption} diff --git a/tidb-cloud/releases/notification-2024-04-09-monitoring-features-maintenance.md b/tidb-cloud/releases/notification-2024-04-09-monitoring-features-maintenance.md index b3bbd7135209e..f9f4d85b88a65 100644 --- a/tidb-cloud/releases/notification-2024-04-09-monitoring-features-maintenance.md +++ b/tidb-cloud/releases/notification-2024-04-09-monitoring-features-maintenance.md @@ -38,7 +38,7 @@ summary: 2024年4月9日に実施されるTiDB Cloud監視機能のメンテナ > **注記：** > -> 今回のメンテナンスは、TiDBクラスタの監視機能のみに影響します。その他の機能には影響はありません。TiDBクラスタの管理や、読み書き操作、その他の操作は通常どおり実行できます。 +> 今回のメンテナンスは、TiDBクラスターの監視機能のみに影響します。その他の機能には影響はありません。TiDBクラスターの管理や、読み書き操作、その他の操作は通常どおり実行できます。 - **メトリクス**ページは、数回にわたり短時間（それぞれ20分未満）一時的に利用できなくなります。 - **スロークエリ**ページは、数回の短い期間（それぞれ5分未満）に一時的に利用できなくなります。 diff --git a/tidb-cloud/releases/notification-2024-04-11-dm-feature-maintenance.md b/tidb-cloud/releases/notification-2024-04-11-dm-feature-maintenance.md index bb7368f93aad2..422b3d2e399e3 100644 --- a/tidb-cloud/releases/notification-2024-04-11-dm-feature-maintenance.md +++ b/tidb-cloud/releases/notification-2024-04-11-dm-feature-maintenance.md @@ -28,13 +28,13 @@ summary: 2024 年 4 月 11 日のTiDB Cloud Data Migration (DM) 機能メンテ - クラウドプロバイダー: Google Cloud、リージョン: 東京 (asia-northeast1) - クラウドプロバイダー: Google Cloud、リージョン: シンガポール (asia-southeast1) -このメンテナンスは、TiDBクラスタのDM機能にのみ影響します。その他の機能には影響はありません。引き続きTiDBクラスタを管理し、通常通り読み取り/書き込み操作やその他の操作を実行できます。 +このメンテナンスは、TiDBクラスターのDM機能にのみ影響します。その他の機能には影響はありません。引き続きTiDBクラスターを管理し、通常通り読み取り/書き込み操作やその他の操作を実行できます。 AWS にデプロイされたクラスターの場合: - アップグレード中も、DMタスクは中断することなく実行を継続できます。DMコンソールは通常通り使用できます。 -Google Cloud にデプロイされたクラスタの場合: +Google Cloud にデプロイされたクラスターの場合: - DM コンソールは最大 30 分間利用できなくなります。この間は、DM タスクの作成や管理はできません。 - DMタスクが増分移行段階にある場合、最大30分間中断されます。この間、MySQLデータベースのバイナリログをパージしないでください。アップグレードが完了すると、DMタスクは自動的に再開されます。 diff --git a/tidb-cloud/releases/notification-2024-04-16-monitoring-features-maintenance.md b/tidb-cloud/releases/notification-2024-04-16-monitoring-features-maintenance.md index 4e8cf666acfe6..77658867d62d4 100644 --- a/tidb-cloud/releases/notification-2024-04-16-monitoring-features-maintenance.md +++ b/tidb-cloud/releases/notification-2024-04-16-monitoring-features-maintenance.md @@ -31,7 +31,7 @@ summary: 2024年4月16日に実施されるTiDB Cloud監視機能のメンテナ > **注記：** > -> 今回のメンテナンスは、TiDBクラスタの監視機能のみに影響します。その他の機能には影響はありません。TiDBクラスタの管理や、読み書き操作、その他の操作は通常どおり実行できます。 +> 今回のメンテナンスは、TiDBクラスターの監視機能のみに影響します。その他の機能には影響はありません。TiDBクラスターの管理や、読み書き操作、その他の操作は通常どおり実行できます。 - **メトリクス**ページは、数回にわたり短時間（それぞれ20分未満）一時的に利用できなくなります。 - **スロークエリ**ページは、数回の短い期間（それぞれ5分未満）に一時的に利用できなくなります。 diff --git a/tidb-cloud/releases/notification-2024-09-15-console-maintenance.md b/tidb-cloud/releases/notification-2024-09-15-console-maintenance.md index a8067c7991114..21cb963a05cd1 100644 --- a/tidb-cloud/releases/notification-2024-09-15-console-maintenance.md +++ b/tidb-cloud/releases/notification-2024-09-15-console-maintenance.md @@ -29,8 +29,8 @@ TiDB Cloudコンソールのメタデータサービスをアップグレード ### TiDB Cloudコンソール UI の影響を受ける機能 {#affected-features-of-tidb-cloud-console-ui} -- クラスタレベル - - クラスタ管理 +- クラスターレベル + - クラスター管理 - クラスターを作成する - クラスターを削除する - スケールクラスター @@ -69,7 +69,7 @@ TiDB Cloudコンソールのメタデータサービスをアップグレード ### TiDB Cloud API の影響を受ける機能 {#affected-features-of-tidb-cloud-api} -- クラスタ管理 +- クラスター管理 - [クラスターの作成](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/CreateCluster) - [クラスターの削除](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/DeleteCluster) - [クラスターの更新](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster) diff --git a/tidb-cloud/releases/release-notes-2020.md b/tidb-cloud/releases/release-notes-2020.md index 328007cc7a87f..ff7643c30b7e4 100644 --- a/tidb-cloud/releases/release-notes-2020.md +++ b/tidb-cloud/releases/release-notes-2020.md @@ -11,11 +11,11 @@ summary: 2020 年のTiDB Cloudのリリース ノートについて説明しま - デフォルトの TiDB バージョンを v4.0.9 にアップグレードします。 - TiDB でのアップグレードとスケーリングを適切にサポートし、クライアント障害をゼロにします。 -- バックアップから新しいクラスタを復元した後、クラスタ構成を回復する +- バックアップから新しいクラスターを復元した後、クラスター構成を回復する ## 2020年12月16日 {#december-16-2020} -- すべてのクラスタ層で TiDB ノードの最小数を 1 に調整します。 +- すべてのクラスター層で TiDB ノードの最小数を 1 に調整します。 - SQL Web シェルでシステム コマンドの実行を禁止する - TiDB クラスターの redact-log をデフォルトで有効にする @@ -34,8 +34,8 @@ summary: 2020 年のTiDB Cloudのリリース ノートについて説明しま - サインアップページの利用規約とプライバシーの場所を更新します - フィードバックフォームの入り口ウィジェットを追加する - 設定タブでメンバーがオーナーを削除できないようにする -- TiFlashおよび TiKVstorageチャートのメトリックを変更する -- デフォルトの TiDB クラスタ バージョンを 4.0.8 にアップグレードします。 +- TiFlashおよび TiKVストレージチャートのメトリックを変更する +- デフォルトの TiDB クラスター バージョンを 4.0.8 にアップグレードします。 ## 2020年10月12日 {#october-12-2020} @@ -45,12 +45,12 @@ summary: 2020 年のTiDB Cloudのリリース ノートについて説明しま ## 2020年10月2日 {#october-2-2020} -- TiFlashディスクstorage構成を修正 +- TiFlashディスクストレージ構成を修正 ## 2020年9月14日 {#september-14-2020} - `region`ラベルを追加して監視メトリックを修正します -- 非HTAPクラスタをスケーリングできない問題を修正 +- 非HTAPクラスターをスケーリングできない問題を修正 ## 2020年9月11日 {#september-11-2020} diff --git a/tidb-cloud/releases/release-notes-2021.md b/tidb-cloud/releases/release-notes-2021.md index 163f1767e1d3f..f53b9264f5896 100644 --- a/tidb-cloud/releases/release-notes-2021.md +++ b/tidb-cloud/releases/release-notes-2021.md @@ -31,7 +31,7 @@ summary: 2021 年のTiDB Cloudのリリース ノートについて説明しま 改善点: - Developer Tierの監視能力の向上 -- 自動バックアップ時間をDeveloper Tierクラスタの作成時間と同じに設定することをサポート +- 自動バックアップ時間をDeveloper Tierクラスターの作成時間と同じに設定することをサポート バグ修正: @@ -45,8 +45,8 @@ summary: 2021 年のTiDB Cloudのリリース ノートについて説明しま 各Developer Tierクラスターはフル機能の TiDB クラスターであり、次のものが含まれます。 - 1つのTiDB共有ノード - - 1 つの TiKV 共有ノード (500 MiB の OLTPstorage付き) - - 1 つのTiFlash共有ノード (500 MiB の OLAPstorage付き) + - 1 つの TiKV 共有ノード (500 MiB の OLTPストレージ付き) + - 1 つのTiFlash共有ノード (500 MiB の OLAPストレージ付き) 始めましょ[ここ](/tidb-cloud/tidb-cloud-quickstart.md) . @@ -62,11 +62,11 @@ summary: 2021 年のTiDB Cloudのリリース ノートについて説明しま ## 2021年9月16日 {#september-16-2021} -- 新規にデプロイされたクラスタのデフォルトのTiDBバージョンを5.2.0から5.2.1にアップグレードしてください。5.2.1の詳細な変更点については、リリースノート[5.2.1](https://docs.pingcap.com/tidb/stable/release-5.2.1)をご覧ください。 +- 新規にデプロイされたクラスターのデフォルトのTiDBバージョンを5.2.0から5.2.1にアップグレードしてください。5.2.1の詳細な変更点については、リリースノート[5.2.1](https://docs.pingcap.com/tidb/stable/release-5.2.1)をご覧ください。 ## 2021年9月2日 {#september-2-2021} -- 新規にデプロイされたクラスタのデフォルトのTiDBバージョンを5.0.2から5.2.0にアップグレードしてください。TiDB 5.1.0および5.2.0の機能の詳細については、リリースノート[5.2.0](https://docs.pingcap.com/tidb/stable/release-5.2.0)および[5.1.0](https://docs.pingcap.com/tidb/stable/release-5.1.0)ご覧ください。 +- 新規にデプロイされたクラスターのデフォルトのTiDBバージョンを5.0.2から5.2.0にアップグレードしてください。TiDB 5.1.0および5.2.0の機能の詳細については、リリースノート[5.2.0](https://docs.pingcap.com/tidb/stable/release-5.2.0)および[5.1.0](https://docs.pingcap.com/tidb/stable/release-5.1.0)ご覧ください。 - TiDB Cloud内部機能のいくつかの問題を修正しました。 ## 2021年8月19日 {#august-19-2021} @@ -87,7 +87,7 @@ summary: 2021 年のTiDB Cloudのリリース ノートについて説明しま ## 2021年7月6日 {#july-6-2021} -- 新規にデプロイされたクラスタのデフォルトのTiDBバージョンを4.0.11から5.0.2にアップグレードしてください。このアップグレードにより、パフォーマンスと機能が大幅に向上します。詳細は[ここ](https://docs.pingcap.com/tidb/stable/release-5.0.0)ご覧ください。 +- 新規にデプロイされたクラスターのデフォルトのTiDBバージョンを4.0.11から5.0.2にアップグレードしてください。このアップグレードにより、パフォーマンスと機能が大幅に向上します。詳細は[ここ](https://docs.pingcap.com/tidb/stable/release-5.0.0)ご覧ください。 ## 2021年6月25日 {#june-25-2021} @@ -121,8 +121,8 @@ summary: 2021 年のTiDB Cloudのリリース ノートについて説明しま - サインアッププロセスにメール認証とロボット対策のreCAPTCHAが追加されました - [TiDB Cloudサービス契約](https://pingcap.com/legal/tidb-cloud-services-agreement)と[PingCAPプライバシーポリシー](https://pingcap.com/legal/privacy-policy/)が更新されました - コンソールの申請フォームに記入して[概念実証](/tidb-cloud/tidb-cloud-poc.md)を申請することができます -- UIを介してサンプルデータをTiDB Cloudクラスタにインポートできます +- UIを介してサンプルデータをTiDB Cloudクラスターにインポートできます - 混乱を避けるため、同じ名前のクラスターは許可されません。 - **サポートメニュー**の**「フィードバックを送信」**をクリックするとフィードバックを送信できます。 - データのバックアップと復元機能は、PoCおよびオンデマンドのトライアルオプションでご利用いただけます。 -- 無料トライアルとPoCにポイント計算ツールとポイント利用ダッシュボードが追加されました。すべてのトライアルオプションでデータstorageと転送の費用は無料です。 +- 無料トライアルとPoCにポイント計算ツールとポイント利用ダッシュボードが追加されました。すべてのトライアルオプションでデータストレージと転送の費用は無料です。 diff --git a/tidb-cloud/releases/release-notes-2022.md b/tidb-cloud/releases/release-notes-2022.md index 1962cceaecf19..1d05188fbea84 100644 --- a/tidb-cloud/releases/release-notes-2022.md +++ b/tidb-cloud/releases/release-notes-2022.md @@ -25,11 +25,11 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま [TiDB Cloudコンソール](https://tidbcloud.com)の**バックアップ設定**で PITR 機能を有効または無効にすることができます。 - 詳細については[TiDB クラスタ データのバックアップと復元](/tidb-cloud/backup-and-restore.md)参照してください。 + 詳細については[TiDB クラスター データのバックアップと復元](/tidb-cloud/backup-and-restore.md)参照してください。 - 複数の変更フィード管理と既存の変更フィード編集をサポートします。 - - 異なるデータレプリケーションタスクを管理するために、必要な数だけ変更フィードを作成できるようになりました。現在、各クラスタには最大10個の変更フィードを設定できます。詳細については、 [チェンジフィードの概要](/tidb-cloud/changefeed-overview.md)を参照してください。 + - 異なるデータレプリケーションタスクを管理するために、必要な数だけ変更フィードを作成できるようになりました。現在、各クラスターには最大10個の変更フィードを設定できます。詳細については、 [チェンジフィードの概要](/tidb-cloud/changefeed-overview.md)を参照してください。 - 一時停止状態の既存の変更フィードの設定を編集できます。詳細については、 [変更フィードを編集する](/tidb-cloud/changefeed-overview.md#edit-a-changefeed)参照してください。 - Amazon Aurora MySQL、Amazon Relational Database Service (RDS) MySQL、またはセルフホスト型MySQL互換データベースからTiDB Cloudオンラインへのデータ直接移行をサポートします。この機能は現在、一般提供中です。 @@ -47,7 +47,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - ローカル CSV ファイルをTiDB Cloudにインポートすることをサポートします。 - タスク設定は数回クリックするだけで完了し、ローカルCSVデータをTiDBクラスターに素早くインポートできます。この方法を使用する場合、クラウドstorageバケットのパスとロールARNを指定する必要はありません。インポートプロセス全体が迅速かつスムーズです。 + タスク設定は数回クリックするだけで完了し、ローカルCSVデータをTiDBクラスターに素早くインポートできます。この方法を使用する場合、クラウドストレージバケットのパスとロールARNを指定する必要はありません。インポートプロセス全体が迅速かつスムーズです。 詳細については[ローカルファイルをTiDB Cloudにインポートする](/tidb-cloud/tidb-cloud-import-local-files.md)参照してください。 @@ -140,9 +140,9 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま PITR 機能を使用するには、TiDB クラスターのバージョンが少なくとも v6.3.0 であり、TiKV ノードのサイズが少なくとも 8 vCPU および 16 GiB であることを確認してください。 - デフォルトでは、バックアップデータはクラスタが作成されたリージョンに保存されます。日本では、GCP 上でホストされ PITR が有効になっている TiDB クラスタの場合、バックアップデータを 1 つまたは 2 つのリージョン（東京または大阪、あるいはその両方）に保存することを選択できます。別のリージョンからデータを復元することで、より高いレベルのデータ安全性が確保され、リージョン障害にも耐えることができます。 + デフォルトでは、バックアップデータはクラスターが作成されたリージョンに保存されます。日本では、GCP 上でホストされ PITR が有効になっている TiDB クラスターの場合、バックアップデータを 1 つまたは 2 つのリージョン（東京または大阪、あるいはその両方）に保存することを選択できます。別のリージョンからデータを復元することで、より高いレベルのデータ安全性が確保され、リージョン障害にも耐えることができます。 - 詳細については[TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)参照してください。 + 詳細については[TiDBクラスターデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)参照してください。 この機能はまだベータ版であり、リクエストに応じてのみ利用可能です。 @@ -174,7 +174,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - Serverless Tierクラスターには、Dedicated Tierクラスターと同様に完全に機能する HTAP 機能が引き続き含まれています。 - Serverless Tierでは、クラスターの作成時間が短縮され、瞬時にコールドスタートできます。Developer Tierと比較して、作成時間は数分から数秒に短縮されます。 - デプロイメントトポロジーについて心配する必要はありません。Serverless Tierは、お客様のリクエストに応じて自動的に調整されます。 - - Serverless Tier[セキュリティのためにクラスタへのTLS接続を強制する](/tidb-cloud/secure-connections-to-serverless-clusters.md) 。 + - Serverless Tier[セキュリティのためにクラスターへのTLS接続を強制する](/tidb-cloud/secure-connections-to-serverless-clusters.md) 。 - 既存のDeveloper Tierクラスターは、今後数か月以内にServerless Tierに自動的に移行されます。クラスターのご利用には影響はなく、ベータ版のServerless Tierクラスターのご利用に対して料金は発生しません。 始めましょ[ここ](/tidb-cloud/tidb-cloud-quickstart.md) . @@ -219,7 +219,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - [Vercel 統合マーケットプレイス](https://vercel.com/integrations#databases)中[TiDB Cloud Vercel 統合](https://vercel.com/integrations/tidb-cloud)を公開します。 - [ヴェルセル](https://vercel.com)はフロントエンド開発者向けのプラットフォームであり、イノベーターがインスピレーションの瞬間に創造するために必要なスピードと信頼性を提供します。TiDB Cloud Vercel Integrationを使用すると、VercelプロジェクトをTiDB Cloudクラスタに簡単に接続できます。詳細については、ドキュメント[TiDB CloudとVercelの統合](/tidb-cloud/integrate-tidbcloud-with-vercel.md)をご覧ください。 + [ヴェルセル](https://vercel.com)はフロントエンド開発者向けのプラットフォームであり、イノベーターがインスピレーションの瞬間に創造するために必要なスピードと信頼性を提供します。TiDB Cloud Vercel Integrationを使用すると、VercelプロジェクトをTiDB Cloudクラスターに簡単に接続できます。詳細については、ドキュメント[TiDB CloudとVercelの統合](/tidb-cloud/integrate-tidbcloud-with-vercel.md)をご覧ください。 - [Vercelテンプレートリスト](https://vercel.com/templates)中[TiDB Cloudスターター テンプレート](https://vercel.com/templates/next.js/tidb-cloud-starter)を公開します。 @@ -229,9 +229,9 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- Dedicated Tierクラスターでは、TiKVまたはTiFlashノードの最小storageサイズが500GiBから200GiBに変更されました。これにより、ワークロードのデータ量が少量であるユーザーにとって、よりコスト効率の高い環境が実現します。 +- Dedicated Tierクラスターでは、TiKVまたはTiFlashノードの最小ストレージサイズが500GiBから200GiBに変更されました。これにより、ワークロードのデータ量が少量であるユーザーにとって、よりコスト効率の高い環境が実現します。 - 詳細は[TiKVノードstorage](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size)および[TiFlashノードstorage](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)を参照してください。 + 詳細は[TiKVノードストレージ](/tidb-cloud/size-your-cluster.md#tikv-node-ストレージ-size)および[TiFlashノードストレージ](/tidb-cloud/size-your-cluster.md#tiflash-node-ストレージ)を参照してください。 - TiDB Cloudサブスクリプションをカスタマイズし、コンプライアンス要件を満たすためにオンライン契約を導入します。 @@ -241,7 +241,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - [ドキュメント](/tidb-cloud/terraform-tidbcloud-provider-overview.md)足して[TiDB CloudTerraform プロバイダー](https://registry.terraform.io/providers/tidbcloud/tidbcloud)になります。 - TiDB Cloud Terraform Providerは、 [テラフォーム](https://www.terraform.io/)使用してクラスタ、バックアップ、リストアなどのTiDB Cloudリソースを管理できるプラグインです。リソースのプロビジョニングとインフラストラクチャワークフローを自動化するシンプルな方法をお探しの場合は、 [ドキュメント](/tidb-cloud/terraform-tidbcloud-provider-overview.md)に従ってTiDB Cloud Terraform Providerをお試しください。 + TiDB Cloud Terraform Providerは、 [テラフォーム](https://www.terraform.io/)使用してクラスター、バックアップ、リストアなどのTiDB Cloudリソースを管理できるプラグインです。リソースのプロビジョニングとインフラストラクチャワークフローを自動化するシンプルな方法をお探しの場合は、 [ドキュメント](/tidb-cloud/terraform-tidbcloud-provider-overview.md)に従ってTiDB Cloud Terraform Providerをお試しください。 ## 2022年10月11日 {#october-11-2022} @@ -280,7 +280,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま TiDB Cloudは、ご利用料金がクォータに達すると請求書を発行します。クォータの引き上げ、または月ごとの請求書の受け取りをご希望の場合は、 [当社の販売](https://www.pingcap.com/contact-us/)ご連絡ください。 -- データバックアップ費用からstorage運用手数料を免除します。最新の料金情報については[TiDB Cloudの価格詳細](https://www.pingcap.com/tidb-cloud-pricing-details/)ご覧ください。 +- データバックアップ費用からストレージ運用手数料を免除します。最新の料金情報については[TiDB Cloudの価格詳細](https://www.pingcap.com/tidb-cloud-pricing-details/)ご覧ください。 **コンソールの変更** @@ -318,7 +318,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに対して新しい Google Cloud リージョンをサポートします: `N. Virginia (us-east4)` 。 +- [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対して新しい Google Cloud リージョンをサポートします: `N. Virginia (us-east4)` 。 ## 2022年9月9日 {#september-9-2022} @@ -340,7 +340,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま **APIの変更** -- [TiDB CloudAPI](https://docs.pingcap.com/api/tidb-cloud-api-overview)を通じて TiKV またはTiFlashノードのstorageを増やすことができます。スケーリングには API エンドポイントの`storage_size_gib`フィールドを使用できます。 +- [TiDB CloudAPI](https://docs.pingcap.com/api/tidb-cloud-api-overview)を通じて TiKV またはTiFlashノードのストレージを増やすことができます。スケーリングには API エンドポイントの`ストレージ_size_gib`フィールドを使用できます。 現在、 TiDB Cloud API はまだベータ版であり、リクエストに応じてのみ利用可能です。 @@ -380,7 +380,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - TiDB Cloud API をベータ版として導入します。 - このAPIを通じて、クラスタなどのTiDB Cloudリソースを自動的かつ効率的に管理できます。詳細については、 [TiDB CloudAPI ドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)ご覧ください。 + このAPIを通じて、クラスターなどのTiDB Cloudリソースを自動的かつ効率的に管理できます。詳細については、 [TiDB CloudAPI ドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)ご覧ください。 現在、 TiDB Cloud APIはベータ版であり、リクエストに応じてのみご利用いただけます。APIアクセスを申請するには、リクエストを送信してください。 @@ -391,7 +391,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - ベータとして TiDB と TiKV の`2 vCPU, 8 GiB (Beta)`ノード サイズを追加します。 - - `2 vCPU, 8 GiB (Beta)` TiKV ノードごとに、storageサイズは 200 GiB 〜 500 GiB です。 + - `2 vCPU, 8 GiB (Beta)` TiKV ノードごとに、ストレージサイズは 200 GiB 〜 500 GiB です。 - 推奨される使用シナリオ: @@ -411,7 +411,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - TiDB および TiKV の`4 vCPU, 16 GiB`ノード サイズが一般提供 (GA) になりました。 - - `4 vCPU, 16 GiB` TiKV ノードごとに、storageサイズは 200 GiB から 2 TiB の間になります。 + - `4 vCPU, 16 GiB` TiKV ノードごとに、ストレージサイズは 200 GiB から 2 TiB の間になります。 - 推奨される使用シナリオ: - 中小企業向けの低負荷の本番環境 @@ -437,7 +437,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま ## 2022年7月28日 {#july-28-2022} -- **「Securityクイックスタート」**ダイアログに**「どこからでもアクセスを許可」**ボタンを追加します。これにより、任意のIPアドレスからクラスタにアクセスできるようになります。詳細については、 [クラスタのSecurity設定を構成する](/tidb-cloud/configure-security-settings.md)参照してください。 +- **「Securityクイックスタート」**ダイアログに**「どこからでもアクセスを許可」**ボタンを追加します。これにより、任意のIPアドレスからクラスターにアクセスできるようになります。詳細については、 [クラスターのSecurity設定を構成する](/tidb-cloud/configure-security-settings.md)参照してください。 ## 2022年7月26日 {#july-26-2022} @@ -453,7 +453,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま Developer Tierクラスターでは、バックアップと復元機能（自動バックアップと手動バックアップの両方を含む）は無効になっています。ただし、 [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview)使用してデータをバックアップとしてエクスポートすることは可能です。 -- [Developer Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターのstorageサイズを 500 MiB から 1 GiB に増やします。 +- [Developer Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターのストレージサイズを 500 MiB から 1 GiB に増やします。 - ナビゲーション エクスペリエンスを向上させるために、 TiDB Cloudコンソールにパンくずリストを追加します。 @@ -475,14 +475,14 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま ## 2022年7月5日 {#july-05-2022} -- 列指向storage[TiFlash](/tiflash/tiflash-overview.md)が一般提供 (GA) になりました。 +- 列指向ストレージ[TiFlash](/tiflash/tiflash-overview.md)が一般提供 (GA) になりました。 - - TiFlashにより、TiDBは本質的にハイブリッドトランザクション／分析処理（HTAP）データベースとなります。アプリケーションデータはまずTiKVに保存され、その後Raftコンセンサスアルゴリズムを介してTiFlashに複製されます。つまり、行storageから列storageへのリアルタイムレプリケーションが実現されます。 + - TiFlashにより、TiDBは本質的にハイブリッドトランザクション／分析処理（HTAP）データベースとなります。アプリケーションデータはまずTiKVに保存され、その後Raftコンセンサスアルゴリズムを介してTiFlashに複製されます。つまり、行ストレージから列ストレージへのリアルタイムレプリケーションが実現されます。 - TiFlashレプリカを持つテーブルの場合、TiDB オプティマイザーはコスト見積もりに基づいて TiKV レプリカとTiFlashレプリカのどちらを使用するかを自動的に決定します。 TiFlashがもたらすメリットを体験するには、 [TiDB Cloud HTAP クイックスタートガイド](/tidb-cloud/tidb-cloud-htap-quickstart.md)ご覧ください。 -- Dedicated Tierクラスターに対して TiKV とTiFlashの[storageサイズの増加](/tidb-cloud/scale-tidb-cluster.md#change-storage)をサポートします。 +- Dedicated Tierクラスターに対して TiKV とTiFlashの[ストレージサイズの増加](/tidb-cloud/scale-tidb-cluster.md#change-ストレージ)をサポートします。 - ノード サイズ フィールドにメモリ情報を表示する機能をサポートします。 @@ -492,10 +492,10 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま ## 2022年6月23日 {#june-23-2022} -- TiDB Cloudの最大値[TiKVのstorage容量](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size)を増やします。 +- TiDB Cloudの最大値[TiKVのストレージ容量](/tidb-cloud/size-your-cluster.md#tikv-node-ストレージ-size)を増やします。 - - 8 vCPU または 16 vCPU TiKV: 最大 4 TiB のstorage容量をサポートします。 - - 4 vCPU TiKV: 最大 2 TiB のstorage容量をサポートします。 + - 8 vCPU または 16 vCPU TiKV: 最大 4 TiB のストレージ容量をサポートします。 + - 4 vCPU TiKV: 最大 2 TiB のストレージ容量をサポートします。 ## 2022年6月21日 {#june-21-2022} @@ -509,7 +509,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - [クラスター作成プロセス](/tidb-cloud/create-tidb-cluster.md)を簡略化します。 - クラスターを作成すると、 TiDB Cloud はデフォルトのクラスター名を提供します。デフォルト名を使用することも、更新することもできます。 - - クラスターを作成するときに、 **「クラスタの作成」**ページでパスワードを設定する必要はありません。 + - クラスターを作成するときに、 **「クラスターの作成」**ページでパスワードを設定する必要はありません。 - クラスターの作成中または作成後に、 **[Securityクイック スタート]**ダイアログ ボックスで、クラスターにアクセスするためのルート パスワードと、クラスターに接続するための IP アドレスを設定できます。 ## 2022年6月14日 {#june-14-2022} @@ -544,7 +544,7 @@ summary: 2022 年のTiDB Cloudのリリース ノートについて説明しま - [作成する](/tidb-cloud/create-tidb-cluster.md)または[復元する](/tidb-cloud/backup-and-restore.md#restore) ～ [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの場合、TiDB、TiKV、およびTiFlashの vCPU サイズの構成をサポートします。 - クラスター作成に AWS リージョン`Mumbai`のサポートを追加します。 -- [TiDB Cloudの請求](/tidb-cloud/tidb-cloud-billing.md)のコンピューティング、storage、およびデータ転送コストを更新します。 +- [TiDB Cloudの請求](/tidb-cloud/tidb-cloud-billing.md)のコンピューティング、ストレージ、およびデータ転送コストを更新します。 ## 2022年4月7日 {#april-7-2022} @@ -570,12 +570,12 @@ TiDB Cloudが一般提供を開始しました。以下の[サインアップ](h 一般的な変更点: -- 固定サイズのクラスタ層はもうありません。TiDB、TiKV、 TiFlashのいずれか[クラスターサイズ](/tidb-cloud/size-your-cluster.md)簡単にカスタマイズできます。 +- 固定サイズのクラスター層はもうありません。TiDB、TiKV、 TiFlashのいずれか[クラスターサイズ](/tidb-cloud/size-your-cluster.md)簡単にカスタマイズできます。 - TiFlashのない既存のクラスターに[TiFlash](/tiflash/tiflash-overview.md)ノードを追加することをサポートします。 -- [新しいクラスターを作成する](/tidb-cloud/create-tidb-cluster.md)の場合、storageサイズ（500～2048 GiB）の指定をサポートします。クラスターの作成後はstorageサイズを変更できません。 +- [新しいクラスターを作成する](/tidb-cloud/create-tidb-cluster.md)の場合、ストレージサイズ（500～2048 GiB）の指定をサポートします。クラスターの作成後はストレージサイズを変更できません。 - 新しいパブリック領域を導入します`eu-central-1` 。 - 8 vCPU TiFlashを廃止し、16 vCPU TiFlashを提供します。 -- CPU とstorageの価格を分離します (どちらも 30% のパブリック プレビュー割引があります)。 +- CPU とストレージの価格を分離します (どちらも 30% のパブリック プレビュー割引があります)。 - [請求情報](/tidb-cloud/tidb-cloud-billing.md)と[価格表](https://www.pingcap.com/pricing/)を更新します。 新機能: @@ -586,7 +586,7 @@ TiDB Cloudが一般提供を開始しました。以下の[サインアップ](h - 新しいクラスターの選択したリージョンに基づいてデフォルトのバックアップ時間を割り当てることをサポートします。 - 詳細については[TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)参照してください。 + 詳細については[TiDBクラスターデータのバックアップと復元](/tidb-cloud/backup-and-restore.md)参照してください。 ## 2022年3月4日 {#march-04-2022} diff --git a/tidb-cloud/releases/release-notes-2023.md b/tidb-cloud/releases/release-notes-2023.md index e0a724bd2301e..17e619e77e2ea 100644 --- a/tidb-cloud/releases/release-notes-2023.md +++ b/tidb-cloud/releases/release-notes-2023.md @@ -45,9 +45,9 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- [データ移行](/tidb-cloud/migrate-from-mysql-using-data-migration.md) Google Cloud にデプロイされた TiDB クラスタの高速物理モードをサポートします。 +- [データ移行](/tidb-cloud/migrate-from-mysql-using-data-migration.md) Google Cloud にデプロイされた TiDB クラスターの高速物理モードをサポートします。 - AWSおよびGoogle CloudにデプロイされたTiDBクラスタで物理モードがご利用いただけるようになりました。物理モードの移行速度は最大110MiB/sに達し、論理モードの2.4倍の速度です。このパフォーマンス向上は、大規模なデータセットをTiDB Cloudに迅速に移行する場合に最適です。 + AWSおよびGoogle CloudにデプロイされたTiDBクラスターで物理モードがご利用いただけるようになりました。物理モードの移行速度は最大110MiB/sに達し、論理モードの2.4倍の速度です。このパフォーマンス向上は、大規模なデータセットをTiDB Cloudに迅速に移行する場合に最適です。 詳細については[既存データと増分データを移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md#migrate-existing-data-and-incremental-data)参照してください。 @@ -92,7 +92,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) Google Cloud でのデュアルリージョン バックアップ (ベータ版) をサポートします。 - Google Cloud でホストされるTiDB Cloud Dedicated クラスタは、Google Cloud Storage とシームレスに連携します。Google Cloud Storage の[デュアルリージョン](https://cloud.google.com/storage/docs/locations#location-dr)機能と同様に、 TiDB Cloud Dedicated のデュアルリージョンで使用するリージョンのペアは、同じマルチリージョン内になければなりません。例えば、東京と大阪は同じマルチリージョン`ASIA`内にあるため、デュアルリージョンstorageとして一緒に使用できます。 + Google Cloud でホストされるTiDB Cloud Dedicated クラスターは、Google Cloud Storage とシームレスに連携します。Google Cloud Storage の[デュアルリージョン](https://cloud.google.com/ストレージ/docs/locations#location-dr)機能と同様に、 TiDB Cloud Dedicated のデュアルリージョンで使用するリージョンのペアは、同じマルチリージョン内になければなりません。例えば、東京と大阪は同じマルチリージョン`ASIA`内にあるため、デュアルリージョンストレージとして一緒に使用できます。 詳細については[TiDB Cloud専用データのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-dual-region-backup)参照してください。 @@ -140,7 +140,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターから 2 つの vCPU TiDB ノードと TiKV ノードを削除します。 - 2 vCPU オプションは、 **[クラスタの作成]**ページまたは**[クラスタの変更]**ページで使用できなくなりました。 + 2 vCPU オプションは、 **[クラスターの作成]**ページまたは**[クラスターの変更]**ページで使用できなくなりました。 - JavaScript のリリース[TiDB Cloudサーバーレス ドライバー (ベータ版)](/develop/serverless-driver.md) 。 @@ -193,9 +193,9 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに対して Google Cloud [プライベートサービスコネクト](https://cloud.google.com/vpc/docs/private-service-connect)をサポートします。 +- [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対して Google Cloud [プライベートサービスコネクト](https://cloud.google.com/vpc/docs/private-service-connect)をサポートします。 - プライベート エンドポイントを作成し、Google Cloud でホストされているTiDB Cloud Dedicated クラスタへの安全な接続を確立できるようになりました。 + プライベート エンドポイントを作成し、Google Cloud でホストされているTiDB Cloud Dedicated クラスターへの安全な接続を確立できるようになりました。 主な利点: @@ -205,11 +205,11 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま 詳細については[プライベートエンドポイント経由で Google Cloud に接続する](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)参照してください。 -- [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターから[Google クラウド ストレージ (GCS)](https://cloud.google.com/storage)にデータをストリーミングするための変更フィードの使用をサポートします。 +- [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターから[Google クラウド ストレージ (GCS)](https://cloud.google.com/ストレージ)にデータをストリーミングするための変更フィードの使用をサポートします。 ご自身のアカウントのバケットを使用し、適切にカスタマイズされた権限を付与することで、 TiDB Cloudから GCS にデータをストリーミングできるようになりました。GCS にデータを複製した後、データの変更を自由に分析できます。 - 詳細については[クラウドストレージに保存](/tidb-cloud/changefeed-sink-to-cloud-storage.md)参照してください。 + 詳細については[クラウドストレージに保存](/tidb-cloud/changefeed-sink-to-cloud-ストレージ.md)参照してください。 ## 2023年8月15日 {#august-15-2023} @@ -368,7 +368,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま アプリケーション開発にGitHubをご利用の場合、 TiDB Cloud Serverlessブランチ機能をGitHub CI/CDパイプラインに統合することで、本番のデータベースに影響を与えることなく、ブランチを使用してプルリクエストを自動的にテストできます。詳細については、 [TiDB Cloud Serverless Branching（ベータ版）をGitHubと統合する](/tidb-cloud/branch-github-integration.md)ご覧ください。 -- [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタの週次バックアップをサポートします。詳細については、 [TiDB Cloud専用データのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)参照してください。 +- [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの週次バックアップをサポートします。詳細については、 [TiDB Cloud専用データのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)参照してください。 ## 2023年7月4日 {#july-4-2023} @@ -412,11 +412,11 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま これにより、 TiDB CloudとAmazon S3のシームレスな統合が可能になります。1 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターからAmazon S3へのリアルタイムのデータキャプチャとレプリケーションが可能になり、下流のアプリケーションと分析機能が最新のデータにアクセスできるようになります。 - 詳細については[クラウドstorageに保存](/tidb-cloud/changefeed-sink-to-cloud-storage.md)参照してください。 + 詳細については[クラウドストレージに保存](/tidb-cloud/changefeed-sink-to-cloud-ストレージ.md)参照してください。 -- [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの 16 vCPU TiKV の最大ノードstorageを4 TiB から 6 TiB に増加します。 +- [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの 16 vCPU TiKV の最大ノードストレージを4 TiB から 6 TiB に増加します。 - この機能強化により、 TiDB Cloud Dedicated クラスターのデータstorage容量が増加し、ワークロードのスケーリング効率が向上し、増大するデータ要件に対応できるようになります。 + この機能強化により、 TiDB Cloud Dedicated クラスターのデータストレージ容量が増加し、ワークロードのスケーリング効率が向上し、増大するデータ要件に対応できるようになります。 詳細については[クラスターのサイズ](/tidb-cloud/size-your-cluster.md)参照してください。 @@ -451,7 +451,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま TiDB Playground を使用すると、複雑な構成のない制御された環境で TiDB の機能をリアルタイムで試すことができるため、TiDB の機能を理解するのに最適です。 - TiDB Playground を使い始めるには、 [**TiDB プレイグラウンド**](https://play.tidbcloud.com/?utm_source=docs&utm_medium=tidb_cloud_release_notes)ページに移動し、探索する機能を選択して探索を開始します。 + TiDB Playground を使い始めるには、 [**TiDB プレイグラウンド**](https://play.tidbcloud.com/?utm_source=docs&utm_medium=tidb_cloud_release_notes)ページに移動し、確認する機能を選択して探索を開始します。 ## 2023年6月5日 {#june-5-2023} @@ -527,7 +527,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- 2023 年 4 月 26 日以降に作成された GCP ホスト クラスタのノード サイズの変更をサポートします。 +- 2023 年 4 月 26 日以降に作成された GCP ホスト クラスターのノード サイズの変更をサポートします。 この機能により、需要の増加に合わせて高パフォーマンスノードにアップグレードしたり、コスト削減のために低パフォーマンスノードにダウングレードしたりできます。この柔軟性の向上により、ワークロードに合わせてクラスターの容量を調整し、コストを最適化できます。 @@ -577,7 +577,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - 組織内の最初の 5 [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターについては、 TiDB Cloud は次のようにクラスターごとに無料使用量割り当てを提供します。 - - 行storage: 5 GiB + - 行ストレージ: 5 GiB - [リクエストユニット（RU）](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) : 月間5000万RU 2023年5月31日まで、 Serverless Tierクラスターは引き続き無料で、100%割引となります。それ以降は、無料枠を超えた使用量については課金されます。 @@ -588,7 +588,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - TiDB Cloud [Serverless Tier](/tidb-cloud/select-cluster-tier.md#starter)クラスターのバックアップと復元をサポートします。 - 詳細については[TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore-serverless.md)参照してください。 + 詳細については[TiDBクラスターデータのバックアップと復元](/tidb-cloud/backup-and-restore-serverless.md)参照してください。 - 新しい[Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのデフォルトの TiDB バージョンを[バージョン6.5.1](https://docs.pingcap.com/tidb/stable/release-6.5.1)から[バージョン6.5.2](https://docs.pingcap.com/tidb/stable/release-6.5.2)にアップグレードします。 @@ -711,7 +711,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - [データサービス（ベータ版）](/tidb-cloud/data-service-overview.md) 、データ アプリに対するよりきめ細かいアクセス制御がサポートされます。 - データアプリの詳細ページで、クラスタをデータアプリにリンクし、各APIキーのロールを指定できるようになりました。ロールは、APIキーがリンクされたクラスタへのデータの読み取りまたは書き込みを許可するかどうかを制御し、 `ReadOnly`または`ReadAndWrite`に設定できます。この機能により、データアプリに対してクラスタレベルおよび権限レベルのアクセス制御が可能になり、ビジネスニーズに応じてアクセス範囲をより柔軟に制御できるようになります。 + データアプリの詳細ページで、クラスターをデータアプリにリンクし、各APIキーのロールを指定できるようになりました。ロールは、APIキーがリンクされたクラスターへのデータの読み取りまたは書き込みを許可するかどうかを制御し、 `ReadOnly`または`ReadAndWrite`に設定できます。この機能により、データアプリに対してクラスターレベルおよび権限レベルのアクセス制御が可能になり、ビジネスニーズに応じてアクセス範囲をより柔軟に制御できるようになります。 詳細については、 [リンクされたクラスターを管理する](/tidb-cloud/data-service-manage-data-app.md#manage-linked-data-sources)および[APIキーを管理する](/tidb-cloud/data-service-api-key.md)を参照してください。 @@ -772,7 +772,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - [Dedicated Tier](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの[データ移行](/tidb-cloud/migrate-from-mysql-using-data-migration.md)機能に対して新しい GCP リージョンをサポートします: `Tokyo (asia-northeast1)` 。 - この機能を使用すると、Google Cloud Platform (GCP) の MySQL 互換データベースから TiDB クラスタにデータを簡単かつ効率的に移行できます。 + この機能を使用すると、Google Cloud Platform (GCP) の MySQL 互換データベースから TiDB クラスターにデータを簡単かつ効率的に移行できます。 詳細については[Data Migration を使用して MySQL 互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md)参照してください。 @@ -869,7 +869,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - TiDB Cloudにデータをインポートするときに、 IAMユーザーの AWS アクセスキーを使用して Amazon S3 バケットにアクセスすることをサポートします。 - この方法はロールARNを使用するよりも簡単です。詳細については[Amazon S3 アクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)を参照してください。 + この方法はロールARNを使用するよりも簡単です。詳細については[Amazon S3 アクセスを構成する](/tidb-cloud/dedicated-external-ストレージ.md#configure-amazon-s3-access)を参照してください。 - [監視メトリクスの保持期間](/tidb-cloud/built-in-monitoring.md#metrics-retention-policy) 2 日からより長い期間に延長します。 @@ -938,7 +938,7 @@ summary: 2023 年のTiDB Cloudのリリース ノートについて説明しま - [Data Migration を使用して MySQL 互換データベースをTiDB Cloudに移行する](/tidb-cloud/migrate-from-mysql-using-data-migration.md) - [ChangeFeed を使用してTiDB Cloudから他のデータ サービスにデータをストリーミングする](/tidb-cloud/changefeed-overview.md) - - [TiDB クラスタ データのバックアップと復元](/tidb-cloud/backup-and-restore.md) + - [TiDB クラスター データのバックアップと復元](/tidb-cloud/backup-and-restore.md) ## 2023年1月10日 {#january-10-2023} diff --git a/tidb-cloud/releases/release-notes-2024.md b/tidb-cloud/releases/release-notes-2024.md index 9f6b05483d7cd..d91f808147b85 100644 --- a/tidb-cloud/releases/release-notes-2024.md +++ b/tidb-cloud/releases/release-notes-2024.md @@ -39,7 +39,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)以下のシナリオにおいて、大規模データ書き込みのコストを最大80%削減します。 - [自動コミットモード](/transaction-overview.md#autocommit)で 16 MiB を超える書き込み操作を実行したとき。 - - [楽観的取引モデル](/optimistic-transaction.md)で16 MiBを超える書き込み操作を実行した場合。 + - [楽観的トランザクションモデル](/optimistic-transaction.md)で16 MiBを超える書き込み操作を実行した場合。 - [TiDB Cloudにデータをインポートする](/tidb-cloud/tidb-cloud-migration-overview.md#import-data-from-files-to-tidb-cloud)とき。 この改善により、データ運用の効率性とコスト効率が向上し、ワークロードの規模が拡大するにつれて、より大きなコスト削減効果が得られます。 @@ -68,7 +68,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ この変更は**、2024年11月12日以降に作成された組織**にのみ適用されます。この日付以前に作成された組織は、事前通知の上、段階的に新しい一時停止動作に移行します。 - 詳細については、[TiDB Cloud Dedicatedクラスタの一時停止または再開](/tidb-cloud/pause-or-resume-tidb-cluster.md)を参照してください。 + 詳細については、[TiDB Cloud Dedicatedクラスターの一時停止または再開](/tidb-cloud/pause-or-resume-tidb-cluster.md)を参照してください。 - [Datadogとの連携（ベータ版）](/tidb-cloud/monitor-datadog-integration.md)では、新しいリージョン`AP1` (日本) のサポートが追加されました。 @@ -146,7 +146,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ 以前は、 TiDB Cloud は[TiDB Cloud CLI](/tidb-cloud/cli-reference.md)を使用したデータエクスポートのみをサポートしていました。今後は、 [TiDB Cloudコンソール](https://tidbcloud.com/)TiDB Cloud Serverless クラスターからローカルファイルや Amazon S3 へ簡単にデータをエクスポートできます。 - 詳細については、 [TiDB Cloud Serverless からデータをエクスポート](/tidb-cloud/serverless-export.md)[TiDB Cloud Serverless の外部ストレージアクセスを構成する](/tidb-cloud/configure-external-storage-access.md)参照してください。 + 詳細については、 [TiDB Cloud Serverless からデータをエクスポート](/tidb-cloud/serverless-export.md)[TiDB Cloud Serverless の外部ストレージアクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md)参照してください。 - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの接続エクスペリエンスを向上させます。 @@ -170,7 +170,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターで新しいプライベートエンドポイント接続を作成する際のユーザーエクスペリエンスを向上させるため、 **「プライベートエンドポイント接続の作成」**ページのレイアウトを改良します。 - 詳細については、 [AWSのプライベートエンドポイントを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections.md)および[Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します。](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)参照してください。 + 詳細については、 [AWSのプライベートエンドポイントを介してTiDB Cloud Dedicatedクラスターに接続する](/tidb-cloud/set-up-private-endpoint-connections.md)および[Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスターに接続します。](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)参照してください。 ## 2024年8月6日 {#august-6-2024} @@ -186,9 +186,9 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ **コンソールの変更** -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)のクラスタサイズ構成エクスペリエンスを向上させます。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)のクラスターサイズ構成エクスペリエンスを向上させます。 - TiDB Cloud Dedicatedクラスターの [**クラスタを作成する**](/tidb-cloud/create-tidb-cluster.md)ページと「クラスター [**クラスタの変更**](/tidb-cloud/scale-tidb-cluster.md)ページの**「クラスタサイズ」**セクションのレイアウトを調整します。さらに、 **「クラスタサイズ」**セクションには、適切なクラスター サイズの選択に役立つノード サイズの推奨ドキュメントへのリンクが含まれるようになりました。 + TiDB Cloud Dedicatedクラスターの [**クラスターを作成する**](/tidb-cloud/create-tidb-cluster.md)ページと「クラスター [**クラスターの変更**](/tidb-cloud/scale-tidb-cluster.md)ページの**「クラスターサイズ」**セクションのレイアウトを調整します。さらに、 **「クラスターサイズ」**セクションには、適切なクラスター サイズの選択に役立つノード サイズの推奨ドキュメントへのリンクが含まれるようになりました。 ## 2024年7月23日 {#july-23-2024} @@ -230,7 +230,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ 詳細については、 [定義済みのシステムエンドポイントを追加します](/tidb-cloud/data-service-manage-endpoint.md#add-a-predefined-system-endpoint)参照してください。 -- 低速クエリのデータstorageを強化する。 +- 低速クエリのデータストレージを強化する。 [TiDB Cloudコンソール](https://tidbcloud.com)におけるクエリアクセスの遅延は、より安定し、データベースのパフォーマンスに影響を与えなくなりました。 @@ -274,11 +274,11 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ **全般的な変更** -- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタの16 vCPU TiFlashおよび32 vCPU TiFlashの最大ノードstorageを2048 GiBから4096 GiBに増加します。 +- [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの16 vCPU TiFlashおよび32 vCPU TiFlashの最大ノードストレージを2048 GiBから4096 GiBに増加します。 - この機能強化により、TiDB Cloud Dedicatedクラスタの分析データstorage容量が増加し、ワークロードのスケーリング効率が向上し、増大するデータ要件に対応できるようになります。 + この機能強化により、TiDB Cloud Dedicatedクラスターの分析データストレージ容量が増加し、ワークロードのスケーリング効率が向上し、増大するデータ要件に対応できるようになります。 - 詳細については、 [TiFlashノードstorage](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)を参照してください。 + 詳細については、 [TiFlashノードストレージ](/tidb-cloud/size-your-cluster.md#tiflash-node-ストレージ)を参照してください。 - 新しい[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターのデフォルトの TiDB バージョンを[v7.5.1](https://docs.pingcap.com/tidb/stable/release-7.5.1)から[v7.5.2](https://docs.pingcap.com/tidb/stable/release-7.5.2)にアップグレードします。 @@ -290,11 +290,11 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ この機能を使用すると、TiDB Cloud Dedicatedクラスター間でデータベースを複製できるため、地域的な災害が発生した場合でも迅速なリカバリが可能になります。 `Project Owner`ロールをお持ちの場合は、新しいリカバリグループを作成し、データベースをそのグループに割り当てることで、この機能を有効にできます。リカバリグループを使用してデータベースを複製することで、災害対策を強化し、より厳格な可用性 SLA を満たし、より積極的な復旧ポイント目標 (RPO) および復旧時間目標 (RTO) を達成できます。 -- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)カラム型storage[TiFlash](/tiflash/tiflash-overview.md)向けに、課金および計測機能 (ベータ版) を導入します。 +- [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)カラム型ストレージ[TiFlash](/tiflash/tiflash-overview.md)向けに、課金および計測機能 (ベータ版) を導入します。 - 2024年6月30日まで、 TiDB Cloud Serverlessクラスターのカラム型storageは100%割引で無料です。この日以降は、各TiDB Cloud Serverlessクラスターに5 GiBのカラム型storageの無料クォータが付与されます。無料クォータを超過した場合は、料金が発生します。 + 2024年6月30日まで、 TiDB Cloud Serverlessクラスターのカラム型ストレージは100%割引で無料です。この日以降は、各TiDB Cloud Serverlessクラスターに5 GiBのカラム型ストレージの無料クォータが付与されます。無料クォータを超過した場合は、料金が発生します。 - 詳細については、 [TiDB Cloud Serverlessの料金詳細](https://www.pingcap.com/tidb-serverless-pricing-details/#storage)を参照してください。 + 詳細については、 [TiDB Cloud Serverlessの料金詳細](https://www.pingcap.com/tidb-serverless-pricing-details/#ストレージ)を参照してください。 - [TiDB Cloud Serverless](/tidb-cloud/select-cluster-tier.md#starter)[生きる時間（TTL）](/time-to-live.md)をサポートします。 @@ -326,7 +326,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ **全般的な変更** -- Google Cloud でホストされる[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに新しい[TiDBノードサイズ](/tidb-cloud/size-your-cluster.md#tidb-vcpu-and-ram)を指定します: `8 vCPU, 16 GiB` +- Google Cloud でホストされる[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに新しい[TiDBノードサイズ](/tidb-cloud/size-your-cluster.md#tidb-vcpu-and-ram)を指定します: `8 vCPU, 16 GiB` ## 2024年5月14日 {#may-14-2024} @@ -349,7 +349,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - 新しい[TiDB CloudAPI](https://docs.pingcap.com/api/tidb-cloud-api-overview)をベースに構築された[TiDB Cloud CLI 1.0.0-beta.1](https://github.com/tidbcloud/tidbcloud-cli)をご紹介します。この新しい CLI には、以下の新機能が搭載されています。 - [TiDB Cloud Serverlessクラスターからデータをエクスポートする](/tidb-cloud/serverless-export.md) - - [ローカルstorageからTiDB Cloudサーバーレスクラスターにデータをインポートする](/tidb-cloud/ticloud-import-start.md) + - [ローカルストレージからTiDB Cloudサーバーレスクラスターにデータをインポートする](/tidb-cloud/ticloud-import-start.md) - [OAuth経由で認証する](/tidb-cloud/ticloud-auth-login.md) TiDB Cloud CLI をアップグレードする前に、この新しい CLI は以前のバージョンと互換性がないことに注意してください。たとえば、CLI コマンドの`ticloud cluster`は`ticloud serverless`に更新されます。詳細については、 [TiDB Cloud CLI リファレンス](/tidb-cloud/cli-reference.md)参照してください。 . @@ -368,7 +368,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ TiDB Cloud Serverlessは、多様なユーザーニーズに対応するため、無料プランと拡張可能なサービスプランを提供しています。これからサービスを開始する場合でも、アプリケーションの需要増加に合わせて規模を拡大する場合でも、これらのプランは必要な柔軟性と機能を提供します。 - 詳細については、[クラスタ計画](/tidb-cloud/select-cluster-tier.md)を参照してください。 + 詳細については、[クラスター計画](/tidb-cloud/select-cluster-tier.md)を参照してください。 - TiDB Cloud Serverless クラスターが使用量クォータに達した際のスロットリング動作を変更します。クラスターが使用量クォータに達すると、新規接続試行を即座に拒否し、既存の操作に対するサービスの中断を防ぎます。 @@ -390,7 +390,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) [ノードレベルのリソースメトリクス](/tidb-cloud/built-in-monitoring.md#server)の**制限**ラベルを表示します。 - **制限**ラベルには、クラスター内の各コンポーネントにおけるCPU、メモリ、storageなどのリソースの最大使用量が表示されます。この機能強化により、クラスターのリソース使用率の監視が簡素化されます。 + **制限**ラベルには、クラスター内の各コンポーネントにおけるCPU、メモリ、ストレージなどのリソースの最大使用量が表示されます。この機能強化により、クラスターのリソース使用率の監視が簡素化されます。 これらのメトリック制限にアクセスするには、クラスターの**監視**ページに移動し、 **[メトリック]**タブの**[サーバー]**カテゴリを確認してください。 @@ -417,7 +417,7 @@ summary: TiDB Cloudの2024年のリリースノートについてご確認くだ - TiDB、TiKV、およびTiFlashのノードサイズオプションとして、32 vCPUを追加します。 - 各`32 vCPU, 128 GiB` TiKV ノードのstorageは200 GiB から 6144 GiB の範囲です。 + 各`32 vCPU, 128 GiB` TiKV ノードのストレージは200 GiB から 6144 GiB の範囲です。 次のようなシナリオでは、このようなノードの使用をお勧めします。 diff --git a/tidb-cloud/releases/release-notes-2025.md b/tidb-cloud/releases/release-notes-2025.md index b3a6c7c7fcd99..2033a402acead 100644 --- a/tidb-cloud/releases/release-notes-2025.md +++ b/tidb-cloud/releases/release-notes-2025.md @@ -15,7 +15,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - TiProxy (ベータ版) をサポートします。 - PingCAPの公式プロキシコンポーネントであるTiProxyが、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタでベータ版として利用可能になりました。強化された接続管理と負荷分散機能により、データベースの信頼性とパフォーマンスが向上します。 + PingCAPの公式プロキシコンポーネントであるTiProxyが、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでベータ版として利用可能になりました。強化された接続管理と負荷分散機能により、データベースの信頼性とパフォーマンスが向上します。 ハイライト: @@ -56,7 +56,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま TiDB Cloud Starter は MCP をサポートし、 TiDB Cloud Starter クラスターを Cursor、Claude Code、VS Code、WindSurf などの一般的な AI ツールに統合的かつ安全に接続できるようになりました。一度接続を設定すれば、数分で AI ツールによるデータクエリを開始できます。 - この機能にアクセスするには、 [クラスタ](https://tidbcloud.com/project/clusters)概要ページの右上隅にある**[AI ツールで使用]**をクリックします。 + この機能にアクセスするには、 [クラスター](https://tidbcloud.com/project/clusters)概要ページの右上隅にある**[AI ツールで使用]**をクリックします。 ## 2025年12月9日 {#december-9-2025} @@ -124,9 +124,9 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **TiDB Cloud専用** - - バックアップから[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターを新しいクラスターに復元するときに、デフォルトのstorageタイプを使用する代わりに、 [標準storage](/tidb-cloud/size-your-cluster.md#standard-storage)などの新しいクラスターのノードstorageタイプを選択できるようになりました。 + - バックアップから[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターを新しいクラスターに復元するときに、デフォルトのストレージタイプを使用する代わりに、 [標準ストレージ](/tidb-cloud/size-your-cluster.md#standard-ストレージ)などの新しいクラスターのノードストレージタイプを選択できるようになりました。 - この機能を使用すると、元の構成を正確に復元するか、ニーズに合った別のstorageタイプを選択できます。 + この機能を使用すると、元の構成を正確に復元するか、ニーズに合った別のストレージタイプを選択できます。 詳細については[新しいクラスターにデータを復元する](/tidb-cloud/backup-and-restore.md#restore-data-to-a-new-cluster)参照してください。 @@ -136,7 +136,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - **TiDB Cloud専用** - - Google Cloud でホストされている[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに VPC ピアリング経由で接続する場合、 [TiDB Cloudコンソール](https://tidbcloud.com/)で`/16` ～ `/18` IP 範囲サイズを直接設定できるようになりました。この設定についてTiDB Cloudサポートに連絡する必要がなくなりました。 + - Google Cloud でホストされている[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに VPC ピアリング経由で接続する場合、 [TiDB Cloudコンソール](https://tidbcloud.com/)で`/16` ～ `/18` IP 範囲サイズを直接設定できるようになりました。この設定についてTiDB Cloudサポートに連絡する必要がなくなりました。 詳細については[VPC ピアリング経由でTiDB Cloud Dedicated に接続する](/tidb-cloud/set-up-vpc-peering-connections.md)参照してください。 @@ -196,7 +196,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 現在、データベース監査ログをサポートしているのは[TiDB Cloudエッセンシャル](/tidb-cloud/select-cluster-tier.md#essential)と[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)のみです。データベース監査ログを使用している既存のTiDB Cloud Starter クラスターには影響しません。 - - [TiDB Cloudスターター](/tidb-cloud/select-cluster-tier.md#starter)インプレースリストア機能が削除され、バックアップを同じクラスタに直接リストアできなくなります。この変更により、アクティブな本番本番データの誤った上書きや潜在的なデータ損失を防ぐことができます。 + - [TiDB Cloudスターター](/tidb-cloud/select-cluster-tier.md#starter)インプレースリストア機能が削除され、バックアップを同じクラスターに直接リストアできなくなります。この変更により、アクティブな本番環境データの誤った上書きや潜在的なデータ損失を防ぐことができます。 データを復元するには、 [バックアップを新しいクラスターに復元する](/tidb-cloud/backup-and-restore-serverless.md#perform-the-restore) . 復元されたデータを検証した後、アプリケーションを新しいクラスターに切り替えます。既存のクラスターに復元されたデータはそのまま残り、新たな復元を実行しない限り、特別な操作は必要ありません。 @@ -229,7 +229,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 使用量の上限を超えると、処理能力が制限される可能性があります。サービスへの影響を避けるため、最大RCUを増やすことをご検討ください。 - イベントの詳細については、 [TiDB Cloudクラスタイベント](/tidb-cloud/tidb-cloud-events.md)参照してください。 + イベントの詳細については、 [TiDB Cloudクラスターイベント](/tidb-cloud/tidb-cloud-events.md)参照してください。 - [**メトリクス**](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page)ページ[TiDB Cloudエッセンシャル](/tidb-cloud/select-cluster-tier.md#essential)では、より迅速な診断と容量計画のために次のメトリックが追加されます。 @@ -263,11 +263,11 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま TiDB Cloud Dedicated クラスターでは、 `UPDATE`イベントを生イベントとして保持するか、 `DELETE`と`INSERT`イベントに分割するかを設定できます。この機能により、高度なレプリケーションシナリオにおいて柔軟性が向上します。 - この機能は[クラウドストレージに保存](/tidb-cloud/changefeed-sink-to-cloud-storage.md) [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md) [アパッチパルサーに沈む](/tidb-cloud/changefeed-sink-to-apache-pulsar.md)てください。 + この機能は[クラウドストレージに保存](/tidb-cloud/changefeed-sink-to-cloud-ストレージ.md) [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md) [アパッチパルサーに沈む](/tidb-cloud/changefeed-sink-to-apache-pulsar.md)てください。 分割動作の詳細については、 [MySQL以外のシンクの主キーまたは一意キーの`UPDATE`イベントを分割する](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)参照してください。 - - Google Cloud でホストされている[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに新しいノード サイズ`32 vCPU, 64 GiB`指定します。 + - Google Cloud でホストされている[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに新しいノード サイズ`32 vCPU, 64 GiB`指定します。 この新しいノード サイズは、TiDB ノードで使用できます。 @@ -287,7 +287,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - データ セキュリティ: 暗号化キーを所有および管理することで、データが保護され、制御されることが保証されます。 - コンプライアンス: CMEK を使用すると、データ暗号化に関する規制およびコンプライアンスの要件を満たすことができます。 - - 柔軟性: プロジェクトを作成するときに CMEK を有効にし、クラスタを作成する前に CMEK 構成を完了できます。 + - 柔軟性: プロジェクトを作成するときに CMEK を有効にし、クラスターを作成する前に CMEK 構成を完了できます。 この機能を有効にするには、次の手順を実行します。 @@ -401,7 +401,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - Google Cloud の .NET Framework [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)では、NAT サブネット割り当て戦略を最適化することで、リージョンごとに 8 個を超える Google Private Service Connect (PSC) 接続がサポートされるようになりました。 - 詳細については[Google Cloud Private Service Connect 経由でTiDB Cloud専用クラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md#restrictions)参照してください。 + 詳細については[Google Cloud Private Service Connect 経由でTiDB Cloud専用クラスターに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md#restrictions)参照してください。 - [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)指標を最適化: @@ -426,7 +426,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - Google Cloud の .NET Framework [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)では、NAT サブネット割り当て戦略を最適化することで、リージョンごとに 8 個を超える Google Private Service Connect (PSC) 接続がサポートされるようになりました。 - 詳細については[Google Cloud Private Service Connect 経由でTiDB Cloud専用クラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md#restrictions)参照してください。 + 詳細については[Google Cloud Private Service Connect 経由でTiDB Cloud専用クラスターに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md#restrictions)参照してください。 - [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)指標を最適化: @@ -441,7 +441,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - 以下のリソースを自動的かつ効率的に管理するためのTiDB Cloud専用 API (v1beta1) を導入します。 - - **クラスタ**: TiDB Cloud Dedicated クラスターをより柔軟に管理します。 + - **クラスター**: TiDB Cloud Dedicated クラスターをより柔軟に管理します。 - **リージョン**: TiDB Cloud Dedicated クラスターをデプロイできるすべてのクラウド リージョンを表示します。 - **プライベート エンドポイント接続**: クラスターの安全でプライベートな接続を設定します。 - **インポート**: クラスターのデータ インポート タスクを管理します。 @@ -450,7 +450,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - 以下のリソースを自動的かつ効率的に管理するためのTiDB Cloud Starter および Essential API (v1beta1) を導入します。 - - **クラスタ**: TiDB Cloud Starter または Essential クラスターをより柔軟に管理します。 + - **クラスター**: TiDB Cloud Starter または Essential クラスターをより柔軟に管理します。 - **ブランチ**: クラスターのブランチを管理します。 - **エクスポート**: クラスターのデータ エクスポート タスクを管理します。 - **インポート**: クラスターのデータ インポート タスクを管理します。 @@ -487,7 +487,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- Google Cloud でホストされている[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに新しいノード サイズ`32 vCPU, 128 GiB`指定します。 +- Google Cloud でホストされている[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに新しいノード サイズ`32 vCPU, 128 GiB`指定します。 この新しいサイズは、TiDB、TiKV、およびTiFlashノードで使用できます。 @@ -500,7 +500,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま **コンソールの変更** -- [TiDB Cloudサーバーレス](/tidb-cloud/select-cluster-tier.md#starter)クラスターのクラウドstorageデータのインポート エクスペリエンスを強化します。 +- [TiDB Cloudサーバーレス](/tidb-cloud/select-cluster-tier.md#starter)クラスターのクラウドストレージデータのインポート エクスペリエンスを強化します。 インポートプロセスは、インテリジェントな事前チェック機能を備えた3ステップのウィザードに簡素化されました。この新しいウィザードは、接続設定、ファイルマッピング、バケットスキャンをガイドします。スキャン機能により、 TiDB Cloudはインポート前にインポートされるファイルとその保存先を正確に表示するため、設定の複雑さが大幅に軽減され、インポートの失敗を防止できます。 @@ -554,9 +554,9 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの場合、16 vCPU および 32 vCPU を持つ TiKV ノードの最大storageサイズが**6144 GiB**から**4096 GiB**に変更されます。 +- [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの場合、16 vCPU および 32 vCPU を持つ TiKV ノードの最大ストレージサイズが**6144 GiB**から**4096 GiB**に変更されます。 - 詳細については[TiKVノードのstorageサイズ](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size)参照してください。 + 詳細については[TiKVノードのストレージサイズ](/tidb-cloud/size-your-cluster.md#tikv-node-ストレージ-size)参照してください。 **コンソールの変更** @@ -586,9 +586,9 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま Azure でTiDB Cloud Dedicated をすぐに使い始めるには、次のドキュメントを参照してください。 - - [Azure 上にTiDB Cloud専用クラスタを作成する](/tidb-cloud/create-tidb-cluster.md) - - [Azure プライベート エンドポイント経由でTiDB Cloud専用クラスタを接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md) - - [Azure 上のTiDB Cloud専用クラスタにデータをインポートする](/tidb-cloud/import-csv-files.md) + - [Azure 上にTiDB Cloud専用クラスターを作成する](/tidb-cloud/create-tidb-cluster.md) + - [Azure プライベート エンドポイント経由でTiDB Cloud専用クラスターを接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md) + - [Azure 上のTiDB Cloud専用クラスターにデータをインポートする](/tidb-cloud/import-csv-files.md) - Prometheus 統合により、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの監視機能を強化するためのメトリックがさらに提供されます。 @@ -596,7 +596,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 利用可能なメトリックと、既存ユーザーと新規ユーザーの両方に対してメトリックを有効にする方法の詳細については、 [TiDB Cloud をPrometheus および Grafana と統合する (ベータ版)](/tidb-cloud/monitor-prometheus-and-grafana-integration.md#metrics-available-to-prometheus)参照してください。 -- TiKV [標準](/tidb-cloud/size-your-cluster.md#standard-storage)および[パフォーマンス](/tidb-cloud/size-your-cluster.md#performance-and-plus-storage)storageの価格が正式に発表されました。 +- TiKV [標準](/tidb-cloud/size-your-cluster.md#standard-ストレージ)および[パフォーマンス](/tidb-cloud/size-your-cluster.md#performance-and-plus-ストレージ)ストレージの価格が正式に発表されました。 割引期間は**2025年6月5日 UTC 00:00**に終了します。その後、価格は通常価格に戻ります。TiDB Cloud Dedicated の価格については、 [TiDB Cloud専用プランの料金詳細](https://www.pingcap.com/tidb-dedicated-pricing-details/#node-cost)ご覧ください。 @@ -612,7 +612,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの変更フィードを使用して[アパッチパルサー](https://pulsar.apache.org)へのデータのストリーミングをサポートします。 - この機能により、 TiDB Cloud Dedicated クラスタをより幅広い下流システムと統合できるようになり、追加のデータ統合要件にも対応できます。この機能を使用するには、 TiDB Cloud Dedicated クラスタのバージョンが v7.5.1 以降であることを確認してください。 + この機能により、 TiDB Cloud Dedicated クラスターをより幅広い下流システムと統合できるようになり、追加のデータ統合要件にも対応できます。この機能を使用するには、 TiDB Cloud Dedicated クラスターのバージョンが v7.5.1 以降であることを確認してください。 詳細については[アパッチパルサーに沈む](/tidb-cloud/changefeed-sink-to-apache-pulsar.md)参照してください。 @@ -631,20 +631,20 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま 開始するには、 [SQLによる全文検索](/ai/guides/vector-search-full-text-search-sql.md)または[Pythonによる全文検索](/ai/guides/vector-search-full-text-search-python.md)を参照してください。 -- [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの最大TiFlashノードstorageを増やします。 +- [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターの最大TiFlashノードストレージを増やします。 - 8 vCPU TiFlashの場合、2048 GiBから4096 GiB - 32 vCPU TiFlashの場合、4096 GiBから8192 GiB - この機能強化により、TiDB Cloud Dedicated クラスターの分析データstorage容量が増加し、ワークロードのスケーリング効率が向上し、増大するデータ要件に対応できるようになります。 + この機能強化により、TiDB Cloud Dedicated クラスターの分析データストレージ容量が増加し、ワークロードのスケーリング効率が向上し、増大するデータ要件に対応できるようになります。 - 詳細については[TiFlashノードstorage](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)参照してください。 + 詳細については[TiFlashノードストレージ](/tidb-cloud/size-your-cluster.md#tiflash-node-ストレージ)参照してください。 - メンテナンス タスクを構成および再スケジュールするための直感的なオプションを提供することで、メンテナンス ウィンドウの構成エクスペリエンスを強化します。 詳細については[メンテナンスウィンドウを構成する](/tidb-cloud/configure-maintenance-window.md)参照してください。 -- TiKV [標準](/tidb-cloud/size-your-cluster.md#standard-storage)および[パフォーマンス](/tidb-cloud/size-your-cluster.md#performance-and-plus-storage)storageタイプの割引期間を延長します。プロモーションは2025年6月5日に終了します。この日以降は、価格が標準料金に戻ります。 +- TiKV [標準](/tidb-cloud/size-your-cluster.md#standard-ストレージ)および[パフォーマンス](/tidb-cloud/size-your-cluster.md#performance-and-plus-ストレージ)ストレージタイプの割引期間を延長します。プロモーションは2025年6月5日に終了します。この日以降は、価格が標準料金に戻ります。 **コンソールの変更** @@ -658,7 +658,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - Alibaba Cloud OSS へのデータエクスポートがサポートされるようになりました。 - [TiDB Cloudサーバーレス](/tidb-cloud/select-cluster-tier.md#starter)クラスターは、 [アクセスキーペア](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair)を使用して[Alibaba Cloud オブジェクト ストレージ サービス (OSS)](https://www.alibabacloud.com/en/product/object-storage-service)にデータをエクスポートできるようになりました。 + [TiDB Cloudサーバーレス](/tidb-cloud/select-cluster-tier.md#starter)クラスターは、 [アクセスキーペア](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair)を使用して[Alibaba Cloud オブジェクト ストレージ サービス (OSS)](https://www.alibabacloud.com/en/product/object-ストレージ-service)にデータをエクスポートできるようになりました。 詳細については[TiDB Cloud Serverlessからデータをエクスポート](/tidb-cloud/serverless-export.md#alibaba-cloud-oss)参照してください。 @@ -668,7 +668,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- [Alibaba Cloud オブジェクト ストレージ サービス (OSS)](https://www.alibabacloud.com/en/product/object-storage-service)クラスターから[TiDB Cloudサーバーレス](/tidb-cloud/select-cluster-tier.md#starter)クラスターへのデータのインポートをサポートします。 +- [Alibaba Cloud オブジェクト ストレージ サービス (OSS)](https://www.alibabacloud.com/en/product/object-ストレージ-service)クラスターから[TiDB Cloudサーバーレス](/tidb-cloud/select-cluster-tier.md#starter)クラスターへのデータのインポートをサポートします。 この機能により、TiDB Cloud Serverlessへのデータ移行が簡素化されます。認証にはAccessKeyペアを使用できます。 @@ -699,21 +699,21 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま メリットの詳細については[技術ブログ](https://www.pingcap.com/blog/tidb-cloud-node-groups-scaling-workloads-predictable-performance/)ご覧ください。開始するには[TiDBノードグループの管理](/tidb-cloud/tidb-node-group-management.md)ご覧ください。 -- AWS でホストされている[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスター内の TiKV ノードに[標準storage](/tidb-cloud/size-your-cluster.md#standard-storage)タイプを導入します。 +- AWS でホストされている[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスター内の TiKV ノードに[標準ストレージ](/tidb-cloud/size-your-cluster.md#standard-ストレージ)タイプを導入します。 - 標準storageタイプは、パフォーマンスとコスト効率のバランスが取れているため、ほとんどのワークロードに最適です。 + 標準ストレージタイプは、パフォーマンスとコスト効率のバランスが取れているため、ほとんどのワークロードに最適です。 **主な利点:** - - **パフォーマンスの向上**: Raftログに十分なディスク リソースを予約し、 Raftとデータstorage間の I/O 競合を減らして、TiKV の読み取りと書き込みのパフォーマンスを向上させます。 + - **パフォーマンスの向上**: Raftログに十分なディスク リソースを予約し、 Raftとデータストレージ間の I/O 競合を減らして、TiKV の読み取りと書き込みのパフォーマンスを向上させます。 - **強化された安定性**: 重要なRaft操作をデータ ワークロードから分離し、より予測可能なパフォーマンスを確保します。 - - **コスト効率**: 従来のstorageタイプと比較して、競争力のある価格でより高いパフォーマンスを実現します。 + - **コスト効率**: 従来のストレージタイプと比較して、競争力のある価格でより高いパフォーマンスを実現します。 **可用性：** - 標準storageタイプは、2025年4月1日以降に作成され、AWSでホストされ、サポート対象バージョン（バージョン7.5.5、8.1.2、または8.5.0以上）の新規クラスター[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)に自動的に適用されます。既存のクラスターは引き続き以前の[基本的なstorage](/tidb-cloud/size-your-cluster.md#basic-storage)タイプを使用しているため、移行は不要です。 + 標準ストレージタイプは、2025年4月1日以降に作成され、AWSでホストされ、サポート対象バージョン（バージョン7.5.5、8.1.2、または8.5.0以上）の新規クラスター[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)に自動的に適用されます。既存のクラスターは引き続き以前の[基本的なストレージ](/tidb-cloud/size-your-cluster.md#basic-ストレージ)タイプを使用しているため、移行は不要です。 - スタンダードstorageの料金はベーシックstorageの料金とは異なります。詳しくは[価格](https://www.pingcap.com/tidb-dedicated-pricing-details/)ご覧ください。 + スタンダードストレージの料金はベーシックストレージの料金とは異なります。詳しくは[価格](https://www.pingcap.com/tidb-dedicated-pricing-details/)ご覧ください。 ## 2025年3月25日 {#march-25-2025} @@ -729,7 +729,7 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま **一般的な変更** -- リソース管理の柔軟性を高めるために、Google Cloud にデプロイされた[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに対して TiDB ノード グループの作成をサポートします。 +- リソース管理の柔軟性を高めるために、Google Cloud にデプロイされた[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対して TiDB ノード グループの作成をサポートします。 詳細については[TiDBノードグループの概要](/tidb-cloud/tidb-node-group-overview.md)参照してください。 @@ -848,4 +848,4 @@ summary: 2025 年のTiDB Cloudのリリース ノートについて説明しま - [TiDB Cloudコンソール](https://tidbcloud.com/)を介して Parquet ファイルでデータのエクスポートをサポートします。 - 詳細については、 [TiDB Cloud Serverlessからデータをエクスポート](/tidb-cloud/serverless-export.md)および[TiDB Cloud Serverless の外部ストレージアクセスを構成する](/tidb-cloud/configure-external-storage-access.md)を参照してください。 + 詳細については、 [TiDB Cloud Serverlessからデータをエクスポート](/tidb-cloud/serverless-export.md)および[TiDB Cloud Serverless の外部ストレージアクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md)を参照してください。 diff --git a/tidb-cloud/releases/tidb-cloud-release-notes.md b/tidb-cloud/releases/tidb-cloud-release-notes.md index 0673971720653..679b331b65a90 100644 --- a/tidb-cloud/releases/tidb-cloud-release-notes.md +++ b/tidb-cloud/releases/tidb-cloud-release-notes.md @@ -36,7 +36,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 、**日本東部**および**米国東部 2**の Microsoft Azure で一般提供 (GA) になりました。 - TiDB Cloud Dedicatedは、99.99%の稼働率SLAを備えた3つのAZ構成による高可用性、 TiFlashによる完全なHTAP、独立したコンピューティングとstorageのスケーリング、PingCAP SREによる完全マネージド運用、シームレスなデータインポートと移行、PITRによる継続的なバックアップ、エンタープライズグレードのセキュリティ、および統合された可観測性を提供します。また、一括データインポート、MySQLやその他のソースからの移行、ダウンストリームシステムへのリアルタイムレプリケーションもサポートしています。Azure [Azure Marketplace](https://azuremarketplace.microsoft.com/)ご利用の場合は、Azure MarketplaceからTiDB Cloud Dedicatedをサブスクライブすることもできます。 + TiDB Cloud Dedicatedは、99.99%の稼働率SLAを備えた3つのAZ構成による高可用性、 TiFlashによる完全なHTAP、独立したコンピューティングとストレージのスケーリング、PingCAP SREによる完全マネージド運用、シームレスなデータインポートと移行、PITRによる継続的なバックアップ、エンタープライズグレードのセキュリティ、および統合された可観測性を提供します。また、一括データインポート、MySQLやその他のソースからの移行、ダウンストリームシステムへのリアルタイムレプリケーションもサポートしています。Azure [Azure Marketplace](https://azuremarketplace.microsoft.com/)ご利用の場合は、Azure MarketplaceからTiDB Cloud Dedicatedをサブスクライブすることもできます。 詳細については、 [プレビュー版から本番環境へ：Microsoft Azure 上のTiDB Cloud Dedicatedが一般提供開始](https://www.pingcap.com/blog/tidb-cloud-dedicated-ga-microsoft-azure/)参照してください。 @@ -52,7 +52,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] TiDB Cloud Premium は[TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)と[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)の間のギャップを埋めるものです。 - - TiDB Cloud Essentialと比較して、 TiDB Cloud Premiumはコンピューティング、storage、ネットワークの各レイヤーにおいて大幅に強化された分離性を提供し、重要なワークロードに対して予測可能なパフォーマンスを保証します。同時に、柔軟性の高いオンデマンドのスケーリングモデルを維持しており、運用上のオーバーヘッドなしにコンピューティング能力を個別に拡張できます。 + - TiDB Cloud Essentialと比較して、 TiDB Cloud Premiumはコンピューティング、ストレージ、ネットワークの各レイヤーにおいて大幅に強化された分離性を提供し、重要なワークロードに対して予測可能なパフォーマンスを保証します。同時に、柔軟性の高いオンデマンドのスケーリングモデルを維持しており、運用上のオーバーヘッドなしにコンピューティング能力を個別に拡張できます。 - TiDB Cloud Dedicatedと比較して、 TiDB Cloud Premiumはアイドル状態の余裕を排除することでコスト効率を向上させ、実際に使用したパフォーマンスに対してのみ料金を支払うことができます。 TiDB Cloud Premium の詳細については、 [TiDB Cloud Premium: ミッションクリティカルなSQLのパブリックプレビュー](https://www.pingcap.com/blog/tidb-cloud-premium-public-preview/)参照してください。 @@ -61,7 +61,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - **TiDB Cloud Dedicated** - - TiProxyがAWS上の[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタで一般提供開始となりました。接続管理と負荷分散機能が強化され、データベースの信頼性とパフォーマンスが向上します。 + - TiProxyがAWS上の[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターで一般提供開始となりました。接続管理と負荷分散機能が強化され、データベースの信頼性とパフォーマンスが向上します。 TiProxyの主な特徴： @@ -136,7 +136,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - **TiDB Cloud Dedicated** - - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタにおけるクラウドstorageデータのインポートエクスペリエンスを向上させます。 + - [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターにおけるクラウドストレージデータのインポートエクスペリエンスを向上させます。 インポートプロセスは、接続、宛先マッピング、事前チェックの3ステップウィザードに簡素化され、Amazon S3、Google Cloud Storage、Azure Blob Storageに対応した**クラウドストレージからのデータインポートの**エントリポイントが統一されました。新しいフローでは、単一ファイルURIとワイルドカードパターンによる手動ファイルマッピングがサポートされ、事前チェックステップではインポート実行前にソースファイルをスキャンしてマッピングをプレビューするため、構成上の問題を早期に発見し、インポートの失敗を減らすことができます。 @@ -200,11 +200,11 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターでは、既存の AK/SK 認証方法に加え、 IAMロール ARN を使用して Amazon S3 シンクの変更フィードを設定できるようになりました。この機能により、有効期限の短い認証情報と自動ローテーションが可能になり、セキュリティが強化されるとともに、シークレット管理が簡素化され、最小権限の原則がサポートされます。 - 詳細については、 [クラウドストレージへのシンク](/tidb-cloud/changefeed-sink-to-cloud-storage.md)参照してください。 + 詳細については、 [クラウドストレージへのシンク](/tidb-cloud/changefeed-sink-to-cloud-ストレージ.md)参照してください。 - - TiKVおよびTiFlashのstorage使用量計算を改善します。 + - TiKVおよびTiFlashのストレージ使用量計算を改善します。 - メトリクスおよびアラートシステムにおけるTiKVおよびTiFlashstorage使用量の計算に、WALファイルと一時ファイルが組み込まれるようになり、より正確な容量および使用状況の監視が可能になりました。 + メトリクスおよびアラートシステムにおけるTiKVおよびTiFlashストレージ使用量の計算に、WALファイルと一時ファイルが組み込まれるようになり、より正確な容量および使用状況の監視が可能になりました。 詳細については、 [TiDB Cloud の組み込みメトリクス](/tidb-cloud/built-in-monitoring.md)を参照してください。 @@ -228,7 +228,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - Azure Blob Storageからのデータインポートにおけるプライベートリンク接続をサポートします。 - Azure Blob Storage から[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターにデータをインポートする際、接続方法としてプライベートリンクを選択し、パブリックインターネットではなく Azure プライベートエンドポイント経由で接続できるようになりました。この機能により、パブリックアクセスが制限されているstorageアカウントに対して、安全でネットワーク分離されたデータインポートが可能になります。 + Azure Blob Storage から[TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターにデータをインポートする際、接続方法としてプライベートリンクを選択し、パブリックインターネットではなく Azure プライベートエンドポイント経由で接続できるようになりました。この機能により、パブリックアクセスが制限されているストレージアカウントに対して、安全でネットワーク分離されたデータインポートが可能になります。 詳細については、[クラウドストレージからサンプルデータ（SQLファイル）をインポートする](/tidb-cloud/import-sample-data.md)[クラウドストレージからCSVファイルをインポートする](/tidb-cloud/import-csv-files.md)[クラウドストレージからApache Parquetファイルをインポートする](/tidb-cloud/import-parquet-files.md)参照してください。 @@ -244,7 +244,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] [TiDB Cloud Dedicated](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated) 、変更フィードデータをAzure Blob Storageに直接保存する機能をサポートするようになりました。この機能により、Azureベースのユーザーは、変更データを効率的にアーカイブして、下流の分析や長期保存に活用できます。また、中間メッセージキューが不要になるためコスト削減にもつながり、既存のAmazon S3およびGoogle Cloud Storage（GCS）シンクとのフォーマット互換性も維持されます。 - 詳細については、 [クラウドストレージへのシンク](/tidb-cloud/changefeed-sink-to-cloud-storage.md)参照してください。 + 詳細については、 [クラウドストレージへのシンク](/tidb-cloud/changefeed-sink-to-cloud-ストレージ.md)参照してください。 ## 2026年1月27日 {#january-27-2026} @@ -298,7 +298,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] [TiDB Cloudコンソール](https://tidbcloud.com/)すべてのサブスクリプションプランにおいてサポート体験を向上させるため、プランに応じたサポートオプションを提供開始しました。これらのアップデートには以下が含まれます。 - - **プランに応じたサポートのリダイレクト**：クラスタ概要ページで、 **[アクション]**列の**[サポートを受ける]**を選択すると、サブスクリプションプランに基づいて最も適切なリソースにリダイレクトされます。ベーシックプランのユーザーは**サポートプラン**パネルに、有料プランのユーザーは**サポートポータル**に誘導されます。 + - **プランに応じたサポートのリダイレクト**：クラスター概要ページで、 **[アクション]**列の**[サポートを受ける]**を選択すると、サブスクリプションプランに基づいて最も適切なリソースにリダイレクトされます。ベーシックプランのユーザーは**サポートプラン**パネルに、有料プランのユーザーは**サポートポータル**に誘導されます。 - **ヘルプセンターメニューの改善**：ヘルプメニュー項目名を**「サポートオプション」**と**「サポートチケット」**に変更し、利用可能なサービスをより適切に反映させます。また、有料プランでのみテクニカルサポートチケットが利用できることを明確にするツールチップを追加します。 - **明確なコミュニティ サポート アクセス**:**サポート プラン**オプション内では、Slack と Discord がベーシック プラン ユーザーの主要なテクニカル サポート チャネルとして明確に識別されます。次のドキュメントは、サポート チャネル ポリシーとコミュニティ アクセスを明確にするために合理化されています: [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)、[コネクテッドケアの概要](/tidb-cloud/connected-care-overview.md)、および[コネクテッドケアの詳細](/tidb-cloud/connected-care-detail.md)。 - **アクション指向のサポートプランUI** ：**サポートプラン**ウィンドウを再設計し、一般的なプラン比較ではなく、現在ご利用のプランで利用可能なサポートオプションを優先的に表示するようにしました。この変更により、現在ご利用のプランに基づいてサポートを受ける方法をすばやく特定できます。 diff --git a/tidb-cloud/scalability-concepts.md b/tidb-cloud/scalability-concepts.md index 2b1ea99a50d73..48c2fbd50a33c 100644 --- a/tidb-cloud/scalability-concepts.md +++ b/tidb-cloud/scalability-concepts.md @@ -10,7 +10,7 @@ TiDB Cloudは、さまざまなワークロードのニーズに対応できる - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter) 、プロトタイプ作成、開発、および初期段階のワークロードに最適です。自動スケーリング機能が組み込まれているため、 TiDB Cloudを簡単かつ費用対効果の高い方法で使い始めることができます。 - [TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)は、トラフィックやデータ量の増加下でも、より堅牢な拡張性と予測可能なパフォーマンスを必要とする本番のワークロード向けに構築されています。 - [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)は、無制限のリアルタイム拡張性を必要とするミッションクリティカルなビジネス向けに設計されています。ワークロードに応じた自動スケーリングと包括的なエンタープライズ機能を提供します。 -- TiDB Cloud Dedicated、データ量やワークロードの変化に合わせて、コンピューティングリソースとstorageリソースを個別に調整できます。TiDB Cloud Dedicatedは、サービスの中断なしにスケーリングが可能です。この柔軟性により、組織は高いパフォーマンスと可用性を維持しながら、インフラストラクチャコストを最適化できます。 +- TiDB Cloud Dedicated、データ量やワークロードの変化に合わせて、コンピューティングリソースとストレージリソースを個別に調整できます。TiDB Cloud Dedicatedは、サービスの中断なしにスケーリングが可能です。この柔軟性により、組織は高いパフォーマンスと可用性を維持しながら、インフラストラクチャコストを最適化できます。 > **ヒント：** > @@ -33,12 +33,12 @@ TiDBは計算処理専用であり、データを保存する機能はありま ## TiKVのスケーラビリティ {#tikv-scalability} -TiKVは行ベースのデータを保存する役割を担います。TiKVのノード数、vCPU、RAM、storageを設定できます。TiKVノード数は最低1セット（3つの異なるゾーンにそれぞれ3ノード）とし、3ノードずつ増やしていく必要があります。 +TiKVは行ベースのデータを保存する役割を担います。TiKVのノード数、vCPU、RAM、ストレージを設定できます。TiKVノード数は最低1セット（3つの異なるゾーンにそれぞれ3ノード）とし、3ノードずつ増やしていく必要があります。 -TiDB Cloudは、耐久性と高可用性を実現するために、選択したリージョン内の3つのアベイラブルゾーンにTiKVノードを均等に配置します。一般的な3レプリカ構成では、データはすべてのアベイラブルゾーンのTiKVノードに均等に分散され、各TiKVノードのディスクに永続化されます。TiKVは主にデータstorageに使用されますが、TiKVノードのパフォーマンスはワークロードによっても異なります。 +TiDB Cloudは、耐久性と高可用性を実現するために、選択したリージョン内の3つのアベイラブルゾーンにTiKVノードを均等に配置します。一般的な3レプリカ構成では、データはすべてのアベイラブルゾーンのTiKVノードに均等に分散され、各TiKVノードのディスクに永続化されます。TiKVは主にデータストレージに使用されますが、TiKVノードのパフォーマンスはワークロードによっても異なります。 ## TiFlashの拡張性 {#tiflash-scalability} -TiFlashは、カラム型データの保存を担当します。TiFlashはTiKVからリアルタイムでデータを同期し、リアルタイム分析ワークロードをすぐにサポートします。TiFlashのノード数、vCPU、RAM、storageは設定可能です。 +TiFlashは、カラム型データの保存を担当します。TiFlashはTiKVからリアルタイムでデータを同期し、リアルタイム分析ワークロードをすぐにサポートします。TiFlashのノード数、vCPU、RAM、ストレージは設定可能です。 -TiDB Cloudは、リージョン内の異なるアベイラビリティゾーンにTiFlashノードを均等に配置します。本番環境での高可用性を確保するため、各TiDB Cloud Dedicatedクラスタに少なくとも2つのTiFlashノードを設定し、データのレプリカを少なくとも2つ作成することをお勧めします。 +TiDB Cloudは、リージョン内の異なるアベイラビリティゾーンにTiFlashノードを均等に配置します。本番環境での高可用性を確保するため、各TiDB Cloud Dedicatedクラスターに少なくとも2つのTiFlashノードを設定し、データのレプリカを少なくとも2つ作成することをお勧めします。 diff --git a/tidb-cloud/scale-tidb-cluster.md b/tidb-cloud/scale-tidb-cluster.md index e995cef3d920a..fe66424bc9e86 100644 --- a/tidb-cloud/scale-tidb-cluster.md +++ b/tidb-cloud/scale-tidb-cluster.md @@ -3,7 +3,7 @@ title: Scale Your TiDB Cluster summary: TiDB Cloudクラスターを拡張する方法を学びます。 --- -# TiDBクラスタのスケール {#scale-your-tidb-cluster} +# TiDBクラスターのスケール {#scale-your-tidb-cluster} > **注記：** > @@ -32,7 +32,7 @@ TiDB、TiKV、またはTiFlashノードの数を増減できます。 > **警告：** > -> TiKV またはTiFlashノード数を減らすとリスクが生じ、残りのノードでstorage容量不足、過剰な CPU 使用率、または過剰なメモリ使用率が発生する可能性があります。 +> TiKV またはTiFlashノード数を減らすとリスクが生じ、残りのノードでストレージ容量不足、過剰な CPU 使用率、または過剰なメモリ使用率が発生する可能性があります。 TiDB、TiKV、またはTiFlashノードの数を変更するには、次の手順を実行します。 @@ -44,9 +44,9 @@ TiDB、TiKV、またはTiFlashノードの数を変更するには、次の手 > > または、 **[クラスター]**ページでスケーリングするクラスターの名前をクリックし、右上隅の**[...]**をクリックすることもできます。 -3. ドロップダウンメニューの**「変更」を**クリックします。「**クラスタの変更」**ページが表示されます。 +3. ドロップダウンメニューの**「変更」を**クリックします。「**クラスターの変更」**ページが表示されます。 -4. **[クラスタの変更]**ページで、TiDB、TiKV、またはTiFlashノードの数を変更します。 +4. **[クラスターの変更]**ページで、TiDB、TiKV、またはTiFlashノードの数を変更します。 5. 右側のペインでクラスター サイズを確認し、 **[確認]**をクリックします。 @@ -63,7 +63,7 @@ TiDB、TiKV、またはTiFlashノードの vCPU と RAM を増減できます。 > - Google Cloud でホストされ、2023/04/26 以降に作成されています。 > - Azure でホストされます。 > - AWS では、vCPU と RAM の変更にクールダウン期間があります。TiDB クラスターが AWS でホストされている場合、TiKV またはTiFlashの vCPU と RAM を変更した後、再度変更するには少なくとも 6 時間待つ必要があります。 -> - vCPUを減らす前に、TiKVまたはTiFlashの現在のノードstorageが、対象のvCPUの最大ノードstorageを超えていないことを確認してください。詳細は[TiKVノードstorage](/tidb-cloud/size-your-cluster.md#tikv-node-storage-size)と[TiFlashノードstorage](/tidb-cloud/size-your-cluster.md#tiflash-node-storage)参照してください。いずれかのコンポーネントの現在のstorageが上限を超えている場合は、vCPUを減らすことはできません。 +> - vCPUを減らす前に、TiKVまたはTiFlashの現在のノードストレージが、対象のvCPUの最大ノードストレージを超えていないことを確認してください。詳細は[TiKVノードストレージ](/tidb-cloud/size-your-cluster.md#tikv-node-ストレージ-size)と[TiFlashノードストレージ](/tidb-cloud/size-your-cluster.md#tiflash-node-ストレージ)参照してください。いずれかのコンポーネントの現在のストレージが上限を超えている場合は、vCPUを減らすことはできません。 TiDB、TiKV、またはTiFlashノードの vCPU と RAM を変更するには、次の手順を実行します。 @@ -75,24 +75,24 @@ TiDB、TiKV、またはTiFlashノードの vCPU と RAM を変更するには、 > > または、 **[クラスター]**ページでスケーリングするクラスターの名前をクリックし、右上隅の**[...]**をクリックすることもできます。 -3. ドロップダウンメニューの**「変更」を**クリックします。「**クラスタの変更」**ページが表示されます。 +3. ドロップダウンメニューの**「変更」を**クリックします。「**クラスターの変更」**ページが表示されます。 -4. **[クラスタの変更]**ページで、TiDB、TiKV、またはTiFlashノードの vCPU と RAM を変更します。 +4. **[クラスターの変更]**ページで、TiDB、TiKV、またはTiFlashノードの vCPU と RAM を変更します。 5. 右側のペインでクラスター サイズを確認し、 **[確認]**をクリックします。 TiDB Cloud APIを使用して、 [TiDB Cloud Dedicated クラスターを変更する](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster)エンドポイント経由でTiDB、TiKV、またはTiFlashノードのvCPUとRAMを変更することもできます。現在、 TiDB Cloud APIはまだベータ版です。詳細については、 [TiDB CloudAPI ドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)ご覧ください。 -## storageの変更 {#change-storage} +## ストレージの変更 {#change-ストレージ} -TiKV またはTiFlashのstorageを増やすことができます。 +TiKV またはTiFlashのストレージを増やすことができます。 > **警告：** > -> - 実行中のクラスターの場合、AWS、Azure、Google Cloud では、インプレースstorage容量のダウングレードは許可されません。 -> - AWS と Azure では、storage変更のクールダウン期間があります。TiDB クラスターが AWS または Azure でホストされている場合、TiKV またはTiFlashのstorage、または vCPU と RAM を変更した後、再度変更するには少なくとも 6 時間待つ必要があります。 +> - 実行中のクラスターの場合、AWS、Azure、Google Cloud では、インプレースストレージ容量のダウングレードは許可されません。 +> - AWS と Azure では、ストレージ変更のクールダウン期間があります。TiDB クラスターが AWS または Azure でホストされている場合、TiKV またはTiFlashのストレージ、または vCPU と RAM を変更した後、再度変更するには少なくとも 6 時間待つ必要があります。 -TiKV またはTiFlashのstorageを変更するには、次の手順を実行します。 +TiKV またはTiFlashのストレージを変更するには、次の手順を実行します。 1. TiDB Cloudコンソールで、プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動します。 @@ -102,10 +102,10 @@ TiKV またはTiFlashのstorageを変更するには、次の手順を実行し > > または、 **[クラスター]**ページでスケーリングするクラスターの名前をクリックし、右上隅の**[...]**をクリックすることもできます。 -3. ドロップダウンメニューの**「変更」を**クリックします。「**クラスタの変更」**ページが表示されます。 +3. ドロップダウンメニューの**「変更」を**クリックします。「**クラスターの変更」**ページが表示されます。 -4. **「クラスタの変更」**ページで、各 TiKV またはTiFlashノードのstorageを変更します。 +4. **「クラスターの変更」**ページで、各 TiKV またはTiFlashノードのストレージを変更します。 5. 右側のペインでクラスター サイズを確認し、 **[確認]**をクリックします。 -TiDB Cloud APIを使用して、 [TiDB Cloud Dedicated クラスターを変更する](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster)エンドポイント経由でTiKVノードまたはTiFlashノードのstorageを変更することもできます。現在、 TiDB Cloud APIはまだベータ版です。詳細については、 [TiDB CloudAPI ドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)ご覧ください。 +TiDB Cloud APIを使用して、 [TiDB Cloud Dedicated クラスターを変更する](https://docs.pingcap.com/tidbcloud/api/v1beta#tag/Cluster/operation/UpdateCluster)エンドポイント経由でTiKVノードまたはTiFlashノードのストレージを変更することもできます。現在、 TiDB Cloud APIはまだベータ版です。詳細については、 [TiDB CloudAPI ドキュメント](https://docs.pingcap.com/tidbcloud/api/v1beta)ご覧ください。 diff --git a/tidb-cloud/secure-connections-to-serverless-clusters.md b/tidb-cloud/secure-connections-to-serverless-clusters.md index 9caaf51afa958..cede61a1add73 100644 --- a/tidb-cloud/secure-connections-to-serverless-clusters.md +++ b/tidb-cloud/secure-connections-to-serverless-clusters.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidbcloud/secure-connections-to-serverless-tier-clusters'] # TiDB Cloud Starter または Essential への TLS 接続 {#tls-connections-to-tidb-cloud-starter-or-essential} -クライアントとTiDB Cloud StarterまたはTiDB Cloud Essentialクラスタ間の安全なTLS接続を確立することは、データベース接続における基本的なセキュリティ対策の一つです。TiDB Cloudのサーバー証明書は、独立したサードパーティの証明書プロバイダによって発行されます。サーバー側のデジタル証明書をダウンロードすることなく、 TiDB Cloudクラスタに簡単に接続できます。 +クライアントとTiDB Cloud StarterまたはTiDB Cloud Essentialクラスター間の安全なTLS接続を確立することは、データベース接続における基本的なセキュリティ対策の一つです。TiDB Cloudのサーバー証明書は、独立したサードパーティの証明書プロバイダによって発行されます。サーバー側のデジタル証明書をダウンロードすることなく、 TiDB Cloudクラスターに簡単に接続できます。 > **注記：** > @@ -45,15 +45,15 @@ aliases: ['/ja/tidbcloud/secure-connections-to-serverless-tier-clusters'] ### ルート証明書の発行と有効性 {#root-certificate-issuance-and-validity} -TiDB Cloudは、クライアントとTiDB Cloudクラスタ間のTLS接続において、 [レッツ・エンクリプト](https://letsencrypt.org/)の証明書を証明機関（CA）として使用します。TiDB Cloud証明書の有効期限が切れると、クラスタの通常の動作や確立されたTLSセキュア接続に影響を与えることなく、自動的にローテーションされます。 +TiDB Cloudは、クライアントとTiDB Cloudクラスター間のTLS接続において、 [レッツ・エンクリプト](https://letsencrypt.org/)の証明書を証明機関（CA）として使用します。TiDB Cloud証明書の有効期限が切れると、クラスターの通常の動作や確立されたTLSセキュア接続に影響を与えることなく、自動的にローテーションされます。 -JavaやGoなど、クライアントがシステムのルートCAストアをデフォルトで使用する場合、CAルートのパスを指定せずにTiDB Cloudクラスタに安全に接続できます。ただし、一部のドライバやORMはシステムルートCAストアを使用しません。そのような場合は、ドライバやORMのCAルートパスをシステムルートCAストアに設定する必要があります。例えば、macOS上のPythonで[mysqlクライアント](https://github.com/PyMySQL/mysqlclient)使用してTiDB Cloudクラスタに接続する場合、引数`ssl`に`ca: /etc/ssl/cert.pem`設定する必要があります。 +JavaやGoなど、クライアントがシステムのルートCAストアをデフォルトで使用する場合、CAルートのパスを指定せずにTiDB Cloudクラスターに安全に接続できます。ただし、一部のドライバやORMはシステムルートCAストアを使用しません。そのような場合は、ドライバやORMのCAルートパスをシステムルートCAストアに設定する必要があります。例えば、macOS上のPythonで[mysqlクライアント](https://github.com/PyMySQL/mysqlclient)使用してTiDB Cloudクラスターに接続する場合、引数`ssl`に`ca: /etc/ssl/cert.pem`設定する必要があります。 複数の証明書が含まれる証明書ファイルを受け入れない DBeaver などの GUI クライアントを使用している場合は、 [ISRGルートX1](https://letsencrypt.org/certs/isrgrootx1.pem)証明書をダウンロードする必要があります。 ### ルート証明書のデフォルトパス {#root-certificate-default-path} -異なるオペレーティング システムにおけるルート証明書のデフォルトのstorageパスは次のとおりです。 +異なるオペレーティング システムにおけるルート証明書のデフォルトのストレージパスは次のとおりです。 **macOS** diff --git a/tidb-cloud/security-concepts.md b/tidb-cloud/security-concepts.md index 3232fae8dd1b5..cfe302c188051 100644 --- a/tidb-cloud/security-concepts.md +++ b/tidb-cloud/security-concepts.md @@ -121,13 +121,13 @@ TiDB Cloudは、組織、プロジェクト、リソースという階層構造 - TiDB Cloudには、3種類のプロジェクトがあります。 - - **TiDB Dedicatedプロジェクト**： TiDB Cloud Dedicatedクラスタ専用のプロジェクトタイプです。Dedicatedプロジェクトは、ネットワーク、メンテナンス、アラート購読、統合、暗号化関連のアクセスなど、プロジェクトスコープの設定を管理します。 + - **TiDB Dedicatedプロジェクト**： TiDB Cloud Dedicatedクラスター専用のプロジェクトタイプです。Dedicatedプロジェクトは、ネットワーク、メンテナンス、アラート購読、統合、暗号化関連のアクセスなど、プロジェクトスコープの設定を管理します。 - **TiDB Xプロジェクト**：TiDB Xインスタンス（ TiDB Cloud Starter、 Essential、Premiumインスタンスを含む）の論理コンテナです。TiDB Xプロジェクトは、リソースのグループ化やプロジェクトレベルのRBACの適用に使用されますが、専用環境専用のインフラストラクチャ設定は保持しません。 - **TiDB X仮想プロジェクト**：どのTiDB Xプロジェクトにもグループ化されていないTiDB Xインスタンス用の仮想プロジェクトです。このプロジェクトタイプはAPI互換性のためだけに使用され、管理機能は提供されません。 **リソース** -- TiDB Cloudリソースは、TiDB X インスタンス ( [TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md)上に構築されたサービス指向のTiDB Cloudオファリング) またはTiDB Cloud Dedicatedクラスタのいずれかになります。 +- TiDB Cloudリソースは、TiDB X インスタンス ( [TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md)上に構築されたサービス指向のTiDB Cloudオファリング) またはTiDB Cloud Dedicatedクラスターのいずれかになります。 ### 例となる構造 {#example-structure} @@ -148,7 +148,7 @@ TiDB Cloudは、組織、プロジェクト、リソースという階層構造 - **詳細な権限設定**： - 組織、プロジェクト、インスタンスの各レベルで特定の役割を割り当てることで、正確なアクセス制御を実現します。 - - TiDB Xインスタンスにはプロジェクトロールまたはインスタンスロールのいずれかを通じてアクセスできますが、 TiDB Cloud Dedicatedクラスタはプロジェクトレベルのアクセスによって管理されます。 + - TiDB Xインスタンスにはプロジェクトロールまたはインスタンスロールのいずれかを通じてアクセスできますが、 TiDB Cloud Dedicatedクラスターはプロジェクトレベルのアクセスによって管理されます。 - **柔軟なプロジェクトモデル**： - TiDB Xプロジェクトはオプションなので、TiDB Xインスタンスはプロジェクトにグループ化することも、組織レベルで管理することもできます。 @@ -213,7 +213,7 @@ TiDB Cloudは、堅牢なネットワークアクセス制御により、安全 ### IPアクセスリスト {#ip-access-list} -- ファイアウォールとして機能し、クラスタへのアクセスを信頼できるIPアドレスに制限します。 +- ファイアウォールとして機能し、クラスターへのアクセスを信頼できるIPアドレスに制限します。 - 詳細については、 [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)参照してください。 @@ -231,7 +231,7 @@ TiDB Cloudは、高度な暗号化機能で静的データを保護し、セキ - 有効にすると、静的データとバックアップをCMEKキーで暗号化します。 -- CMEKを使用しないTiDB Cloud Dedicatedクラスタの場合、 TiDB Cloudはエスクローキーを使用します。TiDB Cloud StarterおよびTiDB Cloud Essentialインスタンスは、エスクローキーのみに依存します。 +- CMEKを使用しないTiDB Cloud Dedicatedクラスターの場合、 TiDB Cloudはエスクローキーを使用します。TiDB Cloud StarterおよびTiDB Cloud Essentialインスタンスは、エスクローキーのみに依存します。 **ベストプラクティス：** diff --git a/tidb-cloud/security-overview.md b/tidb-cloud/security-overview.md index 34652f4aaf5ca..2daf35a45910a 100644 --- a/tidb-cloud/security-overview.md +++ b/tidb-cloud/security-overview.md @@ -23,7 +23,7 @@ TLSを使用してすべての通信を暗号化することで、転送中の -顧客管理暗号化キー（CMEK）が有効になっているTiDB Cloud Dedicatedクラスタの場合、 TiDB Cloudは保存データとバックアップの両方に対して暗号化を提供します。 +顧客管理暗号化キー（CMEK）が有効になっているTiDB Cloud Dedicatedクラスターの場合、 TiDB Cloudは保存データとバックアップの両方に対して暗号化を提供します。 堅牢な鍵管理メカニズムと組み合わせることで、暗号化鍵のライフサイクルと使用状況を制御でき、データセキュリティとコンプライアンスをさらに強化できます。 diff --git a/tidb-cloud/select-cluster-tier.md b/tidb-cloud/select-cluster-tier.md index 7eb14dfa2eebd..4f7d616dcdcb3 100644 --- a/tidb-cloud/select-cluster-tier.md +++ b/tidb-cloud/select-cluster-tier.md @@ -26,7 +26,7 @@ TiDB Cloud Starterは、フルマネージド型のマルチテナント対応Ti 無料プランは、 TiDB Cloud Starter を初めて利用する方に最適です。開発者や小規模チーム向けに、以下の必須機能を提供します。 - **無料**：このプランは完全に無料で、利用開始にクレジットカードは必要ありません。 -- **ストレージ**：初期容量として、行ベースのstorageが5 GiB、列ベースのstorageが5 GiB提供されます。 +- **ストレージ**：初期容量として、行ベースのストレージが5 GiB、列ベースのストレージが5 GiB提供されます。 - **要求単位**: データベース操作の 5,000 万[要求単位（RU）](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru)が含まれます。 ### 使用クォータ {#usage-quota} @@ -35,13 +35,13 @@ TiDB Cloudでは、組織ごとにデフォルトで最大5つのTiDB Cloud Star 組織内の最初の 5 つのTiDB Cloud Starterインスタンス（無料版かスケーラブル版かを問わず）については、 TiDB Cloud はそれぞれに以下の無料使用クォ​​ータを提供します。 -- 行ベースstorage：5 GiB -- カラム型storage：5 GiB +- 行ベースストレージ：5 GiB +- カラム型ストレージ：5 GiB - 要求単位（RU）：月間5,000万RU リクエストユニット（RU）とは、データベースへの単一のリクエストによって消費されるリソース量を表す単位です。リクエストによって消費されるRUの量は、操作の種類や取得または変更されるデータの量など、さまざまな要因によって異なります。 -TiDB Cloud Starterインスタンスが使用クォータに達すると、ユーザーが または新しい月の開始時に使用がリセットさ[割り当てを増やす](/tidb-cloud/manage-serverless-spend-limit.md#update-spending-limit)まで、新しい接続試行は即座に拒否されます。クォータに達する前に確立された既存の接続はアクティブなままですが、スロットリングが発生します。たとえば、無料のTiDB Cloud Starter TiDB Cloud Starterインスタンスの行ベースのstorageが5 GiB を超えると、インスタンスは自動的に新しい接続試行を制限します。 +TiDB Cloud Starterインスタンスが使用クォータに達すると、ユーザーが または新しい月の開始時に使用がリセットさ[割り当てを増やす](/tidb-cloud/manage-serverless-spend-limit.md#update-spending-limit)まで、新しい接続試行は即座に拒否されます。クォータに達する前に確立された既存の接続はアクティブなままですが、スロットリングが発生します。たとえば、無料のTiDB Cloud Starter TiDB Cloud Starterインスタンスの行ベースのストレージが5 GiB を超えると、インスタンスは自動的に新しい接続試行を制限します。 さまざまなリソース（読み取り、書き込み、SQL CPU、ネットワーク出力など）のRU消費量、価格の詳細、およびスロットリング情報の詳細については、 [TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)参照してください。 @@ -50,9 +50,9 @@ TiDB Cloud Starterインスタンスが使用クォータに達すると、ユ ワークロードが増加し、リアルタイムでの拡張性を必要とするアプリケーション向けに、 Essentialプランは以下の機能を備え、ビジネスの成長に合わせて柔軟かつ高性能なソリューションを提供します。 - **機能強化**：Starterプランのすべての機能に加え、より大規模で複雑なワークロードを処理できる能力、および高度なセキュリティ機能が含まれています。 -- **自動スケーリング**：変化するワークロードの需要に効率的に対応するために、storageとコンピューティングリソースを自動的に調整します。 +- **自動スケーリング**：変化するワークロードの需要に効率的に対応するために、ストレージとコンピューティングリソースを自動的に調整します。 - **高可用性**：組み込みの耐障害性と冗長性により、インフラストラクチャの障害発生時でも、アプリケーションの可用性と回復力が維持されます。 -- **予測可能な料金体系**：コンピューティングリソースのstorageとリクエストキャパシティユニット（RCU）に基づいて課金されるため、ニーズに合わせて拡張可能な透明性の高い使用量ベースの料金体系が提供され、予期せぬ追加料金なしで使用した分だけを支払うことができます。 +- **予測可能な料金体系**：コンピューティングリソースのストレージとリクエストキャパシティユニット（RCU）に基づいて課金されるため、ニーズに合わせて拡張可能な透明性の高い使用量ベースの料金体系が提供され、予期せぬ追加料金なしで使用した分だけを支払うことができます。 ## ユーザー名の接頭辞 {#user-name-prefix} @@ -89,9 +89,9 @@ TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスのプレフィ 大規模な容量と一貫した高いパフォーマンスを必要とするミッションクリティカルなエンタープライズワークロード向けに、プレミアムプランは以下の機能を備えたクラウドネイティブなエクスペリエンスを提供します。 - **即時的な拡張性**：トラフィックの急増に対応し、ピーク需要時にも安定したパフォーマンスを維持するために、コンピューティングリソースを自動的に拡張します。 -- **無制限の拡張性**：物理的なインフラストラクチャの制約を受けることなく、ビジネスの成長に合わせてstorageとスループットを拡張できます。 +- **無制限の拡張性**：物理的なインフラストラクチャの制約を受けることなく、ビジネスの成長に合わせてストレージとスループットを拡張できます。 - **ゼロインフラストラクチャ管理**：手動によるスケーリング、パッチ適用、キャパシティプランニングを排除する、完全マネージドサービスを提供します。 -- **予測可能な料金体系**：storageとリクエスト容量ユニット（RCU）に基づいて課金されるため、ニーズに合わせて拡張可能な透明性の高い使用量ベースの料金体系が実現し、予期せぬ追加料金なしで使用した分だけを支払うことができます。 +- **予測可能な料金体系**：ストレージとリクエスト容量ユニット（RCU）に基づいて課金されるため、ニーズに合わせて拡張可能な透明性の高い使用量ベースの料金体系が実現し、予期せぬ追加料金なしで使用した分だけを支払うことができます。 - **高度なセキュリティとコンプライアンス**：高度な暗号化、顧客管理型暗号化キー（CMEK）、プライベートネットワーク、およびコンプライアンス認証をサポートし、機密データを保護します。 ## TiDB Cloud Dedicated {#tidb-cloud-dedicated} @@ -104,4 +104,4 @@ TiDB Cloud Dedicatedクラスターを作成するには、 [支払い方法を > **注記：** > -> TiDB Cloud Dedicatedクラスタの作成後は、ノードのstorageを減らすことはできません。 +> TiDB Cloud Dedicatedクラスターの作成後は、ノードのストレージを減らすことはできません。 diff --git a/tidb-cloud/serverless-export.md b/tidb-cloud/serverless-export.md index fa923276beeed..60354c30c0fed 100644 --- a/tidb-cloud/serverless-export.md +++ b/tidb-cloud/serverless-export.md @@ -5,7 +5,7 @@ summary: TiDB Cloud Starter またはTiDB Cloud Essential クラスターから # TiDB Cloud StarterまたはEssentialからデータをエクスポートする {#export-data-from-tidb-cloud-starter-or-essential} -TiDB Cloudを使用すると、 TiDB Cloud StarterまたはEssentialクラスターからローカルファイルまたは外部storageサービスにデータをエクスポートできます。エクスポートしたデータは、バックアップ、移行、データ分析などの用途に使用できます。 +TiDB Cloudを使用すると、 TiDB Cloud StarterまたはEssentialクラスターからローカルファイルまたは外部ストレージサービスにデータをエクスポートできます。エクスポートしたデータは、バックアップ、移行、データ分析などの用途に使用できます。 [mysqldump](https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html)や TiDB [Dumpling](https://docs.pingcap.com/tidb/dev/dumpling-overview)などのツールを使用してデータをエクスポートすることもできますが、 TiDB Cloudが提供するエクスポート機能は、クラスターからデータをエクスポートするためのより便利で効率的な方法を提供します。これには、次のような利点があります。 @@ -22,16 +22,16 @@ TiDB Cloudを使用すると、 TiDB Cloud StarterまたはEssentialクラスタ 次の場所にデータをエクスポートできます。 - ローカルファイル -- 外部storage、以下を含む: +- 外部ストレージ、以下を含む: - [アマゾンS3](https://aws.amazon.com/s3/) - - [Googleクラウドストレージ](https://cloud.google.com/storage) - - [Azure BLOB ストレージ](https://azure.microsoft.com/en-us/services/storage/blobs/) + - [Googleクラウドストレージ](https://cloud.google.com/ストレージ) + - [Azure BLOB ストレージ](https://azure.microsoft.com/en-us/services/ストレージ/blobs/) - [Alibaba Cloud オブジェクト ストレージ サービス (OSS)](https://www.alibabacloud.com/product/oss) > **注記：** > -> エクスポートするデータのサイズが大きい場合（100 GiB 以上）は、外部storageにエクスポートすることをお勧めします。 +> エクスポートするデータのサイズが大きい場合（100 GiB 以上）は、外部ストレージにエクスポートすることをお勧めします。 ### ローカルファイル {#a-local-file} @@ -41,7 +41,7 @@ TiDB Cloudクラスターからローカル ファイルにデータをエクス - TiDB Cloudコンソールを使用してエクスポートされたデータをダウンロードすることはサポートされていません。 - エクスポートされたデータはTiDB Cloudのスタッシングエリアに保存され、2日後に有効期限が切れます。エクスポートしたデータは期限内にダウンロードする必要があります。 -- スタッシング領域のstorageスペースがいっぱいの場合、データをローカル ファイルにエクスポートすることはできません。 +- スタッシング領域のストレージスペースがいっぱいの場合、データをローカル ファイルにエクスポートすることはできません。 ### アマゾンS3 {#amazon-s3} @@ -52,25 +52,25 @@ Amazon S3 にデータをエクスポートするには、次の情報を提供 - [アクセスキー](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html) : アクセス キーに`s3:PutObject`と`s3:ListBucket`権限があることを確認します。 - [ロールARN](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) : ロールARN（Amazonリソースネーム）に`s3:PutObject`と`s3:ListBucket`権限があることを確認してください。このロールARNはAWSでホストされているクラスターでのみサポートされることに注意してください。 -詳細については[Amazon S3 アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)参照してください。 +詳細については[Amazon S3 アクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-amazon-s3-access)参照してください。 -### Googleクラウドストレージ {#google-cloud-storage} +### Googleクラウドストレージ {#google-cloud-ストレージ} Google Cloud Storage にデータをエクスポートするには、次の情報を提供する必要があります。 - URI: `gs:////` -- アクセス認証情報: バケットの**Base64エンコードされた**[サービスアカウントキー](https://cloud.google.com/iam/docs/creating-managing-service-account-keys) 。サービスアカウントキーに`storage.objects.create`権限があることを確認してください。 +- アクセス認証情報: バケットの**Base64エンコードされた**[サービスアカウントキー](https://cloud.google.com/iam/docs/creating-managing-service-account-keys) 。サービスアカウントキーに`ストレージ.objects.create`権限があることを確認してください。 -詳細については[GCS アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-gcs-access)参照してください。 +詳細については[GCS アクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-gcs-access)参照してください。 -### Azure BLOB ストレージ {#azure-blob-storage} +### Azure BLOB ストレージ {#azure-blob-ストレージ} Azure Blob Storage にデータをエクスポートするには、次の情報を提供する必要があります。 - URI: `azure://.blob.core.windows.net///`または`https://.blob.core.windows.net///` -- アクセス資格情報: Azure Blob Storage コンテナーの[共有アクセス署名（SAS）トークン](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview) 。SAS トークンに、 `Container`と`Object`リソースに対する`Read`と`Write`権限があることを確認してください。 +- アクセス資格情報: Azure Blob Storage コンテナーの[共有アクセス署名（SAS）トークン](https://docs.microsoft.com/en-us/azure/ストレージ/common/ストレージ-sas-overview) 。SAS トークンに、 `Container`と`Object`リソースに対する`Read`と`Write`権限があることを確認してください。 -詳細については[Azure Blob Storage アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access)参照してください。 +詳細については[Azure Blob Storage アクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-azure-blob-ストレージ-access)参照してください。 ### アリババクラウドOSS {#alibaba-cloud-oss} @@ -79,7 +79,7 @@ Alibaba Cloud OSS にデータをエクスポートするには、次の情報 - URI: `oss:////` - アクセス資格情報：Alibaba Cloudアカウントの[アクセスキーペア](https://www.alibabacloud.com/help/en/ram/user-guide/create-an-accesskey-pair)ペアに`oss:PutObject`と`oss:GetBucketInfo`権限があることを確認してください。 -詳細については[Alibaba Cloud Object Storage Service (OSS) アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-alibaba-cloud-object-storage-service-oss-access)参照してください。 +詳細については[Alibaba Cloud Object Storage Service (OSS) アクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-alibaba-cloud-object-ストレージ-service-oss-access)参照してください。 ## エクスポートオプション {#export-options} @@ -245,7 +245,7 @@ Alibaba Cloud OSS にデータをエクスポートするには、次の情報 - **圧縮**: **Gzip** 、 **Snappy** 、 **Zstd** 、または**None**を選択します。 - **フォルダー URI** : `s3:////`形式で Amazon S3 の URI を入力します。 - **バケット アクセス**: 次のアクセス資格情報のいずれかを選択し、資格情報を入力します。 - - **AWS ロール ARN** : バケットへのアクセス権を持つロール ARN を入力します。AWS CloudFormation を使用してロール ARN を作成することをお勧めします。詳細については、 [Amazon S3 アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-amazon-s3-access)参照してください。 + - **AWS ロール ARN** : バケットへのアクセス権を持つロール ARN を入力します。AWS CloudFormation を使用してロール ARN を作成することをお勧めします。詳細については、 [Amazon S3 アクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-amazon-s3-access)参照してください。 - **AWS アクセスキー**: バケットにアクセスする権限を持つアクセスキー ID とアクセスキーシークレットを入力します。 4. **［エクスポート］**をクリックします。 @@ -268,7 +268,7 @@ ticloud serverless export create -c --target-type S3 --s3.uri
    -### Google Cloud Storage にデータをエクスポートする {#export-data-to-google-cloud-storage} +### Google Cloud Storage にデータをエクスポートする {#export-data-to-google-cloud-ストレージ}
    @@ -306,7 +306,7 @@ ticloud serverless export create -c --target-type GCS --gcs.uri -### Azure Blob Storage にデータをエクスポートする {#export-data-to-azure-blob-storage} +### Azure Blob Storage にデータをエクスポートする {#export-data-to-azure-blob-ストレージ}
    @@ -326,7 +326,7 @@ ticloud serverless export create -c --target-type GCS --gcs.uri .blob.core.windows.net///`形式で Azure Blob Storage の URI を入力します。 - - **SASトークン**: コンテナへのアクセス権を持つSASトークンを入力します。2でSASトークンを作成することをお勧めします。詳細については、 [Azure Blob Storage アクセスを構成する](/tidb-cloud/configure-external-storage-access.md#configure-azure-blob-storage-access) [Azure ARM テンプレート](https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/)してください。 + - **SASトークン**: コンテナへのアクセス権を持つSASトークンを入力します。2でSASトークンを作成することをお勧めします。詳細については、 [Azure Blob Storage アクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md#configure-azure-blob-ストレージ-access) [Azure ARM テンプレート](https://learn.microsoft.com/en-us/azure/azure-resource-manager/templates/)してください。 4. **［エクスポート］**をクリックします。 diff --git a/tidb-cloud/serverless-faqs.md b/tidb-cloud/serverless-faqs.md index 3e76ceaec90ce..914959a8ffed9 100644 --- a/tidb-cloud/serverless-faqs.md +++ b/tidb-cloud/serverless-faqs.md @@ -26,7 +26,7 @@ Starter に名前が変更される前、 TiDB Cloudの Serverless 層は何千 このエントリー層の目的をより明確にするため、 TiDB Cloudを使った構築を最も早く開始できる「Starter」に名称を変更しました。Serverless層に関するこれまでの内容はそのままです。 -- 行ベースと列ベースの両方のstorageを備えた完全に管理されたデータベースで、ハイブリッド OLTP および OLAP ワークロードに最適です。 +- 行ベースと列ベースの両方のストレージを備えた完全に管理されたデータベースで、ハイブリッド OLTP および OLAP ワークロードに最適です。 - 自動かつリクエスト主導型のスケーリング。容量計画や手動の調整は必要ありません。 - ベクター検索とフルテキスト検索が組み込まれており、GenAI 検索、チャットボット、その他の AI アプリケーションを強化します。 - 組織ごとに最大 5 つのクラスターまで、月間クォータが常時無料です (5 GiB の行データ + 5 GiB の列データ + クラスターあたり 5,000 万[RU](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) )。 @@ -51,32 +51,32 @@ TiDB Cloud StarterをGoogle CloudやAzureを含む他のクラウドプラット はい、 Developer TierクラスターはTiDB Cloud Starter クラスターに自動的に移行されており、以前の使用状況に支障をきたすことなく、ユーザー エクスペリエンスが向上します。 -### TiDB Cloud Starter の列指向storageとは何ですか? {#what-is-columnar-storage-in-tidb-cloud-starter} +### TiDB Cloud Starter の列指向ストレージとは何ですか? {#what-is-columnar-ストレージ-in-tidb-cloud-starter} -TiDB Cloud Starterの列指向storageは、行ベースstorageの追加レプリカとして機能し、強力な一貫性を確保します。従来の行ベースstorageはデータを行単位で保存しますが、列指向storageはデータを列単位で整理し、データ分析タスクに最適化します。 +TiDB Cloud Starterの列指向ストレージは、行ベースストレージの追加レプリカとして機能し、強力な一貫性を確保します。従来の行ベースストレージはデータを行単位で保存しますが、列指向ストレージはデータを列単位で整理し、データ分析タスクに最適化します。 -列指向storageは、トランザクション ワークロードと分析ワークロードをシームレスに融合することで、TiDB のハイブリッド トランザクションおよび分析処理 (HTAP) 機能を有効にする重要な機能です。 +列指向ストレージは、トランザクション ワークロードと分析ワークロードをシームレスに融合することで、TiDB のハイブリッド トランザクションおよび分析処理 (HTAP) 機能を有効にする重要な機能です。 -列指向storageデータを効率的に管理するために、 TiDB Cloud Starterは独立したElastic TiFlashエンジンを使用します。クエリ実行中、オプティマイザーはクラスターに対し、行ベースストレージと列指向storageのどちらからデータを取得するかを自動的に決定するよう指示します。 +列指向ストレージデータを効率的に管理するために、 TiDB Cloud Starterは独立したElastic TiFlashエンジンを使用します。クエリ実行中、オプティマイザーはクラスターに対し、行ベースストレージと列指向ストレージのどちらからデータを取得するかを自動的に決定するよう指示します。 -### TiDB Cloud Starter で列指向storageを使用するのはいつですか? {#when-should-i-use-columnar-storage-in-tidb-cloud-starter} +### TiDB Cloud Starter で列指向ストレージを使用するのはいつですか? {#when-should-i-use-columnar-ストレージ-in-tidb-cloud-starter} -次のシナリオでは、 TiDB Cloud Starter の列指向storageの使用を検討してください。 +次のシナリオでは、 TiDB Cloud Starter の列指向ストレージの使用を検討してください。 - ワークロードには、効率的なデータスキャンと集約を必要とする分析タスクが含まれます。 - 特に分析ワークロードのパフォーマンス向上を優先します。 -- トランザクション処理（TP）ワークロードへのパフォーマンスへの影響を防ぐため、分析処理とトランザクション処理を分離する必要があります。独立した列指向storageは、これらの異なるワークロードパターンを最適化するのに役立ちます。 +- トランザクション処理（TP）ワークロードへのパフォーマンスへの影響を防ぐため、分析処理とトランザクション処理を分離する必要があります。独立した列指向ストレージは、これらの異なるワークロードパターンを最適化するのに役立ちます。 -このようなシナリオでは、列指向storageによりクエリのパフォーマンスが大幅に向上し、システム内の混合ワークロードに対してシームレスなエクスペリエンスを提供できます。 +このようなシナリオでは、列指向ストレージによりクエリのパフォーマンスが大幅に向上し、システム内の混合ワークロードに対してシームレスなエクスペリエンスを提供できます。 -### TiDB Cloud Starter で列指向storageを使用する方法 {#how-to-use-columnar-storage-in-tidb-cloud-starter} +### TiDB Cloud Starter で列指向ストレージを使用する方法 {#how-to-use-columnar-ストレージ-in-tidb-cloud-starter} -TiDB Cloud Starter での列指向storageの使用は、 TiFlashでの使用と同様です。列指向storageは、テーブルレベルとデータベースレベルの両方で有効にできます。 +TiDB Cloud Starter での列指向ストレージの使用は、 TiFlashでの使用と同様です。列指向ストレージは、テーブルレベルとデータベースレベルの両方で有効にできます。 -- テーブル レベル: TiFlashレプリカをテーブルに割り当てて、特定のテーブルの列指向storageを有効にします。 -- データベース レベル: データベース全体で列型storageを使用するように、データベース内のすべてのテーブルに対してTiFlashレプリカを構成します。 +- テーブル レベル: TiFlashレプリカをテーブルに割り当てて、特定のテーブルの列指向ストレージを有効にします。 +- データベース レベル: データベース全体で列型ストレージを使用するように、データベース内のすべてのテーブルに対してTiFlashレプリカを構成します。 -テーブルにTiFlashレプリカが設定されると、TiDBは行ベースstorageからそのテーブルの列指向storageにデータを自動的に複製します。これにより、データの一貫性が確保され、分析クエリのパフォーマンスが最適化されます。 +テーブルにTiFlashレプリカが設定されると、TiDBは行ベースストレージからそのテーブルの列指向ストレージにデータを自動的に複製します。これにより、データの一貫性が確保され、分析クエリのパフォーマンスが最適化されます。 TiFlashレプリカの設定方法の詳細については、 [TiFlashレプリカを作成する](/tiflash/create-tiflash-replicas.md)参照してください。 @@ -92,14 +92,14 @@ TiFlashレプリカの設定方法の詳細については、 [TiFlashレプリ ### リクエストユニットとは何ですか? {#what-are-request-units} -TiDB Cloud Starterは従量課金モデルを採用しており、storage容量とクラスターの使用量に対してのみ料金が発生します。このモデルでは、SQLクエリ、一括操作、バックグラウンドジョブなど、すべてのクラスターアクティビティが[リクエストユニット（RU）](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru)で定量化されます。RUは、クラスターで開始されたリクエストのサイズと複雑さを表す抽象的な指標です。詳細については、 [TiDB Cloud Starter の価格詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)ご覧ください。 +TiDB Cloud Starterは従量課金モデルを採用しており、ストレージ容量とクラスターの使用量に対してのみ料金が発生します。このモデルでは、SQLクエリ、一括操作、バックグラウンドジョブなど、すべてのクラスターアクティビティが[リクエストユニット（RU）](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru)で定量化されます。RUは、クラスターで開始されたリクエストのサイズと複雑さを表す抽象的な指標です。詳細については、 [TiDB Cloud Starter の価格詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)ご覧ください。 ### TiDB Cloud Starter には無料プランはありますか? {#is-there-any-free-plan-available-for-tidb-cloud-starter} 組織内の最初の 5 つのTiDB Cloud Starter クラスターについては、 TiDB Cloud は次のようにクラスターごとに無料使用量割り当てを提供します。 -- 行ベースのstorage: 5 GiB -- 列指向storage: 5 GiB +- 行ベースのストレージ: 5 GiB +- 列指向ストレージ: 5 GiB - [リクエストユニット（RU）](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) : 月間5000万RU TiDB Cloud Starter クラスターに月間使用制限が設定されている場合、無料割り当て量を超えた使用量には課金されます。無料クラスターの場合、無料割り当て量に達すると、月間使用制限を設定するか、新しい月の開始時に使用量がリセットされるまで、このクラスターの読み取りおよび書き込み操作は制限されます。 @@ -114,17 +114,17 @@ TiDB Cloud Starter クラスターに月間使用制限が設定されている 個々のSQL文のRU消費量を取得するには、SQL文[`EXPLAIN ANALYZE`](/sql-statements/sql-statement-explain-analyze.md#ru-request-unit-consumption)を使用できます。ただし、 `EXPLAIN ANALYZE`で返されるRU使用量には、出力RUは含まれていないことに注意してください。出力使用量はゲートウェイで個別に測定され、TiDBサーバーには認識されないためです。 -クラスターで使用されているRUとstorageを確認するには、クラスターの概要ページの**「今月の使用量」**ペインをご覧ください。このペインに表示される過去のリソース使用量データとリアルタイムのリソース使用量を参考に、クラスターのリソース消費量を追跡し、適切な使用制限を見積もることができます。無料割り当てで要件を満たせない場合は、追加リソースの使用制限を編集できます。詳細については、 [TiDB Cloud Starter の使用割り当て](/tidb-cloud/select-cluster-tier.md#usage-quota)ご覧ください。 +クラスターで使用されているRUとストレージを確認するには、クラスターの概要ページの**「今月の使用量」**ペインをご覧ください。このペインに表示される過去のリソース使用量データとリアルタイムのリソース使用量を参考に、クラスターのリソース消費量を追跡し、適切な使用制限を見積もることができます。無料割り当てで要件を満たせない場合は、追加リソースの使用制限を編集できます。詳細については、 [TiDB Cloud Starter の使用割り当て](/tidb-cloud/select-cluster-tier.md#usage-quota)ご覧ください。 ### 消費される RU の数を最小限に抑えるためにワークロードを最適化するにはどうすればよいでしょうか? {#how-can-i-optimize-my-workload-to-minimize-the-number-of-rus-consumed} [SQLパフォーマンスの最適化](/develop/dev-guide-optimize-sql-overview.md)のガイドラインに従って、クエリが最適なパフォーマンスを得るために注意深く最適化されていることを確認してください。 RU を最も多く消費する SQL ステートメントを特定するには、クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページに移動し、 **[SQL ステートメント]**タブを確認します。ここで、SQL 実行を観察し、**合計 RU**または**平均 RU**でソートされた上位のステートメントを表示できます。 詳細については、 [ステートメント分析](/tidb-cloud/tune-performance.md#statement-analysis)参照してください。 また、出力トラフィックの量を最小限に抑えることも、RU の消費量を削減するために重要です。 これを実現するには、クエリで必要な列と行のみを返すことをお勧めします。これにより、ネットワークの出力トラフィックが削減されます。 これは、返される列と行を慎重に選択してフィルター処理することで実現でき、それによってネットワーク使用率が最適化されます。 -### TiDB Cloud Starter のstorageはどのように計測されますか? {#how-storage-is-metered-for-tidb-cloud-starter} +### TiDB Cloud Starter のストレージはどのように計測されますか? {#how-ストレージ-is-metered-for-tidb-cloud-starter} -storageは、 TiDB Cloud Starter クラスターに保存されるデータ量（月間GiB単位）に基づいて課金されます。これは、すべてのテーブルとインデックスの合計サイズ（データ圧縮とレプリカを除く）と、その月のデータの保存時間数を掛けて算出されます。 +ストレージは、 TiDB Cloud Starter クラスターに保存されるデータ量（月間GiB単位）に基づいて課金されます。これは、すべてのテーブルとインデックスの合計サイズ（データ圧縮とレプリカを除く）と、その月のデータの保存時間数を掛けて算出されます。 -### テーブルまたはデータベースをすぐに削除した後でも、storage使用量のサイズが変更されないのはなぜですか? {#why-does-the-storage-usage-size-remain-unchanged-after-dropping-a-table-or-database-immediately} +### テーブルまたはデータベースをすぐに削除した後でも、ストレージ使用量のサイズが変更されないのはなぜですか? {#why-does-the-ストレージ-usage-size-remain-unchanged-after-dropping-a-table-or-database-immediately} これは、TiDBが削除されたテーブルとデータベースを一定期間保持するためです。この保持期間により[`FLASHBACK DATABASE`](/sql-statements/sql-statement-flashback-database.md)これらのテーブルに依存するトランザクションは中断することなく実行を継続できます。さらに、この保持期間によって[`FLASHBACK TABLE`](/sql-statements/sql-statement-flashback-table.md)機能が実現可能となり、誤って削除されたテーブルやデータベースを回復できるようになります。 @@ -144,19 +144,19 @@ TiDB の必須バックグラウンドジョブが原因で、RU 使用量が急 TiDB Cloud Starter クラスターのデータ インポート プロセス中、データが正常にインポートされた場合にのみ RU 消費が発生するため、RU 使用量が急増します。 -### TiDB Cloud Starter で列指向storageを使用する場合、どのようなコストがかかりますか? {#what-costs-are-involved-when-using-columnar-storage-in-tidb-cloud-starter} +### TiDB Cloud Starter で列指向ストレージを使用する場合、どのようなコストがかかりますか? {#what-costs-are-involved-when-using-columnar-ストレージ-in-tidb-cloud-starter} -TiDB Cloud Starter の列指向storageの料金は、行指向storageの料金とほぼ同じです。列指向storageを使用すると、データ（インデックスなし）を保存するための追加のレプリカが作成されます。行指向ストレージから列指向storageへのデータのレプリケーションには追加料金は発生しません。 +TiDB Cloud Starter の列指向ストレージの料金は、行指向ストレージの料金とほぼ同じです。列指向ストレージを使用すると、データ（インデックスなし）を保存するための追加のレプリカが作成されます。行指向ストレージから列指向ストレージへのデータのレプリケーションには追加料金は発生しません。 詳細な価格情報については、 [TiDB Cloud Starterの価格詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)参照してください。 -### 列指向storageを使用するとコストは高くなりますか? {#is-using-columnar-storage-more-expensive} +### 列指向ストレージを使用するとコストは高くなりますか? {#is-using-columnar-ストレージ-more-expensive} -TiDB Cloud Starterの列指向storageは、追加のレプリカが必要となり、データレプリケーションに必要なstorageとリソースが増えるため、追加コストが発生します。ただし、分析クエリを実行する際には、列指向storageがコスト効率が高くなります。 +TiDB Cloud Starterの列指向ストレージは、追加のレプリカが必要となり、データレプリケーションに必要なストレージとリソースが増えるため、追加コストが発生します。ただし、分析クエリを実行する際には、列指向ストレージがコスト効率が高くなります。 -TPC-H ベンチマーク テストによると、列ベースのstorageで分析クエリを実行するコストは、行ベースのstorageを使用する場合のコストの約 3 分の 1 になります。 +TPC-H ベンチマーク テストによると、列ベースのストレージで分析クエリを実行するコストは、行ベースのストレージを使用する場合のコストの約 3 分の 1 になります。 -したがって、追加のレプリカによる初期コストは発生する可能性がありますが、分析時の計算コストが削減されるため、特定のユースケースではより費用対効果の高いものになる可能性があります。特に分析ニーズが高いユーザーにとって、列指向storageはコストを大幅に削減し、大幅なコスト削減の機会を提供します。 +したがって、追加のレプリカによる初期コストは発生する可能性がありますが、分析時の計算コストが削減されるため、特定のユースケースではより費用対効果の高いものになる可能性があります。特に分析ニーズが高いユーザーにとって、列指向ストレージはコストを大幅に削減し、大幅なコスト削減の機会を提供します。 ## Securityよくある質問 {#security-faqs} diff --git a/tidb-cloud/serverless-high-availability.md b/tidb-cloud/serverless-high-availability.md index d6f595f66ba3c..2d747da170123 100644 --- a/tidb-cloud/serverless-high-availability.md +++ b/tidb-cloud/serverless-high-availability.md @@ -66,9 +66,9 @@ TiDB Cloudは、アプリケーションの透過的なフェイルオーバー - 故障したレプリカの代わりに、新しいレプリカが作成される。 -- storageサービスを提供するサーバーは、Amazon S3またはAlibaba Cloud OSS（クラウドプロバイダーによって異なります）に永続化されたデータからローカルキャッシュを復元し、システムをレプリカと一貫性のある状態に復元します。 +- ストレージサービスを提供するサーバーは、Amazon S3またはAlibaba Cloud OSS（クラウドプロバイダーによって異なります）に永続化されたデータからローカルキャッシュを復元し、システムをレプリカと一貫性のある状態に復元します。 -storageレイヤーでは、永続化されたデータは、高い耐久性を確保するために、定期的にAmazon S3またはAlibaba Cloud OSS（クラウドプロバイダーによって異なります）にプッシュされます。さらに、即時更新は複数のTiKVサーバー間で複製されるだけでなく、各サーバーのEBSにも保存され、データの複製がさらに強化されて耐久性が向上します。TiDBは、バックオフと再試行をミリ秒単位で自動的に実行することで問題を解決し、クライアントアプリケーションのフェイルオーバー処理がシームレスに行われるようにします。 +ストレージレイヤーでは、永続化されたデータは、高い耐久性を確保するために、定期的にAmazon S3またはAlibaba Cloud OSS（クラウドプロバイダーによって異なります）にプッシュされます。さらに、即時更新は複数のTiKVサーバー間で複製されるだけでなく、各サーバーのEBSにも保存され、データの複製がさらに強化されて耐久性が向上します。TiDBは、バックオフと再試行をミリ秒単位で自動的に実行することで問題を解決し、クライアントアプリケーションのフェイルオーバー処理がシームレスに行われるようにします。 @@ -76,9 +76,9 @@ storageレイヤーでは、永続化されたデータは、高い耐久性を - 故障したレプリカの代わりに、新しいレプリカが作成される。 -- storageサービスを提供するサーバーは、Amazon S3（クラウドプロバイダーによって異なります）に永続化されたデータからローカルキャッシュを復元し、システムをレプリカと整合性のある状態に復元します。 +- ストレージサービスを提供するサーバーは、Amazon S3（クラウドプロバイダーによって異なります）に永続化されたデータからローカルキャッシュを復元し、システムをレプリカと整合性のある状態に復元します。 -storageレイヤーでは、永続化されたデータは高い耐久性を確保するために定期的にAmazon S3にプッシュされます。さらに、即時更新は複数のTiKVサーバー間で複製されるだけでなく、各サーバーのEBSにも保存され、データの複製がさらに強化されて耐久性が向上します。TiDBは、バックオフと再試行をミリ秒単位で自動的に実行することで問題を解決し、クライアントアプリケーションのフェイルオーバー処理がシームレスに行われるようにします。 +ストレージレイヤーでは、永続化されたデータは高い耐久性を確保するために定期的にAmazon S3にプッシュされます。さらに、即時更新は複数のTiKVサーバー間で複製されるだけでなく、各サーバーのEBSにも保存され、データの複製がさらに強化されて耐久性が向上します。TiDBは、バックオフと再試行をミリ秒単位で自動的に実行することで問題を解決し、クライアントアプリケーションのフェイルオーバー処理がシームレスに行われるようにします。 diff --git a/tidb-cloud/serverless-limitations.md b/tidb-cloud/serverless-limitations.md index 12ec16b988c43..594a2782de257 100644 --- a/tidb-cloud/serverless-limitations.md +++ b/tidb-cloud/serverless-limitations.md @@ -8,7 +8,7 @@ aliases: ['/ja/tidbcloud/serverless-tier-limitations'] -TiDB Cloud StarterおよびEssentialは、TiDBがサポートするほぼすべてのワークロードで動作しますが、TiDB Self-ManagedまたはTiDB Cloud Dedicatedクラスタと比較して機能に若干の違いがあります。このドキュメントでは、TiDB Cloud StarterおよびTiDB Cloud Essentialの制限事項について説明します。 +TiDB Cloud StarterおよびEssentialは、TiDBがサポートするほぼすべてのワークロードで動作しますが、TiDB Self-ManagedまたはTiDB Cloud Dedicatedクラスターと比較して機能に若干の違いがあります。このドキュメントでは、TiDB Cloud StarterおよびTiDB Cloud Essentialの制限事項について説明します。 TiDB Cloud Starter/EssentialとTiDB Cloud Dedicated間の機能ギャップを継続的に埋めています。ギャップを埋める機能や性能が必要な場合は、機能リクエストに[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)または[お問い合わせ](https://www.pingcap.com/contact-us/?from=en)使用してください。 @@ -68,8 +68,8 @@ TiDB Cloudでは、組織ごとに最大5つのクラスター（デフォルト 組織内の最初の 5 つのTiDB Cloud Starter クラスターについては、 TiDB Cloud は次のようにクラスターごとに無料使用量割り当てを提供します。 -- 行ベースのstorage: 5 GiB -- 列指向storage: 5 GiB +- 行ベースのストレージ: 5 GiB +- 列指向ストレージ: 5 GiB - [リクエストユニット（RU）](/tidb-cloud/tidb-cloud-glossary.md#request-unit-ru) : 月間5000万RU リクエストユニット（RU）は、クエリまたはトランザクションのリソース消費量を追跡するために使用される測定単位です。これは、データベース内の特定のリクエストを処理するために必要な計算リソースを見積もることができる指標です。リクエストユニットは、 TiDB Cloud Starterサービスの課金単位でもあります。 diff --git a/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md b/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md index 4adda95f7b6fd..9be4a282a06cc 100644 --- a/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md +++ b/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md @@ -63,7 +63,7 @@ Alibaba Cloud コンソールでロードバランサーとエンドポイント - **ネットワークタイプ**: `Internal-facing`を選択 - **VPC** : ApsaraDB RDS for MySQL が配置されている VPC を選択します。 - - **ゾーン**: TiDB Cloud Essential クラスタと重複する必要があります + - **ゾーン**: TiDB Cloud Essential クラスターと重複する必要があります - **IPバージョン**: `IPv4`を選択 4. 作成したロードバランサーを見つけて、 **「リスナーの作成」**をクリックします。以下の情報を入力します。 diff --git a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md index 6a974fda65a7b..d1e7d23bbb7e9 100644 --- a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md +++ b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md @@ -142,7 +142,7 @@ SASL/SCRAM の代わりに、 IAM認証を使用して MSK クラスターと同 ## ステップ3. クラスターポリシーをアタッチする {#step-3-attach-the-cluster-policy} -[クラスタポリシーをアタッチする](https://docs.aws.amazon.com/msk/latest/developerguide/mvpc-cluster-owner-action-policy.html) [前提条件](#prerequisites-for-essential)して、 TiDB Cloud がMSK クラスターに接続できるようにします。2 で取得したTiDB Cloud AWS アカウント ID を使用してください。 +[クラスターポリシーをアタッチする](https://docs.aws.amazon.com/msk/latest/developerguide/mvpc-cluster-owner-action-policy.html) [前提条件](#prerequisites-for-essential)して、 TiDB Cloud がMSK クラスターに接続できるようにします。2 で取得したTiDB Cloud AWS アカウント ID を使用してください。 ## ステップ4. マルチVPC接続を有効にする {#step-4-turn-on-multi-vpc-connectivity} diff --git a/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md b/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md index 58c3616a303d6..b5acf2cdd5a8a 100644 --- a/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md +++ b/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md @@ -5,7 +5,7 @@ summary: AWS エンドポイント サービス プライベート リンク接 # プライベートリンク接続を介して AWS 上の Confluent Cloud に接続する {#connect-to-confluent-cloud-on-aws-via-a-private-link-connection} -このドキュメントでは、 [AWS エンドポイントサービスプライベートリンク接続](/tidb-cloud/serverless-private-link-connection.md)を使用してTiDB Cloud Essential クラスターを AWS 上の[Confluent Cloud 専用クラスタ](https://docs.confluent.io/cloud/current/clusters/cluster-types.html)に接続する方法について説明します。 +このドキュメントでは、 [AWS エンドポイントサービスプライベートリンク接続](/tidb-cloud/serverless-private-link-connection.md)を使用してTiDB Cloud Essential クラスターを AWS 上の[Confluent Cloud 専用クラスター](https://docs.confluent.io/cloud/current/clusters/cluster-types.html)に接続する方法について説明します。 > **注記** > @@ -53,7 +53,7 @@ Confluent Cloud ネットワークの一意の名前を取得するには、次 - [前提条件](#prerequisites)で取得したTiDB Cloud AWS アカウント ID を入力します。 - Confluent Cloud によって提供される`VPC Service Endpoint` 、後で使用するために、通常は`com.amazonaws.vpce..vpce-svc-xxxxxxxxxxxxxxxxx`形式で保存します。 -## ステップ3. ネットワークの下にConfluent Cloud専用クラスタを作成する {#step-3-create-a-confluent-cloud-dedicated-cluster-under-the-network} +## ステップ3. ネットワークの下にConfluent Cloud専用クラスターを作成する {#step-3-create-a-confluent-cloud-dedicated-cluster-under-the-network} [ステップ1](#step-1-set-up-a-confluent-cloud-network)で設定した既存のネットワーク下に Confluent Cloud Dedicated クラスターを作成します。詳細については、 [Confluent Cloud で専用クラスターを作成する](https://docs.confluent.io/cloud/current/clusters/create-cluster.html#create-ak-clusters)参照してください。 diff --git a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md index 1cf5bee801098..f0079fe1eb8e8 100644 --- a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md +++ b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md @@ -280,7 +280,7 @@ SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" export JAVA_HOME="$SCRIPT_DIR/jdk-22.0.2" # Define the vars KAFKA_DIR="$SCRIPT_DIR/kafka_2.13-3.7.1/bin" -KAFKA_STORAGE_CMD=$KAFKA_DIR/kafka-storage.sh +KAFKA_STORAGE_CMD=$KAFKA_DIR/kafka-ストレージ.sh KAFKA_START_CMD=$KAFKA_DIR/kafka-server-start.sh KAFKA_DATA_DIR=$SCRIPT_DIR/data KAFKA_LOG_DIR=$SCRIPT_DIR/log diff --git a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md index f48a23845dde5..a3f3d62ddf924 100644 --- a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md +++ b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-aws.md @@ -360,7 +360,7 @@ SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" export JAVA_HOME="$SCRIPT_DIR/jdk-22.0.2" # Define the vars KAFKA_DIR="$SCRIPT_DIR/kafka_2.13-3.7.1/bin" -KAFKA_STORAGE_CMD=$KAFKA_DIR/kafka-storage.sh +KAFKA_STORAGE_CMD=$KAFKA_DIR/kafka-ストレージ.sh KAFKA_START_CMD=$KAFKA_DIR/kafka-server-start.sh KAFKA_DATA_DIR=$SCRIPT_DIR/data KAFKA_LOG_DIR=$SCRIPT_DIR/log diff --git a/tidb-cloud/serverless-private-link-connection.md b/tidb-cloud/serverless-private-link-connection.md index 150bd43818b7a..4c95a76705d10 100644 --- a/tidb-cloud/serverless-private-link-connection.md +++ b/tidb-cloud/serverless-private-link-connection.md @@ -105,7 +105,7 @@ Amazon MSK プロビジョニングプライベートリンク接続を作成す - **プライベート リンク接続名**: プライベート リンク接続の名前を入力します。 - **接続タイプ**： **Amazon MSK Provisioned を**選択します。このオプションが表示されない場合は、クラスターがAWS上に作成されていることを確認してください。 - - **MSKクラスタARN** : Amazon MSK プロビジョニングされたクラスターの ARN を入力します (例: `arn:aws:kafka:us-east-1:385595570414:cluster//xxxx` )。 + - **MSKクラスターARN** : Amazon MSK プロビジョニングされたクラスターの ARN を入力します (例: `arn:aws:kafka:us-east-1:385595570414:cluster//xxxx` )。 5. **[作成]**をクリックします。 @@ -201,7 +201,7 @@ TiDB Cloudコンソールを使用してドメインをプライベート リン 5. **[ドメインの接続]**ダイアログで、ドメインの種類を選択します。 - **TiDB Cloud管理**：ドメインはTiDB Cloudによって自動的に生成されます。生成されたドメインの名前には、そのドメインの一意の名前が付与されます。例えば、生成されたドメインが`*.use1-az1.dvs6nl5jgveztmla3pxkxgh76i.aws.plc.tidbcloud.com`場合、一意の名前は`dvs6nl5jgveztmla3pxkxgh76i`になります。 **「ドメインをアタッチ」**をクリックして確定します。 - - **Confluent Cloud** : Confluent Cloud Dedicatedクラスタからドメインを生成するために提供された一意の名前を入力し、 **「ドメインをアタッチ」を**クリックして確定します。一意の名前の取得方法の詳細については、 [プライベートリンク接続を介してConfluent Cloudに接続する](/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md#step-1-set-up-a-confluent-cloud-network)を参照してください。 + - **Confluent Cloud** : Confluent Cloud Dedicatedクラスターからドメインを生成するために提供された一意の名前を入力し、 **「ドメインをアタッチ」を**クリックして確定します。一意の名前の取得方法の詳細については、 [プライベートリンク接続を介してConfluent Cloudに接続する](/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md#step-1-set-up-a-confluent-cloud-network)を参照してください。
    diff --git a/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md b/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md index 97624be1cd539..f58240a28689c 100644 --- a/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md +++ b/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md @@ -18,14 +18,14 @@ summary: Alibaba Cloudのプライベートエンドポイントを介してTiDB ## Alibaba Cloudでプライベートエンドポイントを設定する {#set-up-a-private-endpoint-with-alibaba-cloud} -プライベートエンドポイント経由でTiDB Cloud StarterまたはTiDB Cloud Essentialクラスタに接続するには、以下の手順に従ってください。 +プライベートエンドポイント経由でTiDB Cloud StarterまたはTiDB Cloud Essentialクラスターに接続するには、以下の手順に従ってください。 -1. [TiDBクラスタを選択してください](#step-1-choose-a-tidb-cluster) +1. [TiDBクラスターを選択してください](#step-1-choose-a-tidb-cluster) 2. [Alibaba Cloud上にプライベートエンドポイントを作成する](#step-2-create-a-private-endpoint-on-alibaba-cloud) 3. [TiDB Cloudでプライベートエンドポイントを認証します。](#step-3-authorize-your-private-endpoint-in-tidb-cloud) -4. [プライベートエンドポイントを使用してTiDBクラスタに接続します。](#step-4-connect-to-your-tidb-cluster-using-the-private-endpoint) +4. [プライベートエンドポイントを使用してTiDBクラスターに接続します。](#step-4-connect-to-your-tidb-cluster-using-the-private-endpoint) -### ステップ1. TiDBクラスタを選択する {#step-1-choose-a-tidb-cluster} +### ステップ1. TiDBクラスターを選択する {#step-1-choose-a-tidb-cluster} 1. [**クラスター**](https://tidbcloud.com/project/clusters)ページ目で、対象のTiDB Cloudクラスターの名前をクリックして、概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 @@ -62,7 +62,7 @@ Alibaba Cloud管理コンソールを使用してVPCインターフェースエ Alibaba Cloudでインターフェースエンドポイントを作成したら、それをクラスターの許可リストに追加する必要があります。 -1. [**クラスター**](https://tidbcloud.com/project/clusters)ページ目で、対象のTiDB Cloud StarterまたはTiDB Cloud Essentialクラスタの名前をクリックして、概要ページに移動します。 +1. [**クラスター**](https://tidbcloud.com/project/clusters)ページ目で、対象のTiDB Cloud StarterまたはTiDB Cloud Essentialクラスターの名前をクリックして、概要ページに移動します。 2. 左側のナビゲーションペインで、 **[設定]** > **[ネットワーク]**をクリックします。 @@ -82,7 +82,7 @@ Alibaba Cloudでインターフェースエンドポイントを作成したら 5. **「送信」**をクリックしてください。 -### ステップ4. プライベートエンドポイントを使用してTiDBクラスタに接続します。 {#step-4-connect-to-your-tidb-cluster-using-the-private-endpoint} +### ステップ4. プライベートエンドポイントを使用してTiDBクラスターに接続します。 {#step-4-connect-to-your-tidb-cluster-using-the-private-endpoint} インターフェースエンドポイントを作成したら、 TiDB Cloudコンソールに戻り、以下の手順を実行してください。 diff --git a/tidb-cloud/set-up-private-endpoint-connections-on-azure.md b/tidb-cloud/set-up-private-endpoint-connections-on-azure.md index e0d826e510831..73510f8453833 100644 --- a/tidb-cloud/set-up-private-endpoint-connections-on-azure.md +++ b/tidb-cloud/set-up-private-endpoint-connections-on-azure.md @@ -1,9 +1,9 @@ --- title: Connect to a TiDB Cloud Dedicated Cluster via Azure Private Link -summary: Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスタに接続する方法を学びましょう。 +summary: Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスターに接続する方法を学びましょう。 --- -# Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスタに接続する {#connect-to-a-tidb-cloud-dedicated-cluster-via-azure-private-link} +# Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスターに接続する {#connect-to-a-tidb-cloud-dedicated-cluster-via-azure-private-link} このドキュメントでは[Azure プライベートリンク](https://learn.microsoft.com/en-us/azure/private-link/private-link-overview)経由でTiDB Cloud Dedicatedクラスターに接続する方法について説明します。 @@ -11,8 +11,8 @@ summary: Azureプライベートリンクを介してTiDB Cloud Dedicatedクラ > **ヒント：** > -> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します。](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 -> - Google Cloud のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します。](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md) +> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスターに接続します。](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 +> - Google Cloud のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスターに接続します。](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md) > - プライベートエンドポイントを介してTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、以下のドキュメントを参照してください。 > - [AWS PrivateLink経由でTiDB Cloud StarterまたはEssentialに接続します。](/tidb-cloud/set-up-private-endpoint-connections-serverless.md) > - [Alibaba Cloudプライベートエンドポイント経由でTiDB Cloud StarterまたはEssentialに接続します。](/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md) @@ -23,8 +23,8 @@ summary: Azureプライベートリンクを介してTiDB Cloud Dedicatedクラ > **ヒント：** > -> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します。](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 -> - Google Cloud のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します。](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md) +> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスターに接続します。](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 +> - Google Cloud のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスターに接続します。](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md) > - プライベートエンドポイント経由でTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、 [AWS PrivateLink経由でTiDB Cloud StarterまたはEssentialに接続します。](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)を参照してください。 @@ -46,22 +46,22 @@ Azure Private Link のアーキテクチャは次のとおりです: [^1] ## 制限 {#restrictions} - `Organization Owner`および`Project Owner`ロールのみがプライベートエンドポイントを作成できます。 -- 接続するプライベートエンドポイントとTiDBクラスタは、同じリージョンに配置されている必要があります。 +- 接続するプライベートエンドポイントとTiDBクラスターは、同じリージョンに配置されている必要があります。 ## Azure Private Link を使用してプライベートエンドポイントを設定する {#set-up-a-private-endpoint-with-azure-private-link} -プライベートエンドポイント経由でTiDB Cloud Dedicatedクラスタに接続するには、以下の手順を実行してください。 +プライベートエンドポイント経由でTiDB Cloud Dedicatedクラスターに接続するには、以下の手順を実行してください。 -1. [TiDBクラスタを選択してください](#step-1-select-a-tidb-cluster) +1. [TiDBクラスターを選択してください](#step-1-select-a-tidb-cluster) 2. [Azureプライベートエンドポイントを作成する](#step-2-create-an-azure-private-endpoint) 3. [エンドポイントを受け入れる](#step-3-accept-the-endpoint) 4. [TiDBクラスターに接続します](#step-4-connect-to-your-tidb-cluster) 複数のクラスターがある場合は、Azure Private Link を使用して接続する各クラスターに対して、これらの手順を繰り返す必要があります。 -### ステップ1. TiDBクラスタを選択します {#step-1-select-a-tidb-cluster} +### ステップ1. TiDBクラスターを選択します {#step-1-select-a-tidb-cluster} -1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Dedicatedクラスタの名前をクリックすると、その概要ページに移動します。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Dedicatedクラスターの名前をクリックすると、その概要ページに移動します。 2. 右上隅の**「接続」**をクリックしてください。接続ダイアログが表示されます。 3. **「接続の種類」**ドロップダウンリストで**「プライベートエンドポイント」**を選択し、 **「プライベートエンドポイント接続の作成」**をクリックして、 **「Azureプライベートエンドポイント接続の作成」**ダイアログを開きます。 diff --git a/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md b/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md index 10f449541f70e..fac44cd190f43 100644 --- a/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md +++ b/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md @@ -3,7 +3,7 @@ title: Connect to a TiDB Cloud Dedicated Cluster via Google Cloud Private Servic summary: Google Cloud Private Service Connectを使用してTiDB Cloudクラスターに接続する方法を学びましょう。 --- -# Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します。 {#connect-to-a-tidb-cloud-dedicated-cluster-via-google-cloud-private-service-connect} +# Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスターに接続します。 {#connect-to-a-tidb-cloud-dedicated-cluster-via-google-cloud-private-service-connect} このドキュメントでは[プライベートサービス接続](https://cloud.google.com/vpc/docs/private-service-connect)を介してTiDB Cloud Dedicatedクラスターに接続する方法について説明します。 Google Cloud Private Service Connect は、Google Cloud が提供するプライベート エンドポイント サービスです。 @@ -11,8 +11,8 @@ summary: Google Cloud Private Service Connectを使用してTiDB Cloudクラス > **ヒント：** > -> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します。](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 -> - Azure のプライベート エンドポイントを介してTiDB Cloud Dedicatedクラスターに接続する方法については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)D dedicated クラスターに接続する」を参照してください。 +> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスターに接続します。](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 +> - Azure のプライベート エンドポイントを介してTiDB Cloud Dedicatedクラスターに接続する方法については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスターに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)D dedicated クラスターに接続する」を参照してください。 > - プライベートエンドポイントを介してTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、以下のドキュメントを参照してください。 > - [AWS PrivateLink経由でTiDB Cloud StarterまたはEssentialに接続します。](/tidb-cloud/set-up-private-endpoint-connections-serverless.md) > - [Alibaba Cloudプライベートエンドポイント経由でTiDB Cloud StarterまたはEssentialに接続します。](/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md) @@ -23,8 +23,8 @@ summary: Google Cloud Private Service Connectを使用してTiDB Cloudクラス > **ヒント：** > -> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します。](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 -> - Azure のプライベート エンドポイントを介してTiDB Cloud Dedicatedクラスターに接続する方法については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)D dedicated クラスターに接続する」を参照してください。 +> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスターに接続します。](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 +> - Azure のプライベート エンドポイントを介してTiDB Cloud Dedicatedクラスターに接続する方法については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスターに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)D dedicated クラスターに接続する」を参照してください。 > - プライベートエンドポイント経由でTiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスに接続する方法については、 [AWS PrivateLink経由でTiDB Cloud StarterまたはEssentialに接続します。](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)を参照してください。 @@ -44,30 +44,30 @@ Google Cloud Private Service Connect のアーキテクチャは以下のとお ## 制限 {#restrictions} -- この機能は、2023年4月13日以降に作成されたTiDB Cloud Dedicatedクラスタに適用されます。それ以前のクラスタについては、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 +- この機能は、2023年4月13日以降に作成されたTiDB Cloud Dedicatedクラスターに適用されます。それ以前のクラスターについては、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 - `Organization Owner`および`Project Owner`ロールのみが、Google Cloud Private Service Connect エンドポイントを作成できます。 -- 各TiDBクラスタは、最大10個のエンドポイントからの接続を処理できます。 -- 各Google Cloudプロジェクトは、最大10個のエンドポイントをTiDBクラスタに接続できます。 +- 各TiDBクラスターは、最大10個のエンドポイントからの接続を処理できます。 +- 各Google Cloudプロジェクトは、最大10個のエンドポイントをTiDBクラスターに接続できます。 - 2025年8月12日以降、Google Cloud上のTiDB Cloud Dedicatedクラスターでリージョンごとに作成できるGoogle Private Service Connect（PSC）接続の最大数は、NATサブネットCIDRブロックサイズによって異なります。 - `/20` : 地域ごとに最大 7 つの PSC 接続 - `/19` : 地域ごとに最大 23 の PSC 接続 - `/18` : 地域ごとに最大55のPSC接続 - `/17` : 地域ごとに最大 119 の PSC 接続 - `/16` : 地域ごとに最大 247 の PSC 接続 -- 接続するプライベートエンドポイントとTiDBクラスタは、同じリージョンに配置されている必要があります。 +- 接続するプライベートエンドポイントとTiDBクラスターは、同じリージョンに配置されている必要があります。 - 送信ファイアウォール ルールでは、エンドポイントの内部 IP アドレスへのトラフィックを許可する必要があります。 [暗黙の送信許可ファイアウォールルール](https://cloud.google.com/firewall/docs/firewalls#default_firewall_rules)任意の宛先 IP アドレスへの送信を許可します。 - VPCネットワークで送信拒否ファイアウォールルールを作成している場合、または暗黙的に許可される送信動作を変更する階層型ファイアウォールポリシーを作成している場合、エンドポイントへのアクセスに影響が出る可能性があります。この場合、エンドポイントの内部宛先IPアドレスへのトラフィックを許可する、特定の送信許可ファイアウォールルールまたはポリシーを作成する必要があります。 ほとんどのシナリオでは、VPCピアリングよりもプライベートエンドポイント接続を使用することをお勧めします。ただし、以下のシナリオでは、プライベートエンドポイント接続の代わりにVPCピアリングを使用する必要があります。 -- 高可用性を実現するために、 [TiCDC](https://docs.pingcap.com/tidb/stable/ticdc-overview)クラスタを使用して、ソースTiDBクラスタからターゲットTiDBクラスタへリージョンをまたいでデータをレプリケートしています。現在、プライベートエンドポイントはリージョン間接続をサポートしていません。 -- TiCDCクラスタを使用してデータをダウンストリームクラスタ（Amazon Aurora、MySQL、Kafkaなど）に複製していますが、ダウンストリームのエンドポイントサービスを独自に維持することはできません。 +- 高可用性を実現するために、 [TiCDC](https://docs.pingcap.com/tidb/stable/ticdc-overview)クラスターを使用して、ソースTiDBクラスターからターゲットTiDBクラスターへリージョンをまたいでデータをレプリケートしています。現在、プライベートエンドポイントはリージョン間接続をサポートしていません。 +- TiCDCクラスターを使用してデータをダウンストリームクラスター（Amazon Aurora、MySQL、Kafkaなど）に複製していますが、ダウンストリームのエンドポイントサービスを独自に維持することはできません。 ## Google Cloud Private Service Connect を使用してプライベートエンドポイントを設定します。 {#set-up-a-private-endpoint-with-google-cloud-private-service-connect} [前提条件](#prerequisites)エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続するには、 を完了し、以下の手順に従ってください。 -1. [TiDBクラスタを選択してください](#step-1-select-a-tidb-cluster) +1. [TiDBクラスターを選択してください](#step-1-select-a-tidb-cluster) 2. [Google Cloudプライベートエンドポイントを作成する](#step-2-create-a-google-cloud-private-endpoint) 3. [エンドポイントへのアクセスを許可する](#step-3-accept-endpoint-access) 4. [TiDBクラスターに接続します](#step-4-connect-to-your-tidb-cluster) @@ -92,9 +92,9 @@ Google Cloud Private Service Connect のアーキテクチャは以下のとお - コンピュータネットワーク[コンピュータネットワーク管理者](https://cloud.google.com/iam/docs/understanding-roles#compute.networkAdmin)) - サービスディレクトリエディター(roles/ [サービスディレクトリエディター](https://cloud.google.com/iam/docs/understanding-roles#servicedirectory.editor)) -### ステップ1. TiDBクラスタを選択します {#step-1-select-a-tidb-cluster} +### ステップ1. TiDBクラスターを選択します {#step-1-select-a-tidb-cluster} -1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Dedicatedクラスタの名前をクリックして、概要ページに移動します。以下のいずれかのステータスのクラスタを選択できます。 +1. [**私のTiDB**](https://tidbcloud.com/tidbs)ページで、対象のTiDB Cloud Dedicatedクラスターの名前をクリックして、概要ページに移動します。以下のいずれかのステータスのクラスターを選択できます。 - **利用可能** - **復元** diff --git a/tidb-cloud/set-up-private-endpoint-connections-serverless.md b/tidb-cloud/set-up-private-endpoint-connections-serverless.md index cd03e3c9dfada..86724bfa438aa 100644 --- a/tidb-cloud/set-up-private-endpoint-connections-serverless.md +++ b/tidb-cloud/set-up-private-endpoint-connections-serverless.md @@ -9,9 +9,9 @@ summary: プライベートエンドポイントを介してTiDB Cloud Starter > **ヒント：** > -> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスタに接続します。](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 -> - Azure のプライベート エンドポイントを介してTiDB Cloud Dedicatedクラスターに接続する方法については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)D dedicated クラスターに接続する」を参照してください。 -> - Google Cloud のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスタに接続します。](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)参照してください。 +> - AWS のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [AWS PrivateLink を介してTiDB Cloud Dedicatedクラスターに接続します。](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 +> - Azure のプライベート エンドポイントを介してTiDB Cloud Dedicatedクラスターに接続する方法については、 [Azureプライベートリンクを介してTiDB Cloud Dedicatedクラスターに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)D dedicated クラスターに接続する」を参照してください。 +> - Google Cloud のプライベート エンドポイント経由でTiDB Cloud Dedicatedクラスターに接続する方法については、 [Google Cloud Private Service Connect を介してTiDB Cloud Dedicatedクラスターに接続します。](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)参照してください。 TiDB Cloudは、 AWS VPC内でホストされているTiDB Cloudサービスへの[AWSプライベートリンク](https://aws.amazon.com/privatelink/?privatelink-blogs.sort-by=item.additionalFields.createdDate&privatelink-blogs.sort-order=desc)を介した高度に安全な一方向アクセスをサポートしています。まるでサービスがお客様自身のVPC内にあるかのように動作します。お客様のVPC内にプライベートエンドポイントが公開され、権限があればそのエンドポイントを介してTiDB Cloudサービスへの接続を作成できます。 diff --git a/tidb-cloud/set-up-private-endpoint-connections.md b/tidb-cloud/set-up-private-endpoint-connections.md index d5c1cb5638d88..7cf50a8d43823 100644 --- a/tidb-cloud/set-up-private-endpoint-connections.md +++ b/tidb-cloud/set-up-private-endpoint-connections.md @@ -3,15 +3,15 @@ title: Connect to a TiDB Cloud Dedicated Cluster via AWS PrivateLink summary: AWS を使用してプライベートエンドポイント経由でTiDB Cloudクラスターに接続する方法を学習します。 --- -# AWS PrivateLink 経由でTiDB Cloud専用クラスタに接続する {#connect-to-a-tidb-cloud-dedicated-cluster-via-aws-privatelink} +# AWS PrivateLink 経由でTiDB Cloud専用クラスターに接続する {#connect-to-a-tidb-cloud-dedicated-cluster-via-aws-privatelink} このドキュメントでは、 [AWS プライベートリンク](https://aws.amazon.com/privatelink)経由でTiDB Cloud Dedicated クラスターに接続する方法について説明します。 > **ヒント：** > > - AWS PrivateLink 経由でTiDB Cloud Starter またはTiDB Cloud Essential クラスターに接続する方法については、 [AWS PrivateLink 経由でTiDB Cloud Starter または Essential に接続します](/tidb-cloud/set-up-private-endpoint-connections-serverless.md)参照してください。 -> - Azure のプライベート エンドポイント経由でTiDB Cloud Dedicated クラスターに接続する方法については、 [Azure Private Link 経由でTiDB Cloud専用クラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)参照してください。 -> - Google Cloud のプライベート エンドポイント経由でTiDB Cloud Dedicated クラスタに接続する方法については、 [Google Cloud Private Service Connect 経由でTiDB Cloud専用クラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)ご覧ください。 +> - Azure のプライベート エンドポイント経由でTiDB Cloud Dedicated クラスターに接続する方法については、 [Azure Private Link 経由でTiDB Cloud専用クラスターに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-azure.md)参照してください。 +> - Google Cloud のプライベート エンドポイント経由でTiDB Cloud Dedicated クラスターに接続する方法については、 [Google Cloud Private Service Connect 経由でTiDB Cloud専用クラスターに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)ご覧ください。 TiDB Cloudは、 AWS VPCでホストされているTiDB Cloudサービスへの、 [AWS プライベートリンク](https://aws.amazon.com/privatelink)経由の高度に安全な一方向アクセスをサポートします。まるでお客様のVPC内にあるかのように機能します。VPC内にプライベートエンドポイントが公開されており、権限があればエンドポイント経由でTiDB Cloudサービスへの接続を作成できます。 @@ -45,11 +45,11 @@ AWS VPC設定でDNSホスト名とDNS解決の[AWS マネジメントコンソ プライベート エンドポイント経由でTiDB Cloud Dedicated クラスターに接続するには、次の手順を実行します。 -1. [TiDBクラスタを選択](#step-1-select-a-tidb-cluster) +1. [TiDBクラスターを選択](#step-1-select-a-tidb-cluster) 2. [AWSインターフェースエンドポイントを作成する](#step-2-create-an-aws-interface-endpoint) 3. [プライベートエンドポイント接続を作成する](#step-3-create-a-private-endpoint-connection) 4. [プライベートDNSを有効にする](#step-4-enable-private-dns) -5. [TiDBクラスタに接続する](#step-5-connect-to-your-tidb-cluster) +5. [TiDBクラスターに接続する](#step-5-connect-to-your-tidb-cluster) 複数のクラスターがある場合は、AWS PrivateLink を使用して接続するクラスターごとにこれらの手順を繰り返す必要があります。 diff --git a/tidb-cloud/set-up-vpc-peering-connections.md b/tidb-cloud/set-up-vpc-peering-connections.md index 2b09dba2fda36..bdd06eeb99a24 100644 --- a/tidb-cloud/set-up-vpc-peering-connections.md +++ b/tidb-cloud/set-up-vpc-peering-connections.md @@ -25,7 +25,7 @@ CIDR (Classless Inter-Domain Routing) は、 TiDB Cloud Dedicated クラスタ VPCピアリングリクエストをリージョンに追加するには、そのリージョンのCIDRを設定し、そのリージョンに最初のTiDB Cloud専用クラスターを作成する必要があります。最初の専用クラスターが作成されると、 TiDB CloudはクラスターのVPCを作成し、アプリケーションのVPCへのピアリングリンクを確立できるようになります。 -最初のTiDB Cloud Dedicatedクラスタを作成する際にCIDRを設定できます。クラスタ作成前にCIDRを設定する場合は、以下の操作を実行してください。 +最初のTiDB Cloud Dedicatedクラスターを作成する際にCIDRを設定できます。クラスター作成前にCIDRを設定する場合は、以下の操作を実行してください。 1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用してターゲット プロジェクトに切り替えます。 @@ -62,7 +62,7 @@ VPCピアリングリクエストをリージョンに追加するには、そ ### ステップ1. VPCピアリングリクエストを追加する {#step-1-add-vpc-peering-requests} -VPC ピアリング リクエストは、TiDB Cloudコンソールのプロジェクト レベルの [**ネットワーク アクセス]**ページまたはクラスタ レベルの**[ネットワーキング]**ページのいずれかで追加できます。 +VPC ピアリング リクエストは、TiDB Cloudコンソールのプロジェクト レベルの [**ネットワーク アクセス]**ページまたはクラスター レベルの**[ネットワーキング]**ページのいずれかで追加できます。
    @@ -188,7 +188,7 @@ AWS CLI または AWS ダッシュボードを使用して、VPC ピアリング aws ec2 modify-vpc-attribute --vpc-id "$app_vpc_id" --enable-dns-support ``` -設定が完了すると、VPCピアリングが作成されます。1 [TiDBクラスタに接続する](#connect-to-the-tidb-cluster)結果を確認できます。 +設定が完了すると、VPCピアリングが作成されます。1 [TiDBクラスターに接続する](#connect-to-the-tidb-cluster)結果を確認できます。
    @@ -240,7 +240,7 @@ AWS ダッシュボードを使用して VPC ピアリング接続を構成す ### ステップ1. VPCピアリングリクエストを追加する {#step-1-add-vpc-peering-requests} -VPC ピアリング リクエストは、TiDB Cloudコンソールのプロジェクト レベルの [**ネットワーク アクセス]**ページまたはクラスタ レベルの**[ネットワーキング]**ページのいずれかで追加できます。 +VPC ピアリング リクエストは、TiDB Cloudコンソールのプロジェクト レベルの [**ネットワーク アクセス]**ページまたはクラスター レベルの**[ネットワーキング]**ページのいずれかで追加できます。
    @@ -313,7 +313,7 @@ gcloud beta compute networks peerings create --project E ## ステップ3. TiDB Cloudから接続する {#step-3-connect-from-tidb-cloud} -1. [TiDB Cloudコンソール](https://tidbcloud.com)に戻って、クラスタ実例**プライベートリンク**を使用してKafkaクラスターに接続します。詳細については、 [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)参照してください。 +1. [TiDB Cloudコンソール](https://tidbcloud.com)に戻って、クラスター実例**プライベートリンク**を使用してKafkaクラスターに接続します。詳細については、 [Apache Kafka にシンクする](/tidb-cloud/changefeed-sink-to-apache-kafka.md)参照してください。 2. **「ChangeFeed ターゲットの構成」>「接続方法」>「プライベート リンク」**に進むときは、次のフィールドに対応する値を入力し、必要に応じてその他のフィールドを入力します。 diff --git a/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md b/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md index d890099941b4a..c0354d34ebe2a 100644 --- a/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md +++ b/tidb-cloud/setup-azure-self-hosted-kafka-private-link-service.md @@ -30,7 +30,7 @@ summary: このドキュメントでは、Azure でセルフホスト型 Kafka - プライベートリンクサービスを管理する - 仮想マシンに接続して Kafka ノードを構成する -2. Azure をお持ちでない場合は[TiDB Cloud専用クラスタを作成する](/tidb-cloud/create-tidb-cluster.md) 。 +2. Azure をお持ちでない場合は[TiDB Cloud専用クラスターを作成する](/tidb-cloud/create-tidb-cluster.md) 。 3. [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターから Kafka デプロイメント情報を取得します。 @@ -220,7 +220,7 @@ summary: このドキュメントでは、Azure でセルフホスト型 Kafka SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" export JAVA_HOME="$SCRIPT_DIR/jdk-22.0.2" KAFKA_DIR="$SCRIPT_DIR/kafka_2.13-3.7.1/bin" - KAFKA_STORAGE_CMD=$KAFKA_DIR/kafka-storage.sh + KAFKA_STORAGE_CMD=$KAFKA_DIR/kafka-ストレージ.sh KAFKA_START_CMD=$KAFKA_DIR/kafka-server-start.sh KAFKA_DATA_DIR=$SCRIPT_DIR/data KAFKA_LOG_DIR=$SCRIPT_DIR/log @@ -446,9 +446,9 @@ b3.abc.eastus.azure.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. 4. **[バックエンド プール]**タブで、次の 3 つのバックエンド プールを追加し、 **[次へ: 受信規則]**をクリックします。 - - 名前: `pool1` ; バックエンド プールコンフィグレーション: `NIC` ; IP 構成: `broker-node-1` - - 名前: `pool2` ; バックエンド プールコンフィグレーション: `NIC` ; IP 構成: `broker-node-2` - - 名前: `pool3` ; バックエンド プールコンフィグレーション: `NIC` ; IP 構成: `broker-node-3` + - 名前: `pool1` ; バックエンド プール設定: `NIC` ; IP 構成: `broker-node-1` + - 名前: `pool2` ; バックエンド プール設定: `NIC` ; IP 構成: `broker-node-2` + - 名前: `pool3` ; バックエンド プール設定: `NIC` ; IP 構成: `broker-node-3` 5. **[受信規則]**タブで、次の 3 つの負荷分散規則を追加します。 diff --git a/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md b/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md index 2cd687ecbcd66..cc11a0d348f43 100644 --- a/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md +++ b/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md @@ -33,7 +33,7 @@ Google Cloud でセルフホスト型 Kafka に Private Service Connect を設 - プライベートサービス接続の管理 - VMノードに接続してKafkaノードを構成する -2. 持っていない場合は[TiDB Cloud専用クラスタを作成する](/tidb-cloud/create-tidb-cluster.md) 。 +2. 持っていない場合は[TiDB Cloud専用クラスターを作成する](/tidb-cloud/create-tidb-cluster.md) 。 3. TiDB Cloud Dedicated クラスターから Kafka デプロイメント情報を取得します。 @@ -43,7 +43,7 @@ Google Cloud でセルフホスト型 Kafka に Private Service Connect を設 1. **宛先**で、 **Kafka**を選択します。 2. **[接続方法]**で、 **[プライベート サービス接続]**を選択します。 4. **先に進む前に、Google Cloud プロジェクトをリマインダー**に書き留めておいてください。このプロジェクトは、 TiDB Cloudからのエンドポイント作成リクエストの自動承認を承認するために使用します。 - 5. **TiDBクラスタのゾーン**をメモしておいてください。これらのゾーンに TiDB クラスターをデプロイします。ゾーン間のトラフィックを削減するため、これらのゾーンに Kafka をデプロイすることをお勧めします。 + 5. **TiDBクラスターのゾーン**をメモしておいてください。これらのゾーンに TiDB クラスターをデプロイします。ゾーン間のトラフィックを削減するため、これらのゾーンに Kafka をデプロイすることをお勧めします。 6. Kafka プライベート サービス接続サービスに固有の**Kafka アドバタイズ リスナー パターン**を選択します。 1. 一意のランダム文字列を入力してください。数字または小文字のみ使用できます。この文字列は、後ほど**Kafkaアドバタイズリスナーパターンを**生成する際に使用します。 2. **「使用状況を確認して生成」を**クリックすると、ランダム文字列が一意であるかどうかが確認され、Kafka ブローカーの外部アドバタイズ リスナーを組み立てるために使用される**Kafka アドバタイズ リスナー パターンが**生成されるか、Kafka プロキシが構成されます。 @@ -245,7 +245,7 @@ VM をプロビジョニングするには、 [VMインスタンス](https://con export JAVA_HOME="$SCRIPT_DIR/jdk-22.0.2" # Define the vars KAFKA_DIR="$SCRIPT_DIR/kafka_2.13-3.7.1/bin" - KAFKA_STORAGE_CMD=$KAFKA_DIR/kafka-storage.sh + KAFKA_STORAGE_CMD=$KAFKA_DIR/kafka-ストレージ.sh KAFKA_START_CMD=$KAFKA_DIR/kafka-server-start.sh KAFKA_DATA_DIR=$SCRIPT_DIR/data KAFKA_LOG_DIR=$SCRIPT_DIR/log @@ -689,7 +689,7 @@ TiDB クラスターと同じリージョンで既に Kafka クラスターが - PSC ポート マッピングによって Kafka PSC を設定する場合は、次の手順を実行します。 - 1. このドキュメントの冒頭の指示に従ってください[ステップ1. Kafkaクラスタのセットアップ](#step-1-set-up-the-kafka-cluster)に進んだら、 [実行中の Kafka クラスターを再構成する](#reconfigure-a-running-kafka-cluster)セクションに従って、EXTERNAL リスナーとアドバタイズリスナーの別のグループを作成してください。このグループの名前は`EXTERNAL2`とします。ポート範囲`EXTERNAL2`は EXTERNAL と重複できないことに注意してください。 + 1. このドキュメントの冒頭の指示に従ってください[ステップ1. Kafkaクラスターのセットアップ](#step-1-set-up-the-kafka-cluster)に進んだら、 [実行中の Kafka クラスターを再構成する](#reconfigure-a-running-kafka-cluster)セクションに従って、EXTERNAL リスナーとアドバタイズリスナーの別のグループを作成してください。このグループの名前は`EXTERNAL2`とします。ポート範囲`EXTERNAL2`は EXTERNAL と重複できないことに注意してください。 2. ブローカーを再構成した後、ネットワーク エンドポイントの別のグループをネットワーク エンドポイント グループに追加し、ポート範囲を`EXTERNAL2`リスナーにマップします。 diff --git a/tidb-cloud/size-your-cluster.md b/tidb-cloud/size-your-cluster.md index cebe5f6f35a7b..70e055c1c4ea7 100644 --- a/tidb-cloud/size-your-cluster.md +++ b/tidb-cloud/size-your-cluster.md @@ -83,7 +83,7 @@ TiDBノード数が8未満の場合、パフォーマンス偏差係数はほぼ TiKVはデータの保存を担当し、水平方向に拡張可能です。 -TiKV のノード数、vCPU と RAM、storageを構成できます。 +TiKV のノード数、vCPU と RAM、ストレージを構成できます。 さまざまなクラスター規模のパフォーマンス テスト結果については、 [TiDB Cloudパフォーマンス リファレンス](/tidb-cloud/tidb-cloud-performance-reference.md)参照してください。 @@ -116,17 +116,17 @@ TiDB Cloudは、耐久性と高可用性を実現するために、選択した > **注記：** > -> TiDB クラスターをスケールすると、3 つのアベイラビリティゾーンのノードが同時に増減します。ニーズに応じて TiDB クラスターをスケールインまたはスケールアウトする方法については、 [TiDBクラスタのスケール](/tidb-cloud/scale-tidb-cluster.md)参照してください。 +> TiDB クラスターをスケールすると、3 つのアベイラビリティゾーンのノードが同時に増減します。ニーズに応じて TiDB クラスターをスケールインまたはスケールアウトする方法については、 [TiDBクラスターのスケール](/tidb-cloud/scale-tidb-cluster.md)参照してください。 -TiKVは主にデータstorageに使用されますが、TiKVノードのパフォーマンスはワークロードによって異なります。そのため、TiKVノードの数を計画する際には、 [**データ量**](#estimate-tikv-node-count-according-to-data-volume)と[期待されるパフォーマンス](#estimate-tikv-node-count-according-to-expected-performance)両方に基づいて見積もり、そのうち大きい方の見積もりを推奨ノード数とする必要があります。 +TiKVは主にデータストレージに使用されますが、TiKVノードのパフォーマンスはワークロードによって異なります。そのため、TiKVノードの数を計画する際には、 [**データ量**](#estimate-tikv-node-count-according-to-data-volume)と[期待されるパフォーマンス](#estimate-tikv-node-count-according-to-expected-performance)両方に基づいて見積もり、そのうち大きい方の見積もりを推奨ノード数とする必要があります。 #### データ量に応じて TiKV ノード数を推定する {#estimate-tikv-node-count-according-to-data-volume} 次のようにして、データ量に応じて推奨される TiKV ノードの数を計算できます。 -`node count = ceil(size of your data * TiKV compression ratio * the number of replicas ÷ TiKV storage usage ratio ÷ one TiKV capacity ÷ 3) * 3` +`node count = ceil(size of your data * TiKV compression ratio * the number of replicas ÷ TiKV ストレージ usage ratio ÷ one TiKV capacity ÷ 3) * 3` -一般的に、TiKVstorageの使用率は80%未満に抑えることが推奨されます。TiDB Cloudのレプリカ数はデフォルトで3です。8 vCPU、64 GiBのTiKVノードの最大storage容量は4096 GiBです。 +一般的に、TiKVストレージの使用率は80%未満に抑えることが推奨されます。TiDB Cloudのレプリカ数はデフォルトで3です。8 vCPU、64 GiBのTiKVノードの最大ストレージ容量は4096 GiBです。 過去のデータに基づくと、TiKV の平均圧縮率は約 40% です。 @@ -171,11 +171,11 @@ TiKVノード数が8未満の場合、パフォーマンス偏差係数はほぼ 次に、データ量に応じて計算された TiKV ノード数と、予想されるパフォーマンスに応じて計算された数を比較し、大きい方を TiKV ノードの推奨数とします。 -### TiKVノードのstorageサイズ {#tikv-node-storage-size} +### TiKVノードのストレージサイズ {#tikv-node-ストレージ-size} -さまざまな TiKV vCPU でサポートされているノードstorageサイズは次のとおりです。 +さまざまな TiKV vCPU でサポートされているノードストレージサイズは次のとおりです。 -| TiKV vCPU | 最小ノードstorage | 最大ノードstorage | デフォルトのノードstorage | +| TiKV vCPU | 最小ノードストレージ | 最大ノードストレージ | デフォルトのノードストレージ | | :-------: | :----------: | :----------: | :--------------: | | 4 仮想CPU | 200ギガバイト | 2048ギガバイト | 500ギガバイト | | 8 仮想CPU | 200ギガバイト | 4096ギガバイト | 500ギガバイト | @@ -184,40 +184,40 @@ TiKVノード数が8未満の場合、パフォーマンス偏差係数はほぼ > **注記：** > -> クラスターの作成後に TiKV ノードのstorageサイズを減らすことはできません。 +> クラスターの作成後に TiKV ノードのストレージサイズを減らすことはできません。 -### TiKVノードstorageタイプ {#tikv-node-storage-types} +### TiKVノードストレージタイプ {#tikv-node-ストレージ-types} -TiDB Cloud は、AWS でホストされる[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対して次の TiKVstorageタイプを提供します。 +TiDB Cloud は、AWS でホストされる[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対して次の TiKVストレージタイプを提供します。 -- [基本的なstorage](#basic-storage) -- [標準storage](#standard-storage) -- [パフォーマンスとプラスstorage](#performance-and-plus-storage) +- [基本的なストレージ](#basic-ストレージ) +- [標準ストレージ](#standard-ストレージ) +- [パフォーマンスとプラスストレージ](#performance-and-plus-ストレージ) -#### 基本的なstorage {#basic-storage} +#### 基本的なストレージ {#basic-ストレージ} -ベーシックstorageは、スタンダードstorageよりもパフォーマンスが低い汎用storageタイプです。 +ベーシックストレージは、スタンダードストレージよりもパフォーマンスが低い汎用ストレージタイプです。 -ベーシックstorageタイプは、AWS でホストされている次のクラスターに自動的に適用されます。 +ベーシックストレージタイプは、AWS でホストされている次のクラスターに自動的に適用されます。 - 2025 年 4 月 1 日より前に作成された既存のクラスター。 - v7.5.5、v8.1.2、または v8.5.0 より前のバージョンの TiDB で作成された新しいクラスター。 -#### 標準storage {#standard-storage} +#### 標準ストレージ {#standard-ストレージ} -スタンダードstorageは、パフォーマンスとコスト効率のバランスが取れており、ほとんどのワークロードに最適です。ベーシックstorageと比較して、 Raftログ用に十分なディスクリソースを確保することで、より優れたパフォーマンスを提供します。これにより、 Raft I/OがデータディスクI/Oに与える影響が軽減され、TiKVの読み取りおよび書き込みパフォーマンスが向上します。 +スタンダードストレージは、パフォーマンスとコスト効率のバランスが取れており、ほとんどのワークロードに最適です。ベーシックストレージと比較して、 Raftログ用に十分なディスクリソースを確保することで、より優れたパフォーマンスを提供します。これにより、 Raft I/OがデータディスクI/Oに与える影響が軽減され、TiKVの読み取りおよび書き込みパフォーマンスが向上します。 -標準storageタイプは、AWS でホストされ、TiDB バージョン v7.5.5、v8.1.2、v8.5.0 以降で作成された新しいクラスターに自動的に適用されます。 +標準ストレージタイプは、AWS でホストされ、TiDB バージョン v7.5.5、v8.1.2、v8.5.0 以降で作成された新しいクラスターに自動的に適用されます。 -#### パフォーマンスとプラスstorage {#performance-and-plus-storage} +#### パフォーマンスとプラスストレージ {#performance-and-plus-ストレージ} -パフォーマンスストレージとプラスstorageは、より高いパフォーマンスと安定性を提供し、これらの拡張機能を反映した価格設定となっています。現在、これらの2つのstorageタイプは、AWSにデプロイされたクラスターに対してのみ、リクエストに応じて利用可能です。パフォーマンスストレージまたはプラスstorageをリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**「？」**をクリックし、 **「サポートチケット**」をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に進みます。チケットを作成し、「**説明」**フィールドに「TiKVstorageタイプを申請」と入力して、 **「送信」**をクリックします。 +パフォーマンスストレージとプラスストレージは、より高いパフォーマンスと安定性を提供し、これらの拡張機能を反映した価格設定となっています。現在、これらの2つのストレージタイプは、AWSにデプロイされたクラスターに対してのみ、リクエストに応じて利用可能です。パフォーマンスストレージまたはプラスストレージをリクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**「？」**をクリックし、 **「サポートチケット**」をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に進みます。チケットを作成し、「**説明」**フィールドに「TiKVストレージタイプを申請」と入力して、 **「送信」**をクリックします。 ## サイズTiFlash {#size-tiflash} TiFlashはTiKVからのデータをリアルタイムで同期し、すぐにリアルタイム分析ワークロードをサポートします。水平方向に拡張可能です。 -TiFlashのノード数、vCPU と RAM、storageを構成できます。 +TiFlashのノード数、vCPU と RAM、ストレージを構成できます。 ### TiFlash vCPU と RAM {#tiflash-vcpu-and-ram} @@ -238,15 +238,15 @@ TiFlashノードの最小数は、特定のテーブルのTiFlashレプリカ数 TiFlashノードの最小数: `min((compressed size of table A * replicas for table A + compressed size of table B * replicas for table B) / size of each TiFlash capacity, max(replicas for table A, replicas for table B))` -たとえば、AWS 上の各TiFlashノードのノードstorageを1024 GiB に設定し、テーブル A にレプリカを 2 つ (圧縮サイズは 800 GiB)、テーブル B にレプリカを 1 つ (圧縮サイズは 100 GiB) 設定した場合、必要なTiFlashノードの数は次のようになります。 +たとえば、AWS 上の各TiFlashノードのノードストレージを1024 GiB に設定し、テーブル A にレプリカを 2 つ (圧縮サイズは 800 GiB)、テーブル B にレプリカを 1 つ (圧縮サイズは 100 GiB) 設定した場合、必要なTiFlashノードの数は次のようになります。 TiFlashノードの最小数: `min((800 GiB * 2 + 100 GiB * 1) / 1024 GiB, max(2, 1)) ≈ 2` -### TiFlashノードstorage {#tiflash-node-storage} +### TiFlashノードストレージ {#tiflash-node-ストレージ} -さまざまなTiFlash vCPU でサポートされているノードstorageは次のとおりです。 +さまざまなTiFlash vCPU でサポートされているノードストレージは次のとおりです。 -| TiFlash vCPU | 最小ノードstorage | 最大ノードstorage | デフォルトのノードstorage | +| TiFlash vCPU | 最小ノードストレージ | 最大ノードストレージ | デフォルトのノードストレージ | | :----------: | :----------: | :----------: | :--------------: | | 8 仮想CPU | 200ギガバイト | 4096ギガバイト | 500ギガバイト | | 16 仮想CPU | 200ギガバイト | 4096ギガバイト | 500ギガバイト | @@ -254,19 +254,19 @@ TiFlashノードの最小数: `min((800 GiB * 2 + 100 GiB * 1) / 1024 GiB, max(2 > **注記：** > -> クラスターの作成後にTiFlashノードのstorageを減らすことはできません。 +> クラスターの作成後にTiFlashノードのストレージを減らすことはできません。 -### TiFlashノードstorageタイプ {#tiflash-node-storage-types} +### TiFlashノードストレージタイプ {#tiflash-node-ストレージ-types} -TiDB Cloud は、AWS でホストされる[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対して次のTiFlashstorageタイプを提供します。 +TiDB Cloud は、AWS でホストされる[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対して次のTiFlashストレージタイプを提供します。 -- [基本的なstorage](#basic-storage-1) -- [プラスstorage](#plus-storage) +- [基本的なストレージ](#basic-ストレージ-1) +- [プラスストレージ](#plus-ストレージ) -#### 基本的なstorage {#basic-storage} +#### 基本的なストレージ {#basic-ストレージ} -ベーシックstorageは、パフォーマンスとコスト効率のバランスが取れているため、ほとんどのワークロードに最適です。 +ベーシックストレージは、パフォーマンスとコスト効率のバランスが取れているため、ほとんどのワークロードに最適です。 -#### プラスstorage {#plus-storage} +#### プラスストレージ {#plus-ストレージ} -Plusstorageは、より高いパフォーマンスと安定性を提供し、これらの拡張機能を反映した価格設定となっています。現在、このstorageタイプは、AWSにデプロイされたクラスターに対してのみ、リクエストに応じて利用可能です。リクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**「？」**をクリックし、 **「サポートチケット」**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に進みます。チケットを作成し、 **「説明」**フィールドに「 TiFlashstorageタイプを申請」と入力して、 **「送信」を**クリックしてください。 +Plusストレージは、より高いパフォーマンスと安定性を提供し、これらの拡張機能を反映した価格設定となっています。現在、このストレージタイプは、AWSにデプロイされたクラスターに対してのみ、リクエストに応じて利用可能です。リクエストするには、 [TiDB Cloudコンソール](https://tidbcloud.com)の右下にある**「？」**をクリックし、 **「サポートチケット」**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に進みます。チケットを作成し、 **「説明」**フィールドに「 TiFlashストレージタイプを申請」と入力して、 **「送信」を**クリックしてください。 diff --git a/tidb-cloud/sql-concepts.md b/tidb-cloud/sql-concepts.md index 0139f93920720..0cb594413ad20 100644 --- a/tidb-cloud/sql-concepts.md +++ b/tidb-cloud/sql-concepts.md @@ -39,7 +39,7 @@ TiDBは、行IDの生成とデータ配信を最適化するための3つのSQL - 自動インクリメント -- 自動乱数 +- AUTO_RANDOM - SHARD_ROW_ID_BITS @@ -53,17 +53,17 @@ TiDBは、行IDの生成とデータ配信を最適化するための3つのSQL 詳細については、[自動インクリメント](/auto-increment.md)を参照してください。 -### 自動乱数 {#auto-random} +### AUTO_RANDOM {#auto-random} -`AUTO_RANDOM`は`BIGINT`列に値を自動的に割り当てるために使用される列属性です。自動的に割り当てられる値はランダムで一意です。 `AUTO_RANDOM`の値はランダムで一意であるため、TiDB が連続する ID を割り当てることによって単一のstorageノードで発生する書き込みホットスポットを回避するために、 [`AUTO_INCREMENT`](/auto-increment.md)の代わりに`AUTO_RANDOM`よく使用されます。 +`AUTO_RANDOM`は`BIGINT`列に値を自動的に割り当てるために使用される列属性です。自動的に割り当てられる値はランダムで一意です。 `AUTO_RANDOM`の値はランダムで一意であるため、TiDB が連続する ID を割り当てることによって単一のストレージノードで発生する書き込みホットスポットを回避するために、 [`AUTO_INCREMENT`](/auto-increment.md)の代わりに`AUTO_RANDOM`よく使用されます。 -`AUTO_RANDOM`の値はランダムかつ一意であるため、TiDB が連続する ID を割り当てることによって単一のstorageノードで発生する書き込みホットスポットを回避するために、 [`AUTO_INCREMENT`](/auto-increment.md)の代わりに`AUTO_RANDOM`がよく使用されます。現在の`AUTO_INCREMENT`列が主キーであり、型が`BIGINT`の場合、 `ALTER TABLE t MODIFY COLUMN id BIGINT AUTO_RANDOM(5);`ステートメントを実行して、 `AUTO_INCREMENT`から`AUTO_RANDOM`に切り替えることができます。 +`AUTO_RANDOM`の値はランダムかつ一意であるため、TiDB が連続する ID を割り当てることによって単一のストレージノードで発生する書き込みホットスポットを回避するために、 [`AUTO_INCREMENT`](/auto-increment.md)の代わりに`AUTO_RANDOM`がよく使用されます。現在の`AUTO_INCREMENT`列が主キーであり、型が`BIGINT`の場合、 `ALTER TABLE t MODIFY COLUMN id BIGINT AUTO_RANDOM(5);`ステートメントを実行して、 `AUTO_INCREMENT`から`AUTO_RANDOM`に切り替えることができます。 -詳細については、[自動乱数](/auto-random.md)を参照してください。 +詳細については、[AUTO_RANDOM](/auto-random.md)を参照してください。 ### SHARD_ROW_ID_BITS {#shard-row-id-bits} -クラスタ化されていないプライマリキーまたはプライマリキーのないテーブルの場合、TiDB は暗黙的な自動インクリメント行 ID を使用します。 `INSERT`操作が多数実行されると、データが単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 +クラスター化されていないプライマリキーまたはプライマリキーのないテーブルの場合、TiDB は暗黙的な自動インクリメント行 ID を使用します。 `INSERT`操作が多数実行されると、データが単一のリージョンに書き込まれるため、書き込みホットスポットが発生します。 ホットスポットの問題を軽減するには、 [`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)を設定できます。行 ID は分散しており、データは複数の異なるリージョンに書き込まれます。 diff --git a/tidb-cloud/starter/_index.md b/tidb-cloud/starter/_index.md index b213ed4ab4eda..575b90cb9dcf2 100644 --- a/tidb-cloud/starter/_index.md +++ b/tidb-cloud/starter/_index.md @@ -41,11 +41,11 @@ summary: TiDB Cloudは、 TiDBの優れた機能すべてをクラウドに提 -[クラスタを作成する](https://docs.pingcap.com/tidbcloud/create-tidb-cluster-serverless/?plan=starter) +[クラスターを作成する](https://docs.pingcap.com/tidbcloud/create-tidb-cluster-serverless/?plan=starter) -[クラスタに接続する](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster-serverless/?plan=starter) +[クラスターに接続する](https://docs.pingcap.com/tidbcloud/connect-to-tidb-cluster-serverless/?plan=starter) -[HTAPクラスタを使用する](https://docs.pingcap.com/tidbcloud/tiflash-overview/?plan=starter) +[HTAPクラスターを使用する](https://docs.pingcap.com/tidbcloud/tiflash-overview/?plan=starter) [データのバックアップと復元](https://docs.pingcap.com/tidbcloud/backup-and-restore-serverless/?plan=starter) diff --git a/tidb-cloud/terraform-migrate-cluster-resource.md b/tidb-cloud/terraform-migrate-cluster-resource.md index 8f5f46b70df72..bc1da12659875 100644 --- a/tidb-cloud/terraform-migrate-cluster-resource.md +++ b/tidb-cloud/terraform-migrate-cluster-resource.md @@ -3,7 +3,7 @@ title: Migrate Cluster Resource to Serverless or Dedicated Cluster Resource summary: クラスター リソースをサーバーレスまたは専用のクラスター リソースに移行する方法を学習します。 --- -# クラスタリソースをサーバーレスまたは専用クラスタリソースに移行する {#migrate-cluster-resource-to-serverless-or-dedicated-cluster-resource} +# クラスターリソースをサーバーレスまたは専用クラスターリソースに移行する {#migrate-cluster-resource-to-serverless-or-dedicated-cluster-resource} TiDB Cloud Terraform Provider v0.4.0 以降では、 `tidbcloud_cluster`リソースが`tidbcloud_serverless_cluster`と`tidbcloud_dedicated_cluster` 2 つの新しいリソースに置き換えられます。TiDB Cloud Terraform Provider v0.4.0 以降のバージョンをご利用の場合は、このドキュメントに従って`tidbcloud_cluster`リソースを`tidbcloud_serverless_cluster`または`tidbcloud_dedicated_cluster`リソースに移行できます。 @@ -37,7 +37,7 @@ TiDB Cloud Terraform Provider v0.4.0 以降では、 `tidbcloud_cluster`リソ terraform state rm ${your_target_cluster_resource} ``` -## ステップ3. ターゲットクラスタリソースの構成を削除する {#step-3-delete-the-configuration-of-your-target-cluster-resource} +## ステップ3. ターゲットクラスターリソースの構成を削除する {#step-3-delete-the-configuration-of-your-target-cluster-resource} `.tf`ファイルで、ターゲット クラスター リソースの構成を見つけて、対応するコードを削除します。 diff --git a/tidb-cloud/terraform-use-backup-resource.md b/tidb-cloud/terraform-use-backup-resource.md index e253b87a1454e..21c69839b1694 100644 --- a/tidb-cloud/terraform-use-backup-resource.md +++ b/tidb-cloud/terraform-use-backup-resource.md @@ -44,7 +44,7 @@ summary: tidbcloud_backup` リソースを使用してTiDB Cloudクラスター description = "create by terraform" } - ファイル内のリソース値 (プロジェクト ID やクラスタ ID など) を独自のものに置き換える必要があります。 + ファイル内のリソース値 (プロジェクト ID やクラスター ID など) を独自のものに置き換える必要があります。 Terraform を使用してクラスター リソース (たとえば、 `example_cluster` ) を管理している場合は、実際のプロジェクト ID とクラスター ID を指定せずに、次のように`tidbcloud_backup`リソースを構成することもできます。 diff --git a/tidb-cloud/terraform-use-cluster-resource.md b/tidb-cloud/terraform-use-cluster-resource.md index c8e26378988e4..451bed169dd84 100644 --- a/tidb-cloud/terraform-use-cluster-resource.md +++ b/tidb-cloud/terraform-use-cluster-resource.md @@ -149,7 +149,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを 次の行をクリックすると、参考用の例の結果の一部が表示されます。 -
    クラスタ仕様 +
    クラスター仕様 { "cloud_provider" = "AWS" @@ -185,7 +185,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを "step" = 1 } "node_size" = "8C64G" - "storage_size_gib_range" = { + "ストレージ_size_gib_range" = { "max" = 2048 "min" = 500 } @@ -196,7 +196,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを "step" = 1 } "node_size" = "16C128G" - "storage_size_gib_range" = { + "ストレージ_size_gib_range" = { "max" = 2048 "min" = 500 } @@ -209,7 +209,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを "step" = 3 } "node_size" = "4C16G" - "storage_size_gib_range" = { + "ストレージ_size_gib_range" = { "max" = 2048 "min" = 200 } @@ -220,7 +220,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを "step" = 3 } "node_size" = "8C32G" - "storage_size_gib_range" = { + "ストレージ_size_gib_range" = { "max" = 4096 "min" = 500 } @@ -231,7 +231,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを "step" = 3 } "node_size" = "8C64G" - "storage_size_gib_range" = { + "ストレージ_size_gib_range" = { "max" = 4096 "min" = 500 } @@ -242,7 +242,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを "step" = 3 } "node_size" = "16C64G" - "storage_size_gib_range" = { + "ストレージ_size_gib_range" = { "max" = 4096 "min" = 500 } @@ -258,7 +258,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを - `region`は`cloud_provider`の領域です。 - `node_quantity_range`最小ノード数とノードをスケーリングするステップを示します。 - `node_size`はノードのサイズです。 -- `storage_size_gib_range` 、ノードに設定できる最小および最大のstorageサイズを示します。 +- `ストレージ_size_gib_range` 、ノードに設定できる最小および最大のストレージサイズを示します。 ## クラスターリソースを使用してクラスターを作成する {#create-a-cluster-using-the-cluster-resource} @@ -304,7 +304,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを } tikv = { node_size : "8C32G" - storage_size_gib : 500, + ストレージ_size_gib : 500, node_quantity : 3 } } @@ -337,7 +337,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを + tikv = { + node_quantity = 3 + node_size = "8C32G" - + storage_size_gib = 500 + + ストレージ_size_gib = 500 } } + ip_access_list = [ @@ -405,7 +405,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを tikv = { node_quantity = 3 node_size = "8C32G" - storage_size_gib = 500 + ストレージ_size_gib = 500 } } ip_access_list = [ @@ -445,7 +445,7 @@ summary: クラスター リソースを使用してTiDB Cloudクラスターを tikv = { node_quantity = 3 node_size = "8C32G" - storage_size_gib = 500 + ストレージ_size_gib = 500 } } ip_access_list = [ @@ -484,12 +484,12 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の } tikv = { node_size : "8C32G" - storage_size_gib : 500 + ストレージ_size_gib : 500 node_quantity : 3 } tiflash = { node_size : "8C64G" - storage_size_gib : 500 + ストレージ_size_gib : 500 node_quantity : 1 } } @@ -513,7 +513,7 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の + tiflash = { + node_quantity = 1 + node_size = "8C64G" - + storage_size_gib = 500 + + ストレージ_size_gib = 500 } # (2 unchanged attributes hidden) } @@ -563,12 +563,12 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の tiflash = { node_quantity = 1 node_size = "8C64G" - storage_size_gib = 500 + ストレージ_size_gib = 500 } tikv = { node_quantity = 3 node_size = "8C32G" - storage_size_gib = 500 + ストレージ_size_gib = 500 } } ip_access_list = [ @@ -586,13 +586,13 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の ステータス`MODIFYING` 、クラスターが現在変更中であることを示します。しばらくお待ちください。ステータスは`AVAILABLE`に変更されます。 -### TiDB クラスタをスケールする {#scale-a-tidb-cluster} +### TiDB クラスターをスケールする {#scale-a-tidb-cluster} ステータスが`AVAILABLE`の場合、TiDB クラスターをスケーリングできます。 1. [クラスターを作成する](#create-a-cluster-using-the-cluster-resource)際に使用される`cluster.tf`ファイルで、 `components`構成を編集します。 - たとえば、TiDB 用にさらに 1 つのノード、TiKV 用にさらに 3 つのノード (TiKV ノードの数は、ステップが 3 であるため 3 の倍数である必要があります[クラスタ仕様からこの情報を取得します](#get-cluster-specification-information-using-the-tidbcloud_cluster_specs-data-source)することができます)、およびTiFlash用にさらに 1 つのノードを追加するには、次のように構成を編集します。 + たとえば、TiDB 用にさらに 1 つのノード、TiKV 用にさらに 3 つのノード (TiKV ノードの数は、ステップが 3 であるため 3 の倍数である必要があります[クラスター仕様からこの情報を取得します](#get-cluster-specification-information-using-the-tidbcloud_cluster_specs-data-source)することができます)、およびTiFlash用にさらに 1 つのノードを追加するには、次のように構成を編集します。 components = { tidb = { @@ -601,12 +601,12 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の } tikv = { node_size : "8C32G" - storage_size_gib : 500 + ストレージ_size_gib : 500 node_quantity : 6 } tiflash = { node_size : "8C64G" - storage_size_gib : 500 + ストレージ_size_gib : 500 node_quantity : 2 } } @@ -731,12 +731,12 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の tiflash = { node_quantity = 2 node_size = "8C64G" - storage_size_gib = 500 + ストレージ_size_gib = 500 } tikv = { node_quantity = 6 node_size = "8C32G" - storage_size_gib = 500 + ストレージ_size_gib = 500 } } ip_access_list = [ @@ -777,12 +777,12 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の tiflash = { node_quantity = 2 node_size = "8C64G" - storage_size_gib = 500 + ストレージ_size_gib = 500 } tikv = { node_quantity = 6 node_size = "8C32G" - storage_size_gib = 500 + ストレージ_size_gib = 500 } } ip_access_list = [ @@ -801,7 +801,7 @@ TiDB Cloud Dedicated クラスターの場合、Terraform を使用して次の 6. 少し待ってから、コマンド`terraform refersh`で状態を更新します。最終的にステータスは`AVAILABLE`に変更されます。 -これで、Terraform を使用してTiDB Cloud Dedicated クラスタを作成および管理できました。次に、 [`tidbcloud_backup`](/tidb-cloud/terraform-use-backup-resource.md)リソースでクラスタのバックアップを作成してみましょう。 +これで、Terraform を使用してTiDB Cloud Dedicated クラスターを作成および管理できました。次に、 [`tidbcloud_backup`](/tidb-cloud/terraform-use-backup-resource.md)リソースでクラスターのバックアップを作成してみましょう。 ## クラスターをインポートする {#import-a-cluster} @@ -853,12 +853,12 @@ Terraform で管理されていない TiDB クラスターの場合は、イン tiflash = { node_quantity = 2 node_size = "8C64G" - storage_size_gib = 500 + ストレージ_size_gib = 500 } tikv = { node_quantity = 6 node_size = "8C32G" - storage_size_gib = 500 + ストレージ_size_gib = 500 } } port = 4000 @@ -870,7 +870,7 @@ Terraform で管理されていない TiDB クラスターの場合は、イン status = "AVAILABLE" } -4. Terraformを使用してクラスタを管理するには、前の手順の出力を構成ファイルにコピーします。1 `id`と`status`行目はTerraformによって制御されるため、削除する必要があることに注意してください。 +4. Terraformを使用してクラスターを管理するには、前の手順の出力を構成ファイルにコピーします。1 `id`と`status`行目はTerraformによって制御されるため、削除する必要があることに注意してください。 resource "tidbcloud_cluster" "import_cluster" { cloud_provider = "AWS" @@ -884,12 +884,12 @@ Terraform で管理されていない TiDB クラスターの場合は、イン tiflash = { node_quantity = 2 node_size = "8C64G" - storage_size_gib = 500 + ストレージ_size_gib = 500 } tikv = { node_quantity = 6 node_size = "8C32G" - storage_size_gib = 500 + ストレージ_size_gib = 500 } } port = 4000 diff --git a/tidb-cloud/terraform-use-dedicated-cluster-resource.md b/tidb-cloud/terraform-use-dedicated-cluster-resource.md index bf667f59dac17..8654e5ab3d4cf 100644 --- a/tidb-cloud/terraform-use-dedicated-cluster-resource.md +++ b/tidb-cloud/terraform-use-dedicated-cluster-resource.md @@ -22,7 +22,7 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi ## tidbcloud_projectsデータソースを使用してプロジェクト ID を取得する {#get-project-ids-using-the-code-tidbcloud-projects-code-data-source} -各TiDB Cloud Dedicatedクラスタはプロジェクトに属します。TiDB Cloud Dedicatedクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。1 `project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 +各TiDB Cloud Dedicatedクラスターはプロジェクトに属します。TiDB Cloud Dedicatedクラスターを作成する前に、クラスターを作成するプロジェクトのIDを取得する必要があります。1 `project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データ ソースを使用します。 @@ -157,8 +157,8 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi tikv_node_setting = { node_spec_key = "2C4G" node_count = 3 - storage_size_gi = 60 - storage_type = "Standard" + ストレージ_size_gi = 60 + ストレージ_type = "Standard" } } @@ -205,8 +205,8 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi + node_count = 3 + node_spec_display_name = (known after apply) + node_spec_key = "2C4G" - + storage_size_gi = 60 - + storage_type = "Standard" + + ストレージ_size_gi = 60 + + ストレージ_type = "Standard" } + update_time = (known after apply) + version = (known after apply) @@ -299,8 +299,8 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi node_count = 3 node_spec_display_name = "2 vCPU, 4 GiB" node_spec_key = "2C4G" - storage_size_gi = 60 - storage_type = "Standard" + ストレージ_size_gi = 60 + ストレージ_type = "Standard" } update_time = "2025-06-06 06:31:42.974 +0000 UTC" version = "v7.5.6" @@ -370,8 +370,8 @@ summary: tidbcloud_dedicated_cluster` リソースを使用してTiDB Cloud Dedi node_count = 3 node_spec_display_name = "2 vCPU, 4 GiB" node_spec_key = "2C4G" - storage_size_gi = 60 - storage_type = "Standard" + ストレージ_size_gi = 60 + ストレージ_type = "Standard" } update_time = "2025-06-06 06:31:42.974 +0000 UTC" version = "v7.5.6" @@ -398,7 +398,7 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 tiflash_node_setting = { node_spec_key = "2C4G" node_count = 3 - storage_size_gi = 60 + ストレージ_size_gi = 60 } 2. `terraform apply`コマンドを実行します。 @@ -451,12 +451,12 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 + node_count = 3 + node_spec_display_name = (known after apply) + node_spec_key = "2C4G" - + storage_size_gi = 60 - + storage_type = (known after apply) + + ストレージ_size_gi = 60 + + ストレージ_type = (known after apply) } ~ tikv_node_setting = { ~ node_spec_display_name = "2 vCPU, 4 GiB" -> (known after apply) - ~ storage_type = "Standard" -> (known after apply) + ~ ストレージ_type = "Standard" -> (known after apply) # (3 unchanged attributes hidden) } ~ update_time = "2025-06-06 09:19:01.548 +0000 UTC" -> (known after apply) @@ -540,15 +540,15 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 node_count = 3 node_spec_display_name = "2 vCPU, 4 GiB" node_spec_key = "2C4G" - storage_size_gi = 60 - storage_type = "Basic" + ストレージ_size_gi = 60 + ストレージ_type = "Basic" } tikv_node_setting = { node_count = 3 node_spec_display_name = "2 vCPU, 4 GiB" node_spec_key = "2C4G" - storage_size_gi = 60 - storage_type = "Standard" + ストレージ_size_gi = 60 + ストレージ_type = "Standard" } update_time = "2025-06-06 08:31:42.974 +0000 UTC" version = "v7.5.6" @@ -571,12 +571,12 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 tikv_node_setting = { node_spec_key = "8C32G" node_count = 6 - storage_size_gi = 200 + ストレージ_size_gi = 200 } tiflash_node_setting = { node_spec_key = "8C64G" node_count = 4 - storage_size_gi = 200 + ストレージ_size_gi = 200 } 2. `terraform apply`コマンドを実行し、確認のために`yes`入力します。 @@ -626,13 +626,13 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 ~ tiflash_node_setting = { ~ node_count = 3 -> 4 ~ node_spec_display_name = "8 vCPU, 64 GiB" -> (known after apply) - ~ storage_type = "Basic" -> (known after apply) + ~ ストレージ_type = "Basic" -> (known after apply) # (2 unchanged attributes hidden) } ~ tikv_node_setting = { ~ node_count = 3 -> 6 ~ node_spec_display_name = "8 vCPU, 32 GiB" -> (known after apply) - ~ storage_type = "Standard" -> (known after apply) + ~ ストレージ_type = "Standard" -> (known after apply) # (2 unchanged attributes hidden) } ~ update_time = "2025-06-09 09:29:25.678 +0000 UTC" -> (known after apply) @@ -715,12 +715,12 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 } ~ tiflash_node_setting = { ~ node_spec_display_name = "8 vCPU, 64 GiB" -> (known after apply) - ~ storage_type = "Basic" -> (known after apply) + ~ ストレージ_type = "Basic" -> (known after apply) # (3 unchanged attributes hidden) } ~ tikv_node_setting = { ~ node_spec_display_name = "8 vCPU, 32 GiB" -> (known after apply) - ~ storage_type = "Standard" -> (known after apply) + ~ ストレージ_type = "Standard" -> (known after apply) # (3 unchanged attributes hidden) } ~ update_time = "2025-06-09 10:01:59.65 +0000 UTC" -> (known after apply) @@ -796,8 +796,8 @@ TiDB Cloud Dedicated クラスターの場合、次のように Terraform を使 node_count = 3 node_spec_display_name = "2 vCPU, 4 GiB" node_spec_key = "2C4G" - storage_size_gi = 60 - storage_type = "Standard" + ストレージ_size_gi = 60 + ストレージ_type = "Standard" } update_time = "2025-06-06 06:31:42.974 +0000 UTC" version = "v7.5.6" @@ -1138,15 +1138,15 @@ TiDB Cloud Dedicated クラスターを削除するには、 `tidbcloud_dedicate - node_count = 4 -> null - node_spec_display_name = "8 vCPU, 64 GiB" -> null - node_spec_key = "8C64G" -> null - - storage_size_gi = 200 -> null - - storage_type = "Basic" -> null + - ストレージ_size_gi = 200 -> null + - ストレージ_type = "Basic" -> null } -> null - tikv_node_setting = { - node_count = 6 -> null - node_spec_display_name = "8 vCPU, 32 GiB" -> null - node_spec_key = "8C32G" -> null - - storage_size_gi = 200 -> null - - storage_type = "Standard" -> null + - ストレージ_size_gi = 200 -> null + - ストレージ_type = "Standard" -> null } -> null - update_time = "2025-06-06 14:15:29.609 +0000 UTC" -> null - version = "v7.5.6" -> null diff --git a/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md b/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md index b9b96ca44751e..75c7a092a9e10 100644 --- a/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md +++ b/tidb-cloud/terraform-use-dedicated-private-endpoint-connection-resource.md @@ -20,7 +20,7 @@ summary: tidbcloud_dedicated_private_endpoint_connection` リソースを使用 ## 前提条件 {#prerequisites} - [TiDB Cloud Terraform プロバイダーを入手する](/tidb-cloud/terraform-get-tidbcloud-provider.md) v0.4.0以降。 -- [TiDB Cloud専用クラスタを作成する](/tidb-cloud/create-tidb-cluster.md) 。 +- [TiDB Cloud専用クラスターを作成する](/tidb-cloud/create-tidb-cluster.md) 。 ## TiDB Cloud Dedicatedプライベートエンドポイント接続を作成する {#create-a-tidb-cloud-dedicated-private-endpoint-connection} @@ -55,7 +55,7 @@ summary: tidbcloud_dedicated_private_endpoint_connection` リソースを使用 - `tidbcloud_dedicated_private_endpoint_connection`リソースを使用するには、リソース タイプを`tidbcloud_dedicated_private_endpoint_connection`に設定します。 - リソース名は必要に応じて定義できます。例： `example` 。 - - 必要な引数の値を取得する方法がわからない場合は、 [AWS のプライベートエンドポイント経由でTiDB Cloud専用クラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 + - 必要な引数の値を取得する方法がわからない場合は、 [AWS のプライベートエンドポイント経由でTiDB Cloud専用クラスターに接続する](/tidb-cloud/set-up-private-endpoint-connections.md)参照してください。 - TiDB Cloud Dedicated プライベート エンドポイント接続仕様情報を取得するには、 [tidbcloud_private_endpoint_connection (リソース)](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/dedicated_private_endpoint_connection)参照してください。 3. `terraform apply`コマンドを実行します。リソースを適用する場合は`terraform apply --auto-approve`の使用は推奨されません。 diff --git a/tidb-cloud/terraform-use-import-resource.md b/tidb-cloud/terraform-use-import-resource.md index 025e55ed7ed0e..6ad1074855546 100644 --- a/tidb-cloud/terraform-use-import-resource.md +++ b/tidb-cloud/terraform-use-import-resource.md @@ -18,7 +18,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク - [TiDB Cloud Terraform プロバイダーを入手する](/tidb-cloud/terraform-get-tidbcloud-provider.md) 。 - TiDB Cloudクラスターを作成するには、次のいずれかのドキュメントを参照してください。 - [TiDB Cloud Starter または Essential クラスターを作成する](/tidb-cloud/create-tidb-cluster-serverless.md) - - [TiDB Cloud専用クラスタを作成する](/tidb-cloud/create-tidb-cluster.md) 。 + - [TiDB Cloud専用クラスターを作成する](/tidb-cloud/create-tidb-cluster.md) 。 ## インポートタスクを作成して実行する {#create-and-run-an-import-task} @@ -66,7 +66,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク file_name = "your_csv_path" } - ファイル内のリソース値（プロジェクトID、クラスタID、CSVパスなど）をご自身のものに置き換えてください。1 の詳細は`csv_format` [設定ページ](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/import#nested-schema-for-csv_format)記載されています。 + ファイル内のリソース値（プロジェクトID、クラスターID、CSVパスなど）をご自身のものに置き換えてください。1 の詳細は`csv_format` [設定ページ](https://registry.terraform.io/providers/tidbcloud/tidbcloud/latest/docs/resources/import#nested-schema-for-csv_format)記載されています。 3. `terraform apply`コマンドを実行してインポート タスクを作成し、 `yes`入力して作成を確認し、インポートを開始します。 @@ -179,7 +179,7 @@ summary: tidbcloud_import` リソースを使用してインポート タスク > **注記：** > -> TiDB Cloud がAmazon S3 バケット内のファイルにアクセスできるようにするには、まず[Amazon S3 アクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)実行する必要があります。 +> TiDB Cloud がAmazon S3 バケット内のファイルにアクセスできるようにするには、まず[Amazon S3 アクセスを構成する](/tidb-cloud/dedicated-external-ストレージ.md#configure-amazon-s3-access)実行する必要があります。 1. ディレクトリ`import`を作成し、その中にディレクトリ`main.tf`を作成します。例: diff --git a/tidb-cloud/terraform-use-restore-resource.md b/tidb-cloud/terraform-use-restore-resource.md index 575f4c1ab0889..8e9f4587646a9 100644 --- a/tidb-cloud/terraform-use-restore-resource.md +++ b/tidb-cloud/terraform-use-restore-resource.md @@ -56,12 +56,12 @@ summary: tidbcloud_restore` リソースを使用して復元タスクを作成 } tikv = { node_size : "8C32G" - storage_size_gib : 500 + ストレージ_size_gib : 500 node_quantity : 6 } tiflash = { node_size : "8C64G" - storage_size_gib : 500 + ストレージ_size_gib : 500 node_quantity : 2 } } @@ -97,12 +97,12 @@ summary: tidbcloud_restore` リソースを使用して復元タスクを作成 + tiflash = { + node_quantity = 2 + node_size = "8C64G" - + storage_size_gib = 500 + + ストレージ_size_gib = 500 } + tikv = { + node_quantity = 6 + node_size = "8C32G" - + storage_size_gib = 500 + + ストレージ_size_gib = 500 } } + port = 4000 @@ -151,12 +151,12 @@ summary: tidbcloud_restore` リソースを使用して復元タスクを作成 tiflash = { node_quantity = 2 node_size = "8C64G" - storage_size_gib = 500 + ストレージ_size_gib = 500 } tikv = { node_quantity = 6 node_size = "8C32G" - storage_size_gib = 500 + ストレージ_size_gib = 500 } } port = 4000 @@ -175,7 +175,7 @@ summary: tidbcloud_restore` リソースを使用して復元タスクを作成 6. クラスターのステータスが`AVAILABLE`に変わると、復元タスクは`RUNNING`なり、最終的に`SUCCESS`になります。 -復元されたクラスタはTerraformによって管理されないことに注意してください。復元されたクラスタは[輸入する](/tidb-cloud/terraform-use-cluster-resource.md#import-a-cluster)で管理できます。 +復元されたクラスターはTerraformによって管理されないことに注意してください。復元されたクラスターは[輸入する](/tidb-cloud/terraform-use-cluster-resource.md#import-a-cluster)で管理できます。 ## 復元タスクを更新する {#update-a-restore-task} diff --git a/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md b/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md index d584723af812a..d23e1d80cda69 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource-manage-essential.md @@ -22,7 +22,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Ess ## tidbcloud_projectsデータソースを使用してプロジェクト ID を取得する {#get-project-ids-using-the-code-tidbcloud-projects-code-data-source} -各TiDBクラスタはプロジェクトに属します。TiDB Cloud Essentialクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。1 `project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 +各TiDBクラスターはプロジェクトに属します。TiDB Cloud Essentialクラスターを作成する前に、クラスターを作成するプロジェクトのIDを取得する必要があります。1 `project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データ ソースを使用します。 @@ -289,7 +289,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Ess ## TiDB Cloud Essential クラスターを変更する {#modify-a-tidb-cloud-essential-cluster} -TiDB Cloud Essential クラスタでは、Terraform を使用してリソースを管理できます。変更可能な引数は次のとおりです。 +TiDB Cloud Essential クラスターでは、Terraform を使用してリソースを管理できます。変更可能な引数は次のとおりです。 - `display_name` : クラスターの表示名。 - `auto_scaling` : クラスターの自動スケーリング構成。 diff --git a/tidb-cloud/terraform-use-serverless-cluster-resource.md b/tidb-cloud/terraform-use-serverless-cluster-resource.md index 3f7aee1734114..b04ce4b4b90de 100644 --- a/tidb-cloud/terraform-use-serverless-cluster-resource.md +++ b/tidb-cloud/terraform-use-serverless-cluster-resource.md @@ -22,7 +22,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Sta ## tidbcloud_projectsデータソースを使用してプロジェクト ID を取得する {#get-project-ids-using-the-code-tidbcloud-projects-code-data-source} -各TiDBクラスタはプロジェクトに属します。TiDB Cloud Starterクラスタを作成する前に、クラスタを作成するプロジェクトのIDを取得する必要があります。1 `project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 +各TiDBクラスターはプロジェクトに属します。TiDB Cloud Starterクラスターを作成する前に、クラスターを作成するプロジェクトのIDを取得する必要があります。1 `project_id`指定されていない場合は、デフォルトのプロジェクトが使用されます。 利用可能なすべてのプロジェクトに関する情報を取得するには、次のように`tidbcloud_projects`データ ソースを使用します。 @@ -286,7 +286,7 @@ summary: tidbcloud_serverless_cluster` リソースを使用してTiDB Cloud Sta ## TiDB Cloud Starter クラスターを変更する {#modify-a-tidb-cloud-starter-cluster} -TiDB Cloud Starterクラスタでは、Terraformを使用してリソースを管理できます。変更可能な引数は次のとおりです。 +TiDB Cloud Starterクラスターでは、Terraformを使用してリソースを管理できます。変更可能な引数は次のとおりです。 - `display_name` : クラスターの表示名。 - `spending_limit` : クラスターの使用制限。 diff --git a/tidb-cloud/terraform-use-sql-user-resource.md b/tidb-cloud/terraform-use-sql-user-resource.md index 0449cd18c6aee..f19f253fbc452 100644 --- a/tidb-cloud/terraform-use-sql-user-resource.md +++ b/tidb-cloud/terraform-use-sql-user-resource.md @@ -19,7 +19,7 @@ summary: tidbcloud_sql_user` リソースを使用してTiDB Cloud SQL ユーザ - [TiDB Cloud Terraform プロバイダーを入手する](/tidb-cloud/terraform-get-tidbcloud-provider.md) v0.4.0以降。 - TiDB Cloudクラスターを作成するには、次のいずれかのドキュメントを参照してください。 - [TiDB Cloud Starter または Essential クラスターを作成する](/tidb-cloud/create-tidb-cluster-serverless.md) - - [TiDB Cloud専用クラスタを作成する](/tidb-cloud/create-tidb-cluster.md) 。 + - [TiDB Cloud専用クラスターを作成する](/tidb-cloud/create-tidb-cluster.md) 。 ## SQLユーザーを作成する {#create-a-sql-user} diff --git a/tidb-cloud/ticloud-auth-login.md b/tidb-cloud/ticloud-auth-login.md index 88b7c2c6bfbd9..ab3b633f3136e 100644 --- a/tidb-cloud/ticloud-auth-login.md +++ b/tidb-cloud/ticloud-auth-login.md @@ -19,10 +19,10 @@ TiDB Cloudにログインするには: ticloud auth login ``` -安全でないstorageを使用してTiDB Cloudにログインするには: +安全でないストレージを使用してTiDB Cloudにログインするには: ```shell -ticloud auth login --insecure-storage +ticloud auth login --insecure-ストレージ ``` ## 旗 {#flags} diff --git a/tidb-cloud/ticloud-branch-create.md b/tidb-cloud/ticloud-branch-create.md index 95fb633010470..d0a5fe33edaaa 100644 --- a/tidb-cloud/ticloud-branch-create.md +++ b/tidb-cloud/ticloud-branch-create.md @@ -39,7 +39,7 @@ ticloud serverless branch create --cluster-id --display-name --region --max- | -p, --project-id 文字列 | クラスターが作成されるプロジェクトのIDを指定します。デフォルト値は`default project`です。 | いいえ | 非対話型モードでのみ動作します。 | | -r, --region 文字列 | クラウドリージョンの名前を指定します。1 コマンド`ticloud serverless region`使用すると、利用可能なすべてのリージョンを表示できます。 | はい | 非対話型モードでのみ動作します。 | | --パブリックエンドポイントを無効にする | パブリックエンドポイントを無効にします。クラスターへのパブリックアクセスを禁止する場合は、このオプションを使用します。 | いいえ | 非対話型モードでのみ動作します。 | -| --暗号化 | 二重層データ暗号化を有効にします。TiDB Cloud Essential クラスタではデフォルトで有効、 TiDB Cloud Starter クラスタではデフォルトで無効になっています。 | いいえ | 非対話型モードでのみ動作します。 | +| --暗号化 | 二重層データ暗号化を有効にします。TiDB Cloud Essential クラスターではデフォルトで有効、 TiDB Cloud Starter クラスターではデフォルトで無効になっています。 | いいえ | 非対話型モードでのみ動作します。 | | --max-rcu int32 | TiDB Cloud Essential クラスターの最大リクエスト容量単位 (RCU) を 100000 まで設定します。 | いいえ | 非対話型モードでのみ動作します。 | | --min-rcu int32 | TiDB Cloud Essential クラスターの最小リクエスト容量単位 (RCU) を少なくとも 2000 に設定します。 | いいえ | 非対話型モードでのみ動作します。 | | -h, --help | このコマンドのヘルプ情報を表示します。 | いいえ | 非対話型モードと対話型モードの両方で動作します | diff --git a/tidb-cloud/ticloud-serverless-audit-log-config-update.md b/tidb-cloud/ticloud-serverless-audit-log-config-update.md index 78f38f7b06ff5..d9d633b61cdd7 100644 --- a/tidb-cloud/ticloud-serverless-audit-log-config-update.md +++ b/tidb-cloud/ticloud-serverless-audit-log-config-update.md @@ -25,10 +25,10 @@ ticloud serverless audit-log config update ticloud serverless audit-log config update -c --unredacted ``` -非対話型モードで Amazon S3storageを使用してデータベース監査ログを有効にします。 +非対話型モードで Amazon S3ストレージを使用してデータベース監査ログを有効にします。 ```shell -ticloud serverless audit-log config update -c --enabled --cloud-storage S3 --s3.uri --s3.access-key-id --s3.secret-access-key +ticloud serverless audit-log config update -c --enabled --cloud-ストレージ S3 --s3.uri --s3.access-key-id --s3.secret-access-key ``` 非対話型モードでデータベース監査ログのローテーション戦略を構成します。 @@ -49,7 +49,7 @@ ticloud serverless audit-log config update -c --enabled=false | --------------------------- | ------------------------------------------------------------------------------------------------------------ | --- | ------------------------------------ | | --azblob.sas-token 文字列 | Azure Blob Storage の SAS トークン。 | いいえ | 非対話型モードでのみ動作します。 | | --azblob.uri 文字列 | `azure://.blob.core.windows.net//`形式の Azure Blob Storage URI。 | いいえ | 非対話型モードでのみ動作します。 | -| --クラウドストレージ文字列 | クラウドstorage`"GCS"` 。 `"AZURE_BLOB"` `"OSS"`オプション: `"TIDB_CLOUD"` `"S3"` | いいえ | 非対話型モードでのみ動作します。 | +| --クラウドストレージ文字列 | クラウドストレージ`"GCS"` 。 `"AZURE_BLOB"` `"OSS"`オプション: `"TIDB_CLOUD"` `"S3"` | いいえ | 非対話型モードでのみ動作します。 | | -c, --cluster-id 文字列 | 更新するクラスターの ID。 | はい | 非対話型モードでのみ動作します。 | | --有効 | データベース監査ログを有効または無効にします。 | いいえ | 非対話型モードでのみ動作します。 | | --gcs.サービスアカウントキー文字列 | Google Cloud Storage の Base64 でエンコードされたサービス アカウント キー。 | いいえ | 非対話型モードでのみ動作します。 | diff --git a/tidb-cloud/ticloud-serverless-export-create.md b/tidb-cloud/ticloud-serverless-export-create.md index 4587519dc2a3e..dca3d6aef23d8 100644 --- a/tidb-cloud/ticloud-serverless-export-create.md +++ b/tidb-cloud/ticloud-serverless-export-create.md @@ -31,7 +31,7 @@ ticloud serverless export create -c --filter ticloud serverless export create -c --s3.uri --s3.access-key-id --s3.secret-access-key --filter ``` -非対話型モードでTiDB Cloud Starter またはTiDB Cloud Essential クラスタから Google Cloud Storage にデータをエクスポートします。 +非対話型モードでTiDB Cloud Starter またはTiDB Cloud Essential クラスターから Google Cloud Storage にデータをエクスポートします。 ```shell ticloud serverless export create -c --gcs.uri --gcs.service-account-key --filter diff --git a/tidb-cloud/ticloud-serverless-export-download.md b/tidb-cloud/ticloud-serverless-export-download.md index 70758a07846d1..4b8c0bc86ec2d 100644 --- a/tidb-cloud/ticloud-serverless-export-download.md +++ b/tidb-cloud/ticloud-serverless-export-download.md @@ -5,7 +5,7 @@ summary: ticloud serverless export download` のリファレンス。 # ticloud サーバーレスエクスポートのダウンロード {#ticloud-serverless-export-download} -TiDB Cloud Starter またはTiDB Cloud Essential クラスターからエクスポートされたデータをローカルstorageにダウンロードします。 +TiDB Cloud Starter またはTiDB Cloud Essential クラスターからエクスポートされたデータをローカルストレージにダウンロードします。 ```shell ticloud serverless export download [flags] diff --git a/tidb-cloud/tidb-cloud-auditing.md b/tidb-cloud/tidb-cloud-auditing.md index ac095a3155489..3e89f5f35643b 100644 --- a/tidb-cloud/tidb-cloud-auditing.md +++ b/tidb-cloud/tidb-cloud-auditing.md @@ -32,7 +32,7 @@ TiDB Cloud は、実行された SQL ステートメントなど、データベ ## 監査ログを有効にする {#enable-audit-logging} -TiDB Cloudは、 TiDB Cloud Dedicatedクラスタの監査ログをクラウドstorageサービスに記録することをサポートしています。データベース監査ログを有効にする前に、クラスタが配置されているクラウドプロバイダーでクラウドstorageサービスを設定してください。 +TiDB Cloudは、 TiDB Cloud Dedicatedクラスターの監査ログをクラウドストレージサービスに記録することをサポートしています。データベース監査ログを有効にする前に、クラスターが配置されているクラウドプロバイダーでクラウドストレージサービスを設定してください。 > **注記：** > @@ -68,9 +68,9 @@ TiDB Cloud が監査ログを書き込む宛先として、組織所有の AWS 4. **「データベース監査ログの有効化」**ダイアログで、 **AWS IAMポリシー設定**セクションを見つけて、後で使用するために**TiDB Cloudアカウント ID**と**TiDB Cloud外部 ID**を記録します。 -2. AWS マネジメントコンソールで、 **IAM** >**アクセス管理**>**ポリシー**に移動し、書き込み専用権限`s3:PutObject`を持つstorageバケットポリシーがあるかどうかを確認します。 +2. AWS マネジメントコンソールで、 **IAM** >**アクセス管理**>**ポリシー**に移動し、書き込み専用権限`s3:PutObject`を持つストレージバケットポリシーがあるかどうかを確認します。 - - はいの場合は、後で使用するために一致したstorageバケット ポリシーを記録します。 + - はいの場合は、後で使用するために一致したストレージバケット ポリシーを記録します。 - そうでない場合は、 **「IAM」** > **「アクセス管理」** > **「ポリシー」** > **「ポリシーの作成」**に移動し、次のポリシー テンプレートに従ってバケット ポリシーを定義します。 ```json @@ -129,11 +129,11 @@ Google Cloud の監査ログを有効にするには、次の手順に従いま TiDB Cloud が監査ログを書き込む宛先として、組織所有の Google Cloud アカウント内の Google Cloud Storage（GCS）バケットを指定します。 -詳細については、Google Cloud Storage ドキュメントの[storageバケットの作成](https://cloud.google.com/storage/docs/creating-buckets)ご覧ください。 +詳細については、Google Cloud Storage ドキュメントの[ストレージバケットの作成](https://cloud.google.com/ストレージ/docs/creating-buckets)ご覧ください。 #### ステップ2. GCSアクセスを構成する {#step-2-configure-gcs-access} -1. 監査ログを有効にする TiDB クラスタの Google Cloud サービス アカウント ID を取得します。 +1. 監査ログを有効にする TiDB クラスターの Google Cloud サービス アカウント ID を取得します。 1. TiDB Cloudコンソールで、プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動します。 @@ -147,10 +147,10 @@ TiDB Cloud が監査ログを書き込む宛先として、組織所有の Googl 4. **[データベース監査ログを有効にする]**ダイアログで、 **[Google Cloud Server アカウント ID]**セクションを見つけて、後で使用するために**サービス アカウント ID**を記録します。 -2. Google Cloud コンソールで、 **[IAMと管理]** > **[ロール]**に移動し、storageコンテナの次の書き込み専用権限を持つロールが存在するかどうかを確認します。 +2. Google Cloud コンソールで、 **[IAMと管理]** > **[ロール]**に移動し、ストレージコンテナの次の書き込み専用権限を持つロールが存在するかどうかを確認します。 - - storage.objects.create - - storage.オブジェクト.削除 + - ストレージ.objects.create + - ストレージ.オブジェクト.削除 はいの場合は、後で使用するためにTiDBクラスターの一致したロールを記録してください。いいえの場合は、 **「IAMと管理」** > **「ロール」** > **「ロールの作成」**に移動して、TiDBクラスターのロールを定義してください。 @@ -164,7 +164,7 @@ TiDB Cloud が監査ログを書き込む宛先として、組織所有の Googl 5. ダイアログ ボックスで、次の手順を実行します。 - 1. **[新しいプリンシパル]**フィールドに、TiDB クラスタの Google Cloud サービス アカウント ID を貼り付けます。 + 1. **[新しいプリンシパル]**フィールドに、TiDB クラスターの Google Cloud サービス アカウント ID を貼り付けます。 2. **[ロール]**ドロップダウン リストで、ターゲット TiDB クラスターのロールを選択します。 3. **[保存]**をクリックします。 @@ -182,34 +182,34 @@ TiDB Cloudコンソールで、 TiDB Cloudアカウント ID を取得した**[ 4. クラスターの監査ログを有効にするには、 **[有効]**をクリックします。 - TiDB Cloud は、指定されたクラスタの監査ログを GCS バケットに書き込む準備が整いました。 + TiDB Cloud は、指定されたクラスターの監査ログを GCS バケットに書き込む準備が整いました。 > **注記：** > > - 監査ログを有効にした後、バケットのURIまたは場所に新たな変更を加えた場合は、 **「接続テスト」**を再度クリックして、TiDB Cloudがバケットに接続できることを確認してください。その後、 **「有効化」**をクリックして変更を適用してください。 -> - TiDB Cloud の GCS バケットへのアクセスを削除するには、Google Cloud コンソールでこのクラスタに付与された信頼ポリシーを削除します。 +> - TiDB Cloud の GCS バケットへのアクセスを削除するには、Google Cloud コンソールでこのクラスターに付与された信頼ポリシーを削除します。 ### Azureの監査ログを有効にする {#enable-audit-logging-for-azure} Azure の監査ログを有効にするには、次の手順を実行します。 -#### ステップ1. Azurestorageアカウントを作成する {#step-1-create-an-azure-storage-account} +#### ステップ1. Azureストレージアカウントを作成する {#step-1-create-an-azure-ストレージ-account} -TiDB Cloudがデータベース監査ログを書き込む宛先として、組織の Azure サブスクリプションに Azurestorageアカウントを作成します。 +TiDB Cloudがデータベース監査ログを書き込む宛先として、組織の Azure サブスクリプションに Azureストレージアカウントを作成します。 -詳細については、Azure ドキュメントの[Azurestorageアカウントを作成する](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-create?tabs=azure-portal)参照してください。 +詳細については、Azure ドキュメントの[Azureストレージアカウントを作成する](https://learn.microsoft.com/en-us/azure/ストレージ/common/ストレージ-account-create?tabs=azure-portal)参照してください。 -#### ステップ2. Azure Blob Storageアクセスを構成する {#step-2-configure-azure-blob-storage-access} +#### ステップ2. Azure Blob Storageアクセスを構成する {#step-2-configure-azure-blob-ストレージ-access} 1. [Azureポータル](https://portal.azure.com/)で、データベース監査ログを保存するために使用するコンテナを作成します。 - 1. Azure ポータルの左側のナビゲーション ウィンドウで、 **[ストレージ アカウント]**をクリックし、データベース監査ログを保存するstorageアカウントをクリックします。 + 1. Azure ポータルの左側のナビゲーション ウィンドウで、 **[ストレージ アカウント]**をクリックし、データベース監査ログを保存するストレージアカウントをクリックします。 > **ヒント：** > > 左側のナビゲーション ペインが非表示になっている場合は、左上隅のメニュー ボタンをクリックして表示を切り替えます。 - 2. 選択したstorageアカウントのナビゲーション ウィンドウで、 **[データstorage] > [コンテナー]**をクリックし、 **[+ コンテナー]**をクリックして**[新しいコンテナー]**ウィンドウを開きます。 + 2. 選択したストレージアカウントのナビゲーション ウィンドウで、 **[データストレージ] > [コンテナー]**をクリックし、 **[+ コンテナー]**をクリックして**[新しいコンテナー]**ウィンドウを開きます。 3. **「新しいコンテナ」**ペインで、新しいコンテナの名前を入力し、匿名アクセスレベル（推奨レベルは**「プライベート」** （匿名アクセスなし））を設定して、 **「作成」**をクリックします。数秒以内に新しいコンテナが作成され、コンテナリストに表示されます。 @@ -230,7 +230,7 @@ TiDB Cloudがデータベース監査ログを書き込む宛先として、組 > **注記：** > - > - 監査機能はstorageアカウントに監査ログを継続的に書き込む必要があるため、SASトークンの有効期間は十分に長くなければなりません。ただし、有効期間が長すぎるとトークン漏洩のリスクが高まります。セキュリティ上、SASトークンは6～12か月ごとに交換することをお勧めします。 + > - 監査機能はストレージアカウントに監査ログを継続的に書き込む必要があるため、SASトークンの有効期間は十分に長くなければなりません。ただし、有効期間が長すぎるとトークン漏洩のリスクが高まります。セキュリティ上、SASトークンは6～12か月ごとに交換することをお勧めします。 > - 生成された SAS トークンは取り消すことができないため、有効期間を慎重に設定する必要があります。 > - 監査ログの継続的な可用性を確保するために、SAS トークンの有効期限が切れる前に必ず再生成して更新してください。 @@ -250,7 +250,7 @@ TiDB Cloudがデータベース監査ログを書き込む宛先として、組 3. **DB 監査ログ**ページで、右上隅の**[有効化]**をクリックします。 -4. **データベース監査ログの有効化**ダイアログで、 [ステップ2. Azure BLOBアクセスを構成する](#step-2-configure-azure-blob-storage-access)から取得した BLOB URL と SAS トークンを指定します。 +4. **データベース監査ログの有効化**ダイアログで、 [ステップ2. Azure BLOBアクセスを構成する](#step-2-configure-azure-blob-ストレージ-access)から取得した BLOB URL と SAS トークンを指定します。 - **「Blob URL」**フィールドに、監査ログが保存されるコンテナの URL を入力します。 - **SAS トークン**フィールドに、コンテナーにアクセスするための SAS トークンを入力します。 @@ -286,7 +286,7 @@ TiDB Cloudがデータベース監査ログを書き込む宛先として、組 ## 監査ログをビュー {#view-audit-logs} -デフォルトでは、 TiDB Cloud はデータベース監査ログ ファイルをstorageサービスに保存するため、storageサービスから監査ログ情報を読み取る必要があります。 +デフォルトでは、 TiDB Cloud はデータベース監査ログ ファイルをストレージサービスに保存するため、ストレージサービスから監査ログ情報を読み取る必要があります。 > **注記：** > @@ -302,7 +302,7 @@ TiDB Cloud監査ログは、クラスター ID、ノード ID、およびログ > **注記：** > -> ログファイルのサイズが10MiBに達するたびに、ログファイルはクラウドstorageバケットにプッシュされます。そのため、監査ログを無効化した後は、10MiB未満のログファイルはクラウドstorageバケットに自動的にプッシュされなくなります。この状況でログファイルを取得するには、 [PingCAPサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 +> ログファイルのサイズが10MiBに達するたびに、ログファイルはクラウドストレージバケットにプッシュされます。そのため、監査ログを無効化した後は、10MiB未満のログファイルはクラウドストレージバケットに自動的にプッシュされなくなります。この状況でログファイルを取得するには、 [PingCAPサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 ## 監査ログフィールド {#audit-log-fields} diff --git a/tidb-cloud/tidb-cloud-billing.md b/tidb-cloud/tidb-cloud-billing.md index 5dc2a9732327c..1bc100cab6ded 100644 --- a/tidb-cloud/tidb-cloud-billing.md +++ b/tidb-cloud/tidb-cloud-billing.md @@ -23,7 +23,7 @@ TiDB Cloud Essentialでは、アプリケーションの実際の使用量で** ### TiDB Cloud Premium の価格設定 {#pricing-for-premium} {#pricing-for-premium} -TiDB Cloud Premium の場合、基礎となるバックエンド ノードやプロビジョニングされたディスク サイズではなく、実際の[要求容量単位（RCU）](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu)消費量と実際に使用するstorageに基づいて請求されます。 [TiDB Cloud Premiumの料金詳細](https://www.pingcap.com/tidb-cloud-premium-pricing-details/)ご覧ください。 +TiDB Cloud Premium の場合、基礎となるバックエンド ノードやプロビジョニングされたディスク サイズではなく、実際の[要求容量単位（RCU）](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu)消費量と実際に使用するストレージに基づいて請求されます。 [TiDB Cloud Premiumの料金詳細](https://www.pingcap.com/tidb-cloud-premium-pricing-details/)ご覧ください。 ## 請求書 {#invoices} @@ -49,7 +49,7 @@ TiDB Cloud Premium の場合、基礎となるバックエンド ノードやプ お客様が弊社の営業担当に連絡して月次請求書の発行を依頼すると、 TiDB Cloudは毎月初めに前月分の請求書を自動的に作成します。 -請求金額には、TiDBリソースの使用消費量、割引、バックアップstorage費用、サポートサービス費用、クレジット消費量、および組織内のデータ送信費用が含まれます。 +請求金額には、TiDBリソースの使用消費量、割引、バックアップストレージ費用、サポートサービス費用、クレジット消費量、および組織内のデータ送信費用が含まれます。 毎月の請求書ごとに： @@ -73,7 +73,7 @@ TiDB Cloud Premium の場合、基礎となるバックエンド ノードやプ 組織内で`Organization Owner`または`Organization Billing Manager`の役割を担っている場合は、 TiDB Cloudの請求詳細を表示およびエクスポートできます。それ以外の場合は、このセクションをスキップしてください。 -支払い方法を設定すると、 TiDB Cloudは過去の月の請求書と請求明細を生成し、毎月初めに当月の請求明細を生成します。請求明細には、組織のTiDBリソース使用量、割引、バックアップstorage費用、データ転送費用、サポートサービス費用、クレジット消費量、プロジェクト分割情報などが含まれます。 +支払い方法を設定すると、 TiDB Cloudは過去の月の請求書と請求明細を生成し、毎月初めに当月の請求明細を生成します。請求明細には、組織のTiDBリソース使用量、割引、バックアップストレージ費用、データ転送費用、サポートサービス費用、クレジット消費量、プロジェクト分割情報などが含まれます。 > **注記：** > diff --git a/tidb-cloud/tidb-cloud-clinic.md b/tidb-cloud/tidb-cloud-clinic.md index a3cd1364debc3..a8473a2eb59ee 100644 --- a/tidb-cloud/tidb-cloud-clinic.md +++ b/tidb-cloud/tidb-cloud-clinic.md @@ -17,15 +17,15 @@ TiDB Cloud Clinic は、 TiDB Cloud上で高度な監視および診断機能を TiDB Cloud Clinic は、**エンタープライズ**または**プレミアム**サポート プランに加入している組織のみが利用できます。 -## クラスタページをビュー {#view-the-cluster-page} +## クラスターページをビュー {#view-the-cluster-page} -**クラスタ**ページを表示するには、次の手順を実行します。 +**クラスター**ページを表示するには、次の手順を実行します。 1. [TiDB Cloudクリニック コンソール](https://clinic.pingcap.com/)にログインし、 **「TiDB アカウントで続行」**を選択して、 TiDB Cloudログイン ページに入ります。 2. 組織リストから対象の組織を選択します。選択したプロジェクト内のクラスターが表示されます。 -3. ターゲットクラスタの名前をクリックします。クラスタの概要ページが表示され、クラスタに関する以下の詳細情報を確認できます。 +3. ターゲットクラスターの名前をクリックします。クラスターの概要ページが表示され、クラスターに関する以下の詳細情報を確認できます。 - 高度なメトリクス - 最も遅いクエリ（クラスターの TiDB バージョンが v8.1.1 以降、v7.5.4 以降の場合にのみサポートされます） @@ -38,7 +38,7 @@ TiDB Cloud ClinicはGrafanaを使用して、TiDBクラスターの包括的な メトリクス ダッシュボードを表示するには、次の手順を実行します。 -1. [TiDB Cloudクリニック コンソール](https://clinic.pingcap.com/)で、クラスターの**「クラスタ」**ページに移動します。 +1. [TiDB Cloudクリニック コンソール](https://clinic.pingcap.com/)で、クラスターの**「クラスター」**ページに移動します。 2. **[メトリック]**をクリックします。 @@ -63,7 +63,7 @@ TiDB Cloud ClinicはGrafanaを使用して、TiDBクラスターの包括的な デフォルトでは、300 ミリ秒を超える時間がかかる SQL クエリは遅いクエリと見なされます。 -TiDB Cloudコンソールのデフォルトの[**遅いクエリ**](/tidb-cloud/tune-performance.md#slow-query)ページでは、パフォーマンスに影響を与えるクエリを特定することが困難になる場合があります。特に、スロークエリが多数存在するクラスタではなおさらです。TiDB Cloud Clinicの**「Top Slow Queries」**機能は、スロークエリのログに基づいて集計分析を提供します。この機能により、パフォーマンスに問題のあるクエリを簡単に特定できるため、全体的なパフォーマンスチューニング時間を少なくとも半分に短縮できます。 +TiDB Cloudコンソールのデフォルトの[**遅いクエリ**](/tidb-cloud/tune-performance.md#slow-query)ページでは、パフォーマンスに影響を与えるクエリを特定することが困難になる場合があります。特に、スロークエリが多数存在するクラスターではなおさらです。TiDB Cloud Clinicの**「Top Slow Queries」**機能は、スロークエリのログに基づいて集計分析を提供します。この機能により、パフォーマンスに問題のあるクエリを簡単に特定できるため、全体的なパフォーマンスチューニング時間を少なくとも半分に短縮できます。 上位の低速クエリには、SQL ダイジェストによって集計された上位 10 件のクエリが、次のディメンションで並べ替えられて表示されます。 @@ -77,7 +77,7 @@ TiDB Cloudコンソールのデフォルトの[**遅いクエリ**](/tidb-cloud/ クラスター内の遅いクエリを表示するには、次の手順を実行します。 -1. [TiDB Cloudクリニック コンソール](https://clinic.pingcap.com/)で、クラスターの**「クラスタ」**ページに移動します。 +1. [TiDB Cloudクリニック コンソール](https://clinic.pingcap.com/)で、クラスターの**「クラスター」**ページに移動します。 2. **[スロー クエリ]**をクリックします。 @@ -97,7 +97,7 @@ TiDB Cloud ClinicはTopSQL情報を提供し、データベース内の各SQL文 TopSQL を表示するには、次の手順を実行します。 -1. [TiDB Cloudクリニック コンソール](https://clinic.pingcap.com/)で、クラスターの**「クラスタ」**ページに移動します。 +1. [TiDB Cloudクリニック コンソール](https://clinic.pingcap.com/)で、クラスターの**「クラスター」**ページに移動します。 2. **TopSQL**をクリックします。 @@ -109,11 +109,11 @@ TopSQL を表示するには、次の手順を実行します。 ## ベンチマークレポートを生成する {#generate-benchmark-reports} -**ベンチマークレポート**機能は、パフォーマンステスト中にTiDBクラスタのパフォーマンス問題を特定するのに役立ちます。ストレステストを完了すると、ベンチマークレポートを生成してクラスタのパフォーマンスを分析できます。レポートでは、特定されたボトルネックが強調表示され、最適化の提案が提供されます。これらの提案を適用した後、もう一度ストレステストを実行し、新しいベンチマークレポートを生成してパフォーマンスの改善を比較できます。 +**ベンチマークレポート**機能は、パフォーマンステスト中にTiDBクラスターのパフォーマンス問題を特定するのに役立ちます。ストレステストを完了すると、ベンチマークレポートを生成してクラスターのパフォーマンスを分析できます。レポートでは、特定されたボトルネックが強調表示され、最適化の提案が提供されます。これらの提案を適用した後、もう一度ストレステストを実行し、新しいベンチマークレポートを生成してパフォーマンスの改善を比較できます。 ベンチマーク レポートを生成するには、次の手順を実行します。 -1. [TiDB Cloudクリニック コンソール](https://clinic.pingcap.com/)で、クラスターの**「クラスタ」**ページに移動します。 +1. [TiDB Cloudクリニック コンソール](https://clinic.pingcap.com/)で、クラスターの**「クラスター」**ページに移動します。 2. **ベンチマークレポート**をクリックします。 diff --git a/tidb-cloud/tidb-cloud-connect-aws-dms.md b/tidb-cloud/tidb-cloud-connect-aws-dms.md index 1024b6ef4d374..f75476e47be43 100644 --- a/tidb-cloud/tidb-cloud-connect-aws-dms.md +++ b/tidb-cloud/tidb-cloud-connect-aws-dms.md @@ -21,7 +21,7 @@ DMS関連リソースを管理するための十分なアクセス権を持つAW TiDB Cloudアカウントと、 TiDB Cloud Starter、 TiDB Cloud Essential、またはTiDB Cloud Dedicated クラスターをお持ちであることが前提となります。お持ちでない場合は、以下のドキュメントを参照して作成してください。 - [TiDB Cloud Starter または Essential クラスターを作成する](/tidb-cloud/create-tidb-cluster-serverless.md) -- [TiDB Cloud専用クラスタを作成する](/tidb-cloud/create-tidb-cluster.md) +- [TiDB Cloud専用クラスターを作成する](/tidb-cloud/create-tidb-cluster.md) ## ネットワークを構成する {#configure-network} @@ -37,7 +37,7 @@ TiDB Cloud Starter またはTiDB Cloud Essential の場合、クライアント - [パブリックエンドポイント経由でTiDB Cloud Starter または Essential クラスターに接続する](/tidb-cloud/connect-via-standard-connection-serverless.md)場合、次のいずれかを実行して、DMS レプリケーション インスタンスがインターネットにアクセスできることを確認します。 - - レプリケーションインスタンスをパブリックサブネットにデプロイ、 **「パブリックアクセス**可能」を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)参照してください。 + - レプリケーションインスタンスをパブリックサブネットにデプロイ、 **「パブリックアクセス**可能」を有効にします。詳細については、 [インターネットアクセスの設定](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)参照してください。 - レプリケーションインスタンスをプライベートサブネットにデプロイ、プライベートサブネット内のトラフィックをパブリックサブネットにルーティングします。この場合、少なくとも3つのサブネット（プライベートサブネット2つとパブリックサブネット1つ）が必要です。2つのプライベートサブネットは、レプリケーションインスタンスが存在するサブネットグループを形成します。次に、パブリックサブネットにNATゲートウェイを作成し、2つのプライベートサブネットのトラフィックをNATゲートウェイにルーティングする必要があります。詳細については、 [プライベートサブネットからインターネットにアクセスする](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html#public-nat-internet-access)参照してください。 @@ -52,7 +52,7 @@ TiDB Cloud Starter またはTiDB Cloud Essential の場合、クライアント - [パブリックエンドポイント経由でTiDB Cloud Starter または Essential クラスターに接続する](/tidb-cloud/connect-via-standard-connection-serverless.md)場合、次のいずれかを実行して、DMS レプリケーション インスタンスがインターネットにアクセスできることを確認します。 - - レプリケーションインスタンスをパブリックサブネットにデプロイ、 **「パブリックアクセス**可能」を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)参照してください。 + - レプリケーションインスタンスをパブリックサブネットにデプロイ、 **「パブリックアクセス**可能」を有効にします。詳細については、 [インターネットアクセスの設定](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)参照してください。 - レプリケーションインスタンスをプライベートサブネットにデプロイ、プライベートサブネット内のトラフィックをパブリックサブネットにルーティングします。この場合、少なくとも3つのサブネット（プライベートサブネット2つとパブリックサブネット1つ）が必要です。2つのプライベートサブネットは、レプリケーションインスタンスが存在するサブネットグループを形成します。次に、パブリックサブネットにNATゲートウェイを作成し、2つのプライベートサブネットのトラフィックをNATゲートウェイにルーティングする必要があります。詳細については、 [プライベートサブネットからインターネットにアクセスする](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html#public-nat-internet-access)参照してください。 @@ -68,7 +68,7 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド - [パブリックエンドポイント経由でTiDB Cloud Dedicated クラスターに接続する](/tidb-cloud/connect-via-standard-connection.md)については、DMS レプリケーションインスタンスがインターネットにアクセスできることを確認するために、次のいずれかを実行します。さらに、レプリケーションインスタンスまたは NAT ゲートウェイのパブリック IP アドレスをクラスターの[IPアクセスリスト](/tidb-cloud/configure-ip-access-list.md)に追加する必要があります。 - - レプリケーションインスタンスをパブリックサブネットにデプロイ、 **「パブリックアクセス**可能」を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)参照してください。 + - レプリケーションインスタンスをパブリックサブネットにデプロイ、 **「パブリックアクセス**可能」を有効にします。詳細については、 [インターネットアクセスの設定](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html#vpc-igw-internet-access)参照してください。 - レプリケーションインスタンスをプライベートサブネットにデプロイ、プライベートサブネット内のトラフィックをパブリックサブネットにルーティングします。この場合、少なくとも3つのサブネット（プライベートサブネット2つとパブリックサブネット1つ）が必要です。2つのプライベートサブネットは、レプリケーションインスタンスが存在するサブネットグループを形成します。次に、パブリックサブネットにNATゲートウェイを作成し、2つのプライベートサブネットのトラフィックをNATゲートウェイにルーティングする必要があります。詳細については、 [プライベートサブネットからインターネットにアクセスする](https://docs.aws.amazon.com/vpc/latest/userguide/nat-gateway-scenarios.html#public-nat-internet-access)参照してください。 @@ -94,7 +94,7 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド - **エンジン バージョン**: デフォルト構成を維持します。 - **高可用性**: ビジネス ニーズに応じて、**マルチ AZ**または**シングル AZ**を選択します。 -5. **割り当てられたstorage(GiB)**フィールドでstorageを構成します。 +5. **割り当てられたストレージ(GiB)**フィールドでストレージを構成します。 6. 接続とセキュリティを設定します。ネットワーク設定については[前のセクション](#configure-network)を参照してください。 @@ -144,7 +144,7 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド - **サーバー名**: TiDB Cloud専用クラスターの`HOST` 。 - **ポート**: TiDB Cloud Dedicated クラスターの`PORT` 。 - - **ユーザー名**：移行用のTiDB Cloud専用クラスタのユーザー。DMS要件を満たしていることを確認してください。 + - **ユーザー名**：移行用のTiDB Cloud専用クラスターのユーザー。DMS要件を満たしていることを確認してください。 - **パスワード**: TiDB Cloud Dedicated クラスター ユーザーのパスワード。 - **セキュリティ Socket Layer (SSL) モード**：パブリックエンドポイント経由で接続する場合は、トランスポートセキュリティを確保するために、モードを**verify-full**に設定することを強くお勧めします。プライベートエンドポイント経由で接続する場合は、 **none**に設定できます。 - (オプション) **CA 証明書**: [TiDB Cloud DedicatedへのTLS接続](/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md)に従って CA 証明書を取得します。 diff --git a/tidb-cloud/tidb-cloud-console-auditing.md b/tidb-cloud/tidb-cloud-console-auditing.md index c417db27862e9..eb3e7ba74c3ed 100644 --- a/tidb-cloud/tidb-cloud-console-auditing.md +++ b/tidb-cloud/tidb-cloud-console-auditing.md @@ -53,13 +53,13 @@ TiDB Cloudは、 [TiDB Cloudコンソール](https://tidbcloud.com)上のユー 3. （オプション）コンソール監査ログの特定の部分をエクスポートする必要がある場合は、さまざまな条件でフィルタリングできます。それ以外の場合は、この手順をスキップしてください。 4. **「ログのダウンロード」**をクリックし、JSON または CSV で希望のエクスポート形式を選択します。 -## コンソール監査ログstorageポリシー {#console-audit-log-storage-policy} +## コンソール監査ログストレージポリシー {#console-audit-log-ストレージ-policy} -コンソール監査ログのstorage期間は 90 日間で、その後はログは自動的にクリーンアップされます。 +コンソール監査ログのストレージ期間は 90 日間で、その後はログは自動的にクリーンアップされます。 > **注記：** > -> - TiDB Cloudではコンソール監査ログのstorage場所を指定できません。 +> - TiDB Cloudではコンソール監査ログのストレージ場所を指定できません。 > - 監査ログを手動で削除することはできません。 ## コンソール監査イベントの種類 {#console-audit-event-types} @@ -127,15 +127,15 @@ TiDB Cloudは、 [TiDB Cloudコンソール](https://tidbcloud.com)上のユー | スケールクラスター | クラスターをスケールする | | TiDBClusterCA をダウンロード | CA証明書をダウンロード | | オープンWebSQLコンソール | Web SQL 経由で TiDB クラスターに接続する | -| ルートパスワードの設定 | TiDBクラスタのルートパスワードを設定する | -| IPアクセスリストの更新 | TiDB クラスタの IP アクセス リストを更新する | -| 自動バックアップの設定 | TiDBクラスタの自動バックアップメカニズムを設定する | -| 手動バックアップ | TiDBクラスタの手動バックアップを実行する | +| ルートパスワードの設定 | TiDBクラスターのルートパスワードを設定する | +| IPアクセスリストの更新 | TiDB クラスターの IP アクセス リストを更新する | +| 自動バックアップの設定 | TiDBクラスターの自動バックアップメカニズムを設定する | +| 手動バックアップ | TiDBクラスターの手動バックアップを実行する | | バックアップ完了 | バックアップタスクが完了しました | | バックアップタスクの削除 | バックアップタスクを削除する | | バックアップの削除 | バックアップファイルを削除する | -| バックアップからの復元 | バックアップファイルに基づいてTiDBクラスタに復元する | -| ゴミ箱から復元 | ゴミ箱内のバックアップファイルに基づいてTiDBクラスタに復元する | +| バックアップからの復元 | バックアップファイルに基づいてTiDBクラスターに復元する | +| ゴミ箱から復元 | ゴミ箱内のバックアップファイルに基づいてTiDBクラスターに復元する | | AWSからのデータのインポート | AWSからデータをインポートする | | GCPからのデータのインポート | Google Cloud からデータをインポートする | | ローカルからのデータのインポート | ローカルディスクからデータをインポートする | @@ -179,8 +179,8 @@ TiDB Cloudは、 [TiDB Cloudコンソール](https://tidbcloud.com)上のユー | 組織名 | 弦 | イベントが属する組織名 | | プロジェクトID | uint64 | イベントが属するプロジェクトID | | プロジェクト名 | 弦 | イベントが属するプロジェクト名 | -| クラスターID | uint64 | イベントが属するクラスタID | -| クラスター名 | 弦 | イベントが属するクラスタ名 | +| クラスターID | uint64 | イベントが属するクラスターID | +| クラスター名 | 弦 | イベントが属するクラスター名 | | トレースID | 弦 | オペレータによって開始されたリクエストのトレースID。このフィールドは現在空ですが、将来のリリースで利用可能になる予定です。 | | 結果 | 列挙型 | イベント結果: `success`または`failure` | | 詳細 | JSON | イベントの詳細な説明 | diff --git a/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md b/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md index 2359b9883ef1d..b7e24e8ad9aa7 100644 --- a/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md +++ b/tidb-cloud/tidb-cloud-dm-precheck-and-troubleshooting.md @@ -16,14 +16,14 @@ summary: データ移行時に発生する事前チェックエラー、移行 ### エラーメッセージ: mysql server_id が 0 より大きいかどうかを確認してください {#error-message-check-whether-mysql-server-id-has-been-greater-than-0} - Amazon Aurora MySQL または Amazon RDS: `server_id`はデフォルトで設定されています。設定する必要はありません。フルデータ移行と増分データ移行の両方をサポートするには、Amazon Aurora MySQL ライターインスタンスを使用していることを確認してください。 -- MySQL: MySQL 用に`server_id`を構成するには、 [レプリケーションソースコンフィグレーションの設定](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html)参照してください。 +- MySQL: MySQL 用に`server_id`を構成するには、 [レプリケーションソース設定の設定](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html)参照してください。 ### エラーメッセージ: mysql binlogが有効になっているか確認してください {#error-message-check-whether-mysql-binlog-is-enabled} - Amazon Aurora MySQL: [Amazon Aurora MySQL互換クラスターでバイナリログを有効にするにはどうすればよいですか？](https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/?nc1=h_ls)を参照してください。完全データ移行と増分データ移行の両方をサポートするには、Amazon Aurora MySQL ライター インスタンスを使用していることを確認してください。 - Amazon RDS: [MySQLバイナリログの設定](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html)参照してください。 - Google Cloud SQL for MySQL: Google は、MySQL マスター データベースのポイントインタイムリカバリを通じてバイナリ ロギングを可能にします。 [特定時点へのリカバリを有効にする](https://cloud.google.com/sql/docs/mysql/backup-recovery/pitr#enablingpitr)参照してください。 -- MySQL: [レプリケーションソースコンフィグレーションの設定](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html)参照してください。 +- MySQL: [レプリケーションソース設定の設定](https://dev.mysql.com/doc/refman/8.0/en/replication-howto-masterbaseconfig.html)参照してください。 ### エラーメッセージ: mysql binlog_format が ROW かどうか確認してください {#error-message-check-whether-mysql-binlog-format-is-row} @@ -74,15 +74,15 @@ TiDB Cloudクラスターでエラーが発生した場合は、ドキュメン ### 移行タスクが中断され、「ドライバー: 接続不良」または「無効な接続」というエラーが含まれています。 {#the-migration-task-is-interrupted-and-contains-the-error-driver-bad-connection-or-invalid-connection} -このエラーは、ダウンストリームの TiDB クラスタへの接続に失敗したことを意味します。ダウンストリームの TiDB クラスタが正常な状態（ `Available`および`Modifying`を含む）であり、ジョブで指定されたユーザー名とパスワードで接続できるかどうかを確認してください。ダウンストリームの TiDB クラスタが利用可能であることを確認したら、 **[再起動]**をクリックしてタスクを再開してみてください。 +このエラーは、ダウンストリームの TiDB クラスターへの接続に失敗したことを意味します。ダウンストリームの TiDB クラスターが正常な状態（ `Available`および`Modifying`を含む）であり、ジョブで指定されたユーザー名とパスワードで接続できるかどうかを確認してください。ダウンストリームの TiDB クラスターが利用可能であることを確認したら、 **[再起動]**をクリックしてタスクを再開してみてください。 -### エラーメッセージ：「指定されたユーザー名とパスワードを使用してTiDBクラスタに接続できませんでした。TiDBクラスタが起動しており、指定されたユーザー名とパスワードで接続できることを確認してください。」 {#error-message-failed-to-connect-to-the-tidb-cluster-using-the-given-user-and-password-please-make-sure-tidb-cluster-is-up-and-can-be-connected-to-using-the-given-user-and-password} +### エラーメッセージ：「指定されたユーザー名とパスワードを使用してTiDBクラスターに接続できませんでした。TiDBクラスターが起動しており、指定されたユーザー名とパスワードで接続できることを確認してください。」 {#error-message-failed-to-connect-to-the-tidb-cluster-using-the-given-user-and-password-please-make-sure-tidb-cluster-is-up-and-can-be-connected-to-using-the-given-user-and-password} TiDB クラスターへの接続に失敗しました。TiDB クラスターが正常な状態（ `Available`および`Modifying`を含む）であるかどうかを確認することをお勧めします。ジョブで指定されたユーザー名とパスワードを使用して接続できます。TiDB クラスターが利用可能であることを確認したら、 **[再起動]**をクリックしてタスクを再開してみてください。 -### エラーメッセージ：「TiDBクラスタのstorageが不足しています。TiKVのノードstorageを増やしてください。」 {#error-message-tidb-cluster-storage-is-not-enough-please-increase-the-node-storage-of-tikv} +### エラーメッセージ：「TiDBクラスターのストレージが不足しています。TiKVのノードストレージを増やしてください。」 {#error-message-tidb-cluster-ストレージ-is-not-enough-please-increase-the-node-ストレージ-of-tikv} -TiDB クラスターのstorageが不足しています。 [TiKVノードのstorageを増やす](/tidb-cloud/scale-tidb-cluster.md#change-storage)から、 **「再起動」**をクリックしてタスクを再開することをお勧めします。 +TiDB クラスターのストレージが不足しています。 [TiKVノードのストレージを増やす](/tidb-cloud/scale-tidb-cluster.md#change-ストレージ)から、 **「再起動」**をクリックしてタスクを再開することをお勧めします。 ### エラーメッセージ：「ソースデータベースへの接続に失敗しました。データベースが利用可能か、または最大接続数に達していないかを確認してください。」 {#error-message-failed-to-connect-to-the-source-database-please-check-whether-the-database-is-available-or-the-maximum-connections-have-been-reached} @@ -90,7 +90,7 @@ TiDB クラスターのstorageが不足しています。 [TiKVノードのstora ### エラーメッセージ：「エラー 1273: 新しい照合順序が有効になっている場合、サポートされていない照合順序です: 'utf8mb4_0900_ai_ci'」 {#error-message-error-1273-unsupported-collation-when-new-collation-is-enabled-utf8mb4-0900-ai-ci} -ダウンストリームのTiDBクラスタでスキーマを作成できませんでした。このエラーは、アップストリームのMySQLで使用されている照合順序がTiDBクラスタでサポートされていないことを意味します。 +ダウンストリームのTiDBクラスターでスキーマを作成できませんでした。このエラーは、アップストリームのMySQLで使用されている照合順序がTiDBクラスターでサポートされていないことを意味します。 この問題を解決するには、 [サポートされている照合順序](/character-set-and-collation.md#character-sets-and-collations-supported-by-tidb)に基づいて TiDB クラスターにスキーマを作成し、 **[再起動]**をクリックしてタスクを再開します。 diff --git a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md index 1d3b583dfc66e..9e6b9e7650909 100644 --- a/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md +++ b/tidb-cloud/tidb-cloud-encrypt-cmek-aws.md @@ -6,9 +6,9 @@ aliases: ['/ja/tidbcloud/tidb-cloud-encrypt-cmek'] # AWS での顧客管理の暗号化キーを使用した保存時の暗号化 {#encryption-at-rest-using-customer-managed-encryption-keys-on-aws} -顧客管理暗号鍵（CMEK）を使用すると、完全に管理可能な対称暗号鍵を利用して、 TiDB Cloud Dedicated クラスタ内の静的データを保護できます。この鍵はCMEK鍵と呼ばれます。 +顧客管理暗号鍵（CMEK）を使用すると、完全に管理可能な対称暗号鍵を利用して、 TiDB Cloud Dedicated クラスター内の静的データを保護できます。この鍵はCMEK鍵と呼ばれます。 -プロジェクトでCMEKを有効にすると、そのプロジェクト内で作成されるすべてのクラスタは、CMEK鍵を使用して静的データを暗号化します。さらに、これらのクラスタによって生成されるバックアップデータも同じ鍵を使用して暗号化されます。CMEKが有効になっていない場合、 TiDB Cloudはエスクロー鍵を使用して、クラスタ内のすべての保存データを暗号化します。 +プロジェクトでCMEKを有効にすると、そのプロジェクト内で作成されるすべてのクラスターは、CMEK鍵を使用して静的データを暗号化します。さらに、これらのクラスターによって生成されるバックアップデータも同じ鍵を使用して暗号化されます。CMEKが有効になっていない場合、 TiDB Cloudはエスクロー鍵を使用して、クラスター内のすべての保存データを暗号化します。 > **注記：** > @@ -17,10 +17,10 @@ aliases: ['/ja/tidbcloud/tidb-cloud-encrypt-cmek'] ## 制限 {#restrictions} - 現在、 TiDB Cloud はCMEK を提供するために AWS KMS と Azure Key Vault の使用のみをサポートしています。 -- CMEK を使用するには、プロジェクトの作成時に CMEK を有効にし、クラスタを作成する前に CMEK 関連の設定を完了する必要があります。既存のプロジェクトでは CMEK を有効にできません。 +- CMEK を使用するには、プロジェクトの作成時に CMEK を有効にし、クラスターを作成する前に CMEK 関連の設定を完了する必要があります。既存のプロジェクトでは CMEK を有効にできません。 - 現在、CMEK 対応プロジェクトでは、AWS と Azure でホストされるクラスターを[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)つだけ作成できます。 - 現在、CMEK 対応プロジェクトでは、 [デュアルリージョンバックアップ](/tidb-cloud/backup-and-restore-concepts.md#dual-region-backup)サポートされていません。 -- 現在、CMEK 対応プロジェクトでは、AWS と Azure で CMEK を有効化できます。クラウドプロバイダーごとに、リージョンごとに 1 つの固有の暗号化キーを設定できます。選択したクラウドプロバイダーの暗号化キーを設定したリージョンでのみ、クラスタを作成できます。 +- 現在、CMEK 対応プロジェクトでは、AWS と Azure で CMEK を有効化できます。クラウドプロバイダーごとに、リージョンごとに 1 つの固有の暗号化キーを設定できます。選択したクラウドプロバイダーの暗号化キーを設定したリージョンでのみ、クラスターを作成できます。 ## CMEKを有効にする {#enable-cmek} @@ -143,7 +143,7 @@ TiDB Cloudコンソールまたは API を使用して、プロジェクトの C ### ステップ3. クラスターを作成する {#step-3-create-a-cluster} -[ステップ1](#step-1-create-a-cmek-enabled-project)で作成したプロジェクトの下に、AWS でホストされるTiDB Cloud Dedicated クラスターを作成します。詳細な手順については[TiDB Cloud専用クラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。クラスターが配置されているリージョンが[ステップ2](#step-2-complete-the-cmek-configuration-of-the-project)と同じであることを確認してください。 +[ステップ1](#step-1-create-a-cmek-enabled-project)で作成したプロジェクトの下に、AWS でホストされるTiDB Cloud Dedicated クラスターを作成します。詳細な手順については[TiDB Cloud専用クラスターを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。クラスターが配置されているリージョンが[ステップ2](#step-2-complete-the-cmek-configuration-of-the-project)と同じであることを確認してください。 > **注記：** > diff --git a/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md b/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md index 21f7ca5afa1f5..0226abf0b65db 100644 --- a/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md +++ b/tidb-cloud/tidb-cloud-encrypt-cmek-azure.md @@ -5,17 +5,17 @@ summary: 顧客管理暗号化キー (CMEK) を使用して、Azure でホスト # Azure での顧客管理の暗号化キーを使用した保存時の暗号化 {#encryption-at-rest-using-customer-managed-encryption-keys-on-azure} -顧客管理暗号鍵（CMEK）を使用すると、完全に管理可能な対称暗号鍵を利用して、 TiDB Cloud Dedicated クラスタ内の静的データを保護できます。この鍵はCMEK鍵と呼ばれます。 +顧客管理暗号鍵（CMEK）を使用すると、完全に管理可能な対称暗号鍵を利用して、 TiDB Cloud Dedicated クラスター内の静的データを保護できます。この鍵はCMEK鍵と呼ばれます。 -プロジェクトでCMEKを有効にすると、そのプロジェクト内で作成されるすべてのクラスタは、CMEK鍵を使用して静的データを暗号化します。さらに、これらのクラスタによって生成されるバックアップデータも同じ鍵を使用して暗号化されます。CMEKが有効になっていない場合、 TiDB Cloudはエスクロー鍵を使用して、クラスタ内のすべての保存データを暗号化します。 +プロジェクトでCMEKを有効にすると、そのプロジェクト内で作成されるすべてのクラスターは、CMEK鍵を使用して静的データを暗号化します。さらに、これらのクラスターによって生成されるバックアップデータも同じ鍵を使用して暗号化されます。CMEKが有効になっていない場合、 TiDB Cloudはエスクロー鍵を使用して、クラスター内のすべての保存データを暗号化します。 ## 制限 {#restrictions} - 現在、 TiDB Cloud はCMEK を提供するために AWS KMS と Azure Key Vault の使用のみをサポートしています。 -- CMEK を使用するには、プロジェクトの作成時に CMEK を有効にし、クラスタを作成する前に CMEK 関連の設定を完了する必要があります。既存のプロジェクトでは CMEK を有効にできません。 +- CMEK を使用するには、プロジェクトの作成時に CMEK を有効にし、クラスターを作成する前に CMEK 関連の設定を完了する必要があります。既存のプロジェクトでは CMEK を有効にできません。 - 現在、CMEK 対応プロジェクトでは、AWS と Azure でホストされるクラスターを[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)つだけ作成できます。 - 現在、CMEK 対応プロジェクトでは、 [デュアルリージョンバックアップ](/tidb-cloud/backup-and-restore-concepts.md#dual-region-backup)サポートされていません。 -- 現在、CMEK 対応プロジェクトでは、AWS と Azure で CMEK を有効化できます。クラウドプロバイダーごとに、リージョンごとに 1 つの固有の暗号化キーを設定できます。選択したクラウドプロバイダーの暗号化キーを設定したリージョンでのみ、クラスタを作成できます。 +- 現在、CMEK 対応プロジェクトでは、AWS と Azure で CMEK を有効化できます。クラウドプロバイダーごとに、リージョンごとに 1 つの固有の暗号化キーを設定できます。選択したクラウドプロバイダーの暗号化キーを設定したリージョンでのみ、クラスターを作成できます。 ## CMEKを有効にする {#enable-cmek} @@ -130,13 +130,13 @@ TiDB Cloudコンソールと Azure Resource Manager を使用して CMEK を構 ### ステップ3. クラスターを作成する {#step-3-create-a-cluster} -[ステップ1](#step-1-create-a-cmek-enabled-project)で作成したプロジェクトの下に、Azure でホストされるTiDB Cloud Dedicated クラスターを作成します。詳細な手順については、 [TiDB Cloud専用クラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 +[ステップ1](#step-1-create-a-cmek-enabled-project)で作成したプロジェクトの下に、Azure でホストされるTiDB Cloud Dedicated クラスターを作成します。詳細な手順については、 [TiDB Cloud専用クラスターを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 クラウドプロバイダーとリージョンを選択すると、適切な暗号化キーが自動的に選択されます。プロバイダーとリージョンで利用可能な暗号化キーがない場合は、コンソールに暗号化キーの作成に役立つヒントが表示されます。 > **注記：** > -> CMEK が有効になっている場合、 TiDB Cloud は、クラスター ノードで使用される Premium SSD v2 とクラスター バックアップ用のstorageBLOB の両方を CMEK で暗号化します。 +> CMEK が有効になっている場合、 TiDB Cloud は、クラスター ノードで使用される Premium SSD v2 とクラスター バックアップ用のストレージBLOB の両方を CMEK で暗号化します。 ## CMEKを回転させる {#rotate-cmek} diff --git a/tidb-cloud/tidb-cloud-events.md b/tidb-cloud/tidb-cloud-events.md index 016254b2dd67b..b7878a399433a 100644 --- a/tidb-cloud/tidb-cloud-events.md +++ b/tidb-cloud/tidb-cloud-events.md @@ -3,9 +3,9 @@ title: TiDB Cloud Cluster Events summary: イベント ページを使用してTiDB Cloudクラスターのイベントを表示する方法を学習します。 --- -# TiDB Cloudクラスタイベント {#tidb-cloud-cluster-events} +# TiDB Cloudクラスターイベント {#tidb-cloud-cluster-events} -TiDB Cloudは、クラスタレベルで過去のイベントを記録します。*イベントは、* TiDB Cloudクラスタにおける変化を示します。記録されたイベントは、 **「イベント」**ページで確認できます。イベントの種類、ステータス、メッセージ、トリガー時刻、トリガーユーザーなどの情報が表示されます。 +TiDB Cloudは、クラスターレベルで過去のイベントを記録します。*イベントは、* TiDB Cloudクラスターにおける変化を示します。記録されたイベントは、 **「イベント」**ページで確認できます。イベントの種類、ステータス、メッセージ、トリガー時刻、トリガーユーザーなどの情報が表示されます。 このドキュメントでは**、[イベント]**ページを使用してTiDB Cloudクラスターのイベントを表示する方法について説明し、サポートされているイベント タイプを一覧表示します。 @@ -30,10 +30,10 @@ TiDB Cloud は、次の種類のクラスター イベントをログに記録 | クラスターの作成 | クラスターを作成する | | 一時停止クラスター | クラスターを一時停止する | | 履歴書クラスター | クラスターを再開する | -| クラスタサイズの変更 | クラスターサイズを変更する | +| クラスターサイズの変更 | クラスターサイズを変更する | | バックアップクラスター | クラスターをバックアップする | | エクスポートバックアップ | バックアップをエクスポートする | -| クラスタからの復元 | クラスターを復元する | +| クラスターからの復元 | クラスターを復元する | | 変更フィードを作成 | チェンジフィードを作成する | | 一時停止変更フィード | チェンジフィードを一時停止する | | 履歴書変更フィード | チェンジフィードを再開する | diff --git a/tidb-cloud/tidb-cloud-faq.md b/tidb-cloud/tidb-cloud-faq.md index 3c0d068844b10..b1fc9b6169e0b 100644 --- a/tidb-cloud/tidb-cloud-faq.md +++ b/tidb-cloud/tidb-cloud-faq.md @@ -15,13 +15,13 @@ summary: TiDB Cloudに関するよくある質問（FAQ）について学びま TiDB Cloud、直感的なコンソールを通じて制御できるフルマネージドのクラウド インスタンスにより、TiDB クラスターのデプロイ、管理、保守がさらに簡単になります。 Amazon Web Services (AWS)、Google Cloud、Microsoft Azure、またはAlibaba Cloudに簡単にデプロイして、ミッションクリティカルなアプリケーションを迅速に構築できます。 Amazon Web Services (AWS)、Google Cloud、またはMicrosoft Azureに簡単にデプロイすることで、ミッションクリティカルなアプリケーションを迅速に構築できます。 -TiDB Cloud を利用すれば、開発者や DBA は、トレーニングをほとんど受けていないか、全く受けていない場合でも、インフラストラクチャ管理やクラスタのデプロイといった、かつては複雑だったタスクを容易に処理できるようになり、データベースの複雑さではなく、アプリケーションの開発に集中できます。また、ボタンをクリックするだけで TiDB クラスタをスケールインまたはスケールアウトできるため、必要な量と期間だけデータベースをプロビジョニングでき、高価なリソースを無駄に消費することがなくなります。 +TiDB Cloud を利用すれば、開発者や DBA は、トレーニングをほとんど受けていないか、全く受けていない場合でも、インフラストラクチャ管理やクラスターのデプロイといった、かつては複雑だったタスクを容易に処理できるようになり、データベースの複雑さではなく、アプリケーションの開発に集中できます。また、ボタンをクリックするだけで TiDB クラスターをスケールインまたはスケールアウトできるため、必要な量と期間だけデータベースをプロビジョニングでき、高価なリソースを無駄に消費することがなくなります。 ### TiDBとTiDB Cloudの関係は何ですか？ {#what-is-the-relationship-between-tidb-and-tidb-cloud} TiDBはオープンソースのデータベースであり、自社のデータセンター、自己管理型のクラウド環境、またはその両方を組み合わせたハイブリッド環境でTiDB Self-Managedを実行したい組織にとって最適な選択肢です。 -TiDB Cloudは、TiDBが提供するフルマネージド型のクラウドデータベースサービスです。使いやすいWebベースの管理コンソールを備えており、ミッションクリティカルな本番環境向けのTiDBクラスタを管理できます。 +TiDB Cloudは、TiDBが提供するフルマネージド型のクラウドデータベースサービスです。使いやすいWebベースの管理コンソールを備えており、ミッションクリティカルな本番環境向けのTiDBクラスターを管理できます。 ### TiDB CloudはMySQLと互換性がありますか？ {#is-tidb-cloud-compatible-with-mysql} @@ -67,7 +67,7 @@ TiDB Cloudについて学ぶ最良の方法は、ステップバイステップ - [さあ始めましょう](/tidb-cloud/tidb-cloud-quickstart.md) - [TiDB Cloud StarterまたはEssentialインスタンスを作成します。](/tidb-cloud/create-tidb-cluster-serverless.md) - [TiDB Cloud Premiumインスタンスを作成する](/tidb-cloud/premium/create-tidb-instance-premium.md) -- [TiDB Cloud Dedicatedクラスタを作成する](/tidb-cloud/create-tidb-cluster.md) +- [TiDB Cloud Dedicatedクラスターを作成する](/tidb-cloud/create-tidb-cluster.md) ### クラスターを削除する際に、 XXX's Org/default project/Cluster0何を指しているのでしょうか？ {#what-does-code-xxx-s-org-default-project-cluster0-code-refer-to-when-deleting-a-cluster} @@ -75,19 +75,19 @@ TiDB Cloudでは、クラスターは組織名、プロジェクト名、クラ ## アーキテクチャよくある質問 {#architecture-faqs} -### 私のTiDBクラスタには様々なコンポーネントがあります。TiDB、TiKV、 TiFlashノードとは何ですか？ {#there-are-different-components-in-my-tidb-cluster-what-are-tidb-tikv-and-tiflash-nodes} +### 私のTiDBクラスターには様々なコンポーネントがあります。TiDB、TiKV、 TiFlashノードとは何ですか？ {#there-are-different-components-in-my-tidb-cluster-what-are-tidb-tikv-and-tiflash-nodes} -TiDBは、TiKVまたはTiFlashストアから返されたクエリのデータを集約するSQLコンピューティングレイヤーです。TiDBは水平方向に拡張可能であり、TiDBノードの数を増やすことで、クラスタが処理できる同時クエリの数を増やすことができます。 +TiDBは、TiKVまたはTiFlashストアから返されたクエリのデータを集約するSQLコンピューティングレイヤーです。TiDBは水平方向に拡張可能であり、TiDBノードの数を増やすことで、クラスターが処理できる同時クエリの数を増やすことができます。 TiKVは、OLTPデータを格納するために使用されるトランザクションストアです。TiKV内のすべてのデータは、複数のレプリカ（デフォルトでは3つのレプリカ）で自動的に管理されるため、TiKVはネイティブな高可用性を備え、自動フェイルオーバーをサポートします。TiKVは水平方向に拡張可能であり、トランザクションストアの数を増やすことでOLTPスループットが向上します。 -TiFlashは、トランザクションストア（TiKV）からリアルタイムでデータを複製し、リアルタイムOLAPワークロードをサポートする分析用storageです。TiKVとは異なり、 TiFlashはデータを列形式で格納することで分析処理を高速化します。また、 TiFlashは水平方向に拡張可能であり、 TiFlashノードを増やすことでOLAPstorageとコンピューティング能力が向上します。 +TiFlashは、トランザクションストア（TiKV）からリアルタイムでデータを複製し、リアルタイムOLAPワークロードをサポートする分析用ストレージです。TiKVとは異なり、 TiFlashはデータを列形式で格納することで分析処理を高速化します。また、 TiFlashは水平方向に拡張可能であり、 TiFlashノードを増やすことでOLAPストレージとコンピューティング能力が向上します。 配置Driver（PD）は、クラスターのメタデータを格納するため、TiDBクラスター全体の「頭脳」と言えます。PDは、TiKVノードからリアルタイムで報告されるデータ分散状態に基づいて、特定のTiKVノードにデータスケジューリングコマンドを送信します。TiDB Cloudでは、各クラスターのPDはPingCAPによって管理されるため、ユーザーはPDを確認したり、メンテナンスしたりすることはできません。 ### TiDBはTiKVノード間でどのようにデータを複製するのですか？ {#how-does-tidb-replicate-data-between-the-tikv-nodes} -TiKVはキーと値のペアの空間をキー範囲に分割し、各キー範囲を「リージョン」として扱います。TiKVでは、データはクラスタ内のすべてのノードに分散され、リージョンを基本単位として使用します。PDは、リージョンをクラスタ内のすべてのノードにできるだけ均等に分散（スケジューリング）する役割を担います。 +TiKVはキーと値のペアの空間をキー範囲に分割し、各キー範囲を「リージョン」として扱います。TiKVでは、データはクラスター内のすべてのノードに分散され、リージョンを基本単位として使用します。PDは、リージョンをクラスター内のすべてのノードにできるだけ均等に分散（スケジューリング）する役割を担います。 TiDBは、 Raftコンセンサスアルゴリズムを使用して、リージョンごとにデータを複製します。異なるノードに保存されたリージョンの複数のレプリカがRaftグループを形成します。 @@ -97,7 +97,7 @@ TiDBは、 Raftコンセンサスアルゴリズムを使用して、リージ ### TiDB Cloudはどのようにして高可用性を確保しているのですか？ {#how-does-tidb-cloud-ensure-high-availability} -TiDBはRaftコンセンサスアルゴリズムを採用し、 Raftグループ内のstorage全体にデータの高い可用性と安全な複製を確保します。データはTiKVノード間で冗長的にコピーされ、異なるアベイラビリティゾーンに配置されることで、マシンやデータセンターの障害から保護されます。自動フェイルオーバー機能により、TiDBはサービスの常時稼働を保証します。 +TiDBはRaftコンセンサスアルゴリズムを採用し、 Raftグループ内のストレージ全体にデータの高い可用性と安全な複製を確保します。データはTiKVノード間で冗長的にコピーされ、異なるアベイラビリティゾーンに配置されることで、マシンやデータセンターの障害から保護されます。自動フェイルオーバー機能により、TiDBはサービスの常時稼働を保証します。 Software as a Service (SaaS) プロバイダーとして、当社はデータのセキュリティを真剣に考えています。当社は[サービス組織管理（SOC）2タイプ1準拠](https://www.pingcap.com/press-release/pingcap-successfully-completes-soc-2-type-1-examination-for-tidb-cloud/)によって要求される厳格な情報セキュリティポリシーと手順を確立しています。これにより、データの安全性、可用性、機密性が確保されます。 @@ -137,12 +137,12 @@ HTAP シナリオの詳細については、 [データプラットフォーム TiDB Cloudでは、保存されているすべてのデータは暗号化され、すべてのネットワークトラフィックはトランスポート層Security（TLS）を使用して暗号化されます。 -- 保存データの暗号化は、暗号化されたstorageボリュームを使用して自動化されます。 -- クライアントとTiDBクラスタまたはインスタンス間のデータ転送における暗号化は、 TiDB CloudウェブサーバーのTLSとTiDBクラスタのTLSを使用して自動化されています。 +- 保存データの暗号化は、暗号化されたストレージボリュームを使用して自動化されます。 +- クライアントとTiDBクラスターまたはインスタンス間のデータ転送における暗号化は、 TiDB CloudウェブサーバーのTLSとTiDBクラスターのTLSを使用して自動化されています。 ### TiDB Cloudはどのようにして私のビジネスデータを暗号化するのですか？ {#how-does-tidb-cloud-encrypt-my-business-data} -TiDB Cloudは、データベースデータやバックアップデータを含む、保存されているビジネスデータに対して、デフォルトでstorageボリューム暗号化を使用します。TiDB Cloudは、転送中のデータに対してTLS暗号化を要求し、さらに、TiDB、PD、TiKV、 TiFlash間のデータベースクラスタ内のデータに対して、コンポーネントレベルのTLS暗号化も要求します。 +TiDB Cloudは、データベースデータやバックアップデータを含む、保存されているビジネスデータに対して、デフォルトでストレージボリューム暗号化を使用します。TiDB Cloudは、転送中のデータに対してTLS暗号化を要求し、さらに、TiDB、PD、TiKV、 TiFlash間のデータベースクラスター内のデータに対して、コンポーネントレベルのTLS暗号化も要求します。 TiDB Cloudにおけるビジネスデータ暗号化に関するより詳細な情報については、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 @@ -158,7 +158,7 @@ TiDB CloudはTLS 1.2またはTLS 1.3をサポートしています。 TiDB Cloudでは、ニーズに応じて、 TiDB Cloud Dedicatedクラスター、 TiDB Cloud Premiumインスタンス、 TiDB Cloud Starterインスタンス、またはTiDB Cloud Essentialインスタンスを使用できます。 -TiDB Cloud Dedicatedクラスタの場合、 TiDB Cloudは以下の対策によってクラスタのセキュリティを確保します。 +TiDB Cloud Dedicatedクラスターの場合、 TiDB Cloudは以下の対策によってクラスターのセキュリティを確保します。 - 各クラスターごとに独立したサブアカウントとVPCを作成します。 - 外部接続を隔離するためのファイアウォールルールを設定します。 @@ -180,10 +180,10 @@ TiDB Cloud Dedicatedクラスターの場合、クラスターへの接続手順 1. ネットワークを認証してください。 2. データベースのユーザーとログイン認証情報を設定してください。 -3. クラスタサーバー用にTLSをダウンロードして設定してください。 +3. クラスターサーバー用にTLSをダウンロードして設定してください。 4. SQLクライアントを選択し、 TiDB Cloud UIに自動生成された接続文字列を表示させた後、その文字列を使用してSQLクライアント経由でクラスターに接続します。 -詳細については、 [TiDB Cloud Dedicatedクラスタに接続します](/tidb-cloud/connect-to-tidb-cluster.md)参照してください。 +詳細については、 [TiDB Cloud Dedicatedクラスターに接続します](/tidb-cloud/connect-to-tidb-cluster.md)参照してください。
    diff --git a/tidb-cloud/tidb-cloud-glossary.md b/tidb-cloud/tidb-cloud-glossary.md index 9767c8816f1f1..c3c032c087a96 100644 --- a/tidb-cloud/tidb-cloud-glossary.md +++ b/tidb-cloud/tidb-cloud-glossary.md @@ -19,7 +19,7 @@ ACIDとは、トランザクションの4つの主要な特性、すなわち原 - **分離とは**、進行中のトランザクションが完了するまで他のトランザクションから見えないことを意味します。これにより、同時実行トランザクションは一貫性を損なうことなくデータの読み書きを行うことができます。TiDB は現在、 `REPEATABLE READ`の分離レベルをサポートしています。 -- **永続性**とは、一度トランザクションがコミットされると、システム障害が発生した場合でもコミットされた状態が維持されることを意味します。TiKVは永続storageを使用して永続性を確保しています。 +- **永続性**とは、一度トランザクションがコミットされると、システム障害が発生した場合でもコミットされた状態が維持されることを意味します。TiKVは永続ストレージを使用して永続性を確保しています。 ## C {#c} @@ -29,11 +29,11 @@ Chat2Query は SQL エディターに統合された AI を活用した機能で さらに、 TiDB Cloud は、AWS でホストされているTiDB Cloud Starterインスタンス向けに Chat2Query API を提供しています。有効化すると、 TiDB Cloud は自動的に**Chat2Query**というシステムデータアプリと、データサービスに Chat2Data エンドポイントを作成します。このエンドポイントを呼び出すことで、指示を与えることにより AI に SQL ステートメントを生成および実行させることができます。詳細については、 [Chat2Query API を使い始めましょう](/tidb-cloud/use-chat2query-api.md)参照してください。. -### クラスタ {#cluster} +### クラスター {#cluster} -TiDB Cloudでは、クラスターとは、ノードトポロジー、インスタンスタイプ、storage構成、スケーリングモデルなどの明確なインフラストラクチャの詳細を含む、専用のクラウドデプロイメントのことです。 +TiDB Cloudでは、クラスターとは、ノードトポロジー、インスタンスタイプ、ストレージ構成、スケーリングモデルなどの明確なインフラストラクチャの詳細を含む、専用のクラウドデプロイメントのことです。 -TiDB Cloudのプランの中で、このデプロイメントモデルを採用しているのはTiDB Cloud Dedicatedクラスタのみです。 +TiDB Cloudのプランの中で、このデプロイメントモデルを採用しているのはTiDB Cloud Dedicatedクラスターのみです。 ### クレジット {#credit} @@ -122,7 +122,7 @@ TiDB Cloudでは、プロジェクトを使用してTiDBリソースをグルー プロジェクトの機能はプロジェクトの種類によって異なります。現在、プロジェクトには以下の3種類があります。 -- **TiDB Dedicatedプロジェクト**：このプロジェクトタイプは、 TiDB Cloud Dedicatedクラスタでのみ使用されます。RBAC、ネットワーク、メンテナンス、アラート購読、暗号化アクセスなど、 TiDB Cloud Dedicatedクラスタの設定をプロジェクトごとに個別に管理できます。 +- **TiDB Dedicatedプロジェクト**：このプロジェクトタイプは、 TiDB Cloud Dedicatedクラスターでのみ使用されます。RBAC、ネットワーク、メンテナンス、アラート購読、暗号化アクセスなど、 TiDB Cloud Dedicatedクラスターの設定をプロジェクトごとに個別に管理できます。 - **TiDB X プロジェクト**: このプロジェクトタイプは、TiDB X インスタンスでのみ使用されます。プロジェクトごとに TiDB X インスタンスの RBAC を管理できます。TiDB X プロジェクトは[**私のTiDB**](https://tidbcloud.com/tidbs)ページでプロジェクトを作成する際のデフォルトのプロジェクトタイプです。 - **TiDB X 仮想プロジェクト**: このプロジェクトは仮想プロジェクトであり、管理機能は提供しません。これは、どのプロジェクトにも属さない TiDB X インスタンスの仮想コンテナとして機能するため、これらのインスタンスには、プロジェクト ID を使用してTiDB CloudAPI 経由でアクセスできます。各組織には一意の仮想プロジェクト ID があります。この ID は、TiDB Cloud API の[アクセス可能なプロジェクトをすべて一覧表示します。](https://docs.pingcap.com/tidbcloud/api/v1beta/#tag/Project/operation/ListProjects) 。 @@ -140,7 +140,7 @@ TiDB Cloudでは、プロジェクトを使用してTiDBリソースをグルー バックアップされたTiDB Cloudリソースが削除されると、その既存のバックアップ ファイルはごみ箱に移動されます。自動バックアップからのバックアップ ファイルについては、ごみ箱に指定された期間保持されます。バックアップの保持期間は**「バックアップ設定」**で設定でき、デフォルトは 7 日です。手動バックアップからのバックアップ ファイルには有効期限はありません。データ損失を防ぐため、新しいTiDB Cloudリソースにデータを速やかに復元してください。なお、 TiDB Cloudリソース**にバックアップがない**場合、削除されたリソースはごみ箱に表示されません。 -現在、ごみ箱機能はTiDB Cloud PremiumインスタンスとTiDB Cloud Dedicatedクラスタのみをサポートしています。 +現在、ごみ箱機能はTiDB Cloud PremiumインスタンスとTiDB Cloud Dedicatedクラスターのみをサポートしています。 ### 地域 {#region} @@ -175,7 +175,7 @@ TiDB Cloud Starter、 Essential、およびPremiumプランでは、リクエス - TiDB Cloud Essentialは、プロビジョニングされた[要求容量単位（RCU）](#request-capacity-unit-rcu)の数に基づいて請求されます。 1 つの RCU は、1 秒あたり特定の数の RU を処理できる固定量のコンピューティング リソースを提供します。詳細については、 [TiDB Cloud Essential の価格詳細](https://www.pingcap.com/tidb-cloud-essential-pricing-details/)を参照してください。 - TiDB Cloud Premium は、ワークロードによって消費された実際のリクエスト キャパシティー ユニット (RCU) に基づいて請求されます。 TiDB Cloudは1 秒あたりの平均 RU を毎分計算し、その平均値を[要求容量単位（RCU）](#request-capacity-unit-rcu)として請求に使用します。詳細については、 [TiDB Cloud Premiumでユニットと容量をリクエストする](https://docs.pingcap.com/tidbcloud/architecture-concepts/?plan=premium#request-units-and-capacity-in-premium)参照してください。 -TiDB Cloud Dedicatedおよび TiDB セルフマネージドの場合、リクエスト ユニット (RU) はシステム リソースの消費を表すリソース抽象化ユニットであり、これには現在 CPU、IOPS、および IO 帯域幅のメトリクスが含まれます。これは、**請求目的ではなく**、データベース要求によって消費されるリソースを制限、分離、管理するためにリソース制御機能によって使用されます。詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します。](/tidb-resource-control-ru-groups.md)参照してください。 +TiDB Cloud Dedicatedおよび TiDB Self-Managedの場合、リクエスト ユニット (RU) はシステム リソースの消費を表すリソース抽象化ユニットであり、これには現在 CPU、IOPS、および IO 帯域幅のメトリクスが含まれます。これは、**請求目的ではなく**、データベース要求によって消費されるリソースを制限、分離、管理するためにリソース制御機能によって使用されます。詳細については、[リソース制御を使用して、リソースグループの制限とフロー制御を実現します。](/tidb-resource-control-ru-groups.md)参照してください。 ## S {#s} @@ -187,11 +187,11 @@ TiDB Cloud Dedicatedおよび TiDB セルフマネージドの場合、リクエ ### TiDBクラスター {#tidb-cluster} -TiDB Cloudでは、クラスターは TiDB の専用クラウド展開であり、ノードトポロジー ( [TiDB](/tidb-computing.md)ノード、[ティクヴ](/tidb-storage.md)、 [TiFlash](/tiflash/tiflash-overview.md)ノードの数を指定できます)、storage構成、スケーリングモデルなどのインフラストラクチャの詳細が明示的に含まれています。 +TiDB Cloudでは、クラスターは TiDB の専用クラウド展開であり、ノードトポロジー ( [TiDB](/tidb-computing.md)ノード、[TiKV](/tidb-ストレージ.md)、 [TiFlash](/tiflash/tiflash-overview.md)ノードの数を指定できます)、ストレージ構成、スケーリングモデルなどのインフラストラクチャの詳細が明示的に含まれています。 ### TiDBノード {#tidb-node} -トランザクションストアまたは分析ストアから返されたクエリのデータを集約するコンピューティングノード。TiDBノードの数を増やすと、TiDB Cloud Dedicatedクラスタが処理できる同時クエリの数が増加します。 +トランザクションストアまたは分析ストアから返されたクエリのデータを集約するコンピューティングノード。TiDBノードの数を増やすと、TiDB Cloud Dedicatedクラスターが処理できる同時クエリの数が増加します。 ### TiDB Cloudリソース {#tidb-cloud-resource} @@ -202,23 +202,23 @@ TiDB Cloudリソースとは、管理可能なTiDB Cloudデプロイメント単 ### TiDB X {#tidb-x} -TiDB Xは、クラウドネイティブなオブジェクトstorageをTiDBの基盤とする、新しい分散SQLアーキテクチャです。コンピューティングとstorageを分離することで、TiDBはワークロードパターン、ビジネスサイクル、データ特性にリアルタイムで適応し、インテリジェントなスケーリングを実現します。 +TiDB Xは、クラウドネイティブなオブジェクトストレージをTiDBの基盤とする、新しい分散SQLアーキテクチャです。コンピューティングとストレージを分離することで、TiDBはワークロードパターン、ビジネスサイクル、データ特性にリアルタイムで適応し、インテリジェントなスケーリングを実現します。 TiDB Xアーキテクチャは、 TiDB Cloud Starter、 Essential、および Premium で利用できるようになりました。詳細については、 [TiDB Xのご紹介：AI時代の分散SQLのための新たな基盤](https://www.pingcap.com/blog/introducing-tidb-x-a-new-foundation-distributed-sql-ai-era/)および[PingCAPがSCaiLEサミット2025でTiDB Xと新たなAI機能を発表](https://www.pingcap.com/press-release/pingcap-launches-tidb-x-new-ai-capabilities/)参照してください。 ### TiDB Xインスタンス {#tidb-x-instance} -TiDB Xインスタンスは、 [TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md)上に構築されたサービス指向のTiDB Cloudサービスです。基盤となるクラスタトポロジーの管理や理解は不要です。 +TiDB Xインスタンスは、 [TiDB Xアーキテクチャ](/tidb-cloud/tidb-x-architecture.md)上に構築されたサービス指向のTiDB Cloudサービスです。基盤となるクラスタートポロジーの管理や理解は不要です。 TiDB Cloudのプランのうち、 TiDB Cloud Starter、 Essential、およびPremiumはTiDB Xアーキテクチャを使用しています。したがって、「TiDB Xインスタンス」という表現は、 TiDB Cloud Starter、 Essential、またはPremiumインスタンスを指します。 ### TiFlashノード {#tiflash-node} -TiKVからリアルタイムでデータを複製し、リアルタイムの分析ワークロードをサポートする分析storageノード。 +TiKVからリアルタイムでデータを複製し、リアルタイムの分析ワークロードをサポートする分析ストレージノード。 ### TiKVノード {#tikv-node} -オンライントランザクション処理（OLTP）データを格納するstorageノード。高可用性を実現するため、3ノードの倍数（例えば、3、6、9）で拡張され、2つのノードがレプリカとして機能します。TiKVノードの数を増やすと、総スループットが向上します。 +オンライントランザクション処理（OLTP）データを格納するストレージノード。高可用性を実現するため、3ノードの倍数（例えば、3、6、9）で拡張され、2つのノードがレプリカとして機能します。TiKVノードの数を増やすと、総スループットが向上します。 ### トラフィックフィルター {#traffic-filter} diff --git a/tidb-cloud/tidb-cloud-htap-quickstart.md b/tidb-cloud/tidb-cloud-htap-quickstart.md index 6a213c0225131..8bf4fc0c3596c 100644 --- a/tidb-cloud/tidb-cloud-htap-quickstart.md +++ b/tidb-cloud/tidb-cloud-htap-quickstart.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidbcloud/use-htap-cluster'] # TiDB Cloud HTAP クイックスタート {#tidb-cloud-htap-quick-start} -[HTAP](https://en.wikipedia.org/wiki/Hybrid_transactional/analytical_processing) 、ハイブリッドトランザクションおよび分析処理を意味します。TiDB Cloudの HTAP クラスターは、トランザクション処理用に設計された行ベースstorageエンジン[TiKV](https://tikv.org)と、分析処理用に設計された列指向storage[TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview)で構成されています。アプリケーションデータはまず TiKV に保存され、その後Raftコンセンサスアルゴリズムを介してTiFlashに複製されます。つまり、行ベースstorageから列指向storageへのリアルタイムレプリケーションです。 +[HTAP](https://en.wikipedia.org/wiki/Hybrid_transactional/analytical_processing) 、ハイブリッドトランザクションおよび分析処理を意味します。TiDB Cloudの HTAP クラスターは、トランザクション処理用に設計された行ベースストレージエンジン[TiKV](https://tikv.org)と、分析処理用に設計された列指向ストレージ[TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview)で構成されています。アプリケーションデータはまず TiKV に保存され、その後Raftコンセンサスアルゴリズムを介してTiFlashに複製されます。つまり、行ベースストレージから列指向ストレージへのリアルタイムレプリケーションです。 このチュートリアルでは、 TiDB Cloudのハイブリッドトランザクションおよび分析処理（HTAP）機能を簡単に体験する方法をご案内します。TiFlashへのテーブルのレプリケーション方法、 TiFlashを使用したクエリの実行方法、そしてパフォーマンス向上の体験方法などについて説明します。 @@ -16,7 +16,7 @@ HTAP 機能を体験する前に、 [TiDB Cloudクイックスタート](/tidb-c ## 手順 {#steps} -### ステップ1. サンプルデータを列指向storageエンジンに複製する {#step-1-replicate-the-sample-data-to-the-columnar-storage-engine} +### ステップ1. サンプルデータを列指向ストレージエンジンに複製する {#step-1-replicate-the-sample-data-to-the-columnar-ストレージ-engine} TiFlashノードを含むクラスターを作成した後、TiKVはデフォルトではTiFlashにデータを複製しません。複製するテーブルを指定するには、TiDBのMySQLクライアントでDDL文を実行する必要があります。その後、TiDBは指定されたテーブルのレプリカをTiFlashに作成します。 @@ -70,9 +70,9 @@ ORDER BY `release_year` DESC; ``` -### ステップ3. 行ベースのstorageと列ベースのstorageのクエリパフォーマンスを比較する {#step-3-compare-the-query-performance-between-row-based-storage-and-columnar-storage} +### ステップ3. 行ベースのストレージと列ベースのストレージのクエリパフォーマンスを比較する {#step-3-compare-the-query-performance-between-row-based-ストレージ-and-columnar-ストレージ} -このステップでは、TiKV (行ベースのstorage) とTiFlash (列ベースのstorage) 間の実行統計を比較できます。 +このステップでは、TiKV (行ベースのストレージ) とTiFlash (列ベースのストレージ) 間の実行統計を比較できます。 - TiKV を使用してこのクエリの実行統計を取得するには、次のステートメントを実行します。 diff --git a/tidb-cloud/tidb-cloud-import-local-files.md b/tidb-cloud/tidb-cloud-import-local-files.md index 8e4825b46fd17..8c993fc966767 100644 --- a/tidb-cloud/tidb-cloud-import-local-files.md +++ b/tidb-cloud/tidb-cloud-import-local-files.md @@ -5,7 +5,7 @@ summary: ローカル ファイルをTiDB Cloud Starter またはTiDB Cloud Esse # ローカルファイルをTiDB Cloud StarterまたはEssentialにインポートする {#import-local-files-to-tidb-cloud-starter-or-essential} -ローカルファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialに直接インポートできます。タスク設定は数回クリックするだけで完了し、ローカルCSVデータがTiDBクラスターに素早くインポートされます。この方法を使用すると、クラウドstorageや認証情報を入力する必要がありません。インポートプロセス全体が迅速かつスムーズです。 +ローカルファイルをTiDB Cloud StarterまたはTiDB Cloud Essentialに直接インポートできます。タスク設定は数回クリックするだけで完了し、ローカルCSVデータがTiDBクラスターに素早くインポートされます。この方法を使用すると、クラウドストレージや認証情報を入力する必要がありません。インポートプロセス全体が迅速かつスムーズです。 現在、この方法では、1 つのタスクに対して 1 つの CSV ファイルを既存の空のテーブルまたは新しいテーブルにインポートすることがサポートされています。 @@ -88,7 +88,7 @@ summary: ローカル ファイルをTiDB Cloud Starter またはTiDB Cloud Esse いいえ。現在、インポート機能を使用する場合、CSV ファイルのすべての列を既存のテーブルにインポートすることしかできません。 -特定の列のみをインポートするには、MySQLクライアントを使用してTiDBクラスタに接続し、 [`LOAD DATA`](https://docs.pingcap.com/tidb/stable/sql-statement-load-data)使用してインポートする列を指定します。例： +特定の列のみをインポートするには、MySQLクライアントを使用してTiDBクラスターに接続し、 [`LOAD DATA`](https://docs.pingcap.com/tidb/stable/sql-statement-load-data)使用してインポートする列を指定します。例： ```sql CREATE TABLE `import_test` ( diff --git a/tidb-cloud/tidb-cloud-intro.md b/tidb-cloud/tidb-cloud-intro.md index 6edeb57b521fb..2841d5587b7a7 100644 --- a/tidb-cloud/tidb-cloud-intro.md +++ b/tidb-cloud/tidb-cloud-intro.md @@ -12,7 +12,7 @@ category: intro ## TiDB Cloudを選ぶ理由 {#why-tidb-cloud} -TiDB Cloudを使用すれば、ほとんど、あるいは全くトレーニングを受けなくても、インフラストラクチャ管理やクラスタ展開といった複雑なタスクを容易に処理できます。 +TiDB Cloudを使用すれば、ほとんど、あるいは全くトレーニングを受けなくても、インフラストラクチャ管理やクラスター展開といった複雑なタスクを容易に処理できます。 - 開発者やデータベース管理者（DBA）は、大量のオンライントラフィックを容易に処理し、複数のデータセットにわたる大量のデータを迅速に分析することができます。 @@ -26,7 +26,7 @@ TiDB Cloudでは、以下の主要機能を利用できます。 - **高速かつカスタマイズ可能なスケーリング** - 重要なワークロード向けに、 ACIDトランザクションを維持しながら、数百ノードまで柔軟かつ透過的に拡張できます。シャーディングについて悩む必要はありません。また、ビジネスニーズに応じて、コンピューティングノードとstorageノードを個別に拡張することも可能です。 + 重要なワークロード向けに、 ACIDトランザクションを維持しながら、数百ノードまで柔軟かつ透過的に拡張できます。シャーディングについて悩む必要はありません。また、ビジネスニーズに応じて、コンピューティングノードとストレージノードを個別に拡張することも可能です。 - **MySQLとの互換性** @@ -46,7 +46,7 @@ TiDB Cloudでは、以下の主要機能を利用できます。 - **フルマネージドサービス** - 使いやすいWebベースの管理プラットフォームを通じて、数回のクリックでTiDBクラスタのデプロイ、スケーリング、監視、管理を行うことができます。 + 使いやすいWebベースの管理プラットフォームを通じて、数回のクリックでTiDBクラスターのデプロイ、スケーリング、監視、管理を行うことができます。 - **マルチクラウド対応** @@ -134,7 +134,7 @@ TiDB Cloudは、以下の導入オプションを提供します。 - TiDB Cloudセントラルサービス - 課金、アラート、メタstorage、ダッシュボードUIなどの中央サービスは、それぞれ独立してデプロイされます。ダッシュボードUIにはインターネット経由でアクセスでき、 TiDB Cloudリソースを操作できます。 + 課金、アラート、メタストレージ、ダッシュボードUIなどの中央サービスは、それぞれ独立してデプロイされます。ダッシュボードUIにはインターネット経由でアクセスでき、 TiDB Cloudリソースを操作できます。 - あなたのVPC diff --git a/tidb-cloud/tidb-cloud-migration-overview.md b/tidb-cloud/tidb-cloud-migration-overview.md index 1806d10d8d45f..40683c681b0ff 100644 --- a/tidb-cloud/tidb-cloud-migration-overview.md +++ b/tidb-cloud/tidb-cloud-migration-overview.md @@ -25,11 +25,11 @@ MySQL互換データベースからデータを移行する場合、完全デー - MySQLシャードの移行とマージ - アプリケーションでデータstorageにMySQLシャードを使用している場合は、これらのシャードを1つのテーブルとしてTiDB Cloudに移行できます。詳細については、 [大規模データセットの MySQL シャードをTiDB Cloudに移行および統合する](/tidb-cloud/migrate-sql-shards.md)ご覧ください。 + アプリケーションでデータストレージにMySQLシャードを使用している場合は、これらのシャードを1つのテーブルとしてTiDB Cloudに移行できます。詳細については、 [大規模データセットの MySQL シャードをTiDB Cloudに移行および統合する](/tidb-cloud/migrate-sql-shards.md)ご覧ください。 -- TiDBセルフマネージドからの移行 +- TiDB Self-Managedからの移行 - DumplingとTiCDCを介して、TiDBセルフマネージドクラスターからTiDB Cloud （AWS）にデータを移行できます。詳細については、 [TiDBセルフマネージドからTiDB Cloudへの移行](/tidb-cloud/migrate-from-op-tidb.md)ご覧ください。 + DumplingとTiCDCを介して、TiDB Self-ManagedクラスターからTiDB Cloud （AWS）にデータを移行できます。詳細については、 [TiDB Self-ManagedからTiDB Cloudへの移行](/tidb-cloud/migrate-from-op-tidb.md)ご覧ください。 ## ファイルからTiDB Cloudにデータをインポートする {#import-data-from-files-to-tidb-cloud} @@ -53,9 +53,9 @@ SQL、CSV、Parquet、またはAurora Snapshot形式のデータファイルを ## 参照 {#reference} -### クラウドstorageアクセスを構成する {#configure-cloud-storage-access} +### クラウドストレージアクセスを構成する {#configure-cloud-ストレージ-access} -ソースデータがAmazon S3、Google Cloud Storage（GCS）バケット、Azure Blob Storageコンテナ、またはAlibaba Cloud OSSバケットに保存されている場合、 TiDB Cloudにデータをインポートまたは移行する前に、storageへのアクセスを設定する必要があります。詳細については、 [TiDB Cloud Starter または Essential の外部ストレージアクセスを構成する](/tidb-cloud/configure-external-storage-access.md)と[TiDB Cloud Dedicatedの外部ストレージアクセスを構成する](/tidb-cloud/dedicated-external-storage.md)参照してください。 +ソースデータがAmazon S3、Google Cloud Storage（GCS）バケット、Azure Blob Storageコンテナ、またはAlibaba Cloud OSSバケットに保存されている場合、 TiDB Cloudにデータをインポートまたは移行する前に、ストレージへのアクセスを設定する必要があります。詳細については、 [TiDB Cloud Starter または Essential の外部ストレージアクセスを構成する](/tidb-cloud/configure-external-ストレージ-access.md)と[TiDB Cloud Dedicatedの外部ストレージアクセスを構成する](/tidb-cloud/dedicated-external-ストレージ.md)参照してください。 ### データインポートの命名規則 {#naming-conventions-for-data-import} diff --git a/tidb-cloud/tidb-cloud-poc.md b/tidb-cloud/tidb-cloud-poc.md index 113bf805796fc..76417ea7c81be 100644 --- a/tidb-cloud/tidb-cloud-poc.md +++ b/tidb-cloud/tidb-cloud-poc.md @@ -54,7 +54,7 @@ TiDB Cloudは、高可用性と大容量データの強力な整合性が求め - リアルタイムHTAP - MySQLプロトコルおよびMySQLエコシステムと互換性があります -分析処理の高速化に役立つ列指向storageエンジンである[TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview)ご利用にもご興味があるかもしれません。PoC期間中は、 TiFlash機能をいつでもご利用いただけます。 +分析処理の高速化に役立つ列指向ストレージエンジンである[TiFlash](https://docs.pingcap.com/tidb/stable/tiflash-overview)ご利用にもご興味があるかもしれません。PoC期間中は、 TiFlash機能をいつでもご利用いただけます。 ## ステップ3. PoC用のTiDB Cloud専用クラスターにサインアップして作成する {#step-3-sign-up-and-create-a-tidb-cloud-dedicated-cluster-for-the-poc} @@ -66,7 +66,7 @@ PoC 用の[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedic フォームを送信すると、 TiDB Cloudサポートチームが申請内容を確認し、ご連絡いたします。申請が承認され次第、アカウントにクレジットが付与されます。また、PingCAP サポートエンジニアにご連絡いただければ、PoC の手順をサポートし、PoC がスムーズに実行されるようサポートいたします。 -2. PoC 用のTiDB Cloud Dedicated クラスターを作成するには、 [TiDB Cloud専用クラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 +2. PoC 用のTiDB Cloud Dedicated クラスターを作成するには、 [TiDB Cloud専用クラスターを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。 > **注記：** > @@ -81,16 +81,16 @@ PoC 用の[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedic クラスターを作成する前に、キャパシティプランニングを実施してクラスターのサイズを決定することをお勧めします。TiDB、TiKV、またはTiFlashノードの概算数から開始し、パフォーマンス要件に合わせて後からクラスターをスケールアウトすることも可能です。詳細については、以下のドキュメントをご覧いただくか、サポートチームにお問い合わせください。 - 推定の実践の詳細については、 [TiDBのサイズ](/tidb-cloud/size-your-cluster.md)参照してください。 -- TiDB Cloud Dedicated クラスターの構成については、 [TiDB Cloud専用クラスタを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。TiDB、TiKV、 TiFlash (オプション) のクラスター サイズをそれぞれ構成します。 +- TiDB Cloud Dedicated クラスターの構成については、 [TiDB Cloud専用クラスターを作成する](/tidb-cloud/create-tidb-cluster.md)を参照してください。TiDB、TiKV、 TiFlash (オプション) のクラスター サイズをそれぞれ構成します。 - PoC クレジットの消費を効果的に計画し、最適化する方法については、このドキュメントの[FAQ](#faq)参照してください。 -- スケーリングの詳細については、 [TiDBクラスタのスケール](/tidb-cloud/scale-tidb-cluster.md)参照してください。 +- スケーリングの詳細については、 [TiDBクラスターのスケール](/tidb-cloud/scale-tidb-cluster.md)参照してください。 -専用のPoCクラスターを作成したら、データをロードして一連のテストを実行する準備が整います。TiDBクラスターへの接続方法については、 [TiDB Cloud専用クラスタに接続する](/tidb-cloud/connect-to-tidb-cluster.md)参照してください。 +専用のPoCクラスターを作成したら、データをロードして一連のテストを実行する準備が整います。TiDBクラスターへの接続方法については、 [TiDB Cloud専用クラスターに接続する](/tidb-cloud/connect-to-tidb-cluster.md)参照してください。 新しく作成されたクラスターの場合は、次の構成に注意してください。 - デフォルトのタイムゾーン（ダッシュボードの**「作成時間」**列）はUTCです。以下の手順[ローカルタイムゾーンを設定する](/tidb-cloud/manage-user-access.md#set-the-time-zone-for-your-organization)で、ローカルタイムゾーンに変更できます。 -- 新しいクラスタのデフォルトのバックアップ設定は、毎日データベース全体のバックアップです。希望するバックアップ時間を指定するか、手動でデータをバックアップすることもできます。デフォルトのバックアップ時間および詳細については、 [TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)参照してください。 +- 新しいクラスターのデフォルトのバックアップ設定は、毎日データベース全体のバックアップです。希望するバックアップ時間を指定するか、手動でデータをバックアップすることもできます。デフォルトのバックアップ時間および詳細については、 [TiDBクラスターデータのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)参照してください。 ## ステップ4. スキーマとSQLを適応させる {#step-4-adapt-your-schemas-and-sql} @@ -139,11 +139,11 @@ TiDB Cloudにはさまざまな形式のデータをインポートできます これで環境の作成、スキーマの調整、データのインポートが完了しました。次はワークロードをテストしましょう。 -ワークロードをテストする前に、必要に応じてデータベースを元の状態に復元できるように、手動バックアップを実行することを検討してください。詳細については、 [TiDBクラスタデータのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)参照してください。 +ワークロードをテストする前に、必要に応じてデータベースを元の状態に復元できるように、手動バックアップを実行することを検討してください。詳細については、 [TiDBクラスターデータのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)参照してください。 ワークロードを開始した後、次の方法を使用してシステムを観察できます。 -- クラスターの一般的なメトリクスは、クラスター概要ページで確認できます。これには、合計QPS、レイテンシ、接続数、 TiFlashリクエストQPS、 TiFlashリクエスト期間、 TiFlashストレージサイズ、TiKVストレージサイズ、TiDB CPU、TiKV CPU、TiKV IO読み取り、TiKV IO書き込みが含まれます。1 [TiDBクラスタを監視する](/tidb-cloud/monitor-tidb-cluster.md)参照してください。 +- クラスターの一般的なメトリクスは、クラスター概要ページで確認できます。これには、合計QPS、レイテンシ、接続数、 TiFlashリクエストQPS、 TiFlashリクエスト期間、 TiFlashストレージサイズ、TiKVストレージサイズ、TiDB CPU、TiKV CPU、TiKV IO読み取り、TiKV IO書き込みが含まれます。1 [TiDBクラスターを監視する](/tidb-cloud/monitor-tidb-cluster.md)参照してください。 - クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページ目に移動し、 **「SQLステートメント」**タブを確認してください。ここでは、システムテーブルをクエリすることなく、SQL実行を監視し、パフォーマンスの問題を簡単に特定できます。5 [ステートメント分析](/tidb-cloud/tune-performance.md#statement-analysis)参照してください。 - クラスターの[**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページ目に移動し、 **「Key Visualizer」**タブでTiDBのデータアクセスパターンとデータホットスポットを確認できます[キービジュアライザー](/tidb-cloud/tune-performance.md#key-visualizer)参照してください。 - これらのメトリクスを独自のDatadogおよびPrometheusに統合することもできます。1 [サードパーティの監視統合](/tidb-cloud/third-party-monitoring-integrations.md)参照してください。 @@ -158,21 +158,21 @@ TiDB Cloudにはさまざまな形式のデータをインポートできます - SQL パフォーマンスを調査して調整します。 - モニターと[ホットスポットの問題を解決する](https://docs.pingcap.com/tidb/dev/troubleshoot-hot-spot-issues#troubleshoot-hotspot-issues) 。 -- storageサイズとCPU使用率を評価し、それに応じてTiDBクラスターのスケールアウトまたはスケールインを実施してください。スケーリングの詳細については、セクション[FAQ](#faq)を参照してください。 +- ストレージサイズとCPU使用率を評価し、それに応じてTiDBクラスターのスケールアウトまたはスケールインを実施してください。スケーリングの詳細については、セクション[FAQ](#faq)を参照してください。 パフォーマンス チューニングのヒントを次に示します。 - 書き込みパフォーマンスの向上 - - TiDB クラスターをスケールアウトして書き込みスループットを向上させます ( [TiDBクラスタのスケール](/tidb-cloud/scale-tidb-cluster.md)参照)。 - - [楽観的取引モデル](https://docs.pingcap.com/tidb/stable/optimistic-transaction#tidb-optimistic-transaction-model)を使用してロックの競合を減らします。 + - TiDB クラスターをスケールアウトして書き込みスループットを向上させます ( [TiDBクラスターのスケール](/tidb-cloud/scale-tidb-cluster.md)参照)。 + - [楽観的トランザクションモデル](https://docs.pingcap.com/tidb/stable/optimistic-transaction#tidb-optimistic-transaction-model)を使用してロックの競合を減らします。 - クエリパフォーマンスの向上 - [**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページの[**SQL文**](/tidb-cloud/tune-performance.md#statement-analysis)タブで SQL 実行プランを確認します。 - [**診断**](/tidb-cloud/tune-performance.md#view-the-diagnosis-page)ページの[**キービジュアライザー**](/tidb-cloud/tune-performance.md#key-visualizer)タブでホットスポットの問題を確認します。 - [**メトリクス**](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page)ページで TiDB クラスターの容量が不足していないかどうかを監視します。 - - TiFlash機能を使用して分析処理を最適化します[HTAPクラスタを使用する](/tiflash/tiflash-overview.md)を参照してください。 + - TiFlash機能を使用して分析処理を最適化します[HTAPクラスターを使用する](/tiflash/tiflash-overview.md)を参照してください。 ## ステップ7. その他の機能を調べる {#step-7-explore-more-features} @@ -180,21 +180,21 @@ TiDB Cloudにはさまざまな形式のデータをインポートできます - アップグレード - TiDB CloudはTiDBクラスタを定期的にアップグレードします。また、サポートチケットを送信してクラスタのアップグレードをリクエストすることもできます。1 [TiDBクラスタのアップグレード](/tidb-cloud/upgrade-tidb-cluster.md)ご覧ください。 + TiDB CloudはTiDBクラスターを定期的にアップグレードします。また、サポートチケットを送信してクラスターのアップグレードをリクエストすることもできます。1 [TiDBクラスターのアップグレード](/tidb-cloud/upgrade-tidb-cluster.md)ご覧ください。 - バックアップ - ベンダーロックインを回避するには、毎日フルバックアップを実行してデータを新しいクラスタに移行し、 [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview)使用してデータをエクスポートします。詳細については、 [TiDB Cloud専用データのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)と[TiDB Cloud StarterまたはEssentialでデータをバックアップおよび復元する](/tidb-cloud/backup-and-restore-serverless.md)参照してください。 + ベンダーロックインを回避するには、毎日フルバックアップを実行してデータを新しいクラスターに移行し、 [Dumpling](https://docs.pingcap.com/tidb/stable/dumpling-overview)使用してデータをエクスポートします。詳細については、 [TiDB Cloud専用データのバックアップと復元](/tidb-cloud/backup-and-restore.md#turn-on-auto-backup)と[TiDB Cloud StarterまたはEssentialでデータをバックアップおよび復元する](/tidb-cloud/backup-and-restore-serverless.md)参照してください。 ## ステップ8. 環境をクリーンアップしてPoCを完了する {#step-8-clean-up-the-environment-and-finish-the-poc} 実際のワークロードを使用してTiDB Cloudをテストし、テスト結果を取得することで、PoCサイクル全体が完了しました。これらの結果は、TiDB Cloudが期待どおりに機能しているかどうかを判断するのに役立ちます。同時に、 TiDB Cloudの活用に関するベストプラクティスも蓄積されました。 -TiDB Cloud をより大規模に試して、 TiDB Cloudが提供する他のノードstorageサイズを使用してデプロイするなど、新しい一連のデプロイとテストを行う場合は、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターを作成してTiDB Cloudへのフル アクセスを取得してください。 +TiDB Cloud をより大規模に試して、 TiDB Cloudが提供する他のノードストレージサイズを使用してデプロイするなど、新しい一連のデプロイとテストを行う場合は、 [TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターを作成してTiDB Cloudへのフル アクセスを取得してください。 クレジットがなくなり、PoC を継続したい場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)に連絡してご相談ください。 -PoCはいつでも終了し、テスト環境を削除できます。詳細については、 [TiDBクラスタを削除する](/tidb-cloud/delete-tidb-cluster.md)ご覧ください。 +PoCはいつでも終了し、テスト環境を削除できます。詳細については、 [TiDBクラスターを削除する](/tidb-cloud/delete-tidb-cluster.md)ご覧ください。 ## FAQ {#faq} @@ -210,10 +210,10 @@ TiDB Cloud は、自動バックアップと手動バックアップの 2 種類 スケーリングに関する考慮事項は次のとおりです。 -- ピーク時間中またはデータのインポート中に、ダッシュボードの容量メトリックが上限に達したことが確認された場合 ( [TiDBクラスタを監視する](/tidb-cloud/monitor-tidb-cluster.md)を参照)、クラスターをスケールアウトする必要がある可能性があります。 +- ピーク時間中またはデータのインポート中に、ダッシュボードの容量メトリックが上限に達したことが確認された場合 ( [TiDBクラスターを監視する](/tidb-cloud/monitor-tidb-cluster.md)を参照)、クラスターをスケールアウトする必要がある可能性があります。 - リソースの使用量が持続的に低い場合（たとえば、CPU 使用率が 10% ～ 20% のみ）は、クラスターをスケールインしてリソースを節約できます。 -コンソール上でクラスターをスケールアウトできます。クラスターをスケールインする必要がある場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。スケーリングの詳細については、 [TiDBクラスタのスケール](/tidb-cloud/scale-tidb-cluster.md)ご覧ください。サポートチームに連絡して、正確な進捗状況を追跡することができます。スケーリング操作はデータの再バランス調整によってパフォーマンスに影響を与える可能性があるため、テストを開始する前に完了するまでお待ちください。 +コンソール上でクラスターをスケールアウトできます。クラスターをスケールインする必要がある場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。スケーリングの詳細については、 [TiDBクラスターのスケール](/tidb-cloud/scale-tidb-cluster.md)ご覧ください。サポートチームに連絡して、正確な進捗状況を追跡することができます。スケーリング操作はデータの再バランス調整によってパフォーマンスに影響を与える可能性があるため、テストを開始する前に完了するまでお待ちください。 ### 3. PoC クレジットを最大限に活用するにはどうすればよいですか? {#3-how-to-make-the-best-use-of-my-poc-credits} diff --git a/tidb-cloud/tidb-cloud-quickstart.md b/tidb-cloud/tidb-cloud-quickstart.md index 7ef3784c024d2..ea0d4fef7da1d 100644 --- a/tidb-cloud/tidb-cloud-quickstart.md +++ b/tidb-cloud/tidb-cloud-quickstart.md @@ -29,8 +29,8 @@ category: quick start - このデフォルト クラスターでTiDB Cloud機能をすぐに試すには、 [ステップ2: AI支援SQLエディターを試す](#step-2-try-ai-assisted-sql-editor)に進みます。 - 独自に新しいTiDB Cloud Starter クラスターを作成するには、次の手順に従います。 - 1. **[クラスタの作成]を**クリックします。 - 2. **「クラスタの作成」**ページでは、デフォルトで**「スターター」**が選択されています。クラスターのクラウドプロバイダーとターゲットリージョンを選択し、必要に応じてデフォルトのクラスター名を更新して、 **「作成」を**クリックします。TiDB Cloud Starterクラスターは約30秒で作成されます。 + 1. **[クラスターの作成]を**クリックします。 + 2. **「クラスターの作成」**ページでは、デフォルトで**「スターター」**が選択されています。クラスターのクラウドプロバイダーとターゲットリージョンを選択し、必要に応じてデフォルトのクラスター名を更新して、 **「作成」を**クリックします。TiDB Cloud Starterクラスターは約30秒で作成されます。 @@ -132,6 +132,6 @@ TiDB Cloud は、 TiDB Cloudをすぐに使い始めるのに役立つ、丁寧 ## 次は何か {#what-s-next} - さまざまな方法を使用してクラスターに接続する方法については、 [TiDB Cloud Starter または Essential クラスターに接続する](/tidb-cloud/connect-to-tidb-cluster-serverless.md)参照してください。 -- SQL エディターと Chat2Query を使用してデータを探索する方法の詳細については、 [AI支援SQLエディターでデータを探索](/tidb-cloud/explore-data-with-chat2query.md)参照してください。 -- TiDB SQL の使用法については、 [TiDB で SQL を探索する](/basic-sql-operations.md)参照してください。 +- SQL エディターと Chat2Query を使用してデータを確認する方法の詳細については、 [AI支援SQLエディターでデータを探索](/tidb-cloud/explore-data-with-chat2query.md)参照してください。 +- TiDB SQL の使用法については、 [TiDBでのSQL基本操作](/basic-sql-operations.md)参照してください。 - ゾーン間の高可用性、水平スケーリング、および[HTAP](https://en.wikipedia.org/wiki/Hybrid_transactional/analytical_processing)利点を備えた本番で使用する場合は、 [TiDB Cloud専用クラスターを作成する](/tidb-cloud/create-tidb-cluster.md)参照してください。 diff --git a/tidb-cloud/tidb-cloud-roadmap.md b/tidb-cloud/tidb-cloud-roadmap.md index 91e4d8c67e529..09c589fd4ad1f 100644 --- a/tidb-cloud/tidb-cloud-roadmap.md +++ b/tidb-cloud/tidb-cloud-roadmap.md @@ -19,11 +19,11 @@ TiDB Cloudのロードマップでは、近未来に予定されている新機 ## 開発者エクスペリエンスとエンタープライズグレードの機能 {#developer-experience-and-enterprise-grade-features} -
    ドメイン特徴説明
    開発者エクスペリエンス✅ サンプルデータセットを手動で読み込む。サンプルデータセットをクラスタにロードする機能をサポートします。このデータを使用すると、 TiDB Cloudの機能を迅速にテストできます。
    ✅ Chat2Query（AI搭載のSQLエディタ）を追加します。 Chat2Queryでは、AIにSQLクエリを自動生成させることも、SQLクエリを手動で記述して、ターミナルを使わずにデータベースに対してSQLクエリを実行することもできます。
    ✅ データサービスをサポートします。データサービス（ベータ版）を使用すると、カスタムAPIエンドポイントを使用してHTTPSリクエスト経由でTiDB Cloudデータを読み書きできます。
    クラウドプロバイダーマーケットプレイス✅ AWS MarketplaceおよびGoogle Cloud Marketplaceのユーザーエクスペリエンスを向上させます。 AWS MarketplaceおよびGoogle Cloud Marketplaceからサインアップするユーザーのユーザー体験と利用プロセスを改善する。
    エンタープライズグレードの機能✅ 複数の組織に属するユーザーを管理します。招待を承諾することで、ユーザーが複数の組織に参加できるようにする。
    ✅ 階層的なユーザーロールと権限をサポートします。 TiDB Cloudコンソールでロールベースアクセス制御（RBAC）をサポートします。クラスタ、課金、メンバーなど、きめ細かなレベルでユーザー権限を管理できます。
    UIエクスペリエンス✅ より便利なフィードバックチャネルを提供する。ユーザーは製品に関するサポートを迅速に受けたり、フィードバックを提供したりできます。
    ✅ 左側のナビゲーションを追加します。 TiDB Cloudコンソールを組織、プロジェクト、ユーザーの構造に沿って表示することで、レイアウトロジックを簡素化し、ユーザーエクスペリエンスを向上させます。
    プレイグラウンドを最適化します。ユーザーがTiDBおよびTiDB Cloudをより深く理解できるよう、状況に応じたチュートリアルを提供する。
    +
    ドメイン特徴説明
    開発者エクスペリエンス✅ サンプルデータセットを手動で読み込む。サンプルデータセットをクラスターにロードする機能をサポートします。このデータを使用すると、 TiDB Cloudの機能を迅速にテストできます。
    ✅ Chat2Query（AI搭載のSQLエディタ）を追加します。 Chat2Queryでは、AIにSQLクエリを自動生成させることも、SQLクエリを手動で記述して、ターミナルを使わずにデータベースに対してSQLクエリを実行することもできます。
    ✅ データサービスをサポートします。データサービス（ベータ版）を使用すると、カスタムAPIエンドポイントを使用してHTTPSリクエスト経由でTiDB Cloudデータを読み書きできます。
    クラウドプロバイダーマーケットプレイス✅ AWS MarketplaceおよびGoogle Cloud Marketplaceのユーザーエクスペリエンスを向上させます。 AWS MarketplaceおよびGoogle Cloud Marketplaceからサインアップするユーザーのユーザー体験と利用プロセスを改善する。
    エンタープライズグレードの機能✅ 複数の組織に属するユーザーを管理します。招待を承諾することで、ユーザーが複数の組織に参加できるようにする。
    ✅ 階層的なユーザーロールと権限をサポートします。 TiDB Cloudコンソールでロールベースアクセス制御（RBAC）をサポートします。クラスター、課金、メンバーなど、きめ細かなレベルでユーザー権限を管理できます。
    UIエクスペリエンス✅ より便利なフィードバックチャネルを提供する。ユーザーは製品に関するサポートを迅速に受けたり、フィードバックを提供したりできます。
    ✅ 左側のナビゲーションを追加します。 TiDB Cloudコンソールを組織、プロジェクト、ユーザーの構造に沿って表示することで、レイアウトロジックを簡素化し、ユーザーエクスペリエンスを向上させます。
    プレイグラウンドを最適化します。ユーザーがTiDBおよびTiDB Cloudをより深く理解できるよう、状況に応じたチュートリアルを提供する。
    ## 診断とメンテナンス {#diagnosis-and-maintenance} -
    ドメイン特徴説明
    レポートを使用したセルフサービス型クラスタ分析および診断✅クラスタの状態レポート。複数の異なる使用シナリオに対応した診断および分析レポートを提供します。
    ✅クラスタの状態比較レポート。いくつかのシナリオにおけるクラスタ障害を特定し、推奨される解決策を提示する。
    ✅クラスタシステムチェックレポート。いくつかのシナリオについて、クラスタキーの状態概要を提供します。
    HTAPワークロード向けSQLチューニングHTAPワークロードにおけるTiFlashおよびTiKV向けSQLの最適化に関する提案を提供してください。 HTAPワークロードにおけるアプリケーションの視点から、SQL実行の概要を表示するダッシュボードを提供する。
    アプリケーションの視点からSQL実行情報を提供する。 1つまたは複数のHTAPシナリオについて、SQL最適化に関する提案を提供してください。
    クラスタ診断データへのアクセス✅ 診断データにオンラインでリアルタイムにアクセスできます。さまざまな監視・診断システムと統合することで、リアルタイムデータアクセス機能を向上させる。
    ✅診断データにオフラインでアクセスできます。大規模な診断、分析、および調整のために、オフラインでのデータアクセスを提供します。
    データ再構築のためのロジックを構築する。データ安定性を向上させ、データ再構築のためのロジックを構築する。
    TiDB CloudサービスのトレースTiDB Cloudサービスの各コンポーネントの監視リンクを構築します。
    • ユーザーシナリオにおいて、 TiDB Cloudサービスの各コンポーネントのトレースリンクを構築します。
    • 利用者の視点から、サービスの利用可能性に関する評価を提供する。
    +
    ドメイン特徴説明
    レポートを使用したセルフサービス型クラスター分析および診断✅クラスターの状態レポート。複数の異なる使用シナリオに対応した診断および分析レポートを提供します。
    ✅クラスターの状態比較レポート。いくつかのシナリオにおけるクラスター障害を特定し、推奨される解決策を提示する。
    ✅クラスターシステムチェックレポート。いくつかのシナリオについて、クラスターキーの状態概要を提供します。
    HTAPワークロード向けSQLチューニングHTAPワークロードにおけるTiFlashおよびTiKV向けSQLの最適化に関する提案を提供してください。 HTAPワークロードにおけるアプリケーションの視点から、SQL実行の概要を表示するダッシュボードを提供する。
    アプリケーションの視点からSQL実行情報を提供する。 1つまたは複数のHTAPシナリオについて、SQL最適化に関する提案を提供してください。
    クラスター診断データへのアクセス✅ 診断データにオンラインでリアルタイムにアクセスできます。さまざまな監視・診断システムと統合することで、リアルタイムデータアクセス機能を向上させる。
    ✅診断データにオフラインでアクセスできます。大規模な診断、分析、および調整のために、オフラインでのデータアクセスを提供します。
    データ再構築のためのロジックを構築する。データ安定性を向上させ、データ再構築のためのロジックを構築する。
    TiDB CloudサービスのトレースTiDB Cloudサービスの各コンポーネントの監視リンクを構築します。
    • ユーザーシナリオにおいて、 TiDB Cloudサービスの各コンポーネントのトレースリンクを構築します。
    • 利用者の視点から、サービスの利用可能性に関する評価を提供する。
    ## データバックアップと移行 {#data-backup-and-migration} @@ -31,4 +31,4 @@ TiDB Cloudのロードマップでは、近未来に予定されている新機 ## Security {#security} -
    ドメイン特徴説明
    TLS回転TiDBクラスタにおけるTLSローテーションをサポートします。 TiDBクラスタにおける内部TLSローテーション設定と自動更新をサポートします。
    データ暗号化顧客が管理する暗号化キーの有効化。 TiDB Cloud上で顧客が独自のKMS暗号化キーを使用できるようにする。
    国立データベース監査ログ✅ データベース監査ログ機能を強化する。データベース監査ログ機能を強化する。
    コンソール監査ログ✅ TiDB Cloudコンソール操作の監査をサポートします。 TiDB Cloudコンソールにおける様々な操作に対して、信頼性の高い監査機能をサポートします。
    +
    ドメイン特徴説明
    TLS回転TiDBクラスターにおけるTLSローテーションをサポートします。 TiDBクラスターにおける内部TLSローテーション設定と自動更新をサポートします。
    データ暗号化顧客が管理する暗号化キーの有効化。 TiDB Cloud上で顧客が独自のKMS暗号化キーを使用できるようにする。
    国立データベース監査ログ✅ データベース監査ログ機能を強化する。データベース監査ログ機能を強化する。
    コンソール監査ログ✅ TiDB Cloudコンソール操作の監査をサポートします。 TiDB Cloudコンソールにおける様々な操作に対して、信頼性の高い監査機能をサポートします。
    diff --git a/tidb-cloud/tidb-cloud-sql-tuning-overview.md b/tidb-cloud/tidb-cloud-sql-tuning-overview.md index 510a9734f6c3e..0afc2b1e3e812 100644 --- a/tidb-cloud/tidb-cloud-sql-tuning-overview.md +++ b/tidb-cloud/tidb-cloud-sql-tuning-overview.md @@ -17,7 +17,7 @@ SQL文のパフォーマンスを向上させるには、以下の原則を考 - スキャン対象データの範囲を最小限に抑えましょう。常に、必要最小限のデータのみをスキャンし、すべてのデータをスキャンすることは避けるのが最善策です。 - 適切なインデックスを使用してください。SQL文の`WHERE`句の各列には、対応するインデックスが存在することを確認してください。そうでない場合、 `WHERE`句はテーブル全体をスキャンするため、パフォーマンスが低下します。 - 適切な結合タイプを使用してください。クエリ内の各テーブルのサイズと相関関係に応じて、適切な結合タイプを選択することが非常に重要です。一般に、TiDB のコストベースのオプティマイザーは、最適な結合タイプを自動的に選択します。ただし、場合によっては、結合タイプを手動で指定する必要がある場合があります。詳細については、[テーブル結合を使用するステートメントについて説明します](/explain-joins.md)参照してください。 -- 適切なstorageエンジンを使用してください。ハイブリッドトランザクションおよび分析処理（HTAP）ワークロードには、 TiFlashstorageエンジンを使用することをお勧めします。HTAP [HTAPクエリ](/develop/dev-guide-hybrid-oltp-and-olap-queries.md)を参照してください。 +- 適切なストレージエンジンを使用してください。ハイブリッドトランザクションおよび分析処理（HTAP）ワークロードには、 TiFlashストレージエンジンを使用することをお勧めします。HTAP [HTAPクエリ](/develop/dev-guide-hybrid-oltp-and-olap-queries.md)を参照してください。 TiDB Cloudには、遅いクエリを分析するのに役立つツールがいくつか用意されています。以下のセクションでは、遅いクエリを最適化するためのいくつかの方法について説明します。 @@ -107,7 +107,7 @@ SQLパフォーマンスチューニングを行ってもパフォーマンス [キービジュアライザー](/tidb-cloud/tune-performance.md#key-visualizer)を使用してホットスポットの問題を分析できます。 -Key Visualizerを使用すると、 TiDB Cloud Dedicatedクラスタの使用パターンを分析し、トラフィックのホットスポットをトラブルシューティングできます。このページでは、TiDB Cloud Dedicatedクラスタのトラフィックの推移を視覚的に表示します。 +Key Visualizerを使用すると、 TiDB Cloud Dedicatedクラスターの使用パターンを分析し、トラフィックのホットスポットをトラブルシューティングできます。このページでは、TiDB Cloud Dedicatedクラスターのトラフィックの推移を視覚的に表示します。 Key Visualizerでは、以下の情報を確認できます。まず、いくつかの[基本概念](https://docs.pingcap.com/tidb/stable/dashboard-key-visualizer#basic-concepts)を理解しておく必要があるかもしれません。 diff --git a/tidb-cloud/tidb-cloud-support.md b/tidb-cloud/tidb-cloud-support.md index feaf5806b46f9..aa255ff76ab2f 100644 --- a/tidb-cloud/tidb-cloud-support.md +++ b/tidb-cloud/tidb-cloud-support.md @@ -58,7 +58,7 @@ TiDB Cloudのすべてのユーザーは、請求およびアカウント関連 - **概要**: 質問の簡単な概要を記入します。 - **TiDB Cloud Org** : 該当する場合は、関連するTiDB Cloud組織を選択します。 - - **TiDB Cloudクラスタ**: 該当する場合は、関連するTiDB Cloudクラスターを選択します。 + - **TiDB Cloudクラスター**: 該当する場合は、関連するTiDB Cloudクラスターを選択します。 - **説明**: 問題に関する詳細を提供します。 - **重大度**: 問題のビジネスへの影響を見積もり、適切な重大度を選択します。(S1 は請求やアカウントの問題には適用されません。) @@ -82,7 +82,7 @@ TiDB Cloudのすべてのユーザーは、請求およびアカウント関連 - **TiDB Cloud Org** : 問題に関連するTiDB Cloud組織を選択します。 - - **TiDB Cloudクラスタ**: 該当する場合は、関連するTiDB Cloudクラスターを選択します。 + - **TiDB Cloudクラスター**: 該当する場合は、関連するTiDB Cloudクラスターを選択します。 - **環境**: TiDB Cloudクラスターを使用する対応する環境を選択します。 diff --git a/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md b/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md index f09e70f4d83fa..2a2c74078aa8f 100644 --- a/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md +++ b/tidb-cloud/tidb-cloud-tls-connect-to-dedicated.md @@ -6,19 +6,19 @@ aliases: ['/ja/tidbcloud/tidb-cloud-tls-connect-to-dedicated-tier'] # TiDB Cloud専用へのTLS接続 {#tls-connections-to-tidb-cloud-dedicated} -TiDB Cloudでは、TLS 接続の確立はTiDB Cloud Dedicated クラスタへの接続における基本的なセキュリティ対策の一つです。クライアント、アプリケーション、開発ツールからTiDB Cloud Dedicated クラスタへの複数の TLS 接続を設定することで、データ転送のセキュリティを保護できます。セキュリティ上の理由から、 TiDB Cloud Dedicated は TLS 1.2 および TLS 1.3 のみをサポートし、TLS 1.0 および TLS 1.1 はサポートしていません。 +TiDB Cloudでは、TLS 接続の確立はTiDB Cloud Dedicated クラスターへの接続における基本的なセキュリティ対策の一つです。クライアント、アプリケーション、開発ツールからTiDB Cloud Dedicated クラスターへの複数の TLS 接続を設定することで、データ転送のセキュリティを保護できます。セキュリティ上の理由から、 TiDB Cloud Dedicated は TLS 1.2 および TLS 1.3 のみをサポートし、TLS 1.0 および TLS 1.1 はサポートしていません。 データのセキュリティを確保するため、 TiDB Cloud Dedicated クラスターの CA 証明書は[AWS プライベート認証局](https://aws.amazon.com/private-ca/)でホストされています。CA 証明書の秘密鍵は、 [FIPS 140-2 レベル 3](https://csrc.nist.gov/projects/cryptographic-module-validation-program/Certificate/3139)セキュリティ標準を満たす AWS 管理のハードウェアセキュリティモジュール (HSM) に保存されます。 ## 前提条件 {#prerequisites} -- [パスワード認証](/tidb-cloud/tidb-cloud-password-authentication.md)または[SSO認証](/tidb-cloud/tidb-cloud-sso-authentication.md)経由してTiDB Cloudにログインし、次に[TiDB Cloud専用クラスタを作成する](/tidb-cloud/create-tidb-cluster.md)経由してログインします。 +- [パスワード認証](/tidb-cloud/tidb-cloud-password-authentication.md)または[SSO認証](/tidb-cloud/tidb-cloud-sso-authentication.md)経由してTiDB Cloudにログインし、次に[TiDB Cloud専用クラスターを作成する](/tidb-cloud/create-tidb-cluster.md)経由してログインします。 - 安全な設定でクラスターにアクセスするためのパスワードを設定します。 これを行うには、プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、 TiDB Cloud Dedicatedクラスターの行にある**「...」**をクリックし、 **「パスワード設定」**を選択します。パスワード設定で「パスワードの**自動生成」**をクリックすると、数字、大文字、小文字、特殊文字を含む16文字のルートパスワードが自動的に生成されます。 -## TiDB Cloud専用クラスタへのセキュリティ接続 {#secure-connection-to-a-tidb-cloud-dedicated-cluster} +## TiDB Cloud専用クラスターへのセキュリティ接続 {#secure-connection-to-a-tidb-cloud-dedicated-cluster} [TiDB Cloudコンソール](https://tidbcloud.com/)では、さまざまな接続方法の例を取得し、次のようにTiDB Cloud Dedicated クラスターに接続できます。 @@ -30,11 +30,11 @@ TiDB Cloudでは、TLS 接続の確立はTiDB Cloud Dedicated クラスタへの IPアクセスリストを設定していない場合は、初回接続前に**「IPアクセスリストの設定**」をクリックして設定してください。詳細については、 [IPアクセスリストを設定する](/tidb-cloud/configure-ip-access-list.md)参照してください。 -4. **「CA証明書」**をクリックして、TiDBクラスタへのTLS接続用のCA証明書をダウンロードしてください。CA証明書はデフォルトでTLS 1.2バージョンをサポートしています。 +4. **「CA証明書」**をクリックして、TiDBクラスターへのTLS接続用のCA証明書をダウンロードしてください。CA証明書はデフォルトでTLS 1.2バージョンをサポートしています。 > **注記：** > - > - ダウンロードしたCA証明書は、オペレーティングシステムのデフォルトのstorageパスに保存することも、別のstorageパスを指定することもできます。以降の手順では、コード例のCA証明書パスをご自身のCA証明書パスに置き換える必要があります。 + > - ダウンロードしたCA証明書は、オペレーティングシステムのデフォルトのストレージパスに保存することも、別のストレージパスを指定することもできます。以降の手順では、コード例のCA証明書パスをご自身のCA証明書パスに置き換える必要があります。 > - TiDB Cloud Dedicated では、クライアントに TLS 接続の使用を強制しません。また、 [`require_secure_transport`](/system-variables.md#require_secure_transport-new-in-v610)変数のユーザー定義構成は現在TiDB Cloud Dedicated ではサポートされていません。 5. 希望する接続方法を選択し、タブ上の接続文字列とサンプル コードを参照してクラスターに接続します。 @@ -44,7 +44,7 @@ TiDB Cloudでは、TLS 接続の確立はTiDB Cloud Dedicated クラスタへの
    -MySQL CLIクライアントはデフォルトでTLS接続を確立しようとします。TiDB Cloud Dedicatedクラスタに接続する場合は、 `ssl-mode`と`ssl-ca`設定する必要があります。 +MySQL CLIクライアントはデフォルトでTLS接続を確立しようとします。TiDB Cloud Dedicatedクラスターに接続する場合は、 `ssl-mode`と`ssl-ca`設定する必要があります。 ```shell mysql --connect-timeout 15 --ssl-mode=VERIFY_IDENTITY --ssl-ca=ca.pem --tls-version="TLSv1.2" -u root -h tidb.eqlfbdgthh8.clusters.staging.tidb-cloud.com -P 4000 -D test -p @@ -60,7 +60,7 @@ mysql --connect-timeout 15 --ssl-mode=VERIFY_IDENTITY --ssl-ca=ca.pem --tls-vers
    -[マイクリ](https://www.mycli.net/)指定すると、TLS関連のパラメータを使用する際にTLSが自動的に有効になります。TiDB Cloud Dedicatedクラスタに接続する場合は、 `ssl-ca`と`ssl-verify-server-cert`設定する必要があります。 +[マイクリ](https://www.mycli.net/)指定すると、TLS関連のパラメータを使用する際にTLSが自動的に有効になります。TiDB Cloud Dedicatedクラスターに接続する場合は、 `ssl-ca`と`ssl-verify-server-cert`設定する必要があります。 ```shell mycli --ssl-ca=ca.pem --ssl-verify-server-cert -u root -h tidb.eqlfbdgthh8.clusters.staging.tidb-cloud.com -P 4000 -D test diff --git a/tidb-cloud/tidb-cloud-tune-performance-overview.md b/tidb-cloud/tidb-cloud-tune-performance-overview.md index 783ba9370cdf4..e70cb238b3be7 100644 --- a/tidb-cloud/tidb-cloud-tune-performance-overview.md +++ b/tidb-cloud/tidb-cloud-tune-performance-overview.md @@ -47,13 +47,13 @@ TiDB Cloudコンソールには、ユーザー応答時間のトラブルシュ - **SQL文を**使用すると、ページ上のSQL実行を直接観察し、システムテーブルをクエリすることなくパフォーマンスの問題を簡単に特定できます。SQL文をクリックすると、クエリの実行プランをさらに詳しく表示して、トラブルシューティングや分析を行うことができます。SQLパフォーマンスチューニングの詳細については、 [SQLチューニングの概要](/tidb-cloud/tidb-cloud-sql-tuning-overview.md)参照してください。 - **Key Visualizer を**使用すると、TiDB のデータ アクセス パターンとデータ ホットスポットを観察できます。 -- [**メトリクス**](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) : このページでは、リクエスト単位、使用済みstorageサイズ、1 秒あたりのクエリ数、平均クエリ実行時間などのメトリックを表示できます。 +- [**メトリクス**](/tidb-cloud/built-in-monitoring.md#view-the-metrics-page) : このページでは、リクエスト単位、使用済みストレージサイズ、1 秒あたりのクエリ数、平均クエリ実行時間などのメトリックを表示できます。 追加のメトリックをリクエストするには、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 レイテンシーやパフォーマンスの問題が発生した場合は、分析とトラブルシューティングについては次のセクションの手順を参照してください。 -### TiDB クラスタ外部のボトルネック {#bottlenecks-outside-the-tidb-cluster} +### TiDB クラスター外部のボトルネック {#bottlenecks-outside-the-tidb-cluster} **「概要」**タブでレイテンシ(P80)を確認します。この値がユーザー応答時間のP80値よりも大幅に低い場合、主なボトルネックはTiDBクラスター外にある可能性があると判断できます。この場合、以下の手順に従ってボトルネックをトラブルシューティングできます。 @@ -65,7 +65,7 @@ TiDB Cloudコンソールには、ユーザー応答時間のトラブルシュ JDBC を使用せず、現在の TiDB クラスターの準備済みプランキャッシュ機能を最大限に活用したい場合は、クライアント側でプリペアドステートメントオブジェクトをキャッシュする必要があります。StmtPrepare および StmtClose の呼び出しをリセットする必要はありません。クエリごとに呼び出されるコマンドの数を 3 から 1 に減らします。パフォーマンス要件とクライアント側の変更の量によっては、ある程度の開発作業が必要になります。1 [PingCAPサポートチーム](/tidb-cloud/tidb-cloud-support.md)参照してください。 -### TiDBクラスタのボトルネック {#bottlenecks-in-the-tidb-cluster} +### TiDBクラスターのボトルネック {#bottlenecks-in-the-tidb-cluster} パフォーマンスのボトルネックが TiDB クラスター内にあると判断した場合は、次の操作を実行することをお勧めします。 @@ -97,7 +97,7 @@ SQL パフォーマンス チューニングの詳細については、 [SQLチ #### スケールアウト {#scale-out} -クラスター[概要](/tidb-cloud/monitor-tidb-cluster.md)ページで、storage容量、CPU使用率、TiKV IOレートのメトリクスを確認してください。いずれかのメトリクスが長期間上限に達している場合は、現在のクラスターサイズではビジネス要件を満たせない可能性があります。クラスター[PingCAPサポートチーム](/tidb-cloud/tidb-cloud-support.md)ご連絡いただき、スケールアウトが必要かどうか確認することをお勧めします。 +クラスター[概要](/tidb-cloud/monitor-tidb-cluster.md)ページで、ストレージ容量、CPU使用率、TiKV IOレートのメトリクスを確認してください。いずれかのメトリクスが長期間上限に達している場合は、現在のクラスターサイズではビジネス要件を満たせない可能性があります。クラスター[PingCAPサポートチーム](/tidb-cloud/tidb-cloud-support.md)ご連絡いただき、スケールアウトが必要かどうか確認することをお勧めします。 #### その他の問題 {#other-issues} diff --git a/tidb-cloud/tidb-node-group-management.md b/tidb-cloud/tidb-node-group-management.md index aa0b7eef1b6c6..bf760dc598173 100644 --- a/tidb-cloud/tidb-node-group-management.md +++ b/tidb-cloud/tidb-node-group-management.md @@ -18,7 +18,7 @@ summary: ビジネス ワークロードを分離するために TiDB ノード - 各 TiDB ノード グループには一意のエンドポイントがあります。 - TiDB ノード グループを削除すると、関連するネットワーク設定 (プライベート リンクや IP アクセス リストなど) も削除されます。 -- デフォルトグループ: クラスタを作成すると、デフォルトのTiDBノードグループが作成されます。そのため、各クラスタにはデフォルトグループが存在します。デフォルトグループは削除できません。 +- デフォルトグループ: クラスターを作成すると、デフォルトのTiDBノードグループが作成されます。そのため、各クラスターにはデフォルトグループが存在します。デフォルトグループは削除できません。 ## 前提条件 {#prerequisites} @@ -27,7 +27,7 @@ summary: ビジネス ワークロードを分離するために TiDB ノード > **注記**： > -> TiDBノードグループはクラスタ作成中に作成できません。クラスタが作成され、 **「使用可能」**状態になった後にグループを追加する必要があります。 +> TiDBノードグループはクラスター作成中に作成できません。クラスターが作成され、 **「使用可能」**状態になった後にグループを追加する必要があります。 ## TiDBノードグループを作成する {#create-a-tidb-node-group} @@ -37,19 +37,19 @@ TiDB ノード グループを作成するには、次の手順を実行しま 2. 左側のナビゲーション ペインで、 **[ノード]**をクリックします。 -3. 右上隅の**「変更」**をクリックします。「**クラスタの変更」**ページが表示されます。 +3. 右上隅の**「変更」**をクリックします。「**クラスターの変更」**ページが表示されます。 -4. **「クラスタの変更」**ページで**「+」**をクリックし、以下のように新しいTiDBノードグループを追加します。デフォルトのグループを直接使用することもできます。 +4. **「クラスターの変更」**ページで**「+」**をクリックし、以下のように新しいTiDBノードグループを追加します。デフォルトのグループを直接使用することもできます。 - TiDB - **vCPU + RAM** ：必要な[TiDBサイズ](/tidb-cloud/size-your-cluster.md#size-tidb)を選択してください。8 vCPUおよび16 GiB以上のメモリを搭載したTiDBノードのみがサポートされます。 - **ノードグループ**: **+**をクリックして新しい TiDB ノードグループを作成します。デフォルトのグループを使用し、 **DefaultGroup**フィールドに TiDB ノードの数を入力することもできます。 - TiKV - **vCPU + RAM** : 必要な[TiKVサイズ](/tidb-cloud/size-your-cluster.md#size-tikv)を選択します。 - - **ストレージ x ノード**:storageサイズと TiKV ノードの数を選択します。 + - **ストレージ x ノード**:ストレージサイズと TiKV ノードの数を選択します。 - TiFlash （オプション） - **vCPU + RAM** : 必要な[TiFlashサイズ](/tidb-cloud/size-your-cluster.md#size-tiflash)を選択します。 - - **ストレージ x ノード**:storageサイズとTiFlashノードの数を選択します。 + - **ストレージ x ノード**:ストレージサイズとTiFlashノードの数を選択します。 ![Create TiDB Node Group](/media/tidb-cloud/tidb-node-group-create.png) @@ -101,9 +101,9 @@ TiDBノードグループを作成しても、デフォルトグループのエ 6. このノード グループの新しい接続を作成するには、 **[プライベート エンドポイント接続の作成] を**クリックします。 - - AWS にデプロイされたクラスターについては、 [AWS PrivateLink 経由でTiDB Cloud専用クラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 + - AWS にデプロイされたクラスターについては、 [AWS PrivateLink 経由でTiDB Cloud専用クラスターに接続する](/tidb-cloud/set-up-private-endpoint-connections.md)を参照してください。 - - Google Cloud にデプロイされたクラスタについては、 [Google Cloud Private Service Connect 経由でTiDB Cloud専用クラスタに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)を参照してください。 + - Google Cloud にデプロイされたクラスターについては、 [Google Cloud Private Service Connect 経由でTiDB Cloud専用クラスターに接続する](/tidb-cloud/set-up-private-endpoint-connections-on-google-cloud.md)を参照してください。 > **注記**： > @@ -147,8 +147,8 @@ TiDB ノード グループの詳細を表示するには、次の手順を実 1. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲット クラスターの名前をクリックして概要ページに移動します。 2. 左側のナビゲーション ペインで、 **[ノード]**をクリックします。 -3. **「ノードマップ」**ページで、右上隅の**「変更」を**クリックします。「**クラスタの変更」**ページが表示されます。 -4. **「クラスタの変更」**ページでは、次の操作を実行できます。 +3. **「ノードマップ」**ページで、右上隅の**「変更」を**クリックします。「**クラスターの変更」**ページが表示されます。 +4. **「クラスターの変更」**ページでは、次の操作を実行できます。 - TiDB ノードの数を変更します。 - 新しいノード グループを追加します。 @@ -166,7 +166,7 @@ TiDB ノード グループを削除するには、次の手順を実行しま 1. [**クラスター**](https://tidbcloud.com/project/clusters)ページに移動し、ターゲット クラスターの名前をクリックして概要ページに移動します。 2. 左側のナビゲーション ペインで、 **[ノード]**をクリックします。 -3. **「ノードマップ」**ページで、右上隅の**「変更」を**クリックします。「**クラスタの変更」**ページが表示されます。 -4. **クラスタの変更**ページで、 TiDB ノード グループを削除します。 +3. **「ノードマップ」**ページで、右上隅の**「変更」を**クリックします。「**クラスターの変更」**ページが表示されます。 +4. **クラスターの変更**ページで、 TiDB ノード グループを削除します。 ![Delete the TiDB node group](/media/tidb-cloud/tidb-node-group-delete.png) diff --git a/tidb-cloud/tidb-node-group-overview.md b/tidb-cloud/tidb-node-group-overview.md index 33222c7f09320..c020568b24a8b 100644 --- a/tidb-cloud/tidb-node-group-overview.md +++ b/tidb-cloud/tidb-node-group-overview.md @@ -5,7 +5,7 @@ summary: TiDB ノード グループ機能の実装と使用シナリオにつ # TiDBノードグループの概要 {#overview-of-tidb-node-group} -[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスタに対してTiDBノードグループを作成できます。TiDBノードグループは、クラスタ内のコンピューティングノード（TiDBレイヤー）を物理的にグループ化し、各グループには特定の数のTiDBノードが含まれます。この構成により、グループ間のコンピューティングリソースが物理的に分離され、複数の業務シナリオにおいて効率的なリソース割り当てが可能になります。 +[TiDB Cloud専用](/tidb-cloud/select-cluster-tier.md#tidb-cloud-dedicated)クラスターに対してTiDBノードグループを作成できます。TiDBノードグループは、クラスター内のコンピューティングノード（TiDBレイヤー）を物理的にグループ化し、各グループには特定の数のTiDBノードが含まれます。この構成により、グループ間のコンピューティングリソースが物理的に分離され、複数の業務シナリオにおいて効率的なリソース割り当てが可能になります。 TiDBノードグループを使用すると、ビジネス要件に基づいてコンピューティングノードを複数のTiDBノードグループに分割し、各TiDBノードグループに固有の接続エンドポイントを設定できます。アプリケーションはそれぞれのエンドポイントを介してクラスターに接続し、リクエストは対応するノードグループにルーティングされて処理されます。これにより、あるグループでのリソースの過剰使用が他のグループに影響を与えることを防ぎます。 @@ -31,17 +31,17 @@ TiDBノードグループ内のすべてのノードは、対応するエンド ## シナリオ {#scenarios} -TiDBノードグループ機能は、TiDB Cloud Dedicatedクラスタのリソース割り当てを大幅に強化します。TiDBノードは計算専用であり、データを保存しません。この機能は、ノードを複数の物理グループに編成することで、あるグループでのリソースの過剰使用が他のグループに影響を与えないようにします。 +TiDBノードグループ機能は、TiDB Cloud Dedicatedクラスターのリソース割り当てを大幅に強化します。TiDBノードは計算専用であり、データを保存しません。この機能は、ノードを複数の物理グループに編成することで、あるグループでのリソースの過剰使用が他のグループに影響を与えないようにします。 この機能を使用すると、次のことが可能になります。 -- 異なるシステムから複数のアプリケーションを単一のTiDB Cloud Dedicatedクラスタに統合します。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作に影響を与えることはありません。TiDBノードグループ機能により、トランザクションアプリケーションの応答時間がデータ分析やバッチアプリケーションの影響を受けないことが保証されます。 +- 異なるシステムから複数のアプリケーションを単一のTiDB Cloud Dedicatedクラスターに統合します。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作に影響を与えることはありません。TiDBノードグループ機能により、トランザクションアプリケーションの応答時間がデータ分析やバッチアプリケーションの影響を受けないことが保証されます。 -- TiDB Cloud Dedicated クラスタ上で、既存の本番ロードのパフォーマンスに影響を与えることなく、インポートまたは DDL タスクを実行できます。インポートまたは DDL タスク用に、専用の TiDB ノードグループを作成できます。これらのタスクは CPU またはメモリリソースを大量に消費しますが、使用するリソースは専用の TiDB ノードグループ内のみであるため、他の TiDB ノードグループのワークロードには影響しません。 +- TiDB Cloud Dedicated クラスター上で、既存の本番ロードのパフォーマンスに影響を与えることなく、インポートまたは DDL タスクを実行できます。インポートまたは DDL タスク用に、専用の TiDB ノードグループを作成できます。これらのタスクは CPU またはメモリリソースを大量に消費しますが、使用するリソースは専用の TiDB ノードグループ内のみであるため、他の TiDB ノードグループのワークロードには影響しません。 -- すべてのテスト環境を単一のTiDBクラスタに統合するか、リソースを大量に消費するバッチタスクを専用のTiDBノードグループにグループ化します。このアプローチにより、ハードウェア使用率が向上し、運用コストが削減され、重要なアプリケーションが常に必要なリソースにアクセスできるようになります。 +- すべてのテスト環境を単一のTiDBクラスターに統合するか、リソースを大量に消費するバッチタスクを専用のTiDBノードグループにグループ化します。このアプローチにより、ハードウェア使用率が向上し、運用コストが削減され、重要なアプリケーションが常に必要なリソースにアクセスできるようになります。 -さらに、TiDBノードグループはスケールインとスケールアウトが容易です。高パフォーマンス要件の主要アプリケーションでは、必要に応じてTiDBノードをグループに割り当てることができます。要件がそれほど厳しくないアプリケーションでは、少数のTiDBノードから開始し、必要に応じてスケールアウトすることができます。TiDBノードグループ機能を効率的に使用することで、クラスタ数を削減し、運用と保守を簡素化し、管理コストを削減できます。 +さらに、TiDBノードグループはスケールインとスケールアウトが容易です。高パフォーマンス要件の主要アプリケーションでは、必要に応じてTiDBノードをグループに割り当てることができます。要件がそれほど厳しくないアプリケーションでは、少数のTiDBノードから開始し、必要に応じてスケールアウトすることができます。TiDBノードグループ機能を効率的に使用することで、クラスター数を削減し、運用と保守を簡素化し、管理コストを削減できます。 ## 制限と割り当て {#limitations-and-quotas} @@ -50,12 +50,12 @@ TiDBノードグループ機能は、TiDB Cloud Dedicatedクラスタのリソ - TiDB ノードグループは、AWS または Google Cloud 上のTiDB Cloud Dedicated クラスターでのみ作成できます。他のクラウドプロバイダーへのサポートは、近い将来に予定されています。 - 4 つの vCPU と 16 GiB のメモリを備えた TiDB クラスターは、TiDB ノード グループ機能をサポートしません。 - デフォルトでは、 TiDB Cloud Dedicated クラスターに最大 5 つの TiDB ノードグループを作成できます。さらにグループが必要な場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)お問い合わせください。 -- 各TiDBノードグループには、少なくとも1つのTiDBノードが含まれている必要があります。グループ内のノード数に制限はありませんが、 TiDB Cloud Dedicatedクラスタ内のTiDBノードの総数は150を超えてはなりません。 +- 各TiDBノードグループには、少なくとも1つのTiDBノードが含まれている必要があります。グループ内のノード数に制限はありませんが、 TiDB Cloud Dedicatedクラスター内のTiDBノードの総数は150を超えてはなりません。 - TiDB Cloudは、ノードグループの境界に関係なく、TiDBオーナーノード上で自動統計収集タスクを実行します。これらのタスクは、個々のTiDBノードグループ内で分離することはできません。 - v8.1.2 より前のバージョンの TiDB クラスターの場合、 `ADD INDEX`タスクを個々の TiDB ノード グループ内で分離することはできません。 ## SLAの影響 {#sla-impact} -TiDB Cloud [サービスレベル契約（SLA）](https://www.pingcap.com/legal/service-level-agreement-for-tidb-cloud-services/)によると、複数のTiDBノードを展開したTiDB Cloud Dedicatedクラスタの月間稼働率は最大99.99%に達します。しかし、TiDBノードグループを導入した後、各グループに1つのTiDBノードのみを含む複数のTiDBノードグループを作成すると、グループの高可用性が失われ、クラスタの月間稼働率は単一のTiDBノード展開モデル（つまり最大99.9%）に低下します。 +TiDB Cloud [サービスレベル契約（SLA）](https://www.pingcap.com/legal/service-level-agreement-for-tidb-cloud-services/)によると、複数のTiDBノードを展開したTiDB Cloud Dedicatedクラスターの月間稼働率は最大99.99%に達します。しかし、TiDBノードグループを導入した後、各グループに1つのTiDBノードのみを含む複数のTiDBノードグループを作成すると、グループの高可用性が失われ、クラスターの月間稼働率は単一のTiDBノード展開モデル（つまり最大99.9%）に低下します。 高可用性を確保するには、TiDB ノード グループごとに少なくとも 2 つの TiDB ノードを構成することをお勧めします。 diff --git a/tidb-cloud/tidb-x-architecture.md b/tidb-cloud/tidb-x-architecture.md index 5abf6c62c7886..3050971dfd016 100644 --- a/tidb-cloud/tidb-x-architecture.md +++ b/tidb-cloud/tidb-x-architecture.md @@ -5,9 +5,9 @@ summary: 共有ストレージとクラウドネイティブなアーキテク # TiDB Xアーキテクチャ {#tidb-x-architecture} -TiDB Xは、クラウドネイティブなオブジェクトstorageをTiDBの基盤とする新しい分散SQLアーキテクチャです。現在、 TiDB Cloud Starter、 Essential、Premiumで利用可能なこのアーキテクチャは、AI時代のワークロード向けに、柔軟なスケーラビリティ、予測可能なパフォーマンス、および最適化された総所有コスト（TCO）を実現します。 +TiDB Xは、クラウドネイティブなオブジェクトストレージをTiDBの基盤とする新しい分散SQLアーキテクチャです。現在、 TiDB Cloud Starter、 Essential、Premiumで利用可能なこのアーキテクチャは、AI時代のワークロード向けに、柔軟なスケーラビリティ、予測可能なパフォーマンス、および最適化された総所有コスト（TCO）を実現します。 -TiDB X は[クラシックTiDB](/tidb-architecture.md)の共有なしアーキテクチャからクラウドネイティブな共有ストレージアーキテクチャへの根本的な進化を表しています。共有永続storageレイヤーとしてオブジェクトstorageを活用することで、TiDB X はコンピューティングワークロードの分離を実現し、オンライントランザクションワークロードをリソース集約型のバックグラウンドタスクから分離します。 +TiDB X は[クラシックTiDB](/tidb-architecture.md)の共有なしアーキテクチャからクラウドネイティブな共有ストレージアーキテクチャへの根本的な進化を表しています。共有永続ストレージレイヤーとしてオブジェクトストレージを活用することで、TiDB X はコンピューティングワークロードの分離を実現し、オンライントランザクションワークロードをリソース集約型のバックグラウンドタスクから分離します。 このドキュメントでは、TiDB Xアーキテクチャを紹介し、TiDB Xの開発動機を説明し、従来のTiDBアーキテクチャと比較した主な革新点について説明します。 @@ -17,25 +17,25 @@ TiDB X は[クラシックTiDB](/tidb-architecture.md)の共有なしアーキ ### 従来のTiDBの強み {#strengths-of-classic-tidb} -従来のTiDBの共有なしアーキテクチャは、従来のモノリシックデータベースの限界を克服します。コンピューティングとstorageを分離し、 Raftコンセンサスアルゴリズムを利用することで、分散SQLワークロードに必要な耐障害性と拡張性を提供します。 +従来のTiDBの共有なしアーキテクチャは、従来のモノリシックデータベースの限界を克服します。コンピューティングとストレージを分離し、 Raftコンセンサスアルゴリズムを利用することで、分散SQLワークロードに必要な耐障害性と拡張性を提供します。 従来のTiDBアーキテクチャは、以下の基本的な機能を提供します。 - **水平スケーラビリティ**：読み取りと書き込みの両方のパフォーマンスにおいて、線形スケーリングをサポートします。クラスターは、毎秒数百万のクエリ（QPS）を処理し、数千万のテーブルにわたる1 PiBを超えるデータを管理できるように拡張できます。 -- **ハイブリッドトランザクションおよび分析処理（HTAP）** ：トランザクションワークロードと分析ワークロードを統合します。集約処理や結合処理といった負荷の高い処理をTiFlash （カラム型storageエンジン）にプッシュダウンすることで、複雑なETLパイプラインを必要とせずに、最新のトランザクションデータに対して予測可能なリアルタイム分析を実現します。 +- **ハイブリッドトランザクションおよび分析処理（HTAP）** ：トランザクションワークロードと分析ワークロードを統合します。集約処理や結合処理といった負荷の高い処理をTiFlash （カラム型ストレージエンジン）にプッシュダウンすることで、複雑なETLパイプラインを必要とせずに、最新のトランザクションデータに対して予測可能なリアルタイム分析を実現します。 - **非ブロッキング型スキーマ変更**：完全オンラインのDDL実装を採用しています。スキーマ変更によって読み取りや書き込みがブロックされないため、アプリケーションのレイテンシーや可用性への影響を最小限に抑えながらデータモデルを進化させることができます。 -- **高可用性**：シームレスなクラスタのアップグレードとスケーリング操作をサポートします。これにより、メンテナンスやリソース調整中も重要なサービスへのアクセスが維持されます。 +- **高可用性**：シームレスなクラスターのアップグレードとスケーリング操作をサポートします。これにより、メンテナンスやリソース調整中も重要なサービスへのアクセスが維持されます。 - **マルチクラウド対応**： Amazon Web Services (AWS)、Google Cloud、Microsoft Azure、Alibaba Cloudをサポートするオープンソースソリューションとして動作します。これによりAmazon Web Services (AWS)、Google Cloud、Microsoft Azureベンダーロックインのないクラウド中立性が実現します。 ### 従来のTiDBの課題 {#challenges-of-classic-tidb} -従来のTiDBの共有なしアーキテクチャは高い耐障害性を提供​​する一方で、ローカルノード上のstorageとコンピューティングの密結合は、極めて大規模な環境では制約をもたらします。データ量の増加とクラウドネイティブ要件の進化に伴い、いくつかの構造的な課題が生じています。 +従来のTiDBの共有なしアーキテクチャは高い耐障害性を提供​​する一方で、ローカルノード上のストレージとコンピューティングの密結合は、極めて大規模な環境では制約をもたらします。データ量の増加とクラウドネイティブ要件の進化に伴い、いくつかの構造的な課題が生じています。 - **拡張性の制限** - データ移動のオーバーヘッド：従来のTiDBでは、スケールアウト（ノードの追加）またはスケールイン（ノードの削除）操作を行う際に、ノード間でSSTファイルを物理的に移動させる必要がありました。大規模なデータセットの場合、この処理は時間がかかり、データ移動中のCPUとI/Oの消費量が多いため、オンラインのトラフィックパフォーマンスが低下する可能性があります。 - - ストレージエンジンのボトルネック：従来のTiDBの基盤となるRocksDBstorageエンジンは、グローバルミューテックスで保護された単一のLSMツリーを使用しています。この設計により、システムが大規模なデータセット（例えば、TiKVノードあたり6TiBを超えるデータ、または30万を超えるSSTファイル）を処理する際に限界が生じ、ハードウェア容量を十分に活用できなくなります。 + - ストレージエンジンのボトルネック：従来のTiDBの基盤となるRocksDBストレージエンジンは、グローバルミューテックスで保護された単一のLSMツリーを使用しています。この設計により、システムが大規模なデータセット（例えば、TiKVノードあたり6TiBを超えるデータ、または30万を超えるSSTファイル）を処理する際に限界が生じ、ハードウェア容量を十分に活用できなくなります。 - **安定性とパフォーマンスの干渉** @@ -43,13 +43,13 @@ TiDB X は[クラシックTiDB](/tidb-architecture.md)の共有なしアーキ - 物理的な分離の欠如：論理リージョンと物理的なSSTファイルの間には物理的な分離がありません。リージョンの移動（バランス調整）などの操作は、圧縮オーバーヘッドを発生させ、それがユーザーのクエリと直接競合するため、パフォーマンスの不安定性につながる可能性があります。 - - 書き込みスロットリング：書き込み負荷が高い場合、バックグラウンドの圧縮処理がフォアグラウンドの書き込みトラフィックに追いつかないと、従来のTiDBはstorageエンジンを保護するためにフロー制御メカニズムを作動させます。その結果、アプリケーションの書き込みスループットが制限され、レイテンシーが急上昇します。 + - 書き込みスロットリング：書き込み負荷が高い場合、バックグラウンドの圧縮処理がフォアグラウンドの書き込みトラフィックに追いつかないと、従来のTiDBはストレージエンジンを保護するためにフロー制御メカニズムを作動させます。その結果、アプリケーションの書き込みスループットが制限され、レイテンシーが急上昇します。 - **資源利用とコスト** - 過剰プロビジョニング：ピーク時のトラフィックやバックグラウンドメンテナンス時に安定性を維持し、パフォーマンスを確保するために、ユーザーは「ハイウォーターマーク」要件に基づいてハードウェアを過剰にプロビジョニングすることがよくあります。 - - 柔軟性に欠けるスケーリング：コンピューティングとstorageは密接に結びついているため、CPU使用率が低い場合でも、storage容量を増やすためだけに、高価でコンピューティング負荷の高いノードを追加せざるを得ない場合があります。 + - 柔軟性に欠けるスケーリング：コンピューティングとストレージは密接に結びついているため、CPU使用率が低い場合でも、ストレージ容量を増やすためだけに、高価でコンピューティング負荷の高いノードを追加せざるを得ない場合があります。 ### TiDB X の動機 {#motivation-for-tidb-x} @@ -57,7 +57,7 @@ TiDB Xへの移行は、データと物理的なコンピューティングリ - **スケーリングの高速化**：物理的なデータ移行の必要性を排除することで、スケーリング性能を最大10倍向上させます。 - **タスクの分離**：バックグラウンドのメンテナンス タスク（圧縮など）とオンラインのトランザクション トラフィックとの間で干渉が一切発生しないようにします。 -- **リソースの柔軟性**：コンピューティングリソースがstorage容量とは独立して拡張できる、真の「従量課金制」モデルを実装します。 +- **リソースの柔軟性**：コンピューティングリソースがストレージ容量とは独立して拡張できる、真の「従量課金制」モデルを実装します。 このアーキテクチャの開発に関する追加のコンテキストについては、ブログ投稿[TiDB Xの誕生秘話：起源、アーキテクチャ、そして今後の展望](https://www.pingcap.com/blog/tidbx-origins-architecture/)を参照してください。 @@ -69,17 +69,17 @@ TiDB Xは、従来のTiDB分散設計をクラウドネイティブに進化さ - **ゲートウェイと接続管理**：TiProxy（またはロードバランサー）は、クライアントとの永続的な接続を維持し、SQLトラフィックをシームレスにルーティングします。元々はオンラインアップグレードをサポートするために設計されたTiProxyは、現在では自然なゲートウェイコンポーネントとして機能します。 - **リージョンによる動的シャーディング**：TiKVは、リージョン（デフォルトでは256MiB）と呼ばれる範囲ベースのシャーディング単位を使用します。データは数百万のリージョンに分割され、システムはリージョンの配置、移動、およびノー​​ド間の負荷分散を自動的に管理します。 -TiDB X は、ローカルのシェアードstorageを**クラウドネイティブの共有ストレージ オブジェクトstorage**バックボーンに置き換えることにより、これらの基盤を進化させます。この移行により、「コンピューティング[コンピューティングとコンピューティングの分離](#separation-of-compute-and-compute)」モデルが可能になり、リソースを大量に消費するタスクをエラスティック プールにオフロードして、即時のスケーラビリティと予測可能なパフォーマンスを確保します。 +TiDB X は、ローカルのシェアードストレージを**クラウドネイティブの共有ストレージ オブジェクトストレージ**バックボーンに置き換えることにより、これらの基盤を進化させます。この移行により、「コンピューティング[コンピューティングとコンピューティングの分離](#separation-of-compute-and-compute)」モデルが可能になり、リソースを大量に消費するタスクをエラスティック プールにオフロードして、即時のスケーラビリティと予測可能なパフォーマンスを確保します。 TiDB Xのアーキテクチャは以下のとおりです。 ![TiDB X Architecture](/media/tidb-x/tidb-x-architecture.png) -### オブジェクトstorageのサポート {#object-storage-support} +### オブジェクトストレージのサポート {#object-ストレージ-support} -TiDB X は、Amazon S3 などのオブジェクトstorageを、すべてのデータの唯一の信頼できる情報源として使用します。データがローカルディスクに保存される従来のアーキテクチャとは異なり、TiDB X ではすべてのデータの永続的なコピーが**共有オブジェクトstorageレイヤー**に保存されます。上位の**共有キャッシュレイヤー**（行エンジンと列エンジン）は、低レイテンシーを確保するための高性能キャッシュとして機能します。 +TiDB X は、Amazon S3 などのオブジェクトストレージを、すべてのデータの唯一の信頼できる情報源として使用します。データがローカルディスクに保存される従来のアーキテクチャとは異なり、TiDB X ではすべてのデータの永続的なコピーが**共有オブジェクトストレージレイヤー**に保存されます。上位の**共有キャッシュレイヤー**（行エンジンと列エンジン）は、低レイテンシーを確保するための高性能キャッシュとして機能します。 -信頼できるデータは既にオブジェクトstorageに保存されているため、バックアップはS3に保存されたRaftの増分ログとメタデータのみに依存し、データ総量に関わらずバックアップ操作は数秒で完了します。スケールアウト操作中、新しいTiKVノードは既存のノードから大量のデータをコピーする必要はありません。代わりに、オブジェクトstorageに接続して必要なデータをオンデマンドでロードするため、スケールアウト操作が大幅に高速化されます。 +信頼できるデータは既にオブジェクトストレージに保存されているため、バックアップはS3に保存されたRaftの増分ログとメタデータのみに依存し、データ総量に関わらずバックアップ操作は数秒で完了します。スケールアウト操作中、新しいTiKVノードは既存のノードから大量のデータをコピーする必要はありません。代わりに、オブジェクトストレージに接続して必要なデータをオンデマンドでロードするため、スケールアウト操作が大幅に高速化されます。 ### 自動スケーリング機構 {#auto-scaling-mechanism} @@ -99,13 +99,13 @@ TiDB Xは、多様なワークロードが互いに干渉しないように、 ![Classic TiDB vs TiDB X architecture](/media/tidb-x/tidb-classic-vs-tidb-x-1.png) -- **エンジンの進化**：従来のTiDBでは、 Raftエンジンがマルチラフトログを管理し、RocksDBがローカルディスク上の物理データstorageを処理していました。TiDB Xでは、これらのコンポーネントは**新しいRFエンジン**（Raftエンジン）と**再設計されたKVエンジン**に置き換えられています。KVエンジンは、RocksDBに代わるLSMツリーstorageエンジンです。どちらの新しいエンジンも、高性能とオブジェクトstorageとのシームレスな統合に特化して最適化されています。 +- **エンジンの進化**：従来のTiDBでは、 Raftエンジンがマルチラフトログを管理し、RocksDBがローカルディスク上の物理データストレージを処理していました。TiDB Xでは、これらのコンポーネントは**新しいRFエンジン**（Raftエンジン）と**再設計されたKVエンジン**に置き換えられています。KVエンジンは、RocksDBに代わるLSMツリーストレージエンジンです。どちらの新しいエンジンも、高性能とオブジェクトストレージとのシームレスな統合に特化して最適化されています。 -- **コンピューティングワークロードの分離**：図中の点線は、オブジェクトstorageレイヤーへのバックグラウンドでの読み書き操作を表しています。TiDB Xでは、RF/KVエンジンとオブジェクトstorage間のこれらの相互作用はフォアグラウンドプロセスから分離されているため、バックグラウンド操作がオンライントラフィックのレイテンシーに影響を与えません。 +- **コンピューティングワークロードの分離**：図中の点線は、オブジェクトストレージレイヤーへのバックグラウンドでの読み書き操作を表しています。TiDB Xでは、RF/KVエンジンとオブジェクトストレージ間のこれらの相互作用はフォアグラウンドプロセスから分離されているため、バックグラウンド操作がオンライントラフィックのレイテンシーに影響を与えません。 ### 計算と計算の分離 {#separation-of-compute-and-compute} -従来のTiDBは既に計算処理（SQLレイヤー）とstorage（TiKV）を分離していますが、TiDB XではSQL層とstorage層の両方において、さらに分離レイヤーが追加されています。この設計により、オンラインのトランザクション処理ワークロード向けの**軽量な計算**処理と、リソース集約型の**バックグラウンド**タスク向けの高負荷な計算処理が区別されます。 +従来のTiDBは既に計算処理（SQLレイヤー）とストレージ（TiKV）を分離していますが、TiDB XではSQL層とストレージ層の両方において、さらに分離レイヤーが追加されています。この設計により、オンラインのトランザクション処理ワークロード向けの**軽量な計算**処理と、リソース集約型の**バックグラウンド**タスク向けの高負荷な計算処理が区別されます。 - **軽量コンピューティング**：ユーザークエリなどのOLTPワークロードDedicatedのリソース。 @@ -115,19 +115,19 @@ TiDB Xは、多様なワークロードが互いに干渉しないように、 DDL操作や大規模データインポートなどの負荷の高い計算タスクの場合、TiDB Xは、オンライントラフィックへの影響を最小限に抑えながら、これらのワークロードをフルスピードで実行するための柔軟な計算リソースを自動的にプロビジョニングできます。たとえば、インデックスを追加すると、データ量に応じてTiDBワーカー、コプロセッサーワーカー、およびTiKVワーカーが動的にプロビジョニングされます。これらのプロビジョニングされた柔軟な計算リソースは、オンライントラフィックを処理するTiDBおよびTiKVサーバーから分離されているため、リソースを大量に消費する操作が重要なOLTPクエリと競合することはありません。実際のシナリオでは、インデックス作成は従来のTiDBよりも最大5倍高速になり、オンラインサービスに影響を与えることもありません。 -### 共有なし環境から共有ストレージへの移行 {#transition-from-shared-nothing-to-shared-storage} +### 共有なし環境から共有ストレージへの移行 {#transition-from-shared-nothing-to-shared-ストレージ} -TiDB Xは、従来の**共有なし**アーキテクチャ（TiKVノード間でデータを物理的にコピーする必要があった）から、**共有ストレージ**アーキテクチャへと移行しました。TiDB Xでは、ローカルディスクではなく、オブジェクトstorage（Amazon S3など）がすべての永続データの唯一の信頼できる情報源として機能します。これにより、スケーリング操作中に大量のデータをコピーする必要がなくなり、迅速な拡張性を実現できます。 +TiDB Xは、従来の**共有なし**アーキテクチャ（TiKVノード間でデータを物理的にコピーする必要があった）から、**共有ストレージ**アーキテクチャへと移行しました。TiDB Xでは、ローカルディスクではなく、オブジェクトストレージ（Amazon S3など）がすべての永続データの唯一の信頼できる情報源として機能します。これにより、スケーリング操作中に大量のデータをコピーする必要がなくなり、迅速な拡張性を実現できます。 -オブジェクトstorageへの移行は、フォアグラウンドでの読み書きパフォーマンスを低下させません。 +オブジェクトストレージへの移行は、フォアグラウンドでの読み書きパフォーマンスを低下させません。 - 読み取り操作：軽量なリクエストはローカルキャッシュとディスクから処理されます。負荷の高い読み取りワークロードのみが、リモートの柔軟なコプロセッサワーカーにオフロードされます。 -- 書き込み操作：オブジェクトstorageとのやり取りは非同期で行われます。まず、 Raftログがローカルディスクに永続化され、 Raft WAL（ライトアヘッドログ）のチャンクがバックグラウンドでオブジェクトstorageにアップロードされます。 -- 圧縮: MemTable内のデータが満杯になり、ローカルディスクに書き込まれると、リージョンリーダーは SST ファイルをオブジェクトstorageにアップロードします。エラスティック圧縮ワーカーでリモート圧縮が完了すると、TiKV ノードに通知され、圧縮された SST ファイルをオブジェクトstorageからロードします。 +- 書き込み操作：オブジェクトストレージとのやり取りは非同期で行われます。まず、 Raftログがローカルディスクに永続化され、 Raft WAL（ライトアヘッドログ）のチャンクがバックグラウンドでオブジェクトストレージにアップロードされます。 +- 圧縮: MemTable内のデータが満杯になり、ローカルディスクに書き込まれると、リージョンリーダーは SST ファイルをオブジェクトストレージにアップロードします。エラスティック圧縮ワーカーでリモート圧縮が完了すると、TiKV ノードに通知され、圧縮された SST ファイルをオブジェクトストレージからロードします。 ### 柔軟な総所有コスト（従量課金制） {#elastic-tco-pay-as-you-go} -従来のTiDBでは、ピーク時のトラフィックとバックグラウンドタスクを同時に処理するために、クラスタが過剰にプロビジョニングされることがよくありました。TiDB Xは**オートスケーリング**に対応しており、ユーザーは消費したリソースに対してのみ料金を支払うことができます（従量課金制）。負荷の高いタスク用のバックグラウンドリソースは必要に応じてプロビジョニングされ、不要になった時点で解放されるため、無駄なコストを削減できます。 +従来のTiDBでは、ピーク時のトラフィックとバックグラウンドタスクを同時に処理するために、クラスターが過剰にプロビジョニングされることがよくありました。TiDB Xは**オートスケーリング**に対応しており、ユーザーは消費したリソースに対してのみ料金を支払うことができます（従量課金制）。負荷の高いタスク用のバックグラウンドリソースは必要に応じてプロビジョニングされ、不要になった時点で解放されるため、無駄なコストを削減できます。 TiDB X は、 [要求容量単位](/tidb-cloud/tidb-cloud-glossary.md#request-capacity-unit-rcu)(RCU) を使用してプロビジョニングされたコンピューティング容量を測定します。1 RCU は、一定数の SQL リクエストを処理できる固定量のコンピューティング リソースを提供します。プロビジョニングする RCU の数によって、TiDB X インスタンスのベースラインのパフォーマンスとスループット容量が決まります。上限を設定することで、弾力的なスケーリングのメリットを享受しながらコストを管理できます。 @@ -135,13 +135,13 @@ TiDB X は、 [要求容量単位](/tidb-cloud/tidb-cloud-glossary.md#request-ca 従来の TiDB では、各 TiKV ノードで単一の RocksDB インスタンスが実行され、すべてのリージョンのデータが 1 つの大きな LSM ツリーに格納されます。数千のリージョンのデータが混在するため、リージョンの移動、スケールアウト、スケールインなどの操作によって大規模な圧縮がトリガーされる可能性があります。これにより、CPU および I/O リソースが大幅に消費され、オンライン トラフィックに影響が出る可能性があります。単一の LSM ツリーはグローバル ミューテックスによって保護されています。データ サイズが大きくなると、大規模 (たとえば、TiKV ノードあたり 6 TiB を超えるデータ、または 300,000 を超える SST ファイル) では、グローバル ミューテックス ロックの競合が増加し、読み取りと書き込みの両方のパフォーマンスに影響が出る可能性があります。 -TiDB X は、単一の LSM ツリーから**LSM フォレスト**へと移行することで、storageエンジンを再設計しました。論理的なリージョン抽象化は維持しつつ、TiDB X は各リージョンに独自の独立した LSM ツリーを割り当てます。この物理的な分離により、スケーリング、リージョンの移動、データ ロードなどの操作中にリージョン間圧縮のオーバーヘッドが解消されます。1 つのリージョンに対する操作は、そのリージョンのツリー内に限定され、グローバルなミューテックスの競合は発生しません。 +TiDB X は、単一の LSM ツリーから**LSM フォレスト**へと移行することで、ストレージエンジンを再設計しました。論理的なリージョン抽象化は維持しつつ、TiDB X は各リージョンに独自の独立した LSM ツリーを割り当てます。この物理的な分離により、スケーリング、リージョンの移動、データ ロードなどの操作中にリージョン間圧縮のオーバーヘッドが解消されます。1 つのリージョンに対する操作は、そのリージョンのツリー内に限定され、グローバルなミューテックスの競合は発生しません。 ![Classic TiDB vs TiDB X](/media/tidb-x/tidb-classic-vs-tidb-x-2.png) ### 迅速かつ柔軟な拡張性 {#rapid-elastic-scalability} -TiDB Xは、共有オブジェクトstorageにデータを保存し、各リージョンを独立したLSMツリーで管理することで、TiKVノードの追加または削除時に物理的なデータ移行や大規模なデータ圧縮を行う必要がなくなります。その結果、スケーリング操作は従来のTiDBに比べて**5～10倍高速化**され、オンラインワークロードのレイテンシーも安定的に維持されます。 +TiDB Xは、共有オブジェクトストレージにデータを保存し、各リージョンを独立したLSMツリーで管理することで、TiKVノードの追加または削除時に物理的なデータ移行や大規模なデータ圧縮を行う必要がなくなります。その結果、スケーリング操作は従来のTiDBに比べて**5～10倍高速化**され、オンラインワークロードのレイテンシーも安定的に維持されます。 ## アーキテクチャ比較の概要 {#architecture-comparison-summary} @@ -149,14 +149,14 @@ TiDB Xは、共有オブジェクトstorageにデータを保存し、各リー | 特徴 | クラシックTiDB | TiDB X | 主なメリット（TiDB X） | | ----------- | ------------------------------------- | ------------------------------------------------ | ----------------------------------------------- | -| アーキテクチャ | 共有なし（データはローカルディスクに保存される） | 共有ストレージ（権威ある永続storageとしてのオブジェクトstorage） | オブジェクトstorageはクラウドネイティブな弾力性を実現する | +| アーキテクチャ | 共有なし（データはローカルディスクに保存される） | 共有ストレージ（権威ある永続ストレージとしてのオブジェクトストレージ） | オブジェクトストレージはクラウドネイティブな弾力性を実現する | | 安定性 | フォアグラウンドタスクとバックグラウンドタスクは同じリソースを共有する | コンピューティングとコンピューティングの分離（高負荷タスク向けの柔軟なコンピューティングプール） | 書き込み負荷の高いワークロードやメンテナンスワークロード下でOLTPワークロードを保護します。 | | パフォーマンス | OLTPとバックグラウンドタスクはCPUとI/Oを競合する。 | 重負荷作業Dedicatedの弾性プール | OLTPのレイテンシーを低減しつつ、負荷の高いタスクをより迅速に完了させる。 | -| スケーリングメカニズム | 物理データ移行（TiKVノード間でのSSTファイルのコピー） | TiKVノードはオブジェクトstorageを介してのみSSTファイルを読み書きします。 | スケールアウトとスケールインが5～10倍高速化 | +| スケーリングメカニズム | 物理データ移行（TiKVノード間でのSSTファイルのコピー） | TiKVノードはオブジェクトストレージを介してのみSSTファイルを読み書きします。 | スケールアウトとスケールインが5～10倍高速化 | | ストレージエンジン | TiKVノードごとに1つのLSMツリー（RocksDB） | LSMフォレスト（リージョンごとに独立したLSMツリーが1つ） | グローバルミューテックスの競合を解消し、圧縮干渉を軽減します。 | | DDL実行 | DDLはローカルCPUとI/Oをめぐってユーザーのトラフィックと競合する。 | DDLを柔軟なコンピューティングリソースにオフロード | スキーマ変更がより迅速になり、レイテンシーもより予測可能になります。 | | コストモデル | ピーク時のワークロードに対応するため、オーバープロビジョニングが必要 | 柔軟な総所有コスト（従量課金制） | 実際の資源消費量に応じてのみ料金を支払う | -| バックアップ | データ量に依存する物理バックアップ | オブジェクトstorage統合によるメタデータ駆動型 | バックアップ操作が大幅に高速化 | +| バックアップ | データ量に依存する物理バックアップ | オブジェクトストレージ統合によるメタデータ駆動型 | バックアップ操作が大幅に高速化 | ## 関連リソース {#related-resources} diff --git a/tidb-cloud/tidbx-instance-move-faq.md b/tidb-cloud/tidbx-instance-move-faq.md index ed673254e53a1..974bb42658696 100644 --- a/tidb-cloud/tidbx-instance-move-faq.md +++ b/tidb-cloud/tidbx-instance-move-faq.md @@ -11,10 +11,10 @@ TiDB Xインスタンスは、 [TiDB Xアーキテクチャ](/tidb-cloud/tidb-x- ## TiDB Cloudコンソールで、TiDB Cloud StarterとEssentialインスタンスを移動するように促されるのはなぜですか？ {#why-does-the-tidb-cloud-console-prompt-me-to-move-my-tidb-cloud-starter-and-essential-instances} -2026年4月15日以前は、 TiDB Cloudは単一の**TiDB専用プロジェクト**タイプを使用してすべてのTiDB Cloudリソースを管理していました。このようなプロジェクトには、TiDB Cloud DedicatedクラスタとTiDB Xインスタンスが混在することができました。しかし、1つのプロジェクトに異なるリソースタイプを混在させると、次のような理由で管理が複雑化しました。 +2026年4月15日以前は、 TiDB Cloudは単一の**TiDB専用プロジェクト**タイプを使用してすべてのTiDB Cloudリソースを管理していました。このようなプロジェクトには、TiDB Cloud DedicatedクラスターとTiDB Xインスタンスが混在することができました。しかし、1つのプロジェクトに異なるリソースタイプを混在させると、次のような理由で管理が複雑化しました。 - TiDB専用プロジェクトは、元々 TiDB Cloud Dedicatedクラスター向けに設計されたものです。 -- TiDB XインスタンスとTiDB Cloud Dedicatedクラスタは、動作と管理モデルが異なります。 +- TiDB XインスタンスとTiDB Cloud Dedicatedクラスターは、動作と管理モデルが異なります。 2026年4月15日より、 TiDB Cloudは異なるリソースタイプを明確に区別するために、個別のプロジェクトタイプを導入します。各プロジェクトタイプは、それぞれ独自のリソースタイプをホストするようになります。 @@ -22,7 +22,7 @@ TiDB Xインスタンスは、 [TiDB Xアーキテクチャ](/tidb-cloud/tidb-x- - **TiDB Xプロジェクト**：TiDB Xインスタンス向け - **TiDB X仮想プロジェクト**：どのTiDB Xプロジェクトにもグループ化されていないTiDB Xインスタンス用 -TiDB Xプロジェクトは軽量で、TiDB Xインスタンスではオプションですが、 TiDB Cloud Dedicatedクラスタでは専用プロジェクトが必須です。これらのリソースを分離することで、より一貫性のあるユーザーエクスペリエンスが実現し、どのプロジェクト機能が適用されるかについての混乱が解消されます。 +TiDB Xプロジェクトは軽量で、TiDB Xインスタンスではオプションですが、 TiDB Cloud Dedicatedクラスターでは専用プロジェクトが必須です。これらのリソースを分離することで、より一貫性のあるユーザーエクスペリエンスが実現し、どのプロジェクト機能が適用されるかについての混乱が解消されます。 この分離の結果、専用プロジェクトにはTiDB Xインスタンスを含めることができなくなりました。組織が専用プロジェクトに既存のTiDB Cloud StarterまたはEssentialリソースを持っている場合、 TiDB Cloudは新しいリソースモデルに合わせてそれらをTiDB Xプロジェクトに移動するように促します。 @@ -32,7 +32,7 @@ TiDB Cloudは、異なるリソースタイプとユースケースに対応す - **TiDB専用プロジェクト**：このプロジェクトタイプは、 TiDB Cloud Dedicatedクラスターでのみ使用されます。 - - この機能を使うと、RBAC、ネットワーク、メンテナンス、アラート購読、暗号化アクセスなど、 TiDB Cloud Dedicatedクラスタの設定をプロジェクトごとに個別に管理できます。 + - この機能を使うと、RBAC、ネットワーク、メンテナンス、アラート購読、暗号化アクセスなど、 TiDB Cloud Dedicatedクラスターの設定をプロジェクトごとに個別に管理できます。 - 各TiDB Cloud Dedicatedクラスターは、専用プロジェクトに属していなければなりません。 - TiDB Cloud Dedicatedクラスターは、インフラストラクチャの結合により、プロジェクト間で移動することはできません。 @@ -120,7 +120,7 @@ TiDB Cloudのリソースごとに異なるプロジェクトタイプが導入 この移行には追加費用はかかりません。 -移行後、TiDB XインスタンスはTiDB Xプロジェクト（または組織レベル）を通じて管理でき、 TiDB Cloud Dedicatedクラスタは専用プロジェクトを通じて引き続き管理できます。 +移行後、TiDB XインスタンスはTiDB Xプロジェクト（または組織レベル）を通じて管理でき、 TiDB Cloud Dedicatedクラスターは専用プロジェクトを通じて引き続き管理できます。 ## 移行後にはどのような対応が必要ですか？ {#what-actions-are-required-after-migration} diff --git a/tidb-cloud/tiproxy-management.md b/tidb-cloud/tiproxy-management.md index 99e05b896e325..f98728dc90d79 100644 --- a/tidb-cloud/tiproxy-management.md +++ b/tidb-cloud/tiproxy-management.md @@ -13,11 +13,11 @@ summary: TiProxyの有効化、無効化、表示、および変更方法につ ## TiProxyを有効にする {#enable-tiproxy} -TiProxyは、任意のTiDBノードグループ内の新規クラスタまたは既存クラスタのどちらでも有効にできます。 +TiProxyは、任意のTiDBノードグループ内の新規クラスターまたは既存クラスターのどちらでも有効にできます。 ### TiProxyノードのサイズと数を決定する {#decide-the-size-and-number-of-tiproxy-nodes} -TiProxyノードのサイズと数は、 TiDB Cloud DedicatedクラスタのQPS（1秒あたりのクエリ数）とネットワーク帯域幅の両方に依存します。ネットワーク帯域幅は、クライアントのリクエスト帯域幅とTiDBのレスポンス帯域幅の合計です。 +TiProxyノードのサイズと数は、 TiDB Cloud DedicatedクラスターのQPS（1秒あたりのクエリ数）とネットワーク帯域幅の両方に依存します。ネットワーク帯域幅は、クライアントのリクエスト帯域幅とTiDBのレスポンス帯域幅の合計です。 以下の表は、各TiProxyサイズにおける最大QPSとネットワーク帯域幅を示しています。 @@ -42,11 +42,11 @@ TiProxyノードのサイズと数は、 TiDB Cloud DedicatedクラスタのQPS > > TiProxyを有効にすると、該当するTiDBノードグループ内のTiDBノードがローリング再起動され、再起動中に既存の接続が切断されます。また、新しい接続の作成に最大30秒かかる場合があります。TiProxyは必ずメンテナンス期間中に有効にしてください。 -既存のクラスタで TiProxy を有効にするには、次の手順を実行します。 +既存のクラスターで TiProxy を有効にするには、次の手順を実行します。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして、その概要ページに移動します。 -2. 右上隅の**「…」**をクリックし、ドロップダウンメニューから**「変更」**をクリックします。 **「クラスタの変更」**ページが表示されます。 -3. **「クラスタの変更」**ページで、TiProxyのトグルをクリックし、TiProxyのサイズと数を選択します。 +2. 右上隅の**「…」**をクリックし、ドロップダウンメニューから**「変更」**をクリックします。 **「クラスターの変更」**ページが表示されます。 +3. **「クラスターの変更」**ページで、TiProxyのトグルをクリックし、TiProxyのサイズと数を選択します。 ![Enable TiProxy](/media/tidb-cloud/tiproxy-enable-tiproxy.png) @@ -55,7 +55,7 @@ TiProxyノードのサイズと数は、 TiDB Cloud DedicatedクラスタのQPS - TiDBノードグループには、少なくとも2つのTiDBノードが必要です。 - TiDBノードのサイズは、少なくとも4つのvCPUである必要があります。 - 組織内の TiProxy ノードのデフォルトの最大数は`10`です。詳細については、[制限と割り当て](/tidb-cloud/limitations-and-quotas.md)参照してください。 -- TiDBクラスタのバージョンはv6.5.0以降である必要があります。 +- TiDBクラスターのバージョンはv6.5.0以降である必要があります。 ## TiProxyを無効にする {#disable-tiproxy} @@ -66,8 +66,8 @@ TiProxyノードのサイズと数は、 TiDB Cloud DedicatedクラスタのQPS TiProxyを無効にするには、以下の手順を実行してください。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして、その概要ページに移動します。 -2. 右上隅の**「…」**をクリックし、ドロップダウンメニューから**「変更」**をクリックします。 **「クラスタの変更」**ページが表示されます。 -3. 「**クラスタの変更」**ページで、TiProxyのトグルをクリックしてTiProxyを無効にします。 +2. 右上隅の**「…」**をクリックし、ドロップダウンメニューから**「変更」**をクリックします。 **「クラスターの変更」**ページが表示されます。 +3. 「**クラスターの変更」**ページで、TiProxyのトグルをクリックしてTiProxyを無効にします。 ![Disable TiProxy](/media/tidb-cloud/tiproxy-disable-tiproxy.png) @@ -118,8 +118,8 @@ TiProxyの請求書を表示するには、以下の手順を実行してくだ TiProxyをスケールインまたはスケールアウトするには、以下の手順を実行します。 1. [TiDB Cloudコンソール](https://tidbcloud.com/)で、[**私のTiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud Dedicatedクラスターの名前をクリックして、その概要ページに移動します。 -2. 右上隅の**「…」**をクリックし、ドロップダウンメニューから**「変更」**をクリックします。 **「クラスタの変更」**ページが表示されます。 -3. **「クラスタの変更」**ページで、TiProxyノードの数を変更します。 +2. 右上隅の**「…」**をクリックし、ドロップダウンメニューから**「変更」**をクリックします。 **「クラスターの変更」**ページが表示されます。 +3. **「クラスターの変更」**ページで、TiProxyノードの数を変更します。 ![Modify TiProxy](/media/tidb-cloud/tiproxy-enable-tiproxy.png) diff --git a/tidb-cloud/transaction-concepts.md b/tidb-cloud/transaction-concepts.md index b6a5ccb2d9a75..4719e5b7a58cf 100644 --- a/tidb-cloud/transaction-concepts.md +++ b/tidb-cloud/transaction-concepts.md @@ -3,7 +3,7 @@ title: Transactions summary: TiDB Cloudのトランザクション概念について学習します。 --- -# 取引 {#transactions} +# トランザクション {#transactions} TiDB は完全な分散トランザクションを提供し、モデルには[Google パーコレーター](https://research.google.com/pubs/pub36726.html)に基づいたいくつかの最適化が施されています。 diff --git a/tidb-cloud/troubleshoot-import-access-denied-error.md b/tidb-cloud/troubleshoot-import-access-denied-error.md index ec9843c6dc67e..978b0751919c7 100644 --- a/tidb-cloud/troubleshoot-import-access-denied-error.md +++ b/tidb-cloud/troubleshoot-import-access-denied-error.md @@ -48,7 +48,7 @@ TiDB Cloudコンソールの「**データインポート」**ページで**「 ### IAMロールが存在するかどうかを確認する {#check-whether-the-iam-role-exists} -IAMロールが存在しない場合は、 [Amazon S3 アクセスを構成する](/tidb-cloud/dedicated-external-storage.md#configure-amazon-s3-access)手順に従ってロールを作成します。 +IAMロールが存在しない場合は、 [Amazon S3 アクセスを構成する](/tidb-cloud/dedicated-external-ストレージ.md#configure-amazon-s3-access)手順に従ってロールを作成します。 ### 外部IDが正しく設定されているか確認してください {#check-whether-the-external-id-is-set-correctly} @@ -148,7 +148,7 @@ IAMユーザーのポリシーを確認するには、次の手順を実行し このサンプル ポリシーでは、次の点に注意してください。 -- `"arn:aws:s3:::tidb-cloud-source-data/mydata/*"`の`"arn:aws:s3:::tidb-cloud-source-data"`はサンプルの S3 バケット ARN で、 `/mydata/*`データstorage用に S3 バケットのルートレベルでカスタマイズできるディレクトリです。ディレクトリの末尾は`/*` （例： `"//*"` ）でなければなりません。 `/*`追加されていない場合、 `AccessDenied`エラーが発生します。 +- `"arn:aws:s3:::tidb-cloud-source-data/mydata/*"`の`"arn:aws:s3:::tidb-cloud-source-data"`はサンプルの S3 バケット ARN で、 `/mydata/*`データストレージ用に S3 バケットのルートレベルでカスタマイズできるディレクトリです。ディレクトリの末尾は`/*` （例： `"//*"` ）でなければなりません。 `/*`追加されていない場合、 `AccessDenied`エラーが発生します。 - カスタマー管理のキー暗号化で AWS Key Management Service キー (SSE-KMS) を有効にしている場合は、次の設定がポリシーに含まれていることを確認してください。1 `"arn:aws:kms:ap-northeast-1:105880447796:key/c3046e91-fdfc-4f3a-acff-00597dd3801f"`バケットのサンプル KMS キーです。 diff --git a/tidb-cloud/tune-performance.md b/tidb-cloud/tune-performance.md index 275047ed3a1e6..0a74ba3c36714 100644 --- a/tidb-cloud/tune-performance.md +++ b/tidb-cloud/tune-performance.md @@ -18,7 +18,7 @@ TiDB Cloud は、パフォーマンスを分析するために[遅いクエリ]( -- スロークエリを使用すると、TiDB内のすべてのスロークエリを検索して表示できます。クラスタ実例実行プラン、SQL 実行情報、その他の詳細を表示して、各低速クエリのボトルネックを調査します。 +- スロークエリを使用すると、TiDB内のすべてのスロークエリを検索して表示できます。クラスター実例実行プラン、SQL 実行情報、その他の詳細を表示して、各低速クエリのボトルネックを調査します。 - ステートメント分析SQL文ページ上の SQL 実行を直接観察し、システム テーブルをクエリせずにパフォーマンスの問題を簡単に見つけることができます。 @@ -62,7 +62,7 @@ TiDB Cloud は、パフォーマンスを分析するために[遅いクエリ]( デフォルトでは、300 ミリ秒以上かかる SQL クエリは遅いクエリと見なされます。 -TiDBで遅いクエリを表示するにはクラスタ実例、次の手順を実行します。 +TiDBで遅いクエリを表示するにはクラスター実例、次の手順を実行します。 diff --git a/tidb-cloud/upgrade-tidb-cluster.md b/tidb-cloud/upgrade-tidb-cluster.md index 58a8b2fa69fc9..ca32d87ca7467 100644 --- a/tidb-cloud/upgrade-tidb-cluster.md +++ b/tidb-cloud/upgrade-tidb-cluster.md @@ -3,7 +3,7 @@ title: Upgrade a TiDB Cluster summary: TiDB クラスターをアップグレードする方法を学びます。 --- -# TiDBクラスタのアップグレード {#upgrade-a-tidb-cluster} +# TiDBクラスターのアップグレード {#upgrade-a-tidb-cluster} このドキュメントでは、 TiDB Cloud上の TiDB クラスターをアップグレードする方法について説明します。TiDB Cloud は、 TiDB バージョンをアップグレードするための 2 つのアップグレード メカニズムを提供します。 @@ -18,14 +18,14 @@ TiDB バージョンが低すぎる場合、 TiDB Cloud は定期的に均一に - クラウドプロバイダー: AWS、Azure、Google Cloud、または Alibaba Cloud -- クラスタ名: xxx +- クラスター名: xxx - クラウドプロバイダー: AWS、Azure、または Google Cloud -- クラスタ名: xxx +- クラスター名: xxx diff --git a/tidb-cloud/use-chat2query-api.md b/tidb-cloud/use-chat2query-api.md index 6c321ee4b4f37..d54812236718a 100644 --- a/tidb-cloud/use-chat2query-api.md +++ b/tidb-cloud/use-chat2query-api.md @@ -154,7 +154,7 @@ curl --digest --user ${PUBLIC_KEY}:${PRIVATE_KEY} --request POST 'https:// -# TiDBコンフィグレーションファイル {#tidb-configuration-file} +# TiDB設定ファイル {#tidb-configuration-file} TiDB 設定ファイルは、コマンドラインパラメータよりも多くのオプションをサポートしています。デフォルトの設定ファイル[`config.toml.example`](https://github.com/pingcap/tidb/blob/release-8.5/pkg/config/config.toml.example)をダウンロードし、名前を`config.toml`に変更することができます。このドキュメントでは、 [コマンドラインオプション](/command-line-flags-for-tidb-configuration.md)に関係のないオプションについてのみ説明します。 @@ -45,7 +45,7 @@ TiDB 設定ファイルは、コマンドラインパラメータよりも多く ### temp-dir v6.3.0 の新機能 {#code-temp-dir-code-span-class-version-mark-new-in-v6-3-0-span} -- TiDBが一時データを保存するために使用するファイルシステムの場所です。TiDBノードにローカルstorageを必要とする機能がある場合、TiDBはこの場所に一時データを保存します。 +- TiDBが一時データを保存するために使用するファイルシステムの場所です。TiDBノードにローカルストレージを必要とする機能がある場合、TiDBはこの場所に一時データを保存します。 - インデックスを作成するときに、 [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)有効にすると、新しく作成されたインデックスのバックフィルが必要なデータは、最初に TiDB のローカル一時ディレクトリに保存され、その後 TiKV にバッチでインポートされるため、インデックスの作成が高速化されます。 - [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)使用してデータをインポートすると、ソートされたデータは最初に TiDB のローカル一時ディレクトリに保存され、その後 TiKV にバッチでインポートされます。 - デフォルト値: `"/tmp/tidb"` @@ -54,28 +54,28 @@ TiDB 設定ファイルは、コマンドラインパラメータよりも多く > > ディレクトリが存在しない場合、TiDBは起動時に自動的に作成します。ディレクトリの作成に失敗した場合、またはTiDBにそのディレクトリに対する読み取りおよび書き込み権限がない場合、予期しない問題[`Fast Online DDL`](/system-variables.md#tidb_ddl_enable_fast_reorg-new-in-v630)発生する可能性があります。 -### oom-use-tmp-storage {#code-oom-use-tmp-storage-code} +### oom-use-tmp-ストレージ {#code-oom-use-tmp-ストレージ-code} > **警告：** > -> バージョン6.3.0以降、この設定項目は非推奨となり、システム変数[`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom)に置き換えられました。TiDBクラスターをバージョン6.3.0以降にアップグレードすると、この変数は自動的に`oom-use-tmp-storage`に初期化されます。その後、値`oom-use-tmp-storage`を変更しても有効に**なりません**。 +> バージョン6.3.0以降、この設定項目は非推奨となり、システム変数[`tidb_enable_tmp_ストレージ_on_oom`](/system-variables.md#tidb_enable_tmp_ストレージ_on_oom)に置き換えられました。TiDBクラスターをバージョン6.3.0以降にアップグレードすると、この変数は自動的に`oom-use-tmp-ストレージ`に初期化されます。その後、値`oom-use-tmp-ストレージ`を変更しても有効に**なりません**。 -- 単一の SQL ステートメントがシステム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)で指定されたメモリクォータを超えた場合に、一部の演算子の一時storageを有効にするかどうかを制御します。 +- 単一の SQL ステートメントがシステム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)で指定されたメモリクォータを超えた場合に、一部の演算子の一時ストレージを有効にするかどうかを制御します。 - デフォルト値: `true` -### tmp-storage-path {#code-tmp-storage-path-code} +### tmp-ストレージ-path {#code-tmp-ストレージ-path-code} -- 単一の SQL ステートメントがシステム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)で指定されたメモリクォータを超えた場合に、一部の演算子の一時storageパスを指定します。 -- デフォルト値: `/_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-storage` 。 `MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=`は`:/:`の`Base64`エンコード結果です。 -- この構成は、システム変数[`tidb_enable_tmp_storage_on_oom`](/system-variables.md#tidb_enable_tmp_storage_on_oom)が`ON`の場合にのみ有効になります。 +- 単一の SQL ステートメントがシステム変数[`tidb_mem_quota_query`](/system-variables.md#tidb_mem_quota_query)で指定されたメモリクォータを超えた場合に、一部の演算子の一時ストレージパスを指定します。 +- デフォルト値: `/_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-ストレージ` 。 `MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=`は`:/:`の`Base64`エンコード結果です。 +- この構成は、システム変数[`tidb_enable_tmp_ストレージ_on_oom`](/system-variables.md#tidb_enable_tmp_ストレージ_on_oom)が`ON`の場合にのみ有効になります。 -### tmp-storage-quota {#code-tmp-storage-quota-code} +### tmp-ストレージ-quota {#code-tmp-ストレージ-quota-code} -- storageのクォータを`tmp-storage-path`で指定します。単位はバイトです。 +- ストレージのクォータを`tmp-ストレージ-path`で指定します。単位はバイトです。 - 単一の SQL 文が一時ディスクを使用し、TiDBサーバーの一時ディスクの合計容量がこの設定値を超えると、現在の SQL 操作はキャンセルされ、エラー`Out of Global Storage Quota!`が返されます。 - この設定の値が`0`未満の場合、上記のチェックと制限は適用されません。 - デフォルト値: `-1` -- `tmp-storage-path`の残りの使用可能なstorageが`tmp-storage-quota`で定義された値よりも少ない場合、 TiDBサーバーは起動時にエラーを報告し、終了します。 +- `tmp-ストレージ-path`の残りの使用可能なストレージが`tmp-ストレージ-quota`で定義された値よりも少ない場合、 TiDBサーバーは起動時にエラーを報告し、終了します。 ### lease {#code-lease-code} @@ -90,7 +90,7 @@ TiDB 設定ファイルは、コマンドラインパラメータよりも多く - `compatible-kill-query` [`enable-global-kill`](#enable-global-kill-new-in-v610) `false`に設定されている場合にのみ有効になります。 - [`enable-global-kill`](#enable-global-kill-new-in-v610)が`false`の場合、 `compatible-kill-query`クエリを強制終了するときに`TIDB`キーワードを追加する必要があるかどうかを制御します。 - `compatible-kill-query`が`false`の場合、TiDB における`KILL xxx`の動作は MySQL とは異なります。TiDB でクエリを強制終了するには、 `KILL TIDB xxx`のように`TIDB`キーワードを付加する必要があります。 - - `compatible-kill-query`が`true`の場合、TiDB でクエリを強制終了する際に`TIDB`キーワードを付加する必要はありません。クライアントが常に同じ TiDB インスタンスに接続されることが確実でない限り、設定ファイルで`compatible-kill-query`を`true`に設定することは**強く推奨されません**。これは、デフォルトの MySQL クライアントでControl + Cを押すと、新しい接続が開かれ、その中で`KILL`が実行されるためです。クライアントと TiDB クラスタの間にプロキシが存在する場合、新しい接続が別の TiDB インスタンスにルーティングされる可能性があり、誤って別のセッションが強制終了される可能性があります。 + - `compatible-kill-query`が`true`の場合、TiDB でクエリを強制終了する際に`TIDB`キーワードを付加する必要はありません。クライアントが常に同じ TiDB インスタンスに接続されることが確実でない限り、設定ファイルで`compatible-kill-query`を`true`に設定することは**強く推奨されません**。これは、デフォルトの MySQL クライアントでControl + Cを押すと、新しい接続が開かれ、その中で`KILL`が実行されるためです。クライアントと TiDB クラスターの間にプロキシが存在する場合、新しい接続が別の TiDB インスタンスにルーティングされる可能性があり、誤って別のセッションが強制終了される可能性があります。 - [`enable-global-kill`](#enable-global-kill-new-in-v610)が`true`の場合、 `KILL xxx`と`KILL TIDB xxx`同じ効果を持ちます。 - `KILL`ステートメントの詳細については、 [キル [TIDB]](/sql-statements/sql-statement-kill.md)参照してください。 @@ -125,7 +125,7 @@ TiDB 設定ファイルは、コマンドラインパラメータよりも多く > **注記：** > -> TiDBノードは、現在のTiDBバージョンを確認するために値`server-version`を使用します。したがって、予期しない動作を回避するには、TiDBクラスタをアップグレードする前に、値`server-version`を空または現在のTiDBクラスタの実際のバージョンに設定する必要があります。 +> TiDBノードは、現在のTiDBバージョンを確認するために値`server-version`を使用します。したがって、予期しない動作を回避するには、TiDBクラスターをアップグレードする前に、値`server-version`を空または現在のTiDBクラスターの実際のバージョンに設定する必要があります。 ### repair-mode {#code-repair-mode-code} @@ -216,7 +216,7 @@ TiDB 設定ファイルは、コマンドラインパラメータよりも多く > > - SystemDを採用したプラットフォームでは、デフォルトの停止タイムアウトは90秒です。より長いタイムアウトが必要な場合は、 [`TimeoutStopSec=`](https://www.freedesktop.org/software/systemd/man/latest/systemd.service.html#TimeoutStopSec=)設定できます。 > -> - TiUP クラスタコンポーネントを使用する場合、デフォルト[`--wait-timeout`](/tiup/tiup-component-cluster.md#--wait-timeout) 120 秒です。 +> - TiUP クラスターコンポーネントを使用する場合、デフォルト[`--wait-timeout`](/tiup/tiup-component-cluster.md#--wait-timeout) 120 秒です。 > > - Kubernetes を使用する場合、デフォルトは[`terminationGracePeriodSeconds`](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#lifecycle)で 30 秒です。 @@ -235,13 +235,13 @@ TiDB 設定ファイルは、コマンドラインパラメータよりも多く > **警告：** > -> クラスタ内のTiDBインスタンス数が2048を超えるか、単一のTiDBインスタンスの同時接続数が1048576を超えると、32ビット接続IDの容量が不足するため、自動的に64ビット接続IDにアップグレードされます。アップグレードプロセス中、既存のビジネス接続および確立済みの接続は影響を受けません。ただし、それ以降の新規接続は、MySQLコマンドラインでControl+Cを使用して切断することはできません。 +> クラスター内のTiDBインスタンス数が2048を超えるか、単一のTiDBインスタンスの同時接続数が1048576を超えると、32ビット接続IDの容量が不足するため、自動的に64ビット接続IDにアップグレードされます。アップグレードプロセス中、既存のビジネス接続および確立済みの接続は影響を受けません。ただし、それ以降の新規接続は、MySQLコマンドラインでControl+Cを使用して切断することはできません。 ### initialize-sql-file v6.6.0の新機能 {#code-initialize-sql-file-code-span-class-version-mark-new-in-v6-6-0-span} - TiDB クラスターを初めて起動したときに実行される SQL スクリプトを指定します。 - デフォルト値: `""` -- このスクリプト内のすべてのSQL文は、権限チェックなしで最高権限で実行されます。指定されたSQLスクリプトの実行に失敗した場合、TiDBクラスタの起動に失敗する可能性があります。 +- このスクリプト内のすべてのSQL文は、権限チェックなしで最高権限で実行されます。指定されたSQLスクリプトの実行に失敗した場合、TiDBクラスターの起動に失敗する可能性があります。 - この構成項目は、システム変数の値の変更、ユーザーの作成、権限の付与などの操作を実行するために使用されます。 ### enable-forwarding v5.0.0 の新機能 {#code-enable-forwarding-code-span-class-version-mark-new-in-v5-0-0-span} @@ -273,7 +273,7 @@ TiDB 設定ファイルは、コマンドラインパラメータよりも多く ## ログ {#log} -ログに関するコンフィグレーション項目。 +ログに関する設定項目。 ### level {#code-level-code} @@ -352,7 +352,7 @@ TiDB 設定ファイルは、コマンドラインパラメータよりも多く ## ログファイル {#log-file} -ログ ファイルに関連するコンフィグレーション項目。 +ログ ファイルに関連する設定項目。 #### filename {#code-filename-code} @@ -388,7 +388,7 @@ TiDB 設定ファイルは、コマンドラインパラメータよりも多く ## 安全 {#security} -セキュリティに関するコンフィグレーション項目。 +セキュリティに関する設定項目。 ### enable-sem {#code-enable-sem-code} @@ -488,7 +488,7 @@ TiDB 設定ファイルは、コマンドラインパラメータよりも多く ## パフォーマンス {#performance} -パフォーマンスに関連するコンフィグレーション項目。 +パフォーマンスに関連する設定項目。 ### max-procs {#code-max-procs-code} @@ -645,7 +645,7 @@ TiDB 設定ファイルは、コマンドラインパラメータよりも多く ## オープントレーシング {#opentracing} -OpenTracing に関連するコンフィグレーション項目。 +OpenTracing に関連する設定項目。 ### enable {#code-enable-code} @@ -659,7 +659,7 @@ OpenTracing に関連するコンフィグレーション項目。 ## opentracing.sampler {#opentracing-sampler} -opentracing.sampler に関連するコンフィグレーション項目。 +opentracing.sampler に関連する設定項目。 ### type {#code-type-code} @@ -693,7 +693,7 @@ opentracing.sampler に関連するコンフィグレーション項目。 ## オープントレーシングレポーター {#opentracing-reporter} -opentracing.reporter に関連するコンフィグレーション項目。 +opentracing.reporter に関連する設定項目。 ### queue-size {#code-queue-size-code} @@ -702,7 +702,7 @@ opentracing.reporter に関連するコンフィグレーション項目。 ### buffer-flush-interval {#code-buffer-flush-interval-code} -- レポーターがメモリ内のスパンをstorageにフラッシュする間隔。 +- レポーターがメモリ内のスパンをストレージにフラッシュする間隔。 - デフォルト値: `0` ### log-spans {#code-log-spans-code} @@ -824,7 +824,7 @@ opentracing.reporter に関連するコンフィグレーション項目。 ## トランザクションローカルラッチ {#txn-local-latches} -トランザクションラッチに関連するコンフィグレーション項目です。これらの設定項目は将来廃止される可能性があります。使用は推奨されません。 +トランザクションラッチに関連する設定項目です。これらの設定項目は将来廃止される可能性があります。使用は推奨されません。 ### enabled {#code-enabled-code} @@ -838,7 +838,7 @@ opentracing.reporter に関連するコンフィグレーション項目。 ## 状態 {#status} -TiDB サービスのステータスに関連するコンフィグレーション。 +TiDB サービスのステータスに関連する設定。 ### report-status {#code-report-status-code} @@ -892,7 +892,7 @@ TiDB サービスのステータスに関連するコンフィグレーション ## 分離読み取り {#isolation-read} -読み取り分離に関連するコンフィグレーション項目。 +読み取り分離に関連する設定項目。 ### engines {#code-engines-code} @@ -1040,7 +1040,7 @@ TiDB サービスのステータスに関連するコンフィグレーション ## プロキシプロトコル {#proxy-protocol} -PROXY プロトコルに関連するコンフィグレーション項目。 +PROXY プロトコルに関連する設定項目。 ### networks {#code-networks-code} diff --git a/tidb-distributed-execution-framework.md b/tidb-distributed-execution-framework.md index eef00c91bd9d1..168aec2b857a3 100644 --- a/tidb-distributed-execution-framework.md +++ b/tidb-distributed-execution-framework.md @@ -91,7 +91,7 @@ DXF を使用して[`ADD INDEX`](/sql-statements/sql-statement-add-index.md)タ ## タスクのスケジュール {#task-scheduling} -デフォルトでは、DXFはすべてのTiDBノードを分散タスクの実行対象としてスケジュールします。v7.4.0以降、TiDBセルフマネージドクラスターでは、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)設定することで、DXFが分散タスクの実行対象としてスケジュールするTiDBノードを制御できます。 +デフォルトでは、DXFはすべてのTiDBノードを分散タスクの実行対象としてスケジュールします。v7.4.0以降、TiDB Self-Managedクラスターでは、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)設定することで、DXFが分散タスクの実行対象としてスケジュールするTiDBノードを制御できます。 - バージョンv7.4.0からv8.0.0までの場合、 [`tidb_service_scope`](/system-variables.md#tidb_service_scope-new-in-v740)のオプション値は`''`または`background`です。現在のクラスターに`tidb_service_scope = 'background'`のTiDBノードがある場合、DXFはこれらのノードにタスクの実行をスケジュールします。障害または通常のスケールインにより、現在のクラスターに`tidb_service_scope = 'background'` TiDBノードがない場合、DXFは`tidb_service_scope = ''`のノードにタスクの実行をスケジュールします。 diff --git a/tidb-global-sort.md b/tidb-global-sort.md index 7b8a19dac083b..c7f5ac5150a0a 100644 --- a/tidb-global-sort.md +++ b/tidb-global-sort.md @@ -22,7 +22,7 @@ summary: TiDB グローバル ソートの使用例、制限、使用方法、 TiDBのグローバルソート機能は、データインポートとDDL（データ定義言語）操作の安定性と効率性を向上させます。1 [TiDB 分散実行フレームワーク (DXF)](/tidb-distributed-execution-framework.md)汎用演算子として機能し、クラウド上でグローバルソートサービスを提供します。 -現在、グローバルソート機能は、クラウドstorageとして Amazon S3 の使用をサポートしています。 +現在、グローバルソート機能は、クラウドストレージとして Amazon S3 の使用をサポートしています。 ## ユースケース {#use-cases} @@ -46,19 +46,19 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ -2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドstorageパスに設定します。3 [例](/br/backup-and-restore-storages.md)参照してください。 +2. [`tidb_cloud_ストレージ_uri`](/system-variables.md#tidb_cloud_ストレージ_uri-new-in-v740)正しいクラウドストレージパスに設定します。3 [例](/br/backup-and-restore-ストレージs.md)参照してください。 ```sql - SET GLOBAL tidb_cloud_storage_uri = 's3://my-bucket/test-data?role-arn=arn:aws:iam::888888888888:role/my-role' + SET GLOBAL tidb_cloud_ストレージ_uri = 's3://my-bucket/test-data?role-arn=arn:aws:iam::888888888888:role/my-role' ``` -2. [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)正しいクラウドstorageパスに設定します。3 [例](https://docs.pingcap.com/tidb/stable/backup-and-restore-storages)参照してください。 +2. [`tidb_cloud_ストレージ_uri`](/system-variables.md#tidb_cloud_ストレージ_uri-new-in-v740)正しいクラウドストレージパスに設定します。3 [例](https://docs.pingcap.com/tidb/stable/backup-and-restore-ストレージs)参照してください。 ```sql - SET GLOBAL tidb_cloud_storage_uri = 's3://my-bucket/test-data?role-arn=arn:aws:iam::888888888888:role/my-role' + SET GLOBAL tidb_cloud_ストレージ_uri = 's3://my-bucket/test-data?role-arn=arn:aws:iam::888888888888:role/my-role' ``` @@ -73,7 +73,7 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ > **注記：** > -> [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)については、 [`CLOUD_STORAGE_URI`](/sql-statements/sql-statement-import-into.md#withoptions)オプションを使用してクラウドstorageのパスを指定することもできます。 [`tidb_cloud_storage_uri`](/system-variables.md#tidb_cloud_storage_uri-new-in-v740)と`CLOUD_STORAGE_URI`両方に有効なクラウドstorageのパスが設定されている場合、 `CLOUD_STORAGE_URI`の設定が[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)に有効になります。 +> [`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)については、 [`CLOUD_STORAGE_URI`](/sql-statements/sql-statement-import-into.md#withoptions)オプションを使用してクラウドストレージのパスを指定することもできます。 [`tidb_cloud_ストレージ_uri`](/system-variables.md#tidb_cloud_ストレージ_uri-new-in-v740)と`CLOUD_STORAGE_URI`両方に有効なクラウドストレージのパスが設定されている場合、 `CLOUD_STORAGE_URI`の設定が[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)に有効になります。 ## 実施原則 {#implementation-principles} @@ -88,9 +88,9 @@ TiDBのグローバルソート機能は、データインポートとDDL（デ 1. TiDB ノードが特定の範囲のデータをスキャンした後 (データ ソースは CSV データまたは TiKV のテーブル データのいずれかになります)。 1. TiDB ノードはそれらをキーと値のペアにエンコードします。 - 2. TiDB ノードは、キーと値のペアを複数のブロック データ セグメントに分類します (データ セグメントはローカルに分類されます)。各セグメントは 1 つのファイルであり、クラウドstorageにアップロードされます。 + 2. TiDB ノードは、キーと値のペアを複数のブロック データ セグメントに分類します (データ セグメントはローカルに分類されます)。各セグメントは 1 つのファイルであり、クラウドストレージにアップロードされます。 -2. TiDBノードは、各セグメントの実際のキーと値の範囲（統計ファイルと呼ばれます）も連続して記録します。これは、スケーラブルなソート実装のための重要な準備です。これらのファイルは、実際のデータと共にクラウドstorageにアップロードされます。 +2. TiDBノードは、各セグメントの実際のキーと値の範囲（統計ファイルと呼ばれます）も連続して記録します。これは、スケーラブルなソート実装のための重要な準備です。これらのファイルは、実際のデータと共にクラウドストレージにアップロードされます。 ### ステップ2: データを分類して分配する {#step-2-sort-and-distribute-data} diff --git a/tidb-in-kubernetes.md b/tidb-in-kubernetes.md index d9404a7288078..a3a41b8ba074a 100644 --- a/tidb-in-kubernetes.md +++ b/tidb-in-kubernetes.md @@ -3,8 +3,8 @@ title: Deploy a TiDB Cluster on Kubernetes summary: Kubernetes に TiDB クラスターをデプロイする方法を学びます。 --- -# Kubernetes に TiDBクラスタをデプロイ {#deploy-a-tidb-cluster-on-kubernetes} +# Kubernetes に TiDBクラスターをデプロイ {#deploy-a-tidb-cluster-on-kubernetes} -[TiDB Operator](https://github.com/pingcap/tidb-operator)使用して Kubernetes 上に TiDB クラスタをデプロイできます。TiDB Operator は、Kubernetes 上の TiDB クラスタ用の自動運用システムです。デプロイ、アップグレード、スケーリング、バックアップ、フェイルオーバー、設定変更など、TiDB のライフサイクル全体を管理します。TiDB Operatorを使用すると、パブリッククラウドまたはプライベートクラウドにデプロイされた Kubernetes クラスタで TiDB をシームレスに実行できます。 +[TiDB Operator](https://github.com/pingcap/tidb-operator)使用して Kubernetes 上に TiDB クラスターをデプロイできます。TiDB Operator は、Kubernetes 上の TiDB クラスター用の自動運用システムです。デプロイ、アップグレード、スケーリング、バックアップ、フェイルオーバー、設定変更など、TiDB のライフサイクル全体を管理します。TiDB Operatorを使用すると、パブリッククラウドまたはプライベートクラウドにデプロイされた Kubernetes クラスターで TiDB をシームレスに実行できます。 現在、Kubernetes 上の TiDB に関するドキュメントは、TiDB のドキュメントとは独立しています。TiDB Operatorを使用して Kubernetes 上に TiDB クラスターをデプロイする詳細な手順については、 [TiDB Operatorと TiDB バージョンの関係](https://docs.pingcap.com/tidb-in-kubernetes/stable/tidb-operator-overview)を学習し、対応する[Kubernetes 上の TiDB ドキュメント](https://docs.pingcap.com/tidb-in-kubernetes/stable/)参照してください。 diff --git a/tidb-lightning/data-import-best-practices.md b/tidb-lightning/data-import-best-practices.md index ecabffc8cfe59..59755c18f9dd3 100644 --- a/tidb-lightning/data-import-best-practices.md +++ b/tidb-lightning/data-import-best-practices.md @@ -7,7 +7,7 @@ summary: 大量のデータをインポートするためのベスト プラク このドキュメントでは、TiDBへの大容量データのインポートに関するベストプラクティスを解説します。データのインポートに影響を与える重要な要素や手順も含まれています。弊社では、50TiBを超える大規模な単一テーブルのデータを社内環境とお客様の環境の両方にインポートした実績があり、これらの実際のアプリケーションシナリオに基づいたベストプラクティスを蓄積してきました。これにより、よりスムーズかつ効率的なデータインポートが可能になります。 -TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md) ）は、空のテーブルへのデータのインポートや空のクラスタの初期化に使用される包括的かつ効率的なデータインポートツールであり、ファイルをデータソースとして使用します。TiDB Lightningは、単一インスタンスと[並行輸入](/tidb-lightning/tidb-lightning-distributed-import.md) 2つの実行モードを提供します。異なるサイズのソースファイルをインポートできます。 +TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md) ）は、空のテーブルへのデータのインポートや空のクラスターの初期化に使用される包括的かつ効率的なデータインポートツールであり、ファイルをデータソースとして使用します。TiDB Lightningは、単一インスタンスと[並行輸入](/tidb-lightning/tidb-lightning-distributed-import.md) 2つの実行モードを提供します。異なるサイズのソースファイルをインポートできます。 - ソース ファイルのデータ サイズが 10 TiB 以内の場合は、インポートにTiDB Lightningの単一インスタンスを使用することをお勧めします。 - ソース ファイルのデータ サイズが 10 TiB を超える場合は、 [並行輸入](/tidb-lightning/tidb-lightning-distributed-import.md)に対してTiDB Lightningの複数のインスタンスを使用することをお勧めします。 @@ -17,7 +17,7 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni - [重要な要素](#key-factors) - [ソースファイルの準備](#prepare-source-files) -- [storageスペースの見積もり](#estimate-storage-space) +- [ストレージスペースの見積もり](#estimate-ストレージ-space) - [設定パラメータを変更する](#change-configuration-parameters) - [「チェックサム不一致」エラーを解決する](#resolve-the-checksum-mismatch-error) - [チェックポイントを有効にする](#enable-checkpoint) @@ -43,10 +43,10 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni - 圧縮比 - - TiDBクラスタにインポートされたデータは圧縮形式で保存されます。圧縮率は事前に計算できません。圧縮率は、データが実際にTiKVクラスタにインポートされた後にのみ判定できます。 + - TiDBクラスターにインポートされたデータは圧縮形式で保存されます。圧縮率は事前に計算できません。圧縮率は、データが実際にTiKVクラスターにインポートされた後にのみ判定できます。 - ベスト プラクティスとして、最初にデータの小さな部分 (たとえば、10%) をインポートしてクラスターの対応する圧縮率を取得し、それを使用してデータ インポート全体の圧縮率を推定することができます。 -- コンフィグレーションパラメータ +- 設定パラメータ - `region-concurrency` : TiDB Lightning のメイン論理処理の同時実行性。 - `send-kv-pairs` : 1 回のリクエストでTiDB Lightningから TiKV に送信されるキーと値のペアの数。 @@ -79,14 +79,14 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni - ファイル生成中に各ファイルのサイズが 96 MiB 未満になるように制御します。 - ファイルが非常に大きく、256 MiB を超える場合は、 [`strict-format`](/migrate-from-csv-files-to-tidb.md#step-4-tune-the-import-performance-optional)有効にします。 -## storageスペースの見積もり {#estimate-storage-space} +## ストレージスペースの見積もり {#estimate-ストレージ-space} -データのインポートに必要なstorage容量を見積もるには、次の 2 つの方法のいずれかを使用できます。 +データのインポートに必要なストレージ容量を見積もるには、次の 2 つの方法のいずれかを使用できます。 -- 総データサイズを**A** 、総インデックスサイズを**B** 、レプリケーション係数を**3** 、圧縮率を**α** （通常は約2.5）と仮定すると、全体の占有領域は**(A+B)*3/α**で計算できます。この方法は主に、データのインポートを実行せずにクラスタトポロジを計画する際に、概算を行うために使用されます。 +- 総データサイズを**A** 、総インデックスサイズを**B** 、レプリケーション係数を**3** 、圧縮率を**α** （通常は約2.5）と仮定すると、全体の占有領域は**(A+B)*3/α**で計算できます。この方法は主に、データのインポートを実行せずにクラスタートポロジを計画する際に、概算を行うために使用されます。 - データの10%のみをインポートし、実際に使用されている容量に10を掛けることで、そのデータバッチの最終的な容量使用量を推定します。この方法は、特に大量のデータをインポートする場合に、より正確です。 -なお、圧縮やスナップショットのレプリケーションなどのバックグラウンド タスクもstorage領域の一部を消費するため、20% のstorage領域を予約することをお勧めします。 +なお、圧縮やスナップショットのレプリケーションなどのバックグラウンド タスクもストレージ領域の一部を消費するため、20% のストレージ領域を予約することをお勧めします。 ## 設定パラメータを変更する {#change-configuration-parameters} @@ -128,7 +128,7 @@ TiDB Lightningパラメータの詳細については、 [TiDB Lightning構成 次に、 `strict-format`有効にします。このアプローチにより、 TiDB Lightningインスタンス間でインポートされたファイルの主キーと一意のキーの重複が削減され、 TiDB Lightningインスタンスはインポート前に大きなファイルを分割して、最適なインポートパフォーマンスを実現できます。 -### クラスタトポロジを計画する {#plan-cluster-topology} +### クラスタートポロジを計画する {#plan-cluster-topology} TiDB Lightningインスタンスを準備し、各インスタンスが5TiB～10TiBのソースデータを処理できるようにします。各ノードに1つのTiDB Lightningインスタンスをデプロイ。ノードの仕様については、 TiDB Lightningインスタンスの[環境要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)参照してください。 diff --git a/tidb-lightning/import-into-vs-tidb-lightning.md b/tidb-lightning/import-into-vs-tidb-lightning.md index 669aad2caf94a..0627ddda87a52 100644 --- a/tidb-lightning/import-into-vs-tidb-lightning.md +++ b/tidb-lightning/import-into-vs-tidb-lightning.md @@ -31,7 +31,7 @@ summary: IMPORT INTO` とTiDB Lightningの違いについて説明します。 `IMPORT INTO`タスクと他のビジネスワークロードは、TiDB リソースを共有したり、異なるタイミングで利用したりすることで、TiDB リソースを最大限に活用できます。3 タスクのパフォーマンスと安定性を維持しながら、ビジネスワークロードの安定した運用を確保するために、 `IMPORT INTO`タスクにデータインポート専用の[特定のTiDBノード](/system-variables.md#tidb_service_scope-new-in-v740)を指定することができ`IMPORT INTO` 。 -[TiDB グローバルソート](/tidb-global-sort.md)使用する場合、大容量のローカルディスクをマウントする必要はありません。TiDB Global Sort は Amazon S3 をstorageとして使用できます。インポートタスクが完了すると、グローバルソート用に Amazon S3 に保存された一時データは自動的に削除され、storageコストを節約できます。 +[TiDB グローバルソート](/tidb-global-sort.md)使用する場合、大容量のローカルディスクをマウントする必要はありません。TiDB Global Sort は Amazon S3 をストレージとして使用できます。インポートタスクが完了すると、グローバルソート用に Amazon S3 に保存された一時データは自動的に削除され、ストレージコストを節約できます。 #### TiDB Lightning {#tidb-lightning} @@ -71,7 +71,7 @@ TiDB Global Sort を使用すると、 `IMPORT INTO`十 TiB のソースデー これらのKVペアはグローバルにソートされているため、複数のTiDBノードからTiKVにインポートされたデータは重複せず、RocksDBに直接書き込むことができます。これにより、TiKVによる圧縮操作が不要になり、TiKVの書き込みパフォーマンスと安定性が大幅に向上します。 -インポートが完了すると、Amazon S3 上のグローバルソートに使用されたデータは自動的に削除され、storageコストを節約できます。 +インポートが完了すると、Amazon S3 上のグローバルソートに使用されたデータは自動的に削除され、ストレージコストを節約できます。 #### TiDB Lightning {#tidb-lightning} @@ -83,7 +83,7 @@ TiDB Lightningはローカルソートのみをサポートします。例えば 現在、 `IMPORT INTO`とTiDB Lightningの間で同等のテスト環境下でのパフォーマンステスト比較結果はありません。 -グローバルソートのstorageとして Amazon S3 を使用した場合、 `IMPORT INTO`のパフォーマンステスト結果は次のとおりです。 +グローバルソートのストレージとして Amazon S3 を使用した場合、 `IMPORT INTO`のパフォーマンステスト結果は次のとおりです。 | ソースデータセット | ノード構成 | TiDBノードあたりの平均インポート速度 | | -------------------------------------- | --------------------------------------- | -------------------- | diff --git a/tidb-lightning/monitor-tidb-lightning.md b/tidb-lightning/monitor-tidb-lightning.md index c4e44261db1b4..d170f4af3f920 100644 --- a/tidb-lightning/monitor-tidb-lightning.md +++ b/tidb-lightning/monitor-tidb-lightning.md @@ -94,7 +94,7 @@ scrape_configs: いずれかの期間が長すぎる場合は、 TiDB Lightningが使用するディスクが遅すぎるか、I/O でビジー状態であることを示します。 -### 6行目: ストレージ {#row-6-storage} +### 6行目: ストレージ {#row-6-ストレージ} ![Panels in sixth row](/media/lightning-grafana-row-6.png) diff --git a/tidb-lightning/tidb-lightning-checkpoints.md b/tidb-lightning/tidb-lightning-checkpoints.md index 461ec86986762..0da7285658c70 100644 --- a/tidb-lightning/tidb-lightning-checkpoints.md +++ b/tidb-lightning/tidb-lightning-checkpoints.md @@ -28,7 +28,7 @@ driver = "file" # Enabled only when `driver = "mysql"`. # schema = "tidb_lightning_checkpoint" -# The data source name (DSN) indicating the location of the checkpoint storage. +# The data source name (DSN) indicating the location of the checkpoint ストレージ. # # For the "file" driver, the DSN is a path. If the path is not specified, Lightning would # default to "/tmp/CHECKPOINT_SCHEMA.pb". @@ -45,15 +45,15 @@ driver = "file" # keep-after-success = false ``` -## チェックポイントのstorage {#checkpoints-storage} +## チェックポイントのストレージ {#checkpoints-ストレージ} -TiDB Lightning は、ローカル ファイルまたはリモート MySQL 互換データベースの 2 種類のチェックポイントstorageをサポートしています。 +TiDB Lightning は、ローカル ファイルまたはリモート MySQL 互換データベースの 2 種類のチェックポイントストレージをサポートしています。 - `driver = "file"`の場合、チェックポイントは`dsn`で指定されたパスのローカルファイルに保存されます。チェックポイントは頻繁に更新されるため、RAMディスクなど、書き込み耐久性が非常に高いドライブにチェックポイントファイルを置くことを強くお勧めします。 - `driver = "mysql"`の場合、MariaDBやTiDBを含む、 MySQL 5.7以降と互換性のある任意のデータベースにチェックポイントを保存できます。デフォルトでは、チェックポイントはターゲットデータベースに保存されます。 -Lightning は、ターゲットデータベースをチェックポイントのstorageとして使用している場合、大量のデータを同時にインポートします。これにより、ターゲットデータベースに余分な負荷がかかり、通信タイムアウトが発生する場合があります。そのため、**これらのチェックポイントを保存するための一時的な MySQLサーバーをインストールすることを強くお勧めします**。このサーバーは`tidb-lightning`と同じホストにインストールでき、インポート処理が完了したらアンインストールできます。 +Lightning は、ターゲットデータベースをチェックポイントのストレージとして使用している場合、大量のデータを同時にインポートします。これにより、ターゲットデータベースに余分な負荷がかかり、通信タイムアウトが発生する場合があります。そのため、**これらのチェックポイントを保存するための一時的な MySQLサーバーをインストールすることを強くお勧めします**。このサーバーは`tidb-lightning`と同じホストにインストールでき、インポート処理が完了したらアンインストールできます。 ## チェックポイント制御 {#checkpoints-control} diff --git a/tidb-lightning/tidb-lightning-command-line-full.md b/tidb-lightning/tidb-lightning-command-line-full.md index ccc2d36867666..9b5132d2c01a0 100644 --- a/tidb-lightning/tidb-lightning-command-line-full.md +++ b/tidb-lightning/tidb-lightning-command-line-full.md @@ -17,7 +17,7 @@ TiDB Lightning は、設定ファイルまたはコマンドラインから設 | :---------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------- | | `--config ` | ファイルからグローバル設定を読み取ります。このパラメータが指定されていない場合、 TiDB Lightningはデフォルト設定を使用します。 | | | `-V` | プログラムのバージョンを印刷します。 | | -| `-d ` | ローカル ディレクトリまたはデータ ファイルの[外部storageURI](/external-storage-uri.md) 。 | `mydumper.data-source-dir` | +| `-d ` | ローカル ディレクトリまたはデータ ファイルの[外部ストレージURI](/external-ストレージ-uri.md) 。 | `mydumper.data-source-dir` | | `-L ` | ログ`info` : `debug` 、または`error` `warn`は`info` `fatal` 。 | `lightning.level` | | `-f ` | [テーブルフィルタルール](/table-filter.md) 。複数回指定できます。 | `mydumper.filter` | | `--backend ` | インポート モードを選択します。1 は`local` 、 `tidb` [物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md) [論理インポートモード](/tidb-lightning/tidb-lightning-logical-import-mode.md)指します。 | `tikv-importer.backend` | diff --git a/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md b/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md index e4732ae331d85..fafe42c232f00 100644 --- a/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md +++ b/tidb-lightning/tidb-lightning-compatibility-and-scenarios.md @@ -51,7 +51,7 @@ TiCDC を物理インポート モードで使用することは、短期的に このシナリオでは、TiCDC の changefeed が有効になっている場合、 TiDB Lightning の起動後に互換性チェックでエラーが報告されます。上流 TiDB クラスターの[TiDB Lightning構成ファイル](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)パラメータ`Lightning.check-requirements`を`false`に変更し、インポートタスクを再起動する必要があります。 - 上流TiDBクラスタのインポートタスクが完了したら、 TiDB Lightningを使用して、同じデータを下流TiDBクラスタにインポートします。下流にRedshiftやSnowflakeなどのデータベースがある場合は、クラウドstorageサービスからCSV、SQL、またはParquetファイルを読み取り、データベースに書き込むように設定できます。 + 上流TiDBクラスターのインポートタスクが完了したら、 TiDB Lightningを使用して、同じデータを下流TiDBクラスターにインポートします。下流にRedshiftやSnowflakeなどのデータベースがある場合は、クラウドストレージサービスからCSV、SQL、またはParquetファイルを読み取り、データベースに書き込むように設定できます。 ## IMPORT INTOのシナリオ {#scenarios-for-code-import-into-code} @@ -75,4 +75,4 @@ TiCDC を物理インポート モードで使用することは、短期的に このシナリオでは、TiCDC の changefeed が有効になっている場合、 `IMPORT INTO`ステートメントを送信した後に互換性チェックでエラーが報告されます。そのステートメントの[`WithOptions`](/sql-statements/sql-statement-import-into.md#withoptions)に`DISABLE_PRECHECK` (v8.0.0 で導入) を含めて再送信することができます。これにより、データインポートタスクは互換性チェックを無視し、データを直接インポートします。 - 上流 TiDB クラスターのインポートタスクが完了したら、 `IMPORT INTO`使用して下流 TiDB クラスターに同じデータをインポートします。下流に Redshift や Snowflake などのデータベースがある場合は、クラウドstorageサービスから CSV、SQL、または Parquet ファイルを読み取り、データベースに書き込むように設定できます。 + 上流 TiDB クラスターのインポートタスクが完了したら、 `IMPORT INTO`使用して下流 TiDB クラスターに同じデータをインポートします。下流に Redshift や Snowflake などのデータベースがある場合は、クラウドストレージサービスから CSV、SQL、または Parquet ファイルを読み取り、データベースに書き込むように設定できます。 diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index 3711f98733041..99d79c3244b60 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/tidb-lightning/tidb-lightning-configuration.md @@ -3,7 +3,7 @@ title: TiDB Lightning Configuration summary: TiDB Lightningの CLI の使用方法とサンプル構成について学習します。 --- -# TiDB Lightningコンフィグレーション {#tidb-lightning-configuration} +# TiDB Lightning設定 {#tidb-lightning-configuration} このドキュメントでは、グローバル設定とタスク設定のサンプルを提供し、コマンドラインパラメータの使用方法を説明します。サンプル設定ファイルは[`lightning/tidb-lightning.toml`](https://github.com/pingcap/tidb/blob/master/lightning/tidb-lightning.toml)にあります。 @@ -85,7 +85,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### io-concurrency {#code-io-concurrency-code} -- 最大I/O同時実行数。I/O同時実行数が多すぎると、ディスクの内部バッファが頻繁に更新されるため、I/Oレイテンシーが増加し、キャッシュミスが発生し、読み取り速度が低下します。storageメディアによっては、最適なパフォーマンスを得るためにこの値を調整する必要があるかもしれません。 +- 最大I/O同時実行数。I/O同時実行数が多すぎると、ディスクの内部バッファが頻繁に更新されるため、I/Oレイテンシーが増加し、キャッシュミスが発生し、読み取り速度が低下します。ストレージメディアによっては、最適なパフォーマンスを得るためにこの値を調整する必要があるかもしれません。 @@ -106,7 +106,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### meta-schema-name {#code-meta-schema-name-code} -- [並行輸入モード](/tidb-lightning/tidb-lightning-distributed-import.md)では、ターゲットクラスタ内の各TiDB Lightningインスタンスのメタ情報を格納するスキーマ名です。このパラメータは、並列インポートが有効な場合にのみ設定してください。 +- [並行輸入モード](/tidb-lightning/tidb-lightning-distributed-import.md)では、ターゲットクラスター内の各TiDB Lightningインスタンスのメタ情報を格納するスキーマ名です。このパラメータは、並列インポートが有効な場合にのみ設定してください。 - このパラメータに設定する値は、同じ並列インポートに参加する各TiDB Lightningインスタンスで同じである必要があります。そうでない場合、インポートされたデータの正確性は保証されません。 - 並列インポート モードが有効になっている場合は、インポートに使用されるユーザー (構成`tidb.user` ) に、この構成に対応するデータベースを作成してアクセスする権限があることを確認します。 - TiDB Lightningはインポート完了後にこのスキーマを削除します。そのため、このパラメータを設定する際に既存のスキーマ名を使用しないでください。 @@ -158,7 +158,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### dsn {#code-dsn-code} -- チェックポイントstorageの場所を示すデータ ソース名 (DSN)。 +- チェックポイントストレージの場所を示すデータ ソース名 (DSN)。 - `file`ドライバの場合、DSNはパスです。パスが指定されていない場合、 TiDB Lightningはデフォルト値の`/tmp/CHECKPOINT_SCHEMA.pb`使用します。 - `mysql`ドライバーの場合、 DSN は`USER:PASS@tcp(HOST:PORT)/`形式の URL です。 - URL が指定されていない場合は、 `[tidb]`セクションの TiDBサーバーがチェックポイントの保存に使用されます。 @@ -372,7 +372,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設 #### data-source-dir {#code-data-source-dir-code} -- ローカルソースデータディレクトリまたは外部storageのURIを指定します。外部storageのURIの詳細については、 [URI形式](/br/backup-and-restore-storages.md#uri-format)参照してください。 +- ローカルソースデータディレクトリまたは外部ストレージのURIを指定します。外部ストレージのURIの詳細については、 [URI形式](/br/backup-and-restore-ストレージs.md#uri-format)参照してください。 @@ -513,7 +513,7 @@ CSV ファイルの解析方法を構成します。 #### host {#code-host-code} -- クラスターからの任意の TiDBサーバーのコンフィグレーション。 +- クラスターからの任意の TiDBサーバーの設定。 diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md index 4fee706dcb7db..1f8061116066f 100644 --- a/tidb-lightning/tidb-lightning-data-source.md +++ b/tidb-lightning/tidb-lightning-data-source.md @@ -11,7 +11,7 @@ TiDB Lightningのデータ ソースを指定するには、次の構成を使 ```toml [mydumper] -# Local source data directory or the URI of the external storage such as S3. For more information about the URI of the external storage, see https://docs.pingcap.com/tidb/dev/backup-and-restore-storages#uri-format. +# Local source data directory or the URI of the external ストレージ such as S3. For more information about the URI of the external ストレージ, see https://docs.pingcap.com/tidb/dev/backup-and-restore-ストレージs#uri-format. data-source-dir = "/data/my_database" ``` @@ -106,7 +106,7 @@ CSVファイルはスキーマレスです。CSVファイルをTiDBにインポ - DDL ステートメントを含む`${db_name}.${table_name}-schema.sql`および`${db_name}-schema-create.sql`名前のファイルを作成します。 - TiDB にテーブル スキーマを手動で作成します。 -### コンフィグレーション {#configuration} +### 設定 {#configuration} CSV形式は、 `tidb-lightning.toml`ファイルの`[mydumper.csv]`セクションで設定できます。ほとんどの設定には、MySQLの[`LOAD DATA`](https://dev.mysql.com/doc/refman/8.0/en/load-data.html)ステートメントに対応するオプションがあります。 @@ -401,7 +401,7 @@ type = '$3' ## Amazon S3からデータをインポートする {#import-data-from-amazon-s3} -以下の例は、TiDB Lightningを使用して Amazon S3 からデータをインポートする方法を示しています。詳細なパラメータ設定については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +以下の例は、TiDB Lightningを使用して Amazon S3 からデータをインポートする方法を示しています。詳細なパラメータ設定については、 [外部ストレージサービスのURI形式](/external-ストレージ-uri.md)参照してください。 - ローカルに設定された権限を使用して S3 データにアクセスします。 diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md index 2002141fa45ba..c21fe59214d82 100644 --- a/tidb-lightning/tidb-lightning-distributed-import.md +++ b/tidb-lightning/tidb-lightning-distributed-import.md @@ -12,7 +12,7 @@ TiDB Lightning v5.3.0以降、 [物理インポートモード](/tidb-lightning/ TiDB Lightning を使用すると、次のシナリオでデータを並列にインポートできます。 - シャード化されたスキーマとシャード化されたテーブルをインポートします。このシナリオでは、複数の上流データベースインスタンスからの複数のテーブルが、異なるTiDB Lightningインスタンスによって下流 TiDB データベースに並行してインポートされます。 -- 単一テーブルの並列インポート。このシナリオでは、特定のディレクトリまたはクラウドstorage（Amazon S3など）に保存された単一テーブルが、複数のTiDB Lightningインスタンスによって下流のTiDBクラスタに並列インポートされます。これはTiDB 5.3.0で導入された新機能です。 +- 単一テーブルの並列インポート。このシナリオでは、特定のディレクトリまたはクラウドストレージ（Amazon S3など）に保存された単一テーブルが、複数のTiDB Lightningインスタンスによって下流のTiDBクラスターに並列インポートされます。これはTiDB 5.3.0で導入された新機能です。 > **注記：** > @@ -24,7 +24,7 @@ TiDB Lightning を使用すると、次のシナリオでデータを並列に ## 考慮事項 {#considerations} -並列インポートを使用するには、 `parallel-import = true`設定する必要があります。TiDB Lightning を起動すると、下流の TiDB クラスタにメタデータが登録され、同時にターゲットクラスタにデータを移行している他のインスタンスが存在するかどうかが自動的に検出されます。存在する場合、自動的に並列インポートモードに移行します。 +並列インポートを使用するには、 `parallel-import = true`設定する必要があります。TiDB Lightning を起動すると、下流の TiDB クラスターにメタデータが登録され、同時にターゲットクラスターにデータを移行している他のインスタンスが存在するかどうかが自動的に検出されます。存在する場合、自動的に並列インポートモードに移行します。 ただし、データを並行して移行する場合は、次の点を考慮する必要があります。 @@ -37,7 +37,7 @@ TiDB Lightning を使用すると、次のシナリオでデータを並列に ### インポートパフォーマンスの最適化 {#optimize-import-performance} -TiDB Lightningは、生成されたキーバリューデータを、対応するリージョンの各コピーが配置されているTiKVノードにアップロードする必要があるため、インポート速度はターゲットクラスタのサイズによって制限されます。ターゲットTiDBクラスタ内のTiKVインスタンスの数とTiDB Lightningインスタンスの数がn:1（nはリージョンのコピー数）より大きくすることを推奨します。同時に、最適なインポートパフォーマンスを実現するには、以下の要件を満たす必要があります。 +TiDB Lightningは、生成されたキーバリューデータを、対応するリージョンの各コピーが配置されているTiKVノードにアップロードする必要があるため、インポート速度はターゲットクラスターのサイズによって制限されます。ターゲットTiDBクラスター内のTiKVインスタンスの数とTiDB Lightningインスタンスの数がn:1（nはリージョンのコピー数）より大きくすることを推奨します。同時に、最適なインポートパフォーマンスを実現するには、以下の要件を満たす必要があります。 - 各TiDB Lightningインスタンスを専用マシンにデプロイ。1つのTiDB LightningインスタンスはデフォルトですべてのCPUリソースを消費するため、1台のマシンに複数のインスタンスをデプロイしてもパフォーマンスは向上しません。 - 並列インポートを実行する各TiDB Lightningインスタンスのソースファイルの合計サイズは 5 TiB 未満である必要があります。 @@ -67,7 +67,7 @@ TiDB Lightning は実行時に一部のリソースを排他的に使用しま ## 例 1: Dumpling + TiDB Lightningを使用して、シャードデータベースとテーブルを TiDB に並列インポートする {#example-1-use-dumpling-tidb-lightning-to-import-sharded-databases-and-tables-into-tidb-in-parallel} -この例では、アップストリームが10個のシャードテーブルを持つMySQLクラスタで、合計サイズが10TiBであると仮定します。5つのTiDB Lightningインスタンスを使用して並列インポートを実行し、各インスタンスが2TiBをインポートします。合計インポート時間（ Dumplingエクスポートに必要な時間を除く）は、約40時間から約10時間に短縮されると推定されます。 +この例では、アップストリームが10個のシャードテーブルを持つMySQLクラスターで、合計サイズが10TiBであると仮定します。5つのTiDB Lightningインスタンスを使用して並列インポートを実行し、各インスタンスが2TiBをインポートします。合計インポート時間（ Dumplingエクスポートに必要な時間を除く）は、約40時間から約10時間に短縮されると推定されます。 上流ライブラリの名前が`my_db` 、各シャードテーブルの名前が`my_table_01` ～ `my_table_10`であると仮定します。これらを下流のテーブル`my_db.my_table`にマージしてインポートします。具体的な手順については、以下のセクションで説明します。 @@ -102,12 +102,12 @@ Dumpling を使用してデータをエクスポートする方法の詳細に # Specify the path for local sorting data. sorted-kv-dir = "/path/to/sorted-dir" -データソースがAmazon S3やGCSなどの外部storageに保存されている場合は、接続用の追加パラメータを設定する必要があります。このような設定にはパラメータを指定できます。例えば、次の例では、データがAmazon S3に保存されていると仮定しています。 +データソースがAmazon S3やGCSなどの外部ストレージに保存されている場合は、接続用の追加パラメータを設定する必要があります。このような設定にはパラメータを指定できます。例えば、次の例では、データがAmazon S3に保存されていると仮定しています。 tiup tidb-lightning --tidb-port=4000 --pd-urls=127.0.0.1:2379 --backend=local --sorted-kv-dir=/tmp/sorted-kvs \ -d 's3://my-bucket/sql-backup' -詳細なパラメータの説明については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +詳細なパラメータの説明については、 [外部ストレージサービスのURI形式](/external-ストレージ-uri.md)参照してください。 ### ステップ3: TiDB Lightningを起動してデータをインポートする {#step-3-start-tidb-lightning-to-import-data} @@ -122,8 +122,8 @@ nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out & 並列インポート中、 TiDB Lightning はタスクの開始後に次のチェックを自動的に実行します。 -- ローカルディスク（構成`sort-kv-dir`で制御）とTiKVクラスターに、データのインポートに必要な空き容量があるかどうかを確認してください。必要なディスク容量については、 [下流のstorageスペース要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)と[リソース要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)参照してください。TiDB Lightningはデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。 -- TiKVクラスタ内のリージョンが均等に分散されているか、また空きリージョンが多すぎないかを確認してください。空きリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 +- ローカルディスク（構成`sort-kv-dir`で制御）とTiKVクラスターに、データのインポートに必要な空き容量があるかどうかを確認してください。必要なディスク容量については、 [下流のストレージスペース要件](/tidb-lightning/tidb-lightning-requirements.md#ストレージ-space-of-the-target-database)と[リソース要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)参照してください。TiDB Lightningはデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。 +- TiKVクラスター内のリージョンが均等に分散されているか、また空きリージョンが多すぎないかを確認してください。空きリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 - データソースからデータが順番にインポートされているか確認します。確認結果に基づいて`mydumper.batch-size`のサイズが自動的に調整されます。そのため、 `mydumper.batch-size`構成は利用できなくなります。 チェックをオフにして、 `lightning.check-requirements`設定で強制インポートを実行することもできます。詳細なチェックについては、 [TiDB Lightning事前チェック](/tidb-lightning/tidb-lightning-prechecks.md)参照してください。 @@ -139,7 +139,7 @@ nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out & ## 例2: 単一のテーブルを並列にインポートする {#example-2-import-single-tables-in-parallel} -TiDB Lightningは、単一テーブルの並列インポートもサポートしています。例えば、Amazon S3に保存されている複数の単一テーブルを、異なるTiDB Lightningインスタンスで下流のTiDBクラスターに並列インポートできます。この方法により、インポート全体の速度が向上します。Amazon S3などのリモートストレージを使用する場合、 TiDB Lightningの設定パラメータはBRと同じです。詳細については、 [外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +TiDB Lightningは、単一テーブルの並列インポートもサポートしています。例えば、Amazon S3に保存されている複数の単一テーブルを、異なるTiDB Lightningインスタンスで下流のTiDBクラスターに並列インポートできます。この方法により、インポート全体の速度が向上します。Amazon S3などのリモートストレージを使用する場合、 TiDB Lightningの設定パラメータはBRと同じです。詳細については、 [外部ストレージサービスのURI形式](/external-ストレージ-uri.md)参照してください。 > **注記：** > diff --git a/tidb-lightning/tidb-lightning-error-resolution.md b/tidb-lightning/tidb-lightning-error-resolution.md index 670c98b0b8f9c..f7b9c137da835 100644 --- a/tidb-lightning/tidb-lightning-error-resolution.md +++ b/tidb-lightning/tidb-lightning-error-resolution.md @@ -65,7 +65,7 @@ TiDB Lightning がインポート中にエラーに遭遇した場合、終了 [2022/03/13 05:33:57.736 +08:00] [WARN] [errormanager.go:459] ["Detect 1000 data type errors in total, please refer to table `lightning_task_info`.`type_error_v1` for more details"] ``` -すべてのエラーは、下流TiDBクラスタの`lightning_task_info`のデータベース内のテーブルに書き込まれます。インポートが完了した後、エラーデータが収集されていれば、データベース内のエラーを確認し、手動で処理することができます。 +すべてのエラーは、下流TiDBクラスターの`lightning_task_info`のデータベース内のテーブルに書き込まれます。インポートが完了した後、エラーデータが収集されていれば、データベース内のエラーを確認し、手動で処理することができます。 `lightning.task-info-schema-name`設定することでデータベース名を変更できます。 diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md index 4ef89909a886e..417fcdeea9834 100644 --- a/tidb-lightning/tidb-lightning-faq.md +++ b/tidb-lightning/tidb-lightning-faq.md @@ -50,7 +50,7 @@ ADMIN CHECKSUM TABLE `schema`.`table`; TiDB Lightning は以下をサポートします: - [Dumpling](/dumpling-overview.md) 、CSV ファイル、および[Amazon Auroraによって生成された Apache Parquet ファイル](/migrate-aurora-to-tidb.md) 、Apache Hive、Snowflake によってエクスポートされたファイルをインポートします。 -- ローカルディスクまたは Amazon S3storageからデータを読み取ります。 +- ローカルディスクまたは Amazon S3ストレージからデータを読み取ります。 ## TiDB Lightning はスキーマとテーブルの作成をスキップできますか? {#could-tidb-lightning-skip-creating-schema-and-tables} @@ -81,7 +81,7 @@ sql-mode = "STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION" TiDB Lightning は、10 ギガビット ネットワーク カードで使用するのが最適です。 -1ギガビットネットワークカードは合計120MB/秒の帯域幅しか提供できず、これをすべてのターゲットTiKVストアで共有する必要があります。TiDB Lightningは、物理インポートモードで1ギガビットネットワークの全帯域幅を簡単に飽和させ、PDに接続できなくなるため、クラスタを停止させる可能性があります。 +1ギガビットネットワークカードは合計120MB/秒の帯域幅しか提供できず、これをすべてのターゲットTiKVストアで共有する必要があります。TiDB Lightningは、物理インポートモードで1ギガビットネットワークの全帯域幅を簡単に飽和させ、PDに接続できなくなるため、クラスターを停止させる可能性があります。 ## TiDB Lightning がターゲット TiKV クラスターにこれほど多くの空き領域を必要とするのはなぜですか? {#why-tidb-lightning-requires-so-much-free-space-in-the-target-tikv-cluster} @@ -106,7 +106,7 @@ TiDB Lightning は、10 ギガビット ネットワーク カードで使用す 4. 残留メタデータをクリーンアップします。以下のいずれかの条件に該当する場合は、メタデータスキーマを手動でクリーンアップする必要があります。 - - TiDB Lightning v5.1.xおよびv5.2.xバージョンの場合、 `tidb-lightning-ctl`コマンドではターゲットクラスタ内のメタデータスキーマがクリーンアップされません。手動でクリーンアップする必要があります。 + - TiDB Lightning v5.1.xおよびv5.2.xバージョンの場合、 `tidb-lightning-ctl`コマンドではターゲットクラスター内のメタデータスキーマがクリーンアップされません。手動でクリーンアップする必要があります。 - チェックポイント ファイルを手動で削除した場合は、ダウンストリーム メタデータ スキーマを手動でクリーンアップする必要があります。そうしないと、後続のインポートの正確性が影響を受ける可能性があります。 メタデータをクリーンアップするには、次のコマンドを使用します。 @@ -147,11 +147,11 @@ Suppose the source cluster has the following topology: CREATE PLACEMENT POLICY p1 PRIMARY_REGION="us-east" REGIONS="us-east,us-west"; ``` -**状況1：**ターゲットクラスタに3つのレプリカがあり、トポロジがソースクラスタと異なります。このような場合、 TiDB Lightningがターゲットクラスタに配置ポリシーを作成する際にエラーは報告されませんが、ターゲットクラスタのセマンティクスが誤っています。 +**状況1：**ターゲットクラスターに3つのレプリカがあり、トポロジがソースクラスターと異なります。このような場合、 TiDB Lightningがターゲットクラスターに配置ポリシーを作成する際にエラーは報告されませんが、ターゲットクラスターのセマンティクスが誤っています。 ![TiDB Lightning FAQ - situation 1](/media/lightning-faq-situation-1.jpg) -**状況2：**ターゲットクラスタがフォロワーレプリカを「us-mid」リージョン内の別のTiKVノードに配置しており、トポロジ内に「us-west」リージョンが含まれていない場合。このような場合、ターゲットクラスタで配置ポリシーを作成すると、 TiDB Lightningはエラーを報告します。 +**状況2：**ターゲットクラスターがフォロワーレプリカを「us-mid」リージョン内の別のTiKVノードに配置しており、トポロジ内に「us-west」リージョンが含まれていない場合。このような場合、ターゲットクラスターで配置ポリシーを作成すると、 TiDB Lightningはエラーを報告します。 ![TiDB Lightning FAQ - situation 2](/media/lightning-faq-situation-2.jpg) diff --git a/tidb-lightning/tidb-lightning-glossary.md b/tidb-lightning/tidb-lightning-glossary.md index 8ce7efa7d3554..ab6daa0205c35 100644 --- a/tidb-lightning/tidb-lightning-glossary.md +++ b/tidb-lightning/tidb-lightning-glossary.md @@ -93,7 +93,7 @@ TiKV インポーターでは、エンジンは KV ペアをソートするた TiDB Lightningは、エンジンを介してTiKV Importerにデータを転送します。まずエンジンを開き、KVペアを（順序は問わず）エンジンに送信し、最後にエンジンを閉じます。エンジンは閉じた後、受信したKVペアをソートします。閉じられたエンジンは、TiKVストアにアップロードして取り込みを行うことができます。 -エンジンは TiKV インポーター`import-dir`一時storageとして使用します。これは「エンジン ファイル」と呼ばれることもあります。 +エンジンは TiKV インポーター`import-dir`一時ストレージとして使用します。これは「エンジン ファイル」と呼ばれることもあります。 [データエンジン](/tidb-lightning/tidb-lightning-glossary.md#data-engine)と[インデックスエンジン](/tidb-lightning/tidb-lightning-glossary.md#index-engine)も参照してください。 @@ -191,6 +191,6 @@ KV ペアを TiKV Importer に送信する前に、 TiDB Lightning自体によ ### SSTファイル {#sst-file} -SSTは「sorted string table（ソートされた文字列テーブル）」の略です。SSTファイルは、RocksDB（およびTiKV）のKVペアのコレクションのネイティブstorage形式です。 +SSTは「sorted string table（ソートされた文字列テーブル）」の略です。SSTファイルは、RocksDB（およびTiKV）のKVペアのコレクションのネイティブストレージ形式です。 TiKVインポーターは、閉じた[エンジン](/tidb-lightning/tidb-lightning-glossary.md#engine)からSSTファイルを生成します。これらのSSTファイルはアップロードされ、その後TiKVストアに[摂取した](/tidb-lightning/tidb-lightning-glossary.md#ingest)されます。 diff --git a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md index 6232bbf6fce07..5fc331f477928 100644 --- a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md @@ -24,7 +24,7 @@ max-backups = 14 check-requirements = true [mydumper] -# The local data source directory or the URI of the external storage. For more information about the URI of the external storage, see https://docs.pingcap.com/tidb/stable/backup-and-restore-storages/#uri-format. +# The local data source directory or the URI of the external ストレージ. For more information about the URI of the external ストレージ, see https://docs.pingcap.com/tidb/stable/backup-and-restore-ストレージs/#uri-format. data-source-dir = "/data/my_database" [tikv-importer] @@ -43,7 +43,7 @@ password = "" log-level = "error" ``` -完全な設定ファイルについては、 [TiDB Lightning のコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 +完全な設定ファイルについては、 [TiDB Lightning の設定](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 ## 競合検出 {#conflict-detection} @@ -64,7 +64,7 @@ log-level = "error" - 論理インポート モードでは、 TiDB Lightningのパフォーマンスはターゲット TiDB クラスターの書き込みパフォーマンスに大きく依存します。クラスターがパフォーマンスのボトルネックに達した場合は、 [高並行書き込みのベストプラクティス](/best-practices/high-concurrency-best-practices.md)を参照してください。 -- 対象の TiDB クラスタで書き込みボトルネックが発生しない場合は、 TiDB Lightning構成の`region-concurrency`の値を増やすことを検討してください。 `region-concurrency`のデフォルト値は CPU コア数です。 `region-concurrency`の意味は、物理インポート モードと論理インポート モードで異なります。論理インポート モードでは、 `region-concurrency`は書き込み同時実行数です。 +- 対象の TiDB クラスターで書き込みボトルネックが発生しない場合は、 TiDB Lightning構成の`region-concurrency`の値を増やすことを検討してください。 `region-concurrency`のデフォルト値は CPU コア数です。 `region-concurrency`の意味は、物理インポート モードと論理インポート モードで異なります。論理インポート モードでは、 `region-concurrency`は書き込み同時実行数です。 設定例： diff --git a/tidb-lightning/tidb-lightning-logical-import-mode.md b/tidb-lightning/tidb-lightning-logical-import-mode.md index 4c87b2172bed0..dfbb3a05dc8c1 100644 --- a/tidb-lightning/tidb-lightning-logical-import-mode.md +++ b/tidb-lightning/tidb-lightning-logical-import-mode.md @@ -25,4 +25,4 @@ CentOS 7の新規インスタンスの使用をお勧めします。仮想マシ ## 制限事項 {#limitations} -複数のTiDB Lightningを使用して同じターゲットにデータをインポートする場合、バックエンドを混在させないでください。つまり、物理インポートモードと論理インポートモードを同時に使用して、単一のTiDBクラスタにデータをインポートしないでください。 +複数のTiDB Lightningを使用して同じターゲットにデータをインポートする場合、バックエンドを混在させないでください。つまり、物理インポートモードと論理インポートモードを同時に使用して、単一のTiDBクラスターにデータをインポートしないでください。 diff --git a/tidb-lightning/tidb-lightning-overview.md b/tidb-lightning/tidb-lightning-overview.md index 1ecf177d0f12c..048b54af03173 100644 --- a/tidb-lightning/tidb-lightning-overview.md +++ b/tidb-lightning/tidb-lightning-overview.md @@ -5,7 +5,7 @@ summary: Lightning とアーキテクチャ全体について学びます。 # TiDB Lightning の概要 {#tidb-lightning-overview} -[TiDB Lightning](https://github.com/pingcap/tidb/tree/release-8.5/lightning) 、TB規模のデータをTiDBクラスタにインポートするためのツールです。TiDBクラスタへの初期データインポートによく使用されます。 +[TiDB Lightning](https://github.com/pingcap/tidb/tree/release-8.5/lightning) 、TB規模のデータをTiDBクラスターにインポートするためのツールです。TiDBクラスターへの初期データインポートによく使用されます。 TiDB Lightning は次のファイル形式をサポートしています。 @@ -16,8 +16,8 @@ TiDB Lightning は次のファイル形式をサポートしています。 TiDB Lightning は次のソースからデータを読み取ることができます。 - 地元 -- [アマゾンS3](/external-storage-uri.md#amazon-s3-uri-format) -- [Googleクラウドストレージ](/external-storage-uri.md#gcs-uri-format) +- [アマゾンS3](/external-ストレージ-uri.md#amazon-s3-uri-format) +- [Googleクラウドストレージ](/external-ストレージ-uri.md#gcs-uri-format) > **注記：** > @@ -41,8 +41,8 @@ TiDB Lightning は、 `backend`で設定された 2 つのインポート モー | ネットワーク帯域幅の消費 | 高い | 低い | | インポート時のACID準拠 | いいえ | はい | | ターゲットテーブル | 空でなければなりません | データを含むことができる | -| TiDB クラスタ バージョン | = 4.0.0 | 全て | -| TiDBクラスタがインポート中にサービスを提供できるかどうか | [限定サービス](/tidb-lightning/tidb-lightning-physical-import-mode.md#limitations) | はい | +| TiDB クラスター バージョン | = 4.0.0 | 全て | +| TiDBクラスターがインポート中にサービスを提供できるかどうか | [限定サービス](/tidb-lightning/tidb-lightning-physical-import-mode.md#limitations) | はい | diff --git a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md index a2cbb48a8b183..0820171b9f395 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md @@ -26,7 +26,7 @@ max-backups = 14 check-requirements = true [mydumper] -# The local data source directory or the URI of the external storage. For more information about the URI of the external storage, see https://docs.pingcap.com/tidb/stable/backup-and-restore-storages/#uri-format. +# The local data source directory or the URI of the external ストレージ. For more information about the URI of the external ストレージ, see https://docs.pingcap.com/tidb/stable/backup-and-restore-ストレージs/#uri-format. data-source-dir = "/data/my_database" [conflict] @@ -192,17 +192,17 @@ mysql> select table_name,index_name,key_data,row_data from conflict_error_v3 lim バージョン6.2.0以降、 TiDB Lightningはデータインポートがオンラインアプリケーションに与える影響を制限するメカニズムを実装しました。この新しいメカニズムにより、 TiDB Lightningはグローバルスケジューリングを一時停止するのではなく、対象テーブルデータが格納されているリージョンのみのスケジューリングを一時停止します。これにより、インポートがオンラインアプリケーションに与える影響が大幅に軽減されます。 -バージョン7.1.0以降では、 TiDB Lightningパラメータ[`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md)を使用して、スケジューリングの一時停止範囲を制御できます。デフォルト値は`"table"`で、これは対象テーブルデータを格納するリージョンのみのスケジューリングが一時停止されることを意味します。クラスタに業務トラフィックがない場合は、インポート中に他のスケジューリングによる干渉を避けるため、このパラメータを`"global"`に設定することをお勧めします。 +バージョン7.1.0以降では、 TiDB Lightningパラメータ[`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md)を使用して、スケジューリングの一時停止範囲を制御できます。デフォルト値は`"table"`で、これは対象テーブルデータを格納するリージョンのみのスケジューリングが一時停止されることを意味します。クラスターに業務トラフィックがない場合は、インポート中に他のスケジューリングによる干渉を避けるため、このパラメータを`"global"`に設定することをお勧めします。 TiDB Lightningは、既にデータが含まれているテーブルへのデータインポートをサポートしていません。 -TiDBクラスタはv6.1.0以降のバージョンである必要があります。それ以前のバージョンでは、 TiDB Lightningは従来の動作を維持し、グローバルなスケジューリングを一時停止するため、インポート中にオンラインアプリケーションに深刻な影響を与えます。 +TiDBクラスターはv6.1.0以降のバージョンである必要があります。それ以前のバージョンでは、 TiDB Lightningは従来の動作を維持し、グローバルなスケジューリングを一時停止するため、インポート中にオンラインアプリケーションに深刻な影響を与えます。 -TiDB Lightning はデフォルトでは、可能な限り最小限の時間だけクラスタのスケジューリングを一時停止します。しかし、デフォルト設定では、高速インポートによってクラスタのパフォーマンスが影響を受ける可能性があります。これを回避するには、インポート速度やクラスタのパフォーマンスに影響を与える可能性のあるその他の要因を制御するために、次のオプションを設定できます。 +TiDB Lightning はデフォルトでは、可能な限り最小限の時間だけクラスターのスケジューリングを一時停止します。しかし、デフォルト設定では、高速インポートによってクラスターのパフォーマンスが影響を受ける可能性があります。これを回避するには、インポート速度やクラスターのパフォーマンスに影響を与える可能性のあるその他の要因を制御するために、次のオプションを設定できます。 ```toml [tikv-importer] @@ -214,7 +214,7 @@ store-write-bwlimit = "128MiB" distsql-scan-concurrency = 3 ``` -TPCCを使用してオンラインアプリケーションをシミュレートし、 TiDB Lightningを使用してTiDBクラスタにデータをインポートすることで、データインポートがTPCCの結果に与える影響を測定できます。テスト結果は以下のとおりです。 +TPCCを使用してオンラインアプリケーションをシミュレートし、 TiDB Lightningを使用してTiDBクラスターにデータをインポートすることで、データインポートがTPCCの結果に与える影響を測定できます。テスト結果は以下のとおりです。 | 並行処理 | TPM | P99 | P90 | 平均 | | ---- | ------- | ------- | ------- | ------- | @@ -231,13 +231,13 @@ TPCCを使用してオンラインアプリケーションをシミュレート テスト結果によると、同時実行数が少ないほど、データインポートがTPCCの結果に与える影響は大きくなる。同時実行数が64以上の場合、データインポートがTPCCの結果に与える影響はごくわずかである。 -したがって、TiDBクラスタにレイテンシに敏感なアプリケーションがあり、かつ同時実行数が少ない場合は、 TiDB Lightningを使用してクラスタにデータをインポートし**ないこと**を強くお勧めします。これは、オンラインアプリケーションに大きな影響を与える可能性があります。 +したがって、TiDBクラスターにレイテンシに敏感なアプリケーションがあり、かつ同時実行数が少ない場合は、 TiDB Lightningを使用してクラスターにデータをインポートし**ないこと**を強くお勧めします。これは、オンラインアプリケーションに大きな影響を与える可能性があります。 ## パフォーマンスチューニング {#performance-tuning} **物理輸入モードの輸入パフォーマンスを向上させるための最も直接的かつ効果的な方法は以下のとおりです。** -- **Lightningがデプロイされているノードのハードウェア、特にCPUと`sorted-key-dir`のstorageデバイスをアップグレードしてください。** +- **Lightningがデプロイされているノードのハードウェア、特にCPUと`sorted-key-dir`のストレージデバイスをアップグレードしてください。** - **並列インポート機能を使用して、水平方向のスケーリングを実現します。** TiDB Lightningは、物理インポートモードでのインポートパフォーマンスに影響を与える同時実行性関連の設定項目をいくつか提供しています。しかし、長年の経験から、以下の4つの設定項目はデフォルト値のままにしておくことをお勧めします。これらの設定項目を調整しても、パフォーマンスが大幅に向上することはありません。 @@ -256,7 +256,7 @@ TiDB Lightningは、物理インポートモードでのインポートパフォ # The maximum concurrency of I/O. When the concurrency is too high, the disk # cache may be frequently refreshed, causing the cache miss and read speed - # to slow down. For different storage mediums, this parameter may need to be + # to slow down. For different ストレージ mediums, this parameter may need to be # adjusted to achieve the best performance. io-concurrency = 5 @@ -295,6 +295,6 @@ backend = "local" check-disk-quota = "30s" ``` -`disk-quota` TiDB Lightningが使用するstorage容量を制限します。デフォルト値は MaxInt64 で、9223372036854775807 バイトです。この値はインポートに必要なディスク容量よりもはるかに大きいため、デフォルト値のままにしておくことは、ディスククォータを設定しないことと同じです。 +`disk-quota` TiDB Lightningが使用するストレージ容量を制限します。デフォルト値は MaxInt64 で、9223372036854775807 バイトです。この値はインポートに必要なディスク容量よりもはるかに大きいため、デフォルト値のままにしておくことは、ディスククォータを設定しないことと同じです。 `check-disk-quota`は、ディスククォータをチェックする間隔です。デフォルト値は 60 秒です。TiDB Lightning がディスククォータをチェックすると、関連データに対して排他ロックを取得し、すべてのインポートスレッドをブロックします。そのため、 TiDB Lightning が書き込みの前に毎回ディスククォータをチェックすると、書き込み効率が大幅に低下します (シングルスレッド書き込みと同じくらい遅くなります)。効率的な書き込みを実現するために、ディスククォータは書き込みの前に毎回チェックされません。代わりに、 TiDB Lightning はすべてのインポートスレッドを一時停止し、 `check-disk-quota`間隔ごとにディスククォータをチェックします。つまり、 `check-disk-quota`の値を大きな値に設定すると、 TiDB Lightningが使用するディスク領域が設定したディスククォータを超える可能性があり、ディスククォータが無効になります。したがって、 `check-disk-quota`の値は小さい値に設定することをお勧めします。この項目の具体的な値は、 TiDB Lightningが実行される環境によって決まります。TiDB Lightning は、環境によって一時ファイルの書き込み速度が異なります。理論的には、書き込み速度が速いほど、 `check-disk-quota`の値は小さくする必要があります。 diff --git a/tidb-lightning/tidb-lightning-physical-import-mode.md b/tidb-lightning/tidb-lightning-physical-import-mode.md index 84c728493ba56..636ffa7e8f0e0 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode.md @@ -22,7 +22,7 @@ backend = "local" 1. TiDB Lightningは、データをインポートする前に、TiKVノードを自動的に「インポートモード」に切り替えます。これにより、書き込みパフォーマンスが向上し、自動コンパクションが停止します。TiDB Lightningは、 TiDB Lightningのバージョンに応じて、グローバルスケジューリングを一時停止するかどうかを決定します。 - v7.1.0 以降では、 TiDB Lightningパラメータ[`pause-pd-scheduler-scope`](/tidb-lightning/tidb-lightning-configuration.md)を使用して、一時停止スケジュールの範囲を制御できます。 - - TiDB Lightningバージョン v6.2.0 から v7.0.0 の場合、グローバルスケジューリングの一時停止の動作は TiDB クラスタのバージョンによって異なります。TiDB クラスタが v6.1.0 以上の場合、 TiDB Lightning はターゲットテーブルデータが格納されているリージョンのスケジューリングを一時停止します。インポートが完了すると、 TiDB Lightning はスケジューリングを回復します。その他のバージョンの場合、 TiDB Lightning はグローバルスケジューリングを一時停止します。 + - TiDB Lightningバージョン v6.2.0 から v7.0.0 の場合、グローバルスケジューリングの一時停止の動作は TiDB クラスターのバージョンによって異なります。TiDB クラスターが v6.1.0 以上の場合、 TiDB Lightning はターゲットテーブルデータが格納されているリージョンのスケジューリングを一時停止します。インポートが完了すると、 TiDB Lightning はスケジューリングを回復します。その他のバージョンの場合、 TiDB Lightning はグローバルスケジューリングを一時停止します。 - TiDB Lightning < v6.2.0 の場合、 TiDB Lightning はグローバル スケジューリングを一時停止します。 2. TiDB Lightning は、ターゲット データベースにテーブル スキーマを作成し、メタデータを取得します。 @@ -31,7 +31,7 @@ backend = "local" 3. 各テーブルは複数の連続した**ブロック**に分割されるため、 TiDB Lightning は大規模なテーブル (200 GB 以上) からデータを並列にインポートできます。 -4. TiDB Lightningは、キーと値のペアを処理するために、各ブロックごとに「エンジンファイル」を用意します。TiDB LightningはSQLダンプを並列に読み取り、データソースをTiDBと同じエンコーディングでキーと値のペアに変換し、キーと値のペアをソートしてローカルの一時storageファイルに書き込みます。 +4. TiDB Lightningは、キーと値のペアを処理するために、各ブロックごとに「エンジンファイル」を用意します。TiDB LightningはSQLダンプを並列に読み取り、データソースをTiDBと同じエンコーディングでキーと値のペアに変換し、キーと値のペアをソートしてローカルの一時ストレージファイルに書き込みます。 5. エンジン ファイルが書き込まれると、 TiDB Lightning はターゲット TiKV クラスター上のデータの分割とスケジュールを開始し、その後、データを TiKV クラスターにインポートします。 @@ -43,7 +43,7 @@ backend = "local" 自動インクリメントIDは行数の**上限**に基づいて推定され、テーブルデータファイルの合計サイズに比例します。そのため、自動インクリメントIDは通常、実際の行数よりも大きくなります。これは、自動インクリメントIDが[必ずしも連続しているわけではない](/mysql-compatibility.md#auto-increment-id)あるため、正常な動作です。 -7. すべての手順が完了すると、 TiDB Lightningは自動的にTiKVノードを「通常モード」に切り替えます。グローバルスケジューリングが一時停止されている場合、 TiDB Lightningはグローバルスケジューリングも回復します。その後、TiDBクラスタは通常通りサービスを提供できるようになります。 +7. すべての手順が完了すると、 TiDB Lightningは自動的にTiKVノードを「通常モード」に切り替えます。グローバルスケジューリングが一時停止されている場合、 TiDB Lightningはグローバルスケジューリングも回復します。その後、TiDBクラスターは通常通りサービスを提供できるようになります。 ## 要件と制限 {#requirements-and-restrictions} @@ -61,7 +61,7 @@ CentOS 7の新規インスタンスの使用をお勧めします。仮想マシ > > 大量のデータをインポートする場合、1回の同時インポートで約2GiBのメモリが消費される可能性があります。メモリ使用量は合計で`region-concurrency * 2 GiB`まで減少します。デフォルトでは、 `region-concurrency`は論理CPUの数と同じです。メモリサイズ（GiB）がCPUの2倍未満の場合、またはインポート中にOOMが発生する場合は、OOMを回避するために`region-concurrency`減らすことができます。 -**ストレージ**: 設定項目`sorted-kv-dir`は、ソートされたキーバリューファイルの一時storageディレクトリを指定します。このディレクトリは空でなければならず、storage容量はインポートするデータセットのサイズよりも大きくなければなりません。インポートのパフォーマンスを向上させるには、設定項目`data-source-dir`とは異なるディレクトリを使用し、フラッシュstorageと排他I/Oを使用することを推奨します。 +**ストレージ**: 設定項目`sorted-kv-dir`は、ソートされたキーバリューファイルの一時ストレージディレクトリを指定します。このディレクトリは空でなければならず、ストレージ容量はインポートするデータセットのサイズよりも大きくなければなりません。インポートのパフォーマンスを向上させるには、設定項目`data-source-dir`とは異なるディレクトリを使用し、フラッシュストレージと排他I/Oを使用することを推奨します。 **ネットワーク**: 10Gbps イーサネット カードを推奨します。 @@ -72,10 +72,10 @@ CentOS 7の新規インスタンスの使用をお勧めします。仮想マシ ### 制限事項 {#limitations} -- 本番のTiDBクラスタにデータを直接インポートする際に、物理インポートモードを使用しないでください。パフォーマンスに重大な影響を及ぼします。必要な場合は、 [テーブルレベルでスケジュールを一時停止する](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#scope-of-pausing-scheduling-during-import)を参照してください。 -- TiDBクラスタにレイテンシの影響を受けやすいアプリケーションがあり、同時実行性が低い場合は、物理インポートモードを使用してクラスタにデータをインポート**しない**ことを強くお勧めします。このモードは、オンラインアプリケーションに重大な影響を与える可能性があります。 -- 複数のTiDB Lightningインスタンスを同時に実行して同じTiDBクラスタにデータをインポートする場合は、 [並行輸入](/tidb-lightning/tidb-lightning-distributed-import.md)有効にしてインポートを調整できます。各インスタンスが**異なるテーブル**にデータをインポートする場合は、並列インポートオプションは必要ありません。ただし、複数のインスタンスが**同じテーブル**にデータをインポートする場合は、競合を防ぎ、データの整合性を確保するために、並列インポートを有効にする必要があります。 -- 複数のTiDB Lightningを使用して同じターゲットクラスタにデータをインポートする場合、インポートモードを混在させないでください。つまり、物理インポートモードと論理インポートモードを同時に使用しないでください。 +- 本番のTiDBクラスターにデータを直接インポートする際に、物理インポートモードを使用しないでください。パフォーマンスに重大な影響を及ぼします。必要な場合は、 [テーブルレベルでスケジュールを一時停止する](/tidb-lightning/tidb-lightning-physical-import-mode-usage.md#scope-of-pausing-scheduling-during-import)を参照してください。 +- TiDBクラスターにレイテンシの影響を受けやすいアプリケーションがあり、同時実行性が低い場合は、物理インポートモードを使用してクラスターにデータをインポート**しない**ことを強くお勧めします。このモードは、オンラインアプリケーションに重大な影響を与える可能性があります。 +- 複数のTiDB Lightningインスタンスを同時に実行して同じTiDBクラスターにデータをインポートする場合は、 [並行輸入](/tidb-lightning/tidb-lightning-distributed-import.md)有効にしてインポートを調整できます。各インスタンスが**異なるテーブル**にデータをインポートする場合は、並列インポートオプションは必要ありません。ただし、複数のインスタンスが**同じテーブル**にデータをインポートする場合は、競合を防ぎ、データの整合性を確保するために、並列インポートを有効にする必要があります。 +- 複数のTiDB Lightningを使用して同じターゲットクラスターにデータをインポートする場合、インポートモードを混在させないでください。つまり、物理インポートモードと論理インポートモードを同時に使用しないでください。 - データのインポート中は、ターゲットテーブルでDDLおよびDML操作を実行しないでください。そうしないと、インポートが失敗したり、データの不整合が生じたりする可能性があります。また、読み取り操作は、読み取ったデータに不整合が生じる可能性があるため、実行しないことをお勧めします。インポート操作が完了したら、読み取りおよび書き込み操作を実行できます。 - 1 つの Lightning プロセスでインポートできるのは、最大 10 TiB のテーブル 1 つだけです。並列インポートでは、最大 10 個の Lightning インスタンスを使用できます。 diff --git a/tidb-lightning/tidb-lightning-prechecks.md b/tidb-lightning/tidb-lightning-prechecks.md index 051c2538e2f3d..320471b424d30 100644 --- a/tidb-lightning/tidb-lightning-prechecks.md +++ b/tidb-lightning/tidb-lightning-prechecks.md @@ -11,10 +11,10 @@ TiDB 5.3.0以降、 TiDB Lightningは移行タスク実行前に設定をチェ | チェック項目 | サポートされているバージョン | 説明 | | ---------------------------------------------- | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| クラスタのバージョンとステータス | = 5.3.0 | 構成でクラスターを接続できるかどうか、および TiKV/PD/ TiFlashバージョンが物理インポート モードをサポートしているかどうかを確認します。 | -| 権限 | = 5.3.0 | データ ソースがクラウドstorage(Amazon S3) の場合、 TiDB Lightning に必要な権限があるかどうかを確認し、権限不足のためにインポートが失敗しないことを確認します。 | -| ディスク容量 | = 5.3.0 | ローカルディスクと TiKV クラスターに、データのインポートに十分な空き容量があるかどうかを確認します。TiDB Lightning はデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。物理インポートモードでは、外部ソートをローカルで実行する必要があるため、 TiDB Lightning はローカルstorageが十分かどうかも確認します。TiKV クラスターの空き容量とローカルストレージのstorage容量 ( `sort-kv-dir`で制御) の詳細については、 [下流のstorageスペース要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)と[リソース要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)参照してください。 | -| リージョン配信状況 | = 5.3.0 | TiKVクラスタ内のリージョンが均等に分散されているか、また空のリージョンが多すぎないかを確認してください。空のリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 | +| クラスターのバージョンとステータス | = 5.3.0 | 構成でクラスターを接続できるかどうか、および TiKV/PD/ TiFlashバージョンが物理インポート モードをサポートしているかどうかを確認します。 | +| 権限 | = 5.3.0 | データ ソースがクラウドストレージ(Amazon S3) の場合、 TiDB Lightning に必要な権限があるかどうかを確認し、権限不足のためにインポートが失敗しないことを確認します。 | +| ディスク容量 | = 5.3.0 | ローカルディスクと TiKV クラスターに、データのインポートに十分な空き容量があるかどうかを確認します。TiDB Lightning はデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。物理インポートモードでは、外部ソートをローカルで実行する必要があるため、 TiDB Lightning はローカルストレージが十分かどうかも確認します。TiKV クラスターの空き容量とローカルストレージのストレージ容量 ( `sort-kv-dir`で制御) の詳細については、 [下流のストレージスペース要件](/tidb-lightning/tidb-lightning-requirements.md#ストレージ-space-of-the-target-database)と[リソース要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)参照してください。 | +| リージョン配信状況 | = 5.3.0 | TiKVクラスター内のリージョンが均等に分散されているか、また空のリージョンが多すぎないかを確認してください。空のリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 | | データファイル内の非常に大きなCSVファイル | = 5.3.0 | バックアップファイルに10GiBを超えるCSVファイルがあり、自動スライスが有効になっていない場合（StrictFormat=false）、インポートのパフォーマンスに影響します。このチェックは、データが正しい形式であること、および自動スライスが有効になっていることを確認するためのものです。 | | ブレークポイントからの回復 | = 5.3.0 | このチェックにより、ブレークポイント回復プロセス中に、間違ったデータがインポートされるような変更がデータベースのソース ファイルまたはスキーマに加えられないことが保証されます。 | | 既存のテーブルにインポートする | = 5.3.0 | 既に作成されたテーブルにインポートする場合、ソースファイルが既存のテーブルと可能な限り一致するかどうかを確認します。列数が一致しているかどうかを確認します。ソースファイルに列名がある場合は、列名が一致しているかどうかを確認します。ソースファイルにデフォルトの列がある場合は、その列にデフォルト値が設定されているかどうかを確認し、設定されている場合はチェックに合格します。 | diff --git a/tidb-lightning/tidb-lightning-requirements.md b/tidb-lightning/tidb-lightning-requirements.md index 4f81f1e3a4ff6..a48f6c4d5ea1e 100644 --- a/tidb-lightning/tidb-lightning-requirements.md +++ b/tidb-lightning/tidb-lightning-requirements.md @@ -13,9 +13,9 @@ TiDB Lightningを使用する前に、環境が要件を満たしているかど
    特徴範囲必要な権限備考
    必須基本関数ターゲットテーブル作成、選択、挿入、更新、削除、ドロップ、変更DROP は、tidb-lightning-ctl が checkpoint-destroy-all コマンドを実行する場合にのみ必要です。
    ターゲットデータベース作成する
    必須論理インポートモード情報スキーマ列選択
    物理インポートモードmysql.tidb選択
    -素晴らしい
    -制限付き変数管理者、制限付きテーブル管理者ターゲットTiDBがSEMを有効にする場合に必要
    推奨競合検出、最大エラーlightning.task-info-schema-name 用に設定されたスキーマ選択、挿入、更新、削除、作成、削除必要でない場合は、値を "" に設定する必要があります
    オプション並行輸入lightning.meta-schema-name 用に設定されたスキーマ選択、挿入、更新、削除、作成、削除必要でない場合は、値を "" に設定する必要があります
    オプションチェックポイント.ドライバー = "mysql" checkpoint.schema 設定選択、挿入、更新、削除、作成、削除チェックポイント情報がファイルではなくデータベースに保存される場合に必要
    -## 対象データベースのストレージスペース {#storage-space-of-the-target-database} +## 対象データベースのストレージスペース {#ストレージ-space-of-the-target-database} -ターゲットTiKVクラスターには、インポートしたデータを保存するための十分なディスク容量が必要です。1 に加え[標準的なハードウェア要件](/hardware-and-software-requirements.md) 、ターゲットTiKVクラスターのstorage容量**は、データソースのサイズ × レプリカ数 × 2**よりも大きくなければなりません。例えば、クラスターがデフォルトで3つのレプリカを使用する場合、ターゲットTiKVクラスターにはデータソースのサイズの6倍よりも大きなstorage容量が必要です。式に x 2 が含まれているのは、以下の理由によるものです。 +ターゲットTiKVクラスターには、インポートしたデータを保存するための十分なディスク容量が必要です。1 に加え[標準的なハードウェア要件](/hardware-and-software-requirements.md) 、ターゲットTiKVクラスターのストレージ容量**は、データソースのサイズ × レプリカ数 × 2**よりも大きくなければなりません。例えば、クラスターがデフォルトで3つのレプリカを使用する場合、ターゲットTiKVクラスターにはデータソースのサイズの6倍よりも大きなストレージ容量が必要です。式に x 2 が含まれているのは、以下の理由によるものです。 - インデックスは余分なスペースを占める可能性があります。 - RocksDB には空間増幅効果があります。 diff --git a/tidb-lightning/troubleshoot-tidb-lightning.md b/tidb-lightning/troubleshoot-tidb-lightning.md index 74f561a7c8a2b..f6dca54e592da 100644 --- a/tidb-lightning/troubleshoot-tidb-lightning.md +++ b/tidb-lightning/troubleshoot-tidb-lightning.md @@ -152,7 +152,7 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= ### TiDB Lightningがモードを切り替えるときに、 rpc error: code = Unimplemented ... {#encounter-code-rpc-error-code-unimplemented-code-when-tidb-lightning-switches-the-mode} -**原因**: クラスタ内の一部のノードが`switch-mode`サポートしていません。例えば、 TiFlash のバージョンが`v4.0.0-rc.2` 、 [`switch-mode`はサポートされていません](https://github.com/pingcap/tidb-lightning/issues/273)より前の場合などです。 +**原因**: クラスター内の一部のノードが`switch-mode`サポートしていません。例えば、 TiFlash のバージョンが`v4.0.0-rc.2` 、 [`switch-mode`はサポートされていません](https://github.com/pingcap/tidb-lightning/issues/273)より前の場合などです。 **ソリューション**： diff --git a/tidb-monitoring-api.md b/tidb-monitoring-api.md index 094b5edcc2303..d131f9af718b0 100644 --- a/tidb-monitoring-api.md +++ b/tidb-monitoring-api.md @@ -7,12 +7,12 @@ summary: TiDB 監視サービスの API を学習します。 次のタイプのインターフェースを使用して、TiDB クラスターのステータスを監視できます。 -- [ステータスインターフェース](#use-the-status-interface) : このインターフェースはHTTPインターフェースを使用してコンポーネント情報を取得します。このインターフェースを使用すると、現在のTiDBサーバーの[実行ステータス](#running-status)とテーブルの[storage情報](#storage-information)取得できます。 +- [ステータスインターフェース](#use-the-status-interface) : このインターフェースはHTTPインターフェースを使用してコンポーネント情報を取得します。このインターフェースを使用すると、現在のTiDBサーバーの[実行ステータス](#running-status)とテーブルの[ストレージ情報](#ストレージ-information)取得できます。 - [メトリクスインターフェース](#use-the-metrics-interface) : このインターフェースは Prometheus を使用してコンポーネント内のさまざまな操作の詳細情報を記録し、Grafana を使用してこれらのメトリックを表示します。 ## ステータスインターフェースを使用する {#use-the-status-interface} -ステータスインターフェースは、TiDBクラスタ内の特定のコンポーネントの基本情報を監視します。また、Keepaliveメッセージの監視インターフェースとしても機能します。さらに、配置Driver（PD）のステータスインターフェースは、TiKVクラスタ全体の詳細情報を取得できます。 +ステータスインターフェースは、TiDBクラスター内の特定のコンポーネントの基本情報を監視します。また、Keepaliveメッセージの監視インターフェースとしても機能します。さらに、配置Driver（PD）のステータスインターフェースは、TiKVクラスター全体の詳細情報を取得できます。 ### TiDBサーバー {#tidb-server} @@ -32,12 +32,12 @@ curl http://127.0.0.1:10080/status } ``` -#### 保管情報 {#storage-information} +#### 保管情報 {#ストレージ-information} -次の例では、 `http://${host}:${port}/schema_storage/${db}/${table}`使用して特定のデータテーブルのstorage情報を取得します。結果は**JSON**形式で返されます。 +次の例では、 `http://${host}:${port}/schema_ストレージ/${db}/${table}`使用して特定のデータテーブルのストレージ情報を取得します。結果は**JSON**形式で返されます。 ```bash -curl http://127.0.0.1:10080/schema_storage/mysql/stats_histograms +curl http://127.0.0.1:10080/schema_ストレージ/mysql/stats_histograms ``` { @@ -52,7 +52,7 @@ curl http://127.0.0.1:10080/schema_storage/mysql/stats_histograms } ```bash -curl http://127.0.0.1:10080/schema_storage/test +curl http://127.0.0.1:10080/schema_ストレージ/test ``` [ diff --git a/tidb-monitoring-framework.md b/tidb-monitoring-framework.md index 947817a13ee07..56f9c4d562a64 100644 --- a/tidb-monitoring-framework.md +++ b/tidb-monitoring-framework.md @@ -53,4 +53,4 @@ Grafanaは、メトリクスを分析および視覚化するためのオープ ## TiDBダッシュボード {#tidb-dashboard} -TiDBダッシュボードは、TiDBクラスタの監視、診断、管理のためのWeb UIで、v4.0で導入されました。PDコンポーネントに組み込まれているため、別途導入する必要はありません。詳細については、 [TiDBダッシュボードの紹介](/dashboard/dashboard-intro.md)ご覧ください。 +TiDBダッシュボードは、TiDBクラスターの監視、診断、管理のためのWeb UIで、v4.0で導入されました。PDコンポーネントに組み込まれているため、別途導入する必要はありません。詳細については、 [TiDBダッシュボードの紹介](/dashboard/dashboard-intro.md)ご覧ください。 diff --git a/tidb-operator-overview.md b/tidb-operator-overview.md index 2ebf6ecbbd919..d882fb866849e 100644 --- a/tidb-operator-overview.md +++ b/tidb-operator-overview.md @@ -5,7 +5,7 @@ summary: Kubernetes 上の TiDB クラスターの自動運用システムでTiD # TiDB Operator {#tidb-operator} -[TiDB Operator](https://github.com/pingcap/tidb-operator) 、Kubernetes上のTiDBクラスタの自動運用システムです。デプロイメント、アップグレード、スケーリング、バックアップ、フェイルオーバー、設定変更など、TiDBのライフサイクル全体を管理します。TiDB Operatorを使用することで、パブリッククラウドまたはプライベートクラウドにデプロイされたKubernetesクラスタでTiDBをシームレスに実行できます。 +[TiDB Operator](https://github.com/pingcap/tidb-operator) 、Kubernetes上のTiDBクラスターの自動運用システムです。デプロイメント、アップグレード、スケーリング、バックアップ、フェイルオーバー、設定変更など、TiDBのライフサイクル全体を管理します。TiDB Operatorを使用することで、パブリッククラウドまたはプライベートクラウドにデプロイされたKubernetesクラスターでTiDBをシームレスに実行できます。 現在、 TiDB Operator のドキュメント（TiDB on Kubernetes ドキュメントとも呼ばれます）は、TiDB のドキュメントとは独立しています。ドキュメントにアクセスするには、次のリンクをクリックしてください。 diff --git a/tidb-performance-tuning-config.md b/tidb-performance-tuning-config.md index c8f21b661a3a3..e0187da7bbb86 100644 --- a/tidb-performance-tuning-config.md +++ b/tidb-performance-tuning-config.md @@ -28,7 +28,7 @@ TiDBのパフォーマンスを最適化するために、一般的に以下の - [SQL準備済み実行プランキャッシュ](/sql-prepared-plan-cache.md)などの実行プランキャッシュ[準備されていないプランキャッシュ](/sql-non-prepared-plan-cache.md)強化します[インスタンスレベルの実行プランキャッシュ](/system-variables.md#tidb_enable_instance_plan_cache-new-in-v840) - [オプティマイザー修正コントロール](/optimizer-fix-controls.md)を使用して TiDB オプティマイザの動作を最適化します。 -- storageエンジン[タイタン](/storage-engine/titan-overview.md)をより積極的に活用する。 +- ストレージエンジン[Titan](/ストレージ-engine/titan-overview.md)をより積極的に活用する。 - 書き込み負荷の高いワークロード下でも最適かつ安定したパフォーマンスを確保するために、TiKVの圧縮およびフロー制御の設定を微調整します。 これらの設定は、多くのワークロードのパフォーマンスを大幅に向上させることができます。ただし、他の最適化と同様に、本番に展開する前に、必ずご自身の環境で十分にテストしてください。 @@ -99,9 +99,9 @@ enabled = true min-blob-size = "1KB" blob-file-compression = "zstd" -[storage] +[ストレージ] scheduler-pending-write-threshold = "512MiB" -[storage.flow-control] +[ストレージ.flow-control] l0-files-threshold = 50 soft-pending-compaction-bytes-limit = "512GiB" @@ -116,14 +116,14 @@ level0-slowdown-writes-trigger = 20 soft-pending-compaction-bytes-limit = "192GiB" ``` -| コンフィグレーションアイテム | 説明 | 注記 | +| 設定アイテム | 説明 | 注記 | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| [`concurrent-send-snap-limit`](/tikv-configuration-file.md#concurrent-send-snap-limit) [`concurrent-recv-snap-limit`](/tikv-configuration-file.md#concurrent-recv-snap-limit) [`snap-io-max-bytes-per-sec`](/tikv-configuration-file.md#snap-io-max-bytes-per-sec) | TiKVのスケーリング操作中に、同時スナップショット転送量とI/O帯域幅の制限を設定します。制限値を高く設定すると、データ移行が高速化され、スケーリング時間が短縮されます。 | これらの制限を調整すると、スケーリング速度とオンライン取引パフォーマンスのトレードオフに影響します。 | +| [`concurrent-send-snap-limit`](/tikv-configuration-file.md#concurrent-send-snap-limit) [`concurrent-recv-snap-limit`](/tikv-configuration-file.md#concurrent-recv-snap-limit) [`snap-io-max-bytes-per-sec`](/tikv-configuration-file.md#snap-io-max-bytes-per-sec) | TiKVのスケーリング操作中に、同時スナップショット転送量とI/O帯域幅の制限を設定します。制限値を高く設定すると、データ移行が高速化され、スケーリング時間が短縮されます。 | これらの制限を調整すると、スケーリング速度とオンライントランザクションパフォーマンスのトレードオフに影響します。 | | [`rocksdb.max-manifest-file-size`](/tikv-configuration-file.md#max-manifest-file-size) | RocksDB マニフェストファイルの最大サイズを設定します。このファイルには、SST ファイルとデータベースの状態変更に関するメタデータが記録されます。このサイズを大きくすると、マニフェストファイルの書き換え頻度が減り、フォアグラウンド書き込みパフォーマンスへの影響を最小限に抑えることができます。 | デフォルト値は`128MiB`です。SSTファイルが多数存在する環境（例えば、数十万個）では、マニフェストファイルの書き換えが頻繁に行われると、書き込みパフォーマンスが低下する可能性があります。このパラメータを`256MiB`以上の値に調整することで、最適なパフォーマンスを維持できます。 | -| [`rocksdb.titan`](/tikv-configuration-file.md#rocksdbtitan) [`rocksdb.defaultcf.titan`](/tikv-configuration-file.md#rocksdbdefaultcftitan) [`min-blob-size`](/tikv-configuration-file.md#min-blob-size) [`blob-file-compression`](/tikv-configuration-file.md#blob-file-compression) | Titanstorageエンジンを有効にすることで、書き込み増幅を低減し、ディスクI/Oのボトルネックを緩和できます。特に、RocksDBの圧縮処理が書き込みワークロードに追いつかず、圧縮待ちバイトが蓄積される場合に有効です。 | 書き込み増幅が主なボトルネックである場合に有効にします。トレードオフは以下のとおりです。
    • プライマリキー範囲スキャンにおけるパフォーマンスへの影響の可能性。
    • 空間増幅率の向上（最悪の場合、最大2倍）。
    • ブロブキャッシュのための追加メモリ使用量。
    | -| [`storage.scheduler-pending-write-threshold`](/tikv-configuration-file.md#scheduler-pending-write-threshold) | TiKVスケジューラで書き込みキューの最大サイズを設定します。保留中の書き込みタスクの合計サイズがこのしきい値を超えると、TiKVは新規書き込み要求に対してエラーコード`Server Is Busy`を返します。 | デフォルト値は`100MiB`です。書き込み同時実行数が多い場合や、一時的な書き込みスパイクが発生する場合は、このしきい値を上げる（例えば`512MiB`にする）ことで負荷に対応できます。ただし、書き込みキューが継続的に蓄積され、このしきい値を超える場合は、根本的なパフォーマンスの問題が発生している可能性があり、さらに調査が必要です。 | -| [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold) | kvDB L0ファイルの数に基づいて、書き込みフロー制御がトリガーされるタイミングを制御します。しきい値を上げると、書き込み負荷が高い場合の書き込み停止が減少します。 | しきい値を高く設定すると、L0ファイルが多数存在する場合に、より積極的な圧縮処理が行われる可能性があります。 | -| [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 書き込みフロー制御を管理するために、保留中の圧縮バイトのしきい値を制御します。ソフトリミットを設定すると、部分的な書き込み拒否が発生します。 | デフォルトのソフトリミットは`192GiB`です。書き込み負荷の高いシナリオでは、圧縮処理が追いつかない場合、保留中の圧縮バイトが蓄積され、フロー制御がトリガーされる可能性があります。リミットを調整することでバッファ領域を増やすことができますが、蓄積が続く場合は、さらなる調査が必要な根本的な問題があることを示しています。 | +| [`rocksdb.titan`](/tikv-configuration-file.md#rocksdbtitan) [`rocksdb.defaultcf.titan`](/tikv-configuration-file.md#rocksdbdefaultcftitan) [`min-blob-size`](/tikv-configuration-file.md#min-blob-size) [`blob-file-compression`](/tikv-configuration-file.md#blob-file-compression) | Titanストレージエンジンを有効にすることで、書き込み増幅を低減し、ディスクI/Oのボトルネックを緩和できます。特に、RocksDBの圧縮処理が書き込みワークロードに追いつかず、圧縮待ちバイトが蓄積される場合に有効です。 | 書き込み増幅が主なボトルネックである場合に有効にします。トレードオフは以下のとおりです。
    • プライマリキー範囲スキャンにおけるパフォーマンスへの影響の可能性。
    • 空間増幅率の向上（最悪の場合、最大2倍）。
    • ブロブキャッシュのための追加メモリ使用量。
    | +| [`ストレージ.scheduler-pending-write-threshold`](/tikv-configuration-file.md#scheduler-pending-write-threshold) | TiKVスケジューラで書き込みキューの最大サイズを設定します。保留中の書き込みタスクの合計サイズがこのしきい値を超えると、TiKVは新規書き込み要求に対してエラーコード`Server Is Busy`を返します。 | デフォルト値は`100MiB`です。書き込み同時実行数が多い場合や、一時的な書き込みスパイクが発生する場合は、このしきい値を上げる（例えば`512MiB`にする）ことで負荷に対応できます。ただし、書き込みキューが継続的に蓄積され、このしきい値を超える場合は、根本的なパフォーマンスの問題が発生している可能性があり、さらに調査が必要です。 | +| [`ストレージ.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold) | kvDB L0ファイルの数に基づいて、書き込みフロー制御がトリガーされるタイミングを制御します。しきい値を上げると、書き込み負荷が高い場合の書き込み停止が減少します。 | しきい値を高く設定すると、L0ファイルが多数存在する場合に、より積極的な圧縮処理が行われる可能性があります。 | +| [`ストレージ.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit) | 書き込みフロー制御を管理するために、保留中の圧縮バイトのしきい値を制御します。ソフトリミットを設定すると、部分的な書き込み拒否が発生します。 | デフォルトのソフトリミットは`192GiB`です。書き込み負荷の高いシナリオでは、圧縮処理が追いつかない場合、保留中の圧縮バイトが蓄積され、フロー制御がトリガーされる可能性があります。リミットを調整することでバッファ領域を増やすことができますが、蓄積が続く場合は、さらなる調査が必要な根本的な問題があることを示しています。 | | [`rocksdb.(defaultcf|writecf|lockcf).level0-slowdown-writes-trigger`](/tikv-configuration-file.md#level0-slowdown-writes-trigger)と[`rocksdb.(defaultcf|writecf|lockcf).soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1) | `level0-slowdown-writes-trigger`と`soft-pending-compaction-bytes-limit`デフォルト値に手動で設定する必要があります。こうすることで、フロー制御パラメータの影響を受けなくなります。さらに、Rocksdbパラメータを設定して、デフォルトパラメータと同じ圧縮効率を維持してください。 | 詳細については、 [第18708号](https://github.com/tikv/tikv/issues/18708)参照してください。 | 前述の表に示されている圧縮およびフロー制御構成の調整は、以下の仕様を持つインスタンスへの TiKV デプロイメントに合わせて調整されていることに注意してください。 @@ -139,15 +139,15 @@ soft-pending-compaction-bytes-limit = "192GiB" - [`rocksdb.rate-bytes-per-sec`](/tikv-configuration-file.md#rate-bytes-per-sec) : 通常はデフォルト値を使用します。圧縮 I/O がディスク帯域幅のかなりの割合を消費していることに気づいた場合は、レートをディスクの最大スループットの約 60% に制限することを検討してください。これにより、圧縮作業のバランスが取れ、ディスクが飽和状態にならないようになります。たとえば、 **1 GiB/s**の定格のディスクでは、これを約`600MiB`に設定します。 -- [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1)と[`storage.flow-control.hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit-1) ：これらの制限を、利用可能なディスク容量に比例して増やします（例えば、それぞれ1 TiBと2 TiB）。これにより、圧縮処理のためのバッファが増えます。 +- [`ストレージ.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit-1)と[`ストレージ.flow-control.hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit-1) ：これらの制限を、利用可能なディスク容量に比例して増やします（例えば、それぞれ1 TiBと2 TiB）。これにより、圧縮処理のためのバッファが増えます。 これらの設定は、リソースの効率的な利用を確保し、書き込み負荷がピークに達した際の潜在的なボトルネックを最小限に抑えるのに役立ちます。 > **注記：** > -> TiKVは、システムの安定性を確保するために、スケジューラレイヤーでフロー制御を実装しています。保留中の圧縮バイト数や書き込みキューサイズなどの重要なしきい値を超えると、TiKVは書き込み要求を拒否し、ServerIsBusyエラーを返します。このエラーは、バックグラウンドの圧縮プロセスがフォアグラウンドの書き込み操作の現在の速度に追いつけないことを示しています。フロー制御が有効になると、通常、レイテンシーの急増とクエリスループットの低下（QPSの低下）が発生します。これらのパフォーマンス低下を防ぐには、包括的なキャパシティプランニングと、圧縮パラメータおよびstorage設定の適切な構成が不可欠です。 +> TiKVは、システムの安定性を確保するために、スケジューラレイヤーでフロー制御を実装しています。保留中の圧縮バイト数や書き込みキューサイズなどの重要なしきい値を超えると、TiKVは書き込み要求を拒否し、ServerIsBusyエラーを返します。このエラーは、バックグラウンドの圧縮プロセスがフォアグラウンドの書き込み操作の現在の速度に追いつけないことを示しています。フロー制御が有効になると、通常、レイテンシーの急増とクエリスループットの低下（QPSの低下）が発生します。これらのパフォーマンス低下を防ぐには、包括的なキャパシティプランニングと、圧縮パラメータおよびストレージ設定の適切な構成が不可欠です。 -### TiFlash -学習者向け設定 {#tiflash-learner-configurations} +### TiFlash -ラーナー向け設定 {#tiflash-learner-configurations} TiFlash-learner 設定ファイルに以下の設定項目を追加してください。 @@ -156,9 +156,9 @@ TiFlash-learner 設定ファイルに以下の設定項目を追加してくだ snap-io-max-bytes-per-sec = "300MiB" ``` -| コンフィグレーションアイテム | 説明 | 注記 | +| 設定アイテム | 説明 | 注記 | | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | -| [`snap-io-max-bytes-per-sec`](/tikv-configuration-file.md#snap-io-max-bytes-per-sec) | TiKVからTiFlashへのデータレプリケーションにおける、最大許容ディスク帯域幅を制御します。制限値を高く設定すると、初期データロードとキャッチアップレプリケーションが高速化されます。 | 帯域幅の消費量が増加すると、オンライン取引のパフォーマンスに影響が出る可能性があります。レプリケーション速度とシステム安定性のバランスを取ることが重要です。 | +| [`snap-io-max-bytes-per-sec`](/tikv-configuration-file.md#snap-io-max-bytes-per-sec) | TiKVからTiFlashへのデータレプリケーションにおける、最大許容ディスク帯域幅を制御します。制限値を高く設定すると、初期データロードとキャッチアップレプリケーションが高速化されます。 | 帯域幅の消費量が増加すると、オンライントランザクションのパフォーマンスに影響が出る可能性があります。レプリケーション速度とシステム安定性のバランスを取ることが重要です。 | ## ベンチマーク {#benchmark} @@ -336,7 +336,7 @@ go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p ワークロードに頻繁に発生する小規模なトランザクションや、タイムスタンプを頻繁に要求するクエリが含まれる場合、 [TSO（タイムスタンプオラクル）](/glossary.md#timestamp-oracle-tso)パフォーマンスのボトルネックになる可能性があります。TSO の待機時間がシステムに影響を与えているかどうかを確認するには、 [**パフォーマンス概要 > SQL実行時間概要**](/grafana-performance-overview-dashboard.md#sql-execute-time-overview)パネルを確認してください。TSO の待機時間が SQL 実行時間の大部分を占める場合は、次の最適化を検討してください。 - 厳密な一貫性を必要としない読み取り操作には、低精度TSO（ [`tidb_low_resolution_tso`](/system-variables.md#tidb_low_resolution_tso)を有効にする）を使用します。詳細については、 [解決策1：低精度TSOを使用する](#solution-1-low-precision-tso)参照してください。 -- 可能な場合は、小さな取引をまとめて大きな取引にします。詳細については、 [解決策2：TSO要求の並列モード](#solution-2-parallel-mode-for-tso-requests)参照してください。 +- 可能な場合は、小さなトランザクションをまとめて大きなトランザクションにします。詳細については、 [解決策2：TSO要求の並列モード](#solution-2-parallel-mode-for-tso-requests)参照してください。 #### 解決策1：低精度TSO {#solution-1-low-precision-tso} @@ -351,7 +351,7 @@ go-ycsb run mysql -P /ycsb/workloads/workloada -p {host} -p mysql.port={port} -p メリットとデメリット： - キャッシュされたTSOを使用して古いデータの読み取りを有効にすることで、クエリのレイテンシーを削減し、新しいタイムスタンプを要求する必要性をなくします。 -- パフォーマンスとデータの一貫性のバランスを取る：この機能は、古い読み取りデータが許容されるシナリオにのみ適しています。厳密なデータの一貫性が求められる場合には、使用を推奨しません。 +- パフォーマンスとデータの一貫性のバランスを取る：この機能は、ステイル読み取りデータが許容されるシナリオにのみ適しています。厳密なデータの一貫性が求められる場合には、使用を推奨しません。 この最適化を有効にするには： @@ -431,7 +431,7 @@ TiDBは、さまざまなワークロードパターンに合わせてパフォ トランザクションモードは、システム変数[`tidb_txn_mode`](/system-variables.md#tidb_txn_mode)を使用して設定できます。 -- [悲観的な取引モード](/pessimistic-transaction.md) （デフォルト）： +- [悲観的なトランザクションモード](/pessimistic-transaction.md) （デフォルト）： - 書き込み競合が発生する可能性のある一般的なワークロードに適しています。 - より強力な一貫性保証を提供します。 @@ -440,10 +440,10 @@ TiDBは、さまざまなワークロードパターンに合わせてパフォ SET SESSION tidb_txn_mode = "pessimistic"; ``` -- [楽観的な取引モード](/optimistic-transaction.md) : +- [楽観的なトランザクションモード](/optimistic-transaction.md) : - 書き込み競合が最小限のワークロードに適しています。 - - 複数明細の取引におけるパフォーマンスが向上しました。 + - 複数明細のトランザクションにおけるパフォーマンスが向上しました。 - 例： `BEGIN; INSERT...; INSERT...; COMMIT;` . ```sql @@ -479,7 +479,7 @@ TiDBは集計処理をTiKVにプッシュダウンすることで、データ転 - 固有の識別子またはタイムスタンプ。 - 例：ユーザーID、トランザクションID。 -#### コンフィグレーション {#configuration} +#### 設定 {#configuration} セッションレベルまたはグローバルレベルでプッシュダウン最適化を有効にする： diff --git a/tidb-resource-control-ru-groups.md b/tidb-resource-control-ru-groups.md index b968f69468f2f..9fb7b98709c1a 100644 --- a/tidb-resource-control-ru-groups.md +++ b/tidb-resource-control-ru-groups.md @@ -10,13 +10,13 @@ aliases: ['/ja/tidb/v8.5/tidb-resource-control/','/ja/tidb/stable/tidb-resource- > > この機能は、 [TiDB Cloud Starter](https://docs.pingcap.com/tidbcloud/select-cluster-tier#starter)および[TiDB Cloud Essential](https://docs.pingcap.com/tidbcloud/select-cluster-tier#essential)インスタンスではご利用いただけません。 -クラスタ管理者として、リソース制御機能を使用して、リソースグループの作成、リソースグループの割り当て量の設定、およびユーザーをそれらのグループにバインドすることができます。 +クラスター管理者として、リソース制御機能を使用して、リソースグループの作成、リソースグループの割り当て量の設定、およびユーザーをそれらのグループにバインドすることができます。 TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能とTiKVレイヤーの優先度スケジューリング機能という2つのレイヤーのリソース管理機能を提供します。これらの2つの機能は、個別に、または同時に有効にすることができます。詳しくは[リソース制御のためのパラメータ](#parameters-for-resource-control)については を参照してください。これにより、TiDBレイヤーはリソースグループに設定されたクォータに基づいてユーザーの読み取りおよび書き込み要求のフローを制御し、TiKVレイヤーは読み取りおよび書き込みクォータにマッピングされた優先度に基づいて要求をスケジュールすることができます。この操作を行うことで、アプリケーションのリソース分離を確保し、サービス品質（QoS）要件を満たすことができます。 - TiDBフロー制御：TiDBフロー制御は を使用します。バケットに十分なトークンがなく、リソースグループ [トークンバケットアルゴリズム](https://en.wikipedia.org/wiki/Token_bucket)`BURSTABLE`オプションを指定していない場合、リソースグループへのリクエストはトークンバケットがトークンを補充するまで待機し、再試行します。再試行はタイムアウトにより失敗する可能性があります。 -- TiKV スケジューリング: 必要に応じて絶対優先度[（ `PRIORITY` ）](/information-schema/information-schema-resource-groups.md#examples)を設定できます。異なるリソースは`PRIORITY`設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。絶対優先度を設定しない場合、TiKV は各リソース グループの`RU_PER_SEC`の値を使用して、各リソース グループの読み取りおよび書き込み要求の優先度を決定します。storageレイヤーは、優先度に基づいて優先度キューを使用して要求をスケジュールおよび処理します。 +- TiKV スケジューリング: 必要に応じて絶対優先度[（ `PRIORITY` ）](/information-schema/information-schema-resource-groups.md#examples)を設定できます。異なるリソースは`PRIORITY`設定に従ってスケジュールされます。 `PRIORITY`が高いタスクが最初にスケジュールされます。絶対優先度を設定しない場合、TiKV は各リソース グループの`RU_PER_SEC`の値を使用して、各リソース グループの読み取りおよび書き込み要求の優先度を決定します。ストレージレイヤーは、優先度に基づいて優先度キューを使用して要求をスケジュールおよび処理します。 バージョン7.4.0以降、リソース制御機能はTiFlashリソースの制御をサポートしています。その原理は、TiDBフロー制御およびTiKVスケジューリングと同様です。 @@ -41,20 +41,20 @@ TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能と ## リソース制御のシナリオ {#scenarios-for-resource-control} -リソース制御機能の導入は、TiDBにとって画期的な出来事です。この機能により、分散データベースクラスタを複数の論理ユニットに分割できます。たとえ個々のユニットがリソースを過剰に使用したとしても、他のユニットが必要とするリソースを圧迫することはありません。 +リソース制御機能の導入は、TiDBにとって画期的な出来事です。この機能により、分散データベースクラスターを複数の論理ユニットに分割できます。たとえ個々のユニットがリソースを過剰に使用したとしても、他のユニットが必要とするリソースを圧迫することはありません。 この機能を使うと、次のことができます。 -- 異なるシステムに存在する複数の中小規模アプリケーションを単一のTiDBクラスタに統合します。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作には影響しません。システムワークロードが低い場合、負荷の高いアプリケーションは設定されたクォータを超えても必要なシステムリソースを割り当てられるため、リソースを最大限に活用できます。 -- すべてのテスト環境を単一のTiDBクラスタに統合するか、より多くのリソースを消費するバッチタスクを単一のリソースグループにまとめるかを選択できます。これにより、ハードウェア利用率を向上させ、運用コストを削減しながら、重要なアプリケーションが常に必要なリソースを確保できるようになります。 +- 異なるシステムに存在する複数の中小規模アプリケーションを単一のTiDBクラスターに統合します。アプリケーションのワークロードが増加しても、他のアプリケーションの正常な動作には影響しません。システムワークロードが低い場合、負荷の高いアプリケーションは設定されたクォータを超えても必要なシステムリソースを割り当てられるため、リソースを最大限に活用できます。 +- すべてのテスト環境を単一のTiDBクラスターに統合するか、より多くのリソースを消費するバッチタスクを単一のリソースグループにまとめるかを選択できます。これにより、ハードウェア利用率を向上させ、運用コストを削減しながら、重要なアプリケーションが常に必要なリソースを確保できるようになります。 - システム内に複数のワークロードが存在する場合、異なるワークロードを別々のリソースグループに割り当てることができます。リソース制御機能を使用することで、トランザクションアプリケーションの応答時間がデータ分析やバッチ処理アプリケーションの影響を受けないようにすることができます。 - クラスターで予期しないSQLパフォーマンスの問題が発生した場合、SQLバインディングとリソースグループを併用することで、SQLステートメントのリソース消費を一時的に制限できます。 -さらに、リソース制御機能を合理的に活用することで、クラスタ数を削減し、運用・保守の難易度を下げ、管理コストを削減することができます。 +さらに、リソース制御機能を合理的に活用することで、クラスター数を削減し、運用・保守の難易度を下げ、管理コストを削減することができます。 > **注記：** > -> - リソース管理の有効性を評価するには、クラスタを独立したコンピューティングノードとstorageノードにデプロイすることをお勧めします。 `tiup playground`で作成されたデプロイメントでは、リソースがインスタンス間で共有されるため、スケジューリングやその他のクラスタのリソースに依存する機能が正しく動作しない場合があります。 +> - リソース管理の有効性を評価するには、クラスターを独立したコンピューティングノードとストレージノードにデプロイすることをお勧めします。 `tiup playground`で作成されたデプロイメントでは、リソースがインスタンス間で共有されるため、スケジューリングやその他のクラスターのリソースに依存する機能が正しく動作しない場合があります。 ## 制限事項 {#limitations} @@ -64,12 +64,12 @@ TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能と リクエストユニット（RU）は、TiDBにおけるシステムリソースの統一抽象化単位であり、現在CPU、IOPS、およびIO帯域幅メトリックが含まれています。これは、データベースへの単一のリクエストによって消費されるリソースの量を示すために使用されます。リクエストによって消費されるRUの数は、操作の種類や、クエリまたは変更されるデータの量など、さまざまな要因によって異なります。現在、RUには次の表に示すリソースの消費統計が含まれています。 -
    リソースタイプRU消費量
    読むstorage読み取りバッチ2つで1RUを消費します
    8回のstorage読み取りリクエストで1RUを消費します
    64 KiBの読み取りリクエストペイロードは1 RUを消費します
    書くstorage書き込みバッチ1つにつき1RUを消費します
    storage書き込みリクエスト1件につき1RUを消費します。
    1 KiBの書き込みリクエストペイロードは1 RUを消費します
    CPU 3ミリ秒で1RUを消費します
    +
    リソースタイプRU消費量
    読むストレージ読み取りバッチ2つで1RUを消費します
    8回のストレージ読み取りリクエストで1RUを消費します
    64 KiBの読み取りリクエストペイロードは1 RUを消費します
    書くストレージ書き込みバッチ1つにつき1RUを消費します
    ストレージ書き込みリクエスト1件につき1RUを消費します。
    1 KiBの書き込みリクエストペイロードは1 RUを消費します
    CPU 3ミリ秒で1RUを消費します
    > **注記：** > > - 各書き込み操作は最終的にすべてのレプリカに複製されます（デフォルトでは、TiKVには3つのレプリカがあります）。各複製操作は、それぞれ異なる書き込み操作として扱われます。 -> - 上記の表には、TiDBセルフマネージドクラスタのRU計算に関わるリソースのみが記載されており、ネットワークとstorageの消費量は含まれていません。TiDB TiDB Cloud StarterのRUについては、 [TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)参照してください。 +> - 上記の表には、TiDB Self-ManagedクラスターのRU計算に関わるリソースのみが記載されており、ネットワークとストレージの消費量は含まれていません。TiDB TiDB Cloud StarterのRUについては、 [TiDB Cloud Starterの料金詳細](https://www.pingcap.com/tidb-cloud-starter-pricing-details/)参照してください。 > - 現在、 TiFlashのリソース制御では、SQL CPUのみが考慮されます。SQL CPUとは、クエリおよび読み取りリクエストのペイロードに対するパイプラインタスクの実行によって消費されるCPU時間です。 ## リソース制御のためのパラメータ {#parameters-for-resource-control} @@ -88,7 +88,7 @@ TiDBのリソース制御機能は、TiDBレイヤーのフロー制御機能と - TiKV: TiDB Self-Managed では、 `resource-control.enabled`パラメータを使用して、リソース グループのクォータに基づいてリクエスト スケジューリングを使用するかどうかを制御できます。TiDB TiDB Cloudでは、 `resource-control.enabled`パラメータのデフォルト値は`true`であり、動的な変更はサポートされていません。 -- TiFlash: TiDB セルフマネージドの場合、 `tidb_enable_resource_control`システム変数と`enable_resource_control`構成項目 (v7.4.0 で導入) を使用して、 TiFlashリソース制御を有効にするかどうかを制御できます。 +- TiFlash: TiDB Self-Managedの場合、 `tidb_enable_resource_control`システム変数と`enable_resource_control`構成項目 (v7.4.0 で導入) を使用して、 TiFlashリソース制御を有効にするかどうかを制御できます。 @@ -121,7 +121,7 @@ TiDB v7.0.0以降、 `tidb_enable_resource_control`と`resource-control.enabled` -リソース計画を行う前に、クラスタ全体の容量を把握しておく必要があります。TiDB では、クラスタ容量を推定するための[`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md)ステートメントが提供されています。以下のいずれかの方法を使用できます。 +リソース計画を行う前に、クラスター全体の容量を把握しておく必要があります。TiDB では、クラスター容量を推定するための[`CALIBRATE RESOURCE`](/sql-statements/sql-statement-calibrate-resource.md)ステートメントが提供されています。以下のいずれかの方法を使用できます。 - [実際の作業負荷に基づいて容量を推定する](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload) - [ハードウェアの導入状況に基づいて容量を推定する](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-hardware-deployment) @@ -132,7 +132,7 @@ TiDB ダッシュボードで[リソースマネージャーページ](/dashboar -TiDB Self-Managedの場合、 [`CALIBRATE RESOURCE`](https://docs.pingcap.com/tidb/stable/sql-statement-calibrate-resource)ステートメントを使用してクラスタ容量を推定できます。 +TiDB Self-Managedの場合、 [`CALIBRATE RESOURCE`](https://docs.pingcap.com/tidb/stable/sql-statement-calibrate-resource)ステートメントを使用してクラスター容量を推定できます。 TiDB Cloudの場合、 [`CALIBRATE RESOURCE`](https://docs.pingcap.com/tidb/stable/sql-statement-calibrate-resource)ステートメントは適用できません。 @@ -199,7 +199,7 @@ ALTER USER usr2 RESOURCE GROUP rg2; > **注記：** > > - `CREATE USER`または`ALTER USER`を使用してユーザーをリソース グループにバインドすると、その設定はユーザーの既存のセッションには適用されず、ユーザーの新しいセッションにのみ適用されます。 -> - TiDB はクラスタ初期化時に`default`リソース グループを自動的に作成します。このリソース グループの`RU_PER_SEC`のデフォルト値は`UNLIMITED` ( `INT`型の最大値、つまり`2147483647`に相当) で、 `BURSTABLE`モードです。リソース グループにバインドされていないステートメントは、自動的にこのリソース グループにバインドされます。このリソース グループは削除をサポートしていませんが、RU の設定を変更することはできます。 +> - TiDB はクラスター初期化時に`default`リソース グループを自動的に作成します。このリソース グループの`RU_PER_SEC`のデフォルト値は`UNLIMITED` ( `INT`型の最大値、つまり`2147483647`に相当) で、 `BURSTABLE`モードです。リソース グループにバインドされていないステートメントは、自動的にこのリソース グループにバインドされます。このリソース グループは削除をサポートしていませんが、RU の設定を変更することはできます。 リソース グループからユーザーのバインドを解除するには、次のようにしてユーザーを`default`グループに再度バインドするだけです。 @@ -257,7 +257,7 @@ SELECT /*+ RESOURCE_GROUP(rg1) */ * FROM t limit 10; SET GLOBAL tidb_enable_resource_control = 'OFF'; ``` -2. TiDB Self-Managed では、 `resource-control.enabled`パラメータを使用して、リソース グループのクォータに基づいてリクエスト スケジューリングを使用するかどうかを制御できます。TiDB TiDB Cloudでは、 `resource-control.enabled`パラメータのデフォルト値は`true`であり、動的な変更はサポートされていません。TiDB TiDB Cloud Dedicatedクラスタでこれを無効にする必要がある場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 +2. TiDB Self-Managed では、 `resource-control.enabled`パラメータを使用して、リソース グループのクォータに基づいてリクエスト スケジューリングを使用するかどうかを制御できます。TiDB TiDB Cloudでは、 `resource-control.enabled`パラメータのデフォルト値は`true`であり、動的な変更はサポートされていません。TiDB TiDB Cloud Dedicatedクラスターでこれを無効にする必要がある場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 3. TiDB Self-Managed では、 `enable_resource_control`設定項目を使用して、 TiFlashリソース制御を有効にするかどうかを制御できます。TiDB TiDB Cloudでは、 `enable_resource_control`パラメーターのデフォルト値は`true`であり、動的な変更はサポートされていません。TiDB TiDB Cloud Dedicatedクラスターでこれを無効にする必要がある場合は、 [TiDB Cloudサポート](/tidb-cloud/tidb-cloud-support.md)にお問い合わせください。 diff --git a/tidb-rowid.md b/tidb-rowid.md index b37c018861a0e..dc9ae6e2e569f 100644 --- a/tidb-rowid.md +++ b/tidb-rowid.md @@ -5,18 +5,18 @@ summary: _tidb_rowid`とは何か、いつ利用できるのか、そして安 # _tidb_rowid {#code-tidb-rowid-code} -`_tidb_rowid`はTiDBによって自動的に生成される非表示のシステム列です。クラスタ化インデックスを使用しないテーブルの場合、この列はテーブルの内部行IDとして機能します。テーブルスキーマでこの列を宣言または変更することはできませんが、テーブルが内部行IDとして`_tidb_rowid`使用している場合は、SQLで参照できます。 +`_tidb_rowid`はTiDBによって自動的に生成される非表示のシステム列です。クラスター化インデックスを使用しないテーブルの場合、この列はテーブルの内部行IDとして機能します。テーブルスキーマでこの列を宣言または変更することはできませんが、テーブルが内部行IDとして`_tidb_rowid`使用している場合は、SQLで参照できます。 現在の実装では、 `_tidb_rowid`はTiDBによって自動的に管理される追加の`BIGINT NOT NULL`列です。 > **警告：** > -> - `_tidb_rowid`常にグローバルに一意であるとは限らないことに注意してください。クラスタ化インデックスを使用しないパーティションテーブルの場合、 `ALTER TABLE ... EXCHANGE PARTITION`実行すると、異なるパーティション間で`_tidb_rowid`値が重複する可能性があります。 +> - `_tidb_rowid`常にグローバルに一意であるとは限らないことに注意してください。クラスター化インデックスを使用しないパーティションテーブルの場合、 `ALTER TABLE ... EXCHANGE PARTITION`実行すると、異なるパーティション間で`_tidb_rowid`値が重複する可能性があります。 > - 安定した一意の識別子が必要な場合は、 `_tidb_rowid`に依存するのではなく、明示的な主キーを定義して使用してください。 ## _tidb_rowidが利用可能な場合 {#when-code-tidb-rowid-code-is-available} -TiDBでは、テーブルが一意の行識別子としてクラスタ化された主キーを使用しない場合、各行を識別するために`_tidb_rowid`使用します。実際には、これは次のタイプのテーブルが`_tidb_rowid`使用することを意味します。 +TiDBでは、テーブルが一意の行識別子としてクラスター化された主キーを使用しない場合、各行を識別するために`_tidb_rowid`使用します。実際には、これは次のタイプのテーブルが`_tidb_rowid`使用することを意味します。 - 主キーのないテーブル - 主キーが明示的に`NONCLUSTERED`と定義されているテーブル @@ -31,14 +31,14 @@ CREATE TABLE t2 (id BIGINT PRIMARY KEY NONCLUSTERED, a INT); CREATE TABLE t3 (id BIGINT PRIMARY KEY CLUSTERED, a INT); ``` -`t1`と`t2`については、これらのテーブルは行識別子としてクラスタ化インデックスを使用していないため、 `_tidb_rowid`に対してクエリを実行できます。 +`t1`と`t2`については、これらのテーブルは行識別子としてクラスター化インデックスを使用していないため、 `_tidb_rowid`に対してクエリを実行できます。 ```sql SELECT _tidb_rowid, a, b FROM t1; SELECT _tidb_rowid, id, a FROM t2; ``` -`t3`の場合、クラスタ化された主キーが既に行識別子になっているため、 `_tidb_rowid`利用できません。 +`t3`の場合、クラスター化された主キーが既に行識別子になっているため、 `_tidb_rowid`利用できません。 ```sql SELECT _tidb_rowid, id, a FROM t3; @@ -123,8 +123,8 @@ SELECT _tidb_rowid, a, b FROM t WHERE _tidb_rowid = 100; - `_tidb_rowid`という名前のユーザー列を作成することはできません。 - 既存のユーザー列の名前を`_tidb_rowid`に変更することはできません。 - `_tidb_rowid`はTiDBの内部列です。ビジネス上の主キーや長期的な識別子として扱わないでください。 -- パーティション化された非クラスタ化テーブルでは、 `_tidb_rowid`値はパーティション間で一意であることが保証されません。3 `EXCHANGE PARTITION`実行した後、異なるパーティションに同じ`_tidb_rowid`値を持つ行が含まれる可能性があります。 -- `_tidb_rowid`存在するかどうかは、テーブルのスキーマによって異なります。クラスタ化インデックスを持つテーブルの場合は、行識別子として主キーを使用してください。 +- パーティション化された非クラスター化テーブルでは、 `_tidb_rowid`値はパーティション間で一意であることが保証されません。3 `EXCHANGE PARTITION`実行した後、異なるパーティションに同じ`_tidb_rowid`値を持つ行が含まれる可能性があります。 +- `_tidb_rowid`存在するかどうかは、テーブルのスキーマによって異なります。クラスター化インデックスを持つテーブルの場合は、行識別子として主キーを使用してください。 ## ホットスポットの問題に対処する {#address-hotspot-issues} diff --git a/tidb-scheduling.md b/tidb-scheduling.md index 16347f8920788..24a874426b0d6 100644 --- a/tidb-scheduling.md +++ b/tidb-scheduling.md @@ -5,15 +5,15 @@ summary: TiDB クラスターに PD スケジューリングコンポーネン # TiDB スケジューリング {#tidb-scheduling} -配置Driver（ [PD](https://github.com/tikv/pd) ）はTiDBクラスタのマネージャとして機能し、クラスタ内のリージョンのスケジュールも行います。この記事では、PDスケジューリングコンポーネントの設計とコアコンセプトを紹介します。 +配置Driver（ [PD](https://github.com/tikv/pd) ）はTiDBクラスターのマネージャとして機能し、クラスター内のリージョンのスケジュールも行います。この記事では、PDスケジューリングコンポーネントの設計とコアコンセプトを紹介します。 ## スケジュール状況 {#scheduling-situations} -TiKVは、TiDBが使用する分散キーバリューstorageエンジンです。TiKVでは、データはリージョンとして編成され、複数のストアに複製されます。すべてのレプリカにおいて、リーダーが読み取りと書き込みを担当し、フォロワーはリーダーからのRaftログの複製を担当します。 +TiKVは、TiDBが使用する分散キーバリューストレージエンジンです。TiKVでは、データはリージョンとして編成され、複数のストアに複製されます。すべてのレプリカにおいて、リーダーが読み取りと書き込みを担当し、フォロワーはリーダーからのRaftログの複製を担当します。 ここで、次のような状況について考えてみましょう。 -- storageスペースを効率的に利用するには、同じリージョンの複数のレプリカを、リージョンのサイズに応じて異なるノードに適切に分散する必要があります。 +- ストレージスペースを効率的に利用するには、同じリージョンの複数のレプリカを、リージョンのサイズに応じて異なるノードに適切に分散する必要があります。 - 複数のデータセンター トポロジの場合、1 つのデータセンターに障害が発生すると、すべてのリージョンの 1 つのレプリカのみが失敗します。 - 新しい TiKV ストアが追加されると、そのストアにデータを再バランスさせることができます。 - TiKV ストアに障害が発生した場合、PD は次のことを考慮する必要があります。 @@ -27,13 +27,13 @@ TiKVは、TiDBが使用する分散キーバリューstorageエンジンです - すべてのリージョンがホットなわけではないので、すべての TiKV ストアの負荷をバランスさせる必要があります。 - リージョンのバランスが取れている場合、データ転送に多くのネットワーク/ディスク トラフィックと CPU 時間が必要となり、オンライン サービスに影響する可能性があります。 -これらの状況は同時に発生する可能性があり、解決が困難になります。また、システム全体が動的に変化するため、クラスタに関するすべての情報を収集し、クラスタを調整するスケジューラが必要です。そこで、TiDBクラスタにPDが導入されました。 +これらの状況は同時に発生する可能性があり、解決が困難になります。また、システム全体が動的に変化するため、クラスターに関するすべての情報を収集し、クラスターを調整するスケジューラが必要です。そこで、TiDBクラスターにPDが導入されました。 ## スケジュール要件 {#scheduling-requirements} 上記の状況は、次の 2 つのタイプに分類できます。 -1. 分散型で可用性の高いstorageシステムは、次の要件を満たす必要があります。 +1. 分散型で可用性の高いストレージシステムは、次の要件を満たす必要があります。 - 適切な数のレプリカ。 - レプリカは、さまざまなトポロジに応じて異なるマシンに分散する必要があります。 @@ -138,7 +138,7 @@ PD は、ストア ハートビートとリージョンハートビートから **戦略6: 保管サイズは店舗間でバランスをとる必要がある** -起動時に、TiKV ストアはstorageの`capacity`報告します。これは、ストアのスペース制限を示します。PD は、スケジュール設定時にこれを考慮します。 +起動時に、TiKV ストアはストレージの`capacity`報告します。これは、ストアのスペース制限を示します。PD は、スケジュール設定時にこれを考慮します。 **戦略7: スケジュール速度を調整してオンラインサービスを安定させる** @@ -146,6 +146,6 @@ PD は、ストア ハートビートとリージョンハートビートから ## スケジュールの実装 {#scheduling-implementation} -PDはストアハートビートとリージョンハートビートからクラスタ情報を収集し、それらの情報と戦略に基づいてスケジューリングプランを作成します。スケジューリングプランは、一連の基本オペレータから構成されます。PDはリージョンリーダーからリージョンハートビートを受信するたびに、そのリージョンに保留中のオペレータが存在するかどうかを確認します。PDがリージョンに新しいオペレータをディスパッチする必要がある場合、そのオペレータをハートビート応答に割り当て、後続のリージョンハートビートをチェックすることでオペレータを監視します。 +PDはストアハートビートとリージョンハートビートからクラスター情報を収集し、それらの情報と戦略に基づいてスケジューリングプランを作成します。スケジューリングプランは、一連の基本オペレータから構成されます。PDはリージョンリーダーからリージョンハートビートを受信するたびに、そのリージョンに保留中のオペレータが存在するかどうかを確認します。PDがリージョンに新しいオペレータをディスパッチする必要がある場合、そのオペレータをハートビート応答に割り当て、後続のリージョンハートビートをチェックすることでオペレータを監視します。 ここでの「オペレータ」は、リージョンリーダーへの提案に過ぎず、リージョンによってスキップされる可能性があることに注意してください。リージョンLeaderは、スケジューリングオペレータの現在のステータスに基づいて、そのオペレータをスキップするかどうかを決定できます。 diff --git a/tidb-storage.md b/tidb-storage.md index 52473bf5835ae..adbed1683281f 100644 --- a/tidb-storage.md +++ b/tidb-storage.md @@ -1,28 +1,28 @@ --- title: TiDB Storage -summary: TiDB データベースのstorageレイヤーを理解します。 +summary: TiDB データベースのストレージレイヤーを理解します。 --- -# TiDBストレージ {#tidb-storage} +# TiDBストレージ {#tidb-ストレージ} このドキュメントでは、 [TiKV](https://github.com/tikv/tikv)の設計アイデアと主要な概念をいくつか紹介します。 -![storage-architecture](/media/tidb-storage-architecture-1.png) +![ストレージ-architecture](/media/tidb-ストレージ-architecture-1.png) ## キーと値のペア {#key-value-pairs} -データstorageシステムで最初に決定すべきことは、データstorageモデル、つまりデータをどのような形式で保存するかです。TiKVはキーバリューモデルを採用しており、順序付けされたトラバーサル手法を提供します。TiKVデータstorageモデルには、以下の2つの重要なポイントがあります。 +データストレージシステムで最初に決定すべきことは、データストレージモデル、つまりデータをどのような形式で保存するかです。TiKVはキーバリューモデルを採用しており、順序付けされたトラバーサル手法を提供します。TiKVデータストレージモデルには、以下の2つの重要なポイントがあります。 - これは、キーと値のペアを格納する巨大なマップ (C++ の`std::Map`に似ています) です。 - マップ内のキーと値のペアは、キーのバイナリ順序に従って順序付けられます。つまり、特定のキーの位置を Seek し、次に Next メソッドを呼び出して、このキーよりも大きいキーと値のペアを増分順に取得できます。 -なお、本ドキュメントで説明するTiKVのKVstorageモデルは、SQLテーブルとは一切関係ありません。本ドキュメントではSQL関連の概念については説明せず、TiKVのような高性能で信頼性の高い分散型キーバリューstorageの実装方法のみに焦点を当てています。 +なお、本ドキュメントで説明するTiKVのKVストレージモデルは、SQLテーブルとは一切関係ありません。本ドキュメントではSQL関連の概念については説明せず、TiKVのような高性能で信頼性の高い分散型キーバリューストレージの実装方法のみに焦点を当てています。 -## ローカルstorage（RocksDB） {#local-storage-rocksdb} +## ローカルストレージ（RocksDB） {#local-ストレージ-rocksdb} -あらゆる永続storageエンジンでは、データは最終的にディスクに保存されます。TiKVも例外ではありません。TiKVはデータをディスクに直接書き込むのではなく、データstorageを担うRocksDBにデータを保存します。その理由は、スタンドアロンstorageエンジン、特に綿密な最適化を必要とする高性能スタンドアロンエンジンの開発には多大なコストがかかるためです。 +あらゆる永続ストレージエンジンでは、データは最終的にディスクに保存されます。TiKVも例外ではありません。TiKVはデータをディスクに直接書き込むのではなく、データストレージを担うRocksDBにデータを保存します。その理由は、スタンドアロンストレージエンジン、特に綿密な最適化を必要とする高性能スタンドアロンエンジンの開発には多大なコストがかかるためです。 -RocksDBは、Facebookがオープンソース化した優れたスタンドアロンstorageエンジンです。このエンジンは、単一のエンジンでTiKVの様々な要件を満たすことができます。ここでは、RocksDBを単一の永続的なキーバリューマップと見なすことができます。 +RocksDBは、Facebookがオープンソース化した優れたスタンドアロンストレージエンジンです。このエンジンは、単一のエンジンでTiKVの様々な要件を満たすことができます。ここでは、RocksDBを単一の永続的なキーバリューマップと見なすことができます。 ## Raftプロトコル {#raft-protocol} @@ -38,20 +38,20 @@ Raftはコンセンサスアルゴリズムです。このドキュメントで TiKVはRaftを使用してデータレプリケーションを実行します。各データ変更はRaftログとして記録されます。Raftログレプリケーションにより、データはRaftグループ内の複数のノードに安全かつ確実に複製されます。ただし、 Raftプロトコルでは、書き込みが成功するには、データが過半数のノードに複製されている必要があります。 -![Raft in TiDB](/media/tidb-storage-1.png) +![Raft in TiDB](/media/tidb-ストレージ-1.png) -要約すると、TiKVはスタンドアロンマシンRocksDBを介してデータをディスクに迅速に保存し、マシン障害時にはRaftを介して複数のマシンにデータを複製できます。データはRocksDBではなくRaftインターフェースを介して書き込まれます。Raftの実装により、TiKVは分散型キーバリューstorageになります。たとえ少数のマシン障害が発生しても、TiKVはネイティブRaftプロトコルによって自動的に複製を完了できるため、アプリケーションには影響しません。 +要約すると、TiKVはスタンドアロンマシンRocksDBを介してデータをディスクに迅速に保存し、マシン障害時にはRaftを介して複数のマシンにデータを複製できます。データはRocksDBではなくRaftインターフェースを介して書き込まれます。Raftの実装により、TiKVは分散型キーバリューストレージになります。たとえ少数のマシン障害が発生しても、TiKVはネイティブRaftプロトコルによって自動的に複製を完了できるため、アプリケーションには影響しません。 ## リージョン {#region} 理解を容易にするために、すべてのデータにレプリカが1つしかないと仮定しましょう。前述のように、TiKVは大規模で整然としたKVマップと見なすことができ、水平方向のスケーラビリティを実現するために、データは複数のマシンに分散されます。KVシステムでは、複数のマシンにデータを分散させる一般的なソリューションが2つあります。 -- ハッシュ: キーによってハッシュを作成し、ハッシュ値に応じて対応するstorageノードを選択します。 +- ハッシュ: キーによってハッシュを作成し、ハッシュ値に応じて対応するストレージノードを選択します。 - 範囲: 範囲をキーで分割します。シリアル キーのセグメントがノードに保存されます。 TiKVは、キーと値の空間全体を連続するキーセグメントに分割する2番目のソリューションを選択します。各セグメントはリージョンと呼ばれます。各リージョンは、左閉区間と右開区間の`[StartKey, EndKey)`で表されます。各リージョンのデフォルトのサイズ制限は256MiBですが、サイズは設定可能です。 -![Region in TiDB](/media/tidb-storage-2.png) +![Region in TiDB](/media/tidb-ストレージ-2.png) ここでのリージョンはSQLのテーブルとは何の関係もありません。このドキュメントでは、SQLについては一旦忘れてKVに焦点を当てます。データをリージョンに分割した後、TiKVは次の2つの重要なタスクを実行します。 @@ -60,7 +60,7 @@ TiKVは、キーと値の空間全体を連続するキーセグメントに分 これら 2 つのタスクは非常に重要なので、1 つずつ紹介します。 -- まず、データはキーに基づいて複数のリージョンに分割され、各リージョンのデータは1つのノードにのみ保存されます（複数のレプリカは無視されます）。TiDBシステムには、クラスター内のすべてのノードにリージョンを可能な限り均等に分散させるPDコンポーネントがあります。これにより、storage容量が水平方向に拡張され（他のノードのリージョンは新しく追加されたノードに自動的にスケジュールされます）、負荷分散が実現されます（あるノードに大量のデータがある一方で、他のノードにはほとんどデータがないという状況は発生しません）。 +- まず、データはキーに基づいて複数のリージョンに分割され、各リージョンのデータは1つのノードにのみ保存されます（複数のレプリカは無視されます）。TiDBシステムには、クラスター内のすべてのノードにリージョンを可能な限り均等に分散させるPDコンポーネントがあります。これにより、ストレージ容量が水平方向に拡張され（他のノードのリージョンは新しく追加されたノードに自動的にスケジュールされます）、負荷分散が実現されます（あるノードに大量のデータがある一方で、他のノードにはほとんどデータがないという状況は発生しません）。 同時に、上位クライアントが必要なデータにアクセスできるようにするため、システムにはノード上の領域の分布、つまりキーの正確なリージョンと任意のキーを通じて配置されたそのリージョンのノードを記録するコンポーネント(PD) があります。 @@ -68,7 +68,7 @@ TiKVは、キーと値の空間全体を連続するキーセグメントに分 レプリカの1つはグループのLeaderとして機能し、もう1つはFollowerとして機能します。デフォルトでは、すべての読み取りと書き込みはLeaderを介して処理され、リーダーで読み取りが行われ、書き込みはフォロワーに複製されます。次の図は、リージョンとRaftグループの全体像を示しています。 -![TiDB Storage](/media/tidb-storage-3.png) +![TiDB Storage](/media/tidb-ストレージ-3.png) リージョン間でデータを分散・複製することで、分散型キーバリューシステムを構築し、ある程度の災害復旧能力を備えています。容量不足やディスク障害、データ損失を心配する必要はもうありません。 @@ -102,4 +102,4 @@ MVCC では、TiKV のキーと値のペアは次のようになります。 ## 分散ACIDトランザクション {#distributed-acid-transaction} -TiKVのトランザクションは、GoogleがBigTableで使用しているモデルを採用しています: [パーコレーター](https://research.google/pubs/large-scale-incremental-processing-using-distributed-transactions-and-notifications/) 。TiKVの実装はこの論文に着想を得ており、多くの最適化が行われています。詳細は[取引の概要](/transaction-overview.md)ご覧ください。 +TiKVのトランザクションは、GoogleがBigTableで使用しているモデルを採用しています: [パーコレーター](https://research.google/pubs/large-scale-incremental-processing-using-distributed-transactions-and-notifications/) 。TiKVの実装はこの論文に着想を得ており、多くの最適化が行われています。詳細は[トランザクションの概要](/transaction-overview.md)ご覧ください。 diff --git a/tidb-troubleshooting-map.md b/tidb-troubleshooting-map.md index e8917fef20ef9..9b88be8a2fcf4 100644 --- a/tidb-troubleshooting-map.md +++ b/tidb-troubleshooting-map.md @@ -77,7 +77,7 @@ summary: TiDBでよく発生するエラーのトラブルシューティング - DDL所有者の移行: - TiDBサーバーに接続できる場合は、所有者選出コマンドを再度実行してください： `curl -X POST http://{TiDBIP}:10080/ddl/owner/resign` - - TiDBサーバーに接続できない場合は、 `tidb-ctl`を使用してPDクラスタのetcdからDDLオーナーを削除し、再選出をトリガーしてください： `tidb-ctl etcd delowner [LeaseID] [flags] + ownerKey` + - TiDBサーバーに接続できない場合は、 `tidb-ctl`を使用してPDクラスターのetcdからDDLオーナーを削除し、再選出をトリガーしてください： `tidb-ctl etcd delowner [LeaseID] [flags] + ownerKey` - 3.1.3 TiDB のログに`information schema is changed`エラーが報告される @@ -189,7 +189,7 @@ OOM のトラブルシューティングの詳細については、 [TiDBのメ ### 3.6 ホットスポットの問題 {#3-6-hotspot-issues} -分散データベースであるTiDBは、サーバーリソースをより有効活用するために、アプリケーションの負荷をさまざまなコンピューティングノードやstorageノードに均等に分散させるロードバランシングメカニズムを備えています。しかし、特定のシナリオでは、アプリケーションの負荷が適切に分散されない場合があり、パフォーマンスに影響を与え、ホットスポットと呼ばれる高負荷の一点が発生する可能性があります。 +分散データベースであるTiDBは、サーバーリソースをより有効活用するために、アプリケーションの負荷をさまざまなコンピューティングノードやストレージノードに均等に分散させるロードバランシングメカニズムを備えています。しかし、特定のシナリオでは、アプリケーションの負荷が適切に分散されない場合があり、パフォーマンスに影響を与え、ホットスポットと呼ばれる高負荷の一点が発生する可能性があります。 TiDB は、ホットスポットのトラブルシューティング、解決、回避のための完全なソリューションを提供します。負荷ホットスポットのバランスをとることで、QPS の向上やレイテンシーの削減など、全体的なパフォーマンスを向上させることができます。詳細な解決策については、[ホットスポットの問題をトラブルシューティングする](/troubleshoot-hot-spot-issues.md)参照してください。 @@ -211,7 +211,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND ### 4.1 TiKVがパニックを起こして起動に失敗する {#4-1-tikv-panics-and-fails-to-start} -- 4.1.1 TiKVが仮想マシンにデプロイされている場合、仮想マシンが強制終了されたり、物理マシンが電源オフになったりすると、 `entries[X, Y] is unavailable from storage`エラーが報告されます。 +- 4.1.1 TiKVが仮想マシンにデプロイされている場合、仮想マシンが強制終了されたり、物理マシンが電源オフになったりすると、 `entries[X, Y] is unavailable from ストレージ`エラーが報告されます。 この問題は想定内のものです。仮想マシンの`fsync`は信頼性が低いため、 `tikv-ctl`を使用してリージョンを復元する必要があります。 @@ -223,7 +223,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND 問題の原因を確認するには、モニター**Grafana** -> **TiKV-details**で該当するインスタンスを選択して RocksDB の`block cache size`を確認してください。 - 一方、 `[storage.block-cache] capacity = # "1GB"`パラメータが正しく設定されているか確認してください。デフォルトでは、TiKV の`block-cache`はマシンの総メモリの`45%`に設定されています。TiKV は物理マシンのメモリを取得するため、コンテナのメモリ制限を超える可能性があるため、コンテナに TiKV をデプロイする際にはこのパラメータを明示的に指定する必要があります。 + 一方、 `[ストレージ.block-cache] capacity = # "1GB"`パラメータが正しく設定されているか確認してください。デフォルトでは、TiKV の`block-cache`はマシンの総メモリの`45%`に設定されています。TiKV は物理マシンのメモリを取得するため、コンテナのメモリ制限を超える可能性があるため、コンテナに TiKV をデプロイする際にはこのパラメータを明示的に指定する必要があります。 - 4.2.2コプロセッサーが多数の大きなクエリを受信し、大量のデータを返します。gRPC は、コプロセッサがデータを返す速度に追いつかず、結果としてメモリ不足エラーが発生します。 @@ -239,13 +239,13 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 4.3.1 TiKV RocksDB は`write stall`を検出します。 - TiKV インスタンスには 2 つの RocksDB インスタンスがあり、1 つは`data/raft`にありRaftログを格納し、もう 1 つは`data/db`にあり実際のデータを格納します。ログで`grep "Stalling" RocksDB`を実行すると、停止の具体的な原因を確認できます。RocksDB ログは`LOG`で始まるファイルで、 `LOG`が現在のログです。 `write stall`は RocksDB にネイティブに組み込まれたパフォーマンス低下メカニズムです。RocksDB で`write stall`が発生すると、システムのパフォーマンスが大幅に低下します。バージョン 5.2.0 より前のバージョンでは、TiDB は`ServerIsBusy`に遭遇すると、 `write stall`エラーをクライアントに直接返すことで、すべての書き込み要求をブロックしようとしますが、これにより QPS パフォーマンスが急激に低下する可能性があります。バージョン 5.2.0 以降、TiKV は、スケジューリングレイヤーで書き込み要求を動的に遅延させることで書き込みを抑制する新しいフロー制御メカニズムを導入し、 `server is busy`が発生したときにクライアントに`write stall`を返す以前のメカニズムに取って代わります。新しいフロー制御メカニズムはデフォルトで有効になっており、TiKV は`write stall`および`KvDB` (memtable を除く) の`RaftDB`メカニズムを自動的に無効にします。ただし、保留中のリクエスト数が一定のしきい値を超えると、フロー制御メカニズムは引き続き有効になり、一部またはすべての書き込みリクエストを拒否し、 `server is busy`エラーをクライアントに返します。詳細な説明としきい値については、 [フロー制御構成](/tikv-configuration-file.md#storageflow-control)を参照してください。 + TiKV インスタンスには 2 つの RocksDB インスタンスがあり、1 つは`data/raft`にありRaftログを格納し、もう 1 つは`data/db`にあり実際のデータを格納します。ログで`grep "Stalling" RocksDB`を実行すると、停止の具体的な原因を確認できます。RocksDB ログは`LOG`で始まるファイルで、 `LOG`が現在のログです。 `write stall`は RocksDB にネイティブに組み込まれたパフォーマンス低下メカニズムです。RocksDB で`write stall`が発生すると、システムのパフォーマンスが大幅に低下します。バージョン 5.2.0 より前のバージョンでは、TiDB は`ServerIsBusy`に遭遇すると、 `write stall`エラーをクライアントに直接返すことで、すべての書き込み要求をブロックしようとしますが、これにより QPS パフォーマンスが急激に低下する可能性があります。バージョン 5.2.0 以降、TiKV は、スケジューリングレイヤーで書き込み要求を動的に遅延させることで書き込みを抑制する新しいフロー制御メカニズムを導入し、 `server is busy`が発生したときにクライアントに`write stall`を返す以前のメカニズムに取って代わります。新しいフロー制御メカニズムはデフォルトで有効になっており、TiKV は`write stall`および`KvDB` (memtable を除く) の`RaftDB`メカニズムを自動的に無効にします。ただし、保留中のリクエスト数が一定のしきい値を超えると、フロー制御メカニズムは引き続き有効になり、一部またはすべての書き込みリクエストを拒否し、 `server is busy`エラーをクライアントに返します。詳細な説明としきい値については、 [フロー制御構成](/tikv-configuration-file.md#ストレージflow-control)を参照してください。 - `server is busy`エラーが、保留中の圧縮バイト数が多すぎるために発生する場合は、 [`soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)および[`hard-pending-compaction-bytes-limit`](/tikv-configuration-file.md#hard-pending-compaction-bytes-limit)パラメータの値を増やすことで、この問題を軽減できます。 - - 保留中の圧縮バイト数が`soft-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`192GiB` ) に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し始めます ( `ServerIsBusy`をクライアントに返します)。この場合、このパラメータの値を増やすことができます。たとえば、 `[storage.flow-control] soft-pending-compaction-bytes-limit = "384GiB"`のようにです。 + - 保留中の圧縮バイト数が`soft-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`192GiB` ) に達すると、フロー制御メカニズムは一部の書き込み要求を拒否し始めます ( `ServerIsBusy`をクライアントに返します)。この場合、このパラメータの値を増やすことができます。たとえば、 `[ストレージ.flow-control] soft-pending-compaction-bytes-limit = "384GiB"`のようにです。 - - 保留中の圧縮バイト数が`hard-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`1024GiB` ) に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し始めます ( `ServerIsBusy`をクライアントに返します)。フロー制御メカニズムは`soft-pending-compaction-bytes-limit`のしきい値に達した後に書き込み速度を遅くするため、このシナリオが発生する可能性は低くなります。発生した場合は、このパラメータの値を増やすことができます (たとえば`[storage.flow-control] hard-pending-compaction-bytes-limit = "2048GiB"`など)。 + - 保留中の圧縮バイト数が`hard-pending-compaction-bytes-limit`パラメータの値 (デフォルトでは`1024GiB` ) に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し始めます ( `ServerIsBusy`をクライアントに返します)。フロー制御メカニズムは`soft-pending-compaction-bytes-limit`のしきい値に達した後に書き込み速度を遅くするため、このシナリオが発生する可能性は低くなります。発生した場合は、このパラメータの値を増やすことができます (たとえば`[ストレージ.flow-control] hard-pending-compaction-bytes-limit = "2048GiB"`など)。 - ディスクのI/O容量が長時間にわたって書き込み速度に追いつかない場合は、ディスクの容量を増やすことをお勧めします。ディスクのスループットが上限に達し、書き込みが停止する場合（例えば、SATA SSDはNVMe SSDよりも大幅に低い）、CPUリソースが十分であれば、より高い圧縮率の圧縮アルゴリズムを適用することができます。こうすることで、CPUリソースをディスクリソースに振り向け、ディスクへの負荷を軽減できます。 @@ -257,9 +257,9 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 4.3.2 `scheduler too busy` - - 深刻な書き込み競合が発生しています。 `latch wait duration`値が高くなります。モニター**Grafana** -> **TiKV-details** -> **scheduler prewrite** / **scheduler commit**で`latch wait duration`を確認できます。スケジューラで書き込みタスクが蓄積されると、保留中の書き込みタスクが`[storage] scheduler-pending-write-threshold` (100MB) で設定されたしきい値を超えます。 `MVCC_CONFLICT_COUNTER`に対応するメトリックを確認することで、原因を検証できます。 + - 深刻な書き込み競合が発生しています。 `latch wait duration`値が高くなります。モニター**Grafana** -> **TiKV-details** -> **scheduler prewrite** / **scheduler commit**で`latch wait duration`を確認できます。スケジューラで書き込みタスクが蓄積されると、保留中の書き込みタスクが`[ストレージ] scheduler-pending-write-threshold` (100MB) で設定されたしきい値を超えます。 `MVCC_CONFLICT_COUNTER`に対応するメトリックを確認することで、原因を検証できます。 - - 書き込み速度が遅いと、書き込みタスクが蓄積されます。TiKV に書き込まれるデータが`[storage] scheduler-pending-write-threshold` (100MB) で設定されたしきい値を超えています[4.5](#45-tikv-write-is-slow)を参照してください。 + - 書き込み速度が遅いと、書き込みタスクが蓄積されます。TiKV に書き込まれるデータが`[ストレージ] scheduler-pending-write-threshold` (100MB) で設定されたしきい値を超えています[4.5](#45-tikv-write-is-slow)を参照してください。 - 4.3.3 `raftstore is busy` 。メッセージの処理がメッセージの受信よりも遅くなっています。短期間の`channel full`状態はサービスに影響しませんが、エラーが長時間続くとLeaderの切り替えが発生する可能性があります。 @@ -291,7 +291,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 4.5.2 スケジューラのCPUがビジー状態です（トランザクションkvのみ）。 - prewrite/commit の`scheduler command duration`が`scheduler latch wait duration`と`storage async write duration`の合計よりも長くなっています。スケジューラワーカーの CPU 要求が高く、例えば`scheduler-worker-pool-size` * 100% の 80% を超えているか、マシン全体の CPU リソースが比較的限られています。書き込みワークロードが大きい場合は、 `[storage] scheduler-worker-pool-size`の設定が小さすぎないか確認してください。 + prewrite/commit の`scheduler command duration`が`scheduler latch wait duration`と`ストレージ async write duration`の合計よりも長くなっています。スケジューラワーカーの CPU 要求が高く、例えば`scheduler-worker-pool-size` * 100% の 80% を超えているか、マシン全体の CPU リソースが比較的限られています。書き込みワークロードが大きい場合は、 `[ストレージ] scheduler-worker-pool-size`の設定が小さすぎないか確認してください。 その他の状況については、 [バグを報告する](https://github.com/tikv/tikv/issues/new?template=bug-report.md)。 @@ -362,7 +362,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - PD はLeaderを選出できません: PD ログには`lease is not expired`が表示されます。 [この問題は](https://github.com/etcd-io/etcd/issues/10355)v3.0.x および v2.1.19 で修正されました。中国語の[ケース875](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case875.md)参照してください。 - - 選挙が遅い：リージョンの読み込み時間が長い。この問題は、PD ログで`grep "regions cost"`実行することで確認できます。結果が`load 460927 regions cost 11.77099s`のように秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0 では、 `region storage`を`use-region-storage`に設定することで`true`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。詳細は、 [ケース429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md) （中国語）を参照してください。 + - 選挙が遅い：リージョンの読み込み時間が長い。この問題は、PD ログで`grep "regions cost"`実行することで確認できます。結果が`load 460927 regions cost 11.77099s`のように秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0 では、 `region ストレージ`を`use-region-ストレージ`に設定することで`true`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。詳細は、 [ケース429](https://github.com/pingcap/tidb-map/blob/master/maps/diagnose-case-study/case429.md) （中国語）を参照してください。 - 5.2.3 TiDBがSQLステートメントを実行する際にPDがタイムアウトしました。 @@ -444,7 +444,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND ### 6.2 TiDB Lightning {#6-2-tidb-lightning} -- 6.2.1 TiDB Lightningは、大量のデータを TiDB クラスタに高速に完全インポートするためのツールです。TiDB [TiDB Lightning （GitHub）](https://github.com/pingcap/tidb/tree/release-8.5/lightning)を参照してください。 +- 6.2.1 TiDB Lightningは、大量のデータを TiDB クラスターに高速に完全インポートするためのツールです。TiDB [TiDB Lightning （GitHub）](https://github.com/pingcap/tidb/tree/release-8.5/lightning)を参照してください。 - 6.2.2 インポート速度が遅すぎる。 @@ -462,7 +462,7 @@ TiDB は、トランザクションの実行時または[`ADMIN CHECK [TABLE|IND - 原因１：テーブルに既にデータが存在する可能性があります。これらの古いデータは最終的なチェックサムに影響を与える可能性があります。 - - 原因2：ターゲットデータベースのチェックサムが0（つまり何もインポートされていない）の場合、クラスタが過熱していてデータの取り込みに失敗している可能性があります。 + - 原因2：ターゲットデータベースのチェックサムが0（つまり何もインポートされていない）の場合、クラスターが過熱していてデータの取り込みに失敗している可能性があります。 - 原因3：データソースがマシンによって生成され、 [Dumpling](/dumpling-overview.md)によってバックアップされていない場合は、テーブルの制約を遵守していることを確認してください。例： diff --git a/tidb-upgrade-migration-guide.md b/tidb-upgrade-migration-guide.md index 5b786d7fb4814..c40b95e68f88b 100644 --- a/tidb-upgrade-migration-guide.md +++ b/tidb-upgrade-migration-guide.md @@ -3,9 +3,9 @@ title: Migrate and Upgrade a TiDB Cluster summary: 完全バックアップと復元のためのBRと、増分データレプリケーションのための TiCDC を使用して、TiDB クラスターを移行およびアップグレードする方法を学習します。 --- -# TiDBクラスタの移行とアップグレード {#migrate-and-upgrade-a-tidb-cluster} +# TiDBクラスターの移行とアップグレード {#migrate-and-upgrade-a-tidb-cluster} -このドキュメントでは、 [BR](/br/backup-and-restore-overview.md)で完全バックアップとリストアを行い、 [TiCDC](/ticdc/ticdc-overview.md)で増分データレプリケーションを行う TiDB クラスタの移行とアップグレード（ブルーグリーンアップグレードとも呼ばれます）方法について説明します。このソリューションは、デュアルクラスタ冗長性と増分レプリケーションを使用することで、スムーズなトラフィック切り替えと高速ロールバックを実現し、重要なシステムに信頼性が高くリスクの低いアップグレードパスを提供します。パフォーマンスの向上と新機能のメリットを継続的に享受し、安全で効率的なデータベースシステムを維持するために、データベースバージョンを定期的にアップグレードすることをお勧めします。このソリューションの主な利点は次のとおりです。 +このドキュメントでは、 [BR](/br/backup-and-restore-overview.md)で完全バックアップとリストアを行い、 [TiCDC](/ticdc/ticdc-overview.md)で増分データレプリケーションを行う TiDB クラスターの移行とアップグレード（ブルーグリーンアップグレードとも呼ばれます）方法について説明します。このソリューションは、デュアルクラスター冗長性と増分レプリケーションを使用することで、スムーズなトラフィック切り替えと高速ロールバックを実現し、重要なシステムに信頼性が高くリスクの低いアップグレードパスを提供します。パフォーマンスの向上と新機能のメリットを継続的に享受し、安全で効率的なデータベースシステムを維持するために、データベースバージョンを定期的にアップグレードすることをお勧めします。このソリューションの主な利点は次のとおりです。 - **制御可能なリスク**: 数分以内に元のクラスターへのロールバックをサポートし、ビジネスの継続性を確保します。 - **データ整合性**: 多段階の検証メカニズムを使用してデータ損失を防ぎます。 @@ -21,7 +21,7 @@ summary: 完全バックアップと復元のためのBRと、増分データレ **ロールバック プラン**: 移行およびアップグレード プロセス中に新しいクラスターで問題が発生した場合、いつでもビジネス トラフィックを元のクラスターに戻すことができます。 -以下のセクションでは、TiDB クラスターの移行とアップグレードに関する標準化されたプロセスと一般的な手順について説明します。コマンド例は、TiDB セルフマネージド環境に基づいています。 +以下のセクションでは、TiDB クラスターの移行とアップグレードに関する標準化されたプロセスと一般的な手順について説明します。コマンド例は、TiDB Self-Managed環境に基づいています。 ## ステップ1: ソリューションの実現可能性を評価する {#step-1-evaluate-solution-feasibility} @@ -44,9 +44,9 @@ summary: 完全バックアップと復元のためのBRと、増分データレ ## ステップ2: 新しいクラスターを準備する {#step-2-prepare-the-new-cluster} -### 1. 古いクラスタのGC有効期間を調整する {#1-adjust-the-gc-lifetime-of-the-old-cluster} +### 1. 古いクラスターのGC有効期間を調整する {#1-adjust-the-gc-lifetime-of-the-old-cluster} -データレプリケーションの安定性を確保するため、システム変数[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50) 、 BRバックアップ、 BRリストア、クラスタアップグレード、 TiCDC Changefeedレプリケーションセットアップの各操作と間隔の合計所要時間をカバーする値に調整してください。そうしないと、レプリケーションタスクが回復不能な状態`failed`になり、移行とアップグレードのプロセス全体を新しいフルバックアップからやり直す必要が生じる可能性があります。 +データレプリケーションの安定性を確保するため、システム変数[`tidb_gc_life_time`](/system-variables.md#tidb_gc_life_time-new-in-v50) 、 BRバックアップ、 BRリストア、クラスターアップグレード、 TiCDC Changefeedレプリケーションセットアップの各操作と間隔の合計所要時間をカバーする値に調整してください。そうしないと、レプリケーションタスクが回復不能な状態`failed`になり、移行とアップグレードのプロセス全体を新しいフルバックアップからやり直す必要が生じる可能性があります。 次の例では、 `tidb_gc_life_time`を`60h`に設定します。 @@ -59,7 +59,7 @@ SET GLOBAL tidb_gc_life_time=60h; > **注記：** > -> `tidb_gc_life_time`増やすと、 [MVCC](/glossary.md#multi-version-concurrency-control-mvcc)データのstorage使用量が増加し、クエリのパフォーマンスに影響する可能性があります。詳細については、 [GCの概要](/garbage-collection-overview.md)参照してください。storageとパフォーマンスへの影響を考慮しながら、推定操作時間に基づいてGC期間を調整してください。 +> `tidb_gc_life_time`増やすと、 [MVCC](/glossary.md#multi-version-concurrency-control-mvcc)データのストレージ使用量が増加し、クエリのパフォーマンスに影響する可能性があります。詳細については、 [GCの概要](/garbage-collection-overview.md)参照してください。ストレージとパフォーマンスへの影響を考慮しながら、推定操作時間に基づいてGC期間を調整してください。 ### 2. 新しいクラスターに全データを移行する {#2-migrate-full-data-to-the-new-cluster} @@ -74,7 +74,7 @@ SET GLOBAL tidb_gc_life_time=60h; - バックアップ速度: 8 つのスレッドで TiKV ノードごとに 1 TiB のデータのバックアップに約 1 時間かかります。 - 復元速度: TiKV ノードごとに 1 TiB のデータの復元には約 20 分かかります。 -- **コンフィグレーションの整合性**：古いクラスタと新しいクラスタの構成が[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)であることを確認してください。同一でない場合、 BRの復元は失敗します。 +- **設定の整合性**：古いクラスターと新しいクラスターの構成が[`new_collations_enabled_on_first_bootstrap`](/tidb-configuration-file.md#new_collations_enabled_on_first_bootstrap)であることを確認してください。同一でない場合、 BRの復元は失敗します。 - **システム テーブルの復元**: BR復元中に`--with-sys-table`オプションを使用して、システム テーブル データを復元します。 @@ -90,7 +90,7 @@ SET GLOBAL tidb_gc_life_time=60h; ```shell tiup br:${cluster_version} validate decode --field="end-version" \ - --storage "s3://xxx?access-key=${access-key}&secret-access-key=${secret-access-key}" | tail -n1 + --ストレージ "s3://xxx?access-key=${access-key}&secret-access-key=${secret-access-key}" | tail -n1 ``` 3. 新しいクラスターをデプロイ。 @@ -121,7 +121,7 @@ tiup cluster start # Start the cluster ### 1. 順方向データ複製チャネルを確立する {#1-establish-a-forward-data-replication-channel} -この段階では、古いクラスタは元のバージョンのままですが、新しいクラスタはターゲットバージョンにアップグレードされています。このステップでは、古いクラスタから新しいクラスタへの順方向データレプリケーションチャネルを確立する必要があります。 +この段階では、古いクラスターは元のバージョンのままですが、新しいクラスターはターゲットバージョンにアップグレードされています。このステップでは、古いクラスターから新しいクラスターへの順方向データレプリケーションチャネルを確立する必要があります。 > **注記：** > @@ -175,7 +175,7 @@ tiup cluster start # Start the cluster ./sync_diff_inspector --config=./config.toml ``` -- [同期差分インスペクター](/sync-diff-inspector/sync-diff-inspector-overview.md)のスナップショット設定と TiCDC の[同期ポイント](/ticdc/ticdc-upstream-downstream-check.md)機能を組み合わせることで、Changefeed レプリケーションを停止することなくデータの整合性を検証できます。詳細については、 [上流および下流のクラスタのデータ検証とスナップショットの読み取り](/ticdc/ticdc-upstream-downstream-check.md)参照してください。 +- [同期差分インスペクター](/sync-diff-inspector/sync-diff-inspector-overview.md)のスナップショット設定と TiCDC の[同期ポイント](/ticdc/ticdc-upstream-downstream-check.md)機能を組み合わせることで、Changefeed レプリケーションを停止することなくデータの整合性を検証できます。詳細については、 [上流および下流のクラスターのデータ検証とスナップショットの読み取り](/ticdc/ticdc-upstream-downstream-check.md)参照してください。 - テーブルの行数の比較など、ビジネス データの手動検証を実行します。 @@ -184,7 +184,7 @@ tiup cluster start # Start the cluster この移行手順では、 BR `--with-sys-table`オプションを使用して一部のシステムテーブルデータを復元します。対象範囲に含まれないテーブルについては、手動で復元する必要があります。確認および補足すべき一般的な項目は次のとおりです。 - ユーザー権限： `mysql.user`テーブルを比較します。 -- コンフィグレーション設定: 構成項目とシステム変数が一貫していることを確認します。 +- 設定設定: 構成項目とシステム変数が一貫していることを確認します。 - 自動インクリメント列: 新しいクラスター内の自動インクリメント ID キャッシュをクリアします。 - 統計: 統計を手動で収集するか、新しいクラスターで自動収集を有効にします。 @@ -206,7 +206,7 @@ tiup cluster start # Start the cluster ### 2. 切り替えを実行する {#2-execute-the-switchover} -1. 古いクラスタがビジネストラフィックを処理できないように、アプリケーションサービスを停止します。アクセスをさらに制限するには、次のいずれかの方法を使用します。 +1. 古いクラスターがビジネストラフィックを処理できないように、アプリケーションサービスを停止します。アクセスをさらに制限するには、次のいずれかの方法を使用します。 - 古いクラスター内のユーザー アカウントをロックします。 @@ -214,7 +214,7 @@ tiup cluster start # Start the cluster ALTER USER ACCOUNT LOCK; ``` - - 古いクラスタを読み取り専用モードに設定します。アクティブなビジネスセッションをクリアし、読み取り専用モードに入っていない接続を防止するため、古いクラスタ内のTiDBノードを再起動することをお勧めします。 + - 古いクラスターを読み取り専用モードに設定します。アクティブなビジネスセッションをクリアし、読み取り専用モードに入っていない接続を防止するため、古いクラスター内のTiDBノードを再起動することをお勧めします。 ```sql SET GLOBAL tidb_super_read_only=ON; diff --git a/tiflash-deployment-topology.md b/tiflash-deployment-topology.md index 2214d97df5367..f281e5e71e1a6 100644 --- a/tiflash-deployment-topology.md +++ b/tiflash-deployment-topology.md @@ -7,11 +7,11 @@ summary: 最小限の TiDB トポロジに基づくTiFlashの展開トポロジ このドキュメントでは、最小限の TiDB トポロジに基づく[TiFlash](/tiflash/tiflash-overview.md)のデプロイメント トポロジについて説明します。 -TiFlashは列指向型storageエンジンであり、徐々に標準的なクラスタトポロジーになりつつあります。リアルタイムHTAPアプリケーションに適しています。 +TiFlashは列指向型ストレージエンジンであり、徐々に標準的なクラスタートポロジーになりつつあります。リアルタイムHTAPアプリケーションに適しています。 ## トポロジ情報 {#topology-information} -| 実例 | カウント | 物理マシン構成 | IP | コンフィグレーション | +| 実例 | カウント | 物理マシン構成 | IP | 設定 | | :------------- | :--- | :-------------------------------- | :----------------------------------- | :------------------------- | | TiDB | 3 | 16 VCore 32GB * 1 | 10.0.1.7
    10.0.1.8
    10.0.1.9 | デフォルトポート
    グローバルディレクトリ構成 | | PD | 3 | 4 VCore 8GB * 1 | 10.0.1.4
    10.0.1.5
    10.0.1.6 | デフォルトポート
    グローバルディレクトリ構成 | @@ -28,13 +28,13 @@ TiFlashは列指向型storageエンジンであり、徐々に標準的なクラ - [TiFlashトポロジのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiflash.yaml) - [TiFlashトポロジの複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-tiflash.yaml) -上記の TiDB クラスター トポロジ ファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)参照してください。 +上記の TiDB クラスター トポロジ ファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジ設定ファイル](/tiup/tiup-cluster-topology-reference.md)参照してください。 ### 主なパラメータ {#key-parameters} - PD の[配置ルール](/configure-placement-rules.md)機能を有効にするには、構成テンプレートの`replication.enable-placement-rules`の値を`true`に設定します。 - `tiflash_servers`のインスタンス レベル`"-host"`構成では、ドメイン名ではなく IP のみがサポートされます。 -- TiFlashパラメータの詳細な説明については、 [TiFlashコンフィグレーション](/tiflash/tiflash-configuration.md)参照してください。 +- TiFlashパラメータの詳細な説明については、 [TiFlash設定](/tiflash/tiflash-configuration.md)参照してください。 > **注記：** > diff --git a/tiflash-performance-tuning-methods.md b/tiflash-performance-tuning-methods.md index 6c470105b455c..c6cde4ae35003 100644 --- a/tiflash-performance-tuning-methods.md +++ b/tiflash-performance-tuning-methods.md @@ -7,7 +7,7 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ このドキュメントでは、 TiFlash のリソース使用率と主要なパフォーマンス指標について紹介します。パフォーマンス概要ダッシュボードの[TiFlashパネル](/grafana-performance-overview-dashboard.md#tiflash)から、 TiFlashクラスターのパフォーマンスを監視および評価できます。 -## TiFlashクラスタのリソース利用率 {#resource-utilization-of-a-tiflash-cluster} +## TiFlashクラスターのリソース利用率 {#resource-utilization-of-a-tiflash-cluster} 次の 3 つのメトリックを使用すると、 TiFlashクラスターのリソース使用率を簡単に取得できます。 @@ -90,13 +90,13 @@ summary: パフォーマンス概要ダッシュボードにTiFlashメトリッ - 書き込みフロー: すべてのTiFlashインスタンスによるディスク書き込みのトラフィック。 - - ファイル記述子: TiFlashで使用される DeltaTreestorageエンジンの安定したレイヤー。 - - Page: TiFlashで使用される DeltaTreestorageエンジンの Delta 変更レイヤーである Pagestore を指します。 + - ファイル記述子: TiFlashで使用される DeltaTreeストレージエンジンの安定したレイヤー。 + - Page: TiFlashで使用される DeltaTreeストレージエンジンの Delta 変更レイヤーである Pagestore を指します。 - 読み取りフロー: すべてのTiFlashインスタンスのディスク読み取り操作のトラフィック。 - - ファイル記述子: TiFlashで使用される DeltaTreestorageエンジンの安定したレイヤー。 - - Page: TiFlashで使用される DeltaTreestorageエンジンの Delta 変更レイヤーである Pagestore を指します。 + - ファイル記述子: TiFlashで使用される DeltaTreeストレージエンジンの安定したレイヤー。 + - Page: TiFlashで使用される DeltaTreeストレージエンジンの Delta 変更レイヤーである Pagestore を指します。 `(Read flow + Write flow) ÷ total Write Throughput By Instance`式を使用して、 TiFlashクラスター全体の書き込み増幅係数を計算できます。 diff --git a/tiflash-upgrade-guide.md b/tiflash-upgrade-guide.md index d8667e60e127e..d57cda4b2d72b 100644 --- a/tiflash-upgrade-guide.md +++ b/tiflash-upgrade-guide.md @@ -26,7 +26,7 @@ summary: TiFlash をアップグレードする際の注意事項を説明しま TiFlashをv5.3.0より前のバージョンからv5.3.0以降にアップグレードするには、 TiFlashを停止してからアップグレードする必要があります。TiUPを使用してTiFlashをアップグレードする際は、以下の点にご注意ください。 -- TiUPクラスタのバージョンがv1.12.0以降の場合、 TiFlashを停止してからアップグレードすることはできません。アップグレード先のバージョンでTiUPクラスタのバージョンがv1.12.0以降が必要な場合は、まず`tiup cluster:v1.11.3 `使用してTiFlashを中間バージョンにアップグレードし、TiDBクラスタのオンラインアップグレードを実行した後、 TiUPバージョンをアップグレードし、その後TiDBクラスタを停止せずに直接アップグレード先のバージョンにアップグレードすることをお勧めします。 +- TiUPクラスターのバージョンがv1.12.0以降の場合、 TiFlashを停止してからアップグレードすることはできません。アップグレード先のバージョンでTiUPクラスターのバージョンがv1.12.0以降が必要な場合は、まず`tiup cluster:v1.11.3 `使用してTiFlashを中間バージョンにアップグレードし、TiDBクラスターのオンラインアップグレードを実行した後、 TiUPバージョンをアップグレードし、その後TiDBクラスターを停止せずに直接アップグレード先のバージョンにアップグレードすることをお勧めします。 - TiUPクラスターのバージョンが v1.12.0 より前の場合は、次の手順を実行してTiFlash をアップグレードします。 次の手順に従うと、 TiUPを使用して他のコンポーネントを中断せずにTiFlash をアップグレードできます。 @@ -81,11 +81,11 @@ TiFlash Proxyはv6.1.0（TiKV v6.0.0と連動）にアップグレードされ ## v5.x または v6.0 から v6.2 へ {#from-v5-x-or-v6-0-to-v6-2} -TiDB v6.2では、 TiFlashのデータstorageフォーマットがV3にアップグレードされ、ライトアンプリフィケーションの低減とTiFlashの安定性向上が図られています。v5.x、v6.0、またはv6.1からv6.2以降のバージョンにアップグレードする場合は、 [TiFlashプロキシ](#tiflash-proxy)と[動的剪定](#dynamic-pruning)の機能変更に加えて、PageStorageの機能変更にも注意する必要があります。 +TiDB v6.2では、 TiFlashのデータストレージフォーマットがV3にアップグレードされ、ライトアンプリフィケーションの低減とTiFlashの安定性向上が図られています。v5.x、v6.0、またはv6.1からv6.2以降のバージョンにアップグレードする場合は、 [TiFlashプロキシ](#tiflash-proxy)と[動的剪定](#dynamic-pruning)の機能変更に加えて、PageStorageの機能変更にも注意する必要があります。 -### ページストレージ {#pagestorage} +### ページストレージ {#pageストレージ} -TiFlash v6.2.0はデフォルトでPageStorage V3バージョン[`format_version = 4`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file)を使用します。この新しいデータフォーマットは、ピーク時の書き込みI/Oトラフィックを大幅に削減します。更新トラフィックが多く、同時実行性やクエリ負荷が高いシナリオでは、 TiFlashデータGCによる過剰なCPU使用率を効果的に軽減します。また、以前のstorageフォーマットと比較して、V3バージョンはスペース増幅とリソース消費を大幅に削減します。 +TiFlash v6.2.0はデフォルトでPageStorage V3バージョン[`format_version = 4`](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file)を使用します。この新しいデータフォーマットは、ピーク時の書き込みI/Oトラフィックを大幅に削減します。更新トラフィックが多く、同時実行性やクエリ負荷が高いシナリオでは、 TiFlashデータGCによる過剰なCPU使用率を効果的に軽減します。また、以前のストレージフォーマットと比較して、V3バージョンはスペース増幅とリソース消費を大幅に削減します。 - v6.2.0 にアップグレードすると、新しいデータが既存のTiFlashノードに書き込まれると同時に、以前のデータは徐々に新しい形式に変換されます。 - ただし、アップグレード中に以前のデータを新しい形式に完全に変換することはできません。これは、変換によってある程度のシステムオーバーヘッドが発生するためです（サービスには影響はありませんが、注意が必要です）。アップグレード後、 [`Compact`コマンド](/sql-statements/sql-statement-alter-table-compact.md)を実行してデータを新しい形式に変換することをお勧めします。手順は次のとおりです。 @@ -123,19 +123,19 @@ TiFlash v6.2.0はデフォルトでPageStorage V3バージョン[`format_version 対象のTiFlashノードを強制的にスケールインし、TiKVからデータを再度複製することができます。詳細な手順については、 [TiFlashクラスターのスケールイン](/scale-tidb-using-tiup.md#scale-in-a-tiflash-cluster)参照してください。 -## v6.x または v7.x からstorage.format_version = 5が設定された v7.3 へ {#from-v6-x-or-v7-x-to-v7-3-with-code-storage-format-version-5-code-configured} +## v6.x または v7.x からストレージ.format_version = 5が設定された v7.3 へ {#from-v6-x-or-v7-x-to-v7-3-with-code-ストレージ-format-version-5-code-configured} -TiFlash v7.3 以降、新しい DTFile バージョン DTFile V3 (実験的) が導入されました。この新しい DTFile バージョンでは、複数の小さなファイルを 1 つの大きなファイルに結合することで、ファイル総数を削減できます。v7.3 では、デフォルトの DTFile バージョンは引き続き V2 です。V3 を使用するには、 [TiFlash構成パラメータ](/tiflash/tiflash-configuration.md) `storage.format_version = 5`を設定します。設定後もTiFlash はV2 DTFile を読み取り可能で、その後のデータ圧縮時に既存の V2 DTFile を徐々に V3 DTFile に書き換えます。 +TiFlash v7.3 以降、新しい DTFile バージョン DTFile V3 (実験的) が導入されました。この新しい DTFile バージョンでは、複数の小さなファイルを 1 つの大きなファイルに結合することで、ファイル総数を削減できます。v7.3 では、デフォルトの DTFile バージョンは引き続き V2 です。V3 を使用するには、 [TiFlash構成パラメータ](/tiflash/tiflash-configuration.md) `ストレージ.format_version = 5`を設定します。設定後もTiFlash はV2 DTFile を読み取り可能で、その後のデータ圧縮時に既存の V2 DTFile を徐々に V3 DTFile に書き換えます。 TiFlashをv7.3にアップグレードし、V3 DTFilesを使用するように設定した後、 TiFlashを以前のバージョンに戻す必要がある場合は、DTToolをオフラインで使用してV3 DTFilesをV2 DTFilesに書き換えることができます。詳細については、 [DTTool 移行ツール](/tiflash/tiflash-command-line-flags.md#dttool-migrate)参照してください。 ## v6.x または v7.x から v7.4 以降のバージョンへ {#from-v6-x-or-v7-x-to-v7-4-or-a-later-version} -v7.4以降、データ圧縮中に発生する読み取りおよび書き込みの増幅を軽減するため、 TiFlashはPageStorage V3のデータ圧縮ロジックを最適化します。これにより、基盤となるstorageファイル名の一部が変更されます。そのため、 TiFlashをv7.4以降にアップグレードした後は、元のバージョンへのインプレースダウングレードはサポートされません。 +v7.4以降、データ圧縮中に発生する読み取りおよび書き込みの増幅を軽減するため、 TiFlashはPageStorage V3のデータ圧縮ロジックを最適化します。これにより、基盤となるストレージファイル名の一部が変更されます。そのため、 TiFlashをv7.4以降にアップグレードした後は、元のバージョンへのインプレースダウングレードはサポートされません。 ## v7.x から v8.4 以降のバージョンへ {#from-v7-x-to-v8-4-or-a-later-version} -バージョン8.4以降、 TiFlashの基盤となるstorageフォーマットは[ベクトル検索](/ai/concepts/vector-search-overview.md)サポートするように更新されました。そのため、 TiFlashをバージョン8.4以降にアップグレードした後は、元のバージョンへのインプレースダウングレードはサポートされません。 +バージョン8.4以降、 TiFlashの基盤となるストレージフォーマットは[ベクトル検索](/ai/concepts/vector-search-overview.md)サポートするように更新されました。そのため、 TiFlashをバージョン8.4以降にアップグレードした後は、元のバージョンへのインプレースダウングレードはサポートされません。 **テストやその他の特別なシナリオでTiFlash をダウングレードするための回避策** diff --git a/tiflash/create-tiflash-replicas.md b/tiflash/create-tiflash-replicas.md index 3a59177004e92..207b00d3f4fe4 100644 --- a/tiflash/create-tiflash-replicas.md +++ b/tiflash/create-tiflash-replicas.md @@ -279,7 +279,7 @@ TiDB クラスターは、次のいずれかの操作を実行すると、 TiFla -ラベルを使用してレプリカをスケジュールする方法の詳細については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md) 、 [1 つの地域展開における複数のデータセンター](/multi-data-centers-in-one-city-deployment.md) 、および[2 つの地域に配置された 3 つのデータ センター](/three-data-centers-in-two-cities-deployment.md)参照してください。 +ラベルを使用してレプリカをスケジュールする方法の詳細については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md) 、 [1 つの地域に配置された複数のデータセンター](/multi-data-centers-in-one-city-deployment.md) 、および[2 つの地域に配置された 3 つのデータ センター](/three-data-centers-in-two-cities-deployment.md)参照してください。 TiFlashは、異なるゾーンに対するレプリカ選択戦略の設定をサポートしています。詳細については、 [`tiflash_replica_read`](/system-variables.md#tiflash_replica_read-new-in-v730)参照してください。 diff --git a/tiflash/maintain-tiflash.md b/tiflash/maintain-tiflash.md index bb6d8caa2224c..6fe0ceaedaf3e 100644 --- a/tiflash/maintain-tiflash.md +++ b/tiflash/maintain-tiflash.md @@ -3,9 +3,9 @@ title: Maintain a TiFlash Cluster summary: TiFlashクラスターを保守する際の一般的な操作を学習します。 --- -# TiFlashクラスタを管理 {#maintain-a-tiflash-cluster} +# TiFlashクラスターを管理 {#maintain-a-tiflash-cluster} -このドキュメントでは、 TiFlash のバージョン確認など、 [TiFlash](/tiflash/tiflash-overview.md)クラスタのメンテナンス時によく行われる操作について説明します。また、 TiFlashの重要なログとシステムテーブルについても紹介します。 +このドキュメントでは、 TiFlash のバージョン確認など、 [TiFlash](/tiflash/tiflash-overview.md)クラスターのメンテナンス時によく行われる操作について説明します。また、 TiFlashの重要なログとシステムテーブルについても紹介します。 ## TiFlashのバージョンを確認する {#check-the-tiflash-version} diff --git a/tiflash/monitor-tiflash.md b/tiflash/monitor-tiflash.md index a4ac35dbf1abd..1d787a7dbaabb 100644 --- a/tiflash/monitor-tiflash.md +++ b/tiflash/monitor-tiflash.md @@ -3,7 +3,7 @@ title: Monitor the TiFlash Cluster summary: TiFlashの監視項目について学びます。 --- -# TiFlashクラスタを監視する {#monitor-the-tiflash-cluster} +# TiFlashクラスターを監視する {#monitor-the-tiflash-cluster} このドキュメントでは、 TiFlashの監視項目について説明します。 @@ -21,9 +21,9 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas ## サーバ {#server} -- ストア サイズ: 各TiFlashインスタンスで使用されるstorageサイズ。 -- 使用可能なサイズ: 各TiFlashインスタンスで使用可能なstorageサイズ。 -- 容量サイズ: 各TiFlashインスタンスのstorage容量。 +- ストア サイズ: 各TiFlashインスタンスで使用されるストレージサイズ。 +- 使用可能なサイズ: 各TiFlashインスタンスで使用可能なストレージサイズ。 +- 容量サイズ: 各TiFlashインスタンスのストレージ容量。 - 稼働時間: 前回の再起動以降のTiFlashの実行時間。 - メモリ: TiFlashインスタンスごとのメモリ使用量。 - CPU 使用率: TiFlashインスタンスごとの CPU 使用率。 @@ -33,7 +33,7 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas > **注記：** > -> ストア サイズ、FSync OPS、ファイル オープン OPS、および開かれたファイル数は、現在、 TiFlashstorageレイヤーの監視情報のみをカバーしており、 TiFlash-Proxy ではカバーしていません。 +> ストア サイズ、FSync OPS、ファイル オープン OPS、および開かれたファイル数は、現在、 TiFlashストレージレイヤーの監視情報のみをカバーしており、 TiFlash-Proxy ではカバーしていません。 ## コプロセッサー {#coprocessor} @@ -66,12 +66,12 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas - スキーマ内部 DDL OPM: すべてのTiFlashインスタンスで 1 分あたりに実行された特定の DDL 操作の数。 - スキーマ適用期間: すべてのTiFlashインスタンスでの単一の`apply schema`操作に使用される時間。 -## ストレージ {#storage} +## ストレージ {#ストレージ} -- 書き込みコマンド OPS: すべてのTiFlashインスタンスのstorageレイヤーで 1 秒あたりに受信される書き込み要求の数。 +- 書き込みコマンド OPS: すべてのTiFlashインスタンスのストレージレイヤーで 1 秒あたりに受信される書き込み要求の数。 - 書き込み増幅: 各TiFlashインスタンスの書き込み増幅 (実際のディスク書き込みバイト数を論理データの書き込みバイト数で割った値)。1 `total`この開始以降の書き込み増幅で、 `5min`過去 5 分間の書き込み増幅です。 -- 読み取りタスク OPS: TiFlashインスタンスごとのstorageレイヤーでの 1 秒あたりの読み取りタスクの数。 -- 粗セット フィルタ レート: ストレージstorageの粗セットレイヤーによってフィルタされた、過去 1 分間に各TiFlashインスタンスによって読み取られたパケット数の割合。 +- 読み取りタスク OPS: TiFlashインスタンスごとのストレージレイヤーでの 1 秒あたりの読み取りタスクの数。 +- 粗セット フィルタ レート: ストレージストレージの粗セットレイヤーによってフィルタされた、過去 1 分間に各TiFlashインスタンスによって読み取られたパケット数の割合。 - 内部タスク OPS: すべてのTiFlashインスタンスが 1 秒あたりに内部データ ソート タスクを実行する回数。 - 内部タスクの所要時間: すべてのTiFlashインスタンスが内部データ ソート タスクに費やした時間。 - ページ GC タスク OPM: すべてのTiFlashインスタンスが 1 分間に Delta データ ソート タスクを実行する回数。 @@ -83,9 +83,9 @@ TiFlash には、 **TiFlash-Summary** 、 **TiFlash-Proxy-Summary** 、 **TiFlas > **注記：** > -> これらのメトリックは、 TiFlashstorageレイヤーの監視情報のみをカバーし、 TiFlash-Proxy の監視情報はカバーしません。 +> これらのメトリックは、 TiFlashストレージレイヤーの監視情報のみをカバーし、 TiFlash-Proxy の監視情報はカバーしません。 -## ストレージ書き込み停止 {#storage-write-stall} +## ストレージ書き込み停止 {#ストレージ-write-stall} - 書き込みとデルタ管理スループット: すべてのインスタンスの書き込みとデータ圧縮のスループット。 - `throughput_write` Raftを介したデータ同期のスループットを意味します。 diff --git a/tiflash/tiflash-alert-rules.md b/tiflash/tiflash-alert-rules.md index c63e1c7aca43b..3fc31a79afd12 100644 --- a/tiflash/tiflash-alert-rules.md +++ b/tiflash/tiflash-alert-rules.md @@ -33,7 +33,7 @@ summary: TiFlashクラスターのアラート ルールについて学習しま - 解決： - これは、 TiFlashstorageエンジンの内部的な問題が原因である可能性があります。1 [サポートを受ける](/support.md) PingCAP またはコミュニティから提供されました。 + これは、 TiFlashストレージエンジンの内部的な問題が原因である可能性があります。1 [サポートを受ける](/support.md) PingCAP またはコミュニティから提供されました。 ## TiFlash_raft_read_index_duration {#code-tiflash-raft-read-index-duration-code} diff --git a/tiflash/tiflash-command-line-flags.md b/tiflash/tiflash-command-line-flags.md index 62d973383efe2..3457c2c170b90 100644 --- a/tiflash/tiflash-command-line-flags.md +++ b/tiflash/tiflash-command-line-flags.md @@ -22,7 +22,7 @@ summary: TiFlashのコマンドライン起動フラグについて学習しま - データ検証が有効になっているバージョン v5.4.0 以上からバージョン v5.4.0 未満にTiFlash をダウングレードする必要がある場合は、このツールを使用して DTFile のデータ形式をダウングレードできます。 - TiFlash をバージョン >= v5.4.0 にアップグレードし、既存のデータのデータ検証を有効にする場合は、このツールを使用して DTFile のデータ形式をアップグレードできます。 - さまざまな構成で DTFile のスペース使用量と読み取り速度をテストします。 - - 小さなファイルのマージが有効になっているバージョン v7.3.0 以上 (つまり、 `storage.format_version` >= 5) のTiFlash をバージョン v7.3.0 未満にダウングレードする必要がある場合は、このツールを使用して DTFile のデータ形式をダウングレードできます。 + - 小さなファイルのマージが有効になっているバージョン v7.3.0 以上 (つまり、 `ストレージ.format_version` >= 5) のTiFlash をバージョン v7.3.0 未満にダウングレードする必要がある場合は、このツールを使用して DTFile のデータ形式をダウングレードできます。 - パラメータ: - `--imitative` : DTFile の暗号化機能を使用しない場合は、このフラグを使用して構成ファイルの使用と PD への接続を回避できます。 diff --git a/tiflash/tiflash-configuration.md b/tiflash/tiflash-configuration.md index 1fad8097e939f..74dc50c669639 100644 --- a/tiflash/tiflash-configuration.md +++ b/tiflash/tiflash-configuration.md @@ -46,30 +46,30 @@ summary: TiFlash の設定方法を学びます。 #### path {#code-path-code} -- TiFlashデータのstorageパス。複数のディレクトリがある場合は、各ディレクトリをカンマで区切ってください。 -- TiDB v4.0.9以降、 `path`と[`path_realtime_mode`](#path_realtime_mode)は非推奨となりました。マルチディスク展開シナリオでパフォーマンスを向上させるには、 [`storage`](#storage-new-in-v409)セクションの設定を使用してください。 -- TiDB v5.2.0 以降、 [`storage.io_rate_limit`](#storageio_rate_limit-new-in-v520)構成を使用する必要がある場合は、同時にTiFlashデータのstorageパスを[`storage.main.dir`](#dir)に設定する必要があります。 -- `storage`構成が存在する場合、 `path`と[`path_realtime_mode`](#path_realtime_mode)構成は両方とも無視されます。 +- TiFlashデータのストレージパス。複数のディレクトリがある場合は、各ディレクトリをカンマで区切ってください。 +- TiDB v4.0.9以降、 `path`と[`path_realtime_mode`](#path_realtime_mode)は非推奨となりました。マルチディスク展開シナリオでパフォーマンスを向上させるには、 [`ストレージ`](#ストレージ-new-in-v409)セクションの設定を使用してください。 +- TiDB v5.2.0 以降、 [`ストレージ.io_rate_limit`](#ストレージio_rate_limit-new-in-v520)構成を使用する必要がある場合は、同時にTiFlashデータのストレージパスを[`ストレージ.main.dir`](#dir)に設定する必要があります。 +- `ストレージ`構成が存在する場合、 `path`と[`path_realtime_mode`](#path_realtime_mode)構成は両方とも無視されます。 #### path_realtime_mode {#code-path-realtime-mode-code} - `true`に設定し、 `path`に複数のディレクトリを設定した場合、最初のディレクトリに最新のデータが保存され、残りのディレクトリには古いデータが保存されます。 -- TiDB v4.0.9以降、 [`path`](#path)と`path_realtime_mode`は非推奨となりました。マルチディスク展開シナリオでパフォーマンスを向上させるには、 [`storage`](#storage-new-in-v409)セクションの設定を使用してください。 -- `storage`構成が存在する場合、 [`path`](#path)と`path_realtime_mode`構成は両方とも無視されます。 +- TiDB v4.0.9以降、 [`path`](#path)と`path_realtime_mode`は非推奨となりました。マルチディスク展開シナリオでパフォーマンスを向上させるには、 [`ストレージ`](#ストレージ-new-in-v409)セクションの設定を使用してください。 +- `ストレージ`構成が存在する場合、 [`path`](#path)と`path_realtime_mode`構成は両方とも無視されます。 - デフォルト値: `false` #### tmp_path {#code-tmp-path-code} - TiFlash一時ファイルが保存されるパス。 -- デフォルトでは、 [`path`](#path)の最初のディレクトリ、または[`storage.latest.dir`](#dir-1)に`"/tmp"`を付加したディレクトリになります。 +- デフォルトでは、 [`path`](#path)の最初のディレクトリ、または[`ストレージ.latest.dir`](#dir-1)に`"/tmp"`を付加したディレクトリになります。 -#### storagev4.0.9 の新機能 {#storage-span-class-version-mark-new-in-v4-0-9-span} +#### ストレージv4.0.9 の新機能 {#ストレージ-span-class-version-mark-new-in-v4-0-9-span} -storageパス関連の設定を構成します。 +ストレージパス関連の設定を構成します。 ##### format_version {#code-format-version-code} @@ -80,10 +80,10 @@ storageパス関連の設定を構成します。 - `format_version = 3` : v6.0.0 および v6.1.x のデフォルト形式。より多くのデータ検証機能が提供されます。 - `format_version = 4` : バージョン v6.2.0 から v7.3.0 までのデフォルトの形式。書き込み増幅とバックグラウンド タスクのリソース消費を削減します。 - `format_version = 5` : v7.3.0 で導入され、v7.4.0 から v8.3.0 までのバージョンのデフォルト形式で、小さなファイルを結合することで物理ファイルの数を削減します。 - - `format_version = 6` : v8.4.0 で導入され、ベクトル インデックスの構築とstorageを部分的にサポートします。 - - `format_version = 7` : v8.4.0 で導入され、v8.4.0 以降のバージョンのデフォルト形式で、ベクトル インデックスの構築とstorageをサポートします。 + - `format_version = 6` : v8.4.0 で導入され、ベクトル インデックスの構築とストレージを部分的にサポートします。 + - `format_version = 7` : v8.4.0 で導入され、v8.4.0 以降のバージョンのデフォルト形式で、ベクトル インデックスの構築とストレージをサポートします。 -#### storage.main {#storage-main} +#### ストレージ.main {#ストレージ-main} ##### dir {#code-dir-code} @@ -92,47 +92,47 @@ storageパス関連の設定を構成します。 ##### capacity {#code-capacity-code} -- [`storage.main.dir`](#dir)内の各ディレクトリの最大storage容量。例: `[10737418240, 10737418240]` 。 +- [`ストレージ.main.dir`](#dir)内の各ディレクトリの最大ストレージ容量。例: `[10737418240, 10737418240]` 。 - 設定されていない場合、または`0`倍数に設定されている場合、実際のディスク (ディレクトリが配置されているディスク) の容量が使用されます。 - 単位: バイト`"10GB"`などの人間が読める数値はまだサポートされていないことに注意してください。 -- `capacity`番目のリストのサイズは[`storage.main.dir`](#dir)リストのサイズと同じである必要があります。 +- `capacity`番目のリストのサイズは[`ストレージ.main.dir`](#dir)リストのサイズと同じである必要があります。 -#### storage.latest {#storage-latest} +#### ストレージ.latest {#ストレージ-latest} ##### dir {#code-dir-code} -- 最新データを保存するディレクトリのリストです。全データの約10%がこのディレクトリリストに保存されます。ここにリストされているディレクトリ（またはディレクトリ）は、 [`storage.main.dir`](#dir)よりも高いIOPSメトリックを必要とします。 -- 設定されていない場合（デフォルト）、値[`storage.main.dir`](#dir)が使用されます。 +- 最新データを保存するディレクトリのリストです。全データの約10%がこのディレクトリリストに保存されます。ここにリストされているディレクトリ（またはディレクトリ）は、 [`ストレージ.main.dir`](#dir)よりも高いIOPSメトリックを必要とします。 +- 設定されていない場合（デフォルト）、値[`ストレージ.main.dir`](#dir)が使用されます。 ##### capacity {#code-capacity-code} -- [`storage.latest.dir`](#dir-1)内の各ディレクトリの最大storage容量。設定されていない場合、または`0`倍数に設定されている場合は、実際のディスク（ディレクトリが配置されているディスク）の容量が使用されます。 +- [`ストレージ.latest.dir`](#dir-1)内の各ディレクトリの最大ストレージ容量。設定されていない場合、または`0`倍数に設定されている場合は、実際のディスク（ディレクトリが配置されているディスク）の容量が使用されます。 -#### storage.io_rate_limit v5.2.0 の新機能 {#storage-io-rate-limit-span-class-version-mark-new-in-v5-2-0-span} +#### ストレージ.io_rate_limit v5.2.0 の新機能 {#ストレージ-io-rate-limit-span-class-version-mark-new-in-v5-2-0-span} I/O トラフィック制限設定を構成します。 ##### max_bytes_per_sec {#code-max-bytes-per-sec-code} -- ディスクの読み取りと書き込みの合計I/O帯域幅。この設定項目は、I/Oトラフィックを制限するかどうかを決定します。デフォルトでは無効になっています。TiFlashにおけるこのトラフィック制限は、ディスク帯域幅が小さく、特定のサイズに制限TiFlashれているクラウドstorageに適しています。 +- ディスクの読み取りと書き込みの合計I/O帯域幅。この設定項目は、I/Oトラフィックを制限するかどうかを決定します。デフォルトでは無効になっています。TiFlashにおけるこのトラフィック制限は、ディスク帯域幅が小さく、特定のサイズに制限TiFlashれているクラウドストレージに適しています。 - デフォルト値: `0` 。これは、I/O トラフィックがデフォルトで制限されないことを意味します。 - 単位: バイト ##### max_read_bytes_per_sec {#code-max-read-bytes-per-sec-code} - ディスク読み取りの合計 I/O 帯域幅。 -- 設定項目`max_read_bytes_per_sec`および`max_write_bytes_per_sec` 、ディスクの読み取りと書き込みの I/O 帯域幅を個別に制限します。Google Cloud が提供する Persistent Disk など、ディスクの読み取りと書き込みの I/O 帯域幅の制限を個別に計算するクラウドstorageに使用できます。 +- 設定項目`max_read_bytes_per_sec`および`max_write_bytes_per_sec` 、ディスクの読み取りと書き込みの I/O 帯域幅を個別に制限します。Google Cloud が提供する Persistent Disk など、ディスクの読み取りと書き込みの I/O 帯域幅の制限を個別に計算するクラウドストレージに使用できます。 - `max_bytes_per_sec`の値が`0`でない場合は[`max_bytes_per_sec`](#max_bytes_per_sec)が優先されます。 - デフォルト値: `0` ##### max_write_bytes_per_sec {#code-max-write-bytes-per-sec-code} - ディスク書き込みの合計 I/O 帯域幅。 -- 設定項目`max_read_bytes_per_sec`および`max_write_bytes_per_sec` 、ディスクの読み取りと書き込みの I/O 帯域幅を個別に制限します。Google Cloud が提供する Persistent Disk など、ディスクの読み取りと書き込みの I/O 帯域幅の制限を個別に計算するクラウドstorageに使用できます。 +- 設定項目`max_read_bytes_per_sec`および`max_write_bytes_per_sec` 、ディスクの読み取りと書き込みの I/O 帯域幅を個別に制限します。Google Cloud が提供する Persistent Disk など、ディスクの読み取りと書き込みの I/O 帯域幅の制限を個別に計算するクラウドストレージに使用できます。 - `max_bytes_per_sec`の値が`0`でない場合は[`max_bytes_per_sec`](#max_bytes_per_sec)が優先されます。 - デフォルト値: `0` @@ -173,9 +173,9 @@ I/O トラフィック制限設定を構成します。 - デフォルト値: `5` - 単位: 秒 -#### storage.s3 {#storage-s3} +#### ストレージ.s3 {#ストレージ-s3} -以下の設定項目は、 TiFlash分散storageおよびコンピューティングアーキテクチャモードにのみ適用されます。詳細については、 [TiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 サポート](/tiflash/tiflash-disaggregated-and-s3.md)参照してください。 +以下の設定項目は、 TiFlash分散ストレージおよびコンピューティングアーキテクチャモードにのみ適用されます。詳細については、 [TiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 サポート](/tiflash/tiflash-disaggregated-and-s3.md)参照してください。 ##### endpoint {#code-endpoint-code} @@ -197,11 +197,11 @@ I/O トラフィック制限設定を構成します。 - S3 にアクセスするために使用される SECRET_ACCESS_KEY。 -#### storage.remote.cache {#storage-remote-cache} +#### ストレージ.remote.cache {#ストレージ-remote-cache} ##### dir {#code-dir-code} -- 分散storageおよびコンピューティングアーキテクチャ内のコンピューティング ノードのローカル データ キャッシュ ディレクトリ。 +- 分散ストレージおよびコンピューティングアーキテクチャ内のコンピューティング ノードのローカル データ キャッシュ ディレクトリ。 @@ -238,7 +238,7 @@ I/O トラフィック制限設定を構成します。 ##### disaggregated_mode {#code-disaggregated-mode-code} -- この設定項目は、 TiFlash分散storageおよびコンピューティングアーキテクチャモードにのみ適用されます。詳細については、 [TiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 サポート](/tiflash/tiflash-disaggregated-and-s3.md)参照してください。 +- この設定項目は、 TiFlash分散ストレージおよびコンピューティングアーキテクチャモードにのみ適用されます。詳細については、 [TiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 サポート](/tiflash/tiflash-disaggregated-and-s3.md)参照してください。 - 値`"tiflash_compute"`オプション: `"tiflash_write"` ##### graceful_wait_shutdown_timeout v8.5.4 の新機能 {#code-graceful-wait-shutdown-timeout-code-span-class-version-mark-new-in-v8-5-4-span} @@ -278,7 +278,7 @@ I/O トラフィック制限設定を構成します。 ##### data-dir {#code-data-dir-code} -- プロキシのデータstorageパス。 +- プロキシのデータストレージパス。 @@ -404,13 +404,13 @@ I/O トラフィック制限設定を構成します。 ##### dt_compression_method {#code-dt-compression-method-code} -- TiFlashstorageエンジンの圧縮アルゴリズム。 +- TiFlashストレージエンジンの圧縮アルゴリズム。 - デフォルト値: `LZ4` - 値のオプション: `LZ4` `LZ4HC`値は`zstd`と小文字を区別しません。 ##### dt_compression_level {#code-dt-compression-level-code} -- TiFlashstorageエンジンの圧縮レベル。 +- TiFlashストレージエンジンの圧縮レベル。 - `dt_compression_method`が`LZ4`の場合は、この値を`1`に設定することをお勧めします。 - この値は`-1` (圧縮率は低くなりますが、読み取りパフォーマンスは向上します) に設定するか、 `dt_compression_method`が`zstd`の場合は`1`に設定することをお勧めします。 - `dt_compression_method`が`LZ4HC`の場合は、この値を`9`に設定することをお勧めします。 @@ -524,7 +524,7 @@ I/O トラフィック制限設定を構成します。 ##### apply-pool-size {#code-apply-pool-size-code} -- Raftデータをstorageにフラッシュするプール内の許容スレッド数。 +- Raftデータをストレージにフラッシュするプール内の許容スレッド数。 @@ -582,12 +582,12 @@ I/O トラフィック制限設定を構成します。 TiFlashはマルチディスク構成をサポートしています。TiFlashノードに複数のディスクがある場合、以下のセクションで説明するパラメータを設定することで、それらのディスクを最大限に活用できます。TiUPで使用するTiUPの設定テンプレートについては、 [TiFlashトポロジの複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-tiflash.yaml)参照してください。 -v4.0.9以降のバージョンのTiDBクラスターでは、 TiFlashはstorageエンジンのメインデータと最新データを複数のディスクに保存することをサポートしています。TiFlashノードを複数のディスクにデプロイする場合は、ノードのI/Oパフォーマンスを最大限に活用するために、 `[storage]`セクションでstorageディレクトリを指定することをお勧めします。 +v4.0.9以降のバージョンのTiDBクラスターでは、 TiFlashはストレージエンジンのメインデータと最新データを複数のディスクに保存することをサポートしています。TiFlashノードを複数のディスクにデプロイする場合は、ノードのI/Oパフォーマンスを最大限に活用するために、 `[ストレージ]`セクションでストレージディレクトリを指定することをお勧めします。 -TiFlashノード上に類似したI/Oメトリックを持つ複数のディスクがある場合は、リスト`storage.main.dir`で対応するディレクトリを指定し、リスト`storage.latest.dir`空のままにすることをお勧めします。TiFlashはI/O負荷とデータをすべてのディレクトリに分散します。 +TiFlashノード上に類似したI/Oメトリックを持つ複数のディスクがある場合は、リスト`ストレージ.main.dir`で対応するディレクトリを指定し、リスト`ストレージ.latest.dir`空のままにすることをお勧めします。TiFlashはI/O負荷とデータをすべてのディレクトリに分散します。 -TiFlashノード上にI/Oメトリックが異なる複数のディスクがある場合は、 `storage.latest.dir`番目のリストにメトリックの高いディレクトリを指定し、 `storage.main.dir`番目のリストにメトリックの低いディレクトリを指定することをお勧めします。例えば、NVMe-SSDが1台とSATA-SSDが2台の場合、 `storage.latest.dir`を`["/nvme_ssd_a/data/tiflash"]`を`storage.main.dir` `["/sata_ssd_b/data/tiflash", "/sata_ssd_c/data/tiflash"]`設定します。TiFlashは、これらの2つのディレクトリリストにそれぞれI/O負荷とデータを分散します。この場合、 `storage.latest.dir`という容量は、計画容量全体の10%として計画する必要があることに注意してください。 +TiFlashノード上にI/Oメトリックが異なる複数のディスクがある場合は、 `ストレージ.latest.dir`番目のリストにメトリックの高いディレクトリを指定し、 `ストレージ.main.dir`番目のリストにメトリックの低いディレクトリを指定することをお勧めします。例えば、NVMe-SSDが1台とSATA-SSDが2台の場合、 `ストレージ.latest.dir`を`["/nvme_ssd_a/data/tiflash"]`を`ストレージ.main.dir` `["/sata_ssd_b/data/tiflash", "/sata_ssd_c/data/tiflash"]`設定します。TiFlashは、これらの2つのディレクトリリストにそれぞれI/O負荷とデータを分散します。この場合、 `ストレージ.latest.dir`という容量は、計画容量全体の10%として計画する必要があることに注意してください。 > **警告：** > -> `[storage]`設定はTiUP v1.2.5 以降でサポートされています。TiDB クラスタのバージョンが v4.0.9 以降の場合は、 TiUPのバージョンが v1.2.5 以降であることを確認してください。そうでない場合、 `[storage]`で定義されているデータディレクトリはTiUPによって管理されません。 +> `[ストレージ]`設定はTiUP v1.2.5 以降でサポートされています。TiDB クラスターのバージョンが v4.0.9 以降の場合は、 TiUPのバージョンが v1.2.5 以降であることを確認してください。そうでない場合、 `[ストレージ]`で定義されているデータディレクトリはTiUPによって管理されません。 diff --git a/tiflash/tiflash-data-validation.md b/tiflash/tiflash-data-validation.md index 48a268f8b941f..0e059d94a154c 100644 --- a/tiflash/tiflash-data-validation.md +++ b/tiflash/tiflash-data-validation.md @@ -15,7 +15,7 @@ summary: TiFlashのデータ検証メカニズムとツールについて学習 ## 検証メカニズム {#validation-mechanism} -検証メカニズムはDeltaTreeファイル（DTFile）を基盤としています。DTFileはTiFlashデータを保存するstorageファイルです。DTFileには以下の3つの形式があります。 +検証メカニズムはDeltaTreeファイル（DTFile）を基盤としています。DTFileはTiFlashデータを保存するストレージファイルです。DTFileには以下の3つの形式があります。 | バージョン | 州 | 検証メカニズム | 注記 | | :---- | :------------------------ | :-------------------------------------------------------- | :---------------------------- | diff --git a/tiflash/tiflash-disaggregated-and-s3.md b/tiflash/tiflash-disaggregated-and-s3.md index 5bbf6afa3608c..9ab2e24f07870 100644 --- a/tiflash/tiflash-disaggregated-and-s3.md +++ b/tiflash/tiflash-disaggregated-and-s3.md @@ -1,17 +1,17 @@ --- title: TiFlash Disaggregated Storage and Compute Architecture and S3 Support -summary: TiFlash の分散storageとコンピューティングアーキテクチャ、および S3 サポートについて学習します。 +summary: TiFlash の分散ストレージとコンピューティングアーキテクチャ、および S3 サポートについて学習します。 --- -# TiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 サポート {#tiflash-disaggregated-storage-and-compute-architecture-and-s3-support} +# TiFlash分散ストレージおよびコンピューティングアーキテクチャと S3 サポート {#tiflash-disaggregated-ストレージ-and-compute-architecture-and-s3-support} -デフォルトでは、 TiFlashはstorageとコンピューティングを組み合わせたアーキテクチャを使用してデプロイされ、各TiFlashノードはstorageとコンピューティングノードの両方として機能します。TiDB v7.0.0以降、 TiFlashは分散型storageとコンピューティングアーキテクチャをサポートし、Amazon S3またはS3互換オブジェクトstorage（MinIOなど）にデータを保存できるようになりました。 +デフォルトでは、 TiFlashはストレージとコンピューティングを組み合わせたアーキテクチャを使用してデプロイされ、各TiFlashノードはストレージとコンピューティングノードの両方として機能します。TiDB v7.0.0以降、 TiFlashは分散型ストレージとコンピューティングアーキテクチャをサポートし、Amazon S3またはS3互換オブジェクトストレージ（MinIOなど）にデータを保存できるようになりました。 ## アーキテクチャの概要 {#architecture-overview} ![TiFlash Write and Compute Separation Architecture](/media/tiflash/tiflash-s3.png) -分散型storageおよびコンピューティングアーキテクチャでは、 TiFlashプロセスの異なる機能が分割され、書き込みノードとコンピューティングノードという2種類のノードに割り当てられます。これらの2種類のノードは個別に導入および拡張できるため、必要に応じて導入する書き込みノードとコンピューティングノードの数を決定できます。 +分散型ストレージおよびコンピューティングアーキテクチャでは、 TiFlashプロセスの異なる機能が分割され、書き込みノードとコンピューティングノードという2種類のノードに割り当てられます。これらの2種類のノードは個別に導入および拡張できるため、必要に応じて導入する書き込みノードとコンピューティングノードの数を決定できます。 - TiFlash書き込みノード @@ -32,9 +32,9 @@ summary: TiFlash の分散storageとコンピューティングアーキテク ## シナリオ {#scenarios} -TiFlashの分散型storageおよびコンピューティングアーキテクチャは、コスト効率の高いデータ分析サービスに最適です。このアーキテクチャでは、storageとコンピューティングリソースを必要に応じて個別に拡張できるため、以下のシナリオで大きなメリットが得られます。 +TiFlashの分散型ストレージおよびコンピューティングアーキテクチャは、コスト効率の高いデータ分析サービスに最適です。このアーキテクチャでは、ストレージとコンピューティングリソースを必要に応じて個別に拡張できるため、以下のシナリオで大きなメリットが得られます。 -- データ量は膨大ですが、頻繁にクエリされるデータはごくわずかです。データの大部分はコールドデータであり、クエリ頻度は低いです。このため、頻繁にクエリされるデータは通常、コンピュートノードのローカルSSDにキャッシュされ、高速なクエリパフォーマンスを提供します。一方、その他のコールドデータの大部分は、storageコストを節約するために、低コストのS3などのオブジェクトstorageに保存されます。 +- データ量は膨大ですが、頻繁にクエリされるデータはごくわずかです。データの大部分はコールドデータであり、クエリ頻度は低いです。このため、頻繁にクエリされるデータは通常、コンピュートノードのローカルSSDにキャッシュされ、高速なクエリパフォーマンスを提供します。一方、その他のコールドデータの大部分は、ストレージコストを節約するために、低コストのS3などのオブジェクトストレージに保存されます。 - コンピューティングリソースの需要には明らかなピークと谷があります。例えば、集中的なリコンシリエーションクエリは通常夜間に実行され、多くのコンピューティングリソースを必要とします。このような場合、夜間に一時的にコンピューティングノードを追加することを検討できます。一方、他の時間帯には、通常のクエリタスクを実行するために必要なコンピューティングノードの数は少なくて済みます。 @@ -44,7 +44,7 @@ TiFlashの分散型storageおよびコンピューティングアーキテクチ 既存のバケットを使用することもできますが、TiDBクラスターごとに専用のキープレフィックスを予約する必要があります。S3バケットの詳細については、 [AWSドキュメント](https://docs.aws.amazon.com/en_us/AmazonS3/latest/userguide/creating-buckets-s3.html)ご覧ください。 - [ミニオ](https://min.io/)などの他の S3 互換オブジェクトstorageを使用することもできます。 + [ミニオ](https://min.io/)などの他の S3 互換オブジェクトストレージを使用することもできます。 TiFlash はデータにアクセスするために以下の S3 API を使用する必要があります。TiDB クラスター内のTiFlashノードにこれらの API に対する必要な権限が付与されていることを確認してください。 @@ -56,7 +56,7 @@ TiFlashの分散型storageおよびコンピューティングアーキテクチ - オブジェクトタグ付けの取得 - PutBucketライフサイクル -2. TiDBクラスターに、storageとコンピューティングを組み合わせたアーキテクチャを使用してデプロイされたTiFlashノードがないことを確認してください。もしある場合は、すべてのテーブルのTiFlashレプリカ数を`0`に設定し、すべてのTiFlashノードを削除してください。例： +2. TiDBクラスターに、ストレージとコンピューティングを組み合わせたアーキテクチャを使用してデプロイされたTiFlashノードがないことを確認してください。もしある場合は、すべてのテーブルのTiFlashレプリカ数を`0`に設定し、すべてのTiFlashノードを削除してください。例： ```sql SELECT * FROM INFORMATION_SCHEMA.TIFLASH_REPLICA; # Query all tables with TiFlash replicas @@ -71,13 +71,13 @@ TiFlashの分散型storageおよびコンピューティングアーキテクチ ## 使用法 {#usage} -デフォルトでは、 TiUPはTiFlash を結合storageおよびコンピューティングアーキテクチャにデプロイします。分離storageおよびコンピューティングアーキテクチャにTiFlashをデプロイする必要がある場合は、以下の手順に従って手動で設定してください。 +デフォルトでは、 TiUPはTiFlash を結合ストレージおよびコンピューティングアーキテクチャにデプロイします。分離ストレージおよびコンピューティングアーキテクチャにTiFlashをデプロイする必要がある場合は、以下の手順に従って手動で設定してください。 1. 次の構成を持つ、 `scale-out.topo.yaml`などのTiFlashトポロジ構成ファイルを準備します。 ```yaml tiflash_servers: - # In the TiFlash topology configuration file, the `storage.s3` configuration indicates that the disaggregated storage and compute architecture is used for deployment. + # In the TiFlash topology configuration file, the `ストレージ.s3` configuration indicates that the disaggregated ストレージ and compute architecture is used for deployment. # If `flash.disaggregated_mode: tiflash_compute` is configured for a node, it is a Compute Node. # If `flash.disaggregated_mode: tiflash_write` is configured for a node, it is a Write Node. @@ -85,45 +85,45 @@ TiFlashの分散型storageおよびコンピューティングアーキテクチ - host: 172.31.8.1 config: flash.disaggregated_mode: tiflash_write # This is a Write Node - storage.s3.endpoint: http://s3.{region}.amazonaws.com # S3 endpoint address - storage.s3.bucket: mybucket # TiFlash stores all data in this bucket - storage.s3.root: /cluster1_data # Root directory where data is stored in the S3 bucket - storage.s3.access_key_id: {ACCESS_KEY_ID} # Access S3 with ACCESS_KEY_ID - storage.s3.secret_access_key: {SECRET_ACCESS_KEY} # Access S3 with SECRET_ACCESS_KEY - storage.main.dir: ["/data1/tiflash/data"] # Local data directory of the Write Node. Configure it in the same way as the directory configuration of the coupled storage and compute architecture + ストレージ.s3.endpoint: http://s3.{region}.amazonaws.com # S3 endpoint address + ストレージ.s3.bucket: mybucket # TiFlash stores all data in this bucket + ストレージ.s3.root: /cluster1_data # Root directory where data is stored in the S3 bucket + ストレージ.s3.access_key_id: {ACCESS_KEY_ID} # Access S3 with ACCESS_KEY_ID + ストレージ.s3.secret_access_key: {SECRET_ACCESS_KEY} # Access S3 with SECRET_ACCESS_KEY + ストレージ.main.dir: ["/data1/tiflash/data"] # Local data directory of the Write Node. Configure it in the same way as the directory configuration of the coupled ストレージ and compute architecture - host: 172.31.8.2 config: flash.disaggregated_mode: tiflash_write # This is a Write Node - storage.s3.endpoint: http://s3.{region}.amazonaws.com # S3 endpoint address - storage.s3.bucket: mybucket # TiFlash stores all data in this bucket - storage.s3.root: /cluster1_data # Root directory where data is stored in the S3 bucket - storage.s3.access_key_id: {ACCESS_KEY_ID} # Access S3 with ACCESS_KEY_ID - storage.s3.secret_access_key: {SECRET_ACCESS_KEY} # Access S3 with SECRET_ACCESS_KEY - storage.main.dir: ["/data1/tiflash/data"] # Local data directory of the Write Node. Configure it in the same way as the directory configuration of the coupled storage and compute architecture + ストレージ.s3.endpoint: http://s3.{region}.amazonaws.com # S3 endpoint address + ストレージ.s3.bucket: mybucket # TiFlash stores all data in this bucket + ストレージ.s3.root: /cluster1_data # Root directory where data is stored in the S3 bucket + ストレージ.s3.access_key_id: {ACCESS_KEY_ID} # Access S3 with ACCESS_KEY_ID + ストレージ.s3.secret_access_key: {SECRET_ACCESS_KEY} # Access S3 with SECRET_ACCESS_KEY + ストレージ.main.dir: ["/data1/tiflash/data"] # Local data directory of the Write Node. Configure it in the same way as the directory configuration of the coupled ストレージ and compute architecture # 172.31.9.1~2 are TiFlash Compute Nodes - host: 172.31.9.1 config: flash.disaggregated_mode: tiflash_compute # This is a Compute Node - storage.s3.endpoint: http://s3.{region}.amazonaws.com # S3 endpoint address - storage.s3.bucket: mybucket # TiFlash stores all data in this bucket - storage.s3.root: /cluster1_data # Root directory where data is stored in the S3 bucket - storage.s3.access_key_id: {ACCESS_KEY_ID} # Access S3 with ACCESS_KEY_ID - storage.s3.secret_access_key: {SECRET_ACCESS_KEY} # Access S3 with SECRET_ACCESS_KEY - storage.main.dir: ["/data1/tiflash/data"] # Local data directory of the Compute Node. Configure it in the same way as the directory configuration of the coupled storage and compute architecture - storage.remote.cache.dir: /data1/tiflash/cache # Local data cache directory of the Compute Node - storage.remote.cache.capacity: 858993459200 # 800 GiB + ストレージ.s3.endpoint: http://s3.{region}.amazonaws.com # S3 endpoint address + ストレージ.s3.bucket: mybucket # TiFlash stores all data in this bucket + ストレージ.s3.root: /cluster1_data # Root directory where data is stored in the S3 bucket + ストレージ.s3.access_key_id: {ACCESS_KEY_ID} # Access S3 with ACCESS_KEY_ID + ストレージ.s3.secret_access_key: {SECRET_ACCESS_KEY} # Access S3 with SECRET_ACCESS_KEY + ストレージ.main.dir: ["/data1/tiflash/data"] # Local data directory of the Compute Node. Configure it in the same way as the directory configuration of the coupled ストレージ and compute architecture + ストレージ.remote.cache.dir: /data1/tiflash/cache # Local data cache directory of the Compute Node + ストレージ.remote.cache.capacity: 858993459200 # 800 GiB - host: 172.31.9.2 config: flash.disaggregated_mode: tiflash_compute # This is a Compute Node - storage.s3.endpoint: http://s3.{region}.amazonaws.com # S3 endpoint address - storage.s3.bucket: mybucket # TiFlash stores all data in this bucket - storage.s3.root: /cluster1_data # Root directory where data is stored in the S3 bucket - storage.s3.access_key_id: {ACCESS_KEY_ID} # Access S3 with ACCESS_KEY_ID - storage.s3.secret_access_key: {SECRET_ACCESS_KEY} # Access S3 with SECRET_ACCESS_KEY - storage.main.dir: ["/data1/tiflash/data"] # Local data directory of the Compute Node. Configure it in the same way as the directory configuration of the coupled storage and compute architecture - storage.remote.cache.dir: /data1/tiflash/cache # Local data cache directory of the Compute Node - storage.remote.cache.capacity: 858993459200 # 800 GiB + ストレージ.s3.endpoint: http://s3.{region}.amazonaws.com # S3 endpoint address + ストレージ.s3.bucket: mybucket # TiFlash stores all data in this bucket + ストレージ.s3.root: /cluster1_data # Root directory where data is stored in the S3 bucket + ストレージ.s3.access_key_id: {ACCESS_KEY_ID} # Access S3 with ACCESS_KEY_ID + ストレージ.s3.secret_access_key: {SECRET_ACCESS_KEY} # Access S3 with SECRET_ACCESS_KEY + ストレージ.main.dir: ["/data1/tiflash/data"] # Local data directory of the Compute Node. Configure it in the same way as the directory configuration of the coupled ストレージ and compute architecture + ストレージ.remote.cache.dir: /data1/tiflash/cache # Local data cache directory of the Compute Node + ストレージ.remote.cache.capacity: 858993459200 # 800 GiB ``` - 上記の`ACCESS_KEY_ID`と`SECRET_ACCESS_KEY`設定ファイルに直接記述されていることに注意してください。環境変数を使用して個別に設定することもできます。両方の方法で設定した場合、環境変数が優先されます。 @@ -135,7 +135,7 @@ TiFlashの分散型storageおよびコンピューティングアーキテクチ export S3_SECRET_ACCESS_KEY={SECRET_ACCESS_KEY} ``` - - `storage.s3.endpoint` `http`または`https`モードを使用した S3 接続をサポートしており、URL を直接変更することでモードを設定できます。例: `https://s3.{region}.amazonaws.com` 。 + - `ストレージ.s3.endpoint` `http`または`https`モードを使用した S3 接続をサポートしており、URL を直接変更することでモードを設定できます。例: `https://s3.{region}.amazonaws.com` 。 2. TiFlashノードを追加し、 TiFlashレプリカの数をリセットします。 @@ -147,7 +147,7 @@ TiFlashの分散型storageおよびコンピューティングアーキテクチ ALTER TABLE table_name SET TIFLASH REPLICA 1; ``` -3. 分散storageおよびコンピューティングアーキテクチャを使用してTiFlash をクエリするように TiDB 構成を変更します。 +3. 分散ストレージおよびコンピューティングアーキテクチャを使用してTiFlash をクエリするように TiDB 構成を変更します。 1. TiDB 構成ファイルを編集モードで開きます。 @@ -160,7 +160,7 @@ TiFlashの分散型storageおよびコンピューティングアーキテクチ ```shell server_configs: tidb: - disaggregated-tiflash: true # Query TiFlash using the disaggregated storage and compute architecture + disaggregated-tiflash: true # Query TiFlash using the disaggregated ストレージ and compute architecture ``` 3. TiDBを再起動します。 @@ -171,8 +171,8 @@ TiFlashの分散型storageおよびコンピューティングアーキテクチ ## 制限 {#restrictions} -- TiFlash は**、分離storageおよびコンピューティングアーキテクチャと****結合storageおよびコンピューティングアーキテクチャ**間のインプレース切り替えをサポートしていません。分離アーキテクチャに切り替える前に、結合アーキテクチャを使用してデプロイされている既存のTiFlashノードをすべて削除する必要があります。 +- TiFlash は**、分離ストレージおよびコンピューティングアーキテクチャと****結合ストレージおよびコンピューティングアーキテクチャ**間のインプレース切り替えをサポートしていません。分離アーキテクチャに切り替える前に、結合アーキテクチャを使用してデプロイされている既存のTiFlashノードをすべて削除する必要があります。 - あるアーキテクチャから別のアーキテクチャに移行した後、すべてのTiFlashデータを再度複製する必要があります。 - 同じTiDBクラスター内では、同じアーキテクチャのTiFlashノードのみが許可されます。1つのクラスター内で2つのアーキテクチャを共存させることはできません。 -- 分散型storageおよびコンピューティングアーキテクチャはS3 API を使用したオブジェクトstorageのみをサポートしますが、結合型storageおよびコンピューティングアーキテクチャはローカルstorageのみをサポートします。 -- S3storageを使用する場合、 TiFlashノードは自身のノード上にないファイルのキーを取得できないため、 [保存時の暗号化](/encryption-at-rest.md)機能は使用できません。 +- 分散型ストレージおよびコンピューティングアーキテクチャはS3 API を使用したオブジェクトストレージのみをサポートしますが、結合型ストレージおよびコンピューティングアーキテクチャはローカルストレージのみをサポートします。 +- S3ストレージを使用する場合、 TiFlashノードは自身のノード上にないファイルのキーを取得できないため、 [保存時の暗号化](/encryption-at-rest.md)機能は使用できません。 diff --git a/tiflash/tiflash-overview.md b/tiflash/tiflash-overview.md index 11beed501d8a5..ef4aac63a6514 100644 --- a/tiflash/tiflash-overview.md +++ b/tiflash/tiflash-overview.md @@ -5,9 +5,9 @@ summary: TiFlashのアーキテクチャと主な機能について学びます # TiFlashの概要 {#tiflash-overview} -[TiFlash](https://github.com/pingcap/tiflash)は、TiDBを本質的にハイブリッドトランザクション／分析処理（HTAP）データベースにする主要コンポーネントです。TiKVの列指向storage拡張であるTiFlashは、優れた分離レベルと強力な一貫性保証の両方を提供します。 +[TiFlash](https://github.com/pingcap/tiflash)は、TiDBを本質的にハイブリッドトランザクション／分析処理（HTAP）データベースにする主要コンポーネントです。TiKVの列指向ストレージ拡張であるTiFlashは、優れた分離レベルと強力な一貫性保証の両方を提供します。 -TiFlashでは、列指向レプリカはRaft Learnerコンセンサスアルゴリズムに従って非同期的に複製されます。これらのレプリカが読み込まれると、 Raftインデックスと多版型同時実行制御（MVCC）の検証によって、スナップショット分離レベルの一貫性が実現されます。 +TiFlashでは、列指向レプリカはRaftラーナーコンセンサスアルゴリズムに従って非同期的に複製されます。これらのレプリカが読み込まれると、 Raftインデックスと多版型同時実行制御（MVCC）の検証によって、スナップショット分離レベルの一貫性が実現されます。 @@ -17,13 +17,13 @@ TiDB Cloud を使用すると、HTAP ワークロードに応じて 1 つ以上 ## アーキテクチャ {#architecture} -![TiFlash Architecture](/media/tidb-storage-architecture-1.png) +![TiFlash Architecture](/media/tidb-ストレージ-architecture-1.png) 上の図は、 TiFlashノードを含む HTAP 形式の TiDB のアーキテクチャです。 -TiFlashは、ClickHouseによって効率的に実装されたコプロセッサレイヤーを備えた列指向storageを提供します。TiKVと同様に、 TiFlashにもMulti-Raftシステムが搭載されており、リージョン単位でのデータの複製と分散をサポートします（詳細は[データストレージ](https://www.pingcap.com/blog/tidb-internal-data-storage/)参照）。 +TiFlashは、ClickHouseによって効率的に実装されたコプロセッサレイヤーを備えた列指向ストレージを提供します。TiKVと同様に、 TiFlashにもMulti-Raftシステムが搭載されており、リージョン単位でのデータの複製と分散をサポートします（詳細は[データストレージ](https://www.pingcap.com/blog/tidb-internal-data-ストレージ/)参照）。 -TiFlashは、 TiKVノード内のデータのリアルタイムレプリケーションを低コストで実行します。これにより、TiKVへの書き込みがブロックされることはありません。同時に、TiKVと同様の読み取り一貫性を提供し、最新のデータが読み取られることを保証します。TiFlashのリージョンレプリカはTiKVのレプリカと論理的に同一であり、TiKVのLeaderレプリカと同時に分割・統合されます。 +TiFlashは、 TiKVノード内のデータのリアルタイムレプリケーションを低コストで実行します。これにより、TiKVへの書き込みがブロックされることはありません。同時に、TiKVと同様の読み取り一貫性を提供し、最新のデータが読み取られることを保証します。TiFlashのリージョンレプリカはTiKVのレプリカと論理的に同一であり、TiKVのリーダーレプリカと同時に分割・統合されます。 Linux AMD64アーキテクチャでTiFlash を展開するには、CPU が AVX2 命令セットをサポートしている必要があります。1 `grep avx2 /proc/cpuinfo`出力が生成されることを確認して確認してください。Linux ARM64アーキテクチャの場合、CPU が ARMv8 命令セットアーキテクチャをサポートしている必要があります。3 `grep 'crc32' /proc/cpuinfo | grep 'asimd'`出力が生成されることを確認して確認してください。これらの命令セット拡張を使用することで、TiFlash のベクトル化エンジンはより優れたパフォーマンスを発揮できます。 @@ -35,9 +35,9 @@ TiFlashはTiDBと互換性があります。TiDBをTiFlashの計算エンジン ワークロードの分離を確保するため、 TiFlash をTiKV とは別のノードにデプロイすることをお勧めします。業務上の分離が不要な場合は、 TiFlashと TiKV を同じノードにデプロイすることも可能です。 -現在、 TiFlashに直接データを書き込むことはできません。TiKV は TiDB クラスターにLearnerロールとして接続するため、 TiFlashにデータを書き込み、それを複製する必要があります。TiFlashはテーブル単位でのデータ複製をサポートしていますが、デプロイ後、デフォルトではデータは複製されません。指定したテーブルのデータを複製するには、 [テーブルのTiFlashレプリカを作成する](/tiflash/create-tiflash-replicas.md#create-tiflash-replicas-for-tables)参照してください。 +現在、 TiFlashに直接データを書き込むことはできません。TiKV は TiDB クラスターにラーナーロールとして接続するため、 TiFlashにデータを書き込み、それを複製する必要があります。TiFlashはテーブル単位でのデータ複製をサポートしていますが、デプロイ後、デフォルトではデータは複製されません。指定したテーブルのデータを複製するには、 [テーブルのTiFlashレプリカを作成する](/tiflash/create-tiflash-replicas.md#create-tiflash-replicas-for-tables)参照してください。 -TiFlashは、列指向storageコンポーネントとTiFlashプロキシコンポーネントという2つの主要コンポーネントで構成されています。TiFlashコンポーネントは、Multi-Raftコンセンサスアルゴリズムを用いた通信を担います。 +TiFlashは、列指向ストレージコンポーネントとTiFlashプロキシコンポーネントという2つの主要コンポーネントで構成されています。TiFlashコンポーネントは、Multi-Raftコンセンサスアルゴリズムを用いた通信を担います。 TiFlash内のテーブルのレプリカを作成するための DDL コマンドを受信すると、TiDB は PD 内に対応する[配置ルール](https://docs.pingcap.com/tidb/stable/configure-placement-rules)自動的に作成し、その後 PD はこれらのルールに基づいて対応するデータ スケジューリングを実行します。 @@ -52,7 +52,7 @@ TiFlash には次の主な機能があります。 ### 非同期レプリケーション {#asynchronous-replication} -TiFlash内のレプリカは、特別なロールであるRaft Learnerとして非同期的に複製されます。つまり、 TiFlashノードがダウンしたり、ネットワークのレイテンシーが長くなった場合でも、TiKV内のアプリケーションは正常に動作し続けることができます。 +TiFlash内のレプリカは、特別なロールであるRaftラーナーとして非同期的に複製されます。つまり、 TiFlashノードがダウンしたり、ネットワークのレイテンシーが長くなった場合でも、TiKV内のアプリケーションは正常に動作し続けることができます。 このレプリケーション メカニズムは、自動負荷分散と高可用性という TiKV の 2 つの利点を継承しています。 @@ -63,7 +63,7 @@ TiFlash内のレプリカは、特別なロールであるRaft Learnerとして TiFlashはTiKVと同じスナップショット分離レベルの一貫性を提供し、最新のデータが読み取られることを保証します。つまり、TiKVに以前書き込まれたデータを読み取ることができます。このような一貫性は、データレプリケーションの進行状況を検証することで実現されます。 -TiFlash が読み取り要求を受信するたびに、リージョンレプリカはLeaderレプリカに進行状況検証要求（軽量 RPC 要求）を送信します。TiFlashは、読み取り要求のタイムスタンプに含まれるデータが現在のレプリケーション進行状況に含まれた場合にのみ、読み取り操作を実行します。 +TiFlash が読み取り要求を受信するたびに、リージョンレプリカはリーダーレプリカに進行状況検証要求（軽量 RPC 要求）を送信します。TiFlashは、読み取り要求のタイムスタンプに含まれるデータが現在のレプリケーション進行状況に含まれた場合にのみ、読み取り操作を実行します。 ### 賢い選択 {#intelligent-choice} @@ -75,10 +75,10 @@ TiDB は、 TiFlash (列単位) または TiKV (行単位) の使用を自動的 TiFlash は、次の 2 つの方法で TiDB のコンピューティングを高速化します。 -- 列型storageエンジンは読み取り操作の実行においてより効率的です。 +- 列型ストレージエンジンは読み取り操作の実行においてより効率的です。 - TiFlash はTiDB のコンピューティング ワークロードの一部を共有します。 -TiFlashは、TiKVコプロセッサーと同様にコンピューティングワークロードを分散します。TiDBは、storageレイヤーで完了可能なコンピューティングをプッシュダウンします。コンピューティングをプッシュダウンできるかどうかは、 TiFlashのサポート状況によって異なります。詳細については、 [サポートされているプッシュダウン計算](/tiflash/tiflash-supported-pushdown-calculations.md)参照してください。 +TiFlashは、TiKVコプロセッサーと同様にコンピューティングワークロードを分散します。TiDBは、ストレージレイヤーで完了可能なコンピューティングをプッシュダウンします。コンピューティングをプッシュダウンできるかどうかは、 TiFlashのサポート状況によって異なります。詳細については、 [サポートされているプッシュダウン計算](/tiflash/tiflash-supported-pushdown-calculations.md)参照してください。 ## TiFlashを使用する {#use-tiflash} @@ -100,7 +100,7 @@ TPC-H データセットでのデータのインポートからクエリまで -- TiFlashノードを含む新しいクラスターを展開するには、 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)参照してください。 +- TiFlashノードを含む新しいクラスターを展開するには、 [TiUPを使用して TiDBクラスターをデプロイ](/production-deployment-using-tiup.md)参照してください。 - デプロイされたクラスターにTiFlashノードを追加するには、 [TiFlashクラスターのスケールアウト](/scale-tidb-using-tiup.md#scale-out-a-tiflash-cluster)参照してください。 - [TiFlashクラスターを管理](/tiflash/maintain-tiflash.md) 。 - [TiFlashのパフォーマンスを調整する](/tiflash/tune-tiflash-performance.md) 。 diff --git a/tiflash/tiflash-results-materialization.md b/tiflash/tiflash-results-materialization.md index 810cab8fc9caa..4ebf827766a84 100644 --- a/tiflash/tiflash-results-materialization.md +++ b/tiflash/tiflash-results-materialization.md @@ -1,6 +1,6 @@ --- title: TiFlash Query Result Materialization -summary: TiFlashのクエリ結果をトランザクションに保存する方法を学びます。 +summary: TiFlashのクエリ結果をテーブルに保存（マテリアライズ）する方法を学びます。 --- # TiFlashクエリ結果のマテリアライゼーション {#tiflash-query-result-materialization} diff --git a/tiflash/tiflash-supported-pushdown-calculations.md b/tiflash/tiflash-supported-pushdown-calculations.md index 12e23cb377327..d8176a77d3128 100644 --- a/tiflash/tiflash-supported-pushdown-calculations.md +++ b/tiflash/tiflash-supported-pushdown-calculations.md @@ -148,7 +148,7 @@ SHOW WARNINGS; +---------+------+------------------------------------------------------------------------------------------------------------------------------------+ | Level | Code | Message | +---------+------+------------------------------------------------------------------------------------------------------------------------------------+ -| Warning | 1105 | Scalar function 'time'(signature: Time, return type: time) is not supported to push down to storage layer now. | +| Warning | 1105 | Scalar function 'time'(signature: Time, return type: time) is not supported to push down to ストレージ layer now. | | Warning | 1105 | Scalar function 'cast'(signature: CastDurationAsString, return type: var_string(10)) is not supported to push down to tiflash now. | | Warning | 1105 | Scalar function 'cast'(signature: CastDurationAsString, return type: var_string(10)) is not supported to push down to tiflash now. | +---------+------+------------------------------------------------------------------------------------------------------------------------------------+ diff --git a/tiflash/troubleshoot-tiflash.md b/tiflash/troubleshoot-tiflash.md index b2e452d00fb2e..49aa752e6f250 100644 --- a/tiflash/troubleshoot-tiflash.md +++ b/tiflash/troubleshoot-tiflash.md @@ -3,7 +3,7 @@ title: Troubleshoot a TiFlash Cluster summary: TiFlashクラスターのトラブルシューティングを行う際の一般的な操作を学習します。 --- -# TiFlashクラスタのトラブルシューティング {#troubleshoot-a-tiflash-cluster} +# TiFlashクラスターのトラブルシューティング {#troubleshoot-a-tiflash-cluster} このセクションでは、 TiFlashの使用時によく発生する問題、その原因、および解決策について説明します。 @@ -158,7 +158,7 @@ TiDB クラスターを展開した後、 TiFlashレプリカの作成が継続 - 値`count`がクラスター内の TiKV ノードの数以下の場合は、次の手順に進みます。 - - `count`の値がクラスタ内の TiKV ノードの数より大きい場合（例えば、テストクラスタに TiKV ノードが 1 つしかなく、 `count`が`3`場合）、PD はTiFlashノードにリージョンピアを追加しません。この問題に対処するには、 `count`クラスタ内の TiKV ノードの数以下の整数に変更してください。 + - `count`の値がクラスター内の TiKV ノードの数より大きい場合（例えば、テストクラスターに TiKV ノードが 1 つしかなく、 `count`が`3`場合）、PD はTiFlashノードにリージョンピアを追加しません。この問題に対処するには、 `count`クラスター内の TiKV ノードの数以下の整数に変更してください。 > **注記：** > @@ -190,7 +190,7 @@ TiDB クラスターを展開した後、 TiFlashレプリカの作成が継続 - 新しいTiFlashノードをスケールアウトします。PD はTiFlashノード間でリージョンのバランスを自動的に取り、十分なディスク容量を持つTiFlashノードへのリージョンのスケジュールを再開します。 - - TiFlashノードディスクから、ログファイルやディレクトリ`${data}/flash/`の`space_placeholder_file`ファイルなどの不要なファイルを削除します。必要に応じて、 `tiflash-learner.toml` ～ `0MB`の`storage.reserve-space`同時に設定し、 TiFlashサービスを一時的に再開します。 + - TiFlashノードディスクから、ログファイルやディレクトリ`${data}/flash/`の`space_placeholder_file`ファイルなどの不要なファイルを削除します。必要に応じて、 `tiflash-learner.toml` ～ `0MB`の`ストレージ.reserve-space`同時に設定し、 TiFlashサービスを一時的に再開します。 ディスク使用量が`low-space-ratio`未満の場合は、ディスク容量が通常通り利用可能であることを示します。次の手順に進みます。 diff --git a/tiflash/use-fastscan.md b/tiflash/use-fastscan.md index bb774abf0a375..0b3ca4961e5ef 100644 --- a/tiflash/use-fastscan.md +++ b/tiflash/use-fastscan.md @@ -83,7 +83,7 @@ TiFlash は古いデータの圧縮をバックグラウンドで自動的に開 ## FastScanの仕組み {#mechanism-of-fastscan} -TiFlashのstorageレイヤーのデータは、デルタレイヤーと安定レイヤーの 2 つの層に保存されます。 +TiFlashのストレージレイヤーのデータは、デルタレイヤーと安定レイヤーの 2 つの層に保存されます。 デフォルトでは、FastScan は有効になっておらず、TableScan オペレーターは次の手順でデータを処理します。 diff --git a/tiflash/use-tidb-to-read-tiflash.md b/tiflash/use-tidb-to-read-tiflash.md index 4feb0e31d237a..09cde8fad7054 100644 --- a/tiflash/use-tidb-to-read-tiflash.md +++ b/tiflash/use-tidb-to-read-tiflash.md @@ -102,16 +102,16 @@ set SESSION tidb_isolation_read_engines = "engine list separated by commas"; 手動ヒントを使用すると、エンジン分離が満たされていることを前提に、特定のテーブルに対して指定されたレプリカを使用するようにTiDBに強制できます。以下は手動ヒントの使用例です。 ```sql -select /*+ read_from_storage(tiflash[table_name]) */ ... from table_name; +select /*+ read_from_ストレージ(tiflash[table_name]) */ ... from table_name; ``` クエリ文でテーブルに別名を設定した場合、ヒントを有効にするには、ヒントを含む文でもその別名を使用する必要があります。例: ```sql -select /*+ read_from_storage(tiflash[alias_a,alias_b]) */ ... from table_name_1 as alias_a, table_name_2 as alias_b where alias_a.column_1 = alias_b.column_2; +select /*+ read_from_ストレージ(tiflash[alias_a,alias_b]) */ ... from table_name_1 as alias_a, table_name_2 as alias_b where alias_a.column_1 = alias_b.column_2; ``` -上記の文では、 `tiflash[]`オプティマイザにTiFlashレプリカの読み取りを指示します。また、 `tikv[]`使用すると、必要に応じてオプティマイザに TiKV レプリカの読み取りを指示できます。ヒント構文の詳細については、 [ストレージからの読み取り](/optimizer-hints.md#read_from_storagetiflasht1_name--tl_name--tikvt2_name--tl_name-)を参照してください。 +上記の文では、 `tiflash[]`オプティマイザにTiFlashレプリカの読み取りを指示します。また、 `tikv[]`使用すると、必要に応じてオプティマイザに TiKV レプリカの読み取りを指示できます。ヒント構文の詳細については、 [ストレージからの読み取り](/optimizer-hints.md#read_from_ストレージtiflasht1_name--tl_name--tikvt2_name--tl_name-)を参照してください。 ヒントで指定されたテーブルに指定されたエンジンのレプリカが存在しない場合、ヒントは無視され、警告が報告されます。また、ヒントはエンジン分離を前提としてのみ有効です。ヒントで指定されたエンジンがエンジン分離リストに含まれていない場合も、ヒントは無視され、警告が報告されます。 diff --git a/tikv-configuration-file.md b/tikv-configuration-file.md index 73969e90b1ab5..a1ae376ced295 100644 --- a/tikv-configuration-file.md +++ b/tikv-configuration-file.md @@ -3,7 +3,7 @@ title: TiKV Configuration File summary: TiKVの設定ファイルについて学びましょう。 --- -# TiKVコンフィグレーションファイル {#tikv-configuration-file} +# TiKV設定ファイル {#tikv-configuration-file} @@ -42,7 +42,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ### memory-usage-limit {#code-memory-usage-limit-code} - TiKVインスタンスのメモリ使用量の上限。TiKVのメモリ使用量がこのしきい値に近づくと、内部キャッシュが削除されてメモリが解放されます。 -- ほとんどの場合、TiKVインスタンスはシステムメモリ全体の75%を使用するように設定されているため、この設定項目を明示的に指定する必要はありません。残りの25%のメモリはOSページキャッシュ用に予約されています。詳細は[`storage.block-cache.capacity`](#capacity)を参照してください。 +- ほとんどの場合、TiKVインスタンスはシステムメモリ全体の75%を使用するように設定されているため、この設定項目を明示的に指定する必要はありません。残りの25%のメモリはOSページキャッシュ用に予約されています。詳細は[`ストレージ.block-cache.capacity`](#capacity)を参照してください。 - 単一の物理マシン上に複数の TiKV ノードをデプロイする場合でも、この構成項目を設定する必要はありません。この場合、TiKV インスタンスは`5/3 * block-cache.capacity`のメモリを使用します。 - システムメモリ容量ごとのデフォルト値は以下のとおりです。 @@ -52,7 +52,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ## ログv5.4.0 の新機能 {#log-span-class-version-mark-new-in-v5-4-0-span} -- ログに関連するコンフィグレーション項目。 +- ログに関連する設定項目。 - バージョン 5.4.0 以降、TiKV と TiDB のログ設定項目を統一するため、TiKV は以前の設定項目`log-rotation-timespan`を非推奨とし、 `log-level` 、 `log-format` 、 `log-file` 、 `log-rotation-size`を以下の項目に変更します。古い設定項目のみを設定し、その値をデフォルト値以外に設定した場合、古い項目は新しい項目と互換性があります。古い設定項目と新しい設定項目の両方を設定した場合、新しい項目が有効になります。 @@ -76,7 +76,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ## log.file v5.4.0で追加 {#log-file-span-class-version-mark-new-in-v5-4-0-span} -- ログファイルに関連するコンフィグレーション項目。 +- ログファイルに関連する設定項目。 ### filename v5.4.0 で追加 {#code-filename-code-span-class-version-mark-new-in-v5-4-0-span} @@ -106,7 +106,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ## サーバー {#server} -- サーバーに関連するコンフィグレーション項目。 +- サーバーに関連する設定項目。 ### addr {#code-addr-code} @@ -311,7 +311,7 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも ## リードプール.unified {#readpool-unified} -読み取り要求を処理するシングルスレッドプールに関連するコンフィグレーション項目。このスレッドプールは、バージョン4.0以降、従来のstorageスレッドプールとコプロセッサスレッドプールに取って代わるものです。 +読み取り要求を処理するシングルスレッドプールに関連する設定項目。このスレッドプールは、バージョン4.0以降、従来のストレージスレッドプールとコプロセッサスレッドプールに取って代わるものです。 ### min-thread-count {#code-min-thread-count-code} @@ -363,13 +363,13 @@ TiKV の設定ファイルは、コマンドライン パラメータよりも - 値の範囲: `[0.0, 1.0]` -## リードプール。storage {#readpool-storage} +## リードプール。ストレージ {#readpool.storage} -storageスレッドプールに関連するコンフィグレーション項目。 +ストレージスレッドプールに関連する設定項目。 ### use-unified-pool {#code-use-unified-pool-code} -- storage要求に統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメーターの値が`false`の場合、このセクションの残りのパラメーター（ `readpool.storage` ）で構成された別のスレッドプールが使用されます。 +- ストレージ要求に統合スレッドプール（ [`readpool.unified`](#readpoolunified)で構成）を使用するかどうかを決定します。このパラメーターの値が`false`の場合、このセクションの残りのパラメーター（ `readpool.storage` ）で構成された別のスレッドプールが使用されます。 - デフォルト値: このセクション ( `readpool.storage` ) に他の設定がない場合、デフォルト値は`true`です。それ以外の場合は、下位互換性のために、デフォルト値は`false`です。このオプションを有効にする前に、必要に応じて[`readpool.unified`](#readpoolunified)の設定を変更してください。 ### high-concurrency {#code-high-concurrency-code} @@ -419,7 +419,7 @@ storageスレッドプールに関連するコンフィグレーション項目 ## readpool.coprocessor {#code-readpool-coprocessor-code} -コプロセッサースレッドプールに関連するコンフィグレーション項目。 +コプロセッサースレッドプールに関連する設定項目。 ### use-unified-pool {#code-use-unified-pool-code} @@ -471,13 +471,13 @@ storageスレッドプールに関連するコンフィグレーション項目 - 最小値: `"2MiB"` - 最大値: システムで実行された`ulimit -sH`コマンドの結果として出力される Kバイト数。 -## storage {#storage} +## ストレージ {#ストレージ} -storageに関連するコンフィグレーション項目。 +ストレージに関連する設定項目。 ### data-dir {#code-data-dir-code} -- RocksDBディレクトリのstorageパス +- RocksDBディレクトリのストレージパス - デフォルト値: `"./"` ### engine v6.6.0 の新機能 {#code-engine-code-span-class-version-mark-new-in-v6-6-0-span} @@ -491,7 +491,7 @@ storageに関連するコンフィグレーション項目。 - お得なオプション： - `"raft-kv"` : TiDB v6.6.0 より前のバージョンにおけるデフォルトのエンジンタイプ。 - - `"partitioned-raft-kv"` : TiDB v6.6.0 で導入された新しいstorageエンジン タイプ。 + - `"partitioned-raft-kv"` : TiDB v6.6.0 で導入された新しいストレージエンジン タイプ。 ### scheduler-concurrency {#code-scheduler-concurrency-code} @@ -518,8 +518,8 @@ storageに関連するコンフィグレーション項目。 ### reserve-space {#code-reserve-space-code} -- TiKVが起動すると、ディスク保護のためにディスク上に一定量の領域が確保されます。残りのディスク容量が確保された領域よりも少ない場合、TiKVは一部の書き込み操作を制限します。確保された領域は2つの部分に分けられます。80%はディスク容量が不足した場合の操作に必要な追加ディスク容量として使用され、残りの20%は一時ファイルの保存に使用されます。領域解放の過程で、追加ディスク容量を使いすぎてstorageが枯渇した場合、この一時ファイルがサービス復旧のための最後の保護手段として機能します。 -- 一時ファイルの名前は`space_placeholder_file`で、 `storage.data-dir`ディレクトリにあります。ディスク容量不足で TiKV がオフラインになった場合、TiKV を再起動すると、一時ファイルは自動的に削除され、TiKV は空き容量の確保を試みます。 +- TiKVが起動すると、ディスク保護のためにディスク上に一定量の領域が確保されます。残りのディスク容量が確保された領域よりも少ない場合、TiKVは一部の書き込み操作を制限します。確保された領域は2つの部分に分けられます。80%はディスク容量が不足した場合の操作に必要な追加ディスク容量として使用され、残りの20%は一時ファイルの保存に使用されます。領域解放の過程で、追加ディスク容量を使いすぎてストレージが枯渇した場合、この一時ファイルがサービス復旧のための最後の保護手段として機能します。 +- 一時ファイルの名前は`space_placeholder_file`で、 `ストレージ.data-dir`ディレクトリにあります。ディスク容量不足で TiKV がオフラインになった場合、TiKV を再起動すると、一時ファイルは自動的に削除され、TiKV は空き容量の確保を試みます。 - 残りの空き容量が不足している場合、TiKV は一時ファイルを作成しません。保護の有効性は、予約領域のサイズに関係します。予約領域のサイズは、ディスク容量の 5% とこの構成値のうち大きい方の値です。この構成項目が`0`またはサポートされている単位のゼロ値 (たとえば、 `0KiB` 、 `0MiB` 、または`0GiB` ) に設定されている場合、TiKV はこのディスク保護機能を無効にします。 - デフォルト値: `"5GiB"` - 単位: B|KB|KiB|MB|MiB|GB|GiB|TB|TiB|PB|PiB @@ -529,7 +529,7 @@ storageに関連するコンフィグレーション項目。 > **警告：** > > - `enable-ttl`を`true`または`false`に設定してください。**既存**の TiKV クラスターでは、この構成項目の値を変更**しないでください**。 `enable-ttl`値が異なる TiKV クラスターでは、使用するデータ形式が異なります。そのため、既存の TiKV クラスターでこの項目の値を変更すると、クラスターはデータを異なる形式で保存するため、TiKV クラスターを再起動すると「非 TTL で TTL を有効にできません」というエラーが発生します。 -> - `enable-ttl` TiKV クラスタ**でのみ**使用して**ください**。TiDB ノードを含むクラスタ (つまり、そのようなクラスタでは`enable-ttl`を`true`に設定する) では、 `storage.api-version = 2`が設定されていない限り、この構成項目を使用しないでください。そうしないと、データの破損や TiDB クラスタのアップグレード失敗などの重大な問題が発生します。 +> - `enable-ttl` TiKV クラスター**でのみ**使用して**ください**。TiDB ノードを含むクラスター (つまり、そのようなクラスターでは`enable-ttl`を`true`に設定する) では、 `ストレージ.api-version = 2`が設定されていない限り、この構成項目を使用しないでください。そうしないと、データの破損や TiDB クラスターのアップグレード失敗などの重大な問題が発生します。 - [TTL](/time-to-live.md) 「Time to live（有効期限）」の略です。この項目を有効にすると、TiKVはTTLに達したデータを自動的に削除します。TTLの値を設定するには、クライアント経由でデータを書き込む際のリクエストで指定する必要があります。TTLが指定されていない場合、TiKVは該当するデータを自動的に削除しません。 - デフォルト値: `false` @@ -549,13 +549,13 @@ storageに関連するコンフィグレーション項目。 ### api-version v6.1.0で追加 {#code-api-version-code-span-class-version-mark-new-in-v6-1-0-span} -- TiKVがRawKVストアとして機能する際にTiKVが使用するstorageフォーマットとインターフェースバージョン。 +- TiKVがRawKVストアとして機能する際にTiKVが使用するストレージフォーマットとインターフェースバージョン。 - お得なオプション： - `1` : API V1 を使用し、クライアントから渡されたデータをエンコードせず、そのまま保存します。バージョン 6.1.0 より前の TiKV では、デフォルトで API V1 が使用されます。 - `2` : API V2 を使用します: - データは[マルチバージョン同時実行制御 (MVCC)](/glossary.md#multi-version-concurrency-control-mvcc)形式で保存され、タイムスタンプは tikv-server によって PD (TSO) から取得されます。 - - データはさまざまな用途に応じて範囲が定められており、API V2では、単一のクラスタ内でTiDB、トランザクションKV、およびRawKVアプリケーションが共存することをサポートしています。 - - API V2 を使用する場合は、 `storage.enable-ttl = true`も同時に設定する必要があります。API V2 は TTL 機能をサポートしているため、 [`enable-ttl`](#enable-ttl)明示的に有効にする必要があります。そうしないと、 `storage.enable-ttl`が`false`にデフォルト設定されるため、競合が発生します。 + - データはさまざまな用途に応じて範囲が定められており、API V2では、単一のクラスター内でTiDB、トランザクションKV、およびRawKVアプリケーションが共存することをサポートしています。 + - API V2 を使用する場合は、 `ストレージ.enable-ttl = true`も同時に設定する必要があります。API V2 は TTL 機能をサポートしているため、 [`enable-ttl`](#enable-ttl)明示的に有効にする必要があります。そうしないと、 `ストレージ.enable-ttl`が`false`にデフォルト設定されるため、競合が発生します。 - API V2を有効にする場合、不要になったデータを再利用するために、少なくとも1つのtidb-serverインスタンスをデプロイする必要があります。このtidb-serverインスタンスは、読み取りサービスと書き込みサービスを同時に提供できます。高可用性を確保するため、複数のtidb-serverインスタンスをデプロイすることも可能です。 - API V2ではクライアント側のサポートが必要です。詳細は、API V2に対応したクライアントの取扱説明書を参照してください。 - バージョン6.2.0以降、RawKVの変更データキャプチャ（CDC）がサポートされています。RawKV [RawKV CDC](https://tikv.org/docs/latest/concepts/explore-tikv-features/cdc/cdc)を参照してください。 @@ -563,7 +563,7 @@ storageに関連するコンフィグレーション項目。 > **警告：** -> - API V1 と API V2 はstorage形式が異なります。 TiKV に TiDB データのみが含まれている場合に**のみ**、API V2 を直接有効または無効にできます。他のシナリオでは、新しいクラスターをデプロイし、 [RawKVのバックアップと復元](https://tikv.org/docs/latest/concepts/explore-tikv-features/backup-restore/)復元を使用してデータを移行する必要があります。 +> - API V1 と API V2 はストレージ形式が異なります。 TiKV に TiDB データのみが含まれている場合に**のみ**、API V2 を直接有効または無効にできます。他のシナリオでは、新しいクラスターをデプロイし、 [RawKVのバックアップと復元](https://tikv.org/docs/latest/concepts/explore-tikv-features/backup-restore/)復元を使用してデータを移行する必要があります。 > - API V2を有効にした後は、TiKVクラスターをv6.1.0より前のバージョンにダウングレードする**ことはできません**。ダウングレードすると、データ破損が発生する可能性があります。 ## txn-status-cache-capacity （v7.6.0で追加） {#code-txn-status-cache-capacity-code-span-class-version-mark-new-in-v7-6-0-span} @@ -571,9 +571,9 @@ storageに関連するコンフィグレーション項目。 - TiKVにおけるトランザクションステータスキャッシュの容量を設定します。このパラメータは変更しないでください。 - デフォルト値: `5120000` -## storage.block-cache {#storage-block-cache} +## ストレージ.block-cache {#ストレージ-block-cache} -複数の RocksDBカラムファミリー (CF) 間でブロックキャッシュを共有することに関連するコンフィグレーション項目。 +複数の RocksDBカラムファミリー (CF) 間でブロックキャッシュを共有することに関連する設定項目。 ### capacity {#code-capacity-code} @@ -581,8 +581,8 @@ storageに関連するコンフィグレーション項目。 - デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値はシステムメモリ全体のサイズの 45% です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値はシステムメモリ全体のサイズの 30% です。 + - `ストレージ.engine="raft-kv"`の場合、デフォルト値はシステムメモリ全体のサイズの 45% です。 + - `ストレージ.engine="partitioned-raft-kv"`の場合、デフォルト値はシステムメモリ全体のサイズの 30% です。 - 単位：KiB｜MiB｜GiB @@ -591,9 +591,9 @@ storageに関連するコンフィグレーション項目。 - Titanコンポーネントが使用できるブロックキャッシュ全体の割合を制御します。 - デフォルト値: `0.2` -## storage.フロー制御 {#storage-flow-control} +## ストレージ.フロー制御 {#ストレージ-flow-control} -TiKVにおけるフロー制御メカニズムに関連するコンフィグレーション項目。このメカニズムはRocksDBの書き込み停止メカニズムに代わるもので、スケジューラレイヤーでのフローを制御することで、 RaftstoreやApplyスレッドの停止によって引き起こされる二次的な障害を回避します。 +TiKVにおけるフロー制御メカニズムに関連する設定項目。このメカニズムはRocksDBの書き込み停止メカニズムに代わるもので、スケジューラレイヤーでのフローを制御することで、 RaftstoreやApplyスレッドの停止によって引き起こされる二次的な障害を回避します。 ### enable {#code-enable-code} @@ -630,9 +630,9 @@ TiKVにおけるフロー制御メカニズムに関連するコンフィグレ - KvDB の保留中の圧縮バイトがこのしきい値に達すると、フロー制御メカニズムはすべての書き込み要求を拒否し、 `ServerIsBusy`エラーを報告します。 `enable`が`true`に設定されている場合、この構成項目は`rocksdb.(defaultcf|writecf|lockcf).hard-pending-compaction-bytes-limit`を上書きします。 - デフォルト値: `"1024GiB"` -## storage.io-rate-limit {#storage-io-rate-limit} +## ストレージ.io-rate-limit {#ストレージ-io-rate-limit} -I/Oレートリミッターに関連するコンフィグレーション項目。 +I/Oレートリミッターに関連する設定項目。 ### max-bytes-per-sec {#code-max-bytes-per-sec-code} @@ -678,7 +678,7 @@ I/Oレートリミッターに関連するコンフィグレーション項目 ## ラフトストア {#raftstore} -Raftstoreに関連するコンフィグレーション項目。 +Raftstoreに関連する設定項目。 ### prevote {#code-prevote-code} @@ -687,13 +687,13 @@ Raftstoreに関連するコンフィグレーション項目。 ### capacity {#code-capacity-code} -- storage容量。データを保存できる最大サイズです。 `capacity`を指定しない場合、現在のディスクの容量が優先されます。複数の TiKV インスタンスを同じ物理ディスクにデプロイするには、このパラメータを TiKV 構成に追加します。詳細については、 [ハイブリッド展開の主要パラメータ](/hybrid-deployment-topology.md#key-parameters)を参照してください。 +- ストレージ容量。データを保存できる最大サイズです。 `capacity`を指定しない場合、現在のディスクの容量が優先されます。複数の TiKV インスタンスを同じ物理ディスクにデプロイするには、このパラメータを TiKV 構成に追加します。詳細については、 [ハイブリッド展開の主要パラメータ](/hybrid-deployment-topology.md#key-parameters)を参照してください。 - デフォルト値: `0` - 単位：KiB｜MiB｜GiB ### raftdb-path {#code-raftdb-path-code} -- Raftライブラリへのパス（デフォルトでは`storage.data-dir/raft` +- Raftライブラリへのパス（デフォルトでは`ストレージ.data-dir/raft` - デフォルト値: `""` ### raft-base-tick-interval {#code-raft-base-tick-interval-code} @@ -770,7 +770,7 @@ Raftstoreに関連するコンフィグレーション項目。 ### raft-log-compact-sync-interval v5.3で追加 {#code-raft-log-compact-sync-interval-code-span-class-version-mark-new-in-v5-3-span} -- 不要ないかだの丸太を圧縮する時間間隔 +- 不要なRaftの丸太を圧縮する時間間隔 - デフォルト値: `"2s"` - 最小値: `"0s"` @@ -794,7 +794,7 @@ Raftstoreに関連するコンフィグレーション項目。 ### raft-log-gc-size-limit {#code-raft-log-gc-size-limit-code} -- 残余いかだRaftの許容サイズに関する厳格な制限 +- 残余RaftRaftの許容サイズに関する厳格な制限 - デフォルト値：リージョンサイズの3/4 - 最小値: `0`より大きい @@ -862,8 +862,8 @@ Raftstoreに関連するコンフィグレーション項目。 - 手動圧縮の各ラウンドで一度にチェックされるリージョンの数 - デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は`100`です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`5`です。 + - `ストレージ.engine="raft-kv"`の場合、デフォルト値は`100`です。 + - `ストレージ.engine="partitioned-raft-kv"`の場合、デフォルト値は`5`です。 - 最小値: `0` ### region-compact-min-tombstones {#code-region-compact-min-tombstones-code} @@ -1031,7 +1031,7 @@ Raftstoreに関連するコンフィグレーション項目。 > **警告：** > -> クラスタのパフォーマンスに影響を与え、TiDBのガベージコレクションと互換性がないため、本番環境では整合性チェックを有効にすることは推奨され**ません**。 +> クラスターのパフォーマンスに影響を与え、TiDBのガベージコレクションと互換性がないため、本番環境では整合性チェックを有効にすることは推奨され**ません**。 - 整合性チェックがトリガーされる時間間隔。 `0`この機能が無効になっていることを意味します。 - デフォルト値: `"0s"` @@ -1202,7 +1202,7 @@ Raftstoreに関連するコンフィグレーション項目。 ## コプロセッサ {#coprocessor} -コプロセッサーに関連するコンフィグレーション項目。 +コプロセッサーに関連する設定項目。 ### split-region-on-table {#code-split-region-on-table-code} @@ -1273,7 +1273,7 @@ Raftstoreに関連するコンフィグレーション項目。 ## rocksdb {#rocksdb} -RocksDBに関連するコンフィグレーション項目 +RocksDBに関連する設定項目 ### max-background-jobs {#code-max-background-jobs-code} @@ -1351,16 +1351,16 @@ RocksDBに関連するコンフィグレーション項目 - RocksDB WAL の最大サイズは合計で、 `*.log`内の`data-dir`ファイルのサイズです。 - デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は`"4GiB"`です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`1`です。 + - `ストレージ.engine="raft-kv"`の場合、デフォルト値は`"4GiB"`です。 + - `ストレージ.engine="partitioned-raft-kv"`の場合、デフォルト値は`1`です。 ### stats-dump-period {#code-stats-dump-period-code} - 統計情報がログに出力される間隔。 - デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は`"10m"`です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`"0"`です。 + - `ストレージ.engine="raft-kv"`の場合、デフォルト値は`"10m"`です。 + - `ストレージ.engine="partitioned-raft-kv"`の場合、デフォルト値は`"0"`です。 ### compaction-readahead-size {#code-compaction-readahead-size-code} @@ -1490,8 +1490,8 @@ RocksDBに関連するコンフィグレーション項目 - デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は none で、制限なしを意味します。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値はシステムメモリ全体のサイズの 20% です。 + - `ストレージ.engine="raft-kv"`の場合、デフォルト値は none で、制限なしを意味します。 + - `ストレージ.engine="partitioned-raft-kv"`の場合、デフォルト値はシステムメモリ全体のサイズの 20% です。 - 単位：KiB｜MiB｜GiB @@ -1510,7 +1510,7 @@ RocksDBに関連するコンフィグレーション項目 ## rocksdb.titan {#rocksdb-titan} -Titanに関連するコンフィグレーション項目。 +Titanに関連する設定項目。 ### enabled {#code-enabled-code} @@ -1541,7 +1541,7 @@ Titanに関連するコンフィグレーション項目。 ## rocksdb.defaultcf | rocksdb.writecf | rocksdb.lockcf | rocksdb.raftcf {#rocksdb-defaultcf-rocksdb-writecf-rocksdb-lockcf-rocksdb-raftcf} -`rocksdb.defaultcf` 、 `rocksdb.writecf` 、および`rocksdb.lockcf`に関連するコンフィグレーション項目。 +`rocksdb.defaultcf` 、 `rocksdb.writecf` 、および`rocksdb.lockcf`に関連する設定項目。 ### block-size {#code-block-size-code} @@ -1645,14 +1645,14 @@ Titanに関連するコンフィグレーション項目。 - Memtableサイズ - `defaultcf`および`writecf`のデフォルト値: `"128MiB"` - `lockcf`のデフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は`"32MiB"`です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`"4MiB"`です。 + - `ストレージ.engine="raft-kv"`の場合、デフォルト値は`"32MiB"`です。 + - `ストレージ.engine="partitioned-raft-kv"`の場合、デフォルト値は`"4MiB"`です。 - 最小値: `0` - 単位：KiB｜MiB｜GiB ### max-write-buffer-number {#code-max-write-buffer-number-code} -- メンテーブルの最大数。 `storage.flow-control.enable`が`true`に設定されている場合、 `storage.flow-control.memtables-threshold`この設定項目を上書きします。 +- メンテーブルの最大数。 `ストレージ.flow-control.enable`が`true`に設定されている場合、 `ストレージ.flow-control.memtables-threshold`この設定項目を上書きします。 - デフォルト値: `5` - 最小値: `0` @@ -1688,8 +1688,8 @@ Titanに関連するコンフィグレーション項目。 ### level0-slowdown-writes-trigger {#code-level0-slowdown-writes-trigger-code} - L0 レジスタで書き込み停止を引き起こすファイルの最大数。 -- v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この構成項目の値は[`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって直接上書きされます。 -- バージョン 8.5.5 以降: フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この構成項目の値は、その値が`storage.flow-control.l0-files-threshold`より大きい場合にのみ、 [`storage.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。 +- v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合 ( [`ストレージ.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この構成項目の値は[`ストレージ.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって直接上書きされます。 +- バージョン 8.5.5 以降: フロー制御メカニズムが有効になっている場合 ( [`ストレージ.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この構成項目の値は、その値が`ストレージ.flow-control.l0-files-threshold`より大きい場合にのみ、 [`ストレージ.flow-control.l0-files-threshold`](/tikv-configuration-file.md#l0-files-threshold)によって上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。 - デフォルト値: `20` - 最小値: `0` @@ -1746,14 +1746,14 @@ Titanに関連するコンフィグレーション項目。 ### soft-pending-compaction-bytes-limit {#code-soft-pending-compaction-bytes-limit-code} - 保留中の圧縮バイト数のソフトリミット。 -- v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この構成項目は[`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)によって直接上書きされます。 -- バージョン 8.5.5 以降: フロー制御メカニズムが有効になっている場合 ( [`storage.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この設定項目は、 [`storage.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)値が`storage.flow-control.soft-pending-compaction-bytes-limit`より大きい場合にのみ上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。 +- v8.5.4 以前のバージョンでは、フロー制御メカニズムが有効になっている場合 ( [`ストレージ.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この構成項目は[`ストレージ.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)によって直接上書きされます。 +- バージョン 8.5.5 以降: フロー制御メカニズムが有効になっている場合 ( [`ストレージ.flow-control.enable`](/tikv-configuration-file.md#enable)が`true`の場合)、この設定項目は、 [`ストレージ.flow-control.soft-pending-compaction-bytes-limit`](/tikv-configuration-file.md#soft-pending-compaction-bytes-limit)値が`ストレージ.flow-control.soft-pending-compaction-bytes-limit`より大きい場合にのみ上書きされます。この動作により、フロー制御しきい値を上げた際に RocksDB の圧縮高速化メカニズムが弱まるのを防ぎます。 - デフォルト値: `"192GiB"` - 単位：KiB｜MiB｜GiB ### hard-pending-compaction-bytes-limit {#code-hard-pending-compaction-bytes-limit-code} -- 保留中の圧縮バイト数の上限値。 `storage.flow-control.enable` `true`に設定されている場合、 `storage.flow-control.hard-pending-compaction-bytes-limit`この設定項目を上書きします。 +- 保留中の圧縮バイト数の上限値。 `ストレージ.flow-control.enable` `true`に設定されている場合、 `ストレージ.flow-control.hard-pending-compaction-bytes-limit`この設定項目を上書きします。 - デフォルト値: `"256GiB"` - 単位：KiB｜MiB｜GiB @@ -1787,8 +1787,8 @@ Titanに関連するコンフィグレーション項目。 - `5` : TiKV v6.1以降のバージョンで読み取ることができます。フルフィルタとパーティションフィルタは、異なるスキーマを使用した、より高速で高精度なブルームフィルタ実装を使用します。 - デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は`2`です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`5`です。 + - `ストレージ.engine="raft-kv"`の場合、デフォルト値は`2`です。 + - `ストレージ.engine="partitioned-raft-kv"`の場合、デフォルト値は`5`です。 ### ttl v7.2.0の新機能 {#code-ttl-code-span-class-version-mark-new-in-v7-2-0-span} @@ -1813,7 +1813,7 @@ Titanに関連するコンフィグレーション項目。 > > Titan は`rocksdb.defaultcf`でのみ有効にできます。 `rocksdb.writecf`では Titan の有効化はサポートされていません。 -`rocksdb.defaultcf.titan`に関連するコンフィグレーション項目。 +`rocksdb.defaultcf.titan`に関連する設定項目。 ### min-blob-size {#code-min-blob-size-code} @@ -1918,7 +1918,7 @@ Titanに関連するコンフィグレーション項目。 ## raftdb {#raftdb} -`raftdb`に関連するコンフィグレーション項目 +`raftdb`に関連する設定項目 ### max-background-jobs {#code-max-background-jobs-code} @@ -1980,8 +1980,8 @@ Titanに関連するコンフィグレーション項目。 - RocksDB WALの最大サイズ合計 - デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は`"4GiB"`です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`1`です。 + - `ストレージ.engine="raft-kv"`の場合、デフォルト値は`"4GiB"`です。 + - `ストレージ.engine="partitioned-raft-kv"`の場合、デフォルト値は`1`です。 ### compaction-readahead-size {#code-compaction-readahead-size-code} @@ -2071,14 +2071,14 @@ Titanに関連するコンフィグレーション項目。 - RaftDBのログレベル - デフォルト値: `"info"` -## いかだエンジン {#raft-engine} +## Raft Engine {#raft-engine} -Raft Engineに関連するコンフィグレーション項目。 +Raft Engineに関連する設定項目。 > **注記：** > > - Raft Engineを初めて有効にすると、TiKVはRocksDBからRaft Engineにデータを転送します。そのため、TiKVが起動するまで数十秒余分に待つ必要があります。 -> - TiDB v5.4.0 のRaft Engineのデータ形式は、以前の TiDB バージョンと互換性がありません。そのため、TiDB クラスタを v5.4.0 から以前のバージョンにダウングレードする必要がある場合は、ダウングレードする**前に**、 `enable`を`false`に設定してRaft Engine を無効にし、TiKV を再起動して設定を有効にしてください。 +> - TiDB v5.4.0 のRaft Engineのデータ形式は、以前の TiDB バージョンと互換性がありません。そのため、TiDB クラスターを v5.4.0 から以前のバージョンにダウングレードする必要がある場合は、ダウングレードする**前に**、 `enable`を`false`に設定してRaft Engine を無効にし、TiKV を再起動して設定を有効にしてください。 ### enable {#code-enable-code} @@ -2171,8 +2171,8 @@ Raft Engineに関連するコンフィグレーション項目。 - `1` : TiKV v6.3.0 より前のバージョンのデフォルトのログファイルです。TiKV >= v6.1.0 で読み取ることができます。 - `2` : ログのリサイクルをサポートします。TiKV >= v6.3.0 で読み取ることができます。 - デフォルト値: - - `storage.engine="raft-kv"`の場合、デフォルト値は`2`です。 - - `storage.engine="partitioned-raft-kv"`の場合、デフォルト値は`5`です。 + - `ストレージ.engine="raft-kv"`の場合、デフォルト値は`2`です。 + - `ストレージ.engine="partitioned-raft-kv"`の場合、デフォルト値は`5`です。 ### enable-log-recycle v6.3.0の新機能 {#code-enable-log-recycle-code-span-class-version-mark-new-in-v6-3-0-span} @@ -2200,7 +2200,7 @@ Raft Engineに関連するコンフィグレーション項目。 ## 安全 {#security} -セキュリティに関連するコンフィグレーション項目。 +セキュリティに関連する設定項目。 ### ca-path {#code-ca-path-code} @@ -2233,7 +2233,7 @@ Raft Engineに関連するコンフィグレーション項目。 ## セキュリティ暗号化 {#security-encryption} -[保存時の暗号化](/encryption-at-rest.md)(TDE)に関するコンフィグレーション項目。 +[保存時の暗号化](/encryption-at-rest.md)(TDE)に関する設定項目。 ### data-encryption-method {#code-data-encryption-method-code} @@ -2263,7 +2263,7 @@ Raft Engineに関連するコンフィグレーション項目。 ## 輸入 {#import} -TiDB LightningのインポートおよびBR復元に関連するコンフィグレーション項目。 +TiDB LightningのインポートおよびBR復元に関連する設定項目。 ### num-threads {#code-num-threads-code} @@ -2377,7 +2377,7 @@ TiKVの自動圧縮の動作を設定します。 ## バックアップ {#backup} -BRバックアップに関連するコンフィグレーション項目。 +BRバックアップに関連する設定項目。 ### num-threads {#code-num-threads-code} @@ -2399,14 +2399,14 @@ BRバックアップに関連するコンフィグレーション項目。 ### enable-auto-tune v5.4.0の新機能 {#code-enable-auto-tune-code-span-class-version-mark-new-in-v5-4-0-span} -- クラスタのリソース使用率が高い場合に、バックアップタスクが使用するリソースを制限してクラスタへの影響を軽減するかどうかを制御します。詳細については、 [BRオートチューン](/br/br-auto-tune.md)を参照してください。 +- クラスターのリソース使用率が高い場合に、バックアップタスクが使用するリソースを制限してクラスターへの影響を軽減するかどうかを制御します。詳細については、 [BRオートチューン](/br/br-auto-tune.md)を参照してください。 - デフォルト値: `true` ### s3-multi-part-size v5.3.2の新機能 {#code-s3-multi-part-size-code-span-class-version-mark-new-in-v5-3-2-span} > **注記：** > -> この構成は、S3 レート制限によって引き起こされるバックアップの失敗に対処するために導入されました。この問題は[バックアップデータstorage構造の改良](/br/br-snapshot-architecture.md#structure-of-backup-files)により修正されました。したがって、この構成は v6.1.1 から非推奨となり、推奨されなくなりました。 +> この構成は、S3 レート制限によって引き起こされるバックアップの失敗に対処するために導入されました。この問題は[バックアップデータストレージ構造の改良](/br/br-snapshot-architecture.md#structure-of-backup-files)により修正されました。したがって、この構成は v6.1.1 から非推奨となり、推奨されなくなりました。 - バックアップ時にS3へのマルチパートアップロードを実行する際に使用されるパートサイズです。この設定値を調整することで、S3に送信されるリクエスト数を制御できます。 - データが S3 にバックアップされ、バックアップ ファイルがこの設定項目の値より大きい場合、 [マルチパートアップロード](https://docs.aws.amazon.com/AmazonS3/latest/API/API_UploadPart.html)が自動的に有効になります。圧縮率に基づいて、96 MiBリージョンによって生成されるバックアップ ファイルは約 10 MiB ～ 30 MiB になります。 @@ -2427,7 +2427,7 @@ BRバックアップに関連するコンフィグレーション項目。 ## ログバックアップ {#log-backup} -ログバックアップに関連するコンフィグレーション項目。 +ログバックアップに関連する設定項目。 ### v6.2.0でenable {#code-enable-code-span-class-version-mark-new-in-v6-2-0-span} @@ -2438,7 +2438,7 @@ BRバックアップに関連するコンフィグレーション項目。 - 保存するバックアップログデータのサイズ制限。 - デフォルト値: 256MiB -- 注：通常、 `file-size-limit`の値は、外部storageに表示されるバックアップファイルのサイズよりも大きくなります。これは、バックアップファイルが外部storageにアップロードされる前に圧縮されるためです。 +- 注：通常、 `file-size-limit`の値は、外部ストレージに表示されるバックアップファイルのサイズよりも大きくなります。これは、バックアップファイルが外部ストレージにアップロードされる前に圧縮されるためです。 ### initial-scan-pending-memory-quota v6.2.0 の新機能 {#code-initial-scan-pending-memory-quota-code-span-class-version-mark-new-in-v6-2-0-span} @@ -2453,7 +2453,7 @@ BRバックアップに関連するコンフィグレーション項目。 ### max-flush-interval v6.2.0で追加 {#code-max-flush-interval-code-span-class-version-mark-new-in-v6-2-0-span} -- ログバックアップにおいて、バックアップデータを外部storageに書き込む最大間隔。 +- ログバックアップにおいて、バックアップデータを外部ストレージに書き込む最大間隔。 - デフォルト値：3分 ### num-threads （v6.2.0の新機能） {#code-num-threads-code-span-class-version-mark-new-in-v6-2-0-span} @@ -2464,12 +2464,12 @@ BRバックアップに関連するコンフィグレーション項目。 ### temp-path v6.2.0 で追加されました。 {#code-temp-path-code-span-class-version-mark-new-in-v6-2-0-span} -- ログファイルが外部storageに書き込まれる前に一時的に保存されるパス。 +- ログファイルが外部ストレージに書き込まれる前に一時的に保存されるパス。 - デフォルト値: `${deploy-dir}/data/log-backup-temp` ## CDC {#cdc} -TiCDCに関連するコンフィグレーション項目。 +TiCDCに関連する設定項目。 ### min-ts-interval {#code-min-ts-interval-code} @@ -2514,7 +2514,7 @@ TiCDCに関連するコンフィグレーション項目。 ## resolved-ts {#resolved-ts} -ステイル読み取りリクエストを処理するために、解決済みのTSを維持することに関連するコンフィグレーション項目。 +ステイル読み取りリクエストを処理するために、解決済みのTSを維持することに関連する設定項目。 ### enable {#code-enable-code} @@ -2571,7 +2571,7 @@ TiCDCに関連するコンフィグレーション項目。 ## クォータ {#quota} -クォータリミッターに関連するコンフィグレーション項目。 +クォータリミッターに関連する設定項目。 ### max-delay-duration v6.0.0で追加 {#code-max-delay-duration-code-span-class-version-mark-new-in-v6-0-0-span} @@ -2581,7 +2581,7 @@ TiCDCに関連するコンフィグレーション項目。 ### フォアグラウンドクォータリミッター {#foreground-quota-limiter} -フォアグラウンドのクォータリミッターに関連するコンフィグレーション項目。 +フォアグラウンドのクォータリミッターに関連する設定項目。 TiKV がデプロイされているマシンにリソースが限られている場合、たとえば、CPU が 4V、メモリが16GB しかないとします。このような状況では、TiKV のフォアグラウンドが読み書き要求を過剰に処理し、バックグラウンドで使用される CPU リソースがこれらの要求の処理に占有され、TiKV のパフォーマンスの安定性に影響する可能性があります。この状況を回避するには、フォアグラウンドのクォータ関連の設定項目を使用して、フォアグラウンドで使用される CPU リソースを制限できます。要求がクォータ リミッターをトリガーすると、要求は TiKV が CPU リソースを解放するまでしばらく待機させられます。正確な待機時間は要求の数によって異なり、最大待機時間は[`max-delay-duration`](#max-delay-duration-new-in-v600)の値を超えません。 @@ -2606,7 +2606,7 @@ TiKV がデプロイされているマシンにリソースが限られている ### バックグラウンドクォータリミッター {#background-quota-limiter} -バックグラウンドクォータリミッターに関連するコンフィグレーション項目。 +バックグラウンドクォータリミッターに関連する設定項目。 TiKV がデプロイされているマシンにリソースが限られている場合、たとえば CPU が 4V、メモリが16GB しかない場合を考えてみましょう。このような状況では、TiKV のバックグラウンドで計算や読み書き要求が多すぎると、フォアグラウンドで使用される CPU リソースがこれらの要求の処理に占有され、TiKV のパフォーマンスの安定性に影響します。この状況を回避するには、バックグラウンドのクォータ関連の設定項目を使用して、バックグラウンドで使用される CPU リソースを制限できます。要求がクォータ リミッターをトリガーすると、TiKV が CPU リソースを解放するまで、要求はしばらく待機させられます。正確な待機時間は要求の数によって異なり、最大待機時間は[`max-delay-duration`](#max-delay-duration-new-in-v600)の値を超えません。 @@ -2638,7 +2638,7 @@ TiKV がデプロイされているマシンにリソースが限られている ## causal-ts v6.1.0の新機能 {#causal-ts-span-class-version-mark-new-in-v6-1-0-span} -TiKV API V2 が有効になっている場合にタイムスタンプを取得することに関連するコンフィグレーション項目 ( `storage.api-version = 2` )。 +TiKV API V2 が有効になっている場合にタイムスタンプを取得することに関連する設定項目 ( `ストレージ.api-version = 2` )。 書き込みレイテンシーを低減するため、TiKVは定期的にタイムスタンプのバッチをローカルに取得してキャッシュします。キャッシュされたタイムスタンプは、PDへの頻繁なアクセスを回避し、TSOサービスの一時的な障害を許容するのに役立ちます。 @@ -2646,7 +2646,7 @@ TiKV API V2 が有効になっている場合にタイムスタンプを取得 - 事前割り当て済みのTSOキャッシュサイズ（期間）。 - TiKV は、この構成項目で指定された期間に基づいて TSO キャッシュを事前割り当てします。TiKV は、前の期間に基づいて TSO の使用量を推定し、 `alloc-ahead-buffer`満たす TSO をローカルに要求してキャッシュします。 -- この構成項目は、TiKV API V2 が有効になっている場合の PD 障害の許容度を高めるためによく使用されます ( `storage.api-version = 2` )。 +- この構成項目は、TiKV API V2 が有効になっている場合の PD 障害の許容度を高めるためによく使用されます ( `ストレージ.api-version = 2` )。 - この設定項目の値を大きくすると、TSOの消費量とTiKVのメモリオーバーヘッドが増加する可能性があります。十分なTSOを確保するには、PDの設定項目[`tso-update-physical-interval`](/pd-configuration-file.md#tso-update-physical-interval)の値を下げることをお勧めします。 - テストによると、 `alloc-ahead-buffer`がデフォルト値の場合、PDリーダーが故障して別のノードに切り替わると、書き込みリクエストのレイテンシーが一時的に増加し、QPSが約15%減少します。 - ビジネスへの影響を避けるため、PDで`tso-update-physical-interval = "1ms"`を設定し、TiKVで以下の設定項目を設定してください。 @@ -2664,7 +2664,7 @@ TiKV API V2 が有効になっている場合にタイムスタンプを取得 ### renew-batch-min-size {#code-renew-batch-min-size-code} - タイムスタンプ要求におけるTSOの最小数。 -- TiKV は、前の期間のタイムスタンプ消費量に応じて、キャッシュされたタイムスタンプの数を調整します。必要な TSO が少ない場合は、TiKV は要求される TSO の数を`renew-batch-min-size`に達するまで減らします。アプリケーションで大量のバースト書き込みトラフィックが頻繁に発生する場合は、このパラメータを適切な値に設定できます。このパラメータは、単一の tikv-server のキャッシュ サイズであることに注意してください。このパラメータを大きすぎる値に設定し、クラスタに多数の tikv-server が含まれている場合、TSO の消費が速すぎることになります。 +- TiKV は、前の期間のタイムスタンプ消費量に応じて、キャッシュされたタイムスタンプの数を調整します。必要な TSO が少ない場合は、TiKV は要求される TSO の数を`renew-batch-min-size`に達するまで減らします。アプリケーションで大量のバースト書き込みトラフィックが頻繁に発生する場合は、このパラメータを適切な値に設定できます。このパラメータは、単一の tikv-server のキャッシュ サイズであることに注意してください。このパラメータを大きすぎる値に設定し、クラスターに多数の tikv-server が含まれている場合、TSO の消費が速すぎることになります。 - Grafana の**TiKV-RAW** > **Causal timestamp**パネルでは、 **TSO バッチ サイズ**は、アプリケーションのワークロードに応じて動的に調整されるローカル キャッシュされたタイムスタンプの数です。このメトリックを参照して`renew-batch-min-size`を調整できます。 - デフォルト値: `100` @@ -2676,7 +2676,7 @@ TiKV API V2 が有効になっている場合にタイムスタンプを取得 ## リソース制御 {#resource-control} -TiKVstorageレイヤーのリソース制御に関連するコンフィグレーション項目。 +TiKVストレージレイヤーのリソース制御に関連する設定項目。 ### enabled （v6.6.0で新規追加） {#code-enabled-code-span-class-version-mark-new-in-v6-6-0-span} @@ -2696,7 +2696,7 @@ TiKVstorageレイヤーのリソース制御に関連するコンフィグレー ## スプリット {#split} -[ロードベース分割](/configure-load-base-split.md)に関するコンフィグレーション項目。 +[ロードベース分割](/configure-load-base-split.md)に関する設定項目。 ### byte-threshold v5.0 で追加 {#code-byte-threshold-code-span-class-version-mark-new-in-v5-0-span} @@ -2741,7 +2741,7 @@ TiKVstorageレイヤーのリソース制御に関連するコンフィグレー ## インメモリエンジンv8.5.0の新機能 {#in-memory-engine-span-class-version-mark-new-in-v8-5-0-span} -TiKV MVCC インメモリエンジン (IME) のstorageレイヤーに関連する構成項目。 +TiKV MVCC インメモリエンジン (IME) のストレージレイヤーに関連する構成項目。 ### v8.5.0でenable {#code-enable-code-span-class-version-mark-new-in-v8-5-0-span} diff --git a/tikv-control.md b/tikv-control.md index f6cc5e23ca91e..e22e804fb98c3 100644 --- a/tikv-control.md +++ b/tikv-control.md @@ -306,9 +306,9 @@ tikv-ctl --host localhost:20160 region-properties -r 2 tikv-ctl --host ip:port compact -d kv ``` -### TiKVクラスタ全体のデータを手動で圧縮する {#compact-data-of-the-whole-tikv-cluster-manually} +### TiKVクラスター全体のデータを手動で圧縮する {#compact-data-of-the-whole-tikv-cluster-manually} -`compact-cluster`コマンドを使用して、TiKV クラスタ全体のデータを手動で圧縮します。このコマンドのフラグは、 `compact`コマンドと同じ意味と使用法を持ちます。唯一の違いは次のとおりです。 +`compact-cluster`コマンドを使用して、TiKV クラスター全体のデータを手動で圧縮します。このコマンドのフラグは、 `compact`コマンドと同じ意味と使用法を持ちます。唯一の違いは次のとおりです。 - `compact-cluster`コマンドでは、 `--pd`使用して PD のアドレスを指定し、 `tikv-ctl`クラスター内のすべての TiKV ノードをコンパクト ターゲットとして見つけられるようにします。 - `compact`コマンドでは、 `--data-dir`または`--host`使用して、単一の TiKV をコンパクト ターゲットとして指定します。 @@ -403,7 +403,7 @@ tikv-ctl --data-dir /path/to/tikv bad-regions `shared block cache`のサイズを設定します: ```shell -tikv-ctl --host ip:port modify-tikv-config -n storage.block-cache.capacity -v 10GB +tikv-ctl --host ip:port modify-tikv-config -n ストレージ.block-cache.capacity -v 10GB ``` success @@ -449,7 +449,7 @@ tikv-ctl --host ip:port modify-tikv-config -n rocksdb.rate-bytes-per-sec -v "1GB > **警告：** > > - 誤った操作が行われた場合、クラスターの復旧が困難になる可能性があります。潜在的なリスクを認識し、本番環境ではこの機能の使用を避けてください。 -> - `--all-regions`オプションを使用する場合、このコマンドはクラスタに接続されている残りのすべてのストアに対して実行する必要があります。損傷したストアを復旧する前に、これらの正常なストアがサービスの提供を停止していることを確認する必要があります。そうしないと、リージョンレプリカ内のピアリストの不整合により、 `split-region`または`remove-peer`実行した際にエラーが発生します。これにより、他のメタデータ間の不整合も発生し、最終的にはリージョンが利用できなくなります。 +> - `--all-regions`オプションを使用する場合、このコマンドはクラスターに接続されている残りのすべてのストアに対して実行する必要があります。損傷したストアを復旧する前に、これらの正常なストアがサービスの提供を停止していることを確認する必要があります。そうしないと、リージョンレプリカ内のピアリストの不整合により、 `split-region`または`remove-peer`実行した際にエラーが発生します。これにより、他のメタデータ間の不整合も発生し、最終的にはリージョンが利用できなくなります。 > - `remove-fail-stores`実行した後は、削除したノードを再起動したり、クラスターに追加したりすることはできません。そうしないと、メタデータに不整合が生じ、最終的にはリージョンが利用できなくなります。 ```shell @@ -516,7 +516,7 @@ tikv-ctl ldb --hex manifest_dump --path=/tmp/db/MANIFEST-000001 データファイルの暗号化情報をダンプするには、サブコマンド`encryption-meta dump-file`使用します。TiKV デプロイメントに`data-dir`指定するには、TiKV 構成ファイルを作成する必要があります。 # conf.toml - [storage] + [ストレージ] data-dir = "/path/to/tikv/data" `--path`オプションは、対象のデータファイルへの絶対パスまたは相対パスを指定するために使用できます。データファイルが暗号化されていない場合、コマンドは空の出力を返すことがあります。3 `--path`指定しない場合は、すべてのデータファイルの暗号化情報が出力されます。 @@ -530,7 +530,7 @@ tikv-ctl --config=./conf.toml encryption-meta dump-file --path=/path/to/tikv/dat データ暗号化キーをダンプするには、サブコマンド`encryption-meta dump-key`使用します。 `data-dir`に加えて、設定ファイルで現在使用されているマスターキーも指定する必要があります。マスターキーの設定方法については、 [保存時の暗号化](/encryption-at-rest.md)を参照してください。また、このコマンドでは`security.encryption.previous-master-key`設定は無視され、マスターキーのローテーションは実行されません。 # conf.toml - [storage] + [ストレージ] data-dir = "/path/to/tikv/data" [security.encryption.master-key] diff --git a/tikv-overview.md b/tikv-overview.md index c8b3504ee8c24..e575a04f4fe20 100644 --- a/tikv-overview.md +++ b/tikv-overview.md @@ -1,11 +1,11 @@ --- title: TiKV Overview -summary: TiKVstorageエンジンの概要。 +summary: TiKVストレージエンジンの概要。 --- # TiKVの概要 {#tikv-overview} -TiKVは、 ACID準拠のトランザクションAPIを提供する分散型トランザクションキーバリューデータベースです。RocksDBに保存される[Raftコンセンサスアルゴリズム](https://raft.github.io/raft.pdf)とコンセンサスステートの実装により、TiKVは複数のレプリカ間のデータ一貫性と高可用性を保証します。TiDB分散データベースのstorageレイヤーとして、TiKVは読み取りおよび書き込みサービスを提供し、アプリケーションから書き込まれたデータを永続化します。また、TiDBクラスターの統計データも保存します。 +TiKVは、 ACID準拠のトランザクションAPIを提供する分散型トランザクションキーバリューデータベースです。RocksDBに保存される[Raftコンセンサスアルゴリズム](https://raft.github.io/raft.pdf)とコンセンサスステートの実装により、TiKVは複数のレプリカ間のデータ一貫性と高可用性を保証します。TiDB分散データベースのストレージレイヤーとして、TiKVは読み取りおよび書き込みサービスを提供し、アプリケーションから書き込まれたデータを永続化します。また、TiDBクラスターの統計データも保存します。 ## アーキテクチャの概要 {#architecture-overview} @@ -23,9 +23,9 @@ TiKV は、Google Spanner の設計に基づいて、マルチ raft グループ TiKVは、クラスター内の各リージョンの適切なサイズを維持しようとします。リージョンのサイズは現在、デフォルトで256MiBです。このメカニズムは、PDコンポーネントがTiKVクラスター内のノード間でリージョンのバランスをとるのに役立ちます。リージョンのサイズがしきい値（デフォルトでは384MiB）を超えると、TiKVはそれを2つ以上のリージョンに分割します。リージョンのサイズがしきい値（デフォルトでは54MiB）より小さい場合、TiKVは隣接する2つの小さなリージョンを1つのリージョンに結合します。 -PD がレプリカをある TiKV ノードから別の TiKV ノードに移動する場合、まずターゲット ノードにLearnerレプリカを追加し、 LearnerレプリカのデータがLeaderレプリカのデータとほぼ同じになったら、PD はそれをFollowerレプリカに変更し、ソース ノードのFollowerレプリカを削除します。 +PD がレプリカをある TiKV ノードから別の TiKV ノードに移動する場合、まずターゲット ノードにラーナーレプリカを追加し、 ラーナーレプリカのデータがリーダーレプリカのデータとほぼ同じになったら、PD はそれをフォロワーレプリカに変更し、ソース ノードのフォロワーレプリカを削除します。 -Leaderレプリカをあるノードから別のノードに移動させる場合も同様のメカニズムが採用されます。違いは、LearnerレプリカがFollowerレプリカになった後、「Leader移行」処理が実行され、Followerレプリカが自らをLeaderに選出するための選挙を積極的に提案することです。最終的に、新しいLeaderはソースノードから古いLeaderレプリカを削除します。 +リーダーレプリカをあるノードから別のノードに移動させる場合も同様のメカニズムが採用されます。違いは、ラーナーレプリカがフォロワーレプリカになった後、「Leader移行」処理が実行され、フォロワーレプリカが自らをLeaderに選出するための選挙を積極的に提案することです。最終的に、新しいLeaderはソースノードから古いリーダーレプリカを削除します。 ## 分散トランザクション {#distributed-transaction} diff --git a/time-to-live.md b/time-to-live.md index e16685c2fb43b..ade6ca560ac5f 100644 --- a/time-to-live.md +++ b/time-to-live.md @@ -5,7 +5,7 @@ summary: Time to Live（TTL）は、TiDBデータの有効期間を行レベル # TTL (存続時間) {#ttl-time-to-live} -Time to Live（TTL）は、TiDBデータの有効期間を行レベルで管理できる機能です。TTL属性を持つテーブルの場合、TiDBは自動的にデータ有効期間をチェックし、期限切れのデータを行レベルで削除します。この機能は、一部のシナリオにおいてstorage容量を効果的に節約し、パフォーマンスを向上させることができます。 +Time to Live（TTL）は、TiDBデータの有効期間を行レベルで管理できる機能です。TTL属性を持つテーブルの場合、TiDBは自動的にデータ有効期間をチェックし、期限切れのデータを行レベルで削除します。この機能は、一部のシナリオにおいてストレージ容量を効果的に節約し、パフォーマンスを向上させることができます。 TTL の一般的なシナリオを次に示します。 @@ -159,7 +159,7 @@ SET @@global.tidb_ttl_job_schedule_window_end_time = '05:00 +0000'; > **注記：** > -> このセクションはTiDBセルフマネージドにのみ適用されます。現在、 TiDB CloudはTTLメトリクスを提供していません。 +> このセクションはTiDB Self-Managedにのみ適用されます。現在、 TiDB CloudはTTLメトリクスを提供していません。 diff --git a/tiproxy/tiproxy-configuration.md b/tiproxy/tiproxy-configuration.md index 40da0b50d3b6d..e21db005c7ae8 100644 --- a/tiproxy/tiproxy-configuration.md +++ b/tiproxy/tiproxy-configuration.md @@ -3,7 +3,7 @@ title: TiProxy Configuration File summary: TiProxy を構成する方法を学びます。 --- -# TiProxyコンフィグレーションファイル {#tiproxy-configuration-file} +# TiProxy設定ファイル {#tiproxy-configuration-file} このドキュメントでは、 TiProxyの導入と使用に関連する設定パラメータについて説明します。TiUP導入トポロジの設定については、 [tiproxy-servers の設定](/tiup/tiup-cluster-topology-reference.md#tiproxy_servers)参照してください。 @@ -39,7 +39,7 @@ skip-ca = true ### プロキシ {#proxy} -SQL ポートのコンフィグレーション。 +SQL ポートの設定。 #### addr {#code-addr-code} @@ -136,7 +136,7 @@ TiProxy の高可用性構成。 - デフォルト値: `""` - ホットリロードのサポート: いいえ -- 仮想IPアドレスをCIDR形式（例： `"10.0.1.10/24"` ）で指定します。クラスタ内で複数のTiProxyインスタンスを同じ仮想IPで構成した場合、一度にバインドできるインスタンスは1つだけです。このインスタンスがオフラインになると、別のTiProxyインスタンスが自動的に仮想IPを引き継ぎます。これにより、クライアントは常に仮想IPを介して利用可能なTiProxyに接続できるようになります。 +- 仮想IPアドレスをCIDR形式（例： `"10.0.1.10/24"` ）で指定します。クラスター内で複数のTiProxyインスタンスを同じ仮想IPで構成した場合、一度にバインドできるインスタンスは1つだけです。このインスタンスがオフラインになると、別のTiProxyインスタンスが自動的に仮想IPを引き継ぎます。これにより、クライアントは常に仮想IPを介して利用可能なTiProxyに接続できるようになります。 以下に構成例を示します。 diff --git a/tiproxy/tiproxy-deployment-topology.md b/tiproxy/tiproxy-deployment-topology.md index a8317328ed134..f739bba03b077 100644 --- a/tiproxy/tiproxy-deployment-topology.md +++ b/tiproxy/tiproxy-deployment-topology.md @@ -17,7 +17,7 @@ TiProxy は TiDB の L7 プロキシサーバーであり、接続のバラン ## トポロジ情報 {#topology-information} -| 実例 | カウント | 物理マシン構成 | IP | コンフィグレーション | +| 実例 | カウント | 物理マシン構成 | IP | 設定 | | :------------- | :--- | :------------------------------- | :----------------------------------- | :------------------------- | | TiDB | 3 | 16 VCore 32GB * 3 | 10.0.1.4
    10.0.1.5
    10.0.1.6 | デフォルトポート
    グローバルディレクトリ構成 | | PD | 3 | 4 VCore 8GB * 3 | 10.0.1.1
    10.0.1.2
    10.0.1.3 | デフォルトポート
    グローバルディレクトリ構成 | @@ -33,12 +33,12 @@ TiProxy は TiDB の L7 プロキシサーバーであり、接続のバラン TiProxy のテンプレートの詳細については、 [TiProxyトポロジのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiproxy.yaml)参照してください。 -前述の TiDB クラスタ トポロジ ファイル内の構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)参照してください。 +前述の TiDB クラスター トポロジ ファイル内の構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジ設定ファイル](/tiup/tiup-cluster-topology-reference.md)参照してください。 ### 主なパラメータ {#key-parameters} - `tiproxy_servers`のインスタンス レベル`"-host"`構成では、ドメイン名ではなく IP のみがサポートされます。 -- TiProxyパラメータの詳細な説明については、 [TiProxy のコンフィグレーション](/tiproxy/tiproxy-configuration.md)参照してください。 +- TiProxyパラメータの詳細な説明については、 [TiProxy の設定](/tiproxy/tiproxy-configuration.md)参照してください。 > **注記：** > diff --git a/tiproxy/tiproxy-load-balance.md b/tiproxy/tiproxy-load-balance.md index fc4d039c34fdc..1e6a451a93fc4 100644 --- a/tiproxy/tiproxy-load-balance.md +++ b/tiproxy/tiproxy-load-balance.md @@ -41,7 +41,7 @@ TiProxy は、SQL ポートとステータス ポートを使用して、TiDBサ 2. 少なくとも 2 つの TiProxy インスタンスをデプロイ。トランザクション ワークロードに使用する TiProxy インスタンスを[`labels`](/tiproxy/tiproxy-configuration.md#labels)で`{"app": "Order"}`に設定し、BI ワークロードに使用するインスタンスを[`labels`](/tiproxy/tiproxy-configuration.md#labels)で`{"app": "BI"}`に設定します。 3. オプション：高可用性を実現するには、少なくとも4つのTiProxyインスタンスを導入し、ワークロードごとに異なる仮想IPアドレスを設定します。例えば、トランザクションワークロード用のTiProxyインスタンス2つを仮想IP `10.0.1.10/24`に設定し、BIワークロード用のインスタンス2つを仮想IP `10.0.1.20/24`に設定します。この機能を使用するには、TiProxy v1.3.1以降が必要です。 4. TiDB インスタンスを 2 つのグループに分割し、それぞれ[`labels`](/tidb-configuration-file.md#labels)設定します。一方のグループに`"app": "Order"`ラベルを追加し、もう一方のグループに`"app": "BI"`ラベルを追加します。 -5. オプション:storageレイヤーの分離の場合は、 [配置ルール](/configure-placement-rules.md)または[リソース管理](/tidb-resource-control-ru-groups.md)構成します。 +5. オプション:ストレージレイヤーの分離の場合は、 [配置ルール](/configure-placement-rules.md)または[リソース管理](/tidb-resource-control-ru-groups.md)構成します。 6. 仮想IPが設定されている場合、トランザクションクライアントとBIクライアントはそれぞれ2つの仮想IPアドレスに接続します。仮想IPが設定されていない場合、トランザクションクライアントとBIクライアントはそれぞれ2つのTiProxyアドレスに接続します。 ラベルベースの負荷分散 @@ -149,7 +149,7 @@ TiProxyは、ラベル`zone`に基づいて自身とTiDBサーバの場所を決 TiDB Operatorを使用してデプロイされたクラスターについては、 [データの高可用性](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster#high-availability-of-data)参照してください。 -以下はクラスタ構成の例です。 +以下はクラスター構成の例です。 ```yaml component_versions: diff --git a/tiproxy/tiproxy-overview.md b/tiproxy/tiproxy-overview.md index dadee751dc5b5..a95ca4c780624 100644 --- a/tiproxy/tiproxy-overview.md +++ b/tiproxy/tiproxy-overview.md @@ -29,7 +29,7 @@ graph TD ComputeLayer --> StorageLayer - subgraph StorageLayer["storage layer"] + subgraph StorageLayer["ストレージ layer"] TiKV1[TiKV] ~~~ TiKV2[TiKV] ~~~ TiFlash[TiFlash] end @@ -89,7 +89,7 @@ TiProxyは、以下のシナリオに適しています。 TiProxyは、以下のシナリオには適していません。 - パフォーマンスに敏感: TiProxy のパフォーマンスは HAProxy や他のロードバランサーよりも低いため、TiProxy を使用する場合は、同様のパフォーマンスレベルを維持するためにより多くの CPU リソースを確保する必要があります。詳細については、 [TiProxyのパフォーマンステストレポート](/tiproxy/tiproxy-performance-test.md)を参照してください。 -- コストに敏感な場合：TiDBクラスタがハードウェアロードバランサー、仮想IP、またはKubernetesが提供するロードバランサーを使用している場合、TiProxyを追加するとコストが増加します。さらに、クラウド上のアベイラビリティゾーンにまたがってTiDBクラスタをデプロイする場合、TiProxyを追加するとアベイラビリティゾーン間のトラフィックコストも増加します。 +- コストに敏感な場合：TiDBクラスターがハードウェアロードバランサー、仮想IP、またはKubernetesが提供するロードバランサーを使用している場合、TiProxyを追加するとコストが増加します。さらに、クラウド上のアベイラビリティゾーンにまたがってTiDBクラスターをデプロイする場合、TiProxyを追加するとアベイラビリティゾーン間のトラフィックコストも増加します。 - 予期せぬTiDBサーバーのダウンタイムに対するフェイルオーバー：TiProxyは、TiDBサーバーがオフラインになった場合、または計画通りに再起動された場合にのみ、クライアント接続を維持できます。TiDBサーバーが予期せずオフラインになった場合、接続は切断されます。 TiProxyが適しているシナリオではTiProxyを使用し、アプリケーションのパフォーマンスが重要な場合はHAProxyなどの他のプロキシを使用することをお勧めします。 @@ -109,7 +109,7 @@ TiProxyが適しているシナリオではTiProxyを使用し、アプリケー ### TiProxyでクラスターを作成する {#create-a-cluster-with-tiproxy} -以下の手順では、新しいクラスタを作成する際に TiProxy をデプロイする方法について説明します。 +以下の手順では、新しいクラスターを作成する際に TiProxy をデプロイする方法について説明します。 1. TiDBインスタンスを設定します。 @@ -131,11 +131,11 @@ TiProxyが適しているシナリオではTiProxyを使用し、アプリケー - ワークロードの種類と最大 QPS に基づいて、TiProxy インスタンスのモデルと数を選択します。詳細については、 [TiProxyのパフォーマンステストレポート](/tiproxy/tiproxy-performance-test.md)参照してください。 - TiProxyインスタンスは通常TiDBサーバーインスタンスよりも少ないため、TiProxyのネットワーク帯域幅がボトルネックになりやすくなります。たとえば、AWSでは、同じシリーズのEC2インスタンスのベースラインネットワーク帯域幅はCPUコア数に比例しません。ネットワーク帯域幅がボトルネックになった場合は、TiProxyインスタンスをより多くの小さなインスタンスに分割してQPSを向上させることができます。詳細については、 [ネットワーク仕様](https://docs.aws.amazon.com/ec2/latest/instancetypes/co.html#co_network)参照してください。 - - トポロジ構成ファイルでTiProxyのバージョンを指定することをお勧めします。これにより、TiDBクラスタをアップグレードするためにコマンド[`tiup cluster upgrade`](/tiup/tiup-component-cluster-upgrade.md)を実行した際にTiProxyが自動的にアップグレードされるのを防ぎ、TiProxyのアップグレードによってクライアント接続が切断されるのを防止できます。 + - トポロジ構成ファイルでTiProxyのバージョンを指定することをお勧めします。これにより、TiDBクラスターをアップグレードするためにコマンド[`tiup cluster upgrade`](/tiup/tiup-component-cluster-upgrade.md)を実行した際にTiProxyが自動的にアップグレードされるのを防ぎ、TiProxyのアップグレードによってクライアント接続が切断されるのを防止できます。 TiProxy のテンプレートの詳細については、 [TiProxyトポロジーのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiproxy.yaml)参照してください。 - TiDBクラスタトポロジファイル内の構成項目の詳細については、 [TiUPを使用したTiDBデプロイメントのトポロジーコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)参照してください。 + TiDBクラスタートポロジファイル内の構成項目の詳細については、 [TiUPを使用したTiDBデプロイメントのトポロジー設定ファイル](/tiup/tiup-cluster-topology-reference.md)参照してください。 設定例は以下のとおりです。 @@ -161,7 +161,7 @@ TiProxyが適しているシナリオではTiProxyを使用し、アプリケー 4. TiProxyに接続します。 - クラスタがデプロイされると、TiDBサーバーポートとTiProxyポートが同時に公開されます。クライアントはTiDBサーバーに直接接続するのではなく、TiProxyポートに接続する必要があります。 + クラスターがデプロイされると、TiDBサーバーポートとTiProxyポートが同時に公開されます。クライアントはTiDBサーバーに直接接続するのではなく、TiProxyポートに接続する必要があります。 ### 既存のクラスターでTiProxyを有効にする {#enable-tiproxy-for-an-existing-cluster} @@ -231,7 +231,7 @@ TiUPを使用してTiProxyの設定を変更する場合、変更する設定項 ### TiProxyをアップグレードする {#upgrade-tiproxy} -TiProxyをデプロイする際には、TiDBクラスタをアップグレードした際にTiProxyもアップグレードされないように、TiProxyのバージョンを指定することをお勧めします。 +TiProxyをデプロイする際には、TiDBクラスターをアップグレードした際にTiProxyもアップグレードされないように、TiProxyのバージョンを指定することをお勧めします。 TiProxyをアップグレードする必要がある場合は、アップグレードコマンドに[`--tiproxy-version`](/tiup/tiup-component-cluster-upgrade.md#--tiproxy-version)を追加してTiProxyのバージョンを指定してください。 diff --git a/tiproxy/tiproxy-performance-test.md b/tiproxy/tiproxy-performance-test.md index 9800d4ef91973..c55a4067d33ab 100644 --- a/tiproxy/tiproxy-performance-test.md +++ b/tiproxy/tiproxy-performance-test.md @@ -40,7 +40,7 @@ summary: TiProxy のパフォーマンスと HAProxy との比較について学 | TiKV | バージョン8.0.0 | | システムベンチ | 1.0.17 | -### コンフィグレーション {#configuration} +### 設定 {#configuration} #### TiProxy の設定 {#tiproxy-configuration} diff --git a/tiproxy/tiproxy-traffic-replay.md b/tiproxy/tiproxy-traffic-replay.md index adcb5ee1f5fc3..ca8c9cb79ccc3 100644 --- a/tiproxy/tiproxy-traffic-replay.md +++ b/tiproxy/tiproxy-traffic-replay.md @@ -9,7 +9,7 @@ summary: TiProxy トラフィック再生機能の使用例と手順を紹介し > > 現在、TiProxy トラフィックリプレイ機能は実験的です。本番環境での使用は推奨されません。この機能は予告なく変更または削除される可能性があります。バグを発見した場合は、GitHub で[問題](https://github.com/pingcap/tiproxy/issues)報告を行ってください。 -TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのアクセストラフィックをキャプチャし、指定したレートでテストクラスタに再生することができます。この機能により、本番クラスタの実際のワークロードをテスト環境で再現し、SQL文の実行結果とパフォーマンスを検証できます。 +TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスターのアクセストラフィックをキャプチャし、指定したレートでテストクラスターに再生することができます。この機能により、本番クラスターの実際のワークロードをテスト環境で再現し、SQL文の実行結果とパフォーマンスを検証できます。 TiProxyトラフィックリプレイ @@ -31,9 +31,9 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア 1. テスト環境を準備します。 - 1. テストクラスタを作成します。詳細については、 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)参照してください。 + 1. テストクラスターを作成します。詳細については、 [TiUPを使用して TiDBクラスターをデプロイ](/production-deployment-using-tiup.md)参照してください。 2. `tiproxyctl`インストールし、 `tiproxyctl`インストールされているホストが本番とテスト環境の両方の TiProxy インスタンスに接続できることを確認します。詳細については、 [TiProxyコントロールをインストールする](/tiproxy/tiproxy-command-line-flags.md#install-tiproxy-control)参照してください。 - 3. 本番クラスタからテスト環境クラスタにデータを複製します。詳細については、 [データ移行の概要](/migration-overview.md)参照してください。 + 3. 本番クラスターからテスト環境クラスターにデータを複製します。詳細については、 [データ移行の概要](/migration-overview.md)参照してください。 4. テスト クラスターで[`ANALYZE`](/sql-statements/sql-statement-analyze-table.md)ステートメントを実行して統計を更新します。 2. [`tiproxyctl traffic capture`](/tiproxy/tiproxy-command-line-flags.md#traffic-capture)コマンドを使用して、本番クラスターの TiProxy インスタンスに接続し、トラフィックのキャプチャを開始します。 @@ -43,7 +43,7 @@ TiProxy v1.3.0以降では、TiProxyを使用してTiDB本番クラスタのア > - TiProxy は、既存の接続と新しく作成された接続を含むすべての接続のトラフィックをキャプチャします。 > - TiProxy プライマリ/セカンダリ モードで、プライマリ TiProxy インスタンスに接続します。 > - TiProxy が仮想 IP で構成されている場合は、仮想 IP アドレスに接続することをお勧めします。 - > - TiProxyのCPU使用率が高いほど、トラフィックキャプチャによるQPSへの影響が大きくなります。本番クラスタへの影響を軽減するには、CPU容量の少なくとも30%を予約することをお勧めします。これにより、平均QPSが約3%低下します。詳細なパフォーマンスデータについては、 [トラフィックキャプチャテスト](/tiproxy/tiproxy-performance-test.md#traffic-capture-test)ご覧ください。 + > - TiProxyのCPU使用率が高いほど、トラフィックキャプチャによるQPSへの影響が大きくなります。本番クラスターへの影響を軽減するには、CPU容量の少なくとも30%を予約することをお勧めします。これにより、平均QPSが約3%低下します。詳細なパフォーマンスデータについては、 [トラフィックキャプチャテスト](/tiproxy/tiproxy-performance-test.md#traffic-capture-test)ご覧ください。 > - TiProxyはトラフィックを再度キャプチャする際に、以前のキャプチャファイルを自動的に削除しません。手動で削除する必要があります。 たとえば、次のコマンドは、 `10.0.1.10:3080`の TiProxy インスタンスに接続し、1 時間のトラフィックをキャプチャし、それを TiProxy インスタンスの`/tmp/traffic`ディレクトリに保存します。 @@ -180,7 +180,7 @@ tiproxyctl traffic cancel --host 10.0.1.10 --port 3080 ## 制限事項 {#limitations} -- TiProxyは、TiProxyによってキャプチャされたトラフィックファイルの再生のみをサポートしており、他のファイル形式はサポートしていません。そのため、まずはTiProxyを使用して本番クラスタからトラフィックをキャプチャしてください。 +- TiProxyは、TiProxyによってキャプチャされたトラフィックファイルの再生のみをサポートしており、他のファイル形式はサポートしていません。そのため、まずはTiProxyを使用して本番クラスターからトラフィックをキャプチャしてください。 - TiProxyトラフィックの再生はSQLタイプのフィルタリングをサポートしておらず、DMLおよびDDL文が再生されます。そのため、再度再生する前に、クラスターデータを再生前の状態に復元する必要があります。 - TiProxy トラフィック再生では、トラフィックの再生に同じユーザー名が使用されるため、テスト[リソース管理](/tidb-resource-control-ru-groups.md)と[権限管理](/privilege-management.md)サポートされません。 - TiProxy は[`LOAD DATA`](/sql-statements/sql-statement-load-data.md)ステートメントの再生をサポートしていません。 diff --git a/tiup/tiup-cluster-no-sudo-mode.md b/tiup/tiup-cluster-no-sudo-mode.md index 6dfb8dc0e5a9a..5fddfaa6b7f17 100644 --- a/tiup/tiup-cluster-no-sudo-mode.md +++ b/tiup/tiup-cluster-no-sudo-mode.md @@ -3,7 +3,7 @@ title: Deploy and Maintain an Online TiDB Cluster Using TiUP No-sudo Mode summary: TiUP no-sudo モードを使用してオンライン TiDB クラスターを展開および管理する方法を学習します。 --- -# TiUP No-sudo モードを使用してオンライン TiDBクラスタをデプロイおよび管理 {#deploy-and-maintain-an-online-tidb-cluster-using-tiup-no-sudo-mode} +# TiUP No-sudo モードを使用してオンライン TiDBクラスターをデプロイおよび管理 {#deploy-and-maintain-an-online-tidb-cluster-using-tiup-no-sudo-mode} このドキュメントでは、 TiUP no-sudo モードを使用してクラスターをデプロイする方法について説明します。 @@ -160,7 +160,7 @@ Node Check Result Message no-sudoモードでは、 `tidb`ユーザーにはsudo権限がありません。そのため、 `tiup cluster check topology.yaml --apply --user tidb`実行しても失敗したチェック項目を自動的に修正することはできません。対象マシンで`root`ユーザーを使用して手動で修正する必要があります。 -詳細については、 [TiDB環境とシステムコンフィグレーションのチェック](/check-before-deployment.md)参照してください。ドキュメントの手順[SSH相互信頼とパスワードなしのsudoを手動で設定する](/check-before-deployment.md#manually-configure-the-ssh-mutual-trust-and-sudo-without-password)スキップする必要があることに注意してください。 +詳細については、 [TiDB環境とシステム設定のチェック](/check-before-deployment.md)参照してください。ドキュメントの手順[SSH相互信頼とパスワードなしのsudoを手動で設定する](/check-before-deployment.md#manually-configure-the-ssh-mutual-trust-and-sudo-without-password)スキップする必要があることに注意してください。 ## クラスターのデプロイと管理 {#deploy-and-manage-the-cluster} diff --git a/tiup/tiup-cluster-topology-reference.md b/tiup/tiup-cluster-topology-reference.md index 1929e27faf035..a784431a720b7 100644 --- a/tiup/tiup-cluster-topology-reference.md +++ b/tiup/tiup-cluster-topology-reference.md @@ -3,7 +3,7 @@ title: Topology Configuration File for TiDB Deployment Using TiUP summary: TiUPは、トポロジファイルを使用してTiDBのクラスタートポロジをデプロイまたは変更します。また、Prometheus、Grafana、Alertmanagerなどの監視サーバーもデプロイします。トポロジファイルには、グローバル設定、監視サービス、コンポーネントバージョンなどのセクションが含まれています。各セクションでは、対応するサービスがデプロイされるマシンとその設定を指定します。 --- -# TiUPを使用した TiDB デプロイメントのトポロジコンフィグレーションファイル {#topology-configuration-file-for-tidb-deployment-using-tiup} +# TiUPを使用した TiDB デプロイメントのトポロジ設定ファイル {#topology-configuration-file-for-tidb-deployment-using-tiup} TiUPを使用して TiDB をデプロイまたは拡張するには、クラスター トポロジを記述するトポロジ ファイル ( [サンプル](https://github.com/pingcap/tiup/blob/master/embed/examples/cluster/topology.example.yaml) ) を提供する必要があります。 @@ -16,9 +16,9 @@ TiUPを使用して TiDB クラスターをデプロイすると、Prometheus、 TiUPを使用した TiDB デプロイメントのトポロジ構成ファイルには、次のセクションが含まれる場合があります。 - [グローバル](#global) : クラスターのグローバル設定。一部の設定項目はデフォルト値を使用しますが、インスタンスごとに個別に設定できます。 -- [監視](#monitored) : 監視サービス（blackbox_exporterと`node_exporter`のコンフィグレーション。各マシンに`node_exporter`と`blackbox_exporter`デプロイされています。 +- [監視](#monitored) : 監視サービス（blackbox_exporterと`node_exporter`の設定。各マシンに`node_exporter`と`blackbox_exporter`デプロイされています。 - [サーバー構成](#server_configs) : コンポーネントのグローバル設定。各コンポーネントを個別に設定できます。インスタンスに同じ名前の設定項目がある場合は、インスタンスの設定項目が有効になります。 -- [コンポーネントバージョン](#component_versions) : コンポーネントバージョン。コンポーネントがクラスタバージョンを使用しない場合に設定します。このセクションはtiup-cluster v1.14.0で導入されました。 +- [コンポーネントバージョン](#component_versions) : コンポーネントバージョン。コンポーネントがクラスターバージョンを使用しない場合に設定します。このセクションはtiup-cluster v1.14.0で導入されました。 - [pd_servers](#pd_servers) : PDインスタンスの構成。この構成では、PDコンポーネントがデプロイされるマシンを指定します。 - [tidb_servers](#tidb_servers) : TiDBインスタンスの構成。この構成では、TiDBコンポーネントがデプロイされるマシンを指定します。 - [tikv_servers](#tikv_servers) : TiKVインスタンスの構成。この構成では、TiKVコンポーネントがデプロイされるマシンを指定します。 @@ -40,11 +40,11 @@ TiUPを使用した TiDB デプロイメントのトポロジ構成ファイル - `group` : ユーザーが所属するユーザーグループ。ユーザー作成時に指定されます。デフォルト値は``番目のフィールドの値です。指定されたグループが存在しない場合は、自動的に作成されます。 -- `systemd_mode` : クラスタのデプロイメント時にターゲットマシンで使用される`systemd`モードを指定します。デフォルト値は`system`です。 `user`に設定すると、ターゲットマシンでsudo権限は不要になり、 [TiUP no-sudo モード](/tiup/tiup-cluster-no-sudo-mode.md)使用されます。 +- `systemd_mode` : クラスターのデプロイメント時にターゲットマシンで使用される`systemd`モードを指定します。デフォルト値は`system`です。 `user`に設定すると、ターゲットマシンでsudo権限は不要になり、 [TiUP no-sudo モード](/tiup/tiup-cluster-no-sudo-mode.md)使用されます。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポートを指定します。デフォルト値は`22`です。 -- `enable_tls` : クラスタでTLSを有効にするかどうかを指定します。TLSを有効にすると、生成されたTLS証明書はコンポーネント間またはクライアントとコンポーネント間の接続に使用する必要があります。デフォルト値は`false`です。 +- `enable_tls` : クラスターでTLSを有効にするかどうかを指定します。TLSを有効にすると、生成されたTLS証明書はコンポーネント間またはクライアントとコンポーネント間の接続に使用する必要があります。デフォルト値は`false`です。 - `listen_host` : デフォルトのリスニングIPアドレスを指定します。空の場合、各インスタンスは、 `host`フィールドに`:`含まれているかどうかに基づいて、自動的に`::`または`0.0.0.0`に設​​定します。このフィールドはtiup-cluster v1.14.0で導入されました。 @@ -388,7 +388,7 @@ tikv_servers: - `log_dir` : ログディレクトリを指定します。指定されていない場合、または相対ディレクトリとして指定された場合は、 `global`で設定された`log_dir`ディレクトリに従ってログが生成されます。 -- `tmp_path` : TiFlash一時ファイルのstorageパス。デフォルト値は[ `path`または`storage.latest.dir`の最初のディレクトリ] + "/tmp"です。 +- `tmp_path` : TiFlash一時ファイルのストレージパス。デフォルト値は[ `path`または`ストレージ.latest.dir`の最初のディレクトリ] + "/tmp"です。 - `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンに[ヌマクトル](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[ヌマクトル](https://linux.die.net/man/8/numactl)使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 @@ -550,7 +550,7 @@ kvcdc_servers: - `resource_control` : サービスのリソース制御。このフィールドが設定されている場合、フィールドの内容は`global`の`resource_control`内容とマージされます（2つのフィールドが重複している場合は、このフィールドの内容が有効になります）。その後、systemd設定ファイルが生成され、 `host`で指定されたマシンに送信されます`resource_control`の設定ルールは、 `global`の`resource_control`内容と同じです。 -- `ticdc_cluster_id` : サービスに対応するTiCDCクラスタIDを指定します。このフィールドが指定されていない場合、サービスはデフォルトのTiCDCクラスタに参加します。このフィールドはTiDB v6.3.0以降のバージョンでのみ有効です。 +- `ticdc_cluster_id` : サービスに対応するTiCDCクラスターIDを指定します。このフィールドが指定されていない場合、サービスはデフォルトのTiCDCクラスターに参加します。このフィールドはTiDB v6.3.0以降のバージョンでのみ有効です。 上記のフィールドについては、デプロイメント後にこれらの構成済みフィールドを変更することはできません。 @@ -655,7 +655,7 @@ scheduling_servers: - `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンに[ヌマクトル](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[ヌマクトル](https://linux.die.net/man/8/numactl)使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 -- `storage_retention` : Prometheus監視データの保持期間。デフォルト値は`"30d"`です。 +- `ストレージ_retention` : Prometheus監視データの保持期間。デフォルト値は`"30d"`です。 - `rule_dir` : `*.rules.yml`ファイルすべてを含むローカルディレクトリを指定します。これらのファイルは、Prometheusのルールとして、クラスター構成の初期化フェーズ中にターゲットマシンに転送されます。 diff --git a/tiup/tiup-cluster.md b/tiup/tiup-cluster.md index 37916b8e3d0d9..460b18a246197 100644 --- a/tiup/tiup-cluster.md +++ b/tiup/tiup-cluster.md @@ -3,11 +3,11 @@ title: Deploy and Maintain an Online TiDB Cluster Using TiUP summary: TiUPを使用してオンライン TiDB クラスターを展開および保守する方法を学習します。 --- -# TiUPを使用してオンライン TiDBクラスタをデプロイおよび管理 {#deploy-and-maintain-an-online-tidb-cluster-using-tiup} +# TiUPを使用してオンライン TiDBクラスターをデプロイおよび管理 {#deploy-and-maintain-an-online-tidb-cluster-using-tiup} -このドキュメントでは、 TiUPクラスタコンポーネントの使用方法に焦点を当てています。オンライン展開の詳細な手順については、 [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)を参照してください。 +このドキュメントでは、 TiUPクラスターコンポーネントの使用方法に焦点を当てています。オンライン展開の詳細な手順については、 [TiUPを使用して TiDBクラスターをデプロイ](/production-deployment-using-tiup.md)を参照してください。 -ローカルテストデプロイメントで使用される[TiUP遊び場コンポーネント](/tiup/tiup-playground.md)と同様に、 TiUPクラスタコンポーネントは本番環境向けにTiDBを迅速にデプロイします。プレイグラウンドと比較して、クラスタコンポーネントはアップグレード、スケーリング、さらには運用と監査を含む、より強力な本番クラスタ管理機能を提供します。 +ローカルテストデプロイメントで使用される[TiUP遊び場コンポーネント](/tiup/tiup-playground.md)と同様に、 TiUPクラスターコンポーネントは本番環境向けにTiDBを迅速にデプロイします。プレイグラウンドと比較して、クラスターコンポーネントはアップグレード、スケーリング、さらには運用と監査を含む、より強力な本番クラスター管理機能を提供します。 クラスターコンポーネントのヘルプ情報を表示するには、次のコマンドを実行します。 @@ -171,7 +171,7 @@ tiup cluster list Starting /root/.tiup/components/cluster/v1.12.3/cluster list Name User Version Path PrivateKey ---- ---- ------- ---- ---------- - prod-cluster tidb v8.5.4 /root/.tiup/storage/cluster/clusters/prod-cluster /root/.tiup/storage/cluster/clusters/prod-cluster/ssh/id_rsa + prod-cluster tidb v8.5.4 /root/.tiup/ストレージ/cluster/clusters/prod-cluster /root/.tiup/ストレージ/cluster/clusters/prod-cluster/ssh/id_rsa ## クラスターを起動する {#start-the-cluster} @@ -222,7 +222,7 @@ PDコンポーネントの場合、 `|L`または`|UI` `Up`または`Down`に追 > **注記：** > -> このセクションでは、スケールインコマンドの構文のみを説明します。オンラインスケーリングの詳細な手順については、 [TiUPを使用して TiDBクラスタをスケールする](/scale-tidb-using-tiup.md)を参照してください。 +> このセクションでは、スケールインコマンドの構文のみを説明します。オンラインスケーリングの詳細な手順については、 [TiUPを使用して TiDBクラスターをスケールする](/scale-tidb-using-tiup.md)を参照してください。 クラスターをスケールインするとは、一部のノードをオフラインにすることを意味します。この操作により、特定のノードがクラスターから削除され、残りのファイルも削除されます。 @@ -231,7 +231,7 @@ TiKV およびTiFlashコンポーネントのオフライン プロセスは非 - TiKV およびTiFlashの場合: - TiUPクラスターは API を介してノードをオフラインにし、プロセスが完了するのを待たずに直接終了します。 - - その後、クラスタ操作に関連するコマンドが実行されると、 TiUPクラスタはオフラインになったTiKVノードまたはTiFlashノードがあるかどうかを確認します。オフラインになったノードがない場合、 TiUPクラスタは指定された操作を続行します。オフラインになったノードがある場合、 TiUPクラスタは以下の手順を実行します。 + - その後、クラスター操作に関連するコマンドが実行されると、 TiUPクラスターはオフラインになったTiKVノードまたはTiFlashノードがあるかどうかを確認します。オフラインになったノードがない場合、 TiUPクラスターは指定された操作を続行します。オフラインになったノードがある場合、 TiUPクラスターは以下の手順を実行します。 1. オフラインになったノードのサービスを停止します。 2. ノードに関連するデータ ファイルをクリーンアップします。 @@ -289,7 +289,7 @@ PD がノード上のデータを他の TiKV ノードにスケジュールす > **注記：** > -> このセクションでは、スケールアウトコマンドの構文のみを説明します。オンラインスケーリングの詳細な手順については、 [TiUPを使用して TiDBクラスタをスケールする](/scale-tidb-using-tiup.md)を参照してください。 +> このセクションでは、スケールアウトコマンドの構文のみを説明します。オンラインスケーリングの詳細な手順については、 [TiUPを使用して TiDBクラスターをスケールする](/scale-tidb-using-tiup.md)を参照してください。 スケールアウト操作にはデプロイメントと同様の内部ロジックがあります。TiUPTiUPコンポーネントは、まずノードの SSH 接続を確認し、ターゲット ノードに必要なディレクトリを作成してから、デプロイメント操作を実行し、ノード サービスを開始します。 @@ -331,7 +331,7 @@ PDをスケールアウトすると、ノードがクラスターに`join`つ追 ローリングアップグレード機能は、TiDBの分散機能を活用します。アップグレードプロセスはアプリケーションに対して可能な限り透過的に行われるため、ビジネスに影響を与えることはありません。 -アップグレード前に、 TiUPクラスタは各コンポーネントの設定ファイルが適切かどうかを確認します。適切であれば、コンポーネントはノードごとにアップグレードされます。適切でない場合、 TiUPはエラーを報告して終了します。処理はノードによって異なります。 +アップグレード前に、 TiUPクラスターは各コンポーネントの設定ファイルが適切かどうかを確認します。適切であれば、コンポーネントはノードごとにアップグレードされます。適切でない場合、 TiUPはエラーを報告して終了します。処理はノードによって異なります。 ### 異なるノードに対する操作 {#operations-for-different-nodes} @@ -381,7 +381,7 @@ tiup cluster upgrade tidb-test v8.5.4 ## 構成を更新する {#update-configuration} -コンポーネント構成を動的に更新する場合、 TiUPクラスタコンポーネントは各クラスタの現在の構成を保存します。この構成を編集するには、 `tiup cluster edit-config `コマンドを実行します。例： +コンポーネント構成を動的に更新する場合、 TiUPクラスターコンポーネントは各クラスターの現在の構成を保存します。この構成を編集するには、 `tiup cluster edit-config `コマンドを実行します。例： ```bash tiup cluster edit-config prod-cluster @@ -476,7 +476,7 @@ tiup cluster patch test-cluster /tmp/tidb-hotfix.tar.gz -N 172.16.4.5:4000 ## TiDB Ansibleクラスターをインポートする {#import-tidb-ansible-cluster} -TiUPがリリースされる前は、TiDBクラスタのデプロイにTiDB Ansibleがよく使用されていました。TiDB AnsibleによってデプロイされたクラスタをTiUPが引き継ぐようにするには、 `import`コマンドを使用します。 +TiUPがリリースされる前は、TiDBクラスターのデプロイにTiDB Ansibleがよく使用されていました。TiDB AnsibleによってデプロイされたクラスターをTiUPが引き継ぐようにするには、 `import`コマンドを使用します。 `import`コマンドの使用方法は次のとおりです。 @@ -548,7 +548,7 @@ tiup cluster audit 4BLhr0 ## TiDB クラスター内のホストでコマンドを実行する {#run-commands-on-a-host-in-the-tidb-cluster} -TiDBクラスタ内のホストでコマンドを実行するには、 `exec`コマンドを使用します。3 `exec`のコマンドの使用方法は次のとおりです。 +TiDBクラスター内のホストでコマンドを実行するには、 `exec`コマンドを使用します。3 `exec`のコマンドの使用方法は次のとおりです。 ```bash Usage: @@ -572,7 +572,7 @@ Global Flags: tiup cluster exec test-cluster --command='ls /tmp' ``` -## クラスタコントローラー {#cluster-controllers} +## クラスターコントローラー {#cluster-controllers} TiUPがリリースされる前は、 `tidb-ctl` `pd-ctl`のツールを使用してクラスターを制御できました。これら`tikv-ctl`ツールをより簡単にダウンロードして使用できるように、 TiUPはそれらをオールインワンコンポーネント`ctl`に統合しています。 @@ -635,11 +635,11 @@ CPUスレッド数チェック、メモリサイズチェック、ディスク チェック実行時にフラグ`--apply`が指定されている場合、プログラムは失敗した項目を自動的に修復します。自動修復は、設定またはシステムパラメータの変更によって調整可能な一部の項目に限定されます。修復されないその他の項目は、実際の状況に応じて手動で処理する必要があります。 -クラスタのデプロイには環境チェックは必須ではありません。本番環境では、デプロイ前に環境チェックを実施し、すべてのチェック項目に合格することをお勧めします。すべてのチェック項目に合格していない場合、クラスタはデプロイされ正常に動作しますが、最適なパフォーマンスが得られない可能性があります。 +クラスターのデプロイには環境チェックは必須ではありません。本番環境では、デプロイ前に環境チェックを実施し、すべてのチェック項目に合格することをお勧めします。すべてのチェック項目に合格していない場合、クラスターはデプロイされ正常に動作しますが、最適なパフォーマンスが得られない可能性があります。 -## システムのネイティブSSHクライアントを使用してクラスタに接続します {#use-the-system-s-native-ssh-client-to-connect-to-cluster} +## システムのネイティブSSHクライアントを使用してクラスターに接続します {#use-the-system-s-native-ssh-client-to-connect-to-cluster} -クラスタマシン上で実行される上記のすべての操作は、 TiUPに組み込まれたSSHクライアントを使用してクラスタに接続し、コマンドを実行します。ただし、シナリオによっては、制御マシンシステムにネイティブなSSHクライアントを使用してクラスタ操作を実行する必要がある場合もあります。例： +クラスターマシン上で実行される上記のすべての操作は、 TiUPに組み込まれたSSHクライアントを使用してクラスターに接続し、コマンドを実行します。ただし、シナリオによっては、制御マシンシステムにネイティブなSSHクライアントを使用してクラスター操作を実行する必要がある場合もあります。例： - 認証にSSHプラグインを使用するには - カスタマイズされたSSHクライアントを使用するには @@ -683,7 +683,7 @@ TiUPデータは、ユーザーのホームディレクトリ内の`.tiup`ディ > > 制御マシンのディスク破損などの異常な状況によってTiUPデータが失われないように、 `.tiup`ディレクトリを定期的にバックアップすることをお勧めします。 -## クラスタの展開とO&Mのためのメタファイルのバックアップと復元 {#back-up-and-restore-meta-files-for-cluster-deployment-and-o-x26-m} +## クラスターの展開とO&Mのためのメタファイルのバックアップと復元 {#back-up-and-restore-meta-files-for-cluster-deployment-and-o-x26-m} 運用保守（O&M）に使用するメタファイルが失われると、 TiUPを使用したクラスターの管理が失敗します。以下のコマンドを実行して、メタファイルを定期的にバックアップすることをお勧めします。 diff --git a/tiup/tiup-command-telemetry.md b/tiup/tiup-command-telemetry.md index 862e4dc2092e7..23d9202202a18 100644 --- a/tiup/tiup-command-telemetry.md +++ b/tiup/tiup-command-telemetry.md @@ -1,6 +1,6 @@ --- title: tiup telemetry -summary: TiUPテレメトリはv1.11.3でデフォルトで無効化されました。使用状況情報は収集されず、PingCAPと共有もされません。有効化すると、テレメトリ識別子とコマンド実行ステータスが共有されます。クラスタの詳細は共有されません。「tiup telemetry」コマンドを使用し、status、reset、enable、disableなどのサブコマンドでテレメトリを制御してください。 +summary: TiUPテレメトリはv1.11.3でデフォルトで無効化されました。使用状況情報は収集されず、PingCAPと共有もされません。有効化すると、テレメトリ識別子とコマンド実行ステータスが共有されます。クラスターの詳細は共有されません。「tiup telemetry」コマンドを使用し、status、reset、enable、disableなどのサブコマンドでテレメトリを制御してください。 --- # tiup telemetry {#tiup-telemetry} @@ -17,7 +17,7 @@ TiUPテレメトリが有効になっている場合、 TiUPコマンドの実 - クラスターの正確な名前 - クラスタートポロジー -- クラスタ構成ファイル +- クラスター構成ファイル TiUP は`tiup telemetry`コマンドを使用してテレメトリを制御します。 diff --git a/tiup/tiup-component-cluster-audit-cleanup.md b/tiup/tiup-component-cluster-audit-cleanup.md index 4e5f16433031e..82dcb5ad4b4dd 100644 --- a/tiup/tiup-component-cluster-audit-cleanup.md +++ b/tiup/tiup-component-cluster-audit-cleanup.md @@ -35,4 +35,4 @@ tiup cluster audit cleanup [flags] clean audit log successfully ``` -[<< 前のページに戻る - TiUPクラスタコマンドリスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンドリスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-audit.md b/tiup/tiup-component-cluster-audit.md index 8481ad452e688..25fbc9eacb095 100644 --- a/tiup/tiup-component-cluster-audit.md +++ b/tiup/tiup-component-cluster-audit.md @@ -1,6 +1,6 @@ --- title: tiup cluster audit -summary: tiup cluster auditコマンドは、すべてのクラスタで実行されたコマンドの履歴と各コマンドの実行ログを表示します。[audit-id] を指定した場合、対応する実行ログが出力されます。指定しない場合は、ID、時間、コマンドのフィールドを含む表が時系列の逆順に出力されます。 -h, --helpオプションはヘルプ情報を出力、デフォルトでは無効になっています。 +summary: tiup cluster auditコマンドは、すべてのクラスターで実行されたコマンドの履歴と各コマンドの実行ログを表示します。[audit-id] を指定した場合、対応する実行ログが出力されます。指定しない場合は、ID、時間、コマンドのフィールドを含む表が時系列の逆順に出力されます。 -h, --helpオプションはヘルプ情報を出力、デフォルトでは無効になっています。 --- # tiup cluster audit {#tiup-cluster-audit} @@ -32,4 +32,4 @@ tiup cluster audit [audit-id] [flags] - 時間: レコードに対応するコマンドの実行時間 - コマンド: レコードに対応するコマンド -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-check.md b/tiup/tiup-component-cluster-check.md index 55976a72fcf75..3ae836c344ac1 100644 --- a/tiup/tiup-component-cluster-check.md +++ b/tiup/tiup-component-cluster-check.md @@ -1,11 +1,11 @@ --- title: tiup cluster check -summary: TiUP クラスタは、ハードウェアとソフトウェア環境が本番の要件を満たしていることを確認するための「check」コマンドを提供します。OSバージョン、CPUサポート、時刻同期、システム制限などをチェックします。オプションには、自動修復や、CPUコア数、メモリサイズ、ディスクパフォーマンスのチェックの有効化などがあります。チェックを実行するには、「tiup cluster check [flags]」コマンドを使用します。自動修復を試行するには、「--apply」を使用します。チェックするノードとロールを指定するには、「-N, --node」および「-R, --role」を使用します。特定のチェックを有効にするには、「--enable-cpu」、「--enable-disk」、「--enable-mem」を使用します。 +summary: TiUP クラスターは、ハードウェアとソフトウェア環境が本番の要件を満たしていることを確認するための「check」コマンドを提供します。OSバージョン、CPUサポート、時刻同期、システム制限などをチェックします。オプションには、自動修復や、CPUコア数、メモリサイズ、ディスクパフォーマンスのチェックの有効化などがあります。チェックを実行するには、「tiup cluster check [flags]」コマンドを使用します。自動修復を試行するには、「--apply」を使用します。チェックするノードとロールを指定するには、「-N, --node」および「-R, --role」を使用します。特定のチェックを有効にするには、「--enable-cpu」、「--enable-disk」、「--enable-mem」を使用します。 --- # tiup cluster check {#tiup-cluster-check} -正式な本番環境では、稼働前に一連のチェックを実施し、クラスターが最高のパフォーマンスを発揮していることを確認する必要があります。手動チェックの手順を簡素化するため、 TiUP クラスタは、指定されたクラスターのターゲットマシンのハードウェアおよびソフトウェア環境が正常に動作するための要件を満たしているかどうかを確認するための`check`のコマンドを提供しています。 +正式な本番環境では、稼働前に一連のチェックを実施し、クラスターが最高のパフォーマンスを発揮していることを確認する必要があります。手動チェックの手順を簡素化するため、 TiUP クラスターは、指定されたクラスターのターゲットマシンのハードウェアおよびソフトウェア環境が正常に動作するための要件を満たしているかどうかを確認するための`check`のコマンドを提供しています。 ## チェック項目一覧 {#list-of-check-items} @@ -100,7 +100,7 @@ ext4パーティションのマウントオプションを確認してくださ ### CPUコア数 {#cpu-core-number} -対象マシンのCPU情報を確認してください。本番のクラスタでは、CPU論理コアの数が16以上であることが推奨されます。 +対象マシンのCPU情報を確認してください。本番のクラスターでは、CPU論理コアの数が16以上であることが推奨されます。 > **注記：** > @@ -162,7 +162,7 @@ tiup cluster check [flags] > tiup cluster check scale-out.yml --cluster --apply --user root [-p] [-i /home/root/.ssh/gcp_rsa] > ``` -### - クラスタ {#cluster} +### - クラスター {#cluster} - チェックがデプロイ済みのクラスターを対象としていることを示します。 - データ型: `BOOLEAN` @@ -228,7 +228,7 @@ tiup cluster check [flags] > **注記：** > -> このオプションは、 `-cluster`オプションが false の場合にのみ有効です。それ以外の場合、このオプションの値は、クラスタデプロイメントのトポロジファイルで指定されたユーザー名に固定されます。 +> このオプションは、 `-cluster`オプションが false の場合にのみ有効です。それ以外の場合、このオプションの値は、クラスターデプロイメントのトポロジファイルで指定されたユーザー名に固定されます。 ### -i, --identity_file {#i-identity-file} @@ -238,7 +238,7 @@ tiup cluster check [flags] > **注記：** > -> このオプションは、 `--cluster`オプションが false の場合にのみ有効です。それ以外の場合、このオプションの値は`${TIUP_HOME}/storage/cluster/clusters//ssh/id_rsa`に固定されます。 +> このオプションは、 `--cluster`オプションが false の場合にのみ有効です。それ以外の場合、このオプションの値は`${TIUP_HOME}/ストレージ/cluster/clusters//ssh/id_rsa`に固定されます。 ### -p, --パスワード {#p-password} @@ -263,4 +263,4 @@ tiup cluster check [flags] - `Result` : チェック結果（合格、警告、不合格） - `Message` : 結果の説明 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-clean.md b/tiup/tiup-component-cluster-clean.md index 4ac5dbfb01a86..5f144c4add427 100644 --- a/tiup/tiup-component-cluster-clean.md +++ b/tiup/tiup-component-cluster-clean.md @@ -64,4 +64,4 @@ tiup cluster clean [flags] tiup-clusterの実行ログ。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-deploy.md b/tiup/tiup-component-cluster-deploy.md index 28323d22d9f08..b7f6b84fe2bca 100644 --- a/tiup/tiup-component-cluster-deploy.md +++ b/tiup/tiup-component-cluster-deploy.md @@ -1,6 +1,6 @@ --- title: tiup cluster deploy -summary: tiup cluster deployコマンドは、クラスタ名、バージョン、トポロジファイルなどのオプションを指定して新しいクラスタをデプロイするために使用されます。追加オプションには、ユーザー、IDファイル、パスワード、構成チェックの無視、ラベルのスキップ、ユーザー作成のスキップ、ヘルプなどがあります。出力はデプロイメントログです。 +summary: tiup cluster deployコマンドは、クラスター名、バージョン、トポロジファイルなどのオプションを指定して新しいクラスターをデプロイするために使用されます。追加オプションには、ユーザー、IDファイル、パスワード、構成チェックの無視、ラベルのスキップ、ユーザー作成のスキップ、ヘルプなどがあります。出力はデプロイメントログです。 --- # tiup cluster deploy {#tiup-cluster-deploy} @@ -46,14 +46,14 @@ tiup cluster deploy [flags] ### --no-labels {#no-labels} - このオプションはラベル チェックをスキップするために使用されます。 -- 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、PDがクラスタトポロジを学習できないため、同じ物理マシン上の異なるTiKVノードにリージョンの複数のレプリカをスケジュールし、その物理マシンを単一のポイントにしてしまうというリスクが生じます。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)参照してください。 +- 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、PDがクラスタートポロジを学習できないため、同じ物理マシン上の異なるTiKVノードにリージョンの複数のレプリカをスケジュールし、その物理マシンを単一のポイントにしてしまうというリスクが生じます。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)参照してください。 - テスト環境では、このリスクが重要になる可能性があるため、 `--no-labels`使用してチェックをスキップできます。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 ### --skip-create-user {#skip-create-user} -- クラスタのデプロイメント中、 tiup-cluster はトポロジファイルで指定されたユーザー名が存在するかどうかを確認します。存在しない場合は、ユーザー名を作成します。このチェックをスキップするには、 `--skip-create-user`オプションを使用します。 +- クラスターのデプロイメント中、 tiup-cluster はトポロジファイルで指定されたユーザー名が存在するかどうかを確認します。存在しない場合は、ユーザー名を作成します。このチェックをスキップするには、 `--skip-create-user`オプションを使用します。 - データ型: `BOOLEAN` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 @@ -67,4 +67,4 @@ tiup cluster deploy [flags] デプロイメント ログ。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-destroy.md b/tiup/tiup-component-cluster-destroy.md index b0019307ad2c4..3f7bc2765e2a4 100644 --- a/tiup/tiup-component-cluster-destroy.md +++ b/tiup/tiup-component-cluster-destroy.md @@ -23,7 +23,7 @@ tiup cluster destroy [flags] ### --force {#force} -- 場合によっては、クラスタ内の一部のノードがダウンし、SSH経由でノードに接続して操作できなくなることがあります。このような場合は、 `--force`オプションを使用してこれらのエラーを無視できます。 +- 場合によっては、クラスター内の一部のノードがダウンし、SSH経由でノードに接続して操作できなくなることがあります。このような場合は、 `--force`オプションを使用してこれらのエラーを無視できます。 - データ型: `Boolean` - このオプションはデフォルトで無効になっており、デフォルト値は`false`です。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないかのいずれかを選択します。 @@ -49,4 +49,4 @@ tiup cluster destroy [flags] tiup-clusterの実行ログ。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-disable.md b/tiup/tiup-component-cluster-disable.md index bb6b5b1caa9e6..aa7f89e9e46fb 100644 --- a/tiup/tiup-component-cluster-disable.md +++ b/tiup/tiup-component-cluster-disable.md @@ -1,11 +1,11 @@ --- title: tiup cluster disable -summary: tiup cluster disable`コマンドは、マシンの再起動後にクラスタサービスの自動有効化を無効にするために使用されます。指定されたノードで`systemctl disable `を実行します。オプションには、ノードを指定するための-Nとロールを指定するための-Rがあります。出力はtiup-clusterの実行ログです。 +summary: tiup cluster disable`コマンドは、マシンの再起動後にクラスターサービスの自動有効化を無効にするために使用されます。指定されたノードで`systemctl disable `を実行します。オプションには、ノードを指定するための-Nとロールを指定するための-Rがあります。出力はtiup-clusterの実行ログです。 --- # tiup cluster disable {#tiup-cluster-disable} -クラスタサービスが配置されているマシンを再起動すると、クラスタサービスは自動的に有効化されます。クラスタサービスの自動有効化を無効にするには、コマンド`tiup cluster disable`使用します。このコマンドは、指定されたノードでコマンド`systemctl disable `を実行し、サービスの自動有効化を無効にします。 +クラスターサービスが配置されているマシンを再起動すると、クラスターサービスは自動的に有効化されます。クラスターサービスの自動有効化を無効にするには、コマンド`tiup cluster disable`使用します。このコマンドは、指定されたノードでコマンド`systemctl disable `を実行し、サービスの自動有効化を無効にします。 ## 構文 {#syntax} @@ -19,7 +19,7 @@ tiup cluster disable [flags] ### -N, --node {#n-node} -- サービスの自動有効化を無効にするノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスタステータステーブルの最初の列から取得できます。 +- サービスの自動有効化を無効にするノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup cluster display`](/tiup/tiup-component-cluster-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 - データ型: `STRINGS` - このオプションがコマンドで指定されていない場合、すべてのノードの自動有効化はデフォルトで無効になります。 @@ -47,4 +47,4 @@ tiup cluster disable [flags] tiup-clusterの実行ログ。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-display.md b/tiup/tiup-component-cluster-display.md index cd152717f670d..bfd26feff52f0 100644 --- a/tiup/tiup-component-cluster-display.md +++ b/tiup/tiup-component-cluster-display.md @@ -1,11 +1,11 @@ --- title: tiup cluster display -summary: tiup cluster displayコマンドは、クラスタ内の各コンポーネントの動作状況を効率的に表示します。ダッシュボード情報、ノードステータス、CPUおよびメモリ使用率などを表示するオプションが用意されています。出力には、クラスタ名、バージョン、SSHクライアントの種類、ダッシュボードアドレス、ノードの詳細を含む表が含まれます。ノードのサービスステータスは、「稼働中」、「停止中」、「廃棄済み」、「オフライン保留中」、「不明」のいずれかになります。 +summary: tiup cluster displayコマンドは、クラスター内の各コンポーネントの動作状況を効率的に表示します。ダッシュボード情報、ノードステータス、CPUおよびメモリ使用率などを表示するオプションが用意されています。出力には、クラスター名、バージョン、SSHクライアントの種類、ダッシュボードアドレス、ノードの詳細を含む表が含まれます。ノードのサービスステータスは、「稼働中」、「停止中」、「廃棄済み」、「オフライン保留中」、「不明」のいずれかになります。 --- # tiup cluster display {#tiup-cluster-display} -クラスタ内の各コンポーネントの動作状況を確認したい場合、各マシンに1台ずつログインするのは明らかに非効率的です。そこで、 tiup-clusterは、この作業を効率的に実行するための`tiup cluster display`コマンドを提供します。 +クラスター内の各コンポーネントの動作状況を確認したい場合、各マシンに1台ずつログインするのは明らかに非効率的です。そこで、 tiup-clusterは、この作業を効率的に実行するための`tiup cluster display`コマンドを提供します。 ## 構文 {#syntax} @@ -101,4 +101,4 @@ tiup cluster display [flags] ノードのサービスステータスはPDのスケジューリング情報から取得されます。詳細については[情報収集](/tidb-scheduling.md#information-collection)参照してください。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-edit-config.md b/tiup/tiup-component-cluster-edit-config.md index 7c67418a72e1e..f1fd5c9e67e7d 100644 --- a/tiup/tiup-component-cluster-edit-config.md +++ b/tiup/tiup-component-cluster-edit-config.md @@ -1,11 +1,11 @@ --- title: tiup cluster edit-config -summary: tiup cluster edit-config` コマンドを使用すると、デプロイメント後にクラスタ構成を変更できます。エディタを使用して、`$EDITOR` 環境変数で指定されたトポロジファイルを変更できます。構成の変更時にマシンを追加または削除することはできないことに注意してください。コマンド実行後、構成はコントロールマシン上でのみ変更されるため、`tiup cluster reload` を実行して構成を再読み込みする必要があります。 +summary: tiup cluster edit-config` コマンドを使用すると、デプロイメント後にクラスター構成を変更できます。エディタを使用して、`$EDITOR` 環境変数で指定されたトポロジファイルを変更できます。構成の変更時にマシンを追加または削除することはできないことに注意してください。コマンド実行後、構成はコントロールマシン上でのみ変更されるため、`tiup cluster reload` を実行して構成を再読み込みする必要があります。 --- # tiup cluster edit-config {#tiup-cluster-edit-config} -クラスタのデプロイ後にクラスタ設定を変更する必要がある場合は、 `tiup cluster edit-config`コマンドを使用してエディタを起動し、クラスタの[トポロジファイル](/tiup/tiup-cluster-topology-reference.md)編集できます。このエディタは、デフォルトで`$EDITOR`環境変数に指定されています。7 環境変数が存在しない場合は、 `$EDITOR`エディタ`vi`使用されます。 +クラスターのデプロイ後にクラスター設定を変更する必要がある場合は、 `tiup cluster edit-config`コマンドを使用してエディタを起動し、クラスターの[トポロジファイル](/tiup/tiup-cluster-topology-reference.md)編集できます。このエディタは、デフォルトで`$EDITOR`環境変数に指定されています。7 環境変数が存在しない場合は、 `$EDITOR`エディタ`vi`使用されます。 > **注記：** > @@ -33,4 +33,4 @@ tiup cluster edit-config [flags] - コマンドが正常に実行された場合、出力はありません。 - 変更できないフィールドを誤って変更した場合、ファイルを保存するとエラーが表示され、再度編集する必要があることが通知されます。変更できないフィールドについては、 [トポロジファイル](/tiup/tiup-cluster-topology-reference.md)参照してください。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-enable.md b/tiup/tiup-component-cluster-enable.md index 34434e7c003b2..bd25f5da3a130 100644 --- a/tiup/tiup-component-cluster-enable.md +++ b/tiup/tiup-component-cluster-enable.md @@ -1,15 +1,15 @@ --- title: tiup cluster enable -summary: tiup cluster enable` コマンドは、マシンの再起動後にクラスタサービスを自動的に有効化するために使用されます。このコマンドは、指定されたノードで `systemctl enable ` を実行します。オプションには、自動有効化するノードまたはロールの指定が含まれます。また、`-h, --help` オプションはヘルプ情報を出力。出力はtiup-clusterの実行ログです。 +summary: tiup cluster enable` コマンドは、マシンの再起動後にクラスターサービスを自動的に有効化するために使用されます。このコマンドは、指定されたノードで `systemctl enable ` を実行します。オプションには、自動有効化するノードまたはロールの指定が含まれます。また、`-h, --help` オプションはヘルプ情報を出力。出力はtiup-clusterの実行ログです。 --- # tiup cluster enable {#tiup-cluster-enable} -`tiup cluster enable`コマンドは、マシンの再起動後にクラスタサービスを自動的に有効化するように設定するために使用されます。このコマンドは、指定されたノードで`systemctl enable `実行することで、サービスの自動有効化を有効にします。 +`tiup cluster enable`コマンドは、マシンの再起動後にクラスターサービスを自動的に有効化するように設定するために使用されます。このコマンドは、指定されたノードで`systemctl enable `実行することで、サービスの自動有効化を有効にします。 > **注記：** > -> すべてのクラスタをシャットダウンして再起動すると、サービスの起動順序はノードのオペレーティングシステムの起動順序によって決定されます。再起動順序が正しくない場合、再起動後のクラスタでもサービスを提供できない場合があります。例えば、TiKVが最初に起動されているのにPDが起動していない場合、PDが見つからない状態でTiKVを複数回再起動すると、systemdは処理を中止します。 +> すべてのクラスターをシャットダウンして再起動すると、サービスの起動順序はノードのオペレーティングシステムの起動順序によって決定されます。再起動順序が正しくない場合、再起動後のクラスターでもサービスを提供できない場合があります。例えば、TiKVが最初に起動されているのにPDが起動していない場合、PDが見つからない状態でTiKVを複数回再起動すると、systemdは処理を中止します。 ## 構文 {#syntax} @@ -51,4 +51,4 @@ tiup cluster enable [flags] tiup-clusterの実行ログ。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-help.md b/tiup/tiup-component-cluster-help.md index 9ef4fc98d9b50..cb19801d49c17 100644 --- a/tiup/tiup-component-cluster-help.md +++ b/tiup/tiup-component-cluster-help.md @@ -25,4 +25,4 @@ tiup cluster help [command] [flags] `[command]`またはtiup-clusterのヘルプ情報。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-import.md b/tiup/tiup-component-cluster-import.md index 87bbb39ca21b1..c413c77fe0bef 100644 --- a/tiup/tiup-component-cluster-import.md +++ b/tiup/tiup-component-cluster-import.md @@ -1,15 +1,15 @@ --- title: tiup cluster import -summary: TiUP クラスタは、TiDB AnsibleからTiUPにTiDBクラスターを転送して管理するための「import」コマンドを提供しています。特定の構成のクラスターでは「import」を使用しないでください。インポートプロセスをカスタマイズするには、「--dir」や「--rename」などのオプションを使用してください。 +summary: TiUP クラスターは、TiDB AnsibleからTiUPにTiDBクラスターを転送して管理するための「import」コマンドを提供しています。特定の構成のクラスターでは「import」を使用しないでください。インポートプロセスをカスタマイズするには、「--dir」や「--rename」などのオプションを使用してください。 --- # tiup cluster import {#tiup-cluster-import} -TiDB v4.0より前のバージョンでは、TiDBクラスターは主にTiDB Ansibleを使用してデプロイされていました。TiDB v4.0以降のリリースでは、 TiUP クラスタは、クラスターを管理用のtiup-clusterコンポーネントに転送するためのコマンド`import`を提供します。 +TiDB v4.0より前のバージョンでは、TiDBクラスターは主にTiDB Ansibleを使用してデプロイされていました。TiDB v4.0以降のリリースでは、 TiUP クラスターは、クラスターを管理用のtiup-clusterコンポーネントに転送するためのコマンド`import`を提供します。 > **注記：** > -> - TiDB Ansible設定を管理用にTiUPにインポートした後は、クラスタ操作にTiDB Ansibleを使用し**ないでください**。メタ情報の不一致により競合が発生する可能性があります。 +> - TiDB Ansible設定を管理用にTiUPにインポートした後は、クラスター操作にTiDB Ansibleを使用し**ないでください**。メタ情報の不一致により競合が発生する可能性があります。 > - TiDB Ansible を使用してデプロイされたクラスターが次のいずれかの状況にある場合は、 `import`コマンドを使用しないでください。 > - TLS暗号化が有効になっているクラスター > - 純粋な KV クラスター (TiDB インスタンスのないクラスター) @@ -17,7 +17,7 @@ TiDB v4.0より前のバージョンでは、TiDBクラスターは主にTiDB An > - Sparkが有効になっているクラスター > - TiDB Lightning/TiKVインポーターが有効になっているクラスター > - 監視メトリックを収集するために古いモード`push`をまだ使用しているクラスター (デフォルト モード`pull`を変更しない場合は、 `import`コマンドの使用がサポートされます) -> - デフォルト以外のポート（ `group_vars`ディレクトリに設定されているポートは互換性がある）が`node_exporter_port` / `blackbox_exporter_port`を使用して`inventory.ini`構成ファイルで個別に設定されているクラスタ +> - デフォルト以外のポート（ `group_vars`ディレクトリに設定されているポートは互換性がある）が`node_exporter_port` / `blackbox_exporter_port`を使用して`inventory.ini`構成ファイルで個別に設定されているクラスター > - TiDB Ansibleを使用してデプロイしたクラスター内の一部のノードに監視コンポーネントがデプロイされていない場合は、まずTiDB Ansibleを使用して`inventory.ini`ファイルの`monitored_servers`セクションに対応するノード情報を追加し、その後`deploy.yaml`プレイブックを使用して監視コンポーネントを完全にデプロイする必要があります。そうしないと、クラスターをTiUPにインポートした後にメンテナンス操作を実行すると、監視コンポーネントの不足によりエラーが発生する可能性があります。 ## 構文 {#syntax} @@ -50,7 +50,7 @@ tiup cluster import [flags] - TiDB Ansible が配置されているディレクトリ内のファイルのバックアップを無効にするかどうかを制御します。 - データ型: `BOOLEAN` -- このオプションはデフォルトで値`false`に設定されており、無効になっています。インポートが成功すると、オプション`-dir`で指定されたディレクトリ内のすべてのデータがディレクトリ`${TIUP_HOME}/.tiup/storage/cluster/clusters/{cluster-name}/ansible-backup`にバックアップされます。このディレクトリに複数のインベントリファイルがある場合（複数のクラスタがデプロイされている場合）、このオプションを有効にすることをお勧めします。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 +- このオプションはデフォルトで値`false`に設定されており、無効になっています。インポートが成功すると、オプション`-dir`で指定されたディレクトリ内のすべてのデータがディレクトリ`${TIUP_HOME}/.tiup/ストレージ/cluster/clusters/{cluster-name}/ansible-backup`にバックアップされます。このディレクトリに複数のインベントリファイルがある場合（複数のクラスターがデプロイされている場合）、このオプションを有効にすることをお勧めします。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 ### --rename {#rename} @@ -68,4 +68,4 @@ tiup cluster import [flags] インポート プロセスのログを表示します。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-list.md b/tiup/tiup-component-cluster-list.md index 4e000a13746f1..3c23f5ca53312 100644 --- a/tiup/tiup-component-cluster-list.md +++ b/tiup/tiup-component-cluster-list.md @@ -1,6 +1,6 @@ --- title: tiup cluster list -summary: tiup-cluster は、同一の制御マシンを用いた複数のクラスタのデプロイをサポートします。tiup cluster list` コマンドは、現在ログインしているユーザーがデプロイしたすべてのクラスタを出力します。デプロイされたクラスタのデータは `~/.tiup/ storage/cluster/clusters/` ディレクトリに保存されます。ユーザーは、クラスタ名、デプロイユーザー、バージョン、パス、クラスタへの接続に使用された秘密鍵を確認できます。 +summary: tiup-cluster は、同一の制御マシンを用いた複数のクラスターのデプロイをサポートします。tiup cluster list` コマンドは、現在ログインしているユーザーがデプロイしたすべてのクラスターを出力します。デプロイされたクラスターのデータは `~/.tiup/ ストレージ/cluster/clusters/` ディレクトリに保存されます。ユーザーは、クラスター名、デプロイユーザー、バージョン、パス、クラスターへの接続に使用された秘密鍵を確認できます。 --- # tiup cluster list {#tiup-cluster-list} @@ -9,7 +9,7 @@ tiup-cluster は、同じコントロールマシンを使用して複数のク > **注記：** > -> デプロイされたクラスターのデータはデフォルトで`~/.tiup/storage/cluster/clusters/`ディレクトリに保存されるため、同じコントロール マシン上で、現在ログインしているユーザーは他のユーザーがデプロイしたクラスターを表示できません。 +> デプロイされたクラスターのデータはデフォルトで`~/.tiup/ストレージ/cluster/clusters/`ディレクトリに保存されるため、同じコントロール マシン上で、現在ログインしているユーザーは他のユーザーがデプロイしたクラスターを表示できません。 ## 構文 {#syntax} @@ -32,7 +32,7 @@ tiup cluster list [flags] - 名前: クラスター名 - ユーザー: デプロイメントユーザー - バージョン: クラスターのバージョン -- パス: 制御マシン上のクラスタ展開データのパス +- パス: 制御マシン上のクラスター展開データのパス - PrivateKey: クラスターへの接続に使用される秘密鍵のパス -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-meta-backup.md b/tiup/tiup-component-cluster-meta-backup.md index 15f21cd043b20..79f7375b4b813 100644 --- a/tiup/tiup-component-cluster-meta-backup.md +++ b/tiup/tiup-component-cluster-meta-backup.md @@ -1,11 +1,11 @@ --- title: tiup cluster meta backup -summary: TiUPメタファイルは、クラスタの運用と保守に不可欠です。定期的にファイルをバックアップするには、tiup cluster meta backup`コマンドを使用してください。クラスタ名を確認するには、`tiup dm listコマンドを使用してください。`--file`オプションでターゲットディレクトリを指定してください。ヘルプ情報を表示するには、`-h, --helpコマンドを使用してください。出力には、tiup-clusterの実行ログが含まれます。 +summary: TiUPメタファイルは、クラスターの運用と保守に不可欠です。定期的にファイルをバックアップするには、tiup cluster meta backup`コマンドを使用してください。クラスター名を確認するには、`tiup dm listコマンドを使用してください。`--file`オプションでターゲットディレクトリを指定してください。ヘルプ情報を表示するには、`-h, --helpコマンドを使用してください。出力には、tiup-clusterの実行ログが含まれます。 --- -# tiup クラスタメタバックアップ {#tiup-cluster-meta-backup} +# tiup クラスターメタバックアップ {#tiup-cluster-meta-backup} -TiUPメタファイルはクラスタの運用保守（OM）に使用されます。このファイルが失われると、 TiUPを使用してクラスタを管理できなくなります。このような状況を回避するには、 `tiup cluster meta backup`コマンドを使用してTiUPメタファイルを定期的にバックアップしてください。 +TiUPメタファイルはクラスターの運用保守（OM）に使用されます。このファイルが失われると、 TiUPを使用してクラスターを管理できなくなります。このような状況を回避するには、 `tiup cluster meta backup`コマンドを使用してTiUPメタファイルを定期的にバックアップしてください。 ## 構文 {#syntax} @@ -31,4 +31,4 @@ TiUPメタ バックアップ ファイルを保存するターゲット ディ tiup-clusterの実行ログ。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-meta-restore.md b/tiup/tiup-component-cluster-meta-restore.md index 13584759c100c..425343073f28c 100644 --- a/tiup/tiup-component-cluster-meta-restore.md +++ b/tiup/tiup-component-cluster-meta-restore.md @@ -3,7 +3,7 @@ title: tiup cluster meta restore summary: TiUPメタファイルを復元するには、クラスター名とバックアップファイルのパスを指定して「tiup cluster meta restore」コマンドを使用します。復元操作は現在のメタファイルを上書きするため、ファイルが失われた場合にのみ実行してください。「-h」または「--help」オプションを指定するとヘルプ情報が出力。出力には、 tiup-clusterの実行ログが含まれます。 --- -# tiup クラスタ メタ リストア {#tiup-cluster-meta-restore} +# tiup クラスター メタ リストア {#tiup-cluster-meta-restore} TiUPメタ ファイルを復元するには、 `tiup cluster meta restore`コマンドを使用してバックアップ ファイルから復元できます。 @@ -32,4 +32,4 @@ tiup cluster meta restore [flags] tiup-clusterの実行ログ。 -[<< 前のページに戻る - TiUPクラスタコマンドリスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンドリスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-patch.md b/tiup/tiup-component-cluster-patch.md index 4174aa4776772..8b0330e790225 100644 --- a/tiup/tiup-component-cluster-patch.md +++ b/tiup/tiup-component-cluster-patch.md @@ -8,7 +8,7 @@ summary: tiup cluster patch` コマンドを使用すると、実行中のクラ クラスターの実行中にサービスのバイナリを動的に置き換える必要がある場合（つまり、置き換えプロセス中もクラスターを利用可能な状態に保つ必要がある場合）、 `tiup cluster patch`コマンドを使用できます。コマンドの実行後、 TiUP は以下の処理を実行します。 - 置換用のバイナリ パッケージをターゲット マシンにアップロードします。 -- ターゲット サービスが TiKV やTiFlashなどのstorageサービスの場合、 TiUP はまず API 経由で関連ノードをオフラインにします。 +- ターゲット サービスが TiKV やTiFlashなどのストレージサービスの場合、 TiUP はまず API 経由で関連ノードをオフラインにします。 - 対象サービスを停止します。 - バイナリ パッケージを解凍し、サービスを置き換えます。 - 対象サービスを開始します。 @@ -71,7 +71,7 @@ tiup cluster patch [flags] ### --overwrite {#overwrite} -- 特定のコンポーネント（TiDBやTiKVなど）にパッチを適用した後、TiUPクラスタがそのコンポーネントをスケールアウトすると、 TiUPはデフォルトで元のコンポーネントバージョンを使用します。将来クラスタがスケールアウトする際にパッチを適用したバージョンを使用するには、コマンドでオプション`--overwrite`指定する必要があります。 +- 特定のコンポーネント（TiDBやTiKVなど）にパッチを適用した後、TiUPクラスターがそのコンポーネントをスケールアウトすると、 TiUPはデフォルトで元のコンポーネントバージョンを使用します。将来クラスターがスケールアウトする際にパッチを適用したバージョンを使用するには、コマンドでオプション`--overwrite`指定する必要があります。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 @@ -121,4 +121,4 @@ tiup cluster patch [flags] tiup-clusterの実行ログ。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-prune.md b/tiup/tiup-component-cluster-prune.md index d2861a528e077..574a156280b26 100644 --- a/tiup/tiup-component-cluster-prune.md +++ b/tiup/tiup-component-cluster-prune.md @@ -25,4 +25,4 @@ tiup cluster prune [flags] クリーンアッププロセスのログ。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-reload.md b/tiup/tiup-component-cluster-reload.md index 55f0b371960c5..64ea53c5e9b69 100644 --- a/tiup/tiup-component-cluster-reload.md +++ b/tiup/tiup-component-cluster-reload.md @@ -1,11 +1,11 @@ --- title: tiup cluster reload -summary: tiup cluster reload` コマンドは、変更されたクラスタ構成を適用し、サービスを再起動するために使用されます。`--force` で強制実行、`--transfer-timeout` で転送タイムアウトを設定、` --ignore-config-check で設定チェックを無視、` -N 、 --node でノードを指定、` -R 、 --role でロールを指定、`--skip-restart` で再起動をスキップできます。出力はtiup-clusterの実行ログです。 +summary: tiup cluster reload` コマンドは、変更されたクラスター構成を適用し、サービスを再起動するために使用されます。`--force` で強制実行、`--transfer-timeout` で転送タイムアウトを設定、` --ignore-config-check で設定チェックを無視、` -N 、 --node でノードを指定、` -R 、 --role でロールを指定、`--skip-restart` で再起動をスキップできます。出力はtiup-clusterの実行ログです。 --- # tiup cluster reload {#tiup-cluster-reload} -[クラスタ構成の変更](/tiup/tiup-component-cluster-edit-config.md)後、設定を有効にするには、 `tiup cluster reload`コマンドを使用してクラスタをリロードする必要があります。このコマンドは、制御マシンの設定をサービスが稼働しているリモートマシンに公開し、アップグレードプロセスに従ってサービスを順番に再起動します。再起動プロセス中もクラスタは引き続き利用可能です。 +[クラスター構成の変更](/tiup/tiup-component-cluster-edit-config.md)後、設定を有効にするには、 `tiup cluster reload`コマンドを使用してクラスターをリロードする必要があります。このコマンドは、制御マシンの設定をサービスが稼働しているリモートマシンに公開し、アップグレードプロセスに従ってサービスを順番に再起動します。再起動プロセス中もクラスターは引き続き利用可能です。 ## 構文 {#syntax} @@ -103,4 +103,4 @@ tiup cluster reload [flags] tiup-clusterの実行ログ。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-rename.md b/tiup/tiup-component-cluster-rename.md index 0ad094b9ebb46..22c3779a40e05 100644 --- a/tiup/tiup-component-cluster-rename.md +++ b/tiup/tiup-component-cluster-rename.md @@ -35,4 +35,4 @@ tiup cluster rename [flags] tiup-clusterの実行ログ。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-replay.md b/tiup/tiup-component-cluster-replay.md index c8dbe3c43a955..d443da08d5a3c 100644 --- a/tiup/tiup-component-cluster-replay.md +++ b/tiup/tiup-component-cluster-replay.md @@ -25,4 +25,4 @@ tiup cluster replay [flags] ``に対応するコマンドの出力。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-restart.md b/tiup/tiup-component-cluster-restart.md index 3d5f21c21bee6..dae7b48b4a6b3 100644 --- a/tiup/tiup-component-cluster-restart.md +++ b/tiup/tiup-component-cluster-restart.md @@ -51,4 +51,4 @@ tiup cluster restart [flags] サービスの再起動プロセスのログ。 -[<< 前のページに戻る - TiUPクラスタコマンドリスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンドリスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-scale-in.md b/tiup/tiup-component-cluster-scale-in.md index 7d5d71942058b..485cd468d739a 100644 --- a/tiup/tiup-component-cluster-scale-in.md +++ b/tiup/tiup-component-cluster-scale-in.md @@ -1,6 +1,6 @@ --- title: tiup cluster scale-in -summary: 「tiup cluster scale-in」コマンドは、指定されたノードをオフラインにし、クラスタから削除し、残りのファイルを削除することでクラスタをスケールインするために使用されます。TiKVやTiFlashなどのコンポーネントは非同期的に処理されるため、チェックとクリーンアップのための追加手順が必要です。このコマンドには、ノードの指定、強制削除、転送タイムアウト、ヘルプ情報などのオプションも含まれています。 +summary: 「tiup cluster scale-in」コマンドは、指定されたノードをオフラインにし、クラスターから削除し、残りのファイルを削除することでクラスターをスケールインするために使用されます。TiKVやTiFlashなどのコンポーネントは非同期的に処理されるため、チェックとクリーンアップのための追加手順が必要です。このコマンドには、ノードの指定、強制削除、転送タイムアウト、ヘルプ情報などのオプションも含まれています。 --- # tiup cluster scale-in {#tiup-cluster-scale-in} @@ -13,7 +13,7 @@ TiKV およびTiFlashコンポーネントは非同期的にオフラインに - TiKV およびTiFlashコンポーネントの場合: - 1. TiUPクラスタはAPI を介してノードをオフラインにし、プロセスが完了するのを待たずにすぐに終了します。 + 1. TiUPクラスターはAPI を介してノードをオフラインにし、プロセスが完了するのを待たずにすぐに終了します。 2. スケールインされているノードのステータスを確認するには、 `tiup cluster display`コマンドを実行し、ステータスが`Tombstone`なるまで待つ必要があります。 3. ステータス`Tombstone`のノードをクリーンアップするには、コマンド`tiup cluster prune`実行する必要があります。コマンド`tiup cluster prune`は以下の操作を実行します。 @@ -23,8 +23,8 @@ TiKV およびTiFlashコンポーネントは非同期的にオフラインに その他のコンポーネントの場合: -- PD コンポーネントをオフラインにする場合、 TiUP クラスタ はAPI を介して指定されたノードをクラスターからすばやく削除し、指定された PD ノードのサービスを停止し、ノードから関連データ ファイルを削除します。 -- 他のコンポーネントを停止する場合、 TiUP クラスタ はノード サービスを直接停止し、指定されたノードから関連データ ファイルを削除します。 +- PD コンポーネントをオフラインにする場合、 TiUP クラスター はAPI を介して指定されたノードをクラスターからすばやく削除し、指定された PD ノードのサービスを停止し、ノードから関連データ ファイルを削除します。 +- 他のコンポーネントを停止する場合、 TiUP クラスター はノード サービスを直接停止し、指定されたノードから関連データ ファイルを削除します。 ## 構文 {#syntax} @@ -44,7 +44,7 @@ tiup cluster scale-in [flags] ### --force {#force} -- 指定されたノードをクラスタから強制的に削除するかどうかを制御します。オフラインにするノードのホストがダウンしている場合、SSH経由でノードに接続して操作を行うことができないことがあります。その場合は、 `--force`オプションを使用してノードをクラスタから強制的に削除できます。 +- 指定されたノードをクラスターから強制的に削除するかどうかを制御します。オフラインにするノードのホストがダウンしている場合、SSH経由でノードに接続して操作を行うことができないことがあります。その場合は、 `--force`オプションを使用してノードをクラスターから強制的に削除できます。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 @@ -72,4 +72,4 @@ tiup cluster scale-in [flags] スケールイン プロセスのログを表示します。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-scale-out.md b/tiup/tiup-component-cluster-scale-out.md index 2c50b0e80f702..daf4b73f7358c 100644 --- a/tiup/tiup-component-cluster-scale-out.md +++ b/tiup/tiup-component-cluster-scale-out.md @@ -1,11 +1,11 @@ --- title: tiup cluster scale-out -summary: tiup cluster scale-outコマンドは、クラスタに新しいノードを追加するために使用されます。このコマンドは、新しいノードへのSSH接続を確立し、必要なディレクトリを作成し、設定を更新します。オプションには、ユーザー名（-u）、IDファイル（-i）、パスワード（-p）、ラベルチェックをスキップする--no-labels 、ユーザーチェックをスキップする --skip-create-user 、ヘルプ（-h）があります。出力はスケールアウトのログです。 +summary: tiup cluster scale-outコマンドは、クラスターに新しいノードを追加するために使用されます。このコマンドは、新しいノードへのSSH接続を確立し、必要なディレクトリを作成し、設定を更新します。オプションには、ユーザー名（-u）、IDファイル（-i）、パスワード（-p）、ラベルチェックをスキップする--no-labels 、ユーザーチェックをスキップする --skip-create-user 、ヘルプ（-h）があります。出力はスケールアウトのログです。 --- # tiup cluster scale-out {#tiup-cluster-scale-out} -`tiup cluster scale-out`コマンドはクラスタのスケールアウトに使用されます。クラスタのスケールアウトの内部ロジックは、クラスタのデプロイメントと同様です。tiup tiup-clusterコンポーネントは、まず新しいノードへの SSH 接続を確立し、ターゲットノードに必要なディレクトリを作成し、その後デプロイメントを実行してサービスを起動します。 +`tiup cluster scale-out`コマンドはクラスターのスケールアウトに使用されます。クラスターのスケールアウトの内部ロジックは、クラスターのデプロイメントと同様です。tiup tiup-clusterコンポーネントは、まず新しいノードへの SSH 接続を確立し、ターゲットノードに必要なディレクトリを作成し、その後デプロイメントを実行してサービスを起動します。 PD がスケールアウトされると、参加操作によって新しい PD ノードがクラスターに追加され、PD に関連付けられているサービスの構成が更新され、他のサービスは直接開始されてクラスターに追加されます。 @@ -42,14 +42,14 @@ tiup cluster scale-out [flags] ### --no-labels {#no-labels} - このオプションはラベル チェックをスキップするために使用されます。 -- 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、リスクが生じます。PDはクラスタトポロジを把握していないため、同じ物理マシン上の異なるTiKVノードにリージョンのレプリカを複数スケジュールしてしまう可能性があり、その結果、この物理マシンが単一障害点となります。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)参照してください。 +- 2つ以上のTiKVノードを同じ物理マシンにデプロイすると、リスクが生じます。PDはクラスタートポロジを把握していないため、同じ物理マシン上の異なるTiKVノードにリージョンのレプリカを複数スケジュールしてしまう可能性があり、その結果、この物理マシンが単一障害点となります。このリスクを回避するには、ラベルを使用して、同じリージョンを同じマシンにスケジュールしないようにPDに指示することができます。ラベルの設定については、 [トポロジラベルによるレプリカのスケジュール](/schedule-replicas-by-topology-labels.md)参照してください。 - テスト環境では、このリスクは問題にならない可能性があり、 `--no-labels`使用してチェックをスキップできます。 - データ型: `BOOLEAN` - デフォルト: false ### --skip-create-user {#skip-create-user} -- クラスタのデプロイメント中、 tiup-cluster はトポロジファイルで指定されたユーザー名が存在するかどうかを確認します。存在しない場合は、ユーザー名を作成します。このチェックをスキップするには、 `--skip-create-user`オプションを使用します。 +- クラスターのデプロイメント中、 tiup-cluster はトポロジファイルで指定されたユーザー名が存在するかどうかを確認します。存在しない場合は、ユーザー名を作成します。このチェックをスキップするには、 `--skip-create-user`オプションを使用します。 - データ型: `BOOLEAN` - デフォルト: false @@ -63,4 +63,4 @@ tiup cluster scale-out [flags] スケールアウトのログ。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-start.md b/tiup/tiup-component-cluster-start.md index 216b4d9576399..fdb7fe6877932 100644 --- a/tiup/tiup-component-cluster-start.md +++ b/tiup/tiup-component-cluster-start.md @@ -19,11 +19,11 @@ tiup cluster start [flags] ### --init {#init} -クラスタを安全に起動します。クラスタを初めて起動する場合は、このオプションを使用することをお勧めします。この方法では、起動時にTiDBのルートユーザーのパスワードが生成され、コマンドラインインターフェースにパスワードが返されます。 +クラスターを安全に起動します。クラスターを初めて起動する場合は、このオプションを使用することをお勧めします。この方法では、起動時にTiDBのルートユーザーのパスワードが生成され、コマンドラインインターフェースにパスワードが返されます。 > **注記：** > -> - TiDBクラスタを安全に起動した後は、パスワードなしでrootユーザーを使用してデータベースにログインすることはできません。そのため、今後のログインのために、コマンドラインから返されるパスワードを記録しておく必要があります。 +> - TiDBクラスターを安全に起動した後は、パスワードなしでrootユーザーを使用してデータベースにログインすることはできません。そのため、今後のログインのために、コマンドラインから返されるパスワードを記録しておく必要があります。 > - パスワードは一度だけ生成されます。パスワードを記録していない場合、または忘れた場合は、 [`root`パスワードを忘れた](/user-account-management.md#forget-the-root-password)を参照してパスワードを変更してください。 ### -N, --node {#n-node} @@ -56,4 +56,4 @@ tiup cluster start [flags] サービスを開始したログ。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-stop.md b/tiup/tiup-component-cluster-stop.md index 8c92dacd4f177..c7856441ded1b 100644 --- a/tiup/tiup-component-cluster-stop.md +++ b/tiup/tiup-component-cluster-stop.md @@ -51,4 +51,4 @@ tiup cluster stop [flags] サービスを停止したログ。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-template.md b/tiup/tiup-component-cluster-template.md index 15d282273ff89..6f7cbf48e1655 100644 --- a/tiup/tiup-component-cluster-template.md +++ b/tiup/tiup-component-cluster-template.md @@ -1,6 +1,6 @@ --- title: tiup cluster template -summary: tiup cluster templateコマンドは、クラスタデプロイメント用のトポロジファイルを準備するために使用されます。デフォルト、詳細、ローカル、またはマルチDCトポロジテンプレートを出力するオプションがあります。出力は、デプロイメント用のトポロジファイルにリダイレクトできます。 +summary: tiup cluster templateコマンドは、クラスターデプロイメント用のトポロジファイルを準備するために使用されます。デフォルト、詳細、ローカル、またはマルチDCトポロジテンプレートを出力するオプションがあります。出力は、デプロイメント用のトポロジファイルにリダイレクトできます。 --- # tiup cluster template {#tiup-cluster-template} @@ -48,4 +48,4 @@ tiup cluster template [flags] 指定されたオプションに従ってトポロジ テンプレートを出力します。これは、デプロイメントのためにトポロジ ファイルにリダイレクトできます。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster-tls.md b/tiup/tiup-component-cluster-tls.md index 438b403866729..4e706b6cf5f49 100644 --- a/tiup/tiup-component-cluster-tls.md +++ b/tiup/tiup-component-cluster-tls.md @@ -1,11 +1,11 @@ --- title: tiup cluster tls -summary: tiup cluster tls` コマンドは、クラスタコンポーネント間の TLS (トランスポート層Security) を有効または無効にするために使用されます。 +summary: tiup cluster tls` コマンドは、クラスターコンポーネント間の TLS (トランスポート層Security) を有効または無効にするために使用されます。 --- # TIUP クラスター TLS {#tiup-cluster-tls} -`tiup cluster tls`コマンドは、クラスタコンポーネント間で TLS (トランスポート層Security) を有効にするために使用されます。このコマンドは、自己署名証明書を自動的に生成し、クラスタ内の各ノードに配布します。 +`tiup cluster tls`コマンドは、クラスターコンポーネント間で TLS (トランスポート層Security) を有効にするために使用されます。このコマンドは、自己署名証明書を自動的に生成し、クラスター内の各ノードに配布します。 ## 構文 {#syntax} @@ -17,7 +17,7 @@ tiup cluster tls [flags] > **注記：** > -> 現在、 `tiup cluster tls`コマンドは、単一の PD ノードを持つクラスタでのみ TLS の有効化または無効化をサポートしています。複数の PD ノードを持つクラスタの場合、TLS ステータスの切り替えによって PD ノード間で通信例外が発生する可能性があるため、 `tiup cluster tls`コマンドを直接実行するとエラーが返されます。複数の PD ノードを持つクラスタで TLS を有効化または無効化するには、まず PD ノードを 1 つのノードに[`scale-in`](/tiup/tiup-component-cluster-scale-in.md)から、 `tiup cluster tls`コマンドを実行してください。 +> 現在、 `tiup cluster tls`コマンドは、単一の PD ノードを持つクラスターでのみ TLS の有効化または無効化をサポートしています。複数の PD ノードを持つクラスターの場合、TLS ステータスの切り替えによって PD ノード間で通信例外が発生する可能性があるため、 `tiup cluster tls`コマンドを直接実行するとエラーが返されます。複数の PD ノードを持つクラスターで TLS を有効化または無効化するには、まず PD ノードを 1 つのノードに[`scale-in`](/tiup/tiup-component-cluster-scale-in.md)から、 `tiup cluster tls`コマンドを実行してください。 ## オプション {#options} diff --git a/tiup/tiup-component-cluster-upgrade.md b/tiup/tiup-component-cluster-upgrade.md index 78fc9203fda7f..6c1ccb05a95d5 100644 --- a/tiup/tiup-component-cluster-upgrade.md +++ b/tiup/tiup-component-cluster-upgrade.md @@ -13,7 +13,7 @@ summary: tiup cluster upgradeコマンドは、指定したクラスターを特 tiup cluster upgrade [flags] ``` -- `` : 操作対象のクラスタ名。クラスタ名を忘れた場合は、 [クラスターリスト](/tiup/tiup-component-cluster-list.md)コマンドで確認できます。 +- `` : 操作対象のクラスター名。クラスター名を忘れた場合は、 [クラスターリスト](/tiup/tiup-component-cluster-list.md)コマンドで確認できます。 - `` : アップグレード先のバージョン（例： `v8.5.3` ）。現在、現在のクラスターよりも上位のバージョンへのアップグレードのみが許可されており、ダウングレードは許可されていません。また、ナイトリーバージョンへのアップグレードも許可されていません。 ## オプション {#options} @@ -70,7 +70,7 @@ tiup cluster upgrade [flags] ### --tikv-cdc-バージョン {#tikv-cdc-version} -- TiKV CDCのバージョンを指定します。このオプションを設定すると、TiKV CDCのバージョンはクラスタのバージョンと一致しなくなります。 +- TiKV CDCのバージョンを指定します。このオプションを設定すると、TiKV CDCのバージョンはクラスターのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、TiKV CDC のバージョンはクラスターのバージョンと一致し続けます。 @@ -88,7 +88,7 @@ tiup cluster upgrade [flags] ### --tiproxy バージョン {#tiproxy-version} -- TiProxyのバージョンを指定します。このオプションを設定すると、TiProxyのバージョンはクラスタのバージョンと一致しなくなります。 +- TiProxyのバージョンを指定します。このオプションを設定すると、TiProxyのバージョンはクラスターのバージョンと一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、TiProxy のバージョンはクラスターのバージョンと一致したままになります。 @@ -106,7 +106,7 @@ tiup cluster upgrade [flags] ### --blackbox-exporter-version {#blackbox-exporter-version} -- Blackbox Exporterのバージョンを指定します。このオプションを設定すると、Blackbox Exporterのバージョンとクラスタのバージョンが一致しなくなります。 +- Blackbox Exporterのバージョンを指定します。このオプションを設定すると、Blackbox Exporterのバージョンとクラスターのバージョンが一致しなくなります。 - データ型: `STRINGS` - このオプションが設定されていない場合、Blackbox Exporter のバージョンはクラスターのバージョンと一致したままになります。 @@ -153,4 +153,4 @@ tiup cluster upgrade [flags] アップグレードの進行状況のログ。 -[<< 前のページに戻る - TiUPクラスタコマンド リスト](/tiup/tiup-component-cluster.md#command-list) +[<< 前のページに戻る - TiUPクラスターコマンド リスト](/tiup/tiup-component-cluster.md#command-list) diff --git a/tiup/tiup-component-cluster.md b/tiup/tiup-component-cluster.md index 6d614edd15e46..be34043aefce6 100644 --- a/tiup/tiup-component-cluster.md +++ b/tiup/tiup-component-cluster.md @@ -1,11 +1,11 @@ --- title: TiUP Cluster -summary: TiUP クラスタは、 Golangで記述されたTiUPのクラスタ管理コンポーネントです。TiDBクラスタのデプロイ、起動、シャットダウン、破棄、エラスティックスケーリング、アップグレード、 TiUPクラスタパラメータの管理など、日常的な運用とメンテナンスに使用されます。TiUP クラスタを使用するための構文は「tiup cluster [コマンド] [フラグ]」です。サポートされているコマンドには、import、template、check、deploy、list、display、start、stop、restart、scale-in、scale-out、upgrade、prune、edit-config、reload、patch、rename、clean、destroy、audit、replay、enable、disable、meta backup、meta restore、helpなどがあります。 +summary: TiUP クラスターは、 Golangで記述されたTiUPのクラスター管理コンポーネントです。TiDBクラスターのデプロイ、起動、シャットダウン、破棄、エラスティックスケーリング、アップグレード、 TiUPクラスターパラメータの管理など、日常的な運用とメンテナンスに使用されます。TiUP クラスターを使用するための構文は「tiup cluster [コマンド] [フラグ]」です。サポートされているコマンドには、import、template、check、deploy、list、display、start、stop、restart、scale-in、scale-out、upgrade、prune、edit-config、reload、patch、rename、clean、destroy、audit、replay、enable、disable、meta backup、meta restore、helpなどがあります。 --- -# TiUPクラスタ {#tiup-cluster} +# TiUPクラスター {#tiup-cluster} -TiUP クラスタは、 Golangで記述されたTiUPのクラスタ管理コンポーネントです。TiUP クラスタコンポーネントを使用すると、 TiUPクラスタのデプロイ、起動、シャットダウン、破棄、エラスティックスケーリング、アップグレード、TiDBクラスタパラメータの管理など、日常的な運用とメンテナンスを実行できます。 +TiUP クラスターは、 Golangで記述されたTiUPのクラスター管理コンポーネントです。TiUP クラスターコンポーネントを使用すると、 TiUPクラスターのデプロイ、起動、シャットダウン、破棄、エラスティックスケーリング、アップグレード、TiDBクラスターパラメータの管理など、日常的な運用とメンテナンスを実行できます。 ## 構文 {#syntax} @@ -50,7 +50,7 @@ tiup cluster [command] [flags] ### -v, --バージョン {#v-version} -- TiUP クラスタの現在のバージョンを出力します。 +- TiUP クラスターの現在のバージョンを出力します。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 @@ -66,7 +66,7 @@ tiup cluster [command] [flags] - [テンプレート](/tiup/tiup-component-cluster-template.md) : トポロジテンプレートを出力する - [チェック](/tiup/tiup-component-cluster-check.md) : デプロイメントの前後にクラスターをチェックします - [展開する](/tiup/tiup-component-cluster-deploy.md) : 指定されたトポロジに基づいてクラスターを展開します -- [リスト](/tiup/tiup-component-cluster-list.md) : デプロイされたクラスタのリストを照会する +- [リスト](/tiup/tiup-component-cluster-list.md) : デプロイされたクラスターのリストを照会する - [画面](/tiup/tiup-component-cluster-display.md) : 指定されたクラスターのステータスを表示します - [始める](/tiup/tiup-component-cluster-start.md) : 指定されたクラスターを起動します - [停止](/tiup/tiup-component-cluster-stop.md) : 指定されたクラスターを停止します @@ -76,16 +76,16 @@ tiup cluster [command] [flags] - [アップグレード](/tiup/tiup-component-cluster-upgrade.md) : 指定されたクラスターをアップグレードします - [プルーン](/tiup/tiup-component-cluster-prune.md) : 指定されたクラスターの Tombstone ステータスのインスタンスをクリーンアップします - [編集設定](/tiup/tiup-component-cluster-edit-config.md) : 指定されたクラスターの構成を変更します -- [リロード](/tiup/tiup-component-cluster-reload.md) : 指定されたクラスタの構成を再読み込みします +- [リロード](/tiup/tiup-component-cluster-reload.md) : 指定されたクラスターの構成を再読み込みします - [パッチ](/tiup/tiup-component-cluster-patch.md) : デプロイされたクラスター内のサービスを置き換えます - [名前を変更する](/tiup/tiup-component-cluster-rename.md) : クラスターの名前を変更する - [クリーン](/tiup/tiup-component-cluster-clean.md) : 指定されたクラスターからデータを削除します - [破壊する](/tiup/tiup-component-cluster-destroy.md) : 指定されたクラスターを破棄する -- [監査](/tiup/tiup-component-cluster-audit.md) : 指定されたクラスタの操作監査ログを照会します +- [監査](/tiup/tiup-component-cluster-audit.md) : 指定されたクラスターの操作監査ログを照会します - [リプレイ](/tiup/tiup-component-cluster-replay.md) : 指定されたコマンドを再試行します -- [有効にする](/tiup/tiup-component-cluster-enable.md) : マシンの再起動後にクラスタ サービスの自動有効化を有効にします -- [無効にする](/tiup/tiup-component-cluster-disable.md) : マシンの再起動後にクラスタ サービスの自動有効化を無効にします -- [メタバックアップ](/tiup/tiup-component-cluster-meta-backup.md) : 指定されたクラスタの運用と保守に必要なTiUPメタファイルをバックアップします +- [有効にする](/tiup/tiup-component-cluster-enable.md) : マシンの再起動後にクラスター サービスの自動有効化を有効にします +- [無効にする](/tiup/tiup-component-cluster-disable.md) : マシンの再起動後にクラスター サービスの自動有効化を無効にします +- [メタバックアップ](/tiup/tiup-component-cluster-meta-backup.md) : 指定されたクラスターの運用と保守に必要なTiUPメタファイルをバックアップします - [メタリストア](/tiup/tiup-component-cluster-meta-restore.md) : 指定されたクラスターのTiUPメタファイルを復元します - [ヘルプ](/tiup/tiup-component-cluster-help.md) : ヘルプ情報を出力 diff --git a/tiup/tiup-component-dm-audit.md b/tiup/tiup-component-dm-audit.md index 0a6a82e9b90c5..96af999ef6ec2 100644 --- a/tiup/tiup-component-dm-audit.md +++ b/tiup/tiup-component-dm-audit.md @@ -1,6 +1,6 @@ --- title: tiup dm audit -summary: tiup dm audit`コマンドは、全クラスタで実行されたコマンドの履歴と、各コマンドの実行ログを表示します。`[audit-id]`が指定されていない場合は、`audit-id`、実行時間、コマンドの順に操作記録の表が出力されます。`[audit-id]`が指定されている場合は、指定された`audit-id`の実行ログがチェックされます。`-h, --help`オプションはヘルプ情報を出力。`[audit-id]`が指定されている場合は、対応する実行ログが出力されます。指定されていない場合は、ID、時間、コマンドのフィールドを持つ表が出力されます。 +summary: tiup dm audit`コマンドは、全クラスターで実行されたコマンドの履歴と、各コマンドの実行ログを表示します。`[audit-id]`が指定されていない場合は、`audit-id`、実行時間、コマンドの順に操作記録の表が出力されます。`[audit-id]`が指定されている場合は、指定された`audit-id`の実行ログがチェックされます。`-h, --help`オプションはヘルプ情報を出力。`[audit-id]`が指定されている場合は、対応する実行ログが出力されます。指定されていない場合は、ID、時間、コマンドのフィールドを持つ表が出力されます。 --- # tiup dm audit {#tiup-dm-audit} diff --git a/tiup/tiup-component-dm-deploy.md b/tiup/tiup-component-dm-deploy.md index 0f9e9afaa7427..0af6f48e20f5b 100644 --- a/tiup/tiup-component-dm-deploy.md +++ b/tiup/tiup-component-dm-deploy.md @@ -1,6 +1,6 @@ --- title: tiup dm deploy -summary: tiup dm deploy`コマンドは、新しいクラスタをデプロイするために使用されます。クラスタ名、バージョン、および用意したトポロジファイルが必要です。オプションのフラグとして、ユーザー名、IDファイル、パスワード、ヘルプなどがあります。出力はデプロイメントログです。 +summary: tiup dm deploy`コマンドは、新しいクラスターをデプロイするために使用されます。クラスター名、バージョン、および用意したトポロジファイルが必要です。オプションのフラグとして、ユーザー名、IDファイル、パスワード、ヘルプなどがあります。出力はデプロイメントログです。 --- # tiup dm デプロイ {#tiup-dm-deploy} diff --git a/tiup/tiup-component-dm-destroy.md b/tiup/tiup-component-dm-destroy.md index b9ea1bdedcdee..39a493f915cc9 100644 --- a/tiup/tiup-component-dm-destroy.md +++ b/tiup/tiup-component-dm-destroy.md @@ -1,6 +1,6 @@ --- title: tiup dm destroy -summary: tiup dm destroy`コマンドはクラスタを停止し、各サービスのログ、デプロイメント、データディレクトリを削除し、`tiup-dm`によって作成された親ディレクトリも削除します。構文は`tiup dm destroy [flags]`です。オプション`-h, --helpはヘルプ情報を出力。出力はtiup-dmの実行ログです。 +summary: tiup dm destroy`コマンドはクラスターを停止し、各サービスのログ、デプロイメント、データディレクトリを削除し、`tiup-dm`によって作成された親ディレクトリも削除します。構文は`tiup dm destroy [flags]`です。オプション`-h, --helpはヘルプ情報を出力。出力はtiup-dmの実行ログです。 --- # tiup dm 破壊 {#tiup-dm-destroy} diff --git a/tiup/tiup-component-dm-disable.md b/tiup/tiup-component-dm-disable.md index 0621dd5af5a9e..3360480e5cb50 100644 --- a/tiup/tiup-component-dm-disable.md +++ b/tiup/tiup-component-dm-disable.md @@ -1,11 +1,11 @@ --- title: tiup dm disable -summary: tiup dm disable`コマンドは、マシンの再起動後にクラスタサービスの自動有効化を無効にするために使用されます。`-N, --node`オプションを使用してノードを指定し、`-R, --role`オプションを使用して自動有効化を無効にするロールを指定できます。出力はtiup-dmコマンドの実行ログです。 +summary: tiup dm disable`コマンドは、マシンの再起動後にクラスターサービスの自動有効化を無効にするために使用されます。`-N, --node`オプションを使用してノードを指定し、`-R, --role`オプションを使用して自動有効化を無効にするロールを指定できます。出力はtiup-dmコマンドの実行ログです。 --- # tiup dm 無効 {#tiup-dm-disable} -クラスタサービスが配置されているマシンを再起動すると、クラスタサービスは自動的に有効化されます。クラスタサービスの自動有効化を無効にするには、コマンド`tiup dm disable`使用します。このコマンドは、指定されたノードでコマンド`systemctl disable `を実行し、サービスの自動有効化を無効にします。 +クラスターサービスが配置されているマシンを再起動すると、クラスターサービスは自動的に有効化されます。クラスターサービスの自動有効化を無効にするには、コマンド`tiup dm disable`使用します。このコマンドは、指定されたノードでコマンド`systemctl disable `を実行し、サービスの自動有効化を無効にします。 ## 構文 {#syntax} @@ -19,7 +19,7 @@ tiup dm disable [flags] ### -N, --node {#n-node} -- サービスの自動有効化を無効にするノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスタステータステーブルの最初の列から取得できます。 +- サービスの自動有効化を無効にするノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 [`tiup dm display`](/tiup/tiup-component-dm-display.md)コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 - データ型: `STRINGS` - このオプションがコマンドで指定されていない場合、すべてのノードの自動有効化はデフォルトで無効になります。 diff --git a/tiup/tiup-component-dm-display.md b/tiup/tiup-component-dm-display.md index 32ce22d1ebc8e..48d17094479a3 100644 --- a/tiup/tiup-component-dm-display.md +++ b/tiup/tiup-component-dm-display.md @@ -1,11 +1,11 @@ --- title: tiup dm display -summary: tiup dm displayコマンドは、DMクラスタ内の各コンポーネントの動作状況を効率的に確認します。クラスタ名を指定する必要がありますが、ノードIDとロールも指定できます。出力には、クラスタ名、バージョン、SSHクライアントの種類、およびID、ロール、ホスト、ポート、OS/アーキテクチャ、ステータス、データディレクトリ、デプロイディレクトリなどのフィールドを含むテーブルが含まれます。 +summary: tiup dm displayコマンドは、DMクラスター内の各コンポーネントの動作状況を効率的に確認します。クラスター名を指定する必要がありますが、ノードIDとロールも指定できます。出力には、クラスター名、バージョン、SSHクライアントの種類、およびID、ロール、ホスト、ポート、OS/アーキテクチャ、ステータス、データディレクトリ、デプロイディレクトリなどのフィールドを含むテーブルが含まれます。 --- # tiup dm display {#tiup-dm-display} -DMクラスタ内の各コンポーネントの稼働状況を確認する場合、各マシンに個別にログインするのは非効率的です。そこで、tiup-dmは、この作業を効率的に実行するための`tiup dm display`を提供します。 +DMクラスター内の各コンポーネントの稼働状況を確認する場合、各マシンに個別にログインするのは非効率的です。そこで、tiup-dmは、この作業を効率的に実行するための`tiup dm display`を提供します。 ## 構文 {#syntax} @@ -13,7 +13,7 @@ DMクラスタ内の各コンポーネントの稼働状況を確認する場合 tiup dm display [flags] ``` -``は操作対象となるクラスタ名です。クラスタ名を忘れた場合は、 [`tiup dm list`](/tiup/tiup-component-dm-list.md)コマンドで確認できます。 +``は操作対象となるクラスター名です。クラスター名を忘れた場合は、 [`tiup dm list`](/tiup/tiup-component-dm-list.md)コマンドで確認できます。 ## オプション {#options} @@ -45,8 +45,8 @@ tiup dm display [flags] ## 出力 {#output} -- クラスタ名 -- クラスタバージョン +- クラスター名 +- クラスターバージョン - SSHクライアントの種類 - 次のフィールドを含むテーブル: - `ID` : IP:PORT で構成されるノード ID。 diff --git a/tiup/tiup-component-dm-edit-config.md b/tiup/tiup-component-dm-edit-config.md index a3495f2785a01..7891ba1b31b5d 100644 --- a/tiup/tiup-component-dm-edit-config.md +++ b/tiup/tiup-component-dm-edit-config.md @@ -1,6 +1,6 @@ --- title: tiup dm edit-config -summary: tiup dm edit-config`コマンドを使用すると、デプロイメント後にクラスタサービスの設定を変更できます。エディタを使用して、指定したクラスタのトポロジファイルを変更できます。設定変更時にマシンの追加や削除はできないことに注意してください。コマンド実行後、設定はコントロールマシン上でのみ変更されるため、`tiup dm reloadコマンドを実行して設定を再読み込みする必要があります。 +summary: tiup dm edit-config`コマンドを使用すると、デプロイメント後にクラスターサービスの設定を変更できます。エディタを使用して、指定したクラスターのトポロジファイルを変更できます。設定変更時にマシンの追加や削除はできないことに注意してください。コマンド実行後、設定はコントロールマシン上でのみ変更されるため、`tiup dm reloadコマンドを実行して設定を再読み込みする必要があります。 --- # tiup dm 編集設定 {#tiup-dm-edit-config} diff --git a/tiup/tiup-component-dm-enable.md b/tiup/tiup-component-dm-enable.md index a96b0a81ef009..df05ffd34d281 100644 --- a/tiup/tiup-component-dm-enable.md +++ b/tiup/tiup-component-dm-enable.md @@ -1,11 +1,11 @@ --- title: tiup dm enable -summary: tiup dm enable`コマンドは、マシンの再起動後にクラスタサービスの自動有効化を有効にするために使用されます。このコマンドは、指定されたノードで`systemctl enable `を実行します。オプションには、自動有効化するノードまたはロールの指定が含まれます。出力はtiup-dmの実行ログです。 +summary: tiup dm enable`コマンドは、マシンの再起動後にクラスターサービスの自動有効化を有効にするために使用されます。このコマンドは、指定されたノードで`systemctl enable `を実行します。オプションには、自動有効化するノードまたはロールの指定が含まれます。出力はtiup-dmの実行ログです。 --- # tiup dm 有効 {#tiup-dm-enable} -`tiup dm enable`コマンドは、マシンの再起動後にクラスタサービスを自動的に有効化するように設定するために使用されます。このコマンドは、指定されたノードで`systemctl enable `実行することで、サービスの自動有効化を有効にします。 +`tiup dm enable`コマンドは、マシンの再起動後にクラスターサービスを自動的に有効化するように設定するために使用されます。このコマンドは、指定されたノードで`systemctl enable `実行することで、サービスの自動有効化を有効にします。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-dm-import.md b/tiup/tiup-component-dm-import.md index fc775d700ee77..5a8ff4b35dfd2 100644 --- a/tiup/tiup-component-dm-import.md +++ b/tiup/tiup-component-dm-import.md @@ -1,6 +1,6 @@ --- title: tiup dm import -summary: TiUP DMの「import」コマンドは、DMクラスタをv1.0からv2.0以降のバージョンにアップグレードするために使用されます。このコマンドは、v1.0クラスタからのDMポータルコンポーネントのインポートをサポートしておらず、インポート前に元のクラスタを停止する必要があります。このコマンドはDM v2.0.0-rc.2以降のバージョンへのインポートのみをサポートしており、DM v1.0クラスタを新しいDM v2.0クラスタにインポートするために使用できます。インポート後、クラスタ内のDMマスターノードは1つだけになり、一部のコンポーネントのデプロイメントディレクトリは元のクラスタと異なる場合があります。 +summary: TiUP DMの「import」コマンドは、DMクラスターをv1.0からv2.0以降のバージョンにアップグレードするために使用されます。このコマンドは、v1.0クラスターからのDMポータルコンポーネントのインポートをサポートしておらず、インポート前に元のクラスターを停止する必要があります。このコマンドはDM v2.0.0-rc.2以降のバージョンへのインポートのみをサポートしており、DM v1.0クラスターを新しいDM v2.0クラスターにインポートするために使用できます。インポート後、クラスター内のDMマスターノードは1つだけになり、一部のコンポーネントのデプロイメントディレクトリは元のクラスターと異なる場合があります。 --- # tiup dm import DM v1.0 のアップグレードのみ {#tiup-dm-import-span-class-version-mark-only-for-upgrading-dm-v1-0-span} @@ -19,8 +19,8 @@ DM v1.0では、クラスターは基本的にTiDB Ansibleを使用してデプ > - クラスターをインポートする前に、まず元のクラスターの実行を停止します。 > - v2.0 にアップグレードする必要があるデータ移行タスクの場合、これらのタスクで`stop-task`実行しないでください。 > - このコマンドは、DM v2.0.0-rc.2 以降のバージョンへのインポートのみをサポートします。 -> - `import`コマンドは、DM v1.0 クラスタを新しい DM v2.0 クラスタにインポートするために使用されます。既存の v2.0 クラスタにデータ移行タスクをインポートする必要がある場合は、 [TiDB データ移行を v1.0.x から v2.0+ に手動でアップグレードする](/dm/manually-upgrade-dm-1.0-to-2.0.md)を参照してください。 -> - 一部のコンポーネントのデプロイメントディレクトリは、元のクラスタのものと異なる場合`display`あります。1 コマンドで確認できます。 +> - `import`コマンドは、DM v1.0 クラスターを新しい DM v2.0 クラスターにインポートするために使用されます。既存の v2.0 クラスターにデータ移行タスクをインポートする必要がある場合は、 [TiDB データ移行を v1.0.x から v2.0+ に手動でアップグレードする](/dm/manually-upgrade-dm-1.0-to-2.0.md)を参照してください。 +> - 一部のコンポーネントのデプロイメントディレクトリは、元のクラスターのものと異なる場合`display`あります。1 コマンドで確認できます。 > - クラスターをインポートする前に、 `tiup update --self && tiup update dm`実行してTiUP DMコンポーネントを最新バージョンにアップグレードします。 > - クラスターをインポートすると、クラスター内のDMマスターノードは1つだけになります。DMマスターノードをスケールアウトするには、 [`scale out`コマンド](/tiup/tiup-component-dm-scale-out.md)を参照してください。 diff --git a/tiup/tiup-component-dm-list.md b/tiup/tiup-component-dm-list.md index 52deb7e5ef17f..3d545f8f5e1d4 100644 --- a/tiup/tiup-component-dm-list.md +++ b/tiup/tiup-component-dm-list.md @@ -1,6 +1,6 @@ --- title: tiup dm list -summary: tiup-dm は、同一の制御マシンを用いた複数のクラスタのデプロイをサポートします。「tiup dm list」コマンドは、現在ログインしているユーザーがデプロイしたクラスタを確認します。データは ~/.tiup/ storage/dm/clusters/ ディレクトリに保存されます。ユーザーはクラスタ名、デプロイしたユーザー、バージョン、パス、秘密鍵を確認できます。 +summary: tiup-dm は、同一の制御マシンを用いた複数のクラスターのデプロイをサポートします。「tiup dm list」コマンドは、現在ログインしているユーザーがデプロイしたクラスターを確認します。データは ~/.tiup/ ストレージ/dm/clusters/ ディレクトリに保存されます。ユーザーはクラスター名、デプロイしたユーザー、バージョン、パス、秘密鍵を確認できます。 --- # tiup dm list {#tiup-dm-list} @@ -9,7 +9,7 @@ summary: tiup-dm は、同一の制御マシンを用いた複数のクラスタ > **注記：** > -> デフォルトでは、デプロイされたクラスタのデータは`~/.tiup/storage/dm/clusters/`ディレクトリに保存されます。現在ログインしているユーザーは、同じコントロールマシンに他のユーザーがデプロイしたクラスタを閲覧することはできません。 +> デフォルトでは、デプロイされたクラスターのデータは`~/.tiup/ストレージ/dm/clusters/`ディレクトリに保存されます。現在ログインしているユーザーは、同じコントロールマシンに他のユーザーがデプロイしたクラスターを閲覧することはできません。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-dm-patch.md b/tiup/tiup-component-dm-patch.md index 4f3ce90f63a11..2d0d516db5474 100644 --- a/tiup/tiup-component-dm-patch.md +++ b/tiup/tiup-component-dm-patch.md @@ -19,7 +19,7 @@ summary: DM クラスターにホットフィックス パッチを適用する tiup dm patch [flags] ``` -- `` : 操作対象となるクラスタの名前 +- `` : 操作対象となるクラスターの名前 - `` : 置換に使用するバイナリパッケージへのパス ### 準備 {#preparation} @@ -39,7 +39,7 @@ tiup dm patch [flags] ### --overwrite {#overwrite} -- 特定のコンポーネント（dm-workerなど）にパッチを適用した後、tiup-dmがそのコンポーネントをスケールアウトすると、tiup-dmはデフォルトで元のコンポーネントバージョンを使用します。将来クラスタがスケールアウトした際にパッチを適用したバージョンを使用するには、コマンドでオプション`--overwrite`指定する必要があります。 +- 特定のコンポーネント（dm-workerなど）にパッチを適用した後、tiup-dmがそのコンポーネントをスケールアウトすると、tiup-dmはデフォルトで元のコンポーネントバージョンを使用します。将来クラスターがスケールアウトした際にパッチを適用したバージョンを使用するには、コマンドでオプション`--overwrite`指定する必要があります。 - データ型: `BOOLEAN` - このオプションはデフォルトで値`false`で無効になっています。このオプションを有効にするには、コマンドにこのオプションを追加し、値`true`を渡すか、値を渡さないでください。 @@ -65,7 +65,7 @@ tiup dm patch [flags] ### --offline {#offline} -- 現在のクラスタがオフラインであることを宣言します。このオプションを指定すると、 TiUP DMはサービスを再起動せずに、クラスタコンポーネントのバイナリファイルのみを置き換えます。 +- 現在のクラスターがオフラインであることを宣言します。このオプションを指定すると、 TiUP DMはサービスを再起動せずに、クラスターコンポーネントのバイナリファイルのみを置き換えます。 ### -h, --help {#h-help} @@ -79,7 +79,7 @@ tiup dm patch [flags] > **注記：** > -> ホットフィックスは緊急時の修正にのみ使用されます。日常的なメンテナンスは複雑です。DMクラスタを正式版にアップグレードすることをお勧めします。 +> ホットフィックスは緊急時の修正にのみ使用されます。日常的なメンテナンスは複雑です。DMクラスターを正式版にアップグレードすることをお勧めします。 ### 準備 {#preparations} @@ -98,14 +98,14 @@ tiup dm patch [flags] UTC Build Time: 2021-11-29 08:29:49 Go Version: go version go1.16.4 linux/amd64 -### パッチパッケージを準備し、DMクラスタに適用する {#prepare-the-patch-package-and-apply-it-to-the-dm-cluster} +### パッチパッケージを準備し、DMクラスターに適用する {#prepare-the-patch-package-and-apply-it-to-the-dm-cluster} 1. 現在のバージョンに一致する DM ソフトウェア パッケージを準備します。 ```shell mkdir -p /tmp/package - tar -zxvf /root/.tiup/storage/dm/packages/dm-master-v5.3.0-linux-amd64.tar.gz -C /tmp/package/ - tar -zxvf /root/.tiup/storage/dm/packages/dm-worker-v5.3.0-linux-amd64.tar.gz -C /tmp/package/ + tar -zxvf /root/.tiup/ストレージ/dm/packages/dm-master-v5.3.0-linux-amd64.tar.gz -C /tmp/package/ + tar -zxvf /root/.tiup/ストレージ/dm/packages/dm-worker-v5.3.0-linux-amd64.tar.gz -C /tmp/package/ ``` 2. バイナリ ファイルを修正プログラム パッケージに置き換えます。 diff --git a/tiup/tiup-component-dm-reload.md b/tiup/tiup-component-dm-reload.md index 8f2eae4671733..ef09a6f2b20e6 100644 --- a/tiup/tiup-component-dm-reload.md +++ b/tiup/tiup-component-dm-reload.md @@ -1,11 +1,11 @@ --- title: tiup dm reload -summary: 「tiup dm reload」コマンドは、変更されたクラスタ構成を適用し、サービスを再起動するために使用されます。再起動するノードとロールを指定したり、再起動プロセスをスキップしたりできます。また、このコマンドにはヘルプ情報を表示するオプションがあり、tiup-dmの実行ログも出力されます。 +summary: 「tiup dm reload」コマンドは、変更されたクラスター構成を適用し、サービスを再起動するために使用されます。再起動するノードとロールを指定したり、再起動プロセスをスキップしたりできます。また、このコマンドにはヘルプ情報を表示するオプションがあり、tiup-dmの実行ログも出力されます。 --- # tiup dm reload {#tiup-dm-reload} -[クラスタ構成の変更](/tiup/tiup-component-dm-edit-config.md)後、設定を有効にするには、 `tiup dm reload`コマンドを使用してクラスタをリロードする必要があります。このコマンドは、制御マシンの設定をサービスが稼働しているリモートマシンに公開し、アップグレードプロセスに従ってサービスを順番に再起動します。クラスタは再起動プロセス中も引き続き利用可能です。 +[クラスター構成の変更](/tiup/tiup-component-dm-edit-config.md)後、設定を有効にするには、 `tiup dm reload`コマンドを使用してクラスターをリロードする必要があります。このコマンドは、制御マシンの設定をサービスが稼働しているリモートマシンに公開し、アップグレードプロセスに従ってサービスを順番に再起動します。クラスターは再起動プロセス中も引き続き利用可能です。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-dm-replay.md b/tiup/tiup-component-dm-replay.md index fb75a637c3c2a..7edb3fa57606a 100644 --- a/tiup/tiup-component-dm-replay.md +++ b/tiup/tiup-component-dm-replay.md @@ -1,6 +1,6 @@ --- title: tiup dm replay -summary: tiup dm replay` コマンドを使用すると、失敗したクラスタ操作を再試行し、正常に実行された手順をスキップできます。再試行するコマンドの `audit-id` を使用してください。このIDは `tiup dm audit` コマンドで確認できます。これにより、大規模クラスタで操作を再実行する際の時間節約に役立ちます。 +summary: tiup dm replay` コマンドを使用すると、失敗したクラスター操作を再試行し、正常に実行された手順をスキップできます。再試行するコマンドの `audit-id` を使用してください。このIDは `tiup dm audit` コマンドで確認できます。これにより、大規模クラスターで操作を再実行する際の時間節約に役立ちます。 --- # tiup dm replay {#tiup-dm-replay} diff --git a/tiup/tiup-component-dm-restart.md b/tiup/tiup-component-dm-restart.md index 92beb5503c29f..1411182230aff 100644 --- a/tiup/tiup-component-dm-restart.md +++ b/tiup/tiup-component-dm-restart.md @@ -1,6 +1,6 @@ --- title: tiup dm restart -summary: tiup dm restart`コマンドは、指定されたクラスタ内のサービスを再起動するために使用されます。再起動中は、サービスは利用できません。構文は`tiup dm restart [flags]`です。オプションには、再起動するノードを指定する-N、再起動するノードの役割を指定する-R、ヘルプ情報を表示する-hがあります。出力は、サービス再起動プロセスのログです。 +summary: tiup dm restart`コマンドは、指定されたクラスター内のサービスを再起動するために使用されます。再起動中は、サービスは利用できません。構文は`tiup dm restart [flags]`です。オプションには、再起動するノードを指定する-N、再起動するノードの役割を指定する-R、ヘルプ情報を表示する-hがあります。出力は、サービス再起動プロセスのログです。 --- # tiup dm 再起動 {#tiup-dm-restart} @@ -23,7 +23,7 @@ tiup dm restart [flags] ### -N, --node {#n-node} -- 再起動するノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 `[tiup dm display](/tiup/tiup-component-dm-display.md)`コマンドで返されるクラスタステータステーブルの最初の列から取得できます。 +- 再起動するノードを指定します。このオプションの値は、ノードIDのカンマ区切りのリストです。ノードIDは、 `[tiup dm display](/tiup/tiup-component-dm-display.md)`コマンドで返されるクラスターステータステーブルの最初の列から取得できます。 - データ型: `STRING` - このオプションを指定しない場合、 TiUP はデフォルトですべてのノードを再起動します。 diff --git a/tiup/tiup-component-dm-scale-in.md b/tiup/tiup-component-dm-scale-in.md index 4fc2b55000fcd..6751b94078eb5 100644 --- a/tiup/tiup-component-dm-scale-in.md +++ b/tiup/tiup-component-dm-scale-in.md @@ -1,6 +1,6 @@ --- title: tiup dm scale-in -summary: tiup dm scale-inコマンドは、サービスをオフラインにし、指定されたノードをクラスタから削除することで、クラスタをスケールインします。構文は「tiup dm scale-in [flags]」です。オプションには、ノードの指定、ダウンしているノードの強制削除、ヘルプ情報の表示などを行う -N、 --force、-h があります。出力はスケールインのログです。 +summary: tiup dm scale-inコマンドは、サービスをオフラインにし、指定されたノードをクラスターから削除することで、クラスターをスケールインします。構文は「tiup dm scale-in [flags]」です。オプションには、ノードの指定、ダウンしているノードの強制削除、ヘルプ情報の表示などを行う -N、 --force、-h があります。出力はスケールインのログです。 --- # tiup dm scale-in {#tiup-dm-scale-in} @@ -25,7 +25,7 @@ tiup dm scale-in [flags] ### --force {#force} -- 場合によっては、クラスタ内の一部のスケールインノードがダウンし、SSH経由でノードに接続して操作できなくなることがあります。このような場合は、 `--force`オプションを使用してこれらのノードをクラスタから削除できます。 +- 場合によっては、クラスター内の一部のスケールインノードがダウンし、SSH経由でノードに接続して操作できなくなることがあります。このような場合は、 `--force`オプションを使用してこれらのノードをクラスターから削除できます。 - データ型: `BOOLEAN` - デフォルト：false。このオプションがコマンドで指定されていない場合、指定されたノードは強制的に削除されません。 diff --git a/tiup/tiup-component-dm-scale-out.md b/tiup/tiup-component-dm-scale-out.md index 5faa58fa68878..1ab7fed10caa7 100644 --- a/tiup/tiup-component-dm-scale-out.md +++ b/tiup/tiup-component-dm-scale-out.md @@ -5,7 +5,7 @@ summary: tiup dm scale-out` コマンドは、新しいノードへの SSH 接 # tiup dm scale-out {#tiup-dm-scale-out} -`tiup dm scale-out`コマンドはクラスタのスケールアウトに使用されます。クラスタのスケールアウトの内部ロジックは、クラスタのデプロイメントと同様です。3 `tiup-dm`コンポーネントは、まず新しいノードへのSSH接続を確立し、ターゲットノードに必要なディレクトリを作成し、次にデプロイメントを実行してサービスを起動します。 +`tiup dm scale-out`コマンドはクラスターのスケールアウトに使用されます。クラスターのスケールアウトの内部ロジックは、クラスターのデプロイメントと同様です。3 `tiup-dm`コンポーネントは、まず新しいノードへのSSH接続を確立し、ターゲットノードに必要なディレクトリを作成し、次にデプロイメントを実行してサービスを起動します。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-dm-start.md b/tiup/tiup-component-dm-start.md index f186c9060de40..a8cb34ff96948 100644 --- a/tiup/tiup-component-dm-start.md +++ b/tiup/tiup-component-dm-start.md @@ -1,6 +1,6 @@ --- title: tiup dm start -summary: tiup dm start コマンドは、指定されたクラスタのサービスを起動するために使用されます。構文は「tiup dm start [flags]」です。オプションには、ノードを指定する -N/--node、ロールを指定する -R/--role、ヘルプ情報を表示する -h/--help があります。出力はサービス起動のログです。 +summary: tiup dm start コマンドは、指定されたクラスターのサービスを起動するために使用されます。構文は「tiup dm start [flags]」です。オプションには、ノードを指定する -N/--node、ロールを指定する -R/--role、ヘルプ情報を表示する -h/--help があります。出力はサービス起動のログです。 --- # tiup dm スタート {#tiup-dm-start} diff --git a/tiup/tiup-component-dm-upgrade.md b/tiup/tiup-component-dm-upgrade.md index d6a4dcb24ab92..46080259098ab 100644 --- a/tiup/tiup-component-dm-upgrade.md +++ b/tiup/tiup-component-dm-upgrade.md @@ -1,6 +1,6 @@ --- title: tiup dm upgrade -summary: tiup dm upgrade`コマンドは、指定されたクラスタを特定のバージョンにアップグレードします。パラメータとして、クラスタ名とターゲットバージョンを指定する必要があります。`--offline`オプションはオフラインアップグレードを可能にし、`-h, --help`オプションはヘルプ情報を出力。出力は、サービスアップグレードプロセスのログです。 +summary: tiup dm upgrade`コマンドは、指定されたクラスターを特定のバージョンにアップグレードします。パラメータとして、クラスター名とターゲットバージョンを指定する必要があります。`--offline`オプションはオフラインアップグレードを可能にし、`-h, --help`オプションはヘルプ情報を出力。出力は、サービスアップグレードプロセスのログです。 --- # tiup dm upgrade {#tiup-dm-upgrade} @@ -20,7 +20,7 @@ tiup dm upgrade [flags] ### --offline {#offline} -- 現在のクラスタがオフラインであることを宣言します。このオプションを指定すると、 TiUP DMはサービスを再起動せずに、クラスタコンポーネントのバイナリファイルのみを置き換えます。 +- 現在のクラスターがオフラインであることを宣言します。このオプションを指定すると、 TiUP DMはサービスを再起動せずに、クラスターコンポーネントのバイナリファイルのみを置き換えます。 ### -h, --help {#h-help} diff --git a/tiup/tiup-component-dm.md b/tiup/tiup-component-dm.md index 1d2691d09da88..97aa8c94ef7b9 100644 --- a/tiup/tiup-component-dm.md +++ b/tiup/tiup-component-dm.md @@ -1,11 +1,11 @@ --- title: TiUP DM -summary: TiUP DMは、DMクラスタの管理（デプロイ、起動、停止、破棄、スケーリング、アップグレード、構成パラメータの管理など）に使用されます。SSH、タイムアウト、確認のスキップ、バージョン情報の表示、ヘルプ情報などのオプションをサポートしています。サポートされるコマンドは、import、template、deploy、list、display、start、stop、restart、scale-in、scale-out、upgrade、prune、edit-config、reload、patch、destroy、audit、replay、enable、disable、helpです。 +summary: TiUP DMは、DMクラスターの管理（デプロイ、起動、停止、破棄、スケーリング、アップグレード、構成パラメータの管理など）に使用されます。SSH、タイムアウト、確認のスキップ、バージョン情報の表示、ヘルプ情報などのオプションをサポートしています。サポートされるコマンドは、import、template、deploy、list、display、start、stop、restart、scale-in、scale-out、upgrade、prune、edit-config、reload、patch、destroy、audit、replay、enable、disable、helpです。 --- # TiUP DM {#tiup-dm} -TiDBクラスタの管理に使用される[TiUPクラスタ](/tiup/tiup-component-cluster.md)と同様に、 TiUP DMはDMクラスタの管理に使用されます。TiUP TiUP DMコンポーネントを使用すると、DMクラスタのデプロイ、起動、停止、破棄、エラスティックスケーリング、DMクラスタのアップグレード、DMクラスタの構成パラメータの管理など、DMクラスタの日常的な運用および保守タスクを実行できます。 +TiDBクラスターの管理に使用される[TiUPクラスター](/tiup/tiup-component-cluster.md)と同様に、 TiUP DMはDMクラスターの管理に使用されます。TiUP TiUP DMコンポーネントを使用すると、DMクラスターのデプロイ、起動、停止、破棄、エラスティックスケーリング、DMクラスターのアップグレード、DMクラスターの構成パラメータの管理など、DMクラスターの日常的な運用および保守タスクを実行できます。 ## 構文 {#syntax} diff --git a/tiup/tiup-component-management.md b/tiup/tiup-component-management.md index 81502f7660a5e..ec94fe7c75be2 100644 --- a/tiup/tiup-component-management.md +++ b/tiup/tiup-component-management.md @@ -210,7 +210,7 @@ tiup uninstall --all TiUP v1.13.0では、コンポーネントのバイナリを実行ディレクトリ（ `$TIUP_HOME/bin/` ）にリンクし、リンクを解除する実験的コマンド`link`と`unlink`追加されました。この機能により、異なるバージョン間の切り替え機能を維持しながら、毎回TiUPを経由することなくコンポーネントを呼び出すことができます。ただし、この方法では自動更新チェックや特定の環境変数の設定といったプロセスが欠如しており、一部のコンポーネント（ctlなど）は使用できません。そのため、必要な場合にのみ使用することをお勧めします。 -例1: クラスタコンポーネントの最新バージョンをインストールしてリンクする +例1: クラスターコンポーネントの最新バージョンをインストールしてリンクする ```shell tiup install cluster @@ -231,7 +231,7 @@ package cluster provides these executables: tiup-cluster これは、クラスターコンポーネントのバイナリ名が`tiup-cluster`あることを示しています。リンクコマンドが完了したら、コマンドラインに`tiup-cluster`直接入力することで、クラスターコンポーネントを使用できます。 -例3: クラスタコンポーネントのリンクを解除する +例3: クラスターコンポーネントのリンクを解除する ```shell tiup unlink cluster diff --git a/tiup/tiup-dm-topology-reference.md b/tiup/tiup-dm-topology-reference.md index c70ceae71775f..7d0e9df68d053 100644 --- a/tiup/tiup-dm-topology-reference.md +++ b/tiup/tiup-dm-topology-reference.md @@ -3,11 +3,11 @@ title: Topology Configuration File for DM Cluster Deployment Using TiUP summary: TiUPを使用して TiDB データ移行 (DM) クラスターをデプロイまたは拡張するには、クラスターのグローバル設定、サーバー設定、マスターサーバー、ワーカーサーバー、モニタリングサーバー、Grafana サーバー、および Alertmanager サーバーを記述するトポロジファイルが必要です。各セクションには、設定用の特定のフィールドが含まれています。トポロジファイルの構造は、global、server_configs、master_servers、worker_servers、monitoring_servers、grafana_servers、およびalertmanager_servers で構成されます。各セクションには、デプロイと設定のための独自の設定可能なフィールドセットがあります。 --- -# TiUPを使用した DMクラスタ展開のトポロジコンフィグレーションファイル {#topology-configuration-file-for-dm-cluster-deployment-using-tiup} +# TiUPを使用した DMクラスター展開のトポロジ設定ファイル {#topology-configuration-file-for-dm-cluster-deployment-using-tiup} TiDBデータ移行（DM）クラスターをデプロイまたは拡張するには、クラスタートポロジを記述するトポロジファイル（ [サンプル](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml) ）を提供する必要があります。 -同様に、クラスタトポロジを変更するには、トポロジファイルに変更を加える必要があります。違いは、クラスタのデプロイ後は、トポロジファイル内のフィールドの一部しか変更できないことです。このドキュメントでは、トポロジファイルの各セクションと、各セクション内の各フィールドについて説明します。 +同様に、クラスタートポロジを変更するには、トポロジファイルに変更を加える必要があります。違いは、クラスターのデプロイ後は、トポロジファイル内のフィールドの一部しか変更できないことです。このドキュメントでは、トポロジファイルの各セクションと、各セクション内の各フィールドについて説明します。 ## ファイル構造 {#file-structure} @@ -25,7 +25,7 @@ TiUPを使用した DM クラスターのデプロイメントのトポロジ構 `global`セクションはクラスターのグローバル構成に対応し、次のフィールドがあります。 -- `user` : デプロイされたクラスタを起動するユーザー。デフォルト値は「tidb」です。2 ``に指定されたユーザーがターゲットマシン上に存在しない場合、 TiUP は自動的にユーザーの作成を試みます。 +- `user` : デプロイされたクラスターを起動するユーザー。デフォルト値は「tidb」です。2 ``に指定されたユーザーがターゲットマシン上に存在しない場合、 TiUP は自動的にユーザーの作成を試みます。 - `group` : ユーザーが自動作成された際に所属するユーザーグループ。デフォルト値は``フィールドと同じです。指定されたグループが存在しない場合は、自動的に作成されます。 - `ssh_port` : 操作のためにターゲットマシンに接続するためのSSHポート。デフォルト値は「22」です。 - `deploy_dir` : 各コンポーネントのデプロイメントディレクトリ。デフォルト値は「deploy」です。構築ルールは以下のとおりです。 @@ -65,8 +65,8 @@ global: `server_configs` `server_configs`サービスの設定と各コンポーネントの設定ファイルの生成に使用されます。2 セクションと同様に、 `global`セクションの設定は、インスタンス内の同じキーを持つ設定によって上書きできます。6 `server_configs`は主に以下のフィールドが含まれます。 -- `master` : DMマスターサービスに関連する設定。サポートされているすべての設定項目については、 [DMマスターコンフィグレーションファイル](/dm/dm-master-configuration-file.md)参照してください。 -- `worker` : DM ワーカー サービスに関連する構成。サポートされているすべての構成項目については、 [DMワーカーコンフィグレーションファイル](/dm/dm-worker-configuration-file.md)参照してください。 +- `master` : DMマスターサービスに関連する設定。サポートされているすべての設定項目については、 [DMマスター設定ファイル](/dm/dm-master-configuration-file.md)参照してください。 +- `worker` : DM ワーカー サービスに関連する構成。サポートされているすべての構成項目については、 [DMワーカー設定ファイル](/dm/dm-worker-configuration-file.md)参照してください。 `server_configs`構成の例は次のとおりです。 @@ -193,7 +193,7 @@ worker_servers: - `data_dir` : データディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、データディレクトリはセクション`global`の`data_dir`設定に従って生成されます。 - `log_dir` : ログディレクトリを指定します。このフィールドが指定されていない場合、または相対ディレクトリとして指定されている場合、ログディレクトリはセクション`global`の`log_dir`設定に従って生成されます。 - `numa_node` : インスタンスにNUMAポリシーを割り当てます。このフィールドを指定する前に、対象マシンに[ヌマクトル](https://linux.die.net/man/8/numactl)インストールされていることを確認する必要があります。このフィールドを指定した場合、cpubindおよびmembindポリシーは[ヌマクトル](https://linux.die.net/man/8/numactl)使用して割り当てられます。このフィールドは文字列型です。フィールド値はNUMAノードのID（例："0,1"）です。 -- `storage_retention` : Prometheus監視データの保持期間を指定します。デフォルト値は「15日」です。 +- `ストレージ_retention` : Prometheus監視データの保持期間を指定します。デフォルト値は「15日」です。 - `rule_dir` : `*.rules.yml`のファイルすべてが保存されているローカルディレクトリを指定します。指定されたディレクトリ内のファイルは、クラスター構成の初期化フェーズでPrometheusルールとしてターゲットマシンに送信されます。 - `remote_config` : Prometheusデータのリモートへの書き込み、またはリモートからのデータの読み取りをサポートします。このフィールドには2つの設定があります。 - `remote_write` : Prometheus ドキュメント[`<remote_write>`](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#remote_write)を参照してください。 diff --git a/tiup/tiup-faq.md b/tiup/tiup-faq.md index 37dee2b810deb..01f1203138c8c 100644 --- a/tiup/tiup-faq.md +++ b/tiup/tiup-faq.md @@ -22,7 +22,7 @@ TiUPは現時点ではサードパーティ製コンポーネントをサポー ## TiUPプレイグラウンドとTiUPクラスター コンポーネントの違いは何ですか? {#what-is-the-difference-between-the-tiup-playground-and-tiup-cluster-components} -TiUPプレイグラウンド・コンポーネントは、主にLinuxまたはmacOSオペレーティングシステム上でスタンドアロン開発環境を構築するために使用されます。これにより、 TiUPクラスタの特定のバージョンを迅速に開始し、簡単に実行できます。TiUPクラスタ・コンポーネントは、主に本番環境クラスタ（通常は大規模クラスタ）のデプロイと保守に使用されます。TiUPTiUPグラウンドでデプロイされたTiDBクラスタには、一部の機能と運用能力が不足している可能性があるため、完全な機能テストや安定性テストには推奨されません。 +TiUPプレイグラウンド・コンポーネントは、主にLinuxまたはmacOSオペレーティングシステム上でスタンドアロン開発環境を構築するために使用されます。これにより、 TiUPクラスターの特定のバージョンを迅速に開始し、簡単に実行できます。TiUPクラスター・コンポーネントは、主に本番環境クラスター（通常は大規模クラスター）のデプロイと保守に使用されます。TiUPTiUPグラウンドでデプロイされたTiDBクラスターには、一部の機能と運用能力が不足している可能性があるため、完全な機能テストや安定性テストには推奨されません。 ## TiUPクラスターコンポーネントのトポロジ ファイルを作成するにはどうすればよいでしょうか? {#how-do-i-write-the-topology-file-for-the-tiup-cluster-component} @@ -44,9 +44,9 @@ TiUPクラスターコンポーネントを使用すると、同じホストに ## 異なるクラスター間でポートとディレクトリの競合が検出されますか? {#are-port-and-directory-conflicts-detected-among-different-clusters} -複数の異なるクラスタが同じTiUP制御マシンにデプロイされている場合、デプロイおよびスケーリング中にこれらのクラスタ間のポートおよびディレクトリの競合が検出されます。クラスタが異なるTiUP制御マシンにデプロイされている場合、現在、競合検出はサポートされていません。 +複数の異なるクラスターが同じTiUP制御マシンにデプロイされている場合、デプロイおよびスケーリング中にこれらのクラスター間のポートおよびディレクトリの競合が検出されます。クラスターが異なるTiUP制御マシンにデプロイされている場合、現在、競合検出はサポートされていません。 -## クラスタの展開中に、 TiUPはssh: handshake failed: read tcp 10.10.10.34:38980 -> 10.10.10.34:3600: read: connection reset by peerエラーを受信しました {#during-cluster-deployment-tiup-received-an-code-ssh-handshake-failed-read-tcp-10-10-10-34-38980-10-10-10-34-3600-read-connection-reset-by-peer-code-error} +## クラスターの展開中に、 TiUPはssh: handshake failed: read tcp 10.10.10.34:38980 -> 10.10.10.34:3600: read: connection reset by peerエラーを受信しました {#during-cluster-deployment-tiup-received-an-code-ssh-handshake-failed-read-tcp-10-10-10-34-38980-10-10-10-34-3600-read-connection-reset-by-peer-code-error} このエラーは、 TiUPのデフォルトの同時スレッド数が SSH 接続の最大数を超えているために発生する可能性があります。この問題を解決するには、デフォルトの SSH 接続数を増やしてから、sshd サービスを再起動してください。 diff --git a/tiup/tiup-mirror-reference.md b/tiup/tiup-mirror-reference.md index 4434d69e8e92b..5f0702710db38 100644 --- a/tiup/tiup-mirror-reference.md +++ b/tiup/tiup-mirror-reference.md @@ -161,7 +161,7 @@ TiUPミラーでは、ルート証明書は他のメタデータファイルの } } -### 成分 {#component} +### コンポーネント {#component} コンポーネントのメタデータ ファイルには、コンポーネント固有のプラットフォームとバージョンの情報が記録されます。 diff --git a/tiup/tiup-overview.md b/tiup/tiup-overview.md index 1333746da06c5..edb86632cbf3c 100644 --- a/tiup/tiup-overview.md +++ b/tiup/tiup-overview.md @@ -5,7 +5,7 @@ summary: TiUPツールとそのエコシステムを紹介します。 # TiUPの概要 {#tiup-overview} -TiDB 4.0以降、パッケージマネージャーであるTiUPにより、 TiUPエコシステム内のさまざまなクラスタコンポーネントの管理が大幅に容易になります。TiUPコマンドを1行実行するだけで、あらゆるコンポーネントを実行できます。 +TiDB 4.0以降、パッケージマネージャーであるTiUPにより、 TiUPエコシステム内のさまざまなクラスターコンポーネントの管理が大幅に容易になります。TiUPコマンドを1行実行するだけで、あらゆるコンポーネントを実行できます。 ## TiUPをインストールする {#install-tiup} diff --git a/tiup/tiup-playground.md b/tiup/tiup-playground.md index e88c30450faec..f21e9f6a6be44 100644 --- a/tiup/tiup-playground.md +++ b/tiup/tiup-playground.md @@ -1,11 +1,11 @@ --- title: Quickly Deploy a Local TiDB Cluster -summary: TiUPのプレイグラウンドコンポーネントを使用して、ローカルTiDBクラスタを迅速にデプロイする方法を学びましょう。 +summary: TiUPのプレイグラウンドコンポーネントを使用して、ローカルTiDBクラスターを迅速にデプロイする方法を学びましょう。 --- -# ローカルTiDBクラスタを迅速にデプロイ {#quickly-deploy-a-local-tidb-cluster} +# ローカルTiDBクラスターを迅速にデプロイ {#quickly-deploy-a-local-tidb-cluster} -TiDBクラスタは、複数のコンポーネントで構成される分散システムです。一般的なTiDBクラスタは、少なくとも3つのPDノード、3つのTiKVノード、および2つのTiDBノードで構成されます。TiDBをすぐに試してみたい場合、これほど多くのコンポーネントを手動でデプロイするのは時間と手間がかかるかもしれません。このドキュメントでは、 TiUPのプレイグラウンドコンポーネントと、それを使用してローカルのTiDBテスト環境を迅速に構築する方法について説明します。 +TiDBクラスターは、複数のコンポーネントで構成される分散システムです。一般的なTiDBクラスターは、少なくとも3つのPDノード、3つのTiKVノード、および2つのTiDBノードで構成されます。TiDBをすぐに試してみたい場合、これほど多くのコンポーネントを手動でデプロイするのは時間と手間がかかるかもしれません。このドキュメントでは、 TiUPのプレイグラウンドコンポーネントと、それを使用してローカルのTiDBテスト環境を迅速に構築する方法について説明します。 ## TiUP遊具施設の概要 {#tiup-playground-overview} @@ -15,14 +15,14 @@ TiDBクラスタは、複数のコンポーネントで構成される分散シ tiup playground ${version} [flags] ``` -`tiup playground`コマンドを直接実行すると、 TiUP はローカルにインストールされている TiDB、TiKV、および PD コンポーネントを使用するか、これらのコンポーネントの安定版をインストールして、1 つの TiKV インスタンス、1 つの TiDB インスタンス、1 つの PD インスタンス、および 1 つのTiFlashインスタンスで構成される TiDB クラスタを起動します。 +`tiup playground`コマンドを直接実行すると、 TiUP はローカルにインストールされている TiDB、TiKV、および PD コンポーネントを使用するか、これらのコンポーネントの安定版をインストールして、1 つの TiKV インスタンス、1 つの TiDB インスタンス、1 つの PD インスタンス、および 1 つのTiFlashインスタンスで構成される TiDB クラスターを起動します。 このコマンドは実際には以下の操作を実行します。 - このコマンドではプレイグラウンドコンポーネントのバージョンが指定されていないため、 TiUP はまずインストールされているプレイグラウンドコンポーネントの最新バージョンを確認します。最新バージョンが v1.12.3 であると仮定すると、このコマンドは`tiup playground:v1.12.3`と同じように動作します。 - TiUP playgroundを使用してTiDB、TiKV、およびPDコンポーネントをインストールしていない場合、playgroundコンポーネントはこれらのコンポーネントの最新の安定版をインストールし、その後これらのインスタンスを起動します。 - このコマンドでは TiDB、PD、TiKVコンポーネントのバージョンが指定されていないため、 TiUP playground はデフォルトで各コンポーネントの最新バージョンを使用します。最新バージョンが v8.5.4 であると仮定すると、このコマンドは`tiup playground:v1.12.3 v8.5.4`と同じように動作します。 -- このコマンドでは各コンポーネントの数を指定しないため、 TiUP playground はデフォルトで、TiDB インスタンス、TiKV インスタンス、PD インスタンス、 TiFlashインスタンスがそれぞれ 1 つずつで構成される最小のクラスタを起動します。 +- このコマンドでは各コンポーネントの数を指定しないため、 TiUP playground はデフォルトで、TiDB インスタンス、TiKV インスタンス、PD インスタンス、 TiFlashインスタンスがそれぞれ 1 つずつで構成される最小のクラスターを起動します。 - TiDB の各コンポーネントを起動した後、 TiUPプレイグラウンドはクラスターが正常に起動したことを通知し、MySQL クライアントを介して TiDB クラスターに接続する方法や、 [TiDBダッシュボード](/dashboard/dashboard-intro.md)にアクセスする方法など、いくつかの有用な情報を提供します。 プレイグラウンドコンポーネントのコマンドラインフラグを表示するには、次のコマンドを使用できます。 @@ -39,7 +39,7 @@ tiup playground --help tiup list tidb ``` -### 特定のバージョンのTiDBクラスタを起動する {#start-a-tidb-cluster-of-a-specific-version} +### 特定のバージョンのTiDBクラスターを起動する {#start-a-tidb-cluster-of-a-specific-version} ```shell tiup playground ${version} @@ -47,7 +47,7 @@ tiup playground ${version} `${version}`対象のバージョン番号に置き換えてください。 -### ナイトリーバージョンのTiDBクラスタを起動します {#start-a-tidb-cluster-of-the-nightly-version} +### ナイトリーバージョンのTiDBクラスターを起動します {#start-a-tidb-cluster-of-the-nightly-version} ```shell tiup playground nightly @@ -65,7 +65,7 @@ tiup playground --pd.config ~/config/pd.toml ### デフォルトのバイナリファイルを置き換える {#replace-the-default-binary-files} -デフォルトでは、プレイグラウンドが起動されると、各コンポーネントは公式ミラーのバイナリファイルを使用して起動されます。テストのために一時的にコンパイルされたローカルバイナリファイルをクラスタに配置したい場合は、置換フラグ`--{comp}.binpath`を使用できます。たとえば、TiDB のバイナリファイルを置き換えるには、次のコマンドを実行します。 +デフォルトでは、プレイグラウンドが起動されると、各コンポーネントは公式ミラーのバイナリファイルを使用して起動されます。テストのために一時的にコンパイルされたローカルバイナリファイルをクラスターに配置したい場合は、置換フラグ`--{comp}.binpath`を使用できます。たとえば、TiDB のバイナリファイルを置き換えるには、次のコマンドを実行します。 ```shell tiup playground --db.binpath /xx/tidb-server @@ -79,9 +79,9 @@ tiup playground --db.binpath /xx/tidb-server tiup playground --db 3 --pd 3 --kv 3 ``` -### TiDBクラスタの起動時に、データを保存するタグを指定します。 {#specify-a-tag-when-starting-the-tidb-cluster-to-store-the-data} +### TiDBクラスターの起動時に、データを保存するタグを指定します。 {#specify-a-tag-when-starting-the-tidb-cluster-to-store-the-data} -TiUP playground を使用して起動した TiDB クラスタを停止すると、クラスタデータもすべてクリーンアップされます。TiUP playground を使用してTiUPクラスタを起動し、クラスタデータが自動的にクリーンアップされないようにするには、クラスタ起動時にタグを指定できます。タグを指定すると、クラスタデータは`~/.tiup/data`ディレクトリに保存されます。タグを指定するには、次のコマンドを実行します。 +TiUP playground を使用して起動した TiDB クラスターを停止すると、クラスターデータもすべてクリーンアップされます。TiUP playground を使用してTiUPクラスターを起動し、クラスターデータが自動的にクリーンアップされないようにするには、クラスター起動時にタグを指定できます。タグを指定すると、クラスターデータは`~/.tiup/data`ディレクトリに保存されます。タグを指定するには、次のコマンドを実行します。 ```shell tiup playground --tag ${tag_name} @@ -91,7 +91,7 @@ tiup playground --tag ${tag_name} ## TiDBダッシュボードとGrafanaにアクセスする {#access-tidb-dashboard-and-grafana} -TiUP playgroundを使用してTiDBクラスタを起動すると、ブラウザで次のアドレスにアクセスすることで、 [TiDBダッシュボード](/dashboard/dashboard-intro.md)とGrafanaにアクセスできます。 +TiUP playgroundを使用してTiDBクラスターを起動すると、ブラウザで次のアドレスにアクセスすることで、 [TiDBダッシュボード](/dashboard/dashboard-intro.md)とGrafanaにアクセスできます。 - TiDBダッシュボード： `http://127.0.0.1:2379/dashboard` @@ -109,13 +109,13 @@ TiUP playgroundを使用してTiDBクラスタを起動すると、ブラウザ ## playground で起動した TiDB クラスターにすばやく接続します {#quickly-connect-to-the-tidb-cluster-started-by-playground} -TiUPは、playgroundによって起動されたローカルTiDBクラスタを自動的に検出して接続するために使用される`client`コンポーネントを提供します。使用方法は以下のとおりです。 +TiUPは、playgroundによって起動されたローカルTiDBクラスターを自動的に検出して接続するために使用される`client`コンポーネントを提供します。使用方法は以下のとおりです。 ```shell tiup client ``` -このコマンドを実行すると、コンソールに、現在のマシン上でplaygroundによって起動されたTiDBクラスタの一覧が表示されます。接続するTiDBクラスタを選択してください。Enterキーを押すと、TiDBに接続するための組み込みのMySQLクライアントが開きます。 +このコマンドを実行すると、コンソールに、現在のマシン上でplaygroundによって起動されたTiDBクラスターの一覧が表示されます。接続するTiDBクラスターを選択してください。Enterキーを押すと、TiDBに接続するための組み込みのMySQLクライアントが開きます。 ## 起動したクラスターの情報をビュー {#view-information-of-the-started-cluster} @@ -134,7 +134,7 @@ tiup playground display ## クラスターをスケールアウトする {#scale-out-a-cluster} -クラスタをスケールアウトするためのコマンドラインパラメータは、クラスタを起動するためのパラメータと似ています。以下のコマンドを実行することで、2つのTiDBインスタンスをスケールアウトできます。 +クラスターをスケールアウトするためのコマンドラインパラメータは、クラスターを起動するためのパラメータと似ています。以下のコマンドを実行することで、2つのTiDBインスタンスをスケールアウトできます。 ```shell tiup playground scale-out --db 2 @@ -158,9 +158,9 @@ TiUP v1.15.0以降では、 TiUP Playgroundを使用してクラスターにTiPr graceful-wait-before-shutdown=15 - この設定項目は、TiDBがサーバーをシャットダウンするまでの待機時間（秒単位）を制御し、クラスタのスケールイン操作中にクライアントが切断されるのを防ぎます。 + この設定項目は、TiDBがサーバーをシャットダウンするまでの待機時間（秒単位）を制御し、クラスターのスケールイン操作中にクライアントが切断されるのを防ぎます。 -2. TiDBクラスタを起動します。 +2. TiDBクラスターを起動します。 ```shell tiup playground v8.5.4 --tiproxy 1 --db.config tidb.toml diff --git a/tiup/tiup-reference.md b/tiup/tiup-reference.md index d7ce7381d3f27..2f7ae1c76047e 100644 --- a/tiup/tiup-reference.md +++ b/tiup/tiup-reference.md @@ -47,7 +47,7 @@ tiup [flags] [args...] # Runs a component ### -T, --タグ {#t-tag} -- 起動するコンポーネントのタグを指定します。一部のコンポーネントは実行中にディスクstorageを使用する必要があり、 TiUP はこの実行のために一時的なstorageディレクトリを割り当てます。TiUPに固定のディレクトリを割り当てたい場合は、ディレクトリ名に`-T/--tag`指定します。これにより、同じタグを持つ複数の実行で、同じファイルバッチの読み取りと書き込みが可能になります。 +- 起動するコンポーネントのタグを指定します。一部のコンポーネントは実行中にディスクストレージを使用する必要があり、 TiUP はこの実行のために一時的なストレージディレクトリを割り当てます。TiUPに固定のディレクトリを割り当てたい場合は、ディレクトリ名に`-T/--tag`指定します。これにより、同じタグを持つ複数の実行で、同じファイルバッチの読み取りと書き込みが可能になります。 - データ型: `STRING` ### -v, --バージョン {#v-version} @@ -76,5 +76,5 @@ TiUPには複数のコマンドがあり、これらのコマンドには複数 ## コンポーネントリスト {#component-list} -- [クラスタ](/tiup/tiup-component-cluster.md) :本番環境で TiDB クラスターを管理します。 +- [クラスター](/tiup/tiup-component-cluster.md) :本番環境で TiDB クラスターを管理します。 - [dm](/tiup/tiup-component-dm.md) :本番環境で TiDB データ移行 (DM) クラスターを管理します。 diff --git a/tiup/tiup-troubleshooting-guide.md b/tiup/tiup-troubleshooting-guide.md index 6ba4809fba802..d6dd45f3979d6 100644 --- a/tiup/tiup-troubleshooting-guide.md +++ b/tiup/tiup-troubleshooting-guide.md @@ -25,7 +25,7 @@ TiUPはミラーサーバーから最新のコンポーネントリストを毎 CDNサーバーのキャッシュ時間が短いため、新しいチェックサムファイルがコンポーネントパッケージと一致しない可能性があります。5分後に再度ダウンロードをお試しください。それでも新しいチェックサムファイルがコンポーネントパッケージと一致しない場合は、問題[ここ](https://github.com/pingcap/tiup/issues)報告してください。 -## TiUPクラスタコンポーネントのトラブルシューティング {#troubleshoot-tiup-cluster-component} +## TiUPクラスターコンポーネントのトラブルシューティング {#troubleshoot-tiup-cluster-component} ### unable to authenticate, attempted methods [none publickey]プロンプト表示されます。 {#code-unable-to-authenticate-attempted-methods-none-publickey-code-is-prompted-during-deployment} @@ -37,7 +37,7 @@ CDNサーバーのキャッシュ時間が短いため、新しいチェック - フラグ`-i`が指定されている場合、 TiUPは指定された秘密鍵を使用してリモートホストにログインできない可能性があります。3コマンド`ssh -i identity_file user@remote`手動で実行することで確認できます。 - リモート ホストへのログインにパスワードを使用する場合は、フラグ`-p`を指定して正しいログイン パスワードを入力したことを確認してください。 -### TiUPクラスタコンポーネントを使用したクラスタのアップグレード プロセスが中断されます {#the-process-of-upgrading-the-cluster-using-the-tiup-cluster-component-is-interrupted} +### TiUPクラスターコンポーネントを使用したクラスターのアップグレード プロセスが中断されます {#the-process-of-upgrading-the-cluster-using-the-tiup-cluster-component-is-interrupted} 誤用を避けるため、 TiUPクラスターコンポーネントは指定されたノードのアップグレードをサポートしていません。そのため、アップグレードが失敗した後は、アップグレード プロセス中のべき等操作を含むアップグレード操作を再度実行する必要があります。 @@ -53,4 +53,4 @@ CDNサーバーのキャッシュ時間が短いため、新しいチェック ### アップグレード中に、 node_exporter-9100.service/blackbox_exporter-9115.serviceが存在しないことがわかります。 {#during-the-upgrade-you-find-that-code-node-exporter-9100-service-blackbox-exporter-9115-service-code-does-not-exist} -以前にTiDB Ansibleからクラスタを移行し、エクスポーターがTiDB Ansibleにデプロイされていない場合、この状況が発生する可能性があります。この問題を解決するには、当面の間、他のノードから新しいノードに不足しているファイルを手動でコピーしてください。TiUPチームは、移行プロセス中に不足しているコンポーネントを補完します。 +以前にTiDB Ansibleからクラスターを移行し、エクスポーターがTiDB Ansibleにデプロイされていない場合、この状況が発生する可能性があります。この問題を解決するには、当面の間、他のノードから新しいノードに不足しているファイルを手動でコピーしてください。TiUPチームは、移行プロセス中に不足しているコンポーネントを補完します。 diff --git a/topn-limit-push-down.md b/topn-limit-push-down.md index 031116493f3a1..b49e44a7dddf2 100644 --- a/topn-limit-push-down.md +++ b/topn-limit-push-down.md @@ -17,7 +17,7 @@ TiDB実行プランツリーでは、SQLの`LIMIT`節はLimit演算子ノード このセクションでは、いくつかの例を通して TopN プッシュダウンについて説明します。 -### 例1:storageレイヤーのコプロセッサにプッシュダウンする {#example-1-push-down-to-the-coprocessors-in-the-storage-layer} +### 例1:ストレージレイヤーのコプロセッサにプッシュダウンする {#example-1-push-down-to-the-coprocessors-in-the-ストレージ-layer} ```sql create table t(id int primary key, a int not null); @@ -58,7 +58,7 @@ explain select * from t left join s on t.a = s.a order by t.a limit 10; +----------------------------------+----------+-----------+---------------+-------------------------------------------------+ 8 rows in set (0.01 sec) -このクエリでは、TopN演算子のソートルールは外部テーブル`t`の列のみに依存するため、TopNをJoinにプッシュダウンする前に計算を実行することで、Join操作の計算コストを削減できます。また、TiDBはTopNをstorageレイヤーにプッシュダウンします。 +このクエリでは、TopN演算子のソートルールは外部テーブル`t`の列のみに依存するため、TopNをJoinにプッシュダウンする前に計算を実行することで、Join操作の計算コストを削減できます。また、TiDBはTopNをストレージレイヤーにプッシュダウンします。 ### 例3: TopNはJoin前にプッシュダウンできない {#example-3-topn-cannot-be-pushed-down-before-join} diff --git a/transaction-isolation-levels.md b/transaction-isolation-levels.md index 2982bb314971d..a88add6abebd4 100644 --- a/transaction-isolation-levels.md +++ b/transaction-isolation-levels.md @@ -32,7 +32,7 @@ TiDBはスナップショット分離（SI）一貫性を実装しており、My > > TiDB v3.0以降、トランザクションの自動再試行はデフォルトで無効になっています。自動再試行を有効にすると**、トランザクション分離レベルが損なわれる**可能性があるため、有効にすることは推奨されません。詳細は[トランザクションの再試行](/optimistic-transaction.md#automatic-retry)を参照してください。 > -> TiDB v3.0.8以降、新規に作成されたTiDBクラスタはデフォルトで[悲観的トランザクションモード](/pessimistic-transaction.md)使用します。現在の読み取り（ `for update`読み取り）**は繰り返し不可能な読み取り**です。詳細は[悲観的トランザクションモード](/pessimistic-transaction.md)を参照してください。 +> TiDB v3.0.8以降、新規に作成されたTiDBクラスターはデフォルトで[悲観的トランザクションモード](/pessimistic-transaction.md)使用します。現在の読み取り（ `for update`読み取り）**は繰り返し不可能な読み取り**です。詳細は[悲観的トランザクションモード](/pessimistic-transaction.md)を参照してください。 ## 繰り返し読み取り分離レベル {#repeatable-read-isolation-level} diff --git a/transaction-overview.md b/transaction-overview.md index f8f294dfe2bf6..7952c8b562031 100644 --- a/transaction-overview.md +++ b/transaction-overview.md @@ -3,7 +3,7 @@ title: Transactions summary: TiDB でのトランザクションについて学習します。 --- -# 取引 {#transactions} +# トランザクション {#transactions} TiDBは、 [悲観的](/pessimistic-transaction.md)または[楽観的](/optimistic-transaction.md)トランザクションモードを使用した分散トランザクションをサポートします。TiDB 3.0.8以降では、デフォルトで悲観的トランザクションモードが使用されます。 @@ -17,7 +17,7 @@ TiDBは、 [悲観的](/pessimistic-transaction.md)または[楽観的](/optimis ## よくある発言 {#common-statements} -### 取引の開始 {#starting-a-transaction} +### トランザクションの開始 {#starting-a-transaction} ステートメント[`BEGIN`](/sql-statements/sql-statement-begin.md)と[`START TRANSACTION`](/sql-statements/sql-statement-start-transaction.md) 、新しいトランザクションを明示的に開始するために互換的に使用できます。 @@ -57,7 +57,7 @@ COMMIT; > **ヒント：** > -> [楽観的取引](/optimistic-transaction.md)有効にする前に、アプリケーションが`COMMIT`ステートメントでエラーが返される可能性があることを正しく処理できることを確認してください。アプリケーションがこれをどのように処理するか不明な場合は、代わりにデフォルトの[悲観的取引](/pessimistic-transaction.md)使用することをお勧めします。 +> [楽観的トランザクション](/optimistic-transaction.md)有効にする前に、アプリケーションが`COMMIT`ステートメントでエラーが返される可能性があることを正しく処理できることを確認してください。アプリケーションがこれをどのように処理するか不明な場合は、代わりにデフォルトの[悲観的トランザクション](/pessimistic-transaction.md)使用することをお勧めします。 ### トランザクションのロールバック {#rolling-back-a-transaction} @@ -268,7 +268,7 @@ mysql> SELECT * FROM test; ## トランザクションサイズの制限 {#transaction-size-limit} -基盤となるstorageエンジンの制限により、TiDBでは1行のサイズが6MB以下である必要があります。行内のすべての列は、それぞれのデータ型に応じてバイトに変換され、合計されて1行のサイズが推定されます。 +基盤となるストレージエンジンの制限により、TiDBでは1行のサイズが6MB以下である必要があります。行内のすべての列は、それぞれのデータ型に応じてバイトに変換され、合計されて1行のサイズが推定されます。 TiDBは楽観的トランザクションと悲観的トランザクションの両方をサポートしており、楽観的トランザクションは悲観的トランザクションの基盤となります。楽観的トランザクションはまず変更をプライベートメモリにキャッシュするため、TiDBは単一トランザクションのサイズを制限します。 @@ -302,7 +302,7 @@ TiDBはデフォルトで線形一貫性を保証します。線形一貫性の | トランザクション1 | トランザクション2 | | ------------------------------------------- | --------------------------- | -| 因果関係の一貫性のみで取引を開始する | 因果関係の一貫性のみで取引を開始する | +| 因果関係の一貫性のみでトランザクションを開始する | 因果関係の一貫性のみでトランザクションを開始する | | x = SELECT v FROM t WHERE id = 1 FOR UPDATE | | | 更新 t set v = $(x + 1) WHERE id = 2 | | | 専念 | | @@ -317,7 +317,7 @@ TiDBはデフォルトで線形一貫性を保証します。線形一貫性の | トランザクション1 | トランザクション2 | トランザクション3 | | --------------------------- | --------------------------- | ---------------------------------- | -| 因果関係の一貫性のみで取引を開始する | 因果関係の一貫性のみで取引を開始する | | +| 因果関係の一貫性のみでトランザクションを開始する | 因果関係の一貫性のみでトランザクションを開始する | | | 更新 t set v = 3 WHERE id = 2 | | | | | 更新 t SET v = 2 WHERE id = 1 | | | | | 始める | @@ -335,7 +335,7 @@ TiDBはデフォルトで線形一貫性を保証します。線形一貫性の | トランザクション1 | トランザクション2 | | ---------------------------- | --------------------------- | -| 因果関係の一貫性のみで取引を開始する | 因果関係の一貫性のみで取引を開始する | +| 因果関係の一貫性のみでトランザクションを開始する | 因果関係の一貫性のみでトランザクションを開始する | | | 更新 t SET v = 2 WHERE id = 1 | | SELECT v FROM t WHERE id = 1 | | | 更新 t set v = 3 WHERE id = 2 | | diff --git a/troubleshoot-cpu-issues.md b/troubleshoot-cpu-issues.md index 3e2fbfa2f1893..aae1be22203ca 100644 --- a/troubleshoot-cpu-issues.md +++ b/troubleshoot-cpu-issues.md @@ -52,7 +52,7 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ - PD がLeaderを選出できません: PD ログには`lease is not expired`表示されます。3 [この号](https://github.com/etcd-io/etcd/issues/10355) v3.0.x および v2.1.19 で修正されました。 -- リーダー選出が遅い。リージョンの読み込み時間が長い。この問題は、PDログで`grep "regions cost"`実行することで確認できます。結果が`load 460927 regions cost 11.77099s`秒など秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0では、 `use-region-storage`を`true`に設定することで`region storage`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。 +- リーダー選出が遅い。リージョンの読み込み時間が長い。この問題は、PDログで`grep "regions cost"`実行することで確認できます。結果が`load 460927 regions cost 11.77099s`秒など秒単位の場合、リージョンの読み込みが遅いことを意味します。v3.0では、 `use-region-ストレージ`を`true`に設定することで`region ストレージ`機能を有効にでき、リージョンの読み込み時間を大幅に短縮できます。 - TiDBとPD間のネットワークに問題があります。Grafana -> **blackbox_exporter** -> **ping レイテンシー****モニター**にアクセスして、TiDBからPDLeaderへのネットワークが正常に動作しているかどうかを確認してください。 @@ -86,7 +86,7 @@ PD TSOのメトリック`wait duration`が異常に増加しています。こ - ネットワーク分離のため再選。 -- `block-cache`設定が大きすぎる場合、TiKV OOM が発生する可能性があります。問題の原因を確認するには、 **Grafana**モニターで該当するインスタンスを選択し、RocksDB の`block cache size`確認してください。同時に、 `[storage.block-cache] capacity = # "1GB"`パラメータが正しく設定されているかどうかを確認してください。デフォルトでは、 **TiKV**の`block-cache`マシンの総メモリの`45%`に設定されています。コンテナに TiKV をデプロイする際には、このパラメータを明示的に指定する必要があります。TiKV は物理マシンのメモリを取得するため、コンテナのメモリ制限を超える可能性があります。 +- `block-cache`設定が大きすぎる場合、TiKV OOM が発生する可能性があります。問題の原因を確認するには、 **Grafana**モニターで該当するインスタンスを選択し、RocksDB の`block cache size`確認してください。同時に、 `[ストレージ.block-cache] capacity = # "1GB"`パラメータが正しく設定されているかどうかを確認してください。デフォルトでは、 **TiKV**の`block-cache`マシンの総メモリの`45%`に設定されています。コンテナに TiKV をデプロイする際には、このパラメータを明示的に指定する必要があります。TiKV は物理マシンのメモリを取得するため、コンテナのメモリ制限を超える可能性があります。 - コプロセッサーは大量の大きなクエリを受信し、大量のデータを返します。gRPCはコプロセッサがデータを返すのに間に合うようにデータを送信できず、OOMが発生します。原因を確認するには、モニター**Grafana** -> **TiKV詳細**->**コプロセッサ概要**で、 `response size` `network outbound`トラフィックを超えているかどうかを確認してください。 @@ -110,9 +110,9 @@ CPU リソースの使用量がボトルネックになります。 ## その他の原因 {#other-causes} -### クラスタのメンテナンス {#cluster-maintenance} +### クラスターのメンテナンス {#cluster-maintenance} -オンラインクラスタのほとんどは3ノードまたは5ノードで構成されています。メンテナンス対象のマシンにPDコンポーネントが搭載されている場合は、そのノードがリーダーかフォロワーかを判断する必要があります。フォロワーを無効にしてもクラスタの動作には影響しません。リーダーを無効にする前に、リーダーシップを切り替える必要があります。リーダーシップの切り替え中は、約3秒のパフォーマンスジッターが発生します。 +オンラインクラスターのほとんどは3ノードまたは5ノードで構成されています。メンテナンス対象のマシンにPDコンポーネントが搭載されている場合は、そのノードがリーダーかフォロワーかを判断する必要があります。フォロワーを無効にしてもクラスターの動作には影響しません。リーダーを無効にする前に、リーダーシップを切り替える必要があります。リーダーシップの切り替え中は、約3秒のパフォーマンスジッターが発生します。 ### レプリカの少数はオフラインです {#minority-of-replicas-are-offline} diff --git a/troubleshoot-high-disk-io.md b/troubleshoot-high-disk-io.md index 642b3e72a3a04..747fe37ad6e71 100644 --- a/troubleshoot-high-disk-io.md +++ b/troubleshoot-high-disk-io.md @@ -1,6 +1,6 @@ --- title: Troubleshoot High Disk I/O Usage in TiDB -summary: TiDBstorageのI/O 使用率が高い問題を特定して対処する方法を学びます。 +summary: TiDBストレージのI/O 使用率が高い問題を特定して対処する方法を学びます。 --- # TiDB におけるディスク I/O 使用率の高騰のトラブルシューティング {#troubleshoot-high-disk-i-o-usage-in-tidb} @@ -26,7 +26,7 @@ I/Oの問題を特定する最も簡単な方法は、 TiUPによってデフォ #### 2番目のタイプの監視パネル {#the-second-type-of-monitoring-panels} -TiDBクラスターのメインstorageコンポーネントはTiKVです。1つのTiKVインスタンスには2つのRocksDBインスタンスが含まれます。1つはRaftログを保存するためのもので、 `data/raft`に配置されています。もう1つは実データを保存するためのもので、 `data/db`に配置されています。 +TiDBクラスターのメインストレージコンポーネントはTiKVです。1つのTiKVインスタンスには2つのRocksDBインスタンスが含まれます。1つはRaftログを保存するためのもので、 `data/raft`に配置されています。もう1つは実データを保存するためのもので、 `data/db`に配置されています。 **TiKV-Details** > **Raft IO**では、これら 2 つのインスタンスのディスク書き込みに関連するメトリックを確認できます。 @@ -37,7 +37,7 @@ TiDBクラスターのメインstorageコンポーネントはTiKVです。1つ #### 3番目のタイプの監視パネル {#the-third-type-of-monitoring-panels} -**TiKV-Details** > **Storage**には、storageに関連する監視メトリックがあります。 +**TiKV-Details** > **Storage**には、ストレージに関連する監視メトリックがあります。 - `Storage command total` : 受信した異なるコマンドの数を示します。 - `Storage async write duration` : `disk sync duration`などの監視メトリックが含まれます。これらはRaft I/Oに関連する可能性があります。異常な状況が発生した場合は、ログを確認して関連コンポーネントの動作状態を確認してください。 @@ -92,4 +92,4 @@ TiDBクラスターのメインstorageコンポーネントはTiKVです。1つ - I/O ホットスポットの問題が発生していることが確認された場合は、「TiDB ホットスポットの問題の処理」を参照して I/O ホットスポットを排除する必要があります。 - 全体的な I/O パフォーマンスがボトルネックになっていることが確認され、アプリケーション側で I/O パフォーマンスが低下し続けると判断できる場合は、分散データベースのスケーリング機能を活用し、TiKV ノードの数を増やして全体的な I/O スループットを向上させることができます。 -- 上記のようにいくつかのパラメータを調整し、コンピューティング/メモリリソースを使用してディスクstorageリソースを補います。 +- 上記のようにいくつかのパラメータを調整し、コンピューティング/メモリリソースを使用してディスクストレージリソースを補います。 diff --git a/troubleshoot-hot-spot-issues.md b/troubleshoot-hot-spot-issues.md index 2f34962cb470e..459a63e16f334 100644 --- a/troubleshoot-hot-spot-issues.md +++ b/troubleshoot-hot-spot-issues.md @@ -7,7 +7,7 @@ summary: TiDB の読み取りまたは書き込みホットスポットの問題 このドキュメントでは、読み取りおよび書き込みホットスポットの問題を特定して解決する方法について説明します。 -分散データベースであるTiDBは、アプリケーションの負荷を異なるコンピューティングノードまたはstorageノードに可能な限り均等に分散し、サーバーリソースをより有効に活用する負荷分散メカニズムを備えています。しかし、特定のシナリオでは、一部のアプリケーションの負荷が適切に分散されず、パフォーマンスに影響を与え、単一の高負荷ポイント（ホットスポット）が形成される可能性があります。 +分散データベースであるTiDBは、アプリケーションの負荷を異なるコンピューティングノードまたはストレージノードに可能な限り均等に分散し、サーバーリソースをより有効に活用する負荷分散メカニズムを備えています。しかし、特定のシナリオでは、一部のアプリケーションの負荷が適切に分散されず、パフォーマンスに影響を与え、単一の高負荷ポイント（ホットスポット）が形成される可能性があります。 TiDBは、ホットスポットのトラブルシューティング、解決、または回避のための包括的なソリューションを提供します。負荷ホットスポットを分散することで、QPSの向上やレイテンシーの削減など、全体的なパフォーマンスを向上させることができます。 diff --git a/troubleshoot-lock-conflicts.md b/troubleshoot-lock-conflicts.md index 62a742547e8ba..d58d6389324b8 100644 --- a/troubleshoot-lock-conflicts.md +++ b/troubleshoot-lock-conflicts.md @@ -291,7 +291,7 @@ TiDBダッシュボードの`KV Errors`パネルには、トランザクショ ### 悲観的ロック再試行制限に達しました {#pessimistic-lock-retry-limit-reached} -トランザクションの競合が非常に深刻な場合、または書き込みの競合が発生した場合、楽観的トランザクションは直接終了され、悲観的トランザクションは書き込みの競合がなくなるまでstorageからの最新のデータを使用してステートメントを再試行します。 +トランザクションの競合が非常に深刻な場合、または書き込みの競合が発生した場合、楽観的トランザクションは直接終了され、悲観的トランザクションは書き込みの競合がなくなるまでストレージからの最新のデータを使用してステートメントを再試行します。 TiDBのロック操作は書き込み操作であり、そのプロセスはまず読み取り、次に書き込みであるため、RPCリクエストは2つあります。トランザクションの途中で書き込み競合が発生した場合、TiDBは対象キーのロックを再度試行し、各再試行はTiDBログに出力されます。再試行回数は[pessimistic-txn。max-retry-count](/tidb-configuration-file.md#max-retry-count)です。 diff --git a/troubleshoot-tidb-cluster.md b/troubleshoot-tidb-cluster.md index 17bdbce6f0b4c..c7d66759f3206 100644 --- a/troubleshoot-tidb-cluster.md +++ b/troubleshoot-tidb-cluster.md @@ -3,7 +3,7 @@ title: TiDB Cluster Troubleshooting Guide summary: TiDB を使用する際に問題を診断して解決する方法を学びます。 --- -# TiDBクラスタシューティング ガイド {#tidb-cluster-troubleshooting-guide} +# TiDBクラスターシューティング ガイド {#tidb-cluster-troubleshooting-guide} このガイドは、TiDBの使用中に発生する基本的な問題の診断と解決に役立ちます。問題が解決しない場合は、以下の情報を収集して、 [バグを報告する](/support.md) . @@ -32,7 +32,7 @@ summary: TiDB を使用する際に問題を診断して解決する方法を学 3. データがクリアされ、サービスが再デプロイされる場合は、次の点を確認してください。 - `tikv-server`と`pd-server`のデータはすべてクリアされます。特定のデータは`tikv-server`に保存され、メタデータは`pd-server`に保存されます。2つのサーバーのうち1つだけがクリアされると、データの整合性が失われます。 - - `pd-server`と`tikv-server`のデータがクリアされ、 `pd-server`と`tikv-server`再起動された後、 `tidb-server`も再起動する必要があります。クラスタIDは`pd-server`初期化される際にランダムに割り当てられます。そのため、クラスタが再デプロイされるとクラスタIDが変更され、新しいクラスタIDを取得するには`tidb-server`再起動する必要があります。 + - `pd-server`と`tikv-server`のデータがクリアされ、 `pd-server`と`tikv-server`再起動された後、 `tidb-server`も再起動する必要があります。クラスターIDは`pd-server`初期化される際にランダムに割り当てられます。そのため、クラスターが再デプロイされるとクラスターIDが変更され、新しいクラスターIDを取得するには`tidb-server`再起動する必要があります。 ## tidb-serverを起動できません {#cannot-start-code-tidb-server-code} diff --git a/troubleshoot-tidb-oom.md b/troubleshoot-tidb-oom.md index 8b51bd45efa73..8552981ca251f 100644 --- a/troubleshoot-tidb-oom.md +++ b/troubleshoot-tidb-oom.md @@ -93,7 +93,7 @@ OOM 問題のさまざまな原因に応じて、SQL ステートメントのメ - テーブル間の JOIN 順序を調整します。 - ヒントを使用して SQL ステートメントを最適化します。 -- 一部の演算子と関数はstorageレベルへのプッシュダウンがサポートされていないため、中間結果セットが大量に蓄積されます。このような場合は、SQL文を修正するか、ヒントを使用して最適化し、プッシュダウンをサポートする関数または演算子を使用する必要があります。 +- 一部の演算子と関数はストレージレベルへのプッシュダウンがサポートされていないため、中間結果セットが大量に蓄積されます。このような場合は、SQL文を修正するか、ヒントを使用して最適化し、プッシュダウンをサポートする関数または演算子を使用する必要があります。 - 実行プランにはHashAgg演算子が含まれています。HashAggは複数のスレッドで同時に実行されるため、高速ですがメモリ消費量は多くなります。代わりに`STREAM_AGG()`使用することもできます。 @@ -164,9 +164,9 @@ OOM 問題の根本原因を特定するには、次の情報を収集する必 - `oom-action` - `tidb_enable_rate_limit_action` - `tidb_server_memory_limit` - - `oom-use-tmp-storage` - - `tmp-storage-path` - - `tmp-storage-quota` + - `oom-use-tmp-ストレージ` + - `tmp-ストレージ-path` + - `tmp-ストレージ-quota` - `tidb_analyze_version` - Grafana ダッシュボードで TiDBメモリの毎日の使用量を確認します: **TiDB** > **Server** > **Memory Usage** 。 @@ -189,7 +189,7 @@ OOM 問題の根本原因を特定するには、次の情報を収集する必 - `grep "tidb-server has the risk of OOM" tidb.log`実行して、TiDB サーバーによって収集されたアラートファイルのパスを確認します。出力例を以下に示します。 ```shell - ["tidb-server has the risk of OOM because of memory usage exceeds alarm ratio. Running SQLs and heap profile will be recorded in record path"] ["is tidb_server_memory_limit set"=false] ["system memory total"=14388137984] ["system memory usage"=11897434112] ["tidb-server memory usage"=11223572312] [memory-usage-alarm-ratio=0.8] ["record path"="/tmp/0_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-storage/record"] + ["tidb-server has the risk of OOM because of memory usage exceeds alarm ratio. Running SQLs and heap profile will be recorded in record path"] ["is tidb_server_memory_limit set"=false] ["system memory total"=14388137984] ["system memory usage"=11897434112] ["tidb-server memory usage"=11223572312] [memory-usage-alarm-ratio=0.8] ["record path"="/tmp/0_tidb/MC4wLjAuMDo0MDAwLzAuMC4wLjA6MTAwODA=/tmp-ストレージ/record"] ``` ## 参照 {#see-also} diff --git a/troubleshoot-write-conflicts.md b/troubleshoot-write-conflicts.md index c46ed258f97b1..474b5f0ff998d 100644 --- a/troubleshoot-write-conflicts.md +++ b/troubleshoot-write-conflicts.md @@ -7,7 +7,7 @@ summary: 楽観的トランザクションにおける書き込み競合の原 このドキュメントでは、楽観的トランザクションにおける書き込み競合の原因と解決策を紹介します。 -TiDB v3.0.8より前のバージョンでは、TiDBはデフォルトで楽観的トランザクションモデルを使用しています。このモデルでは、TiDBはトランザクション実行中に競合をチェックしません。代わりに、トランザクションが最終的にコミットされる際に2相コミット（2PC）がトリガーされ、TiDBは書き込み競合をチェックします。書き込み競合が存在し、自動再試行メカニズムが有効になっている場合、TiDBは制限時間内にトランザクションを再試行します。再試行が成功するか、再試行回数の上限に達した場合、TiDBはトランザクション実行結果をクライアントに返します。そのため、TiDBクラスタ内に書き込み競合が多数存在する場合、この期間は長くなる可能性があります。 +TiDB v3.0.8より前のバージョンでは、TiDBはデフォルトで楽観的トランザクションモデルを使用しています。このモデルでは、TiDBはトランザクション実行中に競合をチェックしません。代わりに、トランザクションが最終的にコミットされる際に2相コミット（2PC）がトリガーされ、TiDBは書き込み競合をチェックします。書き込み競合が存在し、自動再試行メカニズムが有効になっている場合、TiDBは制限時間内にトランザクションを再試行します。再試行が成功するか、再試行回数の上限に達した場合、TiDBはトランザクション実行結果をクライアントに返します。そのため、TiDBクラスター内に書き込み競合が多数存在する場合、この期間は長くなる可能性があります。 ## 書き込み競合の原因 {#the-reason-of-write-conflicts} diff --git a/tso-configuration-file.md b/tso-configuration-file.md index 112cb9becab8c..912b3e7403d87 100644 --- a/tso-configuration-file.md +++ b/tso-configuration-file.md @@ -3,7 +3,7 @@ title: TSO Configuration File summary: TSO 構成ファイルには、ノード名、データ パス、ノード URL などの複数の構成項目が含まれています。 --- -# TSOコンフィグレーションファイル {#tso-configuration-file} +# TSO設定ファイル {#tso-configuration-file} @@ -58,7 +58,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ## 安全 {#security} -セキュリティ関連のコンフィグレーション項目 +セキュリティ関連の設定項目 ### cacert-path {#code-cacert-path-code} @@ -83,7 +83,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ## ログ {#log} -ログに関するコンフィグレーション項目。 +ログに関する設定項目。 ### level {#code-level-code} @@ -104,7 +104,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ## ログファイル {#log-file} -ログファイルに関連するコンフィグレーション項目 +ログファイルに関連する設定項目 ### max-size {#code-max-size-code} @@ -127,7 +127,7 @@ TSOノードは、PD用の`tso`マイクロサービスを提供するために ## メトリック {#metric} -監視に関連するコンフィグレーション項目 +監視に関連する設定項目 ### interval {#code-interval-code} diff --git a/tso.md b/tso.md index be8b567a9b946..350b590ac910d 100644 --- a/tso.md +++ b/tso.md @@ -5,7 +5,7 @@ summary: TiDB の TimeStamp Oracle (TSO) について学習します。 # TiDB のタイムスタンプ Oracle (TSO) {#timestamp-oracle-tso-in-tidb} -TiDBでは、配置Driver（PD）がクラスタ内の様々なコンポーネントにタイムスタンプを割り当てる上で重要な役割を果たします。これらのタイムスタンプは、トランザクションとデータに時間マーカーを割り当てる際に重要な役割を果たします。これは、TiDB内で[パーコレーター](https://research.google/pubs/large-scale-incremental-processing-using-distributed-transactions-and-notifications/)モデルを実現するために不可欠なメカニズムです。3と[マルチバージョン同時実行制御 (MVCC)](https://docs.pingcap.com/tidb/stable/glossary#multi-version-concurrency-control-mvcc) [取引管理](/transaction-overview.md)サポートするには、Percolatorモデルが使用されます。 +TiDBでは、配置Driver（PD）がクラスター内の様々なコンポーネントにタイムスタンプを割り当てる上で重要な役割を果たします。これらのタイムスタンプは、トランザクションとデータに時間マーカーを割り当てる際に重要な役割を果たします。これは、TiDB内で[パーコレーター](https://research.google/pubs/large-scale-incremental-processing-using-distributed-transactions-and-notifications/)モデルを実現するために不可欠なメカニズムです。3と[マルチバージョン同時実行制御 (MVCC)](https://docs.pingcap.com/tidb/stable/glossary#multi-version-concurrency-control-mvcc) [トランザクション管理](/transaction-overview.md)サポートするには、Percolatorモデルが使用されます。 次の例は、TiDB で現在の TSO を取得する方法を示しています。 diff --git a/tune-operating-system.md b/tune-operating-system.md index e28bba1e97482..a2f9833aebe42 100644 --- a/tune-operating-system.md +++ b/tune-operating-system.md @@ -77,13 +77,13 @@ grubby --update-kernel="$KERNEL" --args='transparent_hugepage=never' - `dirty_ratio`パーセント比。ダーティページキャッシュの総量がシステムメモリ全体のこのパーセント比に達すると、システムは`pdflush`オペレーションを使用してダーティページキャッシュをディスクに書き込みます。デフォルト値の`dirty_ratio`は 20% であり、通常は調整する必要はありません。NVMe デバイスなどの高性能 SSD の場合、この値を下げるとメモリ回収の効率が向上します。 - `dirty_background_ratio`パーセント比。ダーティページキャッシュの総量がシステムメモリ全体のこのパーセント比に達すると、システムはバックグラウンドでダーティページキャッシュをディスクに書き込み始めます。デフォルト値は`dirty_background_ratio`で、10% であり、通常は調整する必要はありません。NVMe デバイスなどの高性能 SSD の場合、値を低く設定するとメモリ回収の効率が向上します。 -### ストレージとファイルシステム {#storage-and-file-system} +### ストレージとファイルシステム {#ストレージ-and-file-system} コア I/O スタック リンクは、ファイル システムレイヤー、ブロック デバイスレイヤー、およびドライバーレイヤーを含めて長くなります。 #### I/Oスケジューラ {#i-o-scheduler} -I/Oスケジューラは、storageデバイス上でI/O操作を実行するタイミングと時間を決定します。I/Oエレベータとも呼ばれます。SSDデバイスの場合、I/Oスケジューリングポリシーを`noop`に設定することをお勧めします。 +I/Oスケジューラは、ストレージデバイス上でI/O操作を実行するタイミングと時間を決定します。I/Oエレベータとも呼ばれます。SSDデバイスの場合、I/Oスケジューリングポリシーを`noop`に設定することをお勧めします。 ```shell echo noop > /sys/block/${SSD_DEV_NAME}/queue/scheduler @@ -93,7 +93,7 @@ echo noop > /sys/block/${SSD_DEV_NAME}/queue/scheduler ブロックはファイルシステムの作業単位です。ブロックサイズは、1つのブロックに保存できるデータの量を決定し、それによって1回あたりに書き込んだり読み込んだりするデータの最小量を決定します。 -デフォルトのブロックサイズは、ほとんどのシナリオに適しています。ただし、ブロックサイズ（または複数のブロックのサイズ）が、通常毎回読み書きされるデータ量と同じか、わずかに大きい場合、ファイルシステムのパフォーマンスが向上し、データstorageの効率も向上します。小さなファイルは依然としてブロック全体を使用します。ファイルを複数のブロックに分散させることも可能ですが、実行時のオーバーヘッドが増加します。 +デフォルトのブロックサイズは、ほとんどのシナリオに適しています。ただし、ブロックサイズ（または複数のブロックのサイズ）が、通常毎回読み書きされるデータ量と同じか、わずかに大きい場合、ファイルシステムのパフォーマンスが向上し、データストレージの効率も向上します。小さなファイルは依然としてブロック全体を使用します。ファイルを複数のブロックに分散させることも可能ですが、実行時のオーバーヘッドが増加します。 `mkfs`コマンドを使用してデバイスをフォーマットする場合、ファイルシステムオプションの一部としてブロックサイズを指定します。ブロックサイズを指定するパラメータはファイルシステムによって異なります。詳細については、対応する`mkfs`マニュアルページ（例： `man mkfs.ext4`を参照してください。 diff --git a/tune-tikv-memory-performance.md b/tune-tikv-memory-performance.md index d56665065f300..b5c8552f6841b 100644 --- a/tune-tikv-memory-performance.md +++ b/tune-tikv-memory-performance.md @@ -7,7 +7,7 @@ summary: 最適なパフォーマンスを得るために TiKV パラメータ このドキュメントでは、TiKVパラメータを調整して最適なパフォーマンスを得る方法について説明します。デフォルトの設定ファイルは[etc/config-template.toml](https://github.com/tikv/tikv/blob/release-8.5/etc/config-template.toml)にあります。設定を変更するには、 [TiUPを使用する](/maintain-tidb-using-tiup.md#modify-the-configuration)または[TiKVを動的に変更する](/dynamic-config.md#modify-tikv-configuration-dynamically)で一部の設定項目を選択できます。完全な設定については、 [TiKV設定ファイル](/tikv-configuration-file.md)ご覧ください。 -TiKVは、TiKVアーキテクチャの最下層における永続storageとしてRocksDBを使用します。そのため、多くのパフォーマンスパラメータはRocksDBに関連しています。TiKVは2つのRocksDBインスタンスを使用します。デフォルトのRocksDBインスタンスはKVデータを保存し、 Raft RocksDBインスタンス（RaftDB）はRaftログを保存します。 +TiKVは、TiKVアーキテクチャの最下層における永続ストレージとしてRocksDBを使用します。そのため、多くのパフォーマンスパラメータはRocksDBに関連しています。TiKVは2つのRocksDBインスタンスを使用します。デフォルトのRocksDBインスタンスはKVデータを保存し、 Raft RocksDBインスタンス（RaftDB）はRaftログを保存します。 TiKV は RocksDB から`Column Families` (CF) を実装します。 @@ -21,7 +21,7 @@ TiKV は RocksDB から`Column Families` (CF) を実装します。 - `default` CF はRaftログを保存します。対応するパラメータは`[raftdb.defaultcf]`にあります。 -TiKV 3.0以降では、デフォルトですべてのCFが1つのブロックキャッシュインスタンスを共有します。キャッシュのサイズは、 `[storage.block-cache]`の下の`capacity`パラメータを設定することで設定できます。ブロックキャッシュが大きいほど、より多くのホットデータをキャッシュでき、データの読み取りが容易になりますが、同時にシステムメモリの占有量も大きくなります。 +TiKV 3.0以降では、デフォルトですべてのCFが1つのブロックキャッシュインスタンスを共有します。キャッシュのサイズは、 `[ストレージ.block-cache]`の下の`capacity`パラメータを設定することで設定できます。ブロックキャッシュが大きいほど、より多くのホットデータをキャッシュでき、データの読み取りが容易になりますが、同時にシステムメモリの占有量も大きくなります。 TiKV 3.0 より前では、共有ブロックキャッシュはサポートされていないため、各 CF ごとにブロックキャッシュを個別に構成する必要があります。 @@ -51,7 +51,7 @@ log-level = "info" # Tag the TiKV instances to schedule replicas. # labels = {zone = "cn-east-1", host = "118", disk = "ssd"} -[storage] +[ストレージ] # The data directory # data-dir = "/tmp/tikv/store" @@ -62,7 +62,7 @@ log-level = "info" # `scheduler-worker-pool-size` higher and increase the number of write threads. # scheduler-worker-pool-size = 4 -[storage.block-cache] +[ストレージ.block-cache] ## Whether to create a shared block cache for all RocksDB column families. ## ## Block cache is used by RocksDB to cache uncompressed blocks. Big block cache can speed up read. @@ -70,7 +70,7 @@ log-level = "info" ## set, it is easier to configure. In most cases, it should be able to auto-balance cache usage ## between column families with standard LRU algorithm. ## -## The rest of config in the storage.block-cache session is effective only when shared block cache +## The rest of config in the ストレージ.block-cache session is effective only when shared block cache ## is on. ## Starting from v6.6.0, the `shared` option is always enabled and cannot be disabled. # shared = true @@ -99,7 +99,7 @@ address = "" job = "tikv" [raftstore] -# Raft RocksDB directory. The default value is Raft subdirectory of [storage.data-dir]. +# Raft RocksDB directory. The default value is Raft subdirectory of [ストレージ.data-dir]. # If there are multiple disks on the machine, store the data of Raft RocksDB on different disks to improve TiKV performance. # raftdb-path = "/tmp/tikv/store/raft" @@ -152,7 +152,7 @@ block-size = "64KB" # "no:no:lz4:lz4:lz4:zstd:zstd" indicates there is no compaction of level0 and level1; lz4 compaction algorithm is used # from level2 to level4; zstd compaction algorithm is used from level5 to level6. # "no" means no compaction. "lz4" is a compaction algorithm with moderate speed and compaction ratio. The -# compaction ratio of zlib is high. It is friendly to the storage space, but its compaction speed is slow. This +# compaction ratio of zlib is high. It is friendly to the ストレージ space, but its compaction speed is slow. This # compaction occupies many CPU resources. Different machines deploy compaction modes according to CPU and I/O resources. # For example, if you use the compaction mode of "no:no:lz4:lz4:lz4:zstd:zstd" and find much I/O pressure of the # system (run the iostat command to find %util lasts 100%, or run the top command to find many iowaits) when writing diff --git a/tune-tikv-thread-performance.md b/tune-tikv-thread-performance.md index d02329a6ae874..56494b536af5a 100644 --- a/tune-tikv-thread-performance.md +++ b/tune-tikv-thread-performance.md @@ -49,7 +49,7 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで - スケジューラ スレッド プール。 - TiKV がマシンの CPU コアの数が 16 以上であることを検出すると、スケジューラ スレッド プールのデフォルト サイズ ( `storage.scheduler-worker-pool-size`に設定) は`8`なります。TiKV がマシンの CPU コアの数が 16 未満であることを検出すると、デフォルト サイズは`4`なります。 + TiKV がマシンの CPU コアの数が 16 以上であることを検出すると、スケジューラ スレッド プールのデフォルト サイズ ( `ストレージ.scheduler-worker-pool-size`に設定) は`8`なります。TiKV がマシンの CPU コアの数が 16 未満であることを検出すると、デフォルト サイズは`4`なります。 このスレッドプールは主に、複雑なトランザクションリクエストを単純なキー値の読み取り/書き込みリクエストに変換するために使用されます。ただし、**スケジューラスレッドプール自体は書き込み操作を実行しません**。 diff --git a/two-data-centers-in-one-city-deployment.md b/two-data-centers-in-one-city-deployment.md index a697a21ef016e..79a39794b46bb 100644 --- a/two-data-centers-in-one-city-deployment.md +++ b/two-data-centers-in-one-city-deployment.md @@ -7,7 +7,7 @@ summary: 1 つのリージョンに 2 つの可用性ゾーンを展開するソ このドキュメントでは、アーキテクチャ、構成、このデプロイメント モードを有効にする方法、このモードでレプリカを使用する方法など、1 つのリージョン内の 2 つのアベイラビリティ ゾーン (AZ) のデプロイメント モードについて説明します。 -このドキュメントにおける「リージョン」という用語は地理的な領域を指し、「リージョン」はTiKVにおけるデータstorageの基本単位を指します。「AZ」はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 +このドキュメントにおける「リージョン」という用語は地理的な領域を指し、「リージョン」はTiKVにおけるデータストレージの基本単位を指します。「AZ」はリージョン内の独立した場所を指し、各リージョンには複数のAZが存在します。このドキュメントで説明するソリューションは、単一の都市に複数のデータセンターが存在するシナリオにも適用されます。 ## 導入 {#introduction} @@ -21,18 +21,18 @@ TiDBは通常、高可用性と災害復旧機能を確保するために、マ クラスター展開のアーキテクチャは次のとおりです。 -- クラスターには6つのレプリカがあります。AZ1には3つのVoterレプリカ、AZ2には2つのVoterレプリカと1つのLearnerレプリカがあります。TiKVコンポーネントでは、各ラックに適切なラベルが付けられています。 +- クラスターには6つのレプリカがあります。AZ1には3つのVoterレプリカ、AZ2には2つのVoterレプリカと1つのラーナーレプリカがあります。TiKVコンポーネントでは、各ラックに適切なラベルが付けられています。 - ユーザーにとって透過的なデータの一貫性と高可用性を確保するために、 Raftプロトコルが採用されています。 ![2-AZ-in-1-region architecture](/media/two-dc-replication-1.png) -このデプロイメントソリューションでは、クラスタのレプリケーション状態を制御および識別するために3つのステータスを定義しており、これによりTiKVのレプリケーションモードが制限されます。クラスタのレプリケーションモードは、3つのステータス間を自動的かつ適応的に切り替えることができます。詳細については、セクション[ステータススイッチ](#status-switch)ご覧ください。 +このデプロイメントソリューションでは、クラスターのレプリケーション状態を制御および識別するために3つのステータスを定義しており、これによりTiKVのレプリケーションモードが制限されます。クラスターのレプリケーションモードは、3つのステータス間を自動的かつ適応的に切り替えることができます。詳細については、セクション[ステータススイッチ](#status-switch)ご覧ください。 - **sync** : 同期レプリケーションモード。このモードでは、災害復旧AZ内の少なくとも1つのレプリカがプライマリAZと同期します。RaftRaftにより、各ログはラベルに基づいてDRに複製されます。 - **async** : 非同期レプリケーションモード。このモードでは、ディザスタリカバリAZはプライマリAZと完全に同期されません。RaftアルゴリズムはRaftプロトコルに従ってログを複製します。 - **sync-recover** : 同期リカバリモード。このモードでは、ディザスタリカバリAZはプライマリAZと完全に同期されていません。Raftは徐々にラベルレプリケーションモードに切り替え、ラベル情報をPDに報告します。 -## コンフィグレーション {#configuration} +## 設定 {#configuration} ### 例 {#example} @@ -89,7 +89,7 @@ alertmanager_servers: ### 配置ルール {#placement-rules} -計画されたトポロジに基づいてクラスターをデプロイするには、 [配置ルール](/configure-placement-rules.md)使用してクラスターレプリカの配置場所を決定する必要があります。4 つのレプリカ（Voter レプリカ 2 つをプライマリ AZ、Voter レプリカ 1 つをディザスタリカバリ AZ に、 Learnerレプリカ 1 つをディザスタリカバリ AZ に配置）のデプロイを例に挙げると、配置ルールを使用してレプリカを次のように設定できます。 +計画されたトポロジに基づいてクラスターをデプロイするには、 [配置ルール](/configure-placement-rules.md)使用してクラスターレプリカの配置場所を決定する必要があります。4 つのレプリカ（Voter レプリカ 2 つをプライマリ AZ、Voter レプリカ 1 つをディザスタリカバリ AZ に、 ラーナーレプリカ 1 つをディザスタリカバリ AZ に配置）のデプロイを例に挙げると、配置ルールを使用してレプリカを次のように設定できます。 cat rule.json [ @@ -273,12 +273,12 @@ curl http://pd_ip:pd_port/pd/api/v1/replication_mode/status このセクションでは、1 つのリージョン展開における 2 つの AZ の災害復旧ソリューションを紹介します。 -同期レプリケーションモードのクラスタに災害が発生した場合、 `RPO = 0`でデータリカバリを実行できます。 +同期レプリケーションモードのクラスターに災害が発生した場合、 `RPO = 0`でデータリカバリを実行できます。 - プライマリ AZ に障害が発生し、Voter レプリカの大部分が失われたものの、災害復旧 AZ に完全なデータが存在する場合、失われたデータは災害復旧 AZ から復旧できます。この場合、専門ツールを用いた手動介入が必要です。復旧ソリューションについては、PingCAP またはコミュニティから[サポートを受ける](/support.md)参照してください。 - 災害復旧 AZ に障害が発生し、いくつかの Voter レプリカが失われた場合、クラスターは自動的に非同期レプリケーション モードに切り替わります。 -同期レプリケーションモードになっていないクラスタに災害が発生し、 `RPO = 0`でデータリカバリを実行できない場合: +同期レプリケーションモードになっていないクラスターに災害が発生し、 `RPO = 0`でデータリカバリを実行できない場合: - Voterレプリカの大部分が失われた場合は、専門ツールを用いた手動介入が必要です。PingCAPまたはコミュニティから復旧ソリューションを[サポートを受ける](/support.md)することもできます。 diff --git a/upgrade-monitoring-services.md b/upgrade-monitoring-services.md index 754865b2ba7ef..e34656a1fa7c1 100644 --- a/upgrade-monitoring-services.md +++ b/upgrade-monitoring-services.md @@ -3,7 +3,7 @@ title: Upgrade Cluster Monitoring Services summary: TiDB クラスターの Prometheus、Grafana、および Alertmanager 監視サービスをアップグレードする方法を学習します。 --- -# TiDBクラスタ監視サービスのアップグレード {#upgrade-tidb-cluster-monitoring-services} +# TiDBクラスター監視サービスのアップグレード {#upgrade-tidb-cluster-monitoring-services} TiDB クラスターをデプロイすると、 TiUP はクラスターの監視サービス（Prometheus、Grafana、Alertmanager など）を自動的にデプロイします。このクラスターをスケールアウトすると、 TiUP はスケーリング中に新しく追加されたノードの監視設定も自動的に追加します。TiUP によって自動的にデプロイされる監視サービスは、通常、これらのサードパーティ製監視サービスの最新バージョンではありません。最新バージョンを使用するには、こちらのドキュメントに従って監視サービスをアップグレードしてください。 diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index 7f85e22937243..3099f5d28d469 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -10,7 +10,7 @@ summary: TiUPを使用してTiDBをアップグレードする方法を学びま > **警告：** > > 1. TiDB をアップグレードする前に、オペレーティング システムのバージョンが[OSおよびプラットフォームの要件](/hardware-and-software-requirements.md#os-and-platform-requirements)を満たしていることを確認してください。 CentOS Linux 7 で実行されているクラスターを v8.5 にアップグレードする場合は、クラスターが使用できなくなるリスクを避けるために、必ず TiDB v8.5.1 以降のバージョンを使用してください。詳細については、 [TiDB v8.5.1 リリースノート](/releases/release-8.5.1.md)を参照してください。 -> 2. TiFlash を5.3 より前のバージョンから 5.3 以降にオンラインでアップグレードすることはできません。代わりに、まず以前のバージョンのTiFlashインスタンスをすべて停止し、その後オフラインでクラスタをアップグレードする必要があります。TiDB や TiKV などの他のコンポーネントがオンラインアップグレードをサポートしていない場合は、[オンラインアップグレード](#online-upgrade)の警告の手順に従ってください。 。 +> 2. TiFlash を5.3 より前のバージョンから 5.3 以降にオンラインでアップグレードすることはできません。代わりに、まず以前のバージョンのTiFlashインスタンスをすべて停止し、その後オフラインでクラスターをアップグレードする必要があります。TiDB や TiKV などの他のコンポーネントがオンラインアップグレードをサポートしていない場合は、[オンラインアップグレード](#online-upgrade)の警告の手順に従ってください。 。 > 3. アップグレード処理中はDDLステートメントを実行**しないでください**。実行すると、未定義の動作が発生する可能性があります。 > 4. TiDB クラスターで DDL ステートメントが実行されている間は、クラスターをアップグレード**しないでください**(通常、 `ADD INDEX`や列型の変更など、時間のかかる DDL ステートメントの場合)。アップグレードの前に、 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)コマンドを使用して、TiDB クラスターで DDL ジョブが実行中かどうかを確認することをお勧めします。クラスターで DDL ジョブが実行されている場合は、クラスターをアップグレードする前に、DDL の実行が完了するまで待つか、 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md)コマンドを使用して DDL ジョブをキャンセルしてください。 > 5. アップグレード前の TiDB バージョンが 7.1.0 以降の場合は、前述の警告 3 と 4 を無視してかまいません。詳細については、 [TiDB スムーズアップグレードの使用に関する制限](/smooth-upgrade-tidb.md#limitations)を参照してください。 @@ -19,11 +19,11 @@ summary: TiUPを使用してTiDBをアップグレードする方法を学びま > **注記：** > > - アップグレードするクラスターが v6.2 より前の場合、シナリオによってはクラスターを v6.2 以降のバージョンにアップグレードすると、アップグレードが停止する可能性があります。 [問題を解決する方法](#how-to-fix-the-issue-that-the-upgrade-gets-stuck-when-upgrading-to-v620-or-later-versions)を参照してください。 -> - TiDBノードは[`server-version`](/tidb-configuration-file.md#server-version)構成項目の値を使用して現在のTiDBバージョンを確認します。そのため、予期しない動作を避けるため、TiDBクラスタをアップグレードする前に、 `server-version`の値を空にするか、現在のTiDBクラスタの実際のバージョンに設定する必要があります。 +> - TiDBノードは[`server-version`](/tidb-configuration-file.md#server-version)構成項目の値を使用して現在のTiDBバージョンを確認します。そのため、予期しない動作を避けるため、TiDBクラスターをアップグレードする前に、 `server-version`の値を空にするか、現在のTiDBクラスターの実際のバージョンに設定する必要があります。 > - [`performance.force-init-stats`](/tidb-configuration-file.md#force-init-stats-new-in-v657-and-v710)設定項目を`ON`に設定すると、TiDB の起動時間が長くなり、起動タイムアウトやアップグレードの失敗が発生する可能性があります。この問題を回避するには、 TiUPの待機タイムアウトを長く設定することをお勧めします。 > - 影響を受ける可能性のあるシナリオ： -> - 元のクラスタバージョンはv6.5.7およびv7.1.0（ `performance.force-init-stats`をまだサポートしていない）より前のバージョンであり、ターゲットバージョンはv7.2.0以降です。 -> - 元のクラスタバージョンはv6.5.7およびv7.1.0以降であり、 `performance.force-init-stats`構成項目は`ON`に設定されています。 +> - 元のクラスターバージョンはv6.5.7およびv7.1.0（ `performance.force-init-stats`をまだサポートしていない）より前のバージョンであり、ターゲットバージョンはv7.2.0以降です。 +> - 元のクラスターバージョンはv6.5.7およびv7.1.0以降であり、 `performance.force-init-stats`構成項目は`ON`に設定されています。 > > - `performance.force-init-stats`設定項目の値を確認してください。 > @@ -49,12 +49,12 @@ summary: TiUPを使用してTiDBをアップグレードする方法を学びま - TiCDC、 TiFlash、およびその他のコンポーネントのバージョンアップグレードをサポートします。 - クラスターが TiCDC クラシックアーキテクチャ(v8.1.2 など) を使用している場合は、メジャー バージョン間のアップグレード中に変更フィードを実行し続けないでください。この場合、次の手順を順番に実行します。すべての変更フィードを一時停止し、TiCDC をアップグレードし、TiDB クラスターをアップグレードし、すべての変更フィードを再開します。詳細については、 [以前のバージョンからのアップグレードに関する互換性に関する注意事項](/ticdc/ticdc-compatibility.md#compatibility-notes-for-upgrading-from-earlier-versions)参照してください。 - TiFlashをv6.3.0より前のバージョンからv6.3.0以降のバージョンにアップグレードする場合、Linux AMD64アーキテクチャではCPUがAVX2命令セットを、Linux ARM64アーキテクチャではARMv8命令セットアーキテクチャをサポートしている必要があることに注意してください。詳細は[v6.3.0 リリースノート](/releases/release-6.3.0.md#others)の説明を参照してください。 -- 各バージョンの互換性に関する詳細な変更点については、各バージョンの[リリースノート](/releases/_index.md)を参照してください。該当するリリースノートの「互換性の変更点」セクションに従って、クラスタ構成を変更してください。 +- 各バージョンの互換性に関する詳細な変更点については、各バージョンの[リリースノート](/releases/_index.md)を参照してください。該当するリリースノートの「互換性の変更点」セクションに従って、クラスター構成を変更してください。 - クラスターをv5.3より前のバージョンからv5.3以降のバージョンに更新する場合、デフォルトでデプロイされたPrometheusによって生成されるアラートの時刻フォーマットが変更されることに注意してください。このフォーマット変更は、Prometheus v2.27.1以降で導入されています。詳細については、 [プロメテウス](https://github.com/prometheus/prometheus/commit/7646cbca328278585be15fa615e22f2a50b47d06)参照してください。 ## 準備 {#preparations} -このセクションでは、 TiUPおよびTiUP クラスタコンポーネントのアップグレードを含め、TiDB クラスターをアップグレードする前に必要な準備作業について説明します。 +このセクションでは、 TiUPおよびTiUP クラスターコンポーネントのアップグレードを含め、TiDB クラスターをアップグレードする前に必要な準備作業について説明します。 ### ステップ1：互換性の変更点を確認する {#step-1-review-compatibility-changes} @@ -72,9 +72,9 @@ TiDBのリリースノートで互換性の変更点を確認してください ### ステップ2： TiUPまたはTiUPオフラインミラーをアップグレードする {#step-2-upgrade-tiup-or-tiup-offline-mirror} -TiDBクラスタをアップグレードする前に、まずTiUPまたはTiUPミラーをアップグレードする必要があります。 +TiDBクラスターをアップグレードする前に、まずTiUPまたはTiUPミラーをアップグレードする必要があります。 -#### TiUPとTiUP クラスタをアップグレードする {#upgrade-tiup-and-tiup-cluster} +#### TiUPとTiUP クラスターをアップグレードする {#upgrade-tiup-and-tiup-cluster} > **注記：** > @@ -87,7 +87,7 @@ TiDBクラスタをアップグレードする前に、まずTiUPまたはTiUP tiup --version ``` -2. TiUP クラスタのバージョンをアップグレードしてください。TiUP クラスタのTiUPは`1.11.3`以降を推奨します。 +2. TiUP クラスターのバージョンをアップグレードしてください。TiUP クラスターのTiUPは`1.11.3`以降を推奨します。 ```shell tiup update cluster @@ -100,7 +100,7 @@ TiDBクラスタをアップグレードする前に、まずTiUPまたはTiUP > > アップグレード対象のクラスターがオフライン方式を使用せずにデプロイされている場合は、この手順をスキップしてください。 -新しいバージョンのTiUPミラー[TiUPを使用してTiDBクラスタをデプロイ- TiUPをオフラインでデプロイ](/production-deployment-using-tiup.md#deploy-tiup-offline)を参照してください。 `local_install.sh`を実行すると、 TiUP は上書きアップグレードを完了します。 +新しいバージョンのTiUPミラー[TiUPを使用してTiDBクラスターをデプロイ- TiUPをオフラインでデプロイ](/production-deployment-using-tiup.md#deploy-tiup-offline)を参照してください。 `local_install.sh`を実行すると、 TiUP は上書きアップグレードを完了します。 ```shell tar xzvf tidb-community-server-${version}-linux-amd64.tar.gz @@ -118,7 +118,7 @@ cp -rp keys ~/.tiup/ tiup mirror merge ../tidb-community-toolkit-${version}-linux-amd64 ``` -ミラーをマージした後、次のコマンドを実行してTiUP クラスタコンポーネントをアップグレードします。 +ミラーをマージした後、次のコマンドを実行してTiUP クラスターコンポーネントをアップグレードします。 ```shell tiup update cluster @@ -149,12 +149,12 @@ tiup update cluster アップグレード中に予期せぬ動作やその他の問題が発生するのを避けるため、アップグレード前に以下の項目を確認することをお勧めします。 -- クラスタDDL: +- クラスターDDL: - [スムーズなアップグレード](/smooth-upgrade-tidb.md)アップグレードを使用して TiDB を v8.1.0 以降にアップグレードし、[分散実行フレームワーク（DXF）](/tidb-distributed-execution-framework.md)が有効になっている場合は、アップグレードする前に DXF を無効にすることをお勧めします。そうしないと、アップグレード プロセス中に追加されたインデックスがデータと矛盾し、アップグレードが失敗する可能性があります。 - な を使用しない場合は、 [`ADMIN SHOW DDL`](/sql-statements/sql-statement-admin-show-ddl.md)[スムーズなアップグレード](/smooth-upgrade-tidb.md)を使用して、実行中の DDL ジョブが存在するかどうかを確認することをお勧めします。実行中の DDL ジョブが存在する場合は、アップグレードを実行する前に、ジョブの実行が完了するまで待つか、 [`ADMIN CANCEL DDL`](/sql-statements/sql-statement-admin-cancel-ddl.md)ステートメントを使用してキャンセルしてください。 -- クラスタのバックアップ：クラスタ内でバックアップまたはリストアタスクが実行中かどうかを確認するには[`SHOW [BACKUPS|RESTORES]`](/sql-statements/sql-statement-show-backups.md)コマンドを実行することをお勧めします。実行中の場合は、アップグレードを実行する前にタスクが完了するまでお待ちください。 +- クラスターのバックアップ：クラスター内でバックアップまたはリストアタスクが実行中かどうかを確認するには[`SHOW [BACKUPS|RESTORES]`](/sql-statements/sql-statement-show-backups.md)コマンドを実行することをお勧めします。実行中の場合は、アップグレードを実行する前にタスクが完了するまでお待ちください。 ### ステップ5：現在のクラスターの健全性状態を確認する {#step-5-check-the-health-status-of-the-current-cluster} @@ -167,17 +167,17 @@ tiup cluster check --cluster コマンドが実行されると、「リージョンステータス」のチェック結果が出力されます。 - 結果が「すべてのリージョンは正常です」であれば、現在のクラスター内のすべてのリージョンは正常であり、アップグレードを続行できます。 -- 結果が「リージョンが完全に正常ではありません：m個のミスピア、n個の保留ピア」で、「他の操作を行う前に、異常なリージョンを修正してください。」というメッセージが表示される場合、現在のクラスタ内の一部のリージョンに異常があります。チェック結果が「すべてのリージョンが正常です」になるまで、異常のトラブルシューティングを行う必要があります。その後、アップグレードを続行できます。 +- 結果が「リージョンが完全に正常ではありません：m個のミスピア、n個の保留ピア」で、「他の操作を行う前に、異常なリージョンを修正してください。」というメッセージが表示される場合、現在のクラスター内の一部のリージョンに異常があります。チェック結果が「すべてのリージョンが正常です」になるまで、異常のトラブルシューティングを行う必要があります。その後、アップグレードを続行できます。 -## TiDBクラスタをアップグレードする {#upgrade-the-tidb-cluster} +## TiDBクラスターをアップグレードする {#upgrade-the-tidb-cluster} -このセクションでは、TiDBクラスタをアップグレードする方法と、アップグレード後のバージョンを確認する方法について説明します。 +このセクションでは、TiDBクラスターをアップグレードする方法と、アップグレード後のバージョンを確認する方法について説明します。 -### TiDBクラスタを指定されたバージョンにアップグレードする {#upgrade-the-tidb-cluster-to-a-specified-version} +### TiDBクラスターを指定されたバージョンにアップグレードする {#upgrade-the-tidb-cluster-to-a-specified-version} クラスターのアップグレードは、オンラインアップグレードとオフラインアップグレードの2つの方法のいずれかで行うことができます。 -TiUP クラスタはデフォルトではオンライン方式でTiDBクラスタをアップグレードします。つまり、アップグレード処理中もTiDBクラスタはサービスを提供し続けることができます。オンライン方式では、アップグレードと再起動の前に各ノードでリーダーが1つずつ移行されます。そのため、大規模なクラスタでは、アップグレード操作全体が完了するまでに時間がかかります。 +TiUP クラスターはデフォルトではオンライン方式でTiDBクラスターをアップグレードします。つまり、アップグレード処理中もTiDBクラスターはサービスを提供し続けることができます。オンライン方式では、アップグレードと再起動の前に各ノードでリーダーが1つずつ移行されます。そのため、大規模なクラスターでは、アップグレード操作全体が完了するまでに時間がかかります。 アプリケーションに、データベースのメンテナンスのために停止するメンテナンス期間が設定されている場合、オフラインアップグレード方式を使用することで、アップグレード操作を迅速に実行できます。 @@ -205,7 +205,7 @@ tiup cluster upgrade v8.5.4 #### アップグレード時にコンポーネントのバージョンを指定してください。 {#specify-the-component-version-during-upgrade} -tiup-cluster v1.14.0以降では、クラスタのアップグレード時に特定のコンポーネントを特定のバージョンに指定できるようになりました。別のバージョンを指定しない限り、これらのコンポーネントは以降のアップグレードでも固定バージョンのままになります。 +tiup-cluster v1.14.0以降では、クラスターのアップグレード時に特定のコンポーネントを特定のバージョンに指定できるようになりました。別のバージョンを指定しない限り、これらのコンポーネントは以降のアップグレードでも固定バージョンのままになります。 > **注記：** > @@ -234,7 +234,7 @@ tiup cluster upgrade -h | grep "version" tiup cluster stop ``` -2. `upgrade`コマンドに`--offline`オプションを指定して、オフラインアップグレードを実行します。 ``にはクラスタ名を、 ``にはアップグレード先のバージョン（例: `v8.5.4`入力します。 +2. `upgrade`コマンドに`--offline`オプションを指定して、オフラインアップグレードを実行します。 ``にはクラスター名を、 ``にはアップグレード先のバージョン（例: `v8.5.4`入力します。 ```shell tiup cluster upgrade --offline @@ -248,7 +248,7 @@ tiup cluster upgrade -h | grep "version" ### クラスターのバージョンを確認します {#verify-the-cluster-version} -`display`コマンドを実行して、最新のクラスタバージョン`TiDB Version`を表示します。 +`display`コマンドを実行して、最新のクラスターバージョン`TiDB Version`を表示します。 ```shell tiup cluster display @@ -260,7 +260,7 @@ tiup cluster display ## FAQ {#faq} -このセクションでは、 TiUPを使用して TiDB クラスタを更新する際に発生する一般的な問題について説明します。 +このセクションでは、 TiUPを使用して TiDB クラスターを更新する際に発生する一般的な問題について説明します。 ### エラーが発生してアップグレードが中断された場合、エラーを修正した後、どのようにアップグレードを再開すればよいですか？ {#if-an-error-occurs-and-the-upgrade-is-interrupted-how-to-resume-the-upgrade-after-fixing-this-error} @@ -282,7 +282,7 @@ tiup cluster display ### バージョン6.2.0以降へのアップグレード時にアップグレード処理が停止してしまう問題を解決するにはどうすればよいですか？ {#how-to-fix-the-issue-that-the-upgrade-gets-stuck-when-upgrading-to-v6-2-0-or-later-versions} -バージョン6.2.0以降、TiDBはデフォルトで[並行DDLフレームワーク](/best-practices/ddl-introduction.md#how-the-online-ddl-asynchronous-change-works-in-tidb)を有効にし、同時DDLの実行を可能にしました。このフレームワークは、DDLジョブのstorageをKVキューからテーブルキューに変更します。この変更により、一部のシナリオではアップグレードが停止する可能性があります。この問題が発生する可能性のあるシナリオと、それに対応する解決策を以下に示します。 +バージョン6.2.0以降、TiDBはデフォルトで[並行DDLフレームワーク](/best-practices/ddl-introduction.md#how-the-online-ddl-asynchronous-change-works-in-tidb)を有効にし、同時DDLの実行を可能にしました。このフレームワークは、DDLジョブのストレージをKVキューからテーブルキューに変更します。この変更により、一部のシナリオではアップグレードが停止する可能性があります。この問題が発生する可能性のあるシナリオと、それに対応する解決策を以下に示します。 - プラグインの読み込みが原因でアップグレードが停止します @@ -312,7 +312,7 @@ tiup cluster display tiup cluster upgrade --force ``` -### TiDBクラスタをアップグレードした後、pd-ctlなどのツールのバージョンを更新するにはどうすればよいですか？ {#how-to-update-the-version-of-tools-such-as-pd-ctl-after-upgrading-the-tidb-cluster} +### TiDBクラスターをアップグレードした後、pd-ctlなどのツールのバージョンを更新するにはどうすればよいですか？ {#how-to-update-the-version-of-tools-such-as-pd-ctl-after-upgrading-the-tidb-cluster} TiUPを使用して対応するコンポーネントの`ctl`コンポーネントをインストールすることで、ツールのバージョンをアップグレードできます。 diff --git a/wrong-index-solution.md b/wrong-index-solution.md index f4c6d56a1ff40..65381573efae8 100644 --- a/wrong-index-solution.md +++ b/wrong-index-solution.md @@ -12,8 +12,8 @@ summary: 間違ったインデックスの問題を解決する方法を学び - **古い統計**：オプティマイザーはクエリコストを推定するために統計を使用します。統計が古い場合、オプティマイザーは最適ではない選択を行う可能性があります。 - **統計の不一致**: 統計が最新であっても、データの分布を正確に反映していない可能性があり、コストの見積もりが不正確になる可能性があります。 - **コスト計算が正しくありません**: クエリ構造やデータ分散が複雑なため、オプティマイザーがインデックスの使用コストを誤って計算する場合があります。 -- **不適切なエンジンの選択**: 場合によっては、オプティマイザーがクエリに最適ではないstorageエンジンを選択することがあります。 -- **関数のプッシュダウンの制限**: 特定の関数または操作がstorageエンジンにプッシュダウンされない可能性があり、クエリのパフォーマンスに影響する可能性があります。 +- **不適切なエンジンの選択**: 場合によっては、オプティマイザーがクエリに最適ではないストレージエンジンを選択することがあります。 +- **関数のプッシュダウンの制限**: 特定の関数または操作がストレージエンジンにプッシュダウンされない可能性があり、クエリのパフォーマンスに影響する可能性があります。 ## 統計の健康 {#statistics-health} @@ -53,7 +53,7 @@ summary: 間違ったインデックスの問題を解決する方法を学び ## 関数プッシュダウン {#function-pushdown} -クエリパフォーマンスを向上させるため、TiDB は特定の関数をTiKV またはTiFlashstorageエンジンにプッシュダウンして実行できます。ただし、一部の関数はプッシュダウンをサポートしていないため、利用可能な実行プランが制限され、クエリパフォーマンスに影響を及ぼす可能性があります。 +クエリパフォーマンスを向上させるため、TiDB は特定の関数をTiKV またはTiFlashストレージエンジンにプッシュダウンして実行できます。ただし、一部の関数はプッシュダウンをサポートしていないため、利用可能な実行プランが制限され、クエリパフォーマンスに影響を及ぼす可能性があります。 プッシュダウンをサポートする式については、 [TiKVはプッシュダウン計算をサポート](/functions-and-operators/expressions-pushed-down.md)と[TiFlashはプッシュダウン計算をサポート](/tiflash/tiflash-supported-pushdown-calculations.md)参照してください。