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

ApsaraDB for ClickHouse:ApsaraDB for ClickHouse Community-compatible Edition クラスター間でデータを移行する

最終更新日:Nov 09, 2025

ApsaraDB for ClickHouse Community-compatible Edition クラスターのバージョンを切り替える予定がある場合、ApsaraDB for ClickHouse コンソールのインスタンス移行機能を使用してデータを移行できます。この機能は、完全データ移行と増分データ移行をサポートし、データ整合性を確保します。

前提条件

  • ソースクラスタとデスティネーションクラスタの両方が、次の要件を満たしている必要があります。

    • 両方のクラスターが Community-compatible Edition クラスターである必要があります。

      説明

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

    • すべてのステータスが [実行中] です。

    • それぞれがデータベースアカウントとパスワードを持つようになりました。

    • ホットデータとコールドデータの階層化ストレージのステータスが両方で同じであること。

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

      説明

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

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

    • バージョンがソースクラスターのバージョンと同じかそれ以降であること。最新バージョンについては、「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-compatible Edition インスタンス] タブを選択し、宛先クラスターの ID をクリックします。

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

  4. [インスタンス移行] ページで、[移行タスクの作成] をクリックします。

    1. ソースインスタンスと宛先インスタンスを構成します。

      次の情報を構成し、[接続をテストして続行] をクリックします。

      説明

      接続テストが成功したら、次のステップに進みます。テストが失敗した場合は、プロンプトに従ってソースインスタンスと宛先インスタンスを再構成します。

      image

    2. 移行コンテンツを確認します。

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

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

      システムは、ソースインスタンスと宛先インスタンスで [インスタンスステータスチェック][ストレージ容量チェック]、および [ローカルテーブルと分散テーブルのチェック] を実行します。

      • チェックが成功した場合:

        1. 移行中のインスタンスへの影響について、ページ上の情報を注意深くお読みください。

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

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

          • 移行の成功率を高めるために、書き込み停止時間を少なくとも 30 分に設定することをお勧めします。

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

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

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

          説明

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

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

        チェック項目

        要件

        インスタンスステータスチェック

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

        ストレージ容量チェック

        移行前に、システムはストレージ容量をチェックします。宛先クラスターのストレージ容量は、ソースクラスターのストレージ容量の少なくとも 1.2 倍である必要があります。

        ローカルテーブルと分散テーブルのチェック

        ソースクラスター内のローカルテーブルに分散テーブルがない場合、またはその分散テーブルが一意でない場合、チェックは失敗します。余分な分散テーブルを削除するか、一意の分散テーブルを作成する必要があります。

ステップ 2: 移行が完了できるかどうかの評価

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

ソースクラスターの書き込み速度が 20 MB/s を超える場合は、宛先クラスターの実際の書き込み速度を確認して、移行が完了できるかどうかを評価する必要があります。宛先クラスターの書き込み速度は、ソースクラスターの書き込み速度に追いつくことができなければなりません。次のステップを実行します:

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

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

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

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

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

  1. [クラスター] ページで、[Community-compatible Edition インスタンス] タブを選択し、宛先クラスターの ID をクリックします。

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

    インスタンス移行リストページで、移行タスクの [移行ステータス][実行ステージ情報]、および [書き込み停止ウィンドウ] を表示できます。

    説明

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

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

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

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

ステップ 4: (オプション) 移行タスクのキャンセル

  1. [クラスター] ページで、[Community-compatible Edition インスタンス] タブを選択し、宛先クラスターの ID をクリックします。

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

  3. ターゲット移行タスクの [アクション] 列で、[移行のキャンセル] をクリックします。

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

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

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

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

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

  1. [クラスター] ページで、[Community-compatible Edition インスタンス] タブを選択し、宛先クラスターの ID をクリックします。

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

  3. ターゲット移行タスクの [アクション] 列で、[書き込み停止ウィンドウの変更] をクリックします。

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

    説明

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

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

関連情報

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