Patronijeve priče o neuspjesima ili kako srušiti vaš PostgreSQL klaster. Aleksej Lesovski

Patronijev glavni cilj je osigurati visoku dostupnost za PostgreSQL. Ali Patroni je samo predložak, a ne gotov alat (što, općenito, kaže dokumentacija). Na prvi pogled, nakon konfiguracije Patronija u testnom laboratoriju, možete vidjeti kako je to divan alat i kako se lako nosi s našim pokušajima da uništimo klaster. Međutim, u praksi u proizvodnom okruženju ne događa se uvijek sve tako lijepo i elegantno kao u ispitnom laboratoriju.

Reći ću vam nešto o sebi. Počeo sam kao sistemski administrator. Radio u web razvoju. U Data Egretu radim od 2014. Tvrtka se bavi savjetovanjem u području Postgresa. Mi posebno servisiramo Postgres i radimo s Postgresom svaki dan, tako da imamo različita operativna stručnost.

I krajem 2018. počeli smo polako koristiti Patroni. A skupilo se i određeno iskustvo. Nekako smo ga dijagnosticirali, ugodili i došli do naših najboljih praksi. I u ovom izvješću govorit ću o njima.

Osim Postgresa, volim Linux. Volim čeprkati i istraživati, volim skupljati jezgre. Volim virtualizaciju, kontejnere, Docker, Kubernetes. Sve me to zanima, jer stare admin navike uzimaju danak. Volim razumijevanje praćenja. I volim postgres stvari vezane uz administraciju, tj. replikaciju, backup. A u slobodno vrijeme pišem u Go-u. Nisam softverski inženjer, samo pišem u Go za sebe. I čini mi zadovoljstvo.

• Mislim da mnogi od vas znaju da Postgres nema HA (High Availability) izvan kutije. Da biste dobili HA, morate nešto uložiti, konfigurirati, uložiti trud i dobiti.
• Postoji nekoliko alata, a Patroni je jedan od njih, koji prilično cool i vrlo dobro rješava HA. Ali ako sve to stavimo u testni laboratorij i pokrenemo, možemo vidjeti da sve radi, možemo reproducirati neke probleme, vidjeti kako ih Patroni servisira. I vidjet ćemo da sve radi odlično.
• Ali u praksi smo se susreli s različitim problemima. I ja ću govoriti o tim problemima.
• Reći ću vam kako smo to dijagnosticirali, što smo podesili - je li nam pomoglo ili nije pomoglo.

• Neću vam reći kako instalirati Patroni, jer to možete guglati na Internetu, možete pogledati konfiguracijske datoteke da shvatite kako sve počinje i kako se konfigurira. Dijagrame i arhitekture možete razumjeti pronalaženjem informacija o tome na internetu.
• O tuđim iskustvima neću. Govorit ću samo o problemima s kojima smo se suočavali.
• I neću govoriti o problemima koji su izvan Patronija i PostgreSQL-a. Ako, na primjer, postoje problemi oko balansiranja kad nam se klaster srušio, o tome neću govoriti.

I malo odricanje od odgovornosti prije nego što započnemo naše izvješće.

Sve ove probleme s kojima smo se susretali, imali smo ih u prvih 6-7-8 mjeseci rada. S vremenom smo došli do vlastite interne najbolje prakse. I naši su problemi nestali. Dakle, prijava je predana prije nekih šest mjeseci, kada mi je sve to bilo svježe u glavi i kada sam se svega savršeno sjećao.

Tijekom pripreme izvješća već sam pokupio stare obdukcije i pogledao zapisnike. A neki detalji su možda zaboravljeni, ili neki detalji možda nisu u potpunosti istraženi tijekom analize problema, pa se u nekim trenucima može činiti da problemi nisu u potpunosti razmotreni, ili postoji neka vrsta nedostatak informacija. I zato te molim da mi oprostiš za ovaj trenutak.

Što je Patroni?

• Ovo je predložak za izgradnju HA. Tako piše u dokumentaciji. I s moje točke gledišta, ovo je vrlo ispravno pojašnjenje. Patroni nije srebrni metak koji će riješiti sve vaše probleme, odnosno morate se potruditi da počne raditi i biti koristan.
• Ovo je agentski servis koji se instalira na svaki servis s bazom podataka, a koji je neka vrsta init sustava za vaš Postgres. Pokreće Postgres, zaustavlja ga, ponovno pokreće, mijenja konfiguraciju i mijenja topologiju vašeg klastera.
• Sukladno tome, da bi se pohranilo stanje klastera, njegov trenutni prikaz, kako izgleda, potrebna je neka vrsta pohrane. I s ove točke gledišta, Patroni je krenuo putem pohranjivanja stanja u vanjski sustav. To je distribuirani sustav za pohranu konfiguracije. To može biti Etcd, Consul, ZooKeeper ili kubernetes Etcd, tj. jedna od ovih opcija.
• A jedna od značajki Patronija je da autofileover dobivate iz kutije, tek nakon što ga postavite. Ako uzmemo Repmgr za usporedbu, filer je tu uključen. Uz Repmgr dobivamo prebacivanje, ali ako želimo autofileover, onda ga treba dodatno konfigurirati. Patroni već ima automatski fileover izvan kutije.
• I ima još puno drugih stvari. Na primjer, održavanje konfiguracija, dodavanje novih replika, sigurnosne kopije itd. Ali to je izvan okvira izvješća, neću o tome govoriti.

A mali rezultat je da je glavni zadatak Patronija napraviti autofileover kvalitetno i pouzdano kako bi naš klaster ostao operativan i aplikacija ne bi primijetila promjene u topologiji klastera.

Ali kada počnemo koristiti Patroni, naš sustav postaje malo složeniji. Ako smo ranije imali Postgres, tada kada koristimo Patroni dobivamo sam Patroni, dobivamo DCS, gdje se pohranjuje stanje. I sve to nekako mora funkcionirati. Stoga, što se može slomiti?

Može prekinuti:

• Postgre se može pokvariti. To može biti master ili replika, jedno od njih može zakazati.
• Sam Patroni se može pokvariti.
• DCS, gdje je pohranjeno stanje, može se pokvariti.
• I mreža može puknuti.

Sve ću te točke razmotriti u izvješću.

Slučajeve ću razmatrati kako budu postajali složeniji, a ne sa stajališta da slučaj uključuje mnoge komponente. I sa stajališta subjektivnih osjećaja, ovaj slučaj mi je bio složen, teško ga je bilo rastaviti... i obrnuto, neki slučaj je bio lagan i lako se rastavio.

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

Dakle, dogodio se filer, idemo shvatiti što se dogodilo.

I ovdje nas zanima kada je došlo do filera. Odnosno, zanima nas ovaj trenutak u vremenu 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. kontinuirani je događaj. A sve događaje dijelimo u tri intervala: imamo vrijeme prije filera, tijekom filera i nakon filera. Odnosno, uzimamo u obzir sve događaje na ovoj vremenskoj liniji.

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

Ako gledamo cjepanice, to su klasične Patroni cjepanice. U njima nam govori da je poslužitelj 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 dogodili zbog kojih se glavna uloga pomaknula s jednog čvora na drugi. A u ovom slučaju sve je jednostavno. Imamo pogrešku u interakciji sa sustavom za pohranu. Majstor je shvatio da ne može raditi s DCS-om, tj. postoji problem s interakcijom. A on kaže da više ne može biti majstor i daje ostavku. Ovaj redak "degradiran ja" govori upravo to.

Pogledamo li događaje koji su prethodili fileru, tu možemo uočiti upravo razloge koji su bili problem za nastavak magistarskog rada.

Ako pogledamo zapisnike Patronija, vidjet ćemo da imamo puno grešaka i isteka vremena, tj. agent Patronija ne može raditi s DCS-om. U ovom slučaju, to je Consul agent, s kojim se komunikacija odvija na portu 8500.

A problem je u tome što Patroni i baza podataka rade na istom hostu. I Consul serveri su pokrenuti na istom čvoru. Opterećenjem poslužitelja stvorili smo probleme Consul poslužiteljima. Nisu mogli normalno komunicirati.

Nakon nekog vremena, kada se opterećenje smanjilo, naš Patroni ponovno je mogao komunicirati s agentima. Nastavljen je normalan rad. I isti Pgdb-2 poslužitelj ponovno je postao glavni. Odnosno, došlo je do malog preokreta, zbog kojeg se čvor odrekao svojih ovlasti gospodara, a zatim ih ponovno preuzeo, tj. sve se vratilo na staro.

I to se može smatrati lažno pozitivnim ili se može smatrati da je Patroni sve napravio kako treba. Odnosno, shvatio je da ne može održati stanje klastera i skinuo mu je ovlasti.

I tu je problem nastao zbog činjenice da se Consul serveri nalaze na istoj opremi kao i baze podataka. Sukladno tome, svako opterećenje: bilo opterećenje diskova ili procesora, također utječe na interakciju s klasterom Consul.

I odlučili smo da ovo ne bi trebalo živjeti zajedno, dodijelili smo zaseban klaster za Consul. A Patroni je već radio s posebnim Consulom, tj. postojao je zasebni klaster Postgres, zasebni klaster Consul. Ovo je osnovna uputa kako odvojiti i držati sve te stvari da ne žive zajedno.

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

Prvi je problem, kao što razumijete, jednostavan. Uzeli smo DCS i spojili ga s bazom, i imali smo problem.

Drugi problem je sličan prvom. Slično je utoliko što opet imamo problema u interakciji s DCS sustavom.

Pogledamo li zapisnike, vidjet ćemo da opet imamo grešku u komunikaciji. A Patroni kaže da ne mogu komunicirati s DCS-om, pa trenutni master ide u način replike.

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

