Artiklis räägin teile, kuidas lähenesime PostgreSQL tõrketaluvuse küsimusele, miks see meie jaoks oluliseks sai ja mis lõpuks juhtus.
Meil on väga koormatud teenus: 2,5 miljonit kasutajat üle maailma, 50 100+ aktiivset kasutajat iga päev. Serverid asuvad ühes Iirimaa piirkonnas Amazones: pidevalt töötab 50+ erinevat serverit, millest ligi XNUMX on andmebaasidega.
Kogu taustaprogramm on suur monoliitne olekupõhine Java-rakendus, mis hoiab kliendiga pidevat veebipesaühendust. Kui samal tahvlil töötab korraga mitu kasutajat, näevad nad kõik muudatusi reaalajas, sest me kirjutame iga muudatuse andmebaasi. Meil on meie andmebaasidele umbes 10 80 päringut sekundis. Tippkoormusel Redis kirjutame 100-XNUMXK päringut sekundis.
Miks vahetasime Rediselt PostgreSQL-ile
Esialgu töötas meie teenus võtmeväärtuste salvestaja Redisega, mis salvestab kõik andmed serveri RAM-i.
Redise plussid:
- Suur reageerimiskiirus, kuna kõik salvestatakse mällu;
- Varundamise ja replikatsiooni lihtsus.
Redise miinused meie jaoks:
- Reaalseid tehinguid ei toimu. Püüdsime neid oma rakenduse tasemel simuleerida. Kahjuks see alati hästi ei töötanud ja nõudis väga keerulise koodi kirjutamist.
- Andmemaht on piiratud mälumahuga. Andmemahu kasvades mälu kasvab ja lõpuks puutume kokku valitud eksemplari omadustega, mis nõuab AWS-is meie teenuse peatamist eksemplari tüübi muutmiseks.
- On vaja pidevalt hoida madalat latentsusaega, sest. meil on väga palju taotlusi. Meie jaoks on optimaalne viite tase 17-20 ms. Tasemel 30–40 ms saame pikki vastuseid oma rakenduselt päringutele ja teenuse halvenemisele. Kahjuks juhtus see meil 2018. aasta septembris, kui üks Redisega juhtudest sai mingil põhjusel latentsusaega 2 korda rohkem kui tavaliselt. Probleemi lahendamiseks peatasime teenuse keskpäeval plaanivälise hoolduse tõttu ja asendasime probleemse Redise eksemplari.
- Lihtne on tuvastada andmete vastuolu isegi väiksemate vigade korral koodis ja seejärel kulutada palju aega nende andmete parandamiseks koodi kirjutamisele.
Võtsime arvesse miinuseid ja mõistsime, et peame üle minema millegi mugavama juurde, kus on normaalsed tehingud ja vähem sõltuvus latentsusest. Viis läbi uurimistööd, analüüsis paljusid võimalusi ja valis PostgreSQL-i.
Oleme juba 1,5 aastat liikunud uude andmebaasi ja liigutanud vaid väikese osa andmetest, seega töötame nüüd samaaegselt Redise ja PostgreSQL-iga. Täpsem info andmete teisaldamise ja andmekogude vahel vahetamise etappide kohta on sisse kirjutatud .
Kui me esimest korda liikuma hakkasime, töötas meie rakendus otse andmebaasiga ja pääses juurde põhiprogrammile Redis ja PostgreSQL. PostgreSQL-klaster koosnes põhiseadmest ja asünkroonse replikatsiooniga koopiast. Andmebaasi skeem nägi välja selline:
PgBounceri rakendamine
Kolimise ajal arenes ka toode: suurenes PostgreSQL-iga töötavate kasutajate ja serverite arv ning meil hakkas puuduma ühendused. PostgreSQL loob iga ühenduse jaoks eraldi protsessi ja kulutab ressursse. Saate ühenduste arvu teatud punktini suurendada, vastasel juhul on võimalus saada ebaoptimaalne andmebaasi jõudlus. Ideaalne variant sellises olukorras oleks valida ühendusehaldur, mis seisab aluse ees.
Meil oli ühendusehalduri jaoks kaks võimalust: Pgpool ja PgBouncer. Kuid esimene ei toeta andmebaasiga töötamise tehingurežiimi, seega valisime PgBounceri.
Oleme üles seadnud järgmise tööskeemi: meie rakendus pääseb juurde ühele PgBouncerile, mille taga on PostgreSQL-i masterid ja iga masteri taga on üks asünkroonse replikatsiooniga koopia.
Samal ajal ei saanud me kogu andmemahtu PostgreSQL-is salvestada ja meie jaoks oli oluline andmebaasiga töötamise kiirus, mistõttu hakkasime PostgreSQL-i jagama rakenduse tasemel. Eelkirjeldatud skeem on selleks suhteliselt mugav: uue PostgreSQL-i killu lisamisel piisab PgBounceri konfiguratsiooni värskendamisest ja rakendus saab kohe uue shardiga tööle hakata.
PgBounceri tõrkeotsas
See skeem töötas kuni hetkeni, mil ainus PgBounceri eksemplar suri. Oleme AWS-is, kus kõik eksemplarid töötavad riistvaraga, mis aeg-ajalt sureb. Sellistel juhtudel liigub eksemplar lihtsalt uuele riistvarale ja töötab uuesti. See juhtus PgBounceriga, kuid see muutus kättesaamatuks. Selle kukkumise tagajärjeks oli meie teenuse kättesaamatus 25 minutiks. AWS soovitab sellisteks olukordadeks kasutada kasutajapoolset koondamist, mida meie riigis sel ajal ei rakendatud.
Pärast seda mõtlesime tõsiselt PgBounceri ja PostgreSQL-i klastrite tõrketaluvusele, sest sarnane olukord võib juhtuda iga meie AWS-i konto eksemplariga.
PgBounceri tõrketaluvuse skeemi ehitasime üles järgmiselt: kõik rakendusserverid pääsevad ligi Network Load Balancerile, mille taga on kaks PgBouncerit. Iga PgBouncer vaatab iga killu sama PostgreSQL-i masteri. Kui AWS-i eksemplari krahh kordub, suunatakse kogu liiklus ümber teise PgBounceri kaudu. Network Load Balanceri tõrkesiirde tagab AWS.
See skeem muudab uute PgBounceri serverite lisamise lihtsaks.
Looge PostgreSQL-i tõrkesiirdeklaster
Selle probleemi lahendamisel kaalusime erinevaid võimalusi: ise kirjutatud failover, repmgr, AWS RDS, Patroni.
Ise kirjutatud stsenaariumid
Nad saavad jälgida põhiseadme tööd ja selle rikke korral reklaamida koopiat ülemseadmele ja värskendada PgBounceri konfiguratsiooni.
Selle lähenemisviisi eelisteks on maksimaalne lihtsus, kuna kirjutate ise skripte ja saate täpselt aru, kuidas need töötavad.
miinuseid:
- Juht ei pruugi surnud, selle asemel võis tekkida võrgutõrge. Failover, kes ei ole sellest teadlik, viib koopia üle meistrile, samal ajal kui vana meister jätkab tööd. Selle tulemusena saame kaks serverit master rolli ja me ei tea, kummal neist on kõige värskemad andmed. Seda olukorda nimetatakse ka lõhenenud ajuks;
- Jäime vastuseta. Meie konfiguratsioonis on juht ja üks koopia, pärast ümberlülitamist liigub koopia ülemseadmesse ja meil pole enam koopiaid, seega peame uue koopia käsitsi lisama;
- Vajame tõrkesiirdeoperatsiooni täiendavat jälgimist, samas kui meil on 12 PostgreSQL-i killukest, mis tähendab, et peame jälgima 12 klastrit. Kildude arvu suurenemisega peate meeles pidama ka tõrkesiirde värskendamist.
Isetehtud tõrkeotsas näib väga keeruline ja nõuab mittetriviaalset tuge. Ühe PostgreSQL klastri puhul oleks see kõige lihtsam variant, aga see ei skaleeru, seega meile ei sobi.
Repmgr
PostgreSQL-klastrite replikatsioonihaldur, mis suudab hallata PostgreSQL-klastri tööd. Samal ajal ei ole sellel automaatset karbist väljalülitamist, nii et töö jaoks peate valmis lahenduse peale kirjutama oma "ümbrise". Nii et kõik võib osutuda veelgi keerulisemaks kui ise kirjutatud skriptidega, nii et me isegi ei proovinud Repmgr-i.
AWS RDS
Toetab kõike, mida vajame, teab, kuidas varukoopiaid teha ja hoiab ühenduste kogumit. Sellel on automaatne ümberlülitus: kui juht sureb, saab koopiast uus juht ja AWS muudab dns-kirje uueks ülemseadmeks, samas kui koopiad võivad asuda erinevates AZ-des.
Puuduste hulka kuulub peente reguleerimise puudumine. Peenhäälestuse näide: meie eksemplaridel on tcp-ühendustele 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 ligi kaks korda kallim kui tavaline eksemplari hind, mis oli peamiseks põhjuseks sellest lahendusest loobumisel.
Patroni
See on Pythoni mall PostgreSQL-i haldamiseks koos hea dokumentatsiooni, automaatse tõrkesiirde ja lähtekoodiga githubis.
Patroni plussid:
- Iga konfiguratsiooniparameetrit kirjeldatakse, on selge, kuidas see töötab;
- Automaatne tõrkesiirde töötab karbist välja;
- Pythonis kirjutatud ja kuna me ise kirjutame palju pythonis, on meil lihtsam probleemidega toime tulla ja võib-olla isegi projekti arendamisele kaasa aidata;
- Haldab täielikult PostgreSQL-i, võimaldab muuta konfiguratsiooni klastri kõigis sõlmedes korraga ja kui uue konfiguratsiooni rakendamiseks on vaja klastrit taaskäivitada, saab seda uuesti teha, kasutades Patroni.
miinuseid:
- Dokumentatsioonist ei selgu, kuidas PgBounceriga õigesti töötada. Kuigi seda on raske miinuseks nimetada, sest Patroni ülesanne on hallata PostgreSQL-i ja kuidas Patroniga ühendused sujuvad, on juba meie probleem;
- Näiteid Patroni rakendamisest suurtes mahtudes on vähe, samas on palju näiteid nullist rakendamisest.
Selle tulemusena valisime tõrkesiirdeklastri loomiseks Patroni.
Patroni rakendusprotsess
Enne Patronit oli meil 12 PostgreSQL-i killu konfiguratsioonis, mis koosnes ühest peamisest ja ühest asünkroonse replikatsiooniga koopiast. Rakendusserverid pääsesid andmebaasidele ligi Network Load Balanceri kaudu, mille taga olid kaks PgBounceriga eksemplari ja nende taga olid kõik PostgreSQL-i serverid.
Patroni juurutamiseks pidime valima hajutatud salvestusklastri konfiguratsiooni. Patroni töötab hajutatud konfiguratsioonisalvestussüsteemidega, nagu etcd, Zookeeper, Consul. Meil on just turul täieõiguslik konsulite klaster, mis töötab koos Vaultiga ja me ei kasuta seda enam. Suurepärane põhjus hakata Consulit sihtotstarbeliselt kasutama.
Kuidas Patroni konsuliga töötab
Meil on konsulite klaster, mis koosneb kolmest sõlmest, ja Patroni klaster, mis koosneb liidrist ja koopiast (Patronis nimetatakse masterit klastri juhiks ja orje koopiateks). Iga Patroni klastri eksemplar saadab konsulile pidevalt teavet klastri oleku kohta. Seetõttu saate Consulilt alati teada, milline on Patroni klastri hetkekonfiguratsioon ja kes on hetkel liider.
Patroni ühendamiseks Consuliga piisab, kui uurida ametlikku dokumentatsiooni, mis ütleb, et peate määrama hosti http- või https-vormingus, olenevalt sellest, kuidas me Consuliga töötame, ja valikuliselt ühendusskeemi:
host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to httpSee tundub lihtne, kuid siit algavad lõksud. Consuliga töötame turvalise ühenduse kaudu https-i kaudu ja meie ühenduse konfiguratsioon näeb välja järgmine:
consul:
host: https://server.production.consul:8080
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}Aga see ei tööta. Käivitamisel ei saa Patroni Consuliga ühendust luua, kuna see proovib niikuinii läbida http kaudu.
Patroni lähtekood aitas probleemiga toime tulla. Hea, et see on pythonis kirjutatud. Selgub, et hosti parameetrit ei sõeluta mingil viisil ja protokoll tuleb skeemis täpsustada. Konsuliga töötamise konfiguratsiooniplokk näeb meie jaoks välja järgmine:
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}konsul-mall
Niisiis, oleme valinud konfiguratsiooni jaoks salvestusruumi. Nüüd peame mõistma, kuidas PgBouncer Patroni klastri liidri vahetamisel oma konfiguratsiooni vahetab. Sellele küsimusele pole dokumentatsioonis vastust, sest. seal tööd PgBounceriga põhimõtteliselt ei kirjeldata.
Lahendust otsides leidsime artikli (pealkirja kahjuks ei mäleta), kus oli kirjas, et Сonsul-mall aitas PgBounceri ja Patroni sidumisel palju kaasa. See ajendas meid uurima, kuidas konsuli mall töötab.
Selgus, et Consul-template jälgib pidevalt Consuli PostgreSQL klastri konfiguratsiooni. Kui juht muutub, värskendab see PgBounceri konfiguratsiooni ja saadab käsu selle uuesti laadimiseks.
Malli suureks plussiks on see, et see salvestatakse koodina, seega piisab uue shardi lisamisel uue commit tegemisest ja malli automaatsest uuendamisest, toetades Infrastructure as code põhimõtet.
Uus arhitektuur koos Patroniga
Selle tulemusena saime järgmise tööskeemi:
Kõik rakendusserverid pääsevad juurde tasakaalustajale → selle taga on kaks PgBounceri eksemplari → igal eksemplaril käivitatakse Consul-mall, mis jälgib iga Patroni klastri olekut ja jälgib PgBounceri konfiguratsiooni asjakohasust, mis saadab päringuid praegusele juhile. igast klastrist.
Käsitsi testimine
Käitasime selle skeemi enne käivitamist väikeses testkeskkonnas ja kontrollisime automaatse ümberlülituse toimimist. Nad avasid tahvli, liigutasid kleebist ja sel hetkel “tappisid” klastri juhi. AWS-is on see sama lihtne kui eksemplari väljalülitamine konsooli kaudu.
Kleebis naasis 10-20 sekundi jooksul ja hakkas siis jälle normaalselt liikuma. See tähendab, et Patroni klaster töötas õigesti: see vahetas juhti, saatis teabe Consulile ja Consul-template võttis selle teabe kohe üles, asendas PgBounceri konfiguratsiooni ja saatis käsu uuesti laadida.
Kuidas suure koormuse all ellu jääda ja seisakuid minimaalsena hoida?
Kõik töötab ideaalselt! Kuid on uusi küsimusi: kuidas see suure koormuse korral töötab? Kuidas kiiresti ja ohutult kõik tootmises kasutusele võtta?
Testikeskkond, milles koormustestimist läbi viime, aitab meil vastata esimesele küsimusele. See on arhitektuuri poolest täiesti identne tootmisega ja on genereerinud katseandmeid, mis on mahult ligikaudu võrdsed tootmisega. Otsustame testi ajal ühe PostgreSQL-i meistrite lihtsalt "tappa" ja vaadata, mis juhtub. Kuid enne seda on oluline kontrollida automaatset rullimist, kuna selles keskkonnas on meil mitu PostgreSQL-i killustikku, nii et saame konfiguratsiooniskripte enne tootmist suurepäraselt testida.
Mõlemad ülesanded tunduvad ambitsioonikad, kuid meil on PostgreSQL 9.6. Kas saame kohe üle minna versioonile 11.2?
Otsustame seda teha kahes etapis: esmalt uuendame versioonile 2, seejärel käivitame Patroni.
PostgreSQL-i värskendus
PostgreSQL-i versiooni kiireks värskendamiseks kasutage valikut -k, milles kõvad lingid luuakse kettale ja teie andmeid pole vaja kopeerida. 300–400 GB baasil võtab värskendamine aega 1 sekundi.
Meil on palju kilde, seega tuleb värskendus teha automaatselt. Selleks kirjutasime Ansible mänguraamatu, mis käsitleb kogu värskendusprotsessi 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 uuendamise alustamist peate selle parameetriga läbi viima --Kontrollimaveendumaks, et saate uuendada. Meie skript asendab ka konfiguratsioone täienduse ajaks. Meie skript valmis 30 sekundiga, mis on suurepärane tulemus.
Käivitage Patroni
Teise probleemi lahendamiseks vaadake lihtsalt Patroni konfiguratsiooni. Ametlikul hoidlal on näidiskonfiguratsioon initdb-ga, mis vastutab uue andmebaasi lähtestamise eest, kui käivitate Patroni esmakordselt. Kuid kuna meil on juba valmis andmebaas, eemaldasime selle jaotise lihtsalt konfiguratsioonist.
Kui alustasime Patroni installimist juba olemasolevasse PostgreSQL-klastrisse ja selle käivitamist, tekkis meil uus probleem: mõlemad serverid alustasid juhina. Patroni ei tea klastri varasest olekust midagi ja proovib käivitada mõlemad serverid kahe eraldi klastrina, millel on sama nimi. Selle probleemi lahendamiseks peate kustutama alamseadme andmetega kataloogi:
rm -rf /var/lib/postgresql/Seda tuleb teha ainult orja peal!
Kui on ühendatud puhas koopia, loob Patroni baasvarukoopia juhi ja taastab selle koopiasse ning jõuab seejärel praeguse olekuga järele vastavalt wali logidele.
Teine probleem, millega puutusime kokku, on see, et kõik PostgreSQL-klastrid on vaikimisi nimetatud peamiseks. Kui kumbki klaster ei tea teisest midagi, on see normaalne. Kuid kui soovite Patronit kasutada, peab kõigil klastritel olema kordumatu nimi. Lahenduseks on klastri nime muutmine PostgreSQL-i konfiguratsioonis.
koormustest
Oleme käivitanud testi, mis simuleerib kasutajakogemust tahvlitel. Kui koormus jõudis meie keskmise päevaväärtuseni, kordasime täpselt sama testi, ühe eksemplari lülitasime välja PostgreSQL liidriga. Automaatne tõrkevahetus toimis ootuspäraselt: Patroni vahetas juhti, Consul-template uuendas PgBounceri konfiguratsiooni ja saatis käsu uuesti laadida. Meie Grafana graafikute järgi oli selge, et andmebaasiga ühenduse loomisega on seotud 20-30-sekundilised viivitused ja väike hulk tõrkeid serveritest. See on normaalne olukord, sellised väärtused on meie tõrkevahetuse jaoks vastuvõetavad ja kindlasti paremad kui teenuse seisak.
Patroni toomine tootmisse
Selle tulemusena jõudsime järgmise plaanini:
- juurutage PgBounceri serveritesse Consul-mall ja käivitage;
- PostgreSQL-i värskendused versioonile 11.2;
- Muuda klastri nime;
- Patroni klastri käivitamine.
Samal ajal võimaldab meie skeem meil peaaegu igal ajal esimese punkti teha, saame iga PgBounceri kordamööda töölt eemaldada ning sellel konsuli malli juurutada ja käivitada. Nii me tegimegi.
Kiireks juurutamiseks kasutasime Ansible'i, kuna oleme kõik mänguraamatud juba testkeskkonnas testinud ja täisskripti täitmisaeg oli iga killu kohta 1,5–2 minutit. Võiksime kõik kordamööda igale killule levitada ilma oma teenust peatamata, kuid peaksime iga PostgreSQL-i mitmeks minutiks välja lülitama. Sel juhul ei saa kasutajad, kelle andmed on sellel killul, praegu täielikult töötada ja see on meie jaoks vastuvõetamatu.
Väljapääs sellest olukorrast oli plaaniline hooldus, mis toimub iga 3 kuu tagant. See on ajastatud töö aken, mil sulgeme oma teenuse täielikult ja uuendame oma andmebaasi eksemplare. Järgmise aknani oli jäänud nädal ja otsustasime lihtsalt oodata ja edasi valmistuda. Ooteaja jooksul turvasime end täiendavalt: iga PostgreSQL-i killu jaoks tõstsime varukoopia juhuks, kui uusimate andmete säilitamine ebaõnnestus, ja lisasime igale killule uue eksemplari, millest peaks saama uus koopia Patroni klastris, et mitte täita andmete kustutamise käsku. Kõik see aitas minimeerida veaohtu.
Taaskäivitasime oma teenuse, kõik töötas nii nagu peab, kasutajad jätkasid tööd, kuid graafikutel märkasime Consuli serverite ebanormaalselt suurt koormust.
Miks me seda testkeskkonnas ei näinud? See probleem illustreerib väga hästi, et on vaja järgida infrastruktuuri kui koodi põhimõtet ja viimistleda kogu taristut alates testkeskkondadest kuni tootmiseni. Vastasel juhul on tekkinud probleem väga lihtne. Mis juhtus? Consul ilmus esmalt tootmis- ja seejärel testkeskkondadesse, mille tulemusena oli testkeskkondades Consuli versioon kõrgem kui tootmisversioon. Just ühes väljaandes lahendati konsul-malliga töötamisel protsessori leke. Seetõttu värskendasime lihtsalt konsulit, lahendades sellega probleemi.
Taaskäivitage Patroni klaster
Saime aga uue probleemi, mida me isegi ei kahtlustanud. Consuli värskendamisel eemaldame lihtsalt konsuli sõlme klastrist, kasutades käsku consul lahku → Patroni loob ühenduse teise Consuli serveriga → kõik töötab. Kuid kui jõudsime konsuli klastri viimase eksemplarini ja saatsime sellele konsuli lahkumiskäsu, käivitusid kõik Patroni klastrid lihtsalt uuesti ja logides nägime järgmist viga:
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>Patroni klaster ei saanud oma klastri kohta teavet ja see käivitati uuesti.
Lahenduse leidmiseks võtsime githubi probleemi kaudu ühendust Patroni autoritega. Nad soovitasid meie konfiguratsioonifailide täiustamist:
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8Saime probleemi testkeskkonnas korrata ja testisime neid võimalusi seal, kuid kahjuks need ei töötanud.
Probleem on endiselt lahendamata. Plaanime proovida järgmisi lahendusi:
- Kasutage igal Patroni klastri eksemplaril Consul-agenti;
- Parandage probleem koodis.
Saame aru, kus viga tekkis: probleemiks on tõenäoliselt vaikimisi ajalõpu kasutamine, mida konfiguratsioonifaili kaudu ei tühistata. Kui viimane Consuli server klastrist eemaldatakse, hangub kogu Consul klaster rohkem kui sekundiks, seetõttu ei saa Patroni klastri olekut saada ja taaskäivitab kogu klastri täielikult.
Õnneks me rohkem vigu ei kohanud.
Patroni kasutamise tulemused
Pärast Patroni edukat käivitamist lisasime igasse klastrisse täiendava koopia. Nüüd on igas klastris justkui kvoorum: üks juht ja kaks koopiat turvavõrguks juhuks, kui vahetamisel aju lõheneb.
Patroni on tootmise kallal töötanud üle kolme kuu. Selle aja jooksul on ta jõudnud meid juba hädast välja aidata. Hiljuti suri ühe klastri juht AWS-is, automaatne tõrkesiirde toimis ja kasutajad jätkasid tööd. Patroni täitis oma põhiülesande.
Väike kokkuvõte Patroni kasutamisest:
- Konfiguratsiooni muutmise lihtsus. Piisab konfiguratsiooni muutmisest ühel eksemplaril ja see tõmmatakse kogu klastrisse. Kui uue konfiguratsiooni rakendamiseks on vaja taaskäivitamist, annab Patroni teile sellest teada. Patroni saab kogu klastri taaskäivitada ühe käsuga, mis on samuti väga mugav.
- Automaatne tõrkesiirde toimib ja on juba suutnud meid aidata.
- PostgreSQL-i värskendus ilma rakenduse seisakuta. Peate esmalt värskendama koopiaid uuele versioonile, seejärel muutma Patroni klastri liidrit ja värskendama vana liidrit. Sel juhul toimub automaatse tõrkevahetuse vajalik testimine.
Allikas: www.habr.com