Failover Cluster PostgreSQL + Patroni. Iskustvo implementacije

U članku ću vam reći kako smo pristupili problemu PostgreSQL tolerancije grešaka, zašto nam je to postalo važno i što se na kraju dogodilo.

Imamo vrlo opterećenu uslugu: 2,5 milijuna korisnika diljem svijeta, 50K+ aktivnih korisnika svaki dan. Poslužitelji se nalaze u Amazoneu u jednoj regiji Irske: 100+ različitih poslužitelja stalno radi, od kojih je gotovo 50 s bazama podataka.

Cijeli backend velika je monolitna Java aplikacija s praćenjem stanja koja održava stalnu websocket vezu s klijentom. Kada nekoliko korisnika istovremeno radi na istoj ploči, svi vide promjene u stvarnom vremenu, jer svaku promjenu upisujemo u bazu. Imamo oko 10 tisuća zahtjeva u sekundi prema našim bazama podataka. Pri vršnom opterećenju u Redisu pišemo 80-100K zahtjeva u sekundi.

Zašto smo se prebacili s Redisa na PostgreSQL

U početku je naša usluga radila s Redisom, pohranom ključeva i vrijednosti koja pohranjuje sve podatke u RAM poslužitelja.

Prednosti Redisa:

1. Velika brzina odgovora, jer sve je pohranjeno u memoriji;
2. Jednostavnost sigurnosnog kopiranja i replikacije.

Nedostaci Redisa za nas:

1. Nema pravih transakcija. Pokušali smo ih simulirati na razini naše aplikacije. Nažalost, to nije uvijek dobro funkcioniralo i zahtijevalo je pisanje vrlo složenog koda.
2. Količina podataka ograničena je količinom memorije. Kako se količina podataka povećava, memorija će rasti, a na kraju ćemo naletjeti na karakteristike odabrane instance, što u AWS-u zahtijeva zaustavljanje naše usluge kako bi se promijenila vrsta instance.
3. Potrebno je stalno održavati nisku razinu latencije, jer. imamo jako veliki broj zahtjeva. Optimalna razina kašnjenja za nas je 17-20 ms. Na razini od 30-40 ms dobivamo duge odgovore na zahtjeve naše aplikacije i degradaciju usluge. Nažalost, to nam se dogodilo u rujnu 2018., kada je jedna od instanci s Redisom iz nekog razloga dobila latenciju 2 puta veću nego inače. Kako bismo riješili problem, prekinuli smo uslugu usred dana zbog neplaniranog održavanja i zamijenili problematičnu instancu Redisa.
4. Lako je dobiti nedosljednost podataka čak i s manjim pogreškama u kodu, a zatim potrošiti puno vremena na pisanje koda za ispravljanje tih podataka.

Uzeli smo u obzir nedostatke i shvatili da moramo prijeći na nešto praktičnije, s normalnim transakcijama i manjom ovisnošću o kašnjenju. Proveo istraživanje, analizirao mnoge mogućnosti i odabrao PostgreSQL.

Već 1,5 godinu prelazimo na novu bazu i premjestili smo samo mali dio podataka, tako da sada radimo simultano s Redisom i PostgreSQL-om. Više informacija o fazama premještanja i prebacivanja podataka između baza podataka je napisano u članak moje kolegice.

Kad smo se tek počeli seliti, naša je aplikacija radila izravno s bazom podataka i pristupala glavnim Redis-u i PostgreSQL-u. PostgreSQL klaster sastojao se od mastera i replike s asinkronom replikacijom. Ovako je izgledala shema baze podataka:

Implementacija PgBouncera

Dok smo se selili, razvijao se i proizvod: povećavao se broj korisnika i broj poslužitelja koji su radili s PostgreSQL-om, a počelo nam je nedostajati veza. PostgreSQL stvara zaseban proces za svaku vezu i troši resurse. Možete povećati broj veza do određene točke, inače postoji mogućnost da dobijete neoptimalne performanse baze podataka. Idealna opcija u takvoj situaciji bila bi odabrati upravitelja veza koji će stajati ispred baze.

