ClickHouse 高可用之副本

ClickHouse 副本

ClickHouse 通过副本机制,可以将数据拷贝存储在不同的节点上。这样,如果一个节点发生故障,数据仍然可以从其他节点中获取,确保系统的可用性。

支持副本的引擎

在 ClickHouse 中,并不是所有的引擎都支持副本,而副本有专门的引擎,在官网中可以看到:

在这里插入图片描述

其中只有 MergeTree 家族中的引擎支持副本,并且需要在原引擎的基础上,加上副本前缀 Replicated

还需要注意,副本都是表级别的,并不是相对于服务器而言,一般是哪个表需要创建副本,就对哪个表使用副本引擎。

注意,副本只能同步数据,并不能同步表结构,所以我们需要在副本同步时,先创建对应的表。

配置高可用副本

说到高可用,那必然是少不了 Zookeeper,数据协调和存储还得看 Zookeeper。

通过以引擎参数的形式提供 ZooKeeper 集群的名称和路径,ClickHouse 支持将副本的元信息存储在备用 ZooKeeper 集群上。也就是说,支持将不同数据表的元数据存储在不同的 ZooKeeper 集群上。

我这里配置两个副本,也就是说一共在三台机器上部署,一共有三份数据,充分保障 ClickHouse 中数据的安全、稳定性。

Zookeeper 和 ClickHouse 的搭建可以看我写的下面两篇文章:

在部署完 Zookeeper 分布式以及 ClickHouse 单机版(每台机器都要安装)后,就可以进行 ClickHouse 副本的配置了。

修改 ClickHouse 配置文件

在其中添加 Zookeeper 集群的信息,先修改一台机器的配置,然后再进行分发同步。

# 请先切换到 root 账户
su root

# 进入到 ClickHouse 的配置文件目录
cd /etc/clickhouse-server

# 修改配置默认的配置文件
vim config.xml

进入文本编辑器,输入 :/zookeeper 快速定位到:

在这里插入图片描述

填写你的 Zookeeper 信息,如下所示:

在这里插入图片描述

修改完成后,同步该文件到其它两台机器。分发完成后,重启每台机器的 Zookeeper、ClickHouse

副本应用

1.副本表概述

官方给出的副本表创建示例:

在这里插入图片描述

副本表示例 SQL:

