我正在运行一个包含两个节点的 RabbitMQ 集群（版本 3.0.2，Erlang R15B），它们继续定期遇到网络分区错误。它们物理上位于同一个数据中心，它们的网络应该是可靠的。当我检查它们的日志时，两个服务器大约同时报告“running_partitioned_network”错误，并且两个节点继续运行，所以我不认为这是硬件故障或其中一个节点意外终止。我将 net_ticktime 修改为 120 秒以尝试缓解该问题，并且它在近一个月内停止发生，但最近它每隔几天又开始发生一次。现在我不确定 net_ticktime 是否有帮助，或者这只是巧合。
为了进一步排除故障，我使用 Wireshark 启动了滚动网络跟踪，并使用计划任务在节点再次分区时停止跟踪。我的目标是确定分区是由不可靠的网络引起的，还是应用程序无法响应。数据包跟踪中没有任何内容显示网络故障，只有少数 TCP 重新传输，并且它们之间成功发送了许多其他数据包。
此时，我不确定在数据包跟踪中还要查看什么才能证明或反驳网络导致故障。Wireshark 可以识别和解码 Erlang 分发协议，但我不知道如何解释消息以了解是什么导致节点检测到分区。此外，net_ticktime 设置为 120 秒，我没有看到服务器之间相互接收消息的 120 秒间隔。没有从其他服务器接收到 Erlang 消息的最长间隔是 22 秒（如果算上 TCP 确认，则要少得多）。我唯一的另一个想法是，如果需要在节点之间发送特定的“ping”类型消息，并且该特定消息被中断，但我不知道在跟踪中会是什么样子。
关于如何进一步诊断该问题原因的任何想法都会有所帮助。
答案1
我不确定情况是否真的如此，但似乎在传递大消息时 Erlang 集群可能会中断。请查看 RabbitMQ 讨论邮件列表中的此主题：http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/2012-March/018745.html
答案2
我在 Erlang R14B03 上的 RabbitMQ 2.8.4 中也看到过类似的问题，不过不可否认的是没有“running_partitioned_network”消息。我们这几个月都没遇到过这种情况（是的，这种情况发生的次数很多，我们有一个 Nagios check_rabbitmq_splitbrain 检查），但如果这种情况再次发生，我会看看能否捕捉到一些细节...