Klaster Redis obsługuje awarie węzłów poprzez połączenie wykrywania awarii, promocji repliki i zarządzania stanem klastrów, aby zapewnić dalszą obsługę i dostępność danych. Został zaprojektowany w celu przetrwania awarii kilku węzłów poprzez automatyczne promowanie replików w celu zastąpienia nieosiągalnych mistrzów, utrzymując integralność kluczowej przestrzeni przy jednoczesnym minimalizowaniu ryzyka utraty danych.
Komunikacja klastra i wykrywanie awarii
Węzły klastra Redis komunikują się za pośrednictwem dedykowanego protokołu binarnego opartego na TCP o nazwie Redis Cluster Bus. Każdy węzeł utrzymuje połączenia z każdym innym węzłem w klastrze za pomocą tej magistrali, umożliwiając ciągłe kontrole zdrowia i propagacja stanu. Węzły okresowo wysyłają pakiety ping, aby potwierdzić status operacyjny swoich rówieśników i dzielą się informacjami o stanie klastra. Ta komunikacja wykorzystuje protokół plotek do skutecznego rozpowszechniania informacji o klastrze, pomagając w wykrywaniu awarii węzłów.
Węzły monitorują rówieśników za pomocą aktywnego mechanizmu ping. Jeśli węzeł nie reaguje na PING w skonfigurowanym okresie limitu czasu (Node_timeout), jest on oznaczony jako prawdopodobnie niepowodzenie ze statusem PFAIL. Jest to niepewna wskazanie awarii, co oznacza, że węzeł może być nieosiągalny lub w dół, ale nie jest jeszcze potwierdzony. Jeżeli warunek PFAIL utrzymuje się i zostanie potwierdzony przez większość głównych węzłów, węzeł jest oznaczony jako niepowodzenie, co wskazuje, że jest uważany za nieosiągalny lub w dół przez klaster. Ten mechanizm wykrywania awarii oparty na konsensusie pomaga zapobiec fałszywym pozytywom w identyfikacji nieudanych węzłów.
Obsługa awarii węzłów głównych
Gdy węzeł główny jest oznaczony jako Fail, Redis Cluster inicjuje proces awaryjnego promowania jednej z jego replik, aby stać się nowym Mistrzem. Proces ten jest automatycznie uruchamiany przez detektor niepowodzenia klastra bez interwencji administracyjnej. Promowana replika przejmuje odpowiedzialność za obsługę szczelin skrótów wcześniej zarządzanych przez nieudanego mistrza, zapewniając, że klaster może kontynuować podawanie żądań bez ręcznej rekonfiguracji.
Przełączanie awaryjne występuje tylko wtedy, gdy dostępna jest co najmniej jedna replika i osiągana do promowania. Jeśli nie istnieje odpowiednia replika, klaster wchodzi w stan błędu, w którym przestanie przyjmować zapytania, aby zapobiec obsłudze niespójnych danych. Podkreśla to znaczenie skonfigurowania replik dla każdego głównego w celu utrzymania wysokiej dostępności.
Mechanika awaryjnego i bezpieczeństwo
Podczas przełączania awaryjnego repliki czekają całkowicie zsynchronizowane z głównym zastępowaniem, zapewniając przetworzenie wszystkich oczekujących aktualizacji, aby uniknąć utraty danych. Osiąga to poprzez dopasowanie przesunięcia replikacji do Master, dzięki czemu ma aktualny zestaw danych przed przejęciem roli głównej.
Po zsynchronizowaniu replica żąda nowej epoki konfiguracyjnej od większości mistrzów. Epoka to logiczny znacznik czasu używany do śledzenia zmian konfiguracji w klastrze. Po uzyskaniu konsensusu replica nadaje zaktualizowaną konfigurację do wszystkich węzłów, ogłaszając jego promocję do Master i degradację starego mistrza do repliki lub usunięcia.
Stary Master, kiedy odzyskuje odzyskuje, odbiera tę aktualizację konfiguracji i przestaje podawać zapytania jako mistrz. Przekierowuje żądania klienta do nowego Mistrza, zapewniając, że klienci przejrzyste w interakcje z klastrem bez ręcznej interwencji.
Postępowanie sieciowe i scenariusze podzielone
Klaster Redis wykorzystuje konsensus oparty na większości, aby uniknąć problemów z podziałem mózgu podczas partycji sieciowych. Mistrz zostanie nie powtórzony tylko wtedy, gdy nie jest onoosobne przez ponad połowę mistrzów w klastrze. Mistrzowie, którzy nie mogą komunikować się z większością, przestaną przyjmować zapisy, zapobiegając rozbieżnym stanom danych między partycjami.
Jeśli jednak partycja mniejszościowa zawiera klientów, którzy kontynuują pisanie do mistrza przed przełączeniem awaryjnym, istnieje możliwość utraty pisania. Redis łagodzi to ryzyko, odmawiając zapisów po stronie mniejszości po limicie limitu czasu i na większości, szybko niepełnosprawne nad nieosiągalnym mistrzem.
Pomimo tych środków ostrożności, zapisy można utracić podczas okien przełączania awaryjnego, ponieważ Redis używa asynchronicznej replikacji między mistrzami i replikami. Ponieważ odpowiedzi na pisanie poleceń i aktualizacje replikacji są wysyłane prawie jednocześnie, okno do utraty pisze jest bardzo wąskie, ale nie niemożliwe.
Opcje konfiguracji wpływające na obsługę awarii
Klaster Redis obejmuje opcje konfiguracji, które wpływają na dostępność i zachowanie podczas awarii węzłów:
-`` Cluster-Require-Full-Coverage` (domyślnie tak): Klaster przestaje akceptować zapisy, jeśli jakakolwiek część kluczowej przestrzeni zostanie odkryta z powodu awarii węzłów, zapewniając silną spójność danych.
-`Cluster-Allow-Reads-When-Down` (domyślne nie): kontrola, czy odczyty są dozwolone, gdy klaster jest w stanie awarii. Włączenie to pozwala na odczyty z węzłów nawet podczas częściowych awarii, ale może ryzykować obsługiwane dane.
Ustawienia te pozwalają administratorom równoważyć dostępność i spójność na podstawie wymagań aplikacji.
Manual Failover Support
Oprócz automatycznego przełączania awaryjnego klaster Redis zapewnia ręczne polecenie awaryjne, które można wydać w węzłach repliki. Jest to przydatne do scenariuszy konserwacji lub testowania, w których administrator chce zamienić role główne bez oczekiwania na faktyczne zdarzenie awarii.
Ręczne przełączanie awaryjne działa poprzez blokowanie klientów na obecnym mistrzu, czekając na pełne nadrabianie zaległości, a następnie promowanie repliki za pomocą płynnego przejścia atomowego. Nie zapewnia to utraty danych podczas zmiany roli i minimalnych zakłóceń klientów.
Streszczenie
Klaster Redis obsługuje awarie węzłów przede wszystkim poprzez system wykrywania uszkodzeń i systemu awaryjnego opartego na ciągłym monitorowaniu za pośrednictwem magistrali klastra Redis i protokołu plotek. Węzły wykrywają nieosiągalnych mistrzów i automatycznie promują repliki po procesie konsensusu wymagającym, że większość mistrzów uzgodniła awarię. Przewodniczący jest zaprojektowany w celu zminimalizowania utraty danych poprzez zapewnienie w pełni zsynchronizowania replików przed promocją. Particje sieciowe są zarządzane za pomocą decyzji opartych na większości, aby zapobiec warunkom podzielonego mózgu, chociaż może wystąpić wąskie okno utraty zapisu z powodu replikacji asynchronicznej. Opcje konfiguracji umożliwiają dostrajanie dostępności w porównaniu do spójności podczas awarii, a ręczne polecenia awaryjne zapewniają operatorom kontrolę w celu konserwacji.
Ta architektura umożliwia klastrze Redis zapewnienie wysokiej dostępności i tolerancji partycji dzięki automatycznemu odzyskiwaniu z awarii węzłów głównych, zapewniając, że klaster pozostaje operacyjny i spójny w scenariuszach awarii.