pingcap · yahonda · Aug 28, 2026 · Aug 28, 2026 · Aug 28, 2026 · Aug 28, 2026
diff --git a/TOC-best-practices.md b/TOC-best-practices.md
@@ -16,11 +16,11 @@
 - [複数列インデックスの最適化](/best-practices/multi-column-index-best-practices.md)
 - [インデックスを管理し、未使用のインデックスを特定する](/best-practices/index-management-best-practices.md)
 
-## 展開
+## デプロイ
 
 - [パブリッククラウドにTiDBをデプロイ](/best-practices/best-practices-on-public-cloud.md)
-- [3ノードのハイブリッド展開](/best-practices/three-nodes-hybrid-deployment.md)
-- [3つのデータセンター展開におけるローカル読み取り](/best-practices/three-dc-local-read.md)
+- [3ノードのハイブリッドデプロイ](/best-practices/three-nodes-hybrid-deployment.md)
+- [3つのデータセンターデプロイにおけるローカル読み取り](/best-practices/three-dc-local-read.md)
 
 ## オペレーション
 

diff --git a/TOC.md b/TOC.md
@@ -299,9 +299,9 @@
       - [オプティマイザ修正コントロール](/optimizer-fix-controls.md)
     - [インデックスアドバイザー](/index-advisor.md)
 - チュートリアル
-  - [1つのリージョンに複数のアベイラビリティゾーンを展開](/multi-data-centers-in-one-city-deployment.md)
-  - [2つのリージョンに3つのアベイラビリティゾーンを展開](/three-data-centers-in-two-cities-deployment.md)
-  - [1つのリージョン展開で2つのアベイラビリティゾーンを実現](/two-data-centers-in-one-city-deployment.md)
+  - [1つのリージョンに複数のアベイラビリティゾーンをデプロイ](/multi-data-centers-in-one-city-deployment.md)
+  - [2つのリージョンに3つのアベイラビリティゾーンをデプロイ](/three-data-centers-in-two-cities-deployment.md)
+  - [1つのリージョンデプロイで2つのアベイラビリティゾーンを実現](/two-data-centers-in-one-city-deployment.md)
   - 履歴データを読む
     - ステイル読み取りを使用する（推奨）
       - [ステイル読み取りの使用シナリオ](/stale-read.md)

