PostgreSQL + Patroni-ko hutsegiteko klusterra. Ezarpen esperientzia

Artikulu honetan PostgreSQL akatsen tolerantziaren gaiari nola heldu diogun kontatuko dizuet, zergatik bihurtu zen garrantzitsua guretzat eta zer gertatu zen azkenean.

Oso kargatutako zerbitzua dugu: 2,5 milioi erabiltzaile mundu osoan, 50K+ erabiltzaile aktibo egunero. Zerbitzariak Amazonen daude Irlandako eskualde batean: 100+ zerbitzari desberdin daude etengabe lanean, horietako ia 50 datu-baseekin.

Backend osoa Java aplikazio monolitiko handi bat da, bezeroarekin websocket konexio iraunkorra mantentzen duena. Hainbat erabiltzailek aldi berean arbel berean lan egiten dutenean, guztiek denbora errealean ikusten dituzte aldaketak, datu-basean aldaketa guztiak erregistratzen baititugu. Gutxi gorabehera 10K eskaera ditugu segundoko gure datu-baseetan. Redis-en karga gorenean 80-100K eskaera idazten ditugu segundoko.

Zergatik aldatu ginen Redistik PostgreSQLra

Hasieran, gure zerbitzuak Redis-ekin funtzionatzen zuen, zerbitzariaren RAM-an datu guztiak gordetzen dituen gako-balioen biltegiarekin.

Redis-en abantailak:

1. Erantzun abiadura handia, zeren dena memorian gordetzen da;
2. Babeskopia eta erreplika erosoa.

Redis-en alde txarrak guretzat:

1. Ez dago benetako transakziorik. Gure aplikazio mailan horiek imitatzen saiatu gara. Zoritxarrez, honek ez zuen beti ondo funtzionatu eta kode oso konplexua idaztea eskatzen zuen.
2. Datu kopurua memoria kopuruaren arabera mugatzen da. Datu kopurua handitu ahala, memoria hazi egingo da, eta, azkenean, aukeratutako instantziaren ezaugarriekin topo egingo dugu, AWSn gure zerbitzua geldiaraztea eskatzen baitu instantzia mota aldatzeko.
3. Beharrezkoa da etengabe latentzia maila baxua mantentzea, zeren Eskaera kopuru oso handia dugu. Guretzat latentzia maila optimoa 17-20 ms-koa da. 30-40 ms-ko mailan, erantzun luzeak lortzen ditugu gure aplikazioen eskaerei eta zerbitzuaren degradazioari. Zoritxarrez, 2018ko irailean gertatu zitzaigun, arrazoiren batengatik Redis-ekin izandako instantzia batek ohikoa baino 2 aldiz handiagoa zen latentzia jaso zuenean. Arazoa konpontzeko, zerbitzua eten genuen lanegunaren erdian programatu gabeko mantentze-lanetarako eta Redis instantzia arazotsua ordezkatu genuen.
4. Erraza da koherentziarik gabeko datuak lortzea kodean akats txikiak izan arren eta gero denbora asko pasatzea kodea idazten datu horiek konpontzeko.

Desabantailak kontuan hartu genituen eta konturatu ginen zerbait erosoago batera joan behar genuela, transakzio normalekin eta latentziaren menpekotasun gutxiagorekin. Gure ikerketa egin genuen, aukera asko aztertu eta PostgreSQL aukeratu genuen.

Orain 1,5 urte daramatzagu datu-base berri batera mugitzen eta datuen zati txiki bat bakarrik transferitu dugu, beraz, orain Redis eta PostgreSQL-ekin batera ari gara lanean. Datu-baseen artean datuak mugitzeko eta aldatzeko faseei buruzko informazio gehiago idatzita dago nire lankidearen artikulua.

Mugitzen hasi ginenean, gure aplikazioak datu-basearekin zuzenean lan egiten zuen eta Redis eta PostgreSQL maisuan sartu zen. PostgreSQL klusterrak erreplika asinkronoa zuen maisu eta erreplika batez osatuta zegoen. Hau da datu-basearen lan-fluxuaren itxura:

PgBouncer ezartzea

Mugitzen ginela, produktua ere garatzen ari zen: PostgreSQLrekin lan egiten zuten erabiltzaile eta zerbitzarien kopurua handitu zen, eta konexiorik gabe geratzen hasi ginen. PostgreSQL-k konexio bakoitzerako prozesu bereizi bat sortzen du eta baliabideak kontsumitzen ditu. Konexio kopurua handitu dezakezu puntu jakin batera arte, bestela datu-baseak ezin hobeto funtzionatzeko aukera dago. Egoera horretan aukera aproposa datu-basearen aurrean egongo den konexio-kudeatzailea hautatzea izango litzateke.

Konexio-kudeatzailerako bi aukera genituen: Pgpool eta PgBouncer. Baina lehenengoak ez du datu-basearekin lan egiteko modu transakzionala onartzen, beraz, PgBouncer aukeratu dugu.

Lan-eskema hau konfiguratu dugu: gure aplikazioak PgBouncer batera sartzen da, horren atzean PostgreSQL maisuak daude, eta maisu bakoitzaren atzean erreplika asinkronoa duen erreplika bat dago.


Aldi berean, ezin izan genuen datu kopuru osoa PostgreSQL-n gorde eta datu-basearekin lan egiteko abiadura garrantzitsua zen guretzat, beraz, PostgreSQL zatikatzen hasi ginen aplikazio mailan. Goian azaldutako eskema nahiko erosoa da horretarako: PostgreSQL zati berri bat gehitzean, nahikoa da PgBouncer konfigurazioa eguneratzea eta aplikazioak berehala lan egin dezake zati berriarekin.

PgBouncer akatsen tolerantzia

Eskema honek funtzionatu zuen PgBouncer instantzia bakarra hil zen arte. AWSn gaude, non instantzia guztiak aldizka hiltzen den hardwarean abiarazten diren. Kasu horietan, instantzia hardware berri batera mugitzen da eta berriro funtzionatzen du. PgBouncer-ekin gertatu zen, baina ez zegoen erabilgarri. Istripu honen emaitza izan zen gure zerbitzua 25 minutuz erabilgarri egon ez zela. Horrelako egoeretarako, AWS-k gomendatzen du erredundantzia erabiltzea erabiltzailearen aldetik, garai hartan ezarri ez genuena.

Horren ostean, serioski pentsatu genuen PgBouncer eta PostgreSQL klusterren akatsen tolerantziaz, antzeko egoera bat berriro gerta zitekeelako gure AWS kontuko edozein instantziarekin.

PgBouncer akatsen tolerantzia-eskema honela eraiki dugu: aplikazio-zerbitzari guztiek Sareko karga-balantzara sartzen dute, eta horren atzean bi PgBouncer daude. PgBouncers bakoitzak zati bakoitzaren PostgreSQL maisu berari begiratzen dio. AWS instantziako hutsegite baten egoera errepikatzen bada, trafiko guztia beste PgBouncer baten bidez birbideratzen da. Network Load Balancer akatsen tolerantzia AWS-k eskaintzen du.

Eskema honek PgBouncer zerbitzari berriak erraz gehi ditzakezu.

PostgreSQL Failover Kluster bat sortzea

Arazo hau konpontzerakoan, aukera desberdinak kontuan hartu ditugu: auto-idatzitako hutsegitea, repmgr, AWS RDS, Patroni.

Norberak idatzitako gidoiak

Maisuaren lana kontrolatu dezakete eta, huts egiten badu, erreplika nagusira sustatu eta PgBouncer konfigurazioa eguneratu.

Ikuspegi honen abantailak sinpletasun handiena dira, gidoiak zuk zeuk idazten dituzulako eta nola funtzionatzen duten zehatz-mehatz ulertzen duzulako.

Cons:

