ClickHouse问题分析：插入数据时，报“Too many parts ...”

在实际业务中，经常可以碰到插入数据时失败，报错“Too many parts …”，现整理如下，有新场景再继续补充

对于复制表，可以通过如下sql查询下merge是否有异常：

SELECT
database,
table,
type,
any(last_exception),
any(postpone_reason),
min(create_time),
max(last_attempt_time),
max(last_postpone_time),
max(num_postponed) AS max_postponed,
max(num_tries) AS max_tries,
min(num_tries) AS min_tries,
countIf(last_exception != '') AS count_err,
countIf(num_postponed > 0) AS count_postponed,
countIf(is_currently_executing) AS count_executing,
count() AS count_all
FROM system.replication_queue
GROUP BY
database,
table,
type
ORDER BY count_all DESC 

如下报错，表明merge出了问题，然后具体问题具体分析。

│ 2021-12-14 23:41:43 │    2021-12-21 11:17:43 │     2021-12-21 11:17:46 │        523780 │         1 │         0 │         1 │            1687 │               0 │      1688 │
│     xxx    │             xxx           │ MERGE_PARTS    │                     │ Not executing log entry MERGE_PARTS for part 20211218_3434_3439_1 because source parts size (157.29 MiB) is greater than the current maximum (4.45 MiB). 

这个报错一般是业务量大的情况下，可用线程数较小，导致可用的空间不够。可以修改通过增大background_pool_size优化（一般为核数的两倍）。

如果修改background_pool_size后，还有同样报错，那可能是集群已经出现这个问题很久了，有很多的part需要merge，线程数仍然不够。
那临时修改如下参数（问题解决后，修改回默认值，一般为8），让表能正常merge（前提是磁盘空间足够）

alter table xxx modify setting number_of_free_entries_in_pool_to_lower_max_size_of_merge = 1

该参数，其实是使得 clickhouse中计算磁盘空间的大小的公式只跟真正的磁盘空间大小有关。如果，磁盘空间的真正大小足够的情况下，是不会再报此错误的。