Failover Cluster PostgreSQL + Patroni. Izkušnje z implementacijo

V članku vam bom povedal, kako smo pristopili k vprašanju tolerance napak PostgreSQL, zakaj je postalo pomembno za nas in kaj se je na koncu zgodilo.

Imamo zelo obremenjeno storitev: 2,5 milijona uporabnikov po vsem svetu, 50+ aktivnih uporabnikov vsak dan. Strežniki se nahajajo v Amazone v eni regiji na Irskem: nenehno deluje več kot 100 različnih strežnikov, od tega skoraj 50 z bazami podatkov.

Celotno zaledje je velika monolitna aplikacija Java s stanjem, ki ohranja stalno povezavo websocket z odjemalcem. Ko na isti plošči dela več uporabnikov hkrati, vsi vidijo spremembe v realnem času, saj vsako spremembo zapišemo v bazo. V naše baze podatkov imamo približno 10 zahtev na sekundo. Pri največji obremenitvi v Redisu pišemo 80-100K zahtev na sekundo.

Zakaj smo prešli z Redisa na PostgreSQL

Na začetku je naša storitev sodelovala z Redisom, shrambo ključev in vrednosti, ki shranjuje vse podatke v RAM strežnika.

Prednosti Redisa:

1. Visoka odzivna hitrost, saj vse je shranjeno v pomnilniku;
2. Enostavnost varnostnega kopiranja in podvajanja.

Slabosti Redisa za nas:

1. Pravih transakcij ni. Poskušali smo jih simulirati na ravni naše aplikacije. Na žalost to ni vedno dobro delovalo in zahtevalo je pisanje zelo zapletene kode.
2. Količina podatkov je omejena s količino pomnilnika. Z večanjem količine podatkov se bo pomnilnik večal in na koncu bomo naleteli na značilnosti izbrane instance, ki v AWS zahteva zaustavitev naše storitve za spremembo vrste instance.
3. Nenehno je treba vzdrževati nizko stopnjo zakasnitve, saj. imamo zelo veliko povpraševanj. Optimalna stopnja zakasnitve za nas je 17-20 ms. Na nivoju 30-40 ms dobimo dolge odgovore na zahteve naše aplikacije in poslabšanje storitve. Na žalost se nam je to zgodilo septembra 2018, ko je ena od instanc z Redisom iz neznanega razloga prejela 2-krat večjo zakasnitev kot običajno. Da bi rešili težavo, smo sredi dneva ustavili storitev zaradi nenačrtovanega vzdrževanja in zamenjali problematični primerek Redisa.
4. Preprosto je dobiti nedoslednost podatkov tudi z manjšimi napakami v kodi in nato porabiti veliko časa za pisanje kode za popravljanje teh podatkov.

Upoštevali smo slabosti in spoznali, da se moramo premakniti na nekaj bolj priročnega, z običajnimi transakcijami in manjšo odvisnostjo od zakasnitve. Izvedel raziskavo, analiziral številne možnosti in izbral PostgreSQL.

Na novo bazo prehajamo že 1,5 leta in smo premaknili le majhen del podatkov, tako da zdaj delamo sočasno z Redisom in PostgreSQL. Več informacij o stopnjah premikanja in preklapljanja podatkov med zbirkami podatkov je napisanih v članek moje kolegice.

Ko smo se prvič začeli seliti, je naša aplikacija delala neposredno z bazo podatkov in dostopala do glavnega Redis in PostgreSQL. Gruča PostgreSQL je bila sestavljena iz masterja in replike z asinhronim podvajanjem. Tako je izgledala shema baze podatkov:

Implementacija PgBouncer

Med selitvijo se je razvijal tudi produkt: povečalo se je število uporabnikov in število strežnikov, ki so delali s PostgreSQL, začelo nam je primanjkovati povezav. PostgreSQL ustvari ločen proces za vsako povezavo in porabi vire. Število povezav lahko povečate do določene točke, sicer obstaja možnost, da bo delovanje baze podatkov neoptimalno. Idealna možnost v takšni situaciji bi bila izbira upravitelja povezav, ki bo stal pred bazo.

