Qëllimi kryesor i Patroni është të sigurojë disponueshmëri të lartë për PostgreSQL. Por Patroni është thjesht një shabllon, jo një mjet i gatshëm (që, në përgjithësi, thuhet në dokumentacion). Në shikim të parë, pasi e keni vendosur Patroni në laboratorin e testimit, mund të shihni se çfarë mjeti i mrekullueshëm është dhe sa lehtë i trajton përpjekjet tona për të thyer grupin. Megjithatë, në praktikë, në një mjedis prodhimi, jo gjithmonë gjithçka ndodh aq bukur dhe elegante sa në një laborator testimi.
Unë do t'ju tregoj pak për veten time. Fillova si administrator sistemi. Ka punuar në zhvillimin e uebit. Unë punoj në Data Egret që nga viti 2014. Kompania është e angazhuar në konsulencë në fushën e Postgres. Dhe ne i sherbejme pikerisht Postgres, dhe punojme me Postgres cdo dite, pra kemi ekspertize te ndryshme ne lidhje me operacionin.
Dhe në fund të vitit 2018, filluam të përdorim ngadalë Patroni. Dhe pak përvojë është grumbulluar. Ne disi e diagnostikuam, e akorduam, arritëm në praktikat tona më të mira. Dhe në këtë raport do të flas për to.
Përveç Postgres, më pëlqen Linux. Më pëlqen të futem në të dhe të eksploroj, më pëlqen të mbledh bërthama. Më pëlqen virtualizimi, kontejnerët, docker, Kubernetes. E gjithë kjo më intereson, sepse zakonet e vjetra të administratorit po ndikojnë. Më pëlqen të merrem me monitorim. Dhe më pëlqejnë gjërat e postgres që lidhen me administrimin, p.sh. replikimin, rezervimin. Dhe në kohën time të lirë shkruaj në Go. Unë nuk jam një inxhinier softuerësh, thjesht shkruaj për veten time në Go. Dhe kjo më jep kënaqësi.
- Unë mendoj se shumë prej jush e dinë se Postgres nuk ka HA (Disponueshmëri e lartë) jashtë kutisë. Për të marrë HA, duhet të instaloni diçka, ta konfiguroni, të bëni një përpjekje dhe ta merrni atë.
- Ka disa mjete dhe Patroni është një prej tyre që e zgjidh HA mjaft mirë dhe shumë mirë. Por duke i vendosur të gjitha në një laborator testimi dhe duke e drejtuar atë, ne mund të shohim se gjithçka funksionon, ne mund të riprodhojmë disa probleme, të shohim se si Patroni u shërben atyre. Dhe ne do të shohim se gjithçka funksionon mirë.
- Por në praktikë u përballëm me probleme të ndryshme. Dhe unë do të flas për këto probleme.
- Unë do t'ju tregoj se si e kemi diagnostikuar atë, çfarë kemi ndryshuar - nëse na ka ndihmuar apo jo.
- Unë nuk do t'ju tregoj se si ta instaloni Patroni, sepse mund të kërkoni në internet në google, mund të shikoni skedarët e konfigurimit për të kuptuar se si fillon gjithçka, si është konfiguruar. Ju mund të kuptoni skemat, arkitekturat, duke gjetur informacion në lidhje me të në internet.
- Nuk do të flas për përvojën e dikujt tjetër. Unë do të flas vetëm për problemet me të cilat u përballëm.
- Dhe nuk do të flas për problemet që janë jashtë Patroni dhe PostgreSQL. Nëse, për shembull, ka probleme që lidhen me balancimin, kur grupi ynë është shembur, nuk do të flas për këtë.
Dhe një mohim i vogël para se të fillojmë raportin tonë.
Të gjitha këto probleme që kemi hasur i kemi pasur në 6-7-8 muajt e parë të funksionimit. Me kalimin e kohës, arritëm te praktikat tona më të mira të brendshme. Dhe problemet tona u zhdukën. Prandaj, raporti u njoftua rreth gjashtë muaj më parë, kur ishte i freskët në kokën time dhe i mbaja mend të gjitha në mënyrë të përsosur.
Gjatë përgatitjes së raportit, unë tashmë ngrita postmorteme të vjetra, shikova shkrimet. Dhe disa nga detajet mund të harrohen, ose disa nga disa detaje nuk mund të hetohen plotësisht gjatë analizës së problemeve, kështu që në disa pika mund të duket se problemet nuk janë shqyrtuar plotësisht, ose ka mungesë informacioni. Dhe prandaj ju kërkoj të më falni për këtë moment.
Çfarë është Patroni?
- Ky është një shabllon për ndërtimin e HA. Kështu thuhet në dokumentacion. Dhe nga këndvështrimi im, ky është një sqarim shumë korrekt. Patroni nuk është një plumb argjendi që do të zgjidhë të gjitha problemet tuaja, domethënë, ju duhet të bëni përpjekje për ta bërë atë të funksionojë dhe të sjellë përfitime.
- Ky është një shërbim agjenti që është i instaluar në çdo shërbim të bazës së të dhënave dhe është një lloj sistemi init për Postgres-in tuaj. Fillon Postgres, ndalon, rinis, rikonfiguron dhe ndryshon topologjinë e grupit tuaj.
- Prandaj, për të ruajtur gjendjen e grupit, përfaqësimi i tij aktual, siç duket, nevojitet një lloj ruajtjeje. Dhe nga ky këndvështrim Patroni mori rrugën e ruajtjes së shtetit në një sistem të jashtëm. Është një sistem i ruajtjes së konfigurimit të shpërndarë. Mund të jetë Etcd, Consul, ZooKeeper ose kubernetes Etcd, pra një nga këto opsione.
- Dhe një nga veçoritë e Patroni është që ju e nxirrni autofilerin nga kutia, vetëm duke e konfiguruar. Nëse marrim Repmgr për krahasim, atëherë skedari përfshihet atje. Me Repmgr, marrim një kalim, por nëse duam një skedar automatik, atëherë duhet ta konfigurojmë atë shtesë. Patroni tashmë ka një autofiler jashtë kutisë.
- Dhe ka shumë gjëra të tjera. Për shembull, mirëmbajtja e konfigurimeve, derdhja e kopjeve të reja, rezervimi, etj. Por kjo është përtej qëllimit të raportit, nuk do të flas për këtë.
Dhe një rezultat i vogël është se detyra kryesore e Patroni është të bëjë një skedar automatik mirë dhe me besueshmëri në mënyrë që grupi ynë të mbetet funksional dhe aplikacioni të mos vërejë ndryshime në topologjinë e grupimit.
Por kur fillojmë të përdorim Patroni, sistemi ynë bëhet pak më i komplikuar. Nëse më parë kishim Postgres, atëherë kur përdorim Patroni marrim vetë Patroni, marrim DCS ku ruhet gjendja. Dhe gjithçka duhet të funksionojë disi. Pra, çfarë mund të shkojë keq?
Mund të prishet:
- Postgres mund të thyhet. Mund të jetë një master ose një kopje, njëra prej tyre mund të dështojë.
- Vetë Patroni mund të prishet.
- DCS ku ruhet gjendja mund të prishet.
- Dhe rrjeti mund të prishet.
Të gjitha këto pika do t'i shqyrtoj në raport.
Unë do t'i shqyrtoj çështjet pasi ato bëhen më komplekse, jo nga pikëpamja që çështja përfshin shumë komponentë. Dhe nga pikëpamja e ndjenjave subjektive, se ky rast ishte i vështirë për mua, ishte e vështirë ta çmontoja ... dhe anasjelltas, një rast ishte i lehtë dhe ishte i lehtë për ta çmontuar.
Dhe rasti i parë është më i lehtë. Ky është rasti kur morëm një grup të dhënash dhe vendosëm ruajtjen tonë DCS në të njëjtin grup. Ky është gabimi më i zakonshëm. Ky është një gabim në ndërtimin e arkitekturave, d.m.th., kombinimi i komponentëve të ndryshëm në një vend.
Pra, kishte një skedar, le të shkojmë të merremi me atë që ndodhi.
Dhe këtu na intereson kur ka ndodhur skedari. Kjo do të thotë, ne jemi të interesuar për këtë moment në kohë kur gjendja e grupimit ndryshoi.
Por skedari nuk është gjithmonë i menjëhershëm, d.m.th. nuk kërkon asnjë njësi kohe, mund të vonohet. Mund të jetë afatgjatë.
Prandaj, ajo ka një kohë fillimi dhe një kohë mbarimi, pra është një ngjarje e vazhdueshme. Dhe ne i ndajmë të gjitha ngjarjet në tre intervale: kemi kohë para skedarit, gjatë skedarit dhe pas skedarit. Kjo do të thotë, ne i konsiderojmë të gjitha ngjarjet në këtë afat kohor.
Dhe gjëja e parë, kur ndodhi një skedar, ne kërkojmë shkakun e asaj që ndodhi, cili ishte shkaku i asaj që çoi në skedar.
Nëse shikojmë trungjet, do të jenë trungje klasike Patroni. Ai na thotë në to se serveri është bërë master dhe roli i masterit i ka kaluar kësaj nyje. Këtu është theksuar.
Më pas, duhet të kuptojmë pse ndodhi skedari, d.m.th. çfarë ngjarjesh ndodhën që shkaktuan kalimin e rolit master nga një nyje në tjetrën. Dhe në këtë rast, gjithçka është e thjeshtë. Kemi një gabim në ndërveprimin me sistemin e ruajtjes. Mjeshtri e kuptoi që ai nuk mund të punonte me DCS, domethënë kishte një lloj problemi me ndërveprimin. Dhe thotë se nuk mund të jetë më mjeshtër dhe jep dorëheqjen. Kjo linjë "vetë e ulur" thotë pikërisht këtë.
Nëse shikojmë ngjarjet që i paraprinë skedarit, mund të shohim aty vetë arsyet që shkaktuan problemin për të vazhduar magjistarin.
Nëse shikojmë regjistrat e Patroni, do të shohim se kemi shumë gabime, afate kohore, dmth agjenti Patroni nuk mund të punojë me DCS. Në këtë rast, ky është agjenti i konsullit, i cili komunikon në portin 8500.
Dhe problemi këtu është se Patroni dhe baza e të dhënave po funksionojnë në të njëjtin host. Dhe serverët e Konsullit u nisën në të njëjtën nyje. Duke krijuar një ngarkesë në server, krijuam probleme edhe për serverët e Konsullit. Ata nuk mund të komunikonin siç duhet.
Pas ca kohësh, kur ngarkesa u ul, Patroni ynë mundi të komunikonte sërish me agjentët. Rifilloi puna normale. Dhe i njëjti server Pgdb-2 u bë përsëri master. Kjo do të thotë, pati një rrokullisje të vogël, për shkak të së cilës nyja hoqi dorë nga fuqitë e zotit, dhe më pas i mori ato përsëri, domethënë gjithçka u kthye siç ishte.
Dhe kjo mund të konsiderohet si një alarm i rremë, ose mund të konsiderohet se Patroni bëri gjithçka në rregull. Kjo do të thotë, ai e kuptoi se nuk mund të ruante gjendjen e grupit dhe hoqi autoritetin e tij.
Dhe këtu problemi lindi për faktin se serverët e Konsullit janë në të njëjtin harduer si bazat. Prandaj, çdo ngarkesë: pavarësisht nëse është ngarkesa në disqe apo procesorë, ajo gjithashtu ndikon në ndërveprimin me grupin e Konsullit.
Dhe ne vendosëm që ajo të mos jetojë së bashku, kemi ndarë një grup të veçantë për Konsullin. Dhe Patroni tashmë punonte me një Konsull të veçantë, domethënë kishte një grup të veçantë Postgres, një grup konsulli më vete. Ky është një udhëzim bazë se si t'i mbani dhe mbani të gjitha këto gjëra në mënyrë që të mos jetojë së bashku.
Si opsion, ju mund të ktheni parametrat ttl, loop_wait, retry_timeout, d.m.th. të përpiqeni t'i mbijetoni këtyre majave afatshkurtra të ngarkesës duke rritur këto parametra. Por ky nuk është opsioni më i përshtatshëm, sepse kjo ngarkesë mund të jetë e gjatë në kohë. Dhe ne thjesht do të shkojmë përtej këtyre kufijve të këtyre parametrave. Dhe kjo mund të mos ndihmojë vërtet.
Problemi i parë, siç e kuptoni, është i thjeshtë. Morëm dhe vendosëm DCS-në bashkë me bazën, patëm një problem.
Problemi i dytë është i ngjashëm me të parën. Është e ngjashme në atë që ne përsëri kemi probleme të ndërveprimit me sistemin DCS.
Nëse shikojmë regjistrat, do të shohim që përsëri kemi një gabim komunikimi. Dhe Patroni thotë se nuk mund të ndërveproj me DCS, kështu që masteri aktual kalon në modalitetin e kopjes.
Mjeshtri i vjetër bëhet replikë, këtu Patroni ia del, si duhet. Ai ekzekuton pg_rewind për të rikthyer regjistrin e transaksioneve dhe më pas lidhet me masterin e ri për të kapur hapin me masterin e ri. Këtu Patroni ia del siç duhet.
Këtu duhet të gjejmë vendin që i parapriu skedarit, pra ato gabime që na bënë të kemi një skedar. Dhe në këtë drejtim, regjistrat Patroni janë mjaft të përshtatshëm për të punuar. Ai shkruan të njëjtat mesazhe në një interval të caktuar. Dhe nëse fillojmë të lëvizim shpejt nëpër këto regjistra, atëherë nga regjistrat do të shohim se regjistrat kanë ndryshuar, që do të thotë se disa probleme kanë filluar. Ne kthehemi shpejt në këtë vend, të shohim se çfarë ndodh.
Dhe në një situatë normale, shkrimet duken diçka si kjo. Pronari i bravës kontrollohet. Dhe nëse pronari, për shembull, ka ndryshuar, atëherë mund të ndodhin disa ngjarje që Patroni duhet t'i përgjigjet. Por në këtë rast jemi mirë. Po kërkojmë vendin ku nisën gabimet.
Dhe pasi kemi lëvizur deri në pikën ku filluan të shfaqen gabimet, shohim që kemi pasur një skedar automatik. Dhe duke qenë se gabimet tona kishin të bënin me ndërveprimin me DCS dhe në rastin tonë ne përdorëm Konsullin, ne shikojmë gjithashtu regjistrat e Konsullit, çfarë ndodhi atje.
Duke krahasuar përafërsisht kohën e skedarit dhe kohën në regjistrat e Konsullit, shohim se fqinjët tanë në grupin e Konsullit filluan të dyshojnë për ekzistencën e anëtarëve të tjerë të grupit të Konsullit.
Dhe nëse shikoni edhe regjistrat e agjentëve të tjerë të Konsullit, mund të shihni gjithashtu se një lloj kolapsi i rrjetit po ndodh atje. Dhe të gjithë anëtarët e grupit të Konsullit dyshojnë në ekzistencën e njëri-tjetrit. Dhe kjo ishte shtysa për skedarin.
Nëse shikoni se çfarë ndodhi para këtyre gabimeve, mund të shihni se ka të gjitha llojet e gabimeve, për shembull, afati, RPC ra, domethënë, ekziston qartë një lloj problemi në ndërveprimin e anëtarëve të grupit të konsullit me njëri-tjetrin. .
Përgjigja më e thjeshtë është riparimi i rrjetit. Por për mua, duke qëndruar në podium, është e lehtë ta them këtë. Por rrethanat janë të tilla që jo gjithmonë klienti mund të përballojë riparimin e rrjetit. Ai mund të jetojë në një DC dhe mund të mos jetë në gjendje të riparojë rrjetin, të ndikojë në pajisjet. Dhe kështu nevojiten disa opsione të tjera.
Ka opsione:
- Opsioni më i thjeshtë, i cili është shkruar, për mendimin tim, edhe në dokumentacion, është të çaktivizoni kontrollet e konsullit, domethënë thjesht të kaloni një grup bosh. Dhe ne i themi agjentit të Konsullit të mos përdorë asnjë kontroll. Me këto kontrolle, ne mund t'i injorojmë këto stuhi rrjeti dhe të mos iniciojmë një skedar.
- Një tjetër mundësi është të kontrolloni dy herë raft_multiplier. Ky është një parametër i vetë serverit të Konsullit. Si parazgjedhje, është vendosur në 5. Kjo vlerë rekomandohet nga dokumentacioni për mjediset e vendosjes. Në fakt, kjo ndikon në frekuencën e mesazheve ndërmjet anëtarëve të rrjetit të Konsullit. Në fakt, ky parametër ndikon në shpejtësinë e komunikimit të shërbimit ndërmjet anëtarëve të grupit të Konsullit. Dhe për prodhimin, tashmë rekomandohet zvogëlimi i tij në mënyrë që nyjet të shkëmbejnë mesazhe më shpesh.
- Një tjetër opsion që kemi dalë është rritja e prioritetit të proceseve të Konsullit midis proceseve të tjera për planifikuesin e proceseve të sistemit operativ. Ekziston një parametër i tillë "i bukur", ai thjesht përcakton përparësinë e proceseve që merret parasysh nga planifikuesi i OS gjatë planifikimit. Kemi ulur edhe vlerën e këndshme për agjentët e Konsullit, d.m.th. rriti prioritetin në mënyrë që sistemi operativ t'u japë proceseve të Konsullit më shumë kohë për të punuar dhe për të ekzekutuar kodin e tyre. Në rastin tonë, kjo e zgjidhi problemin tonë.
- Një opsion tjetër është të mos përdorni Konsullin. Unë kam një mik që është një mbështetës i madh i Etcd. Dhe ne rregullisht debatojmë me të se cili është më mirë Etcd apo Konsull. Por për sa i përket asaj se cila është më e mirë, ne zakonisht pajtohemi me të që Konsulli ka një agjent që duhet të funksionojë në secilën nyje me një bazë të dhënash. Domethënë, ndërveprimi i Patronit me grupin e konsullit kalon përmes këtij agjenti. Dhe ky agjent bëhet një pengesë. Nëse diçka i ndodh agjentit, atëherë Patroni nuk mund të punojë më me grupin e Konsullit. Dhe ky është problemi. Nuk ka asnjë agjent në planin Etcd. Patroni mund të punojë drejtpërdrejt me një listë të serverëve Etcd dhe tashmë të komunikojë me ta. Në këtë drejtim, nëse përdorni Etcd në kompaninë tuaj, atëherë Etcd ndoshta do të jetë një zgjedhje më e mirë se Konsulli. Por ne te klientët tanë jemi gjithmonë të kufizuar nga ajo që klienti ka zgjedhur dhe përdor. Dhe ne kemi Konsullin në pjesën më të madhe për të gjithë klientët.
- Dhe pika e fundit është rishikimi i vlerave të parametrave. Ne mund t'i rrisim këto parametra me shpresën se problemet tona afatshkurtra të rrjetit do të jenë të shkurtra dhe nuk do të bien jashtë gamës së këtyre parametrave. Në këtë mënyrë ne mund të reduktojmë agresivitetin e Patroni në skedarin automatik nëse ndodhin disa probleme në rrjet.
Unë mendoj se shumë që përdorin Patroni janë të njohur me këtë komandë.
Kjo komandë tregon gjendjen aktuale të grupit. Dhe në shikim të parë, kjo foto mund të duket normale. Ne kemi një master, kemi një kopje, nuk ka vonesë replikimi. Por kjo pamje është normale saktësisht derisa të dimë se ky grup duhet të ketë tre nyje, jo dy.
Prandaj, ekzistonte një skedar automatik. Dhe pas këtij skedari automatik, kopja jonë u zhduk. Ne duhet të zbulojmë pse ajo u zhduk dhe ta kthejmë atë, ta rivendosim atë. Dhe ne përsëri shkojmë te regjistrat dhe shohim pse kishim një skedar automatik.
Në këtë rast, kopja e dytë u bë mjeshtër. Gjithçka është këtu.
Dhe ne duhet të shohim kopjen që ra dhe që nuk është në grup. Hapim regjistrat Patroni dhe shohim që kemi pasur një problem gjatë procesit të lidhjes me grupin në fazën pg_rewind. Për t'u lidhur me grupin, duhet të ktheni regjistrin e transaksioneve, të kërkoni regjistrin e kërkuar të transaksioneve nga masteri dhe ta përdorni atë për të kapur hapin me masterin.
Në këtë rast, ne nuk kemi një regjistër transaksionesh dhe kopja nuk mund të fillojë. Prandaj, ne ndalojmë Postgres me një gabim. Dhe për këtë arsye nuk është në grup.
Ne duhet të kuptojmë pse nuk është në grup dhe pse nuk kishte regjistra. Shkojmë te mjeshtri i ri dhe shikojmë se çfarë ka ai në shkrime. Rezulton se kur u krye pg_rewind, ndodhi një pikë kontrolli. Dhe disa nga regjistrat e vjetër të transaksioneve thjesht u riemëruan. Kur mjeshtri i vjetër u përpoq të lidhej me masterin e ri dhe të kërkonte këto regjistra, ato tashmë ishin riemërtuar, thjesht nuk ekzistonin.
Kam krahasuar vulat kohore kur kanë ndodhur këto ngjarje. Dhe këtu ndryshimi është fjalë për fjalë 150 milisekonda, domethënë, pika e kontrollit e përfunduar në 369 milisekonda, segmentet WAL u riemëruan. Dhe fjalë për fjalë në 517, pas 150 milisekondash, filloi rikthimi në kopjen e vjetër. Kjo do të thotë, fjalë për fjalë 150 milisekonda na mjaftuan në mënyrë që kopja të mos mund të lidhej dhe të fitonte.
Cilat janë opsionet?
Fillimisht kemi përdorur lojëra elektronike të riprodhimit. Ne menduam se ishte mirë. Edhe pse në fazën e parë të funksionimit ne fikëm lojëra elektronike. Na u duk se nëse slotet grumbullojnë shumë segmente WAL, ne mund ta heqim masterin. Ai do të bjerë. Ne vuajtëm për ca kohë pa lojëra elektronike. Dhe e kuptuam se na duheshin lojëra elektronike, i kthyem slotet.
Por këtu ka një problem, që kur masteri shkon te replika, ai fshin lojëra elektronike dhe fshin segmentet WAL së bashku me lojëra elektronike. Dhe për të eliminuar këtë problem, vendosëm të rrisim parametrin wal_keep_segments. Parazgjedhja është në 8 segmente. E ngritëm në 1 dhe shikuam sa hapësirë të lirë kishim. Dhe ne dhuruam 000 gigabajt për wal_keep_segments. Kjo do të thotë, gjatë ndërrimit, ne gjithmonë kemi një rezervë prej 16 gigabajt të regjistrave të transaksioneve në të gjitha nyjet.
Dhe plus - është ende e rëndësishme për detyrat e mirëmbajtjes afatgjatë. Le të themi se duhet të përditësojmë një nga kopjet. Dhe ne duam ta fikim. Duhet të përditësojmë softuerin, ndoshta sistemin operativ, diçka tjetër. Dhe kur e fikim një kopje, slota për atë kopje hiqet gjithashtu. Dhe nëse përdorim një segment të vogël wal_keep_, atëherë me një mungesë të gjatë të një kopjeje, regjistrat e transaksioneve do të humbasin. Ne do të ngremë një kopje, ajo do të kërkojë ato regjistrat e transaksioneve ku është ndalur, por ato mund të mos jenë në master. Dhe kopja nuk do të jetë në gjendje të lidhet as. Prandaj, ne mbajmë një magazinë të madhe revistash.
Ne kemi një bazë prodhimi. Tashmë ka projekte në proces.
Kishte një skedar. Hymë brenda dhe shikuam - gjithçka është në rregull, kopjet janë në vend, nuk ka vonesë replikimi. Nuk ka gabime as në regjistra, gjithçka është në rregull.
Ekipi i produktit thotë se duhet të ketë disa të dhëna, por ne i shohim nga një burim, por nuk i shohim në bazën e të dhënave. Dhe ne duhet të kuptojmë se çfarë ndodhi me ta.
Është e qartë se pg_rewind i ka humbur ato. Ne e kuptuam menjëherë këtë, por shkuam për të parë se çfarë po ndodhte.
Në regjistrat, ne gjithmonë mund të gjejmë kur ka ndodhur skedari, kush u bë master, dhe ne mund të përcaktojmë se kush ishte masteri i vjetër dhe kur ai donte të bëhej një kopje, d.m.th. neve na duhen këto regjistra për të gjetur sasinë e regjistrave të transaksioneve që kishte humbur.
Mjeshtri ynë i vjetër është rindezur. Dhe Patroni ishte i regjistruar në autorun. Nisur Patroni. Më pas ai filloi Postgres. Më saktësisht, përpara se të niste Postgres dhe përpara se ta bënte një kopje, Patroni nisi procesin pg_rewind. Prandaj, ai fshiu një pjesë të regjistrave të transaksioneve, shkarkoi të reja dhe u lidh. Këtu Patroni punoi me zgjuarsi, pra siç pritej. Grupi është restauruar. Ne kishim 3 nyje, pas skedarit 3 nyje - gjithçka është e mirë.
Kemi humbur disa të dhëna. Dhe ne duhet të kuptojmë se sa shumë kemi humbur. Ne po kërkojmë vetëm momentin kur kishim një rikthim. Mund ta gjejmë në shënime të tilla në ditar. Rewind filloi, bëri diçka atje dhe mbaroi.
Ne duhet të gjejmë pozicionin në regjistrin e transaksioneve ku mbaroi masteri i vjetër. Në këtë rast, kjo është shenja. Dhe na duhet një shenjë e dytë, domethënë distanca me të cilën mjeshtri i vjetër ndryshon nga ai i ri.
Ne marrim pg_wal_lsn_diff të zakonshme dhe krahasojmë këto dy shenja. Dhe në këtë rast, marrim 17 megabajt. Shumë a pak, secili vendos vetë. Sepse për dikë 17 megabajt nuk janë shumë, për dikë janë shumë dhe të papranueshme. Këtu çdo individ përcakton për vete në përputhje me nevojat e biznesit.
Por çfarë kemi zbuluar vetë?
Së pari, duhet të vendosim vetë - a na duhet gjithmonë Patroni që të fillojë automatikisht pas një rindezjeje të sistemit? Ndodh shpesh që duhet të shkojmë te mjeshtri i vjetër, të shohim sa larg ka shkuar. Ndoshta inspektoni segmente të regjistrit të transaksioneve, shikoni se çfarë ka. Dhe për të kuptuar nëse mund t'i humbim këto të dhëna ose nëse duhet të ekzekutojmë masterin e vjetër në modalitetin e pavarur në mënyrë që t'i nxjerrim këto të dhëna.
Dhe vetëm pas kësaj ne duhet të vendosim nëse mund t'i heqim këto të dhëna ose mund t'i rivendosim ato, ta lidhim këtë nyje si një kopje me grupin tonë.
Përveç kësaj, ekziston një parametër "maksimum_lag_on_failover". Si parazgjedhje, nëse memoria ime më shërben, ky parametër ka një vlerë prej 1 megabajt.
Si punon ai? Nëse kopja jonë është prapa me 1 megabajt të dhënash në vonesën e replikimit, atëherë kjo kopje nuk merr pjesë në zgjedhje. Dhe nëse befas ka një skedar, Patroni shikon se cilat kopje kanë mbetur prapa. Nëse ata janë prapa nga një numër i madh regjistrash transaksionesh, ata nuk mund të bëhen mjeshtër. Ky është një veçori shumë e mirë e sigurisë që ju pengon të humbni shumë të dhëna.
Por ka një problem në atë që vonesa e replikimit në grupin Patroni dhe DCS përditësohet në një interval të caktuar. Unë mendoj se 30 sekonda është vlera e paracaktuar ttl.
Prandaj, mund të ketë një situatë ku ka një vonesë të përsëritjes për kopjet në DCS, por në fakt mund të ketë një vonesë krejtësisht të ndryshme ose mund të mos ketë fare vonesë, domethënë kjo gjë nuk është në kohë reale. Dhe jo gjithmonë pasqyron pamjen reale. Dhe nuk ia vlen të bësh logjikë të zbukuruar me të.
Dhe rreziku i humbjes mbetet gjithmonë. Dhe në rastin më të keq, një formulë, dhe në rastin mesatar, një formulë tjetër. Kjo do të thotë, kur planifikojmë zbatimin e Patroni dhe vlerësojmë se sa të dhëna mund të humbasim, duhet të mbështetemi në këto formula dhe afërsisht të imagjinojmë se sa të dhëna mund të humbasim.
Dhe ka një lajm të mirë. Kur mjeshtri i vjetër ka shkuar përpara, ai mund të shkojë përpara për shkak të disa proceseve të sfondit. Kjo do të thotë, kishte një lloj autovakuumi, ai shkroi të dhënat, i ruajti në regjistrin e transaksioneve. Dhe ne lehtë mund t'i injorojmë dhe t'i humbim këto të dhëna. Nuk ka asnjë problem në këtë.
Dhe kështu duken regjistrat nëse vendoset maximum_lag_on_failover dhe ka ndodhur një skedar, dhe ju duhet të zgjidhni një master të ri. Replika e vlerëson veten si të paaftë për të marrë pjesë në zgjedhje. Dhe ajo refuzon të marrë pjesë në garën për lider. Dhe ajo pret që të zgjidhet një mjeshtër i ri, në mënyrë që më pas të mund të lidhet me të. Kjo është një masë shtesë kundër humbjes së të dhënave.
Këtu kemi një ekip produkti që shkruan se produkti i tyre ka probleme me Postgres. Në të njëjtën kohë, vetë masteri nuk mund të aksesohet, sepse nuk është i disponueshëm përmes SSH. Dhe skedari automatik nuk ndodh as.
Ky host u detyrua të rindizet. Për shkak të rindezjes, ndodhi një skedar automatik, megjithëse ishte e mundur të bëhej një skedar automatik manual, siç e kuptoj tani. Dhe pas rindezjes, ne tashmë do të shohim se çfarë kishim me masterin aktual.
Në të njëjtën kohë, ne e dinim paraprakisht se kishim probleme me disqet, domethënë, e dinim tashmë nga monitorimi se ku të gërmonim dhe çfarë të kërkonim.
Hymë në regjistrin e postgresit, filluam të shohim se çfarë po ndodhte atje. Ne pamë kryerje që zgjasin atje për një, dy, tre sekonda, gjë që nuk është aspak normale. Ne pamë që autovakuumi ynë fillon shumë ngadalë dhe çuditërisht. Dhe ne pamë skedarë të përkohshëm në disk. Kjo do të thotë, të gjithë këta janë tregues të problemeve me disqet.
Ne shikuam sistemin dmesg (regjistri i kernelit). Dhe pamë që kemi probleme me një nga disqet. Nënsistemi i diskut ishte softuer Raid. Ne shikuam /proc/mdstat dhe pamë që na mungonte një makinë. Domethënë ka një Raid prej 8 disqesh, një na mungon. Nëse shikoni me kujdes rrëshqitjen, atëherë në dalje mund të shihni se ne nuk kemi sde atje. Tek ne, me kusht, disku ka rënë. Kjo shkaktoi probleme me diskun dhe aplikacionet gjithashtu përjetuan probleme kur punonin me grupin Postgres.
Dhe në këtë rast Patroni nuk do të na ndihmonte në asnjë mënyrë, sepse Patroni nuk ka për detyrë të monitorojë gjendjen e serverit, gjendjen e diskut. Dhe ne duhet të monitorojmë situata të tilla me monitorim të jashtëm. Ne shtuam shpejt monitorimin e diskut në monitorimin e jashtëm.
Dhe ekzistonte një mendim i tillë - a mund të na ndihmonte softueri i gardhit ose i qenve mbikëqyrës? Ne menduam se ai vështirë se do të na kishte ndihmuar në këtë rast, sepse gjatë problemeve Patroni vazhdonte të ndërvepronte me grupin DCS dhe nuk shihte asnjë problem. Kjo do të thotë, nga këndvështrimi i DCS dhe Patroni, gjithçka ishte në rregull me grupin, megjithëse në fakt kishte probleme me diskun, kishte probleme me disponueshmërinë e bazës së të dhënave.
Sipas mendimit tim, ky është një nga problemet më të çuditshme që kam hulumtuar për një kohë shumë të gjatë, kam lexuar shumë regjistra, kam zgjedhur përsëri dhe e kam quajtur simulator grupi.
Problemi ishte se mjeshtri i vjetër nuk mund të bëhej replikë normale, d.m.th Patroni e nisi, Patroni tregoi se kjo nyje ishte e pranishme si replikë, por në të njëjtën kohë nuk ishte një replikë normale. Tani do të shihni pse. Kjo është ajo që kam mbajtur nga analiza e atij problemi.
Dhe si filloi gjithçka? Filloi, si në problemin e mëparshëm, me frenat e diskut. Ne kishim angazhime për një sekondë, dy.
Kishte ndërprerje në lidhje, d.m.th., klientët ishin grisur.
Kishte bllokime me ashpërsi të ndryshme.
Dhe, në përputhje me rrethanat, nënsistemi i diskut nuk është shumë i përgjegjshëm.
Dhe gjëja më misterioze për mua është kërkesa e menjëhershme e mbylljes që mbërriti. Postgres ka tre mënyra mbylljeje:
- Është e këndshme kur presim që të gjithë klientët të shkëputen vetë.
- Është e shpejtë kur i detyrojmë klientët të shkëputen sepse do të mbyllemi.
- Dhe e menjëhershme. Në këtë rast, imediate as që u thotë klientëve të mbyllen, thjesht mbyllet pa paralajmërim. Dhe për të gjithë klientët, sistemi operativ tashmë dërgon një mesazh RST (një mesazh TCP që lidhja është ndërprerë dhe klienti nuk ka asgjë më shumë për të kapur).
Kush e dërgoi këtë sinjal? Proceset e sfondit Postgres nuk i dërgojnë sinjale të tilla njëri-tjetrit, d.m.th., ky është kill-9. Nuk i dërgojnë gjëra të tilla njëri-tjetrit, vetëm reagojnë ndaj gjërave të tilla, pra ky është një rifillim urgjent i Postgres. Kush e ka dërguar, nuk e di.
Shikova komandën "e fundit" dhe pashë një person i cili gjithashtu hyri në këtë server me ne, por isha shumë i turpshëm për të bërë një pyetje. Ndoshta ishte vrasja -9. Unë do të shihja kill -9 në shkrimet, sepse Postgres thotë se u desh kill -9, por unë nuk e pashë atë në regjistrat.
Duke parë më tej, pashë që Patroni nuk shkroi në regjistër për një kohë të gjatë - 54 sekonda. Dhe nëse krahasojmë dy vula kohore, nuk ka pasur mesazhe për rreth 54 sekonda.
Dhe gjatë kësaj kohe kishte një skedar automatik. Patroni bëri një punë të madhe këtu përsëri. Mjeshtri ynë i vjetër nuk ishte i disponueshëm, diçka i ndodhi. Dhe filloi zgjedhja e një mjeshtri të ri. Gjithçka funksionoi mirë këtu. Pgsql01 ynë është bërë lideri i ri.
Kemi një kopje që është bërë mjeshtër. Dhe ka një përgjigje të dytë. Dhe kishte probleme me kopjen e dytë. Ajo u përpoq të rikonfigurohej. Siç e kuptoj unë, ajo u përpoq të ndryshonte recovery.conf, të riniste Postgres dhe të lidhej me masterin e ri. Ajo shkruan mesazhe çdo 10 sekonda se po përpiqet, por nuk ia del.
Dhe gjatë këtyre përpjekjeve, një sinjal i menjëhershëm mbylljeje arrin te mjeshtri i vjetër. Masteri është rifilluar. Dhe gjithashtu rikuperimi ndalon sepse masteri i vjetër shkon në rindezje. Kjo do të thotë, kopja nuk mund të lidhet me të, sepse është në modalitetin e mbylljes.
Në një moment, funksionoi, por përsëritja nuk filloi.
Supozimi im i vetëm është se kishte një adresë të vjetër master në shërim.conf. Dhe kur u shfaq një mjeshtër i ri, kopja e dytë ende u përpoq të lidhej me mjeshtrin e vjetër.
Kur Patroni filloi në kopjen e dytë, nyja filloi por nuk mund të përsëritej. Dhe u formua një vonesë e përsëritjes, e cila dukej diçka si kjo. Kjo do të thotë, të tre nyjet ishin në vend, por nyja e dytë mbeti prapa.
Në të njëjtën kohë, nëse shikoni regjistrat që ishin shkruar, mund të shihni se replikimi nuk mund të fillonte sepse regjistrat e transaksioneve ishin të ndryshëm. Dhe ato regjistra transaksionesh që ofron masteri, të cilat janë të specifikuara në recovery.conf, thjesht nuk përshtaten me nyjen tonë aktuale.
Dhe këtu bëra një gabim. Më duhej të vija dhe të shikoja se çfarë ishte në rikuperim.conf për të testuar hipotezën time se po lidheshim me mjeshtrin e gabuar. Por atëherë po merresha vetëm me këtë dhe nuk më ndodhte, ose pashë që kopja ngeli prapa dhe do të duhej të rimbushej, domethënë, disi punova pa kujdes. Ky ishte nyja ime.
Pas 30 minutash, tashmë erdhi administratori, d.m.th e rifillova Patroni në replikë. Tashmë i dhashë fund, mendova se do të duhej të rimbushej. Dhe mendova - do të rifilloj Patroni, mbase do të dalë diçka e mirë. Rimëkëmbja filloi. Dhe baza madje u hap, ishte gati të pranonte lidhje.
Replikimi ka filluar. Por një minutë më vonë, ajo ra me një gabim që regjistrat e transaksioneve nuk janë të përshtatshme për të.
Mendova se do të rifilloja përsëri. Rifillova përsëri Patroni dhe nuk e rifillova Postgresin, por rifillova Patroni me shpresën se do të niste në mënyrë magjike bazën e të dhënave.
Replikimi filloi përsëri, por shenjat në regjistrin e transaksioneve ishin të ndryshme, ato nuk ishin të njëjta me përpjekjen e mëparshme të fillimit. Replikimi u ndal përsëri. Dhe mesazhi ishte tashmë pak më ndryshe. Dhe nuk ishte shumë informuese për mua.
Dhe pastaj më shkon mendja - po sikur të rinis Postgres, në këtë kohë bëj një pikë kontrolli në master aktual për të lëvizur pikën në regjistrin e transaksioneve pak përpara, në mënyrë që rikuperimi të fillojë nga një moment tjetër? Plus, ne kishim ende stoqe të WAL.
Rifillova Patroni, bëra nja dy pika kontrolli te masteri, nja dy pika rinisje te replika kur u hap. Dhe ndihmoi. Mendova për një kohë të gjatë pse ndihmoi dhe si funksionoi. Dhe kopja filloi. Dhe përsëritja nuk u shqye më.
Një problem i tillë për mua është një nga më misteriozët, mbi të cilin ende në mëdyshje se çfarë ka ndodhur realisht atje.
Cilat janë implikimet këtu? Patroni mund të punojë sipas qëllimit dhe pa asnjë gabim. Por në të njëjtën kohë, kjo nuk është një garanci 100% se gjithçka është në rregull me ne. Replika mund të fillojë, por mund të jetë në gjendje gjysmë pune dhe aplikacioni nuk mund të funksionojë me një kopje të tillë, sepse do të ketë të dhëna të vjetra.
Dhe pas skedarit, gjithmonë duhet të kontrolloni që gjithçka është në rregull me grupin, domethënë ka numrin e kërkuar të kopjeve, nuk ka vonesë të përsëritjes.
Dhe ndërsa kalojmë nëpër këto çështje, unë do të jap rekomandime. Unë u përpoqa t'i kombinoja në dy sllajde. Ndoshta, të gjitha historitë mund të kombinohen në dy sllajde dhe vetëm të tregohen.
Kur përdorni Patroni, duhet të keni monitorim. Gjithmonë duhet ta dini kur ka ndodhur një skedar automatik, sepse nëse nuk e dini se keni pasur një skedar automatik, nuk keni kontroll mbi grupin. Dhe kjo është e keqe.
Pas çdo skedari, ne gjithmonë duhet të kontrollojmë manualisht grupin. Duhet të sigurohemi që të kemi gjithmonë një numër të përditësuar të kopjeve, të mos ketë vonesa në replikim, të mos ketë gabime në regjistrat që lidhen me riprodhimin e transmetimit, me Patroni, me sistemin DCS.
Automatizimi mund të funksionojë me sukses, Patroni është një mjet shumë i mirë. Mund të funksionojë, por kjo nuk do ta sjellë grupin në gjendjen e dëshiruar. Dhe nëse nuk e zbulojmë këtë, do të jemi në telashe.
Dhe Patroni nuk është një plumb argjendi. Ne ende duhet të kuptojmë se si funksionon Postgres, si funksionon replikimi dhe si punon Patroni me Postgres dhe si sigurohet komunikimi midis nyjeve. Kjo është e nevojshme për të qenë në gjendje të rregulloni problemet me duart tuaja.
Si t'i qasem çështjes së diagnozës? Kështu ndodhi që ne punojmë me klientë të ndryshëm dhe askush nuk ka një stack ELK, dhe ne duhet të zgjidhim regjistrat duke hapur 6 konzola dhe 2 skeda. Në njërën skedë, këto janë regjistrat Patroni për secilën nyje, në skedën tjetër, këto janë regjistrat e Konsullit, ose Postgres nëse është e nevojshme. Është shumë e vështirë për të diagnostikuar këtë.
Çfarë qasjesh kam marrë? Së pari, gjithmonë shikoj kur ka mbërritur skedari. Dhe për mua ky është një pellg ujëmbledhës. Unë shikoj se çfarë ndodhi para skedarit, gjatë skedarit dhe pas skedarit. Mbështetja e skedarit ka dy shenja: kjo është koha e fillimit dhe e përfundimit.
Më pas, kërkoj në regjistrat për ngjarjet para skedarit, të cilat i paraprinë skedarit, d.m.th. kërkoj arsyet pse ndodhi skedari.
Dhe kjo jep një pamje të të kuptuarit se çfarë ka ndodhur dhe çfarë mund të bëhet në të ardhmen në mënyrë që rrethana të tilla të mos ndodhin (dhe si rezultat, nuk ka skedarë).
Dhe ku shikojmë zakonisht? Une shikoj:
- Së pari, te shkrimet e Patroni.
- Më pas, unë shikoj regjistrat e Postgres, ose regjistrat e DCS, në varësi të asaj që u gjet në regjistrat e Patroni.
- Dhe regjistrat e sistemit gjithashtu ndonjëherë japin një kuptim të asaj që e ka shkaktuar skedarin.
Si ndihem për Patronin? Me Patronin kam një marrëdhënie shumë të mirë. Sipas mendimit tim, kjo është më e mira që ekziston sot. Unë njoh shumë produkte të tjera. Këto janë Stolon, Repmgr, Pg_auto_failover, PAF. 4 mjete. I provova të gjitha. Patroni është i preferuari im.
Nëse më pyesin: “A e rekomandoj Patronin?”. Unë do të them po, sepse më pëlqen Patroni. Dhe mendoj se kam mësuar si ta gatuaj.
Nëse jeni të interesuar të shihni se çfarë problemesh të tjera ka me Patroni përveç problemeve që kam përmendur, gjithmonë mund të shikoni faqen në GitHub. Ka shumë histori të ndryshme dhe shumë çështje interesante diskutohen atje. Dhe si rezultat, disa gabime u prezantuan dhe u zgjidhën, domethënë, ky është një lexim interesant.
Ka disa histori interesante rreth njerëzve që qëllojnë veten në këmbë. Shumë informues. Ju lexoni dhe kuptoni se nuk është e nevojshme ta bëni këtë. E shënova veten.
Dhe unë do të doja të them një falenderim të madh për Zalando për zhvillimin e këtij projekti, përkatësisht për Alexander Kukushkin dhe Alexey Klyukin. Aleksey Klyukin është një nga bashkautorët, ai nuk punon më në Zalando, por këta janë dy persona që kanë filluar të punojnë me këtë produkt.
Dhe unë mendoj se Patroni është një gjë shumë e lezetshme. Jam e lumtur që ajo ekziston, është interesante me të. Dhe një falenderim i madh për të gjithë kontribuesit që shkruajnë arna për Patroni. Shpresoj që Patroni të bëhet më i pjekur, më i ftohtë dhe më efikas me kalimin e moshës. Tashmë është funksional, por shpresoj se do të bëhet edhe më mirë. Prandaj, nëse planifikoni të përdorni Patroni, atëherë mos kini frikë. Kjo është një zgjidhje e mirë, mund të zbatohet dhe përdoret.
Kjo eshte e gjitha. Nëse keni pyetje, pyesni.
Pyetjet tuaja
Faleminderit për raportin! Nëse pas një skedari ju ende duhet të shikoni atje me shumë kujdes, atëherë pse na duhet një skedar automatik?
Sepse janë gjëra të reja. Ne kemi qenë me të vetëm për një vit. Më mirë të jesh i sigurt. Ne duam të hyjmë dhe të shohim se gjithçka ka funksionuar vërtet ashtu siç duhet. Ky është niveli i mosbesimit të të rriturve - është më mirë të kontrolloni dy herë dhe të shihni.
Për shembull, shkuam në mëngjes dhe shikuam, apo jo?
Jo në mëngjes, zakonisht mësojmë për skedarin automatik pothuajse menjëherë. Ne marrim njoftime, shohim që ka ndodhur një skedar automatik. Pothuajse menjëherë shkojmë dhe shikojmë. Por të gjitha këto kontrolle duhet të sillen në nivel monitorimi. Nëse aksesoni Patroni nëpërmjet API-së REST, ka një histori. Sipas historisë ju mund të shihni vulat kohore kur ka ndodhur skedari. Bazuar në këtë, mund të bëhet monitorimi. Ju mund të shihni historinë, sa ngjarje ishin atje. Nëse kemi më shumë ngjarje, atëherë ka ndodhur një skedar automatik. Mund të shkoni dhe të shihni. Ose automatizimi ynë në monitorim kontrolloi që ne i kemi të gjitha kopjet në vend, nuk ka vonesë dhe gjithçka është në rregull.
Ju faleminderit!
Faleminderit shumë për historinë e mrekullueshme! Nëse e zhvendosëm grupin DCS diku larg grupit Postgres, atëherë edhe ky grup duhet të shërbehet periodikisht? Cilat janë praktikat më të mira që disa pjesë të grupit DCS duhet të çaktivizohen, diçka që ka të bëjë me to, etj.? Si mbijeton e gjithë kjo strukturë? Dhe si i bëni këto gjëra?
Për një kompani, ishte e nevojshme të bëhej një matricë e problemeve, çfarë ndodh nëse një nga komponentët ose disa komponentë dështojnë. Sipas kësaj matrice, ne kalojmë në mënyrë sekuenciale të gjithë komponentët dhe ndërtojmë skenarë në rast të dështimit të këtyre komponentëve. Prandaj, për çdo skenar dështimi, mund të keni një plan veprimi për rikuperim. Dhe në rastin e DCS, ajo vjen si pjesë e infrastrukturës standarde. Dhe administratori e administron atë, dhe ne tashmë mbështetemi te administratorët që e administrojnë atë dhe aftësinë e tyre për ta rregulluar atë në rast aksidentesh. Nëse nuk ka fare DCS, atëherë ne e vendosim atë, por në të njëjtën kohë nuk e monitorojmë veçanërisht, sepse nuk jemi përgjegjës për infrastrukturën, por japim rekomandime se si dhe çfarë të monitorojmë.
Dmth, a e kuptova saktë se duhet të çaktivizoj Patroni, çaktivizoj skedarin, çaktivizoj gjithçka përpara se të bëj ndonjë gjë me hostet?
Varet nga sa nyje kemi në grupin DCS. Nëse ka shumë nyje dhe nëse çaktivizojmë vetëm njërën prej nyjeve (kopjen), atëherë grupi mban një kuorum. Dhe Patroni mbetet funksional. Dhe asgjë nuk nxitet. Nëse kemi disa operacione komplekse që prekin më shumë nyje, mungesa e të cilave mund të prishë kuorumin, atëherë - po, mund të ketë kuptim ta vendosim Patroni në pauzë. Ka një komandë përkatëse - pauzë patronictl, rinisë patronictl. Ne thjesht ndalojmë dhe skedari automatik nuk funksionon në atë kohë. Ne bëjmë mirëmbajtje në grupimin DCS, më pas heqim pauzën dhe vazhdojmë të jetojmë.
Ju faleminderit shumë!
Faleminderit shumë për raportin tuaj! Si ndihet ekipi i produktit për humbjen e të dhënave?
Ekipet e produkteve nuk u interesojnë, dhe drejtuesit e ekipit janë të shqetësuar.
Çfarë garancish ka?
Garancitë janë shumë të vështira. Alexander Kukushkin ka një raport "Si të llogarisim RPO dhe RTO", d.m.th. koha e rikuperimit dhe sa të dhëna mund të humbasim. Mendoj se duhet t'i gjejmë këto sllajde dhe t'i studiojmë ato. Me sa mbaj mend, ka hapa të veçantë se si të llogariten këto gjëra. Sa transaksione mund të humbasim, sa të dhëna mund të humbasim. Si opsion, ne mund të përdorim përsëritjen sinkron në nivelin Patroni, por kjo është një thikë me dy tehe: ne ose kemi besueshmëri të të dhënave, ose humbasim shpejtësinë. Ka përsëritje sinkron, por gjithashtu nuk garanton mbrojtje 100% kundër humbjes së të dhënave.
Alexey, faleminderit për raportin e mrekullueshëm! Ndonjë përvojë me përdorimin e Patroni për mbrojtje të nivelit zero? Kjo është, në lidhje me gatishmërinë sinkrone? Kjo është pyetja e parë. Dhe pyetja e dytë. Ju keni përdorur zgjidhje të ndryshme. Ne përdorëm Repmgr, por pa autofiler, dhe tani po planifikojmë të përfshijmë skedarin automatik. Dhe Patroni e konsiderojmë si një zgjidhje alternative. Çfarë mund të thoni si avantazhe në krahasim me Repmgr?
Pyetja e parë ishte në lidhje me kopjet sinkrone. Askush nuk përdor përsëritje sinkron këtu, sepse të gjithë janë të frikësuar (disa klientë tashmë e përdorin atë, në parim, ata nuk vunë re probleme të performancës - Shënim i folësit). Por ne kemi zhvilluar një rregull për veten tonë që duhet të ketë të paktën tre nyje në një grup replikues sinkron, sepse nëse kemi dy nyje dhe nëse masteri ose kopja dështon, atëherë Patroni e kalon këtë nyje në modalitetin e pavarur në mënyrë që aplikacioni të vazhdojë të puna. Në këtë rast, ekziston rreziku i humbjes së të dhënave.
Për sa i përket pyetjes së dytë, ne kemi përdorur Repmgr dhe ende e bëjmë me disa klientë për arsye historike. Çfarë mund të thuhet? Patroni vjen me një skedar automatik jashtë kutisë, Repmgr vjen me skedarin automatik si një veçori shtesë që duhet të aktivizohet. Ne duhet të ekzekutojmë demonin Repmgr në secilën nyje dhe më pas mund të konfigurojmë autofilerin.
Repmgr kontrollon nëse nyjet Postgres janë të gjalla. Proceset Repmgr kontrollojnë ekzistencën e njëri-tjetrit, kjo nuk është një qasje shumë efikase. mund të ketë raste komplekse të izolimit të rrjetit në të cilat një grup i madh Repmgr mund të ndahet në disa më të vegjël dhe të vazhdojë të punojë. Unë nuk e kam ndjekur Repmgr për një kohë të gjatë, ndoshta është rregulluar ... ose ndoshta jo. Por heqja e informacionit për gjendjen e grupit në DCS, siç bën Stolon, Patroni, është opsioni më i zbatueshëm.
Alexey, kam një pyetje, ndoshta një pyetje më të dobët. Në një nga shembujt e parë, ju zhvendosët DCS nga makina lokale në një host të largët. Ne e kuptojmë që rrjeti është një gjë që ka karakteristikat e veta, jeton më vete. Dhe çfarë ndodh nëse për ndonjë arsye grupi DCS bëhet i padisponueshëm? Nuk do t'i them arsyet, mund të ketë shumë prej tyre: nga duart e shtrembër të rrjeteve deri te problemet reale.
Nuk e thashë me zë të lartë, por grupi DCS duhet të jetë gjithashtu failover, pra është një numër tek nyjet, në mënyrë që të plotësohet një kuorum. Çfarë ndodh nëse grupi DCS bëhet i padisponueshëm, ose një kuorum nuk mund të plotësohet, d.m.th. një lloj ndarje e rrjetit ose dështim i nyjeve? Në këtë rast, grupi Patroni kalon në modalitetin vetëm për lexim. Grupi Patroni nuk mund të përcaktojë gjendjen e grupit dhe çfarë të bëjë. Ai nuk mund të kontaktojë DCS dhe të ruajë gjendjen e re të grupimit atje, kështu që i gjithë grupi shkon vetëm në lexim. Dhe pret ose për ndërhyrje manuale nga operatori ose që DCS të rikuperohet.
Përafërsisht, DCS bëhet një shërbim për ne po aq i rëndësishëm sa vetë baza?
Po Po. Në kaq shumë kompani moderne, Service Discovery është një pjesë integrale e infrastrukturës. Është duke u zbatuar edhe para se të kishte një bazë të dhënash në infrastrukturë. Relativisht, infrastruktura u lançua, u vendos në DC dhe ne kemi menjëherë Service Discovery. Nëse është Konsull, atëherë DNS mund të ndërtohet mbi të. Nëse kjo është Etcd, atëherë mund të ketë një pjesë nga grupi Kubernetes, në të cilin do të vendoset gjithçka tjetër. Më duket se Service Discovery është tashmë një pjesë integrale e infrastrukturave moderne. Dhe ata mendojnë për këtë shumë më herët sesa për bazat e të dhënave.
Ju faleminderit!
Burimi: www.habr.com