持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第4天，点击查看活动详情
集群重启顺序
集群重启的顺序是固定的，并且是相反的。
- 启动顺序：磁盘节点 => 内存节点
- 关闭顺序：内存节点 => 磁盘节点
最后关闭必须是磁盘节点，不然可能会造成集群启动失败、数据丢失等异常情况。
常见故障
集群状态异常
rabbitmqctl cluster_status检查集群健康状态，不正常节点重新加入集群- 分析是否节点挂掉，手动启动节点。
- 保证网络连通正常
队列阻塞、数据堆积
- 保证网络连通正常
- 保证消费者正常消费，消费速度大于生产速度
- 保证服务器
TCP连接限制合理
脑裂
- 按正确顺序重启集群
- 保证网络连通正常
- 保证磁盘空间、
cpu、内存足够
镜像队列恢复
前提：两个节点(A和B)组成一个镜像队列。
场景1：A先停，B后停。
该场景下B是master，只要先启动B，再启动A即可。
或者先启动A，再在30秒之内启动B即可恢复镜像队列。
场景2: A, B同时停。
该场景可能是由掉电等原因造成，只需在30秒之内连续启动A和B即可恢复镜像队列。
场景3：A先停，B后停，且A无法恢复。
该场景是场景1的加强版
因为B是master，所以等B起来后，在B节点上调用rabbitmqctl forget_cluster_node A，解除与A的cluster关系，再将新的slave节点加入B即可重新恢复镜像队列。
场景4：A先停，B后停，且B无法恢复。
该场景是场景3的加强版
因为B是master，所以直接启动A是不行的，当A无法启动时，也就没办法在A节点上调用rabbitmqctl forget_cluster_node B了。
新版本中，forget_cluster_node支 持–offline参数，offline参数允许rabbitmqctl在离线节点上执行forget_cluster_node命令，迫使 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的磁盘文件。
该场景是场景4的加强版，更加难处理。
将A或B的数据库文件(默认在$RABBIT_HOME/var/lib目录中)拷贝至新节点C的目录下，再将C的hostname改成A或B的hostname。
如果拷过来的是A节点磁盘文件，按场景4处理方式；
如果拷过来的是B节点磁盘文件，按场景3处理方式。最后将新的slave节点加入C即可重新恢复镜像队列。
场景6：A先停，B后停，且A、B均无法恢复，且无法得到A或B的磁盘文件。
该场景下已无法恢复A、B队列中的内容了。
