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 回答