集群恢复与故障转移

RabbitMQ镜像队列集群的恢复的解决方案和应用场景

前提

比如两个节点A和B组成一个镜像队列

场景1

A先停，B后停

方案1：该场景下B是Master，只要先启动B，再启动A即可。或者先启动A，再30秒之内启动B即可恢复镜像队列

场景2

A、B同时停机

方案2：该场景可能由于机房断电造成的，只需在30秒内连续启动A和B即可恢复镜像

场景3

A先停，B后停，且A无法修复

方案3：该场景是1场景的加强版，因为B是Master，所以B起来以后，在B节点上调用控制台命令：rabbitmqctl forget_cluster_node_A解除与A的Cluster关系，再将新的Slave节点加入B即可重新恢复镜像队列

场景4

A先停、B后停，且B无法恢复

方案4：因为B是主节点，所以直接启动A是不行的。当A无法启动的时候，就没办法在A节点上调rabbitmqctl forget_cluster_node_B了。这就意味着允许rabbitmqctl在理想节点上执行命令，迫使RabbitMQ在未启动Slave节点中选择一个节点作为Master，当在A节点执行rabbitmqctl forget_cluster_node --offline B时，RabbitMQ会模拟一个节点代表A，执行forget_cluster_node命令将B剔除cluster，然后A就可以正常启动了，最后将新的Slave节点加入A即可重新恢复镜像队列

场景5

A先停、B后停，且A、B均无法恢复，但是能得到A或B的磁盘文件

方案5：通过恢复数据的方式去尝试恢复，将A或B的数据库文件默认在$RABBIT_HOME/var/lib中，把他复制到新节点的对应目录下，再将新节点的hostname改为A或B的hostname，如果是得到A节点（slave）的磁盘文件，按照场景4处理，如果得到是B节点（Master）的磁盘文件，按照场景3处理，最后将新的Slave加入新的节点后完成

场景6

A先停、B后停，且A、B均无法恢复，且能得不A或B的磁盘文件

可以洗洗睡啦