物理インポートモード

物理インポートモードは効率的で高速なインポートモードで、SQL インターフェイスを介さずにデータをキーと値のペアとして直接 TiKV ノードに挿入します。最大 100 TB のデータのインポートに適しています。これは、並行輸入 10 タスクで、各タスクが 10 TB のデータをインポートすることで実現できます。

物理インポートモードを使用する前に、必ず要件と制限をお読みください。

物理インポートモードのバックエンドはlocalです。

実装

データをインポートする前に、 TiDB Lightning は自動的に TiKV ノードを「インポートモード」に切り替えます。これにより、書き込みパフォーマンスが向上し、自動圧縮が停止します。 TiDB Lightning は、 TiDB クラスターのバージョンに応じて、グローバルスケジューリングを一時停止するかどうかを決定します。
- TiDB クラスター >= v6.1.0 およびTiDB Lightning >= v6.2.0 の場合、 TiDB Lightning は、ターゲットテーブルデータを格納するリージョンのスケジューリングを一時停止します。インポートが完了すると、 TiDB Lightning はスケジューリングを回復します。
- TiDB クラスター < v6.1.0 またはTiDB Lightning < v6.2.0 の場合、 TiDB Lightning はグローバルスケジューリングを一時停止します。
TiDB Lightning は、ターゲットデータベースにテーブルスキーマを作成し、メタデータをフェッチします。
各テーブルは複数の連続したブロックに分割されているため、 TiDB Lightning は大きなテーブル (200 GB を超える) からデータを並行してインポートできます。
TiDB Lightning は、ブロックごとに「エンジンファイル」を用意して、キーと値のペアを処理します。 TiDB Lightning はSQL ダンプを並行して読み取り、データソースを TiDB と同じエンコーディングのキーと値のペアに変換し、キーと値のペアを並べ替えて、ローカルの一時storageファイルに書き込みます。
エンジンファイルが書き込まれると、 TiDB Lightning はターゲットの TiKV クラスターでデータの分割とスケジュールを開始し、データを TiKV クラスターにインポートします。
エンジンファイルには、データエンジンとインデックスエンジンの 2 種類のエンジンが含まれています。各エンジンは、キーと値のペアのタイプ (行データとセカンダリインデックス) に対応しています。通常、行データはデータソース内で完全に順序付けられており、セカンダリインデックスは順序付けされていません。したがって、データエンジンファイルは、対応するブロックが書き込まれた直後にインポートされ、すべてのインデックスエンジンファイルは、テーブル全体がエンコードされた後にのみインポートされます。
すべてのエンジンファイルがインポートされた後、 TiDB Lightning はローカルデータソースとダウンストリームクラスターの間でチェックサムを比較し、インポートされたデータが破損していないことを確認します。次に、 TiDB Lightning が新しいデータ ( 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 以前の場合は、データのインポートを完了するために Importer-backend を使用する必要があります。このモードでは、 tidb-lightning解析されたキーと値のペアを gRPC 経由でtikv-importerに送信する必要があり、 tikv-importerはデータのインポートを完了します。

制限事項

物理インポートモードを使用して、本番の TiDB クラスターにデータを直接インポートしないでください。パフォーマンスに重大な影響があります。その必要がある場合は、テーブルレベルでスケジューリングを一時停止するを参照してください。
デフォルトでは、複数のTiDB Lightningインスタンスを使用して同じ TiDB クラスターにデータをインポートしないでください。代わりに並行輸入品を使用してください。
複数のTiDB Lightningを使用してデータを同じターゲットクラスタにインポートする場合は、インポートモードを混在させないでください。つまり、物理インポートモードと論理インポートモードを同時に使用しないでください。
データのインポートプロセス中は、ターゲットテーブルで書き込み操作を実行しないでください。そうしないと、インポートが失敗するか、データに一貫性がなくなります。同時に、読み取ったデータに一貫性がない可能性があるため、読み取り操作を実行することはお勧めしません。インポート操作が完了したら、読み取りおよび書き込み操作を実行できます。
1 つの Lightning プロセスで、最大 10 TB の 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 は、物理インポートモードで挿入されたデータをキャプチャできません。

物理インポート モード