3

在 VM 环境中将节点添加到集群时,是否存在有关 initial_token 冲突的任何已知问题?

我正在研究在 VM 上设置的 4 节点集群。当我们尝试将节点添加到集群时,我们遇到了问题。

在 cassandra.yaml 文件中,initial_token 留空。由于我们正在运行 > 1.0 的 cassandra,因此 auto_bootstrap 默认应该为 true。

据我了解,集群中的每个节点都应在启动时分配一个初始令牌。

这不是我们目前看到的。我们不想为每个节点手动设置 initial_token 的值(有点违背动态的目标。)我们还将分区器设置为随机:partitioner: org.apache.cassandra.dht.RandomPartitioner

我已经概述了我们遵循的步骤和我们在下面看到的结果。有人可以告知我们在这里缺少什么吗?

以下是我们正在采取的详细步骤:

1)杀死所有cassandra实例并删除每个节点上的数据和提交日志文件。

2)启动种子节点(SSSS)

启动良好。

3) 运行 nodetool -h WWWW ring 并查看:

Address         DC          Rack        Status State   Load            Effective-Ownership Token
S.S.S.S         datacenter1 rack1       Up     Normal  28.37 GB        100.00%             24360745721352799263907128727168388463

4) XXXX 启动

 INFO [GossipStage:1] 2012-11-29 21:16:02,194 Gossiper.java (line 850) Node /X.X.X.X is now part of the cluster
 INFO [GossipStage:1] 2012-11-29 21:16:02,194 Gossiper.java (line 816) InetAddress /X.X.X.X is now UP
 INFO [GossipStage:1] 2012-11-29 21:16:02,195 StorageService.java (line 1138) Nodes /X.X.X.X and /Y.Y.Y.Y have the same token 113436792799830839333714191906879955254.  /X.X.X.X is the new owner
 WARN [GossipStage:1] 2012-11-29 21:16:02,195 TokenMetadata.java (line 160) Token 113436792799830839333714191906879955254 changing ownership from /Y.Y.Y.Y to /X.X.X.X

5) 运行 nodetool -h WWWW ring 并查看:

Address         DC          Rack        Status State   Load            Effective-Ownership Token
                                                                                           113436792799830839333714191906879955254
S.S.S.S         datacenter1 rack1       Up     Normal  28.37 GB        100.00%             24360745721352799263907128727168388463
W.W.W.W         datacenter1 rack1       Up     Normal  123.87 KB       100.00%             113436792799830839333714191906879955254

6) YYYY 启动

 INFO [GossipStage:1] 2012-11-29 21:17:36,458 Gossiper.java (line 850) Node /Y.Y.Y.Y is now part of the cluster
 INFO [GossipStage:1] 2012-11-29 21:17:36,459 Gossiper.java (line 816) InetAddress /Y.Y.Y.Y is now UP
 INFO [GossipStage:1] 2012-11-29 21:17:36,459 StorageService.java (line 1138) Nodes /Y.Y.Y.Y and /X.X.X.X have the same token 113436792799830839333714191906879955254.  /Y.Y.Y.Y is the new owner
 WARN [GossipStage:1] 2012-11-29 21:17:36,459 TokenMetadata.java (line 160) Token 113436792799830839333714191906879955254 changing ownership from /X.X.X.X to /Y.Y.Y.Y

7) 运行 nodetool -h WWWW ring 并查看:

Address         DC          Rack        Status State   Load            Effective-Ownership Token
                                                                                           113436792799830839333714191906879955254
S.S.S.S         datacenter1 rack1       Up     Normal  28.37 GB        100.00%             24360745721352799263907128727168388463
Y.Y.Y.Y         datacenter1 rack1       Up     Normal  123.87 KB       100.00%             113436792799830839333714191906879955254

8) ZZZZ 启动

 INFO [GossipStage:1] 2012-11-30 04:52:28,590 Gossiper.java (line 850) Node /Z.Z.Z.Z is now part of the cluster
 INFO [GossipStage:1] 2012-11-30 04:52:28,591 Gossiper.java (line 816) InetAddress /Z.Z.Z.Z is now UP
 INFO [GossipStage:1] 2012-11-30 04:52:28,591 StorageService.java (line 1138) Nodes /Z.Z.Z.Z and /Y.Y.Y.Y have the same token 113436792799830839333714191906879955254.  /Z.Z.Z.Z is the new owner
 WARN [GossipStage:1] 2012-11-30 04:52:28,592 TokenMetadata.java (line 160) Token 113436792799830839333714191906879955254 changing ownership from /Y.Y.Y.Y to /Z.Z.Z.Z

9) 运行 nodetool -h WWWW ring 并查看:

Address         DC          Rack        Status State   Load            Effective-Ownership Token
                                                                                           113436792799830839333714191906879955254
W.W.W.W         datacenter1 rack1       Up     Normal  28.37 GB        100.00%             24360745721352799263907128727168388463
S.S.S.S         datacenter1 rack1       Up     Normal  28.37 GB        100.00%             24360745721352799263907128727168388463
Z.Z.Z.Z         datacenter1 rack1       Up     Normal  123.87 KB       100.00%             113436792799830839333714191906879955254

提前致谢。

4

2 回答 2

3

显然,您的节点保留了一些过去在启动时使用的集群信息。确保删除 LocationInfo 目录,其中包含有关集群的数据。你有一个非常奇怪的令牌布局(例如,0 令牌在哪里?),所以如果你想要正确的所有权,你肯定需要重新分配它们。

它可能有助于解释令牌分配的工作原理,所以让我也解决这个问题。在一个全新的集群中,默认情况下第一个节点将获得分配的令牌 0,并将拥有 100% 的所有权。如果您没有为下一个节点指定令牌,Cassandra 将计算一个令牌,使得原始节点拥有较低的 50%,新节点拥有较高的 50%。

当您添加节点 3 时,它将在第一个和第二个之间插入令牌,因此您实际上最终会获得看起来像 25%、25%、50% 的所有权。这非常重要,因为这里要学习的教训是 Cassandra 永远不会自己重新分配令牌来平衡环。如果您希望正确平衡所有权,则必须分配自己的代币。这并不难做到,实际上提供了一个实用程序来做到这一点。

因此,Cassandra 的初始引导过程虽然是动态的,但可能无法产生所需的环平衡。您不能简单地允许新节点在没有一些干预的情况下随意加入,以确保您获得所需的结果。否则,您最终会遇到您在问题中提出的方案。

于 2012-12-05T14:58:45.813 回答
2

这就是我为解决这个问题所做的:

  1. 停止 Cassandra 服务
  2. auto_bootstrap: false在种子节点上设置。
  3. 空数据和提交日志目录: sudo rm -rf /var/lib/cassandra/data/* sudo rm -rf /var/lib/cassandra/commitlog/*
  4. 然后重启服务

我用 Cassandra 3.7 对此进行了测试。

于 2016-08-30T08:11:34.900 回答