Skip to main content
この例では、データをレプリケーションするシンプルな ClickHouse クラスターのセットアップ方法を学びます。サーバーは 5 台構成です。うち 2 台はデータのコピーを保持するために使用されます。残りの 3 台は、データのレプリケーションを調整するために使用されます。
これからセットアップするクラスターのアーキテクチャを以下に示します。
ClickHouse Server と ClickHouse Keeper を同じサーバー上でまとめて実行することも可能ですが、 本番環境では ClickHouse Keeper 用に専用ホストを使用することを強く推奨します。 この例でも、その構成を示します。Keeper サーバーはより小規模なものでも問題なく、通常は各 Keeper サーバーにつき 4GB の RAM があれば、 ClickHouse Server が大規模になるまでは十分です。

前提条件

1

ディレクトリ構造とテスト環境のセットアップ

サンプルファイル以下の手順では、クラスターを一からセットアップする方法を順を追って説明します。これらの手順を省略して、すぐにクラスターを実行したい場合は、examplesリポジトリの’docker-compose-recipes’ ディレクトリからサンプルファイルを取得できます。
このチュートリアルでは、Docker compose を使用して ClickHouse クラスターをセットアップします。このセットアップは、個別のローカルマシン、仮想マシン、またはクラウドインスタンスに合わせて変更することも可能です。次のコマンドを実行して、この例のディレクトリ構造を作成します。
次の docker-compose.yml ファイルを cluster_1S_2R ディレクトリに追加します:
docker-compose.yml
以下のサブディレクトリとファイルを作成してください:
  • config.d ディレクトリには、ClickHouse server の構成ファイル config.xml が含まれており、 ここで各 ClickHouse ノード用のカスタム構成を定義します。この 構成は、すべての ClickHouse インストールに含まれるデフォルトの config.xml 構成 ファイルと組み合わされます。
  • users.d ディレクトリにはユーザー構成ファイル users.xml が含まれており、ここで ユーザーごとのカスタム構成を定義します。この構成は、すべての ClickHouse インストールに含まれるデフォルトの users.xml 構成ファイルと組み合わされます。
カスタム構成ディレクトリ独自の構成を記述する場合は、/etc/clickhouse-server/config.xml および etc/clickhouse-server/users.xml の デフォルト構成を直接変更するのではなく、config.dusers.d ディレクトリを 使用することをベストプラクティスとして推奨します。次の行
により、config.d および users.d ディレクトリで定義した構成セクションが、デフォルトの config.xml および users.xml ファイルで定義された構成セクションを上書きするようになります。
2

ClickHouseノードの設定

サーバーのセットアップ

次に、fs/volumes/clickhouse-{}/etc/clickhouse-server/config.d にある空の設定ファイル config.xml をそれぞれ編集します。以下でハイライトされている行は、各ノード固有の値に変更してください。
上記の設定ファイルの各セクションについて、以下で詳しく説明します。

ネットワークとログ

ネットワークインターフェイスで外部からの通信を有効にするには、listen host 設定を有効化します。これにより、ClickHouse server のホストに他の ホストからアクセスできるようになります:
HTTP API のポートは 8123 に設定されています。
clickhouse-client や他のネイティブ ClickHouse ツール、ならびに clickhouse-server と他の clickhouse-servers の間で ClickHouse のネイティブプロトコルによる通信に使用される TCP ポートは、9000 に設定されています。
ロギングは <logger> ブロックで定義します。以下の設定例では、1000M に達するとローテーションするデバッグログを3世代分保持します:
ロギング設定の詳細については、デフォルトの ClickHouse 設定ファイルに含まれるコメントを参照してください。

クラスターの設定

クラスターの設定は <remote_servers> ブロックで行います。 ここでクラスター名 cluster_1S_2R を定義します。<cluster_1S_2R></cluster_1S_2R> ブロックは、<shard></shard> および <replica></replica> の設定を使用してクラスターのレイアウトを定義し、ON CLUSTER 句を使用してクラスター全体で実行される distributed DDL クエリのテンプレートとして機能します。デフォルトでは distributed DDL クエリは許可されていますが、allow_distributed_ddl_queries の設定で無効にすることもできます。internal_replication を true に設定することで、データはいずれか1つのレプリカにのみ書き込まれます。
各サーバーに対して、次のパラメーターを指定します。

Keeperの設定

