物理インポートモード
物理インポート モードは、SQL インターフェイスを経由せずに、データをキーと値のペアとして TiKV ノードに直接挿入する、効率的かつ高速なインポート モードです。物理インポート モードを使用する場合、Lightning の単一インスタンスで最大 10 TiB のデータをインポートできます。理論的には、Lightning インスタンスの数が増えると、サポートされるインポートデータの量も増加します。 Lightning ベースの並行輸入が最大 50 TiB のデータを効果的に処理できることがユーザーによって検証されています。
物理インポートモードを使用する前に、必ず要件と制限事項をお読みください。
物理インポート モードのバックエンドはlocal
です。 tidb-lightning.toml
で変更できます。
[tikv-importer]
# Set the import mode to "local" to use the physical import mode.
backend = "local"
実装
データをインポートする前に、 TiDB Lightning は自動的に TiKV ノードを「インポート モード」に切り替えます。これにより、書き込みパフォーマンスが向上し、自動圧縮が停止されます。 TiDB Lightning は、 TiDB Lightning のバージョンに従ってグローバル スケジューリングを一時停止するかどうかを決定します。
- v7.1.0 以降、 TiDB Lightningパラメータ
pause-pd-scheduler-scope
を使用して、スケジュールの一時停止の範囲を制御できるようになりました。 - v6.2.0 と v7.0.0 の間のTiDB Lightningバージョンの場合、グローバル スケジューリングの一時停止の動作は、TiDB クラスターのバージョンによって異なります。 TiDB クラスター >= v6.1.0 の場合、 TiDB Lightning はターゲット テーブル データを保存するリージョンのスケジューリングを一時停止します。インポートが完了すると、 TiDB Lightning はスケジュールを回復します。他のバージョンの場合、 TiDB Lightning はグローバル スケジューリングを一時停止します。
- TiDB Lightning < v6.2.0 の場合、 TiDB Lightning はグローバル スケジューリングを一時停止します。
- v7.1.0 以降、 TiDB Lightningパラメータ
TiDB Lightning は、ターゲット データベースにテーブル スキーマを作成し、メタデータをフェッチします。
add-index-by-sql
からtrue
に設定すると、tidb-lightning
SQL インターフェイス経由でインデックスを追加し、データをインポートする前にターゲット テーブルからすべてのセカンダリ インデックスを削除します。デフォルト値はfalse
で、これは以前のバージョンと一致しています。各テーブルは複数の連続したブロックに分割されているため、 TiDB Lightning は大きなテーブル (200 GB を超える) から並行してデータをインポートできます。
TiDB Lightning は、キーと値のペアを処理するためにブロックごとに「エンジン ファイル」を準備します。 TiDB Lightning は、SQL ダンプを並行して読み取り、データ ソースを TiDB と同じエンコーディングのキーと値のペアに変換し、キーと値のペアを並べ替えて、ローカルの一時storageファイルに書き込みます。
エンジン ファイルが書き込まれると、 TiDB Lightning はターゲット TiKV クラスター上でデータの分割とスケジュールを開始し、データを TiKV クラスターにインポートします。
エンジン ファイルには、データ エンジンとインデックス エンジンの 2 種類のエンジンが含まれています。各エンジンは、キーと値のペアのタイプ (行データとセカンダリ インデックス) に対応します。通常、行データはデータ ソース内で完全に順序付けされており、セカンダリ インデックスは順序付けされていません。したがって、データ エンジン ファイルは対応するブロックが書き込まれた直後にインポートされ、すべてのインデックス エンジン ファイルはテーブル全体がエンコードされた後にのみインポートされます。
tidb-lightning
が SQL インターフェース経由でインデックスを追加する場合 (つまり、add-index-by-sql
をtrue
に設定する場合)、ターゲット テーブルのセカンダリ インデックスはステップ 2 ですでに削除されているため、インデックス エンジンはデータを書き込まないことに注意してください。すべてのエンジン ファイルがインポートされた後、 TiDB Lightning はローカル データ ソースとダウンストリーム クラスター間のチェックサムを比較し、インポートされたデータが破損していないことを確認します。次に、 TiDB Lightning はステップ 2 で以前に削除したセカンダリ インデックスを追加するか、TiDB に新しいデータ (
ANALYZE
) を分析させて今後の操作を最適化します。一方、tidb-lightning
将来の競合を防ぐためにAUTO_INCREMENT
値を調整します。自動インクリメント ID は行数の上限によって推定され、テーブル データ ファイルの合計サイズに比例します。したがって、自動インクリメント ID は通常、実際の行数よりも大きくなります。自動インクリメント ID は必ずしも連続しているわけではないあるため、これは正常です。
すべての手順が完了すると、 TiDB Lightning は自動的に TiKV ノードを「通常モード」に切り替えます。グローバル スケジューリングが一時停止された場合、 TiDB Lightning はグローバル スケジューリングも回復します。その後、TiDB クラスターは正常にサービスを提供できるようになります。
要件と制限事項
環境要件
オペレーティング·システム:
新しい CentOS 7 インスタンスを使用することをお勧めします。仮想マシンはローカル ホストまたはクラウドにデプロイできます。 TiDB Lightning はデフォルトで必要なだけの CPU リソースを消費するため、専用サーバーに展開することをお勧めします。これが不可能な場合は、他の TiDB コンポーネント (例: tikv-server) とともに単一サーバーにデプロイし、 TiDB Lightningからの CPU 使用率を制限するようにregion-concurrency
を構成できます。通常、サイズは論理 CPU の 75% に構成できます。
メモリとCPU :
パフォーマンスを向上させるには、32 コアを超える CPU と 64 GiB を超えるメモリを割り当てることをお勧めします。
注記:
大量のデータをインポートする場合、1 回の同時インポートで約 2 GiB のメモリを消費する可能性があります。合計メモリ使用量は
region-concurrency * 2 GiB
になることがあります。region-concurrency
は、デフォルトの論理 CPU の数と同じです。メモリサイズ (GiB) が CPU の 2 倍未満であるか、インポート中に OOM が発生する場合は、region-concurrency
を減らして OOM を回避できます。
Storage : sorted-kv-dir
構成項目は、ソートされたキーと値のファイルの一時storageディレクトリを指定します。ディレクトリは空である必要があり、storageスペースはインポートするデータセットのサイズより大きくなければなりません。インポートのパフォーマンスを向上させるには、 data-source-dir
とは異なるディレクトリを使用し、そのディレクトリに対してフラッシュstorageと排他的 I/O を使用することをお勧めします。
ネットワーク: 10Gbps イーサネット カードを推奨します。
バージョン要件
- TiDB Lightning>= v4.0.3。
- TiDB >= v4.0.0。
- ターゲット TiDB クラスターが v3.x 以前の場合、データのインポートを完了するにはインポーター バックエンドを使用する必要があります。このモードでは、
tidb-lightning
解析されたキーと値のペアを gRPC 経由でtikv-importer
に送信する必要があり、tikv-importer
でデータのインポートが完了します。
制限事項
- 本番の TiDB クラスターにデータを直接インポートするために物理インポート モードを使用しないでください。これはパフォーマンスに重大な影響を及ぼします。必要な場合はテーブルレベルでのスケジュールの一時停止を参照してください。
- TiDB クラスターにレイテンシの影響を受けやすいアプリケーションがあり、同時実行性が低い場合は、クラスターへのデータのインポートに物理インポート モードを使用しないことを強くお勧めします。このモードは、オンライン アプリケーションに大きな影響を与える可能性があります。
- デフォルトでは、同じ TiDB クラスターにデータをインポートするために複数のTiDB Lightningインスタンスを使用しないでください。代わりに並行輸入品を使用してください。
- 複数のTiDB Lightningを使用して同じターゲット クラスターにデータをインポートする場合は、インポート モードを混合しないでください。つまり、物理インポート モードと論理インポート モードを同時に使用しないでください。
- データのインポート処理中は、ターゲットテーブルで DDL および DML 操作を実行しないでください。そうしないと、インポートが失敗するか、データに不整合が生じます。同時に、読み取ったデータに一貫性がない可能性があるため、読み取り操作を実行することはお勧めできません。インポート操作が完了した後、読み取りおよび書き込み操作を実行できます。
- 1 つの Lightning プロセスで最大 10 TB の単一テーブルをインポートできます。並行インポートでは、最大 10 個の Lightning インスタンスを使用できます。
他のコンポーネントと併用する場合のヒント
TiFlashでTiDB Lightningを使用する場合は、次の点に注意してください。
- テーブルのTiFlashレプリカを作成したかどうかに関係なく、 TiDB Lightning を使用してデータをテーブルにインポートできます。ただし、インポートには通常のインポートよりも時間がかかる場合があります。インポート時間は、 TiDB Lightningがデプロイされているサーバーのネットワーク帯域幅、 TiFlashノードの CPU とディスクの負荷、およびTiFlashレプリカの数に影響されます。
TiDB Lightning文字セット:
- v5.4.0 より前のTiDB Lightning は、
charset=GBK
のテーブルをインポートできません。
- v5.4.0 より前のTiDB Lightning は、
TiCDC でTiDB Lightning を使用する場合は、次の点に注意してください。
- TiCDC は、物理インポート モードで挿入されたデータをキャプチャできません。
BRでTiDB Lightning を使用する場合は、次の点に注意してください。
- BR がTiDB Lightningによってインポートされているテーブルのスナップショットをバックアップすると、それらのテーブルのバックアップ データが不整合になる可能性があります。
- BR がAWS EBS ボリューム スナップショットを使用してデータをバックアップする場合、 TiDB Lightning はデータのインポートに失敗する場合があります。
- ポイントインタイムリカバリ (PITR) では、 TiDB Lightningによってインポートされたデータをバックアップできません。