Za upravitelja povezav smo imeli dve možnosti: Pgpool in PgBouncer. Toda prvi ne podpira transakcijskega načina dela z bazo podatkov, zato smo izbrali PgBouncer.

Postavili smo naslednjo shemo dela: naša aplikacija dostopa do enega PgBouncerja, za katerim stojijo PostgreSQL masterji, za vsakim masterjem pa je ena replika z asinhrono replikacijo.


Hkrati nismo mogli hraniti celotne količine podatkov v PostgreSQL in je bila za nas pomembna hitrost dela z bazo podatkov, zato smo se lotili šardinga PostgreSQL na nivoju aplikacije. Zgoraj opisana shema je za to razmeroma priročna: ko dodajate nov del PostgreSQL, je dovolj, da posodobite konfiguracijo PgBouncer in aplikacija lahko takoj deluje z novim delcem.

PgBouncer samodejni preklop

Ta shema je delovala do trenutka, ko je umrl edini primerek PgBouncer. Smo v AWS, kjer se vsi primerki izvajajo na strojni opremi, ki občasno umre. V takšnih primerih se primerek enostavno premakne na novo strojno opremo in znova deluje. To se je zgodilo s PgBouncerjem, vendar je postal nedosegljiv. Posledica tega padca je bila 25 minutna nedosegljivost naše storitve. AWS za takšne situacije priporoča uporabo redundance na uporabniški strani, ki pri nas takrat še ni bila implementirana.

Po tem smo resno razmišljali o toleranci napak PgBouncer in PostgreSQL grozdov, ker bi se podobna situacija lahko zgodila s katero koli instanco v našem računu AWS.

Shemo tolerance napak PgBouncer smo zgradili na naslednji način: vsi aplikacijski strežniki dostopajo do Network Load Balancerja, za katerim sta dva PgBouncerja. Vsak PgBouncer gleda na isti master PostgreSQL vsakega drobca. Če se primerek AWS ponovno zruši, se ves promet preusmeri prek drugega PgBouncerja. Omrežni izenačevalnik obremenitve zaradi napake zagotavlja AWS.

Ta shema olajša dodajanje novih strežnikov PgBouncer.

Ustvarite PostgreSQL Failover Cluster

Pri reševanju tega problema smo razmišljali o različnih možnostih: samonapisan failover, repmgr, AWS RDS, Patroni.

Samostojno napisani scenariji

Lahko spremljajo delo masterja in v primeru njegove okvare povišajo repliko v masterja in posodobijo konfiguracijo PgBouncer.

Prednosti tega pristopa so največja preprostost, saj skripte pišete sami in natančno razumete, kako delujejo.

Cons:

• Glavni morda ni umrl, namesto tega je morda prišlo do okvare omrežja. Preklop v primeru napake, ki se tega ne zaveda, bo repliko povišal v master, medtem ko bo stari master nadaljeval z delom. Posledično bomo dobili dva strežnika v vlogi masterja in ne bomo vedeli, kateri od njiju ima zadnje ažurne podatke. To stanje imenujemo tudi razcepljeni možgani;
• Ostali smo brez odgovora. V naši konfiguraciji, glavni in ena replika, se po preklopu replika premakne na glavno in nimamo več replik, zato moramo ročno dodati novo repliko;
• Potrebujemo dodatno spremljanje failover operacije, medtem ko imamo 12 PostgreSQL shardov, kar pomeni, da moramo spremljati 12 gruč. S povečanjem števila drobcev se morate spomniti tudi na posodobitev samodejnega preklopa.

Samodejni preklop je videti zelo zapleten in zahteva netrivialno podporo. Z eno samo gručo PostgreSQL bi bila to najlažja možnost, vendar se ne prilagaja, zato za nas ni primerna.

Repmgr

