Tolerance chyb a vysoká dostupnost jsou velká témata, proto budeme RabbitMQ a Kafkovi věnovat samostatné články. Tento článek je o RabbitMQ a další je o Kafkovi ve srovnání s RabbitMQ. Toto je dlouhý článek, tak si udělejte pohodlí.

Podívejme se na strategie odolnosti proti chybám, konzistence a vysoké dostupnosti (HA) a na kompromisy, které každá strategie přináší. RabbitMQ může běžet na shluku uzlů – a je pak klasifikován jako distribuovaný systém. Pokud jde o distribuované systémy, často mluvíme o konzistenci a dostupnosti.

Tyto pojmy popisují, jak se systém chová, když selže. Selhání síťového připojení, selhání serveru, selhání pevného disku, dočasná nedostupnost serveru z důvodu sběru odpadu, ztráty paketů nebo zpomalení síťového připojení. To vše může vést ke ztrátě dat nebo konfliktům. Ukazuje se, že je prakticky nemožné postavit systém, který by byl jak zcela konzistentní (žádná ztráta dat, žádná divergence dat), tak dostupný (bude akceptovat čtení i zápis) pro všechny scénáře selhání.

Uvidíme, že konzistence a dostupnost jsou na opačných koncích spektra a vy si musíte vybrat způsob optimalizace. Dobrou zprávou je, že s RabbitMQ je tato volba možná. Máte tyto „nerdy“ páky, které posunou rovnováhu směrem k větší konzistenci nebo lepší dostupnosti.

Zvláštní pozornost budeme věnovat tomu, které konfigurace vedou ke ztrátě dat kvůli potvrzeným záznamům. Mezi vydavateli, makléři a spotřebiteli existuje řetězec odpovědnosti. Jakmile je zpráva předána brokerovi, je jeho úkolem zprávu neztratit. Když zprostředkovatel potvrdí vydavateli přijetí zprávy, neočekáváme, že se ztratí. Ale uvidíme, že k tomu může skutečně dojít v závislosti na konfiguraci vašeho brokera a vydavatele.

Primitives Resilience Single Node

Odolné řazení/směrování

V RabbitMQ existují dva typy front: trvanlivé a netrvanlivé. Všechny fronty jsou uloženy v databázi Mnesia. Odolné fronty jsou znovu inzerovány při spuštění uzlu, a tak přežijí restartování, selhání systému nebo selhání serveru (pokud jsou data zachována). To znamená, že pokud prohlásíte směrování (výměnu) a frontu za odolné, infrastruktura řazení/směrování se vrátí do režimu online.

Nestálé fronty a směrování jsou odstraněny při restartování uzlu.

Trvalé zprávy

To, že je fronta odolná, neznamená, že všechny její zprávy přežijí restart uzlu. Pouze zprávy nastavené vydavatelem jako udržitelné (vytrvalý). Trvalé zprávy vytvářejí další zátěž pro brokera, ale pokud je ztráta zpráv nepřijatelná, pak neexistuje žádná jiná možnost.

Rýže. 1. Matice udržitelnosti

Shlukování pomocí zrcadlení fronty

Abychom přežili ztrátu makléře, potřebujeme redundanci. Můžeme zkombinovat více uzlů RabbitMQ do clusteru a poté přidat další redundanci replikací front mezi více uzly. Tímto způsobem, pokud jeden uzel selže, neztratíme data a zůstaneme k dispozici.

Zrcadlení fronty:

• jedna hlavní fronta (master), která přijímá všechny příkazy pro zápis a čtení
• jedno nebo více zrcadel, která přijímají všechny zprávy a metadata z hlavní fronty. Tato zrcátka tu nejsou kvůli škálování, ale čistě kvůli redundanci.

Rýže. 2. Zrcadlení fronty

Zrcadlení je nastaveno příslušnou politikou. V něm můžete vybrat koeficient replikace a dokonce i uzly, na kterých se má fronta nacházet. Příklady:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (jeden mistr a jedno zrcadlo)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

Potvrzení vydavatele

Chcete-li dosáhnout konzistentního záznamu, jsou vyžadována potvrzení vydavatele. Bez nich hrozí ztráta zpráv. Po zapsání zprávy na disk je vydavateli odesláno potvrzení. RabbitMQ zapisuje zprávy na disk nikoli po přijetí, ale pravidelně, v rozsahu několika set milisekund. Při zrcadlení fronty je potvrzení odesláno až poté, co všechna zrcadla také zapíší svou kopii zprávy na disk. To znamená, že použití potvrzení zvyšuje latenci, ale pokud je důležité zabezpečení dat, pak jsou nezbytné.

