Skip to main content
このページはClickHouse Cloudには該当しません。ここで説明している手順は、ClickHouse Cloud サービスでは自動化されています。
ClickHouse Keeper は、データのレプリケーションおよびdistributed DDLクエリの実行に必要な協調システムを提供します。ClickHouse Keeper は ZooKeeper と互換性があります。

実装の詳細

ZooKeeper は、初期に登場した著名なオープンソースの協調システムの 1 つです。Java で実装されており、シンプルで強力なデータモデルを備えています。ZooKeeper の協調アルゴリズムである ZooKeeper Atomic Broadcast (ZAB) は、各 ZooKeeper ノードが読み取りをローカルで処理するため、読み取りの線形化可能性を保証しません。ZooKeeper とは異なり、ClickHouse Keeper は C++ で書かれており、RAFTアルゴリズム実装を使用しています。このアルゴリズムは、読み取りと書き込みの両方で線形化可能性を実現し、さまざまな言語による複数のオープンソース実装があります。 デフォルトでは、ClickHouse Keeper は ZooKeeper と同じ保証を提供します。つまり、書き込みは線形化可能で、読み取りは非線形化可能です。クライアント・サーバープロトコルに互換性があるため、標準的な ZooKeeper クライアントであれば ClickHouse Keeper とやり取りできます。スナップショットとログのフォーマットは ZooKeeper と互換性がありませんが、clickhouse-keeper-converter ツールを使用すると、ZooKeeper のデータを ClickHouse Keeper のスナップショットに変換できます。ClickHouse Keeper のサーバー間プロトコルも ZooKeeper とは互換性がないため、ZooKeeper と ClickHouse Keeper が混在するクラスターを構成することはできません。 ClickHouse Keeper は、ZooKeeper と同様にアクセス制御リスト (ACL) をサポートしています。ClickHouse Keeper は同じ権限セットをサポートしており、組み込みのスキームも worldauthdigest の 3 つで完全に同一です。digest 認証スキームでは username:password の組を使用し、パスワードは Base64 でエンコードされます。
外部インテグレーションはサポートされていません。

設定

ClickHouse Keeper は、ZooKeeper のスタンドアロンの代替として、または ClickHouse server の内部コンポーネントとして使用できます。いずれの場合も、設定はほぼ同じ .xml ファイルで行います。

Keeper 設定項目

ClickHouse Keeper のメイン設定タグは <keeper_server> で、以下のパラメータを使用できます。 その他の一般的なパラメータは、ClickHouse server の設定 (listen_hostlogger など) から継承されます。

内部協調設定

内部協調設定は <keeper_server>.<coordination_settings> セクションにあり、次のパラメータがあります。 クォーラム設定は <keeper_server>.<raft_configuration> セクションにあり、サーバーの説明が含まれます。 クォーラム全体に対する唯一のパラメータは secure で、クォーラム参加者間の通信に暗号化接続を有効にします。ノード間の内部通信用に SSL 接続が必要な場合は、このパラメータを true に設定できます。それ以外の場合は指定しないままにできます。 <server> の主なパラメータは次のとおりです。
  • id — クォーラム内でのサーバー識別子。
  • hostname — このサーバーが配置されているホスト名。
  • port — このサーバーが接続を待ち受けるポート。
  • can_become_leader — サーバーを learner として構成するには false に設定します。省略した場合の値は true です。
ClickHouse Keeper クラスターのトポロジーが変更される場合 (たとえばサーバーの置き換え時) は、server_idhostname の対応関係を常に一貫させ、異なるサーバーに対して既存の server_id を入れ替えたり再利用したりしないようにしてください (たとえば、ClickHouse Keeper のデプロイに自動化スクリプトを使っている場合に起こりえます) 。Keeper インスタンスのホストが変わる可能性がある場合は、IP アドレスを直接使うのではなく、ホスト名を定義して使用することを推奨します。ホスト名の変更は、サーバーを削除して再度追加し直すのと同じであり、場合によってはそれが不可能なことがあります (たとえば、クォーラムを満たすのに十分な Keeper インスタンス数がない場合) 。
async_replication は後方互換性を損なわないよう、デフォルトで無効になっています。クラスター内のすべての Keeper インスタンスが async_replication をサポートするバージョン (v23.9+) で動作している場合は、欠点なくパフォーマンスを向上できるため、有効にすることを推奨します。
3 ノードのクォーラム向けの設定例は、test_keeper_ プレフィックスを持つ 結合テスト にあります。サーバー #1 の設定例:

