Clickhouse 副本节点之间通过Zookeeper 的log数据和其他控制信息,实现了副本间数据的异步同步。本文中简单介绍插入数据后副本之间同步流程。
【ClickHouse副本机制简介】副本表Zookeeper目录结构
创建副本表,并插入数据,在Zookeeper上可以看到表目录下主要包含下列目录信息,
ReplicatedMergeTree(’/clickhouse/tables/{shard}/tbl_replicated’, ‘{replica}’)
tbl_replicated:
| —— block_numbers
|all
| —— blocks
| —— columns 列信息
| —— leader_election
| —— leader_election-0000000000 主信息,副本节点(multiple leaders ok)
| —— log
| —— log-0000000000 part名称以及相关的块信息,创建时间,source replica, part_type
| —— metadata 元数据信息 (未变化)
| —— mutations 空 (未变化)合并场景,alter table的场景
| —— nonincrement_block_numbers 空 (未变化)
| —— quorum----> 默认情况下,INSERT 语句仅等待一个副本写入成功后返回。
如果数据只成功写入一个副本后该副本所在的服务器不再存在,
则存储的数据会丢失。
要启用数据写入多个副本才确认返回,使用 insert_quorum 选项。
| —— failed_parts
| —— last_part
| —— parallel
| —— replicas
| —— 1 、2
| —— columns 列信息
| —— flags
| —— host 当前副本的主机信息,端口号
| —— is_active 副本节点ClickHouseServer进程PID
| —— is_lost
| —— log_pointer ===》 1
| —— max_processed_insert_time
| —— metadata 元数据信息
| —— metadata_version
| —— min_unprocessed_insert_time
| —— mutation_pointer
| —— parts 副本包含的part 信息
| —— queue 副本节执行操作的队列
同步流程
文章图片
数据插入,流程如下:
- 在其中2副本节点插入数据时,如果数据只存在1个partition的数据,则在该副本节点产生1个part。
- ClickHouse Server从tbl_replicated/block_numbers/all(all是分区名,没有分区的情况下是all) 获取新产生part的下标,该下标是递增的。使用获取的part 下标产生对应的part 名。比如,首次插入数据从tbl_replicated/block_numbers/all获取到的下标是0, 则产生all_0_0_0 的part名。下次插入时,从tbl_replicated/block_numbers/all获取到的下标是1,产生的part 名是all_1_1_0;
- 用这个part 名生成写入磁盘后,在zookeeper副本表目录下产生part 信息node
tbl_replicated/replicas/2/parts/all_0_0_0
[zk: 8.5.131.220:24002(CONNECTED) 11] get /clickhouse/tables/17/tbl_replicated/log/log-0000000000
format version: 4
create_time: 2021-11-20 14:27:00
source replica: 2
block_id: all_3218416765532976388_2128470793510818708
get
all_0_0_0
part_type: Compact
source replica: 2 表明该part 是从副本2产生的
副本同步流程
- 副本节点1 定时读取tbl_replicated/log 目录,读取到新的log后,将log同步到本副本节点的tbl_replicated/replicas/1/queue/queue-00000000000, 然后更本节点的tbl_replicated/replicas/1/log_pointer 值为0,表明本副本已经执行到log-0000000000,后续执行log-0000000001(包含)之后的log
- 内核中副本表的定时任务从tbl_replicated/replicas/1/queue消费节点,读取到log-0000000000的内容时,需要从source replica: 2 拉取part ,副本2对应的主机节点host 从znode 节点/clickhouse/tables/17/tbl_replicated/replicas/2/host获取:
host: 8-5-131-220 port: 21429 tcp_port: 9000 database: db_test table: tbl_replicated scheme: https
拉取到part后,副本1也写入tbl_replicated/replicas/1/parts/all_0_0_0的znode ,表明本副本节点有这个part数据。
在副本消费queue的过程中,并不是严格先入先出的顺序。如果看到log 的类型是merge 而不是get ,则考虑优先去拉取merge后的part 数据,而不是直接拉取原始的part
- log 清除逻辑。当log_xxxxxxx下标已经小于所有有副本的log_pointer ,且log 目录下的数量已经大于指定阈值,则会清除该log节点。
本文由华为云发布
推荐阅读
- 程序员|阿里P7大牛手把手教你!mysql数据库应用案例教程
- 程序员|Java的Io模型你了解多少(dockerbuild指定版本)
- 教你用认知和人性来做最棒的程序员
- 学历|别让学历成为你唯一的优势
- 如何在Spark Scala/Java应用中调用Python脚本
- 内化《高效信息管理术》
- 程序员|python如何生成一系列浮点数(含例子)
- 开发者吐槽(Android开发就像“大便三明治”)
- 软件开发通识之二(如何从零开始学编程)