Patroni Failure Stories ali Kako zrušiti vašo gručo PostgreSQL. Aleksej Lesovski

Glavni cilj Patronija je zagotoviti visoko razpoložljivost za PostgreSQL. Toda Patroni je le predloga in ne pripravljeno orodje (kar je na splošno navedeno v dokumentaciji). Ko nastavite Patroni v testnem laboratoriju, lahko že na prvi pogled vidite, kako odlično orodje je in kako enostavno se spopada z našimi poskusi razbitja gruče. Vendar v praksi, v proizvodnem okolju, ne poteka vedno vse tako lepo in elegantno kot v testnem laboratoriju.

Povedal vam bom nekaj o sebi. Začel sem kot sistemski administrator. Delal v spletnem razvoju. V podjetju Data Egret delam od leta 2014. Podjetje se ukvarja s svetovanjem na področju Postgres. In služimo prav Postgresu in s Postgresom delamo vsak dan, tako da imamo različna strokovna znanja, povezana z operacijo.

In konec leta 2018 smo začeli počasi uporabljati Patroni. In nekaj izkušenj se je nabralo. Nekako smo ga diagnosticirali, prilagodili, prišli do naših najboljših praks. In v tem poročilu bom govoril o njih.

Poleg Postgresa obožujem Linux. Rad brskam po njem in raziskujem, rad zbiram jedra. Obožujem virtualizacijo, kontejnerje, docker, Kubernetes. Vse to me zanima, ker vplivajo stare administratorske navade. Rad se ukvarjam s spremljanjem. In obožujem postgresove stvari, povezane z administracijo, tj. replikacijo, varnostno kopiranje. In v prostem času pišem v Go. Nisem programski inženir, samo pišem zase v Go. In to mi je v veselje.

• Mislim, da mnogi od vas veste, da Postgres nima HA (High Availability) takoj po izdelavi. Če želite dobiti HA, morate nekaj namestiti, konfigurirati, se potruditi in to dobiti.
• Obstaja več orodij in Patroni je eno izmed njih, ki precej kul in zelo dobro rešuje HA. Če pa vse to postavimo v preskusni laboratorij in zaženemo, lahko vidimo, da vse deluje, lahko reproduciramo nekatere težave, vidimo, kako jim Patroni služi. In videli bomo, da vse deluje odlično.
• A v praksi smo se srečevali z drugačnimi težavami. In govoril bom o teh težavah.
• Povedal vam bom, kako smo ga diagnosticirali, kaj smo popravili – ali nam je pomagalo ali ne.

• Ne bom vam povedal, kako namestiti Patroni, ker lahko googlate po internetu, si lahko ogledate konfiguracijske datoteke, da razumete, kako se vse začne, kako je konfigurirano. Lahko razumete sheme, arhitekture, iskanje informacij o tem na internetu.
• Ne bom govoril o izkušnjah nekoga drugega. Govoril bom le o težavah, s katerimi smo se soočali.
• In ne bom govoril o težavah, ki so zunaj Patronija in PostgreSQL. Če so na primer težave povezane z uravnoteženjem, ko se je naš grozd sesul, o tem ne bom govoril.

In majhna izjava o omejitvi odgovornosti, preden začnemo s poročilom.

Vse te težave, s katerimi smo se srečevali, smo jih imeli v prvih 6-7-8 mesecih delovanja. Sčasoma smo prišli do naših internih najboljših praks. In naše težave so izginile. Poročilo je bilo torej napovedano pred kakšnimi šestimi meseci, ko je bilo vse sveže v moji glavi in ​​sem se vsega dobro spomnil.

Med pripravo poročila sem že dvignil stare mrliške, si ogledal dnevnike. In nekatere podrobnosti so lahko pozabljene ali pa nekaterih nekaterih podrobnosti med analizo težav ni bilo mogoče v celoti raziskati, zato se na nekaterih točkah morda zdi, da težave niso v celoti upoštevane ali da primanjkuje informacij. Zato vas prosim, da mi za ta trenutek opravičite.

Kaj je Patroni?

• To je predloga za izdelavo HA. Tako piše v dokumentaciji. In z mojega vidika je to zelo pravilno pojasnilo. Patroni ni srebrna krogla, ki bo rešila vse vaše težave, to pomeni, da se morate potruditi, da deluje in prinaša koristi.
• To je posredniška storitev, ki je nameščena na vsaki storitvi baze podatkov in je nekakšen sistem inicializacije za vaš Postgres. Zažene Postgres, ustavi, znova zažene, znova konfigurira in spremeni topologijo vaše gruče.
• V skladu s tem je za shranjevanje stanja gruče, njegove trenutne predstavitve, kot je videti, potrebna nekakšna shramba. In s tega vidika je Patroni ubral pot shranjevanja stanja v zunanjem sistemu. Je porazdeljen sistem za shranjevanje konfiguracije. Lahko je Etcd, Consul, ZooKeeper ali kubernetes Etcd, tj. ena od teh možnosti.
• In ena od značilnosti Patronija je, da samodejni datoteko dobite takoj, ko jo nastavite. Če za primerjavo vzamemo Repmgr, potem je filer tam vključen. Z Repmgr dobimo preklop, če pa želimo autofiler, ga moramo dodatno konfigurirati. Patroni že ima samodejno datoteko iz škatle.
• Pa še marsikaj je. Na primer vzdrževanje konfiguracij, vlivanje novih replik, varnostno kopiranje itd. Ampak to je izven obsega poročila, o tem ne bom govoril.

In majhen rezultat je, da je glavna naloga Patronija narediti samodejno datoteko dobro in zanesljivo, tako da naša gruča ostane operativna in aplikacija ne opazi sprememb v topologiji gruče.

Ko pa začnemo uporabljati Patroni, postane naš sistem nekoliko bolj zapleten. Če smo prej imeli Postgres, potem pri uporabi Patronija dobimo sam Patroni, dobimo DCS, kjer je shranjeno stanje. In vse mora nekako delovati. Kaj gre torej lahko narobe?

