zk目录结构
ClickHouse配置信息
创建基于zk的ClickHouse集群（3zk-2shards-2replicas），主要信息如下：
<?xml version="1.0" encoding="utf-8"?>
<yandex>
<clickhouse_remote_servers>
<default>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>172.17.0.8</host>
<port>9000</port>
</replica>
<replica>
<host>172.17.0.7</host>
<port>9000</port>
</replica>
</shard>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>172.17.0.6</host>
<port>9000</port>
</replica>
<replica>
<host>172.17.0.5</host>
<port>9000</port>
</replica>
</shard>
</default>
</clickhouse_remote_servers>
<zookeeper-servers>
<node index="1">
<host>172.17.0.4</host>
<port>2181</port>
</node>
<node index="2">
<host>172.17.0.3</host>
<port>2181</port>
</node>
<node index="3">
<host>172.17.0.2</host>
<port>2181</port>
</node>
</zookeeper-servers>
<listen_host>::</listen_host>
<listen_host>0.0.0.0</listen_host>
<listen_try>1</listen_try>
<macros>
<shard>1</shard>
<replica>172.17.0.8</replica>
</macros>
</yandex>
其它3个实例的macros会不同
然后创建ReplicatedMergeTree表，Distributed表，再插入5条记录，如下：
CREATE TABLE log_test ON CLUSTER default
(
ts DateTime,
uid String,
biz String
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/log_test','{replica}') PARTITION BY toYYYYMMDD(ts) ORDER BY (ts) SETTINGS index_granularity = 8192;
CREATE TABLE log_test_all ON CLUSTER default(
ts DateTime,
uid String,
biz String
) ENGINE= Distributed(default, default, log_test, rand());
INSERT INTO log_test VALUES ('2019-06-07 20:01:01', 'a', 'show');
INSERT INTO log_test VALUES ('2019-06-07 20:01:02', 'b', 'show');
INSERT INTO log_test VALUES ('2019-06-07 20:01:03', 'a', 'click');
INSERT INTO log_test VALUES ('2019-06-08 20:01:04', 'c', 'show');
INSERT INTO log_test VALUES ('2019-06-08 20:01:05', 'c', 'click');
select * from log_test;
select * from log_test_all;
最终zk的目录结构为
clickhouse
└── tables
├── 1
│ ├── log_test
│ │ ├── metadata #log_test表的元数据信息
│ │ ├── temp #临时节点，存储过程中的临时数据
│ │ └── mutations #表的变更信息，ClickHouse为区别标准SQL特定的一个名词
│ ├── log #写block时记录的log
│ │ ├── log-0000000003
│ │ ├── log-0000000001
│ │ └── log-0000000002
│ ├── leader_election #副本选举leader时使用
│ │ ├── leader_election-0000000001
│ │ └── leader_election-0000000003
│ ├── colums #列信息
│ ├── blocks #和log是对应的，用于block去重
│ │ ├── 201908_12150410223201606212_2366670524718677664
│ │ ├── 201908_15367370223201604745_5325320524718463637
│ │ └── 201907_34543779872932958925_1436457470273464774
│ ├── nonincrement_block_numbers
│ ├── replicas #存储各个副本的相关信息
│ │ └── 10.0.0.71
│ │ ├── is_lost #标记副本是否过时
│ │ ├── metadata #log_test表的元数据信息
│ │ ├── is_active #标记副本是否存活
│ │ ├── mutation_pointer
│ │ ├── colums #列信息
│ │ ├── max_processed_insert_time
│ │ ├── host #主机名或域名
│ │ ├── parts #存储数据所有的parts
│ │ │ └── 201908_0_0_0
│ │ │ ├── checksums
│ │ │ └── colums
│ │ ├── flags #用于数据恢复
│ │ ├── log_pointer #log指针
│ │ ├── min_unprocessed_insert_time
│ │ └── queue #临时处理队列
│ ├── quorum #与是否配置insert_quorum有关
│ │ ├── last_part
│ │ └── failed_parts
│ └── block_number #存储所有的分区值，会根据merge实时更新
│ └── 201908
└─ 2
目录说明
根目录：/clickhouse/tables
下一级时是分片信息目录，其中的1和2是根据配置中的shard生成的
<macros>
<shard>1</shard>
</macros>
分片信息目录中包括所有的表目录，例如：
/clickhouse/tables/1/log_test
/clickhouse/tables/1/log_test2
/clickhouse/tables/1/log_test3
...
以/clickhouse/tables/1/log_test为例，log_test表目录包含以下节点，可以通过zkCli.sh的ls命令查看
[metadata, temp, mutations, log, leader_election, columns, blocks, nonincrement_block_numbers, replicas, quorum, block_numbers]
表目录说明
metadata
存的是log_test表的元数据信息，如下：
metadata format version: 1
date column:
sampling expression:
index granularity: 8192
mode: 0
sign column:
primary key: ts
data format version: 1
partition key: toYYYYMMDD(ts)
granularity bytes: 10485760
temp
临时目录，用于存储ck工作时的一些临时文件的存储，比如mutation过程等
mutations
记录数据的变更，ClickHouse的更新和删除的语法是非标准SQL，新的更新和删除是异步执行的批处理操作，自定义了这样一个名字是为了与传统SQL做区分。
正常情况下这个节点是没有数据的，但如果执行了
ALTER TABLE log_test UPDATE uid='aa' where uid='a';
此时在mutations下会多一个0000000000节点，信息为：
format version: 1
create time: 2020-03-25 07:45:08
source replica: 172.17.0.8
block numbers count: 2
20190607 3
20190608 2
commands: UPDATE uid = \'aa\' WHERE uid = \'a\'
alter version: -1
log
每一个insert语句（严格来说是每一个block）就会生成一个log文件，无论哪个副本写入数据都会产生log，其他副本会watch这个节点去检查自己的数据是否有延迟，如果有会去同分片有该数据的副本中去clone
log-0000000005 中的信息，如下：
format version: 4
create_time: 2020-03-24 15:21:28
source replica: 172.17.0.7
block_id: 20190909_7580776809554376778_6946384220985995348
get
20190909_0_0_0
leader_election
决定哪个副本作为主副本，查询时优先选择该副本，另一个副本根据这个副本同步，在同步过程中还有很多逻辑判断，是否要重新选主，主副本是否是最新的等等，这里不细说。这里包含所有可用的副本
leader_election-0000000003 中的信息，如下：
172.17.0.8
这个值也是根据配置文件生成的
<macros>
<replica>172.17.0.8</replica>
</macros>
leader_election-xxxx是临时节点，如果实例异常，会自动删除，如果实例恢复，会再次写入。如何知道哪个replica是leader可以通过查询system.replicas的is_leader，为1则为leader，为0则不是leader，该表还有个can_become_leader字段标明是否可以成为leader，这个就与副本延迟程度有关了
columns
存储了该表有哪些列，信息如下：
columns format version: 1
3 columns:
`ts` DateTime
`uid` String
`biz` String
blocks
和logs是对应的，log里面包含着block_id，这个id会存一定的数量，作用是为了数据去重，它的格式是patition_hash[0]_hash[1]，就是通过hash值来判断是否重复，如果有重复就不再向zk插入相关数据的元信息
20190608_12150410223201606212_2366670524718677664中的信息是：
20190608_0_0_0
这里就对应着/var/lib/clickhouse/data/default/log_test/20190608_0_0_0这个part
replicas
存储各个副本的相关信息，节点的名称也是根据这个值也是根据配置文件生成的
<macros>
<replica>172.17.0.8</replica>
</macros>
172.17.0.8目录包含
[is_lost, metadata, is_active, mutation_pointer, columns, max_processed_insert_time, host, parts, flags, log_pointer, min_unprocessed_insert_time, queue]
每个节点的作用：
-
is_lost：标记副本是否过时，依据log_pointer是否是最新的，0为正常，-1为过时，1为修复中
-
metadata：元数据信息，同上述的metadata
-
is_active：是否存活，如果服务器异常，会不存在这个节点，恢复后会重新添加进来
-
columns：列信息
-
max_processed_insert_time：最大的insert执行时间
-
host：主机名或域名
-
parts：存储数据的所有parts，每个part中包含checksums和columns信息
-
flags：主要用于强制数据恢复
-
log_pointer：log指针，标记该副本应该处理的log-xxx是哪个
-
min_unprocessed_insert_time：最小的未处理的延时时间
-
queue：插入数据量大时，数据会添加到队列中
quorum
与是否配置insert_quorum 有关
block_numbers
存储所有的分区，会根据merge实时更新
扫一扫
9932
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