• Baliteke maisua ez hiltzea; horren ordez, sarearen hutsegite bat egon liteke. Failover-ek, hori jakin gabe, erreplika sustatuko du maisuari, eta maisu zaharrak lanean jarraituko du. Ondorioz, bi zerbitzari lortuko ditugu maisu rolean eta ez dugu jakingo zeinek dituen uneko azken datua. Egoera honi split-brain ere esaten zaio;
• Erantzunik gabe geratu ginen. Gure konfigurazioan maisu bat eta erreplika bat daude, aldatu ondoren erreplika maisura sustatzen da eta jada ez dugu erreplikarik, beraz, eskuz erreplika berri bat gehitu behar dugu;
• Hutsegiteko eragiketaren jarraipen gehigarria behar dugu, eta 12 PostgreSQL zati ditugu, hau da, 12 kluster kontrolatu behar ditugu. Zati kopurua handitzean, hutsegitea eguneratzea ere gogoratu behar duzu.

Norberak idatzitako hutsegite batek oso konplikatua dirudi eta laguntza hutsala behar du. PostgreSQL kluster batekin, hau izango da aukerarik errazena, baina ez da eskalatzen, beraz, ez da guretzat egokia.

Errepgr

PostgreSQL klusterren erreplika-kudeatzailea, PostgreSQL kluster baten funtzionamendua kudea dezakeena. Aldi berean, ez du hutsegite automatikorik kutxatik kanpo, beraz, lan egiteko prest dagoen irtenbidearen gainean zure "bilgarri" idatzi beharko duzu. Beraz, dena are konplikatuagoa izan daiteke norberak idatzitako gidoiekin baino, horregatik ez genuen Repmgr probatu ere egin.

AWS RDS

Behar dugun guztia onartzen du, babeskopiak egin ditzake eta konexio multzo bat onartzen du. Aldaketa automatikoa du: maisua hiltzen denean, erreplika maisu berri bihurtzen da, eta AWS-k DNS erregistroa maisu berrira aldatzen du, erreplikak AZ ezberdinetan egon daitezkeen bitartean.

Desabantailen artean ezarpen finak ez egotea dago. Sintonizazioaren adibide gisa: gure instantziek tcp konexioetarako murrizketak dituzte, eta, zoritxarrez, ezin dira RDSn egin:

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

Horrez gain, AWS RDS instantzia arruntaren prezioa baino ia bi aldiz garestiagoa da, hori izan zen irtenbide hau bertan behera uzteko arrazoi nagusia.

Patroni

PostgreSQL kudeatzeko python txantiloia da, dokumentazio onarekin, hutsegite automatikoarekin eta github-en iturburu kodearekin.

Patroniren abantailak:

• Konfigurazio-parametro bakoitza deskribatzen da, argi dago nola funtzionatzen duen;
• Porrot automatikoak kutxatik kanpo funtzionatzen du;
• Pythonez idatzita, eta guk geuk pithonez asko idazten dugunez, errazagoa izango zaigu arazoei aurre egitea eta, agian, proiektuaren garapenean laguntzea ere;
• PostgreSQL guztiz kontrolatzen du, klusterreko nodo guztietan konfigurazioa aldi berean aldatzeko aukera ematen du, eta konfigurazio berria aplikatzeak klusterraren berrabiarazi behar badu, Patroni erabiliz berriro egin daiteke.

Cons:

• Dokumentazioan ez dago argi nola funtzionatu behar den PgBouncer-ekin. Honi ken deitzea zaila den arren, Patroniren zeregina PostgreSQL kudeatzea baita, eta Patroni-rekin konexioak nola funtzionatuko duten dagoeneko gure arazoa da;
• Eskala handian Patroni inplementazioaren adibide gutxi daude, eta hutsetik inplementatzeko adibide asko daude.

Ondorioz, Patroni aukeratu genuen hutsegite-kluster bat sortzeko.

Patroni ezarpen-prozesua

