Storie di fallimentu Patroni o Cumu crash u vostru cluster PostgreSQL. Alexey Lesovsky

L'obiettivu principale di Patroni hè di furnisce Alta Disponibilità per PostgreSQL. Ma Patroni hè solu un mudellu, micca un strumentu ready-made (chì, in generale, hè dettu in a documentazione). À u primu sguardu, dopu avè stallatu Patroni in u labburatoriu di teste, pudete vede ciò chì hè un grande strumentu è quantu facilmente gestisce i nostri tentativi di rompe u cluster. Tuttavia, in pratica, in un ambiente di pruduzzione, tuttu ùn succede micca sempre cusì bellu è elegante cum'è in un laboratoriu di teste.

Vi dicu un pocu di mè stessu. Aghju cuminciatu cum'è amministratore di sistema. Hà travagliatu in u sviluppu web. Aghju travagliatu in Data Egret dapoi u 2014. A cumpagnia hè impegnata in cunsulenza in u campu di Postgres. È servimu esattamente Postgres, è travagliemu cù Postgres ogni ghjornu, cusì avemu una sperienza diversa in relazione à l'operazione.

È à a fine di 2018, avemu cuminciatu à aduprà Patroni pianu pianu. È una certa sperienza hè stata accumulata. L'avemu in qualche modu diagnosticatu, sintonizatu, ghjuntu à e nostre migliori pratiche. È in stu rapportu vi parleraghju di elli.

A parte di Postgres, mi piace Linux. Mi piace à spiegà in ellu è scopre, mi piace à cullà i core. Amu a virtualizazione, cuntenituri, docker, Kubernetes. Tuttu chistu m'interessa, perchè i vechji abitudini di l'amministratori sò affettati. Mi piace à trattà cù u monitoraghju. È mi piace e cose postgres relative à l'amministrazione, vale à dì a replicazione, a copia di salvezza. È in u mo tempu liberu scrivu in Go. Ùn sò micca un ingegnere di software, scrivu solu per mè stessu in Go. È mi dà piacè.

• Pensu chì parechji di voi sapete chì Postgres ùn hà micca HA (Alta Disponibilità) fora di a scatula. Per uttene HA, avete bisognu di installà qualcosa, cunfigurà, fate un sforzu è uttene.
• Ci sò parechji arnesi è Patroni hè unu di elli chì risolve HA abbastanza cool è assai bè. Ma mettendu tuttu in un labburatoriu di prova è eseguisce, pudemu vede chì tuttu funziona, pudemu ripruduce qualchi prublemi, vede cumu Patroni li serve. È videremu chì tuttu funziona bè.
• Ma in pratica, avemu affruntatu diversi prublemi. È parleraghju di sti prublemi.
• Vi dicu cumu l'avemu diagnosticatu, ciò chì avemu aghjustatu - s'ellu ci hà aiutatu o micca.

• Ùn vi diceraghju micca cumu installà Patroni, perchè pudete google nantu à Internet, pudete guardà i schedarii di cunfigurazione per capisce cumu tuttu principia, cumu hè cunfiguratu. Pudete capisce i schemi, architetture, truvà infurmazione nantu à Internet.
• Ùn parleraghju micca di l'esperienza di qualcunu altru. Parlaraghju solu di i prublemi chì avemu affruntatu.
• È ùn parleraghju micca di prublemi chì sò fora di Patroni è PostgreSQL. Se, per esempiu, ci sò prublemi assuciati cù l'equilibriu, quandu u nostru cluster hè colapsatu, ùn ne parleraghju micca.

È una piccula disclaimer prima di inizià u nostru rapportu.

Tutti questi prublemi chì avemu scontru, avemu avutu in i primi 6-7-8 mesi di operazione. À u tempu, avemu ghjuntu à e nostre migliori pratiche interne. È i nostri prublemi sò spariti. Per quessa, u rapportu hè statu annunziatu circa sei mesi fà, quandu era tuttu frescu in a mo testa è mi ricurdò tuttu perfettamente.

In u cursu di a preparazione di u rapportu, aghju digià risuscitatu vechji postmortems, fighjatu i logs. È certi di i ditagli puderanu esse scurdati, o alcuni di certi ditaglii ùn puderanu micca esse investigati cumplettamente durante l'analisi di i prublemi, cusì in certi punti pò pare chì i prublemi ùn sò micca cunsiderati cumplettamente, o ci hè una mancanza d'infurmazioni. È cusì vi dumandu di scusa per stu mumentu.

Cosa hè Patroni ?

• Questu hè un mudellu per custruisce HA. Hè ciò chì dice in a documentazione. È da u mo puntu di vista, questu hè una chiarificazione assai curretta. Patroni ùn hè micca una bala d'argentu chì risolverà tutti i vostri prublemi, vale à dì, avete bisognu di fà un sforzu per fà u travagliu è portà benefici.
• Questu hè un serviziu d'agente chì hè stallatu nantu à ogni serviziu di basa di dati è hè un tipu di sistema init per u vostru Postgres. Cumincia Postgres, ferma, riavvia, riconfigura, è cambia a topologia di u vostru cluster.
• In cunsiquenza, per almacenà u statu di u cluster, a so rapprisintazioni attuale, cum'è pare, un certu tipu di almacenamiento hè necessariu. E da stu puntu di vista, Patroni hà pigliatu a strada di u statu di almacenamentu in un sistema esternu. Hè un sistema di almacenamentu di cunfigurazione distribuitu. Pò esse Etcd, Consul, ZooKeeper, o kubernetes Etcd, vale à dì una di queste opzioni.
• È una di e caratteristiche di Patroni hè chì avete l'autofiler fora di a scatula, solu da a stallazione. Se pigliamu Repmgr per paragunà, allora u filer hè inclusu quì. Cù Repmgr, avemu un cambiamentu, ma se vulemu un autofiler, allora avemu bisognu di cunfigurà in più. Patroni hà digià un autofiler fora di a scatula.
• È ci sò parechje altre cose. Per esempiu, mantenimentu di cunfigurazioni, pouring new replicas, backup, etc. Ma questu hè fora di u scopu di u rapportu, ùn ne parleraghju micca.

È un picculu risultatu hè chì u compitu principale di Patroni hè di fà un autofile bè è affidabile per chì u nostru cluster resta operativu è l'applicazione ùn nota micca cambiamenti in a topologia di cluster.

