erfarenheter med gravstenar i Apache Cassandra

Upptäck och förhindra gravstenar

Tombstones kan detekteras i loggar och genom att övervaka specifika mätvärden. Deras livslängd definieras av tabellinställningen gc_grace_seconds.

Ställ in tabellinställningar

• gc_grace_seconds

standardinställningen för gc_grace_seconds är 864000 (10 dagar). För oss var det vettigt att sänka det värdet till 345600 (4 dagar). Om du bestämmer dig för att ändra respitperioden, se till att köra reparationer inom det tidsintervallet.

du kan helt enkelt ändra värdet för befintliga tabeller eller skapa en ny tabell så här:

Skapa tabell keyspace.tablename med GC_GRACE_SECONDS = 345600;

ändra tabell keyspace.tablename med GC_GRACE_SECONDS = 345600;

• TTL

efter att TTL har passerat det definierade tidsintervallet raderas raderna och värdena förvandlas till gravstenar. Som standard upphör inte raderna / värdena.

samtidigt upplever gravsten frågor vi räknat ut att vi behövde öka time-to-live av våra tabeller. Genom att ha det här värdet inställt på 1 oc-dagar, misslyckades skrivjobb med att radera alla data från en tabell på en gång. På grund av de saknade uppdateringarna märktes varje rad med en gravsten. Genom att ställa in värdet högre kan vi köra om jobb i tid och undvika onödig skapande av en stor mängd gravstenar.

• tombstone_warn_threshold

Tombstone threshold warning är inställd på 1.000 som standard och den kommer att bli synlig i dina loggar om mer än 1.000 tombstones skannas av en enda fråga.

• tombstone_failure_threshold

tröskeln för gravstensfel uppnås när 100.000 gravstenar skannas av en enda fråga. I det här fallet avbryts frågan, vilket innebär att data från den berörda tabellen inte längre kan frågas.

dessa tröskelinställningar kan ändras, men var medveten om att om du ökar dem kan det leda till att noder tar slut på minnet.

kör regelbundna reparationer

Cassandra kommer med hög feltolerans och fungerar bra även om en nod är tillfälligt otillgänglig. Ändå är det bästa praxis att köra nodetool repair efter ett nodfel. Särskilt om du vill undvika dataförlust till varje pris.

under reparationsprocessen kommer noden som inte var tillgänglig att få de skrivningar som hände under dess stilleståndstid.

det är ett bra sätt att köra reparationer inom gc_grace_seconds och regelbundet, annars kan du uppleva fall där raderade data uppstår.

det finns ett par sätt att köra reparationer automatiskt. En av dem är Cassandra Reaper. Detta verktyg kommer med en trevlig UI som gör det enkelt att schemalägga reparationer.

konfigurera och kör komprimering

för att slutligen ta bort gravstenar och frigöra diskutrymme måste komprimering utlösas. Det finns olika typer av komplikationer. Den mindre komprimeringen utför komprimering över alla sstables och körs automatiskt i Cassandra. Det tar bort alla gravstenar som är äldre än graceperioden. Om du utlöser en komprimering manuellt över alla sstables kallas det major compaction. Tänk på att komprimering måste utlösas för varje nod individuellt. Du har också möjlighet att köra en användardefinierad komprimering bara på en grupp specificerade sstables.

komprimering av data i C * innebär vanligtvis att sstables slås samman till en enda ny sstable. När du utför läser på flera rader, desto fler sstables måste skannas, desto LÅNGSAMMARE blir processen. För att förhindra att detta händer måste komprimeringen köras regelbundet.

för att starta kompaktioner manuellt kan du använda nodetool compact. Om du inte anger ett nyckelutrymme eller en tabell körs komprimeringen på alla nyckelutrymmen och tabeller.

nodetool compact keyspace tablename

detta kommando startar en komprimering på den angivna tabellen. Du bör ta reda på vilken komprimeringsstrategi som är konfigurerad för dina tabeller och jämföra den med de alternativa strategierna. Om du vill ta reda på om en annan strategi uppfyller dina behov bättre kan du kolla in DataStax-dokumentationen.

övervaka tabellmått

1. Nodetool

Nodetool är Cassandras kommandoradsgränssnitt. Det är praktiskt om du vill ta reda på mer om dina klusters prestanda. Du kan kolla in hela listan över möjliga kommandon som tillhandahålls av DataStax.

nodetool-kommandon måste utföras för varje nod individuellt. Vi kör C * på Kubernetes så att vi kan öppna ett skal för den löpande Cassandra pod enligt följande:

kubectl exec-it cassandra-0-n rekommenderar bash

från den punkten kan vi använda nodetool för att få olika information om våra tabeller. Kommandot nodetool tablestats kan utföras för att skriva ut statistik för enskilda keyspaces eller tabeller:

värdena för ‘genomsnittliga gravstenar per skiva’ och ‘maximala gravstenar per skiva’ kommer att berätta hur många gravstenar som skannades per fråga under de senaste fem minuterna. Om du ser att detta värde är mycket högt kan du behöva köra komprimering oftare för den tabellen.

2. SSTable Tools

innan du kör SSTable Tools Cassandra måste stoppas. Kommandot sstableutil ger dig en lista över sstable-filer som finns för en viss tabell. Exekvera sstablemetadata på dessa filer, kommer att ge dig användbar information om den angivna tabellen, som till exempel TTL och en uppskattning av droppbara gravstenar.

3. Prometheus och Grafana

vår övervakning för C * är upprättad med Prometheus och Grafana. Efter att ha fått tröskelvarningarna för gravstenar bestämde vi oss för att lägga till en panel i vår instrumentpanel som ger oss en uppfattning om gravstensbeteendet för vart och ett av våra bord.

Cassandra har en tabell metrisk kallas ‘TombstoneScannedHistogram’, som presenterar histogrammet av gravstenar som där skannas per fråga. Genom att visa den 99: e percentilen får vi se om något inte stämmer.