【clickhouse】clickhouse读写

写过程

以INSERT操作为例，假设R1和R2是两个副本名称，在R1节点上执行插入操作，其核心流程如下：

1. 在本地执行分区目录的写入，想zk的blocks目录下写入该分区的block_id
2. 然后由副本R1向zk上的/log目录推送操作日志，日志的内容如图：
   表示操作内容为get下载，需要下载的分区是202110152110_1327_1327_0
3. R2会一直监听/log节点，监测到有日志变化，就会从log里读取任务，但不会立刻执行，而是将任务放置到自己目录下的队列里，这样设计时为了避免同时收到多个操作请求的时候处理不过来的情况。
4. R2基于/queue队列开始执行任务：向远端副本发起get请求，下载指定分区的数据
5. R1相应请求，将分区数据返回给R2
6. R2得到数据后在本地完成写入

常见问题 Table is in readonly mode
问题现象：在笔者的项目环境下，由于存在大数据量的数据写入（200MB/s以上的写入速度），时常会在clickhouse-server的日志中看到Table is in readonly mode的告警信息。
问题原因：翻阅资料后发现这其实是很多人都会遇到的一个问题，大体原因当然是和zk的处理性能相关，随着写入数据量的增多，zk的log和snapshot文件会不断膨胀，有时就会出现zk服务不可用的情况，而clickhouse的ReplicatedMergeTree又强依赖于zk，一旦zk不可用，为了保证数据的一致性，系统就会进行“写保护”，出现上述提示。
解决办法：
方案1：调整use_minimalistic_part_header_in_zookeeper参数； 网上有些朋友说是调整这个参数可以减少写入zk日志的数据量，但因为我们使用的是21的版本，此版本默认这个参数已经是开启了，因此这个方案对我们实际无效。
方案2：一个CH集群使用多个zk集群来提供服务； 这属于压力转移的策略，我们最后也无奈使用了这种办法，当然能解决问题，但带来的副作用就是zk集群运维管理成本的上升。

————————————————
版权声明：本文为CSDN博主「普普通通程序猿」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_40104766/article/details/121781470