clickhouse批量写入报错TOO

报错TOO"/>

clickhouse批量写入报错TOO

clickhouse批量写入报错TOO_MANY_PARTS

• • 场景
  • 处理

场景

• 在windows 10上，使用docker，安装clickhouse最新镜像，启动使用
• 数据库使用默认的Ordinary引擎，数据表使用MergeTree
• 之前测试使用了一段时间，数据写入没问题
• 昨天发现，数据并发写入一段时间后报错Code: 252. DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts. (TOO_MANY_PARTS) ，然后就写不进去了

处理

• ClickHouse每一次插入都会产生一个分区块，相同分区键的分区块会自动合并（具体合并时机由MergeTree引擎决定），合并后会将active置为0，随后8分钟（默认8分钟）后被删除。如果出现类似报错，最大可能是插入频次太高，导致分区块合并速度小于积累速度，当分区块数量超过设定值（默认300），就会报错TOO_MANY_PARTS。最正统、最根本的解决办法，就是减少写入频次，尽量大批次、低频次写入，一次可以多写入一些。
• 查看了下分区块情况，发现所有表的所有的分区块active都是1，level都是0

select table,active,level,count(1)  from system.parts WHERE database ='radar'  group by table,active,level;

• 这个说明所有分区都没有合并。我没有特别配置，按理说会正常的合并，分区块的active和level不可能都为1
• 我尝试使用optimize table xxx final命令强制触发分区块合并，结果有报错，如下图
  
• 根据报错提示，我找到对应位置，发现文件确实存在，有很多temp_merge_2022开头的文件，这些都是合并中产生的中间文件
• 报错是文件temp_merge_2022重命名去除temp_merge失败，说明我的分区块合并失败了，只进行了一半
• 我去看了clickhouse日志，果然，也发现了类似的日志，删除文件失败，也是没有权限
• 我根据这些报错百度了下，找到一个相似的问题解决，他是centos里docker启动clickhouse，将数据目录挂载出来，导致权限不足，和我的情况很像
• 我删除了我本机的clickhouse容器，使用命令重建了容器，果然，问题没有了。问题点就是在windows里使用docker部署clickhouse，但将文件目录挂载到外面，导致没有文件删除权限，无法进行合并

docker run -d --name=single-clickhouse-server --memory 8192m --cpus 4 -p 8123:8123 -p 9000:9000 -p 9009:9009 --ulimit nofile=262144:262144 --volume  E:/data/ck/conf:/etc/clickhouse-server:rw --volume E:/data/ck/log:/var/log/clickhouse-server:rw yandex/clickhouse-server	

• 实际上经我本机测试，每秒1-2次的写入速度，clickhouse完全hold住，不会出现TOO_MANY_PARTS的问题
• 当然，也可以在建表时，指定合并相关参数，如下：

CREATE TABLE radar.traffic_index_in_phase
(
... ...
)SETTINGS index_granularity = 8192,old_parts_lifetime = 300,max_suspicious_broken_parts=1000;

• SETTINGS：配置项，建表时可以把一些配置在这里设置，多个配置使用英文半角逗号分割
• old_parts_lifetime ：已合并的分区块，多久后删除，单位是秒，默认8分钟
• max_suspicious_broken_parts：允许最大的损坏碎片数，默认值是10，可选值范围是任意正整数，如果单个分区中的损坏部分数量超过max_suspicious_broken_parts 配置的值，则拒绝自动修复或者拒绝删除损坏部分的数据，并且服务启动时候直接报错退出