rabbitMQ故障恢复与故障转移

Posted 2023-04-16

参考技术A 以下节点中，A代表主master，B代表从Slave。

重启即可。

启动主节点A，忘掉rabbitmqctl forget_cluster_node B，重新添加新的节点。

在B节点执行rabbitmqctl forget_cluster_node --offline A，此时会在线下踢出A，然后B可以正常启动了，再添加新的节点。

重新建立两个新节点，主机名等都和原来的A或B（取决于哪一个磁盘好着用哪一个的）一样。在原磁盘的$RABBIT_HOME/var/lib/目录拷到新的节点上。如果是A节点磁盘可用，按照情景三；如果是B，则按照情景四。

其他情况，洗洗睡了~

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