Yn it artikel sil ik jo fertelle hoe't wy it probleem fan PostgreSQL-fouttolerânsje benadere, wêrom it wichtich waard foar ús en wat der op it lêst barde.
Wy hawwe in tige laden tsjinst: 2,5 miljoen brûkers wrâldwiid, 50K+ aktive brûkers elke dei. De servers lizze yn Amazone yn ien regio fan Ierlân: 100+ ferskillende servers wurkje konstant, wêrfan hast 50 mei databases.
De hiele efterkant is in grutte monolityske stateful Java-applikaasje dy't in konstante websocket-ferbining hâldt mei de kliïnt. As ferskate brûkers tagelyk op itselde boerd wurkje, sjogge se allegear de wizigingen yn echte tiid, om't wy elke feroaring skriuwe yn 'e databank. Wy hawwe sawat 10K oanfragen per sekonde oan ús databases. By peak load yn Redis skriuwe wy 80-100K oanfragen per sekonde.
Wêrom wy oerstapten fan Redis nei PostgreSQL
Yn earste ynstânsje wurke ús tsjinst mei Redis, in winkel foar kaaiwearden dy't alle gegevens opslaat yn it RAM fan 'e server.
Foardielen fan Redis:
- Hege antwurd snelheid, omdat alles wurdt opslein yn it ûnthâld;
- Maklik fan backup en replikaasje.
Neidielen fan Redis foar ús:
- D'r binne gjin echte transaksjes. Wy besochten se te simulearjen op it nivo fan ús applikaasje. Spitigernôch wurke dit net altyd goed en fereasket it skriuwen fan heul komplekse koade.
- De hoemannichte gegevens wurdt beheind troch de hoemannichte ûnthâld. As de hoemannichte gegevens ferheget, sil it ûnthâld groeie, en, op it lêst, sille wy de skaaimerken fan 'e selekteare eksimplaar tsjinkomme, wat yn AWS fereasket om ús tsjinst te stopjen om it type eksimplaar te feroarjen.
- It is needsaaklik om konstant te behâlden in lege latency nivo, omdat. wy hawwe in hiel grut oantal oanfragen. It optimale fertragingsnivo foar ús is 17-20 ms. Op in nivo fan 30-40 ms krije wy lange antwurden op oanfragen fan ús applikaasje en degradaasje fan 'e tsjinst. Spitigernôch barde dit mei ús yn septimber 2018, doe't ien fan 'e gefallen mei Redis om ien of oare reden 2 kear mear latency krige dan normaal. Om it probleem op te lossen, stoppe wy de tsjinst middeis foar net-pland ûnderhâld en ferfongen de problematyske Redis-eksimplaar.
- It is maklik om gegevensynkonsistinsje te krijen, sels mei lytse flaters yn 'e koade en dan in protte tiid te besteegjen oan it skriuwen fan koade om dizze gegevens te korrigearjen.
Wy hawwe rekken hâlden mei de neidielen en realisearre dat wy moatte ferhúzje nei wat handiger, mei normale transaksjes en minder ôfhinklikens fan latency. Undersyk útfierd, in protte opsjes analysearre en keas foar PostgreSQL.
Wy binne al 1,5 jier nei in nije databank ferhuze en hawwe mar in lyts part fan de gegevens ferpleatst, dus no wurkje wy tagelyk mei Redis en PostgreSQL. Mear ynformaasje oer de stadia fan it ferpleatsen en wikseljen fan gegevens tusken databases is skreaun yn .
Doe't wy earst begûnen te ferpleatsen, wurke ús applikaasje direkt mei de databank en tagong ta de master Redis en PostgreSQL. It PostgreSQL-kluster bestie út in master en in replika mei asynchrone replikaasje. Dit is hoe't it databankskema der útseach:
Implementearje PgBouncer
Wylst wy ferhúzje, waard it produkt ek ûntwikkele: it oantal brûkers en it oantal servers dat wurke mei PostgreSQL tanommen, en wy begûnen ferbinings te ûntbrekken. PostgreSQL makket in apart proses foar elke ferbining en verbruikt boarnen. Jo kinne it oantal ferbiningen ferheegje oant in bepaald punt, oars is d'r in kâns om suboptimale databankprestaasjes te krijen. De ideale opsje yn sa'n situaasje soe wêze om in ferbiningsbehearder te kiezen dy't foar de basis sil stean.
Wy hiene twa opsjes foar de ferbiningsbehearder: Pgpool en PgBouncer. Mar de earste stipet de transaksjemodus fan wurkjen mei de databank net, dus wy hawwe PgBouncer keazen.
Wy hawwe it folgjende wurkskema ynsteld: ús applikaasje hat tagong ta ien PgBouncer, wêrefter PostgreSQL-masters binne, en efter elke master is ien replika mei asynchrone replikaasje.
Tagelyk koenen wy net de folsleine hoemannichte gegevens yn PostgreSQL opslaan en de snelheid fan wurkjen mei de databank wie wichtich foar ús, dus wy begûnen PostgreSQL te sjitten op it applikaasjenivo. It hjirboppe beskreaune skema is hjir relatyf handich foar: by it tafoegjen fan in nije PostgreSQL-shard is it genôch om de PgBouncer-konfiguraasje te aktualisearjen en de applikaasje kin fuortendaliks wurkje mei de nije shard.
PgBouncer failover
Dit skema wurke oant it momint dat de ienige PgBouncer-eksimplaar stoar. Wy binne yn AWS, wêr't alle eksimplaren rinne op hardware dy't periodyk stjert. Yn sokke gefallen ferpleatst it eksimplaar gewoan nei nije hardware en wurket it wer. Dit barde mei PgBouncer, mar it waard net beskikber. It resultaat fan dizze hjerst wie de ûnbeskikberens fan ús tsjinst foar 25 minuten. AWS advisearret it brûken fan oerstalligens oan brûkersside foar sokke situaasjes, dy't op dat stuit net yn ús lân ymplementearre waard.
Dêrnei hawwe wy serieus neitocht oer de fouttolerânsje fan PgBouncer- en PostgreSQL-klusters, om't in ferlykbere situaasje koe barre mei elke eksimplaar yn ús AWS-akkount.
Wy bouden it PgBouncer-fouttolerânsjeskema as folget: alle applikaasjeservers hawwe tagong ta de Network Load Balancer, wêrefter d'r twa PgBouncers binne. Elke PgBouncer sjocht nei deselde PostgreSQL-master fan elke shard. As in AWS-eksimplaar-crash wer opkomt, wurdt alle ferkear omlaat fia in oare PgBouncer. Netwurk Load Balancer failover wurdt fersoarge troch AWS.
Dit skema makket it maklik om nije PgBouncer-tsjinners ta te foegjen.
Meitsje in PostgreSQL Failover Cluster
By it oplossen fan dit probleem hawwe wy ferskate opsjes beskôge: selsskreaune failover, repmgr, AWS RDS, Patroni.
Sels skreaune skripts
Se kinne it wurk fan 'e master kontrolearje en, as it mislearret, de replika oan' e master befoarderje en de PgBouncer-konfiguraasje bywurkje.
De foardielen fan dizze oanpak binne maksimale ienfâld, om't jo sels skripts skriuwe en krekt begripe hoe't se wurkje.
Cons:
- De master is miskien net ferstoarn, ynstee kin der in netwurkflater west hawwe. Failover, net bewust fan dit, sil befoarderje de replika oan de master, wylst de âlde master sil fierder wurkje. As gefolch krije wy twa servers yn 'e rol fan master en wy sille net witte wa fan har de lêste aktuele gegevens hat. Dizze situaasje wurdt ek wol split-brain neamd;
- Wy bleauwen sûnder in reaksje. Yn ús konfiguraasje, de master en ien replika, nei it wikseljen, ferpleatst de replika nei de master en wy hawwe gjin replika's mear, dus moatte wy in nije replika manuell tafoegje;
- Wy hawwe ekstra tafersjoch nedich fan 'e failover-operaasje, wylst wy 12 PostgreSQL-shards hawwe, wat betsjut dat wy 12-klusters kontrolearje moatte. Mei in tanimming fan it oantal shards, moatte jo ek ûnthâlde om de failover te aktualisearjen.
Sels skreaune failover sjocht heul yngewikkeld en fereasket net-triviale stipe. Mei ien PostgreSQL-kluster soe dit de maklikste opsje wêze, mar it skaalet net, dus it is net geskikt foar ús.
Repmgr
Replikaasjebehearder foar PostgreSQL-klusters, dy't de wurking fan in PostgreSQL-kluster kinne beheare. Tagelyk hat it gjin automatyske failover út 'e doaze, dus foar wurk sille jo jo eigen "wrapper" moatte skriuwe boppe op 'e ôfmakke oplossing. Alles kin dus noch yngewikkelder wurde as mei selsskreaune skripts, dus wy hawwe Repmgr net iens besocht.
AWS RDS
Unterstützt alles wat wy nedich binne, wit hoe't jo backups meitsje en ûnderhâldt in pool fan ferbiningen. It hat automatysk wikseljen: as de master stjert, wurdt de replika de nije master, en AWS feroaret it dns-record nei de nije master, wylst de replika's yn ferskate AZ's kinne lizze.
De neidielen binne ûnder oaren it gebrek oan boete oanpassingen. As foarbyld fan fine tuning: ús eksimplaren hawwe beheiningen foar tcp-ferbiningen, dy't spitigernôch net dien wurde kinne yn RDS:
net.ipv4.tcp_keepalive_time=10
net.ipv4.tcp_keepalive_intvl=1
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=3
Derneist is AWS RDS hast twa kear sa djoer as de reguliere eksimplaarpriis, wat de wichtichste reden wie foar it ferlitten fan dizze oplossing.
Patroni
Dit is in python-sjabloan foar it behearen fan PostgreSQL mei goede dokumintaasje, automatyske failover en boarnekoade op github.
Foardielen fan Patroni:
- Eltse konfiguraasje parameter wurdt beskreaun, it is dúdlik hoe't it wurket;
- Automatyske failover wurket út 'e doaze;
- Skreaun yn python, en om't wy sels in protte yn python skriuwe, sil it makliker wêze foar ús om te gean mei problemen en, miskien, sels helpe by de ûntwikkeling fan it projekt;
- Folslein beheart PostgreSQL, kinne jo de konfiguraasje op alle knopen fan it kluster tagelyk feroarje, en as it kluster opnij starte moat om de nije konfiguraasje oan te passen, dan kin dit opnij dien wurde mei Patroni.
Cons:
- It is net dúdlik út 'e dokumintaasje hoe't jo goed wurkje mei PgBouncer. Hoewol it dreech is om it in minus te neamen, om't Patroni's taak is om PostgreSQL te behearjen, en hoe't ferbiningen mei Patroni sille gean is al ús probleem;
- D'r binne in pear foarbylden fan ymplemintaasje fan Patroni op grutte folumes, wylst d'r in protte foarbylden binne fan ymplemintaasje fanôf it begjin.
As gefolch hawwe wy Patroni keazen om in failover-kluster te meitsjen.
Patroni ymplemintaasjeproses
Foar Patroni hienen wy 12 PostgreSQL-shards yn in konfiguraasje fan ien master en ien replika mei asynchrone replikaasje. De applikaasje-tsjinners hawwe tagong ta de databases fia de Network Load Balancer, wêrefter twa eksimplaren wiene mei PgBouncer, en efter har wiene alle PostgreSQL-tsjinners.
Om Patroni út te fieren, moasten wy in konfiguraasje foar ferspraat opslachkluster selektearje. Patroni wurket mei ferspraat konfiguraasje opslach systemen lykas etcd, Zookeeper, Consul. Wy hawwe gewoan in folweardich Consul-kluster op 'e merk, dy't wurket yn gearhing mei Vault en wy brûke it net mear. In geweldige reden om Consul te begjinnen foar it bedoelde doel.
Hoe Patroni wurket mei Consul
Wy hawwe in Consul-kluster, dat bestiet út trije knopen, en in Patroni-kluster, dat bestiet út in lieder en in replika (yn Patroni wurdt de master de klusterlieder neamd, en de slaven wurde replika's neamd). Elk eksimplaar fan it Patroni-kluster stjoert konstant ynformaasje oer de steat fan it kluster nei Consul. Dêrom kinne jo fan Consul altyd de hjoeddeistige konfiguraasje fan 'e Patroni-kluster fine en wa't op it stuit de lieder is.
Om Patroni te ferbinen mei Consul, is it genôch om de offisjele dokumintaasje te studearjen, dy't seit dat jo in host moatte opjaan yn it http- of https-formaat, ôfhinklik fan hoe't wy wurkje mei Consul, en it ferbiningskema, opsjoneel:
host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to httpIt liket ienfâldich, mar hjir begjinne de falkûlen. Mei Consul wurkje wy oer in feilige ferbining fia https en ús ferbiningskonfiguraasje sil der sa útsjen:
consul:
host: https://server.production.consul:8080
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}Mar dat slagget net. By it opstarten kin Patroni net ferbine mei Consul, om't it dochs besiket troch http te gean.
De boarnekoade fan Patroni holp it probleem te behanneljen. Goed dat it yn python skreaun is. It docht bliken dat de hostparameter op gjin inkelde manier wurdt parseard, en it protokol moat yn skema oantsjutte wurde. Dit is hoe't it wurkkonfiguraasjeblok foar wurkjen mei Consul der foar ús útsjocht:
consul:
host: server.production.consul:8080
scheme: https
verify: true
cacert: {{ consul_cacert }}
cert: {{ consul_cert }}
key: {{ consul_key }}konsul-sjabloan
Dat, wy hawwe de opslach foar de konfiguraasje keazen. No moatte wy begripe hoe't PgBouncer syn konfiguraasje sil wikselje by it feroarjen fan de lieder yn it Patroni-kluster. D'r is gjin antwurd op dizze fraach yn 'e dokumintaasje, om't. dêr, yn prinsipe, wurkje mei PgBouncer wurdt net beskreaun.
Op syk nei in oplossing fûnen wy in artikel (ik ûnthâlde de titel spitigernôch net) wêr't skreaun waard dat Сonsul-sjabloan in protte holp by it parearjen fan PgBouncer en Patroni. Dit hat ús frege om te ûndersykjen hoe't Consul-template wurket.
It die bliken dat Consul-sjabloan konstant de konfiguraasje fan it PostgreSQL-kluster yn Consul kontrolearret. As de lieder feroaret, fernijt it de PgBouncer-konfiguraasje en stjoert in kommando om it opnij te laden.
In grut plus fan sjabloan is dat it wurdt opslein as koade, dus as jo in nije shard tafoegje, is it genôch om in nije commit te meitsjen en it sjabloan automatysk te aktualisearjen, it stypjen fan it Ynfrastruktuer as koadeprinsipe.
Nije arsjitektuer mei Patroni
As gefolch hawwe wy it folgjende wurkskema krigen:
Alle applikaasje-tsjinners krije tagong ta de balancer → d'r binne twa eksimplaren fan PgBouncer efter it → op elke eksimplaar wurdt Consul-sjabloan lansearre, dy't de status fan elke Patroni-kluster kontrolearret en de relevânsje fan 'e PgBouncer-konfiguraasje kontrolearret, dy't fersiken stjoert nei de hjoeddeistige lieder fan elk kluster.
Hânlieding testen
Wy rûnen dit skema foar it lansearjen fan it op in lytse testomjouwing en kontroleare de wurking fan automatyske skeakeljen. Se iepene it boerd, ferhuze de sticker, en op dat stuit "fermoarde" se de lieder fan 'e kluster. Yn AWS is dit sa ienfâldich as it eksimplaar ôfslute fia de konsole.
De sticker kaam werom binnen 10-20 sekonden, en begon doe wer normaal te bewegen. Dit betsjut dat it Patroni-kluster goed wurke: it feroare de lieder, stjoerde de ynformaasje nei Сonsul, en Сonsul-sjabloan pakte dizze ynformaasje fuortendaliks op, ferfong de PgBouncer-konfiguraasje en stjoerde it kommando om opnij te laden.
Hoe oerlibje ûnder hege lading en hâld de downtime minimaal?
Alles wurket perfekt! Mar d'r binne nije fragen: Hoe sil it wurkje ûnder hege lading? Hoe fluch en feilich alles yn produksje útrolje?
De testomjouwing wêrop wy loadtesten útfiere helpt ús de earste fraach te beantwurdzjen. It is folslein identyk oan produksje yn termen fan arsjitektuer en hat testgegevens generearre dy't yn folume sawat gelyk binne oan produksje. Wy beslute om gewoan ien fan 'e PostgreSQL-masters te "deadzjen" tidens de test en te sjen wat der bart. Mar dêrfoar is it wichtich om de automatyske rolling te kontrolearjen, om't wy yn dizze omjouwing ferskate PostgreSQL-shards hawwe, sadat wy poerbêste testen krije fan konfiguraasjeskripts foar produksje.
Beide taken sjogge ambisjeus, mar wy hawwe PostgreSQL 9.6. Kinne wy fuortendaliks upgrade nei 11.2?
Wy beslute om it yn 2 stappen te dwaan: earst upgrade nei 11.2, lansearje dan Patroni.
PostgreSQL update
Brûk de opsje om de PostgreSQL-ferzje fluch te aktualisearjen -k, wêryn hurde keppelings wurde oanmakke op skiif en it is net nedich om jo gegevens te kopiearjen. Op basis fan 300-400 GB nimt de fernijing 1 sekonde.
Wy hawwe in protte shards, dus de fernijing moat automatysk dien wurde. Om dit te dwaan, hawwe wy in Ansible-spielboek skreaun dat it heule fernijingsproses foar ús behannelet:
/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='It is hjir wichtich om te notearjen dat foardat jo de upgrade begjinne, jo it moatte útfiere mei de parameter --kontrôleom te soargjen dat jo kinne opwurdearje. Us skript makket ek de ferfanging fan konfiguraasjes foar de doer fan 'e upgrade. Us skript foltôge yn 30 sekonden, dat is in poerbêst resultaat.
Launch Patroni
Om it twadde probleem op te lossen, sjoch gewoan nei de Patroni-konfiguraasje. It offisjele repository hat in foarbyldkonfiguraasje mei initdb, dy't ferantwurdlik is foar it inisjalisearjen fan in nije databank as jo Patroni earst begjinne. Mar om't wy al in klearmakke databank hawwe, hawwe wy dizze seksje gewoan út 'e konfiguraasje fuortsmiten.
Doe't wy Patroni begon te ynstallearjen op in al besteande PostgreSQL-kluster en it útfiere, rûnen wy yn in nij probleem: beide servers begon as lieder. Patroni wit neat oer de iere steat fan it kluster en besiket beide tsjinners te begjinnen as twa aparte klusters mei deselde namme. Om dit probleem op te lossen, moatte jo de map mei gegevens oer de slaaf wiskje:
rm -rf /var/lib/postgresql/Dit moat allinich op 'e slaaf dien wurde!
As in skjinne replika is ferbûn, makket Patroni in basebackup-lieder en herstelt it nei de replika, en komt dan yn mei de hjoeddeistige steat neffens de wallogs.
In oare swierrichheid dy't wy tsjinkamen is dat alle PostgreSQL-klusters standert haad wurde neamd. As elk kluster neat oer de oare wit, is dit normaal. Mar as jo Patroni brûke wolle, dan moatte alle klusters in unike namme hawwe. De oplossing is om de klusternamme te feroarjen yn 'e PostgreSQL-konfiguraasje.
load test
Wy hawwe in test lansearre dy't brûkersûnderfining simulearret op boards. Doe't de lading ús gemiddelde deistige wearde berikte, werhelle wy krekt deselde test, wy hawwe ien eksimplaar útskeakele mei de PostgreSQL-lieder. De automatyske failover wurke lykas wy ferwachte: Patroni feroare de lieder, Consul-sjabloan bywurke de PgBouncer-konfiguraasje en stjoerde in kommando om opnij te laden. Neffens ús grafiken yn Grafana wie it dúdlik dat d'r fertragingen binne fan 20-30 sekonden en in lyts bedrach fan flaters fan 'e servers dy't ferbûn binne mei de ferbining mei de databank. Dit is in normale situaasje, sokke wearden binne akseptabel foar ús failover en binne perfoarst better dan de tsjinstferliening.
Patroni nei produksje bringe
As gefolch hawwe wy it folgjende plan betocht:
- Ynsette Consul-sjabloan nei PgBouncer-tsjinners en lansearje;
- PostgreSQL-updates nei ferzje 11.2;
- Feroarje de namme fan it kluster;
- Begjinne de Patroni Cluster.
Tagelyk lit ús skema ús it earste punt hast op elk momint meitsje, wy kinne elke PgBouncer op syn beurt út it wurk ferwiderje en konsul-sjabloan derop ynsette en útfiere. Dat diene wy.
Foar flugge ynset brûkten wy Ansible, om't wy alle playbooks al hifke hawwe op in testomjouwing, en de útfieringstiid fan it folsleine skript wie fan 1,5 oant 2 minuten foar elke shard. Wy koenen alles op beurt útrolje nei elke shard sûnder ús tsjinst te stopjen, mar wy soene elke PostgreSQL ferskate minuten moatte útsette. Yn dit gefal kinne brûkers waans gegevens op dizze shard binne op dit stuit net folslein wurkje, en dit is foar ús net akseptabel.
De útwei út dizze situaasje wie it plande ûnderhâld, dat elke 3 moannen plakfynt. Dit is in finster foar pland wurk, as wy ús tsjinst folslein ôfslute en ús database-eksimplaren opwurdearje. Der wie ien wike oer oant it folgjende finster, en wy besletten gewoan te wachtsjen en fierder te tarieden. Yn 'e wachttiid hawwe wy ússels ek befeilige: foar elke PostgreSQL-shard hawwe wy in reservekopy opbrocht yn gefal fan it mislearjen fan de lêste gegevens, en in nije eksimplaar tafoege foar elke shard, dy't in nije replika wurde moat yn it Patroni-kluster, om gjin kommando út te fieren om gegevens te wiskjen. Dit alles holp om it risiko fan flater te minimalisearjen.
Wy hawwe ús tsjinst opnij starte, alles wurke sa't it moast, brûkers bleaunen wurkje, mar op 'e grafiken hawwe wy in abnormaal hege lading op' e Consul-tsjinners opmurken.
Wêrom hawwe wy dit net sjoen yn 'e testomjouwing? Dit probleem yllustrearret hiel goed dat it needsaaklik is om it Ynfrastruktuer as koadeprinsipe te folgjen en de heule ynfrastruktuer te ferfine, fan testomjouwings oant produksje. Oars is it heul maklik om it probleem te krijen dat wy krigen. Wat is bard? Consul ferskynde earst op produksje, en dan op testomjouwings, as gefolch, op testomjouwings, wie de ferzje fan Consul heger as op produksje. Krekt yn ien fan 'e releases waard in CPU-lek oplost by it wurkjen mei konsul-sjabloan. Dêrom hawwe wy Consul gewoan bywurke, sadat it probleem oplost.
Restart Patroni kluster
Wy krigen lykwols in nij probleem, dat wy net iens fertochten. By it bywurkjen fan Consul, ferwiderje wy gewoan de Consul-knooppunt út it kluster mei it kommando consul leave → Patroni ferbynt mei in oare Consul-tsjinner → alles wurket. Mar doe't wy it lêste eksimplaar fan 'e Consul-kluster berikten en it konsul-ferlofkommando nei it stjoerden, waarden alle Patroni-klusters gewoan opnij starte, en yn 'e logs seagen wy de folgjende flater:
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>It Patroni-kluster koe gjin ynformaasje oer syn kluster ophelje en is opnij starte.
Om in oplossing te finen, hawwe wy kontakt opnommen mei de Patroni-auteurs fia in probleem op github. Se stelden ferbetterings foar oan ús konfiguraasjebestannen:
consul:
consul.checks: []
bootstrap:
dcs:
retry_timeout: 8Wy wienen by steat om te replicate it probleem op in test omjouwing en hifke dizze opsjes dêr, mar spitigernôch se wurken net.
It probleem bliuwt noch net oplost. Wy binne fan plan de folgjende oplossingen te besykjen:
- Brûk Consul-agent op elke Patroni-kluster-eksimplaar;
- Reparearje it probleem yn 'e koade.
Wy begripe wêr't de flater barde: it probleem is wierskynlik it brûken fan standert timeout, dy't net oerskreaun wurdt troch it konfiguraasjetriem. As de lêste Consul-tsjinner út it kluster fuorthelle wurdt, hinget it hiele Consul-kluster mear as in sekonde, hjirtroch kin Patroni de status fan it kluster net krije en it hiele kluster folslein opnij starte.
Gelokkich binne wy gjin flaters mear tsjinkommen.
Resultaten fan it brûken fan Patroni
Nei de suksesfolle lansearring fan Patroni hawwe wy in ekstra replika tafoege yn elk kluster. No yn elke kluster is d'r in skyn fan in kworum: ien lieder en twa replika's, foar feiligensnet yn gefal fan split-brain by it wikseljen.
Patroni hat mear as trije moannen wurke oan produksje. Yn dizze tiid is it him al slagge om ús te helpen. Koartlyn stoar de lieder fan ien fan 'e klusters yn AWS, automatyske failover wurke en brûkers bleaunen wurkje. Patroni ferfolle syn wichtichste taak.
In lytse gearfetting fan it gebrûk fan Patroni:
- Gemak fan konfiguraasje feroarings. It is genôch om de konfiguraasje op ien eksimplaar te feroarjen en it sil nei it heule kluster wurde lutsen. As in herstart nedich is om de nije konfiguraasje oan te passen, dan sil Patroni jo witte. Patroni kin it heule kluster opnij starte mei ien kommando, wat ek heul handich is.
- Automatyske failover wurket en is al slagge om ús te helpen.
- PostgreSQL update sûnder applikaasje downtime. Jo moatte earst de replika's bywurkje nei de nije ferzje, dan de lieder yn it Patroni-kluster feroarje en de âlde lieder bywurkje. Yn dit gefal bart de nedige testen fan automatyske failover.
Boarne: www.habr.com