Scopul principal al Patroni este de a oferi înaltă disponibilitate pentru PostgreSQL. Dar Patroni este doar un șablon, nu un instrument gata făcut (ceea ce, în general, se spune în documentație). La prima vedere, după ce ați configurat Patroni în laboratorul de testare, puteți vedea ce instrument grozav este și cât de ușor se ocupă de încercările noastre de a sparge clusterul. Cu toate acestea, în practică, într-un mediu de producție, totul nu se întâmplă întotdeauna la fel de frumos și elegant ca într-un laborator de testare.
Îți voi spune puțin despre mine. Am început ca administrator de sistem. A lucrat în dezvoltare web. Lucrez la Data Egret din 2014. Compania este angajată în consultanță în domeniul Postgres. Și deservim exact Postgres și lucrăm cu Postgres în fiecare zi, așa că avem o expertiză diferită legată de operațiune.
Și la sfârșitul anului 2018 am început să folosim încet Patroni. Și s-a acumulat ceva experiență. Am diagnosticat-o cumva, l-am reglat, am ajuns la cele mai bune practici. Și în acest reportaj voi vorbi despre ele.
În afară de Postgres, îmi place Linux. Îmi place să mă uit în el și să explorez, îmi place să adun nuclee. Îmi place virtualizarea, containerele, docker, Kubernetes. Toate acestea mă interesează, pentru că vechile obiceiuri de admin afectează. Îmi place să mă ocup de monitorizare. Și îmi plac lucrurile postgres legate de administrare, adică replicare, backup. Și în timpul liber scriu în Go. Nu sunt inginer de software, scriu doar pentru mine în Go. Și îmi face plăcere.
- Cred că mulți dintre voi știți că Postgres nu are HA (High Availability) din cutie. Pentru a obține HA, trebuie să instalați ceva, să îl configurați, să faceți un efort și să îl obțineți.
- Există mai multe instrumente și Patroni este unul dintre ele care rezolvă HA destul de tare și foarte bine. Dar punând totul într-un laborator de testare și rulând, putem vedea că totul funcționează, putem reproduce unele probleme, vedem cum Patroni le servește. Și vom vedea că totul funcționează excelent.
- Dar, în practică, ne-am confruntat cu diferite probleme. Și voi vorbi despre aceste probleme.
- Vă voi spune cum l-am diagnosticat, ce am ajustat - dacă ne-a ajutat sau nu.
- Nu vă voi spune cum să instalați Patroni, pentru că puteți căuta pe google pe Internet, vă puteți uita la fișierele de configurare pentru a înțelege cum pornește totul, cum este configurat. Puteți înțelege schemele, arhitecturile, găsind informații despre acestea pe Internet.
- Nu voi vorbi despre experiența altcuiva. Voi vorbi doar despre problemele cu care ne-am confruntat.
- Și nu voi vorbi despre probleme care sunt în afara Patroni și PostgreSQL. Dacă, de exemplu, există probleme asociate cu echilibrarea, când clusterul nostru s-a prăbușit, nu voi vorbi despre asta.
Și o mică declinare a răspunderii înainte de a începe raportul nostru.
Toate aceste probleme pe care le-am întâlnit, le-am avut în primele 6-7-8 luni de funcționare. De-a lungul timpului, am ajuns la cele mai bune practici interne. Și problemele noastre au dispărut. Prin urmare, raportul a fost anunțat în urmă cu aproximativ șase luni, când totul era proaspăt în capul meu și mi-am amintit totul perfect.
În timpul pregătirii raportului, am ridicat deja autopsie vechi, m-am uitat la bușteni. Și unele detalii ar putea fi uitate, sau unele dintre unele detalii nu au putut fi investigate pe deplin în timpul analizei problemelor, așa că în unele momente poate părea că problemele nu sunt pe deplin luate în considerare, sau există o oarecare lipsă de informații. Și așa că vă rog să mă scuzați pentru acest moment.
Ce este Patroni?
- Acesta este un șablon pentru construirea HA. Asa scrie in documentatie. Și din punctul meu de vedere, aceasta este o clarificare foarte corectă. Patroni nu este un glonț de argint care să îți rezolve toate problemele, adică trebuie să faci un efort ca să funcționeze și să aduci beneficii.
- Acesta este un serviciu agent care este instalat pe fiecare serviciu de bază de date și este un fel de sistem de inițializare pentru Postgres. Pornește Postgres, oprește, repornește, reconfigurează și schimbă topologia clusterului tău.
- În consecință, pentru a stoca starea clusterului, reprezentarea sa actuală, așa cum arată, este nevoie de un fel de stocare. Și din acest punct de vedere, Patroni a luat calea stocării stării într-un sistem extern. Este un sistem de stocare de configurare distribuită. Poate fi Etcd, Consul, ZooKeeper sau kubernetes Etcd, adică una dintre aceste opțiuni.
- Iar una dintre caracteristicile Patroni este că scoateți autofilerul din cutie, doar prin configurarea lui. Dacă luăm Repmgr pentru comparație, atunci filerul este inclus acolo. Cu Repmgr, obținem o trecere, dar dacă vrem un autofiler, atunci trebuie să îl configuram suplimentar. Patroni are deja un autofiler din cutie.
- И есть много еще других вещей. Например, обслуживание конфигураций, наливка новых реплик, резервное копирование и т. д. Но это за пределами доклада, про это я рассказывать не буду.
Și un mic rezultat este că sarcina principală a Patroni este să facă un fișier automat bine și fiabil, astfel încât clusterul nostru să rămână operațional și aplicația să nu observe modificări în topologia clusterului.
Dar când începem să folosim Patroni, sistemul nostru devine puțin mai complicat. Dacă mai devreme aveam Postgres, atunci când folosim Patroni obținem Patroni în sine, obținem DCS unde este stocată starea. Și totul trebuie să funcționeze cumva. Deci, ce poate merge prost?
Se poate rupe:
- Postgres s-ar putea rupe. Poate fi un master sau o replică, unul dintre ele poate eșua.
- Patroni însuși se poate rupe.
- DCS în care este stocată starea se poate rupe.
- Și rețeaua se poate rupe.
Toate aceste puncte le voi lua în considerare în raport.
Voi lua în considerare cazurile pe măsură ce devin mai complexe, nu din punctul de vedere că cazul implică multe componente. Și din punct de vedere al sentimentelor subiective, că această carcasă mi-a fost dificilă, a fost greu să o demontăm... și invers, o carcasă era ușoară și era ușor să o demontăm.
Și primul caz este cel mai ușor. Acesta este cazul când am luat un cluster de baze de date și am implementat stocarea noastră DCS pe același cluster. Aceasta este cea mai frecventă greșeală. Aceasta este o greșeală în construirea arhitecturilor, adică combinarea diferitelor componente într-un singur loc.
Deci, a fost un filer, să mergem să ne ocupăm de ce sa întâmplat.
И здесь нас интересует, когда произошел файловер. Т. е. нас интересует вот этот момент времени, когда произошло изменение состояния кластера.
Но файловер не всегда одномоментный, т. е. он не занимает какую-то единицу времени, он может затянуться. Он может быть продолжительным во времени.
Prin urmare, are o oră de început și o oră de sfârșit, adică este un eveniment continuu. Și împărțim toate evenimentele în trei intervale: avem timp înainte de filer, în timpul filerului și după filer. Adică, luăm în considerare toate evenimentele din această cronologie.
И первым делом, когда произошел файловер, мы ищем причину, что произошло, что стало причиной того, что привело к файловеру.
Если мы посмотрим на логи, то это будут классические логи Patroni. Он в них нам сообщает, что сервер стал мастером, и роль мастера перешла на этот узел. Тут это подсвечено.
În continuare, trebuie să înțelegem de ce s-a întâmplat filerul, adică ce evenimente au avut loc care au făcut ca rolul principal să se mute de la un nod la altul. Și în acest caz, totul este simplu. Avem o eroare în interacțiunea cu sistemul de stocare. Maestrul și-a dat seama că nu poate lucra cu DCS, adică a existat un fel de problemă cu interacțiunea. Și spune că nu mai poate fi maestru și își dă demisia. Această linie „sine retrogradat” spune exact asta.
Если посмотреть на события, которые предшествовали файловеру, то мы там можем увидеть те самые причины, которые послужили проблемой для продолжения работы мастера.
Dacă ne uităm la jurnalele Patroni, vom vedea că avem o mulțime de erori, timeout-uri, adică agentul Patroni nu poate lucra cu DCS. În acest caz, acesta este agentul Consul, care comunică pe portul 8500.
Și problema aici este că Patroni și baza de date rulează pe aceeași gazdă. Și serverele Consul au fost lansate pe același nod. Prin crearea unei încărcări pe server, am creat probleme și pentru serverele Consul. Nu au putut comunica corect.
După ceva timp, când încărcătura sa diminuat, Patronii noștri au reușit să comunice cu agenții. Munca normală a fost reluată. Și același server Pgdb-2 a devenit din nou maestru. Adică, a existat o mică răsturnare, din cauza căreia nodul a demisionat de la puterile maestrului și apoi le-a preluat din nou, adică totul a revenit așa cum era.
И это можно расценивать как ложную сработку, либо можно расценивать, что Patroni сделал все правильно. Т. е. он понял, что не может поддерживать состояние кластера и снял с себя полномочия.
Și aici problema a apărut din cauza faptului că serverele Consul sunt pe același hardware cu bazele. În consecință, orice încărcare: fie că este vorba de încărcare pe discuri sau procesoare, afectează și interacțiunea cu clusterul Consul.
Și am decis că nu ar trebui să locuiască împreună, am alocat un cluster separat pentru Consul. Și Patroni lucra deja cu un Consul separat, adică exista un cluster separat Postgres, un cluster separat Consul. Aceasta este o instrucțiune de bază despre cum să purtați și să păstrați toate aceste lucruri, astfel încât să nu trăiască împreună.
Ca opțiune, puteți să răsuciți parametrii ttl, loop_wait, retry_timeout, adică să încercați să supraviețuiți acestor vârfuri de încărcare pe termen scurt prin creșterea acestor parametri. Dar aceasta nu este cea mai potrivită opțiune, deoarece această sarcină poate fi lungă în timp. Și pur și simplu vom depăși aceste limite ale acestor parametri. Și asta s-ar putea să nu ajute cu adevărat.
Первая проблема, как вы поняли, простая. Мы взяли и DCS положили вместе с базой, получили проблему.
Вторая проблема похожа на первую. Она похожа тем, что у нас снова есть проблемы взаимодействия с системой DCS.
Если мы посмотрим на логи, то мы увидим, что у нас снова ошибка коммуникации. И Patroni говорит, что я не могу взаимодействовать с DCS, поэтому текущий мастер переходит в режим реплики.
Bătrânul maestru devine o replică, aici Patroni se descurcă, așa cum trebuie. Rulează pg_rewind pentru a derula înapoi jurnalul de tranzacții și apoi se conectează la noul master pentru a ajunge din urmă cu noul master. Aici Patroni se descurcă, așa cum ar trebui.
Aici trebuie să găsim locul care a precedat filerul, adică acele erori care ne-au determinat să avem un filer. Și în acest sens, jurnalele Patroni sunt destul de convenabile pentru a lucra. El scrie aceleași mesaje la un anumit interval. Și dacă începem să parcurgem rapid aceste jurnale, atunci vom vedea din jurnalele că jurnalele s-au schimbat, ceea ce înseamnă că au început unele probleme. Ne întoarcem repede în acest loc, să vedem ce se întâmplă.
Și într-o situație normală, jurnalele arată cam așa. Proprietarul lacătului este verificat. Și dacă proprietarul, de exemplu, s-a schimbat, atunci pot apărea unele evenimente la care Patroni trebuie să răspundă. Dar în acest caz, suntem bine. Căutăm locul de unde au început erorile.
Și după ce am derulat până la punctul în care au început să apară erorile, vedem că am avut o auto-fileover. Și din moment ce erorile noastre au fost legate de interacțiunea cu DCS și în cazul nostru am folosit Consul, ne uităm și la jurnalele Consul, ce s-a întâmplat acolo.
Comparând aproximativ ora filerului și cea din jurnalele Consulului, vedem că vecinii noștri din clusterul Consul au început să se îndoiască de existența altor membri ai clusterului Consul.
Și dacă te uiți și la jurnalele altor agenți Consul, poți vedea și că acolo are loc un fel de colaps al rețelei. Și toți membrii grupului Consul se îndoiesc de existența celuilalt. Și acesta a fost impulsul pentru filer.
Dacă te uiți la ceea ce s-a întâmplat înainte de aceste erori, poți vedea că există tot felul de erori, de exemplu, termenul limită, RPC a căzut, adică există în mod clar un fel de problemă în interacțiunea membrilor clusterului Consul între ei. .
Cel mai simplu răspuns este repararea rețelei. Dar pentru mine, stând pe podium, este ușor să spun asta. Dar circumstanțele sunt de așa natură încât nu întotdeauna clientul își poate permite să repare rețeaua. El poate locui într-un DC și nu poate repara rețeaua, afecta echipamentul. Și deci sunt necesare alte opțiuni.
Există opțiuni:
- Cea mai simplă opțiune, care este scrisă, după părerea mea, chiar și în documentație, este să dezactivezi verificările Consul, adică să treci pur și simplu o matrice goală. Și îi spunem agentului Consul să nu folosească niciun cec. Cu aceste verificări, putem ignora aceste furtuni de rețea și nu putem iniția un filer.
- O altă opțiune este să verificați dublu raft_multiplier. Acesta este un parametru al serverului Consul însuși. În mod implicit, este setată la 5. Această valoare este recomandată de documentația pentru mediile de realizare. De fapt, acest lucru afectează frecvența mesajelor între membrii rețelei Consul. De fapt, acest parametru afectează viteza de comunicare a serviciului între membrii clusterului Consul. Și pentru producție, este deja recomandat să o reduceți, astfel încât nodurile să facă schimb de mesaje mai des.
- O altă opțiune cu care am venit este să creștem prioritatea proceselor Consul printre alte procese pentru planificatorul de procese al sistemului de operare. Există un parametru atât de „drăguț”, doar determină prioritatea proceselor care este luată în considerare de planificatorul OS la programare. De asemenea, am redus valoarea plăcută pentru agenții consul, adică. a crescut prioritatea, astfel încât sistemul de operare să ofere proceselor Consul mai mult timp să lucreze și să își execute codul. În cazul nostru, asta ne-a rezolvat problema.
- O altă opțiune este să nu folosești Consul. Am un prieten care este un mare susținător al Etcd. Și ne certam regulat cu el care este mai bine Etcd sau Consul. Dar în ceea ce privește ceea ce este mai bine, de obicei suntem de acord cu el că Consul are un agent care ar trebui să ruleze pe fiecare nod cu o bază de date. Adică prin acest agent trece interacțiunea Patroni cu clusterul Consul. Și acest agent devine un blocaj. Dacă se întâmplă ceva cu agentul, atunci Patroni nu mai poate lucra cu clusterul Consul. Și aceasta este problema. Nu există niciun agent în planul Etcd. Patroni poate lucra direct cu o listă de servere Etcd și poate comunica deja cu acestea. În acest sens, dacă folosești Etcd în compania ta, atunci Etcd va fi probabil o alegere mai bună decât Consul. Dar noi, clienții noștri, suntem întotdeauna limitați de ceea ce a ales și folosește clientul. Și avem Consul în cea mai mare parte pentru toți clienții.
- Și ultimul punct este revizuirea valorilor parametrilor. Putem ridica acești parametri în speranța că problemele noastre de rețea pe termen scurt vor fi scurte și nu vor fi în afara intervalului acestor parametri. În acest fel, putem reduce agresivitatea Patroni de a autofile dacă apar unele probleme de rețea.
Я думаю, многие, кто используют Patroni, знакомы с этой командой.
Această comandă arată starea curentă a clusterului. Și la prima vedere, această imagine poate părea normală. Avem un maestru, avem o replică, nu există nicio întârziere de replicare. Dar această imagine este normală exact până când știm că acest cluster ar trebui să aibă trei noduri, nu două.
În consecință, a existat un fișier automat. Și după acest fișier automat, replica noastră a dispărut. Trebuie să aflăm de ce a dispărut și să o aducem înapoi, să o restabilim. Și mergem din nou la jurnalele și vedem de ce am avut un auto-fileover.
În acest caz, a doua replică a devenit maestru. E totul în regulă aici.
Și trebuie să ne uităm la replica care a căzut și care nu se află în cluster. Deschidem jurnalele Patroni și vedem că am avut o problemă în timpul procesului de conectare la cluster în etapa pg_wind. Pentru a vă conecta la cluster, trebuie să derulați înapoi jurnalul de tranzacții, să solicitați jurnalul de tranzacții necesar de la master și să îl utilizați pentru a ajunge din urmă cu masterul.
В данном случае у нас нет журнала транзакций и реплика не может запуститься. Соответственно, мы Postgres останавливаем с ошибкой. И поэтому ее нет в кластере.
Trebuie să înțelegem de ce nu este în cluster și de ce nu au existat jurnalele. Mergem la noul maestru și ne uităm la ce are el în jurnalele. Se pare că atunci când pg_wind a fost terminat, a avut loc un punct de control. Și unele dintre vechile jurnale de tranzacții au fost pur și simplu redenumite. Când vechiul master a încercat să se conecteze la noul master și să interogheze aceste jurnale, acestea au fost deja redenumite, pur și simplu nu existau.
Am comparat marcajele de timp când au avut loc aceste evenimente. Și acolo diferența este literalmente de 150 de milisecunde, adică punctul de control finalizat în 369 de milisecunde, segmentele WAL au fost redenumite. Și literalmente în 517, după 150 de milisecunde, a început derularea pe vechea replică. Adică, literalmente, 150 de milisecunde au fost suficiente pentru noi, astfel încât replica să nu se poată conecta și să câștige.
Care sunt opțiunile?
Am folosit inițial sloturi de replicare. Am crezut că e bine. Deși la prima etapă de funcționare am oprit sloturile. Ni s-a părut că dacă sloturile acumulează o mulțime de segmente WAL, putem scăpa de master. El va cădea. Am suferit de ceva vreme fără sloturi. Și ne-am dat seama că avem nevoie de sloturi, am returnat sloturile.
Dar există o problemă aici, că atunci când masterul merge la replică, șterge sloturile și șterge segmentele WAL împreună cu sloturile. Și pentru a elimina această problemă, am decis să creștem parametrul wal_keep_segments. Este implicit la 8 segmente. L-am ridicat la 1 și ne-am uitat la cât spațiu liber avem. Și am donat 000 gigaocteți pentru wal_keep_segments. Adică, la comutare, avem întotdeauna o rezervă de 16 gigaocteți de jurnal de tranzacții pe toate nodurile.
Și în plus - este încă relevant pentru sarcinile de întreținere pe termen lung. Să presupunem că trebuie să actualizăm una dintre replici. Și vrem să-l oprim. Trebuie să actualizăm software-ul, poate sistemul de operare, altceva. Și când oprim o replică, slotul pentru acea replică este de asemenea eliminat. Și dacă folosim un mic wal_keep_segments, atunci cu o absență îndelungată a unei replici, jurnalele de tranzacții se vor pierde. Vom ridica o replică, va solicita acele jurnale de tranzacții unde s-a oprit, dar este posibil să nu fie pe master. Și nici replica nu se va putea conecta. Prin urmare, păstrăm un stoc mare de reviste.
Avem o bază de producție. Sunt deja proiecte în derulare.
Произошел файловер. Мы зашли и посмотрели – все в порядке, реплики на месте, лага репликации нет. Ошибок по журналам тоже нет, все в порядке.
Продуктовая команда говорит, что вроде бы как должны быть какие-то данные, но мы их по одному источнику видим, а в базе мы их не видим. И надо понять, что с ними произошло.
Понятно, что pg_rewind их затер. Мы сразу это поняли, но пошли смотреть, что происходило.
În jurnale, putem găsi întotdeauna când a avut loc filerul, cine a devenit maestru și putem determina cine a fost vechiul maestru și când a vrut să devină o replică, adică avem nevoie de aceste jurnale pentru a afla cantitatea de jurnale de tranzacții care a fost pierdut.
Vechiul nostru maestru a repornit. Și Patroni a fost înregistrat în autorun. S-a lansat Patroni. Apoi a început Postgres. Mai exact, înainte de a începe Postgres și înainte de a-l face o replică, Patroni a lansat procesul pg_wind. În consecință, a șters o parte din jurnalele de tranzacții, a descărcat altele noi și s-a conectat. Aici Patroni a lucrat inteligent, adică așa cum era de așteptat. Clusterul a fost restaurat. Am avut 3 noduri, după filer 3 noduri - totul este cool.
Am pierdut câteva date. Și trebuie să înțelegem cât de mult am pierdut. Căutăm doar momentul în care am avut un derulare înapoi. Îl putem găsi în astfel de înregistrări de jurnal. Rewind a început, a făcut ceva acolo și s-a terminat.
Trebuie să găsim poziția în jurnalul de tranzacții de unde a rămas vechiul master. În acest caz, aceasta este marca. Și avem nevoie de un al doilea semn, adică distanța cu care vechiul maestru diferă de cel nou.
Luăm pg_wal_lsn_diff obișnuit și comparăm aceste două mărci. Și în acest caz, obținem 17 megaocteți. Mult sau puțin, fiecare decide singur. Pentru că pentru cineva 17 megaocteți nu este mult, pentru cineva este mult și inacceptabil. Aici, fiecare individ se determină singur în conformitate cu nevoile afacerii.
Dar ce am aflat noi înșine?
În primul rând, trebuie să decidem singuri - avem întotdeauna nevoie de Patroni să pornească automat după o repornire a sistemului? Se întâmplă adesea să trebuiască să mergem la bătrânul maestru, să vedem cât de departe a mers. Poate inspectați segmente din jurnalul de tranzacții, vedeți ce este acolo. Și să înțelegem dacă putem pierde aceste date sau dacă trebuie să rulăm vechiul master în modul independent pentru a scoate aceste date.
И только уже после этого должны принять решения, что мы можем эти данные отбросить или мы можем их восстановить, подключить вот этот узел в качестве реплики в наш кластер.
Помимо этого, есть параметр «maximum_lag_on_failover». По умолчанию, если мне не изменяет память, этот параметр имеет значение 1 мегабайт.
Cum lucrează? Dacă replica noastră este în urmă cu 1 megaoctet de date în decalajul de replicare, atunci această replica nu ia parte la alegeri. Și dacă dintr-o dată apare un fileover, Patroni se uită la ce replici rămân în urmă. Dacă sunt în urmă cu un număr mare de jurnale de tranzacții, nu pot deveni master. Aceasta este o caracteristică de securitate foarte bună care vă împiedică să pierdeți o mulțime de date.
Но тут есть проблема в том, что лаг репликации в кластере Patroni и DCS обновляется с определенным интервалом. По-моему, 30 секунд значение ttl по умолчанию.
În consecință, poate exista o situație în care există o întârziere de replicare pentru replici în DCS, dar de fapt poate exista o întârziere complet diferită sau poate să nu existe deloc întârziere, adică acest lucru nu este în timp real. Și nu reflectă întotdeauna imaginea reală. Și nu merită să faci o logică fantezică asupra lui.
Și riscul de pierdere rămâne întotdeauna. Și în cel mai rău caz, o formulă, iar în cazul mediu, o altă formulă. Adică, atunci când planificăm implementarea Patroni și evaluăm câte date putem pierde, trebuie să ne bazăm pe aceste formule și să ne imaginăm aproximativ câte date putem pierde.
Și sunt vești bune. Când vechiul maestru a mers înainte, el poate merge înainte datorită unor procese de fundal. Adică a existat un fel de autovacuum, a scris datele, le-a salvat în jurnalul de tranzacții. Și putem ignora și pierde cu ușurință aceste date. Nu este nicio problemă în asta.
Și așa arată jurnalele dacă maximum_lag_on_failover este setat și a apărut un filer și trebuie să selectați un nou master. Replica se consideră incapabilă să participe la alegeri. Și refuză să participe la cursa pentru lider. Și așteaptă să fie selectat un nou maestru, pentru a se putea conecta apoi la el. Aceasta este o măsură suplimentară împotriva pierderii de date.
Aici avem o echipă de produse care a scris că produsul lor are probleme cu Postgres. În același timp, masterul în sine nu poate fi accesat, deoarece nu este disponibil prin SSH. Și nici fișierul automat nu se întâmplă.
Această gazdă a fost forțată să repornească. Din cauza repornirii, a avut loc un fișier automat, deși a fost posibil să se facă un fișier automat manual, după cum am înțeles acum. Și după repornire, vom vedea deja ce am avut cu actualul master.
При этом мы заранее знали, что у нас проблемы были с дисками, т. е. мы уже по мониторингу знали, где копать и что искать.
Am intrat în jurnalul postgres și am început să vedem ce se întâmplă acolo. Am văzut comiteri care durează acolo una, două, trei secunde, ceea ce nu este deloc normal. Am văzut că autovacuumul nostru pornește foarte lent și ciudat. Și am văzut fișiere temporare pe disc. Adică, aceștia sunt toți indicatori ai problemelor cu discurile.
Ne-am uitat în sistemul dmesg (jurnalul kernelului). Și am văzut că avem probleme cu unul dintre discuri. Subsistemul de disc a fost software-ul Raid. Ne-am uitat la /proc/mdstat și am văzut că ne lipsea o unitate. Adică există un Raid de 8 discuri, ne lipsește unul. Dacă te uiți cu atenție la slide, atunci în ieșire poți vedea că nu avem sde acolo. La noi, condiționat vorbind, discul a picat. Acest lucru a declanșat probleme de disc, iar aplicațiile au întâmpinat și probleme atunci când lucrau cu clusterul Postgres.
Și în acest caz, Patroni nu ne-ar ajuta în niciun fel, pentru că Patroni nu are sarcina de a monitoriza starea serverului, starea discului. Și trebuie să monitorizăm astfel de situații prin monitorizare externă. Am adăugat rapid monitorizarea discului la monitorizarea externă.
Și a existat un astfel de gând - ar putea să ne ajute software-ul de scrimă sau de supraveghere? Ne-am gândit că cu greu ne-ar fi ajutat în acest caz, pentru că în timpul problemelor Patroni a continuat să interacționeze cu clusterul DCS și nu a văzut nicio problemă. Adică din punctul de vedere al DCS și Patroni totul a fost în regulă cu clusterul, deși de fapt au fost probleme cu discul, au fost probleme cu disponibilitatea bazei de date.
După părerea mea, aceasta este una dintre cele mai ciudate probleme pe care le-am cercetat de foarte mult timp, am citit o mulțime de jurnale, am re-ales și am numit-o un simulator de cluster.
Problema era că vechiul maestru nu putea deveni o replică normală, adică Patroni a început-o, Patroni a arătat că acest nod era prezent ca o replică, dar în același timp nu era o replică normală. Acum vei vedea de ce. Aceasta este ceea ce am reținut din analiza acestei probleme.
И с чего все началось? Началось, как и в предыдущей проблеме, с дисковых тормозов. У нас были коммиты по секунде, по две.
Au fost întreruperi în conexiuni, adică clienții au fost rupti.
Au existat blocaje de severitate diferită.
Și, în consecință, subsistemul de disc nu este foarte receptiv.
И самое загадочное для меня – это прилетевший immediate shutdown request. У Postgres есть три режима выключения:
- Este grațios când așteptăm ca toți clienții să se deconecteze singuri.
- Există rapid când forțăm clienții să se deconecteze pentru că ne vom opri.
- Și imediat. În acest caz, immediate nici măcar nu le spune clienților să se închidă, ci doar se oprește fără avertisment. Și tuturor clienților, sistemul de operare trimite deja un mesaj RST (un mesaj TCP că conexiunea este întreruptă și clientul nu mai are nimic de prins).
Cine a trimis acest semnal? Procesele de fundal Postgres nu trimit astfel de semnale unul altuia, adică acesta este kill-9. Ei nu își trimit astfel de lucruri unul altuia, ci doar reacționează la astfel de lucruri, adică aceasta este o repornire de urgență a Postgres. Cine a trimis-o, nu știu.
M-am uitat la „ultima” comandă și am văzut o persoană care s-a autentificat și pe acest server la noi, dar am fost prea timid să pun o întrebare. Poate a fost uciderea -9. Aș vedea kill -9 în jurnalele, pentru că Postgres spune că a fost nevoie de kill -9, dar nu l-am văzut în jurnalele.
Privind mai departe, am văzut că Patroni nu a scris în jurnal destul de mult timp - 54 de secunde. Și dacă comparăm două marcaje temporale, nu au existat mesaje timp de aproximativ 54 de secunde.
Și în acest timp a existat un fișier automat. Patroni a făcut din nou o treabă grozavă aici. Bătrânul nostru maestru a fost indisponibil, i s-a întâmplat ceva. Și a început alegerea unui nou maestru. Totul a mers bine aici. Pgsql01 nostru a devenit noul lider.
У нас есть реплика, которая стала мастером. И есть вторая реплика. И со второй репликой как раз были проблемы. Она пыталась переконфигурироваться. Как я понимаю, она пыталась поменять recovery.conf, перезапустить Postgres и подключиться к новому мастеру. Она каждые 10 секунд пишет сообщения, что она пытается, но у нее не получается.
Și în timpul acestor încercări, un semnal de oprire imediată ajunge la vechiul maestru. Master-ul este repornit. Și, de asemenea, recuperarea se oprește deoarece vechiul master intră în repornire. Adică replica nu se poate conecta la ea, deoarece este în modul de închidere.
La un moment dat, a funcționat, dar replicarea nu a început.
Singura mea presupunere este că a fost o veche adresă master în recovery.conf. Și când a apărut un nou maestru, a doua replică a încercat în continuare să se conecteze la vechiul maestru.
Când Patroni a pornit la a doua replică, nodul a pornit, dar nu s-a putut replica. Și s-a format un lag de replicare, care arăta cam așa. Adică toate cele trei noduri erau la locul lor, dar al doilea nod a rămas în urmă.
În același timp, dacă te uiți la jurnalele care au fost scrise, ai putea vedea că replicarea nu a putut începe deoarece jurnalele de tranzacții erau diferite. Și acele jurnale de tranzacții pe care le oferă masterul, care sunt specificate în recovery.conf, pur și simplu nu se potrivesc cu nodul nostru actual.
Și aici am făcut o greșeală. A trebuit să vin și să văd ce era în recovery.conf pentru a-mi testa ipoteza că ne conectăm la master greșit. Dar atunci mă ocupam doar de asta și nu mi-a trecut prin minte, sau am văzut că replica rămâne în urmă și ar trebui să fie reumplută, adică am lucrat cumva nepăsător. Acesta a fost articulația mea.
După 30 de minute, a venit deja administratorul, adică am repornit Patroni pe replică. Deja i-am pus capat, m-am gandit ca trebuie reumplut. Și m-am gândit - repornesc Patroni, poate va ieși ceva bun. Recuperarea a început. Și baza chiar s-a deschis, era gata să accepte conexiuni.
Репликация запустилась. Но через минуту она отвалилась с ошибкой, что ей не подходит журналы транзакций.
Я подумал, что еще раз перезапущу. Я перезапустил еще раз Patroni, причем я не перезапускал Postgres, а перезапускал именно Patroni в надежде, что он магическим образом запустит базу.
Replicarea a început din nou, dar semnele din jurnalul de tranzacții erau diferite, nu erau aceleași cu încercarea anterioară de pornire. Replicarea sa oprit din nou. Și mesajul era deja puțin diferit. Și nu a fost foarte informativ pentru mine.
Și apoi îmi trece prin minte - ce se întâmplă dacă repornesc Postgres, în acest moment fac un punct de control pe masterul curent pentru a muta punctul din jurnalul de tranzacții puțin înainte, astfel încât recuperarea să înceapă dintr-un alt moment? În plus, mai aveam stocuri de WAL.
Am repornit Patroni, am făcut câteva puncte de control pe master, câteva puncte de repornire pe replica când s-a deschis. Și a ajutat. M-am gândit mult timp de ce a ajutat și cum a funcționat. Și replica a început. Și replicarea nu a mai fost ruptă.
Такая проблема для меня одна из более загадочных, над которой я до сих пор ломаю голову, что там происходило на самом деле.
Care sunt implicațiile aici? Patroni poate funcționa conform intenției și fără erori. Dar, în același timp, aceasta nu este o garanție 100% că totul este în regulă pentru noi. Replica poate începe, dar poate fi într-o stare de semifuncționare, iar aplicația nu poate funcționa cu o astfel de replică, deoarece vor exista date vechi.
И после файловера всегда нужно проверять, что у нас все в порядке с кластером, т. е. есть нужное количество реплик, нет лага репликации.
Și pe măsură ce trecem prin aceste probleme, voi face recomandări. Am încercat să le combin în două diapozitive. Probabil, toate poveștile ar putea fi combinate în două diapozitive și doar spuse.
Când utilizați Patroni, trebuie să aveți monitorizare. Ar trebui să știți întotdeauna când a avut loc un autofileover, deoarece dacă nu știți că ați avut o autofileover, nu aveți control asupra clusterului. Și asta e rău.
După fiecare filer, trebuie întotdeauna să verificăm manual clusterul. Trebuie să ne asigurăm că avem mereu un număr de replici la zi, nu există lag de replicare, nu există erori în log-urile legate de replicarea în streaming, cu Patroni, cu sistemul DCS.
Automatizarea poate funcționa cu succes, Patroni este un instrument foarte bun. Poate funcționa, dar acest lucru nu va aduce clusterul la starea dorită. Și dacă nu aflăm despre asta, vom avea probleme.
Și Patroni nu este un glonț de argint. Încă trebuie să înțelegem cum funcționează Postgres, cum funcționează replicarea și cum funcționează Patroni cu Postgres și cum este asigurată comunicarea între noduri. Acest lucru este necesar pentru a putea rezolva problemele cu mâinile tale.
Как я подхожу к вопросу диагностики? Так сложилось, что мы работаем с разными клиентами и стека ELK ни у кого нет, и приходится в логах разбираться, открыв 6 консолей и 2 вкладки. В одной вкладке – это логи Patroni для каждого узла, в другой вкладке – это логи Consul, либо Postgres при необходимости. Диагностировать это очень тяжело.
Ce abordări am luat? În primul rând, mă uit mereu când a sosit filerul. Și pentru mine aceasta este o cotitură. Mă uit la ceea ce s-a întâmplat înainte de filer, în timpul filer și după filer. Fileover are două semne: aceasta este ora de început și de sfârșit.
Далее я в логах смотрю события до файловера, что предшествовало файловеру, т. е. я ищу причины, почему произошел файловер.
Și aceasta oferă o imagine a înțelegerii a ceea ce s-a întâmplat și a ceea ce se poate face în viitor, astfel încât astfel de circumstanțe să nu apară (și, ca urmare, nu există niciun filer).
Și unde ne uităm de obicei? ma uit:
- În primul rând, în jurnalele Patroni.
- Далее смотрю логи Postgres, либо логи DCS в зависимости оттого, что нашлось в логах Patroni.
- Și jurnalele de sistem oferă, de asemenea, uneori o înțelegere a cauzei filerului.
Ce părere am despre Patroni? Am o relație foarte bună cu Patroni. După părerea mea, acesta este cel mai bun lucru care există astăzi. Cunosc multe alte produse. Acestea sunt Stolon, Repmgr, Pg_auto_failover, PAF. 4 unelte. Le-am încercat pe toate. Patroni este preferatul meu.
Если меня спросят: «Рекомендую ли я Patroni?». Я скажу, что да, потому что Patroni мне нравится. И, мне кажется, я научился его готовить.
Если вам интересно посмотреть, какие еще бывают проблемы с Patroni, кроме тех проблем, которые я озвучил, вы всегда можете сходить на страницу pe GitHub. Există multe povești diferite și multe probleme interesante sunt discutate acolo. Și, ca urmare, au fost introduse și rezolvate unele erori, adică aceasta este o lectură interesantă.
Там есть интересные истории о том, как люди стреляют себе в ногу. Очень познавательно. Ты читаешь и понимаешь, что так делать не надо. Поставил себе галочку.
Și aș dori să îi mulțumesc lui Zalando pentru dezvoltarea acestui proiect, și anume lui Alexander Kukushkin și Alexey Klyukin. Aleksey Klyukin este unul dintre coautori, nu mai lucrează la Zalando, dar sunt doi oameni care au început să lucreze cu acest produs.
Și cred că Patroni este un lucru foarte tare. Mă bucur că există, e interesant cu ea. Și un mare mulțumire tuturor colaboratorilor care scriu patch-uri la Patroni. Sper ca Patroni să devină mai matur, cool și mai eficient odată cu vârsta. Este deja funcțional, dar sper să fie și mai bine. Prin urmare, dacă intenționați să utilizați Patroni, atunci nu vă fie teamă. Aceasta este o soluție bună, poate fi implementată și utilizată.
Asta e tot. Dacă aveți întrebări, întrebați.
întrebări
Спасибо за доклад! Если после файловера все равно надо туда смотреть очень внимательно, то зачем нам автоматический файловер?
Pentru că sunt lucruri noi. Suntem cu ea doar de un an. Mai bine să fii în siguranță. Vrem să intrăm și să vedem că totul a funcționat într-adevăr așa cum ar trebui. Acesta este nivelul de neîncredere a adulților - este mai bine să verificați și să vedeți.
De exemplu, ne-am dus dimineața și ne-am uitat, nu?
Nu dimineața, de obicei aflăm despre fișierul automat aproape imediat. Primim notificări, vedem că a apărut un autofile. Aproape imediat mergem și ne uităm. Dar toate aceste verificări ar trebui aduse la nivel de monitorizare. Dacă accesați Patroni prin API-ul REST, există un istoric. După istoric, puteți vedea marcajele de timp când a avut loc filerul. Pe baza acestui lucru se poate face monitorizare. Puteți vedea istoria, câte evenimente au fost acolo. Dacă avem mai multe evenimente, atunci a avut loc un fișier automat. Poți merge și vezi. Sau automatizarea noastră de monitorizare a verificat că avem toate replicile la locul lor, nu există decalaj și totul este în regulă.
Vă mulțumim!
Большое спасибо за отличный рассказ! Если мы вынесли кластер DCS куда-то вдаль от кластера Postgres, то этот кластер тоже надо обслуживать периодически? Какие best practices в том, что какие-то куски кластера DCS надо выключать, что-то с ними делать и т. д.? Как при этом живет вся эта конструкция? И каким образом эти вещи делать?
Pentru o companie, a fost necesar să se facă o matrice de probleme, ce se întâmplă dacă una dintre componente sau mai multe componente se defectează. Conform acestei matrice, parcurgem secvențial toate componentele și construim scenarii în cazul defecțiunii acestor componente. În consecință, pentru fiecare scenariu de eșec, puteți avea un plan de acțiune pentru recuperare. Și în cazul DCS, acesta vine ca parte a infrastructurii standard. Iar administratorul îl administrează, iar noi ne bazăm deja pe adminii care îl administrează și pe capacitatea lor de a o remedia în caz de accidente. Dacă nu există deloc DCS, atunci îl implementăm, dar în același timp nu îl monitorizăm în mod deosebit, pentru că nu suntem responsabili pentru infrastructură, dar dăm recomandări despre cum și ce să monitorizăm.
Т. е. правильно ли я понял, что надо отключить Patroni, отключить файловер, отключить все перед тем, как делать что-то с хостами?
Depinde de câte noduri avem în clusterul DCS. Dacă sunt multe noduri și dacă dezactivăm doar unul dintre noduri (replica), atunci clusterul menține un cvorum. Și Patroni rămâne operațional. Și nimic nu este declanșat. Dacă avem unele operațiuni complexe care afectează mai multe noduri, a căror absență poate ruina cvorumul, atunci - da, ar putea avea sens să-l punem pe Patroni pe pauză. Are o comandă corespunzătoare - patronictl pauză, patronictl reluare. Facem doar o pauză și autofilerul nu funcționează în acel moment. Facem întreținere pe clusterul DCS, apoi luăm pauza și continuăm să trăim.
Vă mulțumesc foarte mult!
Vă mulțumesc foarte mult pentru raport! Cum se simte echipa de produs despre pierderea datelor?
Echipelor de produse nu le pasă, iar liderii echipelor sunt îngrijorați.
Ce garanții există?
Garanțiile sunt foarte dificile. Alexander Kukushkin are un raport „Cum se calculează RPO și RTO”, adică timpul de recuperare și câte date putem pierde. Cred că trebuie să găsim aceste diapozitive și să le studiem. Din câte îmi amintesc, există pași specifici pentru a calcula aceste lucruri. Câte tranzacții putem pierde, câte date putem pierde. Opțional, putem folosi replicarea sincronă la nivelul Patroni, dar aceasta este o sabie cu două tăișuri: fie avem fiabilitatea datelor, fie pierdem viteza. Există o replicare sincronă, dar nici nu garantează protecție 100% împotriva pierderii datelor.
Alexey, mulțumesc pentru raportul grozav! Aveți experiență cu utilizarea Patroni pentru protecție la nivel zero? Adică, împreună cu standby sincron? Aceasta este prima întrebare. Și a doua întrebare. Ați folosit diferite soluții. Am folosit Repmgr, dar fără autofiler, iar acum plănuim să includem autofiler. Și considerăm Patroni ca o soluție alternativă. Ce poti spune ca avantaje fata de Repmgr?
Prima întrebare a fost despre replicile sincrone. Nimeni nu folosește replicarea sincronă aici, pentru că toată lumea este speriată (mai mulți clienți o folosesc deja, în principiu, nu au observat probleme de performanță - Nota vorbitorului). Dar am dezvoltat o regulă pentru noi înșine că ar trebui să existe cel puțin trei noduri într-un cluster de replicare sincronă, deoarece dacă avem două noduri și dacă masterul sau replica eșuează, atunci Patroni comută acest nod în modul Standalone, astfel încât aplicația să continue muncă. În acest caz, există riscul pierderii datelor.
În ceea ce privește a doua întrebare, am folosit Repmgr și încă mai facem cu unii clienți din motive istorice. Ce se poate spune? Patroni vine cu un autofiler din cutie, Repmgr vine cu autofiler ca o caracteristică suplimentară care trebuie activată. Trebuie să rulăm demonul Repmgr pe fiecare nod și apoi putem configura autofilerul.
Repmgr verifică dacă nodurile Postgres sunt vii. Procesele Repmgr verifică existența reciprocă, aceasta nu este o abordare foarte eficientă. pot exista cazuri complexe de izolare a rețelei în care un cluster mare Repmgr se poate destrama în câteva mai mici și poate continua să funcționeze. Nu mai urmaresc Repmgr de mult, poate s-a rezolvat... sau poate nu. Dar eliminarea informațiilor despre starea clusterului din DCS, așa cum face Stolon, Patroni, este cea mai viabilă opțiune.
Alexey, am o întrebare, poate una mai lacerată. Într-unul dintre primele exemple, ați mutat DCS de pe mașina locală pe o gazdă la distanță. Înțelegem că rețeaua este un lucru care are propriile sale caracteristici, trăiește de la sine. Și ce se întâmplă dacă dintr-un anumit motiv clusterul DCS devine indisponibil? Nu voi spune motivele, pot fi o mulțime: de la mâinile strâmbe ale rețelelor până la probleme reale.
Nu am spus-o cu voce tare, dar clusterul DCS trebuie să fie și el failover, adică este un număr impar de noduri pentru ca un cvorum să fie îndeplinit. Ce se întâmplă dacă clusterul DCS devine indisponibil sau nu poate fi îndeplinit un cvorum, adică un fel de împărțire a rețelei sau defecțiune a nodului? În acest caz, clusterul Patroni intră în modul numai citire. Clusterul Patroni nu poate determina starea clusterului și ce trebuie făcut. Nu poate contacta DCS și nu poate stoca acolo noua stare a clusterului, astfel încât întregul cluster intră în doar citire. Și așteaptă fie intervenția manuală a operatorului, fie recuperarea DCS.
În linii mari, DCS devine un serviciu pentru noi la fel de important ca și baza în sine?
Da Da. În atât de multe companii moderne, Service Discovery este o parte integrantă a infrastructurii. Este implementat chiar înainte de a exista o bază de date în infrastructură. Relativ vorbind, infrastructura a fost lansată, implementată în DC și avem imediat Service Discovery. Dacă este Consul, atunci DNS poate fi construit pe el. Dacă acesta este Etcd, atunci poate exista o parte din clusterul Kubernetes, în care totul va fi implementat. Mi se pare că Service Discovery este deja o parte integrantă a infrastructurilor moderne. Și se gândesc la asta mult mai devreme decât la baze de date.
Vă mulțumim!
Sursa: www.habr.com