Ovdje moramo pronaći mjesto koje je prethodilo fileru, tj. one greške koje su uzrokovale pojavu filera. I u tom smislu, Patroni dnevnici su prilično praktični za rad. Piše iste poruke u određenim intervalima. I ako počnemo brzo listati kroz te zapisnike, tada ćemo iz zapisa vidjeti da su se zapisnici promijenili, što znači da su počeli neki problemi. Brzo se vraćamo na ovo mjesto i vidimo što se događa.

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

I nakon što smo se pomaknuli do točke gdje su se pogreške počele pojavljivati, vidimo da imamo autofileover. Budući da su naše pogreške bile povezane s interakcijom s DCS-om, au našem slučaju koristili smo Consul, također gledamo Consul zapisnike da vidimo što se tamo dogodilo.

Približno usporedivši vrijeme filera i vrijeme u Consul logovima, vidimo da su naši susjedi u Consul clusteru počeli sumnjati u postojanje ostalih članova Consul clustera.

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

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

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

Postoje opcije:

• Najjednostavnija opcija, koja je napisana, po mom mišljenju, čak iu dokumentaciji, je onemogućiti Consul provjere, tj. jednostavno proći prazan niz. I kažemo agentu konzula da ne koristi nikakve čekove. Zbog ovih provjera, možemo ignorirati te mrežne oluje i ne pokrenuti filer.
• Druga je mogućnost dvaput provjeriti raft_multiplier. Ovo je parametar samog Consul poslužitelja. Prema zadanim postavkama postavljeno je na 5. Ova se vrijednost preporučuje prema dokumentaciji za probna okruženja. To bitno utječe na učestalost razmjene poruka između članova Consul mreže. U biti, ovaj parametar utječe na brzinu službene komunikacije između članova klastera Consul. A za proizvodnju se već preporučuje smanjiti ga tako da čvorovi češće razmjenjuju poruke.
• Druga opcija koju smo počeli koristiti bila je povećanje prioriteta Consul procesa među ostalim procesima za planer procesa operacijskog sustava. Postoji takav parametar "lijep", on samo određuje prioritet procesa koji OS planer uzima u obzir prilikom planiranja. Također smo smanjili lijepu vrijednost za Consul agente, tj. povećao je prioritet tako da operativni sustav Consul procesima daje više vremena za rad i izvršavanje njihovog koda. U našem slučaju, ovo je riješilo naš problem.
• Druga mogućnost je da ne koristite Consul. Imam prijatelja koji je veliki zagovornik Etcd-a. I on i ja se redovito svađamo što je bolje, Etcd ili Consul. Ali što se tiče toga što je bolje, on i ja se općenito slažemo da Consul ima agenta koji mora biti pokrenut na svakom čvoru baze podataka. To jest, Patronijeva interakcija s klasterom Consul odvija se preko ovog agenta. I ovaj agent postaje usko grlo. Ako se nešto dogodi agentu, Patroni više ne može raditi s klasterom Consul. I to je problem. Nema agenta u Etcd planu. Patroni može izravno raditi s popisom Etcd poslužitelja i već komunicirati s njima. U tom smislu, ako koristite Etcd u svojoj tvrtki, onda će Etcd vjerojatno biti bolji izbor od Consula. Ali s našim kupcima uvijek smo ograničeni onim što je klijent odabrao i koristi. I većinom svi naši klijenti imaju konzula.
• I zadnja točka je ponovno razmotriti vrijednosti parametara. Možemo podići ove parametre više u nadi da će naši kratkoročni problemi s mrežom biti kratki i da neće pasti unutar raspona ovih parametara. Na taj način možemo smanjiti agresivnost Patronija da izvrši autofileover ako dođe do problema s mrežom.

Mislim da su mnogi koji koriste Patroni upoznati s ovom naredbom.

Ova naredba prikazuje trenutno stanje klastera. I na prvi pogled ova slika može izgledati normalno. Imamo master, imamo repliku, nema kašnjenja replikacije. Ali ova je slika normalna dok ne znamo da bi ovaj klaster trebao imati tri čvora, a ne dva.

Sukladno tome, došlo je do autofileovera. I nakon ovog autofileovera, naša replika je nestala. Moramo saznati zašto je nestala i vratiti je, obnoviti. I ponovno idemo u zapisnike i gledamo zašto je došlo do autofileovera.

U ovom slučaju, druga replika postala je majstor. Ovdje je sve u redu.

I trebamo pogledati repliku koja je otpala i nije u klasteru. Otvaramo Patroni zapisnike i vidimo da smo imali problema u fazi pg_rewind tijekom povezivanja na klaster. Da biste se povezali s klasterom, morate premotati transakcijski dnevnik, zatražiti potrebni transakcijski dnevnik od mastera i njime uhvatiti korak s masterom.

U ovom slučaju nemamo dnevnik transakcija i replika se ne može pokrenuti. Sukladno tome, zaustavljamo Postgres s pogreškom. I zato ga nema u klasteru.