Ma quandu avemu principiatu cù Patroni, u nostru sistema diventa un pocu più cumplicatu. Se prima avemu avutu Postgres, allora quandu usendu Patroni avemu Patroni stessu, avemu DCS induve u statu hè almacenatu. È tuttu hà da travaglià in qualchì modu. Allora chì pò sbaglià?

Pò rompe:

• Postgres puderia rompe. Pò esse un maestru o una replica, unu di elli pò fallu.
• U Patroni stessu pò rompe.
• U DCS induve u statu hè almacenatu pò rompe.
• È a reta pò rompe.

Tutti questi punti vi cunsiderà in u rapportu.

Cunsidereraghju i casi cumu diventanu più cumplessi, micca da u puntu di vista chì u casu implica assai cumpunenti. E da u puntu di vista di i sentimenti subjectivi, chì questu casu era difficiule per mè, era difficiule di disassemble ... è vice versa, qualchì casu era ligeru è era faciule di disassemble.

È u primu casu hè u più faciule. Questu hè u casu quandu avemu pigliatu un cluster di basa di dati è implementatu u nostru almacenamiento DCS in u stessu cluster. Questu hè u sbagliu più cumuni. Questu hè un sbagliu in l'architettura di custruzzione, vale à dì, cumminendu diverse cumpunenti in un locu.

Allora, ci era un filer, andemu à trattà di ciò chì hè accadutu.

È quì ci interessa quandu u filer hè accadutu. Vale à dì, avemu interessatu in questu mumentu in u tempu quandu u statu di cluster hà cambiatu.

Ma u filler ùn hè micca sempre istantaneu, vale à dì ùn piglia micca unità di tempu, pò esse ritardatu. Pò esse longu.

Dunque, hà un tempu di iniziu è un tempu di fine, vale à dì hè un avvenimentu cuntinuu. E dividimu tutti l'avvenimenti in trè intervalli: avemu u tempu prima di u filer, durante u filer è dopu à u filer. Vale à dì, cunsideremu tutti l'avvenimenti in questa timeline.

È a prima cosa, quandu un filer hè accadutu, cercamu a causa di ciò chì hè accadutu, quale era a causa di ciò chì hà purtatu à u filer.

S'è no guardemu à i ghjurnali, seranu logs Patroni classic. Ci dice in elli chì u servitore hè diventatu u maestru, è u rolu di u maestru hè passatu à questu node. Quì hè evidenziatu.

In seguitu, avemu bisognu di capisce perchè u filer hè accadutu, vale à dì chì avvenimenti accaduti chì anu causatu u rolu di maestru per passà da un node à l'altru. È in questu casu, tuttu hè simplice. Avemu un errore in l'interazzione cù u sistema di almacenamento. U maestru hà capitu chì ùn pudia micca travaglià cù DCS, vale à dì, ci era qualchì tipu di prublema cù l'interazzione. È dici ch'ellu ùn pò più esse maestru è dimissioni. Questa linea "demoted self" dice esattamente questu.

Se guardemu l'avvenimenti chì precedevanu u filer, pudemu vede quì i ragiuni assai chì eranu u prublema per a continuazione di u mago.

S'è no guardemu à i logs Patroni, avemu da vede chì avemu assai errori, timeouts, vale à dì l'agente Patroni ùn pò micca travaglià cù DCS. In questu casu, questu hè l'agente Consul, chì hè cumunicatu nantu à u portu 8500.

È u prublema quì hè chì Patroni è a basa di dati sò in u stessu òspite. È i servitori Consul sò stati lanciati nantu à u stessu node. Creendu una carica nantu à u servitore, avemu criatu prublemi ancu per i servitori Consul. Ùn pudianu micca cumunicà bè.

Dopu qualchì tempu, quandu a carica si calava, u nostru Patroni hà sappiutu cumunicà cù l'agenti di novu. U travagliu nurmale ripresa. È u stessu servitore Pgdb-2 hà tornatu u maestru. Vale à dì, ci era un picculu flip, per via di u quale u node rinunziò i puteri di u maestru, è poi ripigliò di novu, vale à dì, tuttu tornò cum'è era.

È questu pò esse cunsideratu cum'è una falsa alarme, o pò esse cunsideratu chì Patroni hà fattu tuttu bè. Questu hè, hà capitu chì ùn pudia micca mantene u statu di u cluster è sguassate a so autorità.

E quì u prublema hè ghjuntu per u fattu chì i servitori Consul sò in u stessu hardware cum'è e basi. In cunsiquenza, ogni carica: s'ellu hè a carica nantu à dischi o prucessori, affetta ancu l'interazzione cù u cluster Consul.

È avemu decisu chì ùn deve micca campà inseme, avemu attribuitu un cluster separatu per Consul. È Patroni hà digià travagliatu cù un Consul separatu, vale à dì, ci era un cluster separatu di Postgres, un cluster separatu di Consul. Questa hè una struzzione basica nantu à cumu portà è mantene tutte queste cose per ùn campà inseme.

Comu opzione, pudete torce i paràmetri ttl, loop_wait, retry_timeout, vale à dì pruvà à sopravvive à questi picchi di carica di cortu termine aumentendu questi paràmetri. Ma questu ùn hè micca l'opzione più adatta, perchè sta carica pò esse longu in u tempu. È andemu simpricimenti fora di sti limiti di sti paràmetri. È questu puderia micca veramente aiutà.

U primu prublema, cum'è avete capitu, hè simplice. Avemu pigliatu è mette u DCS inseme cù a basa, avemu avutu un prublema.

U sicondu prublema hè simile à u primu. Hè simile in quantu avemu novu prublemi di interoperabilità cù u sistema DCS.

Sè avemu guardà à i logs, avemu da vede chì avemu dinò un errore di cumunicazione. È Patroni dice chì ùn possu micca interagisce cù DCS, cusì u maestru attuale passa in modu di replica.

U vechju maestru diventa una replica, quì Patroni travaglia, cum'è deve esse. Esegue pg_rewind per rinvià u logu di transazzione è dopu cunnette cù u novu maestru per piglià u novu maestru. Quì Patroni travaglia, cum'ellu deve.

