Tõrketaluv PostgreSQL klaster + Patroni. Rakendamise kogemus

Selles artiklis räägin, kuidas me lähenesime PostgreSQL-i tõrke taastamise küsimusele, miks see meile oluline oli ja mis lõpuks välja tuli.

Meil on suure koormusega teenus: 2,5 miljonit kasutajat üle kogu maailma, 50K+ aktiivset kasutajat igapäevaselt. Serverid asuvad Amazones ühes Iiri regioonis: töös on pidevalt 100+ erinevat serverit, neist peaaegu 50 on andmebaasidega.

Kogu backend on suur monoliitne stateful-rakendus Java-s, mis hoiab pidevat websocketi ühendust kliendiga. Kui mitu kasutajat töötab samal tahvelarvutil, näevad nad kõiki muudatusi reaalajas, kuna iga muudatus salvestatakse andmebaasi. Meil on umbes 10K päringut sekundis meie andmebaasidele. Tipukoormuse ajal kirjutame Redis-i 80-100K päringut sekundis.

Miks me läksime Redisilt PostgreSQL-ile üle

Alguses töötas meie teenus Redisiga, võtme-väärtus salvestussüsteemiga, mis hoiab kõiki andmeid mälus serverilt.

Redis'i plussid:

1. Kõrge vastamiskiirus, kuna kõik on mälus;
2. Mugav varukoopiate ja replikatsioonide tegemine.

Redis'i miinused meie jaoks:

1. Tegelikke tehinguid ei ole. Proovisime neid simuleerida meie rakenduse tasemel. Kahjuks ei töötanud see alati hästi ja nõudis väga keerulise koodi kirjutamist.
2. Andmete maht on piiratud mälumahu järgi. Kui andmete hulk suureneb, kasvab mälu ja lõpuks jõuame valitud instantsi omaduste piiridesse, mis AWS-is nõuab meie teenuse peatamist instantsi tüübi muutmiseks.
3. Peame pidevalt hoidma madalat latentsus taset, kuna meil on väga palju päringuid. Meie jaoks optimaalne viivituse tase on 17-20 ms. 30-40 ms tasemel saame pika vastuse päringutele meie rakenduse eest ja teenuse halvenemise. Kahjuks juhtus see meil septembris 2018, kui üks Redis-i instants sai mingil põhjusel viivituse, mis oli kaks korda suurem kui tavaliselt. Probleemi lahendamiseks peatasime teenuse tööpäeva keskel ettenägematuks hoolduseks ja vahetasime probleemse Redis-i instantsi.
4. Andmete konsistentsuse kadumine on lihtne isegi väikeste vigade korral koodis ja seejärel võib kuluda palju aega nende andmete parandamiseks vajaliku koodi kirjutamiseks.

Me võtsime arvesse puudusi ja mõistsime, et peame liikuma millegi mugavama suunas, normaalsemate tehingute ja väiksema sõltuvusega latentsusest. Tegime uuringu, analüüsisime mitmeid valikuid ja valisime PostgreSQL.

Uuele andmebaasile oleme üle kolinud juba 1,5 aastat ja edastanud vaid väikese osa andmetest, seega töötame praegu samal ajal Redis'i ja PostgreSQL'iga. Rohkem etappidest ja andmete üleviimisest andmebaaside vahel on kirjutatud minu kolleegi artiklis.

Kui me alles alustasime üleminekut, töötas meie rakendus otse andmebaasiga ja pöördus Redis'i ja PostgreSQL'i poole. PostgreSQL klaster koosnes peakontorist ja asünkroneeritud replikast. Nii nägi välja andmebaaside töö skeem:

PgBouncer'i rakendamine

Kuna me ülemineku käigus arendasime ka toodet: kasutajate arv ja PostgreSQL'iga töötavate serverite arv suurenes, ja meil hakkas puuduma ühendusi. PostgreSQL loob iga ühenduse jaoks eraldi protsessi ja tarbib ressursse. Ühenduste arvu võib suurendada teatud piirini, vastasel juhul on oht saada alatehnilise töö andmebaas. Sellises olukorras oleks ideaalne valida ühendusehaldur, mis paigaldataks andmebaasi ette.

Meil oli kaks valikut ühendusehalduriks: Pgpool ja PgBouncer. Kuid esimene ei toeta andmebaasi tehingurežiimi, seetõttu valisime PgBouncer'i.

