cassandra - Cassandra v3.0.9 引导程序失败

Question

我们正在运行一个有近 30 个节点的 Cassandra 集群。我们正在将集群扩展到大约 40 个。该集群目前在us-east1AZ 的 AWS 上运行（1b、1e 和 1d）。

引导配置：

• auto_bootstrap: true（默认）
• -Dcassandra.consistent.rangemovement=false（默认）

引导程序似乎已完成，所有节点都将数据流式传输到这个新节点。然而，节点似乎保持在JOINING状态，并且引导最终超时（3 小时后；streaming_socket_timeout_in_ms）。UJ这是一种不一致的状态，新节点永远卡在状态中。

我试过nodetool bootstrap resume了，它也无限期挂起。我检查了一下nodetool netstats，没有一个节点将数据流式传输到新节点。

现在，由于我知道我拥有属于该节点的所有数据，因此我尝试添加auto_bootstrap: false并cassandra.yaml重新启动cassandra过程。我的期望是添加auto_bootstrap: false不会打扰来自其他节点的流数据，但似乎我在这里遗漏了一些东西。该节点似乎从其他节点接收数据，并且引导重新开始。

我又向前迈进了一步，并尝试添加-Dcassandra.consistent.rangemovement=falsewith auto_bootstrap: false（我这样做是因为我间歇性地得到RuntimeException建议A node required to move the data consistently is down，尽管所有节点都是UN）。我仍然看到该节点尝试从其他节点流式传输数据。我在这里错过了什么吗？

如果有人可以在这里帮助我，我将不胜感激。如有必要，乐于提供任何其他细节。

提前致谢。

标签： cassandracassandra-3.0

Answer 1

1)-Dcassandra.consistent.rangemovement=false 应该在并行引导多个节点时使用。它可能会违反一致性。最安全的方法是一次添加一个。

2）如果节点是UJ并且没有流式传输，那么由于某些错误而停止了流式传输，请检查节点system.log，流式传输也会在其他节点在流式传输过程中停止/重新启动时停止。

3）您可以删除数据并重新启动将再次开始流式传输数据的节点。节点为联合国后，检查“nodetool compactionstats”。待压缩过程完成后，在每个节点上依次运行“nodetool repair -pr”和“nodetool cleanup”。