Paraqitje

Disa kohë më parë m'u dha detyra e zhvillimit të një grupi failover për PostgreSQL, që operojnë në disa qendra të dhënash të lidhura me fibër optike brenda një qyteti dhe të aftë për të përballuar një dështim (për shembull, ndërprerje) të një qendre të dhënash. Si softuer që është përgjegjës për tolerancën e gabimeve, unë zgjodha stimulues kardiaksepse kjo është zgjidhja zyrtare nga RedHat për krijimin e grupeve të dështimit. Është mirë sepse RedHat ofron mbështetje për të dhe sepse kjo zgjidhje është universale (modulare). Me ndihmën e tij, do të jetë e mundur të sigurohet toleranca e gabimeve jo vetëm e PostgreSQL, por edhe e shërbimeve të tjera, duke përdorur module standarde ose duke i krijuar ato për nevoja specifike.

Ky vendim ngriti një pyetje të arsyeshme: sa tolerant ndaj gabimeve do të jetë një grup i dështimit? Për të hetuar këtë, kam zhvilluar një stol testimi që simulon dështime të ndryshme në nyjet e grupit, pret që shërbimi të restaurohet, rikuperon nyjen e dështuar dhe vazhdon testimin në një lak. Ky projekt fillimisht quhej hapgsql, por me kalimin e kohës u mërzita me emrin, i cili kishte vetëm një zanore. Prandaj, fillova të thërras bazat e të dhënave tolerante ndaj gabimeve (dhe float IP duke treguar ato) krogan (një personazh nga një lojë kompjuterike në të cilën të gjitha organet e rëndësishme janë dyfishuar), dhe nyjet, grupimet dhe vetë projekti janë tuchanka (planeti ku jetojnë kroganët).

Tani menaxhmenti e ka lejuar hapni projektin për komunitetin me burim të hapur nën licencën MIT. README së shpejti do të përkthehet në anglisht (sepse pritet që konsumatorët kryesorë të jenë zhvilluesit e Pacemaker dhe PostgreSQL), dhe vendosa të prezantoj versionin e vjetër rus të README (pjesërisht) në formën e këtij artikulli.

Grupet vendosen në makinat virtuale VirtualBox. Do të vendosen gjithsej 12 makina virtuale (36 GiB në total), të cilat formojnë 4 grupime tolerante ndaj gabimeve (opsione të ndryshme). Dy grupet e para përbëhen nga dy serverë PostgreSQL, të cilët ndodhen në qendra të ndryshme të të dhënave, dhe një server të përbashkët dëshmitar c pajisje kuorumi (i pritur në një makinë virtuale të lirë në një qendër të tretë të të dhënave), e cila zgjidh pasigurinë 50% / 50%, duke i dhënë votën tuaj njërës prej palëve. Grupi i tretë në tre qendra të dhënash: një master, dy skllevër, nr pajisje kuorumi. Grupi i katërt përbëhet nga katër serverë PostgreSQL, dy për qendër të dhënash: një master, pjesa tjetër kopje, dhe gjithashtu përdor dëshmitar c pajisje kuorumi. E katërta mund të përballojë dështimin e dy serverëve ose një qendre të dhënash. Kjo zgjidhje mund të shkallëzohet në një numër më të madh kopjesh nëse është e nevojshme.

Shërbim i saktë në kohë ntpd gjithashtu është rikonfiguruar për tolerancën e gabimeve, por përdor vetë metodën ntpd (mode jetim). Server i përbashkët dëshmitar vepron si një server qendror NTP, duke shpërndarë kohën e tij në të gjitha grupimet, duke sinkronizuar kështu të gjithë serverët me njëri-tjetrin. Nëse dëshmitar dështon ose bëhet i izoluar, atëherë njëri nga serverët e grupimit (brenda grupit) do të fillojë të shpërndajë kohën e tij. Caching ndihmës Përfaqësuesi HTTP ngritur gjithashtu në dëshmitar, me ndihmën e tij, makina të tjera virtuale kanë akses në depot e Yum. Në realitet, shërbime të tilla si koha e saktë dhe proxies ka shumë të ngjarë të strehohen në serverë të dedikuar, por në kabinën në të cilën ato janë pritur dëshmitar vetëm për të kursyer numrin e makinave virtuale dhe hapësirën.

