From 665bae56d9b7f3af3c5e011112642ef2daf9b537 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:07:18 +0900
Subject: [PATCH 01/34] i18n(ja): fix mistranslated heading and dropped
 negation in best-practices
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- saas-best-practices.md: "Use stale read carefully" mistranslated as
  "read old things carefully" -- confuses the Stale Read feature name
  with generic "old things", contradicting the correct term used in
  the very next paragraph.
- tidb-partitioned-tables-best-practices.md: a dropped negation
  flipped "non-partitioned table" into "partitioned table" directly
  contradicting the section's own heading right above it; 3 more
  sites in a comparison list/table/details-summary where "Non-
  partitioned table" was rendered as bare パーティションテーブル,
  indistinguishable from its "partitioned" sibling rows; a severely
  scrambled recommendation sentence with a stray unclosed
  "（パーティション番号" fragment with no basis in EN.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/saas-best-practices.md                  |  2 +-
 .../tidb-partitioned-tables-best-practices.md          | 10 +++++-----
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/best-practices/saas-best-practices.md b/best-practices/saas-best-practices.md
index f3e7fc44ff520..cd0312ff1ea5e 100644
--- a/best-practices/saas-best-practices.md
+++ b/best-practices/saas-best-practices.md
@@ -80,7 +80,7 @@ SaaSマルチテナントシナリオでは、通常、各ユーザーはTiDBに
 - TiDBのメモリ使用量は接続数にほぼ比例します。実際のテストでは、アイドル接続が20万件あると、TiDBのメモリ使用量が約30GiB増加しました。実際の接続数に基づいて、TiDBのメモリ仕様を増やすことをお勧めします。
 - `PREPARED`ステートメントを使用する場合、各接続はセッションレベルのプリペアドプランキャッシュを維持します。`DEALLOCATE`文が長時間実行されない場合、キャッシュに過剰なプランが蓄積され、メモリ使用量が増加する可能性があります。実際のテストでは、 `IndexRangeScan`を含む 400,000 の実行計画で約 5 GiB のメモリが消費されました。これに応じてメモリ仕様を増やすことをお勧めします。
 
