ApsaraDB for ClickHouse:自社運用 ClickHouse インスタンスから ApsaraDB for ClickHouse Community-Compatible Edition クラスターへのデータ移行

前提条件

• 移行先クラスター：

  • クラスターは Community-Compatible Edition クラスターであること。

  • データベースアカウントとパスワードがあること。ClickHouse アカウントの作成方法の詳細については、「Community-Compatible Edition クラスターのアカウント管理」をご参照ください。

  • アカウントに最高の権限が付与されていること。権限の付与方法の詳細については、「権限の変更」をご参照ください。

• 自社運用クラスター：

  • データベースアカウントとパスワードがあること。

  • アカウントには、データベースとテーブルに対する読み取り権限、および SYSTEM コマンドの実行権限が付与されていること。

• 移行先クラスターと自社運用クラスターがネットワーク経由で相互に通信できること。

  自社運用クラスターと移行先クラスターが同じ VPC 内にある場合、移行先クラスターのすべてのノードの IP アドレスと、その [VSwitch ID] の [IPv4 CIDR ブロック] を自社運用クラスターのホワイトリストに追加します。

  • ApsaraDB for ClickHouse でのホワイトリストの設定方法の詳細については、「ホワイトリストの設定」をご参照ください。

  • 自社運用クラスターのホワイトリストに IP アドレスを追加する方法については、関連するプロダクトドキュメントをご参照ください。

  • ApsaraDB for ClickHouse クラスターのすべてのノードの IP アドレスを表示するには、SELECT * FROM system.clusters; 文を実行します。

  • ApsaraDB for ClickHouse クラスターの [VSwitch ID] に関連付けられた [IPv4 CIDR] を取得するには、次のステップを実行します：

    1. ApsaraDB for ClickHouse コンソールで、移行先クラスターの [クラスター情報] ページに移動し、[ネットワーク情報] セクションから [VSwitch ID] を取得します。

    2. [vSwitch リスト] で、[VSwitch ID] を使用して移行先の vSwitch を検索し、その [IPv4 CIDR] を表示します。

  自社運用クラスターとクラウドクラスターが異なる VPC にある場合、または自社運用クラスターがローカルデータセンターや他のクラウドプラットフォームにある場合は、まずネットワーク接続の問題を解決する必要があります。詳細については、「移行先クラスターとデータソース間のネットワーク接続を確立する方法」をご参照ください。

移行の検証

データ移行を開始する前に、テスト環境を作成することを強く推奨します。この環境では、ビジネスの互換性とパフォーマンスを検証し、移行が正常に完了できることを確認できます。移行の検証が完了した後、本番環境でデータ移行を実行できます。これは、潜在的な問題を事前に特定して解決するのに役立つ重要なステップです。これにより、スムーズな移行プロセスが保証され、本番環境への不要な影響を防ぐことができます。

1. 移行タスクを作成してデータ移行を実行します。詳細な手順については、このトピックの「手順」セクションをご参照ください。

2. クラウド移行の互換性、パフォーマンスボトルネックの分析、および移行が完了できるかどうかの判断については、「自社運用 ClickHouse のクラウド移行における互換性とパフォーマンスボトルネックの分析と解決策」をご参照ください。

ソリューションの選択

手順

<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>

SET GLOBAL allow_experimental_database_materialized_mysql = 1;

移行チェックのエラーメッセージとソリューション

移行後のマージ時間の計算

移行後、移行先クラスターでは頻繁にマージ操作が実行されます。これにより、I/O 使用率とサービスリクエストの遅延が増加します。ビジネスがデータの読み書きの遅延に敏感な場合は、インスタンスタイプと ESSD パフォーマンスレベルをスペックアップすることで、マージによる高い I/O 使用率の期間を短縮できます。詳細については、「コミュニティ互換クラスターの垂直スケーリング、スケールアウト、スケールイン」をご参照ください。

移行後のマージ時間の計算式は次のとおりです：

• 頻繁なマージ操作の合計時間 = MAX(ホットデータのマージ時間, コールドデータのマージ時間)

  • ホットデータのマージ時間 = シングルノードのホットデータ量 × 2 / MIN(インスタンスタイプの帯域幅, ディスク帯域幅 × n)

  • コールドデータのマージ時間 = (コールドデータ量 / ノード数) / MIN(インスタンスタイプの帯域幅, OSS 読み取り帯域幅) + (コールドデータ量 / ノード数) / MIN(インスタンスタイプの帯域幅, OSS 書き込み帯域幅)

各パラメーターの説明は次のとおりです。

• シングルノードのホットデータ量: [ディスク使用量 - シングルノード統計] 行でデータを表示できます。 詳細については、「クラスターの監視情報を表示する」をご参照ください。

• インスタンスタイプの帯域幅

  説明

  インスタンスタイプの帯域幅の値は絶対的なものではありません。このパラメーターは、ApsaraDB for ClickHouse のバックエンドが異なるマシンタイプを使用する場合に変動します。記載されている値は最小帯域幅であり、参考値です。

  仕様	帯域幅 (MB/s)
  標準 8 コア 32 GB	250
  標準 16 コア 64 GB	375
  標準 24 コア 96 GB	500
  標準 32 コア 128 GB	625
  標準 64 コア 256 GB	1250
  標準 80 コア 384 GB	2000
  標準 104 コア 384 GB	2000

• ディスク帯域幅：「ESSD パフォーマンスレベル」の表にある [ディスクあたりの最大スループット (MB/s)] 行をご参照ください。