Fronta převzetí služeb při selhání

Když se broker ukončí nebo zhroutí, všichni vedoucí fronty (master) na tomto uzlu se zhroutí spolu s ním. Cluster pak vybere nejstarší zrcadlo každého masteru a povýší ho jako nový master.

Rýže. 3. Vícenásobné zrcadlené fronty a jejich zásady

Broker 3 klesá. Všimněte si, že zrcadlo Queue C na Broker 2 je povýšeno na hlavní. Všimněte si také, že bylo vytvořeno nové zrcadlo pro frontu C na Broker 1. RabbitMQ se vždy pokouší zachovat replikační faktor uvedený ve vašich zásadách.

Rýže. 4. Broker 3 selže, což způsobí selhání fronty C

Další Broker 1 padá! Zůstal nám pouze jeden makléř. Zrcadlo fronty B je povýšeno na hlavní.

Obr. 5

Vrátili jsme Broker 1. Bez ohledu na to, jak dobře data přežijí ztrátu a obnovu brokera, všechny zprávy zrcadlené fronty jsou po restartu zahozeny. To je důležité si uvědomit, protože to bude mít následky. Brzy se na tyto důsledky podíváme. Broker 1 je tedy nyní opět členem clusteru a cluster se snaží dodržovat zásady, a proto vytváří zrcadla na Broker 1.

V tomto případě byla ztráta Brokera 1 úplná, stejně jako data, takže nezrcadlená fronta B byla zcela ztracena.

Rýže. 6. Makléř 1 se vrací do provozu

Broker 3 je opět online, takže fronty A a B získají zpět zrcadla vytvořená na něm, aby splnily své zásady HA. Ale nyní jsou všechny hlavní fronty na jednom uzlu! To není ideální, lepší je rovnoměrné rozložení mezi uzly. Bohužel zde není mnoho možností pro rebalancování mistrů. K tomuto problému se vrátíme později, protože se nejprve musíme podívat na synchronizaci fronty.

Rýže. 7. Broker 3 se vrací do provozu. Všechny hlavní fronty na jednom uzlu!

Nyní byste tedy měli mít představu o tom, jak zrcadla poskytují redundanci a odolnost proti chybám. To zajišťuje dostupnost v případě selhání jednoho uzlu a chrání před ztrátou dat. Ale ještě nekončíme, protože ve skutečnosti je to mnohem složitější.

Synchronizace

Při vytváření nového zrcadla budou všechny nové zprávy vždy replikovány do tohoto zrcadla a všech ostatních. Pokud jde o stávající data v hlavní frontě, můžeme je replikovat do nového zrcadla, které se stane úplnou kopií hlavního. Můžeme se také rozhodnout nereplikovat existující zprávy a nechat hlavní frontu a nové zrcadlo, aby se v čase sblížily, přičemž nové zprávy dorazí na konci a stávající zprávy opustí hlavní frontu.

Tato synchronizace se provádí automaticky nebo ručně a je spravována pomocí zásad fronty. Podívejme se na příklad.

Máme dvě zrcadlené fronty. Fronta A je synchronizována automaticky a fronta B je synchronizována ručně. Obě fronty obsahují deset zpráv.

Rýže. 8. Dvě fronty s různými režimy synchronizace

Nyní ztrácíme Broker 3.

Rýže. 9. Broker 3 padl

Broker 3 se vrací do provozu. Cluster vytvoří zrcadlo pro každou frontu na novém uzlu a automaticky synchronizuje novou frontu A s hlavním serverem. Zrcadlo nové fronty B však zůstává prázdné. Tímto způsobem máme plnou redundanci na frontě A a pouze jedno zrcadlo pro existující zprávy fronty B.

Rýže. 10. Nové zrcadlo fronty A přijímá všechny existující zprávy, ale nové zrcadlo fronty B nikoli.

Do obou front dorazí dalších deset zpráv. Broker 2 poté havaruje a fronta A se vrátí zpět k nejstaršímu zrcadlu, které je na Broker 1. Při jeho selhání nedochází ke ztrátě dat. Ve frontě B je dvacet zpráv v hlavním serveru a pouze deset v zrcadlení, protože tato fronta nikdy nereplikovala původních deset zpráv.

