From 09477314755b391a82bb90fac2432e53f0025e28 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Thu, 11 Jun 2026 09:53:34 +0900 Subject: [PATCH 1/2] i18n(ja): Fix unnatural translations from MT commit 1e2e78a --- ...up-and-restore-using-dumpling-lightning.md | 26 +++++++------- basic-features.md | 20 +++++------ basic-sql-operations.md | 6 ++-- dm/dm-hardware-and-software-requirements.md | 4 +-- hardware-and-software-requirements.md | 16 ++++----- migrate-aurora-to-tidb.md | 10 +++--- migrate-from-csv-files-to-tidb.md | 6 ++-- migrate-from-parquet-files-to-tidb.md | 16 ++++----- migrate-from-sql-files-to-tidb.md | 6 ++-- migrate-large-mysql-shards-to-tidb.md | 16 ++++----- migrate-large-mysql-to-tidb.md | 24 ++++++------- pd-recover.md | 14 ++++---- tidb-cloud/architecture-concepts.md | 35 +++++++++---------- tidb-cloud/backup-and-restore-serverless.md | 2 +- tidb-cloud/branch-overview.md | 4 +-- tidb-cloud/essential-changefeed-overview.md | 4 +-- .../essential-changefeed-sink-to-kafka.md | 8 ++--- .../essential-changefeed-sink-to-mysql.md | 4 +-- .../dual-layer-data-encryption-premium.md | 4 +-- .../premium/tidb-cloud-auditing-premium.md | 2 +- .../releases/tidb-cloud-release-notes.md | 12 +++---- tidb-cloud/select-cluster-tier.md | 2 +- tidb-cloud/serverless-high-availability.md | 4 +-- ...less-private-link-connection-to-aws-rds.md | 6 ++-- ...e-endpoint-connections-on-alibaba-cloud.md | 2 +- tidb-cloud/tidb-cloud-glossary.md | 12 +++---- tidb-cloud/top-ru.md | 6 ++-- .../tidb-lightning-distributed-import.md | 2 +- tidb-lightning/tidb-lightning-prechecks.md | 2 +- 29 files changed, 137 insertions(+), 138 deletions(-) diff --git a/backup-and-restore-using-dumpling-lightning.md b/backup-and-restore-using-dumpling-lightning.md index f4b886ab1d047..260a2af807760 100644 --- a/backup-and-restore-using-dumpling-lightning.md +++ b/backup-and-restore-using-dumpling-lightning.md @@ -9,7 +9,7 @@ summary: DumplingとTiDB Lightningを使用して、TiDBの完全なデータを 少量のデータ（例えば、50 GiB未満）をバックアップする必要があり、高速なバックアップ速度を必要としない場合は、 [Dumpling](/dumpling-overview.md)を使用してTiDBデータベースからデータをエクスポートし、その後[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md)を使用して別のTiDBデータベースにデータを復元することができます。 -大規模なデータベースをバックアップする必要がある場合は、 [BR](/br/backup-and-restore-overview.md)使用することをお勧めします。DumplingDumpling大規模なデータベースをエクスポートできますが、 BRの方が適しています。 +大規模なデータベースをバックアップする必要がある場合は、 [BR](/br/backup-and-restore-overview.md)を使用することをお勧めします。Dumplingは大規模なデータベースもエクスポートできますが、 BRの方が適しています。 ## 要件 {#requirements} @@ -31,7 +31,7 @@ summary: DumplingとTiDB Lightningを使用して、TiDBの完全なデータを ## リソース要件 {#resource-requirements} -**オペレーティングシステム**: このドキュメントの例では、新規の CentOS 7 インスタンスを使用しています。仮想マシンは、ローカル ホストまたはクラウドにデプロイできます。TiDB TiDB Lightning はデフォルトで必要なだけの CPU リソースを消費するため、専用サーバーにデプロイすることをお勧めします。それが不可能な場合は、他の TiDB コンポーネント (たとえば`tikv-server` ) と一緒に単一のサーバーにデプロイし、 `region-concurrency`を構成して、 TiDB Lightningの CPU 使用率を制限できます。通常、論理 CPU の 75% にサイズを設定できます。 +**オペレーティングシステム**: このドキュメントの例では、新規の CentOS 7 インスタンスを使用しています。仮想マシンは、ローカル ホストまたはクラウドにデプロイできます。TiDB Lightning はデフォルトで必要なだけの CPU リソースを消費するため、専用サーバーにデプロイすることをお勧めします。それが不可能な場合は、他の TiDB コンポーネント (たとえば`tikv-server` ) と一緒に単一のサーバーにデプロイし、 `region-concurrency`を構成して、 TiDB Lightningの CPU 使用率を制限できます。通常、論理 CPU の 75% にサイズを設定できます。 **メモリとCPU** ： TiDB Lightningは多くのリソースを消費するため、64 GiB以上のメモリと32以上のCPUコアを割り当てることを推奨します。最高のパフォーマンスを得るには、CPUコアとメモリ（GiB）の比率が1:2以上であることを確認してください。 @@ -41,10 +41,10 @@ summary: DumplingとTiDB Lightningを使用して、TiDBの完全なデータを バックアップタスクのデータをローカルディスクに保存する必要がある場合は、以下の制限事項に注意してください。 -- Dumplingには、データ ソース全体を保存できる (またはエクスポートされるすべてのアップストリーム テーブルを保存できる) ディスク容量が必要です。必要なスペースを計算するには、 [下流のstorageスペース要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。 -- インポート処理中、 TiDB Lightningはソート済みのキーと値のペアを保存するための一時的な領域を必要とします。ディスク容量は、データソースから取得した最大の単一テーブルを格納できるだけの十分な量が必要です。 +- Dumplingには、データソース全体を保存できる（またはエクスポートされるすべての上流テーブルを保存できる）ディスク容量が必要です。必要なスペースを計算するには、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。 +- インポート処理中、 TiDB Lightningはソート済みのキーと値のペアを保存するための一時的な領域を必要とします。ディスク容量は、データソースの最大の単一テーブルを格納できるのに十分な量が必要です。 -**注**： DumplingによってMySQLからエクスポートされる正確なデータ量を計算することは困難ですが、次のSQLステートメントを使用して`DATA_LENGTH`テーブルの`information_schema.tables`フィールドを要約することで、データ量を推定できます。 +**注記：** DumplingによってMySQLからエクスポートされる正確なデータ量を計算することは困難ですが、次のSQLステートメントを使用して`information_schema.tables`テーブルの`DATA_LENGTH`フィールドを要約することで、データ量を推定できます。 ```sql -- Calculate the size of all schemas @@ -77,10 +77,10 @@ LIMIT ### ターゲットとなるTiKVクラスターのディスク容量 {#disk-space-for-the-target-tikv-cluster} -対象の TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、対象の TiKV クラスターのstorage容量は**、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、対象の TiKV クラスターは、データソースのサイズの 6 倍よりも大きなstorage容量が必要です。この式に x 2 が含まれている理由は次のとおりです。 +ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットの TiKV クラスターのストレージ容量は**、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、ターゲットの TiKV クラスターは、データソースのサイズの 6 倍よりも大きなストレージ容量が必要です。この式に x 2 が含まれている理由は次のとおりです。 -- インデックス作成には余分なスペースが必要になる場合があります。 -- RocksDBには空間増幅効果がある。 +- インデックスには余分な容量が必要になる場合があります。 +- RocksDBには空間増幅がある。 ## Dumplingを使用してフルデータをバックアップします {#use-dumpling-to-back-up-full-data} @@ -94,11 +94,11 @@ LIMIT Dumplingのその他の構成については、 [Dumplingのオプション一覧](/dumpling-overview.md#option-list-of-dumpling)参照してください。 -2. エクスポートが完了すると、ディレクトリ`s3://my-bucket/sql-backup`でバックアップファイルを表示できます。 +2. エクスポートが完了すると、ディレクトリ`s3://my-bucket/sql-backup`でバックアップファイルを確認できます。 ## TiDB Lightningを使用して完全なデータを復元します。 {#use-tidb-lightning-to-restore-full-data} -1. `tidb-lightning.toml`ファイルを編集して、 Dumplingを使用して`s3://my-bucket/sql-backup`からターゲットの TiDB クラスタにバックアップされた完全なデータをインポートします。 +1. `tidb-lightning.toml`ファイルを編集して、Dumplingを使用して`s3://my-bucket/sql-backup`にバックアップされた完全なデータを、ターゲットのTiDBクラスターにインポートします。 ```toml [lightning] @@ -127,7 +127,7 @@ 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`ツールを使用してプログラムを実行することをお勧めします。例: @@ -139,9 +139,9 @@ LIMIT nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out 2>&1 & ``` -3. インポートが開始されたら、ログ内のキーワード`progress` `grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 +3. インポートが開始されたら、ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 -4. TiDB Lightning はインポートが完了すると自動的に終了します。最後の行に`tidb-lightning.log`に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 +4. TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 > **注記：** > diff --git a/basic-features.md b/basic-features.md index b8dea2610ccbc..b813c202542e4 100644 --- a/basic-features.md +++ b/basic-features.md @@ -55,7 +55,7 @@ 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 | +| [式インデックス](/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 | | [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 | @@ -120,9 +120,9 @@ summary: TiDBの機能概要について学びましょう。 | [過去の実行計画に従ってバインディングを作成する](/sql-plan-management.md#create-a-binding-according-to-a-historical-execution-plan) | Y | Y | Y | Y | E | N | N | | [コプロセッサーキャッシュ](/coprocessor-cache.md) | Y | Y | Y | Y | Y | Y | Y | | [ステイル読み取り](/stale-read.md) | Y | Y | Y | Y | Y | Y | Y | -| [Followerが読む](/follower-read.md) | Y | Y | Y | Y | Y | Y | Y | +| [フォロワーリード](/follower-read.md) | Y | Y | Y | Y | Y | Y | Y | | [過去のデータ（tidb_snapshot）を読み込む](/read-historical-data.md) | Y | Y | Y | Y | Y | Y | Y | -| [オプティマイザのヒント](/optimizer-hints.md) | Y | Y | Y | Y | Y | Y | Y | +| [オプティマイザヒント](/optimizer-hints.md) | Y | Y | Y | Y | Y | Y | Y | | [MPP実行エンジン](/explain-mpp.md) | Y | Y | Y | Y | Y | Y | Y | | [MPP実行エンジン - 圧縮交換](/explain-mpp.md#mpp-version-and-exchange-data-compression) | Y | Y | Y | Y | N | N | N | | [TiFlashパイプラインモデル](/tiflash/tiflash-pipeline-model.md) | Y | Y | Y | N | N | N | N | @@ -142,7 +142,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 | @@ -161,17 +161,17 @@ summary: TiDBの機能概要について学びましょう。 -## 取引 {#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 | +| [1PC](/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 | @@ -242,7 +242,7 @@ summary: TiDBの機能概要について学びましょう。 | [パスワード管理](/password-management.md) | Y | Y | Y | Y | Y | N | N | | [MySQL互換の`GRANT`システム](/privilege-management.md) | Y | Y | Y | Y | Y | Y | Y | | [動的権限](/privilege-management.md#dynamic-privileges) | Y | Y | Y | Y | Y | Y | Y | -| [Security強化モード](/system-variables.md#tidb_enable_enhanced_security) | Y | Y | Y | Y | Y | Y | Y | +| [セキュリティ強化モード](/system-variables.md#tidb_enable_enhanced_security) | Y | Y | Y | Y | Y | Y | Y | | [編集済みログファイル](/log-redaction.md) | Y | Y | Y | Y | Y | Y | Y | diff --git a/basic-sql-operations.md b/basic-sql-operations.md index b6e761132c73a..e73cbf275c80c 100644 --- a/basic-sql-operations.md +++ b/basic-sql-operations.md @@ -3,17 +3,17 @@ 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)参照してください。 -SQLを試したり、TiDBとMySQLクエリの互換性をテストしたりするには、 [TiDB Playground](https://play.tidbcloud.com/?utm_source=docs&utm_medium=basic-sql-operations)お試しください。また、まずTiDBクラスタをデプロイしてから、その中でSQL文を実行することもできます。 +SQLを試したり、TiDBとMySQLクエリの互換性をテストしたりするには、 [TiDB Playground](https://play.tidbcloud.com/?utm_source=docs&utm_medium=basic-sql-operations)を試すことができます。また、まずTiDBクラスターをデプロイしてから、その中でSQL文を実行することもできます。 -このページでは、DDL、DML、CRUD 操作などの基本的なTiDB SQLステートメントについて説明します。 TiDB ステートメントの完全なリストについては、 [SQLステートメントの概要](/sql-statements/sql-statement-overview.md)参照してください。 +このページでは、DDL、DML、CRUD操作などのTiDB SQL文について解説します。TiDB文の完全なリストについては、 [SQLステートメントの概要](/sql-statements/sql-statement-overview.md)を参照してください。 ## カテゴリ {#category} diff --git a/dm/dm-hardware-and-software-requirements.md b/dm/dm-hardware-and-software-requirements.md index 4933893ed7955..071636cf70594 100644 --- a/dm/dm-hardware-and-software-requirements.md +++ b/dm/dm-hardware-and-software-requirements.md @@ -47,9 +47,9 @@ DMは、64ビット汎用ハードウェアサーバープラットフォーム > - 本番環境では、DM-master と DM-worker を同じサーバーに導入して実行することは推奨されません。DM-worker がディスクにデータを書き込むと、DM-master の高可用性コンポーネントによるディスクの使用が妨げられる可能性があるためです。 > - パフォーマンスの問題が発生した場合は、ドキュメント[DMのコンフィグレーションを最適化する](/dm/dm-tune-configuration.md)に従ってタスク設定ファイルを変更することをお勧めします。設定ファイルを調整してもパフォーマンスが効果的に最適化されない場合は、サーバーのハードウェアをアップグレードしてみてください。 -## 下流のstorageスペース要件 {#downstream-storage-space-requirements} +## ターゲットデータベースのストレージ要件 {#downstream-storage-space-requirements} -ターゲットTiKVクラスターには、インポートしたデータを保存するための十分なディスク容量が必要です。1 に加え[標準的なハードウェア要件](/hardware-and-software-requirements.md) 、ターゲットTiKVクラスターのstorage容量**は、データソースのサイズ × レプリカ数 × 2**よりも大きくなければなりません。例えば、クラスターがデフォルトで3つのレプリカを使用する場合、ターゲットTiKVクラスターには、データソースのサイズの6倍よりも大きなstorage容量が必要です。式に`x 2`含まれているのは、以下の理由からです。 +ターゲットTiKVクラスターには、インポートしたデータを保存するための十分なディスク容量が必要です。[標準的なハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットTiKVクラスターのストレージ容量は**データソースのサイズ × レプリカ数 × 2**よりも大きくなければなりません。例えば、クラスターがデフォルトで3つのレプリカを使用する場合、ターゲットTiKVクラスターには、データソースのサイズの6倍よりも大きなストレージ容量が必要です。式に`x 2`が含まれているのは、以下の理由からです。 - インデックスは余分なスペースを占める可能性があります。 - RocksDB には空間増幅効果があります。 diff --git a/hardware-and-software-requirements.md b/hardware-and-software-requirements.md index e8c64218935d4..0fa1cdd1f671d 100644 --- a/hardware-and-software-requirements.md +++ b/hardware-and-software-requirements.md @@ -53,7 +53,7 @@ TiDBはv8.5 LTSにおいて、様々なオペレーティングシステムとCP | TiDBのコンパイルと実行に必要なライブラリ | バージョン | | :--------------------- | :----------------- | | Golang | 1.23以降 | -| さび | 毎晩 - 2023年12月28日以降 | +| Rust | nightly - 2023年12月28日以降 | | GCC | 7.x | | LLVM | バージョン17.0以降 | @@ -84,8 +84,8 @@ TiDBの実行に必要なライブラリ：glibc（バージョン2.28-151.el8 | ソフトウェア | バージョン | | :------ | :---------- | | sshpass | バージョン1.06以降 | -| 沼 | 2.0.12以降 | -| タール | どれでも | +| NUMA | 2.0.12以降 | +| tar | 任意 | ## サーバー要件 {#server-requirements} @@ -97,7 +97,7 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ | :-----: | :----: | :----: | :---------------------------: | :------------: | :------------------: | | TiDB | 8コア以上 | 16GB以上 | [保管要件](#storage-requirements) | ギガビットネットワークカード | 1（PDと同じマシンに展開可能） | | PD | 4コア以上 | 8GB以上 | SAS、200GB以上 | ギガビットネットワークカード | 1（TiDBと同じマシンにデプロイ可能） | -| ティクヴ | 8コア以上 | 32GB以上 | SAS、200GB以上 | ギガビットネットワークカード | 3 | +| TiKV | 8コア以上 | 32GB以上 | SAS、200GB以上 | ギガビットネットワークカード | 3 | | TiFlash | 32コア以上 | 64GB以上 | SSD、200GB以上 | ギガビットネットワークカード | 1 | | TiCDC | 8コア以上 | 16GB以上 | SAS、200GB以上 | ギガビットネットワークカード | 1 | | TiProxy | 4コア以上 | 8GB以上 | SAS | ギガビットネットワークカード | 1 | @@ -116,7 +116,7 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ | :-----: | :----: | :-----: | :--------: | :--------------------: | :-----------: | | TiDB | 16コア以上 | 48GB以上 | SSD | 10ギガビットネットワークカード（2枚推奨） | 2 | | PD | 8コア以上 | 16GB以上 | SSD | 10ギガビットネットワークカード（2枚推奨） | 3 | -| ティクヴ | 16コア以上 | 64GB以上 | SSD | 10ギガビットネットワークカード（2枚推奨） | 3 | +| TiKV | 16コア以上 | 64GB以上 | SSD | 10ギガビットネットワークカード（2枚推奨） | 3 | | TiFlash | 48コア以上 | 128GB以上 | 1つ以上のSSD | 10ギガビットネットワークカード（2枚推奨） | 2 | | TiCDC | 16コア以上 | 64GB以上 | SSD | 10ギガビットネットワークカード（2枚推奨） | 2 | | モニター | 8コア以上 | 16GB以上 | SAS | ギガビットネットワークカード | 1 | @@ -158,8 +158,8 @@ TiCDCを導入する前に、500GB以上のPCIe SSDディスクにTiCDCを導入 | :-------------: | :------: | :----------------------------------------------- | | TiDB | 4000 | アプリケーションおよびDBAツール用の通信ポート | | TiDB | 10080 | TiDBの状態を報告するための通信ポート | -| ティクヴ | 20160 | TiKV通信ポート | -| ティクヴ | 20180 | TiKVの状態を報告するための通信ポート | +| TiKV | 20160 | TiKV通信ポート | +| TiKV | 20180 | TiKVの状態を報告するための通信ポート | | PD | 2379 | TiDBとPD間の通信ポート | | PD | 2380 | PDクラスタ内のノード間通信ポート | | TiFlash | 9000 | TiFlash TCPサービスポート | @@ -178,7 +178,7 @@ TiCDCを導入する前に、500GB以上のPCIe SSDディスクにTiCDCを導入 ## 保管要件 {#storage-requirements} -
成分ディスク容量要件ディスクの使用状況は良好です
TiDB
  • ログディスクには最低30GBが必要です
  • バージョン6.5.0以降、インデックスの追加などのDDL操作を高速化するために、Fast Online DDL（tidb_ddl_enable_fast_reorg変数で制御）がデフォルトで有効になっています。アプリケーションで大きなオブジェクトを含むDDL操作がある場合、またはIMPORT INTOを使用してデータをインポートする場合は、TiDB用にSSDディスク領域を追加で用意することを強くお勧めします（100GB以上）。詳細な設定手順については、 「TiDBインスタンスの一時領域を設定する」を参照してください。
 90%未満
