为什么我的 cassandra 集群在重启单个节点时会出现延迟？

Question

我正在运行一个 29 个节点的集群，分布在 EC2 中的 4 个 DC 上，在 Ubuntu 上使用 C* 3.11.1，使用 RF3。有时我需要重启集群中的节点，但每次我都会看到错误和应用程序 (nodejs) 超时。

我像这样重启一个节点：

nodetool disablebinary && nodetool disablethrift && nodetool disablegossip && nodetool drain sudo service cassandra restart

当我这样做时，我经常在我的 nodejs 应用程序中遇到类似这样的超时和错误：

Error: Cannot achieve consistency level LOCAL_ONE

我的查询几乎都是一样的，比如：select * from history where ts > {current_time}（以及 where 子句中的分区键）

错误和超时似乎会在一段时间后自行消失，但这令人沮丧，因为我无法追查自己做错了什么！

我尝试在关闭 cassandra 的步骤之间等待，并且尝试停止、等待，然后启动节点。我注意到的一件事是，即使在nodetool draining 节点之后，在我停止 cassandra 之前，还有与集群中其他节点的开放连接（即查看 netstat 的输出）。我在日志中看不到任何错误或警告。

我注意到的另一件事是，在重新启动节点并看到应用程序延迟后，我还看到我刚刚重新启动的节点看到同一 DC 中的许多其他节点都处于关闭状态（即状态“DN”）。但是，在其他节点上检查 nodetool status 会显示所有节点都正常/正常。对我来说，这可以解释问题 - 节点重新上线，认为它是健康的，但许多其他人不是，所以它从客户端应用程序获取流量。但随后它会收到对属于它认为已关闭的节点的范围的请求，因此它会以错误响应。延迟问题似乎在节点出现故障时大致开始，但在它重新联机并接受连接后会持续很长时间（即 15-20 分钟）。一旦反弹的节点再次显示同一 DC 中的其他节点，它似乎就消失了。

我无法使用 ccm 在本地重现此内容。

我能做些什么来防止这种情况发生？我还应该做些什么来优雅地重新启动集群吗？这可能与 nodejs 驱动程序有关，但我找不到任何可以尝试的东西。

Answer 1

我似乎能够通过发出nodetool disablegossip 作为关闭的最后一步来解决此问题。因此，在重新启动时使用此方法而不是我最初的方法似乎可行（请注意，只有 drain 和 disablegossip 的顺序已切换）：

nodetool disablebinary
nodetool disablethrift
nodetool drain
nodetool disablegossip
sudo service cassandra restart

虽然这似乎可行，但我无法解释原因。在邮件列表中，有人很有帮助地指出 drain 应该 处理 disablegossip 所做的一切，所以我的假设是，首先执行 disablegossip 会导致 drain 然后有问题，只有在启动后才会出现。