ClickHouse 高可用之副本

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
大数据开发治理平台 DataWorks,不限时长
简介: ClickHouse 使用副本机制增强数据可用性,复制数据到多个节点以备故障转移。仅MergeTree系列引擎支持副本,需使用`Replicated`前缀。副本是表级别,需先创建对应表结构。配置高可用副本需借助Zookeeper协调。在三台机器上部署,每台有三份数据。创建副本表时,需指定Zookeeper路径和唯一副本名称。通过`CREATE TABLE`语句在每个节点创建副本表并插入数据,然后验证数据同步。还可以使用工具如PrettyZoo查看Zookeeper中的副本表元数据。

@[toc]

ClickHouse 副本

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

支持副本的引擎

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

image.png

其中只有 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 快速定位到:

image.png

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

image.png

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

副本应用

1.副本表概述

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

image.png

副本表示例 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 上写入的,所以它肯定有数据。

image.png

机器2 查询结果

副本同步成功。

image.png

机器3 查询结果

副本同步成功。

image.png

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

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

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

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

软件下载地址 —— PrettyZoo

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

image.png

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

image.png

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

image.png

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

image.png

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

image.png

相关文章
|
8月前
|
SQL 缓存 大数据
大数据技术之Clickhouse---入门篇---SQL操作、副本
大数据技术之Clickhouse---入门篇---SQL操作、副本
|
9月前
|
存储 Java 数据库
clickhouse集群,双实例多副本集群部署
clickhouse集群,双实例多副本集群部署
|
存储 运维 监控
ByteHouse实践与思考:如何补全ClickHouse高可用短板?
ByteHouse实践与思考:如何补全ClickHouse高可用短板?
|
7天前
|
SQL 人工智能 关系型数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 文档模型中Schema的灵活性
【6月更文挑战第8天】网状模型是层次模型的扩展,允许节点有多重父节点,但导航复杂,需要预知数据库结构。关系模型将数据组织为元组和关系,强调声明式查询,解耦查询语句与执行路径,简化了访问并通过查询优化器提高效率。文档型数据库适合树形结构数据,提供弱模式灵活性,但在Join支持和访问局部性上不如关系型。关系型数据库通过外键和Join处理多对多关系,适合高度关联数据。文档型数据库的模式灵活性体现在schema-on-read,写入时不校验,读取时解析,牺牲性能换取灵活性。适用于不同类型或结构变化的数据场景。
12 0
|
8天前
|
存储 关系型数据库 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多
【6月更文挑战第7天】该文探讨数据模型,比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本(如region_id代替"Greater Seattle Area"),可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中,需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂,若无Join,需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性,层次模型以树形结构限制了多对多关系处理。为克服层次模型局限,发展出了关系模型和网状模型。
17 6
|
9天前
|
SQL JSON NoSQL
【DDIA笔记】【ch2】 数据模型和查询语言 -- 关系模型与文档模型
【6月更文挑战第6天】关系模型是主流数据库模型,以二维表形式展示数据,支持关系算子。分为事务型、分析型和混合型。尽管有其他模型挑战,如网状和层次模型,但关系模型仍占主导。然而,随着大数据增长和NoSQL的出现(如MongoDB、Redis),强调伸缩性、专业化查询和表达力,关系模型的局限性显现。面向对象编程与SQL的不匹配导致“阻抗不匹配”问题,ORM框架缓解但未完全解决。文档模型(如JSON)提供更自然的嵌套结构,适合表示复杂关系,具备模式灵活性和更好的数据局部性。
14 0
|
10天前
|
XML NoSQL 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 概念 + 数据模型
【6月更文挑战第5天】本文探讨了数据模型的分析,关注点包括数据元素、关系及不同类型的模型(关系、文档、图)与Schema模式。查询语言的考量涉及与数据模型的关联及声明式与命令式编程。数据模型从应用开发者到硬件工程师的各抽象层次中起着简化复杂性的关键作用,理想模型应具备简洁直观和可组合性。
13 2
|
11天前
|
敏捷开发 存储 缓存
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可维护性
【6月更文挑战第4天】本文探讨了Twitter面临的一次发推文引发的巨大写入压力问题,指出用户粉丝数分布是决定系统扩展性的关键因素。为解决此问题,Twitter采用混合策略,大部分用户推文扇出至粉丝主页时间线,而少数名人推文则单独处理。性能指标包括吞吐量、响应时间和延迟,其中高百分位响应时间对用户体验至关重要。应对负载的方法分为纵向和横向扩展,以及自动和手动调整。文章强调了可维护性的重要性,包括可操作性、简单性和可演化性,以减轻维护负担和适应变化。此外,良好设计应减少复杂性,提供预测性行为,并支持未来改动。
14 0
|
12天前
|
缓存 关系型数据库 数据库
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- 可扩展性
【6月更文挑战第3天】可扩展性关乎系统应对负载增长的能力,但在产品初期过度设计可能导致失败。理解基本概念以应对可能的负载增长是必要的。衡量负载的关键指标包括日活、请求频率、数据库读写比例等。推特的扩展性挑战在于"扇出",即用户关注网络的广度。两种策略包括拉取(按需查询数据库)和推送(预计算feed流)。推送方法在推特案例中更为有效,因为它减少了高流量时的实时计算压力。
19 0
|
13天前
|
存储 消息中间件 缓存
【DDIA笔记】【ch1】 可靠性、可扩展性和可维护性 -- part1 可靠性
【6月更文挑战第2天】本书探讨现代数据系统,阐述其在信息社会中的关键作用,包括数据库、缓存、搜索引擎、流处理、批处理和消息队列等组成部分。随着技术发展,工具如Kafka、Spark和Redis等多功能组件使得系统设计更为复杂。面对可靠性、可扩展性和可维护性的挑战,书中强调了容错和韧性的重要性,区分了硬件故障、软件错误和人为错误,并提出了应对措施。可靠性关乎用户数据、企业声誉和生存,因此是系统设计的核心考量。
20 0

热门文章

最新文章