我们使用的是Cassandra3.11.2，在尝试引导一个新节点时，流式传输需要花费大量时间。集群是一个三节点的集群，我们正在添加第四个。其他三个节点上的可用数据接近190gb，示例大小为5核5gb，在旋转驱动器上运行。 nodetool netstats 在新节点上显示流文件，在106个文件中，有15个是从节点a收到的。但还是一样 netstats 在节点a上，所有106个文件都已发送。
另外，我们遇到了一些与保持活动状态相关的问题，并且在新节点上增加了相同的问题。这是我们的第二次尝试，在第一次尝试中，引导程序一直失败，我们要么恢复它，要么重新启动新节点上的cassandra，数据增长到接近500gb，然后压缩发生，下降到236gb。
但是引导程序一直失败。所以我们抛弃了它，重新开始。这次，正如hardware choices文档中建议的那样，我们使用不同的物理磁盘来提交日志和数据，以查看iops是否是问题所在。
这个过程永远不会结束。也就是说，它会在连接被对等端重置或io异常时出现故障，我们已经为此奋斗了近一个星期了。
您认为理想情况下，引导一个数据接近190gb的节点需要多少时间？任何意见/建议都会大有帮助。新节点在auto\u bootstrap标志设置为true时启动。
1条答案
按热度按时间mum43rcc1#
您认为理想情况下，引导一个数据接近190gb的节点需要多少时间？
不幸的是，没有简单的方法来回答这个问题。很多因素决定了新节点引导的速度，基本上是特定于底层infra的。
我们使用的是cassandra 3.11.2
我建议（至少）升级到3.11.4。这是一个简单的二进制升级，不需要运行
nodetool upgradesstables. 原因是，3.11.4有一个特性，允许失败的引导恢复到它停止的地方。至少，你不必每次都从头开始。数据增长到接近500gb，然后压缩到236gb。
所以这是有原因的。机架定义（cassandra rackdc.properties）相同还是不同？如果将节点引导为新的逻辑机架，则可能会看到一个新节点负责拥有100%的可用令牌范围。然而，如果您加入一个与其他节点具有相同逻辑机架的新节点，则所有权百分比（和磁盘占用）将下降。
任何意见/建议都会大有帮助。
在将节点引导到新的物理数据中心时，我也遇到过类似的问题。我成功的一件事就是
auto_bootstrap: false和经营一家nodetool rebuild从远程dc传输。当然，如果你没有另一个直流电，这是行不通的。也可以在不启用引导的情况下启动节点，然后运行
nodetool repair一旦它出现。这有一些缺点，新节点仍将尝试服务于客户端请求，而不管它是否实际拥有数据。但它至少可以让您加入节点，并以更渐进的方式传输数据。这就是为什么升级到3.11.4可能是最好的选择。然后您可以在流失败时重新启动节点，它将从停止的地方恢复，并且在数据流完成之前不会接受客户端请求。