Cassandra genererer gravsteiner når du sletter data. Under noen omstendigheter kan overflødige gravsteiner forårsake lange GC-pauser, ventetid, lesefeil eller ut av heap-feil. Denne artikkelen gir råd for å håndtere gravsteiner.

Innholdsfortegnelse

Hva er en gravstein?

i Cassandra blir slettede data ikke umiddelbart renset fra disken. I stedet Skriver Cassandra en spesiell verdi, kjent som en gravstein, for å indikere at data er slettet. Gravsteiner hindre slettede data fra å bli returnert under leser, og vil til slutt tillate dataene å bli droppet via komprimering.Gravsteiner skriver-De går gjennom den normale skrivebanen – tar opp plass på disken, og bruker Cassandras konsistensmekanismer. Gravsteiner kan spres over klyngen via hint og reparasjoner. Hvis en klynge administreres på riktig måte, sikrer dette at data forblir slettet selv om en node er nede når slettingen utstedes.

Gravsteiner genereres av:

• SLETT setninger
• Angi TTLs
• Sette inn nullverdier
• Sette inn data i deler av en samling.

hva er den normale livssyklusen til gravsteiner?

Gravsteiner er skrevet med et tidsstempel. Under ideelle forhold vil gravstein (og tilhørende data) bli droppet under komprimering etter at en viss tid har gått.

følgende tre kriterier må være oppfylt for at gravsteiner skal fjernes:

• gravsteiner ble opprettet mer enn gc_grace_seconds siden.
• tabellen som inneholder gravsteinen er involvert i en komprimering.
• alle sstabeller som kan inneholde relevante data er involvert i komprimeringen.

hver tabell har en gc_grace_seconds innstilling. Som standard er dette satt til 864000, som tilsvarer 10 dager. Hensikten er å gi tid til klyngen for å oppnå konsistens via reparasjoner (og dermed forhindre oppstandelse av slettede data).

Gravsteiner vil bare bli droppet via en komprimering hvis alle sstables som kan inneholde relevante data er involvert i komprimeringen. Hvis det har gått mye tid mellom å skrive de opprinnelige dataene og utstede SLETTINGEN, blir dette mindre sannsynlig:

• Komprimeringsstrategi vil komprimere sstabeller av samme størrelse sammen. Data har en tendens til å flytte inn i større sstables som det aldre, så gravstein (i en ny, liten sstable) er usannsynlig å bli komprimert med data (i en gammel, stor sstable).
• Planert Komprimeringsstrategi er delt inn i mange nivåer som komprimeres separat. Gravsteinen vil bli skrevet inn i nivå 0 og vil effektivt ‘jage’ dataene gjennom nivåene-det skal til slutt ta opp.
• Tidsvinduet Komprimering Strategi (Eller Dato-Lagdelt Komprimering Strategi) vil aldri komprimere gravstein med data hvis de er skrevet inn i ulike tidsvinduer.

når forårsaker gravstein problemer?

Diskbruk

når data slettes, vil plassen faktisk ikke bli frigjort i minst gc_grace-perioden som er angitt i tabellinnstillingene. Dette kan forårsake problemer hvis en klynge raskt fylles opp.

under noen omstendigheter vil plassen aldri bli frigjort uten manuell inngrep.

Les ytelse

Alvorlige ytelsesproblemer kan oppstå hvis leser støter på et stort antall gravsteiner.Ytelsesproblemer er mest sannsynlig å skje med følgende typer spørringer:

