クラスターのスケーリング

クラスターをスケーリングするには、カスタムリソース 上でレプリカ数と分片数を編集します。オペレーター は新しいトポロジーに向けて稼働中のクラスターをリコンサイルし、レプリカごとの StatefulSet を作成または削除し、スキーマの整合性を保ち、status 条件 を通じて進捗を示します。

このガイドでは、ClickHouseCluster のレプリカと分片をスケーリングする方法、KeeperCluster のクォーラムを安全にスケーリングする方法、そしてスケール操作の進行中に確認すべき 条件 について説明します。

spec.replicas は、各分片のレプリカ数を設定します。各レプリカは <cluster>-clickhouse-<shard>-<replica> という名前のそれぞれ独立した StatefulSet で実行されるため、shards: 2 と replicas: 3 のクラスターでは 6 つの StatefulSet が実行されます。

この数はそのまま増減できます:

spec:
  replicas: 3   # was 1
  keeperClusterRef:
    name: my-keeper

スケールアップ時には、オペレーターがレプリカごとの新しい StatefulSets を作成し、各ポッドが Ready になるのを待ってから、新しいレプリカにスキーマを同期します (スキーマの自動同期 を参照) 。スケールダウン時には、余分な StatefulSets を削除し、削除したレプリカが残した古い replicated-database のレプリカ登録をクリーンアップします。

spec.shards は分片数を設定します。新しい分片を追加するたびに、レプリカごとの StatefulSets 一式が追加されます。また、オペレーターは 分片ごとに 1 つの PodDisruptionBudget を作成するため、ある分片での中断が別の分片の許容中断数に影響することはありません。

spec:
  shards: 3   # was 1
  replicas: 2

各分片はデータのそれぞれ異なる一部を保持しており、オペレーターが分片間で行をコピーしたり移動したりすることはありません。Distributed テーブルまたは明示的なルーティング方式によって行の格納先となる分片が決まるため、分片を追加しても、既存の分片にすでに保存されている行に手を加えることなく、新しい書き込みの格納先を増やせます。

spec.settings.enableDatabaseSync が true (デフォルト) の場合、トポロジーの変化に応じて、オペレーターがスキーマの整合性を維持します。

• スケールアップ時 — 少なくとも 2 つのレプリカの準備が完了すると、オペレーターは新しく作成されたレプリカへデータベース定義をレプリケートします。これにより、新しいレプリカはクラスター内の他のレプリカと同じ Replicated データベースおよびインテグレーションデータベースを持った状態で参加できます。
• スケールダウン時 — レプリカが削除される前に、オペレーターは SYSTEM DROP DATABASE REPLICA を使用して、各 Replicated データベースからそのレプリカの登録を削除します。これにより、縮小後のクラスターが、すでに存在しない Replicated データベースのレプリカを待ち続けることを防ぎます。

この動作の対象は Replicated データベースとインテグレーションのデータベースエンジンです。テーブルデータは移動されません。行データは ReplicatedMergeTree テーブルに保持され、このスキーマ同期とは独立して Keeper 経由でレプリケートされます。準備完了したレプリカが 1 つしかない場合はレプリケート先がないため、オペレーターはこのステップをスキップし、対象がないことをログに記録します。

たとえば、外部ツールがスキーマ伝播を管理している場合は、enableDatabaseSync: false を設定してこの動作を無効にします。その場合、オペレーターは SchemaInSync 条件に SchemaSyncDisabled という reason を報告します。

スケール操作の実行中に、カスタムリソースの進捗を確認します:

kubectl get clickhousecluster sample -o yaml | sed -n '/conditions:/,/^[^ ]/p'

スケール操作は、ClusterSizeAligned が UpToDate、SchemaInSync が ReplicasInSync、Ready が AllShardsReady をそれぞれ報告した時点で完了します。

KeeperCluster は RAFT クォーラムで動作するため、オペレーター はメンバーシップを一度に 1 レプリカずつ変更し、クラスターが安定した状態にある場合にのみ実行します。これによりクォーラムが保護されます。2F+1 のクラスターは F 個のメンバーの停止に耐えられるため、3 ノードのクラスターは 1 メンバーが欠けても動作を継続でき、5 ノードのクラスターは 2 メンバーが欠けても動作を継続できます。

spec:
  replicas: 5   # was 3

スケールアップ時には、オペレーター は未使用の中で最も小さいレプリカ ID をクォーラムに追加します。スケールダウン時には、最も大きい ID を削除します。各ステップでは、次の処理を開始する前にクォーラムが安定するまで待機します。Keeper PodDisruptionBudget のデフォルトは maxUnavailable: replicas/2 で、自発的な中断中もクォーラムを維持できるようになっています。

ScaleAllowed 条件は、クォーラムのメンバー構成を現在変更できるかどうかを示します。

Keeper は 1 ステップずつスケールし、変更の合間に ScaleAllowed が ReadyToScale に戻るのを待ってください。一度に複数メンバー分を変更しても、1 回に 1 メンバーずつ行うリコンサイルを省略することはできません。オペレーター はそれでも、クォーラムをステップごとに 1 メンバーずつ進めます。