Quì ci vole à truvà u locu chì precede u filer, vale à dì quelli errori chì ci anu causatu à avè un filer. È in stu riguardu, i logs Patroni sò abbastanza còmuda di travaglià. Scrive i stessi missaghji à un certu intervallu. E si cuminciamu à scrolling through these logs rapidamente, allora avemu da vede da i logs chì i logs anu cambiatu, chì significa chì certi prublemi sò cuminciati. Riturnemu prestu in questu locu, vedi ciò chì succede.

È in una situazione normale, i logs pareanu qualcosa cusì. U pruprietariu di a serratura hè verificatu. È se u pruprietariu, per esempiu, hà cambiatu, allora alcuni avvenimenti ponu accade chì Patroni deve risponde. Ma in questu casu, simu bè. Cerchemu u locu induve l'errori cuminciaru.

E avendu scrollatu à u puntu induve l'errori cuminciaru à apparisce, vedemu chì avemu avutu un auto-fileover. E postu chì i nostri errori eranu ligati à l'interazzione cù DCS è in u nostru casu avemu usatu Consul, avemu ancu vede à i logs Consul, ciò chì hè accadutu.

Apprussimatamente paragunendu u tempu di u filer è u tempu in i logs Consul, vedemu chì i nostri vicini in u cluster Consul accuminciaru à dubbità l'esistenza di l'altri membri di u cluster Consul.

È s'è tù dinù fighjulà à i logs di altri agenti Consul, vi ponu dinù vede chì qualchi tipu di colaps reta hè accadutu ci. È tutti i membri di u gruppu Consul dubitanu l'esistenza di l'altri. È questu era l'impetu per u filer.

Sè vo fighjulà ciò chì hè accadutu prima di sti errori, vi ponu vede chì ci sò tutti i speci di errori, per esempiu, scadenza, RPC falò, chì hè, ci hè chjaramente qualchi tipu di prublema in l 'interazzione di i membri di u cluster Consul cù ogni altru .

A risposta più simplice hè di riparà a reta. Ma per mè, standu nantu à u podium, hè faciule di dì questu. Ma e circustanze sò tali chì micca sempre u cliente pò permette di riparà a reta. Puderà vive in una DC è ùn pò micca esse capace di riparà a reta, affettanu l'equipaggiu. È cusì ci sò bisognu di altre opzioni.

Ci sò opzioni:

• L'opzione più simplice, chì hè scritta, in my opinion, ancu in a ducumentazione, hè di disattivà i cuntrolli di Consul, vale à dì, passanu solu un array viotu. È dicemu à l'agente di u Cunsul di ùn aduprà micca cuntrolli. Cù questi cuntrolli, pudemu ignurà queste tempeste di rete è micca inizià un filer.
• Un'altra opzione hè di verificà raft_multiplier. Questu hè un paràmetru di u servitore Consul stessu. Per automaticamente, hè stabilitu à 5. Stu valore hè cunsigliatu da a documentazione per l'ambienti di staging. In fatti, stu affetta a freccia di messageria trà i membri di a reta Consul. In fatti, stu paràmetru affetta a vitezza di cumunicazione serviziu trà i membri di u cluster Consul. È per a pruduzzione, hè digià cunsigliatu di riduzzione in modu chì i nodi scambià missaghji più spessu.
• Un'altra opzione chì avemu ghjuntu hè di aumentà a priorità di i prucessi Consul trà altri prucessi per u pianificatore di u sistema upirativu. Ci hè un paràmetru cusì "bellu", solu determina a priorità di i prucessi chì hè cunsideratu da u pianificatore di u SO quandu u prugramma. Avemu ancu ridutta u bonu valore per l'agenti Consul, i.e. cresce u priurità cusì chì u sistema upirativu dà Consul prucessi di più tempu à travaglià è esecutà u so codice. In u nostru casu, questu risolve u nostru prublema.
• Un'altra opzione hè micca di utilizà Consul. Aghju un amicu chì hè un gran sustegnu di Etcd. È regularmente discutemu cun ellu quale hè megliu Etcd o Consul. Ma in termini di quale hè megliu, di solitu accunsenu cun ellu chì u Cunsul hà un agentu chì deve esse in esecuzione nantu à ogni node cù una basa di dati. Questu hè, l'interazzione di Patroni cù u cluster Consul passa per questu agentu. È questu agentu diventa un collu di buttiglia. Se qualcosa succede à l'agente, Patroni ùn pò più travaglià cù u cluster Consul. È questu hè u prublema. Ùn ci hè micca agentu in u pianu Etcd. Patroni pò travaglià direttamente cù una lista di servitori Etcd è digià cumunicà cun elli. In stu riguardu, s'è vo aduprate Etcd in a vostra cumpagnia, allura Etcd sarà prubabilmente una scelta megliu cà Consul. Ma noi à i nostri clienti sò sempre limitati da ciò chì u cliente hà sceltu è usa. È avemu Consul per a maiò parte per tutti i clienti.
• È l'ultimu puntu hè di rivisione i valori di i paràmetri. Pudemu susciteghja questi paràmetri in a speranza chì i nostri prublemi di rete à cortu termine seranu brevi è ùn cascà micca fora di a gamma di questi paràmetri. In questu modu, pudemu riduce l'aggressività di Patroni à l'autofile se alcuni prublemi di rete sò.

Pensu chì parechji chì utilizanu Patroni sò familiarizati cù questu cumandamentu.

Questu cumanda mostra u statu attuale di u cluster. È à u primu sguardu, sta stampa pò parè normale. Avemu un maestru, avemu una replica, ùn ci hè micca un lag di replicazione. Ma sta stampa hè normale esattamente finu à chì sapemu chì stu cluster deve avè trè nodi, micca dui.

Per quessa, ci era un autofile. È dopu à questu autofile, a nostra replica hè sparita. Avemu bisognu di scopre perchè ella hè sparita è di rinvià, di ristabilisce. È andemu di novu à i logs è vede perchè avemu avutu un auto-fileover.

In questu casu, a seconda replica diventò u maestru. Hè tuttu bè quì.

È avemu bisognu di guardà a replica chì hè cascata è chì ùn hè micca in u cluster. Avemu apertu i logs Patroni è vede chì avemu avutu un prublema durante u prucessu di cunnessione à u cluster in u stadiu pg_rewind. Per cunnette à u cluster, avete bisognu di rinvià u logu di transazzione, dumandate u logu di transazzione necessariu da u maestru, è l'utilizate per piglià u maestru.

