Mnesia reports that this RabbitMQ cluster has experienced a network partition.

简介: Mnesia reports that this RabbitMQ cluster has experienced a network partition.

Rabbitmq管理界面上也提示报错:

Network partition detected
Mnesia reports that this RabbitMQ cluster has experienced a network partition. There is a risk of losing data. Please read RabbitMQ documentation about network partitions and the possible solutions.

rabbitmq 脑裂问题,实质上是个网络分区问题, 确切来说是网络不稳定导致的问题。

rabbitmq集群的网络分区容错性不好,在网络比较差的情况下容易出错,最明显的就是脑裂问题了。

不要将你的rabbitmq集群建立在广域网上,除非你使用federation或者shovel等插件。

判定条件

默认情况下,一个节点在60s之内不能连接上另一个节点(可用net_ticktime 参数调整),就判定这个节点挂了。即使之后节点网络又连通了,由于节点都认为对方挂了,所以Mnesia 还是会发送网络分区的情况并且将情况记录在日志中。(许多围绕网络分区的细节都与Mnesia的行为相关。Mnesia是一个分布式数据库管理系统(DBMS),适合于电信和其它需要持续运行和具备软实时特性的Erlang应用,是构建电信应用的控制系统平台开放式电信平台(OTP)的一部分。)

除了网络失败原因,操作系统的挂起和恢复也会导致集群内部节点发生分区, 因为发生挂起的节点不会认为自己已经失败或者不能工作,但是其他节点会这么认为。比如:将节点运行在你的电脑上,你合上电脑;或者你将节点运行在虚拟机里,系统管理程序将节点挂起了。

模拟脑裂故障

  1. 在其中一台服务器上封禁默认的内部通信端口25672:
iptables -A INPUT -p tcp --dport 25672 -j DROP
iptables -A OUTPUT -p tcp --dport 25672 -j DROP
  1. 观察两台服务器的日志,会有如下输出:
  • 节点1
  • 节点2

此时只判定出net_tick_timeout,要等网络恢复之后,即解封25672端口之后才会判定出现网络分区。

  1. 解封25672端口:
iptables -D INPUT 1
iptables -D OUTPUT 1
  1. 两个节点的日志都会提示发生了脑裂:
2021-04-13 01:55:35.219 [error] <0.6318.0> Mnesia(rabbit@pc2): ** ERROR ** mnesia_event got {inconsistent_database, running_partitioned_network, rabbit@pc1}

原因

由于网络问题导致集群出现了脑裂。

正常情况下,通过rabbitmqctl cluster_status命令查看到的信息中partitions那一项是空的,就像这样:

# rabbitmqctl cluster_status
Cluster status of node rabbit@smacmullen ...
[{nodes,[{disc,[hare@smacmullen,rabbit@smacmullen]}]},
 {running_nodes,[rabbit@smacmullen,hare@smacmullen]},
 {partitions,[]}]
...done.

然而当网络分区发生时,会变成这样:

# rabbitmqctl cluster_status
Cluster status of node rabbit@smacmullen ...
[{nodes,[{disc,[hare@smacmullen,rabbit@smacmullen]}]},
 {running_nodes,[rabbit@smacmullen,hare@smacmullen]},
 {partitions,[{rabbit@smacmullen,[hare@smacmullen]},
              {hare@smacmullen,[rabbit@smacmullen]}]}]
...done.

临时手动处理

  1. 在出现问题的节点上执行: rabbitmqctl stop_app
  2. 在出现问题的节点上执行: rabbitmqctl start_app

注意:mq集群不能采用kill -9 杀死进程,否则生产者和消费者不能及时识别mq的断连,会影响生产者和消费者正常的业务处理。

配置脑裂后自动修复

  1. 修改节点的配置文件
    在/etc/rabbitmq下新建rabbitmq.conf,加入
[
 {rabbit,
  [{tcp_listeners,[5672]},
   {cluster_partition_handling, autoheal}
  ]}
]
  1. 若已有配置文件,则直接添加{cluster_partition_handling, autoheal}配置,示例:
    vi /etc/rabbitmq/rabbitmq.config
  2. 重启rabbitmq
    systemctl restart rabbitmq-server
    再次模拟脑裂,发现会通过重启其中一个节点自动恢复此问题:

