ClickHouse常见问题排查与解决(一)

22 篇文章 0 订阅
14 篇文章 4 订阅

1、Table is in readonly mode (zookeeper path: /clickhouse/tables/iov/t_fault/2)

  • 异常说明

    表示Zookeeper压力过大,表处于只读状态,导致插入失败

  • 分析问题

    Zookeeper压力过大原因分析:

    • 写入数据以及频率过高
    • 集群中出现Zookeeper节点挂掉,导致压力过大
  • 解决方案:

    • 在zookeeper中将dataLogDir存放目录应该与dataDir分开,可单独采用一套存储设备来存放ZK日志。
    • 做好zookeeper集群和clickhouse集群的规划,可以多套zookeeper集群服务一套clickhouse集群。保证Zookeeper集群高可用

2、Replica /clickhouse/tables/s1/dwd/xxxx/replicas/dt_fault already exists

  • 异常说明

    删除表 ZK replicas未同步

  • 分析问题

    表的元信息会保存到Zookeeper节点上,删除副本以及本地表后,客户端未显示表,但是Zookeeper中的元信息未同步删除,即会出现异常。

  • 解决方案

    • 删除本地表后等待若干时间(根据经验得大概5分钟),再删除副本(分布式表)
    • 可以登录ClickHouse服务器进行删除

3、数据写入成功,但是数据库并不存在数据

  • 问题说明

    表引擎是MergeTree或者ReplicateMergeTree,所以不存在数据被合并掉。

    order by字段包括四个,并且时间在中间,比如:id,name,time,type

  • 分析问题

    根据Arthas(是一个Java诊断工具,由阿里巴巴中间件团队开源。它在开发人员中被广泛采用和流行。)一些手段查询到方法的入参以及方法栈的执行情况得知,数据确实入库。

    比如同一时刻入参有三条数据进行入库,查询表只有两条数据。

    • 第一种猜测

      数据重复导致ClickHouse对重复数据进行幂等性操作,进而把重复数据删除。或者会被ClickH忽略掉此次insert

在这里插入图片描述

    大概意思是说已经有一个一模一样的数据块了。另外ck没有事务概念,但是为了保证重复插入的insert的幂等性,会检测重复,如果重复则跳过。
    
    本地测验重复数据会部分保留在数据库,部分被删除。
    
- 第二种猜测
    
    怀疑order by排序字段位置不合理
  • 解决方案
    1. 如果想保存重复数据,两种解决办法

      1. 关闭幂等性校验。SET insert_deduplicate=0
      2. 增加一个或者多个冗余字段,保证每条数据不相同
    2. 创建表时,order by字段是必须的,但是合理安排order by字段,时间放在所有字段的后边

      比如:name,code,type,time等。

4、查询时(非MergeTree表引擎),查出多条重复数据

  • 问题说明

    表引擎为:ReplicatedReplacingMergeTree

    select * from A join B A.id=B.id

  • 分析问题

    表引擎ReplacingMergeTree一个特性就是:去重;但是不保证过程的数据一致性,只能保证数据最终的一致性。如果数据出现更新的话,查询的时候可能会查询出来多条重复数据。

  • 解决方案

查询数据时,在表名后边加上关键字final ,保证数据唯一性。

在这里插入图片描述
JVM内存泄漏和内存溢出的原因
JVM常用监控工具解释以及使用
Redis 常见面试题(一)
ClickHouse之MaterializeMySQL引擎(十)
三种实现分布式锁的实现与区别
线程池的理解以及使用

号外!号外!

最近面试BAT,整理一份面试资料,覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。想获取吗?如果你想提升自己,并且想和优秀的人一起进步,感兴趣的朋友,可以在扫码关注下方公众号。资料在公众号里静静的躺着呢。。。

  • 喜欢就收藏
  • 认同就点赞
  • 支持就关注
  • 疑问就评论

一键四连,你的offer也四连

————————————————————————————————————————————————————————————————

本文作者:Java技术债务
原文链接:https://www.cuizb.top/myblog/article/1645691702
版权声明: 本博客所有文章除特别声明外,均采用 CC BY 3.0 CN协议进行许可。转载请署名作者且注明文章出处。

  • 2
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
当遇到k8snode节点notready问题时,可以按照以下步骤进行排查解决: 1. 检查节点状态:使用命令 `kubectl get nodes` 检查节点的状态,确保节点处于 `Ready` 状态。如果节点状态为 `NotReady`,则表示存在问题。 2. 检查节点事件:使用命令 `kubectl describe node <node-name>` 查看节点的事件,以了解是否有任何故障或异常情况。 3. 检查kubelet日志:使用命令 `journalctl -u kubelet -n 100` 查看kubelet的日志,以查找任何与节点notready相关的错误或警告信息。 4. 检查容器运行时日志:如果使用的是Docker作为容器运行时,可以使用命令 `journalctl -u docker -n 100` 查看Docker的日志。如果使用的是其他容器运行时,可以查找相应的日志文件。 5. 检查网络配置:确保节点能够与其他节点和控制平面正常通信。检查网络配置是否正确,并确保防火墙规则没有阻止必要的流量。 6. 检查资源使用情况:检查节点的资源使用情况,例如CPU、内存、存储等。确保节点上的资源充足以正常运行Pod。 7. 检查配置文件:检查节点的配置文件,例如kubelet配置文件、节点标签等。确保配置文件没有错误,并且节点的配置与集群的要求一致。 8. 重启kubelet服务:尝试重启kubelet服务,可以使用命令 `sudo systemctl restart kubelet`。重启后,观察节点状态是否变为Ready。 9. 联系硬件供应商:如果怀疑节点故障,例如硬件故障或操作系统崩溃,可以联系硬件供应商寻求支持。 10. 检查其他组件:如果以上步骤都没有解决问题,可以检查其他与节点相关的组件,例如网络插件、存储插件等。 在排查问题时,可以结合使用多个命令和工具,以获取更全面的信息和诊断结果。根据具体的情况,可能需要进一步查找相关文档或寻求社区的帮助来解决问题。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Java技术债务

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值