ClickHouseCluster のレプリカと分片をスケーリングする方法、KeeperCluster のクォーラムを安全にスケーリングする方法、そしてスケール操作の進行中に確認すべき 条件 について説明します。
ClickHouseCluster では常に Keeper が必要で、必須の spec.keeperClusterRef フィールドで参照します。オペレーター はクラスターのサイズに関係なく、これを通じてクラスターを調整します。1 つの分片あたり複数のレプリカを実行するには、データが ReplicatedMergeTree テーブルにも保存されている必要があります。レプリケーションによって、2 つ目のレプリカでも同じ行を提供できるようになるためです。レプリカのスケーリング
spec.replicas は、各分片のレプリカ数を設定します。各レプリカは <cluster>-clickhouse-<shard>-<replica> という名前のそれぞれ独立した StatefulSet で実行されるため、shards: 2 と replicas: 3 のクラスターでは 6 つの StatefulSet が実行されます。
この数はそのまま増減できます:
分片のスケーリング
spec.shards は分片数を設定します。新しい分片を追加するたびに、レプリカごとの StatefulSets 一式が追加されます。また、オペレーターは 分片ごとに 1 つの PodDisruptionBudget を作成するため、ある分片での中断が別の分片の許容中断数に影響することはありません。
Distributed テーブルまたは明示的なルーティング方式によって行の格納先となる分片が決まるため、分片を追加しても、既存の分片にすでに保存されている行に手を加えることなく、新しい書き込みの格納先を増やせます。
自動スキーマ同期
spec.settings.enableDatabaseSync が true (デフォルト) の場合、トポロジーの変化に応じて、オペレーターがスキーマの整合性を維持します。
- スケールアップ時 — 少なくとも 2 つのレプリカの準備が完了すると、オペレーターは新しく作成されたレプリカへデータベース定義をレプリケートします。これにより、新しいレプリカはクラスター内の他のレプリカと同じ
Replicatedデータベースおよびインテグレーションデータベースを持った状態で参加できます。 - スケールダウン時 — レプリカが削除される前に、オペレーターは
SYSTEM DROP DATABASE REPLICAを使用して、各Replicatedデータベースからそのレプリカの登録を削除します。これにより、縮小後のクラスターが、すでに存在しないReplicatedデータベースのレプリカを待ち続けることを防ぎます。
Replicated データベースとインテグレーションのデータベースエンジンです。テーブルデータは移動されません。行データは ReplicatedMergeTree テーブルに保持され、このスキーマ同期とは独立して Keeper 経由でレプリケートされます。準備完了したレプリカが 1 つしかない場合はレプリケート先がないため、オペレーターはこのステップをスキップし、対象がないことをログに記録します。
たとえば、外部ツールがスキーマ伝播を管理している場合は、enableDatabaseSync: false を設定してこの動作を無効にします。その場合、オペレーターは SchemaInSync 条件に SchemaSyncDisabled という reason を報告します。
確認すべき 条件
スケール操作は、
ClusterSizeAligned が UpToDate、SchemaInSync が ReplicasInSync、Ready が AllShardsReady をそれぞれ報告した時点で完了します。
Keeper のスケーリング
KeeperCluster は RAFT クォーラムで動作するため、オペレーター はメンバーシップを一度に 1 レプリカずつ変更し、クラスターが安定した状態にある場合にのみ実行します。これによりクォーラムが保護されます。2F+1 のクラスターは F 個のメンバーの停止に耐えられるため、3 ノードのクラスターは 1 メンバーが欠けても動作を継続でき、5 ノードのクラスターは 2 メンバーが欠けても動作を継続できます。
maxUnavailable: replicas/2 で、自発的な中断中もクォーラムを維持できるようになっています。
ScaleAllowed 条件は、クォーラムのメンバー構成を現在変更できるかどうかを示します。
Keeper は 1 ステップずつスケールし、変更の合間に
ScaleAllowed が ReadyToScale に戻るのを待ってください。一度に複数メンバー分を変更しても、1 回に 1 メンバーずつ行うリコンサイルを省略することはできません。オペレーター はそれでも、クォーラムをステップごとに 1 メンバーずつ進めます。