ApsaraDB for ClickHouse:ClickHouse コミュニティ互換クラスター間のデータ移行

• 移行元クラスターと移行先クラスターは、次の要件を満たす必要があります。

  • 両方ともコミュニティ互換エディションのクラスターであること。

    説明

    コミュニティ互換エディションのクラスターからエンタープライズエディションのクラスターへ、またはその逆の移行が必要な場合は、「ClickHouse コミュニティ互換エディションクラスターからエンタープライズエディションクラスターへの移行」をご参照ください。

  • 両方のクラスターが 実行中 状態であること。

  • 各クラスターのデータベースアカウントとパスワードを持っていること。

  • 両方のクラスターが、ホットデータ/コールドデータ に対して同じ階層型ストレージポリシーを持っていること。

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

    説明

    SELECT * FROM system.clusters; コマンドを実行すると、Alibaba Cloud ClickHouse インスタンスの IP アドレスを確認できます。 ホワイトリストの設定方法については、「ホワイトリストを構成する」をご参照ください。

• 移行先クラスターは、さらに次の要件を満たす必要があります。

  • バージョンが移行元クラスターのバージョン 以上 であること。最新バージョンについては、「コミュニティ互換エディション」をご参照ください。

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

• 移行元クラスターの各ローカルテーブルには、一意の分散テーブルが必要です。

ステップ 1: Kafka/RabbitMQ エンジンテーブルの記録とクリーンアップ

移行を開始する前に、移行元クラスター内のすべての Kafka/RabbitMQ エンジンテーブルとその下流のマテリアライズドビューの定義を記録し、暗黙的なテーブルを処理してから、これらのテーブルを削除して移行エラーを回避します。

1. 移行元クラスターにログインし、すべての Kafka および RabbitMQ エンジンテーブルとその下流の依存関係をクエリします。

   /*
   create_table_query: テーブル定義
   dependencies_database: このテーブルが依存するテーブルのデータベース
   dependencies_table: このテーブルに依存するテーブル
   dependencies_database と dependencies_table から、Kafka/RabbitMQ テーブルに依存するマテリアライズドビューを特定できます
   */
   SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');

2. マテリアライズドビューの定義を表示して、そのターゲットテーブルが暗黙的なテーブルであるかどうかを確認します。

   /*
   マテリアライズドビューの定義を表示します。
   マテリアライズドビューのターゲットテーブルが暗黙的なテーブルである場合は、特に注意が必要です：
   マテリアライズドビューを削除すると、暗黙的なテーブルも削除され、データが失われます。
   例: CREATE MATERIALIZED VIEW [db.]table_name [TO[db.]name] で TO が指定されていない場合、
   システムは自動的に暗黙的なテーブルを作成します。形式は '.inner_id.<TABLE_UUID>' または '.inner.<TABLE>' の可能性があります。
   */
   SELECT * FROM system.tables WHERE database='<DATABASE>' AND name = '<MATERIALIZED_VIEW_NAME>';

3. マテリアライズドビューのターゲットテーブルが暗黙的なテーブルである場合、後でマテリアライズドビューが削除されたときにデータが失われるのを防ぐために、ターゲットテーブルを新しい名前に RENAME します。

   -- データを保護するために、暗黙的なターゲットテーブルを新しい名前に変更します
   RENAME TABLE <DATABASE>.`.inner_id.<TABLE_UUID>` TO <DATABASE>.<new_target_table_name>;

4. Kafka/RabbitMQ エンジンテーブルとその下流のマテリアライズドビューを削除します。

   -- 最初にマテリアライズドビューを削除します
   DROP TABLE <DATABASE>.<MATERIALIZED_VIEW_NAME>;
   -- 次に Kafka/RabbitMQ エンジンテーブルを削除します
   DROP TABLE <DATABASE>.<KAFKA_OR_RABBITMQ_TABLE_NAME>;

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

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

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

3. 左側メニューで、データの移行と同期 > インスタンスの移行 をクリックします。

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

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

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

      説明

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

      

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

      移行内容を確認し、次: 同期の事前検出と開始 をクリックします。

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

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

      • 事前チェックが成功した場合：

        1. 移行中のインスタンスへの影響を確認します。

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

           説明

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

           • 高い成功率を確保するため、書き込み停止期間を少なくとも 30 分に設定することを推奨します。

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

           • 業務への影響を最小限に抑えるため、書き込み停止期間をオフピーク時間に設定することを推奨します。

        3. 終了 をクリックします。

           説明

           このボタンをクリックすると、タスクが作成され、開始されます。

      • 事前チェックが失敗した場合は、プロンプトに従って問題を解決し、データ移行を再試行してください。以下の表に、事前チェック項目とその要件を示します。

        チェック項目	要件
        [インスタンスステータスの検出]	移行元または移行先クラスターで、スケーリングや設定変更などの管理タスクが実行されていないことを確認してください。タスクが進行中の場合、移行を開始することはできません。
        [ストレージスペースの検出]	移行先クラスターの使用可能なストレージ容量は、移行元クラスターの使用済みストレージ容量の 1.2 倍以上である必要があります。
        [ローカルおよび分散テーブルの検出]	移行元クラスターのローカルテーブルに対応する分散テーブルがない場合、または分散テーブルが一意でない場合、チェックは失敗します。余分な分散テーブルを削除するか、各ローカルテーブルに一意の分散テーブルを作成する必要があります。