<ZooKeeper> セクションでは、ClickHouse Keeper (または ZooKeeper) の実行場所を ClickHouse に指定します。 ClickHouse Keeper クラスターを使用する場合、クラスター内の各 <node> に対して、<host> タグおよび <port> タグでそれぞれホスト名とポート番号を指定する必要があります。ClickHouse Keeper のセットアップについては、チュートリアルの次のステップで説明します。
ClickHouse Keeper を ClickHouse Server と同じサーバー上で実行することも可能ですが、 本番環境では、ClickHouse Keeper は専用ホストで実行することを強く推奨します。

マクロの設定

また、<macros> セクションはレプリケートテーブル向けのパラメータ置換を定義するために使用されます。これらは system.macros に一覧表示され、クエリ内で {shard}{replica} などの置換を利用できます。
これらは、クラスターの構成に応じてそれぞれ個別に定義されます。

ユーザー設定

次に、fs/volumes/clickhouse-{}/etc/clickhouse-server/users.d にある空の設定ファイル users.xml をそれぞれ以下の内容に変更します。
/users.d/users.xml
この例では、簡略化のためにデフォルトユーザーをパスワードなしで設定しています。 実際の運用では、この設定は推奨されません。
この例では、各ノードの users.xml ファイルはクラスター全体で同一です。
3

ClickHouse Keeperの設定

Keeperのセットアップ

レプリケーションを機能させるには、ClickHouse Keeper クラスターをセットアップして 設定する必要があります。ClickHouse Keeper はデータレプリケーションのための 調整システムを提供し、ZooKeeper の代替として動作します。ZooKeeper を使用することも可能ですが、 より優れた保証と信頼性を備え、 ZooKeeper よりも少ないリソースで動作するため、ClickHouse Keeper の使用が推奨されます。高可用性を確保し、 クォーラムを維持するため、少なくとも 3 台の ClickHouse Keeper ノードを実行することを推奨します。
ClickHouse Keeper は、ClickHouse と併せてクラスター内の任意のノードで実行できますが、 スケーリングや ClickHouse Keeper クラスターの管理をデータベースクラスターから独立して行えるため、 専用ノードで実行することを推奨します。
各 ClickHouse Keeper ノード用の keeper_config.xml ファイルを、 example フォルダーのルートで次のコマンドを使用して作成します。
各 ノードディレクトリ fs/volumes/clickhouse-keeper-{}/etc/clickhouse-keeper に作成された空の設定ファイルを編集します。以下で 強調表示されている行は、各ノードごとに対応する内容へ変更する必要があります。
/clickhouse-keeper/keeper_config.xml
各設定ファイルには、次のような固有の設定 (以下参照) を含めます。 使用する server_id は、クラスター内の該当する ClickHouse Keeper ノードごとに一意であり、 <raft_configuration> セクションで定義されたサーバーの <id> と一致している必要があります。 tcp_port は、ClickHouse Keeper のクライアントが使用するポートです。
次のセクションでは、 Raftコンセンサスアルゴリズムのクォーラムに参加する サーバーを設定します。
ClickHouse Cloud なら管理がシンプルになりますClickHouse Cloud を利用すると、分片やレプリカの管理に伴う運用負荷を軽減できます。この プラットフォームでは、高可用性、レプリケーション、スケーリングに関する処理が自動的に行われます。 コンピュートとストレージは分離されており、手動での 設定や継続的な保守を必要とせず、需要に応じてスケールします。詳細はこちら
4

セットアップをテストする

お使いのマシンで Docker が実行中であることを確認してください。 cluster_1S_2R ディレクトリのルートで docker-compose up コマンドを実行し、クラスターを起動します。
docker が ClickHouse と Keeper のイメージのプルを開始し、 その後コンテナーが起動するはずです:
クラスターが稼働していることを確認するには、clickhouse-01 または clickhouse-02 のいずれかに接続し、次のクエリを実行します。以下は、最初のノードに接続するコマンドです:
成功すると、ClickHouse client のプロンプトが表示されます:
どのホストにどのクラスターのトポロジーが定義されているかを確認するには、次の クエリを実行します。
Query
Response
ClickHouse Keeper クラスターの状態を確認するには、次のクエリを実行します。
Query
Response
mntr コマンドは、ClickHouse Keeper が稼働していることを確認し、 3 つの Keeper ノード間の関係に関する状態情報を取得するためにも一般的に使用されます。 この例で使用する構成では、3 つのノードが連携して動作します。 ノードは leader を選出し、残りのノードは followers になります。mntr コマンドでは、パフォーマンスに関する情報に加え、 特定のノードが follower か leader かも確認できます。
mntr コマンドを Keeper に送信するには、netcat のインストールが必要になる場合があります。 ダウンロード方法については、nmap.org のページを参照してください。
以下のコマンドを clickhouse-keeper-01clickhouse-keeper-02、および clickhouse-keeper-03 のシェルで実行し、各 Keeper ノードのステータスを確認します。clickhouse-keeper-01 で実行するコマンドを以下に示します。
以下は、フォロワーノードからのレスポンス例です。
Response
以下は、リーダーノードからのレスポンス例です:
Response
これで、1 つの分片と 2 つのレプリカを持つ ClickHouse クラスターのセットアップは完了です。 次のステップでは、このクラスターにテーブルを作成します。
5

