レプリケーション + スケーリング
この例では、レプリケーションとスケーリングの両方を行うシンプルなClickHouseクラスタのセットアップ方法を学びます。これは、2つのシャードと2つのレプリカから成り、クラスター内での調整とクオラムを維持するために3ノードのClickHouse Keeperクラスターを使用します。
あなたが設定するクラスターのアーキテクチャは以下の通りです。

ClickHouse Server と ClickHouse Keeper を同じサーバーで実行することは可能ですが、
本番環境では ClickHouse keeper に専用のホストを使用することを強く推奨します。
これがこの例で説明するアプローチです。
Keeper サーバーは小型で済むことがあり、4GB の RAM で一般的には各 Keeper サーバーに十分です
あなたの ClickHouse Servers が大きくなるまでは。
前提条件
- あなたは以前にローカルClickHouseサーバーをセットアップしている
- あなたはClickHouseの基本的な設定概念、例えば設定ファイルに慣れている
- あなたのマシンにdockerがインストールされている
ディレクトリ構造とテスト環境の設定
以下の手順では、最初からクラスタをセットアップする方法を説明します。これらの手順を省略して直接クラスタを実行したい場合は、examples repository から例のファイルを取得できます。
このチュートリアルでは、Docker composeを使用してClickHouseクラスタをセットアップします。このセットアップは、別のローカルマシン、仮想マシン、またはクラウドインスタンスでも動作するように変更できます。
次のコマンドを実行して、この例のためのディレクトリ構造を設定します。
次のdocker-compose.ymlファイルをclickhouse-clusterディレクトリに追加します:
以下のサブディレクトリとファイルを作成します:
config.dディレクトリには ClickHouse サーバーの設定ファイルconfig.xmlが含まれており、各 ClickHouse ノードのカスタム設定が定義されています。この設定は、すべての ClickHouse インストールに付属するデフォルトのconfig.xmlClickHouse 設定ファイルと組み合わされます。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 |
fs/volumes/clickhouse-03/etc/clickhouse-server/config.d | config.xml |
fs/volumes/clickhouse-04/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_2S_2Rが定義されています。
<cluster_2S_2R></cluster_2S_2R>ブロックは、シャードのレイアウトを定義し、分散DDLクエリ(ON CLUSTER句を使用してクラスター全体で実行されるクエリ)のテンプレートとして機能します。デフォルトでは、分散DDLクエリは許可されていますが、allow_distributed_ddl_queriesの設定を使ってオフにすることもできます。
internal_replicationはtrueに設定されており、データは1つのレプリカに書き込まれます。
<cluster_2S_2R></cluster_2S_2R>セクションはクラスターのレイアウトを定義し、ON CLUSTER句を用いてクラスター全体で実行される分散DDLクエリのテンプレートとして機能します。
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.xmlファイルはクラスタ内のすべてのノードで同一です。
ClickHouse Keeperの設定
次に、調整用に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が実行されていることを確認してください。
cluster_2S_2Rディレクトリのルートからdocker-compose upコマンドを使用してクラスターを起動します:
ClickHouseおよびKeeperのイメージをdockerがプルし始め、その後コンテナが起動されるのを見ることができるはずです:
クラスターが稼働していることを確認するために、任意のノードに接続して以下のクエリを実行します。最初のノードへの接続コマンドは以下の通りです:
成功すれば、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つのシャードと2つのレプリカを持つClickHouseクラスタが正常にセットアップされました。次のステップでは、クラスター内にテーブルを作成します。
データベースの作成
クラスターが正しく設定されて稼働していることを確認したので、UKの物件価格例のデータセットで使用されているのと同じテーブルを再作成します。これは、1995年以降のイングランドとウェールズの不動産物件の支払い価格約3000万行から構成されています。
各ホストのクライアントに接続するには、別々のターミナルタブまたはウィンドウから以下の各コマンドを実行します:
各ホストのclickhouse-clientから以下のクエリを実行して、デフォルトのものを除いてまだ作成されていないデータベースがないことを確認できます:
clickhouse-01クライアントから、ON CLUSTER句を使用して新しいデータベースukを作成するための分散DDLクエリを実行します:
再度、前回と同じクエリを各ホストのクライアントから実行して、clickhouse-01からのみクエリを実行したにもかかわらず、クラスター全体でデータベースが作成されたことを確認します:
クラスター上に分散テーブルを作成する
データベースが作成されたので、次に分散テーブルを作成します。分散テーブルは、異なるホストにあるシャードにアクセスできるテーブルであり、Distributedテーブルエンジンを使用して定義されます。分散テーブルは、クラスター内のすべてのシャードを通じてのインターフェースとして機能します。
任意のホストクライアントから以下のクエリを実行します:
これは、UKの物件価格例のデータセットチュートリアルの元のCREATEステートメントで使用されたクエリと同一ですが、ON CLUSTER句とReplicatedMergeTreeエンジンの使用を除いています。
ON CLUSTER句は、CREATE、DROP、ALTER、RENAMEなどのDDL(データ定義言語)クエリの分散実行のために設計されており、これらのスキーマ変更がクラスター内のすべてのノードに適用されることを保証します。
ReplicatedMergeTreeエンジンは、普通のMergeTreeテーブルエンジンと同様に機能しますが、データも複製します。これは、以下の2つのパラメータを指定する必要があります:
zoo_path: テーブルのメタデータへのKeeper/ZooKeeperパス。replica_name: テーブルのレプリカ名。
zoo_pathパラメータは、任意の値に設定できますが、次の接頭辞を用いることが推奨されます。
ここで:
{database}と{table}は自動的に置換されます。{shard}と{replica}は、各ClickHouseノードのconfig.xmlファイルで定義されたマクロです。
各ホストのクライアントから、テーブルがクラスター全体に作成されたことを確認するためのクエリを実行できます:
分散テーブルにデータを挿入する
分散テーブルにデータを挿入するには、ON CLUSTERを使用することはできません。これは、INSERT、UPDATE、およびDELETEなどのDML(データ操作言語)クエリには適用されません。データを挿入するには、Distributedテーブルエンジンを使用する必要があります。
任意のホストクライアントから以下のクエリを実行して、先にON CLUSTERとReplicatedMergeTreeを使用して作成した既存のテーブルを利用して分散テーブルを作成します:
各ホストのukデータベースには、次のようなテーブルが表示されます:
データは、以下のクエリを使用して任意のホストクライアントからuk_price_paid_distributedテーブルに挿入できます:
以下のクエリを実行して、挿入されたデータがクラスターのノードに均等に分散されていることを確認します: