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

移行中

• 移行中、宛先クラスターではマージプロセスが一時停止されますが、セルフマネージドクラスターでは継続されます。

  説明

  移行タスクが長時間実行されると、宛先クラスターに過剰なメタデータが蓄積される可能性があります。移行タスクの実行期間は 5 日以内にすることを推奨します。5 日を超えるタスクは自動的にキャンセルされます。

• 宛先クラスターは default クラスターである必要があります。セルフマネージドクラスターが別の名前を使用している場合、サービスは分散テーブル内の cluster 定義を自動的に default に変換します。

移行範囲

• サポートされるオブジェクト

  • データベース、データディクショナリ、およびマテリアライズドビュー。

    • SQL で作成されたデータディクショナリは移行をサポートしますが、XML で作成されたものはサポートしません。

      これを確認するには、次のステートメントを実行します：SELECT * FROM system.dictionaries WHERE (database = '') OR isNull(database);。このステートメントが行を返す場合、XML を使用して作成されたデータディクショナリが存在することを示します。

    • データディクショナリが外部サービスにアクセスする場合、外部サービスが利用可能であり、かつクラスターがその許可リストに追加されていることを確認してください。データディクショナリのデータソースが現在の ClickHouse クラスター内の内部テーブルであり、定義内の HOST パラメーターが IP アドレスの場合、移行後に IP アドレスが変更されるため、ディクショナリへのアクセスが失敗する可能性があります。現在の ClickHouse クラスターの HOST を再確認し、データディクショナリを手動で再作成する必要があります。

  • テーブルスキーマ：Kafka および RabbitMQ エンジンテーブルを除くすべてのテーブルスキーマ。

  • データ：MergeTree ファミリーのテーブルからの増分データ移行。

• サポートされないオブジェクトおよびデータ

  • Kafka および RabbitMQ エンジンテーブルとそのデータ。

  • 外部テーブルやログテーブルなど、非 MergeTree テーブルのデータ。

  重要

  上記のサポートされない項目は、手動で移行する必要があります。

• データ量の制限

  • コールドデータ：コールドデータの移行は低速です。長時間の移行による失敗を防ぐため、セルフマネージドクラスターからコールドデータをクリアし、合計データ量が 1 TB を超えないようにすることを推奨します。

  • ホットデータ：ホットデータの量が 10 TB を超える場合、移行タスクが失敗する可能性が高くなります。

  データ量がこれらの制限を超える場合は、代わりに手動移行ソリューションをご検討ください。

ステップ 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：宛先クラスターの互換性を設定する

ステップ 3：（任意）MaterializedMySQL エンジンを有効化する

セルフマネージドクラスターに MaterializedMySQL エンジンを使用するテーブルが含まれている場合は、次のステートメントを実行してこのエンジンを有効化します。

SET GLOBAL allow_experimental_database_materialized_mysql = 1;

ステップ 4：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>;

ステップ 5：データ移行タスクの作成

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

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

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