Lahko zlomi:

• Postgre se lahko pokvari. Lahko je mojster ali replika, eden od njih lahko odpove.
• Sam Patroni se lahko pokvari.
• DCS, kjer je shranjeno stanje, se lahko pokvari.
• In omrežje se lahko prekine.

Vse te točke bom upošteval v poročilu.

Primere bom obravnaval, ko bodo postajali bolj zapleteni, ne z vidika, da zadeva vključuje veliko komponent. In z vidika subjektivnih občutkov, da mi je bila ta zadeva težka, težko jo je bilo razstaviti ... in obratno, neka zadeva je bila lahka in jo je bilo enostavno razstaviti.

In prvi primer je najlažji. To je primer, ko smo vzeli gručo baze podatkov in v isti gruči razmestili našo shrambo DCS. To je najpogostejša napaka. To je napaka pri gradnji arhitektur, torej združevanju različnih komponent na enem mestu.

Torej, prišlo je do datoteke, pojdimo se ukvarjati s tem, kar se je zgodilo.

In tukaj nas zanima, kdaj se je zgodil filer. To pomeni, da nas zanima ta trenutek v času, ko se je stanje grozda spremenilo.

Vendar datoteka ni vedno trenutna, to pomeni, da ne traja nobene časovne enote, lahko se zakasni. Lahko je dolgotrajen.

Zato ima začetni in končni čas, kar pomeni, da je neprekinjen dogodek. In vse dogodke delimo na tri intervale: imamo čas pred filerjem, med filerjem in po filerju. To pomeni, da upoštevamo vse dogodke na tej časovnici.

In prva stvar, ko se je zgodil filer, iščemo vzrok tega, kar se je zgodilo, kaj je bil vzrok, kar je pripeljalo do filera.

Če pogledamo polena, bodo to klasična polena Patroni. V njih nam pove, da je strežnik postal glavni, vloga glavnega pa je prešla na to vozlišče. Tukaj je poudarjeno.

Nato moramo razumeti, zakaj se je zgodil filer, tj. kateri dogodki so se zgodili, zaradi katerih se je glavna vloga premaknila iz enega vozlišča v drugega. In v tem primeru je vse preprosto. Imamo napako pri interakciji s sistemom za shranjevanje. Mojster je ugotovil, da ne more delati z DCS, to je, da je prišlo do neke vrste težave z interakcijo. In pravi, da ne more biti več gospodar in odstopi. Ta vrstica "degradirani jaz" pravi točno to.

Če pogledamo dogodke pred datoteko, lahko tam vidimo prav razloge, ki so bili problem za nadaljevanje čarovnika.

Če pogledamo dnevnike Patroni, bomo videli, da imamo veliko napak, časovnih omejitev, tj. agent Patroni ne more delati z DCS. V tem primeru je to konzul agent, ki komunicira na vratih 8500.

In tukaj je težava, da se Patroni in baza podatkov izvajata na istem gostitelju. In strežniki Consul so bili zagnani na istem vozlišču. Z obremenitvijo strežnika smo povzročili težave tudi strežnikom Consul. Niso mogli pravilno komunicirati.

Čez nekaj časa, ko je obremenitev popustila, je naš Patroni spet lahko komuniciral z agenti. Nadaljevalo se je normalno delo. In isti strežnik Pgdb-2 je spet postal glavni. To pomeni, da je prišlo do majhnega preobrata, zaradi katerega je vozlišče odstopilo od pooblastil gospodarja in jih nato spet prevzelo, to je, da se je vse vrnilo, kot je bilo.

In to je mogoče obravnavati kot lažni alarm ali pa se lahko šteje, da je Patroni naredil vse pravilno. To pomeni, da je ugotovil, da ne more vzdrževati stanja grozda in odstranil svojo avtoriteto.

In tukaj je nastala težava zaradi dejstva, da so strežniki Consul na isti strojni opremi kot baze. Skladno s tem vsaka obremenitev: ne glede na to, ali gre za obremenitev diskov ali procesorjev, vpliva tudi na interakcijo z gruči Consul.

In odločili smo se, da ne sme živeti skupaj, za Consul smo dodelili ločen grozd. In Patroni je že delal z ločenim Consulom, se pravi, obstajal je ločen grozd Postgres, ločen grozd Consul. To je osnovno navodilo, kako prenašati in hraniti vse te stvari, da ne živijo skupaj.

Kot možnost lahko zavrtite parametre ttl, loop_wait, retry_timeout, tj. poskusite preživeti te kratkotrajne konice obremenitve s povečanjem teh parametrov. Vendar to ni najprimernejša možnost, saj je ta obremenitev lahko dolgotrajna. In preprosto bomo šli čez te meje teh parametrov. In to morda res ne bo pomagalo.

Prvi problem, kot razumete, je preprost. Vzeli smo in sestavili DCS skupaj z bazo, imeli smo problem.

Drugi problem je podoben prvemu. Podobno je v tem, da imamo spet težave z interoperabilnostjo sistema DCS.

Če pogledamo dnevnike, bomo videli, da imamo spet komunikacijsko napako. In Patroni pravi, da ne morem komunicirati z DCS, zato trenutni glavni preide v način replike.

Stari mojster postane replika, tukaj Patroni dela, kot se spodobi. Zažene pg_rewind, da previje dnevnik transakcij nazaj in se nato poveže z novim glavnim, da dohiti novega glavnega. Tukaj Patroni dela, kot bi moral.

Tukaj moramo poiskati mesto, ki je bilo pred filerjem, torej tiste napake, zaradi katerih smo imeli filer. In v zvezi s tem so dnevniki Patroni zelo priročni za delo. V določenem intervalu piše ista sporočila. In če začnemo hitro brskati po teh dnevnikih, potem bomo iz dnevnikov videli, da so se dnevniki spremenili, kar pomeni, da so se začele nekatere težave. Hitro se vrnemo na to mesto in vidimo, kaj se zgodi.

