From 8793cbd56dbcb22f3eb8ef05160266005580860a Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 15 Jul 2026 14:03:12 +0900 Subject: [PATCH 1/9] =?UTF-8?q?i18n(ja):=20fix=20bit-shift=20description?= =?UTF-8?q?=20in=20bit-functions=20(=E4=BD=8D=E7=BD=AE=E5=B7=A6=E2=86=92?= =?UTF-8?q?=E5=B7=A6=E3=81=ABn=E6=A1=81,=20add=20missing=20=E3=82=92)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 (1M context) --- functions-and-operators/bit-functions-and-operators.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/functions-and-operators/bit-functions-and-operators.md b/functions-and-operators/bit-functions-and-operators.md index 835d90b1a9f34..78aff4f2100d1 100644 --- a/functions-and-operators/bit-functions-and-operators.md +++ b/functions-and-operators/bit-functions-and-operators.md @@ -204,7 +204,7 @@ SELECT CONV(b'1010' ^ b'1100',10,2); `<<`演算子は左シフト演算を実行し、数値のビットを指定された位置数だけ左にシフトし、右側の空いたビットをゼロで埋めます。 -たとえば、次のステートメントでは、 `1< Date: Wed, 15 Jul 2026 14:08:12 +0900 Subject: [PATCH 2/9] =?UTF-8?q?i18n(ja):=20add=20missing=20=E3=82=92=20(hi?= =?UTF-8?q?nt=20=E3=82=92=E4=BD=BF=E7=94=A8=20/=20=E3=82=B9=E3=83=88?= =?UTF-8?q?=E3=83=AA=E3=83=BC=E3=83=A0=E9=9B=86=E7=B4=84=E3=82=92=E5=BC=B7?= =?UTF-8?q?=E5=88=B6)=20and=20move=20ref=20to=20sentence=20end=20in=20rele?= =?UTF-8?q?ase-4.0-ga?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-Authored-By: Claude Opus 4.8 (1M context) --- releases/release-4.0-ga.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/releases/release-4.0-ga.md b/releases/release-4.0-ga.md index 2033849fa94e9..40e8478040fff 100644 --- a/releases/release-4.0-ga.md +++ b/releases/release-4.0-ga.md @@ -80,7 +80,7 @@ TiDB バージョン: 4.0.0 - `tidb_opt_agg_push_down`が有効になっていて、集計関数がパーティションテーブルをプッシュダウンしたときに、誤った処理ロジックによって発生するシステムパニックを修正しました。 [＃17328](https://github.com/pingcap/tidb/pull/17328) - 一部のケースで障害が発生した TiKV ノードにアクセスできない問題を修正[＃17342](https://github.com/pingcap/tidb/pull/17342) - `tidb.toml`の`isolation-read`設定項目が有効にならない問題を修正[＃17322](https://github.com/pingcap/tidb/pull/17322) - - `hint`使用してストリーム集約強制する場合に、処理ロジックが間違っているために出力結果の順序が間違っている問題を修正しました。 [＃17347](https://github.com/pingcap/tidb/pull/17347) + - `hint`を使用してストリーム集約を強制する場合に、処理ロジックが間違っているために出力結果の順序が間違っている問題を修正しました。 [＃17347](https://github.com/pingcap/tidb/pull/17347) - `insert`異なる`SQL_MODE` の下で DIV を処理する動作を修正 [＃17314](https://github.com/pingcap/tidb/pull/17314) - TiFlash From 78b88be9b9eefce91212f70b938111c0b4838ea3 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 21 Jul 2026 10:10:28 +0900 Subject: [PATCH 3/9] i18n(ja): remove stray number before code span (release-4.0.15) Co-Authored-By: Claude Opus 4.8 (1M context) --- releases/release-4.0.15.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/releases/release-4.0.15.md b/releases/release-4.0.15.md index fa1cfafab23f0..c5225c147cf0a 100644 --- a/releases/release-4.0.15.md +++ b/releases/release-4.0.15.md @@ -62,7 +62,7 @@ TiDB バージョン: 4.0.15 - Dumpling - テーブル情報を取得する前にスキップしたデータベースをフィルタリングして、 `SHOW TABLE STATUS` のフィルタリング効率を向上させます。 [＃337](https://github.com/pingcap/dumpling/pull/337) - - エクスポートするテーブルのテーブル情報を取得するには`SHOW FULL TABLES`使用します。3 `SHOW TABLE STATUS`一部のMySQLバージョンでは正常に動作しないためです。 [＃322](https://github.com/pingcap/dumpling/issues/322) + - エクスポートするテーブルのテーブル情報を取得するには`SHOW FULL TABLES`を使用します。これは、`SHOW TABLE STATUS`が一部のMySQLバージョンでは正常に動作しないためです。 [＃322](https://github.com/pingcap/dumpling/issues/322) - `START TRANSACTION ... WITH CONSISTENT SNAPSHOT`または`SHOW CREATE TABLE`構文をサポートしていない MySQL 互換データベースのバックアップをサポート[＃309](https://github.com/pingcap/dumpling/issues/309) - Dumpling の警告ログを改良し、ダンプが失敗したという誤解を招く情報を回避する[＃340](https://github.com/pingcap/dumpling/pull/340) From 5fddac1f2b354128d0417ce78514e2a884f00d11 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 15 Jul 2026 14:23:54 +0900 Subject: [PATCH 4/9] i18n(ja): fix garbled operator list and pushdown description in sql-tuning-best-practice (gemini review) Co-Authored-By: Claude Opus 4.8 (1M context) --- sql-tuning-best-practice.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sql-tuning-best-practice.md b/sql-tuning-best-practice.md index 9e5140d35fe3f..c5d5006c285ac 100644 --- a/sql-tuning-best-practice.md +++ b/sql-tuning-best-practice.md @@ -399,7 +399,7 @@ FROM ( 実行計画を読む際は、上から下に向かって読み進めてください。次の例では、計画ツリーのリーフノードは`TableFullScan_18`で、テーブル全体のスキャンを実行します。このスキャンで得られた行は`Selection_19`演算子によって使用され、 `ge(trips.start_date, 2017-07-01 00:00:00.000000), le(trips.start_date, 2017-07-01 23:59:59.000000)`に基づいてデータがフィルタリングされます。その後、 group-by 演算子`StreamAgg_9`によって最終的な集計`COUNT(*)`実行されます。 -これらの3つの演算子（ `TableFullScan_18` ） `Selection_19` TiKV（ `StreamAgg_9`で`cop[tikv]` ）にプッシュダウンされ、TiKVでの早期フィルタリングと集計が可能になり、TiKVとTiDB間のデータ転送が削減されます。最後に、 `TableReader_21` `StreamAgg_9`からデータを読み取り、 `StreamAgg_20`最終的な集計`count(*)`実行します。 +これらの3つの演算子（`TableFullScan_18`、`Selection_19`、`StreamAgg_9`）はTiKV（`cop[tikv]`）にプッシュダウンされ、TiKVでの早期フィルタリングと集計が可能になり、TiKVとTiDB間のデータ転送が削減されます。最後に、`TableReader_21`が`StreamAgg_9`からデータを読み取り、`StreamAgg_20`が最終的な集計`count(*)`を実行します。 ```sql EXPLAIN SELECT COUNT(*) FROM trips WHERE start_date BETWEEN '2017-07-01 00:00:00' AND '2017-07-01 23:59:59'; From 0d347a3ad0b8239381eee9ce74c3a77ef36190a1 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Wed, 15 Jul 2026 14:38:29 +0900 Subject: [PATCH 5/9] i18n(ja): address gemini review of #23273 (particles, phrasing, spaces, storage, IAM typo) Co-Authored-By: Claude Opus 4.8 (1M context) --- ai/guides/join-queries.md | 2 +- alert-rules.md | 2 +- .../tidb-partitioned-tables-best-practices.md | 2 +- best-practices/uuid.md | 2 +- br/br-pitr-manual.md | 10 +++++----- br/br-snapshot-architecture.md | 2 +- br/br-snapshot-manual.md | 2 +- develop/dev-guide-aws-appflow-integration.md | 2 +- develop/dev-guide-choose-driver-or-orm.md | 2 +- develop/dev-guide-sample-application-java-hibernate.md | 2 +- develop/dev-guide-vector-search.md | 2 +- develop/java-app-best-practices.md | 4 ++-- dm/deploy-a-dm-cluster-using-tiup-offline.md | 2 +- dm/dm-precheck.md | 2 +- dr-secondary-cluster.md | 2 +- dumpling-overview.md | 2 +- external-storage-uri.md | 6 +++--- functions-and-operators/information-functions.md | 2 +- 18 files changed, 25 insertions(+), 25 deletions(-) diff --git a/ai/guides/join-queries.md b/ai/guides/join-queries.md index 484bf97860578..19671fd844576 100644 --- a/ai/guides/join-queries.md +++ b/ai/guides/join-queries.md @@ -14,7 +14,7 @@ summary: アプリケーションで複数のテーブル結合を使用する
-すでに[TiDBに接続](/ai/guides/connect.md)使用して`TiDBClient`あると仮定します。 +すでに[TiDBに接続](/ai/guides/connect.md)し、`TiDBClient`インスタンスがあるものと仮定します。 `documents`テーブルを作成し、いくつかのサンプル データを挿入します。 diff --git a/alert-rules.md b/alert-rules.md index 3b736b346f521..e36b896c596b9 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -449,7 +449,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 1. `SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME = "tikv_gc_leader_desc"`実行して、GC リーダーに対応する`tidb-server`を見つけます。 2. `tidb-server`のログを確認し、`grep gc_worker tidb.log` を実行します。 - 3. この時間中にGCワーカーがロックを解決中（最後のログは「start resolve locks」）または範囲を削除中（最後のログは「start delete {number} ranges」）であることが確認された場合、GCプロセスは正常に動作していることを意味します。それ以外の場合は、PingCAPまたはコミュニティから[サポートを受ける](/support.md)取得してください。 + 3. この時間中にGCワーカーがロックを解決中（最後のログは「start resolve locks」）または範囲を削除中（最後のログは「start delete {number} ranges」）であることが確認された場合、GCプロセスは正常に動作していることを意味します。それ以外の場合は、PingCAPまたはコミュニティから[サポートを受けて](/support.md)ください。 ### 重大レベルのアラート {#critical-level-alerts} diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md index 590ec09b825f3..6f0cf501283c2 100644 --- a/best-practices/tidb-partitioned-tables-best-practices.md +++ b/best-practices/tidb-partitioned-tables-best-practices.md @@ -365,7 +365,7 @@ TiDBは新しい行とインデックスエントリを「右端」のリージ > > このセクションでは、読み取りおよび書き込みホットスポットを軽減するための例として、パーティションテーブルを使用します。TiDB は、 [`AUTO_INCREMENT`](/auto-increment.md)や[`SHARD_ROW_ID_BITS`](/shard-row-id-bits.md)などのホットスポット軽減のための追加機能も提供しています。 > -> 特定のシナリオでパーティションテーブルを使用する場合は、パーティション境界を維持するために`merge_option=deny`設定してください。詳細については[問題 #58128](https://github.com/pingcap/tidb/issues/58128)参照してください。 +> 特定のシナリオでパーティションテーブルを使用する場合は、パーティション境界を維持するために`merge_option=deny`を設定してください。詳細については[問題 #58128](https://github.com/pingcap/tidb/issues/58128)を参照してください。 ### パーティショニングの仕組み {#how-partitioning-works} diff --git a/best-practices/uuid.md b/best-practices/uuid.md index 612711f0681cb..900256df7a739 100644 --- a/best-practices/uuid.md +++ b/best-practices/uuid.md @@ -22,7 +22,7 @@ UUID を主キーとして使用すると、 [`AUTO_INCREMENT`](/auto-increment. ### バイナリとして保存 {#store-as-binary} -テキスト形式のUUID形式は次のようになります`ab06f63e-8fe7-11ec-a514-5405db7aad56`は36文字の文字列です。[`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md#uuid_to_bin)使用すると、テキスト形式を16バイトのバイナリ形式に変換できます。これにより、テキストを[`BINARY(16)`](/data-type-string.md#binary-type)列に格納できます。UUIDを取得する際には、 [`BIN_TO_UUID()`](/functions-and-operators/miscellaneous-functions.md#bin_to_uuid)関数を使用してテキスト形式に戻すことができます。 +テキスト形式のUUID（例えば`ab06f63e-8fe7-11ec-a514-5405db7aad56`）は36文字の文字列です。[`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md#uuid_to_bin)使用すると、テキスト形式を16バイトのバイナリ形式に変換できます。これにより、テキストを[`BINARY(16)`](/data-type-string.md#binary-type)列に格納できます。UUIDを取得する際には、 [`BIN_TO_UUID()`](/functions-and-operators/miscellaneous-functions.md#bin_to_uuid)関数を使用してテキスト形式に戻すことができます。 ### UUID形式のバイナリ順序とクラスター化された主キー {#uuid-format-binary-order-and-clustered-primary-keys} diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index 8384351938299..d95ab5eb9a056 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -77,7 +77,7 @@ Global Flags: - `task-name` : ログバックアップのタスク名を指定します。この名前は、バックアップタスクのクエリ、一時停止、再開にも使用されます。 - `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`指定します。 - `--pd` : バックアップ クラスターの PD アドレスを指定します。BRはログ バックアップ タスクを開始するために PD にアクセスする必要があります。 -- `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのstorageとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのストレージとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 使用例: @@ -349,7 +349,7 @@ Global Flags: - `--dry-run` : コマンドを実行しますが、実際にはファイルを削除しません。 - `--until` : 指定されたタイムスタンプより前のすべてのログ バックアップ データを削除します。 -- `--storage` : バックアップストレージのアドレス。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--storage` : バックアップストレージのアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 使用例: @@ -390,7 +390,7 @@ Global Flags: このコマンドはバックアップストレージにのみアクセスし、TiDB クラスターにはアクセスしません。 -`--storage`パラメータはバックアップストレージのアドレスを指定するために使用されます。現在、 BR はログバックアップのstorageとして Amazon S3、GCS、または Azure Blob Storage をサポートしています。詳細については[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +`--storage`パラメータはバックアップストレージのアドレスを指定するために使用されます。現在、 BR はログバックアップのストレージとして Amazon S3、GCS、または Azure Blob Storage をサポートしています。詳細については[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 使用例: @@ -441,7 +441,7 @@ Global Flags: 出力例には共通パラメータのみが表示されています。これらのパラメータは以下のように記述されます。 -- `--full-backup-storage` : スナップショット（フル）バックアップのストレージアドレス。PITRを使用する場合は、このパラメータを指定して、復元タイムスタンプ前の最新のスナップショットバックアップを選択します。ログバックアップデータのみを復元する場合は、このパラメータを省略できます。リカバリクラスターを初めて初期化する場合は、スナップショットバックアップを指定する必要があります。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、Azure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--full-backup-storage` : スナップショット（フル）バックアップのストレージアドレス。PITRを使用する場合は、このパラメータを指定して、復元タイムスタンプ前の最新のスナップショットバックアップを選択します。ログバックアップデータのみを復元する場合は、このパラメータを省略できます。リカバリクラスターを初めて初期化する場合は、スナップショットバックアップを指定する必要があります。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、Azure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 - `--pitr-batch-count` : ログデータを復元する際の、1バッチあたりのファイル数の上限。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。 - `--pitr-batch-size` : ログデータを復元する際の単一バッチの最大データサイズ（バイト単位）。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。 - `--pitr-concurrency` : ログ復元中の同時タスク数。各同時タスクは、一度に1バッチのログデータを復元します。 @@ -449,7 +449,7 @@ Global Flags: - `--start-ts` : ログバックアップデータを復元する開始タイムスタンプ。ログバックアップデータのみを復元する必要がある場合は、このパラメータを指定する必要があります。 - `--pd` : 復元クラスターの PD アドレス。 - `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`指定します。 -- `--storage` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのstorageとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--storage` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 使用例: diff --git a/br/br-snapshot-architecture.md b/br/br-snapshot-architecture.md index 441b8309236f4..5d5df295b02a4 100644 --- a/br/br-snapshot-architecture.md +++ b/br/br-snapshot-architecture.md @@ -160,7 +160,7 @@ sequenceDiagram ### SSTファイルの保存形式 {#storage-format-of-sst-files} - SST ファイルのストレージ形式の詳細については、 [RocksDBブロックベーステーブル形式](https://github.com/facebook/rocksdb/wiki/Rocksdb-BlockBasedTable-Format)を参照してください。 -- SST ファイルのバックアップ データのエンコード形式の詳細については、「テーブルデータ[テーブルデータのキー値へのマッピング](/tidb-computing.md#mapping-table-data-to-key-value)参照してください。 +- SST ファイルのバックアップ データのエンコード形式の詳細については、[テーブルデータのキー値へのマッピング](/tidb-computing.md#mapping-table-data-to-key-value)を参照してください。 ### バックアップファイルの構造 {#structure-of-backup-files} diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md index 28c5d01bc98b0..fa12d2f52b501 100644 --- a/br/br-snapshot-manual.md +++ b/br/br-snapshot-manual.md @@ -182,7 +182,7 @@ tiup br restore full \ 上記のコマンドでは、次のようになります。 -- `--with-sys-table` : BR は、アカウント権限データ、SQL バインディング、統計情報など、**一部のシステムテーブルのデータ**を復元します（ [統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)参照）。ただし、統計テーブル（ `mysql.stat_*` ）とシステム変数テーブル（ `mysql.tidb`および`mysql.global_variables` ）は復元されません。詳細については、 [`mysql`スキーマ内のテーブルを復元する](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema)参照してください。 +- `--with-sys-table` : BR は、アカウント権限データ、SQL バインディング、統計情報など、**一部のシステムテーブルのデータ**を復元します（ [統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)を参照）。ただし、統計テーブル（ `mysql.stat_*` ）とシステム変数テーブル（ `mysql.tidb`および`mysql.global_variables` ）は復元されません。詳細については、 [`mysql`スキーマ内のテーブルを復元する](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema)参照してください。 - `--ratelimit` : 復元タスクを実行する**TiKVあたりの**最大速度。単位はMiB/sです。 - `--log-file` : `br`ログが書き込まれる対象ファイル。 diff --git a/develop/dev-guide-aws-appflow-integration.md b/develop/dev-guide-aws-appflow-integration.md index 89bdee077d2fd..3f372a6904426 100644 --- a/develop/dev-guide-aws-appflow-integration.md +++ b/develop/dev-guide-aws-appflow-integration.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-aws-appflow-integration/','/ja/tidb/dev/dev # TiDBとAmazon AppFlowを統合する {#integrate-tidb-with-amazon-appflow} -[Amazon AppFlow](https://aws.amazon.com/appflow/) Software as a Service (SaaS) アプリケーションを AWS サービスに接続し、データを安全に転送するために使用するフルマネージド API 統合サービスです。 Amazon AppFlow を使用すると、TiDB との間で、Salesforce、Amazon S3、LinkedIn、GitHub などのさまざまなタイプのデータプロバイダーにデータをインポートおよびエクスポートできます。詳細については、AWS ドキュメントの[サポートされている送信元および送信先アプリケーション](https://docs.aws.amazon.com/appflow/latest/userguide/app-specific.html)参照してください。 +[Amazon AppFlow](https://aws.amazon.com/appflow/)は、Software as a Service (SaaS) アプリケーションを AWS サービスに接続し、データを安全に転送するために使用するフルマネージド API 統合サービスです。 Amazon AppFlow を使用すると、TiDB との間で、Salesforce、Amazon S3、LinkedIn、GitHub などのさまざまなタイプのデータプロバイダーにデータをインポートおよびエクスポートできます。詳細については、AWS ドキュメントの[サポートされている送信元および送信先アプリケーション](https://docs.aws.amazon.com/appflow/latest/userguide/app-specific.html)参照してください。 このドキュメントでは、TiDBをAmazon AppFlowと統合する方法について説明し、 TiDB Cloud Starterインスタンスの統合を例として取り上げます。 diff --git a/develop/dev-guide-choose-driver-or-orm.md b/develop/dev-guide-choose-driver-or-orm.md index 185dab7b52f6e..dcb41d176ab56 100644 --- a/develop/dev-guide-choose-driver-or-orm.md +++ b/develop/dev-guide-choose-driver-or-orm.md @@ -93,7 +93,7 @@ implementation group: 'org.bouncycastle', name: 'bcpkix-jdk15on', version: '1.67 > **Note:** > -> - 現在、Hibernate は[ネストされたトランザクションをサポートしていません](https://stackoverflow.com/questions/37927208/nested-transaction-in-spring-app-with-jpa-postgres)実行します。 +> - 現在、Hibernate は[ネストされたトランザクションをサポートしていません](https://stackoverflow.com/questions/37927208/nested-transaction-in-spring-app-with-jpa-postgres)。 > > - TiDBはv6.2.0以降、 [セーブポイント](/sql-statements/sql-statement-savepoint.md)サポートしています。5 `@Transactional` `Propagation.NESTED`トランザクション伝播オプションを使用するには、つまり`@Transactional(propagation = Propagation.NESTED)`設定するには、TiDBがv6.2.0以降であることを確認してください。 diff --git a/develop/dev-guide-sample-application-java-hibernate.md b/develop/dev-guide-sample-application-java-hibernate.md index 959fb4d88915c..c3d8c6f942391 100644 --- a/develop/dev-guide-sample-application-java-hibernate.md +++ b/develop/dev-guide-sample-application-java-hibernate.md @@ -325,7 +325,7 @@ TiDBで`CHECK`制約の適用を有効にするには、次のシステム変数 SET GLOBAL tidb_enable_check_constraint=ON; ``` -この設定がない場合、TiDB は`CHECK`制約構文を受け入れますが、それを強制しないため、予期しないデータ整合性の問題が発生する可能性があります。詳細については、 [`CHECK`制約](/constraints.md#check)参照してください。 。 +この設定がない場合、TiDB は`CHECK`制約構文を受け入れますが、それを強制しないため、予期しないデータ整合性の問題が発生する可能性があります。詳細については、 [`CHECK`制約](/constraints.md#check)を参照してください。 ## 次のステップ {#next-steps} diff --git a/develop/dev-guide-vector-search.md b/develop/dev-guide-vector-search.md index 6dd304962e9b9..1827b09edf88e 100644 --- a/develop/dev-guide-vector-search.md +++ b/develop/dev-guide-vector-search.md @@ -24,7 +24,7 @@ TiDB ベクトル検索を開始するには、次のチュートリアルを参 開発を加速させるために、TiDBベクトル検索を一般的なAIフレームワーク（LlamaIndexやLangChainなど）、埋め込みサービス（Jina AIなど）、ORMライブラリ（SQLAlchemy、Peewee、Django ORMなど）と統合できます。ニーズに最適なものを選択できます。 -詳細については[TiDB の AI 統合](/ai/integrations/vector-search-integration-overview.md)参照してください. +詳細については[TiDB の AI 統合](/ai/integrations/vector-search-integration-overview.md)を参照してください。 ## テキスト検索 {#text-search} diff --git a/develop/java-app-best-practices.md b/develop/java-app-best-practices.md index d998b339c1257..d995501a78cc3 100644 --- a/develop/java-app-best-practices.md +++ b/develop/java-app-best-practices.md @@ -252,7 +252,7 @@ hikari: - `maximumPoolSize` : プール内の最大接続数。デフォルト値は`10`です。コンテナ化された環境では、 Javaアプリケーションで使用可能な CPU コア数の 4～10 倍に設定することをお勧めします。この値を高く設定しすぎるとリソースの無駄遣いにつながり、低く設定しすぎると接続の取得が遅くなる可能性があります。 詳細については、を参照[プールのサイズについて](https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing)ください。 - `minimumIdle` : HikariCPでは、このパラメータを設定しないことを推奨します。デフォルト値は`maximumPoolSize`の値と同じで、接続プールのスケーリングを無効にします。これにより、トラフィックの急増時にも接続がすぐに利用可能になり、接続作成による遅延を回避できます。 - `connectionTimeout` : アプリケーションが接続プールから接続を取得するために待機する最大時間 (ミリ秒)。デフォルト値は`30000`ミリ秒 (30 秒) です。この時間内に利用可能な接続が得られない場合、 `SQLException`例外が発生します。 -- `maxLifetime` : プール内の接続の最大有効期間 (ミリ秒)。デフォルト値は`1800000`ミリ秒 (30 分) です。使用中の接続には影響しません。接続が閉じられた後、この設定に従って削除されます。この値を低く設定しすぎると、再接続が頻繁に発生する可能性があります。graceful [`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)使用している場合は、この値が待機時間よりも小さいことを確認してください。 +- `maxLifetime` : プール内の接続の最大有効期間 (ミリ秒)。デフォルト値は`1800000`ミリ秒 (30 分) です。使用中の接続には影響しません。接続が閉じられた後、この設定に従って削除されます。この値を低く設定しすぎると、再接続が頻繁に発生する可能性があります。[`graceful-wait-before-shutdown`](/tidb-configuration-file.md#graceful-wait-before-shutdown-new-in-v50)を使用している場合は、この値が待機時間よりも小さいことを確認してください。 - `keepaliveTime` : プール内の接続に対するキープアライブ操作の間隔 (ミリ秒)。この設定は、データベースまたはネットワークのアイドルタイムアウトによって発生する切断を防ぐのに役立ちます。デフォルト値は`120000`ミリ秒 (2 分) です。プールは、アイドル状態の接続を維持するために JDBC4 `isValid()`メソッドを使用することを優先します。 ### プローブ構成 {#probe-configuration} @@ -260,7 +260,7 @@ hikari: 接続プールは、以下のようにクライアントからTiDBへの永続的な接続を維持します。 - バージョン5.4より前のTiDBでは、デフォルトでは（エラーが報告されない限り）クライアント接続を積極的に閉じることはありません。 -- バージョン5.4以降、TiDBはデフォルトで`28800`秒（つまり`8`時間）の非アクティブ状態が続くと、クライアント接続を自動的に閉じます。このタイムアウト設定は、TiDBおよびMySQL互換の`wait_timeout`変数を使用して制御できます。詳細については、 [JDBCクエリタイムアウト](/develop/dev-guide-timeouts-in-tidb.md#jdbc-query-timeout)参照してください。 . +- バージョン5.4以降、TiDBはデフォルトで`28800`秒（つまり`8`時間）の非アクティブ状態が続くと、クライアント接続を自動的に閉じます。このタイムアウト設定は、TiDBおよびMySQL互換の`wait_timeout`変数を使用して制御できます。詳細については、 [JDBCクエリタイムアウト](/develop/dev-guide-timeouts-in-tidb.md#jdbc-query-timeout)を参照してください。 さらに、クライアントとTiDBの間には、 [LVS](https://en.wikipedia.org/wiki/Linux_Virtual_Server)や[HAProxy](https://en.wikipedia.org/wiki/HAProxy)などのネットワークプロキシが存在する場合があります。これらのプロキシは通常、特定のアイドル期間（プロキシのアイドル設定によって決定されます）が経過すると、接続を自動的にクリーンアップします。接続プールは、プロキシのアイドル設定を監視するだけでなく、キープアライブのために接続を維持またはプローブする必要もあります。 diff --git a/dm/deploy-a-dm-cluster-using-tiup-offline.md b/dm/deploy-a-dm-cluster-using-tiup-offline.md index 90d47fd8b66a3..dd61c23a9d9c4 100644 --- a/dm/deploy-a-dm-cluster-using-tiup-offline.md +++ b/dm/deploy-a-dm-cluster-using-tiup-offline.md @@ -113,7 +113,7 @@ alertmanager_servers: > > - 特定のノードで有効にするパラメータについては、このノードの`config`でこれらのパラメータを設定します。 > -> - `.`構成のサブカテゴリ（例： `log.slow-threshold`を示します。その他の形式については、 [TiUP構成テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml)参照してください。 +> - `.`は構成のサブカテゴリ（例： `log.slow-threshold`）を示します。その他の形式については、 [TiUP構成テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml)参照してください。 > > - 詳細なパラメータの説明については、 [マスター`config.toml.example`](https://github.com/pingcap/tiflow/blob/release-8.5/dm/master/dm-master.toml)と[ワーカー`config.toml.example`](https://github.com/pingcap/tiflow/blob/release-8.5/dm/worker/dm-worker.toml)参照してください。 > diff --git a/dm/dm-precheck.md b/dm/dm-precheck.md index 417f6ea170e98..f1c0f1c097dae 100644 --- a/dm/dm-precheck.md +++ b/dm/dm-precheck.md @@ -50,7 +50,7 @@ tiup dmctl check-task ./task.yaml - アップストリームのMySQLテーブルスキーマの互換性 - - アップストリームテーブルに外部キーがあるかどうかを確認してください。TiDBは外部キーをサポートしています（v8.5.0以降でGA）。また、DMはv8.5.6以降、外部キー制約を持つテーブルのレプリケーションを実験的にサポートしています。事前チェック中に、外部キーが検出された場合、DMは警告を返します。サポートされているシナリオと制限事項については、 [DM互換性カタログ](/dm/dm-compatibility-catalog.md#foreign-key-cascade-operations)参照してください。 . + - アップストリームテーブルに外部キーがあるかどうかを確認してください。TiDBは外部キーをサポートしています（v8.5.0以降でGA）。また、DMはv8.5.6以降、外部キー制約を持つテーブルのレプリケーションを実験的にサポートしています。事前チェック中に、外部キーが検出された場合、DMは警告を返します。サポートされているシナリオと制限事項については、 [DM互換性カタログ](/dm/dm-compatibility-catalog.md#foreign-key-cascade-operations)を参照してください。 - 上流のテーブルで TiDB と互換性のない文字セットが使用されていないか確認してください。詳細については、 [TiDBでサポートされている文字セット](/character-set-and-collation.md)参照してください。 diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index 2ca3e465dd058..f0abde043a021 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -412,4 +412,4 @@ storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=ht ## トラブルシューティング {#troubleshooting} -前の手順で問題が発生した場合は、まず[TiDBに関するよくある質問](/faq/faq-overview.md)で問題の解決策を見つけてください。問題が解決しない場合は、 [バグを報告する](/support.md)実行してください。 +前の手順で問題が発生した場合は、まず[TiDBに関するよくある質問](/faq/faq-overview.md)で問題の解決策を見つけてください。問題が解決しない場合は、 [バグを報告](/support.md)してください。 diff --git a/dumpling-overview.md b/dumpling-overview.md index 280abacb4720d..de0a1801ac25c 100644 --- a/dumpling-overview.md +++ b/dumpling-overview.md @@ -217,7 +217,7 @@ tiup dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test --filetype csv --sql 'se バージョン4.0.8以降、 Dumplingはクラウドストレージへのデータエクスポートをサポートしています。Amazon S3にデータをバックアップする必要がある場合は、 `-o`パラメータでAmazon S3ストレージパスを指定する必要があります。 -指定されたリージョンに Amazon S3 バケットを作成する必要があります ( [Amazonドキュメント - S3バケットの作成方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)参照)。バケット内にフォルダーを作成する必要がある場合は、 [Amazonドキュメント - フォルダの作成](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-folder.html)参照してください。 +指定されたリージョンに Amazon S3 バケットを作成する必要があります ( [Amazonドキュメント - S3バケットの作成方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)を参照)。バケット内にフォルダーを作成する必要がある場合は、 [Amazonドキュメント - フォルダの作成](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-folder.html)参照してください。 Amazon S3バックエンドストレージへのアクセス権限を持つアカウントの`SecretKey`と`AccessKey`を環境変数としてDumplingノードに渡します。 diff --git a/external-storage-uri.md b/external-storage-uri.md index 3527be1448eab..b5e1713794ac6 100644 --- a/external-storage-uri.md +++ b/external-storage-uri.md @@ -31,8 +31,8 @@ URI の基本的な形式は次のとおりです。 - `sse` : アップロードされたオブジェクトの暗号化に使用されるサーバー側暗号化アルゴリズムを指定します (値のオプション: 空、 `AES256` 、または`aws:kms` )。 - `sse-kms-key-id` : `sse` `aws:kms`に設定されている場合は KMS ID を指定します。 - `acl` : アップロードされたオブジェクトの既定 ACL を指定します (たとえば、 `private`または`authenticated-read` )。 - - `role-arn` : 指定された[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)使用してサードパーティの Amazon S3 データにアクセスする必要がある場合、 `arn:aws:iam::888888888888:role/my-role`などの`role-arn` URL クエリパラメータで、対応する[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) IAMロールを指定できます。IAMIAMを使用してサードパーティの Amazon S3 データにアクセスする方法の詳細については、 [AWSドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)参照してください。BRはv7.6.0 以降でこのパラメータをサポートしています。 - - `external-id` : サードパーティから Amazon S3 データにアクセスする場合、正しい[外部ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)指定して[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)引き受けることが必要になる場合があります。この場合、この`external-id` URL クエリパラメータを使用して外部 ID を指定し、 IAMロールを引き受けることができることを確認できます。外部 ID は、Amazon S3 データにアクセスするためにIAMロール ARN と一緒にサードパーティによって提供される任意の文字列です。IAM ロールを引き受ける場合の外部 IDのIAMIAMに外部 ID を必要としない場合は、このパラメータを指定せずにIAMロールを引き受け、対応する Amazon S3 データにアクセスできます。 + - `role-arn` : 指定された[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)使用してサードパーティの Amazon S3 データにアクセスする必要がある場合、 `arn:aws:iam::888888888888:role/my-role`などの`role-arn` URL クエリパラメータで、対応する[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) IAMロールを指定できます。IAMを使用してサードパーティの Amazon S3 データにアクセスする方法の詳細については、 [AWSドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)参照してください。BRはv7.6.0 以降でこのパラメータをサポートしています。 + - `external-id` : サードパーティから Amazon S3 データにアクセスする場合、正しい[外部ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)指定して[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)引き受けることが必要になる場合があります。この場合、この`external-id` URL クエリパラメータを使用して外部 ID を指定し、 IAMロールを引き受けることができることを確認できます。外部 ID は、Amazon S3 データにアクセスするためにIAMロール ARN と一緒にサードパーティによって提供される任意の文字列です。IAM ロールを引き受ける場合の外部 IDのIAMに外部 ID を必要としない場合は、このパラメータを指定せずにIAMロールを引き受け、対応する Amazon S3 データにアクセスできます。 以下は、 TiDB LightningおよびBRの Amazon S3 URI の例です。この例では、特定のファイルパス`testfolder`指定する必要があります。 @@ -83,7 +83,7 @@ tiup cdc:v7.5.0 cli changefeed create \ > **Note:** > > - IAMロールを自動的に作成するには、 [TiDB Cloudコンソール](https://tidbcloud.com/)でクラスターの**[Amazon S3 からのデータのインポート]**ページに移動し、 **[フォルダー URI]**フィールドに入力し、 **[ロール ARN]**フィールドの [**ここをクリックして AWS CloudFormation で新しく作成] を**クリックして、 **[新しいロール ARN の追加]**ダイアログの画面上の指示に従います。 - > - AWS CloudFormation を使用してIAMロールを作成する際に問題が発生した場合は、 **「新しいロール ARN を追加」**ダイアログで**「問題が発生した場合は、ロール ARN を手動で作成する」を**クリックしてTiDB Cloudアカウント ID とTiDB Cloud外部 ID を取得し、 [ロール ARN を使用して Amazon S3 アクセスを構成する](https://docs.pingcap.com/tidbcloud/dedicated-external-storage#configure-amazon-s3-access-using-a-role-arn)の手順に従って手動でロールを作成してください。IAMIAMを設定する際は、 **「アカウント ID」**フィールドにTiDB Cloudアカウント ID を入力し、 [混乱した副官の攻撃](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)から保護するために**外部 ID を要求する」**を選択してください。 + > - AWS CloudFormation を使用してIAMロールを作成する際に問題が発生した場合は、 **「新しいロール ARN を追加」**ダイアログで**「問題が発生した場合は、ロール ARN を手動で作成する」を**クリックしてTiDB Cloudアカウント ID とTiDB Cloud外部 ID を取得し、 [ロール ARN を使用して Amazon S3 アクセスを構成する](https://docs.pingcap.com/tidbcloud/dedicated-external-storage#configure-amazon-s3-access-using-a-role-arn)の手順に従って手動でロールを作成してください。IAMを設定する際は、 **「アカウント ID」**フィールドにTiDB Cloudアカウント ID を入力し、 [混乱した副官の攻撃](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)から保護するために**外部 ID を要求する」**を選択してください。 > - セキュリティを強化するために、**最大セッション継続時間を**短く設定することで、 IAMロールの有効期間を短縮できます。詳細については、AWSドキュメントの[ロールの最大セッション期間を更新する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-settings.html#id_roles_update-session-duration)参照してください。 - `external-id` : TiDB Cloud がAmazon S3 データにアクセスするために必要なTiDB Cloud外部 ID を指定します。この ID は、 [TiDB Cloudコンソール](https://tidbcloud.com/)の**「新しいロール ARN を追加」**ダイアログから取得できます。詳細については、 [ロール ARN を使用して Amazon S3 アクセスを構成する](https://docs.pingcap.com/tidbcloud/dedicated-external-storage#configure-amazon-s3-access-using-a-role-arn)参照してください。 diff --git a/functions-and-operators/information-functions.md b/functions-and-operators/information-functions.md index 69c4dcd077ed7..25bf11751fdf1 100644 --- a/functions-and-operators/information-functions.md +++ b/functions-and-operators/information-functions.md @@ -200,7 +200,7 @@ TABLE t1; > **注記** > -> - TiDBでは、 [`AUTO_ID_CACHE`](/auto-increment.md#auto_id_cache)指定するとMySQLが返す結果と異なる結果になる可能性があります。この不一致は、TiDBが各ノードにIDをキャッシュするため、IDの順序が乱れたり、IDに空白が生じたりする可能性があるためです。アプリケーションで厳密なID順序の維持が不可欠な場合は、 [MySQL互換モード](/auto-increment.md#mysql-compatibility-mode)有効にすることができます。 +> - TiDBでは、 [`AUTO_ID_CACHE`](/auto-increment.md#auto_id_cache)指定するとMySQLが返す結果と異なる結果になる可能性があります。この不一致は、TiDBが各ノードにIDをキャッシュするため、IDの順序が乱れたり、IDに空白が生じたりする可能性があるためです。アプリケーションで厳密なID順序の維持が不可欠な場合は、 [MySQL互換モード](/auto-increment.md#mysql-compatibility-mode)を有効にすることができます。 > > - 上の例ではIDが2ずつ増加しますが、MySQLでは同じシナリオでIDが1ずつ増加します。互換性に関する詳細は[AUTO_INCREMENT ID](/mysql-compatibility.md#auto-increment-id)参照してください。 From 88fb2cd31db106a853d408a58301ba5f71990f2e Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 21 Jul 2026 10:21:25 +0900 Subject: [PATCH 6/9] i18n(ja): harmonize lines shared with sibling i18n PRs These lines are also touched by the other open ja PRs (#23272/#23273/#23274/#23275). Each PR previously applied only its own fix, so whichever merged second would conflict. Apply the union of the fixes (stray-digit removal + particle insertion) so every branch produces identical text and merges cleanly in any order. Co-Authored-By: Claude Opus 4.8 (1M context) --- ai/guides/join-queries.md | 2 +- alert-rules.md | 2 +- best-practices/uuid.md | 2 +- br/br-pitr-manual.md | 14 +++++++------- br/br-snapshot-manual.md | 2 +- develop/dev-guide-aws-appflow-integration.md | 2 +- dm/deploy-a-dm-cluster-using-tiup-offline.md | 2 +- dr-secondary-cluster.md | 2 +- dumpling-overview.md | 2 +- external-storage-uri.md | 6 +++--- functions-and-operators/information-functions.md | 2 +- 11 files changed, 19 insertions(+), 19 deletions(-) diff --git a/ai/guides/join-queries.md b/ai/guides/join-queries.md index 19671fd844576..ff9da5a515638 100644 --- a/ai/guides/join-queries.md +++ b/ai/guides/join-queries.md @@ -14,7 +14,7 @@ summary: アプリケーションで複数のテーブル結合を使用する
-すでに[TiDBに接続](/ai/guides/connect.md)し、`TiDBClient`インスタンスがあるものと仮定します。 +`TiDBClient`を使用して、すでに[TiDBに接続](/ai/guides/connect.md)していると仮定します。 `documents`テーブルを作成し、いくつかのサンプル データを挿入します。 diff --git a/alert-rules.md b/alert-rules.md index e36b896c596b9..974b75c39d89e 100644 --- a/alert-rules.md +++ b/alert-rules.md @@ -449,7 +449,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま 1. `SELECT VARIABLE_VALUE FROM mysql.tidb WHERE VARIABLE_NAME = "tikv_gc_leader_desc"`実行して、GC リーダーに対応する`tidb-server`を見つけます。 2. `tidb-server`のログを確認し、`grep gc_worker tidb.log` を実行します。 - 3. この時間中にGCワーカーがロックを解決中（最後のログは「start resolve locks」）または範囲を削除中（最後のログは「start delete {number} ranges」）であることが確認された場合、GCプロセスは正常に動作していることを意味します。それ以外の場合は、PingCAPまたはコミュニティから[サポートを受けて](/support.md)ください。 + 3. この時間中にGCワーカーがロックを解決中（最後のログは「start resolve locks」）または範囲を削除中（最後のログは「start delete {number} ranges」）であることが確認された場合、GCプロセスは正常に動作していることを意味します。それ以外の場合は、PingCAPまたはコミュニティから[サポートを受けて](/support.md)をください。 ### 重大レベルのアラート {#critical-level-alerts} diff --git a/best-practices/uuid.md b/best-practices/uuid.md index 900256df7a739..3a5cd0de1f297 100644 --- a/best-practices/uuid.md +++ b/best-practices/uuid.md @@ -22,7 +22,7 @@ UUID を主キーとして使用すると、 [`AUTO_INCREMENT`](/auto-increment. ### バイナリとして保存 {#store-as-binary} -テキスト形式のUUID（例えば`ab06f63e-8fe7-11ec-a514-5405db7aad56`）は36文字の文字列です。[`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md#uuid_to_bin)使用すると、テキスト形式を16バイトのバイナリ形式に変換できます。これにより、テキストを[`BINARY(16)`](/data-type-string.md#binary-type)列に格納できます。UUIDを取得する際には、 [`BIN_TO_UUID()`](/functions-and-operators/miscellaneous-functions.md#bin_to_uuid)関数を使用してテキスト形式に戻すことができます。 +テキスト形式のUUID（例えば`ab06f63e-8fe7-11ec-a514-5405db7aad56`）は36文字の文字列です。[`UUID_TO_BIN()`](/functions-and-operators/miscellaneous-functions.md#uuid_to_bin)を使用すると、テキスト形式を16バイトのバイナリ形式に変換できます。これにより、テキストを[`BINARY(16)`](/data-type-string.md#binary-type)列に格納できます。UUIDを取得する際には、 [`BIN_TO_UUID()`](/functions-and-operators/miscellaneous-functions.md#bin_to_uuid)関数を使用してテキスト形式に戻すことができます。 ### UUID形式のバイナリ順序とクラスター化された主キー {#uuid-format-binary-order-and-clustered-primary-keys} diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index d95ab5eb9a056..ced768fa4dedf 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -75,9 +75,9 @@ Global Flags: - `--start-ts` : ログバックアップの開始タイムスタンプを指定します。このパラメータが指定されていない場合、バックアッププログラムは現在の時刻を`start-ts`として使用します。 - `task-name` : ログバックアップのタスク名を指定します。この名前は、バックアップタスクのクエリ、一時停止、再開にも使用されます。 -- `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`指定します。 +- `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`を指定します。 - `--pd` : バックアップ クラスターの PD アドレスを指定します。BRはログ バックアップ タスクを開始するために PD にアクセスする必要があります。 -- `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのストレージとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのストレージとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 使用例: @@ -349,7 +349,7 @@ Global Flags: - `--dry-run` : コマンドを実行しますが、実際にはファイルを削除しません。 - `--until` : 指定されたタイムスタンプより前のすべてのログ バックアップ データを削除します。 -- `--storage` : バックアップストレージのアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--storage` : バックアップストレージのアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 使用例: @@ -390,7 +390,7 @@ Global Flags: このコマンドはバックアップストレージにのみアクセスし、TiDB クラスターにはアクセスしません。 -`--storage`パラメータはバックアップストレージのアドレスを指定するために使用されます。現在、 BR はログバックアップのストレージとして Amazon S3、GCS、または Azure Blob Storage をサポートしています。詳細については[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +`--storage`パラメータはバックアップストレージのアドレスを指定するために使用されます。現在、 BR はログバックアップのストレージとして Amazon S3、GCS、または Azure Blob Storage をサポートしています。詳細については[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 使用例: @@ -441,15 +441,15 @@ Global Flags: 出力例には共通パラメータのみが表示されています。これらのパラメータは以下のように記述されます。 -- `--full-backup-storage` : スナップショット（フル）バックアップのストレージアドレス。PITRを使用する場合は、このパラメータを指定して、復元タイムスタンプ前の最新のスナップショットバックアップを選択します。ログバックアップデータのみを復元する場合は、このパラメータを省略できます。リカバリクラスターを初めて初期化する場合は、スナップショットバックアップを指定する必要があります。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、Azure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--full-backup-storage` : スナップショット（フル）バックアップのストレージアドレス。PITRを使用する場合は、このパラメータを指定して、復元タイムスタンプ前の最新のスナップショットバックアップを選択します。ログバックアップデータのみを復元する場合は、このパラメータを省略できます。リカバリクラスターを初めて初期化する場合は、スナップショットバックアップを指定する必要があります。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、Azure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 - `--pitr-batch-count` : ログデータを復元する際の、1バッチあたりのファイル数の上限。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。 - `--pitr-batch-size` : ログデータを復元する際の単一バッチの最大データサイズ（バイト単位）。このしきい値に達すると、現在のバッチは直ちに終了し、次のバッチが開始されます。 - `--pitr-concurrency` : ログ復元中の同時タスク数。各同時タスクは、一度に1バッチのログデータを復元します。 - `--restored-ts` : データを復元するタイムスタンプ。このパラメータが指定されていない場合、 BRはログバックアップで利用可能な最新のタイムスタンプ、つまりバックアップデータのチェックポイントにデータを復元します。 - `--start-ts` : ログバックアップデータを復元する開始タイムスタンプ。ログバックアップデータのみを復元する必要がある場合は、このパラメータを指定する必要があります。 - `--pd` : 復元クラスターの PD アドレス。 -- `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`指定します。 -- `--storage` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)参照してください。 +- `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`を指定します。 +- `--storage` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 使用例: diff --git a/br/br-snapshot-manual.md b/br/br-snapshot-manual.md index fa12d2f52b501..80d4ba1611d46 100644 --- a/br/br-snapshot-manual.md +++ b/br/br-snapshot-manual.md @@ -182,7 +182,7 @@ tiup br restore full \ 上記のコマンドでは、次のようになります。 -- `--with-sys-table` : BR は、アカウント権限データ、SQL バインディング、統計情報など、**一部のシステムテーブルのデータ**を復元します（ [統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)を参照）。ただし、統計テーブル（ `mysql.stat_*` ）とシステム変数テーブル（ `mysql.tidb`および`mysql.global_variables` ）は復元されません。詳細については、 [`mysql`スキーマ内のテーブルを復元する](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema)参照してください。 +- `--with-sys-table` : BR は、アカウント権限データ、SQL バインディング、統計情報など、**一部のシステムテーブルのデータ**を復元します（ [統計のバックアップ](/br/br-snapshot-manual.md#back-up-statistics)を参照）。ただし、統計テーブル（ `mysql.stat_*` ）とシステム変数テーブル（ `mysql.tidb`および`mysql.global_variables` ）は復元されません。詳細については、 [`mysql`スキーマ内のテーブルを復元する](/br/br-snapshot-guide.md#restore-tables-in-the-mysql-schema)を参照してください。 - `--ratelimit` : 復元タスクを実行する**TiKVあたりの**最大速度。単位はMiB/sです。 - `--log-file` : `br`ログが書き込まれる対象ファイル。 diff --git a/develop/dev-guide-aws-appflow-integration.md b/develop/dev-guide-aws-appflow-integration.md index 3f372a6904426..d85bfc99d68e6 100644 --- a/develop/dev-guide-aws-appflow-integration.md +++ b/develop/dev-guide-aws-appflow-integration.md @@ -6,7 +6,7 @@ aliases: ['/ja/tidb/stable/dev-guide-aws-appflow-integration/','/ja/tidb/dev/dev # TiDBとAmazon AppFlowを統合する {#integrate-tidb-with-amazon-appflow} -[Amazon AppFlow](https://aws.amazon.com/appflow/)は、Software as a Service (SaaS) アプリケーションを AWS サービスに接続し、データを安全に転送するために使用するフルマネージド API 統合サービスです。 Amazon AppFlow を使用すると、TiDB との間で、Salesforce、Amazon S3、LinkedIn、GitHub などのさまざまなタイプのデータプロバイダーにデータをインポートおよびエクスポートできます。詳細については、AWS ドキュメントの[サポートされている送信元および送信先アプリケーション](https://docs.aws.amazon.com/appflow/latest/userguide/app-specific.html)参照してください。 +[Amazon AppFlow](https://aws.amazon.com/appflow/)は、Software as a Service (SaaS) アプリケーションを AWS サービスに接続し、データを安全に転送するために使用するフルマネージド API 統合サービスです。 Amazon AppFlow を使用すると、TiDB との間で、Salesforce、Amazon S3、LinkedIn、GitHub などのさまざまなタイプのデータプロバイダーにデータをインポートおよびエクスポートできます。詳細については、AWS ドキュメントの[サポートされている送信元および送信先アプリケーション](https://docs.aws.amazon.com/appflow/latest/userguide/app-specific.html)を参照してください。 このドキュメントでは、TiDBをAmazon AppFlowと統合する方法について説明し、 TiDB Cloud Starterインスタンスの統合を例として取り上げます。 diff --git a/dm/deploy-a-dm-cluster-using-tiup-offline.md b/dm/deploy-a-dm-cluster-using-tiup-offline.md index dd61c23a9d9c4..4cb13cbd13783 100644 --- a/dm/deploy-a-dm-cluster-using-tiup-offline.md +++ b/dm/deploy-a-dm-cluster-using-tiup-offline.md @@ -113,7 +113,7 @@ alertmanager_servers: > > - 特定のノードで有効にするパラメータについては、このノードの`config`でこれらのパラメータを設定します。 > -> - `.`は構成のサブカテゴリ（例： `log.slow-threshold`）を示します。その他の形式については、 [TiUP構成テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml)参照してください。 +> - `.`は構成のサブカテゴリ（例： `log.slow-threshold`）を示します。その他の形式については、 [TiUP構成テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml)を参照してください。 > > - 詳細なパラメータの説明については、 [マスター`config.toml.example`](https://github.com/pingcap/tiflow/blob/release-8.5/dm/master/dm-master.toml)と[ワーカー`config.toml.example`](https://github.com/pingcap/tiflow/blob/release-8.5/dm/worker/dm-worker.toml)参照してください。 > diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index f0abde043a021..4e1e63283dd19 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -412,4 +412,4 @@ storage = "s3://redo?access-key=minio&secret-access-key=miniostorage&endpoint=ht ## トラブルシューティング {#troubleshooting} -前の手順で問題が発生した場合は、まず[TiDBに関するよくある質問](/faq/faq-overview.md)で問題の解決策を見つけてください。問題が解決しない場合は、 [バグを報告](/support.md)してください。 +前の手順で問題が発生した場合は、まず[TiDBに関するよくある質問](/faq/faq-overview.md)で問題の解決策を見つけてください。問題が解決しない場合は、 [バグを報告](/support.md)をしてください。 diff --git a/dumpling-overview.md b/dumpling-overview.md index de0a1801ac25c..96ed082801820 100644 --- a/dumpling-overview.md +++ b/dumpling-overview.md @@ -217,7 +217,7 @@ tiup dumpling -u root -P 4000 -h 127.0.0.1 -o /tmp/test --filetype csv --sql 'se バージョン4.0.8以降、 Dumplingはクラウドストレージへのデータエクスポートをサポートしています。Amazon S3にデータをバックアップする必要がある場合は、 `-o`パラメータでAmazon S3ストレージパスを指定する必要があります。 -指定されたリージョンに Amazon S3 バケットを作成する必要があります ( [Amazonドキュメント - S3バケットの作成方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)を参照)。バケット内にフォルダーを作成する必要がある場合は、 [Amazonドキュメント - フォルダの作成](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-folder.html)参照してください。 +指定されたリージョンに Amazon S3 バケットを作成する必要があります ( [Amazonドキュメント - S3バケットの作成方法](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-bucket.html)を参照)。バケット内にフォルダーを作成する必要がある場合は、 [Amazonドキュメント - フォルダの作成](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/create-folder.html)を参照してください。 Amazon S3バックエンドストレージへのアクセス権限を持つアカウントの`SecretKey`と`AccessKey`を環境変数としてDumplingノードに渡します。 diff --git a/external-storage-uri.md b/external-storage-uri.md index b5e1713794ac6..27b2941e6f876 100644 --- a/external-storage-uri.md +++ b/external-storage-uri.md @@ -31,8 +31,8 @@ URI の基本的な形式は次のとおりです。 - `sse` : アップロードされたオブジェクトの暗号化に使用されるサーバー側暗号化アルゴリズムを指定します (値のオプション: 空、 `AES256` 、または`aws:kms` )。 - `sse-kms-key-id` : `sse` `aws:kms`に設定されている場合は KMS ID を指定します。 - `acl` : アップロードされたオブジェクトの既定 ACL を指定します (たとえば、 `private`または`authenticated-read` )。 - - `role-arn` : 指定された[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)使用してサードパーティの Amazon S3 データにアクセスする必要がある場合、 `arn:aws:iam::888888888888:role/my-role`などの`role-arn` URL クエリパラメータで、対応する[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) IAMロールを指定できます。IAMを使用してサードパーティの Amazon S3 データにアクセスする方法の詳細については、 [AWSドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)参照してください。BRはv7.6.0 以降でこのパラメータをサポートしています。 - - `external-id` : サードパーティから Amazon S3 データにアクセスする場合、正しい[外部ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)指定して[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)引き受けることが必要になる場合があります。この場合、この`external-id` URL クエリパラメータを使用して外部 ID を指定し、 IAMロールを引き受けることができることを確認できます。外部 ID は、Amazon S3 データにアクセスするためにIAMロール ARN と一緒にサードパーティによって提供される任意の文字列です。IAM ロールを引き受ける場合の外部 IDのIAMに外部 ID を必要としない場合は、このパラメータを指定せずにIAMロールを引き受け、対応する Amazon S3 データにアクセスできます。 + - `role-arn` : 指定された[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)を使用してサードパーティの Amazon S3 データにアクセスする必要がある場合、 `arn:aws:iam::888888888888:role/my-role`などの`role-arn` URL クエリパラメータで、対応する[Amazon リソースネーム (ARN)](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html) IAMロールを指定できます。IAMを使用してサードパーティの Amazon S3 データにアクセスする方法の詳細については、 [AWSドキュメント](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)を参照してください。BRはv7.6.0 以降でこのパラメータをサポートしています。 + - `external-id` : サードパーティから Amazon S3 データにアクセスする場合、正しい[外部ID](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html)を指定して[IAMロール](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)引き受けることが必要になる場合があります。この場合、この`external-id` URL クエリパラメータを使用して外部 ID を指定し、 IAMロールを引き受けることができることを確認できます。外部 ID は、Amazon S3 データにアクセスするためにIAMロール ARN と一緒にサードパーティによって提供される任意の文字列です。IAM ロールを引き受ける場合の外部 IDのIAMに外部 ID を必要としない場合は、このパラメータを指定せずにIAMロールを引き受け、対応する Amazon S3 データにアクセスできます。 以下は、 TiDB LightningおよびBRの Amazon S3 URI の例です。この例では、特定のファイルパス`testfolder`指定する必要があります。 @@ -84,7 +84,7 @@ tiup cdc:v7.5.0 cli changefeed create \ > > - IAMロールを自動的に作成するには、 [TiDB Cloudコンソール](https://tidbcloud.com/)でクラスターの**[Amazon S3 からのデータのインポート]**ページに移動し、 **[フォルダー URI]**フィールドに入力し、 **[ロール ARN]**フィールドの [**ここをクリックして AWS CloudFormation で新しく作成] を**クリックして、 **[新しいロール ARN の追加]**ダイアログの画面上の指示に従います。 > - AWS CloudFormation を使用してIAMロールを作成する際に問題が発生した場合は、 **「新しいロール ARN を追加」**ダイアログで**「問題が発生した場合は、ロール ARN を手動で作成する」を**クリックしてTiDB Cloudアカウント ID とTiDB Cloud外部 ID を取得し、 [ロール ARN を使用して Amazon S3 アクセスを構成する](https://docs.pingcap.com/tidbcloud/dedicated-external-storage#configure-amazon-s3-access-using-a-role-arn)の手順に従って手動でロールを作成してください。IAMを設定する際は、 **「アカウント ID」**フィールドにTiDB Cloudアカウント ID を入力し、 [混乱した副官の攻撃](https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html)から保護するために**外部 ID を要求する」**を選択してください。 - > - セキュリティを強化するために、**最大セッション継続時間を**短く設定することで、 IAMロールの有効期間を短縮できます。詳細については、AWSドキュメントの[ロールの最大セッション期間を更新する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-settings.html#id_roles_update-session-duration)参照してください。 + > - セキュリティを強化するために、**最大セッション継続時間を**短く設定することで、 IAMロールの有効期間を短縮できます。詳細については、AWSドキュメントの[ロールの最大セッション期間を更新する](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_update-role-settings.html#id_roles_update-session-duration)を参照してください。 - `external-id` : TiDB Cloud がAmazon S3 データにアクセスするために必要なTiDB Cloud外部 ID を指定します。この ID は、 [TiDB Cloudコンソール](https://tidbcloud.com/)の**「新しいロール ARN を追加」**ダイアログから取得できます。詳細については、 [ロール ARN を使用して Amazon S3 アクセスを構成する](https://docs.pingcap.com/tidbcloud/dedicated-external-storage#configure-amazon-s3-access-using-a-role-arn)参照してください。 diff --git a/functions-and-operators/information-functions.md b/functions-and-operators/information-functions.md index 25bf11751fdf1..2bc2ccff33fb9 100644 --- a/functions-and-operators/information-functions.md +++ b/functions-and-operators/information-functions.md @@ -200,7 +200,7 @@ TABLE t1; > **注記** > -> - TiDBでは、 [`AUTO_ID_CACHE`](/auto-increment.md#auto_id_cache)指定するとMySQLが返す結果と異なる結果になる可能性があります。この不一致は、TiDBが各ノードにIDをキャッシュするため、IDの順序が乱れたり、IDに空白が生じたりする可能性があるためです。アプリケーションで厳密なID順序の維持が不可欠な場合は、 [MySQL互換モード](/auto-increment.md#mysql-compatibility-mode)を有効にすることができます。 +> - TiDBでは、 [`AUTO_ID_CACHE`](/auto-increment.md#auto_id_cache)を指定するとMySQLが返す結果と異なる結果になる可能性があります。この不一致は、TiDBが各ノードにIDをキャッシュするため、IDの順序が乱れたり、IDに空白が生じたりする可能性があるためです。アプリケーションで厳密なID順序の維持が不可欠な場合は、 [MySQL互換モード](/auto-increment.md#mysql-compatibility-mode)を有効にすることができます。 > > - 上の例ではIDが2ずつ増加しますが、MySQLでは同じシナリオでIDが1ずつ増加します。互換性に関する詳細は[AUTO_INCREMENT ID](/mysql-compatibility.md#auto-increment-id)参照してください。 From fb804b7439aebddd4d276cad5a523312ea2707e8 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 21 Jul 2026 11:05:17 +0900 Subject: [PATCH 7/9] i18n(ja): fix partial negation in vector-search-index MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit EN: "this method is not fully accurate" is a partial negation, but "完全に正確ではありません" reads as a full negation in Japanese (完全に modifying the negation itself). Insert は — 完全には正確ではありません — the standard Japanese device for scoping the negation. Co-Authored-By: Claude Opus 4.8 (1M context) --- ai/reference/vector-search-index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md index d85170f30e6aa..4e64fabddda4f 100644 --- a/ai/reference/vector-search-index.md +++ b/ai/reference/vector-search-index.md @@ -144,7 +144,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES; 詳細については[`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md)参照してください。 -さらに、 `ADMIN SHOW DDL JOBS;`実行して`row count`を確認することで、DDLジョブの実行進捗状況を監視できます。ただし、 `row count`値は`TIFLASH_INDEXES`の`rows_stable_indexed`フィールドから取得されるため、この方法は完全に正確ではありません。この方法は、インデックス作成の進捗状況を追跡するための参照として使用できます。 +さらに、 `ADMIN SHOW DDL JOBS;`を実行して`row count`を確認することで、DDLジョブの実行進捗状況を監視できます。ただし、 `row count`値は`TIFLASH_INDEXES`の`rows_stable_indexed`フィールドから取得されるため、この方法は完全には正確ではありません。この方法は、インデックス作成の進捗状況を追跡するための参照として使用できます。 ## ベクトルインデックスが使用されているかどうかを確認する {#check-whether-the-vector-index-is-used} From 927458c186329b08dfd21bacce56b02e6bfcffd8 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 21 Jul 2026 11:21:01 +0900 Subject: [PATCH 8/9] i18n(ja): restore the dropped WHERE code span in benchmark-tidb-using-ch MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Machine translation lost one of the two `WHERE` code spans and left a numeric placeholder in its place, while duplicating the other: EN: ... in which the `WHERE` clause is used to specify ... remove the `WHERE` clause from the statement. JA: ... 3 句は、確認するデータベースとテーブルを指定します。 ... ステートメントから`WHERE`句`WHERE`削除します。 Deleting the stray 3 alone would leave the clause without its subject, so restore `WHERE` at the first position and drop the duplicate at the second. Co-Authored-By: Claude Opus 4.8 (1M context) --- benchmark/benchmark-tidb-using-ch.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/benchmark/benchmark-tidb-using-ch.md b/benchmark/benchmark-tidb-using-ch.md index f1cc155bef27b..66f151af2fa32 100644 --- a/benchmark/benchmark-tidb-using-ch.md +++ b/benchmark/benchmark-tidb-using-ch.md @@ -62,7 +62,7 @@ TiFlashをデプロイした後、 TiFlash はTiKV データを自動的に複 ALTER DATABASE tpcc SET tiflash replica 2; -`tpcc`データベース内のすべてのテーブルのレプリケーションが完了しているかどうかを確認するには、次のステートメントを実行します。3 句は、確認するデータベースとテーブルを指定します。すべてのデータベースのレプリケーション状態を確認する場合は、ステートメントから`WHERE`句`WHERE`削除します。 +`tpcc`データベース内のすべてのテーブルのレプリケーションが完了しているかどうかを確認するには、次のステートメントを実行します。`WHERE`句は、確認するデータベースとテーブルを指定します。すべてのデータベースのレプリケーション状態を確認する場合は、ステートメントから`WHERE`句を削除します。 ```sql SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = 'tpcc'; From 5f278dca7bd85a46b1e3fe954a2feb8d08cc7cd4 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 21 Jul 2026 14:38:23 +0900 Subject: [PATCH 9/9] i18n(ja): fix three mistranslations found during the MT sweep MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - tidb-cloud/sql-concepts.md: 「30 千」 is not Japanese; EN says "30 thousand" -> 3 万. - dr-solution-introduction.md: "second-level RPO" was read as an ordinal (第 2 レベル) instead of a unit of time -> 秒単位の RPO. - notification-2023-09-26-console-maintenance.md: "Scale clusters" kept English word order (スケールクラスター) while every sibling bullet uses クラスターを…する. Co-Authored-By: Claude Opus 4.8 (1M context) --- ai/reference/vector-search-index.md | 2 +- br/br-pitr-manual.md | 4 ++-- dr-solution-introduction.md | 2 +- sql-statements/sql-statement-admin-checksum-table.md | 2 +- .../releases/notification-2023-09-26-console-maintenance.md | 4 ++-- tidb-cloud/sql-concepts.md | 2 +- 6 files changed, 8 insertions(+), 8 deletions(-) diff --git a/ai/reference/vector-search-index.md b/ai/reference/vector-search-index.md index 4e64fabddda4f..46cc58a09b8f2 100644 --- a/ai/reference/vector-search-index.md +++ b/ai/reference/vector-search-index.md @@ -144,7 +144,7 @@ SELECT * FROM INFORMATION_SCHEMA.TIFLASH_INDEXES; 詳細については[`ALTER TABLE ... COMPACT`](/sql-statements/sql-statement-alter-table-compact.md)参照してください。 -さらに、 `ADMIN SHOW DDL JOBS;`を実行して`row count`を確認することで、DDLジョブの実行進捗状況を監視できます。ただし、 `row count`値は`TIFLASH_INDEXES`の`rows_stable_indexed`フィールドから取得されるため、この方法は完全には正確ではありません。この方法は、インデックス作成の進捗状況を追跡するための参照として使用できます。 +さらに、 `ADMIN SHOW DDL JOBS;`を実行して`row count`を確認することで、DDLジョブの実行進捗状況を監視できます。ただし、 `row count`の値は`TIFLASH_INDEXES`の`rows_stable_indexed`フィールドから取得されるため、この方法は完全には正確ではありません。この方法は、インデックス作成の進捗状況を追跡するための参照として使用できます。 ## ベクトルインデックスが使用されているかどうかを確認する {#check-whether-the-vector-index-is-used} diff --git a/br/br-pitr-manual.md b/br/br-pitr-manual.md index ced768fa4dedf..e104f6037d8db 100644 --- a/br/br-pitr-manual.md +++ b/br/br-pitr-manual.md @@ -75,7 +75,7 @@ Global Flags: - `--start-ts` : ログバックアップの開始タイムスタンプを指定します。このパラメータが指定されていない場合、バックアッププログラムは現在の時刻を`start-ts`として使用します。 - `task-name` : ログバックアップのタスク名を指定します。この名前は、バックアップタスクのクエリ、一時停止、再開にも使用されます。 -- `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`を指定します。 +- `--ca` 、 `--cert` 、 `--key` : TiKVおよびPDと通信するためのmTLS暗号化方式を指定します。 - `--pd` : バックアップ クラスターの PD アドレスを指定します。BRはログ バックアップ タスクを開始するために PD にアクセスする必要があります。 - `--storage` : バックアップストレージのアドレスを指定します。現在、 BRはログバックアップのストレージとしてAmazon S3、Google Cloud Storage (GCS)、またはAzure Blob Storageをサポートしています。上記のコマンドではAmazon S3を例として使用しています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 @@ -448,7 +448,7 @@ Global Flags: - `--restored-ts` : データを復元するタイムスタンプ。このパラメータが指定されていない場合、 BRはログバックアップで利用可能な最新のタイムスタンプ、つまりバックアップデータのチェックポイントにデータを復元します。 - `--start-ts` : ログバックアップデータを復元する開始タイムスタンプ。ログバックアップデータのみを復元する必要がある場合は、このパラメータを指定する必要があります。 - `--pd` : 復元クラスターの PD アドレス。 -- `--ca` : TiKVおよびPDと通信`--key`ためのmTLS暗号化方式`--cert`を指定します。 +- `--ca` 、 `--cert` 、 `--key` : TiKVおよびPDと通信するためのmTLS暗号化方式を指定します。 - `--storage` : ログバックアップのストレージアドレス。現在、 BRはログバックアップのストレージとしてAmazon S3、GCS、またはAzure Blob Storageをサポートしています。詳細は[外部ストレージサービスのURI形式](/external-storage-uri.md)を参照してください。 使用例: diff --git a/dr-solution-introduction.md b/dr-solution-introduction.md index ddf089b95b4f4..0356da25cecf6 100644 --- a/dr-solution-introduction.md +++ b/dr-solution-introduction.md @@ -65,7 +65,7 @@ TiDBのバックアップおよび復元ツールとして、 BRは特定の時 前述のアーキテクチャは、2つのTiDBクラスタで構成されています。クラスタ1はリージョン1で動作し、読み取りおよび書き込み要求を処理します。クラスタ2はリージョン2で動作し、セカンダリクラスタとして機能します。クラスタ1で障害が発生した場合、クラスタ2がサービスを引き継ぎます。データ変更は、TiCDCを使用して2つのクラスタ間で複製されます。このアーキテクチャは、「1対1」の災害復旧ソリューションとも呼ばれます。 -このアーキテクチャはシンプルで可用性が高く、領域レベルのエラー許容目標、スケーラブルな書き込み機能、第 2 レベルの RPO、分単位以下の RTO を備えています。本番システムで RPO をゼロにする必要がない場合は、この DR ソリューションをお勧めします。このソリューションの詳細については、[プライマリおよびセカンダリクラスタに基づくDRソリューション](/dr-secondary-cluster.md)参照してください。 +このアーキテクチャはシンプルで可用性が高く、領域レベルのエラー許容目標、スケーラブルな書き込み機能、秒単位の RPO、分単位以下の RTO を備えています。本番システムで RPO をゼロにする必要がない場合は、この DR ソリューションをお勧めします。このソリューションの詳細については、[プライマリおよびセカンダリクラスタに基づくDRソリューション](/dr-secondary-cluster.md)を参照してください。 ### 単一クラスター内の複数のレプリカに基づく災害復旧ソリューション {#dr-solution-based-on-multiple-replicas-in-a-single-cluster} diff --git a/sql-statements/sql-statement-admin-checksum-table.md b/sql-statements/sql-statement-admin-checksum-table.md index c4aa08b6ebed1..92cbdc502d937 100644 --- a/sql-statements/sql-statement-admin-checksum-table.md +++ b/sql-statements/sql-statement-admin-checksum-table.md @@ -12,7 +12,7 @@ category: reference [チェックサム](/tidb-lightning/tidb-lightning-glossary.md#checksum) 、テーブルのデータと`table_id`などのプロパティに基づいて計算されます。つまり、同じデータを持ちながらも`table_id`値が異なる 2 つのテーブルでは、チェックサムは異なります。 -[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 、 [TiDB Data Migration](/dm/dm-overview.md) 、または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE `実行されます。 +[TiDB Lightning](/tidb-lightning/tidb-lightning-overview.md) 、 [TiDB Data Migration](/dm/dm-overview.md) 、または[`IMPORT INTO`](/sql-statements/sql-statement-import-into.md)を使用してテーブルをインポートした後、データの整合性を検証するためにデフォルトで`ADMIN CHECKSUM TABLE
`が実行されます。 diff --git a/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md b/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md index 4845364d21f85..85d1a42be729a 100644 --- a/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md +++ b/tidb-cloud/releases/notification-2023-09-26-console-maintenance.md @@ -32,8 +32,8 @@ TiDB Cloud Starterの管理インフラストラクチャをアップグレー - クラスタ管理 - クラスターを作成する - クラスターを削除する - - スケールクラスター - - クラスターをビュー + - クラスターをスケールする + - クラスターを表示する - クラスターを一時停止または再開する - クラスターのパスワードを変更する - クラスタートラフィックフィルターを変更する diff --git a/tidb-cloud/sql-concepts.md b/tidb-cloud/sql-concepts.md index 7a84dbb516022..06b9d0cd8712d 100644 --- a/tidb-cloud/sql-concepts.md +++ b/tidb-cloud/sql-concepts.md @@ -47,7 +47,7 @@ TiDBは、行IDの生成とデータ配信を最適化するための3つのSQL `AUTO_INCREMENT`は、列のデフォルト値を自動的に入力するために使用される列属性です。 `INSERT`ステートメントで`AUTO_INCREMENT`列の値が指定されていない場合、システムはこの列に値を自動的に割り当てます。 -パフォーマンス上の理由から、 `AUTO_INCREMENT`番号は、各 TiDBサーバーに値のバッチ (デフォルトでは 30 千) で割り当てられます。つまり、 `AUTO_INCREMENT`番号は一意であることが保証されますが、 `INSERT`ステートメントに割り当てられる値は、TiDBサーバーごとに単調増加になります。 +パフォーマンス上の理由から、 `AUTO_INCREMENT`番号は、各 TiDBサーバーに値のバッチ (デフォルトでは 3 万) で割り当てられます。つまり、 `AUTO_INCREMENT`番号は一意であることが保証されますが、 `INSERT`ステートメントに割り当てられる値は、TiDBサーバーごとに単調増加になります。 すべての TiDB サーバーで`AUTO_INCREMENT`の数値を単調増加にしたい場合、また TiDB のバージョンが v6.5.0 以降の場合は、[MySQL互換モード](/auto-increment.md#mysql-compatibility-mode)を有効にすることをお勧めします。