Replication Manager za gruče PostgreSQL, ki lahko upravlja delovanje gruče PostgreSQL. Hkrati nima samodejnega preklopa izven škatle, zato boste za delo morali napisati svoj »ovitek« na vrhu končne rešitve. Tako lahko vse izpade še bolj zapleteno kot pri samonapisanih skriptah, zato Repmgr sploh nismo poskusili.

AWS RDS

Podpira vse, kar potrebujemo, zna narediti varnostne kopije in vzdržuje skupino povezav. Ima samodejno preklapljanje: ko glavni umre, replika postane novi glavni in AWS spremeni zapis dns na novega glavnega, medtem ko se replike lahko nahajajo v različnih AZ.

Slabosti vključujejo pomanjkanje finih nastavitev. Kot primer natančne nastavitve: naši primerki imajo omejitve za tcp povezave, ki jih na žalost ni mogoče narediti v RDS:

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

Poleg tega je AWS RDS skoraj dvakrat dražji od redne cene instance, kar je bil glavni razlog za opustitev te rešitve.

Patroni

To je predloga python za upravljanje PostgreSQL z dobro dokumentacijo, samodejnim preklopom in izvorno kodo na githubu.

Prednosti Patronija:

• Vsak konfiguracijski parameter je opisan, jasno je, kako deluje;
• Samodejni preklop deluje takoj po namestitvi;
• Napisano v pythonu in ker tudi sami veliko pišemo v pythonu, se bomo lažje spopadali s težavami in morda celo pomagali pri razvoju projekta;
• Popolnoma upravlja PostgreSQL, omogoča spreminjanje konfiguracije na vseh vozliščih gruče hkrati, in če je treba gručo znova zagnati za uporabo nove konfiguracije, lahko to storite znova s ​​Patronijem.

Cons:

• Iz dokumentacije ni jasno, kako pravilno delati s PgBouncer. Čeprav temu težko rečemo minus, saj je Patronijeva naloga upravljanje PostgreSQL, kako bodo potekale povezave s Patronijem, pa je že naš problem;
• Primerov implementacije Patronija na velike količine je malo, medtem ko je veliko primerov implementacije iz nič.

Zato smo izbrali Patroni za ustvarjanje samodejne gruče.

Patroni Implementation Process

Pred Patronijem smo imeli 12 PostgreSQL shardov v konfiguraciji enega masterja in ene replike z asinhrono replikacijo. Aplikacijski strežniki so do baz dostopali prek Network Load Balancerja, za katerim sta bili dve instanci s PgBouncerjem, za njima pa vsi strežniki PostgreSQL.


Za implementacijo Patronija smo morali izbrati konfiguracijo porazdeljene gruče za shranjevanje. Patroni deluje s sistemi za shranjevanje porazdeljenih konfiguracij, kot so etcd, Zookeeper, Consul. Na trgu imamo le polnopravni grozd Consul, ki deluje v povezavi z Vaultom in ga ne uporabljamo več. Odličen razlog, da začnete uporabljati Consul za predvideni namen.

Kako Patroni sodeluje s Consulom

Imamo gručo Consul, ki je sestavljena iz treh vozlišč, in gručo Patroni, ki je sestavljena iz vodje in replike (v Patroniju se master imenuje vodja gruče, podrejeni pa replike). Vsaka instanca gruče Patroni nenehno pošilja podatke o stanju gruče Consulu. Zato lahko pri Consulu vedno izveste trenutno konfiguracijo gruče Patroni in kdo je trenutno vodilni.

Za povezavo Patronija s Consulom je dovolj, da preučite uradno dokumentacijo, ki pravi, da morate določiti gostitelja v formatu http ali https, odvisno od tega, kako delamo s Consulom, in shemo povezave, po želji:

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

Videti je preprosto, a tu se začnejo pasti. S Consulom delamo prek varne povezave prek https in naša konfiguracija povezave bo videti takole:

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

Ampak to ne gre. Ob zagonu se Patroni ne more povezati s Consulom, ker vseeno poskuša iti prek http.

