物理インポートモード

物理インポートモードは、SQL インターフェイスを経由せずに、キーと値のペアとしてデータを直接 TiKV ノードに挿入する、効率的で高速なインポートモードです。物理インポートモードを使用する場合、Lightning の 1 つのインスタンスで最大 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 TiDB Lightning は、 TiDB Lightning のバージョンに応じて、グローバルスケジューリングを一時停止するかどうかを決定します。
- v7.1.0 以降では、 TiDB Lightningパラメータpause-pd-scheduler-scopeを使用して、一時停止スケジュールの範囲を制御できます。
- TiDB Lightningバージョンが v6.2.0 から v7.0.0 の場合、グローバルスケジューリングを一時停止する動作は TiDB クラスターのバージョンによって異なります。TiDB クラスターが >= v6.1.0 の場合、 TiDB Lightning はターゲットテーブルデータを格納するリージョンのスケジューリングを一時停止します。インポートが完了すると、 TiDB Lightning はスケジューリングを回復します。その他のバージョンの場合、 TiDB Lightning はグローバルスケジューリングを一時停止します。
- TiDB Lightning < v6.2.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 TiDB Lightning は、デフォルトで必要なだけの CPU リソースを消費するため、専用サーバーにデプロイすることをお勧めします。これが不可能な場合は、他の TiDB コンポーネント (tikv-server など) と一緒に単一のサーバーにデプロイし、 region-concurrency設定してTiDB Lightningからの CPU 使用量を制限できます。通常、サイズは論理 CPU の 75% に設定できます。

メモリとCPU :

より良いパフォーマンスを得るには、32 コア以上の CPU と 64 GiB 以上のメモリを割り当てることをお勧めします。

注記：
大量のデータをインポートする場合、1 回の同時インポートで約 2 GiB のメモリが消費されることがあります。メモリ使用量の合計はregion-concurrency * 2 GiBなります。デフォルトではregion-concurrency論理 CPU の数と同じです。メモリサイズ (GiB) が CPU の 2 倍未満の場合、またはインポート中に OOM が発生する場合は、 region-concurrencyを減らすことで OOM を回避できます。

ストレージ: sorted-kv-dir構成項目は、ソートされたキー値ファイルの一時storageディレクトリを指定します。ディレクトリは空である必要があり、storageスペースはインポートするデータセットのサイズよりも大きくする必要があります。インポートのパフォーマンスを向上させるには、 data-source-dirとは異なるディレクトリを使用し、ディレクトリにフラッシュstorageと排他的 I/O を使用することをお勧めします。

ネットワーク: 10Gbps イーサネットカードが推奨されます。

バージョン要件

TiDB Lightning >= v4.0.3。
TiDB >= v4.0.0。

制限事項

本番で TiDB クラスターにデータを直接インポートする場合、物理インポートモードを使用しないでください。パフォーマンスに重大な影響を及ぼします。必要な場合は、テーブルレベルでスケジュールを一時停止するを参照してください。
TiDB クラスターにレイテンシの影響を受けやすいアプリケーションがあり、同時実行性が低い場合は、物理インポートモードを使用してクラスターにデータをインポートしないことを強くお勧めします。このモードは、オンラインアプリケーションに大きな影響を与える可能性があります。
デフォルトでは、同じ TiDB クラスターにデータをインポートするために複数のTiDB Lightningインスタンスを使用しないでください。代わりに並行輸入を使用してください。
複数のTiDB Lightningを使用して同じターゲットクラスターにデータをインポートする場合は、インポートモードを混在させないでください。つまり、物理インポートモードと論理インポートモードを同時に使用しないでください。
データのインポート処理中は、ターゲットテーブルで DDL および DML 操作を実行しないでください。そうしないと、インポートが失敗するか、データの不整合が発生します。同時に、読み取ったデータに不整合がある可能性があるため、読み取り操作を実行することはお勧めしません。インポート操作が完了したら、読み取り操作と書き込み操作を実行できます。
1 つの Lightning プロセスでは、最大 10 TiB の 1 つのテーブルをインポートできます。並列インポートでは、最大 10 個の Lightning インスタンスを使用できます。

他のコンポーネントと併用する場合のヒント

TiDB Lightning をTiFlashと併用する場合は、次の点に注意してください。
- テーブルのTiFlashレプリカを作成したかどうかに関係なく、 TiDB Lightningを使用してテーブルにデータをインポートできます。ただし、インポートは通常のインポートよりも時間がかかる場合があります。インポート時間は、TiDB Lightning がデプロイされているサーバーのネットワーク帯域幅、 TiFlashノードの CPU とディスクの負荷、およびTiFlashレプリカの数によって左右されます。
TiDB Lightning文字セット:
- v5.4.0 より前のTiDB Lightning、 charset=GBKのテーブルをインポートできません。
TiCDC でTiDB Lightning を使用する場合は、次の点に注意してください。
- TiCDC は物理インポートモードで挿入されたデータをキャプチャできません。
BRでTiDB Lightning を使用する場合は、次の点に注意してください。
- BR がTiDB Lightningによってインポートされているテーブルのスナップショットをバックアップすると、それらのテーブルのバックアップデータが不整合になる可能性があります。
- BR がAWS EBS ボリュームスナップショットを使用してデータをバックアップすると、 TiDB Lightning はデータのインポートに失敗する可能性があります。
- ポイントインタイムリカバリ (PITR) では、 TiDB Lightningによってインポートされたデータをバックアップできません。