Versione

v0. Punon me CentOS 7 dhe PostgreSQL 11 në VirtualBox 6.1.

Struktura e grupimit

Të gjitha grupet janë krijuar për t'u vendosur në qendra të shumta të dhënash, të kombinuara në një rrjet të sheshtë dhe duhet të përballojnë dështimin ose izolimin e rrjetit të një qendre të vetme të dhënash. Kjo është arsyeja pse është e pamundur Përdorni për mbrojtje kundër truri i ndarë teknologji standarde Pecemaker quajtur STONITH (Gjuani nyjen tjetër në kokë) ose skermë. Thelbi i tij: nëse nyjet në grup fillojnë të dyshojnë se diçka nuk shkon me ndonjë nyje, ajo nuk po përgjigjet ose po sillet gabimisht, atëherë ata e fikin me forcë përmes pajisjeve "të jashtme", për shembull, një kartë kontrolli IPMI ose UPS . Por kjo do të funksionojë vetëm në rastet kur, në rast të një dështimi të vetëm, serveri IPMI ose UPS vazhdon të funksionojë. Këtu ne planifikojmë të mbrohemi nga një dështim shumë më katastrofik, kur e gjithë qendra e të dhënave dështon (për shembull, humbet energjinë). Dhe me një refuzim të tillë, gjithçka stonith-pajisjet (IPMI, UPS, etj.) gjithashtu nuk do të funksionojnë.

Në vend të kësaj, sistemi bazohet në idenë e kuorumit. Të gjitha nyjet kanë një zë, dhe vetëm ato që mund të shohin më shumë se gjysmën e të gjitha nyjeve mund të funksionojnë. Kjo sasi "gjysmë + 1" quhet kuorumi. Nëse nuk arrihet kuorumi, atëherë nyja vendos që është në izolim rrjeti dhe duhet të fikë burimet e saj, d.m.th. kjo është ajo që është mbrojtja e trurit të ndarë. Nëse softueri që është përgjegjës për këtë sjellje nuk funksionon, atëherë një roje, për shembull, bazuar në IPMI, do të duhet të punojë.

Nëse numri i nyjeve është çift (një grup në dy qendra të dhënash), atëherë mund të lindë e ashtuquajtura pasiguri 50% / 50% (Pesëdhjetë pesëdhjetë) kur izolimi i rrjetit e ndan grupin saktësisht në gjysmë. Prandaj, për një numër çift nyjesh, ne shtojmë pajisje kuorumi është një demon jokërkues që mund të lëshohet në makinën virtuale më të lirë në një qendër të tretë të të dhënave. Ai i jep votën e tij njërit prej segmenteve (që ai e sheh), dhe në këtë mënyrë zgjidh pasigurinë 50%/50%. Unë emërova serverin në të cilin do të hapet pajisja e kuorumit dëshmitar (terminologji nga repmgr, më pëlqeu).

Burimet mund të zhvendosen nga një vend në tjetrin, për shembull, nga serverët e dëmtuar te ata të shëndetshëm, ose me komandën e administratorëve të sistemit. Kështu që klientët të dinë se ku ndodhen burimet që u nevojiten (ku të lidhen?), IP lundrues (float IP). Këto janë IP-të që Pecemaker mund të lëvizë nëpër nyje (gjithçka është në një rrjet të sheshtë). Secila prej tyre simbolizon një burim (shërbim) dhe do të vendoset aty ku duhet të lidheni për të fituar akses në këtë shërbim (në rastin tonë, një bazë të dhënash).

Tuchanka1 (qark me ngjeshje)

Strukturë

Ideja ishte që ne kemi shumë baza të dhënash të vogla me ngarkesë të ulët, për të cilat është e padobishme mbajtja e një serveri të dedikuar skllav në modalitetin e gatishmërisë së nxehtë për transaksione vetëm për lexim (nuk ka nevojë për një humbje të tillë burimesh).