Rýže. 11. Fronta A se vrátí zpět na Broker 1 bez ztráty zpráv

Do obou front dorazí dalších deset zpráv. Nyní se zhroutí Broker 1. Fronta A se snadno přepne na zrcadlení bez ztráty zpráv. Fronta B má však problémy. V tomto okamžiku můžeme optimalizovat dostupnost nebo konzistenci.

Pokud chceme optimalizovat přístupnost, pak politiku ha-promote-on-failure by měl být instalován v vždy. Toto je výchozí hodnota, takže politiku prostě nemůžete vůbec specifikovat. V tomto případě v podstatě umožňujeme selhání v nesynchronizovaných zrcadlech. To způsobí ztrátu zpráv, ale fronta zůstane čitelná a zapisovatelná.

Rýže. 12. Fronta A je vrácena zpět do Broker 3 bez ztráty zpráv. Fronta B se vrátí zpět na Broker 3 s deseti ztracenými zprávami

Můžeme také nainstalovat ha-promote-on-failure do smyslu when-synced. V tomto případě bude fronta místo návratu k zrcadlu čekat, dokud se Broker 1 se svými daty nevrátí do online režimu. Po návratu je hlavní fronta zpět na Broker 1 bez ztráty dat. Dostupnost je obětována bezpečnosti dat. Jde ale o riskantní režim, který může vést i k úplné ztrátě dat, na což se zanedlouho podíváme.

Rýže. 13. Po ztrátě Brokera 1 zůstává fronta B nedostupná

Můžete se zeptat: "Je lepší nikdy nepoužívat automatickou synchronizaci?" Odpověď je, že synchronizace je blokující operace. Během synchronizace nemůže hlavní fronta provádět žádné operace čtení ani zápisu!

Podívejme se na příklad. Nyní máme velmi dlouhé fronty. Jak mohou dorůst do takové velikosti? Z několika důvodů:

• Fronty nejsou aktivně využívány
• Jedná se o vysokorychlostní fronty a právě teď jsou spotřebitelé pomalí
• Jsou to vysokorychlostní fronty, došlo k závadě a spotřebitelé to dohánějí

Rýže. 14. Dvě velké fronty s různými režimy synchronizace

Nyní Broker 3 padá.

Rýže. 15. Broker 3 padá a v každé frontě zůstává jeden master a mirror

Broker 3 se vrací online a jsou vytvořena nová zrcadla. Hlavní fronta A začne replikovat existující zprávy do nového zrcadla a během této doby je fronta nedostupná. Replikace dat trvá dvě hodiny, což má za následek dvě hodiny výpadku této fronty!

Fronta B však zůstává k dispozici po celou dobu. Kvůli dostupnosti obětovala určitou nadbytečnost.

Rýže. 16. Fronta zůstává během synchronizace nedostupná

Po dvou hodinách se zpřístupní také fronta A a může začít znovu přijímat čtení a zápis.

Aktualizace

Toto chování blokování během synchronizace ztěžuje aktualizaci clusterů s velmi velkými frontami. V určitém okamžiku je třeba restartovat hlavní uzel, což znamená buď přepnutí na zrcadlo, nebo deaktivaci fronty během upgradu serveru. Pokud se rozhodneme pro přechod, ztratíme zprávy, pokud nebudou zrcadla synchronizována. Ve výchozím nastavení se během výpadku zprostředkovatele neprovádí převzetí služeb při selhání do nesynchronizovaného zrcadla. To znamená, že jakmile se broker vrátí, neztratíme žádné zprávy, jedinou škodou byla obyčejná fronta. Pravidla chování při odpojení brokera jsou dána zásadami ha-promote-on-shutdown. Můžete nastavit jednu ze dvou hodnot:

• always= přechod na nesynchronizovaná zrcadla je povolen
• when-synced= přechod pouze na synchronizované zrcadlo, jinak se fronta stane nečitelnou a nezapisovatelnou. Fronta se vrátí do služby, jakmile se zprostředkovatel vrátí

Tak či onak, u velkých front si musíte vybrat mezi ztrátou dat a nedostupností.

Když dostupnost zlepšuje zabezpečení dat

Před rozhodnutím je třeba zvážit ještě jednu komplikaci. Automatická synchronizace je sice lepší pro redundanci, ale jaký má dopad na bezpečnost dat? S lepší redundancí je samozřejmě menší pravděpodobnost, že RabbitMQ ztratí stávající zprávy, ale co nové zprávy od vydavatelů?

