データのレプリケーション
この例では、データをレプリケートするシンプルな ClickHouse クラスターを設定する方法を学びます。5 台のサーバーが構成されています。2 台はデータのコピーをホストするために使用され、残りの 3 台はデータのレプリケーションを調整するために使用されます。
設定するクラスターのアーキテクチャは以下の通りです。

ClickHouse Server と ClickHouse Keeper を同じサーバーで実行することは可能ですが、
本番環境では ClickHouse keeper に専用のホストを使用することを強く推奨します。
これがこの例で説明するアプローチです。
Keeper サーバーは小型で済むことがあり、4GB の RAM で一般的には各 Keeper サーバーに十分です
あなたの ClickHouse Servers が大きくなるまでは。
前提条件
- 以前に ローカル ClickHouse サーバー をセットアップしたことがある
- 構成ファイル など、ClickHouse の基本的な構成概念に精通している
- あなたのマシンに Docker がインストールされている
ディレクトリ構造とテスト環境の設定
以下の手順では、最初からクラスタをセットアップする方法を説明します。これらの手順を省略して直接クラスタを実行したい場合は、examples repository から例のファイルを取得できます。
このチュートリアルでは、 Docker compose を使用して ClickHouse クラスターを設定します。この設定は、別のローカル マシン、仮想マシン、またはクラウド インスタンスでも機能するように変更できます。
以下のコマンドを実行して、この例のためのディレクトリ構造を設定します。
次に、cluster_1S_2R
ディレクトリに以下の docker-compose.yml
ファイルを追加します。
以下のサブディレクトリとファイルを作成します。
config.d
ディレクトリには ClickHouse サーバーの設定ファイルconfig.xml
が含まれており、各 ClickHouse ノードのカスタム設定が定義されています。この設定は、すべての ClickHouse インストールに付属するデフォルトのconfig.xml
ClickHouse 設定ファイルと組み合わされます。users.d
ディレクトリにはユーザー設定ファイルusers.xml
が含まれており、ユーザー向けのカスタム設定が定義されています。この設定も、すべての ClickHouse インストールに付属するデフォルトの ClickHouseusers.xml
設定ファイルと組み合わされます。
独自の設定を書く際は、デフォルトの設定を直接 /etc/clickhouse-server/config.xml
および etc/clickhouse-server/users.xml
で修正するのではなく、config.d
と users.d
ディレクトリを活用することがベストプラクティスです。
この行
は、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 |
上記の構成ファイルの各セクションについては、以下で詳しく説明します。
ネットワーキングとロギング
外部通信は、リッスンホスト設定を有効にすることによってネットワークインターフェースに対して行われます。これにより、ClickHouseサーバーホストが他のホストから到達可能になります:
HTTP APIのポートは8123
に設定されています:
ClickHouseのネイティブプロトコルによるclickhouse-clientと他のネイティブClickHouseツール、およびclickhouse-serverと他のclickhouse-serversとの間の相互作用のためのTCPポートは9000
に設定されています:
ロギングは <logger>
ブロックで定義されています。この例の構成では、1000M ごとに 3 回ロールオーバーするデバッグログを提供します。
ロギング構成の詳細については、デフォルトの ClickHouse 構成ファイル に含まれているコメントを参照してください。
クラスター構成
クラスターの構成は <remote_servers>
ブロックで設定されています。ここでクラスター名 cluster_1S_2R
が定義されています。
<cluster_1S_2R></cluster_1S_2R>
ブロックは、クラスターのレイアウトを定義し、 <shard></shard>
と <replica></replica>
設定を使用し、 ON CLUSTER
句を使用してクラスター全体で実行されるクエリのテンプレートとして機能します。デフォルトでは、分散 DDL クエリは許可されていますが、allow_distributed_ddl_queries
設定でオフにすることもできます。
internal_replication
は、データがレプリカの 1 つにのみ書き込まれるように true に設定されています。
各サーバーには、以下のパラメータが指定されています:
パラメータ | 説明 | デフォルト値 |
---|---|---|
host | リモートサーバーのアドレスです。ドメイン名またはIPv4またはIPv6アドレスのいずれかを使用できます。ドメインを指定すると、サーバーは起動時にDNSリクエストを行い、その結果はサーバーが稼働している間保存されます。DNSリクエストが失敗すると、サーバーは起動しません。DNSレコードを変更した場合は、サーバーを再起動する必要があります。 | - |
port | メッセンジャーアクティビティ用のTCPポート(設定のtcp_port 、通常は9000に設定されています)。http_port と混同しないでください。 | - |
Keeper 構成
<ZooKeeper>
セクションは、ClickHouse が ClickHouse Keeper (または ZooKeeper) が実行されている場所を指示します。ClickHouse Keeper クラスターを使用しているため、クラスターの各 <node>
は、次のように <host>
および <port>
タグを使用して、そのホスト名とポート番号を指定する必要があります。
ClickHouse Keeper のセットアップは、チュートリアルの次のステップで説明します。
ClickHouse Keeper を ClickHouse サーバーと同じサーバーで実行することは可能ですが、運用環境では ClickHouse Keeper を専用ホストで実行することを強く推奨します。
マクロ構成
さらに、<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 の使用が推奨されます。なぜなら、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-server/config.d | keeper_config.xml |
fs/volumes/clickhouse-keeper-02/etc/clickhouse-server/config.d | keeper_config.xml |
fs/volumes/clickhouse-keeper-03/etc/clickhouse-server/config.d | keeper_config.xml |
各設定ファイルには、以下のユニークな設定が含まれます(下記参照)。
使用される server_id
は、その特定の ClickHouse Keeper ノードに対してユニークで、<raft_configuration>
セクションで定義されたサーバーの <id>
と一致する必要があります。
tcp_port
は ClickHouse Keeper の クライアント によって使用されるポートです。
以下のセクションは、raft 合意アルゴリズム に参加するサーバーを構成するために使用されます:
ClickHouse Cloud は、シャードやレプリカの管理に伴う運用上の負担を取り除きます。この プラットフォームは、高可用性、レプリケーション、およびスケーリングの決定を自動的に処理します。 コンピューティングとストレージは別々にスケールし、手動での設定や継続的なメンテナンスを必要とせずに需要に応じてスケールします。
セットアップのテスト
Docker がマシンで実行されていることを確認してください。docker-compose up
コマンドを cluster_1S_2R
ディレクトリのルートから使用してクラスターを起動します。
ClickHouse と Keeper のイメージを Docker がプルし始め、その後、コンテナーが開始されるのを見ることができるはずです。
クラスターが実行されていることを確認するために、clickhouse-01
または clickhouse-02
のいずれかに接続し、以下のクエリを実行します。最初のノードに接続するためのコマンドは以下の通りです。
成功すると、ClickHouse クライアントのプロンプトが表示されます。
次のクエリを実行して、どのホストにどのクラスター トポロジーが定義されているかを確認します。
次のクエリを実行して、ClickHouse Keeper クラスターのステータスを確認します。
mntr
コマンドは、ClickHouse Keeper が実行されているかを確認し、3 つの Keeper ノードの関係に関する状態情報を取得するためにも一般的に使用されます。この例で使用される構成では、3 つのノードが協力して動作しています。ノードはリーダーを選出し、残りのノードはフォロワーになります。
mntr
コマンドは、パフォーマンスに関連する情報や、特定のノードがフォロワーなのかリーダーなのかを示します。
mntr
コマンドを Keeper に送信するためには、netcat
をインストールする必要があるかもしれません。ダウンロード情報については nmap.org ページをご覧ください。
以下のコマンドを clickhouse-keeper-01
、clickhouse-keeper-02
、および clickhouse-keeper-03
のシェルから実行して、各 Keeper ノードのステータスを確認します。clickhouse-keeper-01
のためのコマンドは以下のようになります。
以下のレスポンスは、フォロワーノードからの応答の例を示しています:
以下のレスポンスは、リーダーノードからの応答の例を示しています:
これで、単一のシャードと 2 つのレプリカを持つ ClickHouse クラスターを正常にセットアップしました。次のステップでは、クラスターにテーブルを作成します。
データベースを作成する
クラスターが正しく設定され、実行されていることを確認したので、 UK property prices の例データセットで使用されているのと同じテーブルを再作成します。これは、1995 年以降のイギリスとウェールズでの不動産の価格に関する約 3000 万行のデータで構成されています。
以下のコマンドを別々のターミナル タブまたはウィンドウから実行して、各ホストのクライアントに接続します。
以下のクエリを各ホストの clickhouse-client から実行して、デフォルトのもの以外にまだデータベースが作成されていないことを確認できます。
clickhouse-01
クライアントから以下の 分散 DDL クエリを ON CLUSTER
句を使用して実行し、uk
という新しいデータベースを作成します。
再度、各ホストのクライアントから同じクエリを実行して、clickhouse-01
でクエリを実行したにもかかわらず、データベースがクラスター全体に作成されていることを確認できます。
クラスター上にテーブルを作成する
データベースが作成されたので、クラスター上にテーブルを作成します。任意のホストのクライアントから以下のクエリを実行してください。
それが、UK property prices の例データセットチュートリアルの元の CREATE
ステートメントで使用されているクエリと同一であることに気付くでしょう。ただし ON CLUSTER
句と ReplicatedMergeTree
エンジンの使用が異なります。
ON CLUSTER
句は、CREATE
、DROP
、ALTER
、および RENAME
のような DDL (データ定義言語) クエリを分散して実行するために設計されており、これらのスキーマ変更がクラスター内のすべてのノードに適用されることを保証します。
ReplicatedMergeTree
エンジンは、通常の MergeTree
テーブルエンジンと同様に機能しますが、データもレプリケートします。
clickhouse-01
または clickhouse-02
クライアントから以下のクエリを実行して、テーブルがクラスター全体に作成されたことを確認できます。
データを挿入する
データセットが大きく、完全に取り込むのに数分かかるため、最初に小さなサブセットのみを挿入します。
以下のクエリを使用して、clickhouse-01
からデータの小さなサブセットを挿入します。
データは各ホストに完全にレプリケートされることに注意してください。
ホストの 1 つが失敗した場合に何が起こるかを示すために、どちらかのホストから簡単なテストデータベースとテストテーブルを作成します。
uk_price_paid
テーブルと同様に、どちらのホストからでもデータを挿入できます。
しかし、ホストの 1 つがダウンした場合はどうなりますか?これをシミュレートするために、次のコマンドを実行して clickhouse-01
を停止します。
以下のコマンドを実行して、ホストがダウンしていることを確認します。
clickhouse-01
がダウンした状態で、テストテーブルに新しい行を挿入して、テーブルをクエリします。
次に、以下のコマンドを実行して clickhouse-01
を再起動します(再起動後に確認するために再度 docker-compose ps
を実行できます)。
clickhouse-01
で docker exec -it clickhouse-01 clickhouse-client
を実行した後に再度テストテーブルをクエリします。
この時点で、完全な UK property price データセットを取り込んで遊びたい場合は、次のクエリを実行できます。
clickhouse-02
または clickhouse-01
からテーブルをクエリします。
結論
このクラスター トポロジーの利点は、2 つのレプリカを使用することで、データが 2 つの異なるホストに存在することです。1 つのホストが障害を起こしても、他のレプリカはデータを失うことなく提供を続けます。これにより、ストレージ レベルでの障害の単一ポイントが排除されます。
1 つのホストがダウンすると、残りのレプリカは次のことが可能です。
- 中断なしに読み取りクエリを処理する
- 新しい書き込みを受け入れる (一貫性設定による)
- アプリケーションのサービス可用性を維持する
障害が発生したホストがオンラインに戻ると、次のことが可能です。
- 健全なレプリカから不足しているデータを自動的に同期する
- 手動介入なしで通常の操作を再開する
- 迅速に完全な冗長性を回復する
次の例では、2 つのシャードを持ち、レプリカは 1 つだけのクラスターを設定する方法について見ていきます。