undersöka livscykeln för gravstenar i Apache Cassandra

detta inlägg är den första delen av en serie blogginlägg om livscykeln och hantering av gravstenar.

ta bort och löper ut data i Cassandra är något som du bör noga planera. Särskilt om du håller på att ta bort en enorm mängd data på en gång. Utan ordentlig planering kan detta ge problem till klustret som en ökning av läs-latens och diskanvändning fotavtryck. Under hela detta inlägg kommer jag att beskriva ett sätt att ta itu med detta och dess varningar.

Låt oss först gå igenom grunderna. I Cassandra är datafilerna (sstables) som finns på disken oföränderliga filer. När vi tar bort något i Cassandra skapas en ny SSTable som innehåller en markör. Denna markör anger vilken partition, rad eller cell som togs bort tillsammans med tidsstämpeln för den raderingen. Denna borttagningsmarkör kallas en gravsten.

de raderade data och gravstenen kan samexistera på disken under en period som heter gc_grace_seconds, vilket som standard är 10 dagar. Under denna tid, även om data fortfarande kan finnas på enheten, returneras den inte till klienten om den frågas. Vilket innebär att data från en klientperspektiv raderas så snart du kör raderingsuttalandet. Men ur operativ synvinkel kan både data och gravsten fortfarande existera och uppta utrymme på disken. Denna raderade data som fortfarande finns på disken kallas ” skuggad data.”

Anm.: I föregående stycke säger jag att data och gravstenarna ”fortfarande kan samexistera på skivan” (betoning på ”burken”) för om komprimering inträffar som involverar data och gravstenarna, kastas data ut. Men gravstenen kommer att förbli om gc_grace_seconds inte har passerat.

gc_grace_seconds är en säkerhetsmekanism för att säkerställa att gravstenen har tillräckligt med tid att replikera till alla noder som har en kopia av skuggade data. För att denna säkerhetsmekanism ska lyckas måste du kunna reparera klustret varje gc_grace_seconds. Vilket innebär att om du använder standard 10 dagar för gc_grace_seconds, måste en reparation startas och avslutas inom var 10 dagar. Reparationen tjänar syftet att förhindra zombiedata i klustret. Jag kommer inte att gå in på detaljer om hur detta kan hända, men i princip uppstår zombiedata när du tar bort data, men det återkommer någon gång senare.

efter att gc_grace_seconds har passerat kan data och gravstenen äntligen kastas ut från disken och återställa det diskutrymme som tidigare använts av dem (Figur 1). ETA för att släppa diskutrymmet är en av de första punkterna som jag vill klargöra i det här inlägget. När man använder Cassandra tycker många att denna mekanism är överraskande, det vill säga att efter att ha raderat data finns data fortfarande på disken. Denna förvirring klargörs vanligtvis snabbt så snart människor lär sig om gravstenar och gc_grace_seconds. Det verkar dock som om operatörer tenderar att tro att data och gravstenar kastas ut direkt efter att gc_grace_seconds har avslutats. Det är faktiskt viktigt att vara medveten om att detta kanske inte (och tenderar inte) att vara sant. Vanligtvis tar det längre tid än gc_grace_seconds för att denna utvisning ska hända och diskutrymmet återställs.

Figur 1-komprimering av skuggade data med utgångna och icke-utgångna gravstenar

utvisningen som nämns ovan händer när komprimering inträffar som involverar SSTables som har skuggade data och gravstenen. Först då tas data bort effektivt och diskutrymmet återställs. Det är viktigt att notera att även om gc_grace_seconds har passerat och SSTable med skuggad data komprimeras med en annan SSTable som inte har gravstenen, rensas inte skuggad data. Samma sak händer för gravstenmarkörerna, det vill säga om SSTable med gravstenen inte komprimeras med alla SSTables som fortfarande har data som raderades, kastas inte gravstenen från skivan. Anledningen till att detta händer är att Cassandra under komprimering inte vet vad som finns i SSTables som inte är inblandade i komprimeringen. Så det har inget sätt att veta att det kan kassera data eftersom det inte kan se gravstenen. Du kan se detta i Figur 2 där, även om gc_grace_seconds har passerat för båda gravstenarna, utvisas ingenting efter komprimeringen.

Figur 2-komprimering av skuggade data och deras gravstenar separat

på grund av diskanvändningen av data och gravstenmarkören kan ackumuleringen av gravstenar påverka läs-latens, eftersom Cassandra behöver läsa massor av gravstenar innan han returnerar levande data.

att radera data är vanligtvis inte ett problem om dessa raderingar är små och glesa. Eftersom Cassandra över den naturliga komprimeringslivscykeln så småningom återvinner diskutrymmet och de rensade gravstenarna. Men om du tar bort en stor mängd data på en gång skapar det många gravstenar och kan snabbt påverka din läsfördröjning.

om du behöver ta bort en stor mängd data på ad hoc-basis, finns det några steg i nästa blogginlägg som du kan vidta för att mildra riskerna.

e-post

författare

  • Pedro Gordo

intresserad av att jobba med Pedro? Planera ett tekniskt samtal.

Lämna ett svar

Din e-postadress kommer inte publiceras.