cassandra - 新节点引导程序的问题

Question

我们使用的是 Cassandra 3.11.2，当尝试引导一个新节点时，流式传输需要很多时间。该集群是一个三节点，我们正在添加第四个节点。其他三个节点上可用的数据接近 190GB，实例大小为 5 核，5GB 在旋转驱动器上运行。

nodetool netstats在新节点上说流文件，在 106 个文件中，有 15 个是从节点 A 收到的。但netstats在节点 A 上同样声称所有 106 个文件都已发送。

此外，我们遇到了一些与保持活动相关的问题，我们确实在新节点上增加了相同的问题。这是我们的第二次尝试，在第一次尝试中，bootstrap 一直失败，我们要么恢复它，要么在新节点上重新启动 Cassandra，数据增长到接近 500GB，然后发生压缩并下降到 236GB。

但随后引导程序一直失败。所以我们放弃了它，重新开始。这一次，正如硬件选择文档中所建议的那样，我们使用不同的物理磁盘来存储提交日志和数据，以查看 iops 是否是问题所在。

这个过程永远不会结束。意思是，它在对等或 IO 异常重置连接之间失败，我们已经为此苦苦挣扎了将近一周。

您认为引导一个数据接近 190GB 的节点理想情况下需要多少？任何建议/建议都会有很大帮助。新节点启动时将 auto_bootstrap 标志设置为 true。

标签： cassandra

Answer 1

您认为引导一个数据接近 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可能是您的最佳选择。然后，您可以在流失败时重新启动节点，它会从中断的地方重新开始，并且在数据流完成之前不会接受客户端请求。