In questu casu, ùn avemu micca un logu di transazzione è a replica ùn pò micca inizià. Per quessa, fermamu Postgres cù un errore. È per quessa ùn hè micca in u cluster.

Avemu bisognu di capisce perchè ùn hè micca in u cluster è perchè ùn ci era micca logs. Andemu à u novu maestru è fighjemu ciò chì hà in i logs. Ci hè chì quandu pg_rewind hè statu fattu, un puntu di cuntrollu hè accadutu. E alcuni di i vechji logs di transazzione sò stati semplicemente rinominati. Quandu u vechju maestru hà pruvatu à cunnette cù u novu maestru è interrogà questi logs, sò stati digià rinominati, solu ùn esistenu micca.

Aghju paragunatu timestamps quandu questi avvenimenti sò accaduti. E quì a diffarenza hè literalmente 150 millisecondi, vale à dì, u puntu di cuntrollu cumpletu in 369 millisecondi, i segmenti WAL sò stati rinominati. È littiralmenti in 517, dopu à 150 millisecondi, u rewind hà iniziatu nantu à a vechja replica. Questu hè, literalmente 150 millisecondi era abbastanza per noi per chì a replica ùn pudia micca cunnette è guadagnà.

Chì sò l'opzioni?

Avemu inizialmente utilizatu slot di replicazione. Avemu pensatu chì era bonu. Ancu s'è in u primu stadiu di u funziunamentu avemu disattivatu i slots. Ci pareva chì se i slots accumulanu assai segmenti WAL, pudemu abbandunà u maestru. Fallerà. Avemu patitu per qualchì tempu senza slots. È avemu capitu chì avemu bisognu di slots, avemu tornatu i slots.

Ma ci hè un prublema quì, chì quandu u maestru và à a replica, sguassate i slots è sguassate i segmenti WAL cù i slots. È per eliminà stu prublema, avemu decisu di elevà u paràmetru wal_keep_segments. Hè predeterminatu à 8 segmenti. L'avemu elevatu à 1 è fighjemu quantu spaziu liberu avemu avutu. È avemu donatu 000 gigabyte per wal_keep_segments. Questu hè, quandu cambiassi, avemu sempre una riserva di 16 gigabytes di logs di transazzione in tutti i nodi.

È in più - hè sempre pertinente per i travaglii di mantenimentu longu. Diciamu chì avemu bisognu di aghjurnà una di e repliche. È vulemu disattivà. Avemu bisognu di aghjurnà u software, forsi u sistema operatore, qualcosa altru. È quandu spegnemu una replica, u slot per quella replica hè ancu eliminata. È se usemu un picculu wal_keep_segments, allora cù una longa assenza di una replica, i logs di transazzione seranu persi. Rilevaremu una replica, dumandà quelli logs di transazzione induve si ferma, ma ùn ponu micca esse nantu à u maestru. È a replica ùn puderà micca cunnette ancu. Per quessa, guardemu un grande stock di riviste.

Avemu una basa di pruduzzione. Ci sò digià prughjetti in corso.

Ci era un filler. Avemu andatu è fighjatu - tuttu hè in ordine, e rèpliche sò in u locu, ùn ci hè micca un lag di replicazione. Ùn ci hè micca errore in i logs, tuttu hè in ordine.

A squadra di u produttu dice chì ci deve esse qualchi dati, ma vedemu da una fonte, ma ùn vedemu micca in a basa di dati. È avemu bisognu di capisce ciò chì hè accadutu per elli.

Hè chjaru chì pg_wind li mancava. Avemu subitu capitu questu, ma andemu à vede ciò chì passava.

In i logs, pudemu sempre truvà quandu u filer hè accadutu, quale hè diventatu u maestru, è pudemu stabilisce quale era u vechju maestru è quandu vulia diventà una replica, vale à dì, avemu bisognu di sti logs per sapè a quantità di logs di transazzione chì era persu.

U nostru vechju maestru hà riavviatu. È Patroni hè statu registratu in l'autorun. Lanciatu Patroni. Dopu hà iniziatu Postgres. Più precisamente, prima di inizià Postgres è prima di fà una replica, Patroni hà lanciatu u prucessu pg_rewind. In cunseguenza, hà sguassatu una parte di i logs di transazzione, scaricatu novi è cunnessi. Quì Patroni hà travagliatu intelligente, vale à dì, cum'è s'aspittava. U cluster hè statu restauratu. Avemu avutu 3 nodes, dopu à u filer 3 nodes - tuttu hè cool.

Avemu persu qualchi dati. È avemu bisognu di capisce quantu avemu persu. Cerchemu solu u mumentu quandu avemu avutu un rewind. Pudemu truvà in tali entrate di ghjurnale. Rewind hà cuminciatu, hà fattu qualcosa quì è finisci.

Avemu bisognu di truvà a pusizioni in u logu di transazzione induve u vechju maestru abbandunò. In questu casu, questu hè a marca. È avemu bisognu di una seconda marca, vale à dì a distanza da quale u vechju maestru difiere da u novu.

Pigliemu u solitu pg_wal_lsn_diff è paragunemu sti dui marchi. È in questu casu, avemu 17 megabytes. Moltu o pocu, ognunu decide per ellu stessu. Perchè per qualchissia 17 megabytes ùn hè micca assai, per qualchissia hè assai è inacceptable. Quì, ogni individuu determina per ellu stessu in cunfurmità cù i bisogni di l'affari.

Ma chì avemu scupertu per noi?

Prima, duvemu decide per noi stessi - avemu sempre bisognu di Patroni per autostart dopu un reboot di u sistema? Succede à spessu chì avemu da andà à u vechju maestru, vede quantu hè andatu. Forse inspeccione i segmenti di u logu di transazzione, vede ciò chì ci hè. È à capisce s'ellu si pò perde sta dati o s'ellu ci vole à curriri u vechju maestru in modu standalone in ordine per tirà sti dati fora.

È solu dopu chì duvemu decide s'ellu pudemu scartà sta dati o pudemu restaurà, cunnette stu node cum'è una replica à u nostru cluster.

Inoltre, ci hè un paràmetru "maximum_lag_on_failover". Per automaticamente, se a mo memoria mi serve, stu paràmetru hà un valore di 1 megabyte.