データベースを作成する

クラスターが正しくセットアップされ、稼働していることを確認できたので、 UK property prices サンプルデータセットのチュートリアルで使用したものと同じテーブルを再作成します。これは、1995年以降の イングランドおよびウェールズの不動産の成約価格約3,000万行で構成されています。各ホストのクライアントに接続するには、以下の各コマンドを、それぞれ別のターミナルの タブまたはウィンドウで実行します。
各ホストの clickhouse-client から以下のクエリを実行し、 デフォルト以外のデータベースがまだ作成されていないことを確認できます:
Query
Response
clickhouse-01 クライアントから、uk という名前の新しいデータベースを作成するため、ON CLUSTER 句を使って次の 分散 DDL クエリを実行します:
各ホストのクライアントから先ほどと同じクエリをもう一度実行し、 クエリを実行したのが clickhouse-01 のみであっても、データベースがクラスター全体に作成されていることを確認できます:
6

クラスター上にテーブルを作成する

データベースを作成したら、クラスター上にテーブルを作成します。 以下のクエリを任意のホストクライアントから実行します。
これは、元の CREATE ステートメントで使用された UK property prices サンプルデータセットのチュートリアル内のクエリと同一で、 ON CLUSTER 句と ReplicatedMergeTree エンジンを使用している点だけが異なります。ON CLUSTER 句は、CREATEDROPALTERRENAME などの DDL (Data Definition Language) クエリを分散実行するためのもので、これらの スキーマ変更がクラスター内のすべてのノードに適用されるようにします。ReplicatedMergeTree エンジンは通常の MergeTree テーブルエンジンと同様に動作しますが、データもレプリケーションされます。以下のクエリを clickhouse-01 または clickhouse-02 のいずれかのクライアントから実行すると、 テーブルがクラスター全体で作成されていることを確認できます。
Query
Response
7

データの挿入

データセットは大きく、完全に取り込むには数分かかるため、まずは少量のサブセットのみを挿入します。以下のクエリを使用して、clickhouse-01 からデータの小さなサブセットを挿入してください:
データが各ホストに完全にレプリケートされていることに注目してください:
ホストに障害が発生した場合の動作を確認するため、いずれかのホストからシンプルなテスト用データベースとテスト用テーブルを作成します。
uk_price_paid テーブルと同様に、どちらのホストからもデータを挿入できます:
では、ホストの1つがダウンした場合はどうなるでしょうか?これをシミュレートするために、次のコマンドを実行して clickhouse-01 を停止します:
次のコマンドを実行して、ホストがダウンしていることを確認します:
Response
clickhouse-01 がダウンしている状態で、テストテーブルにもう1行データを挿入し、テーブルをクエリします:
Response
次のコマンドで clickhouse-01 を再起動してください (再起動後に docker-compose ps を再度実行して確認できます) :
docker exec -it clickhouse-01 clickhouse-client を実行した後、clickhouse-01 からテストテーブルに再度クエリを実行します。
Query
Response
この段階でUKの不動産価格データセット全体を取り込んで試したい場合は、以下のクエリを実行してください。
clickhouse-02 または clickhouse-01 からテーブルにクエリを実行します:
Query
Response

結論

このクラスター トポロジーの利点は、レプリカが 2 つあることで、 データが 2 台の異なるホストに存在する点です。1 台のホストで障害が発生しても、もう一方のレプリカが データ提供を損失なく継続します。これにより、ストレージ層における単一障害点を 排除できます。 1 台のホストが停止しても、残っているレプリカでは引き続き次のことが可能です。
  • 読み取りクエリを中断なく処理する
  • 新しい書き込みを受け付ける (整合性設定によって異なります)
  • アプリケーション向けのサービス可用性を維持する
障害が発生したホストがオンラインに復帰すると、次のことが可能になります。
  • 正常なレプリカから不足データを自動的に同期する
  • 手動で介入しなくても通常運用を再開する
  • 完全な冗長性をすばやく復元する
次の例では、分片が 2 つあり、 レプリカが 1 つだけのクラスターをどのようにセットアップするかを見ていきます。
最終更新日 2026年7月23日