Redis Cluster zpracovává selhání uzlů prostřednictvím kombinace detekce selhání, propagace repliky a správy stavu clusteru, aby byla zajištěna pokračující provoz a dostupnost dat. Je navržen tak, aby přežil selhání několika uzlů automaticky propagací replik, aby nahradil nedosažitelné pány, udržoval integritu klíčového prostoru a zároveň minimalizoval rizika ztráty dat.
Clusterová komunikace a detekce selhání
Uzly redis klastru komunikují prostřednictvím vyhrazeného binárního protokolu založeného na TCP s názvem Cluster Redis Cluster Bus. Každý uzel udržuje spojení s každým dalším uzlem v klastru pomocí této sběrnice, což umožňuje nepřetržité zdravotní kontroly a šíření stavu. Uzly pravidelně odesílají pakety ping, aby potvrdily provozní stav svých vrstevníků a sdílely informace o stavu klastru. Tato komunikace používá protokol o drby k efektivnímu šíření informací o klastru a napomáhá detekci selhání uzlů.
Uzly monitorují vrstevníky pomocí aktivního mechanismu ping. Pokud uzel nereaguje na Pings v nakonfigurovaném období časového limitu (Node_timeout), je označen jako možná selhání se stavem PFAIL. Toto je předběžná indikace selhání, což znamená, že uzel může být nedosažitelný nebo dolů, ale dosud není potvrzen. Pokud podmínka PFAIL přetrvává a je potvrzena většinou hlavních uzlů, uzel je označen jako selhání, což naznačuje, že je klastr považován za nedotknutelný nebo dolů. Tento mechanismus detekce poruch založeného na konsensu pomáhá předcházet falešným pozitivům při identifikaci neúspěšných uzlů.
Manipulace s poruchami hlavního uzlu
Když je hlavní uzel označen jako FAIL, Redis Cluster zahajuje proces převzetí služeb při selhání, aby propagoval jednu z jeho repliky, aby se stal novým mistrem. Tento proces je automaticky spuštěn detektorem selhání klastru bez administrativního zásahu. Propagovaná replika přebírá odpovědnost za obsluhování hashových slotů dříve spravovaných neúspěšným pánem a zajišťuje, že klastr může pokračovat v podávání žádostí o manuální rekonfiguraci.
K převzetí služeb při selhání dochází pouze v případě, že je k dispozici alespoň jedna replika a dosažitelná. Pokud neexistuje žádná vhodná replika, klastr vstoupí do stavu chyby, kde přestane přijímat dotazy, aby se zabránilo podávání nekonzistentních dat. To zdůrazňuje důležitost toho, že repliky nakonfigurují pro každého masara, aby si udrželi vysokou dostupnost.
Mechanika a bezpečnost převzetí služeb při selhání
Během převzetí služeb při selhání replika čeká na úplnou synchronizaci s Masterem, který nahrazuje, a zajišťuje, že zpracoval všechny čekající aktualizace, aby se zabránilo ztrátě dat. Dosáhne toho tím, že porovnáte replikační offset s Master, takže má aktuální datový soubor před převzetím hlavní role.
Po synchronizaci replika požaduje novou konfigurační epochu od většiny mistrů. Epocha je logické časové razítko používané ke sledování změn konfigurace v klastru. Po získání konsensu Replica vysílá aktualizovanou konfiguraci do všech uzlů a oznámí svou propagaci Master a demotion Old Master na repliku nebo odstranění.
Old Master, když se zotaví, obdrží tuto konfigurační aktualizaci a přestane sloužit dotazy jako mistr. Přesměruje požadavky klienta na nového masteru a zajišťuje, aby klienti transparentně nadále interagovali s klastrem bez manuálního zásahu.
Manipulace s síťovými oddíly a scénáře rozdělení mozku
Cluster Redis používá konsenzus založenou na většině, aby se zabránilo problémům s rozdělením mozku během oddílů v síti. Mistr bude selhán, pouze pokud je nedosažitelný více než polovinou mistrů v klastru. Mistři, kteří nemohou komunikovat s většinou, přestanou přijímat zápisy a zabrání divergentním datům mezi oddíly.
Pokud však menšinový oddíl obsahuje klienty, kteří pokračují v psaní mistra před převzetí služeb při selhání, existuje potenciál pro ztrátu zápisu. Redis zmírňuje toto riziko tím, že odmítá píše na straně menšiny po časovém limitu a na většinové straně rychlým selháním nad nedostatkem mistra.
Navzdory těmto opatřením mohou být zápisy ztraceny během oken převzetí služeb při selhání, protože REDIS používá asynchronní replikaci mezi Masters a Replicas. Protože odpovědi na psaní příkazů a aktualizace replikace jsou odesílány téměř současně, okno pro ztrátu zápisů je velmi úzké, ale ne nemožné.
Možnosti konfigurace ovlivňující manipulaci s poruchami
Cluster Redis obsahuje možnosti konfigurace, které ovlivňují dostupnost a chování během selhání uzlu:
-`Cluster-Require-Full-Coverage` (výchozí ano): Cluster přestane přijímat, že píše, zda je nějaká část klíčového prostoru odkryta kvůli selhání uzlu, což zajišťuje silnou konzistenci dat.
-`Cluster-Poallow-Reads-When-Down` (výchozí č.): Řídí, zda jsou čtení povoleno, když je klastr ve stavu selhání. Povolení tohoto umožnění čtení z uzlů i během částečných selhání, ale může riskovat, že se doručují zatuchlá data.
Tato nastavení umožňují správcům vyvážit dostupnost a konzistenci na základě požadavků na aplikaci.
Podpora ručního převzetí služeb
Kromě automatického převzetí služeb při selhání poskytuje klastr REDIS manuální příkaz převzetí služeb při selhání, který lze vydat na uzlech repliky. To je užitečné pro scénáře údržby nebo testování, kde si správce přeje vyměnit hlavní role, aniž by čekal na skutečnou událost selhání.
Manuální převzetí služeb při selhání funguje tak, že blokuje klienty na současném masteru, čekáme, až replika plně dohná a poté propaguje repliku hladký atomový přechod. Tím je zajištěna žádná ztráta dat během změny role a minimální narušení klientů.
Shrnutí
Redis Cluster zpracovává selhání uzlů primárně prostřednictvím detekce poruch a systému převzetí služeb při selhání založené na nepřetržitém monitorování prostřednictvím sběrnice Redis Cluster a protokol o drby. Uzly detekují nedosažitelné pány a automaticky propagují repliky po konsensuálním procesu, který vyžaduje, aby se většina mistrů dohodla na selhání. Převzetí služeb při selhání je navrženo tak, aby minimalizovalo ztrátu dat zajištěním plně synchronizovaných replik před propagací. Síťové oddíly jsou spravovány prostřednictvím většinových rozhodnutí, aby se zabránilo podmínkám s rozdělením mozku, ačkoli v důsledku asynchronní replikace může dojít k úzkému okně ztráty zápisu. Možnosti konfigurace umožňují vyladění dostupnosti versus konzistence během selhání a příkazy ručního převzetí služeb při selhání poskytují operátorům kontrolu pro údržbu.
Tato architektura umožňuje klastru Redis poskytovat vysokou dostupnost a toleranci oddílů s automatickým zotavením z poruch hlavních uzlů, což zajišťuje, že klastr zůstává funkční a konzistentní ve scénářích selhání.