実行方法

ClickHouse Keeper は ClickHouse server パッケージに同梱されているため、/etc/your_path_to_config/clickhouse-server/config.xml<keeper_server> の設定を追加し、通常どおり ClickHouse server を起動するだけです。スタンドアロンの ClickHouse Keeper を実行する場合も、同様に次のように起動できます。
シンボリックリンク (clickhouse-keeper) がない場合は、それを作成するか、clickhouse の引数として keeper を指定できます。

4文字コマンド

ClickHouse Keeper は、ZooKeeper とほぼ同じ 4lw コマンドも提供しています。各コマンドは mntrstat などのように 4 文字で構成されています。さらに、いくつかの便利なコマンドがあります。stat は server と接続中のクライアントに関する一般的な情報を返し、srvr は server の詳細情報を返し、cons は connections の詳細情報を返します。 4lw コマンドには four_letter_word_white_list というホワイトリスト設定があり、そのデフォルト値は conf,cons,crst,envi,ruok,srst,srvr,stat,wchs,dirs,mntr,isro,rcvr,apiv,csnp,lgif,rqld,ydld です。 これらのコマンドは、クライアントポートに対して telnet または nc 経由で ClickHouse Keeper に送信できます。
以下に、4lw コマンドの詳細を示します。
  • ruok: サーバーがエラーのない状態で稼働しているかどうかをテストします。稼働している場合、サーバーは imok を返します。そうでない場合は、まったく応答しません。imok という応答は、サーバーがクォーラムに参加していることを必ずしも意味せず、サーバープロセスがアクティブで、指定されたクライアントポートにバインドされていることを示すだけです。クォーラムに関する状態やクライアント接続情報の詳細については、“stat” を使用してください。
  • mntr: クラスターの健全性の監視に使用できる変数の一覧を出力します。
  • srvr: サーバーの詳細情報を一覧表示します。
  • stat: サーバーと接続中のクライアントの概要を一覧表示します。
  • srst: サーバーの統計情報をリセットします。このコマンドは srvrmntrstat の結果に影響します。
  • conf: 現在の設定の詳細を表示します。
  • cons: このサーバーに接続しているすべてのクライアントの接続/セッションの詳細を一覧表示します。受信/送信したパケット数、セッション ID、操作レイテンシ、最後に実行された操作などの情報が含まれます…
  • crst: すべての接続の connection/session 統計をリセットします。
  • envi: 実行環境の詳細を表示
  • dirs: スナップショットおよびログファイルの合計サイズをバイト単位で表示
  • isro: サーバーが読み取り専用モードで稼働しているかどうかを確認します。読み取り専用モードの場合、サーバーは ro を返し、そうでない場合は rw を返します。
  • wchs: サーバーのウォッチに関する概要を一覧表示します。
  • wchc: サーバーのウォッチに関する詳細情報を、セッションごとに一覧表示します。ウォッチ (パス) に関連付けられたセッション (接続) の一覧が出力されます。なお、ウォッチ数によってはこの操作の負荷が高くなり、サーバーのパフォーマンスに影響する可能性があるため、注意して使用してください。
  • wchp: サーバーのウォッチに関する詳細情報を、パスごとに一覧表示します。関連するセッションとともに、パス (znode) の一覧が出力されます。なお、ウォッチ数によってはこの操作のコストが高くなり (つまり、サーバーのパフォーマンスに影響する可能性があり) 、慎重に使用してください。
  • dump: 残っているセッションとエフェメラルノードを一覧表示します。これはリーダーでのみ機能します。
  • csnp: スナップショット作成タスクをスケジュールします。成功した場合は、スケジュールされたスナップショットの最後にコミットされたログインデックスを返し、失敗した場合は Failed to schedule snapshot creation task. を返します。スナップショットが完了したかどうかは、lgif コマンドで確認できます。
  • lgif: Keeper のログ情報。first_log_idx : ログストア内の最初のログインデックス; first_log_term : 最初のログターム; last_log_idx : ログストア内の最後のログインデックス; last_log_term : 最後のログターム; last_committed_log_idx : ステートマシン内で最後にコミットされたログインデックス; leader_committed_log_idx : 自分から見たリーダーのコミット済みログインデックス; target_committed_log_idx : コミットされるべき対象のログインデックス; last_snapshot_idx : 最後のスナップショットにおける、コミット済みログインデックスの最大値。
  • rqld: 新しいリーダーになるよう要求します。要求の送信に成功した場合は Sent leadership request to leader. を、送信できなかった場合は Failed to send leadership request to leader. を返します。ノードがすでにリーダーである場合も、結果は要求の送信に成功した場合と同じです。
  • ftfl: すべての機能フラグと、それぞれがKeeperインスタンスで有効かどうかを一覧表示します。
  • ydld: リーダーシップを譲ってフォロワーになるよう要求します。要求を受信したサーバーがリーダーの場合、まず書き込み処理を一時停止し、後継ノード (現在のリーダーが後継ノードになることはありません) が最新のログへの追従を完了するまで待ってから、リーダーを退任します。後継ノードは自動的に選択されます。要求が送信された場合は Sent yield leadership request to leader.、送信されなかった場合は Failed to send yield leadership request to leader. を返します。ノードがすでにフォロワーである場合も、結果は要求が送信された場合と同じです。
  • pfev: 収集されたすべてのイベントの値を返します。各イベントについて、イベント名、イベント値、イベントの説明を返します。

