我们正在使用Cassandra 3.11.2，并且在尝试引导新节点时，流传输会花费大量时间。集群是一个三节点的集群，我们正在添加第四个集群。在其他三个节点上可用的数据接近190GB，实例大小为5核，在旋转驱动器上运行的5GB。
新节点上的 nodetool netstats表示流文件，在106个文件中，有15个是从节点A接收的。但是节点A上的相同netstats声称所有106个文件都已发送。
此外，我们遇到了一些与保持生命相关的问题，我们确实在新节点上增加了同样的问题。这是我们的第二次尝试，并且在第一次尝试中，引导程序一直失败，我们要么恢复它，要么在新节点上重新启动Cassandra，数据增长到接近500GB，然后进行压缩，降低到236GB。 / p>
但是随后引导程序一直失败。因此，我们将其丢弃并重新开始。这次，按照硬件选择文档中的建议，我们使用了另一个物理磁盘来提交日志和数据，以查看是否存在iops。
这个过程永远不会结束。意思是，它在通过对等节点或IO异常重置连接之间失败，并且我们为此付出了将近一个星期的努力。
您认为引导数据接近190GB的节点理想情况下需要多少费用？任何建议/建议都会有很大帮助。 新节点是在auto_bootstrap标志设置为true的情况下启动的。
答案 0 :(得分：0)
您认为引导一个接近190GB数据的节点理想情况下需要多少费用？
不幸的是，没有简单的方法来回答这个问题。许多因素决定了新节点的启动速度，这基本上是针对基础设施的。
我们正在使用Cassandra 3.11.2
我建议至少（至少）升级到3.11.4。这是一个简单的二进制升级，不需要运行nodetool upgradesstables。原因是3.11.4具有一项功能，该功能允许失败的自举重新开始。至少到那时，您不必每次都重新开始。
数据增长到接近500GB，然后进行压缩，降至236GB。
所以有某些原因可能导致这种情况发生。机架定义（cassandra-rackdc.properties）是相同还是不同？如果您将节点引导为一个新的逻辑机架，则可能会看到一个新节点负责拥有100％的可用令牌范围。而如果您使用与其他逻辑机架相同的逻辑机架加入新节点，则所有权百分比（和磁盘占用空间）将下降。
任何建议/建议都会有很大帮助。
在将节点引导到新的物理数据中心时，我也遇到过类似的问题。我成功的一件事是设置auto_bootstrap: false并运行nodetool rebuild以从远程DC流式传输。当然，如果您没有其他DC可用于流式传输，那就行不通了。
您也可以在未启用引导程序的情况下启动节点，并在出现nodetool repair后运行它。这具有一些缺点，即无论新节点是否实际具有数据，它都将仍然尝试服务于客户端请求。但这至少可以让您加入节点，并逐步地传输数据。
这就是为什么升级到3.11.4 可能是您最好的选择。然后，当流失败时，您可以重新启动该节点，它将在中断的地方重新开始，并且在数据流完成之前它不会接受客户端请求。