すべてのプロダクト
Search
ドキュメントセンター

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

最終更新日:Mar 29, 2026

セルフマネージド ClickHouse クラスターは、スケールが困難で、維持管理コストが高く、エンタープライズレベルのディザスタリカバリ機能を備えていません。本トピックでは、データを ApsaraDB for ClickHouse Community-Compatible Edition クラスターへ移行する方法について説明します。

移行方法の選択

方法メリットデメリット使用するケース
コンソール移行ガイド付きのインターフェイス。メタデータの手動移行は不要です。クラスター全体のみの移行に対応しており、データベース単位、テーブル単位、または既存データの選択移行はできません。データ量の制限内において、クラスター全体を移行する場合。
手動移行移行対象のデータベースおよびテーブルを完全に制御できます。操作が複雑です。メタデータの移行は手動で実施する必要があります。特定のデータベースまたはテーブルを移行する場合、コールドデータが 1 TB を超える場合、ホットデータが 10 TB を超える場合、またはコンソール移行の要件を満たさないクラスターの場合。

前提条件

開始する前に、以下の条件を満たしていることを確認してください。

  • 最高権限を持つアカウントを有する、送信先の ApsaraDB for ClickHouse Community-Compatible Edition クラスター。詳細については、「Community-Compatible Edition クラスターのアカウント管理」および「権限の変更」をご参照ください。

  • データベースおよびテーブルに対する読み取り権限と、SYSTEM コマンドの実行権限を有する、セルフマネージド ClickHouse クラスターのアカウント。

  • 送信先クラスターとセルフマネージドクラスター間のネットワーク接続。

同一の Virtual Private Cloud (VPC) の場合: セルフマネージドクラスターのホワイトリストに、送信先クラスターのすべてのノード IP アドレスおよびその vSwitch IDIPv4 CIDR ブロック を追加します。

  • ノード IP アドレスの確認方法: SELECT * FROM system.clusters;

  • vSwitch ID の確認方法: 送信先クラスターの クラスター情報 ページにアクセスし、「ApsaraDB for ClickHouse コンソール」の ネットワーク情報 セクションを確認します。

  • IPv4 CIDR ブロック の確認方法: 「vSwitch リスト」で vSwitch ID を検索します。

  • ホワイトリストの設定方法: 「IP アドレスホワイトリストの設定」をご参照ください。

異なる VPC、オンプレミスのデータセンター、または他のクラウドサービスの場合: 移行を開始する前に、ネットワーク接続を確立してください。詳細については、「送信先クラスターとデータソース間のネットワーク接続を確立するには?」をご参照ください。

テスト環境での検証を優先

本番データの移行を実施する前に、テスト環境で移行手順全体を実行し、業務要件との互換性およびパフォーマンスを検証してください。これにより、本番環境への影響を受ける前に問題を特定できます。

  1. コンソール移行」または「手動移行」セクションの手順に従って、移行タスクを作成します。

  2. 互換性およびパフォーマンスを分析します。詳細については、「セルフマネージド ClickHouse からクラウドへの移行における互換性およびパフォーマンスボトルネックの分析と解決策」をご参照ください。

コンソール移行

コンソール移行は、ガイド付きのインターフェイスを提供し、メタデータを自動的に処理しますが、以下の制約があります。

制限事項

  • 送信先クラスターのバージョンは、21.8 以降である必要があります。

  • クラスター全体の完全移行および増分移行のみをサポートしています。個別のデータベース、テーブル、または既存データのスナップショットを選択することはできません。

データ量の制限

データ種別制限制限を超えた場合の動作
コールドデータ推奨合計 ≤ 1 TB移行速度が低下し、タスク失敗のリスクが高まります。
ホットデータ≤ 10 TB失敗する可能性が非常に高くなります。

データ量がこれらの制限を超える場合は、「手動移行」をご利用ください。

移行対象

移行される項目:

  • データベース、データ辞書、およびマテリアライズドビュー

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

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

移行されない項目:

  • Kafka および RabbitMQ のテーブルスキーマおよびそのデータ

  • 非 MergeTree テーブル(外部テーブル、Log テーブル)のデータ

重要

サポートされていないコンテンツは、移行プロセス中に手動で処理してください。手順は以下に記載されています。

潜在的なリスク

セルフマネージドクラスター:

  • 読み取り操作による CPU およびメモリ使用量の増加

  • DDL 操作がブロックされます