HTTP 制御

ClickHouse Keeper は、レプリカがトラフィックを受け付ける準備ができているかどうかを確認するための HTTP インターフェイスを提供します。これは、Kubernetes などのクラウド環境で利用できます。 /ready エンドポイントを有効にする設定例:

機能フラグ

Keeper は ZooKeeper およびそのクライアントと完全な互換性がありますが、ClickHouse client で利用できる独自の機能やリクエストタイプもいくつか導入しています。 これらの機能は後方互換性を持たない変更を引き起こす可能性があるため、その多くはデフォルトで無効になっており、keeper_server.feature_flags 設定で有効にできます。 すべての機能を明示的に無効にすることもできます。 Keeper クラスターで新しい機能を有効にする場合は、まずクラスター内のすべての Keeper インスタンスをその機能をサポートするバージョンに更新してから、機能自体を有効にすることを推奨します。 multi_read を無効にし、check_not_exists を有効にする機能フラグ設定の例:
以下の機能が利用できます。
一部の機能フラグは、バージョン 25.7 以降でデフォルトで有効になります。 Keeper を 25.7+ にアップグレードする推奨手順は、まずバージョン 24.9+ にアップグレードすることです。

ZooKeeper からの移行

ZooKeeper から ClickHouse Keeper へのシームレスな移行はできません。ZooKeeper クラスターを停止し、データを変換したうえで、ClickHouse Keeper を起動する必要があります。clickhouse-keeper-converter ツールは、ZooKeeper のログとスナップショットを ClickHouse Keeper のスナップショットに変換します。ZooKeeper 3.4 以降が必要です。

移行前の準備

移行を行うには、データのインジェストを停止する必要があります。開始前にメンテナンスウィンドウを確保してください。 ZooKeeper を停止する前に、協調用メタデータを変更する ClickHouse のバックグラウンドタスクを停止してください。例えば:
移行後に整合性を確認できるよう、移行前に比較用のメトリクスを記録しておきます。