Patroni baino lehen, 12 PostgreSQL zati genituen maisu eta erreplika konfigurazio batean erreplikazio asinkronoarekin. Aplikazio-zerbitzariak sareko karga-balantzaile baten bidez sartzen ziren datu-baseetara, eta horren atzean bi instantzia zeuden PgBouncerrekin, eta horien atzean PostgreSQL zerbitzari guztiak zeuden.


Patroni ezartzeko, banatutako kluster konfigurazio biltegiratze bat hautatu behar genuen. Patronik banatutako konfigurazio biltegiratze sistemekin lan egiten du, hala nola, etcd, Zookeeper, Consul. Kontsul kluster osoa dugu ekoizpenean, Vault-ekin batera lan egiten duena eta ez dugu gehiago erabiltzen. Arrazoi bikaina da Kontsul bere xederako erabiltzen hasteko.

Patronik nola lan egiten duen kontsularekin

Hiru nodoz osatuta dagoen Consul kluster bat dugu eta Patroni kluster bat, lider batek eta erreplikak osatzen dutena (Patroni-n, maisua kluster-burua deitzen da, eta esklaboei erreplikak). Patroni kluster-instantzia bakoitzak etengabe bidaltzen dio klusterraren egoerari buruzko informazioa Kontsulari. Hori dela eta, Kontsuletik beti jakin dezakezu Patroni klusterraren egungo konfigurazioa eta nor den une honetan liderra.

Patroni Kontsularekin konektatzeko, dokumentazio ofiziala aztertu besterik ez dago, non ostalaria http edo https formatuan zehaztu behar duzula, Consulrekin lan egiten dugun moduaren arabera, eta konexio diagrama, aukeran:

host: the host:port for the Consul endpoint, in format: http(s)://host:port
scheme: (optional) http or https, defaults to http

Erraza dirudi, baina hor hasten dira tranpak. Consul-ekin konexio seguru baten bidez lan egiten dugu https bidez eta gure konexioaren konfigurazioa honela izango da:

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

Baina ez du horrela funtzionatzen. Abiaraztean, Patroni ezin da Consul-era konektatu, oraindik http bidez joaten saiatzen delako.

Patroni iturburu-kodeak arazoa konpontzen lagundu zuen. Ona da python-ez idatzita egotea. Ematen du ostalariaren parametroa ez dela inola ere analizatzen, eta eskeman protokoloa zehaztu behar da. Hau da guretzat Consul-ekin lan egiteko konfigurazio-bloke bat:

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

Kontsul-txantiloia

Beraz, konfigurazio biltegiratzea aukeratu dugu. Orain ulertu behar dugu PgBouncer-ek nola aldatuko duen konfigurazioa Patroni klusterrean liderra aldatzen denean. Dokumentazioan ez dago galdera honi erantzunik, izan ere... Printzipioz, PgBouncer-ekin lan egitea ez da bertan azaltzen.

Irtenbide baten bila, artikulu bat aurkitu genuen (tamalez, ez dut izena gogoratzen), non idatzita zegoen Kontsul-txantiloia oso lagungarria zela PgBouncer eta Patroni konbinatzeko. Honek Kontsul-txantiloiaren lana aztertzera bultzatu gintuen.

Kontsul-txantiloiak PostgreSQL klusterraren konfigurazioa etengabe kontrolatzen duela ikusi da Consul-en. Liderra aldatzen denean, PgBouncer konfigurazioa eguneratzen du eta komando bat bidaltzen du birkargatzeko.

Txantiloiaren abantaila handia kode gisa gordetzen dela da, beraz, zati berri bat gehitzean nahikoa da konpromezu berri bat egitea eta txantiloia automatikoki eguneratzea, Azpiegitura kode printzipio gisa onartzen duena.

Arkitektura berria Patronirekin

Ondorioz, lan eskema hau jaso genuen:


Aplikazio-zerbitzari guztiak sartzen dira orekatzailea → haren atzean PgBouncer-en bi instantzia daude → instantzia bakoitzean Consul-txantiloi bat exekutatzen ari dena, Patroni kluster bakoitzaren egoera kontrolatzen duena eta PgBouncer konfigurazioaren garrantzia kontrolatzen duena, eskaerak egungo liderra zuzentzen dituena. kluster bakoitzarena.

