问题标签 [splitbrain]

我们在带有 openjdk:14-jdk-slim 图像的 kubernetes 环境中使用 hazelcast 4.2.1。在我们只有两个节点的开发环境中，这两个节点有时（在每 5 次部署后不久）最终会出现脑裂状态并且不会合并，尽管它们会找到彼此并就如何做达成一致：

第一个节点的加入者说第二个节点应该加入。而第二个不应该加入第一个节点的加入者。但什么也没有发生。日志每隔几分钟重复一次，并且不会合并集群。

我们是否使用合并策略并不重要。通常情况下，它可以毫无问题地工作。

第一个节点的日志：

第二个节点的日志：

由于TDengine集群模型的选择规则，我怀疑它是否能有效解决一个简单的脑裂情况。但是，测试结果表明可以成功处理脑裂。所以我需要对其核心机制的细节进行一个很好的解释。

例如，一个 7 节点集群由于物理灾难而分裂为两部分，每个部分中都会选择两个主节点，一旦系统恢复，就会成为单个主节点。

这几天我在测试 TDengine 的脑裂问题，不同的配置阻止了我继续部署集群。为了减少遇到瓶颈的可能性，TDengine不可用的场景需要提前声明。所以想知道除了脑裂或者主选失败，什么情况会导致TDengine集群core dump或者不可用？TDengine集群如何有效保证高可用？

我们有一个ReliableMessageListener通过实现同步它在集群中保存的一些数据结构onMessage。

集群由三个节点组成。我们注意到其中一个主题不同步，并且由于消息丢失而被终止，由环形缓冲区检测到，因为我们得到一个“ Terminating MessageListener, ... Reason: Underlying ring buffer data related to reliable topic is lost”异常。发生的情况是该节点仍处于启动状态，但该特定侦听器没有从其他两个节点获取事件/消息，而他们确实从中获取了事件/消息。

我们对这个特定主题进行了事实上的脑裂。

我们的消息监听器配置为isLossTolerant = false, 和isTerminal = false。

我试图了解什么被认为是处理这种情况并从中恢复的好策略。

例如，再次尝试订阅此主题是一个好习惯吗？发送消息以清除集群中其他节点的数据是一种好习惯吗？在环形缓冲区不同步后，他们甚至会收到消息吗？

谢谢