From 2c38f07c9a4a9a510d061b5cd43ae5ab085200c9 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 17 Aug 2026 15:02:48 +0900 Subject: [PATCH 1/2] i18n(ja): restore genuine 2-word TiDB Cloud UI labels to English (unconfirmed batch) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit These 228 candidate labels were skipped by the mechanical 2-word batch (#23535) because they couldn't be confirmed via a plain dbaas-ui grep (mostly third-party console fields — AWS, Azure, Alibaba Cloud, GCP, Kafka, Datadog, New Relic, n8n, Airbyte, PagerDuty, Slack — which dbaas-ui doesn't cover, plus a handful of TiDB-native labels the grep missed). Each was individually triaged against EN (release-8.5) and, for TiDB-native items, dbaas-ui with a strict STRONG/WEAK/ COMMENT_ONLY/NO_HIT classifier, distinguishing genuine clickable UI elements from prose/marketing/category-header bullets that merely share the same words (the "No cost"/"High availability" false-positive pattern from earlier batches). 265 occurrences fixed across 47 files. ~70 further candidates were deliberately left in Japanese as category-header/concept-heading prose, not clickable UI (same precedent as architecture-concepts.md). Along the way this also fixed several pre-existing defects surfaced by the same EN comparison: mismatched AWS IAM button-label pairs (Attach Policies vs Attach Policy treated as the same word), particle- and bracket-trapped-in-bold spans, a word-order/position-pairing mis-mapping (Source/Target engine, Signing method/Account key, Export Path), a mistranslation (一般公開→Public accessible), and an orphaned bracket left over from an incomplete straddling-bracket fix. "Import dashboard" (monitor-new-relic-integration.md) was explicitly skipped — already handled by #23540. --- tidb-cloud/backup-and-restore.md | 8 +-- tidb-cloud/changefeed-overview.md | 4 +- tidb-cloud/changefeed-sink-to-apache-kafka.md | 8 +-- .../changefeed-sink-to-apache-pulsar.md | 6 +-- .../changefeed-sink-to-cloud-storage.md | 30 +++++------ tidb-cloud/changefeed-sink-to-mysql.md | 6 +-- tidb-cloud/changefeed-sink-to-tidb-cloud.md | 6 +-- .../configure-external-storage-access.md | 20 +++---- tidb-cloud/connected-slack-ticket-creation.md | 4 +- .../connected-slack-ticket-interaction.md | 4 +- .../data-service-manage-github-connection.md | 4 +- tidb-cloud/dedicated-external-storage.md | 22 ++++---- .../essential-changefeed-sink-to-kafka.md | 2 +- .../integrate-tidbcloud-with-airbyte.md | 8 +-- .../integrate-tidbcloud-with-aws-lambda.md | 4 +- tidb-cloud/integrate-tidbcloud-with-n8n.md | 18 +++---- tidb-cloud/integrate-tidbcloud-with-zapier.md | 8 +-- .../migrate-from-mysql-using-aws-dms.md | 36 ++++++------- ...migrate-from-mysql-using-data-migration.md | 36 ++++++------- .../migrate-from-oracle-using-aws-dms.md | 6 +-- ...al-data-from-mysql-using-data-migration.md | 4 +- tidb-cloud/monitor-alert-slack.md | 4 +- tidb-cloud/monitor-alert-zoom.md | 4 +- tidb-cloud/monitor-datadog-integration.md | 8 +-- tidb-cloud/monitor-new-relic-integration.md | 2 +- ...mium-via-alibaba-cloud-private-endpoint.md | 2 +- .../premium/tidb-cloud-auditing-premium.md | 26 +++++----- ...private-link-connection-to-alicloud-rds.md | 12 ++--- ...s-private-link-connection-to-amazon-msk.md | 4 +- ...rivate-link-connection-to-aws-confluent.md | 4 +- ...less-private-link-connection-to-aws-rds.md | 10 ++-- ...ection-to-self-hosted-kafka-in-alicloud.md | 38 +++++++------- .../serverless-private-link-connection.md | 6 +-- ...e-endpoint-connections-on-alibaba-cloud.md | 2 +- ...p-private-endpoint-connections-on-azure.md | 2 +- ...te-endpoint-connections-on-google-cloud.md | 8 +-- ...private-endpoint-connections-serverless.md | 4 +- ...-self-hosted-kafka-private-link-service.md | 52 +++++++++---------- ...lf-hosted-kafka-private-service-connect.md | 40 +++++++------- tidb-cloud/tidb-cloud-auditing.md | 30 +++++------ tidb-cloud/tidb-cloud-billing.md | 2 +- tidb-cloud/tidb-cloud-clinic.md | 6 +-- tidb-cloud/tidb-cloud-connect-aws-dms.md | 24 ++++----- tidb-cloud/tidb-cloud-console-auditing.md | 2 +- tidb-cloud/tidb-cloud-sql-tuning-overview.md | 2 +- tidb-cloud/tidb-cloud-support.md | 4 +- tidb-cloud/top-ru.md | 2 +- 47 files changed, 272 insertions(+), 272 deletions(-) diff --git a/tidb-cloud/backup-and-restore.md b/tidb-cloud/backup-and-restore.md index 5206d0655fb50..db4dba48f1d93 100644 --- a/tidb-cloud/backup-and-restore.md +++ b/tidb-cloud/backup-and-restore.md @@ -209,7 +209,7 @@ TiDB Cloud Dedicatedクラスターに手動バックアップを適用するに 2. 対象のバケットの詳細ページを開き、「**アクセス許可」**タブをクリックします。 3. **Bucket policy**までスクロールし、**編集**をクリックします。 4. 生成されたコマンドからポリシーの内容をコピーし、ポリシーエディタに貼り付けてください。 - 5. **「変更を保存」**をクリックしてください。 + 5. **Save changes**をクリックしてください。 5. エクスポートを開始するには、 **「エクスポート」**をクリックしてください。 @@ -232,11 +232,11 @@ TiDB Cloud Dedicatedクラスターに手動バックアップを適用するに - `storage.objects.create` - `storage.objects.delete` -5. **Cloud Storage**>**バケット**に移動し、対象のバケットを選択してから、**アクセス許可**>**アクセスを**許可 をクリックします。 +5. **Cloud Storage**>**バケット**に移動し、対象のバケットを選択してから、**アクセス許可**>**Grant Access**をクリックします。 -6. **「新しいプリンシパル」**で、手順3の**Service Account ID**を入力し、手順4の役割を割り当ててから、 **「保存」**をクリックします。 +6. **New principals**で、手順3の**Service Account ID**を入力し、手順4の役割を割り当ててから、 **「保存」**をクリックします。 -7. **「コンフィグレーション」**タブを開き、 **gsutil URI**をコピーして、 **「Google Cloud Storageへのバックアップのエクスポート」**ダイアログの**「エクスポートパス」**フィールドに貼り付けます。サブディレクトリにエクスポートする場合は、URIにパスサフィックスを追加します。 +7. **Configuration**タブを開き、 **gsutil URI**をコピーして、 **Export Backup to Google Cloud Storage**ダイアログの**Export Path**フィールドに貼り付けます。サブディレクトリにエクスポートする場合は、URIにパスサフィックスを追加します。 8. エクスポートを開始するには、 **「エクスポート」**をクリックしてください。 diff --git a/tidb-cloud/changefeed-overview.md b/tidb-cloud/changefeed-overview.md index b3acc28b2d1eb..e6860b7ba832f 100644 --- a/tidb-cloud/changefeed-overview.md +++ b/tidb-cloud/changefeed-overview.md @@ -124,13 +124,13 @@ TiDB Cloud Premiumでは、チェンジフィードのTiCDC 変更フィード - Apache Kafkaシンク：すべての設定。 - - MySQLシンク： **MySQL接続**、**Table Filter**、および**Event Filter**。 + - MySQLシンク： **MySQL Connection**、**Table Filter**、および**Event Filter**。 - Apache Kafkaシンク：すべての設定。 - - MySQLシンク： **MySQL接続**、**Table Filter**、および**Event Filter**。 + - MySQLシンク： **MySQL Connection**、**Table Filter**、および**Event Filter**。 - TiDB Cloudシンク: **TiDB Cloud Connection**、**Table Filter**、および**Event Filter**。 - クラウドストレージシンク：**Storage Endpoint**、**Table Filter**、および**Event Filter**。 diff --git a/tidb-cloud/changefeed-sink-to-apache-kafka.md b/tidb-cloud/changefeed-sink-to-apache-kafka.md index beb748202276d..d3588adeb66c2 100644 --- a/tidb-cloud/changefeed-sink-to-apache-kafka.md +++ b/tidb-cloud/changefeed-sink-to-apache-kafka.md @@ -258,8 +258,8 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン - **Tables matching**：この列では、イベントフィルターを適用するテーブルを設定できます。ルールの構文は、前の**Table Filter**領域で使用されているものと同じです。変更フィードごとに最大10個のイベントフィルタールールを追加できます。 - **Event Filter**：以下のイベントフィルターを使用して、変更フィードから特定のイベントを除外できます。 - - **イベントを無視する**：指定されたイベントタイプを除外します。 - - **SQL を無視**: 指定された式に一致する DDL イベントを除外します。たとえば、 `^drop` `DROP`で始まるステートメントを除外し、 `add column`は`ADD COLUMN`を含むステートメントを除外します。 + - **Ignore event**：指定されたイベントタイプを除外します。 + - **Ignore SQL**: 指定された式に一致する DDL イベントを除外します。たとえば、 `^drop` `DROP`で始まるステートメントを除外し、 `add column`は`ADD COLUMN`を含むステートメントを除外します。 - **Ignore insert value expression**: 特定の条件を満たす`INSERT`ステートメントを除外します。たとえば、 `id >= 100`は、 `INSERT`が 100 以上である`id`ステートメントを除外します。 - **新しい値の更新式を無視する**: 新しい値が指定された条件に一致する`UPDATE`ステートメントを除外します。たとえば、 `gender = 'male'`は`gender`が`male`になるような更新を除外します。 - **古い値の更新を無視する式**: 古い値が指定された条件に一致する`UPDATE`ステートメントを除外します。たとえば、 `age < 18` `age`の古い値が 18 未満である場合の更新を除外します。 @@ -333,13 +333,13 @@ TiDB Cloudの変更フィードがデータをApache Kafkaにストリーミン - **Replication Factor**：各KafkaメッセージがレプリケートされるKafkaサーバーの数を制御します。有効な値の範囲は、 [`min.insync.replicas`](https://kafka.apache.org/33/documentation.html#brokerconfigs_min.insync.replicas)からKafkaブローカーの数までです。 - **Partition Number**：トピックに存在するパーティションの数を制御します。有効な値の範囲は`[1, 10 * the number of Kafka brokers]`です。 -10. **[イベントの分割]**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 +10. **Split Event**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 11. **「次へ」**をクリックしてください。 ## ステップ4. 変更フィード仕様を設定します {#step-4-configure-your-changefeed-specification} -1. **「チェンジフィードの仕様」**領域で、チェンジフィードで使用する複製容量単位（RCU）チェンジフィードチェンジフィード容量ユニット（CCU）の数を指定します。 +1. **Changefeed Specification**領域で、チェンジフィードで使用する複製容量単位（RCU）チェンジフィードチェンジフィード容量ユニット（CCU）の数を指定します。 2. **Changefeed Name**欄に、変更フィードの名前を指定します。 3. **「次へ」**をクリックして、設定した内容を確認し、次のページへ進んでください。 diff --git a/tidb-cloud/changefeed-sink-to-apache-pulsar.md b/tidb-cloud/changefeed-sink-to-apache-pulsar.md index 0bb8b9be255ba..6491d97152782 100644 --- a/tidb-cloud/changefeed-sink-to-apache-pulsar.md +++ b/tidb-cloud/changefeed-sink-to-apache-pulsar.md @@ -122,8 +122,8 @@ Apache PulsarサービスにパブリックIPアクセスを提供する場合 - **Tables matching**：この列では、イベントフィルターを適用するテーブルを設定できます。ルールの構文は、前の**Table Filter**領域で使用されているものと同じです。変更フィードごとに最大10個のイベントフィルタールールを追加できます。 - **Event Filter**：以下のイベントフィルターを使用して、変更フィードから特定のイベントを除外できます。 - - **イベントを無視する**：指定されたイベントタイプを除外します。 - - **SQL を無視**: 指定された式に一致する DDL イベントを除外します。たとえば、 `^drop` `DROP`で始まるステートメントを除外し、 `add column`は`ADD COLUMN`を含むステートメントを除外します。 + - **Ignore event**：指定されたイベントタイプを除外します。 + - **Ignore SQL**: 指定された式に一致する DDL イベントを除外します。たとえば、 `^drop` `DROP`で始まるステートメントを除外し、 `add column`は`ADD COLUMN`を含むステートメントを除外します。 - **Ignore insert value expression**: 特定の条件を満たす`INSERT`ステートメントを除外します。たとえば、 `id >= 100`は、 `INSERT`が 100 以上である`id`ステートメントを除外します。 - **新しい値の更新式を無視する**: 新しい値が指定された条件に一致する`UPDATE`ステートメントを除外します。たとえば、 `gender = 'male'`は`gender`が`male`になるような更新を除外します。 - **古い値の更新を無視する式**: 古い値が指定された条件に一致する`UPDATE`ステートメントを除外します。たとえば、 `age < 18` `age`の古い値が 18 未満である場合の更新を除外します。 @@ -185,7 +185,7 @@ Apache PulsarサービスにパブリックIPアクセスを提供する場合 テーブルのPulsarメッセージを異なるパーティションに送信するように変更フィードを設定する場合は、この配信方法を選択してください。行の変更ログで指定された列の値によって、変更ログの送信先パーティションが決まります。この配信方法により、各パーティション内の順序が確保され、同じ列の値を持つ変更ログが同じパーティションに送信されることが保証されます。 -7. **[イベントの分割]**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 +7. **Split Event**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 8. **「次へ」**をクリックしてください。 diff --git a/tidb-cloud/changefeed-sink-to-cloud-storage.md b/tidb-cloud/changefeed-sink-to-cloud-storage.md index 4d0a06200ef4c..4eb5aec522de4 100644 --- a/tidb-cloud/changefeed-sink-to-cloud-storage.md +++ b/tidb-cloud/changefeed-sink-to-cloud-storage.md @@ -67,7 +67,7 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl
-**GCS**の場合、 **GCSエンドポイント**を入力する前に、まずGCSバケットへのアクセス権を付与する必要があります。以下の手順に従ってください。 +**GCS**の場合、 **GCS Endpoint**を入力する前に、まずGCSバケットへのアクセス権を付与する必要があります。以下の手順に従ってください。 1. TiDB Cloudコンソールで、**Service Account ID**を記録してください。このIDは、 TiDB CloudにGCSバケットへのアクセス権を付与するために使用されます。 @@ -83,7 +83,7 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl 3. 役割の名前、説明、ID、および役割の起動ステージを入力してください。役割名は、作成後に変更することはできません。 - 4. **「権限の追加」**をクリックします。役割に以下の権限を追加し、 **「追加」**をクリックします。 + 4. **Add permissions**をクリックします。役割に以下の権限を追加し、 **「追加」**をクリックします。 - storage.buckets.get - storage.オブジェクト.作成 @@ -96,13 +96,13 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl 3. [バケツ](https://console.cloud.google.com/storage/browser)ページに移動し、 TiDB CloudがアクセスするGCSバケットを選択してください。GCSバケットは、TiDBクラスタと同じリージョンにある必要があります。 -4. **バケットの詳細**ページで、 **[権限]**タブをクリックし、 **[アクセスを許可]**をクリックします。 +4. **Bucket details**ページで、 **[権限]**タブをクリックし、 **Grant access**をクリックします。 ![Grant Access to the bucket ](/media/tidb-cloud/changefeed/sink-to-cloud-storage-gcs-grant-access-1.png) 5. バケットへのアクセスを許可するには、以下の情報を入力し、 **「保存」**をクリックしてください。 - - **「新しいプリンシパル」**フィールドに、以前に記録した対象のTiDBクラスタの**Service Account ID**を貼り付けます。 + - **New Principals**フィールドに、以前に記録した対象のTiDBクラスタの**Service Account ID**を貼り付けます。 - **「役割を選択」**ドロップダウンリストに、先ほど作成したIAMロールの名前を入力し、フィルター結果からその名前を選択します。 @@ -110,7 +110,7 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl > > TiDB Cloudへのアクセス権を削除するには、付与したアクセス権を削除するだけです。 -6. **バケットの詳細**ページで、「**オブジェクト」**タブをクリックします。 +6. **Bucket details**ページで、「**オブジェクト」**タブをクリックします。 - バケットの gsutil URI を取得するには、[コピー] ボタンをクリックし、プレフィックスとして`gs://`を追加します。たとえば、バケット名が`test-sink-gcs`の場合、URI は`gs://test-sink-gcs/`になります。 @@ -129,25 +129,25 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl 1. [Azureポータル](https://portal.azure.com/)で、変更フィード データを保存するコンテナーを作成します。 - 1. 左側のナビゲーションペインで**「ストレージアカウント」**をクリックし、ストレージアカウントを選択します。 - 2. ストレージアカウントのナビゲーションメニューで、 **[データストレージ]** > **[コンテナー]**を選択し、 **[+コンテナー]**をクリックします。 + 1. 左側のナビゲーションペインで**Storage Accounts**をクリックし、ストレージアカウントを選択します。 + 2. ストレージアカウントのナビゲーションメニューで、 **Data storage** > **[コンテナー]**を選択し、 **+ Container**をクリックします。 3. 新しいコンテナの名前を入力し、匿名アクセスレベルを設定します（推奨レベルは**プライベート**です）。次に、 **[作成]**をクリックします。 2. 対象コンテナのURLを取得します。 1. コンテナ一覧から、対象のコンテナを選択してください。 - 2. コンテナの**「…」**をクリックし、次に**「コンテナのプロパティ」**を選択します。 + 2. コンテナの**「…」**をクリックし、次に**Container properties**を選択します。 3. **URL**値を後で使用するために保存します。たとえば`https://.blob.core.windows.net/`のように保存します。 3. SASトークンを生成します。 1. ストレージアカウントのナビゲーション メニューで、 **Security + networking** > **Shared access signature**を選択します。 - 2. **「許可されたサービス」**セクションで、 **「Blob」**を選択します。 + 2. **Allowed services**セクションで、 **「Blob」**を選択します。 3. **Allowed resource types**セクションで、 **「コンテナ」**と**「オブジェクト」**を選択します。 - 4. **「許可されたアクセス許可」**セクションで、 **「読み取り」** 、 **「書き込み」** 、 **「削除」** 、 **「一覧表示」** 、 **「作成」**を選択します。 + 4. **Allowed permissions**セクションで、 **「読み取り」** 、 **「書き込み」** 、 **「削除」** 、 **「一覧表示」** 、 **「作成」**を選択します。 5. SASトークンの有効期間を、ニーズを満たすのに十分な長さに指定してください。 @@ -189,8 +189,8 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl - **Tables matching**：この列では、イベントフィルターを適用するテーブルを設定できます。ルールの構文は、前の**Table Filter**領域で使用されているものと同じです。変更フィードごとに最大10個のイベントフィルタールールを追加できます。 - **Event Filter**：以下のイベントフィルターを使用して、変更フィードから特定のイベントを除外できます。 - - **イベントを無視する**：指定されたイベントタイプを除外します。 - - **SQL を無視**: 指定された式に一致する DDL イベントを除外します。たとえば、 `^drop` `DROP`で始まるステートメントを除外し、 `add column`は`ADD COLUMN`を含むステートメントを除外します。 + - **Ignore event**：指定されたイベントタイプを除外します。 + - **Ignore SQL**: 指定された式に一致する DDL イベントを除外します。たとえば、 `^drop` `DROP`で始まるステートメントを除外し、 `add column`は`ADD COLUMN`を含むステートメントを除外します。 - **Ignore insert value expression**: 特定の条件を満たす`INSERT`ステートメントを除外します。たとえば、 `id >= 100`は、 `INSERT`が 100 以上である`id`ステートメントを除外します。 - **新しい値の更新式を無視する**: 新しい値が指定された条件に一致する`UPDATE`ステートメントを除外します。たとえば、 `gender = 'male'`は`gender`が`male`になるような更新を除外します。 - **古い値の更新を無視する式**: 古い値が指定された条件に一致する`UPDATE`ステートメントを除外します。たとえば、 `age < 18` `age`の古い値が 18 未満である場合の更新を除外します。 @@ -213,7 +213,7 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl - **Date Separator**：年、月、日に基づいてデータをローテーションするか、ローテーションしないかを選択します。 - **区切り文字**：CSVファイル内の値を区切る文字を指定します。最も一般的に使用される区切り文字はカンマ（ `,` ）です。 - **引用符**：区切り文字または特殊文字を含む値を囲むために使用する文字を指定します。通常、引用符には二重引用符（ `"` ）が使用されます。 - - **null/空値**：CSVファイル内でnull値または空値がどのように表現されるかを指定します。これは、データの適切な処理と解釈のために重要です。 + - **Null/Empty Values**：CSVファイル内でnull値または空値がどのように表現されるかを指定します。これは、データの適切な処理と解釈のために重要です。 - **Include Commit Ts**：CSV行に[`commit-ts`](https://docs.pingcap.com/tidb/stable/ticdc-sink-to-cloud-storage#replicate-change-data-to-storage-services)を含めるかどうかを制御します。
@@ -238,13 +238,13 @@ summary: このドキュメントでは、TiDB Cloudから Amazon S3、Google Cl > > これら2つのパラメータは、各データベーステーブルごとにクラウドストレージに生成されるオブジェクトの数に影響します。テーブル数が多い場合、同じ設定を使用すると生成されるオブジェクトの数が増加し、結果としてクラウドストレージAPIの呼び出しコストが上昇します。そのため、リカバリポイント目標（RPO）とコスト要件に基づいて、これらのパラメータを適切に設定することをお勧めします。 -6. **[イベントの分割]**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 +6. **Split Event**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 ## ステップ3．仕様の設定 {#step-3-configure-specification} **「次へ」**をクリックして、変更フィードの仕様を設定してください。 -1. **変更フィード仕様**領域で、変更フィードで使用するレプリケーション容量ユニット（RCU）の数を指定します。 +1. **Changefeed Specification**領域で、変更フィードで使用するレプリケーション容量ユニット（RCU）の数を指定します。 2. **Changefeed Name**欄に、変更フィードの名前を指定します。 ## ステップ4．構成を確認し、レプリケーションを開始する {#step-4-review-the-configuration-and-start-replication} diff --git a/tidb-cloud/changefeed-sink-to-mysql.md b/tidb-cloud/changefeed-sink-to-mysql.md index d2b88f97947c7..0bd035f67a238 100644 --- a/tidb-cloud/changefeed-sink-to-mysql.md +++ b/tidb-cloud/changefeed-sink-to-mysql.md @@ -158,8 +158,8 @@ TiDB Cloud PremiumインスタンスがMySQLサービスに接続できること - **Tables matching**：この列では、イベントフィルターを適用するテーブルを設定できます。ルールの構文は、前の**Table Filter**領域で使用されているものと同じです。変更フィードごとに最大10個のイベントフィルタールールを追加できます。 - **Event Filter**：以下のイベントフィルターを使用して、変更フィードから特定のイベントを除外できます。 - - **イベントを無視する**：指定されたイベントタイプを除外します。 - - **SQL を無視**: 指定された式に一致する DDL イベントを除外します。たとえば、 `^drop` `DROP`で始まるステートメントを除外し、 `add column`は`ADD COLUMN`を含むステートメントを除外します。 + - **Ignore event**：指定されたイベントタイプを除外します。 + - **Ignore SQL**: 指定された式に一致する DDL イベントを除外します。たとえば、 `^drop` `DROP`で始まるステートメントを除外し、 `add column`は`ADD COLUMN`を含むステートメントを除外します。 - **Ignore insert value expression**: 特定の条件を満たす`INSERT`ステートメントを除外します。たとえば、 `id >= 100`は、 `INSERT`が 100 以上である`id`ステートメントを除外します。 - **新しい値の更新式を無視する**: 新しい値が指定された条件に一致する`UPDATE`ステートメントを除外します。たとえば、 `gender = 'male'`は`gender`が`male`になるような更新を除外します。 - **古い値の更新を無視する式**: 古い値が指定された条件に一致する`UPDATE`ステートメントを除外します。たとえば、 `age < 18` `age`の古い値が 18 未満である場合の更新を除外します。 @@ -173,7 +173,7 @@ TiDB Cloud PremiumインスタンスがMySQLサービスに接続できること 9. **「次へ」**をクリックして、変更フィードの仕様を設定してください。 - - **「チェンジフィードの仕様」**領域で、チェンジフィードで使用する複製容量単位（RCU）チェンジフィードチェンジフィード容量ユニット（CCU）の数を指定します。 + - **Changefeed Specification**領域で、チェンジフィードで使用する複製容量単位（RCU）チェンジフィードチェンジフィード容量ユニット（CCU）の数を指定します。 - **Changefeed Name**欄に、変更フィードの名前を指定します。 10. **「次へ」**をクリックして、変更フィードの設定を確認してください。 diff --git a/tidb-cloud/changefeed-sink-to-tidb-cloud.md b/tidb-cloud/changefeed-sink-to-tidb-cloud.md index b23739b6fecd9..cbe289d896fbb 100644 --- a/tidb-cloud/changefeed-sink-to-tidb-cloud.md +++ b/tidb-cloud/changefeed-sink-to-tidb-cloud.md @@ -87,8 +87,8 @@ summary: このドキュメントでは、TiDB Cloud Dedicatedクラスタから - **Tables matching**：この列では、イベントフィルターを適用するテーブルを設定できます。ルールの構文は、前の**Table Filter**領域で使用されているものと同じです。変更フィードごとに最大10個のイベントフィルタールールを追加できます。 - **Event Filter**：以下のイベントフィルターを使用して、変更フィードから特定のイベントを除外できます。 - - **イベントを無視する**：指定されたイベントタイプを除外します。 - - **SQL を無視**: 指定された式に一致する DDL イベントを除外します。たとえば、 `^drop` `DROP`で始まるステートメントを除外し、 `add column`は`ADD COLUMN`を含むステートメントを除外します。 + - **Ignore event**：指定されたイベントタイプを除外します。 + - **Ignore SQL**: 指定された式に一致する DDL イベントを除外します。たとえば、 `^drop` `DROP`で始まるステートメントを除外し、 `add column`は`ADD COLUMN`を含むステートメントを除外します。 - **Ignore insert value expression**: 特定の条件を満たす`INSERT`ステートメントを除外します。たとえば、 `id >= 100`は、 `INSERT`が 100 以上である`id`ステートメントを除外します。 - **新しい値の更新式を無視する**: 新しい値が指定された条件に一致する`UPDATE`ステートメントを除外します。たとえば、 `gender = 'male'`は`gender`が`male`になるような更新を除外します。 - **古い値の更新を無視する式**: 古い値が指定された条件に一致する`UPDATE`ステートメントを除外します。たとえば、 `age < 18` `age`の古い値が 18 未満である場合の更新を除外します。 @@ -98,7 +98,7 @@ summary: このドキュメントでは、TiDB Cloud Dedicatedクラスタから 8. **「次へ」**をクリックして、変更フィードの仕様を設定してください。 - - **変更フィード仕様**領域で、変更フィードで使用するレプリケーション容量ユニット（RCU）の数を指定します。 + - **Changefeed Specification**領域で、変更フィードで使用するレプリケーション容量ユニット（RCU）の数を指定します。 - **Changefeed Name**欄に、変更フィードの名前を指定します。 9. **「次へ」**をクリックして、変更フィードの設定を確認してください。 diff --git a/tidb-cloud/configure-external-storage-access.md b/tidb-cloud/configure-external-storage-access.md index 1667ad995eac4..17ad5674ed08e 100644 --- a/tidb-cloud/configure-external-storage-access.md +++ b/tidb-cloud/configure-external-storage-access.md @@ -83,15 +83,15 @@ AWS CloudFormationでロールARNを作成する際に問題が発生した場 1. [AWS マネジメントコンソール](https://console.aws.amazon.com/)コンソールにサインインし、 [Amazon S3コンソール](https://console.aws.amazon.com/s3/)を開きます。 - 2. **バケット**一覧から対象バケットの名前を選択し、 **「ARNをコピー」**をクリックしてS3バケットのARNを取得します（例： `arn:aws:s3:::tidb-cloud-source-data` ）。後で使用するために、バケットのARNをメモしておいてください。 + 2. **バケット**一覧から対象バケットの名前を選択し、 **Copy ARN**をクリックしてS3バケットのARNを取得します（例： `arn:aws:s3:::tidb-cloud-source-data` ）。後で使用するために、バケットのARNをメモしておいてください。 ![Copy bucket ARN](/media/tidb-cloud/copy-bucket-arn.png) - 3. [IAMコンソール](https://console.aws.amazon.com/iam/)を開き、左側のナビゲーションペインで**「ポリシー」**をクリックし、 **「ポリシーの作成」を**クリックします。 + 3. [IAMコンソール](https://console.aws.amazon.com/iam/)を開き、左側のナビゲーションペインで**「ポリシー」**をクリックし、 **Create Policy**をクリックします。 ![Create a policy](/media/tidb-cloud/aws-create-policy.png) - 4. **ポリシー作成**ページで、 **「JSON」**タブをクリックします。 + 4. **Create policy**ページで、 **「JSON」**タブをクリックします。 5. ポリシーテキストフィールドで、必要に応じてポリシーを設定してください。以下は、 TiDB Cloud Starter、 Essential、またはPremiumインスタンスからデータをエクスポートしたり、これらのインスタンスにデータをインポートしたりする際に使用できる例です。 @@ -152,7 +152,7 @@ AWS CloudFormationでロールARNを作成する際に問題が発生した場 6. **「次へ」**をクリックしてください。 - 7. ポリシー名を設定し、ポリシーのタグを追加（任意）してから、 **「ポリシーの作成」を**クリックします。 + 7. ポリシー名を設定し、ポリシーのタグを追加（任意）してから、 **Create policy**をクリックします。 3. AWS マネジメントコンソールで、 TiDB Cloudのアクセスロールを作成し、ロール ARN を取得します。 @@ -168,7 +168,7 @@ AWS CloudFormationでロールARNを作成する際に問題が発生した場 3. **「次へ」**をクリックしてポリシー一覧を開き、先ほど作成したポリシーを選択してから**「次へ」**をクリックします。 - 4. **「役割の詳細」**で役割の名前を設定し、右下隅の**Create role**をクリックします。役割が作成されると、役割の一覧が表示されます。 + 4. **Role details**で役割の名前を設定し、右下隅の**Create role**をクリックします。役割が作成されると、役割の一覧が表示されます。 5. 役割の一覧から、先ほど作成した役割の名前をクリックして概要ページに移動すると、役割のARNを取得できます。 @@ -221,7 +221,7 @@ TiDB Cloud StarterまたはEssentialインスタンスがGCSバケットにア ![service-account](/media/tidb-cloud/serverless-external-storage/gcs-service-account.png) -2. サービスアカウントをクリックし、 `KEYS`ページで**[キーの追加]**をクリックして、サービスアカウントキーを作成します。 +2. サービスアカウントをクリックし、 `KEYS`ページで**ADD KEY**をクリックして、サービスアカウントキーを作成します。 ![service-account-key](/media/tidb-cloud/serverless-external-storage/gcs-service-account-key.png) @@ -276,7 +276,7 @@ Azure ARMテンプレートを使用してSASトークンを作成するには 1. **「ARM テンプレート展開による新しい SAS トークンの生成」**ダイアログで、[クリック**] をクリックして、事前構成済みの ARM テンプレートを含む Azure ポータルを開きます**。 - 2. Azureにログインすると、Azure**カスタムデプロイ**ページにリダイレクトされます。 + 2. Azureにログインすると、Azure**Custom deployment**ページにリダイレクトされます。 3. **Resource group**ページで、**リソースグループ**と**ストレージアカウント名**を入力してください。コンテナが配置されているストレージアカウントの概要ページから、すべての情報を取得できます。 @@ -298,11 +298,11 @@ Azure ARMテンプレートを使用してSASトークンを作成する際に 3. **Shared access signature**ページで、次のように必要なアクセス許可を持つサービス SAS トークンを作成します。詳細については、 [サービスSASトークンを作成します](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview)を参照してください。 - 1. **「許可されたサービス」**セクションで、 **「Blob」**サービスを選択します。 + 1. **Allowed services**セクションで、 **「Blob」**サービスを選択します。 2. **Allowed Resource types**セクションで、 **「コンテナ」**と**「オブジェクト」**を選択します。 - 3. **「許可された権限」**セクションで、必要に応じて権限を選択してください。 + 3. **Allowed permissions**セクションで、必要に応じて権限を選択してください。 - TiDB Cloud StarterまたはEssentialインスタンスからデータをエクスポートするには、**読み取り**権限と**書き込み**権限が必要です。 - TiDB Cloud StarterまたはEssentialインスタンスにデータをインポートするには、**読み取り**権限と**一覧表示**権限が必要です。 @@ -327,7 +327,7 @@ TiDB CloudがAlibaba Cloud OSSバケットにアクセスできるようにす 1. RAM ユーザーを作成し、AccessKey ペアを取得します。詳細については、 [RAMユーザーを作成する](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-ram-user)を参照してください。 - **アクセスモードの**セクションで、 **「永続的なアクセスキーを使用してアクセスする」を**選択します。 + **Access Mode**セクションで、 **「永続的なアクセスキーを使用してアクセスする」を**選択します。 2. 必要な権限を持つカスタム ポリシーを作成します。詳細については、 [カスタムポリシーを作成する](https://www.alibabacloud.com/help/en/ram/user-guide/create-a-custom-policy)を参照してください。 diff --git a/tidb-cloud/connected-slack-ticket-creation.md b/tidb-cloud/connected-slack-ticket-creation.md index f0784bbdc897d..450fb0a7f84ca 100644 --- a/tidb-cloud/connected-slack-ticket-creation.md +++ b/tidb-cloud/connected-slack-ticket-creation.md @@ -13,11 +13,11 @@ summary: Slack チケットの作成と更新サブスクリプションに関 ## サポートチケットを作成する {#create-a-support-ticket} -Slackのサポートチャンネルで、 **PingCAP Support Bot**をメンションし、メッセージで問題を説明してください。すると、チケットボットが**「リクエストを送信」**ボタン付きのメッセージを送信します。 +Slackのサポートチャンネルで、 **PingCAP Support Bot**をメンションし、メッセージで問題を説明してください。すると、チケットボットが**Raise request**ボタン付きのメッセージを送信します。 ![slack-ticket-creation-1](/media/tidb-cloud/connected-slack-ticket-creation-1.png) -**「リクエストを送信」**をクリックしてフォームを開き、問題に応じて入力し、 **「作成」**をクリックしてチケットを送信します。 +**Raise request**をクリックしてフォームを開き、問題に応じて入力し、 **「作成」**をクリックしてチケットを送信します。 ![slack-ticket-creation-2](/media/tidb-cloud/connected-slack-ticket-creation-2.png) diff --git a/tidb-cloud/connected-slack-ticket-interaction.md b/tidb-cloud/connected-slack-ticket-interaction.md index 3e5d52673f70a..9fb642c24258c 100644 --- a/tidb-cloud/connected-slack-ticket-interaction.md +++ b/tidb-cloud/connected-slack-ticket-interaction.md @@ -21,11 +21,11 @@ Slack でサポート チケットに直接返信することもできます。 ## サポートチケットでやり取りする {#interact-with-support-tickets} -Slackのサポートチャンネルで、 **PingCAP Support Bot**をメンションし、メッセージで問題を説明してください。すると、ボットから**「リクエストを送信」**ボタン付きのメッセージが送信されます。 +Slackのサポートチャンネルで、 **PingCAP Support Bot**をメンションし、メッセージで問題を説明してください。すると、ボットから**Raise request**ボタン付きのメッセージが送信されます。 ![slack-ticket-interaction-1](/media/tidb-cloud/connected-slack-ticket-interaction-1.png) -**「リクエストを送信」**をクリックしてフォームを開き、問題に応じて入力し、 **「作成」**をクリックしてチケットを送信します。 +**Raise request**をクリックしてフォームを開き、問題に応じて入力し、 **「作成」**をクリックしてチケットを送信します。 ![slack-ticket-interaction-2](/media/tidb-cloud/connected-slack-ticket-interaction-2.png) diff --git a/tidb-cloud/data-service-manage-github-connection.md b/tidb-cloud/data-service-manage-github-connection.md index c6ad2a2d2f622..ac5f3b5f2b20b 100644 --- a/tidb-cloud/data-service-manage-github-connection.md +++ b/tidb-cloud/data-service-manage-github-connection.md @@ -55,7 +55,7 @@ GitHub接続で**Auto Sync & Deployment**が有効になっている場合、Git - この機能を有効にすると、指定したGitHubディレクトリで行われた変更がTiDB Cloudに自動的にデプロイされ、 TiDB Cloudコンソールで行われた変更もGitHubにプッシュされます。関連するデプロイおよびコミット情報は、データアプリのデプロイ履歴で確認できます。 - この機能を無効にすると、指定したGitHubディレクトリで行われた変更はTiDB Cloudにデプロイさ**れず**、 TiDB Cloudコンソールで行われた変更もGitHubにプッシュされ**ません**。 -5. **「接続確認」**をクリックしてください。 +5. **Confirm Connect**をクリックしてください。 ## ステップ2. データアプリの設定をGitHubと同期する {#step-2-synchronize-data-app-configurations-with-github} @@ -160,7 +160,7 @@ TiDB Cloudコンソールでデータアプリのエンドポイント[データ - この機能を有効にすると、指定したGitHubディレクトリで行われた変更がTiDB Cloudに自動的にデプロイされ、 TiDB Cloudコンソールで行われた変更もGitHubにプッシュされます。関連するデプロイおよびコミット情報は、データアプリのデプロイ履歴で確認できます。 - この機能を無効にすると、指定したGitHubディレクトリで行われた変更はTiDB Cloudにデプロイさ**れず**、 TiDB Cloudコンソールで行われた変更もGitHubにプッシュされ**ません**。 -6. **「接続確認」**をクリックしてください。 +6. **Confirm Connect**をクリックしてください。 ## GitHub接続を削除 {#remove-github-connection} diff --git a/tidb-cloud/dedicated-external-storage.md b/tidb-cloud/dedicated-external-storage.md index eb5d7bfe2d017..26b70d0be2371 100644 --- a/tidb-cloud/dedicated-external-storage.md +++ b/tidb-cloud/dedicated-external-storage.md @@ -41,15 +41,15 @@ TiDB Cloudのバケットアクセスを設定し、以下の手順でロールA 1. AWS マネジメント コンソールにサインインし、 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/)で Amazon S3 コンソールを開きます。 - 2. **バケット**一覧から、ソースデータが入っているバケットの名前を選択し、 **「ARNをコピー」**をクリックしてS3バケットのARNを取得します（例： `arn:aws:s3:::tidb-cloud-source-data` ）。後で使用するために、バケットのARNをメモしておいてください。 + 2. **バケット**一覧から、ソースデータが入っているバケットの名前を選択し、 **Copy ARN**をクリックしてS3バケットのARNを取得します（例： `arn:aws:s3:::tidb-cloud-source-data` ）。後で使用するために、バケットのARNをメモしておいてください。 ![Copy bucket ARN](/media/tidb-cloud/copy-bucket-arn.png) - 3. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)でIAMコンソールを開き、左側のナビゲーション ペインで**[ポリシー]**をクリックし、 **[ポリシーの作成] を**クリックします。 + 3. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)でIAMコンソールを開き、左側のナビゲーション ペインで**[ポリシー]**をクリックし、 **Create Policy**をクリックします。 ![Create a policy](/media/tidb-cloud/aws-create-policy.png) - 4. **ポリシー作成**ページで、 **「JSON」**タブをクリックします。 + 4. **Create policy**ページで、 **「JSON」**タブをクリックします。 5. 以下のアクセス ポリシー テンプレートをコピーして、ポリシー テキスト フィールドに貼り付けてください。 @@ -107,7 +107,7 @@ TiDB Cloudのバケットアクセスを設定し、以下の手順でロールA 6. **「次へ」**をクリックしてください。 - 7. ポリシー名を設定し、ポリシーのタグを追加（任意）してから、 **「ポリシーの作成」を**クリックします。 + 7. ポリシー名を設定し、ポリシーのタグを追加（任意）してから、 **Create policy**をクリックします。 3. AWS マネジメントコンソールで、 TiDB Cloudのアクセスロールを作成し、ロール ARN を取得します。 @@ -123,7 +123,7 @@ TiDB Cloudのバケットアクセスを設定し、以下の手順でロールA 3. **「次へ」**をクリックしてポリシー一覧を開き、先ほど作成したポリシーを選択してから**「次へ」**をクリックします。 - 4. **「役割の詳細」**で役割の名前を設定し、右下隅の**Create role**をクリックします。役割が作成されると、役割の一覧が表示されます。 + 4. **Role details**で役割の名前を設定し、右下隅の**Create role**をクリックします。役割が作成されると、役割の一覧が表示されます。 5. 役割の一覧から、先ほど作成した役割の名前をクリックして概要ページに移動し、役割のARNをコピーします。 @@ -182,7 +182,7 @@ TiDB CloudがGCSバケット内のソースデータにアクセスできるよ 3. 役割の名前、説明、ID、および役割の起動ステージを入力してください。役割名は、作成後に変更することはできません。 - 4. **「権限を追加」を**クリックしてください。 + 4. **ADD PERMISSIONS**をクリックしてください。 5. ロールに以下の読み取り専用権限を追加し、 **[追加]**をクリックします。 @@ -196,13 +196,13 @@ TiDB CloudがGCSバケット内のソースデータにアクセスできるよ 3. [バケツ](https://console.cloud.google.com/storage/browser)ページに移動し、 TiDB CloudがアクセスするGCSバケットの名前をクリックします。 -4. **バケットの詳細**ページで、 **[権限]**タブをクリックし、 **[アクセス権の付与]**をクリックします。 +4. **Bucket details**ページで、 **[権限]**タブをクリックし、 **GRANT ACCESS**をクリックします。 ![Grant Access to the bucket ](/media/tidb-cloud/gcp-bucket-permissions.png) 5. バケットへのアクセス権を付与するには、以下の情報を入力し、 **「保存」**をクリックしてください。 - - **「新しいプリンシパル」**フィールドに、対象のTiDBクラスターのGoogle Cloud ServiceアカウントIDを貼り付けます。 + - **New Principals**フィールドに、対象のTiDBクラスターのGoogle Cloud ServiceアカウントIDを貼り付けます。 - **Select a role**ドロップダウンリストに、先ほど作成したIAMロールの名前を入力し、フィルター結果からその名前を選択します。 @@ -210,7 +210,7 @@ TiDB CloudがGCSバケット内のソースデータにアクセスできるよ > > TiDB Cloudへのアクセス権を削除するには、付与したアクセス権を削除するだけで済みます。 -6. **バケットの詳細**ページで、「**オブジェクト」**タブをクリックします。 +6. **Bucket details**ページで、「**オブジェクト」**タブをクリックします。 ファイルの gsutil URI をコピーするには、ファイルを選択し、 **[オブジェクトを開く] オーバーフロー メニュー**をクリックして、 **Copy gsutil URI**をクリックします。 @@ -236,9 +236,9 @@ TiDB Cloud DedicatedがAzure Blobコンテナにアクセスできるように 3. **Shared access signature**ページで、次のように必要な権限を持つ[アカウントSASトークン](https://docs.microsoft.com/en-us/azure/storage/common/storage-sas-overview)を作成します。 - 1. **「許可されたサービス」**で**「Blob」**を選択します。 + 1. **Allowed services**で**「Blob」**を選択します。 2. **Allowed resource types**で、 **「コンテナ」**と**「オブジェクト」**を選択します。 - 3. **「許可された権限」**で、必要な権限を選択します。たとえば、 TiDB Cloud Dedicatedにデータをインポートするには、 **「読み取り」**と**「一覧表示」の**権限が必要です。 + 3. **Allowed permissions**で、必要な権限を選択します。たとえば、 TiDB Cloud Dedicatedにデータをインポートするには、 **「読み取り」**と**「一覧表示」の**権限が必要です。 4. 必要に応じて**開始日時と有効期限日時**を調整してください。セキュリティ上の理由から、有効期限はデータインポートのスケジュールに合わせて設定することをお勧めします。 5. その他の設定については、デフォルト値を維持してください。 diff --git a/tidb-cloud/essential-changefeed-sink-to-kafka.md b/tidb-cloud/essential-changefeed-sink-to-kafka.md index 61f21f344e939..f12ab4c68648c 100644 --- a/tidb-cloud/essential-changefeed-sink-to-kafka.md +++ b/tidb-cloud/essential-changefeed-sink-to-kafka.md @@ -209,7 +209,7 @@ TiDB Cloud Essential の変更フィードが Apache Kafka にデータをスト - **Replication Factor**：各KafkaメッセージがレプリケートされるKafkaサーバーの数を制御します。有効な値の範囲は、 [`min.insync.replicas`](https://kafka.apache.org/33/documentation.html#brokerconfigs_min.insync.replicas)からKafkaブローカーの数までです。 - **Partition Number**：トピックに存在するパーティションの数を制御します。有効な値の範囲は`[1, 10 * the number of Kafka brokers]`です。 -10. **[イベントの分割]**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 +10. **Split Event**エリアで、 `UPDATE`イベントを別々の`DELETE`と`INSERT`イベントに分割するか、生の`UPDATE`イベントとして保持するかを選択します。詳細については、 [MySQL以外のシンクにおける、主キーまたは一意キーを分割したUPDATEイベント](https://docs.pingcap.com/tidb/stable/ticdc-split-update-behavior/#split-primary-or-unique-key-update-events-for-non-mysql-sinks)を参照してください。 11. **「次へ」**をクリックしてください。 diff --git a/tidb-cloud/integrate-tidbcloud-with-airbyte.md b/tidb-cloud/integrate-tidbcloud-with-airbyte.md index 09251eb0510a0..3f16f9f8e4697 100644 --- a/tidb-cloud/integrate-tidbcloud-with-airbyte.md +++ b/tidb-cloud/integrate-tidbcloud-with-airbyte.md @@ -56,7 +56,7 @@ airbyte-server | -------------------------------------- TiDB Cloudコンソールの接続ダイアログからパラメーター値を取得できます。ダイアログを開くには、[**My TiDB**](https://tidbcloud.com/tidbs)ページに移動し、ターゲットのTiDB Cloud StarterインスタンスTiDB Cloud EssentialインスタンスTiDB Cloud PremiumインスタンスTiDB Cloud Dedicatedクラスタークラスターの名前をクリックして概要ページに移動し、右上隅の**Connect**をクリックします。 -3. **SSL接続**を有効にし、 **JDBC URLパラメータ**でTLSプロトコルを**TLSv1.2**または**TLSv1.3**に設定します。 +3. **SSL Connection**を有効にし、 **JDBC URLパラメータ**でTLSプロトコルを**TLSv1.2**または**TLSv1.3**に設定します。 > **Note:** > @@ -84,11 +84,11 @@ TiDB コネクタの詳細については、 [TiDBソース](https://docs.airbyt 3. 接続**Set up**パネルに移動し、 `${source_name} - ${destination-name}`などの接続名を作成します。 -4. **レプリケーション頻度**を**Every 24 hours**に設定すると、接続は1日に1回データを複製します。 +4. **Replication frequency**を**Every 24 hours**に設定すると、接続は1日に1回データを複製します。 5. **Destination Namespace**を**Custom format**に設定し、**Namespace Custom Format**を**test**に設定して、すべてのデータを`test`データベースに保存します。 -6. **同期モード**を**Full refresh | Overwrite**に選択してください。 +6. **Sync mode**を**Full refresh | Overwrite**に選択してください。 > **Tip:** > @@ -103,7 +103,7 @@ TiDB コネクタの詳細については、 [TiDBソース](https://docs.airbyt 8. **Set up connection**をクリックしてください。 -9. 接続が確立されたら、 **「有効」**をクリックして同期タスクをアクティブ化します。また、 **「今すぐ同期」**をクリックすると、すぐに同期を開始できます。 +9. 接続が確立されたら、 **「有効」**をクリックして同期タスクをアクティブ化します。また、 **Sync now**をクリックすると、すぐに同期を開始できます。 ![Sync data](/media/tidb-cloud/integration-airbyte-sync.jpg) diff --git a/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md b/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md index 8994d6a2bc9f2..79a87fd83707e 100644 --- a/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md +++ b/tidb-cloud/integrate-tidbcloud-with-aws-lambda.md @@ -119,7 +119,7 @@ AWS CloudFormation を使用して書店プロジェクトを設定するには 1. **前提条件**の領域で、 **Choose an existing template**を選択します。 - 2. **テンプレート指定**領域で、 **Upload a template file**を選択し、 **[ファイルを選択]**をクリックしてテンプレート ファイル (YAML または JSON) をアップロードし、 **[次へ]**をクリックします。 + 2. **Specify template**領域で、 **Upload a template file**を選択し、 **Choose file**をクリックしてテンプレート ファイル (YAML または JSON) をアップロードし、 **[次へ]**をクリックします。 まだファイルをお持ちでない場合は、 [GitHub](https://github.com/pingcap/TiDB-Lambda-integration/releases/latest)からダウンロードしてください。このファイルには、プロジェクトに必要なリソースを作成するAWS CloudFormationテンプレートが含まれています。 @@ -131,7 +131,7 @@ AWS CloudFormation を使用して書店プロジェクトを設定するには ![Specify AWS Lambda stack details](/media/develop/aws-lambda-cf-stack-config.png) - - **スタック名**：スタック名を入力してください。 + - **Stack name**：スタック名を入力してください。 - **S3Bucket** ：zipファイルを保存しているS3バケットを入力してください。 - **S3Key** ：S3キーを入力してください。 - **TiDBDatabase** ： TiDB Cloud Starterインスタンス名を入力してください。 diff --git a/tidb-cloud/integrate-tidbcloud-with-n8n.md b/tidb-cloud/integrate-tidbcloud-with-n8n.md index ded9b0e0cef34..239a6a5658b6c 100644 --- a/tidb-cloud/integrate-tidbcloud-with-n8n.md +++ b/tidb-cloud/integrate-tidbcloud-with-n8n.md @@ -57,7 +57,7 @@ n8nを起動したら、 [localhost:5678](http://localhost:5678)にアクセス TiDB Cloudノードは、npmリポジトリでは`n8n-nodes-tidb-cloud`という名前です。n8nでTiDB Cloudを制御するには、このノードを手動でインストールする必要があります。 1. [localhost:5678](http://localhost:5678)ページで、n8nをセルフホスティングするためのオーナーアカウントを作成します。 -2. **設定**>**コミュニティノード**に移動してください。 +2. **設定**>**Community nodes**に移動してください。 3. **Install a community node**をクリックしてください。 4. **npm Package Name**フィールドに`n8n-nodes-tidb-cloud`と入力します。 5. **「インストール」**をクリックしてください。 @@ -84,7 +84,7 @@ TiDB Cloudノードは、npmリポジトリでは`n8n-nodes-tidb-cloud`という TiDB Cloud Starterインスタンスをお持ちでない場合は、このノードを使用してインスタンスを作成できます。そうでない場合は、この操作をスキップしても構いません。 -1. **ワークフロー**パネルに移動し、 **「ワークフローの追加」**をクリックします。 +1. **ワークフロー**パネルに移動し、 **Add workflow**をクリックします。 2. 新しいワークフローワークスペースで、右上隅の**「+」**をクリックし、 **「すべての**フィールド」を選択します。 3. `TiDB Cloud`を検索して、ワークスペースにドラッグします。 4. TiDB Cloudノードの認証情報（TiDB Cloud APIキー）を入力してください。 @@ -93,7 +93,7 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ 7. **Cluster Name**ボックスに、 TiDB Cloud Starterインスタンスの名前を入力します。 8. **リージョン**リストから地域を選択してください。 9. **パスワード**欄に、 TiDB Cloud Starterインスタンスへのログインに使用するパスワードを入力してください。 -10. ノードを実行するには、 **「ノードを実行」**をクリックしてください。 +10. ノードを実行するには、 **Execute Node**をクリックしてください。 > **Note:** > @@ -108,7 +108,7 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ 3. 手動トリガーノードをワークスペースにドラッグし、ノードをダブルクリックします。**パラメーター**ダイアログが表示されます。 4. ルールを以下のように設定してください。 - - **トリガー間隔**： `Days` + - **Trigger Interval**： `Days` - **Days Between Triggers**： `1` - **Trigger at Hour**： `8am` - **Trigger at Minute**: `0` @@ -141,7 +141,7 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ CREATE TABLE IF NOT EXISTS hacker_news_briefing (creator VARCHAR (200), title TEXT, link VARCHAR(200), pubdate VARCHAR(200), comments VARCHAR(200), content TEXT, guid VARCHAR (200), isodate VARCHAR(200)); ``` -11. テーブルを作成するには、 **「実行ノード」**をクリックしてください。 +11. テーブルを作成するには、 **Execute node**をクリックしてください。 #### Hacker NewsのRSSフィードを入手する {#get-the-hacker-news-rss} @@ -205,7 +205,7 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ 5. **操作**リストで、 `Send`を選択します。 6. **「宛先」**欄にメールアドレスを入力してください。 7. **件名**欄に`Hacker News Briefing`と入力します。 -8. **「メールの種類」**ボックスで、 `HTML`を選択します。 +8. **Email Type**ボックスで、 `HTML`を選択します。 9. **メッセージ**ボックスで、 `Expression`をクリックし、 `{{ $json["response"] }}`と入力します。 > **Note:** @@ -214,7 +214,7 @@ TiDB Cloud Starterインスタンスをお持ちでない場合は、このノ ## ステップ4：ワークフローを実行する {#step-4-run-your-workflow} -ワークフローを作成したら、 **「ワークフローの実行」**をクリックしてテスト実行できます。 +ワークフローを作成したら、 **Execute Workflow**をクリックしてテスト実行できます。 ワークフローが想定どおりに実行されれば、Hacker Newsの速報メールが届きます。これらのニュースコンテンツはTiDB Cloud Starterインスタンスにログとして記録されるため、紛失の心配はありません。 @@ -269,7 +269,7 @@ TiDB Cloudノードは[通常のノード](https://docs.n8n.io/workflows/nodes/# - **ユーザー**： TiDB Cloud Starterインスタンスのユーザー名。 - **データベース**：データベース名。 - **テーブル**：テーブル名。 `From list`モードを使用してテーブル名を選択するか、 `Name`モードを使用してテーブル名を手動で入力できます。 -- **削除キー**：データベース内のどの行を削除するかを決定するアイテムのプロパティ名。アイテムとは、あるノードから別のノードに送信されるデータのことです。ノードは、受信データの各アイテムに対してアクションを実行します。n8n のアイテムの詳細については、 [n8nドキュメント](https://docs.n8n.io/workflows/items/)を参照してください。 +- **Delete Key**：データベース内のどの行を削除するかを決定するアイテムのプロパティ名。アイテムとは、あるノードから別のノードに送信されるデータのことです。ノードは、受信データの各アイテムに対してアクションを実行します。n8n のアイテムの詳細については、 [n8nドキュメント](https://docs.n8n.io/workflows/items/)を参照してください。
@@ -295,7 +295,7 @@ TiDB Cloudノードは[通常のノード](https://docs.n8n.io/workflows/nodes/# - **ユーザー**： TiDB Cloud Starterインスタンスのユーザー名。 - **データベース**：データベース名。 - **テーブル**：テーブル名。 `From list`モードを使用してテーブル名を選択するか、 `Name`モードを使用してテーブル名を手動で入力できます。 -- **更新キー**：データベース内のどの行を更新するかを決定するアイテムのプロパティ名。アイテムとは、あるノードから別のノードに送信されるデータのことです。ノードは、受信データの各アイテムに対してアクションを実行します。n8n のアイテムの詳細については、 [n8nドキュメント](https://docs.n8n.io/workflows/items/)を参照してください。 +- **Update Key**: データベース内のどの行を更新するかを決定するアイテムのプロパティ名。アイテムとは、あるノードから別のノードに送信されるデータのことです。ノードは、受信データの各アイテムに対してアクションを実行します。n8n のアイテムの詳細については、 [n8nドキュメント](https://docs.n8n.io/workflows/items/)を参照してください。 - **列**：入力項目のプロパティをカンマで区切ったリスト。更新対象の行の列として使用されます。
diff --git a/tidb-cloud/integrate-tidbcloud-with-zapier.md b/tidb-cloud/integrate-tidbcloud-with-zapier.md index a7d958fc415ba..d0132d3abf5dc 100644 --- a/tidb-cloud/integrate-tidbcloud-with-zapier.md +++ b/tidb-cloud/integrate-tidbcloud-with-zapier.md @@ -51,7 +51,7 @@ Zapier で[TiDB Cloudアプリ](https://zapier.com/apps/tidb-cloud/integrations) 4. テストトリガー - **「トリガーをテスト」を**クリックします。トリガーが正常に設定されると、GitHubアカウントから新しいグローバルイベントのデータが表示されます。 **「続行」**をクリックします。 + **Test trigger**をクリックします。トリガーが正常に設定されると、GitHubアカウントから新しいグローバルイベントのデータが表示されます。 **「続行」**をクリックします。 ### ステップ3： `Find Table in TiDB Cloud`アクションを設定する {#step-3-set-up-the-find-table-in-tidb-cloud-action} @@ -89,7 +89,7 @@ Zapier で[TiDB Cloudアプリ](https://zapier.com/apps/tidb-cloud/integrations) 4. テストアクション - **「テスト」アクション**をクリックすると、Zapierがテーブルを作成します。テストをスキップすることも可能で、その場合はワークフローが初めて実行されるときにテーブルが作成されます。 + **Test action**をクリックすると、Zapierがテーブルを作成します。テストをスキップすることも可能で、その場合はワークフローが初めて実行されるときにテーブルが作成されます。 ### ステップ4： `Create Row in TiDB Cloud`設定する {#step-4-set-up-the-create-row-in-tidb-cloud-action} @@ -105,7 +105,7 @@ Zapier で[TiDB Cloudアプリ](https://zapier.com/apps/tidb-cloud/integrations) 3. アクションを設定する - 1. 前の手順と同様に、**Project Name**、**Cluster Name**、 **TiDBパスワード**、**Database Name**を入力してください。 + 1. 前の手順と同様に、**Project Name**、**Cluster Name**、 **TiDB Password**、**Database Name**を入力してください。 2. **Table Name**で、ドロップダウンリストから**github_global_event**テーブルを選択します。テーブルの列が表示されます。 @@ -117,7 +117,7 @@ Zapier で[TiDB Cloudアプリ](https://zapier.com/apps/tidb-cloud/integrations) 4. テストアクション - **「テスト」アクション**をクリックして、テーブルに新しい行を作成します。TiDB Cloud Starterインスタンスを確認すると、データが正常に書き込まれていることが確認できます。 + **Test action**をクリックして、テーブルに新しい行を作成します。TiDB Cloud Starterインスタンスを確認すると、データが正常に書き込まれていることが確認できます。 ```sql mysql> SELECT * FROM test.github_global_event; diff --git a/tidb-cloud/migrate-from-mysql-using-aws-dms.md b/tidb-cloud/migrate-from-mysql-using-aws-dms.md index 69113121489a3..12f6e70f84d06 100644 --- a/tidb-cloud/migrate-from-mysql-using-aws-dms.md +++ b/tidb-cloud/migrate-from-mysql-using-aws-dms.md @@ -42,8 +42,8 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ 3. インスタンス名、ARN、および説明を入力してください。 4. インスタンス構成を入力してください。 - - **インスタンスクラス**：適切なインスタンスクラスを選択してください。パフォーマンスを向上させるには、 `dms.t3.large`またはそれより高いインスタンスクラスを使用することをお勧めします。 - - **エンジンバージョン**：デフォルト設定を使用します。 + - **Instance class**：適切なインスタンスクラスを選択してください。パフォーマンスを向上させるには、 `dms.t3.large`またはそれより高いインスタンスクラスを使用することをお勧めします。 + - **Engine version**：デフォルト設定を使用します。 - **マルチAZ** ：ビジネスニーズに応じて、**シングルAZ**または**マルチAZ**を選択してください。 5. ストレージは**Allocated storage (GiB)**フィールドで設定します。デフォルト設定を使用してください。 @@ -52,7 +52,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ - **Network type - new**: **IPv4**を選択してください。 - **IPv4 用仮想プライベートクラウド (VPC)** ：必要な VPC を選択してください。ネットワーク構成を簡素化するため、アップストリームデータベースと同じ VPC を使用することをお勧めします。 - **Replication subnet group**：レプリケーションインスタンスに使用するサブネットグループを選択してください。 - - **一般公開**：デフォルト設定を使用します。 + - **Public accessible**：デフォルト設定を使用します。 7. 必要に応じて、**Advanced settings**、**メンテナンス**、および**タグ**を設定します。 **Create replication instance**をクリックして、インスタンスの作成を完了します。 @@ -76,9 +76,9 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ 5. 以下の情報を設定してください。 - - **エンドポイント識別子**：後続のタスク構成で識別しやすくするために、ソースエンドポイントにラベルを作成します。 + - **Endpoint identifier**：後続のタスク構成で識別しやすくするために、ソースエンドポイントにラベルを作成します。 - **記述的な Amazon リソース名 (ARN) - オプション**: デフォルトの DMS ARN に分かりやすい名前を作成します。 - - **ソースエンジン**: **MySQL**を選択してください。 + - **Source engine**: **MySQL**を選択してください。 - **Access to endpoint database**:**Provide access information manually**を選択します。 - **Server name**：データプロバイダーのデータサーバー名を入力してください。データベースコンソールからコピーできます。アップストリームがAmazon RDSまたはAmazon Auroraの場合は、名前が自動的に入力されます。ドメイン名のないセルフホスト型MySQLの場合は、IPアドレスを入力してください。 - ソースデータベースの**ポート番号**、**ユーザー名**、**パスワード**を入力してください。 @@ -86,7 +86,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ ![Fill in the endpoint configurations](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-endpoint-config.png) -6. **エンドポイント設定**、 **KMS key**、**タグに**はデフォルト値を使用してください。**Test endpoint connection (optional)**セクションでは、ネットワーク構成を簡素化するために、ソースデータベースと同じVPCを選択することをお勧めします。対応するレプリケーションインスタンスを選択し、 **「テストの実行」**をクリックします。ステータスが**「成功」**である必要があります。 +6. **Endpoint settings**、 **KMS key**、**タグに**はデフォルト値を使用してください。**Test endpoint connection (optional)**セクションでは、ネットワーク構成を簡素化するために、ソースデータベースと同じVPCを選択することをお勧めします。対応するレプリケーションインスタンスを選択し、 **Run test**をクリックします。ステータスが**「成功」**である必要があります。 7. **Create endpoint**をクリックします。 @@ -100,7 +100,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ 2. TiDB Cloudコンソールで、[**My 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 アドレスを入力して、 **Update Filter**をクリックします。AWS DMS レプリケーション インスタンスのパブリック IP アドレスとプライベート IP アドレスを TiDB クラスタのトラフィック フィルタに同時に追加することをお勧めします。そうしないと、状況によっては AWS DMS が TiDB クラスタに接続できない場合があります。 4. **Download CA cert**をクリックします。ダイアログの**[ステップ3：SQLクライアントで接続する**]で、接続文字列内の`-u` 、 `-h` 、および`-P`情報を後で使用するためにメモしておきます。 @@ -111,9 +111,9 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ 7. TiDBクラスタのターゲットエンドポイントを設定します。 - **Endpoint type**：**Target endpoint**を選択してください。 - - **エンドポイント識別子**：エンドポイントの名前を入力してください。 + - **Endpoint identifier**：エンドポイントの名前を入力してください。 - **記述的な Amazon リソース名 (ARN) - オプション**: デフォルトの DMS ARN に分かりやすい名前を作成します。 - - **対象エンジン**: **MySQL**を選択してください。 + - **Target engine**: **MySQL**を選択してください。 ![Configure the target endpoint](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-target-endpoint.png) @@ -132,7 +132,7 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ ![Upload CA](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-upload-ca.png) -10. **エンドポイント設定**、 **KMS key**、**タグに**はデフォルト値を使用します。**Test endpoint connection (optional)**セクションで、ソースデータベースと同じVPCを選択します。対応するレプリケーションインスタンスを選択し、 **「テストの実行」**をクリックします。ステータスが**「成功」**である必要があります。 +10. **Endpoint settings**、 **KMS key**、**タグに**はデフォルト値を使用します。**Test endpoint connection (optional)**セクションで、ソースデータベースと同じVPCを選択します。対応するレプリケーションインスタンスを選択し、 **Run test**をクリックします。ステータスが**「成功」**である必要があります。 11. **Create endpoint**をクリックします。 @@ -140,15 +140,15 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ ## ステップ4. データベース移行タスクを作成する {#step-4-create-a-database-migration-task} -1. AWS DMS コンソールで、 [データ移行タスク](https://console.aws.amazon.com/dms/v2/home#tasks)ページに移動します。お住まいの地域に切り替えてください。次に、ウィンドウの右上隅にある**「タスクの作成」を**クリックします。 +1. AWS DMS コンソールで、 [データ移行タスク](https://console.aws.amazon.com/dms/v2/home#tasks)ページに移動します。お住まいの地域に切り替えてください。次に、ウィンドウの右上隅にある**Create task**をクリックします。 ![Create task](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-create-task.png) 2. 以下の情報を設定してください。 - - **タスク識別子**：タスクの名前を入力してください。覚えやすい名前を使用することをお勧めします。 + - **Task identifier**: タスクの名前を入力してください。覚えやすい名前を使用することをお勧めします。 - **記述的な Amazon リソース名 (ARN) - オプション**: デフォルトの DMS ARN に分かりやすい名前を作成します。 - - **レプリケーションインスタンス**：先ほど作成したAWS DMSインスタンスを選択します。 + - **Replication instance**：先ほど作成したAWS DMSインスタンスを選択します。 - **Source database endpoint**：先ほど作成したソースデータベースエンドポイントを選択してください。 - **Target database endpoint**：先ほど作成したターゲットデータベースエンドポイントを選択してください。 - **Migration type**：必要に応じて移行タイプを選択してください。この例では、 **「既存データの移行と進行中の変更の複製」**を選択します。 @@ -157,24 +157,24 @@ AWS DMSは、リレーショナルデータベース、データウェアハウ 3. 以下の情報を設定してください。 - - **編集モード**：**ウィザード**を選択してください。 + - **Editing mode**：**ウィザード**を選択してください。 - **ソーストランザクションのカスタムCDC停止モード**：デフォルト設定を使用します。 - **Target table preparation mode**：必要に応じて**Do nothing**またはその他のオプションを選択してください。この例では、 **Do nothing**を選択します。 - **フルロード完了後にタスクを停止する**：デフォルト設定を使用する。 - **LOB列をレプリケーションに含める**：**Limited LOB mode**を選択します。 - **LOBの最大サイズ（KB）** ：デフォルト値の**32**を使用します。 - **Turn on validation**：必要に応じて選択してください。 - - **タスクログ**：今後のトラブルシューティングのために、 **Turn on CloudWatch logs**を選択してください。関連する設定については、デフォルト設定を使用してください。 + - **Task logs**: 今後のトラブルシューティングのために、 **Turn on CloudWatch logs**を選択してください。関連する設定については、デフォルト設定を使用してください。 ![Task settings](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-task-settings.png) -4. **テーブルマッピングの**セクションで、移行するデータベースを指定します。 +4. **Table mappings**のセクションで、移行するデータベースを指定します。 - スキーマ名は、Amazon RDS インスタンス内のデータベース名です。**ソース名**のデフォルト値は「%」で、これは Amazon RDS 内のすべてのデータベースが TiDB に移行されることを意味します。これにより、Amazon RDS 内の`mysql`や`sys`などのシステム データベースが TiDB クラスターに移行され、タスクが失敗します。そのため、特定のデータベース名を入力するか、すべてのシステム データベースを除外することをお勧めします。たとえば、次のスクリーンショットの設定に従って、 `franktest`という名前のデータベースと、そのデータベース内のすべてのテーブルのみが移行されます。 + スキーマ名は、Amazon RDS インスタンス内のデータベース名です。**Source name**のデフォルト値は「%」で、これは Amazon RDS 内のすべてのデータベースが TiDB に移行されることを意味します。これにより、Amazon RDS 内の`mysql`や`sys`などのシステム データベースが TiDB クラスターに移行され、タスクが失敗します。そのため、特定のデータベース名を入力するか、すべてのシステム データベースを除外することをお勧めします。たとえば、次のスクリーンショットの設定に従って、 `franktest`という名前のデータベースと、そのデータベース内のすべてのテーブルのみが移行されます。 ![Table mappings](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-to-tidb-cloud-table-mappings.png) -5. 右下隅の**「タスクの作成」**をクリックしてください。 +5. 右下隅の**Create task**をクリックしてください。 6. [データ移行タスク](https://console.aws.amazon.com/dms/v2/home#tasks)ページに戻ります。お住まいの地域に切り替えてください。タスクのステータスと進捗状況を確認できます。 diff --git a/tidb-cloud/migrate-from-mysql-using-data-migration.md b/tidb-cloud/migrate-from-mysql-using-data-migration.md index 153dd4f916535..c1b3143cdca3c 100644 --- a/tidb-cloud/migrate-from-mysql-using-data-migration.md +++ b/tidb-cloud/migrate-from-mysql-using-data-migration.md @@ -242,7 +242,7 @@ SHOW VARIABLES WHERE Variable_name IN
AWS RDSまたはAurora MySQLの設定 -1. AWS マネジメント コンソールで、 [Amazon RDS コンソール](https://console.aws.amazon.com/rds/)を開き、左側のナビゲーション ペインで**[パラメータ グループ]**をクリックし、カスタム パラメータ グループを作成または編集します。 +1. AWS マネジメント コンソールで、 [Amazon RDS コンソール](https://console.aws.amazon.com/rds/)を開き、左側のナビゲーション ペインで**Parameter groups**をクリックし、カスタム パラメータ グループを作成または編集します。 2. 上記の4つのパラメータを必要な値に設定してください。 3. パラメータグループをインスタンスまたはクラスターにアタッチし、再起動して変更を適用してください。 4. 再起動後、インスタンスに接続し、 `SHOW VARIABLES`ステートメントを実行して構成を確認します。 @@ -253,7 +253,7 @@ SHOW VARIABLES WHERE Variable_name IN
Azure Database for MySQL の構成 - Flexible Server -1. [Azureポータル](https://portal.azure.com/)で、 **Azure Database for MySQL サーバー**を検索して選択し、インスタンス名をクリックしてから、左側のナビゲーション ペインで**[設定]** > **[サーバー パラメーター]**をクリックします。 +1. [Azureポータル](https://portal.azure.com/)で、 **Azure Database for MySQL サーバー**を検索して選択し、インスタンス名をクリックしてから、左側のナビゲーション ペインで**[設定]** > **Server parameters**をクリックします。 2. 各パラメータを検索し、その値を更新します。 @@ -284,7 +284,7 @@ SHOW VARIABLES WHERE Variable_name IN - `binlog_row_image` : `FULL` -3. 左側のナビゲーション ペインで、 **Backup and Restoration**をクリックし、 **[バックアップ戦略]**を選択します。移行中に DM が連続するbinlogファイルにアクセスできるようにするには、バックアップ戦略を次の制約で構成します。 +3. 左側のナビゲーション ペインで、 **Backup and Restoration**をクリックし、 **Backup Strategy**を選択します。移行中に DM が連続するbinlogファイルにアクセスできるようにするには、バックアップ戦略を次の制約で構成します。 - 保存期間：最低3日間（推奨7日間）に設定してください。 @@ -396,10 +396,10 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ - **スキーム**:**内部**。ロードバランサーはVPC内に留まります。次のステップのエンドポイントサービスのみが、ロードバランサーをTiDB Cloudに公開します。 - **VPC** ：RDSまたはAuroraインスタンスと同じVPCを指定します。フォームはデフォルトでアカウントのデフォルトVPCを選択しますが、データベースが配置されている場所は通常このVPCではないため、続行する前に**VPC**のドロップダウンリストを変更してください。 - **Availability Zones**：**少なくとも2つのアベイラビリティゾーン**でサブネットを選択してください。NLBでは、エンドポイントサービスの可用性を確保するためにマルチAZ構成が必要です。RDSがシングルAZ構成の場合でも、同じVPC内の別のAZに2つ目のサブネットが必要になります。 - - **リスナーポート**： `3306` 。ウィザードのデフォルト値は`80`です。リスナーを作成する前に変更してください。 - - **対象グループ**：対象タイプは**IP addresses**、プロトコルは**TCP** 、ポートは**3306** 、データベースと同じVPC内。RDSエンドポイントを直接登録することはできないため、代わりにデータベースのプライベートIPアドレスを登録してください。 + - **Listener port**： `3306` 。ウィザードのデフォルト値は`80`です。リスナーを作成する前に変更してください。 + - **Target group**：対象タイプは**IP addresses**、プロトコルは**TCP** 、ポートは**3306** 、データベースと同じVPC内。RDSエンドポイントを直接登録することはできないため、代わりにデータベースのプライベートIPアドレスを登録してください。 - [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)でデータベースのプライベート IP アドレスを見つけるには、 左側のナビゲーション ペインで**「ネットワーク インターフェイス」**をクリックし、 **「説明**= `RDSNetworkInterface`と**「VPC** = ご使用の VPC」でフィルタリングします。一致するネットワーク インターフェイスに表示されている**Primary private IPv4 address**を使用します。 + [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)でデータベースのプライベート IP アドレスを見つけるには、 左側のナビゲーション ペインで**Network Interfaces**をクリックし、 **「説明**= `RDSNetworkInterface`と**「VPC** = ご使用の VPC」でフィルタリングします。一致するネットワーク インターフェイスに表示されている**Primary private IPv4 address**を使用します。 > **Note:** > @@ -407,17 +407,17 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ 詳細な手順については、AWS ドキュメントの[ネットワークロードバランサーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)を参照してください。 -2. [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)で、左側のナビゲーションペインの**[エンドポイント サービス]**をクリックし、 **Create endpoint service**をクリックします。次の設定を構成します。 +2. [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)で、左側のナビゲーションペインの**Endpoint Services**をクリックし、 **Create endpoint service**をクリックします。次の設定を構成します。 - **Load balancer type**を**Network**に設定し、前の手順で作成したNLBを選択します。**Available load balancers**リストが空の場合は、NLBが**アクティブ**状態になるまで待ってから、リストの横にある更新アイコンをクリックします。 - - **承認が必要**：有効（デフォルト）。 + - **Acceptance required**：有効（デフォルト）。 - **Supported IP address types**： **IPv4**を選択してください。 エンドポイントサービスが作成されたら、後で使用するためにサービス名をコピーしてください。サービス名は`com.amazonaws.vpce..vpce-svc-`の形式です。たとえば、 `com.amazonaws.vpce.us-east-1.vpce-svc-0123456789abcdef0`ようになります。 詳細な手順については、AWS ドキュメントの[エンドポイントサービスを作成します](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html)を参照してください。 -3. TiDB CloudのAWSプリンシパルがエンドポイントサービスを使用できるように承認します。Amazon [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)のエンドポイントサービスの詳細ページで、 **[プリンシパルの許可]**タブを開き、 **[プリンシパルの許可]**をクリックして、次のARNを追加します。 +3. TiDB CloudのAWSプリンシパルがエンドポイントサービスを使用できるように承認します。Amazon [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)のエンドポイントサービスの詳細ページで、 **Allow principals**タブを開き、 **Allow principals**をクリックして、次のARNを追加します。 ```text arn:aws:iam::886436925895:root @@ -482,10 +482,10 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ - **スキーム**:**内部**。ロードバランサーはVPC内に留まります。次のステップのエンドポイントサービスのみが、ロードバランサーをTiDB Cloudに公開します。 - **VPC** ：RDSまたはAuroraインスタンスと同じVPCを指定します。フォームはデフォルトでアカウントのデフォルトVPCを選択しますが、データベースが配置されている場所は通常このVPCではないため、続行する前に**VPC**のドロップダウンリストを変更してください。 - **Availability Zones**：**少なくとも2つのアベイラビリティゾーン**でサブネットを選択してください。NLBでは、エンドポイントサービスの可用性を確保するためにマルチAZ構成が必要です。RDSがシングルAZ構成の場合でも、同じVPC内の別のAZに2つ目のサブネットが必要になります。 - - **リスナーポート**： `3306` 。ウィザードのデフォルト値は`80`です。リスナーを作成する前に変更してください。 - - **対象グループ**：対象タイプは**IP addresses**、プロトコルは**TCP** 、ポートは**3306** 、データベースと同じVPC内。RDSエンドポイントを直接登録することはできないため、代わりにデータベースのプライベートIPアドレスを登録してください。 + - **Listener port**： `3306` 。ウィザードのデフォルト値は`80`です。リスナーを作成する前に変更してください。 + - **Target group**：対象タイプは**IP addresses**、プロトコルは**TCP** 、ポートは**3306** 、データベースと同じVPC内。RDSエンドポイントを直接登録することはできないため、代わりにデータベースのプライベートIPアドレスを登録してください。 - [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)でデータベースのプライベート IP アドレスを見つけるには、 左側のナビゲーション ペインで**「ネットワーク インターフェイス」**をクリックし、 **「説明**= `RDSNetworkInterface`と**「VPC** = ご使用の VPC」でフィルタリングします。一致するネットワーク インターフェイスに表示されている**Primary private IPv4 address**を使用します。 + [Amazon EC2 コンソール](https://console.aws.amazon.com/ec2/)でデータベースのプライベート IP アドレスを見つけるには、 左側のナビゲーション ペインで**Network Interfaces**をクリックし、 **「説明**= `RDSNetworkInterface`と**「VPC** = ご使用の VPC」でフィルタリングします。一致するネットワーク インターフェイスに表示されている**Primary private IPv4 address**を使用します。 > **Note:** > @@ -493,17 +493,17 @@ AWS は RDS またはAuroraへの PrivateLink による直接アクセスをサ 詳細な手順については、AWS ドキュメントの[ネットワークロードバランサーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)を参照してください。 -2. [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)で、左側のナビゲーションペインの**[エンドポイント サービス]**をクリックし、 **Create endpoint service**をクリックします。次の設定を構成します。 +2. [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)で、左側のナビゲーションペインの**Endpoint Services**をクリックし、 **Create endpoint service**をクリックします。次の設定を構成します。 - **Load balancer type**を**Network**に設定し、前の手順で作成したNLBを選択します。**Available load balancers**リストが空の場合は、NLBが**アクティブ**状態になるまで待ってから、リストの横にある更新アイコンをクリックします。 - - **承認が必要**：有効（デフォルト）。 + - **Acceptance required**：有効（デフォルト）。 - **Supported IP address types**： **IPv4**を選択してください。 エンドポイントサービスが作成されたら、後で使用するためにサービス名をコピーしてください。サービス名は`com.amazonaws.vpce..vpce-svc-`の形式です。たとえば、 `com.amazonaws.vpce.us-east-1.vpce-svc-0123456789abcdef0`ようになります。 詳細な手順については、AWS ドキュメントの[エンドポイントサービスを作成します](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html)を参照してください。 -3. TiDB CloudのAWSプリンシパルがエンドポイントサービスを使用できるように承認します。Amazon [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)のエンドポイントサービスの詳細ページで、 **[プリンシパルの許可]**タブを開き、 **[プリンシパルの許可]**をクリックして、次のARNを追加します。 +3. TiDB CloudのAWSプリンシパルがエンドポイントサービスを使用できるように承認します。Amazon [Amazon VPC コンソール](https://console.aws.amazon.com/vpc/)のエンドポイントサービスの詳細ページで、 **Allow principals**タブを開き、 **Allow principals**をクリックして、次のARNを追加します。 ```text arn:aws:iam::886436925895:root @@ -769,9 +769,9 @@ GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX, CREATE VIEW ON - - 接続方法として**Public IP**または**VPC Peering**使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 + - 接続方法として**Public IP**または**VPC Peering**を使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - 接続方法として**Private Link**を使用する場合、エンドポイント要求を承認するよう求められます。 - - AWSの場合： [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **[エンドポイントサービス]**をクリックし、 TiDB Cloudからのエンドポイントリクエストを承認します。 + - AWSの場合： [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**をクリックし、 TiDB Cloudからのエンドポイントリクエストを承認します。 - Azure の場合: [Azureポータル](https://portal.azure.com)に移動し、MySQL Flexible Server を名前で検索し、左側のナビゲーション ペインで**[設定]** > **[ネットワーク]**をクリックし、右側の**Private endpoint**セクションを見つけて、 TiDB Cloudからの保留中の接続要求を承認します。 @@ -783,7 +783,7 @@ GRANT CREATE, SELECT, INSERT, UPDATE, DELETE, ALTER, DROP, INDEX, CREATE VIEW ON - 接続方法として**パブリックを**使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)でエンドポイントサービスを作成したAWSリージョンに切り替え、 **[エンドポイントサービス]**を選択し、 TiDB Cloudからのエンドポイント接続要求を承認してください。 + - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)でエンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**を選択し、 TiDB Cloudからのエンドポイント接続要求を承認してください。 diff --git a/tidb-cloud/migrate-from-oracle-using-aws-dms.md b/tidb-cloud/migrate-from-oracle-using-aws-dms.md index a9d4561dd4ada..3318026cdd407 100644 --- a/tidb-cloud/migrate-from-oracle-using-aws-dms.md +++ b/tidb-cloud/migrate-from-oracle-using-aws-dms.md @@ -125,11 +125,11 @@ AWS Schema Conversion Tool を使用してスキーマを移行する場合は ## ステップ8. データベース移行タスクを作成する {#step-8-create-a-database-migration-task} -1. AWS DMS コンソールで、 [データ移行タスク](https://console.aws.amazon.com/dms/v2/home#tasks)ページに移動します。お住まいの地域に切り替えてください。次に、ウィンドウの右上隅にある**「タスクの作成」を**クリックします。 +1. AWS DMS コンソールで、 [データ移行タスク](https://console.aws.amazon.com/dms/v2/home#tasks)ページに移動します。お住まいの地域に切り替えてください。次に、ウィンドウの右上隅にある**Create task**をクリックします。 ![Create task](/media/tidb-cloud/aws-dms-to-tidb-cloud-create-task.png) -2. データベース移行タスクを作成し、**選択ルール**を指定します。 +2. データベース移行タスクを作成し、**Selection rules**を指定します。 ![Create AWS DMS migration task](/media/tidb-cloud/aws-dms-from-oracle-to-tidb-11.png) @@ -137,7 +137,7 @@ AWS Schema Conversion Tool を使用してスキーマを移行する場合は 3. タスクを作成し、開始し、タスクが完了するまで待ちます。 -4. **テーブル統計**をクリックしてテーブルを確認してください。スキーマ名は`ADMIN`です。 +4. **Table statistics**をクリックしてテーブルを確認してください。スキーマ名は`ADMIN`です。 ![Check AWS DMS migration task](/media/tidb-cloud/aws-dms-from-oracle-to-tidb-13.png) 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 9c7430d14fcf7..1578a10032dfb 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 @@ -211,7 +211,7 @@ SHOW VARIABLES LIKE 'binlog_row_image'; - パブリックIPまたはVPCピアリングを使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - AWS Private Link を使用している場合、エンドポイント要求を承認するよう求められます。AWS [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成した AWS リージョンに切り替え、 **[エンドポイントサービス]**をクリックしてエンドポイント要求を承認してください。 + - AWS Private Link を使用している場合、エンドポイント要求を承認するよう求められます。AWS [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成した AWS リージョンに切り替え、 **Endpoint services**をクリックしてエンドポイント要求を承認してください。 @@ -223,7 +223,7 @@ SHOW VARIABLES LIKE 'binlog_row_image'; - 接続方法として**パブリックを**使用する場合は、データ移行サービスのIPアドレスを、ソースデータベースおよびファイアウォール（存在する場合）のIPアクセスリストに追加する必要があります。 - - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **[エンドポイントサービス]**をクリックして、 TiDB Cloudからのエンドポイント接続要求を承認してください。 + - **Private Link**を使用しており、選択したプライベートエンドポイントがAWSでまだ承認されていない場合は、 [AWS VPCコンソール](https://console.aws.amazon.com/vpc/home)で、エンドポイントサービスを作成したAWSリージョンに切り替え、 **Endpoint services**をクリックして、 TiDB Cloudからのエンドポイント接続要求を承認してください。 diff --git a/tidb-cloud/monitor-alert-slack.md b/tidb-cloud/monitor-alert-slack.md index 75487ccaebb9a..00c15ae3c0b70 100644 --- a/tidb-cloud/monitor-alert-slack.md +++ b/tidb-cloud/monitor-alert-slack.md @@ -31,9 +31,9 @@ TiDB Cloud、Slack、[メール](/tidb-cloud/monitor-alert-email.md)、[Zoom](/t ### ステップ1：SlackウェブフックURLを生成する {#step-1-generate-a-slack-webhook-url} -1. まだお持ちでない場合は、 [Slackアプリを作成する](https://api.slack.com/apps/new)。 **Create New App**をクリックし、 **[最初から]**を選択します。名前を入力し、アプリを関連付けるワークスペースを選択して、 **[アプリの作成] を**クリックします。 +1. まだお持ちでない場合は、 [Slackアプリを作成する](https://api.slack.com/apps/new)。 **Create New App**をクリックし、 **From scratch**を選択します。名前を入力し、アプリを関連付けるワークスペースを選択して、 **Create App**をクリックします。 2. アプリの設定ページに移動します。[アプリの管理ダッシュボード](https://api.slack.com/apps)から設定をロードできます。 -3. **「受信Webhook」**タブをクリックし、 **Activate Incoming Webhooks**を**オン**に切り替えます。 +3. **Incoming Webhooks**タブをクリックし、 **Activate Incoming Webhooks**を**オン**に切り替えます。 4. **「ワークスペースに新しいWebhookを追加」**をクリックします。 5. アラート通知を受信するチャネルを選択し、 **「承認」**を選択してください。受信Webhookをプライベートチャネルに追加する必要がある場合は、まずそのチャネルに参加している必要があります。 diff --git a/tidb-cloud/monitor-alert-zoom.md b/tidb-cloud/monitor-alert-zoom.md index e9f58e6acdc3e..1c4fcff6a3335 100644 --- a/tidb-cloud/monitor-alert-zoom.md +++ b/tidb-cloud/monitor-alert-zoom.md @@ -41,9 +41,9 @@ TiDB Cloud は、Zoom、[Slack](/tidb-cloud/monitor-alert-slack.md)、[メール 1. Zoomデスクトップクライアントにサインインしてください。 -2. **チームチャット**タブをクリックしてください。 +2. **Team Chat**タブをクリックしてください。 -3. **「アプリ」**の下にある**「受信Webhook」**を見つけて選択するか、上記からメッセージを受信したいチャットチャネルを選択してください。 +3. **「アプリ」**の下にある**Incoming Webhook**を見つけて選択するか、上記からメッセージを受信したいチャットチャネルを選択してください。 4. 新しい接続を作成するには、次のコマンドを入力してください。 `${connectionName}`部分を、接続したい名前（例： `tidbcloud-alerts`に置き換えてください。 diff --git a/tidb-cloud/monitor-datadog-integration.md b/tidb-cloud/monitor-datadog-integration.md index f576fbe73fb41..b591bc251774b 100644 --- a/tidb-cloud/monitor-datadog-integration.md +++ b/tidb-cloud/monitor-datadog-integration.md @@ -89,14 +89,14 @@ TiDB Cloudは、2022年3月4日よりプロジェクトレベルのDatadog統合 > **Note:** > -> Datadog にTiDB Cloud統合をすでにインストールしている場合は、このセクションの次の手順をスキップできます。 [**TiDB Cloud Dynamic Tracker**](https://app.datadoghq.com/dash/integration/32021/tidb-cloud-dynamic-tracker)または[**TiDB Cloud Cluster Overview**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview)ダッシュボードは、Datadog [**ダッシュボード一覧**](https://app.datadoghq.com/dashboard/lists)で自動的に利用可能になります。 +> Datadog にTiDB Cloud統合をすでにインストールしている場合は、このセクションの次の手順をスキップできます。 [**TiDB Cloud Dynamic Tracker**](https://app.datadoghq.com/dash/integration/32021/tidb-cloud-dynamic-tracker)または[**TiDB Cloud Cluster Overview**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview)ダッシュボードは、Datadog [**Dashboard List**](https://app.datadoghq.com/dashboard/lists)で自動的に利用可能になります。 1. [Datadog](https://app.datadoghq.com)にログインします。 2. Datadog の[**TiDB Cloud統合**ページ](https://app.datadoghq.com/account/settings#integrations/tidb-cloud)に移動します。 -3. **「コンフィグレーション」**タブで、 **「統合のインストール」を**クリックします。 +3. **「コンフィグレーション」**タブで、 **Install Integration**をクリックします。 - - クラスターレベルの Datadog 統合の場合、 [**TiDB Cloud Dynamic Tracker**](https://app.datadoghq.com/dash/integration/32021/tidb-cloud-dynamic-tracker)ダッシュボードが[**ダッシュボード一覧**](https://app.datadoghq.com/dashboard/lists)に表示されます。 - - 従来のプロジェクト レベルの Datadog 統合 (ベータ版) の場合、 [**TiDB Cloud Cluster Overview**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview)ダッシュボードが[**ダッシュボード一覧**](https://app.datadoghq.com/dashboard/lists)に表示されます。 + - クラスターレベルの Datadog 統合の場合、 [**TiDB Cloud Dynamic Tracker**](https://app.datadoghq.com/dash/integration/32021/tidb-cloud-dynamic-tracker)ダッシュボードが[**Dashboard List**](https://app.datadoghq.com/dashboard/lists)に表示されます。 + - 従来のプロジェクト レベルの Datadog 統合 (ベータ版) の場合、 [**TiDB Cloud Cluster Overview**](https://app.datadoghq.com/dash/integration/30586/tidbcloud-cluster-overview)ダッシュボードが[**Dashboard List**](https://app.datadoghq.com/dashboard/lists)に表示されます。 ## 事前に構築されたダッシュボードを確認する {#view-the-pre-built-dashboard} diff --git a/tidb-cloud/monitor-new-relic-integration.md b/tidb-cloud/monitor-new-relic-integration.md index 7b2bb84fe33c2..8d016a1f3eb14 100644 --- a/tidb-cloud/monitor-new-relic-integration.md +++ b/tidb-cloud/monitor-new-relic-integration.md @@ -123,7 +123,7 @@ TiDB Cloudは、2023年4月11日よりプロジェクトレベルのNew Relic統
1. [New Relic](https://one.newrelic.com/)にログインします。 -2. **「データの追加」**をクリックし、 `TiDB Cloud`を検索して、 **TiDB Cloud Monitoring**ページに移動します。または、 [リンク](https://one.newrelic.com/marketplace?state=79bf274b-0c01-7960-c85c-3046ca96568e)クリックして直接ページにアクセスすることもできます。 +2. **Add Data**をクリックし、 `TiDB Cloud`を検索して、 **TiDB Cloud Monitoring**ページに移動します。または、 [リンク](https://one.newrelic.com/marketplace?state=79bf274b-0c01-7960-c85c-3046ca96568e)クリックして直接ページにアクセスすることもできます。 3. アカウントIDを選択し、New Relicでダッシュボードを作成してください。
diff --git a/tidb-cloud/premium/connect-to-premium-via-alibaba-cloud-private-endpoint.md b/tidb-cloud/premium/connect-to-premium-via-alibaba-cloud-private-endpoint.md index 23fb71907bc07..fbc351df830c4 100644 --- a/tidb-cloud/premium/connect-to-premium-via-alibaba-cloud-private-endpoint.md +++ b/tidb-cloud/premium/connect-to-premium-via-alibaba-cloud-private-endpoint.md @@ -33,7 +33,7 @@ Alibaba Cloud管理コンソールを使用してVPCインターフェースエ 1. [Alibaba Cloud管理コンソール](https://account.alibabacloud.com/login/login.htm)にサインインします。 2. **VPC** >**エンドポイント**に移動します。 -3. **「インターフェースエンドポイント」**タブをクリックし、 **Create Endpoint**をクリックします。 +3. **Interface Endpoints**タブをクリックし、 **Create Endpoint**をクリックします。 4. エンドポイントの詳細を入力してください。 - **リージョン**： TiDB Cloud Premiumインスタンスと同じリージョンを選択してください。 - **Endpoint Name**：エンドポイントの名前を入力してください。 diff --git a/tidb-cloud/premium/tidb-cloud-auditing-premium.md b/tidb-cloud/premium/tidb-cloud-auditing-premium.md index 4d346d6e565da..b92a5c31c8dc1 100644 --- a/tidb-cloud/premium/tidb-cloud-auditing-premium.md +++ b/tidb-cloud/premium/tidb-cloud-auditing-premium.md @@ -57,10 +57,10 @@ TiDB Cloudが監査ログを書き込む宛先として、組織が所有するA 4. **データベース監査ログストレージコンフィグレーション**ダイアログで、 **AWS IAM Policy Settings**セクションを探し、後で使用するために**TiDB Cloud Account ID**と**TiDB Cloud External ID**を記録してください。 -2. AWS マネジメント コンソールで、 **[IAM]** > **[アクセス管理]** > **[ポリシー]**に移動し、 `s3:PutObject`書き込み専用権限を持つストレージバケット ポリシーが存在するかどうかを確認します。 +2. AWS マネジメント コンソールで、 **IAM** > **Access Management** > **Policies**に移動し、 `s3:PutObject`書き込み専用権限を持つストレージバケット ポリシーが存在するかどうかを確認します。 - はいの場合、後で使用するために、一致したストレージバケットポリシーを記録してください。 - - そうでない場合は、 **IAM** >**アクセス管理**>**ポリシー**>**ポリシーの作成**に移動し、次のポリシー テンプレートに従ってバケット ポリシーを定義します。 + - そうでない場合は、 **IAM** > **Access Management** > **Policies** > **Create Policy**に移動し、次のポリシー テンプレートに従ってバケット ポリシーを定義します。 ```json { @@ -75,16 +75,16 @@ TiDB Cloudが監査ログを書き込む宛先として、組織が所有するA } ``` - テンプレートでは、 ``は監査ログファイルが書き込まれる S3 バケットの Amazon リソース ネーム (ARN) です。S3 バケットの**[プロパティ]**タブに移動し、 **[バケットの概要]**領域で ARN の値を取得できます。 `"Resource"`フィールドでは、ARN の後に`/*`を追加する必要があります。たとえば、ARN が`arn:aws:s3:::tidb-cloud-test`の場合、 `"Resource"`フィールドの値を`"arn:aws:s3:::tidb-cloud-test/*"`に設定する必要があります。 + テンプレートでは、 ``は監査ログファイルが書き込まれる S3 バケットの Amazon リソース ネーム (ARN) です。S3 バケットの**[プロパティ]**タブに移動し、 **Bucket Overview**領域で ARN の値を取得できます。 `"Resource"`フィールドでは、ARN の後に`/*`を追加する必要があります。たとえば、ARN が`arn:aws:s3:::tidb-cloud-test`の場合、 `"Resource"`フィールドの値を`"arn:aws:s3:::tidb-cloud-test/*"`に設定する必要があります。 -3. **IAM** >**アクセス管理**>**ロール**に移動し、以前に記録したTiDB Cloudアカウント ID と外部 ID に対応する信頼エンティティを持つロールが既に存在するかどうかを確認します。 +3. **IAM** > **Access Management** > **Roles**に移動し、以前に記録したTiDB Cloudアカウント ID と外部 ID に対応する信頼エンティティを持つロールが既に存在するかどうかを確認します。 - はいの場合、後で使用するために一致した役割を記録してください。 - そうでない場合は、 **Create role**をクリックし、信頼エンティティタイプとして**Another AWS account**を選択してから、 **Account ID**フィールドにTiDB CloudアカウントIDの値を入力します。次に、 **Require External ID**オプションを選択し、**External ID**フィールドにTiDB Cloud外部IDの値を入力します。 -4. **IAM** >**アクセス管理**>**ロール**で、前の手順で確認したロール名をクリックして**概要**ページに移動し、以下の手順を実行します。 +4. **IAM** > **Access Management** > **Roles**で、前の手順で確認したロール名をクリックして**概要**ページに移動し、以下の手順を実行します。 - 1. **「アクセス許可」**タブで、 `s3:PutObject`書き込み専用アクセス許可を持つ記録済みポリシーがロールに添付されているかどうかを確認します。添付されていない場合は、 **「ポリシーの添付」**を選択し、必要なポリシーを検索して、 **「ポリシーの添付」**をクリックします。 + 1. **「アクセス許可」**タブで、 `s3:PutObject`書き込み専用アクセス許可を持つ記録済みポリシーがロールに添付されているかどうかを確認します。添付されていない場合は、 **Attach Policies**を選択し、必要なポリシーを検索して、 **Attach Policy**をクリックします。 2. **概要**ページに戻り、**Role ARN**値をクリップボードにコピーしてください。 #### ステップ3．監査ログを有効にする {#step-3-enable-audit-logging} @@ -141,7 +141,7 @@ TiDB Cloudが監査ログを書き込む宛先として、組織が所有するA - はいの場合、後で使用するためにポリシー名を記録してください。 - - そうでない場合は、 **「ポリシーの作成」**をクリックし、以下のポリシーテンプレートを使用してポリシーを定義してください。 + - そうでない場合は、 **Create Policy**をクリックし、以下のポリシーテンプレートを使用してポリシーを定義してください。 ```json { @@ -160,7 +160,7 @@ TiDB Cloudが監査ログを書き込む宛先として、組織が所有するA `` TiDB Cloud が監査ログを書き込む OSS バケットの名前に置き換えてください。たとえば、バケット名が`auditlog-bucket`の場合は、 `"Resource": "acs:oss:*:*:auditlog-bucket/*"`を使用します。 -3. Alibaba Cloudコンソールで、 **[RAM]** > **[ID]** > **[ロール]**に移動し、**信頼済みエンティティ**が以前に記録したTiDB CloudアカウントIDと外部IDに一致するロールが既に存在するかどうかを確認します。 +3. Alibaba Cloudコンソールで、 **[RAM]** > **[ID]** > **[ロール]**に移動し、**trusted entity**が以前に記録したTiDB CloudアカウントIDと外部IDに一致するロールが既に存在するかどうかを確認します。 - はいの場合、後で使用するために役割名を記録してください。 @@ -169,20 +169,20 @@ TiDB Cloudが監査ログを書き込む宛先として、組織が所有するA 1. 役割作成ページで、 **[ポリシーエディターに切り替える]**をクリックします。 2. **「プリンシパル」**で**Cloud Account**を選択し、フィールドに**TiDB Cloud Account Id**を入力します。 3. **「アクション」**の下にあるドロップダウンリストから**「sts:AssumeRole」**を選択します。 - 4. **「条件を追加」**をクリックし、次のように条件を設定します。 + 4. **Add condition**をクリックし、次のように条件を設定します。 - **キーを**`sts:ExternalId`に設定します。 - **演算子を**`StringEquals`に設定します。 - **TiDB Cloud外部ID**に**値**を設定します。 5. **「OK」**をクリックして**Create Role**ダイアログを開きます。 6. **Role Name**フィールドに役割名を入力し、 **「OK」**をクリックして役割を作成します。 -4. 役割が作成されたら、 **[権限]**タブに移動して、 **[権限を付与]**をクリックします。 +4. 役割が作成されたら、 **[権限]**タブに移動して、 **Grant Permission**をクリックします。 ダイアログで、以下の設定を構成してください。 - - **リソース範囲**については、 **「アカウント」**を選択してください。 + - **Resource Scope**については、 **「アカウント」**を選択してください。 - **「ポリシー」**フィールドで、以前に作成したOSS書き込みポリシーを選択します。 - - **「権限を付与する」**をクリックしてください。 + - **Grant Permissions**をクリックしてください。 5. 後で使用するために、**Role ARN** (例: `acs:ram:::role/tidb-cloud-audit-role` ) をコピーしてください。 @@ -284,7 +284,7 @@ TiDB Cloudの監査ログは、インスタンスID、内部ID、およびログ ## 監査ログを無効にする {#disable-audit-logging} -インスタンスの監査を停止したい場合は、インスタンスのページに移動し、 **[設定]** > **[監査設定]**をクリックして、右上隅の監査設定を**[無効]**に切り替えます。 +インスタンスの監査を停止したい場合は、インスタンスのページに移動し、 **[設定]** > **Audit Settings**をクリックして、右上隅の監査設定を**[無効]**に切り替えます。 > **Note:** > 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 74eceb80e9837..6bb10688170ee 100644 --- a/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md +++ b/tidb-cloud/serverless-private-link-connection-to-alicloud-rds.md @@ -64,13 +64,13 @@ Alibaba Cloud コンソールでロードバランサーとエンドポイント - **Network Type**: `Internal-facing`を選択 - **VPC** : ApsaraDB RDS for MySQL が配置されている VPC を選択します。 - **ゾーン**: TiDB Cloud Essential クラスタと重複する必要があります - - **IPバージョン**: `IPv4`を選択 + - **IP Version**: `IPv4`を選択 -4. 作成したロードバランサーを見つけて、 **「リスナーの作成」**をクリックします。以下の情報を入力します。 +4. 作成したロードバランサーを見つけて、 **Create Listener**をクリックします。以下の情報を入力します。 - - **リスナープロトコル**: `TCP`を選択 - - **リスナーポート**: データベースポートを入力します。例: MySQLの場合は`3306` - - **サーバーグループ**: 前の手順で作成したサーバーグループを選択します + - **Listener Protocol**: `TCP`を選択 + - **Listener Port**: データベースポートを入力します。例: MySQLの場合は`3306` + - **Server Group**: 前の手順で作成したサーバーグループを選択します ### ステップ2.2. エンドポイントサービスを設定する {#step-2-2-set-up-an-endpoint-service} @@ -84,7 +84,7 @@ ApsaraDB RDS for MySQL と同じリージョンにエンドポイント サー 2. エンドポイントサービスの詳細ページに移動し、**Endpoint Service Name**（例： `com.aliyuncs.privatelink..xxxxx` ）をコピーします。これは後でTiDB Cloudで使用する必要があります。 -3. エンドポイントサービスの詳細ページで、「**サービスホワイトリスト」**タブをクリックし、 **Add to Whitelist**をクリックして、 [前提条件](#prerequisites)で取得したAlibaba CloudアカウントIDを入力します。 +3. エンドポイントサービスの詳細ページで、**Service Whitelist**タブをクリックし、 **Add to Whitelist**をクリックして、 [前提条件](#prerequisites)で取得したAlibaba CloudアカウントIDを入力します。 ## ステップ3. TiDB Cloudでプライベートリンク接続を作成する {#step-3-create-a-private-link-connection-in-tidb-cloud} 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 ef46d2a4f50f3..6316939e132e5 100644 --- a/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md +++ b/tidb-cloud/serverless-private-link-connection-to-amazon-msk.md @@ -26,13 +26,13 @@ AWS アカウント ID とアベイラビリティーゾーンを表示するに - **リージョンと AZ** : Amazon MSK プロビジョニングされたクラスターは、 TiDB Cloud Essentialクラスターと同じ AWS リージョンにあり、MSK クラスターのアベイラビリティーゾーンはTiDB Cloudクラスターと同じです。 - MSK クラスターには**認証**: [SASL/SCRAM認証](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password.html)が必要です。 -- **ブローカータイプ**: ブローカー`t4.small`タイプは使用しないでください。プライベートリンクをサポートしていません。 +- **Broker type**: ブローカー`t4.small`タイプは使用しないでください。プライベートリンクをサポートしていません。 詳細な要件については、 [単一リージョンでの Amazon MSK マルチ VPC プライベート接続](https://docs.aws.amazon.com/msk/latest/developerguide/aws-access-mult-vpc.html#mvpc-requirements)を参照してください。 Amazon MSK プロビジョニングされたクラスターがない場合は、 TiDB Cloud Essentialクラスターと同じリージョンおよび同じアベイラビリティーゾーンに[1つ作成する](https://docs.aws.amazon.com/msk/latest/developerguide/create-cluster.html) 、作成されたクラスターに[SASL/SCRAM認証を設定する](https://docs.aws.amazon.com/msk/latest/developerguide/msk-password-tutorial.html) 。 -- **シークレット名**: シークレット名は`AmazonMSK_`で始まる必要があります。 +- **Secret name**: シークレット名は`AmazonMSK_`で始まる必要があります。 - **暗号化**：デフォルトの暗号化キーは使用しないでください。シークレット用に新しいカスタムAWS KMSキーを作成してください。 ## ステップ1. TiDB Cloudアクセス用にKafka ACLを設定する {#step-1-set-up-kafka-acls-for-tidb-cloud-access} 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 f82872f1e853b..44779e2cc698f 100644 --- a/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md +++ b/tidb-cloud/serverless-private-link-connection-to-aws-confluent.md @@ -39,8 +39,8 @@ Confluent Cloud ネットワークは次の要件を満たしている必要が Confluent Cloud ネットワークの一意の名前を取得するには、次の手順を実行します。 1. [Confluent クラウド コンソール](https://confluent.cloud/)で[**環境**](https://confluent.cloud/environments)ページに移動し、Confluent Cloud ネットワークが配置されている環境をクリックします。 -2. **[ネットワーク管理]**をクリックし、 **For dedicated clusters**を選択して、作成したネットワークを見つけます。 -3. Confluent Cloud ネットワークの DNS サブドメインを取得するには、**ネットワークの概要**ページに移動します。 +2. **Network management**をクリックし、 **For dedicated clusters**を選択して、作成したネットワークを見つけます。 +3. Confluent Cloud ネットワークの DNS サブドメインを取得するには、**Network overview**ページに移動します。 4. DNSサブドメインからConfluent Cloudネットワークの一意の名前を抽出します。例えば、DNSサブドメインが`use1-az1.domnprzqrog.us-east-1.aws.confluent.cloud`の場合、一意の名前は`domnprzqrog.us-east-1`です。 5. 後で使用するために一意の名前を保存します。 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 5ffb4d88b71cb..291fc87b07a41 100644 --- a/tidb-cloud/serverless-private-link-connection-to-aws-rds.md +++ b/tidb-cloud/serverless-private-link-connection-to-aws-rds.md @@ -59,11 +59,11 @@ AWSコンソールでロードバランサーとAWSエンドポイントサー 1. [対象グループ](https://console.aws.amazon.com/ec2/home#CreateTargetGroup)に移動して、対象グループを作成します。次の情報を入力してください。 - - **対象タイプ**: `IP addresses`を選択してください。 + - **Target type**: `IP addresses`を選択してください。 - **Protocol and Port**: プロトコルを`TCP`に、ポートをデータベースのポートに設定します。たとえば、MySQL の場合は`3306`です。 - **IP address type**： `IPv4`を選択してください。 - **VPC** ：RDSが配置されているVPCを選択してください。 - - **ターゲットの登録**：Amazon RDSインスタンスのIPアドレスを登録します。RDSエンドポイントにpingを実行すると、IPアドレスを取得できます。 + - **Register targets**：Amazon RDSインスタンスのIPアドレスを登録します。RDSエンドポイントにpingを実行すると、IPアドレスを取得できます。 詳細については、 [ネットワークロードバランサーのターゲットグループを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-target-group.html)を参照してください。 @@ -77,7 +77,7 @@ AWSコンソールでロードバランサーとAWSエンドポイントサー - **Availability Zones**： TiDB Cloud Essentialインスタンスと重複するアベイラビリティゾーンを選択してください。 - - **セキュリティグループ**：以下のルールで新しいセキュリティグループを作成します。 + - **Security groups**：以下のルールで新しいセキュリティグループを作成します。 - MySQL/ Auroraを許可する受信ルール： - タイプ: `MySQL/Aurora` - ソース: `Anywhere-IPv4` @@ -88,7 +88,7 @@ AWSコンソールでロードバランサーとAWSエンドポイントサー - **Listeners and routing**： - **Protocol and Port**：プロトコルを`TCP`に、ポートをデータベースのポート番号に設定します。例えば、MySQLの場合は`3306`です。 - - **対象グループ**：前の手順で作成した対象グループを選択してください。 + - **Target group**: 前の手順で作成した対象グループを選択してください。 詳細については、 [ネットワークロードバランサーを作成する](https://docs.aws.amazon.com/elasticloadbalancing/latest/network/create-network-load-balancer.html)を参照してください。 @@ -106,7 +106,7 @@ AWSコンソールでロードバランサーとAWSエンドポイントサー 2. エンドポイントサービスの詳細ページに移動し、 `com.amazonaws.vpce..vpce-svc-xxxxxxxxxxxxxxxxx`の形式でエンドポイントサービス名をコピーしてください。この名前をTiDB Cloudに提供する必要があります。 -3. エンドポイントサービスの詳細ページで、 **[プリンシパルを許可]**タブをクリックし、[前提条件](#prerequisites)で取得したAWSアカウントIDを許可リストに追加します。例えば、 `arn:aws:iam:::root`のように追加します。 +3. エンドポイントサービスの詳細ページで、 **Allow principals**タブをクリックし、[前提条件](#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/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 4792c3afe1ffa..c2f5d92014303 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 @@ -76,7 +76,7 @@ Kafka VPC を作成するには、次の手順を実行します。 1. [Alibaba Cloud コンソール > VPC ダッシュボード](https://vpc.console.alibabacloud.com/vpc)に進み、Kafka をデプロイするリージョンに切り替えます。 -2. **Create VPC**をクリックします。VPC**設定**ページで以下の情報を入力します。 +2. **Create VPC**をクリックします。**VPC settings**ページで以下の情報を入力します。 1. **名前**を入力します (例: `Kafka VPC` )。 @@ -118,7 +118,7 @@ Kafka VPC を作成するには、次の手順を実行します。 - **インスタンスとイメージ**: `ecs.t5-lc1m2.small`インスタンスタイプと`Alibaba Cloud Linux`イメージ - **Key pair**:再利用`kafka-vpc-key-pair` 。 - **Instance Name**: `broker-node1` - - **Security Group**: Kafka VPCからのすべてのTCPを許可する新しいセキュリティグループを作成します。本番環境では、安全性を考慮してルールを絞り込むことができます。インバウンドルール: -**プロトコル**: `TCP` -**ポート範囲**: `All` -**ソース**: `10.0.0.0/16` + - **Security Group**: Kafka VPCからのすべてのTCPを許可する新しいセキュリティグループを作成します。本番環境では、安全性を考慮してルールを絞り込むことができます。インバウンドルール: -**プロトコル**: `TCP` -**Port range**: `All` -**ソース**: `10.0.0.0/16` - vSwitch `broker-ap-southeast-1b`のブローカー 2 @@ -126,7 +126,7 @@ Kafka VPC を作成するには、次の手順を実行します。 - **インスタンスとイメージ**: `ecs.t5-lc1m2.small`インスタンスタイプと`Alibaba Cloud Linux`イメージ - **Key pair**:再利用`kafka-vpc-key-pair` 。 - **Instance Name**: `broker-node2` - - **Security Group**: Kafka VPCからのすべてのTCPを許可する新しいセキュリティグループを作成します。本番環境では、安全性を考慮してルールを絞り込むことができます。インバウンドルール: -**プロトコル**: `TCP` -**ポート範囲**: `All` -**ソース**: `10.0.0.0/16` + - **Security Group**: Kafka VPCからのすべてのTCPを許可する新しいセキュリティグループを作成します。本番環境では、安全性を考慮してルールを絞り込むことができます。インバウンドルール: -**プロトコル**: `TCP` -**Port range**: `All` -**ソース**: `10.0.0.0/16` - vSwitch `broker-ap-southeast-1c`のブローカー 3 @@ -134,7 +134,7 @@ Kafka VPC を作成するには、次の手順を実行します。 - **インスタンスとイメージ**: `ecs.t5-lc1m2.small`インスタンスタイプと`Alibaba Cloud Linux`イメージ - **Key pair**:再利用`kafka-vpc-key-pair` 。 - **Instance Name**: `broker-node3` - - **Security Group**: Kafka VPCからのすべてのTCPを許可する新しいセキュリティグループを作成します。本番環境では、安全性を考慮してルールを絞り込むことができます。インバウンドルール: -**プロトコル**: `TCP` -**ポート範囲**: `All` -**ソース**: `10.0.0.0/16` + - **Security Group**: Kafka VPCからのすべてのTCPを許可する新しいセキュリティグループを作成します。本番環境では、安全性を考慮してルールを絞り込むことができます。インバウンドルール: -**プロトコル**: `TCP` -**Port range**: `All` -**ソース**: `10.0.0.0/16` **2.3. Kafkaランタイムバイナリの準備** @@ -201,8 +201,8 @@ Kafka VPC を作成するには、次の手順を実行します。 3. 計画値は次のとおりです。 - - **コントローラーポート**: `29092` - - **内部ポート**： `9092` + - **CONTROLLER port**: `29092` + - **INTERNAL port**： `9092` - **外部**: `39092` - **外部アドバタイズリスナーポート範囲**: `9093~9095` @@ -555,7 +555,7 @@ b3.ap-southeast-1c.unique_name.alicloud.plc.tidbcloud.com:9095 (id: 3 rack: null - **Server Group Name**: `bootstrap-server-group` - **VPC** : `Kafka VPC` - **Backend Server Protocol**: `TCP`を選択 - - **バックエンドサーバー**: 作成したサーバーグループをクリックし、 `broker-node1:39092` `broker-node3:39092`含むバックエンドサーバーを追加します`broker-node2:39092` + - **Backend servers**: 作成したサーバーグループをクリックし、 `broker-node1:39092` `broker-node3:39092`含むバックエンドサーバーを追加します`broker-node2:39092` - ブローカーサーバーグループ1 @@ -563,7 +563,7 @@ b3.ap-southeast-1c.unique_name.alicloud.plc.tidbcloud.com:9095 (id: 3 rack: null - **Server Group Name**: `broker-server-group-1` - **VPC** : `Kafka VPC` - **Backend Server Protocol**: `TCP`を選択 - - **バックエンドサーバー**: 作成したサーバーグループをクリックし、バックエンドサーバー`broker-node1:39092`を追加します。 + - **Backend servers**: 作成したサーバーグループをクリックし、バックエンドサーバー`broker-node1:39092`を追加します。 - ブローカーサーバーグループ2 @@ -571,7 +571,7 @@ b3.ap-southeast-1c.unique_name.alicloud.plc.tidbcloud.com:9095 (id: 3 rack: null - **Server Group Name**: `broker-server-group-2` - **VPC** : `Kafka VPC` - **Backend Server Protocol**: `TCP`を選択 - - **バックエンドサーバー**: 作成したサーバーグループをクリックし、バックエンドサーバー`broker-node2:39092`を追加します。 + - **Backend servers**: 作成したサーバーグループをクリックし、バックエンドサーバー`broker-node2:39092`を追加します。 - ブローカーサーバーグループ3 @@ -579,7 +579,7 @@ b3.ap-southeast-1c.unique_name.alicloud.plc.tidbcloud.com:9095 (id: 3 rack: null - **Server Group Name**: `broker-server-group-3` - **VPC** : `Kafka VPC` - **Backend Server Protocol**: `TCP`を選択 - - **バックエンドサーバー**: 作成したサーバーグループをクリックし、バックエンドサーバー`broker-node3:39092`を追加します。 + - **Backend servers**: 作成したサーバーグループをクリックし、バックエンドサーバー`broker-node3:39092`を追加します。 2. [NLB](https://slb.console.alibabacloud.com/nlb)に進み、ネットワーク ロード バランサーを作成します。 @@ -589,35 +589,35 @@ b3.ap-southeast-1c.unique_name.alicloud.plc.tidbcloud.com:9095 (id: 3 rack: null - `ap-southeast-1a`と`broker-ap-southeast-1a vswitch` - `ap-southeast-1b`と`broker-ap-southeast-1b vswitch` - `ap-southeast-1c`と`broker-ap-southeast-1c vswitch` - - **IPバージョン**: `IPv4`を選択 + - **IP Version**: `IPv4`を選択 - **Instance Name**: `kafka-nlb` - - **「今すぐ作成」**をクリックしてロードバランサーを作成します。 + - **Create Now**をクリックしてロードバランサーを作成します。 -3. 作成したロード バランサーを見つけて、 **[リスナーの作成]**をクリックして 4 つの TCP リスナーを作成します。 +3. 作成したロード バランサーを見つけて、 **Create Listener**をクリックして 4 つの TCP リスナーを作成します。 - ブートストラップサーバーグループ - **リスナープロトコル**: `TCP`を選択 - - **リスナーポート**: `9092` - - **サーバー グループ**: 以前に作成したサーバーグループ`bootstrap-server-group`を選択します。 + - **Listener Port**: `9092` + - **Server Group**: 以前に作成したサーバーグループ`bootstrap-server-group`を選択します。 - ブローカーサーバーグループ1 - **リスナープロトコル**: `TCP`を選択 - **リスナーポート**: `9093` - - **サーバー グループ**: 以前に作成したサーバーグループ`broker-server-group-1`を選択します。 + - **Server Group**: 以前に作成したサーバーグループ`broker-server-group-1`を選択します。 - ブローカーサーバーグループ2 - **リスナープロトコル**: `TCP`を選択 - **リスナーポート**: `9094` - - **サーバー グループ**: 以前に作成したサーバーグループ`broker-server-group-2`を選択します。 + - **Server Group**: 以前に作成したサーバーグループ`broker-server-group-2`を選択します。 - ブローカーサーバーグループ3 - **リスナープロトコル**: `TCP`を選択 - **リスナーポート**: `9095` - - **サーバー グループ**: 以前に作成したサーバーグループ`broker-server-group-3`を選択します。 + - **Server Group**: 以前に作成したサーバーグループ`broker-server-group-3`を選択します。 4. 要塞ノードでロードバランサーをテストします。この例では、Kafka ブートストラップのみをテストします。ロードバランサーは Kafka EXTERNAL リスナーをリッスンしているため、EXTERNAL アドバタイズされたリスナーのアドレスは要塞ノードでは解決できません。ロードバランサーの詳細ページから`kafka-lb` DNS 名（例： `nlb-o21d6wyjknamw8hjxb.ap-southeast-1.nlb.aliyuncsslbintl.com` ）をメモしておいてください。要塞ノードでスクリプトを実行してください。 @@ -644,7 +644,7 @@ b3.ap-southeast-1c.unique_name.alicloud.plc.tidbcloud.com:9095 (id: 3 rack: null 2. エンドポイントサービスの詳細ページに移動し、**Endpoint Service Name**（例： `com.aliyuncs.privatelink..xxxxx` ）をコピーします。これは後でTiDB Cloudで使用する必要があります。 -3. エンドポイントサービスの詳細ページで、「**サービスホワイトリスト」**タブをクリックし、 **Add to Whitelist**をクリックして、 [前提条件](#prerequisites)で取得した Alibaba Cloud アカウント ID を入力します。 +3. エンドポイントサービスの詳細ページで、**Service Whitelist**タブをクリックし、 **Add to Whitelist**をクリックして、 [前提条件](#prerequisites)で取得した Alibaba Cloud アカウント ID を入力します。 ## ステップ3. TiDB Cloudでプライベートリンク接続を作成する {#step-3-create-a-private-link-connection-in-tidb-cloud} diff --git a/tidb-cloud/serverless-private-link-connection.md b/tidb-cloud/serverless-private-link-connection.md index 061ebb3e10fc4..96ce789f0dd37 100644 --- a/tidb-cloud/serverless-private-link-connection.md +++ b/tidb-cloud/serverless-private-link-connection.md @@ -36,7 +36,7 @@ TiDB CloudコンソールまたはTiDB Cloud CLI を使用して、AWS Endpoint AWS エンドポイントサービスが次の条件を満たしていることを確認します。 - TiDB Cloudクラスターと同じリージョンに存在します。 -- TiDB Cloudアカウント ID を**許可プリンシパル**リストに追加します。 +- TiDB Cloudアカウント ID を**Allow principals**リストに追加します。 - TiDB Cloudクラスターと重複する可用性ゾーンがあります。 アカウント ID と可用性ゾーンの情報は**、[外部サービス用プライベートエンドポイントの作成**] ダイアログの下部で取得するか、次のコマンドを実行して取得できます。 @@ -126,7 +126,7 @@ TiDB CloudコンソールまたはTiDB Cloud CLI を使用して、Alibaba Cloud Alibaba Cloud エンドポイント サービスが次の条件を満たしていることを確認します。 - TiDB Cloudクラスターと同じリージョンに存在します。 -- TiDB Cloudアカウント ID を**サービス ホワイトリスト**に追加します。 +- TiDB Cloudアカウント ID を**Service Whitelist**に追加します。 - TiDB Cloudクラスターと重複する可用性ゾーンがあります。 アカウント ID と可用性ゾーンの情報は**、[外部サービス用プライベートエンドポイントの作成**] ダイアログの下部で取得するか、次のコマンドを実行して取得できます。 @@ -264,7 +264,7 @@ TiDB Cloudコンソールを使用してプライベート リンク接続から 3. クラウドプロバイダーの**[外部サービス用プライベートエンドポイント]**領域で、対象のプライベート リンク接続を選択し、 **[...]**をクリックします。 -4. **[ドメインの切り離し]**をクリックし、切り離しを確認します。 +4. **Detach Domains**をクリックし、切り離しを確認します。 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 6ed4b5e5885cb..c41431e9f3af0 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 @@ -40,7 +40,7 @@ Alibaba Cloud管理コンソールを使用してVPCインターフェースエ 2. **VPC** >**エンドポイント**に移動します。 -3. **「インターフェースエンドポイント」**タブで、 **Create Endpoint**をクリックします。 +3. **Interface Endpoints**タブで、 **Create Endpoint**をクリックします。 4. エンドポイント情報を入力してください。 - **リージョン**： TiDB Cloud StarterまたはEssentialインスタンスと同じリージョンを選択してください。 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 40d668bb7007c..4ce2432f0f2b8 100644 --- a/tidb-cloud/set-up-private-endpoint-connections-on-azure.md +++ b/tidb-cloud/set-up-private-endpoint-connections-on-azure.md @@ -85,7 +85,7 @@ Azure Private Link のアーキテクチャは次のとおりです: [^1] 1. [Azureポータル](https://portal.azure.com/)にログインします。 2. **Private endpoints**を検索し、検索結果から**Private endpoints**を選択してください。 3. **Private endpoint**ページで、 **+ Create**をクリックします。 -4. **「基本」**タブで、プロジェクトとインスタンスの情報を入力し、 **「次へ: リソース」**をクリックします。 +4. **「基本」**タブで、プロジェクトとインスタンスの情報を入力し、 **Next: Resource**をクリックします。 5. **「リソース」**タブで、**接続方法**として**「リソース ID またはエイリアスを使用して Azure リソースに接続する」**を選択し、コピーしたTiDB Cloudリソース ID を**Resource ID or alias**フィールドに貼り付けます。 6. 引き続き**「次へ」**をクリックして残りの構成タブに進み、必要な設定を完了します。次に、 **[作成]**をクリックしてプライベート エンドポイントを作成してデプロイします。 Azure のデプロイが完了するまでに数秒かかる場合があります。詳細については、Azure ドキュメントの[プライベートエンドポイントを作成する](https://learn.microsoft.com/en-us/azure/private-link/create-private-endpoint-portal?tabs=dynamic-ip#create-a-private-endpoint)を参照してください。 7. プライベートエンドポイントの作成とデプロイが完了したら、 **Go to resource**をクリックし、以下の手順を実行してください。 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 a39b660c72687..7fcf43194b8ff 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 @@ -129,15 +129,15 @@ Google Cloud Private Service Connect のアーキテクチャは以下のとお
1. [Google Cloud Console](https://console.cloud.google.com/)で、現在のプロジェクトがTiDB Cloudに入力した**Google Cloud Project ID**と同じであることを確認してください。 -2. **VPC network**>**Private Service Connect**>**接続済みエンドポイント**に移動し、 **Connect endpoint**をクリックします。 +2. **VPC network**>**Private Service Connect**>**Connected endpoints**に移動し、 **Connect endpoint**をクリックします。 3. TiDB Cloudで生成されたコマンドの値を使用してエンドポイントを設定します。 - **Endpoint name**：コマンドで指定した転送ルール名を使用します。 - - **対象**: **[公開サービス]**を選択し、 `--target-service-attachment`からサービス添付ファイル URI を入力します。 + - **対象**: **Published service**を選択し、 `--target-service-attachment`からサービス添付ファイル URI を入力します。 - **リージョン**：コマンドから地域を選択してください。 - **ネットワーク**: `--network`から VPC ネットワークを選択してください。 - **サブネットワーク**： `--subnet`からサブネットを選択してください。 -4. エンドポイントを作成するには、 **「エンドポイントの追加」**をクリックしてください。 -5. **「接続済みエンドポイント」**で、新しいエンドポイントが作成されていることを確認し、そのエンドポイント名を記録します。 +4. エンドポイントを作成するには、 **Add endpoint**をクリックしてください。 +5. **Connected endpoints**で、新しいエンドポイントが作成されていることを確認し、そのエンドポイント名を記録します。
diff --git a/tidb-cloud/set-up-private-endpoint-connections-serverless.md b/tidb-cloud/set-up-private-endpoint-connections-serverless.md index a7dd251f6f2aa..913e7a9e683db 100644 --- a/tidb-cloud/set-up-private-endpoint-connections-serverless.md +++ b/tidb-cloud/set-up-private-endpoint-connections-serverless.md @@ -81,13 +81,13 @@ AWS マネジメントコンソールを使用して VPC インターフェイ 4. [ステップ1](#step-1-choose-a-tidb-instance)で見つけたサービス名を入力します。 -5. **「サービスを確認する」**をクリックしてください。 +5. **Verify service**をクリックしてください。 6. ドロップダウンリストからVPCを選択します。 **Additional settings**を展開し、 **Enable DNS name**チェックボックスをオンにします。 7. **サブネット**領域で、 TiDB Cloud StarterまたはEssentialインスタンスが配置されているアベイラビリティゾーンを選択し、サブネットIDを選択します。 -8. **セキュリティグループ**領域で、適切なセキュリティグループを選択してください。 +8. **Security groups**領域で、適切なセキュリティグループを選択してください。 > **Note:** > 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 6d2d189aa16ff..9fb7207747c02 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 @@ -92,20 +92,20 @@ summary: このドキュメントでは、Azure でセルフホスト型 Kafka 1. [Azureポータル](https://portal.azure.com/)にログインし、 [仮想マシン](https://portal.azure.com/#view/Microsoft_Azure_ComputeHub/ComputeHubMenuBlade/~/virtualMachinesBrowse)ページに移動して**+ Create**をクリックし、 **[Azure 仮想マシン]**を選択します。 2. **[基本]**タブで、**サブスクリプション**、**Resource group**、**リージョン**を選択し、次の情報を入力して、 **[次へ: ディスク]**をクリックします。 - **仮想マシン名**: `broker-node` - - **利用可能オプション**: `Availability zone` - - **ゾーンオプション**: `Self-selected zone` + - **Availability options**: `Availability zone` + - **Zone options**: `Self-selected zone` - `Zone 3` `Zone 2`**Availability zone**: `Zone 1` - **画像**： `Ubuntu Server 24.04 LTS - x64 Gen2` - - **VMアーキテクチャ：** `x64` + - **VM architecture:** `x64` - **サイズ**: `Standard_D2s_v3` - - **認証タイプ**: `SSH public key` + - **Authentication type**: `SSH public key` - **ユーザー名**: `azureuser` - **SSH public key source:** `Generate new key pair` - **Key pair name**: `kafka_broker_key` - **Public inbound ports**: `Allow selected ports` - **Select inbound ports**: `SSH (22)` 3. **Next : Networking**をクリックし、 **[ネットワーク]**タブに次の情報を入力します。 - - **仮想ネットワーク**： `kafka-pls-vnet` + - **Virtual network**： `kafka-pls-vnet` - **サブネット**: `brokers-subnet` - **Public IP** : `None` - **NIC network security group**: `Basic` @@ -124,7 +124,7 @@ summary: このドキュメントでは、Azure でセルフホスト型 Kafka 2. ブローカー ノードの各ページで、左側のナビゲーション ペインの**Connect > Bastion**をクリックし、次の情報を入力します。 - - **認証タイプ**: `SSH Private Key from Local File` + - **Authentication Type**: `SSH Private Key from Local File` - **ユーザー名**: `azureuser` - **Local File**: 以前にダウンロードした秘密鍵ファイルを選択します - **「新しいブラウザタブで開く」**オプションを選択します @@ -438,30 +438,30 @@ b3.abc.eastus.azure.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. 3. **Frontend IP configuration**タブで、 **[+ フロントエンド IP 構成の追加]**をクリックし、次の情報を入力して**[保存]**をクリックし、 **[次へ: バックエンド プール >]**をクリックします。 - **名前**: `kafka-lb-ip` - - **IP バージョン**: `IPv4` - - **仮想ネットワーク**： `kafka-pls-vnet` + - **IP version**: `IPv4` + - **Virtual network**： `kafka-pls-vnet` - **サブネット**: `brokers-subnet` - **課題**： `Dynamic` - **Availability zone**: `Zone-redundant` -4. **[バックエンド プール]**タブで、次の 3 つのバックエンド プールを追加し、 **Next : Inbound rules**をクリックします。 +4. **Backend pools**タブで、次の 3 つのバックエンド プールを追加し、 **Next : Inbound rules**をクリックします。 - 名前: `pool1` ; バックエンド プールコンフィグレーション: `NIC` ; IP 構成: `broker-node-1` - 名前: `pool2` ; バックエンド プールコンフィグレーション: `NIC` ; IP 構成: `broker-node-2` - 名前: `pool3` ; バックエンド プールコンフィグレーション: `NIC` ; IP 構成: `broker-node-3` -5. **[受信規則]**タブで、次の 3 つの負荷分散規則を追加します。 +5. **Inbound rules**タブで、次の 3 つの負荷分散規則を追加します。 1. ルール1 - **名前**: `rule1` - - **IP バージョン**: `IPv4` + - **IP version**: `IPv4` - **Frontend IP address**: `kafka-lb-ip` - - **バックエンドプール**: `pool1` + - **Backend pool**: `pool1` - **プロトコル**： `TCP` - **ポート**: `9093` - - **バックエンドポート**: `39092` - - **ヘルスプローブ**: **Create New**をクリックし、プローブ情報を入力します。 + - **Backend port**: `39092` + - **Health probe**: **Create New**をクリックし、プローブ情報を入力します。 - **名前**: `kafka-lb-hp` - **プロトコル**： `TCP` - **ポート**: `39092` @@ -469,13 +469,13 @@ b3.abc.eastus.azure.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. 2. ルール2 - **名前**: `rule2` - - **IP バージョン**: `IPv4` + - **IP version**: `IPv4` - **Frontend IP address**: `kafka-lb-ip` - - **バックエンドプール**: `pool2` + - **Backend pool**: `pool2` - **プロトコル**： `TCP` - **ポート**: `9094` - - **バックエンドポート**: `39092` - - **ヘルスプローブ**: **Create New**をクリックし、プローブ情報を入力します。 + - **Backend port**: `39092` + - **Health probe**: **Create New**をクリックし、プローブ情報を入力します。 - **名前**: `kafka-lb-hp` - **プロトコル**： `TCP` - **ポート**: `39092` @@ -483,13 +483,13 @@ b3.abc.eastus.azure.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. 3. ルール3 - **名前**: `rule3` - - **IP バージョン**: `IPv4` + - **IP version**: `IPv4` - **Frontend IP address**: `kafka-lb-ip` - - **バックエンドプール**: `pool3` + - **Backend pool**: `pool3` - **プロトコル**： `TCP` - **ポート**: `9095` - - **バックエンドポート**: `39092` - - **ヘルスプローブ**: **Create New**をクリックし、プローブ情報を入力します。 + - **Backend port**: `39092` + - **Health probe**: **Create New**をクリックし、プローブ情報を入力します。 - **名前**: `kafka-lb-hp` - **プロトコル**： `TCP` - **ポート**: `39092` @@ -504,16 +504,16 @@ b3.abc.eastus.azure.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. 2. **[基本]**タブで、 **[サブスクリプ**ション]、 **Resource group** 、 **[リージョン]**を選択し、[**名前]**フィールドに`kafka-pls`入力して、 **[次へ: 送信設定 >]**をクリックします。 -3. **[送信設定]**タブで、次のようにパラメータを入力し、 **[次へ: アクセス セキュリティ >]**をクリックします。 +3. **Outbound settings**タブで、次のようにパラメータを入力し、 **Next : Access security >**をクリックします。 - - **ロードバランサー**： `kafka-lb` + - **Load balancer**： `kafka-lb` - **ロードバランサのフロントエンド IP アドレス**: `kafka-lb-ip` - **Source NAT subnet**: `kafka-pls-vnet/brokers-subnet` -4. **[アクセス セキュリティ]**タブで、次の操作を行います。 +4. **Access security**タブで、次の操作を行います。 - **表示**については、 **Restricted by subscription**または**Anyone with your alias**を選択します。 - - **Subscription-level access and auto-approval**については、**サブスクリプションの追加**をクリックして、 [前提条件](#prerequisites)で取得したTiDB Cloud Azure アカウントのサブスクリプションを追加します。 + - **Subscription-level access and auto-approval**については、**Add subscriptions**をクリックして、 [前提条件](#prerequisites)で取得したTiDB Cloud Azure アカウントのサブスクリプションを追加します。 5. **Next : Tags >**をクリックし、 **「次へ: 確認と作成 >」**をクリックして情報を確認します。 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 5281cf6f45028..56bad1375d8d9 100644 --- a/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md +++ b/tidb-cloud/setup-self-hosted-kafka-private-service-connect.md @@ -81,8 +81,8 @@ Kafka クラスターを簡単に構成できるように、Kafka VPC 用に 2 - **名前**: `kafka-vpc` - サブネット - - **名前**: `bastion-subnet` ;**リージョン**: `us-west1` ; **IPv4範囲**: `10.0.0.0/18` - - **名前**: `brokers-subnet` ;**リージョン**: `us-west1` ; **IPv4範囲**: `10.64.0.0/18` + - **名前**: `bastion-subnet` ;**リージョン**: `us-west1` ; **IPv4 range**: `10.0.0.0/18` + - **名前**: `brokers-subnet` ;**リージョン**: `us-west1` ; **IPv4 range**: `10.64.0.0/18` - ファイアウォールルール - `kafka-vpc-allow-custom` - `kafka-vpc-allow-ssh` @@ -478,16 +478,16 @@ b3.abc.us-west1.gcp.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. 1. ネットワークエンドポイント1 - **インスタンス**: `broker-node1` - - **VMポート**: `39092` - - **クライアントポート**: `9093` + - **VM Port**: `39092` + - **Client Port**: `9093` 2. ネットワークエンドポイント2 - **インスタンス**: `broker-node2` - - **VMポート**: `39092` - - **クライアントポート**: `9094` + - **VM Port**: `39092` + - **Client Port**: `9094` 3. ネットワークエンドポイント3 - **インスタンス**: `broker-node3` - - **VMポート**: `39092` - - **クライアントポート**: `9095` + - **VM Port**: `39092` + - **Client Port**: `9095` 3. [負荷分散](https://console.cloud.google.com/net-services/loadbalancing/list/loadBalancers)ページに移動します。以下の手順でロードバランサーを作成します。 @@ -498,14 +498,14 @@ b3.abc.us-west1.gcp.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. - **リージョン**: `us-west1` - **ネットワーク**: `kafka-vpc` - バックエンド構成 - - **バックエンドタイプ**： `Port mapping network endpoint group` + - **Backend type**： `Port mapping network endpoint group` - **プロトコル**： `TCP` - **ポートマッピングネットワークエンドポイントグループ**: `kafka-neg` - フロントエンド構成 - **サブネットワーク**: `brokers-subnet` - **ポート**: `All` -4. [**Private Service Connect**>**公開サービス**](https://console.cloud.google.com/net-services/psc/list/producers)に進みます。 +4. [**Private Service Connect** > **PUBLISH SERVICE**](https://console.cloud.google.com/net-services/psc/list/producers)に進みます。 - **Load Balancer Type**: `Internal passthrough Network Load Balancer` - **Internal load balancer**： `kafka-lb` @@ -514,8 +514,8 @@ b3.abc.us-west1.gcp.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. - **名前**: `psc-subnet` - **VPC Network**: `kafka-vpc` - **リージョン**: `us-west1` - - **IPv4範囲**: `10.128.0.0/18` - - **承認されたプロジェクト**: [前提条件](#prerequisites)で取得したTiDB Cloudの Google Cloud プロジェクト (例: `tidbcloud-prod-000` )。 + - **IPv4 range**: `10.128.0.0/18` + - **Accepted projects**: [前提条件](#prerequisites)で取得したTiDB Cloudの Google Cloud プロジェクト (例: `tidbcloud-prod-000` )。 5. `kafka-psc`の詳細ページに移動します。**Service attachment**（例： `projects/tidbcloud-dp-stg-000/regions/us-west1/serviceAttachments/kafka-psc` ）を書き留めます。TiDB Cloudでこの PSC に接続する際に使用します。 @@ -525,7 +525,7 @@ b3.abc.us-west1.gcp.3199745.tidbcloud.com:9095 (id: 3 rack: null) -> ERROR: org. - **Direction of traffic**： `Ingress` - **Action on match**： `Allow` - **ターゲット**： `All instances in the network` - - **ソースフィルター**: `IPv4 ranges` + - **Source filter**: `IPv4 ranges` - **Source IPv4 ranges**: `10.128.0.0/18` -subnetの範囲。 - **Protocols and ports**: すべて許可 @@ -565,7 +565,7 @@ TiDB クラスターと同じリージョンで既に Kafka クラスターが - **場所**： `Single zone` - **リージョン**: `us-west1` - **ゾーン**: ブローカーのゾーンの 1 つを選択します。 - - **自動スケーリングモード**: `Off` + - **Autoscaling mode**: `Off` - **Minimum number of instances**: `1` - **Maximum number of instances**: `1` 。Kafkaプロキシはクラスターモードをサポートしていないため、デプロイできるインスタンスは1つだけです。各Kafkaプロキシはローカルポートをブローカーのポートにランダムにマッピングするため、プロキシごとにマッピングが異なります。ロードバランサーの背後に複数のKafkaプロキシをデプロイすると、問題が発生する可能性があります。Kafkaクライアントが1つのプロキシに接続し、別のプロキシを経由してブローカーにアクセスすると、リクエストが誤ったブローカーにルーティングされる可能性があります。 @@ -633,9 +633,9 @@ TiDB クラスターと同じリージョンで既に Kafka クラスターが - **リージョン**: `us-west1` - **ネットワーク**: あなたのネットワーク - バックエンド構成 - - **バックエンドタイプ**： `Instance group` + - **Backend type**： `Instance group` - **プロトコル**： `TCP` - - **インスタンスグループ**: `kafka-proxy-ig` + - **Instance group**: `kafka-proxy-ig` - フロントエンド構成 - **サブネットワーク**: サブネット - **ポート**: `All` @@ -645,7 +645,7 @@ TiDB クラスターと同じリージョンで既に Kafka クラスターが - **プロトコル**： `TCP` - **ポート**: `9092` -proxy でブートストラップ ポートの 1 つを選択できます。 -2. [**Private Service Connect**>**公開サービス**](https://console.cloud.google.com/net-services/psc/list/producers)に進みます。 +2. [**Private Service Connect** > **PUBLISH SERVICE**](https://console.cloud.google.com/net-services/psc/list/producers)に進みます。 - **Load Balancer Type**: `Internal passthrough Network Load Balancer` - **Internal load balancer**： `kafka-proxy-lb` @@ -654,8 +654,8 @@ TiDB クラスターと同じリージョンで既に Kafka クラスターが - **名前**: `proxy-psc-subnet` - **VPC Network**: あなたのネットワーク - **リージョン**: `us-west1` - - **IPv4 範囲**: ネットワーク計画に基づいて CIDR を設定します - - **承認されたプロジェクト**: [前提条件](#prerequisites)で取得したTiDB Cloudの Google Cloud プロジェクト (例: `tidbcloud-prod-000` )。 + - **IPv4 range**: ネットワーク計画に基づいて CIDR を設定します + - **Accepted projects**: [前提条件](#prerequisites)で取得したTiDB Cloudの Google Cloud プロジェクト (例: `tidbcloud-prod-000` )。 3. **kafka-proxy-psc**の詳細ページに移動します。 `Service attachment` （例： `projects/tidbcloud-dp-stg-000/regions/us-west1/serviceAttachments/kafka-proxy-psc` ）をメモします。これは、 TiDB Cloudがこの PSC に接続する際に使用されます。 @@ -665,7 +665,7 @@ TiDB クラスターと同じリージョンで既に Kafka クラスターが - **Direction of traffic**： `Ingress` - **Action on match**： `Allow` - **対象**: ネットワーク内のすべてのインスタンス - - **ソースフィルター**: `IPv4 ranges` + - **Source filter**: `IPv4 ranges` - **Source IPv4 ranges**: proxy-psc-subnet の CIDR - **Protocols and ports**: すべて許可 diff --git a/tidb-cloud/tidb-cloud-auditing.md b/tidb-cloud/tidb-cloud-auditing.md index 202d9c27f4d89..78419f04e9e3c 100644 --- a/tidb-cloud/tidb-cloud-auditing.md +++ b/tidb-cloud/tidb-cloud-auditing.md @@ -75,10 +75,10 @@ TiDB Cloud が監査ログを書き込む宛先として、組織所有の AWS 4. **「データベース監査ログストレージ設定」**ダイアログで、 **AWS IAM Policy Settings**セクションを見つけて、後で使用するために**TiDB Cloud Account ID**と**TiDB Cloud External ID**を記録します。 -2. [AWS Management Console](https://console.aws.amazon.com/)で、 **IAM** >**アクセス管理**>**ポリシー**に移動し、書き込み専用権限`s3:PutObject`を持つIAMポリシーがあるかどうかを確認します。 +2. [AWS Management Console](https://console.aws.amazon.com/)で、 **IAM** > **Access Management** > **Policies**に移動し、書き込み専用権限`s3:PutObject`を持つIAMポリシーがあるかどうかを確認します。 - はいの場合は、後で使用するために一致したポリシーを記録します。 - - そうでない場合は、 **「IAM」** > **「アクセス管理」** > **「ポリシー」** > **「ポリシーの作成」**に移動し、次のポリシー テンプレートに従ってIAMポリシーを定義します。 + - そうでない場合は、 **IAM** > **Access Management** > **Policies** > **Create Policy**に移動し、次のポリシー テンプレートに従ってIAMポリシーを定義します。 ```json { @@ -93,16 +93,16 @@ TiDB Cloud が監査ログを書き込む宛先として、組織所有の AWS } ``` - テンプレート内の``は、監査ログファイルが書き込まれるS3バケットのAmazonリソースネーム（ARN）です。S3バケットの**「プロパティ」**タブに移動し、 **「バケットの概要」**エリアでARN値を確認できます。「 `"Resource"`フィールドでは、ARNの後に`/*`を追加する必要があります。例えば、ARNが`arn:aws:s3:::tidb-cloud-test`の場合、 `"Resource"`フィールドの値を`"arn:aws:s3:::tidb-cloud-test/*"`に設定する必要があります。 + テンプレート内の``は、監査ログファイルが書き込まれるS3バケットのAmazonリソースネーム（ARN）です。S3バケットの**「プロパティ」**タブに移動し、 **Bucket Overview**エリアでARN値を確認できます。「 `"Resource"`フィールドでは、ARNの後に`/*`を追加する必要があります。例えば、ARNが`arn:aws:s3:::tidb-cloud-test`の場合、 `"Resource"`フィールドの値を`"arn:aws:s3:::tidb-cloud-test/*"`に設定する必要があります。 -3. **「IAM」** > **「アクセス管理」** > **「ロール」**に移動し、前に記録したTiDB Cloudアカウント ID と外部 ID に対応する信頼エンティティを持つロールがすでに存在するかどうかを確認します。 +3. **IAM** > **Access Management** > **Roles**に移動し、前に記録したTiDB Cloudアカウント ID と外部 ID に対応する信頼エンティティを持つロールがすでに存在するかどうかを確認します。 - はいの場合は、後で使用するために一致したロールを記録します。 - そうでない場合は、 **Create role**をクリックし、信頼エンティティタイプとして**Another AWS account**を選択し、 **Account ID**フィールドにTiDB CloudのアカウントIDを入力します。次に、 **Require External ID**オプションを選択し、 **External ID**フィールドにTiDB Cloudの外部IDを入力します。 -4. **IAM** >**アクセス管理**>**ロール**で、前の手順のロール名をクリックして**概要**ページに移動し、次の手順を実行します。 +4. **IAM** > **Access Management** > **Roles**で、前の手順のロール名をクリックして**概要**ページに移動し、次の手順を実行します。 - 1. **「権限」**タブで、書き込み専用権限`s3:PutObject`を持つ記録済みのポリシーがロールにアタッチされているかどうかを確認します。アタッチされていない場合は、 **「ポリシーのアタッチ」**を選択し、必要なポリシーを検索して**「ポリシーのアタッチ」を**クリックします。 + 1. **「権限」**タブで、書き込み専用権限`s3:PutObject`を持つ記録済みのポリシーがロールにアタッチされているかどうかを確認します。アタッチされていない場合は、 **Attach Policies**を選択し、必要なポリシーを検索して**Attach Policy**をクリックします。 2. **概要**ページに戻り、**Role ARN**値をクリップボードにコピーします。 #### ステップ3. 監査ログを有効にする {#step-3-enable-audit-logging} @@ -159,13 +159,13 @@ TiDB Cloud が監査ログを書き込む宛先として、組織所有の Googl パネルが表示されます。 -4. パネルで、 **「プリンシパルの追加」**をクリックします。 +4. パネルで、 **ADD PRINCIPAL**をクリックします。 プリンシパルを追加するためのダイアログ ボックスが表示されます。 5. ダイアログ ボックスで、次の手順を実行します。 - 1. **[新しいプリンシパル]**フィールドに、TiDB クラスタの Google Cloud サービス アカウント ID を貼り付けます。 + 1. **New Principals**フィールドに、TiDB クラスタの Google Cloud サービス アカウント ID を貼り付けます。 2. **[ロール]**ドロップダウン リストで、ターゲット TiDB クラスターのロールを選択します。 3. **[保存]**をクリックします。 @@ -198,26 +198,26 @@ TiDB Cloudがデータベース監査ログを書き込む宛先として、組 1. [Azureポータル](https://portal.azure.com/)で、データベース監査ログを保存するために使用するコンテナを作成します。 - 1. Azure ポータルの左側のナビゲーション ウィンドウで、 **[ストレージ アカウント]**をクリックし、データベース監査ログを保存するストレージアカウントをクリックします。 + 1. Azure ポータルの左側のナビゲーション ウィンドウで、 **Storage Accounts**をクリックし、データベース監査ログを保存するストレージアカウントをクリックします。 > **Tip:** > > 左側のナビゲーション ペインが非表示になっている場合は、左上隅のメニュー ボタンをクリックして表示を切り替えます。 - 2. 選択したストレージアカウントのナビゲーション ウィンドウで、 **Data storage > Containers**をクリックし、 **[+ コンテナー]**をクリックして**[新しいコンテナー]**ウィンドウを開きます。 + 2. 選択したストレージアカウントのナビゲーション ウィンドウで、 **Data storage > Containers**をクリックし、 **+ Container**をクリックして**New container**ウィンドウを開きます。 - 3. **「新しいコンテナ」**ペインで、新しいコンテナの名前を入力し、匿名アクセスレベル（推奨レベルは**「プライベート」** （匿名アクセスなし））を設定して、 **「作成」**をクリックします。数秒以内に新しいコンテナが作成され、コンテナリストに表示されます。 + 3. **New container**ペインで、新しいコンテナの名前を入力し、匿名アクセスレベル（推奨レベルは**「プライベート」** （匿名アクセスなし））を設定して、 **「作成」**をクリックします。数秒以内に新しいコンテナが作成され、コンテナリストに表示されます。 2. ターゲット コンテナの URL を取得します。 - 1. コンテナー リストで、対象のコンテナーを選択し、コンテナーの**[...]**をクリックして、 **[コンテナーのプロパティ]**を選択します。 + 1. コンテナー リストで、対象のコンテナーを選択し、コンテナーの**[...]**をクリックして、 **Container properties**を選択します。 2. 表示されたプロパティ ページで、後で使用するために**URL**値をコピーし、コンテナー リストに戻ります。 3. ターゲット コンテナーの SAS トークンを生成します。 - 1. コンテナー リストで、ターゲット コンテナーを選択し、コンテナーの**[...]**をクリックして、 **[SAS の生成]**を選択します。 + 1. コンテナー リストで、ターゲット コンテナーを選択し、コンテナーの**[...]**をクリックして、 **Generate SAS**を選択します。 - 2. 表示された**「SAS の生成」**ペインで、**Account key**として**「アカウント キー」**を選択します。 + 2. 表示された**Generate SAS**ペインで、**Signing method**として**Account key**を選択します。 3. **[権限]**ドロップダウン リストで、 **[読み取り]** 、 **[書き込み]** 、 **[作成]**を選択して、監査ログ ファイルの書き込みを許可します。 @@ -229,7 +229,7 @@ TiDB Cloudがデータベース監査ログを書き込む宛先として、組 > - 生成された SAS トークンは取り消すことができないため、有効期間を慎重に設定する必要があります。 > - 監査ログの継続的な可用性を確保するために、SAS トークンの有効期限が切れる前に必ず再生成して更新してください。 - 5. **許可されたプロトコル**については、安全なアクセスを確保するために**HTTPS のみ**を選択します。 + 5. **Allowed protocols**については、安全なアクセスを確保するために**HTTPS only**を選択します。 6. **[SAS トークンと URL の生成]**をクリックし、表示される**Blob SAS token**を後で使用するためにコピーします。 diff --git a/tidb-cloud/tidb-cloud-billing.md b/tidb-cloud/tidb-cloud-billing.md index ec71f68822420..5a93d33eb7cc4 100644 --- a/tidb-cloud/tidb-cloud-billing.md +++ b/tidb-cloud/tidb-cloud-billing.md @@ -414,7 +414,7 @@ TiDB CloudアカウントをAlibaba Cloudの請求アカウントにリンクす 1. [アリババクラウドマーケットプレイスページ](https://marketplace.alibabacloud.com/)ページを開き、 `TiDB Cloud`を検索し、検索結果から**TiDB Cloud**を選択します。 TiDB Cloudの製品ページが表示されます。 -2. TiDB Cloud製品ページで**「今すぐ有効化」**をクリックし、画面の指示に従って従量課金モードを確認し、有効化アプリケーションを表示します。 +2. TiDB Cloud製品ページで**Activate Now**をクリックし、画面の指示に従って従量課金モードを確認し、有効化アプリケーションを表示します。 3. 購読ページで、 TiDB Cloudの購読情報を探し、 **「自動ログイン」**をクリックしてください。TiDB Cloudのサインアップページに移動します。 diff --git a/tidb-cloud/tidb-cloud-clinic.md b/tidb-cloud/tidb-cloud-clinic.md index d5cce6c96aace..cd6dfbedfc4ab 100644 --- a/tidb-cloud/tidb-cloud-clinic.md +++ b/tidb-cloud/tidb-cloud-clinic.md @@ -109,16 +109,16 @@ TopSQL を表示するには、次の手順を実行します。 ## ベンチマークレポートを生成する {#generate-benchmark-reports} -**ベンチマークレポート**機能は、パフォーマンステスト中にTiDBクラスタのパフォーマンス問題を特定するのに役立ちます。ストレステストを完了すると、ベンチマークレポートを生成してクラスタのパフォーマンスを分析できます。レポートでは、特定されたボトルネックが強調表示され、最適化の提案が提供されます。これらの提案を適用した後、もう一度ストレステストを実行し、新しいベンチマークレポートを生成してパフォーマンスの改善を比較できます。 +**Benchmark Report**機能は、パフォーマンステスト中にTiDBクラスタのパフォーマンス問題を特定するのに役立ちます。ストレステストを完了すると、ベンチマークレポートを生成してクラスタのパフォーマンスを分析できます。レポートでは、特定されたボトルネックが強調表示され、最適化の提案が提供されます。これらの提案を適用した後、もう一度ストレステストを実行し、新しいベンチマークレポートを生成してパフォーマンスの改善を比較できます。 ベンチマーク レポートを生成するには、次の手順を実行します。 1. [TiDB Cloud Clinic コンソール](https://clinic.pingcap.com/)で、クラスターの**「クラスタ」**ページに移動します。 -2. **ベンチマークレポート**をクリックします。 +2. **Benchmark Report**をクリックします。 3. ベンチマーク レポートで分析する時間範囲を選択します。 -4. ベンチマーク レポートを生成するには、**レポートの作成**をクリックします。 +4. ベンチマーク レポートを生成するには、**Create Report**をクリックします。 5. レポートの生成が完了するまでお待ちください。レポートが完成したら、 **「ビュー」**をクリックして開きます。 diff --git a/tidb-cloud/tidb-cloud-connect-aws-dms.md b/tidb-cloud/tidb-cloud-connect-aws-dms.md index ff677c3240e72..e1bd3feb57fc5 100644 --- a/tidb-cloud/tidb-cloud-connect-aws-dms.md +++ b/tidb-cloud/tidb-cloud-connect-aws-dms.md @@ -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)を参照してください。 + - レプリケーションインスタンスをパブリックサブネットにデプロイし、 **Public accessible**を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](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)を参照してください。 + - レプリケーションインスタンスをパブリックサブネットにデプロイし、 **Public accessible**を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](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)を参照してください。 + - レプリケーションインスタンスをパブリックサブネットにデプロイし、 **Public accessible**を有効にします。詳細については、 [インターネットアクセスのコンフィグレーション](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)を参照してください。 @@ -81,7 +81,7 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド ## AWS DMS レプリケーションインスタンスを作成する {#create-an-aws-dms-replication-instance} -1. AWS DMSコンソールの[**レプリケーションインスタンス**](https://console.aws.amazon.com/dms/v2/home#replicationInstances)ページに移動し、対応するリージョンに切り替えます。AWS DMSでは、 TiDB Cloudと同じリージョンを使用することをお勧めします。 +1. AWS DMSコンソールの[**Replication instances**](https://console.aws.amazon.com/dms/v2/home#replicationInstances)ページに移動し、対応するリージョンに切り替えます。AWS DMSでは、 TiDB Cloudと同じリージョンを使用することをお勧めします。 ![Create replication instance](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-connect-replication-instances.png) @@ -89,9 +89,9 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド 3. インスタンス名、ARN、説明を入力します。 -4. **インスタンス構成**セクションで、インスタンスを構成します。 - - **インスタンスクラス**: 適切なインスタンスクラスを選択します。詳細については、 [レプリケーションインスタンスタイプの選択](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Types.html)を参照してください。 - - **エンジン バージョン**: デフォルト構成を維持します。 +4. **Instance configuration**セクションで、インスタンスを構成します。 + - **Instance class**: 適切なインスタンスクラスを選択します。詳細については、 [レプリケーションインスタンスタイプの選択](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_ReplicationInstance.Types.html)を参照してください。 + - **Engine version**: デフォルト構成を維持します。 - **High Availability**: ビジネス ニーズに応じて、**マルチ AZ**または**シングル AZ**を選択します。 5. **Allocated storage (GiB)**フィールドでストレージを構成します。 @@ -101,7 +101,7 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド - **Network type - new**: **IPv4**を選択します。 - **IPv4 用の仮想プライベート クラウド (VPC)** : 必要な VPC を選択します。 - **Replication subnet group**: レプリケーション インスタンスのサブネット グループを選択します。 - - **パブリックアクセス可能**: ネットワーク構成に基づいて設定します。 + - **Public accessible**: ネットワーク構成に基づいて設定します。 ![Connectivity and security](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-connect-connectivity-security.png) @@ -109,7 +109,7 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド > **Note:** > -> AWS DMS はサーバーレスレプリケーションもサポートしています。詳細な手順については、 [サーバーレスレプリケーションの作成](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Serverless.Components.html#CHAP_Serverless.create)をご覧ください。レプリケーションインスタンスとは異なり、AWS DMS のサーバーレスレプリケーションでは「**パブリックアクセス可能」**オプションは提供されません。 +> AWS DMS はサーバーレスレプリケーションもサポートしています。詳細な手順については、 [サーバーレスレプリケーションの作成](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Serverless.Components.html#CHAP_Serverless.create)をご覧ください。レプリケーションインスタンスとは異なり、AWS DMS のサーバーレスレプリケーションでは**Public accessible**オプションは提供されません。 ## TiDB Cloud DMSエンドポイントを作成する {#create-tidb-cloud-dms-endpoints} @@ -121,9 +121,9 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド 2. **Create endpoint**をクリックして、ターゲット データベース エンドポイントを作成します。 -3. **Endpoint type**セクションで、 **[ソース エンドポイント]**または**Target endpoint**を選択します。 +3. **Endpoint type**セクションで、 **Source endpoint**または**Target endpoint**を選択します。 -4. **エンドポイント設定**セクションで、**エンドポイント識別子**とARNフィールドに入力します。次に、**ソースエンジン**または**ターゲットエンジン**として**MySQLを**選択します。 +4. **Endpoint configuration**セクションで、**Endpoint identifier**とARNフィールドに入力します。次に、**Source engine**または**Target engine**として**MySQL**を選択します。 5. **[Access to endpoint database]**フィールドで、 **[Provide access information manually]**チェックボックスをオンにし、次のようにクラスター情報を入力します。 @@ -154,6 +154,6 @@ TiDB Cloud Dedicated の場合、クライアントはパブリック エンド ![Provide access information manually](/media/tidb-cloud/aws-dms-tidb-cloud/aws-dms-connect-configure-endpoint.png) -6. エンドポイントを**Target endpoint**として作成する場合は、**エンドポイント設定**セクションを展開し、**Use endpoint connection attributes**チェックボックスをオンにして、**Extra connection attributes**を`Initstmt=SET FOREIGN_KEY_CHECKS=0;`に設定します。 +6. エンドポイントを**Target endpoint**として作成する場合は、**Endpoint settings**セクションを展開し、**Use endpoint connection attributes**チェックボックスをオンにして、**Extra connection attributes**を`Initstmt=SET FOREIGN_KEY_CHECKS=0;`に設定します。 7. 必要に応じて、 **KMS Key**と**タグの**セクションを設定します。 **Create endpoint**をクリックしてインスタンスの作成を完了します。 diff --git a/tidb-cloud/tidb-cloud-console-auditing.md b/tidb-cloud/tidb-cloud-console-auditing.md index 9cd471f60750a..cf046ceb0f139 100644 --- a/tidb-cloud/tidb-cloud-console-auditing.md +++ b/tidb-cloud/tidb-cloud-console-auditing.md @@ -39,7 +39,7 @@ TiDB Cloudは、 [TiDB Cloudコンソール](https://tidbcloud.com)上のユー 1. [TiDB Cloudコンソール](https://tidbcloud.com)で、左上隅のコンボ ボックスを使用して対象の組織に切り替えます。 2. 左側のナビゲーション ペインで、 **[Console Audit Logging]**をクリックします。 3. 監査ログの特定の部分を取得するには、イベントの種類、操作ステータス、および時間範囲をフィルタリングできます。 -4. (オプション) さらにフィールドをフィルターするには、 **[詳細フィルター]**をクリックし、さらにフィルターを追加して、 **[適用]**をクリックします。 +4. (オプション) さらにフィールドをフィルターするには、 **Advanced filter**をクリックし、さらにフィルターを追加して、 **[適用]**をクリックします。 5. ログの行をクリックすると、右側のペインに詳細情報が表示されます。 ## コンソール監査ログをエクスポートする {#export-console-audit-logs} diff --git a/tidb-cloud/tidb-cloud-sql-tuning-overview.md b/tidb-cloud/tidb-cloud-sql-tuning-overview.md index 882ce54073e60..c2e9176ece55f 100644 --- a/tidb-cloud/tidb-cloud-sql-tuning-overview.md +++ b/tidb-cloud/tidb-cloud-sql-tuning-overview.md @@ -29,7 +29,7 @@ TiDB Cloudコンソールには、 [**SQL Statement**](/tidb-cloud/tune-performa **SQL Statement**でいくつかの重要な情報を確認できます。 -- **SQLテンプレート**：SQLダイジェスト、SQLテンプレートID、現在表示されている時間範囲、実行計画の数、および実行が行われるデータベースが含まれます。 +- **SQL Template**：SQLダイジェスト、SQLテンプレートID、現在表示されている時間範囲、実行計画の数、および実行が行われるデータベースが含まれます。 ![Details0](/media/dashboard/dashboard-statement-detail0.png) diff --git a/tidb-cloud/tidb-cloud-support.md b/tidb-cloud/tidb-cloud-support.md index 971148454a24b..aa2ece1420aba 100644 --- a/tidb-cloud/tidb-cloud-support.md +++ b/tidb-cloud/tidb-cloud-support.md @@ -41,7 +41,7 @@ PingCAP ヘルプ センターには、 [https://tidb.support.pingcap.com/servic - [TiDB Cloudコンソール](https://tidbcloud.com/)の右下隅にある**[?]**をクリックし、 **Support Tickets**をクリックします。 - [TiDB Cloudコンソール](https://tidbcloud.com/)の左下隅にある**[サポート] を**クリックし、サポート プランに応じて次のいずれかを実行します。 - - **基本**: **[Account & Billing]**領域で、 **[アカウント/請求の問題]**をクリックします。 + - **基本**: **[Account & Billing]**領域で、 **Account/Billing issues**をクリックします。 - **Developer** 、 **Enterprise** 、または**Premium** : **Talk to an expert**エリアで、 **PingCAP Help Center**をクリックします。 - プロジェクトの[**クラスター**](https://tidbcloud.com/project/clusters)ページで、クラスターの行にある**[...]**をクリックし、 **Get Support**を選択します。 - クラスターの概要ページで、右上隅の**[...]**をクリックし、 **Get Support**を選択します。 @@ -99,7 +99,7 @@ TiDB Cloudのすべてのユーザーは、請求およびアカウント関連 - **コンポーネント**: TiDB、TiKV、PD、 TiFlashなど、問題を報告する関連するTiDB Cloudコンポーネントを選択します。 - - **影響を受けるバージョン**: 問題に関連するTiDB Cloudクラスターのバージョンを指定します。 + - **Affects versions**: 問題に関連するTiDB Cloudクラスターのバージョンを指定します。 4. **［送信］**をクリックします。 diff --git a/tidb-cloud/top-ru.md b/tidb-cloud/top-ru.md index 93012a8ce1fc0..35b8b2a97dbb8 100644 --- a/tidb-cloud/top-ru.md +++ b/tidb-cloud/top-ru.md @@ -46,7 +46,7 @@ TiDB Cloudプランによって、RUの主要機能は異なります。 - 利用可能な開始日の最短日は、データ保持期間によって異なります。TiDB Cloud Premiumインスタンスの場合は**30 days ago**、 TiDB Cloud Essentialインスタンスの場合は**7 days ago**。 - 1回のクエリの最大有効期間は**24 hours**です。 -- **上位N** ：表示するSQL文の数を指定します。 +- **Top N**：表示するSQL文の数を指定します。 - TiDB Cloud Premium**インスタンス**：デフォルトは**10。**オプション： **5、20、100** **。** - TiDB Cloud Essentialインスタンス：デフォルトは**10。**オプション： **5**と**20** 。 From 23239b500d4942508945115f132d796892016399 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Mon, 17 Aug 2026 15:21:37 +0900 Subject: [PATCH 2/2] i18n(ja): restore English Airbyte dropdown values Custom format / Full refresh | Overwrite MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit EN shows these as literal Airbyte UI dropdown values: "Set Destination Namespace to Custom format and set Namespace Custom Format to test" and "Choose the Sync mode to Full refresh | Overwrite." All three values (Custom format, Namespace Custom Format, test, Full refresh | Overwrite) were left in Japanese even after Destination Namespace and Sync mode's own field-name labels were fixed to English elsewhere. Also rephrased "Sync mode を Full refresh | Overwrite に選択" (unnatural を...に選択 construction) to "Sync mode で Full refresh | Overwrite を選択" per user feedback. Found while reviewing #23543. --- tidb-cloud/integrate-tidbcloud-with-airbyte.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-cloud/integrate-tidbcloud-with-airbyte.md b/tidb-cloud/integrate-tidbcloud-with-airbyte.md index 3f16f9f8e4697..48f637b7b282c 100644 --- a/tidb-cloud/integrate-tidbcloud-with-airbyte.md +++ b/tidb-cloud/integrate-tidbcloud-with-airbyte.md @@ -88,7 +88,7 @@ TiDB コネクタの詳細については、 [TiDBソース](https://docs.airbyt 5. **Destination Namespace**を**Custom format**に設定し、**Namespace Custom Format**を**test**に設定して、すべてのデータを`test`データベースに保存します。 -6. **Sync mode**を**Full refresh | Overwrite**に選択してください。 +6. **Sync mode**で**Full refresh | Overwrite**を選択してください。 > **Tip:** >