查看“RabbitMQ集群恢复与故障转移的5种解决方案”的源代码

=== 场景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：该场景是场景3的加强版，比较难处理，原因是因为Master节点无法恢复，早在3.1x时代之前没有什么好的解决方案，但是现在已经有解决方案了，在3.4.2以后的版本。因为B是主节点，所有直接启动A是不行的，当A无法启动的时候，也就没办法在A节点上调用之前的rabbitmqctl forget_cluster_node B命令了。新版本中forget_cluster_node支持--offline参数

这就意味着允许rabbitmqctl在理想节点上执行该命令，迫使RabbitMQ在未启动Slave节点中选择一个节点作为Master。当在A节点执行 rabbitmqctl forget_cluster_node --offline B时，RabbitMQ会mock一个节点代表A，执行 forget_cluster_node命令将B剔除cluster，然后A就可以正常的启动了，最后将新的Slave节点加入A即可恢复镜像队列

=== 场景5：A先停、B后停，且A、B均无法恢复，但是能得到A或B的磁盘文件 ===
方案5：这种场景更加难处理，只能通过恢复数据的方式去尝试恢复，将A与B的数据文件模式在$RABBIT_HOME/var/lib/目录中，把它拷贝到新的节点对应的mulxia，再将新的节点hostname改成A或B的hostname，如果是A节点（Slave）的磁盘文件，则按照场景4处理即可，如果是B节点（Master）的磁盘文件，则按照场景3处理即可，最后新的Slave加入新节点后完成恢复。

=== 场景6：A先停、B后停，且A、B均无法恢复，且得不到A和B的磁盘文件 ===
解决方案：可以洗洗睡了~没有方案，解决不了！

[[分类:rabbitmq]]