i18n(ja): fix version-requirement corruption and mistranslations in tidb-lightning

tidb-lightning/data-import-best-practices.md

@@ -39,7 +39,7 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni
 - 表の定義
 
     - テーブルごとのセカンダリインデックスの数とサイズは、インポート速度に影響を与える可能性があります。インデックスの数が少ないほど、インポートが高速化し、インポート後のスペース消費も少なくなります。
-    - インデックスデータサイズ = インデックスの数 *インデックス サイズ* 行数。
+    - インデックスデータサイズ = インデックスの数 \* インデックスサイズ \* 行数。
 
 - 圧縮比
 
@@ -130,13 +130,13 @@ TiDB Lightningパラメータの詳細については、 [TiDB Lightning設定
 
 ### クラスタトポロジを計画する {#plan-cluster-topology}
 
-TiDB Lightningインスタンスを準備し、各インスタンスが5TiB～10TiBのソースデータを処理できるようにします。各ノードに1つのTiDB Lightningインスタンスをデプロイ。ノードの仕様については、 TiDB Lightningインスタンスの[環境要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)を参照してください。
+TiDB Lightningインスタンスを準備し、各インスタンスが5TiB～10TiBのソースデータを処理できるようにします。各ノードに1つのTiDB Lightningインスタンスをデプロイします。ノードの仕様については、 TiDB Lightningインスタンスの[環境要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)を参照してください。
 
 ### 設定パラメータを変更する {#change-configuration-parameters}
 
-- TiDB Lightningインスタンスのコア数の`region-concurrency` ～ 75% を設定します。
+- `region-concurrency`をTiDB Lightningインスタンスのコア数の75%に設定します。
 - `send-kv-pairs`を`3200`に設定します。この方法はTiDB v7.1.0以前のバージョンに適用されます。v7.2.0以降では、このパラメータは`send-kv-size`に置き換えられ、追加の設定は不要です。
-- インスタンスが配置されているノード上のメモリを`GOMEMLIMIT` ～ 80% に調整します。
+- `GOMEMLIMIT`をインスタンスが配置されているノード上のメモリの80%に調整します。
 
 インポートプロセス中の PD 散布リージョンのレイテンシーが30分を超える場合は、次の最適化を検討してください。
 

tidb-lightning/import-into-vs-tidb-lightning.md

@@ -23,7 +23,7 @@ summary: IMPORT INTO` とTiDB Lightningの違いについて説明します。
 
 #### TiDB Lightning {#tidb-lightning}
 
-対照的に、 TiDB Lightning[個別のサーバーデプロイ](/tidb-lightning/deploy-tidb-lightning.md)が必要です。
+対照的に、 TiDB Lightningには[個別のサーバーデプロイ](/tidb-lightning/deploy-tidb-lightning.md)が必要です。
 
 ### リソースの活用 {#resource-utilization}
 
@@ -43,11 +43,11 @@ TiDB Lightning をデプロイして実行するには、別々のサーバー
 
 #### `IMPORT INTO` {#import-into}
 
-You can directly write SQL statements to submit import tasks, which are easy to call and integrate.
+SQL文を直接記述してインポートタスクを送信でき、呼び出しと統合が容易です。
 
 #### TiDB Lightning {#tidb-lightning}
 
-対照的に、 TiDB Lightning[タスク設定ファイル](/tidb-lightning/tidb-lightning-configuration.md)を記述する必要があります。これらの設定ファイルは複雑であり、サードパーティが簡単に呼び出すことはできません。
+対照的に、 TiDB Lightningでは[タスク設定ファイル](/tidb-lightning/tidb-lightning-configuration.md)を記述する必要があります。これらの設定ファイルは複雑であり、サードパーティが簡単に呼び出すことはできません。
 
 ### タスクのスケジュール {#task-scheduling}
 
@@ -104,7 +104,7 @@ TiDB Lightningインスタンス ノードに障害が発生した場合、以
 
 #### `IMPORT INTO` {#import-into}
 
-Due to the use of Global Sort, data imported into TiKV does not overlap, resulting in better scalability compared with TiDB Lightning.
+Global Sortを使用しているため、TiKVにインポートされるデータが重複せず、TiDB Lightningと比較してスケーラビリティが向上します。
 
 #### TiDB Lightning {#tidb-lightning}
 

tidb-lightning/monitor-tidb-lightning.md

@@ -5,7 +5,7 @@ summary: TiDB Lightningのモニター構成と監視メトリックについて
 
 # TiDB Lightning監視 {#tidb-lightning-monitoring}
 
-`tidb-lightning` [Prometheus](https://prometheus.io/)を介してメトリクス収集をサポートします。このドキュメントでは、 TiDB Lightningの監視設定と監視メトリクスについて説明します。
+`tidb-lightning`は[Prometheus](https://prometheus.io/)を介してメトリクス収集をサポートします。このドキュメントでは、 TiDB Lightningの監視設定と監視メトリクスについて説明します。
 
 ## モニター構成 {#monitor-configuration}
 
@@ -33,7 +33,7 @@ scrape_configs:
 
 ## Grafanaダッシュボード {#grafana-dashboard}
 
-[Grafana](https://grafana.com/) 、Prometheus メトリックをダッシュボードとして視覚化するための Web インターフェースです。
+[Grafana](https://grafana.com/)は、Prometheus メトリックをダッシュボードとして視覚化するための Web インターフェースです。
 
 ### 1行目: スピード {#row-1-speed}
 
@@ -43,7 +43,7 @@ scrape_configs:
 | :-------- | :------------------- | :---------------------------------------------------------------- |
 | インポート速度   | TiDB Lightningから書き込む | TiDB Lightningから TiKV Importer への KV の送信速度。これは各テーブルの複雑さによって異なります。 |
 | インポート速度   | TIKVにアップロード          | TiKVインポーターからすべてのTiKVレプリカへの合計アップロード速度                              |
-| Chunk処理期間 |                      | Average time needed to completely encode one single data file     |
+| Chunk処理期間 |                      | 1つのデータファイルを完全にエンコードするのにかかる平均時間     |
 
 場合によっては、インポート速度がゼロになり、他のパーツが追いつくまで時間がかかることがあります。これは正常な動作です。
 
@@ -88,7 +88,7 @@ scrape_configs:
 | パネル                  | シリーズ      | 説明                                  |
 | :------------------- | :-------- | :---------------------------------- |
 | Chunkパーサーのブロック読み取り期間 | ブロックを読み込む | 解析の準備のために1ブロックのバイトを読み取るのにかかる時間      |
-| Chunkパーサーのブロック読み取り期間 | 応募者       | アイドル状態のIO同時実行を待つのにかかった時間            |
+| Chunkパーサーのブロック読み取り期間 | apply worker       | アイドル状態のIO同時実行を待つのにかかった時間            |
 | SQLプロセスの実行時間         | 行エンコード    | 1行の解析とエンコードにかかる時間                   |
 | SQLプロセスの実行時間         | ブロック配信    | KV ペアのブロックを TiKV インポーターに送信するのにかかる時間 |
 
@@ -202,7 +202,7 @@ scrape_configs:
 
 - **`lightning_import_seconds`** （ヒストグラム）
 
-    Bucketed histogram for the time needed to import a table.
+    テーブルのインポートに必要な時間のバケット化されたヒストグラム。
 
 - **`lightning_row_read_bytes`** （ヒストグラム）
 

tidb-lightning/tidb-lightning-checkpoints.md

@@ -67,7 +67,7 @@ tidb-lightning-ctl --checkpoint-error-destroy='`schema`.`table`'
 
 このオプションを使用すると、テーブルのインポートを最初からやり直すことができます。スキーマ名とテーブル名はバッククォートで囲む必要があり、大文字と小文字が区別されます。
 
-- 以前にテーブル`` `schema`.`table` ``インポートに失敗した場合、このオプションは次の操作を実行します。
+- 以前にテーブル`` `schema`.`table` ``のインポートに失敗した場合、このオプションは次の操作を実行します。
 
     1. ターゲットデータベースからテーブル`` `schema`.`table` ``を削除します。つまり、インポートされたすべてのデータが削除されます。
     2. このテーブルのチェックポイント レコードを"not yet started"状態にリセットします。
@@ -87,7 +87,7 @@ tidb-lightning-ctl --checkpoint-error-ignore='`schema`.`table`'
 tidb-lightning-ctl --checkpoint-error-ignore=all
 ```
 
-テーブル`` `schema`.`table` ``インポートが以前に失敗していた場合、これによりエラーステータスがクリアされ、何も起こらなかったかのようになります。バリアント`all`では、この操作がすべてのテーブルに適用されます。
+テーブル`` `schema`.`table` ``のインポートが以前に失敗していた場合、これによりエラーステータスがクリアされ、何も起こらなかったかのようになります。バリアント`all`では、この操作がすべてのテーブルに適用されます。
 
 > **Note:**
 >

tidb-lightning/tidb-lightning-configuration.md

@@ -112,7 +112,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設
 - TiDB Lightningはインポート完了後にこのスキーマを削除します。そのため、このパラメータを設定する際に既存のスキーマ名を使用しないでください。
 - デフォルト値: `"lightning_metadata"`
 
-### 安全 {#security}
+### security {#security}
 
 `security`セクションでは、クラスター内の TLS 接続の証明書とキーを指定します。
 
@@ -173,7 +173,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設
 
 <!-- Example: `false` -->
 
-### 対立 {#conflict}
+### conflict {#conflict}
 
 #### `strategy` {#strategy}
 
@@ -215,7 +215,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設
 - 論理インポートモードでは、戦略が`"ignore"`の場合、無視される競合レコードが記録され、戦略が`"replace"`の場合、競合レコードは記録されません。
 - デフォルト値: `10000`
 
-### tikvインポーター {#tikv-importer}
+### tikv-importer {#tikv-importer}
 
 #### `backend` {#backend}
 
@@ -294,7 +294,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設
 - このメカニズムは、過去のバージョンと一貫性があります。SQLを使用してインデックスを追加する利点は、データのインポートとインデックスのインポートを個別に実行できるため、データのインポートが高速化されることです。データのインポート後、インデックスの追加に失敗しても、インポートされたデータの整合性には影響しません。
 - デフォルト値: `false`
 - 値のオプション:
-    - `false` : TiDB Lightningデータとインデックスデータの両方を KV ペアにエンコードし、一緒に TiKV にインポートします。
+    - `false` : TiDB Lightningは行データとインデックスデータの両方を KV ペアにエンコードし、一緒に TiKV にインポートします。
     - `true` : TiDB Lightning は、行データをインポートした後、 `ADD INDEX` SQL文を介してインデックスを追加します。
 
 #### `keyspace-name` {#keyspace-name}
@@ -363,7 +363,7 @@ TiDB Lightningには「グローバル」と「タスク」という2つの設
 
 #### `batch-import-ratio` {#batch-import-ratio}
 
-- エンジンファイルは順番にインポートする必要があります。並列処理のため、複数のデータエンジンがほぼ同時にインポートされ、キューが生成されてリソースが浪費されます。そのため、 TiDB Lightning、リソースを適切に配分するために、最初の数バッチのサイズをわずかに大きくしています。
+- エンジンファイルは順番にインポートする必要があります。並列処理のため、複数のデータエンジンがほぼ同時にインポートされ、キューが生成されてリソースが浪費されます。そのため、 TiDB Lightningは、リソースを適切に配分するために、最初の数バッチのサイズをわずかに大きくしています。
 - スケールアップ係数はこのパラメータによって制御されます。このパラメータは、完全な同時実行における"import"ステップと"write"ステップの所要時間の比率を表します。これは、約1GiBの単一テーブルにおける比率（インポート所要時間/書き込み所要時間）を使用して計算できます。正確な時間はログで確認できます。
 - "import"の方が高速であれば、バッチサイズの分散は小さくなり、比率が 0 であればバッチサイズは均一になります。
 - 範囲: `[0, 1)`
@@ -509,7 +509,7 @@ CSV ファイルの解析方法を構成します。
 
 - 例: `'$3'`
 
-### ティッド {#tidb}
+### tidb {#tidb}
 
 #### `host` {#host}
 
@@ -660,7 +660,7 @@ CSV ファイルの解析方法を構成します。
 - デフォルト値: `"optional"`
 - 値のオプション: `"required"` 、 `"optional"` 、 `"off"`
 
-### クローン {#cron}
+### cron {#cron}
 
 - バックグラウンドでの定期的なアクションを設定します。
 - サポートされる単位: h (時間)、m (分)、s (秒)。

tidb-lightning/tidb-lightning-data-source.md

@@ -50,9 +50,9 @@ rename srcdb. tgtdb. *.sql
 以下は、正規表現を使用してオンラインで名前を置換する例です。この例では、
 
 - データファイル`pattern`の一致ルールは`^({schema_regrex})\.({table_regrex})\.({file_serial_regrex})\.(csv|parquet|sql)`です。
-- `schema`を`'$1'`と指定すると、最初の正規表現の値`schema_regrex`は変更されません。または、 `schema` `'tgtdb'`などの文字列として指定すると、固定のターゲットデータベース名になります。
-- `table`を`'$2'`と指定すると、2番目の正規表現の値`table_regrex`は変更されません。または、 `table` `'t1'`などの文字列として指定すると、固定のターゲットテーブル名になります。
-- `type`を`'$3'` （データファイルの種類）として指定します。`type` `"table-schema"` （ `schema.sql`ファイル）または`"schema-schema"` （ `schema-create.sql`ファイル）として指定できます。
+- `schema`を`'$1'`と指定すると、最初の正規表現の値`schema_regrex`は変更されません。または、 `schema`を`'tgtdb'`などの文字列として指定すると、固定のターゲットデータベース名になります。
+- `table`を`'$2'`と指定すると、2番目の正規表現の値`table_regrex`は変更されません。または、 `table`を`'t1'`などの文字列として指定すると、固定のターゲットテーブル名になります。
+- `type`を`'$3'` （データファイルの種類）として指定します。`type`は`"table-schema"` （ `schema.sql`ファイル）または`"schema-schema"` （ `schema-create.sql`ファイル）として指定できます。
 
 ```toml
 [mydumper]
@@ -73,7 +73,7 @@ table = '$2'
 type = '$3'
 ```
 
-`gzip`を使用してデータファイルをバックアップする場合は、それに応じて圧縮形式を設定する必要があります。データファイル`pattern`のマッチングルールは`'^({schema_regrex})\.({table_regrex})\.({file_serial_regrex})\.(csv|parquet|sql)\.(gz)'`です。圧縮ファイル形式を表すために、 `compression` `'$4'`として指定できます。例：
+`gzip`を使用してデータファイルをバックアップする場合は、それに応じて圧縮形式を設定する必要があります。データファイル`pattern`のマッチングルールは`'^({schema_regrex})\.({table_regrex})\.({file_serial_regrex})\.(csv|parquet|sql)\.(gz)'`です。圧縮ファイル形式を表すために、 `compression`を`'$4'`として指定できます。例：
 
 ```toml
 [mydumper]
@@ -219,7 +219,7 @@ trim-last-separator = false
 
 #### `trim-last-separator` {#trim-last-separator}
 
-- `separator`行末文字として扱い、すべての末尾の区切り文字を削除するかどうか。
+- `separator`を行末文字として扱い、すべての末尾の区切り文字を削除するかどうか。
 
     たとえば、次の CSV ファイルでは、
 
@@ -404,7 +404,7 @@ type = '$3'
     - インポートするテーブルの名前（例： `table1` ）。一致したすべてのファイルは`table1`にインポートされます。
 - **type** : ファイルの種類。`sql` 、`parquet` 、`csv`をサポートします。値は次のとおりです。
     - 正規表現を使用して取得されたグループ インデックス (例: `$3` )。
-- **key** : ファイル番号 (例: `${db_name}.${table_name}.001.csv`の場合は`001` 。
+- **key** : ファイル番号（例：`${db_name}.${table_name}.001.csv`の`001`）。
     - 正規表現を使用して取得されたグループ インデックス (例: `$4` )。
 
 ## Amazon S3からデータをインポートする {#import-data-from-amazon-s3}