• Spørringer som kjører over alle partisjoner i en tabell («velg * fra keyspace.Tabell»)
• Utvalgsspørringer («velg * fra keyspace.tabell der verdi > x», eller «HVOR verdi I (value1, value2,…)»
• en spørring som bare kan kjøres med en» TILLAT FILTRERING » – setning.

disse ytelsesproblemene oppstår på grunn av oppførselen til gravsteiner under lesing. I en områdespørring vil Cassandra-driveren vanligvis bruke personsøking, noe som gjør at noder kan returnere et begrenset antall svar om gangen. Når cassandra gravsteiner er involvert, må noden holde gravsteinene som den har møtt i minnet og returnere dem til koordinatoren, hvis en av de andre replikene ikke er klar over at de relevante dataene er slettet. Gravstenene kan ikke veksles fordi det er viktig å returnere dem alle, så ventetid og minnebruk øker proporsjonalt med antall gravsteiner som oppstår.

Om gravsteinene vil bli funnet, avhenger av måten dataene lagres og hentes på. For Eksempel, Hvis Cassandra brukes til å lagre data i en kø (som ikke anbefales), kan spørringer støte på titusenvis av gravsteiner for å returnere noen få rader med data.

hvordan kan jeg diagnostisere tombstone-relaterte problemer?

Spørringer som støter på et stort antall gravsteiner vil dukke opp i loggene. Som standard vil en lesning som møter mer enn tusen gravsteiner generere en advarsel:

WARN org.apache.cassandra.dB.ReadCommand Les 0 levende rader og 87051 tombstone celler FOR spørring VELG * fra eksempel.tabell

som standard vil det føre til at spørringen mislykkes med En TombstoneOverwhelmingException.

hvis du vil kontrollere om tombstone-lesing forårsaker ytelsesproblemer, kontrollerer du om lesingen korrelerer med en økning i leseforsinkelse og GC-pausevarighet.

hvis det er klart at gravsteiner er problemene, kan følgende teknikker bidra til å begrense omfanget av problemet:

• antall gravsteiner returnert i en bestemt spørring kan bli funnet ved å kjøre spørringen i cqlsh med sporing aktivert.
• Statistikk for antall gravsteiner oppdaget nylig i hver tabell er tilgjengelig i utgangen fra nodetool cfstats.
• for klynger i vår administrerte tjeneste er statistikk for nylig oppdagede gravsteiner tilgjengelig på klyngesiden i Metrikklister > Tabellinfo. Dette inkluderer levende celler per lese og gjennomsnitt og maks gravsteiner per lese, fordelt på node eller tabell for en gitt tidsperiode.
• Mer detaljert informasjon om lagrede gravsteiner finner du ved hjelp av ic-verktøy.

Hvordan kan jeg unngå tombstone problemer?

følgende alternativer kan hjelpe:

• Unngå spørringer som kjører på alle partisjoner i tabellen (f.eks. spørringer uten WHERE-setning eller spørringer som krever TILLAT FILTRERING).
• Endre områdespørringer for å unngå spørring av slettede data, eller bruk et smalere utvalg av data. Ytelsesproblemer oppstår bare hvis gravsteiner leses, og skala med antall gravsteiner som leses.
• Design datamodellen for å unngå å slette store mengder data.
• hvis du planlegger å slette alle dataene i en tabell, avkort eller slipp tabellen for å fjerne alle dataene uten å generere gravsteiner.
• Bruk en standard tid-til-live-verdi. Dette fungerer bare effektivt hvis primærnøkkelen til dataene dine er tidsbasert, dataene dine skrives i kronologisk rekkefølge, og dataene slettes på en kjent dato. Hvis du vil gjøre dette, angir du en standard TTL i alternativene på tabellnivå, og angir en tidsbasert komprimeringsstrategi (TimeWindowCompactionStrategy hvis tilgjengelig, DateTieredCompactionStrategy ellers). Dette vil fortsatt skape gravsteiner, men hele sstables vil bli effektivt droppet når TTL på alt innholdet har passert.

Hvordan kan jeg bli kvitt eksisterende gravsteiner?

under de fleste omstendigheter er den beste tilnærmingen å vente på at gravsteinen komprimeres normalt. Hvis haster ytelse eller disk bruk problemer krever mer umiddelbar handling, er det to nodetool kommandoer som kan brukes til å tvinge komprimering, som kan bistå i å slippe gravsteiner. Disse bør betraktes som en siste utvei-i en sunn klynge med en godt designet datamodell, er det ikke nødvendig å kjøre manuelle komprimeringer.

Kjører nodetool compact tvinger en komprimering av alle sstables. Dette krever en stor mengde ledig diskplass. Keyspace og tabellargumenter bør brukes til å begrense komprimeringen til tabellene der gravsteiner er et problem. På tabeller hvor Komprimeringsstrategi med Størrelsesnivå brukes, kan denne kommandoen føre til opprettelsen av en enorm sstable som aldri vil ha jevnaldrende å komprimere med; hvis –split-output flagget er tilgjengelig, bør det brukes.

kommandoennodetool garbagecollect er tilgjengelig fra Cassandra 3.10 og utover. Denne kommandoen kjører en rekke mindre komprimeringer som også kontrollerer overlappende sstables. DET er MER CPU-intensivt og tidkrevende enn nodetool compact, men krever mindre ledig diskplass.

Gravsteiner vil bare bli fjernet hvis gc_grace_seconds har gått siden gravsteiner ble opprettet. Det tiltenkte formålet med gc_grace_seconds er å gi tid til reparasjoner for å gjenopprette konsistens til klyngen, så vær forsiktig når du endrer den-for tidlig å fjerne gravsteiner kan resultere i oppstandelse av slettede data. Gc_grace_seconds-innstillingen påvirker også utløpet av hint generert for hintet handoff, så det er farlig å redusere gc_grace_seconds under varigheten av hintet handoff-vinduet (som standard, 3 timer).

Reparasjoner

Reparasjoner kan forsinke eller hindre slippe gravsteiner. Når en full eller inkrementell reparasjon kjøres, merkes sstablene som er berørt, som reparert. i etterfølgende komprimeringer komprimeres disse tabellene separat fra sstablene som ikke er reparert. Hvis gravsteiner er i ikke-reparerte sstables og skyggede dataene er i reparerte sstables (eller omvendt), kan ikke dataene slettes fordi sstables ikke kan komprimeres sammen.hvis du regelmessig kjører full eller inkrementelle reparasjoner på klyngen, bør dette ikke være for mye av et problem siden gravsteiner og data til slutt vil ende opp reparert. Men hvis du har en blanding av reparerte og ureparerte data, og du ikke regelmessig kjører reparasjoner, kan dette bli et problem. sstablemetadata kan hjelpe deg med å inspisere den reparerte statusen til sstables for å finne ut om dette skjer. Hvis det er, kan det være lurt å sette alle sstables som unrepaired med sstablerepairedset slik at de kan komprimeres sammen.
Vær oppmerksom på at subrange reparasjoner ikke markerer data som reparert.