diff --git a/auto-increment.md b/auto-increment.md
@@ -284,7 +284,7 @@ mysql> SELECT * FROM t ORDER BY b;
 11 rows in set (0.00 sec)
 ```
 
-値`2030000`が挿入された後、次の値は`2060001`です。このシーケンスのジャンプは、別の TiDBサーバーが中間キャッシュ範囲`[2030001-2060000]`を取得しているためです。複数の TiDB サーバーが展開されている場合、キャッシュ要求がインターリーブされるため、 `AUTO_INCREMENT`シーケンスにギャップが生じます。
+値`2030000`が挿入された後、次の値は`2060001`です。このシーケンスのジャンプは、別の TiDBサーバーが中間キャッシュ範囲`[2030001-2060000]`を取得しているためです。複数の TiDB サーバーがデプロイされている場合、キャッシュ要求がインターリーブされるため、 `AUTO_INCREMENT`シーケンスにギャップが生じます。
 
 ### キャッシュサイズの制御 {#cache-size-control}
 

diff --git a/basic-features.md b/basic-features.md
@@ -285,7 +285,7 @@ summary: TiDBの機能概要について学びましょう。
 | [明細書の要約表](/statement-summary-tables.md)                                                                                                                                                                                                                                |  Y  |  Y  |  Y  |  Y  |  Y  |  Y  |  Y  |
 | [ステートメントの要約テーブル - 要約の永続化](/statement-summary-tables.md#persist-statements-summary)                                                                                                                                                                                     |  E  |  E  |  E  |  E  |  N  |  N  |  N  |
 | [スロークエリログ](/identify-slow-queries.md)                                                                                                                                                                                                                                  |  Y  |  Y  |  Y  |  Y  |  Y  |  Y  |  Y  |
-| [TiUPの展開](/tiup/tiup-overview.md)                                                                                                                                                                                                                                      |  Y  |  Y  |  Y  |  Y  |  Y  |  Y  |  Y  |
+| [TiUPのデプロイ](/tiup/tiup-overview.md)                                                                                                                                                                                                                                      |  Y  |  Y  |  Y  |  Y  |  Y  |  Y  |  Y  |
 | [Kubernetes オペレーター](https://docs.pingcap.com/tidb-in-kubernetes/)                                                                                                                                                                                                      |  Y  |  Y  |  Y  |  Y  |  Y  |  Y  |  Y  |
 | [内蔵の物理バックアップ](/br/backup-and-restore-use-cases.md)                                                                                                                                                                                                                     |  Y  |  Y  |  Y  |  Y  |  Y  |  Y  |  Y  |
 | [グローバルキル](/sql-statements/sql-statement-kill.md)                                                                                                                                                                                                                       |  Y  |  Y  |  Y  |  Y  |  Y  |  Y  |  E  |

diff --git a/benchmark/benchmark-tidb-using-sysbench.md b/benchmark/benchmark-tidb-using-sysbench.md
@@ -172,4 +172,4 @@ TiKV 全体の CPU 使用率は低いですが、クラスター内の一部の
 
 NUMAアーキテクチャのCPUは、一部のハイエンド機器で使用されています。これらの機器では、リモートメモリへのCPU間アクセスによってパフォーマンスが大幅に低下します。デフォルトでは、TiDBはサーバーのすべてのCPUを使用するため、goroutineスケジューリングによって必然的にCPU間メモリアクセスが発生します。
 
-したがって、NUMAアーキテクチャのサーバーに*n 個の*TiDB ( *n*は NUMA CPU の数) を展開し、同時に TiDB パラメータ`max-procs` NUMA CPU コアの数と同じ値に設定することをお勧めします。
+したがって、NUMAアーキテクチャのサーバーに*n 個の*TiDB ( *n*は NUMA CPU の数) をデプロイし、同時に TiDB パラメータ`max-procs` NUMA CPU コアの数と同じ値に設定することをお勧めします。
diff --git a/benchmark/benchmark-tidb-using-tpcc.md b/benchmark/benchmark-tidb-using-tpcc.md
@@ -37,7 +37,7 @@ tiup install bench
 
 TiUP Benchコンポーネントの詳細な使用方法については、 [TiUP Bench](/tiup/tiup-bench.md)を参照してください。
 
-172.16.5.140 と 172.16.5.141 にある 2つの TiDB サーバーを含む TiDB クラスターを展開し、両方のサーバーがポート 4000 でリッスンしているとします。次の手順で TPC-C テストを実行できます。
+172.16.5.140 と 172.16.5.141 にある 2つの TiDB サーバーを含む TiDB クラスターをデプロイし、両方のサーバーがポート 4000 でリッスンしているとします。次の手順で TPC-C テストを実行できます。
 
 ## データを読み込む {#load-data}
 

diff --git a/best-practices/_index.md b/best-practices/_index.md
@@ -34,7 +34,7 @@ TiDBにおけるスキーマ設計のベストプラクティスを学びまし
 | ベストプラクティスのトピック                                                           | 説明                                                                                          |
 | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- |
 | [TiDBをパブリッククラウドにデプロイ](/best-practices/best-practices-on-public-cloud.md) | TiDBをパブリッククラウドにデプロイする際のベストプラクティス。これにより、TiDBデプロイメントのパフォーマンス、コスト効率、信頼性、および拡張性を最大限に高めることができます。 |
-| [3ノードハイブリッド展開](/best-practices/three-nodes-hybrid-deployment.md)         | 安定性を維持しながら、費用対効果の高いハイブリッド3ノード構成を実現するためのベストプラクティス。                                           |
+| [3ノードハイブリッドデプロイ](/best-practices/three-nodes-hybrid-deployment.md)         | 安定性を維持しながら、費用対効果の高いハイブリッド3ノード構成を実現するためのベストプラクティス。                                           |
 | [3つのデータセンター構成におけるローカル読み取り](/best-practices/three-dc-local-read.md)       | ステイル読み取りを使用してセンター間のレイテンシーを削減するためのベストプラクティス。                                                 |
 
 ## 運用 {#operations}

diff --git a/best-practices/grafana-monitor-best-practices.md b/best-practices/grafana-monitor-best-practices.md
@@ -17,7 +17,7 @@ aliases: ['/ja/docs/dev/best-practices/grafana-monitor-best-practices/','/ja/doc
 TiDB 2.1.3以降のバージョンでは、TiDBモニタリングはプル方式をサポートしています。これは以下の利点を持つ優れた調整です。
 
 - Prometheus を移行する必要がある場合、TiDB クラスター全体を再起動する必要はありません。調整前に Prometheus を移行するには、ターゲットアドレスを更新する必要があるため、クラスター全体を再起動する必要があります。
-- 監視ポイントが単一になるのを防ぐために、Grafana + Prometheus 監視プラットフォーム (高可用性ではない) の 2つの個別のセットを展開できます。
+- 監視ポイントが単一になるのを防ぐために、Grafana + Prometheus 監視プラットフォーム (高可用性ではない) の 2つの個別のセットをデプロイできます。
 - 単一障害点となる可能性のある Pushgateway が削除されます。
 
 ## 監視データのソースと表示 {#source-and-display-of-monitoring-data}

diff --git a/best-practices/three-dc-local-read.md b/best-practices/three-dc-local-read.md
@@ -1,18 +1,18 @@
 ---
 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`に設定することで実現されます。Stale ステイル読み取りの実行方法の詳細については、ドキュメントを参照してください。
 aliases: ['/ja/tidb/stable/three-dc-local-read/']
 ---
 
-# 3つのデータセンター展開におけるローカル読み取りのベストプラクティス {#best-practices-for-local-reads-in-three-data-center-deployments}
+# 3つのデータセンターデプロイにおけるローカル読み取りのベストプラクティス {#best-practices-for-local-reads-in-three-data-center-deployments}
 
 3つのデータセンターモデルでは、リージョンには各データセンターに分離された3つのレプリカが存在します。しかし、強力な整合性のある読み取りが求められるため、TiDBはすべてのクエリにおいて、対応するデータのLeaderレプリカにアクセスする必要があります。クエリがLeaderレプリカとは異なるデータセンターで生成された場合、TiDBは別のデータセンターからデータを読み取る必要があり、アクセスレイテンシーが増加します。
 
 このドキュメントでは、 [ステイル読み取り](/stale-read.md)機能を使用して、センター間アクセスを回避し、リアルタイムのデータ可用性を犠牲にしてアクセスのレイテンシーを減らす方法について説明します。
 
 ## 3つのデータセンターのTiDBクラスタをデプロイ {#deploy-a-tidb-cluster-of-three-data-centers}
 
-3 つのデータセンターの展開方法については、 [1つの地域展開における複数のデータセンター](/multi-data-centers-in-one-city-deployment.md)を参照してください。
+3 つのデータセンターのデプロイ方法については、 [1つの地域デプロイにおける複数のデータセンター](/multi-data-centers-in-one-city-deployment.md)を参照してください。
 
 TiKVノードとTiDBノードの両方に構成項目`labels`設定されている場合、同じデータセンター内のTiKVノードとTiDBノードのラベル`zone`の値は同一である必要があります。例えば、TiKVノードとTiDBノードの両方がデータセンター`dc-1`にある場合、2つのノードに以下のラベルを設定する必要があります。
Original file line number	Diff line number	Diff line change
Expand Up		@@ -172,4 +172,4 @@ TiKV 全体の CPU 使用率は低いですが、クラスター内の一部の

		NUMAアーキテクチャのCPUは、一部のハイエンド機器で使用されています。これらの機器では、リモートメモリへのCPU間アクセスによってパフォーマンスが大幅に低下します。デフォルトでは、TiDBはサーバーのすべてのCPUを使用するため、goroutineスケジューリングによって必然的にCPU間メモリアクセスが発生します。

		したがって、NUMAアーキテクチャのサーバーにn 個のTiDB ( nは NUMA CPU の数) を展開し、同時に TiDB パラメータ`max-procs` NUMA CPU コアの数と同じ値に設定することをお勧めします。
		したがって、NUMAアーキテクチャのサーバーにn 個のTiDB ( nは NUMA CPU の数) をデプロイし、同時に TiDB パラメータ`max-procs` NUMA CPU コアの数と同じ値に設定することをお勧めします。