TiDB LightningFAQ
このドキュメントには、 TiDB Lightningに関するよくある質問 (FAQ) と回答が記載されています。
TiDB Lightningでサポートされている TiDB/TiKV/PD クラスタの最小バージョンは何ですか?
TiDB Lightningのバージョンは、クラスターと同じである必要があります。 Local-backend モードを使用する場合、利用可能な最も古いバージョンは 4.0.0 です。 Importer-backend モードまたは TiDB-backend モードを使用する場合、利用可能な最も古いバージョンは 2.0.9 ですが、3.0 安定バージョンを使用することをお勧めします。
TiDB Lightningは複数のスキーマ (データベース) のインポートをサポートしていますか?
はい。
ターゲット データベースの権限要件は何ですか?
権限の詳細については、 TiDB Lightningを使用するための前提条件を参照してください。
1 つのテーブルをインポートするときに、 TiDB Lightningでエラーが発生しました。他のテーブルに影響しますか?プロセスは終了しますか?
エラーが発生したテーブルが 1 つだけの場合でも、残りは正常に処理されます。
TiDB Lightningを適切に再起動するには?
Importer-backend を使用している場合、 tikv-importer
のステータスに応じて、 TiDB Lightningを再起動する基本的なシーケンスは次のようになります。
tikv-importer
がまだ実行中の場合:
tidb-lightning
停止する .- ソースデータの修正、設定の変更、ハードウェアの交換など、意図した変更を実行します。
- 変更によって以前にいずれかのテーブルが変更された場合は、 対応するチェックポイントを削除しますも変更されます。
tidb-lightning
を開始します。
tikv-importer
を再起動する必要がある場合:
tidb-lightning
停止する .tikv-importer
停止する .- ソースデータの修正、設定の変更、ハードウェアの交換など、意図した変更を実行します。
tikv-importer
を開始します。tidb-lightning
を開始し、プログラムが CHECKSUM エラーで失敗するまで待ちます。tikv-importer
を再起動すると、まだ書き込まれているすべてのエンジン ファイルが破棄されますが、tidb-lightning
はそのことを知りませんでした。 v3.0 の時点で、最も簡単な方法はtidb-lightning
を続けて再試行することです。
- 失敗したテーブルとチェックポイントを破棄する
tidb-lightning
をやり直してください。
Local-backend または TiDB-backend を使用している場合、操作は、 tikv-importer
がまだ実行されているときに Importer-backend を使用する場合と同じです。
インポートされたデータの整合性を確保するにはどうすればよいですか?
デフォルトでは、 TiDB Lightningはローカル データ ソースとインポートされたテーブルでチェックサムを実行します。チェックサムの不一致がある場合、プロセスは中止されます。これらのチェックサム情報は、ログから読み取ることができます。
ターゲット テーブルでADMIN CHECKSUM TABLE
SQL コマンドを実行して、インポートされたデータのチェックサムを再計算することもできます。
ADMIN CHECKSUM TABLE `schema`.`table`;
+---------+------------+---------------------+-----------+-------------+
| Db_name | Table_name | Checksum_crc64_xor | Total_kvs | Total_bytes |
+---------+------------+---------------------+-----------+-------------+
| schema | table | 5505282386844578743 | 3 | 96 |
+---------+------------+---------------------+-----------+-------------+
1 row in set (0.01 sec)
TiDB Lightningでサポートされているデータ ソース形式は何ですか?
TiDB Lightningは以下をサポートしています。
- Dumpling 、CSV ファイル、およびAmazon Auroraによって生成された Apache Parquet ファイルによってエクスポートされたファイルのインポート。
- ローカル ディスクまたは Amazon S3 ストレージからのデータの読み取り。詳細については、 外部ストレージを参照してください。
TiDB Lightningはスキーマとテーブルの作成をスキップできますか?
v5.1 から、 TiDB Lightningはダウンストリームのスキーマとテーブルを自動的に認識できるようになりました。 v5.1 より前のTiDB Lightningを使用している場合は、 tidb-lightning.toml
の[mydumper]
セクションにno-schema = true
を設定する必要があります。これにより、 TiDB LightningはCREATE TABLE
の呼び出しをスキップし、メタデータをターゲット データベースから直接フェッチします。テーブルが実際に欠落している場合、 TiDB Lightningはエラーで終了します。
厳密な SQL モードを無効にして、無効なデータをインポートできるようにすることはできますか?
はい。デフォルトでは、 TiDB Lightningで使用されるsql_mode
は"STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION"
であり、日付1970-00-00
などの無効なデータは許可されません。モードは、 tidb-lightning.toml
の[tidb]
セクションのsql-mode
の設定を変更することで変更できます。
...
[tidb]
sql-mode = ""
...
1 つのtikv-importer
importer で複数のtidb-lightning
インスタンスを処理できますか?
はい、すべてのインスタンスが異なるテーブルでtidb-lightning
する限り。
tikv-importer
プロセスを停止するには?
tikv-importer
のプロセスを停止するには、展開方法に応じて対応する操作を選択できます。
- 手動デプロイの場合:
tikv-importer
がフォアグラウンドで実行されている場合は、 Ctrl + Cを押して終了します。それ以外の場合は、ps aux | grep tikv-importer
コマンドを使用してプロセス ID を取得し、kill ${PID}
コマンドを使用してプロセスを終了します。
tidb-lightning
プロセスを停止するには?
tidb-lightning
のプロセスを停止するには、展開方法に応じて対応する操作を選択できます。
- 手動デプロイの場合:
tidb-lightning
がフォアグラウンドで実行されている場合は、 Ctrl + Cを押して終了します。それ以外の場合は、ps aux | grep tidb-lightning
コマンドを使用してプロセス ID を取得し、kill -2 ${PID}
コマンドを使用してプロセスを終了します。
TiDB Lightningは 1 ギガビット ネットワーク カードで使用できますか?
TiDB Lightningは、10 ギガビットのネットワーク カードで使用するのが最適です。
1 ギガビット ネットワーク カードは、合計 120 MB/秒の帯域幅しか提供できず、これをすべてのターゲット TiKV ストアで共有する必要があります。 TiDB Lightningは、物理インポート モードで 1 ギガビット ネットワークのすべての帯域幅を簡単に飽和させ、PD に接続できなくなるため、クラスターをダウンさせる可能性があります。
TiDB Lightningが対象の TiKV クラスタに大量の空き容量を必要とするのはなぜですか?
3 つのレプリカのデフォルト設定では、ターゲット TiKV クラスターのスペース要件は、データ ソースのサイズの 6 倍です。次の要因がデータ ソースに反映されていないため、余分な "2" の倍数は保守的な見積もりです。
- インデックスが占めるスペース
- RocksDB での空間増幅
TiDB Lightningの実行中に TiKV Importer を再起動できますか?
いいえ。TiKV Importer は、エンジンの一部の情報をメモリに保存します。 tikv-importer
を再起動すると、 tidb-lightning
は接続が失われたために停止します。この時点で、これらの TiKV Importer 固有の情報が失われるため、 失敗したチェックポイントを破棄するにする必要があります。TiDB Lightningを再起動できます。
正しい順序については、 TiDB Lightningを適切に再起動するには?も参照してください。
TiDB Lightningに関連するすべての中間データを完全に破棄するには?
チェックポイント ファイルを削除します。
tidb-lightning-ctl --config conf/tidb-lightning.toml --checkpoint-remove=all何らかの理由でこのコマンドを実行できない場合は、手動でファイルを削除してみてください
/tmp/tidb_lightning_checkpoint.pb
。Local-backend を使用している場合は、構成で
sorted-kv-dir
のディレクトリを削除します。 Importer-backend を使用している場合は、tikv-importer
をホストしているマシンのimport
ディレクトリ全体を削除します。必要に応じて、TiDB クラスターで作成されたすべてのテーブルとデータベースを削除します。
残りのメタデータをクリーンアップします。次のいずれかの条件が存在する場合は、メタデータ スキーマを手動でクリーンアップする必要があります。
- TiDB Lightning v5.1.x および v5.2.x バージョンの場合、
tidb-lightning-ctl
コマンドはターゲット クラスターのメタデータ スキーマをクリーンアップしません。手動でクリーンアップする必要があります。 - チェックポイント ファイルを手動で削除した場合は、ダウンストリーム メタデータ スキーマを手動でクリーンアップする必要があります。そうしないと、後続のインポートの正確性が影響を受ける可能性があります。
次のコマンドを使用して、メタデータをクリーンアップします。
DROP DATABASE IF EXISTS `lightning_metadata`;- TiDB Lightning v5.1.x および v5.2.x バージョンの場合、
TiDB Lightningの実行時のゴルーチン情報を取得する方法
TiDB Lightningの設定ファイルに
status-port
が指定されている場合は、この手順をスキップしてください。それ以外の場合は、 USR1 シグナルをTiDB Lightningに送信してstatus-port
を有効にする必要があります。ps
などのコマンドを使用してTiDB Lightningのプロセス ID (PID) を取得し、次のコマンドを実行します。kill -USR1 <lightning-pid>TiDB Lightningのログを確認してください。
starting HTTP server
のログは、新しく有効になったstatus-port
を示してstarted HTTP server
start HTTP server
。http://<lightning-ip>:<status-port>/debug/pprof/goroutine?debug=2
にアクセスして、ゴルーチン情報を取得します。
TiDB Lightningが SQL の Placement Rules と互換性がないのはなぜですか?
TiDB LightningはSQL の配置規則と互換性がありません。 TiDB Lightningが配置ポリシーを含むデータをインポートすると、 TiDB Lightningはエラーを報告します。
その理由は次のように説明されています。
SQL での配置ルールの目的は、特定の TiKV ノードのデータの場所をテーブルまたはパーティション レベルで制御することです。 TiDB Lightningは、テキスト ファイル内のデータをターゲットの TiDB クラスターにインポートします。データ ファイルが配置ルールの定義とともにエクスポートされる場合、インポート プロセス中に、 TiDB Lightningは定義に基づいてターゲット クラスタに対応する配置ルール ポリシーを作成する必要があります。ソース クラスタとターゲット クラスタのトポロジが異なる場合、これが問題を引き起こす可能性があります。
ソース クラスタに次のトポロジがあるとします。
ソース クラスタには、次の配置ポリシーがあります。
CREATE PLACEMENT POLICY p1 PRIMARY_REGION="us-east" REGIONS="us-east,us-west";
状況 1:ターゲット クラスターに 3 つのレプリカがあり、トポロジーがソース クラスターとは異なります。このような場合、 TiDB Lightningがターゲット クラスタに配置ポリシーを作成するときに、エラーは報告されません。ただし、ターゲット クラスタのセマンティクスは間違っています。
状況 2:ターゲット クラスターは、リージョン「us-mid」の別の TiKV ノードにフォロワー レプリカを配置し、トポロジーにリージョン「us-west」を持っていません。このような場合、ターゲット クラスタで配置ポリシーを作成すると、 TiDB Lightningはエラーを報告します。
回避策:
TiDB Lightningを使用して SQL で配置ルールを使用するには、データをターゲット テーブルにインポートする前に、関連するラベルとオブジェクトがターゲット TiDB クラスターに作成されていることを確認する必要があります。 SQL の配置ルールは PD および TiKVレイヤーで機能するため、 TiDB Lightningは、インポートされたデータを格納するためにどの TiKV を使用する必要があるかを見つけるために必要な情報を取得できます。このように、SQL のこの配置ルールはTiDB Lightningに対して透過的です。
手順は次のとおりです。
- データ分散トポロジを計画します。
- TiKV と PD に必要なラベルを構成します。
- 配置ルール ポリシーを作成し、作成したポリシーをターゲット テーブルに適用します。
- TiDB Lightningを使用して、データをターゲット テーブルにインポートします。