移行手順

  1. すべての ClickHouse ノードへのデータのインジェストを停止します。
  2. すべての ClickHouse ノードで、すべてのバックグラウンドタスクを停止します (上記を参照) 。
  3. すべての ZooKeeper ノードを停止します。
  4. 任意ですが、推奨します: ZooKeeper のリーダーノードを特定し、起動してから再度停止します。これにより、変換前に ZooKeeper が整合性のあるスナップショットをディスクに書き込むよう強制できます。
  5. リーダーノードで clickhouse-keeper-converter を実行します。ClickHouse の完全なバイナリがインストールされている場合は、代わりに keeper-converter サブコマンド (clickhouse keeper-converter) を使用します。どちらも利用できない場合は、バイナリをダウンロードしてください。
  1. スナップショットをすべての ClickHouse Keeper ノードにコピーします。どのノードも起動する前に、すべてのノードにスナップショットが存在している必要があります。スナップショットがないままノードが起動すると、空の状態で自らをリーダーに選出してしまう可能性があります。
  2. 新しい Keeper クラスターを参照するように ClickHouse の設定を更新します。
  3. すべてのノードで ClickHouse Keeper を起動し、その後 ClickHouse を再起動します。
  4. 整合性を確認するため、移行前のベースラインとメトリクスを比較します。
  5. バックグラウンドタスクを再開し、データのインジェストを再開します。

複数の ZooKeeper クラスターの統合

複数の ZooKeeper クラスター (たとえば分片グループごとに 1 つ) を運用している場合は、それらを 1 つの ClickHouse Keeper クラスターに統合できます。公式の clickhouse-keeper-converter ツールがサポートしているのは 1 対 1 の変換 (1 つの ZooKeeper クラスターから 1 つの Keeper スナップショットへの変換) のみであるため、統合するには converter のソースコードを修正し、複数のスナップショットをマージする必要があります。
  1. 各 ZooKeeper クラスターに対して clickhouse-keeper-converter を個別に実行し、それぞれの出力を別々のディレクトリに書き込みます。
  2. スナップショットファイルを順番にデシリアライズします。マージ時には、異なるソースクラスターのネームスペース間でノード ID の競合が発生しないよう、numChildren の値を再計算します。
  3. マージした出力を、対象の ClickHouse Keeper スナップショット用ディレクトリに書き込みます。

暗号化とACLの取り扱い

ClickHouse Keeper は、ZooKeeper と同じ ACL スキーム (worldauthdigest) をサポートしています。変換時に ACL をどのように扱うかは、ZooKeeper の構成によって異なります。
  • 完全に暗号化されている、またはまったく暗号化されていない: そのまま変換できます。コンバーターは既存の ACL 情報を保持します。
  • 部分的に暗号化されている: 変換前にスーパー管理者アカウントに権限を付与し、影響を受けるパスで setAcl -R を使って ACL をクリアします。変換後、必要に応じて ClickHouse Keeper で暗号化を再度有効にしてください。

移行の検証

ClickHouse Keeper を起動し、ClickHouse を再起動したら、移行が正常に完了したことを確認するために、主要なメトリクスを移行前のベースラインと比較します。 複数の ZooKeeper クラスターを統合する場合は、次の違いを区別してください。
  • 共通パス: 複数のソースクラスターに同一データで存在するパス。これらは、マージ後の出力で重複排除する必要があります。
  • 固有のパス: 特定のクラスター配下にのみ存在するパス (例: 各分片グループの /clickhouse/tables 配下) 。これらは、正しいソースのものを保持する必要があります。
比較のために大規模な ZooKeeper ツリーを直接走査するのは避けてください。代わりに、変換時に変換したすべてのパスをファイルに出力してください。

移行後のチューニング

移行後は、より大規模なクラスターや、より高いスループットが必要な場合に備えて、以下の設定を調整することを検討してください。 これらの設定は、Keeper の設定coordination_settings で構成します。

クォーラム喪失後の復旧

ClickHouse Keeper は Raft を使用しているため、クラスターのサイズに応じて一定数のノード障害に耐えられます。 たとえば、3 ノードのクラスターであれば、1 ノードだけが停止しても正常に動作を継続できます。 クラスター構成は動的に変更できますが、いくつか制約があります。再構成も Raft に依存しているため、 クラスターにノードを追加または削除するにはクォーラムが必要です。クラスター内で同時に多くのノードを失い、 しかもそれらを再起動できる見込みがない場合、Raft は動作を停止し、通常の方法ではクラスターを再構成できなくなります。 それでも、ClickHouse Keeper には、1 ノードだけでクラスターを強制的に再構成できる復旧モードがあります。 これは、ノードを再起動できない場合や、同じエンドポイントで新しいインスタンスを起動できない場合の最終手段としてのみ使用してください。 続行する前に、次の重要な点に注意してください。
  • 障害が発生したノードが再びクラスターに接続できないことを確認してください。
  • 手順で指示があるまでは、新しいノードをいずれも起動しないでください。
