作家先容

邹春华，新炬相聚会间件众人。10年软件开采职责劝诫，9年运营商行业IT系统贵重劝诫。耀眼C、C++、JAVA、PHP、SHELL等讲话，有着深厚的大型IT软件系统征军功底，耀眼MQ、Redis、Zookeeper、nginx、tomcat等技巧组件的建树和优化，也擅长zabbix、Grafana 、cacti、ansbile等组件的利用，有大量的自动化运维开采握行。

大众好，我是别称有着近二十年职责劝诫的运维老鸟。你问运维干什么的？呵呵…运维就像三国里的智囊，擅长排兵列阵，粗略出筹画策，统筹大局。再烂的系统，运维也能玩得转！你说什么？重启粗略惩处运维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:38895）启动192.176.238.219:2181实例，由于该实例的通信、选举端口和集群1建树一致，何况集群1仍是选举了节点5为leader， 该实例将加入集群1成为follower，变成5节点的集群。6）分别将原集群2的数据分类后再行写入到集群1和集群3。7）搜检集群景象，搜检集群数据信息，并进行业务测试。规复后的集群信息如下：通过以上操作门径后，集群规复平日，丢失数据再行写入，通盘业务考证平日。六、小结该问题根因很简便，仅仅一个建树的小问题，然而处理却很容易出错。因为这是一个仍是在线运转了很久的系统，不时不会怀疑是建树的问题，在处理该问题时，要是莫得理明晰问题根因，仅仅简便将问题集群重启，名义上问题仍是惩处，然而大量数据将会丢失会严重影响到业务，何况根因莫得找到，问题依旧存在，随时可能复发…说了这样多，你还觉得运维仅仅简便的重启就能惩处问题吗？那什么是运维呢？其实啊，运维是个灶台，上头背着个黑锅，底下还有个大坑…