ApsaraDB for ClickHouse:セルフマネージド ClickHouse から ApsaraDB for ClickHouse Enterprise Edition への移行

注意事項

ステップ 1：クラスターの確認とシステムテーブルの有効化

データ移行を開始する前に、セルフマネージドクラスターの config.xml ファイルを設定して増分移行を有効にします。設定は、system.part_log および system.query_log システムテーブルがすでに有効になっているかどうかによって異なります。

<part_log>
    <database>system</database>
    <table>part_log</table>
    <partition_by>event_date</partition_by>
    <order_by>event_time</order_by>
    <ttl>event_date + INTERVAL 15 DAY DELETE</ttl>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</part_log>

<query_log>
    <database>system</database>
    <table>query_log</table>
    <partition_by>event_date</partition_by>
    <order_by>event_time</order_by>
    <ttl>event_date + INTERVAL 15 DAY DELETE</ttl>
    <flush_interval_milliseconds>7500</flush_interval_milliseconds>
</query_log>

ステップ 2：クラスターの互換性の設定

ターゲットクラスターがセルフマネージドクラスターと可能な限り互換性を持つようにするため、「ターゲットクラスターへの接続」を参照してターゲットクラスターに接続し、compatibility パラメーターをセルフマネージドクラスターのバージョンに合わせて変更します。

例：

SELECT currentProfiles(); // 現在のプロファイル名を取得します。
SELECT
    profile_name,
    setting_name,
    value
FROM system.settings_profile_elements
WHERE (setting_name = 'compatibility') AND (profile_name = 'xxxx'); // 互換性設定の値を確認します。
ALTER PROFILE XXXX SETTINGS compatibility = '23.8'; // 互換性の値を設定します。

ステップ 3：移行タスクの作成

1. ApsaraDB for ClickHouse コンソールにログインします。クラスターリスト ページで、Enterprise Edition インスタンスのリスト を選択し、ターゲットクラスターの ID をクリックします。

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

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

4. ソースインスタンスとターゲットインスタンスの選択

   パラメーター	説明	例
   タスク名	移行タスクの一意の名前。大文字と小文字は区別されません。名前には英字と数字のみ使用できます。	MigrationTask1229
   配信元インスタンスクラスター名	SELECT * FROM system.clusters; を実行して、ご利用のセルフマネージドクラスターのクラスター名を取得します。	default
   VPC IP アドレス	クラスター内の各シャードの IP アドレスとポートをカンマで区切って入力します。形式：IP:PORT,IP:PORT,.... 次の SQL ステートメントを使用して、ご利用のセルフマネージドクラスターの IP アドレスとポートを取得できます。 SELECT shard_num, replica_num, host_address as ip, port FROM system.clusters WHERE cluster = '<cluster_name>' and replica_num = 1; パラメーターの説明： cluster_name：ご利用のセルフマネージドクラスターの名前。 replica_num=1 は最初のレプリカセットを選択します。別のレプリカセットを選択するか、各シャードから手動で 1 つのレプリカを選択することもできます。 重要 ClickHouse クラスターの VPC ドメイン名または SLB アドレスは使用できません。 NAT を使用して IP アドレスとポートを Alibaba Cloud にマッピングする場合、ご利用のネットワーク設定に従って、マッピングされた IP アドレスとポートを設定する必要があります。	192.168.0.5:9000,192.168.0.6:9000
   データベースアカウント	セルフマネージドクラスターのデータベースアカウント。	test
   データベースパスワード	セルフマネージドクラスターのデータベースアカウントのパスワード。	test******
   ソースインスタンスのカーネルバージョン	バージョン取得 をクリックします。	22.8.5.29

5. ソースインスタンスのバージョンに基づいて、次のように進めます。

   • ソースインスタンスのバージョンが 22.10 以降の場合：次のステップ をクリックします。

   • ソースインスタンスのバージョンが 22.10 より前の場合：プロンプトに従って ターゲットインスタンス情報 を入力し、次のステップ をクリックします。

   • バージョンの取得に失敗した場合：これは、ソースインスタンス情報が正しくないか、ネットワークが切断されている場合に発生する可能性があります。プロンプトに従って問題を解決し、再度 バージョン取得 をクリックします。

   説明

   以前のコミュニティ版と Enterprise Edition の間のパラメーターの非互換性のため、ソースインスタンスのバージョンが 22.10 より前の場合、ソースからターゲットにデータをプッシュしてデータを同期する必要があります。このシナリオでは、ターゲットインスタンスの IP アドレスをセルフマネージドネットワークにマッピングする必要があります。セルフマネージドネットワークと Enterprise Edition インスタンスが同じ VPC 内にある場合、または VPC ピアリング接続を介して接続されている場合は、接続に元の IP アドレスを使用できます。

6. 接続性と設定の確認

   1. チェックの開始 をクリックします。

      このチェックでは、以下の項目が検証されます：

      • 接続性検証：セルフマネージドクラスターとターゲットインスタンスが完全なネットワーク接続を持ち、すべてのノードが相互にアクセスできることを検証します。

      • アカウント権限検証：ソースアカウントとパスワードが正しく、ソースインスタンスに接続できることを検証します。

      • ソースインスタンスのシステムテーブルチェック：セルフマネージドインスタンスに system.query_log、system.parts、および system.part_log システムテーブルがあることを検証します。

      • 設定チェック：セルフマネージドインスタンスとターゲットインスタンスが同じタイムゾーンを使用していること、およびターゲットインスタンスの compatibility パラメーターがソースインスタンスのバージョンと一致していることを検証します。

   2. チェック中に、右上隅の アイコンをクリックしてリアルタイムの進捗状況を確認できます。

   3. チェックが完了したら、結果に基づいて進めます。

      結果レベル と確認項目を選択し、 アイコンをクリックして対応する結果を表示できます。結果レベルは以下のように説明されます。

      • 成功：すべてのチェックに合格した場合、次のステップ をクリックして続行します。

      • 警告：これらは非ブロッキング項目です。警告がワークロードや移行タスクに影響するかどうかを手動で確認する必要があります。警告を無視するか、問題を解決して再度 チェックの開始 をクリックできます。

      • エラー：これらはブロッキング項目です。提供された情報を使用してエラーを解決し、再度 チェックの開始 をクリックする必要があります。

        エラーメッセージと解決策については、「よくある質問」をご参照ください。

7. データベースとテーブルの構造の確認

   接続性と設定のチェックに合格したら、データベースとテーブルの構造の確認に進みます。このステップは、移行するデータベースの選択、移行するテーブルの選択、データベースとテーブルの構造の確認の 3 つのサブステップで構成されます。

   重要

   移行するデータベースの選択と移行するテーブルの選択のサブステップはオプションです。ソースインスタンスからすべてのデータベースとテーブルを移行したい場合は、これら 2 つのサブステップをスキップして、直接サブステップ 3 (データベースとテーブルの構造の確認) に進むことができます。

   サブステップ 1：移行するデータベースの選択 (オプション)

   1. [ソースをクエリ] をクリックします。システムはソースインスタンス上のすべてのデータベースを自動的にクエリします。

   2. クエリ中に、[クエリ結果] をクリックしてリアルタイムの結果を表示できます。

   3. クエリが完了したら、ビジネス要件に基づいて移行するデータベースを選択します。選択が完了したら、[確認] をクリックします。

   サブステップ 2：移行するテーブルの選択 (オプション)

   1. データベースを選択すると、テーブルを選択するインターフェイスが表示されます。[ソースをクエリ] をクリックします。システムは選択されたデータベース内のすべてのテーブルを自動的にクエリします。

   2. クエリ中に、[クエリ結果] をクリックしてリアルタイムの結果を表示できます。

   3. クエリが完了したら、ビジネス要件に基づいて移行するテーブルを選択します。選択が完了したら、[確認] をクリックします。

   説明

   デフォルトでは、すべてのテーブルが選択されています。特定のテーブルのみを移行する必要がある場合は、対応するデータベースの全選択チェックボックスの選択を解除し、ドロップダウンリストを展開して必要なテーブルを選択します。

   サブステップ 3：データベースとテーブルの構造の確認

   1. チェックの開始 をクリックします。システムはデータベース構造、テーブル構造、および UDF をチェックして、ソースインスタンスとターゲットインスタンス間の非互換性を特定します。

   2. チェック中に、結果レベルと確認項目でフィルタリングし、更新アイコンをクリックしてリアルタイムの結果を表示できます。

   3. チェック結果は、成功、警告、エラーの 3 つのレベルに分類されます。

      • チェック成功：[次へ] をクリックして移行を続行します。

      • チェック中に警告が発生

        結果レベルを警告に設定し、対応する確認項目を見つけて警告の詳細を確認します。

        重要

        警告レベルの確認項目は非ブロッキングです。警告がワークロードや移行タスクに影響するかどうかを確認する必要があります。確認後、2 つの選択肢があります。

        • 警告を無視して [次へ] をクリックして移行を続行します。

        • 提供された詳細に基づいて警告を解決し、再度 チェックの開始 をクリックしてデータベースとテーブルの構造を再チェックします。警告メッセージと解決策については、このトピックのよくある質問セクションをご参照ください。

      • チェック失敗

        結果レベルをエラーに設定し、対応する確認項目を見つけてエラーの詳細を確認します。

        重要

        エラーレベルの確認項目はブロッキングです。提供された詳細に基づいてエラーを解決し、再度 チェックの開始 をクリックしてデータベースとテーブルの構造を再チェックする必要があります。エラーメッセージと解決策については、このトピックのよくある質問セクションをご参照ください。

