正如标题所述，我们的 Cassandra 集群出现了问题。9 个节点和复制因子为 3使用网络拓扑策略. 全部在同一个 DC 和 Rack 中。Cassandra 版本是3.11.4（计划于 3.11.10 迁移）。实例有4 CPU和32 GB 内存. （计划迁移至 8 CPU）
每当我们尝试在集群上运行修复时（在其中一个节点上使用 Cassandra Reaper），我们都会在此过程中丢失一个节点。我们迅速停止修复，在节点上重新启动 Cassandra 服务并等待它加入环。因此，这些天我们再也无法运行修复了。
我观察了这个问题，并意识到这个问题是由于我们某些节点的 CPU 使用率过高造成的（正好 3）。您可以在下面看到 1 周间隔的图表。波动是由应用程序的使用引起的。早上，波动非常低。
我比较了每个节点上运行的进程，高 CPU 节点上没有任何额外内容。我比较了配置。它们完全相同。找不到任何差异。
我还意识到这些节点是占用大部分流量的节点。请参见下面的 1 周间隔图。已发送和已接收的字节。
我做了一些研究。我发现这线程，最后建议dynamic_snitch: false在 Cassandra 配置中设置。我查看了我们的告密策略，它是闲话房产文件告密者。实际上，这个策略应该能够正常工作，但我猜它并没有起作用。
告密者的工作是提供有关网络拓扑的信息，以便 Cassandra 可以有效地路由请求。
我唯一观察到的可能导致此问题的文件是cassandra-拓扑.properties具体来说被告知要被删除如果使用 GossipingPropertyFileSnitch
本地节点的机架和数据中心在 cassandra-rackdc.properties 中定义，并通过 gossip 传播到其他节点。如果 cassandra-topology.properties 存在，则将其用作后备，允许从 PropertyFileSnitch 迁移。
我没有删除此文件，因为我找不到任何确凿的证据证明这是导致问题的原因。如果您对此有任何了解，或者发现我的问题有其他原因，我将不胜感激。