ステップ 3: 移行完了の評価

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

移行元クラスターの書き込み速度が 20 MB/s を超える 場合は、移行が完了できるか評価するために、移行先クラスターの実際の書き込み速度を確認する必要があります。移行先クラスターの書き込み速度は、移行元クラスターの書き込み速度に追いつく必要があります。そのためには、次の手順を実行します。

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

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

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

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

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

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

2. 左側メニューで、データの移行と同期 > インスタンスの移行 をクリックします。

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

   説明

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

   • トリガー時間が設定された書き込み停止期間 内 である場合、移行元クラスターへの書き込みが停止されます。

   • トリガー時間が設定された書き込み停止期間 外 であるが、タスク開始 (つまり、タスク作成) 日 + 5 日 以前 である場合、書き込み停止期間を変更して移行を続行できます。

   • トリガー時間が設定された書き込み停止期間 外 であり、タスク開始 (つまり、タスク作成) 日 + 5 日 より後 である場合、移行は失敗します。移行タスクをキャンセルし、移行先クラスターから移行済みデータをクリアして、新しい移行タスクを作成する必要があります。

   重要

   • 移行元クラスターに Kafka/RabbitMQ エンジンテーブルが含まれている場合：移行タスクが データ移行 フェーズ (つまり、テーブルスキーマの移行が完了) に入ったら、ステップ 5 を実行して移行元クラスターに Kafka/RabbitMQ エンジンテーブルを再構築することで、増分データのフローが再開され、移行先クラスターに同期されるようになります。

   • 設定された書き込み停止期間の直前に、ステップ 6 を実行して、移行元クラスター上の Kafka/RabbitMQ エンジンテーブルとその下流のマテリアライズドビューを削除し、書き込み停止期間中のメッセージのバックログによるデータ不整合を防ぎます。

ステップ 5: 移行元クラスターでの Kafka/RabbitMQ エンジンテーブルの再構築

移行タスクが データ移行 フェーズ (つまり、テーブルスキーマの移行が完了) に入った後、以前に保存した DDL 文を使用して、移行元クラスターに Kafka/RabbitMQ エンジンテーブルとその下流のマテリアライズドビューを再構築します。再構築されると、増分データフローが再開され、自動的に移行先クラスターに同期されます。

-- 移行元クラスターで Kafka/RabbitMQ エンジンテーブルを再構築します
CREATE TABLE <database>.<kafka_or_rabbitmq_table_name> (...)
ENGINE = Kafka/RabbitMQ
SETTINGS ...;

-- マテリアライズドビューを再構築します (名前変更後のターゲットテーブルを指します)
CREATE MATERIALIZED VIEW <database>.<materialized_view_name> TO <database>.<new_target_table_name>
AS SELECT ... FROM <database>.<kafka_or_rabbitmq_table_name>;

ステップ 6: 移行元クラスターでの Kafka/RabbitMQ エンジンテーブルの削除

設定された書き込み停止期間の直前に、移行元クラスター上の Kafka/RabbitMQ エンジンテーブルとその下流のマテリアライズドビューを削除して、増分データ書き込みを停止し、最終的なデータ同期の整合性を確保します。

-- 最初にマテリアライズドビューを削除します
DROP TABLE <database>.<materialized_view_name> ON CLUSTER default;

-- 次に Kafka/RabbitMQ エンジンテーブルを削除します
DROP TABLE <database>.<kafka_or_rabbitmq_table_name> ON CLUSTER default;

ステップ 7: 移行先クラスターでの Kafka/RabbitMQ エンジンテーブルの再構築

移行タスクが完了した後、以前に保存した DDL 文を使用して、移行先クラスターに Kafka/RabbitMQ エンジンテーブルとその下流のマテリアライズドビューを再構築し、増分データ消費パイプラインを復元します。

-- 移行先クラスターで Kafka/RabbitMQ エンジンテーブルを再構築します
CREATE TABLE <database>.<kafka_or_rabbitmq_table_name> (...)
ENGINE = Kafka/RabbitMQ
SETTINGS ...;

-- マテリアライズドビューを再構築します
CREATE MATERIALIZED VIEW <database>.<materialized_view_name> TO <database>.<new_target_table_name>
AS SELECT ... FROM <database>.<kafka_or_rabbitmq_table_name>;

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

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

2. 左側メニューで、データの移行と同期 > インスタンスの移行 をクリックします。

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

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

   説明

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

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

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

ステップ 9: (任意) 書き込み停止期間の変更

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

2. 左側メニューで、データの移行と同期 > インスタンスの移行 をクリックします。

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

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

   説明

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

5. を決定 をクリックします。