4. 移行タスクページで、移行タスクの作成をクリックします。

   1. ソースインスタンスと宛先インスタンスを設定します。

      次の設定を構成し、次のステップの接続をテストしますをクリックします。

      説明

      接続テストが成功した場合は、次のステップに進んでください。接続テストが失敗した場合は、表示されるプロンプトに基づいてソースおよび宛先インスタンスを再設定してください。

      

      ソースクラスターパラメーター

      パラメーター	説明	例
      ソースアクセスモード	専用回線 / VPN Gateway / Smart Gateway / ESC セルフマネージド ClickHouseを選択します。	専用回線 / VPN Gateway / Smart Gateway / ESC セルフマネージド ClickHouse
      クラスター名	ソースクラスターの名前。 名前には数字と小文字のみを使用できます。	source
      配信元インスタンスクラスター名	SELECT * FROM system.clusters; を実行して、配信元インスタンスクラスター名を取得します。	default
      VPC IP アドレス	クラスター内の各シャードの IP アドレスとポート (TCP アドレス) をカンマ区切りで指定します。 重要 ApsaraDB for ClickHouse クラスターの VPC ドメイン名または SLB アドレスは使用できません。 形式：IP:PORT,IP:PORT,...... クラスターの IP アドレスとポートを取得する方法は、データ移行のシナリオによって異なります。 クロスアカウントまたはクロスリージョン移行 次の SQL ステートメントを使用して、セルフマネージドクラスターの IP アドレスとポートを取得できます。 SELECT shard_num, replica_num, host_address as ip, port FROM system.clusters WHERE cluster = 'default' and replica_num = 1; ここで、replica_num=1 は最初のレプリカセットを選択します。他のレプリカセットを選択したり、各シャードから 1 つのレプリカを選択することもできます。 Alibaba Cloud 以外の ClickHouse 移行 IP アドレスを Alibaba Cloud に簡単にマッピングできない場合は、次の 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 つのレプリカを選択することもできます。 IP アドレスとポートがネットワーク変換を通じて Alibaba Cloud にマッピングされている場合は、対応するマッピング済みの IP アドレスとポートを設定する必要があります。	192.168.0.5:9000,192.168.0.6:9000
      データベースアカウント	ソースクラスターのデータベースアカウント。	test
      データベースパスワード	ソースクラスターのデータベースアカウントのパスワード。	test******

      宛先クラスターパラメーター

      パラメーター	説明	例
      データベースアカウント	宛先クラスターのデータベースアカウント。	test
      データベースパスワード	宛先クラスターのデータベースアカウントのパスワード。	test******

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

      ページに表示される移行対象データの情報を慎重に確認し、次: 同期の事前検出と開始をクリックします。

   3. システムはバックグラウンドで移行リンクの事前チェックを実行し、タスクを開始します。

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

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

        事前チェック成功後のページを次に示します。

        

        1. データ移行プロセスがインスタンスに与える影響を慎重に確認します。

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

           重要

           • [完了] をクリックすると、システムがタスクを作成して開始し、ステータスが「実行中」に変化します。タスクリストでタスクを確認できます。

           • タスク作成後は、タスクを監視する必要があります。移行の最終段階では、セルフマネージドクラスターへの書き込み操作を停止し、残りのデータベースおよびテーブルスキーマを移行する必要があります。詳細については、「移行タスクの監視とセルフマネージドクラスターへの書き込み停止」をご参照ください。

      • 事前チェックが失敗した場合：エラーメッセージの指示に従って、データ移行タスクを再度実行します。事前チェック項目とその要件を次の表に示します。事前チェックのエラーメッセージとその解決策の詳細については、「移行事前チェックエラーと解決策」をご参照ください。

        チェック項目	要件
        インスタンスステータスの検出	ソースまたは宛先クラスターで管理タスク (スケールアウト、アップグレード、スペックダウンなど) が実行中の場合、データ移行タスクを開始できません。
        ストレージスペースの検出	宛先クラスターの利用可能なストレージ容量は、セルフマネージドクラスターの使用済みストレージ容量の少なくとも 1.2 倍である必要があります。
        ローカルおよび分散テーブルの検出	セルフマネージドクラスターのローカルテーブルに対応する分散テーブルが存在しない、または複数存在する場合、チェックは失敗します。これを解決するには、余分な分散テーブルを削除するか、ローカルテーブルに対して一意の分散テーブルを作成してください。

ステップ 8：セルフマネージドクラスターでの 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>;

ステップ 9：書き込み停止と切り替え

推定残り移行時間が 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 句でリネーム後のターゲットテーブルを指定してください。

   -- 宛先クラスターで 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. 宛先クラスターのデータパイプラインが正常に動作しており、データが正常に流入していることを確認します。

ステップ 10：移行の完了

セルフマネージドクラスターへの書き込みを停止した後、Complete the taskできます。このステップにより、残りのデータが移行され、データ量チェックが実行され、残りのデータベースおよびテーブルスキーマが移行されます。タスク詳細で移行された内容を確認できます。

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

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

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

4. 対象の移行タスクの 操作 列で、移行完了 をクリックします。

5. 移行完了 ダイアログボックスで、を決定 をクリックします。

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

移行タスクでは、非 MergeTree テーブル (外部テーブルやログテーブルなど) のテーブルスキーマのみが移行され、宛先クラスターにビジネスデータなしで作成されます。ビジネスデータは手動で移行する必要があります。次の手順を実行してください。

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 関数を使用してテーブルデータを移行します。詳細な手順については、「remote 関数を使用したデータ移行」をご参照ください。

その他の操作

移行タスクが完了すると、移行ステータス が 完了 に変化します。タスクリストは即座に更新されないため、最新のステータスを確認するには定期的にページをリフレッシュしてください。

方法 1：BACKUP および RESTORE コマンドの使用

詳細については、「BACKUP および RESTORE コマンドを使用したデータのバックアップと復元」をご参照ください。

方法 2：INSERT FROM SELECT ステートメントの使用