网络分区处理策略

rabbitmq 提供了3种模式

  1. ignore 默认配置,即分区不做任何处理。要使用这种,就要保证网络高可用,例如,节点都在一个机架上,用的同一个交换机,这个交换机连上一个WAN,保证网络稳定。
  2. pause_minority。优先暂停‘少数派’。就是节点判断自己在不在‘少数派’(少于或者等于集群中一半的节点数),在就自动关闭,保证稳定区的大部分节点可以继续运行。
  3. autoheal, 关闭客户端连接数最多的节点。 这里比较有意思,rabbitmq 会自动挑选一个‘获胜’分区,即连接数最小的,重启其他分区。(如果平手,就选节点多的,如果节点也一致,那就以未知方式挑选‘获胜者’)。这个更关心服务的连续性而不是数据的完整性。


相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
相关文章
|
消息中间件
RabbitMq Virtual host ‘myHost’ experienced an error on node XXXX and may be inaccessible
RabbitMq Virtual host ‘myHost’ experienced an error on node XXXX and may be inaccessible
852 0
RabbitMq Virtual host ‘myHost’ experienced an error on node XXXX and may be inaccessible
|
消息中间件
RabbitMQ Network Partitions 处理策略
网络分区的意义 RabbitMQ的模型类似交换机模型,且采用erlang这种电信网络方面的专用语言实现。RabbitMQ集群是不能跨LAN部署(如果要WAN部署需要采用专门的插件)的,也就是基于网络情况良好的前提下运行的。
1793 0
|
消息中间件 监控
RabbitMQ Network Partitions 服务日志对比
如果你一直使用RabbitMQ作为业务的消息中间件,难免会遇到网络分区(Network Partitions)的故障,也许你当时会束手无策,一脸懵逼,不过希望在看完这篇文章之后,能给你一点解决网络分区的思路。
1670 0
|
消息中间件 API 网络架构
RabbitMQ Network Partitions
Clustering and Network Partitions RabbitMQ clusters do not tolerate network partitions well.
1158 0
|
3月前
|
消息中间件 C语言 RocketMQ
消息队列 MQ操作报错合集之出现"Connection reset by peer"的错误,该如何处理
消息队列(MQ)是一种用于异步通信和解耦的应用程序间消息传递的服务,广泛应用于分布式系统中。针对不同的MQ产品,如阿里云的RocketMQ、RabbitMQ等,它们在实现上述场景时可能会有不同的特性和优势,比如RocketMQ强调高吞吐量、低延迟和高可用性,适合大规模分布式系统;而RabbitMQ则以其灵活的路由规则和丰富的协议支持受到青睐。下面是一些常见的消息队列MQ产品的使用场景合集,这些场景涵盖了多种行业和业务需求。
|
4天前
|
消息中间件 存储 弹性计算
云消息队列RabbitMQ实践
云消息队列RabbitMQ实践
|
6天前
|
消息中间件 安全 Java
云消息队列RabbitMQ实践解决方案评测
一文带你详细了解云消息队列RabbitMQ实践的解决方案优与劣
30 4
|
10天前
|
消息中间件 存储 监控
解决方案 | 云消息队列RabbitMQ实践
在实际业务中,网站因消息堆积和高流量脉冲导致系统故障。为解决这些问题,云消息队列 RabbitMQ 版提供高性能的消息处理和海量消息堆积能力,确保系统在流量高峰时仍能稳定运行。迁移前需进行技术能力和成本效益评估,包括功能、性能、限制值及费用等方面。迁移步骤包括元数据迁移、创建用户、网络打通和数据迁移。
45 4
|
1月前
|
消息中间件 运维 监控
云消息队列RabbitMQ实践解决方案评测报告
本报告旨在对《云消息队列RabbitMQ实践》解决方案进行综合评测。通过对该方案的原理理解、部署体验、设计验证以及实际应用价值等方面进行全面分析,为用户提供详尽的反馈与建议。
62 16
|
1月前
|
消息中间件 弹性计算 运维
阿里云云消息队列RabbitMQ实践解决方案评测报告
阿里云云消息队列RabbitMQ实践解决方案评测报告
57 9