Cassandra：添加节点花费的时间太长

Question

我有一个集群，由四个环中的节点组成，每个 DC 一个。我正在向其中一个 DC 添加一个新节点，但它花费的时间太长。我使用的是 3 的 RF，并且只有一个键空间。我正在使用 cassandra 2.0.11。几个问题：

在“nodetool netstats”中，我看到新节点也在从其他数据中心的节点中提取数据，而不仅仅是它所属的节点。鉴于其 DC 中的节点拥有所有数据，为什么会这样？

是否要求集群在添加新节点时必须处于完美状态，不需要任何修复？这可能是节点从其他 DC 中的节点拉取数据的原因吗？

我已使用“nodetool setthroughput”将流吞吐量设置为 0，但我看到该节点仅以大约 350kb/s 的速度接收数据。我能做些什么来加快速度吗？在过去的 1 天里，我看到节点只收到了大约 2GB 的数据（如 nodetool 状态中所见），它还有另外 10GB 的数据要处理，所以你可以看到它需要很长时间。这是正常的吗？

在引导的节点上，“nodetool netstats”显示它正在从其他节点接收文件，但在所有其他节点上我看到“不发送任何流”。这是正常的吗？

最后，是否可以在引导节点完全加入集群之前重新启动引导节点？我想尝试更改一些需要重新启动的设置，但我想知道引导程序流是否会从重新启动前离开的位置继续。

谢谢

Answer 1

我将尝试在线回答您的问题，希望这些能有所帮助：

在“nodetool netstats”中，我看到新节点也在从其他数据中心的节点中提取数据，而不仅仅是它所属的节点。鉴于其 DC 中的节点拥有所有数据，为什么会这样？

这取决于很多事情；密钥空间复制设置、种子列表（每个 DC 应该至少有一个节点）和集群的修复状态（即仅在远程 DC 中的密钥）。

是否要求集群在添加新节点时必须处于完美状态，不需要任何修复？这可能是节点从其他 DC 中的节点拉取数据的原因吗？

不，集群状态不必是完美的，但是是的，您是对的，这可能是节点可能从远程 DC 流式传输的原因

我已使用“nodetool setthroughput”将流吞吐量设置为 0，但我看到该节点仅以大约 350kb/s 的速度接收数据。我能做些什么来加快速度吗？

设置此值应该取消限制流式传输您是正确的。可能有很多因素导致这没有达到全部带宽，也许有计划的修复正在进行，或者其他流量，例如客户端应用程序同时向集群读取或写入数据？这也可能意味着压缩落后，您可以nodetool tpstats在当时查看线程池统计信息，以查看节点是否忙于执行诸如压缩之类的事情。

在过去的 1 天里，我看到节点只收到了大约 2GB 的数据（如 nodetool 状态中所示），它还有另外 10GB 的数据，所以你可以看到它需要很长时间。这是正常的吗？

一般来说没有。当我看到诸如缓慢引导之类的事情时，它通常会受到 CPU 或磁盘吞吐量等硬件的影响。您的节点是否使用本地磁盘？它们是 SSD 还是 HDD？您是否使用网络附加存储？

在引导的节点上，“nodetool netstats”显示它正在从其他节点接收文件，但在所有其他节点上我看到“不发送任何流”。这是正常的吗？

旧版本的 Cassandra 已经出现了一些引导问题，其中流式传输可能会“挂起”，如果可能，最好尝试为您的发布流获取最新版本并重新检查。

最后，是否可以在引导节点完全加入集群之前重新启动引导节点？我想尝试更改一些需要重新启动的设置，但我想知道引导程序流是否会从重新启动前离开的位置继续。

每次启动过程时，引导都会从头开始。重新启动一个节点将停止原来的引导过程并从头开始。请注意，数据文件将被重新流式传输，因此您最终可能会在节点上获得多余的数据。最好在再次引导之前清除数据目录。

如果节点不引导，您始终可以auto_bootstrap: false在cassandra.yaml文件中进行设置，然后再运行修复。