Zde je třeba zvážit následující:

• Mohl by vydavatel jednoduše vrátit chybu a nechat službu nebo uživatele, aby to zkusili později?
• Může vydavatel uložit zprávu místně nebo do databáze a zkusit to znovu později?

Pokud vydavatel může zprávu pouze zahodit, pak zlepšení dostupnosti ve skutečnosti také zlepšuje zabezpečení dat.

Je tedy třeba hledat rovnováhu a řešení závisí na konkrétní situaci.

Problémy s ha-promote-on-failure=when-synced

Nápad ha-promote-on-failure= při synchronizaci spočívá v tom, že zabráníme přepnutí na nesynchronizované zrcadlo, a tím zabráníme ztrátě dat. Fronta zůstane nečitelná nebo zapisovatelná. Místo toho se snažíme obnovit havarovaný broker s nedotčenými daty, aby mohl znovu fungovat jako hlavní server bez ztráty dat.

Ale (a to je velké ale), pokud broker ztratil svá data, pak máme velký problém: fronta je ztracena! Všechna data jsou pryč! I když máte zrcadla, která většinou dohánějí hlavní frontu, tato zrcadla jsou také vyřazena.

Chcete-li znovu přidat uzel se stejným názvem, řekneme clusteru, aby zapomněl ztracený uzel (pomocí příkazu rabbitmqctl forget_cluster_node) a založte nového brokera se stejným názvem hostitele. Zatímco klastr si pamatuje ztracený uzel, pamatuje si starou frontu a nesynchronizovaná zrcadla. Když je klastru řečeno, aby zapomněl na osiřelý uzel, zapomene se i tato fronta. Nyní to musíme znovu deklarovat. Ztratili jsme všechna data, i když jsme měli zrcadla s částečnou sadou dat. Bylo by lepší přejít na nesynchronizované zrcadlo!

Proto ruční synchronizace (a selhání synchronizace) v kombinaci s ha-promote-on-failure=when-synced, podle mě dost riskantní. Dokumenty říkají, že tato možnost existuje pro zabezpečení dat, ale je to dvousečná zbraň.

Master rebalancování

Jak jsme slíbili, vracíme se k problému akumulace všech masterů na jednom nebo několika uzlech. To se může dokonce stát v důsledku postupné aktualizace clusteru. V tříuzlovém clusteru se všechny hlavní fronty shromažďují na jednom nebo dvou uzlech.

Rebalancování masterů může být problematické ze dvou důvodů:

• Neexistují žádné dobré nástroje pro provádění rebalancování
• Synchronizace fronty

Pro rebalancování existuje třetí strana Plugin, který není oficiálně podporován. Pokud jde o pluginy třetích stran v příručce RabbitMQ řekl: „Plugin poskytuje některé další konfigurační a reportovací nástroje, ale není podporován ani ověřen týmem RabbitMQ. Použití na vlastní nebezpečí."

Existuje další trik, jak přesunout hlavní frontu prostřednictvím zásad HA. Manuál zmiňuje skript pro tohle. Funguje to takto:

• Odebere všechna zrcadla pomocí dočasné zásady, která má vyšší prioritu než stávající zásada HA.
• Změní dočasnou zásadu HA tak, aby používala režim uzlu, přičemž určí uzel, do kterého má být hlavní fronta přenesena.
• Synchronizuje frontu pro push migraci.
• Po dokončení migrace odstraní dočasné zásady. Počáteční zásada HA se projeví a vytvoří se požadovaný počet zrcadel.

Nevýhodou je, že tento přístup nemusí fungovat, pokud máte velké fronty nebo přísné požadavky na redundanci.

Nyní se podívejme, jak clustery RabbitMQ fungují se síťovými oddíly.

Ztráta konektivity

Uzly distribuovaného systému jsou propojeny síťovými spoji a síťové spoje mohou a budou odpojeny. Četnost výpadků závisí na místní infrastruktuře nebo spolehlivosti vybraného cloudu. Distribuované systémy si s nimi každopádně musí umět poradit. Opět máme na výběr mezi dostupností a konzistencí a opět dobrou zprávou je, že RabbitMQ poskytuje obě možnosti (jen ne současně).

S RabbitMQ máme dvě hlavní možnosti:

• Povolit logické dělení (split-brain). Tím je zajištěna dostupnost, ale může dojít ke ztrátě dat.
• Zakázat logické oddělení. Může vést ke krátkodobé ztrátě dostupnosti v závislosti na tom, jak se klienti připojují ke clusteru. Může také vést k úplné nedostupnosti v clusteru se dvěma uzly.

