将节点添加到现有的Cassandra集群

时间:2020-05-26 10:20:51

标签: cassandra cassandra-3.0

我们目前有一个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. 将Endpoint snitch更改为GossipingPropetyFileSnitch
  2. 使用复制因子NetworkTopologyStrategy将键空间更改为'datacenter1': '3'

根据文档,当我们向现有集群添加新的DC时,我们也必须更改系统键空间。但是在本例中,我们仅更改了snitch和keyspace策略,而不更改了Datacenter。还是在添加更多节点并更改密探的情况下也应该更改系统键空间策略和复制因子?

1 个答案:

答案 0 :(得分:0)

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

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

还是我也应该更改系统键空间策略和复制因子?

是的,您应该在以下键空间上设置相同的键空间复制定义:system_authsystem_tracessystem_distributed

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

不久前,我为此撰写了一篇文章(于2018年更新):Replication Factor to use for system_auth

此外,我建议在system_tracessystem_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)。

因此,第六个也是最后一个节点,它将包含的数据超出其负责的范围。