Cumu travaglia ? Se a nostra replica hè daretu à 1 megabyte di dati in u lag di replicazione, allora sta replica ùn participa micca à l'alizzioni. È s'è di colpu ci hè un fileover, Patroni s'assumiglia à quali ripliche sò in ritardu. S'elli sò daretu da un gran numaru di logs di transazzione, ùn ponu micca diventà un maestru. Quissa hè una funzione di sicurità assai bona chì impedisce voi da perde assai dati.

Ma ci hè un prublema in chì u lag di replicazione in u cluster Patroni è DCS hè aghjurnatu à un certu intervallu. Pensu chì 30 seconde hè u valore ttl predeterminatu.

Di conseguenza, pò esse una situazione induve ci hè un ritardu di replicazione per e rèpliche in DCS, ma in fattu pò esse un ritardu completamente diversu o ùn pò esse micca un ritardu, vale à dì chì questu ùn hè micca in tempu reale. È ùn riflette micca sempre a vera stampa. È ùn vale a pena fà una logica fantastica nantu à questu.

È u risicu di perdita ferma sempre. È in u peghju casu, una formula, è in u casu mediu, una altra formula. Questu hè, quandu avemu pianificatu l'implementazione di Patroni è evaluà quantu dati pudemu perde, avemu da cunfidenza nantu à sti formule è apprussimatamente imagine quantu dati pudemu perde.

È ci hè una bona nutizia. Quandu u vechju maestru hè andatu avanti, pò andà avanti per via di qualchi prucessi di fondo. Questu hè, ci era un tipu d'autovacuum, hà scrittu i dati, salvatu à u logu di transazzione. È pudemu ignurà facilmente è perde sta dati. Ùn ci hè micca prublema in questu.

È questu hè cumu si vede i logs se maximum_lag_on_failover hè stallatu è un filer hè accadutu, è avete bisognu di selezziunà un novu maestru. A replica s'estima incapace di participà à l'elezzioni. È ricusa di participà à a corsa per u capu. È aspetta chì un novu maestru sia sceltu, per ch'ella puderà cunnette cun ellu. Questa hè una misura supplementaria contra a perdita di dati.

Eccu avemu un squadra di produttu chì hà scrittu chì u so pruduttu hà prublemi cù Postgres. À u listessu tempu, u maestru stessu ùn pò micca accede, perchè ùn hè micca dispunibule via SSH. È l'autofile ùn succede ancu.

Stu òspite hè statu obligatu à reboot. A causa di u reboot, un auto-file hè accadutu, ancu s'ellu era pussibule di fà un auto-file manuale, cum'è avà capitu. È dopu à u reboot, andemu digià à vede ciò chì avemu avutu cù u maestru attuale.

À u listessu tempu, sapemu in anticipu chì avemu avutu prublemi cù i dischi, vale à dì, avemu digià cunnisciutu da u monitoraghju induve scavà è ciò chì circà.

Entramu in u logu di postgres, cuminciamu à vede ciò chì succede. Avemu vistu commits chì duranu quì per unu, dui, trè seconde, chì ùn hè micca in tuttu normale. Avemu vistu chì u nostru autovacuum principia assai pianu è stranu. È avemu vistu i schedari tempuranee nantu à u discu. Questu hè, questi sò tutti l'indicatori di prublemi cù i discu.

Avemu cercatu in u sistema dmesg (registru di u kernel). E avemu vistu chì avemu prublemi cù unu di i dischi. U sottosistema di discu era u software Raid. Avemu guardatu /proc/mdstat è avemu vistu chì ci mancava una unità. Vale à dì, ci hè un Raid di 8 dischi, ci manca unu. Se guardate attentamente u slide, allora in u output pudete vede chì ùn avemu micca sde quì. À noi, in cundizzioni, u discu hè cascatu. Questu hà attivatu prublemi di discu, è l'applicazioni anu ancu avutu prublemi quandu travagliavanu cù u cluster Postgres.

È in questu casu, Patroni ùn ci aiutava micca in ogni modu, perchè Patroni ùn hà micca u compitu di monitorà u statu di u servitore, u statu di u discu. È avemu da monitorà tali situazioni da un surviglianza esternu. Avemu aghjustatu rapidamente u monitoraghju di discu à u monitoraghju esternu.

È ci era un tali pensamentu - puderia aiutà u software di scherma o di watchdog? Pensemu ch'ellu ùn ci avissi guasi aiutatu in questu casu, perchè durante i prublemi Patroni hà cuntinuatu à interagisce cù u cluster DCS è ùn hà vistu nisun prublema. Questu hè, da u puntu di vista di DCS è Patroni, tuttu era bè cù u cluster, ancu s'ellu ci era in fattu prublemi cù u discu, ci eranu prublemi cù a dispunibilità di a basa di dati.

In u mo scusa, questu hè unu di i prublemi più strani chì aghju investigatu per un tempu assai longu, aghju lettu assai logs, re-cogliu è chjamatu un simulatore di cluster.

U prublema era chì u vechju maestru ùn pudia diventà una rèplica normale, vale à dì Patroni hà iniziatu, Patroni hà dimustratu chì stu node era presente cum'è una replica, ma à u stessu tempu ùn era micca una rèplica normale. Avà vi vede perchè. Questu hè ciò chì aghju tenutu da l'analisi di quellu prublema.

E cumu hà principiatu tuttu ? Cuminciò, cum'è in u prublema precedente, cù freni di discu. Avemu avutu impegni per un secondu, dui.

Ci sò stati rotture in cunnessione, vale à dì, i clienti eranu strappati.

Ci sò stati blocchi di gravità diversa.

È, per quessa, u subsistema di discu ùn hè micca assai responsivo.

È a cosa più misteriosa per mè hè a dumanda di arrestu immediata chì hè ghjunta. Postgres hà trè modi di spegnimentu:

• Hè graziosu quandu aspittemu chì tutti i clienti si scolleganu per sè stessu.
• Ci hè veloce quandu forzemu i clienti à disconnettere perchè andemu à chjude.
• È immediata. In questu casu, l'immediatu ùn dice mancu à i clienti di chjude, solu si chjude senza avvisu. È à tutti i clienti, u sistema operatore hà digià mandatu un missaghju RST (un missaghju TCP chì a cunnessione hè interrotta è u cliente ùn hà nunda di più per catturà).

Quale hà mandatu stu signale ? I prucessi di fondo di Postgres ùn mandanu micca tali signali à l'altri, vale à dì questu hè kill-9. Ùn si mandanu micca tali cose l'un à l'altru, solu reagiscenu à tali cose, vale à dì questu hè un riavviu d'emergenza di Postgres. Quale hè mandatu, ùn sò micca.

Aghju guardatu à l'"ultimu" cumandamentu è aghju vistu una persona chì hà ancu logatu in stu servitore cun noi, ma era troppu timida per fà una quistione. Forse era uccisu -9. Videraghju tumbà -9 in i logs, perchè Postgres dice chì hà pigliatu kill -9, ma ùn aghju micca vistu in i logs.

Fighjendu più, aghju vistu chì Patroni ùn hà micca scrittu à u logu per un bellu pezzu - 54 seconde. È se paragunemu dui timestamps, ùn ci era micca messagi per circa 54 seconde.

È duranti stu tempu ci era un autofile. Patroni hà fattu un bellu travagliu quì di novu. U nostru vechju maestru ùn era micca dispunibule, qualcosa hè accadutu à ellu. È principia l'elezzione di un novu maestru. Tuttu hà travagliatu bè quì. U nostru pgsql01 hè diventatu u novu capu.

Avemu una replica chì hè diventata un maestru. È ci hè una seconda risposta. È ci sò stati prublemi cù a seconda replica. Ella hà pruvatu à ricunfigurazione. Comu l'aghju capitu, hà pruvatu à cambià recovery.conf, riavvia Postgres è cunnette à u novu maestru. Scrive missaghji ogni 10 seconde chì prova, ma ùn hè micca successu.

È durante questi tentativi, un signalu di arrestu immediata arriva à u vechju maestru. U maestru hè riavviatu. È ancu a ricuperazione si ferma perchè u vechju maestru entra in reboot. Vale à dì, a replica ùn pò micca cunnette cù questu, perchè hè in modu di chjusu.

À un certu puntu, hà travagliatu, ma a replicazione ùn hà micca cuminciatu.

A mo sola ipotesi hè chì ci era un vechju indirizzu maestru in recovery.conf. È quandu un novu maestru apparsu, a seconda replica hà sempre pruvatu à cunnette cù u vechju maestru.

Quandu Patroni hà iniziatu nantu à a seconda replica, u node hà iniziatu, ma ùn pudia micca riplicà. È hè statu furmatu un lag di replicazione, chì pareva qualcosa cusì. Vale à dì, tutti i trè nodi eranu in u locu, ma u sicondu nodu era in daretu.

À u listessu tempu, se guardate i logs chì sò stati scritti, pudete vede chì a replicazione ùn pudia micca principià perchè i logs di transazzione eranu diffirenti. E quelli logs di transazzione chì u maestru offre, chì sò specificati in recovery.conf, simpricimenti ùn si adattanu micca à u nostru node attuale.

È quì aghju fattu un sbagliu. Aviu avutu à vene à vede ciò chì era in recovery.conf per pruvà a mo ipotesi chì avemu cunnessu à u maestru sbagliatu. Ma tandu era solu trattatu di questu è ùn m'hè micca accadutu, o aghju vistu chì a rèplica era in ritardu è duveria esse ripiegata, vale à dì, aghju travagliatu in qualchì manera senza cura. Questa era a mo articulazione.

Dopu à 30 minuti, l'amministratore hè digià ghjuntu, vale à dì chì aghju riavviatu Patroni nantu à a replica. L'aghju dighjà finitu, pensu ch'ellu ci vole à ritruvà. È aghju pensatu - riavvia à Patroni, forse qualcosa di bonu ne esce. A ricuperazione hà iniziatu. È a basa ancu aperta, era pronta per accettà cunnessione.

A replicazione hà iniziatu. Ma un minutu dopu hà cascatu cù un errore chì i logs di transazzione ùn sò micca adattati per ella.

Pensu di riavvià di novu. Aghju riavviatu Patroni di novu, è ùn aghju micca riavviatu Postgres, ma hà riavviatu Patroni in a speranza chì magicamente principia a basa di dati.

A replicazione hà cuminciatu di novu, ma i marchi in u logu di transazzione eranu diffirenti, ùn eranu micca listessi cum'è u tentativu di principiu precedente. A replicazione si ferma di novu. È u missaghju era digià un pocu sfarente. È ùn era micca assai informativu per mè.

E poi mi succede - chì s'ellu riavvia Postgres, in questu mumentu aghju fattu un puntu di cuntrollu nantu à u maestru attuale per spustà u puntu in u logu di transazzione un pocu avanti per chì a ricuperazione principia da un altru mumentu? In più, avemu sempre avutu azioni di WAL.

Aghju riavviatu Patroni, hà fattu un paru di punti di cuntrollu nantu à u maestru, un paru di punti di riavvia nantu à a replica quandu hà apertu. È hà aiutatu. Pensu per un bellu pezzu perchè hà aiutatu è cumu hà travagliatu. È a replica principia. È a replicazione ùn era più strappata.

Un tali prublemu per mè hè unu di i più misteriosi, nantu à quale aghju sempre cunfusu ciò chì hè accadutu veramente.

Chì sò l'implicazioni quì? Patroni pò travaglià cum'è previstu è senza errore. Ma à u stessu tempu, questu ùn hè micca una guaranzia 100% chì tuttu hè bè cun noi. A replica pò principià, ma pò esse in un statu semi-travagliu, è l'applicazione ùn pò micca travaglià cù una tale replica, perchè ci saranu dati vechji.

E dopu à u filer, avete sempre bisognu di verificà chì tuttu hè in ordine cù u cluster, vale à dì, ci hè u numeru necessariu di rèpliche, ùn ci hè micca un lag di replicazione.

È cum'è andemu à traversu questi prublemi, vi farà cunsiglii. Aghju pruvatu à cunghjuntà in dui slides. Probabilmente, tutte e storie puderanu esse cumminate in dui slides è solu cuntate.

Quandu avete aduprà Patroni, avete bisognu di monitorà. Avete sempre sapè quandu un autofileover hè accadutu, perchè se ùn sapete micca chì avete un autofileover, ùn avete micca cuntrollu di u cluster. È hè male.

Dopu ogni filer, avemu sempre à verificà manualmente u cluster. Avemu bisognu di assicurà chì avemu sempre un nùmeru up-to-date di replica, ùn ci hè micca lag replication, ùn ci sò micca errore in i logs ligati à a replicazione streaming, cù Patroni, cù u sistema DCS.

