ClickHouse副本机制简介

ClickHouse副本机制简介

Clickhouse 副本节点之间通过Zookeeper 的log数据和其他控制信息，实现了副本间数据的异步同步。本文中简单介绍插入数据后副本之间同步流程。

副本表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 副本节执行操作的队列

同步流程

数据插入，流程如下：

1、在其中2副本节点插入数据时，如果数据只存在1个partition的数据，则在该副本节点产生1个part。

2、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;

3、用这个part 名生成写入磁盘后，在zookeeper副本表目录下产生part 信息node

tbl_replicated/replicas/2/parts/all_0_0_0

在tbl_replicated/replicas/2/part/all_0_0_0在tbl_replicated/log目录产生log-0000000000 日志信息:

[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、副本节点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

2、内核中副本表的定时任务从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

3、log 清除逻辑。当log_xxxxxxx下标已经小于所有有副本的log_pointer ，且log 目录下的数量已经大于指定阈值，则会清除该log节点。

EI企业智能 FusionInsight

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。