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

ApsaraDB for ClickHouse:ApsaraDB for ClickHouse クラスター間のデータ移行

最終更新日:Mar 14, 2026

ApsaraDB for ClickHouse Community-compatible Edition クラスターのバージョンを変更する場合、ApsaraDB for ClickHouse コンソールのインスタンス移行機能を使用してデータを移行できます。この機能は、全量および増分データ移行をサポートし、データの整合性を保証します。

前提条件

  • 移行元と移行先の両方のクラスターが、次の要件を満たしている必要があります:

    • 両方のクラスターは、コミュニティ互換エディションクラスターである必要があります。

      説明

      Community-compatible Edition クラスターを Enterprise Edition クラスターに移行する場合、またはその逆の場合は、「ClickHouse Community-compatible Edition クラスターから Enterprise Edition クラスターへの移行」をご参照ください。

    • すべて実行中です。

    • 両方にデータベースアカウントとパスワードがあること。

    • ホット/コールド階層化ストレージの状態が両者で一致していること。

    • 両方のクラスターが同じ VPC を使用し、同じリージョンにあること。お互いの IP アドレスをホワイトリストに追加する必要があります。これらの条件が満たされない場合は、まずネットワークの問題を解決する必要があります。詳細については、「移行先クラスターとデータソース間のネットワーク接続の問題を解決する方法」をご参照ください。

      説明

      ApsaraDB for ClickHouse インスタンスの IP アドレスは、SELECT * FROM system.clusters; を実行して確認できます。ホワイトリストの設定の詳細については、「ホワイトリストの設定」をご参照ください。

  • 移行先クラスターは、次の要件も満たしている必要があります:

    • バージョンが移行元クラスターのバージョンと同じかそれ以降であること。最新バージョンについては、「Community-compatible Edition」をご参照ください。

    • 未使用のディスクストレージ容量 (コールドストレージを除く) が、移行元クラスターの使用済みディスクストレージ容量 (コールドストレージを除く) の少なくとも 1.2 倍であること。

  • 移行元クラスターの各ローカルテーブルに、一意の分散テーブルがあること。

注意事項

  • 移行速度:移行先クラスターのシングルノードの移行速度は、通常 20 MB/s を超えます。移行元クラスターのシングルノードの書き込み速度も 20 MB/s を超える場合は、移行先クラスターの移行速度が移行元クラスターの書き込み速度に追いつけるかどうかを評価する必要があります。追いつけない場合、移行が完了しない可能性があります。

  • 移行中、移行先クラスターはマージ操作を一時停止しますが、移行元クラスターは一時停止しません。

  • 移行内容:

    • クラスター、データベース、テーブル、データディクショナリ、マテリアライズドビュー、ユーザー権限、クラスター構成を移行できます。

      • SQL を使用して作成されたデータディクショナリのみ移行できます。XML を使用して作成されたデータディクショナリはサポートされていません。

        確認するには、次のコマンドを実行します: SELECT * FROM system.dictionaries WHERE (database = '') OR isNull(database);。コマンドが結果を返した場合、XML を使用して作成されたデータディクショナリが存在します。

      • データディクショナリが外部サービスにアクセスする場合、そのサービスが利用可能であり、そのホワイトリストがクラスターからのアクセスを許可していることを確認する必要があります。データディクショナリが現在の ClickHouse インスタンスの内部テーブルをデータソースとして使用し、HOST パラメーターが IP アドレスに設定されている場合、IP アドレスが変更されるため移行後にアクセスが失敗する可能性があります。この場合、ClickHouse インスタンスの新しい HOST の IP アドレスを確認し、データディクショナリを手動で再作成する必要があります。

    • Kafka および RabbitMQ エンジンテーブルは移行をサポートしていません。

    • 重要

      Kafka および RabbitMQ のデータが分割されないようにするには、移行元クラスターから Kafka および RabbitMQ エンジンテーブルをクリアする必要があります。その後、移行先クラスターでそれらを作成するか、異なるコンシューマーグループを使用できます。

      外部テーブルや Log テーブルなど、非 MergeTree テーブルのテーブルスキーマのみが移行可能です。

      説明

      移行元クラスターに非 MergeTree テーブルが含まれている場合、移行後の移行先クラスターのこれらのテーブルにはスキーマのみが存在し、ビジネスデータは含まれません。ビジネスデータを移行するには、remote 関数を使用できます。詳細については、「remote 関数を使用したデータ移行」をご参照ください。

  • データ量:

    • コールドデータ:コールドデータの移行は低速です。移行元クラスターのコールドデータをクリアして、合計サイズが 1 TB を超えないようにする必要があります。超える場合、長時間の移行により失敗する可能性があります。

    • ホットデータ:ホットデータが 10 TB を超える場合、移行タスクの失敗率が高くなります。この方法での移行は使用しないでください。

  • データが上記の条件を満たさない場合は、「手動移行」を実行する必要があります。