送信先クラスター:

  • 書き込み操作による CPU およびメモリ使用量の増加

  • DDL 操作がブロックされます

  • 移行済みのデータベースおよびテーブルに対して DDL 操作がブロックされます(他のデータベースおよびテーブルにはこの制限は適用されません)

  • 移行済みのデータベースおよびテーブルに対してマージが一時停止されます(他のデータベースおよびテーブルのマージには影響しません)

  • 移行タスクの開始時および終了時にクラスターが再起動されます

  • 移行完了後、クラスターは高頻度のマージを実行し、I/O 使用量およびリクエスト遅延が増加します。「移行後のマージ時間の算出」を使用して、予想されるマージ所要時間を計算してください。

移行に時間がかかりすぎると、送信先クラスターにメタデータが蓄積されます。移行タスクの作成から 5 日以内に移行を完了してください。

操作手順

ステップ 1:セルフマネージドクラスターでシステムテーブルを有効化

コンソール移行では、セルフマネージドクラスターの system.part_log および system.query_log を、config.xml で正しく有効化および設定する必要があります。

ログが有効化されていない場合

config.xml に system.part_log および system.query_log が有効化されていない場合、以下のブロックを config.xml に追加します。

system.part_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>

system.query_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>

ログが有効化済みの場合

system.part_log および system.query_log がすでに有効化されている場合、既存の設定を上記のブロックと比較します。設定が異なる場合は、一致するように更新したうえで、テーブルを削除して再作成します。

system.part_log

system.query_log

DROP TABLE system.part_log;
DROP TABLE system.query_log;

次のデータ挿入時に、テーブルは自動的に再作成されます。

ステップ 2:送信先クラスターで互換性を設定

送信先クラスターを、セルフマネージドクラスターと同じ互換性レベルで構成します。これにより、移行後の変更を最小限に抑えられます。

  1. 両方のクラスターのバージョンを確認します。

    SELECT version();
  2. バージョンが異なる場合は、送信先クラスターの互換性パラメーターを、セルフマネージドクラスターのバージョンに合わせて設定します。例:

    SET GLOBAL compatibility = '22.8';

ステップ 3(任意):MaterializedMySQL エンジンの有効化

セルフマネージドクラスターに MaterializedMySQL エンジンを使用するテーブルがある場合は、送信先クラスターで以下のコマンドを実行します。

SET GLOBAL allow_experimental_database_materialized_mysql = 1;
ClickHouse コミュニティは、MaterializedMySQL エンジンのメンテナンスを中止しました。移行後は、Data Transmission Service (DTS) を使用して MySQL データを ReplacingMergeTree テーブルと同期してください。詳細については、「シームレスな統合を使用して ApsaraDB RDS for MySQL から ApsaraDB for ClickHouse クラスターへデータを同期する」および「ApsaraDB RDS for MySQL から ApsaraDB for ClickHouse クラスターへデータを同期する」をご参照ください。