Ale co je to logické oddělení? To je, když se cluster rozdělí na dva kvůli ztrátě síťových připojení. Na každé straně jsou zrcadla povýšena na master, takže v každém tahu je nakonec několik mistrů.

Rýže. 17. Hlavní fronta a dvě zrcadla, každé na samostatném uzlu. Potom dojde k selhání sítě a jedno zrcadlo se odpojí. Oddělený uzel vidí, že ostatní dva odpadly, a povýší svá zrcadla na master. Nyní máme dvě hlavní fronty, zapisovatelné a čitelné.

Pokud vydavatelé pošlou data oběma masterům, skončíme se dvěma odlišnými kopiemi fronty.

Různé režimy RabbitMQ poskytují buď dostupnost, nebo konzistenci.

Ignorovat režim (výchozí)

Tento režim zajišťuje dostupnost. Po ztrátě konektivity dochází k logickému oddělení. Po obnovení připojení se musí správce rozhodnout, kterému oddílu udělit prioritu. Prohrávající strana bude restartována a všechna nashromážděná data na této straně budou ztracena.

Rýže. 18. Tři vydavatelé jsou spojeni se třemi makléři. Interně cluster směruje všechny požadavky do hlavní fronty na Broker 2.

Nyní ztrácíme Brokera 3. Vidí, že ostatní makléři odpadli a povýší své zrcadlo na mistra. Tak dochází k logickému oddělení.

Rýže. 19. Logické dělení (split-brain). Záznamy jdou do dvou hlavních front a dvě kopie se rozcházejí.

Konektivita je obnovena, ale logické oddělení zůstává. Administrátor musí ručně vybrat stranu, která prohrála. V níže uvedeném případě administrátor restartuje Broker 3. Všechny zprávy, které nestihl odeslat, jsou ztraceny.

Rýže. 20. Správce zakáže Broker 3.

Rýže. 21. Správce spustí Broker 3 a ten se připojí ke clusteru, přičemž ztratí všechny zprávy, které tam zůstaly.

Při ztrátě připojení a po jeho obnovení byly cluster a tato fronta k dispozici pro čtení a zápis.

Režim autoheal

Funguje podobně jako režim Ignorovat, s tím rozdílem, že po rozdělení a obnovení konektivity si cluster sám automaticky vybere stranu prohrávající. Prohrávající strana se vrátí do clusteru prázdná a fronta ztratí všechny zprávy, které byly odeslány pouze této straně.

Pozastavit režim menšin

Pokud nechceme povolit logické dělení, pak naší jedinou možností je zahodit čtení a zápisy na menší stranu po rozdělení clusteru. Když broker vidí, že je na menší straně, pozastaví práci, tedy uzavře všechna stávající spojení a odmítne jakákoli nová. Jednou za sekundu kontroluje obnovení připojení. Jakmile je připojení obnoveno, obnoví provoz a připojí se ke clusteru.

Rýže. 22. Tři vydavatelé jsou spojeni se třemi makléři. Interně cluster směruje všechny požadavky do hlavní fronty na Broker 2.

Broker 1 a 2 se poté oddělí od Brokera 3. Místo toho, aby povýšil svůj mirror na master, Broker 3 se pozastaví a stane se nedostupným.

Rýže. 23. Broker 3 se pozastaví, odpojí všechny klienty a odmítne požadavky na připojení.

Jakmile je připojení obnoveno, vrátí se do clusteru.

Podívejme se na další příklad, kde je hlavní fronta na Broker 3.

Rýže. 24. Hlavní fronta na Broker 3.

Pak dojde ke stejné ztrátě konektivity. Broker 3 se pozastaví, protože je na menší straně. Na druhé straně uzly vidí, že Broker 3 spadl, takže starší zrcadlo z Brokerů 1 a 2 je povýšeno na master.

Rýže. 25. Přechod na Broker 2, pokud je Broker 3 nedostupný.

Po obnovení připojení se Broker 3 připojí ke clusteru.

Rýže. 26. Cluster se vrátil do normálního provozu.

Zde je důležité pochopit, že získáme konzistenci, ale můžeme také získat dostupnost, jestliže Klienty úspěšně převedeme do většiny úseku. Pro většinu situací bych osobně zvolil režim Pause Minority, ale opravdu záleží na individuálním případě.