Imali smo dvije opcije za upravitelja povezivanja: Pgpool i PgBouncer. Ali prvi ne podržava transakcijski način rada s bazom podataka, pa smo odabrali PgBouncer.

Postavili smo sljedeću shemu rada: naša aplikacija pristupa jednom PgBounceru iza kojeg se nalaze PostgreSQL masteri, a iza svakog mastera je jedna replika s asinkronom replikacijom.


Pritom nismo mogli pohraniti cjelokupnu količinu podataka u PostgreSQL i bila nam je bitna brzina rada s bazom, pa smo krenuli s shardiranjem PostgreSQL-a na razini aplikacije. Gore opisana shema je relativno prikladna za to: kada dodajete novi PostgreSQL shard, dovoljno je ažurirati konfiguraciju PgBouncera i aplikacija može odmah raditi s novim shardom.

PgBouncer failover

Ova shema je radila do trenutka kada je jedina instanca PgBouncera umrla. Nalazimo se u AWS-u, gdje se sve instance pokreću na hardveru koji povremeno umire. U takvim slučajevima, instanca se jednostavno premješta na novi hardver i ponovno radi. To se dogodilo s PgBouncerom, ali je postao nedostupan. Posljedica ovog pada bila je nedostupnost naše usluge 25 minuta. AWS za takve situacije preporuča korištenje redundancije na korisničkoj strani, koja u to vrijeme nije bila implementirana kod nas.

Nakon toga ozbiljno smo razmišljali o toleranciji grešaka PgBouncer i PostgreSQL klastera, jer bi se slična situacija mogla dogoditi s bilo kojom instancom na našem AWS računu.

Izgradili smo PgBouncer shemu tolerancije grešaka na sljedeći način: svi aplikacijski poslužitelji pristupaju Network Load Balanceru, iza kojeg se nalaze dva PgBouncera. Svaki PgBouncer gleda isti PostgreSQL master za svaki shard. Ako ponovno dođe do pada instance AWS-a, sav se promet preusmjerava kroz drugi PgBouncer. Nadilaženje mrežnog balansera opterećenja osigurava AWS.

Ova shema olakšava dodavanje novih PgBouncer poslužitelja.

Napravite PostgreSQL Failover Cluster

Prilikom rješavanja ovog problema razmatrali smo različite opcije: samonapisani failover, repmgr, AWS RDS, Patroni.

Skripte koje sam napisao

Oni mogu pratiti rad mastera i, ako ne uspije, promovirati repliku u master i ažurirati konfiguraciju PgBouncera.

Prednosti ovog pristupa su maksimalna jednostavnost, jer sami pišete skripte i točno razumijete kako rade.

Cons:

• Master možda nije umro, umjesto toga možda je došlo do kvara na mreži. Failover, nesvjestan toga, unaprijedit će repliku u master, dok će stari master nastaviti s radom. Kao rezultat toga, dobit ćemo dva servera u ulozi mastera i nećemo znati koji od njih ima najnovije ažurne podatke. Ova situacija se također naziva split-brain;
• Ostali smo bez odgovora. U našoj konfiguraciji, master i jedna replika, nakon prebacivanja, replika se pomiče prema masteru i više nemamo replika, tako da moramo ručno dodati novu repliku;
• Treba nam dodatno praćenje failover operacije, dok imamo 12 PostgreSQL shardova, što znači da moramo nadzirati 12 klastera. S povećanjem broja fragmenata, također morate zapamtiti da ažurirate failover.

Samonapisani failover izgleda vrlo komplicirano i zahtijeva netrivijalnu podršku. S jednim PostgreSQL klasterom, ovo bi bila najlakša opcija, ali se ne skalira, pa nije prikladna za nas.

Repmgr

Replication Manager za PostgreSQL klastere, koji može upravljati radom PostgreSQL klastera. Istodobno, nema automatski failover izvan kutije, tako da ćete za rad morati napisati vlastiti "omot" na vrhu gotovog rješenja. Dakle, sve može ispasti još kompliciranije nego sa samonapisanim skriptama, pa nismo ni pokušali Repmgr.

