复制 + 扩展
在这个例子中,您将学习如何设置一个简单的 ClickHouse 集群,该集群既具有复制功能又具备扩展性。它由两个分片和两个副本组成,并使用 3 节点的 ClickHouse Keeper 集群来管理协调及保持集群中的法定人数。
您将要设置的集群架构如下所示:

尽管可以在同一服务器上运行 ClickHouse Server 和 ClickHouse Keeper 的组合,但我们强烈建议在生产环境中为 ClickHouse Keeper 使用 专用 主机,这也是我们将在本示例中演示的方法。
Keeper 服务器可以更小,每个 Keeper 服务器一般需要 4GB 内存,直到您的 ClickHouse 服务器变得庞大。
前提条件
- 您之前已设置过一个 本地 ClickHouse 服务器
- 您熟悉 ClickHouse 的基本配置概念,例如 配置文件
- 您的机器上已安装 docker
设置目录结构和测试环境
以下步骤将指导您从头开始设置集群。如果您希望跳过这些步骤并直接运行集群,可以从 examples repository 获取示例文件。
在本教程中,您将使用 Docker compose 来设置 ClickHouse 集群。该设置可以修改为适应独立的本地机器、虚拟机或云实例。
运行以下命令以设置本示例的目录结构:
将以下 docker-compose.yml
文件添加到 clickhouse-cluster
目录中:
创建以下子目录和文件:
config.d
目录包含 ClickHouse 服务器配置文件config.xml
,在其中定义了每个 ClickHouse 节点的自定义配置。该配置与每个 ClickHouse 安装中自带的默认config.xml
ClickHouse 配置文件相结合。users.d
目录包含用户配置文件users.xml
,在其中定义了用户的自定义配置。该配置与每个 ClickHouse 安装中自带的默认 ClickHouseusers.xml
配置文件相结合。
在编写自己的配置时,最好使用 config.d
和 users.d
目录,而不是直接修改 /etc/clickhouse-server/config.xml
和 etc/clickhouse-server/users.xml
中的默认配置。
这一行
确保了在 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 |
上述配置文件的每个部分将在下面详细解释。
网络与日志记录
外部通信通过激活 listen host 设置来启用网络接口。这确保 ClickHouse 服务器主机可以被其他主机访问:
HTTP API 的端口设置为 8123
:
用于 clickhouse-client 与其他本地 ClickHouse 工具以及 clickhouse-server 与其他 clickhouse-servers 之间通过 ClickHouse 本地协议进行交互的 TCP 端口设置为 9000
:
日志配置在 <logger>
块中定义。此示例配置提供了一个调试日志,日志将在 1000M 时滚动三次:
有关日志配置的更多信息,参见默认 ClickHouse 配置文件 中包含的注释。
集群配置
集群的配置在 <remote_servers>
块中设置。在这里,集群名称 cluster_2S_2R
被定义。
<cluster_2S_2R></cluster_2S_2R>
块定义了集群的布局,使用 <shard></shard>
和 <replica></replica>
设置,并作为分布式 DDL 查询的模板,这些查询在集群内使用 ON CLUSTER
子句执行。默认情况下,允许分布式 DDL 查询,但也可以通过设置 allow_distributed_ddl_queries
关闭。
internal_replication
设置为 true,以便数据仅写入一个副本。
<cluster_2S_2R></cluster_2S_2R>
部分定义了集群的布局,并充当分布式 DDL 查询的模板,这些查询在集群内使用 ON CLUSTER
子句执行。
Keeper 配置
<ZooKeeper>
部分告知 ClickHouse 点击 House Keeper(或 ZooKeeper)在哪里运行。由于我们使用的是 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,因为它提供更好的保障和可靠性,并且比 ZooKeeper 使用更少的资源。为了高可用性并保持法定人数,建议运行至少三个 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 |
每个配置文件将包含以下唯一配置(如下所示)。
用于 ClickHouse Keeper 节点的 server_id
应在集群中唯一,并且与 <raft_configuration>
部分中定义的服务器 <id>
匹配。
tcp_port
是 ClickHouse Keeper 的 客户端 使用的端口。
以下部分用于配置参与 raft 共识算法 的服务器:
ClickHouse Cloud 消除了与管理分片和副本相关的操作负担。该平台自动处理高可用性、复制和扩展决策。 计算和存储是独立的,并根据需求进行扩展,无需手动配置或持续维护。
测试设置
确保您的机器上正在运行 docker。使用 docker-compose up
命令从 cluster_2S_2R
目录的根目录启动集群:
您应该会看到 docker 开始拉取 ClickHouse 和 Keeper 镜像,并随后启动容器:
要验证集群是否正在运行,请连接到任意一个节点并运行以下查询。连接到第一个节点的命令如下所示:
如果成功,您将看到 ClickHouse 客户端提示:
运行以下查询以检查定义了哪些集群拓扑以及对应的主机:
运行以下查询以检查 ClickHouse Keeper 集群的状态:
mntr
命令通常用于验证 ClickHouse Keeper 是否正在运行,并获取有关三个 Keeper 节点关系的状态信息。在本示例中使用的配置中,有三个节点协同工作。节点将选举出一个领导者,其余的节点将作为跟随者。
mntr
命令提供与性能相关的信息,以及某个特定节点是跟随者还是领导者。
您可能需要安装 netcat
以便将 mntr
命令发送到 Keeper。请参见 nmap.org 页面以获取下载信息。
在 clickhouse-keeper-01
、clickhouse-keeper-02
和 clickhouse-keeper-03
上从 shell 运行以下命令,以检查每个 Keeper 节点的状态。clickhouse-keeper-01
的命令如下所示:
下面的响应显示了来自跟随者节点的示例响应:
下面的响应显示了来自领导者节点的示例响应:
通过这些步骤,您成功设置了一个具有两个分片和两个副本的 ClickHouse 集群。在下一步中,您将创建一个集群中的表。
创建数据库
现在您已经验证集群正确设置并正在运行,您将重新创建与 英国房地产价格 示例数据集教程中使用的表相同的表。它由大约 3000 万行自 1995 年以来在英格兰和威尔士支付的房地产价格组成。
通过分别在不同的终端标签或窗口中运行以下每个命令,连接到每个主机的客户端:
您可以从每个主机的 clickhouse-client 运行如下查询,以确认除了默认的数据库外,尚未创建任何数据库:
从 clickhouse-01
客户端运行以下 分布式 DDL 查询,使用 ON CLUSTER
子句创建一个名为 uk
的新数据库:
您可以再次从每个主机的客户端运行相同的查询,以确认尽管只从 clickhouse-01
运行查询,但数据库已经跨集群创建:
在集群上创建分布式表
数据库创建完成后,接下来您将创建一个分布式表。分布式表是可以访问位于不同主机的分片的表,使用 Distributed
表引擎进行定义。分布式表充当集群中所有分片的接口。
从任一主机客户端运行以下查询:
请注意,它与原始 CREATE
语句中使用的查询完全相同,正如 英国房地产价格 示例数据集教程中所示,只是增加了 ON CLUSTER
子句和使用了 ReplicatedMergeTree
引擎。
ON CLUSTER
子句旨在用于分布式执行 DDL(数据定义语言)查询,例如 CREATE
、DROP
、ALTER
和 RENAME
,确保这些模式更改会在集群中的所有节点上应用。
ReplicatedMergeTree
引擎的工作方式与普通的 MergeTree
表引擎相同,但它还会复制数据。它需要指定两个参数:
zoo_path
:表的元数据在 Keeper/ZooKeeper 中的路径。replica_name
:表的副本名称。
zoo_path
参数可以设置为您选择的任何内容,尽管建议按照以下约定使用前缀
其中:
{database}
和{table}
将被自动替换。{shard}
和{replica}
是在之前的config.xml
文件中定义的宏 定义。
您可以从每个主机客户端运行下面的查询,以确认表已在集群中创建:
向分布式表插入数据
要向分布式表插入数据,不能使用 ON CLUSTER
,因为它不适用于 DML(数据操作语言)查询,例如 INSERT
、UPDATE
和 DELETE
。要插入数据,必须使用 Distributed
表引擎。
从任何主机客户端运行以下查询,以使用之前创建的表创建分布式表,且使用 ON CLUSTER
和 ReplicatedMergeTree
的方式:
在每个主机上,您现在将看到 uk
数据库中的以下表:
数据可以使用以下查询从任何主机客户端插入到 uk_price_paid_distributed
表中:
运行以下查询以确认插入的数据已均匀分布在我们集群的节点之间: