Cassandra节点对上/下状态和复制有不同的看法。如何修复？

我有一个由三个节点组成的Cassandra 2.0.1集群，主键空间的复制因子为3。由于集群中额外的四分之一节点的意外错误配置，我尝试先用不必要的“nodetool停用”（在节点db2上）来修复它，然后再执行正确的“nodetool removenode”

现在，运行decommission的db2节点似乎看到另一个节点的状态为“Down”，尽管其他节点认为一切正常。此外，当我在所有节点上运行“nodetool-ring”时，db1会给出“Replicas:2”，其中db2和db3在列表顶部有“Replicas:3”

键空间包含我不想丢失的数据，并且由于一直在插入新数据，因此无法完全关闭集群。在不危及现有数据和新数据的情况下，解决问题的好方法是什么

下面是模糊的nodetool状态输出

[db1 ~]# nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns (effective)  Host ID                               Rack
UN  xx.xx.xx.99    30.38 MB   256     100.0%            cccccccc-cccc-cccc-cccc-cccccccccccc  rack1
UN  xx.xx.xx.122   28.93 MB   256     100.0%            aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa  rack1
UN  xx.xx.xx.123   29.59 MB   256     100.0%            bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb  rack1

[db2 ~]# nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns (effective)  Host ID                               Rack
DN  xx.xx.xx.122   28.93 MB   256     100.0%            aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa  rack1
UN  xx.xx.xx.99    30.38 MB   256     100.0%            cccccccc-cccc-cccc-cccc-cccccccccccc  rack1
UN  xx.xx.xx.123   29.59 MB   256     100.0%            bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb  rack1

[db3 ~]# nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns (effective)  Host ID                               Rack
UN  xx.xx.xx.122   28.93 MB   256     100.0%            aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa  rack1
UN  xx.xx.xx.99    30.38 MB   256     100.0%            cccccccc-cccc-cccc-cccc-cccccccccccc  rack1
UN  xx.xx.xx.123   29.59 MB   256     100.0%            bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb  rack1

---

亚伦·莫顿详细描述了他是如何做到的。您应该检查集群中的流言状态

• 检查nodetool gossipinfo的状态
• 启用以下跟踪日志记录：

  log4j.logger.org.apache.cassandra.gms.Gossiper=TRACE

  log4j.logger.org.apache.cassandra.gms.FailureDetector=TRACE

---

希望您能从中更好地了解集群中正在发生的事情。

谢谢，这为您提供了一些前进的提示。但是还没有解决这个问题，因为它与Aaron的不完全相同，Aaron的还包括Cassandra 1.x，因此在所有方面都不适用于2.0。看起来这个问题自己神奇地解决了。有问题的节点遇到了一些（可能是无关的）硬盘问题，必须重新启动，并重放了一堆提交日志，可能还有一些其他自动修复的东西。尽管症状已经消失，但所有这些背后的原因仍不清楚。我们在生产中面临着同样的问题。我们的集群中有10个节点。当我运行nodetool status时，一个节点显示为DN，但当我再次运行nodetool status时，相同的节点显示为UN。这个问题是一贯的。可能的原因是什么？我确信这个问题不是由于硬盘问题造成的。