ClickHouse Operator とは
- クラスターのライフサイクル管理 (作成、更新、スケーリング、削除)
- ClickHouse Keeper クラスターの協調
- 構成の自動生成
- データベーススキーマの同期
- ローリング更新とアップグレード
- ストレージのプロビジョニング
カスタムリソース
ClickHouseCluster
KeeperCluster
協調
ClickHouse Keeper は必須です
keeperClusterRef を使って ClickHouseCluster の spec で参照する必要があります。デフォルトでは、operator は ClickHouseCluster のネームスペース内を参照しますが、keeperClusterRef.namespace を設定して、監視対象の別のネームスペース内にある KeeperCluster を指定することもできます。
1 対 1 の Keeper の対応関係
- 複数の ClickHouseCluster から同じ KeeperCluster を参照することはできません
- ClickHouseCluster を再作成する場合は、対応する KeeperCluster も再作成する必要があります
ClickHouseCluster または KeeperCluster リソースを削除しても、Persistent Volumes は自動的に削除されません。
- ClickHouseCluster リソースを削除します
- KeeperCluster リソースを削除します
- すべてのポッドが終了するまで待ちます
- 必要に応じて、PersistentVolumeClaims を削除してクリーンな状態からやり直します
- KeeperCluster と ClickHouseCluster の両方を一緒に再作成します
スキーマのレプリケーション
レプリケートされるもの
- Replicated データベースの定義
- インテグレーション用データベースエンジン (PostgreSQL、MySQL など)
- レプリケーションされていないデータベース (Atomic、Ordinary など)
- レプリケーションされていないデータベース内のローカルテーブル
- テーブルデータ (ClickHouse のレプリケーションで処理されます)
推奨: Replicated データベースエンジンを使用する
- すべてのノードでスキーマが自動的にレプリケーションされる
- テーブル管理が簡素化される
- Operator が新しいレプリカとも同期できる
- クラスター全体でスキーマの一貫性が保たれる
Replicated 以外のエンジンを避ける
- 各レプリカで個別にテーブルを作成する必要があります
- ノード間でスキーマの不整合が発生する可能性があります
- Operator は新しいレプリカを自動的に同期できません
スキーマのレプリケーションを無効にする
spec.settings.enableDatabaseSync を false に設定します。
ストレージ管理
データボリュームの設定
dataVolumeClaimSpec でストレージ要件を指定します。
ストレージのライフサイクル
- 作成: PVC はクラスターの作成時に自動的に作成されます
- 拡張: StorageClass でボリュームの拡張が許可されている場合にサポートされます
- 保持: クラスターを削除しても PVC は自動的には削除されません
- 再利用: 同じ名前でクラスターを再作成すると、既存の PVC を再利用できます
デフォルト構成の主なポイント
- 事前設定済みのクラスター: すべての ClickHouse ノードを含む、
defaultという名前のクラスター。 - デフォルトのマクロ: 便利なマクロがいくつか事前定義されています:
{cluster}: クラスター名 (default){shard}: 分片番号{replica}: レプリカ番号
- ロールベースのアクセス制御 (RBAC) エンティティ向けのレプリケートストレージ
- ユーザー定義関数 (UDF) 向けのレプリケートストレージ
次のステップ
- 設定ガイド - 設定オプションの詳細
- API リファレンス - API の完全なドキュメント