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'; // プロファイルを変更します。

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

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

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

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

4. ソースおよびターゲットインスタンスの選択

   パラメーター	説明	例
   タスク名	移行タスクの名前です。名前には大文字、小文字、数字のみ使用できます。名前は一意である必要があり、大文字と小文字は区別されません。	MigrationTask1229
   配信元インスタンスクラスター名	セルフマネージドインスタンスのクラスター名は、SELECT * FROM system.clusters; を実行することで取得できます。	default
   VPC IP アドレス	クラスター内の各シャードの IP および PORT アドレスはカンマで区切ります。形式： IP:PORT,IP:PORT,.... セルフマネージドクラスターの IP アドレスおよびポートを取得するには、以下の SQL ステートメントを使用します： 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 アドレスおよびポートを指定します。	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. データベースおよびテーブルスキーマの確認

   1. 確認の開始 をクリックします。

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

   3. 確認が完了したら、結果に応じて後続の操作を実行します。

      確認結果の説明については、ステップ 6 をご参照ください。

8. データベースおよびテーブルスキーマの移行

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

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

   3. 確認が完了したら、結果に応じて後続の操作を実行します。

      確認結果の説明については、ステップ 6 をご参照ください。

9. （任意）SQL 互換性の確認

   SQL 互換性チェックでは、セルフマネージドインスタンスから取得した SQL ステートメントをターゲットインスタンスで再生し、異なるカーネルバージョン間の構文互換性を検証します。このステップを実行するかどうかは、お客様のニーズに応じて決定できます。

   • このステップをスキップする場合は、スキップ をクリックします。

   • このステップを実行する場合は、リクエスト再生時間 を選択し、その後 確認の開始 をクリックします。チェックが通過した場合は、次のステップ をクリックします。チェックが失敗した場合は、ステップ 6 を参照して対応してください。

     重要

     • このチェックは構文互換性のみを検証し、インスタンスのデータベースおよびテーブル内のデータを必要としません。データが必要な場合は、まず次のステップに進んで一部のデータを移行できます。

     • SQL を再生するクライアントのバージョンがターゲットインスタンスと一致していない場合、誤検知が発生する可能性があります。例外が発生した場合は、SQL ステートメントを手動で実行してエラーを確認してください。