AWS RDS

Podržava sve što trebamo, zna napraviti sigurnosne kopije i održava skup veza. Ima automatsko prebacivanje: kada master umre, replika postaje novi master, a AWS mijenja dns zapis na novi master, dok se replike mogu nalaziti u različitim AZ-ovima.

Nedostaci uključuju nedostatak finih podešavanja. Kao primjer finog podešavanja: naše instance imaju ograničenja za tcp veze, što se, nažalost, ne može učiniti u RDS-u:

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

Osim toga, AWS RDS je gotovo dvostruko skuplji od redovne cijene instance, što je bio glavni razlog odustajanja od ovog rješenja.

pokrovitelj

Ovo je python predložak za upravljanje PostgreSQL-om s dobrom dokumentacijom, automatskim prebacivanjem greške i izvornim kodom na githubu.

Prednosti Patronija:

• Svaki konfiguracijski parametar je opisan, jasno je kako radi;
• Automatski failover radi izvan kutije;
• Napisano u pythonu, a budući da i sami puno pišemo u pythonu, bit će nam lakše nositi se s problemima i možda čak pomoći razvoju projekta;
• U potpunosti upravlja PostgreSQL-om, omogućuje promjenu konfiguracije na svim čvorovima klastera odjednom, a ako je klaster potrebno ponovno pokrenuti da bi se primijenila nova konfiguracija, to se može ponovno učiniti pomoću Patronija.

Cons:

• Iz dokumentacije nije jasno kako ispravno raditi s PgBouncerom. Iako je to teško nazvati minusom, jer zadatak Patronija je upravljanje PostgreSQL-om, a kako će ići veze s Patronijem to je već naš problem;
• Malo je primjera implementacije Patronija na velikim količinama, dok je mnogo primjera implementacije od nule.

Kao rezultat toga, odabrali smo Patroni za stvaranje failover klastera.

Patroni proces implementacije

Prije Patronija imali smo 12 PostgreSQL shardova u konfiguraciji jednog mastera i jedne replike s asinkronom replikacijom. Aplikacijski poslužitelji su bazama pristupali preko Network Load Balancera iza kojeg su bile dvije instance s PgBouncerom, a iza njih svi PostgreSQL poslužitelji.


Za implementaciju Patronija morali smo odabrati konfiguraciju distribuiranog klastera za pohranu. Patroni radi s distribuiranim sustavima za pohranu konfiguracije kao što su etcd, Zookeeper, Consul. Upravo imamo puni Consul klaster na tržištu, koji radi u sprezi s Vaultom i više ga ne koristimo. Sjajan razlog da počnete koristiti Consul za namjeravanu svrhu.

Kako Patroni radi s Consulom

Imamo klaster Consul, koji se sastoji od tri čvora, i klaster Patroni, koji se sastoji od voditelja i replike (u Patronu se master zove voditelj klastera, a robovi se nazivaju replike). Svaka instanca Patroni klastera konstantno šalje informacije o stanju klastera Consulu. Stoga od Consula uvijek možete saznati trenutnu konfiguraciju Patroni klastera i tko je trenutno vodeći.

Za povezivanje Patronija s Consulom dovoljno je proučiti službenu dokumentaciju u kojoj stoji da morate navesti host u http ili https formatu, ovisno o tome kako radimo s Consulom, te shemu povezivanja, po želji:

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

Izgleda jednostavno, ali ovdje počinju zamke. S Consulom radimo preko sigurne veze putem https-a i naša će konfiguracija veze izgledati ovako:

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

Ali to ne ide. Prilikom pokretanja, Patroni se ne može spojiti na Consul jer svejedno pokušava ići preko http-a.

Izvorni kod Patronija pomogao je u rješavanju problema. Dobro je da je napisano u pythonu. Ispada da se parametar glavnog računala ni na koji način ne analizira, a protokol mora biti naveden u shemi. Ovako kod nas izgleda radni konfiguracijski blok za rad s Consulom:

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