In v običajni situaciji so dnevniki videti nekako takole. Lastnik ključavnice je preverjen. In če se na primer spremeni lastnik, se lahko zgodijo dogodki, na katere se mora Patroni odzvati. Ampak v tem primeru smo v redu. Iščemo kraj, kjer so se napake začele.

In ko smo se pomaknili do točke, kjer so se začele pojavljati napake, vidimo, da smo imeli samodejni pregled datotek. In ker so bile naše napake povezane z interakcijo z DCS in smo v našem primeru uporabili Consul, pogledamo tudi dnevnike Consul, kaj se je tam zgodilo.

Če približno primerjamo čas vložka in čas v dnevnikih Consul, vidimo, da so naši sosedje v gruči Consul začeli dvomiti v obstoj drugih članov gruče Consul.

In če pogledate tudi dnevnike drugih konzulovih agentov, lahko tudi vidite, da se tam dogaja nekakšen kolaps omrežja. In vsi člani gruče Consul dvomijo o obstoju drug drugega. In to je bila spodbuda za filerja.

Če pogledate, kaj se je zgodilo pred temi napakami, lahko vidite, da obstajajo vse vrste napak, na primer rok, RPC je padel, torej očitno obstaja nekakšna težava v interakciji članov grozda Consul med seboj .

Najenostavnejši odgovor je popraviti omrežje. Ampak meni, ko stojim na stopničkah, je to enostavno reči. Toda okoliščine so takšne, da si stranka ne more vedno privoščiti popravila omrežja. Morda živi v DC in morda ne bo mogel popraviti omrežja, vplivati ​​na opremo. In zato so potrebne nekatere druge možnosti.

Obstajajo možnosti:

• Najenostavnejša možnost, ki je po mojem mnenju napisana tudi v dokumentaciji, je onemogočanje konzularnih pregledov, torej preprosto posredovanje praznega polja. Konzulu povemo, naj ne uporablja nobenih čekov. S temi preverjanji lahko prezremo te omrežne nevihte in ne sprožimo datoteke.
• Druga možnost je, da dvakrat preverite raft_multiplier. To je parameter samega strežnika Consul. Privzeto je nastavljena na 5. To vrednost priporoča dokumentacija za uprizoritvena okolja. Pravzaprav to vpliva na pogostost sporočanja med člani mreže Consul. Pravzaprav ta parameter vpliva na hitrost storitvene komunikacije med člani gruče Consul. In za proizvodnjo je že priporočljivo zmanjšati, tako da si vozlišča pogosteje izmenjujejo sporočila.
• Druga možnost, ki smo jo iznašli, je povečati prednost procesov Consul med drugimi procesi za načrtovalnik procesov operacijskega sistema. Obstaja tako "lep" parameter, ki samo določa prednost procesov, ki jih načrtovalnik OS upošteva pri načrtovanju. Prav tako smo znižali lepo vrednost za agente Consul, tj. povečal prednost, tako da operacijski sistem daje procesom Consul več časa za delo in izvajanje njihove kode. V našem primeru je to rešilo naš problem.
• Druga možnost je, da ne uporabite Consul. Imam prijatelja, ki je velik zagovornik Etcd. In z njim se redno prepirava, kateri je boljši Etcd ali Consul. Toda glede tega, kaj je boljše, se običajno strinjamo z njim, da ima Consul agenta, ki bi moral delovati na vsakem vozlišču z bazo podatkov. To pomeni, da interakcija Patronija z gručem Consul poteka prek tega agenta. In ta agent postane ozko grlo. Če se agentu kaj zgodi, Patroni ne more več sodelovati z gruči Consul. In to je problem. V načrtu Etcd ni agenta. Patroni lahko dela neposredno s seznamom strežnikov Etcd in že komunicira z njimi. V zvezi s tem, če uporabljate Etcd v vašem podjetju, bo Etcd verjetno boljša izbira kot Consul. A pri naših strankah smo vedno omejeni s tem, kaj je stranka izbrala in uporablja. In imamo Consul večinoma za vse stranke.
• In zadnja točka je revizija vrednosti parametrov. Te parametre lahko zvišamo v upanju, da bodo naše kratkoročne težave z omrežjem kratke in ne bodo izven obsega teh parametrov. Na ta način lahko zmanjšamo agresivnost Patronija do samodejne datoteke, če pride do težav z omrežjem.

Mislim, da mnogi, ki uporabljajo Patroni, poznajo ta ukaz.

Ta ukaz prikazuje trenutno stanje gruče. In na prvi pogled se ta slika morda zdi normalna. Imamo master, imamo repliko, ni zamika replikacije. Toda ta slika je normalna natanko dokler ne vemo, da mora ta gruča imeti tri vozlišča, ne dveh.

V skladu s tem je prišlo do samodejne datoteke. In po tej samodejni datoteki je naša replika izginila. Ugotoviti moramo, zakaj je izginila in jo vrniti, obnoviti. In spet gremo v dnevnike in vidimo, zakaj smo imeli samodejni pregled.

V tem primeru je druga replika postala mojster. Tukaj je vse v redu.

In pogledati moramo repliko, ki je odpadla in je ni v gruči. Odpremo dnevnike Patroni in vidimo, da smo imeli težavo med postopkom povezovanja z gručo na stopnji pg_rewind. Če se želite povezati z gručo, morate dnevnik transakcij previti nazaj, zahtevati zahtevani dnevnik transakcij od nadrejenega in ga uporabiti, da dohitite nadrejenega.

V tem primeru nimamo dnevnika transakcij in replika se ne more zagnati. V skladu s tem ustavimo Postgres z napako. In zato ni v grozdu.