PDデータディスクとログディスクにはそれぞれ最低20GBの容量が必要です。 90%未満
ティクヴデータディスクとログディスクにはそれぞれ最低100GBが必要です。 80%未満
TiFlashデータディスクには最低100GB、ログディスクには最低30GBが必要です。 80%未満
TiUP
  • コントロールマシン：単一バージョンのTiDBクラスタをデプロイする場合、必要な容量は1GB以下です。複数のバージョンのTiDBクラスタをデプロイする場合は、必要な容量が増加します。
  • デプロイメントサーバー（TiDBコンポーネントが実行されるマシン）： TiFlashは約700MBの容量を占有し、その他のコンポーネント（PD、TiDB、TiKVなど）はそれぞれ約200MBの容量を占有します。クラスターのデプロイメントプロセス中、 TiUPクラスターは一時ファイルを保存するために1MB未満の一時領域（ /tmpディレクトリ）を必要とします。
該当なし
ンモニタリング
  • Conprof: 3 x 1 GB x コンポーネント数（各コンポーネントは1日あたり約1 GB、合計3日間）+ 20 GBの予約済みスペース
  • Top SQL：30 x 50MB x コンポーネント数（各コンポーネントは1日あたり約50MBを占有し、合計30日間）
  • ConprofとTop SQLは予約スペースを共有しています。
該当なし
+
コンポーネントディスク容量要件ディスク使用率は良好です
TiDB
  • ログディスクには最低30GBが必要です
  • バージョン6.5.0以降、インデックスの追加などのDDL操作を高速化するために、Fast Online DDL（tidb_ddl_enable_fast_reorg変数で制御）がデフォルトで有効になっています。アプリケーションで大きなオブジェクトを含むDDL操作がある場合、またはIMPORT INTOを使用してデータをインポートする場合は、TiDB用にSSDディスク領域を追加で用意することを強くお勧めします（100GB以上）。詳細な設定手順については、 「TiDBインスタンスの一時領域を設定する」を参照してください。
 90%未満
PDデータディスクとログディスクにはそれぞれ最低20GBの容量が必要です。 90%未満
TiKVデータディスクとログディスクにはそれぞれ最低100GBが必要です。 80%未満
TiFlashデータディスクには最低100GB、ログディスクには最低30GBが必要です。 80%未満
TiUP
  • コントロールマシン：単一バージョンのTiDBクラスターをデプロイする場合、必要な容量は1GB以下です。複数のバージョンのTiDBクラスターをデプロイする場合は、必要な容量が増加します。
  • デプロイメントサーバー（TiDBコンポーネントが実行されるマシン）： TiFlashは約700MBの容量を占有し、その他のコンポーネント（PD、TiDB、TiKVなど）はそれぞれ約200MBの容量を占有します。クラスターのデプロイメントプロセス中、 TiUPクラスターは一時ファイルを保存するために1MB未満の一時領域（ /tmpディレクトリ）を必要とします。
該当なし
モニタリング
  • Conprof: 3 x 1 GB x コンポーネント数（各コンポーネントは1日あたり約1 GB、合計3日間）+ 20 GBの予約済みスペース
  • Top SQL：30 x 50MB x コンポーネント数（各コンポーネントは1日あたり約50MBを占有し、合計30日間）
  • ConprofとTop SQLは予約スペースを共有しています。
