După cum se spune în titlu, avem o problemă cu clusterul Cassandra. Sunt 9 noduri cu factor de replicare de 3 folosind NetworkTopologyStrategy. Toate în același DC și Rack. Versiunea Cassandra este 3.11.4 (planifică să se mute pe 3.11.10). Instanțele au 4 CPU și 32 GB RAM. (planifică să treci pe 8 CPU)
Ori de câte ori încercăm să rulăm reparații pe clusterul nostru (folosind Cassandra Reaper pe unul dintre nodurile noastre), pierdem un nod undeva în proces. Oprim rapid reparația, repornim serviciul Cassandra pe nod și așteptăm ca acesta să se alăture inelului. Prin urmare, în zilele noastre nu putem executa reparații.
Am observat problema și mi-am dat seama că această problemă este cauzată de utilizarea ridicată a CPU pe unele dintre nodurile noastre (exact 3). Este posibil să vedeți graficul intervalului de 1 săptămână mai jos. Sușurile și coborâșurile sunt cauzate de utilizarea aplicației.Dimineața, este foarte scăzut.
Graficul de utilizare a procesorului
Am comparat procesele care rulează pe fiecare nod și nu există nimic în plus pentru nodurile CPU înalte. Am comparat configurațiile. Sunt identice. Nu am putut găsi nicio diferență.
De asemenea, mi-am dat seama că aceste noduri sunt cele care preiau cel mai mult trafic. Vedeți graficul intervalului de 1 săptămână de mai jos. Ambii octeți trimiși și primiți.
Graficul octeților trimiși și primiți
Am făcut niște cercetări. am găsit acest fir si la final se recomanda fixarea dynamic_snitch: fals în configurația Cassandra. M-am uitat la strategia noastră de snitch care este GossipingPropertyFileSnitch. În practică, această strategie ar trebui să funcționeze corect, dar cred că nu funcționează.
Sarcina unui snitch este de a furniza informații despre topologia rețelei dvs., astfel încât Cassandra să poată direcționa eficient cererile.
Singura mea observație care ar putea fi cauza acestei probleme este că există un fișier numit cassandra-topologie.proprietati care este în mod specific spus să fie eliminat dacă utilizați GossipingPropertyFileSnitch
Rack-ul și centrul de date pentru nodul local sunt definite în cassandra-rackdc.properties și propagate către alte noduri prin bârfă. Dacă cassandra-topology.properties există, acesta este folosit ca alternativă, permițând migrarea din PropertyFileSnitch.
Nu am eliminat acest fișier, deoarece nu am putut găsi nicio dovadă concretă că aceasta cauzează problema. Dacă aveți cunoștințe despre acest lucru sau vedeți orice alt motiv pentru problema mea, aș aprecia ajutorul dvs.
