共计 2468 个字符，预计需要花费 7 分钟才能阅读完成。
本文应用「署名 4.0 国内 (CC BY 4.0)」许可协定，欢送转载、或从新批改应用，但须要注明起源。署名 4.0 国内 (CC BY 4.0)
本文作者: Nicksxs
创立工夫: 2022-05-29
本文链接: 记录下 zookeeper 集群迁徙和易错点
前阵子做了 zk 的集群降级迁徙，大略状况是原来是一个三节点的 zk 集群（最小可用
大略是
zk1 192.168.2.1
zk2 192.168.2.2
zk3 192.168.2.3在 zoo.cfg 中的配置就是如下
server.1=192.168.2.1:2888:3888
server.2=192.168.2.2:2888:3888
server.3=192.168.2.3:2888:3888加节点
须要将集群迁徙到 192.168.2.4（简称 zk4），192.168.2.5（简称 zk5），192.168.2.6（简称 zk6）这三台机器上，目前新的这三台机器上是没有 zk 部署的, 咱们想要的是数据不失落，那次要思考的就是滚动降级，这里我其实犯了几个谬误，也特地阐明下
首先咱们想要新的三台机器加进去，所以我在 zk4，zk5，zk6 的配置是这样
server.1=192.168.2.1:2888:3888
server.2=192.168.2.2:2888:3888
server.3=192.168.2.3:2888:3888
server.4=192.168.2.4:2888:3888
server.5=192.168.2.5:2888:3888
server.6=192.168.2.6:2888:3888这样起来发现状态是该节点没起来，
PS：查看以后节点状态能够通过 ./zkServer.sh status 来查看
第一个问题是我须要一个 myid 文件，标识我是哪个节点，外面的内容就写 4或 5 或 6 这样就行了，并且这个文件的门路应该在配置文件中指定的 dataDir= 数据目录下
第二个问题是困扰我比拟久的，我在按下面的配置启动节点后，发现这几个节点都是没起来的，并且有 FastLeaderElection@xxx - Notification time out: 60000 这个报错，一开始认为是网络不通，端口没开这些起因，查看了下都是通的，后果起因其实跟我之前的一个思考是相干的，当有六个节点的时候，实践上须要有半数以上的节点可用，集群才会是衰弱的，然而按我这个形式起来，其实我配置了六个节点，然而其中三个都是不可用的（包含本身节点），那么它天然是没方法失常工作，所以这里其实也须要滚动增加，相似于这样
我的 zk4 的配置应该是这样
server.1=192.168.2.1:2888:3888
server.2=192.168.2.2:2888:3888
server.3=192.168.2.3:2888:3888
server.4=192.168.2.4:2888:3888而后 zk5 的配置
server.1=192.168.2.1:2888:3888
server.2=192.168.2.2:2888:3888
server.3=192.168.2.3:2888:3888
server.4=192.168.2.4:2888:3888
server.5=192.168.2.5:2888:3888接着 zk6 的配置就能够是全副了
server.1=192.168.2.1:2888:3888
server.2=192.168.2.2:2888:3888
server.3=192.168.2.3:2888:3888
server.4=192.168.2.4:2888:3888
server.5=192.168.2.5:2888:3888
server.6=192.168.2.6:2888:3888而后为了集群齐全更新，就持续在 zk4 和 zk5 加上其余节点，这样我的 6 节点集群就起来了
下节点
这里我踩了另外一个坑，或者说没搞清楚两种形式的差异，
第一种
首先说说我没采纳的第一种形式，（也是比拟正当的）其实下面这个集群有个显著的问题，老集群其实还是各自认了一个三节点的集群，其中 zk3 是主节点，对于 zk1，zk2，zk3 来说它们能看到的就只有这三个节点，对于后三个 zk4，zk5，zk6 节点来说他们能连上其余五个节点，能够认为这是个六节点的集群，那么比拟正当的操作应该是在老的三节点上把前面三个也都加进来，即每个节点的配置里 server 都有 6 个，而后我再对老的节点进行下线，这里下线须要留神的比拟现实的是下一个节点就要批改配置，挪掉下线的节点后进行一遍重启，比方我晓得了集群中的 leader 是在 zk3 下面，那么我先将 zk1 和 zk2 下掉，那么在我将 zk1 下线的之后，我将其余的五个节点都删除 zk1 的配置，而后重启，这样其实不是必须，但绝对会牢靠些，实践上我也能够在下掉 zk1 和 zk2 之后再批改配置重启其余节点。而当只剩下 zk3，zk4，zk5，zk6 四个节点的集群后，并且每个节点里的配置也只有这四个 server，我再下线 zk3 这个 leader 的时候，就会进行选举，再选出新的 leader，因为刚好是三节点，同样保障了最小可用。
第二种
这也是我踩坑的一种形式，就是我没有批改原来三节点的配置，并且我一开始认为能够通过下线 zk1，zk2，zk3（进行选举）的形式实现下线，而后再进行重启，然而这种形式就是我下面说的，原来的三节点里我下掉 zk1 还是可能失常运行，然而我下线 zk2 的时候，这个集群就等于是挂了，小于最小可用了，这样三节点都挂了，而且对于新退出的三个节点来说，又回到了最后起不来一样状态，六节点里只有三节点在线，导致整个集群都挂了，所以对于我这样的操作来说，我须要滚动批改启动，在下线 zk1 的时候就须要把 zk4，zk5，zk6 中的 zk1 移除后重启，当然这样惟一的益处就是能够少重启几个，同样持续下线 zk2 的时候，把 zk2 移除掉再重启，其实在移除 zk1 后批改重启后，在下线 zk2 的时候，集群就会从新选举了，因为 zk2 下线的时候，zk3 还是会一起下线。这个是咱们须要特地留神的