运维老鸟告诉你这个经典Zookeeper问题的根因

2020 年 4 月 25 日

运维老鸟告诉你这个经典Zookeeper问题的根因

本文由 dbaplus 社群授权转载。


大家好,我是一名有着近二十年工作经验的运维老鸟。


你问运维干什么的?呵呵…运维就像三国里的军师,擅长排兵布阵,能够运筹帷幄,统筹大局。再烂的系统,运维也能玩得转!


你说什么?重启能够解决运维 90%的问题?


嗯…嗯…其实…你说的对!重启能够解决 90%的问题,如果不行的话…那就再重启一次试试!


好吧,看看大家眼中的运维是什么样的吧:



至于我对运维的理解…给大家讲讲我们最近解决的一个小问题吧。


一、问题缘由


最近从业务部门纳管了一批 ZooKeeper 集群,在对纳管集群进行巡检的时候,发现其中一个 5 节点的集群存在两个 leader 节点的情况。经与业务部门确认,该集群影响多个重要业务系统,所以在处理问题的时候既要保证 ZooKeeper 集群能够恢复正常服务,又需要确保所有的业务数据不能丢失。


问题集群为三机房部署的可容灾集群,集群信息如下(本文所有 IP 等关键信息已脱敏):



正常情况下一个 ZooKeeper 集群只能有一个 leader 节点,若干个 follower 节点。如下图:



但是该集群在两个 leader 节点的情况下,各节点依然状态正常,并能够正常提供服务,确实有点奇怪。为了能够说明清楚该问题,我们先了解下 ZooKeeper 集群的选举原则。


二、ZooKeeper 集群选举原则


ZooKeeper 集群的 leader 选举三原则:


  • 集群中只有超过半数以上的节点启动,集群才能正常工作;

  • 在集群正常服务前,myid小的节点给myid大的节点投票,直到集群正常,选出Leader;

  • 选出Leader之后,之前的节点状态由Looking变为Following,以后的节点都是Follower。


假设一个 5 节点的集群,myid 分别是 1、2、3、4、5,依序启动:


1)节点 1 启动


  • 各节点状态(1:启动;2:关停;3:关停;4:关停;5:关停)

  • 选取状态(1: LOOKING;2:-;3:-;4:-;5:-)

  • 集群状态(节点未满半数:失败)


2)节点 2 启动


  • 各节点状态(1:启动;2:启动;3:关停;4:关停;5:关停)

  • 选取状态(1: LOOKING;2:LOOKING;3:-;4:-;5:-)

  • 集群状态(节点未满半数:失败)


3)节点 3 启动


  • 各节点状态(1:启动;2:启动;3:启动;4:关停;5:关停)

  • 选取状态(1: FOLLOWING;2:FOLLOWING;3:LEADING;4:-;5:-)

  • 集群状态(节点过半数:成功)


4)节点 4 启动


  • 各节点状态(1:启动;2:启动;3:启动;4:启动;5:关停)

  • 选取状态(1: FOLLOWING;2:FOLLOWING;3:LEADING;4:FOLLOWING;5:-)

  • 集群状态(节点过半数:成功)


5)节点 5 启动


  • 各节点状态(1:启动;2:启动;3:启动;4:启动;5:启动)

  • 选取状态(1: FOLLOWING;2:FOLLOWING;3:LEADING;4:FOLLOWING;5:FOLLOWING)

  • 集群状态(节点过半数:成功)


三、问题分析


根据集群信息表:



查看 192.176.238.219 的日志发现 4 号节点成为 LEADING 状态时,集群中有 3 个节点:


[myid:4] - INFO  [QuorumPeer[myid=4]/0:0:0:0:0:0:0:0:2181:Leader@946] - Have quorum of supporters, sids: [ 1,2,4 ];
复制代码


满足节点数过半的原则,集群正常服务,但是查看节点内容,发现节点 1、2 的内容和 4 不一致,反而是节点 1、2、3、5 内容是一致的。


查看节点 4 的内容:



查看节点 5 内容:



通过内容排查可以看出节点 1、2、3、5 内容一致,可能属于同一集群,那么节点 4 为什么和其它节点内容不一致呢?


继续排查节点的配置信息,发现节点 4 配置的内部通讯端口:选举端口与其它节点配置的不一致!


节点 4 配置情况:



节点 1、2、3、5 的配置情况:



通过配置排查可以确认 1、2、3、5 是属于同一个集群,那 4 节点又是哪个集群呢?


继续排查发现,在同一批主机下面部署了另一个 ZooKeeper 实例,开放的服务端口是 2182,而其配置的内部通讯端口:选举端口正是 2888:3888。



通过排查这个集群节点的内容发现:节点 1、2 的内容和上面集群的节点 4 内容是一致的,而这个集群 3、4、5 节点的内容又是一致的!通过推断,集群状态如下表:



由于集群 2 和集群 3 都有三个节点,配置的总节点数是 5,均满足节点数过半的原则!


四、问题影响


那么这种情况下会出现什么问题呢?


本来正常情况下 A 类业务系统只读写 2181 端口的集群、B 类业务系统只读写 2182 端口的集群,而现在集群 2 既可以服务 A 类业务,又可服务 B 类业务,如果集群 2 的数据丢失,将影响两类业务的正常运行。



