From 8222889dd793055e9a4e52fbe6f662f445362dbe Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 15 Sep 2026 14:18:20 +0900 Subject: [PATCH 1/2] i18n(ja): fix version-requirement corruption and mistranslations in tidb-lightning Co-Authored-By: Claude Sonnet 5 --- tidb-lightning/data-import-best-practices.md | 8 ++++---- .../import-into-vs-tidb-lightning.md | 8 ++++---- tidb-lightning/monitor-tidb-lightning.md | 10 +++++----- tidb-lightning/tidb-lightning-checkpoints.md | 4 ++-- tidb-lightning/tidb-lightning-configuration.md | 14 +++++++------- tidb-lightning/tidb-lightning-data-source.md | 12 ++++++------ .../tidb-lightning-error-resolution.md | 8 ++++---- tidb-lightning/tidb-lightning-faq.md | 2 +- tidb-lightning/tidb-lightning-glossary.md | 10 +++++----- ...tidb-lightning-logical-import-mode-usage.md | 2 +- .../tidb-lightning-logical-import-mode.md | 2 +- tidb-lightning/tidb-lightning-overview.md | 2 +- ...idb-lightning-physical-import-mode-usage.md | 18 +++++++++--------- .../tidb-lightning-physical-import-mode.md | 2 +- tidb-lightning/tidb-lightning-prechecks.md | 18 +++++++++--------- tidb-lightning/tidb-lightning-web-interface.md | 4 ++-- tidb-lightning/troubleshoot-tidb-lightning.md | 8 ++++---- 17 files changed, 66 insertions(+), 66 deletions(-) diff --git a/tidb-lightning/data-import-best-practices.md b/tidb-lightning/data-import-best-practices.md index 2a15dca4d7dc0..f8bdd5091f40d 100644 --- a/tidb-lightning/data-import-best-practices.md +++ b/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分を超える場合は、次の最適化を検討してください。 diff --git a/tidb-lightning/import-into-vs-tidb-lightning.md b/tidb-lightning/import-into-vs-tidb-lightning.md index a6f58facb8dae..a13430a4d346d 100644 --- a/tidb-lightning/import-into-vs-tidb-lightning.md +++ b/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} diff --git a/tidb-lightning/monitor-tidb-lightning.md b/tidb-lightning/monitor-tidb-lightning.md index 14699f2f1b0ac..71f24ce300729 100644 --- a/tidb-lightning/monitor-tidb-lightning.md +++ b/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`** （ヒストグラム） diff --git a/tidb-lightning/tidb-lightning-checkpoints.md b/tidb-lightning/tidb-lightning-checkpoints.md index 83f4c9b0474c4..40da8897fb4ef 100644 --- a/tidb-lightning/tidb-lightning-checkpoints.md +++ b/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:** > diff --git a/tidb-lightning/tidb-lightning-configuration.md b/tidb-lightning/tidb-lightning-configuration.md index 9be7b0b92b966..6212e91cbcc2d 100644 --- a/tidb-lightning/tidb-lightning-configuration.md +++ b/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つの設 -### 対立 {#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 (秒)。 diff --git a/tidb-lightning/tidb-lightning-data-source.md b/tidb-lightning/tidb-lightning-data-source.md index 7392b2cc46ed5..4d67ab2ef3091 100644 --- a/tidb-lightning/tidb-lightning-data-source.md +++ b/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} diff --git a/tidb-lightning/tidb-lightning-error-resolution.md b/tidb-lightning/tidb-lightning-error-resolution.md index 1a7a04628b7d6..9ea2e5fe87e5a 100644 --- a/tidb-lightning/tidb-lightning-error-resolution.md +++ b/tidb-lightning/tidb-lightning-error-resolution.md @@ -10,13 +10,13 @@ v5.4.0以降、 TiDB Lightningを設定して、無効な型変換や一意キ このドキュメントでは、TiDB Lightning のエラーの種類、エラーのクエリ方法、および例を紹介します。以下の設定項目が関係します。 - `lightning.max-error` : 型エラーの許容閾値 -- `conflict.strategy` : 競合`conflict.max-record-rows` `conflict.threshold`に関連する構成 +- `conflict.strategy`、 `conflict.threshold`、および`conflict.max-record-rows`: 競合するデータに関連する設定 - `tikv-importer.duplicate-resolution` (v8.0.0 で非推奨となり、将来のリリースで削除される予定): 物理インポートモードでのみ使用できる競合処理構成 - `lightning.task-info-schema-name` : TiDB Lightningが競合を検出したときに競合するデータが格納されるデータベース 詳細については[TiDB Lightning （タスク）](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を参照してください。 -## 入力エラー {#type-error} +## 型エラー {#type-error} `lightning.max-error`設定を使用すると、データ型に関連するエラーの許容範囲を広げることができます。この設定を*N*に設定すると、 TiDB Lightning はデータソースから最大*N*個のエラーを許容し、データソースが存在する前にスキップします。デフォルト値の`0`は、エラーが許容されないことを意味します。 @@ -57,7 +57,7 @@ TiDB Lightning がインポート中にエラーに遭遇した場合、終了 | | エラーの種類 | エラー数 | エラーデータテーブル | | - | ------ | ---- | ------------------------------------- | - | 1 | データ型 | 1000 | `lightning_task_info` `type_error_v1` | + | 1 | データ型 | 1000 | `lightning_task_info`.`type_error_v1` | - TiDB Lightningログファイル内のエラーレポートは次のとおりです。 @@ -130,7 +130,7 @@ CREATE VIEW conflict_view AS `conflict_view`ビューは、インポート前とインポート後の競合検出の両方で検出された競合を記録します。これらの競合は、論理インポートモードと物理インポートモードの両方で`conflict`設定グループによって管理されます。このビューは、 `conflict_error_v3`テーブルと`conflict_records`テーブルに対して`UNION`操作を実行することで作成されます。 -| カラム | 構文 | タイプ | 対立 | 説明 | +| カラム | 構文 | タイプ | 競合 | 説明 | | ------- | -- | --- | -- | --------------------------------------------------------------------------- | | task_id | ✓ | ✓ | ✓ | このエラーを生成するTiDB Lightningタスク ID | | create_time | ✓ | ✓ | ✓ | エラーが記録された時刻 | diff --git a/tidb-lightning/tidb-lightning-faq.md b/tidb-lightning/tidb-lightning-faq.md index a8fc59cc8bd85..6c95d4bf284e6 100644 --- a/tidb-lightning/tidb-lightning-faq.md +++ b/tidb-lightning/tidb-lightning-faq.md @@ -9,7 +9,7 @@ summary: TiDB Lightningに関するよくある質問 (FAQ) と回答につい ## TiDB Lightningでサポートされる最小の TiDB/TiKV/PD クラスター バージョンは何ですか? {#what-is-the-minimum-tidbtikvpd-cluster-version-supported-by-tidb-lightning} -TiDB Lightningのバージョンはクラスターと同じである必要があります。Local-backendモードを使用する場合、利用可能な最新バージョンは4.0.0です。Importer-backendモードまたはTiDB-backendモードを使用する場合、利用可能な最新バージョンは2.0.9ですが、安定版の3.0を使用することをお勧めします。 +TiDB Lightningのバージョンはクラスターと同じである必要があります。Local-backendモードを使用する場合、利用可能な最も古いバージョンは4.0.0です。Importer-backendモードまたはTiDB-backendモードを使用する場合、利用可能な最も古いバージョンは2.0.9ですが、安定版の3.0を使用することをお勧めします。 ## TiDB Lightning は複数のスキーマ (データベース) のインポートをサポートしていますか? {#does-tidb-lightning-support-importing-multiple-schemas-databases} diff --git a/tidb-lightning/tidb-lightning-glossary.md b/tidb-lightning/tidb-lightning-glossary.md index 060beffabc0c6..2853d3d1399dc 100644 --- a/tidb-lightning/tidb-lightning-glossary.md +++ b/tidb-lightning/tidb-lightning-glossary.md @@ -11,7 +11,7 @@ TiDB 関連の用語と定義については、 [TiDB用語集](/glossary.md)を -## あ {#a} +## A {#a} ### 分析する {#analyze} @@ -109,13 +109,13 @@ TiDB Lightningは、エンジンを介してTiKV Importerにデータを転送 -## 私 {#i} +## I {#i} ### インポートモード {#import-mode} 読み取り速度とスペース使用量を犠牲にして、書き込み用に TiKV を最適化する構成。 -TiDB Lightningは実行中に自動的にインポートモードを切り替えます。ただし、TiKVがインポートモードで停止した場合は、 `tidb-lightning-ctl` ～ [強制的に元に戻す](/tidb-lightning/troubleshoot-tidb-lightning.md#the-tidb-cluster-uses-lots-of-cpu-resources-and-runs-very-slowly-after-using-tidb-lightning) ～ [通常モード](/tidb-lightning/tidb-lightning-glossary.md#normal-mode)を使用してください。 +TiDB Lightningは実行中に自動的にインポートモードを切り替えます。ただし、TiKVがインポートモードで停止した場合は、 `tidb-lightning-ctl`を使用して[通常モード](/tidb-lightning/tidb-lightning-glossary.md#normal-mode)に[強制的に元に戻して](/tidb-lightning/troubleshoot-tidb-lightning.md#the-tidb-cluster-uses-lots-of-cpu-resources-and-runs-very-slowly-after-using-tidb-lightning)ください。 ### インデックスエンジン {#index-engine} @@ -155,7 +155,7 @@ KV ペアを TiKV Importer に送信する前に、 TiDB Lightning自体によ -## 北 {#n} +## N {#n} ### 通常モード {#normal-mode} @@ -167,7 +167,7 @@ KV ペアを TiKV Importer に送信する前に、 TiDB Lightning自体によ ### 後処理 {#post-processing} -データソース全体が解析され、TiKV Importer に送信された後の期間。TiDB Lightning はTiKV Importer のアップロードを待機し、 [SST ファイル](/tidb-lightning/tidb-lightning-glossary.md#sst-file)を[取り込み](/tidb-lightning/tidb-lightning-glossary.md#ingest) 。 +データソース全体が解析され、TiKV Importer に送信された後の期間。TiDB Lightning は、TiKV Importer が[SST ファイル](/tidb-lightning/tidb-lightning-glossary.md#sst-file)をアップロードして[取り込む](/tidb-lightning/tidb-lightning-glossary.md#ingest)のを待機します。 diff --git a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md index df8058788c576..b1670884d35b2 100644 --- a/tidb-lightning/tidb-lightning-logical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-logical-import-mode-usage.md @@ -58,7 +58,7 @@ log-level = "error" 戦略が`"error"`の場合、競合するデータによって発生したエラーはインポートタスクを直接終了させます。戦略が`"replace"`または`"ignore"`の場合、 [`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を設定することで許容される競合の最大数を制御できます。デフォルト値は`10000`で、これは 10000件のエラーが許容されることを意味します。 -戦略が`"ignore"`の場合、競合するデータは下流の`conflict_records`テーブルに記録されます。詳細については、 [エラーレポート](/tidb-lightning/tidb-lightning-error-resolution.md#error-report)を参照してください。v8.1.0 より前は、 [`conflict.max-record-rows`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を設定することでレコードを制限でき、制限を超える競合データはスキップされ、記録されません。v8.1.0 以降は、TiDB Lightning が[`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)入力に関係なく`max-record-rows`の値に`threshold`の値を自動的に割り当てるため、代わりにTiDB Lightning を設定する必要があります。 +戦略が`"ignore"`の場合、競合するデータは下流の`conflict_records`テーブルに記録されます。詳細については、 [エラーレポート](/tidb-lightning/tidb-lightning-error-resolution.md#error-report)を参照してください。v8.1.0 より前は、 [`conflict.max-record-rows`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を設定することでレコードを制限でき、制限を超える競合データはスキップされ、記録されません。v8.1.0 以降は、代わりに[`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)を設定する必要があります。これは、ユーザーの入力に関係なく、TiDB Lightning が自動的に`max-record-rows`の値に`threshold`の値を割り当てるためです。 ## パフォーマンスチューニング {#performance-tuning} diff --git a/tidb-lightning/tidb-lightning-logical-import-mode.md b/tidb-lightning/tidb-lightning-logical-import-mode.md index 8da87d8b92190..17c9b152bfae0 100644 --- a/tidb-lightning/tidb-lightning-logical-import-mode.md +++ b/tidb-lightning/tidb-lightning-logical-import-mode.md @@ -19,7 +19,7 @@ CentOS 7の新規インスタンスの使用をお勧めします。仮想マシ **メモリとCPU** : -パフォーマンスを向上させるには、CPUコア数を4以上、メモリを8GiB以上割り当てることをお勧めします。TiDB Lightningは、論理インポートモードではメモリ使用量が5GiB以下と、それほど大きくないことが検証されています。ただし、値を`region-concurrency`に増やすと、 TiDB Lightningのメモリ消費量が増加する可能性があります。 +パフォーマンスを向上させるには、CPUコア数を4以上、メモリを8GiB以上割り当てることをお勧めします。TiDB Lightningは、論理インポートモードではメモリ使用量が5GiB以下と、それほど大きくないことが検証されています。ただし、 `region-concurrency`の値を増やすと、 TiDB Lightningのメモリ消費量が増加する可能性があります。 **ネットワーク**: 1 Gbps または 10 Gbps のイーサネット カードが推奨されます。 diff --git a/tidb-lightning/tidb-lightning-overview.md b/tidb-lightning/tidb-lightning-overview.md index bf0d893f0e186..f292f7ceba9fa 100644 --- a/tidb-lightning/tidb-lightning-overview.md +++ b/tidb-lightning/tidb-lightning-overview.md @@ -41,7 +41,7 @@ TiDB Lightning は、 `backend`で設定された 2つのインポートモー | ネットワーク帯域幅の消費 | 高い | 低い | | インポート時のACID準拠 | いいえ | はい | | ターゲットテーブル | 空でなければなりません | データを含むことができる | -| TiDB クラスタバージョン | = 4.0.0 | 全て | +| TiDB クラスタバージョン | >= 4.0.0 | 全て | | TiDBクラスタがインポート中にサービスを提供できるかどうか | [限定サービス](/tidb-lightning/tidb-lightning-physical-import-mode.md#limitations) | はい | diff --git a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md index 25808355a6388..230779a4124c4 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode-usage.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode-usage.md @@ -7,7 +7,7 @@ summary: TiDB Lightningの物理インポートモードの使い方を学びま このドキュメントでは、 TiDB Lightningの[物理インポートモード](/tidb-lightning/tidb-lightning-physical-import-mode.md)の使用方法について説明します。具体的には、設定ファイルの作成、パフォーマンスのチューニング、ディスククォータの設定などが含まれます。 -物理インポートモードには制限があります。物理インポートモードを使用する前に、 [制限事項](/tidb-lightning/tidb-lightning-physical-import-mode.md#limitations)必ずお読みください。 +物理インポートモードには制限があります。物理インポートモードを使用する前に、 [制限事項](/tidb-lightning/tidb-lightning-physical-import-mode.md#limitations)を必ずお読みください。 ## 物理インポートモードを設定して使用する {#configure-and-use-the-physical-import-mode} @@ -124,7 +124,7 @@ analyze = "optional" > > TiDB Lightningの内部実装と制限により、物理インポートモードでの競合検出結果は、SQLベースのインポート結果と異なる場合があります。 -戦略が`"error"`で競合データが検出された場合、 TiDB Lightning はエラーを報告してインポートを終了します。戦略が`"replace"`の場合、競合データは[競合エラー](/tidb-lightning/tidb-lightning-error-resolution.md#conflict-errors)として扱われます。conflict.threshold [`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)値が`0`より大きい場合、 TiDB Lightning は指定された数の競合エラーを許容します。デフォルト値は`9223372036854775807`で、これはほぼすべてのエラーが許容されることを意味します。詳細については、を参照してください。 [エラー解決](/tidb-lightning/tidb-lightning-error-resolution.md)。 +戦略が`"error"`で競合データが検出された場合、 TiDB Lightning はエラーを報告してインポートを終了します。戦略が`"replace"`の場合、競合データは[競合エラー](/tidb-lightning/tidb-lightning-error-resolution.md#conflict-errors)として扱われます。 [`conflict.threshold`](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)の値が`0`より大きい場合、 TiDB Lightning は指定された数の競合エラーを許容します。デフォルト値は`9223372036854775807`で、これはほぼすべてのエラーが許容されることを意味します。詳細については、 [エラー解決](/tidb-lightning/tidb-lightning-error-resolution.md)を参照してください。 新しいバージョンの競合検出機能には、以下の制限事項があります。 @@ -135,15 +135,15 @@ analyze = "optional" ### 旧バージョンの競合検出機能（v8.0.0で非推奨） {#the-old-version-of-conflict-detection-deprecated-in-v800} -バージョン 8.0.0 以降、競合検出の旧バージョン ( `tikv-importer.duplicate-resolution` ) は非推奨となります。 `tikv-importer.duplicate-resolution`パラメータは今後のリリースで削除されます。 `tikv-importer.duplicate-resolution`が`remove`であり、 `conflict.strategy`が設定されていない場合、 TiDB Lightning は`conflict.strategy`の値`"replace"` 。 `tikv-importer.duplicate-resolution`と`conflict.strategy`は同時に設定できません。同時に設定するとエラーが発生しますのでご注意ください。 +バージョン 8.0.0 以降、競合検出の旧バージョン ( `tikv-importer.duplicate-resolution` ) は非推奨となります。 `tikv-importer.duplicate-resolution`パラメータは今後のリリースで削除されます。 `tikv-importer.duplicate-resolution`が`remove`であり、 `conflict.strategy`が設定されていない場合、 TiDB Lightning は自動的に`conflict.strategy`の値を`"replace"`に割り当てることで、新しいバージョンの競合検出を有効にします。 `tikv-importer.duplicate-resolution`と`conflict.strategy`は同時に設定できません。同時に設定するとエラーが発生しますのでご注意ください。 -- バージョン v7.3.0 から v7.6.0 の間では、 `tikv-importer.duplicate-resolution`空文字列でない場合、 TiDB Lightning は古いバージョンの競合検出を有効にします。 +- バージョン v7.3.0 から v7.6.0 の間では、 `tikv-importer.duplicate-resolution`が空文字列でない場合、 TiDB Lightning は古いバージョンの競合検出を有効にします。 - TiDB Lightningは、v7.2.0以前のバージョンでは、古いバージョンの競合検出のみをサポートしています。 旧バージョンの競合検出では、 TiDB Lightningは2つの戦略を提供していました。 - `remove` (推奨): ターゲット TiDB の一貫した状態を確保するために、ターゲットテーブルから競合するすべてのレコードを記録して削除します。 -- `none` : 重複レコードを検出しません。 `none` 2つの戦略の中で最も優れたパフォーマンスを発揮しますが、ターゲット TiDB のデータに不整合が生じる可能性があります。 +- `none` : 重複レコードを検出しません。 `none`は2つの戦略の中で最も優れたパフォーマンスを発揮しますが、ターゲット TiDB のデータに不整合が生じる可能性があります。 バージョン5.3より前のTiDB Lightningは、競合検出をサポートしていません。競合データが存在する場合、インポート処理はチェックサムの段階で失敗します。競合検出が有効になっている場合、競合データが存在すると、 TiDB Lightningはチェックサムの段階をスキップします（常に失敗するため）。 @@ -264,7 +264,7 @@ io-concurrency = 5 インポート処理中、各テーブルはインデックスを格納するための「インデックスエンジン」1つと、行データを格納するための複数の「データエンジン」に分割されます。 -`index-concurrency`インデックスエンジンの最大同時実行数を制御します。 `index-concurrency`を調整する際は、CPU が最大限に活用されるように`index-concurrency * the number of source files of each table > region-concurrency`も必ず調整してください。比率は通常 1.5 ～ 2 です。 `index-concurrency`を高く設定しすぎたり、2 (デフォルト値) より低く設定したりしないでください。 `index-concurrency`高すぎると、パイプラインが多数構築され、インデックスエンジンのインポートステージが滞留します。 +`index-concurrency`はインデックスエンジンの最大同時実行数を制御します。 `index-concurrency`を調整する際は、CPU が最大限に活用されるように`index-concurrency * the number of source files of each table > region-concurrency`も必ず調整してください。比率は通常 1.5 ～ 2 です。 `index-concurrency`を高く設定しすぎたり、2 (デフォルト値) より低く設定したりしないでください。 `index-concurrency`が高すぎると、パイプラインが多数構築され、インデックスエンジンのインポートステージが滞留します。 `table-concurrency`についても同様です。 `table-concurrency * the number of source files of each table > region-concurrency`がCPUをフル活用していることを確認してください。推奨値は`region-concurrency * 4 / the number of source files of each table`前後で、4を下回らないようにしてください。 @@ -272,11 +272,11 @@ io-concurrency = 5 `index-concurrency`と`table-concurrency`はインポート速度にほとんど影響を与えません。デフォルト値のままで問題ありません。 -`io-concurrency`ファイル読み取りの同時実行数を制御します。デフォルト値は 5 です。常に 5つのハンドルのみが読み取り操作を実行します。ファイル読み取り速度は通常ボトルネックにならないため、この設定はデフォルト値のままにしておくことができます。 +`io-concurrency`はファイル読み取りの同時実行数を制御します。デフォルト値は 5 です。常に 5つのハンドルのみが読み取り操作を実行します。ファイル読み取り速度は通常ボトルネックにならないため、この設定はデフォルト値のままにしておくことができます。 ファイルデータが読み込まれた後、Lightning はデータのエンコードやローカルでのソートなどの後処理を行う必要があります。これらの操作の同時実行は`region-concurrency`によって制御されます。デフォルト値は CPU コア数です。この設定はデフォルト値のままにしておくことができます。Lightning は他のコンポーネントとは別のサーバーにデプロイすることをお勧めします。Lightning を他のコンポーネントと一緒にデプロイする必要がある場合は、負荷に応じて`region-concurrency`の値を下げる必要があります。 -TiKV の[`num-threads`](/tikv-configuration-file.md#num-threads)設定もパフォーマンスに影響を与える可能性があります。新しいクラスターの場合は、 `num-threads` CPU コア数に設定することをお勧めします。 +TiKV の[`num-threads`](/tikv-configuration-file.md#num-threads)設定もパフォーマンスに影響を与える可能性があります。新しいクラスターの場合は、 `num-threads`をCPU コア数に設定することをお勧めします。 ## ディスククォータの設定（v6.2.0の新機能） {#configure-disk-quota-new-in-v620} @@ -297,6 +297,6 @@ backend = "local" check-disk-quota = "30s" ``` -`disk-quota` TiDB Lightningが使用するストレージ容量を制限します。デフォルト値は MaxInt64 で、9223372036854775807 バイトです。この値はインポートに必要なディスク容量よりもはるかに大きいため、デフォルト値のままにしておくことは、ディスククォータを設定しないことと同じです。 +`disk-quota`はTiDB Lightningが使用するストレージ容量を制限します。デフォルト値は MaxInt64 で、9223372036854775807 バイトです。この値はインポートに必要なディスク容量よりもはるかに大きいため、デフォルト値のままにしておくことは、ディスククォータを設定しないことと同じです。 `check-disk-quota`は、ディスククォータをチェックする間隔です。デフォルト値は 60秒です。TiDB Lightning がディスククォータをチェックすると、関連データに対して排他ロックを取得し、すべてのインポートスレッドをブロックします。そのため、 TiDB Lightning が書き込みの前に毎回ディスククォータをチェックすると、書き込み効率が大幅に低下します (シングルスレッド書き込みと同じくらい遅くなります)。効率的な書き込みを実現するために、ディスククォータは書き込みの前に毎回チェックされません。代わりに、 TiDB Lightning はすべてのインポートスレッドを一時停止し、 `check-disk-quota`間隔ごとにディスククォータをチェックします。つまり、 `check-disk-quota`の値を大きな値に設定すると、 TiDB Lightningが使用するディスク領域が設定したディスククォータを超える可能性があり、ディスククォータが無効になります。したがって、 `check-disk-quota`の値は小さい値に設定することをお勧めします。この項目の具体的な値は、 TiDB Lightningが実行される環境によって決まります。TiDB Lightning は、環境によって一時ファイルの書き込み速度が異なります。理論的には、書き込み速度が速いほど、 `check-disk-quota`の値は小さくする必要があります。 diff --git a/tidb-lightning/tidb-lightning-physical-import-mode.md b/tidb-lightning/tidb-lightning-physical-import-mode.md index 03f1ff29e62d1..93adeecfa1cba 100644 --- a/tidb-lightning/tidb-lightning-physical-import-mode.md +++ b/tidb-lightning/tidb-lightning-physical-import-mode.md @@ -37,7 +37,7 @@ backend = "local" エンジンファイルには、**データエンジン**と**インデックスエンジン**という2種類のエンジンが含まれています。各エンジンは、キーと値のペアの種類（行データとセカンダリインデックス）に対応しています。通常、行データはデータソース内で完全に順序付けされており、セカンダリインデックスは順序付けされていません。そのため、データエンジンファイルは対応するブロックが書き込まれた直後にインポートされ、すべてのインデックスエンジンファイルはテーブル全体がエンコードされた後にのみインポートされます。 - `tidb-lightning` SQL インターフェイス経由でインデックスを追加する場合 (つまり、 `add-index-by-sql`を`true`に設定する場合)、ターゲットテーブルのセカンダリインデックスは手順 2 で既に削除されているため、インデックスエンジンはデータを書き込まないことに注意してください。 + `tidb-lightning`が SQL インターフェイス経由でインデックスを追加する場合 (つまり、 `add-index-by-sql`を`true`に設定する場合)、ターゲットテーブルのセカンダリインデックスは手順 2 で既に削除されているため、インデックスエンジンはデータを書き込まないことに注意してください。 6. すべてのエンジンファイルがインポートされた後、 TiDB Lightningはローカルデータソースと下流クラスターのチェックサムを比較し、インポートされたデータが破損していないことを確認します。その後、 TiDB Lightningはステップ2で削除したセカンダリインデックスを追加するか、TiDBに新しいデータを分析させて（ `ANALYZE` ）、将来の操作を最適化します。一方、 `tidb-lightning`は将来の競合を防ぐために`AUTO_INCREMENT`値を調整します。 diff --git a/tidb-lightning/tidb-lightning-prechecks.md b/tidb-lightning/tidb-lightning-prechecks.md index 11cd2f42ca261..8faef0407dda1 100644 --- a/tidb-lightning/tidb-lightning-prechecks.md +++ b/tidb-lightning/tidb-lightning-prechecks.md @@ -11,12 +11,12 @@ TiDB 5.3.0以降、 TiDB Lightningは移行タスク実行前に設定をチェ | チェック項目 | サポートされているバージョン | 説明 | | ---------------------------------------------- | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| クラスタのバージョンとステータス | = 5.3.0 | 構成でクラスターを接続できるかどうか、および TiKV/PD/ TiFlashバージョンが物理インポートモードをサポートしているかどうかを確認します。 | -| 権限 | = 5.3.0 | データソースがクラウドストレージ(Amazon S3) の場合、 TiDB Lightning に必要な権限があるかどうかを確認し、権限不足のためにインポートが失敗しないことを確認します。 | -| ディスク容量 | = 5.3.0 | ローカルディスクとTiKVクラスターに、データのインポートに十分な空き容量があるかどうかを確認します。TiDB Lightningはデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。物理インポートモードでは、外部ソートをローカルで実行する必要があるため、TiDB Lightningはローカルストレージが十分かどうかも確認します。TiKVクラスターの空き容量とローカルストレージのストレージ容量 ( `sort-kv-dir`で制御) の詳細については、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)と[リソース要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)を参照してください。 | -| リージョン配信状況 | = 5.3.0 | TiKVクラスタ内のリージョンが均等に分散されているか、また空のリージョンが多すぎないかを確認してください。空のリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 | -| データファイル内の非常に大きなCSVファイル | = 5.3.0 | バックアップファイルに10GiBを超えるCSVファイルがあり、自動スライスが有効になっていない場合（StrictFormat=false）、インポートのパフォーマンスに影響します。このチェックは、データが正しい形式であること、および自動スライスが有効になっていることを確認するためのものです。 | -| ブレークポイントからの回復 | = 5.3.0 | このチェックにより、ブレークポイント回復プロセス中に、間違ったデータがインポートされるような変更がデータベースのソースファイルまたはスキーマに加えられないことが保証されます。 | -| 既存のテーブルにインポートする | = 5.3.0 | 既に作成されたテーブルにインポートする場合、ソースファイルが既存のテーブルと可能な限り一致するかどうかを確認します。列数が一致しているかどうかを確認します。ソースファイルに列名がある場合は、列名が一致しているかどうかを確認します。ソースファイルにデフォルトの列がある場合は、その列にデフォルト値が設定されているかどうかを確認し、設定されている場合はチェックに合格します。 | -| 対象テーブルが空かどうか | = 5.3.1 | ターゲットテーブルが空でない場合、 TiDB Lightningは自動的にエラーを出力して終了します。並列インポートモードが有効（ `parallel-import = true` ）になっている場合、このチェック項目はスキップされます。 | -| PITRが有効になっているか、またはクラスター内で変更フィードタスクが実行されているかどうか | = 6.5.0 | TiDB Lightning の物理インポートモードは、PITR および changefeed と互換性がありません。PITR が有効になっているか、changefeed タスクが実行中の場合、 TiDB Lightning は自動的にエラーを出力して終了します。インポートするテーブルでレプリケーションに PITR または changefeed が不要であることが確実な場合は、このチェックをスキップしてTiDB Lightning の物理インポートモードを続行できます。 | +| クラスタのバージョンとステータス | >= 5.3.0 | 構成でクラスターを接続できるかどうか、および TiKV/PD/ TiFlashバージョンが物理インポートモードをサポートしているかどうかを確認します。 | +| 権限 | >= 5.3.0 | データソースがクラウドストレージ(Amazon S3) の場合、 TiDB Lightning に必要な権限があるかどうかを確認し、権限不足のためにインポートが失敗しないことを確認します。 | +| ディスク容量 | >= 5.3.0 | ローカルディスクとTiKVクラスターに、データのインポートに十分な空き容量があるかどうかを確認します。TiDB Lightningはデータソースをサンプリングし、サンプル結果からインデックスサイズの割合を推定します。推定にはインデックスも含まれるため、ソースデータのサイズがローカルディスクの空き容量よりも小さい場合でも、チェックが失敗する場合があります。物理インポートモードでは、外部ソートをローカルで実行する必要があるため、TiDB Lightningはローカルストレージが十分かどうかも確認します。TiKVクラスターの空き容量とローカルストレージのストレージ容量 ( `sort-kv-dir`で制御) の詳細については、 [ターゲットデータベースのストレージ要件](/tidb-lightning/tidb-lightning-requirements.md#storage-space-of-the-target-database)と[リソース要件](/tidb-lightning/tidb-lightning-physical-import-mode.md#environment-requirements)を参照してください。 | +| リージョン配信状況 | >= 5.3.0 | TiKVクラスタ内のリージョンが均等に分散されているか、また空のリージョンが多すぎないかを確認してください。空のリージョンの数がmax(1000, テーブル数 * 3)を超える場合、つまり「1000」または「テーブル数の3倍」のいずれか大きい方を超える場合、インポートは実行できません。 | +| データファイル内の非常に大きなCSVファイル | >= 5.3.0 | バックアップファイルに10GiBを超えるCSVファイルがあり、自動スライスが有効になっていない場合（StrictFormat=false）、インポートのパフォーマンスに影響します。このチェックは、データが正しい形式であること、および自動スライスが有効になっていることを確認するためのものです。 | +| ブレークポイントからの回復 | >= 5.3.0 | このチェックにより、ブレークポイント回復プロセス中に、間違ったデータがインポートされるような変更がデータベースのソースファイルまたはスキーマに加えられないことが保証されます。 | +| 既存のテーブルにインポートする | >= 5.3.0 | 既に作成されたテーブルにインポートする場合、ソースファイルが既存のテーブルと可能な限り一致するかどうかを確認します。列数が一致しているかどうかを確認します。ソースファイルに列名がある場合は、列名が一致しているかどうかを確認します。ソースファイルにデフォルトの列がある場合は、その列にデフォルト値が設定されているかどうかを確認し、設定されている場合はチェックに合格します。 | +| 対象テーブルが空かどうか | >= 5.3.1 | ターゲットテーブルが空でない場合、 TiDB Lightningは自動的にエラーを出力して終了します。並列インポートモードが有効（ `parallel-import = true` ）になっている場合、このチェック項目はスキップされます。 | +| PITRが有効になっているか、またはクラスター内で変更フィードタスクが実行されているかどうか | >= 6.5.0 | TiDB Lightning の物理インポートモードは、PITR および changefeed と互換性がありません。PITR が有効になっているか、changefeed タスクが実行中の場合、 TiDB Lightning は自動的にエラーを出力して終了します。インポートするテーブルでレプリケーションに PITR または changefeed が不要であることが確実な場合は、このチェックをスキップしてTiDB Lightning の物理インポートモードを続行できます。 | diff --git a/tidb-lightning/tidb-lightning-web-interface.md b/tidb-lightning/tidb-lightning-web-interface.md index af3ea64f847a5..bcad87da628bb 100644 --- a/tidb-lightning/tidb-lightning-web-interface.md +++ b/tidb-lightning/tidb-lightning-web-interface.md @@ -48,7 +48,7 @@ TiDB Lightningを起動したら、 `http://127.0.0.1:8289`にアクセスして タイトルバーの機能（左から右へ）： -| アイコン | 関数 | +| アイコン | 機能 | | :------------- | :---------------------------------------------------------------- | | TiDB Lightning | クリックしてトップページに戻る | | ⚠ | *前の*タスクからのエラーメッセージを表示する | @@ -71,7 +71,7 @@ TiDB Lightningを起動したら、 `http://127.0.0.1:8289`にアクセスして ![Submit task dialog](/media/lightning-web-submit.png) -タスクは[タスク構成](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)として記述される TOML ファイルです。 **[アップロード]**をクリックしてローカル TOML ファイルを開くこともできます。 +タスクは[タスク構成](/tidb-lightning/tidb-lightning-configuration.md#tidb-lightning-task)として記述される TOML ファイルです。 **UPLOAD**をクリックしてローカル TOML ファイルを開くこともできます。 タスクを実行するには、 **SUBMIT**をクリックしてください。既にタスクが実行中の場合は、新しいタスクはキューに追加され、現在のタスクが正常に完了した後に実行されます。 diff --git a/tidb-lightning/troubleshoot-tidb-lightning.md b/tidb-lightning/troubleshoot-tidb-lightning.md index 42fa6b2a586d7..a4a1113bd969d 100644 --- a/tidb-lightning/troubleshoot-tidb-lightning.md +++ b/tidb-lightning/troubleshoot-tidb-lightning.md @@ -52,7 +52,7 @@ strict-format = true ## TiDB クラスターは多くの CPU リソースを消費し、 TiDB Lightningを使用すると非常に遅くなります。 {#the-tidb-cluster-uses-lots-of-cpu-resources-and-runs-very-slowly-after-using-tidb-lightning} -`tidb-lightning`異常終了した場合、クラスターは本番には適さない"import mode"で停止している可能性があります。現在のモードは次のコマンドで取得できます。 +`tidb-lightning`が異常終了した場合、クラスターは本番には適さない"import mode"で停止している可能性があります。現在のモードは次のコマンドで取得できます。 ```sh tidb-lightning-ctl --config tidb-lightning.toml --fetch-mode @@ -120,7 +120,7 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= 1. ファイル全体が UTF-8 または GB-18030 になるようにスキーマを修正します。 -2. ターゲットデータベース内の影響を受けるテーブルを手動で`CREATE` 。 +2. ターゲットデータベース内の影響を受けるテーブルを手動で`CREATE`してください。 3. `[mydumper] character-set = "binary"`を設定するとチェックをスキップします。ただし、これにより対象データベースに文字化けが発生する可能性があります。 @@ -154,7 +154,7 @@ tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-error-destroy= ### TiDB Lightningがモードを切り替えるときに、 `rpc error: code = Unimplemented ...` {#encounter-rpc-error-code--unimplemented--when-tidb-lightning-switches-the-mode} -**原因**: クラスタ内の一部のノードが`switch-mode`サポートしていません。例えば、 TiFlash のバージョンが`v4.0.0-rc.2` 、 [`switch-mode`はサポートされていません](https://github.com/pingcap/tidb-lightning/issues/273)より前の場合などです。 +**原因**: クラスタ内の一部のノードが`switch-mode`をサポートしていません。例えば、 TiFlash のバージョンが`v4.0.0-rc.2`より前の場合、 [`switch-mode`はサポートされていません](https://github.com/pingcap/tidb-lightning/issues/273)。 **ソリューション**： @@ -182,7 +182,7 @@ TiDBはMySQLのすべての文字セットをサポートしているわけで ### `invalid compression type ...` {#invalid-compression-type-} -- TiDB Lightning v6.4.0以降のバージョンでは、 `gzip` `snappy`圧縮データファイルのみがサポートされています。その他の種類の圧縮ファイルを使用するとエラーが発生します。ソースデータファイルが保存されているディレクトリにサポートされていない圧縮ファイルが存在する場合、タスクがエラーを報告します。このようなエラーを回避するには、サポートされていないファイルをインポートデータディレクトリから移動してください。詳細については、 [圧縮ファイル](/tidb-lightning/tidb-lightning-data-source.md#compressed-files)を参照してください。 +- TiDB Lightning v6.4.0以降のバージョンでは、 `gzip` 、 `snappy` 、および`zstd`圧縮データファイルのみがサポートされています。その他の種類の圧縮ファイルを使用するとエラーが発生します。ソースデータファイルが保存されているディレクトリにサポートされていない圧縮ファイルが存在する場合、タスクがエラーを報告します。このようなエラーを回避するには、サポートされていないファイルをインポートデータディレクトリから移動してください。詳細については、 [圧縮ファイル](/tidb-lightning/tidb-lightning-data-source.md#compressed-files)を参照してください。 > **Note:** > From 11a17319f0f5ebdceddd2bf1a50ed5fee83757db Mon Sep 17 00:00:00 2001 From: Yasuo Honda Date: Tue, 15 Sep 2026 14:56:11 +0900 Subject: [PATCH 2/2] i18n(ja): escape asterisks in formula to match EN and avoid markdownlint MD037 Co-Authored-By: Claude Sonnet 5 --- tidb-lightning/data-import-best-practices.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tidb-lightning/data-import-best-practices.md b/tidb-lightning/data-import-best-practices.md index f8bdd5091f40d..8e53da9a0038a 100644 --- a/tidb-lightning/data-import-best-practices.md +++ b/tidb-lightning/data-import-best-practices.md @@ -39,7 +39,7 @@ TiDB Lightning （ [物理インポートモード](/tidb-lightning/tidb-lightni - 表の定義 - テーブルごとのセカンダリインデックスの数とサイズは、インポート速度に影響を与える可能性があります。インデックスの数が少ないほど、インポートが高速化し、インポート後のスペース消費も少なくなります。 - - インデックスデータサイズ = インデックスの数 * インデックスサイズ * 行数。 + - インデックスデータサイズ = インデックスの数 \* インデックスサイズ \* 行数。 - 圧縮比