erfaringer med gravsten i Apache Cassandra

opdage og forhindre gravsten

gravsten kan detekteres i logfiler og ved at overvåge specifikke målinger. Deres levetid er defineret af tabelindstillingen gc_grace_seconds.

Indstil tabelindstillinger

• gc_grace_seconds

standardindstillingen for gc_grace_seconds er 864000 (10 dage). For os var det fornuftigt at sænke denne værdi til 345600 (4 dage). Hvis du beslutter dig for at ændre graceperioden, skal du sørge for at køre reparationer inden for dette tidsinterval.

du kan blot ændre værdien for eksisterende tabeller eller oprette en ny tabel som denne:

Opret tabel keyspace.tablenavn med GC_GRACE_SECONDS = 345600;

ALTER TABLE keyspace.tablenavn med GC_GRACE_SECONDS = 345600;

• TTL

når TTL har passeret det definerede tidsinterval, slettes rækkerne, og værdierne omdannes til gravsten. Som standard udløber rækkerne / værdierne ikke.

mens vi oplevede gravstensproblemerne, fandt vi ud af, at vi havde brug for at øge tiden til live på vores borde. Ved at have denne værdi sat til 1 liter dage, svigtende skrive job havde den virkning at slette alle data fra en tabel på en gang. På grund af de manglende opdateringer blev hver række markeret med en gravsten. Indstilling af værdien højere giver os mulighed for at køre job igen i tide og undgå unødvendig oprettelse af en stor mængde gravsten.

• tombstone_advarsel_threshold

gravstenstærskeladvarslen er som standard indstillet til 1.000, og den bliver synlig i dine logfiler, hvis mere end 1.000 gravsten scannes af en enkelt forespørgsel.

• tombstone_failure_threshold

Tombstone failure threshold nås, når 100.000 gravsten scannes af en enkelt forespørgsel. I dette tilfælde afbrydes forespørgslen, hvilket betyder, at data fra den berørte tabel ikke længere kan forespørges.

disse tærskelindstillinger kan ændres, men vær opmærksom på, at hvis du øger dem, kan det føre til, at noder løber tør for hukommelse.

Kør regelmæssige reparationer

Cassandra leveres med høj fejltolerance og fungerer godt, selvom en node midlertidigt ikke er tilgængelig. Ikke desto mindre er det bedste praksis at køre nodetool reparation efter en knudefejl. Især hvis du vil undgå datatab for enhver pris.

under reparationsprocessen modtager den node, der ikke var tilgængelig, de skrivninger, der skete under dens nedetid.

det er en god tilgang til at køre reparationer inden for gc_grace_seconds og regelmæssigt, ellers kan du opleve tilfælde, hvor slettede data genopstår.

der er et par måder at køre reparationer automatisk. En af dem er Cassandra Reaper. Dette værktøj leveres med en dejlig brugergrænseflade, der gør det nemt at planlægge reparationer.

Konfigurer og kør komprimering

for endelig at fjerne gravsten og frigøre diskplads skal komprimering udløses. Der er forskellige former for compactions. Den mindre komprimering udfører komprimering over alle sstables og kører automatisk i Cassandra. Det fjerner alle gravsten, der er ældre end graceperioden. Hvis du udløser en komprimering manuelt over alle sstables kaldes det større komprimering. Husk, at komprimering skal udløses for hver knude individuelt. Du har også mulighed for at køre en brugerdefineret komprimering bare på en gruppe af specificerede sstables.

komprimering af data i C* betyder normalt at flette sstables til en enkelt ny sstable. Når du udfører læser på flere rækker, jo flere sstables skal scannes, jo LANGSOMMERE bliver processen. For at forhindre dette sker komprimeringen regelmæssigt.

for at starte compactions manuelt kan du bruge nodetool compact. Hvis du ikke angiver et keyspace eller en tabel, vil komprimeringen køre på alle keyspaces og tabeller.

nodetool compact keyspace tablename

denne kommando starter en komprimering på den angivne tabel. Du skal finde ud af, hvilken komprimeringsstrategi der er konfigureret til dine tabeller og sammenligne den med de alternative strategier. Hvis du vil finde ud af, om en anden strategi opfylder dine behov bedre, kan du tjekke dokumentationen til skat.

Monitor tabel metrics

1. Nodetool

Nodetool er Cassandras kommandolinjegrænseflade. Det er praktisk, hvis du vil finde ud af mere om din klyngepræstation. Du kan tjekke hele listen over mulige kommandoer leveret af Dataskat.

Nodetool kommandoer skal udføres for hver node individuelt. Vi kører C * på Kubernetes, så vi kan åbne en skal til den løbende Cassandra pod som følger:

kubectl cassandra-0 – n anbefaler bash

fra det tidspunkt kan vi bruge nodetool til at få forskellige oplysninger om vores tabeller. Kommandoen nodetool tablestats kan udføres for at udskrive statistik for individuelle keyspaces eller tabeller:

værdierne for ‘gennemsnitlige gravsten pr skive ‘og’ maksimale gravsten pr skive ‘ vil fortælle dig, hvor mange gravsten blev scannet pr forespørgsel i de sidste fem minutter. Hvis du ser, at denne værdi er meget høj, skal du muligvis køre komprimering oftere for den tabel.

2. Sstable Tools

før udførelse Sstable Tools Cassandra skal stoppes. Kommandoen sstableutil giver dig en liste over sstable-filer, der findes i en bestemt tabel. Udførelse sstablemetadata på disse filer, vil give dig nyttige oplysninger om den angivne tabel, som for eksempel TTL og et skøn over droppable gravsten.

3. Prometheus og Grafana

vores overvågning af C * er sat op med Prometheus og Grafana. Efter at have modtaget gravstenens tærskeladvarsler besluttede vi at tilføje et panel til vores dashboard, der giver os en ide om gravstenens adfærd for hver af vores tabeller.

Cassandra har en tabel metric kaldet ‘TombstoneScannedHistogram’, som præsenterer histogrammet af gravsten, hvor scannet pr forespørgsel. Ved at vise den 99. percentil vil vi se, om noget ikke er rigtigt.