Redis Cluster håndterer nodefeil gjennom en kombinasjon av feildeteksjon, replika -promotering og Cluster State Management for å sikre fortsatt drift og datatilgjengelighet. Den er designet for å overleve svikt i noen få noder ved automatisk å markedsføre kopier for å erstatte utilgjengelige mestere, og opprettholde integriteten til nøkkelområdet og samtidig minimere risiko for tap av data.
Cluster Communication and Failure Detection
Redis Cluster Nodes kommuniserer via en dedikert TCP-basert binær protokoll kalt Redis Cluster Bus. Hver node opprettholder tilkoblinger med hver annen node i klyngen ved hjelp av denne bussen, noe som muliggjør kontinuerlig helsekontroller og statlig forplantning. Noder sender med jevne mellomrom pingpakker for å bekrefte den operasjonelle statusen til sine jevnaldrende og dele informasjon om klyngens stat. Denne kommunikasjonen bruker en sladderprotokoll for å effektivt spre klyngeinformasjon, og hjelpe til med å oppdage nodesvikt.
Noder overvåker jevnaldrende ved hjelp av en aktiv ping -mekanisme. Hvis en node ikke svarer på pinger i en konfigurert tidsavbrudd (Node_Timeout), blir den flagget som muligens mislykkes med en PFAIL -status. Dette er en tentativ feilindikasjon, noe som betyr at noden kan være utilgjengelig eller nede, men den er ennå ikke bekreftet. Hvis PFAIL -tilstanden vedvarer og bekreftes av et flertall av hovedknuter, er noden merket som mislykket, noe som indikerer at den anses som utilgjengelig eller nede av klyngen. Denne konsensusbaserte feildeteksjonsmekanismen hjelper med å forhindre falske positiver i å identifisere mislykkede noder.
Håndtering av masternodefeil
Når en masternode flagges som mislykket, setter Redis Cluster en failover -prosess for å promotere en av kopiene sine for å bli den nye mesteren. Denne prosessen utløses automatisk av klyngens sviktdetektor uten administrativ inngripen. Den promoterte kopien overtar ansvaret for å betjene hasjsporene som tidligere er administrert av den mislykkede mesteren, og sikrer at klyngen kan fortsette å servere forespørsler uten manuell rekonfigurasjon.
Failover oppstår bare hvis det er minst en kopi tilgjengelig og tilgjengelig for å fremme. Hvis det ikke eksisterer noen passende kopi, går klyngen inn i en feiltilstand der den vil slutte å akseptere spørsmål for å forhindre servering av inkonsekvente data. Dette fremhever viktigheten av å ha kopier som er konfigurert for hver master for å opprettholde høy tilgjengelighet.
Failover Mechanics and Safety
Under failover venter kopien med å synkronisere fullstendig med mesteren den erstatter, og sikrer at den har behandlet alle ventende oppdateringer for å unngå tap av data. Det oppnår dette ved å matche replikasjonsforskyvningen med mesteren slik at den har et oppdatert datasett før du antar masterrollen.
Når den er synkronisert, ber kopien om en ny konfigurasjonsepok fra et flertall av mestrene. Epoken er en logisk tidsstempel som brukes til å spore konfigurasjonsendringer i klyngen. Etter å ha oppnådd enighet, sender replikaen den oppdaterte konfigurasjonen til alle noder, og kunngjør promoteringen til Master og demotionen til den gamle mesteren til replika eller fjerning.
Den gamle mesteren, når den kommer seg, mottar denne konfigurasjonsoppdateringen og slutter å servere spørsmål som en mester. Den omdirigerer klientforespørsler til den nye mesteren, og sikrer at klienter transparent fortsetter å samhandle med klyngen uten manuell intervensjon.
Håndtering av nettverkspartisjoner og split-hjerne-scenarier
Redis Cluster bruker majoritetsbasert konsensus for å unngå problemer med split-hjerne under nettverkspartisjoner. En mester vil bare bli mislykket hvis den ikke kan nås av mer enn halvparten av mestrene i klyngen. Mestere som ikke kan kommunisere med flertallet, vil slutte å akseptere skriver, og forhindre divergerende datatilstander mellom partisjoner.
Imidlertid, hvis en minoritetspartisjon inneholder klienter som fortsetter å skrive til en mester før failover, er det et potensial for skrivetap. Redis reduserer denne risikoen ved å nekte å skrive på minoritetssiden etter en timeout og på majoritetssiden ved å raskt svikte over den uoppnåelige mesteren.
Til tross for disse forholdsreglene, kan skriver gå tapt under failover -vinduer fordi Redis bruker asynkron replikasjon mellom mestere og kopier. Siden svar på å skrive kommandoer og replikasjonsoppdateringer sendes nesten samtidig, er vinduet for å miste skriver veldig smalt, men ikke umulig.
Konfigurasjonsalternativer som påvirker feilhåndtering
Redis Cluster inkluderer konfigurasjonsalternativer som påvirker tilgjengeligheten og atferden under nodesvikt:
-`Cluster-Require-Full-dekning` (Standard ja): Klyngen slutter å akseptere skriver om noen del av nøkkelområdet blir avdekket på grunn av nodesvikt, noe som sikrer sterk datakonsistens.
-`Cluster-Allow-Reads-When-Down` (Standard No): Kontroller om leser er tillatt når klyngen er i en feiltilstand. Aktivering av dette tillater leser fra noder selv under delvise feil, men kan risikere foreldede data som blir servert.
Disse innstillingene lar administratorer balansere tilgjengelighet og konsistens basert på søknadskrav.
Manuell failover -støtte
I tillegg til automatisk failover, gir Redis Cluster en manuell failover -kommando som kan utstedes på replikatnoder. Dette er nyttig for vedlikehold eller testingsscenarier der en administrator ønsker å bytte hovedroller uten å vente på en faktisk feilhendelse.
Manuell failover fungerer ved å blokkere klienter på den nåværende mesteren, og venter på at kopien skal ta igjen fullt opp, og deretter markedsføre kopien med en jevn atomovergang. Dette sikrer ikke noe tap av data under rolleendringen og minimal forstyrrelse for klienter.
Sammendrag
Redis Cluster håndterer nodefeil primært gjennom en feildeteksjon og failover -system basert på kontinuerlig overvåking via Redis Cluster -bussen og en sladderprotokoll. Noder oppdager utilgjengelige mestere og markedsfører replikker automatisk etter en konsensusprosess som krever at et flertall av mestere skal bli enige om feilen. Failover er designet for å minimere tap av data ved å sikre at kopier er fullstendig synkronisert før promotering. Nettverkspartisjoner administreres via majoritetsbaserte beslutninger for å forhindre forhold i split-hjerne, selv om et smalt vindu med skrivetap kan oppstå på grunn av asynkron replikasjon. Konfigurasjonsalternativer tillater innstilling av tilgjengelighet kontra konsistens under feil, og manuelle failover -kommandoer gir operatørene kontroll for vedlikehold.
Denne arkitekturen gjør det mulig for Redis -klyngen å gi høy tilgjengelighet og partisjonstoleranse med automatisk gjenoppretting fra masternodesvikt, noe som sikrer at klyngen forblir operativ og konsistent under svikt -scenarier.