Razumeti moramo, zakaj ni v gruči in zakaj ni bilo dnevnikov. Gremo do novega gospodarja in pogledamo, kaj ima v logih. Izkazalo se je, da je prišlo do kontrolne točke, ko je bil pg_rewind končan. Nekateri stari dnevniki transakcij so bili preprosto preimenovani. Ko se je stari mojster poskušal povezati z novim masterjem in poizvedovati po teh dnevnikih, so bili že preimenovani, preprosto niso obstajali.

Primerjal sem časovne žige, ko so se ti dogodki zgodili. In tam je razlika dobesedno 150 milisekund, to je kontrolna točka opravljena v 369 milisekundah, segmenti WAL so bili preimenovani. In dobesedno v 517, po 150 milisekundah, se je začelo previjanje nazaj na staro repliko. Se pravi, dobesedno 150 milisekund nam je bilo dovolj, da se replika ni mogla povezati in zaslužiti.

Kakšne so možnosti?

Sprva smo uporabljali podvojitvene reže. Zdelo se nam je dobro. Čeprav smo na prvi stopnji delovanja izklopili reže. Zdelo se nam je, da če reže kopičijo veliko segmentov WAL, lahko izpustimo master. Padel bo. Nekaj ​​časa smo trpeli brez slotov. In ugotovili smo, da potrebujemo reže, vrnili smo reže.

Toda tukaj je težava, da ko master gre do replike, izbriše reže in izbriše segmente WAL skupaj z režami. Da bi odpravili to težavo, smo se odločili povečati parameter wal_keep_segments. Privzeto je 8 segmentov. Dvignili smo ga na 1 in pogledali, koliko prostega prostora imamo. Podarili smo 000 gigabajtov za wal_keep_segments. Se pravi, da imamo ob preklopu vedno rezervo 16 gigabajtov transakcijskih dnevnikov na vseh vozliščih.

Poleg tega je še vedno ustrezen za dolgoročna vzdrževalna opravila. Recimo, da moramo posodobiti eno od replik. In želimo ga izklopiti. Moramo posodobiti programsko opremo, morda operacijski sistem, kaj drugega. In ko izklopimo repliko, se odstrani tudi reža za to repliko. In če uporabimo majhne wal_keep_segments, potem bodo z dolgo odsotnostjo replike izgubljeni dnevniki transakcij. Vzpostavili bomo repliko, zahtevala bo tiste dnevnike transakcij, kjer se je ustavila, vendar jih morda ne bo na glavnem. In tudi replika se ne bo mogla povezati. Zato hranimo veliko zalogo revij.

Imamo proizvodno bazo. V teku so že projekti.

Tam je bil filer. Vstopili smo in pogledali - vse je v redu, replike so na mestu, ni zaostanka replikacije. Tudi v dnevnikih ni napak, vse je v redu.

Ekipa izdelka pravi, da bi moralo biti nekaj podatkov, vendar jih vidimo iz enega vira, vendar jih ne vidimo v bazi podatkov. In razumeti moramo, kaj se jim je zgodilo.

Jasno je, da jih je pg_rewind spregledal. To smo takoj razumeli, a smo šli pogledat, kaj se dogaja.

V dnevnikih lahko vedno najdemo, kdaj se je zgodil filer, kdo je postal mojster in lahko ugotovimo, kdo je bil stari mojster in kdaj je želel postati replika, torej te dnevnike potrebujemo, da ugotovimo količino transakcijskih dnevnikov, ki jih je bil izgubljen.

Naš stari mojster se je znova zagnal. In Patroni je bil registriran v samodejnem zagonu. Lansiran Patroni. Nato je začel Postgres. Natančneje, pred zagonom Postgresa in preden je naredil repliko, je Patroni zagnal proces pg_rewind. V skladu s tem je izbrisal del transakcijskih dnevnikov, prenesel nove in se povezal. Tukaj je Patroni delal pametno, torej po pričakovanjih. Grozd je bil obnovljen. Imeli smo 3 vozlišča, po filerju 3 vozlišča - vse je kul.

Izgubili smo nekaj podatkov. In razumeti moramo, koliko smo izgubili. Iščemo samo trenutek, ko smo imeli previjanje nazaj. Najdemo ga v takih dnevnikih. Previjanje nazaj se je začelo, tam nekaj naredilo in končalo.

V dnevniku transakcij moramo najti položaj, kjer je stari mojster končal. V tem primeru je to oznaka. In potrebujemo drugo oznako, to je razdaljo, po kateri se stari mojster razlikuje od novega.

Vzamemo običajni pg_wal_lsn_diff in primerjamo ti dve oznaki. In v tem primeru dobimo 17 megabajtov. Veliko ali malo, vsak se odloči sam. Ker za nekoga 17 megabajtov ni veliko, za nekoga je veliko in nesprejemljivo. Tu se vsak posameznik sam odloča glede na potrebe posla.

Toda kaj smo ugotovili sami?

Najprej se moramo sami odločiti - ali potrebujemo, da se Patroni vedno samodejno zažene po ponovnem zagonu sistema? Velikokrat se zgodi, da moramo k staremu mojstru, pogledat, kako daleč je prišel. Morda preglejte segmente dnevnika transakcij, poglejte, kaj je tam. In razumeti, ali lahko te podatke izgubimo ali pa moramo zagnati starega masterja v samostojnem načinu, da te podatke potegnemo ven.

In šele nato se moramo odločiti, ali lahko te podatke zavržemo ali pa jih lahko obnovimo, povežemo to vozlišče kot repliko v našo gručo.

Poleg tega obstaja parameter "maximum_lag_on_failover". Če me spomin ne vara, ima ta parameter privzeto vrednost 1 megabajt.

Kako deluje? Če naša replika v zaostanku replikacije zaostaja za 1 megabajt podatkov, potem ta replika ne sodeluje pri volitvah. In če nenadoma pride do datoteke, Patroni pogleda, katere replike zaostajajo. Če zaostajajo za velikim številom dnevnikov transakcij, ne morejo postati mojster. To je zelo dobra varnostna funkcija, ki preprečuje izgubo veliko podatkov.

Toda tukaj je težava v tem, da se zamik podvajanja v gruči Patroni in DCS posodablja v določenem intervalu. Mislim, da je 30 sekund privzeta vrednost ttl.

V skladu s tem lahko pride do situacije, ko obstaja en zamik podvajanja za replike v DCS, dejansko pa je lahko popolnoma drugačen zamik ali pa ga sploh ni, kar pomeni, da ta stvar ni v realnem času. In ne odraža vedno prave slike. In ni vredno delati modne logike na tem.

In tveganje izgube vedno ostaja. In v najslabšem primeru ena formula, v povprečnem primeru pa druga formula. To pomeni, da ko načrtujemo implementacijo Patronija in ocenjujemo, koliko podatkov lahko izgubimo, se moramo zanašati na te formule in si približno predstavljati, koliko podatkov lahko izgubimo.

In tu je dobra novica. Ko je stari mojster šel naprej, lahko gre naprej zaradi nekih procesov v ozadju. Se pravi, bil je nekakšen avtovakuum, zapisal je podatke, jih shranil v dnevnik transakcij. In te podatke zlahka prezremo in izgubimo. V tem ni problema.

In tako izgledajo dnevniki, če je nastavljena maximum_lag_on_failover in je prišlo do datoteke in morate izbrati novega glavnega. Replika se ocenjuje kot nesposobna za udeležbo na volitvah. In noče sodelovati v tekmi za vodilnega. In počaka, da se izbere nov master, da se potem lahko poveže z njim. To je dodaten ukrep proti izgubi podatkov.

Tukaj imamo produktno skupino, ki je zapisala, da ima njihov izdelek težave s Postgresom. Hkrati do samega masterja ni mogoče dostopati, ker ni na voljo prek SSH. In tudi samodejna datoteka se ne zgodi.

Ta gostitelj se je moral znova zagnati. Zaradi ponovnega zagona se je zgodila samodejna datoteka, čeprav je bilo mogoče narediti ročno samodejno datoteko, kot zdaj razumem. In po ponovnem zagonu bomo že videli, kaj smo imeli s trenutnim mojstrom.

Hkrati smo že vnaprej vedeli, da imamo težave z diski, se pravi, da smo že iz spremljanja vedeli, kje kopati in kaj iskati.

Vstopili smo v dnevnik postgres in začeli opazovati, kaj se tam dogaja. Videli smo potrditve, ki tam trajajo eno, dve, tri sekunde, kar sploh ni normalno. Videli smo, da se naš avtovakuum zažene zelo počasi in čudno. In na disku smo videli začasne datoteke. Se pravi, vse to so znaki težav z diski.

Pogledali smo v sistemski dmesg (dnevnik jedra). In videli smo, da imamo težave z enim od diskov. Diskovni podsistem je bila programska oprema Raid. Pogledali smo /proc/mdstat in videli, da nam manjka en pogon. To pomeni, da obstaja Raid 8 diskov, manjka nam eden. Če natančno pogledate diapozitiv, lahko v izhodu vidite, da tam nimamo sde. Pri nas je, pogojno rečeno, disk izpadel. To je sprožilo težave z diskom, težave pa so imele tudi aplikacije pri delu z gručo Postgres.

In v tem primeru nam Patroni ne bi nič pomagal, saj Patroni nima naloge spremljati stanja strežnika, stanja diska. In takšne situacije moramo spremljati z zunanjim nadzorom. Zunanjemu nadzoru smo hitro dodali nadzor diska.

In pojavila se je taka misel - ali bi nam lahko pomagala programska oprema za ograje ali čuvaje? Mislili smo, da nam v tem primeru težko pomaga, saj je Patroni med težavami še naprej komuniciral z gručo DCS in ni videl nobene težave. Se pravi, z vidika DCS in Patronija je bilo z gručo vse v redu, čeprav so bile v resnici težave z diskom, težave z razpoložljivostjo baze podatkov.

Po mojem mnenju je to ena najbolj nenavadnih težav, ki sem jo raziskoval zelo dolgo, prebral sem veliko dnevnikov, ponovno izbral in jo poimenoval simulator gruče.

Težava je bila v tem, da stari mojster ni mogel postati običajna replika, tj. Patroni ga je zagnal, Patroni je pokazal, da je to vozlišče prisotno kot replika, a hkrati ni bila običajna replika. Zdaj boste videli zakaj. To sem zadržal pri analizi tega problema.

In kako se je vse začelo? Začelo se je, kot v prejšnji težavi, z disk zavorami. Imeli smo obveznosti za sekundo, dve.

Prišlo je do prekinitev povezav, tj. prekinitev strank.

Pojavile so se blokade različne resnosti.

In zato diskovni podsistem ni zelo odziven.

In najbolj skrivnostna stvar zame je prispela zahteva za takojšnjo zaustavitev. Postgres ima tri načine zaustavitve:

• Lepo je, ko čakamo, da se vsi odjemalci sami odklopijo.
• Hitro je, ko odjemalce prisilimo v prekinitev povezave, ker se nameravamo zaustaviti.
• In takoj. V tem primeru immediate odjemalcem niti ne sporoči, naj se zaustavijo, samo izklopi se brez opozorila. In vsem odjemalcem operacijski sistem že pošlje RST sporočilo (TCP sporočilo, da je povezava prekinjena in odjemalec nima več kaj loviti).

Kdo je poslal ta signal? Procesi v ozadju Postgres drug drugemu ne pošiljajo takih signalov, to je kill-9. Takih stvari si ne pošiljajo, na take stvari se samo odzovejo, torej gre za nujni ponovni zagon Postgresa. Kdo ga je poslal, ne vem.