8. データベースとテーブルの構造の移行

   1. 移行開始 をクリックします。

   2. 移行中に、右上隅の アイコンをクリックしてリアルタイムの進捗状況を確認できます。

   3. 移行が完了したら、結果に基づいて進めます。

      結果については、ステップ 5 をご参照ください。

9. (オプション) SQL 互換性の確認

   SQL 互換性チェックは、セルフマネージドインスタンスからの SQL ステートメントをターゲットインスタンスでリプレイし、異なるカーネルバージョン間の構文の互換性を検証します。

   • このステップをスキップするには、互換性検証をスキップ をクリックします。

   • このチェックを実行するには、リクエストリプレイ時間 を選択し、チェックの開始 をクリックします。チェックに合格した場合は、次のステップ をクリックします。チェックに失敗した場合は、ステップ 5 の解決策をご参照ください。

     重要

     • インスタンスのデータベースとテーブルにはデータが含まれていないため、このチェックは構文の互換性のみを検証します。データを使用してテストするには、次のステップで一部のデータを移行できます。

     • SQL リプレイに使用されるクライアントバージョンとターゲットインスタンスの不一致により、誤検知が発生する可能性があります。エラーが発生した場合は、SQL ステートメントを手動で実行して結果を検証してください。

10. 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 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>;

    重要

    記録したすべての DDL ステートメントを必ず保存してください。後でセルフマネージドクラスターとターゲットクラスターの両方でこれらのテーブルを再作成するために必要になります。RENAME 操作を実行した場合は、マテリアライズドビューを再作成する際に TO 句を使用して、名前が変更されたターゲットテーブルを指すようにしてください。

