Clickhouse集群应用、分片、复制_可爱马莲花的博客-CSDN博客
Clickhouse集群应用、分片、复制
可爱马莲花
于 2018-11-30 19:03:27 发布
3324
收藏
14
分类专栏：
clickhouse
文章标签：
clickhouse
clickhouse
专栏收录该内容
1 篇文章
0 订阅
订阅专栏
通常生产环境我们会用集群代替单机，主要是解决两个问题：
效率稳定
如何提升效率？一个大大大任务，让一个人干需要一年，拆解一下让12个人同时干，可能只需要1个月。对于数据库来说，就是数据分片。
如何提升稳定性？所谓稳定就是要保证服务时刻都能用，也常说高可用。这就像团队里必须有二把手，老大有事不在，老二要能顶上。对于数据库来说，就是数据备份。
而集群是解决这两个问题的最佳手段。话说，三个臭皮匠，赛过诸葛亮，这就是团队的力量。
几乎所有大数据相关的产品，基本都是以这两个问题为出发点，Clickhouse也不例外。
不同的是，Hadoop系列的集群是服务级别的，而Clickhouse的集群是表上的。例如，一个hdfs集群，所有文件都会切片、备份；而clickhouse集群中，建表时也可以自己决定用不用。习惯了其他大数据产品的人，刚转到clickhouse会感觉这设计太反人类，后文会详细介绍。
安装
我们使用三台机器演示，三个机器分别安装clickhouse 教程：https://www.jianshu.com/p/5f5ee0904bba
数据
实验使用到官方提供的OnTime数据集，先下载下来，并按照文档建表。
教程： https://clickhouse.yandex/docs/en/single/?query=internal_replication#ontime
数据分片
这里再说明一下，分片是为了提高效率。
分片，就像是把鸡蛋放到多个篮子里，降低整体风险，结果可能是部分数据不可用，虽然一定程度上起到了「高可用」的作用，但分片的目的是为了提速。况且，比较严格的场景下，部分不可用也是不可用。
clickhouse需要自己动手定义分片。
vim /etc/clickhouse-server/config.xml
编辑config.xml文件，搜索remote_servers：
<remote_servers incl="clickhouse_remote_servers" >
...
</remote_servers>
说明：remote_servers就是集群配置，可以直接在此处配置，也可以提出来配置到扩展文件中。incl属性表示可从外部文件中获取节点名为clickhouse_remote_servers的配置内容。
我们使用扩展文件，首先，添加外部扩展配置文件：
<include_from>/etc/clickhouse-server/metrika.xml</include_from>
然后，编辑配置文件：
vim /etc/clickhouse-server/metrika.xml
添加内容：
<yandex>
<!-- 集群配置 -->
<clickhouse_remote_servers>
<!-- 3分片1备份 -->
<cluster_3shards_1replicas>
<!-- 数据分片1 -->
<shard>
<replica>
<host>hadoop1</host>
<port>9000</port>
</replica>
</shard>
<!-- 数据分片2 -->
<shard>
<replica>
<host>hadoop2</host>
<port> 9000</port>
</replica>
</shard>
<!-- 数据分片3 -->
<shard>
<replica>
<host>hadoop3</host>
<port>9000</port>
</replica>
</shard>
</cluster_3shards_1replicas>
</clickhouse_remote_servers>
</yandex>
说明：
clickhouse_remote_servers与config.xml中的incl属性值对应；cluster_3shards_1replicas是集群名，可以随便取名；共设置3个分片，每个分片只有1个副本；
在其他两台机器上同样操作。
打开clickhouse-client，查看集群：
hadoop1 :) select * from system.clusters;
SELECT *
FROM system.clusters
┌─cluster───────────────────┬─shard_num─┬─shard_weight─┬─replica_num─┬─host_name─┬─host_address─┬─port─┬─is_local─┬─user────┬─default_database─┐
│ cluster_3shards_1replicas │ 1 │ 1 │ 1 │ hadoop1 │ 192.168.0.6 │ 9000 │ 1 │ default │ │
│ cluster_3shards_1replicas │ 2 │ 1 │ 1 │ hadoop2 │ 192.168.0.16 │ 9000 │ 0 │ default │ │
│ cluster_3shards_1replicas │ 3 │ 1 │ 1 │ hadoop3 │ 192.168.0.11 │ 9000 │ 0 │ default │ │
└───────────────────────────┴───────────┴──────────────┴─────────────┴───────────┴──────────────┴──────┴──────────┴─────────┴──────────────────┘
3 rows in set. Elapsed: 0.003 sec.
可以看到cluster_3shards_1replicas就是我们定义的集群名称，一共有三个分片，每个分片有一份数据。
建数据表
在三个节点上分别建表：ontime_local
CREATE TABLE `ontime_local` (
`Year` UInt16,
`Quarter` UInt8,
`Month` UInt8,
`DayofMonth` UInt8,
`DayOfWeek` UInt8,
`FlightDate` Date,
`UniqueCarrier` FixedString(7),
`AirlineID` Int32,
`Carrier` FixedString(2),
`TailNum` String,
`FlightNum` String,
`OriginAirportID` Int32,
`OriginAirportSeqID` Int32,
`OriginCityMarketID` Int32,
`Origin` FixedString(5),
`OriginCityName` String,
`OriginState` FixedString(2),
`OriginStateFips` String,
`OriginStateName` String,
`OriginWac` Int32,
`DestAirportID` Int32,
`DestAirportSeqID` Int32,
`DestCityMarketID` Int32,
`Dest` FixedString(5),
`DestCityName` String,
`DestState` FixedString(2),
`DestStateFips` String,
`DestStateName` String,
`DestWac` Int32,
`CRSDepTime` Int32,
`DepTime` Int32,
`DepDelay` Int32,
`DepDelayMinutes` Int32,
`DepDel15` Int32,
`DepartureDelayGroups` String,
`DepTimeBlk` String,
`TaxiOut` Int32,
`WheelsOff` Int32,
`WheelsOn` Int32,
`TaxiIn` Int32,
`CRSArrTime` Int32,
`ArrTime` Int32,
`ArrDelay` Int32,
`ArrDelayMinutes` Int32,
`ArrDel15` Int32,
`ArrivalDelayGroups` Int32,
`ArrTimeBlk` String,
`Cancelled` UInt8,
`CancellationCode` FixedString(1),
`Diverted` UInt8,
`CRSElapsedTime` Int32,
`ActualElapsedTime` Int32,
`AirTime` Int32,
`Flights` Int32,
`Distance` Int32,
`DistanceGroup` UInt8,
`CarrierDelay` Int32,
`WeatherDelay` Int32,
`NASDelay` Int32,
`SecurityDelay` Int32,
`LateAircraftDelay` Int32,
`FirstDepTime` String,
`TotalAddGTime` String,
`LongestAddGTime` String,
`DivAirportLandings` String,
`DivReachedDest` String,
`DivActualElapsedTime` String,
`DivArrDelay` String,
`DivDistance` String,
`Div1Airport` String,
`Div1AirportID` Int32,
`Div1AirportSeqID` Int32,
`Div1WheelsOn` String,
`Div1TotalGTime` String,
`Div1LongestGTime` String,
`Div1WheelsOff` String,
`Div1TailNum` String,
`Div2Airport` String,
`Div2AirportID` Int32,
`Div2AirportSeqID` Int32,
`Div2WheelsOn` String,
`Div2TotalGTime` String,
`Div2LongestGTime` String,
`Div2WheelsOff` String,
`Div2TailNum` String,
`Div3Airport` String,
`Div3AirportID` Int32,
`Div3AirportSeqID` Int32,
`Div3WheelsOn` String,
`Div3TotalGTime` String,
`Div3LongestGTime` String,
`Div3WheelsOff` String,
`Div3TailNum` String,
`Div4Airport` String,
`Div4AirportID` Int32,
`Div4AirportSeqID` Int32,
`Div4WheelsOn` String,
`Div4TotalGTime` String,
`Div4LongestGTime` String,
`Div4WheelsOff` String,
`Div4TailNum` String,
`Div5Airport` String,
`Div5AirportID` Int32,
`Div5AirportSeqID` Int32,
`Div5WheelsOn` String,
`Div5TotalGTime` String,
`Div5LongestGTime` String,
`Div5WheelsOff` String,
`Div5TailNum` String
) ENGINE = MergeTree(FlightDate, (Year, FlightDate), 8192)
表结构与ontime完全一样。
建分布表
CREATE TABLE ontime_all AS ontime_local
ENGINE = Distributed(cluster_3shards_1replicas, default, ontime_local, rand())
分布表（Distributed）本身不存储数据，相当于路由，需要指定集群名、数据库名、数据表名、分片KEY，这里分片用rand()函数，表示随机分片。查询分布表，会根据集群配置信息，路由到具体的数据表，再把结果进行合并。
ontime_all与ontime在同一个节点上，方便插入数据。
插入数据
INSERT INTO ontime_all SELECT * FROM ontime;
把ontime的数据插入到ontime_all，ontime_all会随机插入到三个节点的ontime_local里。
表ontime需要提前建好，并导入数据。
导入完成后，查看总数据量：
hadoop1 :) select count(1) from ontime_all;
SELECT count(1)
FROM ontime_all
┌──count(1)─┐
│ 177920306 │
└───────────┘
再看下每个节点的数据：
hadoop1 :) select count(1) from ontime_local;
SELECT count(1)
FROM ontime_local
┌─count(1)─┐
│ 59314494 │
└──────────┘
可以看到，每个节点大概有1/3的数据。
性能对比
对比一下分片与不分片的性能差异。
不分片：
hadoop1 :) select Carrier, count() as c, round(quantileTDigest(0.99)(DepDelay), 2) as q from ontime group by Carrier order by q desc limit 5;
SELECT
Carrier,
count() AS c,
round(quantileTDigest(0.99)(DepDelay), 2) AS q
FROM ontime
GROUP BY Carrier
ORDER BY q DESC
LIMIT 5
┌─Carrier─┬───────c─┬──────q─┐
│ B6 │ 2991782 │ 191.22 │
│ NK │ 412396 │ 190.97 │
│ EV │ 6222018 │ 187.17 │
│ XE │ 2145095 │ 179.55 │
│ VX │ 371390 │ 178.3 │
└─────────┴─────────┴────────┘
5 rows in set. Elapsed: 1.951 sec. Processed 177.92 million rows, 1.07 GB (91.18 million rows/s., 547.11 MB/s.)
用时1.951秒。
分片：
hadoop1 :) select Carrier, count() as c, round(quantileTDigest(0.99)(DepDelay), 2) as q from ontime_all group by Carrier order by q desc limit 5;
SELECT
Carrier,
count() AS c,
round(quantileTDigest(0.99)(DepDelay), 2) AS q
FROM ontime_all
GROUP BY Carrier
ORDER BY q DESC
LIMIT 5
┌─Carrier─┬───────c─┬──────q─┐
│ B6 │ 2991782 │ 191.2 │
│ NK │ 412396 │ 191.06 │
│ EV │ 6222018 │ 187.22 │
│ XE │ 2145095 │ 179.42 │
│ VX │ 371390 │ 178.33 │
└─────────┴─────────┴────────┘
5 rows in set. Elapsed: 0.960 sec. Processed 177.92 million rows, 1.07 GB (185.37 million rows/s., 1.11 GB/s.)
用时0.96秒，速度大约提升2倍。
现在，停掉一个节点，会是神马情况？
Received exception from server (version 18.10.3):
Code: 279. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::NetException. DB::NetException: All connection tries failed. Log:
Code: 32, e.displayText() = DB::Exception: Attempt to read after eof, e.what() = DB::Exception
Code: 210, e.displayText() = DB::NetException: Connection refused: (hadoop2:9000, 192.168.0.16), e.what() = DB::NetException
Code: 210, e.displayText() = DB::NetException: Connection refused: (hadoop2:9000, 192.168.0.16), e.what() = DB::NetException
报错了，看来clickhouse的处理很严格，如果一个分片不可用，就整个分布式表都不可用了。
当然，此时如果查本地表ontime_local还是可以的。
那么，如何解决整个问题呢？这就是前文所说的稳定性问题了，解决方案是：数据备份！
数据备份
说明一点，数据备份与分片没有必然联系，这是两个方面的问题。但在clickhouse中，replica是挂在shard上的，因此要用多副本，必须先定义shard。
最简单的情况：1个分片多个副本。
添加集群
像之前一样，再配置一个集群，叫做cluster_1shards_2replicas，表示1分片2副本，配置信息如下：
<yandex>
<!-- 1分片2备份 -->
<cluster_1shards_2replicas>
<shard>
<internal_replication>false</internal_replication>
<replica>
<host>hadoop1</host>
<port>9000</port>
</replica>
<replica>
<host>hadoop2</host>
<port>9000</port>
</replica>
</shard>
</cluster_1shards_2replicas>
</yandex>
注意，如果配置文件没有问题，是不用重启clickhouse-server的，会自动加载！
建数据表
CREATE TABLE `ontime_local_2` (
...
) ENGINE = MergeTree(FlightDate, (Year, FlightDate), 8192)
表名为ontime_local_2，在三台机器分别执行。
建分布表
CREATE TABLE ontime_all_2 AS ontime_local_2
ENGINE = Distributed(cluster_1shards_2replicas, default, ontime_local_2, rand())
表名是ontime_all_2，使用cluster_1shards_2replicas集群，数据为ontime_local_2。
导入数据
INSERT INTO ontime_all_2 SELECT * FROM ontime
查询
hadoop1 :) select count(1) from ontime_all_2;
SELECT count(1)
FROM ontime_all_2
┌──count(1)─┐
│ 177920306 │
└───────────┘
查询ontime_local_2，两个节点都有全量数据。
关掉一个服务器，仍能查询全量数据，数据副本已经生效。
一致性
既然有多副本，就有个一致性的问题：加入写入数据时，挂掉一台机器，会怎样？
我们来模拟一下：
停掉hadoop2服务
service clickhouse-server stop
通过ontime_all_2插入几条数据
hadoop1 :) insert into ontime_all_2 select * from ontime limit 10;
启动hadoop2服务
service clickhouse-server start
查询验证 查看两个机器的ontime_local_2、以及ontime_all_2，发现都是总数据量都增加了10条，说明这种情况下，集群节点之间能够自动同步
再模拟一个复杂点的：
停掉hadoop2；通过ontime_all_2插入10条数据；查询ontime_all_2，此时数据增加了10条；停掉hadoop1；启动hadoop2，此时，整个集群不可用；查询ontime_all_2，此时，集群恢复可用，但数据少了10条；启动hadoop1，查询ontime_all_2、ontime_local_2，数据自动同步；
上边都是通过ontime_all_2表插入数据的，如果通过ontime_local_2表插入数据，还能同步吗？
hadoop1上往ontime_local_2插入10条数据；查询hadoop2，ontime_local_2数据没有同步
综上，通过分布表写入数据，会自动同步数据；而通过数据表写入数据，不会同步；正常情况没什么大问题。
更复杂的情况没有模拟出来，但是可能会存在数据不一致的问题，官方文档描述如下：
Each shard can have the 'internal_replication' parameter defined in the config file.
If this parameter is set to 'true', the write operation selects the first healthy replica and writes data to it. Use this alternative if the Distributed table "looks at" replicated tables. In other words, if the table where data will be written is going to replicate them itself.
If it is set to 'false' (the default), data is written to all replicas. In essence, this means that the Distributed table replicates data itself. This is worse than using replicated tables, because the consistency of replicas is not checked, and over time they will contain slightly different data.
翻译下：
分片可以设置internal_replication属性，这个属性是true或者false，默认是false。
如果设置为true，则往本地表写入数据时，总是写入到完整健康的副本里，然后由表自身完成复制，这就要求本地表是能自我复制的。
如果设置为false，则写入数据时，是写入到所有副本中。这时，是无法保证一致性的。
举个栗子，一条数据要insert到ontime_all_2中，假设经过rand()实际是要写入到hadoop1的ontime_local表中，此时ontime_local配置了两个副本。 如果internal_replication是false，那么就会分别往两个副本中插入这条数据。注意！！！分别插入，可能一个成功，一个失败，插入结果不检验！这就导致了不一致性； 而如果internal_replication是true，则只往1个副本里写数据，其他副本则是由ontime_local自己进行同步，这样就解决了写入一致性问题。
虽然没有模拟出数据不一致的情况，实际中可能会遇到，所以官方建议使用表自动同步的方式，也就是internal_replication为true。
具体怎么用，下边具体介绍。
自动数据备份
自动数据备份，是表的行为，ReplicatedXXX的表支持自动同步。
Replicated前缀只用于MergeTree系列（MergeTree是最常用的引擎），即clickhouse支持以下几种自动备份的引擎：
ReplicatedMergeTree ReplicatedSummingMergeTree ReplicatedReplacingMergeTree ReplicatedAggregatingMergeTree ReplicatedCollapsingMergeTree ReplicatedGraphiteMergeTree
再强调一遍，Replicated表自动同步与之前的集群自动同步不同，是表的行为，与clickhouse_remote_servers配置没有关系，只要有zookeeper配置就行了。
为了说明这个问题，先不配置clickhouse_remote_servers，只添加zookeeper配置：
<yandex>
...
<zookeeper-servers>
<node index="1">
<host>hadoop1</host>
<port>2181</port>
</node>
<node index="2">
<host>hadoop2</host>
<port>2181</port>
</node>
<node index="3">
<host>hadoop3</host>
<port>2181</port>
</node>
</zookeeper-servers>
...
</yandex>
建数据表
hadoop1:
CREATE TABLE `ontime_replica` (
...
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/ontime', 'replica1', FlightDate, (Year, FlightDate), 8192);
hadoop2:
CREATE TABLE `ontime_replica` (
...
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/ontime', 'replica2', FlightDate, (Year, FlightDate), 8192);
hadoop3:
CREATE TABLE `ontime_replica` (
...
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/ontime', 'replica3', FlightDate, (Year, FlightDate), 8192);
查看zk信息：
[zk: localhost:2181(CONNECTED) 0] ls /clickhouse/tables/ontime/replicas
[replica2, replica3, replica1]
可以看到，zk中已经有了对应的路径和副本信息。
插入数据
hadoop1:
INSERT INTO ontime_replica SELECT * FROM ontime
注意！只在一个机器上执行插入操作。
查看数据
分别在三个机器上查询ontime_replica，都有数据，且数据完全一样。
可以看到，这种方式与之前方式的区别，直接写入一个节点，其他节点自动同步，完全是表的行为；而之前的方式必须创建Distributed表，并通过Distributed表写入数据才能同步（目前我们还没有给ontime_replica创建对应的Distributed表）。
配置集群
...
<!-- 1分片3备份：使用表备份-->
<cluster_1shards_3replicas>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>hadoop1</host>
<port>9000</port>
</replica>
<replica>
<host>hadoop2</host>
<port>9000</port>
</replica>
<replica>
<host>hadoop3</host>
<port>9000</port>
</replica>
</shard>
</cluster_1shards_3replicas>
...
集群名字为cluster_1shards_3replicas，1个分片，3个副本；与之前不同，这次设置internal_replication为true，表示要用表自我复制功能，而不用集群的复制功能。
建分布表
CREATE TABLE ontime_replica_all AS ontime_replica
ENGINE = Distributed(cluster_1shards_3replicas, default, ontime_replica, rand())
表名为ontime_replica_all，使用cluster_1shards_3replicas集群，数据表为ontime_replica。
查询分布表：
hadoop1 :) select count(1) from ontime_replica_all;
SELECT count(1)
FROM ontime_replica_all
┌──count(1)─┐
│ 177920306 │
└───────────┘
分布表写入
前边说了，一个节点ontime_replica写入数据时，其他节点自动同步；那如果通过分布表ontime_replica_all写入数据会如何呢？
其实，前文已经提到过，internal_replication为true，则通过分布表写入数据时，会自动找到“最健康”的副本写入，然后其他副本通过表自身的复制功能同步数据，最终达到数据一致。
分片 + 备份
分片，是为了突破单机上限（存储、计算等上限），备份是为了高可用。
只分片，提升了性能，但是一个分片挂掉，整个服务不可用；只备份，确实高可用了，但是整体还是受限于单机瓶颈（备份1000份与备份2份没什么区别，除了更浪费机器）。
所以，生产中这两方面需要同时满足。
其实，只要把之前的分片和备份整合起来就行了，例如，3分片2备份的配置如下：
...
<!-- 3分片2备份：使用表备份 -->
<cluster_3shards_2replicas>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>hadoop1</host>
<port>9000</port>
</replica>
<replica>
<host>hadoop2</host>
<port>9000</port>
</replica>
</shard>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>hadoop3</host>
<port>9000</port>
</replica>
<replica>
<host>hadoop4</host>
<port>9000</port>
</replica>
</shard>
<shard>
<internal_replication>true</internal_replication>
<replica>
<host>hadoop5</host>
<port>9000</port>
</replica>
<replica>
<host>hadoop6</host>
<port>9000</port>
</replica>
</shard>
</cluster_3shards_2replicas>
...
这里一共需要建6个数据表：
CREATE TABLE `ontime_replica` (
...
) ENGINE = ReplicatedMergeTree('/clickhouse/tables/ontime/{shard}', '{replica}', FlightDate, (Year, FlightDate), 8192);
其中，{shard}和{replica}是macros配置（相当于环境变量），修改配置文件：
vi /etc/clickhose-server/metrika.xml
添加内容：
...
<macros>
<shard>01</shard>
<replica>01</replica>
</macros>
...
每台机器的shard和replica值根据具体情况设置，例如，这里是3分片2副本，则配置如下：
hadoop1: shard=01, replica=01
hadoop2: shard=01, replica=02
hadoop3: shard=02, replica=01
hadoop4: shard=02, replica=02
hadoop5: shard=03, replica=01
hadoop6: shard=03, replica=02
使用macros只是为了建表方便（每个机器可以使用同样的建表语句），不是必须的，只要ReplicatedMergeTree指定zk路径和replica值即可。
由于资源有限，这里不实验了。
需要提醒一下，每个clickhouse-server实例只能放一个分片的一个备份，也就是3分片2备份需要6台机器（6个不同的clickhouse-server）。
之前为了节省资源，打算循环使用，把shard1的两个副本放到hadoop1、hadoop2两个机器上，shard2的两个副本放到hadoop2、hadoop3上，shard3的两个副本放到hadoop3、hadoop1上，结果是不行的。
原因是shard+replica对应一个数据表，Distributed查询规则是每个shard里找一个replica，把结果合并。
假如按照以上设置，可能一个查询解析结果为： 取shard1的replica1，对应hadoop1的ontime_replica； 取shard2的replica2，对应hadoop3的ontime_replica； 取shard3的replica2，对应hadoop1的ontime_replica；
最后，得到的结果是hadoop1的ontime_replica查询两次+hadoop3的ontime_replica查询一次，结果是不正确的。
由于之前用elasticsearch集群，可以用3台服务器来创建5分片2备份的索引，所以想当然的认为clickhouse也可以，结果坑了两天。
作者：小琪的大爷 链接：https://www.jianshu.com/p/20639fdfdc99 來源：简书 简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
可爱马莲花
关注
关注
点赞
14
收藏
评论
Clickhouse集群应用、分片、复制
通常生产环境我们会用集群代替单机，主要是解决两个问题：效率稳定如何提升效率？一个大大大任务，让一个人干需要一年，拆解一下让12个人同时干，可能只需要1个月。对于数据库来说，就是数据分片。如何提升稳定性？所谓稳定就是要保证服务时刻都能用，也常说高可用。这就像团队里必须有二把手，老大有事不在，老二要能顶上。对于数据库来说，就是数据备份。而集群是解决这两个问题的最佳手段。话说，三个臭皮...
复制链接
扫一扫
专栏目录
「ClickHouse系列」Replication机制详解
微信搜：import_bigdata，大数据领域硬核原创作者
03-10
421
点击上方蓝色字体，选择“设为星标”回复"面试"获取更多惊喜八股文交给我，你们专心刷题和面试Hi，我是王知无，一个大数据领域的原创作者。放心关注我，获取更多行业的一手消息。在阅读本文之前你...
【ClickHouse源码】ReplicatedMergeTree之数据同步流程
一只努力的微服务
04-03
2593
ReplicatedMergeTree之数据同步流程
在创建了ReplicatedMergeTree后，会有几个taskHolder在后台去监听zk的log并向queue添加，监听mutations的变化并触发mutation相关操作。这里先不对mutation相关操作做分析，主要先说明一下正常的数据插入和正常的数据复制流程。
首先了解一个taskHolder
queue_task_handle：...
评论 1
您还未登录，请先
登录
后发表或查看评论
ClickHouse教程 — 第一章 ClickHouse单机版安装
最新发布
Mr_XiMu的博客
11-22
346
ClickHouse单机版安装使用
ClickHouse-ReplicatedMergeTree主备同步
qq_42016966的博客
10-17
5255
了解到，分布式DDL功能对Zookeeper的依赖情况还是比较轻量级的，接下来介绍的ReplicatedMergeTree表引擎对Zookeeper的依赖可以说是所有表操作全方面的依赖，真实集群中大量的ReplicatedMergeTree表会对Zookeeper造成非常大的请求压力，需要用户关注Zookeeper的运维。
ReplicatedMergeTree表引擎实现的主备同步和传统主备同步有很大的差异：1）它不是一个（抢主，主节点执写入更新，备节点同步follow）的模型，ClickHouse的主节
【clickhouse】clickhouse 副本与分片 分片详解
九师兄
02-07
3703
1.概述
转载：【clickhouse】clickhouse 副本与分片 分片详解
clickhouse 中每个服务器节点都可以被称为一个 shard（分片）。 假设有 N 台服务器，每个服务器上都有一张数据表 A，且每个服务器上的 数据表 A 的数据不重复，那么就可以说数据表 A 拥有 N 的分片。
对于一个完整的方案来说，还要考虑在数据写入时如何被均匀低写到各个分片中，以及数据在查询时如何路由到每个分片，组合成结果集。
clickhouse 的数据分片需要结合 DIstributed 表引擎一起使用。.
ClickHouse集群搭建（二）
郑龙飞
11-30
589
重叠泪痕缄锦字，人生只有情难死。
分布式集群安装
在上一章我们已经完成ClickHouse分布式集群安装，也创建本地表和分布式表进行了测试，但是，假如停掉一个节点会发生神马情况？
node03上kill掉clickhouse-server进程
[root@node03 ~]# ps -ef | grep clickhouse
clickho+ 2233 1 73 13:07 ? 00:00:02 clickhouse-server --daemon --pid-file=/va.
clickhouse的报错集合(以错误状态码收集)
qq_44833146的博客
11-30
5280
错误码目录项目场景(错误码:210, 279)：备用项目场景：
项目场景(错误码:210, 279)：
在使用Distributed的分布引擎时出现的报错
问题描述：
先在3台节点上都创建t表,
再在102上使用分布引擎创建表,合并这些表格,
结果出现的错误是:
↘ Progress: 0.00 rows, 0.00 B (0.00 rows/s., 0.00 B/s.) Received exception from server (version 19.7.3):
Code: 279. DB::E
「分布式技术专题」数据分布（数据复制、数据分片及优劣势）
qq_39918081的博客
03-02
428
数据复制
对于那些需要在多个场地上对数据进行更新的应用来说，自动快照的功能就显得很不够了。这些应用要求同一个表的多份拷贝在多个场上进行维护。把数据复制到远程节点，使数据更容易被系统中的较远的用户访问，从而境加了系统的本地自治度。分布式数据库必须解决一个重要问题是，保持所有拷贝的同步更新。
当同一表的多个拷贝存在时，访问这些分布数据的用户应该不会察觉这些副本的位置。否则，用户必须依靠系统当前的位置和当前维护的副本的编号进行修改。
复制、数据一致性和位位置透明性都是分布式数据库复制数据时要完成的功能。这些功能在
clickhouse连接问题解决：Code: 210. DB::NetException: I/O error: Broken pipe, while writing to socket
MDJ_D2T的博客
03-13
2214
文章目录
#一、问题现象
clickhouse-client可以正常连接登录，但是执行语句就会报错；
报错如下：
10.58.11.10 :) show tables ;
SHOW TABLES
Exception on client:
Code: 210. DB::NetException: I/O error: Broken pipe, while writing to socket (10.58.11.10:9000)
Connecting to 10.58.11.10
ClickHouse复制表、分布式表机制与使用方法
LittleMagic's Blog
04-29
9234
Replication & Sharding
在ClickHouse文集的第一篇文章中，笔者介绍了ClickHouse高可用集群的配置方法，并且提到：分布式存储要保证高可用，就必须有数据冗余——即副本（replica）。ClickHouse依靠ReplicatedMergeTree引擎族与ZooKeeper实现了复制表机制，成为其高可用的基础。
另外，笔者也提到，ClickHouse像El...
使用spark将数据写入到clickhouse报Broken pipe错误
anyitian的博客
04-06
1744
文章目录前言解决办法
前言
最近在使用spark将数据写入clickhouse中，中间也遇到了一些问题，报错如下：
[ERROR 2019-08-15 11:19:12 (com.ly.data.ysck.tool.CKTool:47)] 插入异常
ru.yandex.clickhouse.except.ClickHouseUnknownException: ClickHouse exception, code: 1002, host: 172.20.89.26, port: 17133; Broken p
IOError: [Errno 32] Broken pipe 解决方案
qq_29015763的博客
09-17
4588
在stack overflow上看到的解决方案，实测可行：
from functools import wraps
from sys import exit, stderr, stdout
from traceback import print_exc
def suppress_broken_pipe_msg(f):
@wraps(f)
def wrapper(*args, **kwargs):
...
clickhouse高可用-节点宕机数据一致性方案-热扩容
zzy7075的专栏
05-17
1022
1. 集群节点及服务分配
说明：
1.1. 在每个节点上启动两个clickhouse服务(后面会详细介绍如何操作这一步)，一个数据分片，一个数据备份，为了确保宕机数据一致性，数据分片和数据备份不能同一节点，比如gawh201上的shard不能备份在gawh201的replica，如果这样做，当gawh201宕机了，该节点shard的数据是找不到的。
1.2. 基于a所以shard和replica必须错开，但不是随意错开就可以了。按照上图给的规律错开(后面会详细介绍超大节点的集群的shard和re.
ck(二) ck集群注意及常规操作
赵俊杰
01-20
1584
一、当设置了副本无效时记得检查以下三个方面。
1、xml中的设置和system.clusters中的是否一致。
2、<listen_host>0.0.0.0</listen_host> 这个配置要配置成0.0.0.0不然节点之间通讯可能有问题
3、<interserver_http_host>ck1</interserver_http_host&g...
clickhouse集群安装部署
隐0士的博客
06-30
533
HDFS、Spark、HBase和Elasticsearch这类分布式系统，都采用了Master-Slave主从架构，由一个管控节点作为Leader统筹全局。而ClickHouse则采用Multi-Master多主架构，集群中的每个节点角色对等，客户端访问任意一个节点都能得到相同的效果。这种多主的架构有许多优势，例如对等的角色使系统架构变得更加简单，不用再区分主控节点、数据节点和计算节点，集群中的所有节点功能相同。所以它天然规避了单点故障的问题，非常适合用于多数据中心、异地多活的场景。集群是副本和分片的基础
ClickHouse跨集群表数据同步
qq_654603797
07-10
656
ck提供remote函数，允许我们去查询远程的服务。直接跨集群传输，减少了I/O次数，进而大幅度提升了跨集群的数据传输，如数据备份，不同环境同步数据等效率。
ClickHouse报错：Code: 210. DB::NetException: Connection refused (localhost:9000)
zuodingquan666的博客
02-14
6733
TNND，我是真的服了，估计玩阿里云集群的兄弟，都会遇到这个个问题。
首先我们来看启动信息：
[root@hadoop101 ~]# clickhouse-client -m
ClickHouse client version 20.4.5.36 (official build).
Connecting to localhost:9000 as user default.
Code: 210. DB::NetException: Connection refused (localhost:9000).
clickhouse副本和分片
浪子huang
06-24
1462
title: clickhouse副本和分片
date: 2021-02-20 16:48:02
categories: 数据库
tags: clickHouse
副本和分片是在很多分布式系统中都有，首先简单来看看他们的概念。
副本：数据结构相同，数据相同（数据层面的备份冗余）
分片：数据结构相同，数据不同。（数据量层面水平切分）
集群是副本和分片的基础，它将ClickHouse的服务拓扑由单节点延伸到多个节点，但它并不像Hadoop 生态的某些系统那样，要求所有节点组成一个单一的大集群。ClickH.
“相关推荐”对你有帮助么？
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
©️2022 CSDN
皮肤主题：精致技术
设计师：CSDN官方博客
返回首页
可爱马莲花
CSDN认证博客专家
CSDN认证企业博客
码龄6年
暂无认证
原创
97万+
周排名
188万+
总排名
9万+
访问
等级
972
积分
粉丝
28
获赞
评论
94
收藏
私信
关注
热门文章
linux 查询目录下包含关键字的所有文件
15206
jdk的动态代理及为什么需要接口
11475
DNS域名解析服务器的搭建
10895
HTTP cookies 详解
8416
查看Linux操作系统版本
8077
分类专栏
java
13篇
linux
6篇
rabbitmq
1篇
kafka
1篇
spring boot
3篇
ngix
http
3篇
web
1篇
redis
3篇
Java io
2篇
windows
2篇
java集合
3篇
spring
3篇
spring ioc源码学习
3篇
git
1篇
hive
1篇
大数据
5篇
grpc
1篇
定时调度
2篇
hadoop
4篇
zookeeper
curator
2篇
clickhouse
1篇
dubbo
1篇
最新评论
分布式任务编排调度框架设计
燕之夜:
图呢？
jdk的动态代理及为什么需要接口
?^_^Y?:
这个文章看一下，https://segmentfault.com/a/1190000021821314，就懂了
jdk的动态代理及为什么需要接口
提木甬跑路:
到你这找这个问题的答案的时候我到现在为止已经找了一个多小时了，你这说法还是没有重点，炒来炒去没意思就像那些人写论文一样，文字游戏
hive存储处理器（StorageHandlers）以及hive与hbase整合
爱你魔力转圈圈:
亲爱的博主，你好，我是你忠实的粉丝，我拜读了你很多文章。都很不错。我有一个小小的建议，就是你的文章应该搞个目录，然后不要用斜体，该加粗的加粗，要不然你这文章没法看。一片白，抓不出重点
jdk的动态代理及为什么需要接口
刘客青:
看了很多博文，和你回答的都差不多，其实都没有回答开头的问题。为什么jdk动态代理需要接口。你们回答的不过都是jdk实现的手段的局限性。人家cglib不是也实现了嘛。真正的原因其实应该藏在 byte[] proxyClassFile = ProxyGenerator.generateProxyClass( proxyName, interfaces, accessFlags);这一句代码里。理解了这段代码的逻辑，我想才能更好的回答这个问题。
您愿意向朋友推荐“博客详情页”吗？
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
精通Dubbo——Dubbo支持的协议的详解
[Curator] Leader Election 的使用与分析
[Curator] Path Cache 的使用与分析
2018年48篇
2017年2篇
目录
目录
分类专栏
java
13篇
linux
6篇
rabbitmq
1篇
kafka
1篇
spring boot
3篇
ngix
http
3篇
web
1篇
redis
3篇
Java io
2篇
windows
2篇
java集合
3篇
spring
3篇
spring ioc源码学习
3篇
git
1篇
hive
1篇
大数据
5篇
grpc
1篇
定时调度
2篇
hadoop
4篇
zookeeper
curator
2篇
clickhouse
1篇
dubbo
1篇
目录
评论 1
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明：
1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、C币套餐、付费专栏及课程。
余额充值