V tomto článku vám poviem, ako sme pristupovali k problematike odolnosti voči chybám PostgreSQL, prečo sa stala pre nás dôležitou a čo sa nakoniec stalo.
Máme vysoko nabitú službu: 2,5 milióna používateľov na celom svete, viac ako 50 100 aktívnych používateľov každý deň. Servery sa nachádzajú v Amazone v jednom regióne Írska: 50+ rôznych serverov je neustále v prevádzke, takmer XNUMX z nich má databázy.
Celý backend je veľká monolitická stavová Java aplikácia, ktorá udržiava trvalé pripojenie websocket s klientom. Keď viacerí používatelia pracujú súčasne na tej istej doske, všetci vidia zmeny v reálnom čase, pretože každú zmenu zaznamenávame do databázy. Do našich databáz máme približne 10 80 požiadaviek za sekundu. Pri špičkovom zaťažení v Redis zapisujeme 100-XNUMX XNUMX požiadaviek za sekundu.
Prečo sme prešli z Redis na PostgreSQL
Naša služba spočiatku spolupracovala s Redis, úložiskom kľúč-hodnota, ktoré ukladá všetky údaje do pamäte RAM servera.
Výhody Redis:
- Vysoká rýchlosť odozvy, pretože všetko je uložené v pamäti;
- Pohodlné zálohovanie a replikácia.
Nevýhody Redis pre nás:
- Neexistujú žiadne skutočné transakcie. Snažili sme sa ich napodobniť na našej aplikačnej úrovni. Bohužiaľ to nefungovalo vždy dobre a vyžadovalo si to písanie veľmi zložitého kódu.
- Množstvo dát je obmedzené veľkosťou pamäte. S narastajúcim množstvom dát bude rásť pamäť a nakoniec narazíme na charakteristiky vybranej inštancie, čo v AWS vyžaduje zastavenie našej služby, aby sa zmenil typ inštancie.
- Je potrebné neustále udržiavať nízku úroveň latencie, pretože Máme veľmi veľké množstvo žiadostí. Optimálna úroveň latencie je pre nás 17-20 ms. Na úrovni 30-40 ms dostávame dlhé odpovede na požiadavky našich aplikácií a degradáciu služieb. Bohužiaľ, toto sa nám stalo v septembri 2018, keď jedna z inštancií s Redis z nejakého dôvodu dostala latenciu, ktorá bola 2-krát vyššia ako zvyčajne. Aby sme problém vyriešili, zastavili sme službu uprostred pracovného dňa z dôvodu neplánovanej údržby a vymenili sme problematickú inštanciu Redis.
- Je ľahké získať nekonzistentné údaje aj s malými chybami v kóde a potom stráviť veľa času písaním kódu na opravu týchto údajov.
Zohľadnili sme nevýhody a uvedomili sme si, že musíme prejsť na niečo pohodlnejšie, s normálnymi transakciami a menšou závislosťou od latencie. Urobili sme náš prieskum, analyzovali sme veľa možností a vybrali sme PostgreSQL.
Už 1,5 roka prechádzame na novú databázu a preniesli sme len malú časť dát, takže teraz pracujeme súčasne s Redis a PostgreSQL. Viac informácií o fázach presúvania a prepínania údajov medzi databázami je napísaných v .
Keď sme sa prvýkrát začali pohybovať, naša aplikácia pracovala priamo s databázou a pristupovala k hlavnému serveru Redis a PostgreSQL. Klaster PostgreSQL pozostával z hlavného servera a repliky s asynchrónnou replikáciou. Takto vyzeral pracovný postup databázy:
Implementácia PgBouncer
Počas nášho sťahovania sa produkt tiež vyvíjal: zvýšil sa počet používateľov a počet serverov, ktoré pracovali s PostgreSQL, a začali nám dochádzať pripojenia. PostgreSQL vytvára samostatný proces pre každé pripojenie a spotrebúva zdroje. Do určitého bodu môžete zvýšiť počet pripojení, inak existuje šanca, že databáza nebude fungovať optimálne. Ideálnou možnosťou v takejto situácii by bolo vybrať správcu pripojenia, ktorý bude stáť pred databázou.
Pre správcu pripojenia sme mali dve možnosti: Pgpool a PgBouncer. Prvý z nich ale nepodporuje transakčný režim práce s databázou, preto sme zvolili PgBouncer.
Nastavili sme nasledujúcu schému práce: naša aplikácia pristupuje k jednému PgBounceru, za ktorým sú Master PostgreSQL a za každým masterom je jedna replika s asynchrónnou replikáciou.
Zároveň sme v PostgreSQL nemohli ukladať celé množstvo dát a rýchlosť práce s databázou bola pre nás dôležitá, preto sme začali PostgreSQL shardovať na aplikačnej úrovni. Vyššie popísaná schéma je na to pomerne pohodlná: pri pridávaní nového shardu PostgreSQL stačí aktualizovať konfiguráciu PgBouncer a aplikácia môže okamžite pracovať s novým shardom.
Odolnosť voči chybám PgBouncer
Táto schéma fungovala, kým nezomrela jediná inštancia PgBouncer. Nachádzame sa v AWS, kde sa všetky inštancie spúšťajú na hardvéri, ktorý pravidelne odumiera. V takýchto prípadoch sa inštancia jednoducho presunie na nový hardvér a znova funguje. Stalo sa to s PgBouncer, ale stal sa nedostupným. Výsledkom tohto zlyhania bolo, že naša služba bola nedostupná 25 minút. Pre takéto situácie AWS odporúča použiť redundanciu na strane používateľa, ktorú sme vtedy neimplementovali.
Potom sme sa vážne zamysleli nad odolnosťou voči chybám klastrov PgBouncer a PostgreSQL, pretože podobná situácia sa môže zopakovať s ktoroukoľvek inštanciou v našom účte AWS.
Schému odolnosti proti chybám PgBouncer sme vytvorili nasledovne: všetky aplikačné servery pristupujú k Network Load Balancer, za ktorým sú dva PgBouncery. Každý z PgBouncerov sa pozerá na rovnaký hlavný PostgreSQL každého fragmentu. Ak sa situácia s pádom inštancie AWS zopakuje, všetka prevádzka je presmerovaná cez iný PgBouncer. Toleranciu chýb Network Load Balancer poskytuje AWS.
Táto schéma vám umožňuje jednoducho pridávať nové servery PgBouncer.
Vytvorenie klastra zlyhania PostgreSQL
Pri riešení tohto problému sme zvažovali rôzne možnosti: samonapísané zlyhanie, repmgr, AWS RDS, Patroni.
Vlastnoručne písané skriptá
Môžu monitorovať prácu mastera a ak zlyhá, povýšiť repliku na master a aktualizovať konfiguráciu PgBouncer.
Výhodou tohto prístupu je maximálna jednoduchosť, pretože skripty si píšete sami a presne rozumiete, ako fungujú.
Nevýhody:
- Master možno nezomrel; namiesto toho mohlo dôjsť k zlyhaniu siete. Failover, ktorý si to neuvedomuje, povýši repliku na master a starý master bude pokračovať v práci. V dôsledku toho získame dva servery v hlavnej úlohe a nebudeme vedieť, ktorý z nich má najnovšie aktuálne údaje. Táto situácia sa tiež nazýva split-brain;
- Ostali sme bez odozvy. V našej konfigurácii je master a jedna replika, po prepnutí je replika povýšená na master a my už nemáme repliky, takže musíme manuálne pridať novú repliku;
- Potrebujeme ďalšie monitorovanie prevádzky pri zlyhaní a máme 12 fragmentov PostgreSQL, čo znamená, že musíme monitorovať 12 klastrov. Pri zvyšovaní počtu zlomkov musíte tiež pamätať na aktualizáciu núdzového prepnutia.
Vlastné zlyhanie vyzerá veľmi komplikovane a vyžaduje si netriviálnu podporu. S jedným klastrom PostgreSQL to bude najjednoduchšia možnosť, ale neškáluje sa, takže pre nás nie je vhodná.
Repmgr
Replication Manager pre klastre PostgreSQL, ktorý dokáže riadiť prevádzku klastra PostgreSQL. Zároveň nemá automatické prepnutie z krabice, takže na prácu budete musieť napísať svoj vlastný „balíček“ na hotové riešenie. Všetko sa teda môže ukázať ešte komplikovanejšie ako pri skriptoch napísaných vlastnými rukami, a preto sme Repmgr ani neskúšali.
AWS RDS
Podporuje všetko, čo potrebujeme, dokáže zálohovať a podporuje skupinu pripojení. Má automatické prepínanie: keď master zomrie, replika sa stane novým masterom a AWS zmení DNS záznam na nový master, pričom repliky môžu byť umiestnené v rôznych AZ.
Medzi nevýhody patrí nedostatok jemných nastavení. Ako príklad jemného doladenia: naše inštancie majú obmedzenia pre pripojenia tcp, ktoré, žiaľ, nie je možné vykonať v RDS:
net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3
AWS RDS je navyše takmer dvakrát drahšie ako bežná cena inštancie, čo bol hlavný dôvod opustenia tohto riešenia.
Patroni
Toto je pythonová šablóna na správu PostgreSQL s dobrou dokumentáciou, automatickým núdzovým prepnutím a zdrojovým kódom na github.
Výhody spoločnosti Patroni:
- Každý konfiguračný parameter je popísaný, je jasné, ako funguje;
- Automatické prepnutie pri zlyhaní funguje hneď po vybalení;
- Napísané v pythone, a keďže my sami veľa píšeme v pythone, bude pre nás jednoduchšie riešiť problémy a možno aj pomôcť rozvoju projektu;
- Plne ovláda PostgreSQL, umožňuje zmeniť konfiguráciu na všetkých uzloch klastra naraz a ak si aplikácia novej konfigurácie vyžaduje reštart klastra, dá sa to urobiť znova pomocou Patroni.
Nevýhody:
- Z dokumentácie nie je jasné, ako správne pracovať s PgBouncer. Aj keď je ťažké nazvať to mínusom, pretože úlohou Patroni je spravovať PostgreSQL a ako budú pripojenia k Patroni fungovať, je už náš problém;
- Existuje niekoľko príkladov implementácie Patroni vo veľkých mierkach, zatiaľ čo existuje veľa príkladov implementácie od začiatku.
V dôsledku toho sme si vybrali Patroni na vytvorenie klastra prepnutia pri zlyhaní.
Proces implementácie Patroni
Pred Patroni sme mali 12 fragmentov PostgreSQL v jednej hlavnej a jednej replikovanej konfigurácii s asynchrónnou replikáciou. Aplikačné servery pristupovali k databázam cez Network Load Balancer, za ktorým boli dve inštancie s PgBouncer a za nimi boli všetky PostgreSQL servery.
Na implementáciu Patroni sme potrebovali vybrať distribuované úložisko konfigurácie klastra. Patroni pracuje s distribuovanými konfiguračnými úložnými systémami, ako sú etcd, Zookeeper, Consul. Vo výrobe máme plnohodnotný klaster Consul, ktorý funguje v spojení s Vaultom a už ho nepoužívame. Skvelý dôvod, prečo začať používať Consul na určený účel.
Ako Patroni spolupracuje s konzulom
Máme klaster Consul, ktorý pozostáva z troch uzlov, a klaster Patroni, ktorý pozostáva z vodcu a repliky (v Patroni sa master nazýva vodca klastra a otroci sa nazývajú repliky). Každá inštancia klastra Patroni neustále posiela informácie o stave klastra konzulovi. Preto od Consul môžete vždy zistiť aktuálnu konfiguráciu klastra Patroni a kto je momentálne vedúci.
Ak chcete pripojiť Patroni ku Consul, stačí si preštudovať oficiálnu dokumentáciu, ktorá hovorí, že musíte zadať hostiteľa vo formáte http alebo https, v závislosti od toho, ako pracujeme s Consul, a schému pripojenia, voliteľne:
host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to httpVyzerá to jednoducho, no tu začínajú úskalia. S Consul pracujeme cez zabezpečené pripojenie cez https a naša konfigurácia pripojenia bude vyzerať takto:
consul:
host: https://server.production.consul:8080
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}Ale takto to nefunguje. Pri spustení sa Patroni nemôže pripojiť k službe Consul, pretože sa stále pokúša prejsť cez http.
Zdrojový kód Patroni pomohol vyriešiť problém. Je dobré, že je to napísané v pythone. Ukazuje sa, že parameter hostiteľa nie je žiadnym spôsobom analyzovaný a protokol musí byť špecifikovaný v schéme. Takto pre nás vyzerá pracovný konfiguračný blok pre prácu s Consulom:
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}Konzul-šablóna
Zvolili sme teda úložisko konfigurácie. Teraz musíme pochopiť, ako PgBouncer zmení svoju konfiguráciu, keď sa zmení vedúci v klastri Patroni. Na túto otázku nie je v dokumentácii žiadna odpoveď, pretože... Práca s PgBouncer tam v princípe nie je popísaná.
Pri hľadaní riešenia sme našli článok (bohužiaľ, nepamätám si názov), kde bolo napísané, že Consul-template bol veľmi nápomocný pri kombinovaní PgBouncer a Patroni. To nás podnietilo študovať prácu Consul-template.
Ukázalo sa, že Consul-template neustále monitoruje konfiguráciu klastra PostgreSQL v Consul. Keď sa vedúci zmení, aktualizuje konfiguráciu PgBouncer a odošle príkaz na opätovné načítanie.
Veľkou výhodou šablóny je, že je uložená ako kód, takže pri pridávaní nového shardu stačí urobiť nový commit a aktualizovať šablónu automaticky, podporujúc princíp Infrastructure as code.
Nová architektúra s Patroni
V dôsledku toho sme dostali nasledujúcu schému práce:
Všetky aplikačné servery pristupujú k balanceru → za ním sú dve inštancie PgBouncer → na každej inštancii je spustená šablóna Consul, ktorá monitoruje stav každého klastra Patroni a monitoruje relevantnosť konfigurácie PgBouncer, ktorá smeruje požiadavky k aktuálnemu vedúcemu každého klastra.
Manuálne testovanie
Pred uvedením do výroby sme túto schému spustili na malom testovacom prostredí a skontrolovali fungovanie automatického prepínania. Otvorili tabuľu, posunuli nálepku a v tom momente „zabili“ vodcu klastra. V AWS stačí inštanciu vypnúť cez konzolu.
Nálepka sa vrátila do 10-20 sekúnd a potom sa začala opäť normálne pohybovať. To znamená, že klaster Patroni fungoval správne: zmenil vedúceho, odoslal informácie konzulovi a Consul-template tieto informácie okamžite zachytil, nahradil konfiguráciu PgBouncer a poslal príkaz na opätovné načítanie.
Ako prežiť pri vysokej záťaži a udržať minimálne prestoje?
Všetko funguje perfektne! Vynárajú sa však nové otázky: Ako bude fungovať pri vysokej záťaži? Ako rýchlo a bezpečne rozvinúť všetko vo výrobe?
Testovacie prostredie, v ktorom vykonávame záťažové testovanie, nám pomáha odpovedať na prvú otázku. Je úplne identický s produkciou v architektúre a vygeneroval testovacie dáta, ktoré sa objemom približne rovnajú produkcii. Rozhodneme sa, že počas testu jednoducho „zabijeme“ jedného z majstrov PostgreSQL a uvidíme, čo sa stane. Ešte predtým je však dôležité skontrolovať automatický rollout, pretože na tomto prostredí máme niekoľko shardov PostgreSQL, takže pred výrobou dostaneme výborné testovanie konfiguračných skriptov.
Obe úlohy vyzerajú ambiciózne, ale máme PostgreSQL 9.6. Možno by sme mohli okamžite aktualizovať na 11.2?
Rozhodli sme sa to urobiť v 2 fázach: najprv aktualizujte verziu na 11.2 a potom spustite Patroni.
Aktualizácia PostgreSQL
Ak chcete rýchlo aktualizovať verziu PostgreSQL, musíte použiť túto možnosť -k, v ktorom sa na disku vytvorí pevný odkaz a nie je potrebné kopírovať vaše dáta. Pri databázach s veľkosťou 300 – 400 GB trvá aktualizácia 1 sekundu.
Máme veľa úlomkov, takže aktualizácia musí prebiehať automaticky. Na tento účel sme napísali príručku Ansible, ktorá za nás vykoná celý proces aktualizácie:
/usr/lib/postgresql/11/bin/pg_upgrade
<b>--link </b>
--old-datadir='' --new-datadir=''
--old-bindir='' --new-bindir=''
--old-options=' -c config_file='
--new-options=' -c config_file='Tu je dôležité poznamenať, že pred spustením aktualizácie ju musíte vykonať s parametrom --skontrolovaťaby ste si boli istí, že upgrade je možný. Náš skript tiež nahrádza konfigurácie počas inovácie. Náš skript bol dokončený za 30 sekúnd, čo je vynikajúci výsledok.
Spustenie Patroni
Ak chcete vyriešiť druhý problém, stačí sa pozrieť na konfiguráciu Patroni. Oficiálny repozitár má príklad konfigurácie s initdb, ktorý je zodpovedný za inicializáciu novej databázy pri prvom spustení Patroni. Ale keďže už máme pripravenú databázu, jednoducho sme túto sekciu z konfigurácie odstránili.
Keď sme začali inštalovať Patroni na pripravený klaster PostgreSQL a spúšťať ho, narazili sme na nový problém: oba servery boli spustené ako líder. Patroni nevie nič o počiatočnom stave klastra a pokúša sa spustiť oba servery ako dva samostatné klastre s rovnakým názvom. Ak chcete vyriešiť tento problém, musíte vymazať dátový adresár na podriadenom zariadení:
rm -rf /var/lib/postgresql/Toto sa musí robiť iba na otrokovi!
Pri pripájaní čistej repliky Patroni vytvorí vedúceho zálohovania základne a obnoví ho do repliky a potom dohoní aktuálny stav pomocou protokolov múru.
Ďalším problémom, s ktorým sme sa stretli, je, že všetky klastre PostgreSQL sa štandardne nazývajú hlavné. Keď každý zhluk nevie nič o druhom, je to normálne. Ale keď chcete používať Patroni, všetky klastre musia mať jedinečný názov. Riešením je zmena názvu klastra v konfigurácii PostgreSQL.
Záťažový test
Spustili sme test, ktorý simuluje prácu používateľov na doskách. Keď záťaž dosiahla náš denný priemer, zopakovali sme presne ten istý test, jednu inštanciu sme vypli s vedúcim PostgreSQL. Automatické núdzové prepnutie fungovalo tak, ako sme očakávali: Patroni zmenil vedúceho, Consul-template aktualizoval konfiguráciu PgBouncer a poslal príkaz na opätovné načítanie. Podľa našich grafov v Grafane bolo jasné, že došlo k oneskoreniam 20-30 sekúnd a malému množstvu chýb zo serverov súvisiacich s pripojením k databáze. Toto je normálna situácia, takéto hodnoty sú prijateľné pre naše zlyhanie a sú určite lepšie ako prestoje služby.
Spustenie Patroni do výroby
V dôsledku toho sme prišli s nasledujúcim plánom:
- Nasaďte Consul-template na server PgBouncer a spustite;
- Aktualizácie PostgreSQL na verziu 11.2;
- Zmena názvu klastra;
- Spustenie klastra Patroni.
Naša schéma nám zároveň umožňuje urobiť prvý bod takmer kedykoľvek, každý PgBouncer môžeme jeden po druhom odstrániť z práce a vykonať na ňom nasadenie a spustenie konzultačnej šablóny. To sme urobili.
Na rýchle testovanie sme použili Ansible, keďže sme už testovali celú príručku v testovacom prostredí a čas vykonania celého skriptu bol od 1,5 do 2 minút pre každý fragment. Mohli by sme zaviesť všetko jeden po druhom pre každý fragment bez zastavenia našej služby, ale museli by sme vypnúť každý PostgreSQL na niekoľko minút. V tomto prípade by používatelia, ktorých údaje sú na tomto zlomku, nemohli v tejto chvíli plnohodnotne pracovať, a to je pre nás neprijateľné.
Východiskom z tejto situácie bola plánovaná údržba, ktorú robíme každé 3 mesiace. Toto je okno pre plánovanú prácu, kedy úplne vypneme našu službu a aktualizujeme inštancie databázy. Do ďalšieho okna zostával týždeň a my sme sa rozhodli len počkať a pripraviť sa ďalej. Počas čakania sme dodatočne zabezpečili naše stávky: pre každý fragment PostgreSQL sme vyzbierali náhradnú repliku pre prípad zlyhania, aby sme uložili najnovšie údaje, a pridali novú inštanciu pre každý fragment, ktorý by sa mal stať novou replikou v Patroni cluster, aby nevydal príkaz na vymazanie údajov . To všetko pomohlo minimalizovať riziko chyby.
Reštartovali sme našu službu, všetko fungovalo ako malo, používatelia pokračovali v práci, ale na grafoch sme zaznamenali abnormálne vysoké zaťaženie serverov Consul.
Prečo sme to nevideli v testovacom prostredí? Tento problém veľmi dobre ilustruje, že je potrebné riadiť sa princípom Infrastructure as code a zlepšiť celú infraštruktúru, od testovacích prostredí až po produkciu. V opačnom prípade je veľmi ľahké dostať sa k problému, ktorý máme. Čo sa stalo? Consul sa prvýkrát objavil v produkčnom a potom v testovacích prostrediach; výsledkom bolo, že v testovacích prostrediach bola verzia Consul vyššia ako v produkčnom prostredí. Práve v jednom z vydaní bol vyriešený únik CPU pri práci s consul-template. Takže sme jednoducho aktualizovali Consul, čím sme problém vyriešili.
Reštartujte klaster Patroni
Dostali sme však nový problém, o ktorom sme ani len netušili. Pri aktualizácii Consul jednoducho odstránime uzol Consul z klastra pomocou príkazu consul leave → Patroni sa pripojí k inému serveru Consul → všetko funguje. Keď sme sa však dostali k poslednej inštancii klastra Consul a odoslali sme mu príkaz opustiť konzul, všetky klastre Patroni sa jednoducho reštartovali a v protokoloch sme videli nasledujúcu chybu:
ERROR: get_cluster
Traceback (most recent call last):
...
RetryFailedError: 'Exceeded retry deadline'
ERROR: Error communicating with DCS
<b>LOG: database system is shut down</b>Klaster Patroni nedokázal získať informácie o svojom klastri a reštartoval sa.
Aby sme našli riešenie, kontaktovali sme autorov Patroni prostredníctvom problému na githube. Navrhli vylepšenia našich konfiguračných súborov:
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8Problém sa nám podarilo replikovať v testovacom prostredí a otestovať tieto nastavenia tam, no bohužiaľ nefungovali.
Problém stále zostáva nevyriešený. Plánujeme vyskúšať nasledujúce riešenia:
- Použite konzultačného agenta na každú inštanciu klastra Patroni;
- Opravte problém v kóde.
Chápeme, kde sa stala chyba: problém je pravdepodobne v použití predvoleného časového limitu, ktorý nie je prepísaný cez konfiguračný súbor. Po odstránení posledného servera Consul z klastra celý klaster Consul zamrzne, čo trvá dlhšie ako sekundu; Patroni preto nemôže získať stav klastra a úplne reštartuje celý klaster.
Našťastie sme už na žiadne chyby nenarazili.
Výsledky používania Patroni
Po úspešnom spustení Patroni sme pridali ďalšiu repliku do každého klastra. Teraz má každý klaster zdanie kvóra: jeden vodca a dve repliky na ochranu pred rozštiepeným mozgom pri prepínaní.
Patroni pracuje vo výrobe už viac ako tri mesiace. Počas tejto doby nám už stihol pomôcť. Nedávno v AWS zomrel vedúci jedného z klastrov, automatické prepnutie zlyhalo a používatelia pokračovali v práci. Patroni splnil svoju hlavnú úlohu.
Krátke zhrnutie používania Patroni:
- Jednoduchosť zmien konfigurácie. Stačí zmeniť konfiguráciu na jednej inštancii a bude platiť pre celý klaster. Ak je na použitie novej konfigurácie potrebný reštart, Patroni vás na to upozorní. Patroni dokáže reštartovať celý klaster jedným príkazom, čo je tiež veľmi pohodlné.
- Automatické prepnutie funguje a už nám pomohlo.
- Aktualizácia PostgreSQL bez výpadku aplikácie. Najprv musíte aktualizovať repliky na novú verziu, potom zmeniť vodcu v klastri Patroni a aktualizovať starého vodcu. V tomto prípade dôjde k nevyhnutnému testovaniu automatického prepnutia pri zlyhaní.
Zdroj: hab.com