我正在运行一个29节点集群，分布在EC2中的4个DC上，使用RF3在Ubuntu上使用C * 3.11.1。偶尔我需要重新启动集群中的节点，但每次我都会看到错误和应用程序（nodejs）超时。
我重启了这样一个节点：
nodetool disablebinary && nodetool disablethrift && nodetool disablegossip && nodetool drain
sudo service cassandra restart
当我这样做时，我经常在我的nodejs app中得到这样的超时和错误：
Error: Cannot achieve consistency level LOCAL_ONE
我的查询几乎完全相同，例如：select * from history where ts > {current_time}（以及where子句中的分区键）
错误和超时似乎会在一段时间后自行消失，但这令人沮丧，因为我无法追踪到我做错了什么！
我已经尝试在关闭cassandra的步骤之间等待，我已经尝试停止，等待，然后启动节点。我注意到的一件事是，即使在nodetool drain节点之后，也有与集群中其他节点的开放连接（即查看netstat的输出），直到我停止cassandra。我没有在日志中看到任何错误或警告。
我注意到的另一件事是，在重新启动节点并看到应用程序延迟之后，我还看到刚刚重新启动的节点看到同一DC中的许多其他节点正在关闭（即状态“DN”）。但是，检查其他节点上的nodetool status会将所有节点显示为up / normal。对我来说，这可以解释这个问题 - 节点重新上线，认为它是健康的，但很多其他的不是，所以它从客户端应用程序获得流量。但是它会收到属于它认为已关闭的节点的范围的请求，因此它会响应错误。延迟问题似乎在节点出现故障时大致开始，但在重新联机并接受连接后会持续很长时间（即15-20分钟）。一旦反弹节点再次显示同一DC中的其他节点，它似乎就会消失。
我无法使用ccm在本地重现此内容。
我该怎么做才能防止这种情况发生？我还应该做些什么来优雅地重启集群？它可能与nodejs驱动程序有关，但我找不到任何可以尝试的东西。
答案 0 :(得分：1)
我似乎能够通过发出nodetool disablegossip作为关闭的最后一步来解决问题。因此，在重新启动时使用此方法而不是我的初始方法似乎有效（请注意，只有drain和disablegossip的顺序已切换）：
nodetool disablebinary
nodetool disablethrift
nodetool drain
nodetool disablegossip
sudo service cassandra restart
虽然这似乎有效，但我没有解释原因。在邮件列表中，有人帮助指出drain 应该处理disablegossip所做的一切，所以我的假设是disablegossip首先做drain然后/html/body/div[3]/div[1]/div[1]/div[1]/div/div
出现问题，这些问题只会在启动后出现。