Moramo razumjeti zašto nije u klasteru i zašto nije bilo dnevnika. Idemo do novog gospodara i gledamo što ima u svojim dnevnicima. Ispostavilo se da kada je pg_rewind gotov, došlo je do kontrolne točke. A neki stari zapisnici transakcija jednostavno su preimenovani. Kada se stari master pokušao spojiti na novog mastera i zatražiti te zapise, oni su već bili preimenovani, jednostavno nisu postojali.

Usporedio sam vremenske oznake kada su se ti događaji dogodili. I tu je razlika doslovno 150 milisekundi, tj. za 369 milisekundi kontrolna točka je završena, WAL segmenti su preimenovani. I doslovno na 517, 150 milisekundi kasnije, počelo je premotavanje unatrag na staroj replici. Odnosno, bilo nam je dovoljno doslovno 150 milisekundi da spriječimo spajanje i rad replike.

Koje su mogućnosti?

U početku smo koristili utore za replikaciju. Mislili smo da je dobro. Iako smo u prvoj fazi rada onemogućili utore. Činilo nam se da bismo mogli ispustiti master ako utori nakupe mnogo WAL segmenata. On će pasti. Patili smo neko vrijeme bez utora. I shvatili smo da nam trebaju utori, vratili smo utore.

Ali ovdje postoji problem da kada master prijeđe na repliku, on briše utore i, zajedno sa utorima, briše WAL segmente. A kako bismo uklonili ovaj problem, odlučili smo povećati parametar wal_keep_segments. Zadano je 8 segmenata. Digli smo ga na 1 i gledali koliko slobodnog prostora imamo. I donirali smo 000 gigabajta za wal_keep_segments. Odnosno, prilikom prebacivanja uvijek imamo rezervu od 16 gigabajta transakcijskih dnevnika na svim čvorovima.

I plus – ovo je također relevantno za zadatke dugotrajnog održavanja. Recimo da trebamo ažurirati jednu od replika. I želimo ga ugasiti. Moramo ažurirati softver, možda operativni sustav, nešto drugo. A kada isključimo repliku, uklanja se i utor za tu repliku. A ako koristimo male wal_keep_segmente, onda ako postoji duga odsutnost replike, zapisnici transakcija će biti izgubljeni. Pokupit ćemo repliku, ona će zatražiti one zapise transakcija gdje je stala, ali oni možda neće biti na glavnoj stranici. A replika se također neće moći povezati. Zato imamo veliku zalihu časopisa.

Imamo proizvodnu bazu. Tamo se već rade projekti.

Dogodio se filer. Ušli smo i pogledali - sve je u redu, replike su na mjestu, nema kašnjenja replikacije. Nema grešaka ni u zapisnicima, sve je uredno.

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

Jasno je da ih je pg_rewind izbrisao. Odmah smo to shvatili, ali smo otišli vidjeti što se događa.

U zapisnicima uvijek možemo pronaći kada se dogodio filer, tko je postao master, možemo utvrditi tko je bio stari majstor i kada je želio postati replika, tj. potrebni su nam ovi zapisnici da saznamo količinu transakcijskih dnevnika koji je izgubljeno.

Naš stari majstor se ponovno pokrenuo. I Patroni je bio registriran u autostartu. Patroni je pokrenut. Zatim je pokrenuo Postgres. Točnije, prije pokretanja Postgresa i prije nego što je napravio njegovu repliku, Patroni je pokrenuo proces pg_rewind. Sukladno tome, obrisao je neke od transakcijskih dnevnika, preuzeo nove i povezao se. Ovdje je Patroni napravio odličan posao, odnosno kako i treba biti. 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 upravo trenutak kada smo imali premotavanje. To možemo saznati iz ovih unosa u dnevnik. premotavanje unatrag počelo, tamo nešto napravilo i završilo.

Moramo pronaći poziciju u dnevniku transakcija gdje je stari majstor stao. U ovom slučaju to je ova oznaka. I trebamo drugu oznaku, tj. udaljenost po kojoj se stari majstor razlikuje od novog.

Uzimamo uobičajeni pg_wal_lsn_diff i uspoređujemo ove dvije oznake. I u ovom slučaju dobivamo 17 megabajta. Je li to puno ili malo, svatko odlučuje za sebe. Jer nekome 17 megabajta nije puno, nekome je puno i nedopustivo. Ovdje svatko odlučuje za sebe pojedinačno u skladu s potrebama posla.

Ali što smo sami otkrili?

Prvo, moramo sami odlučiti - treba li nam uvijek automatsko pokretanje Patronija nakon ponovnog pokretanja sustava? Češće se događa da moramo otići do starog majstora, vidjeti dokle je otišao. Možda pregledati segmente dnevnika transakcija, vidjeti što je tamo. I razumjeti možemo li izgubiti ove podatke ili trebamo pokrenuti stari master u samostalnom načinu rada da dohvatimo te podatke.

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

Osim toga, postoji parametar “maximum_lag_on_failover”. Standardno, ako me pamćenje ne vara, ovaj parametar ima vrijednost od 1 megabajta.

Kako on radi? Ako naša replika zaostaje za 1 megabajt podataka u zaostatku replikacije, tada ta replika ne sudjeluje u izborima. A ako se iznenada pojavi filer, Patroni gleda koje replike zaostaju. Ako zaostaju za velikim brojem zapisnika transakcija, ne mogu postati gospodari. Ovo je vrlo dobra sigurnosna značajka koja vas sprječava od gubitka puno podataka.

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

Sukladno tome, može postojati situacija u kojoj je kašnjenje replikacije za replike u DCS-u isto, ali zapravo može postojati potpuno drugačije kašnjenje ili možda uopće ne postoji kašnjenje, tj. ova stvar nije u stvarnom vremenu. I ne odražava uvijek stvarnu sliku. I ne vrijedi na tome stvarati otmjenu logiku.

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

I ima dobrih vijesti. Kad je stari majstor krenuo naprijed, on može ići naprijed zbog nekih pozadinskih procesa. Odnosno, došlo je do neke vrste autovakuma, zapisao je podatke i spremio ih u dnevnik transakcija. I lako možemo zanemariti i izgubiti te podatke. S ovim nema problema.

I ovako izgledaju zapisnici ako je postavljen maximum_lag_on_failover i dogodi se fileover, a vi trebate odabrati novi master. Replika sebe procjenjuje nesposobnom za izlazak na izbore. I odbija sudjelovati u utrci za vodstvo. I čeka da se odabere novi majstor, pa da se onda poveže s njim. Ovo je dodatna mjera protiv gubitka podataka.

Ovdje je naš proizvodni tim napisao da njihov proizvod ima problema pri radu s Postgresom. Istodobno, ne možete pristupiti samom masteru, jer nije dostupan putem SSH-a. A autofileover se također ne događa.

Ovaj host je bio prisiljen na ponovno pokretanje. Zbog ponovnog pokretanja, došlo je do autofileovera, iako je bilo moguće izvršiti i ručno autofileover, koliko sada razumijem. I nakon reboota idemo vidjeti što smo imali s trenutnim majstorom.

Pritom smo unaprijed znali da imamo problema s diskovima, odnosno već smo iz praćenja znali gdje kopati i što tražiti.

Ušli smo u postgres log i počeli gledati što se tamo događa. Vidjeli smo komitove koji su trajali jednu, dvije ili tri sekunde, što uopće nije normalno. Vidjeli smo da našem autovakumu treba jako dugo i čudno da se pokrene. I vidjeli smo privremene datoteke na disku. Odnosno, sve su to pokazatelji problema s diskovima.

Pogledali smo u sustav dmesg (nuclear message log). I vidjeli smo da imamo problema s jednim od diskova. Diskovni podsustav bio je softverski Raid. Pogledali smo /proc/mdstat i vidjeli da nam nedostaje jedan disk. Odnosno, postoji Raid od 8 diskova, nedostaje nam jedan. Ako pažljivo pogledate slajd, možete vidjeti u izlazu da tamo nemamo sde. Disk nam je, relativno govoreći, ispao. To je pokrenulo probleme s diskom, a i aplikacije su imale problema pri radu s Postgres klasterom.

I u ovom slučaju Patroni nam ne bi nikako pomogao, jer Patroni nema zadaću pratiti stanje servera, stanje diska. I takve situacije moramo pratiti vanjskim nadzorom. Eksternom nadzoru dodali smo operativni nadzor diska.

Postojala je ta misao - može li nam softver za ograđivanje ili pas čuvar pomoći? Mislili smo da je malo vjerojatno da bi nam on pomogao u ovom slučaju, jer tijekom problema Patroni je nastavio komunicirati s DCS klasterom i nije vidio nikakav problem. Odnosno, sa stajališta DCS-a i Patronija, s klasterom je sve bilo u redu, iako je zapravo bilo problema s diskom, bilo je problema s dostupnošću baze podataka.

Po mom mišljenju, ovo je jedan od najčudnijih problema koji sam jako dugo istraživao, ponovno čitao puno dnevnika, petljao s njim i nazvao ga simulatorom klastera.

Problem je bio u tome što stari majstor nije mogao postati normalna replika, tj. Patroni ga je lansirao, Patroni je pokazao da je ovaj čvor prisutan kao replika, ali u isto vrijeme nije bio normalna replika. Sada ćete vidjeti zašto. Čuvao sam ovo od analize tog problema.

A gdje je sve počelo? Počelo je, kao i u prethodnom problemu, s disk kočnicama. Imali smo obveze jednu po jednu sekundu, dvije odjednom.

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

Bilo je blokada različite težine.

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

A najmisterioznije mi je stigao zahtjev za hitno gašenje. Postgres ima tri načina isključivanja:

• Lijepo je kada čekamo da se svi klijenti sami odspoje.
• Postoji brza situacija kada prisilimo klijente da prekinu vezu jer ćemo se isključiti.
• I to odmah. U ovom slučaju, immediate čak niti ne govori klijentima da se isključe, samo se isključuje bez upozorenja. I operativni sustav šalje RST poruku svim klijentima (TCP poruka da je veza prekinuta i da klijent više nema što uhvatiti).

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