11. 同期の開始

    1. 同期の開始 をクリックします。

    2. 同期中に、右上隅の アイコンをクリックしてリアルタイムの進捗状況を確認できます。

       同期中に、停止、再起動、および 移行のキャンセル 操作を使用して移行プロセスを制御できます。クリックしてこれらの操作の詳細を表示します。

       アクション	説明	影響	ユースケース
       停止	データ移行を直ちに停止し、残りのデータベースとテーブル構造の移行に進みます。	データが完全に移行されない可能性があります。 移行を再開する前に、データの重複を避けるために、ターゲットクラスターから移行済みのデータをクリアする必要があります。	すべてのデータが移行された後、手動で移行タスクを停止する場合。 セルフマネージドクラスターへの書き込みを停止せずに、部分的なデータ移行でテストする場合。
       再起動	チェックまたは移行ステップ中にエラーが発生した場合、問題を解決した後に失敗したステップを再試行します。	なし	移行エラーを解決した後、失敗した時点からタスクを再開する場合。
       移行をキャンセル	タスクを強制的にキャンセルし、後続のすべてのステップをスキップします。 重要 キャンセル後、移行タスクはロックされ、移行プロセスを変更できなくなります。前のステップ、次のステップ、または リフレッシュ ボタンを使用して、完了したステップの結果を表示できます。	移行タスクは強制的に終了されます。ターゲットインスタンスのデータベースとテーブルの構造および設定が不完全になり、本番ワークロードには使用できなくなる可能性があります。 移行を再開する前に、データの重複を避けるために、ターゲットクラスターから移行済みのデータをクリアする必要があります。	移行タスクがセルフマネージドクラスターに悪影響を及ぼしており、書き込みを再開するために迅速に終了する必要がある場合。

    3. セルフマネージドクラスターで、以前に保存した DDL ステートメントを使用して、Kafka/RabbitMQ エンジンテーブルとその下流のマテリアライズドビューを再作成します。再作成後、増分データは再び流れ込み、ターゲットクラスターに自動的に同期されます。

       重要

       以前に暗黙的なターゲットテーブルに対して RENAME 操作を実行した場合は、マテリアライズドビューを再作成する際に TO 句を使用して、名前が変更されたターゲットテーブルを指すようにしてください。詳細については、「CREATE MATERIALIZED VIEW」をご参照ください。

       CREATE MATERIALIZED VIEW [db.]table_name [TO[db.]name]

       。

       -- セルフマネージドクラスターで 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>;

    4. プロセスが データを移行する ステージに達したら、データを移行する タブに切り替え、 アイコンをクリックして 移行の進行状況 と 推定残り時間 を表示します。

       移行が完了可能かどうかの評価

       移行の成功は、セルフマネージドクラスターの書き込み速度に対する移行速度に依存します。

       • 以下の表は、移行速度のテストデータを提供します：

         平均パートサイズ	ソースインスタンスタイプ	ソースディスクタイプ	ターゲットインスタンスタイプ	ターゲット記憶媒体	クラスターノード	シングルノード速度	全体的な移行速度
         402.54MB	8C32G	PL1	16CCU	OSS	16	47MB/s	752.34MB/s
         402.54MB	80C384G	PL3	48CCU	ESSD_L2	8	197.74MB/s	1581.95MB/s

       • ターゲットクラスターとセルフマネージドクラスターの書き込み速度を比較します：

         データ移行速度は、パートサイズ (テストでは、平均パートサイズが 100 MB から 10 GB の間で高速な移行速度が観測されました)、インスタンスタイプ、ディスクタイプ、およびワークロードの特性などの要因に依存します。したがって、テストデータは参考用です。ターゲットクラスターの実際の書き込み速度を判断するには、そのディスクスループットを確認してください。ディスクスループットの表示方法については、「クラスターのモニタリング情報の表示」をご参照ください。

         • ターゲットクラスターの書き込み速度がセルフマネージドクラスターよりも遅い場合：移行は失敗する可能性が高いです。タスクをキャンセルし、手動移行を実行することを推奨します。

         • ターゲットクラスターの書き込み速度がセルフマネージドクラスターよりも速い場合：成功率を向上させるために、移行時間 (データ量 / (移行速度 - セルフマネージドクラスターの書き込み速度)) が 5 日以内であることを確認することを推奨します。

       重要

       • 移行の進行状況 を注意深く監視する必要があります。推定残り時間 に基づいて、セルフマネージドクラスターへの書き込みを積極的に停止し、Kafka および RabbitMQ エンジンを使用するテーブルを処理する必要があります。

       • バックグラウンドプロセスは、5 日を超えて実行されるタスクを自動的にキャンセルします。移行タスクにさらに時間が必要な場合は、チケットを送信してしきい値の調整をリクエストしてください。

       セルフマネージドクラスターへの書き込み停止と切り替えのタイミングの見積もり

       推定移行時間が 10 分未満になるか、移行の進捗が 99% に達したら、以下の操作を実行して切り替えを完了します。

       1. ビジネスの書き込みを停止します。セルフマネージドクラスターで、以前に再作成した Kafka/RabbitMQ エンジンテーブルとその下流のマテリアライズドビューを削除します。

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

       2. 移行の進捗が 100% に達し、移行が完全に完了するのを待ちます。

       3. ターゲットクラスターに接続し、以前に保存した DDL ステートメントを使用して、Kafka/RabbitMQ エンジンテーブルとその下流のマテリアライズドビューを再作成します。

          重要

          以前に暗黙的なターゲットテーブルに対して RENAME 操作を実行した場合は、マテリアライズドビューを再作成する際に TO 句を使用して、名前が変更されたターゲットテーブルを指すようにしてください。詳細については、CREATE MATERIALIZED VIEW をご参照ください。

          -- ターゲットクラスターで 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>;

       4. ターゲットクラスターのデータパイプラインが正常に機能し、データが期待どおりに流れ込んでいることを確認します。

    5. 移行の進行状況 が 100% に達し、ソースインスタンスへの書き込みが停止したことを確認したら、停止 をクリックしてデータ移行を終了し、次のステップに進みます。

       

    6. 同期が完了したら、終了 をクリックします。

       重要

       同期の開始ステップが完了すると、移行タスクはロックされ、移行プロセスを変更できなくなります。前のステップ、次のステップ、または リフレッシュ ボタンを使用して、完了したステップの結果を表示することはできます。

ステップ 4：非 MergeTree テーブルのデータ移行

移行タスク中、非 MergeTree テーブルはテーブル構造の移行のみをサポートするか (例：MySQL テーブル)、移行を全くサポートしません (例：Log テーブル)。したがって、移行タスクが完了した後、ターゲットクラスターには構造はあるがビジネスデータがないテーブルが含まれる可能性があります。次のようにビジネスデータを手動で移行する必要があります。

1. セルフビルドクラスターにログインし、データ移行が必要な非 MergeTree テーブルを特定します。

   SELECT
       `database` AS database_name,
       `name` AS table_name,
       `engine`
   FROM `system`.`tables`
   WHERE (`engine` NOT LIKE '%MergeTree%') AND (`engine` != 'Distributed') AND (`engine` != 'MaterializedView') AND (`engine` NOT IN ('Kafka', 'RabbitMQ')) AND (`database` NOT IN ('system', 'INFORMATION_SCHEMA', 'information_schema')) AND (`database` NOT IN (
       SELECT `name`
       FROM `system`.`databases`
       WHERE `engine` IN ('MySQL', 'MaterializedMySQL', 'MaterializeMySQL', 'Lazy', 'PostgreSQL', 'MaterializedPostgreSQL', 'SQLite')
   ))

2. ターゲットクラスターにログインし、remote 関数を使用してデータを移行します。