Redis Cluster håndterer knudefejl gennem en kombination af fejldetektion, replikafremme og klyngestatstyring for at sikre fortsat drift og datatilgængelighed. Det er designet til at overleve fiaskoer af nogle få noder ved automatisk at fremme replikaer til at erstatte uopnåelige mestre, hvilket opretholder integriteten af nøgleområdet, mens de minimerer datatabsrisici.
Cluster kommunikation og fiaskodetektion
Redis-klyngeknuder kommunikerer via en dedikeret TCP-baseret binær protokol kaldet Redis Cluster Bus. Hver knude opretholder forbindelser med hver anden knude i klyngen ved hjælp af denne bus, hvilket muliggør kontinuerlig sundhedskontrol og statsudbredelse. Knudepunkter sender med jævne mellemrum pingpakker for at bekræfte den operationelle status for deres jævnaldrende og dele information om klyngens tilstand. Denne kommunikation bruger en sladderprotokol til effektivt at formidle information om klynge, der hjælper med påvisning af nodefejl.
Knudepunkter overvåger peers ved hjælp af en aktiv pingmekanisme. Hvis en knude ikke reagerer på pinger inden for en konfigureret timeout -periode (node_timeout), markeres den som muligvis mislykkes med en Pfail -status. Dette er en tentativ fiaskoindikation, hvilket betyder, at noden kan være utilgængelig eller ned, men den er endnu ikke bekræftet. Hvis Pfail -tilstanden vedvarer og bekræftes af et flertal af mastnoder, er noden markeret som FAIL, hvilket indikerer, at den betragtes som uopnåelig eller nede af klyngen. Denne konsensusbaserede fejldetekteringsmekanisme hjælper med at forhindre falske positive ved at identificere mislykkede knudepunkter.
Håndtering af master node -fejl
Når en master -knude er markeret som FAIL, initierer Redis Cluster en failover -proces for at fremme en af dens replikaer til at blive den nye mester. Denne proces udløses automatisk af klyngens fejldetektor uden administrativ indgriben. Den promoverede replika overtager ansvaret for at betjene de hash -slots, der tidligere blev administreret af den mislykkede mester, hvilket sikrer, at klyngen kan fortsætte med at betjene anmodninger uden manuel rekonfiguration.
Failover forekommer kun, hvis der er mindst en replika tilgængelig og tilgængelig for at promovere. Hvis der ikke findes nogen passende replika, går klyngen ind i en fejltilstand, hvor den holder op med at acceptere forespørgsler for at forhindre servering af inkonsekvente data. Dette fremhæver vigtigheden af at have replikaer konfigureret til hver mester til at opretholde høj tilgængelighed.
Failover Mechanics and Safety
Under failover venter replikaen med at synkronisere fuldstændigt med masteren, den erstatter, hvilket sikrer, at den har behandlet alle verserende opdateringer for at undgå datatab. Det opnår dette ved at matche replikations offset med masteren, så det har et ajourført datasæt, før man antager masterrollen.
Når den er synkroniseret, anmoder replikaen om en ny konfigurationsepok fra et flertal af mestrene. Epoken er en logisk tidsstempel, der bruges til at spore konfigurationsændringer i klyngen. Efter at have fået konsensus udsender replikaen den opdaterede konfiguration til alle knudepunkter, der annoncerer sin promovering til master og nedrivning af den gamle mester til replika eller fjernelse.
Den gamle mester, når den kommer sig tilbage, modtager denne konfigurationsopdatering og stopper med at servere forespørgsler som en master. Det omdirigerer klientanmodninger til den nye master og sikrer, at klienter gennemsigtigt fortsætter med at interagere med klyngen uden manuel indgriben.
Håndtering af netværkspartitioner og split-hjerne-scenarier
Redis Cluster bruger majoritetsbaseret konsensus for at undgå split-hjerneproblemer under netværkspartitioner. En mester mislykkes kun, hvis det ikke kan nås af mere end halvdelen af mestrene i klyngen. Mastere, der ikke kan kommunikere med flertallet, vil stoppe med at acceptere skrivninger og forhindre divergerende datasilstande mellem partitioner.
Men hvis en mindretals partition indeholder klienter, der fortsætter med at skrive til en master før failover, er der et potentiale for skrivningstab. Redis mindsker denne risiko ved at nægte skrivning på mindretalsiden efter en timeout og på flertalssiden ved hurtigt at svigte over den uopnåelige mester.
På trods af disse forholdsregler kan skrivning gå tabt under failover -vinduer, fordi Redis bruger asynkron replikation mellem mestre og kopier. Da svar til at skrive kommandoer og replikationsopdateringer sendes næsten samtidig, er vinduet for at miste skriv meget smalt, men ikke umuligt.
Konfigurationsindstillinger, der påvirker håndtering af fejl
Redis Cluster inkluderer konfigurationsindstillinger, der påvirker tilgængeligheden og adfærd under nodefejl:
-`Cluster-Require-full-coverage` (standard ja): klyngen stopper med at acceptere skriv, hvis en del af nøgleområdet afdækkes på grund af nodefejl, hvilket sikrer stærk datakonsistens.
-`Cluster-Allow-Reads-When-Down` (standard nr): Kontrollerer, om læsninger er tilladt, når klyngen er i en fiasko-tilstand. Aktivering af dette tillader læsning fra noder, selv under delvise fejl, men kan risikere uaktuelle data.
Disse indstillinger giver administratorer mulighed for at afbalancere tilgængelighed og konsistens baseret på applikationskrav.
Manuel failover support
Foruden automatisk failover giver Redis Cluster en manuel failover -kommando, der kan udstedes på replika -noder. Dette er nyttigt til vedligeholdelses- eller testscenarier, hvor en administrator ønsker at bytte masterroller uden at vente på en faktisk fejlbegivenhed.
Manuel failover fungerer ved at blokere klienter på den aktuelle master, vente på, at replikaen skal indhente fuldt ud og derefter fremme replikaen med en glat atomovergang. Dette sikrer intet datatab under rolleændringen og minimal forstyrrelse af klienterne.
Resume
Redis Cluster håndterer knudefejl primært gennem et fejldetekterings- og failover -system baseret på kontinuerlig overvågning via Redis Cluster Bus og en sladderprotokol. Knudepunkter detekterer uopnåelige mestre og fremmer replikaer automatisk efter en konsensusproces, der kræver, at et flertal af mestre er enige om fejlen. Failover er designet til at minimere datatab ved at sikre, at kopier er fuldt synkroniseret inden forfremmelse. Netværkspartitioner styres via majoritetsbaserede beslutninger for at forhindre split-hjerne-forhold, skønt der kan forekomme et smalt vindue med skrivetab på grund af asynkron replikation. Konfigurationsindstillinger tillader indstilling af tilgængelighed versus konsistens under fejl, og manuelle failover -kommandoer giver operatører kontrol til vedligeholdelse.
Denne arkitektur gør det muligt for Redis Cluster at give høj tilgængelighed og opdelingstolerance med automatisk gendannelse fra mastersnodefejl, hvilket sikrer, at klyngen forbliver operationel og konsistent under fiasko -scenarier.