Pogledao sam "zadnju" naredbu i vidio sam jednu osobu koja se također prijavila na ovaj server s nama, ali bilo me je sram postaviti pitanje. Možda je to bilo ubojstvo -9. Vidio bih kill -9 u zapisima, jer... Postgres kaže da je prihvatio kill -9, ali ja to nisam vidio u zapisima.

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

I tijekom tog vremena dogodio se autofileover. Patroni je i ovdje odlično radio. Naš stari majstor je bio nedostupan, nešto mu se događalo. I počeo je izbor novog gospodara. Ovdje je sve dobro ispalo. Naš pgsql01 je postao naš novi vođa.

Imamo repliku koja je postala majstor. A postoji i druga replika. I s drugom primjedbom je bilo problema. Pokušala se rekonfigurirati. Koliko sam shvatio, pokušala je promijeniti recovery.conf, ponovno pokrenuti Postgres i spojiti se na novi master. Svakih 10 sekundi šalje poruku da pokušava, ali ne uspijeva.

I tijekom tih pokušaja, starom majstoru stiže signal za trenutno gašenje. Master se ponovno pokreće. I oporavak se zaustavlja jer stari majstor ide u ponovno pokretanje. Odnosno, replika se ne može povezati s njom jer je u stanju isključivanja.

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

Jedina hipoteza koju imam je da recovery.conf sadrži adresu starog majstora. A kada se pojavio novi majstor, druga replika se ipak pokušala povezati sa starim majstorom.

Kad se Patroni pokrenuo na drugoj replici, čvor se pokrenuo, ali se nije mogao povezati putem replikacije. I stvorio se zastoj replikacije, koji je izgledao otprilike ovako. Odnosno, sva su tri čvora bila na mjestu, ali je drugi čvor zaostajao.

U isto vrijeme, ako pogledate zapisane zapisnike, mogli ste vidjeti da replikacija nije mogla započeti jer su zapisnici transakcija bili drugačiji. A zapisnici transakcija koje nudi čarobnjak, a koji su navedeni u recovery.conf, jednostavno nisu prikladni za naš trenutni čvor.

I tu sam pogriješio. Morao sam doći vidjeti što je tamo u recovery.conf da testiram svoju hipotezu da se povezujemo s pogrešnim masterom. Ali ja sam to tada samo smišljao i nije mi palo na pamet, ili sam vidio da replika zaostaje i treba je napuniti, tj. nekako sam to nemarno razradio. Ovo je bio moj jamb.

Nakon 30 minuta stigao je admin, tj. restartao sam Patroni na replici. Već sam odustao od toga, mislio sam da će morati dopuniti. I pomislio sam, ponovno ću pokrenuti Patroni, možda ispadne nešto dobro. Oporavak je započeo. A baza se čak otvorila, bila je spremna prihvatiti veze.

Replikacija je započela. Ali minutu kasnije srušio se s greškom da zapisnici transakcija nisu prikladni za njega.

Mislio sam ponovno pokrenuti. Ponovno sam pokrenuo Patroni, ali nisam ponovno pokrenuo Postgres, već sam ponovno pokrenuo Patroni u nadi da će čarobno pokrenuti bazu podataka.

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

I onda mi padne na pamet - što ako ponovno pokrenem Postgres, u ovom trenutku napravim kontrolnu točku na trenutnom masteru kako bih točku u transakcijskom dnevniku pomaknuo malo naprijed da oporavak krene od drugog trenutka? Plus tamo smo još uvijek imali WAL rezerve.

Restartao sam Patroni, napravio par checkpointa na masteru, par restart pointa na replici kad se otvorila. I pomoglo je. Dugo sam razmišljao zašto je to pomoglo i kako djeluje. I krenula je replika. I replikacija više nije uspjela.

Ovaj problem je za mene jedan od misterioznijih, oko kojeg još uvijek razbijam glavu što se tu zapravo dogodilo.

Koji su zaključci ovdje? Patroni može raditi kako treba i bez grešaka. Ali u isto vrijeme, to nije 100% jamstvo da je s nama sve u redu. Replika se može pokrenuti, ali može biti u polu-radnom stanju i aplikacija ne može raditi s takvom replikom jer će tamo biti starih podataka.

I nakon fileovera uvijek treba provjeriti je li sve u redu s klasterom, tj. imamo potreban broj replika i nema kašnjenja replikacije.

I dok budemo razmatrali ove probleme, ja ću formulirati preporuke. Pokušao sam ih spojiti u dva slajda. Vjerojatno 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 se dogodio autofileover, jer ako ne znate da ste imali autofileover, ne kontrolirate klaster. 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 replikacije i da nema pogrešaka u zapisima vezanim uz replikaciju strujanja, Patroni ili DCS sustav.

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

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

Kako pristupiti pitanju dijagnoze? Dogodilo se da radimo s različitim klijentima i nitko nema ELK stack, a zapise moramo razumjeti otvaranjem 6 konzola i 2 taba. U jednoj kartici nalaze se Patroni dnevnici za svaki čvor, u drugoj kartici su Consul dnevnici ili Postgres dnevnici po potrebi. Vrlo je teško dijagnosticirati.

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