Pogledal sem "zadnji" ukaz in videl eno osebo, ki se je prav tako prijavila na ta strežnik z nami, vendar sem bil preveč sramežljiv, da bi postavil vprašanje. Morda je bilo ubijanje -9. V dnevnikih bi videl kill -9, ker Postgres pravi, da je potreboval kill -9, vendar tega nisem videl v dnevnikih.

Če pogledam naprej, sem videl, da Patroni ni pisal v dnevnik precej dolgo - 54 sekund. In če primerjamo dva časovna žiga, ni bilo sporočil približno 54 sekund.

In v tem času je bila samodejna datoteka. Patroni je tudi tukaj opravil odlično delo. Naš stari gospodar ni bil na voljo, nekaj se mu je zgodilo. In začele so se volitve novega gospodarja. Tukaj se je vse dobro izšlo. Naš pgsql01 je postal novi vodja.

Imamo repliko, ki je postala mojster. In obstaja drugi odgovor. In z drugo repliko so bile težave. Poskušala je preoblikovati. Kolikor razumem, je poskušala spremeniti recovery.conf, znova zagnati Postgres in se povezati z novim masterjem. Vsakih 10 sekund piše sporočila, da se trudi, a ji ne uspe.

In med temi poskusi prispe do starega mojstra signal za takojšen izklop. Master se ponovno zažene. In tudi obnovitev se ustavi, ker gre stari mojster v ponovni zagon. To pomeni, da se replika ne more povezati z njo, ker je v načinu zaustavitve.

Na neki točki je delovalo, vendar se replikacija ni začela.

Moja edina domneva je, da je bil v recovery.conf star glavni naslov. In ko se je pojavil nov mojster, se je druga replika še vedno poskušala povezati s starim mojstrom.

Ko je Patroni zagnal drugo repliko, se je vozlišče zagnalo, vendar se ni moglo podvojiti. In nastal je replikacijski zamik, ki je bil videti nekako takole. To pomeni, da so bila vsa tri vozlišča na svojem mestu, vendar je drugo vozlišče zaostajalo.

Istočasno, če pogledate zapisane dnevnike, lahko vidite, da se replikacija ni mogla začeti, ker so bili dnevniki transakcij drugačni. In tisti dnevniki transakcij, ki jih ponuja master in so navedeni v recovery.conf, preprosto ne ustrezajo našemu trenutnemu vozlišču.

In tukaj sem naredil napako. Moral sem priti pogledat, kaj je v recovery.conf, da preizkusim svojo hipotezo, da se povezujemo z napačnim masterjem. Ampak takrat sem se samo ukvarjal s tem in mi ni prišlo na misel, ali pa sem videl, da replika zaostaja in jo bo treba napolniti, se pravi, da sem nekako malomarno delal. To je bil moj joint.

Po 30 minutah je že prišel admin, tj. ponovno sem zagnal Patroni na repliki. Temu sem že naredil konec, mislil sem, da ga bo treba napolniti. In pomislil sem - ponovno bom zagnal Patronija, morda se bo izkazalo kaj dobrega. Okrevanje se je začelo. In baza se je celo odprla, pripravljena je sprejemati povezave.

Replikacija se je začela. Ampak minuto kasneje je odpadla z napako, da transakcijski dnevniki niso primerni zanjo.

Mislil sem, da bi znova začel. Ponovno sem zagnal Patroni in nisem znova zagnal Postgresa, ampak ponovno zagnal Patroni v upanju, da bo čarobno zagnal bazo podatkov.

Replikacija se je znova začela, vendar so bile oznake v dnevniku transakcij drugačne, niso bile enake prejšnjemu poskusu zagona. Replikacija se je znova ustavila. In že je bilo sporočilo nekoliko drugačno. In zame ni bilo preveč informativno.

In potem mi pride na misel - kaj če ponovno zaženem Postgres, v tem času naredim kontrolno točko na trenutnem masterju, da premaknem točko v dnevniku transakcij malo naprej, da se obnovitev začne od drugega trenutka? Poleg tega smo imeli še vedno zaloge WAL.

Ponovno sem zagnal Patronija, naredil nekaj kontrolnih točk na masterju, nekaj ponovnih zagonov na repliki, ko se je odprla. In pomagalo je. Dolgo sem razmišljal, zakaj je pomagalo in kako deluje. In replika se je začela. In replikacija ni bila več raztrgana.

Takšna težava je zame ena bolj skrivnostnih, nad katero še vedno begam, kaj se je tam res zgodilo.

Kakšne so posledice tukaj? Patroni lahko deluje kot je predvideno in brez napak. Toda to hkrati ni 100% zagotovilo, da je z nami vse v redu. Replika se lahko zažene, vendar je lahko v napol delujočem stanju in aplikacija s takšno repliko ne more delovati, ker bodo stari podatki.

In po datoteki morate vedno preveriti, ali je z grozdom vse v redu, to je, da obstaja zahtevano število replik, ni zaostanka replikacije.

In ko bomo obravnavali ta vprašanja, bom podal priporočila. Poskušal sem jih združiti v dva diapozitiva. Verjetno bi lahko vse zgodbe združili v dva diapozitiva in jih samo povedali.

Ko uporabljate Patroni, morate imeti nadzor. Vedno morate vedeti, kdaj je prišlo do samodejnega preklopa datotek, kajti če ne veste, da ste imeli samodejni preklop datotek, nimate nadzora nad gručo. In to je slabo.

Po vsakem filerju moramo vedno ročno preveriti gručo. Poskrbeti moramo, da imamo vedno posodobljeno število replik, da ni zaostanka replikacije, da ni napak v dnevnikih, povezanih s pretočno replikacijo, s Patronijem, s sistemom DCS.

Avtomatizacija lahko deluje uspešno, Patroni je zelo dobro orodje. Lahko deluje, vendar to ne bo pripeljalo grozda v želeno stanje. In če za to ne izvemo, bomo v težavah.