Izvorna koda Patronija je pomagala rešiti težavo. Še dobro, da je napisano v pythonu. Izkazalo se je, da parameter gostitelja ni razčlenjen na noben način in mora biti protokol naveden v shemi. Takole izgleda delovni konfiguracijski blok za delo s Consulom pri nas:

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

konzul-šablona

Tako smo izbrali shrambo za konfiguracijo. Zdaj moramo razumeti, kako bo PgBouncer spremenil svojo konfiguracijo, ko bo spremenil vodilnega v gruči Patroni. Dokumentaciji to vprašanje ni odgovora, saj. tam načeloma delo s PgBouncerjem ni opisano.

V iskanju rešitve smo našli članek (žal se ne spomnim naslova), kjer je pisalo, da je Sonsul-template zelo pomagal pri parjenju PgBouncerja in Patronija. To nas je spodbudilo, da smo raziskali, kako deluje Consul-template.

Izkazalo se je, da Consul-template nenehno spremlja konfiguracijo gruče PostgreSQL v Consulu. Ko se vodja spremeni, posodobi konfiguracijo PgBouncer in pošlje ukaz za ponovno nalaganje.

Velik plus predloge je, da je shranjena kot koda, tako da je pri dodajanju novega sharda dovolj, da naredite novo potrditev in samodejno posodobite predlogo, kar podpira načelo Infrastruktura kot koda.

Nova arhitektura s Patronijem

Kot rezultat smo dobili naslednjo shemo dela:


Vsi aplikacijski strežniki dostopajo do uravnoteženja → za njim sta dve instanci PgBouncer → na vsaki instanci se zažene Consul-template, ki spremlja status vsake gruče Patroni in spremlja ustreznost konfiguracije PgBouncer, ki pošilja zahteve trenutnemu vodji vsakega grozda.

Ročno testiranje

To shemo smo zagnali pred zagonom v majhnem testnem okolju in preverili delovanje samodejnega preklopa. Odprli so tablo, premaknili nalepko in v tistem trenutku »ubili« vodjo grozda. V AWS je to tako preprosto kot zaustavitev primerka prek konzole.

Nalepka se je vrnila v 10-20 sekundah, nato pa se je spet začela normalno premikati. To pomeni, da je gruča Patroni delovala pravilno: zamenjala je voditelja, poslala podatke Consulu, Consul-template pa je te informacije takoj pobral, zamenjal konfiguracijo PgBouncer in poslal ukaz za ponovno nalaganje.

Kako preživeti pod visoko obremenitvijo in ohraniti čas izpadov čim manjši?

Vse deluje odlično! Pojavljajo pa se nova vprašanja: Kako bo deloval pod visoko obremenitvijo? Kako hitro in varno uvesti vse v proizvodnjo?

Na prvo vprašanje nam pomaga odgovoriti testno okolje, na katerem izvajamo obremenitveno testiranje. Z vidika arhitekture je popolnoma enak proizvodnji in je ustvaril testne podatke, ki so po obsegu približno enaki proizvodnji. Odločili smo se, da bomo med testom preprosto "ubili" enega od mojstrov PostgreSQL in videli, kaj se bo zgodilo. Pred tem pa je pomembno preveriti samodejno rolanje, saj imamo v tem okolju več PostgreSQL shardov, tako da bomo dobili odlično testiranje konfiguracijskih skriptov pred produkcijo.

Obe nalogi sta videti ambiciozni, vendar imamo PostgreSQL 9.6. Ali lahko takoj nadgradimo na 11.2?

Odločili smo se, da bomo to storili v dveh korakih: najprej nadgradimo na 2, nato zaženemo Patroni.

Posodobitev PostgreSQL

Za hitro posodobitev različice PostgreSQL uporabite možnost -k, pri katerem so trde povezave ustvarjene na disku in vaših podatkov ni treba kopirati. Pri bazah 300-400 GB posodobitev traja 1 sekundo.

Imamo veliko drobcev, zato je treba posodobitev izvesti samodejno. Da bi to naredili, smo napisali Ansible playbook, ki namesto nas obravnava celoten postopek posodobitve:

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

