复制的
该引擎基于 Atomic 引擎。它支持通过将 DDL 日志写入 ZooKeeper 并在给定数据库的所有副本上执行来复制元数据。
一个 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} 被展开为来自服务器配置的值，而不是来自数据库引擎参数。但将来，可以使用复制数据库的 shard_name 和 replica_name。
具体事项和建议
带有 Replicated 数据库的 DDL 查询的工作方式与 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 级别上复制，即如果表未被复制，则数据不会被复制（数据库仅负责元数据）。
ALTER TABLE FREEZE|ATTACH|FETCH|DROP|DROP DETACHED|DETACH PARTITION|PART 查询是允许的，但不被复制。数据库引擎将仅添加/提取/移除当前副本的分区/部分。然而，如果表本身使用复制表引擎，则在使用 ATTACH 后数据将被复制。
如果您只需要配置集群而不维护表复制，请参考 Cluster Discovery 特性。
使用示例
创建一个有三个主机的集群：
运行 DDL 查询：
显示系统表：
创建分布式表并插入数据：
在一个主机上添加副本：
集群配置将如下所示：
分布式表也将从新主机获取数据：