L'automatizazione pò travaglià bè, Patroni hè un strumentu assai bonu. Pò travaglià, ma questu ùn porta micca u cluster à u statu desideratu. È s'ellu ùn l'avemu scupertu, seremu in prublemi.

È Patroni ùn hè micca una bala d'argentu. Avemu sempre bisognu di capiscenu cumu funziona Postgres, cumu funziona a replicazione è cumu Patroni travaglia cù Postgres, è cumu a cumunicazione trà i nodi hè furnita. Questu hè necessariu per pudè risolve i prublemi cù e vostre mani.

Cumu avvicinà u prublema di diagnosi? Hè accadutu chì avemu travagliatu cù diversi clienti è nimu hà una pila ELK, è avemu da sorte i logs aprendu 6 console è 2 tabs. In una tabulazione, questi sò i logs Patroni per ogni node, in l'altru tab, questi sò i logs Consul, o Postgres s'ellu hè necessariu. Hè assai difficiule di diagnosticà questu.

Chì approcci aghju pigliatu ? Prima, guardu sempre quandu u filer hè ghjuntu. È per mè questu hè un bacinu d'acqua. Fighjulà ciò chì hè accadutu prima di u filer, durante u filer è dopu à u filer. U fileover hà duie marche: questu hè l'ora di principiu è di fine.

In seguitu, cercu in i logs per l'avvenimenti prima di u filer, chì precede u filer, vale à dì cercu i mutivi per quessa chì u filer hè accadutu.

È questu dà una figura di capiscenu ciò chì hè accadutu è ciò chì pò esse fattu in u futuru per chì tali circustanze ùn accadenu micca (è in u risultatu, ùn ci hè micca filer).

È induve guardemu di solitu? mi pare :

• Prima, à i logs Patroni.
• In seguitu, aghju guardatu i logs Postgres, o i logs DCS, secondu ciò chì hè statu trovu in i logs Patroni.
• È i logs di u sistema ancu qualchì volta dà una cunniscenza di ciò chì hà causatu u filer.

Cumu mi sentu per Patroni ? Aghju una relazione assai bona cù Patroni. In u mo parè, questu hè u megliu chì ci hè oghje. Cunnoscu parechji altri prudutti. Questi sò Stolon, Repmgr, Pg_auto_failover, PAF. 4 arnesi. Aghju pruvatu tutti. Patroni hè u mo favuritu.

S'elli mi dumandanu : "U cunsigliu Patroni?". Diciaraghju di sì, perchè mi piace Patroni. E pensu chì aghju amparatu à cocilu.

Sè vo site interessatu à vede chì altri prublemi ci sò cù Patroni oltri i prublemi ch'e aghju citatu, pudete sempre cunsultà a pagina imbusci nantu à GitHub. Ci sò parechje storie diverse è parechji temi interessanti sò discututi quì. È in u risultatu, alcuni bugs sò stati presentati è risolti, questu hè una lettura interessante.

Ci hè parechje storie interessanti nantu à e persone chì si sparanu in u pede. Moltu informativu. Avete lettu è capisce chì ùn hè micca necessariu di fà cusì. Aghju marcatu mè stessu.

È vogliu dì un grande ringraziu à Zalando per u sviluppu di stu prughjettu, à dì à Alexander Kukushkin è Alexey Klyukin. Aleksey Klyukin hè unu di i co-autori, ùn travaglia più in Zalando, ma sò dui persone chì cuminciaru à travaglià cù stu pruduttu.

E pensu chì Patroni hè una cosa assai bella. Sò cuntentu ch'ella esiste, hè interessante cun ella. È un ringraziu maiò à tutti i cuntributori chì scrivenu patch à Patroni. Spergu chì Patroni diventerà più maturu, cool è efficiente cù l'età. Hè digià funziunale, ma spergu chì sarà ancu megliu. Per quessa, s'è vo pensa à aduprà Patroni, allura ùn àbbia paura. Questa hè una bona suluzione, pò esse implementata è utilizata.

Eccu tuttu. Sì avete dumande, dumandate.

I vostri dumanni

Grazie per u rapportu! Se dopu à un filer avete sempre bisognu di guardà quì assai cura, allora perchè avemu bisognu di un filer automaticu?

Perchè hè roba nova. Avemu solu cun ella per un annu. Hè megliu esse sicuru. Vulemu entra è vede chì tuttu hà veramente travagliatu cum'è duverebbe. Questu hè u livellu di sfiducia di l'adulti - hè megliu cuntrollà è vede.

Per esempiu, andemu in a matina è fighjemu, nò ?

Micca in a matina, avemu di solitu amparà circa l'autofile quasi subitu. Ricevemu notificazioni, vedemu chì un autofile hè accadutu. Quasi subitu andemu à circà. Ma tutti sti cuntrolli deve esse purtatu à u livellu di monitoraghju. Se accede à Patroni via l'API REST, ci hè una storia. Per a storia pudete vede i timestamps quandu u filer hè accadutu. Basatu nantu à questu, u monitoraghju pò esse fattu. Pudete vede a storia, quanti avvenimenti eranu. Se avemu più avvenimenti, allora un autofile hè accadutu. Pudete andà à vede. O a nostra automatizazione di monitorizazione hà verificatu chì avemu tutte e rèpliche in u locu, ùn ci hè micca ritardu è tuttu hè bè.

Grazie!

Grazie mille per a grande storia! Se avemu spustatu u cluster DCS in un locu luntanu da u cluster Postgres, allora questu cluster deve ancu esse servitu periodicamente? Chì sò e pratiche megliu chì certi pezzi di u cluster DCS deve esse disattivatu, qualcosa per esse fattu cun elli, etc.? Cumu sopravvive sta struttura sana? È cumu fate queste cose ?

Per una cumpagnia, era necessariu di fà una matrice di prublemi, ciò chì succede se unu di i cumpunenti o parechji cumpunenti fiascanu. Sicondu sta matrice, andemu in sequenza per tutti i cumpunenti è custruiscenu scenarii in casu di fallimentu di sti cumpunenti. Dunque, per ogni scenariu di fallimentu, pudete avè un pianu d'azzione per a ricuperazione. È in u casu di DCS, vene cum'è parte di l'infrastruttura standard. È l'amministratori l'amministranu, è avemu digià cunfidendu l'amministratori chì l'amministranu è a so capacità di riparà in casu d'accidenti. Se ùn ci hè micca DCS in tuttu, allora l'avemu implementatu, ma à u stessu tempu ùn avemu micca particularmente monitoratu, perchè ùn simu micca rispunsevuli di l'infrastruttura, ma demu cunsiglii cumu è ciò chì monitorizà.

