タイトルにもあるように、Cassandraクラスタに問題が発生しています。9 ノードとともに複製係数 3使用してネットワークトポロジ戦略すべて同じDCとラックにあります。Cassandraバージョンは3.11.4（3.11.10に移行する予定）。インスタンスは4CPUそして32 GB の RAM（8CPUへの移行を計画中）
クラスターで修復を実行しようとすると (ノードの 1 つで Cassandra Reaper を使用して)、プロセスのどこかでノードが 1 つ失われます。すぐに修復を停止し、ノードで Cassandra サービスを再起動して、リングに参加するまで待機します。そのため、最近は修復を実行できません。
私はこの問題を観察し、この問題は一部のノードのCPU使用率が高いことによって引き起こされていることに気付きました。（正確には3）1 週間間隔のグラフは以下に表示されます。上下はアプリの使用状況によって変わります。朝は非常に低くなります。
各ノードで実行中のプロセスを比較しましたが、CPU 使用率の高いノードには何も追加されていません。構成を比較しました。それらは同一です。違いは見つかりませんでした。
また、これらのノードがトラフィックの大部分を占めていることもわかりました。下の 1 週間間隔のグラフをご覧ください。送信バイトと受信バイトの両方。
調べてみたところ、これスレッドと最後にdynamic_snitch: falseCassandraの設定で設定することをお勧めします。私はスニッチ戦略を見ました。ゴシッププロパティファイルスニッチ実際には、この戦略は適切に機能するはずですが、そうではないようです。
スニッチの役割は、Cassandra がリクエストを効率的にルーティングできるように、ネットワーク トポロジに関する情報を提供することです。
この問題の原因として考えられるのは、Cassandra トポロジープロパティ具体的には削除するように言われたGossipingPropertyFileSnitchを使用する場合
ローカル ノードのラックとデータ センターは cassandra-rackdc.properties で定義され、ゴシップを介して他のノードに伝播されます。cassandra-topology.properties が存在する場合は、フォールバックとして使用され、PropertyFileSnitch からの移行が可能になります。
このファイルが問題の原因であるという確固たる証拠が見つからなかったため、このファイルを削除しませんでした。これについて何か知識をお持ちの方、または私の問題に他の原因があると思われる方は、ご協力いただければ幸いです。