Pro zajištění dostupnosti je důležité zajistit, aby se klienti úspěšně připojili k hostiteli. Podívejme se na naše možnosti.

Zajištění zákaznické konektivity

Máme několik možností, jak nasměrovat klienty do hlavní části clusteru nebo do pracovních uzlů (po výpadku jednoho uzlu) po ztrátě konektivity. Nejprve si připomeňme, že konkrétní fronta je hostována na konkrétním uzlu, ale směrování a zásady jsou replikovány napříč všemi uzly. Klienti se mohou připojit k libovolnému uzlu a interní směrování je nasměruje tam, kam potřebují. Ale když je uzel pozastaven, odmítá připojení, takže se klienti musí připojit k jinému uzlu. Pokud uzel odpadne, může dělat jen málo.

Naše možnosti:

• Ke clusteru se přistupuje pomocí nástroje pro vyrovnávání zatížení, který jednoduše prochází uzly a klienti se znovu pokusí připojit, dokud nebudou úspěšné. Pokud je uzel vypnutý nebo pozastavený, pokusy o připojení k tomuto uzlu selžou, ale následné pokusy přejdou na jiné servery (v režimu round-robin). To je vhodné pro krátkodobou ztrátu připojení nebo výpadek serveru, který bude rychle obnoven.
• Získejte přístup ke clusteru pomocí nástroje pro vyrovnávání zatížení a odeberte pozastavené/selhal uzly ze seznamu, jakmile jsou zjištěny. Pokud to uděláme rychle a budou-li klienti schopni znovu zkusit připojení, dosáhneme stálé dostupnosti.
• Dejte každému klientovi seznam všech uzlů a klient při připojování náhodně vybere jeden z nich. Pokud při pokusu o připojení obdrží chybu, přesune se na další uzel v seznamu, dokud se nepřipojí.
• Odstraňte provoz z neúspěšného/pozastaveného uzlu pomocí DNS. To se provádí pomocí malého TTL.

Závěry

Klastrování RabbitMQ má své výhody a nevýhody. Nejzávažnější nevýhody jsou, že:

• když se připojují ke clusteru, uzly zahazují svá data;
• blokování synchronizace způsobí, že se fronta stane nedostupnou.

Všechna obtížná rozhodnutí pramení z těchto dvou architektonických prvků. Pokud by RabbitMQ mohl uložit data při opětovném připojení clusteru, synchronizace by byla rychlejší. Pokud by byl schopen neblokující synchronizace, lépe by podporoval velké fronty. Oprava těchto dvou problémů by výrazně zlepšila výkon RabbitMQ jako technologie odolné proti chybám a vysoce dostupné technologie zasílání zpráv. Váhal bych s doporučením RabbitMQ s clusteringem v následujících situacích:

• Nespolehlivá síť.
• Nespolehlivé úložiště.
• Velmi dlouhé fronty.

Pokud jde o nastavení vysoké dostupnosti, zvažte následující:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (nebo autoheal)
• trvalé zprávy
• zajistit, aby se klienti připojili k aktivnímu uzlu, když některý uzel selže

Pro konzistenci (zabezpečení dat) zvažte následující nastavení:

• Potvrzení vydavatele a ruční potvrzení na straně spotřebitele
• ha-promote-on-failure=when-synced, pokud to vydavatelé mohou zkusit znovu později a pokud máte velmi spolehlivé úložiště! Jinak řečeno =always.
• ha-sync-mode=automatic (ale u velkých neaktivních front může být vyžadován manuální režim; zvažte také, zda nedostupnost nezpůsobí ztrátu zpráv)
• Pozastavit menšinový režim
• trvalé zprávy

Ještě jsme nepokryli všechny otázky odolnosti proti chybám a vysoké dostupnosti; například jak bezpečně provádět administrativní procedury (jako jsou průběžné aktualizace). Musíme také mluvit o federaci a pluginu Shovel.

Pokud jsem ještě něco vynechal, dejte mi prosím vědět.

Viz také můj zveřejnit, kde provádím zmatek na clusteru RabbitMQ pomocí Docker a Blockade k testování některých scénářů ztráty zpráv popsaných v tomto článku.

Předchozí články ze série:
Č.1 - habr.com/ru/company/itsumma/blog/416629
Č.2 - habr.com/ru/company/itsumma/blog/418389
Č.3 - habr.com/ru/company/itsumma/blog/437446

Zdroj: www.habr.com