10. 同期の開始

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

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

       同期プロセス中は、停止、再開、移行のキャンセル の各操作を使用して移行フローを制御できます。各操作の説明および影響を表示するには、こちらをクリックしてください。

       操作	機能	影響	利用シーン
       停止	データ移行を直ちに停止し、残りのデータベースおよびテーブルスキーマを移行します。	データが完全に移行されない可能性があります。 移行を再開する前に、重複データを回避するために、ターゲットクラスターから既に移行されたデータをクリアする必要があります。	すべてのデータが移行された後に、移行タスクを能動的に停止する場合。 一部のデータが移行された後に、セルフマネージドクラスターへの書き込みを停止せずに移行をテストする場合。
       再開	他のデータベース／テーブルのチェックおよびクリーンアップ、データの移行、残りのスキーマの移行中に例外が発生した場合、エラーメッセージに基づいて問題を解決できます。この操作により、現在のステップが再試行され、その後のステップが続行されます。	なし	プロセス中に発生した例外を解決した後、ブレークポイントから移行を再開する場合。
       移行のキャンセル	タスクを強制的にキャンセルし、すべての後続ステップをスキップします。 重要 移行をキャンセルした後、移行タスクはロックされ、移行フローの変更ができなくなります。移行ステップの実行結果を表示するには、前のステップ、次のステップ、または リフレッシュ ボタンを使用できます。	移行タスクが強制終了されます。ターゲットインスタンスのデータベースおよびテーブルスキーマ、および構成が不完全になる可能性があり、ビジネス運用には使用できません。 移行を再開する前に、重複データを回避するために、ターゲットクラスターから既に移行されたデータをクリアする必要があります。	移行タスクがセルフマネージドクラスターに影響を与えている場合に、迅速に移行を終了し、書き込みを再開する場合。

    3. データの移行 ステップが実行中の場合、データの移行 タブに切り替え、 ボタンをクリックして 移行の進行状況 および 残り推定時間 を表示します。

       移行が完了可能かどうかを評価する方法を表示するには、こちらをクリックしてください。

       移行が成功するかどうかは、移行速度とセルフマネージドクラスターの書き込み速度の関係によって決まります。

       • 以下の表は、当社のテストから得られた移行速度のデータです：

         平均パートサイズ	ソースインスタンスタイプ	ソースディスクタイプ	ターゲットインスタンスタイプ	ターゲットストレージメディア	クラスターノード数	単一ノード移行速度	全体移行速度
         402.54 MB	8C32G	PL1	16CCU	OSS	16	47 MB/s	752.34 MB/s
         402.54 MB	80C384G	PL3	48CCU	ESSD_L2	8	197.74 MB/s	1581.95 MB/s

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

         データ移行速度は、パートサイズ（当社のテストでは、平均パートサイズが 100 MB ～ 10 GB の場合、移行速度が高くなりました）、インスタンスタイプ、ディスクタイプ、およびビジネスデータの特性 などの要因に依存します。したがって、テストデータは参考用です。ターゲットクラスターの実際の書き込み速度を判定するには、ディスクスループット を確認する必要があります。「ディスクスループット の確認方法」については、「クラスター監視情報の表示」をご参照ください。

         • ターゲットクラスターの書き込み速度がセルフマネージドクラスターの書き込み速度より遅い場合、移行は失敗する可能性があります。移行タスクをキャンセルし、代わりに手動移行をご利用ください。

         • ターゲットクラスターの書き込み速度がセルフマネージドクラスターの書き込み速度より速い場合、後続のステップを続行できます。移行の成功確率を高めるため、移行に必要な時間（データ量 / （移行速度 - セルフマネージドインスタンスの書き込み速度））を5 日以内に収めるよう推奨します。

       重要

       • 移行の進行状況 をターゲットタスクで厳密に監視する必要があります。残り推定時間 を基に、セルフマネージドクラスターへの書き込みを停止し、Kafka および RabbitMQ エンジンのテーブルを処理します。

       • 現在の最大移行時間しきい値は5 日に設定されています。移行が5 日間継続した場合、システムが移行タスクを自動的にキャンセルします。移行タスクにさらに長い時間がかかる場合は、技術サポートに連絡するためチケットを送信してください。

       セルフマネージドクラスターへの書き込みをいつ停止するかを推定する方法を表示するには、こちらをクリックしてください。

       ビジネストラフィックを切り替える前に、移行後のデータ整合性を保証するために、セルフマネージドインスタンスへの新しいデータの書き込みを停止する必要があります。このため、ビジネス書き込みを停止し、Kafka および RabbitMQ テーブルを削除します。手順は以下のとおりです：

       1. セルフマネージドクラスター にログインし、処理が必要なテーブルを照会するための以下のステートメントを実行します：

          SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');

       2. ターゲットテーブルの CREATE TABLE ステートメントを表示します。

          SHOW CREATE TABLE <aim_table_name>;

       3. 「ターゲットクラスターへの接続」を行い、前のステップで取得した CREATE TABLE ステートメントを実行します。

       4. セルフマネージドクラスター にログインし、移行済みの Kafka および RabbitMQ エンジンのテーブルを削除します。

          重要

          Kafka テーブルを削除する場合、それを参照するマテリアライズドビューも削除する必要があります。そうしないと、マテリアライズドビューが移行できず、移行全体が失敗します。

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

       

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

       重要

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

ステップ 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. [ターゲットクラスター] にログオンし、データ移行 を [リモート関数] を使用して実行します。