Tukaj je pomembno upoštevati, da morate pred začetkom nadgradnje to izvesti s parametrom --preveritida zagotovite, da lahko nadgradite. Naš skript naredi tudi zamenjavo konfiguracij za čas nadgradnje. Naš scenarij je bil dokončan v 30 sekundah, kar je odličen rezultat.

Zaženite Patroni

Če želite rešiti drugo težavo, samo poglejte konfiguracijo Patronija. Uradni repozitorij ima primer konfiguracije z initdb, ki je odgovoren za inicializacijo nove baze podatkov, ko prvič zaženete Patroni. Ker pa že imamo pripravljeno bazo podatkov, smo ta razdelek preprosto odstranili iz konfiguracije.

Ko smo začeli nameščati Patroni na že obstoječo gručo PostgreSQL in jo izvajati, smo naleteli na novo težavo: oba strežnika sta začela kot vodilna. Patroni ne ve ničesar o zgodnjem stanju gruče in poskuša zagnati oba strežnika kot dve ločeni gruči z istim imenom. Če želite rešiti to težavo, morate izbrisati imenik s podatki na podrejeni napravi:

rm -rf /var/lib/postgresql/

To je treba storiti samo na sužnju!

Ko je povezana čista replika, Patroni ustvari vodjo osnovne varnostne kopije in jo obnovi v repliko, nato pa dohiti trenutno stanje glede na dnevnike zidov.

Druga težava, na katero smo naleteli, je, da so vse gruče PostgreSQL privzeto poimenovane glavne. Če vsaka skupina ne ve ničesar o drugi, je to normalno. Ko pa želite uporabljati Patroni, morajo imeti vse gruče edinstveno ime. Rešitev je, da spremenite ime gruče v konfiguraciji PostgreSQL.

preizkus obremenitve

Uvedli smo test, ki simulira uporabniško izkušnjo na ploščah. Ko je obremenitev dosegla našo povprečno dnevno vrednost, smo ponovili povsem enak test, izklopili smo eno instanco z vodilnim PostgreSQL. Samodejni preklop je deloval, kot smo pričakovali: Patroni je spremenil vodilnega, Consul-template je posodobil konfiguracijo PgBouncer in poslal ukaz za ponovno nalaganje. Glede na naše grafe v Grafani je bilo razvidno, da prihaja do zamud 20-30 sekund in majhne količine napak iz strežnikov, povezanih s povezavo do baze podatkov. To je normalna situacija, takšne vrednosti so sprejemljive za naš failover in so vsekakor boljše od izpada storitve.

Priprava Patronija v proizvodnjo

Kot rezultat smo prišli do naslednjega načrta:

• Namestite predlogo Consul na strežnike PgBouncer in zaženite;
• Posodobitve PostgreSQL na različico 11.2;
• Spremenite ime gruče;
• Zagon gruče Patroni.

Hkrati nam naša shema omogoča, da naredimo prvo točko skoraj kadar koli, vsak PgBouncer lahko po vrsti odstranimo iz dela ter na njem namestimo in zaženemo predlogo konzula. Tako smo tudi naredili.

Za hitro postavitev smo uporabili Ansible, saj smo že vse playbooke testirali na testnem okolju, čas izvajanja celotne skripte pa je bil od 1,5 do 2 minuti za vsak shard. Lahko bi uvedli vse po vrsti na vsak delček, ne da bi ustavili našo storitev, vendar bi morali vsak PostgreSQL izklopiti za nekaj minut. V tem primeru uporabniki, katerih podatki so na tem shardu, trenutno ne morejo v celoti delovati, kar je za nas nesprejemljivo.

Izhod iz te situacije je bilo načrtovano vzdrževanje, ki poteka vsake 3 mesece. To je okno za načrtovano delo, ko popolnoma zaustavimo našo storitev in nadgradimo instance baze podatkov. Do naslednjega okna je ostal še en teden in odločili smo se, da počakamo in se pripravimo naprej. V času čakanja smo se dodatno zavarovali: za vsak šard PostgreSQL smo dvignili rezervno repliko v primeru neuspešnega ohranjanja najnovejših podatkov in za vsak šard dodali novo instanco, ki naj bi postala nova replika v gruči Patroni, da ne bi izvršil ukaza za brisanje podatkov . Vse to je pomagalo zmanjšati tveganje napake.


