Redis Cluster hanterar nodfel genom en kombination av feldetektering, replikfrämjande och klusterstatlig hantering för att säkerställa fortsatt drift och datatillgänglighet. Det är utformat för att överleva misslyckanden med några noder genom att automatiskt främja kopior för att ersätta oåtkomliga mästare, upprätthålla integriteten i nyckelutrymmet samtidigt som dataförlustrisker minimeras.
Klusterkommunikation och feldetektering
Redis-klusternoder kommunicerar via ett dedikerat TCP-baserat binärt protokoll som kallas Redis Cluster Bus. Varje nod upprätthåller anslutningar med alla andra noder i klustret med denna buss, vilket möjliggör kontinuerlig hälsokontroll och tillståndsförökning. Noder skickar regelbundet pingpaket för att bekräfta deras kamrater och dela information om klusterens tillstånd. Denna kommunikation använder ett skvallerprotokoll för att effektivt sprida klusterinformation och hjälpa till att upptäcka nodfel.
Noder övervakar kamrater med en aktiv pingmekanism. Om en nod inte svarar på pings inom en konfigurerad tidsgräns (node_timeout), flaggas den som eventuellt misslyckas med en PFAIL -status. Detta är en tentativ felindikation, vilket innebär att noden kan vara oåtkomlig eller nere men den är ännu inte bekräftad. Om PFAIL -tillståndet kvarstår och bekräftas av en majoritet av masternoderna, markeras noden som misslyckande, vilket indikerar att det anses oåtkomligt eller ner av klustret. Denna konsensusbaserade feldetekteringsmekanism hjälper till att förhindra falska positiva effekter för att identifiera misslyckade noder.
Hantera masternodfel
När en masternod flaggas som Fail, initierar Redis Cluster en failover -process för att främja en av dess kopior för att bli den nya mästaren. Denna process utlöses automatiskt av klusterens feldetektor utan administrativ intervention. Den befordrade repliken tar över ansvaret för att betjäna hashplatserna som tidigare hanterats av den misslyckade mästaren, vilket säkerställer att klustret kan fortsätta betjäna förfrågningar utan manuell rekonfiguration.
Failover inträffar endast om det finns minst en kopia tillgänglig och nås för att främja. Om det inte finns någon lämplig replik, kommer klustret in i ett feltillstånd där det kommer att sluta acceptera frågor för att förhindra att tjäna inkonsekventa data. Detta belyser vikten av att ha repliker konfigurerade för varje mästare för att upprätthålla hög tillgänglighet.
failover mekanik och säkerhet
Under failover väntar repliken på att synkronisera helt med den mästare som den ersätter, vilket säkerställer att den har behandlat alla väntande uppdateringar för att undvika dataförlust. Det uppnår detta genom att matcha replikeringsförskjutningen med Master så att den har ett aktuellt datasätt innan du antar masterrollen.
När den synkroniseras begär repliken en ny konfigurationsepok från en majoritet av mästarna. Epoken är en logisk tidsstämpel som används för att spåra konfigurationsändringar i klustret. Efter att ha erhållit konsensus sänder repliken den uppdaterade konfigurationen till alla noder och tillkännager sin marknadsföring till mästare och demotion av den gamla mästaren till replik eller borttagning.
Den gamla mästaren, när den återhämtar sig, får denna konfigurationsuppdatering och slutar betjäna frågor som en mästare. Det omdirigerar klientförfrågningar till den nya mästaren och säkerställer att klienter transparent fortsätter att interagera med klustret utan manuellt ingripande.
Hantera nätverkspartitioner och split-hjärnsscenarier
Redis Cluster använder majoritetsbaserad konsensus för att undvika split-hjärnfrågor under nätverkspartitioner. En mästare kommer endast att misslyckas om den är oåtkomlig av mer än hälften av mästarna i klustret. Mästare som inte kan kommunicera med majoriteten kommer att sluta acceptera skrivningar, vilket förhindrar divergerande datatillstånd mellan partitioner.
Men om en minoritetspartition innehåller klienter som fortsätter att skriva till en mästare före failover, finns det en potential för skrivförlust. Redis mildrar denna risk genom att vägra skrivningar på minoritetssidan efter en timeout och på majoritetssidan genom att snabbt misslyckas över den oåtkomliga mästaren.
Trots dessa försiktighetsåtgärder kan skrivningar gå förlorade under failover -fönster eftersom Redis använder asynkron replikering mellan mästare och kopior. Eftersom svar på att skriva kommandon och replikationsuppdateringar skickas nästan samtidigt, är fönstret för att förlora skrivningar mycket smalt men inte omöjligt.
Konfigurationsalternativ som påverkar felhantering
Redis Cluster inkluderar konfigurationsalternativ som påverkar tillgänglighet och beteende under nodfel:
-`Cluster-Craquire-Full-Coverage '(Standard Ja): Klustret slutar att acceptera skriver om någon del av nyckelutrymmet avslöjas på grund av nodfel, vilket säkerställer stark datakonsistens.
-`Kluster-tillåtna-läser när det är ner (standard nr): Kontrollerar om läsningar är tillåtna när klustret är i ett felstillstånd. Att möjliggöra detta gör det möjligt för läsningar från noder även under delvis fel men kan riskera inaktuella data som serveras.
Dessa inställningar gör det möjligt för administratörer att balansera tillgänglighet och konsistens baserat på applikationskrav.
Manual Failover Support
Förutom Automatic Failover tillhandahåller Redis Cluster ett manuellt failover -kommando som kan utfärdas på repliknoder. Detta är användbart för underhålls- eller testningsscenarier där en administratör vill byta huvudroller utan att vänta på en verklig misslyckad händelse.
Manuell failover fungerar genom att blockera klienter på den nuvarande mästaren, vänta på att kopian ska komma ikapp och sedan främja kopian med en smidig atomövergång. Detta säkerställer ingen dataförlust under rollförändringen och minimal störning för klienterna.
Sammanfattning
Redis Cluster hanterar nodfel främst genom ett feldetekterings- och failover -system baserat på kontinuerlig övervakning via Redis -klusterbussen och ett skvallerprotokoll. Noder upptäcker oåtkomliga mästare och främjar kopior automatiskt efter en konsensusprocess som kräver att en majoritet av mästarna kommer överens om misslyckandet. Failover är utformat för att minimera dataförlust genom att säkerställa att kopior är helt synkroniserade före marknadsföring. Nätverkspartitioner hanteras via majoritetsbaserade beslut för att förhindra split-hjärnförhållanden, även om ett smalt fönster med skrivförlust kan uppstå på grund av asynkron replikering. Konfigurationsalternativ tillåter inställning av tillgänglighet kontra konsistens under fel, och manuella failover -kommandon ger operatörerna kontroll för underhåll.
Denna arkitektur gör det möjligt för Redis -kluster att ge hög tillgänglighet och partitiontolerans med automatisk återhämtning från masternodfel, vilket säkerställer att klustret förblir i drift och konsekvent under misslyckande scenarier.