Hoe gaat Redis Cluster om met knooppuntfouten

Clustercommunicatie en faaldetectie

Redis-clusterknooppunten communiceren via een speciaal TCP-gebaseerd binair protocol genaamd de Redis Cluster Bus. Elk knooppunt onderhoudt verbindingen met elk ander knooppunt in het cluster met behulp van deze bus, waardoor continue gezondheidscontroles en staatspropagatie mogelijk worden. Knooppunten sturen periodiek pingpakketten om de operationele status van hun collega's te bevestigen en informatie te delen over de staat van het cluster. Deze communicatie maakt gebruik van een roddelprotocol om clusterinformatie efficiënt te verspreiden, die helpt bij de detectie van knooppuntfalen.

Knooppunten bewaken collega's met behulp van een actief pingmechanisme. Als een knooppunt niet reageert op pings binnen een geconfigureerde time -outperiode (Node_Timeout), wordt het gemarkeerd als mogelijk mislukt met een PFAIL -status. Dit is een voorlopige faalindicatie, wat betekent dat het knooppunt onbereikbaar of omlaag kan zijn, maar het is nog niet bevestigd. Als de PFAIL -toestand aanhoudt en wordt bevestigd door een meerderheid van de hoofdknooppunten, wordt het knooppunt gemarkeerd als mislukt, wat aangeeft dat het door het cluster als onbereikbaar wordt beschouwd. Dit op consensus gebaseerde faaldetectiemechanisme helpt valse positieven te voorkomen bij het identificeren van mislukte knooppunten.

hantering master knooppunt storingen

Wanneer een masternode wordt gemarkeerd als mislukt, initieert Redis Cluster een failover -proces om een ​​van zijn replica's te promoten om de nieuwe meester te worden. Dit proces wordt automatisch geactiveerd door de faaldetector van het cluster zonder administratieve interventie. De gepromoveerde replica neemt de verantwoordelijkheid over om de hash -slots te bedienen die eerder door de mislukte master werden beheerd, zodat het cluster verzoeken kan blijven bedienen zonder handmatige herconfiguratie.

Failover treedt alleen op als er ten minste één replica beschikbaar en bereikbaar is om te promoten. Als er geen geschikte replica bestaat, voert het cluster een foutstatus in waar het niet meer query's accepteert om inconsistente gegevens te voorkomen. Dit benadrukt het belang van replica's die voor elke master worden geconfigureerd om een ​​hoge beschikbaarheid te behouden.

Failover -mechanica en veiligheid

Tijdens failover wacht de replica om volledig te synchroniseren met de master die hij vervangt, zodat het alle lopende updates heeft verwerkt om gegevensverlies te voorkomen. Het bereikt dit door de replicatie-offset te matchen met de master, zodat deze een up-to-date dataset heeft voordat hij de hoofdrol op zich neemt.

Eenmaal gesynchroniseerd, vraagt ​​de replica om een ​​nieuw configuratie -tijdperk van een meerderheid van de meesters. Het tijdperk is een logisch tijdstempel dat wordt gebruikt om configuratiewijzigingen in het cluster bij te houden. Na het verkrijgen van consensus zendt de replica de bijgewerkte configuratie uit naar alle knooppunten, en kondigt de promotie van Master en de degradatie van de oude master aan om te replica of verwijdering.

De oude master, wanneer hij herstelt, ontvangt deze configuratie -update en stopt met het bedienen van query's als master. Het wordt klantverzoeken omgeleid naar de nieuwe master, zodat klanten transparant blijven interactie met het cluster zonder handmatige interventie.

Handeling netwerkpartities en split-brain scenario's

Redis Cluster maakt gebruik van meerderheidsgebaseerde consensus om problemen met gesplitste hersenen tijdens netwerkpartities te voorkomen. Een meester zal alleen niet door de hand liggen als deze door meer dan de helft van de meesters in het cluster onbereikbaar is. Masters die niet met de meerderheid kunnen communiceren, zullen stoppen met het accepteren van schrijven, waardoor uiteenlopende gegevensstaten tussen partities worden voorkomen.

Als een minderheidspartitie echter klanten bevat die blijven schrijven naar een master vóór failover, is er een potentieel voor schrijfverlies. Redis vermindert dit risico door te weigeren schrijft aan de minderheidszijde na een time -out en aan de meerderheid van de kant door snel te falen over de onbereikbare meester.

Ondanks deze voorzorgsmaatregelen kunnen schrijven verloren gaan tijdens failover -vensters omdat Redis asynchrone replicatie tussen meesters en replica's gebruikt. Aangezien antwoorden om opdrachten en replicatie -updates te schrijven bijna gelijktijdig worden verzonden, is het venster voor het verliezen van schrijfwerk erg smal maar niet onmogelijk.

Configuratie -opties die van invloed zijn op het afhandelen van de fout

Redis Cluster bevat configuratie -opties die de beschikbaarheid en gedrag beïnvloeden tijdens knooppuntfouten:

-`Cluster-require-full-coverage` (standaard ja): het cluster stopt met het accepteren van schrijft of een deel van de sleutelruimte wordt ontdekt vanwege knooppuntfouten, waardoor een sterke gegevensconsistentie wordt gewaarborgd.
-`Cluster-allow-reads-When-Down` (standaard NO): regelt of lezingen zijn toegestaan ​​wanneer het cluster in een foutstatus staat. Als u dit inschakelt, kunt u lezen van knooppunten, zelfs tijdens gedeeltelijke storingen, maar kunnen het risico lopen dat malde gegevens worden geserveerd.

Met deze instellingen kunnen beheerders de beschikbaarheid en consistentie in evenwicht brengen op basis van toepassingsvereisten.

handmatige failover -ondersteuning

Naast automatische failover biedt Redis Cluster een handmatig failover -opdracht dat op replica -knooppunten kan worden uitgegeven. Dit is handig voor onderhouds- of testscenario's waarbij een beheerder masterrollen wil ruilen zonder te wachten op een daadwerkelijke faalgebeurtenis.

Handmatige failover werkt door klanten op de huidige master te blokkeren, wachtend op de replica om volledig in te halen en vervolgens de replica te promoten met een soepele atoomovergang. Dit zorgt voor geen gegevensverlies tijdens de rolverandering en minimale verstoring van klanten.

Samenvatting

Redis Cluster verwerkt knooppuntfouten, voornamelijk door een foutdetectie en failover -systeem op basis van continue monitoring via de Redis -clusterbus en een roddelprotocol. Knooppunten detecteren onbereikbare meesters en promoten replica's automatisch na een consensusproces waarbij een meerderheid van de meesters moet worden over het falen. Failover is ontworpen om gegevensverlies te minimaliseren door ervoor te zorgen dat replica's volledig worden gesynchroniseerd vóór promotie. Netwerkpartities worden beheerd via meerderheidsgebaseerde beslissingen om split-brain-omstandigheden te voorkomen, hoewel een smal venster van schrijfverlies kan optreden als gevolg van asynchrone replicatie. Configuratie -opties maken de afstemming van beschikbaarheid versus consistentie tijdens storingen mogelijk, en handmatige failover -opdrachten geven operators controle voor onderhoud.