标签：hub efi block config 完成 元数据 str 方案 无法
当clickhouse在建表时使用了Replicated引擎族时, 会对zookeeper有非常重的依赖, 这时候就要注意zookeeper集群的一些优化项.
clickhouse集群两分片两副本(4C8G),实测每分钟80W数据量的情况下, Zookeeper单机(4C8G)完全就能够满足要求了, 甚至还有很大的余地.
修改zookeeper的配置项
具体的参数说明可以看官网 Clickhouse Settings
clientPort=2181
dataDir=/data/zookeeper
dataLogDir=/data/logs/zookeeper
tickTime=2000
initLimit=30000
syncLimit=10
maxClientCnxns=2000
maxSessionTimeout=60000000
autopurge.snapRetainCount=10
autopurge.purgeInterval=1
preAllocSize=131072
snapCount=3000000
leaderServes=yes
standaloneEnabled=false
server.1=172.16.8.132:2888:3888
Zookeeper相关文件的存放
多套Zookeeper集群配置一套Clickhouse集群.
com.dtstack.jlogstash.outputs.core.common.ClickhouseException: ru.yandex.clickhouse.except.ClickHouseException: ClickHouse exception, code: 999, host: 172.16.8.84, port: 8123; Code: 999, e.displayText() = DB::Exception: Cannot allocate block number in ZooKeeper: Coordination::Exception: Connection loss (version 19.14.6.12)
ck与Zookeeper的连接丢失导致不能分配块号等问题.
在Clickhouse中, 表的元数据信息, 每个数据块的信息, 每次插入的时候, 数据同步的时候, 都需要和zookeeper进行交互. zookeerper 服务在同步日志过程中, 会导致ZK无法响应外部请求, 进而引发session过期等问题.
参考上面zookeeper相关的优化.
在zoo.cfg中增加forceSync=no
默认是开启的, 为避免同步延迟问题, zk接收到数据后会立刻去将当前状态信息同步到磁盘日志文件中, 同步完成后才会应答. 将此项关闭后，客户端连接可以得到快速响应.
关闭forceSync选项后, 会存在潜在风险, 虽然依旧会刷磁盘(log.flush()首先被执行), 但因为操作系统为提高写磁盘效率, 会先写缓存. 当机器异常后, 可能导致一些zk状态信息没有同步到磁盘, 从而带来zkl前后信息不一样问题.
clickhouse建表的时候添加use_minimalistic_part_header_in_zookeeper参数, 对元数据进行压缩存储, 但是修改完了以后无法再回滚的.
com.dtstack.jlogstash.outputs.core.common.ClickhouseException: ru.yandex.clickhouse.except.ClickHouseException: ClickHouse exception, code: 225, host: 172.16.8.84, port: 8123; Code: 225, e.displayText() = DB::Exception: ZooKeeper session has been expired. (version 19.14.6.12)
zk会话超时, 一般都是由于zk单机/集群出问题(例如zk服务挂了, zk的压力太大)导致的.
com.dtstack.jlogstash.outputs.core.common.ClickhouseException: ru.yandex.clickhouse.except.ClickHouseException: ClickHouse exception, code: 242, host: 172.16.8.84, port: 8123; Code: 242, e.displayText() = DB::Exception: Table is in readonly mode (version 19.14.6.12)
zookeeper压力太大, 表处于“read only mode”模式, 导致插入失败.
其实和上面两个问题Code 999/225一样, 都是由于zk集群的配置导致的, 所以只要想办法增加zk集群的配置, 或者降低zk集群的压力即可.
com.dtstack.jlogstash.outputs.core.common.ClickhouseException: ru.yandex.clickhouse.except.ClickHouseUnknownException: ClickHouse exception, code: 1002, host: 172.16.8.84, port: 8123; 172.16.8.84:8123 failed to respond
导致的原因是官方jdbc的实现用了httpclient的库.
服务器的keep-alive时间已知为3s, 客户端与服务端进行通信, httpclient会复用已创建的连接, 若服务端已关闭连接, 客户端在沿用这个连接就会出现failed to respond的错误.
NohttpResponseException的异常, 重新发送请求，重发N次后还是失败才停止.validateAfterInactivity小于keepAlive Time, 但这种方法依旧不能避免同时关闭.对于clickhouse的jdbc来说, 如果要提供方案, 就要在源码层面更改：
方案1: 修改为短连接, 当然这种方式看你接不接受了, ClickHousePreparedStatementImpl中设置:
post.setHeader("Connection", "close");
方案2: 引入重试机制, 当出现这种错误的时候, 莫急莫慌, 再试一次.
这里我们采用的是方案2, 使用重试机制, 具体的重试次数可以通过参数bulkRetries来控制.
推荐Insert操作使用方案2, Select操作使用方案1. 不需要考虑多次Insert同一数据导致数据重复的问题, CH内部有机制来保证数据唯一性.
An error occured before execution: Code: 371, e.displayText() = DB::Exception: Table ‘test01‘ isn‘t replicated, but shard #1 is replicated according to its cluster definition (version 19.14.6.12)
只有使用了replicated开头的engine的引擎的表, 才能够在拥有on cluster xxx条件的ddl语句中进行集群更新
其他engine的表, 只能够每个node进行update.
distributed_table使用的是Distributed引擎, 所以也不支持on cluster xxx这样条件的ddl语句.
但是在最近的版本中(v20.8 LTS)中, Distributed引擎也支持了 on cluster 操作了, 感觉在低版本中不支持集群DDL语句可能是一个BUG.
所以建议条件允许的话, 将CH集群升级到20.8及以上版本即可.
如果是分布式表
如果是local表
ClickHouse exception, code: 48, host: 172.16.8.84, port: 8123; Code: 48, e.displayText() = DB::Exception: There was an error on [172.16.8.84:9000]: Cannot execute replicated DDL query on leader (version 19.14.6.12)
这个问题我自己也没有弄明白, 查了非常多的资料, 各执一词. 在20.4及以后版本的一个pr修复了相关的问题:
Fix DDL worker timeouts for long queries
推荐升级到v20.8LTS版本.
如果不支持升级CH版本, 我尝试在低版本上为每个分片加了一个副本也将这个问题解决了(原先的架构是无副本的).
标签：hub efi block config 完成 元数据 str 方案 无法
原文地址：https://www.cnblogs.com/yisany/p/14275785.html
