セルフマネージド ClickHouse クラスターの安定性のリスクの高さ、クラスターのスケーラビリティの低さやバージョンアップの難しさによる運用管理の困難さ、ディザスタリカバリ機能の脆弱性などから、セルフマネージド ClickHouse クラスターからクラウドの PaaS (Platform as a Service) サービスにデータを移行したいというユーザーが増えています。このトピックでは、セルフマネージド ClickHouse クラスターから Community 互換 Edition を実行する ApsaraDB for ClickHouse クラスターにデータを移行する方法について説明します。
前提条件
移行先クラスター:
クラスターは Community 互換 Edition を実行しています。
クラスタ用にデータベースアカウントが作成されます。詳細については、「Community 互換エディションクラスタのデータベースアカウントを管理する」をご参照ください。
アカウントは特権アカウントです。詳細については、「ApsaraDB for ClickHouse コンソールまたは SQL 文を使用してデータベースアカウントの権限を変更する」をご参照ください。
セルフマネージドクラスター:
クラスター用にデータベースアカウントが作成されています。
アカウントは、データベースとテーブルに対する読み取り権限と、SYSTEM コマンドを実行する権限を持っています。
移行先クラスターはセルフマネージドクラスターに接続されています。
セルフマネージドクラスターと移行先クラスターが同じ VPC (Virtual Private Cloud) 内にある場合は、移行先クラスターのすべてのノードの IP アドレスと、移行先クラスターの [vSwitch] の [IPv4 CIDR ブロック] をセルフマネージドクラスターのホワイトリストに追加する必要があります。
ApsaraDB for ClickHouse クラスターのホワイトリストを構成する方法の詳細については、「ホワイトリストを構成する」をご参照ください。
セルフマネージドクラスターのホワイトリストを構成する方法の詳細については、関連ドキュメントをご参照ください。
SELECT * FROM system.clusters;文を実行して、ApsaraDB for ClickHouse クラスターのすべてのノードの IP アドレスをクエリできます。ApsaraDB for ClickHouse クラスターの [vSwitch] の [IPv4 CIDR ブロック] を取得するには、次の操作を実行します。
ApsaraDB for ClickHouse コンソールで、管理するクラスターを見つけ、クラスター名をクリックします。[クラスター情報] ページの [ネットワーク情報] セクションで、[vSwitch ID] を取得します。
vSwitch ページに移動し、[vSwitch ID] を使用して vSwitch を検索し、vSwitch の [IPv4 CIDR ブロック] を取得します。
セルフマネージドクラスターと移行先クラスターが異なる VPC にある場合、またはセルフマネージドクラスターがデータセンター内にあるか、サードパーティのサービスプロバイダーからのものである場合は、クラスター間の接続を確立する必要があります。詳細については、「移行先クラスターとデータソースの間に接続が確立できない場合はどうすればよいですか。」をご参照ください。
ビジネスの互換性を検証する
移行前に、テスト環境を作成してビジネスの互換性とシステムパフォーマンスを検証し、移行が正常に完了できるかどうかを確認することをお勧めします。検証が完了したら、本番環境でデータを移行できます。検証手順は、潜在的な問題を事前に特定して解決し、スムーズな移行を確保し、本番環境への悪影響を回避するのに役立つため、非常に重要です。
データを移行するための移行タスクを作成します。移行手順の詳細については、以下のセクションをご参照ください。
ビジネスの互換性とパフォーマンスボトルネック分析の詳細については、「セルフマネージド ClickHouse から ApsaraDB for ClickHouse への移行における互換性とパフォーマンスボトルネックの分析とソリューション」をご参照ください。
方法を選択する
移行方法 | メリット | デメリット | シナリオ |
視覚的にデータを移行でき、メタデータを手動で移行する必要がありません。 | クラスターのフルデータまたは増分データのみを移行します。特定のデータベース、テーブル、または既存データを移行することはできません。 | クラスター全体を移行する必要があります。 | |
移行するデータベースとテーブルを指定できます。 | 複雑な操作とメタデータの手動移行が必要です。 |
|
手順
ApsaraDB for ClickHouse コンソール
制限
移行先クラスターのバージョンは 21.8 以降である必要があります。
注意事項
移行中は、次の項目に注意してください。
移行プロセス中は、移行先クラスター内のデータベースとテーブルのマージは一時停止されますが、セルフマネージドクラスターでは継続されます。
説明移行に時間がかかりすぎる場合、移行先クラスターに過剰なメタデータが蓄積されます。移行タスクの期間を 5 日以内に設定することをお勧めします。
移行先クラスターはデフォルトクラスターである必要があります。セルフマネージドクラスターの名前が default でない場合、システムは分散テーブルのクラスター定義を自動的に default に変更します。
移行対象:
サポートされている オブジェクト:
データベース、データディクショナリ、マテリアライズドビュー。
テーブルスキーマ: Kafka テーブルと RabbitMQ テーブルのスキーマを除くすべてのテーブルスキーマ。
データ: MergeTree ファミリーエンジンを使用するテーブルの増分データ。
サポートされていない オブジェクト:
Kafka テーブルと RabbitMQ テーブル、およびデータ。
外部テーブルやログテーブルなど、MergeTree 以外のテーブルのデータ。
重要サポートされていないオブジェクトは手動で移行する必要があります。「手動移行」で説明されている手順に従って処理できます。
データ量:
コールドデータ: コールドデータの移行速度は比較的遅くなります。セルフマネージドクラスター内のコールドデータをクリーンアップして、コールドデータの合計量が 1 TB を超えないようにすることをお勧めします。そうしないと、移行に時間がかかりすぎる場合、移行が失敗する可能性があります。
ホットデータ: ホットデータの量が 10 TB を超える場合、移行タスクが失敗する可能性があります。他の移行方法を使用することをお勧めします。
上記の要件が満たされていない場合は、手動でデータを移行できます。詳細については、手動移行 をご参照ください。
クラスターへの影響
セルフマネージドクラスター:
セルフマネージドクラスターからデータを読み取ると、クラスターの CPU 使用率とメモリ使用量が増加します。
DDL 操作は許可されていません。
移行先クラスター:
移行先クラスターにデータを書き込むと、クラスターの CPU 使用率とメモリ使用量が増加します。
DDL 操作は許可されていません。
移行するデータベースとテーブルでは DDL 操作は許可されていません。この制限は、移行する必要のないデータベースとテーブルには課されません。
移行プロセス中は、データベースとテーブルのマージは一時停止されます。この制限は、移行する必要のないデータベースとテーブルには課されません。
移行先クラスターは、移行開始前と移行完了後に再起動されます。
移行後、クラスターは一定期間、頻繁なマージ操作を実行します。これにより、I/O 使用量が増加し、サービスリクエストのレイテンシが高くなります。サービスリクエストのレイテンシの潜在的な影響に対処するための計画を立てることをお勧めします。マージ操作の期間を計算する必要があります。詳細については、移行後のマージ操作の期間を計算する をご参照ください。
手順
ステップ 1: セルフマネージドクラスターの システム テーブルを有効にする
移行前に、セルフマネージドクラスターの config.xml ファイルを変更して、システムテーブル system.part_log と system.query_log を有効にし、増分移行を許可する必要があります。
system.part_log と system.query_log が無効になっている場合
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 が有効になっている場合
config.xml ファイルの
system.part_logとsystem.query_logの設定を確認し、設定が次のサンプルコードと一致することを確認して、移行の失敗や速度低下を回避します。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>設定を変更した後、
drop table system.part_log文とdrop table system.query_log文を実行する必要があります。ビジネステーブルにデータが挿入されると、system.part_logテーブルとsystem.query_logテーブルが再作成されます。
手順 2: セルフマネージドクラスターのバージョンと互換性を持つようにデスティネーションクラスターを構成する
デスティネーションクラスターがセルフマネージドクラスターと互換性があることを確認します。これにより、移行後のビジネス変更の必要性を最小限に抑えることができます。
デスティネーションクラスターとセルフマネージドクラスターのバージョン番号をクエリし、バージョン番号が同じかどうかを確認します。
クラスターに個別にログインし、次の文を実行してクラスターのバージョン番号をクエリします。詳細については、「データベース接続」をご参照ください。
SELECT version();バージョン番号が異なる場合は、デスティネーションクラスターにログインし、互換性パラメーターをセルフマネージドクラスターのバージョン番号に設定します。デスティネーションクラスターがセルフマネージドクラスターと機能的に互換性があることを確認します。サンプルコード:
SET GLOBAL compatibility = '22.8';
(オプション) 手順 3: MaterializedMySQL エンジンを移行先クラスターで有効にする
セルフマネージドクラスターに MaterializedMySQL エンジンを使用するテーブルが含まれている場合は、次の文を実行して、移行先クラスターで MaterializedMySQL エンジンを有効にします。
SET GLOBAL allow_experimental_database_materialized_mysql = 1;ClickHouse コミュニティでは、MaterializedMySQL エンジンは現在メンテナンスされていません。移行後に Data Transmission Service (DTS) を使用して MySQL データを同期することをお勧めします。
MaterializedMySQL エンジンはコミュニティによってメンテナンスされていないため、DTS を使用して MySQL データを ApsaraDB for ClickHouse クラスターに同期できます。同期の際、DTS は MaterializedMySQL テーブルを ReplacingMergeTree テーブルに置き換えます。詳細については、「MaterializedMySQL の互換性」をご参照ください。
MySQL データベースから ApsaraDB for ClickHouse クラスターにデータを移行するために DTS を使用する方法の詳細については、以下のトピックをご参照ください。
ステップ 4: 移行タスクを作成する
ApsaraDB for ClickHouse コンソール にログオンします。
[クラスタ] ページで、[Community 互換エディションのクラスタ] タブをクリックし、管理するクラスタの ID をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
表示されるページの左上隅にある [移行タスクの作成] をクリックします。
ソースクラスタとデスティネーションクラスタを構成します。
[ソースインスタンス情報] セクションと [デスティネーションインスタンス情報] セクションで必要なパラメーターを構成し、[接続テストと続行] をクリックします。
説明接続テストが成功したら、[移行コンテンツ] ステップに進みます。接続テストが失敗した場合は、プロンプトに従ってソースクラスタとデスティネーションクラスタを再構成します。

