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