Ponovno smo zagnali našo storitev, vse je delovalo kot mora, uporabniki so delali naprej, vendar smo na grafih opazili nenormalno visoko obremenitev strežnikov Consul.


Zakaj tega nismo videli v testnem okolju? Ta problem zelo dobro ponazarja, da je treba slediti načelu Infrastruktura kot koda in izpopolniti celotno infrastrukturo, od testnih okolij do produkcije. V nasprotnem primeru je zelo enostavno dobiti problem, ki ga imamo. Kaj se je zgodilo? Consul se je najprej pojavil v produkcijskih, nato pa v testnih okoljih, zato je bila v testnih okoljih različica Consula višja od produkcijske. Samo v eni od izdaj je bilo odpravljeno puščanje procesorja pri delu s predlogo konzula. Zato smo preprosto posodobili Consul in tako rešili težavo.

Znova zaženite gručo Patroni

Dobili pa smo novo težavo, ki je nismo niti slutili. Ko posodabljamo Consul, preprosto odstranimo vozlišče Consul iz gruče z ukazom consul leave → Patroni se poveže z drugim strežnikom Consul → vse deluje. Ko pa smo dosegli zadnjo instanco gruče Consul in ji poslali ukaz za odhod konzula, so se vse gruče Patroni preprosto znova zagnale in v dnevnikih smo videli to napako:

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>

Gruča Patroni ni mogla pridobiti informacij o svoji gruči in se je znova zagnala.

Da bi našli rešitev, smo stopili v stik z avtorji Patronija prek težave na githubu. Predlagali so izboljšave naših konfiguracijskih datotek:

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

Težavo smo lahko posnemali v testnem okolju in tam preizkusili te možnosti, a žal niso delovale.

Problem še vedno ostaja nerešen. Preizkusiti nameravamo naslednje rešitve:

• Uporabite Consul-agent na vsaki instanci gruče Patroni;
• Odpravite težavo v kodi.

Razumemo, kje je prišlo do napake: težava je verjetno uporaba privzete časovne omejitve, ki ni preglasena v konfiguracijski datoteki. Ko je zadnji strežnik Consul odstranjen iz gruče, celotna gruča Consul visi za več kot sekundo, zaradi tega Patroni ne more pridobiti statusa gruče in popolnoma znova zažene celotno gručo.

Na srečo nismo več naleteli na napake.

Rezultati uporabe Patronija

Po uspešnem lansiranju Patronija smo v vsako gručo dodali dodatno repliko. Zdaj je v vsaki gruči podoben kvorum: en voditelj in dve repliki, za varnostno mrežo v primeru razcepljenih možganov pri preklopu.


Patroni se s proizvodnjo ukvarja že več kot tri mesece. V tem času nam je že uspel pomagati. Pred kratkim je vodja enega od grozdov umrl v AWS, samodejni preklop je deloval in uporabniki so nadaljevali z delom. Patroni je izpolnil svojo glavno nalogo.

Majhen povzetek uporabe Patronija:

• Enostavnost spreminjanja konfiguracije. Dovolj je, da spremenite konfiguracijo na enem primerku in ta se bo potegnila na celotno gručo. Če je za uporabo nove konfiguracije potreben ponovni zagon, vas bo Patroni o tem obvestil. Patroni lahko znova zažene celotno gručo z enim samim ukazom, kar je tudi zelo priročno.
• Samodejni preklop deluje in nam je že pomagal.
• Posodobitev PostgreSQL brez izpada aplikacije. Najprej morate posodobiti replike na novo različico, nato spremeniti vodilnega v gruči Patroni in posodobiti starega vodilnega. V tem primeru pride do potrebnega testiranja samodejnega preklopa.

Vir: www.habr.com