セルフマネージド 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 ID の IPv4 CIDR ブロック を追加します。
ノード IP アドレスの確認方法:
SELECT * FROM system.clusters;vSwitch ID の確認方法: 送信先クラスターの クラスター情報 ページにアクセスし、「ApsaraDB for ClickHouse コンソール」の ネットワーク情報 セクションを確認します。
IPv4 CIDR ブロック の確認方法: 「vSwitch リスト」で vSwitch ID を検索します。
ホワイトリストの設定方法: 「IP アドレスホワイトリストの設定」をご参照ください。
異なる VPC、オンプレミスのデータセンター、または他のクラウドサービスの場合: 移行を開始する前に、ネットワーク接続を確立してください。詳細については、「送信先クラスターとデータソース間のネットワーク接続を確立するには?」をご参照ください。
テスト環境での検証を優先
本番データの移行を実施する前に、テスト環境で移行手順全体を実行し、業務要件との互換性およびパフォーマンスを検証してください。これにより、本番環境への影響を受ける前に問題を特定できます。
互換性およびパフォーマンスを分析します。詳細については、「セルフマネージド 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:送信先クラスターで互換性を設定
送信先クラスターを、セルフマネージドクラスターと同じ互換性レベルで構成します。これにより、移行後の変更を最小限に抑えられます。
両方のクラスターのバージョンを確認します。
SELECT version();バージョンが異なる場合は、送信先クラスターの互換性パラメーターを、セルフマネージドクラスターのバージョンに合わせて設定します。例:
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:移行タスクの作成
ApsaraDB for ClickHouse コンソール にログインします。
クラスター ページで、Community-compatible Edition のクラスター を選択し、送信先クラスター ID をクリックします。
左側のナビゲーションウィンドウで、データ移行および同期 > ClickHouse からの移行 をクリックします。
移行タスクの作成 をクリックします。
ソースクラスターの接続設定を構成します。ソースクラスターの 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;から取得した内部クラスター名。defaultVPC IP アドレス 各シャードの TCP IP:PORT のペアをカンマ区切りで指定します。VPC ドメイン名または SLB アドレスは使用しないでください。形式: IP:PORT,IP:PORT,...192.168.0.5:9000,192.168.0.6:9000データベースアカウント ソースクラスターのアカウント。 testデータベースパスワード ソースクラスターのアカウントのパスワード。 — 送信先クラスターのパラメーター
送信先クラスターの設定:
フィールド 説明 データベースアカウント 送信先クラスターのアカウント。 データベースパスワード 送信先クラスターのアカウントのパスワード。 
接続テストと続行 をクリックします。テストが失敗した場合は、接続設定を修正して再試行してください。
移行内容を確認し、次へ:事前検出および同期の開始 をクリックします。
システムが 3 つの事前チェックを実行します。すべてのチェックが成功した場合:いずれかのチェックが失敗した場合は、「事前チェックのエラーメッセージと解決策」のエラー案内に従って対応してください。
影響に関するプロンプトをよくお読みください。
完了 をクリックして、タスクを作成および開始します。
チェック項目 要件 インスタンス状態検出 どちらのクラスターにも、実行中の管理タスク(スケールアウト、アップグレード、スペックダウン)がないこと。 ストレージ容量検出 送信先クラスターのストレージ容量 ≥ セルフマネージドクラスターの使用済み容量 × 1.2。 ローカルテーブルおよび分散テーブル検出 セルフマネージドクラスターの各ローカルテーブルには、対応する分散テーブルが 1 つだけ存在すること。 
ステップ 5:移行の完了可能性の評価
ソースクラスターの書き込み速度が 20 MB/s 未満の場合は、このステップをスキップできます。
ソースクラスターの書き込み速度が 20 MB/s を超える場合は、送信先クラスターが追従できるかどうかを確認します。
送信先クラスターの ディスクスループット メトリックを確認します。詳細については、「クラスターモニタリング情報の表示」をご参照ください。
書き込み速度を比較します。
送信先の書き込み速度 > ソースの書き込み速度:移行は 成功する可能性が高い です。ステップ 6 に進んでください。
送信先の書き込み速度 < ソースの書き込み速度:移行は 失敗する可能性が高い です。タスクをキャンセルし、「手動移行」をご利用ください。
ステップ 6:移行タスクの監視
ApsaraDB for ClickHouse コンソール にログインします。
クラスター ページで、Community-compatible Edition のクラスター を選択し、送信先クラスター ID をクリックします。
左側のナビゲーションウィンドウで、データ移行および同期 > ClickHouse からの移行 をクリックします。
タスクのステータスおよび 実行中の情報 列を監視します。
実行中の情報 列に表示される推定残り時間を追跡してください。タスクの完了が近づいたら、ステップ 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 のテーブルを手動で作成します。
セルフマネージドクラスター で、処理対象のテーブルを特定します。
SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');各テーブルの DDL を取得します。
SHOW CREATE TABLE <target_table_name>;送信先クラスター で、DDL ステートメントを実行してテーブルを作成します。「DMS を使用した ClickHouse クラスターへの接続」で接続手順をご確認ください。
セルフマネージドクラスター で、Kafka および RabbitMQ のテーブルを削除します。
Kafka テーブルを削除する際は、それを参照するすべてのマテリアライズドビューも削除してください。削除しないと、移行タスクが失敗します。
ステップ 8:移行の完了
セルフマネージドクラスターへの書き込みを停止した後、移行を完了します。これにより、残りのデータが移行され、データ量のチェックが実行され、未処理のデータベースおよびテーブルスキーマが移行されます。
移行タスクの作成から 5 日以内に完了してください。長期間実行されるタスクでは、送信先クラスターに過剰なメタデータが蓄積され、移行が遅くなります。データ量チェックが失敗した場合は、タスクをキャンセルして新しいタスクを作成してください。
ApsaraDB for ClickHouse コンソール にログインします。
クラスター ページで、Community-compatible Edition のクラスター を選択し、送信先クラスター ID をクリックします。
左側のナビゲーションウィンドウで、データ移行および同期 > ClickHouse からの移行 をクリックします。
タスクの 操作 列で、移行の完了 をクリックします。
ダイアログボックスで、OK をクリックします。
ステップ 9:非 MergeTree テーブルのデータ移行
移行タスクは、非 MergeTree テーブル(外部テーブル、Log テーブル)のテーブルスキーマをコピーしますが、そのデータはコピーしません。データは手動で移行する必要があります。
セルフマネージドクラスター で、手動でデータ移行が必要なテーブルを特定します。
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') ))送信先クラスター で、
remote関数を使用してデータを移行します。「remote 関数を使用したデータ移行」(手動移行セクション)をご参照ください。
その他の操作
移行タスクが完了すると、そのステータスは 完了 に変わりますが、一覧が即座に更新されない場合があります。最新のステータスを確認するには、ページをリフレッシュしてください。
| 操作 | 実行内容 | 影響 | 使用するケース |
|---|---|---|---|
| 移行の停止 | データ移行を直ちに停止します。データ量チェックをスキップし、残りのスキーマを移行します。 | 送信先クラスターが再起動します。 | セルフマネージドクラスターへの書き込みを停止せずに、テスト用に一部のデータを移行する場合。 |
| 移行のキャンセル | タスクを強制的にキャンセルします。データ量チェックをスキップし、残りのスキーマは移行しません。 | 送信先クラスターが再起動します。データベースおよびテーブルのスキーマが不完全になる可能性があります。再試行前に、送信先から移行済みのデータをクリアしてください。 | マイグレーションがセルフマネージドクラスターに影響を及ぼしており、直ちに停止して書き込みを再有効化する必要があります。 |
移行の停止
移行の停止:
ApsaraDB for ClickHouse コンソール にログインします。
クラスター ページで、Community-compatible Edition のクラスター を選択し、送信先クラスター ID をクリックします。
左側のナビゲーションウィンドウで、データ移行および同期 > ClickHouse からの移行 をクリックします。
操作 列で、移行の停止 をクリックし、確認します。
移行のキャンセル
移行のキャンセル:
ApsaraDB for ClickHouse コンソール にログインします。
クラスター ページで、Community-compatible Edition のクラスター を選択し、送信先クラスター ID をクリックします。
左側のナビゲーションウィンドウで、データ移行および同期 > ClickHouse からの移行 をクリックします。
操作 列で、移行のキャンセル をクリックし、確認します。
手動移行
特定のデータベースまたはテーブルを選択したり、大規模なコールドデータまたはホットデータを移行したり、コンソール移行ツールを使用できないクラスターを扱ったりする場合など、細かい制御が必要な場合に手動移行をご利用ください。
方法 1:BACKUP および RESTORE コマンド
詳細については、「BACKUP および RESTORE コマンドを使用したバックアップおよびリストア」をご参照ください。
方法 2:remote 関数を使用した INSERT INTO SELECT
この 2 ステップ方式では、まずテーブルスキーマを移行し、その後にデータを移行します。
ステップ 1:テーブルスキーマ(DDL)の移行
送信先の ApsaraDB for ClickHouse クラスターと同じバージョンの clickhouse-client をインストールします。「clickhouse-client」でダウンロード手順をご確認ください。
セルフマネージドクラスター内のデータベースを一覧表示します。
clickhouse-client \ --host="<old_host>" --port="<old_port>" \ --user="<old_username>" --password="<old_password>" \ --query="SHOW databases" > database.listsystemデータベースは移行する必要はありません。セルフマネージドクラスター内のテーブルを一覧表示します。以下のいずれかの方法を使用します。
.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';データベース内のすべてのテーブルの 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送信先クラスターでターゲットデータベースを作成し、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 関数を使用したデータ移行
以下のコマンドを 送信先クラスター で実行します。
(任意)ZSTD 圧縮を有効化してネットワークトラフィックを削減します。
SET network_compression_method = 'ZSTD';現在の設定を確認するには:
SELECT * FROM system.settings WHERE name = 'network_compression_method';テーブル単位でデータを移行します。必要に応じて、パーティションでフィルター処理できます。
バージョン 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
-
ソース種別 形式 例 セルフマネージド ClickHouse IP:TCP_ポート192.168.0.5:9000ApsaraDB for ClickHouse Community-Compatible Edition VPC_内部アドレス:3306cc-2zeqhh5v7y6q*****.clickhouse.ads.aliyuncs.com:3306ApsaraDB for ClickHouse Enterprise VPC_内部アドレス:9000cc-bp1anv7jo84ta*****clickhouse.clickhouseserver.rds.aliyuncs.com:9000INSERT 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 GB | 250 |
| 標準 16 コア 64 GB | 375 |
| 標準 24 コア 96 GB | 500 |
| 標準 32 コア 128 GB | 625 |
| 標準 64 コア 256 GB | 1,250 |
| 標準 80 コア 384 GB | 2,000 |
| 標準 104 コア 384 GB | 2,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 が失われます。
解決策:
非レプリケートテーブルを削除できる場合は、ソースから削除してください。それ以外の場合は、ReplicatedMergeTree テーブルに置き換えます。
ソースクラスターにログインします。
非レプリケートテーブルと同じスキーマで ReplicatedMergeTree テーブルを作成します(エンジンのみ変更します)。
各レプリカから新規の 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;で取得できます。テーブル名を交換します。
EXCHANGE TABLES <source_database>.<non_replicated_table> AND <destination_database>.<new_replicated_table> ON CLUSTER default;