Questu hè, aghju capitu bè chì aghju bisognu di disattivà Patroni, disattivà u filer, disattivà tuttu prima di fà qualcosa cù l'ospiti?

Dipende da quanti nodi avemu in u cluster DCS. Se ci sò parechji nodi è se disattivemu solu unu di i nodi (a replica), u cluster mantene un quorum. È Patroni ferma operativu. È nunda hè attivatu. Se avemu qualchì operazione cumplessa chì affettanu più nodi, l'absenza di quale pò arruvinà u quorum, allora - iè, puderia esse sensu per mette Patroni in pausa. Havi un cumandamentu currispundenti - patronictl pause, patronictl resume. Facemu una pausa è l'autofiler ùn funziona micca in quellu tempu. Facemu mantenimentu nantu à u cluster DCS, dopu togliemu a pausa è cuntinuemu à campà.

Grazie!

Grazie mille per u vostru rapportu! Cumu si sente a squadra di u produttu annantu à a perdita di dati?

E squadre di produttu ùn importa micca, è i capi di squadra sò preoccupati.

Chì garanzie ci sò ?

I garanti sò assai difficiuli. Alexander Kukushkin hà un rapportu "Cumu calculà RPO è RTO", vale à dì u tempu di ricuperazione è quantu dati pudemu perde. Pensu chì avemu bisognu di truvà sti slides è studià. Quantu mi ricordu, ci sò passi specifichi nantu à cumu calculà queste cose. Quante transazzione pudemu perde, quantu dati pudemu perde. Cum'è una opzione, pudemu usà a replicazione sincrona à u livellu di Patroni, ma questu hè una spada à doppiu tagliu: o avemu a fiducia di dati, o perdemu a veloce. Ci hè replicazione sincrona, ma dinù ùn guarantisci 100% prutezzione contra a perdita di dati.

Alexey, grazie per u grande rapportu! Qualchese sperienza cù l'usu di Patroni per a prutezzione di livellu zero? Questu hè, in cunghjunzione cù u standby sincronu? Questa hè a prima quistione. È a seconda quistione. Avete usatu diverse suluzioni. Avemu usatu Repmgr, ma senza autofiler, è avà avemu pensatu à include autofiler. È cunsideremu Patroni cum'è una suluzione alternativa. Chì pudete dì cum'è vantaghji paragunatu à Repmgr?

A prima quistione era di ripliche sincrone. Nimu ùn usa a replicazione sincrona quì, perchè tutti anu paura (Parechji clienti l'anu digià utilizatu, in principiu, ùn anu micca nutatu prublemi di rendiment - Nota di u parlante). Ma avemu sviluppatu una regula per noi stessi chì ci deve esse almenu trè nodi in un cluster di replicazione sincrona, perchè s'ellu avemu dui nodi è se u maestru o a replica falla, Patroni cambia stu node à u modu Standalone per chì l'applicazione cuntinueghja travagliu. In stu casu, ci hè un risicu di perdita di dati.

In quantu à a seconda quistione, avemu usatu Repmgr è facemu sempre cù certi clienti per ragioni storichi. Chì si pò dì ? Patroni vene cun un autofiler fora di a scatula, Repmgr vene cun autofiler cum'è una funzione supplementaria chì deve esse attivata. Avemu bisognu di eseguisce u daemon Repmgr in ogni node è poi pudemu cunfigurà l'autofiler.

Repmgr verifica se i nodi Postgres sò vivi. I prucessi Repmgr verificanu l'esistenza di l'altri, questu ùn hè micca un approcciu assai efficau. Ci ponu esse casi cumplessi di isolamentu di a rete in quale un grande cluster Repmgr pò fallu in parechji più chjuchi è cuntinuà à travaglià. Ùn aghju micca seguitu Repmgr per un bellu pezzu, forse hè stata fissata ... o forse micca. Ma l'eliminazione di l'infurmazioni nantu à u statu di u cluster in DCS, cum'è Stolon, Patroni, hè l'opzione più viable.

Alexey, aghju una dumanda, forse una lamer. In unu di i primi esempi, avete spustatu DCS da a macchina lucale à un host remoto. Capemu chì a reta hè una cosa chì hà e so caratteristiche, vive da sola. E chì succede se per una certa ragione u cluster DCS diventa indisponibile? Ùn diceraghju micca i motivi, ci ponu esse assai: da e mani storte di i networkers à i prublemi veri.

Ùn l'aghju micca dettu à voce alta, ma u cluster DCS deve ancu esse failover, vale à dì hè un nùmeru imparu di nodi, per esse un quorum. Chì succede se u cluster DCS diventa indisponibile, o un quorum ùn pò esse scuntratu, vale à dì qualchì tipu di split network o fallimentu di node? In questu casu, u cluster Patroni entra in modu di sola lettura. U cluster Patroni ùn pò micca determinà u statu di u cluster è ciò chì fà. Ùn pò micca cuntattà u DCS è almacenà u novu statu di cluster quì, cusì tuttu u cluster entra in sola lettura. È aspetta sia per l'intervenzione manuale da l'operatore sia per DCS per ricuperà.

À pocu pressu, DCS diventa un serviziu per noi cusì impurtante cum'è a basa stessa?

Iè Iè. In tanti cumpagnii muderni, Service Discovery hè una parte integrante di l'infrastruttura. Hè implementatu ancu prima chì ci era ancu una basa di dati in l'infrastruttura. Relativamente parlante, l'infrastruttura hè stata lanciata, implementata in DC, è avemu immediatamente u Service Discovery. S'ellu hè Consul, allura DNS pò esse custruitu nantu à questu. Se questu hè Etcd, allora pò esse una parte da u cluster Kubernetes, in quale tuttu u restu serà implementatu. Mi pari chì Service Discovery hè digià una parte integrante di l'infrastrutture muderni. È pensanu assai prima di e basa di dati.

Grazie!

Source: www.habr.com