Seadsime üles järgmise töö skeemi: meie rakendus pöördub ühe PgBouncer'i poole, mille taga on PostgreSQL'i peamised serverid, ja iga peamise konto taga on üks asünkroneeritud replik.

Samal ajal ei saanud me salvestada kogu andmevoogu PostgreSQL'i ja meile oli oluline andmebaasi töö kiirus, seega hakkasime PostgreSQL'i andmebaasi sharding'iga rakenduse tasemel. Ülaltoodud skeem on selle jaoks suhteliselt mugav: uue shard'i lisamisel on PostgreSQL'i konfiguratsiooni lihtsalt uuendada ja rakendus võib kohe uue shard'iga töötada.

PgBouncer'i talitlushäiretunne

See skeem töötas seni, kuni ainus PgBouncer'i instants hetkel ei kadunud. Oleme AWS-is, kus kõik instantsid töötavad riistvaral, mis aeg-ajalt kukub. Sellistel juhtudel liigub instants lihtsalt uuele riistvarale ja töötab jälle. Nii juhtus ka PgBouncer'i puhul, kuid see muutus kättesaamatuks. Selle purunemise tulemuseks oli meie teenuse tõrge 25 minutiks. AWS soovitab selliste olukordade jaoks kasutada kasutaja poolel üleliiksust, mida meie hetkel ei olnud rakendanud.

Pärast seda hakkasime tõsiselt mõtlema PgBouncer'i ja PostgreSQL'i klastrite töökindlusele, sest sarnane olukord võis korduda mis tahes meie AWS kontol asuvas instantsis.

PgBouncer'i töökindluse skeemi ehitasime järgmiselt: kõik rakendusserverid pöörduvad Network Load Balancer'i poole, mille taga on kaks PgBouncer'it. Iga PgBouncer vaatab sama master PostgreSQL'i igas shardis. Kui situatsioon AWS-i instantsi kukkumisega kordub, suunatakse kogu liiklus teise PgBouncer'i kaudu. Network Load Balancer'i töökindlust tagab AWS.

See skeem võimaldab probleemideta lisada uusi PgBouncer'e.

Töökindla PostgreSQL'i klusteri loomine

Selle probleemi lahendamisel kaalume erinevaid valikuid: isetehtud failover, repmgr, AWS RDS, Patroni.

Isetehitatud skriptid

Saavad jälgida master'i tööd ja, kui see kukub, tõsta replikatsioon master'iks ja uuendada PgBouncer'i konfiguratsiooni.

Selle lähenemise plussid on maksimaalne lihtsus, sest kirjutate ise skripte ja mõistate täpselt, kuidas need töötavad.

Miinused:

• Master ei pruugi olla surnud, võib olla ka võrgu tõrge. Failover, teadmata sellest, tõukab replikatsiooni master'iks, samas kui vana master jätkab töötamist. Tulemuseks on, et meil on kaks serverit master'i rollis ja me ei tea, millel on viimased aktiivsed andmed. Sellist olukorda nimetatakse ka split-brain'iks.
• Jäime ilma replikast. Meie konfiguratsioonis on master ja üks replikatsioon, pärast üleviimist tõukatakse replikatsioon master'iks ja meil ei ole enam replikasid, seega peame käsitsi lisama uue replikatsiooni.
• On vajalik täiendav failover'i töötamise jälgimine, samas on meil 12 PostgreSQL'i shard'i, seega peame jälgima 12 klastrit. Kui shard'ide arv suureneb, ei tohi unustada failover'it uuendada.

Kohandatud failover tundub väga keeruline ja nõuab mitte triviaalset tuge. Ühe PostgreSQL-klastriga on see kõige lihtsam variant, kuid see ei ole skaleeritav, seega meie jaoks ei sobi.

Repmgr

PostgreSQL klastrite replikatsiooni haldaja, mis oskab hallata PostgreSQL klastri tööd. Samas puudub selles automaatne failover „karbist välja”, seega on vajalik kirjutada selle valmis lahenduse peale oma „ümberpakend”. Nii et kõik võib osutuda isegi keerulisemaks kui kohandatud skriptide puhul, seega ei proovinud me isegi Repmgr.

AWS RDS

