Wie im Titel angegeben, haben wir ein Problem mit unserem Cassandra-Cluster. Es gibt9 Knotenmit einemReplikationsfaktor von 3mitNetzwerkTopologieStrategie. Alles im selben DC und Rack. Cassandra-Version ist3.11.4(geplanter Umzug am 3.11.10). Instanzen haben4 ZentralprozessorenUnd32 GB RAM. (Planung, auf 8 CPU umzusteigen)
Immer wenn wir versuchen, eine Reparatur auf unserem Cluster auszuführen (mit Cassandra Reaper auf einem unserer Knoten), verlieren wir irgendwo im Prozess einen Knoten. Wir stoppen die Reparatur schnell, starten den Cassandra-Dienst auf dem Knoten neu und warten, bis er dem Ring beitritt. Daher können wir derzeit nie eine Reparatur ausführen.
Ich habe das Problem beobachtet und festgestellt, dass es durch eine hohe CPU-Auslastung auf einigen unserer Knoten verursacht wird(genau 3). Sie können das 1-Wochen-Intervalldiagramm unten sehen.Die Schwankungen sind auf die Nutzung der App zurückzuführen. Morgens ist der Wert sehr niedrig.
Ich habe die laufenden Prozesse auf jedem Knoten verglichen und es gibt nichts Zusätzliches auf den Knoten mit hoher CPU-Auslastung. Ich habe die Konfigurationen verglichen. Sie sind identisch. Konnte keinen Unterschied feststellen.
Mir ist auch aufgefallen, dass diese Knoten den größten Teil des Datenverkehrs abfangen. Siehe das 1-Wochen-Intervalldiagramm unten.Sowohl gesendete als auch empfangene Bytes.
Diagramm „Gesendete und empfangene Bytes“
Ich habe ein wenig recherchiert. Ich fandDasThread und am Ende wird empfohlen, dynamic_snitch: falsein der Cassandra-Konfiguration festzulegen. Ich habe mir unsere Snitch-Strategie angesehen, die istTratsch und Gerüchte. In der Praxis sollte diese Strategie einwandfrei funktionieren, aber ich vermute, das tut sie nicht.
Die Aufgabe eines Snitches besteht darin, Informationen über Ihre Netzwerktopologie bereitzustellen, damit Cassandra Anfragen effizient weiterleiten kann.
Meine einzige Beobachtung, die Ursache für dieses Problem sein könnte, ist, dass es eine Datei namenscassandra-topology.propertiesDas ist speziellsoll entfernt werdenbei Verwendung von GossipingPropertyFileSnitch
Das Rack und das Rechenzentrum für den lokalen Knoten werden in cassandra-rackdc.properties definiert und über Gossip an andere Knoten weitergegeben. Wenn cassandra-topology.properties vorhanden ist, wird es als Fallback verwendet und ermöglicht die Migration vom PropertyFileSnitch.
Ich habe diese Datei nicht entfernt, da ich keine eindeutigen Beweise dafür finden konnte, dass sie das Problem verursacht. Wenn Sie diesbezüglich etwas wissen oder einen anderen Grund für mein Problem sehen, wäre ich für Ihre Hilfe dankbar.