Kafka Cached zkVersion [62] not equal to that in zookeeper, skip updating ISR (kafka.cluster.Partition) 问题分析

我司业务Kafka集群是3节点（broker分别为10,20,30），每个Topic 3 Partition，3 Repilication的配置，早上起床突然发现所有Topic的Broker节点都变为2个了，然后监控发现仍然活着的Broker个数还是3个。那这是怎么回事呢？

通过KafkaManager监控发现，每个Topic的Leader为10的Partition的ISR只有10了，20,30都消失了，而其他Partition的ISR中也都缺少了10。直觉告诉我，10这个节点实际已经被整个集群抛弃了，查看10节点的日志文件，发现日志仍然在增长，并且其他节点的信息也都在正常同步，也就是说10节点还在工作，但是对于整个集群来说，并没有认可，那么问题是什么呢？由于我们对于Kafka和ZK没有最基本的监控，所以只能通过有限的监控来判断问题发生的时间点，然后找到对应的log日志进行排查。

首先需要确认问题发生的时间点，既然kafka级别的监控不全，那么首先从主机级别的流量开始查吧：

比较幸运的是，发现16:19分左右，10节点的流量有个突变，首先是大幅降低，直至为0，然后突然暴涨，后续恢复正常，很明显是一个10节点离线，然后上线的过程。定位到这个时间点，然后去翻日志，发现20,30节点的日志出奇的类似：

10节点首先被踢出了集群，Shrinking ISR for partition [XXXXXXX,1] from 30,10,20 to 30,20

然后更新ISR的时候报错：Cached zkVersion [27] not equal to that in zookeeper, skip updating ISR (kafka.cluster.Partition)

这个基本符合我们的猜测，10节点短暂离线，然后上线后，因为20,30update ISR时判断ZKversion错误，中断更新，导致10节点只是接管了自己是Leader的那些Partition，对于20,30是Leader的那些，很遗憾，认为10一直死着。这真是一个天大的悲剧啊！

那么为什么会产生这个问题呢？通过一阵google，发现这么一篇文章：https://issues.apache.org/jira/browse/KAFKA-2729 。

Kafka-2729Bug，摘抄几个回复：

ok，我们得出几个结论，这种问题确实是Kafka与ZK连接短暂中断引起，并且这个只能通过重启Kafka节点解决，然后这个在1.1.0版本才得以修复。。。。。。

没其他办法，我们只能择日重启了10节点的kafka，问题解决。

对于升级这件事情，短期内我们是无法解决的，我们应该如何避免或者第一时间知道此类问题的发生呢？

1. 首先Kafka跟ZK的连接为什么中断呢？原因很多，比如网络闪断，比如ZK繁忙，比如ZKGC时间过长。那么我们需要加大Kafka与ZK连接的超时时间：默认6秒，我们增加到30秒。更新位置：Kafka配置文件，两个参数更新如下：

zookeeper.session.timeout.ms=30000

zookeeper.connection.timeout.ms=30000

2. 比如对Kafka，ZK建立全面的监控，结合预警，第一时间知晓问题，然后根据监控指标进行分析，而不是撞大运，人工翻日志

如何建立全面的kafka,ZK监控体系呢？别急，下篇揭晓，先上个图吧：

3. 当然是熟读源码，然后知其所以然，然后。。。。由于业务重心不在这一块，所以这个目标对我而言有点难，各位大牛如果知道此问题的前因后果，欢迎告诉小弟，感激不尽！

巴特西

Kafka Cached zkVersion [62] not equal to that in zookeeper, skip updating ISR (kafka.cluster.Partition) 问题分析

最新文章

热门文章