Cassandra v3.0.9引导程序失败

我们正在运行一个具有近30个节点的Cassandra集群。我们正在将集群扩展到大约40个。集群目前在AWS上运行，位于美国东部地区（1b、1e和1d）

引导的配置：

• 自动引导：true

  （默认）

• -Dcassandra.consistent.rangemovement=false

  （默认）

引导过程似乎已经完成，所有节点都将数据流传输到此新节点。然而，节点似乎仍处于加入状态，引导最终超时（3小时后；

流式传输\u套接字\u超时\u ms

）。这是一种不一致的状态，新节点永远处于

UJ

状态

我尝试了

nodetool引导恢复

，它也会无限期挂起。我选中了

nodetool netstats

，没有一个节点将数据流传输到新节点

现在，由于我知道我拥有属于此节点的所有数据，我尝试在

cassandra.yaml

中添加

auto_bootstrap:false

，然后重新启动

cassandra

过程。我的期望是，添加

auto_bootstrap:false

不会对来自其他节点的流式数据感到烦恼，但我似乎遗漏了一些东西。该节点似乎从其他节点接收数据，引导正在重新开始

我又向前走了一步，尝试添加

-Dcassandra.consistent.rangemovement=false

以及

auto_bootstrap:false

（我这样做是因为我间歇性地得到

RuntimeException

提示

一致地移动数据所需的节点已关闭

，尽管所有节点都是

UN

）。我仍然看到该节点尝试从其他节点流式传输数据。我是不是遗漏了什么

如果有人能帮我，我会非常感激的。如有必要，乐意提供任何其他细节

提前感谢。

1）-Dcassandra.consistent.rangemovement=false应在并行引导多个节点时使用。而且它会破坏一致性。最安全的方法是一次添加一个

2） 如果节点为UJ且未进行流式处理，则流式处理由于某些错误而停止，请检查node system.log，当流式处理正在进行时，当其他节点停止/重新启动时，流式处理也将停止

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