ApsaraDB for ClickHouse:ワンクリックでのメジャーエンジンバージョンアップグレード

前提条件

クラスターは[実行中]状態です。

注意事項

• ワンクリックでのメジャーエンジンバージョンアップグレードプロセスは、開始後にキャンセルすることはできません。

  説明

  ワンクリックでのメジャーエンジンバージョンアップグレード後のバージョンロールバックはサポートされていません。アップグレード後に以前のバージョンにロールバックできるようにする必要がある場合は、クラスターをクローンしてアップグレードを実行できます。詳細については、「クローンによるメジャーエンジンバージョンのアップグレード」をご参照ください。

• スムーズなアップグレードを確実にするために、アップグレードを開始する前にアプリケーションからの書き込み操作を停止することを推奨します。プロセス中にクラスターは自動的に書き込み操作を停止しますが、事前にアプリケーション側で停止しない場合、長い遅延が発生したり、同期が迅速に完了しなかったりする可能性があります。これにより、アップグレードが遅くなることがあります。

• ビジネスへの影響を最小限に抑えるために、アップグレード前に以下の検証を実行することを強く推奨します：

  • 互換性とパフォーマンスの検証：書き込みおよびクエリ操作の機能、構文、パフォーマンスの違いを確認します。

  • アップグレード所要時間の検証：バージョンアップグレード中にインスタンスは複数回再起動します。一部のインスタンスでは、データベース、テーブル、またはパーティション (parts) の数が多いため、1 回の再起動に時間がかかる場合があります。

    重要

    クラスターがホットデータとコールドデータの階層型ストレージを使用しており、クローン検証を実行する場合、ワンクリックアップグレードは検証よりも時間がかかります。これは、クローン操作にはコールドデータが含まれないのに対し、実際のアップグレードには含まれるためです。

  検証の実行方法については、「バージョン互換性の検証」をご参照ください。

クラスターへの影響

バージョンアップグレード中にクラスターは複数回再起動します。これらの再起動中、クラスターは読み取りおよび書き込み操作の両方で利用できなくなります。オフピーク時間帯にアップグレードを実行することを推奨します。

バージョン互換性の検証

ワンクリックでのメジャーエンジンバージョンアップグレードはロールバックできないため、最初にアップグレードをテストすることを強く推奨します。新しいバージョンがソースバージョンの機能と完全に互換性があり、アップグレードの所要時間が許容範囲であることを確認してから続行してください。検証を実行するには、次の手順に従ってください：

1. ターゲットインスタンスのクラスター情報 ページに移動します。左側のナビゲーションウィンドウで、バックアップリカバリ をクリックします。インスタンスがバックアップされたら、インスタンスの復元 をクリックします。

2. [リアルタイムレプリカからクローン] を選択し、ターゲットエンジンバージョンをアップグレードしたいバージョンに設定します。

3. クローンされたクラスターを作成します。

4. 互換性検証を実行します。

   1. ビジネスのクエリと新しいバージョンとの互換性を検証します。詳細については、「SQL 互換性検証」をご参照ください。

   2. ビジネス機能の回帰テストを実行します。

操作手順

1. Alibaba Cloud アカウントで ApsaraDB for ClickHouse コンソールにログインします。

2. ページ左上で、対象クラスターが配置されているリージョンを選択します。

3. 左側のナビゲーションウィンドウで、Community Edition インスタンスのリスト をクリックします。

4. 目的のクラスターを探し、クラスター ID をクリックすると、クラスター情報 ページに移動します。

5. クラスターのプロパティ セクションで、メジャーバージョンのアップグレード を、バージョン の横でクリックします。

6. プロンプトに従って次のパラメーターを設定し、を決定 をクリックしてください。

   パラメーター	説明	例
   クラスターカーネルのバージョンをアップグレード	ターゲットクラスターのバージョン。アップグレード後のバージョンロールバックはサポートされていません。 現在、バージョン 23.8 のみがサポートされています。	23.8 (LTS バージョン)
   バージョンアップグレードの実行時間	クラスターアップグレードを実行する時間。 重要 指定した時間またはメンテナンスウィンドウ内のアップグレードを選択した場合、クラスターのステータスは実行中からバージョンをアップグレードしていますに変わります。指定した時間またはメンテナンスウィンドウになるまで、クラスターは読み取りおよび書き込みリクエストを通常どおり処理できますが、インスタンス構成の変更、スケーリング、移行などのメンテナンス操作は実行できません。 指定時間：将来の時点を選択してメジャーバージョンアップグレードを実行します。 メンテナンス可能な時間帯にアップグレードする：アップグレードは、クラスターに設定されたメンテナンスウィンドウ中に実行されます。 今すぐアップグレード：すぐにアップグレードを開始します。	2024-05-29 14:46
   クローン検証の実行	クローン検証が実行されました または クローン検証のスキップ (非推奨) を選択します。	クローン検証済み