ステップ 4:移行タスクの作成

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

  2. クラスター ページで、Community-compatible Edition のクラスター を選択し、送信先クラスター ID をクリックします。

  3. 左側のナビゲーションウィンドウで、データ移行および同期ClickHouse からの移行 をクリックします。

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

  5. ソースクラスターの接続設定を構成します。ソースクラスターの IP アドレスおよびポートを取得するには:replica_num = 1 は最初のレプリカセットを選択します。必要に応じて、他のレプリカセットを選択できます。

    クロスアカウントまたはクロスリージョンの移行

    クロスアカウントまたはクロスリージョンの Alibaba Cloud ClickHouse インスタンス: ``sql SELECT shard_num, replica_num, host_address AS ip, port FROM system.clusters WHERE cluster = 'default' AND replica_num = 1; ``

    Alibaba Cloud 外のインスタンスの移行

    Alibaba Cloud 外の ClickHouse インスタンス: ``sql SELECT shard_num, replica_num, host_address AS ip, port FROM system.clusters WHERE cluster = '<cluster_name>' AND replica_num = 1; ``

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

    ソースクラスターの設定:

    フィールド説明
    ソースアクセス方法Express Connect、VPN Gateway、Smart Access Gateway、または ECS インスタンス上のセルフマネージド ClickHouse クラスター を選択します。
    クラスター名ソースクラスターの名前。数字および小文字のみ使用可能です。source
    ソースクラスター名SELECT * FROM system.clusters; から取得した内部クラスター名。default
    VPC IP アドレス各シャードの TCP IP:PORT のペアをカンマ区切りで指定します。VPC ドメイン名または SLB アドレスは使用しないでください。形式: IP:PORT,IP:PORT,...192.168.0.5:9000,192.168.0.6:9000
    データベースアカウントソースクラスターのアカウント。test
    データベースパスワードソースクラスターのアカウントのパスワード。

    送信先クラスターのパラメーター

    送信先クラスターの設定:

    フィールド説明
    データベースアカウント送信先クラスターのアカウント。
    データベースパスワード送信先クラスターのアカウントのパスワード。

    image

  6. 接続テストと続行 をクリックします。テストが失敗した場合は、接続設定を修正して再試行してください。

  7. 移行内容を確認し、次へ:事前検出および同期の開始 をクリックします。

  8. システムが 3 つの事前チェックを実行します。すべてのチェックが成功した場合:いずれかのチェックが失敗した場合は、「事前チェックのエラーメッセージと解決策」のエラー案内に従って対応してください。

    1. 影響に関するプロンプトをよくお読みください。

    2. 完了 をクリックして、タスクを作成および開始します。

    チェック項目要件
    インスタンス状態検出どちらのクラスターにも、実行中の管理タスク(スケールアウト、アップグレード、スペックダウン)がないこと。
    ストレージ容量検出送信先クラスターのストレージ容量 ≥ セルフマネージドクラスターの使用済み容量 × 1.2。
    ローカルテーブルおよび分散テーブル検出セルフマネージドクラスターの各ローカルテーブルには、対応する分散テーブルが 1 つだけ存在すること。

    image

ステップ 5:移行の完了可能性の評価

ソースクラスターの書き込み速度が 20 MB/s 未満の場合は、このステップをスキップできます。

ソースクラスターの書き込み速度が 20 MB/s を超える場合は、送信先クラスターが追従できるかどうかを確認します。

  1. 送信先クラスターの ディスクスループット メトリックを確認します。詳細については、「クラスターモニタリング情報の表示」をご参照ください。

  2. 書き込み速度を比較します。

    • 送信先の書き込み速度 > ソースの書き込み速度:移行は 成功する可能性が高い です。ステップ 6 に進んでください。

    • 送信先の書き込み速度 < ソースの書き込み速度:移行は 失敗する可能性が高い です。タスクをキャンセルし、「手動移行」をご利用ください。

ステップ 6:移行タスクの監視

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

  2. クラスター ページで、Community-compatible Edition のクラスター を選択し、送信先クラスター ID をクリックします。

  3. 左側のナビゲーションウィンドウで、データ移行および同期ClickHouse からの移行 をクリックします。

  4. タスクのステータスおよび 実行中の情報 列を監視します。

重要

実行中の情報 列に表示される推定残り時間を追跡してください。タスクの完了が近づいたら、ステップ 7 に従って書き込みを停止し、Kafka および RabbitMQ のテーブルを処理してください。

タスクの詳細を表示するには、詳細の表示操作 列でクリックします。詳細ページには、移行済みのテーブルスキーマ、データベース構造、およびエラーメッセージが表示されます。

タスクが終了した後(ステータス:完了またはキャンセル)、詳細の表示 ページはクリアされます。その後も移行済みのテーブルスキーマを表示するには、以下のコマンドを実行してください。
SELECT `database`, `name`, `engine_full`
FROM `system`.`tables`
WHERE `database` NOT IN ('system', 'INFORMATION_SCHEMA', 'information_schema');

タスクのステータス:

ステータス説明
実行中環境およびリソースの準備中。
初期化移行タスクの初期化中。
構成移行クラスター構成の移行中。
スキーマ移行データベース、MergeTree ファミリーのテーブル、および分散テーブルの移行中。
データ移行MergeTree ファミリーのテーブルからのデータの増分移行中。
その他のスキーマ移行マテリアライズドビューおよび非 MergeTree テーブルのスキーマの移行中。
データチェック送信先のデータ量がセルフマネージドクラスターと一致しているかを検証中。
ポスト構成移行環境のクリーニングおよびソースクラスターへの書き込みの再開中。
完了移行が完了しました。
キャンセル移行がキャンセルされました。