上記を確認したら、次の作業を行ってください。
  1. 新しいリーダーとする Keeper ノードを 1 つ選びます。そのノードのデータがクラスター全体で使われるため、できるだけ最新の状態を持つノードを使用することを推奨します。
  2. ほかの作業を行う前に、選択したノードの log_storage_path および snapshot_storage_path フォルダーのバックアップを作成します。
  3. 使用する予定のすべてのノードでクラスターを再構成します。
  4. 選択したノードに 4 文字コマンド rcvr を送信してそのノードを復旧モードに移行するか、または選択したノード上の Keeper インスタンスを停止し、--force-recovery 引数を付けて再起動します。
  5. 新しいノード上で Keeper インスタンスを 1 つずつ起動し、次のノードを起動する前に mntrzk_server_state に対して follower を返すことを確認します。
  6. 復旧モード中、リーダーノードは新しいノードとのクォーラムが成立するまで、mntr コマンドに対してエラーメッセージを返し、クライアントおよびフォロワーからのあらゆるリクエストを拒否します。
  7. クォーラムが成立すると、リーダーノードは通常動作モードに戻り、すべてのリクエストを受け付けます。mntr で確認すると、zk_server_state に対して leader が返るはずです。

Keeper でディスクを使用する

Keeper は、スナップショット、ログファイル、状態ファイルの保存先として、外部ディスク の一部をサポートしています。 サポートされているディスクの種類は次のとおりです。
  • s3_plain
  • s3
  • local
以下は、設定に含まれるディスク定義の例です。
ログ用にディスクを使用するには、keeper_server.log_storage_disk 設定にディスク名を指定する必要があります。 スナップショット用にディスクを使用するには、keeper_server.snapshot_storage_disk 設定にディスク名を指定する必要があります。 さらに、最新のログには keeper_server.latest_log_storage_disk、最新のスナップショットには keeper_server.latest_snapshot_storage_disk を使用できます。 その場合、新しいログまたはスナップショットが作成されると、Keeper は自動的にファイルを適切なディスクに移動します。 state ファイル用にディスクを使用するには、keeper_server.state_storage_disk 設定にディスク名を指定する必要があります。 ディスク間でのファイル移動は安全で、転送の途中で Keeper が停止してもデータが失われることはありません。 ファイルが新しいディスクに完全に移動されるまでは、元のディスクから削除されません。 keeper_server.coordination_settings.force_synctrue に設定した Keeper (デフォルトは true) では、すべての種類のディスクに対して一部の保証を満たせません。 現時点で永続 sync をサポートしているのは、local 型のディスクのみです。 force_sync を使用する場合、latest_log_storage_disk を使用しないのであれば、log_storage_disklocal ディスクである必要があります。 latest_log_storage_disk を使用する場合は、常に local ディスクである必要があります。 force_sync を無効にすると、どの種類のディスクでも、どの構成でも使用できます。 Keeper インスタンスのストレージ構成例は、次のようになります。
このインスタンスでは、最新のログを除くすべてのログはディスク log_s3_plain に保存され、最新のログはディスク log_local に保存されます。 同様に、スナップショットについても、最新のスナップショットを除くすべてのスナップショットは snapshot_s3_plain に保存され、最新のスナップショットはディスク snapshot_local に保存されます。

ディスク構成の変更

新しいディスク構成を適用する前に、Keeper のログとスナップショットをすべて手動でバックアップしてください。
階層化されたディスク構成が定義されている場合 (最新のファイル用に別のディスクを使用する場合) 、Keeper は起動時にファイルを適切なディスクへ自動的に移動しようとします。 従来と同じ保証が適用されます。ファイルが新しいディスクへの移動を完全に終えるまでは古いディスクから削除されないため、複数回再起動しても 安全です。 ファイルをまったく新しいディスクに移動する必要がある場合 (または 2 ディスク構成から単一ディスク構成に移行する場合) は、keeper_server.old_snapshot_storage_diskkeeper_server.old_log_storage_disk を複数定義できます。 次の設定は、以前の 2 ディスク構成から、まったく新しい単一ディスク構成へ移行する方法を示しています。
起動時に、すべてのログファイルは log_locallog_s3_plain から log_local2 ディスクに移動されます。 また、すべてのスナップショットファイルは snapshot_localsnapshot_s3_plain から snapshot_local2 ディスクに移動されます。