-## 古いものを使用するには、慎重に読んでください {#use-stale-read-carefully}
+## ステイル読み取りは慎重に使用してください {#use-stale-read-carefully}
 
 [ステイル読み取り](/stale-read.md)を使用すると、古いスキーマバージョンによって過去のスキーマがフルロードされ、パフォーマンスに重大な影響を与える可能性があります。この問題を軽減するには、 [`tidb_schema_version_cache_limit`](/system-variables.md#tidb_schema_version_cache_limit-new-in-v740)の値を（例えば`255`に）増やしてください。
 
diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md
index bda9c4e031abf..a3be9076c2913 100644
--- a/best-practices/tidb-partitioned-tables-best-practices.md
+++ b/best-practices/tidb-partitioned-tables-best-practices.md
@@ -51,7 +51,7 @@ TiDBでは、パーティションテーブルはデフォルトでローカル
 
 このテストでは、次のテーブル構成間でのクエリパフォーマンスを比較します。
 
-- パーティションテーブル
+- 非パーティションテーブル
 - ローカルインデックスを持つパーティションテーブル
 - グローバルインデックスを持つパーティションテーブル
 
@@ -116,7 +116,7 @@ WHERE `fa`.`sid` IN (
 
 | コンフィグレーション                | 平均クエリ時間 | COP タスク（インデックススキャン） | COP タスク（テーブル検索） | COP タスクの合計 |
 | ------------------------- | ------- | ------------------ | ------------- | -------- |
-| パーティションテーブル               | 12.6ミリ秒 | 72                 | 79            | 151      |
+| 非パーティションテーブル              | 12.6ミリ秒 | 72                 | 79            | 151      |
 | ローカルインデックスを持つパーティションテーブル  | 108ミリ秒  | 600                | 375           | 975      |
 | グローバルインデックスを持つパーティションテーブル | 14.8ミリ秒 | 69                 | 383           | 452      |
 
@@ -133,7 +133,7 @@ WHERE `fa`.`sid` IN (
 
 次の例は、各構成の実行計画を示しています。
 
-<details><summary><b>パーティションテーブル</b></summary>
+<details><summary><b>非パーティションテーブル</b></summary>
 
 ```
 | id                        | estRows | estCost   | actRows | task      | access object                        | execution info | operator info | memory   | disk |
@@ -319,7 +319,7 @@ ALTER TABLE ad_cache LAST PARTITION LESS THAN ("${nextTimestamp}");
 
 #### 推奨事項 {#recommendations}
 
-- 大規模なデータクリーンアップや時間ベースのデータクリーンアップには、パーティション分割テーブル（パーティション番号`DROP PARTITION`を使用してください。このアプローチにより、パフォーマンスが向上し、システムへの影響が軽減され、操作が簡素化されます。
+- 大規模または時間ベースのデータクリーンアップには、 `DROP PARTITION`を使用したパーティション分割テーブルを使用してください。このアプローチにより、パフォーマンスが向上し、システムへの影響が軽減され、操作が簡素化されます。
 - きめ細かいデータクリーンアップやバックグラウンドデータクリーンアップにはTTLを使用してください。TTLは、書き込みスループットが高いワークロードや、大量のデータを迅速に削除するワークロードには適していません。
 
 ### パーティション削除の効率: ローカルインデックスとグローバルインデックス {#partition-drop-efficiency-local-indexes-vs-global-indexes}
@@ -379,7 +379,7 @@ TiDBはテーブルデータとインデックスをリージョンに保存し
 
 **パーティション化されていないテーブル**
 
-パーティションテーブルでは、新しい行は常に最大のキー値を持ち、同じ「最後の」リージョンに書き込まれます。この単一のリージョンは、1つのTiKVノードによって処理されるため、書き込みのボトルネックになる可能性があります。
+パーティション化されていないテーブルでは、新しい行は常に最大のキー値を持ち、同じ「最後の」リージョンに書き込まれます。この単一のリージョンは、1つのTiKVノードによって処理されるため、書き込みのボトルネックになる可能性があります。
 
 **ハッシュまたはキーでパーティション分割されたテーブル**
 

From 806722c13db4c962bd33ce617c12b62f6979ad6f Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:07:46 +0900
Subject: [PATCH 02/34] i18n(ja): fix 2 more dropped-particle sites in
 tidb-partitioned-tables-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Found during review: missing を before 定期的に更新する and before
サポートしていません.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/tidb-partitioned-tables-best-practices.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md
index a3be9076c2913..b94337e60e2df 100644
--- a/best-practices/tidb-partitioned-tables-best-practices.md
+++ b/best-practices/tidb-partitioned-tables-best-practices.md
@@ -310,7 +310,7 @@ FIRST PARTITION LESS THAN ('2025-02-19 18:00:00')
 LAST PARTITION LESS THAN ('2025-02-19 20:00:00');
 ```
 
-`FIRST PARTITION`と`LAST PARTITION`定期的に更新するには、次のようなDDL文を実行します。これらの文は古いパーティションを削除し、新しいパーティションを作成します。
+`FIRST PARTITION`と`LAST PARTITION`を定期的に更新するには、次のようなDDL文を実行します。これらの文は古いパーティションを削除し、新しいパーティションを作成します。
 
 ```sql
 ALTER TABLE ad_cache FIRST PARTITION LESS THAN ("${nextTimestamp}");
@@ -428,7 +428,7 @@ PARTITION BY KEY (id) PARTITIONS 16;
     SELECT * FROM server_info WHERE `serial_no` = ?;
     ```
 
-- パーティションキーを使用しないクエリのスキャンオーバーヘッドを削減するには、グローバルインデックスを作成する必要があります。グローバルインデックスは`DROP PARTITION`操作を遅くする可能性がありますが、ハッシュおよびキーパーティションテーブルは`DROP PARTITION`サポートしていません。したがって、これらのパーティションはほとんど切り捨てられないため、グローバルインデックスは実用的なソリューションです。例：
+- パーティションキーを使用しないクエリのスキャンオーバーヘッドを削減するには、グローバルインデックスを作成する必要があります。グローバルインデックスは`DROP PARTITION`操作を遅くする可能性がありますが、ハッシュおよびキーパーティションテーブルは`DROP PARTITION`をサポートしていません。したがって、これらのパーティションはほとんど切り捨てられないため、グローバルインデックスは実用的なソリューションです。例：
 
     ```sql
     ALTER TABLE server_info ADD UNIQUE INDEX(serial_no, id) GLOBAL;

From 5b23255b5bd144f305b69284be629c8e0f330845 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:08:41 +0900
Subject: [PATCH 03/34] i18n(ja): fix nonsensical term, reversed table/column
 names, and dropped particles in tidb-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- "load balancing" mistranslated as "Raftバランシング" (nonsensical),
  contradicting the correctly-translated ロードバランシング heading
  later in the same file.
- Table `t` and column `c` swapped in an example, self-contradicting
  the SQL statement shown in the same sentence.
- A false-friend translation of "on 2017-05-26" as "2017-05-26上の"
  (spatially "on top of" rather than "on that date").
- 2 dropped を particles.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/tidb-best-practices.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md
index b38dfe42961de..f81d688f5f5c9 100644
--- a/best-practices/tidb-best-practices.md
+++ b/best-practices/tidb-best-practices.md
@@ -22,7 +22,7 @@ TiDBは、MySQLのプロトコルと構文に対応した分散データベー
 
 ## 基本概念 {#basic-concepts}
 
-ベストプラクティスは、その実装原則と密接に関連しています。Raftコンセンサスアルゴリズム、分散トランザクション、データシャーディング、Raftバランシング、SQLからキーバリュー（KV）へのマッピングソリューション、セカンダリインデックスの実装方法、分散実行エンジンなど、基本的なメカニズムを習得することをお勧めします。
+ベストプラクティスは、その実装原則と密接に関連しています。Raftコンセンサスアルゴリズム、分散トランザクション、データシャーディング、ロードバランシング、SQLからキーバリュー（KV）へのマッピングソリューション、セカンダリインデックスの実装方法、分散実行エンジンなど、基本的なメカニズムを習得することをお勧めします。
 
 このセクションでは、これらの概念について説明します。詳細については、 [PingCAPのブログ記事](https://pingcap.com/blog/)を参照してください。
 
@@ -108,7 +108,7 @@ MySQLで培った多くの経験は、TiDBにも応用できます。ただし
 
     以下の2つの条件では、2回のアクセスという問題は発生しません。
 
-    - インデックスの列は既にクエリの要件を満たしています。 `c`テーブルの`t`列にインデックスがあり、クエリが`select c from t where c > 10;`であると仮定します。このとき、インデックスにアクセスすれば必要なすべてのデータを取得できます。この状況は`Covering Index`と呼ばれます。しかし、クエリのパフォーマンスに重点を置く場合は、フィルタリングする必要はないがクエリ結果で返す必要がある列の一部をインデックスに入れ、複合インデックスを作成できます。 `select c1, c2 from t where c1 > 10;`例にとります。複合インデックス`Index c12 (c1, c2)`を作成することで、このクエリを最適化できます。
+    - インデックスの列は既にクエリの要件を満たしています。 `t`テーブルの`c`列にインデックスがあり、クエリが`select c from t where c > 10;`であると仮定します。このとき、インデックスにアクセスすれば必要なすべてのデータを取得できます。この状況は`Covering Index`と呼ばれます。しかし、クエリのパフォーマンスに重点を置く場合は、フィルタリングする必要はないがクエリ結果で返す必要がある列の一部をインデックスに入れ、複合インデックスを作成できます。 `select c1, c2 from t where c1 > 10;`を例にとります。複合インデックス`Index c12 (c1, c2)`を作成することで、このクエリを最適化できます。
 
     - テーブルの主キーは整数型です。この場合、TiDBは主キーの値を行IDとして使用します。したがって、クエリ条件が主キーに基づいている場合は、行IDの範囲を直接構築し、テーブルデータをスキャンして結果を取得できます。
 
@@ -160,9 +160,9 @@ TiDBクラスタのデプロイには[TiUP](/production-deployment-using-tiup.md
 
 `INSERT` 、 `UPDATE` 、 `DELETE`のいずれのステートメントであっても、ステートメントをバッチに分割するか、ステートメントに制限を追加することをお勧めします。
 
-大量のデータを削除する場合は、 `Delete from t where xx limit 5000;`を使用することをお勧めします。これはループを通して削除を行い、 `Affected Rows == 0`条件としてループを終了します。
+大量のデータを削除する場合は、 `Delete from t where xx limit 5000;`を使用することをお勧めします。これはループを通して削除を行い、 `Affected Rows == 0`を条件としてループを終了します。
 
-一度に削除する必要のあるデータ量が多い場合、各削除が逆方向にたどるため、このループ方式はどんどん遅くなります。前のデータを削除した後、削除済みフラグが短時間残り（その後、ガベージコレクションによってすべてクリアされます）、次の`DELETE`文に影響を与えます。可能であれば、 `WHERE`条件を改良することをお勧めします。 `2017-05-26`上のすべてのデータを削除する必要がある場合は、次のステートメントを使用できます。
+一度に削除する必要のあるデータ量が多い場合、各削除が逆方向にたどるため、このループ方式はどんどん遅くなります。前のデータを削除した後、削除済みフラグが短時間残り（その後、ガベージコレクションによってすべてクリアされます）、次の`DELETE`文に影響を与えます。可能であれば、 `WHERE`条件を改良することをお勧めします。 `2017-05-26`のすべてのデータを削除する必要がある場合は、次のステートメントを使用できます。
 
 ```sql
 for i from 0 to 23:

From 05a805bd2fe1c2b69859e13b6e01ac3a9ebb59ff Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:09:55 +0900
Subject: [PATCH 04/34] i18n(ja): fix false friends, MT duplication, and
 dropped particles in best-practices-on-public-cloud.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- "cordoned node" (a Kubernetes term for marked-unschedulable)
  mistranslated as 切断された (disconnected); also restored the
  dropped "by cordoning it" mechanism from the preceding sentence.
- "watching script" mistranslated as スクリプトを見る (literally
  "look at the script") instead of 監視スクリプト, which the same
  file already uses correctly a few lines later.
- 3 sites of a recurring MT-duplication artifact ("Raft Raft Engine").
- 文/ステートメント inconsistency for "insert statements" within one
  bullet list.
- Several dropped particles (は x3, を x2, が x1) found while fixing
  the above, including one creating a run-on sentence.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/best-practices-on-public-cloud.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md
index e3c0ea4c46e4a..815a1ee1beecc 100644
--- a/best-practices/best-practices-on-public-cloud.md
+++ b/best-practices/best-practices-on-public-cloud.md
@@ -45,7 +45,7 @@ compression-per-level = ["zstd", "zstd", "zstd", "zstd", "zstd", "zstd", "zstd"]
 
 ## Raft Engine専用のディスクを使用する {#use-a-dedicated-disk-for-raft-engine}
 
-TiKVの[Raft Engine](/glossary.md#raft-engine) 、従来のデータベースにおける先行書き込みログ（WAL）と同様の重要な役割を果たします。最適なパフォーマンスと安定性を実現するには、パブリッククラウドにTiDBをデプロイする際に、 Raft Engine専用のディスクを割り当てることが不可欠です。次の`iostat` 、書き込み負荷の高いワークロードにおけるTiKVノードのI/O特性を示しています。
+TiKVの[Raft Engine](/glossary.md#raft-engine)は、従来のデータベースにおける先行書き込みログ（WAL）と同様の重要な役割を果たします。最適なパフォーマンスと安定性を実現するには、パブリッククラウドにTiDBをデプロイする際に、 Raft Engine専用のディスクを割り当てることが不可欠です。次の`iostat`は、書き込み負荷の高いワークロードにおけるTiKVノードのI/O特性を示しています。
 
 ```
 Device            r/s     rkB/s       w/s     wkB/s      f/s  aqu-sz  %util
@@ -53,7 +53,7 @@ sdb           1649.00 209030.67   1293.33 304644.00    13.33    5.09  48.37
 sdd           1033.00   4132.00   1141.33  31685.33   571.00    0.94 100.00
 ```
 
-デバイス`sdb`はKV RocksDBに使用され、 `sdd` Raft Engineのログを復元するために使用されます`sdd`には、デバイスの1秒あたりのフラッシュリクエスト完了数を表す`f/s`値が大幅に高いことに注目してください。Raft Raft Engineでは、バッチ内の書き込みが同期としてマークされている場合、バッチリーダーは書き込み後に`fdatasync()`呼び出し、バッファリングされたデータがストレージにフラッシュされることを保証します。Raft Raft Engine専用のディスクを使用することで、TiKVはリクエストの平均キュー長を短縮し、最適で安定した書き込みレイテンシーを保証します。
+デバイス`sdb`はKV RocksDBに使用され、 `sdd`はRaft Engineのログを復元するために使用されます。 `sdd`には、デバイスの1秒あたりのフラッシュリクエスト完了数を表す`f/s`値が大幅に高いことに注目してください。Raft Engineでは、バッチ内の書き込みが同期としてマークされている場合、バッチリーダーは書き込み後に`fdatasync()`を呼び出し、バッファリングされたデータがストレージにフラッシュされることを保証します。Raft Engine専用のディスクを使用することで、TiKVはリクエストの平均キュー長を短縮し、最適で安定した書き込みレイテンシーを保証します。
 
 クラウドプロバイダーによって、IOPSやMBPSなどのパフォーマンス特性が異なる様々なディスクタイプが提供されています。そのため、ワークロードに応じて適切なクラウドプロバイダー、ディスクタイプ、ディスクサイズを選択することが重要です。
 
@@ -67,7 +67,7 @@ sdd           1033.00   4132.00   1141.33  31685.33   571.00    0.94 100.00
 
 - AWSでは[gp3](https://aws.amazon.com/ebs/general-purpose/)推奨されます。gp3ボリュームは、ボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分な値です。
 
-- Google Cloudでは[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)推奨されています。IOPSとMBPSは割り当てられたディスクサイズによって異なります。パフォーマンス要件を満たすには、 Raft Engineに200GBを割り当てることを推奨します。Raft Raft Engineはそれほど大きな容量を必要としませんが、最適なパフォーマンスを確保できます。
+- Google Cloudでは[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)が推奨されています。IOPSとMBPSは割り当てられたディスクサイズによって異なります。パフォーマンス要件を満たすには、 Raft Engineに200GBを割り当てることを推奨します。Raft Engineはそれほど大きな容量を必要としませんが、最適なパフォーマンスを確保できます。
 
 - Azureでは[プレミアム SSD v2](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssd-v2)推奨されます。AWS gp3と同様に、Premium SSD v2はボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分です。
 
@@ -88,7 +88,7 @@ AWS は、20 GB [gp3](https://aws.amazon.com/ebs/general-purpose/)ボリュー
 書き込み集中型のソーシャル ネットワーク アプリケーション ワークロードに AWS 上の専用の 20 GB [gp3](https://aws.amazon.com/ebs/general-purpose/) Raft Engineディスクを使用すると、次のような改善が見られますが、推定コストはわずか 0.4% しか増加しません。
 
 - QPS（1秒あたりのクエリ数）が17.5%増加
-- 挿入文の平均レイテンシーが18.7%減少
+- 挿入ステートメントの平均レイテンシーが18.7%減少
 - 挿入ステートメントの p99レイテンシーが 45.6% 減少しました。
 
 | メトリック            | 共有Raft Engineディスク | 専用Raft Engineディスク | 違い （％） |
@@ -143,9 +143,9 @@ TiFlash MPPタスクのデータシャッフルによって発生するネット
 
 Google Cloud の[ライブマイグレーション機能](https://cloud.google.com/compute/docs/instances/live-migration-process)は、ダウンタイムを発生させることなく、ホスト間でVMをシームレスに移行できます。しかし、これらの移行イベントは頻度は低いものの、TiDBクラスタで実行されているVMを含むVMのパフォーマンスに重大な影響を与える可能性があります。このようなイベントが発生すると、影響を受けるVMのパフォーマンスが低下し、TiDBクラスタでのクエリ処理時間が長くなる可能性があります。
 
-Google Cloud によって開始されたライブマイグレーション イベントを検出し、これらのイベントによるパフォーマンスへの影響を軽減するために、TiDB は Google のメタデータ[例](https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/compute/metadata/main.py)に基づく[スクリプトを見る](https://github.com/PingCAP-QE/tidb-google-maintenance)提供します。このスクリプトを TiDB、TiKV、PD ノードにデプロイして、メンテナンス イベントを検出できます。メンテナンス イベントが検出されると、中断を最小限に抑え、クラスタの動作を最適化するために、次のように適切なアクションが自動的に実行されます。
+Google Cloud によって開始されたライブマイグレーション イベントを検出し、これらのイベントによるパフォーマンスへの影響を軽減するために、TiDB は Google のメタデータ[例](https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/compute/metadata/main.py)に基づく[監視スクリプト](https://github.com/PingCAP-QE/tidb-google-maintenance)を提供します。このスクリプトを TiDB、TiKV、PD ノードにデプロイして、メンテナンス イベントを検出できます。メンテナンス イベントが検出されると、中断を最小限に抑え、クラスタの動作を最適化するために、次のように適切なアクションが自動的に実行されます。
 
-- TiDB: TiDBノードをオフラインにし、TiDBポッドを削除します。これは、TiDBインスタンスのノードプールが自動スケールに設定され、TiDB専用になっていることを前提としています。ノード上で実行されている他のポッドに中断が発生する可能性があり、切断されたノードは自動スケーラーによって回収されることが想定されます。
+- TiDB: TiDBノードをコルドンしてオフラインにし、TiDBポッドを削除します。これは、TiDBインスタンスのノードプールが自動スケールに設定され、TiDB専用になっていることを前提としています。ノード上で実行されている他のポッドに中断が発生する可能性があり、コルドンされたノードは自動スケーラーによって回収されることが想定されます。
 - TiKV: メンテナンス中に、影響を受ける TiKV ストアのリーダーを削除します。
 - PD: 現在の PD インスタンスが PD リーダーである場合、リーダーを辞任します。
 

From fb1dd89ece1be0ffd4817ff4c45db3978d413f6d Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:10:17 +0900
Subject: [PATCH 05/34] i18n(ja): fix Health Check false friend and literal
 package name in haproxy-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- "Health Check" mistranslated as 健康チェック (a medical-checkup
  false friend) instead of the standard ヘルスチェック term.
- Literal package name epel-release transliterated into katakana,
  inconsistent with its correct literal use in the same command a few
  lines below.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/haproxy-best-practices.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/best-practices/haproxy-best-practices.md b/best-practices/haproxy-best-practices.md
index 46b5158940f77..c5ed50a0fe0b8 100644
--- a/best-practices/haproxy-best-practices.md
+++ b/best-practices/haproxy-best-practices.md
@@ -24,7 +24,7 @@ HAProxyは、LinuxカーネルのコアコントリビューターであるWilly
 
 - [高可用性](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.4) : HAProxy は、正常なシャットダウンとシームレスな切り替えをサポートする高可用性を提供します。
 - [負荷分散](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#4.2-balance) : 2つの主要なプロキシ モード (レイヤー4 とも呼ばれる TCP とレイヤー7 とも呼ばれる HTTP) がサポートされています。ラウンドロビン、Leastconn、ランダムなど、9種類以上の負荷分散アルゴリズムがサポートされています。
-- [健康チェック](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#5.2-check) : HAProxy はサーバーの HTTP または TCP モードのステータスを定期的にチェックします。
+- [ヘルスチェック](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html#5.2-check) : HAProxy はサーバーの HTTP または TCP モードのステータスを定期的にチェックします。
 - [スティッキーセッション](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.6) : アプリケーションがスティッキーセッションをサポートしていない間、HAProxy はクライアントを特定のサーバーに固定することができます。
 - [SSL](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.2) : HTTPS 通信と解決がサポートされます。
 - [監視と統計](http://cbonte.github.io/haproxy-dconv/2.6/intro.html#3.3.3) ：Web ページを通じて、サービスの状態とトラフィック フローをリアルタイムで監視できます。
@@ -63,7 +63,7 @@ HAProxy をデプロイする前に、ハードウェアとソフトウェアの
 
 #### 依存関係 {#dependencies}
 
-- エペルリリース
+- epel-release
 - gcc
 - systemd-devel
 

From e3998b7c8f92fffaaa19e912587437c0a5b5ed63 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:11:07 +0900
Subject: [PATCH 06/34] i18n(ja): fix wrong particle direction, Raft
 duplication, and dropped particles in massive-regions-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- から/に particle used backwards, making "X is configured to 2" read
  as "configured FROM X TO 2".
- Duplicated "RaftstoreRaftstore" MT artifact.
- 4 dropped particles (が x3, を x1) found during review.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/massive-regions-best-practices.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md
index d01e0e557a4d1..83527b2bfcf06 100644
--- a/best-practices/massive-regions-best-practices.md
+++ b/best-practices/massive-regions-best-practices.md
@@ -12,7 +12,7 @@ TiDBでは、データはリージョンに分割され、各リージョンに
 
 ## Raftstoreワークフロー {#raftstore-workflow}
 
-TiKVインスタンスには複数のリージョンが存在します。RaftstoreRaftstoreはRaftステートマシンを駆動し、リージョンメッセージを処理します。これらのメッセージには、リージョンに対する読み取りまたは書き込みリクエストの処理、 Raftログの永続化または複製、 Raftハートビートの処理が含まれます。ただし、リージョン数の増加はクラスター全体のパフォーマンスに影響を与える可能性があります。これを理解するには、以下に示すRaftstoreのワークフローを理解する必要があります。
+TiKVインスタンスには複数のリージョンが存在します。RaftstoreはRaftステートマシンを駆動し、リージョンメッセージを処理します。これらのメッセージには、リージョンに対する読み取りまたは書き込みリクエストの処理、 Raftログの永続化または複製、 Raftハートビートの処理が含まれます。ただし、リージョン数の増加はクラスター全体のパフォーマンスに影響を与える可能性があります。これを理解するには、以下に示すRaftstoreのワークフローを理解する必要があります。
 
 ![Raftstore Workflow](/media/best-practices/raft-process.png)
 
@@ -26,7 +26,7 @@ TiKVインスタンスには複数のリージョンが存在します。Raftsto
 
 Raftstore のワークフロー図から、各リージョンのメッセージは1つずつ処理されます。リージョンの数が多い場合、 Raftstore は各リージョンのハートビートを処理するのに時間がかかり、遅延が発生する可能性があります。その結果、一部の読み取りおよび書き込みリクエストが時間内に処理されない場合があります。読み取りおよび書き込みの負荷が高い場合、 Raftstoreスレッドの CPU 使用率がボトルネックになりやすく、遅延がさらに増加してパフォーマンスに影響を及ぼします。
 
-一般的に、ロードされたRaftstoreのCPU使用率が85%以上に達すると、 Raftstoreはビジー状態になり、ボトルネックとなります。同時に、 `propose wait duration`数百ミリ秒に達することもあります。
+一般的に、ロードされたRaftstoreのCPU使用率が85%以上に達すると、 Raftstoreはビジー状態になり、ボトルネックとなります。同時に、 `propose wait duration`が数百ミリ秒に達することもあります。
 
 > **Note:**
 >
@@ -74,7 +74,7 @@ Grafana の**TiKV-Details**ダッシュボードでは、次の監視メトリ
 
 Raftstore はTiDB v3.0 以降、マルチスレッド モジュールにアップグレードされており、 Raftstoreスレッドがボトルネックになる可能性が大幅に減少しています。
 
-TiKVでは、デフォルトで`raftstore.store-pool-size`から`2`に設定されています。Raftstoreでボトルネックが発生する場合は、実際の状況に応じてこの設定項目の値を適切に増やすことができます。ただし、不要なスレッド切り替えのオーバーヘッドを回避するため、この値を高くしすぎないことをお勧めします。
+TiKVでは、デフォルトで`raftstore.store-pool-size`は`2`に設定されています。Raftstoreでボトルネックが発生する場合は、実際の状況に応じてこの設定項目の値を適切に増やすことができます。ただし、不要なスレッド切り替えのオーバーヘッドを回避するため、この値を高くしすぎないことをお勧めします。
 
 ### 方法2: 休止状態リージョンを有効にする {#method-2-enable-hibernate-region}
 
@@ -119,7 +119,7 @@ I/O リソースと CPU リソースが十分な場合は、単一のマシン
 raft-base-tick-interval = "2s"
 ```
 
-上記の設定では、 `raft-base-tick-interval` Raftstore が各リージョンのRaftステートマシンを駆動する時間間隔です。つまり、この時間間隔でRaftstore はRaftステートマシンに tick メッセージを送信します。この間隔を長くすることで、 Raftstoreからのメッセージ数を効果的に減らすことができます。
+上記の設定では、 `raft-base-tick-interval`は、Raftstore が各リージョンのRaftステートマシンを駆動する時間間隔です。つまり、この時間間隔でRaftstore はRaftステートマシンに tick メッセージを送信します。この間隔を長くすることで、 Raftstoreからのメッセージ数を効果的に減らすことができます。
 
 ティックメッセージ間のこの間隔は、 `election timeout`と`heartbeat`の間の間隔も決定することに注意してください。次の例をご覧ください。
 
@@ -132,7 +132,7 @@ raft-heartbeat-interval = raft-base-tick-interval * raft-heartbeat-ticks
 
 ### 方法6:リージョンのサイズを調整する {#method-6-adjust-region-size}
 
-リージョンのデフォルトサイズは256MiBです。リージョンのサイズを大きくすることで、リージョンの数を減らすことができます。詳細については、 [リージョンパフォーマンスの調整](/tune-region-performance.md)ご覧ください。
+リージョンのデフォルトサイズは256MiBです。リージョンのサイズを大きくすることで、リージョンの数を減らすことができます。詳細については、 [リージョンパフォーマンスの調整](/tune-region-performance.md)をご覧ください。
 
 > **Note:**
 >
@@ -158,7 +158,7 @@ TiKVノード間のRaft通信に使用される最大接続数を調整するに
 
 PDは、PD Leaderノードの切り替え後、迅速にリージョンルーティングサービスを再開できるように、etcdにリージョンメタ情報を保持する必要があります。リージョン数が増えると、etcdのパフォーマンス問題が発生し、PDがLeaderを切り替える際に、etcdからリージョンメタ情報を取得するのに時間がかかります。数百万のリージョンが存在する場合、etcdからメタ情報を取得するのに10秒以上、場合によっては数十秒かかることがあります。
 
-この問題に対処するため、TiDB v3.0以降、PDではデフォルトで`use-region-storage`有効になっています。この機能を有効にすると、PDはリージョンメタ情報をローカルLevelDBに保存し、他のメカニズムを通じてPDノード間で情報を同期します。
+この問題に対処するため、TiDB v3.0以降、PDではデフォルトで`use-region-storage`が有効になっています。この機能を有効にすると、PDはリージョンメタ情報をローカルLevelDBに保存し、他のメカニズムを通じてPDノード間で情報を同期します。
 
 ### PDルーティング情報が時間内に更新されない {#pd-routing-information-is-not-updated-in-time}
 

From 0aebaeebdb31a7ca3aaf142062beb437f5aea470 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:12:10 +0900
Subject: [PATCH 07/34] i18n(ja): fix dropped tier, register inconsistency, and
 stray quote in pd-scheduling-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- A dropped fallback tier: EN describes 3 tiers (zones -> racks ->
  hosts) but JA dropped the middle "schedule to racks" step entirely,
  losing real content.
- 3 sites mixing polite ないでください with plain ない across one
  parallel bullet list of negative constraints.
- A stray unmatched opening quote 「 with no closing 」.
- 2 dropped は particles.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/pd-scheduling-best-practices.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md
index 3c019f091da91..37f5ec07ab59a 100644
--- a/best-practices/pd-scheduling-best-practices.md
+++ b/best-practices/pd-scheduling-best-practices.md
@@ -42,10 +42,10 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/
 
     さまざまなスケジューラが、次の点を考慮して、独自のロジックと要件に基づいてオペレーターを生成します。
 
-    - 異常な状態（切断、ダウン、ビジー、容量不足）にあるピアをストアに追加しないでください。
+    - 異常な状態（切断、ダウン、ビジー、容量不足）にあるピアをストアに追加しない
     - 異常な状態のリージョンのバランスをとらない
-    - リーダーを保留中のピアに転送しないでください
-    - リーダーを直接削除しないでください
+    - リーダーを保留中のピアに転送しない
+    - リーダーを直接削除しない
     - さまざまなリージョンピアの物理的な分離を破壊しない
     - ラベルプロパティなどの制約に違反しない
 
@@ -84,13 +84,13 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/
 
 2. 負荷分散と同様の方法でこれらのリージョンを再分配します。
 
-ホット書き込みリージョンの場合、 `hot-region-scheduler`リージョンピアとリーダーの両方の再配布を試行します。ホット読み取りリージョンの場合、 `hot-region-scheduler`リージョンリーダーのみを再配布します。
+ホット書き込みリージョンの場合、 `hot-region-scheduler`はリージョンピアとリーダーの両方の再配布を試行します。ホット読み取りリージョンの場合、 `hot-region-scheduler`はリージョンリーダーのみを再配布します。
 
 ### クラスタトポロジの認識 {#cluster-topology-awareness}
 
 クラスタトポロジーの認識により、PDはリージョンのレプリカを可能な限り分散させることができます。これにより、TiKVは高可用性と災害復旧能力を確保します。PDはバックグラウンドですべてのリージョンを継続的にスキャンします。リージョンの分散が最適ではないと判断された場合、PDはピアを置き換えてリージョンを再分散するためのオペレーターを生成します。
 
-リージョン分散をチェックするコンポーネントは`replicaChecker`です。これは、無効にできないことを除いてスケジューラに似ています。 `replicaChecker`は`location-labels`の設定に基づいてスケジュールします。たとえば、 `[zone,rack,host]`はクラスターの 3 層トポロジを定義します。PD は、最初にリージョン ピアを異なるゾーンにスケジュールしようとします。ゾーンが不十分な場合は (たとえば、レプリカ 3つに対してゾーン 2つ)、またはラックが不十分な場合は異なるホストにスケジュールしようとします。
+リージョン分散をチェックするコンポーネントは`replicaChecker`です。これは、無効にできないことを除いてスケジューラに似ています。 `replicaChecker`は`location-labels`の設定に基づいてスケジュールします。たとえば、 `[zone,rack,host]`はクラスターの 3 層トポロジを定義します。PD は、最初にリージョン ピアを異なるゾーンにスケジュールしようとします。ゾーンが不十分な場合は (たとえば、レプリカ 3つに対してゾーン 2つ) 異なるラックに、ラックが不十分な場合は異なるホストにスケジュールしようとします。
 
 ### スケールインと障害回復 {#scale-in-and-failure-recovery}
 
@@ -231,7 +231,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー
 
 - スケジューリング速度はデフォルトで制限されています。`leader-schedule-limit`または`replica-schedule-limit`の値を大きく調整できます。同様に、 `max-pending-peer-count`と`max-snapshot-count`の制限を緩和することも検討できます。
 - 他のスケジューリングタスクが同時に実行され、システム内のリソースを奪い合っています。解決策は[リーダー/リージョンが均等に分布していない](#leadersregions-are-not-evenly-distributed)を参照してください。
-- 単一ノードをオフラインにすると、処理対象となるリージョンリーダー（レプリカ3台構成では約1/3）が削除対象のノードに分散されます。そのため、処理速度はこの単一ノードによるスナップショット生成速度によって制限されます。「 `evict-leader-scheduler`を手動で追加することで、リージョンリーダーの移行速度を上げることができます。
+- 単一ノードをオフラインにすると、処理対象となるリージョンリーダー（レプリカ3台構成では約1/3）が削除対象のノードに分散されます。そのため、処理速度はこの単一ノードによるスナップショット生成速度によって制限されます。 `evict-leader-scheduler`を手動で追加することで、リージョンリーダーの移行速度を上げることができます。
 
 対応するオペレーターの生成に失敗した場合、考えられる理由は次のとおりです。
 

From a38e27416c8f93869bc8dcd8d8c3909ae4171f80 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:12:51 +0900
Subject: [PATCH 08/34] i18n(ja): fix scrambled subject/value and dropped
 particles in three-nodes-hybrid-deployment.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

A scrambled sentence read "the default value is
rocksdb.max-background-jobs, but it's set to 8" instead of "the
default value of rocksdb.max-background-jobs is 8" (subject and value
swapped). Also fixed 3 more dropped particles (の x2, は x1) found
while reviewing the surrounding paragraphs.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/three-nodes-hybrid-deployment.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md
index 0286129f04031..b82df5bcee30f 100644
--- a/best-practices/three-nodes-hybrid-deployment.md
+++ b/best-practices/three-nodes-hybrid-deployment.md
@@ -82,14 +82,14 @@ TiKVはフォアグラウンドタスクに加えて、バックグラウンド
 
 #### `rocksdb.max-background-jobs`と`rocksdb.max-sub-compactions` {#rocksdb-max-background-jobs-and-rocksdb-max-sub-compactions}
 
-RocksDBスレッドプールは、コンパクションジョブとフラッシュジョブを実行するために使用されます。デフォルト値は`rocksdb.max-background-jobs`ですが、 `8`に設定されており、明らかに必要なリソースを超えています。したがって、リソース使用量を制限するために値を調整する必要があります。
+RocksDBスレッドプールは、コンパクションジョブとフラッシュジョブを実行するために使用されます。 `rocksdb.max-background-jobs`のデフォルト値は`8`であり、明らかに必要なリソースを超えています。したがって、リソース使用量を制限するために値を調整する必要があります。
 
-`rocksdb.max-sub-compactions` 、単一の圧縮ジョブで許可される同時サブタスクの数を示します。デフォルトは`3`です。書き込みトラフィックが多くない場合は、この値を下げることができます。
+`rocksdb.max-sub-compactions`は、単一の圧縮ジョブで許可される同時サブタスクの数を示します。デフォルトは`3`です。書き込みトラフィックが多くない場合は、この値を下げることができます。
 
 このテストでは、 `rocksdb.max-background-jobs`の値は`3`に、 `rocksdb.max-sub-compactions`の値は`1`に設定されています。TPC-C負荷での12時間テスト中、書き込みストールは発生しませんでした。実際の負荷に応じて2つのパラメータ値を最適化する際には、監視指標に基づいて値を徐々に下げることができます。
 
-- 書き込み停止が発生する場合は、値を`rocksdb.max-background-jobs`増やします。
-- 書き込み停止が続く場合は、値`rocksdb.max-sub-compactions`を`2`または`3`に設定します。
+- 書き込み停止が発生する場合は、 `rocksdb.max-background-jobs`の値を増やします。
+- 書き込み停止が続く場合は、 `rocksdb.max-sub-compactions`の値を`2`または`3`に設定します。
 
 #### `rocksdb.rate-bytes-per-sec` {#rocksdb-rate-bytes-per-sec}
 

From 4fe35f307e6993d6bc7966715faa780a8459e69d Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:13:23 +0900
Subject: [PATCH 09/34] i18n(ja): fix garbled two-argument explanation and
 missing backtick in uuid.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- An unclosed parenthesis and dropped structure garbled the
  explanation of UUID_TO_BIN()'s one-argument vs two-argument forms.
- A missing opening backtick before \`BINARY(16)\` in the frontmatter
  summary.
- 2 dropped を particles.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/uuid.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/best-practices/uuid.md b/best-practices/uuid.md
index e76046d07fc3f..ae30e459118ab 100644
--- a/best-practices/uuid.md
+++ b/best-practices/uuid.md
@@ -1,6 +1,6 @@
 ---
 title: Best Practices for Using UUIDs as Primary Keys
-summary: UUIDを主キーとして使用すると、ネットワーク通信の削減、ほとんどのプログラミング言語とデータベースでのサポート、列挙攻撃からの保護などの利点が得られます。UUIDはバイナリ形式でBINARY(16)`列に保存することをお勧めします。また、ホットスポットの発生を防ぐため、TiDBでは`swap_flag`の設定を避けることをお勧めします。UUIDはMySQLと互換性があります。
+summary: UUIDを主キーとして使用すると、ネットワーク通信の削減、ほとんどのプログラミング言語とデータベースでのサポート、列挙攻撃からの保護などの利点が得られます。UUIDはバイナリ形式で`BINARY(16)`列に保存することをお勧めします。また、ホットスポットの発生を防ぐため、TiDBでは`swap_flag`の設定を避けることをお勧めします。UUIDはMySQLと互換性があります。
 aliases: ['/ja/tidb/stable/uuid/','/ja/tidbcloud/uuid/']
 ---
 
@@ -26,9 +26,9 @@ UUID を主キーとして使用すると、 [`AUTO_INCREMENT`](/auto-increment.
 
 ### UUID形式のバイナリ順序とクラスター化された主キー {#uuid-format-binary-order-and-clustered-primary-keys}
 
-`UUID_TO_BIN()`関数は、 1つの引数 (UUID)、または 2つの引数 (2 番目の引数は`swap_flag`とともに使用できます。
+`UUID_TO_BIN()`関数は、 1つの引数（UUID）で使用することも、 2つの引数（2番目の引数は`swap_flag`）で使用することもできます。
 
-[ホットスポット](/best-practices/high-concurrency-best-practices.md)回避するために、 TiDB で`swap_flag`設定しないことをお勧めします。
+[ホットスポット](/best-practices/high-concurrency-best-practices.md)を回避するために、 TiDB で`swap_flag`を設定しないことをお勧めします。
 
 ホットスポットを回避するために、UUID ベースの主キーに[`CLUSTERED`オプション](/clustered-indexes.md)を明示的に設定することもできます。
 

From 9be03e55647906678f331602294eeb137f2b849f Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:13:38 +0900
Subject: [PATCH 10/34] i18n(ja): fix stray untranslated word and missing
 backtick in three-dc-local-read.md summary
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- A stray leftover untranslated "Stale" sitting directly beside its
  own correct translation "ステイル読み取り".
- A missing opening backtick before \`zone\`.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/three-dc-local-read.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/best-practices/three-dc-local-read.md b/best-practices/three-dc-local-read.md
index 434f5259035cf..cdcb613ca164d 100644
--- a/best-practices/three-dc-local-read.md
+++ b/best-practices/three-dc-local-read.md
@@ -1,6 +1,6 @@
 ---
 title: Best Practices for Local Reads in Three-Data-Center Deployments
-summary: TiDBの3データセンターデプロイモデルでは、センター間データ読み取りによりアクセスレイテンシーが増加する可能性があります。これを軽減するために、 ステイル読み取り機能ではローカルの履歴データへのアクセスを可能にし、リアルタイムデータ可用性を犠牲にしてレイテンシーを削減します。地理的に分散されたシナリオでステイル読み取りを使用する場合、TiDBはセンター間ネットワークレイテンシーを回避するためにローカルレプリカにアクセスします。これは、zone`ラベルを設定し、`tidb_replica_read`を`closest-replicas`に設定することで実現されます。Stale ステイル読み取りの実行方法の詳細については、ドキュメントを参照してください。
+summary: TiDBの3データセンターデプロイモデルでは、センター間データ読み取りによりアクセスレイテンシーが増加する可能性があります。これを軽減するために、 ステイル読み取り機能ではローカルの履歴データへのアクセスを可能にし、リアルタイムデータ可用性を犠牲にしてレイテンシーを削減します。地理的に分散されたシナリオでステイル読み取りを使用する場合、TiDBはセンター間ネットワークレイテンシーを回避するためにローカルレプリカにアクセスします。これは、 `zone`ラベルを設定し、`tidb_replica_read`を`closest-replicas`に設定することで実現されます。ステイル読み取りの実行方法の詳細については、ドキュメントを参照してください。
 aliases: ['/ja/tidb/stable/three-dc-local-read/']
 ---
 

From 8823f486c86856d4f725ee0fbaedf76d67d41fe0 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:14:00 +0900
Subject: [PATCH 11/34] i18n(ja): fix bold-span defects in
 multi-column-index-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

EN bolds both **AND** and **OR** condition names, but JA only bolded
OR; separately, an object particle を was trapped inside its own bold
span with no EN counterpart at all.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/multi-column-index-best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/best-practices/multi-column-index-best-practices.md b/best-practices/multi-column-index-best-practices.md
index 33595a83ea44f..0e681ffa56733 100644
--- a/best-practices/multi-column-index-best-practices.md
+++ b/best-practices/multi-column-index-best-practices.md
@@ -123,7 +123,7 @@ TiDBオプティマイザには、強力な範囲導出コンポーネントが
 
 ![Table Access Path Selection](/media/best-practices/multi-column-index-table-access-path-selection.png)
 
-複数列のフィルターは、前述の基本的な例よりも複雑になることがよくあります。AND条件、 **OR**条件、あるいはその両方の組み合わせが含まれる場合があります。TiDBの範囲導出サブシステムは、これらのケース**を**効率的に処理し、最も選択性の高い（したがって最も効果的な）インデックス範囲を生成するように設計されています。
+複数列のフィルターは、前述の基本的な例よりも複雑になることがよくあります。 **AND**条件、 **OR**条件、あるいはその両方の組み合わせが含まれる場合があります。TiDBの範囲導出サブシステムは、これらのケースを効率的に処理し、最も選択性の高い（したがって最も効果的な）インデックス範囲を生成するように設計されています。
 
 一般的に、サブシステムは**OR**条件から生成された範囲には**UNION**演算を適用し、 **AND**条件から生成された範囲には**INTERSECT**演算を適用します。このアプローチにより、TiDBは複雑なフィルタリングロジックであっても、可能な限り正確にデータをフィルタリングできます。
 

From 180990233525dace6c2fa2ffa0f37b3be39901b3 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:14:47 +0900
Subject: [PATCH 12/34] i18n(ja): fix Raft duplication and dropped particles in
 high-concurrency-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Duplicated "RaftRaft" (dropped グループ, should be "Raftグループでは")
plus 3 dropped particles found during review.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/high-concurrency-best-practices.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md
index 1e6c4dfe0c91b..02c5010b59a06 100644
--- a/best-practices/high-concurrency-best-practices.md
+++ b/best-practices/high-concurrency-best-practices.md
@@ -35,7 +35,7 @@ aliases: ['/ja/tidb/stable/high-concurrency-best-practices/','/ja/tidb/dev/high-
 
 上記の課題に対処するには、TiDBのデータセグメンテーションとスケジューリングの原理から始める必要があります。詳細については[スケジュール](https://www.pingcap.com/blog/tidb-internal-scheduling/)を参照してください。
 
-TiDBはデータをリージョンに分割します。リージョンはそれぞれ、デフォルトで96MBのサイズ制限を持つデータ範囲を表します。各リージョンには複数のレプリカがあり、レプリカの各グループはRaftグループと呼ばれます。RaftRaftでは、リージョンLeaderがデータ範囲内の読み取りおよび書き込みタスク（TiDBは[フォロワー読み取り](/follower-read.md)サポート）を実行します。リージョンLeaderは、Placement Driver （PD）コンポーネントによって自動的に異なる物理ノードにスケジュールされ、読み取りおよび書き込みの負荷を均等に分散します。
+TiDBはデータをリージョンに分割します。リージョンはそれぞれ、デフォルトで96MBのサイズ制限を持つデータ範囲を表します。各リージョンには複数のレプリカがあり、レプリカの各グループはRaftグループと呼ばれます。Raftグループでは、リージョンLeaderがデータ範囲内の読み取りおよび書き込みタスク（TiDBは[フォロワー読み取り](/follower-read.md)をサポート）を実行します。リージョンLeaderは、Placement Driver （PD）コンポーネントによって自動的に異なる物理ノードにスケジュールされ、読み取りおよび書き込みの負荷を均等に分散します。
 
 ![TiDB Data Overview](/media/best-practices/tidb-data-overview.png)
 
@@ -152,7 +152,7 @@ TiDBは汎用的な用途向けのデータベースであり、データ分布
 
 このような状況とホットスポット問題を回避する必要性を踏まえ、TiDBは`Split Region`構文を使用して、同時書き込みが集中するシナリオでパフォーマンスを最適化します。上記のケースに基づいて、 `Split Region`構文を使用してリージョンを分散させ、負荷分散を観察してみましょう。
 
-テストで書き込まれるデータは正の範囲内で完全に離散的であるため、次のステートメントを使用して、テーブルを`minInt64`から`maxInt64`範囲内の 128 個の領域に事前に分割できます。
+テストで書き込まれるデータは正の範囲内で完全に離散的であるため、次のステートメントを使用して、テーブルを`minInt64`から`maxInt64`の範囲内の 128 個の領域に事前に分割できます。
 
 ```sql
 SPLIT TABLE TEST_HOTSPOT BETWEEN (0) AND (9223372036854775807) REGIONS 128;

From 70c2455c0114b11b9431045fa68802bae0789bf0 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:19:09 +0900
Subject: [PATCH 13/34] i18n(ja): fix dropped particles after backticked
 identifiers in index-management-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Restore を/は/が/の particles dropped immediately after backticked
identifiers (TIDB_INDEX_USAGE, CLUSTER_TIDB_INDEX_USAGE,
schema_unused_indexes, LAST_ACCESS_TIME, PERCENTAGE_ACCESS_100) in two
headings and five sentences.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/index-management-best-practices.md | 14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md
index 8b2cb5b655a0c..807fb95afa493 100644
--- a/best-practices/index-management-best-practices.md
+++ b/best-practices/index-management-best-practices.md
@@ -95,22 +95,22 @@ DESC TIDB_INDEX_USAGE;
 - 未使用のインデックス:
 
     - `QUERY_TOTAL = 0`の場合、インデックスはどのクエリでも使用されていません。
-    - `LAST_ACCESS_TIME`かなり前のものを示している場合、インデックスはもはや関連がない可能性があります。
+    - `LAST_ACCESS_TIME`がかなり前のものを示している場合、インデックスはもはや関連がない可能性があります。
 
 - 非効率的なインデックス:
 
-    - `PERCENTAGE_ACCESS_100`値が大きい場合は完全なインデックススキャンが実行されることを意味し、インデックスが非効率的である可能性があります。
+    - `PERCENTAGE_ACCESS_100`の値が大きい場合は完全なインデックススキャンが実行されることを意味し、インデックスが非効率的である可能性があります。
     - `ROWS_ACCESS_TOTAL`と`QUERY_TOTAL`を比較して、インデックスが使用量に比べてスキャンする行数が多すぎるかどうかを判断します。
 
 `TIDB_INDEX_USAGE`システムテーブルを使用すると、インデックスのパフォーマンスに関する詳細な情報を取得できるため、不要なインデックスを削除し、クエリ実行を最適化することが容易になります。
 
-### `TIDB_INDEX_USAGE`効果的に使用する {#use-tidb-index-usage-effectively}
+### `TIDB_INDEX_USAGE`を効果的に使用する {#use-tidb-index-usage-effectively}
 
 次の点は、 `TIDB_INDEX_USAGE`システムテーブルを正しく理解して使用するのに役立ちます。
 
 #### データの更新が遅れている {#data-updates-are-delayed}
 
-パフォーマンスへの影響を最小限に抑えるため、 `TIDB_INDEX_USAGE`即座に更新されません。インデックス使用状況の指標は最大 5分ほど遅延する場合があります。クエリを分析する際は、このレイテンシーにご注意ください。
+パフォーマンスへの影響を最小限に抑えるため、 `TIDB_INDEX_USAGE`は即座に更新されません。インデックス使用状況の指標は最大 5分ほど遅延する場合があります。クエリを分析する際は、このレイテンシーにご注意ください。
 
 #### インデックス使用状況データは保存されません {#index-usage-data-is-not-persisted}
 
@@ -151,13 +151,13 @@ ORDER BY total_queries DESC;
 | インデックス追跡 | データは各データベースインスタンスに対してローカルです。          | クラスター全体の集中ビューを提供します。               |
 | 主な使用例    | データベースインスタンスレベルでインデックスの使用状況をデバッグします。 | グローバルインデックスパターンとマルチノードの動作を分析します。 |
 
-### `CLUSTER_TIDB_INDEX_USAGE`効果的に使用する {#use-cluster-tidb-index-usage-effectively}
+### `CLUSTER_TIDB_INDEX_USAGE`を効果的に使用する {#use-cluster-tidb-index-usage-effectively}
 
 `CLUSTER_TIDB_INDEX_USAGE`システムテーブルは複数のノードからのデータを統合するため、次の点に注意してください。
 
 - データ更新の遅延
 
-    パフォーマンスへの影響を最小限に抑えるため、 `CLUSTER_TIDB_INDEX_USAGE`即座に更新されません。インデックス使用状況の指標は最大 5分ほど遅延する場合があります。クエリを分析する際は、このレイテンシーにご注意ください。
+    パフォーマンスへの影響を最小限に抑えるため、 `CLUSTER_TIDB_INDEX_USAGE`は即座に更新されません。インデックス使用状況の指標は最大 5分ほど遅延する場合があります。クエリを分析する際は、このレイテンシーにご注意ください。
 
 - メモリベースのストレージ
 
@@ -177,7 +177,7 @@ ORDER BY total_queries DESC;
 
 `schema_unused_indexes`を使用すると、不要なインデックスをすばやく識別し、最小限の労力でデータベースのオーバーヘッドを削減できます。
 
-### `schema_unused_indexes`仕組み {#how-schema-unused-indexes-works}
+### `schema_unused_indexes`の仕組み {#how-schema-unused-indexes-works}
 
 `schema_unused_indexes`ビューは`TIDB_INDEX_USAGE`から派生しており、最後の TiDB 再起動以降にクエリ アクティビティが 0 個記録されたインデックスを自動的に除外することを意味します。
 

From 2f38d3ddf2ed0e74691595f0a0d479a428c347da Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:21:06 +0900
Subject: [PATCH 14/34] i18n(ja): fix dropped particles in ddl-introduction.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Restore を before 例にとる and before a linked 論理DDL文,
both missing after the linked/backticked term.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/ddl-introduction.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/best-practices/ddl-introduction.md b/best-practices/ddl-introduction.md
index a5b96a21865dd..ce90dcc03637a 100644
--- a/best-practices/ddl-introduction.md
+++ b/best-practices/ddl-introduction.md
@@ -67,7 +67,7 @@ DDL変更は、ある状態から別の状態への遷移を伴い、通常は
 
 このように、複数の小さなバージョンを経ることで、複数のTiDBノード間でメタデータが正しく同期されます。これにより、プロセス中にデータの変更を伴うユーザートランザクションの正確性と一貫性が維持されます。
 
-`ADD INDEX`例にとると、状態変化の全体プロセスは次のようになります。
+`ADD INDEX`を例にとると、状態変化の全体プロセスは次のようになります。
 
 ```
 absent -> delete only -> write only -> write reorg -> public
@@ -87,7 +87,7 @@ DDL実行のユーザーエクスペリエンスを向上させるため、TiDB
 - 同じテーブルに対して実行される DDL文は相互にブロックされます。
 - `DROP DATABASE`と、データベース内のすべてのオブジェクトに影響する DDL文は相互にブロックされます。
 - 異なるテーブルでのインデックスの追加と列タイプの変更を同時に実行できます。
-- v8.2.0 以降では、異なるテーブルに対して[論理DDL文](/best-practices/ddl-introduction.md#types-of-ddl-statements)並列実行できます。
+- v8.2.0 以降では、異なるテーブルに対して[論理DDL文](/best-practices/ddl-introduction.md#types-of-ddl-statements)を並列実行できます。
 - それ以外の場合、同時 DDL 実行の可用性レベルに基づいて DDL を実行できます。
 
 具体的には、TiDB 6.2.0 では、次の点で DDL 実行フレームワークが強化されました。

From df2fd2a21154d0b50a32f6931fce52011dd71f2c Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:21:06 +0900
Subject: [PATCH 15/34] i18n(ja): fix dropped particle in
 grafana-monitor-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Restore を before 追加する, dropped after the linked
deploy-a-tidb-cluster-using-tiup reference.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/grafana-monitor-best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/best-practices/grafana-monitor-best-practices.md b/best-practices/grafana-monitor-best-practices.md
index 7d827cc68a111..74011148a263d 100644
--- a/best-practices/grafana-monitor-best-practices.md
+++ b/best-practices/grafana-monitor-best-practices.md
@@ -6,7 +6,7 @@ aliases: ['/ja/docs/dev/best-practices/grafana-monitor-best-practices/','/ja/doc
 
 # Grafana を使用した TiDB 監視のベストプラクティス {#best-practices-for-monitoring-tidb-using-grafana}
 
-トポロジ構成にGrafanaとPrometheus [TiUPを使用してTiDBクラスタをデプロイする](/production-deployment-using-tiup.md)追加すると、TiDBクラスター内の様々なコンポーネントとマシンのメトリクスを収集・表示するために、 [Grafana + Prometheus 監視プラットフォーム](/tidb-monitoring-framework.md)のツールセットが同時にデプロイされます。このドキュメントでは、Grafanaを用いたTiDBの監視に関するベストプラクティスについて説明します。メトリクスを用いてTiDBクラスターの状態を分析し、問題を診断するのに役立つことを目的としています。
+トポロジ構成にGrafanaとPrometheus [TiUPを使用してTiDBクラスタをデプロイする](/production-deployment-using-tiup.md)を追加すると、TiDBクラスター内の様々なコンポーネントとマシンのメトリクスを収集・表示するために、 [Grafana + Prometheus 監視プラットフォーム](/tidb-monitoring-framework.md)のツールセットが同時にデプロイされます。このドキュメントでは、Grafanaを用いたTiDBの監視に関するベストプラクティスについて説明します。メトリクスを用いてTiDBクラスターの状態を分析し、問題を診断するのに役立つことを目的としています。
 
 ## 監視アーキテクチャ {#monitoring-architecture}
 

From 87f1dd5d20c6e4746ff9bc84579202812e53d38f Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:21:06 +0900
Subject: [PATCH 16/34] i18n(ja): fix dropped particles in
 haproxy-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Restore を before ご覧ください and before カスタマイズできます,
both dropped immediately after a linked term.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/haproxy-best-practices.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/best-practices/haproxy-best-practices.md b/best-practices/haproxy-best-practices.md
index c5ed50a0fe0b8..2ba137bdc0149 100644
--- a/best-practices/haproxy-best-practices.md
+++ b/best-practices/haproxy-best-practices.md
@@ -18,7 +18,7 @@ aliases: ['/ja/docs/dev/best-practices/haproxy-best-practices/','/ja/docs/dev/re
 
 HAProxyは、C言語で書かれた無料のオープンソースソフトウェアで、TCPおよびHTTPベースのアプリケーション向けの高可用性ロードバランサおよびプロキシサーバーを提供します。CPUとメモリを高速かつ効率的に使用できるため、GitHub、Bitbucket、Stack Overflow、Reddit、Tumblr、Twitter、Tuenti、AWS（Amazon Web Services）など、多くの著名なウェブサイトで広く利用されています。
 
-HAProxyは、LinuxカーネルのコアコントリビューターであるWilly Tarreauによって2000年に作成されました。彼は現在もプロジェクトのメンテナンスを担当し、オープンソースコミュニティに無料のソフトウェアアップデートを提供しています。このガイドでは、HAProxy [2.6](https://www.haproxy.com/blog/announcing-haproxy-2-6/)を使用しています。最新の安定版の使用を推奨します。詳細は[HAProxyのリリースバージョン](http://www.haproxy.org/)ご覧ください。
+HAProxyは、LinuxカーネルのコアコントリビューターであるWilly Tarreauによって2000年に作成されました。彼は現在もプロジェクトのメンテナンスを担当し、オープンソースコミュニティに無料のソフトウェアアップデートを提供しています。このガイドでは、HAProxy [2.6](https://www.haproxy.com/blog/announcing-haproxy-2-6/)を使用しています。最新の安定版の使用を推奨します。詳細は[HAProxyのリリースバージョン](http://www.haproxy.org/)をご覧ください。
 
 ## 基本機能 {#basic-features}
 
@@ -75,7 +75,7 @@ yum -y install epel-release gcc systemd-devel
 
 ## HAProxyをデプロイ {#deploy-haproxy}
 
-HAProxyを使用すると、負荷分散されたデータベース環境を簡単に構成・セットアップできます。このセクションでは、一般的なデプロイメント操作について説明します。実際のシナリオに合わせて[設定ファイル](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html)カスタマイズできます。
+HAProxyを使用すると、負荷分散されたデータベース環境を簡単に構成・セットアップできます。このセクションでは、一般的なデプロイメント操作について説明します。実際のシナリオに合わせて[設定ファイル](http://cbonte.github.io/haproxy-dconv/2.6/configuration.html)をカスタマイズできます。
 
 ### HAProxyをインストールする {#install-haproxy}
 

From c1cfe0ce0ccb665bf83d519c73f8f7d03c6efa5b Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:21:06 +0900
Subject: [PATCH 17/34] i18n(ja): fix dropped particles in readonly-nodes.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Restore を before 使用 and が before 解析されない, both dropped
right after the backticked `$` label-prefix character.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/readonly-nodes.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/best-practices/readonly-nodes.md b/best-practices/readonly-nodes.md
index 36937a40bf8c4..fb2f337bc316e 100644
--- a/best-practices/readonly-nodes.md
+++ b/best-practices/readonly-nodes.md
@@ -12,7 +12,7 @@ aliases: ['/ja/tidb/stable/readonly-nodes/','/ja/tidb/dev/readonly-nodes/']
 
 ### 1. 一部のTiKVノードを読み取り専用として指定する {#1-specify-some-tikv-nodes-as-read-only}
 
-一部のTiKVノードを読み取り専用として指定するには、これらのノードに特別なラベル（ラベルキーのプレフィックスとして`$`使用）を付けます。配置ルールを使用してこれらのノードにデータを格納するように明示的に指定しない限り、PDはこれらのノードにデータをスケジュールしません。
+一部のTiKVノードを読み取り専用として指定するには、これらのノードに特別なラベル（ラベルキーのプレフィックスとして`$`を使用）を付けます。配置ルールを使用してこれらのノードにデータを格納するように明示的に指定しない限り、PDはこれらのノードにデータをスケジュールしません。
 
 `tiup cluster edit-config`コマンドを実行して読み取り専用ノードを構成できます。
 
@@ -117,7 +117,7 @@ set tidb_replica_read=learner;
 
 #### 3.2 クラスターデータのバックアップ時にFollower Readを使用する {#3-2-use-follower-read-when-backing-up-cluster-data}
 
-クラスターデータのバックアップ時に読み取り専用ノードからデータを読み取るには、brコマンドラインで`--replica-read-label`オプションを指定します。シェルで次のコマンドを実行する際は、 `$`解析されないように、ラベルを一重引用符で囲む必要があることに注意してください。
+クラスターデータのバックアップ時に読み取り専用ノードからデータを読み取るには、brコマンドラインで`--replica-read-label`オプションを指定します。シェルで次のコマンドを実行する際は、 `$`が解析されないように、ラベルを一重引用符で囲む必要があることに注意してください。
 
 ```shell
 tiup br backup full ... --replica-read-label '$mode:readonly'

From 8fc514aa1ffa828381d87701dedd19e985ee7860 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:22:44 +0900
Subject: [PATCH 18/34] i18n(ja): fix more dropped particles in
 best-practices-on-public-cloud.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Restore は before the RocksDB storage-engine sentence, ことで
connecting the Titan/compression-level links to the performance
improvement clause, and が before 推奨されます for gp3/Premium SSD
v2/pd-extreme, all dropped after a linked term.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/best-practices-on-public-cloud.md | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md
index 815a1ee1beecc..6e9aaea8f274b 100644
--- a/best-practices/best-practices-on-public-cloud.md
+++ b/best-practices/best-practices-on-public-cloud.md
@@ -12,9 +12,9 @@ aliases: ['/ja/tidb/stable/best-practices-on-public-cloud/']
 
 ## KV RocksDB の圧縮 I/O フローを削減 {#reduce-compaction-i-o-flow-in-kv-rocksdb}
 
-TiKVのストレージエンジンである[RocksDB](https://rocksdb.org/) 、ユーザーデータの保存に使用されます。クラウドEBSのプロビジョニングされたIOスループットは通常、コスト上の理由から制限されているため、RocksDBは書き込み増幅率が高くなり、ディスクスループットがワークロードのボトルネックになる可能性があります。その結果、保留中のコンパクションバイトの総数は時間の経過とともに増加し、フロー制御がトリガーされます。これは、TiKVがフォアグラウンド書き込みフローに対応するための十分なディスク帯域幅を欠いていることを示しています。
+TiKVのストレージエンジンである[RocksDB](https://rocksdb.org/)は、ユーザーデータの保存に使用されます。クラウドEBSのプロビジョニングされたIOスループットは通常、コスト上の理由から制限されているため、RocksDBは書き込み増幅率が高くなり、ディスクスループットがワークロードのボトルネックになる可能性があります。その結果、保留中のコンパクションバイトの総数は時間の経過とともに増加し、フロー制御がトリガーされます。これは、TiKVがフォアグラウンド書き込みフローに対応するための十分なディスク帯域幅を欠いていることを示しています。
 
-ディスクスループットの制限によるボトルネックを軽減するには、パフォーマンスを[Titanを有効にする](#enable-titan)向上させることができます。平均行サイズが 512 バイト未満の場合は、Titan は適用できません。この場合、パフォーマンスを[すべての圧縮レベルを上げる](#increase-all-the-compression-levels)向上させることができます。
+ディスクスループットの制限によるボトルネックを軽減するには、 [Titanを有効にする](#enable-titan)ことでパフォーマンスを向上させることができます。平均行サイズが 512 バイト未満の場合は、Titan は適用できません。この場合、 [すべての圧縮レベルを上げる](#increase-all-the-compression-levels)ことでパフォーマンスを向上させることができます。
 
 ### Titanを有効にする {#enable-titan}
 
@@ -65,11 +65,11 @@ sdd           1033.00   4132.00   1141.33  31685.33   571.00    0.94 100.00
 
 さまざまなパブリッククラウドに推奨されるミドルレンジ ディスクは次のとおりです。
 
-- AWSでは[gp3](https://aws.amazon.com/ebs/general-purpose/)推奨されます。gp3ボリュームは、ボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分な値です。
+- AWSでは[gp3](https://aws.amazon.com/ebs/general-purpose/)が推奨されます。gp3ボリュームは、ボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分な値です。
 
 - Google Cloudでは[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)が推奨されています。IOPSとMBPSは割り当てられたディスクサイズによって異なります。パフォーマンス要件を満たすには、 Raft Engineに200GBを割り当てることを推奨します。Raft Engineはそれほど大きな容量を必要としませんが、最適なパフォーマンスを確保できます。
 
-- Azureでは[プレミアム SSD v2](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssd-v2)推奨されます。AWS gp3と同様に、Premium SSD v2はボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分です。
+- Azureでは[プレミアム SSD v2](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssd-v2)が推奨されます。AWS gp3と同様に、Premium SSD v2はボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分です。
 
 #### ハイエンドディスク {#high-end-disk}
 
@@ -77,7 +77,7 @@ Raft Engineのレイテンシーをさらに低減したい場合は、ハイエ
 
 - AWSでは[io2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html)が推奨されます。ディスクサイズとIOPSは、お客様の特定の要件に応じてプロビジョニングできます。
 
-- Google Cloud では[pd-extreme](https://cloud.google.com/compute/docs/disks#disk-types/)推奨されます。ディスクサイズ、IOPS、MBPS をプロビジョニングできますが、64 個以上の CPU コアを持つインスタンスでのみ利用可能です。
+- Google Cloud では[pd-extreme](https://cloud.google.com/compute/docs/disks#disk-types/)が推奨されます。ディスクサイズ、IOPS、MBPS をプロビジョニングできますが、64 個以上の CPU コアを持つインスタンスでのみ利用可能です。
 
 - Azure では[Ultra Disk](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#ultra-disks)が推奨されます。ディスクサイズ、IOPS、MBPS は、お客様の特定の要件に応じてプロビジョニングできます。
 

From d0d0b4aef43337071475f645dffcaa4657ca2727 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:22:44 +0900
Subject: [PATCH 19/34] i18n(ja): fix dropped particle in
 high-concurrency-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Restore を before 読みいただく, dropped after the linked
TiDB Best Practices blog reference.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/high-concurrency-best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md
index 02c5010b59a06..9c38daa008f64 100644
--- a/best-practices/high-concurrency-best-practices.md
+++ b/best-practices/high-concurrency-best-practices.md
@@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/high-concurrency-best-practices/','/ja/tidb/dev/high-
 
 ## 対象読者 {#target-audience}
 
-このドキュメントは、読者がTiDBの基礎を理解していることを前提としています。まず、TiDBの基礎を解説した以下の3つのブログ記事と、 [TiDB ベストプラクティス](https://www.pingcap.com/blog/tidb-best-practice/)読みいただくことをお勧めします。
+このドキュメントは、読者がTiDBの基礎を理解していることを前提としています。まず、TiDBの基礎を解説した以下の3つのブログ記事と、 [TiDB ベストプラクティス](https://www.pingcap.com/blog/tidb-best-practice/)を読みいただくことをお勧めします。
 
 - [データストレージ](https://www.pingcap.com/blog/tidb-internal-data-storage/)
 - [コンピューティング](https://www.pingcap.com/blog/tidb-internal-computing/)

From f34a117e607714b7995c967c9abb2219fbd77648 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:22:44 +0900
Subject: [PATCH 20/34] i18n(ja): fix more dropped particles in
 pd-scheduling-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Restore を before 参考にして (dropped after the linked Load
balancing reference), before 大きく調整する (max-store-down-time),
and before 加算した (evict-leader-scheduler).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/pd-scheduling-best-practices.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md
index 37f5ec07ab59a..e26bc4d1b6686 100644
--- a/best-practices/pd-scheduling-best-practices.md
+++ b/best-practices/pd-scheduling-best-practices.md
@@ -206,7 +206,7 @@ PDの評価メカニズムでは、異なるストアのリーダー数とリー
 
 - 負荷の不均衡を引き起こすホットリージョンがあります。この場合、 [ホットリージョンのスケジュール](#hot-regions-are-not-evenly-distributed)に基づいてさらに分析する必要があります。
 - 空きリージョンや小さなリージョンが多数存在するため、ストア間でリーダーの数に大きな差が生じ、 Raftストアへの負荷が高くなります。このような状況では、 [リージョンの統合](#region-merge-is-slow)スケジューリングが適しています。
-- ハードウェアおよびソフトウェア環境はストアによって異なります。リーダー/リージョンの配分を制御するには、 [負荷分散](#load-balancing)参考にして`leader-weight`と`region-weight`の値を調整してください。
+- ハードウェアおよびソフトウェア環境はストアによって異なります。リーダー/リージョンの配分を制御するには、 [負荷分散](#load-balancing)を参考にして`leader-weight`と`region-weight`の値を調整してください。
 - その他の不明な理由。ただし、 `leader-weight`と`region-weight`の値を調整することで、リーダー/リージョンの配分を制御することができます。
 
 異なるストア間で評価に大きな差がある場合は、オペレーター関連の指標、特にオペレーターの生成と実行に焦点を当てて調査する必要があります。主な状況としては、以下の2つが挙げられます。
@@ -291,9 +291,9 @@ v3.0.4およびv2.1.16以前では、特定の状況（主にテーブルの削
 
 TiKV ノードに障害が発生した場合、PD はデフォルトで、対応するノードを 30分後 (設定項目`max-store-down-time`でカスタマイズ可能) に**ダウン**状態に設定し、関係するリージョンのレプリカを再調整します。
 
-実用的には、ノード障害が回復不可能と判断された場合、直ちにオフラインにすることができます。これにより、PDはすぐに別のノードにレプリカを補充し、データ損失のリスクを軽減します。一方、ノードが回復可能と判断されたものの、30分以内に回復できない場合は、タイムアウト後にレプリカの不必要な補充とリソースの浪費を回避するために、一時的に`max-store-down-time`大きく調整することができます。
+実用的には、ノード障害が回復不可能と判断された場合、直ちにオフラインにすることができます。これにより、PDはすぐに別のノードにレプリカを補充し、データ損失のリスクを軽減します。一方、ノードが回復可能と判断されたものの、30分以内に回復できない場合は、タイムアウト後にレプリカの不必要な補充とリソースの浪費を回避するために、一時的に`max-store-down-time`を大きく調整することができます。
 
-TiDB v5.2.0以降、TiKVは低速ディスクノードを検出するメカニズムを導入しました。このメカニズムは、TiKV内のリクエストをサンプリングすることで、1から100までのスコアを算出します。スコアが80以上のTiKVノードは低速としてマークされます。[`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe)を追加することで、低速ノードをスケジュールできます。低速と検出されたTiKVノードが1つだけで、その低速スコアが上限（デフォルトでは80）に達した場合、そのノードのリーダーは排除されます（ `evict-leader-scheduler`加算した場合と同様の効果）。
+TiDB v5.2.0以降、TiKVは低速ディスクノードを検出するメカニズムを導入しました。このメカニズムは、TiKV内のリクエストをサンプリングすることで、1から100までのスコアを算出します。スコアが80以上のTiKVノードは低速としてマークされます。[`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe)を追加することで、低速ノードをスケジュールできます。低速と検出されたTiKVノードが1つだけで、その低速スコアが上限（デフォルトでは80）に達した場合、そのノードのリーダーは排除されます（ `evict-leader-scheduler`を加算した場合と同様の効果）。
 
 v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニズムを導入しました。低速ディスクノード検出と同様に、このメカニズムはTiKVノード間のネットワークレイテンシーをプローブし、スコアを計算することで低速ノードを特定します。このメカニズムを有効にするには[`enable-network-slow-store`](/pd-control.md#scheduler-config-evict-slow-store-scheduler)を指定します（デフォルトでは無効）。
 

From 56efe3f1b58efce64c6ccfa4be03e97d3e83eb0e Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:22:44 +0900
Subject: [PATCH 21/34] i18n(ja): fix another dropped particle in
 tidb-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Restore を before ご覧ください, dropped after the linked
migration tool overview reference.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/tidb-best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md
index f81d688f5f5c9..eccb373a3d041 100644
--- a/best-practices/tidb-best-practices.md
+++ b/best-practices/tidb-best-practices.md
@@ -203,7 +203,7 @@ TiDB 4.0 以降、TiDB は使いやすさを向上させるために[TiDB Dashbo
 
 TiDB には、中国語と英語の両方で多数の公式文書があります。問題が発生した場合は、 [FAQ](/faq/tidb-faq.md)と[TiDB クラスタトラブルシューティングガイド](/troubleshoot-tidb-cluster.md)から始めることができます。 [TiDBリポジトリ（GitHub）](https://github.com/pingcap/tidb)でIssueリストを検索したり、Issueを作成したりすることもできます。
 
-TiDB には便利な移行ツールも多数あります。詳細については、[移行ツールの概要](/ecosystem-tool-user-guide.md)ご覧ください。
+TiDB には便利な移行ツールも多数あります。詳細については、[移行ツールの概要](/ecosystem-tool-user-guide.md)をご覧ください。
 
 TiDB の技術的な詳細に関する記事については、 [PingCAP公式ブログサイト](https://pingcap.com/blog/)を参照してください。
 

From e448a8c5a6ac4c0eed36520d4e2db37f14fba912 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:22:44 +0900
Subject: [PATCH 22/34] i18n(ja): fix another dropped particle in
 tidb-partitioned-tables-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Restore の before 手順に従います, dropped after the linked
best-practices reference for non-clustered partitioned tables.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/tidb-partitioned-tables-best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md
index b94337e60e2df..ca4dbfd2f7476 100644
--- a/best-practices/tidb-partitioned-tables-best-practices.md
+++ b/best-practices/tidb-partitioned-tables-best-practices.md
@@ -599,7 +599,7 @@ SHOW TABLE employees PARTITION (p4) regions;
 
 #### ベストプラクティス {#best-practices}
 
-新しいレンジパーティションによって発生するホットスポットの問題を軽減するには、 [非クラスター化パーティションテーブルのベストプラクティス](#best-practices)手順に従います。
+新しいレンジパーティションによって発生するホットスポットの問題を軽減するには、 [非クラスター化パーティションテーブルのベストプラクティス](#best-practices)の手順に従います。
 
 ### クラスター化された非パーティションテーブルのソリューション {#solutions-for-clustered-non-partitioned-tables}
 

From da3f10a64ef849b44a8fbd11d3ab813f2f1f4b41 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:23:29 +0900
Subject: [PATCH 23/34] i18n(ja): fix 2 more dropped particles in
 tidb-partitioned-tables-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Restore の before パフォーマンスに関する調査結果 and は before the
DROP PARTITION comparison bullet, both dropped after the backticked
DROP PARTITION term.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/tidb-partitioned-tables-best-practices.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/best-practices/tidb-partitioned-tables-best-practices.md b/best-practices/tidb-partitioned-tables-best-practices.md
index ca4dbfd2f7476..b103916a1a6f4 100644
--- a/best-practices/tidb-partitioned-tables-best-practices.md
+++ b/best-practices/tidb-partitioned-tables-best-practices.md
@@ -255,11 +255,11 @@ TTL パフォーマンスに関する調査結果は次のとおりです。
 - 100 スレッドの場合、TTL は最大 2,000 万行を処理できますが、実行時間は 15 ～ 30分に増加し、変動も大きくなります。
 - 負荷が高い場合、TTL ジョブは追加のスキャンと削除のオーバーヘッドにより全体的な QPS を低下させます。
 
-`DROP PARTITION`パフォーマンスに関する調査結果は次のとおりです。
+`DROP PARTITION`のパフォーマンスに関する調査結果は次のとおりです。
 
 - `ALTER TABLE ... DROP PARTITION`ステートメントは、パーティション全体をほぼ即座に削除します。
 - この操作はメタデータ レベルで実行されるため、最小限のリソースしか使用されません。
-- `DROP PARTITION` 、特に大規模な履歴データセットの場合、TTL よりも高速で予測可能です。
+- `DROP PARTITION`は、特に大規模な履歴データセットの場合、TTL よりも高速で予測可能です。
 
 #### TiDBでTTLと`DROP PARTITION`を使用する {#use-ttl-and-drop-partition-in-tidb}
 

From d0c3e67bf6afb832f73cd80c1b4a9c72bea69988 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:24:06 +0900
Subject: [PATCH 24/34] i18n(ja): fix another dropped particle in
 index-management-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Restore を before 提供しています, dropped after the linked
schema_unused_indexes reference.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/index-management-best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md
index 807fb95afa493..9c917f3cd7855 100644
--- a/best-practices/index-management-best-practices.md
+++ b/best-practices/index-management-best-practices.md
@@ -167,7 +167,7 @@ ORDER BY total_queries DESC;
 
 ## `schema_unused_indexes`を使用して未使用のインデックスを識別する {#identify-unused-indexes-using-schema-unused-indexes}
 
-インデックス使用状況データを手動で分析するのは時間がかかります。このプロセスを簡素化するために、TiDBは[`schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md)提供しています。これは、データベースの最後の再起動以降に使用されていないインデックスを一覧表示するシステムビューです。
+インデックス使用状況データを手動で分析するのは時間がかかります。このプロセスを簡素化するために、TiDBは[`schema_unused_indexes`](/sys-schema/sys-schema-unused-indexes.md)を提供しています。これは、データベースの最後の再起動以降に使用されていないインデックスを一覧表示するシステムビューです。
 
 これにより、次の操作を簡単に実行できるようになります。
 

From c9355f3436a288ba08107322ae7ca6c3d26c59d4 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:28:10 +0900
Subject: [PATCH 25/34] i18n(ja): keep Premium SSD v2 as a literal product name

Restore the Azure disk product name to literal English in the link
text, matching its own literal use in the following sentence and the
literal treatment of every other disk product name in this file
(gp3, io2, pd-ssd, pd-extreme, Ultra Disk).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/best-practices-on-public-cloud.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md
index 6e9aaea8f274b..18400cf44f4a7 100644
--- a/best-practices/best-practices-on-public-cloud.md
+++ b/best-practices/best-practices-on-public-cloud.md
@@ -69,7 +69,7 @@ sdd           1033.00   4132.00   1141.33  31685.33   571.00    0.94 100.00
 
 - Google Cloudでは[pd-ssd](https://cloud.google.com/compute/docs/disks#disk-types/)が推奨されています。IOPSとMBPSは割り当てられたディスクサイズによって異なります。パフォーマンス要件を満たすには、 Raft Engineに200GBを割り当てることを推奨します。Raft Engineはそれほど大きな容量を必要としませんが、最適なパフォーマンスを確保できます。
 
-- Azureでは[プレミアム SSD v2](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssd-v2)が推奨されます。AWS gp3と同様に、Premium SSD v2はボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分です。
+- Azureでは[Premium SSD v2](https://learn.microsoft.com/en-us/azure/virtual-machines/disks-types#premium-ssd-v2)が推奨されます。AWS gp3と同様に、Premium SSD v2はボリュームサイズに関係なく、3000 IOPSと125 MB/秒のスループットを無料で割り当てることができ、通常はRaft Engineに十分です。
 
 #### ハイエンドディスク {#high-end-disk}
 

From 7719ddbcc8b62bfceae518b98abd52dabf613538 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:30:20 +0900
Subject: [PATCH 26/34] i18n(ja): fix TiKV master branch mistranslation in
 massive-regions-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

"TiKV master" refers to the tikv/tikv repository's master branch (the
link points to github.com/tikv/tikv/tree/master), not a "master node".
Restore it as a literal branch-name reference, matching the sibling
[`master`](.../tree/master) pattern already used in README.md, instead
of the misleading マスター rendering that implies a master/slave role.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/massive-regions-best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md
index 83527b2bfcf06..c47c315c3f9f4 100644
--- a/best-practices/massive-regions-best-practices.md
+++ b/best-practices/massive-regions-best-practices.md
@@ -80,7 +80,7 @@ TiKVでは、デフォルトで`raftstore.store-pool-size`は`2`に設定され
 
 実際の状況では、読み取りおよび書き込みリクエストはすべてのリージョンに均等に分散されるわけではなく、一部のリージョンに集中します。そのため、一時的にアイドル状態のリージョンにおけるRaftリーダーとフォロワー間のメッセージ数を最小限に抑えることができます。これはHibernate リージョンの機能です。この機能により、 Raftstoreはアイドル状態のリージョンのRaftステートマシンに、必要がない限りティックメッセージを送信しません。そのため、これらのRaftステートマシンはハートビートメッセージを生成するためにトリガーされることがなくなり、 Raftstoreのワークロードを大幅に軽減できます。
 
-[TiKVマスター](https://github.com/tikv/tikv/tree/master)では、Hibernate リージョン がデフォルトで有効になっています。この機能は必要に応じて設定できます。詳細は[Hibernateリージョンを構成する](/tikv-configuration-file.md)を参照してください。
+[TiKVのmasterブランチ](https://github.com/tikv/tikv/tree/master)では、Hibernate リージョン がデフォルトで有効になっています。この機能は必要に応じて設定できます。詳細は[Hibernateリージョンを構成する](/tikv-configuration-file.md)を参照してください。
 
 ### 方法3: `Region Merge`を有効にする {#method-3-enable-region-merge}
 

From 966e7a33076b696eccb173359b56105fb43495c7 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:33:32 +0900
Subject: [PATCH 27/34] i18n(ja): keep "cordon" as literal English, not
 katakana
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Kubernetes' own official Japanese documentation keeps "cordon" as
literal English (e.g. "cordonされたNode"), never katakanizing it.
Match that established convention instead of the katakana コルドン
used in the previous fix.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/best-practices-on-public-cloud.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/best-practices/best-practices-on-public-cloud.md b/best-practices/best-practices-on-public-cloud.md
index 18400cf44f4a7..b8653cf468744 100644
--- a/best-practices/best-practices-on-public-cloud.md
+++ b/best-practices/best-practices-on-public-cloud.md
@@ -145,7 +145,7 @@ Google Cloud の[ライブマイグレーション機能](https://cloud.google.c
 
 Google Cloud によって開始されたライブマイグレーション イベントを検出し、これらのイベントによるパフォーマンスへの影響を軽減するために、TiDB は Google のメタデータ[例](https://github.com/GoogleCloudPlatform/python-docs-samples/blob/master/compute/metadata/main.py)に基づく[監視スクリプト](https://github.com/PingCAP-QE/tidb-google-maintenance)を提供します。このスクリプトを TiDB、TiKV、PD ノードにデプロイして、メンテナンス イベントを検出できます。メンテナンス イベントが検出されると、中断を最小限に抑え、クラスタの動作を最適化するために、次のように適切なアクションが自動的に実行されます。
 
-- TiDB: TiDBノードをコルドンしてオフラインにし、TiDBポッドを削除します。これは、TiDBインスタンスのノードプールが自動スケールに設定され、TiDB専用になっていることを前提としています。ノード上で実行されている他のポッドに中断が発生する可能性があり、コルドンされたノードは自動スケーラーによって回収されることが想定されます。
+- TiDB: TiDBノードをcordonしてオフラインにし、TiDBポッドを削除します。これは、TiDBインスタンスのノードプールが自動スケールに設定され、TiDB専用になっていることを前提としています。ノード上で実行されている他のポッドに中断が発生する可能性があり、cordonされたノードは自動スケーラーによって回収されることが想定されます。
 - TiKV: メンテナンス中に、影響を受ける TiKV ストアのリーダーを削除します。
 - PD: 現在の PD インスタンスが PD リーダーである場合、リーダーを辞任します。
 

From bfa7d8941d16b8125cd40f1497764a7ad0e7cf1f Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:39:10 +0900
Subject: [PATCH 28/34] i18n(ja): fix inverted meaning of "filters out" in
 index-management-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The JA text said schema_unused_indexes "excludes" (除外する) indexes
with zero recorded query activity, inverting the actual meaning:
per the docs-cn source (筛选出, "filter/select out") and the sentence
immediately after showing SELECT * FROM sys.schema_unused_indexes
returning exactly those indexes, the view actually extracts/surfaces
them, it does not exclude them. Fixed to 抽出する. Also removed a
stray space in クエリ アクティビティ and reworded "0 個" to "0 回" to
match "zero query activity" more naturally.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/index-management-best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/best-practices/index-management-best-practices.md b/best-practices/index-management-best-practices.md
index 9c917f3cd7855..6e5a83ed5bd4c 100644
--- a/best-practices/index-management-best-practices.md
+++ b/best-practices/index-management-best-practices.md
@@ -179,7 +179,7 @@ ORDER BY total_queries DESC;
 
 ### `schema_unused_indexes`の仕組み {#how-schema-unused-indexes-works}
 
-`schema_unused_indexes`ビューは`TIDB_INDEX_USAGE`から派生しており、最後の TiDB 再起動以降にクエリ アクティビティが 0 個記録されたインデックスを自動的に除外することを意味します。
+`schema_unused_indexes`ビューは`TIDB_INDEX_USAGE`から派生しており、最後の TiDB 再起動以降にクエリアクティビティが 0 回記録されたインデックスを自動的に抽出することを意味します。
 
 未使用のインデックスのリストを取得するには、次の SQL文を実行します。
 

From de96fd48ed6d12ba25f181d991e34c648b758636 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:40:16 +0900
Subject: [PATCH 29/34] i18n(ja): keep Hibernate Region as a literal feature
 name in its heading
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The heading translated "Hibernate Region" as 休止状態リージョン while
every other occurrence of this TiKV feature name in the same file
(summary, and 2 body sentences) keeps it literal as Hibernateリージョン.
Align the heading to match, since EN itself always writes "Hibernate
Region" literally, including in this exact heading.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/massive-regions-best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md
index c47c315c3f9f4..d577034f4a134 100644
--- a/best-practices/massive-regions-best-practices.md
+++ b/best-practices/massive-regions-best-practices.md
@@ -76,7 +76,7 @@ Raftstore はTiDB v3.0 以降、マルチスレッド モジュールにアッ
 
 TiKVでは、デフォルトで`raftstore.store-pool-size`は`2`に設定されています。Raftstoreでボトルネックが発生する場合は、実際の状況に応じてこの設定項目の値を適切に増やすことができます。ただし、不要なスレッド切り替えのオーバーヘッドを回避するため、この値を高くしすぎないことをお勧めします。
 
-### 方法2: 休止状態リージョンを有効にする {#method-2-enable-hibernate-region}
+### 方法2: Hibernateリージョンを有効にする {#method-2-enable-hibernate-region}
 
 実際の状況では、読み取りおよび書き込みリクエストはすべてのリージョンに均等に分散されるわけではなく、一部のリージョンに集中します。そのため、一時的にアイドル状態のリージョンにおけるRaftリーダーとフォロワー間のメッセージ数を最小限に抑えることができます。これはHibernate リージョンの機能です。この機能により、 Raftstoreはアイドル状態のリージョンのRaftステートマシンに、必要がない限りティックメッセージを送信しません。そのため、これらのRaftステートマシンはハートビートメッセージを生成するためにトリガーされることがなくなり、 Raftstoreのワークロードを大幅に軽減できます。
 

From ed653c3acc3c120729297e6a1137230400f2b58f Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:43:36 +0900
Subject: [PATCH 30/34] =?UTF-8?q?i18n(ja):=20unify=20literal=20"Leader"=20?=
 =?UTF-8?q?to=20katakana=20=E3=83=AA=E3=83=BC=E3=83=80=E3=83=BC=20in=20hig?=
 =?UTF-8?q?h-concurrency-best-practices.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The file mixed literal English "Leader" (Region Leader, Raft Group
Leader) with katakana リーダー for the same concept, including both
forms within a single sentence at one point. EN itself capitalizes
this term inconsistently (Region Leader vs. leader election vs.
Region leader), so it is not a fixed literal identifier. Unify to
リーダー, matching this file's own majority usage and the established
corpus-wide convention (PDリーダー, リージョンリーダー).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/high-concurrency-best-practices.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md
index 9c38daa008f64..ddf0d3bbdf663 100644
--- a/best-practices/high-concurrency-best-practices.md
+++ b/best-practices/high-concurrency-best-practices.md
@@ -35,7 +35,7 @@ aliases: ['/ja/tidb/stable/high-concurrency-best-practices/','/ja/tidb/dev/high-
 
 上記の課題に対処するには、TiDBのデータセグメンテーションとスケジューリングの原理から始める必要があります。詳細については[スケジュール](https://www.pingcap.com/blog/tidb-internal-scheduling/)を参照してください。
 
-TiDBはデータをリージョンに分割します。リージョンはそれぞれ、デフォルトで96MBのサイズ制限を持つデータ範囲を表します。各リージョンには複数のレプリカがあり、レプリカの各グループはRaftグループと呼ばれます。Raftグループでは、リージョンLeaderがデータ範囲内の読み取りおよび書き込みタスク（TiDBは[フォロワー読み取り](/follower-read.md)をサポート）を実行します。リージョンLeaderは、Placement Driver （PD）コンポーネントによって自動的に異なる物理ノードにスケジュールされ、読み取りおよび書き込みの負荷を均等に分散します。
+TiDBはデータをリージョンに分割します。リージョンはそれぞれ、デフォルトで96MBのサイズ制限を持つデータ範囲を表します。各リージョンには複数のレプリカがあり、レプリカの各グループはRaftグループと呼ばれます。Raftグループでは、リージョンリーダーがデータ範囲内の読み取りおよび書き込みタスク（TiDBは[フォロワー読み取り](/follower-read.md)をサポート）を実行します。リージョンリーダーは、Placement Driver （PD）コンポーネントによって自動的に異なる物理ノードにスケジュールされ、読み取りおよび書き込みの負荷を均等に分散します。
 
 ![TiDB Data Overview](/media/best-practices/tidb-data-overview.png)
 
@@ -98,7 +98,7 @@ FROM
 
 ![QPS3](/media/best-practices/QPS3.png)
 
-[Raft store CPU](/grafana-tikv-dashboard.md)はスレッド`raftstore`のCPU使用率で、通常は書き込み負荷を表します。このシナリオでは、 `tikv-3`がこのRaftグループのLeader、 `tikv-0`と`tikv-1`がフォロワーです。他のノードの負荷はほぼ空です。
+[Raft store CPU](/grafana-tikv-dashboard.md)はスレッド`raftstore`のCPU使用率で、通常は書き込み負荷を表します。このシナリオでは、 `tikv-3`がこのRaftグループのリーダー、 `tikv-0`と`tikv-1`がフォロワーです。他のノードの負荷はほぼ空です。
 
 PD の監視メトリックでも、ホットスポットが発生したことが確認されます。
 
@@ -116,7 +116,7 @@ PD の監視メトリックでも、ホットスポットが発生したこと
 
 ![TiKV Region Split](/media/best-practices/tikv-Region-split.png)
 
-上の図は、リージョン分割プロセスを示しています。データがTiKVに継続的に書き込まれると、TiKVはリージョンを複数のリージョンに分割します。リーダー選出は、分割対象のリージョンLeaderが配置されている元のストアで開始されるため、新しく分割された2つのリージョンのリーダーは同じストアに残っている可能性があります。この分割プロセスは、新しく分割されたリージョン2とリージョン3でも発生する可能性があります。このように、書き込み負荷はTiKVノード1に集中します。
+上の図は、リージョン分割プロセスを示しています。データがTiKVに継続的に書き込まれると、TiKVはリージョンを複数のリージョンに分割します。リーダー選出は、分割対象のリージョンリーダーが配置されている元のストアで開始されるため、新しく分割された2つのリージョンのリーダーは同じストアに残っている可能性があります。この分割プロセスは、新しく分割されたリージョン2とリージョン3でも発生する可能性があります。このように、書き込み負荷はTiKVノード1に集中します。
 
 継続的な書き込みプロセス中、ノード1でホットスポットが発生していることを検出すると、PDは集中しているリーダーノードを他のノードに均等に分散させます。TiKVノードの数がリージョンレプリカの数よりも多い場合、TiKVはこれらのリージョンをアイドルノードに移行しようとします。書き込みプロセス中のこれらの2つの操作は、PDの監視メトリクスにも反映されます。
 

From 187254c731e0f4332303c4764be72cf59f11b3bc Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:43:36 +0900
Subject: [PATCH 31/34] i18n(ja): fix 2 more same-file notation inconsistencies
 in massive-regions-best-practices.md
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- "PD Leader" (literal English, in a heading and its body) contradicted
  the file's own summary and the corpus-wide convention of katakana
  PDリーダー. Unified to PDリーダー.
- "tick message" was rendered as fully-katakana ティックメッセージ at
  2 sites but as mixed "tick メッセージ" at a 3rd, within the same
  file. Unified to the file's majority form, ティックメッセージ.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/massive-regions-best-practices.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/best-practices/massive-regions-best-practices.md b/best-practices/massive-regions-best-practices.md
index d577034f4a134..2dc2f3a483431 100644
--- a/best-practices/massive-regions-best-practices.md
+++ b/best-practices/massive-regions-best-practices.md
@@ -119,7 +119,7 @@ I/O リソースと CPU リソースが十分な場合は、単一のマシン
 raft-base-tick-interval = "2s"
 ```
 
-上記の設定では、 `raft-base-tick-interval`は、Raftstore が各リージョンのRaftステートマシンを駆動する時間間隔です。つまり、この時間間隔でRaftstore はRaftステートマシンに tick メッセージを送信します。この間隔を長くすることで、 Raftstoreからのメッセージ数を効果的に減らすことができます。
+上記の設定では、 `raft-base-tick-interval`は、Raftstore が各リージョンのRaftステートマシンを駆動する時間間隔です。つまり、この時間間隔でRaftstore はRaftステートマシンにティックメッセージを送信します。この間隔を長くすることで、 Raftstoreからのメッセージ数を効果的に減らすことができます。
 
 ティックメッセージ間のこの間隔は、 `election timeout`と`heartbeat`の間の間隔も決定することに注意してください。次の例をご覧ください。
 
@@ -154,9 +154,9 @@ TiKVノード間のRaft通信に使用される最大接続数を調整するに
 
 このセクションでは、その他の問題と解決策について説明します。
 
-### PD Leaderの切り替えが遅い {#switching-pd-leader-is-slow}
+### PDリーダーの切り替えが遅い {#switching-pd-leader-is-slow}
 
-PDは、PD Leaderノードの切り替え後、迅速にリージョンルーティングサービスを再開できるように、etcdにリージョンメタ情報を保持する必要があります。リージョン数が増えると、etcdのパフォーマンス問題が発生し、PDがLeaderを切り替える際に、etcdからリージョンメタ情報を取得するのに時間がかかります。数百万のリージョンが存在する場合、etcdからメタ情報を取得するのに10秒以上、場合によっては数十秒かかることがあります。
+PDは、PDリーダーノードの切り替え後、迅速にリージョンルーティングサービスを再開できるように、etcdにリージョンメタ情報を保持する必要があります。リージョン数が増えると、etcdのパフォーマンス問題が発生し、PDがリーダーを切り替える際に、etcdからリージョンメタ情報を取得するのに時間がかかります。数百万のリージョンが存在する場合、etcdからメタ情報を取得するのに10秒以上、場合によっては数十秒かかることがあります。
 
 この問題に対処するため、TiDB v3.0以降、PDではデフォルトで`use-region-storage`が有効になっています。この機能を有効にすると、PDはリージョンメタ情報をローカルLevelDBに保存し、他のメカニズムを通じてPDノード間で情報を同期します。
 

From 35497d561d9e474827049761425ae2b08ba78100 Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:43:36 +0900
Subject: [PATCH 32/34] =?UTF-8?q?i18n(ja):=20unify=20literal=20"Leader"=20?=
 =?UTF-8?q?to=20katakana=20=E3=83=AA=E3=83=BC=E3=83=80=E3=83=BC=20in=20pd-?=
 =?UTF-8?q?scheduling-best-practices.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

A Note block used bolded literal "Leaderの排除" 3 times, standing out
against this file's otherwise near-universal use of katakana リーダー
(30+ occurrences). Unified to リーダーの排除 for consistency.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/pd-scheduling-best-practices.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/best-practices/pd-scheduling-best-practices.md b/best-practices/pd-scheduling-best-practices.md
index e26bc4d1b6686..7d05b8d302408 100644
--- a/best-practices/pd-scheduling-best-practices.md
+++ b/best-practices/pd-scheduling-best-practices.md
@@ -299,4 +299,4 @@ v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニ
 
 > **Note:**
 >
-> **Leaderの排除**は、PDがTiKVの低速ノードにスケジューリングリクエストを送信し、TiKVが受信したスケジューリングリクエストを順次実行することで実現されます。**低速I/O**などの要因により、低速ノードではリクエストが蓄積され、一部のリーダーは遅延したリクエストが処理されるまで**Leaderの排除**リクエストを処理できない場合があります。その結果、**Leaderの排除**にかかる時間が全体的に長くなります。したがって、 `evict-slow-store-scheduler`を有効にする場合は、この状況を緩和するために[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)も有効にすることをお勧めします。
+> **リーダーの排除**は、PDがTiKVの低速ノードにスケジューリングリクエストを送信し、TiKVが受信したスケジューリングリクエストを順次実行することで実現されます。**低速I/O**などの要因により、低速ノードではリクエストが蓄積され、一部のリーダーは遅延したリクエストが処理されるまで**リーダーの排除**リクエストを処理できない場合があります。その結果、**リーダーの排除**にかかる時間が全体的に長くなります。したがって、 `evict-slow-store-scheduler`を有効にする場合は、この状況を緩和するために[`store-io-pool-size`](/tikv-configuration-file.md#store-io-pool-size-new-in-v530)も有効にすることをお勧めします。

From a7f84e2cf3179a1b540dfb3bb3bd09318bdf76ed Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 14:48:06 +0900
Subject: [PATCH 33/34] =?UTF-8?q?i18n(ja):=20reword=20=E3=83=A1=E3=83=A2?=
 =?UTF-8?q?=E3=83=AA=E4=BB=95=E6=A7=98=20to=20=E3=83=A1=E3=83=A2=E3=83=AA?=
 =?UTF-8?q?=E5=89=B2=E3=82=8A=E5=BD=93=E3=81=A6=20for=20naturalness?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

"仕様" (specification) is not naturally something you "increase" in
Japanese; reworded both occurrences to 割り当て (allocation), matching
the intended meaning of "increase memory specifications" (i.e. the
amount of memory allocated).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/saas-best-practices.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/best-practices/saas-best-practices.md b/best-practices/saas-best-practices.md
index cd0312ff1ea5e..a2aab5621b1bc 100644
--- a/best-practices/saas-best-practices.md
+++ b/best-practices/saas-best-practices.md
@@ -77,8 +77,8 @@ TiKV および PD に推奨されるハードウェア構成は次のとおり
 SaaSマルチテナントシナリオでは、通常、各ユーザーはTiDBに接続して自身のテナント（データベース）内のデータを操作します。多数の接続をサポートするには、次の点に留意してください。
 
 - より多くの同時リクエストをサポートするには、TiDB 設定項目[`token-limit`](/tidb-configuration-file.md#token-limit) (デフォルトでは`1000` ) を増やします。
-- TiDBのメモリ使用量は接続数にほぼ比例します。実際のテストでは、アイドル接続が20万件あると、TiDBのメモリ使用量が約30GiB増加しました。実際の接続数に基づいて、TiDBのメモリ仕様を増やすことをお勧めします。
-- `PREPARED`ステートメントを使用する場合、各接続はセッションレベルのプリペアドプランキャッシュを維持します。`DEALLOCATE`文が長時間実行されない場合、キャッシュに過剰なプランが蓄積され、メモリ使用量が増加する可能性があります。実際のテストでは、 `IndexRangeScan`を含む 400,000 の実行計画で約 5 GiB のメモリが消費されました。これに応じてメモリ仕様を増やすことをお勧めします。
+- TiDBのメモリ使用量は接続数にほぼ比例します。実際のテストでは、アイドル接続が20万件あると、TiDBのメモリ使用量が約30GiB増加しました。実際の接続数に基づいて、TiDBのメモリ割り当てを増やすことをお勧めします。
+- `PREPARED`ステートメントを使用する場合、各接続はセッションレベルのプリペアドプランキャッシュを維持します。`DEALLOCATE`文が長時間実行されない場合、キャッシュに過剰なプランが蓄積され、メモリ使用量が増加する可能性があります。実際のテストでは、 `IndexRangeScan`を含む 400,000 の実行計画で約 5 GiB のメモリが消費されました。これに応じてメモリ割り当てを増やすことをお勧めします。
 
 ## ステイル読み取りは慎重に使用してください {#use-stale-read-carefully}
 

From 286776ee1ed17bcb18d57f18691a63c859ccf64c Mon Sep 17 00:00:00 2001
From: Yasuo Honda <yahonda@pingcap.com>
Date: Wed, 16 Sep 2026 15:02:39 +0900
Subject: [PATCH 34/34] i18n(ja): apply CodeRabbit fixes for scrambled clause
 order and incomplete predicates
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- grafana-monitor-best-practices.md: separate the topology-update
  clause (add Grafana and Prometheus) from the TiUP-deploy link, which
  had been left as the object of 追加する after an earlier partial fix.
- high-concurrency-best-practices.md: add the honorific お prefix
  (お読みいただく, not 読みいただく) and complete the follower-read
  parenthetical (サポートしています, not the bare stem サポート).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
---
 best-practices/grafana-monitor-best-practices.md  | 2 +-
 best-practices/high-concurrency-best-practices.md | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/best-practices/grafana-monitor-best-practices.md b/best-practices/grafana-monitor-best-practices.md
index 74011148a263d..01031623af787 100644
--- a/best-practices/grafana-monitor-best-practices.md
+++ b/best-practices/grafana-monitor-best-practices.md
@@ -6,7 +6,7 @@ aliases: ['/ja/docs/dev/best-practices/grafana-monitor-best-practices/','/ja/doc
 
 # Grafana を使用した TiDB 監視のベストプラクティス {#best-practices-for-monitoring-tidb-using-grafana}
 
-トポロジ構成にGrafanaとPrometheus [TiUPを使用してTiDBクラスタをデプロイする](/production-deployment-using-tiup.md)を追加すると、TiDBクラスター内の様々なコンポーネントとマシンのメトリクスを収集・表示するために、 [Grafana + Prometheus 監視プラットフォーム](/tidb-monitoring-framework.md)のツールセットが同時にデプロイされます。このドキュメントでは、Grafanaを用いたTiDBの監視に関するベストプラクティスについて説明します。メトリクスを用いてTiDBクラスターの状態を分析し、問題を診断するのに役立つことを目的としています。
+トポロジ構成にGrafanaとPrometheusを追加し、[TiUPを使用してTiDBクラスタをデプロイする](/production-deployment-using-tiup.md)と、TiDBクラスター内の様々なコンポーネントとマシンのメトリクスを収集・表示するために、 [Grafana + Prometheus 監視プラットフォーム](/tidb-monitoring-framework.md)のツールセットが同時にデプロイされます。このドキュメントでは、Grafanaを用いたTiDBの監視に関するベストプラクティスについて説明します。メトリクスを用いてTiDBクラスターの状態を分析し、問題を診断するのに役立つことを目的としています。
 
 ## 監視アーキテクチャ {#monitoring-architecture}
 
diff --git a/best-practices/high-concurrency-best-practices.md b/best-practices/high-concurrency-best-practices.md
index ddf0d3bbdf663..6c69488d67b5e 100644
--- a/best-practices/high-concurrency-best-practices.md
+++ b/best-practices/high-concurrency-best-practices.md
@@ -10,7 +10,7 @@ aliases: ['/ja/tidb/stable/high-concurrency-best-practices/','/ja/tidb/dev/high-
 
 ## 対象読者 {#target-audience}
 
-このドキュメントは、読者がTiDBの基礎を理解していることを前提としています。まず、TiDBの基礎を解説した以下の3つのブログ記事と、 [TiDB ベストプラクティス](https://www.pingcap.com/blog/tidb-best-practice/)を読みいただくことをお勧めします。
+このドキュメントは、読者がTiDBの基礎を理解していることを前提としています。まず、TiDBの基礎を解説した以下の3つのブログ記事と、 [TiDB ベストプラクティス](https://www.pingcap.com/blog/tidb-best-practice/)をお読みいただくことをお勧めします。
 
 - [データストレージ](https://www.pingcap.com/blog/tidb-internal-data-storage/)
 - [コンピューティング](https://www.pingcap.com/blog/tidb-internal-computing/)
@@ -35,7 +35,7 @@ aliases: ['/ja/tidb/stable/high-concurrency-best-practices/','/ja/tidb/dev/high-
 
 上記の課題に対処するには、TiDBのデータセグメンテーションとスケジューリングの原理から始める必要があります。詳細については[スケジュール](https://www.pingcap.com/blog/tidb-internal-scheduling/)を参照してください。
 
-TiDBはデータをリージョンに分割します。リージョンはそれぞれ、デフォルトで96MBのサイズ制限を持つデータ範囲を表します。各リージョンには複数のレプリカがあり、レプリカの各グループはRaftグループと呼ばれます。Raftグループでは、リージョンリーダーがデータ範囲内の読み取りおよび書き込みタスク（TiDBは[フォロワー読み取り](/follower-read.md)をサポート）を実行します。リージョンリーダーは、Placement Driver （PD）コンポーネントによって自動的に異なる物理ノードにスケジュールされ、読み取りおよび書き込みの負荷を均等に分散します。
+TiDBはデータをリージョンに分割します。リージョンはそれぞれ、デフォルトで96MBのサイズ制限を持つデータ範囲を表します。各リージョンには複数のレプリカがあり、レプリカの各グループはRaftグループと呼ばれます。Raftグループでは、リージョンリーダーがデータ範囲内の読み取りおよび書き込みタスク（TiDBは[フォロワー読み取り](/follower-read.md)をサポートしています）を実行します。リージョンリーダーは、Placement Driver （PD）コンポーネントによって自動的に異なる物理ノードにスケジュールされ、読み取りおよび書き込みの負荷を均等に分散します。
 
 ![TiDB Data Overview](/media/best-practices/tidb-data-overview.png)