我们有一个使用4.0.1版本运行的群集。此版本中的停用过程存在问题。问题是在将数据流竞争到群集中的副本后，停用会卡住。即使在12小时后，节点状态仍显示正在离开，并且许多压缩请求在节点中排队。我们在从3.11版本升级4.0.1后观察到了此问题。有人遇到过这种问题吗？如果是，解决方案是什么？我尝试了多种方法，但仍然是相同的。谁能检查并回答这个问题？
问候你，Mani
我试过这个https://support.datastax.com/s/article/Node-stuck-in-LEAVING-state-after-being-decommissioned，但它不工作.
1条答案
按热度按时间ax6ht2ek1#
如果
nodetool netstats输出中的流显示为100%，则意味着节点正在等待接收副本确认完成。延迟的一个常见原因是架构中定义了多个索引。如果是这种情况，则接收副本仍忙碌索引流到它们的数据，因此它们不会向源节点（正在停用的节点）发送确认，并且流尚未被视为完成。
您可以通过运行
nodetool compactionstats来检查接收副本上的索引进度。所有接收副本必须在源节点上的所有流被认为完成之前确认完成。干杯！👉 请将鼠标悬停在cassandra标签上，然后单击
Watch tag按钮，以支持Apache Cassandra社区。🙏谢谢！