ログキャッシュの設定

ディスクから読み取るデータ量を最小限に抑えるため、Keeper はログエントリをメモリにキャッシュします。 リクエストが大きい場合、ログエントリがメモリを過剰に消費する可能性があるため、キャッシュされるログ量には上限が設けられています。 この上限は、次の 2 つの設定で制御します。
  • latest_logs_cache_size_threshold - キャッシュに保存される最新ログの合計サイズ
  • commit_logs_cache_size_threshold - 次にコミットする必要がある後続ログの合計サイズ
デフォルト値が大きすぎる場合は、この 2 つの設定を小さくすることでメモリ使用量を削減できます。
pfev コマンドを使用すると、各キャッシュおよびファイルから読み取られたログ量を確認できます。 また、Prometheus エンドポイントのメトリクスを使用して、両方のキャッシュの現在のサイズを追跡することもできます。

Prometheus

Keeper は、Prometheus によるスクレイピング用にメトリクスデータを公開できます。 設定:
  • endpoint – Prometheus サーバーがメトリクスをスクレイピングするための HTTP エンドポイント。’/’ で始まる必要があります。
  • portendpoint に使用するポート。
  • metricssystem.metrics テーブルのメトリクスを公開するかどうかを設定するフラグ。
  • eventssystem.events テーブルのメトリクスを公開するかどうかを設定するフラグ。
  • asynchronous_metricssystem.asynchronous_metrics テーブルの現在のメトリクス値を公開するかどうかを設定するフラグ。
確認してください (127.0.0.1 はご利用の ClickHouse server の IPアドレスまたはホスト名に置き換えてください) :
ClickHouse Cloud のPrometheus インテグレーションもご覧ください。

ClickHouse Keeper ユーザーガイド

このガイドでは、ClickHouse Keeper を設定するためのシンプルで最小限の構成と、分散処理をテストする方法の例を紹介します。この例では、Linux 上の 3 つのノードを使用します。
1

Keeper 設定を使用してノードを構成する

  1. 3 台のホスト (chnode1chnode2chnode3) に、3 つの ClickHouse インスタンスをインストールします。 (ClickHouse のインストール方法の詳細については、クイックスタートを参照してください。)
  2. 各ノードで、ネットワークインターフェイス経由の外部通信を許可するために、以下のエントリを追加します。
  3. 以下のClickHouse Keeperの設定を3台すべてのサーバーに追加し、各サーバーの<server_id>設定を更新します。たとえば、chnode11chnode22となります。
    上記で使用した基本設定は以下のとおりです。
  4. ZooKeeper コンポーネントを有効にします。このコンポーネントでは ClickHouse Keeper エンジンを使用します:
    上記で使用した基本設定は以下のとおりです。
  5. ClickHouse を再起動し、各 Keeper インスタンスが稼働していることを確認します。各サーバーで次のコマンドを実行してください。Keeper が稼働しており正常な状態であれば、ruok コマンドは imok を返します。
  6. system データベースには、ClickHouse Keeper の各インスタンスの詳細が格納された zookeeper という名前のテーブルがあります。では、このテーブルを見てみましょう。
    表は次のとおりです。
2

ClickHouse でクラスターを構成する

  1. 2 台のノード上で、2 つの分片と各分片あたり 1 つのレプリカ בלבדのシンプルなクラスターを構成してみましょう。3 台目のノードは、ClickHouse Keeper の要件であるクォーラムを満たすために使用します。chnode1chnode2 の設定を更新します。以下のクラスターでは、各ノードに 1 つの分片を定義しているため、レプリケーションなしで合計 2 つの分片になります。この例では、データの一部は一方のノードに、残りはもう一方のノードに配置されます。
  2. ClickHouse を再起動し、クラスターが作成されたことを確認します。
    クラスターが表示されるはずです。
3

