a sírkövekkel kapcsolatos tapasztalatok az Apache Cassandra-ban

a sírkövek észlelése és megelőzése

a sírkövek naplókban és speciális mutatók megfigyelésével észlelhetők. Élettartamukat a gc_grace_seconds táblázat határozza meg.

Tune table settings

• gc_grace_seconds

a gc_grace_seconds alapértelmezett beállítása 864000 (10 nap). Számunkra volt értelme ezt az értéket 345600-ra (4 napra) csökkenteni. Abban az esetben, ha úgy dönt, hogy megváltoztatja a türelmi időt, győződjön meg róla, hogy a javításokat ezen időtartamon belül hajtja végre.

egyszerűen megváltoztathatja a meglévő táblák értékét, vagy létrehozhat egy új táblát:

Táblázat létrehozása kulcstér.tablename val vel GC_GRACE_SECONDS = 345600;

ALTER TABLE kulcstér.tablename WITH GC_GRACE_SECONDS = 345600;

• TTL

miután a TTL átlépte a meghatározott időtartományt, a sorok törlődnek, és az értékek sírkövekké alakulnak. Alapértelmezés szerint a sorok/értékek nem járnak le.

miközben a sírkő problémákat tapasztaltuk, rájöttünk, hogy növelnünk kell az asztalok élettartamának idejét. Azáltal, hogy ezt az értéket 1 napokra állította, az írási feladatok elmulasztása azt eredményezte, hogy az összes adatot egyszerre törölte a táblázatból. A hiányzó frissítések miatt minden sort sírkővel jelöltek meg. Az érték magasabb beállítása lehetővé teszi számunkra, hogy időben újrafuttassuk a munkákat, és elkerüljük a nagy mennyiségű sírkő felesleges létrehozását.

• tombstone_warn_threshold

a sírkő küszöbértékre vonatkozó figyelmeztetés alapértelmezés szerint 1.000-re van állítva, és a naplókban akkor jelenik meg, ha egyetlen lekérdezés több mint 1.000 sírkövet vizsgál.

• tombstone_failure_threshold

a sírkő meghibásodási küszöbértéke akkor érhető el, ha egyetlen lekérdezés 100 000 sírkövet vizsgál. Ebben az esetben a lekérdezés megszakad, ami azt jelenti, hogy az érintett tábla adatait már nem lehet lekérdezni.

ezek a küszöbérték-beállítások megváltoztathatók, de ne feledje, hogy ha növeli őket, akkor a csomópontok memóriája elfogy.

rendszeres javítások futtatása

a Cassandra nagy hibatűréssel rendelkezik, és akkor is jól működik, ha egy csomópont ideiglenesen nem érhető el. Ennek ellenére a legjobb gyakorlat a nodetool javítás futtatása csomópont meghibásodása után. Különösen, ha minden áron el akarja kerülni az adatvesztést.

a javítási folyamat során a nem elérhető csomópont megkapja az állásidő alatt történt írásokat.

ez egy jó megközelítés a javítások futtatásához a gc_grace_seconds-en belül és rendszeresen, különben előfordulhat, hogy a törölt adatok feltámadnak.

a javítások automatikus futtatásának néhány módja van. Az egyik Cassandra Reaper. Ez az eszköz egy szép felhasználói felülettel rendelkezik, amely megkönnyíti a javítások ütemezését.

konfigurálja és futtassa a tömörítést

a sírkövek végleges eltávolításához és a lemezterület felszabadításához a tömörítést aktiválni kell. Különböző típusú tömörítések vannak. A kisebb tömörítés végrehajtja a tömörítést az összes sstables – en, és automatikusan fut a Cassandra-ban. Eltávolítja az összes sírkövet, amely régebbi, mint a türelmi idő. Ha manuálisan indítja el a tömörítést az összes sstables felett, akkor azt major tömörítésnek nevezik. Ne feledje, hogy a tömörítést minden egyes csomópontra külön-külön kell kiváltani. Arra is van lehetőség, hogy fut egy felhasználó által definiált tömörítés csak egy csoport meghatározott sstables.

az adatok tömörítése C* – ban általában azt jelenti, hogy az sstables-t egyetlen új sstable-be kell egyesíteni. Ha több sorban olvas, minél több sstables-t kell beolvasni, annál lassabb lesz a folyamat. Ennek megakadályozása érdekében a tömörítésnek rendszeresen futnia kell.

a tömörítés kézi indításához használhatja a nodetool compact alkalmazást. Abban az esetben, ha nem ad meg kulcsteret vagy táblát, a tömörítés az összes kulcstéren és táblán fut.

nodetool compact keyspace tablename

ez a parancs elindítja a tömörítést a megadott táblán. Meg kell találnia, hogy melyik tömörítési stratégia van konfigurálva a táblákhoz, és hasonlítsa össze az alternatív stratégiákkal. Ha meg akarja tudni, hogy egy másik stratégia jobban megfelel-e az Ön igényeinek, akkor nézze meg a DataStax dokumentációt.

Monitor táblázat mutatók

1. Nodetool

a Nodetool a Cassandra parancssori felülete. Jól jön, ha többet szeretne megtudni a klaszterek teljesítményéről. Megnézheti a DataStax által biztosított lehetséges parancsok teljes listáját.

a Nodetool parancsokat minden egyes csomóponthoz külön kell végrehajtani. A C* – ot a Kubernetes-en futtatjuk, így a következőképpen nyithatunk meg egy héjat a futó Cassandra pod számára:

kubectl exec-it cassandra-0-n ajánlom bash

ettől a ponttól kezdve a nodetool segítségével különféle információkat szerezhetünk a tábláinkról. A nodetool tablestats parancs végrehajtható az egyes kulcsterek vagy táblák statisztikáinak nyomtatásához:

az ‘átlagos sírkövek szeletenként’ és a ‘maximális sírkövek szeletenként’ értékek megmutatják, hogy lekérdezésenként hány sírkövet szkenneltek be az elmúlt öt percben. Ha úgy látja, hogy ez az érték nagyon magas, akkor előfordulhat, hogy gyakrabban kell futtatnia a tömörítést az adott táblához.

2. SSTable Tools

az SSTable Tools végrehajtása előtt a Cassandra-t le kell állítani. Az sstableutil parancs megadja az adott táblához létező sstable fájlok listáját. Az sstablemetadata végrehajtása ezeken a fájlokon hasznos információkat nyújt a megadott tábláról, például a TTL-ről és a csepegtethető sírkövek becsléséről.

3. Prometheus és Grafana

a C* megfigyelését a Prometheus és a Grafana végzi. Miután megkaptuk a sírkövek küszöbértékére vonatkozó figyelmeztetéseket, úgy döntöttünk, hogy hozzáadunk egy panelt az irányítópultunkhoz, amely képet ad nekünk az egyes táblázatok sírkő viselkedéséről.

Cassandra rendelkezik egy ‘TombstoneScannedHistogram’ nevű táblázatos mutatóval, amely bemutatja a sírkövek hisztogramját, amelyet lekérdezésenként beolvastak. A 99. percentilis bemutatásával meglátjuk, hogy valami nincs-e rendben.