• n：シングルノードのディスク数。次のコマンドを実行してこの値を取得します： SELECT count() FROM system.disks WHERE type = 'local';

• コールドデータ量: [コールドストレージ使用量] 行で確認できます。 詳細については、「クラスターのモニタリング情報を表示する」をご参照ください。

• ノード数：クラスター内のノード数。次のコマンドを実行してこの値を取得します： SELECT count() FROM system.clusters WHERE cluster = 'default' and replica_num=1;

• OSS 読み取り帯域幅：「OSS 帯域幅」の表にある [イントラネットとインターネットの合計ダウンロード帯域幅] 列の値をご参照ください。

• OSS 書き込み帯域幅：「OSS 帯域幅」の表にある [イントラネットとインターネットの合計アップロード帯域幅] 列の値をご参照ください。

よくある質問

• Q：「Too many partitions for single INSERT block (more than 100)」というエラーを解決するにはどうすればよいですか。

  A：このエラーは、単一の INSERT 操作が `max_partitions_per_insert_block` の制限を超えたために発生します。このパラメーターのデフォルト値は 100 です。ClickHouse では、各書き込み操作でデータパートが作成され、1 つのパーティションには 1 つ以上のデータパートを含めることができます。単一の INSERT 操作でデータが多すぎるパーティションに書き込まれると、過剰な数のデータパートが作成されます。これにより、マージとクエリのパフォーマンスに大きな影響が及ぶ可能性があります。ClickHouse は、パフォーマンスの低下を防ぐためにこの制限を設けています。

  ソリューション：この問題は、パーティションの数を調整するか、`max_partitions_per_insert_block` パラメーターを変更することで解決できます。

  • テーブルスキーマとパーティショニングメソッドを調整するか、単一の操作で多数の異なるパーティションにデータを挿入することを避けます。

  • 一度に多くのパーティションにデータを挿入することを避けられない場合は、データ量に応じて `max_partitions_per_insert_block` パラメーターを変更して制限を増やすことができます。構文は次のとおりです。

    SET GLOBAL ON cluster DEFAULT max_partitions_per_insert_block = XXX;

    説明

    ClickHouse コミュニティでは、デフォルト値の 100 を使用することを推奨しています。パフォーマンスに悪影響を及ぼす可能性があるため、この値を高く設定しすぎないでください。バッチデータインポートが完了したら、値をデフォルトに戻してください。

• Q：移行先の ApsaraDB for ClickHouse インスタンスから自己管理型の ClickHouse データベースへの接続が失敗するのはなぜですか。

  A: この問題は、自己管理型の ClickHouse クラスターにファイアウォールまたはホワイトリストが設定されている場合に発生する可能性があります。この問題を解決するには、自己管理型の ClickHouse クラスターのホワイトリストに、ApsaraDB for ClickHouse クラスターの [VSwitch ID] の [IPv4 CIDR] を追加する必要があります。ApsaraDB for ClickHouse クラスターの [VSwitch ID] の [IPv4 CIDR] を取得する方法については、「IPv4 CIDR ブロックの表示」をご参照ください。

• Q：マルチレプリカインスタンスを拡張または移行する際に、非 Replicated テーブルが許可されないのはなぜですか。存在する場合、この問題を解決するにはどうすればよいですか。

  A：この制限の理由とソリューションは次のとおりです。

  • 理由：マルチレプリカインスタンスでは、レプリカ間でデータを同期するために Replicated テーブルが必要です。Replicated テーブルがないと、マルチレプリカのセットアップは効果がありません。移行ツールは、ランダムに 1 つのレプリカをデータソースとして選択し、そのデータを宛先インスタンスに移行します。

    非 Replicated テーブルが存在する場合、レプリカ間でデータを同期できず、データは単一のレプリカにしか存在しないことになります。移行ツールは 1 つのレプリカからしかデータを移行しないため、このプロセスではデータ損失が発生します。例えば、次の図に示すように、レプリカ 0 (r0) の MergeTree テーブルにはデータ 1、2、3 が含まれ、レプリカ 1 (r1) の MergeTree テーブルにはデータ 4、5 が含まれています。移行ツールが r0 をソースとして選択した場合、データ 1、2、3 のみが宛先インスタンスに移行されます。

    

  • ソリューション：ソースインスタンス内の非 Replicated テーブルを削除できる場合は、削除してください。そうでない場合は、次の手順を実行して、非 Replicated テーブルを Replicated テーブルに置き換える必要があります。

    1. ソースインスタンスにログインします。

    2. Replicated テーブルを作成します。テーブルスキーマは、エンジンを除き、置き換えたい非 Replicated テーブルと同一である必要があります。

    3. 非 Replicated テーブルから新しい Replicated テーブルに手動でデータを移行します。移行文は次のとおりです。

       重要

       各レプリカを移行する必要があります。つまり、r0 と r1 の両方で文を実行する必要があります。

       文のノード IP アドレスは、SELECT * FROM system.clusters; を実行して取得できます。

       INSERT INTO <destination_database>.<new_replicated_table> 
       SELECT * 
       FROM remote('<node_IP>:3003', '<source_database>', '<non_replicated_table_to_replace>', '<username>', '<password>')
       [WHERE _partition_id = '<partition_id>']
       SETTINGS max_execution_time = 0, max_bytes_to_read = 0, log_query_threads = 0;

    4. 非 Replicated テーブルと Replicated テーブルの名前を交換します。

    EXCHANGE TABLES <source_database>.<non_replicated_table_to_replace> AND <destination_database>.<new_replicated_table> ON CLUSTER default;