Eskuzko probak

Produkziora abiarazi aurretik, eskema hau proba-ingurune txiki batean abiarazi genuen eta etenketa automatikoaren funtzionamendua egiaztatu genuen. Taula ireki, pegatina mugitu eta une horretan klusterreko buruzagia "hil" zuten. AWSn, egin behar duzun guztia instantzia itzali da kontsolaren bidez.

Eranskailua 10-20 segundoren buruan itzuli zen eta, ondoren, berriro normaltasunez mugitzen hasi zen. Horrek esan nahi du Patroni klusterrak behar bezala funtzionatu zuela: liderra aldatu zuen, informazioa bidali zion Consul-era eta Consul-template-k berehala jaso zuen informazio hori, PgBouncer konfigurazioa ordezkatu zuen eta komando bat bidali zuen birkargatzeko.

Nola bizi karga handian eta gutxieneko geldialdi-denbora mantendu?

Dena primeran funtzionatzen du! Baina galdera berriak sortzen dira: nola funtzionatuko du karga handiarekin? Nola azkar eta segurtasunez zabaldu ekoizpenean dena?

Karga-probak egiten ditugun proba-inguruneak lehen galderari erantzuten laguntzen digu. Arkitekturako ekoizpenaren guztiz berdina da eta proba-datuak sortu ditu, gutxi gorabehera ekoizpenaren bolumenaren berdina. Probak zehar PostgreSQL maisuetako bat "hiltzea" erabakitzen dugu eta zer gertatzen den ikustea. Baina aurretik, garrantzitsua da inplementazio automatikoa egiaztatzea, ingurune honetan PostgreSQL zati batzuk ditugulako, beraz, konfigurazio-scripten proba bikainak lortuko ditugu produzitu aurretik.

Bi zereginek asmo handikoak dirudite, baina PostgreSQL 9.6 dugu. Agian berehala eguneratu gaitezke 11.2ra?

Hau 2 fasetan egitea erabakitzen dugu: lehenik bertsioa eguneratu 11.2ra, eta gero Patroni abiarazi.

PostgreSQL eguneratzea

PostgreSQL bertsioa azkar eguneratzeko, aukera erabili behar duzu -k, zeinetan esteka gogor bat sortzen da diskoan eta ez dago zure datuak kopiatu beharrik. 300-400 GB-ko datu-baseetan, eguneratzeak segundo 1 irauten du.

Zati asko ditugu, beraz, eguneratzea automatikoki egin behar da. Horretarako, eguneratze prozesu osoa egiten digu Ansible playbook bat idatzi dugu:

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

Garrantzitsua da hemen berritzea hasi aurretik parametroarekin egin behar duzula --egiaztatuberritzea posible dela ziurtatzeko. Gure script-ak ere konfigurazioak ordezkatzen ditu eguneratzean. Gure gidoia 30 segundotan osatu da, emaitza bikaina da.

Patroni abian jartzea

Bigarren arazoa konpontzeko, begiratu besterik ez dago Patroniren konfigurazioa. Biltegi ofizialak initdb-rekin konfigurazio adibide bat du, Patroni lehen aldiz abiarazten denean datu-base berri bat hasieratzeaz arduratzen dena. Baina dagoeneko prest egindako datu-base bat dugunez, atal hau konfiguraziotik kendu besterik ez dugu egin.

Patroni prest egindako PostgreSQL kluster batean instalatzen eta hura abiarazten hasi ginenean, arazo berri bat aurkitu genuen: bi zerbitzariak lider gisa abiarazi ziren. Patronik ez daki ezer klusterraren hasierako egoeraz eta bi zerbitzariak izen bereko bi kluster gisa exekutatzen saiatzen da. Arazo hau konpontzeko, esklaboaren datu-direktorioa ezabatu behar duzu:

rm -rf /var/lib/postgresql/

Hau esklaboaren gainean bakarrik egin behar da!