クラスターへの影響

  • 移行元クラスター:データ移行中、移行元クラスターのテーブルに対して読み取りおよび書き込みは可能ですが、データベースやテーブルのメタデータを追加、削除、変更するなどのデータ定義言語 (DDL) 操作は実行できません。

    重要
    • 移行タスクの完了を保証するため、コンソールでの推定残り移行時間が 10 分以下になると、事前に設定された書き込み停止タイムウィンドウ内で移行元クラスターは自動的にデータ書き込みを一時停止します。

    • 事前に設定されたタイムウィンドウ内にすべてのデータが移行された場合、または移行が完了する前にタイムウィンドウが終了した場合、移行元クラスターは自動的にデータ書き込みを再開します。

  • 移行先クラスター:移行後、移行先クラスターは一定期間、頻繁にマージ操作を実行します。これにより I/O 使用量が増加し、サービスリクエストのレイテンシーが高くなる可能性があります。このレイテンシー増加による潜在的な影響について、事前に計画を立てる必要があります。マージ操作の期間はご自身で計算できます。期間の計算については、「移行後のマージ期間の計算」をご参照ください。

操作手順

重要

以降の手順は、移行元クラスターではなく、移行先クラスターで実行する必要があります。

ステップ 1: 移行タスクの作成

  1. ApsaraDB for ClickHouse コンソールにログインします。

  2. クラスターリスト ページで、Community Edition インスタンスのリスト タブを選択し、移行先クラスターの ID をクリックします。

  3. 左側のナビゲーションウィンドウで、データの移行と同期 > インスタンスの移行 をクリックします。

  4. 移行タスクの作成 をクリックします。

    1. 移行元インスタンスと移行先インスタンスを設定します。

      次の情報を設定し、次のステップの接続をテストします をクリックします。

      説明

      接続テストが成功すると、次のステップに進むことができます。テストが失敗した場合は、プロンプトに従って移行元インスタンスと移行先インスタンスを再設定する必要があります。

      image

    2. 移行内容を確認します。

      ページ上の移行内容に関する情報を注意深く読み、次: 同期の事前検出と開始 をクリックします。

    3. システムが事前チェックを実行し、タスクを開始します。

      システムは、移行元インスタンスと移行先インスタンスに対して、インスタンスステータスの検出ストレージスペースの検出、および ローカルおよび分散テーブルの検出 を実行します。

      • 検出成功:

        1. ページ上の移行中のインスタンスへの影響に関する情報を注意深く読みます。

        2. 書き込み停止時間 を設定します。

          説明
          • データ整合性を確保するため、移行の最後の 10 分間は移行元クラスターの書き込みを停止する必要があります。

          • 移行の成功率を高めるため、書き込み停止時間は少なくとも 30 分に設定する必要があります。

          • 移行タスクは作成から 5 日以内に終了する必要があります。したがって、書き込み停止時間 の終了日は 現在の日付 + 5 日 以降にすることはできません。

          • ビジネスへの影響を軽減するため、書き込み停止タイムウィンドウをオフピーク時間に設定できます。

        3. [完了] をクリックします。

          説明

          [完了] をクリックすると、タスクが作成され、開始されます。

      • チェックが失敗した場合は、プロンプトに従って問題を解決し、データ移行を再試行する必要があります。確認項目と要件は次のとおりです。

        確認項目

        検出要件

        インスタンスステータスの検出

        移行開始時に、スケールアウトや構成変更などの管理タスクが移行元または移行先クラスターで実行されていないこと。管理タスクが実行中の場合、移行タスクを開始することはできません。

        ストレージスペースの検出

        移行前にストレージ容量を確認します。移行先クラスターのストレージ容量は、移行元クラスターのストレージ容量の少なくとも 1.2 倍である必要があります。

        ローカルおよび分散テーブルの検出

        移行元クラスターのローカルテーブルに分散テーブルがない場合、またはその分散テーブルが一意でない場合、チェックは失敗します。余分な分散テーブルを削除するか、一意の分散テーブルを作成してください。