Toetab kõike vajalikku meie jaoks, oskab teha varukoopiaid ja toetab ühenduste basseini. Omab automaatset vahetust: kui master sureb, muutub replikast uus master ja AWS muudab dns-kirje uuele masterile, samal ajal kui replikad võivad olla erinevates AZ-des.

Puudustena võib välja tuua peente seadete puudumise. Näiteks peene seadistusena on meie instantsidel TCP-ühenduste jaoks piirangud, mida kahjuks RDS-is teha ei saa:

net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3

Lisaks on AWS RDS hind peaaegu kaks korda kallim kui tava hind instantside puhul, mis oli ka peamine põhjus selle lahenduse käest ära ütlemiseks.

Patronit

See on Pythonis kirjutatud mall PostgreSQL haldamiseks, millel on hea dokumentatsioon, automaatne failover ja source code GitHubis.

Patroni plussid:

• Iga seadistuse parameeter on kirjas, on selge, kuidas mis töötab;
• Automaatne failover töötab karbist välja;
• Kirjutatud Pythonis ja kuna me ise kirjutame palju Pythonis, siis on meil lihtsam lahendada probleeme ja võib-olla isegi aidata projekti arengus;
• Haldab täielikult PostgreSQL-i, võimaldab muuta konfiguratsiooni kohe kõigil klastrinoodidel, ja kui uue konfiguratsiooni kasutamiseks on vajalik klastrit taaskäivitada, saab seda taas teha Patroni abil.

Miinused:

• Dokumentatsioonist ei ole selge, kuidas õigesti PgBounceriga töötada. Kuigi seda on keeruline miinuseks pidada, sest Patroni ülesanne on hallata PostgreSQL-i, ja kuidas ühendused Patronisse jõuavad, on juba meie probleem;
• Patroni rakendamise näidiseid on vähe suurte koguste puhul, samas on palju näiteid rakendamise algusest.

Kokkuvõttes valisime kõrgema usaldusväärsuse klastri loomiseks just Patroni.

Patroni rakendamise protsess

Enne Patronit oli meil 12 PostgreSQL shard'i konfiguratsioonis, kus oli üks meister ja üks replikatsioon asünkroonse replikatsiooniga. Rakenduste serverid kasutasid andmebaase Network Load Balancer'i kaudu, mille taga olid kaks PgBouncer'i instantsi, ja nende taga kõik PostgreSQL serverid.

Patroni rakendamiseks pidime valima klastrite konfiguratsiooni jaotatud salvestuse. Patroni töötab jaotatud konfiguratsioonide salvestussüsteemidega nagu etcd, Zookeeper ja Consul. Meil on tootmises täielik Consul klaster, mis töötab koos Vault'iga ja me ei kasuta seda muul viisil. Suurepärane võimalus hakata Consulit sihipäraselt kasutama.

Kuidas Patroni töötab koos Consuliga

Meil on Consul klaster, mis koosneb kolmest sõlmest ja Patroni klaster, mis koosneb ülemast ja replikast (Patronis nimetatakse meistrit klastrite ülemaks ja koopiaid replikateks). Iga Patroni klastrite instants saadab pidevalt Consulile teavet klastrite oleku kohta. Seetõttu on Consul'is alati võimalik teada saada hetke Patroni klastrite konfiguratsiooni ja kes on antud hetkel ülem.

Patroni ühendamiseks Consuliga piisab ametliku dokumentatsiooni uurimisest, kus on kirjas, et tuleb näidata hosti http või https formaadis, olenevalt meie tööviisist Consuliga, ja ühenduse skeemi, valikuline:

host: Consul'i lõpp-punkti host:port, formaadis: http(s)://host:port
scheme: (valikuline) http või https, vaikeväärtuseks on http

See tundub lihtne, kuid siin algavad probleemid. Consul'iga töötame kaitstud ühenduse kaudu https kaudu ja meie ühenduse konfigureerimine näeb välja järgmine:

consul:
  host: https://server.production.consul:8080 
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

Kuid see ei tööta. Patroni käivitamisel ei saa see Consul'iga ühendust, sest ta proovib ikkagi minna http kaudu.

Probleemi lahendamine osutus annetatud Patroni lähtekoodiks. Hea, et see on kirjutatud python'is. Selgub, et parameetrit host ei parsita, vaid protokoll tuleb näidata skeemis. Nii näeb välja töötav konfiguratsiooniblokk Consul'iga töötamiseks meie jaoks:

consul:
  host: server.production.consul:8080
  scheme: https
  verify: true
  cacert: {{ consul_cacert }}
  cert: {{ consul_cert }}
  key: {{ consul_key }}

Consul-template

Nii, me oleme valinud konfiguratsioonide mahuti. Nüüd tuleb mõista, kuidas PgBouncer muudab oma konfiguratsiooni, kui Patroni klastris liider vahetub. Selle kohta dokumentatsioonis vastust ei leidu, kuna PgBouncer'i kasutamine ei ole seal põhjalikult kirjeldatud.

Lahendust otsides leidsime artikli (pealkirja, kahjuks, ei mäleta), kus kirjutati, et Consul-template aitas väga hästi PgBouncer'i ja Patroni vahel. See suunaski meid uurima Consul-template'i tööd.

Selgus, et Consul-template jälgib pidevalt PostgreSQL klastri konfiguratsiooni Consulis. Liidri vahetamisel uuendab ta PgBouncer'i konfiguratsiooni ja saadab käsu selle taaskäivitamiseks.

Suur pluss template'i juures on see, et see on salvestatud koodina, seega on uue shardi lisamisel piisav teha uus commit ja automaatse protsessiga template uuendada, toetades Infrastructure as Code põhimõtet.

Uus arhitektuur Patroniga

Tulemuseks saime järgmise tööskeemi:

Kõik rakenduse serverid pöörduvad tasakaalustaja poole → selle taga on kaks PgBouncer'i instantsi → igal instantsil töötab Consul-template, mis jälgib iga Patroni klastri olekut ja hoolitseb PgBouncer'i konfi ajakohasuse eest, suunates päringud iga klastri aktiivsele liidrile.

Käsitsi testimine

Enne tootmist lõpuleviimist käivitasime selle skeemi väikeses testkeskkonnas ja kontrollisime automaatse vahetamise toimimist. Avastasime tahvli, liikusime kleebise ümber ja samal ajal 'tapsime' klastri liidri. AWS-is piisab selleks instantsi konsoliga välja lülitamisest.

Kleebis naases 10-20 sekundi jooksul tagasi, ja seejärel hakkas uuesti normaalselt liikuma. See tähendab, et Patroni klaster tegutses õigesti: vahetas liidri, edastas teabe Consulisse ja Consul-template haaras kohe selle teabe, asendas PgBouncer'i konfiguratsiooni ja saatis reload käsu.

Kuidas ellu jääda kõrge koormuse all ja hoida minimaalset seisuaja?

Kõik töötab suurepäraselt! Ent tekivad uued küsimused: Kuidas see töötab kõrge koormuse all? Kuidas kiiresti ja ohutult kõik tootmisse viia?

Esimesele küsimusele vastamiseks aitab meid testkeskkond, kus viime läbi koormustestimise. See on täielikult identne tootmisuuendusele arhitektuurilt ja sisaldab genereeritud testandmeid, mille maht on ligikaudu sama kui tootmises. Me otsustame lihtsalt 'tappa' ühe PostgreSQL meistritest testimise ajal ja vaadata, mis juhtub. Kuid enne seda on oluline kontrollida automaatset ümberpaigutamist, kuna sellel keskkonnas on meil mitu PostgreSQL shard'i, seega saame suurepärase konfigureerimisskriptide testimise enne tootmist.

Mõlemad ülesanded näevad ambitsioonikad välja, kuid meil on PostgreSQL 9.6. Kas me võiks kohe 11.2 versioonile üle minna?

Otsustame teha seda kahes etapis: esmalt uuendame versiooni 11.2 peale, seejärel käivitame Patroni.

PostgreSQL uuendamine

PostgreSQL versiooni kiireks uuendamiseks tuleb kasutada valikut -k, mille puhul luuakse kõvakettale hard link ja teie andmete kopeerimine ei ole vajalik. 300–400 GB suuruste andmebaaside puhul kestab uuendamine 1 sekund.

Meil on palju shard'e, seega peab uuendamine toimuma automaatselt. Selleks oleme kirjutanud Ansible playbook'i, mis teostab kogu uuendamise protsessi meie eest:

/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='

Siinkohal on oluline märkida, et enne uuenduse käivitamist tuleb see teha parameetriga —check, et olla kindel uuenduse võimalikuses. Samuti meie skript asendab konfiguratsioone uuenduse ajaks. Meie skript täitis ülesande 30 sekundiga, see on suurepärane tulemus.

Patroni käivitamine

Teise probleemi lahendamiseks piisab Patroni konfiguratsiooni vaatamisest. Ametlikus hoidlas on olemas näidiskonfiguratsioon koos initdb'ga, mis vastutab uue andmebaasi initsialiseerimise eest Patroni esmakordsel käivitamisel. Kuid kuna meil on juba valmis andmebaas, siis lihtsalt kustutasime selle osa konfiguratsioonist.

Kui me hakkasime Patroni installima juba olemasolevale PostgreSQL klastrile ja seda käivitama, siis kokku puutusime uue probleemiga: mõlemad serverid käivitusid juhtidena. Patroni ei tea klastrite varasemast olekust ja proovib käivitada mõlemat serverit kui kahte eraldi klastri samu nimesid. Selle probleemi lahendamiseks on vajalik kustutada slave'i andmed direktorium:

rm -rf /var/lib/postgresql/

Seda tuleb teha ainult slave'il!

Puhta replika ühendamisel teeb Patroni basebackup'i juhist ja taastab selle replikale, seejärel hoiab see ajakohast seisundit wal-logide kaudu.

Veel raskusi, millega silmitsi seisime, oli see, et kõik PostgreSQL klastrid on vaikimisi nimega main. Kui iga klaster ei tea teistest, siis on kõik korras. Kuid kui soovite kasutada Patronit, peavad kõik klastrid omama ainulaadset nime. Lahendus on muuta PostgreSQL konfiguratsioonis klastri nime.

Koormustest

Läksime testima, simuleerides kasutajate tööd foorumites. Kui koormus jõudis meie keskmisele päevasele tasemele, kordasime täpselt sama testi, kus katkestasime ühe instance'i, millel oli PostgreSQL juht. Automaatne failover toimis ootuspäraselt: Patron vahetas juhti, Consul-template uuendas PgBounceri konfiguratsiooni ja saatis reload-käsu. Meie Grafanas olevad graafikud näitasid, et esines 20-30 sekundi viivitusi ja mõningaid vigu serveritest, mis olid seotud andmebaasi ühendamisega. See on normaalne olukord, sellised näitajad on meie failoveri jaoks vastuvõetavad ja kindlasti parem kui teenuse seiskumine.

Patroni käitamine tootmises

Kokkuvõttes saime järgmise plaani:

• Consul-template'i paigaldamine PgBounceri serveritesse ja käivitamine;
• PostgreSQL värskendamine versioonile 11.2;
• Klastri nime muutmine;
• Patroni klastri käivitamine.

Samas võimaldab meie skeem teha esimese punkti praktiliselt igal ajal, saame järjestikku iga PgBounceri töölt eemaldada ja teha selle jaoks Consul-template'i paigaldamise ja käivitamise. Just seda me tegime.

Kiireks juurutamiseks kasutasime Ansible'i, kuna kõik playbookid olime juba testkeskkonnas kontrollinud, ning kogu stsenaariumi täitmise aeg oli iga shard'i jaoks 1,5 kuni 2 minutit. Saime kõik järjestikku igale shard'ile juurutada ilma meie teenuse seiskamiseta, kuid pidime iga PostgreSQL mõneks minutiks välja lülitama. Sel juhul ei saaks kasutajad, kelle andmed on sellel shard'il, samaaegselt töötada, mis meie jaoks pole vastuvõetav.

Situatsioonist pääsemiseks toimus planeeritud hooldus, mis meil toimub iga 3 kuu tagant. See on aeg, mil teeme täiesti välja meie teenuse ning uuendame andmebaasi instantsid. Jäänud oli nädal järgmise aknani ja otsustasime lihtsalt oodata ning valmistuda. Ootamise ajal tegime täiendavaid ettevaatusabinõusid: iga PostgreSQL shard'i jaoks tõime üles varureplika juhuks, kui midagi läheks valesti, et säilitada viimaseid andmeid, ja lisasime iga shardi jaoks uue instantsi, millest peaks saama uus replik Patroni klastris, et mitte täita käsu andmete kustutamiseks. See kõik aitas minimeerida vea riski.

