Ako zlyhajú uzoly Redis Cluster

Komunikácia a detekcia zlyhania

Klastrové uzly Redis komunikujú prostredníctvom vyhradeného binárneho protokolu založeného na TCP nazývanom Redis Cluster Bus. Každý uzol udržiava pripojenia s každým iným uzlom v klastri pomocou tejto zbernice, čo umožňuje nepretržité zdravotné kontroly a šírenie štátu. Uzly pravidelne odosielajú pingové pakety, aby potvrdili prevádzkový stav svojich kolegov a zdieľal informácie o stave klastrov. Táto komunikácia využíva protokol klebety na efektívne šírenie informácií o klastri a pomáha pri detekcii porúch uzlov.

Uzly monitorujú rovesníkov pomocou aktívneho mechanizmu pingu. Ak uzol nereaguje na pingy v konfigurovanom období časového limitu (node_timeout), je označený ako zlyhanie so stavom PFAIL. Toto je indikácia predbežného zlyhania, čo znamená, že uzol by mohol byť nedostupný alebo dole, ale ešte nie je potvrdený. Ak podmienka PFAIL pretrváva a je potvrdená väčšinou hlavných uzlov, uzol je označený ako zlyhanie, čo naznačuje, že sa považuje za nedosiahnuteľný alebo dole klaster. Tento mechanizmus detekcie zlyhania založený na konsenzu pomáha predchádzať falošným pozitívam pri identifikácii neúspešných uzlov.

manipulovanie s zlyhaniami hlavného uzla

Ak je hlavný uzol označený ako zlyhanie, Redis Cluster iniciuje proces zlyhania na propagáciu jednej zo svojich replík, aby sa stal novým majstrom. Tento proces je spustený automaticky detektorom zlyhania klastrov bez administratívneho zásahu. Propagovaná replika preberá zodpovednosť za obsluhovanie hash slotov, ktoré predtým spravoval neúspešný majster, čím sa zabezpečuje, že klaster môže pokračovať v poskytovaní žiadostí bez manuálnej rekonfigurácie.

Zlyhanie sa vyskytuje iba vtedy, ak je k dispozícii aspoň jedna replika a dostupná na podporu. Ak neexistuje vhodná replika, klaster zadá chybový stav, kde prestane prijímať dotazy, aby sa zabránilo poskytovaniu nekonzistentných údajov. To zdôrazňuje dôležitosť nakonfigurovaných replík pre každý majster na udržanie vysokej dostupnosti.

Mechanika a bezpečnosť zlyhania

Počas zlyhania replika čaká na úplnú synchronizáciu s majstrom, ktorý nahrádza, čím sa zabezpečí, že spracuje všetky čakajúce aktualizácie, aby sa predišlo strate údajov. Dosahuje to tým, že sa zhoduje s replikáciou s hlavným majstrom, takže má aktuálny súbor údajov pred prevzatím hlavnej úlohy.

Po synchronizácii replika požaduje novú epochu konfigurácie z väčšiny majstrov. Epocha je logická časová pečiatka používaná na sledovanie zmien konfigurácie v klastri. Po získaní konsenzu replika vysiela aktualizovanú konfiguráciu na všetky uzly a oznámila svoju propagáciu na zvládnutie a democia starého Master na repliku alebo odstránenie.

Starý Master, keď sa obnoví, prijíma túto aktualizáciu konfigurácie a prestane slúžiť dotazov ako majstra. Presmeruje požiadavky klienta do nového Master a zabezpečuje, aby klienti transparentne pokračovali v interakcii s klastrom bez manuálneho zásahu.

Manipulácia s sieťovými oddielmi a scenárom rozdeleného mozgu

Redis Cluster využíva konsenzus založený na väčšine, aby sa predišlo problémom s rozdelením mozgu počas siete. Majster bude zlyhať iba vtedy, ak je nedosiahnuteľná viac ako polovica majstrov v klastri. Masters, ktorí nemôžu komunikovať s väčšinou, prestanú prijímať zápisy, ktoré zabránia divergentným údajom medzi oddielmi.

Ak však menšinový oddiel obsahuje klientov, ktorí pokračujú v písaní hlavnému predpisu pred zlyhaním, existuje potenciál na stratu zápisu. Redis zmierňuje toto riziko odmietnutím písať o menšinovej strane po časovom limite a na väčšinovej strane rýchlym zlyhaním nad nedostupným majstrom.

Napriek týmto bezpečnostným opatreniam sa môžu zápisy stratiť počas Windows Failover Windows, pretože Redis používa asynchrónnu replikáciu medzi majstrov a replikami. Pretože odpovede na písanie príkazov a aktualizácií replikácií sa odosielajú takmer súčasne, okno na stratu zápisov je veľmi úzke, ale nie nemožné.

Možnosti konfigurácie ovplyvňujúce spracovanie zlyhania

Redis Cluster obsahuje možnosti konfigurácie, ktoré ovplyvňujú dostupnosť a správanie počas zlyhaní uzlov:

-`Cluster-Require-Full-Coverage` (predvolené ÁNO): Klaster prestane prijímať zápisy, ak je niektorá časť kľúčového priestoru odkrytá v dôsledku zlyhaní uzlov, čím sa zabezpečí silná konzistentnosť údajov.
-`Cluster-Talt-Reads-When-Down` (predvolené číslo): Ovláda, či sú čítania povolené, keď je klaster v stave zlyhania. Povolenie tohto umožňuje čítania z uzlov aj počas čiastočných zlyhaní, ale môžu riskovať, že sa poskytujú zastarané údaje.

Tieto nastavenia umožňujú správcom vyvážiť dostupnosť a konzistentnosť na základe požiadaviek na aplikáciu.

manuálna podpora zlyhania

Okrem automatického zlyhania poskytuje Redis Cluster príkaz manuálneho zlyhania, ktorý je možné vydať na replikach. Je to užitočné pre scenáre údržby alebo testovania, kde si správca chce vymeniť hlavné role bez čakania na skutočnú udalosť zlyhania.

Manuálne zlyhanie funguje tak, že blokuje klientov na súčasnom majstre, čaká na úplnú dobu repliky a potom propaguje repliku hladkým atómovým prechodom. To zaisťuje žiadnu stratu údajov počas zmeny úloh a minimálneho narušenia klientov.

Zhrnutie

Redis Cluster spracováva zlyhania uzlov predovšetkým prostredníctvom systému detekcie porúch a zlyhania založeného na kontinuálnom monitorovaní prostredníctvom zbernice klastra Redis a protokolom klebety. Uzly zistia nedosiahnuteľné majstrov a automaticky propagujú repliky po konsenzuálnom procese, ktorý vyžaduje, aby väčšina majstrov súhlasila s zlyhaním. Failover je navrhnutý tak, aby minimalizoval stratu údajov zabezpečením úplného synchronizácie replík pred propagáciou. Sieťové oddiely sú spravované prostredníctvom rozhodnutí založených na väčšine s cieľom zabrániť podmienkam rozdeleného mozgu, hoci v dôsledku asynchrónnej replikácie sa môže vyskytnúť úzke okno straty zápisu. Možnosti konfigurácie umožňujú ladenie dostupnosti verzus konzistentnosť počas zlyhaní a príkazy manuálneho zlyhania poskytujú operátorom kontrolu údržby.