ステップ 7:書き込みの停止および Kafka および RabbitMQ テーブルの処理

業務トラフィックを送信先クラスターに切り替える前に、セルフマネージドクラスターへのすべての書き込みを停止し、送信先で Kafka および RabbitMQ のテーブルを手動で作成します。

  1. セルフマネージドクラスター で、処理対象のテーブルを特定します。

    SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');
  2. 各テーブルの DDL を取得します。

    SHOW CREATE TABLE <target_table_name>;
  3. 送信先クラスター で、DDL ステートメントを実行してテーブルを作成します。「DMS を使用した ClickHouse クラスターへの接続」で接続手順をご確認ください。

  4. セルフマネージドクラスター で、Kafka および RabbitMQ のテーブルを削除します。

重要

Kafka テーブルを削除する際は、それを参照するすべてのマテリアライズドビューも削除してください。削除しないと、移行タスクが失敗します。

ステップ 8:移行の完了

セルフマネージドクラスターへの書き込みを停止した後、移行を完了します。これにより、残りのデータが移行され、データ量のチェックが実行され、未処理のデータベースおよびテーブルスキーマが移行されます。

重要

移行タスクの作成から 5 日以内に完了してください。長期間実行されるタスクでは、送信先クラスターに過剰なメタデータが蓄積され、移行が遅くなります。データ量チェックが失敗した場合は、タスクをキャンセルして新しいタスクを作成してください。

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

  2. クラスター ページで、Community-compatible Edition のクラスター を選択し、送信先クラスター ID をクリックします。

  3. 左側のナビゲーションウィンドウで、データ移行および同期ClickHouse からの移行 をクリックします。

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

  5. ダイアログボックスで、OK をクリックします。

ステップ 9:非 MergeTree テーブルのデータ移行

移行タスクは、非 MergeTree テーブル(外部テーブル、Log テーブル)のテーブルスキーマをコピーしますが、そのデータはコピーしません。データは手動で移行する必要があります。

  1. セルフマネージドクラスター で、手動でデータ移行が必要なテーブルを特定します。

    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. ApsaraDB for ClickHouse コンソール にログインします。

  2. クラスター ページで、Community-compatible Edition のクラスター を選択し、送信先クラスター ID をクリックします。

  3. 左側のナビゲーションウィンドウで、データ移行および同期ClickHouse からの移行 をクリックします。

  4. 操作 列で、移行の停止 をクリックし、確認します。

移行のキャンセル

移行のキャンセル:

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

  2. クラスター ページで、Community-compatible Edition のクラスター を選択し、送信先クラスター ID をクリックします。

  3. 左側のナビゲーションウィンドウで、データ移行および同期ClickHouse からの移行 をクリックします。

  4. 操作 列で、移行のキャンセル をクリックし、確認します。

手動移行

特定のデータベースまたはテーブルを選択したり、大規模なコールドデータまたはホットデータを移行したり、コンソール移行ツールを使用できないクラスターを扱ったりする場合など、細かい制御が必要な場合に手動移行をご利用ください。

方法 1:BACKUP および RESTORE コマンド

詳細については、「BACKUP および RESTORE コマンドを使用したバックアップおよびリストア」をご参照ください。

方法 2:remote 関数を使用した INSERT INTO SELECT

この 2 ステップ方式では、まずテーブルスキーマを移行し、その後にデータを移行します。

ステップ 1:テーブルスキーマ(DDL)の移行