分散テーブルの作成とテスト

  1. chnode1 上の ClickHouse client を使用して、新しいクラスターに新しいデータベースを作成します。ON CLUSTER 句により、両方のノードにデータベースが自動的に作成されます。
  2. db1 データベースに新しいテーブルを作成します。今回も、ON CLUSTER によって両方のノードにテーブルが作成されます。
  3. chnode1 ノードで、2 行のデータを追加します。
  4. chnode2 ノードでも、2 行のデータを追加します。
  5. 各ノードで SELECT ステートメントを実行すると、そのノード上のデータしか表示されないことに注目してください。たとえば、chnode1 では次のようになります。
    chnode2 では次のようになります。
  6. 2 つの分片上のデータを表す Distributed テーブルを作成できます。Distributed テーブルエンジンを使用するテーブル自体はデータを保持しませんが、複数のサーバーにまたがる分散クエリ処理を可能にします。read はすべての分片に対して実行され、write は分片間に分散できます。chnode1 で次のクエリを実行してください。
  7. dist_table をクエリすると、2 つの分片にある 4 行すべてのデータが返されることに注目してください。

まとめ

このガイドでは、ClickHouse Keeper を使用してクラスターを構成する方法を説明しました。ClickHouse Keeper を使用すると、クラスターを構成し、分片をまたいでレプリケーション可能な分散テーブルを定義できます。

一意のパスでClickHouse Keeperを設定する

このページはClickHouse Cloudには該当しません。ここで説明している手順は、ClickHouse Cloud サービスでは自動化されています。

説明

この記事では、組み込みの {uuid} マクロ設定を使って、 ClickHouse Keeper または ZooKeeper に一意のエントリを作成する方法を説明します。一意の パスは、テーブルの作成と削除を頻繁に行う場合に役立ちます。これは、 パスが作成されるたびにその パス内で新しい uuid が使用されるため、パスのエントリを削除する Keeper のガベージコレクションが完了するまで 数分待つ必要がないからです。 パスが再利用されることはありません。

環境例

3 ノードのクラスターを構成し、3 つすべてのノードで ClickHouse Keeper を、 そのうち 2 つのノードで ClickHouse を動作させます。これにより、 ClickHouse Keeper は 3 ノード (タイブレーカーノードを含む) 構成となり、 ClickHouse は 2 つのレプリカからなる単一の分片として構成されます。 クラスターの設定例:

テーブルで {uuid} を使用するための設定手順

  1. 各サーバーでマクロを設定します サーバー 1 の例:
shardreplica にはマクロを定義していますが、{uuid} はここでは定義していない点に注意してください。これは組み込みのため、定義する必要はありません。
  1. データベースを作成する
  1. マクロと {uuid} を使用して、クラスター上にテーブルを作成します
  1. 分散テーブルを作成する

動作確認

  1. 最初のノード (例: chnode1) にデータを挿入します
  1. 2つ目のノードにデータを挿入します (例: chnode2)
  1. 分散テーブルを使ってレコードを表示する

別の方法

デフォルトのレプリケーションパスは、マクロと {uuid} を使ってあらかじめ定義できます
  1. 各ノードでテーブルのデフォルト設定を行う
特定のデータベースでノードを使用している場合は、各ノードでマクロ {database} を定義することもできます。
  1. パラメータを明示せずにテーブルを作成します:
  1. デフォルト設定と同じ設定が使われていることを確認します

トラブルシューティング

テーブル情報とUUIDを取得するコマンドの例:
上記のテーブルのUUIDを使ってZooKeeper内のテーブル情報を取得するコマンド例
データベースは Atomic である必要があります。以前のバージョンからアップグレードする場合、 default データベースは Ordinary である可能性が高いです。
確認するには: たとえば、

ClickHouse Keeper の動的再設定

このページはClickHouse Cloudには該当しません。ここで説明している手順は、ClickHouse Cloud サービスでは自動化されています。

説明

