ApsaraDB for ClickHouse Community-Compatible Edition クラスターの高可用性 (HA) を向上させるために、マルチゾーンデプロイメントにアップグレードできます。このプロセスでは、単一レプリカのクラスターを 2 レプリカのクラスターに、または単一ゾーンのクラスターをマルチゾーンのクラスターにアップグレードします。
前提条件
クラスターが Community-Compatible Edition クラスターであること。
クラスターが「実行中」ステータスであること。
クラスターに未払いの更新注文がないこと。
説明ApsaraDB for ClickHouse コンソールにログインします。ページの右上隅で、[請求] > [経費とコスト] を選択します。左側のナビゲーションウィンドウで、[注文管理] をクリックします。その後、注文の支払いまたはキャンセルができます。
注意事項
クラスターをマルチゾーンデプロイメントにアップグレードすると、MergeTree エンジンテーブルの既存データが新しいクラスターに移行され、自動的に再分散されます。
次の項目は移行がサポートされています:
データベース、データディクショナリ、マテリアライズドビュー。
テーブルスキーマ: Kafka または RabbitMQ エンジンを使用するテーブルを除くすべてのテーブルスキーマ。
データ: MergeTree ファミリーテーブルからのデータの増分移行。
次の項目は移行がサポートされていません:
Kafka または RabbitMQ エンジンを使用するテーブルとそのデータ。
重要構成を変更すると、データは新しいインスタンスに移行され、最終的にトラフィックは新しいインスタンスに切り替えられます。Kafka と RabbitMQ のデータが分割されないようにするには、まずソースクラスターから Kafka と RabbitMQ のエンジンテーブルを削除します。変更が完了したら、それらを再作成します。
外部テーブルや Log テーブルなど、MergeTree タイプではないテーブルのデータ。
重要アップグレード中は、この Topic の手順に従って、サポートされていないコンテンツを手動で処理する必要があります。
マルチゾーンデプロイメントへのアップグレード中は、データ定義言語 (DDL) 操作を実行しないでください。実行した場合、アップグレードの最後にデータ検証が失敗し、アップグレードが失敗する原因となります。
マルチゾーンデプロイメントへのアップグレード後、内部ノードの IP アドレスが変更されます。データ書き込みおよびアクセス操作がノードの IP アドレスに依存している場合は、クラスターの VPC CIDR ブロックを再度取得する必要があります。詳細については、「クラスターの VPC CIDR ブロックを取得する」をご参照ください。
クラスター構成を変更した後、一定期間、頻繁にマージ操作が発生します。これらの操作により I/O 使用量が増加し、ビジネスリクエストのレイテンシーが増加する可能性があります。このレイテンシー増加による潜在的な影響を計画する必要があります。マージ操作の期間を計算する方法の詳細については、「移行後のマージ期間を計算する」をご参照ください。
マルチゾーンデプロイメントへのアップグレード中、クラスターの CPU とメモリ使用量が増加します。ノードあたりの推定リソース使用量は、5 コア未満、メモリ 20 GB 未満です。
コスト
クラスター構成を変更すると、コストが変わります。実際のコストはコンソールに表示されます。詳細については、「構成変更の課金」をご参照ください。
手順
ステップ 1: Kafka および RabbitMQ エンジンを持つテーブルの処理
Kafka または RabbitMQ エンジンを使用するテーブルの移行はサポートされていません。これらのテーブルは手動で処理する必要があります。
クラスターにログインし、次の文を実行して処理する必要があるテーブルをクエリします。詳細については、「DMS を使用して ClickHouse クラスターに接続する」をご参照ください。
SELECT * FROM `system`.`tables` WHERE engine IN ('RabbitMQ', 'Kafka');各ターゲットテーブルの `CREATE TABLE` 文を表示してバックアップします。
SHOW CREATE TABLE <aim_table_name>;Kafka および RabbitMQ エンジンを使用するテーブルを削除します。
重要Kafka テーブルを削除するときは、それを参照するマテリアライズドビューも削除する必要があります。そうしないと、スケールアウトまたはスケールイン操作が失敗します。
ステップ 2: 非 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 テーブルからデータをバックアップする必要があります。詳細については、「OSS へのデータのバックアップ」をご参照ください。
ステップ 3: コンソールでアップグレードを実行する
ApsaraDB for ClickHouse コンソールにログインします。
ページの左上隅で、クラスターが配置されているリージョンを選択します。
[クラスター] ページで、[Community-Compatible Edition] を選択します。
ターゲットの [クラスター ID] の [アクション] 列で、[構成の変更] をクリックします。
[構成の変更] ダイアログボックスで、[マルチゾーンデプロイメントへのアップグレード] を選択し、[OK] をクリックします。
表示される検出ウィンドウで、検出ステータスを確認します。
検出成功: [次へ] をクリックします。
検出失敗: ページに表示されるプロンプトに従って変更を加え、[再試行] をクリックします。検出が成功したら、[次へ] をクリックします。
アップグレード中の検出は、いくつかの理由で失敗する可能性があります。
一意の分散テーブルの欠落: ローカルテーブルに対応する分散テーブルがありません。作成する必要があります。
対応する分散テーブルが一意でない: ローカルテーブルに複数の分散テーブルがあります。余分な分散テーブルを削除し、1 つだけ保持します。
Kafka/RabbitMQ エンジンテーブルはサポートされていません: Kafka または RabbitMQ エンジンテーブルが存在します。それらを削除してください。
プライマリレプリカインスタンスに、レプリケートされていない
*MergeTreeテーブルがあります: レプリカ間でデータが不整合です。これにより、スケールアウトまたはスケールイン操作のデータ移行中に例外が発生します。分散テーブルとローカルテーブルの列が不整合です: 分散テーブルとローカルテーブルの列が一致していることを確認する必要があります。そうしないと、スケールアウトまたはスケールイン操作のデータ移行中に例外が発生します。
一部のノードでテーブルが欠落しています: 異なるシャードに同じ名前のテーブルを作成する必要があります。マテリアライズドビューの内部テーブルについては、内部テーブルの名前を変更し、名前が変更された内部テーブルを指すようにマテリアライズドビューを再構築します。詳細については、「マテリアライズドビューの内部テーブルがシャード間で不整合である」をご参照ください。
[アップグレード/ダウングレード] ページで、必要に応じてデプロイメント計画、ゾーン、VPC vSwitch、および書き込み中断時間を構成します。
説明マルチゾーンデプロイメントへのアップグレードにはデータ移行が含まれます。移行を成功させるために、書き込み中断時間は次の要件に従う必要があります:
書き込み中断時間を少なくとも 30 分に設定します。
アップグレードは、構成変更が作成されてから 5 日以内に完了する必要があります。したがって、[書き込み中断終了時間] の日付は
現在の日付 + 5以下である必要があります。移行がビジネスに与える影響を軽減するために、書き込み中断時間をオフピーク時間に設定します。
[今すぐ購入] をクリックし、プロンプトに従って支払いを完了します。
[注文完了] ページで、[管理コンソール] をクリックします。
[Community-Compatible Edition] リストの [ステータス] 列で、ターゲットクラスターのステータスを表示できます。クラスターのステータスが Scaling から Running に変わると、アップグレードは完了です。
マルチゾーンデプロイメントへのアップグレードには 30 分以上かかると予想されます。期間はデータ量によって異なります。実際のタスクステータスは、コンソールに表示されるクラスターのステータスによって示されます。
ステップ 4: Kafka および RabbitMQ エンジンを持つテーブルを再作成する
クラスターにログインし、「ステップ 1: Kafka および RabbitMQ エンジンを持つテーブルの処理」でバックアップした `CREATE TABLE` 文を実行します。詳細については、「DMS を使用して ClickHouse クラスターに接続する」をご参照ください。
ステップ 5: 非 MergeTree テーブルからビジネスデータを移行する
クラスターにログインし、OSS を使用して、「ステップ 2: 非 MergeTree テーブルからビジネスデータをバックアップする」でバックアップしたデータを移行します。詳細については、「OSS からデータをインポートする」をご参照ください。