i18n(ja): restore text dropped by the translation pipeline (part 2)

ai/reference/vector-search-data-types.md

@@ -212,7 +212,7 @@ Vector と String 間のキャストを行うには、次の関数を使用し
 1 row in set (0.01 sec)
 ```
 
-ベクトルを明示的に文字列表現にキャストすることもできます。1関数`VEC_AS_TEXT()`例に挙げましょう。
+ベクトルを明示的に文字列表現にキャストすることもできます。`VEC_AS_TEXT()`関数の使用を例に挙げましょう。
 
 ```sql
 -- The string is first implicitly cast to a vector, and then the vector is explicitly cast to a string, thus returning a string in the normalized format:

alert-rules.md

@@ -467,7 +467,7 @@ summary: TiDB クラスターのアラート ルールについて学習しま
 
     1.  ネットワークがクリアかどうかを確認してください。
     2.  リモート TiKV がダウンしていないかどうかを確認します。
-    3.  リモートTiKVがダウンしていない場合は、圧力が高すぎないか確認してください。1の解決策を参照してください[`TiKV_channel_full_total`](#tikv_channel_full_total)
+    3.  リモートTiKVがダウンしていない場合は、圧力が高すぎないか確認してください。[`TiKV_channel_full_total`](#tikv_channel_full_total)の解決策を参照してください。
 
 #### `TiKV_channel_full_total` {#tikv-channel-full-total}
 

analyze-slow-queries.md

@@ -59,7 +59,7 @@ summary: スロークエリを見つけて分析する方法を学びます。
 
 ### TiKVはデータ処理が遅い {#tikv-is-slow-in-data-processing}
 
-TiKVによるデータ処理が遅い場合、 `EXPLAIN ANALYZE`の結果から簡単に特定できます。次の例では、 `StreamAgg_8`と`TableFullScan_15` 、つまり2つの`tikv-task`秒（ `task`列の`cop[tikv]`で示される）の実行に`170ms`かかります。15 `170ms`差し引くと、TiDB演算子の実行時間は全体の実行時間に占める割合が非常に小さくなります。これは、ボトルネックがTiKVにあることを示しています。
+TiKVによるデータ処理が遅い場合、 `EXPLAIN ANALYZE`の結果から簡単に特定できます。次の例では、 `StreamAgg_8`と`TableFullScan_15` 、つまり2つの`tikv-task`秒（ `task`列の`cop[tikv]`で示される）の実行に`170ms`かかります。`170ms`を差し引くと、TiDB演算子の実行時間は全体の実行時間に占める割合が非常に小さくなります。これは、ボトルネックがTiKVにあることを示しています。
 
 ```sql
 +----------------------------+---------+---------+-----------+---------------+------------------------------------------------------------------------------+---------------------------------+-----------+------+

auto-increment.md

@@ -94,7 +94,7 @@ TiDB は`AUTO_INCREMENT`暗黙的な割り当てを次のように実装しま
 CREATE TABLE t(id int UNIQUE KEY AUTO_INCREMENT, c int);
 ```
 
-クラスター内に2つのTiDBインスタンス（ `A`と`B`があるとします。7テーブルに対してそれぞれ`t`と`B` `A` `INSERT`ステートメントを実行すると、次のようになります。
+クラスター内に2つのTiDBインスタンス（ `A`と`B` ）があるとします。`A`と`B`でそれぞれ`t`テーブルに対して`INSERT`ステートメントを実行すると、次のようになります。
 
 ```sql
 INSERT INTO t (c) VALUES (1)

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

@@ -10,7 +10,7 @@ aliases: ['/ja/docs/dev/best-practices/grafana-monitor-best-practices/','/ja/doc
 
 ## 監視アーキテクチャ {#monitoring-architecture}
 
-[Prometheus](https://prometheus.io/)は、多次元データ モデルと柔軟なクエリ言語を備えた時系列データベースです。2 [Grafana](https://grafana.com/) 、メトリックを分析および視覚化するためのオープン ソースの監視システムです。
+[Prometheus](https://prometheus.io/)は、多次元データ モデルと柔軟なクエリ言語を備えた時系列データベースです。[Grafana](https://grafana.com/)は、メトリックを分析および視覚化するためのオープン ソースの監視システムです。
 
 ![The monitoring architecture in the TiDB cluster](/media/prometheus-in-tidb.png)
 

best-practices/massive-regions-best-practices.md

@@ -102,7 +102,7 @@ TiKVでは、デフォルトで`raftstore.store-pool-size`から`2`に設定さ
 -   [`max-merge-region-keys`](/pd-configuration-file.md#max-merge-region-keys)
 -   [`merge-schedule-limit`](/pd-configuration-file.md#merge-schedule-limit)
 
-`Region Merge`パラメータのデフォルト設定はかなり保守的です。5 [PDスケジュールのベストプラクティス](/best-practices/pd-scheduling-best-practices.md#region-merge-is-slow)記載されている方法を参考にすれば、 `Region Merge`プロセスを高速化できます。
+`Region Merge`パラメータのデフォルト設定はかなり保守的です。[PDスケジュールのベストプラクティス](/best-practices/pd-scheduling-best-practices.md#region-merge-is-slow)に記載されている方法を参考にすれば、 `Region Merge`プロセスを高速化できます。
 
 ### 方法4: TiKVインスタンスの数を増やす {#method-4-increase-the-number-of-tikv-instances}
 

best-practices/multi-column-index-best-practices.md

@@ -223,8 +223,8 @@ CREATE TABLE t1 (
 
     TiDBオプティマイザは条件を分解した後、各部分の範囲を計算し、それらを結合します。この例では、次のように導出されます。
 
-    -   `(a1, b1) > (1, 10)`場合: `a1 > 1`の場合は 3 、 `a1 = 1`および`b1 > 10`の場合は`(1, +inf]` `(1, 10, 1, +inf]`の範囲を作成します。
-    -   `(a1, b1) < (10, 20)`の場合: `a1 < 10`と`[10, -inf, 10, 20)`の場合は範囲`[-inf, 10)`を作成し、 `a1 = 10`と`b1 < 20`の場合は範囲​​ 7 を作成します。
+    -   `(a1, b1) > (1, 10)`の場合: `a1 > 1`の場合は範囲`(1, +inf]`を作成し、 `a1 = 1`および`b1 > 10`の場合は`(1, 10, 1, +inf]`を作成します。
+    -   `(a1, b1) < (10, 20)`の場合: `a1 < 10`の場合は範囲`[-inf, 10)`を作成し、 `a1 = 10`と`b1 < 20`の場合は範囲`[10, -inf, 10, 20)`を作成します。
 
     最終結果では、これらを組み合わせて、洗練された範囲`(1, 10, 1, +inf] UNION (1, 10) UNION [10, -inf, 10, 20)`得られます。
 

best-practices/pd-scheduling-best-practices.md

@@ -74,7 +74,7 @@ aliases: ['/ja/docs/dev/best-practices/pd-scheduling-best-practices/','/ja/docs/
 -   ストレージが不足している場合は、使用可能なストレージに基づいて割り当てます (異なるノード上のストレージの可用性のバランスをとるため)。
 -   どちらの状況も当てはまらない場合は、上記の 2 つの要素の加重合計に基づきます。
 
-ノードによってパフォーマンスが異なる場合があるため、ストアごとにロードバランシングの重みを設定することもできます。1と`region-weight` `leader-weight`それぞれリーダー重みとリージョン重みを制御します（どちらもデフォルトは「1」です）。例えば、あるストアの`leader-weight` 「2」に設定すると、スケジューリングが安定した後、そのノードのリーダー数は他のノードの約2倍になります。同様に、あるストアの`leader-weight` 「0.5」に設定すると、そのノードのリーダー数は他のノードの約半分になります。
+ノードによってパフォーマンスが異なる場合があるため、ストアごとにロードバランシングの重みを設定することもできます。`leader-weight`と`region-weight`は、それぞれリーダー重みとリージョン重みを制御します（どちらもデフォルトは「1」です）。例えば、あるストアの`leader-weight`を「2」に設定すると、スケジューリングが安定した後、そのノードのリーダー数は他のノードの約2倍になります。同様に、あるストアの`leader-weight`を「0.5」に設定すると、そのノードのリーダー数は他のノードの約半分になります。
 
 ### ホットリージョンのスケジュール {#hot-regions-scheduling}
 
@@ -293,7 +293,7 @@ TiKV ノードに障害が発生した場合、PD はデフォルトで、対応
 
 実用的には、ノード障害が回復不可能と判断された場合、直ちにオフラインにすることができます。これにより、PDはすぐに別のノードにレプリカを補充し、データ損失のリスクを軽減します。一方、ノードが回復可能と判断されたものの、30分以内に回復できない場合は、タイムアウト後にレプリカの不必要な補充とリソースの浪費を回避するために、一時的に`max-store-down-time`大きく調整することができます。
 
-TiDB v5.2.0以降、TiKVは低速ディスクノードを検出するメカニズムを導入しました。このメカニズムは、TiKV内のリクエストをサンプリングすることで、1から100までのスコアを算出します。スコアが80以上のTiKVノードは低速としてマークされます。1 [`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe)加算することで、低速ノードをスケジュールできます。低速と検出されたTiKVノードが1つだけで、その低速スコアが上限（デフォルトでは80）に達した場合、そのノードのリーダーは排除されます（ `evict-leader-scheduler`加算した場合と同様の効果）。
+TiDB v5.2.0以降、TiKVは低速ディスクノードを検出するメカニズムを導入しました。このメカニズムは、TiKV内のリクエストをサンプリングすることで、1から100までのスコアを算出します。スコアが80以上のTiKVノードは低速としてマークされます。[`evict-slow-store-scheduler`](/pd-control.md#scheduler-show--add--remove--pause--resume--config--describe)を追加することで、低速ノードをスケジュールできます。低速と検出されたTiKVノードが1つだけで、その低速スコアが上限（デフォルトでは80）に達した場合、そのノードのリーダーは排除されます（ `evict-leader-scheduler`加算した場合と同様の効果）。
 
 v8.5.5以降、TiKVは低速ネットワークノードを検出するメカニズムを導入しました。低速ディスクノード検出と同様に、このメカニズムはTiKVノード間のネットワークレイテンシーをプローブし、スコアを計算することで低速ノードを特定します。このメカニズムを有効にするには[`enable-network-slow-store`](/pd-control.md#scheduler-config-evict-slow-store-scheduler)指定します（デフォルトでは無効）。
 

best-practices/three-nodes-hybrid-deployment.md

@@ -123,4 +123,4 @@ tiup ctl:v<CLUSTER_VERSION> tikv --host=${ip:port} modify-tikv-config -n gc.max_
 
 このパラメータは、Goプロセス全体で使用できるCPUコアの数を制御するために使用されます。デフォルトでは、この値は現在のマシンまたはcgroupのCPUコア数と同じです。
 
-Goの実行中、GCなどのバックグラウンドタスクには一定量のスレッドが使用されます。1パラメータの値を制限しないと、これらのバックグラウンドタスク`performance.max-procs` CPUを過剰に消費することになります。
+Goの実行中、GCなどのバックグラウンドタスクには一定量のスレッドが使用されます。`performance.max-procs`パラメータの値を制限しないと、これらのバックグラウンドタスクがCPUを過剰に消費することになります。

blocklist-control-plan.md

@@ -96,10 +96,10 @@ DESC mysql.expr_pushdown_blacklist;
 上記の各フィールドの説明は次のとおりです。
 
 -   `name` : プッシュダウンが無効になっている関数の名前。
--   `store_type` : 関数の計算時にプッシュダウンされないようにするコンポーネントを指定します。指定できる要素は`tidb` 、 `tikv` 、 `tiflash`です。8 `store_type`大文字と小文字を区別しません。複数の要素を指定する必要がある場合は、各コンポーネントをカンマで区切ってください。
-    -   `store_type`が`tidb`場合、TiDBメモリテーブルの読み取り中に他の TiDB サーバーで関数を実行できるかどうかを示します。
-    -   `store_type`が`tikv`場合、関数が TiKV サーバーのコプロセッサーコンポーネントで実行できるかどうかを示します。
-    -   `store_type`が`tiflash`場合、関数がTiFlash Server のコプロセッサーコンポーネントで実行できるかどうかを示します。
+-   `store_type` : 関数の計算時にプッシュダウンされないようにするコンポーネントを指定します。指定できる要素は`tidb` 、 `tikv` 、 `tiflash`です。`store_type`大文字と小文字を区別しません。複数の要素を指定する必要がある場合は、各コンポーネントをカンマで区切ってください。
+    -   `store_type`が`tidb`の場合、TiDBメモリテーブルの読み取り中に他の TiDB サーバーで関数を実行できるかどうかを示します。
+    -   `store_type`が`tikv`の場合、関数が TiKV サーバーのコプロセッサーコンポーネントで実行できるかどうかを示します。
+    -   `store_type`が`tiflash`の場合、関数がTiFlash Server のコプロセッサーコンポーネントで実行できるかどうかを示します。
 -   `reason` : この関数がブロックリストに追加された理由を記録します。
 
 ### 使用法 {#usage}

br/br-checkpoint-restore.md

@@ -69,7 +69,7 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた
 
 > **注記：**
 >
-> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。1パラメータを使用して`--checkpoint-storage`チェックポイントデータのストレージを指定できます。
+> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。`--checkpoint-storage`パラメータを使用して、チェックポイントデータのストレージを指定できます。
 
 チェックポイント復元操作は、スナップショット復元と PITR 復元の 2 つの部分に分かれています。
 
@@ -99,7 +99,7 @@ MVCC (Multi-Version Concurrency Control) メカニズムを使用しているた
 
 > **注記：**
 >
-> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。1パラメータを使用して`--checkpoint-storage`チェックポイントデータの外部ストレージを指定できます。例：
+> v8.5.5以降、 BRはデフォルトでチェックポイントデータをダウンストリームクラスターに保存します。`--checkpoint-storage`パラメータを使用して、チェックポイントデータの外部ストレージを指定できます。例：
 >
 > ```shell
 > ./br restore full -s "s3://backup-bucket/backup-prefix" --checkpoint-storage "s3://temp-bucket/checkpoints"

br/br-pitr-manual.md

@@ -94,7 +94,7 @@ BR を使用すると、ログ バックアップ データをバックアップ
 
 TiDB v8.4.0 以降では、ログ バックアップ コマンドで次のパラメータ ( [スナップショットバックアップの暗号化](/br/br-snapshot-manual.md#encrypt-the-backup-data)に類似) を渡すことで、ログ バックアップ データを暗号化できます。
 
--   `--log.crypter.method` : 暗号化アルゴリズム。2、4、6 `aes192-ctr` `aes128-ctr`かになります。デフォルト値は`aes256-ctr` `plaintext` 、データは暗号化されません。
+-   `--log.crypter.method` : 暗号化アルゴリズム。`aes128-ctr` 、 `aes192-ctr` 、または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。
 -   `--log.crypter.key` : 16進文字列形式の暗号化キー。アルゴリズム`aes128-ctr`の場合は128ビット（16バイト）、アルゴリズム`aes192-ctr`の場合は24バイト、アルゴリズム`aes256-ctr`の場合は32バイトのキーです。
 -   `--log.crypter.key-file` : キーファイル。2 `crypter.key`渡さずに、キーが保存されているファイルパスをパラメータとして直接渡すこともできます。
 
@@ -111,7 +111,7 @@ tiup br log start \
 
 ただし、セキュリティ要件が高いシナリオでは、固定の暗号化キーをコマンドラインで直接渡すことは望ましくない場合があります。セキュリティをさらに強化するには、マスターキーベースの暗号化システムを使用して暗号化キーを管理できます。このシステムは、ログバックアップファイルごとに異なるデータキーを生成し、マスターキーのローテーションをサポートします。以下のパラメータを使用して設定できます。
 
--   `--master-key-crypter-method` : マスターキーに基づく暗号化アルゴリズム。2、4 `aes192-ctr`または`aes256-ctr` `aes128-ctr`かになります。デフォルト値は`plaintext`で、データは暗号化されません。
+-   `--master-key-crypter-method` : マスターキーに基づく暗号化アルゴリズム。`aes128-ctr` 、 `aes192-ctr`または`aes256-ctr`のいずれかになります。デフォルト値は`plaintext`で、データは暗号化されません。
 -   `--master-key` ：マスターキーの設定。ローカルディスクに保存されたマスターキー、またはクラウドキー管理サービス（KMS）によって管理されたマスターキーを使用できます。
 
 ローカル ディスクに保存されているマスター キーを使用して暗号化します。