keeper_server.enable_reconfiguration が有効な場合、ClickHouse Keeper はクラスターを動的に再構成するための ZooKeeper の reconfig コマンドを部分的にサポートします。
この設定が無効な場合は、各レプリカの raft_configuration セクションを手動で変更することでクラスターを再構成できます。変更を適用するのはリーダーのみであるため、 すべてのレプリカ上のファイルを編集してください。 また、ZooKeeper 互換クライアント経由で reconfig クエリを送信することもできます。
仮想ノード /keeper/config には、最後にコミットされたクラスター構成が次のフォーマットで格納されています。
  • 各サーバーのエントリは改行で区切られます。
  • server_typeparticipant または learner のいずれかです (learner はリーダー選出に参加しません) 。
  • server_priority は、リーダー選出でどのノードを優先するか を示す 0 以上の整数です。 優先度が 0 の場合、そのサーバーがリーダーになることはありません。
例:
reconfig コマンドを使用すると、新しいサーバーの追加、既存サーバーの削除、既存サーバーの 優先度の変更ができます。以下はその例です (clickhouse-keeper-client を使用) :
kazoo の例を以下に示します。
joining 内のサーバーは、上記で説明したサーバー形式に従っている必要があります。サーバーエントリはカンマで区切る必要があります。 新しいサーバーを追加する際は、server_priority (デフォルト値は 1) と server_type (デフォルト値 は participant) を省略できます。 既存サーバーの優先度を変更する場合は、変更先の優先度を指定してそのサーバーを joining に追加します。 サーバーのホスト、ポート、タイプは、既存のサーバー設定と一致している必要があります。 サーバーの追加と削除は、joiningleaving に記載された順序で行われます。 joining の更新はすべて、leaving の更新より先に処理されます。 Keeper の再構成実装には、いくつかの注意点があります。
  • サポートされているのは増分再構成のみです。new_members が空でないリクエストは拒否されます。 ClickHouse Keeper の実装では、メンバーシップを動的に変更するために NuRaft API を使用しています。NuRaft では、 1 回につき 1 台のサーバーを追加または削除できます。つまり、設定に対する各変更 (joining の各要素、leaving の各要素) は、それぞれ個別に決定される必要があります。そのため、一括での 再構成は提供されていません。エンドユーザーに誤解を与えるおそれがあるためです。 サーバータイプ (participant/learner) の変更もできません。これは NuRaft でサポートされていないためです。また、 唯一の方法はサーバーを削除して再度追加することですが、これもやはり誤解を招くおそれがあります。
  • 返された znodestat の値は使用できません。
  • from_version フィールドは使用されません。from_version が設定されたリクエストはすべて拒否されます。 これは、/keeper/config が仮想ノードであるためです。つまり、このノードは永続ストレージには保存されず、 代わりに指定されたノード設定に基づいて、リクエストごとにその場で生成されます。 このような設計になっているのは、NuRaft がすでにこの設定を保存しているため、データの重複を避けるためです。
  • ZooKeeper とは異なり、sync コマンドを送信してクラスターの再構成が完了するまで待機する方法はありません。 新しい設定はいずれ適用されますが、適用時期は保証されません。
  • reconfig コマンドは、さまざまな理由で失敗する可能性があります。クラスターの状態を確認して、更新が 適用されたかどうかを確認できます。

単一ノードの Keeper をクラスター化する

実験的な Keeper ノードをクラスターに拡張する必要が生じる場合があります。以下は、3 ノードのクラスターに段階的に拡張する手順の概要です。
  • 重要: 新しいノードは、現在のクォーラム未満の単位で追加する必要があります。そうしないと、それらのノード間でリーダーが選出されてしまいます。この例では、1 台ずつ追加します。
  • 既存の Keeper ノードでは、keeper_server.enable_reconfiguration 設定パラメーターを有効にしておく必要があります。
  • Keeper クラスターの新しい完全な設定で 2 台目のノードを起動します。
  • 起動後、reconfig を使用してノード 1 に追加します。
  • 次に、3 台目のノードを起動し、reconfig を使用して追加します。
  • 新しい Keeper ノードを追加するように clickhouse-server の設定を更新し、変更を適用するために再起動します。
  • ノード 1 の raft 設定を更新し、必要に応じて再起動します。
この手順を確実に理解するのに役立つよう、サンドボックスリポジトリも用意されています。

サポートされていない機能

ClickHouse Keeper は ZooKeeper との完全な互換性を目指していますが、現時点では未実装の機能がいくつかあります (現在も開発は進行中です) 。
最終更新日 2026年7月23日