送信先の ApsaraDB for ClickHouse クラスターと同じバージョンの clickhouse-client をインストールします。「clickhouse-client」でダウンロード手順をご確認ください。

  1. セルフマネージドクラスター内のデータベースを一覧表示します。

    clickhouse-client \
      --host="<old_host>" --port="<old_port>" \
      --user="<old_username>" --password="<old_password>" \
      --query="SHOW databases" > database.list

    system データベースは移行する必要はありません。

  2. セルフマネージドクラスター内のテーブルを一覧表示します。以下のいずれかの方法を使用します。

    .inner. で始まるテーブル名は、マテリアライズドビューの内部表現であり、移行する必要はありません。
    clickhouse-client \
      --host="<old_host>" --port="<old_port>" \
      --user="<old_username>" --password="<old_password>" \
      --query="SHOW tables from <database_name>" > table.list

    または、すべてのデータベースおよびテーブルを一度に照会します。

    SELECT DISTINCT database, name FROM system.tables WHERE database != 'system';
  3. データベース内のすべてのテーブルの DDL をエクスポートします。

    clickhouse-client \
      --host="<old_host>" --port="<old_port>" \
      --user="<old_username>" --password="<old_password>" \
      --query="SELECT concat(create_table_query, ';') FROM system.tables WHERE database='<database_name>' FORMAT TabSeparatedRaw" > tables.sql
  4. 送信先クラスターでターゲットデータベースを作成し、DDL をインポートします。

    パラメーター説明
    <old_host id="49bc4df282xmg"></old_host>セルフマネージドクラスターのアドレス。
    <old_port id="875bbc7cbci4e"></old_port>セルフマネージドクラスターのポート。
    <old_username></old_username>DML の読み取り/書き込み、設定、DDL の権限を持つアカウント。
    <old_password id="349ed6d40fai6"></old_password>アカウントのパスワード。
    <new_host>送信先の ApsaraDB for ClickHouse クラスターのアドレス。
    <new_port>送信先の ApsaraDB for ClickHouse クラスターのポート。
    <new_username>DML の読み取り/書き込み、設定、DDL の権限を持つアカウント。
    <new_password>アカウントのパスワード。
    clickhouse-client \
      --host="<new_host>" --port="<new_port>" \
      --user="<new_username>" --password="<new_password>" \
      -d '<database_name>' --multiquery < tables.sql

ステップ 2:データの移行

3 つのオプションがあります。可能な場合は、パーティション単位の移行をサポートし、リソース使用量を削減できる remote 関数(オプション A)をご利用ください。

オプション A:remote 関数を使用したデータ移行

以下のコマンドを 送信先クラスター で実行します。

  1. (任意)ZSTD 圧縮を有効化してネットワークトラフィックを削減します。

    SET network_compression_method = 'ZSTD';

    現在の設定を確認するには:

    SELECT * FROM system.settings WHERE name = 'network_compression_method';
  2. テーブル単位でデータを移行します。必要に応じて、パーティションでフィルター処理できます。

    バージョン 20.8 の場合、まず remoteRaw を試してください。移行が失敗した場合は、マイナーバージョンのアップグレードを依頼してください。 ``sql INSERT INTO <new_database>.<new_table> SELECT * FROM remoteRaw('<old_endpoint>', <old_database>.<old_table>, '<username>', '<password>') [WHERE _partition_id = '<partition_id>'] SETTINGS max_execution_time = 0, max_bytes_to_read = 0, log_query_threads = 0, max_result_rows = 0; ``
    重要

    必ず VPC 内部エンドポイントを使用し、パブリックエンドポイントは使用しないでください。

    パラメーター:

    パラメーター説明
    <new_database>送信先クラスター上のターゲットデータベース名。
    <new_table>送信先クラスター上のターゲットテーブル名。
    <old_endpoint id="d2d4b83546bri"></old_endpoint>ソースエンドポイント(下記の形式をご確認ください)。
    <old_database id="55418a01cduev"></old_database>ソースデータベース名。
    <old_table id="b6794ac596wmm"></old_table>ソーステーブル名。
    <username>ソースクラスターのアカウント。
    <password>ソースクラスターのパスワード。
    max_execution_timeクエリの最大実行時間。0 = 制限なし。
    max_bytes_to_readソースから読み取る最大バイト数。0 = 制限なし。
    log_query_threadsクエリのスレッド情報をログ出力します。0 = 無効。
    max_result_rows結果の最大行数。0 = 制限なし。
    _partition_idフィルター処理するパーティション ID。パーティションでフィルター処理すると、リソース使用量が削減されます(推奨)。

    `<old_endpoint>` のエンドポイント形式:

    セルフマネージド ClickHouse
    ApsaraDB for ClickHouse

    ソースインスタンスの VPC エンドポイントを使用します(パブリックエンドポイントは使用しないでください)。

    重要

    ポート 3306 および 9000 は固定値です。

    • Community-compatible Edition インスタンス:

      • エンドポイント形式:VPC 内部アドレス:3306

      • 例:cc-2zeqhh5v7y6q*****.clickhouse.ads.aliyuncs.com:3306

    • Enterprise Edition インスタンス:

      • エンドポイント形式:VPC 内部アドレス:9000

      • 例:cc-bp1anv7jo84ta*****clickhouse.clickhouseserver.rds.aliyuncs.com:9000

    ソース種別形式
    セルフマネージド ClickHouseIP:TCP_ポート192.168.0.5:9000
    ApsaraDB for ClickHouse Community-Compatible EditionVPC_内部アドレス:3306cc-2zeqhh5v7y6q*****.clickhouse.ads.aliyuncs.com:3306
    ApsaraDB for ClickHouse EnterpriseVPC_内部アドレス:9000cc-bp1anv7jo84ta*****clickhouse.clickhouseserver.rds.aliyuncs.com:9000
    INSERT INTO <new_database>.<new_table>
    SELECT *
    FROM remote('<old_endpoint>', <old_database>.<old_table>, '<username>', '<password>')
    [WHERE _partition_id = '<partition_id>']
    SETTINGS max_execution_time = 0, max_bytes_to_read = 0, log_query_threads = 0, max_result_rows = 0;

    パーティション ID およびパート数を確認するには:

    SELECT partition_id, count(*) AS part_count
    FROM clusterAllReplicas(default, system, parts)
    WHERE `database` = '<old_database>' AND `table` = '<old_table>'
    GROUP BY partition_id;

