RabbitMQ集群恢复与故障转移的5种解决方案
Posted
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了RabbitMQ集群恢复与故障转移的5种解决方案相关的知识，希望对你有一定的参考价值。
参考技术A 前提：比如两个节点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：该场景是场景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的磁盘文件
恩，你可以直接跑路了o(╯□╰)o
以上是关于RabbitMQ集群恢复与故障转移的5种解决方案的主要内容，如果未能解决你的问题，请参考以下文章