In Patroni ni srebrna krogla. Še vedno moramo razumeti, kako deluje Postgres, kako deluje replikacija in kako Patroni deluje s Postgresom ter kako je zagotovljena komunikacija med vozlišči. To je potrebno, da lahko z rokami odpravite težave.

Kako naj pristopim k vprašanju diagnoze? Tako se je zgodilo, da delamo z različnimi strankami in nihče nima sklada ELK, dnevnike pa moramo urejati tako, da odpremo 6 konzol in 2 zavihka. V enem zavihku so to dnevniki Patronija za vsako vozlišče, v drugem zavihku pa dnevniki Consul ali po potrebi Postgres. To je zelo težko diagnosticirati.

Kakšne pristope sem razvil? Najprej vedno pogledam, kdaj je filer prišel. In zame je to prelomnica. Gledam, kaj se je zgodilo pred filerjem, med filerjem in po filerju. Fileover ima dve oznaki: to je začetni in končni čas.

Nato v logih poiščem dogodke pred filerjem, ki so bili pred filerjem, torej iščem razloge, zakaj je prišlo do filera.

In to daje sliko razumevanja, kaj se je zgodilo in kaj je mogoče storiti v prihodnosti, da do takšnih okoliščin ne pride (in posledično ni datoteke).

In kam ponavadi gledamo? Gledam:

• Najprej k dnevnikom Patroni.
• Nato pogledam dnevnike Postgres ali dnevnike DCS, odvisno od tega, kaj je bilo najdeno v dnevnikih Patronija.
• In sistemski dnevniki včasih tudi povedo, kaj je povzročilo datoteko.

Kako se počutim glede Patronija? S Patronijem imam zelo dober odnos. Po mojem mnenju je to najboljše, kar je danes. Poznam še veliko drugih izdelkov. To so Stolon, Repmgr, Pg_auto_failover, PAF. 4 orodja. Poskusila sem vse. Patroni je moj najljubši.

Če me vprašajo: "Ali priporočam Patroni?". Rekel bom da, ker mi je všeč Patroni. In mislim, da sem se ga naučil kuhati.

Če vas poleg težav, ki sem jih omenil, zanimajo še druge težave s Patronijem, si lahko vedno ogledate stran Vprašanja na GitHubu. Tam je veliko različnih zgodb in veliko zanimivih vprašanj. In posledično so bile uvedene in odpravljene nekatere napake, se pravi, to je zanimivo branje.

Obstaja nekaj zanimivih zgodb o ljudeh, ki so se ustrelili v stopalo. Zelo informativno. Preberete in razumete, da to ni potrebno. Obkljukal sem se.

Rad bi se zahvalil Zalandu za razvoj tega projekta, in sicer Aleksandru Kukuškinu in Alekseju Kljukinu. Aleksej Kljukin je eden od soavtorjev, ne dela več pri Zalandu, vendar sta to dve osebi, ki sta se začela ukvarjati s tem izdelkom.

In mislim, da je Patroni zelo kul stvar. Vesela sem, da obstaja, z njo je zanimivo. In velika hvala vsem sodelujočim, ki pišejo popravke za Patron. Upam, da bo Patroni z leti postal bolj zrel, hladen in učinkovit. Deluje že, ampak upam, da bo še bolje. Torej, če nameravate uporabljati Patroni, potem se ne bojte. To je dobra rešitev, jo je mogoče implementirati in uporabiti.

To je vse. Če imate vprašanja, vprašajte.

vprašanja

Hvala za poročilo! Če morate po filerju še vedno zelo natančno pogledati, zakaj potem potrebujemo avtomatski filer?

Ker je nova stvar. Z njo sva komaj eno leto. Bolje je biti varen. Želimo priti in videti, da je res vse potekalo tako, kot se mora. To je stopnja nezaupanja odraslih - bolje je dvakrat preveriti in videti.

Na primer, zjutraj smo šli in pogledali, kajne?

Ne zjutraj, za samodejno datoteko običajno izvemo skoraj takoj. Prejmemo obvestila, vidimo, da je prišlo do samodejne datoteke. Skoraj takoj gremo pogledat. Toda vse te preglede je treba spraviti na raven spremljanja. Če do Patronija dostopate prek API-ja REST, obstaja zgodovina. V zgodovini lahko vidite časovne žige, ko se je datoteka zgodila. Na podlagi tega se lahko izvede spremljanje. Lahko vidite zgodovino, koliko dogodkov je bilo tam. Če imamo več dogodkov, je prišlo do samodejne datoteke. Lahko greš pogledat. Ali pa je naša avtomatizacija za spremljanje preverila, ali imamo vse replike na svojem mestu, ni zamikov in je vse v redu.

Hvala!

Najlepša hvala za odlično zgodbo! Če smo DCS gručo premaknili nekam daleč od Postgresove, potem je treba tudi to gručo občasno servisirati? Katere so najboljše prakse, da je treba nekatere dele gruče DCS izklopiti, z njimi kaj narediti itd.? Kako ta celotna struktura preživi? In kako počnete te stvari?

Za eno podjetje je bilo treba narediti matriko problemov, kaj se zgodi, če ena od komponent ali več komponent odpove. Po tej matriki gremo zaporedno skozi vse komponente in gradimo scenarije v primeru okvare teh komponent. V skladu s tem lahko imate za vsak scenarij okvare akcijski načrt za obnovitev. In v primeru DCS je del standardne infrastrukture. In skrbnik to upravlja, mi pa se že zanašamo na skrbnike, ki to upravljajo, in njihovo sposobnost, da to popravijo v primeru nesreč. Če DCS sploh ni, ga postavimo, vendar ga hkrati ne spremljamo posebej, ker nismo odgovorni za infrastrukturo, ampak dajemo priporočila, kako in kaj spremljati.