ファイルのエクスポートおよびインポート

オプション B:CSV ファイルを介したエクスポートおよびインポート

セルフマネージドクラスターからのエクスポート:

clickhouse-client \
  --host="<old_host>" --port="<old_port>" \
  --user="<old_username>" --password="<old_password>" \
  --query="SELECT * FROM <database_name>.<table_name> FORMAT CSV" > table.csv

送信先クラスターへのインポート:

clickhouse-client \
  --host="<new_host>" --port="<new_port>" \
  --user="<new_username>" --password="<new_password>" \
  --query="INSERT INTO <database_name>.<table_name> FORMAT CSV" < table.csv
オプション C:Linux パイプを介したストリーミング

中間ファイルを経由せずに、エクスポートおよびインポートを 1 つのコマンドでパイプ処理します。

clickhouse-client \
  --host="<old_host>" --port="<old_port>" \
  --user="<username>" --password="<password>" \
  --query="SELECT * FROM <database_name>.<table_name> FORMAT CSV" | \
clickhouse-client \
  --host="<new_host>" --port="<new_port>" \
  --user="<username>" --password="<password>" \
  --query="INSERT INTO <database_name>.<table_name> FORMAT CSV"

事前チェックのエラーメッセージと解決策

エラーメッセージ原因解決策
一意の分散テーブルが不足している、または sharding_key が設定されていません。セルフマネージドクラスターのローカルテーブルに対応する分散テーブルがありません。移行前に、ローカルテーブルに対応する分散テーブルを作成してください。
対応する分散テーブルが一意ではありません。ローカルテーブルに複数の分散テーブルがあります。余分な分散テーブルを削除し、1 つだけ残してください。
マルチレプリカクラスター上の MergeTree テーブル。セルフマネージドクラスターは、非レプリケートテーブルを含むマルチレプリカクラスターです。FAQ セクションの「マルチレプリカクラスターにおける非レプリケートテーブル」をご参照ください。
送信先クラスターにデータ保持テーブルがあります。送信先に、対応するテーブルにすでにデータが存在します。送信先クラスターから対応するテーブルを削除してください。
分散テーブルとローカルテーブルのカラムが競合しています。分散テーブルとローカルテーブルのカラム定義が一致していません。ローカルテーブルと一致するように、分散テーブルを再構築してください。
ストレージが不足しています。送信先クラスターのストレージ容量が不足しています。送信先クラスターのディスクをアップグレードしてください。送信先の合計容量は、セルフマネージドクラスターの使用済み容量の 1.2 倍以上である必要があります。「Community-Compatible Edition クラスターのアップグレード/ダウングレードおよびスケールアウト/スケールイン」をご参照ください。
システムテーブルが不足しています。セルフマネージドクラスターに必要なシステムテーブルがありません。config.xml を更新して、必要なシステムテーブルを有効化してください。「ステップ 1:システムテーブルの有効化」をご参照ください。
テーブルが異なるノード間で不完全です。一部のシャードにテーブルが欠落しています。すべてのシャードにテーブルを作成してください。マテリアライズドビューの内部テーブルの場合は、内部テーブルの名前を変更してマテリアライズドビューを再構築してください。「マテリアライズドビューの内部テーブルがシャード間で不整合です」をご参照ください。

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

