关于zk迁移的一些教训

运维千成条，稳定第一条，操作不规范，后台两行泪

###极简步骤

假设有zkid 【 1 , 2 ,3 】 的三台机器，现在因各种原因需要裁撤和下线 【1，2 】 的机器。

• 扩容zk 集群为 【1，2，3，4，5】
• 所有调用方更改zk调用为 【3，4，5】
• 确认这【1，2】机器的2181端口，没有来自除zk集群以外的的长连接
• 缩容为 【3，4，5】

关于ZK的在线迁移实验和完整和详细步骤， 可见此文的操作  

https://cloud.tencent.com/developer/article/1406912

本文重点说缩容为 3,4,5 再强调补充.

缩容的详细步骤是

1. 更改 3 的配置为 3,4,5 组一个zk集群， 然后重启3
2. 再改 4 的配置为 3,4,5 组一个zk集群，然后重启4
3. 接着停止1
4. 停止2
5. 改5的配置为 3,4,5 组一个zk集群， 最后重启5

以上步骤必须严格按此步骤执行， 操作不规范会进入一个非常痛苦的场景

如果你是这样操作的

1. 停止1
2. 停止2
3. zk集群正常，OK，回收机器

那结果就是大坑！！！

这时候 zk3-5仍然认为 【1，2，3，4，5】是一个集群

停止1，2服务是没有影响的，集群running .但是

已然处于一个非常危险的境地， 【1，2，3，4，5】

再任意宕机一台，集群都会停止服务 !!!

怎么补救

如果1，2的机器还在，或者说能够以原来的IP启动服务， 那此事比较容易

1. 以原来的配置恢复1
2. 以原来的配置恢复2
3. 验证集群状态，是否为 【1，2，3，4，5】全部online .
4. 然后再按照zk缩容的步骤下线

如果1,2的机器已然不在，而且你无法找到同样IP的机器，用于恢复服务，那此时只能以有损的方式，恢复到高可用状态

1. 更改 3 的配置为 3,4,5 组一个zk集群， 然后重启3 , 此时集群会异常
2. 再改 4 的配置为 3,4,5 组一个zk集群，然后重启4, 此时集群也会异常
3. 改5的配置为 3,4,5 组一个zk集群， 最后重启5 , leader按预期会选举为4

为什么不能通过 增加 6 7扩容，再缩容的方式恢复服务了

刚刚异常的场景是 【1，2，3，4，5】,按扩容步骤， 应该是增加 6， 7

但是:

• 此时 3 ， 4 ， 5 的配置，认为是这样一个状态 【1，2，3，4，5】
• 更改3or4的配置进行重启时， 集群都会处于 半数以上宕机的状态， 进而停止服务