すべてのプロダクト
Search
ドキュメントセンター

Lindorm:HBase クラスタから Lindorm へのデータの移行と同期

最終更新日:Mar 18, 2025

Lindorm Tunnel Service (LTS) を使用して、既存のデータの移行と、セルフマネージド HBase クラスタまたは ApsaraDB for HBase クラスタから LindormTable へのリアルタイムデータの同期を実行できます。このトピックでは、HBase クラスタからデータを移行および同期する方法について説明します。

シナリオ

  • セルフマネージド HBase クラスタから Lindorm へのデータ移行。

  • リージョン間のデータ移行。たとえば、中国 (青島) リージョンのデータセンターから中国 (北京) リージョンのデータセンターにデータを移行できます。

  • ワークロード分散。たとえば、ビジネスの一部を新しいクラスタに移行できます。

機能と利点

サポートされている機能

  • HBase V1.x および V2.x クラスタから Lindorm に、ビジネスを中断することなくデータを移行できます。

  • テーブルスキーマの移行、リアルタイムデータ同期、および完全なデータ移行がサポートされています。

  • データベース、名前空間、およびテーブルに基づく移行がサポートされています。

  • 移行中のテーブル名の変更がサポートされています。

  • 移行中に、時間範囲、行キー範囲、および列を指定できます。

  • 移行タスクを作成するための API 操作がサポートされています。

利点

  • 移行中、ビジネスは中断されません。1 つの移行タスク中に、既存データとリアルタイムの増分データの両方を移行できます。

  • データの移行中、宛先のセルフマネージド HBase クラスタは、ソース HBase クラスタと対話しません。宛先 HBase クラスタは、ソースクラスタの HDFS からのみデータを読み取ります。これにより、ソースクラスタで実行されているオンラインビジネスへの影響が最小限に抑えられます。

  • ほとんどの場合、API レイヤーでのデータ移行と比較して、ファイルレイヤーでのデータレプリケーションにより、データ使用量の 50% 以上を削減し、効率を向上させることができます。

  • 各ノードは最大 150 MB/秒の速度でデータを移行できるため、データ移行の安定性要件を満たすことができます。水平スケーリングのためにノードを追加して、テラバイトまたはペタバイトのデータを移行できます。

  • LTS は堅牢な再試行メカニズムを実装してエラーに対応します。LTS はタスク速度とタスクの進捗状況をリアルタイムで監視し、タスクが失敗した場合にアラートを生成します。

  • LTS はスキーマを自動的に同期して、パーティション間の一貫性を確保します。

制限事項

  • セルフマネージド HBase クラスタにデータを移行することはできません。

  • Kerberos が有効になっている HBase クラスタはサポートされていません。

  • シングルノードの ApsaraDB for HBase クラスタはサポートされていません。

  • ネットワークの互換性の問題により、クラシックネットワークにデプロイされている ApsaraDB for HBase クラスタはサポートされていません。

  • Lindorm スタンドアロンインスタンスにデータを移行または同期することはできません。

  • LTS は、先行書き込みログ (WAL) に基づいて増分データを同期するための非同期モードを実装しています。バルクロードを使用してインポートされたデータ、および WAL ファイルに書き込まれていないデータは同期されません。

  • 検索インデックスは移行できません。

使用上の注意

  • データを移行する前に、宛先クラスタの HDFS 容量が十分であることを確認してください。これは、移行中に容量が不足するのを防ぐのに役立ちます。

  • 増分同期タスクを送信する前に、ソースクラスタのログ保存期間を 12 時間より長く設定して、LTS が増分同期のエラーを処理するための時間を確保することをお勧めします。hbase-site.xml 構成ファイルの hbase.master.logcleaner.ttl パラメーターの値を変更して、ソースクラスタのログ保存期間を設定できます。パラメーター値を変更した後、ソースクラスタを再起動する必要があります。hbase.master.logcleaner.ttl パラメーターの単位は ms です。たとえば、hbase.master.logcleaner.ttl パラメーターを 43200000 に設定すると、指定されたログ保存期間は 12 時間になります。

  • 宛先クラスタにテーブルを手動で作成する必要はありません。LTS は、ソースクラスタと同じ方法でテーブルとリージョンを自動的に作成します。手動で作成されたテーブルのパーティション分割スキームは、ソーステーブルのパーティション分割スキームとは異なる場合があります。その結果、移行プロセスが完了した後、手動で作成されたテーブルが頻繁に分割または圧縮される可能性があります。テーブルに大量のデータが格納されている場合、プロセス全体に時間がかかる場合があります。

  • ソーステーブルにコプロセッサがある場合は、宛先テーブルを作成するときに、宛先クラスタに対応するコプロセッサの JAR ファイルが含まれていることを確認してください。

  • 増分同期機能を有効にした後、ログデータが消費されない場合、ログデータはデフォルトで 48 時間保持されます。期間が経過すると、サブスクリプションは自動的にキャンセルされ、保持されているデータは自動的に削除されます。

前提条件

タスクの作成

  1. LTS にログオンします。詳細については、「LTS の Web UI にログオンする」をご参照ください。

  2. 左側のナビゲーションウィンドウで、[移行] > [クイック移行] を選択します。

  3. パラメーターを構成し、[作成] をクリックします。

  4. [ジョブ名 (オプション)] フィールドに、タスクの名前を入力します。タスク名には、文字と数字のみを含めることができます。タスク名は指定しないでおくことができます。この場合、タスク ID がタスク名として使用されます。

  5. プロンプトに従って、[ソースクラスタ] パラメーターと [ターゲットクラスタ] パラメーターを構成します。

  6. 実行する操作を選択します。

    • [移行テーブルスキーマ]: 宛先クラスタにテーブルを作成します。これらのテーブルは、ソーステーブルと同じスキーマとパーティション情報を持っています。宛先クラスタにテーブルが既に存在する場合、このテーブルのデータは移行されません。

    • [リアルタイムデータレプリケーション]: ソースクラスタから増分データをリアルタイムで同期します。

    • [既存データの移行]: すべてのファイルを物理的に移行します。

  7. [テーブルマッピング] フィールドと [詳細設定] フィールドに必要な情報を入力します。詳細設定フィールドは指定しないでおくことができます。

  8. [作成] をクリックします。

タスクの詳細の表示

  1. 左側のナビゲーションウィンドウで、[移行] > [クイック移行] を選択して、作成したタスクを表示します。

  2. 表示されたページで、表示するタスクの名前をクリックします。表示されたページで、タスクの実行ステータスを表示します。

スイッチオーバーの実行

  1. 完全移行タスクが完了するまで待ちます。増分同期の待機時間は、数秒または数百ミリ秒と短くなっています。

  2. LTS データサンプリングと検証を有効にします。大きなテーブルをサンプリングして検証する場合は、オンラインビジネスへの影響を防ぐために、サンプリング比率が適切であることを確認してください。

  3. ビジネスを確認します。

  4. ビジネスでスイッチオーバーを実行します。

FAQ

タスクのデータが消費されないのはなぜですか?

タスクの実行中に LTS クラスタが解放されたか、同期タスクが一時停止されたか、タスクが異常にブロックされています。

データ移行タスクが失敗した場合はどうすればよいですか?

データ移行タスクは、不安定なネットワーク接続やサービスの競合などの要因により失敗する可能性があります。LTS には再試行メカニズムが備わっており、システムは障害後にタスクを自動的に再試行できます。問題が解決しない場合は、Lindorm テクニカルサポート (DingTalk ID: s0s3eg3) にお問い合わせください。