[experimental] Replicated
该引擎基于Atomic引擎。它支持通过将DDL日志写入ZooKeeper并在给定数据库的所有副本上执行的元数据复制。
一个ClickHouse服务器可以同时运行和更新多个复制的数据库。但是同一个复制的数据库不能有多个副本。
创建数据库
CREATE DATABASE testdb ENGINE = Replicated('zoo_path', 'shard_name', 'replica_name') [SETTINGS ...]
引擎参数
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
。
使用方式
使用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 ATTACH|FETCH|DROP|DROP DETACHED|DETACH PARTITION|PART