五、解决问题


集群 2 是一个异常集群,但是如果将集群 2 的节点恢复正常并分别加入到集群 1 和集群 3 后,集群 2 的数据势必会丢失。由于 ZooKeeper 集群的数据是由 A 类业务系统和 B 类业务系统进行读写的,解决的方法首先需要将集群 2 的数据导出并根据业务类型进行区分,待集群恢复正常后,再将这部分数据依据业务归属分别重新写入到对应的集群。


集群恢复步骤:


1)为防止数据丢失,备份集群 1、集群 2、集群 3 的数据(snapshot 和 log)。


2)提取集群 2 的数据,并依据业务类型将数据分类,并准备重新写入。


3)关停集群 2 节点 4(192.176.238.219:2181)实例,集群 2 剩余 2 个节点,不满足半数要求,集群重新进行选举,由于集群 2 的 1、2 两个节点的通讯、选举端口和集群 3 配置一致,并且集群 3 已经选举了节点 5 为 leader,那么集群 2 的节点 1、2 将加入到集群 3 成为 follower,形成 5 节点的集群。


4)修改集群 2 节点 4(192.176.238.219:2181)的内部通讯端口:选举端口为 2889:3889


5)启动 192.176.238.219:2181 实例,由于该实例的通讯、选举端口和集群 1 配置一致,并且集群 1 已经选举了节点 5 为 leader, 该实例将加入集群 1 成为 follower,形成 5 节点的集群。


6)分别将原集群 2 的数据分类后重新写入到集群 1 和集群 3。


7)检查集群状态,检查集群数据信息,并进行业务测试。


恢复后的集群信息如下:



通过以上操作步骤后,集群恢复正常,丢失数据重新写入,所有业务验证正常。


六、小结


该问题根因很简单,只是一个配置的小问题,但是处理却很容易出错。因为这是一个已经在线运行了很久的系统,往往不会怀疑是配置的问题,在处理该问题时,如果没有理清楚问题根因,只是简单将问题集群重启,表面上问题已经解决,但是大量数据将会丢失会严重影响到业务,并且根因没有找到,问题依旧存在,随时可能复发…


说了这么多,你还认为运维只是简单的重启就能解决问题吗?那什么是运维呢?


其实啊,运维是个灶台,上面背着个黑锅,下面还有个大坑…


作者介绍


邹春华,新炬网络中间件专家。10 年软件开发工作经验,9 年运营商行业 IT 系统维护经验。精通 C、C++、JAVA、PHP、SHELL 等语言,有着深厚的大型 IT 软件系统开发功底,精通 MQ、Redis、Zookeeper、nginx、tomcat 等技术组件的配置和优化,也擅长 zabbix、Grafana 、cacti、ansbile 等组件的运用,有大量的自动化运维开发实践。


原文链接


https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650787351&idx=2&sn=5332cc47bc2fd2f043f3462dc7f5773e&chksm=f3f97b82c48ef294a82ce33edd9166b159a0cbeaee292b40e991fba37daa6c26b06c00174f9a&scene=27#wechat_redirect


2020 年 4 月 25 日 10:001246

评论 1 条评论

发布
用户头像
一般会在同几个主机上部署多套zookeeper集群吗?
2020 年 04 月 30 日 13:41
回复
没有更多评论了
发现更多内容

算法训练营第二期:第二周总结

xiaomao

1.请简述 CAP 原理。

张荣召

11/1-第二周-作业

张冬冬

学习

架构师训练营 1 期第 6 周:技术选型(二) - 作业

灵霄

极客大学架构师训练营

技术选型(2)课后作业

ABS

框架设计原则

笨笨程序猿

架构设计 极客大学架构师训练营 接口隔离

架构师训练营第 1 期第 6 周总结

du tiezheng

极客大学架构师训练营

第六周总结

_

极客大学架构师训练营 第六周总结

架构师训练营第六周命题作业

一马行千里

极客大学架构师训练营 命题作业

架构师二期第二周作业

supersky6

作业

week2学习总结

幸福小子

碎碎念

大头虾

第 5 周 这东西也有标准化答案???

Pyr0man1ac

第六周课后总结

天天向上

极客大学架构师训练营

Week 2 :框架设计(作业一)

shuyaxx

第六周 技术选型 作业一

应鹏

极客大学架构师训练营

架构师训练营 - 第六周作业

一个节点

极客大学架构师训练营

6.1分布式关系数据库(上)

张荣召

架构课第二周Cache UML图

路路

极客大学架构师训练营

架构师训练营第二周学习总结

张小胖

极客大学架构师训练营

架构师训练营第 1 期 - 第 6 周 - 学习总结

wgl

第六周作业

熊桂平

极客大学架构师训练营

第六周总结

与前端训练营的日子--Week01

SamGe

学习

依赖倒置原则、接口隔离原则优化类的设计

Calvin

极客大学架构师训练营

第六周作业

架构师训练营第二期 - 第二周课后练习

xiaomao

第 6 周 是这么玩的???

Pyr0man1ac

架构师训练营第 1 期 - 第 6 周 - 命题作业

wgl

week6

张兵

极客大学架构师训练营

MULE 无法接收TCP报文问题分析

东风微鸣

APM

运维老鸟告诉你这个经典Zookeeper问题的根因-InfoQ