ApsaraDB for ClickHouse:Community-Compatible Edition クラスターの垂直スケーリングと水平スケーリング

ステップ 1：Kafka/RabbitMQ テーブルの記録と削除

コンソールのスケーリング機能は、Kafka および RabbitMQ エンジンテーブルを直接移行できません。 クラスターをスケーリングする前に、これらのテーブルの DDL ステートメントを記録し、スケーリングタスクに影響を与えないようにクラスターから削除する必要があります。

1. クラスターにログインし、次のステートメントを実行して、すべての Kafka および RabbitMQ エンジンテーブルとその下流の依存関係をクエリします。

   /*
   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：非 MergeTree テーブルデータのバックアップ

1. クラスターにログインし、次のステートメントを実行して、データ移行が必要な非 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')
   ))

2. データをバックアップします。

   非 MergeTree テーブルにある業務データをバックアップします。 詳細については、「OSS へのデータのバックアップ」をご参照ください。

ステップ 4：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>;

ステップ 5：書き込み停止前の 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;

ステップ 6：スケーリング後の 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>;

ステップ 7：非 MergeTree テーブルデータの移行

クラスターにログインし、ステップ 2 でバックアップしたデータを OSS を使用して移行します。 詳細については、「OSS からのデータのインポート」をご参照ください。