Dalje, gledam u logovima događaje prije filera, koji su prethodili fileru, tj. tražim razloge zašto je došlo do filera.

A to daje sliku razumijevanja onoga što se dogodilo i što se može učiniti u budućnosti da se spriječi pojava takvih okolnosti (i, kao rezultat toga, ne dolazi do fileovera).

A gdje obično tražimo? Izgledam:

• Prvo do Patroninih loga.
• Zatim gledam zapisnike Postgresa ili zapisnike DCS-a, ovisno o tome što je pronađeno u zapisnicima Patronija.
• I zapisnici sustava također ponekad daju razumijevanje o tome što je uzrokovalo datoteku.

Kako se osjećam prema Patroniju? Osjećam se jako dobro u vezi Patronija. Po mom mišljenju, ovo je nešto najbolje što danas postoji. Znam mnoge druge proizvode. To su Stolon, Repmgr, Pg_auto_failover, PAF. 4 alata. Sve sam ih probao. Najviše mi se svidio Patroni.

Ako me pitaju: "Preporučujem li Patroni?" Reći ću da, jer mi se sviđa Patroni. I mislim da sam ga naučila kuhati.

Ako vas zanima koji još problemi postoje s Patronijem, osim problema koje sam iznio, uvijek možete otići na stranicu pitanja na GitHubu. Ima tu mnogo različitih priča i mnogo zanimljivih problema. Kao rezultat toga, uvedene su i riješene neke greške, tj. ovo je zanimljivo štivo.

Tamo ima zanimljivih priča o ljudima koji su sebi pucali u nogu. Vrlo informativno. Pročitali ste i shvatili da to ne trebate učiniti. Sam sam sebe označio.

I želio bih reći veliko hvala tvrtki Zalando za razvoj ovog projekta, odnosno Aleksandru Kukuškinu i Alekseju Kljukinu. Alexey Klyukin je jedan od koautora, on više ne radi u Zalandu, ali to su dvije osobe koje su počele raditi s ovim proizvodom.

I mislim da je Patroni jako cool stvar. Drago mi je da postoji, zanimljivo je biti s njom. I veliko hvala svim suradnicima koji pišu zakrpe za Patroni. Nadam se da će Patroni s godinama postati zreliji, cool i sposobniji. Već je učinkovito, ali nadam se da će postati još bolje. Dakle, ako planirate koristiti Patroni u svom domu, ne bojte se. Ovo je dobro rješenje, može se implementirati i koristiti.

To je sve. Ako imate pitanja, slobodno pitajte.

pitanja

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

Jer je to nova stvar. S njom radimo tek godinu dana. Bolje igrati na sigurno. Želimo ući i vidjeti da je stvarno sve funkcioniralo kako treba. Ovo je razina nepovjerenja odraslih - bolje je još jednom provjeriti i vidjeti.

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

Ne ujutro, obično skoro odmah saznamo za autofileover. Primamo obavijesti, vidimo da je došlo do autofileovera. Gotovo odmah ulazimo i razgledavamo. Ali sve te provjere moraju se dovesti na razinu monitoringa. Ako pristupite Patroni putem REST API-ja, postoji povijest. Koristeći povijest, možete pogledati vremenske oznake kada je datoteka preuzeta. Na temelju toga može se vršiti praćenje. Možete pogledati povijest da vidite koliko je bilo događaja. Ako imamo više događaja, to znači da je došlo do autofileovera. Možete otići i pogledati. Ili je naša automatizacija nadzora provjerila imamo li sve replike na mjestu, nema kašnjenja i sve je u redu.

Hvala vam!

Hvala vam puno na sjajnoj priči! Ako smo DCS klaster premjestili negdje dalje od Postgres klastera, treba li i ovaj klaster povremeno servisirati? Koje su najbolje prakse u tome da neke dijelove DCS klastera treba isključiti, učiniti nešto s njima itd.? Kako živi cijela ova struktura? I kako učiniti te stvari?

Za jednu tvrtku bilo je potrebno izraditi matricu problema što se događa ako jedna ili više komponenti zakažu. Koristeći ovu matricu, sekvencijalno prolazimo kroz sve komponente i gradimo scenarije u slučaju kvara tih komponenti. Sukladno tome, za svaki scenarij kvara možete imati akcijski plan za oporavak. A u slučaju DCS-a, to dolazi kao dio standardne infrastrukture. I admin administrira, a mi se već oslanjamo na admine koji administriraju i na njegovu sposobnost da to popravi u slučaju katastrofa. Ako uopće nema DCS-a, onda ga postavljamo, ali ga posebno ne pratimo, jer nismo odgovorni za infrastrukturu, ali dajemo preporuke kako i što pratiti.

Odnosno, jesam li dobro shvatio da moram onemogućiti Patroni, onemogućiti filer, onemogućiti sve prije nego što bilo što učinim s hostovima?

