TiDB Self-Managed
Learning Center
お問い合わせ

物理インポート モード

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

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

実装

  1. データをインポートする前に、 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はグローバル スケジューリングを一時停止します。

  2. TiDB Lightningは、ターゲット データベースにテーブル スキーマを作成し、メタデータを取得します。

  3. 各テーブルは複数の連続したブロックに分割されているため、 TiDB Lightningは大きなテーブル (200 GB を超える) からデータを並行してインポートできます。

  4. TiDB Lightningは、ブロックごとに「エンジン ファイル」を用意して、キーと値のペアを処理します。 TiDB Lightningは SQL ダンプを並行して読み取り、データ ソースを TiDB と同じエンコーディングのキーと値のペアに変換し、キーと値のペアを並べ替えて、ローカルの一時ストレージ ファイルに書き込みます。

  5. エンジン ファイルが書き込まれると、 TiDB Lightningはターゲットの TiKV クラスターでデータの分割とスケジュールを開始し、データを TiKV クラスターにインポートします。

    エンジン ファイルには、データ エンジンとインデックス エンジンの 2 種類のエンジンが含まれています。各エンジンは、キーと値のペアのタイプ (行データとセカンダリ インデックス) に対応しています。通常、行データはデータ ソース内で完全に順序付けられており、セカンダリ インデックスは順序付けされていません。したがって、データ エンジン ファイルは、対応するブロックが書き込まれた直後にインポートされ、すべてのインデックス エンジン ファイルは、テーブル全体がエンコードされた後にのみインポートされます。

  6. すべてのエンジン ファイルがインポートされた後、 TiDB Lightningはローカル データ ソースとダウンストリーム クラスターの間でチェックサムを比較し、インポートされたデータが破損していないことを確認します。次に、 TiDB Lightningが新しいデータ ( ANALYZE ) を分析して、今後の運用を最適化します。一方、 tidb-lightningは将来の競合を防ぐためにAUTO_INCREMENTの値を調整します。

    自動インクリメント ID は、行数の上限によって推定され、テーブル データ ファイルの合計サイズに比例します。したがって、自動インクリメント ID は通常、実際の行数より大きくなります。自動インクリメント ID 必ずしも連続しているわけではないのため、これは正常です。

  7. すべての手順が完了すると、 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構成項目は、ソートされたキー値ファイルの一時ストレージ ディレクトリを指定します。ディレクトリは空である必要があり、ストレージ スペースはインポートするデータセットのサイズより大きくなければなりません。インポートのパフォーマンスを向上させるには、 data-source-dir以外のディレクトリを使用し、そのディレクトリにフラッシュ ストレージと排他的 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 インスタンスを使用できます。

他のコンポーネントと併用するためのヒント

  • TiFlash でTiDB Lightningを使用する場合は、次の点に注意してください。

    • テーブルの TiFlash レプリカを作成したかどうかに関係なく、 TiDB Lightningを使用してデータをテーブルにインポートできます。ただし、インポートには通常のインポートよりも時間がかかる場合があります。インポート時間は、 TiDB Lightningがデプロイされているサーバーのネットワーク帯域幅、TiFlash ノードの CPU とディスクの負荷、および TiFlash レプリカの数の影響を受けます。

  • TiDB Lightning文字セット:

    • TiDB Lightningはcharset=GBKのテーブルをインポートできません。

  • TiCDC でTiDB Lightningを使用する場合は、以下ではありません。

    • TiCDC は、物理インポート モードで挿入されたデータをキャプチャできません。