konzul-predložak

Dakle, odabrali smo pohranu za konfiguraciju. Sada moramo razumjeti kako će PgBouncer promijeniti svoju konfiguraciju kada promijeni lidera u klasteru Patroni. U dokumentaciji nema odgovora na ovo pitanje jer. tamo, u principu, rad s PgBouncerom nije opisan.

U potrazi za rješenjem, pronašli smo članak (nažalost se ne sjećam naslova) gdje je pisalo da je Sonsul-template puno pomogao u uparivanju PgBouncera i Patronija. To nas je potaknulo da istražimo kako funkcionira Consul-predložak.

Pokazalo se da Consul-template stalno prati konfiguraciju PostgreSQL klastera u Consulu. Kada se voditelj promijeni, on ažurira konfiguraciju PgBouncera i šalje naredbu za ponovno učitavanje.

Veliki plus predloška je što se pohranjuje kao kod, pa je pri dodavanju novog sharda dovoljno napraviti novi commit i automatski ažurirati predložak, podržavajući princip Infrastructure as code.

Nova arhitektura s Patronom

Kao rezultat toga dobili smo sljedeću shemu rada:


Svi aplikacijski poslužitelji pristupaju balanseru → iza njega stoje dvije instance PgBouncer → na svakoj instanci pokreće se predložak Consul koji nadzire status svakog Patroni klastera i prati relevantnost konfiguracije PgBouncera, koja šalje zahtjeve trenutnom voditelju svakog klastera.

Ručno testiranje

Pokrenuli smo ovu shemu prije pokretanja u malom testnom okruženju i provjerili rad automatskog prebacivanja. Otvorili su ploču, pomaknuli naljepnicu i u tom trenutku “ubili” vođu klastera. U AWS-u je to jednostavno poput gašenja instance putem konzole.

Naljepnica se vratila u roku od 10-20 sekundi, a zatim se ponovno počela normalno pomicati. To znači da je Patroni klaster radio ispravno: promijenio je voditelja, poslao informacije Sonsulu, a Sonsul-template je odmah pokupio te informacije, zamijenio konfiguraciju PgBouncera i poslao naredbu za ponovno učitavanje.

Kako preživjeti pod velikim opterećenjem i zadržati minimalno vrijeme zastoja?

Sve radi savršeno! Ali postoje nova pitanja: Kako će raditi pod velikim opterećenjem? Kako brzo i sigurno uvesti sve u proizvodnju?

Testno okruženje na kojem provodimo testiranje opterećenja pomaže nam odgovoriti na prvo pitanje. Potpuno je identičan proizvodnji u smislu arhitekture i generirao je testne podatke koji su po količini približno jednaki proizvodnji. Odlučili smo jednostavno "ubiti" jednog od PostgreSQL mastera tijekom testa i vidjeti što će se dogoditi. Ali prije toga, važno je provjeriti automatsko rolanje, jer na ovom okruženju imamo nekoliko PostgreSQL shardova, tako da ćemo dobiti izvrsno testiranje konfiguracijskih skripti prije proizvodnje.

Oba zadatka izgledaju ambiciozno, ali imamo PostgreSQL 9.6. Možemo li odmah nadograditi na 11.2?

Odlučili smo to učiniti u 2 koraka: prvo nadograditi na 11.2, zatim pokrenuti Patroni.

PostgreSQL ažuriranje

Za brzo ažuriranje PostgreSQL verzije upotrijebite opciju -k, u kojem se tvrde poveznice stvaraju na disku i nema potrebe kopirati vaše podatke. Na bazama od 300-400 GB ažuriranje traje 1 sekundu.

Imamo puno fragmenata, pa se ažuriranje mora obaviti automatski. Da bismo to učinili, napisali smo Ansible playbook koji umjesto nas upravlja cijelim procesom ažuriranja:

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

Ovdje je važno napomenuti da prije početka nadogradnje morate izvršiti s parametrom --čekkako biste bili sigurni da možete nadograditi. Naša skripta također vrši zamjenu konfiguracija za vrijeme trajanja nadogradnje. Naša skripta završila je za 30 sekundi, što je izvrstan rezultat.

Pokreni Patroni

Da biste riješili drugi problem, samo pogledajte konfiguraciju Patronija. Službeno spremište ima primjer konfiguracije s initdb, koji je odgovoran za pokretanje nove baze podataka kada prvi put pokrenete Patroni. Ali budući da već imamo gotovu bazu podataka, jednostavno smo uklonili ovaj odjeljak iz konfiguracije.

Kad smo počeli instalirati Patroni na već postojeći PostgreSQL klaster i pokrenuti ga, naišli smo na novi problem: oba su poslužitelja startala kao vodeći. Patroni ne zna ništa o ranom stanju klastera i pokušava pokrenuti oba poslužitelja kao dva odvojena klastera s istim imenom. Da biste riješili ovaj problem, morate izbrisati direktorij s podacima na podređenom uređaju:

rm -rf /var/lib/postgresql/

Ovo treba učiniti samo na robu!

Kada se spoji čista replika, Patroni stvara vođu basebackupa i vraća ga u repliku, a zatim sustiže trenutno stanje prema zapisima zida.

Još jedna poteškoća s kojom smo se susreli je da su svi PostgreSQL klasteri prema zadanim postavkama nazvani glavni. Kada svaki klaster ne zna ništa o drugom, to je normalno. Ali kada želite koristiti Patroni, tada svi klasteri moraju imati jedinstven naziv. Rješenje je promijeniti naziv klastera u PostgreSQL konfiguraciji.

test opterećenja

Pokrenuli smo test koji simulira korisničko iskustvo na pločama. Kada je opterećenje doseglo našu prosječnu dnevnu vrijednost, ponovili smo potpuno isti test, isključili smo jednu instancu s vodećim PostgreSQL-om. Automatsko prebacivanje radilo je kako smo očekivali: Patroni je promijenio voditelja, Consul-template je ažurirao konfiguraciju PgBouncera i poslao naredbu za ponovno učitavanje. Prema našim grafikonima u Grafani bilo je jasno da postoje kašnjenja od 20-30 sekundi i mala količina grešaka sa servera povezanih s vezom na bazu podataka. Ovo je normalna situacija, takve vrijednosti su prihvatljive za naš failover i definitivno su bolje od zastoja usluge.

Dovođenje Patronija u proizvodnju

Kao rezultat toga, došli smo do sljedećeg plana:

• Postavite Consul-template na PgBouncer poslužitelje i pokrenite;
• PostgreSQL ažuriranja na verziju 11.2;
• Promijenite naziv klastera;
• Pokretanje klastera Patroni.

U isto vrijeme, naša shema nam omogućuje da napravimo prvu točku gotovo u bilo kojem trenutku, možemo ukloniti svaki PgBouncer iz posla zauzvrat i implementirati i pokrenuti predložak konzula na njemu. Tako smo i učinili.

Za brzu implementaciju koristili smo Ansible, budući da smo sve playbooke već testirali na testnom okruženju, a vrijeme izvršenja pune skripte bilo je od 1,5 do 2 minute za svaki shard. Mogli bismo uvesti sve redom na svaki shard bez zaustavljanja naše usluge, ali bismo morali isključiti svaki PostgreSQL na nekoliko minuta. U ovom slučaju korisnici čiji se podaci nalaze na ovom shardu trenutno ne mogu u potpunosti raditi, a to je za nas neprihvatljivo.

Izlaz iz ove situacije bilo je planirano održavanje koje se provodi svaka 3 mjeseca. Ovo je prozor za planirani rad, kada potpuno gasimo našu uslugu i nadograđujemo naše instance baze podataka. Ostalo je još tjedan dana do sljedećeg prozora, a mi smo odlučili čekati i dalje se pripremati. Tijekom vremena čekanja dodatno smo se osigurali: za svaki PostgreSQL shard podigli smo rezervnu repliku u slučaju nemogućnosti čuvanja najnovijih podataka te smo za svaki shard dodali novu instancu koja bi trebala postati nova replika u klasteru Patroni, kako ne bi izvršio naredbu za brisanje podataka . Sve je to pomoglo smanjiti rizik pogreške.


Ponovno smo pokrenuli našu uslugu, sve je radilo kako treba, korisnici su nastavili raditi, ali na grafovima smo primijetili nenormalno veliko opterećenje Consul servera.


Zašto ovo nismo vidjeli u testnom okruženju? Ovaj problem vrlo dobro ilustrira da je potrebno slijediti princip Infrastructure as code i doraditi cjelokupnu infrastrukturu, od testnih okruženja do proizvodnje. Inače, vrlo je lako dobiti problem koji imamo. Što se dogodilo? Consul se prvo pojavio u produkcijskim, a potom i u testnim okruženjima, kao rezultat toga, u testnim okruženjima, verzija Consula bila je viša nego u produkcijskoj. Samo u jednom od izdanja riješeno je curenje CPU-a pri radu s predloškom konzula. Stoga smo jednostavno ažurirali Consul i tako riješili problem.

Ponovno pokrenite Patroni klaster

No, dobili smo novi problem, za koji nismo ni slutili. Kada ažuriramo Consul, jednostavno uklanjamo Consul čvor iz klastera pomoću naredbe consul leave → Patroni se spaja na drugi Consul poslužitelj → sve radi. Ali kada smo došli do posljednje instance klastera Consul i poslali mu naredbu za izlazak iz konzula, svi klasteri Patroni jednostavno su se ponovno pokrenuli, a u zapisima smo vidjeli sljedeću pogrešku:

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 nije mogao dohvatiti informacije o svom klasteru i ponovno se pokrenuo.

Kako bismo pronašli rješenje, kontaktirali smo autore Patronija putem pitanja na githubu. Predložili su poboljšanja naših konfiguracijskih datoteka:

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

Uspjeli smo replicirati problem u testnom okruženju i tamo smo testirali te opcije, ali nažalost nisu radile.

Problem i dalje ostaje neriješen. Planiramo isprobati sljedeća rješenja:

• Koristite Consul-agent na svakoj instanci Patroni klastera;
• Riješite problem u kodu.

Razumijemo gdje se pogreška dogodila: problem je vjerojatno korištenje zadanog vremenskog ograničenja, koje nije nadjačano kroz konfiguracijsku datoteku. Kada se posljednji Consul poslužitelj ukloni iz klastera, cijeli Consul klaster visi više od jedne sekunde, zbog toga Patroni ne može dobiti status klastera i potpuno ponovno pokreće cijeli klaster.

Srećom, nismo više naišli na pogreške.

Rezultati korištenja Patronija

Nakon uspješnog lansiranja Patronija, dodali smo dodatnu repliku u svaki klaster. Sada u svakom klasteru postoji privid kvoruma: jedan vođa i dvije replike, za sigurnosnu mrežu u slučaju podijeljenog mozga prilikom prebacivanja.


Patroni na proizvodnji radi više od tri mjeseca. Za to vrijeme nam je već uspio pomoći. Nedavno je voditelj jednog od klastera umro u AWS-u, automatski failover je radio i korisnici su nastavili raditi. Patroni je ispunio svoju glavnu zadaću.

Mali sažetak korištenja Patronija:

• Jednostavnost promjena konfiguracije. Dovoljno je promijeniti konfiguraciju na jednoj instanci i ona će se povući na cijeli klaster. Ako je za primjenu nove konfiguracije potrebno ponovno pokretanje, Patroni će vas obavijestiti. Patroni može ponovno pokrenuti cijeli klaster jednom naredbom, što je također vrlo zgodno.
• Automatski failover radi i već nam je uspio pomoći.
• PostgreSQL ažuriranje bez prekida rada aplikacije. Najprije morate ažurirati replike na novu verziju, zatim promijeniti voditelja u klasteru Patroni i ažurirati starog voditelja. U tom slučaju dolazi do potrebnog testiranja automatskog prelaska u grešku.

Izvor: www.habr.com