Ovisi o tome 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 pokreće. Ako imamo neke složene operacije koje utječu na više čvorova, čiji bi nedostatak mogao uništiti kvorum, onda da, možda ima smisla pauzirati Patronija. Ima odgovarajuću naredbu - patronictl pauza, patronictl nastavak. Jednostavno ga pauziramo, a autofileover trenutno ne radi. Održavamo DCS klaster, zatim uklanjamo pauzu i nastavljamo sa životom.

Hvala vam puno!

Hvala vam puno na izvješću! Kako se tim proizvoda osjeća zbog gubitka podataka?

Timove za proizvode nije briga, ali voditelji timova su zabrinuti.

Kakva jamstva postoje?

S garancijama je jako teško. Alexander Kukushkin ima izvješće “Kako izračunati RPO i RTO”, tj. vrijeme oporavka i koliko podataka možemo izgubiti. Mislim da moramo pronaći ove slajdove i proučiti ih. Koliko se sjećam, postoje određeni koraci kako izračunati te stvari. Koliko transakcija možemo izgubiti, koliko podataka možemo izgubiti. Kao opciju, možemo koristiti sinkronu replikaciju na razini Patronija, ali to je dvosjekli mač: ili imamo pouzdanost podataka ili gubimo na brzini. Postoji sinkrona replikacija, ali ona također ne jamči 100% zaštitu od gubitka podataka.

Alexey, hvala ti na prekrasnom izvješću! Imate li iskustva s korištenjem Patronija za zaštitu nulte razine? Odnosno u kombinaciji sa sinkronim stanjem pripravnosti? Ovo je prvo pitanje. I drugo pitanje. Koristili ste različita rješenja. Koristili smo Repmgr, ali bez autofileovera i sada planiramo omogućiti autofileover. Patroni smatramo alternativnim rješenjem. Što možete reći o prednostima u usporedbi s Repmgr-om?

Prvo pitanje odnosilo se na sinkrone replike. Ovdje nitko ne koristi sinkronu replikaciju, jer se svi boje (nekoliko klijenata je već koristi, nisu primijetili nikakve probleme s performansama - Bilješka govornika). Ali razvili smo pravilo za sebe da u klasteru sinkrone replikacije moraju postojati najmanje tri čvora, jer ako imamo dva čvora i ako glavni ili replika zakaže, tada Patroni prebacuje ovaj čvor u Samostalni način rada tako da aplikacija nastavi raditi. U tom slučaju postoji opasnost od gubitka podataka.

Što se tiče drugog pitanja, koristili smo Repmgr i još uvijek ga koristimo za neke klijente iz povijesnih razloga. Što možemo reći? U Patroni, autofileover dolazi odmah; u Repmgr, autofileover dolazi kao dodatna značajka koju je potrebno omogućiti. Moramo pokrenuti Repmgr demon na svakom čvoru i tada možemo konfigurirati autofileover.

Repmgr provjerava jesu li Postgres čvorovi živi. Repmgr procesi provjeravaju postojanje jedan drugog, ovo nije vrlo učinkovit pristup jer Mogu postojati složeni slučajevi mrežne izolacije u kojima se veliki Repmgr klaster može razbiti u nekoliko malih i nastaviti s radom. Ne pratim Repmgr dugo vremena, možda je ovo popravljeno... a možda i nije. Ali prijenos informacija o stanju klastera u DCS, kao što to rade Stolon i Patroni, najizvodljivija je opcija.

Alexey, imam pitanje koje je možda jadno. U jednom od prvih primjera premjestili ste DCS s lokalnog stroja na udaljeni čvor. Razumijemo da je mreža stvar koja ima svoje karakteristike; ona živi sama za sebe. A što se događa ako iz nekog razloga DCS klaster postane nedostupan? Neću govoriti o razlozima, može ih biti puno: od krivih ruku mrežnih radnika do stvarnih problema.

Nisam to rekao naglas, ali DCS klaster također mora biti tolerantan na pogreške, što znači da ima neparan broj čvorova kako bi se dogodio kvorum. Što 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 klaster Patroni prelazi u način rada samo za čitanje. Patroni klaster ne može odrediti stanje klastera i što učiniti. Ne može kontaktirati DCS i tamo spremiti novo stanje klastera, tako da cijeli klaster prelazi u način rada samo za čitanje. I čeka ručnu intervenciju operatera ili da se DCS ponovno uspostavi.

DCS nam, grubo rečeno, postaje jednako važna usluga kao i sama baza podataka?

Da da. U mnogim modernim tvrtkama, Service Discovery je sastavni dio infrastrukture. Provodi se i prije nego što je uopće postojala baza podataka u infrastrukturi. Relativno govoreći, pokrenuli smo infrastrukturu, postavili je u DC i odmah imamo Service Discovery. Ako je ovo Consul, onda se DNS može izgraditi na njemu. 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 modernih infrastruktura. I oni o tome razmišljaju puno prije nego baze podataka.

Hvala vam!

Izvor: www.habr.com