ソースクラスタを構成する
パラメーター
説明
例
ソースアクセス方法
アクセス方法。 Express Connect、VPN Gateway、Smart Access Gateway、または ECS インスタンス上のセルフマネージド ClickHouse を選択します。
Express Connect、VPN Gateway、Smart Access Gateway、または ECS インスタンス上のセルフマネージド ClickHouse
クラスタ名
ソースクラスタの名前。
値には数字と小文字を含めることができます。
source
ソースクラスタ名
SELECT * FROM system.clusters;文を実行して、クラスタ名 を取得する必要があります。default
VPC IP アドレス
クラスタ内の各シャードの IP アドレスとポート、または TCP アドレス。複数の値はカンマ (,) で区切ります。
重要ApsaraDB for ClickHouse クラスタの VPC ドメイン名、または Server Load Balancer (SLB) インスタンスの IP アドレスは使用できません。
形式:
IP:PORT,IP:PORT,......次のシナリオに基づいて、セルフマネージドクラスタの IP アドレスとポートをクエリできます。
アカウントまたはリージョンをまたがる ApsaraDB for ClickHouse クラスタの移行
セルフマネージドクラスタの IP アドレスとポートをクエリするには、次の SQL 文を実行します。
SELECT shard_num, replica_num, host_address as ip, port FROM system.clusters WHERE cluster = 'default' and replica_num = 1;上記の例では、replica_num=1 設定は、最初のレプリカセットが選択されていることを示しています。別のレプリカセットを選択するか、各シャードから 1 つのレプリカを選択してレプリカセットを形成することもできます。
ApsaraDB for ClickHouse 以外のクラスタの移行
セルフマネージドクラスタの IP アドレスが Alibaba Cloud IP アドレスにマッピングされていない場合は、次の 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 アドレスとポートにマッピングされている場合は、接続設定に基づいて IP アドレスとポートを構成する必要があります。
192.168.0.5:9000,192.168.0.6:9000
データベースアカウント
ソースクラスタ内のデータベースアカウントのユーザー名。
test
データベースパスワード
ソースクラスタ内のデータベースアカウントのパスワード。
test******
デスティネーションクラスタを構成する
パラメーター
説明
例
データベースアカウント
デスティネーションクラスタ内のデータベースアカウントのユーザー名。
test
データベースパスワード
デスティネーションクラスタ内のデータベースアカウントのパスワード。
test******
移行コンテンツを確認します。
表示されるページで、データ移行コンテンツに関する情報を読み、[次へ: 事前検出と同期開始] をクリックします。
システムは移行構成の事前チェックを実行し、事前チェックに合格した後、バックグラウンドで移行タスクを開始します。
システムは、ソースクラスタとデスティネーションクラスタに対して次の事前チェックを実行します: [インスタンスステータス検出]、[ストレージ容量検出]、および [ローカルテーブルと分散テーブルの検出]。
事前チェックが成功した場合は、次の操作を実行します。
事前チェックが成功すると、次の図に示す情報が表示されます。

