关于数据库:干货收藏｜Clickhouse-常见问题及解决方案汇总

常见问题

偶然呈现 CLOSE_WAIT 状况

CLOSE_WAIT 占用的是网络端口资源，一台机器能够有 6 万多个端口，如果偶然有 CLOSE_WAIT 的状况，也不必太焦急，只有 CLOSE_WAIT 不是迅速继续地减少，一般来说该状况也会在数小时后被零碎回收掉。

频繁呈现 CLOSE_WAIT 状况

如果零碎有大量 CLOSE_WAIT，次要体现是在有句柄操作时会报 ”too many open files” 的问题，这时候服务不可拜访，甚至 SSH 都连不上。但 ”too many open files” 的问题也有可能是关上的文件句柄太多导致，即 ClickHouse 写入太频繁或者查问的时候常常要查大量的历史数据。

呈现 ”too many parts” 状况

“too many parts” 个别是 ClickHouse 写入太频繁，导致 Parts 没有及时合并引起的，也有可能有大查问导致磁盘 IO 被占用而受影响。

呈现 ”too many simultaneous queries” 状况

“too many simultaneous queries” 外表上来看是查问并发引起的，但通常状况下也有可能是因为有 大查问占用了大量的磁盘，导致很多查问申请沉积而超过了阈值引发的。

ClickHouse 里的并发申请都是存在 processes 表中，所有待执行与正在执行的申请均在该表中，当申请执行完之后便会被革除。呈现 ”too many simultaneous queries” 谬误时，便是依据这张表中求求的数量和 config.xml 的 max_concurrent_queries 参数来比照的，如果 processes 中的数量超过了 max_concurrent_queries，就会报 “too many simultaneous queries”，该景象能够了解为一种限流的爱护机制。如果一个申请执行花了很长时间，它在 processes 表中待的工夫就很长，如果很多申请均呈现这样的状况，那么 processes 中的记录就有可能超过 max_concurrent_queries。

Clickhouse 的 CPU 使用率与 CPU Load 飙升

大查问引起

包含 Join 查问、未带分区的查问、表构造定义没有应用好分区和主键、理论数据量过大、并发查问、Bug 等；

ClickHouse 正本同步引起

故障形容

• Clickhouse 节点意外挂掉重启后 CPU Load 值继续飙升（超过 CPU 核数）无奈复原，节点不能失常提供服务，同步数据处于卡死状态；

• 查问集群中每个节点的 system.replication_queue，存在异样 MERGE_PARTS 类型工作，日志中有 “No active replica has part … or covering part” 报错信息。

  解决方法

  问题呈现的起因为 Clickhouse V20 有相干 Bug。当一些正本中有 Parts 失落，此时正本同步队列中有异样工作时则会导致正本之前的同步呈现死锁景象，具体解决步骤如下：
  在集群中每个节点上，通过 clickhouse-clinet 连贯后，查问 system.replication_queue 表，看有无异样工作；

SELECT * FROM system.replication_queue WHERE create_time < now() - INTERVAL 1 DAY AND type = 'MERGE_PARTS' AND last_exception LIKE '%No active replica has part%' \G

如果节点存在上述异样工作，执行上面的 SQL 查出 zookeeper 上的 Path；

SELECT replica_path || '/queue/' || node_name FROM system.replication_queue JOIN system.replicas USING (database, table) WHERE create_time < now() - INTERVAL 1 DAY AND type = 'MERGE_PARTS' AND last_exception LIKE '%No active replica has part%'

相似：

在 shell 中执行上面的命令，将队列中异样工作的 path 输入到 clickhouse_exception.log 文件中；

clickhouse-client --query "SELECT replica_path ||'/queue/'|| node_name FROM system.replication_queue JOIN system.replicas USING (database, table) WHERE create_time < now() - INTERVAL 1 DAY AND type ='MERGE_PARTS'AND last_exception LIKE'%No active replica has part%'" > clickhouse_exception.log

在 ClickHouse 集群对应的 Zookeeper 节点上，拜访 ./zookeeper-shell.sh 127.0.0.1:2181，连贯 zookeeper 后，按 clickhouse_exception.log 中记录的 path, 逐个执行删除 path 的操作。需注意，该操作十分危险，肯定要确认 rmr 前面的门路与 clickhouse_exception.log 中的门路一样。参考示例如下：

rmr /clickhouse/tables/1/docp/metrics/replicas/replica1/queue/queue-0000003433

当异样的 Path 删除实现后，在以后 ClickHouse 节点的 Clickhouse-client 中执行 SYSTEM RESTART REPLICAS 命令，使正本同步工作重启；

按上述步骤对其余节点进行解决，并再次查看曾经解决过的节点。

解决思路

1. 首先需剖析故障状况是否为近期呈现，如果是，则需查看近期是否有其余变更；
2. 如果近期未有其余变更，则须要查看机器的 CPU、网络、内存、磁盘等负载状况。程序在超负荷状态下会呈现各种问题，因而，首先要将负荷降到失常状态再来排查问题；
3. 机器负载异样，要从两方面剖析。一方面有可能是程序异样引起了高负载，另一方面也有可能是高负载引起了程序异样，如果不好判断，则用排除法，能够卸载一些性能来看负载的变动；
4. 如果以后故障为历史问题，则需回到问题首次浮现的工夫点来剖析。

总结

程序是运行在 OS 和硬件上的，程序和 OS 非亲非故，程序的一些问题会反馈到 OS 的指标上，OS 上的指标也能看进去程序运行的一些问题，所以只有把握如何看机器负载，对相干指标有清晰的意识能力更好的做好排障工作。通常上面这样状况均须要引起器重：

1. CPU Load5 及 Load10 超过 CPU 核数；
2. 机器的闲暇内存超过 90%；
3. CPU 均匀使用率超过 90%；
4. 磁盘使用率超过 90%，磁盘 util 继续超过 90%；
5. 网络上传下载速率超过带宽的 80%。

开源我的项目举荐

云智慧已开源数据可视化编排平台 FlyFish。通过配置数据模型为用户提供上百种可视化图形组件，零编码即可实现合乎本人业务需要的炫酷可视化大屏。同时，飞鱼也提供了灵便的拓展能力，反对组件开发、自定义函数与全局事件等配置，面向简单需要场景可能保障高效开发与交付。

如果喜爱咱们的我的项目，请不要遗记点击下方代码仓库地址，在 GitHub / Gitee 仓库上点个 Star，咱们须要您的激励与反对。此外，即刻参加 FlyFish 我的项目奉献成为 FlyFish Contributor 的同时更有万元现金等你来拿。

GitHub 地址： https://github.com/CloudWise-OpenSource/FlyFish

Gitee 地址： https://gitee.com/CloudWise/f…

微信扫描辨认下方二维码，备注【飞鱼】退出 AIOps 社区飞鱼开发者交换群，与 FlyFish 我的项目 PMC 面对面交换～