将节点添加到现有 Cassandra 集群

Question

我们目前有一个 2 节点 Cassandra 集群。我们想使用机架功能向集群添加 4 个节点。未来的拓扑将是：

• node-01 (Rack1)
• node-02 (Rack1)
• node-03 (Rack2)
• node-04 (Rack2)
• node-05 (Rack3)
• node-06 (Rack3)

我们想使用不同的机架，但使用相同的 DC。

但现在我们使用SimpleStrategy 并且所有键空间的复制因子为 1。我从 2 节点集群切换到 6 节点集群的计划如下所示：

1. 将端点告密者更改为GossipingPropetyFileSnitch。
2. 将键空间更改为 NetworkTopologyStrategy...使用 replication_factor 'datacenter1': '3'。

根据文档，当我们向现有集群添加新 DC 时，我们也必须更改系统键空间。但在我们的例子中，我们只改变了告密者和密钥空间策略，而不是数据中心。或者在添加更多节点和更改告密者的情况下，我是否也应该更改系统键空间策略和复制因子？

Answer 1

首先，我将在一个节点上将endpoint_snitch 更改为GossipingPropertyFileSnitch 并重新启动它。首先，您需要确保该方法有效。通常，您不能（轻松）更改正在运行的集群上的逻辑数据中心或机架名称。 技术上你没有这样做，但SimpleStrategy 可能会在后台做一些事情来抽象数据中心/机架感知，所以测试它是个好主意。

如果可行，请进行更改并重新启动另一个节点。如果它不起作用，您可能需要添加 6 个新节点（而不是 4 个）并停用现有的 2 个节点。

或者我也应该更改系统键空间策略和复制因子？

是的，您应该在以下键空间上设置相同的键空间复制定义：system_auth、system_traces 和 system_distributed。

考虑这种情况：如果您的 2 个节点之一崩溃，您将无法以通过 system_auth 表分配给该节点的用户身份登录。因此，确保system_auth 被正确复制是非常重要的。

我前段时间写了一篇关于这个的帖子（2018年更新）：Replication Factor to use for system_auth

另外，我建议在 system_traces 和 system_distributed 上使用相同的方法，因为如果无法找到这些键空间的有效令牌范围，未来的节点添加/替换/修复可能会失败。基本上，对它们使用相同的方法可以防止将来出现潜在问题。

编辑 20200527：

snitch 和 keyspace 拓扑更改后，是否需要在旧集群节点上启动 nodetool cleanup？根据文档“是”，但仅在旧节点上？

您需要在每个节点上运行它，除了最后一个添加的节点。最后一个节点是唯一保证只有与其令牌范围分配匹配的数据的节点。

“为什么？”你可能会问。考虑随着集群从 2 个节点逐渐增长到 6 个节点时的总所有权百分比。如果将 RF 从 1 增加到 2（运行修复），然后从 2 增加到 3 并添加第一个节点，您将拥有一个具有 3 个节点的集群和 3 个副本。然后每个节点都拥有 100% 的数据所有权。

随着每个节点的添加，所有权百分比逐渐降低，当添加第 6 个也是最后一个节点时，所有权百分比会下降到 50%。但即使所有节点都将拥有 50% 的令牌范围：

• 前 3 个节点实际上仍将拥有 100% 的数据集，占应有的额外数据的 50%。
• 第四个节点仍将有额外的 25%（3/4 减去 1/2 或 50%）。
• 第五个节点仍然会有额外的 10%（3/5 减去 1/2）。

因此，第六个也是最后一个节点是唯一一个不会包含比它负责的更多数据的节点。