问题回顾

时间线

• 09-27 03:23 开始，53一直是leader

• 10-02 08:32 53突然大量链接超时，与其他节点心跳断开

  • （可能是GC导致的，这段时间有个20s的GC）

• 10-02 08:33 54选举为leader，开始接管集群

• 10-02 08:34 54和55网路链接断开，集群失去leader，持续10s左右

  • 这个断开可能也是GC导致的

• 10-02 08:34 网络恢复，重新加入集群，53成为leader

• 10-02 08:35 54,55同步数据超时（15s），断开链接，重新选举

  • 这个应该是硬盘和网络导致的，猜测硬盘的可能大一些，zk出问题后，大量组件报错写日志，磁盘io飙高，zk使用的磁盘和日志用的磁盘是同一个（系统盘）

• 10-02 08:35 54,55选举54成为leader

• 10-02 08:36 54出现心跳超时，53重新被选为leader

  • （可能也是GC引起的）

• zookeeper正常

PS：查看日志，11点的时候也出现了超时切换leader，当时54也出现了长时间GC（由于手动重启的原因，lead此时是54），暂时先增大了zookeeper的内存，后续观察会不会继续出现GC超时的现象

影响范围

涉及zk的组件都受到了影响

• YARN

• KAFKA

• HBASE

• pipeline 及 flink实时任务

• fht与zk和kafka相关任务

kafka

 Cached zkVersion [114] not equal to that in zookeeper, skip updating ISR

[KAFKA-3042] 由于 zk 版本问题，更新在多次失败后应停止 - ASF JIRA (apache.org)

[KAFKA-2729] Cached zkVersion not equal to that in zookeeper, broker not recovering. - ASF JIRA (apache.org)

原因：由于zk的问题，51节点被踢出集群，55成为新leader，但是zkVersion和缓存的不一致，不认可zk的metedata，认为自己还是leader，导致脑裂

缓存不一致可能的问题是zk不稳定时发生了kafka选举，epochId比后面的高，51拿着一个比较高的epochId，认为55的选举是过期的（实际上是zk同步失败，导致epochId降低）

这是kafka的bug，目前看来只有出现Pipe broker问题才可能导致这个bug，kafka官方目前未修复

yarn

    hdfs与yarn都以来zk做主备选举，区别是hdfs只利用zk做选举，因此对zk的忍受度相对较高，当zk不稳定时，不会发生主备切换，此时hdfs只要master自己不出问题，短时间内还是不受影响的。

    但是yarn需要使用zk来做状态存储，applicationInfo是存储在zk里面的，当zk不稳定时，ResourceManager无法创建,提交任务，ResourceManager会报错后主动切换为standby,此时另一个ResourceManager也和zk连接有问题，无法切换为master，多次重试后，ResourceManager尝试重启，注意此时不是热备了，已经无法热切换了（此时切换需要重启所有任务），两个ResourceManager都切换不了master，造成YARN整体无法对外服务（但是此时实时任务还在运行，NodeManager并没有挂）。

    这种情况下正确操作是重置yarn的状态，ResourceManager会自动恢复（更快的方法是删除zk中的状态），之后重启任务即可。

    

HBASE:

    Hbase主备选举依赖于zookeeper，zookeeper出问题后master挂掉，zookeeper恢复后重启即可

解决方案

此次问题本质是由于zookeeper的GC时间过长引起（20s,7s,6s）

临时方案：暂时先增大了zookeeper的内存（2G->4G）,减少GC次数

后续：

• GC超时的原因有很多

  • 可能是使用了swap，GC收集器不合理，或者GC参数不合适等

• 后续继续观察，增加GC日志，考虑zk单独部署、更换GC收集器、禁用swap等

• 考虑当时zk同步超时，zk的磁盘可能需要和其他组件分开