レプリケーション

このエンジンはAtomicエンジンに基づいています。メタデータのレプリケーションは、DDLログがZooKeeperに書き込まれ、指定されたデータベースのすべてのレプリカで実行されることをサポートしています。

1つのClickHouseサーバーは、同時に複数のレプリケートされたデータベースを実行および更新できます。ただし、同じレプリケートされたデータベースの複数のレプリカを持つことはできません。

データベースの作成

エンジンパラメータ

zoo_path — ZooKeeperパス。同じZooKeeperパスは、同じデータベースに対応します。
shard_name — シャード名。データベースのレプリカはshard_nameによってシャードにグループ化されます。
replica_name — レプリカ名。レプリカ名は、同じシャードのすべてのレプリカで異ならなければなりません。

ReplicatedMergeTree テーブルの場合、引数が提供されていない場合は、デフォルトの引数が使用されます：/clickhouse/tables/{uuid}/{shard}および{replica}。これらはサーバー設定のdefault_replica_pathおよびdefault_replica_nameで変更できます。マクロ{uuid}はテーブルのuuidに展開され、{shard}および{replica}はデータベースエンジンの引数からではなく、サーバー構成の値に展開されます。ただし、将来的にはReplicatedデータベースのshard_nameとreplica_nameを使用できるようになります。

特徴と推奨事項

DDLクエリは、ReplicatedデータベースでON CLUSTERクエリと似たように動作しますが、いくつかの違いがあります。

まず、DDLリクエストは、イニシエーター（元々リクエストを受け取ったホスト）で実行しようとします。リクエストが満たされない場合、ユーザーは直ちにエラーを受け取り、他のホストはそれを満たそうとはしません。リクエストがイニシエーターで正常に完了した場合、すべての他のホストは自動的に再試行を行い、完了するまで待機します。イニシエーターは、他のホストでのクエリの完了を待つことを試みます（distributed_ddl_task_timeoutを超えない範囲で）し、各ホストでのクエリ実行ステータスのテーブルを返します。

エラーが発生した場合の動作は、distributed_ddl_output_mode設定で制御されており、Replicatedデータベースには、null_status_on_timeoutに設定するのが良いです — つまり、いくつかのホストがdistributed_ddl_task_timeoutのリクエストを実行する時間がなかった場合、例外をスローするのではなく、そのホストに対してNULLステータスをテーブルに表示します。

system.clustersシステムテーブルには、レプリケートされたデータベースと同名のクラスタが含まれており、データベースのすべてのレプリカで構成されます。このクラスタはレプリカの作成/削除時に自動的に更新され、Distributedテーブルに使用できます。

データベースの新しいレプリカを作成する際、このレプリカは自らテーブルを作成します。レプリカが長い間利用できなかったり、レプリケーションログから遅れると、ローカルメタデータとZooKeeper内の現在のメタデータをチェックし、データを持つ余分なテーブルを、誤って何か余計なものを削除しないように別の非レプリケートデータベースに移動し、欠落しているテーブルを作成し、別名に変更された場合にはテーブル名を更新します。データはReplicatedMergeTreeレベルでレプリケートされます。つまり、テーブルがレプリケートされていない場合、データはレプリケートされない（データベースはメタデータのみを担当します）。

クラスタの設定を構成する必要があるだけで、テーブルのレプリケーションを維持する必要がない場合は、Cluster Discovery機能を参照してください。

使用例

3つのホストを持つクラスタを作成：

DDLクエリを実行：

システムテーブルを表示：

分散テーブルを作成し、データを挿入：

もう1つのホストにレプリカを追加：

クラスタ構成は次のようになります：

分散テーブルも新しいホストからデータを取得します：

データベースの作成​

特徴と推奨事項​

使用例​

データベースの作成

特徴と推奨事項

使用例