Se pravi, ali sem pravilno razumel, da moram onemogočiti Patronija, onemogočiti datoteko, onemogočiti vse, preden karkoli naredim z gostitelji?

Odvisno je od tega, koliko vozlišč imamo v gruči DCS. Če je vozlišč veliko in če onemogočimo samo eno od vozlišč (repliko), potem gruča vzdržuje kvorum. In Patroni ostaja operativen. In nič se ne sproži. Če imamo nekaj zapletenih operacij, ki vplivajo na več vozlišč, katerih odsotnost lahko uniči sklepčnost, potem - da, morda bi bilo smiselno, da Patroni postavimo na premor. Ima ustrezen ukaz - patronictl premor, patronictl nadaljevanje. Samo začasno ustavimo in samodejni datoteko takrat ne deluje. Opravimo vzdrževanje na DCS gruči, nato prekinemo pavzo in nadaljujemo z življenjem.

Najlepša hvala!

Najlepša hvala za vaše poročilo! Kako se ekipa izdelka počuti glede izgube podatkov?

Produktnim ekipam je vseeno, vodje ekip pa so zaskrbljene.

Kakšna so jamstva?

Garancije so zelo težke. Alexander Kukushkin ima poročilo »Kako izračunati RPO in RTO«, tj. čas obnovitve in koliko podatkov lahko izgubimo. Mislim, da moramo najti te diapozitive in jih preučiti. Kolikor se spomnim, obstajajo posebni koraki, kako izračunati te stvari. Koliko transakcij lahko izgubimo, koliko podatkov lahko izgubimo. Kot možnost lahko uporabimo sinhrono replikacijo na ravni Patronija, vendar je to dvorezen meč: ali imamo zanesljivost podatkov ali izgubimo hitrost. Obstaja sinhrono podvajanje, vendar tudi ne zagotavlja 100-odstotne zaščite pred izgubo podatkov.

Alexey, hvala za odlično poročilo! Imate kakšne izkušnje z uporabo Patronija za ničelno zaščito? Se pravi v povezavi s sinhrono pripravljenostjo? To je prvo vprašanje. In drugo vprašanje. Uporabili ste različne rešitve. Uporabili smo Repmgr, vendar brez autofilerja, zdaj pa načrtujemo vključitev autofilerja. Patron smatramo kot alternativno rešitev. Kaj lahko rečete kot prednosti v primerjavi z Repmgr?

Prvo vprašanje je bilo o sinhronih replikah. Tukaj nihče ne uporablja sinhrone replikacije, ker se vsi bojijo (več strank jo že uporablja, načeloma niso opazili težav z zmogljivostjo - Beseda govornika). Vendar smo zase razvili pravilo, da morajo biti v gruči sinhrone replikacije vsaj tri vozlišča, kajti če imamo dve vozlišči in če glavno ali replika odpove, potem Patroni to vozlišče preklopi v samostojni način, tako da aplikacija nadaljuje delo. V tem primeru obstaja nevarnost izgube podatkov.

Kar zadeva drugo vprašanje, smo uporabljali Repmgr in ga še vedno uporabljamo pri nekaterih strankah zaradi zgodovinskih razlogov. Kaj je mogoče reči? Patroni ima avtomatsko datoteko takoj po izdelavi, Repmgr ima samodejno datoteko kot dodatno funkcijo, ki jo je treba omogočiti. Na vsakem vozlišču moramo zagnati demon Repmgr, nato pa lahko konfiguriramo samodejno datoteko.

Repmgr preveri, ali so vozlišča Postgres živa. Procesi repmgr preverjajo medsebojni obstoj, to ni zelo učinkovit pristop. lahko pride do zapletenih primerov izolacije omrežja, v katerih lahko velika gruča Repmgr razpade na več manjših in nadaljuje z delom. Repmgr že dolgo ne spremljam, mogoče je bilo popravljeno ... ali pa tudi ne. Toda odstranitev informacij o stanju gruče v DCS, kot to počne Stolon, Patroni, je najbolj izvedljiva možnost.

Alexey, imam vprašanje, morda lamersko. V enem od prvih primerov ste premaknili DCS z lokalnega računalnika na oddaljenega gostitelja. Zavedamo se, da je omrežje stvar, ki ima svoje značilnosti, živi sama od sebe. In kaj se zgodi, če iz nekega razloga gruča DCS postane nedosegljiva? Ne bom povedal razlogov, lahko jih je veliko: od ukrivljenih rok omrežnikov do resničnih težav.

Tega nisem rekel na glas, vendar mora biti tudi gruča DCS nadomestna, tj. to je liho število vozlišč, da je sklepčnost izpolnjena. Kaj se zgodi, če gruča DCS postane nedosegljiva ali ni mogoče doseči kvoruma, tj. nekakšna razdelitev omrežja ali okvara vozlišča? V tem primeru gre gruča Patroni v način samo za branje. Gruča Patroni ne more določiti stanja gruče in kaj storiti. Ne more vzpostaviti stika z DCS in tam shraniti novega stanja gruče, zato gre celotna gruča v način samo za branje. In čaka na ročno posredovanje operaterja ali na DCS, da si opomore.

Grobo povedano postane DCS za nas tako pomembna storitev kot sama baza?

Da Da. V mnogih sodobnih podjetjih je odkrivanje storitev sestavni del infrastrukture. Izvaja se, še preden je sploh obstajala baza podatkov v infrastrukturi. Relativno rečeno, infrastruktura je bila lansirana, razporejena v DC in takoj imamo odkrivanje storitev. Če je Consul, potem je DNS mogoče zgraditi na njem. Če je to Etcd, potem je morda del iz gruče Kubernetes, v katerega bo razporejeno vse ostalo. Zdi se mi, da je Service Discovery že sestavni del sodobnih infrastruktur. In o tem razmišljajo veliko prej kot o bazah podatkov.

Hvala!

Vir: www.habr.com