Erfaringer Med Gravsteiner I Apache Cassandra

Oppdag og forhindre gravsteiner

Gravsteiner kan oppdages i logger og ved å overvåke spesifikke beregninger. Deres levetid er definert av tabellinnstillingen gc_grace_seconds.

Tune tabellinnstillinger

• gc_grace_seconds

standardinnstillingen for gc_grace_seconds er 864000 (10 dager). For oss var det fornuftig å senke den verdien til 345600 (4 dager). Hvis du bestemmer deg for å endre gyldighetsperioden, må du sørge for å kjøre reparasjoner innen det tidsområdet.

du kan ganske enkelt endre verdien for eksisterende tabeller eller opprette et nytt bord som dette:

LAG TABELL keyspace.tabellnavn MED GC_GRACE_SECONDS = 345600;

ENDRE TABELL keyspace.tabellnavn MED GC_GRACE_SECONDS = 345600;

• TTL

etter AT TTL har passert det definerte tidsområdet, slettes radene og verdiene blir omgjort til gravsteiner. Som standard utløper ikke radene / verdiene.

mens vi opplevde gravsteinsproblemene, fant vi ut at vi trengte å øke tiden til våre bord. Ved å ha denne verdien satt til 1 ½ dager, hadde ikke SKRIVEJOBBER effekten av å slette alle dataene fra et bord samtidig. På grunn av de manglende oppdateringene ble hver rad merket med en gravstein. Ved å sette verdien høyere kan vi kjøre jobber i tide og unngå unødvendig opprettelse av en stor mengde gravsteiner.

• tombstone_warn_threshold

tombstone terskel advarsel er satt til 1.000 som standard, og det vil bli synlig i loggene i tilfelle mer enn 1.000 gravsteiner skannes av en enkelt spørring.

• tombstone_failure_threshold

terskelen for gravsteinssvikt nås når 100.000 gravsteiner skannes av en enkelt spørring. I dette tilfellet blir spørringen avbrutt, noe som betyr at data fra den berørte tabellen ikke lenger kan spørres.

disse terskelinnstillingene kan endres, men vær oppmerksom på at hvis du øker dem, kan det føre til at noder går tom for minne.

Kjør regelmessige reparasjoner

Cassandra kommer med høy feiltoleranse og fungerer godt selv om en node er midlertidig utilgjengelig. Likevel er det best praksis å kjøre nodetool repair etter en node feil. Spesielt hvis du vil unngå tap av data for enhver pris.

under reparasjonsprosessen mottar noden som ikke var tilgjengelig, skrivingene som skjedde under nedetiden.

det er en god tilnærming til å kjøre reparasjoner i gc_grace_seconds og regelmessig, ellers kan du oppleve tilfeller der slettede data oppstår.

det er et par måter å kjøre reparasjoner automatisk på. En av Dem Er Cassandra Reaper. Dette verktøyet kommer med en fin UI som gjør det enkelt å planlegge reparasjoner.

Konfigurer og kjør komprimering

for endelig å fjerne gravsteiner og frigjøre diskplass, må komprimering utløses. Det finnes forskjellige typer komprimering. Den mindre komprimeringen utfører komprimering over alle sstables og kjører automatisk I Cassandra. Det fjerner alle gravsteiner som er eldre enn nådeperioden. Hvis du utløser en komprimering manuelt over alle sstables kalles det major compaction. Husk at komprimering må utløses for hver node individuelt. Du har også muligheten til å kjøre en brukerdefinert komprimering bare på en gruppe angitte sstables.

Komprimering av data i C* betyr vanligvis å slå sammen sstables til en enkelt ny sstable. Når du utfører leser på flere rader, jo flere sstables må skannes, jo tregere blir prosessen. For å unngå at dette skjer, må komprimeringen kjøres regelmessig.

for å starte komprimeringer manuelt kan du bruke nodetool compact. Hvis du ikke angir et nøkkelområde eller en tabell, kjøres komprimeringen på alle nøkkelområder og tabeller.

nodetool compact keyspace tablename

denne kommandoen starter en komprimering på den angitte tabellen. Du bør finne ut hvilken komprimeringsstrategi som er konfigurert for tabellene dine, og sammenligne den med de alternative strategiene. Hvis du vil finne ut om en annen strategi oppfyller dine behov bedre, kan du sjekke Ut DataStax-dokumentasjonen.

Overvåk tabellberegninger

1. Nodetool

Nodetool Er Cassandra kommandolinjegrensesnitt. Den kommer godt med hvis du ønsker å finne ut mer om klynger ytelse. Du kan sjekke ut hele listen over mulige kommandoer levert Av DataStax.

Nodetool kommandoer må utføres for hver node individuelt. Vi kjører C * På Kubernetes slik at vi kan åpne et skall for Løpende Cassandra pod som følger:

kubectl exec-it cassandra-0-n anbefaler bash

Fra det punktet kan vi bruke nodetool for å få ulike opplysninger om våre tabeller. Kommandoen nodetool tablestats kan utføres for å skrive ut statistikk for individuelle nøkkelområder eller tabeller:

verdiene For ‘Gjennomsnittlige gravsteiner per skive ‘og’ Maksimale gravsteiner per skive ‘ vil fortelle deg hvor mange gravsteiner som ble skannet per spørring de siste fem minuttene. Hvis du ser at denne verdien er svært høy, må du kanskje kjøre komprimering oftere for det bordet.

2. SSTable Verktøy

Før du utfører Sstable Verktøy Cassandra må stoppes. Kommandoen sstableutil vil gi deg en liste over sstable-filer som eksisterer for et bestemt bord. Utfører sstablemetadata på disse filene, vil gi deg nyttig informasjon om den angitte tabellen, som FOR eksempel TTL og et estimat av droppable gravsteiner.

3. Prometheus Og Grafana

vår overvåking For C * er satt opp Med Prometheus og Grafana. Etter å ha mottatt gravsteiner terskel advarsler bestemte vi oss for å legge til et panel på dashbordet som gir oss en ide om gravstein oppførsel for hver av våre bord.

Cassandra har en tabellmetrisk kalt ‘TombstoneScannedHistogram’, som presenterer histogrammet av gravsteiner som ble skannet per spørring. Ved å vise den 99. persentilen vil vi se om noe ikke er riktig.