Erreplika garbi bat konektatzean, Patronik basebackup lider bat egiten du eta erreplikan berrezartzen du, eta, ondoren, uneko egoera lortzen du wal erregistroak erabiliz.

Aurkitu dugun beste zailtasun bat PostgreSQL kluster guztiak lehenespenez nagusi deitzen direla da. Kluster bakoitzak besteari buruz ezer ez dakienean, hau normala da. Baina Patroni erabili nahi duzunean, kluster guztiek izen esklusibo bat izan behar dute. Irtenbidea PostgreSQL konfigurazioan kluster izena aldatzea da.

Karga proba

Erabiltzaileek arbeletan nola lan egiten duten simulatzen duen proba bat jarri dugu martxan. Karga gure eguneroko batez bestekoa iritsi zenean, proba bera errepikatu genuen, PostgreSQL liderrarekin instantzia bat desaktibatu genuen. Porrot automatikoak espero genuen bezala funtzionatu zuen: Patronik liderra aldatu zuen, Consul-template-k PgBouncer konfigurazioa eguneratu zuen eta komando bat bidali zuen birkargatzeko. Grafanako gure grafikoen arabera, argi zegoen 20-30 segundoko atzerapenak eta akats txikiak zeudela zerbitzarietatik datu-baserako konexioarekin erlazionatuta. Egoera normala da, horrelako balioak onargarriak dira gure hutsegiterako eta, zalantzarik gabe, zerbitzuaren geldialdia baino hobeak dira.

Patroni ekoizpenera martxan jartzea

Ondorioz, plan hau egin genuen:

• Inplementatu Kontsul-txantiloia PgBouncer zerbitzarian eta abiarazi;
• PostgreSQL 11.2 bertsiora eguneratzen da;
• Kluster izena aldatzea;
• Patroni klusterra abian jartzea.

Aldi berean, gure eskemak lehen puntua ia edozein unetan egiteko aukera ematen digu; PgBouncer bakoitza lanetik banan-banan ken dezakegu eta bertan kontsul-txantiloiaren hedapena eta abiaraztea egin dezakegu. Horixe egin genuen.

Proba azkarrak egiteko, Ansible erabili dugu, jada proba-ingurunean proba-ingurunean probatu baikenuen playbook osoa, eta script osoa exekutatzeko denbora zati bakoitzeko 1,5 eta 2 minutu bitartekoa zen. Dena banatu genezake zati bakoitzean banan-banan gure zerbitzua gelditu gabe, baina PostgreSQL bakoitza hainbat minutuz itzali beharko genuke. Kasu honetan, zati honetan datuak dituzten erabiltzaileek ezingo lukete guztiz lan egin une honetan, eta hori onartezina da guretzat.

Egoera honetatik irteteko mantenu planifikatua zen, 3 hilabetean behin egiten duguna. Hau programatutako lanerako leiho bat da, gure zerbitzua guztiz itzaltzen dugunean eta datu-basearen instantziak eguneratzen ditugunean. Astebete falta zen hurrengo leihorako, eta itxaron eta gehiago prestatzea erabaki genuen. Itxaronaldian, gainera, gure apustuak estali genituen: PostgreSQL zati bakoitzeko ordezko erreplika bat planteatu genuen hutsegiteen kasuan, azken datuak gordetzeko, eta zati bakoitzeko instantzia berri bat gehitu genuen, Patroni-n erreplika berri bat bihurtu beharko litzatekeena. cluster, datuak ezabatzeko komandorik ez emateko. Horrek guztiak errore-arriskua gutxitzen lagundu zuen.


Gure zerbitzua berrabiarazi genuen, dena behar bezala funtzionatu zuen, erabiltzaileek lanean jarraitu zuten, baina grafikoetan karga anormal handi bat nabaritu genuen Consul zerbitzarietan.