前提条件

クラスターは[実行中]の状態です。

注意事項

• ワンクリックでのメジャーエンジンバージョンアップグレードは単一のクラスターのみを対象とし、アップグレード完了後にバージョンロールバックはできません。

  説明

  ワンクリックでのメジャーエンジンバージョンアップグレード後のバージョンロールバックはサポートされていません。アップグレード後に以前のバージョンにロールバックできるようにする必要がある場合は、データ移行によってアップグレードを実行できます。詳細については、「データ移行によるメジャーエンジンバージョンのアップグレード」をご参照ください。

• クラスターをアップグレードする際、そのデータベースとテーブルについて以下の点にご注意ください：

  • MergeTree ファミリーエンジンを使用するテーブルの場合、既存データは新しいクラスターに移行され、アップグレード中に自動的に再分散されます。

  • 外部テーブルや Log テーブルなど、MergeTree ファミリーエンジンを使用しないテーブルの場合、テーブルスキーマのみが移行され、データは移行されません。

  • マテリアライズドビューの場合、スキーマのみが移行され、データは移行されません。

  • Kafka および RabbitMQ エンジンテーブルは、コンソールのアップグレード機能を通じて直接移行することはできません。アップグレードタスクへの干渉を防ぐため、これらのテーブルの DDL 文を記録し、アップグレード前にクラスターから削除する必要があります。アップグレード完了後、これらのテーブルを再構築する必要があります。詳細な手順については、以下の手順をご参照ください。

  • アップグレード後、内部ノードの IP アドレスが変更されます。データの書き込みやアクセスがノードの IP アドレスに依存している場合は、クラスターの新しい VPC CIDR ブロックを取得する必要があります。

• ビジネスへの影響を最小限に抑えるために、アップグレード前に以下の検証を実行することを強く推奨します：

  • 互換性とパフォーマンスの検証：書き込みおよびクエリ操作の機能、構文、パフォーマンスの違いを確認します。

  • アップグレード所要時間の検証：バージョンアップグレード中にインスタンスは複数回再起動します。一部のインスタンスでは、データベース、テーブル、またはパーティション (parts) の数が多いため、1 回の再起動に時間がかかる場合があります。

  検証の実行方法については、「バージョン互換性の検証」をご参照ください。

クラスターへの影響

Community Edition クラスターは、移行の最後の 10 分間に読み取り専用になるのを除き、アップグレードプロセス全体を通じて読み取りおよび書き込みが可能です。残りの移行時間を確認するには、「アップグレードの進捗状況の表示」をご参照ください。

バージョン互換性の検証

ワンクリックでのメジャーエンジンバージョンアップグレードはロールバックできないため、最初にアップグレードをテストすることを強く推奨します。新しいバージョンがソースバージョンの機能と完全に互換性があり、アップグレードの所要時間が許容範囲であることを確認してから続行してください。検証を実行するには、次の手順に従ってください：

1. 新しいクラスターを購入して移行検証を実行します。詳細については、「データ移行によるメジャーエンジンバージョンのアップグレード」をご参照ください。

2. 新しいクラスターで、SQL 互換性検証を実行します。詳細については、「SQL 互換性検証」をご参照ください。

3. ビジネス機能の回帰テストを実行します。

ステップ 1：Kafka/RabbitMQ エンジンテーブルの記録とクリーンアップ

Kafka および RabbitMQ エンジンテーブルは、コンソールのアップグレード機能を通じて直接移行することはできません。アップグレードタスクへの干渉を防ぐため、これらのテーブルの DDL 文を記録し、アップグレード前にクラスターから削除する必要があります。

1. クラスターにログオンし、次のステートメントを実行して処理が必要なテーブルをクエリします。

   /*
   create_table_query: テーブル定義文
   dependencies_database: このテーブルに依存するデータベース
   dependencies_table: このテーブルに依存するテーブル名
   dependencies_database と dependencies_table を使用して、Kafka/RabbitMQ テーブルに依存するマテリアライズドビューを特定します
   */
   SELECT * FROM system.tables WHERE engine IN ('RabbitMQ', 'Kafka');

2. マテリアライズドビューの定義を表示して、そのターゲットテーブルが暗黙的なテーブルであるかどうかを確認します。

   /*
   マテリアライズドビューの定義を表示します。
   マテリアライズドビューのターゲットテーブルが暗黙的なテーブルである場合、次の点に注意してください：
   マテリアライズドビューを削除すると、暗黙的なテーブルも削除され、データ損失が発生します。
   例：CREATE MATERIALIZED VIEW [db.]table_name [TO[db.]name] が TO 句を指定しない場合、
   システムは自動的に '.inner_id.<TABLE_UUID>' または '.inner.<TABLE>' の形式で暗黙的なテーブルを作成します
   */
   SELECT * FROM system.tables WHERE database='<DATABASE>' AND name = '<MATERIALIZED_VIEW_NAME>';

