运维老鸟告诉你这个经典Zookeeper问题的根因
最后更新：2020-04-18 11:51:59 手机定位技术交流文章
作者简介
邹春华是新居网络中间件专家。在运营商行业有10年的软件开发经验和9年的信息技术系统维护经验。精通C、C++、JAVA、PHP、SHELL等语言，在大型IT软件系统开发方面有深厚的基础，精通MQ、Redis、Zookeeper、nginx、tomcat等技术组件的配置和优化，还擅长zabbix、Grafana、cacti、ansbile等组件的应用，并有大量的自动化操作和维护开发实践。
大家好，我是一个有近20年操作和维护经验的老鸟。
你要求操作和维护什么？哈哈…操作和维护就像三国的军师。善于排兵布阵，能运筹帷幄，协调全局。不管系统有多差，操作和维护也能发挥好！
你说什么？重启可以解决90%的操作和维护问题？
呃...呃...实际上...你说得对！如果不能，重启可以解决90%的问题...那就再试一次！
好吧，让我们看看每个人眼中的行动是什么样的:
至于我对操作和维护的理解...让我们来谈谈我们最近解决的一个小问题。
一、问题的原因
最近，一批ZooKeeper集群由业务部管理。在检查受管集群期间，发现5个节点集群中的一个具有两个领导节点。在与业务部门确认后，集群影响到许多重要的业务系统，因此在处理问题时，有必要确保ZooKeeper集群能够恢复正常服务，并且不会丢失所有的业务数据。
问题群集是部署在三个计算机房中的灾难容忍群集。集群信息如下(在本文中，所有关键信息(如IP)都被忽略):
在正常情况下，ZooKeeper集群只能有一个引导节点和几个跟随节点。下图:
然而，在两个领导节点的情况下，集群中的节点仍然处于正常状态，能够正常提供服务，这确实有点奇怪。为了清楚地解释这个问题，我们首先了解动物园管理员集群的选举原则。
第二，动物园管理员的集群选举原则
动物园管理员集群中领导者选举的三个原则:
只有当集群中超过一半的节点被启动时，集群才能正常工作；在集群正常服务之前，myid小的节点投票给myid大的节点，直到集群正常并成为领导者；被选中。选择“引线”后，先前的节点状态将从“查看”更改为“跟随”，所有后续节点都将跟随。假设一个5节点集群，myid分别为1、2、3、4、5，依次开始:
1)节点1开始
每个节点的状态(1:启动；2.关闭。3.关闭。4.关闭。5:关机)选择状态(1:查看；2:3:4:5:-)群集状态(少于一半的节点:失败)2)节点2已启动
每个节点的状态(1:启动；2.启动；3.关闭。4.关闭。5:关机)选择状态(1:查看；2:寻找；3:4:5:-)群集状态(少于一半的节点:失败)3)节点3已启动
每个节点的状态(1:启动；2.启动；3.启动；4.关闭。5.关机)选择状态(1:以下；2:FOLLOWING；3:领导；4:5:-)群集状态(节点多数:成功)4)节点4已启动
每个节点的状态(1:启动；2.启动；3.启动；4.启动；5.关机)选择状态(1:以下；2:FOLLOWING；3:领导；4:FOLLOWING；5:-)群集状态(节点多数:成功)5)节点5已启动
每个节点的状态(1:启动；2.启动；3.启动；4.启动；5:开始)选择状态(1:以下；2:FOLLOWING；3:领导；4:FOLLOWING；5:以下)群集状态(节点多数:成功)3。问题分析
根据聚类信息表:
查看192.176.238.219的日志，发现当节点4成为LEADING时，群集中有3个节点:
要查看节点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，这满足了一半以上节点的原则！
Iv .问题的影响
在这种情况下会出现什么问题？
在正常情况下，A类服务系统仅读取和写入端口为2181的群集，而B类服务系统仅读取和写入端口为2182的群集。现在，集群2可以同时服务于A类服务和B类服务。如果群集2的数据丢失，这两种服务的正常运行将受到影响。
V.问题解决
群集2是一个异常群集，但如果群集2的节点恢复正常并分别添加到群集1和群集3，群集2的数据将不可避免地丢失。由于ZooKeeper集群的数据是由A类服务系统和B类服务系统读写的，因此解决方案首先需要导出集群2的数据，并根据服务类型进行区分。当集群恢复正常后，这部分数据将根据服务属性分别重写到相应的集群中。
群集恢复步骤:
1)为防止数据丢失，请备份群集1、群集2和群集3的数据(快照和日志)。
2)提取集群2的数据，根据服务类型对数据进行分类，并准备重写。
3)关闭群集2的节点4(192.176.238.219:2181)的实例。群集2的其余2个节点不满足一半的要求。集群重新选举。由于集群2的1和2节点的通信和选举端口与集群3的配置一致，并且集群3已经选举节点5作为领导者，那么集群2的节点1和2将作为追随者加入集群3，形成5节点集群。
4)修改集群2节点4的内部通信端口(192.176.238.219:2181):选举端口为2889:3889
5)启动192.176.238.219:2181实例。由于此实例的通信、选择端口和集群1配置相同，并且集群1已选择节点5作为领导者，因此此实例将作为跟随者加入集群1，并形成由5个节点组成的集群。
6)对原始集群2的数据进行分类，并将它们分别写回到集群1和集群3。
7)检查集群状态，检查集群数据信息，并进行业务测试。
恢复的群集信息如下:
通过上述操作步骤后，集群恢复正常，丢失的数据被重写，所有服务被验证为正常。
六.摘要
这个问题的根源很简单，它只是一个小的配置问题，但在处理时很容易出错。因为这是一个已经在线运行了很长时间的系统，所以通常不会被怀疑是配置问题。在处理这个问题时，如果没有清楚地了解问题的根本原因，问题集群只是简单地重新启动，问题在表面上已经得到解决，但是大量的数据将会丢失，这将严重影响业务，并且如果没有找到根本原因，问题仍然存在并且可能随时重复出现。
本文由 在线网速测试 整理编辑，转载请注明出处。
