如標題所述，我們的 Cassandra 叢集遇到問題。有9個節點與一個複製因子為 3使用網路拓撲策略。全部位於同一個 DC 和機架中。卡桑德拉版本是3.11.4（計劃於 2010 年 11 月 3 日轉移）。實例有4個CPU和32 GB 內存。 （計劃轉向 8 CPU）
每當我們嘗試在叢集上執行修復（在其中一個節點上使用 Cassandra Reaper）時，我們都會在此過程中的某個位置遺失一個節點。我們迅速停止修復，重新啟動節點上的 Cassandra 服務並等待其加入環。因此，我們這些天永遠無法進行修復。
我觀察了這個問題，意識到這個問題是由於我們的一些節點上的CPU使用率過高所引起的（正好 3）。您可能會在下面看到 1 週間隔圖。起伏是由應用程式的使用引起的。早上，溫度很低。
我比較了每個節點上正在運行的進程，高CPU節點上沒有任何額外的東西。我比較了配置。它們是相同的。找不到任何區別。
我還意識到這些節點是佔用大部分流量的節點。請參閱下面的 1 週間隔圖。發送和接收位元組。
我做了一些研究。我發現這線程，最後建議dynamic_snitch: false在 Cassandra 配置中進行設定。我查看了我們的告密策略是八卦財產文件告密者。實際上，這個策略應該可以正常運作，但我想事實並非如此。
告密者的工作是提供有關網路拓撲的信息，以便 Cassandra 可以有效地路由請求。
我唯一觀察到可能導致此問題的是有一個名為cassandra-topology.properties具體來說就是被告知要刪除如果使用 GossipingPropertyFileSnitch
本地節點的機架和資料中心在 cassandra-rackdc.properties 中定義，並透過 gossip 傳播到其他節點。如果 cassandra-topology.properties 存在，則將其用作後備，允許從 PropertyFileSnitch 遷移。
我沒有刪除這個文件，因為我找不到任何確鑿的證據證明這是導致問題的原因。如果您對此有任何了解或發現我的問題有任何其他原因，我將不勝感激您的幫助。