3. マテリアライズドビューが TO 句なしで作成された場合、システムは自動的に .inner または .inner_id というプレフィックスを持つ暗黙的なターゲットテーブルを生成します。これらの暗黙的なテーブルはアップグレード中に新しいクラスターノードに移行されますが、内部の命名メカニズムにより、元のマテリアライズドビューを直接再作成すると命名の競合が発生する可能性があります。したがって、まず暗黙的なターゲットテーブルを通常のテーブル名に名前変更する必要があります。

   -- 暗黙的なターゲットテーブルを通常のテーブル名に名前変更します (すべてのノードで実行)
   RENAME TABLE <database>.`.inner_id.<uuid>` TO <database>.<new_target_table_name> ON CLUSTER default;

4. マテリアライズドビューと Kafka/RabbitMQ エンジンテーブルを削除します。

   重要

   最初に Kafka/RabbitMQ テーブルを参照するマテリアライズドビューを削除し、次に Kafka/RabbitMQ エンジンテーブルを削除する必要があります。そうしないと、アップグレード操作は失敗します。

   -- 最初にマテリアライズドビューを削除します
   DROP TABLE <database>.<materialized_view_name> ON CLUSTER default;
   
   -- 次に Kafka/RabbitMQ エンジンテーブルを削除します
   DROP TABLE <database>.<kafka_or_rabbitmq_table_name> ON CLUSTER default;

ステップ 2：クラスターのアップグレード

1. Alibaba Cloud アカウントで ApsaraDB for ClickHouse コンソールにログインします。

2. ページ左上で、対象クラスターが配置されているリージョンを選択します。

3. 左側のナビゲーションウィンドウで、Community Edition インスタンスのリスト をクリックします。

4. 対象のクラスターを見つけ、クラスター ID をクリックしてクラスター情報 ページに移動します。

5. クラスターのプロパティ セクションで、メジャーバージョンのアップグレード を バージョン の横でクリックします。

6. プロンプトに従って次のパラメーターを設定し、を決定をクリックします。

   パラメーター	説明	例
   クラスターカーネルバージョンをアップグレード	ターゲットクラスターのバージョン。アップグレード後のバージョンロールバックはサポートされていません。 現在、バージョン 23.8 のみがサポートされています。	23.8 (LTS バージョン)
   書き込み停止時間	アップグレード前後のデータ整合性を確保するため、クラスターはアップグレードの最後の 10 分間に書き込み操作を自動的に停止します。書き込み停止時間の設定には以下のルールが適用されます： アップグレードを成功させるために、書き込み停止時間を少なくとも 30 分に設定することを推奨します。 アップグレードは 5 日以内に完了する必要があります。このため、書き込み停止時間 の終了日は、current date + 5 days 以下である必要があります。 書き込み停止がビジネスに与える影響を最小限に抑えるため、書き込み停止時間をオフピーク時間帯に設定することを推奨します。	2025-03-20 10:08 - 2025-03-25 10:08
   インスタンス移行検証の実行	インスタンス移行の検証を実行済み または [インスタンス移行検証をスキップ (非推奨)] を選択します。	インスタンス移行検証済み

7. 次のステップ

   • ソースクラスターに Kafka または RabbitMQ エンジンテーブルが含まれている場合、アップグレード中の適切なタイミングでステップ 3 から 5 を実行します。詳細については、以下のセクションをご参照ください。

   • アップグレードの進捗状況を表示するには、「アップグレードの進捗状況の表示」をご参照ください。

   • 指定した書き込み停止時間が経過してもクラスターのステータスが [アップグレード中] のままである場合は、移行を完了するために 書き込み停止時間を変更する必要があります。

   • アップグレードがビジネスに影響を与え、迅速に停止したい場合は、アップグレードをキャンセルすることができます。

ステップ 3：データ移行中に Kafka/RabbitMQ エンジンテーブルを再構築する

アップグレードタスクが [データ移行] フェーズに入ったとき (テーブルスキーマの移行が完了した後)、以前に保存した DDL 文を使用して Kafka/RabbitMQ エンジンテーブルとその下流のマテリアライズドビューを再構築します。再構築されると、増分データのフローが再開され、新しいクラスターノードに自動的に同期されます。

