ApsaraDB for ClickHouse:自社運用 ClickHouse クラスターから ApsaraDB for ClickHouse Enterprise Edition へのデータ移行

注意事項

ステップ1：自社運用クラスターのチェックとシステムテーブルの有効化

データ移行の前に、増分移行をサポートするために、自社運用クラスターで system.part_log と system.query_log が有効になっているかどうかに基づいて config.xml ファイルを変更します。

<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. ソースインスタンスと移行先インスタンスの選択

   設定項目	説明	例
   タスク名	タスク名には英字および数字のみを使用できます。名前は大文字と小文字を区別しない（case-insensitive）ものであり、一意である必要があります。	MigrationTask1229
   配信元インスタンスクラスター名	自己管理型インスタンスのクラスター名を取得するには、SELECT * FROM system.clusters; を実行します。	default
   VPC IP アドレス	クラスター内の各シャードの IP アドレスとポートをカンマで区切って指定します。形式： 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 アドレスは使用しないでください。 Alibaba Cloud で IP およびポートのマッピングが適用されている場合は、ネットワーク接続状況に応じてマップされた 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 の3つのシステムテーブルが必要です。

      • 構成チェック：自社運用インスタンスと移行先インスタンスのタイムゾーンが同じであること、および移行先インスタンスの compatibility 設定がソースのバージョンと一致していること。

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

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

      [結果レベル] とチェック項目を選択し、 ボタンをクリックして詳細を表示します。結果は次のように解釈されます：

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

      • 警告：これらはブロッキングではない問題です。ビジネスや移行に影響があるかどうかを確認してください。警告を無視するか、問題を修正して再度 [チェック開始] をクリックして再チェックできます。

      • エラー：これらはブロッキングの問題です。エラーを修正し、再度 [チェック開始] をクリックして再チェックしてください。

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

7. データベースとテーブルスキーマのチェック

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

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

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

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

8. データベースとテーブルスキーマの移行

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

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

   3. 検査が完了したら、検査結果に基づいて次のステップに進むことができます。

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

9. (オプション) SQL 互換性のチェック

   SQL 互換性チェックは、自社運用インスタンスの SQL 文を移行先インスタンスで再生し、カーネルバージョン間の構文の互換性を検証します。必要に応じてこのステップを実行するかどうかを決定してください。

   • スキップする場合は、[スキップ] をクリックします。

   • チェックを実行する場合は、[リクエスト再生時間] を選択し、[チェック開始] をクリックします。チェックが成功したら、次のステップ をクリックします。チェックに失敗した場合は、ステップ5の解決策をご参照ください。

     重要

     • このチェックは構文の互換性のみを検証し、データは必要ありません。データを使用してテストするには、次のステップで部分的なデータを先に移行してください。

     • クライアントのバージョンが移行先インスタンスと一致しないために、誤検知が発生する可能性があります。必要に応じて SQL 文を手動で検証してください。

10. 同期の開始

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

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

       移行プロセスは、[停止]、[再起動]、[移行をキャンセル] の操作で制御できます。クリックして操作の意味と影響を確認してください。

       操作	機能定義	影響	シナリオ
       停止	データ移行を直ちに停止しますが、残りのテーブルスキーマの移行は続行します。	一部のデータが完全に移行されない可能性があります。 移行を再開する前に、重複を避けるために移行先クラスターの移行済みデータをクリーンアップしてください。	完全なデータ移行後に移行タスクを停止する。 自社運用クラスターへの書き込みを停止せずに、部分的なデータ移行後にテストする。
       再起動	スキーマまたはデータ移行中に発生したエラーを解決した後、現在のステップを再試行します。	なし	エラーを修正した後、ブレークポイントから移行を再開する。
       移行をキャンセル	タスクを強制的にキャンセルし、後続のステップをスキップします。 重要 キャンセル後、移行タスクはロックされ、変更できなくなります。前のステップ、次のステップ、または リフレッシュ ボタンを使用してステップの結果を表示します。	移行は終了します。移行先インスタンスには不完全なスキーマや構成が残る可能性があり、ビジネスには使用できません。 移行を再開する前に、重複を避けるために移行先クラスターの移行済みデータをクリーンアップしてください。	自社運用クラスターへの書き込みを再開するために、移行を迅速に終了する。

    3. プロセスが [データ移行] に達したら、[データ移行] タブに切り替え、 ボタンをクリックして 移行の進行状況 と [推定残り時間] を表示します。

       クリックして移行が完了できるかどうかを評価する方法を学びます。

       移行の成功は、移行速度と自社運用クラスターの書き込み速度の関係に依存します。

       • テスト移行速度は次のとおりです：

         平均 part サイズ	ソースインスタンスタイプ	ソースディスクタイプ	移行先インスタンスタイプ	宛先記憶媒体	クラスターノード数	ノードあたりの移行速度	全体の移行速度
         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

       • 移行先クラスターと自社運用クラスターの書き込み速度を比較します：

         移行速度は、part サイズ (テストでは、平均 part サイズが 100 MB から 10 GB の間で高速を維持)、インスタンスタイプ、ディスクタイプ、データ特性などの要因に依存します。したがって、テストデータは参考用です。移行先クラスターの実際の書き込み速度は、そのディスクスループットを監視して判断してください。詳細については、「クラスターの監視情報の表示」をご参照ください。

         • 移行先クラスターの書き込み速度が自社運用クラスターの書き込み速度より低い場合、移行の失敗率が高くなります。移行タスクをキャンセルし、手動移行を使用してください。

         • 移行先クラスターの書き込み速度が自社運用クラスターの書き込み速度より高い場合は、続行します。成功率を高めるために、データ量 / (移行速度 - 自社運用書き込み速度) として計算される移行期間が5日以下であることを確認してください。

       重要

       移行の進行状況 を注視します。[推定残り時間] に基づいて、セルフマネージドクラスターへの書き込みを停止し、Kafka および RabbitMQ エンジンテーブルを処理します。

       クリックして、自社運用クラスターへの書き込みを停止するタイミングを推定する方法を学びます。

       移行後のデータの完全性を確保するために、トラフィックの切り替え前にビジネスの書き込みを停止し、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. 移行先クラスターにログインし、remote 関数を使用してデータを移行します。