移行後、送信先クラスターは高頻度のマージを実行します。これにより、I/O 使用量およびリクエスト遅延が増加します。ワークロードが高遅延感度の場合、この期間を短縮するために、インスタンスタイプまたは ESSD パフォーマンスレベルをアップグレードすることを検討してください。「Community-Compatible Edition クラスターの垂直スケーリング、スケールアウトおよびスケールイン」をご参照ください。

この式は、シングルレプリカクラスターおよびマスターレプリカクラスターの両方に適用されます。

総マージ時間 = MAX(ホットデータのマージ時間, コールドデータのマージ時間)

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

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

各値の取得方法:

取得方法
ノードあたりのホットデータ量クラスターモニタリング情報の表示」の ディスク使用量 - シングルノード統計
コールドデータクラスターモニタリング情報の表示」の コールドストレージ使用量
ノード数SELECT count() FROM system.clusters WHERE cluster = 'default' AND replica_num = 1;
n(ノードあたりのディスク数)SELECT count() FROM system.disks WHERE type = 'local';
ディスク帯域幅ESSD パフォーマンスレベル」表の ディスクあたりの最大スループット(MB/s)
OSS 読み取り帯域幅OSS 帯域幅」表の イントラネットおよびインターネットのダウンロード帯域幅合計
OSS 書き込み帯域幅OSS 帯域幅」表の イントラネットおよびインターネットのアップロード帯域幅合計

インスタンスタイプ帯域幅の参考値(最小値):

仕様帯域幅(MB/s)
標準 8 コア 32 GB250
標準 16 コア 64 GB375
標準 24 コア 96 GB500
標準 32 コア 128 GB625
標準 64 コア 256 GB1,250
標準 80 コア 384 GB2,000
標準 104 コア 384 GB2,000
実際の帯域幅はマシンタイプによって異なります。これらの値は最小限の参考値です。

よくある質問

単一 INSERT ブロックのパーティション数が多すぎます

エラー: Too many partitions for single INSERT block (more than 100)

各 INSERT は、パーティション間でデータパーツを作成します。単一 INSERT が max_partitions_per_insert_block(デフォルト:100)を超えるパーティションに書き込むと、ClickHouse はマージおよびクエリ時のパフォーマンス劣化を防ぐため、操作を拒否します。

この問題を解決するには、INSERT ごとのパーティション数を減らすか、回避できない場合は制限値を増加させます。

SET GLOBAL ON CLUSTER DEFAULT max_partitions_per_insert_block = <value>;
この値はできる限り小さく保ってください。デフォルト値 100 はコミュニティの推奨値です。バッチインポート完了後は、デフォルト値に戻してください。

送信先からセルフマネージドクラスターへの接続が失敗します

セルフマネージドクラスターには、ファイアウォールまたはホワイトリストが設定されている可能性があります。送信先クラスターの [IPv4 CIDR ブロック] を、セルフマネージドクラスターのホワイトリストに追加します。vSwitch ID の CIDR ブロックの検出方法については、「前提条件」セクションをご参照ください。

マルチレプリカクラスターにおける非レプリケートテーブル

非レプリケートテーブルがブロックされる理由: マルチレプリカクラスターでは、移行ツールが 1 つのレプリカをデータソースとして選択します。非レプリケート MergeTree テーブルが存在する場合、各レプリカが異なるデータを保持する可能性があり、単一のレプリカからの移行ではデータ損失が発生します。

例:レプリカ r0 が行 1、2、3 を保持し、レプリカ r1 が行 4、5 を保持している場合、r0 からの移行では行 4、5 が失われます。

image

解決策:

非レプリケートテーブルを削除できる場合は、ソースから削除してください。それ以外の場合は、ReplicatedMergeTree テーブルに置き換えます。

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

  2. 非レプリケートテーブルと同じスキーマで ReplicatedMergeTree テーブルを作成します(エンジンのみ変更します)。

  3. 各レプリカから新規の Replicated テーブルへデータを移行します。各レプリカノードで以下のコマンドを実行します。

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

    ノード IP アドレスは SELECT * FROM system.clusters; で取得できます。

  4. テーブル名を交換します。

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