該当なし
TiDBはXFSおよびExt4ファイルシステムをサポートしています。その他のファイルシステムは、本番は推奨されません。 diff --git a/migrate-aurora-to-tidb.md b/migrate-aurora-to-tidb.md index d381bcf3a00a3..995551e91c0c9 100644 --- a/migrate-aurora-to-tidb.md +++ b/migrate-aurora-to-tidb.md @@ -72,11 +72,11 @@ sorted-kv-dir = "${path}" data-source-dir = "s3://my-bucket/schema-backup" ``` -TiDB クラスターで TLS を有効にする必要がある場合は、 [TiDB Lightning のコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 +TiDBクラスターでTLSを有効にする必要がある場合は、 [TiDB Lightningの構成](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 #### 1.3 スキーマファイルをTiDBにインポートする {#1-3-import-the-schema-file-to-tidb} -TiDB Lightningを使用して、スキーマファイルを下流のTiDBにインポートします。 +TiDB Lightningを使用して、スキーマファイルをターゲットのTiDBにインポートします。 ```shell export AWS_ACCESS_KEY_ID=${access_key} @@ -146,7 +146,7 @@ table = '$2' type = '$3' ``` -TiDB クラスターで TLS を有効にする必要がある場合は、 [TiDB Lightning のコンフィグレーション](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 +TiDBクラスターでTLSを有効にする必要がある場合は、 [TiDB Lightningの構成](/tidb-lightning/tidb-lightning-configuration.md)を参照してください。 #### 2.3 TiDBへの全データのインポート {#2-3-import-full-data-to-tidb} @@ -160,11 +160,11 @@ TiDB クラスターで TLS を有効にする必要がある場合は、 [TiDB 2. インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 - - {{B `progress` `grep`キーワードがログに記録されます。デフォルトでは、進行状況は 5 分ごとに更新されます。 + - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進捗状況を確認します。 - [TiDB Lightning Webインターフェース](/tidb-lightning/tidb-lightning-web-interface.md)で進行状況を確認します。 -3. TiDB Lightning はインポートが完了すると自動的に終了します。最後の行に`tidb-lightning.log`に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 +3. TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 > **注記：** > diff --git a/migrate-from-csv-files-to-tidb.md b/migrate-from-csv-files-to-tidb.md index 3b682e8367b71..d584543ce63c0 100644 --- a/migrate-from-csv-files-to-tidb.md +++ b/migrate-from-csv-files-to-tidb.md @@ -16,7 +16,7 @@ TiDB Lightningは、CSVファイルやタブ区切り値（TSV）などの他の ## ステップ1. CSVファイルを準備する {#step-1-prepare-the-csv-files} -すべてのCSVファイルを同じディレクトリに配置してください。TiDB TiDB LightningがすべてのCSVファイルを認識する必要がある場合は、ファイル名が以下の要件を満たす必要があります。 +すべてのCSVファイルを同じディレクトリに配置してください。TiDB LightningがすべてのCSVファイルを認識する必要がある場合は、ファイル名が以下の要件を満たす必要があります。 - CSV ファイルにテーブル全体のデータが含まれている場合は、ファイル名を`${db_name}.${table_name}.csv`とします。 - 1つのテーブルのデータが複数のCSVファイルに分割されている場合は、これらのCSVファイルに数値サフィックスを追加してください。例： `${db_name}.${table_name}.003.csv` 。数値サフィックスは連続していなくても構いませんが、昇順である必要があります。また、すべてのサフィックスの長さが同じになるように、数値の前にゼロを追加する必要があります。 @@ -126,11 +126,11 @@ nohup tiup tidb-lightning -config tidb-lightning.toml > nohup.out 2>&1 & インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 -- {{B `progress` `grep`キーワードがログに記録されます。デフォルトでは、進行状況は 5 分ごとに更新されます。 +- ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進行状況を確認します。 - [TiDB Lightning Webインターフェース](/tidb-lightning/tidb-lightning-web-interface.md)で進行状況を確認します。 -TiDB Lightning はインポートが完了すると自動的に終了します。最後の行に`tidb-lightning.log`に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 +TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 > **注記：** > diff --git a/migrate-from-parquet-files-to-tidb.md b/migrate-from-parquet-files-to-tidb.md index a50cd1753addc..33afa7b6c5631 100644 --- a/migrate-from-parquet-files-to-tidb.md +++ b/migrate-from-parquet-files-to-tidb.md @@ -5,20 +5,20 @@ summary: ParquetファイルからTiDBへのデータ移行方法を学びまし # ParquetファイルからTiDBへのデータ移行 {#migrate-data-from-parquet-files-to-tidb} -このドキュメントでは、Apache Hive から parquet ファイルを生成する方法と、 TiDB Lightningを使用して parquet ファイルから TiDB にデータを移行する方法について説明します。 +このドキュメントでは、Apache Hive から Parquet ファイルを生成する方法と、 TiDB Lightningを使用して Parquet ファイルから TiDB にデータを移行する方法について説明します。 -Amazon Auroraから寄木細工ファイルをエクスポートする場合は、 [Amazon AuroraからTiDBへデータを移行する](/migrate-aurora-to-tidb.md)を参照してください。 +Amazon AuroraからParquetファイルをエクスポートする場合は、 [Amazon AuroraからTiDBへデータを移行する](/migrate-aurora-to-tidb.md)を参照してください。 ## 前提条件 {#prerequisites} - [TiUPを使用してTiDB Lightningをインストールする](/migration-tools.md)。 - [TiDB Lightningに必要なターゲットデータベース権限を取得します。](/tidb-lightning/tidb-lightning-faq.md#what-are-the-privilege-requirements-for-the-target-database) -## ステップ1. 寄木細工のファイルを用意する {#step-1-prepare-the-parquet-files} +## ステップ1. Parquetファイルを用意する {#step-1-prepare-the-parquet-files} このセクションでは、 TiDB Lightningで読み取れる Parquet ファイルを Hive からエクスポートする方法について説明します。 -Hive の各テーブルは`STORED AS PARQUET LOCATION '/path/in/hdfs'`という注釈を付けることで、parquet ファイルにエクスポートできます。したがって、 `test`という名前のテーブルをエクスポートする必要がある場合は、次の手順を実行します。 +Hive の各テーブルは`STORED AS PARQUET LOCATION '/path/in/hdfs'`という注釈を付けることで、Parquet ファイルにエクスポートできます。したがって、 `test`という名前のテーブルをエクスポートする必要がある場合は、次の手順を実行します。 1. Hiveで以下のSQL文を実行してください。 @@ -29,13 +29,13 @@ Hive の各テーブルは`STORED AS PARQUET LOCATION '/path/in/hdfs'`という 上記のステートメントを実行すると、テーブルデータはHDFSシステムに正常にエクスポートされます。 -2. `hdfs dfs -get`コマンドを使用して、parquet ファイルをローカルファイルシステムにエクスポートします。 +2. `hdfs dfs -get`コマンドを使用して、Parquet ファイルをローカルファイルシステムにエクスポートします。 ```shell hdfs dfs -get /path/in/hdfs /path/in/local ``` - エクスポートが完了した後、HDFS 内のエクスポートされた parquet ファイルを削除する必要がある場合は、一時テーブル ( `temp` } ) を直接削除できます。 + エクスポートが完了した後、HDFS 内のエクスポートされた Parquet ファイルを削除する必要がある場合は、一時テーブル ( `temp` ) を直接削除できます。 ```sql DROP TABLE temp; @@ -43,7 +43,7 @@ Hive の各テーブルは`STORED AS PARQUET LOCATION '/path/in/hdfs'`という 3. Hive からエクスポートされた Parquet ファイルには`.parquet`サフィックスが付いていない場合があり、 TiDB Lightningで正しく識別できない可能性があります。そのため、ファイルをインポートする前に、エクスポートされたファイルの名前を変更し、 `.parquet`サフィックスを追加して、ファイル名全体をTiDB Lightning が認識する形式（例: `${db_name}. ${table_name}.parquet`に変更する必要があります。ファイルの種類とパターンに関する詳細については、 [TiDB Lightningデータソース](/tidb-lightning/tidb-lightning-data-source.md)を参照してください。また、正しい[カスタマイズされた表現](/tidb-lightning/tidb-lightning-data-source.md#match-customized-files)を設定することでデータ ファイルを一致させることもできます。 -4. すべての Parquet ファイルを、例えば`/data/my_datasource/`や`s3://my-bucket/sql-backup`のような単一のディレクトリに配置してください。TiDB TiDB Lightning は、このディレクトリとそのサブディレクトリ内のすべての`.parquet`ファイルを再帰的に検索します。 +4. すべての Parquet ファイルを、例えば`/data/my_datasource/`や`s3://my-bucket/sql-backup`のような単一のディレクトリに配置してください。TiDB Lightning は、このディレクトリとそのサブディレクトリ内のすべての`.parquet`ファイルを再帰的に検索します。 ## ステップ2. 対象テーブルのスキーマを作成する {#step-2-create-the-target-table-schema} @@ -113,7 +113,7 @@ pd-addr = "${ip}:${port}" # The address of the PD cluster, e.g.: 172.16.31.3:237 2. インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 - - `progress`を使用して、ログ内でキーワード`grep` } を検索してください。進捗状況はデフォルトで 5 分ごとに更新されます。 + - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進捗状況を確認してください。 - [TiDB Lightning Webインターフェース](/tidb-lightning/tidb-lightning-web-interface.md)で進行状況を確認します。 diff --git a/migrate-from-sql-files-to-tidb.md b/migrate-from-sql-files-to-tidb.md index 37bc49440480d..6de6e0008c21a 100644 --- a/migrate-from-sql-files-to-tidb.md +++ b/migrate-from-sql-files-to-tidb.md @@ -14,7 +14,7 @@ summary: SQLファイルからTiDBへのデータ移行方法を学びましょ ## ステップ1. SQLファイルを準備する {#step-1-prepare-sql-files} -すべての SQL ファイルを`/data/my_datasource/`や`s3://my-bucket/sql-backup`のように同じディレクトリに配置してください。TiDB TiDB Lightning は、このディレクトリとそのサブディレクトリ内のすべての`.sql`ファイルを再帰的に検索します。 +すべての SQL ファイルを`/data/my_datasource/`や`s3://my-bucket/sql-backup`のように同じディレクトリに配置してください。TiDB Lightning は、このディレクトリとそのサブディレクトリ内のすべての`.sql`ファイルを再帰的に検索します。 ## ステップ2. 対象テーブルのスキーマを定義する {#step-2-define-the-target-table-schema} @@ -81,11 +81,11 @@ TiDB Lightning は`~/.aws/credentials`からの認証情報ファイルの読み インポートが開始された後、以下のいずれかの方法で進行状況を確認できます。 -- `progress`ログ内で、 `grep` } キーワードを検索します。このログはデフォルトで 5 分ごとに更新されます。 +- ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。このログはデフォルトで 5 分ごとに更新されます。 - Grafana ダッシュボードを使用します。詳細については、 [TiDB Lightningモニタリング](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 - Webインターフェイスを使用します。詳細については、 [TiDB Lightning Webインターフェース](/tidb-lightning/tidb-lightning-web-interface.md)を参照してください。 -インポートが完了すると、 TiDB Lightning は自動的に終了します。最後の行に`tidb-lightning.log`に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合は、インポートは成功です。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 +インポートが完了すると、 TiDB Lightning は自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合は、インポートは成功です。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 > **注記：** > diff --git a/migrate-large-mysql-shards-to-tidb.md b/migrate-large-mysql-shards-to-tidb.md index e518cc00297b9..5372dcd9b2094 100644 --- a/migrate-large-mysql-shards-to-tidb.md +++ b/migrate-large-mysql-shards-to-tidb.md @@ -30,8 +30,8 @@ MySQL シャードのデータ サイズが 1 TiB 未満の場合は、[小規 - [TiUPを使用してDMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md) - [TiUPを使用してDumplingとライトニングをデプロイ](/migration-tools.md) -- [Dumplingの下流特権要件](/dumpling-overview.md#export-data-from-tidb-or-mysql) -- [TiDB Lightningのダウンストリーム権限要件](/tidb-lightning/tidb-lightning-requirements.md) +- [Dumplingに必要なターゲットデータベース権限](/dumpling-overview.md#export-data-from-tidb-or-mysql) +- [TiDB Lightningに必要なターゲットデータベース権限](/tidb-lightning/tidb-lightning-requirements.md) - [TiDB Lightningのダウンストリームstorageスペース](/tidb-lightning/tidb-lightning-requirements.md) - [DMワーカーに必要な権限](/dm/dm-worker-intro.md) @@ -67,7 +67,7 @@ CREATE TABLE `table5` ( ## ステップ1. Dumplingを使用して全データをエクスポートします。 {#step1-use-dumpling-to-export-full-data} -エクスポートする複数のシャーディングされたテーブルが同じアップストリームの MySQL インスタンスにある場合は、 Dumplingの`-f`パラメータを直接使用して、単一の操作でエクスポートできます。 +エクスポートする複数のシャーディングされたテーブルが同じ上流のMySQLインスタンスにある場合は、 Dumplingの`-f`パラメータを直接使用して、単一の操作でエクスポートできます。 シャーディングされたテーブルが異なるMySQLインスタンスに保存されている場合は、 Dumplingを使用してそれぞれをエクスポートし、エクスポートされた結果を同じ親ディレクトリに配置することができます。 @@ -126,7 +126,7 @@ TiDB Lightningタスクが回復不能なエラー（データ破損など）に ### ターゲットスキーマを作成する {#create-a-target-schema} -下流で`mydb.table5`を作成します。 +ターゲットで`mydb.table5`を作成します。 ```sql CREATE TABLE `table5` ( @@ -207,7 +207,7 @@ CREATE TABLE `table5` ( - 監視ダッシュボードから進捗状況をビュー。詳細については、 [TiDB Lightningモニタリング](/tidb-lightning/monitor-tidb-lightning.md)を参照してください。 - Web ページから進捗状況をビュー。 [ウェブインターフェース](/tidb-lightning/tidb-lightning-web-interface.md)を参照してください。 -TiDB Lightning はインポートが完了すると自動的に終了します。最後の行に`tidb-lightning.log`に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 +TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 > **注記：** > @@ -221,7 +221,7 @@ TiDB Lightning はインポートが完了すると自動的に終了します ### データソースを追加する {#add-the-data-source} -`source1.yaml`という名前の新しいデータソースファイルを作成し、DM にアップストリームデータソースを設定します。そして、以下の内容を追加します。 +`source1.yaml`という名前の新しいデータソースファイルを作成し、DMに上流データソースを設定します。そして、以下の内容を追加します。 ```yaml # Configuration. @@ -252,7 +252,7 @@ tiup dmctl --master-addr ${advertise-addr} operate-source create source1.yaml | `--master-addr` | dmctlが接続するクラスタ内の任意のDMマスターノードの{advertise-addr}。例：172.16.10.71:8261 | | `operate-source create` | データソースをDMクラスターにロードします。 | -上記の手順を繰り返して、すべてのMySQLアップストリームインスタンスをデータソースとしてDMに追加します。 +上記の手順を繰り返して、すべてのMySQL上流インスタンスをデータソースとしてDMに追加します。 ### レプリケーションタスクを作成する {#create-a-replication-task} @@ -358,7 +358,7 @@ tiup dmctl --master-addr ${advertise-addr} query-status ${task-name} 移行タスクの履歴や内部運用指標は、Grafanaまたはログを通じて確認できます。 -- グラファーナ経由 +- グラファナ経由 TiUPを使用してDMクラスタをデプロイする際に、Prometheus、Alertmanager、およびGrafanaが正しくデプロイされていれば、GrafanaでDMの監視メトリクスを表示できます。具体的には、デプロイ時に指定したIPアドレスとポートをGrafanaに入力し、DMダッシュボードを選択してください。 diff --git a/migrate-large-mysql-to-tidb.md b/migrate-large-mysql-to-tidb.md index 628075325e856..c8e4bd26d8a19 100644 --- a/migrate-large-mysql-to-tidb.md +++ b/migrate-large-mysql-to-tidb.md @@ -7,7 +7,7 @@ summary: MySQLからTiDBへ大規模データセットを移行する方法を 移行するデータ量が少ない場合は、完全移行と増分レプリケーションの両方で、 [DMを使用してデータを移行する](/migrate-small-mysql-to-tidb.md)簡単にできます。ただし、DM はデータのインポート速度が遅い (30 ～ 50 GiB/h) ため、データ量が多い場合、移行に時間がかかることがあります。このドキュメントにおける「大規模なデータセット」とは、通常、約 1 TiB 以上のデータを意味します。 -このドキュメントでは、 DumplingとTiDB Lightningを使用してフルマイグレーションを実行する方法について説明します。TiDB TiDB Lightningの[物理輸入モード](/tidb-lightning/tidb-lightning-physical-import-mode.md)では、最大500 GiB/hの速度でデータをインポートできます。ただし、この速度はハードウェア構成、テーブルスキーマ、インデックス数など、さまざまな要因によって影響を受けることに注意してください。フルマイグレーションが完了したら、DMを使用して増分データをレプリケートできます。 +このドキュメントでは、 DumplingとTiDB Lightningを使用してフルマイグレーションを実行する方法について説明します。TiDB Lightningの[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)では、最大500 GiB/hの速度でデータをインポートできます。ただし、この速度はハードウェア構成、テーブルスキーマ、インデックス数など、さまざまな要因によって影響を受けることに注意してください。フルマイグレーションが完了したら、DMを使用して増分データをレプリケートできます。 ## 前提条件 {#prerequisites} @@ -19,17 +19,17 @@ summary: MySQLからTiDBへ大規模データセットを移行する方法を ## リソース要件 {#resource-requirements} -**オペレーティングシステム**: このドキュメントの例では、新規の CentOS 7 インスタンスを使用しています。仮想マシンは、ローカル ホストまたはクラウドにデプロイできます。TiDB TiDB Lightning はデフォルトで必要なだけの CPU リソースを消費するため、専用サーバーにデプロイすることをお勧めします。それが不可能な場合は、他の TiDB コンポーネント (たとえば`tikv-server` ) と一緒に単一のサーバーにデプロイし、 `region-concurrency`を構成して、 TiDB Lightningの CPU 使用率を制限できます。通常、論理 CPU の 75% にサイズを設定できます。 +**オペレーティングシステム**: このドキュメントの例では、新規の CentOS 7 インスタンスを使用しています。仮想マシンは、ローカル ホストまたはクラウドにデプロイできます。TiDB Lightning はデフォルトで必要なだけの CPU リソースを消費するため、専用サーバーにデプロイすることをお勧めします。それが不可能な場合は、他の TiDB コンポーネント (たとえば`tikv-server` ) と一緒に単一のサーバーにデプロイし、 `region-concurrency`を構成して、 TiDB Lightningの CPU 使用率を制限できます。通常、論理 CPU の 75% にサイズを設定できます。 **メモリとCPU** ： TiDB Lightningは多くのリソースを消費するため、64 GiB以上のメモリと32以上のCPUコアを割り当てることを推奨します。最高のパフォーマンスを得るには、CPUコアとメモリ（GiB）の比率が1:2以上であることを確認してください。 **ディスク容量**： -- Dumplingには、データ ソース全体を保存できる (またはエクスポートされるすべてのアップストリーム テーブルを保存できる) ディスク容量が必要です。 SSD推奨です。必要なスペースを計算するには、 [下流のstorageスペース要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。 -- インポート処理中、 TiDB Lightningはソート済みのキーと値のペアを保存するための一時的な領域を必要とします。ディスク容量は、データソースから取得した最大の単一テーブルを格納できるだけの十分な量が必要です。 -- データ総量が大きい場合は、アップストリーム側のbinlogのstorage時間を延長することができます。これは、増分レプリケーション中にバイナリログが失われないようにするためです。 +- Dumplingには、データソース全体を保存できる（またはエクスポートされるすべての上流テーブルを保存できる）ディスク容量が必要です。SSD推奨です。必要なスペースを計算するには、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。 +- インポート処理中、 TiDB Lightningはソート済みのキーと値のペアを保存するための一時的な領域を必要とします。ディスク容量は、データソースの最大の単一テーブルを格納できるのに十分な量が必要です。 +- データ総量が大きい場合は、上流側のbinlogのstorage時間を延長することができます。これは、増分レプリケーション中にバイナリログが失われないようにするためです。 -**注**： DumplingによってMySQLからエクスポートされる正確なデータ量を計算することは困難ですが、次のSQLステートメントを使用して`DATA_LENGTH`テーブルの`information_schema.tables`フィールドを要約することで、データ量を推定できます。 +**注**： DumplingによってMySQLからエクスポートされる正確なデータ量を計算することは困難ですが、次のSQLステートメントを使用して`information_schema.tables`テーブルの`DATA_LENGTH`フィールドを要約することで、データ量を推定できます。 ```sql -- Calculate the size of all schemas @@ -62,10 +62,10 @@ LIMIT ### ターゲットとなるTiKVクラスターのディスク容量 {#disk-space-for-the-target-tikv-cluster} -対象の TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、対象の TiKV クラスターのstorage容量は**、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、対象の TiKV クラスターは、データソースのサイズの 6 倍よりも大きなstorage容量が必要です。この式に`x 2`が含まれている理由は次のとおりです。 +ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットの TiKV クラスターのstorage容量は**、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、ターゲットの TiKV クラスターは、データソースのサイズの 6 倍よりも大きなstorage容量が必要です。この式に`x 2`が含まれている理由は次のとおりです。 -- インデックス作成には余分なスペースが必要になる場合があります。 -- RocksDBには空間増幅効果がある。 +- インデックスには余分な容量が必要になる場合があります。 +- RocksDBには空間増幅がある。 ## ステップ1. MySQLからすべてのデータをエクスポートする {#step-1-export-all-data-from-mysql} @@ -92,7 +92,7 @@ LIMIT | - `B`または`--database` | エクスポートするデータベースを指定します。 | | `-f`または`--filter` | パターンに一致するテーブルをエクスポートします。構文については[テーブルフィルター](/table-filter.md)を参照してください。 | - `${data-path}`には、エクスポートされたすべてのアップストリーム テーブルを保存するのに十分な空き容量があることを確認してください。必要な容量を計算するには、 [下流のstorageスペース要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)参照してください。大きなテーブルがすべてのスペースを消費してエクスポートが中断されるのを防ぐため、 `-F`オプションを使用して単一ファイルのサイズを制限することを強くお勧めします。 + `${data-path}`には、エクスポートされたすべての上流テーブルを保存するのに十分な空き容量があることを確認してください。必要な容量を計算するには、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。大きなテーブルがすべてのスペースを消費してエクスポートが中断されるのを防ぐため、 `-F`オプションを使用して単一ファイルのサイズを制限することを強くお勧めします。 2. `metadata`ディレクトリにある`${data-path}`ファイルをビュー。これは、Dumpling によって生成されたメタデータ ファイルです。ステップ 3 の増分レプリケーションに必要なbinlogの位置情報を記録します。 @@ -149,11 +149,11 @@ LIMIT 3. インポートが開始された後、以下のいずれかの方法でインポートの進行状況を確認できます。 - - {{B `progress` `grep`のキーワードがログに記録されます。デフォルトでは、進行状況は 5 分ごとに更新されます。 + - ログ内のキーワード`progress`を`grep`することで、インポートの進行状況を確認できます。進行状況は、デフォルトでは 5 分ごとに更新されます。 - [モニタリングダッシュボード](/tidb-lightning/monitor-tidb-lightning.md)で進捗状況を確認します。 - [TiDB Lightning Webインターフェース](/tidb-lightning/tidb-lightning-web-interface.md)で進行状況を確認します。 -4. TiDB Lightning はインポートが完了すると自動的に終了します。最後の行に`tidb-lightning.log`に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 +4. TiDB Lightning はインポートが完了すると自動的に終了します。`tidb-lightning.log`の最後の行に`the whole procedure completed`が含まれているかどうかを確認してください。含まれている場合はインポートが成功しています。含まれていない場合は、インポート中にエラーが発生しました。エラーメッセージの指示に従ってエラーに対処してください。 > **注記：** > diff --git a/pd-recover.md b/pd-recover.md index 0e76a245f3cd9..e07c0a41b1cee 100644 --- a/pd-recover.md +++ b/pd-recover.md @@ -9,7 +9,7 @@ PD RecoverはPDのディザスタリカバリツールであり、正常に起 ## ソースコードからコンパイル {#compile-from-source-code} -- Goモジュールが使用されるため、[行く](https://golang.org/)1.23以降が必要です。 +- Goモジュールが使用されるため、[Go](https://golang.org/)1.23以降が必要です。 - [PDプロジェクト](https://github.com/pingcap/pd)のルートディレクトリで、 `make pd-recover`コマンドを使用して`bin/pd-recover`をコンパイルおよび生成します。 > **注記：** @@ -32,7 +32,7 @@ PD Recover インストール パッケージは、 TiDB Toolkitに含まれて ### ステップ2：生存しているPDノードを起動する {#step-2-start-the-surviving-pd-node} -`--force-new-cluster`起動パラメータを使用して、残存PDノードを起動し、ノードが元のデータディレクトリを使用するようにします。これは、 `--data-dir`を使用してコマンドラインで明示的に指定することも、 `data-dir`で`conf/pd.toml`を事前に設定することもできます。例： +`--force-new-cluster`起動パラメータを使用して、残存PDノードを起動し、ノードが元のデータディレクトリを使用するようにします。これは、 `--data-dir`を使用してコマンドラインで明示的に指定することも、 `conf/pd.toml`で`data-dir`を事前に設定することもできます。例： ```shell ./bin/pd-server --force-new-cluster --name=pd-127.0.0.10-2379 --data-dir=/path/to/existing/pd/data --client-urls=http://0.0.0.0:2379 --advertise-client-urls=http://127.0.0.1:2379 --peer-urls=http://0.0.0.0:2380 --advertise-peer-urls=http://127.0.0.1:2380 --config=conf/pd.toml @@ -42,8 +42,8 @@ PD Recover インストール パッケージは、 TiDB Toolkitに含まれて > **注記：** > -> - コマンドラインで`--data-dir`が指定されていない場合は、 `data-dir`内の`conf/pd.toml`が、存続している PD ノードの元のデータ ディレクトリを正しく指していることを確認してください。そうでない場合`pd-recover`後続の操作で失敗する可能性があります。 -> - `data-dir`が`conf/pd.toml`とコマンドライン引数の両方で指定されている場合、 `data-dir`の`conf/pd.toml`設定が優先されます。 +> - コマンドラインで`--data-dir`が指定されていない場合は、 `conf/pd.toml`内の`data-dir`が、存続しているPDノードの元のデータディレクトリを正しく指していることを確認してください。そうでない場合、`pd-recover`は後続の操作で失敗する可能性があります。 +> - `conf/pd.toml`とコマンドライン引数の両方で`data-dir`が指定されている場合、 `conf/pd.toml`の`data-dir`設定が優先されます。 ### ステップ3： pd-recoverを使用してメタデータを修復する {#step-3-repair-metadata-using-code-pd-recover-code} @@ -57,7 +57,7 @@ PD Recover インストール パッケージは、 TiDB Toolkitに含まれて > > このステップでは、storage内の`alloc_id`が安全な値`100000000`だけ自動的に増加します。その結果、後続のクラスタではより大きな ID が割り当てられます。 > -> さらに、 `pd-recover`は TSO を変更しません。したがって、この手順を実行する前に、ローカル時刻が障害発生時刻よりも後であることを確認し、障害発生前に PD コンポーネント間で NTP クロック同期サービスが有効になっていることを確認してください。有効になっていない場合は、TSO がロールバックされないように、ローカルクロックを未来の時刻に調整する必要があります。 +> さらに、 `pd-recover`はTSOを変更しません。したがって、この手順を実行する前に、ローカル時刻が障害発生時刻よりも後であることを確認し、障害発生前にPDコンポーネント間でNTPクロック同期サービスが有効になっていることを確認してください。有効になっていない場合は、TSOがロールバックされないように、ローカルクロックを未来の時刻に調整する必要があります。 ### ステップ4：PDノードを再起動する {#step-4-restart-the-pd-node} @@ -143,7 +143,7 @@ grep "idAllocator allocates a new id" {{/path/to}}/pd*.log | awk -F'=' '{print ### ステップ4：pd-recoverを使用する {#step-4-use-pd-recover} -`pd-recover` 1 つの PD ノードでのみ実行する必要があります。再割り当てを避けるため、 `-alloc-id`パラメータには割り当て済み ID より大きい値を設定することをお勧めします。たとえば、監視またはログから取得した最大割り当て済み ID が`9000`の場合、 `10000`パラメータには`-alloc-id` } またはそれより大きい値を渡すことをお勧めします。 +`pd-recover`は1つのPDノードでのみ実行する必要があります。再割り当てを避けるため、 `-alloc-id`パラメータには割り当て済みIDより大きい値を設定することをお勧めします。たとえば、監視またはログから取得した最大割り当て済みIDが`9000`の場合、 `-alloc-id`パラメータには`10000`以上の値を渡すことをお勧めします。 ```bash ./pd-recover -endpoints http://10.0.1.13:2379 -cluster-id 6747551640615446306 -alloc-id 10000 @@ -161,4 +161,4 @@ PDクラスタが作成されると、新しいクラスタ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-recover`を実行する際には、PD サービスが必要です。PD リカバリを使用する前に、PD クラスタをデプロイて起動してください。 +`pd-recover`を実行する際には、PDサービスが必要です。PDリカバリを使用する前に、PDクラスタをデプロイして起動してください。 diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index e49f5fe0ce7ae..aa51a64a48c00 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -60,24 +60,23 @@ Starterプランは、 TiDB Cloudを初めて利用する方に最適です。 TiDB Cloud Essentialは、ゾーン型高可用性を提供します。これは、すべてのコンポーネントを同じ可用性ゾーン内に配置することで、ネットワークレイテンシーを低減します。詳細については、[TiDB Cloudにおける高可用性](/tidb-cloud/serverless-high-availability.md)を参照してください。 + + + + +- **機能強化**：Starterプランのすべての機能に加え、より大規模で複雑なワークロードを処理できる能力、および高度なセキュリティ機能が含まれています。 +- **自動スケーリング**：変化するワークロードの需要に効率的に対応するために、storageとコンピューティングリソースを自動的に調整します。 +- **高可用性**：組み込みの耐障害性と冗長性により、インフラストラクチャの障害発生時でも、アプリケーションの可用性と回復力が維持されます。 +- **予測可能な料金体系**：コンピューティングリソースのstorageとリクエストキャパシティユニット（RCU）に基づいて課金されるため、ニーズに合わせて拡張可能な透明性の高い使用量ベースの料金体系が提供され、予期せぬ追加料金なしで使用した分だけを支払うことができます。 + +TiDB Cloud Essentialは、さまざまな運用要件に対応するため、2種類の高可用性機能を提供します。 + +- ゾーン高可用性：すべてのコンポーネントを同じ可用性ゾーン内に配置することで、ネットワークレイテンシーを低減します。 +- 地域別高可用性：ノードを複数の可用性ゾーンに分散させることで、インフラストラクチャの最大限の分離性と冗長性を実現します。 + +詳細については、[TiDB Cloudにおける高可用性](/tidb-cloud/serverless-high-availability.md)参照してください。 + - - - -- **機能強化**：Starterプランのすべての機能に加え、より大規模で複雑なワークロードを処理できる能力、および高度なセキュリティ機能が含まれています。 -- **自動スケーリング**：変化するワークロードの需要に効率的に対応するために、storageとコンピューティングリソースを自動的に調整します。 -- **高可用性**：組み込みの耐障害性と冗長性により、インフラストラクチャの障害発生時でも、アプリケーションの可用性と回復力が維持されます。 -- **予測可能な料金体系**：コンピューティングリソースのstorageとリクエストキャパシティユニット（RCU）に基づいて課金されるため、ニーズに合わせて拡張可能な透明性の高い使用量ベースの料金体系が提供され、予期せぬ追加料金なしで使用した分だけを支払うことができます。 - -TiDB Cloud Essentialは、さまざまな運用要件に対応するため、2種類の高可用性機能を提供します。 - -- ゾーン高可用性：すべてのコンポーネントを同じ可用性ゾーン内に配置することで、ネットワークレイテンシーを低減します。 -- 地域別高可用性：ノードを複数の可用性ゾーンに分散させることで、インフラストラクチャの最大限の分離性と冗長性を実現します。 - -詳細については、[TiDB Cloudにおける高可用性](/tidb-cloud/serverless-high-availability.md)参照してください。 - - - ## TiDB Cloud Premium {#tidb-cloud-premium} 管理された環境で高いパフォーマンスと強化されたセキュリティを必要とするミッションクリティカルなアプリケーション向けに、プレミアムプランは、以下の機能を備えた堅牢なインフラストラクチャと高度な制御を提供します。 @@ -181,7 +180,7 @@ TiDBノードを複数デプロイすることで、水平方向に拡張し、 ### RCUの自動スケーリング {#rcu-auto-scaling} -TiDB Cloud Premium インスタンスを構成する際に、ワークロードに必要な最大 RCU 数 ( `RCU_max` ) を指定します。TiDB TiDB Cloud は`0.25 * RCU_max`から`RCU_max` 。 +TiDB Cloud Premium インスタンスを構成する際に、ワークロードに必要な最大 RCU 数 ( `RCU_max` ) を指定します。TiDB Cloudは`0.25 * RCU_max`から`RCU_max`までの範囲で自動的にスケーリングします。 例えば、最大容量を20,000 RCUに設定した場合、 TiDB Cloudはリアルタイムの需要に基づいて、容量を5,000 RCUから20,000 RCUの間で動的にスケーリングします。このスケーリングは自動的かつ瞬時に行われるため、手動操作や遅延なしに、いつでも最大数のRCUを消費できます。 diff --git a/tidb-cloud/backup-and-restore-serverless.md b/tidb-cloud/backup-and-restore-serverless.md index 59457385b4949..a62b1645781dc 100644 --- a/tidb-cloud/backup-and-restore-serverless.md +++ b/tidb-cloud/backup-and-restore-serverless.md @@ -89,7 +89,7 @@ TiDB Cloudは、新しいTiDB Cloud StarterまたはEssentialインスタンス > **注記：** > -> ソースのTiDB Cloud StarterまたはEssentialインスタンスのユーザー認証情報と権限は、新しいTiDB Cloud StarterまたはEssentialインスタンスには復元されません。 +> 元のTiDB Cloud StarterまたはEssentialインスタンスのユーザー認証情報と権限は、新しいTiDB Cloud StarterまたはEssentialインスタンスには復元されません。 新しいTiDB Cloud StarterまたはEssentialインスタンスにデータを復元するには、以下の手順に従ってください。 diff --git a/tidb-cloud/branch-overview.md b/tidb-cloud/branch-overview.md index c3ac3d5ef2ec8..42e3bb298ddd3 100644 --- a/tidb-cloud/branch-overview.md +++ b/tidb-cloud/branch-overview.md @@ -5,7 +5,7 @@ summary: TiDB Cloudのブランチの概念を学びましょう。 # TiDB Cloudブランチング（ベータ版）の概要 {#tidb-cloud-branching-beta-overview} -TiDB Cloud、 TiDB Cloud StarterおよびTiDB Cloud Essentialインスタンスのブランチを作成できます。TiDB TiDB Cloud StarterまたはEssentialインスタンスのブランチは、元のTiDB Cloud StarterまたはEssentialインスタンスから分岐したデータコピーを含む独立したインスタンスです。これにより、隔離された環境が提供され、元のTiDB Cloud StarterまたはEssentialインスタンスへの影響を気にすることなく、自由に実験を行うことができます。 +TiDB Cloud、 TiDB Cloud StarterおよびTiDB Cloud Essentialインスタンスのブランチを作成できます。TiDB Cloud StarterまたはEssentialインスタンスのブランチは、元のTiDB Cloud StarterまたはEssentialインスタンスから分岐したデータコピーを含む独立したインスタンスです。これにより、隔離された環境が提供され、元のTiDB Cloud StarterまたはEssentialインスタンスへの影響を気にすることなく、自由に実験を行うことができます。 ブランチ機能を使用することで、開発者は並行して作業を進め、新機能を迅速に反復開発し、本番データベースに影響を与えることなく問題をトラブルシューティングし、必要に応じて変更を簡単に元に戻すことができます。この機能は、開発およびデプロイプロセスを効率化すると同時に、本番データベースの高い安定性と信頼性を確保します。 @@ -39,7 +39,7 @@ TiDB Cloudは、高速かつシームレスなブランチ作成を実現する 現在、 TiDB Cloudの各ブランチはベータ版であり、無料で利用できます。 -- TiDB Cloudの各組織では、デフォルトではTiDB Cloud StarterおよびEssentialインスタンス全体で最大 5 つのブランチを作成できます。TiDB TiDB Cloud StarterまたはEssentialインスタンスのブランチは、インスタンスと同じリージョンに作成されます。また、スロットリングが適用されている、または 100 GiB を超えるサイズのTiDB Cloud StarterまたはEssentialインスタンスにはブランチを作成できません。 +- TiDB Cloudの各組織では、デフォルトではTiDB Cloud StarterおよびEssentialインスタンス全体で最大 5 つのブランチを作成できます。TiDB Cloud StarterまたはEssentialインスタンスのブランチは、インスタンスと同じリージョンに作成されます。また、スロットリングが適用されている、または 100 GiB を超えるサイズのTiDB Cloud StarterまたはEssentialインスタンスにはブランチを作成できません。 > **注記：** > diff --git a/tidb-cloud/essential-changefeed-overview.md b/tidb-cloud/essential-changefeed-overview.md index a77f6068a1cbd..523010be94d75 100644 --- a/tidb-cloud/essential-changefeed-overview.md +++ b/tidb-cloud/essential-changefeed-overview.md @@ -5,7 +5,7 @@ summary: TiDB Cloud changefeed を使用すると、TiDB Cloudから他のデー # 変更フィード {#changefeed} -TiDB Cloud changefeed を使用すると、TiDB Cloudから他のデータサービスへデータをストリーミングできます。現在、 TiDB Cloud Essential はApache Kafka と MySQL へのデータストリーミングをサポートしています。 +TiDB Cloud changefeed を使用すると、TiDB Cloudから他のデータサービスへデータをストリーミングできます。現在、 TiDB Cloud EssentialはApache Kafka と MySQL へのデータストリーミングをサポートしています。 > **注記：** > @@ -15,7 +15,7 @@ TiDB Cloud changefeed を使用すると、TiDB Cloudから他のデータサー > 2. **「サポート チケット」**をクリックして[ヘルプセンター](https://tidb.support.pingcap.com/servicedesk/customer/portals)に移動します。 > 3. チケットを作成します。「説明」欄に「changefeedへの申請」と入力します。 > 4. **「送信」**をクリックしてください。 -> - TiDB Cloud、 TiDB Cloud Essentialインスタンスごとに最大10個のチェンジフィードしか許可されていません。 +> - TiDB Cloud Essentialインスタンスごとに最大10個の変更フィードが許可されています。 > - [TiDB Cloud Starter](/tidb-cloud/select-cluster-tier.md#starter)インスタンスでは、変更フィード機能は利用できません。 ## 制限 {#restrictions} diff --git a/tidb-cloud/essential-changefeed-sink-to-kafka.md b/tidb-cloud/essential-changefeed-sink-to-kafka.md index 05662efb6db44..008723b8ae672 100644 --- a/tidb-cloud/essential-changefeed-sink-to-kafka.md +++ b/tidb-cloud/essential-changefeed-sink-to-kafka.md @@ -18,10 +18,10 @@ summary: このドキュメントでは、TiDB Cloud Essentialから Apache Kafk ## 制限 {#restrictions} -- TiDB Cloud Essentialインスタンスごとに、最大10個のチェンジフィードを作成できます。 +- TiDB Cloud Essentialインスタンスごとに、最大10個の変更フィードを作成できます。 - 現在、 TiDB Cloud Essentialは、Kafkaブローカーへの接続に自己署名TLS証明書をアップロードすることをサポートしていません。 -- TiDB Cloud Essential はTiCDC を使用して変更フィードを確立するため、同じ[TiCDCの制限](https://docs.pingcap.com/tidb/stable/ticdc-overview#unsupported-scenarios)があります。 -- 複製対象のテーブルに主キーまたはNULLを許容しない一意インデックスがない場合、複製中に一意制約が存在しないことで、一部の再試行シナリオにおいて、下流で重複データが挿入される可能性があります。 +- TiDB Cloud EssentialはTiCDCを使用して変更フィードを確立するため、同じ[TiCDCの制限](https://docs.pingcap.com/tidb/stable/ticdc-overview#unsupported-scenarios)があります。 +- 複製対象のテーブルに主キーまたはNULLを許容しない一意インデックスがない場合、複製中に一意制約が存在しないことで、一部の再試行シナリオにおいて、ターゲットで重複データが挿入される可能性があります。 ## 前提条件 {#prerequisites} @@ -186,7 +186,7 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト 変更フィードで全ての変更ログに対して1つのKafkaトピックを作成する場合は、このモードを選択してください。そうすると、変更フィード内のすべてのKafkaメッセージが1つのKafkaトピックに送信されます。トピック名は**「トピック名」**フィールドで指定できます。 -8. **パーティション分散**領域では、Kafka メッセージの送信先パーティションを決定できます。**すべてのテーブルに対して単一のパーティションディスパッチャを**定義することも、**テーブルごとに異なるパーティションディスパッチャを**定義することもできます。TiDB TiDB Cloud、次の 4 種類のディスパッチャが提供されています。 +8. **パーティション分散**領域では、Kafka メッセージの送信先パーティションを決定できます。**すべてのテーブルに対して単一のパーティションディスパッチャを**定義することも、**テーブルごとに異なるパーティションディスパッチャを**定義することもできます。TiDB Cloudは、次の4種類のディスパッチャを提供しています。 - **プライマリキーまたはインデックス値に基づいて変更ログをKafkaパーティションに分散します。** diff --git a/tidb-cloud/essential-changefeed-sink-to-mysql.md b/tidb-cloud/essential-changefeed-sink-to-mysql.md index e903364169e15..c529d2118beec 100644 --- a/tidb-cloud/essential-changefeed-sink-to-mysql.md +++ b/tidb-cloud/essential-changefeed-sink-to-mysql.md @@ -56,11 +56,11 @@ MySQLサービスがパブリックネットワーク経由でアクセスでき ### 既存データの読み込み（オプション） {#load-existing-data-optional} -**Sink to MySQL**コネクタは、特定のタイムスタンプ以降のTiDB Cloud EssentialインスタンスからMySQLへの増分データのみをシンクできます。TiDB TiDB Cloud Essentialインスタンスに既にデータが存在する場合は、 **Sink to MySQL**を有効にする前に、 TiDB Cloud Essentialインスタンスの既存データをエクスポートしてMySQLにロードすることができます。 +**Sink to MySQL**コネクタは、特定のタイムスタンプ以降のTiDB Cloud EssentialインスタンスからMySQLへの増分データのみをシンクできます。TiDB Cloud Essentialインスタンスに既にデータが存在する場合は、 **Sink to MySQL**を有効にする前に、 TiDB Cloud Essentialインスタンスの既存データをエクスポートしてMySQLにロードすることができます。 既存のデータを読み込むには： -1. [tidb_gc_life_time](https://docs.pingcap.com/tidb/stable/system-variables#tidb_gc_life_time-new-in-v50)以下の 2 つの操作の合計時間よりも長く設定することで、この期間中の履歴データが TiDB によってガベージ コレクションされないようにします。 +1. [`tidb_gc_life_time`](https://docs.pingcap.com/tidb/stable/system-variables#tidb_gc_life_time-new-in-v50)以下の 2 つの操作の合計時間よりも長く設定することで、この期間中の履歴データが TiDB によってガベージ コレクションされないようにします。 - 既存データのエクスポートとインポートにかかる時間 - **Sink to MySQL**を作成する時間 diff --git a/tidb-cloud/premium/dual-layer-data-encryption-premium.md b/tidb-cloud/premium/dual-layer-data-encryption-premium.md index 5f421fcda848d..242ebeaa686b1 100644 --- a/tidb-cloud/premium/dual-layer-data-encryption-premium.md +++ b/tidb-cloud/premium/dual-layer-data-encryption-premium.md @@ -175,7 +175,7 @@ TiDB Cloudに暗号化キーの管理を代行させるには、以下の手順 バックアップがCMEKで暗号化されている場合は、復元中に新しいインスタンスがKMSマスターキーにアクセスできることを確認してください。キーARNは変更されません。 -アクセスを確認するには、 **「確認」**をクリックして信頼ポリシーの検証を開始します。TiDB TiDB Cloud は、キー ポリシーで承認されたTiDB Cloudアカウントが、元のバックアップに関連付けられているアカウントと一致するかどうかを確認します。 +アクセスを確認するには、 **「確認」**をクリックして信頼ポリシーの検証を開始します。TiDB Cloudは、キーポリシーで承認されたTiDB Cloudアカウントが、元のバックアップに関連付けられているアカウントと一致するかどうかを確認します。 - アカウントが一致する場合、それ以上の承認は必要ありません。 - アカウントが一致しない場合は、提供されたキーポリシーをコピーし、クラウドプロバイダーのKMSで更新してください。この更新によりキーが再認証され、新しいインスタンスがキーにアクセスできるようになります。 @@ -186,7 +186,7 @@ TiDB Cloudに暗号化キーの管理を代行させるには、以下の手順 ## 顧客管理暗号化キー（CMEK）をローテーションする {#rotate-a-customer-managed-encryption-key-cmek} -クラウドプロバイダーのKMSでCMEKの自動ローテーションを設定できます。TiDB TiDB Cloudでは設定の更新は不要です。 +クラウドプロバイダーのKMSでCMEKの自動ローテーションを設定できます。TiDB Cloudでは設定の更新は不要です。 - AWS については、 [CMEK自動回転](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html)を参照してください。 - Alibaba Cloud については、 [キーローテーション](https://www.alibabacloud.com/help/en/kms/key-management-service/user-guide/configure-key-rotation)を参照してください。 diff --git a/tidb-cloud/premium/tidb-cloud-auditing-premium.md b/tidb-cloud/premium/tidb-cloud-auditing-premium.md index 6725e70e08172..f027db57db365 100644 --- a/tidb-cloud/premium/tidb-cloud-auditing-premium.md +++ b/tidb-cloud/premium/tidb-cloud-auditing-premium.md @@ -9,7 +9,7 @@ TiDB Cloudは、実行されたSQLステートメントなど、データベー 組織のユーザーアクセスポリシーやその他の情報セキュリティ対策の有効性を評価するには、データベース監査ログを定期的に分析することがセキュリティ上のベストプラクティスです。 -監査ログ機能は**デフォルトでは無効になっています**。TiDB TiDB Cloud Premiumインスタンスを監査するには、まず監査ログを有効にしてから、監査フィルタルールを設定する必要があります。 +監査ログ機能は**デフォルトでは無効になっています**。TiDB Cloud Premiumインスタンスを監査するには、まず監査ログを有効にしてから、監査フィルタルールを設定する必要があります。 > **注記：** > diff --git a/tidb-cloud/releases/tidb-cloud-release-notes.md b/tidb-cloud/releases/tidb-cloud-release-notes.md index cb77262b82ce9..56fabf403121b 100644 --- a/tidb-cloud/releases/tidb-cloud-release-notes.md +++ b/tidb-cloud/releases/tidb-cloud-release-notes.md @@ -30,7 +30,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - 2026年6月9日以降に新たに作成される[TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンスは、単一のアベイラビリティゾーンにデプロイされ、リージョンごとの高可用性はサポートされません。 - リージョンの高可用性とクロス AZ フェイルオーバーが必要な場合は、 [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)選択を検討してください。 + リージョンの高可用性とクロス AZ フェイルオーバーが必要な場合は、 [TiDB Cloud Premium](/tidb-cloud/select-cluster-tier.md#premium)を選択することを検討してください。 この変更は、2026年6月9日より前に作成されたTiDB Cloud Essentialインスタンスには影響しません。 @@ -40,9 +40,9 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - **TiDB Cloud Premium** - - [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)向けに以下のバックアップAPIエンドポイントを導入し、組織内のアクティブなインスタンスと削除されたインスタンスの両方を一元的に管理できるようにします。 + - [TiDB Cloud Premium](/tidb-cloud/select-cluster-tier.md#premium)向けに以下のバックアップAPIエンドポイントを導入し、組織内のアクティブなインスタンスと削除されたインスタンスの両方を一元的に管理できるようにします。 - - バックアップの一覧を[バックアップの一覧を表示](https://docs.pingcap.com/tidbcloud/api/v1beta2/premium/#tag/Backup/operation/BackupService_ListBackups): 組織内のアクティブなTiDB Cloudプレミアム インスタンス (ごみ箱内) の両方のバックアップを一覧表示します。 + - バックアップの一覧を[バックアップの一覧を表示](https://docs.pingcap.com/tidbcloud/api/v1beta2/premium/#tag/Backup/operation/BackupService_ListBackups): 組織内のアクティブなTiDB Cloud Premiumインスタンス (ごみ箱内) の両方のバックアップを一覧表示します。 - [バックアップを削除する](https://docs.pingcap.com/tidbcloud/api/v1beta2/premium/#tag/Backup/operation/BackupService_DeleteBackup): `backupId`によって組織内の特定のバックアップを削除します。 ## 2026年6月2日 {#june-2-2026} @@ -67,7 +67,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - **TiDB Cloud Premium** - - [TiDB Cloudプレミアム](/tidb-cloud/select-cluster-tier.md#premium)インスタンスの Alibaba Cloud で二層データ暗号化をサポートします。 + - [TiDB Cloud Premium](/tidb-cloud/select-cluster-tier.md#premium)インスタンスの Alibaba Cloud で二層データ暗号化をサポートします。 Alibaba Cloud Key Management Service (KMS) では、独自のキーを使用して保存データを暗号化できるため、データセキュリティとコンプライアンスをより詳細に管理できます。 @@ -146,7 +146,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - **TiDB Cloud Premium** - - `AVG RU/s`メトリクスを[TiDB Cloudプレミアム](https://docs.pingcap.com/tidbcloud/premium/?plan=premium)**Metrics**ページに追加します。 + - `AVG RU/s`メトリクスを[TiDB Cloud Premium](https://docs.pingcap.com/tidbcloud/premium/?plan=premium)**Metrics**ページに追加します。 `AVG RU/s` 、選択した時間範囲における1秒あたりの平均RU消費数を表示し、リソース消費をよりよく理解するのに役立ちます。 @@ -164,7 +164,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - **TiDB Cloud Premium** - - [TiDB Cloudプレミアム](https://docs.pingcap.com/tidbcloud/premium/?plan=premium)現在、AWSアリババクラウドでパブリック プレビュー中です。 + - [TiDB Cloud Premium](https://docs.pingcap.com/tidbcloud/premium/?plan=premium)は、現在AWSアリババクラウドでパブリックプレビュー中です。 [TiDB X](/tidb-cloud/tidb-x-architecture.md)カーネルを搭載したTiDB Cloud Premiumは、ハイパースケール、妥協のないパフォーマンス、そしてクラウドネイティブな消費モデルによるコスト効率を必要とする、ミッションクリティカルなエンタープライズワークロード向けに特別に設計されています。 diff --git a/tidb-cloud/select-cluster-tier.md b/tidb-cloud/select-cluster-tier.md index 53757b6d06459..0c7b4f67a80a1 100644 --- a/tidb-cloud/select-cluster-tier.md +++ b/tidb-cloud/select-cluster-tier.md @@ -70,7 +70,7 @@ TiDB Cloudインスタンス容量プランの申請が承認されると、メ -TiDB TiDB Cloudは、 TiDB Cloud StarterまたはTiDB Cloud Essentialの各インスタンスに対して、他のインスタンスと区別するための固有のプレフィックスを生成します。 +TiDB Cloudは、 TiDB Cloud StarterまたはTiDB Cloud Essentialの各インスタンスに対して、他のインスタンスと区別するための固有のプレフィックスを生成します。 データベースユーザー名を使用または設定する際は、必ずプレフィックスをユーザー名に含める必要があります。たとえば、 TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンスのプレフィックスが`3pTAoNNegb47Uc8`であるとします。 diff --git a/tidb-cloud/serverless-high-availability.md b/tidb-cloud/serverless-high-availability.md index 8b123d32086ae..5d73ef7db4fc4 100644 --- a/tidb-cloud/serverless-high-availability.md +++ b/tidb-cloud/serverless-high-availability.md @@ -67,7 +67,7 @@ TiDB Cloudは、ゾーン別高可用性とリージョン別高可用性によ ゾーン型高可用性アーキテクチャでは： -- 配置Driver（PD）は複数の可用性ゾーンに展開され、ゾーン間でデータを冗長に複製することで高可用性を確保します。 +- Placement Driver（PD）は複数の可用性ゾーンに展開され、ゾーン間でデータを冗長に複製することで高可用性を確保します。 - データは、ローカル可用性ゾーン内のTiKVサーバーとTiFlash書き込みノード間で複製されます。 - TiDBサーバーとTiFlash計算ノードは、ストレージレベルのレプリケーションによって保護されているTiKVおよびTiFlash書き込みノードとの間で読み書きを行います。 @@ -137,7 +137,7 @@ TiDB Cloud EssentialまたはTiDB Cloud Premium インスタンスをリージ 地域的な高可用性アーキテクチャにおいて： -- 配置Driver（PD）とTiKVは複数の可用性ゾーンに展開され、最高レベルの可用性を確保するために、データは常にゾーン間で冗長的に複製されます。 +- Placement Driver（PD）とTiKVは複数の可用性ゾーンに展開され、最高レベルの可用性を確保するために、データは常にゾーン間で冗長的に複製されます。 - データは、プライマリ可用性ゾーン内のTiFlash書き込みノード間で複製されます。 - TiDBサーバーとTiFlash計算ノードは、ストレージレベルのレプリケーションによって保護されているこれらのTiKVおよびTiFlash書き込みノードとの間で読み書きを行います。 diff --git a/tidb-cloud/serverless-private-link-connection-to-aws-rds.md b/tidb-cloud/serverless-private-link-connection-to-aws-rds.md index 63ed1d1a8e384..a96aca62ff8b4 100644 --- a/tidb-cloud/serverless-private-link-connection-to-aws-rds.md +++ b/tidb-cloud/serverless-private-link-connection-to-aws-rds.md @@ -96,7 +96,7 @@ AWSコンソールでロードバランサーとAWSエンドポイントサー エンドポイントサービスをRDSと同じリージョンに設定するには、以下の手順を実行してください。 -1. エンドポイント[エンドポイントサービス](https://console.aws.amazon.com/vpcconsole/home#EndpointServices)に移動して、エンドポイントサービスを作成します。次の情報を入力してください。 +1. [エンドポイントサービス](https://console.aws.amazon.com/vpcconsole/home#EndpointServices)に移動して、エンドポイントサービスを作成します。次の情報を入力してください。 - **ロードバランサータイプ**： `Network`を選択 - **利用可能なロードバランサー**：前の手順で作成したロードバランサーを入力してください。 @@ -106,10 +106,10 @@ AWSコンソールでロードバランサーとAWSエンドポイントサー 2. エンドポイントサービスの詳細ページに移動し、 `com.amazonaws.vpce..vpce-svc-xxxxxxxxxxxxxxxxx`の形式でエンドポイントサービス名をコピーしてください。この名前をTiDB Cloudに提供する必要があります。 -3. エンドポイントサービスの詳細ページで、 **[プリンシパルを許可]**タブをクリックし、取得した AWS アカウント ID を許可[前提条件](#prerequisites)に追加します。 例えば、 `arn:aws:iam:::root`のように追加します。 +3. エンドポイントサービスの詳細ページで、 **[プリンシパルを許可]**タブをクリックし、[前提条件](#prerequisites)で取得した AWS アカウント ID を許可リストに追加します。例えば、 `arn:aws:iam:::root`のように追加します。 ## ステップ3. TiDB CloudでAWSエンドポイントサービスのプライベートリンク接続を作成します。 {#step-3-create-an-aws-endpoint-service-private-link-connection-in-tidb-cloud} TiDB CloudコンソールまたはTiDB Cloud CLIを使用して、プライベートリンク接続を作成できます。 -詳細については、 [AWS Endpoint Service のプライベートリンク接続を作成します。](/tidb-cloud/serverless-private-link-connection.md#create-an-aws-endpoint-service-private-link-connection)参照してください。 +詳細については、 [AWS Endpoint Service のプライベートリンク接続を作成する](/tidb-cloud/serverless-private-link-connection.md#create-an-aws-endpoint-service-private-link-connection)参照してください。 diff --git a/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md b/tidb-cloud/set-up-private-endpoint-connections-on-alibaba-cloud.md index 09c33ad6f04ee..07d84b539334c 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 @@ -58,7 +58,7 @@ Alibaba Cloud管理コンソールを使用してVPCインターフェースエ 9. エンドポイントの状態が**アクティブ**になり、接続状態が**接続**済みになるまで待ちます。 -### ステップ3．TiDB TiDB Cloudでプライベートエンドポイントを認証する（オプション） {#step-3-authorize-your-private-endpoint-in-tidb-cloud-optional} +### ステップ3．TiDB Cloudでプライベートエンドポイントを認証する（オプション） {#step-3-authorize-your-private-endpoint-in-tidb-cloud-optional} > **注記：** > diff --git a/tidb-cloud/tidb-cloud-glossary.md b/tidb-cloud/tidb-cloud-glossary.md index 8bd595f913464..b78fe852a0689 100644 --- a/tidb-cloud/tidb-cloud-glossary.md +++ b/tidb-cloud/tidb-cloud-glossary.md @@ -123,10 +123,10 @@ TiDB Cloudでは、プロジェクトを使用してTiDBリソースをグルー プロジェクトの機能はプロジェクトの種類によって異なります。現在、プロジェクトには以下の3種類があります。 - **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) 。 +- **TiDB X プロジェクト**: このプロジェクトタイプは TiDB X インスタンスでのみ使用されます。プロジェクトごとに TiDB X インスタンスの RBAC を管理できます。TiDB X プロジェクトは [**My TiDB**](https://tidbcloud.com/tidbs) ページでプロジェクトを作成する際のデフォルトのプロジェクトタイプです。 +- **TiDB X 仮想プロジェクト**: このプロジェクトは仮想プロジェクトであり、管理機能は提供しません。これは、どのプロジェクトにも属さない TiDB X インスタンスの仮想コンテナとして機能するため、これらのインスタンスには、プロジェクト ID を使用して TiDB Cloud API 経由でアクセスできます。各組織には一意の仮想プロジェクト ID があります。この ID は、 [**My TiDB**](https://tidbcloud.com/tidbs) ページのプロジェクト表示から取得できます。 -これらのプロジェクト タイプの違いの詳細については、 [プロジェクト](/tidb-cloud/manage-user-access.md#projects)を参照してください。 +これらのプロジェクトタイプの違いの詳細については、 [プロジェクト](/tidb-cloud/manage-user-access.md#projects)を参照してください。 ### プロジェクトメンバー {#project-members} @@ -150,7 +150,7 @@ TiDB Cloudでは、プロジェクトを使用してTiDBリソースをグルー - TiDB Cloudリージョン - TiDB Cloudリソースがデプロイされる地理的領域。TiDB TiDB Cloudリージョンは少なくとも3つのアベイラビリティゾーンで構成され、クラスターまたはインスタンスはこれらのゾーンにまたがってデプロイされます。 + TiDB Cloudリソースがデプロイされる地理的領域。TiDB Cloudリージョンは少なくとも3つのアベイラビリティゾーンで構成され、クラスターまたはインスタンスはこれらのゾーンにまたがってデプロイされます。 - TiDBリージョン @@ -185,13 +185,13 @@ TiDB Cloud Dedicatedおよび TiDB セルフマネージドの場合、リクエ ### 支出限度額 {#spending-limit} -は、特定のワークロードに対して1か月あたりに費やすことができる最大金額を指します。これは、TiDB Cloud Starterインスタンスの予算を設定できるコスト管理メカニズムです。 [支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)制限が0に設定されている場合、 TiDB Cloud Starterインスタンスは無料のままです。支出制限が0より大きい場合は、クレジットカードを追加する必要があります。 +は、特定のワークロードに対して1か月あたりに費やすことができる最大金額を指します。これは、TiDB Cloud Starterインスタンスの予算を設定できるコスト管理メカニズムです。 [支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)が0に設定されている場合、 TiDB Cloud Starterインスタンスは無料のままです。支出限度額が0より大きい場合は、クレジットカードを追加する必要があります。 ## T {#t} ### 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-storage.md)、 [TiFlash](/tiflash/tiflash-overview.md)ノードの数を指定できます)、storage構成、スケーリングモデルなどのインフラストラクチャの詳細が明示的に含まれています。 ### TiDBノード {#tidb-node} diff --git a/tidb-cloud/top-ru.md b/tidb-cloud/top-ru.md index 172562e1a429f..54ef23eaa6e7e 100644 --- a/tidb-cloud/top-ru.md +++ b/tidb-cloud/top-ru.md @@ -5,7 +5,7 @@ summary: Top RUを使用して、1分単位の粒度で最もリクエストユ # トップRU {#top-ru} -**Top RUは、** SQL文をリクエストユニット（RU）消費量に基づいてランク付けし、RU使用量を押し上げているクエリを迅速に特定するのに役立ちます。TiDB TiDB Cloud EssentialまたはTiDB Cloud Premiumインスタンスのメトリクスで予期せぬRUの急増に気づいた場合は、Top RUを使用して原因となっているSQL文を特定し、的を絞った対策を講じてください。 +**Top RUは、** SQL文をリクエストユニット（RU）消費量に基づいてランク付けし、RU使用量を押し上げているクエリを迅速に特定するのに役立ちます。TiDB Cloud EssentialまたはTiDB Cloud Premiumインスタンスのメトリクスで予期せぬRUの急増に気づいた場合は、Top RUを使用して原因となっているSQL文を特定し、的を絞った対策を講じてください。 > **注記：** > @@ -43,7 +43,7 @@ TiDB Cloudプランによって、RUの主要機能は異なります。 カスタム時間範囲の場合： - - 利用可能な開始日の最短日は、データ保持期間によって異なります。TiDB TiDB Cloud Premiumインスタンスの場合は**30日前**、 TiDB Cloud Essentialインスタンスの場合は**7日前です**。 + - 利用可能な開始日の最短日は、データ保持期間によって異なります。TiDB Cloud Premiumインスタンスの場合は**30日前**、 TiDB Cloud Essentialインスタンスの場合は**7日前です**。 - 1回のクエリの最大有効期間は**24時間**です。 - **上位N** ：表示するSQL文の数を指定します。 @@ -147,7 +147,7 @@ RUスパイクを調査するには、以下のワークフローを使用して [Top SQL](/tidb-cloud/tidb-cloud-clinic.md#monitor-top-sql)特定のTiDBまたはTiKVノードにおけるCPU時間に基づいてSQLステートメントをランク付けします。これはTiDB Cloud Dedicatedクラスタに適用されます。 -Top RUは、インスタンスレベルでのリクエストユニット（RU）消費量に基づいてSQLステートメントをランク付けし、ユーザーレベルでの内訳をサポートします。TiDB TiDB Cloud PremiumインスタンスとTiDB Cloud Essentialインスタンスに適用されます。 +Top RUは、インスタンスレベルでのリクエストユニット（RU）消費量に基づいてSQLステートメントをランク付けし、ユーザーレベルでの内訳をサポートします。TiDB Cloud PremiumインスタンスとTiDB Cloud Essentialインスタンスに適用されます。 ### Top RUにデータがないのはなぜですか？ {#why-is-there-no-data-in-top-ru} diff --git a/tidb-lightning/tidb-lightning-distributed-import.md b/tidb-lightning/tidb-lightning-distributed-import.md index 2002141fa45ba..4eb2903d93435 100644 --- a/tidb-lightning/tidb-lightning-distributed-import.md +++ b/tidb-lightning/tidb-lightning-distributed-import.md @@ -122,7 +122,7 @@ 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はデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。 +- ローカルディスク（構成`sort-kv-dir`で制御）とTiKVクラスターに、データのインポートに必要な空き容量があるかどうかを確認してください。必要なディスク容量については、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)と[リソース要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)を参照してください。TiDB Lightningはデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。 - TiKVクラスタ内のリージョンが均等に分散されているか、また空きリージョンが多すぎないかを確認してください。空きリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 - データソースからデータが順番にインポートされているか確認します。確認結果に基づいて`mydumper.batch-size`のサイズが自動的に調整されます。そのため、 `mydumper.batch-size`構成は利用できなくなります。 diff --git a/tidb-lightning/tidb-lightning-prechecks.md b/tidb-lightning/tidb-lightning-prechecks.md index 051c2538e2f3d..d1c01b6a5561f 100644 --- a/tidb-lightning/tidb-lightning-prechecks.md +++ b/tidb-lightning/tidb-lightning-prechecks.md @@ -13,7 +13,7 @@ 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 クラスターに、データのインポートに十分な空き容量があるかどうかを確認します。TiDB Lightning はデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。物理インポートモードでは、外部ソートをローカルで実行する必要があるため、 TiDB Lightning はローカルstorageが十分かどうかも確認します。TiKV クラスターの空き容量とローカルストレージのstorage容量 ( `sort-kv-dir`で制御) の詳細については、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)と[リソース要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)を参照してください。 | | リージョン配信状況 | = 5.3.0 | TiKVクラスタ内のリージョンが均等に分散されているか、また空のリージョンが多すぎないかを確認してください。空のリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 | | データファイル内の非常に大きなCSVファイル | = 5.3.0 | バックアップファイルに10GiBを超えるCSVファイルがあり、自動スライスが有効になっていない場合（StrictFormat=false）、インポートのパフォーマンスに影響します。このチェックは、データが正しい形式であること、および自動スライスが有効になっていることを確認するためのものです。 | | ブレークポイントからの回復 | = 5.3.0 | このチェックにより、ブレークポイント回復プロセス中に、間違ったデータがインポートされるような変更がデータベースのソース ファイルまたはスキーマに加えられないことが保証されます。 | From 7dec2a201f410e8c3f5c0e4e19236751d6ccc936 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Fri, 12 Jun 2026 13:46:38 +0900 Subject: [PATCH 2/2] i18n(ja): address gemini-code-assist review comments on PR #23036 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fixes: - migrate-large-mysql-to-tidb.md: storage時間→保存期間, storage容量→ストレージ容量 - pd-recover.md: 存続している→生存している - architecture-concepts.md: remove spaces around Premium/RCU - essential-changefeed-sink-to-kafka.md: remove spaces around Kafka - essential-changefeed-sink-to-mysql.md: fix spacing and add missing particle - tidb-cloud-auditing-premium.md: 監査フィルタルール→監査フィルタールール - tidb-cloud-release-notes.md: クロス AZ→クロスAZ - serverless-private-link-connection-to-aws-rds.md: remove spaces around AWS - tidb-cloud-glossary.md: storage構成→ストレージ構成 - tidb-lightning-prechecks.md: fix spacing and terminology inconsistencies --- migrate-large-mysql-to-tidb.md | 4 ++-- pd-recover.md | 2 +- tidb-cloud/architecture-concepts.md | 2 +- tidb-cloud/branch-overview.md | 2 +- tidb-cloud/connect-via-standard-connection-serverless.md | 2 +- tidb-cloud/essential-changefeed-sink-to-kafka.md | 4 ++-- tidb-cloud/essential-changefeed-sink-to-mysql.md | 2 +- tidb-cloud/premium/tidb-cloud-auditing-premium.md | 2 +- tidb-cloud/releases/tidb-cloud-release-notes.md | 2 +- tidb-cloud/serverless-private-link-connection-to-aws-rds.md | 2 +- tidb-cloud/tidb-cloud-glossary.md | 4 ++-- tidb-lightning/tidb-lightning-prechecks.md | 2 +- 12 files changed, 15 insertions(+), 15 deletions(-) diff --git a/migrate-large-mysql-to-tidb.md b/migrate-large-mysql-to-tidb.md index c8e4bd26d8a19..6eafbe4a6d791 100644 --- a/migrate-large-mysql-to-tidb.md +++ b/migrate-large-mysql-to-tidb.md @@ -27,7 +27,7 @@ summary: MySQLからTiDBへ大規模データセットを移行する方法を - Dumplingには、データソース全体を保存できる（またはエクスポートされるすべての上流テーブルを保存できる）ディスク容量が必要です。SSD推奨です。必要なスペースを計算するには、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)を参照してください。 - インポート処理中、 TiDB Lightningはソート済みのキーと値のペアを保存するための一時的な領域を必要とします。ディスク容量は、データソースの最大の単一テーブルを格納できるのに十分な量が必要です。 -- データ総量が大きい場合は、上流側のbinlogのstorage時間を延長することができます。これは、増分レプリケーション中にバイナリログが失われないようにするためです。 +- データ総量が大きい場合は、上流側のbinlogの保存期間を延長することができます。これは、増分レプリケーション中にバイナリログが失われないようにするためです。 **注**： DumplingによってMySQLからエクスポートされる正確なデータ量を計算することは困難ですが、次のSQLステートメントを使用して`information_schema.tables`テーブルの`DATA_LENGTH`フィールドを要約することで、データ量を推定できます。 @@ -62,7 +62,7 @@ LIMIT ### ターゲットとなるTiKVクラスターのディスク容量 {#disk-space-for-the-target-tikv-cluster} -ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットの TiKV クラスターのstorage容量は**、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、ターゲットの TiKV クラスターは、データソースのサイズの 6 倍よりも大きなstorage容量が必要です。この式に`x 2`が含まれている理由は次のとおりです。 +ターゲットの TiKV クラスターには、インポートされたデータを保存するのに十分なディスク容量が必要です。[標準ハードウェア要件](/hardware-and-software-requirements.md)に加えて、ターゲットの TiKV クラスターのストレージ容量は**、データソースのサイズ × レプリカ数× 2**よりも大きくなければなりません。たとえば、クラスターがデフォルトで 3 つのレプリカを使用する場合、ターゲットの TiKV クラスターは、データソースのサイズの 6 倍よりも大きなストレージ容量が必要です。この式に`x 2`が含まれている理由は次のとおりです。 - インデックスには余分な容量が必要になる場合があります。 - RocksDBには空間増幅がある。 diff --git a/pd-recover.md b/pd-recover.md index e07c0a41b1cee..75bce2f8869e6 100644 --- a/pd-recover.md +++ b/pd-recover.md @@ -42,7 +42,7 @@ PD Recover インストール パッケージは、 TiDB Toolkitに含まれて > **注記：** > -> - コマンドラインで`--data-dir`が指定されていない場合は、 `conf/pd.toml`内の`data-dir`が、存続しているPDノードの元のデータディレクトリを正しく指していることを確認してください。そうでない場合、`pd-recover`は後続の操作で失敗する可能性があります。 +> - コマンドラインで`--data-dir`が指定されていない場合は、 `conf/pd.toml`内の`data-dir`が、生存しているPDノードの元のデータディレクトリを正しく指していることを確認してください。そうでない場合、`pd-recover`は後続の操作で失敗する可能性があります。 > - `conf/pd.toml`とコマンドライン引数の両方で`data-dir`が指定されている場合、 `conf/pd.toml`の`data-dir`設定が優先されます。 ### ステップ3： pd-recoverを使用してメタデータを修復する {#step-3-repair-metadata-using-code-pd-recover-code} diff --git a/tidb-cloud/architecture-concepts.md b/tidb-cloud/architecture-concepts.md index aa51a64a48c00..26cd2004dcd7f 100644 --- a/tidb-cloud/architecture-concepts.md +++ b/tidb-cloud/architecture-concepts.md @@ -180,7 +180,7 @@ TiDBノードを複数デプロイすることで、水平方向に拡張し、 ### RCUの自動スケーリング {#rcu-auto-scaling} -TiDB Cloud Premium インスタンスを構成する際に、ワークロードに必要な最大 RCU 数 ( `RCU_max` ) を指定します。TiDB Cloudは`0.25 * RCU_max`から`RCU_max`までの範囲で自動的にスケーリングします。 +TiDB Cloud Premiumインスタンスを構成する際に、ワークロードに必要な最大RCU数 ( `RCU_max` ) を指定します。TiDB Cloudは`0.25 * RCU_max`から`RCU_max`までの範囲で自動的にスケーリングします。 例えば、最大容量を20,000 RCUに設定した場合、 TiDB Cloudはリアルタイムの需要に基づいて、容量を5,000 RCUから20,000 RCUの間で動的にスケーリングします。このスケーリングは自動的かつ瞬時に行われるため、手動操作や遅延なしに、いつでも最大数のRCUを消費できます。 diff --git a/tidb-cloud/branch-overview.md b/tidb-cloud/branch-overview.md index 42e3bb298ddd3..84d2e47b1026c 100644 --- a/tidb-cloud/branch-overview.md +++ b/tidb-cloud/branch-overview.md @@ -5,7 +5,7 @@ summary: TiDB Cloudのブランチの概念を学びましょう。 # TiDB Cloudブランチング（ベータ版）の概要 {#tidb-cloud-branching-beta-overview} -TiDB Cloud、 TiDB Cloud StarterおよびTiDB Cloud Essentialインスタンスのブランチを作成できます。TiDB Cloud StarterまたはEssentialインスタンスのブランチは、元のTiDB Cloud StarterまたはEssentialインスタンスから分岐したデータコピーを含む独立したインスタンスです。これにより、隔離された環境が提供され、元のTiDB Cloud StarterまたはEssentialインスタンスへの影響を気にすることなく、自由に実験を行うことができます。 +TiDB Cloudでは、TiDB Cloud StarterおよびTiDB Cloud Essentialインスタンスのブランチを作成できます。TiDB Cloud StarterまたはEssentialインスタンスのブランチは、元のTiDB Cloud StarterまたはEssentialインスタンスから分岐したデータコピーを含む独立したインスタンスです。これにより、隔離された環境が提供され、元のTiDB Cloud StarterまたはEssentialインスタンスへの影響を気にすることなく、自由に実験を行うことができます。 ブランチ機能を使用することで、開発者は並行して作業を進め、新機能を迅速に反復開発し、本番データベースに影響を与えることなく問題をトラブルシューティングし、必要に応じて変更を簡単に元に戻すことができます。この機能は、開発およびデプロイプロセスを効率化すると同時に、本番データベースの高い安定性と信頼性を確保します。 diff --git a/tidb-cloud/connect-via-standard-connection-serverless.md b/tidb-cloud/connect-via-standard-connection-serverless.md index 8a03106964d0b..0b7a2acc64cb1 100644 --- a/tidb-cloud/connect-via-standard-connection-serverless.md +++ b/tidb-cloud/connect-via-standard-connection-serverless.md @@ -42,7 +42,7 @@ summary: パブリックエンドポイントを介して、 TiDB Cloud Starter -4. TiDB Cloud、 TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンス用に[支店](/tidb-cloud/branch-overview.md)を作成できます。ブランチが作成されると、**ブランチの**ドロップダウン リストからブランチに接続できます。 `main` TiDB Cloud StarterまたはEssentialインスタンス自体を表します。 +4. TiDB Cloudでは、TiDB Cloud StarterまたはTiDB Cloud Essentialインスタンス用に[支店](/tidb-cloud/branch-overview.md)を作成できます。ブランチが作成されると、**ブランチの**ドロップダウン リストからブランチに接続できます。 `main` TiDB Cloud StarterまたはEssentialインスタンス自体を表します。 5. まだパスワードを設定していない場合は、 **「パスワードを生成」をクリックしてランダムなパスワード**を生成してください。生成されたパスワードは二度と表示されませんので、安全な場所に保存してください。 diff --git a/tidb-cloud/essential-changefeed-sink-to-kafka.md b/tidb-cloud/essential-changefeed-sink-to-kafka.md index 008723b8ae672..08a4c8b9ea2ae 100644 --- a/tidb-cloud/essential-changefeed-sink-to-kafka.md +++ b/tidb-cloud/essential-changefeed-sink-to-kafka.md @@ -186,11 +186,11 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト 変更フィードで全ての変更ログに対して1つのKafkaトピックを作成する場合は、このモードを選択してください。そうすると、変更フィード内のすべてのKafkaメッセージが1つのKafkaトピックに送信されます。トピック名は**「トピック名」**フィールドで指定できます。 -8. **パーティション分散**領域では、Kafka メッセージの送信先パーティションを決定できます。**すべてのテーブルに対して単一のパーティションディスパッチャを**定義することも、**テーブルごとに異なるパーティションディスパッチャを**定義することもできます。TiDB Cloudは、次の4種類のディスパッチャを提供しています。 +8. **パーティション分散**領域では、Kafkaメッセージの送信先パーティションを決定できます。**すべてのテーブルに対して単一のパーティションディスパッチャを**定義することも、**テーブルごとに異なるパーティションディスパッチャを**定義することもできます。TiDB Cloudは、次の4種類のディスパッチャを提供しています。 - **プライマリキーまたはインデックス値に基づいて変更ログをKafkaパーティションに分散します。** - 変更フィードでテーブルの Kafka メッセージを異なるパーティションに送信する場合は、この分散方法を選択してください。行の変更ログの主キーまたはインデックス値によって、変更ログの送信先パーティションが決まります。主キーを使用する場合は、 **「インデックス名」**フィールドを空のままにしてください。この分散方法は、パーティションのバランスを改善し、行レベルの順序性を確保します。 + 変更フィードでテーブルのKafkaメッセージを異なるパーティションに送信する場合は、この分散方法を選択してください。行の変更ログの主キーまたはインデックス値によって、変更ログの送信先パーティションが決まります。主キーを使用する場合は、 **「インデックス名」**フィールドを空のままにしてください。この分散方法は、パーティションのバランスを改善し、行レベルの順序性を確保します。 - **変更ログをテーブルごとにKafkaパーティションに分散する** diff --git a/tidb-cloud/essential-changefeed-sink-to-mysql.md b/tidb-cloud/essential-changefeed-sink-to-mysql.md index c529d2118beec..327c206839ba6 100644 --- a/tidb-cloud/essential-changefeed-sink-to-mysql.md +++ b/tidb-cloud/essential-changefeed-sink-to-mysql.md @@ -60,7 +60,7 @@ MySQLサービスがパブリックネットワーク経由でアクセスでき 既存のデータを読み込むには： -1. [`tidb_gc_life_time`](https://docs.pingcap.com/tidb/stable/system-variables#tidb_gc_life_time-new-in-v50)以下の 2 つの操作の合計時間よりも長く設定することで、この期間中の履歴データが TiDB によってガベージ コレクションされないようにします。 +1. [`tidb_gc_life_time`](https://docs.pingcap.com/tidb/stable/system-variables#tidb_gc_life_time-new-in-v50)を以下の2つの操作の合計時間よりも長く設定することで、この期間中の履歴データがTiDBによってガベージ コレクションされないようにします。 - 既存データのエクスポートとインポートにかかる時間 - **Sink to MySQL**を作成する時間 diff --git a/tidb-cloud/premium/tidb-cloud-auditing-premium.md b/tidb-cloud/premium/tidb-cloud-auditing-premium.md index f027db57db365..1caef370db342 100644 --- a/tidb-cloud/premium/tidb-cloud-auditing-premium.md +++ b/tidb-cloud/premium/tidb-cloud-auditing-premium.md @@ -9,7 +9,7 @@ TiDB Cloudは、実行されたSQLステートメントなど、データベー 組織のユーザーアクセスポリシーやその他の情報セキュリティ対策の有効性を評価するには、データベース監査ログを定期的に分析することがセキュリティ上のベストプラクティスです。 -監査ログ機能は**デフォルトでは無効になっています**。TiDB Cloud Premiumインスタンスを監査するには、まず監査ログを有効にしてから、監査フィルタルールを設定する必要があります。 +監査ログ機能は**デフォルトでは無効になっています**。TiDB Cloud Premiumインスタンスを監査するには、まず監査ログを有効にしてから、監査フィルタールールを設定する必要があります。 > **注記：** > diff --git a/tidb-cloud/releases/tidb-cloud-release-notes.md b/tidb-cloud/releases/tidb-cloud-release-notes.md index 56fabf403121b..9f61c4413ab5d 100644 --- a/tidb-cloud/releases/tidb-cloud-release-notes.md +++ b/tidb-cloud/releases/tidb-cloud-release-notes.md @@ -30,7 +30,7 @@ aliases: ['/ja/tidbcloud/supported-tidb-versions','/ja/tidbcloud/release-notes'] - 2026年6月9日以降に新たに作成される[TiDB Cloud Essential](/tidb-cloud/select-cluster-tier.md#essential)インスタンスは、単一のアベイラビリティゾーンにデプロイされ、リージョンごとの高可用性はサポートされません。 - リージョンの高可用性とクロス AZ フェイルオーバーが必要な場合は、 [TiDB Cloud Premium](/tidb-cloud/select-cluster-tier.md#premium)を選択することを検討してください。 + リージョンの高可用性とクロスAZフェイルオーバーが必要な場合は、 [TiDB Cloud Premium](/tidb-cloud/select-cluster-tier.md#premium)を選択することを検討してください。 この変更は、2026年6月9日より前に作成されたTiDB Cloud Essentialインスタンスには影響しません。 diff --git a/tidb-cloud/serverless-private-link-connection-to-aws-rds.md b/tidb-cloud/serverless-private-link-connection-to-aws-rds.md index a96aca62ff8b4..f6943305de376 100644 --- a/tidb-cloud/serverless-private-link-connection-to-aws-rds.md +++ b/tidb-cloud/serverless-private-link-connection-to-aws-rds.md @@ -106,7 +106,7 @@ AWSコンソールでロードバランサーとAWSエンドポイントサー 2. エンドポイントサービスの詳細ページに移動し、 `com.amazonaws.vpce..vpce-svc-xxxxxxxxxxxxxxxxx`の形式でエンドポイントサービス名をコピーしてください。この名前をTiDB Cloudに提供する必要があります。 -3. エンドポイントサービスの詳細ページで、 **[プリンシパルを許可]**タブをクリックし、[前提条件](#prerequisites)で取得した AWS アカウント ID を許可リストに追加します。例えば、 `arn:aws:iam:::root`のように追加します。 +3. エンドポイントサービスの詳細ページで、 **[プリンシパルを許可]**タブをクリックし、[前提条件](#prerequisites)で取得したAWSアカウントIDを許可リストに追加します。例えば、 `arn:aws:iam:::root`のように追加します。 ## ステップ3. TiDB CloudでAWSエンドポイントサービスのプライベートリンク接続を作成します。 {#step-3-create-an-aws-endpoint-service-private-link-connection-in-tidb-cloud} diff --git a/tidb-cloud/tidb-cloud-glossary.md b/tidb-cloud/tidb-cloud-glossary.md index b78fe852a0689..c5ac8e3dee925 100644 --- a/tidb-cloud/tidb-cloud-glossary.md +++ b/tidb-cloud/tidb-cloud-glossary.md @@ -185,13 +185,13 @@ TiDB Cloud Dedicatedおよび TiDB セルフマネージドの場合、リクエ ### 支出限度額 {#spending-limit} -は、特定のワークロードに対して1か月あたりに費やすことができる最大金額を指します。これは、TiDB Cloud Starterインスタンスの予算を設定できるコスト管理メカニズムです。 [支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)が0に設定されている場合、 TiDB Cloud Starterインスタンスは無料のままです。支出限度額が0より大きい場合は、クレジットカードを追加する必要があります。 +支出限度額は、特定のワークロードに対して1か月あたりに費やすことができる最大金額を指します。これは、TiDB Cloud Starterインスタンスの予算を設定できるコスト管理メカニズムです。 [支出限度額](/tidb-cloud/manage-serverless-spend-limit.md)が0に設定されている場合、 TiDB Cloud Starterインスタンスは無料のままです。支出限度額が0より大きい場合は、クレジットカードを追加する必要があります。 ## T {#t} ### TiDBクラスター {#tidb-cluster} -TiDB Cloudでは、クラスターは TiDB の専用クラウド展開であり、ノードトポロジー ( [TiDB](/tidb-computing.md)ノード、[TiKV](/tidb-storage.md)、 [TiFlash](/tiflash/tiflash-overview.md)ノードの数を指定できます)、storage構成、スケーリングモデルなどのインフラストラクチャの詳細が明示的に含まれています。 +TiDB Cloudでは、クラスターはクラウド上に専用デプロイされたTiDB環境であり、ノードトポロジー ( [TiDB](/tidb-computing.md)ノード、[TiKV](/tidb-storage.md)、 [TiFlash](/tiflash/tiflash-overview.md)ノードの数を指定できます)、ストレージ構成、スケーリングモデルなどのインフラストラクチャの詳細が明示的に含まれています。 ### TiDBノード {#tidb-node} diff --git a/tidb-lightning/tidb-lightning-prechecks.md b/tidb-lightning/tidb-lightning-prechecks.md index d1c01b6a5561f..9fdee947ca3df 100644 --- a/tidb-lightning/tidb-lightning-prechecks.md +++ b/tidb-lightning/tidb-lightning-prechecks.md @@ -13,7 +13,7 @@ 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`で制御) の詳細については、 [ターゲットデータベースのストレージ要件](/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クラスターに、データのインポートに十分な空き容量があるかどうかを確認します。TiDB Lightningはデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。物理インポートモードでは、外部ソートをローカルで実行する必要があるため、TiDB Lightningはローカルストレージが十分かどうかも確認します。TiKVクラスターの空き容量とローカルストレージのストレージ容量 ( `sort-kv-dir`で制御) の詳細については、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)と[リソース要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)を参照してください。 | | リージョン配信状況 | = 5.3.0 | TiKVクラスタ内のリージョンが均等に分散されているか、また空のリージョンが多すぎないかを確認してください。空のリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 | | データファイル内の非常に大きなCSVファイル | = 5.3.0 | バックアップファイルに10GiBを超えるCSVファイルがあり、自動スライスが有効になっていない場合（StrictFormat=false）、インポートのパフォーマンスに影響します。このチェックは、データが正しい形式であること、および自動スライスが有効になっていることを確認するためのものです。 | | ブレークポイントからの回復 | = 5.3.0 | このチェックにより、ブレークポイント回復プロセス中に、間違ったデータがインポートされるような変更がデータベースのソース ファイルまたはスキーマに加えられないことが保証されます。 |