不平衡的 Cassandra 集群

Question

更新 - 短版：
前 3 个节点（机架 1-3）的 PropertyFileSnitchcassandra-topology.properties 通过指定默认值 default=DC2:r1 声明只有这些节点位于 DC1 中，其他节点位于 DC2 中。当通过添加节点 4 和 5 扩展集群时，这些节点的 PropertyFileSnitch 配置为将它们添加到 DC1 以及机架 4 和 5 中，但来自前 3 个节点的告密者保持不变，并且作为结果集群处于这种不一致的状态。

我的问题是这个集群是否可以重新平衡（固定）。如果我在修复 cassandra-topology.properties 后重新启动整个集群就足够了吗？
请告知我如何安全地重新平衡集群。

加长版：

我是 Cassandra 的新手，我开始使用已经构建的集群。
我在不同机架上的同一数据中心有 5 个节点，运行 Cassandra 版本 3.0.5，vnodes num_tokens: 256 和一个带有 replication = {'class': 'NetworkTopologyStrategy', 'DC1': '3'} AND durable_writes = true 的键空间。
从历史上看，只有 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 命令时，我得到以下输出：

数据中心：DC2 状态=向上/向下 |/ 状态=正常/离开/加入/移动 -- 地址加载令牌拥有（有效）主机 ID 机架 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 数据中心：DC1 状态=向上/向下 |/ 状态=正常/离开/加入/移动 -- 地址加载令牌拥有（有效）主机 ID 机架 UN 10.0.0.10 16.14 GB 256 100.0% cf9d327f 机架 1 UN 10.0.0.11 22.83 GB 256 100.0% e725441e 机架 2 UN 10.0.0.12 19.66 GB 256 100.0% 95b5c8e3 机架3

但是在节点 4 或 5 上运行 nodetool status 命令时，我得到以下输出：

数据中心：DC1 状态=向上/向下 |/ 状态=正常/离开/加入/移动 -- 地址加载令牌拥有（有效）主机 ID 机架 UN 10.0.0.13 10.68 GB 256 58.9% 75e17b8a 机架4 UN 10.0.0.14 9.43 GB 256 61.1% 21678ddb 机架5 UN 10.0.0.10 16.14 GB 256 60.3% cf9d327f 机架 1 UN 10.0.0.11 22.83 GB 256 61.4% e725441e 机架 2 UN 10.0.0.12 19.66 GB 256 58.3% 95b5c8e3 机架3

经过进一步调查，集群扩大后，PropertyFileSnitchcassandra-topology.properties 似乎没有在节点 1、2 和 3（这也是该集群的种子）上更新。 p>

谢谢！

Answer 1

如果不访问系统，我无法判断您的建议是否足够，但我有一些观察。所有权应该分布在集群中的所有节点之间。这意味着所有 5 个节点的“Owns”选项卡下所有值的总和应该等于 100，如果它们正在形成一个集群。让几个节点拥有 100% 的集群看起来不正确。这表明每个节点都以独立模式运行，并且未加入集群。
我在第一个打印输出中看到地址 10.40.0.10，而在第二个打印输出中看到地址 10.0.0.10。看起来像一个错误的配置。此外，检查每个节点是否可以访问所有其他节点的 IP 地址。我在第一个打印输出中看到 10.0.0.13 属于“r1”，而在第二个打印输出中它属于“Rack4”。
为了简化配置，您可以为所有 5 个节点配置一个数据中心（例如 DC1）和一个机架（例如 Rack1），无论其物理分布如何。

Answer 2

在搜索了几个在线资源后，我找到了一些可能的解决方案。我会将它们发布在这里，以便所有人都可以访问。

来自实用 Cassandra：开发人员的方法：

节点之间的环视图不同
当环视图不同时 节点，从来都不是一件好事。也没有简单的方法可以恢复 从这个状态。恢复的唯一方法是做一个完整的集群 重新开始。滚动重启不起作用，因为 Gossip 协议来自 坏节点将通知新启动的好节点坏节点 状态。一个完整的集群重新启动并首先启动好的节点 应该能让集群恢复到良好的状态。

同样的解决方案也可以在 DataStax 文档中找到：View of ring differs between some nodes

我还在Apache Cassandra Community 上发现了一个类似的问题。社区用户线程上的答案是：

发生的事情是，您现在有两个数据中心 簇。他们复制信息的方式将取决于您的 键空间设置。关于你的过程，我认为不安全 那样做。我将从停用节点 4 和 5 开始，以便 您的集群返回到具有 3 个节点的 1 个数据中心，然后添加它们 再次依次确保 Snitch 中的配置是 合适的。