i18n(ja): fix mistranslations and dropped particles across the best-practices/ directory

best-practices/best-practices-on-public-cloud.md

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

best-practices/ddl-introduction.md

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

best-practices/grafana-monitor-best-practices.md

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