From a87a07397ef9cd86444fcc36a151f0c944b47951 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Fri, 28 Aug 2026 11:47:20 +0900 Subject: [PATCH 1/3] i18n(ja): unify the Japanese term for deploy/deployment (190 files) Corpus-wide sweep unifying the Japanese rendering of EN deploy/deployment to a single katakana term, while leaving untouched occurrences that correspond to a different English word (expand, roll out, extract, evolve) or the already-unified deployment-topology term. --- TOC-best-practices.md | 6 +++--- TOC.md | 6 +++--- auto-increment.md | 2 +- basic-features.md | 2 +- benchmark/benchmark-tidb-using-sysbench.md | 2 +- benchmark/benchmark-tidb-using-tpcc.md | 2 +- best-practices/_index.md | 2 +- .../grafana-monitor-best-practices.md | 2 +- best-practices/three-dc-local-read.md | 6 +++--- .../three-nodes-hybrid-deployment.md | 16 ++++++++-------- best-practices/tidb-best-practices.md | 4 ++-- binary-package.md | 2 +- br/br-monitoring-and-alert.md | 4 ++-- br/br-use-overview.md | 4 ++-- check-before-deployment.md | 8 ++++---- clinic/clinic-data-instruction-for-tiup.md | 12 ++++++------ clinic/clinic-introduction.md | 6 +++--- clinic/clinic-user-guide-for-tiup.md | 4 ++-- clinic/quick-start-with-clinic.md | 2 +- configure-memory-usage.md | 2 +- dashboard/dashboard-faq.md | 6 +++--- dashboard/dashboard-ops-reverse-proxy.md | 4 ++-- dashboard/dashboard-ops-security.md | 2 +- dashboard/dashboard-resource-manager.md | 6 +++--- .../dev-guide-sample-application-aws-lambda.md | 2 +- ...dev-guide-sample-application-ruby-mysql2.md | 2 +- .../dev-guide-sample-application-ruby-rails.md | 2 +- develop/dev-guide-use-follower-read.md | 4 ++-- dm/deploy-a-dm-cluster-using-binary.md | 12 ++++++------ dm/deploy-a-dm-cluster-using-tiup-offline.md | 14 +++++++------- dm/deploy-a-dm-cluster-using-tiup.md | 10 +++++----- dm/dm-best-practices.md | 10 +++++----- dm/dm-faq.md | 2 +- dm/dm-open-api.md | 2 +- dm/maintain-dm-using-tiup.md | 4 ++-- dm/quick-start-with-dm.md | 2 +- dr-solution-introduction.md | 2 +- ecosystem-tool-user-case.md | 2 +- ecosystem-tool-user-guide.md | 4 ++-- enable-tls-between-components.md | 2 +- encryption-at-rest.md | 4 ++-- faq/deploy-and-maintain-faq.md | 2 +- faq/faq-overview.md | 2 +- faq/high-availability-faq.md | 2 +- faq/manage-cluster-faq.md | 2 +- follower-read.md | 4 ++-- geo-distributed-deployment-topology.md | 2 +- glossary.md | 2 +- hardware-and-software-requirements.md | 6 +++--- hybrid-deployment-topology.md | 8 ++++---- migrate-small-mysql-shards-to-tidb.md | 2 +- migrate-small-mysql-to-tidb.md | 2 +- multi-data-centers-in-one-city-deployment.md | 12 ++++++------ performance-tuning-methods.md | 4 ++-- placement-rules-in-sql.md | 6 +++--- production-deployment-using-tiup.md | 8 ++++---- quick-start-with-htap.md | 2 +- quick-start-with-tidb.md | 2 +- releases/release-2.1.18.md | 2 +- releases/release-3.0.4.md | 2 +- releases/release-3.0.9.md | 2 +- releases/release-3.1.0-beta.1.md | 2 +- releases/release-3.1.0-beta.2.md | 2 +- releases/release-4.0.15.md | 4 ++-- releases/release-4.0.3.md | 2 +- releases/release-4.0.8.md | 2 +- releases/release-5.0.0-rc.md | 2 +- releases/release-5.0.0.md | 2 +- releases/release-5.0.4.md | 4 ++-- releases/release-5.1.1.md | 2 +- releases/release-5.1.2.md | 2 +- releases/release-5.1.5.md | 2 +- releases/release-5.2.0.md | 2 +- releases/release-5.3.0.md | 2 +- releases/release-6.0.0-dmr.md | 4 ++-- releases/release-6.1.0.md | 2 +- releases/release-6.1.1.md | 2 +- releases/release-6.1.2.md | 2 +- releases/release-6.1.3.md | 2 +- releases/release-6.1.4.md | 2 +- releases/release-6.1.5.md | 2 +- releases/release-6.1.6.md | 2 +- releases/release-6.1.7.md | 2 +- releases/release-6.3.0.md | 2 +- releases/release-6.5.0.md | 4 ++-- releases/release-6.5.1.md | 4 ++-- releases/release-6.5.10.md | 4 ++-- releases/release-6.5.11.md | 2 +- releases/release-6.5.12.md | 2 +- releases/release-6.5.2.md | 2 +- releases/release-6.5.3.md | 2 +- releases/release-6.5.4.md | 2 +- releases/release-6.5.5.md | 2 +- releases/release-6.5.6.md | 2 +- releases/release-6.5.7.md | 2 +- releases/release-6.5.8.md | 2 +- releases/release-6.5.9.md | 2 +- releases/release-7.1.0.md | 2 +- releases/release-7.1.1.md | 2 +- releases/release-7.1.2.md | 2 +- releases/release-7.1.3.md | 2 +- releases/release-7.1.4.md | 2 +- releases/release-7.1.5.md | 2 +- releases/release-7.1.6.md | 2 +- releases/release-7.3.0.md | 2 +- releases/release-7.5.0.md | 2 +- releases/release-7.5.1.md | 2 +- releases/release-7.5.2.md | 4 ++-- releases/release-7.5.3.md | 2 +- releases/release-7.5.4.md | 2 +- releases/release-7.5.5.md | 2 +- releases/release-7.5.6.md | 2 +- releases/release-7.5.7.md | 2 +- releases/release-8.1.0.md | 4 ++-- releases/release-8.1.1.md | 2 +- releases/release-8.1.2.md | 2 +- releases/release-8.5.0.md | 2 +- releases/release-8.5.1.md | 2 +- releases/release-8.5.2.md | 2 +- releases/release-8.5.3.md | 2 +- releases/release-8.5.4.md | 2 +- releases/release-8.5.5.md | 4 ++-- releases/release-8.5.6.md | 2 +- releases/release-8.5.7.md | 2 +- releases/release-rc.1.md | 2 +- resources/doc-templates/template-concept.md | 2 +- schedule-replicas-by-topology-labels.md | 2 +- .../sql-statement-calibrate-resource.md | 2 +- stale-read.md | 2 +- storage-engine/rocksdb-overview.md | 2 +- system-variable-reference.md | 6 +++--- three-data-centers-in-two-cities-deployment.md | 18 +++++++++--------- ticdc/deploy-ticdc.md | 2 +- ticdc/integrate-confluent-using-ticdc.md | 4 ++-- ticdc/monitor-ticdc.md | 2 +- ticdc/ticdc-overview.md | 2 +- tidb-cloud/architecture-concepts.md | 2 +- tidb-cloud/built-in-monitoring.md | 2 +- tidb-cloud/data-service-manage-data-app.md | 4 ++-- tidb-cloud/data-service-manage-endpoint.md | 2 +- tidb-cloud/high-availability-with-multi-az.md | 2 +- tidb-cloud/integrate-tidbcloud-with-vercel.md | 4 ++-- tidb-cloud/limitations-and-quotas.md | 2 +- tidb-cloud/monitor-built-in-alerting.md | 4 ++-- tidb-cloud/monitor-tidb-cluster.md | 2 +- tidb-cloud/releases/release-notes-2023.md | 4 ++-- tidb-cloud/releases/release-notes-2025.md | 2 +- tidb-cloud/serverless-high-availability.md | 4 ++-- ...nection-to-self-hosted-kafka-in-alicloud.md | 2 +- ...k-connection-to-self-hosted-kafka-in-aws.md | 2 +- ...s-self-hosted-kafka-private-link-service.md | 2 +- ...e-self-hosted-kafka-private-link-service.md | 4 ++-- ...elf-hosted-kafka-private-service-connect.md | 2 +- tidb-cloud/size-your-cluster.md | 2 +- tidb-cloud/tidb-cloud-intro.md | 4 ++-- tidb-cloud/tidb-node-group-overview.md | 2 +- tidb-lightning/deploy-tidb-lightning.md | 4 ++-- .../import-into-vs-tidb-lightning.md | 4 ++-- .../tidb-lightning-distributed-import.md | 2 +- tidb-lightning/tidb-lightning-faq.md | 2 +- tidb-performance-tuning-config.md | 2 +- tiflash/create-tiflash-replicas.md | 2 +- tiflash/tiflash-configuration.md | 12 ++++++------ tiflash/tiflash-overview.md | 4 ++-- tiflash/troubleshoot-tiflash.md | 4 ++-- tikv-configuration-file.md | 2 +- tiproxy/tiproxy-deployment-topology.md | 6 +++--- tiproxy/tiproxy-load-balance.md | 4 ++-- tiup/customized-montior-in-tiup-environment.md | 2 +- tiup/tiup-cluster-no-sudo-mode.md | 2 +- tiup/tiup-cluster-topology-reference.md | 8 ++++---- tiup/tiup-cluster.md | 12 ++++++------ tiup/tiup-command-telemetry.md | 2 +- tiup/tiup-component-cluster-check.md | 2 +- tiup/tiup-component-cluster-list.md | 2 +- tiup/tiup-component-cluster-reload.md | 4 ++-- tiup/tiup-component-cluster-rename.md | 2 +- tiup/tiup-component-cluster-upgrade.md | 4 ++-- tiup/tiup-component-cluster.md | 2 +- tiup/tiup-component-dm-list.md | 2 +- tiup/tiup-dm-topology-reference.md | 2 +- tiup/tiup-faq.md | 4 ++-- tiup/tiup-overview.md | 2 +- troubleshoot-tidb-cluster.md | 2 +- troubleshoot-tidb-oom.md | 8 ++++---- tune-tikv-memory-performance.md | 2 +- tune-tikv-thread-performance.md | 2 +- two-data-centers-in-one-city-deployment.md | 10 +++++----- upgrade-monitoring-services.md | 2 +- upgrade-tidb-using-tiup.md | 2 +- 190 files changed, 319 insertions(+), 319 deletions(-) diff --git a/TOC-best-practices.md b/TOC-best-practices.md index 1f6eb78112390..e7a5a33df1e08 100644 --- 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 index 8263d50441982..c48e69df69d0d 100644 --- 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 index 4612a750ec218..c7711e83e5b08 100644 --- 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 index c82e427380a9e..b3c5564e9a695 100644 --- 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 index 23e4219b96854..62c45b387d247 100644 --- 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 index 77eea353a694c..7e477d2f782a8 100644 --- 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 index 26fed08df4e93..5a4c6a899cbae 100644 --- 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 index 160a4afd27ecb..f1fe6679e81a8 100644 --- 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 index 60ff06e6c6f26..7900d79e3a59a 100644 --- a/best-practices/three-dc-local-read.md +++ b/best-practices/three-dc-local-read.md @@ -1,10 +1,10 @@ --- 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は別のデータセンターからデータを読み取る必要があり、アクセスレイテンシーが増加します。 @@ -12,7 +12,7 @@ aliases: ['/ja/tidb/stable/three-dc-local-read/'] ## 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つのノードに以下のラベルを設定する必要があります。 diff --git a/best-practices/three-nodes-hybrid-deployment.md b/best-practices/three-nodes-hybrid-deployment.md index 783624749b805..e9db8e70a3996 100644 --- a/best-practices/three-nodes-hybrid-deployment.md +++ b/best-practices/three-nodes-hybrid-deployment.md @@ -4,13 +4,13 @@ summary: TiDBクラスタは、3台のマシンでコスト効率よく導入で aliases: ['/ja/tidb/stable/three-nodes-hybrid-deployment/'] --- -# 3ノードハイブリッド展開のベストプラクティス {#best-practices-for-three-node-hybrid-deployment} +# 3ノードハイブリッドデプロイのベストプラクティス {#best-practices-for-three-node-hybrid-deployment} TiDB クラスターの場合、高パフォーマンスは要求されないもののコストを抑える必要がある場合は、TiDB、TiKV、PD コンポーネントを 3台のマシンにハイブリッド方式でデプロイできます。 -このドキュメントでは、3ノードのハイブリッド展開例と、展開されたクラスターに対するTPC-Cテストを紹介します。この例に基づいて、展開シナリオとそのパラメータ調整に関するベストプラクティスを紹介します。 +このドキュメントでは、3ノードのハイブリッドデプロイ例と、デプロイされたクラスターに対するTPC-Cテストを紹介します。この例に基づいて、デプロイシナリオとそのパラメータ調整に関するベストプラクティスを紹介します。 -## 展開の前提条件とテスト方法 {#prerequisites-for-deployment-and-the-test-method} +## デプロイの前提条件とテスト方法 {#prerequisites-for-deployment-and-the-test-method} この例では、16個のCPUコアと32 GBのメモリを備えた3台の物理マシンがデプロイメントに使用されます。各マシン（ノード）には、TiDBインスタンス、TiKVインスタンス、PDインスタンスがそれぞれ1つずつ、ハイブリッド方式でデプロイされます。 @@ -28,7 +28,7 @@ PDとTiKVはどちらもディスク上に情報を保存するため、ディ ## パラメータ調整 {#parameter-adjustment} -上の画像では、デフォルトのスレッドプール構成とバックグラウンドタスクへのリソース割り当てが、十分なリソースを持つマシン向けに設定されているため、パフォーマンスのジッターが発生しています。ハイブリッド展開シナリオでは、リソースが複数のコンポーネント間で共有されるため、構成パラメータによってリソース消費を制限する必要があります。 +上の画像では、デフォルトのスレッドプール構成とバックグラウンドタスクへのリソース割り当てが、十分なリソースを持つマシン向けに設定されているため、パフォーマンスのジッターが発生しています。ハイブリッドデプロイシナリオでは、リソースが複数のコンポーネント間で共有されるため、構成パラメータによってリソース消費を制限する必要があります。 このテストの最終的なクラスター構成は次のとおりです。 @@ -50,13 +50,13 @@ tikv: ### TiKVスレッドプールサイズのコンフィグレーション {#configuration-of-tikv-thread-pool-size} -このセクションでは、フォアグラウンドアプリケーションのスレッドプールのリソース割り当てに関連するパラメータを調整するためのベストプラクティスを紹介します。これらのスレッドプールサイズを縮小するとパフォーマンスが低下しますが、リソースが限られているハイブリッド展開シナリオでは、クラスター自体で高いパフォーマンスを達成することは困難です。このシナリオでは、パフォーマンスよりもクラスター全体の安定性が優先されます。 +このセクションでは、フォアグラウンドアプリケーションのスレッドプールのリソース割り当てに関連するパラメータを調整するためのベストプラクティスを紹介します。これらのスレッドプールサイズを縮小するとパフォーマンスが低下しますが、リソースが限られているハイブリッドデプロイシナリオでは、クラスター自体で高いパフォーマンスを達成することは困難です。このシナリオでは、パフォーマンスよりもクラスター全体の安定性が優先されます。 実際の負荷テストを実施する場合は、まずデフォルト設定を使用して、各スレッドプールの実際のリソース使用量を観察します。その後、関連する設定項目を調整し、使用量が少ないスレッドプールのサイズを縮小することができます。 #### `readpool.unified.max-thread-count` {#readpool-unified-max-thread-count} -このパラメータのデフォルト値は、マシンのスレッド数の80%です。ハイブリッド展開シナリオでは、この値を手動で計算して指定する必要があります。まずは、TiKVが使用するCPUスレッド数の80%に設定することをお勧めします。 +このパラメータのデフォルト値は、マシンのスレッド数の80%です。ハイブリッドデプロイシナリオでは、この値を手動で計算して指定する必要があります。まずは、TiKVが使用するCPUスレッド数の80%に設定することをお勧めします。 #### `server.grpc-concurrency` {#server-grpc-concurrency} @@ -70,7 +70,7 @@ tikv: TiKVがマシンのCPUコア数が`16`以上であることを検出すると、このパラメータ値はデフォルトで`8`に設定されます。CPUコア数が`16`未満の場合、このパラメータ値はデフォルトで`4`に設定されます。このパラメータは、TiKVが複雑なトランザクション要求を単純なキー値の読み取りまたは書き込みに変換するものの、スケジューラスレッドプールが書き込みを実行しない場合に使用されます。 -理想的には、スケジューラスレッドプールの使用率は50%～75%に維持されます。gRPCスレッドプールと同様に、ハイブリッド展開中はパラメータ`storage.scheduler-worker-pool-size`がデフォルトで大きな値に設定されるため、リソースの使用量が不足します。このテストでは、このパラメータの値はベストプラクティスに沿って`2`に設定されており、これは**スケジューラワーカーCPU**パネルの対応するメトリックを観察した結果に基づいています。 +理想的には、スケジューラスレッドプールの使用率は50%～75%に維持されます。gRPCスレッドプールと同様に、ハイブリッドデプロイ中はパラメータ`storage.scheduler-worker-pool-size`がデフォルトで大きな値に設定されるため、リソースの使用量が不足します。このテストでは、このパラメータの値はベストプラクティスに沿って`2`に設定されており、これは**スケジューラワーカーCPU**パネルの対応するメトリックを観察した結果に基づいています。 ![Scheduler Worker CPU](/media/best-practices/three-nodes-scheduler-pool-usage.png) @@ -78,7 +78,7 @@ TiKVがマシンのCPUコア数が`16`以上であることを検出すると、 TiKVはフォアグラウンドタスクに加えて、バックグラウンドタスクでも定期的にデータのソートと古いデータの削除を実行します。デフォルト設定では、高トラフィックの書き込みシナリオに対応できるよう、これらのタスクに十分なリソースが割り当てられます。 -ただし、ハイブリッド展開シナリオでは、このデフォルト構成はベストプラクティスに準拠していません。以下のパラメータを調整して、バックグラウンドタスクのリソース使用量を制限する必要があります。 +ただし、ハイブリッドデプロイシナリオでは、このデフォルト構成はベストプラクティスに準拠していません。以下のパラメータを調整して、バックグラウンドタスクのリソース使用量を制限する必要があります。 #### `rocksdb.max-background-jobs`と`rocksdb.max-sub-compactions` {#rocksdb-max-background-jobs-and-rocksdb-max-sub-compactions} diff --git a/best-practices/tidb-best-practices.md b/best-practices/tidb-best-practices.md index 1165acac197c7..234d4679862d5 100644 --- a/best-practices/tidb-best-practices.md +++ b/best-practices/tidb-best-practices.md @@ -30,7 +30,7 @@ TiDBは、MySQLのプロトコルと構文に対応した分散データベー Raftは、強力な一貫性を備えたデータ複製を保証する合意アルゴリズムです。TiDBは、最下層でRaftを使用してデータを複製します。TiDBは、成功の結果を返す前に、レプリカの過半数にデータを書き込みます。このようにして、少数のレプリカが失われた場合でも、システムは最新のデータを保持します。たとえば、レプリカが3つある場合、2つのレプリカにデータが書き込まれるまで、システムは成功の結果を返しません。レプリカが失われた場合でも、残りの2つのレプリカのうち少なくとも1つは最新のデータを保持します。 -3 つのレプリカを保存する場合、ソースレプリカのレプリケーションと比較して、 Raftの方が効率的です。Raft の書き込みレイテンシーは、最も遅いレプリカではなく、最も速い 2つのレプリカに依存します。そのため、 Raftレプリケーションを使用することで、地理的に分散した複数のアクティブなデータセンターの実装が可能になります。2つのサイトに 3つのデータセンターが分散している典型的なシナリオでは、データの一貫性を保証するために、TiDB は 3つのデータセンターすべてに書き込むのではなく、ローカルデータセンターとより近いデータセンターにデータを正しく書き込むだけで済みます。ただし、これは、あらゆるシナリオでクロス データセンター展開を実装できるという意味ではありません。書き込むデータ量が多い場合、データセンター間の帯域幅とレイテンシーが重要な要素になります。書き込み速度が帯域幅を超えたり、レイテンシーが高すぎたりすると、 Raftレプリケーション メカニズムはうまく機能しません。 +3 つのレプリカを保存する場合、ソースレプリカのレプリケーションと比較して、 Raftの方が効率的です。Raft の書き込みレイテンシーは、最も遅いレプリカではなく、最も速い 2つのレプリカに依存します。そのため、 Raftレプリケーションを使用することで、地理的に分散した複数のアクティブなデータセンターの実装が可能になります。2つのサイトに 3つのデータセンターが分散している典型的なシナリオでは、データの一貫性を保証するために、TiDB は 3つのデータセンターすべてに書き込むのではなく、ローカルデータセンターとより近いデータセンターにデータを正しく書き込むだけで済みます。ただし、これは、あらゆるシナリオでクロス データセンターデプロイを実装できるという意味ではありません。書き込むデータ量が多い場合、データセンター間の帯域幅とレイテンシーが重要な要素になります。書き込み速度が帯域幅を超えたり、レイテンシーが高すぎたりすると、 Raftレプリケーション メカニズムはうまく機能しません。 ### 分散トランザクション {#distributed-transactions} @@ -189,7 +189,7 @@ OLTPワークロードとOLAPワークロードを完全に分離するには、 監視メトリクスは、システムの状態を把握する最良の方法です。TiDBクラスタと同時に監視システムを導入することをお勧めします。 -TiDB は[Grafana + Prometheus](/tidb-monitoring-framework.md)を使用してシステムのステータスを監視します。 TiUPを使用して TiDB を展開すると、監視システムが自動的に展開および構成されます。 +TiDB は[Grafana + Prometheus](/tidb-monitoring-framework.md)を使用してシステムのステータスを監視します。 TiUPを使用して TiDB をデプロイすると、監視システムが自動的にデプロイおよび構成されます。 監視システムには多くの項目があり、その大部分は TiDB 開発者向けです。ソースコードを深く理解していなくても、これらの項目を理解する必要はありません。アプリケーションやシステムの主要コンポーネントの状態に関連する項目は選択され、ユーザー向けに別の`overview`パネルに表示されます。 diff --git a/binary-package.md b/binary-package.md index 9a585b955ebd6..57ade8cc031e3 100644 --- a/binary-package.md +++ b/binary-package.md @@ -5,7 +5,7 @@ summary: TiDB インストールパッケージと、含まれる特定のコン # TiDB インストールパッケージ {#tidb-installation-packages} -[TiUPをオフラインで展開する](/production-deployment-using-tiup.md#deploy-tiup-offline)前に、 [TiUPオフラインコンポーネントパッケージを準備する](/production-deployment-using-tiup.md#prepare-the-tiup-offline-component-package)で説明されているように TiDB のバイナリパッケージをダウンロードする必要があります。 +[TiUPをオフラインでデプロイする](/production-deployment-using-tiup.md#deploy-tiup-offline)前に、 [TiUPオフラインコンポーネントパッケージを準備する](/production-deployment-using-tiup.md#prepare-the-tiup-offline-component-package)で説明されているように TiDB のバイナリパッケージをダウンロードする必要があります。 TiDBバイナリパッケージは、amd64およびarm64アーキテクチャで利用可能です。どちらのアーキテクチャでも、TiDBは`TiDB-community-server`と`TiDB-community-toolkit` 2つのバイナリパッケージを提供します。 diff --git a/br/br-monitoring-and-alert.md b/br/br-monitoring-and-alert.md index b78933f0d109e..7b59f03925fb9 100644 --- a/br/br-monitoring-and-alert.md +++ b/br/br-monitoring-and-alert.md @@ -5,7 +5,7 @@ summary: このドキュメントでは、ログバックアップの監視、 # バックアップと復元の監視とアラート {#monitoring-and-alert-for-backup-and-restore} -このドキュメントでは、監視コンポーネント、監視メトリック、一般的なアラートを展開する方法など、バックアップと復元機能の監視とアラートについて説明します。 +このドキュメントでは、監視コンポーネント、監視メトリック、一般的なアラートをデプロイする方法など、バックアップと復元機能の監視とアラートについて説明します。 ## スナップショットのバックアップと復元の監視 {#snapshot-backup-and-restore-monitoring} @@ -18,7 +18,7 @@ summary: このドキュメントでは、ログバックアップの監視、 ### 監視構成 {#monitoring-configuration} - TiUPを使用してデプロイされたクラスターの場合、Prometheus は監視メトリックを自動的に収集します。 -- 手動でデプロイされたクラスターの場合は、 [TiDBクラスタ監視の展開](/deploy-monitoring-services.md)の手順に従って、Prometheus 構成ファイルの`scrape_configs`セクションに TiKV 関連のジョブを追加します。 +- 手動でデプロイされたクラスターの場合は、 [TiDBクラスタ監視のデプロイ](/deploy-monitoring-services.md)の手順に従って、Prometheus 構成ファイルの`scrape_configs`セクションに TiKV 関連のジョブを追加します。 ### Grafanaの設定 {#grafana-configuration} diff --git a/br/br-use-overview.md b/br/br-use-overview.md index f99e02d3d1ec5..6ddc0b9629a8b 100644 --- a/br/br-use-overview.md +++ b/br/br-use-overview.md @@ -5,7 +5,7 @@ summary: TiDB バックアップ＆リストアは、バックアップ方法の # TiDB バックアップとリストアの使用概要 {#usage-overview-of-tidb-backup-and-restore} -このドキュメントでは、バックアップ方法の選択方法、バックアップデータの管理方法、バックアップおよび復元ツールのインストールと展開方法など、TiDB のバックアップおよび復元機能の使用に関するベストプラクティスについて説明します。 +このドキュメントでは、バックアップ方法の選択方法、バックアップデータの管理方法、バックアップおよび復元ツールのインストールとデプロイ方法など、TiDB のバックアップおよび復元機能の使用に関するベストプラクティスについて説明します。 ## 推奨されるプラクティス {#recommended-practices} @@ -62,7 +62,7 @@ TiDB クラスターを独自に構築したデータセンターに導入する ## BRをデプロイて使用する {#deploy-and-use-br} -BRを展開するには、次の要件が満たされていることを確認してください。 +BRをデプロイするには、次の要件が満たされていることを確認してください。 - BR、TiKVノード、およびバックアップストレージシステムは、バックアップ速度よりも大きなネットワーク帯域幅を提供します。ターゲットクラスターが非常に大規模な場合、バックアップおよびリストア速度のしきい値は、バックアップネットワークの帯域幅によって制限されます。 - バックアップストレージシステムは、十分な読み取りおよび書き込みパフォーマンス（IOPS）を提供します。そうでない場合、バックアップまたは復元中にパフォーマンスのボトルネックになる可能性があります。 diff --git a/check-before-deployment.md b/check-before-deployment.md index d94a31d234787..0110c39364033 100644 --- a/check-before-deployment.md +++ b/check-before-deployment.md @@ -7,7 +7,7 @@ summary: TiDB をデプロイする前に環境チェック操作について学 このドキュメントでは、TiDB をデプロイする前に行う環境チェック手順について説明します。以下の手順は優先度順に説明されています。 -## TiKVを展開するターゲットマシンにオプション付きでデータディスクのext4ファイルシステムをマウントします。 {#mount-the-data-disk-ext4-filesystem-with-options-on-the-target-machines-that-deploy-tikv} +## TiKVをデプロイするターゲットマシンにオプション付きでデータディスクのext4ファイルシステムをマウントします。 {#mount-the-data-disk-ext4-filesystem-with-options-on-the-target-machines-that-deploy-tikv} 本番環境では、TiKVデータの保存にEXT4ファイルシステムのNVMe SSDを使用することをお勧めします。この構成はベストプラクティスであり、その信頼性、セキュリティ、安定性は多数のオンラインシナリオで実証されています。 @@ -744,7 +744,7 @@ SSH相互信頼を設定する際は、すべてのターゲットノードで`t tidb ALL=(ALL) NOPASSWD: ALL ``` -3. `tidb`ユーザーでコントロールマシンにログインし、以下のコマンドを実行します。`10.0.1.1`をターゲットマシンの IP アドレスに置き換え、プロンプトが表示されたらターゲットマシンの`tidb`ユーザーパスワードを入力します。コマンド実行後、SSH 相互信頼が既に作成されています。これは他のマシンにも適用されます。新しく作成された`tidb`ユーザーには`.ssh`ディレクトリがありません。このようなディレクトリを作成するには、RSA キーを生成するコマンドを実行します。コントロールマシンに TiDB コンポーネントを展開するには、コントロールマシンとコントロールマシン自体の相互信頼を設定します。 +3. `tidb`ユーザーでコントロールマシンにログインし、以下のコマンドを実行します。`10.0.1.1`をターゲットマシンの IP アドレスに置き換え、プロンプトが表示されたらターゲットマシンの`tidb`ユーザーパスワードを入力します。コマンド実行後、SSH 相互信頼が既に作成されています。これは他のマシンにも適用されます。新しく作成された`tidb`ユーザーには`.ssh`ディレクトリがありません。このようなディレクトリを作成するには、RSA キーを生成するコマンドを実行します。コントロールマシンに TiDB コンポーネントをデプロイするには、コントロールマシンとコントロールマシン自体の相互信頼を設定します。 ```bash ssh-keygen -t rsa @@ -777,7 +777,7 @@ SSH相互信頼を設定する際は、すべてのターゲットノードで`t > **Note:** > -> - NUMA を使用してコアをバインドすることは、CPU リソースを分離する方法であり、高度に構成された物理マシンに複数のインスタンスを展開するのに適しています。 +> - NUMA を使用してコアをバインドすることは、CPU リソースを分離する方法であり、高度に構成された物理マシンに複数のインスタンスをデプロイするのに適しています。 > - `tiup cluster deploy`を使用してデプロイメントを完了したら、 `exec`コマンドを使用してクラスターレベルの管理操作を実行できます。 NUMA ツールをインストールするには、次の2つの方法のいずれかを実行します。 @@ -790,7 +790,7 @@ sudo yum -y install numactl **方法 2** : `tiup cluster exec`コマンドを実行して、既存のクラスターに NUMA を一括インストールします。 -1. [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)に従ってクラスター`tidb-test`を展開します。TiDB クラスターをインストールしている場合は、この手順をスキップできます。 +1. [TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)に従ってクラスター`tidb-test`をデプロイします。TiDB クラスターをインストールしている場合は、この手順をスキップできます。 ```bash tiup cluster deploy tidb-test v6.1.0 ./topology.yaml --user root [-p] [-i /home/root/.ssh/gcp_rsa] diff --git a/clinic/clinic-data-instruction-for-tiup.md b/clinic/clinic-data-instruction-for-tiup.md index e87aca2c727d4..0d3f73a73963e 100644 --- a/clinic/clinic-data-instruction-for-tiup.md +++ b/clinic/clinic-data-instruction-for-tiup.md @@ -5,18 +5,18 @@ summary: PingCAP Clinic診断サービスは、 TiUPを使用してTiDBおよび # PingCAP Clinic診断データ {#pingcap-clinic-diagnostic-data} -このドキュメントでは、 TiUPを使用して展開された TiDB および DM クラスタからPingCAP Clinic診断サービス (PingCAP Clinic) によって収集できる診断データの種類について説明します。また、各データの種類に対応するデータ収集パラメータも示します。[Diagクライアント（Diag）を使用してデータを収集する](/clinic/clinic-user-guide-for-tiup.md)コマンドを実行する際に、収集するデータの種類に応じて必要なパラメータをコマンドに追加できます。 +このドキュメントでは、 TiUPを使用してデプロイされた TiDB および DM クラスタからPingCAP Clinic診断サービス (PingCAP Clinic) によって収集できる診断データの種類について説明します。また、各データの種類に対応するデータ収集パラメータも示します。[Diagクライアント（Diag）を使用してデータを収集する](/clinic/clinic-user-guide-for-tiup.md)コマンドを実行する際に、収集するデータの種類に応じて必要なパラメータをコマンドに追加できます。 PingCAP Clinicによって収集された診断データは、クラスターの問題のトラブルシューティングに**のみ**使用されます。 -クラウドに展開される診断サービスである Clinic Server は、データのストレージの場所に応じて 2つの独立したサービスを提供します。 +クラウドにデプロイされる診断サービスである Clinic Server は、データのストレージの場所に応じて 2つの独立したサービスを提供します。 -- [国際ユーザー向けClinic Server](https://clinic.pingcap.com) ：収集したデータを国際ユーザー向けのClinic Serverにアップロードすると、データはPingCAPがAWS米国リージョンに展開するAmazon S3サービスに保存されます。PingCAPは厳格なデータアクセスポリシーを採用しており、承認されたテクニカルサポート担当者のみがデータにアクセスできます。 -- [中国本土のユーザー向けClinic Server](https://clinic.pingcap.com.cn) ：収集したデータを中国本土のユーザー向けClinic Serverにアップロードすると、データはPingCAPが中国（北京）リージョンに展開するAmazon S3サービスに保存されます。PingCAPは厳格なデータアクセスポリシーを採用しており、承認されたテクニカルサポート担当者のみがデータにアクセスできます。 +- [国際ユーザー向けClinic Server](https://clinic.pingcap.com) ：収集したデータを国際ユーザー向けのClinic Serverにアップロードすると、データはPingCAPがAWS米国リージョンにデプロイするAmazon S3サービスに保存されます。PingCAPは厳格なデータアクセスポリシーを採用しており、承認されたテクニカルサポート担当者のみがデータにアクセスできます。 +- [中国本土のユーザー向けClinic Server](https://clinic.pingcap.com.cn) ：収集したデータを中国本土のユーザー向けClinic Serverにアップロードすると、データはPingCAPが中国（北京）リージョンにデプロイするAmazon S3サービスに保存されます。PingCAPは厳格なデータアクセスポリシーを採用しており、承認されたテクニカルサポート担当者のみがデータにアクセスできます。 ## TiDB クラスター {#tidb-clusters} -このセクションでは、 TiUPを使用して展開された TiDB クラスターから[Diag](https://github.com/pingcap/diag)によって収集できる診断データの種類を示します。 +このセクションでは、 TiUPを使用してデプロイされた TiDB クラスターから[Diag](https://github.com/pingcap/diag)によって収集できる診断データの種類を示します。 ### TiDB クラスタ情報 {#tidb-cluster-information} @@ -100,7 +100,7 @@ PingCAP Clinicによって収集された診断データは、クラスターの ## DMクラスター {#dm-clusters} -このセクションでは、 TiUPを使用して展開された DM クラスターから Diag によって収集できる診断データの種類を示します。 +このセクションでは、 TiUPを使用してデプロイされた DM クラスターから Diag によって収集できる診断データの種類を示します。 ### DMクラスター情報 {#dm-cluster-information} diff --git a/clinic/clinic-introduction.md b/clinic/clinic-introduction.md index d0f115642c282..b99f0c089f2ec 100644 --- a/clinic/clinic-introduction.md +++ b/clinic/clinic-introduction.md @@ -19,7 +19,7 @@ PingCAP Clinic は、クラスターの問題を診断するために次の2つ - Clinic Server: - Clinic Serverはクラウド上に展開されるクラウドサービスです。SaaSモデルで診断サービスを提供することで、Clinic Serverはアップロードされた診断データを受信するだけでなく、データの保存、閲覧、クラスター診断レポートの提供など、オンライン診断環境として機能します。Clinic Serverは、ストレージの場所に応じて2つの独立したサービスを提供します。 + Clinic Serverはクラウド上にデプロイされるクラウドサービスです。SaaSモデルで診断サービスを提供することで、Clinic Serverはアップロードされた診断データを受信するだけでなく、データの保存、閲覧、クラスター診断レポートの提供など、オンライン診断環境として機能します。Clinic Serverは、ストレージの場所に応じて2つの独立したサービスを提供します。 - [国際ユーザー向けClinic Server](https://clinic.pingcap.com) : データは米国の AWS に保存されます。 - [中国本土のユーザー向けClinic Server](https://clinic.pingcap.com.cn) : データは中国 (北京) リージョンの AWS に保存されます。 @@ -42,11 +42,11 @@ PingCAP Clinic は、クラスターの問題を診断するために次の2つ - SCP 経由でサーバーファイルを転送する - TiUPを使用して展開されたクラスターの場合、Diag はセキュリティコピー プロトコル (SCP) を介してターゲットコンポーネントのノードからログファイルと構成ファイルを直接収集できます。 + TiUPを使用してデプロイされたクラスターの場合、Diag はセキュリティコピー プロトコル (SCP) を介してターゲットコンポーネントのノードからログファイルと構成ファイルを直接収集できます。 - SSH経由でリモートコマンドを実行してデータを収集する - TiUPを使用して展開されたクラスターの場合、Diag は SSH ( セキュリティ Shell) を介してターゲットコンポーネントシステムに接続し、コマンド (Insight など) を実行して、カーネル ログ、カーネルパラメーター、システムとハードウェアの基本情報などのシステム情報を取得できます。 + TiUPを使用してデプロイされたクラスターの場合、Diag は SSH ( セキュリティ Shell) を介してターゲットコンポーネントシステムに接続し、コマンド (Insight など) を実行して、カーネル ログ、カーネルパラメーター、システムとハードウェアの基本情報などのシステム情報を取得できます。 - HTTP呼び出しを通じてデータを収集する diff --git a/clinic/clinic-user-guide-for-tiup.md b/clinic/clinic-user-guide-for-tiup.md index 6ed2ad3060781..3ca443e1c8f28 100644 --- a/clinic/clinic-user-guide-for-tiup.md +++ b/clinic/clinic-user-guide-for-tiup.md @@ -44,7 +44,7 @@ PingCAP Clinicを使用する前に、Diag（ PingCAP Clinicが提供するデ > **Note:** > - > - インターネット接続のないクラスタでは、Diagをオフラインで展開する必要があります。詳細については、 [TiUPをオフラインでデプロイ: 方法2](/production-deployment-using-tiup.md#deploy-tiup-offline)を参照してください。 + > - インターネット接続のないクラスタでは、Diagをオフラインでデプロイする必要があります。詳細については、 [TiUPをオフラインでデプロイ: 方法2](/production-deployment-using-tiup.md#deploy-tiup-offline)を参照してください。 > - Diag は、TiDB Server オフライン ミラー パッケージ v5.4.0 以降で**のみ**提供されます。 2. データをアップロードするためのアクセストークン (トークン) を取得して設定します。 @@ -132,7 +132,7 @@ Diag によって収集できるデータの完全なリストについては、 ### ステップ2. データを収集する {#step-2-collect-data} -Diag を使用すると、 TiUPを使用して展開された TiDB クラスターと DM クラスターからデータを収集できます。 +Diag を使用すると、 TiUPを使用してデプロイされた TiDB クラスターと DM クラスターからデータを収集できます。 1. Diag のデータ収集コマンドを実行します。 diff --git a/clinic/quick-start-with-clinic.md b/clinic/quick-start-with-clinic.md index d941bfb217541..5b7b235e81cab 100644 --- a/clinic/quick-start-with-clinic.md +++ b/clinic/quick-start-with-clinic.md @@ -16,7 +16,7 @@ PingCAP Clinicは、 [Diagクライアント](https://github.com/pingcap/diag) > **Note:** > -> - 以下のデータ収集およびアップロード方法は[TiUPを使用して展開されたクラスター](/production-deployment-using-tiup.md)に**のみ**適用されます。Kubernetes 上のTiDB Operatorを使用してデプロイされたクラスターの場合は、 [TiDB Operator環境向けPingCAP Clinic](https://docs.pingcap.com/tidb-in-kubernetes/stable/clinic-user-guide)を参照してください。 +> - 以下のデータ収集およびアップロード方法は[TiUPを使用してデプロイされたクラスター](/production-deployment-using-tiup.md)に**のみ**適用されます。Kubernetes 上のTiDB Operatorを使用してデプロイされたクラスターの場合は、 [TiDB Operator環境向けPingCAP Clinic](https://docs.pingcap.com/tidb-in-kubernetes/stable/clinic-user-guide)を参照してください。 > - PingCAP Clinicによって収集された診断データは、クラスターの問題のトラブルシューティングに**のみ**使用されます。 ## 前提条件 {#prerequisites} diff --git a/configure-memory-usage.md b/configure-memory-usage.md index c66fa53d6d047..a05ebe267c3aa 100644 --- a/configure-memory-usage.md +++ b/configure-memory-usage.md @@ -56,7 +56,7 @@ tidb-server インスタンスのメモリ使用量が総メモリの一定割 > **Note:** > -> ハイブリッド展開シナリオでは、物理マシン全体の合計メモリしきい値ではなく、単一の tidb-server インスタンスのメモリ使用量しきい値は`tidb_server_memory_limit`になります。 +> ハイブリッドデプロイシナリオでは、物理マシン全体の合計メモリしきい値ではなく、単一の tidb-server インスタンスのメモリ使用量しきい値は`tidb_server_memory_limit`になります。 ## INFORMATION_SCHEMA システムテーブルを使用して、現在の tidb-server インスタンスのメモリ使用量を表示する {#view-the-memory-usage-of-the-current-tidb-server-instance-using-the-information_schema-system-table} diff --git a/dashboard/dashboard-faq.md b/dashboard/dashboard-faq.md index def0b00bfaa81..6d84e6efc91a6 100644 --- a/dashboard/dashboard-faq.md +++ b/dashboard/dashboard-faq.md @@ -13,11 +13,11 @@ summary: このドキュメントは、TiDB Dashboardに関するよくある質 クラスター内に複数のPlacement Driver（PD）インスタンスがデプロイされている場合、TiDB Dashboardサービスを実際に実行するPDインスタンスは1つだけです。このPDインスタンスではなく他のPDインスタンスにアクセスすると、ブラウザは別のアドレスにリダイレクトします。TiDB Dashboardへのアクセス用にファイアウォールまたはリバースプロキシが適切に設定されていない場合、ダッシュボードにアクセスした際に、ファイアウォールまたはリバースプロキシによって保護されている内部アドレスにリダイレクトされる可能性があります。 -- 複数の PD インスタンスを使用した TiDB Dashboardの動作原理については、 [TiDB Dashboardのマルチ PD インスタンスの展開](/dashboard/dashboard-ops-deploy.md)を参照してください。 +- 複数の PD インスタンスを使用した TiDB Dashboardの動作原理については、 [TiDB Dashboardのマルチ PD インスタンスのデプロイ](/dashboard/dashboard-ops-deploy.md)を参照してください。 - リバースプロキシを正しく構成する方法については、 [リバースプロキシ経由でTiDB Dashboardを使用する](/dashboard/dashboard-ops-reverse-proxy.md)を参照してください。 - ファイアウォールを正しく構成する方法については、 [TiDB Dashboardのセキュリティ保護](/dashboard/dashboard-ops-security.md)を参照してください。 -### TiDB Dashboardがデュアルネットワークインターフェースカード（NIC）で展開されている場合、別のNICを使用してTiDB Dashboardにアクセスすることはできません。 {#when-tidb-dashboard-is-deployed-with-dual-network-interface-cards-nics-tidb-dashboard-cannot-be-accessed-using-another-nic} +### TiDB Dashboardがデュアルネットワークインターフェースカード（NIC）でデプロイされている場合、別のNICを使用してTiDB Dashboardにアクセスすることはできません。 {#when-tidb-dashboard-is-deployed-with-dual-network-interface-cards-nics-tidb-dashboard-cannot-be-accessed-using-another-nic} セキュリティ上の理由から、PD上のTiDB Dashboardは、デプロイメント時に指定されたIPアドレスのみを監視します（つまり、1つのNICのみを監視します）。`0.0.0.0`ですべてのNICを監視するわけではありません。そのため、ホストに複数のNICがインストールされている場合、別のNICを使用してTiDB Dashboardにアクセスすることはできません。 @@ -60,7 +60,7 @@ NgMonitoringは、TiDB v5.4.0以降のバージョンに組み込まれた高度 Web ページに`required component NgMonitoring is not started`が表示されている場合は、次のようにしてデプロイメントの問題をトラブルシューティングできます。 -
TiUPを使用して展開されたクラスター +
TiUPを使用してデプロイされたクラスター ステップ1. バージョンを確認する diff --git a/dashboard/dashboard-ops-reverse-proxy.md b/dashboard/dashboard-ops-reverse-proxy.md index b5969ab28d16e..d82d43274cfff 100644 --- a/dashboard/dashboard-ops-reverse-proxy.md +++ b/dashboard/dashboard-ops-reverse-proxy.md @@ -115,9 +115,9 @@ server_configs: dashboard.public-path-prefix: /foo ``` -
TiUPを使用して新しいクラスターを展開するときに構成を変更する +
TiUPを使用して新しいクラスターをデプロイするときに構成を変更する -新しいクラスタをデプロイする場合は、上記の設定を`topology.yaml` TiUPトポロジファイルに追加してクラスタをデプロイできます。具体的な手順については、 [TiUP展開ドキュメント](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)を参照してください。 +新しいクラスタをデプロイする場合は、上記の設定を`topology.yaml` TiUPトポロジファイルに追加してクラスタをデプロイできます。具体的な手順については、 [TiUPデプロイドキュメント](/production-deployment-using-tiup.md#step-3-initialize-the-cluster-topology-file)を参照してください。
diff --git a/dashboard/dashboard-ops-security.md b/dashboard/dashboard-ops-security.md index 96cf05d084f33..09e7899749f29 100644 --- a/dashboard/dashboard-ops-security.md +++ b/dashboard/dashboard-ops-security.md @@ -39,7 +39,7 @@ TiDB DashboardはPDクライアントポート（デフォルトは[http://IP:23 - リバースプロキシを構成して、別のポートで TiDB Dashboard サービスを外部ネットワークに安全に提供する方法の詳細については、 [リバースプロキシの背後で TiDB Dashboardを使用する](/dashboard/dashboard-ops-reverse-proxy.md)を参照してください。 -### 複数のPDインスタンスを展開するときにTiDB Dashboardポートへのアクセスを開く方法 {#how-to-open-access-to-tidb-dashboard-port-when-deploying-multiple-pd-instances} +### 複数のPDインスタンスをデプロイするときにTiDB Dashboardポートへのアクセスを開く方法 {#how-to-open-access-to-tidb-dashboard-port-when-deploying-multiple-pd-instances} > **Warning:** > diff --git a/dashboard/dashboard-resource-manager.md b/dashboard/dashboard-resource-manager.md index d1de53e166d4b..f658fd2ce880d 100644 --- a/dashboard/dashboard-resource-manager.md +++ b/dashboard/dashboard-resource-manager.md @@ -1,6 +1,6 @@ --- title: TiDB Dashboard Resource Manager Page -summary: TiDB Dashboardのリソースマネージャページは、クラスタ管理者がリソースグループを作成し、クォータを設定することでリソース分離を実装するのに役立ちます。クラスタ容量を推定し、リソース消費量を監視するための方法を提供します。このページには、TiDB Dashboardまたはブラウザからアクセスできます。このページには、構成、容量推定、およびメトリックのセクションがあります。容量推定方法には、ハードウェアの展開と実際のワークロードが含まれます。監視メトリックには、消費されたRUの合計、リソースグループによる消費RU、TiDB CPUクォータと使用量、TiKV CPUクォータと使用量、TiKV IO MBpsが含まれます。 +summary: TiDB Dashboardのリソースマネージャページは、クラスタ管理者がリソースグループを作成し、クォータを設定することでリソース分離を実装するのに役立ちます。クラスタ容量を推定し、リソース消費量を監視するための方法を提供します。このページには、TiDB Dashboardまたはブラウザからアクセスできます。このページには、構成、容量推定、およびメトリックのセクションがあります。容量推定方法には、ハードウェアのデプロイと実際のワークロードが含まれます。監視メトリックには、消費されたRUの合計、リソースグループによる消費RU、TiDB CPUクォータと使用量、TiKV CPUクォータと使用量、TiKV IO MBpsが含まれます。 --- # TiDB Dashboardリソースマネージャーページ {#tidb-dashboard-resource-manager-page} @@ -28,7 +28,7 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ - 容量の見積もり：リソース計画を立てる前に、クラスター全体の容量を把握する必要があります。以下のいずれかの方法を使用できます。 - [実際の作業負荷に基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-actual-workload) - - [ハードウェアの展開に基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-hardware-deployment) + - [ハードウェアのデプロイに基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-hardware-deployment) - メトリクス: パネル上のメトリクスを観察することで、クラスターの現在の全体的なリソース消費状態を把握できます。 @@ -36,7 +36,7 @@ summary: TiDB Dashboardのリソースマネージャページは、クラスタ リソース計画を立てる前に、クラスター全体の容量を把握しておく必要があります。TiDBは、現在のクラスターの[リクエストユニット（RU）](/tidb-resource-control-ru-groups.md#what-is-request-unit-ru#what-is-request-unit-ru)の容量を見積もる2つの方法を提供しています。 -- [ハードウェアの展開に基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-hardware-deployment) +- [ハードウェアのデプロイに基づいて容量を見積もる](/sql-statements/sql-statement-calibrate-resource.md#estimate-capacity-based-on-hardware-deployment) TiDB は次のワークロード タイプを受け入れます。 diff --git a/develop/dev-guide-sample-application-aws-lambda.md b/develop/dev-guide-sample-application-aws-lambda.md index ce4193c037857..bf350ec691157 100644 --- a/develop/dev-guide-sample-application-aws-lambda.md +++ b/develop/dev-guide-sample-application-aws-lambda.md @@ -265,7 +265,7 @@ AWS Lambda関数は、 [SAM CLI](#sam-cli-deployment-recommended)または[AWS L # Successfully created! ``` -### Webコンソールの展開 {#web-console-deployment} +### Webコンソールのデプロイ {#web-console-deployment} 1. バンドルを作成する: diff --git a/develop/dev-guide-sample-application-ruby-mysql2.md b/develop/dev-guide-sample-application-ruby-mysql2.md index 0a1cd0a571263..be7d1f15ff811 100644 --- a/develop/dev-guide-sample-application-ruby-mysql2.md +++ b/develop/dev-guide-sample-application-ruby-mysql2.md @@ -333,7 +333,7 @@ end 3. OpenSUSE 用`/etc/ssl/ca-bundle.pem` 4. `/etc/ssl/cert.pem` macOS または Alpine (Docker コンテナ) -CA証明書のパスを手動で指定することも可能ですが、異なるマシンや環境によってCA証明書の保存場所が異なる可能性があるため、複数の環境に展開するシナリオでは大きな不便が生じる可能性があります。そのため、柔軟性と異なる環境への展開の容易性を考慮して、 `sslca`を`nil`に設定することをお勧めします。 +CA証明書のパスを手動で指定することも可能ですが、異なるマシンや環境によってCA証明書の保存場所が異なる可能性があるため、複数の環境にデプロイするシナリオでは大きな不便が生じる可能性があります。そのため、柔軟性と異なる環境へのデプロイの容易性を考慮して、 `sslca`を`nil`に設定することをお勧めします。 ## 次のステップ {#next-steps} diff --git a/develop/dev-guide-sample-application-ruby-rails.md b/develop/dev-guide-sample-application-ruby-rails.md index df8a67d2d2c8e..10c445781b061 100644 --- a/develop/dev-guide-sample-application-ruby-rails.md +++ b/develop/dev-guide-sample-application-ruby-rails.md @@ -302,7 +302,7 @@ player.destroy 3. /etc/ssl/ca-bundle.pem # OpenSUSE 4. /etc/ssl/cert.pem # MacOS / Alpine (Dockerコンテナ) -CA証明書のパスを手動で指定することも可能ですが、異なるマシンや環境によってCA証明書の保存場所が異なる場合があるため、複数の環境に展開するシナリオでは、この方法は大きな不便をもたらす可能性があります。そのため、 `sslca`を`nil`に設定することで、柔軟性と異なる環境への展開の容易性を確保できます。 +CA証明書のパスを手動で指定することも可能ですが、異なるマシンや環境によってCA証明書の保存場所が異なる場合があるため、複数の環境にデプロイするシナリオでは、この方法は大きな不便をもたらす可能性があります。そのため、 `sslca`を`nil`に設定することで、柔軟性と異なる環境へのデプロイの容易性を確保できます。 ## 次のステップ {#next-steps} diff --git a/develop/dev-guide-use-follower-read.md b/develop/dev-guide-use-follower-read.md index a1d188daafc8b..f675db5b9e207 100644 --- a/develop/dev-guide-use-follower-read.md +++ b/develop/dev-guide-use-follower-read.md @@ -27,9 +27,9 @@ TiDBは、 [リージョン](/tidb-storage.md#region)基本単位として、ク 読み取りホットスポットが避けられない場合、または変更コストが非常に高い場合は、Follower Read機能を使用して、フォロワーリージョンへの読み取り要求のバランスをより適切にロードすることができます。 -### 地理的に分散した展開のレイテンシーを削減 {#reduce-latency-for-geo-distributed-deployments} +### 地理的に分散したデプロイのレイテンシーを削減 {#reduce-latency-for-geo-distributed-deployments} -TiDB クラスターが複数の地区またはデータセンターにまたがって展開されている場合、リージョンの異なるレプリカが異なる地区またはデータセンターに分散されます。この場合、 Follower Read を`closest-adaptive`または`closest-replicas`に設定することで、TiDB が現在のデータセンターからの読み取りを優先するように設定できます。これにより、読み取り操作のレイテンシーとトラフィックのオーバーヘッドが大幅に削減されます。実装の詳細については、 [Follower Read](/follower-read.md)を参照してください。 +TiDB クラスターが複数の地区またはデータセンターにまたがってデプロイされている場合、リージョンの異なるレプリカが異なる地区またはデータセンターに分散されます。この場合、 Follower Read を`closest-adaptive`または`closest-replicas`に設定することで、TiDB が現在のデータセンターからの読み取りを優先するように設定できます。これにより、読み取り操作のレイテンシーとトラフィックのオーバーヘッドが大幅に削減されます。実装の詳細については、 [Follower Read](/follower-read.md)を参照してください。 ## Follower Readを有効にする {#enable-follower-read} diff --git a/dm/deploy-a-dm-cluster-using-binary.md b/dm/deploy-a-dm-cluster-using-binary.md index ea35cd93dc03e..4b825a77946a4 100644 --- a/dm/deploy-a-dm-cluster-using-binary.md +++ b/dm/deploy-a-dm-cluster-using-binary.md @@ -9,7 +9,7 @@ summary: DM バイナリを使用してデータ移行クラスターをデプ > **Note:** > -> 本番環境では、 [TiUPを使用してDMクラスタを展開する](/dm/deploy-a-dm-cluster-using-tiup.md)を推奨します。 +> 本番環境では、 [TiUPを使用してDMクラスタをデプロイする](/dm/deploy-a-dm-cluster-using-tiup.md)を推奨します。 ## DMバイナリをダウンロード {#download-dm-binary} @@ -17,9 +17,9 @@ DMバイナリはTiDB Toolkitに含まれています。TiDB Toolkitをダウン ## サンプルシナリオ {#sample-scenario} -次のサンプル シナリオに基づいて DM クラスターを展開するとします。 +次のサンプル シナリオに基づいて DM クラスターをデプロイするとします。 -2 つの DM ワーカーノードと 3つの DM マスターノードが 5台のサーバーに展開されます。 +2 つの DM ワーカーノードと 3つの DM マスターノードが 5台のサーバーにデプロイされます。 各ノードのアドレスは次のとおりです。 @@ -31,15 +31,15 @@ DMバイナリはTiDB Toolkitに含まれています。TiDB Toolkitをダウン | DMワーカー1 | 192.168.0.7 | 8262 | | DMワーカー2 | 192.168.0.8 | 8262 | -このシナリオに基づいて、次のセクションでは DM クラスターを展開する方法について説明します。 +このシナリオに基づいて、次のセクションでは DM クラスターをデプロイする方法について説明します。 > **Note:** > -> - 単一のサーバーに複数の DM マスターまたは DM ワーカーインスタンスを展開する場合、各インスタンスのポートと作業ディレクトリは一意である必要があります。 +> - 単一のサーバーに複数の DM マスターまたは DM ワーカーインスタンスをデプロイする場合、各インスタンスのポートと作業ディレクトリは一意である必要があります。 > > - DM クラスターの高可用性を確保する必要がない場合は、DM マスターノードを 1つだけデプロイし、デプロイされる DM ワーカーノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数以上である必要があります。 > -> - DM クラスターの高可用性を確保するには、3つの DM マスターノードを展開することをお勧めします。また、展開する DM ワーカーノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数より多くする必要があります (たとえば、DM ワーカーノードの数は、アップストリーム インスタンスの数より 2つ多くなります)。 +> - DM クラスターの高可用性を確保するには、3つの DM マスターノードをデプロイすることをお勧めします。また、デプロイする DM ワーカーノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数より多くする必要があります (たとえば、DM ワーカーノードの数は、アップストリーム インスタンスの数より 2つ多くなります)。 > > - 次のコンポーネント間のポートが相互接続されていることを確認します。 > - DM マスターノード間の`8291`ポートは相互接続されています。 diff --git a/dm/deploy-a-dm-cluster-using-tiup-offline.md b/dm/deploy-a-dm-cluster-using-tiup-offline.md index c038227c3cc5e..98d0c1df902d7 100644 --- a/dm/deploy-a-dm-cluster-using-tiup-offline.md +++ b/dm/deploy-a-dm-cluster-using-tiup-offline.md @@ -1,11 +1,11 @@ --- title: Deploy a DM Cluster Offline Using TiUP -summary: TiUPを使用して DM クラスターをオフラインで展開する方法を紹介します。 +summary: TiUPを使用して DM クラスターをオフラインでデプロイする方法を紹介します。 --- # TiUPを使用して DMクラスタをオフラインでデプロイ {#deploy-a-dm-cluster-offline-using-tiup} -このドキュメントでは、 TiUPを使用して DM クラスターをオフラインで展開する方法について説明します。 +このドキュメントでは、 TiUPを使用して DM クラスターをオフラインでデプロイする方法について説明します。 ## ステップ1: TiUPオフラインコンポーネントパッケージを準備する {#step-1-prepare-the-tiup-offline-component-package} @@ -72,7 +72,7 @@ source /home/tidb/.bash_profile 完全な構成テンプレートについては、「 [TiUP構成パラメータ テンプレート](https://github.com/pingcap/tiup/blob/master/embed/examples/dm/topology.example.yaml) . 構成ファイルを作成する」 `topology.yaml`を参照してください。その他の複合シナリオでは、テンプレートに従って必要に応じて構成ファイルを編集します。 -3 つの DM マスター、3つの DM ワーカー、および 1つの監視コンポーネントインスタンスを展開する構成は次のとおりです。 +3 つの DM マスター、3つの DM ワーカー、および 1つの監視コンポーネントインスタンスをデプロイする構成は次のとおりです。 ```yaml --- @@ -107,7 +107,7 @@ alertmanager_servers: > > - DM クラスターの高可用性を確保する必要がない場合は、DM マスターノードを 1つだけデプロイし、デプロイされた DM ワーカーノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数以上である必要があります。 > -> - DM クラスターの高可用性を確保するには、3つの DM マスターノードを展開することをお勧めします。また、展開する DM ワーカーノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数より多くする必要があります (たとえば、DM ワーカーノードの数は、アップストリーム インスタンスの数より 2つ多くなります)。 +> - DM クラスターの高可用性を確保するには、3つの DM マスターノードをデプロイすることをお勧めします。また、デプロイする DM ワーカーノードの数は、移行するアップストリーム MySQL/MariaDB インスタンスの数より多くする必要があります (たとえば、DM ワーカーノードの数は、アップストリーム インスタンスの数より 2つ多くなります)。 > > - グローバルに有効にする必要があるパラメータについては、構成ファイルの`server_configs`セクションで対応するコンポーネントのこれらのパラメータを構成します。 > @@ -128,7 +128,7 @@ alertmanager_servers: > **Note:** > -> TiUPを使用して DM を展開する場合、セキュリティ認証に秘密キーまたは対話型パスワードを使用できます。 +> TiUPを使用して DM をデプロイする場合、セキュリティ認証に秘密キーまたは対話型パスワードを使用できます。 > > - 秘密鍵を使用する場合は、 `-i`または`--identity_file`を通じて鍵のパスを指定できます。 > - パスワードを使用する場合は、パスワード対話ウィンドウに入るために`-p`フラグを追加します。 @@ -143,7 +143,7 @@ tiup dm deploy dm-test ${version} ./topology.yaml --user root [-p] [-i /home/roo - デプロイされた DM クラスターの名前は`dm-test`です。 - DMクラスタのバージョンは`${version}`です。TiUPでサポートされている最新バージョンを確認するには、 `tiup list dm-master`を実行します。 - 初期化構成ファイルは`topology.yaml`です。 -- `--user root` : `root`キーを使用してターゲットマシンにログインし、クラスターの展開を完了するか、 `ssh`および`sudo`権限を持つ他のユーザーを使用して展開を完了することができます。 +- `--user root` : `root`キーを使用してターゲットマシンにログインし、クラスターのデプロイを完了するか、 `ssh`および`sudo`権限を持つ他のユーザーを使用してデプロイを完了することができます。 - `[-i]`と`[-p]` : オプション。ターゲットマシンへのログインをパスワードなしで設定している場合、これらのパラメータは不要です。そうでない場合は、2つのパラメータのいずれかを選択してください。`[-i]`は、ターゲットマシンにアクセスできる`root`ユーザー（または`--user`で指定された他のユーザー）の秘密鍵です。`[-p]`は、ユーザーパスワードを対話的に入力するために使用されます。 - TiUP DMは組み込みのSSHクライアントを使用します。制御マシンシステムにネイティブのSSHクライアントを使用する場合は、 [システムのネイティブSSHクライアントを使用してクラスターに接続する](/dm/maintain-dm-using-tiup.md#use-the-systems-native-ssh-client-to-connect-to-cluster)に従って設定を編集してください。 @@ -163,7 +163,7 @@ Name User Version Path PrivateKey dm-test tidb ${version} /root/.tiup/storage/dm/clusters/dm-test /root/.tiup/storage/dm/clusters/dm-test/ssh/id_rsa ``` -## ステップ6: 展開されたDMクラスタのステータスを確認する {#step-6-check-the-status-of-the-deployed-dm-cluster} +## ステップ6: デプロイされたDMクラスタのステータスを確認する {#step-6-check-the-status-of-the-deployed-dm-cluster} `dm-test`クラスターのステータスを確認するには、次のコマンドを実行します。 diff --git a/dm/deploy-a-dm-cluster-using-tiup.md b/dm/deploy-a-dm-cluster-using-tiup.md index afdb55f5c07c9..bcda8ae9b398b 100644 --- a/dm/deploy-a-dm-cluster-using-tiup.md +++ b/dm/deploy-a-dm-cluster-using-tiup.md @@ -1,6 +1,6 @@ --- title: Deploy a DM Cluster Using TiUP -summary: TiUP DMを使用して TiDB データ移行を展開する方法を学習します。 +summary: TiUP DMを使用して TiDB データ移行をデプロイする方法を学習します。 --- # TiUPを使用して DMクラスタをデプロイ {#deploy-a-dm-cluster-using-tiup} @@ -17,7 +17,7 @@ TiUPはDM v2.0以降のバージョンの導入をサポートしています。 - DMが完全なデータレプリケーションタスクを実行する場合、DMワーカーは1つの上流データベースのみにバインドされます。DMワーカーはまずローカルで全データをエクスポートし、その後、下流データベースにインポートします。そのため、ワーカーのホスト領域には、エクスポートするすべての上流テーブルを保存できる十分な大きさが必要です。ストレージパスは、タスク作成時に後で指定します。 -- DM クラスターを展開する場合は、 [ハードウェアとソフトウェアの要件](/dm/dm-hardware-and-software-requirements.md)を満たす必要があります。 +- DM クラスターをデプロイする場合は、 [ハードウェアとソフトウェアの要件](/dm/dm-hardware-and-software-requirements.md)を満たす必要があります。 - v8.0.0 以降、 [データベースのパスワードを暗号化する](/dm/dm-manage-source.md#encrypt-the-database-password)必要な場合は、事前に[データベースのパスワードを暗号化および復号化するために使用されるキーファイル](/dm/dm-customized-secret-key.md)を DM マスターに保存し、 `dmctl encrypt`コマンドを使用する前に[`secret-key-path`](/dm/dm-master-configuration-file.md)を DM マスターに設定する必要があります。 @@ -47,7 +47,7 @@ TiUPはDM v2.0以降のバージョンの導入をサポートしています。 コマンド`tiup dm template > topology.yaml`を使用すると、構成ファイル テンプレートをすばやく生成できます。 -3 つの DM マスター、3つの DM ワーカー、および 1つの監視コンポーネントインスタンスを展開する構成は次のとおりです。 +3 つの DM マスター、3つの DM ワーカー、および 1つの監視コンポーネントインスタンスをデプロイする構成は次のとおりです。 ```yaml # The global variables apply to all other components in the configuration. If one specific value is missing in the component instance, the corresponding global variable serves as the default value. @@ -164,7 +164,7 @@ tiup dm deploy ${name} ${version} ./topology.yaml -u ${ssh_user} [-p] [-i /home/ | `${name}` | DM クラスターの名前 (例: dm-test) | | `${version}` | DM クラスターのバージョン`tiup list dm-master`を実行すると、サポートされている他のバージョンを確認できます。 | | `./topology.yaml` | トポロジ構成ファイルのパス。 | -| `-u`または`--user` | クラスターの展開を完了するには、root ユーザーまたは ssh および sudo権限を持つ他のユーザーアカウントとしてターゲットマシンにログインします。 | +| `-u`または`--user` | クラスターのデプロイを完了するには、root ユーザーまたは ssh および sudo権限を持つ他のユーザーアカウントとしてターゲットマシンにログインします。 | | `-p`または`--password` | 対象ホストのパスワード。指定すると、パスワード認証が使用されます。 | | `-i`または`--identity_file` | SSH IDファイルのパス。指定すると公開鍵認証が使用されます（デフォルトは「/root/.ssh/id_rsa」）。 | @@ -184,7 +184,7 @@ Name User Version Path PrivateKey dm-test tidb ${version} /root/.tiup/storage/dm/clusters/dm-test /root/.tiup/storage/dm/clusters/dm-test/ssh/id_rsa ``` -## ステップ5: 展開されたDMクラスタのステータスを確認する {#step-5-check-the-status-of-the-deployed-dm-cluster} +## ステップ5: デプロイされたDMクラスタのステータスを確認する {#step-5-check-the-status-of-the-deployed-dm-cluster} `dm-test`クラスターのステータスを確認するには、次のコマンドを実行します。 diff --git a/dm/dm-best-practices.md b/dm/dm-best-practices.md index 591c99ba9ae7f..c6c87e2677d33 100644 --- a/dm/dm-best-practices.md +++ b/dm/dm-best-practices.md @@ -119,13 +119,13 @@ TiDB v6.0.0以降、GBKがサポートされています。詳細については - [文字セットと照合順序](/character-set-and-collation.md) - [GBK互換性](/character-set-gbk.md#mysql-compatibility) -### 展開のベストプラクティス {#best-practices-for-deployment} +### デプロイのベストプラクティス {#best-practices-for-deployment} #### DMマスターとDMワーカーをデプロイ {#deploy-dm-master-and-dm-worker} DM は DM マスターノードと DM ワーカーノードで構成されます。 -- DMマスターは、移行タスクのメタデータを管理し、DMワーカーノードのスケジュールを管理します。これはDMプラットフォーム全体の中核です。そのため、DMマスターをクラスターとして展開することで、DMプラットフォームの高可用性を確保できます。 +- DMマスターは、移行タスクのメタデータを管理し、DMワーカーノードのスケジュールを管理します。これはDMプラットフォーム全体の中核です。そのため、DMマスターをクラスターとしてデプロイすることで、DMプラットフォームの高可用性を確保できます。 - DMワーカーは、上流および下流の移行タスクを実行します。DMワーカーノードはステートレスです。最大1000個のDMワーカーノードをデプロイできます。DMを使用する場合は、高可用性を確保するために、アイドル状態のDMワーカーをいくつか確保することをお勧めします。 @@ -141,12 +141,12 @@ MySQLシャードの移行とマージを行う際、上流のシャードの種 移行タスクを分割することで保証されるのは、最終的なデータの整合性のみであることにご注意ください。リアルタイムの整合性は、様々な理由により大きく変動する可能性があります。 -次の表は、さまざまなシナリオにおける DM マスターと DM ワーカーの推奨される展開計画を示しています。 +次の表は、さまざまなシナリオにおける DM マスターと DM ワーカーの推奨されるデプロイ計画を示しています。 -| シナリオ | DMマスターの展開 | DMワーカーの展開 | +| シナリオ | DMマスターのデプロイ | DMワーカーのデプロイ | | :-------------------------------------------------------------------- | :----------------------------------------------------------------------------- | :---------------------------------------------------------------------------------------- | |
  • 小さなデータセット（1 TiB 未満）
  • 一度限りのデータ移行
    • | 1つのDMマスターノードをデプロイ | 上流データソースの数に応じて、1～N 台の DM ワーカーノードをデプロイ。通常は 1台の DM ワーカーノードを推奨します。 | -|
  • 大規模なデータセット（1 TiB 以上）と MySQL シャードの移行およびマージ
  • 一度限りのデータ移行
    • | 長時間のデータ移行中に DM クラスターの可用性を確保するために、3つの DM マスターノードを展開することをお勧めします。 | データソースまたは移行タスクの数に応じて、DMワーカーノードをデプロイ。稼働中のDMワーカーノードに加えて、アイドル状態のDMワーカーノードを1～3台展開することをお勧めします。 | +|
  • 大規模なデータセット（1 TiB 以上）と MySQL シャードの移行およびマージ
  • 一度限りのデータ移行
    • | 長時間のデータ移行中に DM クラスターの可用性を確保するために、3つの DM マスターノードをデプロイすることをお勧めします。 | データソースまたは移行タスクの数に応じて、DMワーカーノードをデプロイ。稼働中のDMワーカーノードに加えて、アイドル状態のDMワーカーノードを1～3台デプロイすることをお勧めします。 | | 長期データ複製 | DMマスターノードは3台必要です。クラウド上にDMマスターノードをデプロイする場合は、異なるアベイラビリティゾーン（AZ）にデプロイするようにしてください。 | データソース数や移行タスク数に応じて、DMワーカーノードをデプロイ。実際に必要なDMワーカーノード数の1.5～2倍を配置する必要があります。 | #### アップストリームデータソースを選択して構成する {#choose-and-configure-the-upstream-data-source} diff --git a/dm/dm-faq.md b/dm/dm-faq.md index 6e0233e41d03b..4b9a7278cd2f1 100644 --- a/dm/dm-faq.md +++ b/dm/dm-faq.md @@ -133,7 +133,7 @@ DM v2.0 以降、増分データレプリケーションを続行するために このエラーは[DM 1.0 クラスターの DM 移行タスクを DM 2.0 クラスターに手動でインポートする](/dm/manually-upgrade-dm-1.0-to-2.0.md)で処理できます。 -## TiUP がDM の一部のバージョン (たとえば、v2.0.0-hotfix) の展開に失敗するのはなぜですか? {#why-does-tiup-fail-to-deploy-some-versions-of-dm-for-example-v200-hotfix} +## TiUP がDM の一部のバージョン (たとえば、v2.0.0-hotfix) のデプロイに失敗するのはなぜですか? {#why-does-tiup-fail-to-deploy-some-versions-of-dm-for-example-v200-hotfix} `tiup list dm-master`コマンドを使用すると、 TiUP がデプロイをサポートしている DM バージョンを表示できます。このコマンドで表示されない DM バージョンはTiUPによって管理されません。 diff --git a/dm/dm-open-api.md b/dm/dm-open-api.md index 0516cb450dc62..8c72601e8e92c 100644 --- a/dm/dm-open-api.md +++ b/dm/dm-open-api.md @@ -27,7 +27,7 @@ OpenAPI を有効にするには、次のいずれかの操作を実行します > > - DMはOpenAPI 3.0.0標準に準拠した[仕様書](https://github.com/pingcap/tiflow/blob/release-8.5/dm/openapi/spec/dm.yaml)提供します。このドキュメントには、すべてのリクエストパラメータと戻り値が含まれています。このドキュメントのyamlをコピーして、 [Swaggerエディター](https://editor.swagger.io/)でプレビューできます。 > -> - DM マスターノードを展開した後、 `http://{master-addr}/api/v1/docs`アクセスしてドキュメントをオンラインでプレビューできます。 +> - DM マスターノードをデプロイした後、 `http://{master-addr}/api/v1/docs`アクセスしてドキュメントをオンラインでプレビューできます。 > > - 設定ファイルでサポートされている一部の機能は、OpenAPIではサポートされていません。これらの機能は完全には連携されていません。本番環境では、 [設定ファイル](/dm/dm-config-overview.md)を使用することをお勧めします。 diff --git a/dm/maintain-dm-using-tiup.md b/dm/maintain-dm-using-tiup.md index 00dc1a452fb36..d5cd762d5c3b3 100644 --- a/dm/maintain-dm-using-tiup.md +++ b/dm/maintain-dm-using-tiup.md @@ -7,7 +7,7 @@ summary: TiUPを使用して DM クラスターを保守する方法を学びま このドキュメントでは、TiUP DMコンポーネントを使用して DM クラスターを保守する方法について説明します。 -DM クラスターをまだ展開していない場合は、手順[TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)を参照してください。 +DM クラスターをまだデプロイしていない場合は、手順[TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)を参照してください。 > **Note:** > @@ -380,4 +380,4 @@ export TIUP_NATIVE_SSH=enable > **Note:** > -> クラスターの展開プロセス中に、接続にパスワードを使用する必要がある場合、またはキー ファイルに`passphrase`が設定されている場合は、コントロールマシンに`sshpass`がインストールされていることを確認する必要があります。そうでない場合、タイムアウトエラーが報告されます。 +> クラスターのデプロイプロセス中に、接続にパスワードを使用する必要がある場合、またはキー ファイルに`passphrase`が設定されている場合は、コントロールマシンに`sshpass`がインストールされていることを確認する必要があります。そうでない場合、タイムアウトエラーが報告されます。 diff --git a/dm/quick-start-with-dm.md b/dm/quick-start-with-dm.md index 6ee84b8d7a37e..414ae954fa5cc 100644 --- a/dm/quick-start-with-dm.md +++ b/dm/quick-start-with-dm.md @@ -9,7 +9,7 @@ summary: TiUP Playground を使用してデータ移行環境をすばやくセ > **Note:** > -> 本番への展開については、 [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)を参照してください。 +> 本番へのデプロイについては、 [TiUPを使用して DMクラスタをデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)を参照してください。 ## ステップ1: テスト環境をセットアップする {#step-1-set-up-the-test-environment} diff --git a/dr-solution-introduction.md b/dr-solution-introduction.md index 5c3f1fa1f5e10..412c82df3f4e2 100644 --- a/dr-solution-introduction.md +++ b/dr-solution-introduction.md @@ -99,7 +99,7 @@ BRに基づく DR ソリューションは、5分未満の RPO と、復元す ### その他の災害復旧ソリューション {#other-dr-solutions} -前述の DR ソリューションに加えて、同じ都市のデュアルセンター シナリオでゼロ RPO が必須の場合は、DR-AUTO 同期ソリューションを使用することもできます。詳細については、[1つの地域に展開された 2つのデータセンター](/two-data-centers-in-one-city-deployment.md)をご覧ください。 +前述の DR ソリューションに加えて、同じ都市のデュアルセンター シナリオでゼロ RPO が必須の場合は、DR-AUTO 同期ソリューションを使用することもできます。詳細については、[1つの地域にデプロイされた 2つのデータセンター](/two-data-centers-in-one-city-deployment.md)をご覧ください。 ## 解決策の比較 {#solution-comparison} diff --git a/ecosystem-tool-user-case.md b/ecosystem-tool-user-case.md index e446abc5e7876..5ed05e932771f 100644 --- a/ecosystem-tool-user-case.md +++ b/ecosystem-tool-user-case.md @@ -9,7 +9,7 @@ summary: TiDB ツールの一般的な使用例とツールの選択方法につ ## 物理マシンまたは仮想マシンに TiDB をデプロイ運用する {#deploy-and-operate-tidb-on-physical-or-virtual-machines} -物理マシンまたは仮想マシンに TiDB を展開して操作する必要がある場合は、 [TiUP](/tiup/tiup-overview.md)をインストールし、 TiUPを使用して TiDB、PD、TiKV などの TiDB コンポーネントを管理できます。 +物理マシンまたは仮想マシンに TiDB をデプロイして操作する必要がある場合は、 [TiUP](/tiup/tiup-overview.md)をインストールし、 TiUPを使用して TiDB、PD、TiKV などの TiDB コンポーネントを管理できます。 ## Kubernetes 上で TiDBをデプロイて運用する {#deploy-and-operate-tidb-on-kubernetes} diff --git a/ecosystem-tool-user-guide.md b/ecosystem-tool-user-guide.md index b300040df1959..58decc95f9d87 100644 --- a/ecosystem-tool-user-guide.md +++ b/ecosystem-tool-user-guide.md @@ -7,9 +7,9 @@ summary: ツールと適用可能なシナリオを学習します。 TiDBは、TiDBの導入と保守、データ管理（データ移行、バックアップと復元、データ比較など）、TiKV上でのSpark SQLの実行を支援する豊富なツールセットを提供しています。ニーズに応じて適切なツールを選択できます。 -## 展開および運用ツール {#deployment-and-operation-tools} +## デプロイおよび運用ツール {#deployment-and-operation-tools} -TiDB は、さまざまなシステム環境での展開および運用のニーズを満たすために、 TiUPとTiDB Operator を提供します。 +TiDB は、さまざまなシステム環境でのデプロイおよび運用のニーズを満たすために、 TiUPとTiDB Operator を提供します。 ### 物理マシンまたは仮想マシンに TiDBをデプロイて運用する - TiUP {#deploy-and-operate-tidb-on-physical-or-virtual-machines-tiup} diff --git a/enable-tls-between-components.md b/enable-tls-between-components.md index 144e0206fd6c7..8ab8bea3c3ec4 100644 --- a/enable-tls-between-components.md +++ b/enable-tls-between-components.md @@ -233,7 +233,7 @@ TiDBコンポーネント間の通信にTLSを設定したら、以下のコマ ## 証明書を再読み込みする {#reload-certificates} -- TiDB クラスターがローカルデータセンターに展開されている場合、証明書とキーを再ロードするために、TiDB、PD、TiKV、 TiFlash、TiCDC、およびすべての種類のクライアントは、新しい接続が作成されるたびに、TiDB クラスターを再起動せずに現在の証明書とキー ファイルを再読み取ります。 +- TiDB クラスターがローカルデータセンターにデプロイされている場合、証明書とキーを再ロードするために、TiDB、PD、TiKV、 TiFlash、TiCDC、およびすべての種類のクライアントは、新しい接続が作成されるたびに、TiDB クラスターを再起動せずに現在の証明書とキー ファイルを再読み取ります。 - TiProxy は 1時間に 1回、ディスクから証明書を再読み込みします。 diff --git a/encryption-at-rest.md b/encryption-at-rest.md index ee0d1f3514ed6..c11bcf047405d 100644 --- a/encryption-at-rest.md +++ b/encryption-at-rest.md @@ -21,7 +21,7 @@ TiDBクラスターをデプロイすると、ユーザーデータの大部分 TiKVは保存時の暗号化をサポートしています。この機能により、TiKVは[AES](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard)または[SM4](https://en.wikipedia.org/wiki/SM4_(cipher)) in [CTR](https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation)モードを使用してデータファイルを透過的に暗号化できます。保存時の暗号化を有効にするには、ユーザーが暗号化キーを提供する必要があります。このキーはマスターキーと呼ばれます。TiKVは、実際のデータファイルの暗号化に使用したデータキーを自動的にローテーションします。マスターキーは手動で随時ローテーションできます。保存時の暗号化は、保存中のデータ（つまりディスク上）のみを暗号化し、ネットワーク経由で転送中のデータは暗号化しないことに注意してください。保存時の暗号化とTLSを併用することをお勧めします。 -クラウド展開とセルフホスト展開の両方でキー管理サービス (KMS) を使用することも、プレーンテキストのマスターキーをファイルで提供することもできます。 +クラウドデプロイとセルフホストデプロイの両方でキー管理サービス (KMS) を使用することも、プレーンテキストのマスターキーをファイルで提供することもできます。 TiKVは現在、コアダンプから暗号鍵とユーザーデータを除外していません。保存時の暗号化を使用する場合は、TiKVプロセスのコアダンプを無効にすることをお勧めします。これは現在、TiKV自体では処理されていません。 @@ -33,7 +33,7 @@ SM4暗号化はTiKVバージョン6.3.0以降でのみサポートされます TiFlash は保存時の暗号化をサポートします。データキーはTiFlashによって生成されます。TiFlash（ TiFlash Proxy を含む）に書き込まれるすべてのファイル（データファイル、スキーマファイル、一時ファイルを含む）は、現在のデータキーを使用して暗号化されます。暗号化アルゴリズム、暗号化設定（ TiFlashでサポートされる[`tiflash-learner.toml`ファイル](/tiflash/tiflash-configuration.md#configure-the-tiflashtoml-file) ）、および監視メトリックの意味は、TiKV のものと一致しています。 -Grafana を使用してTiFlash を展開した場合は、 **TiFlash-Proxy-Details** -> **Encryption**パネルを確認できます。 +Grafana を使用してTiFlash をデプロイした場合は、 **TiFlash-Proxy-Details** -> **Encryption**パネルを確認できます。 SM4 暗号化は、 TiFlashの v6.4.0 以降のバージョンでのみサポートされます。TiFlashのv6.4.0 より前のバージョンでは、AES 暗号化のみがサポートされます。 diff --git a/faq/deploy-and-maintain-faq.md b/faq/deploy-and-maintain-faq.md index 2305ff358244c..65e4a8d93be3f 100644 --- a/faq/deploy-and-maintain-faq.md +++ b/faq/deploy-and-maintain-faq.md @@ -33,7 +33,7 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ 詳細は[ソフトウェアとハ​​ードウェアの推奨事項](/hardware-and-software-requirements.md)参照。 -## インストールと展開 {#installation-and-deployment} +## インストールとデプロイ {#installation-and-deployment} 本番環境では、 [TiUP](/tiup/tiup-overview.md)を使用してTiDBクラスタをデプロイすることをお勧めします。[TiUPを使用して TiDBクラスタをデプロイ](/production-deployment-using-tiup.md)を参照してください。 diff --git a/faq/faq-overview.md b/faq/faq-overview.md index 12eee5bacde11..07a5c9540f176 100644 --- a/faq/faq-overview.md +++ b/faq/faq-overview.md @@ -7,4 +7,4 @@ summary: TiDB に関するよくある質問 (FAQ) をまとめています。 このドキュメントでは、TiDB に関するよくある質問 (FAQ) をまとめています。 -
    カテゴリ関連文書
    TiDBのアーキテクチャと原則TiDBアーキテクチャに関するFAQ
    展開
    データ移行
    データのバックアップと復元バックアップと復元に関するよくある質問
    SQL操作SQLに関するよくある質問
    クラスタのアップグレードTiDB アップグレードに関する FAQ
    クラスタ管理クラスタ管理に関するFAQ
    監視と警告
    高可用性と高信頼性
    一般的なエラーコードエラーコードとトラブルシューティング
    +
    カテゴリ関連文書
    TiDBのアーキテクチャと原則TiDBアーキテクチャに関するFAQ
    デプロイ
    データ移行
    データのバックアップと復元バックアップと復元に関するよくある質問
    SQL操作SQLに関するよくある質問
    クラスタのアップグレードTiDB アップグレードに関する FAQ
    クラスタ管理クラスタ管理に関するFAQ
    監視と警告
    高可用性と高信頼性
    一般的なエラーコードエラーコードとトラブルシューティング
    diff --git a/faq/high-availability-faq.md b/faq/high-availability-faq.md index 2de8af35bffa2..77bbf290a85ef 100644 --- a/faq/high-availability-faq.md +++ b/faq/high-availability-faq.md @@ -13,6 +13,6 @@ summary: TiDB の高可用性に関連する FAQ について説明します。 最下層では、TiKVはレプリケーションログ＋ステートマシンのモデルを用いてデータを複製します。書き込みリクエストの場合、データはLeaderに書き込まれ、Leaderはログの形式でコマンドをフォロワーに複製します。クラスター内の過半数のノードがこのログを受信すると、ログはコミットされ、ステートマシンに適用できるようになります。 -## 地理的に分散した 3つのデータセンターを展開する場合に推奨されるソリューションは何ですか? {#what-s-the-recommended-solution-for-the-deployment-of-three-geo-distributed-data-centers} +## 地理的に分散した 3つのデータセンターをデプロイする場合に推奨されるソリューションは何ですか? {#what-s-the-recommended-solution-for-the-deployment-of-three-geo-distributed-data-centers} TiDBのアーキテクチャは、地理的分散とマルチアクティブ性を完全にサポートすることを保証します。データとアプリケーションは常時稼働です。すべての障害はアプリケーションに対して透過的であり、データは自動的に復旧できます。動作はネットワークのレイテンシーと安定性に依存します。レイテンシーは5ミリ秒以内に抑えることを推奨します。現在、TiDBには同様のユースケースが既に存在します。詳細については、 [2つの地域に配置された 3つのデータセンター](/three-data-centers-in-two-cities-deployment.md)ご覧ください。 diff --git a/faq/manage-cluster-faq.md b/faq/manage-cluster-faq.md index f5e03b86f52f8..1834ca33ed1b6 100644 --- a/faq/manage-cluster-faq.md +++ b/faq/manage-cluster-faq.md @@ -353,7 +353,7 @@ TiKVで大量のデータを書き込んだり読み込んだりすると、I/O ### TiKVはSAS/SATAディスク、またはSSD/SASディスクの混在構成をサポートしていますか？ {#does-tikv-support-sas-sata-disks-or-mixed-deployment-of-ssd-sas-disks} -いいえ。OLTPシナリオでは、TiDBはデータアクセスと操作に高I/Oディスクを必要とします。TiDBは強力な一貫性を備えた分散データベースであり、レプリカレプリケーションやボトムレイヤーストレージの圧縮など、書き込み増幅機能を備えています。そのため、TiDBのベストプラクティスでは、ストレージディスクとしてNVMe SSDの使用を推奨しています。TiKVとPDの混在展開はサポートされていません。 +いいえ。OLTPシナリオでは、TiDBはデータアクセスと操作に高I/Oディスクを必要とします。TiDBは強力な一貫性を備えた分散データベースであり、レプリカレプリケーションやボトムレイヤーストレージの圧縮など、書き込み増幅機能を備えています。そのため、TiDBのベストプラクティスでは、ストレージディスクとしてNVMe SSDの使用を推奨しています。TiKVとPDの混在デプロイはサポートされていません。 ### キーデータテーブルの範囲は、データアクセス前に分割されますか？ {#is-the-range-of-the-key-data-table-divided-before-data-access} diff --git a/follower-read.md b/follower-read.md index a0f5ffc906358..9434da69f8388 100644 --- a/follower-read.md +++ b/follower-read.md @@ -22,14 +22,14 @@ Follower Read を実行する際、TiDB はトポロジ情報に基づいて適 フォロワーが読み取りリクエストを処理できるようにすることで、 Follower Read は次の目標を達成します。 - 読み取りホットスポットを分散し、リーダーの作業負荷を軽減します。 -- マルチ AZ またはマルチデータセンターの展開でローカルレプリカの読み取りを優先し、AZ 間のトラフィックを最小限に抑えます。 +- マルチ AZ またはマルチデータセンターのデプロイでローカルレプリカの読み取りを優先し、AZ 間のトラフィックを最小限に抑えます。 ## 使用シナリオ {#usage-scenarios} Follower Read は次のシナリオに適しています。 - 読み取り要求が集中するアプリケーション、または読み取りホットスポットが顕著なアプリケーション。 -- ローカルレプリカからの読み取りを優先して、AZ 間の帯域幅使用量を削減するマルチ AZ 展開。 +- ローカルレプリカからの読み取りを優先して、AZ 間の帯域幅使用量を削減するマルチ AZ デプロイ。 - 全体的な読み取りパフォーマンスをさらに向上させたい読み取り/書き込み分離アーキテクチャ。 > **Note:** diff --git a/geo-distributed-deployment-topology.md b/geo-distributed-deployment-topology.md index 69358fd5bff92..9c5e95bb0c3f2 100644 --- a/geo-distributed-deployment-topology.md +++ b/geo-distributed-deployment-topology.md @@ -42,7 +42,7 @@ summary: TiDB の地理的に分散された展開トポロジについて学習 - ラベル構成: - TiKVは複数のデータセンターにまたがって展開されているため、物理マシンがダウンすると、 Raftグループはデフォルトの5つのレプリカのうち3つを失い、クラスターが利用できなくなる可能性があります。この問題に対処するには、ラベルを設定してPDのスマートスケジューリングを有効にします。これにより、 Raftグループは、同じデータセンターの同じキャビネット内の同じマシン上のTiKVインスタンスに3つのレプリカを配置することを許可しません。 + TiKVは複数のデータセンターにまたがってデプロイされているため、物理マシンがダウンすると、 Raftグループはデフォルトの5つのレプリカのうち3つを失い、クラスターが利用できなくなる可能性があります。この問題に対処するには、ラベルを設定してPDのスマートスケジューリングを有効にします。これにより、 Raftグループは、同じデータセンターの同じキャビネット内の同じマシン上のTiKVインスタンスに3つのレプリカを配置することを許可しません。 - TiKV 構成: diff --git a/glossary.md b/glossary.md index 347a1d6876930..847ac0da8e2f0 100644 --- a/glossary.md +++ b/glossary.md @@ -268,7 +268,7 @@ Placement Driver(PD) は、メタデータの保存、トランザクション ### 配置ルール（Placement Rules） {#placement-rules} -配置ルールは、TiKVクラスタにおけるデータの配置を設定するために使用されます。この機能を使用すると、テーブルとパーティションを異なるリージョン、データセンター、キャビネット、またはホストに展開するように指定できます。使用例としては、低コストでデータ可用性戦略を最適化すること、ローカルの古いデータの読み取りのためにローカルデータレプリカが利用可能であることを保証すること、およびローカルのデータコンプライアンス要件に準拠することなどが挙げられます。 +配置ルールは、TiKVクラスタにおけるデータの配置を設定するために使用されます。この機能を使用すると、テーブルとパーティションを異なるリージョン、データセンター、キャビネット、またはホストにデプロイするように指定できます。使用例としては、低コストでデータ可用性戦略を最適化すること、ローカルの古いデータの読み取りのためにローカルデータレプリカが利用可能であることを保証すること、およびローカルのデータコンプライアンス要件に準拠することなどが挙げられます。 詳細については、 [SQLにおける配置ルール](/placement-rules-in-sql.md)を参照してください。 diff --git a/hardware-and-software-requirements.md b/hardware-and-software-requirements.md index 4b2361029306e..86d204ff0a2ae 100644 --- a/hardware-and-software-requirements.md +++ b/hardware-and-software-requirements.md @@ -95,7 +95,7 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ | コンポーネント | CPU | メモリ | ローカルストレージ | ネットワーク | インスタンス数（最小要件） | | :-----: | :----: | :----: | :---------------------------: | :------------: | :------------------: | -| TiDB | 8コア以上 | 16GB以上 | [ストレージ要件](#storage-requirements) | ギガビットネットワークカード | 1（PDと同じマシンに展開可能） | +| TiDB | 8コア以上 | 16GB以上 | [ストレージ要件](#storage-requirements) | ギガビットネットワークカード | 1（PDと同じマシンにデプロイ可能） | | PD | 4コア以上 | 8GB以上 | SAS、200GB以上 | ギガビットネットワークカード | 1（TiDBと同じマシンにデプロイ可能） | | TiKV | 8コア以上 | 32GB以上 | SAS、200GB以上 | ギガビットネットワークカード | 3 | | TiFlash | 32コア以上 | 64GB以上 | SSD、200GB以上 | ギガビットネットワークカード | 1 | @@ -107,7 +107,7 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ > - テスト環境では、TiDBとPDのインスタンスを同じサーバーにデプロイできます。 > - 性能関連のテストにおいては、テスト結果の正確性を保証するため、性能の低いストレージおよびネットワークハードウェア構成を使用しないでください。 > - TiKVサーバーには、読み書き速度を向上させるためにNVMe SSDの使用をお勧めします。 -> - 機能をテストして確認するだけの場合は、 [TiDB クイックスタートガイド](/quick-start-with-tidb.md)に従って単一マシンに TiDB を展開してください。 +> - 機能をテストして確認するだけの場合は、 [TiDB クイックスタートガイド](/quick-start-with-tidb.md)に従って単一マシンに TiDB をデプロイしてください。 > - バージョン 6.3.0 以降、Linux AMD64アーキテクチャでTiFlash をデプロイするには、CPU が AVX2 命令セットをサポートしている必要があります。 `grep avx2 /proc/cpuinfo`に出力があることを確認してください。Linux ARM64アーキテクチャでTiFlash をデプロイするには、CPU が ARMv8 命令セットアーキテクチャをサポートしている必要があります。 `grep 'crc32' /proc/cpuinfo | grep 'asimd'`に出力があることを確認してください。命令セット拡張機能を使用することで、TiFlash のベクトル化エンジンはより優れたパフォーマンスを発揮できます。 ### 本番環境 {#production-environment} @@ -135,7 +135,7 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ TiFlashを導入する前に、以下の項目に注意してください。 -- TiFlash は[複数のディスクに展開されています](/tiflash/tiflash-configuration.md#multi-disk-deployment)。 +- TiFlash は[複数のディスクにデプロイされています](/tiflash/tiflash-configuration.md#multi-disk-deployment)。 - TiFlashデータディレクトリの最初のディスクとして、TiKVデータのリアルタイムレプリケーションをバッファリングするために、高性能SSDを使用することをお勧めします。このディスクの性能は、PCIe SSDなど、TiKVと同等以上である必要があります。ディスク容量は、総容量の10%以上でなければなりません。そうでない場合、このノードのボトルネックになる可能性があります。他のディスクには通常のSSDを使用することもできますが、より高性能なPCIe SSDを使用すると、パフォーマンスが向上することに注意してください。 - TiFlashはTiKVとは別のノードにデプロイすることをお勧めします。どうしても同じノードにTiFlashとTiKVをデプロイする必要がある場合は、CPUコア数とメモリ容量を増やし、互いに干渉しないようにTiFlashとTiKVを異なるディスクにデプロイするようにしてください。 - TiFlashディスクの総容量は、次のように計算されます: `the data volume of the entire TiKV cluster to be replicated / the number of TiKV replicas * the number of TiFlash replicas` 。たとえば、TiKV の計画容量が 1 TB、TiKV レプリカ数が 3、 TiFlashレプリカ数が 2 の場合、推奨されるTiFlashの総容量は`1024 GB / 3 * 2`です。一部のテーブルのデータのみを複製することもできます。その場合は、複製するテーブルのデータ量に応じてTiFlash の容量を決定します。 diff --git a/hybrid-deployment-topology.md b/hybrid-deployment-topology.md index a235c176cfdfb..2b93d26148e53 100644 --- a/hybrid-deployment-topology.md +++ b/hybrid-deployment-topology.md @@ -5,9 +5,9 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて # ハイブリッド展開トポロジ {#hybrid-deployment-topology} -このドキュメントでは、TiKV と TiDB のハイブリッド展開のトポロジと主要なパラメータについて説明します。 +このドキュメントでは、TiKV と TiDB のハイブリッドデプロイのトポロジと主要なパラメータについて説明します。 -ハイブリッド展開は通常、次のシナリオで使用されます。 +ハイブリッドデプロイは通常、次のシナリオで使用されます。 デプロイメントマシンには、十分なメモリを備えた複数のCPUプロセッサが搭載されています。物理マシンリソースの利用率を向上させるため、TiDBとTiKVのCPUリソースはNUMAノードバインディングによって分離され、単一のマシンに複数のインスタンスをデプロイできます。PDとPrometheusは一緒にデプロイされますが、それぞれのデータディレクトリは別々のファイルシステムを使用する必要があります。 @@ -26,8 +26,8 @@ summary: TiDB クラスターのハイブリッド展開トポロジについて ### トポロジテンプレート {#topology-templates} -- [ハイブリッド展開のためのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-multi-instance.yaml) -- [ハイブリッド展開のための複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-multi-instance.yaml) +- [ハイブリッドデプロイのためのシンプルなテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-multi-instance.yaml) +- [ハイブリッドデプロイのための複雑なテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-multi-instance.yaml) 上記の TiDB クラスター トポロジファイルの構成項目の詳細については、 [TiUPを使用して TiDB をデプロイするためのトポロジコンフィグレーションファイル](/tiup/tiup-cluster-topology-reference.md)を参照してください。 diff --git a/migrate-small-mysql-shards-to-tidb.md b/migrate-small-mysql-shards-to-tidb.md index 5d32fb3a19af2..a0a959137e027 100644 --- a/migrate-small-mysql-shards-to-tidb.md +++ b/migrate-small-mysql-shards-to-tidb.md @@ -218,7 +218,7 @@ Grafana またはログを通じて、移行タスクの履歴と内部運用メ DM の実行中、DM-master、DM-worker、dmctl は、移行タスクに関する情報を含むログを出力します。各コンポーネントのログディレクトリは以下のとおりです。 - - DMマスターログディレクトリ：DMマスタープロセスパラメータ`--log-file`で指定されます。DMがTiUPを使用して展開されている場合、ログディレクトリは`/dm-deploy/dm-master-8261/log/`です。 + - DMマスターログディレクトリ：DMマスタープロセスパラメータ`--log-file`で指定されます。DMがTiUPを使用してデプロイされている場合、ログディレクトリは`/dm-deploy/dm-master-8261/log/`です。 - DMワーカーログディレクトリ：DMワーカープロセスパラメータ`--log-file`で指定します。DMがTiUPを使用してデプロイされている場合、ログディレクトリは`/dm-deploy/dm-worker-8262/log/`です。 ## 参照 {#see-also} diff --git a/migrate-small-mysql-to-tidb.md b/migrate-small-mysql-to-tidb.md index e6df1b91c7058..7fa8202182b26 100644 --- a/migrate-small-mysql-to-tidb.md +++ b/migrate-small-mysql-to-tidb.md @@ -124,7 +124,7 @@ tiup dmctl --master-addr ${advertise-addr} query-status ${task-name} TiUPを使用して DM をデプロイする際に Prometheus、Alertmanager、Grafana をデプロイしている場合は、デプロイ時に指定した IP アドレスとポートを使用して Grafana にアクセスできます。その後、DM ダッシュボードを選択して、DM 関連の監視メトリクスを表示できます。 -- DMマスターのログディレクトリ：DMマスタープロセスパラメータ`--log-file`で指定されます。TiUPを使用してDMを展開した場合、ログディレクトリはデフォルトで`/dm-deploy/dm-master-8261/log/`なります。 +- DMマスターのログディレクトリ：DMマスタープロセスパラメータ`--log-file`で指定されます。TiUPを使用してDMをデプロイした場合、ログディレクトリはデフォルトで`/dm-deploy/dm-master-8261/log/`なります。 - DM-workerのログディレクトリ：DM-workerプロセスパラメータ`--log-file`で指定されます。TiUPを使用してDMをデプロイした場合、デフォルトのログディレクトリは`/dm-deploy/dm-worker-8262/log/`です。 ## 次は何？ {#what-s-next} diff --git a/multi-data-centers-in-one-city-deployment.md b/multi-data-centers-in-one-city-deployment.md index ba2a48644e2c4..742b9be02a1b7 100644 --- a/multi-data-centers-in-one-city-deployment.md +++ b/multi-data-centers-in-one-city-deployment.md @@ -3,7 +3,7 @@ title: Multiple Availability Zones in One Region Deployment summary: 1つのリージョン内の複数の可用性ゾーンへのデプロイメント ソリューションについて学習します。 --- -# 1つのリージョンに複数のアベイラビリティゾーンを展開 {#multiple-availability-zones-in-one-region-deployment} +# 1つのリージョンに複数のアベイラビリティゾーンをデプロイ {#multiple-availability-zones-in-one-region-deployment} - TiDB クラスター以外のサービスはありますか? -- `pd-server`と`tikv-server`は別々に展開されますか? +- `pd-server`と`tikv-server`は別々にデプロイされますか? - 現在の操作は何ですか? - `top -H`コマンドを使用して CPU スレッド名を確認します。 - 最近、ネットワークまたは IO 監視データに例外はありますか? diff --git a/troubleshoot-tidb-oom.md b/troubleshoot-tidb-oom.md index c11aedc5867a0..24cd4d9600eb7 100644 --- a/troubleshoot-tidb-oom.md +++ b/troubleshoot-tidb-oom.md @@ -51,7 +51,7 @@ OOM の問題をトラブルシューティングする場合は、次のプロ 2. OOM の問題であることを確認した後、OOM の原因がデプロイメントによるものかデータベースによるものかをさらに調査できます。 - - OOM が展開の問題によって発生した場合は、リソース構成とハイブリッド展開の影響を調査する必要があります。 + - OOM がデプロイの問題によって発生した場合は、リソース構成とハイブリッドデプロイの影響を調査する必要があります。 - OOM がデータベースの問題によって発生した場合、次のような原因が考えられます。 - TiDB は、大規模なクエリ、大規模な書き込み、データのインポートなどの大規模なデータ トラフィックを処理します。 - TiDB は、複数の SQL ステートメントが同時にリソースを消費したり、オペレーターの同時実行性が高くなったりする、同時実行性の高いシナリオです。 @@ -63,13 +63,13 @@ OOM の問題をトラブルシューティングする場合は、次のプロ OOM の問題は通常、次の原因で発生します。 -- [展開の問題](#deployment-issues) +- [デプロイの問題](#deployment-issues) - [データベースの問題](#database-issues) - [クライアント側の問題](#client-side-issues) -### 展開の問題 {#deployment-issues} +### デプロイの問題 {#deployment-issues} -不適切な展開による OOM の原因は次のとおりです。 +不適切なデプロイによる OOM の原因は次のとおりです。 - オペレーティングシステムのメモリ容量が小さすぎます。 - TiUP構成[`resource_control`](/tiup/tiup-cluster-topology-reference.md#global)は適切ではありません。 diff --git a/tune-tikv-memory-performance.md b/tune-tikv-memory-performance.md index abd818fdb888b..5722c5d49baa2 100644 --- a/tune-tikv-memory-performance.md +++ b/tune-tikv-memory-performance.md @@ -249,7 +249,7 @@ target-file-size-base = "32MiB" ## TiKVの推奨構成 {#recommended-configuration-of-tikv} -- 本番環境では、CPU コアが 8 個未満、またはメモリが 32 GiB 未満のマシンに TiKV を展開することは推奨されません。 +- 本番環境では、CPU コアが 8 個未満、またはメモリが 32 GiB 未満のマシンに TiKV をデプロイすることは推奨されません。 - 高い書き込みスループットが求められる場合は、スループット容量の優れたディスクを使用することをお勧めします。 diff --git a/tune-tikv-thread-performance.md b/tune-tikv-thread-performance.md index d0a9e4b428f49..c4f38b9271bfc 100644 --- a/tune-tikv-thread-performance.md +++ b/tune-tikv-thread-performance.md @@ -44,7 +44,7 @@ TiKV v5.0以降、すべての読み取りリクエストはデフォルトで v8.5.4以降、gRPCスレッドプールのデフォルトサイズ（ `server.grpc-concurrency`で設定）が固定値の`5`から、CPUコア数に基づいて計算される適応値に変更されました。詳細な計算式については、 [`server.grpc-concurrency`](/tikv-configuration-file.md#grpc-concurrency)を参照してください。このスレッドプールはコンピューティングオーバーヘッドがほとんどなく、主にネットワークI/Oとデシリアライズリクエストを処理するため、通常はデフォルト設定を調整する必要はありません。 - - TiKV で展開されたマシンの CPU コア数が少ない (8 個以下) 場合は、 `server.grpc-concurrency`構成項目を`2`に設定することを検討してください。 + - TiKV でデプロイされたマシンの CPU コア数が少ない (8 個以下) 場合は、 `server.grpc-concurrency`構成項目を`2`に設定することを検討してください。 - TiKV を導入したマシンの構成が非常に高く、TiKV が大量の読み取りおよび書き込み要求を処理し、Grafana でスレッド CPU を監視する値`gRPC poll CPU`が`server.grpc-concurrency`の 80% を超える場合は、スレッドプールの使用率を 80% 未満 (つまり、Grafana のメトリックが`80% * server.grpc-concurrency`未満) に保つために値`server.grpc-concurrency`を増やすことを検討してください。 - スケジューラスレッドプール。 diff --git a/two-data-centers-in-one-city-deployment.md b/two-data-centers-in-one-city-deployment.md index 2e05f5ed87c10..e7658c29f3b32 100644 --- a/two-data-centers-in-one-city-deployment.md +++ b/two-data-centers-in-one-city-deployment.md @@ -1,9 +1,9 @@ --- title: Two Availability Zones in One Region Deployment -summary: 1つのリージョンに 2つの可用性ゾーンを展開するソリューションについて学習します。 +summary: 1つのリージョンに 2つの可用性ゾーンをデプロイするソリューションについて学習します。 --- -# 1つのリージョンに2つのアベイラビリティゾーンを展開 {#two-availability-zones-in-one-region-deployment} +# 1つのリージョンに2つのアベイラビリティゾーンをデプロイ {#two-availability-zones-in-one-region-deployment} このドキュメントでは、アーキテクチャ、構成、このデプロイメント モードを有効にする方法、このモードでレプリカを使用する方法など、1つのリージョン内の 2つのアベイラビリティゾーン (AZ) のデプロイメント モードについて説明します。 @@ -19,7 +19,7 @@ TiDBは通常、高可用性と災害復旧機能を確保するために、マ このセクションでは、AZ1 と AZ2 という 2つのアベイラビリティゾーンがそれぞれ東と西に配置されているリージョンを例に説明します。AZ1 はプライマリ AZ で、AZ2 は災害復旧 (DR) AZ です。 -クラスター展開のアーキテクチャは次のとおりです。 +クラスターデプロイのアーキテクチャは次のとおりです。 - クラスターには6つのレプリカがあります。AZ1には3つのVoterレプリカ、AZ2には2つのVoterレプリカと1つのLearnerレプリカがあります。TiKVコンポーネントでは、各ラックに適切なラベルが付けられています。 - ユーザーにとって透過的なデータの一貫性と高可用性を確保するために、 Raftプロトコルが採用されています。 @@ -36,7 +36,7 @@ TiDBは通常、高可用性と災害復旧機能を確保するために、マ ### 例 {#example} -次の`tiup topology.yaml`サンプル ファイルは、1つのリージョン展開モードにおける 2つの可用性ゾーンの一般的なトポロジ構成です。 +次の`tiup topology.yaml`サンプル ファイルは、1つのリージョンデプロイモードにおける 2つの可用性ゾーンの一般的なトポロジ構成です。 ```yaml # # Global variables are applied to all deployments and used as the default value of @@ -275,7 +275,7 @@ curl http://pd_ip:pd_port/pd/api/v1/replication_mode/status ### 災害復旧 {#disaster-recovery} -このセクションでは、1つのリージョン展開における 2つの AZ の災害復旧ソリューションを紹介します。 +このセクションでは、1つのリージョンデプロイにおける 2つの AZ の災害復旧ソリューションを紹介します。 同期レプリケーションモードのクラスタに災害が発生した場合、 `RPO = 0`でデータリカバリを実行できます。 diff --git a/upgrade-monitoring-services.md b/upgrade-monitoring-services.md index da0ae46a60985..5f5d4d15c956f 100644 --- a/upgrade-monitoring-services.md +++ b/upgrade-monitoring-services.md @@ -11,7 +11,7 @@ TiDB クラスターをデプロイすると、 TiUP はクラスターの監視 > **Note:** > -> - 監視サービスが[手動で展開](/deploy-monitoring-services.md)の場合、 TiUPを使用する代わりに、このドキュメントを参照せずに直接アップグレードできます。 +> - 監視サービスが[手動でデプロイ](/deploy-monitoring-services.md)の場合、 TiUPを使用する代わりに、このドキュメントを参照せずに直接アップグレードできます。 > - TiDBと新しいバージョンの監視サービスとの互換性はテストされていないため、アップグレード後、一部の機能が期待どおりに動作しない可能性があります。問題が発生した場合は、GitHubで[問題](https://github.com/pingcap/tidb/issues)を作成してください。 > - このドキュメントのアップグレード手順は、 TiUPバージョン 1.9.0 以降に適用されます。そのため、アップグレード前にTiUP のバージョンをご確認ください。 > - TiUPを使用して TiDB クラスターをアップグレードすると、 TiUP は監視サービスをデフォルトバージョンに再デプロイします。TiDB のアップグレード後、監視サービスのアップグレードを再度実行する必要があります。 diff --git a/upgrade-tidb-using-tiup.md b/upgrade-tidb-using-tiup.md index 406e403118a04..913fe62ff15c7 100644 --- a/upgrade-tidb-using-tiup.md +++ b/upgrade-tidb-using-tiup.md @@ -217,7 +217,7 @@ tiup-cluster v1.14.0以降では、クラスタのアップグレード時に特 > **Note:** > -> TiDB、TiKV、PD、TiCDCなど、バージョン番号を共有するコンポーネントについては、バージョンが混在する展開環境で正しく動作することを保証する完全なテストは実施されていません。このセクションはテスト環境でのみ使用するか、または[テクニカルサポート](/support.md)の支援を受けて使用してください。 +> TiDB、TiKV、PD、TiCDCなど、バージョン番号を共有するコンポーネントについては、バージョンが混在するデプロイ環境で正しく動作することを保証する完全なテストは実施されていません。このセクションはテスト環境でのみ使用するか、または[テクニカルサポート](/support.md)の支援を受けて使用してください。 ```shell tiup cluster upgrade -h | grep "version" From 8ed6c7bb5ca441b4460470d0b619d078f7ba282c Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Fri, 28 Aug 2026 14:28:41 +0900 Subject: [PATCH 2/3] i18n(ja): also drop the long vowel mark in the deployment topology term MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Consolidates PR #23644 (now closed): unifies 展開トポロジー/デプロイメントトポロジー to 展開トポロジ (no long vowel mark), matching the target pages' own H1 titles. 6 files, 2 of which required combining with this PR's own deploy/deployment wording changes on the same lines. --- br/backup-and-restore-overview.md | 2 +- dr-secondary-cluster.md | 2 +- placement-rules-in-sql.md | 2 +- production-deployment-using-tiup.md | 8 ++++---- releases/release-6.3.0.md | 2 +- tidb-cloud/releases/release-notes-2022.md | 2 +- 6 files changed, 9 insertions(+), 9 deletions(-) diff --git a/br/backup-and-restore-overview.md b/br/backup-and-restore-overview.md index b26a9af68da78..e4b55bcde17b1 100644 --- a/br/backup-and-restore-overview.md +++ b/br/backup-and-restore-overview.md @@ -5,7 +5,7 @@ summary: TiDB Backup & Restore (BR) は、クラスタの高可用性とデー # TiDBのバックアップと復元の概要 {#tidb-backup--restore-overview} -TiDBは、 Raftプロトコルと適切なデプロイメントトポロジーに基づいて、クラスタの高い可用性を実現しています。クラスタ内のノードがいくつか故障しても、クラスタは引き続き利用可能です。さらにデータの安全性を確保するため、TiDBは、自然災害や誤操作からデータを復旧するための最終手段として、バックアップ＆リストア（BR）機能を提供しています。 +TiDBは、 Raftプロトコルと適切な展開トポロジに基づいて、クラスタの高い可用性を実現しています。クラスタ内のノードがいくつか故障しても、クラスタは引き続き利用可能です。さらにデータの安全性を確保するため、TiDBは、自然災害や誤操作からデータを復旧するための最終手段として、バックアップ＆リストア（BR）機能を提供しています。 BRは以下の要件を満たしています。 diff --git a/dr-secondary-cluster.md b/dr-secondary-cluster.md index b18b3362adb74..3f39389759eb3 100644 --- a/dr-secondary-cluster.md +++ b/dr-secondary-cluster.md @@ -42,7 +42,7 @@ summary: TiCDCに基づいたプライマリ・セカンダリディザスタリ ### プライマリクラスターとセカンダリクラスターを設定する {#set-up-primary-and-secondary-clusters} -このドキュメントでは、TiDBのプライマリクラスタとセカンダリクラスタは2つの異なるリージョン（リージョン1とリージョン2）にデプロイされています。プライマリクラスタとセカンダリクラスタの間には一定のネットワークレイテンシーがあるため、TiCDCはセカンダリクラスタと共にデプロイされます。TiCDCをセカンダリクラスタと共にデプロイすることで、ネットワークレイテンシーの影響を回避し、最適なレプリケーションパフォーマンスを実現できます。このドキュメントで提供する例のデプロイトポロジーは以下のとおりです（1つのコンポーネントノードが1つのサーバーにデプロイされます）。 +このドキュメントでは、TiDBのプライマリクラスタとセカンダリクラスタは2つの異なるリージョン（リージョン1とリージョン2）にデプロイされています。プライマリクラスタとセカンダリクラスタの間には一定のネットワークレイテンシーがあるため、TiCDCはセカンダリクラスタと共にデプロイされます。TiCDCをセカンダリクラスタと共にデプロイすることで、ネットワークレイテンシーの影響を回避し、最適なレプリケーションパフォーマンスを実現できます。このドキュメントで提供する例の展開トポロジは以下のとおりです（1つのコンポーネントノードが1つのサーバーにデプロイされます）。 | リージョン | ホスト | クラスタ | コンポーネント | | ------ | -------------------------- | ---- | ------------------------------- | diff --git a/placement-rules-in-sql.md b/placement-rules-in-sql.md index f3c9be88cff73..1f829106acd70 100644 --- a/placement-rules-in-sql.md +++ b/placement-rules-in-sql.md @@ -55,7 +55,7 @@ tikv-server --labels region=,zone=,host= | デプロイ方法 | 例 | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | 手動デプロイ | [トポロジーラベルに基づいてレプリカをスケジュールする](/schedule-replicas-by-topology-labels.md) | -| TiUPを使用したデプロイ | [地理的に分散した展開トポロジー](/geo-distributed-deployment-topology.md) | +| TiUPを使用したデプロイ | [地理的に分散した展開トポロジ](/geo-distributed-deployment-topology.md) | | TiDB Operatorを使用したデプロイメント | [KubernetesでTiDBクラスタを構成する](https://docs.pingcap.com/tidb-in-kubernetes/stable/configure-a-tidb-cluster#high-availability-of-data) | > **Note:** diff --git a/production-deployment-using-tiup.md b/production-deployment-using-tiup.md index e6373ddaaeab7..8c3b2e5f26d30 100644 --- a/production-deployment-using-tiup.md +++ b/production-deployment-using-tiup.md @@ -210,13 +210,13 @@ tiup cluster template > topology.yaml 以下の2つの一般的なシナリオでは、コマンドを実行することで推奨トポロジーテンプレートを生成できます。 -- ハイブリッド デプロイメントの場合: 複数のインスタンスが 1台のマシンにデプロイされます。詳細は[ハイブリッド展開トポロジー](/hybrid-deployment-topology.md)を参照。 +- ハイブリッド デプロイメントの場合: 複数のインスタンスが 1台のマシンにデプロイされます。詳細は[ハイブリッド展開トポロジ](/hybrid-deployment-topology.md)を参照。 ```shell tiup cluster template --full > topology.yaml ``` -- 地理的に分散したデプロイの場合: TiDB クラスターは地理的に分散したデータセンターにデプロイされます。詳細については、[地理的に分散した展開トポロジー](/geo-distributed-deployment-topology.md)を参照してください。 +- 地理的に分散したデプロイの場合: TiDB クラスターは地理的に分散したデータセンターにデプロイされます。詳細については、[地理的に分散した展開トポロジ](/geo-distributed-deployment-topology.md)を参照してください。 ```shell tiup cluster template --multi-dc > topology.yaml @@ -258,8 +258,8 @@ alertmanager_servers: | OLTP | [最小限のトポロジーをデプロイ](/minimal-deployment-topology.md) | [シンプルな最小限の構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-mini.yaml)
    [完全な最小構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-mini.yaml) | これは、tidb-server、tikv-server、およびpd-serverを含む基本的なクラスタトポロジーです。 | | HTAP | [TiFlashトポロジーをデプロイ](/tiflash-deployment-topology.md) | [シンプルなTiFlash設定テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-tiflash.yaml)
    [TiFlashの完全な構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-tiflash.yaml) | これは、最小限のクラスタトポロジーとともにTiFlashをデプロイするためのものです。TiFlashはカラム型ストレージエンジンであり、徐々に標準的なクラスタトポロジーへと進化していきます。 | | [TiCDC](/ticdc/ticdc-overview.md)を使用して増分データを複製する | [TiCDCトポロジーをデプロイ](/ticdc-deployment-topology.md) | [シンプルなTiCDC構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-cdc.yaml)
    [TiCDC構成テンプレート全体](https://github.com/pingcap/docs/blob/master/config-templates/complex-cdc.yaml) | これは、最小限のクラスタトポロジーとともにTiCDCをデプロイするためのものです。TiCDCは、TiDB、MySQL、Kafka、MQ、ストレージサービスなど、複数のダウンストリームプラットフォームをサポートしています。 | -| 1台のマシンに複数のインスタンスをデプロイ | [ハイブリッドトポロジーをデプロイ](/hybrid-deployment-topology.md) | [ハイブリッドデプロイ用のシンプルな構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-multi-instance.yaml)
    [ハイブリッドデプロイ用の完全な構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-multi-instance.yaml) | ディレクトリ、ポート、リソース比率、ラベルなどの追加設定が必要な場合にも、デプロイメントトポロジーが適用されます。 | -| TiDBクラスターをデータセンター全体にデプロイ | [地理的に分散したデプロイメントトポロジーをデプロイ](/geo-distributed-deployment-topology.md) | [地理的に分散したデプロイメントのためのコンフィグレーションテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/geo-redundancy-deployment.yaml) | このトポロジーは、2つの都市に3つのデータセンターを配置する典型的なアーキテクチャを例として取り上げています。地理的に分散したデプロイメントアーキテクチャと、注意すべき重要な構成について解説します。 | +| 1台のマシンに複数のインスタンスをデプロイ | [ハイブリッドトポロジーをデプロイ](/hybrid-deployment-topology.md) | [ハイブリッドデプロイ用のシンプルな構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/simple-multi-instance.yaml)
    [ハイブリッドデプロイ用の完全な構成テンプレート](https://github.com/pingcap/docs/blob/master/config-templates/complex-multi-instance.yaml) | ディレクトリ、ポート、リソース比率、ラベルなどの追加設定が必要な場合にも、展開トポロジが適用されます。 | +| TiDBクラスターをデータセンター全体にデプロイ | [地理的に分散した展開トポロジをデプロイ](/geo-distributed-deployment-topology.md) | [地理的に分散したデプロイメントのためのコンフィグレーションテンプレート](https://github.com/pingcap/docs/blob/master/config-templates/geo-redundancy-deployment.yaml) | このトポロジーは、2つの都市に3つのデータセンターを配置する典型的なアーキテクチャを例として取り上げています。地理的に分散したデプロイメントアーキテクチャと、注意すべき重要な構成について解説します。 | > **Note:** > diff --git a/releases/release-6.3.0.md b/releases/release-6.3.0.md index 2d1bfc9050c8a..920b9de34a8a5 100644 --- a/releases/release-6.3.0.md +++ b/releases/release-6.3.0.md @@ -193,7 +193,7 @@ TiDBバージョン: 6.3.0-DMR ### TiDBデータ共有サブスクリプション {#tidb-data-share-subscription} -- TiCDCは、地理的に分散した複数のデータソースからデータを複製できるデプロイメントトポロジーをサポートしています [#5301](https://github.com/pingcap/tiflow/issues/5301) @[sdojjy](https://github.com/sdojjy) +- TiCDCは、地理的に分散した複数のデータソースからデータを複製できる展開トポロジをサポートしています [#5301](https://github.com/pingcap/tiflow/issues/5301) @[sdojjy](https://github.com/sdojjy) v6.3.0 以降、単一の TiDB クラスターから複数の地理的に分散されたデータ システムへのデータの複製をサポートするために、 [TiCDCは複数のIDCにデプロイできます](/ticdc/deploy-ticdc.md) 。この機能は、地理的に分散されたデータレプリケーションおよび展開トポロジの機能を提供するのに役立ちます。 diff --git a/tidb-cloud/releases/release-notes-2022.md b/tidb-cloud/releases/release-notes-2022.md index 37a399674ef43..d11e11b507a7d 100644 --- a/tidb-cloud/releases/release-notes-2022.md +++ b/tidb-cloud/releases/release-notes-2022.md @@ -173,7 +173,7 @@ summary: 2022年のTiDB Cloudのリリースノートについて説明します - Serverless Tierクラスターには、Dedicated Tierクラスターと同様に完全に機能する HTAP 機能が引き続き含まれています。 - Serverless Tierでは、クラスターの作成時間が短縮され、瞬時にコールドスタートできます。Developer Tierと比較して、作成時間は数分から数秒に短縮されます。 - - デプロイメントトポロジーについて心配する必要はありません。Serverless Tierは、お客様のリクエストに応じて自動的に調整されます。 + - 展開トポロジについて心配する必要はありません。Serverless Tierは、お客様のリクエストに応じて自動的に調整されます。 - Serverless Tier[セキュリティのためにクラスタへのTLS接続を強制する](/tidb-cloud/secure-connections-to-serverless-clusters.md) 。 - 既存のDeveloper Tierクラスターは、今後数か月以内にServerless Tierに自動的に移行されます。クラスターのご利用には影響はなく、ベータ版のServerless Tierクラスターのご利用に対して料金は発生しません。 From 73472b9fd6a799742397e1ca8b7c6366bb8f3c61 Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Fri, 28 Aug 2026 14:41:50 +0900 Subject: [PATCH 3/3] i18n(ja): fix 3 defects found during independent PR review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md: unify デプロイ情報 to デプロイメント情報, matching 4 near-identical sibling pages using the same EN sentence. - production-deployment-using-tiup.md: fix a pre-existing garbled MT artifact (stray デプロイ」のデプロイを fragment) that the mechanical 展開→デプロイ swap left in place, now doubly confusing since it read デプロイ twice back to back. - hardware-and-software-requirements.md: fix a pre-existing mistranslation where EN's capability ("can be deployed") was stated as a completed fact (デプロイされています instead of デプロイできます). --- dm/deploy-a-dm-cluster-using-binary.md | 2 +- hardware-and-software-requirements.md | 2 +- production-deployment-using-tiup.md | 2 +- stale-read.md | 2 +- ...-private-link-connection-to-self-hosted-kafka-in-alicloud.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/dm/deploy-a-dm-cluster-using-binary.md b/dm/deploy-a-dm-cluster-using-binary.md index 4b825a77946a4..a5b2d4b07c5a7 100644 --- a/dm/deploy-a-dm-cluster-using-binary.md +++ b/dm/deploy-a-dm-cluster-using-binary.md @@ -9,7 +9,7 @@ summary: DM バイナリを使用してデータ移行クラスターをデプ > **Note:** > -> 本番環境では、 [TiUPを使用してDMクラスタをデプロイする](/dm/deploy-a-dm-cluster-using-tiup.md)を推奨します。 +> 本番環境では、 [TiUPを使用したDMクラスタのデプロイ](/dm/deploy-a-dm-cluster-using-tiup.md)を推奨します。 ## DMバイナリをダウンロード {#download-dm-binary} diff --git a/hardware-and-software-requirements.md b/hardware-and-software-requirements.md index 86d204ff0a2ae..afdea92898eed 100644 --- a/hardware-and-software-requirements.md +++ b/hardware-and-software-requirements.md @@ -135,7 +135,7 @@ TiDBは、Intel x86-64アーキテクチャの64ビット汎用ハードウェ TiFlashを導入する前に、以下の項目に注意してください。 -- TiFlash は[複数のディスクにデプロイされています](/tiflash/tiflash-configuration.md#multi-disk-deployment)。 +- TiFlash は[複数のディスクにデプロイできます](/tiflash/tiflash-configuration.md#multi-disk-deployment)。 - TiFlashデータディレクトリの最初のディスクとして、TiKVデータのリアルタイムレプリケーションをバッファリングするために、高性能SSDを使用することをお勧めします。このディスクの性能は、PCIe SSDなど、TiKVと同等以上である必要があります。ディスク容量は、総容量の10%以上でなければなりません。そうでない場合、このノードのボトルネックになる可能性があります。他のディスクには通常のSSDを使用することもできますが、より高性能なPCIe SSDを使用すると、パフォーマンスが向上することに注意してください。 - TiFlashはTiKVとは別のノードにデプロイすることをお勧めします。どうしても同じノードにTiFlashとTiKVをデプロイする必要がある場合は、CPUコア数とメモリ容量を増やし、互いに干渉しないようにTiFlashとTiKVを異なるディスクにデプロイするようにしてください。 - TiFlashディスクの総容量は、次のように計算されます: `the data volume of the entire TiKV cluster to be replicated / the number of TiKV replicas * the number of TiFlash replicas` 。たとえば、TiKV の計画容量が 1 TB、TiKV レプリカ数が 3、 TiFlashレプリカ数が 2 の場合、推奨されるTiFlashの総容量は`1024 GB / 3 * 2`です。一部のテーブルのデータのみを複製することもできます。その場合は、複製するテーブルのデータ量に応じてTiFlash の容量を決定します。 diff --git a/production-deployment-using-tiup.md b/production-deployment-using-tiup.md index 8c3b2e5f26d30..94247b47ae900 100644 --- a/production-deployment-using-tiup.md +++ b/production-deployment-using-tiup.md @@ -28,7 +28,7 @@ TiUPを制御マシンにデプロイするには、オンラインデプロイ > **Note:** > -> TiUP環境がオフラインに切り替わった場合は、 [TiUPをオフラインでデプロイ](#deploy-tiup-offline)デプロイ」のデプロイを参照してください。そうしないと、 TiUP が正常に動作しません。 +> TiUP環境がオフラインに切り替わった場合は、デプロイについては[TiUPをオフラインでデプロイ](#deploy-tiup-offline)を参照してください。そうしないと、 TiUP が正常に動作しません。 通常のユーザーアカウントを使用して制御マシンにログインします（例として`tidb`ユーザーを使用します）。その後のTiUPのインストールとクラスタ管理は`tidb`ユーザーが実行できます。 diff --git a/stale-read.md b/stale-read.md index 40ae420aa6d7f..e7e969c999097 100644 --- a/stale-read.md +++ b/stale-read.md @@ -15,7 +15,7 @@ summary: ステイル読み取りとその使用シナリオについて学習 - シナリオ 1: トランザクションが読み取り操作のみを伴い、ある程度のデータの古さが許容される場合は、 ステイル読み取りを使用して履歴データを取得できます。 ステイル読み取りを使用すると、TiDB はリアルタイム パフォーマンスをある程度犠牲にしてクエリ要求を任意のレプリカに送信するため、クエリ実行のスループットが向上します。特に、小さなテーブルをクエリするシナリオでは、強力な一貫性のある読み取りを使用すると、リーダーが特定のストレージノードに集中し、クエリの負荷もそのノードに集中する可能性があります。そのため、そのノードがクエリ全体のボトルネックになる可能性があります。しかし、 ステイル読み取り を使用すると、クエリ全体のスループットが向上し、クエリのパフォーマンスが大幅に向上します。 -- シナリオ 2: 地理的に分散したデプロイメントの一部のシナリオでは、フォロワーから読み取ったデータがLeaderに保存されているデータと整合していることを確認するために、強力な整合性を持つフォロワー読み取りを使用する場合、TiDB は検証のために異なるデータセンターに`Readindex`要求します。これにより、クエリプロセス全体のアクセスレイテンシーが増加します。ステイル読み取りを使用すると、TiDB は現在のデータセンターのレプリカにアクセスして対応するデータを読み取りますが、リアルタイムパフォーマンスが多少犠牲になります。これにより、センター間接続によるネットワークレイテンシーが回避され、クエリ全体のアクセスレイテンシーが短縮されます。詳細については、 [3つのデータセンターデプロイにおけるローカル読み取りのベストプラクティス](/best-practices/three-dc-local-read.md)を参照してください。 +- シナリオ 2: 地理的に分散したデプロイメントの一部のシナリオでは、フォロワーから読み取ったデータがLeaderに保存されているデータと整合していることを確認するために、強力な整合性を持つフォロワー読み取りを使用する場合、TiDB は検証のために異なるデータセンターに`Readindex`を要求します。これにより、クエリプロセス全体のアクセスレイテンシーが増加します。ステイル読み取りを使用すると、TiDB は現在のデータセンターのレプリカにアクセスして対応するデータを読み取りますが、リアルタイムパフォーマンスが多少犠牲になります。これにより、センター間接続によるネットワークレイテンシーが回避され、クエリ全体のアクセスレイテンシーが短縮されます。詳細については、 [3つのデータセンターデプロイにおけるローカル読み取りのベストプラクティス](/best-practices/three-dc-local-read.md)を参照してください。 diff --git a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md index f8beb85b490b1..e7d15ff3bdf94 100644 --- a/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md +++ b/tidb-cloud/serverless-private-link-connection-to-self-hosted-kafka-in-alicloud.md @@ -46,7 +46,7 @@ Alibaba Cloud アカウント ID とアベイラビリティーゾーンを表 2. **Alibaba Cloud Private Endpoints for External Services**領域で、**Create Private Endpoint for External Services**をクリックします。 3. 表示されたダイアログで、Alibaba Cloud アカウント ID とアベイラビリティーゾーンを見つけることができます。 -次の表は、デプロイ情報の例を示しています。 +次の表は、デプロイメント情報の例を示しています。 | 情報 | 値 | 注記 | | ------------------------------ | --------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |