In die artikel sal ek jou vertel hoe ons die kwessie van PostgreSQL-fouttoleransie benader het, hoekom dit vir ons belangrik geword het en wat op die ou end gebeur het.
Ons het 'n hoogs gelaaide diens: 2,5 miljoen gebruikers wêreldwyd, 50K+ aktiewe gebruikers elke dag. Die bedieners is in Amazone in een streek van Ierland geleë: 100+ verskillende bedieners is voortdurend in werking, waarvan byna 50 met databasisse is.
Die hele backend is 'n groot monolitiese stateful Java-toepassing wat 'n konstante websocket-verbinding met die kliënt hou. Wanneer verskeie gebruikers gelyktydig op dieselfde bord werk, sien hulle almal die veranderinge in reële tyd, want ons skryf elke verandering na die databasis. Ons het ongeveer 10K versoeke per sekonde na ons databasisse. Met pieklading in Redis skryf ons 80-100K versoeke per sekonde.
Waarom ons van Redis na PostgreSQL oorgeskakel het
Aanvanklik het ons diens gewerk met Redis, 'n sleutelwaarde-winkel wat alle data in die bediener se RAM stoor.
Voordele van Redis:
- Hoë reaksie spoed, want alles word in die geheue gestoor;
- Gemak van rugsteun en replikasie.
Nadele van Redis vir ons:
- Daar is geen werklike transaksies nie. Ons het probeer om hulle op die vlak van ons toepassing te simuleer. Ongelukkig het dit nie altyd goed gewerk nie en vereis die skryf van baie komplekse kode.
- Die hoeveelheid data word beperk deur die hoeveelheid geheue. Soos die hoeveelheid data toeneem, sal die geheue groei, en uiteindelik sal ons die kenmerke van die geselekteerde instansie raakloop, wat in AWS vereis dat ons diens gestaak word om die tipe instansie te verander.
- Dit is nodig om voortdurend 'n lae latensievlak te handhaaf, want. ons het 'n baie groot aantal versoeke. Die optimale vertragingsvlak vir ons is 17-20 ms. Op 'n vlak van 30-40 ms, kry ons lang antwoorde op versoeke van ons toepassing en agteruitgang van die diens. Ongelukkig het dit met ons gebeur in September 2018, toe een van die gevalle met Redis om een of ander rede latency 2 keer meer as gewoonlik ontvang het. Om die probleem op te los, het ons die diens middernag gestaak vir ongeskeduleerde instandhouding en die problematiese Redis-instansie vervang.
- Dit is maklik om data inkonsekwentheid te kry, selfs met geringe foute in die kode en spandeer dan baie tyd om kode te skryf om hierdie data reg te stel.
Ons het die nadele in ag geneem en besef dat ons na iets geriefliker moet beweeg, met normale transaksies en minder afhanklikheid van latensie. Navorsing gedoen, baie opsies ontleed en PostgreSQL gekies.
Ons skuif al vir 1,5 jaar na 'n nuwe databasis en het net 'n klein deel van die data geskuif, so nou werk ons gelyktydig met Redis en PostgreSQL. Meer inligting oor die stadiums van verskuiwing en omskakeling van data tussen databasisse is in geskryf .
Toe ons die eerste keer begin beweeg het, het ons toepassing direk met die databasis gewerk en toegang tot die meester Redis en PostgreSQL verkry. Die PostgreSQL-kluster het bestaan uit 'n meester en 'n replika met asinchrone replikasie. Dit is hoe die databasisskema gelyk het:
Implementering van PgBouncer
Terwyl ons verhuis het, het die produk ook ontwikkel: die aantal gebruikers en die aantal bedieners wat met PostgreSQL gewerk het, het toegeneem, en ons het verbindings begin ontbreek. PostgreSQL skep 'n aparte proses vir elke verbinding en verbruik hulpbronne. U kan die aantal verbindings tot 'n sekere punt verhoog, anders is daar 'n kans om suboptimale databasisprestasie te kry. Die ideale opsie in so 'n situasie sal wees om 'n verbindingsbestuurder te kies wat voor die basis sal staan.
Ons het twee opsies vir die verbindingsbestuurder gehad: Pgpool en PgBouncer. Maar die eerste een ondersteun nie die transaksionele modus om met die databasis te werk nie, daarom het ons PgBouncer gekies.
Ons het die volgende werkskema opgestel: ons toepassing het toegang tot een PgBouncer, waaragter PostgreSQL-meesters is, en agter elke meester is een replika met asinchrone replikasie.
Terselfdertyd kon ons nie die hele hoeveelheid data in PostgreSQL stoor nie en die spoed van werk met die databasis was vir ons belangrik, so ons het begin om PostgreSQL op die toepassingsvlak te versplinter. Die skema hierbo beskryf is relatief gerieflik hiervoor: wanneer 'n nuwe PostgreSQL-skerf bygevoeg word, is dit genoeg om die PgBouncer-konfigurasie op te dateer en die toepassing kan dadelik met die nuwe skerf werk.
PgBouncer failover
Hierdie skema het gewerk tot die oomblik toe die enigste PgBouncer-instansie gesterf het. Ons is in AWS, waar alle gevalle op hardeware loop wat periodiek sterf. In sulke gevalle skuif die instansie eenvoudig na nuwe hardeware en werk weer. Dit het met PgBouncer gebeur, maar dit het onbeskikbaar geword. Die gevolg van hierdie herfs was die onbeskikbaarheid van ons diens vir 25 minute. AWS beveel aan om gebruikerskantoortolligheid vir sulke situasies te gebruik, wat nie op daardie stadium in ons land geïmplementeer is nie.
Daarna het ons ernstig nagedink oor die fouttoleransie van PgBouncer- en PostgreSQL-klusters, want 'n soortgelyke situasie kan met enige geval in ons AWS-rekening gebeur.
Ons het die PgBouncer-fouttoleransieskema soos volg gebou: alle toepassingsbedieners kry toegang tot die Network Load Balancer, waaragter daar twee PgBouncers is. Elke PgBouncer kyk na dieselfde PostgreSQL-meester van elke skerf. As 'n AWS-instansie-ongeluk weer plaasvind, word alle verkeer deur 'n ander PgBouncer herlei. Network Load Balancer failover word deur AWS verskaf.
Hierdie skema maak dit maklik om nuwe PgBouncer-bedieners by te voeg.
Skep 'n PostgreSQL Failover Cluster
Toe ons hierdie probleem oplos, het ons verskillende opsies oorweeg: selfgeskrewe failover, repmgr, AWS RDS, Patroni.
Selfgeskrewe skrifte
Hulle kan die werk van die meester monitor en, as dit misluk, die replika na die meester bevorder en die PgBouncer-konfigurasie opdateer.
Die voordele van hierdie benadering is maksimum eenvoud, want jy skryf self skrifte en verstaan presies hoe dit werk.
Nadele:
- Die meester het dalk nie gesterf nie, maar 'n netwerkfout het dalk plaasgevind. Failover, onbewus hiervan, sal die replika aan die meester bevorder, terwyl die ou meester sal aanhou werk. Gevolglik sal ons twee bedieners in die rol van meester kry en ons sal nie weet watter van hulle die nuutste bygewerkte data het nie. Hierdie situasie word ook gesplete brein genoem;
- Ons is sonder 'n antwoord gelaat. In ons konfigurasie, die meester en een replika, na oorskakeling, beweeg die replika op na die meester en ons het nie meer replikas nie, so ons moet 'n nuwe replika handmatig byvoeg;
- Ons het addisionele monitering van die failover-operasie nodig, terwyl ons 12 PostgreSQL-skerwe het, wat beteken dat ons 12 trosse moet monitor. Met 'n toename in die aantal skerwe, moet jy ook onthou om die failover op te dateer.
Selfgeskrewe failover lyk baie ingewikkeld en vereis nie-onbeduidende ondersteuning. Met 'n enkele PostgreSQL-kluster sou dit die maklikste opsie wees, maar dit skaal nie, so dit is nie geskik vir ons nie.
Repmgr
Replikasiebestuurder vir PostgreSQL-klusters, wat die werking van 'n PostgreSQL-kluster kan bestuur. Terselfdertyd het dit nie 'n outomatiese failover uit die boks nie, so vir werk sal jy jou eie "wrapper" moet skryf bo-op die voltooide oplossing. Alles kan dus selfs meer ingewikkeld uitdraai as met selfgeskrewe skrifte, so ons het nie eers Repmgr probeer nie.
AWS RDS
Ondersteun alles wat ons nodig het, weet hoe om rugsteun te maak en hou 'n poel verbindings in stand. Dit het outomatiese omskakeling: wanneer die meester sterf, word die replika die nuwe meester, en AWS verander die dns-rekord na die nuwe meester, terwyl die replikas in verskillende AZ'e geleë kan wees.
Die nadele sluit in die gebrek aan fyn aanpassings. As 'n voorbeeld van fyn instel: ons gevalle het beperkings vir tcp-verbindings, wat ongelukkig nie in RDS gedoen kan word nie:
net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3
Boonop is AWS RDS amper twee keer so duur as die gewone instansieprys, wat die hoofrede was om hierdie oplossing te laat vaar.
Patroni
Dit is 'n python-sjabloon vir die bestuur van PostgreSQL met goeie dokumentasie, outomatiese failover en bronkode op github.
Voordele van Patroni:
- Elke konfigurasieparameter word beskryf, dit is duidelik hoe dit werk;
- Outomatiese failover werk uit die boks;
- Geskryf in luislang, en aangesien ons self baie in luislang skryf, sal dit vir ons makliker wees om probleme te hanteer en miskien selfs die ontwikkeling van die projek te help;
- Bestuur PostgreSQL ten volle, laat jou toe om die konfigurasie op alle nodusse van die groep tegelyk te verander, en as die groep herbegin moet word om die nuwe konfigurasie toe te pas, kan dit weer gedoen word met Patroni.
Nadele:
- Dit is nie duidelik uit die dokumentasie hoe om korrek met PgBouncer te werk nie. Alhoewel dit moeilik is om dit 'n minus te noem, want Patroni se taak is om PostgreSQL te bestuur, en hoe verbindings met Patroni sal verloop, is reeds ons probleem;
- Daar is min voorbeelde van implementering van Patroni op groot volumes, terwyl daar baie voorbeelde van implementering van nuuts af is.
Gevolglik het ons Patroni gekies om 'n failover-kluster te skep.
Patroni-implementeringsproses
Voor Patroni het ons 12 PostgreSQL-skerwe gehad in 'n konfigurasie van een meester en een replika met asynchrone replikasie. Die toepassingsbedieners het toegang tot die databasisse verkry deur die Network Load Balancer, waaragter twee gevalle met PgBouncer was, en agter hulle was al die PostgreSQL-bedieners.
Om Patroni te implementeer, moes ons 'n verspreide bergingkluster-konfigurasie kies. Patroni werk met verspreide konfigurasiebergingstelsels soos ens, Zookeeper, Consul. Ons het net 'n volwaardige Consul-kluster op die mark, wat saam met Vault werk en ons gebruik dit nie meer nie. 'n Goeie rede om Consul vir sy beoogde doel te begin gebruik.
Hoe Patroni met Consul werk
Ons het 'n Konsul-kluster, wat uit drie nodusse bestaan, en 'n Patroni-kluster, wat bestaan uit 'n leier en 'n replika (in Patroni word die meester die trosleier genoem, en die slawe word replikas genoem). Elke geval van die Patroni-kluster stuur voortdurend inligting oor die toestand van die groep aan Consul. Daarom kan u altyd by Consul uitvind wat die huidige opset van die Patroni-kluster is en wie op die oomblik die leier is.
Om Patroni aan Consul te koppel, is dit genoeg om die amptelike dokumentasie te bestudeer, wat sê dat jy 'n gasheer in die http- of https-formaat moet spesifiseer, afhangende van hoe ons met Consul werk, en die verbindingskema, opsioneel:
host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to httpDit lyk eenvoudig, maar hier begin die slaggate. Met Consul werk ons oor 'n veilige verbinding via https en ons verbindingkonfigurasie sal soos volg lyk:
consul:
host: https://server.production.consul:8080
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}Maar dit werk nie. By opstart kan Patroni nie aan Consul koppel nie, want dit probeer in elk geval deur http gaan.
Die bronkode van Patroni het gehelp om die probleem te hanteer. Goed dat dit in luislang geskryf is. Dit blyk dat die gasheerparameter nie op enige manier ontleed word nie, en die protokol moet in skema gespesifiseer word. So lyk die werkkonfigurasieblok om met Consul vir ons te werk:
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}konsul-sjabloon
Dus, ons het die berging vir die konfigurasie gekies. Nou moet ons verstaan hoe PgBouncer sy konfigurasie sal verander wanneer die leier in die Patroni-kluster verander word. Daar is geen antwoord op hierdie vraag in die dokumentasie nie, want. daar word in beginsel nie werk met PgBouncer beskryf nie.
Op soek na 'n oplossing, het ons 'n artikel gevind (ek onthou ongelukkig nie die titel nie) waar geskryf is dat Сonsul-sjabloon baie gehelp het om PgBouncer en Patroni te koppel. Dit het ons aangespoor om te ondersoek hoe Consul-template werk.
Dit het geblyk dat Consul-template voortdurend die konfigurasie van die PostgreSQL-kluster in Consul monitor. Wanneer die leier verander, dateer dit die PgBouncer-konfigurasie op en stuur 'n opdrag om dit te herlaai.
'n Groot pluspunt van sjabloon is dat dit as kode gestoor word, dus wanneer 'n nuwe skerf bygevoeg word, is dit genoeg om 'n nuwe commit te maak en die sjabloon outomaties op te dateer, wat die Infrastruktuur as kode-beginsel ondersteun.
Nuwe argitektuur met Patroni
As gevolg hiervan het ons die volgende werkskema gekry:
Alle toepassingsbedieners kry toegang tot die balanseerder → daar is twee gevalle van PgBouncer daaragter → op elke instansie word Consul-sjabloon geloods, wat die status van elke Patroni-groepering monitor en die relevansie van die PgBouncer-konfigurasie monitor, wat versoeke na die huidige leier stuur van elke groep.
Handmatige toetsing
Ons het hierdie skema uitgevoer voordat dit op 'n klein toetsomgewing bekendgestel is en die werking van outomatiese skakeling nagegaan. Hulle het die bord oopgemaak, die plakker geskuif, en op daardie oomblik het hulle die leier van die groep “doodgemaak”. In AWS is dit so eenvoudig soos om die instansie via die konsole af te sluit.
Die plakker het binne 10-20 sekondes teruggekeer en toe weer normaal begin beweeg. Dit beteken dat die Patroni-kluster korrek gewerk het: dit het die leier verander, die inligting na Сonsul gestuur, en Сonsul-sjabloon het hierdie inligting dadelik opgetel, die PgBouncer-konfigurasie vervang en die opdrag gestuur om te herlaai.
Hoe om onder hoë las te oorleef en die stilstandtyd minimaal te hou?
Alles werk perfek! Maar daar is nuwe vrae: Hoe sal dit werk onder hoë las? Hoe om alles in produksie vinnig en veilig uit te rol?
Die toetsomgewing waarop ons vragtoetsing doen, help ons om die eerste vraag te beantwoord. Dit is heeltemal identies aan produksie in terme van argitektuur en het toetsdata gegenereer wat in volume ongeveer gelyk is aan produksie. Ons besluit om net een van die PostgreSQL-meesters te “doodmaak” tydens die toets en kyk wat gebeur. Maar voor dit is dit belangrik om die outomatiese rol na te gaan, want in hierdie omgewing het ons verskeie PostgreSQL-skerwe, so ons sal uitstekende toetsing van konfigurasieskrifte voor produksie kry.
Albei take lyk ambisieus, maar ons het PostgreSQL 9.6. Kan ons dadelik opgradeer na 11.2?
Ons besluit om dit in 2 stappe te doen: gradeer eers op na 11.2, begin dan Patroni.
PostgreSQL-opdatering
Gebruik die opsie om die PostgreSQL-weergawe vinnig op te dateer -k, waarin harde skakels op skyf geskep word en dit is nie nodig om jou data te kopieer nie. Op basis van 300-400 GB neem die opdatering 1 sekonde.
Ons het baie skerwe, so die opdatering moet outomaties gedoen word. Om dit te doen, het ons 'n Ansible-speelboek geskryf wat die hele opdateringsproses vir ons hanteer:
/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='Dit is belangrik om hier op te let dat u dit met die parameter moet uitvoer voordat u die opgradering begin --tjekom seker te maak jy kan opgradeer. Ons skrip maak ook die vervanging van konfigurasies vir die duur van die opgradering. Ons draaiboek is binne 30 sekondes voltooi, wat 'n uitstekende resultaat is.
Begin Patroni
Om die tweede probleem op te los, kyk net na die Patroni-konfigurasie. Die amptelike bewaarplek het 'n voorbeeldkonfigurasie met initdb, wat verantwoordelik is vir die inisiasie van 'n nuwe databasis wanneer u Patroni die eerste keer begin. Maar aangesien ons reeds 'n klaargemaakte databasis het, het ons eenvoudig hierdie afdeling uit die konfigurasie verwyder.
Toe ons Patroni op 'n reeds bestaande PostgreSQL-kluster begin installeer en dit laat loop, het ons 'n nuwe probleem ondervind: albei bedieners het as 'n leier begin. Patroni weet niks van die vroeë toestand van die groepering nie en probeer om beide bedieners as twee afsonderlike groepe met dieselfde naam te begin. Om hierdie probleem op te los, moet jy die gids met data oor die slaaf uitvee:
rm -rf /var/lib/postgresql/Dit moet net op die slaaf gedoen word!
Wanneer 'n skoon replika gekoppel is, maak Patroni 'n basisrugsteunleier en herstel dit na die replika, en haal dan die huidige toestand in volgens die muurlogboeke.
Nog 'n probleem wat ons teëgekom het, is dat alle PostgreSQL-klusters by verstek hoof genoem word. Wanneer elke groep niks van die ander weet nie, is dit normaal. Maar wanneer jy Patroni wil gebruik, moet alle trosse 'n unieke naam hê. Die oplossing is om die groepnaam in die PostgreSQL-konfigurasie te verander.
vrag toets
Ons het 'n toets van stapel gestuur wat gebruikerservaring op borde simuleer. Toe die vrag ons gemiddelde daaglikse waarde bereik het, het ons presies dieselfde toets herhaal, ons het een geval met die PostgreSQL-leier afgeskakel. Die outomatiese failover het gewerk soos ons verwag het: Patroni het die leier verander, Consul-template het die PgBouncer-konfigurasie opgedateer en 'n opdrag gestuur om te herlaai. Volgens ons grafieke in Grafana was dit duidelik dat daar vertragings van 20-30 sekondes is en 'n klein hoeveelheid foute van die bedieners wat verband hou met die verbinding met die databasis. Dit is 'n normale situasie, sulke waardes is aanvaarbaar vir ons failover en is beslis beter as die diensstilstand.
Patroni na produksie te bring
Gevolglik het ons met die volgende plan vorendag gekom:
- Ontplooi Consul-sjabloon na PgBouncer-bedieners en begin;
- PostgreSQL-opdaterings na weergawe 11.2;
- Verander die naam van die groepie;
- Begin die Patroni-groepering.
Terselfdertyd stel ons skema ons in staat om byna enige tyd die eerste punt te maak, ons kan elke PgBouncer om die beurt van die werk verwyder en konsul-sjabloon daarop ontplooi en uitvoer. So het ons gedoen.
Vir vinnige ontplooiing het ons Ansible gebruik, aangesien ons reeds al die speelboeke op 'n toetsomgewing getoets het, en die uitvoeringstyd van die volledige skrif was van 1,5 tot 2 minute vir elke skerf. Ons kan alles om die beurt na elke skerf uitrol sonder om ons diens te stop, maar ons sal elke PostgreSQL vir 'n paar minute moet afskakel. In hierdie geval kon gebruikers wie se data op hierdie skerf is nie tans ten volle werk nie, en dit is vir ons onaanvaarbaar.
Die uitweg uit hierdie situasie was die beplande instandhouding, wat elke 3 maande plaasvind. Dit is 'n venster vir geskeduleerde werk, wanneer ons ons diens heeltemal afskakel en ons databasisgevalle opgradeer. Daar was een week oor tot die volgende venster, en ons het besluit om net te wag en verder voor te berei. Gedurende die wagtyd het ons onsself boonop beveilig: vir elke PostgreSQL-skerf het ons 'n ekstra replika geskep in geval van versuim om die nuutste data te hou, en 'n nuwe instansie vir elke skerf bygevoeg, wat 'n nuwe replika in die Patroni-groepering moet word, om nie 'n opdrag uit te voer om data uit te vee nie. Dit alles het gehelp om die risiko van foute te verminder.
Ons het ons diens herbegin, alles het gewerk soos dit moes, gebruikers het aangehou werk, maar op die grafieke het ons 'n abnormaal hoë las op die Consul-bedieners opgemerk.
Hoekom het ons dit nie in die toetsomgewing gesien nie? Hierdie probleem illustreer baie goed dat dit nodig is om die Infrastruktuur as kode-beginsel te volg en die hele infrastruktuur te verfyn, van toetsomgewings tot produksie. Andersins is dit baie maklik om die probleem wat ons gekry het te kry. Wat het gebeur? Consul het eers op produksie verskyn, en toe op toetsomgewings, gevolglik op toetsomgewings was die weergawe van Consul hoër as op produksie. Net in een van die vrystellings is 'n SVE-lekkasie opgelos wanneer daar met konsul-sjabloon gewerk word. Daarom het ons Konsul eenvoudig opgedateer en sodoende die probleem opgelos.
Herbegin Patroni-groepering
Ons het egter 'n nuwe probleem gekry, wat ons nie eers vermoed het nie. Wanneer ons Consul opdateer, verwyder ons eenvoudig die Consul-nodus uit die groepering deur die konsul verlaat opdrag → Patroni koppel aan 'n ander Consul bediener → alles werk. Maar toe ons die laaste instansie van die Konsul-groepering bereik en die konsulverlofopdrag daarheen gestuur het, het alle Patroni-klusters eenvoudig weer begin, en in die logboeke het ons die volgende fout gesien:
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>Die Patroni-groepering kon nie inligting oor sy groepering ophaal nie en het weer begin.
Om 'n oplossing te vind, het ons die Patroni-outeurs gekontak via 'n probleem op github. Hulle het verbeterings aan ons konfigurasielêers voorgestel:
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8Ons kon die probleem op 'n toetsomgewing herhaal en hierdie opsies daar getoets, maar dit het ongelukkig nie gewerk nie.
Die probleem bly steeds onopgelos. Ons beplan om die volgende oplossings te probeer:
- Gebruik Consul-agent op elke Patroni-kluster-instansie;
- Los die probleem in die kode op.
Ons verstaan waar die fout plaasgevind het: die probleem is waarskynlik die gebruik van verstek-time-out, wat nie deur die konfigurasielêer oorheers word nie. Wanneer die laaste Consul-bediener uit die groep verwyder word, hang die hele Consul-kluster vir meer as 'n sekonde, as gevolg hiervan kan Patroni nie die status van die groep kry nie en herbegin die hele groep heeltemal.
Gelukkig het ons nie meer foute teëgekom nie.
Resultate van die gebruik van Patroni
Na die suksesvolle bekendstelling van Patroni het ons 'n bykomende replika in elke groep bygevoeg. Nou in elke groepering is daar 'n skyn van 'n kworum: een leier en twee replikas, vir veiligheidsnet in die geval van gesplete brein wanneer oorskakeling.
Patroni werk al meer as drie maande aan produksie. Gedurende hierdie tyd het hy reeds daarin geslaag om ons uit te help. Onlangs het die leier van een van die groepe in AWS gesterf, outomatiese failover het gewerk en gebruikers het voortgegaan om te werk. Patroni het sy hooftaak vervul.
'n Klein opsomming van die gebruik van Patroni:
- Gemak van konfigurasie veranderinge. Dit is genoeg om die konfigurasie op een instansie te verander en dit sal na die hele groep opgetrek word. As 'n herlaai nodig is om die nuwe konfigurasie toe te pas, sal Patroni jou laat weet. Patroni kan die hele groep herbegin met 'n enkele opdrag, wat ook baie gerieflik is.
- Outomatiese failover werk en het reeds daarin geslaag om ons te help.
- PostgreSQL-opdatering sonder stilstand van die toepassing. Jy moet eers die replikas opdateer na die nuwe weergawe, dan die leier in die Patroni-kluster verander en die ou leier opdateer. In hierdie geval vind die nodige toetsing van outomatiese failover plaas.
Bron: will.com