📣
TiDB Cloud Essential はパブリックプレビュー中です。このページは自動翻訳されたものです。原文はこちらからご覧ください。
TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

物理インポートモード

物理インポートモードは、SQLインターフェースを経由せずに、TiKVノードにキーと値のペアとして直接データを挿入する、効率的で高速なインポートモードです。物理インポートモードを使用する場合、Lightningインスタンス1つで最大10TiBのデータをインポートできます。Lightningインスタンスの数が増えると、サポートされるインポートデータ量は理論上増加します。ユーザーによる検証では、Lightningインスタンス並行輸入で最大50TiBのデータを効率的に処理できることが示されています。

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

物理インポートモードのバックエンドはlocalです。これをtidb-lightning.tomlで変更できます。

[tikv-importer]
# Set the import mode to "local" to use the physical import mode.
backend = "local"

実装

  1. 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 はグローバル スケジューリングを一時停止します。

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

    add-index-by-sqlをtrueに設定した場合、 tidb-lightning SQLインターフェース経由でインデックスを追加し、データをインポートする前にターゲットテーブルからすべてのセカンダリインデックスを削除します。デフォルト値はfalseで、以前のバージョンと一致しています。

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

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

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

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

    tidb-lightning SQL インターフェイス経由でインデックスを追加する場合 (つまり、 add-index-by-sqlをtrueに設定する場合)、ターゲット テーブルのセカンダリ インデックスは手順 2 で既に削除されているため、インデックス エンジンはデータを書き込まないことに注意してください。

  6. すべてのエンジンファイルがインポートされた後、 TiDB Lightningはローカルデータソースと下流クラスターのチェックサムを比較し、インポートされたデータが破損していないことを確認します。その後、 TiDB Lightningはステップ2で削除したセカンダリインデックスを追加するか、TiDBに新しいデータを分析させて（ ANALYZE ）、将来の操作を最適化します。一方、 tidb-lightning将来の競合を防ぐためにAUTO_INCREMENT値を調整します。

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

  7. すべての手順が完了すると、 TiDB Lightningは自動的にTiKVノードを「通常モード」に切り替えます。グローバルスケジューリングが一時停止されている場合、 TiDB Lightningはグローバルスケジューリングも回復します。その後、TiDBクラスタは通常通りサービスを提供できるようになります。

要件と制限

環境要件

オペレーティング·システム：

CentOS 7の新規インスタンスの使用をお勧めします。仮想マシンはローカルホストまたはクラウドにデプロイできます。TiDB TiDB Lightningはデフォルトで必要なCPUリソースを消費するため、専用サーバーにデプロイすることをお勧めします。これが不可能な場合は、他のTiDBコンポーネント（例：tikv-server）と一緒に単一のサーバーにデプロイし、 TiDB LightningからのCPU使用量を制限するようにregion-concurrency設定できます。通常、サイズは論理CPUの75%に設定できます。

メモリとCPU :

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

注記：

大量のデータをインポートする場合、1回の同時インポートで約2GiBのメモリが消費される可能性があります。メモリ使用量は合計でregion-concurrency * 2 GiBまで減少します。デフォルトでは、メモリ使用量は論理CPUの数と同じregion-concurrencyです。メモリサイズ（GiB）がCPUの2倍未満の場合、またはインポート中にOOM（オーバーヘッドオーバー）が発生する場合は、OOMを回避するためにregion-concurrencyまで減らすことができます。

ストレージ: 設定項目sorted-kv-dirは、ソートされたキーバリューファイルの一時storageディレクトリを指定します。このディレクトリは空でなければならず、storage容量はインポートするデータセットのサイズよりも大きくなければなりません。インポートのパフォーマンスを向上させるには、設定項目data-source-dirとは異なるディレクトリを使用し、フラッシュstorageと排他I/Oを使用することを推奨します。

ネットワーク: 10Gbps イーサネット カードを推奨します。

バージョン要件

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

制限事項

  • 本番のTiDBクラスタにデータを直接インポートする際に、物理インポートモードを使用しないでください。パフォーマンスに重大な影響が生じます。必要な場合は、 テーブルレベルでスケジュールを一時停止するを参照してください。
  • TiDBクラスタにレイテンシの影響を受けやすいアプリケーションがあり、同時実行性が低い場合は、物理インポートモードを使用してクラスタにデータをインポートしないことを強くお勧めします。このモードは、オンラインアプリケーションに重大な影響を与える可能性があります。
  • 複数のTiDB Lightningインスタンスを同時に実行して同じTiDBクラスタにデータをインポートする場合は、 並行輸入有効にしてインポートを調整できます。各インスタンスが異なるテーブルにデータをインポートする場合は、並列インポートオプションは必要ありません。ただし、複数のインスタンスが同じテーブルにデータをインポートする場合は、競合を防ぎ、データの整合性を確保するために、並列インポートを有効にする必要があります。
  • 複数の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 はデータのインポートに失敗する可能性があります。
    • TiDB Lightning物理インポート モードでインポートされたデータはログバックアップサポートしていないため、Point-in-Time Recovery (PITR) では復元できません。

このページは役に立ちましたか？