Çdo qendër e të dhënave ka një server. Secili server ka dy instanca PostgreSQL (në terminologjinë PostgreSQL quhen grupe, por për të shmangur konfuzionin do t'i quaj instanca (në analogji me bazat e tjera të të dhënave), dhe do t'i quaj vetëm grupe grupimesh të stimulimit të stimulimit. Një shembull funksionon në modalitetin master dhe vetëm ai ofron shërbime (vetëm IP float të çon në të). Shkalla e dytë punon si skllav për qendrën e dytë të të dhënave dhe do të ofrojë shërbime vetëm nëse masteri i saj dështon. Meqenëse në shumicën e rasteve vetëm një shembull nga dy (master) do të ofrojë shërbime (kryer kërkesat), të gjitha burimet e serverit janë optimizuar për master (memoria ndahet për cache shared_buffers, etj.), por në mënyrë që instanca e dytë gjithashtu ka burime të mjaftueshme (megjithëse për funksionim jooptimal përmes cache të sistemit të skedarëve) në rast të dështimit të njërës prej qendrave të të dhënave. Skllavi nuk ofron shërbime (nuk kryen kërkesa vetëm për lexim) gjatë funksionimit normal të grupit, në mënyrë që të mos ketë luftë për burime me masterin në të njëjtën makinë.

Në rastin e dy nyjeve, toleranca e gabimeve është e mundur vetëm me replikimin asinkron, pasi me replikimin sinkron, dështimi i një slave do të çojë në ndalimin e masterit.

Dështimi për të dëshmuar

Dështimi për të dëshmuar (pajisje kuorumi) Unë do të konsideroj vetëm për grupin Tuchanka1, me gjithë të tjerët do të jetë e njëjta histori. Nëse dëshmitari dështon, asgjë nuk do të ndryshojë në strukturën e grupit, gjithçka do të vazhdojë të funksionojë në të njëjtën mënyrë që ka bërë. Por kuorumi do të bëhet 2 nga 3, dhe për këtë arsye çdo dështim i mëvonshëm do të jetë fatal për grupin. Do të duhet ende të rregullohet urgjentisht.

Tuchanka1 refuzim

Dështimi i njërës prej qendrave të të dhënave për Tuchanka1. Në këtë rast dëshmitar ia hedh votën një nyje të dytë në një qendër të dytë të dhënash. Atje, ish-skllavi shndërrohet në një master, si rezultat, të dy zotërit punojnë në të njëjtin server dhe të dy IP-të e tyre float tregojnë drejt tyre.

Tuchanka2 (klasike)

Strukturë

Skema klasike e dy nyjeve. I zoti punon në njërën, skllavi në të dytën. Të dy mund të ekzekutojnë kërkesa (skllavi lexohet vetëm), kështu që të dyja drejtohen me IP-në float: krogan2 është master, krogan2s1 është slave. Si zotëria ashtu edhe skllavi do të kenë tolerancë ndaj gabimeve.

Në rastin e dy nyjeve, toleranca ndaj gabimeve është e mundur vetëm me replikimin asinkron, sepse me replikimin sinkron, dështimi i slave do të çojë në ndalimin e masterit.

Tuchanka2 refuzim

Nëse një nga qendrat e të dhënave dështon dëshmitar voton për të dytin. Në të vetmen qendër të të dhënave që funksionon, masteri do të ngrihet dhe të dy IP-të float do të tregojnë drejt tij: masteri dhe slave. Natyrisht, instanca duhet të konfigurohet në atë mënyrë që të ketë burime të mjaftueshme (kufijtë e lidhjes, etj.) për të pranuar njëkohësisht të gjitha lidhjet dhe kërkesat nga IP-ja kryesore dhe slave float. Kjo do të thotë, gjatë funksionimit normal duhet të ketë një furnizim të mjaftueshëm kufijsh.

Tuchanka4 (shumë skllevër)

Strukturë

Tashmë një ekstrem tjetër. Ka baza të dhënash që marrin shumë kërkesa vetëm për lexim (një rast tipik i një siti me ngarkesë të lartë). Tuchanka4 është një situatë ku mund të ketë tre ose më shumë skllevër për të trajtuar kërkesa të tilla, por ende jo shumë. Me një numër shumë të madh skllevërsh, do të jetë e nevojshme të shpikni një sistem riprodhimi hierarkik. Në rastin minimal (në foto), secila prej dy qendrave të të dhënave ka dy serverë, secili me një shembull PostgreSQL.

Një veçori tjetër e kësaj skeme është se tashmë është e mundur të organizohet një përsëritje sinkron. Është konfiguruar që të kopjohet, nëse është e mundur, në një qendër tjetër të dhënash, në vend të një kopjeje në të njëjtën qendër të dhënash si masteri. Masteri dhe çdo skllav drejtohen nga një IP float. Për fat të mirë, midis skllevërve do të jetë e nevojshme të balanconi kërkesat disi proxy sql, për shembull, në anën e klientit. Lloje të ndryshme klientësh mund të kërkojnë lloje të ndryshme proxy sql, dhe vetëm zhvilluesit e klientëve e dinë se kujt i nevojitet. Ky funksionalitet mund të zbatohet ose nga një daemon i jashtëm ose nga një bibliotekë klienti (pool lidhjeje), etj. E gjithë kjo shkon përtej temës së një grupi të bazës së të dhënave të dështimit (failover Proxy SQL mund të zbatohet në mënyrë të pavarur, së bashku me tolerancën e fajit të klientit).

Tuchanka4 refuzim

Nëse një qendër e të dhënave (d.m.th., dy serverë) dështon, dëshmitari voton për të dytin. Si rezultat, ka dy serverë që funksionojnë në qendrën e dytë të të dhënave: njëri po ekzekuton një master dhe IP-ja kryesore float tregon tek ai (për marrjen e kërkesave për lexim-shkrim); dhe në serverin e dytë ka një skllav që funksionon me replikim sinkron, dhe një nga IP-të slave float tregon tek ai (për kërkesat vetëm për lexim).

Gjëja e parë që duhet të theksohet është se jo të gjitha IP-të slave float do të jenë punëtorë, por vetëm një. Dhe për të punuar me të siç duhet, do të jetë e nevojshme proxy sql ridrejtoi të gjitha kërkesat në IP-në e vetme float të mbetur; dhe nëse proxy sql jo, atëherë mund të rendisni të gjithë skllevërit e IP-së float të ndara me presje në URL-në e lidhjes. Në këtë rast, me libpq lidhja do të jetë me IP-në e parë të punës, kjo bëhet në sistemin e testimit automatik. Ndoshta në bibliotekat e tjera, për shembull, JDBC, kjo nuk do të funksionojë dhe është e nevojshme proxy sql. Kjo është bërë sepse IP-të float për skllevër janë të ndaluar të ngrihen njëkohësisht në një server, në mënyrë që ato të shpërndahen në mënyrë të barabartë midis serverëve skllav nëse ka disa prej tyre që funksionojnë.

Së dyti: edhe në rast të dështimit të qendrës së të dhënave, përsëritja sinkron do të mbahet. Dhe edhe nëse ndodh një dështim dytësor, domethënë, një nga dy serverët në qendrën e mbetur të të dhënave dështon, grupi, megjithëse do të ndalojë ofrimin e shërbimeve, do të ruajë përsëri informacionin për të gjitha transaksionet e kryera për të cilat ka dhënë konfirmimin e kryerjes. (nuk do të ketë informacion për humbjen në rast të dështimit dytësor).

Tuchanka3 (3 qendra të dhënash)

Strukturë

Ky është një grup për një situatë ku ka tre qendra të dhënash plotësisht funksionale, secila prej të cilave ka një server të bazës së të dhënave plotësisht funksionale. Në këtë rast pajisje kuorumi nuk nevojitet. Një qendër e të dhënave përbëhet nga një master, dy të tjerat janë të pajisura me skllevër. Replikimi është sinkron, tipi ANY (slave1, slave2), domethënë, klienti do të marrë një konfirmim të kryerjes kur ndonjë nga skllevërit është i pari që përgjigjet se ai e ka pranuar kryerjen. Burimet tregohen nga një IP float për masterin dhe dy për skllevër. Ndryshe nga Tuchanka4, të tre IP-të float janë tolerante ndaj gabimeve. Për të balancuar pyetjet SQL vetëm për lexim mund të përdorni proxy sql (me tolerancë të veçantë ndaj gabimeve), ose cakto njërën IP float skllav gjysmës së klientëve dhe gjysmën tjetër të dytit.

Tuchanka3 refuzim

Nëse një nga qendrat e të dhënave dështon, mbeten dy. Në njërën, IP-ja master dhe float nga masteri ngrihen, në të dytën - IP-të slave dhe të dy slave float (shembulli duhet të ketë një rezervë të dyfishtë burimesh në mënyrë që të pranojë të gjitha lidhjet nga të dy IP-të slave float). Replikimi sinkron midis zotërinjve dhe skllevërve. Gjithashtu, grupi do të ruajë informacione për transaksionet e kryera dhe të konfirmuara (nuk do të ketë humbje informacioni) në rast të shkatërrimit të dy qendrave të të dhënave (nëse ato nuk shkatërrohen njëkohësisht).

Vendosa të mos përfshij një përshkrim të detajuar të strukturës dhe vendosjes së skedarit. Kushdo që dëshiron të luajë mund t'i lexojë të gjitha në README. Unë po jap vetëm një përshkrim të testimit të automatizuar.

Sistemi i testimit automatik

Për të testuar tolerancën ndaj gabimeve të grupimeve duke simuluar gabime të ndryshme, është krijuar një sistem testimi automatik. Nisur nga skenari test/failure. Skripti mund të marrë si parametra numrat e grupimeve që dëshironi të testoni. Për shembull, kjo komandë:

test/failure 2 3

do të testojë vetëm grupin e dytë dhe të tretë. Nëse parametrat nuk janë specifikuar, atëherë të gjitha grupimet do të testohen. Të gjitha grupet testohen paralelisht dhe rezultati shfaqet në panelin tmux. Tmux përdor një server të dedikuar tmux, kështu që skripti mund të ekzekutohet nga tmux i paracaktuar, duke rezultuar në një tmux të mbivendosur. Unë rekomandoj përdorimin e terminalit në një dritare të madhe dhe me një font të vogël. Përpara se të fillojë testimi, të gjitha makinat virtuale kthehen në një fotografi në kohën kur skenari përfundon setup.

Terminali ndahet në kolona sipas numrit të grupimeve që testohen; si parazgjedhje (në pamjen e ekranit) janë katër. Unë do të përshkruaj përmbajtjen e kolonave duke përdorur shembullin e Tuchanka2. Panelet në pamjen e ekranit janë të numëruara:

1. Statistikat e testimit shfaqen këtu. Kolonat:
   • dështim — emri i testit (funksioni në skenar) që imiton gabimin.
   • reagim — koha mesatare aritmetike në sekonda gjatë së cilës grupi rikuperoi funksionalitetin e tij. Ai matet që nga fillimi i skriptit duke emuluar një gabim deri në momentin kur grupi rikthen funksionalitetin e tij dhe është në gjendje të vazhdojë të ofrojë shërbime. Nëse koha është shumë e shkurtër, për shembull, gjashtë sekonda (kjo ndodh në grupe me disa skllevër (Tuchanka3 dhe Tuchanka4)), kjo do të thotë se gabimi ishte në skllavin asinkron dhe nuk ndikoi në performancën në asnjë mënyrë; nuk kishte çelsin e gjendjes së grupit.
   • devijim — tregon përhapjen (saktësinë) e vlerës reagim duke përdorur metodën e devijimit standard.
   • akuzë - sa herë është kryer ky test.
2. Një regjistër i shkurtër ju lejon të vlerësoni se çfarë po bën grupi aktualisht. Shfaqet numri i përsëritjes (testit), vula kohore dhe emri i operacionit. Vrapimi shumë i gjatë (> 5 minuta) tregon një problem.
3. zemër (zemra) - koha aktuale. Për vlerësimin vizual të performancës mjeshtër Koha aktuale shkruhet vazhdimisht në tabelën e saj duke përdorur masterin IP float. Nëse është i suksesshëm, rezultati shfaqet në këtë panel.
4. mundi (pulsi) - "koha aktuale", e cila ishte regjistruar më parë nga skenari zemër për të zotëruar, tani lexoni nga skllav nëpërmjet IP-së së tij float. Ju lejon të vlerësoni vizualisht performancën e skllevërve dhe replikimit. Në Tuchanka1 nuk ka skllevër me IP float (nuk ka skllevër që ofrojnë shërbime), por ka dy raste (DB), kështu që nuk do të shfaqet këtu mundiDhe zemër shkalle e dyte.
5. Monitorimi i shëndetit të grupimeve duke përdorur shërbimin pcs mon. Tregon strukturën, shpërndarjen e burimeve nëpër nyje dhe informacione të tjera të dobishme.
6. Monitorimi i sistemit nga çdo makinë virtuale në grup shfaqet këtu. Mund të ketë më shumë panele të tilla në varësi të numrit të makinave virtuale që ka grupi. Dy grafikë Ngarkesa e CPU-së (makinat virtuale kanë dy procesorë), emri i makinës virtuale, Ngarkesa e Sistemit (emërtuar Load Average sepse është mesatarisht mbi 5, 10 dhe 15 minuta), të dhënat e procesit dhe shpërndarja e memories.
7. Gjurmë e skenarit që kryen testimin. Në rast të një mosfunksionimi - një ndërprerje e papritur e funksionimit ose një cikël pritjeje të pafund - këtu mund të shihni arsyen e kësaj sjelljeje.

Testimi kryhet në dy faza. Së pari, skripti kalon nëpër të gjitha llojet e testeve, duke zgjedhur rastësisht një makinë virtuale për të aplikuar këtë test. Pastaj kryhet një cikël i pafund testimi, makinat virtuale dhe defekti zgjidhen në mënyrë të rastësishme çdo herë. Ndërprerja e papritur e skriptit të testimit (paneli i poshtëm) ose një lak i pafund i pritjes për diçka (> 5 minuta kohë ekzekutimi për një operacion, kjo mund të shihet në gjurmë) tregon se disa nga testet në këtë grup kanë dështuar.

Çdo test përbëhet nga operacionet e mëposhtme:

1. Nisni një funksion që emulon një defekt.
2. Gati? — duke pritur që grupi të restaurohet (kur të ofrohen të gjitha shërbimet).
3. Shfaq afatin kohor të rikuperimit të grupit (reagim).
4. Fix — grupi po “riparohet”. Pas së cilës duhet të kthehet në një gjendje plotësisht funksionale dhe të jetë gati për mosfunksionimin e radhës.

Këtu është një listë e testeve me një përshkrim të asaj që ata bëjnë:

• ForkBomb: Krijon "Jo memorie" duke përdorur një pirun bombë.
• OutOfSpace: Hard disku është plot. Por testi është mjaft simbolik; me ngarkesën e parëndësishme që krijohet gjatë testimit, PostgreSQL zakonisht nuk dështon kur hard disku është plot.
• Postgres-VRASJE: vret PostgreSQL me komandën killall -KILL postgres.
• Postgres-STOP: varet komanda PostgreSQL killall -STOP postgres.
• Fike: “de-energjizon” makinën virtuale me komandën VBoxManage controlvm "виртуалка" poweroff.
• Reset: mbingarkon makinën virtuale me komandën VBoxManage controlvm "виртуалка" reset.
• SBD-STOP: pezullon demonin SBD me komandën killall -STOP sbd.
• Fike: dërgon një komandë në makinën virtuale nëpërmjet SSH systemctl poweroff, sistemi mbyllet me hijeshi.
• Shkëpute lidhjen: izolimi i rrjetit, komanda VBoxManage controlvm "виртуалка" setlinkstate1 off.

Përfundimi i testimit ose duke përdorur komandën standarde tmux "kill-window" Ctrl-b &, ose komanda "shkëput-klient". Ctrl-b d: në këtë pikë testimi përfundon, tmux mbyllet, makinat virtuale fiken.

Problemet e identifikuara gjatë testimit

• Ne kete moment demon rojtar sbd punon në ndalimin e demonëve të vëzhguar, por jo në ngrirjen e tyre. Dhe, si rezultat, defekte që çojnë vetëm në ngrirje Corosinc и stimulues kardiak, por jo i varur sbd. Për kontroll Corosinc tashmë kanë PR#83 (në GitHub në sbd), pranuar në fill mjeshtër. Ata premtuan (në PR#83) se do të kishte diçka të ngjashme për Pacemaker, shpresoj që deri më tani Kapelë e Kuqe 8 do të bëjë. Por të tilla "mosfunksionime" janë spekulative dhe mund të simulohen lehtësisht artificialisht duke përdorur, për shembull, killall -STOP corosync, por kurrë nuk takohen në jetën reale.

• У stimulues kardiak në versionin për CentOS 7 vendosur gabimisht sync_timeout у pajisje kuorumi, si rezultat nëse një nyje dështoi, me disa gjasa nyja e dytë gjithashtu rindizet, në të cilën mjeshtri duhej të lëvizte. Kurohet nga zmadhimi sync_timeout у pajisje kuorumi gjatë vendosjes (në skenar setup/setup1). Ky ndryshim nuk u pranua nga zhvilluesit stimulues kardiak, në vend të kësaj ata premtuan të ridizajnojnë infrastrukturën në një mënyrë të tillë (në një të ardhme të paspecifikuar) që ky afat do të llogaritet automatikisht.

• Nëse konfigurimi i bazës së të dhënave e specifikon atë LC_MESSAGES (mesazhe me tekst) Unicode mund të përdoret, p.sh. ru_RU.UTF-8, pastaj në fillim postgres në një mjedis ku lokalizimi nuk është UTF-8, le të themi në një mjedis bosh (këtu stimulues kardiak+pgsqlms(paf) vrapon postgres), atëherë regjistri do të përmbajë pikëpyetje në vend të shkronjave UTF-8. Zhvilluesit e PostgreSQL nuk kanë rënë dakord se çfarë të bëjnë në këtë rast. Kushton, duhet ta instaloni LC_MESSAGES=en_US.UTF-8 kur konfiguroni (krijoni) një shembull të bazës së të dhënave.

• Nëse wal_receiver_timeout është vendosur (si parazgjedhje është 60s), atëherë gjatë testit PostgreSQL-STOP në master në grupimet tuchanka3 dhe tuchanka4 replikimi nuk rilidhet me masterin e ri. Replikimi atje është sinkron, kështu që jo vetëm skllav ndalon, por edhe masteri i ri. Funksionon duke vendosur wal_receiver_timeout=0 kur konfiguroni PostgreSQL.

• Herë pas here kam vërejtur ngrirje të replikimit në PostgreSQL në testin ForkBomb (mbushje memorie). Pas ForkBomb, ndonjëherë skllevërit mund të mos lidhen sërish me zotërinë e re. Këtë e kam hasur vetëm në grupimet tuchanka3 dhe tuchanka4, ku masteri ngriu për shkak të replikimit sinkron. Problemi u largua vetë pas një kohe të gjatë (rreth dy orë). Nevojiten më shumë kërkime për ta korrigjuar këtë. Simptomat janë të ngjashme me insektin e mëparshëm, i cili shkaktohet nga një arsye tjetër, por me të njëjtat pasoja.

Foto e Krogan e marrë nga Art devijante me lejen e autorit:

Burimi: www.habr.com