ステップ 2: 移行が完了可能かどうかの評価

移行元クラスターの書き込み速度が 20 MB/s 未満の場合は、このステップをスキップできます。

移行元クラスターの書き込み速度が 20 MB/s を超える場合、移行先クラスターのシングルノードの書き込み速度も理論的には 20 MB/s を超えます。移行先クラスターの書き込み速度が移行元クラスターの書き込み速度に追いつき、移行を完了できるようにするには、移行先クラスターの実際の書き込み速度を確認して移行の実現可能性を評価する必要があります。次の手順を実行します:

  1. 移行先クラスターのディスクスループットを確認して、実際の書き込み速度を判断します。ディスクスループットの表示方法の詳細については、「監視メトリクスの表示」をご参照ください。

  2. 移行先クラスターと移行元クラスターの書き込み速度を比較します。

    1. 移行先クラスターの書き込み速度が移行元クラスターの書き込み速度より大きい場合、移行の成功率は高いです。ステップ 3 に進みます。

    2. 移行先クラスターの書き込み速度が移行元クラスターの書き込み速度より低い場合、移行は失敗する可能性があります。「移行タスクのキャンセル」または「手動移行」を実行することを推奨します。

ステップ 3: 移行タスクの表示

  1. クラスターリスト ページで、Community Edition インスタンスのリスト タブを選択し、移行先クラスターの ID をクリックします。

  2. 左側のナビゲーションウィンドウで、データの移行と同期 > インスタンスの移行 をクリックします。

    インスタンス移行リストページで、移行タスクの 移行ステータス実行段階の情報、および ウィンドウの書き込みを停止する を確認できます。

    説明

    実行段階の情報 列の推定残り時間が 10 分以下で、移行ステータスが [移行中] の場合、データ整合性を確保するために移行元クラスターの書き込み停止がトリガーされます。ルールは次のとおりです:

    • トリガー時間が移行元クラスターの事前に設定された書き込み停止タイムウィンドウである場合、移行元クラスターは書き込みを停止します。

    • トリガー時間が移行元クラスターの事前に定義された書き込み停止タイムウィンドウであり、かつ タスク作成日 + 5 日 以下である場合、移行タスクを続行するには書き込み停止タイムウィンドウを変更する必要があります。

    • トリガー時間が移行元クラスターの事前に定義された書き込み停止タイムウィンドウであり、かつ タスク作成日 + 5 日 より大きい場合、移行は失敗します。移行タスクをキャンセルし、移行先クラスターの移行済みデータをクリアして、移行タスクを再作成する必要があります。

ステップ 4: (任意) 移行タスクのキャンセル

  1. クラスターリスト ページで、Community Edition インスタンスのリスト に移動し、対象クラスターの ID をクリックします。

  2. 左側のナビゲーションウィンドウで、データの移行と同期 > インスタンスの移行 をクリックします。

  3. 対象の移行タスクの 操作 列で、移行のキャンセル をクリックします。

  4. 移行のキャンセル ダイアログボックスで、[OK] をクリックします。

    説明
    • 移行をキャンセルした後、タスクリストはすぐには更新されません。ページを定期的に更新してタスクのステータスを確認できます。

    • タスクがキャンセルされると、その [移行ステータス][完了] に変わります。

    • 新しい移行を開始する前に、データの重複を避けるために、移行先クラスターから移行済みのデータをクリアする必要があります。

ステップ 5: (任意) 書き込み停止タイムウィンドウの変更

  1. クラスターリスト ページで、Community Edition インスタンスのリスト タブを選択し、移行先クラスターの ID をクリックします。

  2. 左側のナビゲーションウィンドウで、データの移行と同期 > インスタンスの移行 をクリックします。

  3. 対象の移行タスクの 操作 列で、書き込み停止ウィンドウの変更 をクリックします。

  4. 書き込み停止ウィンドウの変更 ダイアログボックスで、書き込み停止時間 を選択します。

    説明

    書き込み停止時間 の設定ルールは、移行タスク作成時と同じです。

  5. [OK] をクリックします。

関連資料

セルフマネージド ClickHouse クラスターから ApsaraDB for ClickHouse にデータを移行する方法については、「セルフマネージド ClickHouse クラスターから ApsaraDB for ClickHouse Community-compatible Edition クラスターへのデータ移行」をご参照ください。