Question

在VM环境中向群集添加节点时，是否存在initial_token碰撞的已知问题？

我正在开发一个在VM上设置的4节点群集。当我们尝试将节点添加到集群时，我们遇到了问题。

在cassandra.yaml文件中，initial_token留空。由于我们正在运行＆gt; 1.0 cassandra，默认情况下auto_bootstrap应为true。

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

这不是我们目前所看到的。我们不想为每个节点手动设置initial_token的值（这样做会破坏动态的目标..）我们还将分区器设置为random：partitioner：org.apache.cassandra.dht.RandomPartitioner

我已经概述了我们遵循的步骤以及我们在下面看到的结果。有人可以请问我们在这里缺少什么吗？

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

1）杀死所有cassandra实例并删除数据＆amp;在每个节点上提交日志文件。

2）启动种子节点（S.S.S.S）

启动很好。

3）运行nodetool -h W.W.W.W 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）X.X.X.X Startup

 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 W.W.W.W 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）Y.Y.Y.Y Startup

 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 W.W.W.W 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）Z.Z.Z.Z Startup

 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 W.W.W.W 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

提前致谢。

Answer 1

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

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

当您添加节点3时，它会在第一个和第二个之间插入令牌，因此您实际上最终将拥有25％，25％，50％的所有权。这非常重要，因为这里要学到的教训是Cassandra永远不会重新分配一个令牌来平衡戒指。如果您希望您的所有权得到适当的平衡，您必须分配自己的令牌。这并不难，并且实际上提供了一个实用程序。

因此Cassandra的初始自举过程虽然是动态的，但可能无法产生所需的环平衡。如果没有一些干预，你不能简单地允许新节点加入，以确保获得所需的结果。否则，您将最终得到您在问题中列出的方案。

Answer 2

这就是我为解决这个问题所做的工作：

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

我用Cassandra 3.7进行了测试。

在VMWare上启动集群中的Cassandra节点时，如何解决节点令牌冲突问题？