データのレプリケーション
この例では、データをレプリケートするシンプルな ClickHouse クラスターのセットアップ方法を学びます。ここでは 5 台のサーバーを構成します。うち 2 台はデータのコピーを保持するために使用します。残りの 3 台のサーバーは、データレプリケーションを調整するために使用します。
これからセットアップするクラスターのアーキテクチャは、次のとおりです。

ClickHouse Server と ClickHouse Keeper を同じサーバー上で動かすことも可能ですが、 本番環境では ClickHouse Keeper 用に 専用 ホストを使用することを強く推奨します。 この例でもその構成を用いて説明します。
Keeper サーバーは小さめの構成でも問題なく、各 Keeper サーバーあたり 4GB の RAM があれば、 ClickHouse Server 群が大きくなるまでは一般的には十分です。
前提条件
- 以前に ローカルの ClickHouse サーバー をセットアップしている
- 設定ファイル など、ClickHouse の基本的な設定の概念を理解している
- 使用しているマシンに Docker がインストールされている
ディレクトリ構造とテスト環境のセットアップ
以下の手順では、クラスターをゼロからセットアップする方法を順を追って説明します。これらの手順をスキップしてすぐにクラスターを起動したい場合は、examples リポジトリの 'docker-compose-recipes' ディレクトリ からサンプルファイルを取得できます。
このチュートリアルでは、Docker composeを使用してClickHouseクラスタをセットアップします。このセットアップは、個別のローカルマシン、仮想マシン、クラウドインスタンスでも動作するように変更可能です。
この例のディレクトリ構造をセットアップするには、以下のコマンドを実行します:
以下の docker-compose.yml ファイルを cluster_1S_2R ディレクトリに追加します:
以下のサブディレクトリとファイルを作成します:
config.dディレクトリには ClickHouse サーバーの設定ファイルconfig.xmlが含まれており、 各 ClickHouse ノード向けのカスタム設定がここで定義されます。 この設定は、すべての ClickHouse インストールに付属するデフォルトの ClickHouse 設定ファイルconfig.xmlとマージされて使用されます。users.dディレクトリにはユーザー設定ファイルusers.xmlが含まれており、 ユーザーに対するカスタム設定がここで定義されます。 この設定は、すべての ClickHouse インストールに付属するデフォルトの ClickHouse 設定ファイルusers.xmlとマージされて使用されます。
独自の設定を記述する際には、/etc/clickhouse-server/config.xml および
etc/clickhouse-server/users.xml のデフォルト設定を直接変更するのではなく、
config.d および users.d ディレクトリを利用することがベストプラクティスです。
The line
config.d および users.d ディレクトリで定義された設定セクションが、デフォルトの config.xml および users.xml ファイルで定義されている設定セクションより優先されるようにします。
ClickHouseノードの設定
サーバーのセットアップ
次に、fs/volumes/clickhouse-{}/etc/clickhouse-server/config.dに配置されている各空の設定ファイルconfig.xmlを修正します。以下で強調表示されている行は、各ノードに固有の内容に変更する必要があります:
| ディレクトリ | ファイル |
|---|---|
fs/volumes/clickhouse-01/etc/clickhouse-server/config.d | config.xml |
fs/volumes/clickhouse-02/etc/clickhouse-server/config.d | config.xml |
上記の設定ファイルの各セクションについて、以下で詳細に説明します。
ネットワーキングとロギング
ネットワークインターフェースへの外部からの通信は、listen_host 設定を有効にすることで行えるようになります。これにより、ClickHouse サーバーホストには他のホストから接続できるようになります。
HTTP API 用のポートは 8123 に設定されています:
ClickHouse のネイティブプロトコルを使用した clickhouse-client と他のネイティブ ClickHouse ツール間、ならびに clickhouse-server と他の clickhouse-server 間の通信に用いられる TCP ポートは 9000 です。
ログ記録は <logger> ブロックで定義します。この設定例では、1000Mに達すると3回ローテーションするデバッグログが出力されます:
ログ設定の詳細については、デフォルトのClickHouse設定ファイルに含まれているコメントを参照してください。
クラスター設定
クラスタの設定は <remote_servers> ブロックで設定します。
ここでクラスタ名 cluster_1S_2R を定義します。
<cluster_1S_2R></cluster_1S_2R> ブロックは、<shard></shard> および <replica></replica> 設定を使用してクラスタのレイアウトを定義し、分散DDLクエリのテンプレートとして機能します。分散DDLクエリは、ON CLUSTER 句を使用してクラスタ全体で実行されるクエリです。デフォルトでは分散DDLクエリは許可されていますが、allow_distributed_ddl_queries 設定により無効化することも可能です。
internal_replication を true に設定すると、データはレプリカの1つにのみ書き込まれます。
各サーバーごとに、次のパラメータを指定します。
| Parameter | Description | Default Value |
|---|---|---|
host | リモートサーバーのアドレス。ドメイン名、IPv4 アドレス、または IPv6 アドレスのいずれかを使用できます。ドメイン名を指定した場合、サーバー起動時に DNS リクエストが行われ、その結果はサーバーの動作中保持されます。DNS リクエストが失敗した場合、サーバーは起動しません。DNS レコードを変更した場合は、サーバーを再起動する必要があります。 | - |
port | messenger の動作に使用する TCP ポート(設定ファイルの tcp_port。通常は 9000 に設定)。http_port と混同しないでください。 | - |
Keeper の設定
<ZooKeeper> セクションは、ClickHouse Keeper(または ZooKeeper)の実行場所を ClickHouse に指定します。
ClickHouse Keeper クラスタを使用する場合、クラスタの各 <node> を指定する必要があります。
ホスト名とポート番号はそれぞれ <host> タグと <port> タグを使用して指定します。
ClickHouse Keeperのセットアップは、チュートリアルの次のステップで説明されています。
ClickHouse KeeperをClickHouse Serverと同じサーバー上で実行することは可能ですが、本番環境では専用ホスト上で実行することを強く推奨します。
マクロの設定
また、<macros> セクションは、レプリケーテッドテーブルのパラメータ置換を定義するために使用されます。これらは system.macros に記載され、クエリ内で {shard} や {replica} などの置換を使用できます。
これらはクラスタの構成に応じて個別に定義する必要があります。
ユーザー設定
次に、fs/volumes/clickhouse-{}/etc/clickhouse-server/users.d に配置されている各空の設定ファイル users.xml を以下の内容で変更します:
| ディレクトリ | ファイル |
|---|---|
fs/volumes/clickhouse-01/etc/clickhouse-server/users.d | users.xml |
fs/volumes/clickhouse-02/etc/clickhouse-server/users.d | users.xml |
この例では、簡略化のためデフォルトユーザーをパスワードなしで設定しています。 実際の運用環境では、この設定は推奨されません。
この例では、クラスター内のすべてのノードでusers.xmlファイルが同一です。
ClickHouse Keeperの設定
Keeperのセットアップ
レプリケーションを機能させるためには、ClickHouse Keeper クラスターをセットアップして 構成する必要があります。ClickHouse Keeper はデータレプリケーションのためのコーディネーションシステムを提供し、 ZooKeeper の代替として動作しますが、ZooKeeper を使用することも可能です。 ただし ClickHouse Keeper は、より強い保証と高い信頼性を提供し、ZooKeeper よりも少ないリソースで 動作するため推奨されます。高可用性とクォーラム維持のために、少なくとも 3 つの ClickHouse Keeper ノードを 実行することを推奨します。
ClickHouse Keeper はクラスター内の任意のノード上で ClickHouse と一緒に実行できますが、 スケーリングおよびデータベースクラスターとは独立した ClickHouse Keeper クラスターの管理を可能にするため、 専用ノード上で実行することを推奨します。
各 ClickHouse Keeper ノード用の keeper_config.xml ファイルを、
サンプルディレクトリのルートから次のコマンドを使用して作成します:
各ノードのディレクトリ fs/volumes/clickhouse-keeper-{}/etc/clickhouse-keeper に作成された空の設定ファイルを編集します。
以下のハイライトされた行を、各ノードに固有の設定となるように変更してください。
| ディレクトリ | ファイル |
|---|---|
fs/volumes/clickhouse-keeper-01/etc/clickhouse-keeper | keeper_config.xml |
fs/volumes/clickhouse-keeper-02/etc/clickhouse-keeper | keeper_config.xml |
fs/volumes/clickhouse-keeper-03/etc/clickhouse-keeper | keeper_config.xml |
各設定ファイルには、以下のような固有の設定が含まれています(下記参照)。
使用する server_id は、そのクラスタ内で該当する ClickHouse Keeper ノードごとに一意であり、
<raft_configuration> セクションで定義されているサーバーの <id> と一致している必要があります。
tcp_port は ClickHouse Keeper の クライアント が使用するポートです。
次のセクションでは、Raft 合意アルゴリズム の クォーラムに参加するサーバーを構成します。
ClickHouse Cloud は、シャードおよびレプリカの管理に伴う運用上の負担を取り除きます。 プラットフォームが高可用性の確保、レプリケーション、およびスケーリングに関する判断を自動的に行います。 コンピュートリソースとストレージは分離されており、需要に応じて自動的にスケールするため、手動での設定や継続的なメンテナンスは不要です。
セットアップのテスト
マシン上でDockerが実行されていることを確認してください。
cluster_1S_2Rディレクトリのルートからdocker-compose upコマンドを使用してクラスターを起動します:
dockerがClickHouseとKeeperのイメージをプルし、 その後コンテナを起動する様子が確認できます:
クラスタが稼働していることを確認するには、clickhouse-01 または clickhouse-02 のいずれかに接続し、以下のクエリを実行します。最初のノードへの接続コマンドは次のとおりです:
成功すると、ClickHouseクライアントのプロンプトが表示されます:
以下のクエリを実行して、各ホストに定義されているクラスタトポロジを確認します:
以下のクエリを実行して、ClickHouse Keeperクラスタのステータスを確認します:
mntr コマンドは、ClickHouse Keeper が稼働していることを確認し、
3 つの Keeper ノード間の関係に関する状態情報を取得するためにも一般的に使用されます。
この例で使用している構成では、3 つのノードが協調して動作しています。
ノード間でリーダーを選出し、残りのノードはフォロワーになります。
mntr コマンドは、パフォーマンスに関連する情報と、特定のノードが
フォロワーかリーダーかを示します。
Keeper に mntr コマンドを送信するには、netcat をインストールする必要がある場合があります。
ダウンロード情報については nmap.org のページを参照してください。
各 Keeper ノードのステータスを確認するために、clickhouse-keeper-01、clickhouse-keeper-02、
clickhouse-keeper-03 上のシェルから以下のコマンドを実行します。
clickhouse-keeper-01 用のコマンドは次のとおりです。
以下は、フォロワーノードからの応答例です。
以下は、リーダーノードからの応答例です。
これで、1つのシャードと2つのレプリカを持つClickHouseクラスタのセットアップが完了しました。 次のステップでは、クラスタにテーブルを作成します。
データベースを作成する
クラスタが正しくセットアップされ、実行されていることを確認したので、UK property pricesサンプルデータセットチュートリアルで使用されているものと同じテーブルを再作成します。このデータセットは、1995年以降にイングランドとウェールズで取引された不動産物件の価格データ約3,000万行で構成されています。
各ホストのクライアントに接続するには、以下の各コマンドを別々のターミナルタブまたはウィンドウから実行します:
各ホストのclickhouse-clientから以下のクエリを実行して、デフォルトのデータベース以外にデータベースが作成されていないことを確認してください:
clickhouse-01 クライアントから、ON CLUSTER 句を使用して以下の分散型 DDL クエリを実行し、uk という名前の新しいデータベースを作成します:
各ホストのクライアントから先ほどと同じクエリを再度実行し、clickhouse-01でのみクエリを実行したにもかかわらず、クラスタ全体でデータベースが作成されていることを確認できます。
クラスタ上にテーブルを作成する
データベースが作成されたので、クラスタ上にテーブルを作成します。 任意のホストクライアントから以下のクエリを実行してください:
これは、英国不動産価格サンプルデータセットチュートリアルの元のCREATE文で使用されたクエリと同一です。ただし、ON CLUSTER句とReplicatedMergeTreeエンジンの使用が異なる点に注意してください。
ON CLUSTER句は、CREATE、DROP、ALTER、RENAMEなどのDDL(Data Definition Language)クエリを分散実行するために設計されており、これらのスキーマ変更をクラスタ内のすべてのノードに適用します。
ReplicatedMergeTreeエンジンは、通常のMergeTreeテーブルエンジンと同様に動作しますが、データのレプリケーションも行います。
clickhouse-01 または clickhouse-02 のいずれかのクライアントから以下のクエリを実行して、クラスタ全体でテーブルが作成されたことを確認します:
データの挿入
データセットが大きく、完全に取り込むには数分かかるため、まず小さなサブセットのみを挿入します。
clickhouse-01 から以下のクエリを使用して、データの一部を挿入します:
各ホストでデータが完全にレプリケートされていることに注意してください:
ホストの1つに障害が発生した場合の動作を確認するため、いずれかのホストから簡単なテストデータベースとテストテーブルを作成します:
uk_price_paidテーブルと同様に、いずれのホストからでもデータを挿入できます:
ホストの1台がダウンした場合、何が起こるでしょうか?これをシミュレートするには、以下を実行してclickhouse-01を停止します:
以下を実行してホストがダウンしていることを確認します:
clickhouse-01 が停止している状態で、テストテーブルに別のデータ行を挿入し、
テーブルをクエリします:
次のコマンドで clickhouse-01 を再起動します(確認のため、その後 docker-compose ps を再度実行できます):
docker exec -it clickhouse-01 clickhouse-client を実行した後、clickhouse-01 からテストテーブルに再度クエリを実行します:
この段階で英国不動産価格データセット全体を取り込んで操作してみたい場合は、以下のクエリを実行してください。
clickhouse-02 または clickhouse-01 からテーブルをクエリします:
まとめ
このクラスタートポロジーの利点は、2 つのレプリカを持つことで データを 2 台の別々のホスト上に保持できる点です。片方のホストが障害を起こしても、 もう一方のレプリカがデータを損失なく提供し続けます。これにより、ストレージレベルでの 単一障害点が排除されます。
一方のホストがダウンしても、残っているレプリカは次のことができます。
- 中断なく読み取りクエリを処理する
- (整合性設定に応じて)新規書き込みを受け付ける
- アプリケーション向けのサービス可用性を維持する
障害が発生したホストがオンラインに戻ると、次のことができます。
- 正常なレプリカから不足しているデータを自動的に同期する
- 手動での介入なしに通常運用へ復帰する
- 速やかに完全な冗長性を回復する
次の例では、2 つのシャードを持ち、レプリカが 1 つだけのクラスターを どのように構成するかを見ていきます。