クラスタへのデータ移行の影響に関する情報を読みます。
[完了] をクリックします。
重要構成を完了すると、タスクが作成され、実行中状態になります。タスクリストでタスクを表示できます。
移行タスクが作成された後、移行タスクを監視する必要があります。移行が完了に近づいたら、セルフマネージドクラスタへのデータの書き込みを停止し、残りのデータベースとテーブルスキーマを移行する必要があります。詳細については、「移行タスクの監視とセルフマネージドクラスタへのデータ書き込みの停止」をご参照ください。
事前チェックが失敗した場合は、画面上の指示に従って問題を解決し、移行タスクパラメーターを再構成する必要があります。次の表に、事前チェック項目と要件を示します。エラーと解決策の詳細については、「移行チェックで報告されたエラーのクエリとトラブルシューティング」をご参照ください。
項目
要件
クラスタステータス検出
データを移行する前に、スケールアウト、スペックアップ、またはスペックダウンなどの管理操作がセルフマネージドクラスタとデスティネーションクラスタで実行されていないことを確認してください。セルフマネージドクラスタとデスティネーションクラスタで管理操作が実行されている場合、システムは移行タスクを開始できません。
ストレージ容量検出
移行タスクが開始される前に、システムはセルフマネージドクラスタとデスティネーションクラスタのストレージ容量を確認します。デスティネーションクラスタのストレージ容量がセルフマネージドクラスタのストレージ容量の少なくとも 1.2 倍であることを確認してください。
ローカルテーブルと分散テーブルの検出
ローカルテーブル用に分散テーブルが作成されていない場合、または同じローカルテーブル用に複数の分散テーブルがセルフマネージドクラスタに作成されている場合、事前チェックは失敗します。冗長な分散テーブルを削除するか、一意の分散テーブルを作成する必要があります。
ステップ 5:移行タスクが完了できるかどうかを確認する
ソースクラスターの書き込み速度が 20 MB/s より低い場合は、このステップをスキップします。
ソースクラスターの書き込み速度が 20 MB/s より高い場合は、デスティネーションクラスターの書き込み速度を確認する必要があります。ほとんどの場合、デスティネーションクラスターのノードあたりの書き込み速度は 20 MB/s より高くなります。移行を成功させるには、デスティネーションクラスターの書き込み速度がソースクラスターの速度に追いついている必要があります。デスティネーションクラスターの実際の書き込み速度を確認するには、次の操作を実行します。
デスティネーションクラスターの [ディスクスループット] を確認して、実際の書き込み速度を判断します。 [ディスクスループット] の表示方法の詳細については、「クラスターのモニタリング情報を表示する」をご参照ください。
書き込み速度を比較します。
デスティネーションクラスターの書き込み速度がソースクラスターの書き込み速度より高い場合、移行は成功する可能性があります。ステップ 6 に進みます。
デスティネーションクラスターの書き込み速度がソースクラスターの書き込み速度より低い場合、移行は失敗する可能性があります。移行タスクをキャンセルし、手動でデータを移行することをお勧めします。詳細については、「移行タスクをキャンセルする」および「手動移行」をご参照ください。
ステップ 6:移行タスクを監視し、セルフマネージドクラスターへのデータ書き込みを停止する
ApsaraDB for ClickHouse コンソール にログインします。
[クラスター] ページで、[Community 互換エディションのクラスター] タブをクリックし、管理するクラスターの ID をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
表示されるページで、次の操作を実行します。
移行タスクのステータスと実行ステージ情報を確認します。
重要セルフマネージドクラスターへのデータの書き込みを停止し、[実行情報] 列に表示される推定残り時間に基づいて Kafka テーブルと RabbitMQ テーブルを管理します。詳細については、「ステップ 7:セルフマネージドクラスターへの書き込みを停止し、Kafka テーブルと RabbitMQ テーブルを管理する」をご参照ください。
[アクション] 列の [詳細の表示] をクリックして、タスクの詳細を表示します。タスクの詳細には、次の内容が含まれます。
説明注意:移行タスクが完了すると、タスクステータスは [完了] または [キャンセル] に変わり、 ページの内容はクリアされます。次の SQL 文を実行して、移行先のクラスターに移行されたテーブルスキーマを表示できます。
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 テーブルを削除する必要があります。次の操作を実行します。
セルフマネージド クラスター にログオンし、次の SQL 文を実行して、管理するテーブルをクエリします。
SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');/* 管理対象のテーブルをクエリするSQL文 */必要なテーブルを作成するための文を表示します。
SHOW CREATE TABLE <aim_table_name>;/* テーブル作成文を表示するSQL文 */宛先クラスター にログインし、前のステップで取得したテーブル作成文を実行します。宛先クラスターにログインする方法の詳細については、「DMS を使用して ApsaraDB for ClickHouse クラスターに接続する」をご参照ください。
セルフマネージド クラスター にログオンし、移行された Kafka と RabbitMQ のテーブルを削除します。
重要Kafka テーブルを削除する場合は、これらのテーブルを参照するマテリアライズドビューも削除する必要があります。そうしないと、マテリアライズドビューの移行が失敗する可能性があります。
ステップ 8: 移行タスクを完了する
セルフマネージドクラスターへのデータ書き込みを停止した後、タスクは残りのデータの移行、データボリュームチェックの実行、残りのデータベースとテーブルスキーマの移行を続行します。移行されたオブジェクトを表示する方法の詳細については、「詳細の表示」をご参照ください。
移行タスクがデータボリュームチェックに合格しなかった場合、移行タスクはデータボリュームチェックフェーズのままになります。この場合、移行タスクをキャンセルして再作成することをお勧めします。移行タスクをキャンセルする方法の詳細については、「その他の操作」をご参照ください。
移行に時間がかかりすぎる場合、宛先クラスターに過剰なメタデータが蓄積され、移行プロセスが遅くなる可能性があります。移行タスクが作成されてから 5 日以内にこの操作を完了することをお勧めします。
ApsaraDB for ClickHouse コンソール にログオンします。
[クラスター] ページで、[コミュニティ互換エディションのクラスター] タブをクリックし、管理するクラスターの ID をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
完了する移行タスクを見つけ、[アクション] 列の [移行の完了] をクリックします。
[移行の完了] メッセージで、[OK] をクリックします。
ステップ 9:MergeTree 以外のテーブルのデータを移行する
外部テーブルやログテーブルなどの MergeTree 以外のテーブルの移行中は、テーブルスキーマのみを移行できます。 移行が完了した後、移行先クラスター内のこれらのテーブルには、ビジネスデータではなく、テーブルスキーマのみが含まれます。 ビジネスデータは手動で移行する必要があります。 次の操作を実行します。
セルフマネージド クラスター にログインし、次の文を実行して、データ移行が必要な 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') ))/* セルフマネージドクラスターにログインし、次の文を実行して、データ移行が必要なMergeTree以外のテーブルを表示します。 */デスティネーション クラスター にログインし、
remoteテーブルデータを宛先クラスターに移行する関数。詳細については、「 関数を使用して、テーブルデータを移行先クラスターに移行します。 詳細については、「remote 関数を使用してデータを移行する」をご参照ください。
その他の操作
移行タスクが完了すると、タスクの [移行ステータス] が 完了 に変わります。ただし、タスクリストはすぐに更新されません。タスクステータスを表示するために、一定の間隔でタスクリストをリフレッシュすることをお勧めします。
操作 | 説明 | 影響 | シナリオ |
移行タスクをキャンセルする | タスクを強制的にキャンセルし、データボリュームチェックをスキップし、残りのデータベースまたはテーブルスキーマを移行しません。 |
| 移行タスクは自己管理型クラスタに影響を与えます。移行タスクを停止し、できるだけ早くクラスタにデータを書き込みたいと考えています。 |
移行タスクを停止する | データの移行をすぐに停止し、データボリュームチェックをスキップし、残りのデータベースとテーブルスキーマを移行します。 | 移行先クラスタが再起動されます。 | 一定量のデータを移行してテストを実行したいと考えています。自己管理型クラスタへのデータの書き込みを停止したくありません。 |
移行タスクを停止する
ApsaraDB for ClickHouse コンソール にログオンします。
[クラスタ] ページで、[コミュニティ互換版のクラスタ] タブをクリックし、管理するクラスタの ID をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
停止する移行タスクを見つけ、[アクション] 列の [移行の停止] をクリックします。
[移行の停止] メッセージで、[OK] をクリックします。
移行タスクをキャンセルする
ApsaraDB for ClickHouse コンソール にログオンします。
[クラスタ] ページで、[コミュニティ互換版のクラスタ] タブをクリックし、管理するクラスタの ID をクリックします。
左側のナビゲーションウィンドウで、 を選択します。
キャンセルする移行タスクを見つけ、[アクション] 列の [移行のキャンセル] をクリックします。
[移行のキャンセル] メッセージで、[OK] をクリックします。
手動移行
手順 1: メタデータの移行(テーブル作成用の DDL 文)
ClickHouse メタデータの移行は、主にテーブルの作成に使用される DDL 文の移行を伴います。
clickhouse-client をインストールする必要がある場合は、clickhouse-client のバージョンが移行先 ApsaraDB for ClickHouse クラスターのバージョンと一致していることを確認してください。 clickhouse-client のダウンロード方法の詳細については、「clickhouse-client」をご参照ください。
セルフマネージドクラスター内のデータベースをクエリします。
clickhouse-client --host="<old host>" --port="<old port>" --user="<old user name>" --password="<old password>" --query="SHOW databases" > database.listパラメーター
パラメーター
説明
old host
セルフマネージドクラスターのエンドポイント。
old port
セルフマネージドクラスターのポート。
old user name
セルフマネージドクラスターにログインするために使用するアカウントのユーザー名。ユーザーは、読み取り、書き込み、権限の設定など、特定の DML 文を実行する権限を持っている必要があります。また、ユーザーは DDL 文を実行する権限も持っている必要があります。
old password
セルフマネージドクラスターにログインするために使用するアカウントのパスワード。
説明system はシステムデータベースを指定します。これは移行する必要はありません。移行中にこのデータベースをスキップできます。
セルフマネージドクラスター内のテーブルをクエリします。
clickhouse-client --host="<old host>" --port="<old port>" --user="<old user name>" --password="<old password>" --query="SHOW tables from <database_name>" > table.listパラメーター
パラメーター
説明
database_name
データベース名。
システムテーブルを使用して、クラスター内のすべてのデータベースとテーブルの名前をクエリできます。
SELECT DISTINCT database, name FROM system.tables WHERE database != 'system';説明.inner. で始まる名前のテーブルは、マテリアライズドビューの内部表現であり、移行する必要はありません。移行中にこれらのテーブルをスキップできます。
セルフマネージドクラスターの指定されたデータベース内のテーブルを作成するために使用される DDL 文をエクスポートします。
clickhouse-client --host="<old host>" --port="<old port>" --user="<old user name>" --password="<old password>" --query="SELECT concat(create_table_query, ';') FROM system.tables WHERE database='<database_name>' FORMAT TabSeparatedRaw" > tables.sqlDDL 文を移行先クラスターにインポートします。
説明DDL 文をインポートする前に、DDL 文で定義されたテーブルをホストするために、移行先クラスターにデータベースが作成されていることを確認してください。
clickhouse-client --host="<new host>" --port="<new port>" --user="<new user name>" --password="<new password>" -d '<database_name>' --multiquery < tables.sqlパラメーター
パラメーター
説明
new host
移行先クラスターのエンドポイント。
new port
移行先クラスターのポート。
new user name
移行先クラスターにログインするために使用するアカウントのユーザー名。ユーザーは、読み取り、書き込み、権限の設定など、特定の DML 文を実行する権限を持っている必要があります。また、ユーザーは DDL 文を実行する権限も持っている必要があります。
new password
移行先クラスターにログインするために使用するアカウントのパスワード。
手順 2: データの移行
remote 関数を使用してデータを移行する
移行先の ApsaraDB for ClickHouse クラスターで次の SQL 文を実行して、データを移行します。
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;説明ApsaraDB for ClickHouse V20.8 の場合、remoteRaw 関数を使用してデータを移行することをお勧めします。データの移行に失敗した場合は、マイナーバージョンアップデートを申請できます。
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;パラメーター
重要partition_id パラメーターを使用してデータをフィルタリングし、リソース使用量を削減できます。このパラメーターを使用することをお勧めします。
パラメーター
説明
new_database
移行先クラスターのデータベース名。
new_table
移行先クラスターのテーブル名。
old_endpoint
セルフマネージドクラスターのエンドポイント。
セルフマネージドクラスター
セルフマネージドクラスターのエンドポイントは、
セルフマネージドクラスターのノードの IP アドレス:ポート形式です。重要この場合、ポートは TCP ポートです。
ApsaraDB for ClickHouse クラスター
ApsaraDB for ClickHouse クラスターのエンドポイントは、パブリックエンドポイントではなく VPC エンドポイントです。
重要ポート 3306 は ApsaraDB for ClickHouse Community 互換 Edition クラスターのデフォルトポートであり、ポート 9000 は ApsaraDB for ClickHouse Enterprise Edition クラスターのデフォルトポートです。
Community 互換 Edition クラスター:
エンドポイントは
VPC エンドポイント:3306形式です。例:
cc-2zeqhh5v7y6q*****.clickhouse.ads.aliyuncs.com:3306.
Enterprise Edition クラスター:
エンドポイントは
VPC エンドポイント:9000形式です。例:
cc-bp1anv7jo84ta*****clickhouse.clickhouseserver.rds.aliyuncs.com:9000.
old_database
セルフマネージドクラスターのデータベース名。
old_table
セルフマネージドクラスターのテーブル名。
username
セルフマネージドクラスターのアカウントのユーザー名。
password
セルフマネージドクラスターのアカウントのパスワード。
max_execution_time
クエリの最大実行時間。値 0 は制限がないことを示します。
max_bytes_to_read
クエリ中にソースデータから読み取ることができる最大バイト数。値 0 は制限がないことを示します。
log_query_threads
クエリスレッドに関する情報を記録するかどうかを指定します。値 0 は、クエリスレッドに関する情報が記録されないことを示します。
_partition_id
データパーティションの ID。
ファイルをエクスポートおよびインポートしてデータを移行する
セルフマネージドクラスターからファイルをエクスポートし、そのファイルを移行先クラスターにインポートしてデータを移行できます。
CSV ファイルをエクスポートおよびインポートする
セルフマネージドクラスターから CSV ファイルにデータをエクスポートします。
clickhouse-client --host="<old host>" --port="<old port>" --user="<old user name>" --password="<old password>" --query="select * from <database_name>.<table_name> FORMAT CSV" > table.csvCSV ファイルを移行先クラスターにインポートします。
clickhouse-client --host="<new host>" --port="<new port>" --user="<new user name>" --password="<new password>" --query="insert into <database_name>.<table_name> FORMAT CSV" < table.csv
Linux でパイプを使用してストリーミングデータをエクスポートおよびインポートする
clickhouse-client --host="<old host>" --port="<old port>" --user="<user name>" --password="<password>" --query="select * from <database_name>.<table_name> FORMAT CSV" | clickhouse-client --host="<new host>" --port="<new port>" --user="<user name>" --password="<password>" --query="INSERT INTO <database_name>.<table_name> FORMAT CSV"
移行チェックで報告されたエラーのクエリとトラブルシューティング
エラーメッセージ | 説明 | 解決策 |
一意の分散テーブルがないか、sharding_key が設定されていません。 | セルフマネージドクラスターのローカルテーブルに関連付けられた一意の分散テーブルが存在しません。 | 移行前に、セルフマネージドクラスターのローカルテーブルの分散テーブルを作成します。 |
対応する分散テーブルが一意ではありません。 | セルフマネージドクラスターのローカルテーブルは、複数の分散テーブルに関連付けられています。 | 冗長な分散テーブルを削除し、1 つの分散テーブルを保持します。 |
複数レプリカクラスター上の MergeTree テーブル | セルフマネージドクラスターは複数レプリカクラスターであり、レプリケートされたテーブルが含まれています。この場合、データはレプリカ間で一貫性がなく、移行できません。 | 詳細については、「複数レプリカクラスターをスケールアップまたはスケールダウン、あるいは移行するときに、非レプリケートテーブルが許可されないのはなぜですか。」をご参照ください。 |
宛先クラスター上のデータ予約テーブル | 宛先テーブルには既にデータが含まれています。 | データを含む宛先テーブルを削除します。 |
分散テーブルとローカルテーブルの列が競合しています | 分散テーブルの列がローカルテーブルの列と一致しません。 | セルフマネージドクラスターで分散テーブルを再構築し、分散テーブルの列がローカルテーブルの列と一致することを確認します。 |
ストレージが不足しています。 | 宛先クラスターのストレージ容量が不足しています。 | 宛先クラスターのストレージ容量を、セルフマネージドクラスターのストレージ容量の少なくとも 1.2 倍に拡張します。詳細については、「ApsaraDB for ClickHouse Community 互換エディションクラスターの構成を変更する」をご参照ください。 |
システムテーブルがありません。 | セルフマネージドクラスターのシステムテーブルがありません。 | 必要なシステムテーブルを作成するには、セルフマネージドクラスターの config.xml ファイルを変更します。詳細については、「手順 1: セルフマネージドクラスターのシステムテーブルを有効にする」をご参照ください。 |
移行後のマージ操作時間の計算
移行後、宛先クラスターは一定期間、頻繁なマージ操作を実行します。これにより、I/O 使用率が増加し、サービスリクエストのレイテンシが高くなります。ビジネスで読み取りおよび書き込みレイテンシが重要な場合は、マージ操作による高 I/O 使用率の期間を短縮するために、インスタンスタイプとディスクパフォーマンスレベルをスペックアップすることをお勧めします。詳細については、「ApsaraDB for ClickHouse Community 互換エディションクラスターの構成を変更する」をご参照ください。
移行後のマージ操作の時間は、次の数式を使用して計算できます。
この数式は、シングルレプリカエディションクラスターとダブルレプリカエディションクラスターに適用されます。
推定マージ時間 =
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 メモリ
1,250
標準タイプ、80 コア、384 GB メモリ
2,000
標準タイプ、104 コア、384 GB メモリ
2,000
ディスクスループット: ESSD PL 表で、ディスクあたりの最大スループット (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 書き込み帯域幅: 内部ネットワークとインターネットの合計アップロード帯域幅帯域幅 表の 内部ネットワークとインターネットの合計アップロード帯域幅 列のデータを表示できます。
よくある質問
「Too many partitions for single INSERT block (more than 100)」というエラーメッセージが表示された場合はどうすればよいですか?
単一の INSERT 操作におけるパーティション数が、max_partitions_per_insert_block パラメーターの値を超えています。 max_partitions_per_insert_block パラメーターのデフォルト値は 100 です。ApsaraDB for ClickHouse は、書き込み操作ごとにデータパーツを生成します。パーティションには、1 つ以上のデータパーツが含まれる場合があります。単一の INSERT 操作で挿入されるパーティション数が過度に多い場合、多数のデータパーツが生成され、マージ操作とクエリ操作に大きな負荷がかかる可能性があります。多数のデータパーツが生成されないようにするために、ApsaraDB for ClickHouse には特定の制限が課されています。
解決策:次の操作を実行して、パーティション数または max_partitions_per_insert_block パラメーターの値を調整します。
テーブルスキーマとパーティションモードを調整するか、一度に挿入されるパーティション数が上限を超えないようにします。
一度に挿入されるパーティション数が上限を超えないようにするには、次の文を実行して、データボリュームに基づいて max_partitions_per_insert_block パラメーターの値を増やします。
SET GLOBAL ON cluster DEFAULT max_partitions_per_insert_block = XXX;説明ClickHouse では、max_partitions_per_insert_block の推奨デフォルト値は 100 です。 max_partitions_per_insert_block パラメーターを過度に大きな値に設定しないでください。設定すると、パフォーマンスに影響する可能性があります。バッチデータのインポートが完了したら、パラメーターをデフォルト値にリセットできます。
宛先 ApsaraDB for ClickHouse クラスターがセルフマネージド ClickHouse クラスターに接続できないのはなぜですか?
セルフマネージド ClickHouse クラスターにファイアウォールまたはホワイトリストが設定されている可能性があります。 ApsaraDB for ClickHouse の [vSwitch] の [IPv4 CIDR ブロック] をセルフマネージド ClickHouse クラスターのホワイトリストに追加する必要があります。詳細については、「IPv4 CIDR ブロックを表示する」をご参照ください。
マルチレプリカクラスターをスケールアップまたはスケールダウンしたり、移行したりするときに、非レプリケートテーブルが許可されないのはなぜですか? 非レプリケートテーブルが存在する場合はどうすればよいですか?
次のセクションでは、問題の原因と関連する解決策について説明します。
原因分析:マルチレプリカクラスターでは、レプリケートテーブルを使用して、レプリカ間でデータを同期します。移行ツールは、レプリカの 1 つをランダムに選択してデータソースとして、宛先クラスターにデータを移行します。
非レプリケートテーブルが存在する場合、異なるレプリカ間でデータを同期できません。その結果、各レプリカに異なるデータが含まれる可能性があります。移行ツールは、レプリカの 1 つからのみデータを移行するため、データが失われます。次の図では、r0 という名前のレプリカの MergeTree テーブルにはレコード 1、2、3 が含まれており、r1 という名前のレプリカの MergeTree テーブルにはレコード 4 と 5 が含まれています。この場合、レコード 1、2、3 のみが宛先クラスターに移行されます。
解決策:ソースクラスター内の非レプリケートテーブルを削除できる場合は、テーブルを削除することをお勧めします。削除できない場合は、ソースクラスター内の非レプリケートテーブルをレプリケートテーブルに置き換える必要があります。手順:
ソースクラスターにログオンします。
レプリケートテーブルを作成します。テーブルエンジン以外は、テーブルスキーマが同一であることを確認します。
非レプリケートテーブルから新しいレプリケートテーブルに手動でデータを移行します。次のコードは、文の例を示しています。
重要各レプリカの非レプリケートテーブルのすべてのデータを、対応するレプリケートテーブルに移行する必要があります。この例では、サンプル文をレプリカ r0 と r1 で実行する必要があります。
SELECT * FROM system.clusters;文を実行して、次のサンプル文のノード IP アドレスパラメーターの値をクエリできます。INSERT INTO <宛先データベース>.<新しいレプリケートテーブル> SELECT * FROM remote('<ノード IP アドレス>:3003', '<ソースデータベース>', '<置き換える非レプリケートテーブル>', '<ユーザー名>', '<パスワード>') [WHERE _partition_id = '<partition_id>'] SETTINGS max_execution_time = 0, max_bytes_to_read = 0, log_query_threads = 0;非レプリケートテーブルとレプリケートテーブルの名前を交換します。
EXCHANGE TABLES <ソースデータベース>.<置き換える非レプリケートテーブル> AND <宛先データベース>.<新しいレプリケートテーブル> ON CLUSTER default;