Failover Cluster PostgreSQL + Patroni. Iskustvo implementacije

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

Imamo veoma opterećenu uslugu: 2,5 miliona korisnika širom svijeta, 50K+ aktivnih korisnika svaki dan. Serveri se nalaze u Amazoneu u jednoj regiji Irske: 100+ različitih servera je stalno u funkciji, od kojih je skoro 50 sa bazama podataka.

Cijela pozadina je velika monolitna Java aplikacija sa stanjem koja održava stalnu websocket vezu s klijentom. Kada više korisnika istovremeno radi na istoj ploči, svi vide promjene u realnom vremenu, jer svaku promjenu upisujemo u bazu podataka. Imamo oko 10 zahtjeva u sekundi u naše baze podataka. Pri vršnom opterećenju u Redis-u pišemo 80-100K zahtjeva u sekundi.

Zašto smo prešli sa Redis-a na PostgreSQL

U početku je naš servis radio sa Redis-om, skladištem ključ/vrijednost koje pohranjuje sve podatke u RAM servera.

Prednosti Redis-a:

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

Nedostaci Redisa za nas:

1. Nema pravih transakcija. Pokušali smo da ih simuliramo na nivou naše aplikacije. Nažalost, ovo 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 i, na kraju, naići ćemo na karakteristike odabrane instance, što u AWS-u zahtijeva zaustavljanje našeg servisa kako bismo promijenili tip instance.
3. Neophodno je stalno održavati nizak nivo latencije, jer. imamo veoma veliki broj zahteva. Optimalni nivo kašnjenja za nas je 17-20 ms. Na nivou od 30-40 ms, dobijamo duge odgovore na zahtjeve naše aplikacije i degradaciju usluge. Nažalost, to nam se dogodilo u septembru 2018. godine, kada je jedna od instanci sa Redis-om iz nekog razloga imala 2 puta više kašnjenja nego inače. Da bismo riješili problem, zaustavili smo uslugu sredinom dana zbog neplaniranog održavanja i zamijenili problematičnu Redis instancu.
4. Lako je doći do nedosljednosti podataka čak i sa manjim greškama u kodu, a zatim potrošiti puno vremena na pisanje koda kako biste ispravili ove podatke.

Uzeli smo u obzir nedostatke i shvatili da moramo prijeći na nešto praktičnije, s normalnim transakcijama i manje ovisnosti o kašnjenju. Proveo istraživanje, analizirao mnoge opcije i izabrao PostgreSQL.

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

Kada smo tek počeli da se krećemo, naša aplikacija je radila direktno sa bazom podataka i pristupala glavnom Redis-u i PostgreSQL-u. PostgreSQL klaster se sastojao od mastera i replike sa asinhronom replikacijom. Ovako je izgledala shema baze podataka:

Implementacija PgBouncer-a

Dok smo se kretali, razvijao se i proizvod: povećao se broj korisnika i broj servera koji su radili sa PostgreSQL-om, a počele su nam nedostajati veze. PostgreSQL kreira poseban proces za svaku vezu i troši resurse. Možete povećati broj konekcija do određene tačke, inače postoji šansa da dobijete neoptimalne performanse baze podataka. Idealna opcija u takvoj situaciji bila bi odabir menadžera veza koji će stajati ispred baze.

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

Postavili smo sljedeću shemu rada: naša aplikacija pristupa jednom PgBouncer-u iza kojeg se nalaze PostgreSQL masteri, a iza svakog mastera je po jedna replika sa asinhronom replikacijom.


U isto vrijeme nismo mogli pohraniti cjelokupnu količinu podataka u PostgreSQL i brzina rada sa bazom podataka nam je bila važna, pa smo počeli s shardovanjem PostgreSQL-a na nivou aplikacije. Gore opisana shema je relativno zgodna za ovo: prilikom dodavanja novog PostgreSQL šarda, dovoljno je ažurirati konfiguraciju PgBouncer-a i aplikacija može odmah raditi s novim šardom.

PgBouncer failover

Ova šema je radila do trenutka kada je jedina instanca PgBouncer umrla. Nalazimo se u AWS-u, gdje se sve instance pokreću na hardveru koji povremeno umire. U takvim slučajevima, instanca jednostavno prelazi na novi hardver i ponovo radi. To se dogodilo sa PgBouncer-om, ali je postao nedostupan. Rezultat ovog pada bila je nedostupnost naše usluge 25 minuta. AWS preporučuje korištenje redundanse na strani korisnika za takve situacije, što u to vrijeme nije bilo implementirano u našoj zemlji.

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

Napravili smo PgBouncer shemu tolerancije grešaka na sljedeći način: svi serveri aplikacija pristupaju Network Load Balancer-u, iza kojeg se nalaze dva PgBouncer-a. Svaki PgBouncer gleda na isti PostgreSQL master svakog šarda. Ako se ponovo dogodi pad AWS instance, sav promet se preusmjerava preko drugog PgBouncer-a. Mrežni balanser opterećenja obezbeđuje AWS.

Ova šema olakšava dodavanje novih PgBouncer servera.

Kreirajte PostgreSQL Failover Cluster

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

Samonapisane skripte

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

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

Cons:

• Master možda nije umro, umjesto toga je možda došlo do mrežnog kvara. Failover, nesvjestan toga, promovirat će repliku u master, dok će stari majstor nastaviti s radom. Kao rezultat toga, dobićemo dva servera u ulozi mastera i nećemo znati koji od njih ima najnovije ažurne podatke. Ova situacija se također naziva podijeljenim mozgom;
• Ostali smo bez odgovora. U našoj konfiguraciji, master i jedna replika, nakon prebacivanja, replika se pomiče na master i više nemamo replike, tako da moramo ručno dodati novu repliku;
• Potrebno nam je dodatno praćenje failover operacije, dok imamo 12 PostgreSQL šarda, što znači da moramo nadgledati 12 klastera. S povećanjem broja dijelova, također morate zapamtiti da ažurirate prelazak na grešku.

Samonapisani prelazak na grešku izgleda veoma komplikovano i zahteva netrivijalnu podršku. Sa jednim PostgreSQL klasterom, ovo bi bila najlakša opcija, ali se ne skalira, pa nam nije prikladna.

Repmgr

Upravitelj replikacije za PostgreSQL klastere, koji može upravljati radom PostgreSQL klastera. Istovremeno, nema automatski prelazak na grešku iz kutije, tako da ćete za rad morati da napišete svoj vlastiti „omotač“ na vrhu gotovog rješenja. Dakle, sve može ispasti još komplikovanije nego sa skriptama koje su sami napisali, tako da Repmgr nismo ni probali.

AWS RDS

Podržava sve što nam treba, zna kako napraviti sigurnosne kopije i održava skup konekcija. Ima automatsko prebacivanje: kada master umre, replika postaje novi master, a AWS mijenja dns zapis u 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

Uz to, AWS RDS je skoro duplo skuplji od cijene regularne instance, što je i bio glavni razlog odustajanja od ovog rješenja.

Patroni

Ovo je python šablon za upravljanje PostgreSQL-om sa dobrom dokumentacijom, automatskim prelaskom na grešku i izvornim kodom na githubu.

Prednosti Patronija:

• Svaki konfiguracioni parametar je opisan, jasno je kako radi;
• Automatski prelazak na grešku radi izvan kutije;
• Napisano na pythonu, a pošto i sami puno pišemo na pythonu, lakše ćemo se nositi s problemima i, možda, čak i pomoći razvoju projekta;
• U potpunosti upravlja PostgreSQL-om, omogućava vam da promijenite konfiguraciju na svim čvorovima klastera odjednom, a ako klaster treba ponovo pokrenuti da bi se primijenila nova konfiguracija, onda se to može učiniti ponovo koristeći Patroni.

Cons:

• Iz dokumentacije nije jasno kako pravilno raditi sa PgBouncer-om. Iako je to teško nazvati minusom, jer je Patronijev zadatak da upravlja PostgreSQL-om, a kako će ići konekcije sa Patronijem je već naš problem;
• Malo je primjera implementacije Patronija na velikim količinama, dok ima mnogo primjera implementacije od nule.

Kao rezultat toga, odabrali smo Patroni da kreiramo klaster za nadilaženje greške.

Patroni proces implementacije

Prije Patronija, imali smo 12 PostgreSQL dijelova u konfiguraciji od jednog mastera i jedne replike s asinhronom replikacijom. Aplikacioni serveri su pristupili bazama podataka preko Network Load Balancer-a, iza kojeg su bile dvije instance sa PgBouncer-om, a iza njih su bili svi PostgreSQL serveri.


Da bismo implementirali Patroni, morali smo odabrati konfiguraciju distribuiranog skladišnog klastera. Patroni radi sa sistemima za skladištenje distribuiranih konfiguracija kao što su etcd, Zookeeper, Consul. Imamo samo punopravni Consul klaster na tržištu, koji radi u sprezi sa Vaultom i više ga ne koristimo. Odličan razlog da počnete koristiti Consul za njegovu namjenu.

Kako Patroni radi sa Konzulom

Imamo Consul klaster, koji se sastoji od tri čvora, i Patroni klaster, koji se sastoji od vođe i replike (u Patroni, master se zove vođa klastera, a slave se nazivaju replike). Svaka instanca klastera Patroni konstantno šalje informacije o stanju klastera Konzulu. Stoga od Consul-a uvijek možete saznati trenutnu konfiguraciju klastera Patroni i ko je trenutno vodeći.

Da povežete Patroni sa Consulom, dovoljno je proučiti zvaničnu dokumentaciju koja kaže da morate navesti host u http ili https formatu, u zavisnosti od toga kako radimo sa Consulom, i šemu povezivanja, opciono:

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. Sa Consulom radimo preko sigurne veze putem https i naša konfiguracija veze će izgledati ovako:

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

Ali to ne radi. Prilikom pokretanja, Patroni se ne može povezati na Consul, jer ionako pokušava proći kroz http.

Izvorni kod Patronija pomogao je u rješavanju problema. Dobro da je napisano na Pythonu. Ispostavilo se da parametar hosta nije raščlanjen ni na koji način, a protokol mora biti specificiran u šemi. Ovako za nas izgleda radni konfiguracijski blok za rad sa Consulom:

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

konzul-šablon

Dakle, odabrali smo skladište za konfiguraciju. Sada moramo razumjeti kako će PgBouncer promijeniti svoju konfiguraciju prilikom promjene lidera u Patroni klasteru. Na ovo pitanje nema odgovora u dokumentaciji, jer. tamo, u principu, rad sa PgBouncer-om nije opisan.

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

Ispostavilo se da Consul-template stalno prati konfiguraciju PostgreSQL klastera u Consulu. Kada se vođa promijeni, ažurira konfiguraciju PgBouncer-a i šalje naredbu za ponovno učitavanje.

Veliki plus šablona je što se pohranjuje kao kod, pa je prilikom dodavanja novog šarda dovoljno napraviti novi urezivanje i automatski ažurirati šablon, podržavajući princip Infrastruktura kao kod.

Nova arhitektura sa Patronijem

Kao rezultat, dobili smo sljedeću shemu rada:


Svi serveri aplikacija pristupaju balanseru → iza njega stoje dvije instance PgBouncer-a → na svakoj instanci se pokreće Consul-template, koji prati status svakog Patroni klastera i prati relevantnost PgBouncer konfiguracije, koja šalje zahtjeve trenutnom lideru svakog klastera.

Ručno testiranje

Pokrenuli smo ovu šemu prije pokretanja u malom testnom okruženju i provjerili rad automatskog prebacivanja. Otvorili su tablu, pomerili nalepnicu i u tom trenutku „ubili“ vođu klastera. U AWS-u, ovo je jednostavno kao isključivanje instance putem konzole.

Naljepnica se vratila u roku od 10-20 sekundi, a zatim se ponovo počela normalno kretati. To znači da je Patroni klaster ispravno radio: promijenio je vođu, poslao informaciju Consulu, a Consul-template je odmah pokupio ove informacije, zamijenio PgBouncer konfiguraciju i poslao naredbu za ponovno učitavanje.

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

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

Testno okruženje na kojem provodimo testiranje opterećenja pomaže nam da odgovorimo na prvo pitanje. Potpuno je identičan proizvodnji u smislu arhitekture i generirao je testne podatke koji su po obimu približno jednaki proizvodnji. Odlučujemo da samo "ubijemo" jednog od PostgreSQL mastera tokom testa i vidimo šta će se desiti. Ali prije toga, važno je provjeriti automatsko rolovanje, jer na ovom okruženju imamo nekoliko PostgreSQL šardova, tako da ćemo dobiti odlično 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, a zatim pokrenuti Patroni.

PostgreSQL ažuriranje

Da biste brzo ažurirali verziju PostgreSQL-a, koristite opciju -k, u kojem se prave veze na disku i nema potrebe za kopiranjem vaših podataka. Na bazi od 300-400 GB, ažuriranje traje 1 sekundu.

Imamo puno fragmenata, tako da ažuriranje mora biti obavljeno automatski. Da bismo to učinili, napisali smo Ansible playbook koji upravlja cijelim procesom ažuriranja za nas:

/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 nego što započnete nadogradnju, morate je izvršiti sa parametrom --checkkako biste bili sigurni da možete nadograditi. Naša skripta također vrši zamjenu konfiguracija za vrijeme trajanja nadogradnje. Naša skripta je završena za 30 sekundi, što je odličan rezultat.

Pokrenite Patroni

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

Kada smo počeli da instaliramo Patroni na već postojeći PostgreSQL klaster i pokrećemo ga, naišli smo na novi problem: oba servera su počela kao vodeći. Patroni ne zna ništa o ranom stanju klastera i pokušava da pokrene oba servera kao dva odvojena klastera sa istim imenom. Da biste riješili ovaj problem, morate izbrisati direktorij s podacima na slave-u:

rm -rf /var/lib/postgresql/

Ovo treba uraditi samo na slaveu!

Kada je čista replika povezana, Patroni pravi vođu baze rezervne kopije i vraća je u repliku, a zatim sustiže trenutno stanje prema evidenciji zida.

Još jedna poteškoća na koju smo naišli je da se svi PostgreSQL klasteri po defaultu nazivaju glavnim. Kada svaki klaster ne zna ništa o drugom, to je normalno. Ali kada želite da koristite Patroni, onda svi klasteri moraju imati jedinstveno ime. Rješenje je promjena naziva klastera u PostgreSQL konfiguraciji.

test opterećenja

Pokrenuli smo test koji simulira korisničko iskustvo na pločama. Kada je opterećenje dostiglo našu prosječnu dnevnu vrijednost, ponovili smo potpuno isti test, isključili smo jednu instancu sa PostgreSQL liderom. Automatsko prebacivanje na grešku je radilo kako smo očekivali: Patroni je promijenio vođu, Consul-template je ažurirao konfiguraciju PgBouncer-a 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 sa vezom na bazu podataka. Ovo je normalna situacija, takve vrijednosti su prihvatljive za naš failover i definitivno su bolje od vremena zastoja usluge.

Dovođenje Patronija u proizvodnju

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

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

U isto vrijeme, naša shema nam omogućava da napravimo prvu tačku gotovo u bilo koje vrijeme, možemo ukloniti svaki PgBouncer s posla naizmjence i postaviti i pokrenuti consul-template na njemu. Tako smo i uradili.

Za brzu implementaciju koristili smo Ansible, budući da smo već testirali sve playbookove u test okruženju, a vrijeme izvršenja pune skripte je bilo od 1,5 do 2 minute za svaki šard. Mogli bismo sve redom izbaciti na svaki šard bez zaustavljanja naše usluge, ali bismo morali da isključimo svaki PostgreSQL na nekoliko minuta. U ovom slučaju, korisnici čiji se podaci nalaze na ovom šardu u ovom trenutku nisu mogli u potpunosti raditi, a to je za nas neprihvatljivo.

Izlaz iz ove situacije je planirano održavanje, koje se obavlja svaka 3 mjeseca. Ovo je prozor za planirani rad, kada potpuno gasimo našu uslugu i nadogradimo instance baze podataka. Do sljedećeg prozora ostalo je još tjedan dana, a mi smo odlučili da samo čekamo i pripremamo se dalje. Za vrijeme čekanja dodatno smo se osigurali: za svaki PostgreSQL shard podigli smo rezervnu repliku u slučaju neuspjeha čuvanja najnovijih podataka i dodali novu instancu za svaki shard, koja bi trebala postati nova replika u Patroni klasteru, kako ne bi izvršili naredbu za brisanje podataka. Sve ovo je pomoglo da se rizik od greške svede na minimum.


Ponovo smo pokrenuli naš servis, sve je radilo kako treba, korisnici su nastavili sa radom, ali na grafikonima smo primijetili nenormalno veliko opterećenje na Consul serverima.


Zašto ovo nismo vidjeli u testnom okruženju? Ovaj problem veoma dobro ilustruje da je neophodno pratiti princip Infrastruktura kao kod i usavršiti celokupnu infrastrukturu, od test okruženja do produkcije. Inače, vrlo je lako doći do problema koji imamo. Šta se desilo? Consul se prvo pojavio u produkcijskom, a zatim na testnim okruženjima, kao rezultat toga, na testnim okruženjima, verzija Consula je bila viša nego na produkcijskoj. Samo u jednom od izdanja riješeno je curenje CPU-a pri radu sa consul-template-om. Stoga smo jednostavno ažurirali Consul i tako riješili problem.

Ponovo pokrenite Patroni klaster

Međutim, 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 povezuje na drugi Consul server → sve radi. Ali kada smo došli do posljednje instance Consul klastera i poslali mu naredbu za napuštanje konzula, svi Patroni klasteri su se jednostavno ponovo pokrenuli, a u zapisnicima smo vidjeli sljedeću greš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 ponovo je pokrenut.

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

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

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

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

• Koristite Consul-agent na svakoj instanci klastera Patroni;
• Popravite problem u kodu.

Razumijemo gdje je došlo do greške: problem je vjerovatno korištenje default timeout-a, koji se ne poništava kroz konfiguracijski fajl. Kada se posljednji Consul server ukloni iz klastera, cijeli Consul klaster visi duže od sekunde, zbog toga Patroni ne može dobiti status klastera i potpuno restartuje cijeli klaster.

Na sreću, više nismo naišli na greš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 lider i dvije replike, za sigurnosnu mrežu u slučaju split-brain prilikom prebacivanja.


Patroni radi na proizvodnji više od tri mjeseca. Za to vrijeme nam je već uspio pomoći. Nedavno je vođa jednog od klastera umro u AWS-u, automatski prelazak na grešku je proradio i korisnici su nastavili da rade. Patroni je ispunio svoj glavni zadatak.

Mali sažetak upotrebe Patronija:

• Lakoća promjena konfiguracije. Dovoljno je promijeniti konfiguraciju na jednoj instanci i ona će se povući na cijeli klaster. Ako je potrebno ponovno pokretanje da bi se primijenila nova konfiguracija, Patroni će vas obavijestiti. Patroni može ponovo pokrenuti ceo klaster sa jednom komandom, što je takođe veoma zgodno.
• Automatsko prebacivanje na grešku radi i već nam je uspjelo pomoći.
• PostgreSQL ažuriranje bez zastoja aplikacije. Prvo morate ažurirati replike na novu verziju, zatim promijeniti vođu u Patroni klasteru i ažurirati stari lider. U tom slučaju dolazi do potrebnog testiranja automatskog prelaska na grešku.

izvor: www.habr.com