Zergatik ez dugu hau ikusi proba-ingurunean? Arazo honek oso ondo erakusten du beharrezkoa dela Azpiegitura kode printzipio gisa jarraitu eta azpiegitura osoa hobetzea, proba-inguruneetatik hasi eta ekoizpenera arte. Bestela, oso erraza da lortu dugun arazoa lortzea. Zer gertatu da? Kontsul ekoizpenean agertu zen lehenik, eta proba-inguruneetan gero; ondorioz, proba-inguruneetan Consul-en bertsioa ekoizpenean baino handiagoa zen. Argitalpenetako batean bakarrik, PUZaren ihesa konpondu zen kontsul-txantiloiarekin lan egitean. Beraz, Kontsul eguneratu besterik ez dugu egin, eta horrela arazoa konponduz.

Berrabiarazi Patroni clusterra

Hala ere, susmatzen ere ez genuen arazo berri bat iritsi zaigu. Kontsula eguneratzean, kontsul-nodoa klustertik kendu besterik ez dugu kontsul utzi komandoa erabiliz → Patroni beste Consul zerbitzari batera konektatzen da → dena funtzionatzen du. Baina Consul klusterraren azken instantziara iritsi eta kontsul utzi komandoa bidali genionean, Patroni kluster guztiak berrabiarazi ziren eta erregistroetan errore hau ikusi genuen:

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 klusterrak ezin izan du bere klusterari buruzko informaziorik lortu eta berrabiarazi da.

Irtenbide bat bilatzeko, Patroni-ren egileekin harremanetan jarri ginen github-eko arazo baten bidez. Gure konfigurazio fitxategietan hobekuntzak iradoki dituzte:

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

Arazoa proba-ingurune batean errepikatu ahal izan dugu eta ezarpen hauek bertan probatu ditugu, baina, tamalez, ez dute funtzionatu.

Arazoak oraindik konpondu gabe jarraitzen du. Konponbide hauek probatzeko asmoa dugu:

• Erabili Consul-agent Patroni klusterraren instantzia bakoitzean;
• Konpondu arazoa kodean.

Errorea non gertatu den ulertzen dugu: ziurrenik arazoa denbora-muga lehenetsia erabiltzean dago, eta hori ez da konfigurazio fitxategiaren bidez gainidazten. Azken Consul zerbitzaria klusterretik kentzen denean, Consul kluster osoa izoztu egiten da, segundo bat baino gehiago irauten duena; horregatik, Patronik ezin du klusterren egoera lortu eta kluster osoa guztiz berrabiaraziko du.

Zorionez, ez dugu akats gehiagorik aurkitu.

Patroni erabiltzearen emaitzak

Patroni arrakastaz abian jarri ondoren, erreplika gehigarri bat gehitu dugu kluster bakoitzean. Orain kluster bakoitzak quorum itxura du: lider bat eta bi erreplika, aldatzean garun zatituaren aurka babesteko.


Patronik hiru hilabete baino gehiago daramatza ekoizpenean lanean. Denbora horretan, dagoeneko lortu zuen guri laguntzea. Duela gutxi, klusterren baten liderra AWSn hil zen, hutsegite automatikoak funtzionatu zuen eta erabiltzaileek lanean jarraitu zuten. Patronik bere eginkizun nagusia bete du.

Patroni erabiltzearen laburpen labur bat:

• Konfigurazio-aldaketak egiteko erraztasuna. Nahikoa da instantzia batean konfigurazioa aldatzea eta kluster osoan aplikatuko da. Konfigurazio berria aplikatzeko berrabiarazi behar bada, Patronik horren berri emango dizu. Patronik kluster osoa berrabiarazi dezake komando batekin, eta hori ere oso erosoa da.
• Porrot automatikoa funtzionatzen ari da eta dagoeneko lagundu digu.
• PostgreSQL eguneratzea aplikazioaren geldialdirik gabe. Lehenik eta behin erreplikak bertsio berrira eguneratu behar dituzu, gero Patroni klusterreko liderra aldatu eta lider zaharra eguneratu. Kasu honetan, hutsegite automatikoaren beharrezko probak egiten dira.

Iturria: www.habr.com