Taaskäivitame oma teenuse, kõik töötas nagu peab, kasutajad jätkasid tööd, kuid graafikutel märkasime ebanormaalset kõrget koormust Consul-serveritele.

Miks me ei näinud seda testkeskkonnas? See probleem illustreerib väga hästi, et on vajalik järgida infrastruktuuri kui koodi põhimõtet ja täiendada kogu infrastruktuuri alates testkeskkondadest kuni tootmiseni. Vastasel juhul on väga lihtne sattuda sellisesse probleemisse nagu meil. Mis juhtus? Consul ilmus esmalt tootmisesse ja alles sitten testkeskkondades, mille tulemusena testkeskkondade versioon Consulist oli kõrgem kui tootmises. Ühes versioonide väljaandes lahendati CPU leke, kui töötati consul-template'iga. Seetõttu uuendusime lihtsalt Consulit, lahendades nii probleemi.

Taaskäivita Patroni klaster

Kuid me sattusime uude probleemisse, millest me isegi ei kahtlustanud. Consuli uuendamise käigus kustutame lihtsalt Consuli sõlme klastrist käsuga consul leave → Patroni ühendub teise Consul-serveriga → kõik töötab. Kuid kui jõudsime viimase instantsi Consuli klastrisse ja saatasime talle käsu consul leave, taaskäivitusid kõik Patroni klastrid ja logides nägime järgmist viga:

VIGA: get_cluster
Jälgimine (viimane kutse viimasena):
...
RetryFailedError: 'Ületatud korduse tähtaeg'
VIGA: Viga suhtlemisel DCS-iga
<b>LOG: andmebaasisüsteem on välja lülitatud</b>

Patroni klaster ei suutnud saada teavet oma klastri kohta ja taaskäivitati.

Lahenduse leidmiseks pöördusime Patroni autorite poole GitHubi kaudu. Nad soovitasid meie konfiguratsioonifailide täiustusi:

consul:
 consul.checks: []
bootstrap:
 dcs:
   retry_timeout: 8

Me suutsime probleemi testkeskkonnas uuesti esitada ja testisime seal neid parameetreid, kuid kahjuks need ei toiminud.

Probleem jääb endiselt lahendamata. Planeerime proovida järgmisi lahendusi:

• Kasutada Consul-agent'i igas Patroni klastris asuvas instantsis;
• Parandada probleem koodis.

Meile on teada vea tekkimise koht: tõenäoliselt on probleem default timeout'i kasutamises, mida ei ümbersõideta konfiguratsioonifailis. Kui viimane Consul server eemaldatakse klastri seest, jääb kogu Consul-klaster hanguma, mis kestab kauem kui sekund, mistõttu ei saa Patroni klastri seisundit määrata ja käivitab kogu klastri täielikult uuesti.

Õnneks ei ole me kokku puutunud millegi muuga, mis viga tekitaks.

Patroni kasutamise tulemused

Pärast Patroni edukat käivitamist lisasime igasse klastrisse ühe täiendava replitseerimise. Nüüd on igas klastris mingi kuorum: üks juht ja kaks replitseerimist, et tagada ohutus split-braini korral vahetamise ajal.

Tootmises on Patroni töötanud üle kolme kuu. Selle aja jooksul on see meid juba aidanud. Hiljuti suri AWS-is ühe klastri juht, automaatne failover toimis ja kasutajad jätkasid tööd. Patroni täitis oma peamist ülesannet.

Väike kokkuvõte Patroni kasutamisest:

• Konfiguratsiooni muutmise mugavus. Piisab konfiguratsiooni muutmisest ühel instantsil ja see tõmmatakse kogu klastrisse. Kui uue konfiguratsiooni rakendamiseks on vajalik taaskäivitamine, siis Patroni annab sellest teada. Patroni saab kogu klastrit taaskäivitada ühe käsuga, mis on samuti väga mugav.
• Automaatne failover töötab ja on meid juba aidanud.
• PostgreSQL uuendamine ilma rakenduse seisaku. Esiteks tuleb uuendada replitseerimise uus versioon, seejärel vahetada klastri Patronis juht ja uuendada vana juhti. Sellega kaasneb vajalik automaatse failoveri testimine.

Allikas: habr.com