更新 - 简短版本：
前3个节点（机架1-3）的 PropertyFileSnitch cassandra-topology.properties表明只有这些节点在DC1中，而其他节点在DC2中，通过指定默认值default=DC2:r1。当通过添加节点4和5来扩展集群时，这些节点的 PropertyFileSnitch 被配置为在DC1以及机架4和5中添加它们，但来自前3个节点的告警保持不变并且结果集群处于此不一致状态。
我的问题是否可以重新平衡（修复）此群集。如果我在修复cassandra-topology.properties后完成了一次完整的群集重启就足够了吗？
请告知我如何安全重新平衡群集。
更长的版本：
我是Cassandra的新手，我开始研究已经建成的集群
我在运行带有 vnodes num_tokens: 256的Cassandra 3.0.5版本和带有replication = {'class': 'NetworkTopologyStrategy', 'DC1': '3'} AND durable_writes = true的密钥空间的不同机架上的同一数据中心有5个节点。
从历史上看，只有3个节点，并且通过额外的2个节点扩展了集群。我有一个自动修复脚本，使用选项nodetool repair运行parallelism: parallel, primary range: false, incremental: true, job threads: 1。
插入大量数据后，问题就开始出现了。在节点4或5上运行修复脚本时，节点2会过载：CPU使用率保持在100％，MutationStage队列增长，GC暂停至少需要1秒，直到Cassandra进程最终死亡。修复结果通常为failed with error Stream failed (progress: 0%)。
在节点1,2或3上运行nodetool status命令时，我得到以下输出：
Datacenter: DC2 Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.0.13 10.68 GB 256 0.0% 75e17b8a r1 UN 10.0.0.14 9.43 GB 256 0.0% 21678ddb r1 Datacenter: DC1 Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.0.10 16.14 GB 256 100.0% cf9d327f Rack1 UN 10.0.0.11 22.83 GB 256 100.0% e725441e Rack2 UN 10.0.0.12 19.66 GB 256 100.0% 95b5c8e3 Rack3
但是当在节点4或5上运行nodetool status命令时，我得到以下输出：
Datacenter: DC1 Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.0.0.13 10.68 GB 256 58.9% 75e17b8a Rack4 UN 10.0.0.14 9.43 GB 256 61.1% 21678ddb Rack5 UN 10.0.0.10 16.14 GB 256 60.3% cf9d327f Rack1 UN 10.0.0.11 22.83 GB 256 61.4% e725441e Rack2 UN 10.0.0.12 19.66 GB 256 58.3% 95b5c8e3 Rack3
经过进一步调查后，似乎在群集扩展后， PropertyFileSnitch cassandra-topology.properties未在节点1,2和3（这也是此群集的种子）上更新。
谢谢！
答案 0 :(得分：1)
在搜索了几个在线资源后，我找到了一些可能的解决方案。我将它们发布在这里，以便每个人都可以访问它。
来自 Practical Cassandra：开发人员的方法：
节点之间的环视图不同
当环视图不同时 节点，从来都不是一件好事。还有一种简单的方法可以恢复 来自这个州。恢复的唯一方法是执行完整群集 重新开始。滚动重启不起作用，因为Gossip协议来自 坏节点将通知新引导的坏节点 州。完整集群重新启动并首先启动好节点 应该使群集恢复状态良好。
同样的解决方案也可以在 DataStax文档中找到：View of ring differs between some nodes
我在Apache Cassandra Community上也发现了类似的问题。社区用户线程的答案是：
发生的事情是你现在有两个数据中心 簇。他们复制信息的方式取决于你的 键空间设置。关于你的过程，我不认为它是安全的 这样做。我开始退出节点4和5，以便这样做 您的群集返回到包含3个节点的1个数据中心，然后添加它们 再次确保Snitch中的配置是 适当的。
答案 1 :(得分：0)
如果不访问系统，我无法判断你的建议是否足够，但我有一些观察。所有权应在群集中的所有节点之间分配。这意味着＆＃34; Owns＆＃34;下的所有值的总和。如果它们形成一个簇，则所有5个节点的选项卡应该等于100。让几个节点拥有100％的集群看起来并不正确。这表示每个节点都以独立模式运行，并且未加入群集。
我在第一次打印输出时看到地址10.40.0.10，在第二次打印输出时看到10.0.0.10。看起来像是一个配置错误。此外，检查每个节点是否可以到达所有其他节点的IP地址。我看到10.0.0.13属于＆＃39; r1＆＃39;在第一次打印输出时，它属于＆＃39; Rack4＆＃39;在第二。
为了简单和易于配置，您可以为所有5个节点配置一个数据中心（例如DC1）和一个机架（例如Rack1），无论其物理分布如何。