Question

我们在具有NetworkTopologyStrategy，复制因子为3和EC2Snitch的aws上运行了一个6节点的cassandra 1.2.10集群。每个AWS可用区域中都有2个节点。

当我们使用Quorum的一致性向集群读取或写入数据时，我们发现'可能没有足够的副本来处理一致性级别“。

这没有意义，因为我们只关闭了一个节点，我们的RF为3，所以即使我们用一个法定读/写节点关闭一个节点，仍然应该有足够的数据节点（2）。

查看我们没有退役的服务器上的cassandra日志，我们在另一个节点停用期间看到了这一点。

 INFO [GossipTasks:1] 2013-10-21 15:18:10,695 Gossiper.java (line 803) InetAddress /10.0.22.142 is now DOWN
 INFO [GossipTasks:1] 2013-10-21 15:18:10,696 Gossiper.java (line 803) InetAddress /10.0.32.159 is now DOWN
 INFO [HANDSHAKE-/10.0.22.142] 2013-10-21 15:18:10,862 OutboundTcpConnection.java (line 399) Handshaking version with /10.0.22.142
 INFO [GossipTasks:1] 2013-10-21 15:18:11,696 Gossiper.java (line 803) InetAddress /10.0.12.178 is now DOWN
 INFO [GossipTasks:1] 2013-10-21 15:18:11,697 Gossiper.java (line 803) InetAddress /10.0.22.106 is now DOWN
 INFO [GossipTasks:1] 2013-10-21 15:18:11,698 Gossiper.java (line 803) InetAddress /10.0.32.248 is now DOWN

最终我们看到的消息看起来像这样。

 INFO [GossipStage:3] 2013-10-21 15:18:19,429 Gossiper.java (line 789) InetAddress /10.0.32.248 is now UP

表示每个节点。因此，群集中的其余节点最终会恢复生机。

当这些节点关闭时，我可以看到为什么我们得到“可能不够复制......”的消息。因为一切都失败了。

我的问题是为什么八卦关闭这些节点，我们首先没有退役？

Answer 1

Gossip正在关闭，因为没有从对等方收到几条心跳消息。通常这是由于主机上的过度调度。 CPU，网络或磁盘可能会负担过重。

在DataStax，我们正致力于使Gossip状态机在此场景和其他场景中更加强大。如果您是DataStax客户，请打开技术支持的票证，以获得跟踪和最快的解决方案。

在群集中停用一个EC2节点会导致其他节点进入DOWN / UP状态并导致“可能没有足够的副本...”

1 个答案: