Patroni Failure Stories ili Kako srušiti svoj PostgreSQL klaster. Alexey Lesovsky

Patronijev glavni cilj je da obezbedi visoku dostupnost za PostgreSQL. Ali Patroni je samo šablon, a ne gotova alatka (što, generalno, piše u dokumentaciji). Na prvi pogled, nakon što ste konfigurisali Patroni u testnoj laboratoriji, možete videti kakav je to divan alat i kako lako podnosi naše pokušaje da uništimo klaster. Međutim, u praksi u proizvodnom okruženju sve se ne dešava uvek tako lepo i elegantno kao u laboratoriji za testiranje.

Reći ću vam nešto o sebi. Počeo sam kao sistem administrator. Radio u web razvoju. U Data Egretu radim od 2014. Kompanija se bavi konsaltingom u oblasti Postgresa. I mi posebno servisiramo Postgres i radimo sa Postgresom svaki dan, tako da imamo raznovrsnu operativnu ekspertizu.

I krajem 2018. počeli smo polako koristiti Patroni. I stečeno je neko specifično iskustvo. Nekako smo to dijagnosticirali, podesili i došli do naših najboljih praksi. I u ovom izvještaju ću govoriti o njima.

Osim Postgresa, volim Linux. Volim da čačkam i istražujem, volim da sakupljam jezgra. Volim virtuelizaciju, kontejnere, Docker, Kubernetes. Sve me to zanima, jer stare administratorske navike uzimaju svoj danak. Volim da razumijem praćenje. I volim postgres stvari vezane za administraciju, tj. replikaciju, backup. A u slobodno vrijeme pišem u Go. Nisam softverski inženjer, samo pišem u Go za sebe. I to mi pričinjava zadovoljstvo.

• Mislim da mnogi od vas znaju da Postgres nema HA (High Availability) iz kutije. Da biste dobili HA, morate nešto ubaciti, konfigurirati, uložiti trud i dobiti.
• Postoji nekoliko alata i Patroni je jedan od njih, koji rješava HA prilično cool i vrlo dobro. Ali ako sve to stavimo u testnu laboratoriju i pokrenemo, možemo vidjeti da sve funkcionira, možemo reproducirati neke probleme, vidjeti kako ih Patroni servisira. I videćemo da sve to odlično funkcioniše.
• Ali u praksi smo nailazili na različite probleme. I ja ću govoriti o ovim problemima.
• Reći ću vam kako smo to dijagnosticirali, šta smo podesili – da li nam je pomoglo ili nije.

• Neću vam reći kako da instalirate Patroni, jer možete ga proguglati na internetu, možete pogledati konfiguracijske datoteke da shvatite kako sve počinje i kako se konfigurira. Možete razumjeti dijagrame i arhitekture pronalaženjem informacija o njima na Internetu.
• Neću pričati o iskustvima drugih ljudi. Govoriću samo o problemima sa kojima smo se suočili.
• I neću govoriti o problemima koji su izvan Patronija i PostgreSQL-a. Ako, na primjer, postoje problemi vezani za balansiranje kada se naš klaster urušio, neću o tome.

I malo odricanje od odgovornosti prije nego što počnemo s našim izvještajem.

Sve ove probleme sa kojima smo nailazili, imali smo ih u prvih 6-7-8 meseci rada. Vremenom smo došli do sopstvene interne najbolje prakse. I naši problemi su nestali. Dakle, izvještaj je dostavljen prije otprilike šest mjeseci, kada mi je sve bilo svježe u glavi i ja sam se toga savršeno sjećao.

Prilikom pripreme izvještaja, već sam pokupio stare obdukcije i pogledao trupce. I neki od detalja su možda zaboravljeni, ili neki detalji možda nisu u potpunosti istraženi tokom analize problema, pa se u nekim momentima može činiti da problemi nisu u potpunosti razmotreni, ili postoji neka vrsta nedostatak informacija. I zato vas molim da mi oprostite za ovaj trenutak.

Šta je Patroni?

• Ovo je šablon za izgradnju HA. Tako piše u dokumentaciji. I sa moje tačke gledišta, ovo je vrlo ispravno pojašnjenje. Patroni nije srebrni metak koji će riješiti sve vaše probleme, odnosno potrebno je da se potrudite da proradi i bude koristan.
• Ovo je servis agenta koji je instaliran na svakom servisu sa bazom podataka i koji je vrsta init sistema za vaš Postgres. Pokreće Postgres, zaustavlja ga, ponovo pokreće, mijenja konfiguraciju i mijenja topologiju vašeg klastera.
• Shodno tome, da bi se pohranilo stanje klastera, njegov trenutni prikaz, kako izgleda, potrebna je neka vrsta pohrane. I sa ove tačke gledišta, Patroni je krenuo putem čuvanja stanja u eksternom sistemu. To je distribuirani sistem za pohranu konfiguracije. To može biti Etcd, Consul, ZooKeeper ili kubernetes Etcd, tj. jedna od ovih opcija.
• A jedna od karakteristika Patronija je da autofileover dobijate iz kutije, tek nakon što ga podesite. Ako uzmemo Repmgr za poređenje, filer je tu uključen. Sa Repmgr-om dobijamo prebacivanje, ali ako želimo autofileover, onda ga treba dalje konfigurirati. Patroni već ima autofileover iz kutije.
• I ima još mnogo drugih stvari. Na primjer, održavanje konfiguracija, dodavanje novih replika, sigurnosne kopije, itd. Ali ovo je izvan okvira izvještaja, neću o tome govoriti.

I mali rezultat je da je glavni zadatak Patronija da dobro i pouzdano obavi autofileover kako bi naš klaster ostao operativan i aplikacija ne primijeti promjene u topologiji klastera.

Ali kada počnemo koristiti Patroni, naš sistem postaje malo složeniji. Ako smo ranije imali Postgres, onda kada koristimo Patroni dobijamo sam Patroni, dobijamo DCS, gde je stanje pohranjeno. I sve to mora nekako funkcionirati. Dakle, šta se može pokvariti?

Može slomiti:

• Postgres se može pokvariti. To može biti majstor ili replika, jedan od njih može pokvariti.
• Sam Patroni se može pokvariti.
• DCS, gdje je pohranjeno stanje, može pokvariti.
• I mreža se može pokvariti.

Razmotriću sve ove tačke u izveštaju.

Predmete ću razmatrati kako postanu složeniji, a ne sa stanovišta da predmet uključuje mnogo komponenti. I sa stanovišta subjektivnih osjećaja, ovaj kofer mi je bio kompleksan, teško ga je bilo rastaviti...i obrnuto, neki kofer je bio lagan i lako se rastavlja.

A prvi slučaj je najjednostavniji. To je slučaj kada smo uzeli klaster baze podataka i rasporedili naše DCS skladište na istom klasteru. Ovo je najčešća greška. Ovo je greška u građenju arhitekture, odnosno kombinovanja različitih komponenti na jednom mestu.

Dakle, desio se dosije, hajde da shvatimo šta se desilo.

I ovdje nas zanima kada se desio filer. Odnosno, zanima nas ovaj trenutak kada se stanje klastera promijenilo.

Ali filer nije uvijek trenutan, tj. ne traje određenu jedinicu vremena, može se povući. Može biti dugotrajan.

Dakle, ima vrijeme početka i vrijeme završetka, tj. to je kontinuirani događaj. I sve događaje dijelimo u tri intervala: imamo vrijeme prije filera, tokom filera i nakon filera. Odnosno, razmatramo sve događaje u ovoj vremenskoj liniji.

I prije svega, kada se desio filer, tražimo razlog, šta se dogodilo, šta je uzrokovalo ono što je dovelo do filera.

Ako pogledamo trupce, ovo su klasični Patroni trupci. U njima nam govori da je server postao master, a uloga mastera je prešla na ovaj čvor. Ovdje je istaknuto.

Zatim, moramo razumjeti zašto je došlo do filera, tj. koji su se događaji desili zbog kojih se glavna uloga pomjerila s jednog čvora na drugi. A u ovom slučaju sve je jednostavno. Imamo grešku u interakciji sa sistemom pohrane. Majstor je shvatio da ne može da radi sa DCS-om, tj. postoji neki problem sa interakcijom. I kaže da više ne može biti gospodar i daje ostavku. Ova linija "degradirano ja" govori upravo to.

Ako pogledamo događaje koji su prethodili fileru, tamo možemo uočiti upravo razloge koji su predstavljali problem za nastavak rada majstora.

Ako pogledamo Patroni logove, vidjet ćemo da imamo puno grešaka i tajm-auta, tj. Patroni agent ne može raditi sa DCS-om. U ovom slučaju, to je konzul agent, s kojim se komunikacija odvija na portu 8500.

Problem je što Patroni i baza podataka rade na istom hostu. I Consul serveri su pokrenuti na istom čvoru. Stvaranjem opterećenja na serveru, stvorili smo probleme za Consul servere. Nisu mogli normalno komunicirati.

Nakon nekog vremena, kada se opterećenje smanjilo, naš Patroni je ponovo mogao komunicirati s agentima. Normalan rad je nastavljen. I isti Pgdb-2 server je ponovo postao glavni. Odnosno, došlo je do malog prevrtanja, zbog čega se čvor odrekao svojih moći gospodara, a zatim ih ponovo preuzeo, tj. sve se vratilo kako je bilo.

I to se može smatrati lažno pozitivnim, ili se može smatrati da je Patroni sve uradio kako treba. Odnosno, shvatio je da ne može održati stanje klastera i uklonio je svoje ovlaštenje.

I ovdje je problem nastao zbog činjenice da se Consul serveri nalaze na istoj opremi kao i baze podataka. U skladu s tim, svako opterećenje: bilo da se radi o opterećenju diskova ili procesora, također utječe na interakciju s Consul klasterom.

I odlučili smo da ovo ne treba da živi zajedno, izdvojili smo zaseban klaster za Konzula. A Patroni je već radio sa zasebnim konzulom, tj. postojao je poseban klaster Postgres, poseban klaster konzula. Ovo je osnovno uputstvo o tome kako sve te stvari razdvojiti i držati tako da ne žive zajedno.

Alternativno, možete podesiti parametre ttl, loop_wait, retry_timeout, tj. pokušati preživjeti ove kratkoročne vrhove opterećenja povećanjem ovih parametara. Ali ovo nije najprikladnija opcija, jer ovo opterećenje može biti dugotrajno. I jednostavno ćemo preći ove granice ovih parametara. A to možda neće baš pomoći.

Prvi problem, kao što razumete, je jednostavan. Uzeli smo DCS i spojili ga sa bazom i dobili smo problem.

Drugi problem je sličan prvom. Slično je i po tome što opet imamo problema u interakciji sa DCS sistemom.

Ako pogledamo dnevnike, vidjet ćemo da opet imamo grešku u komunikaciji. A Patroni kaže da ne mogu komunicirati sa DCS-om, tako da trenutni master ide u repliku mod.

Stari majstor postaje replika, ovdje Patroni radi kako treba. Pokreće pg_rewind da premota dnevnik transakcija i zatim se poveže sa novim masterom, a zatim uhvati korak sa novim masterom. Ovdje Patroni radi kako treba.

Ovdje moramo pronaći mjesto koje je prethodilo fileru, odnosno one greške koje su uzrokovale pojavu filera. I u tom pogledu, Patroni dnevnici su prilično zgodni za rad. Piše iste poruke u određenim intervalima. A ako krenemo brzo da skrolujemo kroz ove dnevnike, onda ćemo iz logova videti da su se logovi promenili, što znači da su počeli neki problemi. Brzo se vraćamo na ovo mjesto i vidimo šta se dešava.

A u normalnoj situaciji, dnevnici izgledaju otprilike ovako. Vlasnik brave je provjeren. A ako se vlasnik, recimo, promijeni, onda se mogu dogoditi neki događaji na koje Patroni mora odgovoriti. Ali u ovom slučaju smo u redu. Tražimo mjesto gdje su greške počele.

I nakon skrolovanja do tačke u kojoj su se greške počele pojavljivati, vidimo da imamo automatsko preklapanje datoteka. A pošto su naše greške bile vezane za interakciju sa DCS-om i u našem slučaju smo koristili Consul, takođe gledamo Consul logove da vidimo šta se tamo dogodilo.

Kada smo otprilike uporedili vrijeme podnosioca zahtjeva i vrijeme u Consul logs, vidimo da su naši susjedi u Konzulskom klasteru počeli sumnjati u postojanje drugih članova Konzulskog klastera.

A ako pogledate dnevnike drugih konzularnih agenata, također možete vidjeti da se tamo događa neka vrsta kolapsa mreže. I svi članovi klastera Konzula sumnjaju jedni u druge. I to je bio poticaj za filer.

Ako pogledate šta se dešavalo prije ovih grešaka, možete vidjeti da postoje razne vrste grešaka, na primjer, rok, RPC je pao, tj. očito postoji neki problem u međusobnoj interakciji članova Consul klastera.

Najjednostavniji odgovor je popraviti mrežu. Ali, stojeći na podijumu, lako mi je ovo reći. Ali okolnosti su takve da korisnik ne može uvijek priuštiti popravku mreže. Možda živi u DC-u i možda nema mogućnost popravljanja mreže ili utjecaja na opremu. I stoga su potrebne neke druge opcije.

Postoje opcije:

• Najjednostavnija opcija, koja je po mom mišljenju napisana čak iu dokumentaciji, je da se onemoguće Consul provjere, odnosno jednostavno proslijedite prazan niz. I mi kažemo konzulskom agentu da ne koristi nikakve čekove. Zbog ovih provjera, možemo zanemariti ove mrežne oluje i ne pokrenuti filer.
• Druga opcija je da još jednom provjerite raft_multiplier. Ovo je parametar samog Consul servera. Podrazumevano je postavljeno na 5. Ova vrijednost se preporučuje prema dokumentaciji za okruženja za postavljanje. U suštini, ovo utiče na učestalost razmjene poruka između članova mreže konzulata. U suštini, ovaj parametar utiče na brzinu službene komunikacije između članova Konzul klastera. A za proizvodnju se već preporučuje da se smanji kako bi čvorovi češće razmjenjivali poruke.
• Druga opcija koju smo počeli da koristimo bila je povećanje prioriteta procesa Consul među ostalim procesima za planer procesa operativnog sistema. Postoji takav parametar „lepo“, on samo određuje prioritet procesa koji OS planer uzima u obzir prilikom planiranja. Također smo smanjili lijepu vrijednost za konzularne agente, tj. povećao prioritet tako da operativni sistem daje Consul procesima više vremena za rad i izvršavanje svog koda. U našem slučaju to je riješilo naš problem.
• Druga opcija je da ne koristite Consul. Imam prijatelja koji je veliki pristalica Etcd-a. I on i ja se redovno svađamo šta je bolje, itd. ili Konzul. Ali u pogledu toga koji je bolji, on i ja se generalno slažemo da Consul ima agenta koji treba da radi na svakom čvoru baze podataka. Odnosno, Patronijeva interakcija sa Konzul klasterom se odvija preko ovog agenta. I ovaj agent postaje usko grlo. Ako se nešto dogodi agentu, onda Patroni više ne može raditi s Consul klasterom. I ovo je problem. U Etcd planu nema agenta. Patroni može direktno raditi sa listom Etcd servera i već komunicirati s njima. U tom smislu, ako koristite Etcd u svojoj kompaniji, onda će Etcd vjerovatno biti bolji izbor od Consul-a. Ali kod naših kupaca, uvijek smo ograničeni onim što je klijent odabrao i koristi. I uglavnom svi naši klijenti imaju Consul.
• I posljednja stvar je ponovno razmotriti vrijednosti parametara. Ove parametre možemo podići više u nadi da će naši kratkoročni mrežni problemi biti kratki i da neće pasti u opseg ovih parametara. Na ovaj način možemo smanjiti agresivnost Patronija da izvrši autofileover ako se pojave bilo kakvi mrežni problemi.

Mislim da su mnogi koji koriste Patroni upoznati sa ovom komandom.

Ova komanda pokazuje trenutno stanje klastera. I na prvi pogled ova slika može izgledati normalno. Imamo master, imamo repliku, nema kašnjenja u replikaciji. Ali ova slika je normalna sve dok ne znamo da ovaj klaster treba da ima tri čvora, a ne dva.

U skladu s tim, došlo je do automatskog preuzimanja datoteka. I nakon ovog autofileover-a, naša replika je nestala. Moramo otkriti zašto je nestala i vratiti je, obnoviti. I opet idemo na dnevnike i gledamo zašto je došlo do autofileover-a.

U ovom slučaju, druga replika je postala master. Ovde je sve u redu.

I treba da pogledamo repliku koja je otpala i nije u klasteru. Otvaramo Patroni logove i vidimo da smo imali problem u fazi pg_rewind prilikom povezivanja na klaster. Da biste se povezali na klaster, trebate premotati dnevnik transakcija, zatražiti potreban dnevnik transakcija od mastera i koristiti ga za sustizanje glavnog.

U ovom slučaju nemamo dnevnik transakcija i replika se ne može pokrenuti. Shodno tome, zaustavljamo Postgres sa greškom. I zato nije u klasteru.

Moramo razumjeti zašto nije u klasteru i zašto nije bilo dnevnika. Idemo do novog majstora i pogledamo šta ima u svojim zapisnicima. Ispostavilo se da kada je pg_rewind urađen, došlo je do kontrolne tačke. A neki od starih dnevnika transakcija su jednostavno preimenovani. Kada je stari master pokušao da se poveže sa novim masterom i zatraži ove evidencije, oni su već bili preimenovani, jednostavno nisu postojali.

Uporedio sam vremenske oznake kada su se ti događaji dogodili. I tu je razlika doslovno 150 milisekundi, tj. za 369 milisekundi je kontrolna tačka završena, WAL segmenti su preimenovani. I bukvalno na 517, 150 milisekundi kasnije, počelo je premotavanje na staroj replici. Odnosno, bukvalno 150 milisekundi nam je bilo dovoljno da spriječimo da se replika poveže i radi.

Koje su mogućnosti?

U početku smo koristili slotove za replikaciju. Mislili smo da je dobro. Iako smo u prvoj fazi rada onemogućili utore. Činilo nam se da ako se u slotovima nakupi mnogo WAL segmenata, možemo ispustiti master. On će pasti. Patili smo neko vrijeme bez slotova. I shvatili smo da nam trebaju slotovi, vratili smo slotove.

Ali ovdje postoji problem što kada master pređe na repliku, briše utore i, zajedno sa slotovima, briše WAL segmente. I da bismo eliminirali ovaj problem, odlučili smo podići parametar wal_keep_segments. Zadano je 8 segmenata. Podigli smo ga na 1 i pogledali koliko slobodnog prostora imamo. I donirali smo 000 gigabajta za wal_keep_segments. Odnosno, prilikom prebacivanja uvijek imamo rezervu od 16 gigabajta dnevnika transakcija na svim čvorovima.

I plus – ovo je također relevantno za dugoročne zadatke održavanja. Recimo da trebamo ažurirati jednu od replika. I želimo da ga isključimo. Moramo da ažuriramo softver, možda operativni sistem, nešto drugo. A kada isključimo repliku, utor za tu repliku se također uklanja. A ako koristimo male wal_keep_segments, onda ako postoji dugo odsustvo replike, dnevnici transakcija će biti izgubljeni. Pokupićemo repliku, ona će zatražiti te evidencije transakcija na kojima je stala, ali oni možda nisu na masteru. A replika se također neće moći povezati. Zato držimo veliku zalihu časopisa.

Imamo proizvodnu bazu. Projekti tamo već rade.

Došlo je do filera. Ušli smo i pogledali - sve je u redu, replike su na mjestu, nema kašnjenja u replikaciji. Ni u logovima nema grešaka, sve je u redu.

Tim proizvoda kaže da se čini da bi trebalo da postoje neki podaci, ali mi ih vidimo iz jednog izvora, ali ih ne vidimo u bazi podataka. I moramo razumjeti šta im se dogodilo.

Jasno je da ih je pg_rewind izbrisao. To smo odmah shvatili, ali smo otišli da vidimo šta se dešava.

U logovima uvijek možemo pronaći kada je nastao filer, ko je postao master i možemo utvrditi ko je bio stari master i kada je želio da postane replika, tj. ovi logovi su nam potrebni da saznamo količinu dnevnika transakcija koja je bila izgubljen.

Naš stari majstor se ponovo pokrenuo. I Patroni je registrovan u autostartu. Patroni lansiran. Zatim je pokrenuo Postgres. Tačnije, prije pokretanja Postgresa i prije nego što je napravio repliku, Patroni je pokrenuo pg_rewind proces. Shodno tome, on je obrisao neke od dnevnika transakcija, preuzeo nove i povezao se. Ovdje je Patroni odradio odličan posao, odnosno kako i treba. Naš klaster je obnovljen. Imali smo 3 čvora, nakon filera su bila 3 čvora - sve je bilo cool.

Izgubili smo neke podatke. I moramo shvatiti koliko smo izgubili. Tražimo tačno trenutak kada smo imali premotavanje. To možemo saznati iz ovih dnevničkih zapisa. premotavanje je počelo, uradio nešto tamo i završio.

Moramo pronaći poziciju u dnevniku transakcija gdje je stari master stao. U ovom slučaju, to je ova oznaka. I potrebna nam je druga oznaka, odnosno udaljenost po kojoj se stari majstor razlikuje od novog.

Uzimamo uobičajeni pg_wal_lsn_diff i upoređujemo ove dvije oznake. I u ovom slučaju dobijamo 17 megabajta. Da li je ovo mnogo ili malo, svako odlučuje za sebe. Jer za neke 17 megabajta nije puno, za druge je mnogo i neprihvatljivo. Ovdje svako odlučuje za sebe u skladu sa potrebama poslovanja.

Ali šta smo sami otkrili?

Prvo, moramo sami odlučiti - da li nam je uvijek potrebno Patroni autostart nakon ponovnog pokretanja sistema? Češće se dešava da moramo otići kod starog majstora, vidjeti dokle je otišao. Možda pregledajte segmente dnevnika transakcija, vidite šta je tamo. I shvatite da li možemo izgubiti ove podatke ili trebamo pokrenuti stari master u samostalnom načinu rada da bismo dohvatili ove podatke.

I tek nakon toga moramo odlučiti da li možemo odbaciti ove podatke ili ih možemo vratiti, povezati ovaj čvor kao repliku na naš klaster.

Osim toga, postoji parametar “maximum_lag_on_failover”. Podrazumevano, ako me memorija ne vara, ovaj parametar ima vrijednost od 1 megabajta.

Kako on radi? Ako naša replika zaostaje za 1 megabajt podataka u kašnjenju replikacije, onda ova replika ne učestvuje na izborima. A ako se iznenada pojavi filer, Patroni gleda koje replike zaostaju. Ako zaostaju za velikim brojem dnevnika transakcija, ne mogu postati master. Ovo je vrlo dobra sigurnosna funkcija koja vas sprečava da izgubite mnogo podataka.

Ali postoji problem što se kašnjenje replikacije u Patroni i DCS klasteru ažurira u određenom intervalu. Mislim da je 30 sekundi zadana vrijednost ttl.

Shodno tome, može doći do situacije u kojoj je kašnjenje replikacije za replike u DCS-u isto, ali u stvari može postojati potpuno drugačije kašnjenje ili ga uopće nema, tj. ova stvar nije u realnom vremenu. I ne odražava uvijek pravu sliku. I ne vredi davati fensi logiku o tome.

A rizik od gubitka uvijek ostaje. I u najgorem slučaju postoji jedna formula, au prosječnom slučaju druga formula. Odnosno, kada planiramo implementaciju Patronija i procjenjujemo koliko podataka možemo izgubiti, moramo se osloniti na ove formule i približno zamisliti koliko podataka možemo izgubiti.

I ima dobrih vijesti. Kada stari majstor krene naprijed, može se kretati naprijed zbog nekih pozadinskih procesa. Odnosno, postojala je neka vrsta autovakuma, zapisao je podatke i spremio ih u dnevnik transakcija. A te podatke možemo lako zanemariti i izgubiti. Nema problema sa ovim.

A ovako izgledaju dnevnici ako se postavi maksimum_lag_on_failover i dođe do prelaska fajla, a vi trebate odabrati novi master. Replika se ocjenjuje kao nesposobna za učešće na izborima. I odbija da učestvuje u trci za liderstvo. I čeka da se izabere novi gospodar, kako bi se onda mogla povezati s njim. Ovo je dodatna mjera protiv gubitka podataka.

Ovdje je naš proizvodni tim napisao da njihov proizvod ima problema pri radu sa Postgresom. U isto vrijeme, ne možete pristupiti samom masteru, jer nije dostupan preko SSH-a. A ni autofileover se ne dešava.

Ovaj domaćin je bio prisiljen na ponovno pokretanje. Zbog ponovnog pokretanja, došlo je do autofileover-a, iako je bilo moguće napraviti i ručno automatsko prebacivanje datoteka, kako sada razumijem. I nakon ponovnog pokretanja, idemo da vidimo šta smo imali sa trenutnim masterom.

U isto vrijeme, unaprijed smo znali da imamo problema s diskovima, odnosno već smo znali iz praćenja gdje kopati i šta tražiti.

Ušli smo u postgres log i počeli da gledamo šta se tamo dešava. Vidjeli smo urezivanja koja su trajala jednu, dvije ili tri sekunde, što nikako nije normalno. Vidjeli smo da našem autovakumu treba jako dugo i čudno vrijeme da se pokrene. I vidjeli smo privremene datoteke na disku. Odnosno, sve su to pokazatelji problema s diskovima.

Pogledali smo u sistemski dmesg (dnevnik nuklearnih poruka). I vidjeli smo da imamo problema sa jednim od diskova. Diskovni podsistem je bio softverski Raid. Pogledali smo /proc/mdstat i vidjeli da nam nedostaje jedan disk. To jest, postoji Raid od 8 diskova, nedostaje nam jedan. Ako pažljivo pogledate slajd, možete vidjeti u izlazu da tamo nemamo sde. Naš disk je, relativno govoreći, ispao. To je izazvalo probleme s diskom, a aplikacije su također imale probleme pri radu sa Postgres klasterom.

I u ovom slučaju, Patroni nam ne bi ništa pomogao, jer Patroni nema zadatak da prati stanje servera, stanje diska. I takve situacije moramo pratiti vanjskim nadzorom. Eksternom nadzoru smo dodali nadzor operativnog diska.

I postojala je ova misao - može li nam pomoći softver za mačevanje ili čuvar? Mislili smo da je malo vjerovatno da bi nam on pomogao u ovom slučaju, jer je tokom problema Patroni nastavio interakciju sa DCS klasterom i nije vidio nikakav problem. Odnosno, sa stanovišta DCS-a i Patronija, sve je bilo u redu sa klasterom, iako je u stvari bilo problema sa diskom, bilo je problema sa dostupnošću baze podataka.

Po mom mišljenju, ovo je jedan od najčudnijih problema koji sam istraživao jako dugo, ponovo čitao mnogo dnevnika, petljao po njemu i nazvao ga simulatorom klastera.

Problem je bio što stari master nije mogao postati normalna replika, tj. Patroni ju je pokrenuo, Patroni je pokazao da je ovaj čvor prisutan kao replika, ali u isto vrijeme nije normalna replika. Sada ćete vidjeti zašto. Zadržao sam ovo od analize tog problema.

I gdje je sve počelo? Počelo je, kao i kod prethodnog problema, sa disk kočnicama. Imali smo urezivanja sekundu po sekundu, dvije odjednom.

Došlo je do prekida veze, odnosno prekida veze klijenata.

Bilo je blokada različite težine.

I, shodno tome, diskovni podsistem nije baš osjetljiv.

A najmisterioznija stvar za mene je zahtjev za momentalno gašenje koji je stigao. Postgres ima tri načina isključivanja:

• Lijepo je kada čekamo da se svi klijenti sami prekinu.
• Postoji brzo, kada prisilimo klijente da prekinu vezu jer ćemo se isključiti.
• I odmah. U ovom slučaju, immediate čak ni ne govori klijentima da se ugase, već se samo gasi bez upozorenja. I operativni sistem šalje RST poruku svim klijentima (TCP poruka da je veza prekinuta i da klijent nema više šta da uhvati).

Ko je poslao ovaj signal? Pozadina Postgres procesi ne šalju takve signale jedni drugima, tj. ovo je kill-9. Oni to ne šalju jedni drugima, oni samo reaguju na ovo, tj. ovo je hitno ponovno pokretanje Postgresa. Ne znam ko ga je poslao.

Pogledao sam naredbu “last” i vidio sam jednu osobu koja se također prijavila na ovaj server sa nama, ali mi je bilo neugodno postaviti pitanje. Možda je bilo ubistvo -9. Vidio bih kill -9 u evidenciji, jer... Postgres kaže da je prihvatio kill -9, ali ja to nisam vidio u evidenciji.

Gledajući dalje, vidio sam da Patroni nije pisao u dnevnik dosta dugo - 54 sekunde. A ako uporedite dvije vremenske oznake, nije bilo poruka oko 54 sekunde.

I za to vrijeme došlo je do autofileover-a. Patroni je opet odlično radio ovdje. Naš stari majstor je bio nedostupan, nešto mu se dešavalo. I počeo je izbor novog gospodara. Ovdje je sve dobro funkcioniralo. Naš pgsql01 je postao naš novi lider.

Imamo repliku koja je postala majstor. A postoji i druga replika. I bilo je problema sa drugom napomenom. Pokušala je da se rekonfiguriše. Koliko sam shvatio, pokušala je promijeniti recovery.conf, restartovati Postgres i povezati se na novi master. Svakih 10 sekundi šalje poruke koliko pokušava, ali ne uspijeva.

I tokom ovih pokušaja, do starog mastera stiže signal trenutnog isključivanja. Master se ponovo pokreće. I oporavak se zaustavlja jer stari master ide u ponovno pokretanje. To jest, replika se ne može povezati s njom jer je u isključenom načinu rada.

U nekom trenutku je uspjelo, ali replikacija nije počela.

Jedina hipoteza koju imam je da recovery.conf sadrži adresu starog mastera. A kada se pojavio novi master, druga replika je i dalje pokušavala da se poveže sa starim masterom.

Kada je Patroni pokrenuo drugu repliku, čvor se pokrenuo, ali se nije mogao povezati putem replikacije. I formirao se kašnjenje replikacije, koje je izgledalo otprilike ovako. Odnosno, sva tri čvora su bila na svom mjestu, ali je drugi čvor zaostajao.

U isto vrijeme, ako pogledate zapisnike koji su napisani, mogli ste vidjeti da replikacija ne može započeti jer su dnevnici transakcija različiti. A evidencije transakcija koje nudi čarobnjak, a koje su navedene u recovery.conf, jednostavno nisu prikladne za naš trenutni čvor.

I tu sam napravio grešku. Morao sam da dođem da vidim šta ima u recovery.conf da testiram svoju hipotezu da se povezujemo sa pogrešnim masterom. Ali ja sam tada tek skontao i nije mi palo na pamet, ili sam vidio da replika zaostaje i da će se morati dopuniti, tj. nekako sam to nehajno razradio. Ovo je bio moj dovratak.

Nakon 30 minuta je stigao admin, tj. restartovao sam Patroni na replici. Već sam odustao od njega, mislio sam da će ga morati dopuniti. I pomislio sam, ponovo ću pokrenuti Patronija, možda će nešto dobro ispasti. Oporavak je počeo. I baza se čak otvorila, bila je spremna da prihvati veze.

Replikacija je počela. Ali minut kasnije se srušio uz grešku da dnevnici transakcija nisu prikladni za njega.

Mislio sam ponovo pokrenuti. Ponovo sam pokrenuo Patroni i nisam ponovo pokrenuo Postgres, već sam ponovo pokrenuo Patroni u nadi da će magično pokrenuti bazu podataka.

Replikacija je ponovo počela, ali bilješke u dnevniku transakcija su bile drugačije, nisu bile iste kao one koje su bile u prethodnom pokušaju pokretanja. Replikacija je ponovo zaustavljena. I poruka je bila malo drugačija. I nije mi bilo posebno informativno.

I onda mi padne na pamet - šta ako restartujem Postgres, u ovom trenutku napravim kontrolnu tačku na trenutnom masteru kako bih pomjerio tačku u dnevniku transakcija malo naprijed tako da oporavak počne od drugog trenutka? Osim toga, još smo tamo imali rezerve WAL-a.

Ponovo sam pokrenuo Patroni, napravio par kontrolnih tačaka na masteru, par tačaka ponovnog pokretanja na replici kada se otvorila. I pomoglo je. Dugo sam razmišljao zašto mi pomaže i kako djeluje. I replika je počela. I replikacija više nije uspjela.

Ovaj problem je za mene jedan od tajanstvenijih, nad kojim se još uvijek pitam šta se zapravo tamo dogodilo.

Koji su zaključci ovdje? Patroni može raditi kako je predviđeno i bez ikakvih grešaka. Ali u isto vrijeme, to nije 100% garancija da je kod nas sve u redu. Replika se može pokrenuti, ali može biti u poluradnom stanju, a aplikacija ne može raditi s takvom replikom, jer će tamo biti starih podataka.

I nakon fileover-a uvijek trebamo provjeriti da li je sve u redu sa klasterom, tj. imamo potreban broj replika i nema kašnjenja u replikaciji.

I dok budemo razmatrali ove probleme, ja ću formulisati preporuke. Pokušao sam ih spojiti u dva slajda. Vjerovatno su se sve priče mogle spojiti u dva slajda i samo ih ispričati.

Kada koristite Patroni, morate imati nadzor. Uvijek biste trebali znati kada je došlo do autofileover, jer ako ne znate da ste imali autofileover, nemate kontrolu nad klasterom. I to je loše.

Nakon svakog filera, uvijek bismo trebali ručno provjeriti klaster. Moramo se pobrinuti da uvijek imamo ažuran broj replika, da nema kašnjenja u replikaciji i da nema grešaka u evidencijama koje se odnose na streaming replikaciju, Patroni ili DCS sistem.

Automatizacija može uspješno raditi, Patroni je jako dobar alat. Možda radi, ali neće dovesti klaster u željeno stanje. A ako ne znamo za to, onda ćemo imati problema.

A Patroni nije srebrni metak. Još uvijek moramo razumjeti kako Postgres funkcionira, kako funkcionira replikacija i kako Patroni radi sa Postgresom i kako se ostvaruje komunikacija između čvorova. To je neophodno kako biste mogli riješiti probleme sa svojim rukama.

Kako pristupiti pitanju dijagnoze? Dogodilo se da radimo sa različitim klijentima i niko nema ELK stack, a mi moramo razumjeti logove tako što ćemo otvoriti 6 konzola i 2 taba. U jednoj kartici se nalaze Patroni logovi za svaki čvor, na drugoj kartici se nalaze Consul logovi, ili Postgres logovi ako je potrebno. Veoma je teško postaviti dijagnozu.

Koje sam pristupe razvio? Prvo, uvijek pogledam kada je filer stigao. A za mene je ovo svojevrsna prekretnica. Gledam šta se dogodilo prije filera, tokom filera i nakon filera. Fileover ima dvije oznake: ovo je vrijeme početka i završetka.

Zatim u logovima gledam događaje prije filera, koji su prethodili fileru, tj. tražim razloge zašto se filer dogodio.

I ovo daje sliku razumijevanja onoga što se dogodilo i šta se može učiniti u budućnosti da se spriječi pojavljivanje takvih okolnosti (i kao rezultat toga, ne dolazi do preuzimanja datoteka).

A gdje obično gledamo? Gledam:

• Prvo na Patroni dnevnike.
• Zatim gledam Postgres logove ili DCS dnevnike, ovisno o tome šta je pronađeno u Patroni logovima.
• A sistemski dnevnici također ponekad daju razumijevanje o tome šta je uzrokovalo filer.

Kako se osjećam prema Patroni? Osećam se veoma dobro zbog Patronija. Po mom mišljenju, ovo je nešto najbolje što postoji danas. Znam mnoge druge proizvode. To su Stolon, Repmgr, Pg_auto_failover, PAF. 4 alata. Sve sam ih probao. Patroni mi se najviše dopao.

Ako me pitaju: “Da li preporučujem Patroni?” Reći ću da, jer mi se sviđa Patroni. I mislim da sam naučio da ga kuvam.

Ako ste zainteresovani da vidite koji su jos problemi sa Patronijem, pored problema koje sam izneo, uvek mozete da odete na stranicu pitanja na GitHubu. Postoji mnogo različitih priča i tamo se raspravlja o mnogim zanimljivim problemima. I kao rezultat toga, neke greške su uvedene i riješene, odnosno ovo je zanimljivo čitanje.

Postoje zanimljive priče o ljudima koji su pucali sebi u nogu. Vrlo informativno. Pročitali ste i shvatili da ne morate ovo da radite. Označio sam sebe.

I želim da kažem veliko hvala kompaniji Zalando na razvoju ovog projekta, odnosno Aleksandru Kukuškinu i Alekseju Kljukinu. Alexey Klyukin je jedan od koautora, on više ne radi u Zalandu, ali ovo su dvoje ljudi koji su počeli raditi s ovim proizvodom.

I mislim da je Patroni veoma kul stvar. Drago mi je da postoji, zanimljivo je biti sa njom. I puno hvala svim saradnicima koji pišu zakrpe za Patroni. Nadam se da će Patroni s godinama postati zreliji, hladniji i sposobniji. Već je efikasan, ali nadam se da će postati još bolji. Dakle, ako planirate da koristite Patroni u svom domu, ne bojte se. Ovo je dobro rješenje, može se implementirati i koristiti.

To je sve. Ako imate pitanja, pitajte.

Vaša pitanja

Hvala na izvještaju! Ako nakon filera i dalje morate pažljivo pogledati, zašto nam je onda potreban automatski filer?

Jer je to nova stvar. Sa njom radimo tek godinu dana. Bolje je igrati na sigurno. Želimo da uđemo i vidimo da je sve zaista funkcionisalo kako treba. Ovo je nivo nepovjerenja odraslih - bolje je još jednom provjeriti i vidjeti.

Na primjer, došli smo jutros i pogledali, zar ne?

Ne ujutro, obično saznamo za autofileover skoro odmah. Primamo obavještenja, vidimo da je došlo do autofileover. Gotovo odmah ulazimo i razgledamo. Ali sve te provjere moraju biti dovedene na nivo monitoringa. Ako pristupite Patroni preko REST API-ja, postoji istorija. Koristeći istoriju, možete pogledati vremenske oznake kada je datoteka preuzeta. Na osnovu toga se može vršiti monitoring. Možete pogledati istoriju da vidite koliko je događaja bilo. Ako imamo više događaja, to znači da se dogodio autofileover. Možete otići i pogledati. Ili je naša automatizacija praćenja provjerila da imamo sve replike na mjestu, da nema kašnjenja i da je sve u redu.

Hvala vam!

Hvala puno na odličnoj priči! Ako smo DCS klaster pomerili negde daleko od Postgres klastera, da li i ovaj klaster treba periodično da se servisira? Koje su najbolje prakse u tome da neke dijelove DCS klastera treba isključiti, nešto učiniti s njima itd.? Kako živi cijela ova struktura? I kako da uradim ove stvari?

Za jednu kompaniju bilo je potrebno kreirati matricu problema šta se dešava ako jedna ili više komponenti zakaže. Koristeći ovu matricu, uzastopno prolazimo kroz sve komponente i gradimo scenarije u slučaju kvara ovih komponenti. U skladu s tim, za svaki scenarij kvara možete imati akcioni plan za oporavak. A u slučaju DCS-a, ovo dolazi kao dio standardne infrastrukture. A administrator to administrira, a mi se već oslanjamo na administratore koji to administriraju i na njegovu sposobnost da to popravi u slučaju katastrofe. Ako DCS uopšte nema, onda ga postavljamo, ali ga posebno ne pratimo, jer nismo odgovorni za infrastrukturu, ali dajemo preporuke kako i šta da pratimo.

Odnosno, da li sam dobro shvatio da moram onemogućiti Patroni, onemogućiti filer, onemogućiti sve prije nego što radim bilo šta sa hostovima?

Zavisi koliko čvorova imamo u DCS klasteru. Ako postoji mnogo čvorova i ako onemogućimo samo jedan od čvorova (repliku), tada se u klasteru održava kvorum. A Patroni ostaje operativan. I ništa se ne aktivira. Ako imamo neke složene operacije koje utiču na više čvorova, čiji bi nedostatak mogao uništiti kvorum, onda da, možda ima smisla pauzirati Patroni. Ima odgovarajuću komandu - patronictl pause, patronictl resume. Jednostavno ga pauziramo, a autofileover trenutno ne radi. Održavamo DCS klaster, zatim uklanjamo pauzu i nastavljamo sa životom.

Puno vam hvala!

Hvala vam puno na izvještaju! Kako se tim proizvoda osjeća u vezi s gubitkom podataka?

Timove za proizvode nije briga, ali vođe tima su zabrinuti.

Koje garancije postoje?

Vrlo je teško sa garancijama. Alexander Kukushkin ima izvještaj “Kako izračunati RPO i RTO”, odnosno vrijeme oporavka i koliko podataka možemo izgubiti. Mislim da moramo pronaći ove slajdove i proučiti ih. Koliko se sjećam, postoje konkretni koraci kako izračunati ove stvari. Koliko transakcija možemo izgubiti, koliko podataka možemo izgubiti. Kao opciju, možemo koristiti sinkronu replikaciju na Patroni nivou, ali ovo je mač sa dvije oštrice: ili imamo pouzdanost podataka ili gubimo brzinu. Postoji sinhrona replikacija, ali isto tako ne garantuje 100% zaštitu od gubitka podataka.

Alexey, hvala na divnom izvještaju! Ima li iskustva u korištenju Patronija za zaštitu nultog nivoa? Odnosno, u kombinaciji sa sinhronim stanjem pripravnosti? Ovo je prvo pitanje. I drugo pitanje. Koristili ste različita rješenja. Koristili smo Repmgr, ali bez autofileover i sada planiramo da omogućimo autofileover. A Patroni smatramo alternativnim rješenjem. Koje su prednosti u odnosu na Repmgr?

Prvo pitanje se odnosilo na sinhrone replike. Niko ovdje ne koristi sinhronu replikaciju, jer su svi uplašeni (nekoliko klijenata je već koristi, uopće nisu primijetili probleme s performansama - Napomena govornika). Ali mi smo za sebe razvili pravilo da u klasteru sinkrone replikacije moraju biti najmanje tri čvora, jer ako imamo dva čvora i ako master ili replika zakaže, onda Patroni ovaj čvor prebacuje u samostalni način rada kako bi aplikacija nastavila raditi. rad. U tom slučaju postoji rizik od gubitka podataka.

Što se tiče drugog pitanja, koristili smo Repmgr i još uvijek radimo za neke klijente iz istorijskih razloga. šta možemo reći? U Patroni, autofileover dolazi iz kutije; u Repmgr, autofileover dolazi kao dodatna funkcija koju treba omogućiti. Moramo pokrenuti Repmgr demon na svakom čvoru i onda možemo konfigurirati autofileover.

Repmgr provjerava da li su Postgres čvorovi živi. Repmgr procesi međusobno provjeravaju postojanje, to nije baš efikasan pristup jer Mogu postojati složeni slučajevi izolacije mreže u kojima se veliki Repmgr klaster može razbiti na nekoliko malih i nastaviti s radom. Repmgr nisam pratio dugo, možda je ovo popravljeno... ili možda nije. Ali prenošenje informacija o stanju klastera u DCS, kao što to čine Stolon i Patroni, je najizvodljivija opcija.

Alexey, imam jedno pitanje koje bi moglo biti glupo. U jednom od prvih primjera, premjestili ste DCS sa lokalne mašine na udaljeni čvor. Razumijemo da je mreža stvar koja ima svoje karakteristike, ona živi sama za sebe. A šta se dešava ako iz nekog razloga DCS klaster postane nedostupan? Neću govoriti o razlozima, može ih biti mnogo: od krivih ruku mreža do pravih problema.

Nisam to rekao naglas, ali DCS klaster takođe mora biti otporan na greške, što znači da ima neparan broj čvorova da bi se pojavio kvorum. Šta se događa ako DCS klaster postane nedostupan ili se ne može postići kvorum, tj. neka vrsta podjele mreže ili kvara čvora? U ovom slučaju, Patroni klaster prelazi u način rada samo za čitanje. Patroni klaster ne može odrediti stanje klastera i šta da radi. Ne može kontaktirati DCS i tamo spremiti novo stanje klastera, tako da cijeli klaster prelazi u mod samo za čitanje. I čeka ili na ručnu intervenciju operatera ili da se DCS vrati.

Grubo govoreći, DCS postaje važan servis za nas kao i sama baza podataka?

Da da. U mnogim modernim kompanijama Service Discovery je sastavni dio infrastrukture. Implementira se i prije nego što je postojala i baza podataka u infrastrukturi. Relativno govoreći, pokrenuli smo infrastrukturu, rasporedili je u DC i odmah imamo Service Discovery. Ako je ovo Consul, onda se na njemu može izgraditi DNS. Ako je ovo Etcd, onda može postojati dio iz Kubernetes klastera u kojem će sve ostalo biti raspoređeno. Čini mi se da je Service Discovery već sastavni dio moderne infrastrukture. I o tome razmišljaju mnogo ranije nego o bazama podataka.

Hvala vam!

izvor: www.habr.com