-- Kafka/RabbitMQ エンジンテーブルを再構築します
CREATE TABLE <database>.<kafka_or_rabbitmq_table_name> (...)
ENGINE = Kafka/RabbitMQ
SETTINGS ...;

-- マテリアライズドビューを再構築します (名前変更されたターゲットテーブルを指す TO 句を使用)
CREATE MATERIALIZED VIEW <database>.<materialized_view_name> TO <database>.<new_target_table_name>
AS SELECT ... FROM <database>.<kafka_or_rabbitmq_table_name>;

ステップ 4：書き込み停止前に Kafka/RabbitMQ エンジンテーブルを削除する

設定された書き込み停止期間の直前に、クラスター上の Kafka/RabbitMQ エンジンテーブルとその下流のマテリアライズドビューを削除して、増分データの書き込みを停止し、最終的なデータ同期の整合性を確保します。

-- 最初にマテリアライズドビューを削除します
DROP TABLE <database>.<materialized_view_name> ON CLUSTER default;

-- 次に Kafka/RabbitMQ エンジンテーブルを削除します
DROP TABLE <database>.<kafka_or_rabbitmq_table_name> ON CLUSTER default;

ステップ 5：アップグレード後に Kafka/RabbitMQ エンジンテーブルを再構築する

アップグレードタスクが完了した後、以前に保存した DDL 文を使用して、アップグレードされたクラスター上で Kafka/RabbitMQ エンジンテーブルとその下流のマテリアライズドビューを再構築し、増分データ消費パイプラインを復元します。

-- Kafka/RabbitMQ エンジンテーブルを再構築します
CREATE TABLE <database>.<kafka_or_rabbitmq_table_name> (...)
ENGINE = Kafka/RabbitMQ
SETTINGS ...;

-- マテリアライズドビューを再構築します (名前変更されたターゲットテーブルを指す TO 句を使用)
CREATE MATERIALIZED VIEW <database>.<materialized_view_name> TO <database>.<new_target_table_name>
AS SELECT ... FROM <database>.<kafka_or_rabbitmq_table_name>;

アップグレードの進捗状況の表示

1. Alibaba Cloud アカウントで ApsaraDB for ClickHouse コンソールにログインします。

2. ページ左上で、対象クラスターが配置されているリージョンを選択します。

3. 左側のナビゲーションウィンドウで、Community Edition インスタンスのリストをクリックします。

4. 対象のクラスターを見つけ、クラスター ID をクリックして クラスター情報 ページに移動します。

5. クラスターの状態セクションで、バージョンのアップグレードの進捗状況を表示するをクリックします。これは状態の横にあります。

   書き込み停止ウィンドウの変更 ダイアログボックスが表示され、MergeTree スキーマ移行の進捗、データ移行、データ移行の推定残り時間、その他のスキーマ移行の進捗など、スペックアップの進捗を確認できます。

書き込み停止時間の変更

指定した書き込み停止時間が経過してもクラスターのステータスが [アップグレード中] のままである場合、データ移行はまだ完了していません。アップグレードが正常に完了するように、書き込み停止時間を調整する必要があります。

1. Alibaba Cloud アカウントで ApsaraDB for ClickHouse コンソールにログインします。

2. ページ左上で、対象クラスターが配置されているリージョンを選択します。

3. 左側のナビゲーションウィンドウで、Community Edition インスタンスのリストをクリックします。

4. 目的のクラスターを見つけ、クラスター ID をクリックしてクラスター情報 ページに移動します。

5. クラスターの状態 セクションで、バージョンのアップグレードの進捗状況を表示する (状態 の横) をクリックします。

6. 表示された 書き込み停止ウィンドウの変更 ダイアログボックスで、書き込み停止時間 を変更し、Confirm をクリックします。

   説明

   書き込み停止時間の設定ルールは、クラスターのアップグレードで説明されている書き込み停止時間 パラメーターと同じです。

アップグレードのキャンセル

アップグレードがビジネスに影響を与え、迅速に停止したい場合は、アップグレードをキャンセルできます。

1. Alibaba Cloud アカウントで ApsaraDB for ClickHouse コンソールにログインします。

2. ページ左上で、対象クラスターが配置されているリージョンを選択します。

3. 左側のナビゲーションウィンドウで、Community Edition インスタンスのリストをクリックします。

4. 対象のクラスターのクラスター ID をクリックして、クラスター情報 ページに移動します。

5. クラスターの状態 セクションで、バージョンのアップグレードの進捗状況を表示する をクリックします。これは 状態 の横にあります。

6. 表示された 書き込み停止ウィンドウの変更 ダイアログボックスで、アップグレードのキャンセル をクリックします。

   説明

   アップグレードのキャンセル をクリックしても、アップグレードタスクはすぐには停止しません。タスクは約 5 分後に完全に停止します。