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'); // compatibility 設定の値を確認します。
ALTER PROFILE XXXX SETTINGS compatibility = '23.8'; // compatibility の値を設定します。

ステップ 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 関数を使用してデータを移行します。