CREATE TABLE table_name
(
    EventDate DateTime,
    CounterID UInt32,
    UserID UInt32
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/table_name', '{replica}')
PARTITION BY toYYYYMM(EventDate)
ORDER BY (CounterID, EventDate, intHash32(UserID))
SAMPLE BY intHash32(UserID);

其中副本表引擎在创建时,需要传入两个参数:ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/table_name', '{replica}')

参数说明

  • 参数一:指定在 ZooKeeper 中存储的路径,推荐模板:/clickhouse/tables/{layer}-{shard}/{database}/{table},其中 {layer}-{shard} 表示分片标识信息,大多数情况下,只需要写入一个占位符。

  • 参数二:ZooKeeper 中该表的副本名称,该值必须与其它机器不同!

在创建副本表时,它们可以存储在不同的库中,并不会影响副本的创建,只需要保证它们使用的是同一个 Zookeeper 路径即可。

2.创建副本表

除了副本名称外,其余都需要保持一致。

进入 ClickHouse

# 我没有配置账户与密码
clickhouse-client -m

机器1 中创建。

CREATE TABLE test_rp
(
    EventDate DateTime DEFAULT now(),
    CounterID UInt32,
    UserID UInt32
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/01/test_rp', 'test_rp01')
PARTITION BY toYYYYMM(EventDate)
ORDER BY (EventDate);

机器2 中创建。

CREATE TABLE test_rp
(
    EventDate DateTime DEFAULT now(),
    CounterID UInt32,
    UserID UInt32
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/01/test_rp', 'test_rp02')
PARTITION BY toYYYYMM(EventDate)
ORDER BY (EventDate);

机器3 中创建。

CREATE TABLE test_rp
(
    EventDate DateTime DEFAULT now(),
    CounterID UInt32,
    UserID UInt32
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/01/test_rp', 'test_rp03')
PARTITION BY toYYYYMM(EventDate)
ORDER BY (EventDate);

3.写入模拟数据

机器1 中的表内插入一些模拟数据:

insert into test_rp (CounterID,UserID ) values (1,1001),(2,1002),(3,1003);

4.副本验证

数据插入完成后,分别在 机器1机器2机器3 上查询该表,检查副本是否创建成功。

select * from test_rp;

机器1 查询结果

我们数据是在 机器1 上写入的,所以它肯定有数据。

在这里插入图片描述

机器2 查询结果

副本同步成功。

在这里插入图片描述

机器3 查询结果

副本同步成功。

在这里插入图片描述

各位也可以反过来测试,在其它机器上插入,然后在不同的机器上进行查询,我这里就不再进行演示了。

扩展 —— 在 Zookeeper 中查看副本表信息

如果你想要在 Zookeeper 中查看副本表的目录结构以及存储情况,那么你可以使用 Zookeeper 的可视化工具进行查看。当然,在命令行中查看也是可以的。

这里使用国内个人开发者设计的 PrettyZoo —— 颜值与功能双在线的 Zookeeper 可视化工具

软件下载地址 —— PrettyZoo

解压后即可使用,单机左上角 + 号连接 Zookeeper:

在这里插入图片描述

创建完成后,直接点击 connect 进行连接:

在这里插入图片描述

连接成功后,会自动进入 Zookeeper 目录结构界面:

在这里插入图片描述

查看我们创建的副本表的元数据信息:

在这里插入图片描述

其中存储了副本表的各种元数据信息,大家感兴趣的话就自己下载玩玩吧,这里不过多介绍了。

在这里插入图片描述

### ClickHouse 高可用配置与实现方法 #### 1. 基本概念 ClickHouse 是一种列式数据库管理系统,专为在线分析处理(OLAP)设计。为了确保系统的高可用性和数据冗余,通常采用多节点集群架构来分发查询负载并提供故障转移机制。 #### 2. 多副本表引擎 ReplicatedMergeTree 通过使用 `ReplicatedMergeTree` 表引擎可以创建具有多个副本来存储相同数据集的表格。这允许即使某些服务器发生故障的情况下也能继续访问最新的数据版本[^6]。 ```sql CREATE TABLE replicated_table ON CLUSTER '{cluster}' ( ... ) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{layer}-{shard}/replicated_table', '{replica}') ORDER BY tuple(); ``` 此命令中的路径参数用于指定 ZooKeeper 中保存元数据的位置;而 `{replica}` 则代表当前实例的名字,在不同机器上应该设置成不同的值以便区分各个复制体。 #### 3. 使用 Keeper 或外部协调服务如 Apache Zookeeper 为了管理这些分布式的副本之间的同步状态变化以及自动选举 leader 节点等功能,则需要依赖于额外的服务来进行分布式锁管理和一致性协议的支持。官方推荐的方式之一就是集成 Apache ZooKeeper 来完成这项工作[^7]。 - 安装并启动 ZooKeeper 实例群; - 修改 ClickHouse 的配置文件以指向正确的 ZooKeeper 地址列表; - 创建带有 `Replicated*` 后缀的数据结构时会自动连接到所定义好的 keeper 上面去进行相应的操作。 #### 4. 故障切换策略 当主节点不可用时,客户端应用程序应当能够无缝地重定向请求至其他健康的成员之上。可以通过以下几种方式达成: - **DNS轮询**: 将所有可能成为 master 的 IP 地址都注册在一个域名之下,并让应用层随机挑选其中的一个作为目标地址发起 HTTP 请求。 - **代理中间件**: 构建一层位于前端的应用网关负责转发流量给后端实际工作的 DBMS 进程。这种方式的好处是可以集中控制路由逻辑而不必修改业务代码本身。 - **内置 Load Balancer 插件**: 如果是在云环境中运行的话还可以考虑利用平台自带的功能特性比如 AWS ELB / ALB 等来做动态分配资源的工作[^8]。
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

月亮给我抄代码

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值